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

快捷方式

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

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

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

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

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

公告欄

[人事] 仲裁委員會選舉已有結果，10名用戶當選仲裁員。
[公告] 用户组自我除权、GFDL相關規範加入及WP:ITNR字眼的小修訂已經通過。
[公告] 母公司子品牌列出規範、修訂优特标准、引入WP:ONUS、修订用户名方针与用户页指引、修訂圖表説明結尾有無句號及條目“大小”不宜移動、重定向或合併到題目“尺寸”一事與變更條件正在公示，如有意見請儘快提出。
[討論] 互助客栈技术区正在討論修订过滤器警告信息，請踴躍參與討論。
[討論] 互助客栈方针区正在討論在非原創方針新增例子以禁止綜合常識及可靠來源及擴充ITNR獲選類別，請踴躍參與討論。
[討論] 互助客栈其他区正在討論是否应关闭中文维基百科以抗议基金会举措、管理人員任免制度檢討等事及本地部署安全投票及相关权限，請踴躍參與討論。
[广告] 維基百科亞洲月及其分項北亞月現正舉行，直至11月30日完結，歡迎踴躍參與！

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

存檔

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

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

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

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

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	关于WP:非原创研究方针是否适用于模板；以及判定模板为“原创研究”的客观标准	49	16	Nostalgiacn	2024-11-17 01:44
2	提议将金砖国家峰会纳入Wikipedia:新聞動態/重複發生的項目	31	11	Patrickov	2024-11-18 12:46
3	修正优特标准的翻译腔问题	29	10	自由雨日	2024-11-22 20:34
4	关于仲裁委员会职权的疑问	2	2	Ericliu1912	2024-10-27 02:16
5	仲裁委員會成立後的管理人員解任機制（續）	1	1	LuciferianThomas	2024-10-28 09:38
6	關於日本選舉的標題問題	16	5	FK8438	2024-11-18 13:02
7	关于用户名方针与用户页指引的重大修订建议	19	11	阿南之人	2024-11-19 23:33
8	修訂娛樂產業內容相關共識之藝人條目綜藝節目列表章節	21	8	CaryCheng	2024-11-18 10:50
9	討論被錯誤理解達成共識應該怎樣做？	3	1	Factrecordor	2024-11-14 21:39
10	修订政治人物关注度指引	39	12	CaryCheng	2024-11-18 12:15
11	完善WP:封禁「不限期不是永久」總方針	41	13	WiiUf	2024-11-20 18:04
12	有關簽名附帶的文字的問題（第三次）	41	9	Dryrace	2024-11-19 12:43
13	关于本地化资讯是否为琐碎内容的问题	18	6	Factrecordor	2024-11-16 20:47
14	导向重复的列表拆分逻辑是否成立？	42	3	红渡厨	2024-11-18 16:37
15	A/B分支仲裁	6	4	Iming	2024-11-19 21:29
16	关于Wikipedia:避免地域中心#地理，建议增加关于“来”字的论述	15	8	航站区	2024-11-24 11:34
17	關於非原創研究問題	45	10	HK5201314	2024-11-24 13:29
18	修订WP:外文重定向方针与首句MOS:外语名称格式指引，并将他们对应	10	4	自由雨日	2024-11-21 14:25
19	infobox nativename應否加粗	9	5	Sohryu Asuka Langley Not Shikinami	2024-11-23 15:38
20	部分基础条目是否应视为高风险主题及反破坏的方法	3	2	暁月凛奈	2024-11-23 18:57

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

正在廣泛徵求意見的議題

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

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

維基百科格式與命名

Wikipedia talk:格式手册/标点符号 § 推進圖註結尾有無句號共識

由於其餘版本被反對，擬採用並在不久後公示版本A，亦歡迎繼續評點其他版本。副知前次討論者@Lopullinen@HTinC23@捍粵者@PexEric@Evesiesta@Anghualee@InstantNull— Gohan 2024年11月5日 (二) 10:48 (UTC)

維基百科方針與指引

Wikipedia:互助客栈/方针 § 关于WP:非原创研究方针是否适用于模板；以及判定模板为“原创研究”的客观标准

現行條文

在先前有关WP:页面存废讨论中，若干编者多次以模板为“明显的原创总结”及WP:非原创研究方针提删。但这些编者没有回答区别这些模板为“原创总结”，而其他模板如 Template:生成式人工智能、Template:各国列表、Template:软件开发过程、Template:人工智能等不是“原创总结”的客观标准。
现行WP:非原创研究方针提到：

条目不应该包含有对已发表材料的新式分析和总结，如若这些分析与总结产生了原始来源中并未明确的立场。

但方针文字中未直接涉及模板。

提議條文

因以上问题，提请社群就WP:非原创研究方针是否适用于模板，以及判定模板为“原创研究”的客观标准，予以讨论和澄清。

在此讨论未完成之前，请暂缓以“明显的原创总结”及WP:非原创研究方针为由删除模板。

--Zhenqinli（留言） 2024年8月8日 (四) 08:02 (UTC)

Wikipedia talk:字詞轉換處理 § 《WP:字詞轉換處理#歷史》一章中的“模板:Tq 只能用于讨论和项目页面。请勿在条目中使用。”

“在以前有繁简两版本的文章现在仍然需要人手合并，但目前已经大致完成。”这反映的应该是中文维基百科极早期的状态了吧？应该依事实修订为“目前早已完成”或“已于20XX年完成”？--自由雨日🌧️（留言｜贡献） 2024年8月24日 (六) 16:35 (UTC)

Talk:中国地理 § 中维“中国”一词的地理意义指什么？

条目名为“中国地理”，但通篇介绍的内容不是“中华人民共和国地理”就是“中国大陆地理”——即少部分涉及主权声索等问题时实质上是在介绍中华人民共和国地理，用“中国”一词代表了“中华人民共和国”，违规；其余不涉及主权等问题时则是单纯介绍中国大陆这片区域的地理，用“中国”一词代表了“中国大陆”，违规。如果是一般的条目，只消将条目名移动至“中华人民共和国地理”或“中国大陆地理”然后明确介绍范围即可。但“中国地理”本身是极重要的“中国”类条目，更是《中国》条目《地理》章节的主条目，可以说中维必须要存在一个名为“中国地理”的条目，因为这直接关系到中维“中国”一词的“地理”涵义（类似{{中国历史}}模板和《中国历史》条目对明确中维“历史意义的‘中国’一词指什么”的重要性）。综上，该如何处理本条目？或者说，在中文维基百科，“中国”一词的地理涵义是什么？--自由雨日🌧️（留言｜贡献） 2024年9月25日 (三) 19:25 (UTC)

Wikipedia talk:可供查證 § WP:V引入en:WP:ONUS

今天看到英维的这一段我们没有，并觉得这一段方针对于日常编辑时很有引导作用，以下是我大概翻译的版本，欢迎大家编辑改善，提出自己的意见。

存在可靠来源不保证内容被收录

任何条目中收录的内容应可由可靠来源验证，但这并不代表任何可供查证的信息都应写入条目中。特定内容可能通过共识决定没有改善其条目，也可能由其他方针指出并不应写入维基百科条目。此类内容应被省略或写入其他条目。希望添加存在争议的内容的编者有义务为添加该内容形成共识。--0xDeadbeef (留言) 2024年10月13日 (日) 04:08 (UTC)

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

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

Wikipedia talk:COVID-19條目共識 § 調整COVID-19條目共識的規定

承上討論，現提議修改WP:COVID-19條目共識的表述。草案正文，差異。San mo sa _新朝雅政 2024年10月23日 (三) 02:00 (UTC)

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

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

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

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

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

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

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

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

Wikipedia talk:格式手冊/電視 § 對於剛訂立的格式手冊/電視，細節上的疑問

由於在Wikipedia:互助客栈/条目探讨#是否建立各家平台或電視台之外購動畫、節目、特攝的分類項目，日漸離題地討論剛訂立的Wikipedia:格式手冊/電視，故在此再開話題。討論的焦點在於

節目的OTT播放平台及網絡電視的節目可觀看地區均需列明來源，OTT播放平台及網絡電視平台播放清單不建議作為證明「可觀看地區」的來源，因為相關平台及播放清單通常不會明文記錄可觀看地區。若相關OTT播放平台及網絡電視平台播放清單明文記錄可觀看地區，則不受此限。

來源1號[1]：草擬人@HK5201314舉出的傳媒報道，作為符合要求的來源例子，相關內文為：「韓劇《重組家庭》於10月9日首播，共有16集，每週三連續播出2集，作為Viu Original劇集在香港、東南亞、中東及南非等16個地區於Viu網上平台獨家播出。」明確地列出了Viu平台的全部可觀看地區。

來源2號[2]及3號[3]：我所舉出的傳媒報道，不全面，相關內文為：「也特別聯合9大平台，中華電信MOD/Hami Video、LINE TV、遠傳friDay影音、巴哈姆特動畫瘋、MyVideo、KKTV、Muse木棉花-TW/Muse木棉花-HK、霹靂電視台、PILI線上看等，回顧《Thunderbolt Fantasy 東離劍遊紀》第1~3季及2部劇場版的精彩內容。」「首播平台爭戰最終敲定於4月3日開始，每周六晚間9:30於6大影音平台CATCHPLAY、遠傳friDay、台灣大哥大 myVideo、MOD中華電信、Hami Video與官方PILI線上準時播映。」我認為這些針對台灣地區的來源，已等同代表可觀看地區包括台灣，雖然沒有提及台灣以外（也許Muse木棉花-TW/Muse木棉花-HK除外）有哪些可觀看地區，但條文也沒有明文規定必須在來源的情況下列出全部「可觀看地區」才算及格，那麼就算只証明部分「可觀看地區」，也無不可。

它們都可算第三方來源，但相信當中的平台播放資訊都是來自宣傳稿，當然1號是平台本身的宣傳，2-3號是作品本身的宣傳。

相信訂立條文的精神，本是希望禁止羅列一些不三不四的盜版平台，以及對數量可能會太多的播放資訊進行適度篩選。我擔心過度執著証明平台所有地區版權，會變得本末倒置，不能公平地作出真正有效的篩選。我意思維基認為可用或不可用的驗證方法，對平台、對作品製作方、對傳媒、對觀眾來說，往往都未必需在意的事。一個平台的操作介面和宣傳稿，如果剛好習慣很明顯地顯示全觀看地區，它就會僥倖地在維基得到優勢，其他平台縱使合法性、覆蓋性相當，純粹因顯示區域的習慣不迎合，就不能寫，若在這種情況不能坐視不管。我們要做的是觀察各方普遍的習慣，從中拿捏出反映現實又寬緊恰當的篩選準則。如果我們定的準則，只是看誰的習慣僥倖地較能迎合，那就不是一個好的準則，應當修改。

另外，草擬人指出已通過的規則比英維更嚴，這是和某幾位參與者討論後，才越來越嚴格的。當時我不是持續關注那討論，但印象是積極發言者多是希望從寬。所以，懷疑大家對共識內容的解讀會有很大差異，需召集大家回來看看。--Factrecordor（留言） 2024年11月2日 (六) 18:19 (UTC)

Wikipedia talk:格式手册/标点符号 § 推進圖註結尾有無句號共識

由於其餘版本被反對，擬採用並在不久後公示版本A，亦歡迎繼續評點其他版本。副知前次討論者@Lopullinen@HTinC23@捍粵者@PexEric@Evesiesta@Anghualee@InstantNull— Gohan 2024年11月5日 (二) 10:48 (UTC)

Wikipedia talk:维基百科不是什么 § 提請修訂維基百科不是什麼中的旅遊指南，新增「建築物附近交通資訊」的規管

現行條文

旅遊指南。例如，關於巴黎的條目應該敘述艾菲爾鐵塔、羅浮宮等名勝，但您最喜歡的酒店的電話號碼、香榭麗舍大道賣的牛奶咖啡的價錢……都不是適當的內容。維基百科不是建立酒店或美食指南、遊記等內容的地方。知名城市可能符合收錄標準，但最終條目不必包括每個旅遊景點、餐館、酒店或場地等。雖然每個城市的旅遊指南通常會提到鄰近城市的景點，但維基百科的每個城市條目應該僅列出實際位於該城市的景點。如果您確實希望幫助編寫旅行指南，我們非常歡迎您為我們的姊妹專案維基導遊做出貢獻。需要注意的是，出於著作權上的考慮，請勿隨便抄錄其他文字，除非您是著作權持有者。

提議條文

旅遊指南。例如，關於巴黎的條目應該敘述艾菲爾鐵塔、羅浮宮等名勝，但您最喜歡的酒店的電話號碼、前往那間酒店的交通資訊、香榭麗舍大道賣的牛奶咖啡的價錢……都不是適當的內容。維基百科不是建立酒店或美食指南、遊記等內容的地方。知名城市可能符合收錄標準，但最終條目不必包括每個旅遊景點、餐館、酒店或場地等。雖然每個城市的旅遊指南通常會提到鄰近城市的景點，但維基百科的每個城市條目應該僅列出實際位於該城市的景點。如果您確實希望幫助編寫旅行指南，我們非常歡迎您為我們的姊妹專案維基導遊做出貢獻。需要注意的是，出於著作權上的考慮，請勿隨便抄錄其他文字，除非您是著作權持有者。

目前，許多香港建築物條目均設有公共交通路線資料，讓遊客可透過維基百科了解如何前往該座建築物。但是，這不應是維基導遊及Google Map的職責嗎？於是建議新增這句「前往那間酒店的交通資訊」。位置已透過粗體標示出來了。--唔好阻住我愛國（留言） 2024年11月5日 (二) 11:03 (UTC)

維基百科提議

Wikipedia:互助客栈/其他 § 為管理人員任免制度檢討等事

近期又一管理人員解任投票，甫應用安全投票之新制，技術實務運作尚難稱熟稔；又逢顯著外來干涉及共識形成程序疑慮，遂致前所未有之困窘，亂象叢生、弊端頻出，社群矛盾對峙趨於激烈，此實無庸置疑。與此同時，定期審視更新管理人員任免制度，有助於人才新陳代謝，充實本站進階維護量能。時值仲裁委員會組織籌備停滯之際，「遠水難救近火」，故謹以此話題為首，先行就管理人員任免制度若干既存問題略作檢討，望社群踴躍發表意見。改革路程自不必操之過急，但求氣象有所更新爾。本人謹提出三個大問題，社群可撥冗予以回應，或自行提出其他值得專門討論之問題。—— Eric Liu_{創造は生命（留言・留名・學生會）} 2024年8月18日 (日) 18:29 (UTC)

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

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

原标题：SecurePoll elections with the electionadmin right

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

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

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

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

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

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

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

Wikipedia:互助客栈/其他 § 仲裁委員選舉結果

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:仲裁委员会/选举/2024年。

仲裁委員選舉已有結果，請參看Wikipedia:仲裁委员会/选举/2024年#結果，10名用戶當選為仲裁員。謝謝。--A T 2024年11月15日 (五) 17:31 (UTC)

專題命名空間

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

Wikipedia:名字空间/2021年設立新命名空間及偽命名空間

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

已通過：

已

公示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)[回复]
測試結果見此[4]，以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好像有点问题。[5]，页眉显示名字空间侦测错误，不知道是什么情况 ——羊羊 (留言|贡献) 2021年1月28日 (四) 01:50 (UTC)[回复]
- ns:102也有这个问题…… ——羊羊 (留言|贡献) 2021年1月28日 (四) 02:04 (UTC)[回复]
  切换到非中文en界面就不报错[6]--百無一用是書生 (☎) 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)[回复]

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

各階段不得同時討論，前一項討論完結之後，才能進行下一段討論。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 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)[回复]

第四階段：調整專題模板

已完成：

已修改完大多數相關模板。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 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)[回复]

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

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

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

第六階段：(暫不開放)

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

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

偽命名空間

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

Wikipedia:名字空间/2021年設立新命名空間及偽命名空間本案討論格式手冊及長期破壞者提升問題。目前有三案：

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

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

技術問題處理

命名空間偵測模板以及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)[回复]

自動半保護偽命名空間

我很難說有多少人會去破壞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)[回复]

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

WP:捷徑指引草案修訂

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

Wikipedia:名字空间/2021年設立新命名空間及偽命名空間

說明

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

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

本討論的各階段分為：

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

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

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

專題命名空間問題

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

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

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

完成技術的部分已完成大部分的設定，剩下制度完善的部分。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月25日 (四) 05:48 (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)[回复]

建议删除姓氏分类

如题，如果连姓氏（如[[Category:刘姓]]）都要分类，那就没有理由不加[[Category:布什姓]][[Category:史密斯姓]][[Category:史蒂文斯姓]][[Category:詹姆斯姓]][[Category:山口姓]][[Category:小泉姓]][[Category:弗朗索娃]]……--7（留言） 2021年2月5日 (五) 07:57 (UTC)[回复]

我給予(＋)支持，畢竟這算是過度分類。但這件事情很「重大」，應該讓更多的用戶才是（尤其是那些很少來互助客栈的編輯們），我可不想被人在背後說閒話說我們是維基小圈圈。 --無心*插柳*柳橙汁 2021年2月5日 (五) 08:07 (UTC)[回复]

我個人確實也是覺得姓氏分類的設立的必要性不大，而且也難以盡收，做不到分類的應有功能。我在{{bulletin}}把這直接設為社群調查好了，這樣大家直接看到和關注到這討論。如果結論是（基本）刪除姓氏分類的話，部分模板可能也要連帶調整。SAN MO SA _SPQR 2021年2月5日 (五) 10:09 (UTC)[回复]

(＋)支持毫无意义的一个分类，虽然会有很多条目因此又少一个分类。

