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

Breezeicons-apps-48-cantor.svg

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


發表前請先搜索存档,參考舊討論中的内容可節省您的時間。
公告板
# 話題 發言 參與 最新發言 最後更新(UTC+8)
1 專題命名空間(第二點五至四階段) 29 7 A2569875 2021-05-16 15:30
2 專題命名空間(第五至六階段) 59 10 Sanmosa 2021-05-14 21:12
3 偽命名空間(階段一:設立前) 1 1 Jimmy-bot 2021-05-16 10:48
4 偽命名空間(階段三:設立後續) 23 5 A2569875 2021-05-13 12:31
5 WP:捷徑指引草案修訂 24 4 A2569875 2021-05-13 12:33
6 關於Wikipedia:命名常规 (音乐) 110 19 生米一粒 2021-05-13 03:21
7 有關新增偽命名空間的提議 30 11 Sanmosa 2021-05-12 14:28
8 模板颜色相关规范 75 19 特克斯特 2021-05-16 03:34
9 设计一个制度解决部分速删模板挂不上去的页面的删除问题 98 9 A2569875 2021-05-13 03:55
10 限縮{{電視節目的變遷}}模板使用範圍 0 0
11 设立过滤器禁止将维基百科用作来源 22 10 Poontele 2021-05-15 02:24
12 订立编辑松相关规章制度 54 19 Ericliu1912 2021-05-06 08:09
13 訂立影片加入相關指引 23 8 Sanmosa 2021-05-06 09:54
14 关于“个人贡献”之“机械翻译工具”所衍生问题相关讨论及方案探讨 33 9 維基百科最忠誠的反對者 2021-05-09 23:42
15 参考英文指引,为页面分类指引引入可查证性的要求,同时引入Uncited category维护模板的提案 77 18 Antigng 2021-05-09 23:19
16 再次推动破坏者(LTA)成为名字空间 20 10 羊羊32521 2021-05-12 12:59
17 修改拉票与游戏维基规则为不要拉票与不要游戏维基规则,并规范此类命名 1 1 Jimmy-bot 2021-05-16 10:48
18 有關用戶討論頁及其存檔的刪除事宜 9 7 羊羊32521 2021-05-15 21:53
19 修订CSD#G14 1 1 Jimmy-bot 2021-05-16 10:48
20 为什么点开新链接时不打开一个新窗口 0 0
21 格式手冊對於國籍的規定有缺陷,有用戶藉此刪除知名人士的前國家國籍 28 10 Billytanghh 2021-05-16 15:06
22 「格式手冊/兩岸四地用語」之國籍章節規定"PRC國籍"應該直接寫為"中國國籍"的中立性問題 45 8 Barter84 2021-05-15 09:44
23 大量條目的標誌被無故刪除 55 17 Baycrest 2021-05-15 01:26
24 UAA处理相关 6 4 蟲蟲飛 2021-05-10 17:56
25 放寬维基百科:維基榮譽新人獎勵的獲得條件 10 5 Temp3600 2021-05-11 13:13
26 修改WP:命名常规#书名号 58 13 Sanmosa 2021-05-15 11:55
27 澄清 或修改 Wikipedia:共识#互助客栈草案 -- 现条款中没有给出客观公正判断“有说服力的理由”的方法,并且否定了民主客观的判断原则,与“公示无异议”才能通过冲突 34 9 蟲蟲飛 2021-05-16 11:37
28 关于COVID-19重定向的讨论 50 11 No1lovesu2 2021-05-15 17:55
29 建议:将“关注度”更名为“收录标准” 23 13 Sanmosa 2021-05-14 18:55
30 提議在指引層面對移動頁面的機器人或機器用戶做出規範 5 4 Kanashimi 2021-05-14 05:29
31 條目標題、內文及重新導向頁面標題中對SARS-CoV-2的變種的稱呼 7 3 Liu116 2021-05-16 14:02
32 7DAYS的第七次讨论 9 5 Temp3600 2021-05-16 00:04
33 針對WP:小小作品的事實性修訂 1 1 Koala0090 2021-05-16 11:43
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時,
請先檢查設定是否有誤

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

導航模板請參閱此。導言請參閱此

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

已解決
已由痛心疾首Xiplus等人手動修復。--Xiplus#Talk 2021年5月16日 (日) 02:56 (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年5月13日 (四) 04:29 (UTC)

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

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

併入第五階段。-- 五歲抬☎️·☘️) 2021年5月16日 (日) 07:25 (UTC)
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

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


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

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

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


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

其他事項编辑

結以待續。-- 五歲抬☎️·☘️) 2021年5月16日 (日) 07:30 (UTC)
下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

※註:第二點五階段還有東西在詢問。-- 五歲抬☎️·☘️) 2021年5月6日 (四) 02:58 (UTC)

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

專題命名空間(第五至六階段)编辑

[編輯此導航模板]

導航模板請參閱此。導言請參閱此

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

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

本案進入倒數第二個部分。現在將討論未來專題捷徑如何設立,以及原有捷徑的去留:
  • 未來是否允許建立跨WP與PJ空間的捷徑?如果需要,是否需要進一步規範?
  • 未來是否允許建立跨WP與PJ空間的非捷徑的重新導向?
  • 舊有的跨WP與PJ空間的捷徑是否需要清除連入然後(×)删除
cc.@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)

重行公示7日。SANMOSA Σουέζ 2021年5月14日 (五) 13:12 (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)

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

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

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

[編輯此導航模板]

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

  • 格式手冊及長期破壞者提升為命名空間,英語名稱待定;
  • 格式手冊及長期破壞者成為偽命名空間,縮寫為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)
  說明由於目前有些其他意見,第五階段公示暫停。-- 五歲抬☎️·☘️) 2021年5月13日 (四) 04:33 (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)
@生米一粒:我想了想,關於標點符號,可以先寫「關於標點符號的時候,同樣根據上述規則使用,當遇到以下幾種情況時,根據下述內容命名」。 --Loving You Is A Losing Game 2021年5月12日 (三) 17:01 (UTC)
好的。最初主要是看到QQ音乐上这首歌的歌名,逗号后面是有空格的(而且正式的英文书面语法中,逗号后面都是有空格的)。后来看了下日文那边的歌名,是半形逗号后面没有空格,直接跟了日文,所以就接受了这个写法。虽然我还是更倾向于半形逗号后面加上半形空格,但现在这样也能接受。生米一粒留言) 2021年5月12日 (三) 19:21 (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)

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

後續處理编辑

@AnYiLin:能處理一下剩餘的ER嗎,還有幾個尚未完成:

以上。--LuciferianThomas留言 2021年5月12日 (三) 00:24 (UTC)

抱歉,编辑:仅允许管理员。--安忆Talk 2021年5月12日 (三) 04:29 (UTC)
@XiplusSANMOSA Σουέζ 2021年5月12日 (三) 06:28 (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代碼對表格背景加入花俏的樣式(如漸層色等)。

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

提議條文

颜色及内联图像

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

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

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

以上。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代碼對表格背景加入花俏的樣式(如漸層色等)。

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

提議條文

颜色及内联图像

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

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

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

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

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

  • 與正文內容密切相關,不使用就無法(或很難)準確闡釋條目內容;
  • 編者有理由相信電腦無法正常解碼和顯示;
  • (非強制)有對應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)中「設法在不破壞其他已完成部分,將一柱轉成  。」不使用內連圖像怎麼描述?「設法在不破壞其他已完成部分,將一柱轉成『清楚辨識到可見之兩個面的中心塊與下方塊是相同的顏色,同時,左側最右上方式底面的顏色、上方為左側面的顏色、右方與該面之中心塊同色且角塊右邊的邊塊顏色與左方的角塊同色且方向相同』或『清楚辨識到可減兩個面的中心塊與下方塊是相同的顏色,同時,左側最右上方式做側面中心塊的顏色、上方為右側面的顏色、右方與底面同色且不可見之面之右側面之角塊的頂部顏色與可見面之左側面之中心塊同色』。」這樣的可怕的文字來描述嗎;
    • 那麼這種又要怎麼辦「當方塊變為
      時」({{模板樣式色塊圖}})→「當方塊變為『方塊下兩層已完成,且頂面顏色在頂面上呈 (不用圖片無法表達)形狀時,頂面靠近自己本身的地方是不可見面右側面之中心塊顏色,頂面右側前方(靠近不可見面)兩塊與可見之左側側面同色、頂面左側兩塊與可見之右側側面同色....』時」。(-)反对到時許多條目,不限於魔術方塊都要用可怕的東西描述,WP:太長不看,編者不會想看到一堆廢話,條目失去功能。
      關於上述提到的 ,類似的例子例如俄羅斯方塊,你描述 ,文字描述用L型,可是他仍有非常多種變體
       
      不使用內連圖像,怎麼準確表達
    • Unicode亦有無助於文字表達的字元,用起來跟 這樣的图像沒有兩樣,例如Unicode字符列表#特殊Unicode幾何圖形列表方塊元素、麻將字元、撲克牌字元(見章節扑克牌#歷史)...等
    • 關於顏色,有的Unicode字元還會自帶顏色,例如Emoji
    • Unicode字符列表#盲文圖案點字該不該禁?「未收錄點字
    ※其他關於顏色或Unicode事項待補;會在找到時補充。
    以上-- 五歲抬☎️·☘️) 2021年4月15日 (四) 04:17 (UTC)
(▲)同上 2021年4月15日 (四) 11:27 (UTC)
魔方问题可以像英语维基百科那样用右侧图像,或者像论文那样<gallery />加“如图1”。一图胜千言,但没看出图像非要内联的理由。而且  
这三个内连例子真心一点都不大方,图片小小、看着眼晕;图片优势没发挥出来不说,还搞到正文稀稀拉拉的。至于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)
(~)補充另外,關於「
」的描述,我認為應該要這樣「方塊下兩層已完成,且頂面顏色在頂面上呈 形狀時....」不然圖像還要引用旁邊另外圖像,真的很詭異。-- 五歲抬☎️·☘️) 2021年4月16日 (五) 05:40 (UTC)

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

   
圖1.1 圖1.2
  • 這樣一來,魔方的圖案想再放大些都不怕影響排版。
  • 摺紙的案例和索馬立方的案例一樣,可以製作表格或圖片庫,不需使用內聯圖像。
  • 天文學符號完全可以在表格或者Infobox裏面用,不需用作內聯圖像。
  • 中華民國國語那個注音符號,以及那個阿拉伯樂譜符號,都已經符合「與正文內容密切相關,不使用就無法準確闡釋條目內容」的例外條件。
  • 至於PlayStation濱崎步的案例簡直就是邊緣得不能再邊緣了。PlayStation的那句營銷口號,完全可以上傳一張自製圖片來表示,反正像    這種簡單的幾何符號,是怎麼都達不到原創性門檻的。濱崎步的案例已經涉嫌過量使用非自由圖像,違反《WP:NFCC#3了。
