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

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

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

Breezeicons-apps-48-cantor.svg

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


發表前請先搜索存档,參考舊討論中的内容可節省您的時間。
公告板
# 話題 發言 參與 最新發言 最後更新(UTC+8)
1 專題命名空間 171 19 A2569875 2021-04-07 14:22
2 偽命名空間 217 18 A2569875 2021-04-07 14:24
3 WP:捷徑指引草案修訂 21 4 A2569875 2021-04-07 14:14
4 有關某年代相關分類命名統一事宜 41 13 Sanmosa 2021-03-29 19:35
5 提议建立“元维基用户查核指南” 1 1 听风吹过的声音 2021-04-10 17:06
6 修订删除方针第1(删除理由)章节第9项 31 11 KirkLU 2021-04-11 01:49
7 請求第三方管理員參與評估和總結可靠來源討論 1 1 Antigng 2021-03-09 14:40
8 關於Wikipedia:命名常规 (音乐) 74 15 羊羊32521 2021-04-11 10:26
9 (重提)Wikipedia:共识#提案討論及公示時間的執行力度 94 17 DrizzleD 2021-04-05 00:29
10 臺灣原住民族人條目命名(第二次) 55 9 克勞棣 2021-04-04 00:15
11 命名常規擬議修訂 1 1 Jimmy-bot 2021-04-11 16:14
12 有關新增偽命名空間的提議 16 7 LuciferianThomas 2021-04-11 07:10
13 交通關注度指引修訂 1 1 听风吹过的声音 2021-04-10 17:16
14 模板颜色相关规范 38 16 Pseudo Classes 2021-04-10 15:05
15 交通關注度指引適用範圍的擴展 1 1 听风吹过的声音 2021-04-10 17:19
16 提案将维基百科:格式手册/不要模棱两可列入格式手册 1 1 Jimmy-bot 2021-04-11 16:14
17 提议对WP:DYKC的投票须知进行修改 6 5 Sanmosa 2021-04-10 13:59
18 调整界面管理员方针之“权限取得”一节 21 10 羊羊32521 2021-04-11 11:41
19 模板修訂建議 5 5 Lopullinen 2021-04-11 03:19
20 表格標題背景與文字顏色 2 2 星星 2021-04-11 13:20
21 设计一个制度解决部分速删模板挂不上去的页面的删除问题 4 2 Tranve 2021-04-10 14:30
22 关于Wikipedia:关注度 (组织) 2 2 Sanmosa 2021-04-10 14:28
23 限縮{{电视节目的变迁}}模板使用範圍 3 3 星星 2021-04-11 09:31
24 通用行為準則/2021諮詢 6 3 YFdyh000 2021-04-11 00:38
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時,
請先檢查設定是否有誤

專題命名空間[编辑]

[編輯此導航模板]

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

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

本討論的各階段分為:

  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)
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

  • 將會提供給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)
        • @A2569875Green 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)
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。



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

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

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

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

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

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

  • 第三階段為修正指向專題的內部連結,主要要修正的是一些模板、模組等,純粹葉面的內部連結因為有保留重新導向故暫時還會有效,至於需不需要全部修正並刪除重新導向可以討論(日維當時保留大部分的重新導向至今)。已經修復的模板包括{{Namespace pagename}};目前已知待修復的模板有{{Category handler}}及{{Namespace detect}}。其餘將陸續補充。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月29日 (五) 12:57 (UTC)
  • @A2569875:想请问一下快捷方式如何规定?目前是专题都占用了一个WP快捷方式,以后是否都需要把WP快捷方式换成WPJ快捷方式?--LightyearsTalk#欢迎加入智能手机专题 2021年1月30日 (六) 10:02 (UTC)
  • 是否需要修改所有的內部連結,可能需要與「是否需要刪除WP->PJ的重定向」一併討論。-- 五歲抬☎️·☘️) 2021年3月24日 (三) 05:47 (UTC)

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

已完成:
已修改完大多數相關模板。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月14日 (日) 09:33 (UTC)
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。


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

第五階段:討論重新導向與捷徑的設立方式[编辑]

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

本案進入倒數第二個部分。現在將討論未來專題捷徑如何設立,以及原有捷徑的去留:
  • 未來是否允許建立跨WP與PJ空間的捷徑?如果需要,是否需要進一步規範?
  • 未來是否允許建立跨WP與PJ空間的非捷徑的重新導向?
  • 舊有的跨WP與PJ空間的捷徑是否需要清除連入然後(×)删除
[email protected]30000lightyearsTaiwania JustoLuciferianThomas羊羊32521BlackShadowG
請討論-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 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)
既然(我認為)未來不允許建立跨WP與PJ空間的非捷徑重新導向,而且非條目命名空間的非捷徑重新導向本來就使用率低下,如果真的有人意外建立了,都不會有多少連入,清除連入也不是甚麽困難的事,而且還能避免未來的誤用。SANMOSA Σουέζ 2021年3月31日 (三) 07:43 (UTC)
Wikipedia:专题Wikipedia:专题委员会等部分页面为何还没有移动到新的名字空间?还是这些页面不应该移动?--百無一用是書生 () 2021年2月19日 (五) 02:46 (UTC)
先前討論有提到將專題介紹留在WP空間。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月19日 (五) 17:12 (UTC)
专题委员会并非专题介绍,Wikipedia:专题似乎也称不上是介绍,更像是WikiProject:首页的作用--百無一用是書生 () 2021年3月1日 (一) 02:54 (UTC)
個人認為跨WP->PJ沒差,但PJ->WP的不行-- Sunny00217  2021年2月21日 (日) 13:56 (UTC)

第五階段:小結[编辑]

總結以上討論意見:

  1. 禁止建立跨WP與PJ空間的捷徑重新導向。並清理連入頁面後刪除現有跨WP與PJ空間的捷徑重新導向;同时,将PJ名字空间中所有{{shortcut}}中的捷径一律改为以“PJ”开头的捷径,不再推荐使用以WP开头的捷径。→修改R2規範
  2. Wikipedia:專題Wikipedia:專題委員會移動到PJ空間。→需探討是否留重定向
以上-- 五歲抬☎️·☘️) 2021年4月7日 (三) 06:22 (UTC)

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

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

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

偽命名空間[编辑]

[編輯此導航模板]

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

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

@A2569875Taiwania 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)

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

尝试推动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 JustoPseudo ClassesSanmosaA2569875GZWDer公示七日結束,共識期間唯一異議排除,公示獲得通過,有關條文。即日起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)
想向諸位確認一下@A2569875Taiwania 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 JustoLuciferianThomas:啟用偽命名空間能解決什麼問題?我相信這是提案必須討論的重點,我需要有人能回答這個問題。如果沒辦法解決什麼問題,我認為維持現狀即可,也就是WP足矣。然而,就我查看整個討論,似乎都是討論命名空間真偽的可行性,只有幾個留言有提到這個問題。 2021年1月29日 (五) 04:57 (UTC)
看來你是沒有看到最初的討論,見本章節頂端討論導航最初的討論,已經是說明了偽命名空間的作用為讓捷徑意義更加清晰且減少可能構成重複的捷徑名稱的情況。現在不是解決問題的情況,而是優化社群討論和表達的問題了。--LuciferianThomas留言 2021年1月29日 (五) 05:01 (UTC)
一直以來捷徑都沒有什麼規範,尤其是格式手冊、維基專題及LTA的頁面重定向,表達不清之餘容易造成混亂,偽命名空間就是讓這些項目的捷徑統一化,方便社群溝通。--LuciferianThomas留言 2021年1月29日 (五) 05:04 (UTC)
例子:MOS:BOLDWP:MOSBOLD簡潔,但連結至格式手冊的捷徑沒有規範導致格式混亂難以維護,有些有WP:MOS字首有些沒有;而LTA更甚,捷徑完全沒有要表達連結目標為LTA頁面的意思。相對於WP:LTA/HBN,使用偽命名空間概念的LTA:HBN更簡潔易明。在解決捷徑的問題的同時順便推動在其他維基項目運行暢順的偽命名空間比較合適。--LuciferianThomas留言 2021年1月29日 (五) 05:13 (UTC)
@LuciferianThomas:真是抱歉,我沒有一直關注這個提案,突然要找相關討論也找不到。既然如此,我沒意見了。-- 2021年1月29日 (五) 14:02 (UTC)

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

進一步討論[编辑]

自動提刪R2[编辑]

完成 by Jimmy Xu--LuciferianThomas留言 2021年2月1日 (一) 23:04 (UTC)
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

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

@Jimmy Xu。--臺灣杉在此發言 (會客室) 2021年1月31日 (日) 04:31 (UTC)
Special:Diff/64056831-- Sunny00217  2021年2月1日 (一) 11:53 (UTC)
已更新。--Jimmy Xu 2021年2月1日 (一) 14:07 (UTC)

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

MOS捷徑名稱[编辑]

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

WP:NS2021/MOSSC,已列出部分格式手冊可用捷徑,請檢查,並協助補充。--LuciferianThomas留言 2021年2月1日 (一) 08:48 (UTC)
已完成,請協助檢查。--LuciferianThomas留言 2021年2月3日 (三) 04:35 (UTC)

軟重定向[编辑]

已否決:
--LuciferianThomas留言 2021年1月31日 (日) 04:58 (UTC)
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

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

(-)反对,原有重新導向應保留,沒必要軟重新導向。-- 2021年1月31日 (日) 03:56 (UTC)
或是透過JS小工具提示功能,讓用戶在非討論頁面中點擊舊有連結時提示修改為新連結?--LuciferianThomas留言 2021年1月31日 (日) 04:23 (UTC)
不必更動,英語維基百科部分MOS也有用WP的捷徑。--臺灣杉在此發言 (會客室) 2021年1月31日 (日) 04:32 (UTC)
好的,那麼就捨棄軟重定向,只重新議論MOS的捷徑名稱。--LuciferianThomas留言 2021年1月31日 (日) 04:52 (UTC)

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

技術問題處理[编辑]

已通過:
已完成設定並佈署。-- 五歲抬☎️·☘️) 2021年3月24日 (三) 05:50 (UTC)
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

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

小補充:偽命名空間捷徑可用{{捷徑重定向}}標記,已加入自動偵測偽命名空間顯示偽命名空間簡單說明。--LuciferianThomas留言 2021年2月2日 (二) 05:55 (UTC)
另外@A2569875:已創建MOS:MOS:MOSMOS:手冊MOS:格式手冊供你們測試各項技術問題。--LuciferianThomas留言 2021年2月2日 (二) 05:59 (UTC)
根據Wikipedia:保護方針#需进行公示,即使偽命名空間已獲得社群共識,輕微影響外觀顯示的編輯仍需公示七日,因為未添加亦不會影響偽命名空間的運作。-- 2021年2月2日 (二) 06:29 (UTC)
@LuciferianThomas。-- 2021年2月2日 (二) 06:34 (UTC)
@LuciferianThomasPseudo 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)
(:)回應@AnYiLinUser: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.jsWP: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)
公示通過了,@A2569875AnYiLin。--LuciferianThomas留言 2021年2月15日 (一) 06:49 (UTC)
@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)

完成:已通過並佈署。-- 五歲抬☎️·☘️) 2021年3月24日 (三) 05:50 (UTC)

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

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

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

不應做出預見性保護。--Xiplus#Talk 2021年2月2日 (二) 10:26 (UTC)
若捷徑指向的條目因為破壞被保護,有需要跟隨進行保護嗎?--LuciferianThomas留言 2021年2月2日 (二) 12:06 (UTC)
不需要吧,有這樣的案例嗎?--Xiplus#Talk 2021年2月2日 (二) 12:30 (UTC)
案例我不清楚,但我倒是覺得需要,尤其本來有某些LTA有破壞自己LTA頁的傾向,可算是高風險。--LuciferianThomas留言 2021年2月2日 (二) 12:59 (UTC)
有破壞事實就能保護,不需預先保護。--Xiplus#Talk 2021年2月2日 (二) 13:04 (UTC)
建议用滥用过滤器阻止非自动确认用户编辑,配以相关警告。--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)
  • 「快速刪除方針的應用有時並不限於快速刪除本身」如無異議將在適當的時間進行公示。-- 五歲抬☎️·☘️) 2021年4月7日 (三) 06:24 (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)
@羊羊32521YFdyh000:看來LTA還是需要升格為獨立的名字空間,才不會被其他名字空間的設定檔左右。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月3日 (三) 18:57 (UTC)
開新討論吧。--LuciferianThomas留言 2021年2月3日 (三) 22:29 (UTC)
連過去的是WP,可以將該頁NOINDEX吧,那麼相關捷徑就會有同樣效果?--臺灣杉在此發言 (會客室) 2021年2月4日 (四) 08:39 (UTC)
其實Google搜尋似乎沒看到這些頁面,或許重定向本來就被忽略?--LuciferianThomas留言 2021年2月5日 (五) 01:52 (UTC)
Bing找得到但直接顯示目標頁面內容。--LuciferianThomas留言 2021年2月5日 (五) 01:55 (UTC)
所以还需要noindex吗 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年2月18日 (四) 03:02 (UTC)
需要是獨立的名字空間才能設定noindex—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月18日 (四) 10:12 (UTC)
@羊羊32521:我認為如果可以設定的話會更佳,但可能命名空間化會比較方便。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年3月3日 (三) 05:20 (UTC)
那我周末再提一下 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月3日 (三) 15:00 (UTC)
(?)疑問改这个是否可行?--安忆Talk 2021年3月3日 (三) 15:13 (UTC)
仍支持命名空間案,我只是覺得提升命名空間案一直被人以奇怪的理由關掉很可惜。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年3月3日 (三) 15:21 (UTC)
那就搬新段重開吧,抱歉太亂了。--LuciferianThomas留言 2021年3月6日 (六) 06:51 (UTC)
也沒有亂吧,個段落應該分開檢視吧,怎麼會不能放在兩個結束之議案的中間呢?-- 五歲抬☎️·☘️) 2021年3月10日 (三) 06:00 (UTC)
从语法看可以。--YFdyh000留言) 2021年3月3日 (三) 15:22 (UTC)
以往phab有修改此部分的先例嗎?-- 五歲抬☎️·☘️) 2021年3月17日 (三) 06:42 (UTC)
如果沒有的話,我認為很難實行。-- 五歲抬☎️·☘️) 2021年3月31日 (三) 06:51 (UTC)
實測上Google應沒有對重新導向進行索引(例如搜尋"LTA:蘇俞安"找不到該重新導向或是目標頁面),所以我們應沒必要再對其標記NOINDEX。--Xiplus#Talk 2021年3月31日 (三) 08:55 (UTC)
Google搜尋重新導向時會顯示目標頁的內容,即會有一行「(重新導向自)」,請見[4],但是不影響偽命名空間。-- 2021年4月5日 (一) 07:29 (UTC)
google:detache出现了一个到https://en.wikipedia.org/?title=Detach%C3%A9&redirect=no的搜索结果。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月11日 (日) 14:31 (UTC)

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

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

[編輯此導航模板]

說明[编辑]

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

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

本討論的各階段分為:

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

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

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

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

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

已通過:
已通過,並完成主要設定。-- 五歲抬☎️·☘️) 2021年3月24日 (三) 05:55 (UTC)
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

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


完成:設定完畢,有問題請在此提出。-- 五歲抬☎️·☘️) 2021年3月24日 (三) 05:55 (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)
不急,因為#第五階段:討論重新導向與捷徑的設立方式也還在討論。-- 五歲抬☎️·☘️) 2021年3月17日 (三) 06:43 (UTC)
上述第五階段將會在適當的時機公示。-- 五歲抬☎️·☘️) 2021年3月31日 (三) 06:50 (UTC)

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

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

@ATSANMOSA 誓山海而長在,似日月而無休 2021年2月25日 (四) 10:54 (UTC)
@IoksengSANMOSA 誓山海而長在,似日月而無休 2021年2月25日 (四) 10:56 (UTC)
我建議通報至管理員佈告版。--AT 2021年2月25日 (四) 10:58 (UTC)
@ATWP: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)
支持這個提議,而且可以把「年代分類」當作首要討論對象,未來可以擴及其他分類原則。我支持“1950年代”這個寫法,理由如下:
  1. 此次討論顯示“19世纪50年代”這個用法確實容易導致誤判。
  2. “1950年代”寫法較為簡潔。
  3. 分類與主條目名稱統一對讀者來說最為便利,按照年代列表目前所有年代主條目都是採取“1950年代”這個寫法。
  4. User:Sanmosa在上方已提及的分類維護問題。--迴廊彼端留言) 2021年3月6日 (六) 03:10 (UTC)
  • “19世纪50年代”不是相等於“1950年代”嗎。--Temp3600留言) 2021年2月26日 (五) 13:29 (UTC)
認真?“19世纪50年代”相等於“1850年代”,“20世纪50年代”才相等於“1950年代”。-游蛇脫殼/克勞 2021年2月26日 (五) 14:16 (UTC)
@Temp3600:想一下2000年是几世纪,称多少年代。以及Category:2000年代怎么整。--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)
@YFdyh000:好,謝謝你告訴我浪子魚留言) 2021年3月9日 (二) 07:12 (UTC)

針對性決議[编辑]

通過:
通過。SANMOSA Σουέζ 2021年3月29日 (一) 09:11 (UTC)
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

我這裏的建議是:為便利分類維護,並避免由模板自動產生的分類出錯,當將所有以“YY世紀YY年代”格式命名的分類重新命名為“XXXX年代”格式、將所有以“創立”格式命名的分類重新命名為“建立”格式。頁面命名一致性的通用(普遍性)條文會稍後草擬,針對性的決議應該先通過。SANMOSA 江南好,風景舊曾諳 2021年3月15日 (一) 08:18 (UTC)
現公示以下針對性決議7日:將所有以「YY世紀YY年代」格式命名的分類重新命名為「XXXX年代」格式、將所有以「創立」格式命名的分類重新命名為「建立」格式。SANMOSA 江南好,風景舊曾諳 2021年3月22日 (一) 10:15 (UTC)
(+)贊成--YFdyh000留言) 2021年3月22日 (一) 11:06 (UTC)
前者同意,以便於維護,減少因格式之混雜不一所造成的分類維護困難;但後者則建議以既有母分類(諸如「各年建立的OOO」等,後續子分類一併以「建立的OOO」為原則)的命名格式為主,倘若尚無母分類者建議以「建立」為主要命名格式。--Steven |_-。) 2021年3月23日 (二) 14:52 (UTC)
兩者皆贊成,理由如下:
XXXX年代部分-
  1. 以上討論顯示“19世纪50年代”這個用法容易誤判。
  2. “1950年代”寫法較為簡潔。
  3. 分類與主條目名稱統一對讀者來說最為便利,按照年代列表目前所有年代主條目都是採取“1950年代”這個寫法。
  4. User:Sanmosa在上方已提及的分類維護問題
建立部分-
  1. 以「創立」為名的分類數量明顯少於以「建立」為名的分類。--迴廊彼端留言) 2021年3月23日 (二) 15:15 (UTC)

