本页使用了标题或全文手工转换

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

维基百科，自由的百科全书
跳到导航 跳到搜索

快捷方式
Breezeicons-apps-48-cantor.svg

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


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

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

公告板
# 話題 發言 參與 最新發言 最後更新(UTC+8)
1 專題命名空間 163 19 A2569875 2021-03-03 13:17
2 偽命名空間 208 18 YFdyh000 2021-03-03 23:22
3 WP:捷徑指引草案修訂 14 4 A2569875 2021-03-03 13:21
4 關於Wikipedia:命名常规#使用外文命名时的专门要求，請問音樂作品名稱是否能算是專有名詞？ 86 27 Milkypine 2021-03-03 13:10
5 國際關係條目命名常規 23 6 YFdyh000 2021-03-04 22:44
6 悬挂Blocked user模板之利弊 12 7 CreeperDigital1903 2021-02-26 18:28
7 維基百科:管理員解任投票潛在漏洞 16 11 Ericliu1912 2021-03-01 14:34
8 將Wikipedia:回退功能#移動時不留重定向合併到Wikipedia:重定向#移動時不留重定向 24 5 Hjh474 2021-03-01 18:29
9 Wikipedia:格式手册/标点符号#冒号增訂 6 4 Sanmosa 2021-03-01 18:37
10 修订维基百科:关注度 (人物) 20 7 Fire-and-Ice 2021-03-03 17:31
11 擬議快速刪除方針條文增修（A部分） 10 4 Pseudo Classes 2021-02-26 20:57
12 擬議快速刪除方針條文增修（B部分） 26 4 YFdyh000 2021-03-04 22:16
13 擬議快速刪除方針條文增修（C部分） 39 4 YFdyh000 2021-03-03 22:18
14 提案重启“新设删除员权限”讨论 58 20 Longway22 2021-02-28 12:21
15 Wikipedia:格式手册/两岸四地用语及Wikipedia:格式手册/朝鲜半岛用语 5 2 Sanmosa 2021-03-01 18:51
16 有關某年代相關分類命名統一事宜 31 10 YFdyh000 2021-02-27 05:01
17 买卖维基百科的账户是否合规 14 5 喵呜猫 2021-02-28 22:44
18 重提Wikipedia:集中讨论 3 3 BlackShadowG 2021-03-04 22:08
19 在格式手冊/標點符號#引号中加入 POV 一節 15 4 BlackShadowG 2021-03-04 21:49
20 關於快速刪除G8 4 3 Xiplus 2021-03-02 22:06
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時，
請先檢查設定是否有誤

專題命名空間[编辑]

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

[編輯此導航模板]

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

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

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

本討論的各階段分為：

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

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

專題命名空間通過，剩餘細節獨立討論。臺灣杉在此發言 (會客室) 2021年1月11日 (一) 11:20 (UTC)
目前的後續討論須等phab:T271612佈署完畢後才能繼續進行。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月12日 (二) 13:08 (UTC)

已通過：

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

下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

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

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

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

  1. 英文命名部分，其一為Project並取消與Wikipedia空間連動，其二為以WikiProject命名；
  2. 部分使用者認為直接將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)
確定英文名稱不會衝突就可以，中文名稱應該沒問題。SANMOSA SPQR 2020年12月12日 (六) 03:34 (UTC)
支持命名为WikiProject/专题 ——羊羊 (留言|贡献) 2020年12月16日 (三) 15:08 (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)
  • 既然木已成舟，大家意見如此，我也沒法反對什麼，但是請提案者一定要做好配套措施，以免留給本地社群一堆爛攤子去收。—— Eric Liu 創造は生命（留言．留名．學生會） 2020年12月31日 (四) 11:32 (UTC)
  • 自上周補充公示共識內容的發言 2020年12月26日 (六) 12:47 (UTC)後已公示逾一周，公示期內無合理異議，本議案通過。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月3日 (日) 07:44 (UTC)
本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

專題空間設立流程與細節[编辑]

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

  1. 向phab:提交申請設立專題空間；
  2. 將專題頁與討論頁批次移動到專題空間（可能需WP:FLOOD）；
  3. 修正指向專題的內部連結（可能需WP:FLOOD）；
  4. 調整專題模板；
  5. 討論重新導向與捷徑的設立方式；
  6. 其他議題。
以上。以上流程不會立即執行，會在社群對流程沒有異議之後公示後執行。如有其他相關疑問可繼續在下方討論。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月3日 (日) 07:44 (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)
    • (：)回應@羊羊32521：該名稱主要是介面顯示的名稱（如左上角顯示[維基專題][討論][不转换]_____[閱讀][編輯][歷史]☆[更多∇][TW∇][搜尋維基百科🔍]），而關於簡潔與否問題，由於有同步申請別名，因此亦可以透過輸入專題:XXX連結到專題頁，並不一定要寫全名維基專題:XXX（參考預計命名）。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月3日 (日) 19:42 (UTC)
      • (？)疑問@羊羊32521：您可以接受上面的解釋嗎？；@YFdyh000：那個中文名稱實際上是對應介面顯示名稱—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月5日 (二) 05:52 (UTC)
        • @A2569875：Green tickY行 ——羊羊 (留言|贡献) 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)
本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

第一點五階段：內容事實修訂[编辑]

由於該命名空間設立完畢，已修正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)

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

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

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

本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。
专题指引更名
「維基專題:維基專題:XX」的頁面
已處理：

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

下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。
本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

第二點五階段：相關技術問題修正[编辑]

於Phabricator查看
編號T273763的任務
已解決

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

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

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

第四階段：調整專題模板[编辑]

已完成：

已修改完大多數相關模板。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月14日 (日) 09:33 (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。--LightyearsTalk·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)
個人意見：
  1. 原則上不允許，但社羣就個別頁面的特殊情形可以例外特許。建議以修改R2規範處理。
  2. 不允許。如出現，應清除連入並刪除。
  3. 可行。清除連入可以請求bot（WP→PJ），刪除的話我覺得開一個list，然後轉AFD即可。
以上。SANMOSA SPQR 2021年2月17日 (三) 14:40 (UTC)
Wikipedia:专题和Wikipedia:专题委员会等部分页面为何还没有移动到新的名字空间？还是这些页面不应该移动？--百無一用是書生 (☎) 2021年2月19日 (五) 02:46 (UTC)
先前討論有提到將專題介紹留在WP空間。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月19日 (五) 17:12 (UTC)
专题委员会并非专题介绍，Wikipedia:专题似乎也称不上是介绍，更像是WikiProject:首页的作用--百無一用是書生 (☎) 2021年3月1日 (一) 02:54 (UTC)
個人認為跨WP->PJ沒差，但PJ->WP的不行-- Sunny00217  2021年2月21日 (日) 13:56 (UTC)

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

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

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

偽命名空間[编辑]

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:名字空间/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）。SANMOSA SPQR 2020年12月27日 (日) 07:32 (UTC)
支持提升為命名空間，因為會違反快速刪除方針的R2準則。 2020年12月28日 (一) 07:06 (UTC)
如果是偽命名空間通過，就會在下一階段修訂快速刪除、捷徑以及命名空間規範。--臺灣杉在此發言 (會客室) 2020年12月28日 (一) 09:53 (UTC)
支持成為偽命名空間。命名空间涉及较多技术问题，未来如需求明显，可再议转换。--YFdyh000（留言） 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設為偽命名空間。SANMOSA 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)
我建議直接排除成為真命名空間的可能性，這樣會產生維護問題。SANMOSA SPQR 2021年1月6日 (三) 06:10 (UTC)
  • (？)疑問@Sanmosa：比方說哪方面的維護問題？數字ID跟擴展重複？（這個可以克服，頂多新擴展本站的Namespace id與其他語言版本或己妹計畫不同步而已）；頁面內容維護？（我想不出甚麼樣的情況會不利於維護）；跨語言連結？-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月6日 (三) 06:44 (UTC)
方針指引宜集中於同一命名空間。SANMOSA SPQR 2021年1月6日 (三) 06:45 (UTC)
(！)意見SanmosaLTA不是方針、指引、態度指引、草案、提議、論述、專題、主題、存檔、書籍、條目、分類、介面...都不是。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月6日 (三) 06:48 (UTC)
那你當我的建議僅適用於MOS。SANMOSA 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)

以上。--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不就好了，先前討論早就提議了「建立允許不快速刪除的偽名字空間列表」，難道列表只能列在指引哩，不能寫在程式裡？？；關於介面是同理，將是偽名字空間的頁面改掉顯示名稱不就得了？技術上到底是有甚麼障礙，我看不出，有障礙的分明是「你不想」吧，例如下方列舉的程式碼片段：
以上。再來，快速刪除方針，請參閱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。如果设立名字空间的同时增设页面查看权限（回退员及以上），我会考虑支持。--YFdyh000（留言） 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)
本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

小結3[编辑]

  • 我的意見是，如果偽命名空間不會造成「系統性」的重大問題，就可以納入考量。例如佔用其他命名空間、習慣性等等問題，在我眼中看來不是重大系統問題，而且可以透過其他技術手段解決（如上所述）。--臺灣杉在此發言 (會客室) 2021年1月18日 (一) 10:16 (UTC)
    “顯示為‘條目|條目討論’”是指重定向页吗？我觉得重定向页显示条目没什么大问题（） ——羊羊 (留言|贡献) 2021年1月19日 (二) 05:07 (UTC)
    見ナナチ上方的留言，當中有說明可在MediaWiki:Common.js加一段代碼讓偽命名空間不顯示「條目」。--LuciferianThomas．留言 2021年1月19日 (二) 07:50 (UTC)
在使用者自訂的Common.js測試有關代碼的結果。測試於[[MOS:001]]。
(：)回應@LuciferianThomas：已測試相關代碼（程式碼片段）在Common.js中的行為，Special:Diff/63843386，以[[MOS:001]]為例，效果見圖File:Pseudo-Namespace MOS UI Test in Chinese Wikipedia.png。如偽名字空間通過設立可以考慮請求介面管理員添加相關代碼於MediaWiki:Common.js。副知@羊羊32521：重定向页显示条目已有可行解決辦法。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月21日 (四) 08:32 (UTC)
  • 其实照这个思路，如果怕伪名字空间占用条目名字空间，又怕（对于MOS:）指引分散，可以设立MOS:名字空间，然后MOS:下的页面重定向到Wikipedia空间的格式手册里 ——羊羊 (留言|贡献) 2021年1月19日 (二) 05:21 (UTC)
    這不太符合邏輯吧，同時存在「格式手冊」命名空間和專案（維基百科）命名空間的格式手冊。額外設立一個「格式手冊」或「長期破壞者」命名空間但只作重定向用，好像沒什麼意義。--LuciferianThomas．留言 2021年1月19日 (二) 07:48 (UTC)

再提捷徑空间提案[编辑]

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

尝试推动LTA空间[编辑]

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

下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

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

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

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

如果用户不可查看的名字空间不会显示在Special:搜索，我想名字空间多不是个大问题。赞成“LTA与Project空间联系性不大”。不认为二次移动是个大问题，社群可以先用伪名字空间看看效果。--YFdyh000（留言） 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)
本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

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

通過：

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

下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

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

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

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

現行條文

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

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

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

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

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

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