另:@Lopullinen1233:小弟新增了無正當理由禁止使用什錦字型繪文字的條文,請回應。📕📙📒📗📘📚📖 2021年4月16日 (五) 06:19 (UTC)
  • 內文其實禁止更改字體的,不過無意見。--1233 T / C 2021年4月16日 (五) 08:11 (UTC)
  • (:)回應我認為索馬立方摺紙與正文密切相關。天文符號其他例子例如電路符號、化學特殊符號、化學結構式(有苯環的)生物學符號,我不建議在旁邊放成表格,一堆一個小符號整理成表格非常詭異。以及「
    :頂面顏色在頂面上呈 形狀」的 亦與正文密切相關。同時,整個連純文字也包成圖片放旁邊表格將會有「無法複製其中文字」的缺點。-- 五歲抬☎️·☘️) 2021年4月16日 (五) 06:27 (UTC)
  • 小整理一下,以便針對點討論
    • 已解決的問題
      • 自身有獨特排版,且為學術界慣例,又需要顏色表達之表格
      • 無法使用現有文字代替的符號(打不出來的字,或者非自然語言表達範疇之記號)
        • 未收錄漢字(如{{缺字}})
        • 數學符號(如{{CDD}})
        • 樂譜記號
        • 特殊的語言
    • 未解決問題
      • 可以用排版代替顏色的表
        • 地質年代表的背景色。
        • 生物保育狀態的背景色。
      • 可以使用現有文字代替的符號
        • 天文符號
        • 化學結構式
      • 具表意功能圖示使用時機
        • 如摺紙圖示
        • 文字不易描述的瑣碎形狀圖示(一句話出現多種時,使用表格反而雜亂)
        • Emoji、繪文字
        • 什錦符號
      • 特殊標語口號
        • 「LIVE IN Y UR W RLD. PL Y IN  URS」(整個做成圖片將會導致文字複製困難)
        • LaTeX
    以上-- 五歲抬☎️·☘️) 2021年4月16日 (五) 07:06 (UTC)
在我看來明文限制使用顏色或內文圖片會造成很多麻煩,更不應該直接限制着色,應當按照情況逐例處理;例如在有用戶提出更好減少使用顏色的情況下,若內容不造成明顯閱讀困難就應儘量以顏色較少的方式處理(即指排版妥當;不應以「比較那個比較方便閱讀」為準則,只要整體不造成閱讀困難即可)。列表條目中適當使用顏色協助用戶進行分類,限制用色比限制着色更實際。--LuciferianThomas留言 2021年4月16日 (五) 09:41 (UTC)
  • 「地質年代表的背景色」和「生物保育狀態的背景色」我在上面已經說過符合例外條件,因此不屬於「未解決問題」。嚴格來說,俄羅斯方塊的圖像也屬於「與正文內容密切相關,不使用就無法準確闡釋條目內容」,只是編者有責任證明非使用內聯圖像不可。
  • 我加入了或者以LaTeX製作的科學表述,以包括數學公式和化學方程式等。
  • 我粗略閱讀了《》、《》等化學條目,裏面的圖像都不算「內聯圖像」。「內聯圖像」是指插入段落之內,文字之間的圖像。但這些條目當中的圖像都是用在段落之間,而非段落之內,因此不符合「內聯圖像」的定義。
  • 天文符號可以在表格或Infobox裏使用,不需使用內聯圖像。
  • 「LIVE IN Y UR W RLD. PL Y IN  URS」這種標語是不是非加入不可?「導致文字複製困難」似乎暗示閣下打算複製粘貼到其他條目,但除了PS條目本身以外,還有哪些條目非有這條標語不可?
  • @LuciferianThomas:限制著色是為了防止出現像某個IP對《追夢 Do Re Mi》瘋狂著色的情況再次出現。而我提出「一種邊界色、一種標題欄背景色、一種標題欄文字色,除非能自證有理」是為了方便執行,盡可能壓制遊戲維基規則的空間。另外,我在上面的提案也有限制用色的條文:「背景色飽和度不能太高」。
歡迎回應。A25698751233LopullinenPseudo ClassesSanmosa蕭漫Lab06 N羊羊32521📕📙📒📗📘📚📖 2021年4月16日 (五) 15:29 (UTC)
  • 關於複製,我指的是會困擾讀者,讀者將無法或難以複製該文字。維基百科不應搞得像那種讓讀者複製不了東西的神秘部落格,且讀者理應要能夠方便地複製「LIVE IN Y UR W RLD. PL Y IN  URS」以便到其他地方利用或查詢其他相關資料,整個包成圖像你是要讀者去研究影像辨識和機器視覺??;另外「有對應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 Y UR W RLD. PL Y IN  URS」包装成图像读者能理解,那就不应该使用内连图像;再说这东西复制出来居然是“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)
  • (-)反对同Owennson意見一樣。特特留言) 2021年5月15日 (六) 19:34 (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)

cc@蟲蟲飛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),公示已結束(10天前)(更新)-- 五歲抬☎️·☘️) 2021年5月5日 (三) 10:00 (UTC)

  •  通過:公示期已過,且已逾時超過一日(10天前),在公示期將結束至此刻(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|快速删除理由}}"},
  • 位于模块名字空间的页面(文档页面除外):请使用以下语法:
    require('Module:Module wikitext')._addText('{{Delete|快速删除理由}}')
  • CSS页面:请使用以下语法:
    ._addText{
    	content:"{{Delete|快速删除理由}}";
    }
    
  • JavaScript页面:请使用以下语法:
    var _addText="{{Delete|快速删除理由}}";
  • 純文字CSS(包括“已过滤的CSS”)和JavaScript(不包括JSON)也能通過在注释中使用以下語法來放置模板。
    /* _addText: {{Delete|快速删除理由}} */
  • 對於部分有特殊編輯介面的特殊頁面(如FLOW討論頁大量訊息發送列表等)請直接將提刪模板放置於對應頁面的描述或摘要欄位即可。
    例如,提刪FLOW討論頁時,請使用「編輯話題摘要」功能將{{Delete|快速删除理由}}填入;而提刪大量訊息發送列表時,請將提刪模板放置在「描述」欄位中。
  • 註:由於技術限制,在JSONFLOW討論頁純文字放置模板後暫時不會自動被加入分類,因此在提刪此類頁面時可能還需要另外通知一位管理員來執行刪除。

管理员操作注意事项 ……

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

限縮{{電視節目的變遷}}模板使用範圍编辑

—以上未加入日期時間的留言是于2021年5月16日 (日) 02:48 (UTC)之前加入的。

设立过滤器禁止将维基百科用作来源编辑

在修订爱丁堡公爵菲利普亲王的时候,我发现有用户将维基百科条目用作来源,由于维基百科早有方针禁止在条目中使用维基百科作为来源,这类编辑显然违反有关方针。然而,维基百科上引用维基百科的条目实在不少,例如以中文维基为例,证明这些方针一直以来未能发挥有效作用。故在此建议设立过滤器,禁止在引用中使用维基百科的内容(URL或者内部链接)。--百战天虫留言) 2021年4月12日 (一) 13:03 (UTC)

請提供至少5筆編輯差異供測試。--Xiplus#Talk 2021年4月12日 (一) 13:11 (UTC)
巡查員申請條件嗎www-- Sunny00217  2021年4月12日 (一) 13:21 (UTC)
不足100条,应当清理。过滤器可以打标签,至多警告,阻止不建议,可能有合理的WP:自我参照和其他值得保留内容,清理这种内容也不会太麻烦。--YFdyh000留言) 2021年4月12日 (一) 13:18 (UTC)
@Xiplus:是指这类条目的编辑差异吗?--百战天虫留言) 2021年4月12日 (一) 13:50 (UTC)
您認為應該被阻止的「那筆編輯」,盡量在1個月內的編輯。--Xiplus#Talk 2021年4月12日 (一) 13:53 (UTC)
1个月内的比较难,更久一点倒可以找。--百战天虫留言) 2021年4月12日 (一) 13:58 (UTC)
如果情況過少就可能不會考慮建立過濾器,當然可以先建立看看實際觸發量,但不排除在確認過少後停用。--Xiplus#Talk 2021年4月14日 (三) 15:36 (UTC)
也可以按照上面的意见做个警告加标签,暂不设立过滤器。不过现在有引用的肯定要清理了。--百战天虫留言) 2021年4月14日 (三) 15:56 (UTC)
@Xiplus:阁下的意见?--百战天虫留言) 2021年4月18日 (日) 07:34 (UTC)
或者將Special:滥用过滤器/39不可信來源中的豁免取消掉。--Xiplus#Talk 2021年4月18日 (日) 07:54 (UTC)
本人不怎么看,就是个路人,罢了--Raptor (Unknown)
所以现在有两种方案,一是对引用维基百科的编辑加警告和标签,二是将第39号滥用过滤器的不可信來源中的豁免取消掉,欢迎大家发表意见。--百战天虫留言) 2021年4月21日 (三) 05:20 (UTC)
无必要,本人的机器人会自动清理。--Antigng留言) 2021年4月21日 (三) 07:39 (UTC)
阁下能不能列举几项编辑记录?--百战天虫留言) 2021年4月24日 (六) 09:12 (UTC)
上面那个链接里用标签筛选出来的都是。--Antigng留言) 2021年4月24日 (六) 10:56 (UTC)
清理归清理,打标签归打标签,事先设过滤器警告的话也能减少机器人清理工作量。--60.248.43.141留言) 2021年5月2日 (日) 04:42 (UTC)
(-)反对。將維基百科條目放入參考來源,偶爾是合理的。有一些編者習慣用參考來源的方式書寫註釋,例如「關於XXX的YYY方面,可參閱某個條目」。--Yangwenbo99 2021年4月26日 (一) 00:07 (UTC)
@Yangwenbo99:就像閣下的示例,要使用內鏈而非外鏈-- Sunny00217  2021年4月28日 (三) 14:16 (UTC)
查了一下有出現 "en.wikipedia.org" 的條目,其實數量比中文的更多--Wolfch (留言) 2021年4月28日 (三) 01:32 (UTC)
那就是T:link-en的回合了-- 本人該補完2019年台鐵各站旅客人次了,有事按「此」留言 2021年5月3日 (一) 14:37 (UTC)
有些是單純的跨語言連結,是T:link-en的回合,不過其中不少是用英文維基網址作為參考資料。--Wolfch (留言) 2021年5月3日 (一) 15:01 (UTC)
@Xiplus:雖然用戶Antigng的機器人會清理裸網址形式的內部連結,但是對於使用「<ref>wikipedia.org</ref>」這種形式的似乎無法處理,以目前的情況是否需要設置過濾器禁止或警告這種形式的參考引用?--Poontele留言) 2021年5月14日 (五) 18:24 (UTC)

订立编辑松相关规章制度编辑

上次中塞编辑松由于主持人Walter Grassroot的一些行为对社群造成了恶劣的影响。实际上截至目前本地并没有对编辑松的举办、规则的订立相关的方针或指引,为避免再次发生类似于中塞编辑松的恶劣事件,本人提议在本地订立编辑松的相关指引。我认为至少可以作以下要求:

  1. 在提出举办编辑松时,需将举办计划提交至互助客栈由社群审阅;
  2. 编辑松规则订立时,不得订立任何歧视维基人的规则;
  3. 规则订立完成后,同样需要交由互助客栈审阅;
  4. 编辑松开始之后,除非规则有重大问题,否则不得修改编辑松规则。

以上。--忒有钱🌊塩水あります🐳留言) 2021年4月17日 (六) 18:46 (UTC)