本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
@YFdyh000StevenK234迴廊彼端:決議已通過。名為「創立」的分類已經全部處理。以“YY世紀YY年代”格式命名的分類太多,未能全部重新命名,暫時只處理了「19世紀00年代」、「19世紀10年代」、「21世紀10年代」、「21世紀20年代」和整個18世紀,其他可能需要請求bot,或靠各位的幫助自行移動,我會嘗試移動一部分。移動理由應使用「Special:diff/64972159決議通過統一命名格式」。SANMOSA Σουέζ 2021年3月29日 (一) 09:28 (UTC)

頁面命名一致性的通用(普遍性)條文[编辑]

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

本章節暫時不存檔。欲讓機器人存檔,請移除本模板。留言請置於本模板上方。

提议建立“元维基用户查核指南”[编辑]

修订删除方针第1(删除理由)章节第9项[编辑]

对象:Wikipedia:删除方针#9
提案:
現行條文

9. 多余无用,且影响其他模板命名或者百科运作的模板。

提議條文

9. 未被使用或被脚本引用,且影响其他模板命名或者百科运作的模板,或近期没有使用价值也缺乏参考意义,其中:

  • 参考价值,可以指诸如:功能已被合并的模板,仍被部分页面的历史版本所使用,其存在有助于主要历史版本完整呈现时,模板所具备的价值。
理由:近期在存废讨论和存废复核中多见有关多余无用模板是否应当保留的讨论,一些模板尽管并非影响其他模板命名或者百科运作,也有合意删除的,且这种删除也并非不合理:
  1. 2021年1月“Template:2017年香港播出之動畫”存废复核指出此种删除其实回应了站内“日常整理、保持井然有序”的需求,我认为这是合理的;
  2. 该条方针制定的原始讨论来看,现行条文的制定主要是为避免仅仅因为没有链入而提删(尤其实务上也起到了阻止对无链入模板作单纯批量提删的效果),而本意不是一概地阻碍多余无用但尚未影响模板命名和百科运作被删除。
故建议允许“经讨论在合理预期范围内近期没有使用价值也缺乏参考意义”也作为一可选条件,适当放宽现行条文。
以上。--Kirk★ # 2021年3月7日 (日) 15:45 (UTC)
这样的话“影响其他模板命名或者百科运作的模板”无需再提。同意你的理由,我建议改成一句话“多余无用的模板”即可,原因是:
  1. 其他的删除理由比较简洁,没这么多字。
  2. 模板除了嵌入和脚本外还有其他使用方式(如subst),没必要列举。
  3. “参考价值”是一种保留模板的理由,但不需要写在删除方针里,完全可以在存废讨论中提出。
--Lt2818留言) 2021年3月7日 (日) 17:25 (UTC)
改成一句话亦可,但应有适当描述阻挠单纯大批量提删无链入模板的行为(这也是之前加入“且影响其他模板命名或者百科运作”这一条件考量之一),第3条原因所指的“完全可以在存废讨论中提出”,建立在所提出删除是适量的,可/来得及被社群仔细审视的基础上,而不是不足以应付的。故,第1条原因的简洁需求不是最终需求,而要建立在方针能够适用、能够阐述清楚规则的基础上。--Kirk★ # 2021年3月7日 (日) 17:35 (UTC)
你的提议条文说实话没阐述清楚,看两三遍才能读懂。整段话结构是!(A|B)&((C|D)|(!E&!F...)),不被你绕晕才怪。
要达到目的就直接说明好了,不用兜圈子。“多余无用的模板。请注意无链入模板也可能有用,并非提删的充分理由。”--Lt2818留言) 2021年3月7日 (日) 18:08 (UTC)
可。(或再补个,“不要批量提删”一类的)。--KirkLU-Librarian留言) 2021年3月7日 (日) 18:22 (UTC)
也不用。不合适的批量提删容易引起反感,离封禁不远。--Lt2818留言) 2021年3月7日 (日) 18:32 (UTC)
好,这样说大致也是合理的。Lt2818阁下的方案,我觉得我也是可以赞成的。--Kirk★ # 2021年3月8日 (一) 06:17 (UTC)
(+)支持:修訂得很好,但建議把「且」改為「或」。--蟲蟲飛♡♡→♡℃留言 2021年3月8日 (一) 04:27 (UTC)
絕對不能。--Bookwith留言) 2021年3月8日 (一) 07:50 (UTC)
  • 現在afd提刪理由都不會符“且”的條件,如果保留,則引發drv案,如果刪除,又不符方針。--蟲蟲飛♡♡→♡℃留言 2021年3月8日 (一) 11:06 (UTC)
DP説的是“一個頁面通常出於下列原因而需要被刪除”,所以在一定的情況下,不是那14個理由也能刪除(但有點IAR了)。另一方面,DP有14個理由,那不合9但合其他還是能刪除(例如12)。SANMOSA 江南好,風景舊曾諳 2021年3月8日 (一) 12:27 (UTC)
方案比较:
現行條文

9. 多余无用,且影响其他模板命名或者百科运作的模板。

提議條文

9. 未被使用或被脚本引用,且影响其他模板命名或者百科运作的模板,或近期没有使用价值也缺乏参考意义,其中:

  • 参考价值,可以指诸如:功能已被合并的模板,仍被部分页面的历史版本所使用,其存在有助于主要历史版本完整呈现时,模板所具备的价值。
現行條文

9. 多余无用,且影响其他模板命名或者百科运作的模板。

提議條文

9. 多余无用的模板。请注意无链入模板也可能有用,模板无链入并非提删的充分理由。

两个方案都还行,看看大家意见。无论采哪种,我认为最有必要实现的还是两点:
  1. 为什么改)放松过于严苛的约束,以免阻碍正常清理工作;
  2. 改成什么样)保证社群能够在AFD,对有无使用价值、参考价值的问题进行仔细审视、讨论和决定;
    包括,防止以“无用”为由进行批量提删,致使社群无暇审视、扰乱AFD运作的情况发生。--Kirk★ # 2021年3月9日 (二) 12:12 (UTC)

合并后新提案

現行條文

9. 多余无用,且影响其他模板命名或者百科运作的模板。

提議條文

9. 多余无用的模板。[1]

参考資料

  1. ^ 模板无链入并非提删的充分理由,除链入外应从是否被脚本引用、是否有助于主要历史版本完整呈现、是否短期内有机会再被复用等方面考量是否仍有使用价值。
基于上述两种方案和修订所期望达到的目的,提出了一个字面上简洁、而通过注释使得意思完整的新提案,作为拟付诸公示的文本。若经讨论合适可付诸公示。--Kirk★ # 2021年3月12日 (五) 14:19 (UTC)
还可以。建议你删去最后一句话,这和“游戏维基规则”不大一样,也没必要丑话在前,况且有时候确实需要大量提删模板。--Lt2818留言) 2021年3月12日 (五) 15:01 (UTC)
两点想法:
  1. 指出“纯粹大量提删”的违规风险,不损害合理提删。 合理的大量提删往往是(虽然也并不必然是)系列模板(,就意味着可以合并审视),且更重要的是会附有为何需要大量提删的合理理由,且提删者常常会为社群审视提供必要便利。
  2. 正是有鉴于方针上一次收紧的原因,本次方针在放宽提删条件的同时,期待使用现行方针给WP:DISRUPT行为设置明确的阻碍(或事先劝诫)。纯粹“挖坟”旧模板、无差别大批量送交的行为,是滥用方针提供的提删程序,“用以推进明显非方针原意的目的”。[1]而方针的原意——同时也是根据现有的先例——是帮助编辑更方便地开展对模板的日常整理工作。[2][3][4]
以上。--Kirk★ # 2021年3月12日 (五) 18:20 (UTC)
提删者如果根本不重视维基规则,“游戏维基规则”的帽子戴着就不合适。不当行为还有很多种(比如把模板的链入都删除后提删之),无法一一列举。以此观之,条文越细,可能的漏洞就越多,所以宁可保持简洁,以留有适应各种情况的余地。--Lt2818留言) 2021年3月14日 (日) 12:15 (UTC)
  • (+)支持,不过最后一句话有点WP:BEAN。——BlackShadowG留言维基百科20岁生日快乐! 2021年3月13日 (六) 14:25 (UTC)
  • (+)支持最新提案。最后一句赞成删掉,不需预先警告模糊的边界,有碍勇于编辑。--YFdyh000留言) 2021年3月13日 (六) 14:33 (UTC)
    啊,众意如此便不明确写入了。根据具体情况适用GAME亦可。--Kirk★ # 2021年3月14日 (日) 11:34 (UTC)
  • 支持,影響其他模板命名或者百科運作的模板界定籠統-- Sunny00217  2021年3月14日 (日) 14:21 (UTC)
  • 不是很同意。删除是最终手段,模板“多余无用”(即使并不只在无链入的意义上无用)并不成为要删的理由。提删者必须说明删除该模板为何有利于百科全书建设。或许有人认为多余无用的模板的存在本身就不利于百科全书建设,但我现在找不到同意这一点的充足理由。--DrizzleD (按此给我留言) 2021年3月15日 (一) 10:04 (UTC)
    @DrizzleD:几方面想法:
    1. 修订主要是出于,对诸多存废案提出(或至少反映出)的“本站日常整理、保持井然有序”[2]的需求所进行的回应;逐案复核并以超越基本字面意思的方式说理[2]应当仅可作为短期措施,更长期来说如果需求合理,制定统一的新规则回应这种需求并给予明确规范是必要的;
    2. 在方针上回应这种需求(“本站日常整理、保持井然有序”),实际上就是认可其合理性,认可了处理“多余无用”模板确实能带来益处,包括但不限于(以下几类可能互有重叠):
      • 剔除无用的旧模板,有利于防止(尤其是新手或许因为不熟悉会)意外地使用旧的模板或在旧模板上贡献。
      • 所反映内容已在现实中失去效力的模板(比如,南京市旗帜模板[4])可以防止此类失效内容再被添加进条目。
      • 有些模板是纳入分类的,对确实不需要的模板进行清理,也能有利于分类的整理。
      • 甚至仅仅是视觉上,对整齐的追求。(只要能符合前提——确保被删模板确实无用)
    3. 为什么草案要求提删时审视“确保无用”而不同时要求说明“删除所带来的益处”:
      • 主要是因为“确保无用”才是最决定性的规则——即使论证了有一笔删除很多益处,只要模板仍然是“有用”的,就应当通过其他适当方式协调处理——也是最需要众意审视的规则(类似“利于呈现历史版本”、“被脚本引用”的情况,由大家共同审视是最妥当的)。
      • 而与之相对地,“观感整齐”、“利于分类整理”、“利于防止废弃版本误用”等利处反而是普遍存在的(比如,多数模板是有分类的,模板的废弃多数是因为不必要也不应当再使用),不是提删说理和审视的重点。
      • 况且,模板的“废弃、不再使用、也不具有其他可利用价值”本身也事实上证明了“改善后继续使用”或“挪为他用”已是不可能或不经济(方便)或不必要的,其实也就证明了删除并不违背“删除是最终手段”这个精神。(“删除是最终手段”实际上是一种“我觉得还可以再抢救一下”的精神,对于一个有潜力的条目这个原则自然重要,对于废弃的模板却往往不是如此)
    以上,不知妥否?--Kirk★ # 2021年3月15日 (一) 16:01 (UTC)
    • 给废弃模板挂上{{deprecated}}等,足以防止新手意外使用旧模板。
    • 删除废弃模板源代码的[[Category:]]项,应该不会比删除它们更麻烦。
    • 请问对整齐的追求中的“整齐”是指哪一方面?
    • 人们很难预见一个模板是不是有用。原先以为没用的东西最后被证明有用的事情,至少在人类历史上为数不少。至于在维基百科上,也容易想象这样的情景,例如后来者利用了原废弃模板的代码(即使不利用内容)等。
    • 显然不应该使用的模板,也许(不敢说往往)可以依其他方针删除,例如广告宣传。
    • 对于某些个例,确实干扰到了百科运作的模板,可以依原方针删除。
    • 但我确实想到一个可能的通用理由,妨碍搜索。不知道技术层面上能否解决此问题。--DrizzleD (按此给我留言) 2021年3月21日 (日) 06:00 (UTC)
      这和删除无用的MediaWiki系统消息没两样。你的理由对于非模板也一样适用,举个例子,难道删除小小作品还要说明为何有利于百科全书建设?维基百科不能变成垃圾堆,这一条就足够了。--Lt2818留言) 2021年3月21日 (日) 10:41 (UTC)
      小小作品是在条目空间的,废弃模板不是。--DrizzleD (按此给我留言) 2021年3月28日 (日) 07:23 (UTC)
      @DrizzleD:意见部分同上:
      • “不整齐”是多方面的:提案设立的删除标准包括了没有使用和参考价值,加挂“不活跃/不使用/存档模板”的通常作用是备考(如,讨论页存档)或以备使用(如,不活跃专题)。加挂{{deprecated}}等模板但实际没有参考和使用价值,移除Category让原本各自归类的模板变得“流浪”,再加上(如您所说)这些模板又被搜索到,从而降低搜索结果的有效性。
      • “有用”或无用的问题,也没有上升到“最后被证明”的高度,只是以“近(短)期”内为准。看远期缺乏意义,不仅谁也看不准,且从模板技术实现和所包含的内容都不断变化的角度看,远期对陈年旧模板进行改造还不如重做更为方便也是高度盖然的。[5]
      总之,删除作为处理一部分退役模板的“最终手段”,符合删除方针的精神,不显著有害的同时,带来了一部分利处。--Kirk # 2021年3月22日 (一) 15:59 (UTC)
      • 凯恩斯这么说的背景是扩张性的经济政策的确至少在短期内有益,并不是长期危害看不清,所以问题还是回到比较好处和害处上面来。
      • 移除Category固然让原本各自归类的模板变得“流浪”,但此种“流浪”的程度低于直接删除带来的“流浪”的程度。毕竟“流浪”不好,也是因为它会妨碍利用。
      • 从实践上来说,难以期望每个提删者和参与讨论者能充分检查“是否被脚本引用、是否有助于主要历史版本完整呈现、是否短期内有机会再被复用等方面”,例如检查模板在未知条目的历史版本中的出现要比检查条目关注度困难得多。存在错删的风险。--DrizzleD (按此给我留言) 2021年3月28日 (日) 07:37 (UTC)
      不过我确实还没想到一个能让废弃模板逃脱一般搜索,却又能在某种选项下搜索到(否则失去意义)的办法 囧rz……--DrizzleD (按此给我留言) 2021年3月28日 (日) 07:39 (UTC)
      @DrizzleD:我能认可您提出的潜在风险的问题,不过我还是认为收益还是更大的。(考虑到方案的利弊上面逐项列示大致已经充分了)或许我换个角度,具体来说,此处所讨论的内容实际上是为了澄清包括前面提到的四个存废[2][3][4]在内的所有类似案例到底应该如何操作。或许为合理的实操建立更明确的规则,比完全需要逐个超越方针原文适用更为有益。--Kirk # 2021年3月29日 (一) 14:29 (UTC)
  • 小小作品是主空間,標準就不同了。另外未見有甚麼一定需要刪除舊模版的理由。--Temp3600留言) 2021年4月5日 (一) 15:54 (UTC)
颇感讨论时间越长,持反对意见的编辑越多,可再观察7日,如若大家认为共识不够充分,建议搁置。--Kirk # 2021年4月10日 (六) 17:49 (UTC)

参考資料

  1. ^ Wikipedia:游戏维基规则第4(滥用程序)章节。在“游戏维基规则、人身攻击、为阐述观点而扰乱”三种情形中,模板提删尤以第一种为甚。
  2. ^ 2.0 2.1 2.2 2.3 2021年1月“Template:2017年香港播出之動畫”存废复核([2021]DRV-01/11-23{TPLT}):“……不应该过度理解为阻碍本站日常整理、保持井然有序之理由……”。
  3. ^ 3.0 3.1 2021年1月29日“Template:NFSC”存废讨论([2021]AFD-01/29-9{TPLT}),并2021年2月“Template:NFSC”存废复核申请([2021]DRV-02/09-26{TPLT})。
  4. ^ 4.0 4.1 4.2 2021年2月“Template:南京市”存废复核申请([2021]DRV-02/20-40{TPLT})。
  5. ^ 或许可以不完全恰当地借用凯恩斯的一句话:“用长期指导当下是一种误导。因为长期来看,我们都完了。(……this long run is a misleading guide to current affairs. In the long run we are all dead.)”John Maynard Keynes, A Track on Monetary Reform, Promethus Books, 2000 (originally 1923), p. 80.

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


  • 该请求已受理;相应讨论将择期关闭。--Antigng留言) 2021年3月9日 (二) 06:40 (UTC)

本章節暫時不存檔,直至问题解决。欲讓機器人存檔,請移除本模板。留言請置於本模板上方。

關於Wikipedia:命名常规 (音乐)[编辑]

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

希望各位可以給點意見,協助改善該命名常规Ohtashinichiro和平至上LeehsiaoSanmosaTombus20032000百战天虫Kriz Ju生米一粒Pseudo ClassesKodokunaSmileEasterliesAT卡達YumetoSickManWP羊羊32521EdwardAlexanderCrowleyZhaoweizhi0325MoonLight3650HXXXXPunkhippieLouis0921geePeace 621WhykittyMoonshimmer93夜来南风起Fake12345。 --無心*插柳*柳橙汁 2021年3月15日 (一) 06:12 (UTC)