同意提案。SANMOSA 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：兩者應當一同公示並通過，否則會有合法性問題。SANMOSA 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)
建立預設啟用/默認啟用的小工具來呈現偽名字空間介面
还有个小建议：当处于移动视图时，不必在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)
完成AnYiLinSpecial: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]]為例
Pseudo Namespace UI desing for zhwiki.png Pseudo Namespace UI desing for zhwiki zh-hans.png
設定為繁體中文(以zh-tw為例) 設定為簡體中文(以zh-cn為例)
提供目前版本小工具運行結果圖，供公示參考用。右上角的連結為Wikipedia:偽名字空間用於說明，如有缺漏歡迎改善。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月3日 (三) 19:03 (UTC)
@A2569875：等等等一下，這版在像是Mos:$1沒有大寫的也會執行耶，，，-- Sunny00217  2021年2月4日 (四) 08:45 (UTC)
(※)注意：為免混淆WP:偽名字空間原有內容移動至WP:PNS+，並改為指向WP:捷徑#偽命名空間使其等價WP:偽命名空間的重定向。--LuciferianThomas．留言 2021年2月5日 (五) 06:21 (UTC)
  • (？)疑問@LuciferianThomas：所以「OOjs UI icon helpNotice-ltr.svg偽名字空間」（[[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)
      做成小工具就是因为有关闭的需求，其次是维护的需求。--YFdyh000（留言） 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]]為例
Pseudo Namespace Gadget for zhwiki zh-hant.png Pseudo Namespace Gadget for zhwiki zh-hans.png
設定為繁體中文 設定為簡體中文
如期內無合理異議則全站套用此修改。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 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)

自動半保護偽命名空間[编辑]

我很難說有多少人會去破壞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)
建议用滥用过滤器阻止非自动确认用户编辑，配以相关警告。--YFdyh000（留言） 2021年2月2日 (二) 13:07 (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)
至少這也能成為移動操作的依據。快速刪除方針的應用有時並不限於快速刪除本身。SANMOSA SPQR 2021年2月17日 (三) 15:06 (UTC)

將LTA空間設定為noindex[编辑]

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

條目空間中無法使用noindex魔術字。--Xiplus#Talk 2021年2月3日 (三) 13:54 (UTC)
@Xiplus：意思說部分維護模板的設定是設定辛酸的？！-- Sunny00217  2021年2月3日 (三) 14:54 (UTC)
@羊羊32521、YFdyh000：看來LTA還是需要升格為獨立的名字空間，才不會被其他名字空間的設定檔左右。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月3日 (三) 18:57 (UTC)
開新討論吧。--LuciferianThomas．留言 2021年2月3日 (三) 22:29 (UTC)
連過去的是WP，可以將該頁NOINDEX吧，那麼相關捷徑就會有同樣效果？--臺灣杉在此發言 (會客室) 2021年2月4日 (四) 08:39 (UTC)
其實Google搜尋似乎沒看到這些頁面，或許重定向本來就被忽略？--LuciferianThomas．留言 2021年2月5日 (五) 01:52 (UTC)
Bing找得到但直接顯示目標頁面內容。--LuciferianThomas．留言 2021年2月5日 (五) 01:55 (UTC)
所以还需要noindex吗 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年2月18日 (四) 03:02 (UTC)
需要是獨立的名字空間才能設定noindex—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月18日 (四) 10:12 (UTC)
@羊羊32521：我認為如果可以設定的話會更佳，但可能命名空間化會比較方便。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年3月3日 (三) 05:20 (UTC)
那我周末再提一下 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月3日 (三) 15:00 (UTC)
(？)疑問：改这个是否可行？--安忆Talk 2021年3月3日 (三) 15:13 (UTC)
仍支持命名空間案，我只是覺得提升命名空間案一直被人以奇怪的理由關掉很可惜。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年3月3日 (三) 15:21 (UTC)
从语法看可以。--YFdyh000（留言） 2021年3月3日 (三) 15:22 (UTC)

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

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

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

[編輯此導航模板]

說明[编辑]

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

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

本討論的各階段分為：

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

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

專題命名空間通過，剩餘細節獨立討論。臺灣杉在此發言 (會客室) 2021年1月11日 (一) 11:20 (UTC)
偽命名空間和專題空間都設立了。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年3月3日 (三) 05:21 (UTC)

專題命名空間問題[编辑]

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

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

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

捷徑細部修訂[编辑]

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

在上次討論當中，有提及中文捷徑等相關問題，歡迎進一步討論。臺灣杉在此發言 (會客室) 2021年1月31日 (日) 07:42 (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)

關於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」也可。SANMOSA 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)

从语言学意义上讲，音乐作品名称并不是严格意义上的专有名词。英文维基专有名词和普通名词（英语：Proper and common nouns）的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[4][5]），之所以會有大寫也主要是官方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)
我的意見是遵照官方寫法，官方寫法因為語言等問題顯得不明確的話，那應該依從常用名稱的寫法，仍然無法判斷的情況下則頭文字大寫，其他小寫就好。--AT 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[6] willow[7] YESTERDAY LOVE[8] HANN(Alone)[9]
官方Youtube you broke me first[10] willow[11] YESTERDAY LOVE[12] HANN(Alone)[13]
Apple Music you broke me first[14] willow[15] YESTERDAY LOVE[16] Hann (Alone)[17]
Spotify you broke me first[18] willow[19] 不支援 HANN (Alone)[20]
mora you broke me first[21] willow[22] YESTERDAY LOVE[23] HANN (Alone)[24]
我不清楚韓國是否不會隔空格，否則我認為沿用HANN(Alone)沒有什麼問題，如果韓國是不會隔空格的話，那可以用HANN (Alone)。--AT 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.Crowley666✍️ 2021年2月13日 (六) 05:36 (UTC)
某些鬼畜的条目名称可以处理，比如（tItLE，如果真的有人用）但displaytitle必须改--E.A.Crowley666✍️ 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:命名常规#使用外文命名时的专门要求來處理。
  1. (＋)支持。 --無心*插柳*柳橙汁 2021年2月15日 (一) 17:36 (UTC)
  2. (＋)支持。--Tom......（留言） 2021年2月16日 (二) 14:29 (UTC)
  3. 我認為大小寫和簡繁體類似，更偏向一個名稱的兩種字體，而非兩個不同的名稱。就像繁體中文區的事物不強求使用繁體中文命名那樣；對於西文字母大小寫的問題，中文維基百科有理由使用自己的格式規範。--洛普利宁 2021年2月16日 (二) 16:13 (UTC)
  4. (＋)支持。--东风（留言） 2021年2月16日 (二) 16:23 (UTC)
  5. (＋)支持。--Leehsiao（留言） 2021年2月16日 (二) 22:08 (UTC)

命名時以官方名稱為優先[编辑]

選擇這條後，音樂條目的名稱將根據官方名稱命名（但是具體該根據什麼的「官方名稱」還須另外討論）。
  1. 支持。—AT 2021年2月16日 (二) 14:23 (UTC)
  2. 支持。－hiJK910 七一七二一 2021年2月16日 (二) 14:32 (UTC)
  3. 支持。--孤山王子（查閱馬薩布爾之書） 2021年2月16日 (二) 15:18 (UTC)
  4. Mısaka ꮬ Mikoto 悼自由 2021年2月16日 (二) 15:24 (UTC)
  5. 支持。请注意著作人格权在加拿大的案例，连为雕塑绑上红丝带都是侵犯著作人格权，何况是写错名字？须知，一些“现代艺术作品”名字是很重要的。故对所有作品都应尽量保持原文，除非作品名包含不正常的组合（如特殊Unicode、大小写、侮辱性词语）。至于繁简体则视为字体变化，不受约束。--E.A.Crowley666✍️ 2021年2月16日 (二) 15:34 (UTC)
  6. (＋)支持，希望能藉此解決相關爭議，並方便將來創建條目的編者適用（而且盡可能不用動腦，竊以為原方針有點太複雜，涉及太多一層層下來的判斷問題）。個人建議直接以作品（專輯或單曲）封面樣式優先即可。--Kriz Ju（留言） 2021年2月16日 (二) 15:57 (UTC)
  7. 支持。 紺野夢人 恭賀新春 2021年2月16日 (二) 16:01 (UTC)
  8. (＋)支持。--SickManWP歡迎參與♥️邊緣人小組的活動·✏簽到發表於 2021年2月16日 (二) 16:35 (UTC)
  9. (＋)支持。--K·Y·K·Z·K ◢ 2021年2月16日 (二) 18:02 (UTC)
  10. 參官方網站寫法。但有一點要顧慮的是WP:COMMONNAME對WP:名從主人的優先性。SANMOSA SPQR 2021年2月16日 (二) 23:52 (UTC)
  11. (＋)支持。--夜来南风起（留言） 2021年2月17日 (三) 10:33 (UTC)
  12. (＋)支持。--【和平至上】支持通過港區國安法💬 2021年2月17日 (三) 18:28 (UTC)
  13. (＋)支持。 2021年2月18日 (四) 05:51 (UTC)
  14. (＋)支持。🍫巧克力～✿ 2021年2月18日 (四) 09:15 (UTC)
  15. (＋)支持。-- 天秤P Iūstitia | Spēs
  16. (－)反对，应该常用名优先--百無一用是書生 (☎) 2021年3月3日 (三) 01:41 (UTC)
@Shizhao：嚴格來說這裡的投票的不會影響到Wikipedia:命名常规#使用常用名称。 --無心*插柳*柳橙汁 2021年3月3日 (三) 05:10 (UTC)

意見[编辑]

Milkypine意見：我個人選擇第一條（音樂作品不屬於專有名詞）。「官方名稱」是個很容統的稱呼
  1. 以官方網站為主：並非所有唱片公司都有網站，就算有也不一定都有作品列表，更甚至有已經關門的公司（沒錯，我就是再說你EMI）
  2. 官方Youtube為主：並非所有官方Youtube都會上傳作品，如果遇到沒有的作品可能無法適用（不過通常沒Youtube也很大機會不符合關注度）
  3. 商業平台為主（這裡是指Apple Music、Spotify、Amazon和tower等提供串流與販賣音樂的平台）：平台百百種，該如何抉擇？