(+)支持。完善制度比指責個別人對維基百科更加有益(但這不代表無人需要為之前的紛擾負責)。--Yangwenbo99 2021年4月17日 (六) 22:35 (UTC)
(-)反对,提议者本身就是此次闹剧的编造者,此事本身就是对大陆社群的污名化行动。目前又想伪造社群共识以实现对中国大陆社群的侮辱既定事实。对此我表示坚决反对。门可罗雀的霧島診所三天打鱼两天晒网神社的羽毛飘啊飘 2021年4月18日 (日) 03:53 (UTC)
  • 我也是中国大陆人,而且现在就生活在中国大陆,大陆人和大陆人之间能有什么坏心思呢?(确信)--忒有钱🌊塩水あります🐳留言) 2021年4月18日 (日) 04:54 (UTC)
    • 其实我也好奇为什么热衷于打压和破坏大陆社群的老管理员为什么都是大陆人。。。。。--飞贼燕子留言) 2021年4月19日 (一) 23:22 (UTC)
      「規管和(要求)遏止不恰當的行為就算是『打壓』和『破壞』」這種歪理是不會被社羣認可的。SANMOSA Σουέζ 2021年4月20日 (二) 04:50 (UTC)
      当年某位把占海特一家领到活动场地进行蹭热度和政治活动的时候可没听说过那条管规和指引让他们这么玩,但这并不妨碍那些管理员把反对和知道真相的用户一个一个封掉以企图掩盖的行为。不过有一点你说的很对,后来的事实证明那几个管理员的歪理确实没有被社群认可。--飞贼燕子留言) 2021年4月20日 (二) 07:50 (UTC)
      這是站外的東西,站內無權管,沒必要將這些站外的恩怨帶進站內,反正當事人以外的任何一個人都對此沒有興趣。SANMOSA Σουέζ 2021年4月20日 (二) 12:53 (UTC)
      • 站内无权管当初干嘛心虚的不得了,封人家捂人家嘴还处处针对别人,大家早就都知道他几个是干什么职业的了,掩盖的多了吧那叫歪理。--飞贼燕子留言) 2021年4月21日 (三) 02:10 (UTC)
        你不先想想在站內討論不斷張貼一堆和本站無關的東西(i.e. 離題討論)是否恰當?我不清楚事件的大概,但至少這點是肯定適用的。現在討論頁指引是被廢了嗎?(我不只是說你上面提及到的事件,我也是說你現在的留言本身。)SANMOSA Σουέζ 2021年4月22日 (四) 04:02 (UTC)
  • 我不知道忒有钱君什么时候成为“此次闹剧的编造者”的。Eric君被Walter君踢出WMC编辑群,忒有钱君在互助客栈请求取消Walter君的WMC编辑群管理员职务。后来该讨论才演变成对Walter君移除编辑松条目的讨论。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月18日 (日) 05:30 (UTC)
  • 上面那個投反對票的不關注忒有钱的提議是否有道理,上來就訴諸人身。提議有提到「不得订立任何歧视维基人的规则」,所以你是不反對此類歧視性規則咯--Googol19980904留言) 2021年4月18日 (日) 11:20 (UTC)
你们组织的所谓社群,党同伐异,异己者唯除之而后快,连制定规章都要反对。--𢿃𠫱留言) 2021年4月19日 (一) 04:44 (UTC)
这里明明是在谈防止公报私仇行为的再次出现,不要扯到地域问题上来。--🔨留言) 2021年4月19日 (一) 10:53 (UTC)
呼籲各位理性討論,另霧島聖閣下“闹剧的编造者;就是对大陆社群的污名化行动;又想伪造社群共识以实现对中国大陆社群的侮辱既定事实“均已涉嫌針對用戶個人的人身攻擊,以個人經驗敬請閣下不要這麽做。---維基百科最忠誠的反對者留言) 2021年4月21日 (三) 19:11 (UTC)
(▲)同上WP:AGFWP:CIV轻率鲁莽地指控他人行为不当。--Steven Sun留言) 2021年4月24日 (六) 12:57 (UTC)
(▲)同上。--14-5-2@维基抗生素协会 2021年4月18日 (日) 04:09 (UTC)
上面那個投反對票的本身就是很多爭議的製造者,甚至假定惡意來封鎖使用者,真是八兩笑一斤。 2021年4月18日 (日) 16:09 (UTC)
八兩笑一斤?百步笑五十步比較準確吧。--Yangwenbo99 2021年4月18日 (日) 16:53 (UTC)
我是指他自己份量太輕,竟然指責(笑)比自己份量更重的人。 2021年4月19日 (一) 00:38 (UTC)
不限于编辑松,任何对外合作的编辑活动建议在开始前将活动规则在公开讨论中报备一次,并且避免产生会对特定或所有编辑不友好的行为。我认为这个提议可以考虑,——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年4月19日 (一) 01:00 (UTC)
同上。提案本身是沒有問題的。SANMOSA Σουέζ 2021年4月19日 (一) 01:35 (UTC)
(+)支持,强烈譴責因為一己私欲敗壞社群名聲的行為。--Newbamboo留言) 2021年4月19日 (一) 04:36 (UTC)
(+)支持,同上。----𢿃𠫱留言) 2021年4月19日 (一) 04:40 (UTC)
一、你這個編輯松的定義是甚麼?動員令、亞洲月(及其附屬活動)算不算?安可牌條目提升計劃算不算?如果動員令、亞洲月算,我認為兩者都應該獲得豁免(近十年來,曾經有兩三個人意圖擾亂動員令,但最後都折戟沉沙)。二、個別編輯松的主辦者制定規則排斥個別用戶,這應該用NPA、CIV處理。三、可以考慮為編輯松的舉辦流程制定原則、指引和違規處理機制(不要求為綜合文本,可散見於不同頁面),但不贊成舉行甚麼編輯松都要上客棧報備,這樣容易橫生枝節。--春卷柯南-發前人所未知 ( ) 2021年4月19日 (一) 10:39 (UTC)
一:动员令只是中维站内活动,当然不算;亚洲月本就是与其他语言联合举办的编辑松的一种形式,需要算在内。二:(✓)同意,但最好还是先定下规则(我认为我草拟的规则中第四条非常重要)。三:未必是上客栈,可以用专用页面(比如Wikipedia:编辑松的子页面)。--忒有钱🌊塩水あります🐳留言) 2021年4月19日 (一) 21:07 (UTC)
一、你這個定義標準是站不住腳的,編輯松的本質就是鼓勵別人做編輯,寫條目的活動啊,而動員令和亞洲月都是條目競賽。二、暫時不回覆。三、我的意思是說報備這一步是不必要的。一個通知還不夠嗎?如果通知以後,有一群人認為事情不對勁,也就是在客棧事後審查,一如目前的做法。--春卷柯南-發前人所未知 ( ) 2021年4月20日 (二) 13:46 (UTC)
@春卷柯南:(1)認同你的見解,但需要考慮到的是協調各維基百科的亞洲月的相關人士未必清楚本站內負責的主持人的主持方式是否恰當,因此不贊同豁免亞洲月。(3)2月的事件已經證明了事後審查的成效不大。雖然說那三個核心人物之一已經獲得處理,但明明問題就已經存在而且非常明顯了,到現在還是有人敢公然向大家說不存在問題,就已經證明了現在編輯松的舉辦者會走通知程序的漏洞,然後恣意妄為,並且把這當成常態。如果沒有人濫用現行程序,我相信他也不會走出來提這案。SANMOSA Σουέζ 2021年4月21日 (三) 03:16 (UTC)
支持社群采取一切合理措施阻止个别有过公报私仇前科且拒绝认错及改善的编者担任往后一切活动(包括但不限于动员令和编辑松等)的主持人,及阻止活动中一切存在显著问题及争议规则的制定与实施,如果无法阻止编辑松由有公报私仇前科且拒绝认错及改善的编者担任其中一位主持人,或无法阻止存在显著问题及争议规则在编辑松当中的出现,则支持社群采取一切合理措施阻止相应编辑松在本站的宣传。--🔨留言) 2021年4月19日 (一) 11:44 (UTC)
(-)反对,好像每次举办社群活动的时候一般会向社群发通告吧,几位的意思是不经过几位批准以后大家都别搞了是吧。不知几位是打算怎么审批呢?是打算投票比人头呢还是在客栈聚众扯皮呢?个人觉得这个提议当个笑话看看完了没必要去较真。--飞贼燕子留言) 2021年4月19日 (一) 23:06 (UTC)
社羣討論的共識或大方向一旦不合己意就胡亂聲稱其已失效,這不是只有你一個人正在做的事情,但大家都在看著。SANMOSA Σουέζ 2021年4月20日 (二) 04:50 (UTC)
我也不見得籌辦編輯松的程序開誠布公是壞事(所有社羣成員都能就此發表意見),除非籌辦者意圖利用編輯松進行違反使用條款和方針指引的事項。SANMOSA Σουέζ 2021年4月20日 (二) 04:55 (UTC)
  • 怎么办活动怎么办好像参与和组织者都会写在公告上谁都可以看吧,不觉得谁会举办前就在公告里刻意违反规则指引啥的,再者个人不觉得谁会听一个完全无关闲人去批准同不同意。--飞贼燕子留言) 2021年4月20日 (二) 07:31 (UTC)
    但舉辦期間這樣做的情況已經出現了。社群作為編輯松的參與者,怎麼可能是「閑人」?不然編輯松是開來做甚麼的?SANMOSA Σουέζ 2021年4月20日 (二) 12:53 (UTC)
    「不觉得谁会举办前就在公告里刻意违反规则指引啥的」——上一次活動是在活動中更改規則,違反指引的。--Yangwenbo99 2021年4月21日 (三) 03:34 (UTC)
  • 操作涉及操作问题一次不行下次可以修正,社群活动的参与者不少但是那些喜欢捣蛋的闲人也一样不少。方针规则这东西这次你能用下次别人一样能拿来用,届时就社群活动就谁都别搞不了只能在互助客栈扎堆审查扯皮,我看这个提案就是为那些闲人在社群活动时审查扯皮捣蛋准备的提案。--飞贼燕子留言) 2021年4月21日 (三) 02:10 (UTC)
我不介意重複一次上面的話:「社羣討論的共識或大方向一旦不合己意就胡亂聲稱其已失效,這不是只有你一個人正在做的事情,但大家都在看著。」「社群作為編輯松的參與者,怎麼可能是『閑人』?」(還是說,你已經把特定的社群參與者,不當成是社群的一分子,然後要把他們排擠出去?)你的反對理由是完全無效的。SANMOSA Σουέζ 2021年4月21日 (三) 03:07 (UTC)
「届时就社群活动就谁都别搞不了只能在互助客栈扎堆审查扯皮」——所以閣下認為舉行「社羣活動」不需要取得「社羣共識」?會導致「扎堆审查扯皮」的操作必然是爭議性操作, by definition, 而閣下是否認為在社羣活動的規章之中進行爭議性操作是適當的?「操作涉及操作问题一次不行下次可以修正」——制訂規則就是為了防止之後出現類似問題。我明白閣下希望維基百科都是舉手機器,但是殘酷的現實是,維基百科有一批編者是有獨立思考能力的知識分子,而這當中有一部分人願意為維基百科的益處進行爭論。--Yangwenbo99 2021年4月21日 (三) 03:34 (UTC)
(竟然有這樣一句來著)「操作涉及操作問題一次不行下次可以修正」——之前2月的時候都已經「不行」了,之前的「下次」不就是現在嗎?SANMOSA Σουέζ 2021年4月21日 (三) 03:44 (UTC)
  • 其实我感觉您和我一样现在很想尝试下去给别人捣蛋让和毫不相关的人必须听我摆摆的感觉,但为了保证以后不出什么大家担心的长期的大乱子我感觉您还是哪里凉快上哪里歇,冷静下的好。--飞贼燕子留言) 2021年4月21日 (三) 08:59 (UTC)
    不要一來就直接不斷說其他人「搗蛋」(我超想說這句很久了),不然按照你的邏輯,現在氣候暖化這麼嚴重,冷靜不下來的人很有可能是你。「站外的東西,站內無權管,沒必要將這些站外的恩怨帶進站內」,這句話容許我再抄送一次,可惜有很多人一直都不懂。SANMOSA Σουέζ 2021年4月21日 (三) 09:03 (UTC)
    “个人觉得这个提议当个笑话看看完了;感觉您和我一样现在很想尝试下去给别人捣蛋让和毫不相关的人必须听我摆摆的感觉;我感觉您还是哪里凉快上哪里歇,冷静下的好。”上述語句個人認爲涉嫌輕蔑其他編輯及訴諸人身,容易引起爭議,請投下否決票的兩位用戶注意言辭。維基百科最忠誠的反對者留言) 2021年4月21日 (三) 19:28 (UTC)
