維基百科:互助客棧/方針

捷徑

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

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

請注重禮儀、遵守方針與指引，一般問題請至互助客棧其他區或知識問答提出，留言後請務必簽名（點擊）。

發表前請先搜尋存檔，參考舊討論中的內容可節省您的時間。

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

公告欄

[人事] Manchiu、UjuiUjuMandan、ASid、ATannedBurger獲提名為管理員，AT獲提名為監督員，歡迎踴躍參與提問和討論。
[公告] 互助客棧正在對於Unblock-zh.org試運行徵求意見。
[公告] 修改模板:No source及修訂維基百科不是維基物種已經通過。
[公告] 再擬設立文化遺產關注度指引、將地理特徵關注度指引中有關道路的部分改為在交通關注度指引中列出、修改非原創研究方針中有關日常計算的規定、再擬設立國際關係命名常規為方針、關於{{Death}}和{{Deceased Wikipedian}}文案調整的方案及規範討論發起步驟正在公示，如有意見請儘快提出。
[討論] 互助客棧方針區正在討論修改RFA流程相關規定，請踴躍參與討論。
[討論] 互助客棧技術區正在討論ToolsRedirect建立的繁簡重新導向問題，請踴躍參與討論。
[討論] 互助客棧條目探討區正在討論Rightmost模板與Str rightc模板重複的問題，請踴躍參與討論。
[討論] 互助客棧其他區正在討論對新聞動態獲選標準及ITNR規則的小修訂及頁面評級與通用評級行政層面上的統合方案，請踴躍參與討論。
[廣告] 第二十二次動員令將於7月6日至9月8日間舉行，現正在徵求主題及主持人，歡迎踴躍參與！

[協作] 現有124個頁面需維基化，277個條目需清理，15個移動請求正在討論。
[獎勵] 現有3名用戶獲提名維基獎勵，歡迎投票。

存檔

2003年	5月以前					6	7	8	9	10	11	12	月
2004年	1	2	3	4	5	6	7	8	9	10	11	12	月
2005年	1	2	3	4	5	6	7	8	9	10	11	12	月
2006年	1	2	3	4	5	6	7	8	9	10	11	12	月
2007年	1	2	3	4	5	6	7	8	9	10	11	12	月
2008年	1	2	3	4	5	6	7	8	9	10	11	12	月
2009年	1	2	3	4	5	6	7	8	9	10	11	12	月
2010年	1	2	3	4	5	6	7	8	9	10	11	12	月
2011年	1	2	3	4	5	6	7	8	9	10	11	12	月
2012年	1	2	3	4	5	6	7	8	9	10	11	12	月
2013年	1	2	3	4	5	6	7	8	9	10	11	12	月
2014年	1	2	3	4	5	6	7	8	9	10	11	12	月
2015年	1	2	3	4	5	6	7	8	9	10	11	12	月
2016年	1	2	3	4	5	6	7	8	9	10	11	12	月
2017年	1	2	3	4	5	6	7	8	9	10	11	12	月
2018年	1	2	3	4	5	6	7	8	9	10	11	12	月
2019年	1	2	3	4	5	6	7	8	9	10	11	12	月
2020年	1	2	3	4	5	6	7	8	9	10	11	12	月
2021年	1	2	3	4	5	6	7	8	9	10	11	12	月
2022年	1	2	3	4	5	6	7	8	9	10	11	12	月
2023年	1	2	3	4	5	6	7	8	9	10	11	12	月
2024年	1	2	3	4	5	6	7	8	9	10	11	12	月

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	提議提高條目評選投票資格門檻	1	1	Sanmosa	2024-05-14 19:00
2	再擬設立國際關係命名常規為方針	61	11	Tp0910	2024-05-22 05:24
3	提議英維指引en: MOS:TVINTL經本地化後引入中維維基百科:格式手冊/電視	81	9	HK5201314	2024-05-20 09:37
4	提議：允許使用開放代理編輯WP:RFR，並在WP:RFR中加入「註冊帳號申請」	1	1	Sanmosa	2024-05-14 19:01
5	提議：對WP:日常計算做小修改	1	1	Sanmosa	2024-05-14 23:49
6	提議對中國大陸的文物保護單位設立關注度豁免	1	1	Sanmosa	2024-05-14 23:01
7	附帶有限追蹤檢查的無IP的IPBE	13	8	Bluedeck	2024-05-17 17:01
8	關於國籍的原創研究	19	7	Ericliu1912	2024-05-14 01:04
9	關於跨行政區域的實體，是否應該使用多個分類	15	6	克勞棣	2024-05-15 01:00
10	必須防止濫用「防濫用過濾器」	19	14	MilkyDefer	2024-05-21 12:11
11	提議外部連結指引WP:ELNO同時編入WP:可供查證。	16	4	HK5201314	2024-05-22 08:14
12	把會讓人產生不適感的圖片做一層遮掩與提示怎麼樣？	11	5	世界解放者	2024-05-19 08:45
13	修改RFA流程相關規定	6	3	Sanmosa	2024-05-21 11:31
14	關於WP:CTOP/BLP方針	5	4	Sinsyuan	2024-05-22 09:02

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

正在廣泛徵求意見的議題

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

維基百科格式與命名

Template talk:Infobox person § 修改 Infobox person 中 native_name 參數位置

可能需要進一步討論以便獲得共識。--Kethyga（留言） 2024年4月24日 (三) 05:15 (UTC)

維基百科方針與指引

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

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

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

Wikipedia talk:關注度 (文化遺產) § 再擬設立文化遺產關注度指引

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

如題。--——— 紅渡廚（留言・貢獻） 2024年5月10日 (五) 06:05 (UTC)

Wikipedia talk:關注度 (地理特徵) § 建議將地理特徵關注度指引中有關道路的部分改為在交通關注度指引中列出

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

如題，我一直以來都感覺道路與地理特徵關注度指引中其他的被規範對象的性質比較不同，因此我尋思著應該把道路相關的規定移到交通關注度指引比較好，於是趁着現在有時間提起此事了。具體的做法是WP:關注度 (交通)#道路現有的內容由WP:關注度 (地理特徵)#道路現有的內容取代，WP:關注度 (地理特徵)#道路全節刪去。San mo sa _{全方貧工之聯合} 2024年5月14日 (二) 10:25 (UTC)

Wikipedia talk:非原創研究 § 提議：對WP:日常計算做小修改

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

此討論意在修訂既有WP:日常計算的規定。San mo sa _{全方貧工之聯合} 2024年5月14日 (二) 15:50 (UTC)

維基百科提議

Wikipedia talk:仲裁委員會 § RfC：2024年2月

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

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

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

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

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

Template talk:Twitter § Twitter改為X

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

Wikipedia:互助客棧/其他 § 對ITN獲選標準及ITNR的小修訂

此前的相關討論：

最近Wikipedia:新聞動態候選出了一些問題：

第一，在社群討論沒有得出支持刊登的情況，管理員自行刊登內容，如Wikipedia:新聞動態候選/存檔/2024年3月#亞倫·布殊內爾自焚事件；

第二，部分內容在刊登之前沒有收到反對意見，刊出之後被質疑關注度或重大性不夠，如Wikipedia:新聞動態候選/存檔/2024年4月#習馬二會；

第三，涉及中國載人航天工程的條目近期在提名時多被社群以不具備突破性為由反對，見Wikipedia:新聞動態候選/存檔/2022年6月#神舟十四號、Wikipedia:新聞動態候選/存檔/2023年6月#神舟十六號、Wikipedia:新聞動態候選/存檔/2023年10月#神舟十七號和Wikipedia:新聞動態候選#神舟十八號。

針對以上的第一條及第二條問題，提案對現行的ITN獲選標準作出如下修訂：

現行條文

管理員在每次更新欄目時，應當檢視新聞動態候選區內所有提案。管理員認為提案符合新聞動態候選標準的，應予採納；不符合候選標準的，應由管理員陳述意見後退回重審。有二名及以上維基人提出反對意見的，亦應當退回重審。

提議條文

管理員在每次更新欄目時，應當檢視新聞動態候選區內所有提案。管理員認為提案符合新聞動態候選標準，或支持刊登的意見佔大多數的，應予採納；不符合候選標準的，應由管理員陳述意見後退回重審。有二名及以上維基人提出反對意見的，亦應當退回重審。
對於刊登之後出現反對意見提案，管理員應暫時移除相關內容，直至社群得到支持刊登的共識。對於沒有得到絕對結論的提案，需要有二名及以上的管理員進行商討，以最終決定是否刊登。
提案新聞內容涉及需要地區詞轉換的用字，提案人需要先自行處理。

針對以上的第三條問題，提案對現行的WP:ITNR作出如下修訂：

現行條文

載人軌道航天器的發射升空；一個國家首次成功完成自主發展的軌道發射；發射空間站或其主要組成部分；航天器抵達月球或更遠的目的地；重大航天任務失敗

提議條文

每款載人軌道航天器首次發射升空；每款載人軌道航天器與特定空間站首次成功對接；一個國家首次成功完成自主發展的軌道發射；發射空間站或其主要組成部分；航天器抵達月球或更遠的目的地；重大航天任務失敗

正如WP:NOTNEWS所說，維基百科不是新聞報道。新聞動態候選和Portal:新聞動態設立的初衷也不是為了提供新聞報道，「是為了鼓勵增訂或更新相關的條目，而不是用作新聞報道」。由此可見，社群應該從百科性的角度來提報及衡量新聞動態條目，一些不具備百科性的條目能不提報就不提報，能不刊登就儘量不刊登，畢竟「維基百科不是新聞報道」。所以，新聞動態的標準也儘量嚴謹。上述的修改意見只不過是拋磚引玉，歡迎社群在此提案的基礎上踴躍討論。--Jeffchu2014（留言） 2024年4月28日 (日) 17:08 (UTC)

Template talk:Hang on § {{hangon}}

Template:Db-meta（英語：Template:Db-meta）的格式在之前的討論中，無法解決標記提速刪頁面上的速刪狀態；如果用機械人的方式來處理，是否可行？臺灣杉在此發言 (會客室) 2024年4月30日 (二) 08:33 (UTC)

專題命名空間

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

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

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

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

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

本討論的各階段分為：

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

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

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

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

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

已通過：

已

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

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

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

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

先前討論

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

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

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

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

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

從這個動議的內容上看應該是這個意思，開闢一個「WikiProject」空間，簡稱"PJ"，中文為「專題」和「維基專題」--MilkyDefer，推遲，咕咕 2020年11月16日 (一) 16:11 (UTC)[回覆]

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

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

小總結

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

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

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

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

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

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

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

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

“

與專供維基編者使用的維基專題不同，維基主題是同時為編者及一般讀者服務的。

”

—— Portal:首頁

——羊羊 (留言|貢獻) 2020年11月29日 (日) 04:11 (UTC)[回覆]

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

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

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

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

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

那這樣起不到「減少命名衝突」的效果…… ——羊羊 (留言|貢獻) 2020年11月30日 (一) 22:06 (UTC)[回覆]

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

我在這裏作出過的留言可供參考。--MilkyDefer，推遲，咕咕 2020年11月29日 (日) 16:16 (UTC)[回覆]

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

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

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

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

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

個人以為Project命名空間肯定不能變，否則可能會造成不少連結失效。因此命名空間應該命名為「WikiProject」，對應的中文命名空間應該命名為「維基專題」，以便於與「WikiProject」對應。——BlackShadowG（留言） 2020年12月11日 (五) 16:27 (UTC)[回覆]
- 我認為中文叫做「專題」並無不妥，也無衝突。將「WikiProject:」作為程式系統前綴；「專題」、「維基專題」、「PJ」作為別名。其他中文別名也可以之後再議再補。並依照法維和日維和其他姐妹專案的統一定義，定為{{ns:102}}(目前顯示為「WikiProject」，空白是因為本地尚未實裝）。— ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2020年12月11日 (五) 18:16 (UTC)[回覆]

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

支持命名為WikiProject/專題 ——羊羊 (留言|貢獻) 2020年12月16日 (三) 15:08 (UTC)[回覆]

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

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

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

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

專題空間設立流程與細節

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

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

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

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

第一階段：申請

已通過：

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

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

於Phabricator檢視
編號T271612的工單
狀態：已解決

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

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

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

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

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

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

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

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

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

您漏了WP:NS#縮寫和別名。--LuciferianThomas．留言 2021年1月28日 (四) 08:08 (UTC)[回覆]

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

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

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

已通過：

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

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

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

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

第二階段之公示狀態通告

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

第二階段之公示期討論

看來需要移動了 @A2569875、羊羊32521、BlackShadowG、YFdyh000、GZWDer、Z7504、AnYiLin那Wikipedia:專題應該被重命名成甚麼？WikiProject:首頁嗎？-- Sunny00217 2021年1月27日 (三) 10:07 (UTC)[回覆]
- 專題和專題委員會目前不在上述清單中，暫時不會移動。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月27日 (三) 10:27 (UTC)[回覆]
  - 我覺得可以在WP命名空間中留一個介紹專題的頁面，專題委員會可以考慮更名為WikiProject:委員會，不過這都是後話了，先完成轉移再討論吧。——BlackShadowG（留言）維基百科20歲生日快樂！ 2021年1月27日 (三) 12:56 (UTC)[回覆]
    @BlackShadowG：這主意不錯。--空氣小貓（留言） 2021年1月27日 (三) 16:48 (UTC)[回覆]

技術性~~(－)反對~~，ns:103好像有點問題。[2]，頁眉顯示命名空間偵測錯誤，不知道是什麼情況 ——羊羊 (留言|貢獻) 2021年1月28日 (四) 01:50 (UTC)[回覆]
- ns:102也有這個問題…… ——羊羊 (留言|貢獻) 2021年1月28日 (四) 02:04 (UTC)[回覆]
  切換到非中文en介面就不報錯[3]--百無一用是書生 (☎) 2021年1月28日 (四) 03:53 (UTC)[回覆]
  雖然有報錯資訊，但是建立頁面沒有問題：WikiProject:沙盒--百無一用是書生 (☎) 2021年1月28日 (四) 03:58 (UTC)[回覆]
  已修復 已經修復這個問題在Template:Namespace pagename--百無一用是書生 (☎) 2021年1月28日 (四) 04:10 (UTC)[回覆]
  還是有問題，Special:diff/63966864, 顯示WikiProject talk非討論頁 ——羊羊 (留言|貢獻) 2021年1月28日 (四) 04:16 (UTC)[回覆]
  Done，已在Template:存檔至/core新增該討論空間。--臺灣杉在此發言 (會客室) 2021年1月28日 (四) 04:27 (UTC)[回覆]
  感謝，已劃票 ——羊羊 (留言|貢獻|古典音樂專題) 2021年1月28日 (四) 04:30 (UTC)[回覆]
  - 視為本反對意見已排除。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月28日 (四) 07:22 (UTC)[回覆]
    - 我已經劃票了Topic:W2cr3gexeunjmjce ——羊羊 (留言|貢獻|古典音樂專題) 2021年1月28日 (四) 10:18 (UTC)[回覆]
已申請Wikipedia:機械用戶/申請#專題命名空間頁面遷移作業，預計於公示結束後開始執行任務。（目前仍然照着日維的劇本在走，有前人經驗參考，我想應該會順利完成）-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月28日 (四) 07:40 (UTC)[回覆]
題外話：完成所有討論後，應否為整個設立新命名空間及偽命名空間的討論設WT分頁並重新整理所有章節的討論？--LuciferianThomas．留言 2021年1月28日 (四) 08:14 (UTC)[回覆]
- @LuciferianThomas：我把日維的ja:Wikipedia:ウィキプロジェクト/名前空間の新設直接搬來了，你看看行不。Wikipedia:專題/提升為命名空間-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月28日 (四) 09:29 (UTC)[回覆]
  我意思是說Talk Archive🌚--LuciferianThomas．留言 2021年1月28日 (四) 09:48 (UTC)[回覆]
好奇的問一下，Wikipedia:電子遊戲專題/條目指引和Wikipedia:錢幣學專題/條目指引這兩個同時是維基百科正式內容指引的頁面會不會移動？ --Milky·Defer 2021年1月28日 (四) 12:19 (UTC)[回覆]
- 預計先全部移動，再另外處理其餘要移到他處的頁面。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月28日 (四) 12:32 (UTC)[回覆]
  - 或者您也可以直接編輯轉移表，透過加入註解符號（//或/* ... */）來排除您認為不應轉移到專題空間的頁面，User:A2569875/議案/專題空間設立/轉移表‎、User:A2569875/議案/專題空間設立/重新導向轉移表‎（上方列出用於公示的wikitable僅是視覺化呈現的方式，實際上仍然要用json輸入FLOOD程式）感謝。-- ナナチ果物プリン🐰🥭🍮（宇帆·s☎️<用戶/span>·☘️） 2021年1月28日 (四) 13:23 (UTC)[回覆]

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

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

(註:以下討論涉及後續階段的探討，先不關閉)-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月29日 (五) 13:04 (UTC)[回覆]
Just a suggestion，正式全面部署後能不能設定過濾器或者白名單，限制用戶建立「WP:XX專題」或「WP:XX維基專題」的頁面？--百戰天蟲（留言） 2021年1月28日 (四) 16:32 (UTC)[回覆]
(＋)支持——BlackShadowG（留言）維基百科20歲生日快樂！ 2021年1月29日 (五) 00:54 (UTC)[回覆]
目前有一個技術問題，Template:Category handler無法處理WikiProject namespace，連帶導致各個已經轉移的專題無法被列入諸如Category:活躍維基專題這類活躍度分類。--BoyuZhang1998（留言） 2021年1月29日 (五) 10:06 (UTC)[回覆]
- 那麼提請全保護模板編輯請求不就解決了。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月29日 (五) 10:15 (UTC)[回覆]
  - 完成@BoyuZhang1998：編輯請求已由U:KirkLU處理，問題將在維基媒體系統緩存清除完畢後解決，請靜待維基媒體系統清除緩存。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月31日 (日) 11:38 (UTC)[回覆]

專題指引更名

(承上方已經封閉的討論）Wikipedia:電子遊戲專題/條目指引和Wikipedia:錢幣學專題/條目指引可以如Template:Wikipedia policies and guidelines所示，考慮移動到Wikipedia:電子遊戲條目指引和Wikipedia:錢幣學條目指引（一個類似的例子是ACG專題論述Wikipedia:日本動漫遊戲條目指導）。或者保守一點，簡單刪掉斜線，變成Wikipedia:電子遊戲專題條目指引和Wikipedia:錢幣學專題條目指引）。--洛普利寧 2021年1月30日 (六) 15:19 (UTC)[回覆]
- (＋)支持更名為Wikipedia:電子遊戲條目指引和Wikipedia:錢幣學條目指引，這比較符合WP:方針中規定的命名方式。——BlackShadowG（留言）維基百科20歲生日快樂！ 2021年2月1日 (一) 02:02 (UTC)[回覆]
- (＋)支持，直接更名為「Wikipedia:xxxx條目指引」就好了，我覺得沒必要帶一個「專題」字樣。如果其他專題也有未成正式指引的條目指導的話，我支持全部移動成「Wikipedia:xxxxx條目指導」，日後如果有提升為指引，再將「指導」改成「指引」。--Milky·Defer 2021年2月1日 (一) 03:05 (UTC)[回覆]
- (＋)傾向支持以上提議，提升專題指引的曝光度和參與度，使其更經考驗。直接名為「指引」，掛特製參數的「專題指引」模板為好。--YF dyh000（留言） 2021年2月1日 (一) 04:25 (UTC)[回覆]
7日內無新留言，根據WP:7DAYS，就Wikipedia:電子遊戲專題/條目指引和Wikipedia:錢幣學專題/條目指引更名為Wikipedia:電子遊戲條目指引和Wikipedia:錢幣學條目指引一案 公示7日。——BlackShadowG（留言）維基百科20歲生日快樂！ 2021年2月10日 (三) 01:13 (UTC)[回覆]
@BlackShadowG：公示完畢了。--Milky·Defer >恭賀新春 2021年2月18日 (四) 15:03 (UTC)[回覆]
@MilkyDefer：目前所有方針指引均被移動保護，已提出移動請求，等待管理員處理。——BlackShadowG（留言）維基百科20歲生日快樂！ 2021年2月18日 (四) 16:04 (UTC)[回覆]
第二階段：提議將WP:XX專題/YY指引以及PJ:XX專題/YY指引皆移動到WP:XXYY指引。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月18日 (四) 16:10 (UTC)[回覆]

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

已處理：

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

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

@A2569875：話說這種的需不需要考慮直接提請管理員批量刪除？-- Sunny00217 2021年2月1日 (一) 11:27 (UTC)[回覆]
- (＋)支持，此類重新導向並無意義，看起來是移動時出現的失誤？——BlackShadowG（留言）維基百科20歲生日快樂！ 2021年2月3日 (三) 01:50 (UTC)[回覆]

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

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

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

於Phabricator檢視
編號T273763的工單
狀態：已解決

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

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

前幾天發現WikiProject:傳統百科全書條目因為頁面移動後造成大部分子頁面出現錯誤，目前已經修復一部分--百無一用是書生 (☎) 2021年3月16日 (二) 02:37 (UTC)[回覆]

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

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

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

第四階段：調整專題模板

已完成：

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

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

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

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

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

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

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

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

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

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

我認為PJ空間的捷徑統一規範為WPJ/PJ:XXX，將現有WP重新導向全部轉到PJ去。比如WikiProject:智能手機的WP:SMARTPHONE直接轉移到WPJ:SMARTPHONE。--Lightyears_{Talk·Sign#訂閱維貓報喵！} 2021年2月14日 (日) 11:15 (UTC)[回覆]
個人意見
1. 為了避免混淆，將來應該一律禁止建立跨WP與PJ空間的捷徑重新導向。
2. 目前存在的WP重新導向到PJ的捷徑應該全部轉移到PJ，若無連入或很少連入，可考慮(×)刪除；若數量過大，或者已經在討論中被引用，則可考慮(○)保留以僅供歷史參考。
3. 同時，將PJ命名空間中所有{{shortcut}}中的捷徑一律改為以「PJ」開頭的捷徑，不再推薦使用以WP開頭的捷徑。

——BlackShadowG（留言）維基百科20歲生日快樂！ 2021年2月14日 (日) 12:57 (UTC)[回覆]

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

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

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

所以把PJ空間的{{shortcut}}全部更新，提醒將來的編者不要再用WP連結到PJ的捷徑就行了。那些沒有連入的WP捷徑刪了也無妨。——BlackShadowG（留言）維基百科20歲生日快樂！ 2021年2月16日 (二) 02:05 (UTC)[回覆]

個人意見：

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

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

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

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

Wikipedia:專題和Wikipedia:專題委員會等部分頁面為何還沒有移動到新的命名空間？還是這些頁面不應該移動？--百無一用是書生 (☎) 2021年2月19日 (五) 02:46 (UTC)[回覆]

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

專題委員會並非專題介紹，Wikipedia:專題似乎也稱不上是介紹，更像是WikiProject:首頁的作用--百無一用是書生 (☎) 2021年3月1日 (一) 02:54 (UTC)[回覆]

(？)疑問所以您建議將WP:專題(►)移動到PJ:首頁嗎？-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年3月1日 (一) 08:09 (UTC)[回覆]
我認為應該這樣，WP:專題可以不需要，或者另外重寫，作為對專題的介紹頁面--百無一用是書生 (☎) 2021年3月1日 (一) 11:46 (UTC)[回覆]
(？)疑問那麼您對專題委員會的存放位置有何建議？—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年3月3日 (三) 05:17 (UTC)[回覆]
(？)疑問@Shizhao：？-- 五歲抬頭雪菲（☎️·☘️） 2021年3月10日 (三) 06:01 (UTC)[回覆]
專題委員會應該是從屬於專題的啊，我覺得按道理來說應該在WikiProject下面--百無一用是書生 (☎) 2021年3月10日 (三) 07:19 (UTC)[回覆]

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

第六階段：(暫不開放)

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

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

偽命名空間

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

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

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

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

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

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

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

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

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

支持成為偽命名空間。命名空間涉及較多技術問題，未來如需求明顯，可再議轉換。--YF dyh000（留言） 2020年12月30日 (三) 13:01 (UTC)[回覆]

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

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

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

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

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

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

我對成立真命名空間(＃)有保留，尤其是格式手冊。對格式手冊而言，因為格式手冊同時也是指引，對它成立真命名空間將意味着指引分散兩地。 --Milky·Defer 2020年12月31日 (四) 17:13 (UTC)[回覆]

小結1

標題添加： ——羊羊 (留言|貢獻) 2021年1月19日 (二) 05:21 (UTC)[回覆]

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

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

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

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

這整得跟投票一樣，建議各位將(＋)支持和(－)反對的理由寫出來，逐一進行討論，以此達到共識。畢竟投票不能代替討論。 ——羊羊 (留言|貢獻) 2021年1月5日 (二) 15:50 (UTC)[回覆]

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

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

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

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

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

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

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

所有LTA的子頁面如下：

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

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

把LTA設定成命名空間的一個效果是可以設定所有頁面為noindex（包括少數不使用LTA模板的子頁），雖然社群要評估一下這麼做的價值。--GZWDer（留言） 2021年1月10日 (日) 14:42 (UTC)[回覆]

小結2

標題添加： ——羊羊 (留言|貢獻) 2021年1月19日 (二) 05:21 (UTC)[回覆]

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

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

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

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

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

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

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

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

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

或者

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

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

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

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

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

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

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

個人認為，如果長期破壞者（LTA）有成為命名空間的潛力的話，應該此時直接升級成為命名空間。不然，如果之後再討論升級為命名空間，所有帶LTA:前綴的頁面還要重新移動一遍。 ——羊羊 (留言|貢獻) 2021年1月15日 (五) 12:04 (UTC)[回覆]

感覺LTA頁面及命名空間有違WP:RBI。如果設立命名空間的同時增設頁面檢視權限（回退員及以上），我會考慮支持。--YF dyh000（留言） 2021年1月15日 (五) 12:28 (UTC)[回覆]

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

(－)反對設立MOS和LTA命名空間，這與技術問題無關，而是目前MOS和LTA頁面的數量和讀者關注的程度遠遠達不到需要設立新命名空間的地步。LTA頁面的數量充其量也就一百個左右，MOS頁面的數量更是少得可憐，才十幾個，遠遠沒有達到維基專題那樣的2000多個頁面。同時，LTA只有熟悉CU等站務的編者會去查閱，MOS查閱的人數更少，這些也完全比不上熟悉某些特定領域的編者和讀者都會關注的維基專題。因此，我反對設立以上兩個命名空間，對設立偽命名空間表示(＝)中立。——BlackShadowG（留言）維基百科20周年慶即將到來 2021年1月15日 (五) 13:41 (UTC)[回覆]

LTA數量可能少，但shortcut還是蠻多的。而且LTA數量也會增多-- ——羊羊 (留言|貢獻) 2021年1月16日 (六) 12:55 (UTC)[回覆]

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

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

捷徑空間提案

標題添加： ——羊羊 (留言|貢獻) 2021年1月19日 (二) 05:21 (UTC)[回覆]

否決：

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

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

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

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

小結3

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

「顯示為『條目|條目討論』」是指重新導向頁面嗎？我覺得重新導向頁面顯示條目沒什麼大問題（） ——羊羊 (留言|貢獻) 2021年1月19日 (二) 05:07 (UTC)[回覆]
見ナナチ上方的留言，當中有說明可在MediaWiki:Common.js加一段代碼讓偽命名空間不顯示「條目」。--LuciferianThomas．留言 2021年1月19日 (二) 07:50 (UTC)[回覆]

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

其實照這個思路，如果怕偽命名空間佔用條目命名空間，又怕（對於MOS:）指引分散，可以設立MOS:命名空間，然後MOS:下的頁面重新導向到Wikipedia空間的格式手冊里 ——羊羊 (留言|貢獻) 2021年1月19日 (二) 05:21 (UTC)[回覆]
這不太符合邏輯吧，同時存在「格式手冊」命名空間和專案（維基百科）命名空間的格式手冊。額外設立一個「格式手冊」或「長期破壞者」命名空間但只作重新導向用，好像沒什麼意義。--LuciferianThomas．留言 2021年1月19日 (二) 07:48 (UTC)[回覆]

再提捷徑空間提案

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

嘗試推動LTA空間

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

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

經過上方的討論，我認為LTA更適宜作為真·命名空間。好處是（上方有人提到）可以設定所有頁面為NOINDEX，增設頁面檢視權限（體現WP:RBI，而且有天邪鬼這種……）。

此外，LTA與Project空間聯繫性不大，沒有維護問題。而且，如果設偽命名空間之後再討論升級為命名空間，所有帶LTA:前綴的頁面還要重新移動一遍。(mw:Help:Namespace)

至於LTA頁面數量少……我是不知道設立命名空間還有頁面數量門檻啊…… 囧rz…… ——羊羊 (留言|貢獻) 2021年1月23日 (六) 05:20 (UTC)[回覆]

如果用戶不可檢視的命名空間不會顯示在Special:搜尋，我想命名空間多不是個大問題。贊成「LTA與Project空間聯繫性不大」。不認為二次移動是個大問題，社群可以先用偽命名空間看看效果。--YF dyh000（留言） 2021年1月23日 (六) 12:25 (UTC)[回覆]

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

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

@羊羊32521：討論不知道為什麼被關掉了，(？)疑問你有要繼續推動的意願嗎？-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月1日 (一) 09:36 (UTC)[回覆]
YFdyh000說讓社群看看偽命名空間的效果……我覺得可以先這樣？過一段時間再提吧-- ——羊羊 (留言|貢獻|古典音樂專題) 2021年2月1日 (一) 09:43 (UTC)[回覆]

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

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

通過：

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

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

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

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

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

現行條文

R2. 跨命名空間的重新導向。

由條目的命名空間重新導向至非條目命名空間，將用戶頁移出條目命名空間時遺留的重新導向，或者從草稿命名空間指向非草稿命名空間的重新導向。（有時新加入的維基人偶爾會在主條目空間誤建用戶頁。使用「移動」頁面工具將用戶頁移回用戶名字空間會保留頁面歷史，在刪除遺留的重新導向頁前，考慮保留一到兩天；草稿重新導向速刪前，請確保草稿已經完成其作用，並且草稿的歷史已經合適地移動到相應的正式頁面。）

提議條文

R2. 跨命名空間的重新導向。

由條目的命名空間重新導向至非條目命名空間，將用戶頁移出條目命名空間時遺留的重新導向，或者從草稿命名空間指向非草稿命名空間的重新導向。經社群同意設立的偽命名空間屬於本規則之例外。注意：有時新加入的維基人偶爾會在主條目空間誤建用戶頁。使用「移動」頁面工具將用戶頁移回用戶名字空間會保留頁面歷史，在刪除遺留的重新導向頁前，考慮保留一到兩天；草稿重新導向速刪前，請確保草稿已經完成其作用，並且草稿的歷史已經合適地移動到相應的正式頁面。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

進一步討論

自動提刪R2

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

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

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

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

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

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

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

MOS捷徑名稱

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

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

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

軟重新導向

已否決：

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

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

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

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

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

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

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

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

技術問題處理

已通過：

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

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

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

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

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

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

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

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

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

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

@A2569875：可以考慮作為預設啟用的小工具，這樣也方便維護。--安憶 ^Talk 2021年2月2日 (二) 12:35 (UTC)[回覆]

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

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

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

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

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

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

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

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

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

還有個小建議：當處於移動視圖時，不必在minerva外觀的頁面標題（腳本里的tips_selector）處添加提示，因為在觸控設備上沒辦法看到鼠標懸停才有的提示，反而被加了下劃線，感覺不太美觀。--安憶 ^Talk 2021年2月2日 (二) 16:31 (UTC)[回覆]

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

感覺用'ontouchstart' in document.documentElement來判斷更合適。--安憶 ^Talk 2021年2月3日 (三) 08:59 (UTC)[回覆]

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

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

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

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

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

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

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

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

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

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

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

(？)疑問@LuciferianThomas：所以「偽命名空間」（[[WP:偽名字空間|偽名字空間]]）要改成什麼？-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月5日 (五) 06:46 (UTC)[回覆]
維基百科:偽命名空間輔助說明（捷徑WP:PNS+）--LuciferianThomas．留言 2021年2月5日 (五) 08:10 (UTC)[回覆]
BTW在問號圖案後加個空格唄，貼著很醜…--LuciferianThomas．留言 2021年2月5日 (五) 08:13 (UTC)[回覆]
- 完成：Special:Diff/64147054。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月6日 (六) 14:00 (UTC)[回覆]
- @LuciferianThomas：還有其他疑問嗎？若沒有我就要公示囉？@AnYiLin：高風險模板/介面編輯請求的公示確定不必放公告欄嗎？-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月7日 (日) 04:07 (UTC)[回覆]
  支持啟動公示。--LuciferianThomas．留言 2021年2月7日 (日) 04:37 (UTC)[回覆]
  
  在此公示吧，這個修改只是配合偽名稱空間的使用，後者已經公示過了。我剛剛也再次讀了一遍保護方針，沒理解錯的話其只要求在對受保護的模板和模組進行一些變更時需要達成共識/進行公示。
  
  此小工具會預設開啟並在偏好設定處隱藏，避免用戶誤操作關閉（達到和直接放進common.js同樣的效果）。--安憶 ^Talk 2021年2月7日 (日) 04:46 (UTC)[回覆]
  我反對隱藏，我個人不需要這個功能，想將其關閉。用戶誤關閉不會造成嚴重問題，如果有人問起相關問題，叫他重新打開就好了，看不出隱藏的必要性。--Xiplus#Talk 2021年2月15日 (一) 04:34 (UTC)[回覆]
  但是如果這段代碼直接按最初設想放進common.js的話，也是關不掉的吧。--安憶 ^Talk 2021年2月15日 (一) 04:44 (UTC)[回覆]
  做成小工具就是因為有關閉的需求，其次是維護的需求。--YF dyh000（留言） 2021年2月15日 (一) 04:46 (UTC)[回覆]
  做成小工具本來就是我提出來的，從未考慮過提供其他需求（比如自由選擇開關），只是為了方便維護，不用去改common.js，放進common.js根本沒得選。--安憶 ^Talk 2021年2月15日 (一) 04:51 (UTC)[回覆]

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

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

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

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

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

於Phabricator檢視
編號T178356的工單

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

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

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

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

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

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

自動半保護偽命名空間

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

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

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

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

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

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

建議用濫用過濾器阻止非自動確認用戶編輯，配以相關警告。--YF dyh000（留言） 2021年2月2日 (二) 13:07 (UTC)[回覆]

(＋)支持用濫用過濾器阻止非自動確認用戶編輯，配以相關警告。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月7日 (日) 04:08 (UTC)[回覆]

提議設立快速刪除標準 O8

現行條文

(無)

提議條文

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)[回覆]

將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)[回覆]

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

WP:捷徑指引草案修訂

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

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

說明

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

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

本討論的各階段分為：

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

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

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

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

專題命名空間問題

本主題全部或部分段落文字，已轉移至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)[回覆]