如果真的選擇這條，我希望大家可以想想該使用何者為「官方名稱」基準。 --無心*插柳*柳橙汁 2021年2月15日 (一) 17:36 (UTC)
提名musicbrainz，先找官方网站再找元数据。不过我不太清楚哪个网站的元数据靠谱。--E.A.Crowley666✍️ 2021年2月13日 (六) 09:22 (UTC)
我認為像musicbrainz、Discogs這類與維基同樣有使用者貢獻的內容優先度最低，話說不符合三項條件的機會好像也很低...。 --無心*插柳*柳橙汁 2021年2月13日 (六) 11:03 (UTC)
M君上述提出的三點對我而言是杞人憂天。首先，沒有官方網站的音樂作品必然佔少數，絕大多數的音樂作品也有官方網站，不存在官方名稱不明確的問題，也就是說可能產生這類問題的音樂作品只佔條目中的極低比重。其次，官方Youtube對我而言也是官方網站的一環，其他平台也一，正常來說如果是官方名稱，不同的官方平台也理應一致，就算有差異也只是極少數的情況下才有可能。其三，串流網站確實五花八門，因此我認為這是沒有官方平台的時候才應該拿來參考。最後，就因為有些音樂作品可能沒有官方平台就要依從命名常規來將其他符合名從主人的名稱一併改成符合外文規定的名稱是於理不合，這已經是接近原創研究的行為，況且對於那些少數沒有任何官方平台的音樂作品，我認為使用最常用名稱就好，沒必要牽拖有官方名稱的音樂作品。以上。—AT 2021年2月16日 (二) 14:34 (UTC)
的確「不存在官方名稱不明確的問題」，但如果說要用「官方網站」來舉證，許多老歌或是非三大音樂集團的作品很可能沒辦法。就我上述提到的兩首英文歌就是有官方網站但官網並不存在音樂作品的情況（和日韓文歌相比，這兩首明顯沒有作品列表這類明確的官方網站）。
不過這邊我應該會等之後確定好再來討論。 --無心*插柳*柳橙汁 2021年2月16日 (二) 16:41 (UTC)
上面Kriz Ju說得好，看封面不就好了？官方網站只是其中一種舉證方法而已。那些老歌或非主流作品沒有明確的官方名稱的時候，那跟從外文規定當然沒有問題。問題就在於當有官方名稱的情況下，還要受到外文規定的影響，改到不倫不類的話，那就是本末倒置。很多日韓歌您要是硬把它們改成小寫的話，說真的非常奇怪，一來不常用，二來不名從主人，只用外文規定是一種非常差的篩選方式。--AT 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)
    就當它不是專有名詞，那加一句音樂作品豁免什麼的就好了，因噎廢食並不可取啊。--AT 2021年2月16日 (二) 17:13 (UTC)

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

總結[编辑]

經過長久的討論與一個禮拜的投票，許多維基人皆認為在命名音樂條目時該根據官方名稱命名。當然維基並非依據投票數做決定，這邊也再次詢問支持「音樂作品不屬於專有名詞」與其他維基人的意見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_appendLopullinen、AnYiLin、Yel D'ohan、Temp3600、Bigbullfrog1996、陳寅恪、Tenhumantenok、Prince of Erebor、K.Y.K.Z.K.、Arivgao、Gracelllee、Tjmj、Kahnballack、FredYYoo和Apple v 。如果沒有問題，那麼將其公示。 --無心*插柳*柳橙汁 2021年3月1日 (一) 18:06 (UTC)

國際關係條目命名常規[编辑]

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

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

  • (！)抗议+(－)反对：這不是共識，這是某用戶製造出來的所謂「共識」。社群諮詢中，明明提議用「—」多於「與」；提議用英文國家名字母順序多於其他順序方式，然而該用戶一概無視。強烈建議暫緩通過，重新開設投票。-- 約翰同志－條目裱糊匠（留言） 2021年2月8日 (一) 11:13 (UTC)
  • 意見大致同上。不建議強行推動修訂。—— Eric Liu 創造は生命（留言．留名．學生會） 2021年2月8日 (一) 15:34 (UTC)
@Comrade John、Ericliu1912：前者是我看漏，已更正。後者而言，根據先前的社羣諮詢的結果，在涉及「中國」與代表「中國」的（歷史）政權時，兩個主權國家／有限承認國家之間的國際關係的條目的命名排序中，在常用語排序優先以及中文使用慣性的前提下，「中國」與代表「中國」的（歷史）政權先行。另外，有用戶指出直接明文寫明「中國」與代表「中國」的（歷史）政權先行會違反避免地域中心方針，因此兩個主權國家／有限承認國家之間的國際關係的條目的命名排序難以區分為涉及與不涉及「中國」與代表「中國」的（歷史）政權的兩種情況處理。考量到在條文實際效果中，如果條目命名上不做到「中國」與代表「中國」的（歷史）政權先行，會引來更大規模的社群反對聲音，因此我只能作出如此取捨。另一方面，擬議條文是“同等級雙邊關係中，命名先後順序按照中文常用語序確定，如無特定中文常用語序則以英文國名字母順序確定”，考量到在不涉及「中國」與代表「中國」的（歷史）政權的情況下，中文一般並無特定常用排列順序，因此最終的結果也是以英文國名字母順序確定。綜以上，就後者而言，由於實際應用效果相同，我不認為我有錯誤總結共識。SANMOSA 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)
  • （離題）話說日本跟北韓沒有建交，但條目仍然叫做日本－朝鲜关系，可見現行「－」跟「與」的原創研究區別方法甚至都沒能完全實踐。—— Eric Liu 創造は生命（留言．留名．學生會） 2021年2月16日 (二) 06:10 (UTC)
  • 英文字母順序還是不要硬性規定，太多例外，如梵蒂岡，根據聖座「在國際關係中，各國大使不是獲梵蒂岡城國而是獲聖座所接受；聖座向各國和國際組織派出的外交代表機構或使節，是代表聖座而非所謂梵蒂岡城國。」，所以是用「H」而非「V」。英維大部份通用命名情況是怎樣，跟隨就是了。-- 約翰同志－條目裱糊匠（留言） 2021年2月16日 (二) 08:51 (UTC)
    • @Comrade John：就Holy See那點，我再修改一下。其他情況我認為“其他情況根據編輯者創建的情況‘先到先得’或經包括創建者在內的編輯者討論達成共識後移動”一條已經包含，就不用再改了。SANMOSA SPQR 2021年2月18日 (四) 01:41 (UTC)
現已無反對意見，依WP:7DAYS公示7日。SANMOSA 誓山海而長在，似日月而無休 2021年2月25日 (四) 02:18 (UTC)
@Comrade John、Ericliu1912：邀请明确意见。个人对“实体名不得使用单字简称”且方针性质倾向反对，中日关系应当改成中国－日本关系吗。其他条款未研究，怀疑是否已有足够共识。--YFdyh000（留言） 2021年2月25日 (四) 03:12 (UTC)
@YFdyh000：要移動，移動後原名稱要改為消歧義，否則會產生歧義。另外此命名常規意在統一所有兩個實體之間的國際關係條目命名，以避免原創研究問題（一些用「－」，一些用「與」，一些用簡稱，完全沒有使用準則，即使有，也是原創研究，而且也沒有完全落實執行）。SANMOSA 誓山海而長在，似日月而無休 2021年2月25日 (四) 09:04 (UTC)
(－)傾向反對公示。儘管我個人是贊成移動之後消歧義的，但本地社群的共識似乎並不普遍贊同所謂「實體名不得使用單字簡稱」的規定，強硬推動並無好處。亦即，多數朋友並不會同意將中日关系移動至中國－日本關係。考慮到常用名稱原則，較好的方法應是在中日關係條目直接做消歧義。中日關係悠久，各政權時期皆有其重要性，相信是足以做平等消歧義的。此處順道提出一個方案，1971年以前與中國建交的國家，其「中某關係」或「中國－某國關係」雙邊關係條目採用平等消歧義，1971年以後與中國建交的國家，其「中某關係」或「中國－某國關係」雙邊關係條目則採用主從消歧義，按慣例主為「中華人民共和國」，從為中華民國，兼顧兩岸勢力消長。—— Eric Liu 創造は生命（留言．留名．學生會） 2021年2月28日 (日) 15:22 (UTC)
@Ericliu1912：我的具體想法是：使用「<國名甲>－<國名乙>關係」的格式命名具體兩個國家之間的國際關係條目，條目內容以兩國各個時期的關係歷史為主；使用「<國號甲>－<國名乙>關係」的格式命名一個國家特定政權甲與另一個國家乙的多個政權之間的國際關係條目，作為甲對外關係史條目的拓展條目。「中某關係」類條目在此規則下通常會演變成三個並立的條目。另一方面，不以簡稱命名條目的規定也適用於非「中某關係」類條目，如「英美關係」也會更名為「英國－美國關係」。不以簡稱命名條目的規定意在確立條目命名一致性，使條目命名格式變成只有一種，易於讓新用戶適從。假設我是一個有志於國際關係條目的新用戶，現時的暫行做法很明顯會讓我不清楚要怎樣命名國際關係條目：有些國際關係條目不能用簡稱，有些國際關係條目能用簡稱但又不用，有些國際關係條目能用簡稱而且也用了，我根本不能掌握使用和不使用簡稱的時機。這和之前Ericliu1912你表示國際關係條目一些用「－」，一些用「與」的使用準則不但是原創研究，而且也沒有完全落實執行的情況是完全一致的，我可以斷言這兩件事是同一個問題。另一方面，不以簡稱命名條目的規定也意在減少條目命名的地域中心傾向，例如「中朝關係」和「中華人民共和國－朝鮮民主主義人民共和國關係」是完全等同的（朝鮮民主主義人民共和國僅曾與中華人民共和國有邦交），但只有中國大陸的人才會將朝鮮民主主義人民共和國簡稱為「朝」，中國大陸以外的地方的人只會把朝鮮民主主義人民共和國簡稱為「北韓」，但條目名稱在如此情況下也難以設定轉換，結果導致條目命名偏向中國大陸，對中國大陸以外地區的人造成（行文理解上）不友善的情況。擬議版國際關係條目命名常規的大原則是在最大程度上避免地域中心，而且避免地域中心也是中文維基百科極為重要的一個方針，我個人留意到不贊同「實體名不得使用單字簡稱」的規定的留言都對避免地域中心方針有不同程度的忽視，而且也並非多數意見，根據共識方針，我認為相關意見不應該納入共識考量。SANMOSA 江南好，風景舊曾諳 2021年3月1日 (一) 06:08 (UTC)
@Ericliu1912：不好意思，想問一下有沒有後續回應。SANMOSA 江南好，風景舊曾諳 2021年3月4日 (四) 09:49 (UTC)
粗略地看了一下社群意见征询，感觉大多数参与者都不太支持将“中美关系”一类的十分常用的简称移动至目前提议的名称（虽然这样可以易于辨识且防止歧义），个人认为应该（仅）允许将一些十分常用的简称代替“<國名甲>－<國名乙>關係”的名称，毕竟如果简称过于常用，完全禁用还是有违WP:COMMONNAME的。——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年3月4日 (四) 12:05 (UTC)
@BlackShadowG：（1）你自己也說了：有歧義。另一個問題是要避免地域中心和默認海峽兩岸主權。（2）我自己是看不出「蒙俄關係」有多常用。SANMOSA 江南好，風景舊曾諳 2021年3月4日 (四) 14:26 (UTC)
1. 刻意使用不常用的全称可能反而不中立。2. 所以它不是十分常用的简称。--YFdyh000（留言） 2021年3月4日 (四) 14:44 (UTC)
(！)抗议：有些人看到“中国”哪怕是“中国江苏”就“有默認兩岸四地主權歸屬的問題”，和“一看到白胳膊,就想到全裸体,一想到全裸体,就会想到生殖器,一想到生殖器,就想到性交,一想到性交,就想到杂交”有什么区别？实在搞不懂这是啥逻辑。之前W:CS4D就是这么带病通过的，现在还想再搞一次么？中立，中立，多少罪恶假汝之名。—2A04:6F00:1:0:0:0:0:10A9（留言） 2021年3月4日 (四) 14:37 (UTC)

悬挂Blocked user模板之利弊[编辑]

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

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

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

