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

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

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

Breezeicons-apps-48-cantor.svg

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


發表前請先搜索存档,參考舊討論中的内容可節省您的時間。
公告板
# 話題 發言 參與 最新發言 最後更新(UTC+8)
1 專題命名空間(第二點五至四階段) 31 8 Xiplus 2021-05-06 11:45
2 專題命名空間(第五至六階段) 58 10 A2569875 2021-05-09 03:25
3 偽命名空間(階段一:設立前) 110 13 A2569875 2021-05-06 12:14
4 偽命名空間(階段三:設立後續) 22 5 A2569875 2021-05-06 12:09
5 WP:捷徑指引草案修訂 23 4 A2569875 2021-05-04 14:46
6 頁面命名一致性的通用(普遍性)條文 1 1 Jimmy-bot 2021-05-10 23:37
7 關於Wikipedia:命名常规 (音乐) 108 19 Milkypine 2021-05-09 23:10
8 有關新增偽命名空間的提議 27 10 LuciferianThomas 2021-05-01 08:59
9 模板颜色相关规范 72 18 A2569875 2021-05-11 00:53
10 设计一个制度解决部分速删模板挂不上去的页面的删除问题 97 9 A2569875 2021-05-11 21:13
11 限縮{{电视节目的变迁}}模板使用範圍 20 8 LuciferianThomas 2021-05-06 06:13
12 设立过滤器禁止将维基百科用作来源 21 9 Wolfch 2021-05-03 23:01
13 订立编辑松相关规章制度 54 19 Ericliu1912 2021-05-06 08:09
14 訂立影片加入相關指引 23 8 Sanmosa 2021-05-06 09:54
15 关于“个人贡献”之“机械翻译工具”所衍生问题相关讨论及方案探讨 33 9 維基百科最忠誠的反對者 2021-05-09 23:42
16 参考英文指引,为页面分类指引引入可查证性的要求,同时引入Uncited category维护模板的提案 77 18 Antigng 2021-05-09 23:19
17 WP:封禁方针,WP:傀儡增修 1 1 Jimmy-bot 2021-05-10 16:14
18 再次推动破坏者(LTA)成为名字空间 19 10 羊羊32521 2021-05-05 19:18
19 修改拉票与游戏维基规则为不要拉票与不要游戏维基规则,并规范此类命名 16 10 Sanmosa 2021-05-04 10:10
20 修订Wikipedia:命名常规 (化学) 1 1 Jimmy-bot 2021-05-10 00:14
21 有關WP:CSD#O1 3 3 Super Wang 2021-05-03 10:30
22 修订CSD#G14 11 7 Pseudo Classes 2021-05-05 16:36
23 为什么点开新链接时不打开一个新窗口 3 3 Matt Zhuang 2021-05-03 22:40
24 格式手冊對於國籍的規定有缺陷,有用戶藉此刪除知名人士的前國家國籍 26 10 Sanmosa 2021-05-09 20:10
25 「格式手冊/兩岸四地用語」之國籍章節規定"PRC國籍"應該直接寫為"中國國籍"的中立性問題 21 6 Barter84 2021-05-11 19:47
26 大量條目的標誌被無故刪除 41 17 Sanmosa 2021-05-11 12:46
27 放寬维基百科:維基榮譽新人獎勵的獲得條件 10 5 Temp3600 2021-05-11 13:13
28 修改WP:命名常规#书名号 17 7 Ericliu1912 2021-05-11 22:00
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時,
請先檢查設定是否有誤

專題命名空間(第二點五至四階段)[编辑]

[編輯此導航模板]

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

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

本討論的各階段分為:

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

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

專題命名空間通過,剩餘細節獨立討論。臺灣杉在此發言 (會客室) 2021年1月11日 (一) 11:20 (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)

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

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

前几天发现WikiProject:传统百科全书条目因为页面移动后造成大部分子页面出现错误,目前已经修复一部分--百無一用是書生 () 2021年3月16日 (二) 02:37 (UTC)
(?)疑問@Shizhao:還有多少部分需要修正,有沒有例子,或列表?-- 五歲抬☎️·☘️) 2021年5月6日 (四) 02:51 (UTC)
WikiProject:传统百科全书条目下的所有json子页面--百無一用是書生 () 2021年5月6日 (四) 03:33 (UTC)
JSON不支援重新導向,所以所有連入都需要進行修正。--Xiplus#Talk 2021年5月6日 (四) 03:45 (UTC)

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

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

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

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


本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
※註:第二點五階段還有東西在詢問。-- 五歲抬☎️·☘️) 2021年5月6日 (四) 02:58 (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)
補:R2修改內容:
現行條文

R2. 跨名字空间重定向

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

R2. 跨名字空间重定向

包括以下幾種類型:
  1. 从条目名字空间指向非條目名字空间的重定向(包括將用户页从条目名字空间移動至用户页名字空间時遺留的重定向);
  2. 从草稿名字空间指向非草稿名字空间的重定向;
  3. 從計畫命名空間(Wikipedia)指向維基專題命名空間(WikiProject)的重定向;及
  4. 從維基專題命名空間(WikiProject)指向計畫命名空間(Wikipedia)的重定向。
經社群同意設立的偽命名空間屬於本規則之例外。
注意:有时新加入的维基人偶尔会在主条目空间誤建用户页。使用“移动”页面工具将用户页移回用户名字空间会保留页面历史,在删除遺留的重定向頁前,考虑保留一到两天;草稿重定向速删前,请确保草稿已经完成其作用,并且草稿的历史已经合适地移动到相应的正式页面。
  • 使用模板{{d|R2}}或{{d|interwk}}。

以上。SANMOSA Σουέζ 2021年4月17日 (六) 04:12 (UTC)

Module:Template:Delete/data模組的對應修改見User:Sanmosa/R2模組SANMOSA Σουέζ 2021年4月17日 (六) 04:24 (UTC)
現時有3502個WP->WPJ的重新導向,33個WPJ->WP的重新導向。--Xiplus#Talk 2021年4月17日 (六) 05:07 (UTC)
上面的結論有指明「清理連入頁面後刪除現有跨WP與PJ空間的捷徑重新導向」,所以應該需要bot,再不然發通知邀請社群協力清理也可。SANMOSA Σουέζ 2021年4月17日 (六) 11:00 (UTC)
(!)意見:“2. 将用户页移出条目名字空间时遗留的重定向”真包含于“1. 由条目名字空间指向非條目名字空间的重定向”,可以删去。另外那个看起来怪怪的,建议删去。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月20日 (二) 04:57 (UTC)
@羊羊32521:(1)1是(條目命名空間)→(非條目命名空間),2是(非條目命名空間)→(條目命名空間),2不能刪。(2)完成。SANMOSA Σουέζ 2021年4月21日 (三) 03:38 (UTC)
查CSD历史,R2最初加入于Special:Diff/284065通过将用户页移出条目名字空间而建立的重订向。 (有时新的维基人偶尔会在主条目空间创建用户页。使用“移动”页面工具将用户页移入用户名字空间会保留页面的历史,考虑在删除作为移动结果的重定向页前,保留一到两天。) 所以是说:①在主名字空间建立用户页;②将该用户页移动到用户名字空间(留重定向);③快速删除重定向页。故2亦是“(条目名字空间)→(非条目名字空间)”。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月21日 (三) 15:55 (UTC)
阁下这一改意思都变了 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月21日 (三) 15:59 (UTC)
@Sanmosa-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月24日 (六) 14:39 (UTC)
另外我认为WP→PJ可能不适合速删,上方讨论有提到
或者先开机器人把历史遗留问题解决掉 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月21日 (三) 16:08 (UTC)
容許我再多等待三日,上面的提案會稍為調整。SANMOSA Σουέζ 2021年4月21日 (三) 03:38 (UTC)
@羊羊32521:有道理。已再調整。7日後我再重行公示。SANMOSA Σουέζ 2021年4月25日 (日) 08:19 (UTC)
針對「WP→PJ可能不適合速刪」一點,我也曾經表示需要bot處理,但我認為人手逐個處理亦非不可,情況如同enwiki曾經有過的X1,分別僅在於這變成永久措施,並禁止日後同類重新導向的建立。SANMOSA Σουέζ 2021年4月25日 (日) 08:25 (UTC)
@Xiplus:請求WP->WPJ的重新導向及WPJ->WP的重新導向的具體清單。另見上。SANMOSA Σουέζ 2021年4月30日 (五) 06:00 (UTC)
@Sanmosa列表於此,另您想讓我注意什麼?--Xiplus#Talk 2021年4月30日 (五) 06:10 (UTC)
@Xiplus:關於我對速刪WP->WPJ的重新導向的意見。當然我仍然希望有bot能協助清理連入(初步構思:[[WP:AA]]→[[WPJ:BB|WP:AA]]、[[WP:AA|自定義文字]]→[[WPJ:BB|自定義文字]])。SANMOSA Σουέζ 2021年4月30日 (五) 06:15 (UTC)
看起來無問題,不過我個人是覺得有大量連入的重定向就不應刪除,這樣也不需要去修正。--Xiplus#Talk 2021年4月30日 (五) 11:43 (UTC)
注意编辑摘要里也可能引用快捷方式(虽然专题页的引用量可能不会很大)。(▲)同上有大量链入的重定向不应删除-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月1日 (六) 05:49 (UTC)
此類提案應該不太可能涉及「有大量链入的重定向」,如有,請另表列出。SANMOSA Σουέζ 2021年5月1日 (六) 07:57 (UTC)
应该是没有-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月1日 (六) 09:19 (UTC)
178萬6641個頁面需要更新,占全部頁面27%,我認為修復重新導向是不明智的。--Xiplus#Talk 2021年5月1日 (六) 10:01 (UTC)
(:)回應有些是模板連入造成的,修改模板就可能可以大幅減少。—- 五歲抬☎️·☘️) 2021年5月1日 (六) 12:31 (UTC)
我本來也是以為是模板連入造成,但再次檢查後,其實不然,可靠地估計需編輯的頁面至少在156萬以上。--Xiplus#Talk 2021年5月1日 (六) 12:44 (UTC)
@Xiplus:我要求就每個捷徑分別排查連入數,並分別區分模板連入和非模板連入。我不相信大部分此類捷徑都能產生逾100萬的連入。SANMOSA Σουέζ 2021年5月4日 (二) 05:36 (UTC)
沒辦法透過查詢連入來知道是否透過模板產生的連入,自己用搜尋功能比較準。--Xiplus#Talk 2021年5月4日 (二) 07:52 (UTC)
@Xiplus:那能不能就每個捷徑分別給出連入數?我仍然覺得此類捷徑不可能每一個都能產生逾100萬的連入。SANMOSA Σουέζ 2021年5月6日 (四) 01:50 (UTC)
Special:PermaLink/65497881。--Xiplus#Talk 2021年5月6日 (四) 02:13 (UTC)
剛才用正規表達式insource:/\[\[:?WP:MEA\|?/精準匹配結果也至少是130萬 截圖 因為正則會跑很久[1],但相信這只是特定專題這樣而已,大部分的專題連入應該都很少,有的專題甚至無連入。-- 五歲抬☎️·☘️) 2021年5月4日 (二) 06:14 (UTC)
保留這個吧,這個是{{Welcome}}/{{Welcomeip}}的連結之一,當然非常常見。提議加個豁免條款,截至通過日,除本身多於一萬直接連入的常用捷徑豁免快速刪除外其他都機械人修正唄。--LuciferianThomas留言 2021年5月4日 (二) 07:17 (UTC)
这应该要保留,不仅是大量链入,还会导致修改大量用户的讨论页 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月4日 (二) 10:56 (UTC)
我維持我的提案(快速刪除從Wikipedia指向WikiProject的重新導向,並由bot協助清理連入),但可以容許WP:專題/首頁的缺失條目WP:MEA這兩個例外(只有這兩個產生了逾150萬的連入,其餘都少於10萬,而且大部分估計是模板連入,即使假設全部為非模板連入也不會構成太大的工作量),但也就只有這兩個能例外,而且也不便明文規定,因此會走Liangent G15的路綫,只在模組進行限制。@A2569875XiplusSANMOSA Σουέζ 2021年5月6日 (四) 09:27 (UTC)
Module:Template:Delete/data模組的對應修改見User:Sanmosa/R2模組,已在2021年5月6日 (四) 09:33 (UTC)更新。有勞Xiplus檢查對應修改的代碼是否正常。SANMOSA Σουέζ 2021年5月6日 (四) 09:33 (UTC)

参考資料

  1. ^ 圖床連結。此正則會匹配連結到WP:MEA的內部連結或管道|連結。※註:由於/:?/有爾會導致搜索功能錯誤,因此以/:*/替代;由於/\|?/有爾會導致搜索功能錯誤,因此以/[\|\]]/替代。

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

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

  • 以下暫時備註
  1. 方針或指引修訂(一點五階段已修改部分,如有未盡之事宜請在此提出)
    Wikipedia:互助客栈/方针#第一點五階段:內容事實修訂
    Wikipedia:互助客栈/方针#修订CSD#G14
  2. 專題主頁與專題委員會存放處
  3. WP空間中的專題介紹、Help的專題說明
  4. 專題指引存放處
  5. 未調整好的模板或模組
  6. 這幾個月的使用反饋
  7. 其他未盡之事項