(+)支持(!)意見對於未就本次提案提供建設性意見、訴諸人身且屢次樹立稻草人論證之類的發言及投票(包括以此無理理據之“同上票”),我本人建議按照维基百科:建设性意见在内的方針指引將其作廢,不納入討論共識之考量。另同Newbamboo閣下對於任何為主張/闡釋/維護個人立場及觀點敗壞本站名譽的行爲表示最强烈之譴責。--維基百科最忠誠的反對者留言) 2021年4月21日 (三) 19:42 (UTC)
現在並沒有投票。--Yangwenbo99 2021年4月22日 (四) 18:52 (UTC)
  • 只是担心,如果社群专门出指引来规管编辑马拉松但无法覆盖每个方面,则很可能是无用功。--痛心疾首 2021年4月26日 (一) 03:19 (UTC)
  • 对于1和3,有一些在时效性上的担心。--安忆Talk 2021年4月27日 (二) 11:55 (UTC)

根据上方的意见,现将提案内容调整如下:

  1. 举办编辑松需要在本地创建专题页面(具体用编辑松专用子页面还是单独的项目页面另行商议),列出编辑松的举办时间、规则、主持人等必要信息;
  2. 编辑松活动不得有任何歧视维基人的规则;
  3. 编辑松开始之后,除非规则有重大问题,否则不得修改编辑松规则。

以上,欢迎补充。--忒有钱🌊塩水あります🐳留言) 2021年4月27日 (二) 11:48 (UTC)

  • 编辑冲突 我暂时不认同将编辑松相关事务方针指引。因为本人认为,上述多项内容是已有而不必要的,且有一部分属于部分维基人私意自治或可以自行协商的内容。
    举办编辑松需要在本地创建专题页面,列出编辑松的举办时间、规则、主持人等必要信息——任何正常举办的编辑松都不可能存在不明确的上述内容。如果有这种什么信息都没有的编辑松,可以理解为扰乱行为,相关页面应该是符合纯粹破坏而被快速删除的。
    编辑松活动不得有任何歧视维基人的规则——任何歧视维基人的行为当然违反文明方针Openness决议的。
    除非规则有重大问题,否则不得修改编辑松规则。——这个纯属相关举办方的私意自治范畴,我不认为社群应该直接介入,除非涉及上一点。
    至于出事了怎么处理,无疑是处罚主持人。WG都被禁止了,这就是结果。--痛心疾首 2021年4月27日 (二) 12:08 (UTC)
    (:)回應请注意第一条的“本地”,之前中塞编辑松只在meta有专题页面,本地没有。--忒有钱🌊塩水あります🐳留言) 2021年4月27日 (二) 12:37 (UTC)
    注意到了,修改一下意见:如果有类似的规定,我仅能支持第一条。--痛心疾首 2021年4月27日 (二) 13:14 (UTC)
  • (-)傾向反對在本地訂立編輯松的相關指引。一來主辦方對編輯松的呈現方式應該有一定程度的自由,而且在提供連結和必要資訊的情況下,在本地建立頁面跟在meta或任何其他地方建立頁面的意義是相同的,為此不同意第一條;至於第二條和第三條,我相信之前的事情純屬特例,一般編輯松不會出現這麼離譜的事情,為了一次特例而去對往後的眾多社群編輯活動訂立規範是沒有必要的。真的再出現像上次的情況怎麼辦?痛心疾首閣下已經提供了解答。按本地和基金會方針處理應當足矣,社群的執行力才是重點。—— Eric Liu 創造は生命(留言留名學生會 2021年4月27日 (二) 15:24 (UTC)
(1)同意。(2、3)不然,此類事件有一即有二(就像出軌一樣),因此我認為編輯松規則的修改需要得到社羣授權方可為之,以加強社羣監察之效。規章制度的訂立本身有加強社羣執行力的效果。SANMOSA Σουέζ 2021年4月30日 (五) 05:46 (UTC)
我收回我“暂时不认同将编辑松相关事务方针指引”的看法,我认为将相关内容综合为一个指引或信息页是有必要的,有助于后来者避免触及一些错误。忒有钱Ericliu1912Sanmosa --痛心疾首 2021年5月5日 (三) 15:27 (UTC)
建立一個資訊頁(而非指引),整合涉及的全域、本地既有方針與指引或許是比較好的方案。—— Eric Liu 創造は生命(留言留名學生會 2021年5月6日 (四) 00:09 (UTC)

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

訂立影片加入相關指引编辑

我發現最近有很多條目中都被加入了影片,雖然其中不少都對條目大有裨益,但是我也發現相當一部分條目中被加入了與條目本身關係不大的内容或與條目本身不對稱的内容(比如在青藏高原條目加入中科院院士的演講影片和在小條目加入長達20分鐘的影片),所以想請問一下社群是否需要訂立相關指引來規範條目中的影片加入?--Newbamboo留言) 2021年4月20日 (二) 04:11 (UTC)

谢谢,这个是我在Telegram提起来的,WP:AGF的话是我确定这些内容是对维基百科的内容大有益处(尤其很多内容是我们这些普通编者很难接触到或者获取到的)的也非常感谢把他们传到commons的同仁,但是视频尤其新闻报道可能会涉及WP:NPOV的问题,即使没有NPOV问题也涉及到篇幅的问题(一个小作品里出现几十分钟的视频肯定是读者没有耐心去看的),我想了一下,有以下几个点可能可以改进:
  1. 针对新闻视频,提供新闻供稿人的名称,供读者自行辨识观点。
  2. 针对过长的视频,考虑进行剪辑或者进行截图,然后将截图插入条目进行展示。
  3. 或者如果实在认为新闻信息对条目非常宝贵,将新闻视频转写成文字的形式作为来源扩充条目。
不知道各位意向如何?--ParkerTian 2021年4月20日 (二) 04:21 (UTC)
@NewbambooPark1996:已有相關規範,見WP:VUPSANMOSA Σουέζ 2021年4月20日 (二) 04:28 (UTC)
虽然说针对视频资料过度使用影响阅读体验的问题,去年就已经修订相应方针来加以限制。不过就现在的情况来看,相关方针执行力度并不算强。--🔨留言) 2021年4月20日 (二) 06:25 (UTC)
@Liu116:有甚麼條目是違反相關方針的,請列出來,我動手清理一下,有人回退的話,我就依方針提報。SANMOSA Σουέζ 2021年4月20日 (二) 12:55 (UTC)
……这个我没法完整列出,我顶多只知道脱贫攻坚战条目中原本被移除掉的视频后来又都被加了回来,还有2019冠状病毒病疫苗条目,以及部分“202X年X月中国大陆”的条目也有这样的问题。--🔨留言) 2021年4月20日 (二) 13:08 (UTC)
我看到的是驻港部队有过多视频。好像很多都是WG君加入的,能不能跟他说一下让他自己改正呢--ParkerTian 2021年4月20日 (二) 18:33 (UTC)
當中兩段影片未獲正文提及,另有一段與正文關係不夠密切,已代為刪除。--Yangwenbo99 2021年4月20日 (二) 23:33 (UTC)
對於「加入影片」這一行為,已有相關規定——Wikipedia:文件使用方针#使用守則,即必須同時滿足
  1. 與條目有密切關連、
  2. 在條目內文有所提及、
  3. 符合中立的觀點(包括旁白、註釋),且比重需合理,及
  4. 僅保留具代表性之檔案,每條目一般不應同時存在多於五條影片。
而若在無共識的情況下將原本被刪除的影片重新加入,即屬蓄意挑起WP:編輯戰
建議加入一條「一般而言,新聞報導與條目所論述內容有關,並不代表其內容與條目主題直接相關。僅在該影片所論述之內容本身為所在條目或所在章節之主要論述內容時,方可被認為與條目主題直接相關。
另外,可以考慮將與內容相關,但是不便加入條目的影片放置於外部鏈接當中。甚至可以訂立指引,表示外部鏈接中可以設一節放置相關影片,以及規定收錄影片的標準。
此外,同意就編輯影片以便加入條目訂立指引。
以上。--Yangwenbo99 2021年4月20日 (二) 23:26 (UTC)
我總結一下上面的意見,並得出以下的提議條文:

以上。SANMOSA Σουέζ 2021年4月21日 (三) 03:56 (UTC)

虽然说追加视频时长的限制是好事,不过就目前的情况来看比起进一步追加条文,我觉得更重要的还是解决执行力的问题……不然加再多条文也没用……--🔨留言) 2021年4月21日 (三) 04:56 (UTC)
這可能要請管理員長期持續監察才能成事。SANMOSA Σουέζ 2021年4月21日 (三) 08:54 (UTC)
(-)反对:原有条文足矣,不必更易。这些问题不是条文的问题,而纯属执行力问题。--痛心疾首 2021年4月21日 (三) 07:24 (UTC)
原有條文的執行力差,部分原因是條文本身部分論述較為籠統,所以應當具體化。如「僅保留具代表性之檔案」,但對於檔案長度的要求未有規定。以及未有規定如何處理不應放置於內文,但有相當重要性的影片。--Yangwenbo99 2021年4月21日 (三) 15:31 (UTC)
意見大致同Liu116閣下及痛心疾首閣下。若方針無人執行,增加再多規範也是無用。—— Eric Liu 創造は生命(留言留名學生會 2021年4月21日 (三) 12:57 (UTC)
過濾器能不能幫忙?SANMOSA Σουέζ 2021年4月22日 (四) 04:07 (UTC)
@Sanmosa:可以设立过滤器“标签”“條目同時存在多於五條影片”的情况;但是既然方针规定“一個條目一般不應同時存在多於五條影片”,设立过滤器加以警告乃至阻止就需要社群共识后才能设立。--Antigng留言) 2021年4月22日 (四) 05:51 (UTC)
@Antigng:既然技術上過濾器能幫忙,我嘗試徵求社羣對過濾器的意見,有共識的話就有勞你代為設立了。SANMOSA Σουέζ 2021年4月25日 (日) 08:07 (UTC)
@Liu116痛心疾首Yangwenbo99Ericliu1912:不好意思,最近疏於關注了。上面Antigng指出了技術上可以以過濾器防止條目同時存在多於五條影片(我估計技術上也可以以過濾器防止加入曾被移除的影片),因此我建議設置過濾器,阻止使條目同時存在多於五條影片的操作,並對加入曾被移除的影片的操作予以警告,同時對此兩類操作予以標籤。相信此提議應可增強相關方針的執行力度,還請各位發表意見。SANMOSA Σουέζ 2021年4月25日 (日) 08:07 (UTC)
加入超過五條影片,偶爾也是合理的。例如化学史的條目,如果有編者分別為不同時期的歷史製作影片並放入對應章節,那麼即使超過五條也依舊可以接受。使用過濾器強制條目中影片數量少於五條則完全否定了這種行為的正當性,並且會衍生大量技術問題。例如,有編者將原本冗長的一條影片提換成兩條截取至原影片的精煉影片,則可能因為增加影片被阻攔。私以為過濾器可以用於提供警告,但不適宜直接禁止。--Yangwenbo99 2021年4月25日 (日) 08:46 (UTC)
@Yangwenbo99:此情況罕見。而且方針已明定加入超過五條影片者要給予合理解釋,也即是須先取得社羣共識方得為之。這種情況下,應先取得社羣共識,然後到過濾器錯誤回報區請求代為加入。(另一辦法是對所有使條目存在超過五條影片的編輯予以警告。)SANMOSA Σουέζ 2021年4月30日 (五) 05:35 (UTC)
我认为应该予以一次警告并进行标记,阻止不是必需的。--痛心疾首 2021年5月5日 (三) 15:46 (UTC)
VUP沒有通過的話確然如此,然而這已經被現在已經通過的VUP明確為屬於違反方針的舉動了,這樣阻止反而是必需的。SANMOSA Σουέζ 2021年5月6日 (四) 01:54 (UTC)

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