(－)反对 提案意图达成的目标在事实上并不严重或无法实现：1. 关于减少数据库下载的容量，本站永封用户仅数万人，{{indef}}不足十个字节，而本站被自动欢迎的注册用户有数百万人，且欢迎模板替换引用后长达数千字节。因此前者所节约的容量与后者相比，有将近5个数量级的差距，不过是九牛之一毛罢了，对数据维护的益处是相当边际性的。2. 关于破坏留痕的问题，现行方针已要求攻击/侮辱性用户名不得创建用户页，已有用户页如存在也要删除；更何况永封用户页本身就是不索引的，主流搜索引擎不会收录，外网几乎不可见，也自然不存在严重的留痕问题。--Antigng（留言） 2021年2月11日 (四) 03:40 (UTC)
好，容量问题可忽略。非严重的恶性用户名页面仍影响Special:前缀索引、数据库记录等部分地方。提出的一大原因是创建模板使日志不显示，相当于“折叠”重要的信息，同时它无法提供难以替代的作用。--YFdyh000（留言） 2021年2月11日 (四) 04:46 (UTC)
不使用模板标记，而直接白纸保护，虽然相较于现行的做法“展开”了一条最近的封禁日志，但与此同时，也“展开”了一条本应“折叠”的无关信息——保护日志（如果采取删除的方式处理既有页面，还会“展开”一条本应“折叠”的删除信息）；何况白纸保护下，用户贡献、完整的封禁日志仍处于折叠状态；用户日志（对于滥建条目的破坏者有用）则根本不存在；现行模板也会呈现白纸保护下不呈现的封禁方针。因此很难说白纸保护相对于模板标记是更好的呈现方式。--Antigng（留言） 2021年2月11日 (四) 06:57 (UTC)
1. 没有好办法，本该呈现。2. 怀疑在技术上能拓展相关显示信息（MediaWiki名字空间下）。3. 现行模板强制用户去寻找和点击并不明显的封禁日志链接，我看都蒙。要不然参考机器人紧急停止模板设计，封禁日志链接变大型，用户贡献记录变中等。--YFdyh000（留言） 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}}建立用戶頁後对之进行永久全保护。

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

支持，因其他原因永封没必要强制都要创建用户页并标记。--Kuailong™ 2021年2月18日 (四) 18:04 (UTC)
(＋)支持-- Sunny00217  2021年2月21日 (日) 13:53 (UTC)
支持。至于提案提到的其他事项，有人愿意推进再说吧。--YFdyh000（留言） 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个月，偷鸡不成蚀把米。--YFdyh000（留言） 2021年2月11日 (四) 06:23 (UTC)
    提出存在讨论共识的解任案，不代表提案者肯定具备投票权并计入投票。--YFdyh000（留言） 2021年2月11日 (四) 06:34 (UTC)
我的理解是自動確認用戶可以提出，但若其不符合人事任免投票資格，則不包括為七人之中；事實上提出的人可以不參與聯署，可以當作「第零票」吧。--【和平至上】支持通過港區國安法💬 2021年2月11日 (四) 16:44 (UTC)
我認為和平至上的解讀可行。就「提出的人可以不參與聯署」的情形，1233曾為之（雖然其具人事任免投票資格）。SANMOSA 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)
我不認為是筆誤，但不反對收緊。SANMOSA SPQR 2021年2月16日 (二) 00:13 (UTC)
我不认为是笔误，在出现明显共识前我不认为需要收紧。--YFdyh000（留言） 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:新頁面巡查。

理由如下：

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

-- Sunny00217  2021年2月11日 (四) 16:08 (UTC)

WP:回退员重定向到回退功能页面。“如有违反前述原则，当以除权处理。”对方针有意义，需要解决。--YFdyh000（留言） 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:重定向：
現行條文

移動時不留重定向

主页面：Wikipedia:回退功能 § 移動時不留重定向
快捷方式

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

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

提議條文

移動時不留重定向

快捷方式

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

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

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

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

WP:回退功能：
現行條文

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

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

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

提議條文

移動時不留重定向

主页面：Wikipedia:重定向 § 移動時不留重定向
WP:新頁面巡查：
現行條文

移動時不留重定向

主页面：Wikipedia:回退功能 § 移動時不留重定向

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

提議條文

移動時不留重定向

主页面：Wikipedia:重定向 § 移動時不留重定向

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