-- 五歲抬☎️·☘️) 2021年5月8日 (六) 19:25 (UTC)

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

偽命名空間(階段一:設立前)[编辑]

已佈署:
大部分核心項目皆已佈署,其餘細小部分分開討論。-- 五歲抬☎️·☘️) 2021年5月6日 (四) 04:14 (UTC)
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

[編輯此導航模板]

大部分核心項目皆已佈署,其餘細小部分分開討論。本結關閉,結以待續,以便存檔。如要開新的討論,請開新的二級標題。-- 五歲抬☎️·☘️) 2021年5月6日 (四) 04:14 (UTC)


本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
主要討論
通過:
已通過-- 五歲抬☎️·☘️) 2021年5月6日 (四) 03:00 (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年5月6日 (四) 03:00 (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年5月6日 (四) 03:01 (UTC)
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

  • 我的意見是,如果偽命名空間不會造成「系統性」的重大問題,就可以納入考量。例如佔用其他命名空間、習慣性等等問題,在我眼中看來不是重大系統問題,而且可以透過其他技術手段解決(如上所述)。--臺灣杉在此發言 (會客室) 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)

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

偽命名空間(階段三:設立後續)[编辑]

[編輯此導航模板]

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

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

請討論。臺灣杉在此發言 (會客室) 2020年12月25日 (五) 01:23 (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)

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

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

已結案的議題[编辑]

已結案:
將已結案的討論分出來存檔。-- 五歲抬☎️·☘️) 2021年5月6日 (四) 04:06 (UTC)
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

自動提刪R2
軟重新導向
技術問題處理
提議設立快速刪除標準 O8
將LTA空間設定為noindex
再次推动破坏者(LTA)成为名字空间

以上討論大部分已通過,故標記已結案。-- 五歲抬☎️·☘️) 2021年5月6日 (四) 04:06 (UTC)


本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。
※註:上面有幾個子議題正在準備公示。-- 五歲抬☎️·☘️) 2021年5月6日 (四) 03:57 (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)
  • 說明剩下的第四點,有部分項目正在等待專題、格式手冊、LTA等命名空間的相關議題之討論或公示。-- 五歲抬☎️·☘️) 2021年4月21日 (三) 02:51 (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)
上述第五階段曾於2021年4月14日 (三) 03:45 (UTC) 進入公示階段。-- 五歲抬☎️·☘️) 2021年5月4日 (二) 06:46 (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)
我這個人最沒有主見了,關於「(單曲)」,我上次被百战天虫大說服後[1],覺得很有道理。當然,如果是像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好像已经结束了自行发歌[2]。->>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
@Milkypine:了解,看了一下討論,這個作為共識應該沒問題。 2021年4月12日 (一) 02:42 (UTC)
已查閱,感謝貢獻。--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)

Wikipedia:命名常规 (音乐)公示[编辑]

Ohtashinichiro和平至上LeehsiaoSanmosaTombus20032000百战天虫Kriz Ju生米一粒Pseudo ClassesKodokunaSmileEasterliesAT卡達YumetoSickManWP羊羊32521EdwardAlexanderCrowleyZhaoweizhi0325MoonLight3650HXXXXPunkhippieLouis0921geePeace 621WhykittyMoonshimmer93夜来南风起Fake12345TreasureBabe325Hijk910Jacklamf1d14Ericliu1912NaveradSoftyuSammypanTw drama感謝大家的意見,現將Wikipedia:命名常规 (音乐)公示。 --Loving You Is A Losing Game 2021年4月20日 (二) 07:36 (UTC)

ShingkeiHikki李新阳CHih-See HsiePv163JoJo_appendLopullinenAnYiLinYel D'ohanTemp3600Bigbullfrog1996陳寅恪TenhumantenokPrince of EreborK.Y.K.Z.K.ArivgaoFredYYooApple vTfcheng5597Comrade JohnAdsa562Austin ZhangGracellleeShwangtianyuan星巴克女王金善賢老奋Lilychen1388DrippinpunchKulivLienwingyanBbene98ParistungJoshua ZhanAchanhk由於人數眾多,這邊分開ping相關討論用戶。 --Loving You Is A Losing Game 2021年4月20日 (二) 07:39 (UTC)
  • (?)疑問@Milkypine:看完整體草案,有疑惑的是「對於官方沒有給出羅馬化名稱的日文作品,根據平文式羅馬字羅馬化。」這條,特別指的是日本作品,那麼韓國作品有必要依照馬科恩-賴肖爾表記法將韓文轉換成羅馬字?若有的話,以「보라빛 밤」為例,是要以羅馬字呈現的英文「Pporappippam」為條目名稱,還是按照過去以編者翻譯先到先得、名從主人所相輔相成的WP:NAME規範,維持「紫光夜」的條目名稱?--🍫巧克力~✿ 2021年4月20日 (二) 07:46 (UTC)
    • @卡達:方針有寫到「命名音樂條目時,優先使用最為通用的中文名稱命名。」,所以一定可以被命名為「紫光夜」。如果沒有中文名稱,則是對其外文依序進行處理(例如가시나因為有官方名稱所以使用「Gashina」)。基本上日韓語歌如果沒有英文歌名,一定都會有個中文名稱(例如24小時也不夠),這項提議也是針對「稀有狀況」做處理 --Loving You Is A Losing Game 2021年4月20日 (二) 10:04 (UTC)
(?)疑問「對於官方沒有給出羅馬化名稱的日文作品,根據平文式羅馬字羅馬化」是不是代表「リスク」這樣的詞語如果沒有官方羅馬化名稱,就要寫成「risuku」?還有,建議在這一條裏不要用《不適任者》這首使用中文作為條目標題的歌作為例子。--【和平至上】💬 2021年4月23日 (五) 14:36 (UTC)
@和平至上:如果我有更好的例子我早就改了ˊ_>ˋ,我的歌單就46和宇多田光,剩下的動漫歌也有一堆常用中文,會用到這條的你該問樓上那些人。
常理來講「リスク」是「risk」,不會有人故意寫成「risuku」(麥當勞寫成馬哭都納魯兜的畫面太美我不敢想)。這條既然有歧異我做了修飾,請參考。 --Loving You Is A Losing Game 2021年4月24日 (六) 12:47 (UTC)
現在這樣沒有問題了(雖說平文式羅馬字好像沒有提到外來語的處理方法)。--【和平至上】💬 2021年4月24日 (六) 13:04 (UTC)
這邊使用「羅馬化」這種曖昧的詞也是為了處理這類問題,不過加上羅馬拼音方式倒是又造成沒有料想到的問題。 -Loving You Is A Losing Game 2021年4月24日 (六) 15:57 (UTC)
  • 古典音乐“作品在体裁内的序号+作品体裁+作曲家名字。序号使用「阿拉伯数字」,前面有「第」字;作曲家名字放在半角括号内,括号之前有一个半角空格”规定与已有方针维基百科:命名常规矛盾。维基百科:命名常规要求 使用常用名称。例如(柴科夫斯基的)第一钢琴协奏曲、(贝多芬的、德沃夏克的)第九交响曲等相对于第1号钢琴协奏曲、第9号交响曲是通常使用的名称,可以通过搜索引擎验证。这一草案与命名常规相抵触,却又声称“本方針為Wikipedia:命名常规的補充,而非替代”。--如沐西风留言) 2021年4月24日 (六) 16:22 (UTC)
    • @如沐西风:ˊ_>ˋ這方面還請你和上面擅長古典音樂的大大們溝通。話說就算維基以常用優先,還會有很多要求,例如這一切的開端「使用小寫」,那常用名稱要求按照常用格式也不是什麼太大問題,(話說使用繁體搜尋,結果是相反過來,所以這方面究竟誰比較常用,可能還要看實體書籍等其他方面來參考)。 --Loving You Is A Losing Game 2021年4月25日 (日) 12:35 (UTC)
    那句话已经删了( -- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月29日 (四) 15:54 (UTC)
  • @如沐西风:說實話,這段敘述“本方針為Wikipedia:命名常规的補充,而非替代”和上述內容有衝突嗎?大家都知道要按照常用,但命名常规自己本身也有對常用的規定(例如小寫、縮寫等)。而閣下提到的例子在這邊我也得出相反結果,那麼該以何者為基準?如果案例很明顯,我絕對贊成「第九交响曲」,但當不同名稱都有一定程度的使用比例,那麼就需要方針去處理,總不能把異己打死吧。 --Loving You Is A Losing Game 2021年4月29日 (四) 16:04 (UTC)
    • 新订规则不应该与已有规则相冲突,不然将来执行的时候肯定有问题。比如“第九交响曲”和“第9號交響曲”,维基百科:命名常规Wikipedia:命名常规 (音乐)(假如通过)给出了不同的规定,听哪个?新修规则应该明确一个大方向,要么细化已有规定,要么为已有规定做补充;如果觉得现有规定不对,那么就去修维基百科:命名常规。不要搞出矛盾来。留不留那句“本方針為Wikipedia:命名常规的補充,而非替代”,新设方针都不该和已有方针冲突,不然总得有一个变成废纸。
    • 即便退一步讲,就算“第9號交響曲”是港台地区的惯用名称,“第九交响曲”是大陆的惯用名称,维基百科:命名常规已经做出了规定:维基百科:命名常规#中文用詞差異的處理:先到先得“應维持條目第一個重要版本所采用的標題(须符合本方針其他命名规则)”。这种情况下条目叫什么,不该Wikipedia:命名常规 (音乐)说了算。不看维基百科:命名常规,强行要求古典音乐必须以某一命名方式为准(不管是港台的命名还是大陆的命名),这才是不按方针处理,“把異己打死”。--如沐西风留言) 2021年4月29日 (四) 16:17 (UTC)
「新订规则不应该与已有规则相冲突」並非,前提是刪去“本方針為Wikipedia:命名常规的補充,而非替代”一句。子命名常規的適用優先性高於母命名常規,情況如同關注度指引。SANMOSA Σουέζ 2021年4月30日 (五) 05:31 (UTC)
@Sanmosa:所以只要刪除這段內容,就沒有問題對吧。這邊我是參考其他命名常規,沒有想到會造成這樣的影響。 --Loving You Is A Losing Game 2021年5月1日 (六) 14:38 (UTC)
  • 上面的問題是解決了,但我仍反對「條目名稱須符合『大調大寫,小調小寫』」的規定。大調和小調依習慣均應大寫。SANMOSA Σουέζ 2021年5月4日 (二) 05:57 (UTC)
@Sanmosa:請問就你個人看來,這個習慣應該根據「專業領域」還是「普羅大眾」? --Loving You Is A Losing Game 2021年5月4日 (二) 16:33 (UTC)
於我而言,這是完全不需要討論的,因為我自己本身就質疑「在樂理的學習和考試中以及大多數的實踐中,都應當使用『大調大寫,小調小寫』的原則」的真實性及全域性。SANMOSA Σουέζ 2021年5月5日 (三) 05:23 (UTC)
  • “本方針為Wikipedia:命名常规的補充,而非替代”这个应该是最基本的原则吧,Wikipedia:命名常规 (音乐)不应该与维基百科:命名常规有冲突。而且看前面的例子,“第九交响曲”和“第9號交響曲”的讨论,只是因为简体和繁体的常用名称不同,才会有冲突,但并没有违背维基百科:命名常规中所说的“使用常用名称”这个规定。这种情况下除了先到先得之外,还需要把另外一个名称设置重定向页面,这样其实就相当于“第九交响曲”和“第9號交響曲”两种名称都算常用名称,都可以使用。生米一粒留言) 2021年5月8日 (六) 18:51 (UTC)
  • 草案关于古典音乐的若干规定仍然不够完善,有一些漏洞。
  • “作品在体裁内的序号+作品体裁+作曲家名字。序号使用「阿拉伯数字」,前面有「第」字;作曲家名字放在半角括号内,括号之前有一个半角空格。”这条规定会导致一些很诡异、别扭的结果。例如“弦乐小夜曲”条目需要据此规定移动到“第13号夜曲 (莫扎特)”(Serenade Nr. 13 für Streicher in G-Dur),一个使用频率很低的名字。真的要这样做吗?
  • “某些不寻常的体裁应使用约定俗成的名字。例:圆号三重奏 (勃拉姆斯)、木管五重奏 (贝多芬)”。什么叫做“不寻常的体裁”,交响曲和奏鸣曲之外都是“不寻常的体裁”?木管五重奏其实蛮常见的吧,不知道“不寻常”在哪里,又由谁来裁断呢?再说,什么叫做“使用约定俗成的名字”?规则给的两个例子都是用 体裁+作曲家名字来命名,是不是必须这样“约定俗成”呢?
  • “如果作曲家只创作了一部该体裁或享有该名称的作品,则序号可以省略。例:庄严弥撒 (贝多芬)、弦乐八重奏 (门德尔松)”这一条莫名其妙。庄严弥撒 和 弦乐八重奏 恐怕不是“序号可以省略”,而是没有序号(从上下文来看这里的 序号 指的不是作品号 opus number)。看上去更像是后面一条“如果该作品的序号不详、有争议或无可靠来源使用,则可以用作品号或调性。調性優先,若無須消歧義,作曲家名字可以省略”的例子(“该作品的序号不详 或 无可靠来源使用”)。
  • 根据这些规定来看一下“鱒魚五重奏”的命名,很好玩的样子。体裁是钢琴五重奏,好像没有序号。由于没有序号,不能按第一条命名为第X号钢琴五重奏。那钢琴五重奏算不算一个“不寻常的体裁”呢?不知道,如果算“不寻常的体裁”,要用“约定俗成的名字”;“鱒魚五重奏”好像挺通用的,但是规则里“约定俗成”的两个例子都是用体裁加作曲家名字命名,所以应该叫“钢琴五重奏 (舒伯特)“?慢着,按第六条“如果该作品的序号不详、有争议或无可靠来源使用,则可以用作品号或调性。調性優先”,好像又该叫“A大调钢琴五重奏 (舒伯特)”。但是如果按第四条“如果該作品的名稱是獨一無二的,且無須消歧義,則作曲家名字也可以省略”,好像“鱒魚五重奏”就可以?规则自己跟自己打架,怎么办?
  • 或者换个例子,幻想交響曲。没有序号,不能用第一条“第X号交响曲”。交响曲这个体裁挺寻常的,跳过第二条。那么是按照“如果作曲家只创作了一部该体裁或享有该名称的作品,则序号可以省略”命名为“幻想交响曲”吗?(那为什么不能有“悲怆交响曲”而只能有“第6号交响曲 (柴科夫斯基)”呢?)还是说得按照第六条序号不详的情况命名为“C大调交响曲 (柏辽兹)”?
  • 再来换个角度看。草案里面“古典音樂作品”实际涵盖范围相当狭窄。没有歌剧或者歌剧选段。巴洛克时代之前的音乐好像完全不涉及。规则好像也不怎么关心西方音乐史,不考虑 标题音乐(Program music)或者非标题音乐的不同情况(规则都没有 标题音乐 四个字出现)。草案中古典音乐部分的规则不成体系,主要是以举例的方式来说明,导致一些自相矛盾、规则不清的问题。很多问题也没有涵盖到。比如不同译名的问题:图兰朵还是杜兰朵,爱之甘醇还是爱情灵药?条目应该叫蓝色多瑙河圆舞曲,还是叫蓝色多瑙河,还是照德文名翻成“在美丽的蓝色的多瑙河上”?
  • 维基百科:命名常规确实有“如果条目所属的专门领域存在具体命名规定,应遵照该规定执行,而不再按照命名惯例的要求确定名称”的规定,上次说的问题草案确实有权力规定。但是“第6号交响曲 (贝多芬)”这样的规定恐怕未必是个好规定。大陆通常用的是“第六交响曲”而非“第6号交响曲”这一类的命名,可以参看《中国大百科全书》第一版的音乐卷等文献。要是强制使用“第6号交响曲 (贝多芬)”可能还得必须用正体/繁体字,不然“第6号交响曲”都不大好搞字词转换;或者,中文维基要钦定繁体/正体和简体都必须用“第6号交响曲 (贝多芬)”,禁止字词转换?--如沐西风留言) 2021年5月5日 (三) 15:24 (UTC)
    需要考量命名一致性和WP:MOSNUM的問題。SANMOSA Σουέζ 2021年5月5日 (三) 23:40 (UTC)
    會加入古典音樂相關內容也是有往例可以參考,但就目前來看,只能說是我思慮不周。我先將古典音樂相關內容移除,專注討論現代音樂,古典音樂的部分則先暫緩討論。 --Loving You Is A Losing Game 2021年5月6日 (四) 13:58 (UTC)
