Wikipedia:互助客栈/方针

互助客棧： 消息  方针  技术  求助  条目探讨  其他 |  知识问答

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

公告欄

• [公告] 調整COVID-19條目共識的規定、規範日本選舉條目命名及禁止有關藝人演出的獨立列表條目羅列非固定參與的節目已經通過。
• [公告] 抄襲論述併入不要包含原始資料的副本指引、不限期不是永久-解封指引與第二次機會、在本地启用安全投票及electionadmin权限、規範資訊框內母公司子品牌的列出方式及修订用户名方针与用户页指引正在公示，如有意見請儘快提出。
• [討論] 互助客栈方针区正在討論赋予过滤器助理过滤器编辑权、將格式手冊移動到MOS命名空間下、在非原創方針新增例子以禁止綜合常識及可靠來源、擴充ITNR獲選類別及根据WP:用戶頁对WP:用戶框进行修订，請踴躍參與討論。
• [討論] 互助客栈技术区正在討論修订过滤器警告信息，請踴躍參與討論。
• [討論] 互助客栈条目探讨区正在討論請求協助批量移動日本參眾兩院選舉條目及有關日本內閣條目的命名問題，請踴躍參與討論。
• [討論] 互助客栈其他区正在討論是否应关闭中文维基百科以抗议基金会举措、管理人員任免制度檢討等事及本地部署安全投票及相关权限，請踴躍參與討論。
• [討論] 互助客棧試行案討論區正在討論討論遞進機制試行案-檢討意見分享，請踴躍參與討論。
• [廣告] 第四屆臺灣－斯洛伐克編輯松正在進行中，直到12月31日結束，歡迎踴躍貢獻！

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

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	关于Wikipedia:避免地域中心#地理，建议增加关于“来”字的论述	29	11	航站区	2024-12-09 14:46
2	修订WP:外文重定向方针与首句MOS:外语名称格式指引，并将他们对应	79	7	自由雨日	2024-12-14 16:51
3	傀儡方针新增“被容许使用多重账号的行为”的情况（教育专案）	17	7	Reke	2024-12-06 01:09
4	將WP:格式手冊所有方針與論述移動到MOS命名空間，並將MOS命名空間更名為「格式手冊」	41	8	SunAfterRain	2024-12-13 16:47
5	应根据WP:用戶頁对WP:用戶框进行修订	36	12	暁月凛奈	2024-12-13 18:12
6	赋予过滤器助理修改滥用过滤器权限	37	9	ATannedBurger	2024-12-14 12:10
7	提議維基百科:抄襲併入維基百科:不要包含原始資料的副本	37	7	HK5201314	2024-12-14 11:54
8	請求社群關注仲裁委員會在管理員的離任討論中相關的權限問題	18	6	Gluo88	2024-12-14 05:08
9	重新讨论NT:MUSIC	16	8	Talimu0518	2024-12-14 19:08
10	維基百科:命名常规 (人名)中的例子姜太公已经移动	3	3	魔琴	2024-12-13 05:23
11	建議Wikipedia:愛好者內容擴增「交通迷內容」方針之請求與討論	6	3	HK5201314	2024-12-14 11:43
12	被不限期封禁用户不应默认复审移除IP封禁豁免权限	27	7	Heihaheihaha	2024-12-14 19:35

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

正在廣泛徵求意見的議題

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

維基百科格式與命名

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

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

(－)反对，標題為東立正式名稱[1]。--HelloYu0910（留言） 2024年11月21日 (四) 07:14 (UTC)

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

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

Wikipedia:消歧义#条目的命名：「請注意所使用的消歧義詞亦應符合命名常規。」這裡需要符合的是Wikipedia:命名常规#地名，即使用「湖南省」。另外本條目就是「南華大學」，括弧及其內的文字只是本站用來消歧義的，而中国地质大学（北京）就是「中国地质大学（北京）」，並不類似。--紺野夢人 2024年11月24日 (日) 07:44 (UTC)

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

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

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

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

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

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

維基百科方針與指引

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

此前，互助客棧方針版的長度一度逾60萬位元組，在我搬運了若干已結束或stale了的討論後才降到40多萬，然而這個長度還是比起其他互助客棧的版塊來得長（互助客棧其他版的長度現在是20多萬位元組，條目探討版是10多萬，消息、技術與求助版不超過10萬），而且在頁面載入與編輯上也產生了一些問題（我在電腦嘗試載入或編輯頁面的話，頁面完全載入所需的時間顯著地延長了）。有鑒於此前曾有討論提議以WP:徵求意見機制取代互助客棧方針版的機能，我認為現在是合適的時機來提出這件事情。Sanmosa _新朝雅政 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:管理員的離任 § 仲裁委員會成立後的管理人員解任機制（續）

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

1. 彈劾機制；
2. 糾舉機制；
3. 直接除權；及
4. 依請求介入社群程序。

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

--路西法人 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:关注度 (人物)如下：

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

提議條文 現任、曾任及／或候任國際級、國家／地區級及／或（採用聯邦制或類似政治體制的國家的）一級行政區級權力機關的重要實權公職及／或立法機關成員。 参考資料

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

維基百科提議

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

原标题：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考虑向印度法院披露编辑身份信息，英维正在讨论关站抗议

参见：亚洲国际新闻诉维基媒体基金会案、Wikipedia:頁面存廢討論/記錄/2024/11/14 § 亚洲国际新闻诉维基媒体基金会案、en:Wikipedia:Community response to Asian News International vs. Wikimedia Foundation、en:Wikipedia:2024 open letter to the Wikimedia Foundation和en:Wikipedia talk:2024 open letter to the Wikimedia Foundation § Update from 14 November hearing

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

整理引导新手的相关页面

目前用以帮助新人的页面实在庞杂。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：你是指怎樣安裝小工具的教程還是怎樣使用小工具的教程？（雖然我感覺兩個教程都能編製一下就是了）Sanmosa _{Συ γάρ μοι και μοίρα εί και τύχη} 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)

这块应该申请已经较为便利了，重点应该在怎么编辑（看懂Wikitext、使用Wikitext之类的）--Evesiesta_{COVID-19感染中} 2023年3月11日 (六) 02:36 (UTC)

關注度指引改名事宜

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

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

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

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

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

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

可行的方案：

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

相关链接：

• Temporary policy: ChatGPT is banned - Meta Stack Overflow
• Should ChatGPT be used to write Wikipedia articles? - Slate

以上。--Diskdance 2023年1月28日 (六) 01:42 (UTC)

原則上支持，但不論是禁制還是審閱如何自動分辨為需要審核或禁止？人工難以審核每一個新頁面和版本差異確認沒有AI編寫內容。--路西法人 2023年1月28日 (六) 01:47 (UTC)

以Stack Overflow為例，他們唯一能實際做的是在有用戶被發現疑似使用ChatGPT的時候才予以禁制，無法杜絕有關內容的發佈。您的兩個建議方案都涉及審核所有ChatGPT寫的內容，除了一般的舉報外如何做到？還是只能跟現在的侵權提報一樣有人發現才報？--路西法人 2023年1月28日 (六) 01:50 (UTC)

不认为您的方案可行。ChatGPT等工具并不像Google Translate那样输入和输出总是相同，很容易受到使用者的影响，不是能够直接禁止的。社群似乎也不具备人工审核每一笔编辑的能力。若要求使用此类工具的用户主动声明倒是可以，但也定然不是所有用户都会主动声明。同时，用户也可能是生成后自行润色，将其质量提升到可接受的标准后再发布。—— 月_樱_雪 (留言) 2023年1月28日 (六) 01:54 (UTC)

1不实际可行，缺乏有效检测手段。2在当前意义不大，条目本应被巡查，没有必要“歧视”。如有滥建、批量建立发生，按寻常规则处理即可，判断是否出自AI及质量如何没有依据。对要求申报表示支持，参考机器人、有偿编辑等方针，但落实存难度会变成君子协定。--YFdyh000（留言） 2023年1月28日 (六) 03:09 (UTC)

这是恶意推定，我不知道使用ChatGPT造成何种破坏或者违法哪一方面的规则。--Cat on the Mars 2023年1月28日 (六) 03:56 (UTC)

这个时候就得搬出User:0xDeadbeef在英维举出的例子了。以下是使用ChatGPT生成的关于Rust for Linux的条目片段（方便不懂相关领域的编者，部分术语我自己添加了内链）：

Rust for Linux是向Linux内核项目提交的一系列补丁的总称，这一系列补丁让Rust语言可以用于编写内核组件。该项目始于2017年，由一群对将Rust用作系统底层开发感兴趣的志愿者发起。

Rust for Linux is a series of patches to the Linux kernel that adds the Rust programming language as a second language for writing kernel components. The project was started in 2017 by a group of volunteers who were interested in exploring the use of Rust for low-level systems programming.

早先的补丁是与Linux内核维护者以及开源群体一同合作开发而成的。这些补丁聚焦于将Rust的内存安全以及并行特性带入内核当中，同时提供对已有的C语言代码基础的相容性。

The initial patches were developed in collaboration with the Linux kernel maintainers and other members of the open-source community. They focused on integrating Rust's memory safety and concurrent programming features into the kernel, and on providing compatibility with the existing C codebase.

在2018年，这些补丁被合并至Linux内核代码库当中，令Rust成为第一门除C语言之外，获官方支持可以用作编写内核组件的语言。对于Rust语言社群来说是里程碑式的成就，展示了Rust语言可以胜任内核级别编程的需求。

In 2018, the patches were merged into the mainline Linux kernel, making Rust the first programming language other than C to be officially supported for writing kernel components. This marked a significant milestone for the Rust community, as it demonstrated the language's ability to handle the demanding requirements of kernel-level programming.

自Rust语言加入至Linux内核之中起，Rust for Linux项目持续发展，当前聚焦于改善Rust在内核中运作的兼容性以及效率。该项目还吸引了其他操作系统开发者的注意力，令他们对将Rust语言用作内核级别编程所带来的潜在优点感兴趣。

Since its inclusion in the Linux kernel, the Rust for Linux project has continued to evolve, with ongoing work on improving the compatibility and performance of Rust in the kernel. It has also attracted the attention of other operating system developers, who are interested in exploring the potential benefits of using Rust for kernel-level programming.

我就问一句，这么有模有样的段落你能发现这里面捏造了好几个关键事实吗？你们还觉得这不会造成破坏吗？ --MilkyDefer 2023年1月28日 (六) 09:12 (UTC)

注：我自己能注意到的捏造事实如下

• Rust for Linux项目起始于2020年，不是片段中宣称的2017年；
• Rust for Linux项目代码合并至Linux内核是在2022年，不是片段中宣称的2018年；
• 当前Rust for Linux还没有达到有闲心改善兼容性和效率的地步，当前只有最基础能让编译顺利通过的部分。

有这么方便的工具那些喜欢搞鬼祟破坏的LTA们简直笑开花了啊。 --MilkyDefer 2023年1月28日 (六) 09:16 (UTC)