@Sunny00217、YFdyh000、Pseudo Classes、Hjh474。SANMOSA SPQR 2021年2月18日 (四) 01:17 (UTC)
没什么意见。把“纪录”更正“记录”吧。--YFdyh000（留言） 2021年2月18日 (四) 01:27 (UTC)
@YFdyh000：完成。SANMOSA 誓山海而長在，似日月而無休 2021年2月20日 (六) 02:22 (UTC)
@YFdyh000：名詞是用「紀錄」沒錯，動詞才是「記錄」。我改的一處正是本是動詞的地方。SANMOSA 誓山海而長在，似日月而無休 2021年2月20日 (六) 02:37 (UTC)
不是名词动词问题吧，纪录用于成绩统计层面（纪录片除外），记录才是文字层面。难道有地区词差异。--YFdyh000（留言） 2021年2月20日 (六) 02:51 (UTC)
@YFdyh000：《文書處理手冊》附錄2（第60頁）。（意外發現地區詞差異）SANMOSA 誓山海而長在，似日月而無休 2021年2月20日 (六) 03:05 (UTC)
有点搞不清，可能需另议或字词转换……在中国大陆，纪录主要是最好成绩或总结归纳，会议记录、历史记录等不会写纪录，个人健康纪录也一般是“个人健康记录”。此博客提到文书所用动词/名词分法，但评论也有不同意见。--YFdyh000（留言） 2021年2月20日 (六) 04:11 (UTC)
@YFdyh000：恐怕不能用字詞轉換處理，因為誤轉機率太高：有些地方的使用是一樣的，但有些地方的使用是完全不同的。《文書處理手冊》是臺灣官方文件，我給予的連結也是政府網站連結，我認為沒辦法質疑。繁體來說是會寫「會議紀錄」、「歷史紀錄」的（至少前者我非常肯定）。SANMOSA 誓山海而長在，似日月而無休 2021年2月20日 (六) 04:18 (UTC)
指在方针指引页（如Wikipedia:R）转换。浏览器的“历史记录”我是很确定的。--YFdyh000（留言） 2021年2月20日 (六) 04:36 (UTC)
（1）問題完全一樣，在任何地方轉換都會出現一樣的問題。（2）科技公司經常會忽略地區用詞差異，不能作準。SANMOSA 誓山海而長在，似日月而無休 2021年2月20日 (六) 07:56 (UTC)
你这一“不能作准”，中国大陆所有软件和文献就都是错的了。我非常确定99%+将History称作历史记录，历史纪录是Best record。在此题中讨论可能不大合适。--YFdyh000（留言） 2021年2月20日 (六) 08:06 (UTC)
@YFdyh000：至少在繁體不能作準吧。如果是中國大陸公司開發的browser，在中國大陸簡體下反而是可以作準的。如果沒其他問題的話，我就不再修改提案了。SANMOSA 誓山海而長在，似日月而無休 2021年2月20日 (六) 13:57 (UTC)
代為標示{{新增條文}}，請幫確認有無錯漏。--Hjh474（留言） 2021年2月18日 (四) 02:17 (UTC)
{{刪除條文}}也加上了。SANMOSA SPQR 2021年2月18日 (四) 02:26 (UTC)
原來巡查權那裏也有一段-- Sunny00217  2021年2月18日 (四) 03:10 (UTC)
是不是需要公示貼公告板？--Hjh474（留言） 2021年2月26日 (五) 02:46 (UTC)
@Hjh474：你是不是忘了WP:7DAYS？SANMOSA 江南好，風景舊曾諳 2021年3月1日 (一) 10:25 (UTC)
👍 赞。--Hjh474（留言） 2021年3月1日 (一) 10:29 (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:豆子。--YFdyh000（留言） 2021年2月23日 (二) 13:33 (UTC)
@Bookwith。SANMOSA 江南好，風景舊曾諳 2021年3月1日 (一) 10:37 (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或其他主要搜索引擎中是否有很多有關的條目？
  • 檢查虛構情節：編寫虛構人物角色條目時，請務必閱讀本忠告。

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

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

我修了一下。Fire Ice 2021年2月20日 (六) 17:08 (UTC)
(＋)支持。SANMOSA 誓山海而長在，似日月而無休 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。SANMOSA 誓山海而長在，似日月而無休 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)

目前有四个方案：一、删除其他测试。二、其他测试位置不变。三、其他测试移至参见并改为三级标题。四、其他测试移至参见并删除标题。请各位选择吧。Fire Ice 2021年3月2日 (二) 12:18 (UTC)

(！)意見:其他测试部分保留在「參見」，其實不是很大問題；有些方針也會把論述放進去，問題也不大，那只是參考，不是方針條文，沒有約束力。--蟲蟲飛♡♡→♡℃※留言 2021年3月2日 (二) 12:32 (UTC)
三（二也不拒绝）理由见上。--懒癌哪天行→Lazy, as no today's excuse. 2021年3月3日 (三) 05:42 (UTC)
我选一。Fire Ice 2021年3月3日 (三) 09:31 (UTC)

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

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

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

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

以上。SANMOSA 誓山海而長在，似日月而無休 2021年2月21日 (日) 05:22 (UTC)

請勿將擬議快速刪除方針條文增修的其他部分與此部分合併，以免討論失焦。SANMOSA 誓山海而長在，似日月而無休 2021年2月21日 (日) 05:30 (UTC)
怎么避免消歧义页改成重定向然后速删。比如限定存在已超过1年的重定向？--YFdyh000（留言） 2021年2月21日 (日) 05:32 (UTC)
@YFdyh000：擬議條文僅處理帶有「(消歧義)」字樣的重新導向。帶有「(消歧義)」字樣的重新導向通常不會重新導向至非消歧義頁面。如果是使用平等消歧義抑或主題目消歧義的爭議，依擬議條文，應交由存廢討論處理。SANMOSA 誓山海而長在，似日月而無休 2021年2月21日 (日) 05:41 (UTC)
按新增条文，我可以将主题目消歧义的消歧义页改成重定向页（如重定向回主条目）、取消链入、改为顶注消歧义（或者单纯反对而不作任何消歧义），然后悄然请求速删其他人创建的消歧义页面，期间创建人可以不知情。我很好奇「(消歧義)」字樣的重定向的成因，似应避免，或者不管、保留。--YFdyh000（留言） 2021年2月21日 (日) 05:53 (UTC)
@YFdyh000：「改為頂注消歧義」仍是「應使用平等消歧義抑或主題目消歧義存在未解決的爭議」的情況（頂注消歧義為主題目消歧義的一種），依原提議條文，仍應交由存廢討論處理。就「單純反對而不作任何消歧義」一點，我已再更新提議條文，現提議條文在「單純反對而不作任何消歧義」的情況下應交由存廢討論處理。SANMOSA 誓山海而長在，似日月而無休 2021年2月21日 (日) 06:05 (UTC)
(－)反对 沒有甚麼價值，只是存不存在罷了-- Sunny00217  2021年2月21日 (日) 13:52 (UTC)
@Sunny00217：請你詳細解釋一下你的理由。我是想説，如果最後的結果必然是刪除，那根據WP:SNOW的思想，應該加快此類提刪的刪除程序。SANMOSA 誓山海而長在，似日月而無休 2021年2月21日 (日) 23:42 (UTC)
你可以把我這張票視作無效反對票就是了，基本上個人認為這種提案沒有甚麼必要-- Sunny00217  2021年2月22日 (一) 09:48 (UTC)
不是「清除」連入，已改為「清理」。 2021年2月26日 (五) 12:57 (UTC)

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

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

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

以上。SANMOSA 誓山海而長在，似日月而無休 2021年2月21日 (日) 05:38 (UTC)

請勿將擬議快速刪除方針條文增修的其他部分與此部分合併，以免討論失焦。SANMOSA 誓山海而長在，似日月而無休 2021年2月21日 (日) 05:43 (UTC)
增加「若條目內的模板包括資訊框，且資訊框在不包含其預設欄位名稱的情況下仍有內容，則亦不適用」的原因是資訊框通常具百科性內容。其他部分的修改原因是促進草稿化。SANMOSA 誓山海而長在，似日月而無休 2021年2月21日 (日) 05:46 (UTC)
@Poem。SANMOSA 誓山海而長在，似日月而無休 2021年2月21日 (日) 05:48 (UTC)
inuse的部分我认为没必要，按常识按需移除即可，{{inuse|2年}}不适用吗。“有内容”可能非常宽泛，标点和胡言乱语都是内容，不过我还没想到更好表述。A6同上。因此，我不认为有必要修订。--YFdyh000（留言） 2021年2月21日 (日) 06:00 (UTC)
@YFdyh000：就「若條目內的模板包括資訊框，且資訊框在不包含其預設欄位名稱的情況下仍有內容，則亦不適用」來說，你說的情況並不常見（而且可以用A1處理），大多數情況是確有有意義內容，這種情況下不應刪除，但我更改一下表達方式。後一點我開放討論，因為這個提議是照抄舊提議的。SANMOSA 誓山海而長在，似日月而無休 2021年2月21日 (日) 06:12 (UTC)
  • 摘下inuse再提刪就行。--Temp3600（留言） 2021年2月21日 (日) 14:31 (UTC)
@Temp3600：不排除有誘發編輯戰的可能性。SANMOSA 誓山海而長在，似日月而無休 2021年2月21日 (日) 23:44 (UTC)
(※)注意
  1. 用戶經常只加了模板及訊息框後後，就一走了之，這些只有模板及訊息框的條目嚴重影響條目質素，也影響維基的聲譽，讓外界看到維基的條目只有模板及訊息框。
  2. A6現行條文已經很清晰，用戶及管理員也會根據常識判斷。
以上。--蟲蟲飛♡♡→♡℃※留言 2021年2月22日 (一) 04:47 (UTC)
（1）一來這條文修改其實是為了促進草稿化，巡查員看到自然懂得怎麽樣去處理，不要說的像所有巡查員都死了一般。二來中文維基百科品質低下的條目多的是，有些條目的字數只是剛好過50，我看它們的品質跟只有Infobox的條目差不多。（2）這一點我開放討論，因為這個提議是照抄舊提議的。SANMOSA 誓山海而長在，似日月而無休 2021年2月22日 (一) 12:29 (UTC)
(？)疑問:現行方針下，您要「促進草稿化」，就做不到嗎？您可以把符合A2的條目，以移動到草稿的方式去替代提速刪，沒必要改方針。--蟲蟲飛♡♡→♡℃※留言 2021年2月24日 (三) 12:40 (UTC)
我現在又不是巡查員，所以我能做的東西很少，我總不可能整天盯著Category:快速删除候选吧。那如果我要想辦法提醒巡查員的話，最好的辦法就是從方針層面提醒，讓他們挂A2的誘因減少，草稿化的誘因增加。SANMOSA 誓山海而長在，似日月而無休 2021年2月25日 (四) 02:23 (UTC)
(＆)建議:這種常識性的東西，我不認為巡查員會不懂，如果不懂，您改了方針，也不會立刻懂了。建議您可以直接走去巡查員用戶討論頁建議，這比您改方針的方式來得有效。--蟲蟲飛♡♡→♡℃※留言 2021年2月25日 (四) 03:52 (UTC)
我不認為草稿化是“常識性的東西”。SANMOSA 誓山海而長在，似日月而無休 2021年2月25日 (四) 09:08 (UTC)
  • 請您論述提案解決了甚麼問題？現行機制是否無法解決您提到的問題？--蟲蟲飛♡♡→♡℃※留言 2021年2月28日 (日) 02:17 (UTC)
我在2021年2月22日 (一) 12:29 (UTC)的留言中的（1）中的“二來”有説明修訂條文後資訊框預設欄位名稱以外的內容視為條目本身的內容，實際上避免了只有已填寫有意義的百科性内容的資訊框的條目被刪除，讓該等條目有機會被改寫出文字段落敘述。SANMOSA 江南好，風景舊曾諳 2021年2月28日 (日) 10:51 (UTC)
  • 您這個意見我上面已經回應了，在條目空間保留這些只有訊息框或模板的條目，很影響外界對維基的觀感，而且我沒看到提案有甚麼修訂意義。--蟲蟲飛♡♡→♡℃※留言 2021年3月3日 (三) 10:23 (UTC)
請問百科全書最重要的目的是甚麽？照顧特定人士的觀感？不可能。不要把本末輕重顛倒。SANMOSA 江南好，風景舊曾諳 2021年3月3日 (三) 13:56 (UTC)
对当前提案的A2条文修订倾向支持。对inuse相关修订（持续时间内）认为没必要强调，挂模板的人应有常识。对虫虫飞认为的“这些只有模板及讯息框的条目严重影响条目质素”等反对，有维护模板更体现维基百科的不完善、号召贡献（我甚至倾向“模板轰炸”），新建的不违规条目不需要迅速处理。虫虫飞，“您可以把符合A2的條目，以移動到草稿的方式去替代提速刪，沒必要改方針。”大概不能代替Sanmosa期望的减少A2使用率。--YFdyh000（留言） 2021年3月3日 (三) 14:27 (UTC)
inuse的部分，很不幸地，在我看來，沒多少人有如此的常識。SANMOSA 江南好，風景舊曾諳 2021年3月3日 (三) 14:30 (UTC)
(？)異議:現在社羣對條目質素有非常高的要求，沒必要把質素極差的A2，可能不成條目的條目留在維基。--蟲蟲飛♡♡→♡℃※留言 2021年3月3日 (三) 14:35 (UTC)
@蟲蟲飛：您的观点大概是小小作品应当速删。但宁缺毋滥、宁滥勿缺等观点是并存的。@Sanmosa：所以有很多人在速删挂了inuse的条目吗。--YFdyh000（留言） 2021年3月3日 (三) 14:51 (UTC)
  • 小小作品還算條目，A2連條目都不是，質素極差的，不知為甚麼還要放寬？--蟲蟲飛♡♡→♡℃※留言 2021年3月3日 (三) 14:57 (UTC)
@蟲蟲飛：提案的A2会将这样内容的新条目排除，并将无实际内容的新条目归入A1。虽然这个示例也许稍显极端，但确实有编者和新手会将早期版本的草稿提交到条目空间，如果内容可修改格式来变为小小作品乃至小作品，或者移动到草稿空间，不应该交由速删，如此速删像是惩罚编者而非促进内容创建。--YFdyh000（留言） 2021年3月3日 (三) 15:09 (UTC)
这样差的條目還要放過？合理嗎？雖然我反對熱血刪除，但也(－)反对把條目的質素標準降到那麼低。--蟲蟲飛♡♡→♡℃※留言 2021年3月4日 (四) 13:53 (UTC)
能轻松总结和改写为小小作品或以上的仅信息框条目，不应以速删结束，应留出完善和打捞时间（小小作品或存废讨论）。尚不是合格的条目（包括如广告宣传、关注度不足、需要重写等），不代表要立即速删，侵权删除都有7天呢。指引Wikipedia:小小作品#小小作品提昇管理辦法也提到，正文的定义“不包含讯息框的预设字段名称和其他模板本身”，即非预设字段是计入小小作品字数计算的，A2没理由比它更严格。--YFdyh000（留言） 2021年3月4日 (四) 14:16 (UTC)

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

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

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

站务有这个需求吗。担心被破坏者利用。--YFdyh000（留言） 2021年2月21日 (日) 07:48 (UTC)
不清楚。可能需要一些數據，還有社群的看法。CSD F7被破壞者利用的可能性不太大。SANMOSA 誓山海而長在，似日月而無休 2021年2月21日 (日) 08:54 (UTC)
F7不清楚，O7对保留派维基人来说可能是不建议用的。O4会被利用，见童孝賢（對話頁 | 用户貢獻）。如果没有严重积压，不认为有必要引入机器人。如果机器人运转良好，也未见需要对方针有所修订。--YFdyh000（留言） 2021年2月21日 (日) 09:02 (UTC)
先放著，看看其他人的意見。O7被刪除的草稿我沒見過幾個人管（除刪除外）。SANMOSA 誓山海而長在，似日月而無休 2021年2月21日 (日) 09:53 (UTC)
(※)注意
  1. 有時用戶不懂得加分類重定向，機器人會以O4提刪，管理員要手動加「分類重定向模板」，才能解決機器人反覆提刪分類重定向；而且之前機器人失靈，把已經放了分類重定向模板的頁面也提刪，因此必須有管理員判斷。
  2. O7的頁面可以WP:AR還原，如果機器人自動刪除，但令WP:AR出現問題。
  3. 方針規定提刪和刪除必須兩個用戶，因此同一個機器人去提刪及刪除，又會與方針牴觸。
  4. 有時用戶會把合理使用的檔案轉載到共享，但原檔案不能F7刪去。
  5. 之前已經有很多機器人失靈，如果讓機器人自動刪除，風險很大。
以上。--蟲蟲飛♡♡→♡℃※留言 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。SANMOSA 誓山海而長在，似日月而無休 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一個。SANMOSA 誓山海而長在，似日月而無休 2021年2月22日 (一) 12:42 (UTC)
  • 對，Jimmy-abot才有管理員權限，但兩個機器人的主人都是Jimmy，因此只能視為一個用戶。--蟲蟲飛♡♡→♡℃※留言 2021年2月22日 (一) 12:46 (UTC)
所以我才把Xiplus-abot找出來啊，Jimmy Xu跟Xiplus總是兩個人吧。SANMOSA 誓山海而長在，似日月而無休 2021年2月22日 (一) 12:49 (UTC)
我也ping一下新提到的當事人好了：@Xiplus。SANMOSA 誓山海而長在，似日月而無休 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）認同你的觀點。SANMOSA 誓山海而長在，似日月而無休 2021年2月22日 (一) 14:06 (UTC)
@Xiplus。SANMOSA 誓山海而長在，似日月而無休 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上面說的事情還是值得憂慮的。SANMOSA 誓山海而長在，似日月而無休 2021年2月23日 (二) 01:34 (UTC)
(※)注意:我上面羅列了那麼多問題，好像都被無視了。--蟲蟲飛♡♡→♡℃※留言 2021年2月23日 (二) 01:46 (UTC)
多是机器人能判断和避免的。--YFdyh000（留言） 2021年2月23日 (二) 03:07 (UTC)
（也就是説，上面羅列的問題不成問題。）SANMOSA 誓山海而長在，似日月而無休 2021年2月23日 (二) 04:25 (UTC)
(？)疑問:其實大家知道甚麼叫分類重定向嗎？--蟲蟲飛♡♡→♡℃※留言 2021年2月24日 (三) 02:58 (UTC)
(※)注意:不認為機器人有能力解決以下問題:
  1. 有時用戶不懂得加分類重定向，機器人會以O4提刪，管理員要手動加「分類重定向模板」，才能解決機器人反覆提刪分類重定向；而且之前機器人失靈，把已經放了分類重定向模板的頁面也提刪，因此必須有管理員判斷。有些管理員也會誤判。
  2. O7的頁面可以WP:AR還原，如果機器人自動刪除，但令WP:AR出現問題。
  3. 有時用戶會把合理使用的檔案轉載到共享，但原檔案不能F7刪去。有些管理員也會誤判，不認為機器人有能力判斷版權。
以上。--蟲蟲飛♡♡→♡℃※留言 2021年2月24日 (三) 02:52 (UTC)
我究竟説過多少次了，2技術上不可能發生。SANMOSA 誓山海而長在，似日月而無休 2021年2月24日 (三) 10:32 (UTC)
而且1也不是甚麽大問題，刪除了以後，重建時直接加{{cr}}就好。我沒見過挂了{{cr}}還是被自動提刪的情形，就蟲蟲飛説的那種情形，我認為{{cr}}很可能是被自動提刪後才挂的，然後蟲蟲飛又沒看過頁面歷史，結果產生了誤解；即使真的是挂了{{cr}}以後才被自動提刪，發生的機率實在太低，沒必要過度憂慮。SANMOSA 誓山海而長在，似日月而無休 2021年2月24日 (三) 10:34 (UTC)
3來説，既然“有些管理員也會誤判”，那憑甚麽要求bot“解決（誤判的）問題”？即使誤判，走DRV程序恢復就好，沒甚麽大不了的。這提案本來就只是打算通過bot加快處理流程，僅此而已。SANMOSA 誓山海而長在，似日月而無休 2021年2月24日 (三) 10:40 (UTC)
  • 您沒看懂我的留言。總之，提案不但沒有解決問題，而且當前沒有問題，但提案反而製造了問題。--蟲蟲飛♡♡→♡℃※留言 2021年2月25日 (四) 03:55 (UTC)
不，這提案沒有製造任何的問題，而且上面所謂的“問題”要麽不可能發生，要麽就發生機率太低而不成問題。SANMOSA 誓山海而長在，似日月而無休 2021年2月25日 (四) 09:07 (UTC)
  • 請您論述提案解決了甚麼問題？現行機制是否無法解決您提到的問題？--蟲蟲飛♡♡→♡℃※留言 2021年2月28日 (日) 02:19 (UTC)
這提案本來就只是打算通過bot加快處理流程，請問我是不是連提出一個加快處理流程的提議都不行？SANMOSA 江南好，風景舊曾諳 2021年2月28日 (日) 05:27 (UTC)
您沒看懂我上面提到的問題。請再看一下o4、F7及o7的問題，尤其是o4、F7。您不能把機器人誤刪的問題全推給DRV去處理。--蟲蟲飛♡♡→♡℃※留言 2021年2月28日 (日) 05:42 (UTC)
為何？管理員自己誤刪也是給DRV去處理，對管理員的容忍度那麽高，卻對BOT一點都不容忍？提案的目的只有一個：加快。誤刪率不是我的重點，反正是不會加大的。SANMOSA 江南好，風景舊曾諳 2021年2月28日 (日) 10:48 (UTC)
未见加快的必要，机器人无法辨识破坏者操作和误导，会增加反破坏的查证和复核成本。如果有同类任务积压，人工用机器人或脚本辅助还差不多。--YFdyh000（留言） 2021年2月28日 (日) 11:01 (UTC)
我要求實際數據證明此説法。SANMOSA 江南好，風景舊曾諳 2021年3月1日 (一) 10:28 (UTC)
我要求机器人先展示自己的效果。方针未必需要修订，机器人操作者（管理员）承担责任就可以。--YFdyh000（留言） 2021年3月1日 (一) 10:31 (UTC)
應該請Sanmosa描述管理員處理該等速刪時，應該進行哪些檢查和判斷，列出詳盡步驟，再來看看機器人是否能完美複製人類的行為。--Xiplus#Talk 2021年3月1日 (一) 11:18 (UTC)
覆以上：
  1. O4的檢測比較複雜：首先要點進去看是不是分類重新導向頁面：如果是，而且已使用{{cr}}，直接移除快速刪除模板；如果是，但未使用{{cr}}（通常是錯誤使用一般重新導向頁面的格式編寫），則以{{cr}}重寫；如果不是，接下來就看管理員自己的細心程度。比較細心的管理員可能會查看最近的分類移動紀錄，檢查是否有不正常的分類移除情形，確定沒有才會處理；沒那麼多時間檢查的管理員就可能會直接處理。
  2. O7基本上真的要檢查的話就只有是否6個月內有有意義編輯而已，一般而言我認為管理員也甚少就此檢查，所以bot在此沒任何「複製人類的行為」的地方，檢測O7掛了一段時間後直接刪除即可。O7其實可以算是（除O3外）最應該用bot處理的一條快速刪除規則。
  3. F7要檢查的事項有兩項：第一項是是否真的和commons的檔案重複，第二項是commons的檔案是否存在版權問題（如果有的話，一般需要經過commons當地的存廢討論）。
以上。SANMOSA 江南好，風景舊曾諳 2021年3月2日 (二) 11:12 (UTC)
  • 您太神化機器人的功能，而且從您的回應，我覺得您不瞭解管理員的操作。--蟲蟲飛♡♡→♡℃※留言 2021年3月3日 (三) 10:25 (UTC)
就我的理解，bot其實就是自動化處理重複性的工作，而且只要有人寫得出來那樣的代碼（在具有相關權限的前提下），那事情就能辦到，所以我完全不認同你的“神化”論。你自己是管理員，卻又不説清楚你認為的“管理員的操作”其實是怎樣，那你又何來判定我“不瞭解管理員的操作”？這樣我可能會認為你其實才是那個“不瞭解管理員的操作”的人，我可能比你更清楚“管理員的操作”多一些。SANMOSA 江南好，風景舊曾諳 2021年3月3日 (三) 14:00 (UTC)
@Sanmosa：问题在于可能没人去写出达标的机器人。请先按WP:RFBOT流程完成人工监督试运行，再谈社群是否要更改方针允许全自动运行，否则只是空设条文。--YFdyh000（留言） 2021年3月3日 (三) 14:18 (UTC)

提案重启“新设删除员权限”讨论[编辑]

本主題或以下段落文字，在討論結束後應存檔至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，清晰明确，唯“快速除权”应更名“紧急除权”，参考管理员的紧急除权标准，并在落实原因后可根据共识和行政员决定直接复权或重新参选。解任后重新参选条件、不活跃除权等有待完善。--YFdyh000（留言） 2021年2月21日 (日) 14:21 (UTC)
    積壓一點也不多啊，發起理由完全不成立。--AT 2021年2月21日 (日) 14:28 (UTC)
    没太关注站务，但解任投票和这里都有人说站务有积压情况——虽然不一定是存废，但存废和侵权验证是很大占比、很费时间的，分摊一些没什么不好，有权用户的增多也能促进一些关注和讨论。悄悄滥用是另一层面，更低的解任和提报难度可弥补。--YFdyh000（留言） 2021年2月21日 (日) 14:50 (UTC)
  • (－)反对目前的方案：“删除”权限并不是比“封禁”、“保护”更为不敏感的权限；就本人的观察而言，条目删除对新用户的打击有时并不亚于直接对该用户施与封禁。运用删除权限也意味着提名人需时刻具备向受影响用户解释自己删除操作的能力，而这是管理员的核心能力之一。因此，不应该设立当选门槛低于管理员的删除员。--Antigng（留言） 2021年2月21日 (日) 14:35 (UTC)
    1. 就我个人的观察，PJ:AFC对新用户的鼓励与打击程度可能是同等的，期望在意新手的维基人和"提案人'予以关注。2. 不认为提名人无法做到解释自己的删除操作，如果做不到那么离被解任已经很近了，且比管理员更近，部分管理员反而因事务繁忙、解任难度高、疲劳感等原因不详细解释自己的操作依据，或者无视其他人的理由或意见。3. 删除员担任经历可能成为晋升管理员的一步，同时缓解站务压力。4. 其他管理员和删除员可以还原并重启不合适的处理（可能需方针修订；当然，WP:DRV也不错；需明确删除员能否处理DRV，大概是不能）。警告模板和其他不友好行为对新手的打击同样巨大，不是禁止更多人参与站务的理由。--YFdyh000（留言） 2021年2月21日 (日) 15:22 (UTC)
    AFC本意上是帮助新手更好建立条目，不过我参与该计划以来好像就没有通过几个条目……虽然确实对新手打击较大，但我也不知道怎么更好平衡条目质量与保护新手两方面。--LightyearsTalk·Sign#订阅维猫报喵！ 2021年2月22日 (一) 15:19 (UTC)
    没用AFC提交过，很认可帮助新手和同行评审理念，但实务执行中显然存在问题、似乎小圈子。我认为很简单，增加一个阶段，条目内容满足关注度和基本素质（即基本合格。削减后可作小作品），但内容可进一步完善，这种情况下不要驳回为不通过（尤其是通用意见），会使新手以为现有内容不对、这仍不是合格的条目、做了无用功。状态可以是绿色的合格标识附评语，并等待编写人反馈后续意向，或者移到条目但保留隐藏分类，继续在条目讨论页讨论完善。发现您似乎创建了AFC的两个TG群，您能否转交意见和尝试推进讨论（可以ping我）。--YFdyh000（留言） 2021年2月22日 (一) 16:25 (UTC)
    已在您的讨论区留言，我们似乎离题太远，接下来的交流我们可以在您的讨论区进行。再次感谢您的宝贵意见。--LightyearsTalk·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，删除员也可以快速处理广告速删（判定层面是个问题，但管理员未必就做的更好）。--YFdyh000（留言） 2021年2月21日 (日) 15:27 (UTC)
      • 技术和普通站务维护是相对平行正交的维度，但是站务管理中的“封禁”、“删除”与“保护”则不然，不宜将IA/TE的设立作为设立删除员的论据。--Antigng（留言） 2021年2月21日 (日) 14:55 (UTC)
        不太赞成是平行维度，不太懂您的意思。也可理解为我认为将管理员的反破坏职责与站务职责在概念上分拆是好事。--YFdyh000（留言） 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)
      对于存废复核和修订版本删除，个人也倾向反对，在没有出现积压前，存有争议或操作不显著的权限不适合授权，至少不适合新任删除员使用。--YFdyh000（留言） 2021年2月21日 (日) 15:35 (UTC)