ShingkeiHikki李新阳CHih-See HsiePv163JoJo_appendLopullinenAnYiLinYel D'ohanTemp3600Bigbullfrog1996陳寅恪TenhumantenokPrince of EreborK.Y.K.Z.K.ArivgaoFredYYooApple vTfcheng5597Comrade JohnAdsa562Austin ZhangGracellleeShwangtianyuan星巴克女王金善賢老奋Lilychen1388DrippinpunchKulivLienwingyanBbene98ParistungJoshua ZhanAchanhk如沐西风由於人數眾多,這邊分開ping相關討論用戶。 --Loving You Is A Losing Game 2021年5月8日 (六) 07:18 (UTC)
英维的音乐命名常规中,古典音乐长度占了一半,可见古典音乐方面需要较为复杂的命名常规,而中维无法短时间内拟出。为保证现代音乐部分正常生效,建议排除古典音乐部分进行公示。-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月8日 (六) 07:41 (UTC)
當初想說有現成的可以用,沒想卻是自討苦吃OTZ。 --Loving You Is A Losing Game 2021年5月8日 (六) 07:43 (UTC)
现在看来,虽然那是现成的,但并没有约束力,编者可以比较灵活地处理。一旦升级为指引,具有约束力,就得考虑各种情况……-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月8日 (六) 08:58 (UTC)
  • 有个疑问,“符號使用”章节的“斜線”部分有个例子Angelic Angel/Hello,細數繁星,这里是遵循了“不存在任何全形符號,則僅應用半形斜線”所以使用半形斜線吗?我的问题是:1. 細數繁星这几个汉字算不算全形符號?2. 关于逗号如何处理,有没有规定?感觉上这里的逗号,要么用全形(中文用法),要么在半形逗号后面加个半形空格(英文用法)?生米一粒留言) 2021年5月8日 (六) 19:23 (UTC)
还有个疑问,虽然可能不是完全属于音乐条目,但也不值得另外单开一个话题,就在这里一并问了吧:偶然间发现的,简体的避难所和繁体的避難所(不要跳转)两个页面同时存在,请问这种情况该怎么处理?生米一粒留言) 2021年5月8日 (六) 19:45 (UTC)
  • 將其中一個的標題改為消歧義即可。 2021年5月8日 (六) 20:24 (UTC)
  • @生米一粒:字也算符號......,既然閣下認為字是符號,那我改為「標點符號」好了。關於符號的使用,還是要考慮作品名稱,例如少了我,很空虛官方中文為大寫,那麼命名時就該使用大寫 --Loving You Is A Losing Game 2021年5月8日 (六) 23:12 (UTC)
要不要增加一条关于逗号的规定?QQ音乐上这首歌的歌名是半形斜線,前后都有空格,半形逗号后面也有个空格。我主要的疑问在于这个例子里,半形逗号后面没有空格,好像既不符合英文的常规用法,也不符合中文的常规用法,也不符合这首歌的官方歌名用法。生米一粒留言) 2021年5月9日 (日) 08:43 (UTC)
這邊可以參考同樣案例〈HANN (Alone)〉,如果〈Angelic Angel/Hello,細數繁星〉在多個平台都使用「/」和「,」,那就該使用「/」和「,」。關於半形逗号后面要不要空格,則是看作品名稱如何安排。 --Loving You Is A Losing Game 2021年5月9日 (日) 15:10 (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

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

通過:
@Sanmosa羊羊32521MilkyDeferYFdyh000:通過,請開始實行各修訂。--LuciferianThomas留言 2021年4月30日 (五) 04:13 (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)

初步定案[编辑]

建議為命名常規和關注度指引設立專門的捷徑偽命名空間,其中命名常規的專門捷徑偽命名空間為「NC:」,而關注度指引的專門捷徑偽命名空間則為「NT:」。SANMOSA Σουέζ 2021年4月14日 (三) 13:24 (UTC)

(打撈)--LuciferianThomas留言 2021年4月23日 (五) 01:31 (UTC)
@LuciferianThomas:請記得也把存檔頁的內容刪除,以免之後存檔有重複內容。--Xiplus#Talk 2021年4月23日 (五) 01:40 (UTC)
好滴--LuciferianThomas留言 2021年4月23日 (五) 01:58 (UTC)
Sanmosa由於超過七日無新意見, 公示7日,2021年4月30日 (五) 01:33 (UTC) 結束。--LuciferianThomas留言 2021年4月23日 (五) 01:33 (UTC)
若有條目也叫NC,會不會對沖呢? 2021年4月27日 (二) 09:07 (UTC)
NC不是名字空間,NC加冒號「NC:」才是名字空間。-- 五歲抬☎️·☘️) 2021年4月28日 (三) 04:14 (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)
@Sanmosa:「影響範圍過大」和「不能體現所有使用者的意見」已經不是您所指的單純問題了。您發起民調來蒐集意見我沒意見,但是要將投票結果作為共識執行,我不能接受。當然您要發起與否是您的自由,如果社群能夠接受結果,那我也沒話說,只是還請留意,我不能接受投票不代表我反對投票,也不代表我變相剝奪視覺障礙人士的合理閱讀體驗,這只是表達我的個人意見,而我的意見是對於此種議題,應該有比投票更能體現共識的方式。 2021年4月12日 (一) 02:31 (UTC)
發起投票的最主要目的是在討論各方意見很大程度上分歧時確立討論的大方向,如果連大方向都不能確立,我難以相信討論能有效持續。SANMOSA Σουέζ 2021年4月14日 (三) 13:19 (UTC)
@Sanmosa:確立討論的方向,請使用民調而非投票。 2021年4月14日 (三) 18:01 (UTC)

變通提案[编辑]

以下是小弟的變通提案:

現行條文

颜色及内联图像

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

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

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

提議條文

颜色及内联图像

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

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

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

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

同理,禁止在正文中使用内联图像(例如在文字中出現Symbol support vote.svg這樣的图像)什錦字型繪文字但符合以下條件圖像則不在此限:

  • 與正文內容密切相關,不使用就無法(或很難)準確闡釋條目內容;
  • 編者有理由相信電腦無法正常解碼和顯示;
  • (非強制)有對應Unicode代碼的天然語言字符或專業符號,或者符合知名度要求的人造語言的字符,或者以LaTeX製作的科學表述。

此外,在表格及信息框中也可以使用内联图像

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

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

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