另外不要忘记维基百科是自然语言处理领域重要的数据集来源，我们有义务不要搞出垃圾进入维基百科又被提取成训练垃圾生成器的原材料的事情。--MilkyDefer 2023年1月28日 (六) 09:21 (UTC)

我认为鉴于ChatGPT的现状，应该将它按对待人类新手的方式处理，事实上就内容而言我们也无法区分新手和机器人之间的区别，何况你站已经封禁了绝大多数代理网段，仅仅凭借实验内容无法证实其破坏性或者真的有人会用来破坏，加上理论上ChatGPT还在使用旧的数据集，分辨拙劣过时内容远远比分辨是否是高级AI作品更加具备可行性也更加重要，暂时没有必要就这件事因“人”立法，如果需要修改方针必须证明现有方针在哪一方面无法满足你的需求（包括劣质训练集，还不如去改进你站存废积压）。--Cat on the Mars 2023年1月28日 (六) 09:38 (UTC)

再新手也不会写出金玉其外败絮其中的内容，真正的新手是写出来读出来就像是新手。你说的这不是新手，是破坏者。--MilkyDefer 2023年1月28日 (六) 09:44 (UTC)

你维的毛某人浪迹天涯多少年了，这种抓不出来其他更是抓不到，你维有长过记性了吗，我说过不要因人立法，不是因为一会儿折毛，一会儿ChatGPT，封个把人就能解决的事情，ChatGPT就我的实际体验还不具备单独作案的能力，我刚刚想要让他搞点引用都得费神很久，像这么一大段无来源内容理所应当就是劣质内容，巡查员应该有自己的判断。----Cat on the Mars 2023年1月28日 (六) 10:01 (UTC)

本人基本同意CatOnMars的观点。--0xDeadbeef（留言） 2023年1月28日 (六) 10:17 (UTC)

至少举例中如果缺少来源（或者来源能通过编辑者审阅并确认过的话），还是能区分出行文问题。需要注意但不至于需要规例。——Sakamotosan路过围观 | 避免做作，免敬 2023年1月29日 (日) 00:41 (UTC)

(！)意見 我认为把可供查证做好就能避免大部分问题。--Taeas（留言） 2023年1月28日 (六) 12:10 (UTC)

• (＋)支持。我當然知道實際上禁之不絕，但態度還是要擺出來。--Temp3600（留言） 2023年1月28日 (六) 19:56 (UTC)

  我认为标题中说的“限制”就可以了，不必要禁止也难以禁止（如何分辨，难道搞一个ChatGPT检查器之类的？[2]但准确度又如何？）,非常同意Temp3600的意见，“態度還是要擺出來”--百無一用是書生 (☎) 2023年1月29日 (日) 03:11 (UTC)

  刚才用chatgpt-detector检测了一下上面的例子Rust for Linux，英文都能正确识别是ChatGPT，但翻译成中文就认为是人类了--百無一用是書生 (☎) 2023年1月29日 (日) 03:19 (UTC)

提问：ChatGPT是否会造成目前方针无法处理的破坏？如果有，是否说明目前的方针存在漏洞？--Steven Sun（留言） 2023年1月29日 (日) 03:44 (UTC)

按WP:破坏处理。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年1月29日 (日) 04:34 (UTC)

(＋)支持，MilkyDefer给出的例子已经很明显了，用于破坏实在是太过简单。--BlackShadowG Slava Ukraini! 2023年1月29日 (日) 04:27 (UTC)

支持禁止，列入行为方针即可。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年1月29日 (日) 04:32 (UTC)

我是持怀疑态度。首先是无法检测、无法证明。任何一段文字，就算GPT检测器说是GPT写的，你无法看到那个人把这段文字从GPT复制下来贴上了。第二，ChatGPT用法多种多样，不应该所有用法都不能用。我特别喜欢叫他帮我找错别字，和从其他语言翻译成中文。应该还有很多无破坏性的例子。Last but not least，现有规则已经可以cover ChatGPT造成的破坏。难道现在加一条说ChatGPT做好事也不行？--Gqqnb（留言） 2023年1月29日 (日) 13:01 (UTC)

我倒是有点想开了，维基百科又不是检查你们做大学作业，有些学校会怀疑是不是你自己写的，你只要写出来了，巡查员检查过了，我管你是怎么写的。我不明白有些人的逻辑，只要这种东西能够用来破坏，「很容易用来破坏」，那这种东西就一定要禁止，是不是你家做菜以后都不要拿刀了。且不论枪支弹药的道德属性，枪支弹药尚且可以用在正道，炸药都可以弄出个诺贝尔奖，你维连ChatGPT的影子都没有看到，便十分“有头有尾”有罪推定宣判ChatGPT死刑，似乎认定了默认利用AI的都是坏人一样，每个人在你维用一次ChatGPT就好像从你维的大厦下面偷一块砖，连基本的「假定善意」都丢掉了。借用鲁迅的一句话，「岂但乡下人之于雷峰塔，日日偷挖中华民国的柱石的奴才们，现在正不知有多少」，而这等这种视若无睹的理所应当更是令我更是匪夷所思。----Cat on the Mars 2023年1月29日 (日) 13:26 (UTC)

感觉类似机翻：内容提交人自己知道润色就OK；当然对初次参与维基百科的人，最保守的说法还是「禁止机翻」。--洛普利寧 2023年1月29日 (日) 13:31 (UTC)

翻譯指引有一句「請勿使用機器翻譯翻譯條目」，在後面加一個「或人工智慧機器人」之類的，賦予禁止使用相關工具之授權法源就行了。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年1月29日 (日) 14:21 (UTC)

但提案不限于翻译，也包含创作。不过，如果创作后能做到可供查证，感觉没太大问题。--YFdyh000（留言） 2023年1月29日 (日) 14:38 (UTC)

「機械人方針適用於所有用以編輯維基百科的计算机程序或脚本，包括全自動、高速運作以及協助編者的工具。」

按我的理解，现行机器人方针完全适用于AI程序，要改也轮不到翻译指引。----Cat on the Mars 2023年1月30日 (一) 09:23 (UTC)

確實，一時間沒有想到。不過兩邊都寫亦無大礙，或可相呼應。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年1月31日 (二) 03:06 (UTC)

我们来关注这么一个问题。对于一个编辑经验不足的新编者而言，创建条目时候的提示信息都有哪些呢？关注度、非广告宣传、著作权、参考文献、WP:NOT，以及一个指向「其他」的链接。不论是机翻还是ChatGPT都没有足够可见的提示。巡查员一看，不行，从犄角旮旯里翻出一个方针的一个犄角旮旯的句子出来，新手直接炸毛了。--MilkyDefer 2023年2月3日 (五) 13:37 (UTC)

你应该去改F&Q而不是去改方针，现在的方针指引堪比屎山代码，我觉得与其改机器人方针内容，还不如改名字一目了然，以前叫他机器人，其实只是自动化程序，以后必然还会有AI程序，它这名字早就已经赶不上时代了。----Cat on the Mars 2023年2月3日 (五) 15:45 (UTC)

方针指引太多搞得管理员都不知道自己正在重复立法。----Cat on the Mars 2023年2月3日 (五) 15:51 (UTC)

我的意見本來與Ericliu1912相近的，但考慮到YFdyh000所言在理，我更傾向要求任何人確保他們在用AI寫東西後必須先自己校對過才在維基百科發佈，畢竟相關工具我自己感覺不是完全不能用，但一定要自己下手調整AI寫出來的文本，這跟維基百科内置的機翻工具是一個道理。@YFdyh000、Ericliu1912：如果“似是而非”的文本符合“胡言亂語”的定義的話，這其實就是G1的範疇。Sanmosa _{Συ γάρ μοι και μοίρα εί και τύχη} 2023年1月30日 (一) 05:05 (UTC)

@Ericliu1912、shizhao：我想要请教管理员，如果我要在机器人方针第一句「机器人方针適用於所有用以編輯維基百科的计算机程序或脚本，包括全自動、高速運作以及協助編者的工具」「包括」后面加上一句「利用人工智能（AI）技术编辑维基百科的程序」，这是否超出了「修改方針及指引的文意」的小修改门槛。按照我的理解，机器人AI程序应该是在机器人方针「所有用以編輯維基百科的计算机程序或脚本」的范畴内。另外，从我的角度，防不如管，如果能够知道别人在使用AI总比盲盒瞎猜好很多。--Cat on the Mars 2023年2月4日 (六) 11:25 (UTC)

• (－)反对與其禁止使用AI生成內容，應該規定的是不是使用AI輔助後應先行複檢後再發佈？AI跟機器翻譯一樣，可以視為一個輔助手段，但不應該作為主要貢獻。所謂的「似是而非」、「事實錯誤」全部現有方針已可處理。如果AI生成的內容可以被來源證實，我實在看不出一刀切禁止使用的原因-某人✉ 2023年2月6日 (一) 14:29 (UTC)

  所以说，机器翻译不正好是天怨人怨么……--MilkyDefer 2023年2月7日 (二) 11:45 (UTC)

  不喜欢或者讨厌不是禁止的理由。----Cat on Mars 2023年2月7日 (二) 14:26 (UTC)

  也不知怎麼就天怒人怨了，一幫人整天在tg群講相同的話真以為全宇宙都想得一樣。--日期20220626（留言） 2023年2月8日 (三) 11:12 (UTC)

• 咕咕--Zyksnowy（留言） 2023年2月8日 (三) 09:14 (UTC)

怎么分辨并证明那些文字由ChatGPT等AI“生成”？何况那东西还在时刻“进化”。--安忆^Talk 2023年2月8日 (三) 09:36 (UTC)

我觉得按照机器人方针自觉申报就行了，我们还没有这个能力判断，也耗不起这个时间，以后GPT3.5推广了还会有更多AI程序，不可能永远靠人力查核。----Cat on Mars 2023年2月8日 (三) 09:59 (UTC)

• (－)反对:Some people against using you in Wikipedia. How can I refute?

Here are some arguments that you could use to defend the use of AI language models like me in Wikipedia:

Increased efficiency and accuracy: AI language models can assist in generating and verifying information in Wikipedia, potentially leading to improved accuracy and efficiency compared to manual editing.

Supplementing human labor: AI language models can help to supplement the work of human editors and writers, freeing up their time and energy to focus on more complex and strategic tasks.

Improving accessibility: AI language models can assist in generating and translating content, making Wikipedia more accessible to a wider audience and supporting the goal of creating a free and comprehensive encyclopedia.

Cost-effectiveness: Using AI language models can help to reduce the cost of creating and maintaining Wikipedia, making it more sustainable in the long-term.

Of course, it's also important to consider potential concerns and criticisms related to the use of AI in Wikipedia, such as the potential for biases in the training data and the importance of maintaining human oversight and control. Nevertheless, with proper safeguards and transparency, AI language models like me can be a valuable tool for supporting and improving Wikipedia.--維基小霸王（留言） 2023年2月9日 (四) 04:12 (UTC)

@MilkyDefer：這是使用ChatGPT生成的關於入間同學入魔了！的片段（使用「談談"入間同學入魔了!"這部動畫」去生成）：