首段建議附加維基專題空間，他們會稍後設立捷徑。--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)[回覆]

擬議快速刪除方針條文增修（A2修訂）

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:快速刪除方針、Wikipedia talk:小小作品。

原標題為：擬議快速刪除方針條文增修（B部分）

現擬議修改快速刪除方針A2與A6條文如下：

“

A2：

現行條文

帶有{{inuse}}模板的不適用。

提議條文

帶有{{inuse}}模板的頁面（在編輯持續時間內）不適用。
若條目內的模板包括資訊框，資訊框預設欄位名稱以外的內容視為條目本身的內容。如相關內容符合A1，請改為使用A1提請快速刪除。

”

“

A6：

現行條文

帶有{{inuse}}和{{translating}}模板的不適用。

提議條文

帶有{{inuse}}（在編輯持續時間內）及／或{{translating}}模板的頁面不適用。

”

以上。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月21日 (日) 05:38 (UTC)[回覆]

請勿將擬議快速刪除方針條文增修的其他部分與此部分合併，以免討論失焦。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月21日 (日) 05:43 (UTC)[回覆]

增加「若條目內的模板包括資訊框，且資訊框在不包含其預設欄位名稱的情況下仍有內容，則亦不適用」的原因是資訊框通常具百科性內容。其他部分的修改原因是促進草稿化。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月21日 (日) 05:46 (UTC)[回覆]

@Poem。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月21日 (日) 05:48 (UTC)[回覆]

inuse的部分我認為沒必要，按常識按需移除即可，{{inuse|2年}}不適用嗎。「有內容」可能非常寬泛，標點和胡言亂語都是內容，不過我還沒想到更好表述。A6同上。因此，我不認為有必要修訂。--YF dyh000（留言） 2021年2月21日 (日) 06:00 (UTC)[回覆]

@YFdyh000：就「若條目內的模板包括資訊框，且資訊框在不包含其預設欄位名稱的情況下仍有內容，則亦不適用」來說，你說的情況並不常見（而且可以用A1處理），大多數情況是確有有意義內容，這種情況下不應刪除，但我變更一下表達方式。後一點我開放討論，因為這個提議是照抄舊提議的。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月21日 (日) 06:12 (UTC)[回覆]

摘下inuse再提刪就行。--Temp3600（留言） 2021年2月21日 (日) 14:31 (UTC)[回覆]

@Temp3600：不排除有誘發編輯戰的可能性。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月21日 (日) 23:44 (UTC)[回覆]

(※)注意

用戶經常只加了模板及訊息框後後，就一走了之，這些只有模板及訊息框的條目嚴重影響條目質素，也影響維基的聲譽，讓外界看到維基的條目只有模板及訊息框。
A6現行條文已經很清晰，用戶及管理員也會根據常識判斷。

以上。--蟲蟲飛♡♡→♡℃※留言 2021年2月22日 (一) 04:47 (UTC)[回覆]

（1）一來這條文修改其實是為了促進草稿化，巡查員看到自然懂得怎麽樣去處理，不要說的像所有巡查員都死了一般。二來中文維基百科品質低下的條目多的是，有些條目的字數只是剛好過50，我看它們的品質跟只有Infobox的條目差不多。（2）這一點我開放討論，因為這個提議是照抄舊提議的。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月22日 (一) 12:29 (UTC)[回覆]

(？)疑問:現行方針下，您要「促進草稿化」，就做不到嗎？您可以把符合A2的條目，以移動到草稿的方式去替代提速刪，沒必要改方針。--蟲蟲飛♡♡→♡℃※留言 2021年2月24日 (三) 12:40 (UTC)[回覆]

我現在又不是巡查員，所以我能做的東西很少，我總不可能整天盯着Category:快速刪除候選吧。那如果我要想辦法提醒巡查員的話，最好的辦法就是從方針層面提醒，讓他們掛A2的誘因減少，草稿化的誘因增加。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 02:23 (UTC)[回覆]

(＆)建議:這種常識性的東西，我不認為巡查員會不懂，如果不懂，您改了方針，也不會立刻懂了。建議您可以直接走去巡查員用戶討論頁建議，這比您改方針的方式來得有效。--蟲蟲飛♡♡→♡℃※留言 2021年2月25日 (四) 03:52 (UTC)[回覆]

我不認為草稿化是「常識性的東西」。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 09:08 (UTC)[回覆]

請您論述提案解決了甚麼問題？現行機制是否無法解決您提到的問題？--蟲蟲飛♡♡→♡℃※留言 2021年2月28日 (日) 02:17 (UTC)[回覆]

我在2021年2月22日 (一) 12:29 (UTC)的留言中的（1）中的「二來」有説明修訂條文後資訊框預設欄位名稱以外的內容視為條目本身的內容，實際上避免了只有已填寫有意義的百科性內容的資訊框的條目被刪除，讓該等條目有機會被改寫出文字段落敘述。SAN MO SA _{江南好，風景舊曾諳} 2021年2月28日 (日) 10:51 (UTC)[回覆]

您這個意見我上面已經回應了，在條目空間保留這些只有訊息框或模板的條目，很影響外界對維基的觀感，而且我沒看到提案有甚麼修訂意義。--蟲蟲飛♡♡→♡℃※留言 2021年3月3日 (三) 10:23 (UTC)[回覆]

請問百科全書最重要的目的是甚麽？照顧特定人士的觀感？不可能。不要把本末輕重顛倒。SAN MO SA _{江南好，風景舊曾諳} 2021年3月3日 (三) 13:56 (UTC)[回覆]

對當前提案的A2條文修訂傾向支持。對inuse相關修訂（持續時間內）認為沒必要強調，掛模板的人應有常識。對蟲蟲飛認為的「這些只有模板及訊息框的條目嚴重影響條目質素」等反對，有維護模板更體現維基百科的不完善、號召貢獻（我甚至傾向「模板轟炸」），新建的不違規條目不需要迅速處理。蟲蟲飛，「您可以把符合A2的條目，以移動到草稿的方式去替代提速刪，沒必要改方針。」大概不能代替Sanmosa期望的減少A2使用率。--YF dyh000（留言） 2021年3月3日 (三) 14:27 (UTC)[回覆]

inuse的部分，很不幸地，在我看來，沒多少人有如此的常識。SAN MO SA _{江南好，風景舊曾諳} 2021年3月3日 (三) 14:30 (UTC)[回覆]

(？)異議:現在社羣對條目質素有非常高的要求，沒必要把質素極差的A2，可能不成條目的條目留在維基。--蟲蟲飛♡♡→♡℃※留言 2021年3月3日 (三) 14:35 (UTC)[回覆]

@蟲蟲飛：您的觀點大概是小小作品應當速刪。但寧缺毋濫、寧濫勿缺等觀點是並存的。@Sanmosa：所以有很多人在速刪掛了inuse的條目嗎。--YF dyh000（留言） 2021年3月3日 (三) 14:51 (UTC)[回覆]

小小作品還算條目，A2連條目都不是，質素極差的，不知為甚麼還要放寬？--蟲蟲飛♡♡→♡℃※留言 2021年3月3日 (三) 14:57 (UTC)[回覆]

@蟲蟲飛：提案的A2會將這樣內容的新條目排除，並將無實際內容的新條目歸入A1。雖然這個範例也許稍顯極端，但確實有編者和新手會將早期版本的草稿提交到條目空間，如果內容可修改格式來變為小小作品乃至小作品，或者移動到草稿空間，不應該交由速刪，如此速刪像是懲罰編者而非促進內容建立。--YF dyh000（留言） 2021年3月3日 (三) 15:09 (UTC)[回覆]

這樣差的條目還要放過？合理嗎？雖然我反對熱血刪除，但也(－)反對把條目的質素標準降到那麼低。--蟲蟲飛♡♡→♡℃※留言 2021年3月4日 (四) 13:53 (UTC)[回覆]

能輕鬆總結和改寫為小小作品或以上的僅資訊框條目，不應以速刪結束，應留出完善和打撈時間（小小作品或存廢討論）。尚不是合格的條目（包括如廣告宣傳、關注度不足、需要重寫等），不代表要立即速刪，侵權刪除都有7天呢。指引Wikipedia:小小作品#小小作品提昇管理辦法也提到，正文的定義「不包含訊息框的預設字段名稱和其他模板本身」，即非預設字段是計入小小作品字數計算的，A2沒理由比它更嚴格。--YF dyh000（留言） 2021年3月4日 (四) 14:16 (UTC)[回覆]

我還沒看到修訂A2或取消A2的實際意義，而且用戶經常寫了A2條目後就一走了之，修訂只會令維基積壓更多沒有內容只有訊息框的問題條目。此外，站務性的方針不建議頻繁地修改，這樣很影響巡查員去處理站務。而且今天有用戶感覺想改一下方針，明天又有用戶要改，改來改去，很影響巡查員處理站務。--蟲蟲飛♡♡→♡℃※留言 2021年3月5日 (五) 06:49 (UTC)[回覆]

如果確實有改的需要，即使頻繁，還是要改。改的時機僅取決於有沒有那個需要，而不取決於是否頻繁，而有沒有那個需要也不取決於是否頻繁。而且，這條改下來以後理論上應該是減少了巡察員的工作，如果説真的「很影響巡查員處理站務」，那樣那個影響一定是正面的影響。SAN MO SA _{江南好，風景舊曾諳} 2021年3月5日 (五) 07:07 (UTC)[回覆]

方針有問題當然要改，但不能為改而改，而且現在沒有改的需要，因為提案沒有解決任何問題，而且帶出了新的問題。--蟲蟲飛♡♡→♡℃※留言 2021年3月5日 (五) 07:13 (UTC)[回覆]

@蟲蟲飛：意義是給保留派維基人和建立者留出充足的打撈時間。包括我，在巡查或存廢中看到關注度不足或小小作品的條目時，如有閒暇和興趣，會嘗試搜尋來源和內容並嘗試打撈為小作品；而如果讓我從頭建立和編寫那個條目，基於完美主義等原因（自動過期被刪了不少譯了八九成的草稿……），我肯定是拒絕的。此方針修訂幅度很小，很容易理解，只需巡查員改掛小小作品或A1而非A2，管理員處置A2時稍加留意，駁回並轉其他處理方式。哪怕有管理員沒注意到A2的變更，也不會出什麼大事。另外，一個標有維護模板的資訊極少條目，可能會激發一些讀者參與到維基百科編輯中來，因為稍作改善是很容易的，並不是只有好條目才能提升維基百科。因此，對A2修訂支持（不含inuse部分）。不清楚蟲蟲飛所講的新問題是什麼。--YF dyh000（留言） 2021年3月5日 (五) 07:20 (UTC)[回覆]

現時的機制已經可以讓保留派改善A2條目，例如在編輯中的A2不應提刪，而且您也可以把符合A2的移動到草稿再改善。--蟲蟲飛♡♡→♡℃※留言 2021年3月5日 (五) 07:25 (UTC)[回覆]

幾分鐘至幾小時不足以獲得充分關注和打撈，多放幾天並不會怎樣。移動到草稿空間對建立者（尤其是已註冊的新人或資深用戶）很不尊重、突然。--YF dyh000（留言） 2021年3月5日 (五) 08:22 (UTC)[回覆]

我也很(－)反對把條目移動到草稿，但從我每天處理速刪所見，過去兩年沒看過有人去救A2條目，反而用戶寫了A2條目後，一走了之，不負責任的太多了。--蟲蟲飛♡♡→♡℃※留言 2021年3月6日 (六) 04:33 (UTC)[回覆]

或許管理員們對掛上A2的條目，可以放個一兩天或兩三天，如果沒改善再刪？當初的想法是覺得有些只有訊息框的條目內容量足夠，要改寫成小作品條目不算難，這時刪了可惜。放個幾天再刪一方面可以讓編者有時間改寫，對新手編者也不會因為被移到草稿而認為條目不見而影響心情（不指望新手編者會看監視清單，或注意到通知），也可維持有些人對維基的觀感？這樣也不用動到公開的方針。Poem（留言） 2021年3月6日 (六) 16:34 (UTC)[回覆]

不同管理員的處事方式不同，有必要定明文方針。SAN MO SA _{江南好，風景舊曾諳} 2021年3月7日 (日) 00:57 (UTC)[回覆]

改方針不能解決問題，建議您有意見可以直接走去提醒管理員。--蟲蟲飛♡♡→♡℃※留言 2021年3月7日 (日) 02:16 (UTC)[回覆]

不同管理員的處事方式不同，不改方針沒辦法規範管理員的處理方式，沒辦法使管理員必須遵守。SAN MO SA _{江南好，風景舊曾諳} 2021年3月8日 (一) 23:55 (UTC)[回覆]

改方針，管理員不會立刻改善，兩者沒有因果關係，您自己走去提醒和溝通，才有用。--蟲蟲飛♡♡→♡℃※留言 2021年3月9日 (二) 02:58 (UTC)[回覆]

沒有用。不同管理員的處事方式不同，我想跟他們溝通，他們也還不願意溝通呢，何況又不是他們必須做的事情。SAN MO SA _{江南好，風景舊曾諳} 2021年3月10日 (三) 10:45 (UTC)[回覆]

不回應用戶留言及請求的管理員確實很多，遇到這個問題，您可以來找我，您看每天都很多人走來找我幫忙。--蟲蟲飛♡♡→♡℃※留言 2021年3月11日 (四) 03:12 (UTC)[回覆]

我不排除這會衍生管理戰的問題。SAN MO SA _{江南好，風景舊曾諳} 2021年3月11日 (四) 15:54 (UTC)[回覆]

車輪戰是很嚴重的，就算只是一次，也可以彈劾，或者無須警告，直接封鎖。--蟲蟲飛♡♡→♡℃※留言 2021年3月12日 (五) 00:44 (UTC)[回覆]

這月初不就發生過一次（Wikipedia:編輯禁制紀錄）。SAN MO SA _{江南好，風景舊曾諳} 2021年3月14日 (日) 04:23 (UTC)[回覆]

涉事的管理員已經被部分封鎖。--蟲蟲飛♡♡→♡℃※留言 2021年3月17日 (三) 11:45 (UTC)[回覆]

這不就表示（部分）封鎖無阻於管理員進行管理戰嗎？SAN MO SA _{江南好，風景舊曾諳} 2021年3月17日 (三) 12:35 (UTC)[回覆]

如果沒有任何人提出新的、有效的論點的話，我計劃在3月22日進行公示。SAN MO SA _{江南好，風景舊曾諳} 2021年3月15日 (一) 08:20 (UTC)[回覆]

(？)異議:未見提案解決了甚麼問題，沒看到修改的意義，而且現行方針版本較佳，而且提案帶出了新的問題。--蟲蟲飛♡♡→♡℃※留言 2021年3月17日 (三) 11:43 (UTC)[回覆]

最後一次回應：（1）此提議意在放寬條目存留要求，不是用作「解決甚麼問題」，要是一定要說「解決了甚麼問題」的話，那就是變得更新手友善。（2）「提案帶出了新的問題」，然而其所謂的「新的問題」根本不是問題。SAN MO SA _{江南好，風景舊曾諳} 2021年3月17日 (三) 12:35 (UTC)[回覆]

請您重看我上面的留言：

用戶經常只加了模板及訊息框後後，就一走了之，這些只有模板及訊息框的條目嚴重影響條目質素，也影響維基的聲譽，讓外界看到維基的條目只有模板及訊息框。
A6現行條文已經很清晰，用戶及管理員也會根據常識判斷。

以上。--蟲蟲飛♡♡→♡℃※留言 2021年3月17日 (三) 12:57 (UTC)[回覆]

就（1），我不打算重覆YFdyh000的論點。就（2），就我看來，沒多少人有如此的常識，而摘下inuse再提刪則有誘發編輯戰的可能性。SAN MO SA _{江南好，風景舊曾諳} 2021年3月17日 (三) 23:16 (UTC)[回覆]

1.不同意，原因見上面論述。而且為了本站條目質素，不應讓慘不忍睹的劣質A2條目長時間留在維基。2.行之有效，未見有問題，如有，請舉證及論述現時的問題。--蟲蟲飛♡♡→♡℃※留言 2021年3月18日 (四) 03:52 (UTC)[回覆]

你這意見和小小作品應當速刪沒本質上的差別。SAN MO SA _{江南好，風景舊曾諳} 2021年3月18日 (四) 05:50 (UTC)[回覆]

錯，A2是沒有條目內容，只有模板等東西，小小作品是有內容的。--蟲蟲飛♡♡→♡℃※留言 2021年3月19日 (五) 06:25 (UTC)[回覆]

然而Infobox是存在百科內容的，小小作品算字數甚至也算Infobox。SAN MO SA _{江南好，風景舊曾諳} 2021年3月19日 (五) 14:36 (UTC)[回覆]

抱歉，無法接受只有訊訊框，而沒有正文的劣質條目。--蟲蟲飛♡♡→♡℃※留言 2021年3月20日 (六) 08:29 (UTC)[回覆]

那轉送社群調查吧，看看社群大體的反應如何。SAN MO SA _{江南好，風景舊曾諳} 2021年3月21日 (日) 08:30 (UTC)[回覆]

已轉送社群調查。SAN MO SA _{江南好，風景舊曾諳} 2021年3月22日 (一) 00:29 (UTC)[回覆]

共識是通過討論達成，不是通過調查；提案最大的問題是沒有解決任何問題，而且帶出了新的問題，沒有任何修訂意義。--蟲蟲飛♡♡→♡℃※留言 2021年3月22日 (一) 13:25 (UTC)[回覆]

這社群調查中間還不是討論，我不就是想找一個方法吸引更多人來這裏。SAN MO SA _{江南好，風景舊曾諳} 2021年3月22日 (一) 13:45 (UTC)[回覆]

您首要做的事是先論述一下您希望解決甚麼問題？--蟲蟲飛♡♡→♡℃※留言 2021年3月23日 (二) 06:40 (UTC)[回覆]

上面説了，不重複。如果你還是打算重複你上面説過的那些陳腔濫調的話，那大可不必。SAN MO SA _{江南好，風景舊曾諳} 2021年3月23日 (二) 07:08 (UTC)[回覆]

您上面留言我也回應了，注意提案如果根本沒有解決任何問題，而且帶出新的問題，那麼提案就不應該成立。--蟲蟲飛♡♡→♡℃※留言 2021年3月24日 (三) 06:37 (UTC)[回覆]

@YFdyh000、Temp3600、Poem：想重新問一下對於上面的提議修訂有沒有其他意見的？inuse的部分喜歡的話當成表述方式的調整就好，重點還是在A2。SAN MO SA _Σουέζ 2021年3月31日 (三) 08:00 (UTC)[回覆]

重述傾向支持。對蟲蟲飛從站務角度來嚴格化清理無正文條目，個人有所理解但不贊同——要不然規定將這種條目移動到草稿空間吧，變廢棄草稿再清理，雖然O7的六個月稍久。個人支持無正文也是條目，符合小小條目規定。還想到另一種情況，目前可做到編者沒寫內容但資訊框包含眾多有意義內容，通過d:Template:Databox，但如果新條文是以條目原始碼的內容為準則沒問題。--YF dyh000（留言） 2021年3月31日 (三) 08:15 (UTC)[回覆]

(※)注意:速刪方針屬於站務方針，現行方針已經很好，沒甚麼問題，修訂版標準模糊，除了帶給站務人員判斷上的爭議外，也未見帶出甚麼意義。而且重申:非常(－)反對把極度劣質而沒有內容的A2條目長時間留在條目空間，很影響外界對維基的觀感。--蟲蟲飛♡♡→♡℃※留言 2021年3月31日 (三) 08:32 (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)[回覆]

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

重提Wikipedia:集中討論

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:集中討論（錯誤：Wikipedia talk:集中讨论是重新導向頁面）。


問題背景	Wikipedia:互助客棧/消息因用戶查核問題引發大篇幅討論。此前在COVID-19、朝鮮半島等問題上，互助客棧也產生過爭論。這些討論佔據大量篇幅，不利於其它討論的進行。
解決方案	將Wikipedia:集中討論升級為指引。啟用{{Centralized discussion}}。
此前的類似討論	見Wikipedia talk:集中討論：2020年有過類似討論，基本上沒有反對意見，但沒有進入公示階段。

--Steven Sun（留言） 2021年2月28日 (日) 01:22 (UTC)[回覆]

不太懂具體怎麼做。與公告欄的差別。模板說明頁未翻譯。--YF dyh000（留言） 2021年2月28日 (日) 10:37 (UTC)[回覆]

通知模板建立者@Taiwania Justo：。另，即使開啟此制度，似乎也沒有把那個頁面提升到指引的必要。——BlackShadowG（留言）_{維基百科20歲生日快樂！} 2021年3月4日 (四) 14:08 (UTC)[回覆]

無須升級成指引。此外之前有提議該機制需和WP:RFC連動，因此在沒有部署RFC前（我正在翻譯），還屬於準備期。--臺灣杉在此發言 (會客室) 2021年3月5日 (五) 02:25 (UTC)[回覆]

@Taiwania Justo、BlackShadowG：我認為有立為指引的必要，這樣移動大型討論的動作才會有憑據，否則可能會出現移動大型討論的編輯戰（之前存檔討論的事情也出現過同樣的問題）。和WP:RFC連動的問題，我認為在現時預留和RFC連動的空間，然後屆時RFC正式通過時同時連帶修改Wikipedia:集中討論也非不可。SAN MO SA _{江南好，風景舊曾諳} 2021年3月6日 (六) 04:57 (UTC)[回覆]

(※)注意:沒有看到升級方針指引的必要，而且提案的內容被摺疊或隱藏，不利於用戶瞭解提案原因，也無法瞭解有多少人具體已經表態了。--蟲蟲飛♡♡→♡℃※留言 2021年3月6日 (六) 05:07 (UTC)[回覆]

集中討論似乎並非一定要與RFC配合使用，看起來{{Centralized discussion}}只是用於列出需要社群關注的議題，也就是代替目前公告欄中一長串的邀請討論的通知，該模板啟用以後公告欄中需要留下通知性的消息即可，可以很好地給公告欄「減壓」。——BlackShadowG（留言）_{維基百科20歲生日快樂！} 2021年3月6日 (六) 08:32 (UTC)[回覆]

公告欄的效果較好吧，很多用戶甚至把公告欄放在用戶頁，重大提案理應發公告，讓提案廣為人知。--蟲蟲飛♡♡→♡℃※留言 2021年3月6日 (六) 08:38 (UTC)[回覆]

我覺得顯然是{{Centralized discussion}}的效果更好，目前公告欄空間本來就不多，而其中3-4條通知都是邀請參與討論，佔據了不少空間。而且這些討論的連結都集中在幾行，觀感很不好。{{Centralized discussion}}則可以將討論連結點列式排列，且沒有上限。目前大多數將公告欄加入用戶頁的用戶關心的應該是一些比較重要的變動，而非一長串正在進行的討論。模板啟用後，公告欄只需要留下一些通知類的事項，而提案的連結則放置到該模板。這樣關注客棧議題的用戶可以將{{Centralized discussion}}加入用戶頁，接收其它通知的用戶可以把公告欄加入用戶頁，各得其所。討論結束後，還可以將連結存檔至WP:集中討論/存檔，便於記錄每次提案。——BlackShadowG（留言）_{維基百科20歲生日快樂！} 2021年3月6日 (六) 16:11 (UTC)[回覆]

我自己的想法是公告欄和{{Centralized discussion}}並行。SAN MO SA _{江南好，風景舊曾諳} 2021年3月7日 (日) 01:07 (UTC)[回覆]

確實是要並行，只不過是把客棧議題的連結移動到{{Centralized discussion}}而已。——BlackShadowG（留言）_{維基百科20歲生日快樂！} 2021年3月7日 (日) 01:47 (UTC)[回覆]

不反對公告欄並行，但我還是比較喜歡客棧「辯論形式」的討論，而不是把不同人的意見分開，像自說自話，而且隱藏某些討論也不利於社羣瞭解其他用戶的表態情況。--蟲蟲飛♡♡→♡℃※留言 2021年3月7日 (日) 01:58 (UTC)[回覆]
沒人說把意見分開，也沒人說要把討論隱藏啊--百無一用是書生 (☎) 2021年3月8日 (一) 02:50 (UTC)[回覆]

您可能忘了，上次提案有人說明了就是把「互助客棧討論過長的議題移動到其他頁面」，我看到其他其他專案是把不同意見分開，就是各自表達意見，但沒有互動和對話。--蟲蟲飛♡♡→♡℃※留言 2021年3月8日 (一) 04:13 (UTC)[回覆]

您誤會了，「把互助客棧討論過長的議題移動到其他頁面」是WP:RFC，與本次集中討論提案並無明顯關聯，建議您先閱讀介紹頁面WP:集中討論。——BlackShadowG（留言）_{維基百科20歲生日快樂！} 2021年3月9日 (二) 11:46 (UTC)[回覆]

(？)疑問:剛再重看了WP:集中討論，沒看到具體改了甚麼，帶來甚麼新的好處，能解釋一下究竟討論模式有甚麼改變嗎？--蟲蟲飛♡♡→♡℃※留言 2021年3月10日 (三) 08:23 (UTC)[回覆]

避免WP:FORUMSHOP和客棧討論焦點被轉移。SAN MO SA _{江南好，風景舊曾諳} 2021年3月11日 (四) 14:10 (UTC)[回覆]

WP:集中討論沒說具體如何改變客棧討論模式，請說明﹗--蟲蟲飛♡♡→♡℃※留言 2021年3月11日 (四) 14:17 (UTC)[回覆]

僅此通知，目前RFC只剩下引入機械人階段，歡迎到此討論。臺灣杉在此發言 (會客室) 2021年3月9日 (二) 12:35 (UTC)[回覆]

(？)異議:還沒有共識引入RFC，怎麼就要申請機械人？--蟲蟲飛♡♡→♡℃※留言 2021年3月10日 (三) 02:42 (UTC)[回覆]

已在技術區回覆。--臺灣杉在此發言 (會客室) 2021年3月10日 (三) 03:21 (UTC)[回覆]

(＋)支持，我認為可以和原有模式並行。-- 五歲抬頭雪菲（☎️·☘️） 2021年3月10日 (三) 07:13 (UTC)[回覆]

整體說明

趁這個時候來把集中討論的疑問全部說一下好了。

首先，集中討論的模板設立後，並不會改變原有的討論模式，只有在公告欄會將部分具有潛在大幅改變社群運作模式（如系統、方針、指引）的討論邀請通知轉移至集中討論模板，除了讓公告欄減壓之外，更能提高這些討論的可見度，而不會塞在一堆公告當中。

其次，討論串過長的問題，還是以討論各方與/或討論發起人的共識及意願，而不是強迫要怎麼做。但我會建議採取「推薦」的方式，也就是當該討論過長時，由討論各方決定是否獨立頁面處理；如果是發起人決定要獨立頁面，也要適時通知討論人等新的討論位置，並修改相應公告。這只是建議與推薦，而不強迫一定要獨立。

希望這些可以解決相關的疑問。臺灣杉在此發言 (會客室) 2021年3月12日 (五) 12:54 (UTC)[回覆]

謝謝澄清﹗--蟲蟲飛♡♡→♡℃※留言 2021年3月12日 (五) 13:49 (UTC)[回覆]

(－)反對

有些用戶把討論內容摺疊已經很令人討厭，現在還要移動到獨立頁面，令其他人不便於閱讀，討論內容應讓社羣看到討論中的所有意見，包括其他用戶如何表態、提案理由、提案要解決的問題等，不應以任何形式令社羣不便看到整個討論內容。
把「方針、指引的討論邀請通知轉移至集中討論模板」更加是不必要，這些重大的提案更應放在公告欄，讓社羣廣泛知悉，相反不重要討論通知才應移至集中討論模板。

以上。--蟲蟲飛♡♡→♡℃※留言 2021年3月12日 (五) 13:48 (UTC)[回覆]

您可能誤解移動到獨立頁面的型態。移動到獨立頁面不是要支解討論內容；相反來說，而是將這個討論的所有內容，包含原始觀點、各方觀點等完整討論移動到獨立頁面，並通知所有人到該獨立頁面討論。這類討論在主流語言版本維基百科當中已行之有年，其實中文維基百科之前也有將某重大議題在獨立頁面討論的先例；獨立頁面只要做好適當的引導，如公告欄提及獨立頁面的位置、互助客棧說明該完整討論已經移動等等，我想應不至於降低可讀性以及討論熱度等。--臺灣杉在此發言 (會客室) 2021年3月12日 (五) 20:16 (UTC)[回覆]