暫時認為閣下的提案影響太多:各類模板應限制至條目導航及各類infobox。另建議禁止任何WCAG 2.0中兩種低於2.0的配色分別用於背景及正文。--1233 T / C 2021年4月14日 (三) 02:33 (UTC)
1233已修訂為「同一表格、導航模板或信息框模板只能使用一種邊界色、一種標題欄背景色、一種標題欄文字色,且總共不能超過三種顏色」。另外,能否解釋一下怎樣才算「WCAG 2.0中兩種低於2.0的配色」?📕📙📒📗📘📚📖 2021年4月14日 (三) 21:37 (UTC)
    • 拿這個:[3]--1233 T / C 2021年4月16日 (五) 08:32 (UTC)
  • (-)反对只能使用三種顏色。Template:元素週期表會無法呈現,更不用說縮圖型導航的Template:NavPeriodicTable,此舉同時也導致了之前色弱友善元素週期表顏色配置Template talk:Isotope nav#同位素模板顏色更換全部白討論了,浪費了社群資源。 考量到需要區分元素本身特性,以下主題有許多層級需要區分
    1. 元素週期表(Template:元素週期表Template:NavPeriodicTable
    2. 元素穩定性表(Template talk:Isotope nav
      • 大量穩定同位素、僅一種穩定同位素、僅有觀測上穩定同位素、最穩定同位素半衰期萬年、半衰期千年、半衰期1年或以下、半衰期以日計、半衰期以時計、半衰期以秒計、目前未發現同位素(如Uue) 等至少10種等級
    3. 元素分區(Template:元素週期表_(正文)#範例
    要區分5種以上等級,禁用顏色根本強人所難,無法實行,或實行會導致元素週期表等相關條目無法準確製作示意圖表。-- 五歲抬☎️·☘️) 2021年4月14日 (三) 19:05 (UTC)—- 五歲抬☎️·☘️) 2021年4月15日 (四) 02:24 (UTC)
    同時也反對禁用內連圖像。{{缺字}}、或Unicode未收錄符號、特殊的語言(如克林貢語)和特殊數學符號(如en:Coxeter–Dynkin_diagram、{{CDD}}),全是內連圖像,禁用的話,全部都難以或無法描述條目了。特別是en:Coxeter–Dynkin_diagram,根本不可能用文字描述代表一個en:Coxeter–Dynkin_diagram,要求只能放在圖表將導致內文難以描述,必須在內文呈現符號再加以說明,這個如果禁的話,那我認為數學公式也該禁。仍然堅持,特殊數學符號是有必要跟文字一起使用的。-- 五歲抬☎️·☘️) 2021年4月15日 (四) 02:24 (UTC)
    A2569875請閣下留意:
    例1:小弟已經特地指定了一個「有正當理由,並且能在討論頁自證有理」的例外條件。閣下以上提到的元素週期表導航模板都屬於「正當理由」,因此不受「最多三種顏色」的限制。
    例2:小弟也指定了例外條件。閣下提及的人造語言字母和數學符號都符合例外的條件,因此不受「禁用內連圖像」的限制。至於Unicode未收錄的符號當中哪些應該禁止,哪些應該允許,都可以慢慢討論。能不能請閣下舉例說明:哪些符號Unicode尚未收錄,卻又在某些條目中非用不可?📕📙📒📗📘📚📖 2021年4月15日 (四) 02:51 (UTC)
    • 關於Unicode尚未收錄符號,需要與文字一同描述的就是特殊數學符號(如上方{{CDD}})、化學符號、其他科學表示符號,而所有{{缺字}}、特殊語言也是Unicode尚未收錄符號;Unicode尚未收錄的Emoji確實不必在條目正文中出現(甚至已收錄之Emoji都不該)
    • 「編者有理由相信電腦無法正常解碼和顯示」不明確,可能會導致編輯戰,例如某個字原先未被已Unicode收錄,因此使用內連圖像,後來某天被Unicode收錄,然而剛收錄時未被廣泛的字體支援,也許在電腦上看可以正常顯示,然而在iPhone上看都成了豆腐塊,因此使用iPhone的用戶將看起來像豆腐塊的文字回退成內連圖像,而電腦版用戶又將內連圖像回退成在iPhone上看都成了豆腐塊的文字,因而導致編輯戰。例如前陣子剛發命名的幾個化學元素之中文字,在Unicode剛收錄等字時,發生被改來改去的現象。
    • CFOP#下兩層(F2L)中「設法在不破壞其他已完成部分,將一柱轉成CFOP F2L type1.pngCFOP F2L type2.png。」不使用內連圖像怎麼描述?「設法在不破壞其他已完成部分,將一柱轉成『清楚辨識到可見之兩個面的中心塊與下方塊是相同的顏色,同時,左側最右上方式底面的顏色、上方為左側面的顏色、右方與該面之中心塊同色且角塊右邊的邊塊顏色與左方的角塊同色且方向相同』或『清楚辨識到可減兩個面的中心塊與下方塊是相同的顏色,同時,左側最右上方式做側面中心塊的顏色、上方為右側面的顏色、右方與底面同色且不可見之面之右側面之角塊的頂部顏色與可見面之左側面之中心塊同色』。」這樣的可怕的文字來描述嗎;
    • 那麼這種又要怎麼辦「當方塊變為
      時」({{模板樣式色塊圖}})→「當方塊變為『方塊下兩層已完成,且頂面顏色在頂面上呈Tetris S.svg(不用圖片無法表達)形狀時,頂面靠近自己本身的地方是不可見面右側面之中心塊顏色,頂面右側前方(靠近不可見面)兩塊與可見之左側側面同色、頂面左側兩塊與可見之右側側面同色....』時」。(-)反对到時許多條目,不限於魔術方塊都要用可怕的東西描述,WP:太長不看,編者不會想看到一堆廢話,條目失去功能。
      關於上述提到的Tetris S.svg,類似的例子例如俄羅斯方塊,你描述Tetris L.svg,文字描述用L型,可是他仍有非常多種變體
      Variations.png
      不使用內連圖像,怎麼準確表達
    • Unicode亦有無助於文字表達的字元,用起來跟Symbol support vote.svg這樣的图像沒有兩樣,例如Unicode字符列表#特殊Unicode幾何圖形列表方塊元素、麻將字元、撲克牌字元(見章節扑克牌#歷史)...等
    • 關於顏色,有的Unicode字元還會自帶顏色,例如Emoji
    • Unicode字符列表#盲文圖案點字該不該禁?「未收錄點字
    ※其他關於顏色或Unicode事項待補;會在找到時補充。
    以上-- 五歲抬☎️·☘️) 2021年4月15日 (四) 04:17 (UTC)
(▲)同上 2021年4月15日 (四) 11:27 (UTC)
魔方问题可以像英语维基百科那样用右侧图像,或者像论文那样<gallery />加“如图1”。一图胜千言,但没看出图像非要内联的理由。而且CFOP F2L type1.pngCFOP F2L type2.png
这三个内连例子真心一点都不大方,图片小小、看着眼晕;图片优势没发挥出来不说,还搞到正文稀稀拉拉的。至于Unicode字符列表这种,特殊字符独占单元格的环境,我认为不算内连。--洛普利宁 2021年4月15日 (四) 17:50 (UTC)
魔術方塊可能不是個很好的例子,那麼我換個例子基礎摺法索馬立方en:Soma_cube),這也難以純粹文字描述。-- 五歲抬☎️·☘️) 2021年4月15日 (四) 21:40 (UTC)
同意Lopullinen的看法。不一定要用內聯圖像,可以用右側圖像或者圖片庫。例如《索馬立方》可以改用如下的圖片庫:
索馬立方》圖片庫
這樣就既不需要使用內聯圖像,也不需要單純依賴文字描述。📕📙📒📗📘📚📖 2021年4月15日 (四) 22:14 (UTC)
  • 仍然堅持會有需要把文字和圖片放在一起的情況,摺紙的你們還沒回應,我將會繼續尋找,補充一個找了一整晚的
(將會陸續補充)
以上-- 五歲抬☎️·☘️) 2021年4月16日 (五) 05:23 (UTC)
(~)補充另外,關於「
」的描述,我認為應該要這樣「方塊下兩層已完成,且頂面顏色在頂面上呈Tetris S.svg形狀時....」不然圖像還要引用旁邊另外圖像,真的很詭異。-- 五歲抬☎️·☘️) 2021年4月16日 (五) 05:40 (UTC)

「設法在不破壞其他已完成部分,將一柱轉成以下兩種形式之一(圖1.1和圖1.2):」

CFOP F2L type1.png CFOP F2L type2.png
圖1.1 圖1.2
  • 這樣一來,魔方的圖案想再放大些都不怕影響排版。
  • 摺紙的案例和索馬立方的案例一樣,可以製作表格或圖片庫,不需使用內聯圖像。
  • 天文學符號完全可以在表格或者Infobox裏面用,不需用作內聯圖像。
  • 中華民國國語那個注音符號,以及那個阿拉伯樂譜符號,都已經符合「與正文內容密切相關,不使用就無法準確闡釋條目內容」的例外條件。
  • 至於PlayStation濱崎步的案例簡直就是邊緣得不能再邊緣了。PlayStation的那句營銷口號,完全可以上傳一張自製圖片來表示,反正像PlayStationCircle.svgPlayStationCross.svgPlayStationTriangle.svgPlayStationSquare.svg這種簡單的幾何符號,是怎麼都達不到原創性門檻的。濱崎步的案例已經涉嫌過量使用非自由圖像,違反《WP:NFCC#3了。
另:@Lopullinen1233:小弟新增了無正當理由禁止使用什錦字型繪文字的條文,請回應。📕📙📒📗📘📚📖 2021年4月16日 (五) 06:19 (UTC)
  • 內文其實禁止更改字體的,不過無意見。--1233 T / C 2021年4月16日 (五) 08:11 (UTC)
  • (:)回應我認為索馬立方摺紙與正文密切相關。天文符號其他例子例如電路符號、化學特殊符號、化學結構式(有苯環的)生物學符號,我不建議在旁邊放成表格,一堆一個小符號整理成表格非常詭異。以及「
    :頂面顏色在頂面上呈Tetris S.svg形狀」的Tetris S.svg亦與正文密切相關。同時,整個連純文字也包成圖片放旁邊表格將會有「無法複製其中文字」的缺點。-- 五歲抬☎️·☘️) 2021年4月16日 (五) 06:27 (UTC)
  • 小整理一下,以便針對點討論
    • 已解決的問題
      • 自身有獨特排版,且為學術界慣例,又需要顏色表達之表格
      • 無法使用現有文字代替的符號(打不出來的字,或者非自然語言表達範疇之記號)
        • 未收錄漢字(如{{缺字}})
        • 數學符號(如{{CDD}})
        • 樂譜記號
        • 特殊的語言
    • 未解決問題
      • 可以用排版代替顏色的表
        • 地質年代表的背景色。
        • 生物保育狀態的背景色。
      • 可以使用現有文字代替的符號
        • 天文符號
        • 化學結構式
      • 具表意功能圖示使用時機
        • 如摺紙圖示
        • 文字不易描述的瑣碎形狀圖示(一句話出現多種時,使用表格反而雜亂)
        • Emoji、繪文字
        • 什錦符號
      • 特殊標語口號
        • 「LIVE IN YOUR WORLD. PLAY IN OURS」(整個做成圖片將會導致文字複製困難)
        • LaTeX
    以上-- 五歲抬☎️·☘️) 2021年4月16日 (五) 07:06 (UTC)
在我看來明文限制使用顏色或內文圖片會造成很多麻煩,更不應該直接限制着色,應當按照情況逐例處理;例如在有用戶提出更好減少使用顏色的情況下,若內容不造成明顯閱讀困難就應儘量以顏色較少的方式處理(即指排版妥當;不應以「比較那個比較方便閱讀」為準則,只要整體不造成閱讀困難即可)。列表條目中適當使用顏色協助用戶進行分類,限制用色比限制着色更實際。--LuciferianThomas留言 2021年4月16日 (五) 09:41 (UTC)
  • 「地質年代表的背景色」和「生物保育狀態的背景色」我在上面已經說過符合例外條件,因此不屬於「未解決問題」。嚴格來說,俄羅斯方塊的圖像也屬於「與正文內容密切相關,不使用就無法準確闡釋條目內容」,只是編者有責任證明非使用內聯圖像不可。
  • 我加入了或者以LaTeX製作的科學表述,以包括數學公式和化學方程式等。
  • 我粗略閱讀了《》、《》等化學條目,裏面的圖像都不算「內聯圖像」。「內聯圖像」是指插入段落之內,文字之間的圖像。但這些條目當中的圖像都是用在段落之間,而非段落之內,因此不符合「內聯圖像」的定義。
  • 天文符號可以在表格或Infobox裏使用,不需使用內聯圖像。
  • 「LIVE IN YOUR WORLD. PLAY IN OURS」這種標語是不是非加入不可?「導致文字複製困難」似乎暗示閣下打算複製粘貼到其他條目,但除了PS條目本身以外,還有哪些條目非有這條標語不可?
  • @LuciferianThomas:限制著色是為了防止出現像某個IP對《追夢 Do Re Mi》瘋狂著色的情況再次出現。而我提出「一種邊界色、一種標題欄背景色、一種標題欄文字色,除非能自證有理」是為了方便執行,盡可能壓制遊戲維基規則的空間。另外,我在上面的提案也有限制用色的條文:「背景色飽和度不能太高」。