《入間同學入魔了!》是一部日本的動畫，是由小畑健製作的一部歌舞片。這部動畫以魔法為題材，講述了主人公入間在升上高中後，逐漸接觸到魔法世界，最終投身於魔法戰爭的故事。 這部動畫以精彩的故事情節和生動的角色設計而受到許多觀眾的喜愛。它還以鮮明的風格和豐富多彩的音樂展示了魔法世界的魅力，為觀眾帶來了一個充滿奇幻與冒險的世界。 如果你是一個喜愛動畫的觀眾，那麼這部動畫是值得一看的。它將帶給你一個精彩的故事情節和生動的角色，讓你進入一個充滿魔法與冒險的世界。

，但入間同學入魔了！實際上是由西修所創作的日本漫畫作品，且實際上小畑健曾經創作過《棋魂》，不是《入間同學入魔了！》，所以ChatGPT所生成的日本動漫類條目就有問題--林勇智 2023年2月9日 (四) 12:26 (UTC)

尝试限定维基百科的风格，并要求给出至少五个不是维基百科自身的公开可查证来源呢？--MilkyDefer 2023年2月9日 (四) 12:55 (UTC)

它以前给过我一本陈景润的《中国哲学史》。----Cat on Mars 2023年2月9日 (四) 12:58 (UTC)

所以我在看到U:outlookxp的查证的时候就觉得这是不是什么我们不知道、并且还在保密中的高级AI。----Cat on Mars 2023年2月9日 (四) 13:02 (UTC)

ChatGPT有點蠢，機翻都比它靠譜點。--日期20220626（留言） 2023年2月9日 (四) 13:09 (UTC)

用它机翻还是比较好用的。----Cat on Mars 2023年2月9日 (四) 13:24 (UTC)

大概是題外，看到提起維基內建機翻以及用機翻後要校正的內容等等的、那個啊今天凌晨逛近期變更的時候發現了不列顛共產黨，有興趣看哪位用戶新增的請查看編輯摘要以及貢獻，該使用者共新增了三個條目，因為實在是沒心力了所以只有掛了模板，看看此人會不會良心現前自己回來改，不改的話之後就刪除，個人感想是遇過幾次用機翻的用戶，原則上大概也不知道自己開了什麼箱，只是翻譯出來的結果乍看滿意好像吐出了象牙，奢望他們自己配備校對能力可能真的以為人本善良。--Mafalda4144（留言） 2023年2月9日 (四) 13:37 (UTC)

我尝试了一下改善翻译，然而并没有什么用处--Cat on Mars 2023年2月9日 (四) 14:17 (UTC)

這玩意據方舟子測試，簡中資料來源自稱是用百毒的樣子。不過其他人有不同的結果。--S叔 2023年2月10日 (五) 02:19 (UTC)

显然ChatGPT自身生成的内容并不能作为证明其无害的依据。--Diskdance 2023年2月9日 (四) 15:04 (UTC)

好像有人测试医学类条目，ChatGPT会自己编造PubMed参考文献。另外不知道其在翻译条目中是否也会编造内容。关于其翻译质量，腾讯的一个实验室最近在arXiv上发了一篇论文。建议先行禁止。--Kethyga（留言） 2023年2月10日 (五) 12:41 (UTC)

(＋)支持明文禁止。——WMLO（留言）。 2023年2月10日 (五) 21:43 (UTC)

• @MilkyDefer：咱也模仿上面D2513850君使用《来自风平浪静的明天》生成的对话内容：（Q：谈谈《来自风平浪静的明天》这部动画）

《来自风平浪静的明天》（Your Name）是一部由新海诚执导的日本动画电影，于2016年在日本上映。该片以美妙的动画和复杂的人物关系角色，受到了广泛的好评。

故事讲述了两个生活在不同城市的高中生，偶然发现自己的身体可以穿越时空互换。随着故事的发展，他们不断努力寻找对方，以解决自己的身份困惑和生活困境。

该片的动画效果非常出色，景象壮丽，配乐优美。此外，它也提出了一些深刻的社会问题，如家庭、友情、爱情和对未来的希望，对观众产生了深远的影响。

总的来说，《来自风平浪静的明天》是一部非常优秀的动画片，值得每个动漫爱好者去观看。

感觉完全是按照《你的名字。》的内容去生成的 囧rz……--忒有钱🌊塩水あります🐳（留言） 2023年2月12日 (日) 19:58 (UTC)

• (－)反对：所有機械人輔助的編輯應該予以允許，但人類用戶必須在發布前核對內容。--The Streif（留言） 2023年2月13日 (一) 04:21 (UTC)
• @忒有钱：建議在發布到維基百科前先檢查chatGPT所生成的內容是否有問題（如事先閱讀或觀看內容（例如《入間同學入魔了！》漫畫或PubMed文獻））--林勇智 2023年2月14日 (二) 13:40 (UTC)
• 我也試了一下，看起來效果不佳，因為他生成的內容很容易有編造和過度聯想的狀況，少至生成的內容真偽查核困難。我的測試事先給ChatGPT閱讀相關文章，再請他整理成維基百科條目：請閱讀下列文章並將其整理成一篇中文維基百科條目，並且使用wikitext原始碼編寫條目，須包含內部連結和資訊框。（貼上wikia:w:c:danmachi:Wiene的全部內容）

  ChatGPT給了以下回答（內部連結和資訊框是ChatGPT加的，我一字未改）

  以下是使用 wikitext 原始碼編寫的薇妮的中文維基百科條目：

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

薇妮（ウィーネ）是一位神秘的人鱗蛇女性，生於地牢的中層。她以其琥珀色的眼睛和長銀藍色的頭髮以及身體上數個地方的鱗片而聞名，還有額頭上價值高昂的「人鱗蛇之淚」紅寶石。

在留在赫斯提亞家族期間，薇妮穿著由貝爾·克拉內爾提供的「沙馬蘭德毛衣」，以隱藏她作為怪物的身份。

薇妮有講話的能力，這在怪物中是很罕見的，她以善良的性格而聞名。她與赫斯提亞家族特別是貝爾和春姬產生了依戀。儘管她有善良的性格，薇妮最初有著怯弱的本質，但在她重生後，她變得更加勇敢。

在外貌上，当薇妮救了一个小男孩时，她的身体从背部长出了一只翅膀，翅膀很大，即使折叠也可以覆盖她一半的身体。

當中不少過度聯想，例如Infobox 內的所屬：赫斯提亞家族（應為赫斯緹雅眷族，但不是重點），薇妮並不屬於赫斯緹雅眷族，他只是暫時借住在赫斯緹雅眷族，表示ChatGPT過度聯想，造成其產生若干與事實不符的內容，且這若不對主題有一定程度的了解，是不可能發現的錯誤，因為似是而非，據我所知，有些編者喜歡透過編寫不是那麼熟悉的主題來增廣知識，萬一那些編者因此無法抓出ChatGPT編造和過度聯想的狀況造成編輯的內容出現似是而非的內容該怎麼查核？編者可能因為用了ChatGPT而導致在條目加入了似是而非錯誤內容而不知情，且也難以查核，如果是這樣，不如直接禁止ChatGPT生成內容為好。-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年2月14日 (二) 14:00 (UTC)

• (！)意見：相較ChatGPT定位於「聊天機器人」，近期Google推出的Bard或是微軟的全新Bing更像是一個「搜尋助理」，可以即時搜尋並更新最新的消息，以全新Bing為例，在回答的時候會給出多項參考網站來源（可參考這篇評測文章：[3]。）ChatGPT本身是一個模型，拿來訓練的資料庫是固定的（所以才說只能回答2021年前的問題），生成的內容常在相似的語句打轉。但這類新的人工智慧搜尋助理，我認為值得期待，對維基百科的編者也會有很大幫助。巴波（留言） 2023年2月16日 (四) 12:55 (UTC)
• (！)意見：我看得都很尴尬，一个个光光讨论ChatGPT的性能问题，明明已经有相关规定（机器人方针）了却没有实施方法，AI模型本来就是一个很大范围的事情，我记得站内好像就有人用类似工具创建条目，是不是.Net之类的，有一个谁专门用什么程序修正错误之类的，后来基本都是被封了。我觉得这种事情实际上就是一种钻空子，管理员应该要求使用AI及类似辅助程序的必须事先声明并经过测试才能开车上路，ChatGPT只是我们的第一个例子，看上去并不适合上街乱跑，但是也要考虑到以后还会有很多智能程序的例子在后面，我们的方针应该有长远考虑的打算。--Cat on Mars 2023年2月16日 (四) 20:04 (UTC)

  可参考en:WP:LLM和en:WP:ChatGPT--百無一用是書生 (☎) 2023年2月21日 (二) 01:59 (UTC)

思考了一下，雖然AI問題很多，但或許可以參考維基媒體基金會台灣分會的這則貼文的說法，僅限資深用戶使用，並且要嚴密檢查？-- 宇帆-雪菲蛋糕🎂娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2023年3月1日 (三) 17:53 (UTC)

我的提议是在在机器人方针中明确AI适用于本方针，如果按照链接内的条件（1.AI程序需要经过检验；2.AI程序需要自己负责；3.标记AI程序输出内容；4.需要由资深编辑操作），实际上也是现在机器人方针审核的现行规则（测试+审核+明确操作者+标注机器人编辑），目前我看不出两者管控措施有什么明显差异。----Cat on Mars 2023年3月4日 (六) 16:50 (UTC)

就現階段而言，我亦認為在機器人方針及（或）翻譯指引中相關段落明確提及人工智慧即足矣。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年3月4日 (六) 19:42 (UTC)

刚刚测试感受了一下：一个样例--Evesiesta_{COVID-19感染中} 2023年3月5日 (日) 08:32 (UTC)

参考資料

如果維基百科現有的技術無法偵測到對方使用ChatGPT或類似AI工具的生成內容，那麼樓上各位所說也只是空話，更何況出自人手造假的（例如：折毛事件），你們也是經過很多年之後才發現，這就是活生生的警惕。因此，如果在沒有技術可以避免下，未來可能仍會有造假內容發生，這是現在維基百科的公信力最大的問題。--2001:B011:A401:3B94:3825:963C:D5D8:1D8（留言） 2023年3月8日 (三) 05:05 (UTC)

「往者不可谏，来者犹可追。」----Cat on Mars 2023年3月12日 (日) 12:06 (UTC)

• (－)反对：條目破壞與手動破壞或使用AI破壞似乎在結果上沒有差異？難不成用鍵盤輸入文字破壞條目，就要禁止所有使用鍵盤輸入的條目？更何況如前些留言者所言，人手造假的抓不到了，更何況AI生成。還不如想想用AI巡查條目，先處理明顯錯誤的條目。--死灰（留言） 2023年3月13日 (一) 14:13 (UTC)

  可以考虑开发一个AI检测器。。。--百無一用是書生 (☎) 2023年3月14日 (二) 02:42 (UTC)