关于“个人贡献”之“机械翻译工具”所衍生问题相关讨论及方案探讨编辑

“请勿使用机器翻译翻译条目,无论使用哪种机器翻译软件或网站,条目的质量通常都会差到让人难以理解。我们强烈不建议在机器翻译基础上进行编辑。”

如题,见维基百科:翻译指引#翻譯注意事项。是否需要为避免机翻或以此衍生相关的问题(如是否可将此视作“特例”)为由增修该指引或者废除“翻译”页面之机械翻译工具? - 维基百科,自由的百科全书 (wikipedia.org)--維基百科最忠誠的反對者留言) 2021年4月21日 (三) 18:49 (UTC)

否,答案是否定的,有時翻譯整篇條目會很花時間,有這樣工具的協助,能縮減使用者翻譯的時間,最後可能只需要改一下語氣、用詞和通順度而已。您在這發起討論也沒用,全域幾乎都有開啟翻譯工具,應該不可能只讓中文維基百科成為例外。更何況,如果機器翻譯後,修改的部分沒有很多,也不會讓您發布條目。 2021年4月22日 (四) 02:20 (UTC)
是,一來這種工具的存在是鼓勵翻譯者不查看外文版原始文獻,即將條目連帶來源整個搬運過來,如外文版本中有錯誤(錯誤解讀文獻、或文獻無法佐證條目內容等),會直接將其錯誤移植到中文維基之中;二來使用此工具再「改一下語氣、用詞和通順度」而成的條目正是相當危險、完全不值得鼓勵的,英翻中的機器翻譯技術仍不成熟,翻譯結果充滿錯誤難以參考,使用機器翻譯後再人工修改(假設翻譯者中文功力了得,可以完全解決翻譯腔的問題),可能消除了翻譯腔,卻產生「通順的錯誤內容」,後者對中文維基的危害顯然更大。
但是如上所述,全域幾乎都有開啟翻譯工具,基金會本身也非常支持這些工具的開發,所以我們在這裡討論也不會有什麼作用.....--Labyrinthulomycetes🧬 2021年4月22日 (四) 06:58 (UTC)
只停用機器翻譯可行的。--Xiplus#Talk 2021年4月22日 (四) 09:15 (UTC)
遇到看不懂的、拙劣翻譯的條目提刪不就好了。--Googol19980904留言) 2021年4月23日 (五) 03:31 (UTC)
@靖天子:您覺得DeepL翻譯的翻譯品質如何?--Googol19980904留言) 2021年4月23日 (五) 07:59 (UTC)
沒有用過,不清楚。但即使比現有的機器翻譯工具好,我仍不認為應該用來寫作條目。因為即使是翻譯條目,也應該是個「編譯」的過程,即重新組織、增減、修改原文的內容(過程中經常需要參考其他文獻),而非直接將條目翻到中文。熟悉外文的人,直接翻譯會比使用機器翻譯再修改快得多,而不熟悉外文的人使用機器翻譯就更危險了。--Labyrinthulomycetes🧬-分生全掃 2021年4月23日 (五) 09:24 (UTC)
1. 直接翻译和依托外文条目重新整理和编译我认为是两回事,如书籍的译者至多调整一些顺序、添加译注,而不太会较多改变原文和新增内容。2. 熟悉外文的编者自然有,但可能不少人没兴趣将“一看就懂”的条目译到中文维基,并也有不熟悉中文用语等情况。3. 直接翻译时,确实有缺乏查证的情况,除非译者特别认真,或者熟悉该主题而注意到不对劲。但同样,如果译者自行查证和修订谬误,也可能产生误读等现象,而且很多人不对修改处做注明,以及未修改外文版本而造成不统一、缺乏评审。谬误及传播主要还是相关条目缺乏足够关注和良好评审。4. 对于停用翻译工具是否能减少劣质翻译的条目,我持怀疑态度。--YFdyh000留言) 2021年4月25日 (日) 22:27 (UTC)
(▲)同上 2021年4月27日 (二) 09:09 (UTC)
這裡應該有兩個層面的問題,一個是外文版原文本身的問題,一個是翻譯過程產生的問題。1.像翻譯書籍般的翻譯條目,主要的前提是原文版條目內容正確無誤,可以直接翻譯過來,然而很遺憾的,英文維基的內容遠非如此,就我閱讀、翻譯英文版一些專業條目的經驗,除了少數數條特例,幾乎沒有可以直接翻譯過來的條目,有些是內容編排不妥,有些直接有內容錯誤,有些乾脆整個離題,令我經常邊寫邊罵英文版條目品質差勁,中文版是人力缺乏,你們人力充足怎麼還寫成這樣(離題了,發個牢騷)。我不是主張不要翻譯,或原創好於翻譯,而是說我們應該「不只是」翻譯,而是必須有個「編譯」的過程,自己去思考、查證英文版條目是否有不妥之處。當然可能是我看的條目領域問題,可能還是有些條目,特別是優良或特色條目可以像翻譯書籍那樣直接翻譯過來,不改变原文和新增内容,但多數條目(至少是許多條目)沒有這種捷徑。2. 沒有看懂您的意思,您是指因為很多編者不熟悉外文,內容翻譯工具對他們有幫助? 3.假設原文有5個錯誤,譯者查證過程可能通通發現,可能發現3個,總之都比直接翻過來不修正的好。如果是原文沒有錯,譯者自己誤解而改出了錯誤(您是這個意思吧),那顯然譯者不熟悉該主題,不應該翻譯該條目。至於修改外文版本,如果英文版是小筆誤我會隨手修改,如果是整段寫壞了則愛莫能助。 4.這個大概是每個人觀點不同。
不過我很想請教一件事,「內容翻譯」的功能到底對譯者有什麼幫助?如果幫助是如上面所講「有時翻譯整篇條目會很花時間,有這樣工具的協助,能縮減使用者翻譯的時間,最後可能只需要改一下語氣、用詞和通順度而已」,為何認為這樣的寫作方法不會產生翻譯錯誤?我很想聽聽支持者對此的看法。--Labyrinthulomycetes🧬-分生全掃 2021年4月28日 (三) 10:36 (UTC)
@靖天子:可以將新條目自動連接到wikidata、直接翻譯category和[[xxx]]、直接建立{{Translated page}}--Googol19980904留言) 2021年4月28日 (三) 10:55 (UTC)
@靖天子:从维基百科作用本身来说,追求内容完美是一个颇有难度的理想,读者需对条目抱有参考而非听信的态度,并在有怀疑时提出质疑或修改。即便是通过评审的优质条目,亦难保证内容未被破坏或存有问题。所以,我不认为‘直接翻译’的门槛需要过高,准确表达了原始正文即满足基本要求,内容在专业性、准确性乃至全面性等方面的提升应该交给同行评审/专业人士/提升计划,并在发现问题时一道指出和尽量跟进原文的修订,而不须竭力保证译本的完美、有所改进。2. 用上工具有助于对比原文和译文(如发现遗漏或笔误)、了解全文概况(虽然应该在翻译前通读,但并无强制性)、自动保存草稿、延缓处理源码及格式,对于未达到{{user en-3}}或以上级别的译者以及不精通维基源码的编者来说,我认为有所帮助。3. 发现错误理应纠正,但纠正的部分应作指明乃至经过评审(比如同时修订原条目),因为确实存在译者想当然而出错的情况,这与水平相关但不绝对。对于查证所有来源和重新编译,见上文,我认为这是进阶任务。对基于机翻的结果来修改润色是否会导致误译,这在不同领域下可能有很大差异,专业性条目下或应避免,但我建议交由相关专题作规范处理,避免一刀切。而普通知识、程式化内容的总结归纳,机翻的结果不一定比人工翻译差太多,人工翻译更可能掺杂不标准的口语和译法。--YFdyh000留言) 2021年4月29日 (四) 11:04 (UTC)
YFdyh000雖不完全贊同,但可以理解您的意思,感謝分享。--Labyrinthulomycetes🧬-分生全掃 2021年4月29日 (四) 23:10 (UTC)
我在站內遇到過人工翻譯出錯而機翻比人工翻譯更好的情況,比如Jarodalien的這筆翻譯「Frederick again called for a British naval deployment in the Baltic to deter Russia and an increasingly unfriendly Sweden, though nothing came of it.」,被他翻譯成「腓特烈二世再度呼吁英国海军进驻波罗的海,威慑俄罗斯和越来越敌视普鲁士的瑞典,不过瑞典始终没有从海上加入战斗。」,deepl翻譯成「腓特烈再次呼吁英国在波罗的海部署海军,以威慑俄罗斯和日益不友好的瑞典,但没有任何结果」。Comrade John建議翻譯為「腓特烈二世再度呼吁英国海军进驻波罗的海,威慑俄罗斯和越来越敌视普鲁士的瑞典,但英国对此置若罔闻。」[5],若是閱讀deepl機翻的結果,可以準確理解意思,Comrade John的推薦結果和機翻意思相差不大,而Jarodalien的翻譯則已扭曲英文原意。--Googol19980904留言) 2021年4月29日 (四) 16:59 (UTC)

採行方案编辑

鉴讨论有一周有余,对上述问题的意见可包括:

項目 认为违反方针指引 认为不违反方针指引(或某些情况下可作为特例)
各方論述
  • 此类编辑工具涉嫌鼓励用户在不查询外文文献的前提下直接挪用、且翻译工具并不具有可靠性,容易拉低条目品质(质量)
  • 哪怕使用此相对良好的翻译工具并进行润色翻译也不值得鼓励,引起可能产生「通順的錯誤內容」相较于明显的翻译错误(及不通顺)的内容危害更大。
  • 此类编辑工具有時翻譯條目會消耗较多的时间,有该工具的協助,能縮減翻譯;另只需改善語氣、用詞和通順度即可。
  • 直接翻译或参考外文条目翻译应该区分,另对停用翻译工具是否能减少劣质翻译的条目持怀疑。
所屬支持者 靖天子 Googol19980904Pseudo ClassesYFdyh000

现拟定四个方案供各位参考,请在各方案底下以支持行之,不接受反对。此次表態僅作為參考,用意在篩選主流意見與/或排除顯然不受大多數使用者支持的方案,將在最後一位使用者表態後七日進行統整。

一、违反方针指引,依据维基百科:翻译指引#翻譯注意事项将其关闭。
二、不违反方针指引,可修改Wikipedia:翻譯指引内容,将可以“减少翻译时间”之类理由允许用户使用机械翻译。
三、现阶段得不到社群共识,日后讨论,但因与现行方针指引冲突暂时关闭机械翻译选项。
四、现阶段得不到社群共识,日后讨论,不用关闭机械翻译选项。

