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

快捷方式

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

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

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

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

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

公告欄

[人事] Manchiu、UjuiUjuMandan、ASid、ATannedBurger获提名为管理员，AT获提名为监督员，欢迎踊跃参与提问和讨论。
[公告] 現時已改為只有延伸確認用戶可以使用內容翻譯將頁面釋出到主條目空間，如有疑問及意見，歡迎參與相關討論。
[公告] 回饋請求系統正在試運作中，誠邀用户訂閱以接收討論通知。用户訂閱有興趣參與的討論議題後，机器人會自動在新討論發起時隨機抽取部分用户發消息通知。
[公告] “阅读无障碍”功能字體大小更改及「大字體」小工具調整已經通過。
[公告] 修訂維基百科不是維基物種、IP封禁豁免权授予者的顶部图标及將小紅書評為通常不可靠正在公示，如有意見請盡快提出。
[討論] 互助客栈技术区正在討論ToolsRedirect创建的繁簡重定向問題，請踴躍參與討論。
[討論] 互助客栈方针区正在討論電視條目播放資訊增加收錄準則及再擬議立國際關係命名常規為方針，請踴躍參與討論。
[討論] 互助客栈其他区正在討論第二十二次動員令籌備相關事宜、对新闻动态获选标准及ITNR规则的小修订及頁面評級與通用評級行政層面上的統合方案，請踴躍參與討論。
[请求] 请协助处理修订版本删除请求积压！

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

存檔

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年	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	月

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	提議提高條目評選投票資格門檻	81	23	For Each element In group Next	2024-05-02 11:29
2	再擬議立國際關係命名常規為方針	39	10	Kethyga	2024-05-02 08:40
3	修订删除方针明确允许删除没有来源30日以上的条目	43	7	Cwek	2024-05-01 21:34
4	Quick CU introduction	11	6	Ericliu1912	2024-05-01 12:24
5	提議英維指引en: MOS:TVINTL經本地化後引入中維維基百科:格式手冊/電視	62	8	YFdyh000	2024-05-02 03:36

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

正在廣泛徵求意見的議題

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

維基百科格式與命名

Template talk:Infobox person § 修改 Infobox person 中 native_name 参数位置

可能需要进一步讨论以便获得共识。--Kethyga（留言） 2024年4月24日 (三) 05:15 (UTC)

維基百科方針與指引

Wikipedia talk:维基百科不是什么 § 修订方针维基百科不是维基物种

此討論正在公示7天，直至2024年5月8日 (三) 17:00 (UTC)結束；如有意見請儘快提出。

現行條文

維基百科不是手冊、攻略書、教科書、或科學雜誌（略）

提議條文

維基百科不是手冊、攻略書、教科書、科學雜誌或物种列表（上略）

8：維基百科有关于物种详细介绍的内容，但如仅列出物种列表，姊妹计划维基物种可能更适合这种内容。

--Python6345（留言） 2024年3月23日 (六) 02:26 (UTC)

Wikipedia talk:共识 § 共識建立的遞進步驟

推行RFC後，我發現很多人沒理會非強制性的提示，導致WP:VPD持續過長。我提議調整方針，明確共識建立的遞進步驟，確保各討論頁獲得善用。--路西法人 2024年4月8日 (一) 09:58 (UTC)

Wikipedia:互助客栈/条目探讨 § 盛岡市的導言和宣傳的定義

https://zh.wikipedia.org/w/index.php?title=%E7%9B%9B%E5%B2%A1%E5%B8%82&diff=prev&oldid=82050595

如連結所示，user:tofugamay認為闡述盛岡市是縣內的人口、政治與經濟中心是在宣傳，但典範條目的札幌、函館與福岡皆有先例，且優良條目中的秋田市與新潟市也有前例，與因此想請問各位的意見。我個人認為隨意將看起來像在宣傳的文字直接定義成是在宣傳非常不妥，因典範與優良條目中皆有先例，若任意否決與經同行們審查並核可使用的相似形容，等於是無視當今編輯慣例與同行審查的過程，因為那些文字是在審查時就有的內容。而對方先前對於宣傳性的定義也相當不明理，認為導言涉及當地產業的簡述和特產的簡述就是在宣傳，但先前已有多位資深編輯員表示不違反規則，如user:AT和user:CryptidNext，而導言若只是簡單描述近年來某城鎮以發展觀光業為主，及當地特產為西瓜和蘋果等，我認為不至於在宣傳，因宣傳需帶有特定態度與字眼，不宜直接說死。這次的事已告知對方，但礙於之前我跟他才剛暫時結束一個大紛爭，只能來尋求版上各位的看法，因他也不一定會回我。

典範與優良條目連結如下: https://zh.wikipedia.org/zh-tw/%E7%A7%8B%E7%94%B0%E5%B8%82 、 https://zh.wikipedia.org/wiki/%E6%96%B0%E6%BD%9F%E5%B8%82 https://zh.wikipedia.org/wiki/%E7%A6%8F%E5%B2%A1%E5%B8%82 、https://zh.wikipedia.org/wiki/%E5%87%BD%E9%A4%A8%E5%B8%82 --雪雨73（留言） 2024年4月21日 (日) 13:19 (UTC)

Wikipedia talk:消歧义 § 请问以下消歧义的存在是否合理？

我发现到诸如阮副總統、蕭副總統、李副總統等一大堆“同姓称号消歧义”。请问这些消歧义的存在是否合理？另外，Category:假名消歧義和Category:諺文消歧義里的一堆消歧义的存在是否也合理？这些消歧义非中文/罗马字，请问中文维基需要这种消歧义吗？@Sdf：在此通知这些消歧义（大部分）的建立者。--微肿头龙（留言） 2024年4月25日 (四) 07:52 (UTC)

維基百科提議

Wikipedia talk:仲裁委员会 § RfC：2024年2月

接續上段，繼續提請討論仲裁委員會的執行細節。目前討論中的範疇包括：

授予權限：向仲裁委員會授予什麼權限？
權限限制：如何限制仲裁員在委員會職務以外使用權限？
選舉信任度下限：目前以50%為最低可當選門檻，是否有需要調高？
管理人員解任處理：管理人員解任在多大程度由仲裁委員會處理？
其他準備工作：包含相關頁面籌備與部署、技術問題及其他需要處理之事項。

--路西法人 2024年2月16日 (五) 02:13 (UTC)

Wikipedia talk:回饋請求服務 § 将回馈请求系统用于存废讨论和存废复核

感觉“回馈请求”就是之前为了解决存废讨论积压提出的“邀请讨论”类似的东西，此系统是否可以用于存废复核以便解决积压？--桐生ここ★[讨论] 2024年3月6日 (三) 04:01 (UTC)

Wikipedia talk:字詞轉換處理/公共轉換組 § 思路：條目預儲公共轉換組中匹配的規則，減少載入時間

近年有些公共轉換組越來越大，導致所嵌入的各條目等頁面_{（爲便説明下稱「條目」但不限於條目）}載入越來越慢，爲人詬病。而若條目預先儲存公共轉換組中與條目中字詞相匹配的轉換規則，並適時更新：— Gohan 2024年3月12日 (二) 05:00 (UTC)

Template talk:Twitter § Twitter改為X

因應Twitter已改名X一段時間了，因此提請討論是否做相應更改。臺灣杉在此發言 (會客室) 2024年4月18日 (四) 04:10 (UTC)

Wikipedia:互助客栈/其他 § 对ITN获选标准及ITNR的小修订

此前的相关讨论：

最近Wikipedia:新闻动态候选出了一些问题：

第一，在社群讨论没有得出支持刊登的情况，管理员自行刊登内容，如Wikipedia:新闻动态候选/存档/2024年3月#亚伦·布什内尔自焚事件；

第二，部分内容在刊登之前没有收到反对意见，刊出之后被质疑关注度或重大性不够，如Wikipedia:新闻动态候选/存档/2024年4月#習馬二會；

第三，涉及中国载人航天工程的条目近期在提名时多被社群以不具备突破性为由反对，见Wikipedia:新闻动态候选/存档/2022年6月#神舟十四号、Wikipedia:新闻动态候选/存档/2023年6月#神舟十六号、Wikipedia:新闻动态候选/存档/2023年10月#神舟十七号和Wikipedia:新闻动态候选#神舟十八号。

针对以上的第一条及第二条问题，提案对现行的ITN获选标准作出如下修订：

現行條文

管理员在每次更新栏目时，应当查看新闻动态候选区内所有提案。管理员认为提案符合新闻动态候选标准的，应予采纳；不符合候选标准的，应由管理员陈述意见后退回重审。有二名及以上维基人提出反对意见的，亦应当退回重审。

提議條文

管理员在每次更新栏目时，应当查看新闻动态候选区内所有提案。管理员认为提案符合新闻动态候选标准，或支持刊登的意见占大多数的，应予采纳；不符合候选标准的，应由管理员陈述意见后退回重审。有二名及以上维基人提出反对意见的，亦应当退回重审。
对于刊登之后出现反对意见提案，管理员应暂时移除相关内容，直至社群得到支持刊登的共识。对于没有得到绝对结论的提案，需要有二名及以上的管理员进行商讨，以最终决定是否刊登。
提案新闻内容涉及需要地区词转换的用字，提案人需要先自行处理。

针对以上的第三条问题，提案对现行的WP:ITNR作出如下修订：

現行條文

载人轨道航天器的发射升空；一个国家首次成功完成自主发展的轨道发射；发射空间站或其主要组成部分；航天器抵达月球或更远的目的地；重大航天任务失败

提議條文

每款载人轨道航天器首次发射升空；每款载人轨道航天器與特定空间站首次成功對接；一个国家首次成功完成自主发展的轨道发射；发射空间站或其主要组成部分；航天器抵达月球或更远的目的地；重大航天任务失败

正如WP:NOTNEWS所说，维基百科不是新闻报道。新闻动态候选和Portal:新闻动态设立的初衷也不是为了提供新闻报道，“是为了鼓励增订或更新相关的条目，而不是用作新闻报道”。由此可见，社群应该从百科性的角度来提报及衡量新闻动态条目，一些不具备百科性的条目能不提报就不提报，能不刊登就尽量不刊登，毕竟“维基百科不是新闻报道”。所以，新闻动态的标准也尽量严谨。上述的修改意见只不过是抛砖引玉，欢迎社群在此提案的基础上踊跃讨论。--Jeffchu2014（留言） 2024年4月28日 (日) 17:08 (UTC)

Template talk:Hang on § {{hangon}}

Template:Db-meta（英语：Template:Db-meta）的格式在之前的討論中，無法解決标记提速删页面上的速删状态；如果用機器人的方式來處理，是否可行？臺灣杉在此發言 (會客室) 2024年4月30日 (二) 08:33 (UTC)

專題命名空間

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间（錯誤：Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间是重定向頁面）。

[編輯此導航模板] 設立新命名空間及偽命名空間無共識：2018年12月的先前討論全案結以待續：第一輪討論 - 開放偽命名空間作捷徑連結用結以待續：設立LTA、MOS、PJ三個偽命名空間結以待續：升格維基專題為命名空間結以待續：修正命名空間資訊頁面結以待續：將「Wikipedia:捷徑」訂為方針完結：第二輪討論完成部署：設立專題命名空間相關討論及任務已通過：討論升格維基專題為命名空間任務完成：向Phabricator申請部署維基專題命名空間已合併：在Gerrit提交所需修正編碼任務完成：在Phabricator請求合併編碼完成：事實性修訂「Wikipedia:命名空間」以包含新的維基專題命名空間完成，待檢查：將專案命名空間下的維基專題移動至維基專題命名空間專題移動列表專題重定向移動列表已完成：修正指向專題的內部連結機器人任務已完成：調整專題模板已通過：討論捷徑的設立方式已通過：其他議題討論完結：設立偽命名空間相關討論已通過：討論設立LTA及MOS偽命名空間供捷徑使用已否決：設立捷徑空間供LTA/MOS捷徑使用已否決：設立捷徑空間作其他用途結以待續：升格LTA為命名空間完結：後續討論處理事項完成：修改機械人操作不提刪偽命名空間捷徑無結論：格式手冊新捷徑名稱討論 MOS捷徑列表已否決：舊捷徑改為軟重定向完成：設置預設啟用小工具已否決：自動半保護偽命名空間條目已通過：提議設立新快速刪除標準完結：第三輪討論已否決：捷徑命名空間已完成：捷徑指引草案修訂已通過：增設更多偽命名空間（一）已通過但未實行：第三次推动设立LTA命名空间

本主題全部或部分段落文字，轉移自Wikipedia:互助客栈/方针#WP:捷徑指引草案修訂。执行人：臺灣杉在此發言 (會客室)。標記人：_{_{來人啊，餵宮子吃布丁！}} ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月14日 (四) 06:44 (UTC)。[回复]

捷徑指引草案的討論，源自於「偽命名空間」的討論，英語維基百科對於捷徑相關的規範及偽命名空間的設立已有成熟的執行方式。中文維基百科中的部分編輯者對於「格式手冊」、「長期破壞者」及「專題」這三個主題提出可升級成命名空間或以偽命名空間形式存在，並有正反兩方的陳述與看法。

目前較為接近共識的是「專題」提升為正式命名空間，反對者的論述已由支持者回應，且反方無進一步論述。然為求慎重，且將捷徑與命名空間等議題作系統性討論，將會執行階段修訂，以取得最大共識。

本討論的各階段分為：

~~專題提升為命名空間與否及其細節~~；
~~格式手冊及長期破壞者是否成為命名空間或偽命名空間~~；
偽命名空間規範寫入捷徑規範內（如前項通過）或是否允許偽命名空間（如前項不通過）；
捷徑規範細部討論並決定是否成為指引。

各階段不得同時討論，前一項討論完結之後，才能進行下一段討論。臺灣杉在此發言 (會客室) 2020年12月10日 (四) 05:47 (UTC)[回复]

專題命名空間通過，剩餘細節獨立討論。臺灣杉在此發言 (會客室) 2021年1月11日 (一) 11:20 (UTC)[回复]

目前的後續討論須等phab:T271612佈署完畢後才能繼續進行。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月12日 (二) 13:08 (UTC)[回复]

說明稍微看了一下先前韓文維基的申請phab:T29651，其工程師處理的流程將近一個月，故認為應該還要一段時間才能完成布署，故暫時先撤下公告Special:Diff/63712969、Special:Diff/63713130，等到了Code Review階段時再放回。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月14日 (四) 06:18 (UTC)[回复]
- 完成：程式碼已Commit到gerrit:657572，並已佈署，恢復原有公示，基於原有時間再延長3天。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月26日 (二) 20:03 (UTC)[回复]
- (補)：更新，WP:偽命名空間已通過。-- 五歲抬頭雪菲（☎️·☘️） 2021年3月17日 (三) 06:41 (UTC)[回复]

已通過：

已

公示7日無合理異議，本議案通過。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月3日 (日) 07:44 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

直接將PJ:獨立為新WP:命名空間

(＆)建議像日文維基那樣，專題直接變成一個 "真" 名字空間 ja:Help:名前空間#プロジェクト就不會有cwek說的 "假" 名字空間的混淆問題了。日維相關討論。 -- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年11月16日 (一) 06:06 (UTC)[回复]

先前討論

(＝)中立，但此僅為其中一個被提議的偽命名空間提供了替代方案，那麼另外的LTA:和MOS:呢？--LuciferianThomas．留言 2020年11月16日 (一) 09:32 (UTC)[回复]

一個一個來。肯定會有方法的。pj是有多個維基實行過，且效果不錯，可行性較高，也不會混淆。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年11月16日 (一) 13:10 (UTC)[回复]

好的。(＋)傾向支持吧，始終我不太清除其他維基項目對此的執行，不過覺得與維基空間的內容有點距離，可以自己分離了。--LuciferianThomas．留言 2020年11月16日 (一) 15:19 (UTC)[回复]

LTA和MOS感覺不足以達到獨立名字空間門檻，且其他語言維基也沒先例，故不提案。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年11月16日 (一) 15:32 (UTC)[回复]

意思使用新建一個「專題」的空間，把Wikipedia:ACG專題移動到專題:ACG；然後把PJ作為「專題」名字空間的別名？--洛普利宁 2020年11月16日 (一) 16:01 (UTC)[回复]

从这个动议的内容上看应该是这个意思，开辟一个“WikiProject”空间，简称"PJ"，中文为“专题”和“维基专题”--MilkyDefer，推迟，咕咕 2020年11月16日 (一) 16:11 (UTC)[回复]

大概就類似User:青子守歌用戶頁裡面的ja:利用者:青子守歌/frwpのウィキプロジェクト名前空間と参考文献名前空間。日文維基佈署很久，沒甚麼太大的問題。且專題:ACG比Wikipedia:ACG專題淺顯多了，並也允許PJ:ACG這樣的連結方式。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年11月16日 (一) 17:24 (UTC)[回复]

(＋)支持 ——羊羊 (留言|贡献) 2020年11月19日 (四) 15:49 (UTC)[回复]
大致(＋)支持（LTA和MOS可以單獨開成新的，即簡稱直接當本名，格式手冊當別名）-- Sunny00217 2020年11月22日 (日) 12:26 (UTC)[回复]

小總結

根據以上討論，目前共有兩個選項：

開放偽命名空間；
將PJ納入命名空間並作為別名，MOS、LTA再行討論。

偽命名空間看起來是3人反對，5人左右支持，僅能算過半支持，但也未達到絕對多數，且目前還沒看到反對方出來針對正方回應進行進一步論述。而部分支持偽命名空間的使用者也不反對後者的提案。

所以目前的共識傾向為將PJ（專題）獨立成為新的命名空間，偽命名空間將繼續討論。因本討論最後一次發言起過5日，公示期延長為9日。因此現在起 公示9日，2020年12月6日 (日) 03:26 (UTC) 結束。臺灣杉在此發言 (會客室) 2020年11月27日 (五) 03:26 (UTC)[回复]

至於遺留下來的問題，將會由下方討論繼續進行。臺灣杉在此發言 (會客室) 2020年11月27日 (五) 03:37 (UTC)[回复]

反對將專題獨立為（偽）命名空間。眾所皆知維基專題在本地一直發展不起來，除部分專題有實質工作外，多數專題基本上就只有評級的作用而已。連專題發展蓬勃的英文維基百科都沒有將專題獨立為（偽）命名空間了，本地大概更沒需要。另外，我從沒見過哪位編者用PJ代指維基專題的，多半直接用專題簡稱。現在這樣子感覺像是為獨立而獨立，硬是找一個英文縮寫當作別名。反倒是LTA，我覺得可以獨立為偽命名空間。—— Eric Liu_{創造は生命（留言．留名．學生會）} 2020年11月27日 (五) 04:19 (UTC)[回复]

不是偽，是「真」。「專題:數學」顯然比「維基百科:數學專題」更簡潔。見日語維基和法語維基。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年11月27日 (五) 08:05 (UTC)[回复]

等等，PJ:和P(ortal):的区别我没太搞清。哪位可以解释一下？Zhuofan Wu^{Cien años de soledad} 2020年11月29日 (日) 03:08 (UTC)[回复]

“

与专供维基编者使用的维基专题不同，维基主题是同时为编者及一般读者服务的。

”

—— Portal:首页

——羊羊 (留言|贡献) 2020年11月29日 (日) 04:11 (UTC)[回复]

一個是Portal，一個是Project。--臺灣杉在此發言 (會客室) 2020年11月29日 (日) 08:31 (UTC)[回复]

如果要細節的話：Portal（主題）有點類似各知識領域的主頁，展示該領域重要或優良的條目之用；Project（專題）則是說明該領域知識的編輯建議與規則，以及該領域社群的討論場所。臺灣杉在此發言 (會客室) 2020年11月29日 (日) 10:07 (UTC)[回复]

Wait，有bug。Project命名空間在中文維基百科等價於Wikipedia命名空間。SAN MO SA _SPQR 2020年11月29日 (日) 14:24 (UTC)[回复]

不成問題，見日維相關討論。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年11月29日 (日) 14:28 (UTC)[回复]

那倒不如直接設PJ命名空間在中文維基百科等價於Wikipedia命名空間（如同WP命名空間），反正各專題現時皆在Wikipedia命名空間下，這樣會較能保持一致性，也不會衍生Project的指代問題。SAN MO SA _SPQR 2020年11月29日 (日) 14:33 (UTC)[回复]

那这样起不到“减少命名冲突”的效果…… ——羊羊 (留言|贡献) 2020年11月30日 (一) 22:06 (UTC)[回复]

@Sanmosa：見下-- Sunny00217 2020年12月2日 (三) 14:25 (UTC)[回复]

我在这里作出过的留言可供参考。--MilkyDefer，推迟，咕咕 2020年11月29日 (日) 16:16 (UTC)[回复]

依照目前公示後討論情況，將會和下面的捷徑指引案併案討論，並採取分階段修訂。今天晚上會進行整合。臺灣杉在此發言 (會客室) 2020年12月6日 (日) 07:38 (UTC)[回复]

(？)疑問@Taiwania Justo：所以有沒有要建專題空間？-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年12月9日 (三) 13:56 (UTC)[回复]
還在整理中，不過順序是這樣：先調查LTA、MOS和PJ是否升格為正式空間，第二層是偽命名空間，第三層是捷徑修訂。--臺灣杉在此發言 (會客室) 2020年12月9日 (三) 14:57 (UTC)[回复]
@Taiwania Justo：仍然建議從專題（PJ）空間開始會比較容易。畢竟日維和法維等維基有專題:名字空間，代表我們可以參考他們的建置過程及申請方式；然而LTA:和MOS:目前似乎沒看到有其他語言維基百科或姊妹計畫有此「真」名字空間設定，代表建置過程及申請方式全部都是要由我們本地自己建，難度會比較高。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年12月9日 (三) 17:07 (UTC)[回复]

依據先前討論，專題命名空間的討論已接近達成共識之階段，目前問題包含：

英文命名部分，其一為Project並取消與Wikipedia空間連動，其二為以WikiProject命名；
部分使用者認為直接將PJ與Wikipedia連動即可。

請討論。臺灣杉在此發言 (會客室) 2020年12月10日 (四) 05:47 (UTC)[回复]

个人以为Project名字空间肯定不能变，否则可能会造成不少链接失效。因此名字空间应该命名为“WikiProject”，对应的中文名字空间应该命名为“维基专题”，以便于与“WikiProject”对应。——BlackShadowG（留言） 2020年12月11日 (五) 16:27 (UTC)[回复]
- 我認為中文叫做「專題」並無不妥，也無衝突。將「WikiProject:」作為程式系統前綴；「專題」、「維基專題」、「PJ」作為別名。其他中文別名也可以之後再議再補。並依照法維和日維和其他姐妹計劃的統一定義，定為{{ns:102}}(目前顯示為「WikiProject」，空白是因為本地尚未實裝）。— ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年12月11日 (五) 18:16 (UTC)[回复]

確定英文名稱不會衝突就可以，中文名稱應該沒問題。SAN MO SA _SPQR 2020年12月12日 (六) 03:34 (UTC)[回复]

支持命名为WikiProject/专题 ——羊羊 (留言|贡献) 2020年12月16日 (三) 15:08 (UTC)[回复]

若自羊羊32521留言2020年12月16日 (三) 15:08 (UTC)的一周後未有新意見可以先公示這個部分。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年12月22日 (二) 07:55 (UTC)[回复]

公示7天：理據：本議題先前公示並通過的討論已討論滿一個月，且自本討論上次有效發言羊羊32521留言2020年12月16日 (三) 15:08 (UTC)已逾一周，根據WP:7DAYS公示七天。如通過，屆時具體的做法可以參考phab:T26852 -- _{來人啊，餵宮子吃布丁！} ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年12月24日 (四) 08:47 (UTC)[回复]
- 公示什么？ ——羊羊 (留言|贡献) 2020年12月26日 (六) 10:21 (UTC)[回复]
  - @羊羊32521：將專題升為名字空間啊（公告欄上有）主要是細節，程式名稱定為WikiProject、然後「專題」、維基專題、PJ作為別名，並且參考phab:T26852將Namespace id 設為102討論頁以此類推（WikiProject_talk;103;專題討論,維基專題討論）。其餘請參考先前討論、發布公示的留言以及公布欄，另補充一個2018年在WP:TG上討論出的草案。— ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年12月26日 (六) 12:47 (UTC)[回复]
專題這種東西本來就都沒有什麼用戶在關注了。所以什麼都不問，只問一個問題：請問這樣一來那些原本已經用於條目討論頁上的專題名稱會不會有影響？--Z7504非常建議必要時多關注評選（留言） 2020年12月31日 (四) 08:42 (UTC)[回复]
- @Z7504：例如WP:ACG专题會變成專題:ACG（_{現在先不要改哦，會違反快速刪除方針準則}）。以此類推。此外本議題先前公示已經通過了，這次是細節公示。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年12月31日 (四) 09:43 (UTC)[回复]
既然木已成舟，大家意見如此，我也沒法反對什麼，但是請提案者一定要做好配套措施，以免留給本地社群一堆爛攤子去收。—— Eric Liu_{創造は生命（留言．留名．學生會）} 2020年12月31日 (四) 11:32 (UTC)[回复]
- 參考日文維基當時做法，預計會分階段完成設立，不會留爛攤子。但需要一些時間來執行。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月1日 (五) 19:19 (UTC)[回复]

自上周補充公示共識內容的發言 2020年12月26日 (六) 12:47 (UTC)後已公示逾一周，公示期內無合理異議，本議案通過。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月3日 (日) 07:44 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

專題空間設立流程與細節

參考ja:Special:PermaLink/39099771#ウィキプロジェクト用名前空間の新設以及ja:Wikipedia:ウィキプロジェクト/名前空間の新設，本地的處理方式預計會分成5個階段進行：

~~向phab:提交申請設立專題空間；~~
將專題頁與討論頁批次移動到專題空間（可能需WP:FLOOD）；
修正指向專題的內部連結（可能需WP:FLOOD）；
調整專題模板；
討論重新導向與捷徑的設立方式；
其他議題。

以上。以上流程不會立即執行，會在社群對流程沒有異議之後公示後執行。如有其他相關疑問可繼續在下方討論。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月3日 (日) 07:44 (UTC)[回复]

專題空間已於本地生效，準備進行頁面移轉。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月27日 (三) 04:10 (UTC)[回复]

第一階段：申請

已通過：

已通過公示，亦完成布署（前端 by User:AnYiLin、後端 by User:A2569875），專題名字空間已於中文維基百科生效，將立即進行下一階段討論。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月27日 (三) 04:06 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

於Phabricator查看
編號T271612的工單
狀態：已解決

將會提供給phab:的細節如下：

	名字空間	討論空間
內部名稱 (前綴)	WikiProject:	WikiProject_talk:
ID	102	103
中文名稱 (介面名稱)	維基專題	維基專題討論
別名	專題专题維基專題维基专题 PJ WPJ	專題討論专题讨论專題對話专题对话維基專題討論维基专题讨论維基專題對話维基专题对话 PJT WPJT

-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月3日 (日) 09:41 (UTC)[回复]

我觉得中文名称叫“专题”更简洁一点…… ——羊羊 (留言|贡献) 2021年1月3日 (日) 14:02 (UTC)[回复]
- 這個名稱是參考User:BlackShadowG的提議。@BlackShadowG：關於羊羊32521的意見，您有甚麼看法？-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月3日 (日) 14:10 (UTC)[回复]
  - 在我看来，名字空间的中英文应该对应，这样可以避免误解。如果中文名称定为“专题:”那英文名称应该对应为“Project:“才对，然而“Project:”早已被用为“Wikipedia:“的别名了。——BlackShadowG（留言）维基百科20周年庆即将到来 2021年1月4日 (一) 14:43 (UTC)[回复]
    - @BlackShadowG：不认为需要严格对应。对应“专题”是“Topic”才对，“Project”是项目/工程/专案/方案。--YFdyh000（留言） 2021年1月4日 (一) 14:47 (UTC)[回复]
      - 該中文名稱僅是「介面顯示名稱」其如何設定並不會影響運作。但仍需要決定一個顯示名稱以讓介面管理員設定。若無法做出決定可能要像日文維基一樣開個名稱投票，然而由於WP:投票不能代替討論，因此不建議這麼做。當然，這不影響命名空間的申請與設定，因為Phab那邊只管內部名稱，而內部名稱「WikiProject:」已公示通過；介面名稱可以取得共識後再由WP:介面管理員於本地設置。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月4日 (一) 15:15 (UTC)[回复]
  建议名字空间内部名用英文，以免出现繁简问题。--GZWDer（留言） 2021年1月3日 (日) 16:18 (UTC)[回复]
  - (：)回應@GZWDer：參見上表，內部名稱（前綴）在最初的公示時（去年11月）就已經決定定義為英文「WikiProject」了。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月3日 (日) 16:23 (UTC)[回复]
- (：)回應@羊羊32521：該名稱主要是介面顯示的名稱（如左上角顯示[維基專題][討論][不转换]_____[閱讀][編輯][歷史]☆[更多∇][TW∇][搜尋維基百科🔍]），而關於簡潔與否問題，由於有同步申請別名，因此亦可以透過輸入專題:XXX連結到專題頁，並不一定要寫全名維基專題:XXX（參考預計命名）。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月3日 (日) 19:42 (UTC)[回复]
  - (？)疑問@羊羊32521：您可以接受上面的解釋嗎？；@YFdyh000：那個中文名稱實際上是對應介面顯示名稱—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月5日 (二) 05:52 (UTC)[回复]
    - @A2569875：Y行 ——羊羊 (留言|贡献) 2021年1月5日 (二) 15:22 (UTC)[回复]
      - 不解，這種東西為什麼需要用什麼「申請」？不是都通過了？那這樣公示是什麼意思？--Z7504非常建議必要時多關注評選（留言） 2021年1月6日 (三) 02:27 (UTC)[回复]
        @Z7504：要去phab:提申請，才會有工程師建立啊。舉個例子：台北市政府通過建造某條捷運，請問還沒向工程單位申請建造捷運路線，捷運路線就會自己冒出來嗎？從天上掉下來？怎麼可能。這邊主要是技術細節討論，完成後向技術分站提工單，通過是指社群共識通過，不意味著工程師理解具體要怎麼執行社群共識，現在就是要討論怎麼讓工程師理解具體怎麼操作，就這樣。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️）
        您有沒有看到關於上方具體要給工程師設定技術細節的部分還在討論，現在就是要處理程式碼具體技術上設定的部分。我想一氣呵成，不想變成有缺漏還要補提多張工單浪費時間，現在的討論正是這個目的。且技術細節討論只有公示通過後討論才有意義，如前次公示沒有通過，討論技術上程式設定也是白費功夫紙上談兵。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月6日 (三) 05:37 (UTC)[回复]
        理解，不過phab這個不怎麼在看，就不贅述了。--Z7504非常建議必要時多關注評選（留言） 2021年1月6日 (三) 06:39 (UTC)[回复]
公示3日，如無異議就转交phab:。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月6日 (三) 07:53 (UTC)[回复]

转交phab:T271612。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月9日 (六) 08:16 (UTC)[回复]

进行中……：已由User:Shizhao將之轉交Project Board:Site Configuration（參見討論Topic:W1avxa7f606do5k1），目前工單Task:T271612位於Tag:Wikimedia-site-requests中的Project Board:Config - to process，正待處理中。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月21日 (四) 07:47 (UTC)[回复]
經確認，根據維基百科後端代碼includes/Title.php中的function getNamespaceKey，其定義為：'nstab-' . lc($namespaceKey)，因此介面文字無需由phab那邊指定，屆時僅要由介面管理員將 "MediaWiki:nstab-" + 小寫(命名空間英文名稱) 填入文字即可，即需要在以下頁面提出編輯請求MediaWiki:Nstab-wikiproject、MediaWiki:Nstab-wikiproject/zh、MediaWiki:Nstab-wikiproject/zh-hant、MediaWiki:Nstab-wikiproject/zh-tw、MediaWiki:Nstab-wikiproject/zh-hk、MediaWiki:Nstab-wikiproject/zh-mo、MediaWiki:Nstab-wikiproject/zh-hans、MediaWiki:Nstab-wikiproject/zh-cn、MediaWiki:Nstab-wikiproject/zh-sg、MediaWiki:Nstab-wikiproject/zh-my填入维基专题或維基專題即可。好像User:羊羊32521在phab那邊提醒的zh-MY漏打好像其實也不用補，因為技術人員也無法調整那個部分，只能由介面管理員記得建立MediaWiki:Nstab-wikiproject/zh-my即可。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月23日 (六) 02:34 (UTC)[回复]
@A2569875：MediaWiki:Conversion-ns102和MediaWiki:Conversion-ns103也需要補-- Sunny00217 2021年1月23日 (六) 05:34 (UTC)[回复]
- @Sunny00217：不急，等到佈署後再補充也不遲，現在code還沒review，我只是先貼上備忘。另外，感謝補充。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月23日 (六) 05:40 (UTC)[回复]
完成已Commit程式碼到gerrit:657572（詳細資料）。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月26日 (二) 12:50 (UTC)[回复]
- 完成已提出編輯請求MediaWiki_talk:Nstab-wikiproject#編輯請求_2021-01-26，並補上User:Sunny00217提醒的MediaWiki:Conversion-ns102以及MediaWiki:Conversion-ns103等頁面。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月26日 (二) 13:55 (UTC)[回复]
  - 完成編輯請求已由User:AnYiLin受理。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月27日 (三) 04:06 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

第一點五階段：內容事實修訂

由於該命名空間設立完畢，已修正WP:命名空間新增該空間說明。如需補充歡迎討論。臺灣杉在此發言 (會客室) 2021年1月27日 (三) 13:40 (UTC)[回复]

您漏了WP:NS#缩写和别名。--LuciferianThomas．留言 2021年1月28日 (四) 08:08 (UTC)[回复]

完成。--臺灣杉在此發言 (會客室) 2021年1月29日 (五) 13:37 (UTC)[回复]

請協助複查是否全部的相關說明頁都修復完畢。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月25日 (四) 05:49 (UTC)[回复]

第二階段：轉移至新名字空間

已通過：

公示從2021年1月6日起至2021年1月14日暫停再從2021年1月26日起至1月29日共11天，期內所有異議的論述已由支持者回應，且反方無進一步論述，故無合理異議，議案通過。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月29日 (五) 13:04 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

名字空間設立完畢後，將會把所有列於Category:维基专题中的頁面及子頁面轉移至新名字空間，預計轉移的頁面及轉移之目標列於此頁User:A2569875/議案/專題空間設立/影響頁面（暫不包括重新導向），如有異議請盡快提出。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月3日 (日) 19:26 (UTC)[回复]

以下彙整：
- User:A2569875/議案/專題空間設立/影響頁面
  另請參考對應表（重新導向移動時若與對應表重複將不會進行移動）
- User:A2569875/議案/專題空間設立/影響重新導向
-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月4日 (一) 09:28 (UTC)[回复]

第二階段之公示狀態通告

公示即日起至命名空間佈署完畢為止。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月6日 (三) 14:12 (UTC)[回复]
- 說明如公示通過，預計使用以下腳本：User:A2569875/議案/專題空間設立/轉移腳本.js，並申請WP:FLOOD-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月6日 (三) 14:14 (UTC)[回复]
  - (～)補充：該Code的功能是，若一個頁面有低於100個連入頁面，則不保留重定向，連結問題將於下一階段用Flood修復（如高過100個會修不完。。。），其餘保留重新導向。移動重新導向時，全數皆會保留重新導向。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月28日 (四) 06:56 (UTC)[回复]
擱置、暫停公示：稍微看了一下先前韓文維基的申請phab:T29651，其工程師處理的流程將近一個月，故認為應該還要一段時間才能完成布署，為了避免長時間占用公告欄，因此暫時先撤下公告Special:Diff/63712969，等到了Code Review階段時再繼續公示。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月14日 (四) 06:18 (UTC)[回复]
- 程式碼已Commit到gerrit:657572（詳細資料），恢復公示，並延長3天，到2021年1月29日 (五) 12:56 (UTC)為止。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月26日 (二) 12:56 (UTC)[回复]
測試結果見此[1]，以PJ:多面體為例，目前未見系統性問題。預定將在公示結束時申請WP:FLOOD（或現在就去送審）並進行批量(►)移动。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月28日 (四) 07:21 (UTC)[回复]

第二階段之公示期討論

看來需要移動了 @A2569875、羊羊32521、BlackShadowG、YFdyh000、GZWDer、Z7504、AnYiLin那Wikipedia:专题應該被重命名成甚麼？WikiProject:首页嗎？-- Sunny00217 2021年1月27日 (三) 10:07 (UTC)[回复]
- 專題和專題委員會目前不在上述清單中，暫時不會移動。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月27日 (三) 10:27 (UTC)[回复]
  - 我觉得可以在WP名字空间中留一个介绍专题的页面，专题委员会可以考虑更名为WikiProject:委员会，不过这都是后话了，先完成转移再讨论吧。——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年1月27日 (三) 12:56 (UTC)[回复]
    @BlackShadowG：這主意不錯。--空氣小貓（留言） 2021年1月27日 (三) 16:48 (UTC)[回复]

技术性~~(－)反对~~，ns:103好像有点问题。[2]，页眉显示名字空间侦测错误，不知道是什么情况 ——羊羊 (留言|贡献) 2021年1月28日 (四) 01:50 (UTC)[回复]
- ns:102也有这个问题…… ——羊羊 (留言|贡献) 2021年1月28日 (四) 02:04 (UTC)[回复]
  切换到非中文en界面就不报错[3]--百無一用是書生 (☎) 2021年1月28日 (四) 03:53 (UTC)[回复]
  虽然有报错信息，但是创建页面没有问题：WikiProject:沙盒--百無一用是書生 (☎) 2021年1月28日 (四) 03:58 (UTC)[回复]
  已修复 已经修复这个问题在Template:Namespace pagename--百無一用是書生 (☎) 2021年1月28日 (四) 04:10 (UTC)[回复]
  还是有问题，Special:diff/63966864, 显示WikiProject talk非讨论页 ——羊羊 (留言|贡献) 2021年1月28日 (四) 04:16 (UTC)[回复]
  Done，已在Template:存檔至/core新增該討論空間。--臺灣杉在此發言 (會客室) 2021年1月28日 (四) 04:27 (UTC)[回复]
  感谢，已划票 ——羊羊 (留言|贡献|古典音乐专题) 2021年1月28日 (四) 04:30 (UTC)[回复]
  - 視為本反對意見已排除。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月28日 (四) 07:22 (UTC)[回复]
    - 我已经划票了Topic:W2cr3gexeunjmjce ——羊羊 (留言|贡献|古典音乐专题) 2021年1月28日 (四) 10:18 (UTC)[回复]
已申請Wikipedia:机器用户/申请#專題名字空間頁面遷移作業，預計於公示結束後開始執行任務。（目前仍然照著日維的劇本在走，有前人經驗參考，我想應該會順利完成）-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月28日 (四) 07:40 (UTC)[回复]
題外話：完成所有討論後，應否為整個設立新命名空間及偽命名空間的討論設WT分頁並重新整理所有章節的討論？--LuciferianThomas．留言 2021年1月28日 (四) 08:14 (UTC)[回复]
- @LuciferianThomas：我把日維的ja:Wikipedia:ウィキプロジェクト/名前空間の新設直接搬來了，你看看行不。Wikipedia:专题/提升为命名空间-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月28日 (四) 09:29 (UTC)[回复]
  我意思是說Talk Archive🌚--LuciferianThomas．留言 2021年1月28日 (四) 09:48 (UTC)[回复]
好奇的问一下，Wikipedia:电子游戏专题/条目指引和Wikipedia:钱币学专题/条目指引这两个同时是维基百科正式内容指引的页面会不会移动？ --Milky·Defer 2021年1月28日 (四) 12:19 (UTC)[回复]
- 預計先全部移動，再另外處理其餘要移到他處的頁面。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月28日 (四) 12:32 (UTC)[回复]
  - 或者您也可以直接編輯轉移表，透過加入註解符號（//或/* ... */）來排除您認為不應轉移到專題空間的頁面，User:A2569875/議案/專題空間設立/轉移表‎、User:A2569875/議案/專題空間設立/重定向轉移表‎（上方列出用於公示的wikitable僅是視覺化呈現的方式，實際上仍然要用json輸入FLOOD程式）感謝。-- ナナチ果物プリン🐰🥭🍮（宇帆·s☎️<用户/span>·☘️） 2021年1月28日 (四) 13:23 (UTC)[回复]

公示通過，即將開始移動-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月29日 (五) 13:04 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

(註:以下討論涉及後續階段的探討，先不關閉)-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月29日 (五) 13:04 (UTC)[回复]
Just a suggestion，正式全面部署后能不能设置过滤器或者白名单，限制用户创建“WP:XX专题”或“WP:XX维基专题”的页面？--百战天虫（留言） 2021年1月28日 (四) 16:32 (UTC)[回复]
(＋)支持——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年1月29日 (五) 00:54 (UTC)[回复]
目前有一个技术问题，Template:Category handler无法处理WikiProject namespace，连带导致各个已经转移的专题无法被列入诸如Category:活跃维基专题这类活跃度分类。--BoyuZhang1998（留言） 2021年1月29日 (五) 10:06 (UTC)[回复]
- 那麼提請全保護模板編輯請求不就解決了。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月29日 (五) 10:15 (UTC)[回复]
  - 完成@BoyuZhang1998：編輯請求已由U:KirkLU處理，問題將在維基媒體系統緩存清除完畢後解決，請靜待維基媒體系統清除緩存。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月31日 (日) 11:38 (UTC)[回复]

专题指引更名

(承上方已經封閉的討論）Wikipedia:电子游戏专题/条目指引和Wikipedia:钱币学专题/条目指引可以如Template:Wikipedia policies and guidelines所示，考慮移動到Wikipedia:电子游戏条目指引和Wikipedia:钱币学条目指引（一个类似的例子是ACG专题论述Wikipedia:日本動漫遊戲條目指導）。或者保守一点，简单删掉斜线，变成Wikipedia:电子游戏专题条目指引和Wikipedia:钱币学专题条目指引）。--洛普利宁 2021年1月30日 (六) 15:19 (UTC)[回复]
- (＋)支持更名为Wikipedia:电子游戏条目指引和Wikipedia:钱币学条目指引，这比较符合WP:方针中规定的命名方式。——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年2月1日 (一) 02:02 (UTC)[回复]
- (＋)支持，直接更名为「Wikipedia:xxxx条目指引」就好了，我觉得没必要带一个「专题」字样。如果其他专题也有未成正式指引的条目指导的话，我支持全部移动成「Wikipedia:xxxxx条目指导」，日后如果有提升为指引，再将「指导」改成「指引」。--Milky·Defer 2021年2月1日 (一) 03:05 (UTC)[回复]
- (＋)傾向支持以上提议，提升专题指引的曝光度和参与度，使其更经考验。直接名为“指引”，挂特制参数的“专题指引”模板为好。--YF dyh000（留言） 2021年2月1日 (一) 04:25 (UTC)[回复]
7日内无新留言，根据WP:7DAYS，就Wikipedia:电子游戏专题/条目指引和Wikipedia:钱币学专题/条目指引更名为Wikipedia:电子游戏条目指引和Wikipedia:钱币学条目指引一案 公示7日。——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年2月10日 (三) 01:13 (UTC)[回复]
@BlackShadowG：公示完毕了。--Milky·Defer >恭贺新春 2021年2月18日 (四) 15:03 (UTC)[回复]
@MilkyDefer：目前所有方针指引均被移动保护，已提出移动请求，等待管理员处理。——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年2月18日 (四) 16:04 (UTC)[回复]
第二階段：提議將WP:XX專題/YY指引以及PJ:XX專題/YY指引皆移動到WP:XXYY指引。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月18日 (四) 16:10 (UTC)[回复]

「維基專題:維基專題:XX」的頁面

已處理：

已由蟲蟲飛快速刪除-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月5日 (五) 06:55 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

@A2569875：話說這種的需不需要考慮直接提請管理員批量刪除？-- Sunny00217 2021年2月1日 (一) 11:27 (UTC)[回复]
- (＋)支持，此类重定向并无意义，看起来是移动时出现的失误？——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年2月3日 (三) 01:50 (UTC)[回复]

完成：Topic:W2qh255e9e7fx3x8，已由User:蟲蟲飛執行WP:CSD#R3(×)快速删除-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月5日 (五) 06:59 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

第二點五階段：相關技術問題修正

於Phabricator查看
編號T273763的工單
狀態：已解決

根據phab:T273763（設立專題空間後，連入頁面API於 pywikibot 出錯），此修正案導致部分機器人出錯。目前phab:T273763已解決，留此節討論其他相關技術出問題時的策略與解決方案。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月8日 (一) 17:54 (UTC)[回复]

(～)補充，如移動完成的頁面有遇到任何技術問題，歡迎於此回報。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月8日 (一) 18:16 (UTC)[回复]

前几天发现WikiProject:传统百科全书条目因为页面移动后造成大部分子页面出现错误，目前已经修复一部分--百無一用是書生 (☎) 2021年3月16日 (二) 02:37 (UTC)[回复]

第三階段：修正指向專題的內部連結

各階段不得同時討論，前一項討論完結之後，才能進行下一段討論。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月3日 (日) 19:29 (UTC)[回复]

第三階段為修正指向專題的內部連結，主要要修正的是一些模板、模組等，純粹葉面的內部連結因為有保留重新導向故暫時還會有效，至於需不需要全部修正並刪除重新導向可以討論（日維當時保留大部分的重新導向至今）。已經修復的模板包括{{Namespace pagename}}；目前已知待修復的模板有{{Category handler}}及{{Namespace detect}}。其餘將陸續補充。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月29日 (五) 12:57 (UTC)[回复]
@A2569875：想请问一下快捷方式如何规定？目前是专题都占用了一个WP快捷方式，以后是否都需要把WP快捷方式换成WPJ快捷方式？--Lightyears_{Talk#欢迎加入智能手机专题} 2021年1月30日 (六) 10:02 (UTC)[回复]
- @30000lightyears：請見最初流程規劃「5.討論重新導向與捷徑的設立方式」，這是第五階段的討論重點。我認為先把現有頁面調整好再討論這方面比較好，否則整個會亂掉。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月30日 (六) 10:22 (UTC)[回复]
  好，麻烦您在第五阶段开放时ping一下我，谢谢！--Lightyears_{Talk#欢迎加入智能手机专题} 2021年1月30日 (六) 10:24 (UTC)[回复]
是否需要修改所有的內部連結，可能需要與「是否需要刪除WP->PJ的重定向」一併討論。-- 五歲抬頭雪菲（☎️·☘️） 2021年3月24日 (三) 05:47 (UTC)[回复]

第四階段：調整專題模板

已完成：

已修改完大多數相關模板。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月14日 (日) 09:33 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

部分專題模板需要調整才能正常，除了第三階段與連入頁面、分類相關的模板要調整外，其餘模板帶移動完成後再觀察情況，屆時將會補充需要辦理的事項。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月29日 (五) 12:57 (UTC)[回复]
- (～)補充亦有部分關於專題模板整改的討論於PJT:ACG#遷移至WikiProject名字空間展開。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月29日 (五) 12:58 (UTC)[回复]
比如{{WPBannerMeta}}？——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年2月5日 (五) 02:02 (UTC)[回复]
- 是的@BlackShadowG：，除了{{WPBannerMeta}}，其他已經修改好的模板有{{Namespace detect}}、{{Namespace pagename}}、{{Namespace detect showall‎}}、{{Main talk other}}、{{Category handler}}，然後{{Main other}}管理員還沒處理。如有缺漏還需協助指出。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月5日 (五) 13:51 (UTC)[回复]
  {{WPBannerMeta}}好像还没修-- ——羊羊 (留言|贡献|古典音乐专题) 2021年2月6日 (六) 07:10 (UTC)[回复]
  - 全保護......⋯⋯—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月6日 (六) 12:21 (UTC)[回复]
    {{Main other}}一直還沒修阿 囧rz……-- Sunny00217 2021年2月10日 (三) 15:14 (UTC)[回复]
- (：)回應@羊羊32521：主模板已在2月10日由大貓修復，目前還有子模板410個待修，目前先手工慢慢修，因為怕機器人會有例外；@Sunny00217：{{Main other}} （編輯討論說明信息鏈入歷史）也在今日稍早由大貓修復。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月12日 (五) 09:18 (UTC)[回复]
等待管理员處理：除了Template:WikiProject Tree of Life、Template:WikiProject_Biography被全保護之外，已完成Template:WPBannerMeta相關模板(共410-2個)模板的修改(全數由人手工修改，少數由其他用戶修改已發出感謝。)；另外Template:中國傳統聲音專題建立時就指向PJ:空間因此無須調整。剩餘部分等待Template_talk:WikiProject_Tree_of_Life#編輯請求 2021-02-14與Template_talk:WikiProject_Biography#編輯請求 2021-02-14被管理員接受後本討論就可以完成，屆時將進入下一階段的討論。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月14日 (日) 09:07 (UTC)[回复]
- 完成：已由U:AT完成修改。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月14日 (日) 09:32 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

第五階段：討論重新導向與捷徑的設立方式

~~各階段不得同時討論，前一項討論完結之後，才能進行下一段討論。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月29日 (五) 12:57 (UTC)~~[回复]

本案進入倒數第二個部分。現在將討論未來專題捷徑如何設立，以及原有捷徑的去留：

未來是否允許建立跨WP與PJ空間的捷徑？如果需要，是否需要進一步規範?
未來是否允許建立跨WP與PJ空間的非捷徑的重新導向？
舊有的跨WP與PJ空間的捷徑是否需要清除連入然後(×)删除？

cc.@30000lightyears、Taiwania Justo、LuciferianThomas、羊羊32521、BlackShadowG：

請討論-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月14日 (日) 09:41 (UTC)[回复]

我认为PJ空间的捷径统一规范为WPJ/PJ:XXX，将现有WP重定向全部转到PJ去。比如WikiProject:智能手机的WP:SMARTPHONE直接转移到WPJ:SMARTPHONE。--Lightyears_{Talk·Sign#订阅维猫报喵！} 2021年2月14日 (日) 11:15 (UTC)[回复]
个人意见
1. 为了避免混淆，将来应该一律禁止建立跨WP与PJ空间的捷径重定向。
2. 目前存在的WP重定向到PJ的捷径应该全部转移到PJ，若无链入或很少链入，可考虑(×)删除；若数量过大，或者已经在讨论中被引用，则可考虑(○)保留以仅供历史参考。
3. 同时，将PJ名字空间中所有{{shortcut}}中的捷径一律改为以“PJ”开头的捷径，不再推荐使用以WP开头的捷径。

——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年2月14日 (日) 12:57 (UTC)[回复]

同上，不然就沒必要偽命名空間了。空氣小貓（留言） 2021年2月14日 (日) 13:49 (UTC)[回复]

我覺得從PJ空間捷徑連出沒什麼問題，WP空間也有捷徑連至Help。PJ分拆了就不要再從WP連過去了，舊的就隨它吧。--LuciferianThomas．留言 2021年2月14日 (日) 14:09 (UTC)[回复]

舊的捷徑如要批量刪除的話可能要請求管理員開刪除機器人...-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月14日 (日) 14:11 (UTC)[回复]

所以把PJ空间的{{shortcut}}全部更新，提醒将来的编者不要再用WP链接到PJ的捷径就行了。那些没有链入的WP捷径删了也无妨。——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年2月16日 (二) 02:05 (UTC)[回复]

個人意見：

原則上不允許，但社羣就個別頁面的特殊情形可以例外特許。建議以修改R2規範處理。
不允許。如出現，應清除連入並刪除。
可行。清除連入可以請求bot（WP→PJ），刪除的話我覺得開一個list，然後轉AFD即可。

以上。SAN MO SA _SPQR 2021年2月17日 (三) 14:40 (UTC)[回复]

(？)疑問@Sanmosa：您認為需要清除連入嗎？-- 五歲抬頭雪菲（☎️·☘️） 2021年3月31日 (三) 06:53 (UTC)[回复]

既然（我認為）未來不允許建立跨WP與PJ空間的非捷徑重新導向，而且非條目命名空間的非捷徑重新導向本來就使用率低下，如果真的有人意外建立了，都不會有多少連入，清除連入也不是甚麽困難的事，而且還能避免未來的誤用。SAN MO SA _Σουέζ 2021年3月31日 (三) 07:43 (UTC)[回复]

Wikipedia:专题和Wikipedia:专题委员会等部分页面为何还没有移动到新的名字空间？还是这些页面不应该移动？--百無一用是書生 (☎) 2021年2月19日 (五) 02:46 (UTC)[回复]

先前討論有提到將專題介紹留在WP空間。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月19日 (五) 17:12 (UTC)[回复]

专题委员会并非专题介绍，Wikipedia:专题似乎也称不上是介绍，更像是WikiProject:首页的作用--百無一用是書生 (☎) 2021年3月1日 (一) 02:54 (UTC)[回复]

(？)疑問所以您建議將WP:专题(►)移动到PJ:首页嗎？-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年3月1日 (一) 08:09 (UTC)[回复]
我认为应该这样，WP:专题可以不需要，或者另外重写，作为对专题的介绍页面--百無一用是書生 (☎) 2021年3月1日 (一) 11:46 (UTC)[回复]
(？)疑問那麼您對專題委員會的存放位置有何建議？—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年3月3日 (三) 05:17 (UTC)[回复]
(？)疑問@Shizhao：？-- 五歲抬頭雪菲（☎️·☘️） 2021年3月10日 (三) 06:01 (UTC)[回复]
專題委員會应该是从属于专题的啊，我觉得按道理来说应该在WikiProject下面--百無一用是書生 (☎) 2021年3月10日 (三) 07:19 (UTC)[回复]

個人認為跨WP->PJ沒差，但PJ->WP的不行-- Sunny00217 2021年2月21日 (日) 13:56 (UTC)[回复]

第五階段：小結

總結以上討論意見：

禁止建立跨WP與PJ空間的捷徑重新導向。並清理連入頁面後刪除現有跨WP與PJ空間的捷徑重新導向；同时，将PJ名字空间中所有{{shortcut}}中的捷径一律改为以“PJ”开头的捷径，不再推荐使用以WP开头的捷径。→修改R2規範
Wikipedia:專題和Wikipedia:專題委員會移動到PJ空間。→需探討是否留重定向

以上-- 五歲抬頭雪菲（☎️·☘️） 2021年4月7日 (三) 06:22 (UTC)[回复]

公示7日-- 五歲抬頭雪菲（☎️·☘️） 2021年4月14日 (三) 03:35 (UTC)[回复]
R2具體修改內容呢？--Xiplus#Talk 2021年4月14日 (三) 05:31 (UTC)[回复]

補：R2修改內容：

現行條文

R2. 跨名字空间的重定向。

由条目的名字空间重定向至非條目名字空间，将用户页移出条目名字空间時遺留的重定向，或者从草稿名字空间指向非草稿名字空间的重定向。經社群同意設立的偽命名空間屬於本規則之例外。注意：有时新加入的维基人偶尔会在主条目空间誤建用户页。使用“移动”页面工具将用户页移回用户名字空间会保留页面历史，在删除遺留的重定向頁前，考虑保留一到两天；草稿重定向速删前，请确保草稿已经完成其作用，并且草稿的历史已经合适地移动到相应的正式页面。

使用模板{{d|R2}}或{{d|interwk}}。

提議條文

R2. 跨名字空间的重定向。

包括以下幾種類型：

从条目名字空间指向非條目名字空间的重定向（包括將用户页从条目名字空间移動至用户页名字空间時遺留的重定向）；
从草稿名字空间指向非草稿名字空间的重定向；
從計畫命名空間（Wikipedia）指向維基專題命名空間（WikiProject）的重定向；及
從維基專題命名空間（WikiProject）指向計畫命名空間（Wikipedia）的重定向。

經社群同意設立的偽命名空間屬於本規則之例外。

注意：有时新加入的维基人偶尔会在主条目空间誤建用户页。使用“移动”页面工具将用户页移回用户名字空间会保留页面历史，在删除遺留的重定向頁前，考虑保留一到两天；草稿重定向速删前，请确保草稿已经完成其作用，并且草稿的历史已经合适地移动到相应的正式页面。

使用模板{{d|R2}}或{{d|interwk}}。

以上。SAN MO SA _Σουέζ 2021年4月17日 (六) 04:12 (UTC)[回复]

Module:Template:Delete/data模組的對應修改見User:Sanmosa/R2模組。SAN MO SA _Σουέζ 2021年4月17日 (六) 04:24 (UTC)[回复]

現時有3502個WP->WPJ的重新導向，33個WPJ->WP的重新導向。--Xiplus#Talk 2021年4月17日 (六) 05:07 (UTC)[回复]

上面的結論有指明「清理連入頁面後刪除現有跨WP與PJ空間的捷徑重新導向」，所以應該需要bot，再不然發通知邀請社群協力清理也可。SAN MO SA _Σουέζ 2021年4月17日 (六) 11:00 (UTC)[回复]

(！)意見：“2. 将用户页移出条目名字空间时遗留的重定向”真包含于“1. 由条目的名字空间指向非條目名字空间的重定向”，可以删去。另外那个的看起来怪怪的，建议删去。 ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月20日 (二) 04:57 (UTC)[回复]

@羊羊32521：（1）1是（條目命名空間）→（非條目命名空間），2是（非條目命名空間）→（條目命名空間），2不能刪。（2）完成。SAN MO SA _Σουέζ 2021年4月21日 (三) 03:38 (UTC)[回复]

查CSD历史，R2最初加入于Special:Diff/284065：通过将用户页移出条目名字空间而建立的重订向。（有时新的维基人偶尔会在主条目空间创建用户页。使用“移动”页面工具将用户页移入用户名字空间会保留页面的历史，考虑在删除作为移动结果的重定向页前，保留一到两天。) 所以是说：①在主名字空间建立用户页；②将该用户页移动到用户名字空间（留重定向）；③快速删除重定向页。故2亦是“（条目名字空间）→（非条目名字空间）”。 ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月21日 (三) 15:55 (UTC)[回复]

阁下这一改意思都变了 ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月21日 (三) 15:59 (UTC)[回复]

@Sanmosa-- ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月24日 (六) 14:39 (UTC)[回复]

另外我认为WP→PJ可能不适合速删，上方讨论有提到

“

若数量过大，或者已经在讨论中被引用，则可考虑(○)保留以仅供历史参考。

”

——User:BlackShadowG

或者先开机器人把历史遗留问题解决掉

——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月21日 (三) 16:08 (UTC)[回复]

容許我再多等待三日，上面的提案會稍為調整。SAN MO SA _Σουέζ 2021年4月21日 (三) 03:38 (UTC)[回复]

@羊羊32521：有道理。已再調整。7日後我再重行公示。SAN MO SA _Σουέζ 2021年4月25日 (日) 08:19 (UTC)[回复]

針對「WP→PJ可能不適合速刪」一點，我也曾經表示需要bot處理，但我認為人手逐個處理亦非不可，情況如同enwiki曾經有過的X1，分別僅在於這變成永久措施，並禁止日後同類重新導向的建立。SAN MO SA _Σουέζ 2021年4月25日 (日) 08:25 (UTC)[回复]

@Xiplus：請求WP->WPJ的重新導向及WPJ->WP的重新導向的具體清單。另見上。SAN MO SA _Σουέζ 2021年4月30日 (五) 06:00 (UTC)[回复]

@Sanmosa：列表於此，另您想讓我注意什麼？--Xiplus#Talk 2021年4月30日 (五) 06:10 (UTC)[回复]

@Xiplus：關於我對速刪WP->WPJ的重新導向的意見。當然我仍然希望有bot能協助清理連入（初步構思：[[WP:AA]]→[[WPJ:BB|WP:AA]]、[[WP:AA|自定義文字]]→[[WPJ:BB|自定義文字]]）。SAN MO SA _Σουέζ 2021年4月30日 (五) 06:15 (UTC)[回复]

看起來無問題，不過我個人是覺得有大量連入的重定向就不應刪除，這樣也不需要去修正。--Xiplus#Talk 2021年4月30日 (五) 11:43 (UTC)[回复]

第六階段：(暫不開放)

各階段不得同時討論，前一項討論完結之後，才能進行下一段討論。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月14日 (日) 09:41 (UTC)[回复]

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

偽命名空間

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间（錯誤：Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间是重定向頁面）。

[編輯此導航模板] 設立新命名空間及偽命名空間無共識：2018年12月的先前討論全案結以待續：第一輪討論 - 開放偽命名空間作捷徑連結用結以待續：設立LTA、MOS、PJ三個偽命名空間結以待續：升格維基專題為命名空間結以待續：修正命名空間資訊頁面結以待續：將「Wikipedia:捷徑」訂為方針完結：第二輪討論完成部署：設立專題命名空間相關討論及任務已通過：討論升格維基專題為命名空間任務完成：向Phabricator申請部署維基專題命名空間已合併：在Gerrit提交所需修正編碼任務完成：在Phabricator請求合併編碼完成：事實性修訂「Wikipedia:命名空間」以包含新的維基專題命名空間完成，待檢查：將專案命名空間下的維基專題移動至維基專題命名空間專題移動列表專題重定向移動列表已完成：修正指向專題的內部連結機器人任務已完成：調整專題模板已通過：討論捷徑的設立方式已通過：其他議題討論完結：設立偽命名空間相關討論已通過：討論設立LTA及MOS偽命名空間供捷徑使用已否決：設立捷徑空間供LTA/MOS捷徑使用已否決：設立捷徑空間作其他用途結以待續：升格LTA為命名空間完結：後續討論處理事項完成：修改機械人操作不提刪偽命名空間捷徑無結論：格式手冊新捷徑名稱討論 MOS捷徑列表已否決：舊捷徑改為軟重定向完成：設置預設啟用小工具已否決：自動半保護偽命名空間條目已通過：提議設立新快速刪除標準完結：第三輪討論已否決：捷徑命名空間已完成：捷徑指引草案修訂已通過：增設更多偽命名空間（一）已通過但未實行：第三次推动设立LTA命名空间

本案討論格式手冊及長期破壞者提升問題。目前有三案：

格式手冊及長期破壞者提升為命名空間，英語名稱待定；
格式手冊及長期破壞者成為偽命名空間，縮寫為MOS及LTA；
維持現行方式。

請討論。臺灣杉在此發言 (會客室) 2020年12月25日 (五) 01:23 (UTC)[回复]

(＋)支持将格式手册和长期破坏者设立为伪名字空间，(－)傾向反對设立为名字空间，个人认为没有必要。--Yining Chen（留言|签名） 2020年12月26日 (六) 11:32 (UTC)[回复]
(！)意見格式手冊(LTA:)及長期破壞者(MOS:)要升格成「真」命名空間可能比較困難，因為沒有別的維基百科分站、姊妹計畫、語言版本有啟用此設定，故技術細節無從參考，諸如Namespcae id(一個整數)也須討論，且還有數字id可能重複的問題。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年12月26日 (六) 12:59 (UTC)[回复]
(＋)支持成为伪命名空间。如果成为真·命名空间，我(＋)傾向支持長期破壞者(LTA:)，而不是格式手冊(MOS:) ——羊羊 (留言|贡献) 2020年12月26日 (六) 15:44 (UTC)[回复]

建議立為偽命名空間（方案2）。SAN MO SA _SPQR 2020年12月27日 (日) 07:32 (UTC)[回复]

支持提升為命名空間，因為會違反快速刪除方針的R2準則。空氣小貓（留言） 2020年12月28日 (一) 07:06 (UTC)[回复]

如果是偽命名空間通過，就會在下一階段修訂快速刪除、捷徑以及命名空間規範。--臺灣杉在此發言 (會客室) 2020年12月28日 (一) 09:53 (UTC)[回复]

支持成為偽命名空間。命名空间涉及较多技术问题，未来如需求明显，可再议转换。--YF dyh000（留言） 2020年12月30日 (三) 13:01 (UTC)[回复]

如需要立為名字空間也並非不可，只是要決定其所使用的數字ID

0-99的命名空間ID要保留給維基媒體系統使用，故需要使用100以上的命名空間ID
下面整理許多語言版本維基百科的命名空間ID使用(主空間是偶數，討論空間是奇數)

命名空間	命名空間ID / 討論頁ID	維基百科各語言版本使用狀況(未窮舉)	本地使用狀況	備註
主題:	100/101	全部語言版本維基百科皆有啟用（參考此處整理）	本地已使用	Help:主题
專題:	102/103	中文及加泰蘭文、世界文、法文、韓文、奧克西坦文、日文等	本地已使用	Wikipedia:专题
附件:	104/105	西班牙文等	未使用	類似中文維基辭典的附錄
列表:	104/105	僅立陶宛文維基	未使用	WP:列表
文獻:	104/105	法文、奧克西坦文等	未使用	參考User:青子守歌的整理
仲裁:	106/107	俄羅斯文等	未使用	(本地未通過相應指引) WP:仲裁委員會
圖書:	108/109	超過25個語言版本使用。	本地通過的共識為 : 繁簡轉換系統處理完畢後引入，然而P站仍在努力中，因此還是有機會使用此數值	Help:圖書
	110/111	未使用
草稿:	118/119	超過25個語言版本使用。	本地已使用	WP:草稿

以上補充。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年12月31日 (四) 09:52 (UTC)[回复]

如果要設立的話可能就120/121與122/123吧，或110/111、112/113與120/121、122/123選一組。如果要避免跟未來新功能重複，也可以使用150之後的數字比較保險。同時亦須留意擴展名字空間ID列表有沒有可能存在本地有機會引入的擴展。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月1日 (五) 08:07 (UTC)[回复]
- (～)補充剛才到gerrit.wikimedia.org看了一下，其列出的Recommended命名空間ID共有：
  - 100 - Portal
  - 102 - WikiProject
  - 104 - Reference
  - 114 - Translation
以上補充。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月21日 (四) 10:19 (UTC)[回复]

(＋)支持為設立偽命名空間，對設為真命名空間(＃)有保留。--LuciferianThomas．留言 2020年12月31日 (四) 15:58 (UTC)[回复]

我对成立真命名空间(＃)有保留，尤其是格式手册。对格式手册而言，因为格式手册同时也是指引，对它成立真命名空间将意味着指引分散两地。 --Milky·Defer 2020年12月31日 (四) 17:13 (UTC)[回复]

小结1

标题添加： ——羊羊 (留言|贡献) 2021年1月19日 (二) 05:21 (UTC)[回复]

小總結一下，包含#先前討論截至2021年1月1日 (五) 19:38 (UTC)之前，社群成員意見大致如下
- 支持MOS真：2 (_{空氣小貓 2020年12月28日 (一) 07:06 (UTC)、Sunny00217 2020年11月22日 (日) 12:26 (UTC)})
- 反對MOS真：2 (_{Yining Chen 2020年12月26日 (六) 11:32 (UTC)、MilkyDefer 2020年12月31日 (四) 17:13 (UTC)})
- 支持MOS偽：5 (_{LuciferianThomas 2020年12月31日 (四) 15:58 (UTC)、YFdyh000 2020年12月30日 (三) 13:01 (UTC)、SANMOSA 2020年12月27日 (日) 07:32 (UTC)、羊羊 2020年12月26日 (六) 15:44 (UTC)、Yining Chen 2020年12月26日 (六) 11:32 (UTC)})
- 反對MOS偽：1 (_{cwek Wikipedia_talk:名字空间#開放偽命名空間作捷徑連結用})
- 支持LTA真：3 (_{空氣小貓 2020年12月28日 (一) 07:06 (UTC)、羊羊 2020年12月26日 (六) 15:44 (UTC)、Sunny00217 2020年11月22日 (日) 12:26 (UTC)})
- 反對LTA真：1 (_{Yining Chen 2020年12月26日 (六) 11:32 (UTC)})
- 支持LTA偽：5 (_{LuciferianThomas 2020年12月31日 (四) 15:58 (UTC)、YFdyh000 2020年12月30日 (三) 13:01 (UTC)、SANMOSA 2020年12月27日 (日) 07:32 (UTC)、羊羊 2020年12月26日 (六) 15:44 (UTC)、Yining Chen 2020年12月26日 (六) 11:32 (UTC)})
- 反對LTA偽：1 (_{cwek Wikipedia_talk:名字空间#開放偽命名空間作捷徑連結用})
大部分人皆認為可以設立偽名字空間，少數人認為可以成立真名字空間，亦有人認為礙於方針需升格為名字空間，然而部分人對是否升格為真名字空間有所保留。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月1日 (五) 19:38 (UTC)[回复]
- @Taiwania Justo：目前這樣的討論模式不易解讀共識，看是不是要根據LTA/MOS/真/偽逐條討論，或直接開投票？-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月1日 (五) 19:41 (UTC)[回复]
  其實可以看出來大部分是偽命名空間為多數，還不至於動到投票的地步。--臺灣杉在此發言 (會客室) 2021年1月2日 (六) 02:35 (UTC)[回复]
(＋)支持設立LTA偽命名空間，(＋)傾向支持設立MOS偽命名空間，(－)反对設立任何命名空間。—— Eric Liu_{創造は生命（留言．留名．學生會）} 2021年1月2日 (六) 04:45 (UTC)[回复]
- 如果主流意見都是偽名字空間，就得修方針指引了；萬一方針指引沒過，有配套嗎？—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月2日 (六) 05:04 (UTC)[回复]
  頂多就是維持現狀，直到通過為止。不過在修改時，R2增加的例外條款必須納入社群的共識在裡面，不至於不通過。--臺灣杉在此發言 (會客室) 2021年1月2日 (六) 07:32 (UTC)[回复]
  基本上在這裏支持設立偽命名空間的都理應明白偽命名空間就是R2例外的意思吧…？--LuciferianThomas．留言 2021年1月4日 (一) 01:54 (UTC)[回复]

我想補充一個意見：我反對MOS及LTA設為真命名空間，僅支持MOS及LTA設為偽命名空間。SAN MO SA _SPQR 2021年1月2日 (六) 08:17 (UTC)[回复]

支持命名空間，反對偽命名空間。SmallTim（留言） 2021年1月5日 (二) 13:56 (UTC)[回复]

(？)疑問@SmallTim：有鑑於WP:投票不能代替討論，能否請您補充一下反對偽命名空間的理由，以便彙整、推進討論？感激不盡。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月5日 (二) 18:25 (UTC)[回复]

这整得跟投票一样，建议各位将(＋)支持和(－)反对的理由写出来，逐一进行讨论，以此达到共识。毕竟投票不能代替讨论。 ——羊羊 (留言|贡献) 2021年1月5日 (二) 15:50 (UTC)[回复]

我建議直接排除成為真命名空間的可能性，這樣會產生維護問題。SAN MO SA _SPQR 2021年1月6日 (三) 06:10 (UTC)[回复]

(？)疑問@Sanmosa：比方說哪方面的維護問題？數字ID跟擴展重複？（這個可以克服，頂多新擴展本站的Namespace id與其他語言版本或己妹計畫不同步而已）；頁面內容維護？（我想不出甚麼樣的情況會不利於維護）；跨語言連結？-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月6日 (三) 06:44 (UTC)[回复]

方針指引宜集中於同一命名空間。SAN MO SA _SPQR 2021年1月6日 (三) 06:45 (UTC)[回复]

(！)意見LTA不是方針、指引、態度指引、草案、提議、論述、專題、主題、存檔、書籍、條目、分類、介面...都不是。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月6日 (三) 06:48 (UTC)[回复]

那你當我的建議僅適用於MOS。SAN MO SA _SPQR 2021年1月6日 (三) 06:51 (UTC)[回复]

綜上所述，@Taiwania Justo：由於本質不同，建議LTA與MOS分項討論。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月6日 (三) 07:11 (UTC)[回复]
這樣好了，MOS大多數意見都是偽命名空間，可以開啟第三階段修訂方針部分，然後LTA獨立出來繼續討論，如何？--臺灣杉在此發言 (會客室) 2021年1月6日 (三) 10:04 (UTC)[回复]

(？)疑問：有多少此次提案涉及的LTA？--Yining Chen（留言|签名） 2021年1月7日 (四) 05:39 (UTC)[回复]

所有LTA的子頁面如下：

所有指向LTA頁面的捷徑如下：（設立偽命名空間需要將以下捷徑移至LTA:XXX）

以上。--LuciferianThomas．留言 2021年1月8日 (五) 02:01 (UTC)[回复]

把LTA设置成名字空间的一个效果是可以设置所有页面为noindex（包括少数不使用LTA模板的子页），虽然社群要评估一下这么做的价值。--GZWDer（留言） 2021年1月10日 (日) 14:42 (UTC)[回复]

小结2

标题添加： ——羊羊 (留言|贡献) 2021年1月19日 (二) 05:21 (UTC)[回复]

@A2569875、Taiwania Justo：其實我覺得上方的總結可能會導致共識的混淆。

表達意見用戶	格式手冊（MOS）		長期破壞者（LTA）		備註
表達意見用戶	升格命名空間	設偽命名空間允許R2例外	升格命名空間	設偽命名空間允許R2例外	備註
Yining Chen	傾向反對	支持	傾向反對	支持
羊羊32521	反對	支持	傾向支持	支持	LTA傾向偽，意見優先取偽
Sanmosa	反對	支持	—	支持
Pseudo Classes	支持	反對	支持	反對	以違反CSD R2為由反對議案是否WP:CCC？
YFdyh000	—	支持	—	支持
LuciferianThomas	有保留	支持	有保留	支持
Ericliu1912	反對	傾向支持	反對	支持
MilkyDefer	有保留	支持	有保留	支持	早前討論
Super Wang	—	可開可不開	—	支持	早前討論
Cwek	—	反對	—	反對	早前討論
Lopullinen	—	傾向反對	—	傾向反對	早前討論
Sunny00217	支持	—	支持	—	早前討論
總計	2 : 4 : 2	7 : 3 : 1	3 : 2 : 3	8 : 3 : 0

此總結方式會否更加清晰？--LuciferianThomas．留言 2021年1月12日 (二) 02:06 (UTC)[回复]

澄清一下，因為現行方針尚未針對此議題修正，實不宜直接設立偽命名空間，我認為修正方針應要在此議題之前完成。道理就像UBER進入到某市場一樣，應在其進入市場前設立相應法規，避免無法與計程車公平競爭、司機有無載客資格和違法現行法規等問題。--空氣小貓（留言） 2021年1月12日 (二) 17:45 (UTC)[回复]

此外，反對偽命名空間的理由是，MOS和LTA既為縮寫，儘管名義上是偽命名空間，但是實際上仍屬於條目命名空間，這樣子與其內容衝突非常奇怪，更何況現存有許多辨識命名空間的模板，身為重度模板使用者，我不希望辨識偽命名空間時，輸出的結果為「條目」。--空氣小貓（留言） 2021年1月12日 (二) 17:57 (UTC)[回复]

在模板裡面放if else不就好了。Module亦然。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月12日 (二) 18:07 (UTC)[回复]
@A2569875：您應該明白我的重點不在這裡吧。--空氣小貓（留言） 2021年1月17日 (日) 14:20 (UTC)[回复]
- 山不轉路轉、路不轉人轉。大可以將所有判斷名字空間的模板在判斷前先匹配偽名字空間表再做進一步輸出，看不出有什麼問題，很多語言版本維基都有它自己的「本地特化」。對於傾向支持偽名字空間（當然如可能我還是希望名字空間啦，但基金會那邊不一定會買單，你看編輯審核保護和Book:名字空間工單提那麼久還在「神秘的技術問題擱置」就知道有多難，何況其他語言版本沒有先例）對於傾向支持偽名字空間的立場者來說，當然會提出傾向於去符合對偽名字空間有利的方案去做提議。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月17日 (日) 14:38 (UTC)[回复]
  伪名字空间只是一个重定向页，模板所处的页面还是在项目空间上，当然不会输出“条目”，就像这个链接User:羊羊32521/S/VP点进去不会造成Wikipedia:互助客栈变成“用户页”一样。 ——羊羊 (留言|贡献) 2021年1月19日 (二) 05:14 (UTC)[回复]
不認為以上問題是問題，模板模組加個if-else或switch case在本地特化的名字空間便是模板/模組不就好了，況且現在有不少的名字空間判斷都不是直接引用魔術字，是使用中介模板例如{{Namespace_detect}}，在裡面補充if-else或switch case不就好了，先前討論早就提議了「建立允許不快速刪除的偽名字空間列表」，難道列表只能列在指引哩，不能寫在程式裡？？；關於介面是同理，將是偽名字空間的頁面改掉顯示名稱不就得了？技術上到底是有甚麼障礙，我看不出，有障礙的分明是「你不想」吧，例如下方列舉的程式碼片段：

在MediaWiki:Common.js加入程式碼片段不就能正常顯示了

(～)補充，你可以到諸如 [[MOS:001]] 的頁面，在瀏覽器Console模式下執行以下代碼，就可以看到介面顯示不再是「條目」。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月19日 (二) 07:20 (UTC)[回复]

var pseudoNS_list={
	MOS:wgULS('格式手册','格式手冊'),
	LTA:wgULS('持续出没的破坏者','持續出沒的破壞者'),
	SC:wgULS('捷径','捷徑'),
	/*這是DEMO，正式使用時請移除*/WIKIPEDIA:'Demo',
};
var ns=(function(test){return test.length>1?test[0]:''})(mw.config.get('wgPageName').replace(/[_\s]talk/i,'').replace(/talk:/i,'').split(':'));
var newregexp=function(test){return new RegExp(test.replace(/[-[\]{}()*+?.,\\^$|#\s]/g, "\\$&"),'ig')};
if(pseudoNS_list.hasOwnProperty(ns.toUpperCase())){
	var nstab=$('.vector-menu-content-list>li').filter(function(){return this.id.match(/nstab/i);});
	nstab.html(nstab.html().replace(newregexp(nstab.text()),pseudoNS_list[ns.toUpperCase()]));
}

或者

var newregexp=(test=>new RegExp(test.replace(/[-[\]{}()*+?.,\\^$|#\s]/g, "\\$&"),'ig'));
((ns_name,ns_tab,ns_list)=>ns_list.hasOwnProperty(ns_name)?ns_tab.html(ns_tab.html().replace(newregexp(ns_tab.text()),ns_list[ns_name])):null)(
	(test=>test.length>1?test[0]:'')(mw.config.get('wgPageName').replace(/[_\s]talk/i,'').replace(/talk:/i,'').split(':')).toUpperCase(),
	$('.vector-menu-content-list>li').filter(function(){return this.id.match(/nstab/i);}),
	{
		MOS:wgULS('格式手册','格式手冊'),
		LTA:wgULS('持续出没的破坏者','持續出沒的破壞者'),
		SC:wgULS('捷径','捷徑'),
		/*這是DEMO，正式使用時請移除*/WIKIPEDIA:'Demo',
	}
)

以上。再來，快速刪除方針，請參閱WP:CCC。未見系統性問題，謝謝。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月19日 (二) 07:14 (UTC)[回复]

在偽命名空間部分，我是以「有需求」為前提，如果共識認為不需設立或不能設立，那就是維持原案，也就沒有需要修方針的問題。--臺灣杉在此發言 (會客室) 2021年1月13日 (三) 02:58 (UTC)[回复]

而以現時討論而言主流意見為將MOS和LTA設為偽命名空間。--LuciferianThomas．留言 2021年1月13日 (三) 05:16 (UTC)[回复]

@LuciferianThomas：影響的範圍較大，即使有主流共識，目前討論的參與者人數並不能代表整個社群。空氣小貓（留言） 2021年1月17日 (日) 14:17 (UTC)[回复]

能有多大？，不就條目名字空間裡多幾個幾乎不會發生命名衝突的捷徑而已？怎麼講的好像設立下去維基伺服器會炸掉一樣。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月17日 (日) 14:43 (UTC)[回复]

關於主流意見的共識，我認為引用WP:7DAYS並無不妥，你不可能直接讓幾千人一起討論，你這樣說乾脆舉辦維基社群公投算了，BUT:WP:投票不能代替討論。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月17日 (日) 14:45 (UTC)[回复]

个人认为，如果长期破坏者（LTA）有成为名字空间的潜力的话，应该此时直接升级成为名字空间。不然，如果之后再讨论升级为名字空间，所有带LTA:前缀的页面还要重新移动一遍。 ——羊羊 (留言|贡献) 2021年1月15日 (五) 12:04 (UTC)[回复]

感觉LTA页面及名字空间有违WP:RBI。如果设立名字空间的同时增设页面查看权限（回退员及以上），我会考虑支持。--YF dyh000（留言） 2021年1月15日 (五) 12:28 (UTC)[回复]

但似乎普遍意見並不贊同LTA升格真命名空間，即使有潛力但卻缺乏社群共識，也難以行事。--LuciferianThomas．留言 2021年1月15日 (五) 17:40 (UTC)[回复]

(－)反对设立MOS和LTA名字空间，这与技术问题无关，而是目前MOS和LTA页面的数量和读者关注的程度远远达不到需要设立新名字空间的地步。LTA页面的数量充其量也就一百个左右，MOS页面的数量更是少得可怜，才十几个，远远没有达到维基专题那样的2000多个页面。同时，LTA只有熟悉CU等站务的编者会去查阅，MOS查阅的人数更少，这些也完全比不上熟悉某些特定领域的编者和读者都会关注的维基专题。因此，我反对设立以上两个名字空间，对设立伪名字空间表示(＝)中立。——BlackShadowG（留言）维基百科20周年庆即将到来 2021年1月15日 (五) 13:41 (UTC)[回复]

LTA数量可能少，但shortcut还是蛮多的。而且LTA数量也会增多-- ——羊羊 (留言|贡献) 2021年1月16日 (六) 12:55 (UTC)[回复]

偽命名空間只是for捷徑連結而已，原本的頁面不會被移動。--LuciferianThomas．留言 2021年1月16日 (六) 13:12 (UTC)[回复]

(＋)支持偽名字空間。我原本是支持名字空間的，但經歷了上述討論以及主持了專題名字空間的設立，我發現偽名字空間是有許多優點的。先看名字空間，名字空間是需要「安裝」的，本地獲得共識之後要等待工程師安裝，期間從數周到數月不等，且不具備可擴充性，即每新增一個名字空間都要請工程師協助，本地管理員、介面管理員、模組編輯員都無能為力，只有基金會工程師可以執行，「真名字空間」可擴充性不佳。我們來看看「偽名字空間」，它「免安裝」耶，隨加即用，涉及命名空間判斷的本地模板與模組本地的管理員、介面管理員、模組編輯員都能即時加入，也不必等待工程師安裝，「偽名字空間」可擴充性十分良好。假如今天社群需要一個新的捷徑前綴或字首，真名字空間需要等待工程師安裝，而偽名字空間公示通過後就能隨加即用，是多麼的方便。正如臺灣杉在此發言 (會客室)所言：「如果偽命名空間不會造成「系統性」的重大問題，就可以納入考量。」且許多問題如模板輸出都可以透過技術手段解決，參見#宇帆於2021年1月19日 (二) 07:14 (UTC)之發言。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月19日 (二) 07:16 (UTC)[回复]

捷徑空间提案

标题添加： ——羊羊 (留言|贡献) 2021年1月19日 (二) 05:21 (UTC)[回复]

否決：

設立捷徑專用名字空間無法有效解決本案核心問題。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月20日 (三) 07:14 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

大家普遍對於建立新名字空間「頁面不夠不足以獨立名字空間」、「獨立名字空間指引會分散兩地」.....、又不想占用其他名字空間，或不想看到介面顯示為「條目」....又有許多意見想解決名稱衝突問題......這也太困難（好似：又要馬兒肥、又要馬兒不吃草）。(＆)建議乾脆定義一個「捷徑」名字空間「Shortcut:」好了。然後找一個簡短的文字當作名字空間別名，例如「Link」的「L」，然後捷徑變成「L:MOS:XX」、「L:LTA:XX」之類的，這樣既不會占用其他名字空間造成命名衝突，介面也不會顯示為「條目|條目討論」會顯示為「捷徑|捷徑討論」；也不必擔心頁面太少不足以獨立成名字空間：因為它整合了MOS、LTA等；也不會導致指引分散兩地；也不會佔用到其他名字空間；也不會有名稱衝突。（為了整合所有反對意見所產生的奇異提案。）-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月17日 (日) 09:29 (UTC)[回复]
- 剛才小研究一下英文維基的偽名字空間，真的有許多詭異的偽名字空間捷徑，除了MOS:外，例如「MP:」連接首頁上不同區域的章節捷徑。。。如果社群傾向不跟隨英文維基也是可以搞一個本地特色的名字空間。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月17日 (日) 10:29 (UTC)[回复]
但此會造成混亂，因為WP:VIP之類的捷徑卻不在捷徑空間，但也同時沒有理由改為L:WP:VIP。--LuciferianThomas．留言 2021年1月18日 (一) 02:08 (UTC)[回复]
- WP開頭的捷徑當然是留在WP空間；現在是要解決跨空間問題吧。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月18日 (一) 07:32 (UTC)[回复]
  - (：)回應@LuciferianThomas：我想到辦法了，一樣是捷徑名字空間，然後將LTA與MOS都設定為這個名字空間的別名，這樣就能建立MOS:XX、LTA:XX也不會佔用到任何其他名字空間。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月19日 (二) 05:32 (UTC)[回复]
    可是缺點是，以後如果有其他捷徑字首的需求，都要去phab申請，可擴充性不佳。偽名字空間的優點就是擴充性佳、容易設立。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月19日 (二) 05:38 (UTC)[回复]
    呃等等，如此LTA:123==MOS:123？若未來出現了一個「兩岸四地用語破壞者」，而現時的WP:CS4D佔用MOS:CS4D==L:CS4D，那麼就只能迴避LTA:CS4D==L:CS4D？--LuciferianThomas．留言 2021年1月19日 (二) 07:19 (UTC)[回复]
    阿，沒有想到這個問題。這太困難了，突然覺得設立「偽名字空間」才是最省事的方案。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月19日 (二) 07:24 (UTC)[回复]
  還有一個盲點，要說跨空間，老實那句，這命名空間的重定向也是跨命名空間，還是要修訂R2。--LuciferianThomas．留言 2021年1月19日 (二) 07:34 (UTC)[回复]
  @A2569875：撤回議案…？--LuciferianThomas．留言 2021年1月20日 (三) 00:20 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

小結3

我的意見是，如果偽命名空間不會造成「系統性」的重大問題，就可以納入考量。例如佔用其他命名空間、習慣性等等問題，在我眼中看來不是重大系統問題，而且可以透過其他技術手段解決（如上所述）。--臺灣杉在此發言 (會客室) 2021年1月18日 (一) 10:16 (UTC)[回复]

“顯示為‘條目|條目討論’”是指重定向页吗？我觉得重定向页显示条目没什么大问题（） ——羊羊 (留言|贡献) 2021年1月19日 (二) 05:07 (UTC)[回复]
見ナナチ上方的留言，當中有說明可在MediaWiki:Common.js加一段代碼讓偽命名空間不顯示「條目」。--LuciferianThomas．留言 2021年1月19日 (二) 07:50 (UTC)[回复]

(：)回應@LuciferianThomas：已測試相關代碼（程式碼片段）在Common.js中的行為，Special:Diff/63843386，以[[MOS:001]]為例，效果見圖File:Pseudo-Namespace MOS UI Test in Chinese Wikipedia.png。如偽名字空間通過設立可以考慮請求介面管理員添加相關代碼於MediaWiki:Common.js。副知@羊羊32521：重定向页显示条目已有可行解決辦法。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月21日 (四) 08:32 (UTC)[回复]

其实照这个思路，如果怕伪名字空间占用条目名字空间，又怕（对于MOS:）指引分散，可以设立MOS:名字空间，然后MOS:下的页面重定向到Wikipedia空间的格式手册里 ——羊羊 (留言|贡献) 2021年1月19日 (二) 05:21 (UTC)[回复]
這不太符合邏輯吧，同時存在「格式手冊」命名空間和專案（維基百科）命名空間的格式手冊。額外設立一個「格式手冊」或「長期破壞者」命名空間但只作重定向用，好像沒什麼意義。--LuciferianThomas．留言 2021年1月19日 (二) 07:48 (UTC)[回复]

再提捷徑空间提案

本主題全部或部分段落文字，已轉移至Wikipedia:互助客栈/技术#捷徑空间提案2。执行人：Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 _{祝百毒不侵～}。標記人：_{_{來人啊，餵宮子吃布丁！}} ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月25日 (一) 06:32 (UTC)。[回复]

尝试推动LTA空间

結以待續，請發起新議案。--LuciferianThomas．留言 2021年1月31日 (日) 23:09 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

经过上方的讨论，我认为LTA更适宜作为真·名字空间。好处是（上方有人提到）可以设置所有页面为NOINDEX，增设页面查看权限（体现WP:RBI，而且有天邪鬼这种……）。

此外，LTA与Project空间联系性不大，没有维护问题。而且，如果设伪名字空间之后再讨论升级为名字空间，所有带LTA:前缀的页面还要重新移动一遍。(mw:Help:Namespace)

至于LTA页面数量少……我是不知道设立名字空间还有页面数量门槛啊…… 囧rz…… ——羊羊 (留言|贡献) 2021年1月23日 (六) 05:20 (UTC)[回复]

如果用户不可查看的名字空间不会显示在Special:搜索，我想名字空间多不是个大问题。赞成“LTA与Project空间联系性不大”。不认为二次移动是个大问题，社群可以先用伪名字空间看看效果。--YF dyh000（留言） 2021年1月23日 (六) 12:25 (UTC)[回复]

我覺得可以，但目前名字空間的申請正在排隊（需插入程式碼到\mediawiki-config\wmf-config\InitialiseSettings.php ，且如有頁面權限問題或要不要NOINDEX問題需要額外調整$wgNamespacesToBeSearchedDefault、$wgNamespaceRobotPolicies等其他數值，如需要對IP用戶和新用戶隱藏，可能還需要mw:Extension:Lockdown），因此，如需設立可能還需要等待數周。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月25日 (一) 06:29 (UTC)[回复]
本議案可能須分階段討論，要討論的項目有：
1. 是否需要默認關閉LTA頁面的Special:搜索？（mw:Manual:$wgNamespacesToBeSearchedDefault設定）
2. 是否需防止LTA頁面被機器人或網路爬蟲索引？（mw:Manual:$wgNamespaceRobotPolicies設定）
3. 是否需設定LTA頁面的檢視權限？（例如，只有自動確認用戶、巡查員、回退員、管理員能檢視/訪問這些頁面，需引入mw:Extension:Lockdown）
等。如具備以上需求，才有必要定為名字空間。以上，請討論-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月27日 (三) 04:57 (UTC)[回复]
- 根据之前的一些Task維基媒体不会启用mw:Extension:Lockdown。但是如果只是为了避免WP:BEANS而没有保密需求那么用CSS屏蔽掉内容显示即可。--GZWDer（留言） 2021年1月27日 (三) 11:58 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

@羊羊32521：討論不知道為什麼被關掉了，(？)疑問你有要繼續推動的意願嗎？-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月1日 (一) 09:36 (UTC)[回复]
YFdyh000说让社群看看伪名字空间的效果……我觉得可以先这样？过一段时间再提吧-- ——羊羊 (留言|贡献|古典音乐专题) 2021年2月1日 (一) 09:43 (UTC)[回复]

關掉是希望這個分開重新討論，不要卡在議案的中間，有點尷尬，歡迎開新討論。--LuciferianThomas．留言 2021年2月1日 (一) 12:28 (UTC)[回复]

偽命名空間相關方針及WP:捷徑修正

通過：

公示七日結束，共識期間唯一異議排除，公示獲得通過，有關條文。即日起MOS、LTA偽命名空間獲得CSD R2例外，上述命名空間作為格式手冊和長期破壞者頁面的正規連結。--LuciferianThomas．留言 2021年1月31日 (日) 03:11 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

本討論已近一個月，得到的回饋有：

主流意見認為格式手冊及長期破壞者（持續出沒的破壞者）宜設立偽命名空間；
已有技術手段可分出偽命名空間與主命名空間的差異性；
設立偽命名空間無重大系統性問題，且部署容易，不牽涉到基金會層面之程式修改。

由此，偽命名空間將會在上段討論開始一個月後進行公示（也沒過幾天），而相關規範也將儘速修正或設立，下列針對快速刪除方針R2進行修正，及將WP:捷徑中的偽命名空間部分做為指引。下列為R2修正提案。

現行條文

R2. 跨名字空间的重定向。

由条目的名字空间重定向至非條目名字空间，将用户页移出条目名字空间時遺留的重定向，或者从草稿名字空间指向非草稿名字空间的重定向。（有时新加入的维基人偶尔会在主条目空间誤建用户页。使用“移动”页面工具将用户页移回用户名字空间会保留页面历史，在删除遺留的重定向頁前，考虑保留一到两天；草稿重定向速删前，请确保草稿已经完成其作用，并且草稿的历史已经合适地移动到相应的正式页面。）

提議條文

R2. 跨名字空间的重定向。

由条目的名字空间重定向至非條目名字空间，将用户页移出条目名字空间時遺留的重定向，或者从草稿名字空间指向非草稿名字空间的重定向。經社群同意設立的偽命名空間屬於本規則之例外。注意：有时新加入的维基人偶尔会在主条目空间誤建用户页。使用“移动”页面工具将用户页移回用户名字空间会保留页面历史，在删除遺留的重定向頁前，考虑保留一到两天；草稿重定向速删前，请确保草稿已经完成其作用，并且草稿的历史已经合适地移动到相应的正式页面。

捷徑中偽命名空間的規範詳見這裡。

請討論。臺灣杉在此發言 (會客室) 2021年1月20日 (三) 06:53 (UTC)[回复]

同意提案。SAN MO SA _SPQR 2021年1月20日 (三) 08:10 (UTC)[回复]

(＋)贊成R2修正案，另就WP:捷徑，我看了一遍，似乎要整個重新整理過。--LuciferianThomas．留言 2021年1月20日 (三) 10:04 (UTC)[回复]

捷徑修正細節是最後一項討論內容，目前先以偽命名空間為討論對象。也歡迎對捷徑規範作重新整理。--臺灣杉在此發言 (會客室) 2021年1月20日 (三) 12:19 (UTC)[回复]

(＋)支持WP:CSD修正案與偽名字空間。我原本是支持名字空間的，但經歷了上述討論以及主持了專題名字空間的設立，我發現偽名字空間是有許多優點的。先看名字空間，名字空間是需要「安裝」的，本地獲得共識之後要等待工程師安裝，期間從數周到數月不等，且不具備可擴充性，即每新增一個名字空間都要請工程師協助，本地管理員、介面管理員、模組編輯員都無能為力，只有基金會工程師可以執行，「真名字空間」可擴充性不佳。我們來看看「偽名字空間」，它「免安裝」耶，隨加即用，涉及命名空間判斷的本地模板與模組本地的管理員、介面管理員、模組編輯員都能即時加入，也不必等待工程師安裝，「偽名字空間」可擴充性十分良好。假如今天社群需要一個新的捷徑前綴或字首，真名字空間需要等待工程師安裝，而偽名字空間公示通過後就能隨加即用，是多麼的方便，然而要實現此需要修正WP:CSD#R2，正如臺灣杉在此發言 (會客室)所言：「如果偽命名空間不會造成「系統性」的重大問題，就可以納入考量。」，參見#宇帆於2021年1月19日 (二) 07:16 (UTC)之發言，未見要修正WP:CSD#R2會出現什麼系統性問題，故此(＋)支持WP:CSD修正案。以上-- _{_{來人啊，餵宮子吃布丁！}} ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月21日 (四) 08:06 (UTC)[回复]

想向諸位確認一下@A2569875、Taiwania Justo：此案中已經說明偽命名空間的實施，意即此案通過則偽命名空間同步通過？--LuciferianThomas．留言 2021年1月22日 (五) 11:32 (UTC)[回复]

順序是上面的MOS、LTA先公示完畢，本案才會接著進行公示。於此期間兩邊同步討論。--臺灣杉在此發言 (會客室) 2021年1月22日 (五) 15:05 (UTC)[回复]

我認為兩案必然掛鉤，建議若公示偽命名空間則同步公示R2修訂，沒有分部處理的必要。--LuciferianThomas．留言 2021年1月22日 (五) 22:06 (UTC)[回复]

@Taiwania Justo：兩者應當一同公示並通過，否則會有合法性問題。SAN MO SA _SPQR 2021年1月23日 (六) 08:55 (UTC)[回复]

借問：現在討論似乎已經算超過一個月了（這提案承接上次討論，已經很久了），而已經達到基本社群共識（共識不強求全然同意，但可採取主流意見），理論上可以7DAYS？--LuciferianThomas．留言 2021年1月23日 (六) 09:25 (UTC)[回复]

那就現在公示吧。--臺灣杉在此發言 (會客室) 2021年1月24日 (日) 02:47 (UTC)[回复]

本討論超過一個月，且偽命名空間之相關技術問題已得到解決，且主流意見認為有設置必要，現就偽命名空間、R2及WP:捷徑內的偽命名空間規範 公示7日，2021年1月31日 (日) 02:51 (UTC) 結束。臺灣杉在此發言 (會客室) 2021年1月24日 (日) 02:51 (UTC)[回复]

@Taiwania Justo、LuciferianThomas：啟用偽命名空間能解決什麼問題？我相信這是提案必須討論的重點，我需要有人能回答這個問題。如果沒辦法解決什麼問題，我認為維持現狀即可，也就是WP足矣。然而，就我查看整個討論，似乎都是討論命名空間真偽的可行性，只有幾個留言有提到這個問題。空氣小貓（留言） 2021年1月29日 (五) 04:57 (UTC)[回复]

看來你是沒有看到最初的討論，見本章節頂端討論導航最初的討論，已經是說明了偽命名空間的作用為讓捷徑意義更加清晰且減少可能構成重複的捷徑名稱的情況。現在不是解決問題的情況，而是優化社群討論和表達的問題了。--LuciferianThomas．留言 2021年1月29日 (五) 05:01 (UTC)[回复]

一直以來捷徑都沒有什麼規範，尤其是格式手冊、維基專題及LTA的頁面重定向，表達不清之餘容易造成混亂，偽命名空間就是讓這些項目的捷徑統一化，方便社群溝通。--LuciferianThomas．留言 2021年1月29日 (五) 05:04 (UTC)[回复]

例子：MOS:BOLD較WP:MOSBOLD簡潔，但連結至格式手冊的捷徑沒有規範導致格式混亂難以維護，有些有WP:MOS字首有些沒有；而LTA更甚，捷徑完全沒有要表達連結目標為LTA頁面的意思。相對於WP:LTA/HBN，使用偽命名空間概念的LTA:HBN更簡潔易明。在解決捷徑的問題的同時順便推動在其他維基項目運行暢順的偽命名空間比較合適。--LuciferianThomas．留言 2021年1月29日 (五) 05:13 (UTC)[回复]

@LuciferianThomas：真是抱歉，我沒有一直關注這個提案，突然要找相關討論也找不到。既然如此，我沒意見了。--空氣小貓（留言） 2021年1月29日 (五) 14:02 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

進一步討論

自動提刪R2

完成 by Jimmy Xu--LuciferianThomas．留言 2021年2月1日 (一) 23:04 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

現時主命名空間的R2好像有機械人自動提速刪？是否要請BOT主修正，或暫時透過過濾器阻止機械人速刪？--LuciferianThomas．留言 2021年1月31日 (日) 03:11 (UTC)[回复]

@Jimmy Xu。--臺灣杉在此發言 (會客室) 2021年1月31日 (日) 04:31 (UTC)[回复]

Special:Diff/64056831-- Sunny00217 2021年2月1日 (一) 11:53 (UTC)[回复]

已更新。--Jimmy Xu ^论 2021年2月1日 (一) 14:07 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

MOS捷徑名稱

LTA空間的捷徑大部分都可以快速移動，但格式手冊的捷徑很多不同格式，在此希望各位一同組成完整的新捷徑列表。--LuciferianThomas．留言 2021年1月31日 (日) 03:11 (UTC)[回复]

WP:NS2021/MOSSC，已列出部分格式手冊可用捷徑，請檢查，並協助補充。--LuciferianThomas．留言 2021年2月1日 (一) 08:48 (UTC)[回复]

已完成，請協助檢查。--LuciferianThomas．留言 2021年2月3日 (三) 04:35 (UTC)[回复]

軟重定向

已否決：

--LuciferianThomas．留言 2021年1月31日 (日) 04:58 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

原有的捷徑可否改為軟重定向並作出提示「此捷徑已移動至XXX，請直接使用新捷徑」？--LuciferianThomas．留言 2021年1月31日 (日) 03:11 (UTC)[回复]

(－)反对，原有重新導向應保留，沒必要軟重新導向。--空氣小貓（留言） 2021年1月31日 (日) 03:56 (UTC)[回复]

或是透過JS小工具提示功能，讓用戶在非討論頁面中點擊舊有連結時提示修改為新連結？--LuciferianThomas．留言 2021年1月31日 (日) 04:23 (UTC)[回复]

不必更動，英語維基百科部分MOS也有用WP的捷徑。--臺灣杉在此發言 (會客室) 2021年1月31日 (日) 04:32 (UTC)[回复]

好的，那麼就捨棄軟重定向，只重新議論MOS的捷徑名稱。--LuciferianThomas．留言 2021年1月31日 (日) 04:52 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

技術問題處理

已通過：

已完成設定並佈署。-- 五歲抬頭雪菲（☎️·☘️） 2021年3月24日 (三) 05:50 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

命名空間偵測模板以及MediaWiki:Common.js（見此處）需要提編輯請求，以令偽命名空間生效。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月31日 (日) 05:30 (UTC)[回复]

小補充：偽命名空間捷徑可用{{捷徑重定向}}標記，已加入自動偵測偽命名空間顯示偽命名空間簡單說明。--LuciferianThomas．留言 2021年2月2日 (二) 05:55 (UTC)[回复]

另外@A2569875：已創建MOS:、MOS:MOS、MOS:手冊、MOS:格式手冊供你們測試各項技術問題。--LuciferianThomas．留言 2021年2月2日 (二) 05:59 (UTC)[回复]

根據Wikipedia:保護方針#需进行公示，即使偽命名空間已獲得社群共識，輕微影響外觀顯示的編輯仍需公示七日，因為未添加亦不會影響偽命名空間的運作。--空氣小貓（留言） 2021年2月2日 (二) 06:29 (UTC)[回复]

@LuciferianThomas。--空氣小貓（留言） 2021年2月2日 (二) 06:34 (UTC)[回复]

@LuciferianThomas、Pseudo Classes：還不能公示，因為討論仍在進行中MediaWiki_talk:Common.js#編輯請求_2021-01-31。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月2日 (二) 06:39 (UTC)[回复]

不影響運作，他可以使用個人JS頁面進行測試，只是這個意思。而提及重定向模板純粹因為這個章節叫做「技術問題處理」，沒有其他地方方便提及就在這裏說而已。--LuciferianThomas．留言 2021年2月2日 (二) 07:22 (UTC)[回复]

(：)回應由於U:YFdyh000提到的誤導問題，故反對使用個人用戶小工具模式，因為誤導問題就是在於不知此事的人，知道的人啟用小工具又有什麼卵用？故強烈建議全站套用。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月2日 (二) 10:50 (UTC)[回复]

@A2569875：可以考虑作为默认启用的小工具，这样也方便维护。--安忆 ^Talk 2021年2月2日 (二) 12:35 (UTC)[回复]

@Pseudo Classes：閣下錯引方針了，該章節位於「使用和處理編輯請求」章節底下，指明是管理員和模板編輯員在處理編輯請求的情況下才需要經過討論及七日公示。該模板僅為半保護防止破壞，而非模板保護。--LuciferianThomas．留言 2021年2月2日 (二) 11:47 (UTC)[回复]

@LuciferianThomas：首句「在受保護的頁面上編輯時，應當特別小心，並於共識和任何相關的指導方針相一致」，只要是受保護的頁面均受此限制。--空氣小貓（留言） 2021年2月2日 (二) 11:54 (UTC)[回复]

該章節也提到：「一些會輕微影響使用方式和外觀顯示的編輯，需在提交編輯請求後等待七天，無爭議方可進行修改」，您沒有提出編輯請求即自行變更，可視為繞過程序。--空氣小貓（留言） 2021年2月2日 (二) 11:58 (UTC)[回复]

自動確認用戶編輯非編輯爭議的半保護頁面也要提出編輯請求是什麼說法？那麼怎麼不直接模板保護？--LuciferianThomas．留言 2021年2月2日 (二) 12:01 (UTC)[回复]

@LuciferianThomas：依照您這個說法，難道模板編輯員和管理員對模板重大更新，都不用提交編輯請求？此外，半保護並不是只有防止破壞，其亦屬於高風險模板。--空氣小貓（留言） 2021年2月2日 (二) 12:17 (UTC)[回复]

已處理，見本人討論頁。--LuciferianThomas．留言 2021年2月2日 (二) 12:45 (UTC)[回复]

當初本議案一堆人以「介面會顯示[條目]」為由異議，後來是提出了「修改MediaWiki:Common.js解決問題」排除異議，而使得異議排除通過議案，那如果現在不設置不就變成「異議沒有排除」？反對這種花式推翻議案的作法。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月2日 (二) 12:01 (UTC)[回复]
（已站外解釋，宇帆似乎誤解了我們上面說公示和編輯保護模板的事情。）另外想說此處之前對有關JS編碼的支持意見可視為對於「同意作出這樣更改」的意見嗎？--LuciferianThomas．留言 2021年2月2日 (二) 12:48 (UTC)[回复]

建立預設啟用/默認啟用的小工具來呈現偽名字空間介面

上述有些意見（含MediaWiki_talk:Common.js#編輯請求_2021-01-31的留言）認為小工具有利於維護；而U:AnYiLin已將代碼整改為可用於小工具的格式（這則留言）。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月2日 (二) 16:20 (UTC)[回复]

还有个小建议：当处于移动视图时，不必在minerva皮肤的页面标题（脚本里的tips_selector）处添加提示，因为在触控设备上没办法看到鼠标悬停才有的提示，反而被加了下划线，感觉不太美观。--安忆 ^Talk 2021年2月2日 (二) 16:31 (UTC)[回复]

(：)回應@AnYiLin：User:A2569875/pseudonamespace_UI.js已修改。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月2日 (二) 19:48 (UTC)[回复]

感觉用'ontouchstart' in document.documentElement来判断更合适。--安忆 ^Talk 2021年2月3日 (三) 08:59 (UTC)[回复]

完成Special:Diff/64090030，已加入代碼。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月3日 (三) 09:33 (UTC)[回复]

(＋)支持預設啟用小工具，在使用上與修改介面理應無異；亦方便維護，當通過新偽命名空間時可快速增添設定。--LuciferianThomas．留言 2021年2月3日 (三) 08:47 (UTC)[回复]

(～)補充：亦支持直接修改介面，這真的視乎最終選擇。--LuciferianThomas．留言 2021年2月3日 (三) 08:53 (UTC)[回复]

@LuciferianThomas：修改介面？那不就又回到獨立成新的命名空間了嗎？（技術問題還少些）-- Sunny00217 2021年2月4日 (四) 08:47 (UTC)[回复]

…你是真的沒有跟上整個討論對吧…所謂「修改界面」是修改顯示界面，僅表示顯示界面時捷徑頁不是直接顯示頁面為「條目」而已，實際上不影響任何其他方面。--LuciferianThomas．留言 2021年2月4日 (四) 08:52 (UTC)[回复]

小工具執行結果
以頁面[[MOS:MOS]]為例

設定為繁體中文(以zh-tw為例)	設定為簡體中文(以zh-cn為例)

提供目前版本小工具運行結果圖，供公示參考用。右上角的連結為Wikipedia:偽名字空間用於說明，如有缺漏歡迎改善。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月3日 (三) 19:03 (UTC)[回复]

@A2569875：等等等一下，這版在像是Mos:$1沒有大寫的也會執行耶，，，-- Sunny00217 2021年2月4日 (四) 08:45 (UTC)[回复]

(：)回應@Sunny00217：那就不要toUpperCase()了。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月4日 (四) 08:51 (UTC)[回复]

(※)注意：為免混淆WP:偽名字空間原有內容移動至WP:PNS+，並改為指向WP:捷徑#偽命名空間使其等價WP:偽命名空間的重定向。--LuciferianThomas．留言 2021年2月5日 (五) 06:21 (UTC)[回复]

(？)疑問@LuciferianThomas：所以「偽名字空間」（[[WP:偽名字空間|偽名字空間]]）要改成什麼？-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月5日 (五) 06:46 (UTC)[回复]
維基百科:偽命名空間輔助說明（捷徑WP:PNS+）--LuciferianThomas．留言 2021年2月5日 (五) 08:10 (UTC)[回复]
BTW在問號圖案後加個空格唄，貼著很醜…--LuciferianThomas．留言 2021年2月5日 (五) 08:13 (UTC)[回复]
- 完成：Special:Diff/64147054。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月6日 (六) 14:00 (UTC)[回复]
- @LuciferianThomas：還有其他疑問嗎？若沒有我就要公示囉？@AnYiLin：高風險模板/介面編輯請求的公示確定不必放公告欄嗎？-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月7日 (日) 04:07 (UTC)[回复]
  支持啟動公示。--LuciferianThomas．留言 2021年2月7日 (日) 04:37 (UTC)[回复]
  
  在此公示吧，这个修改只是配合伪名称空间的使用，后者已经公示过了。我刚刚也再次读了一遍保护方针，没理解错的话其只要求在对受保护的模板和模块进行一些更改时需要达成共识/进行公示。
  
  此小工具会默认开启并在参数设置处隐藏，避免用户误操作关闭（达到和直接放进common.js同样的效果）。--安忆 ^Talk 2021年2月7日 (日) 04:46 (UTC)[回复]
  我反對隱藏，我個人不需要這個功能，想將其關閉。使用者誤關閉不會造成嚴重問題，如果有人問起相關問題，叫他重新打開就好了，看不出隱藏的必要性。--Xiplus#Talk 2021年2月15日 (一) 04:34 (UTC)[回复]
  但是如果这段代码直接按最初设想放进common.js的话，也是关不掉的吧。--安忆 ^Talk 2021年2月15日 (一) 04:44 (UTC)[回复]
  做成小工具就是因为有关闭的需求，其次是维护的需求。--YF dyh000（留言） 2021年2月15日 (一) 04:46 (UTC)[回复]
  做成小工具本来就是我提出来的，从未考虑过提供其他需求（比如自由选择开关），只是为了方便维护，不用去改common.js，放进common.js根本没得选。--安忆 ^Talk 2021年2月15日 (一) 04:51 (UTC)[回复]

公示7日：現交付公示，公示詳細資訊如下：

小工具原始碼
~~User:A2569875/pseudonamespace_UI.js~~（WP:CSD#O1）→MediaWiki:Gadget-pseudonamespace-UI.js （公示完畢後會使用「移動不留重新導向」功能移動到MediaWiki:Gadget-空間）
小工具執行結果
以頁面[[MOS:MOS]]為例

設定為繁體中文	設定為簡體中文

如期內無合理異議則全站套用此修改。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月8日 (一) 05:56 (UTC)[回复]

公示通過了，@A2569875、AnYiLin。--LuciferianThomas．留言 2021年2月15日 (一) 06:49 (UTC)[回复]

於Phabricator查看
編號T178356的工單

@LuciferianThomas：被User:Jon_(WMF)刪掉了Special:Diff/64319519....說甚麼有東西undefined，看半天沒看出原因，至少我這邊所有裝置測試都沒出問題。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月16日 (二) 06:40 (UTC)[回复]

看起來是startsWith()問題，部分瀏覽器不支援。--LuciferianThomas．留言 2021年2月16日 (二) 09:10 (UTC)[回复]

安億君幫您為不支援的平台補了function的定義了。--LuciferianThomas．留言 2021年2月16日 (二) 09:12 (UTC)[回复]

meta:User_talk:Jon_(WMF)#Gadget-pseudonamespace-UI@zhwiki，問題似乎已解決？—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月25日 (四) 05:46 (UTC)[回复]

完成：已通過並佈署。-- 五歲抬頭雪菲（☎️·☘️） 2021年3月24日 (三) 05:50 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

自動半保護偽命名空間

我很難說有多少人會去破壞MOS捷徑，但倒是LTA捷徑有可能會被破壞。建議可自動半保護（建立、編輯、移動）主命名空間「MOS:」、「LTA:」字首的條目空間。--LuciferianThomas．留言 2021年1月31日 (日) 08:28 (UTC)[回复]

不應做出預見性保護。--Xiplus#Talk 2021年2月2日 (二) 10:26 (UTC)[回复]

若捷徑指向的條目因為破壞被保護，有需要跟隨進行保護嗎？--LuciferianThomas．留言 2021年2月2日 (二) 12:06 (UTC)[回复]

不需要吧，有這樣的案例嗎？--Xiplus#Talk 2021年2月2日 (二) 12:30 (UTC)[回复]

案例我不清楚，但我倒是覺得需要，尤其本來有某些LTA有破壞自己LTA頁的傾向，可算是高風險。--LuciferianThomas．留言 2021年2月2日 (二) 12:59 (UTC)[回复]

有破壞事實就能保護，不需預先保護。--Xiplus#Talk 2021年2月2日 (二) 13:04 (UTC)[回复]

建议用滥用过滤器阻止非自动确认用户编辑，配以相关警告。--YF dyh000（留言） 2021年2月2日 (二) 13:07 (UTC)[回复]

(＋)支持用滥用过滤器阻止非自动确认用户编辑，配以相关警告。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月7日 (日) 04:08 (UTC)[回复]

提議設立快速刪除標準 O8

通過。SAN MO SA _Σουέζ 2021年4月21日 (三) 03:28 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

現行條文

(無)

提議條文

O8. 在偽命名空間中建立的非重新導向頁面。

偽命名空間僅能用於重新導向。如可以移動到合適的名稱，請將頁面移動到合適的名稱，否則請使用此款快速刪除。若頁面明顯是一個條目，則不適用此款快速刪除。

使用模板{{d|O8}}。

根據上述討論，偽命名空間應僅能是重定向頁。位於偽命名空間中的非重定向頁應可被快速刪除。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月1日 (一) 09:53 (UTC)[回复]

(＋)支持，若有條目真的需要以偽命名空間佔用條目前綴，使用全形冒號而非半形冒號以辨別即可，此可避免之前有用戶擔憂會佔用主空間條目名的情況。另外，我本來是在想可以把這條同時套用於不當使用偽命名空間重定向至其他頁面，但想起有個別屬於格式手冊的論述其實不在Wikipedia:格式手冊/前綴（WP:SAL），所以暫時作罷。--LuciferianThomas．留言 2021年2月1日 (一) 11:12 (UTC)[回复]

@LuciferianThomas：使用全形冒號，極有可能違反命名常規。--空氣小貓（留言） 2021年2月2日 (二) 05:46 (UTC)[回复]

未見命名常規有不能用全形冒號的規則。若以與事物本身名稱不同說違反常規，可按照其他命名技術限制做法，不加冒號或改用全形冒號，並以{{Wrongtitle}}標記即可。--LuciferianThomas．留言 2021年2月2日 (二) 05:52 (UTC)[回复]

@LuciferianThomas：名從主人，這就是有使用者擔憂會佔用主空間條目名的情況，也有像en:Gadget:Invention, Travel, & Adventure類似的情況。--空氣小貓（留言） 2021年2月2日 (二) 06:04 (UTC)[回复]

可直接按照該情況處理，若通過則當作技術限制即可。用{{DISPLAYTITLE}}修正亦可。--LuciferianThomas．留言 2021年2月2日 (二) 06:21 (UTC)[回复]

這理論上可以出現在任何命名空間的情況，故按照命名空間一般處理方式即可。--LuciferianThomas．留言 2021年2月2日 (二) 06:24 (UTC)[回复]

很抱歉，{{DISPLAYTITLE}}需使用全名，少一個冒號就不會變更顯示。--空氣小貓（留言） 2021年2月2日 (二) 06:33 (UTC)[回复]

(＋)支持。--忒有钱 🌊塩水あります🐳（留言） 2021年2月1日 (一) 15:20 (UTC)[回复]

為何不是移動到合適的名稱？例如在LTA:誤建LTA頁面應該移動到WP空間後，讓原先頁面成為重新導向之類的。--Xiplus#Talk 2021年2月2日 (二) 05:53 (UTC)[回复]

若果明顯屬於錯誤建立有關專題頁面的當然可以移動，這裡應該是指創建與該專題無關的頁面。--LuciferianThomas．留言 2021年2月2日 (二) 06:01 (UTC)[回复]

那就要寫清楚，避免被提快速刪除後，管理員未注意直接刪除。--空氣小貓（留言） 2021年2月2日 (二) 06:07 (UTC)[回复]

(！)意見：偽命名空間的設立理應是用作指向比較複雜的Wikipedia命名空間項目，不應用以指向其他無關條目，或許可以增加刪除「非指向維基百科命名空間的重定向」條款？理論上偽命名空間屬於WP空間的延伸，不應該出現指向WP以外的偽命名空間，其他命名空間有自己的命名空間別稱，不會使用偽命名空間捷徑。未來倘若通過將部分項目升格命名空間，但該項目本身有偽命名空間捷徑，該等捷徑理應全數自動納入新命名空間而不會保留於主命名空間，不會影響此規則。--LuciferianThomas．留言 2021年2月2日 (二) 06:12 (UTC)[回复]

呃忘了有幾條MOS在PJ空間。--LuciferianThomas．留言 2021年2月3日 (三) 08:48 (UTC)[回复]

還有這種事？！-- Sunny00217 2021年2月3日 (三) 09:18 (UTC)[回复]

有啊，專題的條目指引有幾條跟隨專題搬過去了。列表有寫。也有疑似專題移了但分頁未移的餘孽，但遲早都要搬過去吧。--LuciferianThomas．留言 2021年2月3日 (三) 11:10 (UTC)[回复]

§ 第二階段：轉移至新名字空間在讨论这类MOS的更名，很快就能解决。——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年2月4日 (四) 11:18 (UTC)[回复]

加了附加條件之後讓我覺得這個準則永遠不會被使用，無論是什麼內容都應該根據內容來移動到新名稱，若是破壞也可用現存的G3等刪除。--Xiplus#Talk 2021年2月3日 (三) 13:59 (UTC)[回复]

至少這也能成為移動操作的依據。快速刪除方針的應用有時並不限於快速刪除本身。SAN MO SA _SPQR 2021年2月17日 (三) 15:06 (UTC)[回复]

「快速刪除方針的應用有時並不限於快速刪除本身」如無異議將在適當的時間進行公示。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月7日 (三) 06:24 (UTC)[回复]
公示7日-- 五歲抬頭雪菲（☎️·☘️） 2021年4月14日 (三) 03:34 (UTC)[回复]

Module:Template:Delete/data模組的對應修改見User:Sanmosa/O8模組。SAN MO SA _Σουέζ 2021年4月17日 (六) 04:32 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

將LTA空間設定為noindex

認為LTA空間應設定為noindex 避免搜尋引擎索引。具體的作法可建立專用於標記偽名字空間的模板，在模板內用{{Namespace_detect}}判斷是否為LTA空間，加入noindex 魔術字。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月3日 (三) 13:43 (UTC)[回复]

條目空間中無法使用noindex魔術字。--Xiplus#Talk 2021年2月3日 (三) 13:54 (UTC)[回复]

@Xiplus：意思說部分維護模板的設定是設定辛酸的？！-- Sunny00217 2021年2月3日 (三) 14:54 (UTC)[回复]

@羊羊32521、YFdyh000：看來LTA還是需要升格為獨立的名字空間，才不會被其他名字空間的設定檔左右。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月3日 (三) 18:57 (UTC)[回复]

開新討論吧。--LuciferianThomas．留言 2021年2月3日 (三) 22:29 (UTC)[回复]

連過去的是WP，可以將該頁NOINDEX吧，那麼相關捷徑就會有同樣效果？--臺灣杉在此發言 (會客室) 2021年2月4日 (四) 08:39 (UTC)[回复]

其實Google搜尋似乎沒看到這些頁面，或許重定向本來就被忽略？--LuciferianThomas．留言 2021年2月5日 (五) 01:52 (UTC)[回复]

Bing找得到但直接顯示目標頁面內容。--LuciferianThomas．留言 2021年2月5日 (五) 01:55 (UTC)[回复]

所以还需要noindex吗 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年2月18日 (四) 03:02 (UTC)[回复]

需要是獨立的名字空間才能設定noindex—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月18日 (四) 10:12 (UTC)[回复]

@羊羊32521：我認為如果可以設定的話會更佳，但可能命名空間化會比較方便。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年3月3日 (三) 05:20 (UTC)[回复]

那我周末再提一下 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月3日 (三) 15:00 (UTC)[回复]

(？)疑問：改这个是否可行？--安忆 ^Talk 2021年3月3日 (三) 15:13 (UTC)[回复]

仍支持命名空間案，我只是覺得提升命名空間案一直被人以奇怪的理由關掉很可惜。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年3月3日 (三) 15:21 (UTC)[回复]

那就搬新段重開吧，抱歉太亂了。--LuciferianThomas．留言 2021年3月6日 (六) 06:51 (UTC)[回复]

也沒有亂吧，個段落應該分開檢視吧，怎麼會不能放在兩個結束之議案的中間呢？-- 五歲抬頭雪菲（☎️·☘️） 2021年3月10日 (三) 06:00 (UTC)[回复]

从语法看可以。--YF dyh000（留言） 2021年3月3日 (三) 15:22 (UTC)[回复]

以往phab有修改此部分的先例嗎?-- 五歲抬頭雪菲（☎️·☘️） 2021年3月17日 (三) 06:42 (UTC)[回复]

如果沒有的話，我認為很難實行。-- 五歲抬頭雪菲（☎️·☘️） 2021年3月31日 (三) 06:51 (UTC)[回复]

實測上Google應沒有對重新導向進行索引（例如搜尋"LTA:蘇俞安"找不到該重新導向或是目標頁面），所以我們應沒必要再對其標記NOINDEX。--Xiplus#Talk 2021年3月31日 (三) 08:55 (UTC)[回复]

Google搜尋重新導向時會顯示目標頁的內容，即會有一行「（重新導向自）」，請見[4]，但是不影響偽命名空間。--空氣小貓（留言） 2021年4月5日 (一) 07:29 (UTC)[回复]

google:detache出现了一个到https://en.wikipedia.org/?title=Detach%C3%A9&redirect=no的搜索结果。 ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月11日 (日) 14:31 (UTC)[回复]

這個不像是主動收錄的網址，而且有設定canonical，理應不會收錄這個重定向。--Xiplus#Talk 2021年4月14日 (三) 05:32 (UTC)[回复]

本提案已經另開。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月28日 (三) 04:17 (UTC)[回复]

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

WP:捷徑指引草案修訂

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:捷徑、Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间（錯誤：Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间是重定向頁面）。

[編輯此導航模板] 設立新命名空間及偽命名空間無共識：2018年12月的先前討論全案結以待續：第一輪討論 - 開放偽命名空間作捷徑連結用結以待續：設立LTA、MOS、PJ三個偽命名空間結以待續：升格維基專題為命名空間結以待續：修正命名空間資訊頁面結以待續：將「Wikipedia:捷徑」訂為方針完結：第二輪討論完成部署：設立專題命名空間相關討論及任務已通過：討論升格維基專題為命名空間任務完成：向Phabricator申請部署維基專題命名空間已合併：在Gerrit提交所需修正編碼任務完成：在Phabricator請求合併編碼完成：事實性修訂「Wikipedia:命名空間」以包含新的維基專題命名空間完成，待檢查：將專案命名空間下的維基專題移動至維基專題命名空間專題移動列表專題重定向移動列表已完成：修正指向專題的內部連結機器人任務已完成：調整專題模板已通過：討論捷徑的設立方式已通過：其他議題討論完結：設立偽命名空間相關討論已通過：討論設立LTA及MOS偽命名空間供捷徑使用已否決：設立捷徑空間供LTA/MOS捷徑使用已否決：設立捷徑空間作其他用途結以待續：升格LTA為命名空間完結：後續討論處理事項完成：修改機械人操作不提刪偽命名空間捷徑無結論：格式手冊新捷徑名稱討論 MOS捷徑列表已否決：舊捷徑改為軟重定向完成：設置預設啟用小工具已否決：自動半保護偽命名空間條目已通過：提議設立新快速刪除標準完結：第三輪討論已否決：捷徑命名空間已完成：捷徑指引草案修訂已通過：增設更多偽命名空間（一）已通過但未實行：第三次推动设立LTA命名空间

說明

捷徑指引草案的討論，源自於「偽命名空間」的討論，英語維基百科對於捷徑相關的規範及偽命名空間的設立已有成熟的執行方式。中文維基百科中的部分編輯者對於「格式手冊」、「長期破壞者」及「專題」這三個主題提出可升級成命名空間或以偽命名空間形式存在，並有正反兩方的陳述與看法。

目前較為接近共識的是「專題」提升為正式命名空間，反對者的論述已由支持者回應，且反方無進一步論述。然為求慎重，且將捷徑與命名空間等議題作系統性討論，將會執行階段修訂，以取得最大共識。

本討論的各階段分為：

~~專題提升為命名空間與否及其細節~~（phab:T271612）；
~~格式手冊及長期破壞者是否成為命名空間或偽命名空間~~；
~~偽命名空間規範寫入捷徑規範內（如前項通過）或是否允許偽命名空間（如前項不通過）~~；
捷徑規範細部討論並決定是否成為指引。

各階段不得同時討論，前一項討論完結之後，才能進行下一段討論。臺灣杉在此發言 (會客室) 2020年12月10日 (四) 05:47 (UTC)[回复]

專題命名空間通過，剩餘細節獨立討論。臺灣杉在此發言 (會客室) 2021年1月11日 (一) 11:20 (UTC)[回复]

偽命名空間和專題空間都設立了。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年3月3日 (三) 05:21 (UTC)[回复]

說明剩下的第四點，有部分項目正在等待專題、格式手冊、LTA等命名空間的相關議題之討論或公示。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月21日 (三) 02:51 (UTC)[回复]

專題命名空間問題

本主題全部或部分段落文字，已轉移至Wikipedia:互助客栈/方针#專題命名空間。执行人：臺灣杉在此發言 (會客室)。標記人：_{_{來人啊，餵宮子吃布丁！}} ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月14日 (四) 06:44 (UTC)。[回复]

格式手冊及長期破壞者命名空間問題

本主題全部或部分段落文字，已轉移至Wikipedia:互助客栈/方针#偽命名空間。执行人：臺灣杉在此發言 (會客室)。標記人：_{_{來人啊，餵宮子吃布丁！}} ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年3月24日 (三) 05:54 (UTC)。[回复]

已通過：

已通過，並完成主要設定。-- 五歲抬頭雪菲（☎️·☘️） 2021年3月24日 (三) 05:55 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

已移動至偽命名空間。臺灣杉在此發言 (會客室) 2021年2月1日 (一) 03:47 (UTC)[回复]

完成技術的部分已完成大部分的設定，剩下制度完善的部分。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月25日 (四) 05:48 (UTC)[回复]
- 如有技術問題，請回報至討論對應章節。-- 五歲抬頭雪菲（☎️·☘️） 2021年3月10日 (三) 05:58 (UTC)[回复]

完成：設定完畢，有問題請在此提出。-- 五歲抬頭雪菲（☎️·☘️） 2021年3月24日 (三) 05:55 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

捷徑細部修訂

本案進入倒數第二個部分，捷徑細節修訂。目前偽命名空間部分已成為指引，其餘部分仍須修訂。

在上次討論當中，有提及中文捷徑等相關問題，歡迎進一步討論。臺灣杉在此發言 (會客室) 2021年1月31日 (日) 07:42 (UTC)[回复]

我對捷徑不是很熟，但#快捷方式的命名真的是中維社群慣例嗎（ ——羊羊 (留言|贡献|古典音乐专题) 2021年2月5日 (五) 12:08 (UTC)[回复]
- ……我好像一不小心把“不鼓勵不按”看成了“不鼓勵按” 囧rz…… 眼瞎不好意思，當我沒說 ——羊羊 (留言|贡献|古典音乐专题) 2021年2月5日 (五) 12:13 (UTC)[回复]
  慣例還有簡單中文簡稱以及其他，所以才要修正相關內容，歡迎提出修改方案。--臺灣杉在此發言 (會客室) 2021年2月11日 (四) 07:41 (UTC)[回复]
  目前還有多少未完善之處？—- 五歲抬頭雪菲（☎️·☘️） 2021年4月7日 (三) 06:14 (UTC)[回复]

首段建議附加維基專題空間，他們會稍後設立捷徑。--LuciferianThomas．留言 2021年2月6日 (六) 04:03 (UTC)[回复]

(：)回應Wikipedia:互助客栈/方针#第五階段：討論重新導向與捷徑的設立方式討論已開始。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月14日 (日) 09:51 (UTC)[回复]

@Taiwania Justo？--LuciferianThomas．留言 2021年2月21日 (日) 00:13 (UTC)[回复]

目前在忙著RFC以及其他現實生活事務，且目前還有殘餘議案等待處理，待完全告一段落後再行整理該案。--臺灣杉在此發言 (會客室) 2021年2月21日 (日) 03:46 (UTC)[回复]

不急，因為#第五階段：討論重新導向與捷徑的設立方式也還在討論。-- 五歲抬頭雪菲（☎️·☘️） 2021年3月17日 (三) 06:43 (UTC)[回复]

上述第五階段將會在適當的時機公示。-- 五歲抬頭雪菲（☎️·☘️） 2021年3月31日 (三) 06:50 (UTC)[回复]

上述第五階段已開始公示。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月14日 (三) 03:45 (UTC)[回复]

公示擱置中討論中。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月28日 (三) 04:19 (UTC)[回复]

有關某年代相關分類命名統一事宜

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:分类名称。

最近Jarodalien對某年代相關分類進行了大規模的重新命名工作（將“XXXX年代”重新命名為“YY世紀YY年代”、將“建立”重新命名為“創立”），並聲稱其理由為“先到先得”，然而“先到先得”並不適用於非條目頁面。我曾就部分分類的擬議重新命名（移動請求）進行反對，然而被其無視，其不但無視反對意見照樣進行移動操作，更反過來誣指我取消重新命名的操作為“破壞”，更牽連到其他本與相關移動請求不相關的分類。在其進行大規模的重新命名工作後，我收到部分用戶反映其重新命名工作導致部分由模板自動產生的分類出錯，可見其大規模的重新命名工作輕率且窒礙模板維護，構成破壞。請管理員盡快回退其移動操作，並以一切可行的辦法阻止其繼續進行相關破壞性移動。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 10:54 (UTC)[回复]

@AT。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 10:54 (UTC)[回复]

@Iokseng。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 10:56 (UTC)[回复]

我建議通報至管理員佈告版。--A T 2021年2月25日 (四) 10:58 (UTC)[回复]

@AT：WP:AIV提報過了，但當時我未收到部分用戶對於其重新命名工作導致部分由模板自動產生的分類出錯的反映。我覺得至少也得把他做的移動操作全數回退，這比較急。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 11:00 (UTC)[回复]

@Jarodalien：請參與討論，不然我會考慮禁制您編輯分類空間。謝謝。--A T 2021年2月25日 (四) 11:15 (UTC)[回复]

正在回退一部分他移動過的分類，但數量有點多，我移不完。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 12:16 (UTC)[回复]

？什么意思？是说只允许别的用户把本来是叫“XX世纪XX年代”的分类移动成“XXXX年代”，不允许反过来吗？就像Category:1910年代美国罪案本来是20世纪10年代美国罪案等等。既然先到先得不适用分类，那么为什么不能够移动？为什么“埃及定居地‎”不对只能移动到“埃及聚居地”，“非洲各国定居点‎”不行要移动到繁体的“非洲各國聚居地‎”？--7（留言） 2021年2月25日 (四) 12:48 (UTC)[回复]

你還記得你上次不允許將「获奖名单」、「获奖列表」等分類移動到「获奖与提名列表」嗎？你都會說沒事不要移動了，現在突然搞這些是有事嗎？ --無心*插柳*柳橙汁 2021年2月25日 (四) 13:01 (UTC)[回复]

注意翻历史纪录，不只是我的纪录。我一向的主张是先到先得，是楼主说分类不先到先得。以此为由把Category:20世纪10年代美国罪案移动到Category:1910年代美国罪案。我也想确认是不是真的“分类不先到先得”，我个人是觉得很不可思议，因为这就意味着什么谁都明白。--7（留言） 2021年2月25日 (四) 13:13 (UTC)[回复]

命名常規只規範條目、不規範分類，自然不適用「先到先得」，不要把你自己當成方針。分類的命名看的是更宏觀的其他東西。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 15:42 (UTC)[回复]

不允许反过来吗。前后极其相似或许先到先得（因为没必要改、WP:OWN），改变命名方式已经不只是先到先得的范畴了。--YF dyh000（留言） 2021年2月25日 (四) 16:04 (UTC)[回复]

根据民智，19世纪50年代可能会被误认为是1950年代，这类移动没有必要。不过有些词，比如建立出版物，成立音乐团体，创建教育机构，不说合不合适，至少是不是可以讨论讨论拿个统一的方案。->>Vocal&Guitar->>_留言 2021年2月25日 (四) 13:11 (UTC)[回复]

如果有人觉得“19世纪50年代”是“1950年代”，这个人一定不懂汉语。懂汉语的人不需要考虑不懂汉语的人会有什么误解。--7（留言） 2021年2月25日 (四) 13:13 (UTC)[回复]

我有印象先前有類似的討論，當時的意見好像是“1950年代”這樣的表述比較省，不過我沒記得是哪年在哪的討論。既然音樂條目都開了命名討論，關於是否統一年代表示，再開一個討論又不會怎麼樣。 --無心*插柳*柳橙汁 2021年2月25日 (四) 14:48 (UTC)[回复]

這個討論是Wikipedia:命名常规/有关“20世纪80年代”的写法的问题。 紺野夢人 ^恭賀新春 2021年2月25日 (四) 16:25 (UTC)[回复]

我不同意「這個人一定不懂漢語」的論斷，一時看得較快看錯了所導致的誤認是非常正常的事情。就此例而言，這是前述情況最為經典的例子。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 15:42 (UTC)[回复]

这是认知不广泛的“常识”（就像公元1年到公元前1年之间有几年，不一定有过半数人答对），有更清楚且简洁表达的情况下不应该改成更模糊、更容易出错的。--YF dyh000（留言） 2021年2月25日 (四) 16:00 (UTC)[回复]

@YFdyh000：所以說答案是空集，還是元素為“0年”的單元素集合？⋯⋯--洛普利宁 2021年2月26日 (五) 15:46 (UTC)[回复]

这不重要吧……我指看似常识的东西很多人并不清楚，如有没有公元0年，世纪怎么算，年代又怎么算。相比可能模糊但容易猜对的xxxx年代，双重模糊的xx世纪xx年代更难判断。--YF dyh000（留言） 2021年2月26日 (五) 16:01 (UTC)[回复]

@Jarodalien：無論如何，你進行的重新命名工作導致部分由模板自動產生的分類出錯這一點是無庸置疑的，我認為你應該將先前所建立和重新命名的分類（包括但不限於某年代相關分類，我認為其他相關分類很可能也有同樣情形）全部統一回模板自動產生的格式，否則這無庸置疑會嚴重影響模板維護工作。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 15:42 (UTC)[回复]

為免後患，我建議就各類頁面（包括但不限於分類頁）引入「命名一致性」的規定，以有效減少頁面命名上的紛爭，並便利維護。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 15:56 (UTC)[回复]

支持這個提議，而且可以把「年代分類」當作首要討論對象，未來可以擴及其他分類原則。我支持“1950年代”這個寫法，理由如下：

此次討論顯示“19世纪50年代”這個用法確實容易導致誤判。
“1950年代”寫法較為簡潔。
分類與主條目名稱統一對讀者來說最為便利，按照年代列表目前所有年代主條目都是採取“1950年代”這個寫法。
User:Sanmosa在上方已提及的分類維護問題。--迴廊彼端（留言） 2021年3月6日 (六) 03:10 (UTC)[回复]

“19世纪50年代”不是相等於“1950年代”嗎。--Temp3600（留言） 2021年2月26日 (五) 13:29 (UTC)[回复]

認真？“19世纪50年代”相等於“1850年代”，“20世纪50年代”才相等於“1950年代”。-游蛇脫殼/克勞棣 2021年2月26日 (五) 14:16 (UTC)[回复]

@Temp3600：想一下2000年是几世纪，称多少年代。以及Category:2000年代怎么整。--YF dyh000（留言） 2021年2月26日 (五) 14:20 (UTC)[回复]

似乎2000年是20世紀90年代（1991至2000年）的最後一年，以及2000年代（2000至2009年）的第一年⋯⋯像1世紀是1至100年，21世紀是2001年至2100年；而X世紀00年代是這個世紀的第一個十年。所以21世紀00年代是2001年至2010年，和2000年代嚴格來說還不是一個東西？PS：「21世紀00年代」和「21世紀10年代」怎麼讀？「二十一世紀零十年代」「二十一世紀一十年代」？--洛普利宁 2021年2月26日 (五) 15:10 (UTC)[回复]

这，尴尬了，我记成21世纪了

捂脸--YF dyh000（留言） 2021年2月26日 (五) 15:24 (UTC)[回复]

读作零零年代、一零年代，就像九零后、零零后。--YF dyh000（留言） 2021年2月26日 (五) 16:01 (UTC)[回复]

①“20世纪50年代”=“1950年代”=“1950年到1959年”，這應該比較沒有爭議；②但如您所舉例，遇到100的倍數就麻煩了；③「20世纪50年代」、「21世紀00年代」、「21世紀10年代」我會分別讀「二十世紀五零年代」、「二十一世紀零零年代」、「二十一世紀一零年代」，至於別人怎麼讀，我就不知道了。-游蛇脫殼/克勞棣 2021年2月26日 (五) 16:15 (UTC)[回复]

00和10以外的年代，我大概会读作“__十年代”，读法上没问题。--YF dyh000（留言） 2021年2月26日 (五) 21:01 (UTC)[回复]

@@YFdyh000：說到年代的是，請教大家一個問題，最近我都不太用維基百科了，今天我在找資料時發現有條目裡面原有年代的部分被刪除了，查了查是有編輯者刪除了，可能他認為那是考古專家學者考據的年代，不是當時人寫下的年代，譬如，古埃及第三xxx王朝約西元前xxx年-西元前xxx年，所以編輯者把年代刪除在內容改成不知道，現在可以這樣嗎？><?我怕搞不清楚狀況所以問問。--User:浪子魚|愛偷懶的魚🐠※User talk:浪子魚|留言 2021年2月26日 (五) 16:43 (UTC) ──以上未簽名的留言由浪子魚（討論｜貢獻）加入。

@浪子魚：不太清楚您的意思，是条目内容还是分类，年代与条目主题的关系。麻烦您将签名加上内部链接，不然别人不方便查阅和回复，您的ping也不会生效。--YF dyh000（留言） 2021年2月26日 (五) 21:01 (UTC)[回复]

@YFdyh000：好，謝謝你告訴我浪子魚（留言） 2021年3月9日 (二) 07:12 (UTC)[回复]

針對性決議

通過：

通過。SAN MO SA _Σουέζ 2021年3月29日 (一) 09:11 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

我這裏的建議是：為便利分類維護，並避免由模板自動產生的分類出錯，當將所有以“YY世紀YY年代”格式命名的分類重新命名為“XXXX年代”格式、將所有以“創立”格式命名的分類重新命名為“建立”格式。頁面命名一致性的通用（普遍性）條文會稍後草擬，針對性的決議應該先通過。SAN MO SA _{江南好，風景舊曾諳} 2021年3月15日 (一) 08:18 (UTC)[回复]

現公示以下針對性決議7日：將所有以「YY世紀YY年代」格式命名的分類重新命名為「XXXX年代」格式、將所有以「創立」格式命名的分類重新命名為「建立」格式。SAN MO SA _{江南好，風景舊曾諳} 2021年3月22日 (一) 10:15 (UTC)[回复]

(＋)贊成--YF dyh000（留言） 2021年3月22日 (一) 11:06 (UTC)[回复]

前者同意，以便於維護，減少因格式之混雜不一所造成的分類維護困難；但後者則建議以既有母分類（諸如「各年建立的OOO」等，後續子分類一併以「建立的OOO」為原則）的命名格式為主，倘若尚無母分類者建議以「建立」為主要命名格式。--Steven |_-｡) 2021年3月23日 (二) 14:52 (UTC)[回复]

兩者皆贊成，理由如下：

XXXX年代部分－

以上討論顯示“19世纪50年代”這個用法容易誤判。
“1950年代”寫法較為簡潔。
分類與主條目名稱統一對讀者來說最為便利，按照年代列表目前所有年代主條目都是採取“1950年代”這個寫法。
User:Sanmosa在上方已提及的分類維護問題

建立部分－

以「創立」為名的分類數量明顯少於以「建立」為名的分類。--迴廊彼端（留言） 2021年3月23日 (二) 15:15 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

@YFdyh000、StevenK234、迴廊彼端：決議已通過。名為「創立」的分類已經全部處理。以“YY世紀YY年代”格式命名的分類太多，未能全部重新命名，暫時只處理了「19世紀00年代」、「19世紀10年代」、「21世紀10年代」、「21世紀20年代」和整個18世紀，其他可能需要請求bot，或靠各位的幫助自行移動，我會嘗試移動一部分。移動理由應使用「Special:diff/64972159決議通過統一命名格式」。SAN MO SA _Σουέζ 2021年3月29日 (一) 09:28 (UTC)[回复]

頁面命名一致性的通用（普遍性）條文

暫時不太想得到該怎樣寫。我可能要再看一看英文維基百科的對應規定，7日內應該能夠寫好。各位如果有其他的草案提議，也可以直接提。SAN MO SA _Σουέζ 2021年3月29日 (一) 11:35 (UTC)[回复]

引入一致性之后，一致性和常用（同主条目一致=主条目命名时的常用）会有冲突的问题。 --达师 - 370 - 608 2021年4月13日 (二) 16:37 (UTC)[回复]
如果是說條目的話，確然，因此若確立命名一致性規定，可能需要就個別條目的命名再進行討論，但實際操作上通常會依照主條目常用名作命名一致性處理，因此發生衝突的機會可能沒想像中大。如果是說條目以外的頁面的話（我會將對條目以外的頁面的規定分開處理，不放入命名常規），則未必。SAN MO SA _Σουέζ 2021年4月14日 (三) 13:14 (UTC)[回复]

暫時有這個條文草稿：

就條目命名（寫入Wikipedia:命名常规#技术要求或Wikipedia:命名常规#命名原则，寫入位置的不同會影響規則強度）：

“

快捷方式

命名一致性

條目（包括列表條目，下同）的命名的格式（包括但不限於用詞）應與其他同類條目的命名的格式一致^{[註 1]}。部分專題已經設置適用於該專題的子命名常規，並已在其中包含對該類條目的命名的格式的規範。其他條目的命名的格式由社群討論商定，並應立為子命名常規，否則應在《條目命名一致性決議》頁面予以記載。

”

就分類頁面命名（寫入Wikipedia:分类名称#通则）：

“

命名一致性

分類頁面的命名的格式（包括但不限於用詞）應與其他同類分類頁面的命名的格式一致^{[註 1]}。分類頁面的命名的格式由社群討論商定，並在《分類頁面命名一致性決議》頁面予以記載。

”

就其他非條目頁面命名（另開頁面）：

“

命名一致性

非條目頁面的命名的格式（包括但不限於用詞）應與其他同類非條目頁面的命名的格式一致^{[註 1]}。方針及指引頁面的命名的格式由《方針及指引》頁面的相關條文指定，而分類頁面的命名的格式則由《分類名稱》頁面的相關條文指定，至於其他非條目頁面的命名的格式則由社群討論商定，並在《其他非條目頁面命名一致性決議》頁面予以記載。

”

^ ^1.0 ^1.1 ^1.2 使用地區詞處理至一致也算作一致。

以上。@hat600、Milkypine、YFdyh000。SAN MO SA _Σουέζ 2021年4月19日 (一) 06:24 (UTC)[回复]

支持讓子命名常規處理該類條目的命名的格式的規範。 --Loving You Is A Losing Game 2021年4月20日 (二) 07:05 (UTC)[回复]

其實技術上不可能反對，因為已經有子命名常規這樣做了。SAN MO SA _Σουέζ 2021年4月21日 (三) 08:59 (UTC)[回复]

公示上案7日。就條目命名的部分寫入Wikipedia:命名常规#技术要求，就其他非條目頁面命名的部分寫入Wikipedia:非條目頁面命名；三部分均作方針。SAN MO SA _Σουέζ 2021年4月30日 (五) 06:08 (UTC)[回复]

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

關於Wikipedia:命名常规 (音乐)

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:命名常规 (音乐)。

延續上次Wikipedia talk:命名常规#關於Wikipedia:命名常规#使用外文命名时的专门要求，請問音樂作品名稱是否能算是專有名詞？的討論，我寫了一篇Wikipedia:命名常规 (音乐)

希望各位可以給點意見，協助改善該命名常规。 --無心*插柳*柳橙汁 2021年3月15日 (一) 06:12 (UTC)[回复]

提示：阁下该次ping操作没有一个人会收到，因为您一次性同时ping了超过五十人。--Milky·Defer 2021年3月14日 (日) 20:08 (UTC)[回复]

@MilkyDefer：(´_ゝ`)你沒提，我都忘了我人數超標了。 --無心*插柳*柳橙汁 2021年3月15日 (一) 06:13 (UTC)[回复]

我有ping到人嗎？ --無心*插柳*柳橙汁 2021年3月15日 (一) 14:05 (UTC)[回复]

有ping到。請簡單歸納一下你覺得討論者需要注意的重點。謝謝。－hiJK910 ^七一_七二一 2021年3月15日 (一) 14:10 (UTC)[回复]

@Hijk910：注意的重點嘛...，當屬於上次關於外文問題所寫的「外文規範」，另外我也把上次羊羊32521大的古典音樂內容放入其中。而括號的使用和消歧義，想說藉由這次討論一起解決。 --無心*插柳*柳橙汁 2021年3月15日 (一) 15:11 (UTC)[回复]

有。我被ping了兩次。—— Eric Liu_{創造は生命（留言．留名．學生會）} 2021年3月15日 (一) 14:14 (UTC)[回复]

(！)意見：1. 「夠格」一詞不夠正式。2. 關於「「『(歌曲)』：適用於所有歌曲，通常命名時優先使用」，請問是不是指像炎 (歌曲)這些「(歌曲)」跟「(單曲)」皆可的條目，「必須」還是「建議」以「(歌曲)」為消歧義呢？－hiJK910 ^七一_七二一 2021年3月15日 (一) 14:18 (UTC)[回复]

~~我這個人最沒有主見了~~，關於「(單曲)」，我上次被百战天虫大說服後[5]，覺得很有道理。當然，如果是像ARRIVAL OF EVERGLOW這種單曲專輯使用「(單曲)」，我就覺得還行。

但就目前而言，都是歌曲不用「(歌曲)」而使用「(單曲)」到底是為什麼？我這邊問一下@Ryokie38：，當初建立½ (川本真琴單曲)使用單曲而不像1/2 (川本真琴の曲)（日语：1/2 (川本真琴の曲)）使用歌曲的原因是什麼？。 --無心*插柳*柳橙汁 2021年3月15日 (一) 14:46 (UTC)[回复]

被Tag兩次啦(茶)，基本上名稱方面沒有多大問題。順帶一提，自己也比較傾向於用「(人名歌曲)」或「(人名單曲輯)」或「(人名專輯)」三種來命名．．．好奇其他人的看法。-by 全速前進～～Yosoro！！～～的Tsuna Lu（留言） 2021年3月15日 (一) 16:07 (UTC)[回复]

@Adsa562：我贊同人名的部分，直接使用人名可以避免以後移動的麻煩是好事，但如果是像胡薩維克 (歌曲)這種冷門的名稱或是像妮裳馬戲團 (歌曲)專門到極點的，不用加人名也沒問題。 --無心*插柳*柳橙汁 2021年3月15日 (一) 16:27 (UTC)[回复]

要跟en:Wikipedia:Naming conventions (music)連結吧，然後可以順便參考一下，像關於單曲/歌曲的問題，我覺得宜與英維一樣「儘量避免使用單曲」（If possible, avoid using other terms like "(single)", "(cassette)" or "(CD single)", etc.）--Austin Zhang（留言） 2021年3月15日 (一) 19:53 (UTC)[回复]

对于单首发行的歌曲，消歧义时用歌曲没有问题，但是当单曲发行时有附带B面歌曲且该条目也有介绍该B面歌曲（而不是顺带提及）的时候，用单曲消歧义更合适吧。--无所事事/想要狗带 2021年3月16日 (二) 19:05 (UTC)[回复]

@Softyu：我也有這麼想過，但鑑定不容易。我在下面列出幾個，你覺得哪些可以保留其單曲消歧义。 --無心*插柳*柳橙汁 2021年3月17日 (三) 15:49 (UTC)[回复]

个人观点来说，保留单曲的程度是2＜5=3<1=4，4有不止一首B面曲得到有效介绍，1则是在制作及商业成绩方面皆有充分介绍B面曲，3的介绍相比1单薄，但也算有效，5是仅有一句话的顺带提及，2则是完全没有来源，不过实际操作中，可以考虑对包含B面曲的或所有歌手自身称之为单曲（single）的条目以单曲消歧义，毕竟无论如何也要“名从主人”。

我這邊再給幾個增加樣本數，世界的盡頭 (單曲)、Yellow (木村KAELA單曲)、FACE (NU'EST單曲)、MAGIC (SHOW單曲)、崖上的波妞 (單曲)、Reflection (林原惠單曲)、口唇 (GLAY單曲)、髮夾 (單曲)。“名从主人”方面你說名稱那還有道理，但消歧义也如此就...（也不是不行啦，這在命名常规寫仔細一點）。 --無心*插柳*柳橙汁 2021年3月17日 (三) 23:56 (UTC)[回复]

主要是有D (BIGBANG单曲)、H (滨崎步单曲)这种无法以“歌曲”消歧义的条目存在，导致其他单曲类型条目如果以“歌曲”消歧义的话会产生问题，如果把Moments (濱崎步單曲)改成Moments (濱崎步歌曲)肯定会产生争议的吧。--无所事事/想要狗带 2021年3月18日 (四) 06:29 (UTC)[回复]

D (BIGBANG单曲)、H (滨崎步单曲)這兩個使用單曲沒有問題（就像我前面提到的ARRIVAL OF EVERGLOW）。我引用星巴克女王大的說法來講就是「單曲是偏向介紹某張CD，而歌曲是偏向介紹某首歌曲，而我們寫的主要與歌曲內容有關，而不是介紹某張單曲CD。」 --無心*插柳*柳橙汁 2021年3月19日 (五) 01:19 (UTC)[回复]

为什么“我們寫的主要與歌曲內容有關，而不是介紹某張單曲CD”？？我从来的看法是介绍某张单曲，及其中收录的歌曲。->>Vocal&Guitar->>_留言 2021年3月25日 (四) 07:42 (UTC)[回复]

单曲与歌曲是明显不同的概念，只要以单曲形式发行的作品，不论是一首歌几首歌，都应称为单曲。对于某些特殊的歌曲，比如我和你 (歌曲)之类，其制作背景不是以发行单曲为目的，或没有发行单曲，此时才合适用歌曲。->>Vocal&Guitar->>_留言 2021年3月25日 (四) 07:42 (UTC)[回复]

@Ohtashinichiro：當條目只是一首歌的時候，討論其格式根本沒有意義，你只會介紹一首歌，也只有這麼一首歌可以介紹，這種情況下沒有迫切需要「 (單曲)」做消歧义。再來討論「篩選條件」，我反對以「制作背景不是以发行单曲为目的」及「没有发行单曲」作優先處理。首先「制作背景不是以发行单曲为目的」要怎麼辨別，Say So一開始沒打算打單、Eyes on Me以遊戲主題曲為目的創作，但這兩首最後都打單了。唱片公司的舉動是否屬於制作背景以发行单曲为目的？

二來，現在這年頭，你沒有發行公司也能自己發歌。以Spotify為例，只要你加入Spotify的創作計畫，哪怕你沒有公司也能發歌。但單曲是Spotify的最低計量單位，創作者上傳的作品是否等於发行单曲？（例如PewDiePi的歌曲Congratulations (PewDiePie、Roomie和Boyinaband歌曲)）。　--無心*插柳*柳橙汁 2021年3月25日 (四) 11:51 (UTC)[回复]

如果您只介绍歌曲的背景、词曲、意涵、影响，我觉得您使用歌曲没有问题。但您也会介绍这首歌作为单曲发行的信息比如日期地区形式唱片公司，以及作为单曲发行后的反应比如销量评价奖项，这些都属于单曲而不是歌曲的范围。至于您的举例都是完完全全的商业作品，商业作品当然都是以发行为目的且结果也都是已发行，我前面的表述可能会引起您的误解，也希望您可以研究一下您的举例和《我和你 (歌曲)》的区别在哪，能有一个合适的表述。另外spotify好像已经结束了自行发歌[6]。->>Vocal&Guitar->>_留言 2021年3月26日 (五) 00:19 (UTC)[回复]

@Ohtashinichiro：spotify结束自行发歌不等於整個計畫沒有發生過，對於以前參與計畫的歌該算？而Ohtashinichiro大你給出的這些條件，歌曲一樣可以使用，《家 (陳潔儀歌曲)》難道有出單曲他就活該倒楣只能是商业作品。我不能理解你一直提《我和你 (歌曲)》是想表達什麼，他們都是歌曲。不論有沒有出單曲、派台還是其他單曲形式，歌曲就是該用歌曲，沒有必要過度分類。 --無心*插柳*柳橙汁 2021年3月26日 (五) 04:20 (UTC)[回复]

单曲是“一碗饭”，歌曲是“碗里的饭”，您可能只想吃饭，我希望不要忽略这只碗。只是看起来您对这一点并不认同，那其他的讨论也没有意义了。->>Vocal&Guitar->>_留言 2021年3月26日 (五) 05:01 (UTC)[回复]

很抱歉，我不能理解只在乎容器，而忽視它終究是飯的事實。關於單曲與歌曲的問題就看其他維基人的意思，再來評斷。 --無心*插柳*柳橙汁 2021年3月26日 (五) 05:44 (UTC)[回复]

"上次討論"的連結失效了。--Temp3600（留言） 2021年3月17日 (三) 17:55 (UTC)[回复]

"上次討論"的連結以補充。 --無心*插柳*柳橙汁 2021年3月17日 (三) 23:56 (UTC)[回复]

Wikipedia:命名常规 (音乐)1.0更新報告

感謝大家的意見回饋，自3/14以來，本指引更新下列內容，歡迎大家查閱。 --無心*插柳*柳橙汁 2021年3月25日 (四) 05:33 (UTC)[回复]

「古典音樂作品」敘述修正
「使用中文」內容增加
「外文規範」內容增加
「括號的使用」修改為「符號使用」，並增加「斜線」、「書名號」和「特殊符號」的說明與範例。
「消歧義」內容增加
「注釋」敘述修正

由於人數眾多，這邊分開ping相關討論用戶。 --無心*插柳*柳橙汁 2021年3月25日 (四) 05:42 (UTC)[回复]

我本来就对“古典音乐作品”第一行“对序号是10（不含）以上的作品，‘号’字省略”有点疑虑，这样分类讨论，不利于条目名的统一性。^[1]希望能交付社群讨论。另ping一下之前参与过相关讨论的@Foamposite、Iokseng、Anakharsis： ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月25日 (四) 06:05 (UTC)[回复]
我認為日文羅馬化可能需要詳細規定，例如shi或si到底要使用何者，《日語羅馬字》中有寫到三種羅馬化方式，看是要採用哪一種。空氣小貓（留言） 2021年3月25日 (四) 10:24 (UTC)[回复]
我建議如果官方沒有給出羅馬字的話，全部統一用平文式羅馬字。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 10:27 (UTC)[回复]
我也是這樣認為。空氣小貓（留言） 2021年3月25日 (四) 10:48 (UTC)[回复]
@Pseudo Classes、Sanmosa：以新增。 --無心*插柳*柳橙汁 2021年3月25日 (四) 11:05 (UTC)[回复]

@Milkypine：「對序號是10（不含）以上的作品，『號』字省略」是此類音樂作品的常用名稱的做法嗎？SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 09:57 (UTC)[回复]

@Sanmosa：古典音樂的部分主要根據User:Anakharsis/沙盒#建立条目編寫，至於是否為此類音樂作品的常用名稱做法...這部分需要古典音樂的編輯來回答（技術上來講我會寫原聲帶但不等於我熟悉古典音樂）。 --無心*插柳*柳橙汁 2021年3月26日 (五) 12:41 (UTC)[回复]

@Milkypine：我看了一下應該是對現行做法的總結。然而，我也看過了來源一下，似乎即使號碼大過10，加「號」字還是比較常見。我建議基於常用名稱的原則，將『序號使用阿拉伯數字，前面有「第」字；作曲家名字放在半角括號內，括號之前有一個半角空格。對序號是10（不含）以上的作品，「號」字省略』的規則改為『序號使用阿拉伯數字，前面有「第」字，後面有「號」字；作曲家名字放在半角括號內，括號之前有一個半角空格』。SAN MO SA _{江南好，風景舊曾諳} 2021年3月27日 (六) 05:28 (UTC)[回复]

有關「號」的問題，綜觀慣常一般音樂會場刊的處理，通常都沒有特意加上「號」的，但本人自最初編寫蕭士達高維契交響曲時，經觀察和有前人提醒過名稱上要加上「號」，所以才不論第1還是第15都有加上「號」，且也覺得沒有問題，至於「超過10就不用加號」的說法，倒沒有聽過，不過User:Sanmosa建議不論序號，統一採用「第X號○○○ (某某)」的寫法，個人表示認同和支持。-Foamposite（留言） 2021年3月27日 (六) 07:40 (UTC)[回复]

@Iokseng、Anakharsis：兩位的看法如何？ --無心*插柳*柳橙汁 2021年3月28日 (日) 03:29 (UTC)[回复]

我不知道现在还可不可以为这个讨论作出贡献。我主要编辑古典音乐这方面，所以以下是我对于该方面的浅见：

1）我注意到大家关于“号”的讨论，我赞成“第”后面加“号”，不需要去管超过10什么的。我注意到很多的条目中超过10的也使用“号”，如：第11号钢琴奏鸣曲 (莫札特)、第12号交响曲 (肖斯塔科维奇)与第40号交响曲 (莫扎特)等。我不太懂为啥非要减少一个“号”。

2）哦，对了，維基百科:命名常規 (音樂)这里的降E大調弦樂五重奏（貝多芬作品）的括号好像用成了中文的（）而非()，我觉得咱们可以着重的说一下我们的括号问题用的是英文的那种，我认为新手会喜欢犯这样的错误（比如我，哈哈哈哈）

3）关于调性的问题，我认为我们还应当注意对于音名和字母大小写的统一，如我们真的要写“降E大調弦樂五重奏 (贝多芬)”，我们需要着重指出到底是用“降E”还是“E♭ ”；亦或是“降e”还是“降E”。探讨这个问题很重要，因为在很多命名下面的条目内容出现不一致的情况，比如第3號交響曲 (貝多芬)中我们说“E♭大調第3號交響曲”，但是在第39號交響曲 (莫扎特)中，我们又说降E大調第39號交響曲。我的建议是我们应当使用“大写字母”以及“降”或“升”。

4）关于維基百科:命名常規 (音樂)这个地方的“如果該作品的名稱是獨一無二的，則作曲家名字也可以省略”，这个可能会有点争议，比如其中说到的大地之歌，这玩意儿可能指的是大地之歌 (电影)。我不是在这里杠呀，我是说类似这样的东西需要注意是否已经有不一样的体裁同样名字的东西已在维基百科中出现，比如查拉圖斯特拉如是說、库勒沃，咱们需要加上查拉圖斯特拉如是說 (史特勞斯)或库勒沃 (西贝柳斯)；乃至于有些时候同属于音乐类的《传奇》，是西贝柳斯？还是维尼亚夫斯基？当然，我认为这个可以直接套用“作品在體裁內的序號＋作品體裁＋作...”的方式，只是需要稍加说明。我的建议是说明如果维基百科里已经有不同体裁但相同名字的条目则在新条目建立时的括号内加上作曲家名字，如果没有就无所谓了（自己看着办吧）。

5）注意到我们在古典音乐类编辑中有惯例但无有实质的关于“命名优先性”的规定（或者因为我是个新手没有注意到，哈~），我以我指的“优先性”举一个例子，我们是应该叫第6号交响曲 (柴可夫斯基)还是悲怆交响曲。我知道大家都很聪明，而且我个人感觉我们的惯例通常是用体裁加序號再加作曲家的方式，但是我认为需要在維基百科:命名常規 (音樂)对命名的优先性中做具体的说明，要不然！！！就会像某度那样出现憨憨的“悲怆交响曲”和“柴可夫斯基第六交响曲”那样的重复词条，我笑死了哈哈哈哈哈。

以上这些都是我的浅见，不知道能不能帮到大家~ --李新阳（留言） 2021年3月28日 (日) 06:29 (UTC)[回复]

暫時先回應第5項，要知道很多標題音樂，都不是作曲家原先加上的，因此除非如佛漢·威廉士那種開宗明義講過不喜歡使用作品序號的，就應該予以尊重，不然的話，應採用「第5號交響曲 (貝多芬)」而非採用「命運交響曲」，「第1號交響曲 (馬勒)」而非「巨人／泰坦交響曲」，頂多是使用重定向處理暱稱。--Foamposite（留言） 2021年4月2日 (五) 12:32 (UTC)[回复]

再回應第3項，正如我早前所講，如果是標題，那應使用「升C」、「降E」，因這不會涉及使用音樂符號模板的問題；至於內文中，如果是對應標題的，我會建議沿用「升C」、「降E」的寫法，但當牽涉到配器中的移調樂器（最常見，B♭單簧管），或者表示音樂中的音高時，個人就會覺得應該使用 {{music/xxx}} 的方式去表達。

至於第4點，我立時想到了早陣為拉赫曼尼諾夫的《死之島》開了條目，很明顯原來的畫作的名氣比起樂曲更大時，實在無法引用「獨一無二」的方式來處理，而音樂作品往往都是因其他著作、畫作而獲得靈感，這個概念無疑是限制了古典音樂作品能突破「獨一無二」的框架，除非好像《古雷之歌》，荀伯克選用了雅各生在世時未能完世的詩集內的作品，最終使音樂比原著更為人熟識，這樣的異例實在不多。

第1點早已表述，至於第2點也不過是技術錯失，修正一下便好了。--Foamposite（留言） 2021年4月2日 (五) 23:04 (UTC)[回复]

我赞同你的说明，特别是对于第5项的说明。我认为完全可以纳入到命名的规则之中。感谢~-李新阳（留言） 2021年4月3日 (六) 19:06 (UTC)[回复]

我原先倒是想一律不用号字。我在大陆，我看到的来源（包括中央音乐学院的本科招生简章、校外考级教材，中国音乐家协会的考级教材，人民音乐出版社和花城出版社的初高中课本）只要是数字+体裁的，都没有号字。但是数字用的是汉字。难道这得按地区词处理？ ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月28日 (日) 14:55 (UTC)[回复]

(～)補充：在花城出版社《音乐鉴赏》（2004.8第一版）第115页下方对莫扎特的介绍中出现了阿拉伯数字的写法：“《g小调第40交响曲》《第41交响曲》（朱比特）” ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月28日 (日) 15:51 (UTC)[回复]

我理解羊羊说到的这个现象，不同地区对于曲目的命名确实存在差异。如中国爱乐乐团的曲目设置中，我们称“《古斯塔夫·马勒：第七交响曲》”，^[2]而在国立台湾交响乐团的曲目设置中，我们称“《馬勒：D大調第一號交響曲》”。^[3]当然这并不意味着大陆就一定不使用“号”，或台湾地区就一定使用“号”，比如国家大剧院就称呼“《贝多芬 C小调第五号交响曲，Op.67》”或^[4]在“实践中”，维基百科古典音乐条目的命名中我们普遍使用“号”这个东西。虽然我个人觉得“号”不“号”的无可厚非，但我认为我们应当在维基百科中有一个统一的有共识的对于“号”的规定，我可能不会建议在这样的事情上按地区词处理，可能显得没有必要。(＆)建議：我个人支持在命名时保留“号”这个东西，因为这似乎已经成了维基百科“没有特别规定的共识和实践”，且考虑到这个实践已经存在很长时间了，符合大家的写作习惯。我支持应当采用汉字表示具体的数字，如一、二等，而非使用阿拉伯数字。因为这个是对于大陆和台湾地区而言都通用的。--李新阳（留言） 2021年3月28日 (日) 18:35 (UTC)[回复]

可也。不过我还是建议阿拉伯数字——第一百零三号交响曲 (海顿)实在难看-- ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月29日 (一) 05:18 (UTC)[回复]

而且可能得设重定向 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月29日 (一) 05:22 (UTC)[回复]

思来也是，而且也考虑到现在维基百科的大多数条目都是用阿拉伯数字的惯例的话。羊羊举得这个例子很好，一百零三号交响曲，哈哈哈哈哈哈；那么使用阿拉伯数字可以应付汉字所不能应付的情况，我认为可。感谢~--李新阳（留言） 2021年4月3日 (六) 19:14 (UTC)[回复]

对于李新阳其它几点内容：

见上。
“（贝多芬作品）”不在条目名称里，这个括号只是解释说明作用，没什么关系^[5]。但是个人觉得这一条有点问题，可能有不止一个作曲家的降E大调弦乐五重奏序号不详、有争议或无可靠来源使用，建议改成：调性优先，若无须消歧义，作曲家名字可以省略。
调性的问题。我认为应该用汉字“升”和“降”。至于字母大小写，我觉得争议出在小调上。英维古典音乐专题的Guidelines有说，大意是D小调可以简写为d调，但不能写d小调这种缝合怪。^[6]然而我能看到的来源，（作品名还有行文）D小调和d小调都有，甚至感觉d小调更多。我觉得还是按中文习惯，大调大写，小调小写。
建议改成：如果该作品的名称是独一无二的，且无须消歧义，则作曲家名字也可以省略。
我觉得应该不是问题，第一条解决的就是通用情况。

以上。 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月29日 (一) 06:02 (UTC)[回复]

感谢羊羊对于关于大小调的叙述，我支持进行“大调大写，小调小写”的方式，合乎乐理，然后使用汉语表示升降号，以及新增关于“且无须消歧义”的条文。--李新阳（留言） 2021年3月29日 (一) 08:11 (UTC)[回复]

我自己反而是沒看過「小調小寫」的處理。SAN MO SA _Σουέζ 2021年3月29日 (一) 09:01 (UTC)[回复]

那這樣D小調不就需要...。 --Loving You Is A Losing Game 2021年3月29日 (一) 13:55 (UTC)[回复]

严格意义上来说，在乐理的学习和考试中以及大多数的实践中，都应当使用“大调大写，小调小写”的原则，这样合乎规范也严谨一些。您提到的D小調是一个很好的且应该进行改正的例子。--李新阳（留言） 2021年3月30日 (二) 05:36 (UTC)[回复]

我理解现在的许多音乐会，新闻或者乐评不强求或者不讲究这个，因为往往来说观众都更在意“大调”还是“小调”而非“大写”还是“小写”这样的“技术性问题”。我个人认为为了避免歧义，应当遵循“大调大写，小调小写”的原则。--李新阳（留言） 2021年3月30日 (二) 05:43 (UTC)[回复]

同意，我在音樂系學習時，按西方慣常命名時，大調用大寫，小調用小寫是不成名做法，這個和樂理和聲學有關，當然用在普及化的層面來說，大小寫的意義不大，對此我覺得在維基內可以因着便利性而不執行大小寫的做法，至於「降號」和「升號」，由於真正的寫法和「#」及「b」有別，涉及要用音樂符號模版，我傾向都是用文字表述為佳。--Foamposite（留言） 2021年4月2日 (五) 12:32 (UTC)[回复]

(！)意見：命名中几乎遇不到小调大小写的情况，不属于命名常规讨论范畴，建议拆分为新讨论。 ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年3月31日 (三) 06:08 (UTC)[回复]

进行拆分的话倒是没有任何问题，我主要是看到了“降E大調弦樂五重奏”这个玩意儿，认为应当讨论一下大小写的问题。我现在发现了一个新东西，就是这个夜曲Op. 9 (蕭邦)以及前奏曲Op.28, No. 15 (蕭邦)，我们可能需要引入一个新的话题，即Op和No的问题。我建议翻译出来比较好，要不然看这很别扭。--李新阳（留言） 2021年3月31日 (三) 06:59 (UTC)[回复]

夜曲 (肖邦第9号作品)？前奏曲 (肖邦第28号作品第15首)？太难看了……我觉得这些小问题还是不要讨论了吧，讨论是讨论不完的……你看看英维的音乐命名常规，古典音乐写了多长…… ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月1日 (四) 05:13 (UTC)[回复]

补了个签名 ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月1日 (四) 15:26 (UTC)[回复]

好吧，为尽快了结，可以搞一个独立的拆分讨论大小调的问题。对于[[夜曲Op. 9 (蕭邦)]这种东西现在就暂时不做处理（吗）？（我倒是无所谓，我比较随意）。--李新阳（留言） 2021年4月3日 (六) 18:58 (UTC)[回复]

「命名中几乎遇不到小调大小写的情况」，我不清楚古典音樂們有多少，但對於小調，我想這部分可以一起處理，尤其是Template:Circle of fifths。~~不過這麼一搞，條目裡面有出現小調我可能都要修改了OTZ~~ --Loving You Is A Losing Game 2021年3月31日 (三) 14:28 (UTC)[回复]

辛苦啦~--李新阳（留言） 2021年4月3日 (六) 19:00 (UTC)[回复]

Wikipedia:命名常规 (音乐)2.0更新報告

感謝大家的意見回饋，這次根據上次1.0的討論修改古典音樂，並增加「 (單曲專輯)」的消歧義。歡迎大家查閱。 --Loving You Is A Losing Game 2021年4月10日 (六) 07:04 (UTC)[回复]

由於人數眾多，這邊分開ping相關討論用戶。 --Loving You Is A Losing Game 2021年4月10日 (六) 07:06 (UTC)[回复]

括號一節舉的例子不是有全形字元（中文字）嗎？如果我沒理解錯誤的話，不應該是要用全形括號？空氣小貓（留言） 2021年4月10日 (六) 07:20 (UTC)[回复]

@Pseudo Classes：你的意思是說「中文是全形字元」嗎？如果不是的話，習慣 (超快感)和姊姊妳太美了 (Replay)這兩個例子都沒有全形字。 --Loving You Is A Losing Game 2021年4月10日 (六) 07:26 (UTC)[回复]

@Milkypine：是的，中文字理應也屬於全形字元，這樣寫會有歧義。空氣小貓（留言） 2021年4月10日 (六) 07:31 (UTC)[回复]

斜線一節也有這個問題。--空氣小貓（留言） 2021年4月10日 (六) 07:34 (UTC)[回复]

@Pseudo Classes：已修改為「全形符號」避免歧義。 --Loving You Is A Losing Game 2021年4月10日 (六) 08:01 (UTC)[回复]

@Milkypine：感謝修正，另外我想請問關於斜線和括號有相關的共識嗎？不然我想再針對這個問題討論一次。空氣小貓（留言） 2021年4月10日 (六) 15:18 (UTC)[回复]

@Pseudo Classes：姑且算吧，就算當初沒有共識，現在也可以有，我就不信我ping了快百位編輯沒人沒感覺。 --Loving You Is A Losing Game

@Milkypine：了解，看了一下討論，這個作為共識應該沒問題。空氣小貓（留言） 2021年4月12日 (一) 02:42 (UTC)[回复]

已查閱，感謝貢獻。--SickManWP_{歡迎參與♥️邊緣人小組的活動·✏簽到}發表於 2021年4月10日 (六) 08:25 (UTC)[回复]

作出了一笔事实性编辑，另“大调大写，小调小写”的例子不妥（D大调、d小调），毕竟页面第一个字必须大写，建议改成

條目名稱須符合「大調大寫，小調小寫」，如“D大調”、“d小調”。

或是

條目名稱須符合「大調大寫，小調小寫」，如“D大調”、“d小調”。
例：降B大調、升f小調

以上。 ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月10日 (六) 15:33 (UTC)[回复]

@羊羊32521：页面第一个字雖然必须大写，但d小調和iPhone一樣，都在其（樂理）領域屬於特定詞語，因此使用小血沒有問題。 --Loving You Is A Losing Game 2021年4月10日 (六) 16:50 (UTC)[回复]

好 ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月11日 (日) 02:26 (UTC)[回复]

Wikipedia:命名常规 (音乐)公示

感謝大家的意見，現將Wikipedia:命名常规 (音乐)公示。 --Loving You Is A Losing Game 2021年4月20日 (二) 07:36 (UTC)[回复]

由於人數眾多，這邊分開ping相關討論用戶。 --Loving You Is A Losing Game 2021年4月20日 (二) 07:39 (UTC)[回复]

(？)疑問@Milkypine：看完整體草案，有疑惑的是「對於官方沒有給出羅馬化名稱的日文作品，根據平文式羅馬字羅馬化。」這條，特別指的是日本作品，那麼韓國作品有必要依照馬科恩-賴肖爾表記法將韓文轉換成羅馬字？若有的話，以「보라빛 밤」為例，是要以羅馬字呈現的英文「Pporappippam」為條目名稱，還是按照過去以編者翻譯先到先得、名從主人所相輔相成的WP:NAME規範，維持「紫光夜」的條目名稱？--🍫巧克力～✿ 2021年4月20日 (二) 07:46 (UTC)[回复]
- @卡達：方針有寫到「命名音樂條目時，優先使用最為通用的中文名稱命名。」，所以一定可以被命名為「紫光夜」。如果沒有中文名稱，則是對其外文依序進行處理（例如가시나因為有官方名稱所以使用「Gashina」）。基本上日韓語歌如果沒有英文歌名，一定都會有個中文名稱（例如24小時也不夠），這項提議也是針對「稀有狀況」做處理 --Loving You Is A Losing Game 2021年4月20日 (二) 10:04 (UTC)[回复]

(？)疑問「對於官方沒有給出羅馬化名稱的日文作品，根據平文式羅馬字羅馬化」是不是代表「リスク」這樣的詞語如果沒有官方羅馬化名稱，就要寫成「risuku」？還有，建議在這一條裏不要用《不適任者》這首使用中文作為條目標題的歌作為例子。--【和平至上】💬 2021年4月23日 (五) 14:36 (UTC)[回复]

@和平至上：如果我有更好的例子我早就改了ˊ_>ˋ，我的歌單就46和宇多田光，剩下的動漫歌也有一堆常用中文，會用到這條的你該問樓上那些人。

常理來講「リスク」是「risk」，不會有人故意寫成「risuku」（麥當勞寫成馬哭都納魯兜的畫面太美我不敢想）。這條既然有歧異我做了修飾，請參考。 --Loving You Is A Losing Game 2021年4月24日 (六) 12:47 (UTC)[回复]

現在這樣沒有問題了（雖說平文式羅馬字好像沒有提到外來語的處理方法）。--【和平至上】💬 2021年4月24日 (六) 13:04 (UTC)[回复]

這邊使用「羅馬化」這種曖昧的詞也是為了處理這類問題，不過加上羅馬拼音方式倒是又造成沒有料想到的問題。 -Loving You Is A Losing Game 2021年4月24日 (六) 15:57 (UTC)[回复]

古典音乐“作品在体裁内的序号＋作品体裁＋作曲家名字。序号使用「阿拉伯数字」，前面有「第」字；作曲家名字放在半角括号内，括号之前有一个半角空格”规定与已有方针维基百科:命名常规矛盾。维基百科:命名常规要求使用常用名称。例如（柴科夫斯基的）第一钢琴协奏曲、（贝多芬的、德沃夏克的）第九交响曲等相对于第1号钢琴协奏曲、第9号交响曲是通常使用的名称，可以通过搜索引擎验证。这一草案与命名常规相抵触，却又声称“本方針為Wikipedia:命名常规的補充，而非替代”。--如沐西风（留言） 2021年4月24日 (六) 16:22 (UTC)[回复]
- @如沐西风：ˊ_>ˋ這方面還請你和上面擅長古典音樂的大大們溝通。話說就算維基以常用優先，還會有很多要求，例如這一切的開端「使用小寫」，那常用名稱要求按照常用格式也不是什麼太大問題，（話說使用繁體搜尋，結果是相反過來，所以這方面究竟誰比較常用，可能還要看實體書籍等其他方面來參考）。 --Loving You Is A Losing Game 2021年4月25日 (日) 12:35 (UTC)[回复]
那句话已经删了（ -- ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月29日 (四) 15:54 (UTC)[回复]

@如沐西风：說實話，這段敘述“本方針為Wikipedia:命名常规的補充，而非替代”和上述內容有衝突嗎？大家都知道要按照常用，但命名常规自己本身也有對常用的規定（例如小寫、縮寫等）。而閣下提到的例子在這邊我也得出相反結果，那麼該以何者為基準？如果案例很明顯，我絕對贊成「第九交响曲」，但當不同名稱都有一定程度的使用比例，那麼就需要方針去處理，總不能把異己打死吧。 --Loving You Is A Losing Game 2021年4月29日 (四) 16:04 (UTC)[回复]
- 新订规则不应该与已有规则相冲突，不然将来执行的时候肯定有问题。比如“第九交响曲”和“第9號交響曲”，维基百科:命名常规和Wikipedia:命名常规 (音乐)（假如通过）给出了不同的规定，听哪个？新修规则应该明确一个大方向，要么细化已有规定，要么为已有规定做补充；如果觉得现有规定不对，那么就去修维基百科:命名常规。不要搞出矛盾来。留不留那句“本方針為Wikipedia:命名常规的補充，而非替代”，新设方针都不该和已有方针冲突，不然总得有一个变成废纸。
- 即便退一步讲，就算“第9號交響曲”是港台地区的惯用名称，“第九交响曲”是大陆的惯用名称，维基百科:命名常规已经做出了规定：维基百科:命名常规#中文用詞差異的處理：先到先得“應维持條目第一個重要版本所采用的標題（须符合本方針其他命名规则）”。这种情况下条目叫什么，不该Wikipedia:命名常规 (音乐)说了算。不看维基百科:命名常规，强行要求古典音乐必须以某一命名方式为准（不管是港台的命名还是大陆的命名），这才是不按方针处理，“把異己打死”。--如沐西风（留言） 2021年4月29日 (四) 16:17 (UTC)[回复]

「新订规则不应该与已有规则相冲突」並非，前提是刪去“本方針為Wikipedia:命名常规的補充，而非替代”一句。子命名常規的適用優先性高於母命名常規，情況如同關注度指引。SAN MO SA _Σουέζ 2021年4月30日 (五) 05:31 (UTC)[回复]

参考資料

^ 英维古典音乐专题的Guidelines提到，An article's title should be selected to best represent what readers of Wikipedia expect. This means, among other things, that titles should be consistent for each genre. For example, a reader who has already successfully found Mozart's 40th symphony under Symphony No. 40 (Mozart) will expect that Haydn's 103rd symphony should be found under Symphony No. 103 (Haydn).
^ 纪念古斯塔夫·马勒逝世110周年系列音乐会之二. [2021-03-28].
^ 【海神家族與馬勒巨人】簡文彬與國臺交將以音樂帶您感受作曲家與文學家筆下的深刻情感. [2021-03-28].
^ 贝多芬的第五号交响曲.
^ 理论上在正文出现的括号应该用全角，哈哈
^ Some reference works use a space-saving system where the words "major" and "minor" are omitted; a key in upper case refers to a major key, and one in lower case is a minor key. For example, "D" would mean D major, and "d" would mean D minor. Some editors confuse matters by adopting a part of this system but still spelling out the words "major" or "minor" – thus, "D major" vs. "d minor". This is inconsistent and is to be avoided. ——en:Wikipedia:WikiProject_Classical_music/Guidelines

（重提）Wikipedia:共识#提案討論及公示時間的執行力度

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

最近客棧的提案實在是不勝Wikipedia:共识#提案討論及公示時間的困擾，但不太想盡廢，因此提一個修正案：

現行條文

為了確保所有使用者有充足的時間發表意見以及得悉改動，如果在互助客栈中被提出的提案在七天內沒有新留言或至少討論達一個月以上的情況下，只要取得共識便可公示，為期七天。公示期間若无异议，则提案算作通过；如果有新意見，請通過協商解決問題。存檔後如果要重新提出公示的話，應同時補回相關討論連結，以便社群查閱。

提議條文

為確保所有使用者有充足的時間發表意見及得悉改動，在互助客栈中被提出的提案若在7日內無新留言^[1]，又或討論已持續28日以上的情況下，只要討論取得共識，即可公示，公示為期至少7日。公示期間若無合理異議，作通過論，若有新合理意見，應經協商解決問題。

参考資料

^ 不對提案進行實則性點評的支持意見，以及與提案本身無關的意見，皆不視作此條文所指的「新留言」。

以上。SAN MO SA _{江南好，風景舊曾諳} 2021年3月14日 (日) 15:31 (UTC)[回复]

主要影響：

不對提案進行實則性點評的支持意見不造成重算7日。
與提案本身無關的意見不造成重算7日。
將浮動的時間範圍「1個月」界定為固定的時間範圍「28日」。
容許公示在有必要時可長於7日。

以上。SAN MO SA _{江南好，風景舊曾諳} 2021年3月14日 (日) 15:36 (UTC)[回复]

(？)疑問：

原條文有「如果在互助客栈中被提出的提案」一句，在新條文要刪去嗎?
參閱Wikipedia:互助客栈/条目探讨#春晚及春晚 (消歧義)，這種在Wikipedia:互助客栈/条目探讨的提案是否需要遵守WP:7DAYS?或是要將WP:7DAYS限定在Wikipedia:互助客栈/方针?--CaryCheng（留言） 2021年3月15日 (一) 02:41 (UTC)[回复]

@CaryCheng：（1）漏留意，已補回。（2）理論上要遵從。SAN MO SA _{江南好，風景舊曾諳} 2021年3月15日 (一) 05:53 (UTC)[回复]

@CaryCheng：就（2）作補充：我是説如果決定要進行公示的話，理論上要遵從WP:7DAYS，但是如果不涉及修改方針指引或修改高風險模板的話，一般性的爭議解決討論好像是不用進行公示的，基本上爭議解決了就可以直接關。SAN MO SA _{江南好，風景舊曾諳} 2021年3月15日 (一) 08:45 (UTC)[回复]

(？)疑問:這個提案改過很多次，而且30天和28天就差兩天，有必要改來改去嗎？而且一年就只有二月會有28天，大家都會以30天為一個月的概念，這種修改有甚麼意義呢？--蟲蟲飛♡♡→♡℃※留言 2021年3月15日 (一) 03:52 (UTC)[回复]

1年有7個月是31日，何來「以30天為一個月的概念」？再者，1年12個月的日數不同，假設我在2月1日提案，我最遲可以在28日後公示，但假設我在3月1日提案，我最遲在31日後才能公示（4月同理，最遲在30日後才能公示），這對於在有30日／31日的月份提案的人非常不公平，但如果統一為30日，這會損害在2月提案者的公平性，因為30日的時間必定比2月長，這樣在2月提案的人就會要在多於一個月的時間後才能公示。因此，最公平的方式為統一成28日。SAN MO SA _{江南好，風景舊曾諳} 2021年3月15日 (一) 05:53 (UTC)[回复]

(？)疑問:大致同意，而且也會看到這裡用雪球快速公示，好像也沒完全照規定走。但是這裡有些疑問要問一下，如何界定「已取得共識」、「合理異議」，「合理意見」？合理異議、意見會不會變成兩集團互斥對方不合理。只有一人提問，無人贊成、反對，算不算已取得共識，然後可以公示?這些提案人可以一併考慮，把規定寫更好一些。--2001:B042:1:A9ED:F58C:12D4:4C7B:B776（留言） 2021年3月15日 (一) 06:32 (UTC)[回复]

（1）沒人抓的話其實是沒人會遵守這規定。（2）以前的人進行公示的時候都是説“現公示7日，無合理異議者即作通過”，跟以前的做法處理。（3）提案與現行辦法對於“只有一人提問，無人贊成、反對”的提案的態度是原則上可以公示，這當然會產生一些奇怪的現象（當然如果提案人能夠好好處理提問的話，我倒是覺得可以照樣公示通過），先前討論也談論過，但沒人管。SAN MO SA _{江南好，風景舊曾諳} 2021年3月15日 (一) 07:54 (UTC)[回复]

回答的很完整。不縮小「無新留言」範圍，結果時間等太久，沒人抓大家就不走規定。不討論「已達成共識」定義，結果「一人提問，無人贊成、反對」，反而7日後就可以公示。這是不見得會有問題，但又有一些奇特的現象。--2001:B042:1:ABD5:F58C:12D4:4C7B:B776（留言） 2021年3月15日 (一) 08:27 (UTC)[回复]

所以有時候我會抓一下7日的計算（雖然我自己也不滿現在這規定）。如果“只有一人提問，無人贊成、反對”的提案出現的話，提案人能不能夠好好處理提問是一個重點，如果不能的話，理論上可以抓「已取得共識」一條來說有程序性問題。SAN MO SA _{江南好，風景舊曾諳} 2021年3月15日 (一) 08:42 (UTC)[回复]

(－)反对:重看了一下，註腳很有問題，而且只會增加爭議，應刪去。--蟲蟲飛♡♡→♡℃※留言 2021年3月15日 (一) 06:41 (UTC)[回复]

不同意。這是修訂提案的主要目的之一。之前的討論的主流意見都認同不應該使所有意見都能導致重算7日（我個人比較看重的是DrizzleD的意見）。我邀請一下之前參與過討論的@KirkLU、DrizzleD、BureibuNeko、UjuiUjuMandan、Fire-and-Ice來好了。SAN MO SA _{江南好，風景舊曾諳} 2021年3月15日 (一) 07:49 (UTC)[回复]

不是说增加争议就不好。举个简单例子，根据中华人民共和国刑法，故意杀人的，处死刑、无期徒刑或者十年以上有期徒刑；情节较轻的，处三年以上十年以下有期徒刑，显然在不少案件中具体判罚轻重会有“争议”，但为什么不干脆故意杀人的都处死刑呢？因为不同的案件真的不一样，不能统一判罚。这里类似，单纯支持也好，给建议也好，反对也好，无关意见也好，对共识形成的作用完全不同，却都能导致重算7日，这就背离了WP:7DAYS帮助确认共识的初衷。--DrizzleD _{(按此给我留言)} 2021年3月15日 (一) 09:41 (UTC)[回复]

(＋)支持：这四点都没什么问题。关于第一点，先前討論中已有不少论据，不再赘述（但愿）。简而言之，在没有其他意见的情况下，支持的人越多，提案越晚被公示，这是说不通的。--DrizzleD _{(按此给我留言)} 2021年3月15日 (一) 09:46 (UTC)[回复]

(？)異議:您誤解了WP:7DAYS的初衷，當時AT就是為了解決在討論不足的情況下，用戶火速公示，然後強行通過提案的問題。原先是要30天後才公示，後來才七天後沒有留言公示。七天算是合理時間，沒必要再縮短，否則又會回到以前火速公示，強行通過提案的問題，然後爭議不斷，問題多多。而且現在WP:7DAYS未見有甚麼問題，沒必要再放寛。--蟲蟲飛♡♡→♡℃※留言 2021年3月15日 (一) 13:12 (UTC)[回复]

不不不，是您误解了我的意思，我说它帮助确认共识，意思是它告诉我们什么时候算是确认了共识，不是说它帮助加速通过提案。然后：1. 七天算是合理时间，没必要再缩短，我同意，但这个修正案完全没说要缩短七天这个时间，此说法和此修正案

不相关。2. 又会回到以前火速公示，强行通过提案的问题，当然不，留言支持者越多，说明通过提案越不强行，而不是相反。 3. 而且现在WP:7DAYS未见有什么问题，这个我现在不太活跃确实不太清楚，但Sanmosa似乎能够确认如此，@Sanmosa可以来说说。--DrizzleD _{(按此给我留言)} 2021年3月15日 (一) 13:47 (UTC)[回复]

（3）現成的問題。SAN MO SA _{江南好，風景舊曾諳} 2021年3月16日 (二) 05:53 (UTC)[回复]

(※)注意:請看一下這個提案，有一大堆支持，也已經討論了一個月，還是有人反對，當時也有人催快點公示，也有朋友對說我要快公示，怕夜長夢多，會出現(－)反对，但提案的目的是要尋求共識，而不是快快通過，然後出現爭議，因此急於通過是不必要的，有共識的提案也不怕多放幾天。--蟲蟲飛♡♡→♡℃※留言 2021年3月16日 (二) 06:13 (UTC)[回复]

你對互助客棧討論的想法完全違背進行互助客棧討論應有的健康心態。SAN MO SA _{江南好，風景舊曾諳} 2021年3月16日 (二) 06:58 (UTC)[回复]

@蟲蟲飛：不吸烟也可能患肺癌，这不代表我们不用去倡导戒烟，关键是可能性。类似地，同样是暂时没有反对意见，一个有许多人支持的提案和一个没人理的提案，哪一个有潜在问题的可能性更大？这是不言自明的。

要解决所谓“已经讨论了一个月，还是有人反对”的问题，相关的方案是延长WP:7DAYS中7天或者是1个月的限制（当然可能会有一些别的问题），但这与本案无关。本案的要求是赞成或不相关的意见不影响时间（不管是7天还是什么其他时间）的重算。--DrizzleD _{(按此给我留言)} 2021年3月17日 (三) 02:13 (UTC)[回复]

提案討論就不應存在不相關的意見，而且有時甚麼如何定義「不相關」也有爭議，因此我覺得AT現行版本較佳，沒必要改為一個具爭議性的版本。--蟲蟲飛♡♡→♡℃※留言 2021年3月17日 (三) 02:40 (UTC)[回复]

然而方針指引不能阻止任何用戶發表不相關的意見。SAN MO SA _{江南好，風景舊曾諳} 2021年3月17日 (三) 05:43 (UTC)[回复]

如何定義「不相關」？誰去決定？雙方也可以互相指責對方的留言「不相關」，為甚麼要令提案增加不必要的爭議？AT現行版本是最好的，「七天沒留言」是客觀標準，沒有爭議空間。--蟲蟲飛♡♡→♡℃※留言 2021年3月17日 (三) 12:12 (UTC)[回复]

（1）依據「共識應當考慮到所有正當合理的意見」此條方針來定義。（2）最極端的情況就找行政員，天仍然不會因此塌下來。（3）極端嚴格的「7天沒留言」是客觀標準沒錯，然而違反常識、慣性、正常討論生態和「共識應當考慮到所有正當合理的意見」此條方針。SAN MO SA _{江南好，風景舊曾諳} 2021年3月17日 (三) 12:43 (UTC)[回复]

所以，這種提案還是，被改完的7days攔下吧？-- Sunny00217 2021年3月22日 (一) 16:25 (UTC)[回复]

从现存留言上来看，应该会，因为相邻两条有说理的评论之间均小于7天。当然，改了WP:7Days之后同时可能会促使反对的人更早留言，这就是另一回事了。--DrizzleD _{(按此给我留言)} 2021年3月28日 (日) 06:27 (UTC)[回复]

@Sunny00217。SAN MO SA _{江南好，風景舊曾諳} 2021年3月16日 (二) 05:56 (UTC)[回复]

(－)反对:啥叫合理，啥叫不合理？誰有權判定？個中操作空間太大，不得不反對。芄蘭（留言） 2021年3月15日 (一) 13:22 (UTC)[回复]

啥叫曾在可靠来源中发表过的重要观点，啥叫不重要？谁有权判定？

啥叫恰当地改进或维护维基百科，啥叫不恰当？谁有权判定？

我们能收录可靠来源中的所有观点吗？我们能废除WP:5P5去墨守成规吗？不能。这种操作空间不是洪水猛兽，它是必要的，也是维基百科时时刻刻都在使用的东西。

当然，要是操作规范能写得更细、更准确，那更好，就像WP:WEIGHT较详细叙述了第一个问题。可假设还没人去写WP:WEIGHT的时候，我们订立原则的时候同样应该加上“重要”两个字，因为这就是应该的，而不是去害怕什么“操作空间”。--DrizzleD _{(按此给我留言)} 2021年3月15日 (一) 14:14 (UTC)[回复]

提案人有邀请讨论，我稍微简单说一下自己的浅见：

类似于“最后一天有编辑补了个‘支持’，结果导致要重新计算公示前的无留言时间”的情况客观存在；
个人是支持上例的这种问题能够更灵活化的处理（毕竟，表达一下支持，甚或——更宽泛一点——由于方针通过、问题解决的喜悦在讨论串下面开了个适当的玩笑，都不是什么不合理的事情；让这种表达起到延长公示前时间的效果，并非方针的本意，也一定程度上压抑了这种合理表达的机会——毕竟既然赞成提案，谁也不希望自己表达的支持反而造成了拖延的反效果）；
我能理解反对此种灵活化处理的编辑有种种疑虑，此种情况下不改变现有方针我觉得也是可以理解、认同；
但即使方针不变，只要翻看存档，就会发现此种灵活化处理在往例中比比皆是，在这些案例中大家某种程度上用一种“默示共识（或称沉默共识，或称通过不提出异议来支持）”的方式使得灵活化缩短时程得以实现；
也因此，如3，方针改不改在我看来也许真的问题不大（如果大家真的不期待太明确地以规则确认上述惯例，或至少有些编辑还对此存在很大疑虑，如3，我个人觉得也是能一定程度理解），只是希望即使不改方针，至少这种实践中自然而然的习惯不被刻意地挑战，只要大家觉得适当的情况，就可以稍微灵活一点。事实上，我觉得这也最大程度体现出维基的精神。

以上。--Kirk★ # 2021年3月15日 (一) 17:02 (UTC)[回复]

您是忽略了修訂版本中爭議性的問題，因為如何定義「不相關」有時也有很大爭議，否則之後提案又出現是否合法公示的問題，以前已經出現過很多次公示爭議，不應加一個具爭議性的註腳。我覺得AT現行版較佳，沒有修改的必要。--蟲蟲飛♡♡→♡℃※留言 2021年3月17日 (三) 02:45 (UTC)[回复]

不如此修訂的話，會對互助客棧的討論生態造成嚴重扭曲。SAN MO SA _{江南好，風景舊曾諳} 2021年3月17日 (三) 05:43 (UTC)[回复]

「討論被扭曲」是您說的，不是事實。客棧的提案不是為了收集支持，而是看看有沒有(－)反对，因為提案如果沒有反對，公示後就可以通過，因此公示的過程就是要令提案收集更多的意見，而這七天已經是下限，沒必要再縮減。--蟲蟲飛♡♡→♡℃※留言 2021年3月17日 (三) 12:08 (UTC)[回复]

DrizzleD的1和2已經駁斥了你上面聲稱的東西（這個修正案完全沒說要縮短七天這個時間；留言支持者越多，說明通過提案越不強行，而不是相反）。SAN MO SA _{江南好，風景舊曾諳} 2021年3月17日 (三) 12:14 (UTC)[回复]

那也要看回應的理據是否成立，不是回應了就算。我在上面還沒看到有任何理據是成立。--蟲蟲飛♡♡→♡℃※留言 2021年3月17日 (三) 12:21 (UTC)[回复]

我真誠相信這是因為你中文理解能力有問題的緣故。換作任何其他一個人，他們都必定能夠理解提案的原因，並認為其合理。SAN MO SA _{江南好，風景舊曾諳} 2021年3月17日 (三) 12:43 (UTC)[回复]

您請保持禮儀及文明﹗也請不要訴諸人身﹗--蟲蟲飛♡♡→♡℃※留言 2021年3月17日 (三) 12:51 (UTC)[回复]

没有对“不修改”、“現行版較佳”的观点表示反对。核心是认为可以没有明示规定但要尊重实操中的默契。（比如，规则上尽可以挑战Wikipedia:互助客栈/方针/存档/2021年3月#修订R3适用情形五的公示[毕竟严格意义上他远没有7天]，但缺乏意义，只会把程序性修订也拖得冗长。于我个人而言，如果有挑战，我一定会尊重这种挑战，因为方针如此，效果也不过是拖到下个月再公示。但缺乏意义。）--Kirk★ # 2021年3月17日 (三) 13:36 (UTC)[回复]

不肯定您記得不記得，之前就試過有提案因為公示沒有嚴格依從7days去進行，結果即使提案通過了多天，仍然引發了社羣對提案的有效性的質疑。請注意方針修訂是要面對整個社羣，而不是幾個討論的人同意就可以繞過方針。而且方針指引的有效性不是一時的，可以在幾年後，十幾年後，用戶翻閱存檔時，也可以再次質疑提案的有效性。此外，如果提案是有共識，就不要心急通過，也不用怕多放幾天會有反對。--蟲蟲飛♡♡→♡℃※留言 2021年3月17日 (三) 13:45 (UTC)[回复]

這是因為此規則存在。假設此規則不存在，該公示理論上是完全沒問題的。極端嚴格的「7天沒留言」規則會帶來遊戲規則的可操作性。SAN MO SA _{江南好，風景舊曾諳} 2021年3月18日 (四) 05:47 (UTC)[回复]

整理一下這裡看到的一些東西喔。WP:CONLIMITED說方針與指引的重大修改一定要先充分討論，但是小修改可以直接編輯，然後寫編輯摘要，謹慎一些就到客棧開話題知會一下，沒人回退就定了，有人反對再走程序，不過現在不知道方針小修改還能不能這樣。所以現在這個WP:7DAYS好像就是要讓人在重大修改，需要經過公示的話，希望能放上一個月，7天沒新留言會不會是當時支持方的妥協，所以現在他們不想在縮小新留言範圍，因為精神上他們認為至少放一個月比較好。--2001:B042:1:A908:F58C:12D4:4C7B:B776（留言） 2021年3月18日 (四) 04:40 (UTC)[回复]

现在7days的实际执行情况也不是很好。一些提案会根据SNOW和IAR缩短公示时间，一些提案会在数日无新留言时直接进入公示（并加长公示时间）。 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月18日 (四) 15:23 (UTC)[回复]
也是啦，這個可以在觀察，一個規定常常會被SNOW、IAR、無視，是可以檢討一下規定。以後大家真的覺得「至少放一個月的精神」真的太長的話，看看能不能不要管7天新留言，全部改成至少放14天又取得共識才能公示，然後公示至少要放7天。這樣的14+7規定也不比人事任免、榮譽票選短了，等於提案至少有放21天的知會、反對、討論時間了，然後難聚共識的大提案一定還會在更長。--2001:B042:1:A5B3:7CCD:E884:C570:5D6A（留言） 2021年3月19日 (五) 03:33 (UTC)[回复]

IAR不能亂用，只有在現行規則阻礙您維護維基，才可以用，而且要準備受到社羣的質疑，提案多討論幾天，有利於收集更多意見，因此不適宜引用IAR。此外，不依7DAYS會引發很多爭議，之前就試過有提案因為公示沒有嚴格依從7days去進行，提前公示了，結果即使提案通過了多天，仍然引發了社羣對提案的有效性的質疑。--蟲蟲飛♡♡→♡℃※留言 2021年3月19日 (五) 06:35 (UTC)[回复]

這IAR連其他管理員自己也有用到，那次我就懶得抓7日了，結果就直接過了。SAN MO SA _{江南好，風景舊曾諳} 2021年3月19日 (五) 09:28 (UTC)[回复]

其他用戶怎樣做，我不評論，但IAR是不能亂用。而且我覺得現行方針較佳，沒必要修改，而且提案也帶出了新的爭議。--蟲蟲飛♡♡→♡℃※留言 2021年3月20日 (六) 08:41 (UTC)[回复]

正是因为不能一直IAR下去，所以才要改规定啊。--DrizzleD _{(按此给我留言)} 2021年3月21日 (日) 05:21 (UTC)[回复]

剩下两点。1.没必要不是只有“必要”的事我们才做，有益于维基百科就可以了。2.新的争议争议不是个天生的坏东西，当区分有益的时候，有争议也要区分。--DrizzleD _{(按此给我留言)} 2021年3月21日 (日) 05:36 (UTC)[回复]

@蟲蟲飛：既然這都不能IAR了那IAR存在的意思是？然後濫用IAR的您也可以送一張反對票讓它重寫公示，真的能起爭議的還是能被7DAYS框住的。-- Sunny00217 2021年3月22日 (一) 16:32 (UTC)[回复]

IAR是用於緊急情況，例如管理員失控，刪去首頁，其他管理員可以不用drv，直接還原;或者管理員失控狂封人，其他管理員可以直接解封及封了失控管理員等緊急情況。相反，如果可以任意用，方針指引也沒用，人人都可以引用IAR。--蟲蟲飛♡♡→♡℃※留言 2021年3月22日 (一) 22:33 (UTC)[回复]
从来没有说法说IAR只能用于紧急情况，只要忽略的是妨碍你恰当地改进或维护维基百科的规则就可以了。--DrizzleD _{(按此给我留言)} 2021年3月28日 (日) 06:39 (UTC)[回复]

(＋)支持。——BlackShadowG（留言）_{维基百科20岁生日快乐！} 2021年3月21日 (日) 01:27 (UTC)[回复]
(－)反对：不看好新版条文，因为容易引发争议。--DavidHuai1999※Talk 2021年3月21日 (日) 05:41 (UTC)[回复]
有时候，增加争议是有益的。--DrizzleD _{(按此给我留言)} 2021年3月21日 (日) 06:10 (UTC)[回复]

(？)異議：方針修訂屬於重大提案，如果出現任何爭議都會令提案的合法性受到質疑，所以我覺得ＡＴ現行版本較佳，修訂版本不但沒有解決問題，而且帶出了新的問題。--蟲蟲飛♡♡→♡℃※留言 2021年3月21日 (日) 06:17 (UTC)[回复]

增加爭議是有益的^{[來源請求]}-- Sunny00217 2021年3月22日 (一) 16:34 (UTC)[回复]

论据已经写在上面（并已链接到）了。WP空间内容不是条目，来源不一定有必要，不然讨论没办法进行。--DrizzleD _{(按此给我留言)} 2021年3月28日 (日) 06:43 (UTC)[回复]

調適案1

現行條文

為了確保所有使用者有充足的時間發表意見以及得悉改動，如果在互助客栈中被提出的提案在七天內沒有新留言或至少討論達一個月以上的情況下，只要取得共識便可公示，為期七天。公示期間若无异议，则提案算作通过；如果有新意見，請通過協商解決問題。存檔後如果要重新提出公示的話，應同時補回相關討論連結，以便社群查閱。

提議條文

為確保所有使用者有充足的時間發表意見及得悉改動，在互助客栈中被提出的提案若在7日內無新留言^[1]，又或討論已持續28日以上的情況下，只要討論取得共識，即可公示，公示為期至少7日。公示期間若無異議，作通過論，若有新合理意見，應經協商解決問題。存檔後如果要重新提出公示的話，應同時補回相關討論連結，以便社群查閱。

参考資料

^ 不對提案進行任何點評的支持或中立意見，以及與提案本身無關的意見，皆不視作此條文所指的「新留言」。

我還是想做到一些東西，退而求其次一下好了。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 08:03 (UTC)[回复]

主要影響：

不對提案進行任何點評的支持或中立意見不造成重算7日。
與提案本身無關的意見不造成重算7日，而意見是否與提案有關根據《討論頁指引》的規定界定。
將浮動的時間範圍「1個月」界定為固定的時間範圍「28日」。（依舊）
容許公示在有必要時可長於7日。（依舊）

以上。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 08:09 (UTC)[回复]

(－)反对:理由同上，我還是覺得AT現行版本較佳，而且提案不但沒有解決問題，而且註腳部分帶出更多的公示爭議。--蟲蟲飛♡♡→♡℃※留言 2021年3月26日 (五) 13:31 (UTC)[回复]

「不對提案進行任何點評的支持或中立意見」是很容易看出來的事情，多一句話就已經是「點評」了，非常明確，怎麼可能「帶出更多的公示爭議」？《討論頁指引》的規定也應該很清楚明白吧，難道說《討論頁指引》也是形同虛設的？將浮動的時間範圍界定為固定的時間範圍也是明確指引的處理。修訂容許公示時間可長於7日，但沒容許可短於7日，因此公示時間上也不可能產生爭議。綜以上，我完全不認同調適案1「帶出更多的公示爭議」。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 13:39 (UTC)[回复]

現在方針修改頻繁，AT版七天已經算是很合理的時間，頻繁的方針修訂中，讓社群有足夠時間去消化，及讓提案有足夠時間收集更多意見是必須的。--蟲蟲飛♡♡→♡℃※留言 2021年3月26日 (五) 13:47 (UTC)[回复]

頻繁的方針修訂正是因為社羣有迫切的需求，如果社羣不理解方針修訂的內容，理當向提案人發問（這樣做無論是在原始提案下，抑或在調適案1下，都仍然會造成重算7日），我不明白社羣怎麼在遇到看不明白的事情都不會發問。一味壓抑社羣的迫切需求對社羣而言並不健康，我僅是希望將equilibrium position稍稍推回到提案人一邊一些而已。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 14:07 (UTC)[回复]

像下方#交通關注度指引修訂這樣的方針修訂，我是不見得需要多長的時間來「消化」。需要較長的時間來「消化」可能是像下方#分案1這樣的方針修訂，那為何不像MINQI這樣去發問？這可能比自己自行「消化」提案內容來得更有效率，使自己更快清楚明白提案內容。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 14:11 (UTC)[回复]

您搞錯了兩者因果關係，正因為修訂頻繁，提案更不應急於公示，應該收集更多意見，而不是火速公示，強行通過，然後有些用戶來不及表達意見，結果爭議不斷。--蟲蟲飛♡♡→♡℃※留言 2021年3月26日 (五) 14:14 (UTC)[回复]

不，方針指引修訂頻繁是社羣的迫切需求的結果。現行條文只是在無視社羣實際存在的迫切需求，並將之強行壓抑。社羣的迫切需求是方針指引修訂頻繁的產出來源，應當做的是滿足需求，而非壓抑需求。再者，現實上方針指引修訂頻繁不可能等到所有人發表了意見才能處理，否則這就屬於遊戲共識形成程序的情形。SAN MO SA _{江南好，風景舊曾諳} 2021年3月27日 (六) 10:36 (UTC)[回复]

@Sanmosa：不能认可方针的快速频繁修订（及提案和公示）。方针应该是总结归纳长久的共识，仅在争议严重时依充分讨论规定妥协方案（如COVID-19命名）。将未成熟的方针及公示作为约束或指导后续编辑的手段是不正确的，WP:BURO：“不是盲目跟随默认的方针和程序。要避免编写过分冗长的指示。”。应更多以讨论确认意见、指引，而非编立方针来不必要的规约。设立规则来制止他人反而会有GAME之嫌。--YF dyh000（留言） 2021年3月27日 (六) 12:16 (UTC)[回复]

既然社羣存在如此的迫切需求，那相關的規約自然是必要的。必要性取決於需求。SAN MO SA _{江南好，風景舊曾諳} 2021年3月27日 (六) 13:13 (UTC)[回复]

「迫切需求」是您的意見，不是社羣，方針屬於重大提案，應該讓社羣有足夠時間消化及表達意見，千萬不要心急，有共識的提案就不用怕多放幾天有(－)反对，而且急於通過，火速公示，然後爭議不斷，那通過的提案也不是反映共識。--蟲蟲飛♡♡→♡℃※留言 2021年3月28日 (日) 04:54 (UTC)[回复]

方针快速频繁修订是个问题，但如果真的要修订，这里的关注点是，单纯支持之意见不该导致重算。--DrizzleD _{(按此给我留言)} 2021年3月28日 (日) 06:53 (UTC)[回复]

要说多少遍本提案和“七天”没有任何关系。实话说，您要是觉得时间短，延长到十天我也没意见，但“不对提案进行任何点评的支持或中立意见”能导致重算，究竟合理吗？--DrizzleD _{(按此给我留言)} 2021年3月28日 (日) 06:50 (UTC)[回复]

您說沒有評點就提前公示，為甚麼要以不同名目去提前公示呢？請瞭解AT版當時訂的版本就是為了解決社羣急於公示而帶出的爭議問題，為甚麼不能讓提案多收集一些意見呢？而且要注意不是每個用戶都很活躍，讓提案多放一些時才能收集更多意見，因此我覺得AT現行版本較佳。--蟲蟲飛♡♡→♡℃※留言 2021年3月28日 (日) 06:58 (UTC)[回复]
我明白您的意思。您可以看看下面的方案如何。或许看了之后您可以更了解我的想法。--DrizzleD _{(按此给我留言)} 2021年3月28日 (日) 07:06 (UTC)[回复]

说到这个，为了拯救陷入同义反复的讨论，我决定提出一个新想法，看看能不能抛砖引玉。改成：

為確保所有使用者有充足的時間發表意見及得悉改動，在互助客栈中被提出的提案若在10日內無新留言^[1]，又或討論已持續28日以上的情況下，只要討論取得共識，即可公示，公示為期至少7日。公示期間若無異議，作通過論，若有新合理意見，應經協商解決問題。存檔後如果要重新提出公示的話，應同時補回相關討論連結，以便社群查閱。

参考資料

^ 不對提案進行任何點評的支持或中立意見，以及與提案本身無關的意見，皆不視作此條文所指的「新留言」。

即额外把7日改成10日，这下新提案的讨论时间应该不会比旧的情况少了。“应该让社群有足够时间消化及表达意见，千万不要心急，有共识的提案就不用怕多放几天有(－)反对，而且急于通过，火速公示，然后争议不断，那通过的提案也不是反映共识”，那多几天总没问题吧。--DrizzleD _{(按此给我留言)} 2021年3月28日 (日) 07:01 (UTC)[回复]

我還是覺得註腳部分有爭議，因為「有沒有點評」不同人都有可能有不同的解讀，而且客棧遇到激烈爭議時，這個註腳只會帶出更多爭議，而且本站社羣還沒有達到英維的客觀與理性，無視反對意見，指鹿為馬等奇怪的事常有，因此我還是(－)反对注腳部分。反而，Sanmosa想爭取28天，減兩天，這個我沒有異議。--蟲蟲飛♡♡→♡℃※留言 2021年3月28日 (日) 07:19 (UTC)[回复]
好，Sanmosa想争取28天，减两天，这个我没有异议，看来我们已经达成了第一个共识，讨论是有成果的了。

下一个点是，您是否觉得不对提案进行任何点评的支持意见不导致重算合理。如果是的话，那我们就达成了下一个共识，只需要关心有没有办法解决“有没有点评”不同人都有可能有不同的解读这个问题就可以了。--DrizzleD _{(按此给我留言)} 2021年3月28日 (日) 07:51 (UTC)[回复]

「不對提案進行任何點評的支持或中立意見不造成重算7日」這句話的意思我要解釋一下，就是只寫了「支持」、「中立」、「沒意見」、「不反對」之類的，我認為定義已經足夠明確。我不要求只有「實則性點評」才能導致重算7日已經是很大的讓步了。SAN MO SA _······ 2021年3月28日 (日) 23:51 (UTC)[回复]

這是不必要，而且這是您的理解，實際的爭議時，不同人都可能有不同的解讀，我還是覺得AT現行版本較佳，即「七天沒有留言」就可以公示，完全沒有爭議。但您以不同名目去縮短公示期限，這是不必要，而且容易造成爭議。提案的公示一旦有爭議，提案的合法性就會受到質疑，過去是有先例的。--蟲蟲飛♡♡→♡℃※留言 2021年3月29日 (一) 05:05 (UTC)[回复]
- 问题在于，现在有些人看到讨论过了几天，避免重算也不敢支持也不敢中立，我觉得反而不好收集社群意见。 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月29日 (一) 06:07 (UTC)[回复]

您有所不知，客棧的提案不是收集支持或中立，而是看看有沒有(－)反对，因為提案放出來，七天完全沒有留言，已經可以公示，公示後，沒異議就通過，其他維基也是一樣，因此提案的反對意見比支持的意見重要。而且，「七天沒留言」在維基可視為默認共識，見WP:TALKDONTREVERT：「假如編者已停止在討論頁內回覆相關討論，便可以假定共識已經形成。」--蟲蟲飛♡♡→♡℃※留言 2021年3月29日 (一) 06:30 (UTC)[回复]
如果相關支持意見或中立意見裏面有其他建設性的提議的話，那些意見和反對意見是同等重要的，然而現行條文有可能阻礙相關附有有其他建設性的提議的話支持意見或中立意見的表達。SAN MO SA _······ 2021年3月29日 (一) 06:36 (UTC)[回复]

所以我希望最後的共識能確立該條條文以我上方的解讀為準。SAN MO SA _······ 2021年3月29日 (一) 06:36 (UTC)[回复]

還是回到那個問題，甚麼叫“有建設性的意見”？標準誰定？爭議時互相指責對方的意見“無建設性”，結果把本來不應有的公示爭議，變得非常有爭議。蟲蟲飛♡♡→♡℃※留言 2021年3月29日 (一) 06:53 (UTC)[回复]

我請你重看我的調適案1，我的調適案1完全無提及過「有建設性的意見」，我不知道你是從哪裏看到的，還是你不小心看到了甚麼一般人看不到的東西。如果你是從我上面的留言看到的話，那我只能夠說你真的沒有一般人應有閱讀中文的能力，我說的是現行的條文讓人不願意留下附有其他建設性的提議的支持意見或中立意見，而不是直接阻止，具阻止性質的效果有時候並不需要直接言明的條文達到；至於這事情會產生的問題，那就是只有反對意見得以顯現，使實際的意見比例和表面上所看到的意見的比例不符。SAN MO SA _Σουέζ 2021年3月29日 (一) 10:00 (UTC)[回复]

請重看您於「2021年3月29日 (一) 06:36 (UTC)」的留言。而且「進行任何點評」也是換了不同的名目，性質也是一樣，這些都是不必要的，AT現行版本已經很清晰，沒有修改的必要。--蟲蟲飛♡♡→♡℃※留言 2021年3月29日 (一) 14:02 (UTC)[回复]

完全不一樣，這制限條件已經完全不同了。我真的只能認為你真的沒有一般人應有閱讀中文的能力，這分明已經是兩種完全不同的情況。SAN MO SA _Σουέζ 2021年3月31日 (三) 07:49 (UTC)[回复]

請不要人身攻擊﹗您是換了不同名目去縮短公示期，這是與AT版解決火速公示的提案原意不合。而且我反而我看到您平時公示時一有異議就重新公示，我覺這個操作很不錯，所以建議加一條「公示期間如有異議應重新公示」。--蟲蟲飛♡♡→♡℃※留言 2021年3月31日 (三) 10:35 (UTC)[回复]

「縮短公示期」從不存在，不論是原案抑或調適案也如是。我認為所有用戶均有重新公示的意識，而且重新公示的操作可以依規進行，無須特別規範。SAN MO SA _Σουέζ 2021年4月1日 (四) 00:51 (UTC)[回复]

(－)反对，讚同蟲飛飛的意見。AT的版本已經很清晰。Walter Grassroot（留言） 2021年4月1日 (四) 01:34 (UTC)[回复]

（咦？）SAN MO SA _Σουέζ 2021年4月2日 (五) 08:43 (UTC)[回复]

提案目的并非让方针更“清晰”。--DrizzleD _{(按此给我留言)} 2021年4月4日 (日) 16:24 (UTC)[回复]

(－)反对：在此种情况下应依据常识进行判断，而不是拘泥于方针细节之中。--Yining Chen（留言|签名） 2021年4月4日 (日) 12:05 (UTC)[回复]

就在WP:UCS这一页的图表：是否是规则错了？是→改变规则。--DrizzleD _{(按此给我留言)} 2021年4月4日 (日) 16:29 (UTC)[回复]

第一步

看上去至少明确1个月为28天这一点没人有异议。--DrizzleD _{(按此给我留言)} 2021年4月12日 (一) 09:52 (UTC)[回复]

(－)反对，一個月應為30天，過往各個原定以月計算的資格（例如不活躍管理員、關注度等）都是以30天來換算改例，這個卻不是，執行上可能引起混淆。而上面對於28天的公平性解釋並不充份，上面的理據衹能說明大小月的日子不同而造成的不公平，但不足以說明28天是最公平（因為我也可以說31天可以讓人有較多時間討論，28天顯然損失了時間，為了補償小月的損失所以用31天、全部都要跨月才最公平）。事實上，衹要有一個明確的統一天數，跨月與否本身並不影響公平性。--街燈電箱150號開箱維修抄錶檢驗證明 2021年4月18日 (日) 11:41 (UTC)[回复]

@Cdip150：現在是把不固定的“一個月”改寫成固定的日數，不可能“執行上可能引起混淆”，“28日”和“30日”很明顯是有分別的。現在的討論情況其實就是現行方針已經令客棧討論產生了冗長辯論的問題（這討論串就是活生生的例子），因此即使“跨月與否本身並不影響公平性”成立，也不可能訂立一個較長的日數（對，我的意思就是説30日已經過長，現行方針正在過分鼓吹“讓人有較多時間討論”，結果適得其反，這也是提出是次方針修訂的主因）。我本來的想法是直接縮短那個期限到比任何定義上的“一個月”更短。SAN MO SA _Σουέζ 2021年4月19日 (一) 01:02 (UTC)[回复]

不認為現在的冗長辯論的主因是多了這兩三天，提案要是具爭議的，無論定多少天都會有人拉下去，以現狀來推斷「30日已經過長」、「不可能訂立一個較長的日數」，我認為理據非常不充份。--街燈電箱150號開箱維修抄錶檢驗證明 2021年4月19日 (一) 02:03 (UTC)[回复]

@Cdip150：建議你看看這規則通過以來的所有客棧討論，一個與討論主題不相關的留言直接導致公示延後非常常見。現行規則唯一的“作用”是在不必要地拖時間。SAN MO SA _Σουέζ 2021年4月19日 (一) 02:15 (UTC)[回复]

「一個與討論主題不相關的留言」與至少多少天是不相關的，就算定了28天，不代表那些不相關的留言就會少。又或者說簡單一點，這種延後的原因本來就不是出在「一個月」身上。--街燈電箱150號開箱維修抄錶檢驗證明 2021年4月19日 (一) 03:23 (UTC)[回复]

受影響規模會縮減。SAN MO SA _Σουέζ 2021年4月19日 (一) 03:54 (UTC)[回复]

(？)異議:完全同意Cdip150，完全看不到有甚麼理據一定要改為28天，而且不認為會減少影響，而且這個提案根本就沒必要。頻繁提案改方針，急速公示，強行通過，除了增加爭議，一點意義都沒有。--蟲蟲飛♡♡→♡℃※留言 2021年4月19日 (一) 04:20 (UTC)[回复]

(－)傾向反對，意見同Cdip150閣下。—— Eric Liu_{創造は生命（留言．留名．學生會）} 2021年4月19日 (一) 05:30 (UTC)[回复]

Per Cdip ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月21日 (三) 16:11 (UTC)[回复]

(－)反对甚麼討論有必要個28天沒人發言才能定讞-- Sunny00217 2021年4月26日 (一) 10:41 (UTC)[回复]

有關新增偽命名空間的提議

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:捷徑、Wikipedia talk:偽命名空間輔助說明、Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间（錯誤：Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间是重定向頁面）。

通過：

@Sanmosa、羊羊32521、MilkyDefer、YFdyh000：通過，請開始實行各修訂。--LuciferianThomas • 留言 2021年4月30日 (五) 04:13 (UTC)[回复]

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

現時MOS和LTA均為偽命名空間，其中MOS專門指向站內各已正式通過和未正式通過的格式手冊。我有一個想法是能不能為命名常規和關注度指引也設立專門的捷徑偽命名空間？SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 09:02 (UTC)[回复]

@A2569875、Taiwania Justo、Yining Chen、羊羊32521、YFdyh000、@LuciferianThomas、Ericliu1912、MilkyDefer、Super Wang、Sunny00217。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 09:08 (UTC)[回复]

(＋)支持。偽命名空間運行暢順，可選擇有需要的計劃空間內容增設偽命名空間。(＆)建議命名常規使用「NC」字首、關注度使用「N」字首。另(＆)建議增設共識（討論）捷徑「CON」，連結至各討論存檔（Talk、WT、PJT）或資訊頁（WP），如CON:COVID19指向COVID-19條目共識。--LuciferianThomas．留言 2021年3月24日 (三) 09:32 (UTC)[回复]

NC和N可行。CON可行，但建議另外討論，因為CON可以重新導向到的目標有太多類頁面。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 10:00 (UTC)[回复]

支持N和NC，对CON保留意见 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月25日 (四) 06:07 (UTC)[回复]

N的话会不会短了点？之前MOS和LTA的时候因为是三个字母，跟正式条目命名撞车的可能性小所以没有问题。这一个N我个人有点拿不准。此外我觉得CON可能还不是时候。在我的认知中，单独讨论出共识单独成页的也就只有COVID-19这一个了，至少应当等类似的页面数量足够多了再提出会比较好。如果有我不知道的类似页面尽管告诉我。 --Milky·Defer 2021年3月25日 (四) 07:36 (UTC)[回复]

檢查過，現時沒有條目空間的頁面是「N:」開首的。如果真的不放心的話，NT和NOTE也可以（但不能NOT）。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 07:44 (UTC)[回复]

@sanmosa：维基新闻的前缀就是“n:”，烦请查询Special:跨wiki。--痛心疾首 2021年4月2日 (五) 15:43 (UTC)[回复]

啊，忘了。SAN MO SA _Σουέζ 2021年4月3日 (六) 00:12 (UTC)[回复]

先跑题：MOS基本没用过，看到时我习惯改用WP前缀。LTA用过但没有独立空间所以搜索很不方便，期望未来设独立空间、增设访问限制。然后：我不清楚相关页面有多少，如果很少，可能用的人也不会很多？以及持久性不会好（几年后失效）。N有点短，NOTE我想到[{tl|TA}}和备注，命名常规为什么不是NAME:（但未来会不会冲突？）。关注度没想法，考虑到“关注度”定名本身都有质疑，我暂时想不到很好的。NT在中国大陆网络有贬义“脑瘫”，不赞成。--YF dyh000（留言） 2021年3月25日 (四) 12:14 (UTC)[回复]

@YFdyh000：「NAME:」應該不會衝突吧，也不不失是一個好提議。「NT:」你當我真的NT了吧（在香港「NT」指新界，不過以地名開首還是有些怪）。「NOTA:」不知如何，有種葡文風，但字源仍是「Notability」，衝突的機會也低。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 13:01 (UTC)[回复]

(－)反对，如果将编辑社群页面等因为与Wikipedia命名空间关联性不强而划分出的话，方针等与项目运营有关的的页面不应该划出Wikipedia空间，而且本身这部分已经能通过消歧义的方式处理，没坏别瞎修。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年3月26日 (五) 00:54 (UTC)[回复]

@cwek：偽命名空間僅用於設置重新導向頁面（這是指引指明的），完全沒有你所說的「（將導向目標）劃出Wikipedia空間」那回事。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 01:00 (UTC)[回复]

偽命名空間作用並非直接劃出內容，而是作捷徑之用：#偽命名空間、WP:PNS、WP:PNS+。因為似乎對於提案內容有所誤解，反對的事也並非現在實際正在討論之議案，故難以算作有效反對意見。--LuciferianThomas．留言 2021年3月28日 (日) 06:23 (UTC)[回复]

又想了一下，关注度用用NOTA:什么的太长，不是太有必要，WP:Nxxxx辨识度已经够，NT可行。仍支持NC。nc不是还有脑残的意思？（ ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月8日 (四) 15:16 (UTC)[回复]
Naming Conventions... 別想歪就好了啦。--LuciferianThomas．留言 2021年4月10日 (六) 23:10 (UTC)[回复]

初步定案

建議為命名常規和關注度指引設立專門的捷徑偽命名空間，其中命名常規的專門捷徑偽命名空間為「NC:」，而關注度指引的專門捷徑偽命名空間則為「NT:」。SAN MO SA _Σουέζ 2021年4月14日 (三) 13:24 (UTC)[回复]

（打撈）--LuciferianThomas．留言 2021年4月23日 (五) 01:31 (UTC)[回复]

@LuciferianThomas：請記得也把存檔頁的內容刪除，以免之後存檔有重複內容。--Xiplus#Talk 2021年4月23日 (五) 01:40 (UTC)[回复]

好滴--LuciferianThomas．留言 2021年4月23日 (五) 01:58 (UTC)[回复]

由於超過七日無新意見，

公示7日，2021年4月30日 (五) 01:33 (UTC) 結束。--LuciferianThomas．留言 2021年4月23日 (五) 01:33 (UTC)[回复]

若有條目也叫NC，會不會對沖呢？空氣小貓（留言） 2021年4月27日 (二) 09:07 (UTC)[回复]

NC不是名字空間，NC加冒號「NC:」才是名字空間。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月28日 (三) 04:14 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

MediaWiki:Gadget-pseudonamespace-UI.js需要WP:介面管理員（編輯請求）；另外要改的不少模板是全保護。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月30日 (五) 04:43 (UTC)[回复]

模板颜色相关规范

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:格式手冊/文字格式、Wikipedia talk:分類、列表與導航模板。

本主題或以下段落文字，移動自Wikipedia:互助客栈/条目探讨。执行者：SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 08:57 (UTC)。[回复]

想问一下关于模板的相关规范：现在的模板并没有任何关于颜色的规范。我个人希望模板的颜色本身不应被任何其他的配色所取代（模板不应被着色），尤其是没有达成任何Accessability相关要求的共识前，均不应当修改任何着色，否则将会可能影响读者正常阅读模板。--1233 （T / C） 2021年3月22日 (一) 13:19 (UTC)[回复]

可参见WCAG 2.1 AA。--痛心疾首 2021年3月22日 (一) 13:34 (UTC)[回复]

Wikipedia:格式手冊/文字格式#颜色及内联图像算不算？SAN MO SA _{江南好，風景舊曾諳} 2021年3月22日 (一) 13:52 (UTC)[回复]

導航模板不算正文（邏輯上）。就是此前處理了一個WCAG 2.1有問題的模板我才開啟討論。1233 （T / C） 2021年3月23日 (二) 03:51 (UTC)[回复]

Wikipedia:格式手冊/文字格式#颜色及内联图像的確無法處理導航模板。 --無心*插柳*柳橙汁 2021年3月24日 (三) 03:31 (UTC)[回复]

@1233、Milkypine：可以擴大Wikipedia:格式手冊/文字格式#颜色及内联图像的適用範圍。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 04:40 (UTC)[回复]

完全支持擴大適用範圍。 --無心*插柳*柳橙汁 2021年3月25日 (四) 05:13 (UTC)[回复]

可解決問題，故支持。唯此格式手冊的修訂將會影響大量的模板，故需要更深入的討論。--1233 （T / C） 2021年3月25日 (四) 15:23 (UTC)[回复]

@痛心疾首、Milkypine、1233：已移動討論至方針區。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 09:01 (UTC)[回复]

擬修改如下：

現行條文

颜色及内联图像

在条目正文及表格之中，禁止手动或使用模板将文字染成某种特殊的颜色，可以接受的情况仅限于信息框中。这一方面是为了减轻服务器负担以及方便后来编辑者的维护，另一方面是为了方便色盲、色弱或使用黑白版本的读者阅读文字。^[1]

只有在背景顏色可幫助闡釋條目內容，且沒有其他更佳的表達方式時，才可對表格或其他的內文元素加入背景顏色。為了照顧視障或色覺障礙讀者的需要，請避免單獨地使用背景顏色來表達某一含義，而應適當地同時以文字方式表述。為了保障條目的可讀性，請避免使用飽和度過高，或與文字對比度不足的顏色作為表格的背景色。禁止使用CSS代碼對表格背景加入花俏的樣式（如漸層色等）。

类似地，条目正文中，禁止使用内联图像（例如在文字中出現這樣的图像），但若在表格及信息框中使用則是可以接受的。

参考資料

^ 参见Wikipedia:鐵道專題/移除著色文字模板。

提議條文

颜色及内联图像

条目正文、表格及各類模板（包括信息框）中禁止手动或使用（其他）模板将文字及背景顏色染成非預設颜色。此舉乃是为减轻服务器负担並方便后来编辑者的维护，亦是为方便色盲、色弱或使用黑白版本的读者阅读文字。^[1]

只有在背景顏色可幫助闡釋條目內容，且沒有其他更佳的表達方式時，才可對表格或其他的內文元素加入背景顏色。為了照顧視障或色覺障礙讀者的需要，請避免單獨地使用背景顏色來表達某一含義，而應適當地同時以文字方式表述。為了保障條目的可讀性，請避免使用飽和度過高，或與文字對比度不足的顏色作為表格的背景色。禁止使用CSS代碼對表格背景加入花俏的樣式（如漸層色等）。

同理，条目正文中亦禁止使用内联图像（例如在文字中出現這樣的图像），但在表格及信息框中使用内联图像則可接受。

参考資料

^ 参见WikiProject:鐵道/移除著色文字模板。

以上。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 23:40 (UTC)[回复]

格式手冊僅適用於條目。關於模板的格式指引應該置於維基百科:分類、列表與導航模板。—— Eric Liu_{創造は生命（留言．留名．學生會）} 2021年3月27日 (六) 09:20 (UTC)[回复]
理論上可以在WP:分類、列表與導航模板直接套用Wikipedia:格式手冊/文字格式#颜色及内联图像的內容處理（會動用到onlyinclude參數，效果和模版編輯員方針有關行使權力的條文的效果一致），所以這反而不成問題。SAN MO SA _{江南好，風景舊曾諳} 2021年3月27日 (六) 10:23 (UTC)[回复]

@Ericliu1912。SAN MO SA _{江南好，風景舊曾諳} 2021年3月27日 (六) 10:26 (UTC)[回复]
順便把footnote的連結改為WikiProject:鐵道/移除著色文字模板吧。--LuciferianThomas．留言 2021年3月28日 (日) 06:25 (UTC)[回复]

似乎应该是不在条目里用带特殊颜色的模板，而不是规定模板不得带颜色。所以建议“条目正文、表格及各类模板”→“条目正文、表格及条目中使用的各类模板”。--DrizzleD _{(按此给我留言)} 2021年3月28日 (日) 08:04 (UTC)[回复]

@DrizzleD：然而這裏最原始的提議就是禁止所有模板著色（如果我沒理解錯的話），@1233。SAN MO SA _······ 2021年3月28日 (日) 23:48 (UTC)[回复]

@DrizzleD、Sanmosa：我的概念是應當建立相關Accessibility的指引（例如對規範模板中文字和背景色的對比度）。而又當此等指引未達成共識前，則不應對模板著色。--1233 （T / C） 2021年3月29日 (一) 02:39 (UTC)[回复]

禁止所有模板着色恐怕不现实。且不提{{支持}}这种模板或者就在本句话中使用的{{tq}}，单是为数众多的多彩用户框就不可能处理过来啊。--DrizzleD _{(按此给我留言)} 2021年3月29日 (一) 14:48 (UTC)[回复]

如果我沒理解錯誤的話，是不是Infobox系列模板都不能自訂文字和背景的顏色？空氣小貓（留言） 2021年3月29日 (一) 04:28 (UTC)[回复]

是的（如果我沒理解錯1233的意思的話）。SAN MO SA _······ 2021年3月29日 (一) 05:31 (UTC)[回复]

就Accessability这个理由，完全支持禁止对模板、表格等上色。🌟🌟_Talk 2021年3月29日 (一) 04:53 (UTC)[回复]

(－)反对：信息框內的文字在某些情況下應允許使用不同的顏色，否則將無法很好地表意；導航模板同理，例如{{柑橘属}}和{{地質年代}}模板使用了不同的底色，但也只是起到輔助區分相關信息的作用，並不影響色盲色弱等特殊群體閱覽，取消這些底色後，非但不能照顧到少部分特殊群體（因為在色盲色弱看來，無論普通模板還是上色模板基本都是一片灰，並無本質上的區別），並且對於絕大部分正常讀者而言將是一大損失。讓絕大部分正常群體去遷就少部分特殊群體，屬於西方式政治正確（就好比硬說黑人和白人一樣聰明），英維的做法不可取。--蕭漫（留言） 2021年3月29日 (一) 12:51 (UTC)[回复]

同意需要有指引規範相關模板的著色。另外我處理的部分模板出現嚴重的"撞色"問題，才要求模板應暫時停止著色。這不是西方不西方的問題，而是此等問題已經燃燒至影響正常的閱讀體驗了。--1233 （T / C） 2021年3月29日 (一) 13:30 (UTC)[回复]

西不西方我是不清楚，但肯定是眼殘級別追夢 Do Re Mi。尤其是像Template:Weki_Meki，這邊上色的意義何在？ --Loving You Is A Losing Game 2021年3月29日 (一) 15:21 (UTC)[回复]

不同意柑橘屬跟地質年代這兩個舉例，柑橘屬的顏色僅僅是階層式架構，以排版就足以區分，不需要再加上顏色；至於地質年代的顏色更是沒有意義，部分底色與文字顏色對比度不高，對正常人來說也是難以閱讀。--Xiplus#Talk 2021年4月3日 (六) 06:01 (UTC)[回复]

@Xiplus：像这三个案例{{中国历史}}、{{Geological_range}}、和{{古近纪图形时间线}}呢，有本事你对Geological_range和古近纪图形时间线的英维版禁止着色啊。反对一刀切致使中维倒退的方针。你少代表正常人对地质年代发表看法，也只是对你来说難以閱讀而已。U:Lab06 N 参与微软专题 2021年4月3日 (六) 12:46 (UTC)[回复]

(－)強烈反对：对地质和生物学相关等特殊模板有严重影响！1.减轻服务器负担这个理由就经不起推敲，难道现在的服务器机能还不如以前的服务器？2.另外照顾色盲色弱群体这个理由已经有人反驳了。U:Lab06 N 参与微软专题 2021年3月30日 (二) 13:57 (UTC)[回复]

那完全不是合理的反駁理由。“因為在色盲色弱看來，無論普通模板還是上色模板基本都是一片灰，並無本質上的區別”是錯的，普通模板的話全色盲至少還能分得到淺色和深色（白色和黑色），上色模板全色盲就完全分不到了。全色盲還是能分辨白色和黑色的，他們只是cone cell不能function而已，rod cell還是能function的。SAN MO SA _Σουέζ 2021年3月31日 (三) 07:53 (UTC)[回复]

既然已經了解提案禁止對Infobox等模板上色，那麼我(－)反对此提案，畢竟有些Infobox模板的顏色對辨別條目類型有很大的幫助，不能因為視覺障礙人士而選擇單一的格式，不過如果是限制背景顏色和文字顏色之間的對比度，這我能夠接受。空氣小貓（留言） 2021年4月1日 (四) 14:20 (UTC)[回复]

仔细想了想，倾向不赞同：

（主要）现行方针能够确保色盲（弱）人士能够获取充分信息，根据现行方针要旨，只需避免“单独地使用背景颜色来表达某一含义”，同时避免“饱和度过高，或与文字对比度不足”，上述举措——
- 确保了色盲（弱）人士能够不依赖颜色获取足够信息，确保所有人阅读的文字是清晰的；
- 在此基础上，不对辅助性背景填色进行“一刀切”，能保障更多色觉正常的人士能借背景色获得获取信息上的便利。
（次要）变更宜乎审慎行事，仅高速公路一类就有逾千条条目和大量模板受到影响，即便上述修改要实施，修正案也未能列出批量变动的页面范围和变动的具体方案。

以上。--Kirk # 2021年4月1日 (四) 14:33 (UTC)[回复]

個人認為對現行模板應當是採取沒壞別修的態度：應當先行禁止新（類型）的模板著色，再討論如何界定為“可行”且為輔助性的背景著色，再解決“應當在何時著色”和“怎樣才是可行的著色”的兩個問題--1233 （T / C） 2021年4月3日 (六) 02:41 (UTC)[回复]

(－)反对，限制面太广，用户框、导航模板等都会受影响。可行的着色可以按常识判断。 ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月3日 (六) 04:56 (UTC)[回复]
拆分投票：
- (＋)傾向支持在條目正文中禁用內聯圖像。
- (－)反对一刀切地禁止上色。限制使用過份複雜的上色可以理解，但一刀切的話就過猶不及了。📕📙📒📗📘📚📖 2021年4月3日 (六) 05:12 (UTC)[回复]
支持要求条目用导航模板使用预设配色。使用其他颜色可以，但应该给出理由；而且这个理由是领域内讨论出的统一的配色方案。像Template:Citrus为什么要上成黄色而不是其他颜色？是属级导航框的统一用黄色，纲级导航框又用另一种颜色；还是觉得这个颜色是柑橘的主题色（那孔雀呢）；还是编辑没理由随便上的颜色？而且导航模板和信息框还不一样：条目可以放多个导航模板，随意上色的结果就是花花绿绿，不同颜色搭配起来很不美观。如果其他导航框用默认颜色，比较次要的那个导航模板又私自上色，那它会不会有抢镜头的嫌疑？总之，导航模板上色需要极其保守，找不到必须上色的理由就别上。--洛普利宁 2021年4月3日 (六) 16:13 (UTC)[回复]
支持樓上所述，另參考各語言維基百科也對上色趨於保守或嚴格規範。即便不全面禁止也需有個合理的規範，哪些領域的確有這需求，哪些領域又該嚴格禁止或者限定。不該完全置之不理任由問題累積未來才以影響範圍大而放棄討論制定規範。～立ち直り中^ಇ 2021年4月5日 (一) 12:47 (UTC)[回复]
上色這種東西如果能夠靠自由心證或常識解決，那就不會有像追夢 Do Re Mi這樣的上色亂象。的確我不是地理條目相關編輯，但前面提到的{{中国历史}}、{{Geological_range}}、和{{古近纪图形时间线}}請問有哪個一定需要顏色？或者說這些顏色必須一定要有的理由為何？（當然也可以直接開民調調查有顏色大家會不會比較ＯＫ）。如果這些顏色有一定的存在理由，那就針對這點做改善（例如常用習慣等）。 --Loving You Is A Losing Game 2021年4月5日 (一) 13:11 (UTC)[回复]

意見頗為分歧，我建議就此進行投票，不知各位意下如何。SAN MO SA _Σουέζ 2021年4月10日 (六) 06:39 (UTC)[回复]

這不是投票就能解決的問題，一來是不能只因為視覺障礙人士而選擇單一的樣式，再者是影響範圍過大，投票並不能體現所有使用者的意見（匿名使用者不能投票，請留意維基百科並非專給註冊使用者閱讀）。如果您要發起民調，我沒意見，但是我反對發起投票。空氣小貓（留言） 2021年4月10日 (六) 07:05 (UTC)[回复]

然而現時的狀況確實對視障人士構成嚴重的歧視，我認為所有人現在最基本要知道的就是現時模板的着色情形已經嚴重影響到視障人士的閱讀體驗。投票的選項亦非只有兩種（至少我初步的計劃如是）。在陷入複雜討論的泥潭時，投票顯然是一種快速收集意見以凝聚共識的方法，不能單純因為「影響範圍過大」和「不能體現所有使用者的意見」而反對發起投票和變相剝削視障人士的合理閱讀體驗。SAN MO SA _Σουέζ 2021年4月11日 (日) 14:26 (UTC)[回复]

@Sanmosa：「影響範圍過大」和「不能體現所有使用者的意見」已經不是您所指的單純問題了。您發起民調來蒐集意見我沒意見，但是要將投票結果作為共識執行，我不能接受。當然您要發起與否是您的自由，如果社群能夠接受結果，那我也沒話說，只是還請留意，我不能接受投票不代表我反對投票，也不代表我變相剝奪視覺障礙人士的合理閱讀體驗，這只是表達我的個人意見，而我的意見是對於此種議題，應該有比投票更能體現共識的方式。空氣小貓（留言） 2021年4月12日 (一) 02:31 (UTC)[回复]

發起投票的最主要目的是在討論各方意見很大程度上分歧時確立討論的大方向，如果連大方向都不能確立，我難以相信討論能有效持續。SAN MO SA _Σουέζ 2021年4月14日 (三) 13:19 (UTC)[回复]

@Sanmosa：確立討論的方向，請使用民調而非投票。空氣小貓（留言） 2021年4月14日 (三) 18:01 (UTC)[回复]

(－)反对Template:元素週期表會無法呈現，更不用說縮圖型導航的Template:NavPeriodicTable，此舉同時也導致了之前色弱友善元素週期表顏色配置Template talk:Isotope nav#同位素模板顏色更換全部白討論了，浪費了社群資源。考量到需要區分元素本身特性，以下主題有許多層級需要區分
1. 元素週期表（Template:元素週期表、Template:NavPeriodicTable）
  - 鹼金屬、鹼土金屬、過渡金屬、貧金屬、非金屬、鹵素、稀有氣體.... 等至少7種等級
2. 元素穩定性表（Template talk:Isotope nav）
  - 大量穩定同位素、僅一種穩定同位素、僅有觀測上穩定同位素、最穩定同位素半衰期萬年、半衰期千年、半衰期1年或以下、半衰期以日計、半衰期以時計、半衰期以秒計、目前未發現同位素（如Uue）等至少10種等級
3. 元素分區（Template:元素週期表_(正文)#範例）
  - s區元素、p區元素、d區元素、f區元素、g區元素等至少5種等級
要區分5種以上等級，禁用顏色根本強人所難，無法實行，或實行會導致元素週期表等相關條目無法準確製作示意圖表。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月14日 (三) 19:05 (UTC)[回复]
同時也反對禁用內連圖像。{{缺字}}、或Unicode未收錄符號、特殊的語言（如克林貢語）和特殊數學符號（如en:Coxeter–Dynkin_diagram、{{CDD}}），全是內連圖像，禁用的話，全部都難以或無法描述條目了。特別是en:Coxeter–Dynkin_diagram，根本不可能用文字描述代表一個en:Coxeter–Dynkin_diagram，要求只能放在圖表將導致內文難以描述，必須在內文呈現符號再加以說明，這個如果禁的話，那我認為數學公式也該禁。仍然堅持，特殊數學符號是有必要跟文字一起使用的。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月14日 (三) 19:32 (UTC)[回复]
仍然反對。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月27日 (二) 07:34 (UTC)[回复]

變通提案

以下是小弟的變通提案：

現行條文

颜色及内联图像

条目正文、表格及各類模板（包括信息框）中禁止手动或使用（其他）模板将文字及背景顏色染成非預設颜色。此舉乃是为减轻服务器负担並方便后来编辑者的维护，亦是为方便色盲、色弱或使用黑白版本的读者阅读文字。^[1]

只有在背景顏色可幫助闡釋條目內容，且沒有其他更佳的表達方式時，才可對表格或其他的內文元素加入背景顏色。為了照顧視障或色覺障礙讀者的需要，請避免單獨地使用背景顏色來表達某一含義，而應適當地同時以文字方式表述。為了保障條目的可讀性，請避免使用飽和度過高，或與文字對比度不足的顏色作為表格的背景色。禁止使用CSS代碼對表格背景加入花俏的樣式（如漸層色等）。

同理，条目正文中亦禁止使用内联图像（例如在文字中出現這樣的图像），但在表格及信息框中使用内联图像則可接受。

参考資料

^ 参见WikiProject:鐵道/移除著色文字模板。

提議條文

颜色及内联图像

条目正文、表格及各類模板（包括信息框）中，使用原始碼或其他模板将文字或背景顏色染成非預設颜色，應以幫助闡釋條目內容為第一目的。同時，編者也需要考慮色盲、色弱或使用黑白版本的读者的實際需求。^[1]

除非編者有正當理由，並且能在討論頁自證有理，否則：

同一表格、導航模板或信息框模板只能使用一種邊界色、一種標題欄背景色、一種標題欄文字色，且總共不能超過三種顏色；
請避免單獨地使用背景顏色來表達某一含義，而應適當地同時以文字方式表述；
邊界色、標題背景色、標題文字色之間應該有可視的對比度；
內容背景色和內容文字色之間也應該有可視的對比度；
表格/模板邊界色和內容背景色兩者的飽和度不能太高；
禁止手動將表格或模板的內容文字染成其他顏色。
禁止使用CSS代碼對表格/模板的任何部份加入花俏的樣式（如漸層色等）。

為避免編輯爭議，建議編者在編輯的同時，即在編輯摘要或討論頁中說明上色的理由。

同理，禁止在正文中使用内联图像（例如在文字中出現這樣的图像）、什錦字型或繪文字，但符合以下條件圖像則不在此限：

與正文內容密切相關，不使用就無法（或很難）準確闡釋條目內容；
編者有理由相信電腦無法正常解碼和顯示；
（非強制）有對應Unicode代碼的天然語言字符或專業符號，或者符合知名度要求的人造語言的字符，或者以 $L a T e X$ 製作的科學表述。

此外，在表格及信息框中也可以使用内联图像。

参考資料

^ 参见WikiProject:鐵道/移除著色文字模板。

「一種顏色」的定義為一個RGB值。例：#FFFFFF和#FFFFFE視為兩種顏色。
「飽和度不能太高」定義為紅綠藍三原色中，任何一種原色數值低於EE。

小弟主要編輯體育相關條目，因此在這裏用個和體育相關的例子：編者在編輯某足球隊的球員名單（表格）時使用的標題背景/文字顏色組合，如果和該足球隊隊徽或主場隊服的配色相同，即視為能夠「幫助闡釋條目內容」。反之，如果編者用的是另一支球隊的隊徽或主場隊服的配色，則視為無助於闡釋條目內容，要麼重新上色，要麼改用預設顏色。舉例說明：加拿大國足的主場球衣（守門員除外）的主色調為紅色（#FF0000或更深），球衣字體為白色，而且紅色和白色之間的差距足夠大，因此加拿大國足的導航模板的標題可以染成紅色背景、白色文字。美國國足的主場球衣的主色調為藍色，因此如果把加拿大國足的導航模板的標題染成藍色背景、白色文字，則視為無助於闡釋條目內容。

以上。📕📙📒📗📘📚📖 2021年4月11日 (日) 03:13 (UTC)[回复]

暫時認為閣下的提案影響太多：各類模板應限制至條目導航及各類infobox。另建議禁止任何WCAG 2.0中兩種低於2.0的配色分別用於背景及正文。--1233 （T / C） 2021年4月14日 (三) 02:33 (UTC)[回复]

已修訂為「同一表格、導航模板或信息框模板只能使用一種邊界色、一種標題欄背景色、一種標題欄文字色，且總共不能超過三種顏色」。另外，能否解釋一下怎樣才算「WCAG 2.0中兩種低於2.0的配色」？📕📙📒📗📘📚📖 2021年4月14日 (三) 21:37 (UTC)[回复]

- 拿這個：[7]--1233 （T / C） 2021年4月16日 (五) 08:32 (UTC)[回复]
(－)反对只能使用三種顏色。Template:元素週期表會無法呈現，更不用說縮圖型導航的Template:NavPeriodicTable，此舉同時也導致了之前色弱友善元素週期表顏色配置Template talk:Isotope nav#同位素模板顏色更換全部白討論了，浪費了社群資源。考量到需要區分元素本身特性，以下主題有許多層級需要區分
1. 元素週期表（Template:元素週期表、Template:NavPeriodicTable）
  - 鹼金屬、鹼土金屬、過渡金屬、貧金屬、非金屬、鹵素、稀有氣體.... 等至少7種等級
2. 元素穩定性表（Template talk:Isotope nav）
  - 大量穩定同位素、僅一種穩定同位素、僅有觀測上穩定同位素、最穩定同位素半衰期萬年、半衰期千年、半衰期1年或以下、半衰期以日計、半衰期以時計、半衰期以秒計、目前未發現同位素（如Uue）等至少10種等級
3. 元素分區（Template:元素週期表_(正文)#範例）
  - s區元素、p區元素、d區元素、f區元素、g區元素等至少5種等級
要區分5種以上等級，禁用顏色根本強人所難，無法實行，或實行會導致元素週期表等相關條目無法準確製作示意圖表。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月14日 (三) 19:05 (UTC)—- 五歲抬頭雪菲（☎️·☘️） 2021年4月15日 (四) 02:24 (UTC)[回复]
同時也反對禁用內連圖像。{{缺字}}、或Unicode未收錄符號、特殊的語言（如克林貢語）和特殊數學符號（如en:Coxeter–Dynkin_diagram、{{CDD}}），全是內連圖像，禁用的話，全部都難以或無法描述條目了。特別是en:Coxeter–Dynkin_diagram，根本不可能用文字描述代表一個en:Coxeter–Dynkin_diagram，要求只能放在圖表將導致內文難以描述，必須在內文呈現符號再加以說明，這個如果禁的話，那我認為數學公式也該禁。仍然堅持，特殊數學符號是有必要跟文字一起使用的。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月15日 (四) 02:24 (UTC)[回复]
@A2569875：請閣下留意：
例1：小弟已經特地指定了一個「有正當理由，並且能在討論頁自證有理」的例外條件。閣下以上提到的元素週期表導航模板都屬於「正當理由」，因此不受「最多三種顏色」的限制。

例2：小弟也指定了例外條件。閣下提及的人造語言字母和數學符號都符合例外的條件，因此不受「禁用內連圖像」的限制。至於Unicode未收錄的符號當中哪些應該禁止，哪些應該允許，都可以慢慢討論。能不能請閣下舉例說明：哪些符號Unicode尚未收錄，卻又在某些條目中非用不可？📕📙📒📗📘📚📖 2021年4月15日 (四) 02:51 (UTC)[回复]
關於Unicode尚未收錄符號，需要與文字一同描述的就是特殊數學符號（如上方{{CDD}}）、化學符號、其他科學表示符號，而所有{{缺字}}、特殊語言也是Unicode尚未收錄符號；Unicode尚未收錄的Emoji確實不必在條目正文中出現（甚至已收錄之Emoji都不該）

「編者有理由相信電腦無法正常解碼和顯示」不明確，可能會導致編輯戰，例如某個字原先未被已Unicode收錄，因此使用內連圖像，後來某天被Unicode收錄，然而剛收錄時未被廣泛的字體支援，也許在電腦上看可以正常顯示，然而在iPhone上看都成了豆腐塊，因此使用iPhone的用戶將看起來像豆腐塊的文字回退成內連圖像，而電腦版用戶又將內連圖像回退成在iPhone上看都成了豆腐塊的文字，因而導致編輯戰。例如前陣子剛發命名的幾個化學元素之中文字，在Unicode剛收錄鿫、鿬等字時，發生被改來改去的現象。

CFOP#下兩層（F2L）中「設法在不破壞其他已完成部分，將一柱轉成或。」不使用內連圖像怎麼描述？「設法在不破壞其他已完成部分，將一柱轉成『清楚辨識到可見之兩個面的中心塊與下方塊是相同的顏色，同時，左側最右上方式底面的顏色、上方為左側面的顏色、右方與該面之中心塊同色且角塊右邊的邊塊顏色與左方的角塊同色且方向相同』或『清楚辨識到可減兩個面的中心塊與下方塊是相同的顏色，同時，左側最右上方式做側面中心塊的顏色、上方為右側面的顏色、右方與底面同色且不可見之面之右側面之角塊的頂部顏色與可見面之左側面之中心塊同色』。」這樣的可怕的文字來描述嗎；

那麼這種又要怎麼辦「當方塊變為
時」（{{模板樣式色塊圖}}）→「當方塊變為『方塊下兩層已完成，且頂面顏色在頂面上呈(不用圖片無法表達)形狀時，頂面靠近自己本身的地方是不可見面右側面之中心塊顏色，頂面右側前方（靠近不可見面）兩塊與可見之左側側面同色、頂面左側兩塊與可見之右側側面同色....』時」。(－)反对到時許多條目，不限於魔術方塊都要用可怕的東西描述，WP:太長不看，編者不會想看到一堆廢話，條目失去功能。
關於上述提到的，類似的例子例如俄羅斯方塊，你描述，文字描述用L型，可是他仍有非常多種變體

不使用內連圖像，怎麼準確表達？

Unicode亦有無助於文字表達的字元，用起來跟這樣的图像沒有兩樣，例如Unicode字符列表#特殊、Unicode幾何圖形列表、方塊元素、麻將字元、撲克牌字元（見章節扑克牌#歷史）...等

關於顏色，有的Unicode字元還會自帶顏色，例如Emoji。

Unicode字符列表#盲文圖案：點字該不該禁？「未收錄點字」

※其他關於顏色或Unicode事項待補；會在找到時補充。

以上-- 五歲抬頭雪菲（☎️·☘️） 2021年4月15日 (四) 04:17 (UTC)[回复]

(▲)同上。空氣小貓（留言） 2021年4月15日 (四) 11:27 (UTC)[回复]

魔方问题可以像英语维基百科那样用右侧图像，或者像论文那样<gallery />加“如图1”。一图胜千言，但没看出图像非要内联的理由。而且

、

这三个内连例子真心一点都不大方，图片小小、看着眼晕；图片优势没发挥出来不说，还搞到正文稀稀拉拉的。至于Unicode字符列表这种，特殊字符独占单元格的环境，我认为不算内连。--洛普利宁 2021年4月15日 (四) 17:50 (UTC)[回复]

魔術方塊可能不是個很好的例子，那麼我換個例子基礎摺法、索馬立方（en:Soma_cube），這也難以純粹文字描述。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月15日 (四) 21:40 (UTC)[回复]

同意Lopullinen的看法。不一定要用內聯圖像，可以用右側圖像或者圖片庫。例如《索馬立方》可以改用如下的圖片庫：

《索馬立方》圖片庫

第一片，或稱為V。
第二片，或稱為L：三個立方體排成一列，左下方加一個立方體。
第三片，或稱為T：三個立方體排成一列，中間下方加一個立方體。
第四片，或稱為Z：二個立方體排成一列，上面是另外二個立方體，往右排一格。

第五片，或稱為A：V型的三立方體平放，另一個立方體放在順時針的第一個立方體上方，有立體的不對稱性。
第六片，或稱為B：V型的三立方體平放，另一個立方體放在逆時針的第一個立方體上方，有立體不對稱性。
第七片，或稱為P：V型的三立方體平放，另一個立方體放在轉折的立方體上方的第一個，有立體對稱性。

這樣就既不需要使用內聯圖像，也不需要單純依賴文字描述。📕📙📒📗📘📚📖 2021年4月15日 (四) 22:14 (UTC)[回复]

仍然堅持會有需要把文字和圖片放在一起的情況，摺紙的你們還沒回應，我將會繼續尋找，補充一個找了一整晚的
- en:PlayStation (console)#Marketing success：「The console was marketed with advertising slogans stylised as "LIVE IN YUR WRLD. PLY IN URS" and "U R NOT E" (red E).」
- en:Ayumi_Hamasaki#Footnotes（圖片在英文區，中文區暫時無法顯示，請自行前往英文維基查看）：「This is the symbol: File:Ayumi Hamasaki A Logo.png. It is used either as a substitute for the letter a or to represent Hamasaki's name. The titles of six albums, Rainbow, A Best, A Ballads, A Best 2 -White-, A Best 2 -Black-, and A Complete use this symbol; the titles of these albums appearing as RFile:Ayumi Hamasaki A Logo.pngINBOW, File:Ayumi Hamasaki A Logo.png Best, File:Ayumi Hamasaki A Logo.png Ballads, File:Ayumi Hamasaki A Logo.png Best 2 -White-, File:Ayumi Hamasaki A Logo.png Best 2 -Black-, and File:Ayumi Hamasaki A Logo.png Complete.」
- en:Arabic_maqam#Ajnas：「Sikah (سيكاه‎) trichord, starting on E.」
- 天文學臨時編號：「例如(1) 穀神星被賦予鐮刀的圖形()、(2) 智神星是菱形和一個十字()、(3) 婚神星起初是維納斯的鏡子之上加上一顆恆星 ()，稍後簡化成一顆星加在十字之上()，還有(4) 灶神星是宗教祭壇上的火焰()」
- 彗星：「彗星的天文學符號是，由一個小圓盤和三根如頭髮突起的短線段組成」
- 中華民國國語：「1932年教育部在「編定《國音常用字彙》特組會議」時決定，為了便利說明，添補一個注音符號「ㄭ」（），作為「ㄓㄔㄕㄖㄗㄘㄙ」七個聲母單獨成音節時的省略韻母。另外有三個注音符號ㆭ（-ng）、ㆬ（-m）、（-n），用作解釋聲隨韻母（ㄢ、ㄣ、ㄤ、ㄥ）時使用，的字形是ㄋ多加一筆直豎，ㄤ解作ㄚ+ㆭ、ㄥ解成ㄜ+ㆭ、ㄢ為ㄚ+、ㄣ為ㄜ+；同理，複韻母ㄞ解為ㄚ+ㄧ、ㄠ為ㄚ+ㄨ。ㆭ、ㆬ、絕少單獨使用，「嗯」常唸作「˙ㄣ」，也有人唸成「˙」」

(將會陸續補充)

以上-- 五歲抬頭雪菲（☎️·☘️） 2021年4月16日 (五) 05:23 (UTC)[回复]

(～)補充另外，關於「

」的描述，我認為應該要這樣「方塊下兩層已完成，且頂面顏色在頂面上呈

形狀時....」不然圖像還要引用旁邊另外圖像，真的很詭異。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月16日 (五) 05:40 (UTC)[回复]

CFOP#下兩層（F2L）可以改成如下形式：

「設法在不破壞其他已完成部分，將一柱轉成以下兩種形式之一（圖1.1和圖1.2）：」

圖1.1	圖1.2

這樣一來，魔方的圖案想再放大些都不怕影響排版。
摺紙的案例和索馬立方的案例一樣，可以製作表格或圖片庫，不需使用內聯圖像。
天文學符號完全可以在表格或者Infobox裏面用，不需用作內聯圖像。
中華民國國語那個注音符號，以及那個阿拉伯樂譜符號，都已經符合「與正文內容密切相關，不使用就無法準確闡釋條目內容」的例外條件。
至於PlayStation和濱崎步的案例簡直就是邊緣得不能再邊緣了。PlayStation的那句營銷口號，完全可以上傳一張自製圖片來表示，反正像這種簡單的幾何符號，是怎麼都達不到原創性門檻的。濱崎步的案例已經涉嫌過量使用非自由圖像，違反《WP:NFCC#3》了。

另：@Lopullinen、1233：小弟新增了無正當理由禁止使用什錦字型或繪文字的條文，請回應。📕📙📒📗📘📚📖 2021年4月16日 (五) 06:19 (UTC)[回复]

內文其實禁止更改字體的，不過無意見。--1233 （T / C） 2021年4月16日 (五) 08:11 (UTC)[回复]

(：)回應我認為索馬立方、摺紙與正文密切相關。天文符號其他例子例如電路符號、化學特殊符號、化學結構式（有苯環的）生物學符號，我不建議在旁邊放成表格，一堆一個小符號整理成表格非常詭異。以及「
：頂面顏色在頂面上呈形狀」的亦與正文密切相關。同時，整個連純文字也包成圖片放旁邊表格將會有「無法複製其中文字」的缺點。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月16日 (五) 06:27 (UTC)[回复]

小整理一下，以便針對點討論
- 已解決的問題
  - 自身有獨特排版，且為學術界慣例，又需要顏色表達之表格
    - 元素週期表的背景色。（無法用排版取代，根據討論任意變更元素週期表的排版將構成WP:原創研究）
  - 無法使用現有文字代替的符號（打不出來的字，或者非自然語言表達範疇之記號）
    - 未收錄漢字（如{{缺字}}）
    - 數學符號（如{{CDD}}）
    - 樂譜記號
    - 特殊的語言
- 未解決問題
  - 可以用排版代替顏色的表
    - 地質年代表的背景色。
    - 生物保育狀態的背景色。
  - 可以使用現有文字代替的符號
    - 天文符號
    - 化學結構式
  - 具表意功能圖示使用時機
    - 如摺紙圖示
    - 文字不易描述的瑣碎形狀圖示(一句話出現多種時，使用表格反而雜亂)
    - Emoji、繪文字
    - 什錦符號
  - 特殊標語口號
    - 「LIVE IN YUR WRLD. PLY IN URS」（整個做成圖片將會導致文字複製困難）
    - $L a T e X$
以上-- 五歲抬頭雪菲（☎️·☘️） 2021年4月16日 (五) 07:06 (UTC)[回复]

在我看來明文限制使用顏色或內文圖片會造成很多麻煩，更不應該直接限制着色，應當按照情況逐例處理；例如在有用戶提出更好減少使用顏色的情況下，若內容不造成明顯閱讀困難就應儘量以顏色較少的方式處理（即指排版妥當；不應以「比較那個比較方便閱讀」為準則，只要整體不造成閱讀困難即可）。列表條目中適當使用顏色協助用戶進行分類，限制用色比限制着色更實際。--LuciferianThomas．留言 2021年4月16日 (五) 09:41 (UTC)[回复]

「地質年代表的背景色」和「生物保育狀態的背景色」我在上面已經說過符合例外條件，因此不屬於「未解決問題」。嚴格來說，俄羅斯方塊的圖像也屬於「與正文內容密切相關，不使用就無法準確闡釋條目內容」，只是編者有責任證明非使用內聯圖像不可。
我加入了或者以 $L a T e X$ 製作的科學表述，以包括數學公式和化學方程式等。
我粗略閱讀了《烴》、《苯》等化學條目，裏面的圖像都不算「內聯圖像」。「內聯圖像」是指插入段落之內，文字之間的圖像。但這些條目當中的圖像都是用在段落之間，而非段落之內，因此不符合「內聯圖像」的定義。
天文符號可以在表格或Infobox裏使用，不需使用內聯圖像。
「LIVE IN YUR WRLD. PLY IN URS」這種標語是不是非加入不可？「導致文字複製困難」似乎暗示閣下打算複製粘貼到其他條目，但除了PS條目本身以外，還有哪些條目非有這條標語不可？
@LuciferianThomas：限制著色是為了防止出現像某個IP對《追夢 Do Re Mi》瘋狂著色的情況再次出現。而我提出「一種邊界色、一種標題欄背景色、一種標題欄文字色，除非能自證有理」是為了方便執行，盡可能壓制遊戲維基規則的空間。另外，我在上面的提案也有限制用色的條文：「背景色飽和度不能太高」。

歡迎回應。📕📙📒📗📘📚📖 2021年4月16日 (五) 15:29 (UTC)[回复]

關於複製，我指的是會困擾讀者，讀者將無法或難以複製該文字。維基百科不應搞得像那種讓讀者複製不了東西的神秘部落格，且讀者理應要能夠方便地複製「LIVE IN YUR WRLD. PLY IN URS」以便到其他地方利用或查詢其他相關資料，整個包成圖像你是要讀者去研究影像辨識和機器視覺？？；另外「有對應Unicode代碼」en:Coxeter–Dynkin_diagram、{{CDD}}沒有對應unicode 代碼， $L a T e X$ 也不支援，且由於其抽象性，難以用文字說明代替。另外我相信應該還有一些數學公式或符號不被unicode與 $L a T e X$ 支援，但是需要與文字一同描述。—- 五歲抬頭雪菲（☎️·☘️） 2021年4月16日 (五) 15:39 (UTC)[回复]

總歸一句話，複雜的限制只會更容易被忽略，再加上你遇到例外就加上去、加上去，最後限制越來越多。至少我沒有這麼有耐性看完這些限制，就算看完也好，我也不能確保我不會被混淆。你提議修正條文，就有必要將條文修到完整、易讀的狀態，除非你讓這些條文更加簡潔，否則我(－)反对的立場不會改變。空氣小貓（留言） 2021年4月16日 (五) 16:43 (UTC)[回复]

不限制著色，但漸層應明文禁制；另覺得表格什麼的不是不能上色，但必須整個條目一致就是了。--LuciferianThomas．留言 2021年4月16日 (五) 18:07 (UTC)[回复]

我认为维基百科不应搞得花花绿绿的像粉丝部落格。如果「LIVE IN Y

UR W

RLD. PL

Y IN

URS」包装成图像读者能理解，那就不应该使用内连图像；再说这东西复制出来居然是“LIVE IN YOUR WORLD. PLAY IN OURS”，圈叉三角呢，打哑谜？况且stylized包括大小写、颜色、文字大小等等元素，其主要作用也是视觉冲击，所以本来就更适合用图片表示（再用图注说明，其中四个字母置换成为PlayStation的圈、叉、正方、三角标志）。总之简单一句话：图像可以用，但不要放在正文；如果想放在正文，请想想能不能单独提出来：如果提不出来，再想想所谓的“不用图片不行”整句话是否举例过细，对维基百科这种通用百科并无必要；如果真的很重要，业界也常常这样用，那再讨论要不要内连。科学类条目可以制定自己的格式手册，决定哪些图片可以在兼顾排版的情况下，视同文字在正文中使用。但对于大多数条目，要让编者（特别是新编者）从大方向感觉到，维基百科不鼓励使用内连图像。同时也要鼓励编者锻炼文字表达能力：编者作为爱好者可能以为图片很直观，但非圈内读者很可能根本get不到点。（

这个例子要是不配文字，花花绿绿的我还真不知道想表达最下面两层已完成。）--洛普利宁 2021年4月16日 (五) 18:34 (UTC)[回复]

顏色和附圖塞內文概念上是一樣的，上面列的都是附圖案例，顏色例如：

电子游戏分级制度：「此版适龄提示于2019年由中宣部和网游道德委员会设置。将游戏分为 6+ ， 12+ ， 16+ 和 18+ 四等。」

在我看來，許多狀況，有加附圖或顏色，比起沒加附圖或顏色，「更有助於幫助讀者了解主題」。反而沒有上面說的那麼嚴重。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月17日 (六) 07:51 (UTC)[回复]

@A2569875：您说的这篇条目，正好证明内文颜色不必要乃至多余。您举例的下一段就附了个参考文献；此文献是“8+ (green), 12+ (blue), and 16+ (yellow)”这样用纯文字描述的，而显然编者正确理解了文字（先不讨论绿色用#5CB531是不是原创研究）。由此可见，使用纯文字也能起到等价的效果。另一方面，禁止内连颜色不是禁止使用颜色；正确的方法是这样，用侧边图像大大方方地表示。所以我没看出来，直接给文字上色什么时候成了唯一手段。在我看来，图片放到侧边并配上图注详述、正文做一些大方向上的解释，比起使用不知所以的内联图像或颜色，更有助于读者理解主题。PS：感谢提醒，我把这条目正文中的颜色全部移除了（最上面那个是表格的图示，不属于内连的范畴；下面全都在东施效颦）。--洛普利宁 2021年4月17日 (六) 17:42 (UTC)[回复]

關於顏色，我覺得沒必要限死三種顏色。{{中国历史}}目前的配色可以追溯到Special:Diff/432308，距今近16年，幾無异议。只要色盲色弱人士能看得清，颜色又不会太抢眼就没关系。 ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月18日 (日) 13:40 (UTC)[回复]
如果不想讓例子增加到這麼多的話，那就是換個方向，讓某些變成不符合（不過看下來，不管是從符合還是不符合，兩邊內容都很多）。我只希望大家在追求顏色自由的同時也能考慮顏色自由亂象，不能因為自己的方便造成別人的困擾。 --Loving You Is A Losing Game 2021年4月20日 (二) 07:01 (UTC)[回复]

设计一个制度解决部分速删模板挂不上去的页面的删除问题

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:快速删除方针。

参见Wikipedia:互助客栈/求助/存档/2021年4月#请帮忙删除 User:Tranve/工坊/workshop.json，像 JSON 和 Module: 名字空间的页面，速删模板挂不上去。希望可以在方针制度层面解决这个问题。--Tranve (✉) 2021年4月5日 (一) 13:07 (UTC)[回复]

cc@蟲蟲飛、Xiplus、Sunny00217 --Tranve (✉) 2021年4月5日 (一) 13:09 (UTC)[回复]

說到這個，才想去WT:TW提案讓.json的速刪能不能轉到AFD之類的呢xxdd-- Sunny00217 2021年4月5日 (一) 13:43 (UTC)[回复]

注：可参考英文维基方针。--Tranve (✉) 2021年4月10日 (六) 06:30 (UTC)[回复]

@Tranve：英文維基的en:Module:Module_wikitext可以讓WP:TW支援（見en:MediaWiki:Gadget-twinklespeedy.js），會能很方便地像掛模板那樣，手機也能操作；但是呢！！(※)注意英文維基的en:Module:Module_wikitext在中文維基無效！Module:Module_wikitext，見測試Special:PermaLink/65279867。如果需要引入，可能需要請介面管理員修改介面。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月20日 (二) 03:22 (UTC)[回复]

同上意见。-门可罗雀的霧島診所_{三天打鱼两天晒网}^{神社的羽毛飘啊飘} 2021年4月18日 (日) 03:54 (UTC)[回复]

(※)注意:如果TW可以像封禁選項讓管理員點選「提刪請求參見討論頁」還好，否則要管理員輸入詳細的提刪位置，手機不好操作。而且被刪除的頁面如果沒有任何提刪模板，而且公開的日誌中又未能清楚查看誰在哪裏提出刪除，對操作管理員來說都容易有爭議；刪除的操作不能馬虎，操作不清楚，時隔多天後，如果連操作管理員也忘了用戶在哪裏提出請求，而頁面又沒有提刪模板，對管理員會很不利，可以成為有心人質疑管理員操作的藉口，因此我比較同意Sunny00217建議，或者直接找管理員，或者在用戶自己的討論頁ping管理員請求刪除，管理員刪除時加個編輯差異，這樣才好保障管理員以免陷入不必要的爭議，而且安憶現在已經造了一個編輯差異複製黏貼的小工具，很好用。--蟲蟲飛♡♡→♡℃※留言 2021年4月18日 (日) 04:19 (UTC)[回复]

@蟲蟲飛：我不同意阁下的观点。首先，如果一个快速删除请求仅仅因为删除的页面是一个特殊页面而需要单独联络管理员，这已经违背了快速删除请求“快速”的特质；其次，如果需要到 WP:AFD 去汇报的话，相当于破坏了 AFD 的功能（AFD 原本应用于存废讨论），会导致站务管理混乱。我大致上同意仿照英文维基的方针。目前的技术问题先看看能不能联系管理员解决，如果不能解决的话，再尝试您的方案吧。请问如何联系管理员？--Tranve (✉) 2021年4月20日 (二) 10:41 (UTC)[回复]

(？)疑問:1.全保護的頁面通常是很重要的，有頻繁刪除的需要嗎？而且過去五年，我只看到您一個人有這方面的提刪需求和困難。2.走去找管理員討論頁討頁請求很困難嗎？如果覺得有困難，您在自己討論頁ping在線管理員，請求刪除，有甚麼困難？--蟲蟲飛♡♡→♡℃※留言 2021年4月20日 (二) 13:29 (UTC)[回复]

(：)回應：我在章节标题中已经写明了：我希望这一过程制度化。快速删除的目的是“加快处理显然不合适的页面或文件，省去存废讨论的时间”，而我上面的情形完全符合这个定义，理应走快速删除方针删除，奈何方针不完善啊 :( 其次，这个问题我已经遇到了两次：一次是 JSON 页面挂不上速删模板，另一次是自己的模块页面也挂不上删除模板，不存在全保护的问题。--Tranve (✉) 2021年4月21日 (三) 12:26 (UTC)[回复]

@Tranve：en:Module:Module_wikitext關於在中文維基無效Module:Module_wikitext的問題，導致en:MediaWiki:Gadget-twinklespeedy.js中文維基用不了的問題，請找WP:介面管理員。例如User:安忆是介面管理員。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月20日 (二) 11:17 (UTC)[回复]

@A2569875：没来得及细看（大致看了下关键字）。请问具体需要我的什么帮助？如果是Module的话需要模板编辑员才行。--安忆 ^Talk 2021年4月20日 (二) 14:28 (UTC)[回复]

@安忆：看了一下追查英文維基相關功能的添加紀錄（關於Module:Module_wikitext），為en:Special:Diff/977236565，這個模板编辑员也無法，只能管理員；介面管理員能做的應該是中文維基的en:Special:Diff/977236565完成後，參照英文維基en:MediaWiki:Scribunto-doc-page-does-not-exist修改介面。 @Tranve：涉及如此複雜修該應需要公示。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月20日 (二) 14:36 (UTC)[回复]

@A2569875：多谢！但是我不熟悉互助客栈，请问如何才能公示呢？--Tranve (✉) 2021年4月21日 (三) 12:28 (UTC)[回复]

@Tranve：需先獲得共識才能公示WP:7DAYS-- 五歲抬頭雪菲（☎️·☘️） 2021年4月23日 (五) 19:27 (UTC)[回复]

(－)反对:直接找管理員幫忙就解決了問題，沒必要小題大作。--蟲蟲飛♡♡→♡℃※留言 2021年4月24日 (六) 04:07 (UTC)[回复]

(：)回應：

我之前已经两次回复了您的问题（第一次、第二次），为什么您还是重复相同内容？
当前讨论的议题（制度化）的目的不是“小题大作”，而是“大题小作”，使复杂问题简单化，方便处理。方针制度的存在就是为了通过走流程从而简化一种类型的问题的处理。
退一万步讲，如果真的按照阁下所言，那么连快速删除方针都可以不要了，有页面要删可以直接找管理员帮忙，“没必要小题大做”。

以上。--Tranve (✉) 2021年4月24日 (六) 09:05 (UTC)[回复]

(：)回應

您的兩次回應都未能有效回應我提到的疑慮，請重看我的留言。
您的問題根本就不是問題，沒必要建立所謂“制度”，而且所謂“制度”也帶出了新的問題，詳見我上面的留言。
o1，g10是可以直接找管理員，其他的須要通知頁面建立人，未見現行機制有甚麼問題

以上。--蟲蟲飛♡♡→♡℃※留言 2021年4月24日 (六) 09:21 (UTC)[回复]

逐条(：)回應如下：

关于“Twinkle相关功能”
此类问题应该在方针确定下来后联系 Twinkle 维护者解决。应该没有特别大的技术问题。
关于“管理员陷入不必要的争议”
如果快速删除方针中加入了对特殊页面的相关条文，管理员在删除的时候完全可以援引快速删除方针，之后想要查证，其他管理员直接方针中所写内容去查删除记录（比如查对应讨论页已删除的贡献），不会陷入不必要的争议。另外，为什么会“陷管理员与不义”？这种时候不应该假定善意吗？
关于“快速删除全保护页面”
我想解决的问题中不包括全保护页面的速删请求。
“您的问题根本就不是问题”“o1，g10是可以直接找管理员”
为什么不是呢？自己创建的 JSON 和模块名字空间页面理应走 O1 删除，结果模板挂不上去。

我把快速删除方针从头到尾翻了个遍，都没有找到“o1，g10可以直接找管理员”相关字样。既然这样，谈到这个又有什么意义呢？

总之，我提议将相关内容添加到方针的理由很简单：方针中没有涵盖我遇到的这种特殊情况的处理方法。别人有没有遇到同样问题，有多少人遇到，我不清楚。但是我遇到了，并且如此麻烦的处理过程让我觉得很意外。既然这样，问题就存在了。存在了就应该被解决。

以上。--Tranve (✉) 2021年4月25日 (日) 12:17 (UTC)[回复]

(：)回應:您提到理據完全不成立。您把一個很簡單的問題複雜化，像您提刪User:Tranve/工坊/workshop.json不是很簡單嗎？您不願走去找管理員，您可以在自己用戶討論頁ping管理員，很容易就解決了問題。您在討論頁提刪，但討論頁又因為g15被刪去，被刪去的頁面又沒有提刪模板，很容易令人質疑管理員在沒有提刪的情況下刪去頁面。--蟲蟲飛♡♡→♡℃※留言 2021年4月25日 (日) 12:34 (UTC)[回复]

管理员不是机器人而是人。我觉得有足够经验的管理员应该能够意识到页面是 JSON 页，速删模板挂不上去的。更多讨论请移步下面，谢谢。--Tranve (✉) 2021年4月25日 (日) 12:52 (UTC)[回复]

現在就只有您一個人有這個問題，其他人找管理員幫忙完全沒有問題，而且說了很多遍，管理員刪除頁面一定要清晰註明誰在哪裏提刪頁面，這些操作不能馬虎。--蟲蟲飛♡♡→♡℃※留言 2021年4月25日 (日) 13:42 (UTC)[回复]

如果不用专门去找一个管理员删除，不是更好？--百無一用是書生 (☎) 2021年4月28日 (三) 02:53 (UTC)[回复]

(！)意見仍然想提議引入能在Module頁掛模板的英文維基功能，使TW工具能像英文維基那樣直接自動掛模板。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月24日 (六) 09:38 (UTC)[回复]

TW如果能配合加註提刪位置及提刪者還好，否則就是陷管理員於不義。--蟲蟲飛♡♡→♡℃※留言 2021年4月24日 (六) 09:42 (UTC)[回复]
- 可以但是需要修改介面引入英文維基相關模塊。—- 五歲抬頭雪菲（☎️·☘️） 2021年4月24日 (六) 12:13 (UTC)[回复]

就规范部分特殊页面的删除方式征求社群建议

现提议在Wikipedia:快速删除方针中“管理员操作注意事项”前增加一节，标题为“放置快速删除模板时的注意事项”，正文内容如下：

現行條文

…… 管理员操作注意事项 ……

提議條文

…… 放置快速删除模板时的注意事项部分页面因为技术限制，在放置快速删除模板时需要遵从特定方式。

JSON页面：请在该页面对应的讨论页放置快速删除模板，并在原本的删除理由之后附加“请删除本讨论页对应的主页面”字样。
范例：{{d|快速删除理由|请删除本讨论页对应的主页面}}
位于模块名字空间的页面（文档页面除外）：如果该页面需要通过快速删除请求删除，请使用以下语法。
require('Module:Module wikitext')._addText('{{d|快速删除理由}}')
CSS（包括“已过滤的CSS”）和JavaScript页面：请将快速删除模板包含在注释中，如下所示。
/* {{d|快速删除理由}} */

管理员操作注意事项 ……

为了落实以上方针，需要解决的问题有：

让中文维基百科支持 Module:Module wikitext 模块。
让 Twinkle 实现相关功能的自动化。

现征求社群建议以达成共识。--Tranve (✉) 2021年4月25日 (日) 12:46 (UTC)[回复]

(－)反对:TW如果能配合加註提刪位置及提刪者還好，否則讓管理員的刪除操作欠缺提刪模板，令人誤以為管理員在沒有提刪的情況下刪去頁面，增加不必要的爭議。建議提刪相關頁面直接找管理員處理，或者在用戶討論頁ping管理員，具體操作如User:Tranve/工坊/workshop.json。此外，這種沒提刪模板的刪除操作，連其他復檢刪除頁面的管理員也容易有誤會，因為不會有人去檢查不同的已刪除的子頁面及討論頁，像之前提案人在一個頁面的子頁面提刪，有些頁面有無數子頁面，就算管理員也無法確定具體的提刪位置和提刪者，這就容易引起不必要的誤會和爭議。刪除操作是很嚴肅的事，所有刪除操作都應讓其他管理員容易復檢刪除原由，不能馬虎。--蟲蟲飛♡♡→♡℃※留言 2021年4月25日 (日) 13:36 (UTC)[回复]

(：)回應@蟲蟲飛：首先，我们现在讨论的是速删方针，不是提删方针。如果速删有疑虑，不应该在删除页面之前解决吗？为什么需要复检？其次，Twinkle 相关问题请联系其维护者，与本站的方针无关。--Tranve (✉) 2021年4月26日 (一) 10:26 (UTC)[回复]

不論速刪，還是afd提刪，刪除操作都應非常審慎，而且不只刪除操作，任何操作都會有其他管理員復檢，確保操作沒問題。您的提案是增加了管理員操作及復檢操作的難處，而且您不是沒有更好的解決方法，只是您個人不願去做。例如，您可以在任何獨立於被刪頁面中提出速刪，或者您直接去管理員討論頁留言，但您就不願，把非常簡單的問題複雜化，然後帶出管理員操作上的爭議問題。--蟲蟲飛♡♡→♡℃※留言 2021年4月26日 (一) 10:43 (UTC)[回复]

(※)注意:管理員刪去頁面後，其他管理員都會覆檢究竟管理員的刪除操作是經過其他用戶提刪的程序，還是管理員濫權，直接刪頁面；提案就是增加了其他管理員覆檢刪除操作的難處。-蟲蟲飛♡♡→♡℃※留言 2021年4月26日 (一) 11:16 (UTC)[回复]

(※)注意請蟲蟲飛不要只顧著反對，Antigng 已經著手在IRCTG互聯群開發能直接在json 上掛模板的模組。—- 五歲抬頭雪菲（☎️·☘️） 2021年4月26日 (一) 12:17 (UTC)[回复]

既然技術上解決了問題，就沒必要改方針了。--蟲蟲飛♡♡→♡℃※留言 2021年4月27日 (二) 12:17 (UTC)[回复]
- (：)回應@蟲蟲飛：技术上要解决的问题和设立方针的问题是两个不同的问题，所以您的理由并不成立。“技术上要解决的问题”是因为“设立方针的问题”才存在的，这个依赖关系可以理解吗？--Tranve (✉) 2021年4月28日 (三) 12:42 (UTC)[回复]
第二、三點不改方針，也可以做，修訂方針就沒意義。第一點，您是想通過方針強逼管理員讓您在子頁面或討論頁提刪時，須註明提刪原由，但又沒有TW配合，這是增加管理員操作時的難處。現在已經很少管理員願意處理站務，您的提案是想讓更多管理員不願處理站務。--蟲蟲飛♡♡→♡℃※留言 2021年4月28日 (三) 12:58 (UTC)[回复]

在技术上敲定解决方案之前（见下一章节讨论），以上方针的修改先搁置。--Tranve (✉) 2021年4月30日 (五) 10:40 (UTC)[回复]

引入能夠在特殊頁面掛模板的模組

於Phabricator查看
編號T235798的工單

為了解決模板掛不上去或者TW不支持的問題，因此提議引入以下模組

Module掛模板問題
引入en:Module:Module wikitext並提出編輯請求以編輯相關高風險模板與介面讓中文維基支持
json或css或js掛模板問題
已開發完畢，待社群共識後才會提請編輯請求，見圖

此法如果引入成功，完全可以直接在原頁面申請速刪，不存在上方提到的任何疑慮！如果這個建起來，提刪過程會「跟提刪條目一模一樣」，不會陷管理員於不義。對應要提刪的頁面會有提刪模板，不會讓管理員的刪除操作欠缺提刪模板，不存在上方提到的任何疑慮！—- 五歲抬頭雪菲（☎️·☘️） 2021年4月26日 (一) 18:51 (UTC)[回复]

没有什么不好的。--安忆 ^Talk 2021年4月27日 (二) 11:47 (UTC)[回复]

非常感謝幫忙！能在原頁面掛速刪模板，這樣就可以解決管理員刪去頁面後，其他管理員無法復檢刪除操作的問題，否則其他管理員就無法確定管理員是否濫權，在沒有提刪的情況下，直接刪了頁面，這是屬於嚴重濫權，因此在頁面能留下速刪模板是非常重要的，這件事不能馬虎。此外，既然技術上解決了問題，就沒必要改方針了。--蟲蟲飛♡♡→♡℃※留言 2021年4月27日 (二) 12:15 (UTC)[回复]

目前辦理狀況：等待工單phab:T235798佈署。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月27日 (二) 14:58 (UTC)[回复]

項目	辦理狀況	需編輯的頁面	頁面patch	效果預覽
Module	已完成測試	Module:Module wikitext	（已佈署）	Module:沙盒/a2569875/Test4
		Module:Documentation	Module:Documentation/sandbox
		MediaWiki:Scribunto-doc-page-does-not-exist	User:A25...-does-not-exist （需要語言變種微調）

JS、CSS	已完成測試	Module:Special wikitext	（已佈署）	留言（WP:TG1）、互連群圖床
JS、CSS	已完成測試	MediaWiki:Clearyourcache	User:A25...yourcache （需要語言變種微調）

JSON	等待工單phab:T235798佈署	phab:T235798	gerrit:r/c/543934

本地已經準備完畢的部分（Module、JS、CSS）可考慮先行公示並佈署。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月27日 (二) 15:33 (UTC)[回复]
說明：phab:T235798要解決的問題是，目前JSON可以用技術手段掛模板，且頁面中也確實能夠顯示掛上模板後的速刪分類
（見測試圖留言（WP:TG1）、互連群圖床），然而頁面分類的資料庫暫時無法更新資料，
所以雖然模板能掛了，但還是需要手動提醒/或找一個管理員，告知頁面需要刪除，
這樣@蟲蟲飛：您會不會又無法接受了？當然，這個問題可以修復，只是phab:T235798不明原因擱置中（_{目前看起來是代碼合併衝突、需要更新}），可能需要一點時間，當phab:T235798佈署完畢後就會完全沒有這問題了。在這之前，有以下(＆)建議：
※目前的(＆)建議是，在phab:T235798工單完工之前，先把沒問題的JS、CSS、Module 公示通過在本地佈署_{（_{因為JSON掛模板工能本地需要修改的地方與JS、CSS、Module相同，當phab供單完工後，將會立即生效}）}，而在JSON全域佈署前，JSON先暫時維持原本的提刪方式（模板能掛，但頁面分類的資料庫暫時不會正常更新，看要不要方針註明一下，不是技術限制，而是phab工單工作中..._{（_{最近課業繁忙，比較沒有時間去提供後台php代碼，可能無法像之前專題空間那像迅速完成}，而已經OK的JS、CSS、Module我覺得可以先行佈署）}）。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月28日 (三) 11:41 (UTC)[回复]

(※)注意:頁面能掛速刪模板就好了，就算不能掛模板，走去找管理員留言提刪，安憶那個編輯差異的小工具很好用，可以很容易就在刪除日誌中註明提刪的原由，復檢的管理員也能輕易瞭解刪除操作的管理員有沒有濫權，有沒有在沒提刪的情況下刪去頁面。沒有提刪，直接刪去頁面屬於嚴重濫權，因此刪除操作的處理一定要很審慎。此外，方針沒必要改，這些操作屬於技術性問題，與方針無關，而且現行方針已經很清楚。--蟲蟲飛♡♡→♡℃※留言 2021年4月28日 (三) 12:00 (UTC)[回复]

公示：對於技術相關的反對意見已排除，將Module、JS、CSS掛模板方案 公示7日（通過後JSON其實也能掛模板，但頁面分類暫時無法更新，需要phab:T235798）根據結論，暫時不修改方針。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月28日 (三) 12:15 (UTC)[回复]

如果提刪模板不能放在目標頁面，就不能放在子頁面或者討論頁，因為復檢的管理員如果看到被刪的頁面沒提刪模板，沒有人會檢查所有子頁面及討論頁，然後就容易誤會管理員在沒有提刪的情況下直接刪去頁面。--蟲蟲飛♡♡→♡℃※留言 2021年4月28日 (三) 12:30 (UTC)[回复]

@蟲蟲飛：上面的技術如果公示通過了CSS,JS,Module 才可以在原頁面掛模板，JSON也可以在原頁面掛模板，phab:T235798沒好只是頁面分類暫時不會歸檔。—- 五歲抬頭雪菲（☎️·☘️） 2021年4月28日 (三) 12:53 (UTC)[回复]

非常感謝說明，但建議刪去重複的語句，太多重複語句會影響其他人閱讀。--蟲蟲飛♡♡→♡℃※留言 2021年4月28日 (三) 13:14 (UTC)[回复]
- 感謝提醒，已刪去。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月29日 (四) 08:04 (UTC)[回复]

(～)補充模板掛法說明，「可以在原本的頁面掛」，但需要符合對應頁面的頁面內容模型，語法如下所示，可討論是否需要補充進指引（c.c. @蟲蟲飛：）：
- JSON页面：在最外層的{...}之內加入代碼：（上述模塊引入後，JSON页面雖能顯示模板，但分類暫時不會自動歸檔，需等待phab:T235798佈署）
  "_addText":"{{Delete|快速删除理由}}"
- Array形式的JSON页面：在最外層的[...]之內加入代碼：（如頁面開頭與結尾符號是中括號時[...]）
  {"_addText":"{{Delete|快速删除理由}}"}
- 位于模块名字空间的页面（文档页面除外）：加入代碼：
  require('Module:Module wikitext')._addText('{{Delete|快速删除理由}}')
- CSS页面：加入代碼：
  ._addText{ content:"{{Delete|快速删除理由}}"; }
- JavaScript页面：加入代碼：
  var _addText="{{Delete|快速删除理由}}";
同時提供給WP:TW開發者參考。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月29日 (四) 08:33 (UTC)[回复]
- (～)補充en:special:diff/978461935英文維基對應功能的WP:TW代碼實現請參考此處。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月29日 (四) 08:39 (UTC)[回复]
eslint: _addText沒被定義-- Sunny00217 2021年4月30日 (五) 07:34 (UTC)[回复]
- @Sunny00217：那這樣不就得了？var _addText="{{Delete|快速删除理由}}";-- 五歲抬頭雪菲（☎️·☘️） 2021年4月30日 (五) 07:50 (UTC)[回复]
  @A2569875：只是想到覺得好笑貼上去而已（因此也沒 ping），實際上不會有人要提刪了還用 eslint 的 xxdd-- Sunny00217 2021年4月30日 (五) 12:29 (UTC)[回复]
  
  @A2569875：只是想到覺得好笑貼上去而已（因此也沒 ping），實際上不會有人要提刪了還用 eslint 的 xxdd-- Sunny00217 2021年4月30日 (五) 12:30 (UTC)[回复]
- 嗯。这个做法也不错，或许可以解决虫虫飞的顾虑。我到上面修改一下方针文本。--Tranve (✉) 2021年4月30日 (五) 10:30 (UTC)[回复]
  - (＆)建議@Tranve：要改方針建議先等技術通過再說，不然一起推行只會一起卡死。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月30日 (五) 10:32 (UTC)[回复]
    - 感谢提醒！您的方案我再看了一下，对于 JSON 页和模块页的处理我没有意见，但是 CSS 的处理方式是不是有点 dirty，这样相当于整了一个不存在的_addText class，JavaScript 我认为也有这样的问题。万一有脚本要用到 _addText 变量呢？另外，这个变量一定要是全局变量吗？我的提案，也就是在页面最开头的注释里头放进{{d}}模板的做法，也是可行的。--Tranve (✉) 2021年4月30日 (五) 10:37 (UTC)[回复]
      - @Tranve：完全沒有影響，也不認為有任何問題，加那樣只是讓模板可以被顯示，你不高興就不要加阿，重點只是能否讓管理員標記要提刪，並且註明「模板能被顯示的方案」，你高興只寫/*{{Delete|快速删除理由}}*/也能被加入速刪分類，只是模板不會顯示。因為技術限制/*{{Delete|快速删除理由}}*/寫法無法讓模板被顯示。我仍想推行能讓模板被顯示的方案或手段，因為可以用於插入DOC類的用途。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月30日 (五) 11:09 (UTC)[回复]
      - @Tranve：跟全局變量無關，這是用純粹正则表达式抓取的，你只要有相同的字樣，放哪都沒差。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月30日 (五) 11:12 (UTC)[回复]
        @Tranve：要讓模板能準確被解析器抓到，又要確保最低時間複雜度，註解內無法被準確抓到，如果所有的註解都要讓wikitext解析渲染又更奇怪了。你大可以寫成/* var _addText="{{Delete|快速删除理由}}"; */或/* _addText{content:"{{Delete|快速删除理由}}";} */，反正都是用正則來實現的，都抓得到。不使用這種方法，你要讓解析器解析模板，js或css又不是合法的wikitext怎麼解析?當然要定義正则表达式來抓取。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月30日 (五) 11:18 (UTC)[回复]
        跟全局變量無關，這是用純粹正则表达式抓取的，你高興apple.banana[9487].hyyy().gfdgdfgfdhgfjgh.[console.log("跟全局變量無關這是用純粹正则表达式抓取的你高興寫甚麼都隨便你")]._addText="{{Delete|快速删除理由}}"; 或者let 娜娜奇娜娜奇娜娜奇_addText="{{Delete|快速删除理由}}";或者其他天花亂墜的寫法都行。-- 五歲抬頭雪菲（☎️·☘️） 2021年4月30日 (五) 11:25 (UTC)[回复]

限縮{{电视节目的变迁}}模板使用範圍

電視節目我印象中的認知是綜藝、名嘴那種節目，電視劇個人感覺像是跟電視動畫一樣的存在，只是娛樂產物，雖然我是想直接刪掉這麼雞肋的模板，但似乎無共識，那提議限縮使用範圍如何？以上僅個人拙見。--1.200.74.250（留言） 2021年4月9日 (五) 03:28 (UTC)[回复]

我認爲可以廢掉。前後檔節目一般没有直接關係。如果有關係，也應該是用條目正文說明經緯，比如“前檔的古裝劇《XXX》意外大熱，故電視臺决定延續古裝題材”。類比WP:DATELINK可以說，Template:電視節目的變遷羅列接檔條目時，其聯繫不能祇是“節目在同一時段且前後相連”這种程度。畢竟模板占那麽大位置（三行比一些導航模板都高，還不能折叠），正文又什麽東西都說不出來，那基本就是WP:UNDUE。至於重要電視臺的黄金檔電視劇，這本身就是個話題；可考慮作爲整體直接建導航模板，將一系列條目按時序列出。總而言之：和主題的其他製作、放映資訊相比，前後檔節目這一句話說清的事實是有多緊要，值得獨佔三行空間介紹？--洛普利宁 2021年4月10日 (六) 18:33 (UTC)[回复]

真的没啥用，前后节目本无关联，如有在正文能说明白了。太占位置了，同意直接废除。🌟🌟_Talk 2021年4月11日 (日) 01:31 (UTC)[回复]

中立，感觉类似“参见”（相关条目），不适合写入正文，不是都有明显的意义和参考资料，类似时间线资料。更看不惯收视率章节的统计表。需要电视专题的参与者决定，不然会反弹。--YF dyh000（留言） 2021年4月13日 (二) 12:10 (UTC)[回复]

人家電影票房好歹有來源，电视节目的变迁和收视率一堆沒來源還刪除不了真的是恐怖情人，想甩甩不掉。 --Loving You Is A Losing Game 2021年4月13日 (二) 17:00 (UTC)[回复]

(▲)同上(＋)支持：尤其如果後來隔幾年又有哪個電視台購買版權又添加，簡直沒完沒了，像三生三世十里桃花_(电视剧)#電視節目的變遷就很誇張。～立ち直り中^ಇ 2021年4月20日 (二) 08:33 (UTC)[回复]

不需要廢除，但是也不需要過度使用，我認為只使用於電視台或平台的首播時段是能被接受的，重播則不需要。空氣小貓（留言） 2021年4月22日 (四) 02:24 (UTC)[回复]

(▲)同上，(－)反对直接廢除，只限首播就是了。另限一頁（或一個地區）用一個也行。--LuciferianThomas．留言 2021年4月22日 (四) 06:53 (UTC)[回复]

@Lopullinen、YFdyh000、星星、Milkypine、KodokunaSmile、Pseudo Classes：無共識結案或進一步討論限制措施（如限記錄首播）？--LuciferianThomas • 留言 2021年4月29日 (四) 06:32 (UTC)[回复]

@LuciferianThomas：：这里不是投票。希望反对废除的维基人回应一下，为什么接档信息值得独占三行空间，而不是用正文中的一句话表述。--洛普利宁 2021年4月29日 (四) 06:45 (UTC)[回复]

若多於一個頻道同步首播，其後或此前各自是在播不同的節目，那麼就當然會造成混亂。純文字解決不了的是閱讀上的凸顯。--LuciferianThomas • 留言 2021年4月29日 (四) 06:54 (UTC)[回复]

首先即便是多台首播，点列语法一台一行也足够清晰，根本不用占三行位置。

其次为什么非要列接档信息？条目的主题是电视剧，不是电视台；说一下在电视剧在某台首播即可，不需要在这个电视台的节目表上延展。「电视剧>电视台>电视台x点节目（条目都没写，这还是断链）>电视台x点节目的前后档」这个链条下来，接档和主题的关系都稀释的差不多了。条目还有剧情大纲、制作过程、反响等更重要的信息；没看出来这个信息对一般读者（不是电视台粉丝）重要到值得占三行。接档的事情是电视台层面的东西，要搞也是搞某台x点电视剧这种条目。—洛普利宁 2021年4月29日 (四) 07:18 (UTC)[回复]

這類模板不見得有其重要性，如果能只使用於首播節目的話，那麼能提供讀者具有歷史價值的接映節目資訊，但是過度使用就會失去了原有意義。空氣小貓（留言） 2021年4月29日 (四) 08:45 (UTC)[回复]

我認為要限制使用不怎麼簡單，除非自動偵測條目中模板被使用的次數，並設定幾次後就不顯示和收錄進分類來維護，這樣才有限制的效果。空氣小貓（留言） 2021年4月29日 (四) 08:50 (UTC)[回复]

維基百科不是純文字百科，適量使用圖像、表格、時序等輔助閱讀並無不可。這裡文字的缺點就是比較難找到相關資訊（一整篇文字找一句話），相對這些你覺得不重要而確實有人要看的資訊放頁尾的表格就可。就Pseudo Classes的疑問，我有一下看法：模板支援一個模板多個頻道，限用一個模板並不難（過濾器阻止加新模板）；另以共識在模板使用說明頁寫明不紀錄重播，或增加包含在預設摺疊欄目的重播資訊新增參數也並非不可。這種方式類似{{藝人}}限制收錄暱稱數量，但固然得靠人手清理。另外，合併模板也可透過機械人實現，讓所有包含此模板的頁面都經機械人處理（新增臨時維護用隱藏分類辨識檢測條目）後續以過濾器禁止加入多於一個此模板即可。清理還是得人手清。--LuciferianThomas • 留言 2021年4月30日 (五) 04:29 (UTC)[回复]

應該要這麼說，限制模板使用次數並不困難，但是要設立一個限制使用範圍就沒有那麼簡單，光是模板就有很多後門能走，要規避限制也不是件難事。空氣小貓（留言） 2021年4月30日 (五) 12:22 (UTC)[回复]

@LuciferianThomas：政治人物罗列前任继任关系，是因为条目正文很可能提及传主如何继承/改变前任的政策。音乐专辑条目用表格罗列销售认证，是因为这能反映唱片的业界影响。现在请问，某台前档电视剧是如何影响条目主题的？如果说不上什么影响，那这就是一句话带过的信息（甚至不提都行），根本配不上占据三行文字的空间。而且讲真，为什么不用大表格列导演/制作人/主演的前后作品，偏偏就要列电视台放映的前后作品？当然，您可以说导演/制作人/主演的条目有作品列表，而电视台没有接档节目列表。那这里能不能说明，接档信息的百科价值低？

维基百科首先百科，然后才是非纯文字百科。图片、表格都是为了帮助读者更好的理解正文，而不是像数据库或电视节目指南般专门用来查的。如果读者就是为了找前后档信息，那他应该去电视台节目数据库，或者爱好者组织的x台粉丝站，但总之不是去维基百科。有人要看并非维基百科收录的理由；至于占三行空间，就更谈不上适量，导航模板还知道折叠成一行呢。

最后同样都是流行文化条目，借用电子游戏条目指引的一句话供参考：“如果某内容只对真正的电视台观众有意义，那便是不合适的”。--洛普利宁 2021年4月30日 (五) 15:49 (UTC)[回复]

设立过滤器禁止将维基百科用作来源

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:可供查證。

在修订爱丁堡公爵菲利普亲王的时候，我发现有用户将维基百科条目用作来源，由于维基百科早有方针禁止在条目中使用维基百科作为来源，这类编辑显然违反有关方针。然而，维基百科上引用维基百科的条目实在不少，例如以中文维基为例，证明这些方针一直以来未能发挥有效作用。故在此建议设立过滤器，禁止在引用中使用维基百科的内容（URL或者内部链接）。--百战天虫（留言） 2021年4月12日 (一) 13:03 (UTC)[回复]

請提供至少5筆編輯差異供測試。--Xiplus#Talk 2021年4月12日 (一) 13:11 (UTC)[回复]

巡查員申請條件嗎www-- Sunny00217 2021年4月12日 (一) 13:21 (UTC)[回复]

不足100条，应当清理。过滤器可以打标签，至多警告，阻止不建议，可能有合理的WP:自我参照和其他值得保留内容，清理这种内容也不会太麻烦。--YF dyh000（留言） 2021年4月12日 (一) 13:18 (UTC)[回复]

@Xiplus：是指这类条目的编辑差异吗？--百战天虫（留言） 2021年4月12日 (一) 13:50 (UTC)[回复]

您認為應該被阻止的「那筆編輯」，盡量在1個月內的編輯。--Xiplus#Talk 2021年4月12日 (一) 13:53 (UTC)[回复]

1个月内的比较难，更久一点倒可以找。--百战天虫（留言） 2021年4月12日 (一) 13:58 (UTC)[回复]

如果情況過少就可能不會考慮建立過濾器，當然可以先建立看看實際觸發量，但不排除在確認過少後停用。--Xiplus#Talk 2021年4月14日 (三) 15:36 (UTC)[回复]

也可以按照上面的意见做个警告加标签，暂不设立过滤器。不过现在有引用的肯定要清理了。--百战天虫（留言） 2021年4月14日 (三) 15:56 (UTC)[回复]

@Xiplus：阁下的意见？--百战天虫（留言） 2021年4月18日 (日) 07:34 (UTC)[回复]

或者將Special:滥用过滤器/39不可信來源中的豁免取消掉。--Xiplus#Talk 2021年4月18日 (日) 07:54 (UTC)[回复]

本人不怎么看，就是个路人，罢了--Raptor (Unknown)

所以现在有两种方案，一是对引用维基百科的编辑加警告和标签，二是将第39号滥用过滤器的不可信來源中的豁免取消掉，欢迎大家发表意见。--百战天虫（留言） 2021年4月21日 (三) 05:20 (UTC)[回复]

无必要，本人的机器人会自动清理。--Antigng（留言） 2021年4月21日 (三) 07:39 (UTC)[回复]

阁下能不能列举几项编辑记录？--百战天虫（留言） 2021年4月24日 (六) 09:12 (UTC)[回复]

上面那个链接里用标签筛选出来的都是。--Antigng（留言） 2021年4月24日 (六) 10:56 (UTC)[回复]

(－)反对。將維基百科條目放入參考來源，偶爾是合理的。有一些編者習慣用參考來源的方式書寫註釋，例如「關於XXX的YYY方面，可參閱某個條目」。--Yangwenbo99^{論文} 2021年4月26日 (一) 00:07 (UTC)[回复]

@Yangwenbo99：就像閣下的示例，要使用內鏈而非外鏈-- Sunny00217 2021年4月28日 (三) 14:16 (UTC)[回复]

查了一下有出現 "en.wikipedia.org" 的條目，其實數量比中文的更多--Wolfch (留言) 2021年4月28日 (三) 01:32 (UTC)[回复]

订立编辑松相关规章制度

上次中塞编辑松由于主持人Walter Grassroot的一些行为对社群造成了恶劣的影响。实际上截至目前本地并没有对编辑松的举办、规则的订立相关的方针或指引，为避免再次发生类似于中塞编辑松的恶劣事件，本人提议在本地订立编辑松的相关指引。我认为至少可以作以下要求：

在提出举办编辑松时，需将举办计划提交至互助客栈由社群审阅；
编辑松规则订立时，不得订立任何歧视维基人的规则；
规则订立完成后，同样需要交由互助客栈审阅；
编辑松开始之后，除非规则有重大问题，否则不得修改编辑松规则。

以上。--忒有钱 🌊塩水あります🐳（留言） 2021年4月17日 (六) 18:46 (UTC)[回复]

(＋)支持。完善制度比指責個別人對維基百科更加有益（但這不代表無人需要為之前的紛擾負責）。--Yangwenbo99^{論文} 2021年4月17日 (六) 22:35 (UTC)[回复]

(－)反对，提议者本身就是此次闹剧的编造者，此事本身就是对大陆社群的污名化行动。目前又想伪造社群共识以实现对中国大陆社群的侮辱既定事实。对此我表示坚决反对。门可罗雀的霧島診所_{三天打鱼两天晒网}^{神社的羽毛飘啊飘} 2021年4月18日 (日) 03:53 (UTC)[回复]

我也是中国大陆人，而且现在就生活在中国大陆，大陆人和大陆人之间能有什么坏心思呢？（确信）--忒有钱🌊塩水あります🐳（留言） 2021年4月18日 (日) 04:54 (UTC)[回复]
- 其实我也好奇为什么热衷于打压和破坏大陆社群的老管理员为什么都是大陆人。。。。。--飞贼燕子（留言） 2021年4月19日 (一) 23:22 (UTC)[回复]
  「規管和（要求）遏止不恰當的行為就算是『打壓』和『破壞』」這種歪理是不會被社羣認可的。SANMOSA _Σουέζ 2021年4月20日 (二) 04:50 (UTC)[回复]
  当年某位把占海特一家领到活动场地进行蹭热度和政治活动的时候可没听说过那条管规和指引让他们这么玩，但这并不妨碍那些管理员把反对和知道真相的用户一个一个封掉以企图掩盖的行为。不过有一点你说的很对，后来的事实证明那几个管理员的歪理确实没有被社群认可。--飞贼燕子（留言） 2021年4月20日 (二) 07:50 (UTC)[回复]
  這是站外的東西，站內無權管，沒必要將這些站外的恩怨帶進站內，反正當事人以外的任何一個人都對此沒有興趣。SAN MO SA _Σουέζ 2021年4月20日 (二) 12:53 (UTC)[回复]
  站内无权管当初干嘛心虚的不得了，封人家捂人家嘴还处处针对别人，大家早就都知道他几个是干什么职业的了，掩盖的多了吧那叫歪理。--飞贼燕子（留言） 2021年4月21日 (三) 02:10 (UTC)[回复]
  你不先想想在站內討論不斷張貼一堆和本站無關的東西（i.e. 離題討論）是否恰當？我不清楚事件的大概，但至少這點是肯定適用的。現在討論頁指引是被廢了嗎？（我不只是說你上面提及到的事件，我也是說你現在的留言本身。）SAN MO SA _Σουέζ 2021年4月22日 (四) 04:02 (UTC)[回复]
我不知道忒有钱君什么时候成为“此次闹剧的编造者”的。Eric君被Walter君踢出WMC编辑群，忒有钱君在互助客栈请求取消Walter君的WMC编辑群管理员职务。后来该讨论才演变成对Walter君移除编辑松条目的讨论。 ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月18日 (日) 05:30 (UTC)[回复]
上面那個投反對票的不關注忒有钱的提議是否有道理，上來就訴諸人身。提議有提到「不得订立任何歧视维基人的规则」，所以你是不反對此類歧視性規則咯--Googol19980904（留言） 2021年4月18日 (日) 11:20 (UTC)[回复]

你们组织的所谓社群，党同伐异，异己者唯除之而后快，连制定规章都要反对。--𢿃𠫱（留言） 2021年4月19日 (一) 04:44 (UTC)[回复]

这里明明是在谈防止公报私仇行为的再次出现，不要扯到地域问题上来。--🔨（留言） 2021年4月19日 (一) 10:53 (UTC)[回复]

呼籲各位理性討論，另霧島聖閣下“闹剧的编造者；就是对大陆社群的污名化行动；又想伪造社群共识以实现对中国大陆社群的侮辱既定事实“均已涉嫌針對用戶個人的人身攻擊，以個人經驗敬請閣下不要這麽做。---維基百科最忠誠的反對者（留言） 2021年4月21日 (三) 19:11 (UTC)[回复]

(▲)同上：WP:AGF、WP:CIV：轻率鲁莽地指控他人行为不当。--Steven Sun（留言） 2021年4月24日 (六) 12:57 (UTC)[回复]

(▲)同上。--14-5-2@维基抗生素协会 2021年4月18日 (日) 04:09 (UTC)[回复]

上面那個投反對票的本身就是很多爭議的製造者，甚至假定惡意來封鎖使用者，真是八兩笑一斤。空氣小貓（留言） 2021年4月18日 (日) 16:09 (UTC)[回复]

八兩笑一斤？百步笑五十步比較準確吧。--Yangwenbo99^{論文} 2021年4月18日 (日) 16:53 (UTC)[回复]

我是指他自己份量太輕，竟然指責（笑）比自己份量更重的人。空氣小貓（留言） 2021年4月19日 (一) 00:38 (UTC)[回复]

不限于编辑松，任何对外合作的编辑活动建议在开始前将活动规则在公开讨论中报备一次，并且避免产生会对特定或所有编辑不友好的行为。我认为这个提议可以考虑，——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年4月19日 (一) 01:00 (UTC)[回复]

同上。提案本身是沒有問題的。SAN MO SA _Σουέζ 2021年4月19日 (一) 01:35 (UTC)[回复]

(＋)支持，强烈譴責因為一己私欲敗壞社群名聲的行為。--Newbamboo（留言） 2021年4月19日 (一) 04:36 (UTC)[回复]

(＋)支持，同上。----𢿃𠫱（留言） 2021年4月19日 (一) 04:40 (UTC)[回复]

一、你這個編輯松的定義是甚麼？動員令、亞洲月（及其附屬活動）算不算？安可牌條目提升計劃算不算？如果動員令、亞洲月算，我認為兩者都應該獲得豁免（近十年來，曾經有兩三個人意圖擾亂動員令，但最後都折戟沉沙）。二、個別編輯松的主辦者制定規則排斥個別用戶，這應該用NPA、CIV處理。三、可以考慮為編輯松的舉辦流程制定原則、指引和違規處理機制（不要求為綜合文本，可散見於不同頁面），但不贊成舉行甚麼編輯松都要上客棧報備，這樣容易橫生枝節。--春卷柯南－發前人所未知 ( 論功行賞 ) 2021年4月19日 (一) 10:39 (UTC)[回复]

一：动员令只是中维站内活动，当然不算；亚洲月本就是与其他语言联合举办的编辑松的一种形式，需要算在内。二：( ✓ )同意，但最好还是先定下规则（我认为我草拟的规则中第四条非常重要）。三：未必是上客栈，可以用专用页面（比如Wikipedia:编辑松的子页面）。--忒有钱 🌊塩水あります🐳（留言） 2021年4月19日 (一) 21:07 (UTC)[回复]

一、你這個定義標準是站不住腳的，編輯松的本質就是鼓勵別人做編輯，寫條目的活動啊，而動員令和亞洲月都是條目競賽。二、暫時不回覆。三、我的意思是說報備這一步是不必要的。一個通知還不夠嗎？如果通知以後，有一群人認為事情不對勁，也就是在客棧事後審查，一如目前的做法。--春卷柯南－發前人所未知 ( 論功行賞 ) 2021年4月20日 (二) 13:46 (UTC)[回复]

@春卷柯南：（1）認同你的見解，但需要考慮到的是協調各維基百科的亞洲月的相關人士未必清楚本站內負責的主持人的主持方式是否恰當，因此不贊同豁免亞洲月。（3）2月的事件已經證明了事後審查的成效不大。雖然說那三個核心人物之一已經獲得處理，但明明問題就已經存在而且非常明顯了，到現在還是有人敢公然向大家說不存在問題，就已經證明了現在編輯松的舉辦者會走通知程序的漏洞，然後恣意妄為，並且把這當成常態。如果沒有人濫用現行程序，我相信他也不會走出來提這案。SAN MO SA _Σουέζ 2021年4月21日 (三) 03:16 (UTC)[回复]

支持社群采取一切合理措施阻止个别有过公报私仇前科且拒绝认错及改善的编者担任往后一切活动（包括但不限于动员令和编辑松等）的主持人，及阻止活动中一切存在显著问题及争议规则的制定与实施，如果无法阻止编辑松由有公报私仇前科且拒绝认错及改善的编者担任其中一位主持人，或无法阻止存在显著问题及争议规则在编辑松当中的出现，则支持社群采取一切合理措施阻止相应编辑松在本站的宣传。--🔨（留言） 2021年4月19日 (一) 11:44 (UTC)[回复]

(－)反对，好像每次举办社群活动的时候一般会向社群发通告吧，几位的意思是不经过几位批准以后大家都别搞了是吧。不知几位是打算怎么审批呢？是打算投票比人头呢还是在客栈聚众扯皮呢？个人觉得这个提议当个笑话看看完了没必要去较真。--飞贼燕子（留言） 2021年4月19日 (一) 23:06 (UTC)[回复]

社羣討論的共識或大方向一旦不合己意就胡亂聲稱其已失效，這不是只有你一個人正在做的事情，但大家都在看著。SAN MO SA _Σουέζ 2021年4月20日 (二) 04:50 (UTC)[回复]

我也不見得籌辦編輯松的程序開誠布公是壞事（所有社羣成員都能就此發表意見），除非籌辦者意圖利用編輯松進行違反使用條款和方針指引的事項。SAN MO SA _Σουέζ 2021年4月20日 (二) 04:55 (UTC)[回复]

怎么办活动怎么办好像参与和组织者都会写在公告上谁都可以看吧，不觉得谁会举办前就在公告里刻意违反规则指引啥的，再者个人不觉得谁会听一个完全无关闲人去批准同不同意。--飞贼燕子（留言） 2021年4月20日 (二) 07:31 (UTC)[回复]
但舉辦期間這樣做的情況已經出現了。社群作為編輯松的參與者，怎麼可能是「閑人」？不然編輯松是開來做甚麼的？SAN MO SA _Σουέζ 2021年4月20日 (二) 12:53 (UTC)[回复]

「不觉得谁会举办前就在公告里刻意违反规则指引啥的」——上一次活動是在活動中更改規則，違反指引的。--Yangwenbo99^{論文} 2021年4月21日 (三) 03:34 (UTC)[回复]
操作涉及操作问题一次不行下次可以修正，社群活动的参与者不少但是那些喜欢捣蛋的闲人也一样不少。方针规则这东西这次你能用下次别人一样能拿来用，届时就社群活动就谁都别搞不了只能在互助客栈扎堆审查扯皮，我看这个提案就是为那些闲人在社群活动时审查扯皮捣蛋准备的提案。--飞贼燕子（留言） 2021年4月21日 (三) 02:10 (UTC)[回复]

我不介意重複一次上面的話：「社羣討論的共識或大方向一旦不合己意就胡亂聲稱其已失效，這不是只有你一個人正在做的事情，但大家都在看著。」「社群作為編輯松的參與者，怎麼可能是『閑人』？」（還是說，你已經把特定的社群參與者，不當成是社群的一分子，然後要把他們排擠出去？）你的反對理由是完全無效的。SAN MO SA _Σουέζ 2021年4月21日 (三) 03:07 (UTC)[回复]

「届时就社群活动就谁都别搞不了只能在互助客栈扎堆审查扯皮」——所以閣下認為舉行「社羣活動」不需要取得「社羣共識」？會導致「扎堆审查扯皮」的操作必然是爭議性操作, by definition, 而閣下是否認為在社羣活動的規章之中進行爭議性操作是適當的？「操作涉及操作问题一次不行下次可以修正」——制訂規則就是為了防止之後出現類似問題。我明白閣下希望維基百科都是舉手機器，但是殘酷的現實是，維基百科有一批編者是有獨立思考能力的知識分子，而這當中有一部分人願意為維基百科的益處進行爭論。--Yangwenbo99^{論文} 2021年4月21日 (三) 03:34 (UTC)[回复]

（竟然有這樣一句來著）「操作涉及操作問題一次不行下次可以修正」——之前2月的時候都已經「不行」了，之前的「下次」不就是現在嗎？SAN MO SA _Σουέζ 2021年4月21日 (三) 03:44 (UTC)[回复]

其实我感觉您和我一样现在很想尝试下去给别人捣蛋让和毫不相关的人必须听我摆摆的感觉，但为了保证以后不出什么大家担心的长期的大乱子我感觉您还是哪里凉快上哪里歇，冷静下的好。--飞贼燕子（留言） 2021年4月21日 (三) 08:59 (UTC)[回复]
不要一來就直接不斷說其他人「搗蛋」（我超想說這句很久了），不然按照你的邏輯，現在氣候暖化這麼嚴重，冷靜不下來的人很有可能是你。「站外的東西，站內無權管，沒必要將這些站外的恩怨帶進站內」，這句話容許我再抄送一次，可惜有很多人一直都不懂。SAN MO SA _Σουέζ 2021年4月21日 (三) 09:03 (UTC)[回复]

“个人觉得这个提议当个笑话看看完了；感觉您和我一样现在很想尝试下去给别人捣蛋让和毫不相关的人必须听我摆摆的感觉；我感觉您还是哪里凉快上哪里歇，冷静下的好。”上述語句個人認爲涉嫌輕蔑其他編輯及訴諸人身，容易引起爭議，請投下否決票的兩位用戶注意言辭。維基百科最忠誠的反對者（留言） 2021年4月21日 (三) 19:28 (UTC)[回复]

(＋)支持；(！)意見對於未就本次提案提供建設性意見、訴諸人身且屢次樹立稻草人論證之類的發言及投票（包括以此無理理據之“同上票”），我本人建議按照维基百科:建设性意见在内的方針指引將其作廢，不納入討論共識之考量。另同Newbamboo閣下對於任何為主張/闡釋/維護個人立場及觀點敗壞本站名譽的行爲表示最强烈之譴責。--維基百科最忠誠的反對者（留言） 2021年4月21日 (三) 19:42 (UTC)[回复]

現在並沒有投票。--Yangwenbo99^{論文} 2021年4月22日 (四) 18:52 (UTC)[回复]

只是担心，如果社群专门出指引来规管编辑马拉松但无法覆盖每个方面，则很可能是无用功。--痛心疾首 2021年4月26日 (一) 03:19 (UTC)[回复]
对于1和3，有一些在时效性上的担心。--安忆 ^Talk 2021年4月27日 (二) 11:55 (UTC)[回复]

根据上方的意见，现将提案内容调整如下：

举办编辑松需要在本地创建专题页面（具体用编辑松专用子页面还是单独的项目页面另行商议），列出编辑松的举办时间、规则、主持人等必要信息；
编辑松活动不得有任何歧视维基人的规则；
编辑松开始之后，除非规则有重大问题，否则不得修改编辑松规则。

以上，欢迎补充。--忒有钱 🌊塩水あります🐳（留言） 2021年4月27日 (二) 11:48 (UTC)[回复]

（编辑冲突）我暂时不认同将编辑松相关事务方针指引。因为本人认为，上述多项内容是已有而不必要的，且有一部分属于部分维基人私意自治或可以自行协商的内容。
举办编辑松需要在本地创建专题页面，列出编辑松的举办时间、规则、主持人等必要信息——任何正常举办的编辑松都不可能存在不明确的上述内容。如果有这种什么信息都没有的编辑松，可以理解为扰乱行为，相关页面应该是符合纯粹破坏而被快速删除的。

编辑松活动不得有任何歧视维基人的规则——任何歧视维基人的行为当然违反文明方针和Openness决议的。

除非规则有重大问题，否则不得修改编辑松规则。——这个纯属相关举办方的私意自治范畴，我不认为社群应该直接介入，除非涉及上一点。

至于出事了怎么处理，无疑是处罚主持人。WG都被禁止了，这就是结果。--痛心疾首 2021年4月27日 (二) 12:08 (UTC)[回复]
(：)回應请注意第一条的“本地”，之前中塞编辑松只在meta有专题页面，本地没有。--忒有钱 🌊塩水あります🐳（留言） 2021年4月27日 (二) 12:37 (UTC)[回复]
注意到了，修改一下意见：如果有类似的规定，我仅能支持第一条。--痛心疾首 2021年4月27日 (二) 13:14 (UTC)[回复]
(－)傾向反對在本地訂立編輯松的相關指引。一來主辦方對編輯松的呈現方式應該有一定程度的自由，而且在提供連結和必要資訊的情況下，在本地建立頁面跟在meta或任何其他地方建立頁面的意義是相同的，為此不同意第一條；至於第二條和第三條，我相信之前的事情純屬特例，一般編輯松不會出現這麼離譜的事情，為了一次特例而去對往後的眾多社群編輯活動訂立規範是沒有必要的。真的再出現像上次的情況怎麼辦？痛心疾首閣下已經提供了解答。按本地和基金會方針處理應當足矣，社群的執行力才是重點。—— Eric Liu_{創造は生命（留言．留名．學生會）} 2021年4月27日 (二) 15:24 (UTC)[回复]

（1）同意。（2、3）不然，此類事件有一即有二（就像出軌一樣），因此我認為編輯松規則的修改需要得到社羣授權方可為之，以加強社羣監察之效。規章制度的訂立本身有加強社羣執行力的效果。SAN MO SA _Σουέζ 2021年4月30日 (五) 05:46 (UTC)[回复]

將「青島」、「中國青島」或「山東青島」改成「中華人民共和國山東省青島」是否有必要

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:命名常规。

近日有不少更改是將城市名改為類似「中華人民共和國山東省青島」的詳細行政區劃名。其中單個使用者一兩日內（初步估計）過百次類似編輯，所以應當訂立規定。舉例如下：

此等做法是否存在必要性？我不相信有中文維基百科使用者會不知道青島現由中華人民共和國管轄，亦不相信會有人無法輕易查得青島屬於山東省。另外，在下對把机器人们带走的存在感给抢回来的行為相當欣賞。

就將「中國」改為「中華人民共和國」一事，可能是相關編者受Wikipedia:格式手册/两岸四地用语#使用「中國」一詞中「在1949年之後的相關條目中，應儘量使用中華人民共和國和中華民國等全稱」的影響。但是Wikipedia:格式手册/两岸四地用语#指定樣式表便違背了Wikipedia:格式手册/两岸四地用语#使用「中國」一詞的建議，要求特定人士使用「中国」而非「中华人民共和国」標註國籍。可見，「在1949年之後的相關條目中，應儘量使用中華人民共和國和中華民國等全稱」之不可實踐性。

就應當以何種形式在文中提及城市，似乎 (a) 以行政區劃全稱和 (b) 直接以城市名提及，兩者未能增減文章可讀性。在二者間進行更改似乎建設性不強。而維基百科似乎缺乏相關規定。

以上--Yangwenbo99^{論文} 2021年4月18日 (日) 00:22 (UTC)[回复]

就「使用『中國』一詞」的權宜修正

現行條文

此外：

……

提議條文

此外：

……

對於不存在主權、治權爭議之地理概念，仍舊可逕作「中國」而無需使用置頂宣言。具體以何種形式書寫，依照先到先得之原則處理。

以上。--Yangwenbo99^{論文} 2021年4月18日 (日) 00:53 (UTC)[回复]

就提及兩岸四地之下級地區作出規定

參考Wikipedia:命名常规#地名，提下列提案。

現行條文

下級行政區劃若非描述法理狀況（de jure），在描述兩岸四地下級行政區劃所屬的國家時，應以事實論述（de facto）為主。

提議條文

下級行政區劃若非描述法理狀況（de jure），在描述兩岸四地下級行政區劃所屬的國家時，應以事實論述（de facto）為主。

在不引起歧義的情況下，在文中提及兩岸四地任何知名城市時，通常應當直接不加前綴地直接使用該城市名（如：「青島」或「青島市」）。在會產生歧義時，應當使用能够区分的最上级行政区划名消歧義。在不違背本規則的前提下，具體以何種形式書寫，依照先到先得之原則處理。

以上。--Yangwenbo99^{論文} 2021年4月18日 (日) 00:53 (UTC)[回复]

(＋)支持@K.Y.K.Z.K.：Newbamboo（留言） 2021年4月18日 (日) 02:51 (UTC)[回复]
(－)反对，此款条例是为特定人群进行的政治分肥行为。地级市和直辖市的使用必须尊重并遵循事实，不能采取偷袭或者删减的方式刻意为之。门可罗雀的霧島診所_{三天打鱼两天晒网}^{神社的羽毛飘啊飘} 2021年4月18日 (日) 04:01 (UTC)[回复]
- 亦不應採取大規模襲擊或機械式附加內容的方式刻意為之。那麼閣下有何避免此等情況發生的建議呢？--Yangwenbo99^{論文} 2021年4月18日 (日) 08:27 (UTC)[回复]
  - @Yangwenbo99：“採取大規模襲擊或機械式附加內容的方式刻意為之”應該是“未經授權而使用bot”或“濫用bot”的情況，應該依照bot的相關方針處理。不過我個人也是覺得説成是“政治分肥”也不至於。SAN MO SA _Σουέζ 2021年4月19日 (一) 01:43 (UTC)[回复]
以陈倩_(游泳运动员)为例，该条目的最初版本即为{{CHN}}[[山东省]][[青岛市]]，但在2016年被User:K.Y.K.Z.K.将其中的[[山东省]]移除。范学伟和任永顺两条目亦是如此。翻查User:K.Y.K.Z.K.的编辑历史，其在过去多年内，长期刻意将青岛相关条目中的山东一词抹去（如在青岛地铁的讨论页中移除山东专题），可能构成WP:POINT。Itcfangye（留言） 2021年4月18日 (日) 04:59 (UTC)[回复]
- 希望這個規定就是為了避免在「青島」、「山東青島」、「中國青島」、「中國山東青島」之間反覆變換。如果只是個別編輯，則大可不必在意，但這是單個使用者一兩日內初步估計過百次類似編輯，所以應當訂立規定。更簡單的替代方案是完全依照先到先得的規則，不知閣下意下如何。--Yangwenbo99^{論文} 2021年4月18日 (日) 08:22 (UTC)[回复]
- 我觉得应该对K.Y.K.Z.K.的相应编辑进行编辑禁制，禁止相关用户“反覆變換”相关内容来违反WP:POINT，而没有必要去明确说哪些可以。哪怕放在某些格式手册里，这种“是否需要对知名城市冠以国家/地区名称”也是比较有争议的。--痛心疾首 2021年4月18日 (日) 09:38 (UTC)[回复]
  - 請注意，有許多出現類似情況的條目中K.Y.K.Z.K.並未參與編輯。--Yangwenbo99^{論文} 2021年4月18日 (日) 09:59 (UTC)[回复]
    - Itcfangye、痛心疾首的观点在理。根据K.Y.K.Z.K.的用户页及历史版本，可以看出，他主张青岛市从山东省分离出去。--DavidHuai1999※Talk 2021年4月18日 (日) 10:12 (UTC)[回复]
    - 了解了，但请恕个人很难赞同这种高度争议化的提案。这里需要说明的是，本人反对未阐释观点扰乱性编辑，也不支持这种可能引发强大争议的提案。“以事實論述（de facto）為主”反而能稳定表达一个地方，比如“中华人民共和国山东省青岛市”，不然「青島」、「山東青島」、「中國青島」、「中國山東青島」……可以搞出不晓得多少种来。--痛心疾首 2021年4月18日 (日) 10:15 (UTC)[回复]
      - 據我理解，依事實描述指應當使用「北京市」而非「北平」指稱中央政府所在地等事項。使用「中华人民共和国山东省青岛市」來避免「不晓得多少种」論述，實在是冗長而無比要。如要寫出行政區劃全程，則必然會造成戲劇性結果。下舉一例來自东湖旅店的段落，依照閣下建議，應當改寫為

惠州解放后，东湖旅店曾被用于中华人民共和国广东省惠阳專区武装部的办公场所。2000年代，东湖旅店的产权被以数百万人民币的价格售予私人买家。之后，相关人士在不早于2009年8月对该旅店进行了修缮，并令其回归私人住宅用途。2012年，中华人民共和国广东省惠州市惠城区人民政府将其确定为不可移动文物。2014年11月，东湖旅店被辟为一间名为“水东院子”的休闲咖啡吧。

2017年2月28日，中华人民共和国广东省惠州市惠城区召开宣传思想文化工作会议，指出将抓好包含东湖旅店在内的多幢历史建筑的修缮工作。次月，中华人民共和国广东省惠州市惠城区人民政府以人民币750万元的价格收购了旅店的产权。2018年3月3日，上述咖啡吧于社交网络发布停业装修的公告，随后于当月25日正式宣布结业转让。

以上。--Yangwenbo99^{論文} 2021年4月18日 (日) 12:23 (UTC)[回复]

(▲)同上。--山东济南，中国青岛 2021年4月18日 (日) 06:07 (UTC)[回复]
- 回應(▲)同上。--Yangwenbo99^{論文} 2021年4月18日 (日) 08:22 (UTC)[回复]
不對上述條文置可否，但是我認為在資訊框裡應使用完整的行政區劃，正文則是至少第一次提及時建議使用。另外，不知兩岸以外地區的行政區劃寫法是否有所規範？—— Eric Liu_{創造は生命（留言．留名．學生會）} 2021年4月18日 (日) 14:58 (UTC)[回复]

請問現在究竟是僅討論地名的條目命名，還是擴及地名「在文中」的使用？-游蛇脫殼/克勞棣 2021年4月18日 (日) 15:51 (UTC)[回复]

只討論在正文中的使用。條目命名已有相關規定，即只能使用「青島市」這一種形式。--Yangwenbo99^{論文} 2021年4月18日 (日) 17:04 (UTC)[回复]

(－)反对，理由如下：

就前者：‘但是Wikipedia:格式手册/两岸四地用语#指定樣式表便違背了Wikipedia:格式手册/两岸四地用语#使用「中國」一詞的建議，要求特定人士使用「中国」而非「中华人民共和国」標註國籍。可見，「在1949年之後的相關條目中，應儘量使用中華人民共和國和中華民國等全稱」之不可實踐性。’是錯誤描述。指定樣式表的規範屬於Wikipedia:格式手册/两岸四地用语#使用「中國」一詞的規範的例外條文，而且僅限於國籍，是依據國籍的國際標準表示方式而行，不存在“違背”和“不可實踐”的情形，我要求提案人立即收回其錯誤表述。
就後者：完整的行政區劃和單稱在條目内的不同地方有不同的使用，不可能在一個條目内的所有地方都完全只用完整的行政區劃或單稱。一般來説，資訊框和正文首次提及時會使用完整的行政區劃（例如“中華人民共和國山東省濟南市”、“德國北萊茵-西法倫州（代特莫爾德行政區棉登-呂貝克縣）棉登”），然後正文其餘地方使用單稱（例如“濟南”、“棉登”）。

綜以上，提議修訂屬矯枉過正，我不可能支持。SAN MO SA _Σουέζ 2021年4月19日 (一) 01:21 (UTC)[回复]

補充説明：WG對埃琳·派齐條目的修改是完全錯誤的，1939年的青島是院轄市，不受山東省管轄。SAN MO SA _Σουέζ 2021年4月19日 (一) 01:31 (UTC)[回复]

補充説明2：香港和澳門比較特別，通常不會把（任何形式的）國名和“特別行政區”五個字寫進去（因為嚴格上“十八區”不算是行政分區），因此基本上不會使用完整的行政區劃（唯一表達式：“中華人民共和國XX特別行政區”）。SAN MO SA _Σουέζ 2021年4月19日 (一) 01:38 (UTC)[回复]

另外請各位關注Wikipedia:頁面存廢討論/記錄/2021/04/16中對Template:QDCT、Template:QDC和Template:QDS的提刪。SAN MO SA _Σουέζ 2021年4月19日 (一) 01:50 (UTC)[回复]

循例請一下@K.Y.K.Z.K.、Cxbats過來好了。SAN MO SA _Σουέζ 2021年4月19日 (一) 01:58 (UTC)[回复]

就新事項再通知一次@Itcfangye、痛心疾首。SAN MO SA _Σουέζ 2021年4月19日 (一) 02:00 (UTC)[回复]

这样子，就是在目前青岛市治权还在山东省的情况下，加山东省毫无问题。等未来N年后有机会光荣直辖（要是到时候我死了就在讨论页@我一下），再改也不迟。我本来就在用户页里说了：“除内文必须要提及山东外，仅需要在条目序言提一次山东即可。”

条目里该是山东还是山东，但我永远不会承认自己是山东人。当然，造成这一原因的不是山东人民，而是山东省政府和山东与青岛之间的文化差异性。--K·Y·K·Z·K ◢ 2021年4月19日 (一) 05:36 (UTC)[回复]

真要想成為中國的直轄市，廣州和深圳不比青島更有資格？--Googol19980904（留言） 2021年4月19日 (一) 09:42 (UTC)[回复]

即使青岛在20AA年成为直辖市，也不能否认其在1949-20AA年间是地级市。 ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月19日 (一) 15:33 (UTC)[回复]

那麼，單純地依據「先到先得」如何？--Yangwenbo99^{論文} 2021年4月19日 (一) 10:25 (UTC)[回复]

仍反對，我的理由2仍適用。SAN MO SA _Σουέζ 2021年4月20日 (二) 04:44 (UTC)[回复]

支持--Newbamboo（留言） 2021年4月24日 (六) 02:00 (UTC)[回复]

訂立影片加入相關指引

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:文件使用方针。

我發現最近有很多條目中都被加入了影片，雖然其中不少都對條目大有裨益，但是我也發現相當一部分條目中被加入了與條目本身關係不大的内容或與條目本身不對稱的内容（比如在青藏高原條目加入中科院院士的演講影片和在小條目加入長達20分鐘的影片），所以想請問一下社群是否需要訂立相關指引來規範條目中的影片加入？--Newbamboo（留言） 2021年4月20日 (二) 04:11 (UTC)[回复]

谢谢，这个是我在Telegram提起来的，WP:AGF的话是我确定这些内容是对维基百科的内容大有益处（尤其很多内容是我们这些普通编者很难接触到或者获取到的）的也非常感谢把他们传到commons的同仁，但是视频尤其新闻报道可能会涉及WP:NPOV的问题，即使没有NPOV问题也涉及到篇幅的问题（一个小作品里出现几十分钟的视频肯定是读者没有耐心去看的），我想了一下，有以下几个点可能可以改进：

针对新闻视频，提供新闻供稿人的名称，供读者自行辨识观点。
针对过长的视频，考虑进行剪辑或者进行截图，然后将截图插入条目进行展示。
或者如果实在认为新闻信息对条目非常宝贵，将新闻视频转写成文字的形式作为来源扩充条目。

不知道各位意向如何？--Parker^Tian 2021年4月20日 (二) 04:21 (UTC)[回复]

@Newbamboo、Park1996：已有相關規範，見WP:VUP。SAN MO SA _Σουέζ 2021年4月20日 (二) 04:28 (UTC)[回复]

虽然说针对视频资料过度使用影响阅读体验的问题，去年就已经修订相应方针来加以限制。不过就现在的情况来看，相关方针执行力度并不算强。--🔨（留言） 2021年4月20日 (二) 06:25 (UTC)[回复]

@Liu116：有甚麼條目是違反相關方針的，請列出來，我動手清理一下，有人回退的話，我就依方針提報。SAN MO SA _Σουέζ 2021年4月20日 (二) 12:55 (UTC)[回复]

……这个我没法完整列出，我顶多只知道脱贫攻坚战条目中原本被移除掉的视频后来又都被加了回来，还有2019冠状病毒病疫苗条目，以及部分“202X年X月中国大陆”的条目也有这样的问题。--🔨（留言） 2021年4月20日 (二) 13:08 (UTC)[回复]

我看到的是驻港部队有过多视频。好像很多都是WG君加入的，能不能跟他说一下让他自己改正呢--Parker^Tian 2021年4月20日 (二) 18:33 (UTC)[回复]

當中兩段影片未獲正文提及，另有一段與正文關係不夠密切，已代為刪除。--Yangwenbo99^{論文} 2021年4月20日 (二) 23:33 (UTC)[回复]

對於「加入影片」這一行為，已有相關規定——Wikipedia:文件使用方针#使用守則，即必須同時滿足

與條目有密切關連、
在條目內文有所提及、
符合中立的觀點（包括旁白、註釋），且比重需合理，及
僅保留具代表性之檔案，每條目一般不應同時存在多於五條影片。

而若在無共識的情況下將原本被刪除的影片重新加入，即屬蓄意挑起WP:編輯戰。

建議加入一條「一般而言，新聞報導與條目所論述內容有關，並不代表其內容與條目主題直接相關。僅在該影片所論述之內容本身為所在條目或所在章節之主要論述內容時，方可被認為與條目主題直接相關。」

另外，可以考慮將與內容相關，但是不便加入條目的影片放置於外部鏈接當中。甚至可以訂立指引，表示外部鏈接中可以設一節放置相關影片，以及規定收錄影片的標準。

此外，同意就編輯影片以便加入條目訂立指引。

以上。--Yangwenbo99^{論文} 2021年4月20日 (二) 23:26 (UTC)[回复]

我總結一下上面的意見，並得出以下的提議條文：

“

影片適用的使用守則

快捷方式

WP:VUP

一切影片檔案僅能在相關內容獲正文提及時方可引用，而相關影片應有大部分或全部内容與條目主題直接相關。相關影片在條目内的描述文字須同時與條目内容及影片内容相符。一個條目一般不應同時存在多於五條影片，用戶如在單一條目内加插多條影片，應就其在條目中加入的相關影片的理由，以及相關影片與條目主題的相關性作出合理解釋。

除非可以肯定相關移除影片的動作為明顯的破壞行徑，否則一切影片一旦遭到移除，須先經討論獲得共識後方可再次加入，未經討論共識而強行重新加入遭到非破壞性移除的影片的用戶將會被視同挑起編輯戰，並可被施予編輯禁制，甚至封禁。長期未經討論共識而強行重新加入遭到非破壞性移除的影片，或長期在未作出合理解釋的情況下在大量條目內加插多條影片的用戶則會被視為長期破壞者，應予以較長時間的封鎖。

若引用的影片檔案為新聞影片，應提供新聞供稿人及／或機構的名稱，供讀者自行辨識觀點。一般而言，新聞報導與條目所論述內容有關，並不代表其內容與條目主題直接相關。僅在該影片所論述之內容本身為所在條目或所在章節之主要論述內容時，方可被認為與條目主題直接相關。

過長的影片應予以剪輯，或將之截圖，並將截圖在條目內引用。如可行，請考慮以影片的外部連結代替上載並直接引用影片檔案本身。如相關影片對條目非常重要，且適合作為可靠來源使用，則應將影片以引用來源的方式在條目內引用。社群在有必要時可以對來自可靠性或中立性存疑的媒體的影片進行額外的限制。

”

以上。SAN MO SA _Σουέζ 2021年4月21日 (三) 03:56 (UTC)[回复]

虽然说追加视频时长的限制是好事，不过就目前的情况来看比起进一步追加条文，我觉得更重要的还是解决执行力的问题……不然加再多条文也没用……--🔨（留言） 2021年4月21日 (三) 04:56 (UTC)[回复]

這可能要請管理員長期持續監察才能成事。SAN MO SA _Σουέζ 2021年4月21日 (三) 08:54 (UTC)[回复]

(－)反对：原有条文足矣，不必更易。这些问题不是条文的问题，而纯属执行力问题。--痛心疾首 2021年4月21日 (三) 07:24 (UTC)[回复]

原有條文的執行力差，部分原因是條文本身部分論述較為籠統，所以應當具體化。如「僅保留具代表性之檔案」，但對於檔案長度的要求未有規定。以及未有規定如何處理不應放置於內文，但有相當重要性的影片。--Yangwenbo99^{論文} 2021年4月21日 (三) 15:31 (UTC)[回复]

意見大致同Liu116閣下及痛心疾首閣下。若方針無人執行，增加再多規範也是無用。—— Eric Liu_{創造は生命（留言．留名．學生會）} 2021年4月21日 (三) 12:57 (UTC)[回复]

過濾器能不能幫忙？SAN MO SA _Σουέζ 2021年4月22日 (四) 04:07 (UTC)[回复]

@Sanmosa：可以设立过滤器“标签”“條目同時存在多於五條影片”的情况；但是既然方针规定“一個條目一般不應同時存在多於五條影片”，设立过滤器加以警告乃至阻止就需要社群共识后才能设立。--Antigng（留言） 2021年4月22日 (四) 05:51 (UTC)[回复]

@Antigng：既然技術上過濾器能幫忙，我嘗試徵求社羣對過濾器的意見，有共識的話就有勞你代為設立了。SAN MO SA _Σουέζ 2021年4月25日 (日) 08:07 (UTC)[回复]

@Liu116、痛心疾首、Yangwenbo99、Ericliu1912：不好意思，最近疏於關注了。上面Antigng指出了技術上可以以過濾器防止條目同時存在多於五條影片（我估計技術上也可以以過濾器防止加入曾被移除的影片），因此我建議設置過濾器，阻止使條目同時存在多於五條影片的操作，並對加入曾被移除的影片的操作予以警告，同時對此兩類操作予以標籤。相信此提議應可增強相關方針的執行力度，還請各位發表意見。SAN MO SA _Σουέζ 2021年4月25日 (日) 08:07 (UTC)[回复]

加入超過五條影片，偶爾也是合理的。例如化学史的條目，如果有編者分別為不同時期的歷史製作影片並放入對應章節，那麼即使超過五條也依舊可以接受。使用過濾器強制條目中影片數量少於五條則完全否定了這種行為的正當性，並且會衍生大量技術問題。例如，有編者將原本冗長的一條影片提換成兩條截取至原影片的精煉影片，則可能因為增加影片被阻攔。私以為過濾器可以用於提供警告，但不適宜直接禁止。--Yangwenbo99^{論文} 2021年4月25日 (日) 08:46 (UTC)[回复]

@Yangwenbo99：此情況罕見。而且方針已明定加入超過五條影片者要給予合理解釋，也即是須先取得社羣共識方得為之。這種情況下，應先取得社羣共識，然後到過濾器錯誤回報區請求代為加入。（另一辦法是對所有使條目存在超過五條影片的編輯予以警告。）SAN MO SA _Σουέζ 2021年4月30日 (五) 05:35 (UTC)[回复]

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

关于“个人贡献”之“机械翻译工具”所衍生问题相关讨论及方案探讨

“请勿使用机器翻译翻译条目，无论使用哪种机器翻译软件或网站，条目的质量通常都会差到让人难以理解。我们强烈不建议在机器翻译基础上进行编辑。”

如题，见维基百科:翻译指引#翻譯注意事项。是否需要为避免机翻或以此衍生相关的问题（如是否可将此视作“特例”）为由增修该指引或者废除“翻译”页面之机械翻译工具？ - 维基百科，自由的百科全书 (wikipedia.org)--維基百科最忠誠的反對者（留言） 2021年4月21日 (三) 18:49 (UTC)[回复]

否，答案是否定的，有時翻譯整篇條目會很花時間，有這樣工具的協助，能縮減使用者翻譯的時間，最後可能只需要改一下語氣、用詞和通順度而已。您在這發起討論也沒用，全域幾乎都有開啟翻譯工具，應該不可能只讓中文維基百科成為例外。更何況，如果機器翻譯後，修改的部分沒有很多，也不會讓您發布條目。空氣小貓（留言） 2021年4月22日 (四) 02:20 (UTC)[回复]

是，一來這種工具的存在是鼓勵翻譯者不查看外文版原始文獻，即將條目連帶來源整個搬運過來，如外文版本中有錯誤（錯誤解讀文獻、或文獻無法佐證條目內容等），會直接將其錯誤移植到中文維基之中；二來使用此工具再「改一下語氣、用詞和通順度」而成的條目正是相當危險、完全不值得鼓勵的，英翻中的機器翻譯技術仍不成熟，翻譯結果充滿錯誤難以參考，使用機器翻譯後再人工修改（假設翻譯者中文功力了得，可以完全解決翻譯腔的問題），可能消除了翻譯腔，卻產生「通順的錯誤內容」，後者對中文維基的危害顯然更大。

但是如上所述，全域幾乎都有開啟翻譯工具，基金會本身也非常支持這些工具的開發，所以我們在這裡討論也不會有什麼作用.....--Labyrinthulomycetes 🧬 2021年4月22日 (四) 06:58 (UTC)[回复]

只停用機器翻譯是可行的。--Xiplus#Talk 2021年4月22日 (四) 09:15 (UTC)[回复]

遇到看不懂的、拙劣翻譯的條目提刪不就好了。--Googol19980904（留言） 2021年4月23日 (五) 03:31 (UTC)[回复]

@靖天子：您覺得DeepL翻譯的翻譯品質如何？--Googol19980904（留言） 2021年4月23日 (五) 07:59 (UTC)[回复]

沒有用過，不清楚。但即使比現有的機器翻譯工具好，我仍不認為應該用來寫作條目。因為即使是翻譯條目，也應該是個「編譯」的過程，即重新組織、增減、修改原文的內容（過程中經常需要參考其他文獻），而非直接將條目翻到中文。熟悉外文的人，直接翻譯會比使用機器翻譯再修改快得多，而不熟悉外文的人使用機器翻譯就更危險了。--Labyrinthulomycetes 🧬-分生全掃 2021年4月23日 (五) 09:24 (UTC)[回复]

1. 直接翻译和依托外文条目重新整理和编译我认为是两回事，如书籍的译者至多调整一些顺序、添加译注，而不太会较多改变原文和新增内容。2. 熟悉外文的编者自然有，但可能不少人没兴趣将“一看就懂”的条目译到中文维基，并也有不熟悉中文用语等情况。3. 直接翻译时，确实有缺乏查证的情况，除非译者特别认真，或者熟悉该主题而注意到不对劲。但同样，如果译者自行查证和修订谬误，也可能产生误读等现象，而且很多人不对修改处做注明，以及未修改外文版本而造成不统一、缺乏评审。谬误及传播主要还是相关条目缺乏足够关注和良好评审。4. 对于停用翻译工具是否能减少劣质翻译的条目，我持怀疑态度。--YF dyh000（留言） 2021年4月25日 (日) 22:27 (UTC)[回复]

(▲)同上。空氣小貓（留言） 2021年4月27日 (二) 09:09 (UTC)[回复]

這裡應該有兩個層面的問題，一個是外文版原文本身的問題，一個是翻譯過程產生的問題。1.像翻譯書籍般的翻譯條目，主要的前提是原文版條目內容正確無誤，可以直接翻譯過來，然而很遺憾的，英文維基的內容遠非如此，就我閱讀、翻譯英文版一些專業條目的經驗，除了少數數條特例，幾乎沒有可以直接翻譯過來的條目，有些是內容編排不妥，有些直接有內容錯誤，有些乾脆整個離題，令我經常邊寫邊罵英文版條目品質差勁，中文版是人力缺乏，你們人力充足怎麼還寫成這樣（離題了，發個牢騷）。我不是主張不要翻譯，或原創好於翻譯，而是說我們應該「不只是」翻譯，而是必須有個「編譯」的過程，自己去思考、查證英文版條目是否有不妥之處。當然可能是我看的條目領域問題，可能還是有些條目，特別是優良或特色條目可以像翻譯書籍那樣直接翻譯過來，不改变原文和新增内容，但多數條目（至少是許多條目）沒有這種捷徑。2. 沒有看懂您的意思，您是指因為很多編者不熟悉外文，內容翻譯工具對他們有幫助？ 3.假設原文有5個錯誤，譯者查證過程可能通通發現，可能發現3個，總之都比直接翻過來不修正的好。如果是原文沒有錯，譯者自己誤解而改出了錯誤（您是這個意思吧），那顯然譯者不熟悉該主題，不應該翻譯該條目。至於修改外文版本，如果英文版是小筆誤我會隨手修改，如果是整段寫壞了則愛莫能助。 4.這個大概是每個人觀點不同。

不過我很想請教一件事，「內容翻譯」的功能到底對譯者有什麼幫助？如果幫助是如上面所講「有時翻譯整篇條目會很花時間，有這樣工具的協助，能縮減使用者翻譯的時間，最後可能只需要改一下語氣、用詞和通順度而已」，為何認為這樣的寫作方法不會產生翻譯錯誤？我很想聽聽支持者對此的看法。--Labyrinthulomycetes 🧬-分生全掃 2021年4月28日 (三) 10:36 (UTC)[回复]

@靖天子：可以將新條目自動連接到wikidata、直接翻譯category和[[xxx]]、直接建立{{Translated page}}--Googol19980904（留言） 2021年4月28日 (三) 10:55 (UTC)[回复]

@靖天子：从维基百科作用本身来说，追求内容完美是一个颇有难度的理想，读者需对条目抱有参考而非听信的态度，并在有怀疑时提出质疑或修改。即便是通过评审的优质条目，亦难保证内容未被破坏或存有问题。所以，我不认为‘直接翻译’的门槛需要过高，准确表达了原始正文即满足基本要求，内容在专业性、准确性乃至全面性等方面的提升应该交给同行评审/专业人士/提升计划，并在发现问题时一道指出和尽量跟进原文的修订，而不须竭力保证译本的完美、有所改进。2. 用上工具有助于对比原文和译文（如发现遗漏或笔误）、了解全文概况（虽然应该在翻译前通读，但并无强制性）、自动保存草稿、延缓处理源码及格式，对于未达到{{user en-3}}或以上级别的译者以及不精通维基源码的编者来说，我认为有所帮助。3. 发现错误理应纠正，但纠正的部分应作指明乃至经过评审（比如同时修订原条目），因为确实存在译者想当然而出错的情况，这与水平相关但不绝对。对于查证所有来源和重新编译，见上文，我认为这是进阶任务。对基于机翻的结果来修改润色是否会导致误译，这在不同领域下可能有很大差异，专业性条目下或应避免，但我建议交由相关专题作规范处理，避免一刀切。而普通知识、程式化内容的总结归纳，机翻的结果不一定比人工翻译差太多，人工翻译更可能掺杂不标准的口语和译法。--YF dyh000（留言） 2021年4月29日 (四) 11:04 (UTC)[回复]

雖不完全贊同，但可以理解您的意思，感謝分享。--Labyrinthulomycetes 🧬-分生全掃 2021年4月29日 (四) 23:10 (UTC)[回复]

我在站內遇到過人工翻譯出錯而機翻比人工翻譯更好的情況，比如Jarodalien的這筆翻譯「Frederick again called for a British naval deployment in the Baltic to deter Russia and an increasingly unfriendly Sweden, though nothing came of it.」，被他翻譯成「腓特烈二世再度呼吁英国海军进驻波罗的海，威慑俄罗斯和越来越敌视普鲁士的瑞典，不过瑞典始终没有从海上加入战斗。」，deepl翻譯成「腓特烈再次呼吁英国在波罗的海部署海军，以威慑俄罗斯和日益不友好的瑞典，但没有任何结果」。Comrade John建議翻譯為「腓特烈二世再度呼吁英国海军进驻波罗的海，威慑俄罗斯和越来越敌视普鲁士的瑞典，但英国对此置若罔闻。」[8]，若是閱讀deepl機翻的結果，可以準確理解意思，Comrade John的推薦結果和機翻意思相差不大，而Jarodalien的翻譯則已扭曲英文原意。--Googol19980904（留言） 2021年4月29日 (四) 16:59 (UTC)[回复]

採行方案

鉴讨论有一周有余，对上述问题的意见可包括：

項目	认为违反方针指引	认为不违反方针指引（或某些情况下可作为特例）
各方論述	此类编辑工具涉嫌鼓励用户在不查询外文文献的前提下直接挪用、且翻译工具并不具有可靠性，容易拉低条目品质（质量）哪怕使用此相对良好的翻译工具并进行润色翻译也不值得鼓励，引起可能产生「通順的錯誤內容」相较于明显的翻译错误（及不通顺）的内容危害更大。	此类编辑工具有時翻譯條目會消耗较多的时间，有该工具的協助，能縮減翻譯；另只需改善語氣、用詞和通順度即可。直接翻译或参考外文条目翻译应该区分，另对停用翻译工具是否能减少劣质翻译的条目持怀疑。
所屬支持者	靖天子	Googol19980904、Pseudo Classes、YFdyh000

现拟定四个方案供各位参考，请在各方案底下以支持行之，不接受反对。此次表態僅作為參考，用意在篩選主流意見與/或排除顯然不受大多數使用者支持的方案，將在最後一位使用者表態後七日進行統整。

一、违反方针指引，依据维基百科:翻译指引#翻譯注意事项将其关闭。

二、不违反方针指引，可修改Wikipedia:翻譯指引内容，将可以“减少翻译时间”之类理由允许用户使用机械翻译。

三、现阶段得不到社群共识，日后讨论，但因与现行方针指引冲突暂时关闭机械翻译选项。

四、现阶段得不到社群共识，日后讨论，不用关闭机械翻译选项。

各方案均应欢迎反对意见，不应剥夺用户对各方案提出反对意见的权利，这本就是表决进程应尽之义务。再有表决时各方案同时欢迎赞成和反对意见有利于对比各方案赞成和反对意见的比例以及各用户对各方案的赞成或反对倾向，更易于总结表决结果。另由衷感谢Xiplus之查证。維基百科最忠誠的反對者（留言） 2021年4月28日 (三) 09:11 (UTC)[回复]

@Pseudo Classes、@靖天子、@Googol19980904、@YFdyh000。也欢迎之后的用户参与讨论。--維基百科最忠誠的反對者（留言） 2021年4月28日 (三) 09:18 (UTC)[回复]

你應該做的是，加強提案的說服力，好讓持反對意見的我們能夠被說服，不要動不動就發起表決或投票，投票不能代替討論。空氣小貓（留言） 2021年4月28日 (三) 09:24 (UTC)[回复]

@Pseudo Classes您好，首先十分感谢您参考了我的名字所提出的合理要求，然而在这次提案由于各位的反对/支持理据均有道理，故我本人将在此次讨论中持中立态度。另外，对相关方案采行讨论并非是投票，而是请各位对方案内容提出建设性发言。如果主流意见没有形成，我本人也不会贸然开启投票。另我将把主题更名为《就翻译方针之机械翻译的内容规范讨论》--維基百科最忠誠的反對者（留言） 2021年4月28日 (三) 09:39 (UTC)[回复]

別玩語文遊戲，難道「表決」就不是投票的一種形式？你之前也有將討論認為是投票的前科。空氣小貓（留言） 2021年4月28日 (三) 17:39 (UTC)[回复]

你要發起民意調查我沒意見，但是請注意，「民意調查」和「表決」是截然不同的方式。如果你發起的是民意調查，那麼你的用詞有錯誤。空氣小貓（留言） 2021年4月28日 (三) 17:43 (UTC)[回复]

原谅我本人在措辞上的疏失，我稍后会修正。維基百科最忠誠的反對者（留言） 2021年4月29日 (四) 16:02 (UTC)[回复]

四。减少翻译用时“可能”是事实，亦可能不是，双语精通的译者可以阅读原文并查证来自制译本，所以不必写入指引，也无需鼓励或抑制工具，加强对条目翻译和译者的评审才是核心。--YF dyh000（留言） 2021年4月28日 (三) 10:02 (UTC)[回复]

這個不用繼續討論了吧，顯然只有我支持移除，大多數人應該是反對的（應該遠不只上面幾位發言的），所以我也只是來發個牢騷而已。--Labyrinthulomycetes 🧬-分生全掃 2021年4月28日 (三) 10:36 (UTC)[回复]

我的意見是三。我認為長遠而言應為機械翻譯設立具體的細則指引，以協助新用戶正確利用機械翻譯工具。SAN MO SA _Σουέζ 2021年4月30日 (五) 05:39 (UTC)[回复]

如果是三的話，需要說明一下，是可以使用翻譯頁面，但不提供機械翻譯工具。不過鑒於目前各個語言都默認開啟機器翻譯工具，在達成共識前不如維持現狀，也就是第四種方案。--Googol19980904（留言） 2021年4月30日 (五) 06:41 (UTC)[回复]

有關在條目導入新聞影片的一些規範

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:文件使用方针。

如題，結合先前引起討論大量使用中新社的問題，參考WP:IUP、WP:RS、WP:BIAS的條文，希望在這類新聞影片導入條目後，應透過模板加註其新聞機構所在地與其性質，例如「朝鮮中央通訊社是朝鮮民主主義人民共和國的官方媒體」、「香港電台是香港特別行政區的公共廣播」、「朝日放送是日本的商業廣播」等加註事項，不知道這類能否有一規範並在模板中實現，讓維基百科的閱讀者進一步瞭解這些媒體資源的來源。（@Xiplus、AnYiLin：另外標記現在活躍的技術相關編輯參與討論）--🍫巧克力～✿ 2021年4月23日 (五) 04:28 (UTC)[回复]

重點是不應該在不需要的地方匯入影片，當然也要限制政治性影片的匯入。--Newbamboo（留言） 2021年4月27日 (二) 12:31 (UTC)[回复]

修订WP:CAT

原文：分类条目时一定要注意Wikipedia:中立的观点。除非显而易见而且没有争议（例如张国荣一定是香港人），不然不要对条目归类。请您宁可先到分类的讨论页提出问题，也不要贸然分类。

建议版本一：分类条目时一定要注意Wikipedia:中立的观点。除非社群没有争议（例如张国荣一定是香港人），不然不要对条目归类。请您宁可先到分类的讨论页提出问题，也不要贸然分类。

建议版本二：分类条目时一定要注意Wikipedia:中立的观点。除非可靠来源没有争议（例如毛泽东是极权主义领导人在可靠来源中没有争议），不然不要对条目归类。请您宁可先到分类的讨论页提出问题，也不要贸然分类。

建议版本三：分类条目时一定要注意Wikipedia:中立的观点。除非社群和可靠来源没有争议（例如张国荣一定是香港人），不然不要对条目归类。请您宁可先到分类的讨论页提出问题，也不要贸然分类。

请诸位选择吧！以上。Fire Ice 2021年4月23日 (五) 05:07 (UTC)[回复]

先說我(－)強烈反对，你怎樣定義「可靠來源沒有爭議」？我給了六個可靠來源你仍然死撐「不符合」。通過了這個版本以後來一個人什麼都不用証明，只說一句「我反對」就不能加入，還不是永遠都不用加入負面分類了？-某人✉ 2021年4月23日 (五) 05:41 (UTC)[回复]
- 你的来源本来就没说明毛是极权主义领导人，Aronlee90给的来源才可以，要照版本二这就可以通过。我不过是澄清一下指引，你反对哪个版本呢？Fire Ice 2021年4月23日 (五) 05:49 (UTC)[回复]

先帝貴妃皆寂寞，荔枝何需入長安？--Newbamboo（留言） 2021年4月23日 (五) 06:10 (UTC)[回复]

参考英文指引，为页面分类指引引入可查证性的要求，同时引入Uncited category维护模板的提案

问题的提出：

近期IRC和站内对特定条目是否应该加入特定分类的问题有一些争议。有用户于IRC主张“cat的添加不像条目一样需要citation needed”，因此“受到的限制较少”。查阅现行本地页面分类指引，其已于相应章节阐明条目的分类也须遵守中立性原则：

“

分类条目时一定要注意Wikipedia:中立的观点。除非显而易见而且没有争议（例如张国荣一定是香港人），不然不要对条目归类。请您宁可先到分类的讨论页提出问题，也不要贸然分类。

”

然而与中立性相辅相承的可查证性，该指引却未阐述；仅仅阐述中立性的要求，而没有阐述可查证性的要求，未免也会导致上方如“cat的添加不需要citation needed”的疑虑。为从根源上消除这一疑虑，可借鉴现行英文站的对应指引——其在相关章节规定：

“

Categorization of articles must be verifiable. It should be clear from verifiable information in the article why it was placed in each of its categories. Use the {{Uncited category}} template if you find an article in a category that is not shown by sources to be appropriate or if the article gives no clear indication for inclusion in a category.

Categorization must also maintain a neutral point of view. Categorizations appear on article pages without annotations or referencing to justify or explain their addition; editors should be conscious of the need to maintain a neutral point of view when creating categories or adding them to articles. Categorizations should generally be uncontroversial; if the category's topic is likely to spark controversy, then a list article (which can be annotated and referenced) is probably more appropriate. For example, a politician (not convicted of any crime) should not be added to a category of notable criminals.

A central concept used in categorizing articles is that of the defining characteristics of a subject of the article. A defining characteristic is one that reliable sources commonly and consistently define the subject as having—such as nationality or notable profession (in the case of people), type of location or region (in the case of places), etc. For example, in Caravaggio, an Italian artist of the Baroque movement, Italian, artist, and Baroque may all be considered to be defining characteristics of the subject Caravaggio.

”

现行英文指引不仅对分类的中立性有所要求，还对分类信息的可查证性提出了比一般条目内文信息的可查证性更高的要求：须考量可靠来源中描述的条目主题的“定义性特征”——即诸可靠来源为条目主题所普遍、一致地作出的定义（而不仅仅是可靠来源行文中顺带提及的一笔乃至繁杂列表中的一项）。这一更高的要求显然也有助于解决卡达君于IRC提出的关于“可以去找品質低落的文獻來幫助維基百科建立垃圾分類？”的疑虑。而对于不符合可查证性要求的分类，英文站专门设置了Uncited_category模板加以维护管理。

本人认为现行英文站的指引与维护模板有助于解决目前本地关于条目分类的部分疑虑；考虑到本地指引的行文，现将英文站相应要求整理、合并，提出如下修正案：

現行條文

一个条目可以归属于几个分类，但是归属过多的分类會失去其重心。
- 請注意基本原則：分類越多，每个分類的作用越小。
一个条目通常不应该同时既属于某个分类又属于這個類別的子分类。
- 例如：黃河不應同時被分類到Category:中國地理與Category:中國河流下。因为Category:中國河流已經歸於Category:中國地理大分類下，因此黃河只須分類到Category:中國河流下。
分类条目时一定要注意Wikipedia:中立的观点。除非显而易见而且没有争议（例如張國榮一定是香港人），不然不要对條目归类。請您寧可先到分類的討論頁提出問題，也不要贸然分類。
空的分類與只有一個條目的分類因沒有功能性，請儘量不要建立，空分類有可能會遭管理員快速刪除。
草稿页不使用分类（用户页的草稿除外），如[[Category:分类]]应当以[[:Category:分类]]（Category前加半角冒号）取代，或使用<nowiki></nowiki>包裹。用户页只添加用户页分类（如[[Category:喜欢蓝色的维基人]]），而不添加条目分类（如[[Category:XX国科学家]]）。侵权重写草稿、条目建立专题等所使用的管理维护性分类除外。

提議條文

一个条目可以归属于几个分类，但是归属过多的分类會失去其重心。
- 請注意基本原則：分類越多，每个分類的作用越小。
一个条目通常不应该同时既属于某个分类又属于這個類別的子分类。
- 例如：黃河不應同時被分類到Category:中國地理與Category:中國河流下。因为Category:中國河流已經歸於Category:中國地理大分類下，因此黃河只須分類到Category:中國河流下。
条目分类须满足可查证性的要求。为条目添加分类时，须考量可靠来源所描述的条目主题的“定义性特征”——即诸可靠来源为条目主题所作出的普遍、一致的定义。若条目分类不符合上述可查证性之要求，请以{{Uncited category}}模板标示条目。
分类条目时一定要注意Wikipedia:中立的观点。除非显而易见而且没有争议（例如張國榮一定是香港人），不然不要对條目归类。請您寧可先到分類的討論頁提出問題，也不要贸然分類。
空的分類與只有一個條目的分類因沒有功能性，請儘量不要建立，空分類有可能會遭管理員快速刪除。
草稿页不使用分类（用户页的草稿除外），如[[Category:分类]]应当以[[:Category:分类]]（Category前加半角冒号）取代，或使用<nowiki></nowiki>包裹。用户页只添加用户页分类（如[[Category:喜欢蓝色的维基人]]），而不添加条目分类（如[[Category:XX国科学家]]）。侵权重写草稿、条目建立专题等所使用的管理维护性分类除外。

同时引入{{Uncited category}}维护模板。该修改妥否？请社群审议。

--Antigng（留言） 2021年4月23日 (五) 10:01 (UTC)[回复]

支持踏出这一步。我最近注意到某（一位/一些）用户随意按自己脑中的定义便随意加政治相关分类，甚至为了阐释观点不惜违反签名指引，不断给条目加入大比重特定方面观点及与条目内容无关的参见链接，这类的事情是应该管管了。--痛心疾首 2021年4月23日 (五) 12:15 (UTC)[回复]
(＋)支持。--DavidHuai1999※Talk 2021年4月23日 (五) 16:24 (UTC)[回复]
(＋)支持，同時(＆)建議為分類參考來源規定格式。--Yangwenbo99^{論文} 2021年4月23日 (五) 17:36 (UTC)[回复]
(＋)支持。—— Eric Liu_{創造は生命（留言．留名．學生會）} 2021年4月24日 (六) 01:06 (UTC)[回复]
(＋)支持。——🍫巧克力～✿ 2021年4月24日 (六) 04:25 (UTC)[回复]
英文版Uncited category其实没多少条目使用。我认为“政治相关分类”更大问题是有些分类标准都不明确，例如Category:中國自由派就有多种不同的定义，而把不同来源定义的自由派放在一个分类有原创研究嫌疑。--GZWDer（留言） 2021年4月24日 (六) 09:13 (UTC)[回复]
- (：)回應当然这个提案不能解决所有政治相关分类的争议问题。但至少其中一部分，比如左派右派之类的，由于有不同的定义，就可能会出现一部分来源声称某人是左派领导人，但另一部分来源声称其实质上是形左实右；当来源中出现定义不一致的情况，按照第四条规则和这次加进去的第三条规则，这样的争议分类就可以避免出现在条目里。--Antigng（留言） 2021年4月24日 (六) 15:13 (UTC)[回复]
(＋)支持。--ときさきくるみ 2021年4月24日 (六) 11:08 (UTC)[回复]

{{Uncited category}}模板已导入，各位可以修改措辞及doc页面。--东风（留言） 2021年4月24日 (六) 15:39 (UTC)[回复]

(－)傾向反對：中立的观点应排在可查证性之前。若修改，请划票改为支持。--E.A.Crowley6 6 6^✍️ 2021年4月25日 (日) 04:10 (UTC)[回复]
我个人很好奇您说的这个前面是指条文内顺序的前后还是侧重度优先级的前后？如果是前者的话我觉得无伤大雅，如果是后者的话现在这个条文似乎也没有刻意强调谁在谁前面？--ときさきくるみ 2021年4月25日 (日) 04:28 (UTC)[回复]

目前出了什么问题？没坏别修。Fire Ice 2021年4月25日 (日) 10:01 (UTC)[回复]

“有用户于IRC主张‘cat的添加不像条目一样需要citation needed’，因此‘受到的限制较少’。”这本身就是一个值得纠正的问题。分类——如同另一位IRC用户所述——是在给一个条目主题贴“标签”，下“定义”，理应和内文内容一样受到可供查证方针的制约——甚至理应受到比普通内文内容更多的制约，但现行方针指引完全没有体现这一理念和精神。--Antigng（留言） 2021年4月25日 (日) 10:27 (UTC)[回复]

如果{{Uncited category}}是放在条目页，我认为有过度彰显之嫌，并可能会促成游戏维基规则（没悬挂/讨论则不能移除）。如果是放条目讨论页或单独页面并通告添加者/先行移除，我则没意见。另外当仅看标题，我以为在谈给分类页面放定义或者参考来源——如果谈这个，消歧义页也很缺且不能放来源。--YF dyh000（留言） 2021年4月25日 (日) 22:07 (UTC)[回复]

消歧義頁面一般只會從正文首段截取關鍵介紹，所以一般不會有類似問題吧。--Yangwenbo99^{論文} 2021年4月26日 (一) 00:03 (UTC)[回复]

第二稿

現行條文

一个条目可以归属于几个分类，但是归属过多的分类會失去其重心。
- 請注意基本原則：分類越多，每个分類的作用越小。
一个条目通常不应该同时既属于某个分类又属于這個類別的子分类。
- 例如：黃河不應同時被分類到Category:中國地理與Category:中國河流下。因为Category:中國河流已經歸於Category:中國地理大分類下，因此黃河只須分類到Category:中國河流下。
分类条目时一定要注意Wikipedia:中立的观点。除非显而易见而且没有争议（例如張國榮一定是香港人），不然不要对條目归类。請您寧可先到分類的討論頁提出問題，也不要贸然分類。
空的分類與只有一個條目的分類因沒有功能性，請儘量不要建立，空分類有可能會遭管理員快速刪除。
草稿页不使用分类（用户页的草稿除外），如[[Category:分类]]应当以[[:Category:分类]]（Category前加半角冒号）取代，或使用<nowiki></nowiki>包裹。用户页只添加用户页分类（如[[Category:喜欢蓝色的维基人]]），而不添加条目分类（如[[Category:XX国科学家]]）。侵权重写草稿、条目建立专题等所使用的管理维护性分类除外。

提議條文

一个条目可以归属于几个分类，但是归属过多的分类會失去其重心。
- 請注意基本原則：分類越多，每个分類的作用越小。
一个条目通常不应该同时既属于某个分类又属于這個類別的子分类。
- 例如：黃河不應同時被分類到Category:中國地理與Category:中國河流下。因为Category:中國河流已經歸於Category:中國地理大分類下，因此黃河只須分類到Category:中國河流下。
分类条目时一定要注意中立的观点。除非显而易见而且没有争议（例如張國榮一定是香港人），不然不要对條目归类。請您寧可先到分類的討論頁提出問題，也不要贸然分類。
条目分类须满足可查证性的要求。为条目添加分类时，须考量可靠来源所描述的条目主题的“定义性特征”——即诸可靠来源为条目主题所作出的普遍、一致的定义。{{Uncited category}}模板可用以标示不符合上述可查证性要求之条目分类。
空的分類與只有一個條目的分類因沒有功能性，請儘量不要建立，空分類有可能會遭管理員快速刪除。
草稿页不使用分类（用户页的草稿除外），如[[Category:分类]]应当以[[:Category:分类]]（Category前加半角冒号）取代，或使用<nowiki></nowiki>包裹。用户页只添加用户页分类（如[[Category:喜欢蓝色的维基人]]），而不添加条目分类（如[[Category:XX国科学家]]）。侵权重写草稿、条目建立专题等所使用的管理维护性分类除外。

参考@EdwardAlexanderCrowley、YFdyh000：君的意见，现提出第二稿。相较于初稿，该稿有三处调整，一是将新增条文转移至中立性条文之后；二是修改{{Uncited category}}模板相关的措辞，以减小“没悬挂/讨论则不能移除”这种错误理解/游戏规则的生存空间；三是顺手修改了中立性条文中链接的格式，以保持上下文的一致性。--Antigng（留言） 2021年4月26日 (一) 02:10 (UTC)[回复]
- (＋)支持，无意见。 E.A.Crowley6 6 6^✍️ 2021年4月26日 (一) 11:46 (UTC)[回复]
基於本案之立論言減低爭議，然有關引入查證規例實際於本地尤其於政治等領域，如条目探讨中案所指出是可以各自解讀而令爭議持續，並有淪為政治觀點審查手柄等風險。謹此，詢提案人與支持提案者等，(？)疑問是否能提出更多細節處理之方案，以避免本案淪為新的爭議催化劑？如無法遏制有關爭議之嚴重風險，本案之立基即難以可信，而本編會維持(－)反对存有有關風險之本案。——約克客（留言） 2021年4月27日 (二) 02:46 (UTC)[回复]
- 第一，您所列举的讨论——即使假定相关用户的言论属实——也至多能证明“可供查证方针在特定情况下无法减少争议”，而不能证明您所疑虑的“可供查证”“淪為新的爭議催化劑”。逻辑上，无法减少争议不等同于加剧争议。
- 第二，争论与争论亦有所不同，有的争议比另一些更具有建设性。在可供查证的框架下，编者之间的争议是以列举来源、列举事实、评估来源可靠性的方式体现的。如无可查证性之要求，编者纯粹叙述个人意见想法，亦能成为争议的焦点。即使可查证性不能缓解特定领域的争议的“激烈程度”，将争论限定为事实与来源之争，也显著地提高了争论的质量。+1 Tokisaki Kurumi为此+1了。
- 此外，本案引入的查证性标准甚于一般内文内容的查证性标准：本案明确规定条目分类需考量“诸可靠来源中普遍、一致作出的定义”，出现来源中定义不一致的情况、抑或是来源间接带过而未有明确下定义的情形，均不支持分类的列入。如IRC上一位用户所言，添加分类是在为条目主题“下定义”，言下之意为不可不慎；在维基百科的框架下，这种慎重理所当然地应该体现为“可靠来源下了定义，维基百科才能下定义”，亦即本提案的精神。比内文内容更高的可查证性标准理应更有助于消减相关争议，和/或改善争议的质量。--Antigng（留言） 2021年4月27日 (二) 07:10 (UTC)[回复]
  - 如是閣下所言，於{{Uncited category}}模板應同時體現本案之立論與所倡精神。查模板新晉仍有同步改進之空間，基於提案人詳述，即引用有關修訂該模板，一併審視增益足否。——約克客（留言） 2021年4月27日 (二) 23:31 (UTC)[回复]
    - Longway22阁下的修订参见此处，在下做了修改，不知可否，还请一并审阅。--痛心疾首 2021年4月28日 (三) 00:38 (UTC)[回复]
      (＋)支持这个动议。我唯一不太明白的是，如何为分类提供来源？在实际编辑中如何进行？--百無一用是書生 (☎) 2021年4月28日 (三) 03:00 (UTC)[回复]
- (：)回應：我认为，可以在条目内容引文中提供，如果编辑争议产生，在这样的方针下，双方可以在讨论页面讨论并交换相关的来源。--痛心疾首 2021年4月28日 (三) 07:04 (UTC)[回复]
  - 謝痛心疾首閣下跟手，以之基礎再修訂參，期更準確反映修正案之意願與精神。——約克客（留言） 2021年4月28日 (三) 07:40 (UTC)[回复]
  能否提供几个实例观摩一下？--百無一用是書生 (☎) 2021年4月29日 (四) 02:11 (UTC)[回复]
- 在维基百科的语境下，可供查证有两个层次的含义：一是所有百科条目的内容，都必须有支持其的可靠来源存在（而无论是否文内引注）（ en:WP:V: This means all material must be attributable to reliable, published sources. ）；二是对任何可能引起或已经引起争议的内容，都须以文内引注的形式标示（en:WP:V: Additionally, quotations and any material challenged or likely to be challenged must be supported by inline citations.）。具体运用到分类问题上，大部分不引起争议的分类以条目内文中的来源及其所提供的可供查证信息加以证明即可，如痛心疾首君所言；对于少数引起争议的分类，则可通过在分类后面加注释标明来源的方式满足引注的要求。--Antigng（留言） 2021年4月28日 (三) 13:39 (UTC)[回复]
  在分类后面加注释，可行吗？--百無一用是書生 (☎) 2021年4月30日 (五) 03:05 (UTC)[回复]
  做了一个测试User:Shizhao/Uncited category，似乎在分类后面加注释行不通？--百無一用是書生 (☎) 2021年4月30日 (五) 03:09 (UTC)[回复]
  在下所指的注释是，在页面中以<!--的形式标注来源，不是reftag。--Antigng（留言） 2021年4月30日 (五) 03:50 (UTC)[回复]

WP:封禁方针,WP:傀儡增修

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:封禁方针、Wikipedia talk:傀儡。

由于本人提案修改{{sockpuppeteer}}模板，它的更改将会影响到用户页的标记。故提案之。

修改如下：

現行條文

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

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

提議條文

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

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

現行條文

如主帳號未被封禁及標記，請根據以下程序標記：

`一、`	決定封禁時間－管理員可根據下列條件決定主帳號的封禁時間：如未被封禁：按傀儡的嚴重性，決定封禁時間——可以是有限期或無限期（永久）封禁。如操作傀儡時主帳號已被有限期封禁：按傀儡的嚴重性，決定重新開始計算及/或延長封禁時間。如主帳號已被無限期（永久）封禁：維持原狀，毋須處理。
`二、`	封禁主帳號－在Wikipedia:當前的破壞頁面對應的處理申請點擊主帳號的「封」連結以設定封禁。封禁時間按第一段的規則決定。
`三、`	標記主帳號的用戶頁－除非有特別指示，主帳號如未被標示，需要按以下規則在用戶頁加上標示。如主帳號被有限期封禁，請不要替換主帳號用戶頁的內容。經用戶查核確定操作傀儡的主帳號：將主帳號用戶頁的所有內容替換為`{{sockpuppeteer\|blocked\|checked=yes}}`。未經用戶查核而確定操作傀儡的主帳號：將主帳號用戶頁的所有內容替換為`{{sockpuppeteer\|blocked}}`。

提議條文

如主帳號未被封禁及標記，請根據以下程序標記：

`一、`	決定封禁時間－管理員可根據下列條件決定主帳號的封禁時間：如未被封禁：按傀儡的嚴重性，決定封禁時間——可以是有限期或無限期（永久）封禁。如操作傀儡時主帳號已被有限期封禁：按傀儡的嚴重性，決定重新開始計算及/或延長封禁時間。如主帳號已被無限期（永久）封禁：維持原狀，毋須處理。
`二、`	封禁主帳號－在Wikipedia:當前的破壞頁面對應的處理申請點擊主帳號的「封」連結以設定封禁。封禁時間按第一段的規則決定。
`三、`	標記主帳號的用戶頁－除非有特別指示，主帳號如未被標示，需要按以下規則在用戶頁加上標示。如主帳號被有限期封禁，請不要替換主帳號用戶頁的內容。經用戶查核確定操作傀儡的主帳號：將主帳號用戶頁的所有內容替換為`{{sockpuppeteer\|checked=yes}}`。未經用戶查核而確定操作傀儡的主帳號：將主帳號用戶頁的所有內容替換為`{{sockpuppeteer}}`。

--Creeper Digital 1903 2021年4月24日 (六) 02:38 (UTC)[回复]

(＆)建議:上次提案通過後，根本就沒有管理員會掛傀儡模板，結果要我一個人去處理，方針形同虛設，所以建議就方針的強制性字眼「務必」改為「建議」，除非TW已經有相應的修訂能配合方針。--蟲蟲飛♡♡→♡℃※留言 2021年4月24日 (六) 05:43 (UTC)[回复]

完成--Creeper Digital 1903 2021年4月24日 (六) 07:27 (UTC)[回复]

幫您修正了筆誤。--蟲蟲飛♡♡→♡℃※留言 2021年4月24日 (六) 11:06 (UTC)[回复]

“如主账户未被封禁及标记，请根据以下程序标记：”程序是啥？页面上看不到。--痛心疾首 2021年4月28日 (三) 09:41 (UTC)[回复]

可能要把所有 | 替换成 {{!}} 才看得到？-- ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月28日 (三) 10:18 (UTC)[回复]

感谢提示，已经直接这么改了。--痛心疾首 2021年4月28日 (三) 13:19 (UTC)[回复]

对该案前因后果进行了解后，更新了上面的部分内容后，初步认为(－)反对本提案。原因：代码的历史太过悠久，直接改可能会影响机器人，且相关变更是否必要依然有待商榷。--痛心疾首 2021年4月28日 (三) 13:28 (UTC)[回复]

正因為如此，編輯請求反倒是不知道該如何處理。空氣小貓（留言） 2021年4月29日 (四) 16:33 (UTC)[回复]

@Pseudo Classes：此時應否決編輯請求。SAN MO SA _Σουέζ 2021年4月30日 (五) 05:55 (UTC)[回复]

@Sanmosa：拒絕編輯請求要有合理的原因，然而目前沒有，硬要說的話，也只有「編輯請求影響的範圍太大」，轉交到客棧討論這樣。空氣小貓（留言） 2021年4月30日 (五) 12:13 (UTC)[回复]

再次推动破坏者（LTA）成为名字空间

首批伪名字空间已行月余，我希望推动LTA成为真·名字空间。好处是可以设置所有页面为NOINDEX，增设页面查看权限（体现WP:RBI），且不会被其他名字空间的设置档左右。此外，LTA与Project空间联系性不大，没有维护问题。

至于LTA页面数量少。窃以為設立名字空间没有页面数量门槛。另附先前讨论之部分内容：

“

如果用户不可查看的名字空间不会显示在Special:搜索，我想名字空间多不是个大问题。

”

——User:YFdyh000

“

本議案可能須分階段討論，要討論的項目有：

是否需要默認關閉LTA頁面的Special:搜索？（mw:Manual:$wgNamespacesToBeSearchedDefault設定）
是否需防止LTA頁面被機器人或網路爬蟲索引？（mw:Manual:$wgNamespaceRobotPolicies設定）
是否需設定LTA頁面的檢視權限？（例如，只有自動確認用戶、巡查員、回退員、管理員能檢視/訪問這些頁面，需引入mw:Extension:Lockdown。User:GZWDer：根据之前的一些Task維基媒体不会启用mw:Extension:Lockdown。但是如果只是为了避免WP:BEANS而没有保密需求那么用CSS屏蔽掉内容显示即可。）

等。如具備以上需求，才有必要定為名字空間。

”

——User:A2569875

以上。 ——羊羊 [ 留言贡献维猫报古典音乐专题 ] 2021年4月24日 (六) 14:35 (UTC)[回复]

隨著討論發展，由於確有如此需求，我不反對設LTA為真命名空間。SAN MO SA _Σουέζ 2021年4月25日 (日) 08:34 (UTC)[回复]

(1) wgNamespacesToBeSearchedDefault本來就預設條目空間，Wikipedia空間本來就不在列，等於LTA頁面目前就是預設關閉的，增設命名空間沒有改變現狀。 (2) 目前所有LTA頁面都透過NOINDEX魔術字來指示爬蟲不索引了，增設命名空間沒有改變現狀。 (3) 可能是好主意，但沒有有效的技術手段達成（安裝擴充功能無望，CSS相當容易繞過...等）--Xiplus#Talk 2021年4月25日 (日) 09:48 (UTC)[回复]

基於WP:BEANS，應該還是要隱藏一下（（（-- Sunny00217 2021年4月25日 (日) 11:44 (UTC)[回复]

如果僅用CSS，不需增設命名空間也能達到，這樣上方所列的三個需求都不需要增設命名空間了。--Xiplus#Talk 2021年4月26日 (一) 09:21 (UTC)[回复]

會搜到重新導向頁面？SAN MO SA _Σουέζ 2021年4月30日 (五) 06:03 (UTC)[回复]

同Sanmosa意見，如現在確實有此需求，不反對設立，反正設這個沒有WPJ那麼亂XD--LuciferianThomas．留言 2021年4月26日 (一) 09:12 (UTC)[回复]

@LuciferianThomas：WPJ麻煩的是移動和模板模組處理而已，吧？-- Sunny00217 2021年4月26日 (一) 09:47 (UTC)[回复]

第三点同Xiplus。要真正实现仅特定用户组可查看，只能通过后端。在判断逻辑甚至页面内容都已经发给前端情况下…是在掩耳盗铃。--安忆 ^Talk 2021年4月27日 (二) 11:44 (UTC)[回复]

如果目的在避免普通访客被记载方式干扰和误导，而非保密性，掩耳盗铃未尝不可。类似，具有权限要求的某些内容（如已删除版本）或功能（如回退），并不限制其他用户用别的手段做到。--YF dyh000（留言） 2021年4月28日 (三) 09:56 (UTC)[回复]

只要求在表面上看不见全放在前端当然没什么问题。（另，回退不要后端鉴权吗？）--安忆 ^Talk 2021年4月28日 (三) 12:40 (UTC)[回复]

js可以實現與回退效果幾乎等價的操作。—- 五歲抬頭雪菲（☎️·☘️） 2021年4月28日 (三) 13:05 (UTC)[回复]

加個class？--LuciferianThomas • 留言 2021年4月28日 (三) 22:45 (UTC)[回复]

修改拉票与游戏维基规则为不要拉票与不要游戏维基规则，并规范此类命名

这是两个是中文维基百科的态度指引，但是命名（名字）可能会造成误解，让人以为“去拉票/拉票是可以的”同时标题下方声明这是“中文维基百科的态度指引”，以及处于Category:維基百科態度指引内。那么视觉效果就是 “拉票 ----- 是中文维基百科的态度指引”以及 “维基百科态度指引 ---- 拉票”会对新手（以及只读标题而不看内容的人）造成误导。游戏维基规则同理。

同时提议今后命名此类 “不要做某事”时的方针命名前方加上否定语，如 “不要”/“请勿”之类。 --向宇宙探索！ 2021年4月26日 (一) 11:32 (UTC)[回复]

出于技术原因，擅自在不改变语义的前提下代为修改了少数内容，尚祈见谅。--痛心疾首 2021年4月28日 (三) 13:32 (UTC)[回复]

一般正常人认知里面，不会认为游戏规则和扰乱投票秩序是好的吧？--痛心疾首 2021年4月27日 (二) 07:33 (UTC)[回复]
(▲)同上。空氣小貓（留言） 2021年4月27日 (二) 09:12 (UTC)[回复]
但是我个人认为此举是有益无害的，因为真的有一堆人只读标题。。。。如果保持现状的话会造成一定的误解与混乱。--向宇宙探索！ 2021年4月27日 (二) 12:06 (UTC)[回复]

只讀標題也不是維基的錯啊！那這樣WP:闖紅燈這個快捷方式應該刪除掉嗎？而WP:是英文維基說的！應該改名WP:「是英文維基說的！」不算理由嗎？然後WP:是《是英文維基說的！》說的！就要跟著改名WP:「是《「是英文維基說的！」不算理由》說的！」不算理由？-游蛇脫殼/克勞棣 2021年4月27日 (二) 12:53 (UTC)[回复]

个人认为阁下所举例的两个例子都只是论述，而拉票与游戏维基规则是中维的态度指引。也就是说，新人跳入维基百科社区后，会在早期被导向WP:CAN与WP:GAME（作为编辑百科的指导），而不是WP:RTRL。那么一个明确而清晰的名字（同时避免出现“维基百科态度指引 ---- 拉票”的误导）会更加freshman-friendly。--向宇宙探索！ 2021年4月27日 (二) 18:11 (UTC)[回复]

如是說，那麼Wikipedia:傀儡不就要改為「不要使用傀儡」了嗎？我相信要改絕對改不完，更何況目前也未見標題引起任何問題。請注意，只看標題而誤會是使用者自身的問題，看完內文還能誤會就該重學中文了。空氣小貓（留言） 2021年4月28日 (三) 02:23 (UTC)[回复]

單一改命名似乎未有太大作用，建議提案要再更多可實際操作的細節，才比較有可持續的討論方向--約克客（留言） 2021年4月28日 (三) 07:45 (UTC)[回复]

编者阅读理解有问题，是不是只能靠标题才能让你的鼻子保持畅通？为什么改了不会诱发逆反心态？这更像是没坏别修的问题。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年4月28日 (三) 09:38 (UTC)[回复]

同以上。不要破坏、不要假冒签名、不要骚扰。--YF dyh000（留言） 2021年4月28日 (三) 09:52 (UTC)[回复]

意見同上諸位。—— Eric Liu_{創造は生命（留言．留名．學生會）} 2021年4月28日 (三) 13:44 (UTC)[回复]

修订Wikipedia:命名常规 (化学)

提议背景：规范中文维基百科化学物质条目名称，避免未经社群讨论的移动。

新增条文以绿色底色标出。

化学物质

元素

已發現的化學元素有對應中文漢字名稱者，使用該中文漢字名稱（例如「鈇」）為條目名，否則以IUPAC公佈的元素符號為條目名（例如「Fl」）；未發現的化學元素依IUPAC元素系統命名法對於未發現元素的命名的縮略寫法為條目名（例如「Uuq」）。IUPAC公佈的已發現元素全名、未發現的化學元素依IUPAC元素系統命名法對於未發現元素的命名的全名，以上提及的所有可接受命名（如適用），以及X號元素（X為對應化學元素的原子序）可作為指向對應化學元素條目的重定向。

化合物

当一种物质有通用名时，优先使用通用名，如甲基黄优先于“N,N-二甲基-4-(苯偶氮基)苯胺”。如果有多种同一优先度的命名法可以适用于同一种物质，那么通常应该尊重条目创立者的意愿。如2-氯苯酚与邻氯苯酚可择一创建，另一个作为重定向。这一规则同样适用于因地区词差异而产生的别名。

化合物中元素价态以带括号的罗马数字表示，如钴(III)、钼(III)等。金属元素作为阳离子时，相对低价态可用“亚”表示，如Fe²⁺为亚铁，适用于加“亚”字的元素还有Cr(II)、Cu(I)、Tl(I)、Hg(I)、Pt(II)、Au(I)、Ge(II)、Sn(II)和Ln(II)，其中Ln为镧系元素，Ce^II除外。未提及元素价态需以带括号的罗马数字表明价态或汉字表明组成，如VF₅的条目名为氟化钒(V)或五氟化钒。阴离子中的元素存在变价元素时，可以带括号的罗马数字，或表示价态相对高低的汉字“次”、“亚”、“过/高”等命名。配合物命名一律用带括号的罗马数字，当该元素价态唯一而无歧义或存在俗名时，可省略罗马数字或用俗名命名，如二碘合银酸钾或亚铁氰化钾，其中后者也可命名为六氰合铁(II)酸钾。

化合物中无歧义的汉字或字母在条目名中应省略，如NaCl的名称为氯化钠而非一氯化钠，(CH₃)₂NCHO的条目名称为二甲基甲酰胺而非N,N-二甲基甲酰胺（该化合物的甲基只能接在氮原子上）。化合物中有多个阳离子或阴离子时，以电负性较强的前置，如PbClF为氟氯化铅，KAl(SO₄)₂为硫酸铝钾。

阴离子和阳离子以盐的形式命名，如Cl⁻的条目名为氯化物而非氯离子，SO₄²⁻的条目名为硫酸盐而非硫酸根，NH₄⁺的条目名为铵盐而非铵根离子。这些离子名可建立重定向。当离子的名称更常用时，可以离子命名，如碳正离子。分类的命名亦同。

有机化合物的取代位命名可用阿拉伯数字、希腊字母或汉字表示，不使用英文简写o、m或p，但英文简写可作为别名重定向。异、仲、叔可用汉字或以数字+取代基的方式命名，不使用英文简写。表示并环时可用字母表示，如二苯并[c,g]菲。

其余未尽规则可参考IUPAC命名或系统命名法命名。

其它

化学物质命名中所用的括号标点符号遵循IUPAC命名法的规定，标题中的“(”、“)”使用半角括号且不加空格（如：二氯化二(苯甲腈)合钯），而标题中的“[”、“]”由于技术原因需改为全角的“［”、“］”（如螺[5.5]十一烷对应的页面应命名为“螺［5.5］十一烷”，可以在该页面中使用{{DISPLAYTITLE:螺[5.5]十一烷}}来使页面标题显示正确）。

--Leiem（留言·签名·维基调查） 2021年4月27日 (二) 17:12 (UTC)[回复]

想請問一下，順式和反式異構化合物的是在最前方加上順反就好了嗎？空氣小貓（留言） 2021年4月28日 (三) 02:58 (UTC)[回复]

是的。目前绝大部分现有条目的名称都符合修订的方针。--Leiem（留言·签名·维基调查） 2021年4月28日 (三) 03:26 (UTC)[回复]

好的，謝謝您，另(＋)支持提案。空氣小貓（留言） 2021年4月28日 (三) 04:05 (UTC)[回复]

(＋)支持。--Yangwenbo99^{論文} 2021年4月28日 (三) 06:16 (UTC)[回复]

(＋)支持。--痛心疾首 2021年4月28日 (三) 14:25 (UTC)[回复]

(＋)支持：--~~S i d~~ 2021年4月30日 (五) 06:56 (UTC)[回复]

考虑到上述规定大部分都符合维基百科内现有条目的实际情况，且符合IUPAC的命名指南，现交付公示。--痛心疾首 2021年4月29日 (四) 08:37 (UTC)[回复]

[a1-1] 1.0 ^1.1 ^1.2 使用地區詞處理至一致也算作一致。

[2] 英维古典音乐专题的Guidelines提到，An article's title should be selected to best represent what readers of Wikipedia expect. This means, among other things, that titles should be consistent for each genre. For example, a reader who has already successfully found Mozart's 40th symphony under Symphony No. 40 (Mozart) will expect that Haydn's 103rd symphony should be found under Symphony No. 103 (Haydn).

[3] 纪念古斯塔夫·马勒逝世110周年系列音乐会之二. [2021-03-28].

[4] 【海神家族與馬勒巨人】簡文彬與國臺交將以音樂帶您感受作曲家與文學家筆下的深刻情感. [2021-03-28].

[5] 贝多芬的第五号交响曲.

[6] 理论上在正文出现的括号应该用全角，哈哈

[7] Some reference works use a space-saving system where the words "major" and "minor" are omitted; a key in upper case refers to a major key, and one in lower case is a minor key. For example, "D" would mean D major, and "d" would mean D minor. Some editors confuse matters by adopting a part of this system but still spelling out the words "major" or "minor" – thus, "D major" vs. "d minor". This is inconsistent and is to be avoided. ——en:Wikipedia:WikiProject_Classical_music/Guidelines

[8] 不對提案進行實則性點評的支持意見，以及與提案本身無關的意見，皆不視作此條文所指的「新留言」。

[9] 不對提案進行任何點評的支持或中立意見，以及與提案本身無關的意見，皆不視作此條文所指的「新留言」。

[10] 不對提案進行任何點評的支持或中立意見，以及與提案本身無關的意見，皆不視作此條文所指的「新留言」。

[11] 参见Wikipedia:鐵道專題/移除著色文字模板。

[12] 参见WikiProject:鐵道/移除著色文字模板。

[13] 参见WikiProject:鐵道/移除著色文字模板。

[14] 参见WikiProject:鐵道/移除著色文字模板。

[註 1]

[1]

[2]

[3]

[4]

[5]

[6]

[1]

[1]

[1]

[1]

[1]

[1]

[1]

正在廣泛徵求意見的議題

專題命名空間

專題空間設立流程與細節

第一階段：申請

第一點五階段：內容事實修訂

第二階段：轉移至新名字空間

第二階段 之 公示狀態通告

第二階段 之 公示期討論

第二點五階段：相關技術問題修正

第三階段：修正指向專題的內部連結

第四階段：調整專題模板

第五階段：討論重新導向與捷徑的設立方式

第五階段：小結

第六階段：(暫不開放)

偽命名空間

小结1

小结2

捷徑空间提案

小結3

再提捷徑空间提案

尝试推动LTA空间

偽命名空間相關方針及WP:捷徑修正

進一步討論

自動提刪R2

MOS捷徑名稱

軟重定向

技術問題處理

自動半保護偽命名空間

提議設立快速刪除標準 O8

將LTA空間設定為noindex

WP:捷徑指引草案修訂

說明

專題命名空間問題

格式手冊及長期破壞者命名空間問題

捷徑細部修訂

有關某年代相關分類命名統一事宜

針對性決議

頁面命名一致性的通用（普遍性）條文

關於Wikipedia:命名常规 (音乐)

Wikipedia:命名常规 (音乐)1.0更新報告

Wikipedia:命名常规 (音乐)2.0更新報告

Wikipedia:命名常规 (音乐)公示

（重提）Wikipedia:共识#提案討論及公示時間的執行力度

調適案1

第一步

有關新增偽命名空間的提議

初步定案

模板颜色相关规范

變通提案

设计一个制度解决部分速删模板挂不上去的页面的删除问题

就规范部分特殊页面的删除方式征求社群建议

引入能夠在特殊頁面掛模板的模組

限縮{{电视节目的变迁}}模板使用範圍

设立过滤器禁止将维基百科用作来源

订立编辑松相关规章制度

將「青島」、「中國青島」或「山東青島」改成「中華人民共和國山東省青島」是否有必要

就「使用『中國』一詞」的權宜修正

就提及兩岸四地之下級地區作出規定

訂立影片加入相關指引

关于“个人贡献”之“机械翻译工具”所衍生问题相关讨论及方案探讨

採行方案

有關在條目導入新聞影片的一些規範

修订WP:CAT

参考英文指引，为页面分类指引引入可查证性的要求，同时引入Uncited category维护模板的提案

第二稿

WP:封禁方针,WP:傀儡增修

再次推动破坏者（LTA）成为名字空间

修改拉票与游戏维基规则为不要拉票与不要游戏维基规则，并规范此类命名

修订Wikipedia:命名常规 (化学)

第二階段之公示狀態通告

第二階段之公示期討論