其實就我而言，中文維基百科目前的討論太依賴互助客棧，有很多的小型討論原本不應該在互助客棧討論，而是要先在其他討論頁討論，真的有重大議題才會在互助客棧討論。而這個部分可能需要慢慢做調整；RFC就是來解決這種情況的，可以讓其他討論頁的討論更容易讓社群知悉。--臺灣杉在此發言 (會客室) 2021年3月12日 (五) 20:23 (UTC)[回覆]

(※)注意

您有以下誤解：

一個客棧提案只要沒有異議，呈現在客棧，經過公示，就算通過。這個公開討論和公示的過程不是收集支持意見，而是看看有沒有異議，這個過程是面對整個社羣，而不是幾個參與討論的用戶。因此，您把討論內容移到別處去，但只通知參與討論的幾個人，這是不符合程序公義。
把討論內容移到別處去，這等同於先把討論關閉，然後存檔，然後繼續討論，但整個討論過程無法讓社羣一目瞭然，這也不符合程序公義。

以上。--蟲蟲飛♡♡→♡℃※留言 2021年3月13日 (六) 14:47 (UTC)[回覆]

(＋)支持，將「方針、指引的討論邀請通知轉移至集中討論模板」可以很好地給公告欄「減壓」，目前的公告欄能容納的通知不多，而其中三四條都是邀請討論的連結，且各個議題的連結都擠在同一行，除了容易讓某些影響重大的議題連結反而處於不顯眼的位置以外，也佔用了公告欄的大量空間。將其移動到集中討論模板，將連結使用點列列出，更能提高議題的可見度——BlackShadowG（留言）_{維基百科20歲生日快樂！} 2021年3月13日 (六) 09:33 (UTC)[回覆]

(：)回應

您有以下誤解：

把方針修訂通知從公告欄移到社羣不熟悉「集中討論模板」，不能「減壓」，只是把「集中公告」變成「分散公告」，公告的數量沒有減少，只是讓社羣更難瞭解有甚麼在公告。
方針修訂等屬於重大公告，但卻把重大公告移到社羣不熟悉的「集中討論模板」，讓社羣無法從公告欄中知悉有關方針修訂，屬於本末倒置。相反，為甚麼不把不重要的公告移到「集中討論模板」呢？
更有效的方法去為公告欄「減壓」，應該訂法則，減少濫於發公告；而不是把重大的方針修訂從公告欄移走。

以上。--蟲蟲飛♡♡→♡℃※留言 2021年3月13日 (六) 14:32 (UTC)[回覆]

@蟲蟲飛：從上文看集中討論是用於草案初審、討論和修訂，而不是代替公告欄的公示和召集作用，我認為您對用法有誤解。這將能避免提案被快速修訂（數個版本，按討論順序排列，以及早期版本埋藏於客棧頁修訂歷史）、人多嘴雜和早期投票支持搞亂版面，並能將主要的編輯歷史和查閱放在討論頁而非客棧。等初步方案達成，再於客棧宣佈公示，版面可能更整潔易讀，不影響希望早期參與的維基人從公告欄等處看到通知、前往討論頁議事、在客棧表態。--YF dyh000（留言） 2021年3月13日 (六) 14:53 (UTC)[回覆]

可能討論太亂了，搞到您也誤解了，提案是為公告「減壓」，把方針等重大公告，移到新建的「集中討論模板」，把「集中公告」變成「分散公告」，而且「集中討論模板」是甚麼樣子，大家都不瞭解；如果理解錯，請提案人澄清。--蟲蟲飛♡♡→♡℃※留言 2021年3月13日 (六) 14:59 (UTC)[回覆]

集中討論模板就是{{Centralized discussion}}（下簡稱「cent模板」），且提案通過後cent模板也會加入到互助客棧的頂端，用戶也可以將cent模板加入到用戶頁，仍然能起到「集中公告」的作用。——BlackShadowG（留言）_{維基百科20歲生日快樂！} 2021年3月14日 (日) 01:26 (UTC)[回覆]

誒……@BlackShadowG：那麼這樣做與在公告欄中提供一個預設摺疊的客棧當前討論名單，有區別嗎。用戶不手動訪問「集中討論」模板，是否就看不到最新的重要討論列表了。--YF dyh000（留言） 2021年3月14日 (日) 01:39 (UTC)[回覆]

@YFdyh000：在公告欄中提供一個預設摺疊的客棧當前討論名單確實是個不錯的主意（雖然我覺得這似乎沒有集中討論模板顯眼），不過即使用戶不手動訪問「集中討論」模板也可以看到最新的重要討論列表，因為提案通過後cent模板會放在互助客棧頂端，與公告欄並列。——BlackShadowG（留言）_{維基百科20歲生日快樂！} 2021年3月14日 (日) 02:06 (UTC)[回覆]
@BlackShadowG：不能解決只看近期變更或其他地方的公告欄而不定期查閱客棧主題列表的維基人的痛點，這些人將不能及時獲知最新討論和公示。所以「集中討論」是「集中公佈討論」而非「集中進行討論」嗎……

根據WP:集中討論：「這些討論通常會在相應的討論頁面進行，也有可能發生在元維基、IRC以及我們的電子郵件清單。」，這個模板的真正作用是提及在各討論頁而非客棧頁面進行中的討論啊（而不是在客棧頁作一個小的主題列表），避免中維目前各個討論頁淪為存檔頁或ping場所不然基本沒人看、沒人理的現狀。先與相關頁長期參與者討論，等需要大規模評議、公示時再用客棧頁面和公告欄，而不是啥事都放客棧然後結束後存檔。--YF dyh000（留言） 2021年3月14日 (日) 02:16 (UTC)[回覆]

本討論距離最後一次留言已逾六日，依據上面討論取得之最低共識如下：

集中討論模板將先用於非互助客棧討論以外的其餘討論頁討論，必須是WP:集中討論內所羅列之事項，並放置於WP:互助客棧/方針頁首。
是否納入互助客棧的討論事項，以及是否將公告欄的「討論」專案頁面部分移至集中討論模板，因無共識，日後再議。

以上結論將在明日進行公示。臺灣杉在此發言 (會客室) 2021年3月20日 (六) 05:36 (UTC)[回覆]

(！)意見:您要公示的內容和wp:集中討論不吻合，請先修改wp:集中討論中的內容吧﹗--蟲蟲飛♡♡→♡℃※留言 2021年3月20日 (六) 08:33 (UTC)[回覆]

本頁並非方針頁，僅為資訊頁，不適用「方針、指引」的變更流程；結論公示與修改相關內容不相關；然而明天公示時會一併提出修改方案。--臺灣杉在此發言 (會客室) 2021年3月20日 (六) 11:11 (UTC)[回覆]

我覺得可以把目前的共識先公示後繼續討論是否納入互助客棧的討論事項，以及是否將公告欄的「討論」專案頁面部分移至集中討論模板的問題，無需等到「日後」。——BlackShadowG（留言）_{維基百科20歲生日快樂！} 2021年3月21日 (日) 01:20 (UTC)[回覆]

(！)意見:多加一個集中討論模板無助於減少公告，這只是把「集中公告」變成「分散公告」，而且要社羣為了這個改革而重新適應也是問題。更有效的方法是訂立準則，規限甚麼東西才能放在公告欄，減少無意義的公告。而且公告欄很多都是過期的，沒有人去清理，但存檔又很繁瑣又令人卻步，可以考慮是否取消存檔。--蟲蟲飛♡♡→♡℃※留言 2021年3月21日 (日) 03:41 (UTC)[回覆]

以上最低共識內容，依討論先行 公示7日，2021年4月4日 (日) 12:03 (UTC) 結束。由於本頁為資訊頁，因此內容修改部分會在公示期間進行。臺灣杉在此發言 (會客室) 2021年3月28日 (日) 12:02 (UTC)[回覆]

提議建立「元維基用戶查核指南」

原標題為：元維基用戶查核指南」(含IP傀儡查核常規化、合法化)
修改海の向こうは敵だ！|歡迎訂閱維貓報！ 2021年3月31日 (三) 13:57 (UTC)[回覆]

如題，現時中維本地CU權被拔了，目前我們只能通過SRCU進行查核，而本地方針又管不上，我希望建立本指引以規範用戶查核的轉交。

我已經綜合各方針和頁面，寫好了一個草稿用於本次提案，我的想法是將我寫的提案草稿變成正式的指引指南（在經過修訂後）。

提議條文：Draft:元維基用戶查核指引。

這個草稿規範了查核轉交的基本原則，對新手可能濫用傀儡的第一處理方式，共識的形成等等。

同時也說明了「是否可以代為轉交」這個問題。

此外，由於這是我第一次寫這種指引，所以寫的並不好，如果您覺得哪裏可以改善，歡迎指出！

--海の向こうは敵だ！|歡迎訂閱維貓報！ 2021年3月5日 (五) 16:13 (UTC)[回覆]

@BureibuNeko：（1）如請求查核者非被請求查核者，但被請求查核者對查核表示同意／不反對，算不算「請求自我查核」？（2）被請求查核者能否（在有轉交的共識的情況下）進行轉交？SAN MO SA _{江南好，風景舊曾諳} 2021年3月6日 (六) 00:40 (UTC)[回覆]

(：)回應：@Sanmosa：（1）不算，（2）能。此外感謝提醒qwq！稍後我會將其加入草稿，沒考慮到....--海の向こうは敵だ！|歡迎訂閱維貓報！ 2021年3月6日 (六) 00:59 (UTC)[回覆]

完成--海の向こうは敵だ！|歡迎訂閱維貓報！ 2021年3月6日 (六) 01:04 (UTC)[回覆]

個人對該提議表示(－)反對。理由：1.頁面內濫用bold；2.個人認為其內容更適合「說明頁」而不適合成為指引。感謝。--Yining Chen（留言|簽名） 2021年3月6日 (六) 04:26 (UTC)[回覆]

@Yining Chen：粗斜體的運用確實有些問題，已代改。不反對作為說明頁。SAN MO SA _{江南好，風景舊曾諳} 2021年3月6日 (六) 04:42 (UTC)[回覆]

考慮各位的意見，將本此提案更正為「指南」（即說明頁）。--海の向こうは敵だ！|歡迎訂閱維貓報！ 2021年3月6日 (六) 08:45 (UTC)[回覆]
@Yining Chen、Sanmosa--海の向こうは敵だ！|歡迎訂閱維貓報！ 2021年3月6日 (六) 08:46 (UTC)[回覆]

(－)反對。（1）把「指引」改成「指南」，所以這到底是指引還是指南？如果就把名字改了，但從共識級別上還是指引，這有什麼區別？（2）請提案者論述為什麼對新手進行用戶查核，是可能對新手造成傷害的行為、為什麼對普通用戶的請求應該「慎之又慎」。在我看來，應該「慎之又慎」的是管理員按照duck等理由封鎖新手。而查核的技術證據可以在duck之外幫助判斷某新帳號是否為傀儡，減少誤封，應該多加提倡才對。（3）現在在RFCUHAM上的一大問題是查sleeper的頻率。過頻繁的話，監管員不願意查；不頻繁的話，LTA作祟就沒得管。這導致RFCUHAM上堆的大多數積壓請求都是查sleeper。本提案沒有解決這一問題，甚至沒有解決任何問題，只是把當前大家的通常做法給寫出來了，寫得還不算完全。我沒看到任何制訂指引的必要。沒壞就不要修，我想請提案人講一下當前有什麼問題是需要本指引來解決的。--Techyan（留言） 2021年3月6日 (六) 11:36 (UTC)[回覆]

（1）WP:CONCOVID-19不就是一個前例嗎，你倒是説説這東西的級別是甚麽。（2）我覺得兩個都要「慎之又慎」吧。畢竟CU請求某程度上屬於指控，不當的指控確然會造成傷害。（3）有總結好過沒總結，新用戶至少也會清楚現在的HAM大概是怎樣做的。SAN MO SA _{江南好，風景舊曾諳} 2021年3月8日 (一) 12:23 (UTC)[回覆]

人來了（（（，首先，我只是感覺名字有問題，我寫的這玩應就和指南一樣，用處也和指南沒啥區別，所以改個名也無可厚非。第二，其實關於這個是因為我所知道的一個真實案例，因為我的誤提報而導致對方（新手）想要不再編輯wikipedia，所以我感覺有些必要寫入，技術查核證據雖然可以更加幫助解決相關問題，但如若遇見類似於在同一個辦公室工作，使用同一版本瀏覽器的幾個用戶（這也是一個真實案例，我想Techyan您應該還記得）也是沒啥用，還有就是用戶查核越多，就代表用戶IP知道的人就越多，誠然，有相關協議規定，可惜還是會有人故意泄露。而且就和Sanmosa君一樣，兩者都該慎之又慎。第三，頻繁的查Sleepers這方面，本指南的態度應該是屬於不支持而又不反對。而且監管員不願意查我能怎麼辦？「只是把當前大家的通常做法給寫出來了」，是，但是新用戶、不了解查核流程的用戶可能不了解這些。而至於「沒壞就不要修」，我不覺得沒壞，我見HAM頁從頭到尾哪裏寫過關於「是否可以代為轉交」這一類的問題，我想去告訴下因此產生異議的用戶我都找不到來源，我不覺得此為「沒壞」。以上。--海の向こうは敵だ！|歡迎訂閱維貓報！ 2021年3月12日 (五) 13:39 (UTC)[回覆]

(＝)中立，蟲蟲飛怎麼封的Jennylauk，我看傻了。故希望被查核者可以在有共識時自行轉交。--E.A.Crowley6 6 6^✍️ 2021年3月7日 (日) 13:10 (UTC)[回覆]

有了蟲兒飛，歡樂少不了。但WP:SRCU講不適用自證清白。--YF dyh000（留言） 2021年3月7日 (日) 13:43 (UTC)[回覆]

@EdwardAlexanderCrowley、YFdyh000：上面提案人已經説明被請求查核者能在有轉交的共識的情況下進行轉交。他也説明了請求查核者非被請求查核者，但被請求查核者對查核表示同意／不反對，並不算「請求自我查核」。SAN MO SA _{江南好，風景舊曾諳} 2021年3月8日 (一) 12:23 (UTC)[回覆]

積極促成有濫用工具自證清白的嫌疑，欠缺利益上的避嫌、可引發爭議（如「如此有信心，是不是……」），元維基也可能拒絕查證自己的請求。表達態度或許可以，轉交又不差一人。--YF dyh000（留言） 2021年3月9日 (二) 02:35 (UTC)[回覆]

meta那邊有前例，我認為你說的可能性不大。SAN MO SA _{江南好，風景舊曾諳} 2021年3月9日 (二) 05:45 (UTC)[回覆]

仍然(－)反對將「轉交」這一事項單獨列出設立指引。即便有相關需求，也可以通過在WP:CU里添加內容來解決，再立一個指引是無必要的。另外，查核IP應該是不可能的。基金會有相關政策。--Yining Chen（留言|簽名） 2021年3月13日 (六) 13:13 (UTC)[回覆]

(：)回應我自認爲CU頁面裏介紹轉交方法不是什麽好的想法，而至於「查核IP應該是不可能的」，寫的是查核IP和用戶之間的關係。而這個案例請見上次的AndyandyandyAlbert事件,已經為本指南的這一條「打下了堅實的基礎」。--海の向こうは敵だ！|歡迎訂閱維貓報！ 2021年3月14日 (日) 06:01 (UTC)[回覆]

... 話說沒人來嗎...--海の向こうは敵だ！|歡迎訂閱維貓報！ 2021年3月21日 (日) 10:53 (UTC)[回覆]

除非一名監管員在元維基或中文維基百科親自宣佈「中文維基百科社群可以提交針對檢查IP與用戶關係的查核請求」，否則您的表述無法令人信服。因為這種行為看起來似乎很顯然違反了私隱政策。--Yining Chen（留言|簽名） 2021年3月23日 (二) 14:21 (UTC)[回覆]

@Yining Chen：是的，我再次查閱後，確認了這種行為違反私隱政策，相關內容稍後移除。此外，就有關相關事件我將會與OC（申訴委員會）聯繫，確認自舉是否違反相關政策。最後，感謝您的寶貴意見！--海の向こうは敵だ！|歡迎訂閱維貓報！ 2021年3月27日 (六) 12:54 (UTC)[回覆]

完成--海の向こうは敵だ！|歡迎訂閱維貓報！ 2021年3月27日 (六) 12:59 (UTC)[回覆]

修訂刪除方針第1（刪除理由）章節第9項

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

對象：Wikipedia:刪除方針#9

提案：

現行條文

9. 多餘無用，且影響其他模板命名或者百科運作的模板。

提議條文

9. 未被使用或被腳本引用，且：影響其他模板命名或者百科運作的模板，或近期沒有使用價值也缺乏參考意義，其中：

參考價值，可以指諸如：功能已被合併的模板，仍被部分頁面的歷史版本所使用，其存在有助於主要歷史版本完整呈現時，模板所具備的價值。

理由：近期在存廢討論和存廢覆核中多見有關多餘無用模板是否應當保留的討論，一些模板儘管並非影響其他模板命名或者百科運作，也有合意刪除的，且這種刪除也並非不合理：

2021年1月「Template:2017年香港播出之動畫」存廢覆核指出此種刪除其實回應了站內「日常整理、保持井然有序」的需求，我認為這是合理的；
從該條方針制定的原始討論來看，現行條文的制定主要是為避免僅僅因為沒有連入而提刪（尤其實務上也起到了阻止對無連入模板作單純批量提刪的效果），而本意不是一概地阻礙多餘無用但尚未影響模板命名和百科運作被刪除。

故建議允許「經討論在合理預期範圍內近期沒有使用價值也缺乏參考意義」也作為一可選條件，適當放寬現行條文。

以上。--Kirk★ # 2021年3月7日 (日) 15:45 (UTC)[回覆]

這樣的話「影響其他模板命名或者百科運作的模板」無需再提。同意你的理由，我建議改成一句話「多餘無用的模板」即可，原因是：

其他的刪除理由比較簡潔，沒這麼多字。
模板除了嵌入和腳本外還有其他使用方式（如subst），沒必要列舉。
「參考價值」是一種保留模板的理由，但不需要寫在刪除方針里，完全可以在存廢討論中提出。

--Lt2818（留言） 2021年3月7日 (日) 17:25 (UTC)[回覆]

改成一句話亦可，但應有適當描述阻撓單純大批量提刪無連入模板的行為（這也是之前加入「且影響其他模板命名或者百科運作」這一條件考量之一），第3條原因所指的「完全可以在存廢討論中提出」，建立在所提出刪除是適量的，可/來得及被社群仔細審視的基礎上，而不是不足以應付的。故，第1條原因的簡潔需求不是最終需求，而要建立在方針能夠適用、能夠闡述清楚規則的基礎上。--Kirk★ # 2021年3月7日 (日) 17:35 (UTC)[回覆]

你的提議條文說實話沒闡述清楚，看兩三遍才能讀懂。整段話結構是!(A|B)&((C|D)|(!E&!F...))，不被你繞暈才怪。

要達到目的就直接說明好了，不用兜圈子。「多餘無用的模板。請注意無連入模板也可能有用，並非提刪的充分理由。」--Lt2818（留言） 2021年3月7日 (日) 18:08 (UTC)[回覆]

可。（或再補個，「不要批量提刪」一類的）。--KirkLU-Librarian（留言） 2021年3月7日 (日) 18:22 (UTC)[回覆]

也不用。不合適的批量提刪容易引起反感，離封鎖不遠。--Lt2818（留言） 2021年3月7日 (日) 18:32 (UTC)[回覆]

好，這樣說大致也是合理的。Lt2818閣下的方案，我覺得我也是可以贊成的。--Kirk★ # 2021年3月8日 (一) 06:17 (UTC)[回覆]

(＋)支持:修訂得很好，但建議把「且」改為「或」。--蟲蟲飛♡♡→♡℃※留言 2021年3月8日 (一) 04:27 (UTC)[回覆]

絕對不能。--Bookwith（留言） 2021年3月8日 (一) 07:50 (UTC)[回覆]

現在afd提刪理由都不會符「且」的條件，如果保留，則引發drv案，如果刪除，又不符方針。--蟲蟲飛♡♡→♡℃※留言 2021年3月8日 (一) 11:06 (UTC)[回覆]

DP説的是「一個頁面通常出於下列原因而需要被刪除」，所以在一定的情況下，不是那14個理由也能刪除（但有點IAR了）。另一方面，DP有14個理由，那不合9但合其他還是能刪除（例如12）。SAN MO SA _{江南好，風景舊曾諳} 2021年3月8日 (一) 12:27 (UTC)[回覆]

方案比較：

現行條文

9. 多餘無用，且影響其他模板命名或者百科運作的模板。

提議條文

9. 未被使用或被腳本引用，且：影響其他模板命名或者百科運作的模板，或近期沒有使用價值也缺乏參考意義，其中：

參考價值，可以指諸如：功能已被合併的模板，仍被部分頁面的歷史版本所使用，其存在有助於主要歷史版本完整呈現時，模板所具備的價值。

現行條文

9. 多餘無用，且影響其他模板命名或者百科運作的模板。

提議條文

9. 多餘無用的模板。請注意無連入模板也可能有用，模板無連入並非提刪的充分理由。

兩個方案都還行，看看大家意見。無論采哪種，我認為最有必要實現的還是兩點：

（為什麼改）放鬆過於嚴苛的約束，以免阻礙正常清理工作；
（改成什麼樣）保證社群能夠在AFD，對有無使用價值、參考價值的問題進行仔細審視、討論和決定；
包括，防止以「無用」為由進行批量提刪，致使社群無暇審視、擾亂AFD運作的情況發生。--Kirk★ # 2021年3月9日 (二) 12:12 (UTC)[回覆]

合併後新提案：

現行條文

9. 多餘無用，且影響其他模板命名或者百科運作的模板。

提議條文

9. 多餘無用的模板。^[1]

參考資料

^ 模板無連入並非提刪的充分理由，除連入外應從是否被腳本引用、是否有助於主要歷史版本完整呈現、是否短期內有機會再被復用等方面考量是否仍有使用價值。

基於上述兩種方案和修訂所期望達到的目的，提出了一個字面上簡潔、而通過註釋使得意思完整的新提案，作為擬付諸公示的文本。若經討論合適可付諸公示。--Kirk★ # 2021年3月12日 (五) 14:19 (UTC)[回覆]

還可以。建議你刪去最後一句話，這和「遊戲維基規則」不大一樣，也沒必要醜話在前，況且有時候確實需要大量提刪模板。--Lt2818（留言） 2021年3月12日 (五) 15:01 (UTC)[回覆]

兩點想法：

指出「純粹大量提刪」的違規風險，不損害合理提刪。合理的大量提刪往往是（雖然也並不必然是）系列模板（，就意味着可以合併審視），且更重要的是會附有為何需要大量提刪的合理理由，且提刪者常常會為社群審視提供必要便利。
正是有鑑於方針上一次收緊的原因，本次方針在放寬提刪條件的同時，期待使用現行方針給WP:DISRUPT行為設定明確的阻礙（或事先勸誡）。純粹「挖墳」舊模板、無差別大批量送交的行為，是濫用方針提供的提刪程序，「用以推進明顯非方針原意的目的」。^[1]而方針的原意——同時也是根據現有的先例——是幫助編輯更方便地開展對模板的日常整理工作。^[2]^[3]^[4]

以上。--Kirk★ # 2021年3月12日 (五) 18:20 (UTC)[回覆]

提刪者如果根本不重視維基規則，「遊戲維基規則」的帽子戴着就不合適。不當行為還有很多種（比如把模板的連入都刪除後提刪之），無法一一列舉。以此觀之，條文越細，可能的漏洞就越多，所以寧可保持簡潔，以留有適應各種情況的餘地。--Lt2818（留言） 2021年3月14日 (日) 12:15 (UTC)[回覆]

(＋)支持，不過最後一句話有點WP:BEAN。——BlackShadowG（留言）_{維基百科20歲生日快樂！} 2021年3月13日 (六) 14:25 (UTC)[回覆]
(＋)支持最新提案。最後一句贊成刪掉，不需預先警告模糊的邊界，有礙勇於編輯。--YF dyh000（留言） 2021年3月13日 (六) 14:33 (UTC)[回覆]
啊，眾意如此便不明確寫入了。根據具體情況適用GAME亦可。--Kirk★ # 2021年3月14日 (日) 11:34 (UTC)[回覆]
支持，影響其他模板命名或者百科運作的模板界定籠統-- Sunny00217 2021年3月14日 (日) 14:21 (UTC)[回覆]
不是很同意。刪除是最終手段，模板「多餘無用」（即使並不只在無連入的意義上無用）並不成為要刪的理由。提刪者必須說明刪除該模板為何有利於百科全書建設。或許有人認為多餘無用的模板的存在本身就不利於百科全書建設，但我現在找不到同意這一點的充足理由。--DrizzleD _{(按此給我留言)} 2021年3月15日 (一) 10:04 (UTC)[回覆]
@DrizzleD：幾方面想法：
1. 修訂主要是出於，對諸多存廢案提出（或至少反映出）的「本站日常整理、保持井然有序」^[2]的需求所進行的回應；逐案覆核並以超越基本字面意思的方式說理^[2]應當僅可作為短期措施，更長期來說如果需求合理，制定統一的新規則回應這種需求並給予明確規範是必要的；
2. 在方針上回應這種需求（「本站日常整理、保持井然有序」），實際上就是認可其合理性，認可了處理「多餘無用」模板確實能帶來益處，包括但不限於（以下幾類可能互有重疊）：
  - 剔除無用的舊模板，有利於防止（尤其是新手或許因為不熟悉會）意外地使用舊的模板或在舊模板上貢獻。
  - 所反映內容已在現實中失去效力的模板（比如，南京市旗幟模板^[4]）可以防止此類失效內容再被添加進條目。
  - 有些模板是納入分類的，對確實不需要的模板進行清理，也能有利於分類的整理。
  - 甚至僅僅是視覺上，對整齊的追求。（只要能符合前提——確保被刪模板確實無用）
3. 為什麼草案要求提刪時審視「確保無用」而不同時要求說明「刪除所帶來的益處」：
  - 主要是因為「確保無用」才是最決定性的規則——即使論證了有一筆刪除很多益處，只要模板仍然是「有用」的，就應當通過其他適當方式協調處理——也是最需要眾意審視的規則（類似「利於呈現歷史版本」、「被腳本引用」的情況，由大家共同審視是最妥當的）。
  - 而與之相對地，「觀感整齊」、「利於分類整理」、「利於防止廢棄版本誤用」等利處反而是普遍存在的（比如，多數模板是有分類的，模板的廢棄多數是因為不必要也不應當再使用），不是提刪說理和審視的重點。
  - 況且，模板的「廢棄、不再使用、也不具有其他可利用價值」本身也事實上證明了「改善後繼續使用」或「挪為他用」已是不可能或不經濟（方便）或不必要的，其實也就證明了刪除並不違背「刪除是最終手段」這個精神。（「刪除是最終手段」實際上是一種「我覺得還可以再搶救一下」的精神，對於一個有潛力的條目這個原則自然重要，對於廢棄的模板卻往往不是如此）
以上，不知妥否？--Kirk★ # 2021年3月15日 (一) 16:01 (UTC)[回覆]
給廢棄模板掛上{{deprecated}}等，足以防止新手意外使用舊模板。

刪除廢棄模板原始碼的[[Category:]]項，應該不會比刪除它們更麻煩。

請問對整齊的追求中的「整齊」是指哪一方面？

人們很難預見一個模板是不是有用。原先以為沒用的東西最後被證明有用的事情，至少在人類歷史上為數不少。至於在維基百科上，也容易想像這樣的情景，例如後來者利用了原廢棄模板的代碼（即使不利用內容）等。

顯然不應該使用的模板，也許（不敢說往往）可以依其他方針刪除，例如廣告宣傳。

對於某些個例，確實幹擾到了百科運作的模板，可以依原方針刪除。

但我確實想到一個可能的通用理由，妨礙搜尋。不知道技術層面上能否解決此問題。--DrizzleD _{(按此給我留言)} 2021年3月21日 (日) 06:00 (UTC)[回覆]
這和刪除無用的MediaWiki系統消息沒兩樣。你的理由對於非模板也一樣適用，舉個例子，難道刪除小小作品還要說明為何有利於百科全書建設？維基百科不能變成垃圾堆，這一條就足夠了。--Lt2818（留言） 2021年3月21日 (日) 10:41 (UTC)[回覆]
小小作品是在條目空間的，廢棄模板不是。--DrizzleD _{(按此給我留言)} 2021年3月28日 (日) 07:23 (UTC)[回覆]

@DrizzleD：意見部分同上：
「不整齊」是多方面的：提案設立的刪除標準包括了沒有使用和參考價值，加掛「不活躍/不使用/存檔模板」的通常作用是備考（如，討論頁存檔）或以備使用（如，不活躍專題）。加掛{{deprecated}}等模板但實際沒有參考和使用價值，移除Category讓原本各自歸類的模板變得「流浪」，再加上（如您所說）這些模板又被搜尋到，從而降低搜尋結果的有效性。

「有用」或無用的問題，也沒有上升到「最後被證明」的高度，只是以「近（短）期」內為準。看遠期缺乏意義，不僅誰也看不准，且從模板技術實現和所包含的內容都不斷變化的角度看，遠期對陳年舊模板進行改造還不如重做更為方便也是高度蓋然的。^[5]

總之，刪除作為處理一部分退役模板的「最終手段」，符合刪除方針的精神，不顯著有害的同時，帶來了一部分利處。--Kirk # 2021年3月22日 (一) 15:59 (UTC)[回覆]
凱恩斯這麼說的背景是擴張性的經濟政策的確至少在短期內有益，並不是長期危害看不清，所以問題還是回到比較好處和害處上面來。

移除Category固然讓原本各自歸類的模板變得「流浪」，但此種「流浪」的程度低於直接刪除帶來的「流浪」的程度。畢竟「流浪」不好，也是因為它會妨礙利用。

從實踐上來說，難以期望每個提刪者和參與討論者能充分檢查「是否被腳本引用、是否有助於主要歷史版本完整呈現、是否短期內有機會再被復用等方面」，例如檢查模板在未知條目的歷史版本中的出現要比檢查條目關注度困難得多。存在錯刪的風險。--DrizzleD _{(按此給我留言)} 2021年3月28日 (日) 07:37 (UTC)[回覆]

不過我確實還沒想到一個能讓廢棄模板逃脫一般搜尋，卻又能在某種選項下搜尋到（否則失去意義）的辦法 囧rz……--DrizzleD _{(按此給我留言)} 2021年3月28日 (日) 07:39 (UTC)[回覆]
@DrizzleD：我能認可您提出的潛在風險的問題，不過我還是認為收益還是更大的。（考慮到方案的利弊上面逐項列示大致已經充分了）或許我換個角度，具體來說，此處所討論的內容實際上是為了澄清包括前面提到的四個存廢^[2]^[3]^[4]在內的所有類似案例到底應該如何操作。或許為合理的實操建立更明確的規則，比完全需要逐個超越方針原文適用更為有益。--Kirk # 2021年3月29日 (一) 14:29 (UTC)[回覆]

參考資料

