维基百科:互助客栈/方针

薇妮
薇妮
角色设定信息
物種	人鱗蛇
性別	女性
出生	地牢中層
所屬	赫斯提亞家族

快捷方式

此頁面探討维基百科的方針與指引。

有關繁简处理的议题，请前往字词转换讨论页留言。
有關条目本身內容的議題，请前往条目探讨區留言。
由於互助客棧討論踴躍，經常遭遇載入及儲存過慢等困難，建議先於對應政策的计划頁面發起討論，並徵求廣泛意見（↓查閱相關議題）；若無人加入討論，或本來涉及較少具體修訂內容者，則亦可直接在此提案。

請注重礼仪、遵守方針與指引，一般問題請至互助客棧其他區或知识问答提出，留言后请务必签名（点击）。

發表前請先搜索存档，參考舊討論中的内容可節省您的時間。

議題最後回應時間為12月10日之前（正在公示者除外）或者該議題已經標記為結束達三日，則該議題會存檔至相關討論頁或存檔頁。討論存檔至相關討論頁後，相關討論標題則會於一日後存檔。跳至本頁的：目錄 · 底端

公告欄

[公告] 在本地启用安全投票及electionadmin权限、調整COVID-19條目共識的規定、規範日本選舉條目命名及禁止有關藝人演出的獨立列表條目羅列非固定參與的節目已經通過。
[公告] 修订WP:外文重定向方针与首句MOS:外语名称格式指引，并将他们对应、选举监察员运作细节及开放自由提名管理员等权限申请、仲裁委员会成立后的管理人员解任机制、抄襲論述併入不要包含原始資料的副本指引、規範資訊框內母公司子品牌的列出方式（重公示）、修订用户名方针与用户页指引、賦予過濾器助理建立或修改防濫用過濾器的權限及修订政治人物关注度指引正在公示，如有意見請儘快提出。
[討論] 互助客栈方针区正在討論不限期不是永久-解封指引與第二次機會、是否將格式手冊移動到MOS命名空間下、在非原創方針新增例子以禁止綜合常識及可靠來源、擴充ITNR獲選類別及根据WP:用戶頁对WP:用戶框进行修订，請踴躍參與討論。
[討論] 互助客栈技术区正在討論修订过滤器警告信息，請踴躍參與討論。
[討論] 互助客栈条目探讨区正在討論有關日本內閣條目的命名問題，請踴躍參與討論。
[討論] 互助客栈其他区正在討論实装Automoderator工具、是否应关闭中文维基百科以抗议基金会举措、管理人員任免制度檢討等事、本地部署安全投票及相关权限、禁制復核及提议将编辑提示内容同步到首页每日提示版块展示，請踴躍參與討論。
[討論] 互助客棧試行案討論區正在討論討論遞進機制試行案-檢討意見分享，請踴躍參與討論。
[廣告] 第四屆臺灣－斯洛伐克編輯松正在進行中，直到12月31日結束，歡迎踴躍貢獻！

[協作] 现有135个页面需维基化，402个条目需清理，43个移动请求正在讨论。

存檔

2003年至2010年
2003年	5月以前					6	7	8	9	10	11	12	月
2004年	1	2	3	4	5	6	7	8	9	10	11	12	月
2005年	1	2	3	4	5	6	7	8	9	10	11	12	月
2006年	1	2	3	4	5	6	7	8	9	10	11	12	月
2007年	1	2	3	4	5	6	7	8	9	10	11	12	月
2008年	1	2	3	4	5	6	7	8	9	10	11	12	月
2009年	1	2	3	4	5	6	7	8	9	10	11	12	月
2010年	1	2	3	4	5	6	7	8	9	10	11	12	月

2011年至2020年
2011年	1	2	3	4	5	6	7	8	9	10	11	12	月
2012年	1	2	3	4	5	6	7	8	9	10	11	12	月
2013年	1	2	3	4	5	6	7	8	9	10	11	12	月
2014年	1	2	3	4	5	6	7	8	9	10	11	12	月
2015年	1	2	3	4	5	6	7	8	9	10	11	12	月
2016年	1	2	3	4	5	6	7	8	9	10	11	12	月
2017年	1	2	3	4	5	6	7	8	9	10	11	12	月
2018年	1	2	3	4	5	6	7	8	9	10	11	12	月
2019年	1	2	3	4	5	6	7	8	9	10	11	12	月
2020年	1	2	3	4	5	6	7	8	9	10	11	12	月

2021年	1	2	3	4	5	6	7	8	9	10	11	12	月
2022年	1	2	3	4	5	6	7	8	9	10	11	12	月
2023年	1	2	3	4	5	6	7	8	9	10	11	12	月
2024年	1	2	3	4	5	6	7	8	9	10	11	12	月

早於10（未完成）或3（已完成）日的討論將會由存檔。

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	关于Wikipedia:避免地域中心#地理，建议增加关于“来”字的论述	40	12	Sanmosa	2024-12-19 18:46
2	修订WP:外文重定向方针与首句MOS:外语名称格式指引，并将他们对应	87	8	自由雨日	2024-12-20 08:58
3	將WP:格式手冊所有方針與論述移動到MOS命名空間，並將MOS命名空間更名為「格式手冊」	1	1	Sanmosa	2024-12-20 08:58
4	应根据WP:用戶頁对WP:用戶框进行修订	1	1	Sanmosa	2024-12-20 09:17
5	赋予过滤器助理修改滥用过滤器权限	45	10	Sanmosa	2024-12-17 16:56
6	提議維基百科:抄襲併入維基百科:不要包含原始資料的副本	57	8	沈澄心	2024-12-20 18:03
7	請求社群關注仲裁委員會在管理員的離任討論中相關的權限問題	48	9	0xDeadbeef	2024-12-20 13:23
8	重新讨论NT:MUSIC	1	1	Sanmosa	2024-12-17 16:42
9	維基百科:命名常规 (人名)中的例子姜太公已经移动	3	3	魔琴	2024-12-13 05:23
10	建議Wikipedia:愛好者內容擴增「交通迷內容」方針之請求與討論	20	4	Sanmosa	2024-12-19 19:06
11	被不限期封禁用户不应默认复审移除IP封禁豁免权限	1	1	Sanmosa	2024-12-18 07:27
12	欢迎就Wikipedia:格式手冊/無障礙/2025草稿提供意见	3	2	ItMarki	2024-12-16 12:58
13	提議DYK/GA/FA引入cooldown time(或譯冷靜時間)	60	11	Sanmosa	2024-12-20 15:38
14	提議WP:POINT引入反對言論規範。	1	1	Sanmosa	2024-12-20 08:48
15	控制複雜ANM案例	13	7	Sanmosa	2024-12-20 23:06
16	建議明確签名的「255字节」是以何种編碼計算	3	2	内存溢出的猫	2024-12-20 17:10

發言更新圖例
最近一小時內
最近一日內
一週內
一個月內
逾一個月
特殊狀態
已移動至其他頁面或完成討論之議題
手動設定
當列表出現異常時，請先檢查設定是否有誤

正在廣泛徵求意見的議題

您可在維基百科:回饋請求系統訂閱特定主題的徵求意見討論通知。

以下討論需要社群廣泛關注：（重新整理）

維基百科格式與命名

Talk:加油！中村同學！！ § 建議更名：“加油！中村同學!!”→“加油！中村同學！！”

“加油！中村同學!!” → “加油！中村同學！！”：! or ！--HeihaHeihaHa-麻瓜了……（留言） 2024年11月21日 (四) 06:30 (UTC)

Talk:南华大学 (湖南) § 建議更名：“南华大学 (湖南省)”→“南华大学 (湖南)”

“南华大学 (湖南省)” → “南华大学 (湖南)”：原本的条目名是“南华大学 (湖南)”，不知道为什么要被移动到“南华大学 (湖南省)”。“湖南”已足够消歧义，且更符合习惯，类似中国地质大学（北京）（这里的括号不是维基百科的消歧义，但能体现常用的命名习惯）。--小林子冲（留言） 2024年11月23日 (六) 22:00 (UTC)

Talk:亨利·比索 § 有關為非漢字文化圈人事物擬定香港譯名的問題

該條目的中文部份由本人創建，一直利用香港音譯將Bishop寫成「比索」，早陣才留意到原來兩年前由淺藍雪將我的標題改為「亨利·畢曉普」，本人今天打算重新增幅，亦因為見已有Note TA而將標題改回為本人最初的用語時，卻被一名稱為向史公哲曰的騷擾，他以廣東話叫法為「原創研究」不斷回退我的修改，甚至不容許我用任何方式將「畢曉普」轉換為「比索」，甚至強行將我一直撰寫開的「比索」換為「畢曉普」，意圖不容許我日後再進行增減時再使用「比索」一詞。並且將香港慣常處理英文讀音的方法定義為「原創研究」和「無心中生有」。現在更剛在本人的討論頁上留下所謂「嚴重警告」的恐嚇。

從Google中我同意「畢曉普」、「畢夏普」的使用可能比「比索」為多，但向史公哲曰執着中文維基內只有使用「畢曉普」、「畢夏普」所以不可以有「比索」的寫法再硬塞以「原創研究」來打壓，完全是架空中文維基的包容性和容許多樣化，對此我需要提出社群的建議。

或是當我被向史公哲曰的橫蠻干預而無法再為條目貢獻時，我寧可以創建者的身份申請廢掉條目。--Foamposite（留言） 2024年12月1日 (日) 08:27 (UTC)

Talk:协调世界时 § 建议删除"现在时间"框

该框内显示的时间并不是当前的协调世界时,而只是上次按"刷新"获得的时间.该时间并没有实际意义.增加一个链接到显示当前协调世界时的网站即可.--Uwuw（留言） 2024年12月5日 (四) 18:55 (UTC)

Wikipedia talk:條目命名一致性決議 § 提议：规范部分铁路条目站名的译法

现状

自2012年起，中维有关JR货物各货物大站条目“○○貨物ターミナル駅”出现了“某某货物总站”的译法。诸如2012年出现的条目札幌货物总站。此后接连出现了东京货物总站、大阪货物总站等车站条目皆从其译法。

问题

一个大问题：“貨物Terminal駅”翻译成“货物总站”的根据在哪？

查Google发现，在2012年前,网络来源中十分缺少有关车站译为货物总站的说法，反倒是2012年札幌货物总站等条目出现之后，类似的翻译多了起来。甚至在2019年，中国铁科院有关人士发表论文时，也引用了“总站”的说法（doi:10.16669/j.cnki.issn.1004-2024.2019.12.12）。因此我怀疑最初维基“货物总站”译法可能为原创研究，并一定程度上造成了长达十余年的文献循环论证。

查证

查铁道科学名词审定委员会《铁道科技名词——汉英法德俄日六种语言》（简体中文）时，所谓“ターミナル駅”翻译为“区段站”。但是欠缺“貨物ターミナル駅”的翻译。

查铁道综合技术研究所《铁道技术用语辞典》（日语）时，ターミナル駅，翻译为“枢纽站”，而“貨物ターミナル駅”翻译为“货运枢纽站”。

以上两例或可证明至少在中国大陆的铁路术语中，所谓“总站”的翻译是非常有问题的。

提议

因为不知道非中国大陆的地区术语是否也有对应翻译，需要请教社群中其他地区的有识者（如@鐵路1@雪雨73），并早日确定翻译方案以匡正对应诸多条目的名称。-- 西行寺海苔子 ハナノモトニテ 2024年12月15日 (日) 12:08 (UTC)

維基百科方針與指引

Wikipedia talk:互助客栈 § 有關互助客棧方針版的長度壓力問題

此前，互助客棧方針版的長度一度逾60萬位元組，在我搬運了若干已結束或stale了的討論後才降到40多萬，然而這個長度還是比起其他互助客棧的版塊來得長（互助客棧其他版的長度現在是20多萬位元組，條目探討版是10多萬，消息、技術與求助版不超過10萬），而且在頁面載入與編輯上也產生了一些問題（我在電腦嘗試載入或編輯頁面的話，頁面完全載入所需的時間顯著地延長了）。有鑒於此前曾有討論提議以WP:徵求意見機制取代互助客棧方針版的機能，我認為現在是合適的時機來提出這件事情。San mo sa _新朝雅政 2024年10月23日 (三) 00:30 (UTC)

Wikipedia talk:可靠来源 § （硕士论文）怎样的影响可以算作“显著学术影响”

“硕士学位论文通常未经类似评估，因此不如博士学位论文可靠，除非其具有显著学术影响。”是否需要用信息页说明“显著学术影响”？
对于一般的（无“显著学术影响”）硕士论文而言，相关行文似乎也有模糊之处，只点出硕士论文“不如博士论文可靠”，而未明言其“不是可靠来源”。是否需要点出“除非具有显著学术影响，否则硕士论文不是可靠来源”（英维是明确点出的：“Masters dissertations and theses are considered reliable only if they can be shown to have had significant scholarly influence.”）？--自由雨日🌧️（留言｜贡献） 2024年10月23日 (三) 16:21 (UTC)

Wikipedia talk:消歧义 § 2020年10月修订案与格式讨论

修订案主要涉及#章节安排问题（最简单的做法只需将一个三级标题改为二级标题），以及#修订WP:消歧义命名的问题。格式讨论涉及主从消歧义页面编写方式（若有必要则亦应修改指引）。——自由雨日🌧️（留言｜贡献） 2024年10月25日 (五) 04:39 (UTC)

Wikipedia talk:管理員的離任 § 仲裁委員會成立後的管理人員解任機制（續）

經共識訂立的仲裁機制及其他過往討論中均就仲裁委員會在處理管理人員解任案獲得社群廣泛同意，在維基百科討論:仲裁委员会#管理人員解任中就達成了「仲裁委員會有權調查管理人員行為是否失當後交社群再行決議」，但就仲裁委員會如何行使有關職權仍有待商榷。我想將這個議題分拆成多個部分去探討，期望獲得最大程度的共識。本討論分為以下部分：

(※)注意：此四機制並非僅能採納其中一個，這四個機制的設計是完全可以共容的。

--路西法人 2024年10月27日 (日) 16:39 (UTC)

Wikipedia talk:封禁方针 § 完善WP:封禁「不限期不是永久」總方針

所謂「不限期」不應理解為「永久」，但WP:封禁並沒有指引給管理員對解封的指引，以確保符合這個目的。對此，建議修改WP:封鎖方針，引入擔保制及對巡查員或回退員進行擴權，以進行有條件解封。

想法：

管理員需就不限期封鎖用戶的封鎖理由寫上解封條件。
不限期封鎖用戶可在完成解封條件後找廷伸確認用戶請求擔保
由廷伸確認用戶向管理員確定不限期封鎖用戶已完成解封條件，並聲明會負責監督該名用戶的編輯。
廷伸確認用戶監管不力的話，會被剝奪擔保資格。
巡查員或回退員對該名用戶的編輯進行二次確認。
直至管理員認為那名編輯者真誠悔改，然後解除監管。
只要擔保者決定不對該名用戶進行擔保或巡查員或回退員認為編輯有問題，隨即啟動即時封鎖程序，解封條件會較上一次更嚴格。

好處：減低管理員的工作壓力，從而達到不限期不是永久的目的。--唔好阻住我愛國（留言） 2024年11月9日 (六) 04:02 (UTC)

Wikipedia talk:非原创研究 § 關於非原創研究問題

1.假設美國某媒體報導：「2024年2月30日，川普發表了一場講話，關於他上任後會徵收關稅。」

那麼，我可不可以基於上述資料，斷定美國將會在川普上任後會徵收關稅？

2.假設英國某媒體中文版報導：「2025年2月31日，白悟空將2026年2月31日於Google Play上架」

那麼，我可不可以基於上述資料，斷定白悟空不能在中國下載？

相關討論：Wikipedia talk:格式手冊/電視#對於剛訂立的格式手冊/電視，細節上的疑問--唔好阻住我愛國（留言） 2024年11月19日 (二) 11:21 (UTC)

Wikipedia talk:格式手册/两岸四地用语 § 提議容許中華民國（中華臺北）體育代表隊使用「中華隊」簡稱

中華民國（中華臺北）體育代表隊使用「中華隊」簡稱，乃其來有自。又無論「中華民國（代表）隊」或「中華臺北（代表）隊」，均可簡稱為「中華隊」，行文實較簡易，且得維持一致格式。故比照港澳代表隊之例，建議放寬格式手冊規定，容許首次提及中華民國或中華臺北代表隊完整名稱後，於條目正文（不包含表格及模板等）使用「中華隊」簡稱；與此同時，仍繼續禁止使用「中華」稱呼，避免過度歧義。望社群斟酌。若有其他方案，亦可一併提出。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年11月26日 (二) 18:32 (UTC)

Talk:亨利·比索 § 有關為非漢字文化圈人事物擬定香港譯名的問題

該條目的中文部份由本人創建，一直利用香港音譯將Bishop寫成「比索」，早陣才留意到原來兩年前由淺藍雪將我的標題改為「亨利·畢曉普」，本人今天打算重新增幅，亦因為見已有Note TA而將標題改回為本人最初的用語時，卻被一名稱為向史公哲曰的騷擾，他以廣東話叫法為「原創研究」不斷回退我的修改，甚至不容許我用任何方式將「畢曉普」轉換為「比索」，甚至強行將我一直撰寫開的「比索」換為「畢曉普」，意圖不容許我日後再進行增減時再使用「比索」一詞。並且將香港慣常處理英文讀音的方法定義為「原創研究」和「無心中生有」。現在更剛在本人的討論頁上留下所謂「嚴重警告」的恐嚇。

從Google中我同意「畢曉普」、「畢夏普」的使用可能比「比索」為多，但向史公哲曰執着中文維基內只有使用「畢曉普」、「畢夏普」所以不可以有「比索」的寫法再硬塞以「原創研究」來打壓，完全是架空中文維基的包容性和容許多樣化，對此我需要提出社群的建議。

或是當我被向史公哲曰的橫蠻干預而無法再為條目貢獻時，我寧可以創建者的身份申請廢掉條目。--Foamposite（留言） 2024年12月1日 (日) 08:27 (UTC)

Wikipedia talk:维基百科不是什么 § 出版書籍、雜誌是否為WP:NOT

如題所述，請教以下情況甚麼時候屬WP:NOT及判定依據?

A)條目收錄自行出版之書籍或論文(有一手來源、但沒有二手、三手來源)；
B)條目收錄自行出版之書籍或論文(有二手、三手來源)；
C)條目收錄~~非自行出版~~之雜誌，雜誌內容包括照片、採訪(有一手來源、沒有二手、三手來源)；
D)條目收錄~~非自行出版~~之雜誌，雜誌內容包括照片、採訪(有二手、三手來源)；
E)條目收錄~~非自行出版~~之雜誌，雜誌內容包括照片，但沒有採訪(有一手來源、沒有二手、三手來源)；
F)條目收錄非自行出版之雜誌，雜誌內容包括照片，但沒有採訪(有二手、三手來源)；--Abcet10（留言） 2024年12月4日 (三) 14:31 (UTC)

Wikipedia talk:用戶框 § 应根据WP:用戶頁对WP:用戶框进行修订

从范围上来看，用户框是用户页的子集。用户框的内容也应受到WP:UPNOT的限制。想起这一点是因为近日又有新用户（Carl66066）连续建立多个在我看来并不合适的用户框。以该用户此前的用户页为例：

视觉效果十分糟糕：颜色搭配不当，背景颜色和文字颜色接近，文本框宽度参差不一；
反复宣告自己的观点：使用大量文本详细描述自己的观点，而这些观点基本上与维基媒体运动及社群协作毫无关联；
名称不明确：模板名称与文本内容不相符，或存在歧义。

由于类似的编辑者以往也存在，我认为有必要按照WP:UP修订WP:UBX，把Template:Subcat guideline-en从WP:UBX移掉，对目前的用户框进行整理，将文本内容过于注重表达个人意见的改为中性的陈述或简单的宣告，无可救药的模板批量送存废。——暁月凛奈 (留言) 2024年12月4日 (三) 15:19 (UTC)

(＋)支持。另外除了根据中维的《WP:用户页》修订之外，也可以根据目前英维的en:WP:Userboxes修订？因为似乎中维的版本有些落后了…… ——自由雨日🌧️❄️ 2024年12月4日 (三) 15:27 (UTC)

Wikipedia talk:命名空间 § 將WP:格式手冊所有方針與論述移動到MOS命名空間，並將MOS命名空間更名為「格式手冊」

因為此案涉及到方針指引的移動，故不放在技術區，放在方針區
前言

見前次討論，已有初步共識，不過當時有意見認為需近一步討論，也因此案涉及到方針指引的移動故需要在方針區確認共識或進一步討論。

方針/指引的部分即：

將所有WP:格式手冊的子頁面(►)移动到MOS:空間下。

技術細節：

將MOS更名為「格式手冊」，即：

編輯以下頁面：

在這些介面設定頁面中

中填入格式手册或格式手冊

提出工單將「格式手册」和「格式手冊」設定為「MOS」的別名（比照當時維基專題命名空間的設置）
命名空間偵測模板更新「格式手冊」命名空間名稱

正文

見前次討論，因為MOS語言維基百科的創立，因此本站設立的MOS捷徑得以因此技術原因phab:T363538，被升格為命名空間。當時的討論主流共識認為，既然都有名字空間了，不如把對應頁面都(►)移动進去。

我現在的想法是，既然基金會都升格MOS為正式命名空間了，我們不使用實在浪費。且屆時上述更名技術操作全部完成後，移動到下面的頁面如維基百科:格式手冊/避免自我提及將會直接顯示為「格式手冊:避免自我提及」同當時「維基百科:XX專題」變為「專題:XX」的好處。

提及上次「關於本命名空間」之討論參與者@S8321414、SunAfterRain、魔琴：歡迎再次發表意見。

(～)補充現行「指引上」MOS的地位現在是偽命名空間，然而目前基金會已經將之升格為「真」命名空間，因此「技術上」MOS的地位現在是「真」命名空間。這次希望的修訂就是能充分利用這個「真」命名空間，同時修訂相關方針指引以滿足phab:T363538的現況。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年12月5日 (四) 04:06 (UTC)

Wikipedia talk:關注度 (音樂) § 重新讨论NT:MUSIC

各位编辑，在下长期以来在浏览编辑维基百科的过程中，发现存在大量的近似爱好者内容，这些作品大多以单曲、演唱会和部分音乐综艺节目为主，通常无法证明其关注度，内文更是不重要的内容堆砌。但是，这些条目又往往能绕过当前NT:MUSIC的相关论述，使编者很难在存废问题或其他条目编辑问题上达成共识。依在下所见，当前的NT:MUSIC至少存在以下问题：

在关于来源的问题上，现今条文是他們曾經被多份獨立於該音樂家或團體以外的已出版可靠來源所提及，但是根据中国大陆当前现状，由于充斥大量的内容农场和宣传内容，使许多看似可靠来源实则存在潜在的不中立现象，如自己按门铃自己听中的中国网来源（《歌手·当打之年》今晚终极奇袭周深首秀未发布新曲）之类，在下看不到任何属于可靠来源的证据。
在关于音乐作品的内容中，维基百科:商业排行与认证是部分维基编者编辑部分单曲条目的重要依靠，但是中国大陆的音乐榜单要么是平台的自嗨、要么是粉丝的刷榜，毫无公信力可言。如被部分编辑推崇的腾讯音乐由你榜，就曾被举报过开通年会员可大大提高用户打榜（主要包括播放、收藏、下载、分析、点赞歌曲等）权重（1），并且该榜单仅限腾讯拥有版权的音乐，此类排行榜获得什么周榜月榜第几名、有多少可信度自有公论，其他类似网易、酷狗等等推出的野鸡榜单更是不用再浪费时间。
另外，在相当多内容的条目中存在大量毫无意义的内容，几乎要把维基百科变成Fandom。如“天外来物”世界巡回演唱会中什么“衢州新闻媒体中心在抖音官方账号上发布了视频，表达了对薛之谦的感谢”、自己按门铃自己听中类似“周深在演唱的時候，身穿一件珍珠裝飾的牛仔夾克，搭配黑色T恤和牛仔褲亮相”的表述，在下看不出放在条目内的必要。
现存的NT:MUSIC中没有关于演唱会关注度的表述。

综上所述，现存的NT:MUSIC及其他相关页面均为论述或指引，并且部分表述相当模糊，大量的条目游走在关注度的边缘，因此在下建议社群对上述内容进行重新讨论并争取达成共识并升格为方针。由于刚刚提起讨论，在下暂不提出新的方案内容，待社群讨论后再进行总结。--SheltonMartin留言|签名 2024年12月11日 (三) 01:22 (UTC)

Wikipedia talk:申请解除权限 § 被不限期封禁用户不应默认复审移除IP封禁豁免权限

Wikipedia:申请解除权限在议的多项提议和既往“判例”表明，永封用户经由“已封禁或除权用户复审”快速剥夺IPBE权限。然，本站用户对IPBE权限的使用多是因为GFW封锁下被迫使用代理编辑，为正常编辑所必须之权限，在用户尚未被移除编辑其讨论页权限前移除其IPBE权限在实践上剥夺了被封禁用户编辑其讨论页进行初步申诉的能力，显然是越俎代庖。此外，依据Wikipedia:IP封禁豁免#移除權限一节，被封禁用户虽可能已不被社群信任，但亦不太可能滥用其权限（IPBE），被完全封禁的用户的权限也会因为不活动而自动移除，并无主动快速移除其IPBE权限的必要性。综上所述，提议：

現行條文

提議條文

出于保留受GFW影响的用户在被封禁后使用其讨论页进行申诉的能力，对于拥有IPBE权限的无限期封禁用户，在无证据证明该用户可能滥用其IPBE权限的情况下，不应在其被不限期禁止编辑其讨论页前主动移除其IPBE权限。

此提议需要熟悉反破坏工作（如傀儡调查）的社群成员讨论，另ping之前在布告板参与讨论的@自由雨日、Ericliu1912、Allervous、Manchiu、阿南之人。--HeihaHeihaHa-戒慎恐惧……（留言） 2024年12月13日 (五) 13:40 (UTC)

Wikipedia talk:关注度 (人物) § 修订政治人物关注度指引

此討論正在公示7天，直至2024年12月27日 (五) 02:11 (UTC)結束；如有意見請儘快提出。

現擬修訂WP:关注度 (人物)如下：

現行條文

政治實體及一級行政區的領導階層（例如總統、總理和首相等等）、法律上或事实上最上級及一級行政區行政機構的成員（例如，內閣成員、中共中央政治局常委）、立法機關的議長、議員或代表。

提議條文

現任、曾任及／或候任國際級、國家／地區^[1]級及／或（採用聯邦制或類似政治體制的國家^[2]的）一級行政區級權力機關的重要實權公職及／或立法機關成員^[3]。

参考資料

^ 「地區」指非國家之獨立或高度自治政治實體。
^ 雖然俄罗斯在其憲法上為联邦制國家，然而由於其国体高度中央集权，本條文在處理上不將俄羅斯視為採用聯邦制或類似政治體制的國家。
^ 就共產主義國家與朝鲜民主主义人民共和国而言，僅限其常設機關的成員適用，如全国人民代表大会的常設機關為其常務委員會。

San mo sa _{Samāʾun la-ʿamruka ʾaw ka-s-samā} 2024年12月13日 (五) 15:59 (UTC)

Wikipedia talk:不要為闡釋觀點而擾亂維基百科 § 提議WP:POINT引入反對言論規範。

現行條文

提議條文

如果你在一場討論中欲發表反對言論，但是您發現自己並沒有時間持續關注該討論內容。

理當不要發言，以免您因為對提案不理不睬的態度而妨礙其他人形成共識。