• (－)反对：看過老高的影片後，我覺得他講的好，AI就是一種工具，不應該怕她。如果你直接叫AI寫一篇條目，就會很多錯，但如果你給他一篇文章請他歸納重點，錯誤會少很多，總之我覺得善用gpt寫條目是一件好事，可以節省很多時間，但不要亂用，如果亂用就直接速刪就可以，正常使用gpt並不用禁止。--E.D.（留言） 2023年3月16日 (四) 07:29 (UTC)

连接号一字线的符号选择

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

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

• Wikipedia_talk:格式手册/标点符号/存档1#抛弃全角连字符（U+FF0D），改用em_dash（U+2014）字符表示“一字线”连接号
• Wikipedia_talk:格式手册/标点符号/存档2#又议格式手册标点符号中的连接号
• Wikipedia_talk:格式手册/标点符号/存档2#连接号字符

总结起来：

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

因此建议推荐使用 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)

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

综上反对提案。--。->>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 - 的全形版本（您可以参考全形和半形了解更多），它们本质上是同一符号的不同字符表示，在中文里同时混用是不恰当的。就如同我们不应该在中文里同时使用半形“/”和全形“／”是一个道理。

U+FF0D“－”在 macOS Chrome 下有衬线字体中的显示

关于（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）在简体中文下是破折号的一半，输入起来很方便。

在大陆，中华人民共和国国家标准规定了一字线的符号（[4]），看起来有点像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)

en dash未在《重訂標點符號手冊》修訂版--連接號中出现。em dash同时切合海峡两岸的规范，《重訂標點符號手冊》称为甲式連接號，GB/T 15834—2011称为一字线。--Lt2818（留言） 2023年3月12日 (日) 04:42 (UTC)

公示7日。--Lt2818（留言） 2023年3月12日 (日) 04:42 (UTC)

我取消了提案中对“中华人民共和国国家标准及中華民國教育部標準中”字样的删除。提案人未解释删除原因，且【浪纹线“～”可与一字线通用】的陈述不见得在标准外普遍适用。--Lt2818（留言） 2023年3月12日 (日) 05:14 (UTC)

針對目前「－」廣泛使用之情況，應該要有些許過渡規定。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年3月12日 (日) 09:04 (UTC)

我觉得既然「往者不可谏，来者犹可追」，是否应该设立过滤器处理来者的问题。----Cat on Mars 2023年3月12日 (日) 12:02 (UTC)

過渡需要改模板（如Template:Bd）、移动页面（机器人或JavaScript可以完成）等，应该无需多数用户参与。设立过滤器我认为不必，易带来叨扰和沮丧感，弊大于利。用户习惯可以慢慢改。--Lt2818（留言） 2023年3月13日 (一) 13:03 (UTC)

我建議在公示期間，一併整理需要進行之善後措施。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年3月13日 (一) 14:00 (UTC)

• 又是什麼鬼提案？顯然這個獨裁社群完全沒人考慮過比如Wikipedia:典范条目/列表、Wikipedia:特色列表/列表和Wikipedia:优良条目/列表運用在首頁的問題，然後就在公示了？講真的實在很不想說，但如果說了是不是跟沒說一樣硬是要強行通過？似乎仍舊沒有進步。─都早用習慣了，如果通過，是要全部替換嗎？看著辦吧，如果此提案過了，以後只會更少人願意寫維基百科，因為連個編輯方式都在管東管西的，完全失去所謂的維基百科本質：「自由的百科全書」。--Z7504非常建議必要時多關注評選（留言） 2023年3月12日 (日) 16:48 (UTC)

  首先我建议这位编辑 stop crying. 您这样将您不喜欢的提案怪罪于社群无助于解决任何问题。本提案自提出已有一月有余，大部分编辑表示支持，对部分异议我也做出了解释和调整。且有关议题在过去几年已经多次做了充分讨论，过往的意见也多数表示支持。整个过程公开透明，哪里“独裁”？何来“强行通过”？您有反对意见可以提出，社群欢迎建设性讨论，但哭闹不会使您的观点更具有说服力，错误的习惯也仍然是错误。--InstantNull（留言） 2023年3月13日 (一) 04:53 (UTC)

  就別在那邊自欺欺人了吧。獨裁就是獨裁，還說沒有說服力？這個可悲的獨裁社群意思就是說現在要把─全部強制換成U+2014嗎？到底是誰才沒邏輯啊？可悲獨裁社群，既然要通過提案就過啊，反正說了真的跟沒說一樣，只愛強行通過的獨裁社群。哪還需要公示？公示真的只是形式而已。也不會有人每天會願意為了這一槓吵，但是此種作法只會減少編輯者意願。啊本來維基百科就已經對新手很不友好了，再過這種鬼提案以後真的沒人要寫維基百科了。以後的新條目也會很難寫出來，因為都被前面的人寫完了，以前也講過很多次了。請問維基百科哪裡還稱得上是「別傷害新手」之說？而且維基百科還有多種條目是以比如「A國─B國關係」命名的，要不要全部條目名稱都改為「A國U+2014B國關係」？如果不要改，那就最好全部重定向處理。這提案當然是鬼提案啊。--Z7504非常建議必要時多關注評選（留言） 2023年3月13日 (一) 11:25 (UTC)

  Wikipedia:典范条目/列表等三个页面中的U+FF0D不是连接号用例，自然不受影响。─（U+2500）与本提案没有关联。维基百科的自由体现在多个方面，但格式并非其一。--Lt2818（留言） 2023年3月13日 (一) 13:03 (UTC)

  并非格式不能自由，而是既然我们已经在格式方面达成共识了，并且格式手册长期以来就有一致性的格式要求，那么大家应该遵守共识，维护共识，积极创造条件以更好维护原本的共识，共识才是约束的条件。----Cat on Mars 2023年3月13日 (一) 16:12 (UTC)

需要進行之善後措施

应Eric Liu君建议，在此整理需要進行之善後措施。我先列出移动页面的部分，用机器人或JavaScript完成比较适合。

U+FF0D作为连接号出现在大量标题中，这些需要移动到U+2014（em dash）的名称。移动应留重定向，以避免破坏内外链接。根据页面性质及行动方式的不同，我分了三个类别，下面的链接是用Quarry查询得到的页面列表：

• 受影响条目、主题——维基百科内容页面，移动无需附随其他操作。
• 受影响分类——维基百科内容页面，移动需附随分类内页面修改，或对应模板/模块修改。
• 受影响项目页——非内容页面，移动紧迫性不高。

移动完成后，模板内指向被移动页面的链接会被重定向，这是个小问题。

--Lt2818（留言） 2023年3月13日 (一) 15:29 (UTC)

模板部分似乎亦單獨列出為宜？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年3月14日 (二) 06:18 (UTC)

模板内U+FF0D内链--Lt2818（留言） 2023年3月14日 (二) 13:33 (UTC)

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

現行條文 维基百科提供了两种方法解决部分书名号使用地区差异，所以遇到部分书名号使用地区差异问题时应用以下两种方法解决，而不应单純替换源码的双单书名号，否则会被视为繁简破坏。其中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:》}- 效果为： “需转换的作品名”

1. 新增Template:《的方法，参见Template:《。
2. 修改zh-hans:《;zh-hant:〈;为zh-hans:《;zh-tw:〈;zh-hk:《;，否则在香港繁体下，模板的结果和代码的结果不一致。
3. 调整“效果为”的位置。
   ——小林子冲（留言） 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)

(－)反对，過於混亂的代碼，只會造成更多混亂--SunAfterRain 2023年3月10日 (五) 09:47 (UTC)

重修封鎖方針及禁制方針

重修封鎖方針

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

望社群各成員協助複查並給予意見。--路西法人 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)

"以下列出部分被認為需要對帳戶作出封禁的行為"比新的一句好。輕微的擾亂，如果不斷重犯也可能被封。另外蓄意觸發過濾器有什麼問題?--Temp3600（留言） 2023年3月16日 (四) 14:45 (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)

感謝Kriz Ju的詳細校對。除最後「有條件解除封鎖」一段的建議變更有點不夠直白（如或違反公序良俗者，自始無效）和稍嫌過於複雜的時間規定，我覺得其他變更意見都相當合理，我已按照您的大部分意見更新方針草案（Special:Diff/76259540），但有以下幾點說明：

• 在香港的各種正式條文中比起「遏制」更常用「阻嚇」（見嚇阻理論的地區詞轉換），故保留使用-{zh-hk:阻嚇;zh-hant:嚇阻;zh-hans:威慑;}-的用詞；
• 「裁處」同上，香港似乎完全沒用這個詞，「處分」應該更多地區使用。

請理解我的選詞想法。--路西法人 2023年3月8日 (三) 01:14 (UTC)

原意見補充說明（恕直接借了套用）