^ Wikipedia:遊戲維基規則第4（濫用程序）章節。在「遊戲維基規則、人身攻擊、為闡述觀點而擾亂」三種情形中，模板提刪尤以第一種為甚。
^ ^2.0 ^2.1 ^2.2 ^2.3 2021年1月「Template:2017年香港播出之動畫」存廢覆核（[2021]DRV-01/11-23{TPLT}）：「……不應該過度理解為阻礙本站日常整理、保持井然有序之理由……」。
^ ^3.0 ^3.1 2021年1月29日「Template:NFSC」存廢討論（[2021]AFD-01/29-9{TPLT}），並2021年2月「Template:NFSC」存廢覆核申請（[2021]DRV-02/09-26{TPLT}）。
^ ^4.0 ^4.1 ^4.2 2021年2月「Template:南京市」存廢覆核申請（[2021]DRV-02/20-40{TPLT}）。
^ 或許可以不完全恰當地借用凱恩斯的一句話：「用長期指導當下是一種誤導。因為長期來看，我們都完了。（……this long run is a misleading guide to current affairs. In the long run we are all dead.）」John Maynard Keynes, A Track on Monetary Reform, Promethus Books, 2000 (originally 1923), p. 80.

修訂申請成為管理人員指引第2（流程）章節投票冷靜期條款

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:申請成為管理人員。

通過：

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

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

對象：Wikipedia:申請成為管理人員#流程之2. 檢驗冷靜期

提案：

現行條文

2. 檢驗冷靜期：當管理人員被提名者或自薦者之人事任免投票未通過或中途退選時，90天內不應再次提出申請。在表態時謝絕提名者並不受此限制。

提議條文

2. 檢驗冷靜期：當管理人員被提名者或自薦者之人事任免投票未通過或中途退選時，自投票終止或退選之時起，90天內不應再次提出申請。在表態時謝絕提名者不受此限制。

理由：

現行計算方式存在歧義，即可以解讀為以下兩種含義：
1. 未通過的投票結束後，或中途退選的決定作出後，「冷靜期」即開始計算。
2. 投票未通過的結果或中途退選的決定，經行政員確認之後，「冷靜期」方才開始計算。
行政員確認結果的時間間隔長短是參差的，該種差異不應不均等地影響各被提名者或自薦者的冷靜期的計算。
第2.4（非行政員終止投票）章節指明了冷靜期90天為「緊接的90天」。

另由AnYiLin刪除一處贅字——「並」。（補充於2021年3月8日 (一) 11:30 (UTC)）

故提請修訂。以上。--Kirk★ # 2021年3月7日 (日) 16:58 (UTC)[回覆]

是的，這樣才是正確的計算方法。贊同修改--Bookwith（留言） 2021年3月8日 (一) 07:48 (UTC)[回覆]

同上。順便把「並」刪了。--安憶 ^Talk 2021年3月8日 (一) 08:40 (UTC)[回覆]

啊，謝謝安憶！（方針日常，積壓語病

囧rz……）。--Kirk★ # 2021年3月8日 (一) 11:30 (UTC)[回覆]

逾7日無留言，可付諸公示。--Kirk★ # 2021年3月15日 (一) 16:02 (UTC)[回覆]

先前未於bulletin公告，現重行公示7日。SAN MO SA _{江南好，風景舊曾諳} 2021年3月22日 (一) 00:18 (UTC)[回覆]

@Sanmosa：完。--SW❀^{Dalniy coming soon} 2021年3月29日 (一) 08:37 (UTC)[回覆]

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

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

本主題或以下段落文字，在討論結束後應存檔至Wikipedia:可靠來源/佈告板/存檔/2021年3月。

維基百科:可靠來源/佈告板自2021年1月19日期就某西方新興右翼媒體進行可靠性討論和舉證，討論字元已經超過25萬，由於討論發起人Matt Smith和蟲蟲飛拒絕接受該媒體作為不可靠新聞來源的表決並繼續拖延討論，請第三方未參與討論的管理員進行評估、表決和關閉討論。-- 同舟（論 · 歷） 2021年3月9日 (二) 05:18 (UTC)[回覆]

作為參考，英文WP對該媒體在沒有額外反對意見下一致評定為「Generally unreliable for factual reporting」或「Publishes false or fabricated information, and should be deprecated」-- 同舟（論 · 歷） 2021年3月9日 (二) 05:29 (UTC)[回覆]

(＆)建議:請移玉步至條目區討論！您要禁制來源也應該舉證，提出有效證據證明媒體不可靠，如媒體惡意造假等，而非不同意媒體政治觀點而要禁制媒體。也請您分清甚麼是意見，甚麼是事實，不要混淆！--蟲蟲飛♡♡→♡℃※留言 2021年3月9日 (二) 05:23 (UTC)[回覆]

我沒興趣繼續浪費時間和你這種混餚「新聞報導」與「社評意見」的人繼續討論下去，我舉證無數但現在你連表決都不讓進行。-- 同舟（論 · 歷） 2021年3月9日 (二) 05:29 (UTC)[回覆]

「新聞報導」與「社評意見」與來源是否可靠無關，請您保持文明及禮儀！--蟲蟲飛♡♡→♡℃※留言 2021年3月9日 (二) 05:34 (UTC)[回覆]

「新聞報導與來源是否可靠無關」，這種觀點我也是醉了。-- 同舟（論 · 歷） 2021年3月9日 (二) 05:40 (UTC)[回覆]

@Sameboat：我只能夠說：共識不要求一致意見。至於你想之後怎樣做，也取決於你自己。SAN MO SA _{江南好，風景舊曾諳} 2021年3月9日 (二) 05:48 (UTC)[回覆]

共識沒錯不要求意見一致，但共識要求獲得絕大多數人同意，除了我和m君，還有其他人認為來源在第三級以上，而且wp:共識不是點票，而是看理據。--蟲蟲飛♡♡→♡℃※留言 2021年3月9日 (二) 06:04 (UTC)[回覆]

哦，Wikipedia:可靠來源/佈告板#表決這就是你對「大多數人同意」的定義？-- 同舟（論 · 歷） 2021年3月9日 (二) 06:09 (UTC)[回覆]

維基的提案通常都只有幾個人討論，兩三個反對，已經非常多，而且您們沒有提出有效理據，不是幾個人拉隊，提案就要通過，重點是您們要提出有效理據。--蟲蟲飛♡♡→♡℃※留言 2021年3月9日 (二) 06:31 (UTC)[回覆]

(※)注意:wp:共識不是點票，共識是通過討論來達成，而不是點人頭。--蟲蟲飛♡♡→♡℃※留言 2021年3月9日 (二) 06:33 (UTC)[回覆]

(～)補充:我其實沒興趣介入您們的爭議，但不希望看到社羣動輙因為政見而去禁制媒體，這會影響條目的存廢和編寫，對維基有非常壞的影響。--蟲蟲飛♡♡→♡℃※留言 2021年3月9日 (二) 06:36 (UTC)[回覆]

什麼「因為政見而去禁制媒體」？我舉證的全部都是針對該媒體篡改發言、誤導性標題和誤導性資訊，無視這些違反傳媒操守獲維基百科條目引用才會對條目帶來非常壞的影響。-- 同舟（論 · 歷） 2021年3月9日 (二) 06:46 (UTC)[回覆]

您說的都不是事實，而且加了原創見解，詳見RSN討論。--蟲蟲飛♡♡→♡℃※留言 2021年3月9日 (二) 06:57 (UTC)[回覆]

(！)意見：提醒開題者，對於來源的判斷還是應該以指引Wikipedia:可靠來源#評估來源為準，該指引要求編者「找出其他人對你的資料來源的評論」，而不是編者自己去評論，否則有原創之嫌。依敝人的搜尋結果，《國家脈動》被大部份可靠來源描述為保守媒體，而維基百科並不禁止保守媒體。--Matt Smith（留言） 2021年3月9日 (二) 07:35 (UTC)[回覆]

首先我不是衝着這個媒體是「保守」而反對，如果你認為反對聲音是帶有政治任務實屬不幸。其次是「找出其他人對你的資料來源的評論」不是評估來源的唯一要求，對於這次討論對象的應用也有待商榷，因為該網站是新興網絡傳媒而缺乏同行評審，因此在缺乏評審下是更應該被預設為不可靠。你指有寥寥數個中文媒體引用過它，但這不等於它的可信性已經得到廣泛承認，英文主流媒體對其報導的引用如果你找得到的話歡迎補上。-- 同舟（論 · 歷） 2021年3月9日 (二) 08:32 (UTC)[回覆]

根據WP:CON，共識不強求一致同意，目前參與表決的大多數用戶均支持將其列為第二級，因此應該採納大多數人的意見。——BlackShadowG（留言）_{維基百科20歲生日快樂！} 2021年3月9日 (二) 10:54 (UTC)[回覆]

共識是要獲得絕大多數人同意，只幾個人討論，有四個人說在第三級以上，怎麼會是「絕大多數」呢？而且wp:共識不是點票，而是看理據成立不成立，現在還沒有證據證明媒體不可靠。--蟲蟲飛♡♡→♡℃※留言 2021年3月9日 (二) 11:11 (UTC)[回覆]

等下，哪來的四個人？三月三日前的結果中Matt Smith君在兩次投票中每次都是第三級以上，要說應該算一個人，再加上第二次投票的Mewaqua君，我還是不確定您到底具體意見如何所以先不算您，這也就兩個人呀？--ときさきくるみ 2021年3月9日 (二) 11:56 (UTC)[回覆]

您再看一下。而且請注意wp:共識不是點票，禁制媒體須非常審慎，因為會影響條目的存廢，令維基這個知識寶庫進一步收窄。此外，建議以《某某媒體》(政治)的形式去禁制，這樣才可以減少對非政治性條目的影響。--蟲蟲飛♡♡→♡℃※留言 2021年3月9日 (二) 12:15 (UTC)[回覆]

所以我說的是三月三號前啊，再往前的一票都到2月20號了，說起來我認為要是不再煮起來肯定就保持2-(4)2-2了。至於收窄啊，存廢啊，我覺得您需要舉證一下是怎麼收窄的。順便再提一句，其他更可靠的媒體這樣禁（比如霍芬頓之類的）我還算支持，這個媒體我都不知道怎麼禁，因為無論是社會還是科學方面都有不少反駁這個媒體的，劃分到最後發現還不如一次把所有評出來。--ときさきくるみ 2021年3月9日 (二) 12:26 (UTC)[回覆]

「建議以《某某媒體》(政治)的形式去禁制」這等同於禁制引用所有國家脈動的文章，因為它的新聞報導（或者按蟲蟲飛的解釋：意見）絕大多數是政治相關。-- 同舟（論 · 歷） 2021年3月9日 (二) 12:49 (UTC)[回覆]

「建議以《某某媒體》(政治)的形式去禁制」不等於所有內容，因為媒體還有媒樂版和副刊等。而且請次重申：共識是通過討論去達成，而不是點人頭。否則所有提案都不用討論，直接投票算了。--蟲蟲飛♡♡→♡℃※留言 2021年3月9日 (二) 13:05 (UTC)[回覆]

一般來說英維和中維（雖然我不是很確定中維是不是所有的都這樣，但至少我見到的幾次）的共識是這樣確立的：

各方把自己意見闡述清楚，舉出若干方案（一般會進行15天至一個月）。
投票，或是直接達成共識（後者少）
在投票結束後取一個各方都較為滿意的結果。

所以，如果說不是點人頭也沒錯，但是我認為本次RSN討論中已經討論足夠，投票應該已可以作為一種工具。--ときさきくるみ 2021年3月9日 (二) 13:52 (UTC)[回覆]

再就是，貌似這個媒體沒有娛樂版和副刊，至少我沒找到：

About us：National Pulse成立以在政治問題上提倡誠實（The National Pulse was formed to promote honesty in politics.），我沒看到其提到副刊和娛樂版。
播客：沒看出哪條播客和娛樂有關，也看不出來和副刊有關
Breaking：同樣沒看出哪條新聞和娛樂有關
額外欄目：同樣基本上看不出哪條新聞和娛樂有關
商店：賣東西的，這個倒真是文娛，建議放過這個

--ときさきくるみ 2021年3月9日 (二) 14:05 (UTC)[回覆]

這裏是中文維基，英文維基的東西不適用於本站，wp:共識不是點票，而是看理據成立不成立。此外，還是建議以《某某媒體》(政治)的形式去禁制，這樣對維基的條目的影響較少。--蟲蟲飛♡♡→♡℃※留言 2021年3月10日 (三) 08:27 (UTC)[回覆]
提個意見，有的世界級的可靠來源在一些特定事件上似乎不可靠，比如紐約時報幾乎只要寫到川普永遠是壞的，川普在紐約時報就幾乎不可能有好事，反過來可能在另一方媒體就是完全顛倒的情況--浪子魚（留言） 2021年3月11日 (四) 02:30 (UTC)[回覆]

政治傾向（只報導川普的負面新聞）不等於不可靠，我在舉證反對使用這個媒體亦不是基於其政治傾向，而是其缺乏專業操守（新聞標題與內文不付、新聞不加聲明混入編者主觀意見）、惡意抹黑非政治專業人士如弗契和濫用嚴重譁眾取寵、故意製造恐懼中國的字眼（例如「 Beijing Bowser（美國首都華盛頓特區市長）」、「Washington, District of China」[4]）。WP編者討論時應該盡量避免使用「那又怎麼說」主義（whataboutism）。-- 同舟（論 · 歷） 2021年3月11日 (四) 02:44 (UTC)[回覆]

謝謝你告訴我，一方面我弄錯了意思，另一方面我確實沒想到這個方向，沒想到自己無意間把媒體不中立與是不是可靠混淆在一起--浪子魚（留言） 2021年3月11日 (四) 03:15 (UTC)[回覆]

媒體政治不中立與媒體是否可靠沒有關係，而且「抹黑」是您的「原創意見」，您對媒體的「意見」也不等於事實。建議以《某某媒體》(政治)的形式去禁制，這樣可以滿足某些用戶的政治需要，也可以減少禁制媒體對維基的影響。--蟲蟲飛♡♡→♡℃※留言 2021年3月11日 (四) 03:08 (UTC)[回覆]

謝謝您的說明，一方面我弄錯了意思，另一方面我確實沒想到這點，自己無意間把媒體不中立與可不可靠混淆在一起了。--浪子魚（留言） 2021年3月11日 (四) 03:24 (UTC)[回覆]

媒體可以有自己的政治立場，而維基是通過不同政治立場的媒體去互相平衡來達成「中立」，而不是把其中某些政見媒體禁制，令維基只有「一把聲音」。--蟲蟲飛♡♡→♡℃※留言 2021年3月11日 (四) 03:31 (UTC)[回覆]

我也會找不同立場的放在一起使其平衡，滿足不同用戶的需要，不會去刪別的報導的，只是去年在尋找過程中發現紐時似乎總在報川普壞事，我看標題就知道裏面沒好話了，那時心裏就在想過念頭「這樣到底可不可靠阿」，現在問問大家後豁然開朗了--浪子魚（留言） 2021年3月11日 (四) 03:42 (UTC)[回覆]

針對特定題材禁用媒體應該是該媒體已經報導過不可靠新聞以外的類別，中文WP上已經被禁止引用特定題材的媒體都符合這個前提。就算是管理員最終決定只對這個媒體禁制特定題材被引用（儘管我堅持全面禁制），鑑於針對弗契和其他防疫專家的報導，特定題材禁制範圍至少都得包含「科學」類別。重申禁制這個媒體不是為了滿足個別用戶的政治立場，這是一個非常不友善的惡意假定。--同舟（論 · 歷） 2021年3月11日 (四) 04:00 (UTC)[回覆]

(＆)建議:現在英維也開始傾向於理性，以《某某媒體》(政治)的形式去禁制，試想想您今天去禁制自己不認同的政治立場的媒體，明天人家也把您不喜歡的媒體禁制，長遠來說，對維基有非常壞的影響，最終只會令寫條目越來越難。--蟲蟲飛♡♡→♡℃※留言 2021年3月13日 (六) 15:17 (UTC)[回覆]

我仍不覺得大量誤導性的標題和內文的不當推論是小問題或是與立場有關。--ときさきくるみ 2021年3月15日 (一) 10:55 (UTC)[回覆]

媒體標題的不準確多的是，如果這樣也要禁制，這是自我設限，用戶就更難寫條目了；而且把小數意見的媒體禁制，也令條目的觀點少一把聲音，對維基也有很壞的影響。--蟲蟲飛♡♡→♡℃※留言 2021年3月17日 (三) 12:03 (UTC)[回覆]

「媒體標題的不準確多的是」，主張者應當舉證。還有一個問題不知道您是否考慮過：如果說因為因為定三級的人不算少而定了第三級，那麼為什麼不能因為定第一級的人不算少而定成第一級呢？如您所說，「只幾個人討論，有四個人說在第三級以上」，「維基的提案通常都只有幾個人討論，兩三個反對，已經非常多」，所以應定到第三級，那麼同樣道理，為什麼不能因為只幾個人討論，有兩三個人說在第一級而定到第一級呢？如果說答案是因為第三級不會導致媒體不能用而第一級會導致媒體不能用，那麼應該取消RSN的第一級，因為按照這套邏輯不會有任何媒體被定為第一級，在這套邏輯下的第一級只會有兩種東西：1. 明顯的內容農場。 2. 明顯的個人博客。剩下的所有網頁無需評定直接排除第一級，那麼，第一級就沒有存在的意義了。繼續推論下去可以發現第二級也沒有存在的意義，如果只要一個媒體50％左右的報道是較為可靠——這件事我覺得瀏覽這次討論的不少人開個自媒體然後每轉一篇路透社的通稿再寫一篇個人評論，也就能達到這個要求——那麼這個媒體就不是第二級的話，那麼第二級的存在也沒有了意義（若不然，第二級很明顯就沒有大致的標準），直接將所有媒體定為第三級以上即可。那麼這樣就中立了嗎？並不，我沒看出來這樣怎麼中立了，這樣的結果看起來似乎很好，所有媒體都能用了，但實際上也導致了諸多邊緣的媒體甚至恐怖主義組織的媒體也變成了第三級，反而讓本不應當獲得如此影響力的媒體也變得足夠有影響力。試想一個人打開敘利亞條目後發現所有參考文獻都是伊斯蘭國的媒體（英語：Use of social media by the Islamic State of Iraq and the Levant）將會是多麼滑稽的事吧（相關學術探討1、相關學術探討2）。--ときさきくるみ 2021年3月18日 (四) 03:01 (UTC)+1 [回覆]

有一個觀點應該在RSN沒有被提出的是這個媒體經常引用布賴特巴特新聞網（Breitbart News）作為事實而非觀點意見報導來源[5]，Breitbart News在英文WP那邊不是單單被指定爲不可靠，而是被列入外部連結黑名單。en:WP:BREITBART列出的理由除了是報導假新聞和散播陰謀論外，還有抹黑攻擊WP編者（[6]）和公開WP編者的個人資訊（[7]）。支持這個媒體的各位請不要跟我說各語言WP的政策互不干涉，這種公然擾亂WP社群的媒體是整個維基媒體不能容忍的，而經常引用和附和這個媒體的其他媒體的可靠性都必須受到更嚴格的審查。另外就是曾經公開揚言要斬頭弗契 [8]的班農這個人，創辦人Kassam與他的關係絕對是影響了這個媒體的採編，因為班農與Kassam的政治談話一直會定期更新到這個媒體的頭版。-- 同舟（論 · 歷） 2021年3月18日 (四) 03:33 (UTC)[回覆]

媒體報導疑為不當者~~嫌疑人~~的個人資訊是很正常的事情，哪家媒體沒有報導過？布賴特巴特新聞網只是報導某些WP編者，並沒有「公然擾亂WP社群」，請閣下不要這樣誇大不實。閣下說該媒體不可靠，卻反而暴露了自己的言論有這種頃向。而且閣下有證據能證明該媒體抹黑攻擊WP編者嗎？--Matt Smith（留言） 2021年3月18日 (四) 06:34 (UTC)[回覆]

w:WP:BREITBART？--ときさきくるみ 2021年3月18日 (四) 06:59 (UTC)[回覆]

未經事主同意擅自公開WP編輯的私隱不算擾亂？而且這個結論是英文WP那邊的共識，有異議可以到那邊提出意見，但我相信他們是有充分的理據才會將Breitbart News列入最嚴厲級別的「blacklist」和「deprecate」。「Breitbart News has directly attacked and doxed Wikipedia editors. Posting or linking to another editor's personal information is prohibited under the outing policy, unless the editor is voluntarily disclosing the information on Wikipedia. 」-- 同舟（論 · 歷） 2021年3月18日 (四) 09:24 (UTC)[回覆]

那是維基方針，媒體不是維基用戶，報導疑為不當者~~嫌疑人~~的個人資訊是很常見的，無論疑為不當者~~嫌疑人~~屬於什麼平台、論壇、社群、俱樂部。混淆這兩種不同的情況並聲稱該媒體「公然擾亂WP社群」，這是嚴重失實的言論。而且維基百科不應被用作疑為不當者~~嫌疑人~~的保護傘，那幾個用戶被懷疑涉嫌收錢辦事，閣下不應指責曝光他們的媒體。--Matt Smith（留言） 2021年3月18日 (四) 12:45 (UTC)[回覆]

@Matt Smith：我之前有打算在元維基建個用戶頁面，其中準備放一些名人名言，不知道您能否授權給我您這段回復更多的權限和著作權？謝謝。--ときさきくるみ 2021年3月18日 (四) 13:01 (UTC)[回覆]

更嚴肅地回復一下：Matt Smith君這句話是可證偽的，而且也可以證偽，而且實踐起來並不難（但是理論論證起來會很麻煩），只需要再在英維RSN或者RFC開一次討論即可。--ときさきくるみ 2021年3月18日 (四) 13:08 (UTC)[回覆]

@Matt Smith：無論如何，這至少肯定是違反使用條款的吧。SAN MO SA _{江南好，風景舊曾諳} 2021年3月18日 (四) 13:25 (UTC)[回覆]

有趣，Matt Smith為了辯護特定媒體已經到達了公然支持外部媒體侵犯WP編者的私隱。站外騷擾WP編者是騷擾方針明文禁止的，這是不論被侵犯的編者是否觸犯了特定WP方針都不會改變的。將心比己，如果有媒體指Matt Smith收錢編輯WP而公開你的私隱，不論指控是否屬實，你是否依然支持公開自己私隱這個舉動，並辯稱公開私隱不構成列入禁用來源黑名單的理由？-- 同舟（論 · 歷） 2021年3月18日 (四) 13:29 (UTC)[回覆]

那與媒體報導不當行為是兩回事，請勿混為一談。布賴特巴特新聞網不是維基用戶，因此不存在違反維基方針的問題。打個比喻，允許持槍國家的國民購買槍枝的行為並不違反禁槍國家的法律，因為前者不是後者的國民（註）。--Matt Smith（留言） 2021年3月18日 (四) 13:41 (UTC)[回覆]

所以您是否授權？--ときさきくるみ 2021年3月18日 (四) 13:45 (UTC)[回覆]

請問閣下為何詢問敝人是否受權？維基百科有規定收錄其他用戶的言論之前必須先徵求對方同意嗎？--Matt Smith（留言） 2021年3月18日 (四) 14:01 (UTC)[回覆]

那麼我就預設您這番言論是同意我將您的言論翻譯成英文以及放置在我的用戶頁不違反WP:CC中的人身權了。--ときさきくるみ 2021年3月18日 (四) 14:07 (UTC)[回覆]

敝人不同意，因為那樣引用的結果顯然對敝人不利。--Matt Smith（留言） 2021年3月18日 (四) 14:12 (UTC)[回覆]

那我就預設您上面的發言經不起科學檢驗，真值為假且是對維基編者嚴重的不文明行為及惡意推定，我會考慮等會移除那些留言。--ときさきくるみ 2021年3月18日 (四) 14:21 (UTC)[回覆]

已移除，如有異議還請闡明。--ときさきくるみ 2021年3月18日 (四) 15:28 (UTC)[回覆]

所謂經不起科學檢驗是閣下自己說的，閣下若再擅自移除敝人的留言，敝人就通知管理員。--Matt Smith（留言） 2021年3月18日 (四) 16:19 (UTC)[回覆]

不勞煩您了，我已經提報至VIP了，同時我會考慮同時提報至英文維基及元維基。--ときさきくるみ 2021年3月18日 (四) 16:29 (UTC)[回覆]

那叫亂報告，敝人根本沒有做出破壞行為。--Matt Smith（留言） 2021年3月18日 (四) 16:40 (UTC)[回覆]

我還是覺得第一個版本的評價比較貼合您內心的真實想法，這樣，既然您覺得這不是什麼大問題，那麼把您的言論發英維RFC，讓當事人評判不好嗎？--ときさきくるみ 2021年3月18日 (四) 16:45 (UTC)[回覆]

敝人不知道閣下說的第一個版本是什麼。「涉嫌」（be suspected of being involved）是被懷疑的意思，並未一口咬定。閣下想不想去英維找當事人是閣下的事情。--Matt Smith（留言） 2021年3月18日 (四) 17:03 (UTC)[回覆]

按你的邏輯，因為媒體並不是註冊WP編者，WP也沒有權力禁止引用那些媒體作為來源了，不論理由是否侵犯私隱。-- 同舟（論 · 歷） 2021年3月18日 (四) 13:46 (UTC)[回覆]

非也，WP有權規定自己能或不能引用任何媒體。--Matt Smith（留言） 2021年3月18日 (四) 14:01 (UTC)[回覆]

我覺得有必要告知Matt Smith君一下這位一直在布賴特巴特寫維基百科相關內容的編輯曾經在維基百科有號，還因為反覆違反BLP被多次封鎖，最後因此被永久封鎖了。--ときさきくるみ 2021年3月18日 (四) 13:55 (UTC)[回覆]

那依然與布賴特巴特新聞網本身發佈新聞報導無關，布賴特巴特新聞網不是維基用戶。--Matt Smith（留言） 2021年3月18日 (四) 14:01 (UTC)[回覆]

Wikipedia:RS：「來源在維基百科中有下面三個含義：……作品的作者（作者，記者等）……三者都可以影響內容的可靠性。可靠來源可能意味着有可靠出版過程的出版物，在主題上有權威的作者，或者兩者兼具。來源的可靠性應可以被常人理解」。--ときさきくるみ 2021年3月18日 (四) 14:09 (UTC)[回覆]

該請求已受理；相應討論將擇期關閉。--Antigng（留言） 2021年3月9日 (二) 06:40 (UTC)[回覆]

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

關於Wikipedia:命名常規 (音樂)

延續上次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)[回覆]

~~我這個人最沒有主見了~~，關於「(單曲)」，我上次被百戰天蟲大說服後[9]，覺得很有道理。當然，如果是像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好像已經結束了自行發歌[10]。->>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)[回覆]

我原先倒是想一律不用號字。我在大陸，我看到的來源（包括中央音樂學院的本科招生簡章、校外考級教材，中國音樂家協會的考級教材，人民音樂出版社和花城出版社的初高中課本）只要是數字+體裁的，都沒有號字。但是數字用的是漢字。難道這得按地區詞處理？ ——羊羊 (留言|貢獻|維貓報|古典音樂專題) 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)[回覆]

對於李新陽其它幾點內容：

見上。
「（貝多芬作品）」不在條目名稱里，這個括號只是解釋說明作用，沒什麼關係^[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)[回覆]

(！)意見：命名中幾乎遇不到小調大小寫的情況，不屬於命名常規討論範疇，建議拆分為新討論。 ——羊羊 [ 留言貢獻維貓報古典音樂專題 ] 2021年3月31日 (三) 06:08 (UTC)[回覆]

進行拆分的話倒是沒有任何問題，我主要是看到了「降E大調弦樂五重奏」這個玩意兒，認為應當討論一下大小寫的問題。我現在發現了一個新東西，就是這個夜曲Op. 9 (蕭邦)以及前奏曲Op.28, No. 15 (蕭邦)，我們可能需要引入一個新的話題，即Op和No的問題。我建議翻譯出來比較好，要不然看這很彆扭。--李新陽（留言） 2021年3月31日 (三) 06:59 (UTC)[回覆]