而不要只撇下反對意見卻沒有跟進其他編輯者就着您的反對意見進行深入討論。

現行條文

提議條文

如果你在一場討論中欲發表反對言論。

理當在討論階段表達反對意見。

而不要在公示/投票結束當天提出反對意見。

--唔好阻住我愛國（留言） 2024年12月18日 (三) 14:53 (UTC)

維基百科提議

Wikipedia:互助客栈/其他 § 在本地啟用安全投票及electionadmin权限

本主題或以下段落文字，移動自Wikipedia:互助客栈/技术。执行者：即请秋安 ZhaoFJx_(论•签) 2024年10月17日 (四) 20:53 (UTC)。

原标题：SecurePoll elections with the electionadmin right

（我很抱歉用英语写作。请随意翻译此消息。）

Hello! My name is Joe Sutherland and I'm on the Trust and Safety team at the Wikimedia Foundation. In the past, your community has shown interest in holding elections with SecurePoll — perhaps you already have through votewiki. We are now looking into making this available to local communities to run elections themselves. This will require the "electionadmin" right to be enabled on your project, which is a right that allows access to sensitive information.

As such, it is likely that you will need to run a Request for Comment (or similar process) to ascertain consensus for the implementation of this feature. To help guide such a discussion, we've put together a Meta-Wiki page with more information about what enabling the right will mean for your community.

If your community does discuss and decides to move forward with this, T&S would like to support you — please let us know via email ( ca@wikimedia.org ) if and when consensus is reached. Thank you!--JSutherland (WMF)（留言） 2024年10月17日 (四) 20:07 (UTC)

Wikipedia:互助客栈/其他 § WMF考虑向印度法院披露编辑身份信息，本站是否应该关站抗议

原标题为：WMF考虑向印度法院披露编辑身份信息，英维正在讨论关站抗议

2024年11月14日17:29 (UTC)，也就是几个小时以前，英文维基百科用户发起民意调查，讨论是否就基金会考虑向印度法院披露编辑身份信息而闭站抗议。如果英维闭站抗议，本站是否跟随？ ——魔琴［身份声明留言贡献新手2023］ 2024年11月14日 (四) 20:09 (UTC)

Wikipedia:互助客栈/其他 § 重启Automoderator部署讨论

於Phabricator查看
編號T367306的工單

十余月前，该讨论向社群引介了自动化反破坏Automoderator工具，然其因热度不足而无疾而终。因此，我谨引用原留言：

大家好，我的名字是Sam Walton，是管理员工具（Moderator Tools）团队的产品经理。我们正在开发一个名为Automoderator的项目，该项目让社群能够根据社群自定义的规则自动回退破坏性编辑。我们正在寻求对我们项目的意见，并有一些问题需要巡查员和管理员的参与，以帮助我们更好地理解。除了项目主页面上的概述和问题之外，我们还有两个子页面提供更具体的资讯：
如果您想研究Automoderator的准确率，并查看它在不同编辑上的表现，我们设置了一个测试流程。您可以帮助我们找到新的模式，并在Automoderator部署之前将其纳入考虑范围（译注：例如怎样改善误判问题、使用什么程度的准确率（cution levels）比较好）。评估计划是用来确定Automoderator是否实现目标且不会产生负面影响的计划初稿。如果您对我们收集的数据或制定的指标有任何想法，那么您可以在这里分享！
如果您对Automoderator有任何疑问，或者您的社群是否想要使用这个工具，请告诉我！
— User:Samwalton9_(WMF)

还请社群评估该工具部署之可能性及价值为荷。——敬颂冬绥 ZhaoFJx_(论•签) 2024年12月18日 (三) 19:45 (UTC)

Wikipedia:互助客栈/其他 § 编辑提示已建设完毕，现提议将内容同步到首页“每日提示”版块展示

经过Tisscherry君最近一段时间的不懈努力，Wikipedia:提示的所有每日提示内容已经建设完成（终于完成了一个天坑orz）。有鉴于此，如Wikipedia:每日提示维护小组#任务所述，现提议将“提示”内容同步到首页“每日提示”版块更新，特此征求社群意见。--Jeffchu2014（留言） 2024年12月19日 (四) 10:43 (UTC)

可靠来源方针增加用户生成内容

本主題全部或部分段落文字，已移動至Wikipedia talk:可靠来源、Wikipedia talk:可供查證。执行人：Jimmy-bot（留言） 2023年3月7日 (二) 08:14 (UTC)。[回复]

整理引导新手的相关页面

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:參與貢獻、Wikipedia talk:新手入門、Help talk:簡介、Wikipedia talk:新手上路、Wikipedia talk:第一印象、Help talk:從這裡開始、Wikipedia talk:新手簡明指南、Wikipedia talk:線上訓練、Wikipedia talk:維基百科大歷險、WikiProject talk:維基百科發展/新手2023。

目前用以帮助新人的页面实在庞杂。WP:欢迎、WP:入門、H:簡介和WP:參與貢獻内容都大差不差；WP:新手上路感觉也可和WP:第一印象等分享感受的页面合并；H:從這裡開始是不是另一种WP:新手簡明指南呢；WP:線上訓練整得不明不白，又出来了WP:維基百科大歷險。这些页面看似相同，实际偏向主题各不相同，但是新手看来只会感到困惑；且目前想快速编辑的新手也很难直接找到有用的帮助，是否应该参照英维在侧边栏放入引导页面的链接呢，比如H:簡介。--甘糸（留言） 2022年11月7日 (一) 02:57 (UTC)[回复]

很搞笑的事情是主页上的「人人可编辑」链接转到WP:欢迎，左右两边都是navbox，各种鲜艳晃眼的色彩。反观英维就好看得多了。--0xDeadbeef（留言） 2022年11月9日 (三) 10:27 (UTC)[回复]

WP:欢迎其实完全可以被H:简介取代。--BlackShadowG Slava Ukraini! 2022年11月9日 (三) 13:34 (UTC)[回复]

有一种上世纪网页的美，花花绿绿，要是再来点滚动屏就更像了^{[開玩笑的]}----诚挚的 ZhaoFJx^{（论•编）} 2022年11月14日 (一) 14:49 (UTC)[回复]

怕搞混的話，就在最上方放「論述」也行吧！空氣小貓（留言） 2022年11月15日 (二) 06:55 (UTC)[回复]

儘管支持，這可是個大工程。--Temp3600（留言） 2022年11月15日 (二) 16:46 (UTC)[回复]

建了个协作页面：WikiProject:維基百科發展/新手2023，个人觉得建立条目相关页面也需要优化整理。 ——魔琴 [ 留言贡献 ] 2022年11月18日 (五) 09:08 (UTC)[回复]

認同有改革之必要，以確實分流。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2022年11月25日 (五) 18:18 (UTC)[回复]

話說這些頁面的討論頁也挺亂的orz —— Eric Liu_{創造は生命（留言・留名・學生會）} 2022年12月4日 (日) 16:27 (UTC)[回复]

下面有必要挂{{不存档}}吗？这应该是一个比较长期的工作，如果没有用户有意帮忙整理这些页面，似乎讨论串开着意义也不太大。--BlackShadowG Slava Ukraini! 2022年12月6日 (二) 12:21 (UTC)[回复]

那就先撤除模板吧，改日有進度再議。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2022年12月16日 (五) 17:03 (UTC)[回复]

老實說，目前wikiedu.org已經備有學生和教師的線上訓練，但全都是英文版。

雖然說保留本地版本的線上訓練是沒問題的，但小弟粗略看過了一下，還有不少頁面有待建立…--飄流書生（見山 · 客棧 · DC20） 2022年12月20日 (二) 15:26 (UTC)[回复]

看了这些文章我脑子已经晕了……

这里以读者看到页面的顺序，介绍一下我的思路，这是一个力求页面数最少的方案，读者在入门之前只需要看WP:关于和WP:参与贡献两个页面。

读者应该可以从首页进入WP:关于和WP:参与贡献（或者下面第三点提到的合并后的页面）。手机版主页也应该要有。
把WP:参与贡献的内容移动到WP:关于，后者应该包含维基百科简介、邀请加入的广告，顺便求他们捐款。（不过WP:参与贡献的界面做得不错，删了有点可惜）
把WP:欢迎和WP:新手入门/主页合并（我觉得WP:参与贡献才是最佳名称）。邀请读者注册账户，同时明显给出中国大陆用户无法编辑和注册的解决方案。此处开始给出求助方法（互助客栈）。第二页WP:新手入门/介绍开始入门。
继续往下，新手入门的其他部分不变。H:简介的那一堆按钮可以考虑放到新手入门里。

大概这样吧，之后再补充。--HSUZR（留言） 2023年1月2日 (一) 15:39 (UTC)[回复]

补充一下，我这种方案有两个缺点。一是会使WP:关于文字太多、过于臃肿；二是WP:欢迎起到了分流效果，把人分为可能想加入维基百科的人和普通读者，而这种方案让分流效果没了。如果让WP:关于来分流，它会变得更臃肿。--HSUZR（留言） 2023年1月2日 (一) 15:56 (UTC)[回复]

个人感觉WP:欢迎和Wikipedia:新手入門/主頁都需要存废，但二者在中维确实影响巨大。关于分流，可以将想编辑的转到H:简介，普通读者阅读WP:关于就行。WP:參與貢獻和WP:关于倒是改版成英维的形式比较好。--PexEric 💬|📝 2023年1月24日 (二) 07:10 (UTC)[回复]

感觉WP:参与贡献的东西太多了，而且分页里面还有一堆链接，我都懒得看

囧rz…… ——魔琴 [ 留言贡献新手2023计划 ] 2023年2月27日 (一) 18:02 (UTC)[回复]

新手編輯疑難支援

不另開新文，話說咱們應另行建立一個供新手詢問有關編輯事宜的地方（感覺既有的wp:VPD不太適合）。參考英維，新手大多所問的，均與一些編輯上的疑難有關。

而事實上，英維在其IRC免責聲明頁上有這樣一句：

“

Help is provided by volunteers, so it might take a few minutes before someone replies to your question. Try leaving the chat window open for a bit. If you don't get a reply before you need to leave, consider asking your question at the Teahouse instead.

”

故此，我們需要在既有站外疑難解答群的基礎上，另行建立一個站內版本，為新手編者提供詢問疑難的另一渠道。暫時茶館頁面已成雛形，有興趣可以看看。另可(＆)建議將wp:RD按不同主題分拆，歡迎討論。—飄流書生（見山 · 客棧 · DC20） 2022年12月19日 (一) 04:25 (UTC)[回复]

對於茶館，個人持正面態度，惟擔憂加劇疊床架屋之局面；對於知識問答，個人強烈推薦停止使用結構式討論，此技術非常不利於查詢及追溯過往話題。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2022年12月20日 (二) 13:23 (UTC)[回复]

天灭结构式讨论，加载起来巨慢，而且还不能查找 ----顺颂时祺 ZhaoFJx^{（论•编）} 2022年12月21日 (三) 14:44 (UTC)[回复]

那么WP:VPA呢？ ——魔琴 [ 留言贡献新手2023计划 ] 2022年12月31日 (六) 06:28 (UTC)[回复]

雖然新手亦可使用既有之詢問台（即wp:VPA），但這裡提議之「茶館」概念，則是一個專為新手而設的問答平台，在友善的環境（沒錯，新手最需要的就是這個！）下，由「茶館主持人」解答新手編輯疑難（參考這裡以了解成為茶館主持人的要求）。

具體細節還可以再討論，畢竟現階段還只是個雛形而已。--飄流書生（見山 · 客棧 · DC20） 2023年1月6日 (五) 07:22 (UTC)[回复]

標準答案是Wikipedia:互助客栈/求助，然而不太方便。--Temp3600（留言） 2023年1月8日 (日) 15:19 (UTC)[回复]
既然說了「不方便」，那麼解決方法是甚麼？這裡提出的「茶館」概念，正是以「為新手提供一個方便、友善的詢問處所」為理念而建立的一個新頁面。現有的wp:VPA仍舊可以保留，但茶館的實踐細節（包括本地化）仍有待各位一同討論。--飄流書生（見山 · 客棧 · DC20） 2023年2月7日 (二) 15:28 (UTC)[回复]
注：WP:茶馆已创建。 ——魔琴 [ 留言贡献新手2023计划 ] 2023年3月7日 (二) 16:43 (UTC)[回复]

新人小工具配置指南

剛剛突然想到，新人其實欠缺很多常用小工具，必須先學習配置.js，有些實用小工具甚至連資深使用者也未必了解。有否可能編製一份新人小工具配置指南?--Temp3600（留言） 2023年1月17日 (二) 11:32 (UTC)[回复]

这让我想起U:AT/js……啊，好像咕咕了

——魔琴 [ 留言贡献新手2023计划 ] 2023年1月17日 (二) 12:37 (UTC)[回复]

對對，最好弄出一整塊代碼，新人複製到js 就可以立即使用。--Temp3600（留言） 2023年1月17日 (二) 13:33 (UTC)[回复]

@Temp3600：你是指怎樣安裝小工具的教程還是怎樣使用小工具的教程？（雖然我感覺兩個教程都能編製一下就是了）San mo sa _{Συ γάρ μοι και μοίρα εί και τύχη} 2023年1月17日 (二) 12:39 (UTC)[回复]

的確兩方面都需要。先弄出"一鍵式常用小工具安裝教學"，再逐個小工具手把手教。不然新人就會覺得維基很多事情都要打一大串代碼，根本辦不過來，其實是依靠工具自動產生的。--Temp3600（留言） 2023年1月17日 (二) 13:41 (UTC)[回复]

做個小工具，自動對非自確用戶啟用？--洛普利寧 2023年1月18日 (三) 08:09 (UTC)[回复]

我覺得可以在小工具設定中新闢一區，羅列常用之小工具，以便新手直接批量勾選啟用。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年1月18日 (三) 08:31 (UTC)[回复]

我刚刚去翻了一遍自己启用的小工具和用户脚本，实话说，我其实没注意到有小工具对新人而言帮助很大。目前小工具以协助维护工作居多，比如最常用的TW、Rater、HotCat、DisamAssist、HotDefaultSort都是协助维护工作的，对于刚学会编辑的新人而言帮助其实不算很大。--BlackShadowG Slava Ukraini! 2023年1月18日 (三) 11:38 (UTC)[回复]

先教「如何自動填充cite模版」。--Temp3600（留言） 2023年1月19日 (四) 14:35 (UTC)[回复]

是指Help:如何引用来源中提到的Wikipedia:參考文獻工具列/2.0吗？印象中这个工具好像是默认启用的。--BlackShadowG Slava Ukraini! 2023年1月20日 (五) 04:02 (UTC)[回复]

得教怎樣用。我早一陣子才知道那個放大鏡是「自動填充」功能。--Temp3600（留言） 2023年1月21日 (六) 05:57 (UTC)[回复]

我是WP:自动登出的触发原理揭露时才知道有这玩意

囧rz……说到这，我记得台湾分会有针对这个的教学。 ——魔琴 [ 留言贡献新手2023计划 ] 2023年1月24日 (二) 07:56 (UTC)[回复]

现在默认还不是可视化编辑吗？我记得这件事以前讨论了很久。2.0是只有source才有的功能。----Cat on Mars 2023年2月8日 (三) 05:34 (UTC)[回复]

新版編輯器更突出自動引用網址功能，我認為應該推薦新手使用。若擔心視覺化編輯器的一些問題，可使用（2017）原始碼編輯器。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年1月24日 (二) 12:25 (UTC)[回复]

总觉得让新手用这些工具不太妥当，有点担心玩火上身或者不慎破坏之类的？像{{cite}}这些模板现在都可以用可视化编辑器来填充，别的工具大部分也是是锦上添花（？）——顺颂时祺 ZhaoFJx^{（论•编）} 2023年1月20日 (五) 15:39 (UTC)[回复]

沒有外在工具，要畫一個表格已經非常困難。--Temp3600（留言） 2023年1月21日 (六) 06:00 (UTC)[回复]

可视化编辑器和新版编辑器似乎都可以帮助画表格。--PexEric 💬|📝 2023年1月30日 (一) 09:23 (UTC)[回复]

@PexEric：不是似乎，是可以。作為一個採用新版源代碼編輯器的編者，小弟不知試過直接利用「表格」按鈕加入過多少表格了…--飄流書生（見山 · 客棧 · DC20） 2023年2月8日 (三) 00:56 (UTC)[回复]

这串又没动静了……我个人建议是整理出来两个页面，其中一个侧重编辑的直接塞在左侧栏里。毕竟就算有14亿+人说中文，中维活跃用户甚至比不上德维的一半……--ときさきくるみ 2023年2月17日 (五) 22:36 (UTC)[回复]

不知道有多少是被 Wikipedia:IP封禁例外挡住的，如果可以在该拦截处能统计一下就好了。--Kethyga（留言） 2023年2月23日 (四) 14:27 (UTC)[回复]

建議將Wikipedia:不要訴諸法律威脅提昇為法律方針

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:不要訴諸法律威脅。

有鑑於最近發生的某些事件，我建議將WP:NLT正式升級為法律方針（如同英文維基百科），雖然可能沒辦法完全阻止類似的事情再次發生，但至少有個可以遵循的依據。--冥王歐西里斯（留言） 2022年11月20日 (日) 23:28 (UTC)[回复]

这是否需要法务或者具有法律背景的用户看看是否符合法律要求啊？--百無一用是書生 (☎) 2022年11月21日 (一) 03:04 (UTC)[回复]

或許，需要找人看看。--冥王歐西里斯（留言） 2022年11月21日 (一) 03:17 (UTC)[回复]

可能直接寄信給WMF法務部門請他們來看比較快？--SunAfterRain 2022年11月21日 (一) 09:07 (UTC)[回复]

页面未完善（有一句未翻译内容）和不算稳定。“法律方针”的概念？社群有权定义法律方针吗。也许更适合定为态度指引，但然严厉性可能弱很多。需注意，除了诉诸诉讼和举报，其他对行为合法性的暗示也可能在内和引致同等效果。非站内行为要约束吗，也许较难实现，但似乎很有意义（如WP:OA2021），但验证、警告和处置会相当麻烦。--YF dyh000（留言） 2022年11月21日 (一) 04:21 (UTC)[回复]

法律方針是指「These are policies with legal implications」。「不要訴諸法律威脅」此處理方式確實可能會造成法律上的影響。而英維亦將此視為法律方針。謝謝。--SCP-0000（留言） 2022年11月21日 (一) 04:41 (UTC)[回复]

那句應該是從英文維基百科來的，但說真的我也看不太懂那句是想要表達什麼。--冥王歐西里斯（留言） 2022年11月21日 (一) 05:28 (UTC)[回复]

看上下文是违反这些方针的内容不受WP:NOTCENSOR限制，可以管辖条目内容。-Mys_721tx（留言） 2022年11月21日 (一) 05:40 (UTC)[回复]

那我有更多問題了。法律威脅關條目內容什麼事？升格作法律方針又有什麼效力/效果？這種經紀公司直接見一個ban一個不就行了嗎？-某人 ✉ 2022年11月21日 (一) 08:31 (UTC)[回复]

(＋)贊成，對於某些法務方面的疑難，的確需要訂立方針加以規範，免得使用者們無意中觸法。--Jiaweipan（留言） 2022年11月21日 (一) 09:24 (UTC)[回复]

“无意中触法”与此方针是相悖的吧。--YF dyh000（留言） 2022年11月21日 (一) 10:23 (UTC)[回复]

目前我跟下方LuciferianThomas君的觀點比較像，雖然目前只是論述頁面，也已有與此相關的封禁事件，但畢竟只是論述而非方針，將其提昇為法律方針更能確立標竿，讓管理員與其他社群成員面對類似事件時更有底氣解決。--冥王歐西里斯（留言） 2022年11月22日 (二) 11:40 (UTC)[回复]

(＋)支持。正式訂立為法律方針可以確保針對法律威脅的封禁能夠有明確依據下執行。現今有關法律威脅的封鎖一般都僅以無任何地位的WP:LEGAL作為封禁理據，當然執行上並非一定有問題，但實際上仍然是一個程序漏洞可以給人鑽。--路西法人 2022年11月21日 (一) 14:56 (UTC)[回复]

我記得以前也有人以法律方式刪除條目內不實內容：楊受成控告維基媒體基金會事件，對方只要有心走法律途徑也能處理那些內容，當然這需要鈔能力。--Nostalgiacn（留言） 2022年11月22日 (二) 08:21 (UTC)[回复]

「已截圖存證」算是什麼樣的法律威脅？我真是想不明白啊。而且也不需要給這樣多的例子吧。--Ghren 🐦🕓 2022年11月22日 (二) 08:25 (UTC)[回复]

畢竟有唐澤貴洋（幫在2chan遭到網暴的高中生，順著IP讓不少人入獄）的情況，雖然也很少見啦。--Nostalgiacn（留言） 2022年11月22日 (二) 08:47 (UTC)[回复]

截图的法律效力较弱，但哪些是法律威胁，哪些是正当或不当的威胁/警告提醒/沟通态度问题，还是很难说。比如“您在本条目的所为已存档并转交我司相关部门/人员”，是法律威胁呢，还是表示不满+等待后续沟通的意思，换成“法务”就一定是法律威胁吗，不明说就无事吗。“已对相关发言进行公证”“已对相关发言进行永久存档（网页存档）”在同一场景中有多少本质区别。涉嫌网暴、人肉搜索等风险的非法威胁，是否不考虑同等规制，而且起诉是权力，威胁才是不当的。--YF dyh000（留言） 2022年11月29日 (二) 16:06 (UTC)[回复]

截圖的法律效力較弱？看看香港的立場新聞涉煽動案件，其實截圖都可以作為法律證據。--Wpcpey（留言） 2022年11月29日 (二) 16:15 (UTC)[回复]

未经公证不能保证未篡改，无法作为证据，所以个人“已截图”说是法律威胁比较牵强。如果已截图算，已保存网页、已记录永久链接难道也算法律威胁了。--YF dyh000（留言） 2022年11月29日 (二) 17:41 (UTC)[回复]

那看起來截圖那條可以移除或是移動到其他相關的頁面，其他的例子呢？--冥王歐西里斯（留言） 2022年11月30日 (三) 03:13 (UTC)[回复]

复看了一下，也可能是当时管理员自作主张移除掉（虽然理由是以“没有来源及来源可信度不明”移除内容）？虽然现在的话，可以用Wikipedia:修订版本删除请求的RD2、RD4来申请版本移除。就算声明了发律师函给基金会，也要等基金会是否接受和以基金会行动的方式来直接处理，本地对于这种现实法棍没必要理会。——Sakamotosan路过围观 | 避免做作，免敬 2022年11月22日 (二) 10:15 (UTC)[回复]

(＋)支持：我的意見同LuciferianThomas君。--~~S i d~~ 2022年11月22日 (二) 15:51 (UTC)[回复]

是說目前似乎無人明顯反對，能進公示流程了嗎？--冥王歐西里斯（留言） 2022年11月29日 (二) 02:58 (UTC)[回复]

送公示吧。--路西法人 2022年11月29日 (二) 14:53 (UTC)[回复]

上方有些意見值得重視，但都未有展開有效討論。--Xiplus#Talk 2022年11月29日 (二) 15:34 (UTC)[回复]

看起來下面部份條文已經有可用的版本出來了。--冥王歐西里斯（留言） 2022年12月11日 (日) 14:01 (UTC)[回复]

同xiplus.建議將提昇為法律方針與更新案分開公示，兩案皆通過後再同時執行。--Temp3600（留言） 2022年11月29日 (二) 16:12 (UTC)[回复]

那麼法律方針本身的文字更新應該可以先公示了。--冥王歐西里斯（留言） 2022年11月29日 (二) 23:53 (UTC)[回复]

方針列表#法律方針不是任何指引。不需要公示。--Ghren 🐦🕖 2022年11月30日 (三) 11:01 (UTC)[回复]

对于例子依然觉得不妥。例子重覆，而且引用同一案的说话也不免太多了。--Ghren 🐦🕖 2022年11月30日 (三) 11:10 (UTC)[回复]

不如閣下直接動手改？--冥王歐西里斯（留言） 2022年11月30日 (三) 11:39 (UTC)[回复]

(＋)部分支持：提出司法控訴、保留法律追究權、向警方報案，明確表示採取法律或行政手段，造成損害人身安全的風險；若被職員認為社群缺乏自我約束的能力，因此導致基金會行動，結果不是所有人樂見的。 -- 月都 ※ 2022年12月2日 (五) 16:05 (UTC)[回复]

(－)部分反對：具體細節需要討論。 -- 月都 ※ 2022年12月2日 (五) 16:05 (UTC)[回复]

閣下可在下方的逐條討論發表意見。--冥王歐西里斯（留言） 2022年12月2日 (五) 23:45 (UTC)[回复]

謝謝您的提醒，新增條文以淺綠色顯示，刪除條文以淺紅色顯示。 -- 月都 ※ 2022年12月3日 (六) 07:12 (UTC)[回复]

部分需要輕微修改；理解法律威脅章節，我認為中心句以外的需要重寫，至少清晰化條文。 -- 月都 ※ 2023年1月26日 (四) 13:46 (UTC)[回复]

(＋)支持--Fox6667（留言） 2022年12月3日 (六) 18:02 (UTC)[回复]

(＋)支持。--Kriz Ju（留言） 2022年12月5日 (一) 19:01 (UTC)[回复]

(！)意見：“法律威胁的结论”一节加上“在被封禁前应该提醒用户不要诉诸法律威胁”之类的内容。理由：1.不是所有人都知道这一方针 2.用户可能并不是这个意思而对方会“感受到”法律威胁--落花有意12138 _{论回复请ping我} 2022年12月21日 (三) 09:02 (UTC)[回复]

@冥王欧西里斯：(！)意見导言第二行“您不应该发布法律威胁，而是应该尝试依照维基百科解决争议的程序来处理”后加上“除非前述程序未能达成您希望的结果”。理由：我们应当排斥的是不讨论就采取法律程序，而不是限制合法权利( π )题外话各位注意“权利”和“权力”的区别。--落花有意12138 _{论回复请ping我} 2022年12月21日 (三) 10:12 (UTC)[回复]

反對落花有意的修訂建議，違背LEGAL方針的本意，就算無法達成希望的結果，維基百科也不是釋出法律威脅的地方。--路西法人 2022年12月21日 (三) 11:37 (UTC)[回复]

@LuciferianThomas：如果对方没有达成希望的结果，那么其自然会采取法律手段。目前定义的法律威胁包括通知已经采取法律手段。我认为这一通知应当被允许，因为社群提前知道对方采取法律手段比不知道要好。--落花有意12138 _{论回复请ping我} 2023年1月17日 (二) 12:59 (UTC)[回复]

(！)意見：自然會採取沒錯，然而一旦獲得通報，亦非平台鼓勵之事，尤其嚴重傷害此平台立意宗旨的告知；而所謂比較好，請問如何比較好呢？還請落花君明示，謝謝。下方段落的條文有談到並未全然斷絕用戶告知之權利，而是讓管理員有較大空間裁處，只是告知和威脅難謂涇渭分明，也有濫用或技巧性使用、遊走灰色地帶之空間，因此若單論線上編輯行為或線下聚會活動，個人認為基本上此平台不歡迎動輒告知或通知採行法律途徑。請熱心站友可參閱下方段落。--Kriz Ju（留言） 2023年1月17日 (二) 19:14 (UTC)[回复]