提示:阁下该次ping操作没有一个人会收到,因为您一次性同时ping了超过五十人。--Milky·Defer 2021年3月14日 (日) 20:08 (UTC)
@MilkyDefer:(´_ゝ`)你沒提,我都忘了我人數超標了。 --無心*插柳*柳橙汁 2021年3月15日 (一) 06:13 (UTC)
我有ping到人嗎?TreasureBabe325Hijk910Jacklamf1d14Ericliu1912NaveradSoftyuSammypanTw dramaShingkei李新阳CHih-See HsiePv163JoJo_appendLopullinenAnYiLinYel D'ohanTemp3600Bigbullfrog1996陳寅恪TenhumantenokPrince of EreborK.Y.K.Z.K.ArivgaoFredYYooApple vTfcheng5597Comrade JohnAdsa562Austin ZhangMoonLight3650GracellleeShwangtianyuan --無心*插柳*柳橙汁 2021年3月15日 (一) 14:05 (UTC)
有ping到。請簡單歸納一下你覺得討論者需要注意的重點。謝謝。-hiJK910 七一七二一 2021年3月15日 (一) 14:10 (UTC)
@Hijk910:注意的重點嘛...,當屬於上次關於外文問題所寫的「外文規範」,另外我也把上次羊羊32521大的古典音樂內容放入其中。而括號的使用和消歧義,想說藉由這次討論一起解決。 --無心*插柳*柳橙汁 2021年3月15日 (一) 15:11 (UTC)
有。我被ping了兩次。—— Eric Liu 創造は生命(留言留名學生會 2021年3月15日 (一) 14:14 (UTC)
(!)意見:1. 「夠格」一詞不夠正式。2. 關於「「『(歌曲)』:適用於所有歌曲,通常命名時優先使用」,請問是不是指像炎 (歌曲)這些「(歌曲)」跟「(單曲)」皆可的條目,「必須」還是「建議」以「(歌曲)」為消歧義呢?-hiJK910 七一七二一 2021年3月15日 (一) 14:18 (UTC)
我這個人最沒有主見了,關於「(單曲)」,我上次被百战天虫大說服後[5],覺得很有道理。當然,如果是像ARRIVAL OF EVERGLOW這種單曲專輯使用「(單曲)」,我就覺得還行。
但就目前而言,都是歌曲不用「(歌曲)」而使用「(單曲)」到底是為什麼?我這邊問一下@Ryokie38:,當初建立½ (川本真琴單曲)使用單曲而不像1/2 (川本真琴の曲)日语1/2 (川本真琴の曲)使用歌曲的原因是什麼?。 --無心*插柳*柳橙汁 2021年3月15日 (一) 14:46 (UTC)
被Tag兩次啦(茶),基本上名稱方面沒有多大問題。順帶一提,自己也比較傾向於用「(人名歌曲)」或「(人名單曲輯)」或「(人名專輯)」三種來命名...好奇其他人的看法。-by 全速前進~~Yosoro!!~~的Tsuna Lu留言) 2021年3月15日 (一) 16:07 (UTC)
@Adsa562:我贊同人名的部分,直接使用人名可以避免以後移動的麻煩是好事,但如果是像胡薩維克 (歌曲)這種冷門的名稱或是像妮裳馬戲團 (歌曲)專門到極點的,不用加人名也沒問題。 --無心*插柳*柳橙汁 2021年3月15日 (一) 16:27 (UTC)
要跟en:Wikipedia:Naming conventions (music)連結吧,然後可以順便參考一下,像關於單曲/歌曲的問題,我覺得宜與英維一樣「儘量避免使用單曲」(If possible, avoid using other terms like "(single)", "(cassette)" or "(CD single)", etc.)--Austin Zhang留言) 2021年3月15日 (一) 19:53 (UTC)
对于单首发行的歌曲,消歧义时用歌曲没有问题,但是当单曲发行时有附带B面歌曲且该条目也有介绍该B面歌曲(而不是顺带提及)的时候,用单曲消歧义更合适吧。--无所事事/想要狗带 2021年3月16日 (二) 19:05 (UTC)
@Softyu:我也有這麼想過,但鑑定不容易。我在下面列出幾個,你覺得哪些可以保留其單曲消歧义。 --無心*插柳*柳橙汁 2021年3月17日 (三) 15:49 (UTC)
  1. 四季 (單曲)
  2. Gravity (LUNA SEA單曲)
  3. CLEAR (坂本真綾單曲)
  4. 矛盾心理 (榉坂46单曲)
  5. Lemon (米津玄師單曲)
个人观点来说,保留单曲的程度是2<5=3<1=4,4有不止一首B面曲得到有效介绍,1则是在制作及商业成绩方面皆有充分介绍B面曲,3的介绍相比1单薄,但也算有效,5是仅有一句话的顺带提及,2则是完全没有来源,不过实际操作中,可以考虑对包含B面曲的或所有歌手自身称之为单曲(single)的条目以单曲消歧义,毕竟无论如何也要“名从主人”。
我這邊再給幾個增加樣本數,世界的盡頭 (單曲)Yellow (木村KAELA單曲)FACE (NU'EST單曲)MAGIC (SHOW單曲)崖上的波妞 (單曲)Reflection (林原惠單曲)口唇 (GLAY單曲)髮夾 (單曲)。“名从主人”方面你說名稱那還有道理,但消歧义也如此就...(也不是不行啦,這在命名常规寫仔細一點)。 --無心*插柳*柳橙汁 2021年3月17日 (三) 23:56 (UTC)
主要是有D (BIGBANG单曲)H (滨崎步单曲)这种无法以“歌曲”消歧义的条目存在,导致其他单曲类型条目如果以“歌曲”消歧义的话会产生问题,如果把Moments (濱崎步單曲)改成Moments (濱崎步歌曲)肯定会产生争议的吧。--无所事事/想要狗带 2021年3月18日 (四) 06:29 (UTC)
D (BIGBANG单曲)H (滨崎步单曲)這兩個使用單曲沒有問題(就像我前面提到的ARRIVAL OF EVERGLOW)。我引用星巴克女王大的說法來講就是「單曲是偏向介紹某張CD,而歌曲是偏向介紹某首歌曲,而我們寫的主要與歌曲內容有關,而不是介紹某張單曲CD。」 --無心*插柳*柳橙汁 2021年3月19日 (五) 01:19 (UTC)
为什么“我們寫的主要與歌曲內容有關,而不是介紹某張單曲CD”??我从来的看法是介绍某张单曲,及其中收录的歌曲。->>Vocal&Guitar->>留言 2021年3月25日 (四) 07:42 (UTC)
单曲与歌曲是明显不同的概念,只要以单曲形式发行的作品,不论是一首歌几首歌,都应称为单曲。对于某些特殊的歌曲,比如我和你 (歌曲)之类,其制作背景不是以发行单曲为目的,或没有发行单曲,此时才合适用歌曲。->>Vocal&Guitar->>留言 2021年3月25日 (四) 07:42 (UTC)
@Ohtashinichiro:當條目只是一首歌的時候,討論其格式根本沒有意義,你只會介紹一首歌,也只有這麼一首歌可以介紹,這種情況下沒有迫切需要「 (單曲)」做消歧义。再來討論「篩選條件」,我反對以「制作背景不是以发行单曲为目的」及「没有发行单曲」作優先處理。首先「制作背景不是以发行单曲为目的」要怎麼辨別,Say So一開始沒打算打單、Eyes on Me以遊戲主題曲為目的創作,但這兩首最後都打單了。唱片公司的舉動是否屬於制作背景以发行单曲为目的?
二來,現在這年頭,你沒有發行公司也能自己發歌。以Spotify為例,只要你加入Spotify的創作計畫,哪怕你沒有公司也能發歌。但單曲是Spotify的最低計量單位,創作者上傳的作品是否等於发行单曲?(例如PewDiePi的歌曲Congratulations (PewDiePie、Roomie和Boyinaband歌曲))。 --無心*插柳*柳橙汁 2021年3月25日 (四) 11:51 (UTC)
如果您只介绍歌曲的背景、词曲、意涵、影响,我觉得您使用歌曲没有问题。但您也会介绍这首歌作为单曲发行的信息比如日期地区形式唱片公司,以及作为单曲发行后的反应比如销量评价奖项,这些都属于单曲而不是歌曲的范围。至于您的举例都是完完全全的商业作品,商业作品当然都是以发行为目的且结果也都是已发行,我前面的表述可能会引起您的误解,也希望您可以研究一下您的举例和《我和你 (歌曲)》的区别在哪,能有一个合适的表述。另外spotify好像已经结束了自行发歌[6]。->>Vocal&Guitar->>留言 2021年3月26日 (五) 00:19 (UTC)
@Ohtashinichiro:spotify结束自行发歌不等於整個計畫沒有發生過,對於以前參與計畫的歌該算?而Ohtashinichiro大你給出的這些條件,歌曲一樣可以使用,《家 (陳潔儀歌曲)》難道有出單曲他就活該倒楣只能是商业作品。我不能理解你一直提《我和你 (歌曲)》是想表達什麼,他們都是歌曲。不論有沒有出單曲、派台還是其他單曲形式,歌曲就是該用歌曲,沒有必要過度分類。 --無心*插柳*柳橙汁 2021年3月26日 (五) 04:20 (UTC)
单曲是“一碗饭”,歌曲是“碗里的饭”,您可能只想吃饭,我希望不要忽略这只碗。只是看起来您对这一点并不认同,那其他的讨论也没有意义了。->>Vocal&Guitar->>留言 2021年3月26日 (五) 05:01 (UTC)
很抱歉,我不能理解只在乎容器,而忽視它終究是飯的事實。關於單曲與歌曲的問題就看其他維基人的意思,再來評斷。 --無心*插柳*柳橙汁 2021年3月26日 (五) 05:44 (UTC)
  • "上次討論"的連結失效了。--Temp3600留言) 2021年3月17日 (三) 17:55 (UTC)
Temp3600"上次討論"的連結以補充。 --無心*插柳*柳橙汁 2021年3月17日 (三) 23:56 (UTC)

Wikipedia:命名常规 (音乐)1.0更新報告[编辑]

Ohtashinichiro和平至上LeehsiaoSanmosaTombus20032000百战天虫Kriz Ju生米一粒Pseudo ClassesKodokunaSmileEasterliesAT卡達YumetoSickManWP羊羊32521EdwardAlexanderCrowleyZhaoweizhi0325MoonLight3650HXXXXPunkhippieLouis0921geePeace 621WhykittyMoonshimmer93夜来南风起Fake12345TreasureBabe325Hijk910Jacklamf1d14Ericliu1912NaveradSoftyuSammypanTw drama感謝大家的意見回饋,自3/14以來,本指引更新下列內容,歡迎大家查閱。 --無心*插柳*柳橙汁 2021年3月25日 (四) 05:33 (UTC)

  1. 「古典音樂作品」敘述修正
  2. 「使用中文」內容增加
  3. 「外文規範」內容增加
  4. 「括號的使用」修改為「符號使用」,並增加「斜線」、「書名號」和「特殊符號」的說明與範例。
  5. 「消歧義」內容增加
  6. 「注釋」敘述修正
ShingkeiHikki李新阳CHih-See HsiePv163JoJo_appendLopullinenAnYiLinYel D'ohanTemp3600Bigbullfrog1996陳寅恪TenhumantenokPrince of EreborK.Y.K.Z.K.ArivgaoFredYYooApple vTfcheng5597Comrade JohnAdsa562Austin ZhangGracellleeShwangtianyuan星巴克女王金善賢老奋Lilychen1388Drippinpunch由於人數眾多,這邊分開ping相關討論用戶。 --無心*插柳*柳橙汁 2021年3月25日 (四) 05:42 (UTC)
  • 我本来就对“古典音乐作品”第一行“对序号是10(不含)以上的作品,‘号’字省略”有点疑虑,这样分类讨论,不利于条目名的统一性。[1]希望能交付社群讨论。另ping一下之前参与过相关讨论的@FoampositeIoksengAnakharsis: ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月25日 (四) 06:05 (UTC)
  • 我認為日文羅馬化可能需要詳細規定,例如shi或si到底要使用何者,《日語羅馬字》中有寫到三種羅馬化方式,看是要採用哪一種。 2021年3月25日 (四) 10:24 (UTC)
    我建議如果官方沒有給出羅馬字的話,全部統一用平文式羅馬字。SANMOSA 江南好,風景舊曾諳 2021年3月25日 (四) 10:27 (UTC)
    我也是這樣認為。 2021年3月25日 (四) 10:48 (UTC)
    @Pseudo ClassesSanmosa:以新增。 --無心*插柳*柳橙汁 2021年3月25日 (四) 11:05 (UTC)
@Milkypine:「對序號是10(不含)以上的作品,『號』字省略」是此類音樂作品的常用名稱的做法嗎?SANMOSA 江南好,風景舊曾諳 2021年3月26日 (五) 09:57 (UTC)
@Sanmosa:古典音樂的部分主要根據User:Anakharsis/沙盒#建立条目編寫,至於是否為此類音樂作品的常用名稱做法...這部分需要古典音樂的編輯來回答(技術上來講我會寫原聲帶但不等於我熟悉古典音樂)。 --無心*插柳*柳橙汁 2021年3月26日 (五) 12:41 (UTC)
@Milkypine:我看了一下應該是對現行做法的總結。然而,我也看過了來源一下,似乎即使號碼大過10,加「號」字還是比較常見。我建議基於常用名稱的原則,將『序號使用阿拉伯數字,前面有「第」字;作曲家名字放在半角括號內,括號之前有一個半角空格。對序號是10(不含)以上的作品,「號」字省略』的規則改為『序號使用阿拉伯數字,前面有「第」字,後面有「號」字;作曲家名字放在半角括號內,括號之前有一個半角空格』。SANMOSA 江南好,風景舊曾諳 2021年3月27日 (六) 05:28 (UTC)
有關「號」的問題,綜觀慣常一般音樂會場刊的處理,通常都沒有特意加上「號」的,但本人自最初編寫蕭士達高維契交響曲時,經觀察和有前人提醒過名稱上要加上「號」,所以才不論第1還是第15都有加上「號」,且也覺得沒有問題,至於「超過10就不用加號」的說法,倒沒有聽過,不過User:Sanmosa建議不論序號,統一採用「第X號○○○ (某某)」的寫法,個人表示認同和支持。-Foamposite留言) 2021年3月27日 (六) 07:40 (UTC)
@IoksengAnakharsis:兩位的看法如何? --無心*插柳*柳橙汁 2021年3月28日 (日) 03:29 (UTC)
  • 我不知道现在还可不可以为这个讨论作出贡献。我主要编辑古典音乐这方面,所以以下是我对于该方面的浅见:
1)我注意到大家关于“号”的讨论,我赞成“第”后面加“号”,不需要去管超过10什么的。我注意到很多的条目中超过10的也使用“号”,如:第11号钢琴奏鸣曲 (莫札特)第12号交响曲 (肖斯塔科维奇)第40号交响曲 (莫扎特)等。我不太懂为啥非要减少一个“号”。
2)哦,对了,維基百科:命名常規 (音樂)这里的降E大調弦樂五重奏(貝多芬作品)的括号好像用成了中文的()而非(),我觉得咱们可以着重的说一下我们的括号问题用的是英文的那种,我认为新手会喜欢犯这样的错误(比如我,哈哈哈哈)
3)关于调性的问题,我认为我们还应当注意对于音名和字母大小写的统一,如我们真的要写“降E大調弦樂五重奏 (贝多芬)”,我们需要着重指出到底是用“降E”还是“E♭ ”;亦或是“降e”还是“降E”。探讨这个问题很重要,因为在很多命名下面的条目内容出现不一致的情况,比如第3號交響曲 (貝多芬)中我们说“E♭大調第3號交響曲”,但是在第39號交響曲 (莫扎特)中,我们又说降E大調第39號交響曲。我的建议是我们应当使用“大写字母”以及“降”或“升”。
4)关于維基百科:命名常規 (音樂)这个地方的“如果該作品的名稱是獨一無二的,則作曲家名字也可以省略”,这个可能会有点争议,比如其中说到的大地之歌,这玩意儿可能指的是大地之歌 (电影)。我不是在这里杠呀,我是说类似这样的东西需要注意是否已经有不一样的体裁同样名字的东西已在维基百科中出现,比如查拉圖斯特拉如是說库勒沃,咱们需要加上查拉圖斯特拉如是說 (史特勞斯)库勒沃 (西贝柳斯);乃至于有些时候同属于音乐类的《传奇》,是西贝柳斯?还是维尼亚夫斯基?当然,我认为这个可以直接套用“作品在體裁內的序號+作品體裁+作...”的方式,只是需要稍加说明。我的建议是说明如果维基百科里已经有不同体裁但相同名字的条目则在新条目建立时的括号内加上作曲家名字,如果没有就无所谓了(自己看着办吧)。
5)注意到我们在古典音乐类编辑中有惯例但无有实质的关于“命名优先性”的规定(或者因为我是个新手没有注意到,哈~),我以我指的“优先性”举一个例子,我们是应该叫第6号交响曲 (柴可夫斯基)还是悲怆交响曲。我知道大家都很聪明,而且我个人感觉我们的惯例通常是用体裁加序號再加作曲家的方式,但是我认为需要在維基百科:命名常規 (音樂)对命名的优先性中做具体的说明,要不然!!!就会像某度那样出现憨憨的“悲怆交响曲”和“柴可夫斯基第六交响曲”那样的重复词条,我笑死了哈哈哈哈哈。

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

暫時先回應第5項,要知道很多標題音樂,都不是作曲家原先加上的,因此除非如佛漢·威廉士那種開宗明義講過不喜歡使用作品序號的,就應該予以尊重,不然的話,應採用「第5號交響曲 (貝多芬)」而非採用「命運交響曲」,「第1號交響曲 (馬勒)」而非「巨人/泰坦交響曲」,頂多是使用重定向處理暱稱。--Foamposite留言) 2021年4月2日 (五) 12:32 (UTC)
再回應第3項,正如我早前所講,如果是標題,那應使用「升C」、「降E」,因這不會涉及使用音樂符號模板的問題;至於內文中,如果是對應標題的,我會建議沿用「升C」、「降E」的寫法,但當牽涉到配器中的移調樂器(最常見,B單簧管),或者表示音樂中的音高時,個人就會覺得應該使用 {{music/xxx}} 的方式去表達。
至於第4點,我立時想到了早陣為拉赫曼尼諾夫的《死之島》開了條目,很明顯原來的畫作的名氣比起樂曲更大時,實在無法引用「獨一無二」的方式來處理,而音樂作品往往都是因其他著作、畫作而獲得靈感,這個概念無疑是限制了古典音樂作品能突破「獨一無二」的框架,除非好像《古雷之歌》,荀伯克選用了雅各生在世時未能完世的詩集內的作品,最終使音樂比原著更為人熟識,這樣的異例實在不多。
第1點早已表述,至於第2點也不過是技術錯失,修正一下便好了。--Foamposite留言) 2021年4月2日 (五) 23:04 (UTC)
我赞同你的说明,特别是对于第5项的说明。我认为完全可以纳入到命名的规则之中。感谢~-李新阳留言) 2021年4月3日 (六) 19:06 (UTC)
我原先倒是想一律不用号字。我在大陆,我看到的来源(包括中央音乐学院的本科招生简章、校外考级教材,中国音乐家协会的考级教材,人民音乐出版社花城出版社的初高中课本)只要是数字+体裁的,都没有号字。但是数字用的是汉字。难道这得按地区词处理? ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月28日 (日) 14:55 (UTC)
(~)補充:在花城出版社《音乐鉴赏》(2004.8第一版)第115页下方对莫扎特的介绍中出现了阿拉伯数字的写法:“《g小调第40交响曲《第41交响曲》(朱比特)” ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月28日 (日) 15:51 (UTC)
我理解羊羊说到的这个现象,不同地区对于曲目的命名确实存在差异。如中国爱乐乐团的曲目设置中,我们称“《古斯塔夫·马勒:第七交响曲》”,[2]而在国立台湾交响乐团的曲目设置中,我们称“《馬勒:D大調第一號交響曲》”。[3]当然这并不意味着大陆就一定不使用“号”,或台湾地区就一定使用“号”,比如国家大剧院就称呼“《贝多芬 C小调第五号交响曲,Op.67》”或[4]在“实践中”,维基百科古典音乐条目的命名中我们普遍使用“号”这个东西。虽然我个人觉得“号”不“号”的无可厚非,但我认为我们应当在维基百科中有一个统一的有共识的对于“号”的规定,我可能不会建议在这样的事情上按地区词处理,可能显得没有必要。(&)建議:我个人支持在命名时保留“号”这个东西,因为这似乎已经成了维基百科“没有特别规定的共识和实践”,且考虑到这个实践已经存在很长时间了,符合大家的写作习惯。我支持应当采用汉字表示具体的数字,如一、二等,而非使用阿拉伯数字。因为这个是对于大陆和台湾地区而言都通用的。--李新阳留言) 2021年3月28日 (日) 18:35 (UTC)
可也。不过我还是建议阿拉伯数字——第一百零三号交响曲 (海顿)实在难看-- ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月29日 (一) 05:18 (UTC)
而且可能得设重定向 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月29日 (一) 05:22 (UTC)
思来也是,而且也考虑到现在维基百科的大多数条目都是用阿拉伯数字的惯例的话。羊羊举得这个例子很好,一百零三号交响曲,哈哈哈哈哈哈;那么使用阿拉伯数字可以应付汉字所不能应付的情况,我认为可。感谢~--李新阳留言) 2021年4月3日 (六) 19:14 (UTC)
对于李新阳其它几点内容:
  1. 见上。
  2. “(贝多芬作品)”不在条目名称里,这个括号只是解释说明作用,没什么关系[5]。但是个人觉得这一条有点问题,可能有不止一个作曲家的降E大调弦乐五重奏序号不详、有争议或无可靠来源使用,建议改成:调性优先,若无须消歧义,作曲家名字可以省略。
  3. 调性的问题。我认为应该用汉字“升”和“降”。至于字母大小写,我觉得争议出在小调上。英维古典音乐专题的Guidelines有说,大意是D小调可以简写为d调,但不能写d小调这种缝合怪[6]然而我能看到的来源,(作品名还有行文)D小调和d小调都有,甚至感觉d小调更多。我觉得还是按中文习惯,大调大写,小调小写。
  4. 建议改成:如果该作品的名称是独一无二的,且无须消歧义,则作曲家名字也可以省略。
  5. 我觉得应该不是问题,第一条解决的就是通用情况。
以上。 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月29日 (一) 06:02 (UTC)
感谢羊羊对于关于大小调的叙述,我支持进行“大调大写,小调小写”的方式,合乎乐理,然后使用汉语表示升降号,以及新增关于“且无须消歧义”的条文。--李新阳留言) 2021年3月29日 (一) 08:11 (UTC)
我自己反而是沒看過「小調小寫」的處理。SANMOSA Σουέζ 2021年3月29日 (一) 09:01 (UTC)
那這樣D小調不就需要...。 --Loving You Is A Losing Game 2021年3月29日 (一) 13:55 (UTC)
严格意义上来说,在乐理的学习和考试中以及大多数的实践中,都应当使用“大调大写,小调小写”的原则,这样合乎规范也严谨一些。您提到的D小調是一个很好的且应该进行改正的例子。--李新阳留言) 2021年3月30日 (二) 05:36 (UTC)
我理解现在的许多音乐会,新闻或者乐评不强求或者不讲究这个,因为往往来说观众都更在意“大调”还是“小调”而非“大写”还是“小写”这样的“技术性问题”。我个人认为为了避免歧义,应当遵循“大调大写,小调小写”的原则。--李新阳留言) 2021年3月30日 (二) 05:43 (UTC)
同意,我在音樂系學習時,按西方慣常命名時,大調用大寫,小調用小寫是不成名做法,這個和樂理和聲學有關,當然用在普及化的層面來說,大小寫的意義不大,對此我覺得在維基內可以因着便利性而不執行大小寫的做法,至於「降號」和「升號」,由於真正的寫法和「#」及「b」有別,涉及要用音樂符號模版,我傾向都是用文字表述為佳。--Foamposite留言) 2021年4月2日 (五) 12:32 (UTC)
(!)意見:命名中几乎遇不到小调大小写的情况,不属于命名常规讨论范畴,建议拆分为新讨论。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年3月31日 (三) 06:08 (UTC)
进行拆分的话倒是没有任何问题,我主要是看到了“降E大調弦樂五重奏”这个玩意儿,认为应当讨论一下大小写的问题。我现在发现了一个新东西,就是这个夜曲Op. 9 (蕭邦)以及前奏曲Op.28, No. 15 (蕭邦),我们可能需要引入一个新的话题,即Op和No的问题。我建议翻译出来比较好,要不然看这很别扭。--李新阳留言) 2021年3月31日 (三) 06:59 (UTC)
夜曲 (肖邦第9号作品)前奏曲 (肖邦第28号作品第15首)太难看了……我觉得这些小问题还是不要讨论了吧,讨论是讨论不完的……你看看英维的音乐命名常规,古典音乐写了多长…… ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月1日 (四) 05:13 (UTC)
补了个签名 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月1日 (四) 15:26 (UTC)
好吧,为尽快了结,可以搞一个独立的拆分讨论大小调的问题。对于[[夜曲Op. 9 (蕭邦)]这种东西现在就暂时不做处理(吗)?(我倒是无所谓,我比较随意)。--李新阳留言) 2021年4月3日 (六) 18:58 (UTC)
「命名中几乎遇不到小调大小写的情况」,我不清楚古典音樂們有多少,但對於小調,我想這部分可以一起處理,尤其是Template:Circle of fifths不過這麼一搞,條目裡面有出現小調我可能都要修改了OTZ --Loving You Is A Losing Game 2021年3月31日 (三) 14:28 (UTC)
辛苦啦~--李新阳留言) 2021年4月3日 (六) 19:00 (UTC)

Wikipedia:命名常规 (音乐)2.0更新報告[编辑]

Ohtashinichiro和平至上LeehsiaoSanmosaTombus20032000百战天虫Kriz Ju生米一粒Pseudo ClassesKodokunaSmileEasterliesAT卡達YumetoSickManWP羊羊32521EdwardAlexanderCrowleyZhaoweizhi0325MoonLight3650HXXXXPunkhippieLouis0921geePeace 621WhykittyMoonshimmer93夜来南风起Fake12345TreasureBabe325Hijk910Jacklamf1d14Ericliu1912NaveradSoftyuSammypanTw drama感謝大家的意見回饋,這次根據上次1.0的討論修改古典音樂,並增加「 (單曲專輯)」的消歧義。歡迎大家查閱。 --Loving You Is A Losing Game 2021年4月10日 (六) 07:04 (UTC)

ShingkeiHikki李新阳CHih-See HsiePv163JoJo_appendLopullinenAnYiLinYel D'ohanTemp3600Bigbullfrog1996陳寅恪TenhumantenokPrince of EreborK.Y.K.Z.K.ArivgaoFredYYooApple vTfcheng5597Comrade JohnAdsa562Austin ZhangGracellleeShwangtianyuan星巴克女王金善賢老奋Lilychen1388DrippinpunchKulivLienwingyan由於人數眾多,這邊分開ping相關討論用戶。 --Loving You Is A Losing Game 2021年4月10日 (六) 07:06 (UTC)
括號一節舉的例子不是有全形字元(中文字)嗎?如果我沒理解錯誤的話,不應該是要用全形括號? 2021年4月10日 (六) 07:20 (UTC)
@Pseudo Classes:你的意思是說「中文是全形字元」嗎?如果不是的話,習慣 (超快感)姊姊 妳太美了 (Replay)這兩個例子都沒有全形字。 --Loving You Is A Losing Game 2021年4月10日 (六) 07:26 (UTC)
@Milkypine:是的,中文字理應也屬於全形字元,這樣寫會有歧義。 2021年4月10日 (六) 07:31 (UTC)
斜線一節也有這個問題。-- 2021年4月10日 (六) 07:34 (UTC)
@Pseudo Classes:已修改為「全形符號」避免歧義。 --Loving You Is A Losing Game 2021年4月10日 (六) 08:01 (UTC)
@Milkypine:感謝修正,另外我想請問關於斜線和括號有相關的共識嗎?不然我想再針對這個問題討論一次。 2021年4月10日 (六) 15:18 (UTC)
@Pseudo Classes姑且算吧,就算當初沒有共識,現在也可以有,我就不信我ping了快百位編輯沒人沒感覺。 --Loving You Is A Losing Game
已查閱,感謝貢獻。--SickManWP歡迎參與♥️邊緣人小組的活動·✏簽到發表於 2021年4月10日 (六) 08:25 (UTC)
  • 條目名稱須符合「大調大寫,小調小寫」,如“D大調”、“d小調”。

或是

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

例:降B大調升f小調

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

@羊羊32521:页面第一个字雖然必须大写,但d小調和iPhone一樣,都在其(樂理)領域屬於特定詞語,因此使用小血沒有問題。 --Loving You Is A Losing Game 2021年4月10日 (六) 16:50 (UTC)
好 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月11日 (日) 02:26 (UTC)

参考資料

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

(重提)Wikipedia:共识#提案討論及公示時間的執行力度[编辑]

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

現行條文

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

提議條文

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

参考資料

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

以上。SANMOSA 江南好,風景舊曾諳 2021年3月14日 (日) 15:31 (UTC)

主要影響:
  1. 不對提案進行實則性點評的支持意見不造成重算7日。
  2. 與提案本身無關的意見不造成重算7日。
  3. 將浮動的時間範圍「1個月」界定為固定的時間範圍「28日」。
  4. 容許公示在有必要時可長於7日。
以上。SANMOSA 江南好,風景舊曾諳 2021年3月14日 (日) 15:36 (UTC)
(?)疑問
  1. 原條文有「如果在互助客栈中被提出的提案」一句,在新條文要刪去嗎?
  2. 參閱Wikipedia:互助客栈/条目探讨#春晚及春晚 (消歧義),這種在Wikipedia:互助客栈/条目探讨的提案是否需要遵守WP:7DAYS?或是要將WP:7DAYS限定在Wikipedia:互助客栈/方针?--CaryCheng留言) 2021年3月15日 (一) 02:41 (UTC)
@CaryCheng:(1)漏留意,已補回。(2)理論上要遵從。SANMOSA 江南好,風景舊曾諳 2021年3月15日 (一) 05:53 (UTC)
@CaryCheng:就(2)作補充:我是説如果決定要進行公示的話,理論上要遵從WP:7DAYS,但是如果不涉及修改方針指引或修改高風險模板的話,一般性的爭議解決討論好像是不用進行公示的,基本上爭議解決了就可以直接關。SANMOSA 江南好,風景舊曾諳 2021年3月15日 (一) 08:45 (UTC)
(?)疑問:這個提案改過很多次,而且30天和28天就差兩天,有必要改來改去嗎?而且一年就只有二月會有28天,大家都會以30天為一個月的概念,這種修改有甚麼意義呢?--蟲蟲飛♡♡→♡℃留言 2021年3月15日 (一) 03:52 (UTC)
1年有7個月是31日,何來「以30天為一個月的概念」?再者,1年12個月的日數不同,假設我在2月1日提案,我最遲可以在28日後公示,但假設我在3月1日提案,我最遲在31日後才能公示(4月同理,最遲在30日後才能公示),這對於在有30日/31日的月份提案的人非常不公平,但如果統一為30日,這會損害在2月提案者的公平性,因為30日的時間必定比2月長,這樣在2月提案的人就會要在多於一個月的時間後才能公示。因此,最公平的方式為統一成28日。SANMOSA 江南好,風景舊曾諳 2021年3月15日 (一) 05:53 (UTC)
(?)疑問:大致同意,而且也會看到這裡用雪球快速公示,好像也沒完全照規定走。但是這裡有些疑問要問一下,如何界定「已取得共識」、「合理異議」,「合理意見」?合理異議、意見會不會變成兩集團互斥對方不合理。只有一人提問,無人贊成、反對,算不算已取得共識,然後可以公示?這些提案人可以一併考慮,把規定寫更好一些。--2001:B042:1:A9ED:F58C:12D4:4C7B:B776留言) 2021年3月15日 (一) 06:32 (UTC)
(1)沒人抓的話其實是沒人會遵守這規定。(2)以前的人進行公示的時候都是説“現公示7日,無合理異議者即作通過”,跟以前的做法處理。(3)提案與現行辦法對於“只有一人提問,無人贊成、反對”的提案的態度是原則上可以公示,這當然會產生一些奇怪的現象(當然如果提案人能夠好好處理提問的話,我倒是覺得可以照樣公示通過),先前討論也談論過,但沒人管。SANMOSA 江南好,風景舊曾諳 2021年3月15日 (一) 07:54 (UTC)
回答的很完整。不縮小「無新留言」範圍,結果時間等太久,沒人抓大家就不走規定。不討論「已達成共識」定義,結果「一人提問,無人贊成、反對」,反而7日後就可以公示。這是不見得會有問題,但又有一些奇特的現象。--2001:B042:1:ABD5:F58C:12D4:4C7B:B776留言) 2021年3月15日 (一) 08:27 (UTC)
所以有時候我會抓一下7日的計算(雖然我自己也不滿現在這規定)。如果“只有一人提問,無人贊成、反對”的提案出現的話,提案人能不能夠好好處理提問是一個重點,如果不能的話,理論上可以抓「已取得共識」一條來說有程序性問題。SANMOSA 江南好,風景舊曾諳 2021年3月15日 (一) 08:42 (UTC)
(-)反对:重看了一下,註腳很有問題,而且只會增加爭議,應刪去。--蟲蟲飛♡♡→♡℃留言 2021年3月15日 (一) 06:41 (UTC)
不同意。這是修訂提案的主要目的之一。之前的討論的主流意見都認同不應該使所有意見都能導致重算7日(我個人比較看重的是DrizzleD的意見)。我邀請一下之前參與過討論的@KirkLUDrizzleDBureibuNekoUjuiUjuMandanFire-and-Ice來好了。SANMOSA 江南好,風景舊曾諳 2021年3月15日 (一) 07:49 (UTC)
不是说增加争议就不好。举个简单例子,根据中华人民共和国刑法,故意杀人的,处死刑、无期徒刑或者十年以上有期徒刑;情节较轻的,处三年以上十年以下有期徒刑,显然在不少案件中具体判罚轻重会有“争议”,但为什么不干脆故意杀人的都处死刑呢?因为不同的案件真的不一样,不能统一判罚。这里类似,单纯支持也好,给建议也好,反对也好,无关意见也好,对共识形成的作用完全不同,却都能导致重算7日,这就背离了WP:7DAYS帮助确认共识的初衷。--DrizzleD (按此给我留言) 2021年3月15日 (一) 09:41 (UTC)
  • (+)支持:这四点都没什么问题。关于第一点,先前討論中已有不少论据,不再赘述(但愿)。简而言之,在没有其他意见的情况下,支持的人越多,提案越晚被公示,这是说不通的。--DrizzleD (按此给我留言) 2021年3月15日 (一) 09:46 (UTC)
(?)異議:您誤解了WP:7DAYS的初衷,當時AT就是為了解決在討論不足的情況下,用戶火速公示,然後強行通過提案的問題。原先是要30天後才公示,後來才七天後沒有留言公示。七天算是合理時間,沒必要再縮短,否則又會回到以前火速公示,強行通過提案的問題,然後爭議不斷,問題多多。而且現在WP:7DAYS未見有甚麼問題,沒必要再放寛。--蟲蟲飛♡♡→♡℃留言 2021年3月15日 (一) 13:12 (UTC)
不不不,是您误解了我的意思,我说它帮助确认共识,意思是它告诉我们什么时候算是确认了共识,不是说它帮助加速通过提案。然后:1. 七天算是合理时间,没必要再缩短,我同意,但这个修正案完全没说要缩短七天这个时间,此说法和此修正案不相关 不相关。2. 又会回到以前火速公示,强行通过提案的问题,当然不,留言支持者越多,说明通过提案越不强行,而不是相反。 3. 而且现在WP:7DAYS未见有什么问题,这个我现在不太活跃确实不太清楚,但Sanmosa似乎能够确认如此,@Sanmosa可以来说说。--DrizzleD (按此给我留言) 2021年3月15日 (一) 13:47 (UTC)
(3)現成的問題SANMOSA 江南好,風景舊曾諳 2021年3月16日 (二) 05:53 (UTC)
(※)注意:請看一下這個提案,有一大堆支持,也已經討論了一個月,還是有人反對,當時也有人催快點公示,也有朋友對說我要快公示,怕夜長夢多,會出現(-)反对,但提案的目的是要尋求共識,而不是快快通過,然後出現爭議,因此急於通過是不必要的,有共識的提案也不怕多放幾天。--蟲蟲飛♡♡→♡℃留言 2021年3月16日 (二) 06:13 (UTC)
你對互助客棧討論的想法完全違背進行互助客棧討論應有的健康心態。SANMOSA 江南好,風景舊曾諳 2021年3月16日 (二) 06:58 (UTC)
@蟲蟲飛:不吸烟也可能患肺癌,这不代表我们不用去倡导戒烟,关键是可能性。类似地,同样是暂时没有反对意见,一个有许多人支持的提案和一个没人理的提案,哪一个有潜在问题的可能性更大?这是不言自明的。
要解决所谓“已经讨论了一个月,还是有人反对”的问题,相关的方案是延长WP:7DAYS中7天或者是1个月的限制(当然可能会有一些别的问题),但这与本案无关。本案的要求是赞成或不相关的意见不影响时间(不管是7天还是什么其他时间)的重算。--DrizzleD (按此给我留言) 2021年3月17日 (三) 02:13 (UTC)
  • 提案討論就不應存在不相關的意見,而且有時甚麼如何定義「不相關」也有爭議,因此我覺得AT現行版本較佳,沒必要改為一個具爭議性的版本。--蟲蟲飛♡♡→♡℃留言 2021年3月17日 (三) 02:40 (UTC)
然而方針指引不能阻止任何用戶發表不相關的意見。SANMOSA 江南好,風景舊曾諳 2021年3月17日 (三) 05:43 (UTC)
如何定義「不相關」?誰去決定?雙方也可以互相指責對方的留言「不相關」,為甚麼要令提案增加不必要的爭議?AT現行版本是最好的,「七天沒留言」是客觀標準,沒有爭議空間。--蟲蟲飛♡♡→♡℃留言 2021年3月17日 (三) 12:12 (UTC)
(1)依據「共識應當考慮到所有正當合理的意見」此條方針來定義。(2)最極端的情況就找行政員,天仍然不會因此塌下來。(3)極端嚴格的「7天沒留言」是客觀標準沒錯,然而違反常識、慣性、正常討論生態和「共識應當考慮到所有正當合理的意見」此條方針。SANMOSA 江南好,風景舊曾諳 2021年3月17日 (三) 12:43 (UTC)
所以,這種提案還是,被改完的7days攔下吧?-- Sunny00217  2021年3月22日 (一) 16:25 (UTC)
从现存留言上来看,应该会,因为相邻两条有说理的评论之间均小于7天。当然,改了WP:7Days之后同时可能会促使反对的人更早留言,这就是另一回事了。--DrizzleD (按此给我留言) 2021年3月28日 (日) 06:27 (UTC)
@Sunny00217SANMOSA 江南好,風景舊曾諳 2021年3月16日 (二) 05:56 (UTC)
(-)反对:啥叫合理,啥叫不合理?誰有權判定?個中操作空間太大,不得不反對。芄蘭留言) 2021年3月15日 (一) 13:22 (UTC)
啥叫曾在可靠来源中发表过的重要观点,啥叫不重要?谁有权判定?
啥叫恰当地改进或维护维基百科,啥叫不恰当?谁有权判定?
我们能收录可靠来源中的所有观点吗?我们能废除WP:5P5去墨守成规吗?不能。这种操作空间不是洪水猛兽,它是必要的,也是维基百科时时刻刻都在使用的东西
当然,要是操作规范能写得更细、更准确,那更好,就像WP:WEIGHT较详细叙述了第一个问题。可假设还没人去写WP:WEIGHT的时候,我们订立原则的时候同样应该加上“重要”两个字,因为这就是应该的,而不是去害怕什么“操作空间”。--DrizzleD (按此给我留言) 2021年3月15日 (一) 14:14 (UTC)
提案人有邀请讨论,我稍微简单说一下自己的浅见:
  1. 类似于“最后一天有编辑补了个‘支持’,结果导致要重新计算公示前的无留言时间”的情况客观存在;
  2. 个人是支持上例的这种问题能够更灵活化的处理(毕竟,表达一下支持,甚或——更宽泛一点——由于方针通过、问题解决的喜悦在讨论串下面开了个适当的玩笑,都不是什么不合理的事情;让这种表达起到延长公示前时间的效果,并非方针的本意,也一定程度上压抑了这种合理表达的机会——毕竟既然赞成提案,谁也不希望自己表达的支持反而造成了拖延的反效果);
  3. 我能理解反对此种灵活化处理的编辑有种种疑虑,此种情况下不改变现有方针我觉得也是可以理解、认同;
  4. 但即使方针不变,只要翻看存档,就会发现此种灵活化处理在往例中比比皆是,在这些案例中大家某种程度上用一种“默示共识(或称沉默共识,或称通过不提出异议来支持)”的方式使得灵活化缩短时程得以实现;
  5. 也因此,如3,方针改不改在我看来也许真的问题不大(如果大家真的不期待太明确地以规则确认上述惯例,或至少有些编辑还对此存在很大疑虑,如3,我个人觉得也是能一定程度理解),只是希望即使不改方针,至少这种实践中自然而然的习惯不被刻意地挑战,只要大家觉得适当的情况,就可以稍微灵活一点。事实上,我觉得这也最大程度体现出维基的精神。
以上。--Kirk★ # 2021年3月15日 (一) 17:02 (UTC)
  • 您是忽略了修訂版本中爭議性的問題,因為如何定義「不相關」有時也有很大爭議,否則之後提案又出現是否合法公示的問題,以前已經出現過很多次公示爭議,不應加一個具爭議性的註腳。我覺得AT現行版較佳,沒有修改的必要。--蟲蟲飛♡♡→♡℃留言 2021年3月17日 (三) 02:45 (UTC)
不如此修訂的話,會對互助客棧的討論生態造成嚴重扭曲。SANMOSA 江南好,風景舊曾諳 2021年3月17日 (三) 05:43 (UTC)
「討論被扭曲」是您說的,不是事實。客棧的提案不是為了收集支持,而是看看有沒有(-)反对,因為提案如果沒有反對,公示後就可以通過,因此公示的過程就是要令提案收集更多的意見,而這七天已經是下限,沒必要再縮減。--蟲蟲飛♡♡→♡℃留言 2021年3月17日 (三) 12:08 (UTC)
DrizzleD的1和2已經駁斥了你上面聲稱的東西(這個修正案完全沒說要縮短七天這個時間;留言支持者越多,說明通過提案越不強行,而不是相反)。SANMOSA 江南好,風景舊曾諳 2021年3月17日 (三) 12:14 (UTC)
那也要看回應的理據是否成立,不是回應了就算。我在上面還沒看到有任何理據是成立。--蟲蟲飛♡♡→♡℃留言 2021年3月17日 (三) 12:21 (UTC)
我真誠相信這是因為你中文理解能力有問題的緣故。換作任何其他一個人,他們都必定能夠理解提案的原因,並認為其合理。SANMOSA 江南好,風景舊曾諳 2021年3月17日 (三) 12:43 (UTC)
您請保持禮儀及文明﹗也請不要訴諸人身﹗--蟲蟲飛♡♡→♡℃留言 2021年3月17日 (三) 12:51 (UTC)
没有对“不修改”、“現行版較佳”的观点表示反对。核心是认为可以没有明示规定但要尊重实操中的默契。(比如,规则上尽可以挑战Wikipedia:互助客栈/方针/存档/2021年3月#修订R3适用情形五的公示[毕竟严格意义上他远没有7天],但缺乏意义,只会把程序性修订也拖得冗长。于我个人而言,如果有挑战,我一定会尊重这种挑战,因为方针如此,效果也不过是拖到下个月再公示。但缺乏意义。)--Kirk★ # 2021年3月17日 (三) 13:36 (UTC)
不肯定您記得不記得,之前就試過有提案因為公示沒有嚴格依從7days去進行,結果即使提案通過了多天,仍然引發了社羣對提案的有效性的質疑。請注意方針修訂是要面對整個社羣,而不是幾個討論的人同意就可以繞過方針。而且方針指引的有效性不是一時的,可以在幾年後,十幾年後,用戶翻閱存檔時,也可以再次質疑提案的有效性。此外,如果提案是有共識,就不要心急通過,也不用怕多放幾天會有反對。--蟲蟲飛♡♡→♡℃留言 2021年3月17日 (三) 13:45 (UTC)
這是因為此規則存在。假設此規則不存在,該公示理論上是完全沒問題的。極端嚴格的「7天沒留言」規則會帶來遊戲規則的可操作性。SANMOSA 江南好,風景舊曾諳 2021年3月18日 (四) 05:47 (UTC)
整理一下這裡看到的一些東西喔。WP:CONLIMITED說方針與指引的重大修改一定要先充分討論,但是小修改可以直接編輯,然後寫編輯摘要,謹慎一些就到客棧開話題知會一下,沒人回退就定了,有人反對再走程序,不過現在不知道方針小修改還能不能這樣。所以現在這個WP:7DAYS好像就是要讓人在重大修改,需要經過公示的話,希望能放上一個月,7天沒新留言會不會是當時支持方的妥協,所以現在他們不想在縮小新留言範圍,因為精神上他們認為至少放一個月比較好。--2001:B042:1:A908:F58C:12D4:4C7B:B776留言) 2021年3月18日 (四) 04:40 (UTC)
  • 现在7days的实际执行情况也不是很好。一些提案会根据SNOW和IAR缩短公示时间,一些提案会在数日无新留言时直接进入公示(并加长公示时间)。 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月18日 (四) 15:23 (UTC)
    也是啦,這個可以在觀察,一個規定常常會被SNOW、IAR、無視,是可以檢討一下規定。以後大家真的覺得「至少放一個月的精神」真的太長的話,看看能不能不要管7天新留言,全部改成至少放14天又取得共識才能公示,然後公示至少要放7天。這樣的14+7規定也不比人事任免、榮譽票選短了,等於提案至少有放21天的知會、反對、討論時間了,然後難聚共識的大提案一定還會在更長。--2001:B042:1:A5B3:7CCD:E884:C570:5D6A留言) 2021年3月19日 (五) 03:33 (UTC)
IAR不能亂用,只有在現行規則阻礙您維護維基,才可以用,而且要準備受到社羣的質疑,提案多討論幾天,有利於收集更多意見,因此不適宜引用IAR。此外,不依7DAYS會引發很多爭議,之前就試過有提案因為公示沒有嚴格依從7days去進行,提前公示了,結果即使提案通過了多天,仍然引發了社羣對提案的有效性的質疑。--蟲蟲飛♡♡→♡℃留言 2021年3月19日 (五) 06:35 (UTC)
這IAR連其他管理員自己也有用到,那次我就懶得抓7日了,結果就直接過了。SANMOSA 江南好,風景舊曾諳 2021年3月19日 (五) 09:28 (UTC)
其他用戶怎樣做,我不評論,但IAR是不能亂用。而且我覺得現行方針較佳,沒必要修改,而且提案也帶出了新的爭議。--蟲蟲飛♡♡→♡℃留言 2021年3月20日 (六) 08:41 (UTC)
正是因为不能一直IAR下去,所以才要改规定啊。--DrizzleD (按此给我留言) 2021年3月21日 (日) 05:21 (UTC)
剩下两点。1.没必要 不是只有“必要”的事我们才做,有益于维基百科就可以了。2.新的争议 争议不是个天生的坏东西,当区分有益的时候,有争议也要区分。--DrizzleD (按此给我留言) 2021年3月21日 (日) 05:36 (UTC)
@蟲蟲飛:既然這都不能IAR了那IAR存在的意思是?然後濫用IAR的您也可以送一張反對票讓它重寫公示,真的能起爭議的還是能被7DAYS框住的。-- Sunny00217  2021年3月22日 (一) 16:32 (UTC)
  • IAR是用於緊急情況,例如管理員失控,刪去首頁,其他管理員可以不用drv,直接還原;或者管理員失控狂封人,其他管理員可以直接解封及封了失控管理員等緊急情況。相反,如果可以任意用,方針指引也沒用,人人都可以引用IAR。--蟲蟲飛♡♡→♡℃留言 2021年3月22日 (一) 22:33 (UTC)
    从来没有说法说IAR只能用于紧急情况,只要忽略的是妨碍你恰当地改进或维护维基百科的规则就可以了。--DrizzleD (按此给我留言) 2021年3月28日 (日) 06:39 (UTC)
  • (?)異議:方針修訂屬於重大提案,如果出現任何爭議都會令提案的合法性受到質疑,所以我覺得AT現行版本較佳,修訂版本不但沒有解決問題,而且帶出了新的問題。--蟲蟲飛♡♡→♡℃留言 2021年3月21日 (日) 06:17 (UTC)
增加爭議是有益的[來源請求]-- Sunny00217  2021年3月22日 (一) 16:34 (UTC)
论据已经写在上面(并已链接到)了。WP空间内容不是条目,来源不一定有必要,不然讨论没办法进行。--DrizzleD (按此给我留言) 2021年3月28日 (日) 06:43 (UTC)

調適案1[编辑]

現行條文

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

提議條文

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

参考資料

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

我還是想做到一些東西,退而求其次一下好了。SANMOSA 江南好,風景舊曾諳 2021年3月25日 (四) 08:03 (UTC)

主要影響:
  1. 不對提案進行任何點評的支持或中立意見不造成重算7日。
  2. 與提案本身無關的意見不造成重算7日,而意見是否與提案有關根據《討論頁指引》的規定界定。
  3. 將浮動的時間範圍「1個月」界定為固定的時間範圍「28日」。(依舊)
  4. 容許公示在有必要時可長於7日。(依舊)
以上。SANMOSA 江南好,風景舊曾諳 2021年3月25日 (四) 08:09 (UTC)
(-)反对:理由同上,我還是覺得AT現行版本較佳,而且提案不但沒有解決問題,而且註腳部分帶出更多的公示爭議。--蟲蟲飛♡♡→♡℃留言 2021年3月26日 (五) 13:31 (UTC)
「不對提案進行任何點評的支持或中立意見」是很容易看出來的事情,多一句話就已經是「點評」了,非常明確,怎麼可能「帶出更多的公示爭議」?《討論頁指引》的規定也應該很清楚明白吧,難道說《討論頁指引》也是形同虛設的?將浮動的時間範圍界定為固定的時間範圍也是明確指引的處理。修訂容許公示時間可長於7日,但沒容許可短於7日,因此公示時間上也不可能產生爭議。綜以上,我完全不認同調適案1「帶出更多的公示爭議」。SANMOSA 江南好,風景舊曾諳 2021年3月26日 (五) 13:39 (UTC)
現在方針修改頻繁,AT版七天已經算是很合理的時間,頻繁的方針修訂中,讓社群有足夠時間去消化,及讓提案有足夠時間收集更多意見是必須的。--蟲蟲飛♡♡→♡℃留言 2021年3月26日 (五) 13:47 (UTC)
頻繁的方針修訂正是因為社羣有迫切的需求,如果社羣不理解方針修訂的內容,理當向提案人發問(這樣做無論是在原始提案下,抑或在調適案1下,都仍然會造成重算7日),我不明白社羣怎麼在遇到看不明白的事情都不會發問。一味壓抑社羣的迫切需求對社羣而言並不健康,我僅是希望將equilibrium position稍稍推回到提案人一邊一些而已。SANMOSA 江南好,風景舊曾諳 2021年3月26日 (五) 14:07 (UTC)
像下方#交通關注度指引修訂這樣的方針修訂,我是不見得需要多長的時間來「消化」。需要較長的時間來「消化」可能是像下方#分案1這樣的方針修訂,那為何不像MINQI這樣去發問?這可能比自己自行「消化」提案內容來得更有效率,使自己更快清楚明白提案內容。SANMOSA 江南好,風景舊曾諳 2021年3月26日 (五) 14:11 (UTC)
您搞錯了兩者因果關係,正因為修訂頻繁,提案更不應急於公示,應該收集更多意見,而不是火速公示,強行通過,然後有些用戶來不及表達意見,結果爭議不斷。--蟲蟲飛♡♡→♡℃留言 2021年3月26日 (五) 14:14 (UTC)
不,方針指引修訂頻繁是社羣的迫切需求的結果。現行條文只是在無視社羣實際存在的迫切需求,並將之強行壓抑。社羣的迫切需求是方針指引修訂頻繁的產出來源,應當做的是滿足需求,而非壓抑需求。再者,現實上方針指引修訂頻繁不可能等到所有人發表了意見才能處理,否則這就屬於遊戲共識形成程序的情形。SANMOSA 江南好,風景舊曾諳 2021年3月27日 (六) 10:36 (UTC)
@Sanmosa:不能认可方针的快速频繁修订(及提案和公示)。方针应该是总结归纳长久的共识,仅在争议严重时依充分讨论规定妥协方案(如COVID-19命名)。将未成熟的方针及公示作为约束或指导后续编辑的手段是不正确的,WP:BURO:“不是盲目跟随默认的方针和程序。要避免编写过分冗长的指示。”。应更多以讨论确认意见、指引,而非编立方针来不必要的规约。设立规则来制止他人反而会有GAME之嫌。--YFdyh000留言) 2021年3月27日 (六) 12:16 (UTC)
既然社羣存在如此的迫切需求,那相關的規約自然是必要的。必要性取決於需求。SANMOSA 江南好,風景舊曾諳 2021年3月27日 (六) 13:13 (UTC)
「迫切需求」是您的意見,不是社羣,方針屬於重大提案,應該讓社羣有足夠時間消化及表達意見,千萬不要心急,有共識的提案就不用怕多放幾天有(-)反对,而且急於通過,火速公示,然後爭議不斷,那通過的提案也不是反映共識。--蟲蟲飛♡♡→♡℃留言 2021年3月28日 (日) 04:54 (UTC)
方针快速频繁修订是个问题,但如果真的要修订,这里的关注点是,单纯支持之意见不该导致重算。--DrizzleD (按此给我留言) 2021年3月28日 (日) 06:53 (UTC)
要说多少遍本提案和“七天”没有任何关系。实话说,您要是觉得时间短,延长到十天我也没意见,但“不对提案进行任何点评的支持或中立意见”能导致重算,究竟合理吗?--DrizzleD (按此给我留言) 2021年3月28日 (日) 06:50 (UTC)
  • 您說沒有評點就提前公示,為甚麼要以不同名目去提前公示呢?請瞭解AT版當時訂的版本就是為了解決社羣急於公示而帶出的爭議問題,為甚麼不能讓提案多收集一些意見呢?而且要注意不是每個用戶都很活躍,讓提案多放一些時才能收集更多意見,因此我覺得AT現行版本較佳。--蟲蟲飛♡♡→♡℃留言 2021年3月28日 (日) 06:58 (UTC)
    我明白您的意思。您可以看看下面的方案如何。或许看了之后您可以更了解我的想法。--DrizzleD (按此给我留言) 2021年3月28日 (日) 07:06 (UTC)
说到这个,为了拯救陷入同义反复的讨论,我决定提出一个新想法,看看能不能抛砖引玉。改成:
為確保所有使用者有充足的時間發表意見及得悉改動,在互助客栈中被提出的提案若在10日內無新留言[1],又或討論已持續28日以上的情況下,只要討論取得共識,即可公示,公示為期至少7日。公示期間若無異議,作通過論,若有新合理意見,應經協商解決問題。存檔後如果要重新提出公示的話,應同時補回相關討論連結,以便社群查閱。

参考資料

  1. ^ 不對提案進行任何點評的支持或中立意見,以及與提案本身無關的意見,皆不視作此條文所指的「新留言」。
即额外把7日改成10日,这下新提案的讨论时间应该不会比旧的情况少了。“应该让社群有足够时间消化及表达意见,千万不要心急,有共识的提案就不用怕多放几天有(-)反对,而且急于通过,火速公示,然后争议不断,那通过的提案也不是反映共识”,那多几天总没问题吧。--DrizzleD (按此给我留言) 2021年3月28日 (日) 07:01 (UTC)
  • 我還是覺得註腳部分有爭議,因為「有沒有點評」不同人都有可能有不同的解讀,而且客棧遇到激烈爭議時,這個註腳只會帶出更多爭議,而且本站社羣還沒有達到英維的客觀與理性,無視反對意見,指鹿為馬等奇怪的事常有,因此我還是(-)反对注腳部分。反而,Sanmosa想爭取28天,減兩天,這個我沒有異議。--蟲蟲飛♡♡→♡℃留言 2021年3月28日 (日) 07:19 (UTC)
    好,Sanmosa想争取28天,减两天,这个我没有异议,看来我们已经达成了第一个共识,讨论是有成果的了。
    下一个点是,您是否觉得不对提案进行任何点评的支持意见不导致重算合理。如果是的话,那我们就达成了下一个共识,只需要关心有没有办法解决“有没有点评”不同人都有可能有不同的解读这个问题就可以了。--DrizzleD (按此给我留言) 2021年3月28日 (日) 07:51 (UTC)
「不對提案進行任何點評的支持或中立意見不造成重算7日」這句話的意思我要解釋一下,就是只寫了「支持」、「中立」、「沒意見」、「不反對」之類的,我認為定義已經足夠明確。我不要求只有「實則性點評」才能導致重算7日已經是很大的讓步了。SANMOSA ······ 2021年3月28日 (日) 23:51 (UTC)
  • 這是不必要,而且這是您的理解,實際的爭議時,不同人都可能有不同的解讀,我還是覺得AT現行版本較佳,即「七天沒有留言」就可以公示,完全沒有爭議。但您以不同名目去縮短公示期限,這是不必要,而且容易造成爭議。提案的公示一旦有爭議,提案的合法性就會受到質疑,過去是有先例的。--蟲蟲飛♡♡→♡℃留言 2021年3月29日 (一) 05:05 (UTC)
    • 问题在于,现在有些人看到讨论过了几天,避免重算也不敢支持也不敢中立,我觉得反而不好收集社群意见。 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月29日 (一) 06:07 (UTC)
  • 您有所不知,客棧的提案不是收集支持或中立,而是看看有沒有(-)反对,因為提案放出來,七天完全沒有留言,已經可以公示,公示後,沒異議就通過,其他維基也是一樣,因此提案的反對意見比支持的意見重要。而且,「七天沒留言」在維基可視為默認共識,見WP:TALKDONTREVERT:「假如編者已停止在討論頁內回覆相關討論,便可以假定共識已經形成。」--蟲蟲飛♡♡→♡℃留言 2021年3月29日 (一) 06:30 (UTC)
    如果相關支持意見或中立意見裏面有其他建設性的提議的話,那些意見和反對意見是同等重要的,然而現行條文有可能阻礙相關附有有其他建設性的提議的話支持意見或中立意見的表達。SANMOSA ······ 2021年3月29日 (一) 06:36 (UTC)
所以我希望最後的共識能確立該條條文以我上方的解讀為準。SANMOSA ······ 2021年3月29日 (一) 06:36 (UTC)
  • 還是回到那個問題,甚麼叫“有建設性的意見”?標準誰定?爭議時互相指責對方的意見“無建設性”,結果把本來不應有的公示爭議,變得非常有爭議。蟲蟲飛♡♡→♡℃留言 2021年3月29日 (一) 06:53 (UTC)
我請你重看我的調適案1,我的調適案1完全無提及過「有建設性的意見」,我不知道你是從哪裏看到的,還是你不小心看到了甚麼一般人看不到的東西。如果你是從我上面的留言看到的話,那我只能夠說你真的沒有一般人應有閱讀中文的能力,我說的是現行的條文讓人不願意留下附有其他建設性的提議的支持意見或中立意見,而不是直接阻止,具阻止性質的效果有時候並不需要直接言明的條文達到;至於這事情會產生的問題,那就是只有反對意見得以顯現,使實際的意見比例和表面上所看到的意見的比例不符。SANMOSA Σουέζ 2021年3月29日 (一) 10:00 (UTC)
  • 請重看您於「2021年3月29日 (一) 06:36 (UTC)」的留言。而且「進行任何點評」也是換了不同的名目,性質也是一樣,這些都是不必要的,AT現行版本已經很清晰,沒有修改的必要。--蟲蟲飛♡♡→♡℃留言 2021年3月29日 (一) 14:02 (UTC)
完全不一樣,這制限條件已經完全不同了。我真的只能認為你真的沒有一般人應有閱讀中文的能力,這分明已經是兩種完全不同的情況。SANMOSA Σουέζ 2021年3月31日 (三) 07:49 (UTC)
請不要人身攻擊﹗您是換了不同名目去縮短公示期,這是與AT版解決火速公示的提案原意不合。而且我反而我看到您平時公示時一有異議就重新公示,我覺這個操作很不錯,所以建議加一條「公示期間如有異議應重新公示」。--蟲蟲飛♡♡→♡℃留言 2021年3月31日 (三) 10:35 (UTC)
「縮短公示期」從不存在,不論是原案抑或調適案也如是。我認為所有用戶均有重新公示的意識,而且重新公示的操作可以依規進行,無須特別規範。SANMOSA Σουέζ 2021年4月1日 (四) 00:51 (UTC)
(-)反对,讚同蟲飛飛的意見。AT的版本已經很清晰。Walter Grassroot留言) 2021年4月1日 (四) 01:34 (UTC)
(咦?)SANMOSA Σουέζ 2021年4月2日 (五) 08:43 (UTC)
提案目的并非让方针更“清晰”。--DrizzleD (按此给我留言) 2021年4月4日 (日) 16:24 (UTC)
(-)反对:在此种情况下应依据常识进行判断,而不是拘泥于方针细节之中。--Yining Chen留言|签名) 2021年4月4日 (日) 12:05 (UTC)
就在WP:UCS这一页的图表:是否是规则错了?是→改变规则。--DrizzleD (按此给我留言) 2021年4月4日 (日) 16:29 (UTC)

臺灣原住民族人條目命名(第二次)[编辑]

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

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

@YumetoLt2818克勞棣Y0529543SANMOSA 江南好,風景舊曾諳 2021年3月22日 (一) 01:00 (UTC)
这规定并不能解决究竟是命名为“張惠妹”还是“古歷來·阿密特”的问题。若针对上次事件的话,我觉得重点在于强调人物命名须用汉字。--Lt2818留言) 2021年3月22日 (一) 03:33 (UTC)
@Lt2818:(1)應該是能解決的。張惠妹的戶籍是用甚麼名字登記的?(我看到一些台灣政府網站把她的名字繼續寫成「張惠妹」,臺灣原住民族人名僅為括注,估計應該還是用漢名登記的。)(2)「臺灣原住民族人物命名須用漢字」這點確實也是我希望確立的。SANMOSA 江南好,風景舊曾諳 2021年3月22日 (一) 07:11 (UTC)
戶籍登記姓名可能难以查证。况且,即使張惠妹真的登記为“古歷來·阿密特”,用这个名字命名条目恐怕也不合适。刚刚发现Wikipedia:命名常规已写明“使用中文”,那么再加上既有的常用名原则,就无须对臺灣原住民族作特别规定。--Lt2818留言) 2021年3月22日 (一) 09:04 (UTC)
如果是這樣的話,那就根本不需要另立規則,因為現行命名常規已經有「使用中文」和「使用常用名稱」的規定,直接搬這兩條出來用就可以,這兩條的應用現時也已經具備相當的靈活性。SANMOSA 江南好,風景舊曾諳 2021年3月22日 (一) 10:12 (UTC)
於2021年3月22日 (一) 07:17 (UTC)在不變更提案大意的前提下重寫提案。SANMOSA 江南好,風景舊曾諳 2021年3月22日 (一) 07:17 (UTC)
(-)強烈反对。先前U:克勞棣所稱「谷辣斯·尤達卡不僅僅是中文翻譯,這就是她身為中華民國國民的本名」並非事實,原住民提供翻譯或另取的中文名字,時常只是為了配合漢人的風俗習慣以及漢人政權的法律,不見得代表那就是這個人的本名。例如Kolas自己就有公開說他希望人們用拉丁轉寫來表示他的名字,這才叫名從主人。中維對娛樂創作的標題以及藝名那麼重視官方想要的呈現方式,不旦包括無法念出的符號、區分外觀相同只是Unicode編碼不同的符號、通融各種違反中文文法、不存在於中文的文字、或忽視英文大小寫習慣,然而遇到原住民想用自己的方式表示名字時,卻打壓得這麼起勁?
另外,關於張惠妹/阿密特,如果他有表達比較想用哪個名字,那就用那個,沒有表態或兩者都用的情況下才換用常用名。--C9mVio9JRy留言) 2021年3月24日 (三) 00:24 (UTC)
@C9mVio9JRy君:不!這就是事實,只不過您不想承認而已。①請不要斷章取義,我完整的發言的意思明明是「谷辣斯·尤達卡是她身為中華民國國民的本名之一」,她想叫Kolas Yotaka,《姓名條例》也是允許加註的,谷辣斯·尤達卡與Kolas Yotaka兩者都是她的本名;②中華民國國民就該遵守中華民國法律,這無分河洛人、客家人、外省人、新住民或原住民,一律平等。不然要是有個河洛人想叫「張Davidoff」或「張さゆり」或「張πΣαβγ」,甚至是「張☆△∞」,是否也要允許?不然就是打壓?③漢人只能用中文字當唯一本名,無權像原住民、新住民一樣加註拉丁字母,這是不是也不公平?-游蛇脫殼/克勞 2021年3月24日 (三) 02:29 (UTC)
看來我們對「本名」的定義不同。在我看來「名從主人」不是「名從國家法律」。人類早在世上有國家這種東西之前就有名字了。至於漢人想叫別的,君不見ØZI走路痛WalkToneHowHowJ.SheonJoeman全都用藝名?我就不信大家講話的時候會念/ø.zi.ai/或「ㄗㄡˇ ㄌㄨˋㄊㄨㄥˋ wɔːk toʊn」。叫漢人用漢字和叫原住民用漢字意義完全不同,一個是用母語,一個是用外語。--C9mVio9JRy留言) 2021年3月24日 (三) 10:45 (UTC)
那請問閣下認為Kolas Yotaka的「母語的本名」怎麼寫?人類早在世上有國家這種東西之前就有名字了固然沒錯,但Kolas Yotaka明顯是人類有國家的概念之後才誕生的人類。另外,請問閣下為什麼未經其他用戶同意,就把他們打的「她」都竄改成「[他]」?-游蛇脫殼/克勞 2021年3月24日 (三) 11:04 (UTC)
已代改回。SANMOSA 江南好,風景舊曾諳 2021年3月24日 (三) 11:38 (UTC)
抱歉我的火狐插件設了性別中立轉換,似乎造成了干擾,以後會注意。Kolas自己選用了Kolas這個寫法,這就是他的名字。--C9mVio9JRy留言) 2021年3月24日 (三) 12:38 (UTC)
Kolas是拉丁字母,一樣是借來音譯用的外語,不是她的母語。拉丁字母Kolas並沒有比中文谷辣斯更正統、更能代表阿美語。-游蛇脫殼/克勞 2021年3月24日 (三) 13:36 (UTC)
Kolas覺得「Kolas」比「谷辣斯」更能代表他自己,那就夠了,你一位路人對拉丁文字或漢字的看法與他的名字無關。--C9mVio9JRy留言) 2021年3月24日 (三) 15:32 (UTC)
好,無關。-游蛇脫殼/克勞 2021年3月24日 (三) 17:07 (UTC)
甘仔轄·阿拉米Kamachat Aslamie)是大肚王國君主,屬於(廣義上的)臺灣原住民,那時候的大肚王國根本沒有文字,上面我給出來的拉丁字母是荷蘭人音譯出來的荷蘭文。試問甘仔轄·阿拉米的「母語的本名」又是甚麼?該用中文還是荷蘭文?SANMOSA 江南好,風景舊曾諳 2021年3月24日 (三) 11:38 (UTC)
當時原住民沒有自己的文字而且當事人已過世,那就用現代中文轉譯,這和現代人的情況不同。--C9mVio9JRy留言) 2021年3月24日 (三) 12:41 (UTC)
可能要考慮不愔拉丁字母的人士的需求。SANMOSA 江南好,風景舊曾諳 2021年3月24日 (三) 00:52 (UTC)
重定向可以帶到條目,條目內也列了漢譯。如果真的很在意有人不懂拉丁字母,我們應該先動手的是hide改成松本秀人、Microsoft Windows改成視窗、甚至iPhoneLINE改成哀鳳和賴。--C9mVio9JRy留言) 2021年3月24日 (三) 01:05 (UTC)
使用率不同。你提到的後三個例子基本上都直接被當成中文使用,但人名並非如此。SANMOSA 江南好,風景舊曾諳 2021年3月24日 (三) 02:07 (UTC)
我身邊發音為哀鳳和賴的人比用英語發音成i-phone和line的人更多。--C9mVio9JRy留言) 2021年3月24日 (三) 10:26 (UTC)
可能是所在地不同的情況,我身邊的情況和你身邊的情況完全相反。SANMOSA 江南好,風景舊曾諳 2021年3月24日 (三) 11:24 (UTC)
(+)支持,理據充份,需要有一個可行的維基方針。另提醒維基百科不是宣傳工具,這邊不是宣傳族名拼寫運動或是去中文化的地方(來到中文維基推動去中文化本身目的就抵觸和相反了),這裡只是民間團體的寫作網站,政策方面如有疑義請自行前往監督政府。--章安德魯留言) 2021年3月26日 (五) 18:42 (UTC)
於2021年3月27日 (六) 10:54 (UTC)修改提案,不影響文意。SANMOSA 江南好,風景舊曾諳 2021年3月27日 (六) 10:54 (UTC)
仍然(-)反对。理由再重复写一下:“使用中文”是冗言,理当如此。户籍登记姓名则难以查证,此规定无意义。--Lt2818留言) 2021年3月27日 (六) 11:32 (UTC)
(1)非冗言。WP:命名常规#使用中文:「……惟若原文名稱比中文翻譯的名稱在中文中更加常用,或如果不存在中文翻譯的名稱,則應使用原文名稱。至於個別專題下之條目之命名,如有對應子方針,則應以該子方針指引之規則為優先。」根據此條,「理當如此」的關係不存在,一來是子方針優先性高於母方針,二來是羅馬拼音可能比中文翻譯在中文中更加常用。(2)政府網頁或身分證上的姓名和戶籍登記的姓名一致。SANMOSA 江南好,風景舊曾諳 2021年3月27日 (六) 13:20 (UTC)
举个例子,國際單位制的重新定義之所以拖到2019年,是因为先前对相关物理常数的测量精确度不足。同样,除非中华民国能提供所有公民的登记姓名查询,否则其不应作为判别依据写入方针。--Lt2818留言) 2021年3月27日 (六) 15:28 (UTC)
反對理由不充份,看不懂國際單位制的例子跟這裡的關聯。另外,以人物傳記條目蔡英文為例,「性別、別名、出生、籍貫、民族、國籍、父母」etc.這些資料同樣都不是來源自(也不可能會有)所謂的「公民登記查詢」資料庫。--章安德魯留言) 2021年3月29日 (一) 05:00 (UTC)
国际单位制的例子为类比。公制确立的时候,把“一米”定义为子午线两千万分之一或者米原器长度都没问题,但不能定义为光在1/299792458秒內行進的距離,因为当时没人测得出光速。提议条文中的“户籍登记姓名”同理,哪怕张惠妹亲属以其身份证为凭,也不能把条目命名为张鲑鱼,正因户籍登记姓名对于公众而言无法查证,也不可能让主张者上传身份证来证明。--Lt2818留言) 2021年3月29日 (一) 07:18 (UTC)
還是沒有回答到問題:「性別、別名、出生、籍貫、民族、國籍、父母」etc.同樣也沒有開放可直接線上查詢的登記資料庫,所以反對理由不夠合理。另外雖然不具參考性,但是維基上確實是有老蔣的身份證。--章安德魯留言) 2021年3月30日 (二) 10:55 (UTC)
@Ch.Andrew:我不是说身份信息查询合理。这个条件和“山无陵,江水为竭,冬雷震震”为同样性质,作为另一命题的歸謬,本身并非重点。后者应该见过,毕竟溪口、慈湖都曾游览过。--Lt2818留言) 2021年3月30日 (二) 11:48 (UTC)
想到一個問題:如果我們認定iPhone和Windows是否已經成為中文外來語的依據是它是否常用,那實質上就是用「常用名稱」作為條目名,比照辦理的話,原住民的名字也應該以常用名優先;如果常用名是拼音,那該用拼音作條目名。然而此提案第二點卻說當拼音確實比中文翻譯更常用時,「應將該常用名稱音譯處理」。我不懂如果iPhone和Windows這兩個常用名稱可以當作外來語使用,不用翻譯成哀鳳和視窗,為什麼原住民的名字卻必須以中文優先?一方面我們接受西方和日本的科技及娛樂主題用原文,一方面我們不允許少數民族用原文,這除了雙重標準和差別待遇之外,我看不出別的解釋。--C9mVio9JRy留言) 2021年3月28日 (日) 15:10 (UTC)
總結來說,我的立場有兩點:(1) 當事人明確表態希望用某種方式表示他的名字時,這是他的基本人權(聯合國人權事務委員會,Coeriel and Aurik v. the Netherlands),應予以尊重,尤其當他們是歷史上曾遭受不正義的少數族群時更應如此,凌駕於常用名稱或使用中文的規定(至於那些單純因商業效果而搞得怪里怪氣的官方作品名或產品名,因不涉人權,可以常用名優先)。(2) 若當事人未表態,但有廣泛接受的常用名,此常用名優先,不管是拼音還是中文,如同電子產品和一些亞洲藝人的情況。--C9mVio9JRy留言) 2021年3月28日 (日) 18:29 (UTC)
因為《姓名條例》對所有中華民國國民都有約束力,並沒有雙重標準。如果一位臺灣原住民不是出於商業因素,而是真心非常非常喜歡數學,喜歡的程度多過他的族群傳統文化,閣下認為他可以用e^(iπ)+1=0作為本名嗎?這也是他的基本人權?那麼臺灣漢人有無這樣的基本人權?-游蛇脫殼/克勞 2021年3月29日 (一) 00:24 (UTC)
1. 提案中的「將該常用名稱音譯處理」並非使用符合《姓名條例》的法定姓名。2. 姓名條例對中華民國國民的法定姓名有約束力,但對維基百科的條目名沒有約束力。3. 我傾向認為不論法律是否允許,你都有權昭告天下說你的名字是「許星光流連擊鮭魚」,大家也應該尊重。4. 用數學公式當名字目前沒有判例,如果有一般人念不出來的符號或是技術上難以顯示的格式,我猜人權事務委員會可能會同意國家有權禁止該姓名。5. 漢人當然有權利用別的文字當名字,而且維基百科對這些另取名字的漢人可尊重得很,我前面已經舉例了:ØZI走路痛WalkToneHowHowJ.SheonJoeman。--C9mVio9JRy留言) 2021年3月29日 (一) 00:53 (UTC)
雖然《姓名條例》對伺服器在美國的維基不具約束力,但是仍是一項重要的參考基準。「姓名」和「商標、藝名、產品名、書名」etc.的法律意義及社會意義上都有所不同,姓名是別人如何稱呼你並且令每個人與社會連結的工具。後現代主義讓許多人自我中心慣了,法律和契約這些基本觀念彷彿通通當成空氣一樣。實務上不可能讓姓名權無限上綱,若有人主張自己的姓名是「以微秒變換、以鮭魚起頭接續所有中文字集進行無窮級數排列組合的姓名光譜」,請問該如何呈現?另外還要考慮到姓名跟轉型正義抵觸時被禁止的情況,例如納粹系列的姓名。顯然不可能對於姓名權毫無限制。--章安德魯留言) 2021年3月30日 (二) 11:25 (UTC)
我的要求從來就不是無限上綱,而是把一個技術上可行、在中文維基中本來就存在的寫法(拉丁字母),延伸到既有的「名從主人」規則,並且實行上目前唯一的案例還符合「常用名稱」的規則。你想象的滑坡例子不會有可靠來源,並且可以簡單用技術理由禁止。--C9mVio9JRy留言) 2021年3月31日 (三) 05:40 (UTC)
(-)反对Kolas比谷辣斯更常用、廣為人知,用google去找結果也是這樣。一位原住民符合常用、廣為人知的是拉丁字,還一定要改成漢字,那就請把藝人、運動員、作家...的廣為人知拉丁名條目全部設方針改成漢字,不要只針對原住民。相反若只是原住民自己想要的拉丁名,卻不是廣為人知的常用名,那就不用遷就那個。--2001:B042:1:A724:7CCD:E884:C570:5D6A留言) 2021年3月29日 (一) 05:20 (UTC)
正有此意,规定不应专门针对台湾原住民。合适的行文可以为“人物若以本名命名,应当使用汉字”。--Lt2818留言) 2021年3月29日 (一) 07:38 (UTC)
不管是物件、人物、官方名、藝名……,若他的廣為人知的常用名是拉丁字,倒是不一定要音譯成漢字。可是只要標準是一致的,不是只針對特定族群,這裡就不會去反對了。--2001:B042:1:AF30:7CCD:E884:C570:5D6A留言) 2021年3月29日 (一) 08:27 (UTC)
补充一下,若认为Kolas是中文的话,请加上间隔号书写为Kolas·Yotaka,毕竟中文不用空格作标点。--Lt2818留言) 2021年3月29日 (一) 12:42 (UTC)
Microsoft WindowsiPhone 12 Pro想見 想見 想見你怎解?--C9mVio9JRy留言) 2021年3月29日 (一) 16:12 (UTC)
皆非人名。前两者相当于直接引用原文,都能接受(但对人名不适用);第三者为日本作品,对比该国其他混乱命名(如《你的名字。》《寫不出來!?~編劇 吉丸圭佑的無情節生活~》)则相形见绌。我上面的话过于绝对,中文也会使用全形空格,如挪擡等情形。--Lt2818留言) 2021年3月30日 (二) 05:54 (UTC)
提供一個參考,英文維基對人物傳記的指引en:MOS:MULTIPLENAMES有這句:「If a person, or more typically a group, has adopted a new name because they determined the old name to be offensive, generally use the new name for all time periods. 」簡言之,如果某個人認為原本的名字有冒犯性而改名(可能因為牽涉到歷史正義或傳統信仰),英文維基的指引是所有內文都要盡量改成新的名字。依照此精神,如果有位原住民認為漢字名有冒犯性,也應使用族語名。--C9mVio9JRy留言) 2021年3月29日 (一) 16:53 (UTC)
我要解釋一下為何要避開羅馬拼音:假設臺灣原住民的原住民族姓名格式名字的羅馬拼音版本可以當成條目名,那理論上維基百科大部分非華裔傳主的條目的名字也不該音譯,而應該把那串拉丁字母當成條目名,但這顯然是荒謬的。另一方面,嚴格上來說,羅馬拼音根本不是臺灣原住民族語言的「文字」,臺灣原住民族語言本來就沒有「文字」(或已失傳),是後來才引入拉丁字母來拼寫的。甘仔轄·阿拉米Kamachat Aslamie)的名字應該是拍瀑拉語,但拍瀑拉文根本不存在,我上面給出來的字母是荷蘭文。SANMOSA Σουέζ 2021年3月30日 (二) 00:02 (UTC)
1.現在的命名原則是標題通常是中文的,可是原文比中文翻譯在中文中更常用,或沒有中文翻譯,就能使用原名。這規則用在原住民身上沒幾位本名能用拉丁字的,暫時也就看到Kolas。若這規則用在非華裔傳主的條目會造成很多拉丁字,然後大家又認為人物本名不能用拉丁字,藝名和各種物件才可以,那就設計一套不是只針對原住民的規則來用。2.這個也是有國家、族群,因為被殖民、嚮往種種情形,引入拉丁字母、漢字當成自己語言的書寫方式,現在原住民的母語也還是用拉丁字母在書寫,所以語言去區分是不是嚴格上自己民族發明的文字,也不是太重要的。--2001:B042:1:AFA9:7CCD:E884:C570:5D6A留言) 2021年3月30日 (二) 04:31 (UTC)
不住在華語圈的人,他們的生活中不會面對名字要怎麼寫的問題,也沒有被漢人壓迫的歷史,所以他們的名字音譯成漢字並不會讓他們感到不愉快,但原住民不然;這在Talk:谷辣斯·尤達卡的討論中U:Reke說明得很清楚。至於你質疑拉丁字母本來不是原住民語言,那是帶有隱性歧視的論述。你去跟閩南語維基百科說他們用的白話字不是閩南語原有的文字,或是要求英文維基改用盧恩字母看看。甚至中文在甲骨文出現以前,本來也是沒有文字的,而且現代這套標準化的楷書是Unicode或中華民國教育部出現之後才有的,我們沒有因此說華語、英語、閩南語沒有文字,為什麼原住民語言卻單獨被指出來?現代原住民語言用拉丁字母書寫,這是客觀的事實,就像中華民國是主權獨立的國家一樣是客觀的事實,只不過有些人受意識型態影響而拒絕承認原住民的文字是文字。--C9mVio9JRy留言) 2021年3月30日 (二) 12:00 (UTC)
美洲原住民同樣也有受壓迫的歷史,卻沒有禁用拉丁字母拚寫族語姓名的呼聲,據此我合理懷疑en:MOS:MULTIPLENAMES指引對台灣原住民姓名的適切性。今天如果是要求台灣原住民的條目必須強制用漢名「林〇〇」「陳〇〇」我想在座各位都不會同意。但是針對族語姓名禁用特定語種文字的拼音,類似的作法在維基上並沒有他語種的先例,敘事邏輯倒是跟十年前蔣為文公開罵黃春明的「台灣作家不用台灣語文,卻用中國語創作,可恥!」相當類似。最重要的是,我不認為禁用的作法對族語的推廣與保存具有正面效益,羅塞塔石碑的存在證明了多語言平行對譯的重要性,施加過多的種種限制反而限縮了族語的自身發展空間。同時我不覺得Sanmosa的論述帶有隱性歧視,他應該是聯想或注意到相較於臺灣原住民族,地球上的許多民族具有明確的自身創制文字系統,例如彝族彝文馬雅文明馬雅文字。另外還有一類,是援用現有文字系統並加以改造的,有加拿大原住民音節文字(援引印度天城文並且改良)、苗族柏格理苗文(參考前者的經驗而創制)。而臺灣原住民族語羅馬字是法定的書寫系統,跟前兩者不同的是,既不是自有創制或是援引改良,而是直接套用拉丁字母的文字系統,順帶一提臺灣原住民族語也有使用過日文假名注音字母這2種文字系統[7]甲骨文其實是相對成熟的文字系統,就像化石也有「失落的環節」那樣,比起甲骨文更早之前一定還有文字,只是考古出土和解讀的資料有限而已。至於楷書的標準化明顯跟此事沒有可類比性,這點就直接略過。其餘的政治類論述則是不在我這次的關注範圍內。--章安德魯留言) 2021年3月30日 (二) 19:25 (UTC)
在維基上想替原住民爭取特殊規則,他也只是論述而已,沒有提案或強制大家接受,這種論述他是出於善良的、有同理心的。就好像COVID-19的命名,有人認為部分人被歧視了,想要去禁止一些用詞。現在的提案情形是,原住民傳主的本名就算符合命名原則的原文標題,也一定要音譯成漢字,然後其他主題卻沒有限制。這樣的話針對性比較強,原住民傳主暫時也只看到Kolas本名能用拉丁字母命名而已,遠遠沒有其他藝名、動漫、各種物件主題的拉丁字泛濫的。--2001:B042:1:A95D:C809:62F5:44EC:18E5留言) 2021年3月31日 (三) 03:40 (UTC)
中文維基本來就已經允許很多情況下採用拉丁字母,所以就算MULTIPLENAMES不曾受到美洲原住民的挑戰,也還是可以在此作為參考。我要求的不是禁用漢字音譯,而是在當事人明確表達對拉丁字母的偏好時,採用此寫法。關於其他文字系統的部份,目前有Wikipedia:命名常规#罗马化,所以不會有蒙古文、苗文、滿文、維文之類的問題。雖然這也有西方霸權的嫌疑,但該原則另外也考慮到所有華人國家都在義務教育中納入有英語或拼音的現實(也就是說拉丁字母對多數讀者來說是可識別的,其他文字不然),而且也顧及到一般人能否簡單輸入的技術考量。--C9mVio9JRy留言) 2021年3月31日 (三) 05:30 (UTC)
前面我誤解了閣下的意思,的確,就算《姓名條例》約束所有中華民國國民都要有一個用中文表示的法定名字,也不代表維基必然要用這個法定名字作為條目名,但是,只要符合「當事人明確表達對拉丁字母的偏好」就應該要使用拉丁字母嗎?前面同意「名從主人」的維基人似乎都認為至少還要同時符合「常用名稱」吧?-游蛇脫殼/克勞 2021年4月1日 (四) 15:34 (UTC)
在下還真的不認為白話字臺羅拼音是臺語的文字,臺語的文字應該是中文,儘管臺語並不是唯一一種以中文為書寫系統的語言。個人認為像𣍐、囡、佮、媠、𡳞這些臺語常用、但中華民國國語幾乎不用的「臺語正字」也都是中文。白話字或臺羅拼音都只是拼音而已,不是文字,用六書造出來的臺語正字才是文字。-游蛇脫殼/克勞 2021年4月1日 (四) 15:34 (UTC)
我重看了一下規則,WP:常用名稱只要求「儘量使用……常見的名稱」,並未要求使用「常見的那一個名稱」。如果99.9%的人都用某常用名稱,當事人自己偏好的名字只有0.1%的人用,那我也相信用常用名是合理的,但假如兩個名稱的使用率是60%對40%(甚至51%對49%),或者有三個以上的名稱各有一定的使用率,那麼「常用名稱」不足以表示任一名稱比其他名稱更好。總而言之,常用度和當事人的偏好的取捨,是連續分佈,目前的規則並未強制以「最」常用的名字優先,我也不認為應該這麼做。不過目前還沒遇到實例(Kolas是最常用名稱),這部份的問題或可擱置。--C9mVio9JRy留言) 2021年4月3日 (六) 15:00 (UTC)
我沒有說以「最」常用的名字優先,我的意思是,「名從主人」與「常用名稱」誰都沒有比誰優先,所以如果「名從主人」與「常用名稱」恰好是同一個名稱,那就應該用這個名稱,如果不是同一個名稱,那就需另議了。另外,請閣下也看一下WP:名從主人Kolas Yotaka其實並不符合「名從主人」(但符合「常用名稱」),彭定康陸克文郎世寧才符合。-游蛇脫殼/克勞 2021年4月3日 (六) 16:15 (UTC)

命名常規擬議修訂[编辑]

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

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

@A2569875Taiwania JustoYining Chen羊羊32521YFdyh000@LuciferianThomasEricliu1912MilkyDeferSuper WangSunny00217SANMOSA 江南好,風景舊曾諳 2021年3月24日 (三) 09:08 (UTC)
(+)支持。偽命名空間運行暢順,可選擇有需要的計劃空間內容增設偽命名空間。(&)建議命名常規使用「NC」字首、關注度使用「N」字首。另(&)建議增設共識(討論)捷徑「CON」,連結至各討論存檔(Talk、WT、PJT)或資訊頁(WP),如CON:COVID19指向COVID-19條目共識。--LuciferianThomas留言 2021年3月24日 (三) 09:32 (UTC)
NC和N可行。CON可行,但建議另外討論,因為CON可以重新導向到的目標有太多類頁面。SANMOSA 江南好,風景舊曾諳 2021年3月24日 (三) 10:00 (UTC)
支持N和NC,对CON保留意见 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月25日 (四) 06:07 (UTC)
N的话会不会短了点?之前MOS和LTA的时候因为是三个字母,跟正式条目命名撞车的可能性小所以没有问题。这一个N我个人有点拿不准。此外我觉得CON可能还不是时候。在我的认知中,单独讨论出共识单独成页的也就只有COVID-19这一个了,至少应当等类似的页面数量足够多了再提出会比较好。如果有我不知道的类似页面尽管告诉我。 --Milky·Defer 2021年3月25日 (四) 07:36 (UTC)
檢查過,現時沒有條目空間的頁面是「N:」開首的。如果真的不放心的話,NT和NOTE也可以(但不能NOT)。SANMOSA 江南好,風景舊曾諳 2021年3月25日 (四) 07:44 (UTC)
@sanmosa: 维基新闻的前缀就是“n:”,烦请查询Special:跨wiki。--痛心疾首 2021年4月2日 (五) 15:43 (UTC)
啊,忘了。SANMOSA Σουέζ 2021年4月3日 (六) 00:12 (UTC)
先跑题:MOS基本没用过,看到时我习惯改用WP前缀。LTA用过但没有独立空间所以搜索很不方便,期望未来设独立空间、增设访问限制。然后:我不清楚相关页面有多少,如果很少,可能用的人也不会很多?以及持久性不会好(几年后失效)。N有点短,NOTE我想到[{tl|TA}}和备注,命名常规为什么不是NAME:(但未来会不会冲突?)。关注度没想法,考虑到“关注度”定名本身都有质疑,我暂时想不到很好的。NT在中国大陆网络有贬义“脑瘫”,不赞成。--YFdyh000留言) 2021年3月25日 (四) 12:14 (UTC)
@YFdyh000:「NAME:」應該不會衝突吧,也不不失是一個好提議。「NT:」你當我真的NT了吧(在香港「NT」指新界,不過以地名開首還是有些怪)。「NOTA:」不知如何,有種葡文風,但字源仍是「Notability」,衝突的機會也低。SANMOSA 江南好,風景舊曾諳 2021年3月25日 (四) 13:01 (UTC)
(-)反对,如果将编辑社群页面等因为与Wikipedia命名空间关联性不强而划分出的话,方针等与项目运营有关的的页面不应该划出Wikipedia空间,而且本身这部分已经能通过消歧义的方式处理,没坏别瞎修。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年3月26日 (五) 00:54 (UTC)
@cwek:偽命名空間僅用於設置重新導向頁面(這是指引指明的),完全沒有你所說的「(將導向目標)劃出Wikipedia空間」那回事。SANMOSA 江南好,風景舊曾諳 2021年3月26日 (五) 01:00 (UTC)
偽命名空間作用並非直接劃出內容,而是作捷徑之用:#偽命名空間WP:PNSWP:PNS+。因為似乎對於提案內容有所誤解,反對的事也並非現在實際正在討論之議案,故難以算作有效反對意見。--LuciferianThomas留言 2021年3月28日 (日) 06:23 (UTC)

交通關注度指引修訂[编辑]

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

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

可参见WCAG 2.1 AA。--痛心疾首 2021年3月22日 (一) 13:34 (UTC)
Wikipedia:格式手冊/文字格式#颜色及内联图像算不算?SANMOSA 江南好,風景舊曾諳 2021年3月22日 (一) 13:52 (UTC)
導航模板不算正文(邏輯上)。就是此前處理了一個WCAG 2.1有問題的模板我才開啟討論。1233 T / C 2021年3月23日 (二) 03:51 (UTC)
Wikipedia:格式手冊/文字格式#颜色及内联图像的確無法處理導航模板。 --無心*插柳*柳橙汁 2021年3月24日 (三) 03:31 (UTC)
@1233Milkypine:可以擴大Wikipedia:格式手冊/文字格式#颜色及内联图像的適用範圍。SANMOSA 江南好,風景舊曾諳 2021年3月25日 (四) 04:40 (UTC)
完全支持擴大適用範圍。 --無心*插柳*柳橙汁 2021年3月25日 (四) 05:13 (UTC)
可解決問題,故支持。唯此格式手冊的修訂將會影響大量的模板,故需要更深入的討論。--1233 T / C 2021年3月25日 (四) 15:23 (UTC)
@痛心疾首Milkypine1233:已移動討論至方針區。SANMOSA 江南好,風景舊曾諳 2021年3月26日 (五) 09:01 (UTC)
擬修改如下:
現行條文

颜色及内联图像

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

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

类似地,条目正文中禁止使用内联图像(例如在文字中出現Symbol support vote.svg這樣的图像),但在表格及信息框中使用則接受

提議條文

颜色及内联图像

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

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

同理,条目正文中禁止使用内联图像(例如在文字中出現Symbol support vote.svg這樣的图像),但在表格及信息框中使用内联图像則可接受。

以上。SANMOSA 江南好,風景舊曾諳 2021年3月26日 (五) 23:40 (UTC)

似乎应该是不在条目里用带特殊颜色的模板,而不是规定模板不得带颜色。所以建议“条目正文、表格及各类模板”→“条目正文、表格及条目中使用的各类模板”。--DrizzleD (按此给我留言) 2021年3月28日 (日) 08:04 (UTC)
@DrizzleD:然而這裏最原始的提議就是禁止所有模板著色(如果我沒理解錯的話),@1233SANMOSA ······ 2021年3月28日 (日) 23:48 (UTC)
@DrizzleDSanmosa:我的概念是應當建立相關Accessibility的指引(例如對規範模板中文字和背景色的對比度)。而又當此等指引未達成共識前,則不應對模板著色。--1233 T / C 2021年3月29日 (一) 02:39 (UTC)
禁止所有模板着色恐怕不现实。且不提{{支持}}这种模板或者就在本句话中使用的{{tq}},单是为数众多的多彩用户框就不可能处理过来啊。--DrizzleD (按此给我留言) 2021年3月29日 (一) 14:48 (UTC)
如果我沒理解錯誤的話,是不是Infobox系列模板都不能自訂文字和背景的顏色? 2021年3月29日 (一) 04:28 (UTC)
是的(如果我沒理解錯1233的意思的話)。SANMOSA ······ 2021年3月29日 (一) 05:31 (UTC)
就Accessability这个理由,完全支持禁止对模板、表格等上色。🌟🌟Talk 2021年3月29日 (一) 04:53 (UTC)
(-)反对:信息框內的文字在某些情況下應允許使用不同的顏色,否則將無法很好地表意;導航模板同理,例如{{柑橘属}}和{{地質年代}}模板使用了不同的底色,但也只是起到輔助區分相關信息的作用,並不影響色盲色弱等特殊群體閱覽,取消這些底色後,非但不能照顧到少部分特殊群體(因為在色盲色弱看來,無論普通模板還是上色模板基本都是一片灰,並無本質上的區別),並且對於絕大部分正常讀者而言將是一大損失。讓絕大部分正常群體去遷就少部分特殊群體,屬於西方式政治正確(就好比硬說黑人和白人一樣聰明),英維的做法不可取。--蕭漫留言) 2021年3月29日 (一) 12:51 (UTC)
同意需要有指引規範相關模板的著色。另外我處理的部分模板出現嚴重的"撞色"問題,才要求模板應暫時停止著色。這不是西方不西方的問題,而是此等問題已經燃燒至影響正常的閱讀體驗了。--1233 T / C 2021年3月29日 (一) 13:30 (UTC)
西不西方我是不清楚,但肯定是眼殘級別追夢 Do Re Mi。尤其是像Template:Weki_Meki,這邊上色的意義何在? --Loving You Is A Losing Game 2021年3月29日 (一) 15:21 (UTC)
不同意柑橘屬跟地質年代這兩個舉例,柑橘屬的顏色僅僅是階層式架構,以排版就足以區分,不需要再加上顏色;至於地質年代的顏色更是沒有意義,部分底色與文字顏色對比度不高,對正常人來說也是難以閱讀。--Xiplus#Talk 2021年4月3日 (六) 06:01 (UTC)
@Xiplus:像这三个案例{{中国历史}}、{{Geological_range}}、和{{古近纪图形时间线}}呢,有本事你对Geological_range和古近纪图形时间线的英维版禁止着色啊。反对一刀切致使中维倒退的方针。你少代表正常人对地质年代发表看法,也只是对你来说難以閱讀而已。U:Lab06 N 参与 2021年4月3日 (六) 12:46 (UTC)
(-)強烈反对:对地质和生物学相关等特殊模板有严重影响!1.减轻服务器负担这个理由就经不起推敲,难道现在的服务器机能还不如以前的服务器?2.另外照顾色盲色弱群体这个理由已经有人反驳了。U:Lab06 N 参与 2021年3月30日 (二) 13:57 (UTC)
那完全不是合理的反駁理由。“因為在色盲色弱看來,無論普通模板還是上色模板基本都是一片灰,並無本質上的區別”是錯的,普通模板的話全色盲至少還能分得到淺色和深色(白色和黑色),上色模板全色盲就完全分不到了。全色盲還是能分辨白色和黑色的,他們只是cone cell不能function而已,rod cell還是能function的。SANMOSA Σουέζ 2021年3月31日 (三) 07:53 (UTC)
既然已經了解提案禁止對Infobox等模板上色,那麼我(-)反对此提案,畢竟有些Infobox模板的顏色對辨別條目類型有很大的幫助,不能因為視覺障礙人士而選擇單一的格式,不過如果是限制背景顏色和文字顏色之間的對比度,這我能夠接受。 2021年4月1日 (四) 14:20 (UTC)
仔细想了想,倾向不赞同:
  1. (主要)现行方针能够确保色盲(弱)人士能够获取充分信息,根据现行方针要旨,只需避免“单独地使用背景颜色来表达某一含义”,同时避免“饱和度过高,或与文字对比度不足”,上述举措——
    • 确保了色盲(弱)人士能够不依赖颜色获取足够信息,确保所有人阅读的文字是清晰的;
    • 在此基础上,不对辅助性背景填色进行“一刀切”,能保障更多色觉正常的人士能借背景色获得获取信息上的便利。
  2. (次要)变更宜乎审慎行事,仅高速公路一类就有逾千条条目和大量模板受到影响,即便上述修改要实施,修正案也未能列出批量变动的页面范围和变动的具体方案。
以上。--Kirk # 2021年4月1日 (四) 14:33 (UTC)
個人認為對現行模板應當是採取沒壞別修的態度:應當先行禁止新(類型)的模板著色,再討論如何界定為“可行”且為輔助性的背景著色,再解決“應當在何時著色”和“怎樣才是可行的著色”的兩個問題--1233 T / C 2021年4月3日 (六) 02:41 (UTC)
  • (-)反对,限制面太广,用户框、导航模板等都会受影响。可行的着色可以按常识判断。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月3日 (六) 04:56 (UTC)
  • 拆分投票:
    • (+)傾向支持在條目正文中禁用內聯圖像。
    • (-)反对一刀切地禁止上色。限制使用過份複雜的上色可以理解,但一刀切的話就過猶不及了。📕📙📒📗📘📚📖 2021年4月3日 (六) 05:12 (UTC)
  • 支持要求条目用导航模板使用预设配色。使用其他颜色可以,但应该给出理由;而且这个理由是领域内讨论出的统一的配色方案。像Template:Citrus为什么要上成黄色而不是其他颜色?是属级导航框的统一用黄色,纲级导航框又用另一种颜色;还是觉得这个颜色是柑橘的主题色(那孔雀呢);还是编辑没理由随便上的颜色?而且导航模板和信息框还不一样:条目可以放多个导航模板,随意上色的结果就是花花绿绿,不同颜色搭配起来很不美观。如果其他导航框用默认颜色,比较次要的那个导航模板又私自上色,那它会不会有抢镜头的嫌疑?总之,导航模板上色需要极其保守,找不到必须上色的理由就别上。--洛普利宁 2021年4月3日 (六) 16:13 (UTC)
  • 支持樓上所述,另參考各語言維基百科也對上色趨於保守或嚴格規範。即便不全面禁止也需有個合理的規範,哪些領域的確有這需求,哪些領域又該嚴格禁止或者限定。不該完全置之不理任由問題累積未來才以影響範圍大而放棄討論制定規範。立ち直り中 2021年4月5日 (一) 12:47 (UTC)
  • 上色這種東西如果能夠靠自由心證或常識解決,那就不會有像追夢 Do Re Mi這樣的上色亂象。的確我不是地理條目相關編輯,但前面提到的{{中国历史}}、{{Geological_range}}、和{{古近纪图形时间线}}請問有哪個一定需要顏色?或者說這些顏色必須一定要有的理由為何?(當然也可以直接開民調調查有顏色大家會不會比較OK)。如果這些顏色有一定的存在理由,那就針對這點做改善(例如常用習慣等)。 --Loving You Is A Losing Game 2021年4月5日 (一) 13:11 (UTC)
意見頗為分歧,我建議就此進行投票,不知各位意下如何。SANMOSA Σουέζ 2021年4月10日 (六) 06:39 (UTC)
這不是投票就能解決的問題,一來是不能只因為視覺障礙人士而選擇單一的樣式,再者是影響範圍過大,投票並不能體現所有使用者的意見(匿名使用者不能投票,請留意維基百科並非專給註冊使用者閱讀)。如果您要發起民調,我沒意見,但是我反對發起投票。 2021年4月10日 (六) 07:05 (UTC)
然而現時的狀況確實對視障人士構成嚴重的歧視,我認為所有人現在最基本要知道的就是現時模板的着色情形已經嚴重影響到視障人士的閱讀體驗。投票的選項亦非只有兩種(至少我初步的計劃如是)。在陷入複雜討論的泥潭時,投票顯然是一種快速收集意見以凝聚共識的方法,不能單純因為「影響範圍過大」和「不能體現所有使用者的意見」而反對發起投票和變相剝削視障人士的合理閱讀體驗。SANMOSA Σουέζ 2021年4月11日 (日) 14:26 (UTC)

變通提案[编辑]

以下是小弟的變通提案:

現行條文

颜色及内联图像

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

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

同理,条目正文中禁止使用内联图像(例如在文字中出現Symbol support vote.svg這樣的图像),但在表格及信息框中使用内联图像則可接受。

提議條文

颜色及内联图像

条目正文表格及各類模板(包括信息框中,使用原始碼或其他模板将文字或背景顏色染成非預設颜色,應以幫助闡釋條目內容為第一目的同時,編者也需要考慮色盲、色弱或使用黑白版本的读者的實際需求。[1]

除非編者有正當理由,並且能在討論頁自證有理,否則:

  • 同一表格或模板只能使用一種邊界色、一種標題欄背景色、一種標題欄文字色,且總共不能超過三種顏色;
  • 請避免單獨地使用背景顏色來表達某一含義,而應適當地同時以文字方式表述;
  • 邊界色、標題背景色、標題文字色之間應該有可視的對比度;
  • 內容背景色和內容文字色之間也應該有可視的對比度;
  • 表格/模板邊界色和內容背景色兩者的飽和度不能太高;
  • 禁止手動將表格或模板的內容文字染成其他顏色。
  • 禁止使用CSS代碼對表格/模板的任何部份加入花俏的樣式(如漸層色等)。

為避免編輯爭議,建議編者在編輯的同時,即在編輯摘要或討論頁中說明上色的理由。

同理,条目正文中禁止使用内联图像(例如在文字中出現Symbol support vote.svg這樣的图像),但在表格及信息框中使用内联图像則可接受。

  • 「一種顏色」的定義為一個RGB值。例:#FFFFFF和#FFFFFE視為兩種顏色。
  • 「飽和度不能太高」定義為紅綠藍三原色中,任何一種原色數值低於EE。

小弟主要編輯體育相關條目,因此在這裏用個和體育相關的例子:編者在編輯某足球隊的球員名單(表格)時使用的標題背景/文字顏色組合,如果和該足球隊隊徽或主場隊服的配色相同,即視為能夠「幫助闡釋條目內容」。反之,如果編者用的是另一支球隊的隊徽或主場隊服的配色,則視為無助於闡釋條目內容,要麼重新上色,要麼改用預設顏色。舉例說明:加拿大國足的主場球衣(守門員除外)的主色調為紅色(#FF0000或更深),球衣字體為白色,而且紅色和白色之間的差距足夠大,因此加拿大國足的導航模板的標題可以染成紅色背景、白色文字。美國國足的主場球衣的主色調為藍色,因此如果把加拿大國足的導航模板的標題染成藍色背景、白色文字,則視為無助於闡釋條目內容。

以上。📕📙📒📗📘📚📖 2021年4月11日 (日) 03:13 (UTC)

交通關注度指引適用範圍的擴展[编辑]

提案将维基百科:格式手册/不要模棱两可列入格式手册[编辑]

提议对WP:DYKC的投票须知进行修改[编辑]

現行條文

投票者可用{{支持}}{{反对}}{{意见}}{{建议}}等投票或作为引子来表述观点

提議條文

投票者可用{{支持}}{{反对}}(或{{support}}{{oppose}})进行投票,動用到自定義參數修改預設顯示文字的模板不計票。可用其他模板作为引子来表述观点

WP:VPT#问题回报:新条目推荐候选里面的机器人似乎有点问题中的讨论引申出来的一个条文修订提议。建议明确现行DYKC的投票模板,从而方便人工或者机器人的点票工作。

--Tazkeung(CommentHERE) 2021年4月2日 (五) 04:12 (UTC)

代增補一條。SANMOSA Σουέζ 2021年4月2日 (五) 05:07 (UTC)
(+)支持此提議。另外,建議增加{{Support}}{{Oppose}}寫明於說明內(首字母大寫不同),使敘述更加明確涵蓋到此二模板的各種表示法。不過如果要考慮到點票作業方便,鑒於{{Support}}、{{Oppose}}為較泛用型的意見表達模板,建議可以仿照FA、GA評選,建立評選投票專用模板(比如仿照{{YesFA}}、{{NoGA}}的呈現方式,修改既有{{YesDYK}}、{{NoDYK}},使其做為DYK評選投票專用)。如此應可以增加點票作業程序的穩定性。--Bowleerin留言) 2021年4月3日 (六) 08:17 (UTC)
那麼如果真的有意見或疑問,想要諮詢主編怎麼辦?例如條目內文中出現「……於昭和二十年(1955年)創立」這樣的年份錯誤,想要請主編確認到底是昭和二十年還是1955年。-游蛇脫殼/克勞 2021年4月3日 (六) 13:10 (UTC)
啊就(!)意見(?)疑問啊,這兩個模板本來就不計票。—— Eric Liu 創造は生命(留言留名學生會 2021年4月3日 (六) 13:29 (UTC)
公示7日。SANMOSA Σουέζ 2021年4月10日 (六) 05:59 (UTC)

调整界面管理员方针之“权限取得”一节[编辑]

根据先前讨论一先前讨论二,提议向“资格要求”追加一项“需现任管理员”,以达到逻辑和运作上的自洽。--安忆Talk 2021年4月4日 (日) 06:59 (UTC)

所以你自己這個案會怎樣處理?-某人 2021年4月4日 (日) 08:06 (UTC)
是指权限不足?方针改了的话,这个问题就迎刃而解了。后来的人没问题就行了,我自己可以暂时在需要的时候拜托其他是管理员的人。--安忆Talk 2021年4月4日 (日) 08:22 (UTC)
讓您成為唯一一位例外並不太好; 可是要求您辭職又更過分了。--Temp3600留言) 2021年4月4日 (日) 18:40 (UTC)
我想这不是一个特别难解决的矛盾,不看这个,就方针本身的变动而言,请问有什么意见吗?--安忆Talk 2021年4月5日 (一) 02:30 (UTC)
由於我一向支持將技術組與行政組盡量分拆,我反對您的建議。--Temp3600留言) 2021年4月10日 (六) 12:36 (UTC)
我认为,界面管理员确实有跛脚的问题,但尚没有到必须要所有界管都一定要管理员权限的境地。有最好,但没有的话也不是没法开展工作。--痛心疾首 2021年4月5日 (一) 04:14 (UTC)
目前介面管理員沒有deleteeditcontentmodelmovemove-subpagessuppressredirect等權限,就您的個案來看,這個提案是很實際的。不過對於臨時申請介面管理員的使用者(外站也有可能),這些權限可能不是那麼重要。如果提案通過,介面管理員將永遠不能申請臨時權限。-- 2021年4月5日 (一) 07:15 (UTC)
可以临时授权管理员,历史上有过先例,所以在迫切需要的时候,应该也可以临时授权界管。--安忆Talk 2021年4月5日 (一) 07:23 (UTC)
我相信當初從管理員拆分出介面管理員有一定的道理,如果提案通過,那麼拆分還有什麼意義呢?臨時授權管理員又是另一回事了,因為管理員和介面管理員的業務內容不同,雙重授權必須要從許多方面考量,但是只依申請者的需求來單一授權,手續就不會那麼繁瑣,畢竟臨時授權可能是緊急的,如果從太多方面考量,時間必定會被拖延。這是我的個人意見。-- 2021年4月5日 (一) 17:59 (UTC)
(-)反对提案,不明白「达到逻辑和运作上的自洽」是甚麼意思,根本上介面管理員跟管理員做的事大都有所分別,如果一個人被信任在有權限編輯介面,不代表他/她能解決編輯爭議且能獲得Special:UserGroupRights#sysop中非常多的權限(不止上面列舉的那些)而不濫權。雖然不知道設立這方針時是怎麼想的,但我覺得介管不須管理員權限才能申請也是因為希望兩者是分工合作。--Sun8908 怯就輸一世 2021年4月5日 (一) 12:27 (UTC)
不赞同。理由同痛心疾首和空气小猫。我认为只要可信任+有技术就可以当介面管理员。目前还没有到需要先当上管理员来证明可信度的地步。至于权限不足,也不是什么事情都不能做,而且可以由介面管理员提出编辑请求,让管理员协助。--dqwyy (talk) 我们终将成为枫音乡的过客 2021年4月6日 (二) 06:58 (UTC)
我還是覺得直接讓介面管理員擴權就可以。SANMOSA Σουέζ 2021年4月7日 (三) 05:36 (UTC)
@Sanmosa早在近三月前,我便问过了编辑类权限。但连编辑类权限都要不来,更不要说其他杂七杂八的权限。--安忆Talk 2021年4月8日 (四) 05:08 (UTC)
我認為這是單純因為你使用個人名義請求的緣故。如果有社群共識的話,我估計可能會有所不同。SANMOSA Σουέζ 2021年4月8日 (四) 05:10 (UTC)
我也是这么认为的,所以才有了之后的几个提案,但现在看起来还是不太可行。--安忆Talk 2021年4月8日 (四) 05:18 (UTC)
  • @sanmosaAnYiLin: 我建议,可以授予界面管理员目前没有的editcontentmodel、move、move-subpages和suppressredirect四个和界面调整直接相关且相对不敏感权限。删除权限让人联想到页面的存废,或许太过敏感,可以日后再说。--痛心疾首 2021年4月10日 (六) 07:56 (UTC)
    同意。可以一步一步來。SANMOSA Σουέζ 2021年4月10日 (六) 09:32 (UTC)
    (✓)同意。根据界面管理员实际,我提出了下面的条文,以一劳永逸地解决上述大部分问题,请各位参考:SanmosaAnYiLin痛心疾首DqwyySun8908Pseudo ClassesAINH
現行條文

介面管理員持有下列權限:

  • editinterface︰修改MediaWiki名字空間頁面。
  • editsitecss︰修改MediaWiki名字空間下之CSS頁面。
  • editsitejs︰修改MediaWiki名字空間下之JS頁面。
  • editsitejson︰修改MediaWiki名字空間下之json頁面。
  • editusercss︰修改用戶名字空間下之CSS頁面。
  • edituserjs︰修改用戶名字空間下之JS頁面。
  • edituserjson︰修改用戶名字空間下之json頁面。
  • oathauth-enable︰可以開啟雙重認證(2FA)。
提議條文

介面管理員持有下列權限:

  • editcontentmodel:编辑页面的内容模型。
  • editinterface︰修改MediaWiki名字空間頁面。
  • editsitecss︰修改MediaWiki名字空間下之CSS頁面。
  • editsitejs︰修改MediaWiki名字空間下之JS頁面。
  • editsitejson︰修改MediaWiki名字空間下之json頁面。
  • editusercss︰修改用戶名字空間下之CSS頁面。
  • edituserjs︰修改用戶名字空間下之JS頁面。
  • edituserjson︰修改用戶名字空間下之json頁面。
  • move-subpages:可以在移動主頁面時一併移動子頁面(上限100個)。
  • oathauth-enable︰可以開啟雙重認證(2FA)。
  • suppressredirect:可以移動時並不保留重定向。
  • templateeditor:编辑保护级别为“仅允许模板编辑员和管理员”的页面。
请各位审阅。--悔晚齋臆語) 2021年4月10日 (六) 14:57 (UTC)
(-)反对新增不是只有管理員擁有的權限,請留意介面管理員是能編輯全站CSS或JavaScript頁面的使用者群組,與編輯模板無關,更何況這兩個使用者群組的授權標準不同,如有需要另行申請即可。 2021年4月10日 (六) 15:11 (UTC)
  • (?)疑問可不可以设立新的CSD供界面管理员快速删除需要删除的页面?还可以设立类似“快速编辑请求”,界管提出后,除非明显破坏或违反方针,管理员不得驳回? ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月11日 (日) 03:41 (UTC)

模板修訂建議[编辑]

最近參照一下英維,留意到{{refimprove}}模板下有一行可讓用戶透過搜尋平台(Google、JSTOR)搜索該條目相關而可能有用的參考資料(即類似於{{notability}}的那段「來源搜索」)。小弟認為既然段首模板用意旨在讓其他用戶為條目加入更多參考資料「以彰顯其關注度」,現提議修訂如下:

現有模板

(未有相關內容)

修訂建議

在date參數前加入以下字句:
來源搜索:「條目名稱」—網頁 · 新聞 · 書籍 · 學術 · 圖像 · JSTOR
(連結已刪去,與{{notability}}做法類似)

歡迎討論。—小文人(見山客棧) 2021年4月4日 (日) 13:47 (UTC)

从最终得益的角度,加上也没什么不好。而如果要加,{{blpunsourced}}{{blpsources}}{{unref}}{{onesource}}{{primarysources}}{{third-party}}{{or1}}这些都应该加上,且前三个优先级更高。另外这几个模板也经常同时使用,之间的冗余问题,以及如何在{{issues}}中展示都需要解决。->>Vocal&Guitar->>留言 2021年4月5日 (一) 02:09 (UTC)
先從不太常用的模版開始試用也是有的。--Temp3600留言) 2021年4月10日 (六) 18:59 (UTC)
(+)傾向支持:没什么问题。--安忆Talk 2021年4月5日 (一) 02:25 (UTC)
有個疑惑。像遊戲條目經常有這种情况:作品在中文圈人氣不高甚至約等於零,用條目名(中文)搜没什麽結果,用原文(西文)搜索結果一大堆。如果創建者搞了個中文條目名,而巡查員又是搜中文没结果挂{{Notability}}的,那標籤上搜尋工具基本就等於廢的。推而廣之,不少非中文圈的事物都有這類問題。所以,能不能在模板文檔和TW里推廣一下,允許挂板者手工指定搜尋字串,或者輸入en自動套用(或將來他人連結WD後自動套用)Wikidata上的英文名等。此處不得不羡慕英文世界語言+出版業發達,哪怕日本獨佔作品都有不少可用文獻。--洛普利宁 2021年4月10日 (六) 19:19 (UTC)

表格標題背景與文字顏色[编辑]

電視劇(韓劇、日劇等)、電影、人物傳記等條目內列表標題上色容許範圍是否能有個標準?且大量列表上色都未確保文字和背景的對比達到WCAG 2.0AA等級(如可能則達到AAA等級)

每次修改都遇到「愛上色魔人」都甩一句沒有規範或遵循前人寫死風格別跟著闖紅燈)而不聽勸造成編輯戰。

根據顏色及行內圖像,「在條目正文及表格之中,禁止手動或使用模板將文字染成某種特殊的顏色,可以接受的情況僅限於資訊框中。這一方面是為了減輕伺服器負擔以及方便後來編輯者的維護,另一方面是為了方便色盲、色弱或使用黑白版本的讀者閱讀文字。只有在背景顏色可幫助闡釋條目內容,且沒有其他更佳的表達方式時,才可對表格或其他的內文元素加入背景顏色。」但仍需遵守少用顏色來表達。--