(－)反对：現在這個時候設立權限，我認為會讓個別管理員無視規則單憑個人好惡刪除特定頁面的情況變得更為嚴重（變成管理員以外的人都會這樣做），這是申請門檻沒辦法處理的事情，老用戶這樣做的潛在可能性更高。另一方面，我擔憂會引來權限收集的問題。SANMOSA 誓山海而長在，似日月而無休 2021年2月21日 (日) 23:52 (UTC)
  • (！)意見：中维大校遍地都是，少将却是寥寥无几，更何况中将，上将了。Zhuofan WuCien años de soledad 2021年2月22日 (一) 03:05 (UTC)
  • (＋)傾向支持：可以协助处理站务积压，方案方面均支持提案二。不过删除员是否可以选择处理CSD和AFD而非DRV？个人觉得DRV争议比较大。--LightyearsTalk·Sign#订阅维猫报喵！ 2021年2月22日 (一) 15:15 (UTC)
    • 该等限制尚无技术手段能够实现。--Antigng（留言） 2021年2月22日 (一) 15:57 (UTC)
      可以使用方针限制，不过我认为此案最后会得到和这个差不多的结论。--安忆Talk 2021年2月22日 (一) 16:02 (UTC)
      不需要技术手段，违规处理可以发还讨论、警告和必要时除权。--YFdyh000（留言） 2021年2月22日 (一) 16:28 (UTC)
      同意安忆的想法，可以通过方针限制。下面也有设立两个用户组的想法。--LightyearsTalk·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)
      • 人工评议后授权更好，资历不能证明什么。大概需要两个用户组，删除员、高级删除员（含存废复核和修订删除）。--YFdyh000（留言） 2021年2月23日 (二) 07:10 (UTC)
        (＋)支持。删除员处理CSD和AFD，而高级删除员可以处理DRV。--LightyearsTalk·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？其次，我还是认为“二级维护员”需要社群讨论后授权，而不是管理员授权。--LightyearsTalk·Sign#订阅维猫报喵！ 2021年2月23日 (二) 12:24 (UTC)