(！)意見：用戶擁有興訟之合法權利或採取各式法律途徑，是個人自由和行為，而法律恫嚇或要脅並非一般站內或社群相關活動應容忍之事，況且訴諸法律者即便不知道站內規範，亦絕無可能於當下毫無訴諸法律之用意，也就是總不可能不知道自己正在告知或施壓對方；反過來講，站內程序是否讓自己滿意，亦非有心於站內活動者公開或私下對他人揚言採行法律途徑，卻無適當理由之藉口。也就是說，人人可以有隨意法律興訟的自由，而站內和社群也可以有阻止此類用戶於此平台或社群內活動的權利；至於法律爭議孰是孰非，正因法律事件樣態複雜，個人才會建議授權管理員決定適當的處理措施。--Kriz Ju（留言） 2022年12月21日 (三) 17:27 (UTC)[回复]

@Kriz Ju：用户的确可能宣布采取法律途径，而不知此站不允许宣布。一些用户可能并没有注意到维基百科与其他网站的不同，而这一常见的疏忽不应当成为封禁的理由。“诉诸法律”和“法律威胁”在语义上显然不同，但目前社群对其的定义并没有体现这一不同，我也提醒您注意不要混淆它们。我注意到，您认为“站内程序是否让自己满意，亦非有心于站内活动者公开或私下对他人扬言采行法律途径，却无适当理由之借口”，同时也认为“人人可以有随意法律兴讼的自由”。我是否可以认为，用户可以采取法律行动，但不可以告诉对方？我认为，用户声明已经或者将要采取法律途径解决问题，应当被允许；因为社群知道这一信息有助于当事人采取适当行动和社群共同解决问题，同时禁止这一行为有悖于法治的理念和社会共识。--落花有意12138 _{论回复请ping我} 2023年1月17日 (二) 13:30 (UTC)[回复]

不好意思，在本站而言最常發生的「訴諸法律」在我看來通常就是一種威脅，否則試問為何對他人要訴諸法律呢？還是有什麼要爭取的？至於不知道相關規範，自然也會獲得熱心用戶的警醒，這點倒不成大礙。至於告訴對方，「用户可以采取法律行动，但不可以告诉对方？」，您似乎沒看到可適當告知對方，惟須注意已先採行站內調處程序，並避免公開宣揚、脅迫；換言之若爭執兩造因故（不論因為線上或實體活動之事由）一個要告上法院，一個通報回社群，兩者皆存在、並不衝突，只是會鬧到因為這裡的事情訴諸法律，究竟何事呢？與其說「社群知道这一信息有助于当事人采取适当行动和社群共同解决问题」，請問為何不先以站內程序解決問題呢？而若因個人因素執意採取法律程序，請問「当事人采取适当行动和社群共同解决问题」所指為何呢？既已執意提告，如何行動呢？社群又能怎麼共同解決呢？請問這與“法律威胁”差異何在呢？不會有寒蟬效應嗎？若有明確事例，請舉例。

法律事件複雜之處在於事件樣態繁複且具衍生性，必須具體視情況討論。舉例而言，若雙方因站內宣布或公告舉辦的相關線下推廣活動於現實中見面發生糾紛，不論為了何事，一方提告另一方，站內亦根本無從實質從法律論斷是非，比如：有人因站外活動被對方打而提告，施暴一方反舉報回站內，主張自己被訴諸法律，管理員是否應該封鎖該名因遭到施暴而提告的用戶？若雙方因線下的實體推廣活動產生金錢糾紛而興訟，又舉報回站內，管理員是否封鎖該名訴諸法律的提告用戶？又或者雙方互相提告、互控性侵並通報站內，雙方皆指控對方對自己進行法律恫嚇，管理員是否應該同時封鎖兩名用戶？再或者兩位用戶於參與線下活動後，再轉往他處進行私下活動，算不算站內相關活動呢？此時若發生爭議產生法律糾紛是否應如何論處？甚至若爭執的用戶兩造先因平台推廣相關活動有債務關係在前（比如一方借貸予另一方舉辦線下實體活動），雙方合意以站內互助活動如何相抵，結果欠錢的一方未於站內履行約定，並且拒不認債、長期拖欠，而債權人因討債未果私下揚言提告，債務人反通報回站內，試問管理員該如何看待此事？上述事由之法律爭端可能造成社群各種困擾，亦已超出站務人員所應或所能負擔之範疇，難以論斷，因此下方段落的條文才言明「獲通報至站內，便可能構成管理員裁量是否以封鎖帳號等方式處理之理由。」，也就是管理員可自行裁量，未必直接封鎖帳號，相關使用者亦因此才有機會停止無建設性之不良互動，而平台和社群亦無法實質介入、協助或干預實體的法律程序，只是站內、外的平台直接相關活動若產生爭議未經站內機制適當調處便揚言或告知訴諸法律以要脅對方，並非此平台應允之事（這裡的所謂「法律威脅」通常指用戶間在站內、外活動中，因本站的相關內容和活動而揚言可能將訴諸法律的類型），基金會行動亦已主張此事了（也因此將使用者行為規範之效力延伸至線下相關活動、或運用規管為平台內容和活動範疇之用戶行為準則）。更何況如果單只是有人對頁面內容或什麼機制不滿意，動輒訴諸法律押著別人就範顯然不妥，而站內亦已提供適當處理機制，訴諸法律應為最後一步的個人選擇，就敝人的認知而言大致如此運作；實際上，若就條目內容或平台機制爭議而言，究竟有何需要告知訴諸法律呢？到底還有什麼真正和站內外活動相關結果弄到要告人的情形呢（最常見就公眾人物、演藝公司、私人業者的告知吧）？而敝人不太清楚您說的法治和社會共識所指為何，尤其各地域法律有別，還請明言，謝謝。--Kriz Ju（留言） 2023年1月17日 (二) 21:18 (UTC)[回复]

因此，敝人已於下方段落說明「使用者之間若因維基百科站內相關活動產生法律糾紛，並獲通報至站內，便可能構成管理員裁量是否以封鎖帳號等方式處理之理由。由於存在利益衝突，陷入法律糾紛的編輯者不應編輯與糾紛有關的條目，相關用戶亦應停止無建設性之不良互動。」；「由於各式法律爭議不一而足、樣態複雜，且身為志工之管理員通常實無必要或義務主動涉入其中，抑或心力或能力不足，加上此類爭端可能是非難論，此處建議賦予管理員較大之裁量空間。」；以及「爭端仍回歸相關當事人之實際溝通狀況，以及管理員若獲報後之實務判斷。」下方討論還煩請參閱，謝謝。--Kriz Ju（留言） 2023年1月17日 (二) 20:00 (UTC)[回复]

基於本地實際之各自諸種邏輯演繹等並非與參照語文體系之同一活動有一致之基礎傳統，本地化過程必須投入更多加以釐清和研判關聯之糾紛事態等多樣演繹，社羣及社區有需要考慮到本地語文圈與參照語文圈之明顯法理歷史背景差異，對於判讀本地日常實踐之宣誓解決行動個案等，適宜同時參考有關本地認知因素和系統偏好、鑑識對應之行為理念和認識，即需判明限於本地語文背景基礎因素下之、非普世價值背景因素下之律令性質威脅定義，而這一本地化過程如果有所滯後，個人認為是不足以支持該案達成應當達致之協助社區目標，也難以進一步討論所謂允許甚麼情況採取甚麼行動去怎麼保障社區成員之必要利益。--約克客（留言） 2023年1月19日 (四) 02:03 (UTC)[回复]

逐條討論

本章節對於特定條文進行深入討論，我已列出的都是與英文維基百科不同的，或是我不確定翻譯的，未列出則表示條文與英文維基百科一致，如果您覺得有其他條文需要討論，請按格式列出。為避免版面混亂，如果您認為條文都沒有問題，請不要對每一項都寫{{支持}}，請寫在前一個段落，這不是投票，請不要僅留下{{支持}}而不留下意見。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)[回复]

先改了報告地點與有償編輯的部份。--冥王歐西里斯（留言） 2023年1月10日 (二) 08:33 (UTC)[回复]

看起來逐條討論的部份都改得差不多了？應該可以進入公示流程了？--冥王歐西里斯（留言） 2023年2月9日 (四) 02:49 (UTC)[回复]

（方針名稱）「不要訴諸法律威脅」

「法律威脅」一詞直接翻譯自en:Legal threat，但曾有人建議翻譯成「不要威脅訴諸法律」，發動法律行動實際上會稱為「訴諸法律行動」，而該方針是禁止「威脅要訴諸法律行動」，故縮短為「威脅訴諸法律」，但該稱呼似乎會跟en:Appeal to the law混淆。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)[回复]

另建議動詞可以不要用訴諸，可改為「發布」、「張貼」等。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)[回复]

~~如果是這樣的話，不如改用張貼吧。--冥王歐西里斯（留言） 2022年12月1日 (四) 06:47 (UTC)~~[回复]

(＆)建議：頁面標題維持現狀。序言章節已有「不要在維基百科上發佈法律威脅」，訴諸法律威脅的意思是利用法律威脅途徑解決問題。 -- 月都 ※ 2022年12月3日 (六) 07:27 (UTC)[回复]

(！)意見：個人傾向維持原標題。--Kriz Ju（留言） 2022年12月5日 (一) 19:02 (UTC)[回复]

(！)意見：看了一下，還是維持原標題好了，改成發佈或張貼似乎反而怪怪的。--冥王歐西里斯（留言） 2022年12月14日 (三) 07:18 (UTC)[回复]

（簡而言之）

除直接翻譯外，加上「未被警告的情況下」及「維基百科已有相應的程序處理這些問題」兩句。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)[回复]

(＆)建議：保留「維基百科已有相應的程序處理這些問題」，這很好地解釋了為什麼不應動用法律手段。--Temp3600（留言） 2022年12月3日 (六) 18:23 (UTC)[回复]

(＋)支持：扼要地介紹了什麼不是法律威脅；就如設立方針的理由，首先應循爭議解決程序來解決問題，很多時候能避免訴諸法律來解決問題。 -- 月都 ※ 2022年12月3日 (六) 23:52 (UTC)[回复]

（導言第一行）法律威脅的定義: 加上「訴訟、舉報、告發」作為舉例。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)[回复]

（導言第一行）報告地點: 未翻譯「elsewhere to an administrator」，原本想說統一報告到管理員布告板。但考量到提報人可能被變為訴訟對象，是不是應該提供私下報告方式比較好？可補翻譯加入「管理員列表」及「管理員專用郵件清單 wikipedia-zh-admin」。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)[回复]

並列嗎？聽起來應該可以。--冥王歐西里斯（留言） 2022年12月1日 (四) 06:50 (UTC)[回复]

(＋)支持：提供相關通報管道更為完備。--Kriz Ju（留言） 2022年12月5日 (一) 19:54 (UTC)[回复]

（導言第三行）兩位使用者之間無論是在維基百科或其他地方有法律糾紛，只要沒有在維基百科上發布法律威脅，就不構成封鎖的理由。由於存在利益衝突，陷入法律糾紛的編輯者不應編輯與糾紛有關的條目。

(＆)建議：刪除上述條文。2021年維基媒體基金會行動，顯示了只要蒐集充足的證據，站外的法律威脅會遭到全域封鎖；不一定存在利益衝突，憤怒的時候也可以訴諸法律威脅。 -- 月都 ※ 2022年12月2日 (五) 16:05 (UTC)[回复]

(！)意見：建議異動為「使用者之間若因維基百科站內相關活動產生法律糾紛，並獲通報至站內，便可能構成管理員裁量是否以封鎖帳號等方式處理之理由。由於存在利益衝突，陷入法律糾紛的編輯者不應編輯與糾紛有關的條目，相關用戶亦應停止無建設性之不良互動。」由於各式法律爭議不一而足、樣態複雜，且身為志工之管理員通常實無必要或義務主動涉入其中，抑或心力或能力不足，加上此類爭端可能是非難論，此處建議賦予管理員較大之裁量空間。--Kriz Ju（留言） 2022年12月5日 (一) 19:54 (UTC)[回复]

已接受Kriz Ju的建議。--Xiplus#Talk 2023年1月16日 (一) 13:55 (UTC)[回复]

（導言第三行）「The only concern of this policy is the posting of legal threats on Wikipedia」未翻譯。: 暫未翻譯。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)[回复]

此方針僅關注在維基百科上張貼的威脅？可能還需要潤一下文字。--冥王歐西里斯（留言） 2022年12月1日 (四) 06:51 (UTC)[回复]

(！)意見：個人傾向不需翻譯。--Kriz Ju（留言） 2022年12月5日 (一) 20:03 (UTC)[回复]

這得看上面那條的討論結果，如果站外也納入的話，此條就不需要加入，但若維持僅關心站內的法律威脅的話，此條還是寫上為佳。--冥王歐西里斯（留言） 2022年12月6日 (二) 01:26 (UTC)[回复]

（什麼不是法律威脅 - 著作權）歡迎您告訴我們該使用方式是否符合授權: 不太確定「a clear statement about whether it is licensed for such use is welcome」的意思，暫時用我自己的話重寫。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)[回复]

完整的述明是If you are the owner of copyrighted material that has been inappropriately added to Wikipedia, a clear statement about whether it is licensed for such use is welcome. 本地化句段似乎也未有準確轉譯有關內容，這整段話是以聲稱持有版權者為輔助對象，通篇相信可表述為「假若您是某一被不適切地上載到維基站域內物件的版權持有人，歡迎清晰聲明是否許可上述用途」——這一點也是極大限制版權提起路線之適用對象，即無論社區或社羣並不適用為聲稱及行動對象。

另外以整體內容與WP:CIVIL、WP:HAR等相互銜接而言，加上延伸結合相關著作權判定專題及本地其他經驗，明顯不同於衡常司法環境之中文圈司法認知環境有諸多空間可能仍需本地化進程內嚴加關注及應對，認為該案適合進一步擴展研判中文圈語境或議題界線灰色化之下可能產生之獨特的法律威脅。--約克客（留言） 2023年1月17日 (二) 02:01 (UTC)[回复]

（什麼不是法律威脅 - 著作權）報告程序: Wikipedia:頁面存廢討論/疑似侵權放在首位，這是穩定執行的現有處理程序。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)[回复]

（什麼不是法律威脅 - 有償編輯）「laws against undisclosed advertising」未翻譯: 不太清楚那是什麼，暫未翻譯。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)[回复]

WP:NOHIDDENADS吧，所以是指提醒對方關於不得張貼祕密廣告的這件事並不構成法律威脅。--冥王歐西里斯（留言） 2022年12月6日 (二) 07:52 (UTC)[回复]

（什麼不是法律威脅）擬增訂Wikipedia:生者傳記: 有些請求可能涉及隱私或任何生者傳記規定事項，這些請求可能同時涉及法律威脅，但如果符合Wikipedia:生者傳記規定應移除內容，應優先接受請求，而非指控其法律威脅，以免事態升級。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)[回复]

已加上Wikipedia:不要訴諸法律威脅#生者傳記。--Xiplus#Talk 2023年1月16日 (一) 14:24 (UTC)[回复]

（察覺法律威脅）標題

原文為「Perceived 感知、察覺」，暫用察覺一詞。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)[回复]

Perceived threat与real threat相对，指一方无控告的目的，而其措辞使另一方感觉受到了法律威胁。-Mys_721tx（留言） 2022年12月5日 (一) 20:06 (UTC)[回复]

重命名為「理解法律威脅」，該章節是用來說明如何判斷一段留言是否屬於法律威脅。--Xiplus#Talk 2023年1月16日 (一) 14:11 (UTC)[回复]

（察覺法律威脅）法律威脅的範例

考量到本案當事人和其他新人不熟悉該方針，參考了Wikipedia:条目所有权#所有权的行为示例和Wikipedia:不要人身攻击#例子都有相關的舉例，給出範例能讓所有人更容易理解界線在哪裡，故目前給出很多範例。但我有在考慮方針是否真的適合收錄範例列表，獨立成一頁作為{{輔助說明}}可能更為合適。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)[回复]

搬到輔助說明頁吧，這樣也比較好增修。--冥王歐西里斯（留言） 2022年12月1日 (四) 06:54 (UTC)[回复]

建議獨立成WP:NLT的子頁面。--冥王歐西里斯（留言） 2022年12月6日 (二) 07:53 (UTC)[回复]

(＆)建議：刪除整個章節的條文；任何人都可以不理會法律威脅，並且報告至Wikipedia:管理员布告板/其他不当行为。不必跟隨英語維基百科的版本，片面字句或指控性詞彙常被過於演繹，存在出於善意的可能性，因此嘗試給他人解釋的機會。 -- 月都 ※ 2022年12月5日 (一) 07:35 (UTC)[回复]

(！)意見：支持建立輔助說明頁和月都君條文，另建議條文微調為「任何用戶對於法律威脅皆可報告至Wikipedia:管理员布告板/其他不当行为等適當的協助管道。」--Kriz Ju（留言） 2022年12月5日 (一) 20:18 (UTC)[回复]

範例已拆分到Wikipedia:如何處理法律威脅，該頁面亦可讓管理員補充處理的技巧；該章節重命名為「理解法律威脅」，該章節是用來說明如何判斷一段留言是否屬於法律威脅，而非察覺及如何處理，該段文字已列在首段，故未被接受。--Xiplus#Talk 2023年1月16日 (一) 14:10 (UTC)[回复]

（察覺法律威脅）英文方針原本的舉例「if you repeatedly assert that another editor's comments are "defamatory" or "libelous"」未翻譯

續前，建議留下一個範例即可，但這兩個詞彙似乎都是誹謗，不知道怎麼翻譯，或許可以直接另外寫一個合適的範例。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)[回复]

美国法律上libel和slander是defamation的子集，libel是书面出版的，slander是口头的。-Mys_721tx（留言） 2022年12月5日 (一) 20:16 (UTC)[回复]

(！)意見：個人認為條文可譯為「如果您持續斷言其他編輯的評論是各種誹謗或中傷。」--Kriz Ju（留言） 2022年12月19日 (一) 20:27 (UTC)[回复]

（設立方針的理由）這會造成寒蟬效應: 原本寒蟬效應是連結，但我覺得直接寫出來該詞彙有助於理解。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)[回复]

（設立方針的理由）衝突中的一方就有可能威脅並排斥另一方: 原文「we risk one side of a dispute intimidating the other」，不確定翻譯是否正確。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)[回复]

大約是指有能力作出法律威脅的一方可以脅迫另一方閉嘴，從而破壞條目的自由編輯制度，導致systemic bias云云。--Temp3600（留言） 2022年12月5日 (一) 14:06 (UTC)[回复]

(！)意見：個人認為條文可譯為「社群恐將產生任由爭端出現恫嚇脅迫等行為的風險」--Kriz Ju（留言） 2022年12月19日 (一) 20:40 (UTC)[回复]

已接受Kriz Ju的建議。--Xiplus#Talk 2023年1月16日 (一) 13:55 (UTC)[回复]

（設立方針的理由）社群與曾做出法律威脅的使用者會留下糟糕的經歷

原文「The project has had bad experiences with users who have posted legal threats in the past」，不太確定是指在（英文維基百科）以前曾發生糟糕的經歷，還是指一旦進行了法律威脅，日後社群在與該位編者協作時會想起這段糟糕的經歷。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)[回复]

~~(＆)建議：刪除上述條文，保障維基媒體基礎設施或用戶的安全。較為清楚地說明為甚麼不要訴諸法律威脅。~~ -- 月都 ※ 2022年12月2日 (五) 16:05 (UTC)[回复]

(▲)對於保留上述條文改為中立的態度，雖然bad一詞比較含糊。 -- 月都 ※ 2022年12月5日 (一) 07:35 (UTC)[回复]

（設立方針的理由）只有在您已經嘗試了所有您知道的合理步驟來友善地解決問題，但爭議解決程序仍不能解決您的問題時，您才可以選擇採取法律行動。

原文「If the dispute resolution procedures do not resolve your problem, and you then choose to take legal action, you do so in the knowledge that you took all reasonable steps to resolve the situation amicably.」，不確定翻譯是否正確。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)[回复]

(！)意見：個人認為條文可譯為「請您在選擇採取法律行動之前，確認已經嘗試所有可能的合理步驟友善解決問題，而相關的爭端調解程序卻仍未解決您的問題。」--Kriz Ju（留言） 2022年12月19日 (一) 20:54 (UTC)[回复]

已接受Kriz Ju的建議。--Xiplus#Talk 2023年1月16日 (一) 13:55 (UTC)[回复]

（法律威脅的結論）防止在尋求他人協助後，又將對方變為法律上的對造。: 原文「prevents a situation in which someone seeks to be a collaborative partner, while posting as if they were a legal adversary.」，實際上看了很久都無法理解這句話的意思，更舊的原文是「It prevents the difficult situation where a person is both seeking to be collaborative partner and also setting themselves up as litigatious adversary (in general those two roles are mutually exclusive).」，相關的討論請參見這裡。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)[回复]

這段話應該是闡述一種雙重標準定位的參與語境，舊文可能更好體現到旨在防範之風險問題，difficult、setting up和exclusive等是有更一步述明一定隱含之訴諸特徵，考慮結合精煉含義及原意，個人認為結論之闡述為「旨在避免出現以下某類參與者存在之複雜情況，即在社區過程內同時表現出兩種截然矛盾身份且不能調和之參與者，其一方面看似尋求與其他參與者通盤合作之，但另一方面看似尋求合作同時在訴諸對方為官司追查對象之代理顧問」。--約克客（留言） 2022年12月1日 (四) 09:14 (UTC)[回复]

簡單而言原提煉句基礎上也可能可以再簡練點，前設是閱覽時意識到其表述一種可能處於司法語境裡更顯矛盾之兩種身份——collaborative partner和litigatious adversary，好比合作證人和檢控方，即同一語境裡一方同時具有兩種角色表徵時即已存疑。--約克客（留言） 2022年12月1日 (四) 09:38 (UTC)[回复]

認同。維基人本應團結互助，善意假定，故是被此的 collaborative partner，但如果可能彼此是法律上的對造方，則合作時決不能真心誠意，此一身份矛盾即是維基人間不應以法律手段解決問題的原因。--Temp3600（留言） 2022年12月5日 (一) 10:20 (UTC)[回复]

（法律威脅的結論）在使用者討論頁上反覆進行法律威脅所能造成的擾亂及寒蟬效應範圍有限，除非已經合理嘗試發起文明的討論，否則不應禁止編輯他們的討論頁。

但在本案中的當事人實際上很快地（而不是多次提出申訴）被禁止討論頁及電子郵件，我個人不太認為本案（在被封討論頁當下）有達到非常嚴重的情況，如果本地社群決定更嚴厲執行該方針，或是給予管理員更靈活判斷的權力，應刪除本條。但其實本條是保障當事人申訴權利，及避免事態升級。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)[回复]

(＆)建議：删除上述条文，于当前社群实践不符。--Fox6667（留言） 2022年12月4日 (日) 08:38 (UTC)[回复]

(＆)建議：刪除上述條文，在使用者討論頁上反覆進行法律威脅所能造成的擾亂及寒蟬效應範圍有限；如社群已經不可能阻止法律威脅的問題，或提供充分解釋後執意做出訴諸法律威脅的行為，則應禁止使用者編輯自己的討論頁面。有些時候找到代替的方法，意識到法律威脅的缺點，就不會重蹈覆轍，未來是一位建設維基百科的參與者；現實世界裏沒有採取或已完成法律行動或政府程序，參與者放棄追究相關責任，應該獲得解除封鎖的機會。 -- 月都 ※ 2022年12月5日 (一) 07:35 (UTC)[回复]

(！)意見：建議微調上述條文為「由於在使用者討論頁上反覆進行法律威脅所能造成的擾亂及寒蟬效應範圍有限，社群應考慮發起適當討論，否則不應未經警醒便禁止編輯他們的討論頁。在社群對相關用戶進行善意溝通後，管理人員可依事態發展適當裁處。」--Kriz Ju（留言） 2022年12月5日 (一) 20:51 (UTC)[回复]

已接受Kriz Ju的建議並微調。--Xiplus#Talk 2023年1月16日 (一) 13:55 (UTC)[回复]

續前，電子郵件是否構成法律威脅

翻譯前的原先文字有「如果您決定要訴諸法律行動，請與相關用戶以電郵聯絡，不要把問題放在維基論壇或討論頁。」，而且該方針的規範範圍似乎僅及於公開的地方（可從用戶討論頁就視為不夠公開而給予特別寬容看出），故電子郵件應該不包含在內，但本案中當事人實際上已被禁止電子郵件，另法律威脅已被定義為Wikipedia:騷擾#恐嚇和Wikipedia:不要人身攻击#例子的一種類型，而這兩項規範範圍理應包含電子郵件，因此有矛盾之處。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)[回复]

(＆)建議：应当认为是法律威胁，因有其他方针如此规定。--Fox6667（留言） 2022年12月3日 (六) 18:10 (UTC)[回复]

(！)意見：構成的要件是讓人害怕受到法律行動或政府程序的影響；如使用Wikipedia的電郵聯絡此用戶功能進行法律威脅，或許需要實施封鎖。 -- 月都 ※ 2022年12月3日 (六) 23:52 (UTC)[回复]

私下威脅不見得比公開威脅好。--Temp3600（留言） 2022年12月5日 (一) 10:22 (UTC)[回复]

(！)意見：建議微調上述條文為「如果您決定要訴諸法律行動，建議您適當知會相關用戶，避免持續透過維基論壇或討論頁等平台相關頁面擴大爭端。」其實既已決定訴諸法律，透過何種途徑、管道或形式聯繫，似已非是否構成威脅恫嚇之關鍵；若前面已有「使用者之間若因維基百科站內相關活動產生法律糾紛，並獲通報至站內，便可能構成管理員裁量是否以封鎖帳號等方式處理之理由。」之條文，爭端仍回歸相關當事人之實際溝通狀況，以及管理員若獲報後之實務判斷。換言之，若相關用戶選擇不通報或已私下協調，則亦無訴諸何種媒介應如何處置的問題。--Kriz Ju（留言） 2022年12月5日 (一) 21:34 (UTC)[回复]

(？)疑問所謂私下之法律或他種活動云云，依據過往個案經驗等而言，似乎亦無法避免站域內定義Perceived threat或real threat之可能性，歸結其所隱含之尺度是一個非常需要關聯專業協作之課題，故而可能有必要另行展開專版及適當程序訂立處理，不能全由參與維基計劃之用戶自行承擔被訴諸之風險。--約克客（留言） 2022年12月6日 (二) 02:51 (UTC)[回复]

您是把legal

wikimedia.org當作擺設嗎？--路西法人 2022年12月6日 (二) 03:43 (UTC)[回复]

(！)意見：這項相關規範主要只能用來約束真正有心參與的社群用戶和違規用戶而已（或許類似會員制），理想上希望盡可能提供能讓用戶安心編輯的環境，或至少在發生此類狀況時能有基本應對措施；然而對於站外各種形式的施壓，或是遇到有心人特地來「算帳」或爭執的情況，也僅能加以應對或取得對方理解而已，要是對方根本不參與站內活動，站內也無能為力吧（若涉及法律協助則已超出此規範原意）。因此只能提供各種管道讓用戶適當求助，只有先具備讓人安心、安全發聲反映的管道和規範基礎才有協助的空間。--Kriz Ju（留言） 2022年12月15日 (四) 17:06 (UTC)[回复]

（法律威脅的結論）假定善意不是自殺協議

我其實不懂suicide pact的意思。--Xiplus#Talk 2022年11月30日 (三) 14:48 (UTC)[回复]

按照en:Wikipedia:Our social policies are not a suicide pact，是WP:IAR。在用户页面散发法律威胁因为影响范围较小不会被立即禁止编辑讨论页面，但是持续此类行为会禁止编辑讨论页。-Mys_721tx（留言） 2022年11月30日 (三) 16:10 (UTC)[回复]

