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

本頁提出或讨论维基百科政策、方针，请参看方針與指引和方针列表。
繁简处理的议题请前往字词转换讨论页。
条目应当如何编辑才符合中立性原則寻求社群共识，请前往条目探讨留言。
請注重礼仪及遵守方針與指引，一般問題請至互助客棧其他區或知识问答提出，留言后请务必签名（点击）。

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

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

存檔

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 月

公告板

[討論] 第十九次动员令筹备讨论现已开始，請踴躍參與討論。
[調查] 互助客栈消息區正在就通用行为准则/2021咨询尋求更廣泛的社群意見，請踴躍參與討論。
[調查] 互助客栈方針區正在就7DAYS規則的執行力度及限制模板著色尋求更廣泛的社群意見，請踴躍參與討論。
[公告] 微調WP:DYKC投票须知行文及增訂偽名字空間的快速刪除方針已經通過。
[公告] 專題空間相關捷徑與重定向的規範及請求在全域標題黑名單增加針對不當用戶名之規則正在進行公示，如有意見請盡快提出。
[討論] 互助客栈方針區正在討論專題空間相關捷徑與重定向的規範、建立頁面命名一致性的通用（普遍性）規定、调整界面管理员方针、设立过滤器禁止将维基百科用作来源及订立编辑松相关规章制度，請踴躍參與討論。
[討論] 互助客栈技術區正在討論修改CS1系列引文格式模板、以模組改寫Namespace pagename模板及引入Legobot机器人，請踴躍參與討論。

[協作] 现有124个页面需维基化，12个条目需清理，7个移动请求正在讨论。
[獎勵] 現有4名用户獲提名维基奖励，欢迎投票。

#	話題	發言	參與	最新發言	最後更新(UTC+8)
1	專題命名空間	183	20	羊羊32521	2021-04-22 00:08
2	偽命名空間	222	18	Sanmosa	2021-04-21 11:28
3	WP:捷徑指引草案修訂	23	4	A2569875	2021-04-21 10:51
4	有關某年代相關分類命名統一事宜	46	14	Sanmosa	2021-04-21 16:59
5	請求第三方管理員參與評估和總結可靠來源討論	1	1	痛心疾首	2021-04-18 20:40
6	關於Wikipedia:命名常规 (音乐)	79	16	Milkypine	2021-04-20 18:04
7	（重提）Wikipedia:共识#提案討論及公示時間的執行力度	104	19	羊羊32521	2021-04-22 00:11
8	有關新增偽命名空間的提議	17	7	Sanmosa	2021-04-14 21:24
9	模板颜色相关规范	67	17	Milkypine	2021-04-20 15:01
10	调整界面管理员方针之“权限取得”一节	24	10	Temp3600	2021-04-18 13:22
11	模板修訂建議	1	1	Jimmy-bot	2021-04-22 16:14
12	设计一个制度解决部分速删模板挂不上去的页面的删除问题	14	6	Tranve	2021-04-21 20:28
13	限縮{{电视节目的变迁}}模板使用範圍	8	8	LuciferianThomas	2021-04-22 14:53
14	通用行為準則/2021諮詢	1	1	Yining Chen	2021-04-16 22:31
15	设立过滤器禁止将维基百科用作来源	13	5	Antigng	2021-04-21 15:39
16	订立编辑松相关规章制度	43	15	Yangwenbo99	2021-04-23 02:52
17	將「青島」、「中國青島」或「山東青島」改成「中華人民共和國山東省青島」是否有必要	30	13	Sanmosa	2021-04-20 12:44
18	訂立影片加入相關指引	17	8	Antigng	2021-04-22 13:51
19	在个人贡献之“翻译”页面添加数个机械翻译工具是否涉嫌鼓勵用戶违反方针指引？	4	4	Xiplus	2021-04-22 17:15

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

專題命名空間[编辑]

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间。

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

本主題全部或部分段落文字，轉移自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空間的捷徑是否需要清除連入然後(×)删除？

[email protected]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)

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

“

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

”

——User:BlackShadowG

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

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

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

第六階段：(暫不開放)[编辑]

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

本章節暫時不存檔，直到部署完成。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

偽命名空間[编辑]

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间。

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

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

格式手冊及長期破壞者提升為命名空間，英語名稱待定；
格式手冊及長期破壞者成為偽命名空間，縮寫為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)

在使用者自訂的Common.js測試有關代碼的結果。測試於[[MOS:001]]。

(：)回應@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)#[email protected]，問題似乎已解決？—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 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)

本章節暫時不存檔，直到部署完成。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

WP:捷徑指引草案修訂[编辑]

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:捷徑、Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间。

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

說明[编辑]

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

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

本討論的各階段分為：

~~專題提升為命名空間與否及其細節~~（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)

有關某年代相關分類命名統一事宜[编辑]

本主題或以下段落文字，在討論結束後應存檔至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)

請求第三方管理員參與評估和總結可靠來源討論[编辑]

本主題全部或部分段落文字，已移動至WP:VPD。执行人：痛心疾首 2021年4月18日 (日) 12:40 (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)

参考資料

^ 英维古典音乐专题的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)

有關新增偽命名空間的提議[编辑]

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

現時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)

模板颜色相关规范[编辑]

本主題或以下段落文字，在討論結束後應存檔至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)

變通提案[编辑]

以下是小弟的變通提案：

現行條文

颜色及内联图像

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

(：)回應我認為索馬立方、摺紙與正文密切相關。天文符號其他例子例如電路符號、化學特殊符號、化學結構式（有苯環的）生物學符號，我不建議在旁邊放成表格，一堆一個小符號整理成表格非常詭異。以及「

[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[编辑]

第一步[编辑]

有關新增偽命名空間的提議[编辑]

初步定案[编辑]

模板颜色相关规范[编辑]

變通提案[编辑]

第二階段之公示狀態通告[编辑]

第二階段之公示期討論[编辑]