1.比删除员好听。2.权限集成也许不利于快速成长（熟悉权限、规范和任务）和上任解任（巡查的门槛和后果比删除低得多；可能担心影响站务而忽视解任意见）。不赞成改变现有巡查员和回退员机制，动静太大（方针修改）、收益不大。未必叫初级、二级，初级听上去不那么靠谱，以及“升级”或增加HATC行为。3.个人赞成权限分离，那样还可以剥夺部分权限（类似编辑禁制）。以及或可考虑警告+禁制（移除特定权限x周）之类的更灵活处罚（比如模板编辑员目前是一次严重违规就解任）。x. 如果管理员（sysop）叫站务员或操作员就更好了，可惜不可能。--YFdyh000（留言） 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)
除非受提名管理员的操作特征非常明显（如专注技术），不然投票和问答总会是方方面面，基于个人好恶。除了提升权限拥有者数量，新权限或许能促进一些讨论和新鲜血液的补充、进阶。--YFdyh000（留言） 2021年2月23日 (二) 13:57 (UTC)
管理员不是全能的。如果参选者都表明了自己当选之后的行动方向，还被问一些奇怪问题的话，也挺令人无语的…既然不强制参选者回答所有问题，建议就直接将其忽视掉（如果是我的话）。--安忆Talk 2021年2月23日 (二) 14:09 (UTC)
印象中不少问答质询针对具体类别或案例，不少人将管理员上任当成/盼作解决自己关心问题的“灵丹妙药”。奇奇怪怪、刁钻疑难的问答，以及不信任特定类型操作能力的意见，对管理员上任是个不小的、不一定需要的挑战。就管理员上任难度问题，另一个方法是试用期。--YFdyh000（留言） 2021年2月23日 (二) 14:20 (UTC)
試用期+1，建議不可太長。但因為RFA常常耗費社群相當多精力，因此試用期結束後的續任機制，得要想一下。。。--Hjh474（留言） 2021年2月23日 (二) 14:28 (UTC)
我认为30天（或者4周）适合。RFA可以投票基本达标（如14天内净支持票数>??）后进入试用阶段和授权，阶段结束后讨论总结是否解任（行政员按共识判定），期间有不足也可多次警告和必要时解任。不能解决非试用期解任难度问题。不好意思又跑题了……--YFdyh000（留言） 2021年2月23日 (二) 14:47 (UTC)
试用期不可取，难以定论这个期限有多长，又按什么标准，在我看来只是在为了自己心中的标准二次投票罢了。有问题就和对方说，说过了对方知道了但改不掉却还继续做的话就看情况提除权，没什么大不了的；话说RFA的问题是真的千奇百怪，有的人就是要的圣人，而不是什么管理员、删除员或是什么其他的，严以律人宽以待己。
说回这个删除员，它的很多标准注定是模糊的、量化不了的（包括选举、用权和除权等各个阶段）。管理员的3000次编辑很高吗？其实不是，有的人一周不到就能刷完，所以这类门槛意思意思就行了；假设真有这个删除员了，既然人家是按信任投票上去的，还要人家做管理员的活，那就不要再吝啬自己的信任整什么分级试用等等花活。有人愿意贡献，那就选他，选上来不是做得非常差就够了（不要完美要一般）。况且，什么是做得好？是不犯错是好，还是做得多是好？这看似简单的问题都没办法量化。反正不可能做得又多又没错，因为做得多了肯定会有不合某人意得时候。到时候又会被人翻出某笔远古编辑说话。本来就是闲暇之余做做贡献，居然还要志愿者去打怪升级又不给装备，这恐怕不太合适。我能想象日后是什么光景——做得好没什么人夸，做不好却又有可能被跳出来的一大堆人说。有的人已经忘了“人非圣贤孰能无过”、“知错能改善莫大焉”这些简单的道理。
同意时昭的看法，如果是因为选管理员的问题，那么应该去想办法解决管理员难选的问题，而不是通过这种方式绕过去，没必要单设用户组（甚至还要细分分级）。管理员可以是删除员，反过来也完全可以。值得信任的人、靠谱的人知道自己会做什么、要做什么以及应该做什么。一个是管理员的删除员，多出来的管理员权限可以更好地帮他处理遇到的问题；相反，一个不是管理员的删除员，遇到问题反而会施展不开。都是差不多的标准上去的，后者为的是什么，难不成是为了在删除又需要保护和封禁的时候，再提几个请求刷刷编辑数？
以上是我又看了看历史RFA/RFDA啰嗦的几句，希望不要有人介意。--安忆Talk 2021年2月23日 (二) 15:39 (UTC)
感谢您的意见。我认为社群将RFA视作全能管理员选举的问题中短期内无望解决、无法达成共识，或许还不如尝试分拆权限、快速调整来变相演进。就好似Chrome和Windows 10的快速版本周期，即便屡被吐槽，照样有一定的推进效果，避免大体量的难以调整。--YFdyh000（留言） 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的條目（大部分提刪理由是關注度）其實不用急著刪除，哪怕積壓一段時間也沒問題，從站外非維基人的評價來看很少有人會批評「維基存在低關注度條目」，反倒是有人吐槽亂刪條目[25][26]，所以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:格式手册/朝鲜半岛用语增補以下條文：

以上。SANMOSA 誓山海而長在，似日月而無休 2021年2月24日 (三) 01:03 (UTC)

(？)疑問這種改法是會有什麼作用？以現有的常識判斷，條款之適用必須有進一步的限制，才可能確保本地運用不會偏差。如果削弱了第一章的限制力，並擴大任意詮釋「事實」、「法理」的風險，這樣的修訂恐怕並不會有很好的影響效果吧。提案認為必須重新審視實際的作用，不宜缺少更可靠的限制指明，尤其是本地既有規則的制約--約克客（留言） 2021年3月1日 (一) 01:28 (UTC)
「依據『使用常用名稱原則』」是錯誤的描述，因為使用常用名稱原則僅在條目名稱適用，而從來不在條目內文適用。「事實論述」指的是現在是由哪個政權控制就寫成由哪個政權控制。SANMOSA 江南好，風景舊曾諳 2021年3月1日 (一) 05:48 (UTC)
在現行機制開始難以控制部分問題日趨嚴重的情況下，不認為缺少限制的修訂會有較好效果，如已在上所言這樣可能會製造新的漏洞。要必須強調非常多的編輯，對於事實（fact）和觀點（opinion）的理解還是有很大問題的，缺少限制是可能引發對有關定義新的爭鋒等情況。建議提案重新考慮--約克客（留言） 2021年3月1日 (一) 09:23 (UTC)
我不認為會出這種情況，中文維基百科的人不是白癡。再不然我加註釋說「事實論述」是「de facto」、「法理論述」是「de jure」，讓人直接參照這兩個條目的定義就好了。SANMOSA 江南好，風景舊曾諳 2021年3月1日 (一) 10:51 (UTC)

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

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

@AT。SANMOSA 誓山海而長在，似日月而無休 2021年2月25日 (四) 10:54 (UTC)
@Iokseng。SANMOSA 誓山海而長在，似日月而無休 2021年2月25日 (四) 10:56 (UTC)
我建議通報至管理員佈告版。--AT 2021年2月25日 (四) 10:58 (UTC)
@AT：WP:AIV提報過了，但當時我未收到部分用戶對於其重新命名工作導致部分由模板自動產生的分類出錯的反映。我覺得至少也得把他做的移動操作全數回退，這比較急。SANMOSA 誓山海而長在，似日月而無休 2021年2月25日 (四) 11:00 (UTC)
@Jarodalien：請參與討論，不然我會考慮禁制您編輯分類空間。謝謝。--AT 2021年2月25日 (四) 11:15 (UTC)
正在回退一部分他移動過的分類，但數量有點多，我移不完。SANMOSA 誓山海而長在，似日月而無休 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)
命名常規只規範條目、不規範分類，自然不適用「先到先得」，不要把你自己當成方針。分類的命名看的是更宏觀的其他東西。SANMOSA 誓山海而長在，似日月而無休 2021年2月25日 (四) 15:42 (UTC)
不允许反过来吗。前后极其相似或许先到先得（因为没必要改、WP:OWN），改变命名方式已经不只是先到先得的范畴了。--YFdyh000（留言） 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)
我不同意「這個人一定不懂漢語」的論斷，一時看得較快看錯了所導致的誤認是非常正常的事情。就此例而言，這是前述情況最為經典的例子。SANMOSA 誓山海而長在，似日月而無休 2021年2月25日 (四) 15:42 (UTC)
这是认知不广泛的“常识”（就像公元1年到公元前1年之间有几年，不一定有过半数人答对），有更清楚且简洁表达的情况下不应该改成更模糊、更容易出错的。--YFdyh000（留言） 2021年2月25日 (四) 16:00 (UTC)
@YFdyh000：所以說答案是空集，還是元素為“0年”的單元素集合？⋯⋯--洛普利宁 2021年2月26日 (五) 15:46 (UTC)
这不重要吧……我指看似常识的东西很多人并不清楚，如有没有公元0年，世纪怎么算，年代又怎么算。相比可能模糊但容易猜对的xxxx年代，双重模糊的xx世纪xx年代更难判断。--YFdyh000（留言） 2021年2月26日 (五) 16:01 (UTC)
@Jarodalien：無論如何，你進行的重新命名工作導致部分由模板自動產生的分類出錯這一點是無庸置疑的，我認為你應該將先前所建立和重新命名的分類（包括但不限於某年代相關分類，我認為其他相關分類很可能也有同樣情形）全部統一回模板自動產生的格式，否則這無庸置疑會嚴重影響模板維護工作。SANMOSA 誓山海而長在，似日月而無休 2021年2月25日 (四) 15:42 (UTC)
為免後患，我建議就各類頁面（包括但不限於分類頁）引入「命名一致性」的規定，以有效減少頁面命名上的紛爭，並便利維護。SANMOSA 誓山海而長在，似日月而無休 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年代怎么整。--YFdyh000（留言） 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世纪了Facepalm3.svg 捂脸--YFdyh000（留言） 2021年2月26日 (五) 15:24 (UTC)
读作零零年代、一零年代，就像九零后、零零后。--YFdyh000（留言） 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以外的年代，我大概会读作“__十年代”，读法上没问题。--YFdyh000（留言） 2021年2月26日 (五) 21:01 (UTC)
@@YFdyh000：說到年代的是，請教大家一個問題，最近我都不太用維基百科了，今天我在找資料時發現有條目裡面原有年代的部分被刪除了，查了查是有編輯者刪除了，可能他認為那是考古專家學者考據的年代，不是當時人寫下的年代，譬如，古埃及第三xxx王朝約西元前xxx年-西元前xxx年，所以編輯者把年代刪除在內容改成不知道，現在可以這樣嗎？><?我怕搞不清楚狀況所以問問。--User:浪子魚|愛偷懶的魚🐠※User talk:浪子魚|留言 2021年2月26日 (五) 16:43 (UTC) ──以上未簽名的留言由浪子魚（討論｜貢獻）加入。
@浪子魚：不太清楚您的意思，是条目内容还是分类，年代与条目主题的关系。麻烦您将签名加上内部链接，不然别人不方便查阅和回复，您的ping也不会生效。--YFdyh000（留言） 2021年2月26日 (五) 21:01 (UTC)