(＆)建議：在阻止破壞的同時也應該假定善意，但假定善意不是自殺協議（英语：Wikipedia:Our social policies are not a suicide pact），持續或無理取鬧的申訴將導致使用者被禁止編輯他們的討論頁。條文與法律威脅無關。 -- 月都 ※ 2022年12月2日 (五) 16:05 (UTC)[回复]

不是很看得明白「自杀协议」以及上边两位的解释。--Ghren 🐦🕓 2022年12月3日 (六) 09:52 (UTC)[回复]

淺紅色標示的是提議刪除條文，理由是僅限於假定善意和解除封鎖的範疇，未能解釋與法律威脅的關係；而且法律威脅的結論章節第一段，提到以原諒的態度對待放棄訴諸法律威脅者。 -- 月都 ※ 2022年12月3日 (六) 11:45 (UTC)[回复]

en:The Constitution is not a suicide pact:The phrase expresses the belief that constitutional restrictions on governmental power must be balanced against the need for survival of the state and its people. 大約是指規則設計出來並不是為了要弄死所有人的意思？「及陷於罪，然後從而刑之，是罔民也。」--Temp3600（留言） 2022年12月5日 (一) 13:59 (UTC)[回复]

(！)意見：支持刪去「在阻止破壞的同時也應該假定善意，但假定善意不是自殺協議（英语：Wikipedia:Our social policies are not a suicide pact）」，但保留「，持續或無理取鬧的申訴將導致使用者編輯他們的討論頁。」；合併前面條文則為：「由於在使用者討論頁上反覆進行法律威脅所能造成的擾亂及寒蟬效應範圍有限，社群應考慮發起適當討論，否則不應未經警醒便禁止編輯他們的討論頁。在社群對相關用戶進行善意溝通後，管理人員可依事態發展適當裁處，持續或無理取鬧的不當申訴將導致使用者被禁止編輯他們的討論頁。」。個人意見，供參。--Kriz Ju（留言） 2022年12月5日 (一) 21:53 (UTC)[回复]

已接受Kriz Ju的建議。--Xiplus#Talk 2023年1月16日 (一) 13:55 (UTC)[回复]

公示不要訴諸法律威脅

基於上面已經過充分的討論，現公示Wikipedia:不要訴諸法律威脅的目前版本，針對部分異議，統一回應如下：

眾多舉例已移出方針：管理員應綜合考量具體內容及發佈次數，不應透過單一句子判斷是否構成法律威脅。
電子郵件及是否可以通知要興訟的問題：由於電子郵件只有傳送的雙方可見，且設有拒接電子郵件的功能，並考量本方針的要旨在於防止法律威脅對社群第三方的影響及以法律威脅代替討論，一律規定電子郵件「可以」或「不行」皆不恰當，應個別考量具體案例，故暫未明確寫入方針，但在方針首段讓管理員自由裁量。
初犯警告問題：是否進行警告已在Wikipedia:封禁方针#教育用戶所規定，管理員應根據具體情況判斷是否可以未經警告封鎖，另Wikipedia:不要訴諸法律威脅#法律威脅的結論也規定若當事人已理解規定且願意撤回發言，就可解除封鎖。

公示14日，2023年3月9日 (四) 13:01 (UTC) 結束。--Xiplus#Talk 2023年2月23日 (四) 13:01 (UTC)[回复]

更新对法律方针的描述

現行條文

以下方針有法律上的後果。除這些方針外，基金會行動方針、維基百科不會審查內容也有法律上的意義。留意只要內容符合美國法律，維基不會對內容拖加限制。如想向維基百科提出法律投訴，可向維基媒體基金會提出正式投訴

提議條文
Mys 721tx

以下方针有法律后果。除下列方针和基金会行动方针外，只要维基百科上的内容符合美国法律，维基百科不会对自身可能令人反感的内容进行审查，或采纳其他管辖内容的法律提案。法律问题需通过维基媒体基金会正式提出。

月都

以下方針有法律後果。除下列方針和基金會行動方針外，只要維基百科内容符合美國法律，維基百科不會對自身可能令人反感的内容進行審查，或受其他管轄內容的法律提案約束。有關維基百科的法律問題，請參考爭議解決指引以及請不要訴諸法律威脅。

Kriz Ju

以下方針有法律後果。除下列方針和基金會行動方針外，只要維基百科上的内容符合美國法律，維基百科不會對自身可能令人反感的内容進行審查，或使其受其他內容約束或審查相關法律囿限。關於維基百科的法律問題，可參考爭議解決指引、請不要訴諸法律威脅；如想對維基百科提出法律投訴，請向維基媒體基金會正式提出。

顺手重新翻译了一下法律方针的描述。-Mys_721tx（留言） 2022年11月21日 (一) 05:50 (UTC)[回复]

(＋)支持：社群对不得进行法律威胁之条文虽现无明确列入其中，但已在实践过程中受到普遍性的承认。诸如WMC事件、修订傀儡方针涉及法胁内容以及诸管理员在封禁案例上也有体现。现在明文加入其中，显然是适当的。——2022年11月22日 (二) 15:37 (UTC)--以上未簽名的留言由維基百科最忠誠的反對者（討論｜貢獻）加入。

(！)意見：雖然法律與判刑存在密切關係，但法官或律師意見可能有助於改進維基百科，且不一定被社群採納。通常接受理性討論；通常不接受法律威脅，即針對個人、團體或組織。 -- 月都 ※ 2022年12月3日 (六) 07:12 (UTC)[回复]

(▲)鼓勵採用站內的爭議解決程序；不鼓勵以法律作為武器，強迫別人支持非方針或使用條款的法律觀點。 -- 月都 ※ 2022年12月5日 (一) 08:06 (UTC)[回复]

(＋)支持相關修訂，個人微微彙整上方兩位站友版本。--Kriz Ju（留言） 2022年12月5日 (一) 22:21 (UTC)[回复]

(＋)支持Kriz Ju的版本。--冥王歐西里斯（留言） 2022年12月6日 (二) 07:58 (UTC)[回复]

@Mys 721tx：應該可以使用Kriz Ju的版本修改了？--冥王歐西里斯（留言） 2023年3月2日 (四) 06:49 (UTC)[回复]

完成--Mys_721tx（留言） 2023年3月2日 (四) 07:07 (UTC)[回复]

本討論章節會維持開放，暫時不按最後意見發表時間存檔。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

關注度指引改名事宜

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:关注度。

為整合有關主題的討論，本討論已移動至Wikipedia:集中討論/關注度指引改名事宜 § 第一階段討論區進行集中討論。請至有關頁面發表意見。

執行人：路西法人 2023年1月20日 (五) 08:10 (UTC)[回复]

本討論章節會維持開放，暫時不按最後意見發表時間存檔，直至集中討論結束。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

圖註的結尾的句號

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:格式手册/标点符号。

現行MOS:句號指出，「图片和圖表的描述……末尾不用句号。就算有时说明文字内容比较长，在前面的语段中已用句号，最后的结尾处仍不用句号。」

格式手冊的例子「维基娘是维基百科萌拟人化后的美少女角色。由日本维基百科人创作」我認爲不太好，「美少女角色」後應該用逗號。試另舉一組例子：

维基百科标志
维基娘是维基百科萌拟人化后的美少女角色
维基娘是维基百科萌拟人化后的美少女角色。其雖非官方吉祥物，但已被官方和社群用於各類活動中。

第一張圖的圖註一般按短語理解，結尾不用句號爲宜。第二張圖的圖註可以構成句子，但是當短語處理亦可；結尾句號可加可不加。第三張圖的圖註顯然是兩個句子，尾句不加句號我是感覺到彆扭。

「視作短語的圖註結尾不加句號，視作句子/语段的圖註結尾加句號」可能更合適。但這樣的結果是，一眼看上去圖註結尾句號時有時無，表面上不夠統一。各位怎樣看？--洛普利寧 2023年1月22日 (日) 05:16 (UTC)[回复]

認同Lopullinen閣下的說法，短語不用句號，句子應用句號。(※)注意句2先前版本是「存在于图表中的短语式说明文字，其中部内容可用逗号，但末尾不用句号。就算是有些时候说明文字内容比较长，在前面的语段中已出现句号，最后的结尾处仍不用句号。」（粗體為後加）在下理解後句「说明文字内容⋯⋯最后的结尾处仍不用句号」仍僅適用於前句提到的短語式說明文字，不包括句子。Special:Diff/74616458中捍粵者閣下將「存在于图表中的短语式说明文字」修改成「图片和圖表的描述」使該段落變成適用於句子，但似乎沒有相關共識，應恢復成先前版本。另外Wikipedia_talk:格式手册/标点符号/存档3#新建一个去除图片介绍末尾标点符号的机器人曾討論是否應加句號。——

\color [rgb]{0.04,0,0.5}{\mathsf {htc_{23}}}

（留言） 2023年1月22日 (日) 12:49 (UTC)[回复]

收到！--－－勿用「進行」污染中文，要言簡意賅。　捍粵者 2023年1月22日 (日) 16:43 (UTC)[回复]

(＋)贊成“文字中已有句號或分號的語段應有恰當的標點收尾”。--Gohan 2023年1月23日 (一) 00:38 (UTC)[回复]

(＋)贊成。另外这方面的内容似乎移至MOS:CAP叙述更合适。--PexEric 💬|📝 2023年1月24日 (二) 06:37 (UTC)[回复]

(＝)中立：結尾是否要放上句點那是習慣問題，畢竟條目是應該寫給讀者看而不是自己看的。既然條目內容都是這樣了，那圖片當然也是這樣，不應一竿子改變這種習慣。就好比如：<ref></ref>標籤，請問您要放在句點前還是句點後？其實都行，因為是習慣問題。--Z7504非常建議必要時多關注評選（留言） 2023年1月30日 (一) 19:29 (UTC)[回复]

(＝)中立，习惯问题。个人偏好不加句号，主要我觉得图片下面的字无论是短语还是句子，放在文字旁都是补充内容，就好比是文本中括号内的内容。--Eve sie sta_{🇩🇪❤️🇺🇦} 2023年2月5日 (日) 09:39 (UTC)[回复]

@Evesiesta：一个句子不加句号没有问题，毕竟去掉句号就是短语。关键是复数句子只有最后一句不加句号。就算是文本中的括号内容，里面如果有多个句子，最后一个句子不以标点收束还是很奇怪。--洛普利寧 2023年2月6日 (一) 14:41 (UTC)[回复]

(？)疑問：為什麼要在圖片的說明文字區域裡面寫落落長的文章，導致需要討論文章結尾要不要用句號？--Anghualee（留言） 2023年2月8日 (三) 17:02 (UTC)[回复]

@Anghualee：不一定构成文章，但有时一句话不够用。以此条目正文图片为例。第一句话描述图片本身内容，第二句话呼应正文「長槍剋劍，劍剋斧，斧剋長槍」（WP:NFCC#8，版权图片应有助正文理解）。这用一句话可能不好表述。--洛普利寧 2023年2月9日 (四) 14:09 (UTC)[回复]

也就是說因為除了"遊戲的戰鬥畫面"這幾個字以外的正文需要圖片來達成你所謂的WP:NFCC#8，結果把正文放到圖片說明文字區域裡面。所以我問啊，你到底是為了有助正文理解加圖片（正文擺在正文，圖片擺在圖片，圖片底下說明文字寫"遊戲的戰鬥畫面"），還是加了圖片後為了理解寫了落落長的文章解釋圖片（正文刪掉，圖片擺上去以後，把落落長的正文塞進去）。很明顯前面是你所謂的WP:NFCC#8，後面不是。--Anghualee（留言） 2023年2月9日 (四) 23:51 (UTC)[回复]

再來我們講圖片理解這件事情，請問一下那張圖哪邊看出槍剋制劍？你當然會說名字左邊是武器，在有武器剋制的情況下，武器右下角有箭頭，箭頭代表了武器的剋制。Ok，拜託不要把上面那段加到已經落落長的說明文字裡面了。我問啊，為什麼不在圖片上面的武器畫一個圈，加一條線拉出去到旁邊，寫"武器圖示：劍"，在箭頭上面畫一個圈，加一條線拉出去到旁邊，寫"武器克制示意"，這樣圖片裡面指示清楚了，這個是劍，這個是箭頭。然後圖片說明文字就打武器克制示意圖（槍剋劍），不就好了？我為什麼需要知道右邊是羅伊啊？圖片右上角沒有嗎？--Anghualee（留言） 2023年2月10日 (五) 00:12 (UTC)[回复]

首先这是张游戏截图是版权图片。自行在上面加圆圈箭头修改是不合适的，换用盗版汉化版截图也是不合适的。而且这里是中文维基百科，应当假定读者只会中文。所以读者当然不知道「ロイ」是罗伊。

其次NFCC限制版权图片数量，而游戏条目一般只能放一张截图。配图的机会珍贵，所以应该选一张具有代表性的图片。如果只是为了展示战斗画面，那完全可以传上传一张枪对枪不互克的截图。既然选了一张存在武器互克的截图来展示，当然应该用文字描述细节，让读者看懂你想表达的内容。（要不您不看图片描述和相关条目，猜一下这张图片想说什么？）

最后你问图片第二句话为什么不放到正文。因为这句话就是描述这张图片的，而不是正文的一部分（对正文太过琐碎）。如果条目不放图片，或者换成对话界面的截图，这句话自然不会出现。--洛普利寧 2023年2月10日 (五) 04:56 (UTC)[回复]

著作權我本來是不想討論的，因為那個是另外一個問題。畢竟圖片來源是 http://www.hardcoregaming101.net/，你確定該網站有"擁有使用CC-BY-SA協定釋放該內容的授權／是該內容的原始作者"其中一種嗎？再來你提到 NFCC，NFCC十點是必須全部符合的，第十點的 abc 都齊備了嗎？

其次如果覺得圖像版權是你很關注的問題，可以完全採用 Mock 的方式從白紙開始，框出各個區域以文字描述這是狀態欄，除非你能主張連遊戲畫面中的區塊分佈都具備著作權，否則 NFCC 第一點應該有跟你說如果可以用自由材料加以替代。

我前面就說過了，除了"遊戲的戰鬥畫面"這幾個字以外，不是該丟到正文，就是瑣碎資訊。所以你拿這是中文維基百科云云，我是真的覺得，那你怎麼不把 DMG、Rapier 都解釋了咧。如果這些可以不用因為這裡是中文維基百科而提供相應的中文說明，那羅伊就不用。就我的認知而言，圖片的說明文字放"遊戲的戰鬥畫面"就好了。

至於你列出來的"這張圖片"，以我來講這像是一個勇者鬥惡龍類型的戰鬥畫面，就我認知上來說跟非遊戲玩家的一般人展示時（如果有人還記得我們應該要這樣做的話），圖片的說明文字放"戰鬥畫面"就好，我不會去介紹說這是什麼怪物、為什麼隊伍是三個人、PP是什麼、接下來戰鬥可能會有畫面抖動（或許吧）。

我也不喜歡拿英文維基百科舉例，畢竟這邊是中文維基百科。不過你要不要想看看為啥英語維基百科就是一句"A battle between two units in The Binding Blade."就解決了？--Anghualee（留言） 2023年2月14日 (二) 02:54 (UTC)[回复]

圖片來源是http://www.hardcoregaming101.net/沒有問題。遊戲截圖可以上傳者自己截，也可以別人（比如hardcoregaming101.net）截好我直接上傳。很顯然這張圖片不是以「CC-BY-SA」協議授權的（否則會傳到c站而不是這裏）。然後看NFCC#10：a) 圖像說明頁已經表明版權屬於Intelligent Systems和Nintendo；b) 版權標籤是{{Non-free game screenshot}}，文檔說明頁已經放置；c) 哪篇条目使用这张图片需要指明，这点文档也清楚地链接了火焰之紋章封印之劍条目。

我想說明由於版權問題，遊戲截圖只能使用一張，而不能像Wikia通过大量图片来总结归纳。所以我需要通过文字發揮圖片最大的效用。正文沒說DMG所以我圖片沒解釋DMG，正文沒說Rapier所以我只說成劍而非刺劍，正文有說羅伊所以我圖片有說羅伊，正文有說伯爾尼所以我有說伯爾尼兵，正文強調武器互克所以我專門才用一句話來輔助說明。另外正文不是我寫的，圖片也不是我傳的。我只是根據正文的介紹，幫助圖片發揮更大的作用。我认为图片的一个核心价值是表现了枪克剑；而在陈述清楚这点的基础上，文字当然短一些比较好。如果读者都懂日文，那图注确实可以压缩成一句话；但这里是中文维基百科，読者は日本語がわかりません，我只能用多一些的文字说明左边的角色拿枪、右边的角色持剑。当然，确实我语文能力有限，没有想到更短的介绍文字。

關於英維的圖片用途您猜的對，就是爲了說明勇者鬥惡龍類型的戰鬥畫面。這個討論我注意到了一點，您懂的東西太多了。比如「ロイ」您假設讀者是會讀的，所以認爲標註羅伊多餘。這張圖片您也能猜到上傳者的意思，您可能認爲英維圖註第二句話也多餘。但是對於沒玩過勇者鬥惡龍的讀者，他們不會立刻往這方面想。能用文字說明白的東西，就不要让讀者去猜謎。而且就像您說的，說不定人家還猜你就想強調「DQ是4人隊伍、Mother是3人隊伍」。

英文維基百科只写「A battle between two units in The Binding Blade」的做法我認爲不夠好，没有完全发挥图片的价值。而且中文版圖片原來也只有這樣的描述，第二句是我加的。而且图片还应该有替代文字，英文版懒得写，中文版也懒得写。当然，这是通病。

最後回到正題。如en:Mother_(video_game)#Gameplay所見，有复数句话的图注释确实是存在的。--洛普利寧 2023年2月14日 (二) 14:25 (UTC)[回复]

@Anghualee：另外和您相反，我倾向再用一句话表明我传图片的目的，并尽可能和正文呼应起来。比如最近的火焰之紋章 Engage我就没传任何截图，因为我想传一个同时表现纹章士和Break的战斗截图，但没找到合适的图片；而信息框的图注可以和正文「遊戲視覺形象圖以琉爾為中心繪製」相呼应。其他游戏条目参选优良时，我也提过图注太简单的意见。如果您有想法，欢迎到PJT:VG讨论；毕竟现在关注图注编写的人还是很少的。当然，图注写法对本讨论来说就是离题了。--洛普利寧 2023年2月14日 (二) 14:49 (UTC)[回复]

關於"英維圖註第二句話也多餘"這件事情我簡單講一下，他是兩張圖片用一個圖片描述的方式描述，固定句型就是"左圖為XXX，右圖為XXX。圖片描述"（當然也可以右圖為XXX，左圖為XXX。左右先後看撰者習慣，至少我沒特別學過有對左右先後的相關規範）。就這樣。--Anghualee（留言） 2023年3月1日 (三) 13:11 (UTC)[回复]

这里有一篇文章对这个问题做了解释，供各位参考。--InstantNull（留言） 2023年2月9日 (四) 18:51 (UTC)[回复]

@Lopullinen：似乎有初步共識，可以考慮繼續推進。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年2月24日 (五) 01:52 (UTC)[回复]

提议限制在维基百科使用ChatGPT及类似工具

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:機械人方針、Wikipedia talk:翻譯指引。

最近几个月爆火的ChatGPT可以按照人类的提示生成文本，并且能根据人类的意见进行修改。但其生成的文本常常似是而非，看上去没有问题而实际上却含有事实错误，因此如果在条目中大量使用，可能会具有非常恶劣的影响。

StackOverflow已经禁止使用ChatGPT生成的内容，因此，中文维基百科社群是否应该跟进？

可行的方案：

完全禁止使用ChatGPT生成的内容编写条目；
ChatGPT生成的内容须经过人工审阅确认无问题之后才允许出现在条目中。

连接号一字线的符号选择

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:格式手册/标点符号。

提议：当前MOS:连接号一字线的符号选择"U+FF0D － FULLWIDTH HYPHEN-MINUS"不是通行的做法。改用 U+2014 — EM DASH 是更好的选择。

之前已经有多次讨论，大部分编辑表示支持，但都没有继续推进：

总结起来：

U+FF0D － FULLWIDTH HYPHEN-MINUS是短横线 U+002D - HYPHEN-MINUS的全形版本，二者应该表达相同的含义，不应重复使用。既然短横线已经选择了 U+002D - ，一字线就应该选用其他字符。
使用 em dash 对字体渲染有更好的支持。
使用 em dash 作为连接号是中文印刷品中的主流选择。
全角连字符U+FF0D －从未被广泛使用过。（除了中文维基百科）
多数中文字体对全角连字符的支持并不理想。
一字线应当恰好占据一个字符（即一个 em 长度）。
一字线应当恰好是破折号的一半。

因此建议推荐使用 U+2014 — EM DASH 作为一字线的符号，不再把 U+FF0D － FULLWIDTH HYPHEN-MINUS 作为推荐的符号，但也并不将其列为错误用法。

現行條文

连接号是用作标示某些相关联成分之间的连接。连接号的形式可分为：短横线“-”（U+002D）和一字线“－”（U+FF0D）。中华人民共和国国家标准及中華民國教育部標準中浪纹线“～”可与一字线通用，但在维基百科中不建议采用浪纹线。如果输入一字线不方便，可用{{一字线}}（{{连接号}}）。

连1：短横线用在：

化合物名称，如：β-巯基乙醇、β-羟-β-甲戊二酸单酰辅酶A。
连接号码，如：ISBN 978-0-12-155089-9 。
表示年月日，如：2012-12-21。
连接复合名词，如：南極-艾托肯盆地、比尔-朗伯定律。
产品的名称和型号，如：IA-64处理器。
汉语拼音、外来语内部的分合，如：玛丽亚·斯克沃多夫斯卡-居里。

连2：一字线可用在：

1. 相关项目的起止。

正确：法兰克福－巴黎
错误：法兰克福——巴黎、法兰克福—巴黎、法兰克福-巴黎

2. 数值范围。在不引起歧义的情况下，可省略前一数值的单位或附加符号，如：

1000－2000年、1－5千克。

提議條文

连接号是用作标示某些相关联成分之间的连接。连接号的形式可分为：短横线“-”（U+002D）和一字线“—”（U+2014）。浪纹线“～”可与一字线通用，但在维基百科中不建议采用浪纹线。一字线的输入方法与破折号类似。如果输入一字线不方便，可用{{一字线}}（{{连接号}}）。

连1：短横线用在：

化合物名称，如：β-巯基乙醇、β-羟-β-甲戊二酸单酰辅酶A。
连接号码，如：ISBN 978-0-12-155089-9 。
表示年月日，如：2012-12-21。
连接复合名词，如：南極-艾托肯盆地、比尔-朗伯定律。
产品的名称和型号，如：IA-64处理器。
汉语拼音、外来语内部的分合，如：玛丽亚·斯克沃多夫斯卡-居里。

连2：一字线可用在：

1. 相关项目的起止。

正确：法兰克福－巴黎
错误：法兰克福——巴黎、法兰克福-巴黎

2. 数值范围。在不引起歧义的情况下，可省略前一数值的单位或附加符号，如：

1000－2000年、1－5千克。

--InstantNull（留言） 2023年2月8日 (三) 20:15 (UTC)[回复]

不认同字符选择与表达含义间存在关联
在默认及常见字体中未见明显证据
部分承认（即便在正规印刷品中，002d也有一定使用，虽然可能是误用）
承认
在默认及常见字体中未见明显证据
在微软雅黑中2014略长于em，反之ff0d未见问题
未见可靠出处

综上反对提案。--。->>Vocal&Guitar->>_留言 2023年2月9日 (四) 02:54 (UTC)[回复]

不认同您对 (1) 的意见，Unicode符号本身是具有语义的，形似而不同义的字符都会进行分离，不应混用。en:hyphen和en:dash的用法是不同的；
连接号用U+2014是有权威出处的，如台教标在线网页《重訂標點符號手冊》修訂版。大陆的GB/T 15834-2011虽然公开的是扫描件，不能确定码位，但也明显更像U+2014而不是U+ff0d。

--DvXg 📬 2023年2月9日 (四) 06:55 (UTC)[回复]

关于（1）我想不应该有疑问。正如David Xuang所说，Unicode对于每一个字符都有明确的定义。U+FF0D －是 U+002D - 的全形版本（您可以参考全形和半形了解更多），它们本质上是同一符号的不同字符表示，在中文里同时混用是不恰当的。就如同我们不应该在中文里同时使用半形“/”和全形“／”是一个道理。

关于（2）可以请您参考右侧的截图，U+FF0D －在 macOS Chrome 浏览器中的显示效果。在正文中的是无衬线字体，在标题中的是有衬线字体，二者差异很大，标题中有衬线的字体显示效果非常不理想。

关于（6），我指一个字符宽即一个em 单位，参见Em (字体排印学)。

关于（7）我想多做一点解释。在英文中 en dash 和 em dash 的关系就类似于中文里的连接号与破折号之间的关系一样。传统上 en dash 的长度就是 em dash 的一半。类似的，中文里破折号既然已经广泛接受用两个em dash “——”表示，那么连接号用一个 em dash 才是符合惯例的。

--InstantNull（留言） 2023年2月9日 (四) 18:37 (UTC)[回复]

1. 我关心的是中维常年使用ff0d，现状是否对文章内容的表达产生了歧义？字符的定义在这里并没有特别强调的必要。即便如法兰克福—巴黎变为法兰克福-巴黎也不会产生另一种意义。

2. 我注意到这张截图是2018年，不清楚目前是否仍然有效，我持有的设备（Windows，Android，Ubuntu）上没有发现类似问题。我希望您能多举例以证实“多数中文字体支持不理想”的主张。

6. 建议实测。

7. 您个人的意见我无法评论。另我认同国标推中使用2014，但不认同维基百科需要调整。--。->>Vocal&Guitar->>_留言 2023年2月10日 (五) 03:54 (UTC)[回复]

可否将您的意见理解为"将错就错"?再比如,我在这行句子中,全部错误地使用了半形标点.但这其实丝毫不影响您理解这段话的意思对吗?

常年使用不是一个合理的理由。本人实际上是推动将MOS:標點符號升格为指引的发起者之一，当时连接号码位选择并没有经过讨论，该错误一直遗留至今。中文维基在发展中必然会遇到需要标准化的需要。方便编辑输入和方便读者阅读、检索是必要的现实需求。甚至有一些读者会将维基百科的格式奉为标准，因此我们有义务提供准确的信息。再者我也提到，新指引只是不再把 U+FF0D 作为推荐的符号，不妨碍兼容已有的使用。

截图中的问题仍然存在。之前提到 U+FF0D 从未被广泛使用过，因此有部分中文字体对 U+FF0D 做了专门的字形设计而另一些没有，使得其在实际的主流字体中没有一致的外观。和您提到微软雅黑的问题一样，这是一个字形（glyph）设计概念。这篇文章中有提到，旧版微软雅黑的标点是过时的且不符合国标。这篇文章介绍了相关背景：“但绝大多数中文字体甚至一些西文字体对 U+2014“—”（Em Dash）的显示效果比西文标点 Em Dash 应有的宽度宽一些，基本符合一字线的形式要求。”

以上内容并非个人观点，我已提供了一些资料供您参考，这基本上是中文字体排版的共识。W3C中文支持文档明确写道：“《标点符号用法》（GB/T 15834—2011）中没有指定这三个符号的码位，但是基本上可以推断一字线是U+2014 EM DASH [—]”。--InstantNull（留言） 2023年2月10日 (五) 07:56 (UTC)[回复]

( π )题外话：无论一字线用什么符号，美國－墨西哥－加拿大協議按MOS:连接号指引应该用短横线，应移动到“美国-墨西哥-加拿大协议”。——小林子冲（留言） 2023年2月20日 (一) 20:17 (UTC)[回复]