「命名中幾乎遇不到小調大小寫的情況」，我不清楚古典音樂們有多少，但對於小調，我想這部分可以一起處理，尤其是Template:Circle of fifths。~~不過這麼一搞，條目裏面有出現小調我可能都要修改了OTZ~~ --Loving You Is A Losing Game 2021年3月31日 (三) 14:28 (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:互助客棧/方針#修訂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)[回覆]

歷史人物條目Infobox中的出生、死亡地點、籍貫及國家歸屬應統一使用原稱

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

不應一邊用現代名稱，一邊用古代名稱。現名可以加括號放在後面。芄蘭（留言） 2021年3月18日 (四) 18:32 (UTC)[回覆]

有混淆歷史的可能，用不同名稱的原因就是想區別歷史時期。就像我們會將清朝時的「惠陽縣」稱為「歸善縣」，而不會稱為「惠陽縣」；反過來我們會將清朝以後的「惠陽縣」稱為「惠陽縣」，而不會稱為「歸善縣」。我們不會將禮薩汗掌政前的伊朗稱為「伊朗」，也不會將禮薩汗掌政後的伊朗稱為「波斯」。因此，我個人不甚同意此提案。SAN MO SA _{江南好，風景舊曾諳} 2021年3月18日 (四) 23:51 (UTC)[回覆]

當然，如果說的是同一歷史時期（而非跨歷史時期）的話，統一用同一名稱反而是應該的。SAN MO SA _{江南好，風景舊曾諳} 2021年3月18日 (四) 23:56 (UTC)[回覆]

你理解錯。我指的是一個隋代出生的人，在唐代死去，則應分別使用對應的原稱；而非一個用隋唐原稱，一個用今天名稱。如果他在今天才死，那確應用今天名稱。總之他何時死，就應用何時的地名。芄蘭（留言） 2021年3月19日 (五) 00:57 (UTC)[回覆]

那我完全同意你的想法。這不是常識嗎，究竟是發生甚麽事情了？SAN MO SA _{江南好，風景舊曾諳} 2021年3月19日 (五) 03:54 (UTC)[回覆]

鄭成功，有人寫生於日本九州平戶，死於南明承天府，應該寫肥前國平戶、大明承天府（或者東都明京）。芄蘭（留言） 2021年3月20日 (六) 15:12 (UTC)[回覆]

您要這樣寫是應當、合理的，但麻煩在括號裏附註現今的行政區劃，這也是極度必要的。-游蛇脫殼/克勞棣 2021年3月20日 (六) 20:24 (UTC)[回覆]

他上面不就説了「現名可以加括號放在後面」嗎？他不會否定這種做法。SAN MO SA _{江南好，風景舊曾諳} 2021年3月21日 (日) 10:00 (UTC)[回覆]

@芄蘭：你打算就此增訂格式手冊條文嗎？SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 09:59 (UTC)[回覆]

建議增加「歷史人物條目資訊框（Infobox）中的籍貫、出生、死亡地點，應使用該人物所處年代的原稱。可在括號內附註現今名稱。」國家歸屬暫不寫了，感覺有爭議。芄蘭（留言） 2021年3月27日 (六) 15:14 (UTC)[回覆]

有爭議的話循事實論述即可，我們現在有WP:PB，這不是只有兩岸四地相關的才適用。上面草擬的條文可行（但會微調），我看看適合加入的位置。SAN MO SA _{江南好，風景舊曾諳} 2021年3月28日 (日) 00:51 (UTC)[回覆]

建議在WP:格式手冊和WP:分類、列表與導航模板加入以下一條：

“

各條目及資訊框模板中所列出的一切地點、行政區劃、籍貫及國家歸屬等，均使用其所處年代的稱呼。如有需要，可在括號或適當的欄位（如有）內附註現今名稱及國家歸屬。國家歸屬當依《避免地域中心》方針的規定，以事實論述（De facto disclosure）為主。

”

以上。我感覺這不只Infobox和人物條目才需要適用，而且也符合編輯習慣。SAN MO SA _{江南好，風景舊曾諳} 2021年3月28日 (日) 01:04 (UTC)[回覆]

臺灣原住民族人條目命名（第二次）

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

承上次討論，現擬議為Wikipedia:命名常規 (人名)加入以下一條：

“

命名臺灣原住民族人士的傳記條目時，應依據使用中文及使用常用名稱的原則命名。

如其常用名稱為原住民族姓名的格式：

若其戶籍登記的中文姓名為該常用名稱，應採用其戶籍登記的中文姓名，而條目內應附上並列登記的羅馬拼音。
若否，則應將該常用名稱音譯處理，而條目內應附上該常用名稱的羅馬拼音。

如其常用名稱為漢人姓名的格式，且其戶籍登記的中文姓名為該常用名稱，應採用其戶籍登記的中文姓名。

”

以上。此條確立使用漢人姓名或臺灣原住民族人名命名臺灣原住民族人士的傳記條目時均應使用中文命名的原則，但不對以非本名見稱的臺灣原住民族人士的傳記條目造成影響。SAN MO SA _{江南好，風景舊曾諳} 2021年3月22日 (一) 00:53 (UTC)[回覆]

@Yumeto、Lt2818、克勞棣、Y0529543。SAN MO SA _{江南好，風景舊曾諳} 2021年3月22日 (一) 01:00 (UTC)[回覆]

這規定並不能解決究竟是命名為「張惠妹」還是「古歷來·阿密特」的問題。若針對上次事件的話，我覺得重點在於強調人物命名須用漢字。--Lt2818（留言） 2021年3月22日 (一) 03:33 (UTC)[回覆]

@Lt2818：（1）應該是能解決的。張惠妹的戶籍是用甚麼名字登記的？（我看到一些台灣政府網站把她的名字繼續寫成「張惠妹」，臺灣原住民族人名僅為括注，估計應該還是用漢名登記的。）（2）「臺灣原住民族人物命名須用漢字」這點確實也是我希望確立的。SAN MO SA _{江南好，風景舊曾諳} 2021年3月22日 (一) 07:11 (UTC)[回覆]

戶籍登記姓名可能難以查證。況且，即使張惠妹真的登記為「古歷來·阿密特」，用這個名字命名條目恐怕也不合適。剛剛發現Wikipedia:命名常規已寫明「使用中文」，那麼再加上既有的常用名原則，就無須對臺灣原住民族作特別規定。--Lt2818（留言） 2021年3月22日 (一) 09:04 (UTC)[回覆]

如果是這樣的話，那就根本不需要另立規則，因為現行命名常規已經有「使用中文」和「使用常用名稱」的規定，直接搬這兩條出來用就可以，這兩條的應用現時也已經具備相當的靈活性。SAN MO SA _{江南好，風景舊曾諳} 2021年3月22日 (一) 10:12 (UTC)[回覆]

於2021年3月22日 (一) 07:17 (UTC)在不變更提案大意的前提下重寫提案。SAN MO SA _{江南好，風景舊曾諳} 2021年3月22日 (一) 07:17 (UTC)[回覆]

(－)強烈反對。先前U:克勞棣所稱「谷辣斯·尤達卡不僅僅是中文翻譯，這就是她身為中華民國國民的本名」並非事實，原住民提供翻譯或另取的中文名字，時常只是為了配合漢人的風俗習慣以及漢人政權的法律，不見得代表那就是這個人的本名。例如Kolas自己就有公開說他希望人們用拉丁轉寫來表示他的名字，這才叫名從主人。中維對娛樂創作的標題以及藝名那麼重視官方想要的呈現方式，不旦包括無法念出的符號、區分外觀相同只是Unicode編碼不同的符號、通融各種違反中文文法、不存在於中文的文字、或忽視英文大小寫習慣，然而遇到原住民想用自己的方式表示名字時，卻打壓得這麼起勁？

另外，關於張惠妹/阿密特，如果他有表達比較想用哪個名字，那就用那個，沒有表態或兩者都用的情況下才換用常用名。--C9mVio9JRy（留言） 2021年3月24日 (三) 00:24 (UTC)[回覆]

@C9mVio9JRy君：不！這就是事實，只不過您不想承認而已。①請不要斷章取義，我完整的發言的意思明明是「谷辣斯·尤達卡是她身為中華民國國民的本名之一」，她想叫Kolas Yotaka，《姓名條例》也是允許加註的，谷辣斯·尤達卡與Kolas Yotaka兩者都是她的本名；②中華民國國民就該遵守中華民國法律，這無分河洛人、客家人、外省人、新住民或原住民，一律平等。不然要是有個河洛人想叫「張Davidoff」或「張さゆり」或「張πΣαβγ」，甚至是「張☆△∞」，是否也要允許？不然就是打壓？③漢人只能用中文字當唯一本名，無權像原住民、新住民一樣加註拉丁字母，這是不是也不公平？-游蛇脫殼/克勞棣 2021年3月24日 (三) 02:29 (UTC)[回覆]

看來我們對「本名」的定義不同。在我看來「名從主人」不是「名從國家法律」。人類早在世上有國家這種東西之前就有名字了。至於漢人想叫別的，君不見ØZI、走路痛WalkTone、HowHow、J.Sheon、Joeman全都用藝名？我就不信大家講話的時候會念/ø.zi.ai/或「ㄗㄡˇ ㄌㄨˋㄊㄨㄥˋ wɔːk toʊn」。叫漢人用漢字和叫原住民用漢字意義完全不同，一個是用母語，一個是用外語。--C9mVio9JRy（留言） 2021年3月24日 (三) 10:45 (UTC)[回覆]

那請問閣下認為Kolas Yotaka的「母語的本名」怎麼寫？人類早在世上有國家這種東西之前就有名字了固然沒錯，但Kolas Yotaka明顯是人類有國家的概念之後才誕生的人類。另外，請問閣下為什麼未經其他用戶同意，就把他們打的「她」都竄改成「[他]」？-游蛇脫殼/克勞棣 2021年3月24日 (三) 11:04 (UTC)[回覆]

已代改回。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 11:38 (UTC)[回覆]

抱歉我的火狐插件設了性別中立轉換，似乎造成了干擾，以後會注意。Kolas自己選用了Kolas這個寫法，這就是他的名字。--C9mVio9JRy（留言） 2021年3月24日 (三) 12:38 (UTC)[回覆]

Kolas是拉丁字母，一樣是借來音譯用的外語，不是她的母語。拉丁字母Kolas並沒有比中文谷辣斯更正統、更能代表阿美語。-游蛇脫殼/克勞棣 2021年3月24日 (三) 13:36 (UTC)[回覆]

Kolas覺得「Kolas」比「谷辣斯」更能代表他自己，那就夠了，你一位路人對拉丁文字或漢字的看法與他的名字無關。--C9mVio9JRy（留言） 2021年3月24日 (三) 15:32 (UTC)[回覆]

好，無關。-游蛇脫殼/克勞棣 2021年3月24日 (三) 17:07 (UTC)[回覆]

甘仔轄·阿拉米（Kamachat Aslamie）是大肚王國君主，屬於（廣義上的）臺灣原住民，那時候的大肚王國根本沒有文字，上面我給出來的拉丁字母是荷蘭人音譯出來的荷蘭文。試問甘仔轄·阿拉米的「母語的本名」又是甚麼？該用中文還是荷蘭文？SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 11:38 (UTC)[回覆]

當時原住民沒有自己的文字而且當事人已過世，那就用現代中文轉譯，這和現代人的情況不同。--C9mVio9JRy（留言） 2021年3月24日 (三) 12:41 (UTC)[回覆]

可能要考慮不愔拉丁字母的人士的需求。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 00:52 (UTC)[回覆]

重新導向可以帶到條目，條目內也列了漢譯。如果真的很在意有人不懂拉丁字母，我們應該先動手的是hide改成松本秀人、Microsoft Windows改成視窗、甚至iPhone和LINE改成哀鳳和賴。--C9mVio9JRy（留言） 2021年3月24日 (三) 01:05 (UTC)[回覆]

使用率不同。你提到的後三個例子基本上都直接被當成中文使用，但人名並非如此。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 02:07 (UTC)[回覆]

我身邊發音為哀鳳和賴的人比用英語發音成i-phone和line的人更多。--C9mVio9JRy（留言） 2021年3月24日 (三) 10:26 (UTC)[回覆]

可能是所在地不同的情況，我身邊的情況和你身邊的情況完全相反。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 11:24 (UTC)[回覆]

(＋)支持，理據充份，需要有一個可行的維基方針。另提醒維基百科不是宣傳工具，這邊不是宣傳族名拼寫運動或是去中文化的地方（來到中文維基推動去中文化本身目的就抵觸和相反了），這裏只是民間團體的寫作網站，政策方面如有疑義請自行前往監督政府。--章安德魯（留言） 2021年3月26日 (五) 18:42 (UTC)[回覆]

於2021年3月27日 (六) 10:54 (UTC)修改提案，不影響文意。SAN MO SA _{江南好，風景舊曾諳} 2021年3月27日 (六) 10:54 (UTC)[回覆]

仍然(－)反對。理由再重複寫一下：「使用中文」是冗言，理當如此。戶籍登記姓名則難以查證，此規定無意義。--Lt2818（留言） 2021年3月27日 (六) 11:32 (UTC)[回覆]

（1）非冗言。WP:命名常規#使用中文：「……惟若原文名稱比中文翻譯的名稱在中文中更加常用，或如果不存在中文翻譯的名稱，則應使用原文名稱。至於個別專題下之條目之命名，如有對應子方針，則應以該子方針指引之規則為優先。」根據此條，「理當如此」的關係不存在，一來是子方針優先性高於母方針，二來是羅馬拼音可能比中文翻譯在中文中更加常用。（2）政府網頁或身分證上的姓名和戶籍登記的姓名一致。SAN MO SA _{江南好，風景舊曾諳} 2021年3月27日 (六) 13:20 (UTC)[回覆]

舉個例子，國際單位制的重新定義之所以拖到2019年，是因為先前對相關物理常數的測量精確度不足。同樣，除非中華民國能提供所有公民的登記姓名查詢，否則其不應作為判別依據寫入方針。--Lt2818（留言） 2021年3月27日 (六) 15:28 (UTC)[回覆]

反對理由不充份，看不懂國際單位制的例子跟這裏的關聯。另外，以人物傳記條目蔡英文為例，「性別、別名、出生、籍貫、民族、國籍、父母」etc.這些資料同樣都不是來源自（也不可能會有）所謂的「公民登記查詢」資料庫。--章安德魯（留言） 2021年3月29日 (一) 05:00 (UTC)[回覆]

國際單位制的例子為類比。公制確立的時候，把「一米」定義為子午線兩千萬分之一或者米原器長度都沒問題，但不能定義為光在1299792458秒內行進的距離，因為當時沒人測得出光速。提議條文中的「戶籍登記姓名」同理，哪怕張惠妹親屬以其身份證為憑，也不能把條目命名為張鮭魚，正因戶籍登記姓名對於公眾而言無法查證，也不可能讓主張者上傳身份證來證明。--Lt2818（留言） 2021年3月29日 (一) 07:18 (UTC)[回覆]

還是沒有回答到問題：「性別、別名、出生、籍貫、民族、國籍、父母」etc.同樣也沒有開放可直接線上查詢的登記資料庫，所以反對理由不夠合理。另外雖然不具參考性，但是維基上確實是有老蔣的身份證。--章安德魯（留言） 2021年3月30日 (二) 10:55 (UTC)[回覆]

@Ch.Andrew：我不是說身份資訊查詢合理。這個條件和「山無陵，江水為竭，冬雷震震」為同樣性質，作為另一命題的歸謬，本身並非重點。後者應該見過，畢竟溪口、慈湖都曾遊覽過。--Lt2818（留言） 2021年3月30日 (二) 11:48 (UTC)[回覆]

想到一個問題：如果我們認定iPhone和Windows是否已經成為中文外來語的依據是它是否常用，那實質上就是用「常用名稱」作為條目名，比照辦理的話，原住民的名字也應該以常用名優先；如果常用名是拼音，那該用拼音作條目名。然而此提案第二點卻說當拼音確實比中文翻譯更常用時，「應將該常用名稱音譯處理」。我不懂如果iPhone和Windows這兩個常用名稱可以當作外來語使用，不用翻譯成哀鳳和視窗，為什麼原住民的名字卻必須以中文優先？一方面我們接受西方和日本的科技及娛樂主題用原文，一方面我們不允許少數民族用原文，這除了雙重標準和差別待遇之外，我看不出別的解釋。--C9mVio9JRy（留言） 2021年3月28日 (日) 15:10 (UTC)[回覆]

總結來說，我的立場有兩點：(1) 當事人明確表態希望用某種方式表示他的名字時，這是他的基本人權（聯合國人權事務委員會，Coeriel and Aurik v. the Netherlands），應予以尊重，尤其當他們是歷史上曾遭受不正義的少數族群時更應如此，凌駕於常用名稱或使用中文的規定（至於那些單純因商業效果而搞得怪里怪氣的官方作品名或產品名，因不涉人權，可以常用名優先）。(2) 若當事人未表態，但有廣泛接受的常用名，此常用名優先，不管是拼音還是中文，如同電子產品和一些亞洲藝人的情況。--C9mVio9JRy（留言） 2021年3月28日 (日) 18:29 (UTC)[回覆]

因為《姓名條例》對所有中華民國國民都有約束力，並沒有雙重標準。如果一位臺灣原住民不是出於商業因素，而是真心非常非常喜歡數學，喜歡的程度多過他的族群傳統文化，閣下認為他可以用e^(iπ)+1=0作為本名嗎？這也是他的基本人權？那麼臺灣漢人有無這樣的基本人權？-游蛇脫殼/克勞棣 2021年3月29日 (一) 00:24 (UTC)[回覆]

1. 提案中的「將該常用名稱音譯處理」並非使用符合《姓名條例》的法定姓名。2. 姓名條例對中華民國國民的法定姓名有約束力，但對維基百科的條目名沒有約束力。3. 我傾向認為不論法律是否允許，你都有權昭告天下說你的名字是「許星光流連擊鮭魚」，大家也應該尊重。4. 用數學公式當名字目前沒有判例，如果有一般人念不出來的符號或是技術上難以顯示的格式，我猜人權事務委員會可能會同意國家有權禁止該姓名。5. 漢人當然有權利用別的文字當名字，而且維基百科對這些另取名字的漢人可尊重得很，我前面已經舉例了：ØZI、走路痛WalkTone、HowHow、J.Sheon、Joeman。--C9mVio9JRy（留言） 2021年3月29日 (一) 00:53 (UTC)[回覆]

雖然《姓名條例》對伺服器在美國的維基不具約束力，但是仍是一項重要的參考基準。「姓名」和「商標、藝名、產品名、書名」etc.的法律意義及社會意義上都有所不同，姓名是別人如何稱呼你並且令每個人與社會連結的工具。後現代主義讓許多人自我中心慣了，法律和契約這些基本觀念彷彿通通當成空氣一樣。實務上不可能讓姓名權無限上綱，若有人主張自己的姓名是「以微秒變換、以鮭魚起頭接續所有中文字集進行無窮級數排列組合的姓名光譜」，請問該如何呈現？另外還要考慮到姓名跟轉型正義抵觸時被禁止的情況，例如納粹系列的姓名。顯然不可能對於姓名權毫無限制。--章安德魯（留言） 2021年3月30日 (二) 11:25 (UTC)[回覆]

我的要求從來就不是無限上綱，而是把一個技術上可行、在中文維基中本來就存在的寫法（拉丁字母），延伸到既有的「名從主人」規則，並且實行上目前唯一的案例還符合「常用名稱」的規則。你想像的滑坡例子不會有可靠來源，並且可以簡單用技術理由禁止。--C9mVio9JRy（留言） 2021年3月31日 (三) 05:40 (UTC)[回覆]

(－)反對Kolas比谷辣斯更常用、廣為人知，用google去找結果也是這樣。一位原住民符合常用、廣為人知的是拉丁字，還一定要改成漢字，那就請把藝人、運動員、作家...的廣為人知拉丁名條目全部設方針改成漢字，不要只針對原住民。相反若只是原住民自己想要的拉丁名，卻不是廣為人知的常用名，那就不用遷就那個。--2001:B042:1:A724:7CCD:E884:C570:5D6A（留言） 2021年3月29日 (一) 05:20 (UTC)[回覆]

正有此意，規定不應專門針對台灣原住民。合適的行文可以為「人物若以本名命名，應當使用漢字」。--Lt2818（留言） 2021年3月29日 (一) 07:38 (UTC)[回覆]

不管是物件、人物、官方名、藝名……，若他的廣為人知的常用名是拉丁字，倒是不一定要音譯成漢字。可是只要標準是一致的，不是只針對特定族群，這裏就不會去反對了。--2001:B042:1:AF30:7CCD:E884:C570:5D6A（留言） 2021年3月29日 (一) 08:27 (UTC)[回覆]

補充一下，若認為Kolas是中文的話，請加上間隔號書寫為Kolas·Yotaka，畢竟中文不用空格作標點。--Lt2818（留言） 2021年3月29日 (一) 12:42 (UTC)[回覆]

那Microsoft Windows、iPhone 12 Pro和想見想見想見你怎解？--C9mVio9JRy（留言） 2021年3月29日 (一) 16:12 (UTC)[回覆]

皆非人名。前兩者相當於直接引用原文，都能接受（但對人名不適用）；第三者為日本作品，對比該國其他混亂命名（如《你的名字。》《寫不出來！？～編劇吉丸圭佑的無情節生活～》）則相形見絀。我上面的話過於絕對，中文也會使用全形空格，如挪擡等情形。--Lt2818（留言） 2021年3月30日 (二) 05:54 (UTC)[回覆]

提供一個參考，英文維基對人物傳記的指引en:MOS:MULTIPLENAMES有這句：「If a person, or more typically a group, has adopted a new name because they determined the old name to be offensive, generally use the new name for all time periods. 」簡言之，如果某個人認為原本的名字有冒犯性而改名（可能因為牽涉到歷史正義或傳統信仰），英文維基的指引是所有內文都要盡量改成新的名字。依照此精神，如果有位原住民認為漢字名有冒犯性，也應使用族語名。--C9mVio9JRy（留言） 2021年3月29日 (一) 16:53 (UTC)[回覆]

我要解釋一下為何要避開羅馬拼音：假設臺灣原住民的原住民族姓名格式名字的羅馬拼音版本可以當成條目名，那理論上維基百科大部分非華裔傳主的條目的名字也不該音譯，而應該把那串拉丁字母當成條目名，但這顯然是荒謬的。另一方面，嚴格上來說，羅馬拼音根本不是臺灣原住民族語言的「文字」，臺灣原住民族語言本來就沒有「文字」（或已失傳），是後來才引入拉丁字母來拼寫的。甘仔轄·阿拉米（Kamachat Aslamie）的名字應該是拍瀑拉語，但拍瀑拉文根本不存在，我上面給出來的字母是荷蘭文。SAN MO SA _Σουέζ 2021年3月30日 (二) 00:02 (UTC)[回覆]

1.現在的命名原則是標題通常是中文的，可是原文比中文翻譯在中文中更常用，或沒有中文翻譯，就能使用原名。這規則用在原住民身上沒幾位本名能用拉丁字的，暫時也就看到Kolas。若這規則用在非華裔傳主的條目會造成很多拉丁字，然後大家又認為人物本名不能用拉丁字，藝名和各種物件才可以，那就設計一套不是只針對原住民的規則來用。2.這個也是有國家、族群，因為被殖民、嚮往種種情形，引入拉丁字母、漢字當成自己語言的書寫方式，現在原住民的母語也還是用拉丁字母在書寫，所以語言去區分是不是嚴格上自己民族發明的文字，也不是太重要的。--2001:B042:1:AFA9:7CCD:E884:C570:5D6A（留言） 2021年3月30日 (二) 04:31 (UTC)[回覆]

不住在華語圈的人，他們的生活中不會面對名字要怎麼寫的問題，也沒有被漢人壓迫的歷史，所以他們的名字音譯成漢字並不會讓他們感到不愉快，但原住民不然；這在Talk:谷辣斯·尤達卡的討論中U:Reke說明得很清楚。至於你質疑拉丁字母本來不是原住民語言，那是帶有隱性歧視的論述。你去跟閩南語維基百科說他們用的白話字不是閩南語原有的文字，或是要求英文維基改用盧恩字母看看。甚至中文在甲骨文出現以前，本來也是沒有文字的，而且現代這套標準化的楷書是Unicode或中華民國教育部出現之後才有的，我們沒有因此說華語、英語、閩南語沒有文字，為什麼原住民語言卻單獨被指出來？現代原住民語言用拉丁字母書寫，這是客觀的事實，就像中華民國是主權獨立的國家一樣是客觀的事實，只不過有些人受意識型態影響而拒絕承認原住民的文字是文字。--C9mVio9JRy（留言） 2021年3月30日 (二) 12:00 (UTC)[回覆]

美洲原住民同樣也有受壓迫的歷史，卻沒有禁用拉丁字母拚寫族語姓名的呼聲，據此我合理懷疑en:MOS:MULTIPLENAMES指引對台灣原住民姓名的適切性。今天如果是要求台灣原住民的條目必須強制用漢名「林〇〇」「陳〇〇」我想在座各位都不會同意。但是針對族語姓名禁用特定語種文字的拼音，類似的作法在維基上並沒有他語種的先例，敘事邏輯倒是跟十年前蔣為文公開罵黃春明的「台灣作家不用台灣語文，卻用中國語創作，可恥！」相當類似。最重要的是，我不認為禁用的作法對族語的推廣與保存具有正面效益，羅塞塔石碑的存在證明了多語言平行對譯的重要性，施加過多的種種限制反而限縮了族語的自身發展空間。同時我不覺得Sanmosa的論述帶有隱性歧視，他應該是聯想或注意到相較於臺灣原住民族，地球上的許多民族具有明確的自身創制文字系統，例如彝族的彝文、馬雅文明的馬雅文字。另外還有一類，是援用現有文字系統並加以改造的，有加拿大原住民音節文字（援引印度天城文並且改良）、苗族的柏格理苗文（參考前者的經驗而創制）。而臺灣原住民族語羅馬字是法定的書寫系統，跟前兩者不同的是，既不是自有創制或是援引改良，而是直接套用拉丁字母的文字系統，順帶一提臺灣原住民族語也有使用過日文假名、注音字母這2種文字系統[11]。甲骨文其實是相對成熟的文字系統，就像化石也有「失落的環節」那樣，比起甲骨文更早之前一定還有文字，只是考古出土和解讀的資料有限而已。至於楷書的標準化明顯跟此事沒有可類比性，這點就直接略過。其餘的政治類論述則是不在我這次的關注範圍內。--章安德魯（留言） 2021年3月30日 (二) 19:25 (UTC)[回覆]

在維基上想替原住民爭取特殊規則，他也只是論述而已，沒有提案或強制大家接受，這種論述他是出於善良的、有同理心的。就好像COVID-19的命名，有人認為部分人被歧視了，想要去禁止一些用詞。現在的提案情形是，原住民傳主的本名就算符合命名原則的原文標題，也一定要音譯成漢字，然後其他主題卻沒有限制。這樣的話針對性比較強，原住民傳主暫時也只看到Kolas本名能用拉丁字母命名而已，遠遠沒有其他藝名、動漫、各種物件主題的拉丁字泛濫的。--2001:B042:1:A95D:C809:62F5:44EC:18E5（留言） 2021年3月31日 (三) 03:40 (UTC)[回覆]

中文維基本來就已經允許很多情況下採用拉丁字母，所以就算MULTIPLENAMES不曾受到美洲原住民的挑戰，也還是可以在此作為參考。我要求的不是禁用漢字音譯，而是在當事人明確表達對拉丁字母的偏好時，採用此寫法。關於其他文字系統的部份，目前有Wikipedia:命名常規#羅馬化，所以不會有蒙古文、苗文、滿文、維文之類的問題。雖然這也有西方霸權的嫌疑，但該原則另外也考慮到所有華人國家都在義務教育中納入有英語或拼音的現實（也就是說拉丁字母對多數讀者來說是可識別的，其他文字不然），而且也顧及到一般人能否簡單輸入的技術考量。--C9mVio9JRy（留言） 2021年3月31日 (三) 05:30 (UTC)[回覆]

命名常規擬議修訂

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

原標題為：調整命名常規中「名從主人」及「先到先得」規則的強度

原案

以分案代替：

以分案分開處理具爭議性和不具爭議性的提議。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 07:58 (UTC)[回覆]

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

現擬修改命名常規，以調整其中「名從主人」及「先到先得」規則的強度如下：

現行條文

中文用詞差異的處理

由於不同的人的用詞習慣皆有不同，且上述原則和慣例間有機會存在矛盾，因此命名時常出現有衝突的情形。當條目描述的主題在中文圈有多個名稱時，應使用地區詞轉換使用詞根據用戶設定的轉換模式而變化，且應當在首段註明所有這些名稱（如果是單純異體字所產生的命名差異，則依異體字相關規定處理）。但是，條目的標題只能選取一個，因此有以下原則：

先到先得（時間優先）

捷徑

選擇條目第一個重要版本所採用並符合本方針的標題作為條目的主要命名方式，而其他命名方式都重新導向到這個主要標題上。當標題僅繁簡用字不同時，則無需建立重新導向，系統會自動處理。

但是，當有符合上述「名從主人」慣例的名稱時，有以下處理方式：

當一個事物的名稱符合「名從主人」的慣例，且在全部的中文使用地區皆為常用名稱時，應當使用該名稱。
當一個事物的名稱符合「名從主人」的慣例，但只在某一個或多個中文使用地區為常用，而在其它的中文使用地區並不常用時，仍應當使用符合「名從主人」命名原則確立的名稱，而不應當繼續使用「時間優先」命名原則確立的首個常用名稱。
當一個事物的名稱符合「名從主人」的慣例，但在全部的中文使用地區皆不常用時，應當繼續使用「時間優先」命名原則確立的首個常用名稱，而不應當使用符合「名從主人」命名原則的名稱。
當一個事物的名稱不符合「名從主人」的慣例時，可以用其它命名規則代替。

提議條文

中文用詞差異的處理：先到先得（時間優先）

捷徑

由於不同的人的用詞習慣皆有不同，且上述原則和慣例間有機會存在矛盾，因此命名時常出現有衝突的情形。當條目描述的主題在中文圈有多個名稱時，應使用地區詞轉換使用詞根據用戶設定的轉換模式而變化，且應當在首段註明所有這些名稱（如果是單純異體字所產生的命名差異，則依異體字相關規定處理）。

然而，由於條目的標題只能選取一個，因此應選擇條目第一個重要版本所採用，並符合本方針其他命名原則的標題作為條目的主要命名方式，而其他命名方式都重新導向到這個主要標題上。當標題僅繁簡用字不同時，在未有建立簡繁／繁簡重新導向的情形下，系統可自動處理並跳轉頁面，而在已建立簡繁／繁簡重新導向的情形下，則以重新導向的方式跳轉頁面。

「名從主人」及「先到先得」規則的適用優先性

捷徑

在一個事物存在符合「名從主人」命名慣例的名稱（下稱「該名稱」）時，應按以下辦法處理：

如該名稱在全部的中文使用地區皆為常用名稱，在同時符合其他命名原則的前提下，條目應當移動至該名稱。
如該名稱只在某一個或多個中文使用地區為常用名稱，而在其它的中文使用地區並不常用：
- 條目應當以地區詞轉換的方式使其在該一個或多個中文使用地區顯示該名稱，而在其它的中文使用地區維持顯示其常用名稱。
- 如條目原本使用的名稱為該一個或多個中文使用地區的原地區詞，並在所有的該一個或多個中文使用地區被該名稱完全取代，則在同時符合其他命名原則的前提下，應當移動至該名稱。否則，條目應當繼續使用「時間優先」命名原則確立的首個常用名稱。
如該名稱在全部的中文使用地區皆不常用，則應當繼續維持使用「時間優先」命名原則確立的首個常用名稱。

以上。此修訂意在減少因「名從主人」而產生的頁面移動，並盡可能改以設定地區詞轉換代替，以更大程度上尊重初始條目標題所選定的地區詞的「先到先得」權利，並避免違反地區詞破壞方針。SAN MO SA _{江南好，風景舊曾諳} 2021年3月22日 (一) 11:48 (UTC)[回覆]

@Sanmosa：「當標題僅繁簡用字不同時，則無需建立重新導向，系統會自動處理」這句話應該去掉，會有人重複建立條目，二疊紀簡體標題[12]就是一個例子。--Googol19980904（留言） 2021年3月23日 (二) 15:08 (UTC)[回覆]

@Googol19980904：我的理解是「無需」非「禁止」，而且有時候有技術需求。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 00:47 (UTC)[回覆]

(－)反對，目前新的提議其實是強化了大陸與香港的整體對等性，即14億人使用的定義與0.06億人（或者加上台灣0.2億人）的使用一旦衝突，那麼會導致0.26億人的小眾說法可以超過了14億的大眾說法。我建議按照使用地區的人口作為主要的參考因素。Walter Grassroot（留言） 2021年3月24日 (三) 01:46 (UTC)[回覆]

會產生地域歧視問題，另一方面也無視了馬來西亞和新加坡方面的用詞。此意見相等於完全否定現行的字詞轉換系統，並對中國大陸以外的用戶進行整體性的地域歧視，恕我無法接納為正當合理的意見。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 02:11 (UTC)[回覆]

容許我舉一個例子：「FOX」在中國大陸翻譯為「福克斯」，在臺灣和新加坡翻譯為「福斯」，在香港翻譯為「霍士」。假設條目的初始用名用到「福斯」，根據Walter Grassroot上方的理論，條目會毋庸置疑地需要移動至「福克斯」，我認為這屬於對所有臺灣和新加坡用戶的不尊重和地域歧視（香港反而沒甚麼關係，反正都是轉換才出得來「霍士」）。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 02:30 (UTC)[回覆]

另一方面，考量到現行地區詞破壞方針，我認為Walter Grassroot的提議直接違反現行方針，而相關方針可廢除的概率極小，就可行性而言亦不大。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 02:33 (UTC)[回覆]

有關「建議按照使用地區的人口作為主要的參考因素」，有明顯地域歧視問題，恕我反對。--Wolfch (留言) 2021年3月24日 (三) 02:25 (UTC)[回覆]

@Wolfch：就此事，我已提報至WP:ANM。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 02:30 (UTC)[回覆]

這裏只是在一個叫維基百科的網站上說條目名稱的異同。但，顯然沃爾特草根是在說「你港台因為是中國的一部分所以不能在其他部分蓋過中國」。然而要注意的是這裏不是在決定中國領土法理的問題。維基百科不可能決定這種問題，任何維基百科上的人也沒法有這種能力。--𢿃𠫱（留言） 2021年3月24日 (三) 02:32 (UTC)[回覆]

@松照庵：他最大的問題是他還想凌駕馬來西亞和新加坡的用詞，馬來西亞和新加坡很明顯不是任何定義上的中國的一部分。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 02:35 (UTC)[回覆]

原則上支持，但反對「當標題僅繁簡用字不同時，則無需建立重新導向，系統會自動處理。」一句，簡繁重新導向已經是月經提案。另外抗議Walter Grassroot之地域歧視言論-某人 ✉ 2021年3月24日 (三) 02:45 (UTC)[回覆]
@AINH：我的理解是「無需」非「禁止」，此條並不阻止建立簡繁重新導向。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 02:48 (UTC)[回覆]

先後兩版條文都不好讀。(試圖)簡而言之，提議的條文是如果名從主人的名稱完全變更完成才更名，否則就時間優先？感覺這在變更於某些地區未落定時也會引致爭議。--YF dyh000（留言） 2021年3月24日 (三) 03:03 (UTC)[回覆]

@YFdyh000：（1）有沒有改善語句的提議？（2）「簡而言之」部分的理解正確（可能可以加一個{{nutshell}}）。（3）移動本來就不應該輕率進行。如果會引發爭議的話，根據現在的做法是走討論程序，討論期間應該不能進行移動戰（不然就請管理員實施移動保護）。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 03:09 (UTC)[回覆]

考量@Googol19980904、AINH的意見後，於2021年3月24日 (三) 03:09 (UTC)對提案進行輕微的字眼調整，不影響條文大意。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 03:09 (UTC)[回覆]

Ping錯，應是@Googol19980904。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 03:10 (UTC)[回覆]

現版本可以接受，不然「無需」兩個字就會讓一些人質疑重建繁簡重新導向的行為。--Googol19980904（留言） 2021年3月24日 (三) 03:21 (UTC)[回覆]

+1 某人 ✉ 2021年3月24日 (三) 03:25 (UTC)[回覆]

(－)反對，原本的名從主人條文沒有實質問題，條文修改提案沒有明顯的好處，地區詞「先到先得」也不是值得尊重的做法，只是沒有命名共識時的權宜之計，屬於最終應當解決的問題，試圖用先到先得凌駕於名從主人根本沒有道理。退一萬步講，大陸14億人使用的定義如果和香港0.06億人的稱呼非要同等對待，這等價於在維基百科，一個香港人代表的「民意」等同於大陸233個人代表的「民意」，這顯然才是明目張胆的地域歧視。我在此(！)強烈抗議提案人在本頁面和ANM頁面進行的地域歧視言論，並呼籲管理員正視並進行妥善處理。--

${#(set-global-staff-size 12) a'4 d''8 e''8 a'4 g'4 a'4 g'8 e'8 a'2 \bar "|."}$

2021年3月24日 (三) 06:27 (UTC)

@Wolfch、AINH。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 06:46 (UTC)[回覆]

(－)反對：出於對百科全書嚴謹性的考量，我認為適合使用WP:名從主人的主體事物應使用官方中文名稱。--DavidHuai1999※Talk 2021年3月24日 (三) 06:40 (UTC)[回覆]
@DavidHuai1999：你是我認為第一個發表了合理反對意見的人。就你的意見，我以以下多點回應：（1）現行名從主人的規定似乎難以迴避地區詞破壞方針的影響，如果要某程度上維持的話，可能需要為地區詞破壞方針設定例外條款，這點我開放討論。（2）國名是否適用名從主人的規定這點我深感懷疑，例如消歧義括號內標註的國名，應該不適用名從主人的規定（即不強制將所有「南韓」改為「韓國」，不強制將所有「北韓」改為「朝鮮」，也不強制將所有「斯威士蘭」改為「史瓦帝尼」），否則我認為有矯枉過正之嫌。因此如果現行名從主人的大體規定確實不宜在實際意義上有所更動，我認為可行的替代做法是單獨將國名（國家本身的條目除外）剔除適用名從主人的規定。（3）現行名從主人的規定是「它的擁有者或代表者的官方中文資料裏有出現到該事物的中文名稱的」，然而有時候不同官方中文資料間，甚至同一官方中文資料內自己也會打架（出現一名多譯的情形）。這是老問題，和是次修訂的關係其實不那麼大，但是這裏也給一個方向討論可以如何完善名從主人的規定。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 07:11 (UTC)[回覆]

我認為我上面的留言有回應到遊魂的留言的上半部分（遊魂的留言的上半部分也是可以的），故副知@游魂。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 07:21 (UTC)[回覆]
@Sanmosa：不行的話先把方針裏面繁簡重新導向那裏改了，這一點目前還沒人有反對意見。--Googol19980904（留言） 2021年3月24日 (三) 07:50 (UTC)[回覆]
@Googol19980904：完成。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 07:58 (UTC)[回覆]

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

分案1

由分案1A取代：

由分案1A取代。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 13:43 (UTC)[回覆]

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

收到意見要求分開處理較不具爭議性的部分，故進行分案，以下為分案1。分案1僅調整繁簡重新導向和「名從主人」及「先到先得」規則的適用優先性相關文句的表述，以使條文更為清晰，而不會更動「名從主人」及「先到先得」規則的強度。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 07:58 (UTC)[回覆]

現行條文

中文用詞差異的處理

由於不同的人的用詞習慣皆有不同，且上述原則和慣例間有機會存在矛盾，因此命名時常出現有衝突的情形。當條目描述的主題在中文圈有多個名稱時，應使用地區詞轉換使用詞根據用戶設定的轉換模式而變化，且應當在首段註明所有這些名稱（如果是單純異體字所產生的命名差異，則依異體字相關規定處理）。但是，條目的標題只能選取一個，因此有以下原則：

先到先得（時間優先）

捷徑

選擇條目第一個重要版本所採用並符合本方針的標題作為條目的主要命名方式，而其他命名方式都重新導向到這個主要標題上。當標題僅繁簡用字不同時，則無需建立重新導向，系統會自動處理。

但是，當有符合上述「名從主人」慣例的名稱時，有以下處理方式：

當一個事物的名稱符合「名從主人」的慣例，且在全部的中文使用地區皆為常用名稱時，應當使用該名稱。
當一個事物的名稱符合「名從主人」的慣例，但只在某一個或多個中文使用地區為常用，而在其它的中文使用地區並不常用時，仍應當使用符合「名從主人」命名原則確立的名稱，而不應當繼續使用「時間優先」命名原則確立的首個常用名稱。
當一個事物的名稱符合「名從主人」的慣例，但在全部的中文使用地區皆不常用時，應當繼續使用「時間優先」命名原則確立的首個常用名稱，而不應當使用符合「名從主人」命名原則的名稱。
當一個事物的名稱不符合「名從主人」的慣例時，可以用其它命名規則代替。

提議條文

中文用詞差異的處理：先到先得（時間優先）

捷徑

由於不同的人的用詞習慣皆有不同，且上述原則和慣例間有機會存在矛盾，因此命名時常出現有衝突的情形。當條目描述的主題在中文圈有多個名稱時，應使用地區詞轉換使用詞根據用戶設定的轉換模式而變化，且應當在首段註明所有這些名稱（如果是單純異體字所產生的命名差異，則依異體字相關規定處理）。

然而，由於條目的標題只能選取一個，因此應選擇條目第一個重要版本所採用（並符合本方針其他命名原則）的標題作為條目的主要命名方式，而其他命名方式都重新導向到這個主要標題上。當標題僅繁簡用字不同時，在未有建立簡繁／繁簡重新導向的情形下，系統可自動處理並跳轉頁面，而在已建立簡繁／繁簡重新導向的情形下，則以重新導向的方式跳轉頁面。

「名從主人」及「先到先得」規則的適用優先性

捷徑

在一個事物存在符合「名從主人」命名慣例的名稱（下稱「該名稱」）時，應按以下辦法處理：

如該名稱在全部的中文使用地區皆常用，在同時符合其他命名原則的前提下，條目應當使用該名稱。
如該名稱只在某一個或多個中文使用地區常用，而在其它的中文使用地區並不常用：
- 條目應當以地區詞轉換的方式使其在該名稱常用的地區模式下顯示該名稱，而在該名稱不常用的地區的模式下維持顯示相關地區的常用名稱。
- 在同時符合其他命名原則的前提下，條目應當使用該名稱。
如該名稱在全部的中文使用地區皆不常用，則應當繼續維持使用「先到先得」規則確立的首個常用名稱。

以上。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 07:58 (UTC)[回覆]

通知所有參與討論者：@Googol19980904、Walter Grassroot、Wolfch、松照庵、@AINH、YFdyh000、游魂、DavidHuai1999。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 08:09 (UTC)[回覆]

(－)反對：換湯不換藥，優先性2還是在弱化名從主人，不知道這怎麼叫較不具爭議性。我質疑提案人的誠信程度。--

${#(set-global-staff-size 12) a'4 d''8 e''8 a'4 g'4 a'4 g'8 e'8 a'2 \bar "|."}$

2021年3月25日 (四) 05:23 (UTC)

@游魂：請指出如何「弱化」，我自己是真的看不出來，但我很願意參照意見再調整語句。不過請留意現行方針有「命名原則優先於主要命名慣例」的規定，因此如果你說的是「在同時符合其他命名原則的前提下」那一句的話，我只是在重複上方的規定，那是方針本來就有的東西，那一句話根本不會影響「名從主人」規則的強度；如果硬要說是影響了的話，那就是加入「命名原則優先於主要命名慣例」的規定當時已經被影響了。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 05:38 (UTC)[回覆]

如果3日之內沒回應的話，我會假定他接受我的解釋。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 09:16 (UTC)[回覆]

如果我是真的有心瞞騙大家的話，我也沒必要把所有參與討論的人都ping過來，我亦不是做這種無聊的事的人。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 05:50 (UTC)[回覆]

我調整了一處標點。(＋)支持章節的調整，但(－)反對提議條文中改動的內容。新增的「繁簡重新導向」部分僅僅是對事實的描述，而原先的條文立意為阻止建立無意義的繁簡重新導向。另外，原文的「應當使用該名稱」更加準確，假如原先的名稱本來就是對的，為何「應當移動至該名稱」？--Lt2818（留言） 2021年3月25日 (四) 07:15 (UTC)[回覆]

@Lt2818：（1）「阻止建立無意義的繁簡重新導向」此點先前受社羣反對（這裏容許我請@Cdip150過來），而且實際上本站也完全無力阻止。（2）「應當使用該名稱」的部分是我沒留意，已調整。（3）不反對你進行的標點調整。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 07:38 (UTC)[回覆]

原文也沒有硬性阻止，我覺得「無需建立」的表述很合適。--Lt2818（留言） 2021年3月25日 (四) 07:47 (UTC)[回覆]

上方@Googol19980904、AINH等用戶認為原條文會產生誤解，而且原條文可能會阻撓因技術需求而建立的重新導向。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 07:51 (UTC)[回覆]

@Lt2818：沒有達到無需建立的地步，我前面也說了，會有重建條目的問題。Sanmosa修改後的條文明顯更好。--Googol19980904（留言） 2021年3月25日 (四) 08:13 (UTC)[回覆]

應當通過技術手段阻止這樣的情況出現。方針不是用來寫現狀的，而是給編者提供行為指導。--Lt2818（留言） 2021年3月25日 (四) 08:36 (UTC)[回覆]

@Lt2818：容易誤中副車。有時候跳轉不到的話，仍然需要建立重新導向。另外，有時繁簡未必完全對應（例如「綜合症」和「综合征」）。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 08:41 (UTC)[回覆]

@Lt2818：也請你評論一下我這個提案究竟有沒有「『弱化』名從主人」，我自己是真的看不出來。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 07:51 (UTC)[回覆]

這一段不管新舊條文都難以讀懂，需要更加清晰的表述。--Lt2818（留言） 2021年3月25日 (四) 08:13 (UTC)[回覆]

@Lt2818：嘗試改寫了一下。或許我舉一個例子：「FOX」在中國大陸翻譯為「福克斯」，在臺灣和新加坡翻譯為「福斯」，在香港翻譯為「霍士」，該公司的官方譯名同臺灣和新加坡翻譯。在這種情況下，條目的名稱應該是「福斯」，但在中國大陸和香港模式下應該分別顯示「福克斯」和「霍士」。這也是中文維基百科的現狀。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 08:30 (UTC)[回覆]

方針中上文已經提過地區詞轉換，這裏重複提及就有點奇怪。提議條文中「常用名稱」和「該名稱」也混雜不清。我建議在原方針條文基礎上去除冗餘文字即可。--Lt2818（留言） 2021年3月25日 (四) 08:45 (UTC)[回覆]

2019年加入「命名原則優先於主要命名慣例」和「條目命名的地區詞轉換亦按以上方法處理（按地區詞所屬地域，如適用）」的規定的原因就是因為當時有用戶誤以為命名常規中應用名從主人的名稱不能使用地區詞轉換，因此我認為有重複提及的必要。「常用名稱」和「該名稱」是有分別的：前者是《命名常規》「使用常用名稱」章節中所指的常用名稱（提議條文有給章節連結），後者是符合「名從主人」命名慣例的名稱（提議條文有明確說明後者）。我再額外調整一下。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 09:06 (UTC)[回覆]

@Lt2818：所以我的提案沒有「『弱化』名從主人」？SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 09:09 (UTC)[回覆]

@Sanmosa：沒有，現在我重新看了一下，含義與原來等同，不仔細看確實難以理解。不用理會上面針對個人的評價質問，我知道並非如此。--Lt2818（留言） 2021年3月25日 (四) 11:18 (UTC)[回覆]

感謝你的意見。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 11:53 (UTC)[回覆]

我就問兩個很簡單的例子「新疆職業培訓中心」應該叫什麼？「新冠肺炎」應該叫什麼？--MINQI（留言） 2021年3月25日 (四) 09:49 (UTC)[回覆]

@MINQI：在原本的規定下應該叫甚麼，在新規定下完全一樣，因為此修訂不會更動「名從主人」及「先到先得」規則的強度（我也不預期會動到強度）。如果就後者特別而言，由於WP:CONCOVID-19的額外限制，條目名稱會是「2019冠狀病毒病」。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 10:03 (UTC)[回覆]

我也補充一下就前者特別而言好了：「職業技能教育培訓中心」在中國大陸的常用名稱是「教培中心」／「轉化所」（限新疆）【WP:COMMONNAME：「一般情況下，常用的名稱也是較為簡短的，可以避免條目名稱過於冗長」】，在中國大陸以外的常用名稱是「新疆再教育營」。由於此修訂不會更動「名從主人」及「先到先得」規則的強度，根據原有規則，「當一個事物的名稱符合『名從主人』的慣例，但在全部的中文使用地區皆不常用時，應當繼續使用『時間優先』命名原則確立的首個常用名稱，而不應當使用符合『名從主人』命名原則的名稱」，條目應當繼續維持現狀，使用「時間優先」命名原則確立的首個常用名稱。條目本身現在也已經配置了地區詞轉換，所以即使適用了新規則，也不會對該條目的現狀有任何變更。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 10:09 (UTC)[回覆]

（就前者特別而言）如果你認為現狀並不符合現時的命名常規，那現狀也自然不符合新的命名常規。在這種情況下，我建議你提出移動請求，看看社群的想法，但注意相關機構的官方正式名稱是「職業技能教育培訓中心」。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 10:52 (UTC)[回覆]

如果你喜歡的話，你還可以多問幾個例子，反正在原本的規定下應該叫甚麼，在新規定下完全一樣，我要回答的話也很容易。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 10:17 (UTC)[回覆]

好的，那我說明下吧。1.「新疆職業技能教育培訓中心」，在大陸常用簡稱「教培中心」，大陸以外常用名稱是「新疆再教育營」，然而閣下想必也知道另一個常用稱謂「集中營」。現在就有一個衝突：「新疆再教育營」這稱謂是如何得來的？如果是從英語或其他非中文媒體而來，那麼這個事物名稱就變中文-》外文譯者理解—》中文譯者再理解，這其中會有偏差，這是一個例子；蛇果是另一個，它就是蘋果，只不過商人噱頭稱為蛇果（伊甸園蛇給亞當和夏娃的就是蘋果）。2.由於WP:CONCOVID-19的額外限制所以稱為「2019冠狀病毒病」，然而之前該條目因為台灣常用「武漢肺炎」所以條目叫這個過吧。現在台灣媒體及香港部分媒體也在使用「武漢肺炎」吧？那麼如果沒有WP:CONCOVID-19是不是條目就叫「武漢肺炎病毒」？是這樣的話，是不是不太合理？3.自行反坦克炮，大陸其實稱之為「坦克殲擊車」（Tank destroyer，英語Tank destroyer中文直譯，也更常用），台灣稱之為「驅逐戰車」，來自日語對英語Tank destroyer的翻譯。很明顯這樣的再次翻譯有了第一點中的偏差，同樣也使不同閱讀者一頭霧水。個人意見是儘量名從主人，因為創造這個事物的人必定有發言權，而常用名應作為補充即轉換等操作，常用新名的首個稱呼者或原名翻譯者的理解、見解有些是有益的就像不同菜在不同地區會有改良以適合當地人口味，但要把菜名改了作為這菜的條目（官方）名有些不妥。--MINQI（留言） 2021年3月25日 (四) 14:33 (UTC)[回覆]

@MINQI：（0）先說明：分案1沒打算「『弱化』名從主人」，Lt2818在上面也是認同的（但我現時會推薦Lt2818下方的提案）。（1）但你無法否定其常用名稱的地位。如果刻意消除，會引起社羣強烈反彈，之前就「朝鮮」和「北韓」這事情上已吵過一遍，我認為沒必要再就其他名稱重複本質相同的爭論。因此，相關的偏差程度應在容許範圍內。或許這樣說：在事物本身的條目走「名從主人」規則可以理解，但僅消歧義括號內的名稱（非條目主體）還走「名從主人」規則則屬矯枉過正（當然，如果那個符合「名從主人」的慣例的名稱在全部的中文使用地區皆為常用名稱的話，走「名從主人」規則自然不是矯枉過正），就後者我會另提規則處理，不知意見如何。（2）雖然說由於WP:CONCOVID-19的額外限制，條目名稱會是「2019冠狀病毒病」，但移動至「2019冠狀病毒病」名稱的操作是2020年2月的事（我好像還主導過移動一下），那時候WP:CONCOVID-19根本未出現。常用名稱往往不只一個（就像「職業技能教育培訓中心」在中國大陸的常用名稱已經有兩個一樣），而2019冠狀病毒病條目的初始名稱已是「2019-nCoV急性呼吸道疾病」（武漢肺炎當時是另一個頁面），移動至「2019冠狀病毒病」是出於常用名稱變更的情形而為的（我個人並不否定「2019冠狀病毒病」為常用名稱），並不需要依靠「名從主人」規則。（3）「Tank destroyer」本來就沒有符合「名從主人」規則的名稱，因為它根本沒有「主人」，因此這個例子舉得不太恰當。另一方面，同（1），如果刻意消除個別的常用名稱，會引起社羣強烈反彈，因此僅消歧義括號內的名稱（非條目主體）不應走「名從主人」規則（除非其他規則支持）。我就你的意見調整了Module:CGroup/Military的內容。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 01:29 (UTC)[回覆]

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

分案1A：簡化行文

原方針及上述提案行文太過複雜，我自己讀了半天才讀懂。現合併Sanmosa君提案中我能接受的部分，簡化方針行文，詳列差異如下，供大家討論。該方案之文意與原先無差別。

現行條文

主要命名慣例除上述命名原則之外，尚有以下命名慣例，一般情況下應遵守這些慣例：

使用全稱 ……

名從主人 ……

中文用詞差異的處理

由於不同的人的用詞習慣皆有不同，且上述原則和慣例間有機會存在矛盾，因此命名時常出現有衝突的情形。當條目描述的主題在中文圈有多個名稱時，應使用地區詞轉換使用詞根據用戶設定的轉換模式而變化，且應當在首段註明所有這些名稱（如果是單純異體字所產生的命名差異，則依異體字相關規定處理）。但是，條目的標題只能選取一個，因此有以下原則：

先到先得（時間優先）

捷徑

選擇條目第一個重要版本所採用並符合本方針的標題作為條目的主要命名方式，而其他命名方式都重新導向到這個主要標題上。當標題僅繁簡用字不同時，則無需建立重新導向，系統會自動處理。

但是，當有符合上述「名從主人」慣例的名稱時，有以下處理方式：

當一個事物的名稱符合「名從主人」的慣例，且在全部的中文使用地區皆為常用名稱時，應當使用該名稱。
當一個事物的名稱符合「名從主人」的慣例，但只在某一個或多個中文使用地區為常用，而在其它的中文使用地區並不常用時，仍應當使用符合「名從主人」命名原則確立的名稱，而不應當繼續使用「時間優先」命名原則確立的首個常用名稱。
當一個事物的名稱符合「名從主人」的慣例，但在全部的中文使用地區皆不常用時，應當繼續使用「時間優先」命名原則確立的首個常用名稱，而不應當使用符合「名從主人」命名原則的名稱。
當一個事物的名稱不符合「名從主人」的慣例時，可以用其它命名規則代替。

提議條文

主要命名慣例除上述命名原則之外，尚有以下命名慣例，一般情況下應遵守這些慣例：

使用全稱 ……

名從主人 ……

中文用詞差異的處理：先到先得

捷徑

各地區的用詞習慣不盡相同，命名時常出現有衝突的情形。當條目描述的主題在中文圈有多個名稱時，應使用地區詞轉換根據用戶設定的轉換模式而變化，且應當在首段註明所有這些名稱（如果是單純異體字所產生的命名差異，則依異體字相關規定處理）。

然而條目的標題只能選取一個，因此應維持條目第一個重要版本所採用的標題（須符合本方針其他命名規則），而其他命名方式都重新導向到這個標題上。

但是，若存在符合「名從主人」慣例的名稱，且其在至少一處中文使用地區為常用名稱時，上述「先到先得」的規則不適用，此時條目標題應當使用符合「名從主人」慣例的名稱。

--Lt2818（留言） 2021年3月25日 (四) 12:52 (UTC)[回覆]

可接受（我自己的分案1其實是為了日後的修改空間，但我現在一想，現在好像也不用預留），但容許我稍為微調一下。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 13:00 (UTC)[回覆]

補充：原文的「無需繁簡重新導向」本來也只是附加說明，我閱讀了上面的討論後，同樣刪除了這一句。--Lt2818（留言） 2021年3月25日 (四) 17:31 (UTC)[回覆]

容許我再代調整兩處。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 01:31 (UTC)[回覆]

我覺得沒必要加NFM/FCFS這樣的快捷方式。這裏只是簡單說明先到先得規則不適用的情況，今後也可能添加與「名從主人」無關的條件。--Lt2818（留言） 2021年3月26日 (五) 02:05 (UTC)[回覆]

@Lt2818：但重新導向頁面就已經一早預先建立了，現在的情況很尷尬……移除也可。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 02:08 (UTC)[回覆]

事後提刪不妨。提議條文的三段話其實能夠任意調整順序，把適用「名從主人」的情況提前說也是可以的，這樣的話此類快捷方式就不合適。--Lt2818（留言） 2021年3月26日 (五) 02:17 (UTC)[回覆]

我看看有沒有其他地方需要捷徑，然後再改一改名和用途就好了。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 02:24 (UTC)[回覆]

目前的新方案，我覺得可行。--MINQI（留言） 2021年3月30日 (二) 12:33 (UTC)[回覆]

（重提）現行日期和數字格式手冊條文調適

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:格式手冊/日期和數字。

承前討論，現重提擬對WP:格式手冊/日期和數字修改如下：

現行條文

數字（略）

物理量量值的書寫物理量量值必須使用阿拉伯數字，並正確使用法定計量單位。例如：一百五十平方米應寫作150平方米或150 m²。

（略）

一般量詞前的數值一般量詞前面的數字應該使用阿拉伯數字，不應使用漢字表示：

正確：11個月、50歲、200人、1000名
錯誤：十一個月、五十歲、兩百人、一千名

（略）

金錢單位前的數字非物理量值的單位應該使用阿拉伯數字。例如：20元、10.1萬元、300美元、290億英鎊等。

整數一至十的書寫一至十的整數如果不是出現在具有統計意義的一組數字中，則漢字、阿拉伯數字都可使用，但應保持上下文局部體例一致，例如：一個人、三本書、讀了十遍、5個百分點。

正確：這個地區的高等學校有新聞系6個、新聞專業科系7個
錯誤：這個地區的高等學校有新聞系6個、新聞專業科系七個

多位數字的分節對於多位數字的，應該適當分節，以助於讀者理解。分節時可使用撇節法劃分。

三位撇節法對於小數點前或後超過四位的數，從小數點起，向左和向右每三位數字一組，組間空四分之一個漢字（二分之一個阿拉伯數字）的位置，或以「,」（半角逗號）按千分節，例如：123,456.0789。純小數通常不省略個位數的「0」，例如：「0.46」而非「.46」。

中文的四位撇節法運用「萬」、「億」兩個單位，與阿拉伯數字混用時也可輕易理解，例如：11,3368,2501，意為「11億3368萬2501」；3,4500,0000，意為「三億四千五百萬」，也可寫成「3.45億」、「3,4500萬」，但一般不寫作「3億4千5百萬」。

提議條文

數字整數一至一百的書寫一至一百的整數如果不是出現在具有統計意義的一組數字中，則漢字、阿拉伯數字都可使用，例如：三個人、四十歲、讀了50遍、75個百分點。

正確：這個地區的高等學校有新聞系6個、新聞專業科系7個
錯誤：這個地區的高等學校有新聞系6個、新聞專業科系七個

為保持上下文局部體例一致，若兩組或多組數據並列，則必須統一格式。若其中至少一組數據被本指引禁止使用某種格式，則其他與之並列者亦不可使用。

（略）

物理量量值的書寫物理量量值必須使用阿拉伯數字，並正確使用法定計量單位，惟在無關科學的條目中，符合「整數一至一百的書寫」的規定者例外。例如：一百五十平方米應寫作150平方米或150 m²。「萬X」、「億X」等10⁴的倍數級的中文數字量值當成單位的一部分。

（略）

一般量詞前的數值一般量詞前面的數字應該使用阿拉伯數字，不應使用漢字表示，惟符合「整數一至一百的書寫」的規定者例外：

正確：200人、1000名、5000年
錯誤：兩百人、一千名、五千年

「萬X」、「億X」等10⁴的倍數級的中文數字量值當成單位的一部分。

（略）

金錢單位前的數字非物理量值的單位應該使用阿拉伯數字，惟符合「整數一至一百的書寫」的規定者例外。例如：20元、10.1萬元、300美元、290億英鎊等。「萬X」、「億X」等10⁴的倍數級的中文數字量值當成單位的一部分。

多位數字的分節對於多位數字的，應該適當分節，以助於讀者理解。分節時可使用撇節法劃分。

三位撇節法對於小數點前或後超過四位的數，從小數點起，向左和向右每三位數字一組，組間空四分之一個漢字（二分之一個阿拉伯數字）的位置，或以「,」（半角逗號）按千分節，例如：123,456.0789。純小數通常不省略個位數的「0」，例如：「0.46」而非「.46」。

中文的四位撇節法運用「萬」、「億」兩個單位，與阿拉伯數字混用時也可輕易理解，例如：11,3368,2501，意為「11億3368萬2501」；3,4500,0000，意為「三億四千五百萬」，也可寫成「3.45億」、「3億4500萬」，但一般不寫作「3億4千5百萬」。四位撇節法不在科學相關條目中使用。

只有四位或五位的阿拉伯數字可不進行分節。

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

(！)意見：建議將「一般量詞前面的數字應該使用阿拉伯數字，不應使用漢字表示」改為「一般量詞前面的數字，原則上零到九以中文書寫，大於九的數字用阿拉伯數字書寫」（但不把話說死，允許個別情況例外）。
- 提倡：三年零六個月、50歲、200人、1000名
- 不提倡：3年06個月、五十歲、兩百人、一千名、
(！)意見：三位撇節法不符合中文語法，不應以任何形式推廣。10000中文讀作「一萬」而非「十千」；10000000中文讀作「一千萬」而非「十百萬」。
(？)疑問：為什麼「四位撇節法不在科學相關條目中使用」？中文是使用四位撇節法的語言，在科學條目中使用的數字也不例外。例如光的速度為每秒299792458米，寫成「2,9979,2458米」我不覺得有什麼問題，反而更方便讀者閱讀理解。📕📙📒📗📘📚📖 2021年3月22日 (一) 16:03 (UTC)[回覆]

@PÑēüḾôňïę1357：（1）之前社群的傾向是放寬到1至100也可以用中文數字。（2）三位撇節法是國際標準的數字表達方式，基本上我看到的所有政府公文和科學文獻都使用三位撇節法。（3）我看不到有任何國際上的科學文獻使用四位撇節法，而且即使使用三位撇節法也不會妨礙讀者理解。SAN MO SA _{江南好，風景舊曾諳} 2021年3月22日 (一) 23:51 (UTC)[回覆]

「放寬到1至100也可以用中文數字」我(＋)傾向支持。
~~不如改為「科學相關條目中的數字，原則上不進行撇節」，~~同時也不禁止「2億9979萬2458」這樣的寫法（尤其是在沒有小數位的時候），以方便不熟悉三位撇節法的讀者。如何？📕📙📒📗📘📚📖 2021年3月23日 (二) 02:32 (UTC)[回覆]

@PÑēüḾôňïę1357：（2a）部分數字數值較大，理當進行撇節。國際科學文獻都使用三位撇節法。（2b）我不預期有讀者不熟悉三位撇節法（我反而認為有大量讀者不熟悉以「,」分隔的四位撇節法），而且三位撇節法本身並不影響數字的意義，因此即使真的有讀者不熟悉三位撇節法（雖然我認為不可能），這不會對他們理解數字本身構成障礙。另一方面，同上，國際科學文獻都使用三位撇節法，我認為有必要顧慮維基百科作為百科全書的百科性和專業性。SAN MO SA _{江南好，風景舊曾諳} 2021年3月23日 (二) 05:16 (UTC)[回覆]

我本人是幹翻譯的，基本上每次翻譯數字時都要自己重新進行撇節，以免誤譯。正因如此，我才主張能不用就不用三位撇節法，同時主張不禁止「2億9979萬2458」這樣的寫法。不過「原則上不進行撇節」這部份我可以撤回。

另外，請恕我不明白為什麼不用三位撇節法就不能體現維基百科的「百科性和專業性」。沒錯，絕大部份國際科學文獻都用三位撇節法，但那是因為印歐語系（拉丁語族和日耳曼語族）的語言都用三位撇節法。敝認為「百科性和專業性」首先應該體現在「不容易引起歧異」上，而要避免引起歧異，就應該在不影響原意的前提下，對某些表述進行調整，使其更適應中文，更容易被讀者消化。而我認為對於中文讀者而言，同一個數字，「2億9979萬2458」比「299,792,458」就好比熟肉和生肉，雖然都是肉，但前者比後者更容易消化。

不過歸根究底還得看其他人怎麼投票。📕📙📒📗📘📚📖 2021年3月23日 (二) 05:54 (UTC)[回覆]

我自己看過的科學書籍（還有政府文告），無論是甚麽語言寫的，都是用三位撇節法，如果看到「2億9979萬2458」的話我反倒要質疑這怪胎書籍的可靠性。我自己是不認為三位撇節法會造成任何「歧義」，所以也完全不存在某一種特定的撇節法「更容易被讀者消化」的事情（如果不是的話，那恐怕是四位撇節法才會造成那種「歧義」，我生活中是沒怎麽看過書面上漢字四位撇節法的使用）。SAN MO SA _{江南好，風景舊曾諳} 2021年3月23日 (二) 07:01 (UTC)[回覆]

@LuciferianThomas、Yangwenbo99、Cwek、Lopullinen。SAN MO SA _{江南好，風景舊曾諳} 2021年3月22日 (一) 23:57 (UTC)[回覆]

為什麼我感覺應該是「科學相關條目中的數字，原則上進行撇節」，倒是日常生活相關條目可以考慮不分節……--洛普利寧 2021年3月23日 (二) 05:37 (UTC)[回覆]

(～)補充我反而覺得三位撇節法不適合中文語境吧，因為這是對應英文的數字分節（千、百萬、十億），而中文主要是四位分節（萬、億）。所以不建議保留三位分節，優先使用四位分節或者不分節。——Sakamotosan路過圍觀杯弓蛇影 | 避免做作，免敬 2021年3月23日 (二) 12:40 (UTC)[回覆]

@cwek：難道我是活在平行時空？我看到的數字即使在中文中也是三位撇節法。是地域差異嗎？SAN MO SA _{江南好，風景舊曾諳} 2021年3月23日 (二) 13:48 (UTC)[回覆]

雖然不符合中文語境，但除非是要求使用純中文的地方（比如數字都要求全形的那種），不然很少有超過2段的數字使用四位分節表示。在書面語上，中文單位+數字+四位分段好像是不怎麼常見，口語上倒是方便。--YF dyh000（留言） 2021年3月23日 (二) 22:04 (UTC)[回覆]

= =原來這世界上有四位撇節這神奇玩意啊……反對任何撤銷三位撇節地位的行徑。覺得三位撇節不好的人應該平常不是在幹跟數字有關的工作吧。－hiJK910 ^七一_七二一 2021年3月23日 (二) 12:56 (UTC)[回覆]

囧rz……莫非翻譯數字就不是「在幹跟數字有關的工作」嗎？📕📙📒📗📘📚📖 2021年3月23日 (二) 21:42 (UTC)[回覆]

@PÑēüḾôňïę1357：當然不是。至少是會計、統計、科研、工程、財務這些「完全」離不開數字，而且數目常以百萬起跳的行業。你覺得「翻譯數字」也是玩數字的工種，也證明你不是在幹跟數字有關的工作。－hiJK910 ^七一_七二一 2021年3月25日 (四) 16:26 (UTC)[回覆]

然而我在日常生活中是完全看不到四位撇節法在書面上的使用。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 00:50 (UTC)[回覆]

我是從來都沒有見過使用四位撇、四位空的做法。不知U:PÑēüḾôňïę1357閣下是否是在科技領域活動的譯者。在我見到的大多數科學文獻中，超過五位的數字，一律都要分節的，而如何分節，應當依照該領域的習慣。而無論如何，都沒有任何一個成文規則支持這個習慣。——Yangwenbo99^{論文} 2021年3月24日 (三) 09:54 (UTC)[回覆]

別的國家和地區不知道，大陸即便是教科書也沒有提倡用撇號分節，不提倡用12億3456萬7890的道理，也沒有準寫100、200不准寫一百、二百的道理。不過合作過的出版社凡是寫「進行」、「專業性」這種話的篇件都是當作者漢語還沒學好處理。--7（留言） 2021年3月24日 (三) 08:24 (UTC)[回覆]
空格分節又如何？香港的教科書無論中英文，數字一定會遵照三位撇節法，有時候是空格分開，有時候是半形撇號分開。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 08:52 (UTC)[回覆]

在下認為，不使用空格分節，純粹是因為技術問題，即維基百科無法保證（也不應保證）數字等寬，及空格與數字等寬。鄙人深切相信現時「數理化、醫學」這些領域「對漢語有害」的專業人士大都屬於閣下合作者所稱的「漢語還沒學好」。——Yangwenbo99^{論文} 2021年3月24日 (三) 09:54 (UTC)[回覆]
我的意思只是不同地方習慣不同，我不贊成強調（甚至提倡）任何一種。--7（留言） 2021年3月24日 (三) 10:31 (UTC)[回覆]
然而科學上確實只使用三位撇節法，因此有必要限制四位撇節法不在科學相關條目中使用。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 11:26 (UTC)[回覆]

大陸理科教材初中開始用千分空，小學教材沒有分隔符（我上小學時候課本上有說過三位分節法，現在可能刪了）。另外[13]；「1億2345萬6789」的寫法我見的最多的地方是日本新聞。反正物理上三位分節一眼就能換算單位，中文四位分級不好使。感覺這是學科領域問題，而不是地方習慣問題。PS：如果「123,456,789」一定要強調「億」，那我估計這裏重要的東西是數量級，而不是有效數字位數，所以我可能會直接寫「1.23億」。—洛普利寧 2021年3月25日 (四) 05:59 (UTC)[回覆]
現在並不是在講不能用三分或四分，現在是有人要規定只准用，大陸理科教材用千分空，有哪個老師膽敢把作文里寫漢字的打叉嗎？上面那位不用回復我了，你說的「科學上確實只使用」那是你，和我所見完全不在一個世界。--7（留言） 2021年3月26日 (五) 07:58 (UTC)[回覆]
你自己都懂得說是「作文」了，作文和百科全書是兩回事。而且限制範圍都限定成科學相關條目了。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 08:23 (UTC)[回覆]
(！)意見：建議各位在參與討論對「科學相關條目」的指引前，先確保自身有相關的專業背景。——Yangwenbo99^{論文} 2021年3月24日 (三) 09:54 (UTC)[回覆]

折衷提案

真想不到關於數字格式的討論也能引發這麼大的爭論。不如這樣：大家一人讓一步好不好？具體如下：

科學及專業條目：
1. 已經存在的三位撇節（本身）不改為其他表述方式。
2. 從今往後，小數點前只有五位或以下的阿拉伯數字不進行分節；十萬以上的阿拉伯數字，編者只能選擇「完全不分節」或「三位分節」。
3. 「完全不分節」或「三位分節」適用先到先得規則。
4. 鼓勵編者在小數點前超過五位的阿拉伯數字表述（分節或不分節）後面加註漢阿混合表述，以方便其他讀者。例如：「627147640391274（627萬1476億4039萬1274）」或「627,147,640,391,274（627萬1476億4039萬1274）」皆可接受。
5. 表示座標的數字，則無論如何也不進行分節，以免與座標表述本身混淆。
其他條目：
1. 已經存在的三位撇節（本身）不改為其他表述方式。
2. 從今往後，小數點前只有五位或以下的阿拉伯數字不進行分節；十萬以上的阿拉伯數字，編者~~只能選擇「完全不分節」或「三位分節」~~自行決定「完全不分節」、「三位分節」或「四位分節」。
3. ~~「完全不分節」或「三位分節」~~「完全不分節」、「三位分節」或「四位分節」適用先到先得規則。
4. 鼓勵編者在小數點前超過五位的阿拉伯數字表述（分節或不分節）後面加註漢阿混合表述，以方便其他讀者。由於是非專業條目，因此漢阿混合表述可以是約數。例如：「627147640391274（627.14萬億）」或「627,147,640,391,274（627.14萬億）」皆可接受。

諸位意下如何？📕📙📒📗📘📚📖 2021年3月26日 (五) 20:04 (UTC)[回覆]

(－)傾向反對。對於較長之數字（如閣下所舉出之627,147,640,391,274），學界是強烈地傾向於分節以減少閱讀困難。「先到先得」僅應當適用做與不做都有相當理由的情形，例如對於五六位的數字；而對於達到十位者，（至少在科學條目中）我實在找不到理由不分節。但無論最後何種方案通過，都支持限定新規定之溯及力。——Yangwenbo99^{論文} 2021年3月26日 (五) 20:46 (UTC)[回覆]
@Yangwenbo99：此折衷提案並不禁止分節，只是說「要麼就不分節，要分節就只能用三位分節法，不能用其他分節法」（好滿足三位分節法強硬支持者的要求）。此外，小弟我主張在長數字後面加註漢阿混合表述（例如在達到十位的數字後面加註「（XX.yy億）」或「（XX億yyyy萬）」），就是為了減少閱讀困難。📕📙📒📗📘📚📖 2021年3月26日 (五) 22:41 (UTC)[回覆]
原提案本來就沒禁止在與科學無關的條目應用四位撇節，這「折衷提案」反而盡廢四位撇節，看不出來有多折衷。我仍然認為科學相關條目中的數字應完全遵照三位撇節法（年份等特殊情況除外）。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 23:25 (UTC)[回覆]
另外一個問題，使用科學計數法時怎麼弄？比如3.52*10^35，要不要用中文數字表示數量級？如果讀者能理解10^35，那沒有理由不理解6.27*10^14（千分撇用於快速定位出10^14）？—洛普利寧 2021年3月27日 (六) 06:30 (UTC)[回覆]

又想了一下。「627萬1476億4039萬1274」這種寫法可能是個偽需求。比如光年這個單位，日常生活也會提到。條目序言說「9.46兆千米」，用通俗語言告訴一般讀者，這是個很大的長度單位；這姑且叫科學/專業條目的非專業部分吧。對於想了解天文學知識的人，後面的介紹就沒必要再「X億X萬」了。像是把光年換算成國際單位制，那主要就是參與計算用的；如果不需要精確值，9.461×10¹⁵ m這種科學記數法是最好的；「9461兆米」用於計算自然不方便。而如果要精確值，「9460兆7304億7258萬800米」，按計算器都要擔心千位丟個零，遠沒有「9,460,730,472,580,800」爽快。像一些更專業的內容，比如各類物理常熟，就算幫我標上「627萬1476億4039萬1274」，我還是也看不懂文章說啥啊……--洛普利寧 2021年3月27日 (六) 09:24 (UTC)[回覆]
只要提案有傾向把「XX恆星距地球十億光年」禁止，只允許寫「XX恆星距地球1,000,000,000光年」，我就反對。--7（留言） 2021年3月27日 (六) 04:09 (UTC)[回覆]
如果是我的原提案的話，提議條文有指明『「萬X」、「億X」等10⁴的倍數級的中文數字量值當成單位的一部分』，而且並沒有指明科學相關條目不適用，所以我肯定沒有必須要把整組數字寫出來的傾向。然而由於物理量量值必須使用阿拉伯數字（保留自原指引），上面的文句牽涉了物理量的單位，因此不能寫中國數字，在這種情況下我認為寫成「10億」是最好的做法。如果你說的是那個根本看不出來有多「折衷」的「折衷提案」的話，這可能要他自己回答。SAN MO SA _{江南好，風景舊曾諳} 2021年3月27日 (六) 05:12 (UTC)[回覆]

上面說的對。十億是10*10^8或1.0*10^9或1*10^9，具體取決於你想說十億加零頭還是十多億。1,000,000,000在科學文章有特別表示「十億（精確到個位）」的意思。我也不希望見到表示概數的地方，規定必須寫成容易引起誤解的1,000,000,000或1000000000。—洛普利寧 2021年3月27日 (六) 06:18 (UTC)[回覆]

關於Wikipedia:修訂版本刪除請求的RD5理由是否能適用於Wikipedia:刪除方針和Wikipedia:快速刪除方針

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:修訂版本刪除請求、Wikipedia talk:刪除方針、Wikipedia talk:快速刪除方針。

RD5的描述為「刪除守則下的有效刪除，使用RevisionDelete執行」，而「刪除守則」我認為應該對應Wikipedia:刪除方針（Wikipedia:修訂版本刪除的RD5的對應描述連結，就是刪除方針），而Wikipedia:快速刪除方針（SD）是刪除方針的刪除理由之一，而且SD本身是為了避免冗長討論而對於特定理由能快速執行刪除處理的特例，本身就應該滿足了刪除方針的要求。

所以如果特定版本中用戶名或編輯摘要滿足SD的條件（或者），是否能以RD執行版本剔除？

這源於Wikipedia:修訂版本刪除請求/存檔/2021年3月，「YouTuber」的一個版本中編輯摘要列出一個YouTuber的頻道地址（而且用戶名也是該頻道的名稱，不過沒申請處理，暫且不提），如果按照SD的話，已經符合G11的要求。但@蟲蟲飛：沒給出具體原因而拒絕了請求，所以對於蟲蟲飛或者其他有處理刪除作業的管理員表個態，對於編輯版本三個元素（內容、編輯摘要、用戶名）中存在滿足刪除方針和速刪方針的內容，是否能以RD5申請處理？--Sakamotosan路過圍觀杯弓蛇影 | 避免做作，免敬 2021年3月23日 (二) 09:41 (UTC)[回覆]

嚴重程度達到RD級別則可以。應該以目的和語氣判定。所提的Special:Diff/64784719，我認為沒達到這個程度，第一眼可視作在舉證，沒有讓普通人訪問的欲望。如果用戶名或編輯摘要如：快來訪問xxx、xxx有好東西、xxx某日大優惠之類的，則可以參照G11或G3來RD5，如果是病毒或騷擾則RD3。--YF dyh000（留言） 2021年3月23日 (二) 09:55 (UTC)[回覆]

需考量回退或直接忽略是否可行。--Xiplus#Talk 2021年3月23日 (二) 10:24 (UTC)[回覆]

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

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

現時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)[回覆]

先跑題：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)[回覆]

交通關注度指引修訂

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

現擬修改交通關注度指引如下：

現行條文

鐵路車站

捷徑

WP:NSTATION

任何鐵路車站，不論是跨城市鐵路系統（包含城際鐵路和區域鐵路，可為高速鐵路）車站，抑或是單一城市內鐵路系統（包含城市軌道交通和通勤鐵路）車站，須符合以下條件，方可獲收錄：

至少一條（含：曾、將）經過車站的獨立運行的路線符合《通用關注度指引》^[1]；
該路線所屬的系統屬於當地的骨幹交通系統（只限單一城市內鐵路系統車站）^[2]；
有至少一個可靠來源能提供有關車站座標及簡單統計數據以外的資訊。

不符以上條件者，則須符合《通用關注度指引》方獲收錄。

參考資料

^ 如該車站從未有任何路線經過，則車站須符合《通用關注度指引》方獲收錄。
^ 如地鐵和準地鐵，兩者皆無時則為輕軌運輸系統和輕軌捷運系統。

提議條文

鐵路車站

捷徑

WP:NSTATION

任何鐵路車站，不論是跨城市鐵路系統（包含城際鐵路和區域鐵路，可為高速鐵路）車站，抑或是單一城市內鐵路系統（包含城市軌道交通和通勤鐵路）車站，須符合以下條件，方可獲收錄：

至少一條（含：曾、將）經過車站的獨立運行的路線符合《通用關注度指引》或下方對物理綫路的要求^[1]；
該路線所屬的系統屬於當地的骨幹交通系統（只限單一城市內鐵路系統車站）^[2]；
有至少一個可靠來源能提供有關車站座標及簡單統計數據以外的資訊。

不符以上條件者，則須符合《通用關注度指引》方獲收錄。

參考資料

^ 如該車站從未有任何路線經過，則車站須符合《通用關注度指引》方獲收錄。
^ 如地鐵和準地鐵，兩者皆無時則為輕軌運輸系統和輕軌捷運系統。

以上。此修改意在使Wikipedia:關注度 (交通)#物理綫路適用於Wikipedia:關注度 (交通)#鐵路車站第一款，從而某程度上放寬對於鐵路車站的關注度要求。SAN MO SA _{江南好，風景舊曾諳} 2021年3月24日 (三) 09:58 (UTC)[回覆]

這個算是制定物理線路一節時的失誤，忘記同步修改鐵路車站的第一款了。(＋)支持。Itcfangye（留言） 2021年3月24日 (三) 16:26 (UTC)[回覆]

(＋)支持:修訂版很不錯，感謝修訂﹗--蟲蟲飛♡♡→♡℃※留言 2021年3月25日 (四) 07:18 (UTC)[回覆]

(＋)支持:不過實際上地鐵線路是不可能沒有有效介紹來源的。--Googol19980904（留言） 2021年3月26日 (五) 18:19 (UTC)[回覆]

修訂RD2的措辭使之更為一致

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:修訂版本刪除。

原始提案

問題的提出：近期，有管理員以RD2為由刪除一名用戶於用戶頁中針對其它用戶是破壞者的（疑似失實）指控（內容類似於「xxx是破壞者」）。事後，他/她援引現行RD2方針中的規定，即「這包括各種侮辱、誹謗以及極具冒犯性的內容」，以解釋自己的刪除行為；而這種刪除行為似乎不是社群所期待。仔細審閱RD2的條文可發現其內容存在一定程度的前後矛盾——一方面，RD2的導言規定其針對的是「針對個人、團體或組織的嚴重侮辱、貶低或攻擊性材料，且...」，換言之，RD2處理的問題必須為「針對個體或團體」的「嚴重侮辱、貶低或攻擊性材料」的一個子集；但另一方面，「這包括各種侮辱、誹謗以及極具冒犯性的內容」似乎又囊括了各種嚴重或不嚴重的「侮辱、誹謗」的行為。考慮到該條方針下方的小字解釋「為防止濫用或破壞頁面歷史，只有極度不文明，侮辱和噁心的內容才應利用修訂版本刪除功能。對於此種內容的評判標準之一可以是考慮是否在執行普通刪除後，該單一歷史版本仍能造成惡劣影響。對於一般刪除/回退即可消除影響的內容，請儘量利用一般刪除/回退功能」，可見社群訂明此方針時，即認為RD2的刪除門檻甚高，要求執行普通刪除/回退後仍能造成惡劣影響的內容才適用RD2。由此可認定「包括各種侮辱、誹謗以及極具冒犯性的內容」的措辭與該條方針的精神不符。為避免誤解，現提出以下方針修正案，使其內文更為一致，以期減少誤解與誤用：

現行條文

針對個人、團體或組織的嚴重侮辱、貶低或攻擊性材料，且幾乎或完全不具有價值或百科性，抑或違反生者傳記方針。這包括各種侮辱、誹謗以及極具冒犯性的內容。這不包括事實陳述，也不包括一般性的不文明、人身攻擊或對他人行為的控訴。如果頁面標題符合上述內容，可以在刪除或移動該頁面後，從日誌內移除標題。符合監督方針的內容可考慮申請監督隱藏。

提議條文

針對個人、團體或組織的嚴重侮辱、貶低或攻擊性材料，且幾乎或完全不具有價值或百科性，抑或違反生者傳記方針。這包括各種具有嚴重侮辱性、誹謗性以及極具冒犯性的內容。這不包括事實陳述，也不包括一般性的不文明、人身攻擊或對他人行為的控訴。如果頁面標題符合上述內容，可以在刪除或移動該頁面後，從日誌內移除標題。符合監督方針的內容可考慮申請監督隱藏。

--Antigng（留言） 2021年3月25日 (四) 03:07 (UTC)[回覆]

基本同意修訂。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 03:36 (UTC)[回覆]

(－)反對

違反生者傳記方針及誹謗的內容會令維基帶來法律風險不應該放寬。
這類針對特定生者或用戶的人身攻擊及誹謗不應縱容。
那些帶有針對特定生者或用戶的人身攻擊及誹謗是無意義的編輯修訂，保留對維基一點作用都沒有。

以上。--蟲蟲飛♡♡→♡℃※留言 2021年3月25日 (四) 04:07 (UTC)[回覆]

本人的提案旨在通過修訂方針中的措辭，以保持其內文的一致性，並令其如實、準確反映該條方針在通過之時社群的共識；關鍵在於通過之時社群如何認為，而不是您我他/她如何認為。從字面上看，社群在通過這條方針的時候對RD2就是持有非常嚴格的要求，為此甚至有解釋說明「為防止濫用或破壞頁面歷史...只有...才」——既然該等要求自方針訂立通過之時就存在，反對意見第一條中「放寬」一說自然不成立。

您的反對意見中的第二條和第三條實際上是對現行方針條文的質疑乃至否定。如果您對現行的方針條文，或者社群早前在該問題上的共識有所不滿，您可以考慮另案請求社群重新評估乃至訂立RD2的標準，如您在下一節所開展的行為。本人的提案，無論通過與否，對您的潛在的提案都沒有加以任何限制——它的目標僅僅是在更為準確地反映早前共識而已；而早前共識（無論準確與否）是允許被新近共識所取代的。

綜上，您的反對意見或是不符合事實，或是與本提案在邏輯上沒有關聯，不構成對本人提案的有效反對。以上。--Antigng（留言） 2021年3月25日 (四) 06:26 (UTC)[回覆]

(：)回應

現行方針字面意思已經很清晰，只是不同用戶理解上有些差異，這是正常的。要注意的是：RD2是包括違反生者傳記方針及誹謗，而且兩者都是只有違反不違反的差異，沒有「嚴重違反」的概念。此外，方針的精神比字面意思重要，詳見WP:5P5及WP:NOTBURO，RRD幾乎每個條款都涉及避免法律風險，因此RRD的執行也應以法律風險為主要考慮點：

RD1是刪明顯侵犯版權，與法律風險有關
RD2是刪誹謗及違反生者傳記方針的修訂，與法律風險有關
RD3是刪對他人的指控、騷擾或非常不合適的威脅或攻擊，與法律風險有關
RD4是刪侵犯私隱的，與法律風險有關
RD5是刪合理使用檔案的舊版本，是要配合合理使用的最低使用量的版權要求，與法律風險有關

以上都是與法律風險有關。事實上維基是應該設法避免法律風險的，而不是甚麼「貶低別人」的語句是否「嚴重」，而且「嚴重貶低」是沒有客觀標準的，您認為「不嚴重」，但當事人可能覺得「很嚴重」，而且受到很大的傷害。修訂條文不是詮釋方針，而是收窄了方針的適用範圍，而且沒有解決維基的法律風險問題。

以上。--蟲蟲飛♡♡→♡℃※留言 2021年3月25日 (四) 13:48 (UTC)[回覆]

「現行方針字面意思已經很清晰，只是不同用戶理解上有些差異，這是正常的」與事實不相符。事實上，在本人的提案的問題介紹部分，即解釋過該條規則的引言部分與解釋部分存在的表述差異，一者為「嚴重侮辱、貶低或攻擊性材料」之子集，而另一者則囊括「各種侮辱、誹謗以及極具冒犯性的內容」。這是相當嚴重的矛盾——離「清晰、只有理解上的差異」相差甚遠——因而本身就是一個值得修正的問題。而您為這一斷言所做出的解釋「RD2是包括違反生者傳記方針及誹謗」在邏輯上並不能推出「沒有嚴重違反」的概念，因為「RD2是包括違反生者傳記方針及誹謗」邏輯上不等於「任何違反生者傳記方針及誹謗皆屬RD2」——RD2在導言部分的定義是：

“

針對個人、團體或組織的嚴重侮辱、貶低或攻擊性材料，且幾乎或完全不具有價值或百科性，抑或違反生者傳記方針。

”

這句話語法分析一下，就是：

“

(針對個人、團體或組織的嚴重侮辱、貶低或攻擊性材料) AND ((幾乎或完全不具有價值或百科性) OR (違反生者傳記方針))。

”

足見「違反生者傳記方針」既非RD2成立的充分條件，也非必要條件；該條件不包含「嚴重」的概念，邏輯上也不等於RD2本身不包含「嚴重」的概念。

至於「RD設立的目的主要是為了規避法律風險」、「不是甚麼「貶低別人」的語句是否「嚴重」」——這類斷言也不是社群既有的共識。翻閱相關存檔，唯一涉及法律風險的討論是考量本地法律對RD規則的適用性，而討論結果則是社群的相當一部分成員反對以本地法律限制為由加以RD。而恰恰相反的事實是，RD在通過之時社群成員明確表示需嚴格規範RD尤其是RD2的適用範圍，以排除一般性的人身攻擊與一時的口出惡言。故而，您的這類斷言實質上仍然是在對既有社群共識、乃至既有方針的文本及精神的否定；如前一條回復所述，其在邏輯上與本人的提案（即並非尋求社群意見重新達成共識修改方針，而是根據既有社群共識完善方針文本以消除自相矛盾）沒有關聯。

總之，您提供的所有反對意見仍然符合下列三種問題中的至少一種：1. 與事實不符；2. 存在形式謬誤；3. 與本案無關。故仍不構成有效反對。以上。--Antigng（留言） 2021年3月26日 (五) 14:36 (UTC)[回覆]

(？)異議

提案不是詮釋方針，而是修改方針：

審閱過您引述的方針討論，那些例子都沒有「明確生者目標」，這些沒有目標的語句，當然不能刪，而且沒有「明確生者目標」也不違反生者傳記方針。
有用戶指出：現行條文在誹謗和違反生者傳記方針這兩個短語前，不論是中文還是英文都沒有grossly這個詞。修訂版加了「嚴重」在「誹謗」前是對方針實質的修改，不是單純詮釋方針。
「抑或違反生者傳記方針。」中的「抑或」的意思是「or」，意思即「嚴重侮辱、貶低或攻擊性材料」或「違反生者傳記方針」，符合其一就可以刪。詳見英文版「Grossly insulting, degrading, or offensive material that has little to no encyclopedic or project value, or violates our biographies of living people policy. 」也是用了多個「or」

基於提案是實質修改了方針的意思，而非單純詮釋方針，因此我上面的反對理據是有效，而提案以詮釋方針為目的顯然就不成立。

以上。--蟲蟲飛♡♡→♡℃※留言 2021年3月26日 (五) 16:27 (UTC)[回覆]

第3條錯誤，你引用的這句英文是以that為分界的主從句，邏輯結構正如上面Antigng君的語法分析。--Lt2818（留言） 2021年3月27日 (六) 04:35 (UTC)[回覆]

但that那個短句有個逗號，所以應該獨立來理解。--蟲蟲飛♡♡→♡℃※留言 2021年3月27日 (六) 05:29 (UTC)[回覆]

關於第一條，翻閱與RD2相關的所有討論串，未有一者探討「有/無明確生者目標」情形下處理之差異，甚至區分這兩種情形；故這種區分法本身即不是社群的既有共識，而只能理解為您的個人意見；如本人早前多次陳述，您當然可以提出既有社群共識所未涵蓋乃至相左的個人意見，但它並不能構成對本人這個旨在彰顯既有共識的提案的有效反對。

第二條和第三條純粹是英語問題。由於這裏不是英語課堂而是方針討論，本人僅簡單敘述一下：

關於第二條，前述現行RD2中，引起自相衝突的兩條規則，英文原文分別是

規則一，"Grossly insulting, degrading, or offensive material that..." 和

規則二"This includes slurs, smears, and grossly offensive material..."；

規則一不看that後邊的部分，符合英語語法規則的理解有且僅有有兩種：

a). grossly這個副詞僅修飾insulting這個形容詞，即"(grossly insulting material) OR (degrading material) OR (offensive material)"；