各方案均应欢迎反对意见,不应剥夺用户对各方案提出反对意见的权利,这本就是表决进程应尽之义务。再有表决时各方案同时欢迎赞成和反对意见有利于对比各方案赞成和反对意见的比例以及各用户对各方案的赞成或反对倾向,更易于总结表决结果。另由衷感谢Xiplus之查证。維基百科最忠誠的反對者留言) 2021年4月28日 (三) 09:11 (UTC)

@Pseudo Classes、@靖天子、@Googol19980904、@YFdyh000。也欢迎之后的用户参与讨论。--維基百科最忠誠的反對者留言) 2021年4月28日 (三) 09:18 (UTC)
你應該做的是,加強提案的說服力,好讓持反對意見的我們能夠被說服,不要動不動就發起表決或投票,投票不能代替討論。 2021年4月28日 (三) 09:24 (UTC)
@Pseudo Classes您好,首先十分感谢您参考了我的名字所提出的合理要求,然而在这次提案由于各位的反对/支持理据均有道理,故我本人将在此次讨论中持中立态度。另外,对相关方案采行讨论并非是投票,而是请各位对方案内容提出建设性发言。如果主流意见没有形成,我本人也不会贸然开启投票。另我将把主题更名为《就翻译方针之机械翻译的内容规范讨论》--維基百科最忠誠的反對者留言) 2021年4月28日 (三) 09:39 (UTC)
別玩語文遊戲,難道「表決」就不是投票的一種形式?你之前也有將討論認為是投票的前科。 2021年4月28日 (三) 17:39 (UTC)
你要發起民意調查我沒意見,但是請注意,「民意調查」和「表決」是截然不同的方式。如果你發起的是民意調查,那麼你的用詞有錯誤。 2021年4月28日 (三) 17:43 (UTC)
原谅我本人在措辞上的疏失,我稍后会修正。維基百科最忠誠的反對者留言) 2021年4月29日 (四) 16:02 (UTC)
@Pseudo Classes此外,我對您使用“前科”和“玩語文游戲”之類詞匯表示遺憾及感到憤怒。故我個人鄭重請閣下以後不要再使用此類言辭。維基百科最忠誠的反對者留言) 2021年5月9日 (日) 14:36 (UTC)
陳述事實,何有不當?明明就是在討論,你卻讓社群不要將部分留言納入票數的統計?如果你不能接受我的言論,請你忽略,但是事實不會因此而改變。 2021年5月9日 (日) 15:17 (UTC)
然而,如果我的言論造成你的不適,請接受我的道歉。 2021年5月9日 (日) 15:21 (UTC)
四。减少翻译用时“可能”是事实,亦可能不是,双语精通的译者可以阅读原文并查证来自制译本,所以不必写入指引,也无需鼓励或抑制工具,加强对条目翻译和译者的评审才是核心。--YFdyh000留言) 2021年4月28日 (三) 10:02 (UTC)
  • 這個不用繼續討論了吧,顯然只有我支持移除,大多數人應該是反對的(應該遠不只上面幾位發言的),所以我也只是來發個牢騷而已。--Labyrinthulomycetes🧬-分生全掃 2021年4月28日 (三) 10:36 (UTC)
我的意見是三。我認為長遠而言應為機械翻譯設立具體的細則指引,以協助新用戶正確利用機械翻譯工具。SANMOSA Σουέζ 2021年4月30日 (五) 05:39 (UTC)
如果是三的話,需要說明一下,是可以使用翻譯頁面,但不提供機械翻譯工具。不過鑒於目前各個語言都默認開啟機器翻譯工具,在達成共識前不如維持現狀,也就是第四種方案。--Googol19980904留言) 2021年4月30日 (五) 06:41 (UTC)
(?)異議:wp:共識不是點票,提案沒任何共識,不應以點票取代討論。--蟲蟲飛♡♡→♡℃留言 2021年5月1日 (六) 08:36 (UTC)
(:)回應本次討論為對各方案采用之可行性及主流意見表態及梳理,并非代替投票。--維基百科最忠誠的反對者留言) 2021年5月9日 (日) 14:47 (UTC)
(!)意見:倾向于后者,但是根据我浅薄的翻译经验,机器翻译仍然会出现曲解原文含义的错误。如果译者没有能力或者不能保证排查出这类错误,那么我建议不要使用机器翻译。我猜测这次讨论可能会以无共识结束。——ClayM300(留言讨论🧐) 2021年5月9日 (日) 15:10 (UTC)
(+)傾向赞成畢竟如果譯者沒有能力使用該工具“可能”會有翻譯上的問題。如果在已經熟悉外語的基礎上或許會減少一些翻譯的時間。不如暫時訂立一篇論述以對不熟悉外語的用戶、熟悉外語的用戶提供編輯意見?--維基百科最忠誠的反對者留言) 2021年5月9日 (日) 15:42 (UTC)
@ClayM300,@Googol19980904,@Pseudo Classes,@Sanmosa,@YFdyh000,@蟲蟲飛,@靖天子
(!)意見經兩周的討論過後,我可總結出以下主流意見
1,得不到共識,日後討論且不用關閉機械翻譯。
2,直接關閉機械翻譯。
3,修正方針指引,在那之前暫時關閉。
在綜合上述討論后,本人認爲設置該工具對精通雙語者來説“可能”會減少翻譯時間,但同時也要顧慮到不熟悉外文的用戶選擇使用該工具時會仍會造成翻譯錯誤(比如近期在DYK就發生幾起疑似案例);
故我認爲可否設立一篇WP:論述(但現階段暫時不直接立為指引)以對新進及其他編輯使用該工具時提供適當的建議,同時勸告如果用戶不熟悉他國語言就不要使用該工具。--維基百科最忠誠的反對者留言) 2021年5月9日 (日) 15:25 (UTC)

参考英文指引,为页面分类指引引入可查证性的要求,同时引入Uncited category维护模板的提案编辑

问题的提出:

近期IRC站内对特定条目是否应该加入特定分类的问题有一些争议。有用户于IRC主张“cat的添加不像条目一样需要citation needed”,因此“受到的限制较少”。查阅现行本地页面分类指引,其已于相应章节阐明条目的分类也须遵守中立性原则
然而与中立性相辅相承可查证性,该指引却未阐述;仅仅阐述中立性的要求,而没有阐述可查证性的要求,未免也会导致上方如“cat的添加不需要citation needed”的疑虑。为从根源上消除这一疑虑,可借鉴现行英文站的对应指引——其在相关章节规定
现行英文指引不仅对分类的中立性有所要求,还对分类信息的可查证性提出了比一般条目内文信息的可查证性更高的要求:须考量可靠来源中描述的条目主题的“定义性特征”——即诸可靠来源为条目主题所普遍、一致地作出的定义(而不仅仅是可靠来源行文中顺带提及的一笔乃至繁杂列表中的一项)。这一更高的要求显然也有助于解决卡达君于IRC提出的关于“可以去找品質低落的文獻來幫助維基百科建立垃圾分類?”的疑虑。而对于不符合可查证性要求的分类,英文站专门设置了Uncited_category模板加以维护管理。
本人认为现行英文站的指引与维护模板有助于解决目前本地关于条目分类的部分疑虑;考虑到本地指引的行文,现将英文站相应要求整理、合并,提出如下修正案:
現行條文
  1. 一个条目可以归属于几个分类,但是归属过多的分类會失去其重心。
    • 請注意基本原則:分類越多,每个分類的作用越小。
  2. 一个条目通常不应该同时既属于某个分类又属于這個類別的子分类。
  3. 分类条目时一定要注意Wikipedia:中立的观点。除非显而易见而且没有争议(例如張國榮一定是香港人),不然不要对條目归类。請您寧可先到分類的討論頁提出問題,也不要贸然分類。
  4. 空的分類與只有一個條目的分類因沒有功能性,請儘量不要建立,空分類有可能會遭管理員快速刪除。
  5. 草稿页不使用分类(用户页的草稿除外),如[[Category:分类]]应当以[[:Category:分类]](Category前加半角冒号)取代,或使用<nowiki></nowiki>包裹。用户页只添加用户页分类(如[[Category:喜欢蓝色的维基人]]),而不添加条目分类(如[[Category:XX国科学家]])。侵权重写草稿、条目建立专题等所使用的管理维护性分类除外。
提議條文
  1. 一个条目可以归属于几个分类,但是归属过多的分类會失去其重心。
    • 請注意基本原則:分類越多,每个分類的作用越小。
  2. 一个条目通常不应该同时既属于某个分类又属于這個類別的子分类。
  3. 条目分类须满足可查证性的要求。为条目添加分类时,须考量可靠来源所描述的条目主题的“定义性特征”——即诸可靠来源为条目主题所作出的普遍、一致的定义。若条目分类不符合上述可查证性之要求,请以{{Uncited category}}模板标示条目。
  4. 分类条目时一定要注意Wikipedia:中立的观点。除非显而易见而且没有争议(例如張國榮一定是香港人),不然不要对條目归类。請您寧可先到分類的討論頁提出問題,也不要贸然分類。
  5. 空的分類與只有一個條目的分類因沒有功能性,請儘量不要建立,空分類有可能會遭管理員快速刪除。
  6. 草稿页不使用分类(用户页的草稿除外),如[[Category:分类]]应当以[[:Category:分类]](Category前加半角冒号)取代,或使用<nowiki></nowiki>包裹。用户页只添加用户页分类(如[[Category:喜欢蓝色的维基人]]),而不添加条目分类(如[[Category:XX国科学家]])。侵权重写草稿、条目建立专题等所使用的管理维护性分类除外。

同时引入{{Uncited category}}维护模板。该修改妥否?请社群审议。

--Antigng留言) 2021年4月23日 (五) 10:01 (UTC)

  • 支持踏出这一步。我最近注意到某(一位/一些)用户随意按自己脑中的定义便随意加政治相关分类,甚至为了阐释观点不惜违反签名指引,不断给条目加入大比重特定方面观点与条目内容无关的参见链接,这类的事情是应该管管了。--痛心疾首 2021年4月23日 (五) 12:15 (UTC)
  • (+)支持。--DavidHuai1999Talk 2021年4月23日 (五) 16:24 (UTC)
  • (+)支持,同時(&)建議為分類參考來源規定格式。--Yangwenbo99 2021年4月23日 (五) 17:36 (UTC)
  • (+)支持。—— Eric Liu 創造は生命(留言留名學生會 2021年4月24日 (六) 01:06 (UTC)
  • (+)支持。——🍫巧克力~✿ 2021年4月24日 (六) 04:25 (UTC)
  • 英文版Uncited category其实没多少条目使用。我认为“政治相关分类”更大问题是有些分类标准都不明确,例如Category:中國自由派就有多种不同的定义,而把不同来源定义的自由派放在一个分类有原创研究嫌疑。--GZWDer留言) 2021年4月24日 (六) 09:13 (UTC)
    • (:)回應 当然这个提案不能解决所有政治相关分类的争议问题。但至少其中一部分,比如左派右派之类的,由于有不同的定义,就可能会出现一部分来源声称某人是左派领导人,但另一部分来源声称其实质上是形左实右;当来源中出现定义不一致的情况,按照第四条规则和这次加进去的第三条规则,这样的争议分类就可以避免出现在条目里。--Antigng留言) 2021年4月24日 (六) 15:13 (UTC)
  • (+)支持。--ときさき くるみ 2021年4月24日 (六) 11:08 (UTC)
{{Uncited category}}模板已导入,各位可以修改措辞及doc页面。--东风留言) 2021年4月24日 (六) 15:39 (UTC)
  • (-)傾向反對:中立的观点应排在可查证性之前。若修改,请划票改为支持。--E.A.Crowley666✍️ 2021年4月25日 (日) 04:10 (UTC)
    我个人很好奇您说的这个前面是指条文内顺序的前后还是侧重度优先级的前后?如果是前者的话我觉得无伤大雅,如果是后者的话现在这个条文似乎也没有刻意强调谁在谁前面?--ときさき くるみ 2021年4月25日 (日) 04:28 (UTC)