我個人亦希望能夠規範連接號之使用。不過必須提醒，根據統計，目前本站至少有三千餘篇條目及其他三千餘個頁面之標題含有「－」（另有四千餘個重新導向，總計一萬出頭），更不用提內文了；因此，若要變更連接號標準，應考慮動用機器人進行移動。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年2月10日 (五) 08:32 (UTC)[回复]

是的，所以我其实并不建议将原符号算作错误使用。较好的做法是将标准改正，确保新条目和新文章使用正确标准，并向后兼容，让社区自己逐渐修正。--InstantNull（留言） 2023年2月10日 (五) 17:30 (UTC)[回复]

我倒是建議進行一次集中批量移動，一勞永逸。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年2月11日 (六) 10:57 (UTC)[回复]

(＋)支持提案。中文维基百科选用U+FF0D作为連接號是奇怪的事情，既不符合任何规范又不便于输入。--Lt2818（留言） 2023年2月10日 (五) 14:06 (UTC)[回复]

囧rz……「一字线可以通过中文输入法输入破折号并删去一半得到」？我想說Windows10的倉頡輸入法並沒有這個功能。--街燈電箱150號開箱維修抄錶檢驗證明 2023年2月10日 (五) 14:22 (UTC)[回复]

倉頡輸入法「ZXAY」會得出一個 Em dash. 谢谢提醒，我已对修订条文做了改动。--InstantNull（留言） 2023年2月10日 (五) 17:44 (UTC)[回复]

原则上支持。但我的担心是，如果只是推荐使用U+2014，而不将U+FF0D视为错误，那会造成两者同时存在的混乱局面，还有可能导致一些编辑争议出现。但另一方面，如果要禁止U+FF0D，那修正目前条目中现有的大量U+FF0D感觉是一项不小的工程。当然可以用机器人处理，但也需要注意不应误伤，比如参考文献的标题如果原本用的就是U+FF0D的话我想不应该去修正？还有一些有关Unicode、字体排版等条目中也有确需使用U+FF0D的情况。--Stevenliuyi（留言） 2023年2月11日 (六) 18:45 (UTC)[回复]

為了避免新舊共存引發混亂，我個人建議對現有頁面進行一次集中批量移動。至於正文，可能需要研發小工具專門更改連接號，加快速度。參考資料的話更是一團亂，可能有本來就用這符號的，也可能有後來被改的，沒有辦法用機器人處理，只能比照正文，並研發小工具加速更改。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年2月12日 (日) 07:05 (UTC)[回复]

Wikipedia:格式手册/标点符号是不适用于参考文献的哈。--InstantNull（留言） 2023年2月13日 (一) 01:25 (UTC)[回复]

(？)疑問：有没有办法追踪有人有意或者无意地使用汉字“一”（壹）代替连接号“—”（U+2014），有些系统中汉字“一”和连接号肉眼区分不出来。快捷输入的问题，个人的方法是不少输入法（包括PC、手机）会提供自定义短语，比如设置成“一字线”的拼音或者其他码表，快捷输入应该问题不大。--Kethyga（留言） 2023年2月15日 (三) 11:17 (UTC)[回复]

在本人手机上U+FF0D的显示效果比PC网页上号。--Kethyga（留言） 2023年3月2日 (四) 06:20 (UTC)[回复]

它之所以叫“一字线”是有原因的哈哈。甚至可以说这是U+FF0D“－”的另一个问题：它太短了，和短横线太像而太不像“一”字了。故意用相近字形的字符替换不是 em dash 所特有的问题，正如同我们没有办法故意检测有人故意用数字0去替换字母O一样。在很多软件里也有自动替换功能，比如在Word里输入“--”会被自动替换成em dash--InstantNull（留言） 2023年2月16日 (四) 05:56 (UTC)[回复]

[0-9a-zA-z]一[0-9a-zA-z]这种情况也许是可以加入过滤器的（应该不会有假阳性），就是涵盖的范围可能还不是很够。--DvXg 📬 2023年2月17日 (五) 11:45 (UTC)[回复]

(＋)强烈支持。之前的讨论没有继续推进着实可惜，希望这次能一劳永逸解决中维连接号问题。--PexEric 💬|📝 2023年2月18日 (六) 08:48 (UTC)[回复]

(＋)支持：使用全角的连字暨减号（“－”，U+FF0D）作为“一字线”或“连接号”的确不是常用的做法。Em Dash（“—”，U+2014）在简体中文下是破折号的一半，输入起来很方便。

在大陆，中华人民共和国国家标准规定了一字线的符号（[3]），看起来有点像Em Dash，而不是全角的连字暨减号（连字暨减号看起来更短）。不过这是一个PDF文档，难以确定到底用的是哪一种。

在台湾，连接号条目里说了“台湾教育部《重订标点符号手册》修订版使用em dash作连接号。”

综合上述各地情况，支持将格式手册的连接号改为Em Dash（“—”，U+2014）。——小林子冲（留言） 2023年2月20日 (一) 20:06 (UTC)[回复]

(？)疑問：英维那边使用的连接号为 en dash（“–”，U+2013），而本地的 cite 系列引文模板自英维引进，其中用於连接页码的也是该符号，因此在站内有着大量用例。在本人的设备上看来，连字暨减号“－”（U+FF0D）太短，视觉效果很差，而 em dash“—”（U+2014）又显得过长了，超出了一个汉字的宽度。考虑到连接号最常使用的地方是在数字之间，故其长度如能与数字的宽度相仿理应看着最舒适。使用比汉字还宽的 em dash（U+2014）来连接数字，视觉效果似乎略显累赘。总之，这两个符号看上去都不如长度适中的 en dash（U+2013）美观，所以我们为什么不效仿英维，以 en dash 作为首选连接号？这样一来既能确保美观，又能与引文页码中的连接号保持一致。虽然参考文献使用的符号不必与正文相同，但如能使整篇条目中的连接号整齐划一，未尝不是更好的选择。--蕭漫（留言） 2023年3月1日 (三) 23:19 (UTC)[回复]

这里所有的讨论只针对内文和标题，不适用于文献引用。文献引用有另外单独的格式标准。维基百科:格式手册/标点符号第一段最后一句也说明了这一情况。--InstantNull（留言） 2023年3月2日 (四) 03:26 (UTC)[回复]

再提取消文件移动员并下放权限

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:檔案移動員。

现今，文件移动员身份组仅有2人，且文件移动需求不高，在本地需移动的文件一般也无特别大的争议，故再次提议取消文件移动员并将权限下放，个人认为可下放至延伸确认用户。--在下荷花，请多指教（欢迎签到） 2023年2月11日 (六) 14:04 (UTC)[回复]

(＋)支持感觉这个权限组没什么意义，建议将该权限进一步下放到自动确认用户。为避免移动破坏，保留“移动时不留重定向”给延伸确认用户。第一眼看到这个提案的反应是“什么，我们还有文件移动员？！”的顺颂时祺 ZhaoFJx^{（论•编）} 2023年2月12日 (日) 02:18 (UTC)^{[開玩笑的]}[回复]

我是，另外移动不留重定向在文件移动方面没有独立的权限，所以分不出来。--在下荷花，请多指教（欢迎签到） 2023年2月12日 (日) 03:09 (UTC)[回复]

唔，如果这样的话就不要下放了，因为移动破坏也不是不常见。——顺颂时祺 ZhaoFJx^{（论•编）} 2023年2月12日 (日) 03:12 (UTC)[回复]

不反对将文件移动权限（movefile）下放到延展确认用户。但移动后不留原名（suppressredirect）是否也下放到延展有保留。附，现在“文件移动”给了巡查阔免、巡查、文件移动组，“移动后不留原名”给了萝卜（bot）组、巡查、回退、跨维基导入。（或者说拿到巡查基本上都能用上）——Sakamotosan路过围观 | 避免做作，免敬 2023年2月12日 (日) 05:32 (UTC)[回复]

本案不提议下放不留重定向权限。--在下荷花，请多指教（欢迎签到） 2023年2月12日 (日) 06:31 (UTC)[回复]

(＋)支持下放 movefile 權限至延伸確認使用者並移除檔案移動員使用者群組。--冥王歐西里斯（留言） 2023年2月15日 (三) 03:17 (UTC)[回复]


	上任日	除權日	用權數
Sanmosa的移動日志	2021年9月23日	2022年2月1日	0
RyanCray的移動日志	2020年11月12日	2022年12月7日	17
Minorax 的移動日志	2019年7月13日	至今	1
TimWu007的移動日志	2019年10月28日	2020年8月11日	32
和平至上的移動日志	2018年6月13日	2018年6月17日	0
hehua的移動日志	2022年2月22日	至今	67

更新于：2023年2月12日 (日) 10:09 (UTC) 再作了一次统计。Ghren 🐦🕕 2023年2月12日 (日) 10:11 (UTC)[回复]

看起来好像还可以，我是觉得这个需求不是很大可以下放。--在下荷花，请多指教（欢迎签到） 2023年2月12日 (日) 14:01 (UTC)[回复]

(＋)支持&(！)意見：若下放至扩展确认，不建议取消文件移动员组别，应保留以备自动确认组或是确认用户组的用户申请；若下放至自动确认用户，则支持取消文件移动员组别。另外，个人支持权限下放，文件移动员组别的权限敏感度应当和普通页面移动权类似，没有必要加以限制。至于是下放到扩展确认还是自动确认，由于文件方针较普通页面更严，认为先行下放至扩展确认较为合适。H.Natsumi ™ 2023年2月12日 (日) 14:53 (UTC)[回复]

那也可以。--在下荷花，请多指教（欢迎签到） 2023年2月12日 (日) 15:27 (UTC)[回复]

(＋)支持：就是不知道哪些天兵用戶想出來的類似巡查豁免權一樣的沒屁用權限（有跟沒有意思一樣），這討論看了就真可悲，應當直接廢除這種沒屁用權限才是。還有，這個討論不是應該再邀請熱衷於檔案存廢討論的@Wcam來討論才合理嗎？也沒有人提到要是檔案名稱與維基共享資源重複的問題？奇葩。總之，這討論串基本上沒什麼好討論的，獨裁社群就是喜歡把簡單的事情複雜化。--Z7504非常建議必要時多關注評選（留言） 2023年2月13日 (一) 15:53 (UTC)[回复]

现在来看基本上都支持下放至延确，但是对于是否取消用户组似乎还有不同意见，想问一下应不应该取消呢？个人是倾向取消，但是需要处理的移动文件分类可以保留。--在下荷花，请多指教（欢迎签到） 2023年2月15日 (三) 06:05 (UTC)[回复]

我個人傾向取消，畢竟中文維基百科目前的延伸確認使用者已有三千多人，都已經是英文維基百科的檔案移動員人數的十倍左右了（不過英文維基百科的檔案移動員僅有 movefile 而無 suppressredirect 權限），保留檔案移動員使用者權限群組無甚必要，要找到延伸確認以上權限的使用者協助移動也不困難。--冥王歐西里斯（留言） 2023年2月15日 (三) 06:37 (UTC)[回复]

@S8321414中文的文件移动员也没有不留重定向。--在下荷花，请多指教（欢迎签到） 2023年2月15日 (三) 07:49 (UTC)[回复]

那麼更沒有問題了，更何況 movefile 在管理員、巡查員與巡查豁免都有，就算自確沒有，要找到有此權限的人也應當不困難。--冥王歐西里斯（留言） 2023年2月15日 (三) 08:30 (UTC)[回复]

个人提议如果下放扩展确认仍保留文件移动员组别的原因其实就是Minorax的权限申请，确实无法排除存在跨域贡献者愿意参加本地文件移动的可能性，而目前中文维基百科的扩展确认门槛较高（如果先前没有自动创建中文的账号则需要等待90天），合理认为这样会影响到跨域贡献者的贡献（虽然可以提交移动请求，但是显然对于这一类人直接授权来的更好）。H.Natsumi ™ 2023年2月15日 (三) 08:40 (UTC)[回复]

这个也确实，@S8321414 您怎么认为？--在下荷花，请多指教（欢迎签到） 2023年2月15日 (三) 12:00 (UTC)[回复]

我個人還是傾向廢除檔案移動員群組，但暫時保留還算是可接受的選項（不過這個暫時不知道有多久就是了）。--冥王歐西里斯（留言） 2023年2月15日 (三) 12:45 (UTC)[回复]

@Hotaru Natsumi：經查，Minorax已係延確。另：個人建議檔案移動員權限可改為僅以臨時權限形式授予。San mo sa _{Συ γάρ μοι και μοίρα εί και τύχη} 2023年2月16日 (四) 06:49 (UTC)[回复]

大概接近想法。将“文件移动”下放到延展用户，现有组保留并辞退现有组员，只作为临时授权给没到延展用户的后备，可以自行移除自己组。这样避免浪费组功能，也可以应对特定情况。——Sakamotosan路过围观 | 避免做作，免敬 2023年2月16日 (四) 07:24 (UTC)[回复]

啊不是说Minorax的权限会因此而被移除，而是说因为Minorax的例子个人认为这个组应该要保留，以避免后续如Minorax这样的跨域贡献者在存在经验可以获得该权限的情况下难以直接获得这一权限。另外关于仅授权临时权限，应是合理且必要的，确实若得到这一权限，保持活跃编辑不出12个月应当能够达到扩展确认权限门槛。H.Natsumi ™ 2023年2月16日 (四) 09:01 (UTC)[回复]

感觉没有必要仅授予临时权限，没什么意义，达到了再除权就完了。--在下荷花，请多指教（欢迎签到） 2023年2月16日 (四) 09:04 (UTC)[回复]

这样也行，就是扩展确认本身是自动授权的，有必要的话可以写个机器人自动提报或者自动除权。H.Natsumi ™ 2023年2月16日 (四) 09:25 (UTC)[回复]

也可以。--在下荷花，请多指教（欢迎签到） 2023年2月16日 (四) 10:48 (UTC)[回复]

我认为你搞错了一些点，保留组是为了临时授权的需要，实务上不再使用“文件移动员”组，延展用户的达标是需要一定的编辑量，临时授权是为了前面的情况（例如上面提到的Minorax，19年授权，但到21年才到延展）。——Sakamotosan路过围观 | 避免做作，免敬 2023年2月17日 (五) 00:29 (UTC)[回复]

@Cwekemm我没明白，请问这里的临时授权说的是不授予无限期权限还是什么别的？--在下荷花，请多指教（欢迎签到） 2023年2月17日 (五) 06:37 (UTC)[回复]

就是有期限的组别授权。组别不再长期授予，保留组别是为了应对没到延展的情况临时使用。——Sakamotosan路过围观 | 避免做作，免敬 2023年2月17日 (五) 06:45 (UTC)[回复]

啊，那授予多长时间呢？这要修改方针吧。--在下荷花，请多指教（欢迎签到） 2023年2月17日 (五) 06:54 (UTC)[回复]

因为提出Minorax这个案例，我也不太确定。因为原本就是干脆整组移除的，Minorax的按钮才考虑临时留下。如果参照的话，可以看LIPE的临时授予期？好像常见是半年。——Sakamotosan路过围观 | 避免做作，免敬

大致支持。另外，延伸确认用户得到的不是完整的「文件移动员」权限，没有suppressredirect，不排除有人希望不留重定向移动文件，且不是巡退员。可留作该用。 ——魔琴 [ 留言贡献新手2023计划 ] 2023年2月17日 (五) 14:29 (UTC)[回复]

@魔琴文件移动员本来就没有suppressredirect权限。--在下荷花，请多指教（欢迎签到） 2023年2月18日 (六) 01:01 (UTC)[回复]

哦这样啊，恕在下失察，谨撤回意见。 ——魔琴 [ 留言贡献新手2023计划 ] 2023年2月18日 (六) 04:41 (UTC)[回复]

不反对也不支持下放。目前除了文件移动员外，movefile权限还赋予了管理员、巡查员与巡查豁免，后两者的门槛不高，且移动文件似乎基本上就是巡查工作才需要使用吧。不过既然suppressredirect不下放，倒也不用担心错误移动文件导致红链的问题，因此中立。--BlackShadowG Slava Ukraini! 2023年2月19日 (日) 02:24 (UTC)[回复]

也会有一些上传的时候填错了名想改发现只能请求的情况。--在下荷花，请多指教（欢迎签到） 2023年2月19日 (日) 09:05 (UTC)[回复]

我覺得權限留著也沒有什麼大礙。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年2月20日 (一) 02:28 (UTC)[回复]

提议条文

看上去是没什么大的反对意见了，先放个条文修改如下：

WP:EXTENDEDCONFIRMED：

現行條文

一個已註冊的用戶會在註冊達90天並編輯達500次後自動被授予該群組權限。該群組的權限允許用戶編輯受到延伸確認保護的頁面。

提議條文

一個已註冊的用戶會在註冊達90天並編輯達500次後自動被授予該群組權限。該群組的權限允許用戶編輯受到延伸確認保護的頁面，且相较于自动确认用户，还可以移动文件。

WP:FM：

現行條文

檔案移動員用戶權限允許有經驗的使用者，依據方針執行檔案更名工作，以便享有如同自動確認用戶移動維基百科條目的便利功能。任何管理員可以在審慎考慮之下，授予可信任用戶這個權限，該用戶必須經常處理多媒體文件，且熟悉各類多媒體重新命名的相關方針與指引。檔案移動員的資格基本資格要求是：

自首次編輯以來參與維基百科滿30日；
至少250次編輯，以及過去3個月內（未滿3個月之新註冊用戶，從註冊之日起計算至當日）平均編輯次數多於1次；或曾經提出有效檔案移動申請（包含維基共享資源）至少20次（將會從用戶貢獻中的檔案編輯歷程中查證）；
最近1年內未曾受到封禁處分（不合理封禁除外）；且
申請時須回答管理員或現有檔案移動員相關方針與指引的知識及應用問題。

除此之外，檔案移動員應當非常熟悉維基百科的圖像與多媒體方針（尤其是本頁面當中的重新命名指引）、對圖像更名程序有充分了解和具有處理圖像相關工作的經驗。

如果用戶曾在維基共享資源執行相同工作、使用相關工具以及其他多媒體檔案的相關類似經驗，管理員或許會將這些經驗作為是否授予權限的考慮因素。

除非剛來的編輯者曾上傳一定數量的檔案，否則本用戶權限一般不會授予此類編輯。

如果您有意為您或其他用戶申請檔案移動的權限，請到Wikipedia:權限申請/申請檔案移動權申請。以下用戶不需要去申請或是為他們增加本權限，他們本身已經獲自動授予檔案移動的權限：

提議條文

檔案移動員用戶權限允許有經驗的使用者，依據方針執行檔案更名工作，以便享有如同自動確認用戶移動維基百科條目的便利功能。

文件移动权限已于?年?月?日并入延伸确认用户组，文件移动员权限组现仅保留以便授予未达延伸确认的跨域贡献者文件移动权。

如果您有意為您或其他用戶申請檔案移動的權限，請到Wikipedia:權限申請/申請檔案移動權申請。申请人应当已于维基共享资源或其他维基媒体旗下项目取得相应的文件移动权限，且在其他维基媒体项目进行过一定数量的文件移动。

当持有文件移动员权限组的用户达到了延伸确认或是取得了巡查或巡查豁免资格，则应当自行移除文件移动员组别。

以下用戶不需要去申請或是為他們增加本權限，他們本身已經獲自動授予檔案移動的權限：

以上。H.Natsumi ™ 2023年2月24日 (五) 02:49 (UTC)[回复]

好！--在下荷花，请多指教（欢迎签到） 2023年2月24日 (五) 05:42 (UTC)[回复]

申請資格第二項看起來是多餘的，是否是延伸確認使用者的筆誤？--Xiplus#Talk 2023年2月24日 (五) 06:02 (UTC)[回复]

本意是不持有movefile这个权限，不是指文件移动员这个权限组，实际操作中有这个权限的应该也不会重复申请，想来确实可以移除这个条件，已修改。H.Natsumi ™ 2023年2月24日 (五) 08:24 (UTC)[回复]

(～)補充：此外Wikipedia:權限申請/申請檔案移動權/header应当也要做相应更动，或者更加浅显地说，只保留欲申請檔案移動權，請點擊下方「增加新請求」。，并且加上：

注意：文件移动权已于?年?月?日并入延伸确认用户，此页面现仅供跨域贡献者在未达延伸确认要求，且未取得巡查员、巡查豁免者权限时临时申请文件移动权。普通用户不应在此申请文件移动权，而应使用{{Rename media}}代替，直到获得延伸确认用户权限、巡查权或巡查豁免权。详见Wikipedia:文件移动员。

供参。H.Natsumi ™ 2023年2月24日 (五) 08:43 (UTC)[回复]

(＋)支持--Eve sie sta_{COVID-19感染中} 2023年2月26日 (日) 03:33 (UTC)[回复]

整案提出已近7天无反对意见，本案最终结果是下放文件移动员权限但不取消文件移动员，以方便跨维基贡献者进行文件移动。现 公示7日，2023年3月9日 (四) 13:48 (UTC) 結束。--在下荷花，请多指教（欢迎签到） 2023年3月2日 (四) 13:48 (UTC)[回复]

Wikipedia:格式手册/标点符号#书名号新增使用Template:《的方法，修改使用代码的方法，并调整“效果为”的位置

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:格式手册/标点符号。

現行條文: 维基百科提供了两种方法解决部分书名号使用地区差异，所以遇到部分书名号使用地区差异问题时应用以下两种方法解决，而不应单純替换源码的双单书名号，否则会被视为繁简破坏。其中Template:单双书名号转换用于实现“书2”中双书名号与单书名号之间的使用差异。Template:引书号转换用于实现“书3”中引号与双书名号之间的使用差异。

使用模板：
- {{单双书号转换|需转换的作品名}}
- {{引书号转换|需转换的作品名}}
效果为：
- 《需转换的作品名》
- “需转换的作品名”
使用代码：
- -{zh-hans:《;zh-hant:〈;}-需转换的作品名-{zh-hans:》;zh-hant:〉;}-
- -{zh-hans:“;zh-hant:《}-需转换的作品名-{zh-hans:”;zh-hant:》}-
效果为：
- 《需转换的作品名》
- “需转换的作品名”

提議條文: 维基百科提供了三种方法解决部分书名号使用地区差异，所以遇到部分书名号使用地区差异问题时应用以下三种方法解决，而不应单純替换源码的双单书名号，否则会被视为繁简破坏。其中Template:单双书名号转换用于实现“书2”中双书名号与单书名号之间的使用差异。Template:引书号转换用于实现“书3”中引号与双书名号之间的使用差异。

使用模板：
- {{单双书号转换|需转换的作品名}}
效果为：

《需转换的作品名》
- {{引书号转换|需转换的作品名}}
效果为：

“需转换的作品名”
使用模板：
- {{《}}需转换的作品名{{》}}或{{〈}}需转换的作品名{{〉}}
效果均为：
- 《需转换的作品名》
使用代码：
- -{zh-hans:《;zh-tw:〈;zh-hk:《;}-需转换的作品名-{zh-hans:》;zh-tw:〉;zh-hk:》;}-
效果为：

《需转换的作品名》
- -{zh-hans:“;zh-hant:《}-需转换的作品名-{zh-hans:”;zh-hant:》}-
效果为：

“需转换的作品名”

新增Template:《的方法，参见Template:《。
修改zh-hans:《;zh-hant:〈;为zh-hans:《;zh-tw:〈;zh-hk:《;，否则在香港繁体下，模板的结果和代码的结果不一致。
调整“效果为”的位置。
——小林子冲（留言） 2023年2月21日 (二) 05:28 (UTC)[回复]

( π )题外话：单双书名号可以设置地区词处理，为什么“标有引号的并列成分之间、标有书名号的并列成分之间通常不用顿号”不设置地区词处理，甚至还有用户说“有地域中心之嫌”？——小林子冲（留言） 2023年2月21日 (二) 05:34 (UTC)[回复]

三种方法本质都是一样的，只是代码实现上有所不同。对于格式手册写这么长太啰嗦了。直接写成下面这样就好：

{{《}}需转换的作品名{{》}}、{{〈}}需转换的作品名{{〉}}或{{单双书号转换|需转换的作品名}}

PS：另外还有一种方法是把双书名号改成单书名号，然后加入{{NoteTA|1=zh-cn:《;zh-tw:〈;zh-hk:《;}}。好像音乐类条目有这样的操作。--洛普利寧 2023年2月21日 (二) 13:54 (UTC)[回复]

(＆)建議：格式手册确实应修订部分条文，使站内的顿号用法得以规范化。可将以下代码加入手册供编者複製粘贴，在转换书名号的同时消除大陆简体模式下多餘的顿号：

{{NoteTA
|1 = 〈=>zh-tw:〈; 〈=>zh-hk:《; 〈=>zh-cn:《; <!-- 中国大陆仅在双书名号之内使用单书名号 -->
|2 = 〉=>zh-tw:〉; 〉=>zh-hk:》; 〉=>zh-cn:》;
|3 = zh-tw:〉、〈; zh-hk:》、《; zh-hans:》、《; zh-cn:》《; <!-- 依中国大陆现行规范用法，书名号之间不加顿号 -->
|4 = zh-hant:》、《; zh-hans:》、《; zh-cn:》《;
|5 = zh-hant:」、「; zh-hans:”、“; zh-cn:”“; <!-- 依中国大陆现行规范用法，引号之间不加顿号 -->
}}

当然，更好的处理方式是将後三条转换规则加入全局转换。如遇特殊的例外情况，确需在标有引号或书名号的并列成分之间显示顿号，可手动添加-{}-以包含顿号。鑒於这种例外情况极其少见，故在此提议加入全局转换。--蕭漫（留言） 2023年3月1日 (三) 22:06 (UTC)[回复]

(－)反对蕭漫的提議，上次討論確認不強制規定書名號及引號間用不用頓號才不過一個月不要立刻重提，不解決該討論的有效反對意見則不應通過此項。--路西法人 2023年3月2日 (四) 03:07 (UTC)[回复]

上次反對的是直接兩岸三地都將之視為標準吧，但沒有反對在大陸使用此方案啊。--Ghren 🐦🕓 2023年3月2日 (四) 08:11 (UTC)[回复]

您可以再讀一次討論，有留言指出雖然被列為標準但僅為新設且民間仍有不認同的聲音。--路西法人 2023年3月2日 (四) 14:43 (UTC)[回复]

那个讨论我有看，也有發過言。Y君說的是不推薦也不反對，總之是沒有人明確反對在大陸使用此案就是了。您可以說有人提出在該討論說過該標準在大陸爭議，然後您反對，而不是直接說解決該討論的反對意見。謝謝。Ghren 🐦🕚 2023年3月2日 (四) 15:21 (UTC)[回复]

YF君原話是可能不應推薦這種寫法，但也無需禁止：「可能不應推薦」仍然是對該案和此案的有效爭議意見。雖該留言未明確對大陸使用此案提出爭議，但也是指出了相關爭議，同樣需要回應。看來只是我們對我們自己說的話以及他人留言的不同理解，無須再爭論這點小事了。--路西法人 2023年3月3日 (五) 10:34 (UTC)[回复]

(－)反对。該方案在大陸有爭議，實務上執行者也不多。

唐普.新國標《標點符號用法》并列的引號、書名號間省略頓號規定的問題辨正[J].四川師範大學學報(社會科學版),2022,49(02):199-208.DOI:10.13734/j.cnki.1000-5315.2022.02.023.

[1]張同學.對標點符號用法中一條頓號用法規則的探討[J].傳播與版權,2020(04):22-24.DOI:10.16852/j.cnki.45-1390/g2.2020.04.009.