买卖维基百科的账户是否合规[编辑]

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

目前有这样的情况吗？--LightyearsTalk·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)
@喵呜猫：分享不是这个定义，此条文指将账号控制权交由他人被发现即会被封禁。类似情况有方针上文的“公司/团体名称”，禁止了组内多人持有同一个账号。花钱买账号，大概率还涉及有偿编辑或利益相关。--YFdyh000（留言） 2021年2月28日 (日) 10:43 (UTC)
要有自動確認用戶願意賣，您的擔憂才成立。-游蛇脫殼/克勞棣 2021年2月28日 (日) 10:28 (UTC)
如果有人愿意买，肯定有人愿意卖，可以“量产”。--YFdyh000（留言） 2021年2月28日 (日) 10:44 (UTC)
既然可以「量產」，為什麼不自己生產，還要花錢買？而且想買的人要如何讓人知道他想買？更重要的是，「拿到一堆自确账户进行编辑」本身就已經違規了(傀儡)(會招致懲罰)，不論是否進行破壞。破壞維基百科又沒錢賺，我好奇誰會花錢做這種損人又損己、徒勞無功的事。是不是我太天真？-游蛇脫殼/克勞棣 2021年2月28日 (日) 11:11 (UTC)
1.需要一些技术和时间（>7天），分工不同，就像代理服务器有人卖、验证码打码有人卖，什么都有人卖。2.如果商品有市场，自然有市场在卖。3.可以绕过半保护和一些反破坏机制。公关公司、饭圈粉丝等，都可能买。这也是WP:CU的作用之一。--YFdyh000（留言） 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)

不太懂具体怎么做。与公告栏的差别。模板说明页未翻译。--YFdyh000（留言） 2021年2月28日 (日) 10:37 (UTC)
通知模板创建者@Taiwania Justo：。另，即使开启此制度，似乎也没有把那个页面提升到指引的必要。——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年3月4日 (四) 14:08 (UTC)

在格式手冊/標點符號#引号中加入 POV 一節[编辑]

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:格式手册/标点符号。

維基百科部分條目中有一些不大適當的引號使用。例如某些編輯歷史甚至是主要為了在看似理性的評論中的個別詞組或詞語上加入引號。鄙人亦曾對類似用法產生疑惑，後發覺容易被誤用/濫用。現建議在WP:格式手冊/標點符號#引号下加入一條內容（基本照搬英文維基百科對應內容）。

現行條文

（無）

提議條文

引5：引號應當用於展示情緒化的意見，特別是在此等意見的用詞不適合由維基百科直接轉述時。在此情形下，來源必須清楚給出。且此等用法不適用於展示文化常態。

  • 張三和李四認為此電影「使人難以忘懷」。
  • 此處所受當地人「厭惡」。

簡短而無過分情緒化的意見可以直接轉述，而非使用引文。為簡單的描述性詞語或詞組加上引號，反而可能引致歧義。讀者可能認為此內容包含反諷或影射，因為一些讀者或將此用法視同「所謂」、「理應」。

  • 可接受：張三和李四認為此電影有意思。
  • 可能會產生歧義：張三和李四認為此電影「有意思」。
  • 應當作為引文：張三和李四認為此電影「有意思但十分令人揪心」。

下給出一些類似例子：

  • 習近平條目中，「第十四世达赖喇嘛也称赞习近平“更务实、更开明”」。
  • 还愿 (游戏)#爭議中，「中国大陆玩家批评團隊「夹带私货」（隱蔽或不光明正大地展示個人政治立场）、「侮辱国家领导人」、“侮辱中国公民”」。

--Yangwenbo99論 文 2021年3月1日 (一) 03:27 (UTC)

“投射”是影射吧。目前而言不反对。--YFdyh000（留言） 2021年3月1日 (一) 08:26 (UTC)
代改了。SANMOSA 江南好，風景舊曾諳 2021年3月1日 (一) 10:33 (UTC)
不反對自英文維基百科補充翻譯格式手冊，但我覺得應該要説明作為正文内使用引文的部分不能過長（過長的例子：全国脱贫攻坚总结表彰大会，都變成新聞稿了），如果實在是比較長，而且確實有需要列出，應該使用{{cquote}}、{{quote}}之類的模板（很多FA和GA都有這樣的使用方式）。SANMOSA 江南好，風景舊曾諳 2021年3月1日 (一) 10:33 (UTC)
建議為此另加一條規則。--Yangwenbo99論 文 2021年3月1日 (一) 18:00 (UTC)
提案人能不能在同一提案下就此事作另擬？SANMOSA 江南好，風景舊曾諳 2021年3月2日 (二) 11:00 (UTC)
另外，维基百科:格式手册/标点符号中有不少格式問題。{{Quote_box}}中的第一個 bullet point 基本上都會被吃掉，各位有沒有甚麼修正的建議？--Yangwenbo99論 文 2021年3月2日 (二) 13:27 (UTC)
我測試一下：
  • Lorem ipsum


  • Lorem ipsum

以上。SANMOSA 江南好，風景舊曾諳 2021年3月2日 (二) 13:41 (UTC)

@Yangwenbo99：根據上面的測試結果，你用bullet point的話（不只在{{Quote box}}，各類的quote模板和wikitable也如是）一定要在第一個bullet point前面開一個新行。SANMOSA 江南好，風景舊曾諳 2021年3月2日 (二) 13:45 (UTC)
维基百科:格式手册/标点符号中的{{Quote_box}}大都是使用 "quote" 指名參數，而非位置參數。而此頁面在上一年年末依舊顯示正常。是否是因為這段時間{{Quote_box}}發生了改動？--Yangwenbo99論 文 2021年3月4日 (四) 08:37 (UTC)
@Yangwenbo99：2月26日被改過一次，先回退了。SANMOSA 江南好，風景舊曾諳 2021年3月4日 (四) 09:47 (UTC)
(＋)支持。SANMOSA 江南好，風景舊曾諳 2021年3月2日 (二) 13:45 (UTC)

對引4的修改[编辑]

依照U:Sanmosa建議，現提議對引4作如下修正：

現行條文

引4：当直接引用多段文字时，尽可能的不要直接使用“引号”加“原文”的形式进行排版。应选择Template:Cquote、Template:Quote、Template:Quote box等引用模板实现直接引用多段文字。

  • 应避免：

??“直接引用的文段一……
“直接引用的文段二……
直接引用的文段三……”

  • 使用模板：

{{Cquote|直接引用的文段一……
直接引用的文段二……
直接引用的文段三……}}

  • 效果为：
提議條文

引4：正文内使用引文的部分不應過長。如有必要直接引用多段文字时，尽可能的不要直接使用“引号”加“原文”的形式进行排版。应选择Template:Cquote、Template:Quote、Template:Quote box等引用模板实现直接引用多段文字。

  • 应避免：

??“直接引用的文段一……
“直接引用的文段二……
直接引用的文段三……”

  • 使用模板：

{{Cquote|直接引用的文段一……
直接引用的文段二……
直接引用的文段三……}}

  • 效果为：

--Yangwenbo99論 文 2021年3月2日 (二) 13:27 (UTC)

(＋)支持。SANMOSA 江南好，風景舊曾諳 2021年3月2日 (二) 13:45 (UTC)

關於快速刪除G8[编辑]

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

現在的快速刪除方針中G8寫的是：

  • 使用模板{{d|G8}}或{{d|rm}}。

可是，自從這筆編輯後，使用「G8」或「rm」作為{{delete}}模板的{{{1}}}參數的話也不會讓頁面顯示任何東西，也不會把頁面放進Category:快速删除候选（例如Special:permalink/64564497）。因此我認為應該修改delete模板或修改WP:CSD方針，以免誤會和誤操作。--Sun8908 怯就輸一世 2021年3月2日 (二) 13:01 (UTC)

我記得我之前在跟其他用戶討論CSD R6的時候，就列過一個表格説明WP:FNC和快速刪除規則的對應關係，我這裏對内容稍作更新後也copy來這裏：
FNC要求 對應快速刪除規則
1 CSD G10
2 CSD R6
3 CSD R6
4 CSD R6
5 CSD R3
6 CSD R6
7 CSD R6
8 CSD G3
9 CSD R6（理論上可以用CSD G8，但現時技術上不能由普通用戶提出）
10 CSD R3
那時候的討論，我曾提過不符合WP:FNC第9款的檔案名在移動成為重新導向後，理論上可以用CSD G8處理，這我認為可以視為使用模板{{d|G8}}或{{d|rm}}的一個可行情況，希望社群可以討論。@Stang。當然，實際上需要由普通用戶本人提出的CSD G8可能還有其他例子，我也歡迎大家舉出，讓大家探討。@Sun8908。SANMOSA 江南好，風景舊曾諳 2021年3月2日 (二) 13:57 (UTC)
既然其他FNC準則也有R6的情況，FNC#9又與其他FNC情況類似，新設R6而非合併到G8並無不妥。--Xiplus#Talk 2021年3月2日 (二) 14:06 (UTC)
已移除。該等刪除都是管理員處理其他請求（例如移動請求）所做出，不允許使用者以G8提刪，而是應該去按對應的流程發起請求（例如移動請求）。--Xiplus#Talk 2021年3月2日 (二) 14:01 (UTC)
取自“https://wiki.bairuo.top/w/index.php?title=Wikipedia:互助客栈/方针&oldid=64617692”