b). grossly這個副詞修飾"insulting, degrading, or offensive"這個形容詞短語，展開之後就是"(grossly insulting material) OR (grossly degrading material) OR (grossly offensive material)"。

您的主張是有一位用戶持有理解a)；本人的修正案則建基於理解b)之上。而規則二中的"slur/smear"本身的詞義就分別是程度嚴重的"degrading/insulting"行為，"offensive material"更是直接寫明了"grossly offensive material"加以限定；可見只有接受理解b)而非理解a)，現行英文方針才是上下文一致的；故b)才應視為符合英文方針原意的理解。

關於第三條，您所主張的「獨立理解」根本不為英語的語法規則所支持——"grossly insulting, degrading, or offensive material that has little to no encyclopedic or project value, or violates our biographies of living people policy."一方面，這一名詞性短語所包含的是限制性定語從句，that引導的從句是對中心詞material的限定，亦即必要條件；從句所包含的內容應當以邏輯與與"grossly insulting, degrading, or offensive"並列；另一方面，英語的語法要求從句剔出之後主句（短語）仍然符合語法規則。如"or violates our biographies of living people policy"不理解為從句的一部分，則剔除從句之後，該短語即轉化為"grossly insulting, degrading, or offensive material or violates our biographies of living people policy"，這是存在語法錯誤的。這一矛盾意味着別無選擇，唯有將"or violates our biographies of living people policy"理解為從句的一部分。故您的理解「『違反BLP』和『嚴重侮辱、貶低或攻擊性』之間存在邏輯或的關係」是完全錯誤的。