歡迎回應。A25698751233LopullinenPseudo ClassesSanmosa蕭漫Lab06 N羊羊32521📕📙📒📗📘📚📖 2021年4月16日 (五) 15:29 (UTC)
  • 關於複製,我指的是會困擾讀者,讀者將無法或難以複製該文字。維基百科不應搞得像那種讓讀者複製不了東西的神秘部落格,且讀者理應要能夠方便地複製「LIVE IN YOUR WORLD. PLAY IN OURS」以便到其他地方利用或查詢其他相關資料,整個包成圖像你是要讀者去研究影像辨識和機器視覺??;另外「有對應Unicode代碼」en:Coxeter–Dynkin_diagram、{{CDD}}沒有對應unicode 代碼,LaTeX也不支援,且由於其抽象性,難以用文字說明代替。另外 我相信應該還有一些數學公式或符號不被unicode與LaTeX支援,但是需要與文字一同描述。—- 五歲抬☎️·☘️) 2021年4月16日 (五) 15:39 (UTC)
總歸一句話,複雜的限制只會更容易被忽略,再加上你遇到例外就加上去、加上去,最後限制越來越多。至少我沒有這麼有耐性看完這些限制,就算看完也好,我也不能確保我不會被混淆。你提議修正條文,就有必要將條文修到完整、易讀的狀態,除非你讓這些條文更加簡潔,否則我(-)反对的立場不會改變。 2021年4月16日 (五) 16:43 (UTC)
不限制著色,但漸層應明文禁制;另覺得表格什麼的不是不能上色,但必須整個條目一致就是了。--LuciferianThomas留言 2021年4月16日 (五) 18:07 (UTC)
我认为维基百科不应搞得花花绿绿的像粉丝部落格。如果「LIVE IN YOUR WORLD. PLAY IN OURS」包装成图像读者能理解,那就不应该使用内连图像;再说这东西复制出来居然是“LIVE IN YOUR WORLD. PLAY IN OURS”,圈叉三角呢,打哑谜?况且stylized包括大小写、颜色、文字大小等等元素,其主要作用也是视觉冲击,所以本来就更适合用图片表示(再用图注说明,其中四个字母置换成为PlayStation的圈、叉、正方、三角标志)。总之简单一句话:图像可以用,但不要放在正文;如果想放在正文,请想想能不能单独提出来:如果提不出来,再想想所谓的“不用图片不行”整句话是否举例过细,对维基百科这种通用百科并无必要;如果真的很重要,业界也常常这样用,那再讨论要不要内连。科学类条目可以制定自己的格式手册,决定哪些图片可以在兼顾排版的情况下,视同文字在正文中使用。但对于大多数条目,要让编者(特别是新编者)从大方向感觉到,维基百科不鼓励使用内连图像。同时也要鼓励编者锻炼文字表达能力:编者作为爱好者可能以为图片很直观,但非圈内读者很可能根本get不到点。(
这个例子要是不配文字,花花绿绿的我还真不知道想表达最下面两层已完成。)--洛普利宁 2021年4月16日 (五) 18:34 (UTC)
顏色和附圖塞內文概念上是一樣的,上面列的都是附圖案例,顏色例如:
在我看來,許多狀況,有加附圖或顏色,比起沒加附圖或顏色,「更有助於幫助讀者了解主題」。反而沒有上面說的那麼嚴重。-- 五歲抬☎️·☘️) 2021年4月17日 (六) 07:51 (UTC)
@A2569875:您说的这篇条目,正好证明内文颜色不必要乃至多余。您举例的下一段就附了个参考文献;此文献是“8+ (green), 12+ (blue), and 16+ (yellow)”这样用纯文字描述的,而显然编者正确理解了文字(先不讨论绿色用#5CB531是不是原创研究)。由此可见,使用纯文字也能起到等价的效果。另一方面,禁止内连颜色不是禁止使用颜色;正确的方法是这样,用侧边图像大大方方地表示。所以我没看出来,直接给文字上色什么时候成了唯一手段。在我看来,图片放到侧边并配上图注详述、正文做一些大方向上的解释,比起使用不知所以的内联图像或颜色,更有助于读者理解主题。PS:感谢提醒,我把这条目正文中的颜色全部移除了(最上面那个是表格的图示,不属于内连的范畴;下面全都在东施效颦)。--洛普利宁 2021年4月17日 (六) 17:42 (UTC)
  • 關於顏色,我覺得沒必要限死三種顏色。{{中国历史}}目前的配色可以追溯到Special:Diff/432308,距今近16年,幾無异议。只要色盲色弱人士能看得清,颜色又不会太抢眼就没关系。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月18日 (日) 13:40 (UTC)
  • 如果不想讓例子增加到這麼多的話,那就是換個方向,讓某些變成不符合(不過看下來,不管是從符合還是不符合,兩邊內容都很多)。我只希望大家在追求顏色自由的同時也能考慮顏色自由亂象,不能因為自己的方便造成別人的困擾。 --Loving You Is A Losing Game 2021年4月20日 (二) 07:01 (UTC)
  • 依然認為不能寫死「禁止」,應該用諸如「不建議」,以免部分領域用色用圖困難。-- 五歲抬☎️·☘️) 2021年5月4日 (二) 13:49 (UTC)
  • (-)反对一刀切式禁止。這樣整個維基百科豈不是甚麼顏色都沒有了?鐵路路線代表色要全部作廢?現有的已經足夠了。--owennson聊天室獎座櫃) 2021年5月7日 (五) 10:14 (UTC)

其他概念[编辑]

我單純希望處理的問題只是背景顏色問題,我認為應當限制每表格的每一格應只使用一種背景色,文字顏色及邊框顏色。與此同時,就應當嘗試制定背景顏色及文字顏色的對比度。--1233 T / C 2021年5月10日 (一) 16:36 (UTC)

设计一个制度解决部分速删模板挂不上去的页面的删除问题[编辑]

目前討論狀態:

-- 五歲抬☎️·☘️) 2021年5月8日 (六) 19:10 (UTC)

参见Wikipedia:互助客栈/求助/存档/2021年4月#请帮忙删除 User:Tranve/工坊/workshop.json,像 JSON 和 Module: 名字空间的页面,速删模板挂不上去。希望可以在方针制度层面解决这个问题。--Tranve () 2021年4月5日 (一) 13:07 (UTC)

[email protected]蟲蟲飛XiplusSunny00217 --Tranve () 2021年4月5日 (一) 13:09 (UTC)
說到這個,才想去WT:TW提案讓.json的速刪能不能轉到AFD之類的呢xxdd-- Sunny00217  2021年4月5日 (一) 13:43 (UTC)
注:可参考英文维基方针。--Tranve () 2021年4月10日 (六) 06:30 (UTC)
同上意见。-门可罗雀的霧島診所三天打鱼两天晒网神社的羽毛飘啊飘 2021年4月18日 (日) 03:54 (UTC)
(※)注意:如果TW可以像封禁選項讓管理員點選「提刪請求參見討論頁」還好,否則要管理員輸入詳細的提刪位置,手機不好操作。而且被刪除的頁面如果沒有任何提刪模板,而且公開的日誌中又未能清楚查看誰在哪裏提出刪除,對操作管理員來說都容易有爭議;刪除的操作不能馬虎,操作不清楚,時隔多天後,如果連操作管理員也忘了用戶在哪裏提出請求,而頁面又沒有提刪模板,對管理員會很不利,可以成為有心人質疑管理員操作的藉口,因此我比較同意Sunny00217建議,或者直接找管理員,或者在用戶自己的討論頁ping管理員請求刪除,管理員刪除時加個編輯差異,這樣才好保障管理員以免陷入不必要的爭議,而且安憶現在已經造了一個編輯差異複製黏貼的小工具,很好用。--蟲蟲飛♡♡→♡℃留言 2021年4月18日 (日) 04:19 (UTC)
@蟲蟲飛:我不同意阁下的观点。首先,如果一个快速删除请求仅仅因为删除的页面是一个特殊页面而需要单独联络管理员,这已经违背了快速删除请求“快速”的特质;其次,如果需要到 WP:AFD 去汇报的话,相当于破坏了 AFD 的功能(AFD 原本应用于存废讨论),会导致站务管理混乱。我大致上同意仿照英文维基的方针。目前的技术问题先看看能不能联系管理员解决,如果不能解决的话,再尝试您的方案吧。请问如何联系管理员?--Tranve () 2021年4月20日 (二) 10:41 (UTC)
(?)疑問:1.全保護的頁面通常是很重要的,有頻繁刪除的需要嗎?而且過去五年,我只看到您一個人有這方面的提刪需求和困難。2.走去找管理員討論頁討頁請求很困難嗎?如果覺得有困難,您在自己討論頁ping在線管理員,請求刪除,有甚麼困難?--蟲蟲飛♡♡→♡℃留言 2021年4月20日 (二) 13:29 (UTC)
(:)回應:我在章节标题中已经写明了:我希望这一过程制度化。快速删除的目的是“加快处理显然不合适的页面或文件,省去存废讨论的时间”,而我上面的情形完全符合这个定义,理应走快速删除方针删除,奈何方针不完善啊 :( 其次,这个问题我已经遇到了两次:一次是 JSON 页面挂不上速删模板,另一次是自己的模块页面也挂不上删除模板,不存在全保护的问题。--Tranve () 2021年4月21日 (三) 12:26 (UTC)
@Tranveen:Module:Module_wikitext關於在中文維基無效Module:Module_wikitext的問題,導致en:MediaWiki:Gadget-twinklespeedy.js中文維基用不了的問題,請找WP:介面管理員。例如User:安忆是介面管理員。-- 五歲抬☎️·☘️) 2021年4月20日 (二) 11:17 (UTC)
@A2569875:没来得及细看(大致看了下关键字)。请问具体需要我的什么帮助?如果是Module的话需要模板编辑员才行。--安忆Talk 2021年4月20日 (二) 14:28 (UTC)
@安忆:看了一下追查英文維基相關功能的添加紀錄(關於Module:Module_wikitext),為en:Special:Diff/977236565,這個模板编辑员也無法,只能管理員;介面管理員能做的應該是中文維基的en:Special:Diff/977236565完成後,參照英文維基en:MediaWiki:Scribunto-doc-page-does-not-exist修改介面。 @Tranve:涉及如此複雜修該應需要公示。-- 五歲抬☎️·☘️) 2021年4月20日 (二) 14:36 (UTC)
@A2569875:多谢!但是我不熟悉互助客栈,请问如何才能公示呢?--Tranve () 2021年4月21日 (三) 12:28 (UTC)
@Tranve:需先獲得共識才能公示WP:7DAYS-- 五歲抬☎️·☘️) 2021年4月23日 (五) 19:27 (UTC)
(-)反对:直接找管理員幫忙就解決了問題,沒必要小題大作。--蟲蟲飛♡♡→♡℃留言 2021年4月24日 (六) 04:07 (UTC)
(:)回應
  1. 我之前已经两次回复了您的问题(第一次第二次),为什么您还是重复相同内容?
  2. 当前讨论的议题(制度化)的目的不是“小题大作”,而是“大题小作”,使复杂问题简单化,方便处理。方针制度的存在就是为了通过走流程从而简化一种类型的问题的处理。
  3. 退一万步讲,如果真的按照阁下所言,那么连快速删除方针都可以不要了,有页面要删可以直接找管理员帮忙,“没必要小题大做”。