而且，據張龍的說法，「"《A》《B》和《C》""《A》《B》和《C》（D）"這兩類用法并不違反國標規定,是經濟實用的用法,應該成為頓號省略用法的取向;"《A》、《B》、《C》（D）""《A》（D）、《B》、《C》""《A》、《B》（D）、《C》""《A》（D）、《B》和《C》""《A》、《B》（D）和《C》"這五類用法中的頓號不可或缺。將前述7種用法中的書名號換為引號,亦然。」（張龍.出版傳播中書名號或引號之間的頓號用法芻議[J].溫州大學學報(社會科學版),2021,34(03):61-66.）

此轉換方式會將"《A》、《B》、《C》（D）""《A》（D）、《B》、《C》""《A》、《B》（D）、《C》""《A》（D）、《B》和《C》""《A》、《B》（D）和《C》形式的頓號過度轉換。--Ghren 🐦🕓 2023年3月2日 (四) 08:17 (UTC)[回复]

提議設立「公共交通路線條目指引」

目前，公共交通路線條目的數量超過一萬條，唯目前沒有統一寫法，而當中有大量條目以愛好者角度編寫。故此，本人基於優良條目寫了一個框架-「Wikipedia:公共交通路線條目指引」，望請列入格式手冊。--唔好阻住我愛國（留言） 2023年2月23日 (四) 13:16 (UTC)[回复]

内容与Wikipedia:交通車輛條目指引高度重合。按你说的我也能造出来一堆毫无实际内容的格式指引。--PexEric 💬|📝 2023年2月26日 (日) 06:28 (UTC)[回复]

這是一個框架，是按照WP:GA條目的共通之處寫的，最主要是看看這個框架有沒有問題。--唔好阻住我愛國（留言） 2023年2月26日 (日) 15:50 (UTC)[回复]

鐵路方面說「目前沒有一定數量的條目列入優良條目標準，難以制定統一標準。」那巴士方面才不足十條優良條目也不見得就能代表到一萬條條目的統一框架，而且目前全部優良條目都是來自香港的，其它地方卻一條都沒有，這就難保其它地方用這個框架會出現水土不服。看來現在根本還不是時候，所以(－)反对。--Maccomcre（留言） 2023年3月2日 (四) 01:50 (UTC)[回复]

有關管理員是否能刪除自己之前投票刪除的頁面及其時效的問題

近日，本人提刪了柯文哲和中华民国政党的关系的條目，后由管理員Shizhao執行刪除。

不過該條目在四年前，Shizhao先生曾參與該條目初次的存廢討論，並投下刪除一票。

因避嫌的一些事宜（删除：管理员不得删除自己提议删除或者投票删除的页面），我想向社群詢問一下：

管理員是否可以刪除之前自己參與刪除投票的條目？
兩次提刪是否爲避嫌守則中描寫的一项事宜？

我個人是贊成刪除。不過在守則方面，我們得謹慎一些。--WMLO（留言）。 2023年2月24日 (五) 14:06 (UTC)[回复]

WP:避嫌：“管理员不应该在一项事宜中使用普通用户和管理员的双重身份”。我认为两个AfD应该算两项事宜*。再者，管理员不可能记住自己所有参与过AfD的条目。因此我认为Shizhao的操作没有问题。当然，如果意识到之前参与过，主动避嫌还是一个很好的选择。［＊如果两次AfD有逻辑联系，比如第二次AfD来自DRV发还，或者是目前试行的RELIST流程，我认为还是应该视作一项事宜。］ ——魔琴 [ 留言贡献新手2023计划 ] 2023年2月24日 (五) 17:21 (UTC)[回复]

你都說是四年前的事了，書生怎麼可能記得呢，你會記得你四年前的今天吃了什麼早餐麻:）--~~S i d~~ 2023年2月25日 (六) 01:54 (UTC)[回复]

@ASid：感謝您對於我記憶力的反問，但鄙人不善於吃早餐:) 若論不可能記得，這點同意：但刪除頁面的同時，也完全可以參考以前的提刪事例，從這點也知道參與人數的意見，再進而看出以前自己曾參與過該頁面的存廢投票。并不是完全無可能的。當然，我也只是問一下一般人的標準。——WMLO（留言）。 2023年2月25日 (六) 12:03 (UTC)[回复]

至少要有時間間隔吧，因為有條目會在無共識保留一段時間後又被人提刪了。假如兩次提刪的間隔不長，那麼此時在上一次投過刪除票的管理員就不應該刪除。--日期20220626（留言） 2023年2月25日 (六) 13:50 (UTC)[回复]

佩服您翻旧账的能力。不过很难依据常识判断这两次提删属于一项事宜，两次页面的内容、编辑历史都是不同的，唯一的相同之处是在不同时间占用了同一名称。--PexEric 💬|📝 2023年2月26日 (日) 06:37 (UTC)[回复]

处理存废（包括积压）的时候，又要看有没有自己参与讨论，又要看讨论的最后时间是否超过5星期还是1星期，还要判断讨论的共识，这就已经难免顾此失彼了。。。。（说白了就是规则太复杂了）--百無一用是書生 (☎) 2023年2月28日 (二) 02:23 (UTC)[回复]

relist和vfd

由于relist启用，而vfd未相应更新，导致如想从条目页进入存废讨论必须再次点击，如多次relist，需多次点击。--Fire Ice 2023年2月26日 (日) 01:44 (UTC)[回复]

我已經提醒過Shizhao君了。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2023年2月26日 (日) 14:29 (UTC)[回复]

试行期过了再决定要不要修比较好。--Ghren 🐦🕑 2023年2月26日 (日) 18:09 (UTC)[回复]

重修封鎖方針及禁制方針

重修封鎖方針

細讀本站封鎖方針發現極嚴重翻譯腔及歐化漢語問題，且遺漏關於多項實際有執行但沒寫在方針內的資訊（例如封鎖開放代理）或需要但不存在明確指引的資訊（如解除封鎖相關指導），故建議完全重修封鎖方針以改善以上情況。重修方針草稿置於User:LuciferianThomas/專案/重修封鎖方針。

詳細修訂說明（嵌入引用自User:LuciferianThomas/專案/重修封鎖方針/比較條文）

現行條文

封禁，又称封锁或查封，是管理员阻止用户参与维基百科编辑的手段。封禁的目的只有一個，就是防止维基百科遭到持续或严重破坏，而绝非惩罚用户。

用户可以在当前的破坏页面或者本文提及的其他页面中提议封禁，提议的同时亦应提供充分的证据，但管理员有权拒绝执行被提议的封禁，并可以进行独立的调查。如果您认为某一个封禁不合理，请在使用者討論頁使用{{Unblock}}或向管理员发電子郵件讨论。

提議條文

封禁（或譯封锁或查封）是管理員阻止用戶編輯維基百科部分或所有頁面的技術措施，註冊用戶、未註冊的IP用戶及由多個相鄰的IP位址組成的IP區段（子網）均可被暫時或不限期封鎖。用戶被封鎖後仍留存其用戶討論頁的編輯權限作申訴之用，但在特定情況下管理員或考慮剝奪用戶討論頁使用權限。

封鎖僅應阻止維基百科受到破壞或擾亂，絕非作懲罰用戶之用（參見 § 用途和目的）；任何用戶在提供充分證據下可向適當的佈告板提報具不當編輯行為，提議管理員封鎖相關帳號和IP位址。若其他用戶認為某用戶的封鎖有問題，可至管理員佈告板請求重新審視封鎖是否恰當；管理員可在接納用戶申訴、認為封鎖缺乏適當依據、不再合適等情況下解除對用戶的封鎖情況下解除對用戶的封鎖（參見 § 解除封鎖）。

封鎖與禁制有所不同：禁制是褫奪用戶在維基百科全站或若干部分之編輯權的正式措施，並非技術上阻止用戶編輯頁面，但禁制可以透過封鎖來執行。

變更說明

首句「手段」一次有負面含義，改用更為中性的「技術措施」一詞（尤其整句「管理員[...]的手段」讀起來就很邪惡）。
補充封鎖的效果，取代原有的 § 被封禁的影響。
減少使用粗體。
原先方針除了首段完全沒有再提及AIV或任何其他頁面供提議封鎖，直接重寫為更清晰的指示且不提及當前的破壞（並非只有AIV一個佈告板可提議封鎖）。
與編輯禁制方針對應添加封鎖與禁制不同的文句。
不再使用{{方针列表}}：頁面底部已有導覽框，完全沒有重複的必要。

現行條文

封禁的用途和目的

簡而言之：封禁的目的是透過移除干擾來源，或鼓勵其改過，以避免未來出現問題的機會。封禁不應被用作復仇和懲罰的工具，也不應在不涉及行為問題的情況下使用封禁。

所有封禁均用作避免維基百科受到破壞，或減低潛在問題發生的機會。封禁應是阻止上述問題的最後手段，只用於應對以較溫和的方法不能解決的問題和持續違反方針的行為，而適當運用這手段能透過以下四個方法避免上述問題出現：

避免對維基百科進行迫切的或嚴重的破壞或干擾
透過增加有不當行為的用戶的編輯難度，制止該用戶對維基百科的干擾
讓有不當行為的用戶了解維基百科不能容忍其行為，應改善及避免該不當行為持續
鼓勵有不當行為的用戶以社群認同的有建設性、適當的編輯方式對維基百科進行貢獻

在某些情況下，管理員會延長封禁期限，以避免維基百科受到破壞及鼓勵用戶停止干擾維基百科，重新開始對維基百科作出貢獻。

提議條文

原則

快捷方式

WP:BLOCK#PURPOSE

管理員應當在執行封鎖前瞭解情況，並必須能夠佐證其執行的封鎖。封鎖應當具有阻嚇作用，以防止維基百科受破壞及擾亂，阻止當前持續的破壞行為，並避免往後再出現同類情況，再犯者或會被延長封鎖期限；封鎖時亦應鼓勵有不當行為的用戶以社群認同為建設性的編輯方式貢獻維基百科。封鎖不應用作復仇、貶損或懲罰用戶，更不應在無當前的行為問題下使用封鎖；一般不應以未持續發生且當前已無擾亂風險之事由作追溯式封鎖。

被封鎖用戶可發起封鎖申訴（參見 § 解除封鎖）。解除封鎖的請求同樣應以阻嚇破壞及擾亂性編輯作為考量。承諾停止不當行為，並能對相關規範展現具誠信之適當理解的用戶可能可獲解除封鎖；同樣地，在解除封鎖後持續出現相同不當行為的用戶，其封鎖申訴很可能會被拒絕。

變更說明

原標題繁簡混用，標題原為繁體但臺港澳都不用「封禁」一詞，而段內（不論新舊）都是在說明使用封鎖的原則，故更改標題為「原則」。
「而適當運用這手段能通過以下四個方法避免上述問題出現」這是中文嗎？「手段」如何「通過」「方法」？
四個列出方法當中頭兩個有點語法問題：

「避免對維基百科進行迫切的或嚴重的破壞或干擾」：封鎖無法得到「避免」干擾的效果，只能「阻止」干擾；
「通過增加有不當行為的用戶的編輯難度，制止該用戶對維基百科的干擾」：封鎖不應只是「增加編輯難度」，這個寫出來很有問題，除了少數用局部封鎖的用戶需要經編輯請求封鎖外，被全站封鎖的用戶不應存在「編輯難度」的說法，因為根本不該編輯。

現行條文

需要封禁的情況封禁通常用於以下情況，但不限於這些情況——特別是其他方針有具體規定的情況，只是本表所列的情況相對較少爭議而已。

對於管理員來說，最簡單的指引是：如果不確定封禁是否適合，則不應該執行封禁，或者執行前應諮詢其他管理員。如執行了一個可能具爭議性的封禁，則應在Wikipedia:管理员通告板通告，讓其他管理員進行複審。

此外，由於新用戶不熟悉維基百科的各項方針和指引，有時候他們的編輯看起來像在擾亂維基百科的運作。但管理員應該小心處理新用戶的不適當編輯——如因新用戶不適當的編輯而執行過量的封禁，會影響他們日後對維基百科作出貢獻的意欲。詳情請參閱Wikipedia:不要伤害新手。

提議條文

常見的封鎖原因

快捷方式

WP:WHYBLOCK

以下列出部分最常見的封鎖原因。管理員如果不確定是否應該封鎖則不應徑自執行，應當諮詢其他管理員的意見。執行可能具爭議性的封禁時，則應於管理員佈告板通知其他管理員進行複檢。

管理員在應對新用戶時需多加注意：新用戶可能因不熟悉維基百科的規則和社群規範而令其編輯看起來像在擾亂維基百科的運作，對新用戶採過重的處理手法會影響其日後對維基百科作出貢獻的意欲（參閱維基百科:不要伤害新手）；但需注意用戶在被充分提醒或警告後持續不當編輯仍可被封鎖，而用戶拒絕或顯為不當理解相關規範亦非規避封鎖等處分的理由。

變更說明

標題與段落首句有互相矛盾的情況，又「需要」又「通常」又有其他。
極度嚴重的歐化漢語，基本上不是中文語法，重新整理了語句。

現行條文

保護用戶或社群管理员可能封禁一个用户以保护维基媒体基金会、维基百科用户或者社区。保护目的的封禁用于应对以下行为：

持续人身攻击；
进行人身、财产或法律威胁；
威胁用户安全的行为；
泄漏个人信息（不论信息是否正确）；
持续的侵权行为；
持續在在生人物條目加入無參考來源及對該人物名譽有潛在影響的資訊。
持續發布和維基百科無關的廣告和宣傳信息。

如因有人洩漏其他用戶的個人信息或威脅其他用戶安全，管理員可在其他管理員同意下永久刪除與事件有關的編輯。

提議條文

保護用戶或社群管理员可為保护维基媒体基金会、维基百科用户或者公眾利益而实施封锁，包括但不限於以下情形：

持续人身攻击；
威胁伤害用户人身、名誉、财产或诉诸法律威胁；
其他可能危害用戶安全的行為；
泄漏个人信息，不论信息是否正确；
持续侵犯著作权；
持續於在生人物條目加入未能以可靠來源佐證、顯可合理查知推定其為虛偽，或已經公開證實為不實陳述之誹謗的內容；及
用戶帳號疑似被盜用。

在有人洩漏其他用戶個人信息或威脅其他用戶安全而被封鎖的同時，管理員應考慮請求監督員永久隱藏有關內容。

變更說明

「管理員可能封鎖一個用戶以保護維基媒體基金會、維基百科用戶或者社區」

「需要封鎖」的情況不該寫「可能封鎖」。
此段的重點應是「保護維基媒體基金會、維基百科用戶或者社區」的目的，重點置前；而且「社區」是什麼的「社區」？是指「社群」？

沒聽過「人身威脅」「財產威脅」，大概是直翻英語方針。改成了「威脅傷害用戶人身、名譽、財產」
「威脅用戶安全的行為」與威脅傷害用戶人身有點像，改寫成「可置用戶於危險境地的行為」。
「侵權」沒有註明是侵什麼權，寫明為「侵犯版權」。
BLP加入非可靠來源內容跟加入無來源內容無分別，「無來源內容」改為「無可靠來源佐證」。
「對該人物名譽有潛在影響」直接寫成「誹謗」更簡潔。
阻止發佈廣告保護了誰？其他章節已有，故此部分不寫這個了。

現行條文

防止破壞如果用戶的行為影響維基百科的運作，就會被管理員封禁。至於何謂影響維基百科的運作的行為，主要是不適合維基百科彼此尊重、坦誠、溝通、友愛氣氛的行為，及一切影響讓參與者合作，和諧地創建這個百科全書。以下列出部分被認為需要對帳戶作出封禁的行為：

持续的破坏性编辑；
持续扰乱维基百科的行为；
持续严重的不文明行为；
持续的骚扰行为（参见：en:Wikipedia:Harassment）；
持续的广告宣传；
持续编辑战或过度回退；
不適當使用傀儡；
持續的干犯其他方針與指引。

對於非經常性破壞，用戶一般會在被封禁前受到數次警告；至於有計畫、經常性破壞者則一般不會在封禁前有任何警告。但所有封禁在執行時一般應在被封禁用戶的對話頁給予適當的說明，以減少爭議。

純粹破壞

以下用戶名稱或帳號因為會影響維基百科運作，有可能會在無預警的情況下被封禁（一般為永久封禁）：

只用作干擾維基百科運作（如破壞）的用戶帳號；
共用帳號（其登入密碼被公布或在一個團體中分享）；
不適當的用戶名稱；
在獲得批准前運作的機器人（除去为了展示或测试功能而进行的示范性编辑，但这些编辑应当是无害的），或在運作不被批准的工作的機器人；
根據用戶的貢獻紀錄而判定為以宣傳一些事物（包括人物、公司、產品、服務和組織）的帳號。詳細請參閱Wikipedia:利益衝突和Wikipedia:廣告。

提議條文

防止擾亂

快捷方式

管理員可因用戶作出不適合維基百科文明協作氛圍或影響其他參與者協作共建百科全書的擾亂行為而實施封鎖，其中包括但不限於以下屬嚴重擾亂的行為：

蓄意破坏；
為闡述觀點而作出擾亂維基百科的行為；
不文明行为；
骚扰；
打编辑战，尤其違反回退不过三原则者；
發佈广告宣传及垃圾內容；
蓄意觸發過濾器；
違反方針與指引，尤其濫用多個帳號；及
試圖透過維基百科程序外的行動脅迫其他用戶，不論有關行動在站內或站外進行。

在一般情況下，用戶在首次被封鎖前會收到數次警告，但執行封鎖時仍應當在被封鎖用戶的對話頁提供適當說明或理據以減少爭議；再犯者在被重新封鎖前可能不需再次警告。

純粹擾亂以下帳號均具有明顯擾亂維基百科的可能性，可在無警告的情況下被封鎖（一般為不限期封鎖）：

顯然不是在建設百科全書的用戶；
根據貢獻紀錄而判定為僅用作宣傳特定事物（包括人物、公司、產品、服務和組織）的用戶帳號（詳細請參閱維基百科:利益衝突和維基百科:廣告）；
不適當的用戶名；
登入密碼被公布或在一個團體中分享的共用帳號；
未經審核批准或豁免審核運行，或疑似故障的機器人。

變更說明

將標題的「破壞」變更為「擾亂」，表列的行為並非全部符合破壞定義，但絕對是擾亂行為。
移除重複的「持續」字眼，在後面封鎖指導段落中有再提及。

現行條文

保证用户权限以下不适合的用户（帐号）可能被封禁：

公用帐号，即用户名和密码他人可以得到或者多人共享；
不恰当的用户名；
未经许可或者行为超出许可范围的机器人；
根據其用戶名及編輯紀錄，認定為以宣傳某人、組織、公司、產品或服務的帳號。詳情請參見Wikipedia:利益衝突。

此类封禁应在相应的用户页或者其说明页给出提示，说明用户帐号為何被封禁。

提議條文

整段刪除

變更說明

與上段很大程度重複，併入上段。

現行條文

無

提議條文

開放及匿名代理

開放代理或匿名代理（例如：付費代理、VPN、Tor、蘋果iCloud私密轉送等）常被用作破壞維基百科。管理人員時而需要IP地址等技術資訊來阻截濫用編輯權限的行為，但開放代理服務會隱藏用戶的真實技術資訊，甚至容許快速切換IP地址，導致難以堵截破壞行為。由此，維基百科禁止用戶（包括匿名用戶及註冊用戶）經開放代理網絡連接編輯，並會隨時封鎖開放代理伺服器的IP地址；元維基亦會依照禁用開放代理全域方針對這類IP地址實施全域封鎖。Tor的IP地址則會被維基百科所使用的MediaWiki系統自動封鎖。對開放代理的封鎖並不會限制或影響用戶閱覽維基百科。

此段嵌入引用自維基百科:请勿使用开放代理。

執行編輯禁制

編輯禁制是暫時或永久褫奪用戶在維基百科全站或若干部分之編輯權的正式措施，而封鎖功能是執行禁制的措施之一。執行禁制的封鎖應當依據禁制的條款制定，不同類型的禁制可通過全站及局部封鎖執行。

變更說明

由於現在有機械人自動封鎖代理機房段，故將「開放代理」作為常見封鎖原因寫入方針。
使用封鎖執行局部禁制已成社群規範。

現行條文

繞過封禁

方針快捷方式

如管理員發現某用戶利用其他帳戶蓄意逃避封禁繼續編輯，除了利用的帳戶和IP位置會被封禁外，原有被封禁的帳戶的封禁期限也可能被調整。

代替被封禁用戶作出編輯維基人不可「代表」某被封禁用戶作出編輯（又稱為「代理編輯/proxying」），除非該等編輯明顯有益於維基百科且代為編輯的用戶亦同意該編輯。新用戶如模仿被封禁用戶的行為（特別是那些只被用作這類編輯的帳號），將被視為同一用戶，承擔同等處分。請參閱有關傀儡及真人傀儡的方針。

回退被封禁用戶的編輯回退編輯前，應先考慮其他可行做法，如保護該等頁面。請留意被封禁用戶的所有編輯不一定都需要被回退——明顯有益的編輯，例如修正錯字及移除破壞的編輯等都應該保留。

當確實要回退編輯時，用戶應小心，不應重新加入違反方針的內容，特別是中立的观点方針、可供查證方針及生者傳記方針。用戶需對回退帶來的內容更改負上全責。

提議條文

繞過封鎖

快捷方式

管理員可在發現被封鎖用戶操控其他帳號繞過封鎖編輯的情況下重設封鎖時長；被封鎖繞過封鎖期間若繼續有可致封鎖的編輯行為，管理員亦可考慮延長封鎖時長。用作繞過封鎖的註冊用戶帳號及IP位址均應被封鎖，其中違規的傀儡註冊用戶帳號應當被永久封鎖。

代替被封鎖用戶作出編輯任何用戶不得代理或代表被封鎖用戶編輯，除非該等編輯明顯有益於維基百科且代為編輯的用戶有合理且獨立的原因作出該等編輯。模仿被封鎖用戶編輯行為的新用戶（尤其是僅作此類編輯的用戶帳號）將可被視為傀儡或真人傀儡並被施以與其模仿的用戶的同等處分。

回退被封鎖用戶的編輯任何用戶均可回退繞過封鎖作出的編輯且無需額外提供理由且不受回退不過三原則所規限，但需注意並非所有由被封鎖用戶繞過封鎖作出的編輯都需要被回退，一些明顯有益的編輯例如修正錯字及回退明顯破壞的編輯等可被保留，其他無法確定其明顯有益的情況下均應假定需要回退。

在回退被封鎖用戶的編輯時用戶應當注意不要重新加入違反方針的內容，特別是中立的观点、可供查證及生者傳記等核心方針；回退版本亦視作回退者所作出的編輯並需為回退版本的內容負責。由於新創建的頁面無法被回退（無可回退版本），其他用戶可考慮對被封鎖用戶所創建的頁面提出快速刪除或存廢討論；對於有被善意編輯用戶曾作實際貢獻和改善的頁面，其他用戶應當通知貢獻者頁面由被封鎖用戶創建，並按情況處理。

變更說明

修訂了空泛的「調整」封鎖字眼。
補充回退編輯相關規範。

現行條文

封禁不適用的情況有利益衝突的情況管理員不應該封禁與其有編輯爭議的用戶——這些封禁應交由其他管理員處理。此外，管理員也應該注意在處理與其貢獻的頁面和參與的條目類別有關的封禁時有可能出現的利益衝突問題。

以冷靜為目的的封禁

方針快捷方式

請不要以要用戶冷靜為理由封禁用戶——因為結果往往會適得其反。但，一些需要冷靜下來，而且曾作出破壞性編輯的用戶，則應該被封禁。

记录警告封禁不應被用作记录用戶的警告，因為短暫的封禁一般均被視為懲罰性的封禁，而且對該用戶也有不良的影響。

提議條文

不適用封鎖的情況

快捷方式

WP:BLOCKNO

利益衝突及避嫌管理員不應封鎖與其有編輯爭議的用戶，在此情況下必須避嫌並提報予其他管理員考量處理。管理員也應該注意在處理與其貢獻的頁面和參與的條目類別有關的封鎖時有可能出現的利益衝突問題。

以冷靜為目的的封鎖

快捷方式

請不要僅為讓用戶冷靜而施以封鎖，結果往往會適得其反；需要冷靜且有擾亂行為的用戶則可被封鎖以阻止進一步擾亂行為。

記錄警告封鎖不應僅被用作記錄對用戶的警告或不當事蹟，這些短封鎖很可能被視為懲罰及羞辱性質的封鎖；但在錯誤封鎖且封鎖已過期時可利用短封鎖在封鎖日誌中記錄原封鎖有誤（封鎖未過時則應填寫在解除封鎖或變更封鎖設定的原因當中）。

變更說明

小修訂。「但，[...]」是什麼語法。

現行條文

被封禁的影響被封禁的用戶可以閱讀條目、設定用戶參數，但當按「編輯」鍵時，會連到封禁頁面，解釋用戶被封禁的原因，以及列出解禁的方法。被禁用戶的IP地址會被「自動封禁」，但根據MediaWiki設定，就算用戶被永久封禁，其IP地址只會被封禁24小時。封禁不影響管理員或行政員行使被賦予的權限，但如若因條目爭議而被封禁，被封禁的管理員或行政員應當自律不就相關條目使用管理員權限，否則可能會被提請解除權限。

意外封禁有时候，浮动IP用户可能被封禁，这实际上是因为他们所使用的IP地址以前被破坏者使用过。如果可以更换IP地址，则问题一般可以解决。但如更換IP地址仍不能解決問題，則可於Wikipedia:權限申請頁面申請成為不受IP範圍封禁影響的用戶。

此外，模仿被封禁用户也可能导致意外封禁，因此，请勿模仿被封禁者和其破坏行为。

提議條文

整段刪除

變更說明

併入其他段落。「被封禁的影響」又是什麼語法。

現行條文

管理員注意事項本段講述管理員執行封禁時需要注意的事項，如想了解執行封禁的流程，請參閱Help:管理員操作手冊#封禁用戶。

教育用戶所有用戶均曾經是一個新用戶，而且每個人都曾犯錯。因此我們均不應傷害新手，我們歡迎他們，耐心教導他們，並假定他們都在嘗試對維基百科作出貢獻。在他們違反我們的方針和指引時，我們應該提示他們，避免他們進一步犯錯。管理員和一般用戶均可以模板或自行編寫的勸告（建議）提示犯錯的用戶，封禁應為最後的手段。

在執行封禁前，管理員必須確認該用戶已明白（或已被告知）相關的方針和指引（警告是其中一個方式），並已給予足夠時間讓他停止不當的行為。但管理員可在未經警告的情況下對一些進行被禁止行為（如操作傀儡、明顯破壞、人身攻擊等）的帳號進行封禁。在執行封禁後也應通知用戶，詳細請參閱知會用戶一段。

提議條文

封鎖指導教育用戶所有維基人應盡力在採取封鎖措施前優先考慮教育用戶遵守方針指引，並在其作出與方針指引精神相違背的編輯時予以提醒或警告。請歡迎且不要傷害新手並假定其有改善維基百科的意圖。較有經驗的維基人（包括管理員及一般用戶）應於發現新手犯錯時予以提醒或警告。用戶可使用一系列的警告模板用以發送簡單的罐頭提示，但按情況量身編寫的訊息更佳。封鎖應為最後的手段，管理員應當在封鎖違規的用戶前確認有關用戶知曉或已獲告知相關的規範，並已給予足夠時間讓其停止不當行為。僅用於明顯破壞、人身攻擊或為繞過封鎖的帳號不在此限並可直接封鎖。