綜上，您仍然未提出符合事實和/或與本人提案有關聯的反對意見。--Antigng（留言） 2021年3月27日 (六) 14:19 (UTC)[回覆]

(：)回應

您有以下誤解：

雖然您引錄的方針修訂討論沒有提及「是否有目標」，但方針的其實是包括兩個情況要刪除：「嚴重侮辱」(沒有目標)或「誹謗」(有目標)，那次討論是針對第一項刪除條件，即「嚴重侮辱」(沒有攻擊目標)去討論，我也同意沒目標的侮辱，應該達到「噁心」，才能刪，但違反生者傳記方針的，有法律風險，不能不處理。您是混淆了兩種情況都要達到「嚴重」，方針的標題寫得不好，但正文已經寫得很清晰。您現在是把「誹謗」(有目標)加了一個修飾語「嚴重」，變成「嚴重誹謗」才要刪。但您沒有考慮到「誹謗」是沒有「嚴重不嚴重」的差異，例如，楊受成(條目有相關記述)就曾控告google及維基誹謗，其中他是控告google的搜尋預示關鍵詞出現「楊某某黑社會」，他認為是誹謗，香港法庭受理，並傳召美國的google來香港上庭，結果google敗訴。您可能認為關鍵詞「楊某某黑社會」不嚴重，但一旦涉及「誹謗」，就可以控告維基。
您提到英維方針有文法錯誤，您自己的理解才對，但兩站的正文都已經寫得很清楚，方針的其實是包括兩個情況要刪除：「嚴重侮辱」(沒有目標)或「誹謗」(有目標)，您不能因為標題寫得不好，而改方針，您應修改標題為「違反生者傳記方針或嚴重侮辱、貶低或攻擊性材料」以配合方針正文的描述，而不是反過來，然後忽視了法律風險問題。
我巡查員時天天在提報RRD、速刪、侵權等，我當時的提報基本上是準確無誤，因此我能看到所有管理員的RRD的標準。我上任管理員也每天都處理rrd，我能看到大量不同用戶如果提報rrd，因此我很瞭解社羣如何解讀及實踐rrd，下面我也舉了不同管理員的rrd案例，基本上沒有管理員會把「誹謗」或「違反生者傳記方針」的修訂刪除提高到「嚴重」的標準，而且您把「嚴重」放在「誹謗」前，而且把「誹謗」改為「誹謗性」，那您的標準是甚麼？您如何解決改了方針後，維基所面對的法律風險？
我從社羣實際操作和過去的方針討論，覺得您這是修改方針，不是詮釋方針，因此提案以詮釋方針為目的就已經不成立。

以上。--蟲蟲飛♡♡→♡℃※留言 2021年3月28日 (日) 04:32 (UTC)[回覆]

對方針詮釋的分歧

感覺不能解決目前的操作爭議。建議：針對個人、團體或組織的嚴重侮辱、貶低或攻擊性材料，無益於條目編寫，或者內容違反生者傳記方針。此事重點可能是「也不包括一般性的不文明、人身攻擊或對他人行為的控訴。」，這個他人很多是生者，說「控訴」違背生者傳記與「也不包括」是衝突的，而且指責行為完全算不上「傳記」。而如果不是「傳記」或持續生效的嚴重侮辱，且指責確實指出了頁面存在的問題（錯誤或缺失），那麼是有益於條目編寫的。無法認可蟲蟲飛的操作理據和理念。--YF dyh000（留言） 2021年3月25日 (四) 04:10 (UTC)[回覆]

對以「生者傳記」和誹謗而清理以防法律風險，太多條目中的無來源內容（違背BLP）或者對「爭議」記載的風險大太多了，徹底刪除一般的不文明是本末倒置，濫用版本刪除。--YF dyh000（留言） 2021年3月25日 (四) 04:13 (UTC)[回覆]

一般不文明固然不用刪除，RD2應該是介於OS與回退之間的緩衝，彈性較大，自極不文明至嚴重違反當地及伺服器所在地之法律者皆適用。--銀河市長—☎️— 2021年3月28日 (日) 02:19 (UTC)[回覆]

@YFdyh000：為甚麼您認為沒有來源的生者傳記負面內容不應被刪去？--蟲蟲飛♡♡→♡℃※留言 2021年3月27日 (六) 02:31 (UTC)[回覆]

@蟲蟲飛：即便是條目中的涉及知名人物的無來源負面生者傳記，也只是應當被立即回退（且實務中很多並不會這樣做，比如僅請求來源），而不是版本刪除。所以為什麼您會認為所有頁面中可能很不起眼或普通的涉及一般生者的負面言論都要施加版本刪除？法律風險完全是杞人憂天、奇怪的理由，比如有避風港原則。您對版本刪除的理解和使用也完全不符它的適用範圍。--YF dyh000（留言） 2021年3月27日 (六) 02:46 (UTC)[回覆]