以上。--Tranve () 2021年4月24日 (六) 09:05 (UTC)
(:)回應
  1. 您的兩次回應都未能有效回應我提到的疑慮,請重看我的留言。
  2. 您的問題根本就不是問題,沒必要建立所謂“制度”,而且所謂“制度”也帶出了新的問題,詳見我上面的留言。
  3. o1,g10是可以直接找管理員,其他的須要通知頁面建立人,未見現行機制有甚麼問題
以上。--蟲蟲飛♡♡→♡℃留言 2021年4月24日 (六) 09:21 (UTC)
逐条(:)回應如下:
  1. 关于“Twinkle相关功能”
    此类问题应该在方针确定下来后联系 Twinkle 维护者解决。应该没有特别大的技术问题。
  2. 关于“管理员陷入不必要的争议”
    如果快速删除方针中加入了对特殊页面的相关条文,管理员在删除的时候完全可以援引快速删除方针,之后想要查证,其他管理员直接方针中所写内容去查删除记录(比如查对应讨论页已删除的贡献),不会陷入不必要的争议。另外,为什么会“陷管理员与不义”?这种时候不应该假定善意吗?
  3. 关于“快速删除全保护页面”
    我想解决的问题中不包括全保护页面的速删请求。
  4. “您的问题根本就不是问题”“o1,g10是可以直接找管理员”
    为什么不是呢?自己创建的 JSON 和模块名字空间页面理应走 O1 删除,结果模板挂不上去。
    我把快速删除方针从头到尾翻了个遍,都没有找到“o1,g10可以直接找管理员”相关字样。既然这样,谈到这个又有什么意义呢?
总之,我提议将相关内容添加到方针的理由很简单:方针中没有涵盖我遇到的这种特殊情况的处理方法。别人有没有遇到同样问题,有多少人遇到,我不清楚。但是我遇到了,并且如此麻烦的处理过程让我觉得很意外。既然这样,问题就存在了。存在了就应该被解决。
以上。--Tranve () 2021年4月25日 (日) 12:17 (UTC)
(:)回應:您提到理據完全不成立。您把一個很簡單的問題複雜化,像您提刪User:Tranve/工坊/workshop.json不是很簡單嗎?您不願走去找管理員,您可以在自己用戶討論頁ping管理員,很容易就解決了問題。您在討論頁提刪,但討論頁又因為g15被刪去,被刪去的頁面又沒有提刪模板,很容易令人質疑管理員在沒有提刪的情況下刪去頁面。--蟲蟲飛♡♡→♡℃留言 2021年4月25日 (日) 12:34 (UTC)
管理员不是机器人而是人。我觉得有足够经验的管理员应该能够意识到页面是 JSON 页,速删模板挂不上去的。更多讨论请移步下面,谢谢。--Tranve () 2021年4月25日 (日) 12:52 (UTC)
現在就只有您一個人有這個問題,其他人找管理員幫忙完全沒有問題,而且說了很多遍,管理員刪除頁面一定要清晰註明誰在哪裏提刪頁面,這些操作不能馬虎。--蟲蟲飛♡♡→♡℃留言 2021年4月25日 (日) 13:42 (UTC)
如果不用专门去找一个管理员删除,不是更好?--百無一用是書生 () 2021年4月28日 (三) 02:53 (UTC)
  • (!)意見仍然想提議引入能在Module頁掛模板的英文維基功能,使TW工具能像英文維基那樣直接自動掛模板。-- 五歲抬☎️·☘️) 2021年4月24日 (六) 09:38 (UTC)
  • TW如果能配合加註提刪位置及提刪者還好,否則就是陷管理員於不義。--蟲蟲飛♡♡→♡℃留言 2021年4月24日 (六) 09:42 (UTC)

就规范部分特殊页面的删除方式征求社群建议[编辑]

现提议在Wikipedia:快速删除方针中“管理员操作注意事项”前增加一节,标题为“放置快速删除模板时的注意事项”,正文内容如下:

現行條文

…… 管理员操作注意事项 ……

提議條文

…… 放置快速删除模板时的注意事项 部分页面因为技术限制,在放置快速删除模板时需要遵从特定方式。

  • JSON页面:请在该页面对应的讨论页放置快速删除模板,并在原本的删除理由之后附加“请删除本讨论页对应的主页面”字样。
    范例:{{d|快速删除理由|请删除本讨论页对应的主页面}}
  • 位于模块名字空间的页面(文档页面除外):如果该页面需要通过快速删除请求删除,请使用以下语法。
    require('Module:Module wikitext')._addText('{{d|快速删除理由}}')
  • CSS(包括“已过滤的CSS”)和JavaScript页面:请将快速删除模板包含在注释中,如下所示。
    /* {{d|快速删除理由}} */

管理员操作注意事项 ……

为了落实以上方针,需要解决的问题有:

  1. 让中文维基百科支持 Module:Module wikitext 模块。
  2. 让 Twinkle 实现相关功能的自动化。

现征求社群建议以达成共识。--Tranve () 2021年4月25日 (日) 12:46 (UTC)

(-)反对:TW如果能配合加註提刪位置及提刪者還好,否則讓管理員的刪除操作欠缺提刪模板,令人誤以為管理員在沒有提刪的情況下刪去頁面,增加不必要的爭議。建議提刪相關頁面直接找管理員處理,或者在用戶討論頁ping管理員,具體操作如User:Tranve/工坊/workshop.json。此外,這種沒提刪模板的刪除操作,連其他復檢刪除頁面的管理員也容易有誤會,因為不會有人去檢查不同的已刪除的子頁面及討論頁,像之前提案人在一個頁面的子頁面提刪,有些頁面有無數子頁面,就算管理員也無法確定具體的提刪位置和提刪者,這就容易引起不必要的誤會和爭議。刪除操作是很嚴肅的事,所有刪除操作都應讓其他管理員容易復檢刪除原由,不能馬虎。--蟲蟲飛♡♡→♡℃留言 2021年4月25日 (日) 13:36 (UTC)
(:)回應@蟲蟲飛:首先,我们现在讨论的是速删方针,不是提删方针。如果速删有疑虑,不应该在删除页面之前解决吗?为什么需要复检?其次,Twinkle 相关问题请联系其维护者,与本站的方针无关。--Tranve () 2021年4月26日 (一) 10:26 (UTC)
  • 不論速刪,還是afd提刪,刪除操作都應非常審慎,而且不只刪除操作,任何操作都會有其他管理員復檢,確保操作沒問題。您的提案是增加了管理員操作及復檢操作的難處,而且您不是沒有更好的解決方法,只是您個人不願去做。例如,您可以在任何獨立於被刪頁面中提出速刪,或者您直接去管理員討論頁留言,但您就不願,把非常簡單的問題複雜化,然後帶出管理員操作上的爭議問題。--蟲蟲飛♡♡→♡℃留言 2021年4月26日 (一) 10:43 (UTC)
(※)注意:管理員刪去頁面後,其他管理員都會覆檢究竟管理員的刪除操作是經過其他用戶提刪的程序,還是管理員濫權,直接刪頁面;提案就是增加了其他管理員覆檢刪除操作的難處。-蟲蟲飛♡♡→♡℃留言 2021年4月26日 (一) 11:16 (UTC)
(※)注意請蟲蟲飛不要只顧著反對,Antigng 已經著手在IRCTG互聯群開發能直接在json 上掛模板的模組。—- 五歲抬☎️·☘️) 2021年4月26日 (一) 12:17 (UTC)
  • 既然技術上解決了問題,就沒必要改方針了。--蟲蟲飛♡♡→♡℃留言 2021年4月27日 (二) 12:17 (UTC)
    • (:)回應@蟲蟲飛:技术上要解决的问题和设立方针的问题是两个不同的问题,所以您的理由并不成立。“技术上要解决的问题”是因为“设立方针的问题”才存在的,这个依赖关系可以理解吗?--Tranve () 2021年4月28日 (三) 12:42 (UTC)
  • 第二、三點不改方針,也可以做,修訂方針就沒意義。第一點,您是想通過方針強逼管理員讓您在子頁面或討論頁提刪時,須註明提刪原由,但又沒有TW配合,這是增加管理員操作時的難處。現在已經很少管理員願意處理站務,您的提案是想讓更多管理員不願處理站務。--蟲蟲飛♡♡→♡℃留言 2021年4月28日 (三) 12:58 (UTC)
(~)補充:TG羣有人誤會了我的意思,所以想解釋一下。我擔心的是提案容易讓管理員可直接繞過提刪,直接刪去頁面,如果這種操作成為合法化,就算管理員濫權,其他管理員覆檢就更難。--蟲蟲飛♡♡→♡℃留言 2021年5月1日 (六) 02:17 (UTC)

在技术上敲定解决方案之前(见下一章节讨论),以上方针的修改先搁置。--Tranve () 2021年4月30日 (五) 10:40 (UTC)

引入能夠在特殊頁面掛模板的模組[编辑]

已通過:
公示期已過,且已逾時超過一日(49小時28分鐘),在公示期將結束至此刻(2021年5月7日 (五) 13:45 (UTC))未出現新的異議,期間反對者的論述已由支持者回應,且反方無進一步論述,因此提案通過-- 五歲抬☎️·☘️) 2021年5月7日 (五) 13:45 (UTC)
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

為了解決模板掛不上去或者TW不支持的問題,因此提議引入以下模組

  • Module掛模板問題
    引入en:Module:Module wikitext並提出編輯請求以編輯相關高風險模板與介面讓中文維基支持
  • json或css或js掛模板問題
    已開發完畢,待社群共識後才會提請編輯請求,見圖

此法如果引入成功,完全可以直接在原頁面申請速刪,不存在上方提到的任何疑慮!如果這個建起來,提刪過程會「跟提刪條目一模一樣」,不會陷管理員於不義。對應要提刪的頁面會有提刪模板,不會讓管理員的刪除操作欠缺提刪模板,不存在上方提到的任何疑慮!—- 五歲抬☎️·☘️) 2021年4月26日 (一) 18:51 (UTC)

没有什么不好的。--安忆Talk 2021年4月27日 (二) 11:47 (UTC)
  • 非常感謝幫忙!能在原頁面掛速刪模板,這樣就可以解決管理員刪去頁面後,其他管理員無法復檢刪除操作的問題,否則其他管理員就無法確定管理員是否濫權,在沒有提刪的情況下,直接刪了頁面,這是屬於嚴重濫權,因此在頁面能留下速刪模板是非常重要的,這件事不能馬虎。此外,既然技術上解決了問題,就沒必要改方針了。--蟲蟲飛♡♡→♡℃留言 2021年4月27日 (二) 12:15 (UTC)

項目 辦理狀況 需編輯的頁面 頁面patch 效果預覽
Module 已完成測試 Module:Module wikitext (已佈署) Module:沙盒/a2569875/Test4
Module:Documentation Module:Documentation/sandbox
MediaWiki:Scribunto-doc-page-does-not-exist User:A25...-does-not-exist
(需要語言變種微調)
JS、CSS 已完成測試 Module:Special wikitext (已佈署) 留言WP:TG1) 、 互連群圖床
MediaWiki:Clearyourcache User:A25...yourcache
(需要語言變種微調)
JSON 等待工單phab:T235798佈署 phab:T235798 gerrit:r/c/543934
  • 本地已經準備完畢的部分(Module、JS、CSS)可考慮先行公示並佈署。-- 五歲抬☎️·☘️) 2021年4月27日 (二) 15:33 (UTC)
  • 說明phab:T235798要解決的問題是,目前JSON可以用技術手段掛模板,且頁面中也確實能夠顯示掛上模板後的速刪分類
    (見測試圖留言WP:TG1) 、 互連群圖床),然而頁面分類的資料庫暫時無法更新資料
    所以雖然模板能掛了,但還是需要手動提醒/或找一個管理員,告知頁面需要刪除,
    這樣@蟲蟲飛:您會不會又無法接受了? 當然,這個問題可以修復,只是phab:T235798不明原因擱置中(目前看起來是代碼合併衝突、需要更新),可能需要一點時間,當phab:T235798佈署完畢後就會完全沒有這問題了。 在這之前,有以下(&)建議
    ※目前的(&)建議是,在phab:T235798工單完工之前,先把沒問題的JS、CSS、Module 公示通過在本地佈署因為JSON掛模板工能本地需要修改的地方與JS、CSS、Module相同,當phab供單完工後,將會立即生效,而在JSON全域佈署前,JSON先暫時維持原本的提刪方式(模板掛,但頁面分類的資料庫暫時不會正常更新,看要不要方針註明一下,不是技術限制,而是phab工單工作中...最近課業繁忙,比較沒有時間去提供後台php代碼,可能無法像之前專題空間那像迅速完成,而已經OK的JS、CSS、Module我覺得可以先行佈署))。-- 五歲抬☎️·☘️) 2021年4月28日 (三) 11:41 (UTC)
  • (※)注意:頁面能掛速刪模板就好了,就算不能掛模板,走去找管理員留言提刪,安憶那個編輯差異的小工具很好用,可以很容易就在刪除日誌中註明提刪的原由,復檢的管理員也能輕易瞭解刪除操作的管理員有沒有濫權,有沒有在沒提刪的情況下刪去頁面。沒有提刪,直接刪去頁面屬於嚴重濫權,因此刪除操作的處理一定要很審慎。此外,方針沒必要改,這些操作屬於技術性問題,與方針無關,而且現行方針已經很清楚。--蟲蟲飛♡♡→♡℃留言 2021年4月28日 (三) 12:00 (UTC)