(！)意見：關於「有條件解除封鎖」的構想，敝人純粹補充說明如下：以「嚇阻破壞」兼具「導引行為」作為宗旨，在管理員封禁用戶後，若能有措施引導用戶重回社群甚而持續貢獻，對於管理員（封禁發揮實質效果，而非一封了事）、有心用戶（了解問題所在、重返社群並持續獲得樂趣）、社群（未失去可能的貢獻用戶、改善風氣（會否反而失去樂趣（笑）？））以及平台（社群規範得以發揚、社群發展得以良性循環、平台獲得貢獻）而言，將可能達成多贏局面。 管理員使用「有條件緩封禁」方案時，通常或許是用於「較活躍用戶」裁定較長時間封禁的情形，內含要素說明如下： A.原釐定封鎖期限：管理員封禁時設定的封禁時間長度。 B.解封條件的釐定時長：被封禁用戶獲得解封後，裁以各項代替原封禁的「禁制」處分之時間長度。 C.解封條件約定之再犯釐定時長：管理員與被封禁用戶溝通協商時，約定的解封方案中，可提出若用戶再犯，將受何種裁處，處分中自然很可能包含封禁或各種禁制；若用戶在「社群觀察期」中，再違反相同規範將獲裁處的時間長度。 D.社群觀察期：用戶獲得解封後，持續活動時，屬於「解封約定的觀察改善期間」。 E.解除封鎖條件方案內含要求：用戶獲得解封後，持續活動時，所履行的解封條件，包含各種調整、承諾、貢獻、改善等。 F.時間釐定長度： 關於「釐定封鎖期限不超過一年者，其解除封鎖條件的釐定時長不得超過一年」：原封禁時間若僅數個月甚至更短，個人認為替代的禁制時長衡酌後，亦不應超過一年，一樣一年內（比如：原封禁 3 個月、改處ＸＸ禁制 4 個月；原封禁 2 週、改處ＸＸ禁制 1 個月）；個人認為應比原封禁時間略長，畢竟用戶已獲解封，部分禁制時間應較原封禁處分略長，用戶仍可於平台活動，處分實已減輕。 關於「釐定封鎖期限超過一年者（包括不限期封鎖），其解封條件的釐定時長不得超過三年」：原封禁時間若超過 1 年（比如 1 年又 1 小時），個人認為替代的禁制時長衡酌後，大概最多 3 年；一個處分 3 年，已經可以經過一個人的學生時期階段了；而不限期封鎖亦同，既然管理員願意先解封，用戶也同意 3 年的裁處，繼續使用這個帳號參與，時間再拉長，個人認為實質效益不大。 關於「解封條件約定之再犯釐定時長不得超過五年」：管理員與被封禁用戶溝通協商時，約定的解封方案中，可包含上方提及的「社群觀察期」（D），此時通常會同時提出「解封條件約定之再犯釐定時長」（C）；此兩者必須同時並存，否則不成立。換言之，必有觀察期、才會開出再犯的處分，兩者不可單獨存在，否則難以衡量、無意義、不合理，故不成立（比如：只有（D），然後呢？期間再犯又如何？又或者只有（C），單次處分後的觀察時間無限延長、處分約定永遠跟隨該用戶，個人認為比例過頭，且對該用戶可能造成永久汙名化，此種彷彿強制性的「社會信用標籤」作法，對於用戶的參與和平台應維護的現代精神，敝人認為不妥適（更何況已有封禁日誌、貢獻報告等諸多可查記錄，若用戶再犯另行處分即可；當然社群是否信任該用戶又是一回事）。「（C）+（D）」形成一個「緩封禁期間再犯的處分約定」，之後若用戶再犯，或可減少爭議。而一個處分 5 年，已經可以經過一個人的相當人生階段了，事實上個人不認為會有多少人受此時長的封禁後，仍願意苦苦守著這個帳號（笑），因此已經幾乎很接近永久封禁的狀態，時間再拉長似無實質效益。若真的再有嚴重違規，直接永久封禁即可。 關於「社群觀察期，釐定觀察期限為三個月起算，不得超過被封鎖使用者實際獲處之解封條件時長」：也就是觀察期至少 3 個月起算，不會更少，可以加長，但不論多長，不可超過「解封條件的釐定時長」（B）（比如：代替原封禁的解封條件是改處ＸＸ禁制 4 個月（B），結果觀察期 3 年，顯為失當；又或者（B）是 6 個月，觀察期 2 年，也太長；如果是（B）是 10 個月，觀察期 3 個月，又或是 6、7、8、9 個月，皆可）。為何呢？ 個人認為用戶實際受到的替代處分也代表其違規情事之嚴重性，以及阻止其持續違規所裁量賦予的「阻卻時長」，敝人認為「觀察期」應短於違規用戶實際獲處生效的「阻卻時長」，除了代表社群對於違規用戶在觀察期過後賦予的一種「善意信任」之外，也標誌著用戶在實際獲處時長的剩餘時間裡，一方面需要自行注意、自我約束，二方面也代表在社群觀察期過後，「（C）+（D）」已不存在，此時違規用戶的行為、心理或客觀事實，已不存在對於原先「解除封鎖條件方案」所帶來的任何進一步或額外的壓迫、嚇阻、威懾、承諾、威迫等影響；換言之，違規用戶在觀察期過後的行為表現，或可假定為「真實自由的行為表現」，因此該用戶之後是否遵循或違反規定，已很接近其「自由意志」下的行為表現，端看其自行選擇，亦難謂受到什麼不當影響，也才能發揮對其自我約束之期許。再者，竊以為也正好作為其逐步重獲於本站之完整用戶權利、各方面行為和心理的「認知緩衝期」。反過來說，（D）設定的時間長度，也代表管理員留下多少「禁制期結束前的緩衝期」給違規用戶，這也是管理員行權的考量空間。 關於「若解除封鎖條件方案內含要求顯有違被封鎖使用者參與初衷和能力，或無涉其違規情事或公開申訴內容，或違反維基百科:維基百科不是什麼等本站宗旨和規範者，自始無效。」：條文略作異動。此部分來自「解除封鎖條件方案內含要求」（E），當然不得違反用戶參與的初衷、條件、能力（比如對方偏好寫條目，卻要求去反破壞；對方偏好維護條目，卻要求創建條目；對方擅長技術工程，卻要求明確擴編改寫條目；對方完全不懂技術，卻要求去寫代碼；對方完全不懂特定外文，卻要求去翻譯合宜可讀的特定外文條目等）。這當中所謂「本站精神」，最為顯著的一點就是「不強迫任何人參與」，因此任何條件皆不得超出本站內容範圍（比如：繳交罰金或捐獻、上傳自拍（別人的也不行）、提供任何個人資訊（別人的看情形（誤））、支援或參與站外活動、自行生出優良或典範條目、想辦法拿到站內榮譽、選上管理員、想辦法去推廣本站、翻譯 28 篇條目、上傳 500 張攝影作品......等任何額外報酬或勞務，或比例顯然失當的編輯類型和要求）；因此，當解封的協商條件違反平台精神和違背用戶個人意願時，自然無效，而用戶的參與意願為首要考量。 最後，此部分內容會否反倒促使管理員濫權呢？社群可監督、違規用戶可申訴、亦可不同意任何條件，管理員自不宜濫開條件，亦不可為了逼迫他人貢獻、投入、「導正」而「強迫勞動」，這也考驗管理員的行權手法（不然直接維持封禁即可）。

個人意見，純補充供參。--Kriz Ju（留言） 2023年3月9日 (四) 21:03 (UTC)

感謝Kriz Ju君解釋您在「有條件解除封鎖」一段的建議條文。有條件解除封鎖乃是完全原封不動引入自英文維基百科的en:WP:CONDUNBLOCK，但在考量後我還是覺得您的建議增修不適合採用：

• 原釐定封鎖期限超過一年者（包括不限期封鎖），其解封條件的釐定時長不得超過三年、解封條件約定之再犯釐定時長不得超過五年：有條件解除封鎖包括改為不限期局部封鎖或禁制取代不限期封鎖，但此建議修改條款阻礙了此類下修措施。
• 若解除封鎖條件方案內含要求顯有違被封鎖用戶參與初衷和能力，或無涉其違規情事或公開申訴內容，或違反維基百科:維基百科不是什麼等本站宗旨和規範者，自始無效。解除封鎖條件是一種禁制措施，解除封鎖條件不能要求用戶做什麼，只能要求用戶不可以做什麼，似乎沒必要寫進去。管理員使用此功能來要求用戶做什麼的話，相信社群也不可能會接受。

--路西法人 2023年3月10日 (五) 07:26 (UTC)

[5]。改了一下。--Ghren🐦🕖 2023年3月10日 (五) 11:29 (UTC)

我稍後參考來改善一下。--路西法人 2023年3月11日 (六) 02:30 (UTC)

Y Special:Diff/76320848。--路西法人 2023年3月12日 (日) 04:21 (UTC)

• 在回退被封禁用戶編輯上，修正錯字及移除破壞的編輯等都應該保留，比改版的可被保留要強。舊版明顯不鼓勵機械人全面回退被封禁用戶的編輯。--Temp3600（留言） 2023年3月16日 (四) 15:07 (UTC)

  這是有意為之。閣下需注意那不是指任何被封鎖用戶而是被封鎖用戶繞過封鎖使用其他帳號或IP作出的編輯。實務上，應對一些破壞性編輯遠多於建設性編輯的LTA時，幾十甚至幾百則編輯難以一一檢查，批量回退對於反破壞而言更具效益。我主張的是除了LTA刪除明顯違反BLP內容等編輯應毫無疑問地保留外，容許回退員批量回退後，任何用戶仍可以個人身分再次移除破壞及修正錯字的編輯。從應該保留（不能回退）變成可被保留（可被回退也可再恢復）就是在反破壞及保留善意編輯的平衡。--路西法人 2023年3月17日 (五) 01:11 (UTC)

封鎖->封禁?