--懒癌哪天行_{→Lazy, as no today's excuse.} 2021年2月5日 (五) 13:29 (UTC)[回复]

(＆)建議导入并以维基数据取代，天然的结构化数据，维基数据还能提供约束、组合查询、参考来源（例如特定人物姓氏之争议和变动）等多重功能。但在此之前，应了解使用此种分类的模板、机器人或其他用者，做适当更新。其实生卒地、生卒时间等分类也能维基数据化、细化，但究竟哪种更方便查阅和维护，值得考量。--YF dyh000（留言） 2021年2月5日 (五) 14:41 (UTC)[回复]

同意匯入至維基數據（其實很多東西都可以由維基數據代勞，其他Wikipedia都有更大程度調用維基數據的情形）。SAN MO SA _SPQR 2021年2月6日 (六) 08:54 (UTC)[回复]

同意使用维基数据處理。 --無心*插柳*柳橙汁 2021年2月6日 (六) 11:38 (UTC)[回复]

基本支持刪除姓氏分類，但是同時要注意像Category:范陽盧氏、Category:足利氏或Category:肯尼迪家族等相對於單純姓氏分類要來得關係密切的分類，兩者不應混為一談。--A T 2021年2月6日 (六) 12:00 (UTC)[回复]

天天wikidata，请问都已经2021年了，到底搞出了什么工具？。->>Vocal&Guitar->>_留言 2021年2月6日 (六) 12:14 (UTC)[回复]

大体(＋)支持。顺便一提，金城武条目曾被加入Category:金姓。--Wcam（留言） 2021年2月6日 (六) 14:06 (UTC)[回复]

~~基本(＋)支持提議~~，但要做好配套措施。—— Eric Liu_{創造は生命（留言．留名．學生會）} 2021年2月6日 (六) 14:59 (UTC)[回复]

仔細權衡之後，個人對此提議的立場改為(＝)中立。—— Eric Liu_{創造は生命（留言．留名．學生會）} 2021年2月7日 (日) 13:35 (UTC)[回复]

确定要把姓氏分类都删掉吗？有时候对读者还是有帮助的吧。比如说我记得某个历史人物姓司徒，但是名字记不得了，可以从 Category:司徒姓里查一查；或者说，我只记得某个人叫刘某光，我可以去 Category:刘姓里去找。“中文维基没有 Khrushchev姓分类，所以要把毛姓分类删掉”、“刘姓人物没有全部列入刘姓分类，所以刘姓分类应该删掉”这样的论证恐怕有问题。--如沐西风（留言） 2021年2月7日 (日) 06:36 (UTC)[回复]

我认为可以在姓氏条目底部用外链模板（类似{{commonscat}}）形式提供维基数据的查询入口。反正普通用户更容易查找到条目而非分类，所处位置相近，维基熟手熟悉后也容易找到。--YF dyh000（留言） 2021年2月7日 (日) 07:05 (UTC)[回复]

前提是维基数据提供有中文化、易于理解的查询界面，未在那边活跃所以目前不太清楚。如果共识允许，也可站内开发一个toolforge上的工具来提供这种查询、组合查询功能。如果这种方案能解决查阅用法，可能不再影响共识形成。--YF dyh000（留言） 2021年2月7日 (日) 07:17 (UTC)[回复]

(－)反对。其他族群、國家狀況如何我不清楚，但在華人地區姓氏宗族仍然是一個不可忽視的社會現象。舉一個不算大的姓氏詹姓為例，不但中國大陸、臺灣、新加坡、馬來西亞等地都有宗親會，會舉辦大型祭祖活動、懇親會、跨地域交流、經貿投資等活動，更在地方政治中扮演一定角色，只是比較少編者著手於這方面而已，否則媒體報導其實不少、各地宗親會、民俗學會、姓氏文化研究會也都有相關論述。又以上現象並不適合用家族概括，以上面提到的臺灣苗栗卓蘭鎮為例，當地詹姓是由廣東饒平詹姓加上後來移入的彰化永靖、竹塘詹姓組成，宗族發展至今也有一百多年，是跨越家族的現象。

我認為現在姓氏分類看來累贅的原因是沒有向下細分、缺乏相關條目統合，如果把既有各地家族史、宗族史研究（以樓主舉例的劉姓而言，有看到有人編《湖南刘氏源流史》這種書）、宗族文化（既有各地宗族聚居地及相關建築，未來可能建立的各地各姓族譜、各宗親會）等條目、分類建立起來其實相當可觀，長遠來說朝鮮半島、越南、日本等東亞文化圈成員也可能建立類似條目，故我在此反對刪除。--迴廊彼端（留言） 2021年2月7日 (日) 06:34 (UTC)[回复]

如上方AT所说，家族分类与单纯姓氏分类最好区别对待，家族分类应该保留。家族相关信息写成条目比分类更易维护和查证。姓氏分类细分的可维护性其实很差，比如可能有人写“1990年出生的刘姓人”、“刘姓足球运动员”这种完全没必要且增加查阅和维护难度的分类。--YF dyh000（留言） 2021年2月7日 (日) 07:08 (UTC)[回复]

@YFdyh000：家族跟宗族在嚴格定義上並不相同，適用宗族而非家族的案例我已在上方提及，又您說的維護問題確實有道理，但真要比較難維護，年份分類因為時間細分、收納事物更多更加辛苦，隨手抓個Category:1999年就可以看到一堆疊床架屋的分類，依此邏輯年份分類是否也應刪光？--迴廊彼端（留言） 2021年2月7日 (日) 08:10 (UTC)[回复]

是不同。其实这事急不得，我提议维基数据也只是一个方向，至少得将维基数据充实起来、大家看看效果，再说代替原有分类之事。如果有人单纯提议移除现有的姓氏分类，我也不太赞成。如果维基数据的效果佳，能代替不少叠罗汉分类，但那是长期目标。大家可以先发表意见和疑虑。--YF dyh000（留言） 2021年2月7日 (日) 08:18 (UTC)[回复]

@YFdyh000：謝謝您，我也期待維基數據給百科創造更多新的可能。--迴廊彼端（留言） 2021年2月7日 (日) 08:28 (UTC)[回复]

再附帶一點，對大的姓氏來說，姓氏分類可以增加收錄「Cat:各省O姓」、「Cat:O姓宗親會」、「Cat:O姓聚居地」等等子分類，對小姓氏來說姓氏分類則可能更加重要。例如臺灣三姓姓氏起源明確但人數較少，短期內可能很難有宗族研究支持，如果此新聞中提及的三先生有天符合關注度可以建條目了，便可以由其傳記中反映出三姓的發展，彌補既有研究不足之處。--迴廊彼端（留言） 2021年2月7日 (日) 07:09 (UTC)[回复]

附帶第二點，把姓氏分類拿掉最核心的是分類樹斷裂問題。參照Wikipedia:頁面分類#什么时候用页面分类，分類存在的意義之一是讓用戶用關鍵字快速進行瀏覽；如果沒有Category:王姓分類輔助，我看完王姓條目後很可能不會意識到還有Category:王姓家族、Category:王姓宗祠這些相關分類存在，一來增加查閱難度，二來濫建同義、平行條目跟分類也會增加。--迴廊彼端（留言） 2021年2月7日 (日) 08:28 (UTC)[回复]

(－)反对作推论不要滚雪球，“没有理由不加xx姓”并不能从“加了xx姓”这个前件中推出。还有就是这个分类并没有抵触任何东西，再强调一下：不是一个人觉得有没有意义就可以决定一件事是否有意义。目前最上层的姓氏分类可以帮助人找到这个姓氏下有怎样的单个郡望家族，稀有姓氏的分类更加可以帮助人看出这个姓氏是否在一个地区聚居，总之是很有用处的。----𢿃𠫱（留言） 2021年2月7日 (日) 08:34 (UTC)[回复]
因维基数据少人做事，目前不太可行，如果要刪的話請建立機械人刪除並有熱心人去作维基数据，不然用人肉一一刪除的話只是給貓掛鈴鐺。--Outlookxp（留言） 2021年2月7日 (日) 13:28 (UTC)[回复]
然而對於維基數據，我始終不知道到底要怎麼運用啊！請問有沒有人現在能告訴我，如果刪除了所有中文姓氏分類，而我想知道「除了是元介以外，中維還有哪些是姓的人物條目？」（因為這個姓很罕見，所以好奇），我該如何透過維基數據得到答案？另外，若不限中文姓氏，我可以透過維基數據知道竹野內豐以外的竹野內姓人物、藥師丸博子以外的藥師丸姓人物、蓮佛美沙子以外的蓮佛姓人物、舛添要一以外的舛添姓人物、本假屋唯香以外的本假屋姓人物嗎？若可以，請教要怎麼操作？這些日本罕姓我也很好奇。-游蛇脫殼/克勞棣 2021年2月7日 (日) 14:03 (UTC)[回复]
- 是姓；藥師丸目前只有一条数据；竹野内姓、莲佛姓等数据缺乏。右侧栏-可视化编辑，可以自己搜。更易用的可视化工具可行、可开发。谈代替还早，可以互补和倡议。相比在中文维基维护姓氏分类，利用和填充维基数据设施对未来的各方面有利。--YF dyh000（留言） 2021年2月7日 (日) 14:25 (UTC)[回复]
查询服务-示例正在中文化，欢迎尝试。也计划引入更多维基数据模板、放入条目。--YF dyh000（留言） 2021年2月8日 (一) 18:45 (UTC)[回复]

可是有時候要查某些名字的時候，姓可以查的到，所以也不是完全沒有用吧--愛偷懶的魚🐠※留言 2021年2月9日 (二) 08:12(UTC)

没有听懂，您的意思是从分类找出自己想找的人物？对于常见大姓这会很难，因为成员太多、条目名简繁体不转换，且常难确定是否存在条目（如果有查阅过的印象还好）、是否有姓氏分类（目前加入率还挺高的）。如果是找冷门姓氏人物，站内搜索和维基数据都可以。--YF dyh000（留言） 2021年2月9日 (二) 08:27 (UTC)[回复]

是阿，比如說我記得某個歷史人物姓，但是名字記不得正確的名字了--愛偷懶的魚🐠※留言 2021年2月9日 (二) 08:57(UTC)

感情您都能代表一般读者？一般读者人人都知道有维基数据这个东西？一般读者都会使用语法搜索？把这个拿出来放在一般读者眼前他们会有什么反应？我一点都不反对甚至大力支持利用维基数据，可就现在的数据沟通、迁移、取用和修改，远达不到基本的需求，更不可能改善体验。->>Vocal&Guitar->>_留言 2021年2月10日 (三) 04:29 (UTC)[回复]

(※)注意如果您仔细看了上方讨论，应该能注意到，我的观点是建议替代+不赞成目前移除。--YF dyh000（留言） 2021年2月10日 (三) 12:21 (UTC)[回复]

(：)回應所以您的意思是逐步替代，以便將來移除姓氏分類嗎？另外，請教讀者要如何用站內搜索找到某冷門姓氏人物的條目？是用special:前綴索引嗎？-游蛇脫殼/克勞棣 2021年2月10日 (三) 15:25 (UTC)[回复]

是，因为大姓氏的分类难以细分和查阅，同时维基数据可提供同类型的数据、精细管理。是，特殊:搜索和特殊:前缀索引，如果大家着重在意“冷门”姓氏的查找，冷门姓氏在特定阶段和条件（如<200个条目或者尚无姓氏条目）保留分类也是可行的。--YF dyh000（留言） 2021年2月10日 (三) 15:56 (UTC)[回复]

还有药师丸悦子（相对性理论）和她爹，附(－)反对--E.A.Crowley6 6 6^✍️ 2021年2月13日 (六) 05:27 (UTC)[回复]

(－)反对姓氏分类的作用现时无法由其他方式替代。佛祖西来（留言） 2021年2月10日 (三) 17:56 (UTC)[回复]
問題在於這並不是分類該有的作用。SAN MO SA _SPQR 2021年2月11日 (四) 00:47 (UTC)[回复]
那請教@Sanmosa：您認為分類該有的作用是什麼呢？也期待您回應上面如沐西风的觀點：“刘姓人物没有全部列入刘姓分类，所以刘姓分类应该删掉”这样的论证恐怕有问题--迴廊彼端（留言） 2021年2月11日 (四) 02:02 (UTC)[回复]
1.赞成标题和某些论证不算合理。2.赞成目前不是“删除”分类的时机，但讨论利弊是有价值的。3.可以试试，直接从Category:刘姓找出刘太公大约需要几步，是否达标。--YF dyh000（留言） 2021年2月11日 (四) 13:30 (UTC)[回复]
@YFdyh000：如果維基能開發多重分類檢索功能，也就是同時篩檢符合cat:秦朝人和cat:劉姓的所有條目（當中也就一定包含了刘太公），將會是很偉大的貢獻。假如我想找一個姓劉的秦朝人，這樣一檢索就檢到了。-- love.wh _{大河浪浪寬} 2021年2月20日 (六) 18:14 (UTC)[回复]
WP:PETSCAN。但我覺得這個更像是資料庫的職責。--洛普利宁 2021年2月21日 (日) 14:41 (UTC)[回复]

關於Wikipedia:命名常规#使用外文命名时的专门要求，請問音樂作品名稱是否能算是專有名詞？

近日我和用戶U:KodokunaSmile在外文名稱條目上有不同意見。對於〈HANN (Alone)〉，我表示「按照常用習慣」應該命名為〈Hann (Alone)〉，而KodokunaSmile大則表示「音樂標題應也可以視為專有名詞」，認為應該命名為〈HANN (Alone)〉，歡迎各位維基人參與討論，覺得音樂條目的命名是否該被視為專有名詞。 --無心*插柳*柳橙汁 2021年2月6日 (六) 11:32 (UTC)[回复]

为什么不是？。->>Vocal&Guitar->>_留言 2021年2月6日 (六) 12:02 (UTC)[回复]
- @Ohtashinichiro：因為如果是的話，那麼這條根本沒有必要存在，因為大家都是專有名詞對吧（要這麼嚴格說的話）。而且不說我，翻看過去的移動日誌，有能看到許多類似理由的移動（例如U:Leehsiao）。 --無心*插柳*柳橙汁 2021年2月6日 (六) 13:26 (UTC)[回复]
- 就用形成的例子，KMT (歌曲)，這是因為他是Kiss My Teeth的縮寫所以可以全大寫。反之More (K/DA歌曲)、Toy (歌曲)還有Ddu-Du Ddu-Du都不行。 --無心*插柳*柳橙汁 2021年2月6日 (六) 13:31 (UTC)[回复]
  - 你把enwiki的命名常规拿来这里说不行，还有什么需要讨论的？。->>Vocal&Guitar->>_留言 2021年2月6日 (六) 23:54 (UTC)[回复]
    - @Ohtashinichiro：我沒有拿英維的命名常规，我用的中維，你要不要看看Wikipedia:命名常规到底寫了甚麼？就拿我上面提到的例子，這三個英文名稱哪一個是專有名詞？ --無心*插柳*柳橙汁 2021年2月7日 (日) 05:21 (UTC)[回复]

作品標題理應是「專有名詞」，而不可能是「普通名詞」。--【和平至上】^{支持通過港區國安法}💬 2021年2月6日 (六) 20:11 (UTC)[回复]

不認為音樂作品的標題是專有名詞，專有名詞的意思是專有獨一的，如果音樂作品的標題使用的都是既有的英文字或不存在必要全部大寫的特殊意義，則不應該使用這種所謂的藝術字體，應該按照首字母大寫其他字母小寫規範使用。——Leehsiao（留言） 2021年2月7日 (日) 03:00 (UTC)[回复]

「HANN (Alone)」／「HANN」是完整的專有名詞，前者的「(Alone)」非出於消歧義而為之。我認為作「HANN (Alone)」或「HANN」也可。SAN MO SA _SPQR 2021年2月7日 (日) 03:52 (UTC)[回复]

鑒於現在意見膠著，看來是時候請其他音樂發燒友發表一下意見，@Zhaoweizhi0325、MoonLight3650、HXXXX、Punkhippie、Louis0921gee、Peace 621、Whykitty、AT：@Yumeto、Moonshimmer93、Gracelllee、TreasureBabe325、Hijk910、Jacklamf1d14、Easterlies、Naverad、Softyu、夜来南风起：@Pseudo Classes、生米一粒、百战天虫、Sammypan、Tw drama、Shingkei、Tombus20032000、Kriz Ju：，究竟各位覺得音樂作品名稱是不是專有名詞？ --無心*插柳*柳橙汁 2021年2月7日 (日) 15:27 (UTC)[回复]

傾向贊同Milkypine的看法--Tom......（留言） 2021年2月7日 (日) 15:40 (UTC)[回复]

从语言学意义上讲，音乐作品名称并不是严格意义上的专有名词。英文维基专有名词和普通名词的intro第一句话就讲了，专有名词用来辨认和指明单个实体，具体例子是伦敦、木星、沙拉或者微软，而与之对应的是普通名词，用来辨认和指明一类实体，比如一座城市的“城市”、另一个星球的“星球”、这些人的“人”、我们的公司的“公司”。那么按照这条标准，音乐作品名称可以是专有名词，也可以是普通名词。专有名词的情况下，这个音乐作品名称必须只有一个实体，通俗点说就是只有一首用这个歌名。常见的，比如说各国的国歌，肯定是专有名词了吧，因为国歌是一个国家的代表形象，很少有人会创作和国歌重名的乐曲，所以这类歌曲是专有名词；另外，诸如《命运交响曲》、《威风堂堂进行曲》等有广泛认知度经典古典音乐可能也属于专有名词，现代的乐曲很少会和这些名曲重名。至于流行乐曲，歌名重复的作品太多，单单以“火”作为曲名的歌曲就有几十首（英语：Fire_(disambiguation)），所以绝对不是专有名词，而前面提到的《命运交响曲》的正式名称《第5号交响曲》也肯定不是专有名词了。不过，需要注意到的是，上述的分析只是在音乐作品范围内进行，因为很多时候有些音乐作品的名称会出现在其他领域。最明显的，“马赛曲”除了是法国国歌以外，还可以指法国的一幢同名摩天大楼（英语：La Marseillaise (skyscraper)）。所以，如果没有明确证据显示作品的名称只用在音乐方面，只有一支音乐作品使用，否则无法判断它到底是不是专有名词。有鉴于这个问题的判定有难度，我主张曲名不是专有名词，除非有证据证明这个曲名只有唯一一支作品在使用。所以问题提到的那首歌曲应该命名为《Hann (Alone)》，《HANN (Alone)》只是风格化表现手法，有夸张、强调的效果，英文版也写了“stylized as "HANN (Alone)”。--百战天虫（留言） 2021年2月7日 (日) 16:54 (UTC)[回复]

敝人無甚創建音樂條目，僅以個人意見參照相關資訊思索一陣後，認為爭議頗大。後認同天虫閣下之分析和理據：作品字體之風格化表達不等於該字詞為專有名詞，而現有方針內規範的用意應該是期許編者盡可能在命名時抱持「以中文優先、還原英文一般行文慣例次之」的思維。竊以為「HANN」應該是韓文（한）的音譯寫法，如果英文中沒特別規定的話（個人沒研究），按方針所言「部分語言在羅馬化後沒有對於大小寫的規範，此時參照英文的規則處理。」，所以可能寫成「Hann」即可。不過個人較偏好把作品名稱大小寫按其原樣呈現就是了（忽略一切規則的原創方針？），如此或也最少爭議且能直接為讀者所熟悉（不論視覺或查找時的熟悉感），只是現有方針似乎並非如此。

個人認為在日常生活中，平時遇到作品名稱應視為專有名詞，原文怎麼寫就該怎麼寫，而現有方針規範和條文字面設定範疇似容易造成眾熱心編者適用和解讀不一（究竟何為「專有名詞」？）。--Kriz Ju（留言） 2021年2月7日 (日) 18:22 (UTC)[回复]

中維沒有音樂命名常規，現行的方针也沒有明確規定。拿我上面提到的例子來講，More (K/DA歌曲)是副詞而Ddu-Du Ddu-Du是...形聲字？這兩個名稱不管怎麼樣都不是「專有名詞」，但如果將範圍套用到作品上，這些名稱只要「剛好是」作品名稱就可以被視為專有名詞，但問題是副詞不是專有名詞，現有方針也沒有這樣的規定，直接認定「作品名稱等於專有名詞」算不算原創研究。 --無心*插柳*柳橙汁 2021年2月8日 (一) 04:06 (UTC)[回复]

算的，敝人的原創研究（笑，沒啦）。那些「單字」常常不是專有名詞，而作品的命名呈現其實在現行規範中已有大致的習慣了，所以純粹是竊以為個人於日常生活中偏好原汁原味呈現作品名稱爾，不過這跟維基百科現況不一樣。所以就看眾熱心編者平時逕依現行方針命名即可，或是要特別提議修改規範（自然較費工，如柳橙閣下所言目前這兒沒有特別通用的音樂作品命名規範）。其實就是命名的習慣偏好吧，個人意見爾（若沒人要提新案其實依慣例應該最簡便 ---＞懶散的維基態度）。--Kriz Ju（留言） 2021年2月8日 (一) 16:42 (UTC)[回复]

不認同百戰天蟲的說法，否則人名都不能是專有名詞；但要注意專輯封面上的大小寫不一定是歌曲名稱本身，應以Plain text裏的用法為準。（例如音樂播放網站的標題等）；若大小寫未統一則另說，但若統一或者用法頻率懸殊，應依照原來的大小寫寫法。--【和平至上】^{支持通過港區國安法}💬 2021年2月11日 (四) 15:02 (UTC)[回复]

看下来觉得两边都有道理啊。然后再看了下油管官方用的是HANN(Alone)，中间没有空格，亚马逊用的是HANN (Alone)，中间有个空格，还有用HANN之后括号里没有Alone只有韩文的。所以这样就把问题更加复杂化了。然后看了下别的语言中这个条目名称的用法，发现除了泰语是翻译成当地语言之外，别的都是用的Hann (Alone)。所以，如果用HANN(Alone)，就是跟官方命名的用法保持一致（但是官方本身用法就有歧义）。如果用Hann (Alone)，就是跟维基别的条目的风格保持一致。我现在倾向于跟别的维基条目的风格保持一致的用法Hann (Alone)。生米一粒（留言） 2021年2月7日 (日) 19:30 (UTC)[回复]
- 就一般情況下，將韓文羅馬化會用Hann表示（例如billboard和applemusic不寫成HANN而是Hann[7][8]），之所以會有大寫也主要是官方youtube名稱的關係。按現行方針，條目名稱主要根據常用名稱，但這裡的常用名稱是兩個都有。 --無心*插柳*柳橙汁 2021年2月8日 (一) 04:06 (UTC)[回复]

不認為是專有名詞。空氣小貓（留言） 2021年2月8日 (一) 04:46 (UTC)[回复]

其實無論是否是韓國音樂作品，許多音樂作品其條目命名都有大小寫未統一的情況，有些是根據英維的規範有的是根據官方使用，所以希望這部分有個明確規範出來，方便後來者有個依循。～立ち直り中^ಇ 2021年2月8日 (一) 05:02 (UTC)[回复]

不应该是专有名词，该小写就小写。--东风（留言） 2021年2月9日 (二) 02:34 (UTC)[回复]

統計一下目前大家的意願。根據Ohtashinichiro大的發言，我將其算在「認同」，Sanmosa大主要是討論該案例所以列在「不清楚」。這裡在邀請一次沒回應的人@Zhaoweizhi0325、MoonLight3650、HXXXX、Punkhippie、Louis0921gee、Peace 621、Whykitty、AT、夜来南风起、Fake12345：@Yumeto、Moonshimmer93、Gracelllee、TreasureBabe325、Hijk910、Jacklamf1d14、Naverad、Softyu、SickManWP、Sammypan：@Tw drama、Shingkei、李新阳、羊羊32521、CHih-See Hsie、卡達、Pv163、JoJo_append：希望能早點達成共識解決。 --無心*插柳*柳橙汁 2021年2月11日 (四) 13:30 (UTC)[回复]

傾向認同	傾向反對	不清楚/無傾向
Ohtashinichiro、和平至上	Milkypine、Leehsiao、Tombus20032000、百战天虫、Pseudo Classes、Easterlies、生米一粒、Kriz Ju	Sanmosa、KodokunaSmile、Bigbullfrog1996

題外話，不管是官方名稱還是常用名稱都必須依照Wikipedia:命名常规。哪怕官方名稱是「大寫」也會因為不屬於「專有名詞、部分縮寫等總是大寫的詞」而按照「參照英文的規則處理」。 --無心*插柳*柳橙汁 2021年2月11日 (四) 13:30 (UTC)[回复]

柳橙閣下，您好像搞錯了吧....。敝人的意思應該是偏向反對，畢竟目前沒人提案修改。--Kriz Ju（留言） 2021年2月11日 (四) 13:33 (UTC)[回复]

而生米閣下也是傾向反對，Smile閣下看似期待新提案；目前如果沒人有更多想法，看起來是依原方針解讀命名。--Kriz Ju（留言） 2021年2月11日 (四) 13:44 (UTC)[回复]

我的意見是遵照官方寫法，官方寫法因為語言等問題顯得不明確的話，那應該依從常用名稱的寫法，仍然無法判斷的情況下則頭文字大寫，其他小寫就好。--A T 2021年2月11日 (四) 13:44 (UTC)[回复]

意見(▲)同上。--🍫巧克力～✿ 2021年2月12日 (五) 00:38 (UTC)[回复]

(▲)同上 Konno Yumeto ^恭賀新春 2021年2月12日 (五) 05:15 (UTC)[回复]

@AT、卡達、Yumeto、SickManWP：以官方發表的名稱優先是個很好的方法，但遇到像〈HANN(Alone)〉這樣的例子應該如何處理？我這邊列出幾個官方、Youtube還有幾個音源網站。

雖然我有列出官方網站，但符合嚴格條件的只有〈YESTERDAY LOVE〉〈HANN(Alone)〉，〈you broke me first〉是新聞稿而〈willow〉是官方推特。另外不是許多唱片公司都有作品清單，Youtube遇到沒有出MV的歌曲會失去參考價值，音源網站除了Apple比較多元其他都有地區性。 --無心*插柳*柳橙汁 2021年2月12日 (五) 14:12 (UTC)[回复]

請問該以哪個官方發表名稱為優先度

官方名稱＼作品名稱	you broke me first	willow	YESTERDAY LOVE	HANN (Alone)
官方網站	you broke me first[9]	willow[10]	YESTERDAY LOVE[11]	HANN(Alone)[12]
官方Youtube	you broke me first[13]	willow[14]	YESTERDAY LOVE[15]	HANN(Alone)[16]
Apple Music	you broke me first[17]	willow[18]	YESTERDAY LOVE[19]	Hann (Alone)[20]
Spotify	you broke me first[21]	willow[22]	不支援	HANN (Alone)[23]
mora	you broke me first[24]	willow[25]	YESTERDAY LOVE[26]	HANN (Alone)[27]

我不清楚韓國是否不會隔空格，否則我認為沿用HANN(Alone)沒有什麼問題，如果韓國是不會隔空格的話，那可以用HANN (Alone)。--A T 2021年2月12日 (五) 14:21 (UTC)[回复]

@Milkypine：容我

吐槽一下，閣下如果是要參閱韓樂相關的話，應該找的會是Genie音樂、Melon、Soribada（英语：Soribada）等平台吧？--🍫巧克力～✿ 2021年2月12日 (五) 14:23 (UTC):::[回复]

@卡達：我沒有寫Genie、Melon、Soribada、Bug、Flo甚至Gaon是因為《HANN(Alone)》都用韓文表示，而使用韓文肯定不符合，所以我才列出日本。 --無心*插柳*柳橙汁 2021年2月13日 (六) 07:51 (UTC)[回复]

我認為這一情況，應該為音樂專輯或歌曲的命名規則訂立一個特別的指引。我認為有些特殊情況（例如官方發表的名稱是完全細草，而命名空間不支０持小草開頭）可以例外，將第一個字改成大草，利用Displaytitle將名稱顯示為小草。至於以上的命名意見，本人意見同AT。--SickManWP_{歡迎參與♥️邊緣人小組的活動·✏簽到}發表於 2021年2月12日 (五) 15:01 (UTC)[回复]

@SickManWP：介紹一個模板：{{lowercase}}。－hiJK910 ^七一_七二一 2021年2月16日 (二) 18:15 (UTC)[回复]

我個人認為命名的次序應該以官方發表的名稱優先。在命名此類條目前，需要了解音樂/歌曲的名稱是否有背後的意義。以HANN為例，這首單曲的官方名稱為全部大草，因此我認為應該以「HANN (Alone)」為條目的名稱。至少是否專有名詞，我認為音樂類的條目應以特別方式處理，應該視為專有名詞。--SickManWP_{歡迎參與♥️邊緣人小組的活動·✏簽到}發表於 2021年2月11日 (四) 13:47 (UTC)[回复]

抱歉，在下比较熟悉古典音乐，对现代音乐不是很了解。窃以为歌曲名称是专有名词，但这种故意写成大写的应该“打回原形”。 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年2月12日 (五) 06:38 (UTC)[回复]

当然属于专有名词。这个属于著作人格权，不应该被某些维基的规定覆盖，更没有在此讨论的必要。--E.A.Crowley6 6 6^✍️ 2021年2月13日 (六) 05:36 (UTC)[回复]

某些鬼畜的条目名称可以处理，比如（tItLE，如果真的有人用）但displaytitle必须改--E.A.Crowley6 6 6^✍️ 2021年2月13日 (六) 05:58 (UTC)[回复]

雖然不知道甚麼是「鬼畜」，但你覺得chAngE行不行？－hiJK910 ^七一_七二一 2021年2月16日 (二) 16:02 (UTC)[回复]

音樂條目命名選擇方向

按照目前討論的方向，最後有兩個選擇，第一「音樂作品不屬於專有名詞」，第二「命名時已官方名稱為優先」，「音樂作品屬於專有名詞」這個選項應該是不用再出現了，畢竟我們已經從討論「音樂作品是否屬於專有名詞」變成討論「音樂作品命名方針？」，已官方名稱為優先剛好可以順便解決以前的老問題（包括Wikipedia talk:格式手册/标点符号#用浪紋線表示範圍、Wikipedia_talk:格式手冊/標點符號）。鑒於先前我的判斷錯誤，這邊我邀請各位在下方表示各自的選擇與意見。@Ohtashinichiro、和平至上、Leehsiao、Sanmosa、Tombus20032000、百战天虫、Kriz Ju、生米一粒、Pseudo Classes、KodokunaSmile：@Easterlies、AT、卡達、Yumeto、SickManWP、羊羊32521、EdwardAlexanderCrowley、Zhaoweizhi0325、MoonLight3650、HXXXX：@Punkhippie、Louis0921gee、Peace 621、Whykitty、Moonshimmer93、夜来南风起、Fake12345、TreasureBabe325、Hijk910、Jacklamf1d14：@Ericliu1912、Naverad、Softyu、Sammypan、Tw drama、Shingkei、李新阳、CHih-See Hsie、Pv163、JoJo_append：@Lopullinen、AnYiLin、Yel D'ohan、Temp3600、Bigbullfrog1996、陳寅恪、Tenhumantenok、Prince of Erebor、K.Y.K.Z.K.、Arivgao： --無心*插柳*柳橙汁 2021年2月16日 (二) 14:06 (UTC)[回复]

音樂作品不屬於專有名詞

選擇這條後，音樂條目的名稱只要不屬於專有名詞、縮寫等條件，就不能使用全大寫、全小寫等風格樣式。這邊參照Wikipedia:命名常规#使用外文命名时的专门要求來處理。

(＋)支持。 --無心*插柳*柳橙汁 2021年2月15日 (一) 17:36 (UTC)[回复]
(＋)支持。--Tom......（留言） 2021年2月16日 (二) 14:29 (UTC)[回复]
我認為大小寫和簡繁體類似，更偏向一個名稱的兩種字體，而非兩個不同的名稱。就像繁體中文區的事物不強求使用繁體中文命名那樣；對於西文字母大小寫的問題，中文維基百科有理由使用自己的格式規範。--洛普利宁 2021年2月16日 (二) 16:13 (UTC)[回复]
(＋)支持。--东风（留言） 2021年2月16日 (二) 16:23 (UTC)[回复]
(＋)支持。--Leehsiao（留言） 2021年2月16日 (二) 22:08 (UTC)[回复]

命名時以官方名稱為優先

選擇這條後，音樂條目的名稱將根據官方名稱命名（但是具體該根據什麼的「官方名稱」還須另外討論）。

支持。—A T 2021年2月16日 (二) 14:23 (UTC)[回复]
支持。－hiJK910 ^七一_七二一 2021年2月16日 (二) 14:32 (UTC)[回复]
支持。--孤山王子（查閱馬薩布爾之書） 2021年2月16日 (二) 15:18 (UTC)[回复]
Mısaka ꮬ Mikoto ^悼自由 2021年2月16日 (二) 15:24 (UTC)[回复]
支持。请注意著作人格权在加拿大的案例，连为雕塑绑上红丝带都是侵犯著作人格权，何况是写错名字？须知，一些“现代艺术作品”名字是很重要的。故对所有作品都应尽量保持原文，除非作品名包含不正常的组合（如特殊Unicode、大小写、侮辱性词语）。至于繁简体则视为字体变化，不受约束。--E.A.Crowley6 6 6^✍️ 2021年2月16日 (二) 15:34 (UTC)[回复]
(＋)支持，希望能藉此解決相關爭議，並方便將來創建條目的編者適用（而且盡可能不用動腦，竊以為原方針有點太複雜，涉及太多一層層下來的判斷問題）。個人建議直接以作品（專輯或單曲）封面樣式優先即可。--Kriz Ju（留言） 2021年2月16日 (二) 15:57 (UTC)[回复]
支持。 紺野夢人 ^恭賀新春 2021年2月16日 (二) 16:01 (UTC)[回复]
(＋)支持。--SickManWP_{歡迎參與♥️邊緣人小組的活動·✏簽到}發表於 2021年2月16日 (二) 16:35 (UTC)[回复]
(＋)支持。--K·Y·K·Z·K ◢ 2021年2月16日 (二) 18:02 (UTC)[回复]
參官方網站寫法。但有一點要顧慮的是WP:COMMONNAME對WP:名從主人的優先性。SAN MO SA _SPQR 2021年2月16日 (二) 23:52 (UTC)[回复]
(＋)支持。--夜来南风起（留言） 2021年2月17日 (三) 10:33 (UTC)[回复]
(＋)支持。--【和平至上】^{支持通過港區國安法}💬 2021年2月17日 (三) 18:28 (UTC)[回复]
(＋)支持。空氣小貓（留言） 2021年2月18日 (四) 05:51 (UTC)[回复]
(＋)支持。🍫巧克力～✿ 2021年2月18日 (四) 09:15 (UTC)[回复]
(＋)支持。-- 天秤P Iūstitia | Spēs

意見

Milkypine意見：我個人選擇第一條（音樂作品不屬於專有名詞）。「官方名稱」是個很容統的稱呼

以官方網站為主：並非所有唱片公司都有網站，就算有也不一定都有作品列表，更甚至有已經關門的公司（沒錯，我就是再說你EMI）
官方Youtube為主：並非所有官方Youtube都會上傳作品，如果遇到沒有的作品可能無法適用（不過通常沒Youtube也很大機會不符合關注度）
商業平台為主（這裡是指Apple Music、Spotify、Amazon和tower等提供串流與販賣音樂的平台）：平台百百種，該如何抉擇？

如果真的選擇這條，我希望大家可以想想該使用何者為「官方名稱」基準。 --無心*插柳*柳橙汁 2021年2月15日 (一) 17:36 (UTC)[回复]

提名musicbrainz，先找官方网站再找元数据。不过我不太清楚哪个网站的元数据靠谱。--E.A.Crowley6 6 6^✍️ 2021年2月13日 (六) 09:22 (UTC)[回复]

我認為像musicbrainz、Discogs這類與維基同樣有使用者貢獻的內容優先度最低，話說不符合三項條件的機會好像也很低...。 --無心*插柳*柳橙汁 2021年2月13日 (六) 11:03 (UTC)[回复]

M君上述提出的三點對我而言是杞人憂天。首先，沒有官方網站的音樂作品必然佔少數，絕大多數的音樂作品也有官方網站，不存在官方名稱不明確的問題，也就是說可能產生這類問題的音樂作品只佔條目中的極低比重。其次，官方Youtube對我而言也是官方網站的一環，其他平台也一，正常來說如果是官方名稱，不同的官方平台也理應一致，就算有差異也只是極少數的情況下才有可能。其三，串流網站確實五花八門，因此我認為這是沒有官方平台的時候才應該拿來參考。最後，就因為有些音樂作品可能沒有官方平台就要依從命名常規來將其他符合名從主人的名稱一併改成符合外文規定的名稱是於理不合，這已經是接近原創研究的行為，況且對於那些少數沒有任何官方平台的音樂作品，我認為使用最常用名稱就好，沒必要牽拖有官方名稱的音樂作品。以上。—A T 2021年2月16日 (二) 14:34 (UTC)[回复]

的確「不存在官方名稱不明確的問題」，但如果說要用「官方網站」來舉證，許多老歌或是非三大音樂集團的作品很可能沒辦法。就我上述提到的兩首英文歌就是有官方網站但官網並不存在音樂作品的情況（和日韓文歌相比，這兩首明顯沒有作品列表這類明確的官方網站）。

不過這邊我應該會等之後確定好再來討論。 --無心*插柳*柳橙汁 2021年2月16日 (二) 16:41 (UTC)[回复]

上面Kriz Ju說得好，看封面不就好了？官方網站只是其中一種舉證方法而已。那些老歌或非主流作品沒有明確的官方名稱的時候，那跟從外文規定當然沒有問題。問題就在於當有官方名稱的情況下，還要受到外文規定的影響，改到不倫不類的話，那就是本末倒置。很多日韓歌您要是硬把它們改成小寫的話，說真的非常奇怪，一來不常用，二來不名從主人，只用外文規定是一種非常差的篩選方式。--A T 2021年2月16日 (二) 17:11 (UTC)[回复]

抱歉，在下比较熟悉古典音乐，对现代音乐不是很了解。而据鄙人所知，古典音乐条目或并不存在标题大小写问题，目前也有命名惯例。 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年2月16日 (二) 14:32 (UTC)[回复]
- 日後會把這部分納入音樂作品命名常規，前提是我們最後真的有生出「音樂作品命名常規」。 --無心*插柳*柳橙汁 2021年2月16日 (二) 16:41 (UTC)[回复]

反對依從英維做法。一、英文人跟中文人對英文的看法不一樣是很自然。英文人的英文是母語，對其更有規範是自然；對中文人來說是外語，自然會多些玩心。二、就本人活躍的J-POP、動畫歌曲條目而言，本人編輯時尚未試過對「官方名稱」為何有爭議。日本人玩英文名稱大小寫，一直玩得頗為一致。－hiJK910 ^七一_七二一 2021年2月16日 (二) 14:16 (UTC)[回复]

沒辦法(´_ゝ`)，命名常規這樣寫，有這種情況也是在所難免（要怪就怪當時的人，小的我也只是奉命行事）。事實上你看中維的音樂條目，日韓文歌以官方名稱為大宗，而英文歌則是按照常規走，甚至目前中維的條規也是如此。 --無心*插柳*柳橙汁 2021年2月16日 (二) 16:41 (UTC)[回复]

那你帶的討論方向完全錯誤，問題是「外文名大小寫應否跟隨官方」，歌名裏面用的字當然會有不是專有的名詞啊。－hiJK910 ^七一_七二一 2021年2月16日 (二) 17:08 (UTC)[回复]

第二，我認為在「在以某外語（如日文、韓文，甚至中文）處理英文時，『該語言通常行文的規範』應以該某外語作考慮」。例如在日文歌（或者其他作品名稱）以英文作歌名時，『該語言』指的是日文，在日文中歌名的大小寫是怎樣，就是怎樣；因為「在日文通常行文的規範」中，那東西就是這樣表達的。－hiJK910 ^七一_七二一 2021年2月16日 (二) 17:14 (UTC)[回复]

@Hijk910：我也說了一開始官方名稱不在考慮範圍是因為不管官方名稱如何都需要依照命名常規。說到底我依照命名常規做事我有理，你們用不成文的規定指責我才該念你們，怎麼好像一副我對不起你們的樣子。冤有頭債有主，不要罵我，罵當初寫Wikipedia:命名常规#使用外文命名时的专门要求的人。 --無心*插柳*柳橙汁 2021年2月16日 (二) 17:22 (UTC)[回复]

所以我第二句留言你有沒有看到？－hiJK910 ^七一_七二一 2021年2月16日 (二) 17:23 (UTC)[回复]

你的留言我有看到，但我身為被告也該要解釋自己的行為動機，總不能你說我討論方向完全錯誤，我就乖乖吞下。 --無心*插柳*柳橙汁 2021年2月16日 (二) 17:30 (UTC)[回复]

如果你因為我忽視你的第二句留言感到冒犯，那我這邊跟你說聲抱歉，我並沒有想要忽視，只是對我而言我該為自己辯護。至於詳細的內容，則可以等到投票結束後再來討論。 --無心*插柳*柳橙汁 2021年2月16日 (二) 17:39 (UTC)[回复]

我沒感到冒犯，還ok。我只是重申，我有理解你的想法了。還有想問問你對我的詮釋有何看法。－hiJK910 ^七一_七二一 2021年2月16日 (二) 17:57 (UTC)[回复]

另外，談一點討論方向的問題。1. 「一開始官方名稱不在考慮範圍」是錯誤前設，因為命名常規本身是可以改的。定下豁免是其中一個做法。加入詮釋（如我對「外文規範」、這個討論對「專有名詞」的理解等等）也是一個做法。2. 我發現很多人（包括我）說「歌名是專有名詞」。歌名當然是專有名詞，但不是你想討論的。這是因為我們沒有理解到，你是想指出前人定下的規則跟現況有衝突；也是因為你沒有在討論中直接引述原文。這裏個個都很忙，沒有/不想投入很多時間參與討論。就我而言，「最想維持原狀」「if it ain't broke, don't fix it」「別那麼煩」「一切從簡」「官方名稱也很規範」「韓文大小寫不統一跟日文歌名屁事」。大家第一眼看到「歌名不是專有名詞」如此白痴的陳述句，也只能反對閣下的提議了，你說是不是？－hiJK910 ^七一_七二一 2021年2月16日 (二) 17:57 (UTC)[回复]

你想說的是「若構成非英文區作品名稱的英文詞語如非專有名詞，應跟從『英文』規範，即（條文說的那樣）」，而非「音樂作品不屬於專有名詞」「命名時以官方名稱為優先」就兩項簡陋的陳述句。順帶一提，再重申，我認為「若構成非英文區作品名稱的英文詞語如非專有名詞，應跟從『該非英文區使用的語言』規範，即直接跟隨官方名稱」。－hiJK910 ^七一_七二一 2021年2月16日 (二) 18:06 (UTC)[回复]

「名稱」是專有名詞，屬於人、事、物、地所專用的名稱。不會因為名稱中用了些普通詞語，就讓名稱變成不專有的詞語；也不會因為讀音相同就用寫作所謂規範英文。正如Hunter × Hunter不會因為中間的×不發音，而去刪去中間的×。這個討論完全沒有常識。－hiJK910 ^七一_七二一 2021年2月16日 (二) 14:31 (UTC)[回复]

我覺得作品名像是書名，屬於專有。但我也明白專有名詞可能不能統一的問題。--Temp3600（留言） 2021年2月16日 (二) 14:47 (UTC)[回复]
並不是「使用普通詞語，導致變成不專有名詞」，而是「他打從一開始就不是專有名詞」。所以才要討論專有名詞的範圍。 --無心*插柳*柳橙汁 2021年2月16日 (二) 16:41 (UTC)[回复]
就當它不是專有名詞，那加一句音樂作品豁免什麼的就好了，因噎廢食並不可取啊。--A T 2021年2月16日 (二) 17:13 (UTC)[回复]

个人没有特别意见，以后哪条通过了我就会遵循哪条。--Bigbullfrog1996（留言） 2021年2月17日 (三) 07:09 (UTC)[回复]

總結

經過長久的討論與一個禮拜的投票，許多維基人皆認為在命名音樂條目時該根據官方名稱命名。當然維基並非依據投票數做決定，這邊也再次詢問支持「音樂作品不屬於專有名詞」與其他維基人的意見。如果沒有問題，那麼將其公示。 --無心*插柳*柳橙汁 2021年2月24日 (三) 14:32 (UTC)[回复]

國際關係條目命名常規

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

承先前的社羣諮詢，現根據在其中所得到的所有合理意見擬定新版國際關係條目命名常規，並擬作方針通過。SAN MO SA _SPQR 2021年2月8日 (一) 07:41 (UTC)[回复]

(！)抗议+(－)反对：這不是共識，這是某用戶製造出來的所謂「共識」。社群諮詢中，明明提議用「—」多於「與」；提議用英文國家名字母順序多於其他順序方式，然而該用戶一概無視。強烈建議暫緩通過，重新開設投票。-- 約翰同志－條目裱糊匠（留言） 2021年2月8日 (一) 11:13 (UTC)[回复]
意見大致同上。不建議強行推動修訂。—— Eric Liu_{創造は生命（留言．留名．學生會）} 2021年2月8日 (一) 15:34 (UTC)[回复]

@Comrade John、Ericliu1912：前者是我看漏，已更正。後者而言，根據先前的社羣諮詢的結果，在涉及「中國」與代表「中國」的（歷史）政權時，兩個主權國家／有限承認國家之間的國際關係的條目的命名排序中，在常用語排序優先以及中文使用慣性的前提下，「中國」與代表「中國」的（歷史）政權先行。另外，有用戶指出直接明文寫明「中國」與代表「中國」的（歷史）政權先行會違反避免地域中心方針，因此兩個主權國家／有限承認國家之間的國際關係的條目的命名排序難以區分為涉及與不涉及「中國」與代表「中國」的（歷史）政權的兩種情況處理。考量到在條文實際效果中，如果條目命名上不做到「中國」與代表「中國」的（歷史）政權先行，會引來更大規模的社群反對聲音，因此我只能作出如此取捨。另一方面，擬議條文是“同等級雙邊關係中，命名先後順序按照中文常用語序確定，如無特定中文常用語序則以英文國名字母順序確定”，考量到在不涉及「中國」與代表「中國」的（歷史）政權的情況下，中文一般並無特定常用排列順序，因此最終的結果也是以英文國名字母順序確定。綜以上，就後者而言，由於實際應用效果相同，我不認為我有錯誤總結共識。SAN MO SA _SPQR 2021年2月9日 (二) 00:06 (UTC)[回复]

大体上(＋)支持，虽然我仍然反对使用不符合中文用语习惯的连接符号，但社群意向如此我也不多说什么。另外，能否对简称的重定向方式进行进一步的规定？如果我没理解错，简称应该重定向至“<国名甲>—<国名乙>关系”为宜。——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年2月14日 (日) 13:16 (UTC)[回复]
另，“英文字母顺序”容易引发歧义，比如说美国到底应该用“United States of America”的“U”，还是“America”的“A”？或许应该使用ISO 3166-2的规定。——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年2月14日 (日) 13:24 (UTC)[回复]
- 根據英維做法，美國用「U」。-- 約翰同志－條目裱糊匠（留言） 2021年2月14日 (日) 13:50 (UTC)[回复]
  - 所以说应该用ISO 3166-2中的规定的代码的顺序，其中美国的代码为“US”。——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年2月14日 (日) 14:57 (UTC)[回复]
    - @Comrade John、BlackShadowG：（1）簡稱通常應該重新導向至「<國名甲>－<國名乙>關係」，但：如條目中國家甲僅涉及一個政權，則重新導向至「<國號甲>－<國名乙>關係」，惟如條目中國家乙也僅涉及一個政權，則重新導向至「<國號甲>－<國號乙>關係」；如果產生歧義，則作消歧義頁面處理。（2）我建議在應用英文字母順序時參照世界政區索引的排序，有些國家ISO沒有收。這好像也是enwiki的辦法（？）。（3）另外也請Comrade John回應一下對現案的最新意見，我在2月9日早已進行回應，而且也有ping。SANMOSA _SPQR 2021年2月16日 (二) 00:09 (UTC)[回复]
      - 如果現行建議，在連接和排序方面，實際上是維持現狀，我沒有意見。-- 約翰同志－條目裱糊匠（留言） 2021年2月16日 (二) 08:10 (UTC)[回复]
（離題）話說日本跟北韓沒有建交，但條目仍然叫做日本－朝鲜关系，可見現行「－」跟「與」的原創研究區別方法甚至都沒能完全實踐。—— Eric Liu_{創造は生命（留言．留名．學生會）} 2021年2月16日 (二) 06:10 (UTC)[回复]
英文字母順序還是不要硬性規定，太多例外，如梵蒂岡，根據聖座「在國際關係中，各國大使不是獲梵蒂岡城國而是獲聖座所接受；聖座向各國和國際組織派出的外交代表機構或使節，是代表聖座而非所謂梵蒂岡城國。」，所以是用「H」而非「V」。英維大部份通用命名情況是怎樣，跟隨就是了。-- 約翰同志－條目裱糊匠（留言） 2021年2月16日 (二) 08:51 (UTC)[回复]
- @Comrade John：就Holy See那點，我再修改一下。其他情況我認為“其他情況根據編輯者創建的情況‘先到先得’或經包括創建者在內的編輯者討論達成共識後移動”一條已經包含，就不用再改了。SAN MO SA _SPQR 2021年2月18日 (四) 01:41 (UTC)[回复]

現已無反對意見，依WP:7DAYS公示7日。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 02:18 (UTC)[回复]

@Comrade John、Ericliu1912：邀请明确意见。个人对“实体名不得使用单字简称”且方针性质倾向反对，中日关系应当改成中国－日本关系吗。其他条款未研究，怀疑是否已有足够共识。--YF dyh000（留言） 2021年2月25日 (四) 03:12 (UTC)[回复]

@YFdyh000：要移動，移動後原名稱要改為消歧義，否則會產生歧義。另外此命名常規意在統一所有兩個實體之間的國際關係條目命名，以避免原創研究問題（一些用「－」，一些用「與」，一些用簡稱，完全沒有使用準則，即使有，也是原創研究，而且也沒有完全落實執行）。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 09:04 (UTC)[回复]

(－)傾向反對公示。儘管我個人是贊成移動之後消歧義的，但本地社群的共識似乎並不普遍贊同所謂「實體名不得使用單字簡稱」的規定，強硬推動並無好處。亦即，多數朋友並不會同意將中日关系移動至中國－日本關係。考慮到常用名稱原則，較好的方法應是在中日關係條目直接做消歧義。中日關係悠久，各政權時期皆有其重要性，相信是足以做平等消歧義的。此處順道提出一個方案，1971年以前與中國建交的國家，其「中某關係」或「中國－某國關係」雙邊關係條目採用平等消歧義，1971年以後與中國建交的國家，其「中某關係」或「中國－某國關係」雙邊關係條目則採用主從消歧義，按慣例主為「中華人民共和國」，從為中華民國，兼顧兩岸勢力消長。—— Eric Liu_{創造は生命（留言．留名．學生會）} 2021年2月28日 (日) 15:22 (UTC)[回复]

悬挂Blocked user模板之利弊

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

关于Wikipedia:封禁方针#标记用户页方针。先前讨论见Template talk:Blocked user#編輯請求 2021-02-10、被永久封禁的用户页。个人认为2016年的讨论缺乏共识，写入方针不当，同时不需要为了标记而“標記被永久封鎖的使用者頁面”（TW现有功能）。enwiki上的该模板是已弃用状态。建议明确：用户页未被创建则只需白纸保护；已创建但历史版本无需删除则以{{blocked user}}替换并永久全保护；需要标记傀儡则以{{sockpuppeteer}}或{{blocked sockpuppet}}替换并永久全保护（为了分类傀儡）。

同时建议将历史版本仅是悬挂无参数模板的页面用机器人删除、改以白纸保护（减少完整数据库下载的容量，减少破坏留痕）。以及在技术上是否要为已封禁、未创建的用户页提供更多的说明和工具链接。--YF dyh000（留言） 2021年2月11日 (四) 03:15 (UTC)[回复]

(－)反对提案意图达成的目标在事实上并不严重或无法实现：1. 关于减少数据库下载的容量，本站永封用户仅数万人，{{indef}}不足十个字节，而本站被自动欢迎的注册用户有数百万人，且欢迎模板替换引用后长达数千字节。因此前者所节约的容量与后者相比，有将近5个数量级的差距，不过是九牛之一毛罢了，对数据维护的益处是相当边际性的。2. 关于破坏留痕的问题，现行方针已要求攻击/侮辱性用户名不得创建用户页，已有用户页如存在也要删除；更何况永封用户页本身就是不索引的，主流搜索引擎不会收录，外网几乎不可见，也自然不存在严重的留痕问题。--Antigng（留言） 2021年2月11日 (四) 03:40 (UTC)[回复]

好，容量问题可忽略。非严重的恶性用户名页面仍影响Special:前缀索引、数据库记录等部分地方。提出的一大原因是创建模板使日志不显示，相当于“折叠”重要的信息，同时它无法提供难以替代的作用。--YF dyh000（留言） 2021年2月11日 (四) 04:46 (UTC)[回复]

不使用模板标记，而直接白纸保护，虽然相较于现行的做法“展开”了一条最近的封禁日志，但与此同时，也“展开”了一条本应“折叠”的无关信息——保护日志（如果采取删除的方式处理既有页面，还会“展开”一条本应“折叠”的删除信息）；何况白纸保护下，用户贡献、完整的封禁日志仍处于折叠状态；用户日志（对于滥建条目的破坏者有用）则根本不存在；现行模板也会呈现白纸保护下不呈现的封禁方针。因此很难说白纸保护相对于模板标记是更好的呈现方式。--Antigng（留言） 2021年2月11日 (四) 06:57 (UTC)[回复]

1. 没有好办法，本该呈现。2. 怀疑在技术上能拓展相关显示信息（MediaWiki名字空间下）。3. 现行模板强制用户去寻找和点击并不明显的封禁日志链接，我看都蒙。要不然参考机器人紧急停止模板设计，封禁日志链接变大型，用户贡献记录变中等。--YF dyh000（留言） 2021年2月11日 (四) 07:22 (UTC)[回复]

(＋)支持修改相關訊息可以直接點入日誌（至少不用再去找連結）-- Sunny00217 2021年2月11日 (四) 14:14 (UTC)[回复]

建議依現時實際使用情況修正條文如下：

現行條文

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

若此用户名具有极端侮辱性（比如需要监督），请删除此用户页（如有），并白纸保护此用户页。
其他情况下：
- 若此用户因滥用傀儡，或被确认为他人的傀儡而被封禁，请以{{sockpuppeteer|blocked}}（对于滥用傀儡的用户）或{{blocked sockpuppet|主帐号}}（对于傀儡帐号）替换原有的用户页内容。
- 若此用户因其他原因而被封禁，请以{{blocked user}}替换原有的用户页内容。
最后，永久全保护该用户页。

提議條文

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

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

以上。這比較符合現時的實際使用情況（除了要求必須標記滥用傀儡的用戶／傀儡用戶一條外，原因是方便查找關連傀儡用戶）。SAN MO SA _SPQR 2021年2月17日 (三) 14:27 (UTC)[回复]

支持，因其他原因永封没必要强制都要创建用户页并标记。--Kuailong ™ 2021年2月18日 (四) 18:04 (UTC)[回复]

(＋)支持-- Sunny00217 2021年2月21日 (日) 13:53 (UTC)[回复]

支持。至于提案提到的其他事项，有人愿意推进再说吧。--YF dyh000（留言） 2021年2月21日 (日) 14:09 (UTC)[回复]

支持，同意，其实我现在基本就是这么操作--淺藍雪^❉ 2021年2月23日 (二) 06:15 (UTC)[回复]

(＋)支持，很好，很好，很好，很好。凋零铁道运输总署茶室 2021年2月26日 (五) 10:28 (UTC)[回复]

維基百科:管理員解任投票潛在漏洞

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:管理員解任投票。

兩個問題。一) 作為彈劾案提案人的資格究竟是自動確認用戶還是人事任免投票資格？WP:RFDA/A寫的是前者，如此一來是否可以理解為最重要的第一票不需要達到人事任免投票資格，只需自動確認已經可以提出？二) 提案頁究竟應該是開始聯署就已經建頁還是集齊七名連署人，成案後才建頁？WP:RFDA/A寫的是前者，但社群實際操作多是後者，在互煮集齊七人才建頁。~~以上兩個矛盾真正有約束力的方針WP:RFDA本身均沒有提及~~-某人 ✉ 2021年2月11日 (四) 06:07 (UTC)[回复]

抱歉WP:RFDA寫的原來都是自動確認已經可以提案，那麼又回到我的問題：是否可以理解為最重要的第一票不需要達到人事任免投票資格？-某人 ✉ 2021年2月11日 (四) 06:10 (UTC)[回复]
Wikipedia:管理員的離任是主页面，里面有写道：“提出：由一名自动确认用户提出…联署：…有投票资格的用户联署”，这个“投票资格”显然是指人事任免票。--安忆 ^Talk 2021年2月11日 (四) 06:22 (UTC)[回复]

“最重要的第一票”前提是“第二步：等待讨论共识；”，所以如果没共识就开案，应该会被雪球关闭。暂不认为已有一定共识时第一票必须符合任免资格，新用户可能更勇于编辑和打破僵局。目前看多是在客栈完成第六步的联署再开案，如有意可提案修改此流程。如果有傀儡用自动确认用户开案，但解任失败，反倒会冻结解任6个月，偷鸡不成蚀把米。--YF dyh000（留言） 2021年2月11日 (四) 06:23 (UTC)[回复]

提出存在讨论共识的解任案，不代表提案者肯定具备投票权并计入投票。--YF dyh000（留言） 2021年2月11日 (四) 06:34 (UTC)[回复]

我的理解是自動確認用戶可以提出，但若其不符合人事任免投票資格，則不包括為七人之中；事實上提出的人可以不參與聯署，可以當作「第零票」吧。--【和平至上】^{支持通過港區國安法}💬 2021年2月11日 (四) 16:44 (UTC)[回复]

我認為和平至上的解讀可行。就「提出的人可以不參與聯署」的情形，1233曾為之（雖然其具人事任免投票資格）。SAN MO SA _SPQR 2021年2月12日 (五) 07:12 (UTC)[回复]

(！)意見:我覺得是筆誤，可以修正，因為自動確認用戶是很容易刷自來的。--蟲蟲飛♡♡→♡℃※留言 2021年2月12日 (五) 08:07 (UTC)[回复]

那不如提案修正表述，把“一名自动确认用户提名”改成“一名具人事任免投票资格的用户提名”，后跟“共七名符合人事任免资格用户联署”如何？--TP✉️SE🗳️CSCEP✍ 2021年2月14日 (日) 10:40 (UTC)[回复]

( ✓ )同意--蟲蟲飛♡♡→♡℃※留言 2021年2月14日 (日) 13:10 (UTC)[回复]

我不認為是筆誤，但不反對收緊。SAN MO SA _SPQR 2021年2月16日 (二) 00:13 (UTC)[回复]

我不认为是笔误，在出现明显共识前我不认为需要收紧。--YF dyh000（留言） 2021年2月16日 (二) 03:15 (UTC)[回复]

提名與聯署(票)可分開考慮。--Temp3600（留言） 2021年2月16日 (二) 18:47 (UTC)[回复]
认同和平至上的方案。自动确认用户可以提案，但若不满足人事任免投票資格则不算联署票。--Wonderwind2002（留言） 2021年2月17日 (三) 15:03 (UTC)[回复]

(▲)同上支持U:和平至上的意见，将提案资格与投票资格区分开来，不必剥夺自动确认用户的提案资格。若提案人有资格则联署票计7票，无则计6票。（第0票的说法大可不必，着实容易引起误会）--懒癌哪天行_{→Lazy, as no today's excuse.} 2021年2月21日 (日) 11:59 (UTC)[回复]

將Wikipedia:回退功能#移動時不留重定向合併到Wikipedia:重定向#移動時不留重定向

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:重定向、Wikipedia talk:回退功能、Wikipedia talk:新頁面巡查。

理由如下：

此權限跟Wikipedia:回退功能沒有太大的關連，個人認為純粹是回退權裡包含此權限因此寫入此處
有機率導致像是Wikipedia_talk:重定向#分类重定向的情況

-- Sunny00217 2021年2月11日 (四) 16:08 (UTC)[回复]

WP:回退员重定向到回退功能页面。“如有违反前述原则，当以除权处理。”对方针有意义，需要解决。--YF dyh000（留言） 2021年2月11日 (四) 16:12 (UTC)[回复]

Suppress redirect 也與反破壞有關，不認為完全無關聯。空氣小貓（留言） 2021年2月11日 (四) 16:14 (UTC)[回复]

因為連巡查員也有-- Sunny00217 2021年2月12日 (五) 06:36 (UTC)[回复]

與反破壞有關+1。但若欲改為留下連結，合併重複內文於一處，使未來容易維護，亦無不可。--Hjh474（留言） 2021年2月12日 (五) 02:34 (UTC)[回复]

現擬議修改WP:重定向、WP:回退功能、WP:新頁面巡查如下：

WP:重定向：

現行條文

移動時不留重定向

快捷方式

WP:R#SUPPRESS

一般來說，移動頁面時，會自動留下重定向。某些用戶組（擁有suppressredirect權限的用戶）可以通過取消選中標有「保留重定向」的框來阻止創建重定向，稱為移動時不留重定向（suppressing redirect）。目前，這些群組包括管理員、巡查員、回退員等。在某些情況下，移動頁面時自動創建的重定向是不恰當的——例如文章曾被移動破壞至不良標題。不留重定向即可節省移動後刪除重定向的時間和麻煩。

一般情況下，重定向是歷史紀錄中一個有用的條目，所以除非有充分理由移動時不留重定向（例如故意破壞，將放錯位置的內容轉移到用戶空間或釋放標題以便另一頁面佔用），最好將其留下。重定向留下幫助讀者找到舊文章一條線索，以防在其先前位置創建新文章，並防止連結失效。因此，我們通常既不移動時不留重定向，也不刪除重定向。

提議條文

移動時不留重定向

快捷方式

WP:R#SUPPRESS

一般來說，移動頁面時，會自動留下重定向。某些用戶組（擁有suppressredirect權限的用戶）可以通過取消選中標有「保留重定向」的複選框來阻止創建重定向，稱為移動時不留重定向（suppressing redirect）。目前，這些群組包括管理員、巡查員、回退員等。在某些情況下，移動頁面時自動創建的重定向是不恰當的——例如文章曾被移動破壞至不良標題。不留重定向即可節省移動後刪除重定向的時間和麻煩。移動而不留重定向依舊會記錄在案，不過會加上「不留重新導向」的標示。

一般情況下，重定向是歷史紀錄中一個有用的條目，所以除非有充分理由移動時不留重定向，最好將其留下。重定向留下幫助讀者找到舊文章一條線索，以防在其先前位置創建新文章，並防止連結失效。因此，我們通常既不移動時不留重定向，也不刪除重定向。

何時可移動而不留重定向當重定向符合快速刪除方針，特別是G3（故意破壞）、O1（應用戶要求在該用戶空間下移動頁面或從該用戶空間下將頁面移動到主名字空間），或將放錯位置的內容轉移到用戶空間，或須釋放標題（騰空頁面）以便另一頁面佔用時候，即可移動而不留重定向。

何時不可移動而不留重定向用戶不得利用權限於命名爭議中奪取優勢、無視命名爭議而使用權限或者將權限用於破壞。巡查員、回退員如有違反前述原則，當以除權處理。

WP:回退功能：

現行條文

移動時不留重定向移動頁面時，預設會留下重定向。然而，有時留下重定向會增加後續工作，並不理想，例如回退頁面移動破壞，又或者需要騰空頁面以便移動其他頁面。當擁有「移動時不留重定向」權限時，移動頁面時就可以於移動頁面介面取消剔選「留下重新導向頁面」框框。如此，就可以移動頁面而不留重定向。移動而不留重定向依舊會紀錄在案，不過會多一句「不留重新導向」。

何時可移動而不留重定向當重定向符合快速刪除方針，特別是G3、O1，即回退移動破壞或應用戶要求在該用戶空間下移動頁面或從該用戶空間下將頁面移動到主名字空間。

何時不可移動而不留重定向用戶不得利用權限於命名爭議中奪取優勢、無視命名爭議而使用權限或者將權限用於破壞。如有違反前述原則，當以除權處理。

提議條文

移動時不留重定向

WP:新頁面巡查：

現行條文

移動時不留重定向

移動頁面時，預設會留下重定向。然而，有時留下重定向會增加後續工作，並不理想，例如回退頁面移動破壞，又或者需要騰空頁面以便移動其他頁面。當擁有「移動時不留重定向」權限時，移動頁面時就可以於移動頁面介面取消勾選「留下重新導向頁面」复选框。如此，就可以移動頁面而不留重定向。移動而不留重定向依舊會紀錄在案，不過會多一句「不留重新導向」。巡查員運用此權限時，應遵守回退功能方針相關段落規定。

提議條文

移動時不留重定向

以上。如通過，有關移動時不留重新導向權限的規定將統一整合至WP:重定向（包括有關除權規定），而WP:回退功能與WP:新頁面巡查則只留下章節連結。SAN MO SA _SPQR 2021年2月18日 (四) 01:15 (UTC)[回复]

@Sunny00217、YFdyh000、Pseudo Classes、Hjh474。SAN MO SA _SPQR 2021年2月18日 (四) 01:17 (UTC)[回复]

没什么意见。把“纪录”更正“记录”吧。--YF dyh000（留言） 2021年2月18日 (四) 01:27 (UTC)[回复]

@YFdyh000：

完成。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月20日 (六) 02:22 (UTC)[回复]

@YFdyh000：名詞是用「紀錄」沒錯，動詞才是「記錄」。我改的一處正是本是動詞的地方。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月20日 (六) 02:37 (UTC)[回复]

不是名词动词问题吧，纪录用于成绩统计层面（纪录片除外），记录才是文字层面。难道有地区词差异。--YF dyh000（留言） 2021年2月20日 (六) 02:51 (UTC)[回复]

@YFdyh000：《文書處理手冊》附錄2（第60頁）。（意外發現地區詞差異）SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月20日 (六) 03:05 (UTC)[回复]

有点搞不清，可能需另议或字词转换……在中国大陆，纪录主要是最好成绩或总结归纳，会议记录、历史记录等不会写纪录，个人健康纪录也一般是“个人健康记录”。此博客提到文书所用动词/名词分法，但评论也有不同意见。--YF dyh000（留言） 2021年2月20日 (六) 04:11 (UTC)[回复]

@YFdyh000：恐怕不能用字詞轉換處理，因為誤轉機率太高：有些地方的使用是一樣的，但有些地方的使用是完全不同的。《文書處理手冊》是臺灣官方文件，我給予的連結也是政府網站連結，我認為沒辦法質疑。繁體來說是會寫「會議紀錄」、「歷史紀錄」的（至少前者我非常肯定）。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月20日 (六) 04:18 (UTC)[回复]

指在方针指引页（如Wikipedia:R）转换。浏览器的“历史记录”我是很确定的。--YF dyh000（留言） 2021年2月20日 (六) 04:36 (UTC)[回复]

（1）問題完全一樣，在任何地方轉換都會出現一樣的問題。（2）科技公司經常會忽略地區用詞差異，不能作準。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月20日 (六) 07:56 (UTC)[回复]

你这一“不能作准”，中国大陆所有软件和文献就都是错的了。我非常确定99%+将History称作历史记录，历史纪录是Best record。在此题中讨论可能不大合适。--YF dyh000（留言） 2021年2月20日 (六) 08:06 (UTC)[回复]

@YFdyh000：至少在繁體不能作準吧。如果是中國大陸公司開發的browser，在中國大陸簡體下反而是可以作準的。如果沒其他問題的話，我就不再修改提案了。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月20日 (六) 13:57 (UTC)[回复]

代為標示{{新增條文}}，請幫確認有無錯漏。--Hjh474（留言） 2021年2月18日 (四) 02:17 (UTC)[回复]

{{刪除條文}}也加上了。SAN MO SA _SPQR 2021年2月18日 (四) 02:26 (UTC)[回复]

原來巡查權那裏也有一段-- Sunny00217 2021年2月18日 (四) 03:10 (UTC)[回复]

是不是需要公示貼公告板？--Hjh474（留言） 2021年2月26日 (五) 02:46 (UTC)[回复]

用户名修改与订阅

注意到@BureibuNeko的用户名修改后订阅列表1 2没有更新，是否需要为此修改相关方针？--E.A.Crowley6 6 6^✍️ 2021年2月13日 (六) 03:41 (UTC)[回复]

建议您指出相关方针是哪条，以及修改的方案。——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年2月14日 (日) 13:08 (UTC)[回复]
@EdwardAlexanderCrowley？—— Eric Liu_{創造は生命（留言．留名．學生會）} 2021年2月22日 (一) 13:16 (UTC)[回复]

修正WP:PB條文內容

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:避免地域中心。

通過。SAN MO SA _{江南好，風景舊曾諳} 2021年2月28日 (日) 05:37 (UTC)[回复]

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

現行條文

維基百科應該中立地表述現實，對於台灣海峽兩岸複雜的政治關係及爭議，維基百科不應預設任何政治立場。除了專有名詞、引錄人物原話、檔案原文、機構標準名稱等既有內容之外，為避免使用法理論述所形成的中立性問題，編者應以事實論述為基礎，表述兩岸四地所涉及的複雜情況。關於具體詞語用法，請見Wikipedia:格式手册/两岸四地用语。

提議條文

維基百科應該中立地表述現實，對於台灣海峽兩岸複雜的政治關係與爭議及朝鮮半島南北關係複雜的政治關係與爭議，維基百科不應預設任何政治立場。除了專有名詞、引錄人物原話、檔案原文、機構標準名稱等既有內容之外，為避免使用法理論述所形成的中立性問題，編者應以事實論述為基礎，表述兩岸四地及朝鮮半島南北政權所分別涉及的複雜情況。關於具體詞語用法，請見Wikipedia:格式手册/两岸四地用语與Wikipedia:格式手册/朝鲜半岛用语。

基於MOS:COR條文已經妥善，針對涉及到的WP:PB進行事實性修改。--🍫巧克力～✿ 2021年2月14日 (日) 11:22 (UTC)[回复]

不要在方針正文用簡寫?--Temp3600（留言） 2021年2月15日 (一) 02:49 (UTC)[回复]

@Temp3600：已將捷徑修正為完整的名稱。--🍫巧克力～✿ 2021年2月15日 (一) 07:03 (UTC)[回复]

( ✓ )同意。-- 天秤P Iūstitia | Spēs 2021年2月15日 (一) 13:08 (UTC)[回复]
(＋)贊成。--Jason zhuo（留言） 2021年2月15日 (一) 13:50 (UTC)[回复]
(＋)支持，但是不是太啰嗦了，万一以后又通过了东西德、南北越、塞浦路斯、科索沃、德左、南部联盟什么的格式手册 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年2月15日 (一) 15:25 (UTC)[回复]

我認為用詞可以再調整一下，如下：

現行條文

維基百科應該中立地表述現實，對於台灣海峽兩岸複雜的政治關係及爭議，維基百科不應預設任何政治立場。除了專有名詞、引錄人物原話、檔案原文、機構標準名稱等既有內容之外，為避免使用法理論述所形成的中立性問題，編者應以事實論述為基礎，表述兩岸四地所涉及的複雜情況。關於具體詞語用法，請見Wikipedia:格式手册/两岸四地用语。

提議條文

維基百科應該中立地表述現實，對於台灣海峽兩岸、朝鮮半島南北關係等複雜的政治關係及爭議，維基百科不應預設任何政治立場。除了專有名詞、引錄人物原話、檔案原文、機構標準名稱等既有內容之外，為避免使用法理論述所形成的中立性問題，編者應以事實論述為基礎，表述兩岸四地、朝鮮半島南北政權等所分別涉及的複雜情況。關於具體詞語用法，請見Wikipedia:格式手册/两岸四地用语與Wikipedia:格式手册/朝鲜半岛用语。

以上。SAN MO SA _SPQR 2021年2月16日 (二) 00:12 (UTC)[回复]

(：)回應@Sanmosa：這是針對羊羊君所提列的那些議題所做出的小改動吧？--🍫巧克力～✿ 2021年2月16日 (二) 02:28 (UTC)[回复]
加入「等」字來說，是的。另一方面是希望用詞更為簡潔。SAN MO SA _SPQR 2021年2月16日 (二) 02:43 (UTC)[回复]

@Temp3600、Tenbeens、Jasonzhuocn、羊羊32521：標記上方參與討論的編輯要不要以這版進行調整。--🍫巧克力～✿ 2021年2月16日 (二) 13:47 (UTC)[回复]

都可以。--Temp3600（留言） 2021年2月16日 (二) 14:39 (UTC)[回复]
(＋)支持避免臺灣海峽中心。 紺野夢人 ^恭賀新春 2021年2月16日 (二) 16:35 (UTC)[回复]
既然朝鮮半島相關用語已經通過，那麼避免地域中心就有必要──以上未簽名的留言由Matt Zhuang（討論｜貢獻）於2021年2月17日 (三) 14:57 (UTC)加入。[回复]
(＋)支持 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年2月18日 (四) 04:51 (UTC)[回复]
(＋)支持。-- 天秤P Iūstitia | Spēs 2021年2月19日 (五) 16:31 (UTC)[回复]

若無特別意見，現按Sanmosa所提出的版本進行公示，時間至2021年2月27日07:50 (UTC)止。--🍫巧克力～✿ 2021年2月20日 (六) 07:51 (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百萬”。

提議條文

數字整數一至十的書寫一至十的整数如果不是出現在具有統計意義的一組數字中，則汉字、阿拉伯数字都可使用，例如：一个人、三本书、读了十遍、5个百分点。

正确：这个地区的高等学校有新闻系6个、新闻专业科系7个
错误：这个地区的高等学校有新闻系6个、新闻专业科系七个

為保持上下文局部體例一致，若兩組或多組數據並列，則必須統一格式。若其中至少一組數據被本指引禁止使用某種格式，則其他與之並列者亦不可使用。

（略）

物理量量值的書寫物理量量值必須使用阿拉伯數字，並正確使用法定計量單位，惟在無關科學的條目中，符合「整數一至十的書寫」的規定者例外。例如：一百五十平方米應寫作150平方米或150 m²。

（略）

一般量詞前的數值一般量詞前面的數字應該使用阿拉伯數字，不應使用漢字表示，惟符合「整數一至十的書寫」的規定者例外：

正确：200人、1000名、5000年
错误：兩百人、一千名、五千年

「萬X」、「億X」等10⁴的倍數級的中文數字量值當成單位的一部分。

（略）

金錢單位前的數字非物理量值的單位應該使用阿拉伯數字，惟符合「整數一至十的書寫」的規定者例外。例如：20元、10.1萬元、300美元、290億英鎊等。

多位數字的分節對於多位數字的，應該適當分節，以助於讀者理解。分節時可使用撇節法劃分。

三位撇節法對於小數點前或后超過四位的數，從小數點起，向左和向右每三位數字一組，組間空四分之一個漢字（二分之一個阿拉伯數字）的位置，或以“,”（半角逗号）按千分節，例如：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 _SPQR 2021年2月16日 (二) 03:19 (UTC)[回复]

「7.2 整數一至十，如果不是出現在具有統計意義的一組數字中，可以用漢字，但要照顧到上下文，求得局部體例上的一致。」中華人民共和國國家標準出版物上數字用法的規定（節錄自香港大學中文教育網）我知道已經有相關段落，但建議將該段置上，或在各段簡單說明一至十的例外。--LuciferianThomas．留言 2021年2月17日 (三) 00:01 (UTC)[回复]

@LuciferianThomas：原案標記錯誤，已更正為「符合『整數一至十的書寫』的規定者例外」。已調整排版。SAN MO SA _SPQR 2021年2月17日 (三) 14:07 (UTC)[回复]

另外，此案的一個可行變體為「整數一至十的書寫」擴為「整數一至一百的書寫」。SAN MO SA _SPQR 2021年2月17日 (三) 14:11 (UTC)[回复]

變體也寫一次好了：

現行條文

數字（略）

物理量量值的書寫物理量量值必須使用阿拉伯數字，並正確使用法定計量單位。例如：一百五十平方米應寫作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²。

（略）

一般量詞前的數值一般量詞前面的數字應該使用阿拉伯數字，不應使用漢字表示，惟符合「整數一至一百的書寫」的規定者例外：

正确：200人、1000名、5000年
错误：兩百人、一千名、五千年

「萬X」、「億X」等10⁴的倍數級的中文數字量值當成單位的一部分。

（略）

金錢單位前的數字非物理量值的單位應該使用阿拉伯數字，惟符合「整數一至一百的書寫」的規定者例外。例如：20元、10.1萬元、300美元、290億英鎊等。

多位數字的分節對於多位數字的，應該適當分節，以助於讀者理解。分節時可使用撇節法劃分。

三位撇節法對於小數點前或后超過四位的數，從小數點起，向左和向右每三位數字一組，組間空四分之一個漢字（二分之一個阿拉伯數字）的位置，或以“,”（半角逗号）按千分節，例如：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年2月19日 (五) 02:40 (UTC)[回复]

@LuciferianThomas、Yangwenbo99、Cwek、Lopullinen：想看看大家比較傾向我原本的提案還是變體版本。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月21日 (日) 08:57 (UTC)[回复]

傾向後者。另建議「中文的四位撇節法」不在科技條目中使用。——Yangwenbo99^{論文} 2021年2月22日 (一) 13:05 (UTC)[回复]

補充了。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月22日 (一) 13:57 (UTC)[回复]

Wikipedia:格式手册/标点符号#冒号增訂

打算增加「同一句子當中應避免使用多個冒號」、「冒號提示的範圍不應過窄或過寬」作為注意事項，希望進一步討論。具體例子後補。--Bookwith（留言） 2021年2月20日 (六) 06:15 (UTC)[回复]

他認為：建築工程一再拖延的原因有兩個：管理不妥和人手不足。

他認為，建築工程一再拖延的原因有兩個：管理不妥和人手不足。

舉例「同一句子當中應避免使用多個冒號」。--Bookwith（留言） 2021年2月23日 (二) 06:58 (UTC)[回复]

幾乎沒人願意參與格式手冊修訂的討論。--Bookwith（留言） 2021年2月23日 (二) 07:00 (UTC)[回复]

我覺得單純是你例子太晚提出導致很多人不知道你要幹嘛而已。 --無心*插柳*柳橙汁 2021年2月23日 (二) 13:24 (UTC)[回复]

(▲)同上。我想知道错例在实务中是否常见（例如1个月内>3次），不存在则WP:豆子。--YF dyh000（留言） 2021年2月23日 (二) 13:33 (UTC)[回复]

修订维基百科:关注度 (人物)

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

删除注1。Fire Ice 2021年2月20日 (六) 16:36 (UTC)[回复]

再加码，删除“尽管维基不是纸本出版物，这里还是有一些收录的标准。”，删除“维基百科收录包括重要的历史人物和卷进时事的人的条目。”里的“包括”二字，都是无意义的东西。Fire Ice 2021年2月20日 (六) 16:49 (UTC)[回复]

再加码，“其他测试”一节实际毫无意义，建议整节删除。Fire Ice 2021年2月20日 (六) 16:50 (UTC)[回复]

干脆这样吧：

現行條文

跟任何百科全书一样，維基百科收錄包括重要的历史人物和卷进时事的人的條目。尽管維基不是紙本出版物，這裡还是有一些收錄的标准。除了此指引，也可以参见《關注度》^{[註 1]}，該處有一个普遍及通用的收錄标准。特別地，運動員的關注度應優先考慮《運動員關注度指引》，学者的关注度应优先考虑《学者关注度指引》。 …… 其他測試

以下方法也可以用來測試某人物是否值得收錄於百科全書：

大學教授測試：他是否比一個普通大學教授更廣為人知，或出版了更多的書籍？
確證測試：現在或十年以後，條目中的所有資料還可以被獨立確證嗎？
條目長短：有沒有可能加長至超過小作品？有沒有可能寫成完美條目？
百年測試：一百年後，除了當事人的親戚，還會否有人對他感興趣？
不是自傳：是當事人或當事人近親以外的人寫的嗎？
Google測試：在Google或其他主要搜索引擎中是否有很多有關的條目？
檢查虛構情節：編寫虛構人物角色條目時，請務必閱讀本忠告。

参见

提議條文

跟任何百科全书一样，維基百科可能收錄重要的历史人物和卷进时事的人的條目。关注度决定了一個主题是否有编写独立条目介绍的必要。如果某个人物满足以下任一条件，则可假定该人物符合独立条目的收录标准：

符合通用關注度指引。
符合人物收錄條件其中任何一项。
符合運動員、學者、音樂人物與音樂團體关注度指引其中任何一项。

…… 参见

以下方法也可以用來測試某人物是否值得收錄於百科全書，但注意它们并非本指引的一部分，不能取代上面的收录标准。

大學教授測試：他是否比一個普通大學教授更廣為人知，或出版了更多的書籍？
確證測試：現在或十年以後，條目中的所有資料還可以被獨立確證嗎？
條目長短：有沒有可能加長至超過小作品？有沒有可能寫成完美條目？
百年測試：一百年後，除了當事人的親戚，還會否有人對他感興趣？
不是自傳：是當事人或當事人近親以外的人寫的嗎？
Google測試：在Google或其他主要搜索引擎中是否有很多有關的條目？
檢查虛構情節：編寫虛構人物角色條目時，請務必閱讀本忠告。

^ 關注度等於對主題進行深入介紹的獨立可靠來源。

--GZWDer（留言） 2021年2月20日 (六) 16:51 (UTC)[回复]

我修了一下。Fire Ice 2021年2月20日 (六) 17:08 (UTC)[回复]

(＋)支持。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月21日 (日) 02:54 (UTC)[回复]

(＋)支持:修訂版更清晰，這是屬於事實性修訂，可以在存檔後直接修改。--蟲蟲飛♡♡→♡℃※留言 2021年2月21日 (日) 03:57 (UTC)[回复]

(＋)支持，并做了部分语句修改。--痛心疾首 2021年2月21日 (日) 07:43 (UTC)[回复]

(＋)支持。 --無心*插柳*柳橙汁 2021年2月23日 (二) 13:22 (UTC)[回复]

(－)反对前面的修改可以认同，其他测试那一部分，在下建议建立为参见部分的三级标题。（修改后请通知我改票。）--懒癌哪天行_{→Lazy, as no today's excuse.} 2021年2月25日 (四) 08:18 (UTC)[回复]

“其他测试”到底有什么意义，为什么不能干脆删了算了。Fire Ice 2021年2月25日 (四) 08:32 (UTC)[回复]

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

@Fire-and-Ice：您也并未删除整节内容呀？与其问在下，不如您先回答一下，为何您要放到参见部分？--懒癌哪天行_{→Lazy, as no today's excuse.} 2021年2月25日 (四) 14:38 (UTC)[回复]

是@GZWDer放到参见部分的。至于参见下搞三级标题，我只能说闻所未闻了。Fire Ice 2021年2月25日 (四) 16:01 (UTC)[回复]

在下反对删除其他测试部分，理由：方针是给人读的，多一些能让更多人理解的内容有益处。--懒癌哪天行_{→Lazy, as no today's excuse.} 2021年2月28日 (日) 06:23 (UTC)[回复]

未见能让更多人理解，反而偏离了主题。Fire Ice 2021年2月28日 (日) 12:58 (UTC)[回复]

擬議快速刪除方針條文增修（A部分）

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:快速删除方针、Wikipedia talk:重定向。

由於依WP:R#DELETE第11款（帶有「(消歧義)」字樣，且無連入的重新導向）走AFD程序提刪的重新導向基本上都會被刪除，因此為加快相關重新導向的刪除處理程序，現擬議在WP:快速删除方针增加以下一條：

“

R8. 帶有「(消歧義)」字樣，且無連入的重定向。

在提請快速刪除前，請務必先檢查並清理相關重定向的連入。
如有用戶對應否使用消歧義及消歧義的方式存在未解決的爭議，則應交由存廢討論處理。

使用模板{{d|R8}}或{{d|r8}}。

”

如上述修訂獲通過，將會連帶修訂WP:重定向如下：

“

11. 帶有「(消歧義)」字樣，且無連入的重定向，可适用快速删除方针R8款。

”

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

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

怎么避免消歧义页改成重定向然后速删。比如限定存在已超过1年的重定向？--YF dyh000（留言） 2021年2月21日 (日) 05:32 (UTC)[回复]

@YFdyh000：擬議條文僅處理帶有「(消歧義)」字樣的重新導向。帶有「(消歧義)」字樣的重新導向通常不會重新導向至非消歧義頁面。如果是使用平等消歧義抑或主題目消歧義的爭議，依擬議條文，應交由存廢討論處理。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月21日 (日) 05:41 (UTC)[回复]

按新增条文，我可以将主题目消歧义的消歧义页改成重定向页（如重定向回主条目）、取消链入、改为顶注消歧义（或者单纯反对而不作任何消歧义），然后悄然请求速删其他人创建的消歧义页面，期间创建人可以不知情。我很好奇「(消歧義)」字樣的重定向的成因，似应避免，或者不管、保留。--YF dyh000（留言） 2021年2月21日 (日) 05:53 (UTC)[回复]

@YFdyh000：「改為頂注消歧義」仍是「應使用平等消歧義抑或主題目消歧義存在未解決的爭議」的情況（頂注消歧義為主題目消歧義的一種），依原提議條文，仍應交由存廢討論處理。就「單純反對而不作任何消歧義」一點，我已再更新提議條文，現提議條文在「單純反對而不作任何消歧義」的情況下應交由存廢討論處理。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月21日 (日) 06:05 (UTC)[回复]

(－)反对沒有甚麼價值，只是存不存在罷了-- Sunny00217 2021年2月21日 (日) 13:52 (UTC)[回复]

@Sunny00217：請你詳細解釋一下你的理由。我是想説，如果最後的結果必然是刪除，那根據WP:SNOW的思想，應該加快此類提刪的刪除程序。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月21日 (日) 23:42 (UTC)[回复]

你可以把我這張票視作無效反對票就是了，基本上個人認為這種提案沒有甚麼必要-- Sunny00217 2021年2月22日 (一) 09:48 (UTC)[回复]

不是「清除」連入，已改為「清理」。空氣小貓（留言） 2021年2月26日 (五) 12:57 (UTC)[回复]

擬議快速刪除方針條文增修（B部分）

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

現擬議修改快速刪除方針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)[回复]

擬議快速刪除方針條文增修（C部分）

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

這個其實不太像是擬議條文增修，我這裏想提議的是容許bot自動處理以CSD O4、CSD O7和CSD F7等幾條為理由的快速刪除請求，但為有效減低錯誤刪除的可能性，自動掛模板和自動進行刪除的動作必須分開，而且要間隔足夠的時間。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月21日 (日) 06:32 (UTC)[回复]

站务有这个需求吗。担心被破坏者利用。--YF dyh000（留言） 2021年2月21日 (日) 07:48 (UTC)[回复]

不清楚。可能需要一些數據，還有社群的看法。CSD F7被破壞者利用的可能性不太大。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月21日 (日) 08:54 (UTC)[回复]

F7不清楚，O7对保留派维基人来说可能是不建议用的。O4会被利用，见童孝賢（讨论 | 貢獻）。如果没有严重积压，不认为有必要引入机器人。如果机器人运转良好，也未见需要对方针有所修订。--YF dyh000（留言） 2021年2月21日 (日) 09:02 (UTC)[回复]

先放著，看看其他人的意見。O7被刪除的草稿我沒見過幾個人管（除刪除外）。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月21日 (日) 09:53 (UTC)[回复]

(※)注意

有時用戶不懂得加分類重定向，機器人會以O4提刪，管理員要手動加「分類重定向模板」，才能解決機器人反覆提刪分類重定向；而且之前機器人失靈，把已經放了分類重定向模板的頁面也提刪，因此必須有管理員判斷。
O7的頁面可以WP:AR還原，如果機器人自動刪除，但令WP:AR出現問題。
方針規定提刪和刪除必須兩個用戶，因此同一個機器人去提刪及刪除，又會與方針牴觸。
有時用戶會把合理使用的檔案轉載到共享，但原檔案不能F7刪去。
之前已經有很多機器人失靈，如果讓機器人自動刪除，風險很大。

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

@蟲蟲飛：（1）這應該是改善bot檢測設定的問題，而且上面我也提到自動掛模板和自動進行刪除的動作必須分開，而且要間隔足夠的時間，因此管理員應該是有時間檢查的。不過也考慮到YFdyh000上面的意見，這點我是開放討論的。（2）技術上沒有這個可能性。bot檢測的是最近6個月内是否有編輯，如果最近6個月内完全沒有編輯，bot才會挂模板，bot是不會理會最近6個月内的編輯是小修小補充還是大修改的，基本上一恢復頁面，並回退挂模板操作，就已經算是一次編輯，對bot而言最近6個月内的編輯就需要重算。（3）zhwiki早已開了大量的bot，另開一個abot或者改用另一個已有的bot不是難事（Jimmy-bot和Jimmy-abot就是兩個不同的bot）。（4）正如我上面提到，自動掛模板和自動進行刪除的動作必須分開，而且要間隔足夠的時間，因此只要設定的間隔時間合理，這問題並不大。（5）bot的運行狀況我建議讓bot的主人自己解釋，@Jimmy Xu。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月22日 (一) 12:18 (UTC)[回复]

Jimmy-bot算是現時技術最強的機器人，除了Jimmy-bot，還有其他機器能做到刪除工作嗎？如果沒有，就是同一個機器人同時進行提刪及刪除。此外，同一個主人的機器人，只能算一個用戶。--蟲蟲飛♡♡→♡℃※留言 2021年2月22日 (一) 12:23 (UTC)[回复]

@蟲蟲飛：Jimmy-bot是做不到刪除工作的，它沒有管理員權限，Jimmy-abot才有。理論上所有具有管理員權限的bot都能進行刪除工作，而本地除了Jimmy-abot以外，具有管理員權限的bot（也就是abot）至少還有Xiplus-abot一個。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月22日 (一) 12:42 (UTC)[回复]

對，Jimmy-abot才有管理員權限，但兩個機器人的主人都是Jimmy，因此只能視為一個用戶。--蟲蟲飛♡♡→♡℃※留言 2021年2月22日 (一) 12:46 (UTC)[回复]

所以我才把Xiplus-abot找出來啊，Jimmy Xu跟Xiplus總是兩個人吧。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月22日 (一) 12:49 (UTC)[回复]

我也ping一下新提到的當事人好了：@Xiplus。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月22日 (一) 12:44 (UTC)[回复]

1. 掛模板和刪除分開的邏輯很怪，假設A機器人的判斷標準比B機器人還準確，那麼為何不能修改B使其跟A一樣好呢？如果A跟B判斷標準一樣好，那麼無論是用1個還是多個機器人準確率都不會改變。 2. 留待人類檢查的問題，如果你們覺得需要人類檢查，那麼就應該直接讓人類做最終決策（刪除），而不是確認完了又放著，也會有沒有管理員複查到的問題。 3. 自提自刪的問題，如果機器人做得夠好，那麼修改方針給予機器人豁免不就好了，死抱著規則可是不好的唷^.＜。 4. 總之提案的重點應該是找到一個妥善處理速刪的流程，並將其轉換為程式碼，如果機器人做得到就應該讓機器人做，而不是讓管理員表現得跟機器人一樣。--Xiplus#Talk 2021年2月22日 (一) 13:34 (UTC)[回复]

（1）我説“掛模板和刪除分開”的最主要原因並不是準確度或需要人類檢查的問題，而是被告知者來不來得及反應的問題，我們還是要給一下反應時間，這也是為何提交快速刪除請求以後通常要通知建立頁面者。就説O7好了，廢棄6個月的草稿，如果建立者在那時候突然想再用草稿，他還是有時間直接把快速刪除模板移除掉，然後繼續編修草稿。WP:AR不是不方便，但不代表就必須走一次AR程序。（2）我是覺得上面三種（其實還有其他另外幾種）不太需要人類檢查，不然我也不會提議用bot處理，所以我認同你的觀點。（3）我本來也是想說豁免就好了，但我又怕蟲蟲飛之後又會像之前一樣再度使對話陷入無限鬼打牆循環，所以我就先避開了，當然我個人不反對豁免。另一方面是Jimmy Xu通常不太現身，所以即使不考慮避嫌的問題，找你的話增加bot任務的事情還是能處理的比較快一些。（4）認同你的觀點。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月22日 (一) 14:06 (UTC)[回复]

@Xiplus。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月22日 (一) 14:09 (UTC)[回复]

（1）然而就算是目前的處理方式，沒有規定掛板到刪除的期限，有個假裝是機器人的管理員在，建立者很難在被刪除前阻止，如要建立機器人的機制，建議採通知X天後刪除的機制（當然人類也要遵守）。另O4應該就不太需要這個等待期了？--Xiplus#Talk 2021年2月23日 (二) 01:25 (UTC)[回复]

可能要設定檢測期，檢查掛模板後1日內有沒有編輯（類似O7的6個月檢測期），以及有沒有{{hangon}}。如果掛模板後1日內有編輯，O7就肯定不用刪了，O4和F7而言可能是有人掛了{{hangon}}。O4還是需要等待期，YFdyh000上面說的事情還是值得憂慮的。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月23日 (二) 01:34 (UTC)[回复]

(※)注意:我上面羅列了那麼多問題，好像都被無視了。--蟲蟲飛♡♡→♡℃※留言 2021年2月23日 (二) 01:46 (UTC)[回复]

多是机器人能判断和避免的。--YF dyh000（留言） 2021年2月23日 (二) 03:07 (UTC)[回复]

（也就是説，上面羅列的問題不成問題。）SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月23日 (二) 04:25 (UTC)[回复]

(？)疑問:其實大家知道甚麼叫分類重定向嗎？--蟲蟲飛♡♡→♡℃※留言 2021年2月24日 (三) 02:58 (UTC)[回复]

(※)注意:不認為機器人有能力解決以下問題:

有時用戶不懂得加分類重定向，機器人會以O4提刪，管理員要手動加「分類重定向模板」，才能解決機器人反覆提刪分類重定向；而且之前機器人失靈，把已經放了分類重定向模板的頁面也提刪，因此必須有管理員判斷。有些管理員也會誤判。
O7的頁面可以WP:AR還原，如果機器人自動刪除，但令WP:AR出現問題。
有時用戶會把合理使用的檔案轉載到共享，但原檔案不能F7刪去。有些管理員也會誤判，不認為機器人有能力判斷版權。

以上。--蟲蟲飛♡♡→♡℃※留言 2021年2月24日 (三) 02:52 (UTC)[回复]

我究竟説過多少次了，2技術上不可能發生。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月24日 (三) 10:32 (UTC)[回复]

而且1也不是甚麽大問題，刪除了以後，重建時直接加{{cr}}就好。我沒見過挂了{{cr}}還是被自動提刪的情形，就蟲蟲飛説的那種情形，我認為{{cr}}很可能是被自動提刪後才挂的，然後蟲蟲飛又沒看過頁面歷史，結果產生了誤解；即使真的是挂了{{cr}}以後才被自動提刪，發生的機率實在太低，沒必要過度憂慮。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月24日 (三) 10:34 (UTC)[回复]

3來説，既然“有些管理員也會誤判”，那憑甚麽要求bot“解決（誤判的）問題”？即使誤判，走DRV程序恢復就好，沒甚麽大不了的。這提案本來就只是打算通過bot加快處理流程，僅此而已。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月24日 (三) 10:40 (UTC)[回复]

您沒看懂我的留言。總之，提案不但沒有解決問題，而且當前沒有問題，但提案反而製造了問題。--蟲蟲飛♡♡→♡℃※留言 2021年2月25日 (四) 03:55 (UTC)[回复]

不，這提案沒有製造任何的問題，而且上面所謂的“問題”要麽不可能發生，要麽就發生機率太低而不成問題。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月25日 (四) 09:07 (UTC)[回复]

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

這提案本來就只是打算通過bot加快處理流程，請問我是不是連提出一個加快處理流程的提議都不行？SAN MO SA _{江南好，風景舊曾諳} 2021年2月28日 (日) 05:27 (UTC)[回复]

您沒看懂我上面提到的問題。請再看一下o4、F7及o7的問題，尤其是o4、F7。您不能把機器人誤刪的問題全推給DRV去處理。--蟲蟲飛♡♡→♡℃※留言 2021年2月28日 (日) 05:42 (UTC)[回复]

為何？管理員自己誤刪也是給DRV去處理，對管理員的容忍度那麽高，卻對BOT一點都不容忍？提案的目的只有一個：加快。誤刪率不是我的重點，反正是不會加大的。SAN MO SA _{江南好，風景舊曾諳} 2021年2月28日 (日) 10:48 (UTC)[回复]

未见加快的必要，机器人无法辨识破坏者操作和误导，会增加反破坏的查证和复核成本。如果有同类任务积压，人工用机器人或脚本辅助还差不多。--YF dyh000（留言） 2021年2月28日 (日) 11:01 (UTC)[回复]

提案重启“新设删除员权限”讨论

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:删除员（錯誤：Wikipedia talk:删除员是重定向頁面）。

“新设删除员权限”讨论最初由User:Kuon.Haku在两年前开启，但最终结果为“暂不予设立”。最近站内存废讨论、侵权验证积压日渐增多，本人强烈建议重启此讨论。不同于管理员，删除员并不具有封禁权和保护权这两个比较敏感的权限，但也可以帮助管理员减少积压。

删除员具体权限以及先前草案全文设在Wikipedia:删除员，先前讨论已存档于Wikipedia_talk:删除员，欢迎大家踊跃参阅并加入讨论。--YOWOT868※✌️Tie Up A Habit. 2021年2月21日 (日) 13:44 (UTC)[回复]

(＋)支持本提案，申请方面(＋)支持虫虫飞提案（偏向本提案）与提案2（修改），除权方面(＋)支持提案2（修改）。--海の向こうは敵だ！|欢迎订阅维猫报！ 2021年2月21日 (日) 14:02 (UTC)[回复]
(＋)支持提案，分担管理员工作，降低相关权限的上任与解任难度。赞成提案1；提案2的“酌情”、“也可”太模糊了，落选管理员自己再参选删除员就好；考题有点模糊。除权支持提案2，清晰明确，唯“快速除权”应更名“紧急除权”，参考管理员的紧急除权标准，并在落实原因后可根据共识和行政员决定直接复权或重新参选。解任后重新参选条件、不活跃除权等有待完善。--YF dyh000（留言） 2021年2月21日 (日) 14:21 (UTC)[回复]
積壓一點也不多啊，發起理由完全不成立。--A T 2021年2月21日 (日) 14:28 (UTC)[回复]
没太关注站务，但解任投票和这里都有人说站务有积压情况——虽然不一定是存废，但存废和侵权验证是很大占比、很费时间的，分摊一些没什么不好，有权用户的增多也能促进一些关注和讨论。悄悄滥用是另一层面，更低的解任和提报难度可弥补。--YF dyh000（留言） 2021年2月21日 (日) 14:50 (UTC)[回复]
(－)反对目前的方案：“删除”权限并不是比“封禁”、“保护”更为不敏感的权限；就本人的观察而言，条目删除对新用户的打击有时并不亚于直接对该用户施与封禁。运用删除权限也意味着提名人需时刻具备向受影响用户解释自己删除操作的能力，而这是管理员的核心能力之一。因此，不应该设立当选门槛低于管理员的删除员。--Antigng（留言） 2021年2月21日 (日) 14:35 (UTC)[回复]
1. 就我个人的观察，PJ:AFC对新用户的鼓励与打击程度可能是同等的，期望在意新手的维基人和"提案人'予以关注。2. 不认为提名人无法做到解释自己的删除操作，如果做不到那么离被解任已经很近了，且比管理员更近，部分管理员反而因事务繁忙、解任难度高、疲劳感等原因不详细解释自己的操作依据，或者无视其他人的理由或意见。3. 删除员担任经历可能成为晋升管理员的一步，同时缓解站务压力。4. 其他管理员和删除员可以还原并重启不合适的处理（可能需方针修订；当然，WP:DRV也不错；需明确删除员能否处理DRV，大概是不能）。警告模板和其他不友好行为对新手的打击同样巨大，不是禁止更多人参与站务的理由。--YF dyh000（留言） 2021年2月21日 (日) 15:22 (UTC)[回复]
AFC本意上是帮助新手更好建立条目，不过我参与该计划以来好像就没有通过几个条目……虽然确实对新手打击较大，但我也不知道怎么更好平衡条目质量与保护新手两方面。--Lightyears_{Talk·Sign#订阅维猫报喵！} 2021年2月22日 (一) 15:19 (UTC)[回复]
没用AFC提交过，很认可帮助新手和同行评审理念，但实务执行中显然存在问题、似乎小圈子。我认为很简单，增加一个阶段，条目内容满足关注度和基本素质（即基本合格。削减后可作小作品），但内容可进一步完善，这种情况下不要驳回为不通过（尤其是通用意见），会使新手以为现有内容不对、这仍不是合格的条目、做了无用功。状态可以是绿色的合格标识附评语，并等待编写人反馈后续意向，或者移到条目但保留隐藏分类，继续在条目讨论页讨论完善。发现您似乎创建了AFC的两个TG群，您能否转交意见和尝试推进讨论（可以ping我）。--YF dyh000（留言） 2021年2月22日 (一) 16:25 (UTC)[回复]
已在您的讨论区留言，我们似乎离题太远，接下来的交流我们可以在您的讨论区进行。再次感谢您的宝贵意见。--Lightyears_{Talk·Sign#订阅维猫报喵！} 2021年2月23日 (二) 04:29 (UTC)[回复]

感觉此用户组没有非常大的必要，在和RFA门槛相比差不多的情况下，既然通过的人可以妥善处理删除和恢复，那么我也会相信那个人不会滥用封禁和保护，这个用户组的权限效果和赋权门槛不易平衡，可能只适用于某人确实只需要删除和恢复权限，实在不想处理其他事务的场景。在这种情况下，在申请方面我本是倾向支持提案2，不过投票只需是自动确认用户即可投票，门槛太低。故门槛部分支持虫虫飞版，需任巡查回退一段时间，否则可能会不熟悉删除方针；除权倾向支持提案2。--安忆 ^Talk 2021年2月21日 (日) 14:36 (UTC)[回复]
- 管理员上任投票的提问量和标准我认为过头了，有些人希望上任管理员是多面手、熟练工。模板编辑、界面编辑的分离也是这个趋势，权限就应该“没什么大不了”，当事人善用、不会滥用就应该有权限。关于条件，我倾向看效果再改、更多关注（如试用期），巡查和回退似乎不足以了解存废讨论的流程和习惯。--YFdyh000（留言） 2021年2月21日 (日) 14:50 (UTC)[回复]
  - (～)補充：或许还可以参考下被提名人的AFD和CSD日志。--安忆 ^Talk 2021年2月21日 (日) 14:52 (UTC)[回复]
    怎么说呢…“删除”是一个比较打击编者的操作，我不认为连管理员都感到棘手的删除任务靠独立出来的删除员就能做好。申请门槛低了显然不行，可能会乱删，但较高的申请门槛却只带来了删除和还原，我所能想到的申请心态只有上面提到的“只需要”的情况。有时候在删除的同时又需要保护和封禁，难不成这时候还要再提几个请求？感觉未免有些多此一举。在这种申请门槛和实行情况下，那个人还不如考虑直接申请管理员。--安忆 ^Talk 2021年2月21日 (日) 15:15 (UTC)[回复]
    那可以劝慰避免或者条文禁止处理棘手议案。删除同时要保护和封禁，是反破坏吧，管理员可以着重处理WP:VIP，删除员也可以快速处理广告速删（判定层面是个问题，但管理员未必就做的更好）。--YF dyh000（留言） 2021年2月21日 (日) 15:27 (UTC)[回复]
  - 技术和普通站务维护是相对平行正交的维度，但是站务管理中的“封禁”、“删除”与“保护”则不然，不宜将IA/TE的设立作为设立删除员的论据。--Antigng（留言） 2021年2月21日 (日) 14:55 (UTC)[回复]
    不太赞成是平行维度，不太懂您的意思。也可理解为我认为将管理员的反破坏职责与站务职责在概念上分拆是好事。--YF dyh000（留言） 2021年2月21日 (日) 15:10 (UTC)[回复]
    - 已修改措辞为“正交”，抱歉先前用词不当。--Antigng（留言） 2021年2月21日 (日) 15:21 (UTC)[回复]
    Antigng的意思可能是IA/TE主要的着力点都不是和条目相关的方面，而普通站务维护是。--安忆 ^Talk 2021年2月21日 (日) 15:18 (UTC)[回复]
  基本同Antigng，反对。权限就应该“没什么大不了”，所以应该要改变的是管理员上任投票的提问数量问题，而不是设立删除员。另外，若一个用户真的能通过适当的程序，被证明能合理运用删除权限，那么此人就具备对方针的完善理解、足够的自我控制和反省能力以及良好的沟通技能。既然如此，此人已经适任管理员；若并非如此，则此人在删除相关工作中也会遇到麻烦。别忘了草案中还包含了存废复核、修订版本删除等比较复杂的事务，此类站务若出现积压，则更多是由于缺乏执行的共识，而非大家忙得要死顾不过来。--Tiger（留言） 2021年2月21日 (日) 15:20 (UTC)[回复]
  对于存废复核和修订版本删除，个人也倾向反对，在没有出现积压前，存有争议或操作不显著的权限不适合授权，至少不适合新任删除员使用。--YF dyh000（留言） 2021年2月21日 (日) 15:35 (UTC)[回复]

(－)反对：現在這個時候設立權限，我認為會讓個別管理員無視規則單憑個人好惡刪除特定頁面的情況變得更為嚴重（變成管理員以外的人都會這樣做），這是申請門檻沒辦法處理的事情，老用戶這樣做的潛在可能性更高。另一方面，我擔憂會引來權限收集的問題。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月21日 (日) 23:52 (UTC)[回复]

(！)意見：中维大校遍地都是，少将却是寥寥无几，更何况中将，上将了。Zhuofan Wu^{Cien años de soledad} 2021年2月22日 (一) 03:05 (UTC)[回复]
(＋)傾向支持：可以协助处理站务积压，方案方面均支持提案二。不过删除员是否可以选择处理CSD和AFD而非DRV？个人觉得DRV争议比较大。--Lightyears_{Talk·Sign#订阅维猫报喵！} 2021年2月22日 (一) 15:15 (UTC)[回复]
- 该等限制尚无技术手段能够实现。--Antigng（留言） 2021年2月22日 (一) 15:57 (UTC)[回复]
  可以使用方针限制，不过我认为此案最后会得到和这个差不多的结论。--安忆 ^Talk 2021年2月22日 (一) 16:02 (UTC)[回复]
  
  不需要技术手段，违规处理可以发还讨论、警告和必要时除权。--YF dyh000（留言） 2021年2月22日 (一) 16:28 (UTC)[回复]
  
  同意安忆的想法，可以通过方针限制。下面也有设立两个用户组的想法。--Lightyears_{Talk·Sign#订阅维猫报喵！} 2021年2月23日 (二) 10:36 (UTC)[回复]
(－)反对，同Antigng和Tigerzeng，不认为有此必要。如果是因为选管理员的问题，那么应该去想办法解决管理员难选的问题，而不是通过这种方式绕过去--百無一用是書生 (☎) 2021年2月23日 (二) 02:40 (UTC)[回复]
已經有不少封禁及編輯禁制是由刪除頁面產生的爭議引起，刪除員的判斷能力與信任度的門檻不會比一般管理員低。--Uranus1781（留言） 2021年2月23日 (二) 04:41 (UTC)[回复]
(＋)支持设立删除员，但(－)反对权限中包含的“删除和恢复页面的特定版本“及处理DRV。个人认为这些动作需要更受信任的管理员进行处理。对于细节，支持虫虫飞的提议（否则就又变成选管理员了 囧rz……）。支持设立删除员的原因：该权限略不同于管理员权限。个人认为“封禁”和“保护”等管理员操作较“删除”相比，更加“敏感”，需要操作人员更具备社群信任。因此支持设立删除员。且本人看到AFD和侵权验证有时会有部分积压。--Yining Chen（留言|签名） 2021年2月23日 (二) 06:50 (UTC)[回复]
- (～)補充：对于“删除和恢复页面的特定版本”，是否可以模仿自动确认用户的方式，让某名用户在担任删除员n个月后或进行m笔删除操作后自动具有该权限？--Yining Chen（留言|签名） 2021年2月23日 (二) 07:01 (UTC)[回复]
  - 人工评议后授权更好，资历不能证明什么。大概需要两个用户组，删除员、高级删除员（含存废复核和修订删除）。--YF dyh000（留言） 2021年2月23日 (二) 07:10 (UTC)[回复]
    (＋)支持。删除员处理CSD和AFD，而高级删除员可以处理DRV。--Lightyears_{Talk·Sign#订阅维猫报喵！} 2021年2月23日 (二) 10:34 (UTC)[回复]
    分設兩級可見本人以下建議。--LuciferianThomas．留言 2021年2月23日 (二) 11:08 (UTC)[回复]

(＋)不反對將刪除權限局部下放，但我覺得非管理員不適宜處理帶有爭議的存廢，而是比較適合處理符合快速刪除標準或明顯違反方針指引而沒有版本可以回退的頁面和頁面歷史。

(＆)建議可設「維護員」一職，設兩級制：

初級維護員同時擁有巡查權及回退權；
二級維護員同時擁有巡查權、回退權及刪除權。

設立維護員及建議申請安排如下：

巡查員及回退員的申請逐步暫停受理；
初級維護員的申請安排跟從現時回退員／巡查員申請模式，首次申請有期限授予回退、巡查權，試驗期屆滿可再次申請，由行政員判斷是否予以升任二級維護員（即授予刪除權）、只予續任或除權。
現時已經擁有巡查權或回退權超過一定時間（如六個月），活躍參與反破壞事務且能證明其能恰當使用權限的用戶可直接申請成為維護員，由行政員判斷授予二級或初級維護員身份；
- (～)補充：「活躍參與反破壞事務」可指申請當下符合回退員申請要求，因某些原因而短暫（三個月內）維基假期可酌情處理。
現時同時擁有巡查員及回退員身份之用戶自動獲得初級維護員身份（權限相同，不必重複申請）；
現時只擁有上述兩個身份之一的用戶在期限內未申請新職位視為放棄巡查權及回退權。
- (～)補充：若通過設立此職位，務必透過用戶討論頁通知此類別用戶，自己看不到就自己問題（當然，可容許這些用戶容後再次申請，但行政員怎麼想我就不知道。

同上本人所述，維護員不建議處理有爭議的存廢，但一般的速刪等工作則可執行。擁有此權限的用戶所受的限制（尤其是使用刪除權限方面）必定比現有回退員、巡查員更嚴格。設立維護員一職可減少以至防止WP:HATC行為；未來更可成為申請管理員一職的指標。希望以上意見能被考慮。--LuciferianThomas．留言 2021年2月23日 (二) 11:06 (UTC)[回复]

您的意思是取消巡查员与回退员两者，改用维护员？那门槛如何设置，依照250还是1000？其次，我还是认为“二级维护员”需要社群讨论后授权，而不是管理员授权。--Lightyears_{Talk·Sign#订阅维猫报喵！} 2021年2月23日 (二) 12:24 (UTC)[回复]

1.比删除员好听。2.权限集成也许不利于快速成长（熟悉权限、规范和任务）和上任解任（巡查的门槛和后果比删除低得多；可能担心影响站务而忽视解任意见）。不赞成改变现有巡查员和回退员机制，动静太大（方针修改）、收益不大。未必叫初级、二级，初级听上去不那么靠谱，以及“升级”或增加HATC行为。3.个人赞成权限分离，那样还可以剥夺部分权限（类似编辑禁制）。以及或可考虑警告+禁制（移除特定权限x周）之类的更灵活处罚（比如模板编辑员目前是一次严重违规就解任）。x. 如果管理员（sysop）叫站务员或操作员就更好了，可惜不可能。--YF dyh000（留言） 2021年2月23日 (二) 12:26 (UTC)[回复]

(－)反对取消巡查员一职, 个人认为巡查权不仅可帮助改善维基百科, 而且还可让刚接触维基百科的用户更好的熟悉站务. --Yining Chen（留言|签名） 2021年2月23日 (二) 13:58 (UTC)[回复]

這個意見不可能被接受，至少在「有些使用者只想專注於回退破壞，而有些只想巡查」的前提下就不可能，更何況刪除權只能由值得信賴的使用者操作，與經驗無關。--空氣小貓（留言） 2021年2月27日 (六) 15:39 (UTC)[回复]

(！)意見：有些管理員專精於特定項目，比如技術、條目合併、字詞轉換等等，不一定要全能。「如果」社群覺得對刪除員的信任度幾乎必須比照管理員，其實也就不需要增設刪除員，而是需要專精刪除的管理員。為了補足人力，可以直接徵招對AFD/DRV事務有興趣與自信者申請管理員。相對於{{Template:User_noAdmin}}，可設計一個【這個用戶想成為管理員，尤其對XX有熱忱。】的使用者模板，XX為模板選填參數。有志者先於使用者頁面加入該模板，再積極參與AFD/DRV，現任管理員見其模板也可加強傳授指教之；自薦申請管理員時主動表示志在AFD，社群便可按其表現優先支持，因為「社群覺得對刪除員的信任度幾乎必須比照管理員」，可信的刪除員也差不多就是可信的管理員了。以上淺見。--Hjh474（留言） 2021年2月23日 (二) 13:43 (UTC)[回复]

除非受提名管理员的操作特征非常明显（如专注技术），不然投票和问答总会是方方面面，基于个人好恶。除了提升权限拥有者数量，新权限或许能促进一些讨论和新鲜血液的补充、进阶。--YF dyh000（留言） 2021年2月23日 (二) 13:57 (UTC)[回复]

管理员不是全能的。如果参选者都表明了自己当选之后的行动方向，还被问一些奇怪问题的话，也挺令人无语的…既然不强制参选者回答所有问题，建议就直接将其忽视掉（如果是我的话）。--安忆 ^Talk 2021年2月23日 (二) 14:09 (UTC)[回复]

印象中不少问答质询针对具体类别或案例，不少人将管理员上任当成/盼作解决自己关心问题的“灵丹妙药”。奇奇怪怪、刁钻疑难的问答，以及不信任特定类型操作能力的意见，对管理员上任是个不小的、不一定需要的挑战。就管理员上任难度问题，另一个方法是试用期。--YF dyh000（留言） 2021年2月23日 (二) 14:20 (UTC)[回复]

試用期+1，建議不可太長。但因為RFA常常耗費社群相當多精力，因此試用期結束後的續任機制，得要想一下。。。--Hjh474（留言） 2021年2月23日 (二) 14:28 (UTC)[回复]

我认为30天（或者4周）适合。RFA可以投票基本达标（如14天内净支持票数>??）后进入试用阶段和授权，阶段结束后讨论总结是否解任（行政员按共识判定），期间有不足也可多次警告和必要时解任。不能解决非试用期解任难度问题。不好意思又跑题了……--YF dyh000（留言） 2021年2月23日 (二) 14:47 (UTC)[回复]

试用期不可取，难以定论这个期限有多长，又按什么标准，在我看来只是在为了自己心中的标准二次投票罢了。有问题就和对方说，说过了对方知道了但改不掉却还继续做的话就看情况提除权，没什么大不了的；话说RFA的问题是真的千奇百怪，有的人就是要的圣人，而不是什么管理员、删除员或是什么其他的，严以律人宽以待己。

说回这个删除员，它的很多标准注定是模糊的、量化不了的（包括选举、用权和除权等各个阶段）。管理员的3000次编辑很高吗？其实不是，有的人一周不到就能刷完，所以这类门槛意思意思就行了；假设真有这个删除员了，既然人家是按信任投票上去的，还要人家做管理员的活，那就不要再吝啬自己的信任整什么分级试用等等花活。有人愿意贡献，那就选他，选上来不是做得非常差就够了（不要完美要一般）。况且，什么是做得好？是不犯错是好，还是做得多是好？这看似简单的问题都没办法量化。反正不可能做得又多又没错，因为做得多了肯定会有不合某人意得时候。到时候又会被人翻出某笔远古编辑说话。本来就是闲暇之余做做贡献，居然还要志愿者去打怪升级又不给装备，这恐怕不太合适。我能想象日后是什么光景——做得好没什么人夸，做不好却又有可能被跳出来的一大堆人说。有的人已经忘了“人非圣贤孰能无过”、“知错能改善莫大焉”这些简单的道理。

同意时昭的看法，如果是因为选管理员的问题，那么应该去想办法解决管理员难选的问题，而不是通过这种方式绕过去，没必要单设用户组（甚至还要细分分级）。管理员可以是删除员，反过来也完全可以。值得信任的人、靠谱的人知道自己会做什么、要做什么以及应该做什么。一个是管理员的删除员，多出来的管理员权限可以更好地帮他处理遇到的问题；相反，一个不是管理员的删除员，遇到问题反而会施展不开。都是差不多的标准上去的，后者为的是什么，难不成是为了在删除又需要保护和封禁的时候，再提几个请求刷刷编辑数？

以上是我又看了看历史RFA/RFDA啰嗦的几句，希望不要有人介意。--安忆 ^Talk 2021年2月23日 (二) 15:39 (UTC)[回复]

感谢您的意见。我认为社群将RFA视作全能管理员选举的问题中短期内无望解决、无法达成共识，或许还不如尝试分拆权限、快速调整来变相演进。就好似Chrome和Windows 10的快速版本周期，即便屡被吐槽，照样有一定的推进效果，避免大体量的难以调整。--YF dyh000（留言） 2021年2月23日 (二) 16:33 (UTC)[回复]

又是因为“种种变动牵扯方面过多且复杂，其影响虽深远却现时利益不足”啊…不去推动是永远也没办法前进的，分层/拆分只是在拆了东墙补西墙，剪不断理还乱却又增加新问题。不过也可以理解。--安忆 ^Talk 2021年2月23日 (二) 16:51 (UTC)[回复]

YF君：了解您的意思。為了補足人力，並非反對增設，只是提出另一選項，因為會擔心刪除員效果不彰，比如社群不信其判定，或上任後卻因故不積極處理存廢。。。--Hjh474（留言） 2021年2月23日 (二) 14:12 (UTC)[回复]

(～)補充：以專精存廢的管理員取代刪除員也許還有其他優點。刪除員可使管理員AFD工作量下降，但因位階較低，DRV工作量可能反而上升，不服者可能會期待有管理員出來否決刪除員。--Hjh474（留言） 2021年2月23日 (二) 13:59 (UTC)[回复]

(※)注意更值得關注的認為是可能出現的大規模即時提交，即時刪除的無可挽救風險。而這個一旦發生，本地原有的機制是否可衡常發威也是個問題。(？)疑問提案是否清晰考慮過這些。--約克客（留言） 2021年2月28日 (日) 04:21 (UTC)[回复]

(－)反对：被提交到afd的條目（大部分提刪理由是關注度）其實不用急著刪除，哪怕積壓一段時間也沒問題，從站外非維基人的評價來看很少有人會批評「維基存在低關注度條目」，反倒是有人吐槽亂刪條目[28][29]，所以afd積壓並非緊急站務，無需額外設置刪除員。--Googol19980904（留言） 2021年2月24日 (三) 05:11 (UTC)[回复]
(－)反对，删除页面主要是管理员的职能，若要把这一权限单独授予，选出来的用户必定是受到社群高度信任的用户，若其门槛低于管理员，我觉得是无法接受的。另外，也未见AFD相关站务的明显积压，提案发起的理由都不太成立。——BlackShadowG（留言）_{维基百科20岁生日快乐！} 2021年2月24日 (三) 13:11 (UTC)[回复]

(－)反对，能成為刪除員，也必定能成為管理員，因為兩者都必須值得信賴，拆分管理員權限並不能解決什麼。空氣小貓（留言） 2021年2月27日 (六) 15:34 (UTC)[回复]

(＋)支持但同時建議可以約束刪除員在正常情況下僅能處理CSD這類有即時處理必要的頁面。--銀河市長—☎️— 2021年2月28日 (日) 02:49 (UTC)[回复]

(～)補充意見類似LuciferianThomas我覺得可以設檢修員，同時直轄巡、退權，分初、高階，但初階就包含現在刪除員的權限，高階則多封鎖權、保護權畢竟我覺得封鎖權更需要下放，不然許多條目的歷史頁都可見回退戰，但所有檢修員做出的封鎖、保護、刪除都需上報WP:待審查管理。--銀河市長—☎️— 2021年2月28日 (日) 03:14 (UTC)[回复]

(～)補充但不取消巡、退員。--銀河市長—☎️— 2021年2月28日 (日) 03:21 (UTC)[回复]

Wikipedia:格式手册/两岸四地用语及Wikipedia:格式手册/朝鲜半岛用语

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:格式手册/两岸四地用语、Wikipedia talk:格式手册/朝鲜半岛用语。

現建議在Wikipedia:格式手册/两岸四地用语修改以下條文：

現行條文

下級行政區劃依據「使用常用名稱原則」，若非描述法理狀況，在描述兩岸下級行政區劃所屬的國家時，應以事實論述為主。

提議條文

下級行政區劃若非描述法理狀況，在描述兩岸四地下級行政區劃所屬的國家時，應以事實論述為主。

並在Wikipedia:格式手册/朝鲜半岛用语增補以下條文：

“

下級行政區劃若非描述法理狀況，在描述朝鮮半島南北政權下級行政區劃所屬的國家時，應以事實論述為主。

”

以上。SAN MO SA _{誓山海而長在，似日月而無休} 2021年2月24日 (三) 01:03 (UTC)[回复]

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

最近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)[回复]

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

买卖维基百科的账户是否合规

请问出售维基百科的账户是有偿编辑，还是使用傀儡，因为如果一个新手购买了自确账户就可以规避掉很多自确前的限制，而且很可能会增多破坏者，所以请问维基百科是否有对账户买卖的限制--喵呜CAT 　来讨论嘛　 2021年2月28日 (日) 01:21 (UTC)[回复]

目前有这样的情况吗？--Lightyears_{Talk·Sign#订阅维猫报喵！} 2021年2月28日 (日) 01:43 (UTC)[回复]

无论有无这都是一个较为严重的方针问题，如果有人这么做会对已有方针做出冲击和对维基百科进行可能的破坏—喵呜CAT 　来讨论嘛　 2021年2月28日 (日) 01:51 (UTC)[回复]

而且这样破坏者获得一个自确账户就更快了，甚至可以在几天内拿到一堆自确账户进行破坏编辑，而你根本无法把他确认为一个人，因为他可以换手机，换浏览器，使用代理，用毫无关联的自确账户—-喵呜CAT 　来讨论嘛　 2021年2月28日 (日) 01:54 (UTC)[回复]

WP:ROLE：「不容許建立一些由多人共享的角色帳號」；WP:NOSHARE：「所有與他人分享帳戶的行為（包括分享帳戶密碼）均被禁止」。並可能比照被盜用的帳號直接全域鎖定帳號。--Xiplus#Talk 2021年2月28日 (日) 01:55 (UTC)[回复]

我指的是出售，不是共享，共享指多人同时使用，而出售后仅有一人使用—喵呜CAT 　来讨论嘛　 2021年2月28日 (日) 03:00 (UTC)[回复]

前一留言後半已說明共享的定義。--Xiplus#Talk 2021年2月28日 (日) 07:19 (UTC)[回复]

但是分享可能严格来说并不能算是出售和交易，分享更多是无偿的，我希望能够单独就买卖账户建立新方针或者扩充已有方针—喵呜CAT 　来讨论嘛　 2021年2月28日 (日) 10:20 (UTC)[回复]

@喵呜猫：分享不是这个定义，此条文指将账号控制权交由他人被发现即会被封禁。类似情况有方针上文的“公司/团体名称”，禁止了组内多人持有同一个账号。花钱买账号，大概率还涉及有偿编辑或利益相关。--YF dyh000（留言） 2021年2月28日 (日) 10:43 (UTC)[回复]

要有自動確認用戶願意賣，您的擔憂才成立。-游蛇脫殼/克勞棣 2021年2月28日 (日) 10:28 (UTC)[回复]

如果有人愿意买，肯定有人愿意卖，可以“量产”。--YF dyh000（留言） 2021年2月28日 (日) 10:44 (UTC)[回复]

既然可以「量產」，為什麼不自己生產，還要花錢買？而且想買的人要如何讓人知道他想買？更重要的是，「拿到一堆自确账户进行编辑」本身就已經違規了(傀儡)(會招致懲罰)，不論是否進行破壞。破壞維基百科又沒錢賺，我好奇誰會花錢做這種損人又損己、徒勞無功的事。是不是我太天真？-游蛇脫殼/克勞棣 2021年2月28日 (日) 11:11 (UTC)[回复]

1.需要一些技术和时间（>7天），分工不同，就像代理服务器有人卖、验证码打码有人卖，什么都有人卖。2.如果商品有市场，自然有市场在卖。3.可以绕过半保护和一些反破坏机制。公关公司、饭圈粉丝等，都可能买。这也是WP:CU的作用之一。--YF dyh000（留言） 2021年2月28日 (日) 11:18 (UTC)[回复]

通过水编辑和自动编辑脚本可以实现无成本的高速量产，并且可以以极低的价格出售，同时也一定有人去买（比如某明星狂热粉丝为了给“偶像”刷数据，但是又没时间编辑维基百科）而且通常会造成破坏，这是我的担忧——喵呜CAT 　来讨论嘛　 2021年2月28日 (日) 14:44 (UTC)[回复]

重提Wikipedia:集中讨论


问题背景	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)[回复]

[1] 關注度等於對主題進行深入介紹的獨立可靠來源。

[註 1]

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

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

正在廣泛徵求意見的議題

專題命名空間

專題空間設立流程與細節

第一階段：申請

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

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

第二階段 之 公示狀態通告

第二階段 之 公示期討論

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

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

第四階段：調整專題模板

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

第六階段：(暫不開放)

偽命名空間

小结1

小结2

捷徑空间提案

小結3

再提捷徑空间提案

尝试推动LTA空间

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

進一步討論

自動提刪R2

MOS捷徑名稱

軟重定向

技術問題處理

自動半保護偽命名空間

提議設立快速刪除標準 O8

將LTA空間設定為noindex

WP:捷徑指引草案修訂

說明

專題命名空間問題

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

捷徑細部修訂

建议删除姓氏分类

關於Wikipedia:命名常规#使用外文命名时的专门要求，請問音樂作品名稱是否能算是專有名詞？

音樂條目命名選擇方向

音樂作品不屬於專有名詞

命名時以官方名稱為優先

意見

總結

國際關係條目命名常規

悬挂Blocked user模板之利弊

維基百科:管理員解任投票潛在漏洞

將Wikipedia:回退功能#移動時不留重定向合併到Wikipedia:重定向#移動時不留重定向

用户名修改与订阅

修正WP:PB條文內容

（續）現行日期和數字格式手冊條文調適

Wikipedia:格式手册/标点符号#冒号增訂

修订维基百科:关注度 (人物)

擬議快速刪除方針條文增修（A部分）

擬議快速刪除方針條文增修（B部分）

擬議快速刪除方針條文增修（C部分）

提案重启“新设删除员权限”讨论

Wikipedia:格式手册/两岸四地用语及Wikipedia:格式手册/朝鲜半岛用语

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

买卖维基百科的账户是否合规

重提Wikipedia:集中讨论

第二階段之公示狀態通告

第二階段之公示期討論