公示期討論:技術案[编辑]

  • 公示:對於技術相關的反對意見已排除,將Module、JS、CSS掛模板方案 公示7日(通過後JSON其實也能掛模板,但頁面分類暫時無法更新,需要phab:T235798)根據結論,暫時不修改方針。-- 五歲抬☎️·☘️) 2021年4月28日 (三) 12:15 (UTC)
  • 如果提刪模板不能放在目標頁面,就不能放在子頁面或者討論頁,因為復檢的管理員如果看到被刪的頁面沒提刪模板,沒有人會檢查所有子頁面及討論頁,然後就容易誤會管理員在沒有提刪的情況下直接刪去頁面。--蟲蟲飛♡♡→♡℃留言 2021年4月28日 (三) 12:30 (UTC)
註:此處原有文字,因為過多重複內容,已由五歲抬☎️·☘️)於2021年4月30日 (五) 16:15 (UTC)刪除,尚祈見諒。若有異議請至互助客棧或向管理員反映。
@蟲蟲飛:上面的技術如果公示通過了CSS,JS,Module 才可以在原頁面掛模板,JSON也可以在原頁面掛模板,phab:T235798沒好只是頁面分類暫時不會歸檔。—- 五歲抬☎️·☘️) 2021年4月28日 (三) 12:53 (UTC)
  • (~)補充模板掛法說明,「可以在原本的頁面掛」,但需要符合對應頁面的頁面內容模型,語法如下所示,可討論是否需要補充進指引(c.c. @蟲蟲飛:):
    • JSON页面:在最外層的{...}之內加入代碼:(上述模塊引入後,JSON页面雖能顯示模板,但分類暫時不會自動歸檔,需等待phab:T235798佈署)
      "_addText":"{{Delete|快速删除理由}}"
    • Array形式的JSON页面:在最外層的[...]之內加入代碼:(如頁面開頭與結尾符號是中括號時[...]
      {"_addText":"{{Delete|快速删除理由}}"}
    • 位于模块名字空间的页面(文档页面除外):加入代碼:
      require('Module:Module wikitext')._addText('{{Delete|快速删除理由}}')
    • CSS页面:加入代碼:
      ._addText{
      	content:"{{Delete|快速删除理由}}";
      }
      
    • JavaScript页面:加入代碼:
      var _addText="{{Delete|快速删除理由}}";
    同時提供給WP:TW開發者參考。-- 五歲抬☎️·☘️) 2021年4月29日 (四) 08:33 (UTC)
    eslint: _addText沒被定義-- Sunny00217  2021年4月30日 (五) 07:34 (UTC)
    • @Sunny00217:那這樣不就得了?var _addText="{{Delete|快速删除理由}}";-- 五歲抬☎️·☘️) 2021年4月30日 (五) 07:50 (UTC)
      @A2569875:只是想到覺得好笑貼上去而已(因此也沒 ping),實際上不會有人要提刪了還用 eslint 的 xxdd-- Sunny00217  2021年4月30日 (五) 12:29 (UTC)
    • 嗯。这个做法也不错,或许可以解决虫虫飞的顾虑。我到上面修改一下方针文本。--Tranve () 2021年4月30日 (五) 10:30 (UTC)
      • (&)建議@Tranve:要改方針建議先等技術通過再說,不然一起推行只會一起卡死。-- 五歲抬☎️·☘️) 2021年4月30日 (五) 10:32 (UTC)
        • 感谢提醒!您的方案我再看了一下,对于 JSON 页和模块页的处理我没有意见,但是 CSS 的处理方式是不是有点 dirty,这样相当于整了一个不存在的_addText class,JavaScript 我认为也有这样的问题。万一有脚本要用到 _addText 变量呢?另外,这个变量一定要是全局变量吗?我的提案,也就是在页面最开头的注释里头放进{{d}}模板的做法,也是可行的。--Tranve () 2021年4月30日 (五) 10:37 (UTC)
          • @Tranve:完全沒有影響,也不認為有任何問題,加那樣只是讓模板可以被顯示,重點只是能否讓管理員標記要提刪,並且註明「模板能被顯示的方案」,你高興只寫/*{{Delete|快速删除理由}}*/也能被加入速刪分類,只是模板不會顯示。因為技術限制/*{{Delete|快速删除理由}}*/寫法無法讓模板被顯示。 我仍想推行能讓模板被顯示的方案或手段,因為可以用於插入DOC類的用途。由於是正則,以下的表達是都能識別:
            • /* var _addText="{{Delete|快速删除理由}}"; */
            • /* _addText{content:"{{Delete|快速删除理由}}";} */
            • wiki_addText="{{Delete|快速删除理由}}";
            • []._addText = '{{Delete|快速删除理由}}';
              註:此處原有文字,因為過多重複內容,已由五歲抬☎️·☘️)於2021年4月30日 (五) 16:15 (UTC)刪除,尚祈見諒。若有異議請至互助客棧或向管理員反映。
              。-- 五歲抬☎️·☘️) 2021年4月30日 (五) 11:25 (UTC)
              既然都是用regex來匹配,為何不採用最簡單的格式,即註解的格式。--Xiplus#Talk 2021年5月1日 (六) 00:53 (UTC)
              • 並不想讓所有的註解都被匹配。而且其他非wikitext 的註解也一同渲染會很凌亂。—- 五歲抬☎️·☘️) 2021年5月1日 (六) 01:21 (UTC)
                您可以精準匹配 /* {{Delete|...}} */ ,而不僅是註解。--Xiplus#Talk 2021年5月1日 (六) 02:58 (UTC)
                (-)反对我希望能夠放不是模板的wikitext ,其他用途如DOC或說明文件,包括但不限於速刪之用,且英文維基的en:Module:Module wikitext也沒有限制能放的wikitext 種類,沒道理中文維基製作類似模組就要加入奇怪的限制;此外lua 正則不支援組的或模式(例如(A|B)),而且刪除模板也有許多重定向,完全不建議精準匹配,如果只考慮刪除用途,亦會有AFD模板問題,且不建議用lua 簡化功能、功能不全的正則來匹配模板,因為很難解決模板嵌套問題,亦不建議限制用戶不能在提刪理據裡面以其他模板表示。—- 五歲抬☎️·☘️) 2021年5月1日 (六) 03:39 (UTC)
                但是本提案只是想解决挂速删模板的问题,目前来看/* {{Delete|...}} */可以被正确加到分类里,这对于管理员速删页面来说足够了。至于速删理由,我觉得可以通过方针强制规定注释加到开头即可,这样管理员可以直接看见。如果真要解决挂 DOC 的问题的话,英文维基似乎可以显示一个提示文本“This user script seems to have a documentation page at XXX”,范例见 en:User:Cacycle/wikEd.js--Tranve () 2021年5月5日 (三) 08:31 (UTC)
                • @Tranve:完全不認為有任何衝突,技術案是我提出的臨時動議,我認為統一讓JSON和其他頁面加入此方式沒甚麼問題,只見你一直試圖阻擋提案,甚至在通過的前三個小時故意推翻先前的協議,前幾天你明明已經在TG說可以接受了,又在通過的前三個小時惡意異議,涉嫌WP:遊戲維基規則,且你的提案在json中是無效的,需要性早已在WP:TG陳述,且未見有甚麼不妥之處,英文維基怎麼做事英文維基的事,WP:是英文維基說的!(!)抗议追隨英文維基論;此外,作為視覺派使用者,我強烈支持模板顯示,(!)強烈抗议模板不顯示。-- 五歲抬☎️·☘️) 2021年5月5日 (三) 08:43 (UTC)
                  1. 你的提案在JSON中是無效的,我希望一個統一模式,且我這個統一的_addText模式適用於所有頁面內容模型,Antigng也有說,_addText以底線命名就是要避免變數命名衝突問題,因此未見我的提案有任何問題。
                  2. 你的提案在JSON中是無效的,所以這對於管理員速刪頁面是完全無法操作的,無法解決蟲蟲飛的疑慮。
                  3. 速刪理由問題,速刪模板本身有許多編輯提示,可以對要執行素珊的管理員做出提醒,避免誤操作,認為顯示模板是有好處的。
                  4. 有模板能正常顯示的方案,為何使用提示文字? 有些使用者使用手機閱覽維基百科,會需要多一層操作來檢視模板顯然多此一舉,且提案明明可以正常顯示模板,未見為何故意還要多一道手續顯示模板。請照顧使用特殊裝置的維基使用者。
                  5. 在公視到期臨界時間惡意反對被WP:VIP的例子詳見Wikipedia_talk:关注度_(虚构)#通過後討論,可以很明顯地看到,是唯一一個反對通過的人,而他現在這樣強行阻止條文通過的做法已經構成遊戲維基規則。
                以上-- 五歲抬☎️·☘️) 2021年5月5日 (三) 08:59 (UTC)
                • 编辑冲突再補充一點,en:User:Cacycle/wikEd.js顯示東西的原理跟本地提案相同,是透過介面編輯請求完成,同樣是Antigng提到的「介面黑魔法」,內部依然需要有模組程式碼去匹配對應頁面計算對應頁面的狀態,且過往許多從英文維基引入的提案也都會有本地特化,未見本地特化提案有任何問題。且要完成有關提案也需要進行本案相關編輯請求。持續(!)抗议中。-- 五歲抬☎️·☘️) 2021年5月5日 (三) 09:09 (UTC)
                  • @A2569875:Sorry,了解了。我觉得我们这样谈下去也没完没了。我希望您关于挂速删模板的提案通过后可以试行一段时间,根据用户和管理员的反馈再进行修正,可以吗?--Tranve () 2021年5月5日 (三) 09:15 (UTC)
    @Tranve:關於您的意見,en:User:Cacycle/wikEd.js涉及en:Template:Script doc auto的引入,已經不是本案處理範圍,應另提新案。-- 五歲抬☎️·☘️) 2021年5月5日 (三) 09:28 (UTC)
    • (~)補充關於未來根據反饋修正可以,已在下方預留反饋章節。-- 五歲抬☎️·☘️) 2021年5月5日 (三) 09:51 (UTC)
      • 說明已多等待一日,未見反方有更多意見,因此以「反對者的論述已由支持者回應,且反方無進一步論述」論。-- 五歲抬☎️·☘️) 2021年5月6日 (四) 12:51 (UTC)