目前出了什么问题?没坏别修。Fire Ice 2021年4月25日 (日) 10:01 (UTC)
“有用户于IRC主张‘cat的添加不像条目一样需要citation needed’,因此‘受到的限制较少’。”这本身就是一个值得纠正的问题。分类——如同另一位IRC用户所述——是在给一个条目主题贴“标签”,下“定义”,理应和内文内容一样受到可供查证方针的制约——甚至理应受到比普通内文内容更多的制约,但现行方针指引完全没有体现这一理念和精神。--Antigng留言) 2021年4月25日 (日) 10:27 (UTC)
如果{{Uncited category}}是放在条目页,我认为有过度彰显之嫌,并可能会促成游戏维基规则(没悬挂/讨论则不能移除)。如果是放条目讨论页或单独页面并通告添加者/先行移除,我则没意见。另外当仅看标题,我以为在谈给分类页面放定义或者参考来源——如果谈这个,消歧义页也很缺且不能放来源。--YFdyh000留言) 2021年4月25日 (日) 22:07 (UTC)
消歧義頁面一般只會從正文首段截取關鍵介紹,所以一般不會有類似問題吧。--Yangwenbo99 2021年4月26日 (一) 00:03 (UTC)

第二稿编辑

現行條文
  1. 一个条目可以归属于几个分类,但是归属过多的分类會失去其重心。
    • 請注意基本原則:分類越多,每个分類的作用越小。
  2. 一个条目通常不应该同时既属于某个分类又属于這個類別的子分类。
  3. 分类条目时一定要注意Wikipedia:中立的观点。除非显而易见而且没有争议(例如張國榮一定是香港人),不然不要对條目归类。請您寧可先到分類的討論頁提出問題,也不要贸然分類。
  4. 空的分類與只有一個條目的分類因沒有功能性,請儘量不要建立,空分類有可能會遭管理員快速刪除。
  5. 草稿页不使用分类(用户页的草稿除外),如[[Category:分类]]应当以[[:Category:分类]](Category前加半角冒号)取代,或使用<nowiki></nowiki>包裹。用户页只添加用户页分类(如[[Category:喜欢蓝色的维基人]]),而不添加条目分类(如[[Category:XX国科学家]])。侵权重写草稿、条目建立专题等所使用的管理维护性分类除外。
提議條文
  1. 一个条目可以归属于几个分类,但是归属过多的分类會失去其重心。
    • 請注意基本原則:分類越多,每个分類的作用越小。
  2. 一个条目通常不应该同时既属于某个分类又属于這個類別的子分类。
  3. 分类条目时一定要注意中立的观点。除非显而易见而且没有争议(例如張國榮一定是香港人),不然不要对條目归类。請您寧可先到分類的討論頁提出問題,也不要贸然分類。
  4. 条目分类须满足可查证性的要求。为条目添加分类时,须考量可靠来源所描述的条目主题的“定义性特征”——即诸可靠来源为条目主题所作出的普遍、一致的定义。{{Uncited category}}模板可用以标示不符合上述可查证性要求之条目分类。
  5. 空的分類與只有一個條目的分類因沒有功能性,請儘量不要建立,空分類有可能會遭管理員快速刪除。
  6. 草稿页不使用分类(用户页的草稿除外),如[[Category:分类]]应当以[[:Category:分类]](Category前加半角冒号)取代,或使用<nowiki></nowiki>包裹。用户页只添加用户页分类(如[[Category:喜欢蓝色的维基人]]),而不添加条目分类(如[[Category:XX国科学家]])。侵权重写草稿、条目建立专题等所使用的管理维护性分类除外。
  • 参考@EdwardAlexanderCrowleyYFdyh000:君的意见,现提出第二稿。相较于初稿,该稿有三处调整,一是将新增条文转移至中立性条文之后;二是修改{{Uncited category}}模板相关的措辞,以减小“没悬挂/讨论则不能移除”这种错误理解/游戏规则的生存空间;三是顺手修改了中立性条文中链接的格式,以保持上下文的一致性。--Antigng留言) 2021年4月26日 (一) 02:10 (UTC)
  • 基於本案之立論言減低爭議,然有關引入查證規例實際於本地尤其於政治等領域,条目探讨中案所指出是可以各自解讀而令爭議持續,並有淪為政治觀點審查手柄等風險。謹此,詢提案人與支持提案者等,(?)疑問是否能提出更多細節處理之方案,以避免本案淪為新的爭議催化劑?如無法遏制有關爭議之嚴重風險,本案之立基即難以可信,而本編會維持(-)反对存有有關風險之本案。——約克客留言) 2021年4月27日 (二) 02:46 (UTC)
    • 第一,您所列举的讨论——即使假定相关用户的言论属实——也至多能证明“可供查证方针在特定情况下无法减少争议”,而不能证明您所疑虑的“可供查证”“淪為新的爭議催化劑”。逻辑上,无法减少争议不等同于加剧争议。
    • 第二,争论与争论亦有所不同,有的争议比另一些更具有建设性。在可供查证的框架下,编者之间的争议是以列举来源、列举事实、评估来源可靠性的方式体现的。如无可查证性之要求,编者纯粹叙述个人意见想法,亦能成为争议的焦点。即使可查证性不能缓解特定领域的争议的“激烈程度”,将争论限定为事实与来源之争,也显著地提高了争论的质量。+1
    • 此外,本案引入的查证性标准甚于一般内文内容的查证性标准:本案明确规定条目分类需考量“诸可靠来源中普遍、一致作出的定义”,出现来源中定义不一致的情况、抑或是来源间接带过而未有明确下定义的情形,均不支持分类的列入。如IRC上一位用户所言,添加分类是在为条目主题“下定义”,言下之意为不可不慎;在维基百科的框架下,这种慎重理所当然地应该体现为“可靠来源下了定义,维基百科才能下定义”,亦即本提案的精神。比内文内容更高的可查证性标准理应更有助于消减相关争议,和/或改善争议的质量。--Antigng留言) 2021年4月27日 (二) 07:10 (UTC)
      • 如是閣下所言,於{{Uncited category}}模板應同時體現本案之立論與所倡精神。查模板新晉仍有同步改進之空間,基於提案人詳述,即引用有關修訂該模板,一併審視增益足否。——約克客留言) 2021年4月27日 (二) 23:31 (UTC)
        • Longway22阁下的修订参见此处,在下做了修改,不知可否,还请一并审阅。--痛心疾首 2021年4月28日 (三) 00:38 (UTC)
          (+)支持这个动议。我唯一不太明白的是,如何为分类提供来源?在实际编辑中如何进行?--百無一用是書生 () 2021年4月28日 (三) 03:00 (UTC)
    • (:)回應:我认为,可以在条目内容引文中提供,如果编辑争议产生,在这样的方针下,双方可以在讨论页面讨论并交换相关的来源。--痛心疾首 2021年4月28日 (三) 07:04 (UTC)
      • 謝痛心疾首閣下跟手,以之基礎再修訂參,期更準確反映修正案之意願與精神。——約克客留言) 2021年4月28日 (三) 07:40 (UTC)
      能否提供几个实例观摩一下?--百無一用是書生 () 2021年4月29日 (四) 02:11 (UTC)
    • 在维基百科的语境下,可供查证有两个层次的含义:一是所有百科条目的内容,都必须有支持其的可靠来源存在(而无论是否文内引注)( en:WP:V: This means all material must be attributable to reliable, published sources. );二是对任何可能引起或已经引起争议的内容,都须以文内引注的形式标示(en:WP:V: Additionally, quotations and any material challenged or likely to be challenged must be supported by inline citations.)。具体运用到分类问题上,大部分不引起争议的分类以条目内文中的来源及其所提供的可供查证信息加以证明即可,如痛心疾首君所言;对于少数引起争议的分类,则可通过在分类后面加注释标明来源的方式满足引注的要求。--Antigng留言) 2021年4月28日 (三) 13:39 (UTC)
      在分类后面加注释,可行吗?--百無一用是書生 () 2021年4月30日 (五) 03:05 (UTC)
      做了一个测试User:Shizhao/Uncited category,似乎在分类后面加注释行不通?--百無一用是書生 () 2021年4月30日 (五) 03:09 (UTC)
      在下所指的注释是,在页面中以<!--的形式标注来源,不是reftag。--Antigng留言) 2021年4月30日 (五) 03:50 (UTC)

提案进入公示阶段。若有意见请尽速提出。--Antigng留言) 2021年5月1日 (六) 12:24 (UTC)