變更說明

方針文體應儘量避免「我們」「他們」，稍有不正式的感覺。
重整語句。

現行條文

解釋封禁原因在維基百科，封禁是一件非常嚴重的事情。因此社群均認為封禁一個用戶需要有充足的理由，包括可供查證的證據、合理判斷及所有支持該封禁的因素。這些理由均應在進行複審時按複審人員的要求提供。

知會用戶在執行封禁時，管理員必須給予一個具體原因，讓被封禁的用戶知道自己被封禁的原因。在執行封禁的介面中，已有一些封禁原因可供選擇，管理員也可以輸入其他封禁原因。

除非有特別原因，管理員應在被封禁的用戶的對話頁解釋封禁原因，避免產生任何誤會。管理員可使用一些標準通知模板（請參閱Category:封禁模板和Wikipedia:模板消息/用戶討論名字空間）。

附加資訊如有需要，執行封禁的管理員可考慮在加入以下資料，以協助進行複審的管理員了解這個封禁：

一些不明顯或可能有爭議的證據；
可在不知會執行封禁的管理員的情況下解除封禁（如封禁前已有共識）的通知；
建議解封情況/條件。

保密資訊至於一些關乎個人私隱的證據，如通話记錄，則應發送到封禁申訴專用的郵件列表存檔，以便在有需要開展討論時供相關人員查閱。

提議條文

解釋封鎖原因封鎖對用戶的影響極為顯著，因此必須基於可查的證據及合理判斷，經詳細考慮才執行。所有封鎖的理由均應可在複審者提出要求下清楚提供。

知會用戶管理員必須在執行封鎖時給予清晰且具體地說明封鎖的理據。封鎖理由應避免使用內部術語以確保被封鎖的用戶能理解封鎖理據。在封鎖介面中有一些預設的封鎖理據供選擇，亦有欄目供輸入額外的封鎖原因及資訊。除特別情況外，管理員均應在被封鎖用戶的對話頁當中留下訊息通知用戶，管理員可使用一些標準通知模板（請參閱分類:封禁模板和維基百科:模板消息/用戶討論名字空間 § 封禁）；封鎖時清楚說明總會比後續再解釋容易。

附加資訊執行封鎖的管理員可考慮在加入以下資訊以協助複審者作判決：

不明顯、可能有爭議或其他可能相關的證據；
知會複審者解除封鎖用戶時不需通知執行封鎖的管理員；
建議的解除封鎖條件。

保密資訊關乎個人私隱的證據如通話记錄應發送到封禁申訴郵件列表存檔，以便在有需要開展討論時供相關人員查閱。

變更說明

重整語句。

現行條文

執行封禁區段IP封禁除了後述的建議外，區段IP位址封禁需要非常謹慎——封禁一塊區段IP位址可能影響大量用戶，但破壞者可更換IP地址繼續破壞。因此，管理員在區段IP封禁前，應先檢查多少用戶使用該區段IP，然後謹慎考慮封禁期限，儘量減低對其他用戶的影響。還有，IP位址不應被永久封禁。如真的需要對區段IP執行封禁，應建議受影響的用戶申請成為IP封禁例外用戶，使其不受影響。

區段IP封禁可以輸入CIDR型態區段以達成，常用/24或/16。遇到IPv6用戶時，可以參照mw:Help:Range_blocks/IPv6的位址範圍，一般使用/64～/48的區段。

全域封禁可以到m:SRG申請。

厘定封禁期限封禁的目的是預防被封禁用戶的不當行為進一步惡化，而不是懲罰該不當行為。因此封禁期限主要是根據用戶會否重返而定。如該用戶是某方針的慣犯，管理員應給予較長的封禁，以減低對維基百科的干擾，並避免增加維護工作的負擔。簡而言之，管理員在釐訂封禁期限時應考慮以下兩點：

該不當行為的嚴重程度；
該用戶是否初犯。

此外，在釐定同一行為的封禁期限時，對共享或動態IP地址的封禁期限一般應較對註冊用戶和靜態IP地址的期限短，以減低對其他使用該IP地址進行編輯的人士的影響。

雖然封禁期限應根據實際情況決定，但仍有一些可供參考的標準：

初犯者的封禁期限應為24小時，再犯者則應適當地加長封禁期限；
明顯只用於破壞的用戶應被永久封禁；
對於保護性封禁，其期限一般為需要保護的期限（通常為永久封禁）。

提議條文

執行封鎖

封鎖IP位址

快捷方式

WP:COLLATERAL

封鎖IP位址時需要非常謹慎：封禁IP位址可能影響不少用戶，但IP位址可能會變動，破壞者亦可能更換IP地址繼續破壞。因此，管理員應謹慎考慮封鎖時長以儘量減低對其他用戶的影響；在絕大部分的情況下不應永久封鎖IP位址。請務必在封鎖的IP位址與敏感組織或政府機關有關之時通知維基媒體基金會。

維基百科的封鎖功能支持對IP區段的封鎖，可透過在封鎖界面表單上輸入CIDR型態區段以達成，IPv4及IPv6的封鎖一般分別使用/24—/16之間及/64—/48之間的區段。IP區段封鎖比封鎖單一IP位址的影響更大，故在封鎖IP區段前應當檢查該段的編輯情況，在確認封鎖對維基百科利大於弊時才執行IP區段封鎖；如有需要可提請用戶查核檢查IP區段封鎖可能造成的影響。

獲授IP封禁例外權的用戶不受IP封鎖影響。

釐定封禁期限

快捷方式

WP:BLOCKDURATION

封禁的目的是預防不當行為而非懲罰，因此封禁期限應根據用戶是否有再犯可能而定。再犯者可被假定可能再次或頻繁出現同類擾亂行為而可被施予較長的封鎖以阻截擾亂及減低維護工作的負擔。簡而言之，管理員在釐定封禁期限時應考慮：

該不當行為的嚴重程度；及
該用戶是否初犯。

在釐定共享或動態IP位址作出類似行為的封禁時長時，共享或動態IP位址的封鎖時長一般短於註冊用戶和靜態IP位址的封鎖時長，由以減低對其他使用該IP位址的編者的影響。

雖然封禁期限應根據實際情況決定，但仍有一些可供參考的標準：

初犯者的封禁期限應為一天至數天，再犯者則應適當地加長封禁期限；
明顯只用於破壞的用戶應被不限期封鎖；
為保護用戶及社群而封禁的期限應為需要保護的時長（一般為不限期）。

變更說明

重整語句。

現行條文

解釋封禁原因在維基百科，封禁是一件非常嚴重的事情。因此社群均認為封禁一個用戶需要有充足的理由，包括可供查證的證據、合理判斷及所有支持該封禁的因素。這些理由均應在進行複審時按複審人員的要求提供。

知會用戶在執行封禁時，管理員必須給予一個具體原因，讓被封禁的用戶知道自己被封禁的原因。在執行封禁的介面中，已有一些封禁原因可供選擇，管理員也可以輸入其他封禁原因。

除非有特別原因，管理員應在被封禁的用戶的對話頁解釋封禁原因，避免產生任何誤會。管理員可使用一些標準通知模板（請參閱Category:封禁模板和Wikipedia:模板消息/用戶討論名字空間）。

附加資訊如有需要，執行封禁的管理員可考慮在加入以下資料，以協助進行複審的管理員了解這個封禁：

一些不明顯或可能有爭議的證據；
可在不知會執行封禁的管理員的情況下解除封禁（如封禁前已有共識）的通知；
建議解封情況/條件。

保密資訊至於一些關乎個人私隱的證據，如通話记錄，則應發送到封禁申訴專用的郵件列表存檔，以便在有需要開展討論時供相關人員查閱。

提議條文

解釋封鎖原因封鎖對用戶的影響極為顯著，因此必須基於可查的證據及合理判斷，經詳細考慮才執行。所有封鎖理據應可在複審者提出要求下清楚提供。

知會用戶管理員必須在執行封鎖時給予清晰且具體提供封鎖理據，且應避免使用內部術語以確保被封鎖的用戶能理解相關規範。在封鎖介面中有一些預設的封鎖理據供選擇，亦有欄目供輸入額外的封鎖原因及資訊。除特別情況外，管理員均應在被封鎖用戶的對話頁當中留下訊息通知用戶，管理員可使用一些標準通知模板（請參閱分類:封禁模板和維基百科:模板消息/用戶討論名字空間 § 封禁）；封鎖時清楚說明總會比後續再解釋容易。

附加資訊執行封鎖的管理員可考慮在加入以下資訊以協助其他管理員複審：

不明顯、可能有爭議或其他可能相關的證據；
知會複審者解除封鎖用戶時不需通知執行封鎖的管理員；
建議的解除封鎖條件。

保密資訊關乎個人私隱的證據如通話记錄應發送到封禁申訴郵件列表存檔，以便在有需要開展討論時供相關人員查閱。

變更說明

重整語句。

現行條文

永久封禁

方針快捷方式

WP:INDEF

永久封禁是一個永不失效的封禁。永久封禁通常用於防止嚴重干擾或威脅維基百科正常運作的行為，或嚴重侵犯維基百科政策的行為。這能避免該用戶的行為產生更多的問題。

對於社群來說，永久封禁一個用戶可被理解為完全禁止該用戶進行編輯（如無管理員解封的話）。但在一般情況下，我們建議給該用戶一個最後機會——在某段時間暫時解封該用戶，並在被觀察的情況下繼續編輯，以確保該用戶未來不再違反維基百科的政策。

提議條文

不限期封鎖

方針快捷方式

WP:INDEF

不限期封鎖（或稱永久封鎖）是指無失效時限的封禁，通常用於防止嚴重擾亂維基百科正常運作的行為或嚴重違反維基百科方針指引的行為。不限期封鎖或適合用以阻止持續的不當行為，但仍需注意同樣不應作懲罰之用。不限期封鎖並不代表永恆不可變，而僅代表未有訂立封鎖時長，封鎖不會自動過期解除。被不限期封鎖的用戶在合適的情況下可獲解除封鎖，並在讓其被觀察的情況下繼續編輯，以確保該用戶未來不再違反維基百科的不同規範。

變更說明

「永久封禁」並非「永久」而是「不限期」，尤其在於「可被申訴」一點就不是permanent而是indefinite而已。

現行條文

設定附加封禁方式在設定封禁時，可設定一些特定的封禁條件。但這些條件應適當使用，以下是一些使用指引：

自动将此用户最后所使用的，以及后续编辑所在的所有IP地址封禁$1：在封禁未經許可和運行出现問題的機器人帳號時，不應啟動自動封禁功能，以避免封禁機器人的操作者。但對运行惡意程式的機器人帳號，則應啟動此功能以避免進一步破壞。而對於註冊用戶或不合方针的用户名的封禁（除非该用户在使用大量傀儡作业），一般不建議啟動此功能，以避免影響其他使用同一IP地址的用戶進行編輯。
账号创建：在封禁不適當的用戶名時，不應啟動這個功能，以容許用戶建立一個適當用戶名。但封禁一些惡意建立的用戶名稱，或用於破壞的用戶時，則應啟動此功能。
发送电子邮件：此功能避免用戶在封禁期內使用電郵功能。此功能應只用於濫用電郵功能的被封禁用戶（如寄發垃圾郵件給用戶）——一般封禁不應啟動此功能，但管理員如認為被封禁用戶極可能會濫用電郵功能，可啟動此功能。如啟動此功能，請不要保護該用戶的對話頁（除後述濫用情況），並確保該用戶知道其他申訴的渠道。
编辑自己的讨论页：除非被封禁用戶持續濫用自己的對話頁（如多次重複（無新理據）的申訴），一般封禁不應啟動此功能。

而對於IP地址封禁，一般重用的設定可被稱為軟封禁（關閉“自動封禁”及“禁止此IP／用戶建立新帳戶”功能，并且“只封禁非注冊用戶”）。這種封禁方式容許註冊用戶登入進行編輯，是影響最低的封禁方式，一般用於封禁共用IP地址。但在封禁涉及註冊用戶時，則應啟動“禁止此IP／用戶建立新帳戶”功能，以避免該用戶利用傀儡繞過封禁。而硬封禁（禁止所有人士使用該地址登入或進行編輯，管理員及IP封禁例外用戶除外）則應用於对方持續建立新帳號（或稱為「即用即棄帳號」）進行破壞的情況。此外，一些被用作破壞的开放代理伺服器應被硬封禁，避免再次发起破壞行动。

提議條文

設定封鎖選項封鎖功能提供數個選項，以供在不同情況下作不同程度的封鎖之用：

編輯封鎖選項

全站范围封鎖剝奪用戶編輯除其用戶討論頁外的所有維基百科頁面的權限。此為預設選項，用於可合理相信該用戶會對任何頁面作擾亂性質的編輯的情況，例如純破壞用戶及不是來建設百科全書的用戶。
部分页面封鎖剝奪用戶編輯特定維基百科頁面或命名空間的權限；MediaWiki軟件限制每個封鎖限十個頁面，若需求超過限制則應考慮使用全站范围封鎖。

一般封鎖選項

自動封鎖用戶使用的IP位址會對該用戶最後使用的IP位址及所有其隨後嘗試用於編輯的IP位址添加為時一天的自動封鎖，沒有IP封鎖例外的用戶帳號在被自動封鎖的IP位址編輯亦會被阻止編輯。需注意在封禁未經許可和運行出现問題的機器人帳號時，不應啟動自動封禁功能，以避免封禁機器人的操作者。但對运行惡意程式的機器人帳號，則應啟動此功能以避免進一步破壞。而對於註冊用戶或不合方针的用户名的封禁（除非该用户在使用大量傀儡作业），一般不建議啟動此功能，以避免影響其他使用同一IP地址的用戶進行編輯。
账号创建封鎖選項阻止用戶在封鎖期間使用特殊:创建账户功能建立新帳號。在封禁不適當的用戶名時不應啟動這個功能，以容許用戶建立一個適當用戶名；但在封禁惡意建立的用戶名或用於破壞的用戶時，則應使用此封鎖選項。此封鎖設定會經自動封鎖及IP硬封鎖而套用於在受影響IP的位址登錄且未申獲IP封鎖例外的用戶之上。*发送电子邮件封鎖選項阻止用戶在封鎖期間使用特殊:电邮联系功能。此功能應只用於濫用電郵功能（包括但不限於發送垃圾訊息、恐嚇、騷擾等行為）的用戶，一般封禁不應啟動此功能；管理員如認為被封禁用戶極可能會濫用電郵功能，則可使用此封鎖選項。此封鎖設定會經自動封鎖及IP硬封鎖而套用於在受影響IP的位址登錄且未申獲IP封鎖例外的用戶之上。
编辑自己的讨论页封鎖選項會剝奪被封鎖用戶使用其用戶討論頁的權利，此使其無法經用戶討論頁進行封鎖申訴。此選項在大部分情況下不應使用，僅應在需阻止被封鎖用戶重複濫用自己的對話頁（包括但不限於：對社群進行各種威脅、恫嚇、騷擾；試圖公開他人個人資訊；刻意提供具誤導性之虛偽、不實陳述；以及多次重複申訴而無新申訴理據等情況）下使用此封鎖選項。
封禁使用该IP地址登录的用户選項僅在封鎖IP位址及區段時可用，此選項禁止未申獲IP封鎖例外的用戶帳號在被封鎖的IP位址及區段上使用被封鎖功能，如編輯、創建帳號及使用電郵聯繫功能。此封鎖選項僅應在被長期破壞者或傀儡操作者濫用、有長期且高密度破壞記錄或為開放代理所用的IP位置及區段上使用。

常見封鎖類型註冊用戶及IP位址的封鎖一般均分為兩種，分別可成為「軟封鎖」及「硬封鎖」，以下表格將說明對應的封鎖選項設定及常用情況。

封鎖類型封鎖對象	軟封鎖	硬封鎖
註冊用戶	封鎖設定：停用自動封鎖、容許帳號建立（兩個選項都取消選擇）對註冊用戶的軟封鎖僅禁止該特定帳號編輯而不影響其使用的IP位址。此設定適用於封鎖宣傳性用戶名及其他違反用戶名方針的情況，容許其創建符合用戶名方針的新帳號或繼續以IP編輯。	封鎖設定：啟用自動封鎖、停用帳號建立對註冊用戶的硬封鎖會將封鎖經自動封鎖延伸至其使用的IP位址，使用受影響IP位址且沒有IP封鎖例外的用戶均無法編輯。此設定常用於封鎖破壞者及攔阻其他擾亂行為。
IP位址及區塊	封鎖設定：僅限匿名使用者、停用帳號建立此封鎖設定容許註冊用戶登入進行編輯，僅阻止該IP位址的匿名編輯及創建新帳號，是影響最低的封鎖方式，一般用於封鎖共用IP地址。	封鎖設定：停用帳號建立、封禁使用该IP地址登录的用户此封鎖設定阻止任何沒有IP封鎖例外的用戶在受影響IP位址上編輯。此常用於阻止破壞者持續建立新帳號（或稱為「即用即棄帳號」）進行破壞的情況。開放代理伺服器亦應使用硬封鎖以防止不固定的匿名破壞。

變更說明

修正嚴重翻譯腔和擴充。

現行條文

無

提議條文

封鎖機械人

管理員可在自動化或半自動化編輯的機械人運作異常時封鎖機械人帳號，但必須注意封鎖機械人帳號的時候應當採用軟封鎖（停用自動封鎖）以免影響可能在同一IP位址上運作的機械人及其他編輯的用戶；若僅有單一任務出錯則建議不選擇封鎖而是停用有關任務。

未經審核批准或豁免審核運行的機械人帳號或用戶名因可能被誤會為機械人而違反用戶名方針的帳號可被即時不限期封鎖；若機械人操作者被封鎖，其操作的機械人屬其延伸編輯，故同樣應予以同等長度的封鎖。

變更說明

雖然好像有點重複但也補上去了。

現行條文

标记用户页对于已被永久封禁的用户，请根据以下程序标记此用户的用户页：

若此用户名具有极端侮辱性（比如需要监督），请务必删除此用户页（如有），并对之进行白纸保护。
其他情况下：
- 若此用户因滥用傀儡或被确认为他人的傀儡而被永久封禁，或在被永久封禁後被查出滥用傀儡或被确认为他人的傀儡，请务必以{{sockpuppeteer|blocked}}（对于滥用傀儡的用户）或{{blocked sockpuppet|主帐号}}（对于傀儡帐号）替换原有的用户页内容（如已建立用戶頁）或建立用戶頁（如未建立用戶頁），並对之进行永久全保护。
- 若此用户因其他原因而被永久封禁：
  - 如此用户已建立用戶頁，请以{{blocked user}}替换原有的用户页内容，並对之进行永久全保护。
  - 如此用户未建立用戶頁，請对之进行白纸保护，或以{{blocked user}}建立用戶頁後对之进行永久全保护。

提議條文

标记用户页对于已被永久封禁的用户，请根据以下程序标记此用户的用户页：

若用户名具有极端侮辱性（比如需要监督），请务必删除此用户页（如有），并对之进行白纸保护。
若用户因滥用傀儡或被确认为他人的傀儡而被永久封禁，或在被永久封禁後被查出滥用傀儡或被确认为他人的傀儡，请务必以{{sockpuppeteer|blocked}}（对于滥用傀儡的用户）或{{blocked sockpuppet|主帐号}}（对于傀儡帐号）替换原有的用户页内容（如已建立用戶頁）或建立用戶頁（如未建立用戶頁），並对之进行永久全保护；需拒絕承認的情況不在此限。
若用户因其他原因而被永久封禁：
- 如用戶頁已建立，请以{{blocked user}}替换原有的用户页内容，並对之进行永久全保护。
- 如用戶頁未建立，請对之进行白纸保护，或以{{blocked user}}建立用戶頁後对之进行永久全保护。

變更說明

本地規則不作實際變動，僅調整格式並添加DENY相關說明。

現行條文

如果你反对某个封禁如果你（作为管理员）反对另一个管理员实施的某个封禁，请与该管理员联系并进行讨论。一般需要以下理由中的一个：

封禁该用户的理由不成立；
封禁该用户的理由已经不存在了。

若該封禁為無限期封禁，反對該封禁的管理員須嚴謹處理，並先使用所有可行方法通知實施封禁的管理員，包括在其討論頁留言、發電郵和向unblock-zhlists.wikimedia.org邮件列表发邮件。若實施封禁的管理員已離開維基百科，應交由行政員處理。

如果一个封禁决定有明显的错误，而实施封禁的管理员又不在线，你可以解除该封禁。但务必解封之前通知实施封禁的管理员并在互助客棧其他區进行说明。明显错误封禁如：封禁理由是违反三回退原则，但很明显该用户只进行了三次回退。

有争议的封禁容易引起争议的封禁有：

对怀疑是傀儡的封禁；
对怀疑是被封禁用户的封禁；
对有贡献登录用户的封禁；
对进行扰乱性编辑用户的封禁；
对與閣下涉及條目編輯爭議的用戶的封禁；
缺乏方针支持的封禁。

如果管理员确信以上封禁有必要，请

更仔细的取证；
检查相关方针；
联系其他管理员共同讨论；
在封禁通告中详尽解释封禁原因；
做好与其他维基用户讨论的准备。

对一个用户不断的封禁和解封被称为車輪戰。車輪戰是十分有害的，要极力避免。解封之前尽可能同实施封禁的管理员讨论，并理解他们可能更了解整个事件的经过和细节。

提議條文

解除封鎖解除封鎖及縮短封鎖時長一般出現在被封鎖用戶提出封鎖申訴之時。其他管理員可獨立複檢封鎖理據、被封鎖用戶的過往行為、社群討論（包括封鎖前後）及其他相關證據和資訊判斷是否接納封鎖申訴並予以解除封鎖。常見解除封鎖的原因包括封鎖理據已不存在、承諾改善、封鎖的管理員不清楚實際狀況或明顯的判斷錯誤；需注意過往貢獻絕非免罪卡，不能作為免除封鎖的理據。

解除封鎖不可接受的情況

快捷方式

WP:NEVERUNBLOCK

在以下情況解除封鎖在絕大多數情況下是不可接受的：

構成管理戰（車輪戰）的情況；
解除封鎖自己的帳號（自己封鎖自己帳號的情況除外）；及
管理員未獲用戶查核員或監督員同意下解除指明為用戶查核或監督行動的封鎖。

違反以上任何一條均屬濫用管理權限而可被社群共識制裁（包括但不限於警告、封鎖、禁制或移除管理員權限）。

封鎖申訴

作為封鎖申訴的一部分，社群可參與申訴討論，執行封鎖的管理員則可能按情況被要求檢視並參與申訴討論提供更多資訊。由於封鎖申訴是第三方複檢的程序，管理員不應拒絕其執行封鎖的用戶所提出的申訴；一般而言針對同一封鎖的多次申訴會由不同管理員審閱。社群並未制定針對同一封鎖的申訴次數上限，但持續濫用申訴程序（包括但不限於作嚴重威脅、惡意指控或公開他人個人資訊或屢次重複申訴而無新申訴理據等情況）則可導致管理員禁止用戶使用其用戶討論頁的權限，但用戶仍可向封鎖申訴郵件列表（unblock-zhlists.wikimedia.org）進行申訴。

除包含明顯的錯誤（如封禁理由是违反三回退原则，但很明显该用户只进行了三次回退）外，管理員應當在解除用戶封鎖前通知執行封鎖的管理員（包括在其討論頁留言、發電郵和向封鎖申訴郵件列表发邮件）；若執行封鎖的管理員不活躍或無法與封鎖的管理員達成共識，應交由行政員處理或社群討論。管理員應當在處理涉及濫用傀儡、騷擾或公開他人私隱資訊的封鎖時加倍注意，不應在未瞭解事件全況和與執行封鎖的管理員討論前解除涉上述事項的封鎖。

任何用戶均可參與封鎖申訴的討論，但僅有管理員可處理解除封鎖請求。

解除臨時性質的封鎖臨時性質的封鎖應當在確認情況已解決的時候解除，此包括：

不再用作開放代理伺服器的IP位址及區段；
獲得審核批准或已修復故障的機械人；及
已撤回的法律威脅。

臨時性質的解除封鎖被封鎖用戶可獲暫時且臨時性質的解除封鎖以回應關於其封鎖的討論；此類解除封鎖仍然不容許用戶編輯註明的討論頁面以外的任何其他頁面，違反以上條件可致額外制裁。除非討論共識推翻封鎖，討論結束後應當恢復原先的封鎖。

有條件解除封鎖

快捷方式

WP:CONDUNBLOCK

管理員可在與被封鎖用戶及社群討論後為解除封鎖附加條件，旨在防止用戶重複引致封鎖的行為。

若被封鎖用戶與管理員無法就解除封鎖條件達成共識，被封鎖用戶可重新提出申訴。
管理員具有封鎖條件生效時長的決定權，但原時長不超過一年的封鎖的解封條件的生效時長不得超過一年，原時長超過一年的封鎖（包括不限期封鎖）的解封條件則無時長限制。
解除封鎖條件可包括但不限於頁面禁制、主題禁制、互動禁制、回退限制、使用帳號限制等；部分封鎖亦可作為解除全站範圍封鎖的條件。
違反解除封鎖條件或再作出可致封鎖行為的用戶可被重新封鎖並被進一步制裁。
獲有條件解除封鎖的用戶僅可向執行解除封鎖的管理員或管理員佈告板申訴解封條件。
有條件解除封鎖時應當在獲解除封鎖的用戶的討論頁上發送通知清楚說明解除封鎖條件，並應在解除封鎖日誌當中記錄解除封鎖條件的差異或版本連結。

變更說明

與其給予反對封鎖的指引不如明確解除封鎖的指引。
添加本地沒有實際執行的臨時解封和有條件解封以供選擇，感覺不少案件可以用得着。

現行條文

無

提議條文

全域封鎖

維基媒體元維基的監管員可使用全域封鎖擴展功能阻止IP位址及區段的跨維基站點擾亂行為，被全域封鎖的IP位址及區段被禁止編輯元維基以外的所有公開維基媒體站點，受影響的用戶就全域封鎖僅可在元維基全域佈告板進行申訴。全域封鎖與全域禁制有所不同，後者類似本地禁制屬正式褫奪用戶在所有維基媒體站點的編輯權利。

註冊用戶帳號無法被全域封鎖，對應的措施為全域鎖定，惟註冊用戶帳號仍可受全域封鎖影響而無法編輯。註冊用戶可申請全域IP封鎖例外以繞過全域IP封鎖繼續編輯。

變更說明

僅添加作說明之用。

望社群各成員協助複查並給予意見。--路西法人 2023年3月1日 (三) 03:32 (UTC)[回复]

仔細看了一下，解決了舊的問題，然後又產生了新的問題。很多句子您翻譯進去的句子也是翻譯腔和繁冗的，但我沒有時間一一指出。另外，「手段」沒有貶義。《漢語大詞典》中「手段」有四個義項，此處是義項2，「為達成某種目的而採取的方法和措施」，而非帶貶義的義項3。--Ghren 🐦🕐 2023年3月1日 (三) 05:02 (UTC)[回复]

比如說：「封鎖功能是管理員權限當中最具影響力的，管理員應當在執行封鎖前瞭解情況，並必須能夠佐證其執行的封鎖的依據」：「封鎖功能是管理員權限當中最具影響力的」，是不是「最具影響力」的呢，感覺很主觀。「必須」就是「必須」，「能夠」就是「能夠」，什麼是「必須能夠」呢。「佐證」就是提出證據證明，那後邊「依據」不就重複了。

「承諾停止不當行為並能展現已明白錯誤之處和汲取教訓或已停止不當行為一段時間的用戶可能可獲解除封鎖」，請問如何句讀。