您有所不知，我巡查員時候每天都在舉報違反生者傳記的修訂，全都被不同管理員刪去的，而且我管理員上任後，也看到不同巡查員請求刪去違反生者傳記方針的修訂，這是社羣一向的操作慣例，印象中只有兩位管理員對生者的負面內容的容忍度是較大的。--蟲蟲飛♡♡→♡℃※留言 2021年3月27日 (六) 02:58 (UTC)[回覆]
我只能說相關操作與方針不符，我也不認為這是得當的長期操作慣例。--YF dyh000（留言） 2021年3月27日 (六) 03:02 (UTC)[回覆]

英維和本站的方針都是這樣寫，而且這些操作都符合方針精神，就是要避免有用戶回退到有問題的修訂，為維基帶來法律風險，這是很重要，而且有重大意義。就算您對方針字面意思解讀有所不同，您也要理解方針背後的精神，而且要注意方針的精神比字面意思重要，詳見WP:5P5及WP:NOTBURO。--蟲蟲飛♡♡→♡℃※留言 2021年3月27日 (六) 03:32 (UTC)[回覆]
避免破壞者取得/引導取得被破壞的內容，至多是頁面刪除的作用，版本刪除也至多是RD3（它的靈活性更高，但我依然不贊成您過度使用），RD2的設立肯定是沒這個含義的，因而RD2細則寫明「嚴重」和「這不包括」。--YF dyh000（留言） 2021年3月27日 (六) 12:31 (UTC)[回覆]
我覺得RD2的標準不必太高，否則和OS太接近。--銀河市長—☎️— 2021年3月28日 (日) 02:13 (UTC)[回覆]

如果無來源且負面，沒有可回退的歷史版本就刪除；有則回退。--銀河市長—☎️— 2021年3月27日 (六) 12:20 (UTC)[回覆]

同上，反對蟲蟲飛的反對意見。YFdyh000的意見我認為確實有值得參考之處。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 04:19 (UTC)[回覆]

中文不必有「和/或」之表述，難以理解。上文語境中「以及」表示析取並無歧義，合取會用「且」表示。其他沒有問題。--Lt2818（留言） 2021年3月25日 (四) 04:32 (UTC)[回覆]

已修正，請複查。--Antigng（留言） 2021年3月25日 (四) 06:08 (UTC)[回覆]

好的。--Lt2818（留言） 2021年3月25日 (四) 06:46 (UTC)[回覆]

修訂2

現行條文

針對個人、團體或組織的嚴重侮辱、貶低或攻擊性材料，且幾乎或完全不具有價值或百科性，抑或違反生者傳記方針。這包括各種侮辱、誹謗以及極具冒犯性的內容。這不包括事實陳述，也不包括一般性的不文明、人身攻擊或對他人行為的控訴。如果頁面標題符合上述內容，可以在刪除或移動該頁面後，從日誌內移除標題。符合監督方針的內容可考慮申請監督隱藏。

提議條文

違反生者傳記方針或嚴重侮辱、貶低或攻擊性材料且幾乎或完全不具有價值或百科性。這包括各種侮辱、誹謗以及極具冒犯性的內容。這不包括事實陳述，也不包括一般性的不文明、人身攻擊或對他人行為的控訴。如果頁面標題符合上述內容，可以在刪除或移動該頁面後，從日誌內移除標題。符合監督方針的內容可考慮申請監督隱藏。

以上。--蟲蟲飛♡♡→♡℃※留言 2021年3月25日 (四) 04:14 (UTC)[回覆]

(～)補充:我覺得可以以「有沒有特定對象」作為界線。--蟲蟲飛♡♡→♡℃※留言 2021年3月25日 (四) 04:16 (UTC)[回覆]

(－)反對蟲蟲飛的提案，理由見上YFdyh000所述，這是濫用版本刪除。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 04:19 (UTC)[回覆]

針對生者的誹謗及違反生者傳記方針會為維基帶來法律風險，而且保留這類修訂歷史有甚麼用？--蟲蟲飛♡♡→♡℃※留言 2021年3月25日 (四) 04:24 (UTC)[回覆]

然而你的提案無疑是在濫用版本刪除。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 04:34 (UTC)[回覆]

方針已經說了符合事實的就不能刪。--蟲蟲飛♡♡→♡℃※留言 2021年3月25日 (四) 05:39 (UTC)[回覆]

那甚麼是「事實」？SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 05:48 (UTC)[回覆]

有可靠來源證明的就是「事實」，而且維基可以加入負面內容，前提是有「可靠來源」。沒有可靠來源的誹謗，不只違反生者傳記方針，而且是違法，香港就曾經有人控告維基誹謗，而且當時維基沒有代表上法庭。--蟲蟲飛♡♡→♡℃※留言 2021年3月25日 (四) 15:40 (UTC)[回覆]

@蟲蟲飛：WP:REFNOTTRUE：「可供查證……只是為確保編輯者撰寫的內容，真實存在於可靠來源……但這並不意味可查證來源的內容具有絕對的正確性。來自於可靠來源的內容也可能有誤。」SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 01:53 (UTC)[回覆]

您對法律知識有所不知，如果主流媒體都在說某人有甚麼負面內容，然後維基根據媒體報道去轉述，這是可以免責的。當然事主可以控告媒體誹謗，如果控告成功，法庭會要求媒體撤回文章，然後維基也應因應媒體的撤回言論，也依從法庭指令去撤回。--蟲蟲飛♡♡→♡℃※留言 2021年3月26日 (五) 03:00 (UTC)[回覆]

維基百科伺服器在美國，理論上只需要遵守美國法律。如果真的是在美國法院有這樣的判決，那樣直接根據使用條款移除就可以（使用條款明確說明維基百科需要遵守美國法律），但我認為如果真的出這樣的情況，基金會已經會早一步處理。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 08:26 (UTC)[回覆]

您對香港的法庭非常不瞭解，香港法庭是很厲害的，前幾年楊受誠控告google誹謗，因為搜尋器出現他的名字與黑社會連在一起的關鍵詞，香港法院向美國google公司傳召告票，傳召google來香港上庭，結果google是敗訴，要賠款及付頌費。維基在香港也曾被控告誹謗，當時是沒有基金會代表上庭，如果沒記錯，後來香港維基分會被基金會取消，不肯定與此案是否有關。--蟲蟲飛♡♡→♡℃※留言 2021年3月26日 (五) 13:25 (UTC)[回覆]

特定與否可能難以界定。你覺得我要是辱罵所有濫用傀儡者，算不算特定個人？--Lt2818（留言） 2021年3月25日 (四) 04:49 (UTC)[回覆]

已經根據您的意見修正。--蟲蟲飛♡♡→♡℃※留言 2021年3月25日 (四) 05:36 (UTC)[回覆]

仍然(－)反對你的提案。我理解你的出發點是為自己的操作辯護，但由於條文中包括了「團體或組織」，如此修訂恐怕會為政治審查開方便之門，例如貶低某個政黨的言論就能據此隱藏。--Lt2818（留言） 2021年3月26日 (五) 15:29 (UTC)[回覆]

(：)回應:您誤會了，我沒有加入任何用戶組，而且對黨派之爭不感興趣。而且我這個修訂版其實是收窄了範圍，即刪去沒有目標的「嚴重貶低」，即只限於「生者傳記方針」，就算不修改，現在其他管理員都是這樣操作，而且刪除標準比我更寬。--蟲蟲飛♡♡→♡℃※留言 2021年3月26日 (五) 16:36 (UTC)[回覆]

@蟲蟲飛：凡請抹去姓名並舉例說明「現在其他管理員都是這樣操作，而且刪除標準比我更寬。」--YF dyh000（留言） 2021年3月27日 (六) 00:07 (UTC)[回覆]

@YFdyh000：

以下為其他管理員的操作案例：

以上為部分例子。--蟲蟲飛♡♡→♡℃※留言 2021年3月27日 (六) 02:52 (UTC)[回覆]

我開一個新段：現在的rd2方陣翻譯自英文，原文為「Grossly insulting, degrading, or offensive material that has little to no encyclopedic or project value, or violates our biographies of living people policy. This includes slurs, smears, and grossly offensive material of little or no encyclopedic value, but not mere factual statements, and not "ordinary" incivility, personal attacks or conduct accusations. When pages with grossly improper titles are in question, the page names may also be removed from the page creation, move, and delete logs.」蟲蟲飛的意見可以概括為：去掉這段文字中所有表達「grossly」這個意思的文字。而sanmosa的意見則是：將表達grossly這個意思的文字提前。Itcfangye（留言） 2021年3月25日 (四) 15:26 (UTC)[回覆]

不同意您的總結，我是以「有沒有特定對象」作為界線。--蟲蟲飛♡♡→♡℃※留言 2021年3月25日 (四) 23:56 (UTC)[回覆]

部分同意Itcfangye的總結。Itcfangye對我的意見的理解正確。就Itcfangye對蟲蟲飛的意見的理解而言，蟲蟲飛想移除「grossly」是正確的，但蟲蟲飛不是只想移除「grossly」，他還想加入「(to) specific target(s)」（當然，我自己是認為制限性不足）。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 01:59 (UTC)[回覆]

(※)注意:我之所以以「有沒有特定對象」作為界線，因為誹謗和生者傳記方針都是應該有明確的生者為目標才可以成立，現行方針的原意應該也是這樣，只是表述不清楚。至於是否「嚴重貶低」是沒有客觀標準的，您認為「不嚴重」，因為被誹謗和攻擊的不是你，但事主可能覺得「很嚴重」，而且受到很大的傷害。而且保留這些誹謗和違反生者傳記方針的內容有甚麼用？如果有人回退到那個修訂，維基絕對有可能要面對法律風險。--蟲蟲飛♡♡→♡℃※留言 2021年3月26日 (五) 03:07 (UTC)[回覆]

@蟲蟲飛：但您不能否認您的提案里確實移除了所有原文中的grossly（嚴重、極具）一詞，正如上文sanmosa所指出的這樣。Itcfangye（留言） 2021年3月26日 (五) 03:55 (UTC)[回覆]

（嚴重、極具）一詞確實移除了，但重點不是在這裏，因為誹謗和違反生者傳記方針，有「嚴重」和「不嚴重」的差異嗎？如果您認為有，那標準是甚麼？--蟲蟲飛♡♡→♡℃※留言 2021年3月26日 (五) 04:29 (UTC)[回覆]

現行條文在誹謗和違反生者傳記方針這兩個短語前，不論是中文還是英文都沒有grossly這個詞。Itcfangye（留言） 2021年3月26日 (五) 04:32 (UTC)[回覆]

問題來了，現在有用戶認為誹謗及違反生者傳記方針的內容，也要符合（嚴重、極具）的標準，您覺得是否符合方針意思？--蟲蟲飛♡♡→♡℃※留言 2021年3月26日 (五) 04:41 (UTC)[回覆]

您似乎誤解了antigng的提案，他說的是「嚴重侮辱」或「誹謗」。Itcfangye（留言） 2021年3月26日 (五) 17:00 (UTC)[回覆]

如果是這樣當然沒有問題，但我覺得他的意思是符合「嚴重侮辱」及「誹謗」才可以刪，不嚴重的「誹謗」就不刪。例如「Itcfangye是破壞者」，他覺得不能刪。--蟲蟲飛♡♡→♡℃※留言 2021年3月26日 (五) 17:13 (UTC)[回覆]

這確實不能刪，相信多數意見也是如此。如果這算作誹謗，WP:VIP、WP:SRCU、WP:RFDA/A等頁面中未成立的投訴破壞者是誹謗嗎，應該徹底刪除嗎。

像是「某某是傻瓜」（惡作劇），「xxx完全亂寫」等編輯摘要中的一般性的攻擊或意見，完全達不到需版本刪除的嚴重誹謗。現有方針「也不包括一般性的不文明、人身攻擊或對他人行為的控訴。」已作排除。即便是「xxx騙了我50萬」這種內容/編輯摘要，也至多算無關百科的擾亂（RD3），而不是RD2誹謗，「XXX的XXX專案完全是個騙局！」這種才可能考慮RD2，但同時如果涉及「這不包括事實陳述」（例如已有報道）而有關於條目編寫，則不一定被RD2並可選RD3。

另外提一下，刪除/版本刪除/過濾器封鎖涉及自身的擾亂/騷擾，我認為不夠避嫌。且過濾器產生了多例誤封鎖。--YF dyh000（留言） 2021年3月27日 (六) 00:25 (UTC)[回覆]

(：)回應:

您誤解了「誹謗」的法律概念，「誹謗」是針對「不實陳述」，而非「意見」，以下為舉例：

情景一：「（節刪）是破壞者」(隱含此用戶作出多次及持續的破壞，屬於誹謗)
情景二：「有人到VIP舉報（節刪）破壞，結果:管理員拒絕，判定為非破壞」(舉報過程是屬實，只要結果沒有被偽造，就不是誹謗)
情景三：「A是強姦犯」(誹謗)
情景四:「B控告A強姦，但法庭判定為罪名不成立」(舉報過程是屬實，只要法庭判決沒有被偽造，就不是誹謗)
情景四：「A是傻瓜」(不是誹謗，因為「傻瓜」是「意見」，不是「事實」，但負面形容詞，是違反生者傳記方針。

以上。--蟲蟲飛♡♡→♡℃※留言 2021年3月27日 (六) 02:20 (UTC)[回覆]

我不覺得RD2涉及到法律概念的定義/解讀，並認為您在RD2判定時擴大了對「生者傳記」的解讀，單純的批評或不實言論我認為不是傳記。對於例子，暫無看法，只感覺好像價值不大。--YF dyh000（留言） 2021年3月27日 (六) 03:11 (UTC)[回覆]

(※)注意：我看到您刪去了例子中的用戶名，這裏可以說明「是否嚴重貶低」是沒有客觀標準，如果您是受害人，您的感受是很大的，而且會覺得「很嚴重」，相反，一般人看到其他人的名字被貶低，都沒甚麼感覺，因為被貶低的對象不是自己。維基是很重視「文明與禮儀」和法律風險，這類誹謗或違反生者傳記方針的修訂一點意義都沒有，而且保留只會帶給維基法律風險，過去香港確實有人控告維基誹謗。--蟲蟲飛♡♡→♡℃※留言 2021年3月27日 (六) 03:23 (UTC)[回覆]

我只能說您對RD2的理解已經超出其定義，如果管理員實務操作中普遍如此，那麼應該全盤審核先前的RD2和當前方針解釋。
當事方反應是相差很大、無法估量的，如果不做客觀解釋和標準，版本刪除的濫用是必然的。如果當事人明確拒絕其他人提起某件事或屬性（例如胖），是否相關內容及歷史版本就全部要刪除，否則會給維基帶來法律風險。所有介紹「爭議」的條目，均會給維基帶來法律及其他風險，這是不能且不應避免的。
沒有展示/收錄意義不代表沒有歷史意義，至少我個人更反感刪除歷史記錄的行為，這已相當於WP:CENSOR。--YF dyh000（留言） 2021年3月27日 (六) 03:45 (UTC)[回覆]

(？)疑問：

訂立一個方針須要考慮實質意義和作用，因此要瞭解方針的精神，您要思考以下問題：

LTA在一個條目加了如「某某人智力有問題」或「某某人強姦某人」(誹謗)，在修訂歷史中保留，有甚麼作用及意義？
有用戶回退到「某某人智力有問題」或「某某人強姦某人」(誹謗)的修訂版本，給讀者有甚麼作用及意義？
事主就着「某某人智力有問題」或「某某人強姦某人」(誹謗)的修訂版本控告維基誹謗，這個法律風險是否本站可以無視及不處理？

以上。--蟲蟲飛♡♡→♡℃※留言 2021年3月27日 (六) 04:07 (UTC)[回覆]
保留破壞當然沒有意義，但是應考慮隱藏帶來的其他後果。除了我上面提到的政治審查顧慮外，也要避免長期未被移除的輕微破壞致使大量歷史被隱藏。Wikipedia:互助客棧/其他被監督隱藏的前例，你作為當事人應深有體會。--Lt2818（留言） 2021年3月27日 (六) 05:08 (UTC)[回覆]

那些監督隱藏的操作原意是不讓人看到私隱，符合方針規定。我在元維基也試過兩次意外登出，第一次是當地管理員主動幫我刪去，另一次是我私下電郵sotiale請求刪去。此外，政治審查不是這樣理解，RSN打壓政見媒體才是政治審查，但把破壞者加的「某某人是弱智」等語句刪去，與政治有甚麼關係？--蟲蟲飛♡♡→♡℃※留言 2021年3月27日 (六) 05:38 (UTC)[回覆]
假如我說「中華統一促進黨是弱智」，與生者傳記無關，但落在了你修改後的「針對組織的貶低性材料」範圍中，而這句話的惡性顯然並非嚴重。--Lt2818（留言） 2021年3月27日 (六) 07:04 (UTC)[回覆]

您有來源證明這句嗎？如果沒有，也應該刪去。同理，有人加了「民進黨是弱智」，或者「國民黨是弱智」等語句，在沒有可靠來源支持下，您認為都不能刪嗎？--蟲蟲飛♡♡→♡℃※留言 2021年3月27日 (六) 07:13 (UTC)[回覆]

只要不在條目中，這樣的話隨便說。條目中出現這樣的話則要刪去，但不需要隱藏修訂。--Lt2818（留言） 2021年3月27日 (六) 07:28 (UTC)[回覆]

您這是無視了維基的法律風險，有時即使是一兩個誹謗詞，已經足以構成法律風險。例如，幾年前楊受成控告google誹謗，因為搜尋器出現他的名字與黑社會連在一起的關鍵詞，香港法院向美國google公司傳召告票，傳召google來香港上庭，結果google是敗訴，要賠款及付頌費。楊受成也曾控告維基誹謗。此外，請您注意，千萬不要因為政見，而走去破壞條目。--蟲蟲飛♡♡→♡℃※留言 2021年3月27日 (六) 09:56 (UTC)[回覆]
呃，如果違法就應該要監督，RD2適用於不違法？--銀河市長—☎️— 2021年3月28日 (日) 09:12 (UTC)[回覆]

違法的當然要監督隱藏，但監督前，管理員可以先RD2。RD2也適用於「沒有生者目標的極度噁心」的語句，因為不涉及生者，所以沒有法律風險，但又考慮到令人噁心，才會RD2，但現在有用戶混淆了這兩種情況，以為違法的東西，也要令人噁心，才要RD2，這是對方針的誤解。--蟲蟲飛♡♡→♡℃※留言 2021年3月28日 (日) 10:40 (UTC)[回覆]

（更新版）國際關係條目命名常規

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:命名常規 (國際關係)。

現擬將更新版國際關係條目命名常規作方針通過，草案內容會盡快更新。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 03:52 (UTC)[回覆]

草案內容已在2021年3月25日 (四) 04:01 (UTC)更新，並增補特殊情況。SAN MO SA _{江南好，風景舊曾諳} 2021年3月25日 (四) 04:01 (UTC)[回覆]

草案已在2021年3月26日 (五) 09:21 (UTC)進一步更新。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 09:22 (UTC)[回覆]

@YFdyh000：麻煩你過來發表一下意見了，不然我到時公示又會被其他有心人士中傷。這版的草案大體上鼓勵採用原草案所規範的格式（通過限制「特殊情況」的適用情形），但以「特殊情況」（暫時）容許已採用單字簡稱式條目名的條目繼續採用單字簡稱式條目名，避免對現狀進行太大的更動。至於一些具體條目是不是要移動，「特殊情況」指明可以發起移動請求，或在互助客棧討論。之前我曾經做過幾次被回退的移動，如果這版草案通過的話，這幾個移動我仍不考慮重新來（但其中一個我會考慮提出移動請求）。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 09:21 (UTC)[回覆]

@Sanmosa：抱歉，我目前無意研究和推進該草案。雖然您可公示並擬作方針通過，但如果後續執行發生異議，我認為就需對細節重新討論/表態，WP:7DAYS公示不能代表共識，討論才可以。--YF dyh000（留言） 2021年3月27日 (六) 00:04 (UTC)[回覆]

沒人來討論，通過了又說要重來，這是甚麼討論循環？SAN MO SA _{江南好，風景舊曾諳} 2021年3月27日 (六) 04:57 (UTC)[回覆]

方針設立要基於共識，而如果沒人討論、只有提案人/少數意見，應當是「無共識」或者部分共識，不是任何內容公示多少日就產生「共識」了，希望能提案時明白這點以及7DAYS的本意。您得考慮是否有人關心這份議案、理解其內容，以及不關心客棧但精通相關內容的編者是否已了解到相關變更和實際影響。--YF dyh000（留言） 2021年3月27日 (六) 05:07 (UTC)[回覆]

我認為7DAYS的本意已被曲解，否則我上面也不會提對7DAYS的修正案。我清楚7DAYS（和客棧討論）的本意是甚麼，不然我直接等7日然後公示就好了，用不着ping人來討論。SAN MO SA _{江南好，風景舊曾諳} 2021年3月27日 (六) 05:19 (UTC)[回覆]

我請另外一個人過來好了。@Ericliu1912。SAN MO SA _{江南好，風景舊曾諳} 2021年3月27日 (六) 04:57 (UTC)[回覆]

(＋)支持。——BlackShadowG（留言）_{維基百科20歲生日快樂！} 2021年3月28日 (日) 17:57 (UTC)[回覆]
現行版本草案可以接受。—— Eric Liu_{創造は生命（留言．留名．學生會）} 2021年3月29日 (一) 13:40 (UTC)[回覆]

跨語言連結模板的偏好

本主題或以下段落文字，在討論結束後應存檔至Template talk:Internal link helper、Template talk:Translink。

現在維基百科上使用的跨語言連結有兩種，ilh（link-xx）和tsl。兩種跨語言連結模板的參數順序是不一樣的，在不少頁面中兩種跨語言連結都存在，有時候挺容易將參數寫反，維基百科是不是應該給出一個模板的偏好，儘量減少兩種模板的混用。 --𝓧𝓩𝓣𝓓𝓮𝓪𝓷 ^{𝕋𝕒𝕝𝕜} 2021年3月25日 (四) 21:49 (UTC)[回覆]

不認為需要限制，多種模板的設立和常用正因為編者習慣差異很大。寫自己偏好的，改其他人的連結時多檢查多預覽，或者換掉寫法。{{tsl}}支持省略中文條目名寫法，只填外文條目和顯示文本，ilh則不能。還有{{le}}、{{lj}}等簡寫捷徑，不熟悉肯定看不懂，原始碼習慣沒法統一。--YF dyh000（留言） 2021年3月25日 (四) 23:46 (UTC)[回覆]

link-xx理論上也可以省略中文條目名寫法，前提是中文條目名寫法和外文條目名寫法完全一致。日文類的我常常會這樣做。SAN MO SA _{江南好，風景舊曾諳} 2021年3月26日 (五) 01:02 (UTC)[回覆]

不需要限制，閣下的情形是需要多接觸多練習，而不是限制他人的行為。-- 約翰同志－條目裱糊匠（留言） 2021年3月26日 (五) 08:34 (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)[回覆]

(－)強烈反對：對地質和生物學相關等特殊模板有嚴重影響！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)[回覆]

交通關注度指引適用範圍的擴展

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

雖然現行交通關注度指引希望能夠涵蓋所有和交通有關的專案頁面，但現時實際上只能夠有效銜蓋鐵路和公路相關的專案頁面，而之前有關巴士路綫的關注度社群也沒有一個很好的共識。最近有留意到有一些公共運輸交匯處（轉運站）的條目被刪除，因此想探討一下究竟巴士站（包括但不限於巴士總站、巴士轉乘站、公共運輸交匯處等）究竟要怎樣才能夠收錄。SAN MO SA _······ 2021年3月29日 (一) 06:41 (UTC)[回覆]

公車線路算嗎？--Nrya（留言） 2021年3月29日 (一) 11:48 (UTC)[回覆]

@Nrya：公車線路很明顯不是公車站。SAN MO SA _Σουέζ 2021年3月29日 (一) 12:33 (UTC)[回覆]

Ping幾個人來好了。@Streetdeck、UsFTBu3TR、Richardcai。SAN MO SA _Σουέζ 2021年3月29日 (一) 12:33 (UTC)[回覆]

個人建議參考WP:NSTATION，但指引的第一條修改為：至少*兩*條（含：曾、將）經過車站的獨立運行的路線符合《通用關注度指引》*或超過四條巴士線途經。*—UsFTBu3TR（留言📩） 2021年3月29日 (一) 13:01 (UTC)[回覆]

我認為巴士總站和大型交通樞紐可以直接適用WP:GNG，我暫時看不到需要擴展關注度 (交通)指引的必要性。--痛心疾首 2021年3月29日 (一) 13:03 (UTC)[回覆]

@痛心疾首：理解你的意見，我自己本身也沒有既定立場。不過如果遇着像黃竹坑站公共運輸交匯處和何文田站公共運輸交匯處這種只是加了一個車坑，但又有接駁鐵路車站的公共運輸交匯處（轉運站／交通樞紐／綜合交通中心）的情況，又或是像香港仔（成都道）巴士總站這樣單純把街道上的一個巴士站當成巴士總站的情況（這在澳門很常見），又該如何處理？SAN MO SA _Σουέζ 2021年3月29日 (一) 14:18 (UTC)[回覆]

對於前兩種情況，只加了一個車坑（港灣式車站/候車點）但和軌道交通接駁的，如果是我的話傾向於和軌道交通站同寫。此外，單純把一個巴士站當成總站，則應該看運輸行政部門或者運輸公司的界定，來確定劃入關注度指引的程度，單純一個終點站（總站）不一定有撰寫價值，也許可以和其他名字類似、地點相近的總站合在一起寫。例如，以上海人民廣場為終點的公交車，分為普安路、武勝路（東北、東南、西）、廣東路等地點，不見得就值得把四個站都分開寫，這些站應該都寫在人民廣場（上海）條目里。--痛心疾首 2021年3月30日 (二) 01:17 (UTC)[回覆]

以上兩套方案皆可。——Richardcai·你好，《濘之翼3》！WPJHZ·HZP 2021年3月29日 (一) 13:22 (UTC)[回覆]

對巴士總站、大型換乘站等建築/結構，個人暫時想不出一個比較合適的關注度判別法則。Itcfangye（留言） 2021年3月29日 (一) 23:52 (UTC)[回覆]

或許可以按地區來看。就新加坡而言，參考了一下enwiki的對應條目，我認為只要那個巴士站的英文稱為「Bus Interchange」（達「巴士轉換站」格），即使中文未有跟隨更名，應該假定具有足夠關注度。另外，在新加坡，所有的「綜合交通中心」（「Integrated Transport Hub」）都是由政府特別規劃並界定的，數量亦有限，而且全部都是「Bus Interchange」，因此如「Bus Interchange」應該假定具有足夠關注度，「綜合交通中心」（「Integrated Transport Hub」）亦應該假定具有足夠關注度。新加坡其他一般的巴士總站可能關注度不大，不建議開特例容許收錄。SAN MO SA _Σουέζ 2021年3月30日 (二) 00:20 (UTC)[回覆]

香港的「公共運輸交匯處」（或各類相類近的名稱）用得比較濫，但一般而言大部分的巴士總站和「公共運輸交匯處」都有一定的規模，因此就香港而言，可能不能分級處理，而需要再看情況。SAN MO SA _Σουέζ 2021年3月30日 (二) 00:24 (UTC)[回覆]

[DP9-1] 模板無連入並非提刪的充分理由，除連入外應從是否被腳本引用、是否有助於主要歷史版本完整呈現、是否短期內有機會再被復用等方面考量是否仍有使用價值。

[2] Wikipedia:遊戲維基規則第4（濫用程序）章節。在「遊戲維基規則、人身攻擊、為闡述觀點而擾亂」三種情形中，模板提刪尤以第一種為甚。

[[2021]DRV-01/11-23{TPLT}-3] 2.0 ^2.1 ^2.2 ^2.3 2021年1月「Template:2017年香港播出之動畫」存廢覆核（[2021]DRV-01/11-23{TPLT}）：「……不應該過度理解為阻礙本站日常整理、保持井然有序之理由……」。

[[2021]AFD-01/29-9{TPLT}-4] 3.0 ^3.1 2021年1月29日「Template:NFSC」存廢討論（[2021]AFD-01/29-9{TPLT}），並2021年2月「Template:NFSC」存廢覆核申請（[2021]DRV-02/09-26{TPLT}）。

[[2021]DRV-02/20-40{TPLT}-5] 4.0 ^4.1 ^4.2 2021年2月「Template:南京市」存廢覆核申請（[2021]DRV-02/20-40{TPLT}）。

[6] 或許可以不完全恰當地借用凱恩斯的一句話：「用長期指導當下是一種誤導。因為長期來看，我們都完了。（……this long run is a misleading guide to current affairs. In the long run we are all dead.）」John Maynard Keynes, A Track on Monetary Reform, Promethus Books, 2000 (originally 1923), p. 80.

[7] 英維古典音樂專題的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).

[8] 纪念古斯塔夫·马勒逝世110周年系列音乐会之二. [2021-03-28].

[9] 【海神家族與馬勒巨人】簡文彬與國臺交將以音樂帶您感受作曲家與文學家筆下的深刻情感. [2021-03-28].

[10] 贝多芬的第五号交响曲.

[11] 理論上在正文出現的括號應該用全形，哈哈

[12] 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

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

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

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

[n1-16] 如該車站從未有任何路線經過，則車站須符合《通用關注度指引》方獲收錄。

[17] 如地鐵和準地鐵，兩者皆無時則為輕軌運輸系統和輕軌捷運系統。

[n1-18] 如該車站從未有任何路線經過，則車站須符合《通用關注度指引》方獲收錄。

[19] 如地鐵和準地鐵，兩者皆無時則為輕軌運輸系統和輕軌捷運系統。

[20] 參見Wikipedia:鐵道專題/移除着色文字模板。

[21] 參見WikiProject:鐵道/移除着色文字模板。

[1]

[1]

[2]

[3]

[4]

[5]

[1]

[2]

[3]

[4]

[5]

[6]

[1]

[1]

[1]

[1]

[2]

[1]

[2]

[1]

[1]

正在廣泛徵求意見的議題

專題命名空間

專題空間設立流程與細節

第一階段：申請

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

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

第二階段 之 公示狀態通告

第二階段 之 公示期討論

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

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

第四階段：調整專題模板

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

第六階段：(暫不開放)

偽命名空間

小結1

小結2

捷徑空間提案

小結3

再提捷徑空間提案

嘗試推動LTA空間

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

進一步討論

自動提刪R2

MOS捷徑名稱

軟重新導向

技術問題處理

自動半保護偽命名空間

提議設立快速刪除標準 O8

將LTA空間設定為noindex

WP:捷徑指引草案修訂

說明

專題命名空間問題

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

捷徑細部修訂

擬議快速刪除方針條文增修（A2修訂）

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

針對性決議

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

重提Wikipedia:集中討論

整體說明

提議建立「元維基用戶查核指南」

修訂刪除方針第1（刪除理由）章節第9項

修訂申請成為管理人員指引第2（流程）章節投票冷靜期條款

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

關於Wikipedia:命名常規 (音樂)

Wikipedia:命名常規 (音樂)1.0更新報告

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

調適案1

歷史人物條目Infobox中的出生、死亡地點、籍貫及國家歸屬應統一使用原稱

臺灣原住民族人條目命名（第二次）

命名常規擬議修訂

原案

分案1

分案1A：簡化行文

先到先得（時間優先）

中文用詞差異的處理：先到先得

（重提）現行日期和數字格式手冊條文調適

折衷提案

關於Wikipedia:修訂版本刪除請求的RD5理由是否能適用於Wikipedia:刪除方針和Wikipedia:快速刪除方針

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

交通關注度指引修訂

修訂RD2的措辭使之更為一致

原始提案

對方針詮釋的分歧

修訂2

（更新版）國際關係條目命名常規

跨語言連結模板的偏好

模板顏色相關規範

交通關注度指引適用範圍的擴展

第二階段之公示狀態通告

第二階段之公示期討論