注意到提案人已付諸公示,雖然本編已根據提案人之回應等追加修正模板以衡平有關疑慮,但本編強調仍未撤銷上述中所提出的反對意見,現仍保持必要繼續檢視和觀察的態度。如社群實際已有對為斯大林、毛澤東等人加入極權主義領導人分類展開議案,論述共識和來源的時候就有非常多爭議,引子可歸結到足量不同的觀點——這個也是本地一個比較麻煩的論點
AINH君也提到了很關鍵的審查問題,這點也是本案目前似乎仍未徹底解決的疑慮,本編見到是提案人現版本處理上也改進了很多,但就審查可能擴大的問題仍然比較擔憂,因為不斷地實踐可以發現整體中文語境正越趨於模糊化,而背離普世基本的原本理解引發無限的泥潭。
百無一用是書生閣下其實已經算提出了本案需要的本地化檢視,也是之前本編提出議案需處理細節問題時未有展開的一點,即需要以本地個案來檢視本案是否可能達成提案人提出的願景成效?認為基於現有本地個案有必要再完善後續,本地化應可考慮指明相關查證不得用於政治觀點審查,相信這樣指標會是有助減低本地持續部分問題。--約克客留言) 2021年5月3日 (一) 04:41 (UTC)
  1. “論述共識和來源的時候就有非常多爭議”:该事实与本提案目标之间的不相关性已于上方“第二、争论与争论亦有所不同”一节中回应,不再赘述;
  2. “本地化應可考慮指明相關查證不得用於政治觀點審查”:“用于政治观点审查”是针对动机的负面论述——正如假定善意指引该用户论述所述,揣测他人的动机是坏主意。在指引中要求编者处理争议问题时考量动机明显与该原则背道而驰,故不予以采纳。--Antigng留言) 2021年5月3日 (一) 10:47 (UTC)
  • (-)反对我反對的是下面一句「沒有爭議」,套用回我之前說的那句話(也是現在正在發生的事情)就算有可靠來源,但來一個人甚麼也不用証明,只說一句「我反對」,是不是仍然不可加入?那麼倒不是永遠都不用加入負面分類了?這提案完全沒有解決現在的審查問題。現在的問題不是沒有可靠來源,而是「沒有爭議」這一句被濫用。如果直接以第四條取代現在第三條我就會支持-某人 2021年5月3日 (一) 05:45 (UTC)
    • 该反对意见涉及且仅涉及该修订不涉及的既有方针条文,故非针对本人提案条文的反对意见。无效。--Antigng留言) 2021年5月3日 (一) 10:18 (UTC)
      • 有關,你的修訂在現在審查問題都還未解決的情況下把加入負面分類的門檻提得更高-某人 2021年5月3日 (一) 10:23 (UTC)
        • 不相干谬误。没有可靠来源一致支持并明确定义的内容依照维基百科的基本原理就不适宜列入分类,这一点与您所谓的“审查问题”——即使假定其存在——解决与否,并无逻辑上的关联。--Antigng留言) 2021年5月3日 (一) 10:35 (UTC)
          • 明确定义的可靠來源給了好幾個-某人 2021年5月3日 (一) 12:22 (UTC)
            • 您列举的事实既不足以支持您所谓“审查问题”与本人提案——即为分类引入可查证性要求——之间的关联,也不足以论证本人提案的不合理性。请您专注于本人的提案,而非罗列与本人提案无甚逻辑关联的事实与断言。--Antigng留言) 2021年5月3日 (一) 13:16 (UTC)
      提案人無權單方面宣佈任何反對意見無效,認為現有爭議仍需討論更多防止審查的情況,尤其於中東亞與中文圈言論資訊之開放和自由度正處於極度嚴峻的情況下,強烈建議撤銷議案公示而繼續討論改善--約克客留言) 2021年5月3日 (一) 13:02 (UTC)
      • 第一,“尤其於中東亞與中文圈言論資訊之開放和自由度正處於極度嚴峻的情況”与维基百科无关;没有方针指引规定本站有保护所谓“言论信息开放”的义务。恰恰相反,如该篇论述所述
      • 违反内容方针之内容自然地被移除,而不受NOTCENSOR之限。故在现行方针的框架之下,在涉及到强化内容方针执行的讨论中以NOTCENSOR为由来反对,是没有任何说服力的。--Antigng留言) 2021年5月3日 (一) 13:35 (UTC)
        提案人仍無法舉出可評議有良好效能之個案等加以詮釋,無法認可提案人僅以非本地之英文文本分析有關風險,維持已提出之意見--約克客留言) 2021年5月4日 (二) 01:29 (UTC)
        • 第一,本人没有提供案例的义务。可查证性是本站三大内容方针之一,其引言部分写明“可供查证是维基百科內容的门槛,这意味着写入维基百科的内容须要能被读者在可靠来源中得到验证”,亦即任何不符合可供查证这一门槛性条件的内容本站都会拒之门外。然而现行分类指引以及其它任何涉及分类的指引均无规定可查证性的要求,以至于发生了前文述及的“IRC用户出现困惑以为分类不要citation needed”的情况。无论有无案例证明,这都是原则上的漏洞,值得填补。第二,本人没有“以非本地之英文文本分析有關風險”,而是明确指出,非审查原则在原理上不足以凌驾可查证性这一内容方针。前述英文条文实则为本地方针条文,只因过于翻译腔(判定违反维基百科的生者传记方针,或違反其他維基方針與指引(尤其是中立的觀點),或維基百科伺服器所在地美國佛羅里達州法律的內容,會遭到移除)而援引英文条文加以说明。故以担忧审查为由来反对可查证性方针的落实与执行,本质上没有说服力。最后,“增加审查风险”是您的主张,而您负有举证责任——然而在过往的讨论中您没有列明任何牢靠的证据证明该案为何会提高审查发生的风险。即使上述第二条不成立(即内容方针不能凌驾非审查原则),您也没有有效地证明您的反对意见。
          此外,对于想了解本案现实效果的维基人,在此试举一例:该案通过之后,可以预期Category:名數这个分类树下几乎所有的节点都会被删除,因为其收录的条目绝大部分没有可靠来源去分析其“名称含有数字”这一特征,以至于五大訴求,缺一不可北约五国两样截然不同的事物同处一分类。然而现行规则对这一现象无能为力——按照现行分类指引,分类须遵守中立性原则,如有争议则不得加入。但是纯粹数字鲜有会导致争议,该条规则无法排除上述不合理现象。--Antigng留言) 2021年5月4日 (二) 05:04 (UTC)
  • Antigng閣下的例證充分地證明了欲新增的規則很有可能受到濫用。「五大訴求,缺一不可」和「北约五国顯然都是名稱中包含有「五」的條目,依照社羣慣例,不需要有參考資料。閣下若認為Category:名數因為同一分類中條目關係不大、可以刪除,大可以此為由另行提刪。(事實上指引中也確實有要求分類需要告知讀者相關條目的主題)依照閣下對此新增規則的解釋,可能有編者認為沒有參考資料明確地將「范特霍夫方程」描述成是一個方程式,故應當將其Category:方程的分類刪去。
另外,經仔細思考過後,在下發現「定義性特徵」本身與現行指南矛盾。依照常理,「蒸氣壓」是熱力學的研究對象,故依據現行指南,將其歸入熱力學的範疇完全合理。然而如果按照閣下的提案,這個分類卻變成是錯誤的了——我不相信有書籍會明確地將「蒸氣壓定義為热力学的一部分,儘管依照常識來看確實如此。類似地,也不會有來源將「廈門鷺島足球俱樂部」定義為廈門的一部分。
有鑑於此,在本規則被濫用的風險解除,並且與指南的矛盾消除之前,我只能投出(-)反对。--Yangwenbo99 2021年5月4日 (二) 14:11 (UTC)
您所列举的三个反例均与事实不符:关于范特霍夫方程蒸汽压,事实上只需简单google搜索即可分别找到可靠来源1(The van't Hoff equation is an equation used to calculate the equilibrium constant of a certain adsorption reaction at different temperatures)和2(in thermodynamics the term “vapor pressure” is unambiguously defined)来满足拟引入规则的要求;关于厦门鹭岛队,简单百度搜索即可找到相关来源以满足要求(厦门鹭岛,是厦门新组建的一支劲旅,由前国脚杨林挂帅,实力企业趣店集团投资支持)。这与上例所述名数的情形有天壤之别。
此外,WP:孙中山不是为分类避免可查证性方针的合适理由。倘若按照常识,含有数字“五”就可以合理归入分类,那么是否有必要建立一个含有汉字“汉”的条目的分类?本人非但不认为这种做法是社群惯例——如名数一例,从跨语言链接来看只有本站、日文站和韩文站有相关分类,执行本条拟引入指引的英文站就没有。退一步说,即使是,这种做法也是不符合本站的基本精神的,有充分的必要予以纠正。
至于Help:页面分类入门,考量其所列举的所有正面案例,可发现均有可靠来源满足拟议条文的要求,例如“學科”一节中提及的案例:
意識型態/Category:政治学意识形态是政治学中的核心概念之一;
新闻自由/Category:新闻学李瞻教授早在1972 年初版的《新聞學》即曾指出「新聞自由是新聞哲學的中心議題(引自李瞻,1994: 32)」;
位能/Category:力学1853 年, 朗肯引入了 “势能” 的概念, 一定程度上解决了上述困难, 使力学研究获得了巨大进步
从而与拟议条文不存在实质性的矛盾。--Antigng留言) 2021年5月4日 (二) 16:09 (UTC)
就閣下為范特霍夫方程提出的來源,在下沒有異議。但在下依舊認為,條文中必須要清楚地闡述當中的「定义性特征」和「定義」應當作何解釋。倘若不能對此有詳細解釋,則幾乎所有分類都會有爭議。如果「定義」一詞取最嚴格的定義,基於學科、年份和地點的許多分類便不合理。
  • 廈門鷺島足球俱樂部」不可能被定義為廈門,她只會被描述成廈門的一部分。
  • 毛泽东」不可能被定義成「1893年出生」,儘管1893年出生是他的顯著特徵。
  • 位能」不可能被定義成力學,儘管它是力學中的重要概念。
而如果將「定義」解作「屬於」,仍舊不可解決下列問題:
  • 嚴格來講,這份問答當中,對蒸汽壓下定義的句子是「The “vapor pressure” of a component is identical to (i) the saturation vapor pressure for a single component system or(ii) the partial pressure of a component in equilibrium with a mixed condensed phase."」,此定義不足以說明蒸氣壓屬於熱力學的一部分。而且本檔案本身是否是可靠來源,本身就存在爭議。Vapor pressures of substituted polycarboxylic acids are much lower than previously reported 是一篇受過同行評審的文章,但這份問答本身僅僅是同行評審過程中,作者對於質疑的簡要回應。最後出現在 paper 中的內容是「Note that throughout this article, the term “vapor pressure” is used as defined by chemical thermodynamics to denote 」
  • 此来源僅能證明「廈門鷺島足球俱樂部」成立於廈門,但她是如何能夠依照定義被歸如「廈門」這一分類?(即,她為何屬於廈門?)類似地,地點或者時間這些特徵不總會出現在「定義」當中(甚至一些社會概念本身就無「定義」一說),但是卻明確地可以被作為分類。
  • 「位能可以由力學定義」、「蒸氣壓可以由化學熱力學定義」是否代表「位能屬於力學概念」、「蒸氣壓屬於化學熱力學概念呢」?假如拋棄常識,這個問題是無法作答的。
  • 即使所有可以由WP:孫中山支持的分類都可以由可靠來源支持,為了消除某個不合理質疑便要大費周章翻查資料,也是不合理的。WP:孫中山的核心,是對於任何可能引發合理質疑的內容才必須有參考來源。質疑「五眼聯盟」的名字中是否含有「五」或者質疑「廈門鷺島足球俱樂部」是否屬於廈門,絕對不是合理質疑。
至於Category:名數相關分類是否有存在的必要,已經有條文直接規管,毋須將新增規則做擴張解釋。--2021年5月4日 (二) 23:40 (UTC)
  1. 关于蒸汽压,即使您认为上面的WP:SPS不够好(但值得注意的是,上文援引的文字是署名作者而非匿名审稿人所留,对于介绍蒸汽压这个基本概念而言可能已经足够了)尚有另一篇文献对纯物质的蒸汽压做出如下定义:"Vapour pressure is the pressure exerted by a vapour in thermodynamic equilibrium with its condensed phases at a given temperature in a closed system. "该定义很清晰地将蒸汽压与热力学关联了起来;关于厦门鹭岛足球俱乐部,上方列明的来源中摘录的文字“厦门鹭岛,是厦门新组建的一支劲旅”本身即是定义,将厦门鹭岛“定义为”厦门新组建的一支球队,按照拟议条文厦门的分类就允许加入这一条目;这与上述名数的情形根本上不一样。
  2. 拟议条文中的“定义”不限于“屬於”,而是“具有的性质”,如英文条文原文所述:"A defining characteristic is one that reliable sources commonly and consistently define the subject as having",已于第三稿调整措辞加以明确;
  3. “即使所有可以由WP:孫中山支持的分類都可以由可靠來源支持,為了消除某個不合理質疑便要大費周章翻查資料,也是不合理的”,不同意。按照同样的论述方法,您也可以主张为了消除一个标题的争议不必大费周章翻查资料;但事实上现行命名常规方针要求条目的命名者考量“可靠来源中人、物或事项的常见的名称”——不仅要查阅一个来源,还要遍查可靠来源看哪个名称最为常用。可供查证里的一个核心概念是举证责任,编者永远要为自己撰写的内容的可查证性提供举证责任;编者从撰写条目的一开始就应该保证其所撰写的内容满足可查证性的要求,而不是想当然地草草创建一个条目,然后被质疑了才去到处翻查资料。
  4. 按现行指引,既然读者可以一眼看出条目为什么属于这个分类,“如果使用者從分類頁面點選了條目,他是不是很明顯地可以看出為什麼這個條目會被列在這個分類”这一问题的答案即为是;“可以就這個分類的主題寫幾小段文字,解釋一下這個分類”,当然可以——“条目主题含有数字五+量词的条目”,这个问题的答案也为是。因此,按指引的条文(要求两个问题的答案都为“否”)就不能排除这一不合理分类。--Antigng留言) 2021年5月5日 (三) 02:33 (UTC)
  1. @Antigng:之