「如執行了一個可能具爭議性的封鎖」：「一個」是典型的翻譯腔，然後「可能具爭議性」句意上也不是很清楚。

「保護目的的封鎖用於應對以下情形」：什麼是「保護目的」？

「「嚴重擾亂」包括不適合維基百科文明協作氛圍及影響讓參與者協作共建百科全書的行為」：為什麼不能放到下邊去呢。

「管理員可在發現被封鎖用戶操控其他帳號繞過封鎖編輯的情況下重設封鎖時長；被封鎖繞過封鎖期間若繼續有可致封鎖的編輯行為，管理員亦可考慮延長封鎖時長。」其實可以分成好幾個小句的，不需要一句過的。不過我覺得這段內容全部都應該歸到傀儡去就是了。--Ghren 🐦🕒 2023年3月1日 (三) 07:27 (UTC)[回复]

正是需要社群協助複查。

「手段」：我指的是negative connotation，雖然不是在此使用情況下帶有貶義，但也可以被借來說是那個貶義的意思就變成諷刺，改成「技術措施」就沒有這個問題，也是最factual的說法。
「~~封鎖功能是管理員權限當中最具影響力的。~~」刪了
「承諾停止不當行為並能展現已明白錯誤~~之處和汲取教訓或已停止不當行為一段時間~~的用戶可能可獲解除封鎖」改了。
「如執行了一個可能具爭議性的封鎖」是舊版本已存在的問題，我沒注意到這個。改成了「執行可能具爭議性的封禁時」。
「保護目的」亦是舊版本已存在的問題，指的是「保護用戶或社群」的標題。改成了「包括但不限於以下情形」，因為重譯版前面已經有說明了封鎖在什麼情況下保護用戶和社群。
「「嚴重擾亂」包括不適合維基百科文明協作氛圍及影響讓參與者協作共建百科全書的行為」不寫在下面是因為下面的是「不適合維基百科[...]的行為」的例子，而這個是定義。
「管理員可在發現[...]考慮延長封鎖時長。」問題似乎不是很大。re「這段內容全部都應該歸到傀儡」，其實應該兩邊都寫（

如發現更多問題歡迎再次提出。--路西法人 2023年3月1日 (三) 07:46 (UTC)[回复]

「防止扰乱」：扰乱一词一般特指POINT（即「为阐释观点而扰乱维基百科」），可能会导致误解。不过暂时没想到更好的词。 ——魔琴 [ 留言贡献新手2023计划 ] 2023年3月1日 (三) 10:54 (UTC)[回复]

全文所用擾亂是文字上的意思。基礎方針得常人看得懂，不應有暗含意義，故擾亂一次不會作POINT的意思（除非全寫）。--路西法人 2023年3月1日 (三) 11:02 (UTC)[回复]

那您为什么要突然去定义什么是「严重扰乱」呢。而且您这一句也不像是定义，而像是严重扰乱的一些例子。不论什么是「严重扰乱」根本和封禁方针的实行没有关系吧。--Ghren 🐦🕘 2023年3月1日 (三) 13:26 (UTC)[回复]

「不適合維基百科文明協作氛圍及影響讓參與者協作共建百科全書的行為」非具體例子，僅是定義何謂「可致封鎖的嚴重擾亂行為」，給了定義再給符合此描述的具體方針例子，怎麼沒關係了？--路西法人 2023年3月1日 (三) 14:11 (UTC)[回复]

您給我的留言感覺就是完全沒在讀舊版方針和我參照的英語版方針，這個也是舊方針已經存在的內容，我只是在paraphrase一下翻譯腔和整理語序，怎麼又成了我的問題了？英語版方針原文：A user may be blocked when their conduct severely disrupts the project; that is, when their conduct is inconsistent with a civil, collegial atmosphere and interferes with the process of editors working together harmoniously to create an encyclopedia.--路西法人 2023年3月1日 (三) 14:15 (UTC)[回复]

倒是修了個小筆誤，「…協作氛圍及影響讓其他參與者協作…」。--路西法人 2023年3月1日 (三) 14:23 (UTC)[回复]

本來想不要把一句沒有句讀寫很長，既然閣下看不懂那改成管理員可因用戶作出不適合維基百科文明協作氛圍或影響其他參與者協作共建百科全書的擾亂行為而實施封鎖。--路西法人 2023年3月1日 (三) 14:34 (UTC)[回复]

（1）“其中包括但不限於以下屬嚴重擾亂的行為”里面的“破坏”建议改成“故意破坏”，以减少歧义。（2）“不限期封鎖”后面加上“（又称永久封禁）”，因为永久封禁这个词语仍然相当常用。--GZWDer（留言） 2023年3月3日 (五) 10:05 (UTC)[回复]

（1）破壞定義已包含故意的意思。（2）加了，並改了一點字眼。--路西法人 2023年3月3日 (五) 10:21 (UTC)[回复]

但是有些人认为“破坏”来对应damage，所以这里用“故意破坏”可能会好一些。--GZWDer（留言） 2023年3月3日 (五) 11:57 (UTC)[回复]

非建设性编辑如何？--路西法人 2023年3月3日 (五) 12:17 (UTC)[回复]

“非建设性编辑”比“故意破坏”要广。--GZWDer（留言） 2023年3月3日 (五) 12:59 (UTC)[回复]

加了。--路西法人 2023年3月4日 (六) 01:02 (UTC)[回复]

(！)意見：敝人對路西法閣下所提供之草案全文表達微調意見，恕直接大塊呈現：

第一部分「首段」提議條文：

「管理員可在接納使用者申訴、認為封鎖缺乏適當依據、不再合適等情況下解除對使用者的封鎖（參見 § 解除封鎖）。封鎖與禁制有所不同：禁制是褫奪使用者在維基百科全站或若干部分之編輯權的正式措施，並不直接阻止使用者編輯頁面，但禁制也可以透過封鎖來執行。」個人認為標明紅色的該句具體語意似對一般讀者不甚明朗，有興趣的讀者可以直接詳閱禁制方針。

第二部分「原則」提議條文：

「封鎖應當具有遏制效果，以防止維基百科受破壞及擾亂，..........在一般不應以未持續發生且當前已無擾亂風險之事由作追溯式封鎖。

被封鎖使用者可發起封鎖申訴（參見 § 解除封鎖）。解除封鎖的請求同樣應以遏制、阻卻破壞性編輯和擾亂行為，或嘗試引導善意的建設性編輯作為考量。承諾停止不當行為，並能對相關規範展現具誠信之適當理解的使用者可能可獲解除封鎖；同樣地，在解除封鎖後持續出現相同不當行為的使用者，其封鎖申訴很可能會被拒絕以作阻嚇作用並強調行為不當和改善的必要。」。

第三部分「常見的封鎖原因」提議條文：

「執行可能顯具爭議性的封鎖時，則應以適當方式（如管理員佈告板）通知其他管理員進行複檢。管理員應當在對於新使用者需多加注意：..........但需注意使用者在被充分提醒或警告後持續不當編輯仍可被封鎖，此並不代表「不清楚維基百科的規則」可當作開脫責任的藉口而用戶拒絕或顯為不當理解相關規範亦非規避封禁等裁處的理由。」個人認為由於封鎖是否具爭議性須視情形而定，亦可能因各種用戶的主觀認知而有所差異，若要有爭議總會有爭議，難以一概而論；考量管理員本身應已具備之能力和機動性，可選擇適當的不同處置作為，達成風險降低或錯誤修正效果。另微調字面。

第四部分「保護使用者或社群」提議條文：

「.....包括但不限於以下情形：.....其他可能危害使用者安全的行為；..........持續在生者人物條目加入未能以可靠來源佐證，或顯可合理查知推定其為虛偽，或已經公開證實為不實陳述之誹謗內容；....」。此項所欲保護者為條目在世主角之生者法益，但是誹謗一詞涉事複雜，且各國或地區的法律標準、名目不一，即便可靠來源亦可能對公眾人物構成誹謗，又或者負面和爭議訊息經可靠來源報導散布亦仍可能涉及訴訟爭議，是否誹謗又須經法律認定，因此「未能以可靠來源佐證」或「可能存在誹謗」兩種情形在認定時可能出現矛盾，比如「能以可靠來源佐證」卻也「可能存在誹謗」，又或者傳主主張其為誹謗並訴諸法律，此時又該如何認定？極端而言，若傳主大量興訟，使相關載述事件皆進入法律程序，此時關於事件的公開傳述是否「可能存在誹謗」？以上情形，除已超出一般善意用戶之通常思慮和負荷能力，亦恐損及平台立意和公眾利益，而若無所設限也失去原先規範立意。因此，於此若未明指規限範圍，可能易生各種爭議，尤以若平台遭不當利用為甚。個人建議直接明指在此規範者為「未經可靠來源傳載，或顯明可合理查知其具備虛假陳述」之誹謗疑慮者即可。

第五部分「防止擾亂」提議條文：「在一般情況下，使用者在首次被封鎖前會收到數次警告，但執行封鎖時仍應當在被封鎖使用者的對話頁提供適當說明或理據以減少爭議」。

第八部分「繞過封鎖」之「代替被封鎖使用者作出編輯」提議條文：

「任何使用者不得代理或代表被封鎖使用者編輯，除非該等編輯明顯有益於維基百科，且代為編輯的使用者有合理且獨立的原因作出該等編輯。模仿被封鎖使用者編輯行為的新使用者（尤其是僅作此類編輯的使用者帳號）將可被視為傀儡或真人傀儡，並視具體情事被施以與其所模仿使用者同等的適當裁處。」個人認為「方向」一詞指涉過廣且難以界定，即便換為「編輯內容、行為或傾向」也是相當容易誤解；若實務上遇此類「疑似代理」行為，仍須就具體的編輯行為或內容檢視其是否為「協助」或「代理」被封鎖用戶進行編輯。

第十一部分「封鎖指導」之「教育使用者」提議條文：

「所有維基人應盡力在採取封鎖措施前優先考慮教育使用者遵守方針指引，並在其作出與方針指引精神相違背的編輯時予以提醒或警告。請歡迎且不要傷害其他新手，並假定其有改善維基百科的意圖。較有經驗的維基人（包括管理員及一般使用者）應於發現新手犯錯時予以提醒或警告。使用者可使用一系列的警告模板用以發送簡單的罐頭提示，但按情況量身編寫的訊息更佳。封鎖應為最後的手段，管理員應當在封鎖違規的使用者前確認有關使用者知曉或已獲告知相關的規範，並已給予足夠時間讓其停止不當行為。僅用於明顯破壞、人身攻擊或規避封鎖等被禁止行為的帳號不在此限，並可直接封鎖。」。

第十二部分「解釋封鎖原因」之提議條文：

「.......因此必須基於可查的證據及合理判斷，經詳細考慮才執行。所有封鎖的理據可在複審者提出要求下清楚提供。

知會使用者 管理員必須在執行封鎖時具體提供適當明確的理據。封鎖理由應避免僅使用內部術語以確保被封鎖的使用者能理解相關理據。.........

附加資訊 執行封鎖的管理員可考慮在加入以下資訊，以協助複審者檢視裁處：......」。「判決」一詞似過於正式，且對於站務行權恐生爭議。

第十三部分「執行封鎖」之提議條文：

「釐定封鎖期限 .......，因此封鎖期限應根據使用者是否可能重複不當行為而定。再犯者可被假定可能再次或頻繁出現同類擾亂行為，而可被施予較長的封鎖，以阻截擾亂及減低維護工作的負擔。簡而言之.....」。

第十四部分「解釋封鎖原因」（此段重複？）

第十五部分「不限期封鎖」之提議條文：

「不限期封鎖（或稱永久封鎖）是指無失效時限的封鎖，通常用於防止嚴重擾亂維基百科正常運作的行為，或嚴重違反維基百科相關適用規範的行為。不限期封鎖或適合用以阻止持續的不當行為，但仍需注意同樣不應作懲罰之用。不限期封鎖並不代表永恆不可變，而僅代表未有訂立封鎖時長，封鎖不會自動過期解除。被不限期封鎖的使用者在合適的情況下可獲解除封鎖，並在使其獲得社群適當觀察警醒的情況下繼續編輯，以確保該使用者未來不再違反維基百科的不同規範。」。

第十六部分「設定封鎖選項」之提議條文：

「帳號建立......，則應使用此封鎖選項。此封鎖設定會經自動封鎖及IP硬封鎖而套用於在受影響的IP位址登錄，且未申獲IP封鎖例外的使用者之上。

傳送電子郵件....，則可使用此封鎖選項。此封鎖設定會經自動封鎖及IP硬封鎖而套用於在受影響的IP位址登錄，且未申獲IP封鎖例外的使用者之上。

編輯自己的討論頁封鎖選項會剝奪被封鎖使用者使用其使用者討論頁的權利，此使其無法經使用者討論頁進行封鎖申訴。此選項在大部分情況下不應使用，僅應而在需組織被封鎖使用者顯為濫用自己的對話頁（包括但不限於：對社群進行各種威脅、恫嚇、騷擾；試圖公開他人個人資訊；刻意提供具誤導性之虛偽、不實陳述；以及多次重複申訴而無新申訴理據等濫用討論頁情況）下使用此封鎖選項。

封鎖使用此IP位址的登入使用者.....，此選項禁止未申獲IP封鎖例外的使用者帳號在被封鎖的IP位址及區段上使用被封鎖功能，如編輯、建立帳號及使用電郵聯繫功能。」。

第十七部分「封鎖機器人」之提議條文：

「未經審核批准或豁免審核運行的機器人帳號，或使用者名稱因可能被誤會為機器人而違反使用者名稱方針的帳號，可被即時不限期封鎖；若機器人操作者被封鎖，.....」。

第十八部分「標記使用者頁面」之提議條文：

「若使用者因濫用傀儡或被確認為他人的傀儡而被永久封鎖，或在被永久封鎖後被查出濫用傀儡或被確認為他人的傀儡，請務必以Template:略（對於濫用傀儡的使用者）或Template:略（對於傀儡帳號），替換原有的使用者頁面內容（如已建立使用者頁面）或建立使用者頁面（如未建立使用者頁面），並對之進行永久全保護；需拒絕承認的情況不在此限。」。

第十九部分「解除封鎖」之提議條文：

「封鎖申訴 作為封鎖申訴的一部分，社群可參與申訴討論，執行封鎖的管理員則可能按情況被要求檢視、參與申訴討論，提供更多資訊。.........社群並未制定針對同一封鎖的申訴次數上限，但持續濫用申訴程序（包括但不限於：對社群進行各種威脅、恫嚇、騷擾；試圖公開他人個人資訊；刻意提供具誤導性之虛偽、不實陳述；以及多次重複申訴而無新申訴理據等情況）則可導致管理員禁止使用者使用其使用者討論頁的權限，但使用者仍可透過封鎖申訴郵件列表（unblock-zh@lists.wikimedia.org）進行申訴。...........

臨時性質的解除封鎖......，違反以上條件可處以額外制裁。除非討論共識推翻原先裁處的封鎖，否則討論結束後應當恢復裁處結果。

有條件解除封鎖 管理員具有封鎖條件生效時長的決定權，但原釐定封鎖期限不超過一年者，其解除封鎖條件的釐定時長不得超過一年；原釐定封鎖期限超過一年者（包括不限期封鎖），其解封條件的釐定時長不得超過三年、解封條件約定之再犯釐定時長不得超過五年。若解除封鎖條件方案包含社群觀察期，釐定觀察期限為三個月起算，不得超過被封鎖使用者實際獲處之解封條件時長。若解除封鎖條件方案內含要求顯有違被封鎖用戶參與初衷和能力，或無涉其違規情事或公開申訴內容，或違反公序良俗者，自始無效。.........違反解除封鎖條件或再作出可致封鎖行為的使用者可處重新封鎖並被進一步制裁。」。--Kriz Ju（留言） 2023年3月7日 (二) 23:44 (UTC)[回复]

提議于新版中增應對口吻限制

現行條文

無

提議條文

同封禁者溝通一位維基百科使用者封禁與否，不代表其身爲維基百科社群用戶擁有受尊重權利的喪失，亦不應以仇視或明顯輕蔑之語氣批判、侮辱該使用者。誠然，見到維基百科被破壞或可能的擾亂行爲，您或會想“義憤填膺”地批判當事人，但刻薄的批評往往會有激化矛盾的風險。如果您想參與有關此用戶封禁事務的討論，請盡可能以冷靜的口吻指出其犯下的過失，或以此給出相應的個人意見或建議。

此外我不建議將封禁與禁制的方針修訂一并討論，這可能會造成排版上的混雜（以及討論注意力的分散）。我個人建議分爲兩個不同的討論串。至於設立上述條文的目的只有兩個：以合適的態度應對封禁及違規用戶，以及減少任何製造LTA的可能。——WMLO（留言）。 2023年3月6日 (一) 23:21 (UTC)[回复]

(－)反对，內容與方針及論述並不盡相符，更有不少用詞是相關方針沒有的。「不代表其身爲維基百科社群用戶擁有受尊重權利的喪失」無法連結到用戶行為不文明；「刻薄」一詞過於廣泛，嚴重程度從「unkind」、「harsh」到「mean」都可以叫做「刻薄」，定義非常廣且空泛，前兩者並不完全違反文明及禮儀方針，對事不對人的批評往往屬於前兩者，甚至警告訊息也能被很多人理解為「待人嚴苛」即「刻薄」的定義，而維基百科運營實務上顯然不認同此看法。在不人身攻擊、不侮辱人格且對事不對人的情況下，任何批評都不是違反文明方針或禮儀的行為；被封鎖者態度差異可以很大，對有禮瞭解自己錯誤且願意承擔者有禮、對堅拒承認錯誤者嚴厲是天經地義，顯然一刀切對所有被封鎖用戶（包括態度惡劣者）連批判（criticize）都「不應」絕不合理，提案人建議的內容僅僅給其他用戶過度詮釋文明方針和禮儀指引以拒絕接受合理意見的空間，實務上即使寫得多精準也僅僅是在複述其他方針，完全沒有必要寫在封鎖方針內。--路西法人 2023年3月7日 (二) 00:33 (UTC)[回复]

對於很可能具有善意但一直覺得自己是對的用戶（正如Mosowai一案），你這樣的態度就推動了寧可過度客氣教他不成就隨他被拒絕申訴及繼續維持封鎖，也不要罵醒他讓他真正知道錯誤的做法，完全無助於解決封鎖背後的起因事件。--路西法人 2023年3月7日 (二) 01:05 (UTC)[回复]

用詞符不符合，並不妨礙此草案援引這類方針及論述背後精神，規則只是原則。而禮儀同文明訂立的原則便是避免激化衝突，以造成不和諧的討論氛圍或避免用戶將討論頁面當作不滿情緒的宣泄口。而刻薄、仇視及輕蔑語句顯然屬於這類事務。另夾帶著事物針對該人本身的，言語激烈批評的程度甚於超脫用戶本身的只爲發泄自己情緒目的的言語在某些案例中屢見不鮮（在Mosowai一案中含當事人在内有四名用戶認爲你的用詞不妥）。我就是一刀切對所有被封禁用戶，包括那些態度惡劣的。我反對的不是批判本身，而是刻薄的批判：第一這沒有什麽必要，第二用言語罵他通常只有兩個結果：放棄自己堅持的自尊在你面前承認錯誤；被言語激怒后持續與你展開舌戰。出於人類的感性慣性有相當一部分人屬於後者。而從功利主義的角度來看，與其包裹著方針用激烈刻薄的言語批判他含著激化矛盾甚至製造為報復社群的LTA的行爲風險，還不如以另一種口吻與他接觸。再退步說，當平常的講道理都無法説服他時，您用另一類“罵醒”式發言也只是在前者的基礎下加點火藥味罷了。——WMLO（留言）。 2023年3月7日 (二) 14:30 (UTC)[回复]

此外，也請您莫要模糊嚴厲與刻薄之間的界限轉而將其包裝成所謂的“合理意見”；我一向認可適當的嚴厲或直言不諱，比如Nanachi、薏仁将兩位就在Mosowai一案中以適當的這類言行指出了他的錯誤。而您的言行不可否認也有合理的地方，但留言中參雜的情緒甚至於激化了你與他之間的矛盾，有些語句也顯然是沒有任何必要的：需要我再引用閣下那三句“完全无助于解决封禁背后的起因事件”的文段麽？直言不諱地說，我認爲閣下的言行和另一位管理員的重刑都是把他逼走的重要一環，這時教育用戶的目的達到了麽？又是否符合本站的精神？我引用菲茨傑拉德的一句話“當你要批評別人時，你切要記著，不是人人都有你那樣的條件。當然，草案細節可以再議。但我認爲仍然有必要添加這類條文以限制用戶在封禁事務中的言行避免矛盾的激化。—WMLO（留言）。 2023年3月7日 (二) 14:32 (UTC)[回复]

对于LTA，现行方针应该是「不接触、不理会、不承认」。对于封禁用户，应该适用于普通用户的规则，你这句话放到处理普通用户之间冲突那里都没有问题。----Cat on Mars 2023年3月7日 (二) 01:41 (UTC)[回复]

重修禁制方針

由於近期有用戶在處理持續出沒的破壞者時出現誤會一事，建議在禁制方針正式引入本地全站範圍禁制供社群正式制裁用戶剝奪參與本站編輯權利，類同全域禁制的本地版；建議添加該項而不併入不限期封鎖是鑑於不限期封鎖並不代表禁止編輯，有不當用戶名軟封鎖和機器人出錯的封鎖等。此外，建議將「編輯禁制方針」更名為「禁制方針」，互動禁制和電郵禁制不是編輯權的一部分而是行為的制裁。--路西法人 2023年3月1日 (三) 03:32 (UTC)[回复]

首先中文版和英文版ban的概念不同，英文版的ban是根据社群共识的正式行为（site ban强于indef block），中文版是一种一种比block弱的管理手段（Wikipedia:互助客栈/其他/存档/2019年3月#建议编辑禁制）；此外“根据社群共识所执行的编辑禁制”中文版有显著的反对意见（例如这个场景）。--GZWDer（留言） 2023年3月3日 (五) 03:17 (UTC)[回复]

感謝閣下指出過往討論，我也有研究過，但編輯禁制方針本來就是社群明確反對及後慢慢達成共識而通過的最佳例子。社群討論過並不代表不能再討論，且在上次討論後經歷過不少大事，社群的看法很可能有改變的情況。只要討論制定得宜，過往討論並不能做為不改變的原因。請閣下容我完成新建議版本的編寫再提出更對意見，此僅為佔位討論串，您也可以看到我連條文都還沒提出。--路西法人 2023年3月3日 (五) 04:12 (UTC)[回复]

過往社群屢次反對社群禁制措施的主要原因之一是擔憂制度被濫用打壓異見社群，但經歷OA2021後社群的環境是顯然可見地改善了。

即使是OA2021發生當下，社群內亦沒有出現奪權或打壓的情況，最終討論出來也只有有限度制裁措施，試圖完全打壓整個社群（例如要求正式制裁WMCUG）的提案完全沒能通過，最終只是有限度地移除特定連結和掛模板告知OA2021；OA2021後基本上再未出現管理員操控打壓特定社群並包庇特定用戶的情況。這些證明了：

濫用制度打壓異見社群並非源自權限而是源自人的問題，要用「擔憂被用作打壓異見社群」這點來說那您維連封鎖權限都不能有；及
現時中文維基百科各立場社群顯然比以前的更平衡和互相制約、更能求同存異，再出現同樣程度的集團式操控社群的機會不大。

在社群已經恢復正常的情況下，我覺得現在是適合探討重整禁制制度的合適時機，但基於過往社群討論的考量，確實可以在以英維版本作為基礎重修的同時制定更能防止集體濫用程序的情況發生。--路西法人 2023年3月3日 (五) 09:22 (UTC)[回复]

社群正常也不意味着未来不分裂。甚至可能在Wikipedia:管理員解任投票/Shizhao的时代（约2010-2011年）社群已经出现了拉帮结派问题（虽然和后来的问题不是一回事）。--GZWDer（留言） 2023年3月3日 (五) 10:00 (UTC)[回复]

還是那句，功能、程序設計再好也還是可以被人濫用，我們該做的是排除被濫用的機會而非為了不被濫用而不改善。--路西法人 2023年3月3日 (五) 10:03 (UTC)[回复]

XX族的名稱是否違反中立原則

編輯@JNO1：指出「條目名稱中有族的為非中立，會造成誤解」，希望建立方針，排除有族名的條目。提出討論，是否要建立這樣的方針。--Alfredo ougaowen（留言） 2023年3月7日 (二) 13:48 (UTC)[回复]

我的立場，條目名稱以有充份可靠來源的名稱為準，其次以先建者為準。如果維基同意他的方針，我也無話可說。--Alfredo ougaowen（留言）

我的立場是條目名稱應採用不會產生歧義的命名，且僅限於中國上古時代，將現代民族的命名排斥「族」是Alfredo ougaowen的立場--康族（留言） 2023年3月7日 (二) 15:22 (UTC)[回复]

[1] 「地區」指非國家之獨立或高度自治政治實體。

[2] 雖然俄罗斯在其憲法上為联邦制國家，然而由於其国体高度中央集权，本條文在處理上不將俄羅斯視為採用聯邦制或類似政治體制的國家。

[3] 就共產主義國家與朝鲜民主主义人民共和国而言，僅限其常設機關的成員適用，如全国人民代表大会的常設機關為其常務委員會。

[4] Jiao, Wenxiang; Wang, Wenxuan; Huang, Jen-tse; Wang, Xing; Tu, Zhaopeng, Is ChatGPT A Good Translator? A Preliminary Study, arXiv, 2023-01-31 [2023-02-11], doi:10.48550/arXiv.2301.08745

[1]

[2]

[3]

[1]

查论编布告板
以灰色標註者尚未正式啟用
一般	管理員行政員教育專案首頁錯誤志愿者回覆團隊監督權限一般機器人機器用户解除權限
條目與內容	疑似侵權可靠來源尋求資源垃圾链接黑名單白名單標題黑名單白名單受限制文件翻譯
頁面處理	合併匯入發送大量訊息移動机器人作业保護刪除修訂版本存廢討論頁面檔案覆核查詢已刪除內容
用户行為	利益衝突著作权调查破壞編輯爭議其他不當行為禁制傀儡調查調查助理不當用户名
其他	更改用户名防濫用過濾器新增或修改回報錯誤問題知識問答新條目徵求意見分類索引討論頁話題索引互助客棧消息方針技術求助條目探討其他字詞轉換地区词候选修復請求各地維基人
維基百科布告板

查论编徵求意見（全部）
條目主題	傳記（`bio`）經濟、貿易與公司（`econ`）歷史與地理（`hist`）語言及語言學（`lang`）數學、科學與科技（`sci`）媒體、藝術與建築（`media`）政治、政府與法律（`pol`）宗教與哲學（`reli`）社會、體育運動與文化（`soc`）
非條目主題	維基百科格式與命名（`style`）維基百科方針與指引（`policy`）維基專題與協作（`proj`）維基百科技術議題與模板（`tech`）維基百科提議（`prop`）未分類
提示	要將某一個討論加入上述列表中：在討論頁中的對應討論章節頂端加上`{{rfc\|xxx}}`標籤，其中「xxx」為分類縮寫。各類分類縮寫已列於上方項目中，並應將其插入`{{rfc}}`中。多個分類請使用管道符號分開，如`{{rfc\|xxx\|yyy}}`，其中「xxx」為第一個分類，「yyy」為第二個分類。
更多資訊請參閱維基百科:徵求意見。請在維基百科討論:徵求意見回報有關錯誤。本列表由LuciferianBot於每個小時進行更新。