(!)意見:宇帆TG主羣的留言我看了,您誤會了我的意思,我沒有反對您技術修訂的提案,但前提是提刪的頁面須保留提刪模板。--蟲蟲飛♡♡→♡℃留言 2021年5月1日 (六) 02:14 (UTC)
(:)回應關於這一點,沒有問題,此案確實能讓需要刪除的頁面擁有提刪模板,包括但不限於速刪、DRV、AFD或其他需要模板的提刪過程(如合併、移動、遷移至其他維基計畫或其他維護模板),故顯然不會有管理員執行操作時,缺乏模板標記的問題,惟須注意的是,由於模板掛法要符合特定頁面內容模型,故會需要一些特殊語法,建議在技術案通過後也同步在方針頁註記相應內容模型掛模板的語法。—- 五歲抬☎️·☘️) 2021年5月1日 (六) 08:45 (UTC)
※註:根據Special:Diff/65395602 公示截止時間為2021年5月5日 (三) 20:17 (UTC+8),公示已結束(6天前)(更新)-- 五歲抬☎️·☘️) 2021年5月5日 (三) 10:00 (UTC)

  • 通過:公示期已過,且已逾時超過一日(6天前),在公示期將結束至此刻(2021年5月6日 (四) 12:55 (UTC))未出現新的異議,期間反對者的論述已由支持者回應,且反方無進一步論述,因此提案通過,將開始準備佈署事宜。-- 五歲抬☎️·☘️) 2021年5月6日 (四) 12:55 (UTC)

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

技術案:處理狀況[编辑]

項目 辦理狀況 需編輯的頁面 頁面patch 效果預覽
Module 完成 Module:Module wikitext (已佈署) Module:沙盒/a2569875/Test4
完成編輯請求 Module:Documentation Module:Documentation/sandbox
完成編輯請求 MediaWiki:Scribunto-doc-page-does-not-exist User:A25...-does-not-exist
(需要語言變種微調)
JS、CSS 完成 Module:Special wikitext (已佈署) 留言WP:TG1) 、 互連群圖床
完成編輯請求 MediaWiki:Clearyourcache User:A25...yourcache
(需要語言變種微調)
JSON 等待工單phab:T235798佈署 phab:T235798 gerrit:r/c/543934
WP:模板樣式 讨论进行中……

(兩個項目)

User:A2569875/SpecialWikitext.js

修改方法

圖像圖床對應頁面
頁面預覽功能
WP:TW 等待Twinkle維護者合併修訂 參考差異en:special:diff/978461935(僅LUA部分)
CSS、JSON、JS類推
方針 擱置等待上方議案 Wikipedia:快速删除方针 Special:Diff/65468329 #方針註記案
總進度 50% (項目5/10) 擱置項目
  • JSON分類
  • LUA已刪預覽
已實行項目
  • 掛模板功能
N/A
(更新)-- 五歲抬☎️·☘️) 2021年5月8日 (六) 05:29 (UTC)

技術案階段二:頁面預覽功能[编辑]

可以在檢閱已刪版本時完成預覽:「即使頁面已刪除,提刪模板仍然清晰可見,能輕鬆地讓其他復檢刪除頁面」
本小工具原始碼在User:A2569875/SpecialWikitext.js‎,具有以下功能:
  1. 編輯JS、JSON、CSS的預覽時顯示 _addText 的模板
  2. 相同原理提供WP:模板樣式 _addText 模板顯示功能
  3. JS、JSON、CSS頁面歷史版本檢視的 _addText 的模板預覽 : 如需複查的項目為頁面歷史版本,本工具提供頁面歷史版本內容顯示支援 (可能無法處理歷史版本刪除的狀況)
    歷史版本刪除的檢閱已完成開發,並由Antigng複查功能正常運作-- 五歲抬☎️·☘️) 2021年5月10日 (一) 04:37 (UTC)
  4. 已刪JS、JSON、CSS內容的 _addText 的模板預覽
已經完成所需測試,轉交站內討論是否設定為站內預設啟用的小工具。
註1:正式佈署前,所有人都可以透過在special:myPage/common.js加入importScript('User:A2569875/SpecialWikitext.js');來預覽這個功能。
註1.1:若要在手機網頁板上測試本腳本,改成加入mw.loader.load('https://zh.wikipedia.org/w/index.php?title=User:A2569875/SpecialWikitext.js&action=raw&ctype=text/javascript')
註2:這個功能只會在JS、JSON、CSS中有定義_addText時且 ①預覽JS、JSON、CSS以及 ②閱讀WP:模板樣式CSS頁時啟用,其餘頁面或時機不會作用。
註3:已針對以下皮膚進行測試:Vector、Minerva、現代、MonoBook及Timeless。
註4:
註:此處原有文字,因為lua預覽功能已實裝,已由a2569875(留言)於antigng確認有效後刪除,尚祈見諒。若有異議請至互助客棧或向管理員反映。
以上,請討論-- 五歲抬☎️·☘️) 2021年5月8日 (六) 14:53 (UTC)
  • (~)補充見另外一則測試(使用自架站點測試):預覽圖圖床或右圖,其可以在檢閱已刪版本時完成預覽,能夠符合@蟲蟲飛:最初提出的初衷:「即使頁面已刪除,提刪模板仍然清晰可見,能輕鬆地讓其他復檢刪除頁面,所以能輕易化解其他管理員的誤會」(原句:這種沒提刪模板的刪除操作,連其他復檢刪除頁面的管理員也容易有誤會),故認為提案應全站佈署,以方便社群執行提刪預覽與事後複查(微G11疼?)-- 五歲抬☎️·☘️) 2021年5月8日 (六) 17:00 (UTC)
(+)支持:同意這個小工具應全站佈署,方便所有管理員能覆檢已刪頁面。--蟲蟲飛♡♡→♡℃留言 2021年5月10日 (一) 05:52 (UTC)

技術案階段三:試行期反饋[编辑]

  • 擱置。根據上方2021年5月5日 (三) 09:15 (UTC)意見,預留此節。-- 五歲抬☎️·☘️) 2021年5月5日 (三) 09:19 (UTC)
  • 預計會在上兩案(提刪申請、刪後複檢)完成技術支援佈署後,開放本區收集反饋意見。—- 五歲抬☎️·☘️) 2021年5月8日 (六) 17:52 (UTC)
    • 接收到的反饋1(於WP:TG):預覽、和已刪頁面看不到題刪模板;頁面歷史版本題刪模板與頁面歷史版本內容不匹配
      解決方案:已提出#技術案階段二:頁面預覽功能,並商討全站佈署
    • 接收到的反饋2:未有
    -- 五歲抬☎️·☘️) 2021年5月10日 (一) 05:29 (UTC)
    • 我想问一下,显示出来的模板不能简繁转换是预期行为吗?--Tranve () 2021年5月11日 (二) 13:02 (UTC)
      • (:)回應@Tranve:本案以介面文字實現。介面文字本身不支援自動繁簡轉換-{}-。因此僅能修改你想要放置在特殊頁面的對應模板,用{{lan}}實現-- 五歲抬☎️·☘️) 2021年5月11日 (二) 13:13 (UTC)

方針註記案[编辑]

  • 擱置中...,等待上方公示。在技術案公示結束並佈署完成之前請先在上方章節討論。-- 五歲抬☎️·☘️) 2021年5月3日 (一) 04:01 (UTC)
現行條文

…… 管理员操作注意事项 ……

提議條文

……

放置快速删除模板时的注意事项 部分页面放置提删模板時需要符合相應內容模型,因此在放置快速删除模板时需要遵从特定方式,同時,下面列舉的模板放置方式,亦適用於其他模板,如WP:AFD等。

  • JSON页面:请在根據頁面的格式加入語法:
    • 最外層的格式為花括弧{...}的JSON页面,將以下语法放置在最外層的{...}之內:
    "_addText":"{{Delete|快速删除理由}}",
    • 最外層的格式為中括弧[...]的JSON页面,將以下语法放置在最外層的[...]之內:
    {"_addText":"{{Delete|快速删除理由}}"},
    • 此外,由於技術限制(參見phab:T235798),模板放置後暫時不會自動被加入分類,因此在phab:T235798佈署前,可能還需要通知一位管理員來執行刪除。
  • 位于模块名字空间的页面(文档页面除外):请使用以下语法:
    require('Module:Module wikitext')._addText('{{Delete|快速删除理由}}')
  • CSS页面:请使用以下语法:
    ._addText{
    	content:"{{Delete|快速删除理由}}";
    }
    
  • JavaScript页面:请使用以下语法:
    var _addText="{{Delete|快速删除理由}}";
  • CSS(包括“已过滤的CSS”)和JavaScript(不包括JSON)也能通過在注释中使用以下語法來放置模板。
    /* _addText: {{Delete|快速删除理由}} */
  • 註:除了JSON之外頁面分類都能正常運作,然而,由於技術限制,目前已过滤的CSS頁面無論用何種方式掛模板皆無法正常顯示模板,不過頁面分類能夠正常運作,因此不會影響提刪流程。

管理员操作注意事项 ……

準備中...-- 五歲抬☎️·☘️) 2021年5月3日 (一) 04:01 (UTC)

限縮{{电视节目的变迁}}模板使用範圍[编辑]

電視節目我印象中的認知是綜藝、名嘴那種節目,電視劇個人感覺像是跟電視動畫一樣的存在,只是娛樂產物,雖然我是想直接刪掉這麼雞肋的模板,但似乎無共識,那提議限縮使用範圍如何?以上僅個人拙見。--1.200.74.250留言) 2021年4月9日 (五) 03:28 (UTC)

我認爲可以廢掉。前後檔節目一般没有直接關係。如果有關係,也應該是用條目正文說明經緯,比如“前檔的古裝劇《XXX》意外大熱,故電視臺决定延續古裝題材”。類比WP:DATELINK可以說,Template:電視節目的變遷羅列接檔條目時,其聯繫不能祇是“節目在同一時段且前後相連”這种程度。畢竟模板占那麽大位置(三行比一些導航模板都高,還不能折叠),正文又什麽東西都說不出來,那基本就是WP:UNDUE。至於重要電視臺的黄金檔電視劇,這本身就是個話題;可考慮作爲整體直接建導航模板,將一系列條目按時序列出。總而言之:和主題的其他製作、放映資訊相比,前後檔節目這一句話說清的事實是有多緊要,值得獨佔三行空間介紹?--洛普利宁 2021年4月10日 (六) 18:33 (UTC)
真的没啥用,前后节目本无关联,如有在正文能说明白了。太占位置了,同意直接废除。🌟🌟Talk 2021年4月11日 (日) 01:31 (UTC)
中立,感觉类似“参见”(相关条目),不适合写入正文,不是都有明显的意义和参考资料,类似时间线资料。更看不惯收视率章节的统计表。需要电视专题的参与者决定,不然会反弹。--YFdyh000留言) 2021年4月13日 (二) 12:10 (UTC)
人家電影票房好歹有來源,电视节目的变迁和收视率一堆沒來源還刪除不了真的是恐怖情人,想甩甩不掉。 --Loving You Is A Losing Game 2021年4月13日 (二) 17:00 (UTC)
(▲)同上(+)支持:尤其如果後來隔幾年又有哪個電視台購買版權又添加,簡直沒完沒了,像三生三世十里桃花_(电视剧)#電視節目的變遷就很誇張。立ち直り中 2021年4月20日 (二) 08:33 (UTC)
不需要廢除,但是也不需要過度使用,我認為只使用於電視台或平台的首播時段是能被接受的,重播則不需要。 2021年4月22日 (四) 02:24 (UTC)
(▲)同上(-)反对直接廢除,只限首播就是了。另限一頁(或一個地區)用一個也行。--LuciferianThomas留言 2021年4月22日 (四) 06:53 (UTC)
@LopullinenYFdyh000星星MilkypineKodokunaSmilePseudo Classes:無共識結案或進一步討論限制措施(如限記錄首播)?--LuciferianThomas留言 2021年4月29日 (四) 06:32 (UTC)
@LuciferianThomas::这里不是投票。希望反对废除的维基人回应一下,为什么接档信息值得独占三行空间,而不是用正文中的一句话表述。--洛普利宁 2021年4月29日 (四) 06:45 (UTC)
若多於一個頻道同步首播,其後或此前各自是在播不同的節目,那麼就當然會造成混亂。純文字解決不了的是閱讀上的凸顯。--LuciferianThomas留言 2021年4月29日 (四) 06:54 (UTC)
首先即便是多台首播,点列语法一台一行也足够清晰,根本不用占三行位置。
其次为什么非要列接档信息?条目的主题是电视剧,不是电视台;说一下在电视剧在某台首播即可,不需要在这个电视台的节目表上延展。「电视剧>电视台>电视台x点节目(条目都没写,这还是断链)>电视台x点节目的前后档」这个链条下来,接档和主题的关系都稀释的差不多了。条目还有剧情大纲、制作过程、反响等更