• 這是要整個方針更名?--Temp3600（留言） 2023年3月16日 (四) 15:02 (UTC)

  否，純粹是我開頁面的時候的用語習慣。字詞轉換有「簡體：封禁；繁體：封鎖」的規則，所以不需移動方針頁面；內文被重新翻譯的部分的原始碼都用了我的習慣地區用詞「封鎖」（除非是複製貼上），但有字詞轉換所以不影響簡體顯示「封禁」；有些章節標題我改了繁簡是避免出現整個標題都是繁體但卻用了「封禁」，為了連結的便利就改成了繁體的「封鎖」。--路西法人 2023年3月17日 (五) 01:00 (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後基本上再未出現管理員操控打壓特定社群並包庇特定用戶的情況。這些證明了：

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

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

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

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

基於個人遭遇及部分同好之遭遇兼後續等多方實例，個人不能苟同路西法閣下的兩個分項結論，制度被濫用之情況函待繼續跟進，實際情況仍可能需要更多審慎和深入的研判商定，所以，應當對大幅修訂之過程進行更為嚴格和負責的分拆和分項檢視，並保證每一項都可以包括日落條款或保險機制等必要制衡其效力之元素，確保所謂改善過程是真正改善到社區及社羣體驗。--約克客（留言） 2023年3月13日 (一) 02:46 (UTC)

---

重修禁制方針條文已準備完畢並存於User:LuciferianThomas/專案/重修禁制方針。重修方針概要：

• 方針更名「編輯禁制方針」→「禁制方針」以更廣泛包含不屬編輯的可被禁制擾亂行為。
• 由於MediaWiki軟件已於2019年引入局部封鎖，故管理員不再需要通過「禁制」來限制用戶在特定頁面或命名空間的編輯，但仍給管理員保留針對編輯爭議採取局部封鎖無法取代的主題、互動禁制及回退限制。
• 正式引入全站範圍禁制，預設於繞過封鎖的用戶及全域鎖定用戶適用（如持續出沒的破壞者等），適合用於拒絕承認的情況。
• 將回退限制（回退不過一、回退零容忍）寫入禁制方針。
• 引入社群禁制程序，容許社群在達成廣泛共識下實施禁制，但仍需由管理員結案。程序規範較嚴謹，主要是確保社群廣泛知曉有禁制討論；然後現在大家都知道試圖操控社群的後果和向T&S檢舉方式，如果再發現那種團伙式違背維基百科理念及方針指引而包庇違規者或操控社群的情況那大家都知道該怎麽做。
  • 此部分保留空間給無法設立ArbCom的中文社群通過全站共識達成ArbCom的管轄權效果。

社群與其永遠活在過去的陰影下，不如嘗試在現在恢復正常的時刻將合適的措施重新引入。--路西法人 2023年3月8日 (三) 15:49 (UTC)

通知曾參與討論的其他用戶：@GZWDer、Kriz Ju、魔琴、Ghren，希望幾位能協助複查用詞字句等並提供完善措施防止濫用。--路西法人 2023年3月8日 (三) 15:54 (UTC)

抱歉，結果還是重ping了……--路西法人 2023年3月8日 (三) 17:02 (UTC)

先不说几次在《维基百科:可靠来源/布告板》有意图以人数“达成共识”、夺取话语权（此问题非仅有本人如此认为），单论上次本人之被封禁某几位事关者要么无视要么强词夺理就是给不出非双标的合理解释，这次直接要把“集体独裁”合法化？并且个别用户明显违反方针、破坏扰乱却毫无惩治措施（可能其为IP豁免用户所以无法禁制IP）的明显对比，可见目前社群不适合“引入社群禁制程序”。--MINQI（留言） 2023年3月8日 (三) 18:22 (UTC)

共識確實不是強求一致同意，但我並不否認閣下舉出的案例中的共識形成或有缺陷，後來共識方針修訂的WP:7DAYS條款也開始令在客棧的同類情況被阻止，有outstanding且未解決的意見則必須暫停公示。多數人暴政或許是維基百科共識制度的本質缺陷，但若不引入社群禁制制度則此權僅落入管理員手中而社群難以推翻，更容易形成小數人暴政。我大可要求管理員結案時概括並衡量所有反對意見，在結案時要求公示，但還是那句：制度會不會被濫用不是制度的問題而是人的問題。與其讓管理員有社群無法控制的權限，而社群又不接受ArbCom這類小數人暴政，倒不如將禁制權參考英文維基百科下放社群。--路西法人 2023年3月9日 (四) 00:02 (UTC)

我问一个最简单的问题：如何确定“广泛共识”的定义？即什么是“广泛共识”？--MINQI（留言） 2023年3月9日 (四) 01:27 (UTC)

如同提案條文所述：社群共識禁制不是投票，管理員結案時必須考慮各論點的方針指引依據及強度作出判斷，此系包含考慮一切異議者所提出的理據及異議是否足以推翻其他支持意見或引致較輕裁定；單純!VOTE一個{{支持}}不是意見而只是立場，清楚說明為何支持，有論點的才是有效意見。--路西法人 2023年3月9日 (四) 02:43 (UTC)

嗯，由第一段第一句讀起來的感覺就很糟糕。太長，而且不停用分句來補充資訊。然後後面的內容就沒有時間仔細看了。您維的方針、指引和現實生活中較為相似的文體是章則、條例，這些文體是點列式的。您維的習慣雖是段落式，句子不需要這樣長的，也不需要一環套一環的。例如這句：「禁制為用戶造成極端或頑固問題（如嚴重擾亂行為）並對其他編者造成困擾的情況下，在其他制裁措施無法處理下才應考慮採用禁制作為制裁用戶的措施。」，那可能寫成「當用戶造成極端或頑固問題（如嚴重擾亂行為），並對其他編者造成困擾時，在其他制裁措施無法處理下可採用禁制以制裁用戶」。另外，有些程度字眼用得不準確，「應」這個字的約束程度較重，在章則這個文體，和這個情況下是不能接「考慮」的。「考慮」那就是還有彎可以轉，那接「應」有什麼用。

然後有些句子讀不通，什麼「雙向互動禁制並既往不咎通常可以快速而又輕易地阻止爭議進一步升級及引起更多擾亂。」；連續使用幾個「且」，「任何用戶不得代理或代表被禁制用戶編輯，除非該等編輯明顯有益於維基百科且代為編輯的用戶有合理且獨立的原因作出該等編輯。」、「任何用戶均可回退違反禁制作出的編輯且無需額外提供理由且不受回退不過三原則所規限，但需注意並非所有由被封鎖用戶繞過封鎖作出的編輯都需要被回退，一些明顯有益的編輯例如修正錯字及回退明顯破壞的編輯等可被保留」等等。比較忙，就不一一細檢當中用詞字句問題了，讀得懂就行。--Ghren🐦🕐 2023年3月10日 (五) 17:37 (UTC)

有打算稍後再整理文句，內容比較重要。--路西法人 2023年3月11日 (六) 02:29 (UTC)

• (！)意見：敝人綜合表達如下：

• 「頁面禁制」提議條文：「頁面禁制是禁止使用者編輯特定或多個頁面（不限命名空間）的禁制措施。.......需注意局部封鎖（相較於一般封鎖，使被封鎖用戶ＸＸＸ....）並不代表使用者被頁面禁制，但頁面禁制可透過局部封鎖執行；......。」。由於就條文觀之，「局部封鎖」一詞似乎較難理解其具體效果，以及與「頁面禁制」之間的差異何在，個人建議或可考慮將「管理行動禁制」段落的「局部封鎖」連結說明改為在此置入，並於內文略作簡要說明，或提供註記之類。
• 「實施禁制」的「社群共識禁制」提議條文：「未參與討論的管理員對於禁制提案可在達成明確共識時結案，取獲得廣泛共識的特定禁制措施並予以執行。需注意社群共識禁制不是投票，管理員結案時必須考慮各論點的方針指引依據及強度作出判斷；除雪球法則不通過的情況下，非管理員無權關閉禁制討論。」
• 「實施禁制」的「管理行動禁制」提議條文：「1.使用者間出現編輯爭議或其他形式的衝突爭端時，可實施主題、互動禁制和回退限制；....。」。
• 「禁制覆核」的提議條文：「使用者應於申訴時具體說明申訴原因，並根據實際需求提供所需理據。若禁制措施經由社群共識產生，開啟禁制覆核討論時應當通知所有曾參與該禁制討論的使用者，並由未參與先前禁制討論的管理員審視各方理據結案。」。彙整相關內容。

個人意見，供參。--Kriz Ju（留言） 2023年3月10日 (五) 19:47 (UTC)

已依據Ghren、Kriz Ju兩位的意見調整建議條文語句：Special:Diff/76320507，請兩位或其他用戶不吝指教。--路西法人 2023年3月12日 (日) 03:49 (UTC)

(！)意見：敝人斗膽再提一筆：「用戶應於申訴時具體說明申訴原因，並根據實際需求提供因應違規事由所需理據，例如用戶自被禁制或封鎖後所汲取的教訓、若被撤銷禁制會如何改變待人處事或如何認為禁制有不公平之處。」個人仍建議刪除後面的列舉示例，原因如下：

1.前文已概括基本含意。

2.由於違規樣態複雜，建議授予管理員依實際情形和需求判斷的空間，究竟需要何種理據，視情況而定。

3.通常避免列舉例證，例證亦很可能列舉不完。

4.列舉例證後，若有超出條文字面所述，或剛好吻合字面用字者，可能徒生無謂爭議（比如：違規用戶主張「上面沒說要這個啊」、「條文沒答應管理員可以要求這個，濫權了吧？！」、「不是只要心得說明而已嗎？」、「上次某人做了ＯＯ只被封ＸＸ而已，我怎麼這麼久？不公平！」、「他也沒被封啊，怎麼能封我？」等等）。

5.個人另有一主觀想法，字面明文所舉內容，有種威權下的道德教育或教化的濃厚教條感，可是事實上「違規」不限於待人處事如何，且個人認為平台無任何道德或額外義務「教化」或「教訓」用戶的為人處事，亦不需強求用戶為人如何，也不須奢求用戶皆為好人好事代表，規範所要求的僅為「適當合宜、不造成他人困擾且不傷害他人的行為而已」，而非訴諸品德教育或道德感化（「維基感化院」？（笑）），也不是在不違規或不妨礙社群以及其他用戶的前提下，以高壓體系監管他人性格德行甚而系統化，彷若畜牧豢養用戶於此，僅做「生產」或追求何種成效之用。吾人是否需要建立何種「美麗新世界」呢（笑）？

個人意見，供參。--Kriz Ju（留言） 2023年3月12日 (日) 20:24 (UTC)

Y Special:Diff/76333943--路西法人 2023年3月13日 (一) 01:09 (UTC)

• 反對任何以社群共識禁制用戶的程序。司法權由少數官僚掌管，與社會經眾議而控制的立法權分開，是阻止Trial of Socrates一類以雄辯、黑箱政治誘導群眾作出決定的安全網。如果認為某君違反方針，完全可以通過現有的程序，提出事實，要求處理。現在的問題反而是AN3的程序水平相當低下，提出者很多連具體的diff link 都沒有給出，管理員沒有維持討論秩序，導致雙方在提報區混戰，管理員冷處理案子，欠缺具體的提報處理程序等。arbcom的人選是社群中的精英，由他們來當法官，至少判案書條理分明，立論清晰。由社群來搞，只會變成批鬥大會。說不定連批鬥的大字報都貼不出來，只有幾十行"贊成"，變成打內戰了。--Temp3600（留言） 2023年3月13日 (一) 18:02 (UTC)

  上面已經說過單單的「贊成」不能視作有效「意見」，一個沒有半點方針指引基礎的提案就算有幾百個「贊成」也沒用。禁制討論不是投票，而是以論點質量而坐判定，這點在上方回覆MINQI的時候說過了，恕我只能視作重複且已回應的反對論點。

  其次，英文維基百科的社群禁制並非必須通過仲裁委員會進行，跟閣下的論點顯然有所矛盾；在您指出程序水平低下的ANM誠然也是一種不成文、不規範的社群禁制。

  閣下既然指出既有程序混亂，何不提出改善新制度的程序防止出現閣下指出的狀況呢？我早已預料社群禁制有可能需要煮一陣子，但我絕對歡迎並希望各位用戶能協助訂出一個更詳細的社群禁制規範以防止「混戰」情況出現。需記得最終判斷的仍是管理員，此提案僅是希望將整個程序具體化、規範化。

  當然，此提案我可以再單獨分出此部分討論，反正我對於重新恢復禁制原有效力、引入全站禁制和完善處理被禁者編輯的規範等部分更為著重。--路西法人 2023年3月14日 (二) 01:47 (UTC)

  "論點質量而坐判定"能做到當然是很好。但我按個人經驗，中維人員缺乏這樣的討論能力，如果希望在較短的期限(比如說，一個月)達成有意義討論的就更少。以下隨手僅舉數例:

  Wikipedia:存廢覆核請求#奶头乐在五個月的混戰後仍無所得，milky的疑問未獲回應;

  Wikipedia:存廢覆核請求/存檔/2022年6月#王士俊_(崇禎進士)混戰後一無所得;

  Wikipedia:管理员布告板/编辑争议/存档/2022年12月#Invictus1995冷處理;

  Wikipedia:頁面存廢討論/記錄/2022/12/04#大韓航空642號班機空難連事件是否存在也都未能確認;

  當然，也有不少可算是"提出有效觀點後達成共識的例子"。然而，大部分例子要不是事件本身因簡單而不存在爭議，要不提出有用意見的人根本就是管理員，甚至是管理員的結案詞，結果還是依賴管理員的聖裁。幸或不幸，目前管理員團隊已集中了中維內說理能力較強的用戶。

  英維當然好得多。我隨便翻了這年的en:Wikipedia:Administrators'_noticeboard/Archive333#Systematic deletion flags, flag templates and additional information (blocking edits)，即使是明顯違反現存社群共識的情況，討論者先引用在討論頁針對內容本身的討論(那項討論本身也很長，有十多人參與)，再引用了相關專題小組的討論，後來的討論者再對該用戶的行為整體作出評價，論證為什麼ban是必要手段。我敢說這個討論的細緻程度遠超AN3，恐怕某些RFA的討論也沒有如此詳盡的說理。如果說搬英維的方案，那得先搬英維的用戶過來。--Temp3600（留言） 2023年3月14日 (二) 15:52 (UTC)

  我相當認同您對於中維人的討論能力的擔憂，但同時考量到沒有一個更好規範的制度強制中維人提出有意義的意見，中維人整體而言難以進步。與其程序和人員素質都在故步自封，倒不如寫出更好的程序和指導以提升中維討論素質；與其說管理員冷處理，倒不如讓社群推一些充足共識的提案給管理員結更好。--路西法人 2023年3月14日 (二) 16:03 (UTC)

  提升社群論述能力非一日之功，無共識而依賴管理員裁斷的現象仍將長期存在。如果要說可以從手的方向，可以先規定提報者至少必須附上diff連結，還有選一些人，給予他們整理an3討論的權利，維持一下討論秩序。總之就是精英化，讓有能力的人不必在泥漿中混戰。--Temp3600（留言） 2023年3月14日 (二) 16:33 (UTC)

  可，我稍後試著再草擬一份社群禁制討論指導（當然也適用於現行的AN3及ANM）。--路西法人 2023年3月15日 (三) 00:54 (UTC)

  想問一下@Temp3600君：除社群共識禁制外，您對於封鎖方針修訂及禁制方針剩餘的修訂（方針更名、局部封鎖移出禁制、全站範圍禁制等）有無其他意見？整理出社群禁制討論指導後，您又有無可能改變對於該程序的意見？我期望的是讓社群通過社群禁制程序等逐步改進以慢慢達成可建立一個具代表性的ArbCom的程度。--路西法人 2023年3月16日 (四) 01:28 (UTC)

  這個更改涉及的條文很多，今晚我先看了一部分。如果我認為某一項修訂影響重大，但未見討論，我將會提出分柝該部分的修改。

  社群禁制的本質問題在於新程序有什麼好處，以至必須獨立分家出來。此外，我反對任何通過"社群共識"逼使管理員封人的程序。法無禁止即自由，必須先立法後封人，也就是說，先有了不准做某事的共識，才談得上違反社群共識; 而不能是翻舊帳，在作出共識的時候將還沒立法時候的舊例子翻出來封人。社群眾人更積極參與封禁討論，提出事證等本身當然是好事。--Temp3600（留言） 2023年3月16日 (四) 15:24 (UTC)

  用一個更"哲學"的說法，就是社群共識本身也應被其他權力制衡。--Temp3600（留言） 2023年3月16日 (四) 15:25 (UTC)

  我什麼時候說過可以用原先不存在的共識（如方針指引）來禁制人了？社群共識的基礎必須是現存方針指引，但有時候一些行為方針無法全部明確定義（如WP:GAME、WP:POINT、WP:CIV等，很多條文都是類似「包括但不限於」）。這些是已長久存在的方針，但管理員雖然可能有自己對於某些行為是否有違此類方針有個人看法，即使有方針基礎也缺乏社群認同特定行為是否屬於該等方針所指的不當行為。此並非「法無禁止」（確實有禁止遊戲規則、闡述觀點而擾亂及不文明行為等），但特定行為是否觸犯方針恐怕永遠無法每次都討論加入方針，社群禁制正應是用在這些情況。--路西法人 2023年3月17日 (五) 00:24 (UTC)

  現存的ANM佈告板實質上也是社群禁制的制度：用戶提出請求、其他用戶辯論是否違反上述方針，管理員再視情況決定是否封鎖，只是現存ANM制度毫無規範而已。--路西法人 2023年3月17日 (五) 00:28 (UTC)

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

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

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

我的立場是條目名稱不會產生歧義的命名優先，且僅限於中國上古時代，論先到先得，有熊氏或軒轅氏更早，而我從來沒有提出要建立Alfredo ougaowen所謂「排除有族名的條目」的方針，將現代民族的命名排斥「族」是Alfredo ougaowen的主張。--康族（留言） 2023年3月7日 (二) 15:22 (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)

能力亦為必須。如果你要說我的留言在該案無助解決封鎖起因，那請你再讀一下2023年1月該用戶首次被封鎖前個用戶的「禮貌」留言他有沒有採納過，然後封鎖解除後又在其他用戶說明下是否屢次堅持其扭曲方針的立場而引來我再次回應他。最後警告模板採用的用詞是「這是對閣下的最後警告」，無法理解為何封鎖後反而「請停止某態度和行為」一句警告、直白指明錯誤之處、舉出反面教材也是「刻薄批判」，甚至經你連結的方針指引在暗示這些是違反禮儀及文明的留言，那我對於閣下非常失望。整個提案跟社群慣常流程完全不銜接，尤其是最後警告後封鎖卻要對連最後警告都忽略和開始扭曲的人客客氣氣這一點使我無法理解。--路西法人 2023年3月8日 (三) 01:43 (UTC)

該人是否采納先前的留言，是否扭曲方針與你在這起事件中的留言是否參雜個人情緒以至激化矛盾并無關聯。他不接受先前的留言，不意味著你也可以用刻薄的語句批判他。您在該案中的部分發言使他難堪，也無助於使他認識錯誤。請您以一般人的情感代入若在批評別人時加上類似您的那三句話，您便會接受麽？對方這種情況下，情緒的宣泄是否大於讓別人承認過失和認知自己的錯誤的本質？是否違反禮儀和文明，我也不需要暗示之類，因爲答案顯而易見。此外我已說過，我不反對直接地指出錯誤、反面教材等直言不諱的句子（在Mosowai中就有其他用戶的留言可使您藉鑒），但倘若這過程中加了一些過激的東西，反而與社群惯常精神完全不衔接，我也不認爲這類發言是所謂的“社群惯常流程”的必要一環。而您引用的信息頁正好有三個相關條文符合我所要表達的思想，强调了適當語句的必要，見以下：

强調“能力的必要性”并不意味着:

1. 这并不意味着一旦有人犯了错误就要狠狠教训他们：犯错在所难免，我们要让犯错者知道如何正确操作，只要下次不再犯同样错误就足够了。
2. 这并不意味着可以把某人标记成“无能者”：这是人身攻击行为，对解决问题没有帮助。应该对事不对人，而且说话做事时候不要刺激或打击对方。
3. 这并不意味着可以对确实无能的人不文明：刻薄的评论会使他们感到难堪，从而更加不愿承认自己问题或提高自己自身水平。

路西法人君，還請您理解這點。謝謝。——WMLO（留言）。 2023年3月8日 (三) 11:19 (UTC)

(－)反对：我认为你的动议不合时宜，态度类的内容交给态度指引（例如WP:CIV、WP:礼仪），并且态度本来就没办法强制，何况WP:不要人身攻击本来就有「“落井下石”是錯誤的」条款。方针指引的内容应该各自专注主题，没有必要混杂在一起。----Cat on Mars 2023年3月8日 (三) 15:17 (UTC)

對於閣下持續錯誤詮釋「謾罵」「刻薄」「無知」等詞感到遺憾，但進一步關於該被封鎖用戶的討論已離題，後續討論將轉至閣下討論頁探討。這不影響我對此案的立場，如同CatOnMars所言，無論是非對錯，此條寫入封鎖方針是不合適的，僅是重新詮釋了其他方針並套用於該特定情況，而完全沒有帶來實質的新觀念。方針內可指出需注意什麼其他方針指引，但如同閣下這種詮釋則是不恰當的。--路西法人 2023年3月8日 (三) 15:26 (UTC)

認爲您用“無知”等詞不妥或在認爲言語有待商榷者不止我一個，您談論這些詞匯的定義以讓高壓態度合理化，實則是忽略一般人看到你那些詞匯的感受。至於@CatOnMars態度無法强制，我抱有疑問：在封禁方針中就明定持續對他人展開擾亂和不文明行爲者，視同阻礙社群友善行爲的構成，得對其予以封禁，這足以説明正確之態度為構建社群良善氛圍之基礎。不過若認爲這類提案不應同封禁方針合并之，我也可提案于文明或禮儀頁面添加這類例子。—WMLO（留言）。 2023年3月8日 (三) 16:09 (UTC)

态度从来不应该是封禁的决定性因素，「持續對他人展開擾亂和不文明行爲者」才是，「不要人身攻击」才是，但绝对不应该仅仅因为态度封禁他人。从别人言语揣测态度本来就无异于指控他人思想罪、文字狱，何况很多人习惯直言直语不代表他刻薄或不友善，我们没有必要强迫别人做自己不喜欢、不习惯的事情，或言之仅仅为了社群「看起来」「听起来」「让别人觉得」文明友善就强迫他人更改说话方式。无论「己所不欲」还是「己所欲」都是「勿施于人」，这也是我的原则，我将始终捍卫这一点。你对态度的解释和责罚，无论动机如何，从各种历史经验（尤其包括文革）看都是极其危险的行为，所以态度只是非强制指引而不是强制性的方针。----Cat on Mars 2023年3月8日 (三) 16:38 (UTC)

個人思路認為Cat閣下說出對於強制機制之疑慮有一定合理性，但是草案內述明為請盡可能而並強制要求，而且如將閣下提及之個案經驗納入本案商定考慮範圍，更應該可適用作為支撐WMLO提案所專注之問題——綜合上述，個人認為可按修訂案文後追加修訂：參與溝通中請盡可能始終捍衛文明友善和平等互尊，在維基既定程序發揮作用外，單一以上用戶對已被程序禁制對象單純地一致肆意施以集體語言暴力會是極其危險的行為，任何用戶一旦發現並確定確實存在上述情形時，請依足諸維基傳統及規例做出應對

以上。--約克客（留言） 2023年3月12日 (日) 02:48 (UTC)

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

• 由於此案與封鎖方針重修不相關而不衝突，若此案在封鎖方針重修案前通過，新版封鎖方針通過並不能覆蓋此案所獲取共識（如有），故分拆處理。--路西法人 2023年3月8日 (三) 15:47 (UTC)
• (－)傾向反對，論述類的東西不要寫進方針比較好，畢竟無法從您的提案看出有沒有加上這句話能對問題處理有大的幫助--SunAfterRain 2023年3月10日 (五) 09:43 (UTC)

  方針只是有海陸軍的論述。——WMLO（留言）。 2023年3月14日 (二) 13:26 (UTC)

目前方针或指引有无有关“来源替换后对已写内容审核与修改”？

在最近几次编辑中发现有些编者先找到不符方针的来源（Telegram等普通社交媒体发文，甚至自己云端文件）进行编写，而后自身或其他编者在找到有关不一定可靠但可使用的来源后替换但对内容不加以修改。所以想问是否有方针或指引要求“对替换来源者要求对已写内容审核、修正”？没有的话，能否建立？--MINQI（留言） 2023年3月8日 (三) 21:37 (UTC)

“描述应该符合来源”这个观点，这不是可靠来源、可供查证的要求？——Sakamotosan路过围观 | 避免做作，免敬 2023年3月9日 (四) 01:12 (UTC)

问题出在部分编者只管来源替换不管内容与新来源是否契合。--MINQI（留言） 2023年3月9日 (四) 01:21 (UTC)

若如此，是编辑者没有遵守早已存在的方针或指引而引起问题。不需要建立新的方针或指引。—— 月_樱_雪 (留言) 2023年3月9日 (四) 02:48 (UTC)

是的，Wikipedia:可供查證#举证的责任就有一句「引用的来源须明确支持条目中出现的信息」。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年3月9日 (四) 07:21 (UTC)

謝謝您:感谢月_樱_雪、魔琴两位解答。--MINQI（留言） 2023年3月9日 (四) 08:54 (UTC)

重提草稿化討論

維基百科:草稿命名空間/2022年更新草案似有充分支持意見（先前討論：一、二）而未走公示程序，重推一下。通知@QiuLiming1、HTinC23、Cwek、YFdyh000、Kriz Ju、S8321414、Temp3600。--路西法人 2023年3月9日 (四) 02:57 (UTC)

看上去沒多大問題，但之前看到有人直接把條目移動到draft空間後就沒任何操作，就等於只做了草稿化操作指南第一條的第一點。--日期20220626（留言） 2023年3月9日 (四) 03:54 (UTC)

程序未正式訂立，有人沒能跟從操作尚不算不合理。--路西法人 2023年3月9日 (四) 04:36 (UTC)

"請將草稿頁面內殘留的頁面分類標記和非自由圖片連結化"最好有小工具協助完成。如果單靠人力，偶有遺漏實屬人之常情。--Temp3600（留言） 2023年3月12日 (日) 17:03 (UTC)

還有就是如果有人（比如作者）不同意移動到草稿，就提交到條目存廢討論決定去留嗎。--日期20220626（留言） 2023年3月9日 (四) 03:57 (UTC)

@LuciferianThomas：相关的，如果有巡查先按以往巡查操作给予了操作（包括标识问题、SD、AFD等），也就是不给予草稿化，然后其他编辑能否推翻这些决定，将其草稿化？——Sakamotosan路过围观 | 避免做作，免敬 2023年3月10日 (五) 00:42 (UTC)

（為什麼ping我，我只是幫忙把舊討論拉出來而已）理應不衝突，但建議如果其他巡查員已做事，草稿化後通知一下做事的巡查員會比較好。--路西法人 2023年3月10日 (五) 00:50 (UTC)

看起來沒什麼問題，應該可以繼續推進。--冥王歐西里斯（留言） 2023年3月9日 (四) 05:07 (UTC)

如果不具强制性的话，可以考虑（有些编辑愿意好人做到底的话）。不过“质量明显不符合标准”的章节条件，似乎有点像完全兜底，SD不用SD，AFD预期不会保留的，小作品不挂小作品，全部可以扔去草稿，那这些之前机制好像没有了存在的意义？——Sakamotosan路过围观 | 避免做作，免敬 2023年3月10日 (五) 00:35 (UTC)

之前的機制指的是？--日期20220626（留言） 2023年3月10日 (五) 00:38 (UTC)

正常情况下，该SD就SD（例如G11，你会扔草稿？），该AFD就AFD（保不保留是讨论后决定，不做结果水晶球），小作品就挂小作品等30天。这些就是之前机制。——Sakamotosan路过围观 | 避免做作，免敬 2023年3月10日 (五) 00:45 (UTC)

原則上應該是不符合SD、AFD、小小作品，但又不適合保留在條目空間的才會走草稿化吧，閣下覺得這裡的文字要怎麼修正才能體現這個流程？--冥王歐西里斯（留言） 2023年3月10日 (五) 01:23 (UTC)

是我的错误，没考虑前提条件是条件“全部符合”才需要考虑草稿化，这是其中的一个子条件。——Sakamotosan路过围观 | 避免做作，免敬 2023年3月10日 (五) 01:55 (UTC)

G11的作品如果有關注度但是自己想改善，可以先移動到草稿。不過大部分情況下想改善的人少，所以就直接G11了。--日期20220626（留言） 2023年3月10日 (五) 01:45 (UTC)

畢竟符合G11的條目基本上都是刪後重建比較快（。--冥王歐西里斯（留言） 2023年3月10日 (五) 02:45 (UTC)

“旧条目或不全满足以上条件的新条目不应直接草稿化，而须在存废讨论寻求草稿化共识或提报侵权。”，后面“或提报侵权”是不一定的操作，或者替换成“或其他页面处理方式（包括提报侵权）。”——Sakamotosan路过围观 | 避免做作，免敬 2023年3月10日 (五) 00:42 (UTC)

我認為應該加入英維在昨年通過的條款——當條目已經建立90天（或其他合理的日數），不應草稿化。--Ghren🐦🕖 2023年3月10日 (五) 11:30 (UTC)

那中維的話可以限定為未被巡查的新條目？--日期20220626（留言） 2023年3月10日 (五) 11:33 (UTC)

那也可以，畢竟那條是說除非在AFD達成共識，否則不應把在條目空間超過90天的條目移動到草稿空間。--冥王歐西里斯（留言） 2023年3月10日 (五) 11:35 (UTC)

巡查时限为30日，个人觉得30日足矣。 ——魔琴 [ 留言 贡献 新手2023计划 ] 2023年3月10日 (五) 15:32 (UTC)

英維設90天應該是給一些沒有被即時巡查到的條目對巡查員給予寬限期啦，但限定為巡查期限內的好像也不是不行就是。--冥王歐西里斯（留言） 2023年3月10日 (五) 22:58 (UTC)

• 支持繼續推進。草稿化能給予新手更充足時間改寫條目，並尋求其他編者的幫助，有助緩和巡查員與新人之間的沖突。--Temp3600（留言） 2023年3月12日 (日) 16:59 (UTC)

每个人对草稿化“有发展成完整条目的潜力”的标准不同，执行起来或许会有争议。不如把草稿化作为AFD的一个处理结果。--Steven Sun（留言） 2023年3月13日 (一) 08:06 (UTC)

目前AFD的其中一個結果就會是草稿化（但很少出現），提這個討論的目的應是把目前部份巡查員做的事情指引化（因為部份條目真的不適合留在條目空間，但刪掉又很可惜），讓之後的編者有個可以遵循的依據。--冥王歐西里斯（留言） 2023年3月13日 (一) 23:24 (UTC)

• 草稿化可以是AFD的結果，但其潛力更在於供巡查員處理新人條目這一方面。--Temp3600（留言） 2023年3月13日 (一) 15:19 (UTC)

(＋)支持&(！)意見：敝人不熟草稿流程，但支持持續推進，同時覺得草案所提及的草稿整理實務，對於巡查員或打算申請權限的用戶可能也是個可以參考的標準。另支持「舊條目或不全滿足以上條件的新條目不應直接草稿化，而須在存廢討論尋求草稿化共識或其他页面处理方式（包括提报侵权）。」。--Kriz Ju（留言） 2023年3月16日 (四) 18:32 (UTC)

建议将WP:EVENT升格为社区正式指引

前续Wikipedia:互助客栈/条目探讨#准备批量清理Category:2022年中国大陆2019冠状病毒病聚集性疫情的条目的讨论，除了聚焦性疫情的条目，其实还有很多关注度有待商榷的条目需要进行清理，而这个问题的解决方案可能要归结到WP:EVENT上面来。综合前几次升格讨论，再结合目前WP:EVENT的实际情况，个人觉得需要打磨的地方还是特别多，在此向大家征求修改意见，争取在正式投票前完善现有内容。--百战天虫（留言） 2023年3月14日 (二) 04:15 (UTC)

(＋)支持--🎋🍣 2023年3月14日 (二) 12:18 (UTC)

(－)反对 這樣會讓大量多年來建立的歷史事件條目有被刪除的危機，對讀者是不利，接收的資訊比以往更少。日後可能要出海外的圖書館才能查閲。--Wpcpey（留言） 2023年3月14日 (二) 12:26 (UTC)

你说的理由也可以用来反对现行的WP:GNG。--百战天虫（留言） 2023年3月15日 (三) 15:43 (UTC)

(＋)支持：這個提案從十二年前就獲得大量用戶的認可，只是因爲細節問題暫且擱置。之後的一些指引中也有相應的條文，屬於事實上無冕規則。——WMLO（留言）。 2023年3月14日 (二) 13:24 (UTC)

(＋)支持--冥王歐西里斯（留言） 2023年3月14日 (二) 14:03 (UTC)

雖然此項關注度指引未正式通過，但社群的GNG關注度流程大概也是以跟隨此指引類似的標準的，故(＋)支持正式訂為指引。對於上面那個反對毫不意外，沒來反對才奇怪。--路西法人 2023年3月14日 (二) 15:56 (UTC)

(＋)支持：同時小改錯別字。--Kriz Ju（留言） 2023年3月15日 (三) 18:54 (UTC)

在本地配套機制及慣常措施未能適切發揮制約作用的情況下，有必要將該升格程序分拆及設定週期檢討期限，一旦發現該規限是被濫用或不合比例地適用，就應當啟動中止及重新審訂之程序——綜合改進過程，必要是將WP:MAJORITY、WP:NOTWIKI、WP:JNN、WP:BELONG、WP:JUSTAPOLICY、WP:IDONTLIKEIT、WP:DEFUNCTS等約定及關聯章節，同時間匹配地升格地位，並且強化及細化關聯章節之限制力以及反推作用，確保升格過程及後續影響不會偏頗地發生一邊倒效果。--約克客（留言） 2023年3月16日 (四) 02:48 (UTC)

如果是这样的话，会不会先讨论升格一下阁下所说的这些个规则比较好，起码可以提前上个保险啥的。如果是这样做，工程量肯定不小，不知道可不可以开个集中讨论。--百战天虫（留言） 2023年3月16日 (四) 05:41 (UTC)

en:WP:AADD也只是論述，且逐段提升也不是好主意，就算要也是整個WP:AADD提升指引；但不認為有任何執行價值，違反了也不認為可以導致任何後果，頂多就是提醒或忽略，沒有提升的意義。--路西法人 2023年3月16日 (四) 06:19 (UTC)

目前方针很明显还没有完善，连最基本的出发点也错了。WP:EVENT本则上所依的条文是WP:NOTINFO和WP:NOTNEWS，而非关注度条文。上方的疫情条目相信有不少条目是合「有效介绍」、「可靠」、「第二手」、「独立」的标准，但依WP:NOTINFO和WP:NOTNEWS不应收录。需要大幅修订。--Ghren🐦🕓 2023年3月16日 (四) 09:24 (UTC)

？某些例行的新聞種類（包括絕大多數的犯罪、事故和死亡報道，名人或政治新聞，「震驚」新聞，缺乏持續價值的「奇聞」以及病毒傳播現象），無論是否悲劇，無論是否在當時被報道過，通常都不具有關注度，除非有其他事件可以賦予其持續的意義。--路西法人 2023年3月17日 (五) 00:32 (UTC)

“A地－B地关系”是不是该用短横线？

此话题无关“一字线的符号选择”，故另开一节。许多“A地－B地关系”条目标题用的是一字线，方针草案《WP:命名常规 (国际关系)》中谈及有关内容也用的是一字线，但是窃以为应该用短横线。按我对GB/T 15834-2011的理解，连接号只有表示“起止”时才该用一字线，而“A地－B地关系”中的连接号并不表示起止。

中华人民共和国外交部网站上有些类似情况也用了一字线。然而窃以为，国家标准与外交部网站不同的时候，参照前者会更合适，故仍应使用短横线。--爱维基百科的CuSO₄ 2023年3月14日 (二) 21:19 (UTC)

註釋