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

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

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

Breezeicons-apps-48-cantor.svg
发表前请先搜索存档,参考旧讨论中的内容可节省您的时间。
公告板
# 话题 发言 参与 最新发言 最后更新(UTC+8)
1 专题名字空间 171 19 A2569875 2021-04-07 14:22
2 伪名字空间 217 18 A2569875 2021-04-07 14:24
3 WP:捷径指引草案修订 21 4 A2569875 2021-04-07 14:14
4 有关某年代相关分类命名统一事宜 41 13 Sanmosa 2021-03-29 19:35
5 提议创建“元维基用户查核指南” 1 1 听风吹过的声音 2021-04-10 17:06
6 修订删除方针第1(删除理由)章节第9项 31 11 KirkLU 2021-04-11 01:49
7 请求第三方管理员参与评估和总结可靠来源讨论 1 1 Antigng 2021-03-09 14:40
8 关于Wikipedia:命名常规 (音乐) 74 15 羊羊32521 2021-04-11 10:26
9 (重提)Wikipedia:共识#提案讨论及公示时间的执行力度 94 17 DrizzleD 2021-04-05 00:29
10 台湾原住民族人条目命名(第二次) 55 9 克劳棣 2021-04-04 00:15
11 命名常规拟议修订 1 1 Jimmy-bot 2021-04-11 16:14
12 有关新增伪名字空间的提议 16 7 LuciferianThomas 2021-04-11 07:10
13 交通关注度指引修订 1 1 听风吹过的声音 2021-04-10 17:16
14 模板颜色相关规范 38 16 Pseudo Classes 2021-04-10 15:05
15 交通关注度指引适用范围的扩展 1 1 听风吹过的声音 2021-04-10 17:19
16 提案将维基百科:格式手册/不要模棱两可列入格式手册 1 1 Jimmy-bot 2021-04-11 16:14
17 提议对WP:DYKC的投票须知进行修改 6 5 Sanmosa 2021-04-10 13:59
18 调整界面管理员方针之“权限取得”一节 21 10 羊羊32521 2021-04-11 11:41
19 模板修订建议 5 5 Lopullinen 2021-04-11 03:19
20 表格标题背景与文字颜色 2 2 星星 2021-04-11 13:20
21 设计一个制度解决部分速删模板挂不上去的页面的删除问题 4 2 Tranve 2021-04-10 14:30
22 关于Wikipedia:关注度 (组织) 2 2 Sanmosa 2021-04-10 14:28
23 限缩{{电视节目的变迁}}模板使用范围 3 3 星星 2021-04-11 09:31
24 通用行为准则/2021咨询 6 3 YFdyh000 2021-04-11 00:38
发言更新图例
  • 最近一小时内
  • 最近一日内
  • 一周内
  • 一个月内
  • 逾一个月
特殊状态
已移动至其他页面
或完成讨论之议题
手动设置
当列表出现异常时,
请先检查设置是否有误

专题名字空间

[编辑此导航模板]

捷径指引草案的讨论,源自于“伪名字空间”的讨论,英语维基百科对于捷径相关的规范及伪名字空间的设立已有成熟的执行方式。中文维基百科中的部分编辑者对于“格式手册”、“长期破坏者”及“专题”这三个主题提出可升级成名字空间或以伪名字空间形式存在,并有正反两方的陈述与看法。

目前较为接近共识的是“专题”提升为正式名字空间,反对者的论述已由支持者回应,且反方无进一步论述。然为求慎重,且将捷径与名字空间等议题作系统性讨论,将会执行阶段修订,以取得最大共识。

本讨论的各阶段分为:

  1. 专题提升为名字空间与否及其细节
  2. 格式手册及长期破坏者是否成为名字空间或伪名字空间
  3. 伪名字空间规范写入捷径规范内(如前项通过)或是否允许伪名字空间(如前项不通过);
  4. 捷径规范细部讨论并决定是否成为指引。

各阶段不得同时讨论,前一项讨论完结之后,才能进行下一段讨论。台湾杉在此发言 (会客室) 2020年12月10日 (四) 05:47 (UTC)

专题名字空间通过,剩余细节独立讨论。台湾杉在此发言 (会客室) 2021年1月11日 (一) 11:20 (UTC)
目前的后续讨论须等phab:T271612布署完毕后才能继续进行。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月12日 (二) 13:08 (UTC)

已通过:
公示7日无合理异议,本议案通过。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月3日 (日) 07:44 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

直接将PJ:独立为新WP:名字空间

(&)建议像日文维基那样,专题直接变成一个 "真" 名字空间 ja:Help:名前空间#プロジェクト就不会有cwek说的 "假" 名字空间 的 混淆问题了。日维相关讨论。 -- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2020年11月16日 (一) 06:06 (UTC)

依据先前讨论,专题名字空间的讨论已接近达成共识之阶段,目前问题包含:

  1. 英文命名部分,其一为Project并取消与Wikipedia空间连动,其二为以WikiProject命名;
  2. 部分用户认为直接将PJ与Wikipedia连动即可。

请讨论。台湾杉在此发言 (会客室) 2020年12月10日 (四) 05:47 (UTC)

  • 个人以为Project名字空间肯定不能变,否则可能会造成不少链接失效。因此名字空间应该命名为“WikiProject”,对应的中文名字空间应该命名为“维基专题”,以便于与“WikiProject”对应。——BlackShadowG留言) 2020年12月11日 (五) 16:27 (UTC)
    • 我认为中文叫做“专题”并无不妥,也无冲突。将“WikiProject:”作为程式系统前缀;“专题”、“维基专题”、“PJ”作为别名。其他中文别名也可以之后再议再补。并依照法维和日维和其他姐妹项目的统一定义,定为{{ns:102}}(目前显示为“WikiProject”,空白是因为本地尚未实装)。— ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2020年12月11日 (五) 18:16 (UTC)
确定英文名称不会冲突就可以,中文名称应该没问题。SANMOSA SPQR 2020年12月12日 (六) 03:34 (UTC)
支持命名为WikiProject/专题 ——羊羊 (留言|贡献) 2020年12月16日 (三) 15:08 (UTC)
  • 公示7天:理据:本议题先前公示通过的讨论已讨论满一个月,且自本讨论上次有效发言羊羊32521留言2020年12月16日 (三) 15:08 (UTC)已逾一周,根据WP:7DAYS公示七天。如通过,届时具体的做法可以参考phab:T26852 -- 来人啊,喂宫子吃布丁! ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2020年12月24日 (四) 08:47 (UTC)
    • 公示什么? ——羊羊 (留言|贡献) 2020年12月26日 (六) 10:21 (UTC)
      • @羊羊32521:将专题升为名字空间啊(公告栏上有)主要是细节,程式名称定为WikiProject、然后“专题”、维基专题、PJ作为别名,并且参考phab:T26852将Namespace id 设为102讨论页以此类推(WikiProject_talk;103;专题讨论,维基专题讨论)。其余请参考先前讨论、发布公示的留言以及公布栏,另补充一个2018年在WP:TG讨论出的草案。— ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2020年12月26日 (六) 12:47 (UTC)
  • 专题这种东西本来就都没有什么用户在关注了。所以什么都不问,只问一个问题:请问这样一来那些原本已经用于条目讨论页上的专题名称会不会有影响?--Z7504非常建议必要时多关注评选留言) 2020年12月31日 (四) 08:42 (UTC)
  • 既然木已成舟,大家意见如此,我也没法反对什么,但是请提案者一定要做好配套措施,以免留给本地社群一堆烂摊子去收。—— Eric Liu 创造は生命(留言留名学生会 2020年12月31日 (四) 11:32 (UTC)

  • 自上周补充公示共识内容的发言 2020年12月26日 (六) 12:47 (UTC)后已公示逾一周,公示期内无合理异议,本议案通过。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月3日 (日) 07:44 (UTC)

本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

专题空间设立流程与细节

参考ja:Special:PermaLink/39099771#ウィキプロジェクト用名前空间の新设以及ja:Wikipedia:ウィキプロジェクト/名前空间の新设,本地的处理方式预计会分成5个阶段进行:

  1. phab:提交申请设立专题空间;
  2. 将专题页与讨论页批次移动到专题空间(可能需WP:FLOOD);
  3. 修正指向专题的内部链接(可能需WP:FLOOD);
  4. 调整专题模板;
  5. 讨论重定向与捷径的设立方式;
  6. 其他议题。
以上。以上流程不会立即执行,会在社群对流程没有异议之后公示后执行。如有其他相关疑问可继续在下方讨论。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月3日 (日) 07:44 (UTC)

第一阶段:申请

已通过:
已通过公示,亦完成布署(前端 by User:AnYiLin后端 by User:A2569875),专题名字空间已于中文维基百科生效,将立即进行下一阶段讨论。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月27日 (三) 04:06 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

  • 将会提供给phab:的细节如下:
名字空间 讨论空间
内部名称
(前缀)
WikiProject: WikiProject_talk:
ID 102 103
中文名称
(界面名称)
维基专题 维基专题讨论
别名
  • 專題
  • 专题
  • 維基專題
  • 维基专题
  • PJ
  • WPJ
  • 專題討論
  • 专题讨论
  • 專題對話
  • 专题对话
  • 維基專題討論
  • 维基专题讨论
  • 維基專題對話
  • 维基专题对话
  • PJT
  • WPJT
-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月3日 (日) 09:41 (UTC)
  • 我觉得中文名称叫“专题”更简洁一点…… ——羊羊 (留言|贡献) 2021年1月3日 (日) 14:02 (UTC)
    • 这个名称是参考User:BlackShadowG的提议。@BlackShadowG:关于羊羊32521的意见,您有什么看法?-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月3日 (日) 14:10 (UTC)
      • 在我看来,名字空间的中英文应该对应,这样可以避免误解。如果中文名称定为“专题:”那英文名称应该对应为“Project:“才对,然而“Project:”早已被用为“Wikipedia:“的别名了。——BlackShadowG留言维基百科20周年庆即将到来 2021年1月4日 (一) 14:43 (UTC)
        • BlackShadowG不认为需要严格对应。对应“专题”是“Topic”才对,“Project”是项目/工程/项目/方案。--YFdyh000留言) 2021年1月4日 (一) 14:47 (UTC)
          • 该中文名称仅是“界面显示名称”其如何设置并不会影响运作。但仍需要决定一个显示名称以让界面管理员设置。若无法做出决定可能要像日文维基一样开个名称投票,然而由于WP:投票不能代替讨论,因此不建议这么做。当然,这不影响名字空间的申请与设置,因为Phab那边只管内部名称,而内部名称“WikiProject:”已公示通过;界面名称可以取得共识后再由WP:界面管理员于本地设置。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月4日 (一) 15:15 (UTC)
      建议名字空间内部名用英文,以免出现繁简问题。--GZWDer留言) 2021年1月3日 (日) 16:18 (UTC)
    • (:)回应@羊羊32521:该名称主要是界面显示的名称(如左上角显示[维基专题][讨论][简体]_____[阅读][编辑][历史]☆[更多∇][TW∇][搜索维基百科🔍]),而关于简洁与否问题,由于有同步申请别名,因此亦可以透过输入专题:XXX链接到专题页,并不一定要写全名维基专题:XXX(参考预计命名)。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月3日 (日) 19:42 (UTC)
      • (?)疑问@羊羊32521:您可以接受上面的解释吗?;@YFdyh000:那个中文名称实际上是对应界面显示名称—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月5日 (二) 05:52 (UTC)
        • @A2569875Green tickY行 ——羊羊 (留言|贡献) 2021年1月5日 (二) 15:22 (UTC)
          • 不解,这种东西为什么需要用什么“申请”?不是都通过了?那这样公示是什么意思?--Z7504非常建议必要时多关注评选留言) 2021年1月6日 (三) 02:27 (UTC)
            • @Z7504:要去phab:提申请,才会有工程师创建啊。举个例子:台北市政府通过建造某条捷运,请问还没向工程单位申请建造捷运路线,捷运路线就会自己冒出来吗?从天上掉下来?怎么可能。这边主要是技术细节讨论,完成后向技术分站提工单,通过是指社群共识通过,不意味着工程师理解具体要怎么执行社群共识,现在就是要讨论怎么让工程师理解具体怎么操作,就这样。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️
              • 您有没有看到关于上方具体要给工程师设置技术细节的部分还在讨论,现在就是要处理程式码具体技术上设置的部分。我想一气呵成,不想变成有缺漏还要补提多张工单浪费时间,现在的讨论正是这个目的。且技术细节讨论只有公示通过后讨论才有意义,如前次公示没有通过,讨论技术上程式设置也是白费功夫纸上谈兵。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月6日 (三) 05:37 (UTC)
                • 理解,不过phab这个不怎么在看,就不赘述了。--Z7504非常建议必要时多关注评选留言) 2021年1月6日 (三) 06:39 (UTC)
  • 公示3日,如无异议就转交 转交phab:。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月6日 (三) 07:53 (UTC)
转交 转交phab:T271612。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月9日 (六) 08:16 (UTC)

本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

第一点五阶段:内容事实修订

由于该名字空间设立完毕,已修正WP:名字空间新增该空间说明。如需补充欢迎讨论。台湾杉在此发言 (会客室) 2021年1月27日 (三) 13:40 (UTC)

您漏了WP:NS#缩写和别名。--LuciferianThomas留言 2021年1月28日 (四) 08:08 (UTC)
完成。--台湾杉在此发言 (会客室) 2021年1月29日 (五) 13:37 (UTC)
请协助复查是否全部的相关说明页都修复完毕。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月25日 (四) 05:49 (UTC)

第二阶段:转移至新名字空间

已通过:
公示从2021年1月6日起至2021年1月14日暂停再从2021年1月26日起至1月29日共11天,期内所有异议的论述已由支持者回应,且反方无进一步论述,故无合理异议,议案通过。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月29日 (五) 13:04 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

名字空间设立完毕后,将会把所有列于Category:维基专题中的页面及子页面转移至新名字空间,预计转移的页面及转移之目标列于此页User:A2569875/议案/专题空间设立/影响页面(暂不包括重定向),如有异议请尽快提出。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月3日 (日) 19:26 (UTC)

第二阶段 之 公示状态通告

第二阶段 之 公示期讨论


公示通过,即将开始移动-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月29日 (五) 13:04 (UTC)


本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
专题指引更名
“维基专题:维基专题:XX”的页面
已处理:
已由虫虫飞快速删除-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月5日 (五) 06:55 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。



本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

第二点五阶段:相关技术问题修正

根据phab:T273763(设立专题空间后,链入页面API于 pywikibot 出错),此修正案导致部分机器人出错。目前phab:T273763已解决,留此节讨论其他相关技术出问题时的策略与解决方案。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月8日 (一) 17:54 (UTC)

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

第三阶段:修正指向专题的内部链接

各阶段不得同时讨论,前一项讨论完结之后,才能进行下一段讨论。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月3日 (日) 19:29 (UTC)

  • 第三阶段为修正指向专题的内部链接,主要要修正的是一些模板、模块等,纯粹叶面的内部链接因为有保留重定向故暂时还会有效,至于需不需要全部修正并删除重定向可以讨论(日维当时保留大部分的重定向至今)。已经修复的模板包括{{Namespace pagename}};目前已知待修复的模板有{{Category handler}}及{{Namespace detect}}。其余将陆续补充。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月29日 (五) 12:57 (UTC)
  • @A2569875:想请问一下快捷方式如何规定?目前是专题都占用了一个WP快捷方式,以后是否都需要把WP快捷方式换成WPJ快捷方式?--LightyearsTalk#欢迎加入智能手机专题 2021年1月30日 (六) 10:02 (UTC)
  • 是否需要修改所有的内部链接,可能需要与“是否需要删除WP->PJ的重定向”一并讨论。-- 五岁抬☎️·☘️) 2021年3月24日 (三) 05:47 (UTC)

第四阶段:调整专题模板

已完成:
已修改完大多数相关模板。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月14日 (日) 09:33 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。


本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

第五阶段:讨论重定向与捷径的设立方式

各阶段不得同时讨论,前一项讨论完结之后,才能进行下一段讨论。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月29日 (五) 12:57 (UTC)

本案进入倒数第二个部分。现在将讨论未来专题捷径如何设立,以及原有捷径的去留:
  • 未来是否允许创建跨WP与PJ空间的捷径?如果需要,是否需要进一步规范?
  • 未来是否允许创建跨WP与PJ空间的非捷径的重定向?
  • 旧有的跨WP与PJ空间的捷径是否需要清除链入然后(×)删除
[email protected]30000lightyearsTaiwania JustoLuciferianThomas羊羊32521BlackShadowG
请讨论-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月14日 (日) 09:41 (UTC)
  • 我认为PJ空间的捷径统一规范为WPJ/PJ:XXX,将现有WP重定向全部转到PJ去。比如WikiProject:智能手机WP:SMARTPHONE直接转移到WPJ:SMARTPHONE。--LightyearsTalk·Sign#订阅维猫报喵! 2021年2月14日 (日) 11:15 (UTC)
  • 个人意见
    1. 为了避免混淆,将来应该一律禁止创建跨WP与PJ空间的捷径重定向。
    2. 目前存在的WP重定向到PJ的捷径应该全部转移到PJ,若无链入或很少链入,可考虑(×)删除;若数量过大,或者已经在讨论中被引用,则可考虑(○)保留以仅供历史参考。
    3. 同时,将PJ名字空间中所有{{shortcut}}中的捷径一律改为以“PJ”开头的捷径,不再推荐使用以WP开头的捷径。

——BlackShadowG留言维基百科20岁生日快乐! 2021年2月14日 (日) 12:57 (UTC)

同上,不然就没必要伪名字空间了。 2021年2月14日 (日) 13:49 (UTC)
我觉得从PJ空间捷径连出没什么问题,WP空间也有捷径连至Help。PJ分拆了就不要再从WP连过去了,旧的就随它吧。--LuciferianThomas留言 2021年2月14日 (日) 14:09 (UTC)
旧的捷径如要批量删除的话可能要请求管理员开删除机器人...-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月14日 (日) 14:11 (UTC)
所以把PJ空间的{{shortcut}}全部更新,提醒将来的编者不要再用WP链接到PJ的捷径就行了。那些没有链入的WP捷径删了也无妨。——BlackShadowG留言维基百科20岁生日快乐! 2021年2月16日 (二) 02:05 (UTC)
个人意见:
  1. 原则上不允许,但社群就个别页面的特殊情形可以例外许可。建议以修改R2规范处理。
  2. 不允许。如出现,应清除链入并删除。
  3. 可行。清除链入可以请求bot(WP→PJ),删除的话我觉得开一个list,然后转AFD即可。
以上。SANMOSA SPQR 2021年2月17日 (三) 14:40 (UTC)
既然(我认为)未来不允许创建跨WP与PJ空间的非捷径重定向,而且非条目名字空间的非捷径重定向本来就使用率低下,如果真的有人意外创建了,都不会有多少链入,清除链入也不是什么困难的事,而且还能避免未来的误用。SANMOSA Σουέζ 2021年3月31日 (三) 07:43 (UTC)
Wikipedia:专题Wikipedia:专题委员会等部分页面为何还没有移动到新的名字空间?还是这些页面不应该移动?--百無一用是書生 () 2021年2月19日 (五) 02:46 (UTC)
先前讨论有提到将专题介绍留在WP空间。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月19日 (五) 17:12 (UTC)
专题委员会并非专题介绍,Wikipedia:专题似乎也称不上是介绍,更像是WikiProject:首页的作用--百無一用是書生 () 2021年3月1日 (一) 02:54 (UTC)
个人认为跨WP->PJ没差,但PJ->WP的不行-- Sunny00217  2021年2月21日 (日) 13:56 (UTC)

第五阶段:小结

总结以上讨论意见:

  1. 禁止创建跨WP与PJ空间的捷径重定向。并清理链入页面后删除现有跨WP与PJ空间的捷径重定向;同时,将PJ名字空间中所有{{shortcut}}中的捷径一律改为以“PJ”开头的捷径,不再推荐使用以WP开头的捷径。→修改R2规范
  2. Wikipedia:专题Wikipedia:专题委员会移动到PJ空间。→需探讨是否留重定向
以上-- 五岁抬☎️·☘️) 2021年4月7日 (三) 06:22 (UTC)

第六阶段:(暂不开放)

各阶段不得同时讨论,前一项讨论完结之后,才能进行下一段讨论。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月14日 (日) 09:41 (UTC)

本章节暂时不存档,直到部署完成。欲让机器人存档,请移除本模板。留言请置于本模板上方。

伪名字空间

[编辑此导航模板]

本案讨论格式手册及长期破坏者提升问题。目前有三案:

  • 格式手册及长期破坏者提升为名字空间,英语名称待定;
  • 格式手册及长期破坏者成为伪名字空间,缩写为MOS及LTA;
  • 维持现行方式。

请讨论。台湾杉在此发言 (会客室) 2020年12月25日 (五) 01:23 (UTC)

  • (+)支持将格式手册和长期破坏者设立为伪名字空间(-)倾向反对设立为名字空间,个人认为没有必要。--Yining Chen留言|签名) 2020年12月26日 (六) 11:32 (UTC)
  • (!)意见格式手册(LTA:)及长期破坏者(MOS:)要升格成“真”名字空间可能比较困难,因为没有别的维基百科分站、姊妹项目、语言版本有启用此设置,故技术细节无从参考,诸如Namespcae id(一个整数)也须讨论,且还有数字id可能重复的问题。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2020年12月26日 (六) 12:59 (UTC)
  • (+)支持成为伪名字空间。如果成为真·名字空间,我(+)倾向支持长期破坏者(LTA:),而不是格式手册(MOS:) ——羊羊 (留言|贡献) 2020年12月26日 (六) 15:44 (UTC)
建议立为伪名字空间(方案2)。SANMOSA SPQR 2020年12月27日 (日) 07:32 (UTC)
支持提升为名字空间,因为会违反快速删除方针的R2准则。 2020年12月28日 (一) 07:06 (UTC)
如果是伪名字空间通过,就会在下一阶段修订快速删除、捷径以及名字空间规范。--台湾杉在此发言 (会客室) 2020年12月28日 (一) 09:53 (UTC)
支持成为伪名字空间。名字空间涉及较多技术问题,未来如需求明显,可再议转换。--YFdyh000留言) 2020年12月30日 (三) 13:01 (UTC)
如需要立为名字空间也并非不可,只是要决定其所使用的数字ID
  • 0-99的名字空间ID要保留给维基媒体系统使用,故需要使用100以上的名字空间ID
    下面整理许多语言版本维基百科的名字空间ID使用(主空间是偶数,讨论空间是奇数)
名字空间 名字空间ID
/
讨论页ID
维基百科
各语言版本
使用状况(未穷举)
本地使用状况 备注
主题: 100/101 全部语言版本维基百科皆有启用 参考此处整理 本地已使用 Help:主题
专题: 102/103 中文及加泰兰文世界文法文韩文奥克西坦文日文 本地已使用 Wikipedia:专题
附件: 104/105 西班牙文 未使用 类似中文维基辞典的附录
列表: 104/105 立陶宛文维基 未使用 WP:列表
文献: 104/105 法文奥克西坦文 未使用 参考User:青子守歌的整理
仲裁: 106/107 俄罗斯文 未使用 (本地未通过相应指引)
WP:仲裁委员会
图书: 108/109 超过25个语言版本使用。 本地通过的共识为 :
繁简转换系统处理完毕后引入,然而P站仍在努力中,因此还是有机会使用此数值
Help:图书
110/111 未使用
草稿: 118/119 超过25个语言版本使用。 本地已使用 WP:草稿
以上补充。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2020年12月31日 (四) 09:52 (UTC)
  • 如果要设立的话可能就120/121与122/123吧,或110/111、112/113与120/121、122/123选一组。如果要避免跟未来新功能重复,也可以使用150之后的数字比较保险。同时亦须留意扩展名字空间ID列表有没有可能存在本地有机会引入的扩展。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月1日 (五) 08:07 (UTC)
    • (~)补充刚才到gerrit.wikimedia.org看了一下,其列出的Recommended名字空间ID共有:
      • 100 - Portal
      • 102 - WikiProject
      • 104 - Reference
      • 114 - Translation
    以上补充。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月21日 (四) 10:19 (UTC)
(+)支持为设立伪名字空间,对设为真名字空间(#)有保留。--LuciferianThomas留言 2020年12月31日 (四) 15:58 (UTC)
我对成立真名字空间(#)有保留,尤其是格式手册。对格式手册而言,因为格式手册同时也是指引,对它成立真名字空间将意味着指引分散两地。 --Milky·Defer 2020年12月31日 (四) 17:13 (UTC)

小结1

标题添加: ——羊羊 (留言|贡献) 2021年1月19日 (二) 05:21 (UTC)

  • 小总结一下,包含#先前讨论截至2021年1月1日 (五) 19:38 (UTC)之前,社群成员意见大致如下
    • 支持MOS真:2 (空气小猫 2020年12月28日 (一) 07:06 (UTC)、Sunny00217 2020年11月22日 (日) 12:26 (UTC))
    • 反对MOS真:2 (Yining Chen 2020年12月26日 (六) 11:32 (UTC)、MilkyDefer 2020年12月31日 (四) 17:13 (UTC))
    • 支持MOS伪:5 (LuciferianThomas 2020年12月31日 (四) 15:58 (UTC)、YFdyh000 2020年12月30日 (三) 13:01 (UTC)、SANMOSA 2020年12月27日 (日) 07:32 (UTC)、羊羊 2020年12月26日 (六) 15:44 (UTC)、Yining Chen 2020年12月26日 (六) 11:32 (UTC))
    • 反对MOS伪:1 (cwek Wikipedia_talk:名字空间#开放伪名字空间作捷径链接用)
    • 支持LTA真:3 (空气小猫 2020年12月28日 (一) 07:06 (UTC)、羊羊 2020年12月26日 (六) 15:44 (UTC)、Sunny00217 2020年11月22日 (日) 12:26 (UTC))
    • 反对LTA真:1 (Yining Chen 2020年12月26日 (六) 11:32 (UTC))
    • 支持LTA伪:5 (LuciferianThomas 2020年12月31日 (四) 15:58 (UTC)、YFdyh000 2020年12月30日 (三) 13:01 (UTC)、SANMOSA 2020年12月27日 (日) 07:32 (UTC)、羊羊 2020年12月26日 (六) 15:44 (UTC)、Yining Chen 2020年12月26日 (六) 11:32 (UTC))
    • 反对LTA伪:1 (cwek Wikipedia_talk:名字空间#开放伪名字空间作捷径链接用)
    大部分人皆认为可以设立伪名字空间,少数人认为可以成立真名字空间,亦有人认为碍于方针需升格为名字空间,然而部分人对是否升格为真名字空间有所保留。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月1日 (五) 19:38 (UTC)
    • @Taiwania Justo:目前这样的讨论模式不易解读共识,看是不是要根据LTA/MOS/真/伪逐条讨论,或直接开投票?-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月1日 (五) 19:41 (UTC)
      其实可以看出来大部分是伪名字空间为多数,还不至于动到投票的地步。--台湾杉在此发言 (会客室) 2021年1月2日 (六) 02:35 (UTC)
  • (+)支持设立LTA伪名字空间,(+)倾向支持设立MOS伪名字空间,(-)反对设立任何名字空间。—— Eric Liu 创造は生命(留言留名学生会 2021年1月2日 (六) 04:45 (UTC)
    • 如果主流意见都是伪名字空间,就得修方针指引了;万一方针指引没过,有配套吗?—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月2日 (六) 05:04 (UTC)
      顶多就是维持现状,直到通过为止。不过在修改时,R2增加的例外条款必须纳入社群的共识在里面,不至于不通过。--台湾杉在此发言 (会客室) 2021年1月2日 (六) 07:32 (UTC)
      基本上在这里支持设立伪名字空间的都理应明白伪名字空间就是R2例外的意思吧…?--LuciferianThomas留言 2021年1月4日 (一) 01:54 (UTC)
我想补充一个意见:我反对MOS及LTA设为真名字空间,仅支持MOS及LTA设为伪名字空间。SANMOSA SPQR 2021年1月2日 (六) 08:17 (UTC)
支持名字空间,反对伪名字空间。SmallTim留言) 2021年1月5日 (二) 13:56 (UTC)
(?)疑问@SmallTim:有鉴于WP:投票不能代替讨论,能否请您补充一下反对伪名字空间的理由,以便汇整、推进讨论?感激不尽。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月5日 (二) 18:25 (UTC)
这整得跟投票一样,建议各位将(+)支持(-)反对的理由写出来,逐一进行讨论,以此达到共识。毕竟投票不能代替讨论。 ——羊羊 (留言|贡献) 2021年1月5日 (二) 15:50 (UTC)
我建议直接排除成为真名字空间的可能性,这样会产生维护问题。SANMOSA SPQR 2021年1月6日 (三) 06:10 (UTC)
  • (?)疑问@Sanmosa:比方说哪方面的维护问题?数字ID跟扩展重复?(这个可以克服,顶多新扩展本站的Namespace id与其他语言版本或己妹项目不同步而已);页面内容维护?(我想不出什么样的情况会不利于维护);跨语言链接?-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月6日 (三) 06:44 (UTC)
方针指引宜集中于同一名字空间。SANMOSA SPQR 2021年1月6日 (三) 06:45 (UTC)
(!)意见SanmosaLTA不是方针、指引、态度指引、草案、提议、论述、专题、主题、存档、书籍、条目、分类、界面...都不是。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月6日 (三) 06:48 (UTC)
那你当我的建议仅适用于MOS。SANMOSA SPQR 2021年1月6日 (三) 06:51 (UTC)
  • 综上所述,@Taiwania Justo:由于本质不同,建议LTA与MOS分项讨论。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月6日 (三) 07:11 (UTC)
    这样好了,MOS大多数意见都是伪名字空间,可以开启第三阶段修订方针部分,然后LTA独立出来继续讨论,如何?--台湾杉在此发言 (会客室) 2021年1月6日 (三) 10:04 (UTC)
(?)疑问:有多少此次提案涉及的LTA?--Yining Chen留言|签名) 2021年1月7日 (四) 05:39 (UTC)

以上。--LuciferianThomas留言 2021年1月8日 (五) 02:01 (UTC)

把LTA设置成名字空间的一个效果是可以设置所有页面为noindex(包括少数不使用LTA模板的子页),虽然社群要评估一下这么做的价值。--GZWDer留言) 2021年1月10日 (日) 14:42 (UTC)

小结2

标题添加: ——羊羊 (留言|贡献) 2021年1月19日 (二) 05:21 (UTC)

@A2569875Taiwania Justo:其实我觉得上方的总结可能会导致共识的混淆。

表达意见用户 格式手册(MOS) 长期破坏者(LTA) 备注
升格名字空间 设伪名字空间
允许R2例外
升格名字空间 设伪名字空间
允许R2例外
Yining Chen 倾向反对 支持 倾向反对 支持
羊羊32521 反对 支持 倾向支持 支持 LTA倾向,意见优先取
Sanmosa 反对 支持 支持
Pseudo Classes 支持 反对 支持 反对 以违反CSD R2为由反对议案是否WP:CCC
YFdyh000 支持 支持
LuciferianThomas 有保留 支持 有保留 支持
Ericliu1912 反对 倾向支持 反对 支持
MilkyDefer 有保留 支持 有保留 支持 早前讨论
Super Wang 可开可不开 支持 早前讨论
Cwek 反对 反对 早前讨论
Lopullinen 倾向反对 倾向反对 早前讨论
Sunny00217 支持 支持 早前讨论
总计 2 : 4 : 2 7 : 3 : 1 3 : 2 : 3 8 : 3 : 0

此总结方式会否更加清晰?--LuciferianThomas留言 2021年1月12日 (二) 02:06 (UTC)

澄清一下,因为现行方针尚未针对此议题修正,实不宜直接设立伪名字空间,我认为修正方针应要在此议题之前完成。道理就像UBER进入到某市场一样,应在其进入市场前设立相应法规,避免无法与计程车公平竞争、司机有无载客资格和违法现行法规等问题。-- 2021年1月12日 (二) 17:45 (UTC)
此外,反对伪名字空间的理由是,MOS和LTA既为缩写,尽管名义上是伪名字空间,但是实际上仍属于条目名字空间,这样子与其内容冲突非常奇怪,更何况现存有许多辨识名字空间的模板,身为重度模板用户,我不希望辨识伪名字空间时,输出的结果为“条目”。-- 2021年1月12日 (二) 17:57 (UTC)
  • 在模板里面放if else不就好了。Module亦然。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月12日 (二) 18:07 (UTC)
    @A2569875:您应该明白我的重点不在这里吧。-- 2021年1月17日 (日) 14:20 (UTC)
    • 山不转路转、路不转人转。大可以将所有判断名字空间的模板在判断前先匹配伪名字空间表再做进一步输出,看不出有什么问题,很多语言版本维基都有它自己的“本地特化”。 对于倾向支持伪名字空间(当然如可能我还是希望名字空间啦,但基金会那边不一定会买单,你看编辑审核保护和Book:名字空间工单提那么久还在“神秘的技术问题搁置”就知道有多难,何况其他语言版本没有先例)对于倾向支持伪名字空间的立场者来说,当然会提出倾向于去符合对伪名字空间有利的方案去做提议。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月17日 (日) 14:38 (UTC)
      伪名字空间只是一个重定向页,模板所处的页面还是在项目空间上,当然不会输出“条目”,就像这个链接User:羊羊32521/S/VP点进去不会造成Wikipedia:互助客栈变成“用户页”一样。 ——羊羊 (留言|贡献) 2021年1月19日 (二) 05:14 (UTC)
  • 不认为以上问题是问题,模板模块加个if-else或switch case在本地特化的名字空间便是模板/模块不就好了,况且现在有不少的名字空间判断都不是直接引用魔术字,是使用中介模板例如{{Namespace_detect}},在里面补充if-else或switch case不就好了,先前讨论早就提议了“创建允许不快速删除的伪名字空间列表”,难道列表只能列在指引哩,不能写在程式里??;关于界面是同理,将是伪名字空间的页面改掉显示名称不就得了?技术上到底是有什么障碍,我看不出,有障碍的分明是“你不想”吧,例如下方列举的程式码片段:
以上。再来,快速删除方针,请参阅WP:CCC。 未见系统性问题,谢谢。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月19日 (二) 07:14 (UTC)
在伪名字空间部分,我是以“有需求”为前提,如果共识认为不需设立或不能设立,那就是维持原案,也就没有需要修方针的问题。--台湾杉在此发言 (会客室) 2021年1月13日 (三) 02:58 (UTC)
而以现时讨论而言主流意见为将MOS和LTA设为伪名字空间。--LuciferianThomas留言 2021年1月13日 (三) 05:16 (UTC)
@LuciferianThomas:影响的范围较大,即使有主流共识,目前讨论的参与者人数并不能代表整个社群。 2021年1月17日 (日) 14:17 (UTC)
能有多大?,不就条目名字空间里多几个几乎不会发生命名冲突的捷径而已?怎么讲的好像设立下去维基服务器会炸掉一样。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月17日 (日) 14:43 (UTC)
关于主流意见的共识,我认为引用WP:7DAYS并无不妥,你不可能直接让几千人一起讨论,你这样说干脆举办维基社群公投算了,BUT:WP:投票不能代替讨论。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月17日 (日) 14:45 (UTC)
个人认为,如果长期破坏者(LTA)有成为名字空间的潜力的话,应该此时直接升级成为名字空间。不然,如果之后再讨论升级为名字空间,所有带LTA:前缀的页面还要重新移动一遍。 ——羊羊 (留言|贡献) 2021年1月15日 (五) 12:04 (UTC)
感觉LTA页面及名字空间有违WP:RBI。如果设立名字空间的同时增设页面查看权限(回退员及以上),我会考虑支持。--YFdyh000留言) 2021年1月15日 (五) 12:28 (UTC)
但似乎普遍意见并不赞同LTA升格真名字空间,即使有潜力但却缺乏社群共识,也难以行事。--LuciferianThomas留言 2021年1月15日 (五) 17:40 (UTC)

(-)反对设立MOS和LTA名字空间,这与技术问题无关,而是目前MOS和LTA页面的数量和读者关注的程度远远达不到需要设立新名字空间的地步。LTA页面的数量充其量也就一百个左右,MOS页面的数量更是少得可怜,才十几个,远远没有达到维基专题那样的2000多个页面。同时,LTA只有熟悉CU等站务的编者会去查阅,MOS查阅的人数更少,这些也完全比不上熟悉某些特定领域的编者和读者都会关注的维基专题。因此,我反对设立以上两个名字空间,对设立伪名字空间表示(=)中立。——BlackShadowG留言维基百科20周年庆即将到来 2021年1月15日 (五) 13:41 (UTC)

LTA数量可能少,但shortcut还是蛮多的。而且LTA数量也会增多-- ——羊羊 (留言|贡献) 2021年1月16日 (六) 12:55 (UTC)
伪名字空间只是for捷径链接而已,原本的页面不会被移动。--LuciferianThomas留言 2021年1月16日 (六) 13:12 (UTC)
  • (+)支持伪名字空间。我原本是支持名字空间的,但经历了上述讨论以及主持了专题名字空间的设立,我发现伪名字空间是有许多优点的。先看名字空间,名字空间是需要“安装”的,本地获得共识之后要等待工程师安装,期间从数周到数月不等,且不具备可扩充性,即每新增一个名字空间都要请工程师协助,本地管理员、界面管理员、模块编辑员都无能为力,只有基金会工程师可以执行,“真名字空间”可扩充性不佳。我们来看看“伪名字空间”,它“免安装”耶,随加即用,涉及名字空间判断的本地模板与模块本地的管理员、界面管理员、模块编辑员都能即时加入,也不必等待工程师安装,“伪名字空间”可扩充性十分良好。假如今天社群需要一个新的捷径前缀或字首,真名字空间需要等待工程师安装,而伪名字空间公示通过后就能随加即用,是多么的方便。正如台湾杉在此发言 (会客室)所言:“如果伪名字空间不会造成“系统性”的重大问题,就可以纳入考量。”且许多问题如模板输出都可以透过技术手段解决,参见#宇帆于2021年1月19日 (二) 07:14 (UTC)之发言。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月19日 (二) 07:16 (UTC)

捷径空间提案

标题添加: ——羊羊 (留言|贡献) 2021年1月19日 (二) 05:21 (UTC)

否决:
设立捷径专用名字空间无法有效解决本案核心问题。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月20日 (三) 07:14 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

  • 大家普遍对于创建新名字空间“页面不够不足以独立名字空间”、“独立名字空间指引会分散两地”.....、又不想占用其他名字空间,或不想看到界面显示为“条目”....又有许多意见想解决名称冲突问题......这也太困难(好似:又要马儿肥、又要马儿不吃草)。(&)建议干脆定义一个“捷径”名字空间“Shortcut:”好了。然后找一个简短的文字当作名字空间别名,例如“Link”的“L”,然后捷径变成“L:MOS:XX”、“L:LTA:XX”之类的,这样既不会占用其他名字空间造成命名冲突,界面也不会显示为“条目|条目讨论”会显示为“捷径|捷径讨论”;也不必担心页面太少不足以独立成名字空间:因为它整合了MOS、LTA等;也不会导致指引分散两地;也不会占用到其他名字空间;也不会有名称冲突。(为了整合所有反对意见所产生的奇异提案。)-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月17日 (日) 09:29 (UTC)
    • 刚才小研究一下英文维基的伪名字空间,真的有许多诡异的伪名字空间捷径,除了MOS:外,例如“MP:”连接首页上不同区域的章节捷径。。。如果社群倾向不跟随英文维基也是可以搞一个本地特色的名字空间。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月17日 (日) 10:29 (UTC)
    但此会造成混乱,因为WP:VIP之类的捷径却不在捷径空间,但也同时没有理由改为L:WP:VIP。--LuciferianThomas留言 2021年1月18日 (一) 02:08 (UTC)

本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

小结3

  • 我的意见是,如果伪名字空间不会造成“系统性”的重大问题,就可以纳入考量。例如占用其他名字空间、习惯性等等问题,在我眼中看来不是重大系统问题,而且可以透过其他技术手段解决(如上所述)。--台湾杉在此发言 (会客室) 2021年1月18日 (一) 10:16 (UTC)
    “显示为‘条目|条目讨论’”是指重定向页吗?我觉得重定向页显示条目没什么大问题() ——羊羊 (留言|贡献) 2021年1月19日 (二) 05:07 (UTC)
    见ナナチ上方的留言,当中有说明可在MediaWiki:Common.js加一段代码让伪名字空间不显示“条目”。--LuciferianThomas留言 2021年1月19日 (二) 07:50 (UTC)
用户自订的Common.js测试有关代码的结果。测试于[[MOS:001]]
(:)回应@LuciferianThomas:已测试相关代码(程式码片段)在Common.js中的行为,Special:Diff/63843386,以[[MOS:001]]为例,效果见图File:Pseudo-Namespace MOS UI Test in Chinese Wikipedia.png。如伪名字空间通过设立可以考虑请求界面管理员添加相关代码于MediaWiki:Common.js。副知@羊羊32521:重定向页显示条目已有可行解决办法。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月21日 (四) 08:32 (UTC)
  • 其实照这个思路,如果怕伪名字空间占用条目名字空间,又怕(对于MOS:)指引分散,可以设立MOS:名字空间,然后MOS:下的页面重定向到Wikipedia空间的格式手册里 ——羊羊 (留言|贡献) 2021年1月19日 (二) 05:21 (UTC)
    这不太符合逻辑吧,同时存在“格式手册”名字空间和项目(维基百科)名字空间的格式手册。额外设立一个“格式手册”或“长期破坏者”名字空间但只作重定向用,好像没什么意义。--LuciferianThomas留言 2021年1月19日 (二) 07:48 (UTC)

再提捷径空间提案

尝试推动LTA空间

结以待续,请发起新议案。--LuciferianThomas留言 2021年1月31日 (日) 23:09 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

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

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

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

如果用户不可查看的名字空间不会显示在Special:搜索,我想名字空间多不是个大问题。赞成“LTA与Project空间联系性不大”。不认为二次移动是个大问题,社群可以先用伪名字空间看看效果。--YFdyh000留言) 2021年1月23日 (六) 12:25 (UTC)
  • 我觉得可以,但目前名字空间的申请正在排队(需插入程式码到\mediawiki-config\wmf-config\InitialiseSettings.php ,且如有页面权限问题或要不要NOINDEX问题需要额外调整$wgNamespacesToBeSearchedDefault、$wgNamespaceRobotPolicies等其他数值,如需要对IP用户和新用户隐藏,可能还需要mw:Extension:Lockdown),因此,如需设立可能还需要等待数周。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月25日 (一) 06:29 (UTC)
  • 本议案可能须分阶段讨论,要讨论的项目有:
    1. 是否需要默认关闭LTA页面的Special:搜索?(mw:Manual:$wgNamespacesToBeSearchedDefault设置)
    2. 是否需防止LTA页面被机器人或网络爬虫索引?(mw:Manual:$wgNamespaceRobotPolicies设置)
    3. 是否需设置LTA页面的检视权限?(例如,只有自动确认用户、巡查员、回退员、管理员能检视/访问这些页面,需引入mw:Extension:Lockdown
    等。如具备以上需求,才有必要定为名字空间。以上,请讨论-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月27日 (三) 04:57 (UTC)
    • 根据之前的一些Task维基媒体不会启用mw:Extension:Lockdown。但是如果只是为了避免WP:BEANS而没有保密需求那么用CSS屏蔽掉内容显示即可。--GZWDer留言) 2021年1月27日 (三) 11:58 (UTC)

本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

伪名字空间相关方针及WP:捷径修正

通过:
Taiwania JustoPseudo ClassesSanmosaA2569875GZWDer公示七日结束,共识期间唯一异议排除,公示获得通过,有关条文。即日起MOS、LTA伪名字空间获得CSD R2例外,上述名字空间作为格式手册和长期破坏者页面的正规链接。--LuciferianThomas留言 2021年1月31日 (日) 03:11 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

本讨论已近一个月,得到的回馈有:

  1. 主流意见认为格式手册及长期破坏者(持续出没的破坏者)宜设立伪名字空间;
  2. 已有技术手段可分出伪名字空间与主名字空间的差异性;
  3. 设立伪名字空间无重大系统性问题,且部署容易,不牵涉到基金会层面之程式修改。

由此,伪名字空间将会在上段讨论开始一个月后进行公示(也没过几天),而相关规范也将尽速修正或设立,下列针对快速删除方针R2进行修正,及将WP:捷径中的伪名字空间部分做为指引。下列为R2修正提案。

现行条文

R2. 跨名字空间重定向

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

R2. 跨名字空间重定向

由条目的名字空间重定向至非条目名字空间,将用户页移出条目名字空间时遗留的重定向,或者从草稿名字空间指向非草稿名字空间的重定向。经社群同意设立的伪名字空间属于本规则之例外。注意:有时新加入的维基人偶尔会在主条目空间误建用户页。使用“移动”页面工具将用户页移回用户名字空间会保留页面历史,在删除遗留的重定向页前,考虑保留一到两天;草稿重定向速删前,请确保草稿已经完成其作用,并且草稿的历史已经合适地移动到相应的正式页面。

捷径中伪名字空间的规范详见这里

请讨论。台湾杉在此发言 (会客室) 2021年1月20日 (三) 06:53 (UTC)

同意提案。SANMOSA SPQR 2021年1月20日 (三) 08:10 (UTC)
(+)赞成R2修正案,另就WP:捷径,我看了一遍,似乎要整个重新整理过。--LuciferianThomas留言 2021年1月20日 (三) 10:04 (UTC)
捷径修正细节是最后一项讨论内容,目前先以伪名字空间为讨论对象。也欢迎对捷径规范作重新整理。--台湾杉在此发言 (会客室) 2021年1月20日 (三) 12:19 (UTC)
(+)支持WP:CSD修正案与伪名字空间。我原本是支持名字空间的,但经历了上述讨论以及主持了专题名字空间的设立,我发现伪名字空间是有许多优点的。先看名字空间,名字空间是需要“安装”的,本地获得共识之后要等待工程师安装,期间从数周到数月不等,且不具备可扩充性,即每新增一个名字空间都要请工程师协助,本地管理员、界面管理员、模块编辑员都无能为力,只有基金会工程师可以执行,“真名字空间”可扩充性不佳。我们来看看“伪名字空间”,它“免安装”耶,随加即用,涉及名字空间判断的本地模板与模块本地的管理员、界面管理员、模块编辑员都能即时加入,也不必等待工程师安装,“伪名字空间”可扩充性十分良好。假如今天社群需要一个新的捷径前缀或字首,真名字空间需要等待工程师安装,而伪名字空间公示通过后就能随加即用,是多么的方便,然而要实现此需要修正WP:CSD#R2,正如台湾杉在此发言 (会客室)所言:“如果伪名字空间不会造成“系统性”的重大问题,就可以纳入考量。”,参见#宇帆于2021年1月19日 (二) 07:16 (UTC)之发言,未见要修正WP:CSD#R2会出现什么系统性问题,故此(+)支持WP:CSD修正案。以上-- 来人啊,喂宫子吃布丁! ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月21日 (四) 08:06 (UTC)
想向诸位确认一下@A2569875Taiwania Justo:此案中已经说明伪名字空间的实施,意即此案通过则伪名字空间同步通过?--LuciferianThomas留言 2021年1月22日 (五) 11:32 (UTC)
顺序是上面的MOS、LTA先公示完毕,本案才会接着进行公示。于此期间两边同步讨论。--台湾杉在此发言 (会客室) 2021年1月22日 (五) 15:05 (UTC)
我认为两案必然挂钩,建议若公示伪名字空间则同步公示R2修订,没有分部处理的必要。--LuciferianThomas留言 2021年1月22日 (五) 22:06 (UTC)
@Taiwania Justo:两者应当一同公示并通过,否则会有合法性问题。SANMOSA SPQR 2021年1月23日 (六) 08:55 (UTC)
借问:现在讨论似乎已经算超过一个月了(这提案承接上次讨论,已经很久了),而已经达到基本社群共识(共识不强求全然同意,但可采取主流意见),理论上可以7DAYS?--LuciferianThomas留言 2021年1月23日 (六) 09:25 (UTC)
那就现在公示吧。--台湾杉在此发言 (会客室) 2021年1月24日 (日) 02:47 (UTC)

本讨论超过一个月,且伪名字空间之相关技术问题已得到解决,且主流意见认为有设置必要,现就伪名字空间、R2及WP:捷径内的伪名字空间规范 公示7日,2021年1月31日 (日) 02:51 (UTC) 结束台湾杉在此发言 (会客室) 2021年1月24日 (日) 02:51 (UTC)

@Taiwania JustoLuciferianThomas:启用伪名字空间能解决什么问题?我相信这是提案必须讨论的重点,我需要有人能回答这个问题。如果没办法解决什么问题,我认为维持现状即可,也就是WP足矣。然而,就我查看整个讨论,似乎都是讨论名字空间真伪的可行性,只有几个留言有提到这个问题。 2021年1月29日 (五) 04:57 (UTC)
看来你是没有看到最初的讨论,见本章节顶端讨论导航最初的讨论,已经是说明了伪名字空间的作用为让捷径意义更加清晰且减少可能构成重复的捷径名称的情况。现在不是解决问题的情况,而是优化社群讨论和表达的问题了。--LuciferianThomas留言 2021年1月29日 (五) 05:01 (UTC)
一直以来捷径都没有什么规范,尤其是格式手册、维基专题及LTA的页面重定向,表达不清之余容易造成混乱,伪名字空间就是让这些项目的捷径统一化,方便社群沟通。--LuciferianThomas留言 2021年1月29日 (五) 05:04 (UTC)
例子:MOS:BOLDWP:MOSBOLD简洁,但链接至格式手册的捷径没有规范导致格式混乱难以维护,有些有WP:MOS字首有些没有;而LTA更甚,捷径完全没有要表达链接目标为LTA页面的意思。相对于WP:LTA/HBN,使用伪名字空间概念的LTA:HBN更简洁易明。在解决捷径的问题的同时顺便推动在其他维基项目运行畅顺的伪名字空间比较合适。--LuciferianThomas留言 2021年1月29日 (五) 05:13 (UTC)
@LuciferianThomas:真是抱歉,我没有一直关注这个提案,突然要找相关讨论也找不到。既然如此,我没意见了。-- 2021年1月29日 (五) 14:02 (UTC)

本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

进一步讨论

自动提删R2

完成 by Jimmy Xu--LuciferianThomas留言 2021年2月1日 (一) 23:04 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

现时主名字空间的R2好像有机器人自动提速删?是否要请BOT主修正,或暂时透过过滤器阻止机器人速删?--LuciferianThomas留言 2021年1月31日 (日) 03:11 (UTC)

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

本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

MOS捷径名称

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

WP:NS2021/MOSSC,已列出部分格式手册可用捷径,请检查,并协助补充。--LuciferianThomas留言 2021年2月1日 (一) 08:48 (UTC)
已完成,请协助检查。--LuciferianThomas留言 2021年2月3日 (三) 04:35 (UTC)

软重定向

已否决:
--LuciferianThomas留言 2021年1月31日 (日) 04:58 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

原有的捷径可否改为软重定向并作出提示“此捷径已移动至XXX,请直接使用新捷径”?--LuciferianThomas留言 2021年1月31日 (日) 03:11 (UTC)

(-)反对,原有重定向应保留,没必要软重定向。-- 2021年1月31日 (日) 03:56 (UTC)
或是透过JS小工具提示功能,让用户在非讨论页面中点击旧有链接时提示修改为新链接?--LuciferianThomas留言 2021年1月31日 (日) 04:23 (UTC)
不必更动,英语维基百科部分MOS也有用WP的捷径。--台湾杉在此发言 (会客室) 2021年1月31日 (日) 04:32 (UTC)
好的,那么就舍弃软重定向,只重新议论MOS的捷径名称。--LuciferianThomas留言 2021年1月31日 (日) 04:52 (UTC)

本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

技术问题处理

已通过:
已完成设置并布署。-- 五岁抬☎️·☘️) 2021年3月24日 (三) 05:50 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

名字空间侦测模板以及MediaWiki:Common.js见此处)需要提编辑请求,以令伪名字空间生效。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月31日 (日) 05:30 (UTC)

小补充:伪名字空间捷径可用{{捷径重定向}}标记,已加入自动侦测伪名字空间显示伪名字空间简单说明。--LuciferianThomas留言 2021年2月2日 (二) 05:55 (UTC)
另外@A2569875:已创建MOS:MOS:MOSMOS:手册MOS:格式手册供你们测试各项技术问题。--LuciferianThomas留言 2021年2月2日 (二) 05:59 (UTC)
根据Wikipedia:保护方针#需进行公示,即使伪名字空间已获得社群共识,轻微影响外观显示的编辑仍需公示七日,因为未添加亦不会影响伪名字空间的运作。-- 2021年2月2日 (二) 06:29 (UTC)
@LuciferianThomas。-- 2021年2月2日 (二) 06:34 (UTC)
@LuciferianThomasPseudo Classes:还不能公示,因为讨论仍在进行中MediaWiki_talk:Common.js#编辑请求_2021-01-31。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月2日 (二) 06:39 (UTC)
不影响运作,他可以使用个人JS页面进行测试,只是这个意思。而提及重定向模板纯粹因为这个章节叫做“技术问题处理”,没有其他地方方便提及就在这里说而已。--LuciferianThomas留言 2021年2月2日 (二) 07:22 (UTC)
(:)回应由于U:YFdyh000提到的误导问题,故反对使用个人用户小工具模式,因为误导问题就是在于不知此事的人,知道的人启用小工具又有什么卵用?故强烈建议全站套用。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月2日 (二) 10:50 (UTC)
@A2569875:可以考虑作为默认启用的小工具,这样也方便维护。--安忆Talk 2021年2月2日 (二) 12:35 (UTC)
@Pseudo Classes:阁下错引方针了,该章节位于“使用和处理编辑请求”章节底下,指明是管理员和模板编辑员在处理编辑请求的情况下才需要经过讨论及七日公示。该模板仅为半保护防止破坏,而非模板保护。--LuciferianThomas留言 2021年2月2日 (二) 11:47 (UTC)
@LuciferianThomas:首句“在受保护的页面上编辑时,应当特别小心,并于共识和任何相关的指导方针相一致”,只要是受保护的页面均受此限制。-- 2021年2月2日 (二) 11:54 (UTC)
该章节也提到:“一些会轻微影响使用方式和外观显示的编辑,需在提交编辑请求后等待七天,无争议方可进行修改”,您没有提出编辑请求即自行更改,可视为绕过程序。-- 2021年2月2日 (二) 11:58 (UTC)
自动确认用户编辑非编辑争议的半保护页面也要提出编辑请求是什么说法?那么怎么不直接模板保护?--LuciferianThomas留言 2021年2月2日 (二) 12:01 (UTC)
@LuciferianThomas:依照您这个说法,难道模板编辑员和管理员对模板重大更新,都不用提交编辑请求?此外,半保护并不是只有防止破坏,其亦属于高风险模板。-- 2021年2月2日 (二) 12:17 (UTC)
已处理,见本人讨论页。--LuciferianThomas留言 2021年2月2日 (二) 12:45 (UTC)
  • 当初本议案一堆人以“界面会显示[条目]”为由异议,后来是提出了“修改MediaWiki:Common.js解决问题”排除异议,而使得异议排除通过议案,那如果现在不设置不就变成“异议没有排除”?反对这种花式推翻议案的作法。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月2日 (二) 12:01 (UTC)
    (已站外解释,宇帆似乎误解了我们上面说公示和编辑保护模板的事情。)另外想说此处之前对有关JS编码的支持意见可视为对于“同意作出这样更改”的意见吗?--LuciferianThomas留言 2021年2月2日 (二) 12:48 (UTC)
创建预设启用/默认启用的小工具来呈现伪名字空间界面
还有个小建议:当处于移动视图时,不必在minerva皮肤的页面标题(脚本里的tips_selector)处添加提示,因为在触控设备上没办法看到鼠标悬停才有的提示,反而被加了下划线,感觉不太美观。--安忆Talk 2021年2月2日 (二) 16:31 (UTC)
(:)回应@AnYiLinUser:A2569875/pseudonamespace_UI.js已修改。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月2日 (二) 19:48 (UTC)
感觉用'ontouchstart' in document.documentElement来判断更合适。--安忆Talk 2021年2月3日 (三) 08:59 (UTC)
完成AnYiLinSpecial:Diff/64090030,已加入代码。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月3日 (三) 09:33 (UTC)
(+)支持预设启用小工具,在使用上与修改界面理应无异;亦方便维护,当通过新伪名字空间时可快速增添设置。--LuciferianThomas留言 2021年2月3日 (三) 08:47 (UTC)
(~)补充:亦支持直接修改界面,这真的视乎最终选择。--LuciferianThomas留言 2021年2月3日 (三) 08:53 (UTC)
@LuciferianThomas:修改界面?那不就又回到独立成新的名字空间了吗?(技术问题还少些)-- Sunny00217  2021年2月4日 (四) 08:47 (UTC)
…你是真的没有跟上整个讨论对吧…所谓“修改界面”是修改显示界面,仅表示显示界面时捷径页不是直接显示页面为“条目”而已,实际上不影响任何其他方面。--LuciferianThomas留言 2021年2月4日 (四) 08:52 (UTC)
小工具执行结果
以页面[[MOS:MOS]]为例
Pseudo Namespace UI desing for zhwiki.png Pseudo Namespace UI desing for zhwiki zh-hans.png
设置为繁体中文(以zh-tw为例) 设置为简体中文(以zh-cn为例)
提供目前版本小工具运行结果图,供公示参考用。右上角的链接为Wikipedia:伪名字空间用于说明,如有缺漏欢迎改善。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月3日 (三) 19:03 (UTC)
@A2569875:等等等一下,这版在像是Mos:$1没有大写的也会执行耶,,,-- Sunny00217  2021年2月4日 (四) 08:45 (UTC)
(※)注意:为免混淆WP:伪名字空间原有内容移动至WP:PNS+,并改为指向WP:捷径#伪名字空间使其等价WP:伪名字空间的重定向。--LuciferianThomas留言 2021年2月5日 (五) 06:21 (UTC)
  • (?)疑问@LuciferianThomas:所以“OOjs UI icon helpNotice-ltr.svg伪名字空间”([[WP:偽名字空間|偽名字空間]])要改成什么?-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月5日 (五) 06:46 (UTC)
    维基百科:伪名字空间辅助说明(捷径WP:PNS+)--LuciferianThomas留言 2021年2月5日 (五) 08:10 (UTC)
    BTW在问号图案后加个空格呗,贴著很丑…--LuciferianThomas留言 2021年2月5日 (五) 08:13 (UTC)
    • 完成Special:Diff/64147054。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月6日 (六) 14:00 (UTC)
    • @LuciferianThomas:还有其他疑问吗?若没有我就要公示啰?@AnYiLin:高风险模板/界面编辑请求的公示确定不必放公告栏吗?-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月7日 (日) 04:07 (UTC)
      支持启动公示。--LuciferianThomas留言 2021年2月7日 (日) 04:37 (UTC)
      在此公示吧,这个修改只是配合伪名称空间的使用,后者已经公示过了。我刚刚也再次读了一遍保护方针,没理解错的话其只要求在对受保护的模板和模块进行一些更改时需要达成共识/进行公示。
      此小工具会默认开启并在参数设置处隐藏,避免用户误操作关闭(达到和直接放进common.js同样的效果)。--安忆Talk 2021年2月7日 (日) 04:46 (UTC)
      我反对隐藏,我个人不需要这个功能,想将其关闭。用户误关闭不会造成严重问题,如果有人问起相关问题,叫他重新打开就好了,看不出隐藏的必要性。--Xiplus#Talk 2021年2月15日 (一) 04:34 (UTC)
      但是如果这段代码直接按最初设想放进common.js的话,也是关不掉的吧。--安忆Talk 2021年2月15日 (一) 04:44 (UTC)
      做成小工具就是因为有关闭的需求,其次是维护的需求。--YFdyh000留言) 2021年2月15日 (一) 04:46 (UTC)
      做成小工具本来就是我提出来的,从未考虑过提供其他需求(比如自由选择开关),只是为了方便维护,不用去改common.js,放进common.js根本没得选。--安忆Talk 2021年2月15日 (一) 04:51 (UTC)
  • 公示7日:现交付公示,公示详细信息如下:
小工具源代码
User:A2569875/pseudonamespace_UI.jsWP:CSD#O1)→MediaWiki:Gadget-pseudonamespace-UI.js
(公示完毕后会使用“移动不留重定向”功能移动到MediaWiki:Gadget-空间)
小工具执行结果
以页面[[MOS:MOS]]为例
Pseudo Namespace Gadget for zhwiki zh-hant.png Pseudo Namespace Gadget for zhwiki zh-hans.png
设置为繁体中文 设置为简体中文
如期内无合理异议则全站套用此修改。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月8日 (一) 05:56 (UTC)
公示通过了,@A2569875AnYiLin。--LuciferianThomas留言 2021年2月15日 (一) 06:49 (UTC)
@LuciferianThomas:被User:Jon_(WMF)删掉了Special:Diff/64319519....说什么有东西undefined,看半天没看出原因,至少我这边所有装置测试都没出问题。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月16日 (二) 06:40 (UTC)
看起来是startsWith()问题,部分浏览器不支援。--LuciferianThomas留言 2021年2月16日 (二) 09:10 (UTC)
安亿君帮您为不支援的平台补了function的定义了。--LuciferianThomas留言 2021年2月16日 (二) 09:12 (UTC)

完成:已通过并布署。-- 五岁抬☎️·☘️) 2021年3月24日 (三) 05:50 (UTC)

本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

自动半保护伪名字空间

我很难说有多少人会去破坏MOS捷径,但倒是LTA捷径有可能会被破坏。建议可自动半保护(创建、编辑、移动)主名字空间“MOS:”、“LTA:”字首的条目空间。--LuciferianThomas留言 2021年1月31日 (日) 08:28 (UTC)

不应做出预见性保护。--Xiplus#Talk 2021年2月2日 (二) 10:26 (UTC)
若捷径指向的条目因为破坏被保护,有需要跟随进行保护吗?--LuciferianThomas留言 2021年2月2日 (二) 12:06 (UTC)
不需要吧,有这样的案例吗?--Xiplus#Talk 2021年2月2日 (二) 12:30 (UTC)
案例我不清楚,但我倒是觉得需要,尤其本来有某些LTA有破坏自己LTA页的倾向,可算是高风险。--LuciferianThomas留言 2021年2月2日 (二) 12:59 (UTC)
有破坏事实就能保护,不需预先保护。--Xiplus#Talk 2021年2月2日 (二) 13:04 (UTC)
建议用滥用过滤器阻止非自动确认用户编辑,配以相关警告。--YFdyh000留言) 2021年2月2日 (二) 13:07 (UTC)

提议设立快速删除标准 O8

现行条文

(无)

提议条文

O8. 在伪名字空间中创建非重定向的页面。

  • 伪名字空间仅能用于重定向。如可以移动到合适的名称,请将页面移动到合适的名称,否则,请使用此款快速删除;若页面明显是一个条目,则不适用此款快速删除。
  • 使用模板{{d|O8}}

根据上述讨论,伪名字空间应仅能是重定向页。位于伪名字空间中的非重定向页应可被快速删除。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月1日 (一) 09:53 (UTC)

(+)支持,若有条目真的需要以伪名字空间占用条目前缀,使用全形冒号而非半形冒号以辨别即可,此可避免之前有用户担忧会占用主空间条目名的情况。另外,我本来是在想可以把这条同时套用于不当使用伪名字空间重定向至其他页面,但想起有个别属于格式手册的论述其实不在Wikipedia:格式手册/前缀(WP:SAL),所以暂时作罢。--LuciferianThomas留言 2021年2月1日 (一) 11:12 (UTC)
@LuciferianThomas:使用全形冒号,极有可能违反命名常规。-- 2021年2月2日 (二) 05:46 (UTC)
未见命名常规有不能用全形冒号的规则。若以与事物本身名称不同说违反常规,可按照其他命名技术限制做法,不加冒号或改用全形冒号,并以{{Wrongtitle}}标记即可。--LuciferianThomas留言 2021年2月2日 (二) 05:52 (UTC)
@LuciferianThomas:名从主人,这就是有用户担忧会占用主空间条目名的情况,也有像en:Gadget:Invention, Travel, & Adventure类似的情况。-- 2021年2月2日 (二) 06:04 (UTC)
可直接按照该情况处理,若通过则当作技术限制即可。用{{DISPLAYTITLE}}修正亦可。--LuciferianThomas留言 2021年2月2日 (二) 06:21 (UTC)
这理论上可以出现在任何名字空间的情况,故按照名字空间一般处理方式即可。--LuciferianThomas留言 2021年2月2日 (二) 06:24 (UTC)
很抱歉,{{DISPLAYTITLE}}需使用全名,少一个冒号就不会更改显示。-- 2021年2月2日 (二) 06:33 (UTC)
(+)支持。--忒有钱🌊塩水あります🐳留言) 2021年2月1日 (一) 15:20 (UTC)
为何不是移动到合适的名称?例如在LTA:误建LTA页面应该移动到WP空间后,让原先页面成为重定向之类的。--Xiplus#Talk 2021年2月2日 (二) 05:53 (UTC)
若果明显属于错误创建有关专题页面的当然可以移动,这里应该是指创建与该专题无关的页面。--LuciferianThomas留言 2021年2月2日 (二) 06:01 (UTC)
那就要写清楚,避免被提快速删除后,管理员未注意直接删除。-- 2021年2月2日 (二) 06:07 (UTC)
(!)意见:伪名字空间的设立理应是用作指向比较复杂的Wikipedia名字空间项目,不应用以指向其他无关条目,或许可以增加删除“非指向维基百科名字空间的重定向”条款?理论上伪名字空间属于WP空间的延伸,不应该出现指向WP以外的伪名字空间,其他名字空间有自己的名字空间别称,不会使用伪名字空间捷径。未来倘若通过将部分项目升格名字空间,但该项目本身有伪名字空间捷径,该等捷径理应全数自动纳入新名字空间而不会保留于主名字空间,不会影响此规则。--LuciferianThomas留言 2021年2月2日 (二) 06:12 (UTC)
呃忘了有几条MOS在PJ空间。--LuciferianThomas留言 2021年2月3日 (三) 08:48 (UTC)
还有这种事?!-- Sunny00217  2021年2月3日 (三) 09:18 (UTC)
有啊,专题的条目指引有几条跟随专题搬过去了。列表有写。也有疑似专题移了但分页未移的余孽,但迟早都要搬过去吧。--LuciferianThomas留言 2021年2月3日 (三) 11:10 (UTC)
§ 第二阶段:转移至新名字空间在讨论这类MOS的更名,很快就能解决。——BlackShadowG留言维基百科20岁生日快乐! 2021年2月4日 (四) 11:18 (UTC)
加了附加条件之后让我觉得这个准则永远不会被使用,无论是什么内容都应该根据内容来移动到新名称,若是破坏也可用现存的G3等删除。--Xiplus#Talk 2021年2月3日 (三) 13:59 (UTC)
至少这也能成为移动操作的依据。快速删除方针的应用有时并不限于快速删除本身。SANMOSA SPQR 2021年2月17日 (三) 15:06 (UTC)
  • “快速删除方针的应用有时并不限于快速删除本身”如无异议将在适当的时间进行公示。-- 五岁抬☎️·☘️) 2021年4月7日 (三) 06:24 (UTC)

将LTA空间设置为noindex

认为LTA空间应设置为noindex 避免搜索引擎索引。 具体的作法可创建专用于标记伪名字空间的模板,在模板内用{{Namespace_detect}}判断是否为LTA空间,加入noindex 魔术字。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月3日 (三) 13:43 (UTC)

条目空间中无法使用noindex魔术字。--Xiplus#Talk 2021年2月3日 (三) 13:54 (UTC)
@Xiplus:意思说部分维护模板的设置是设置辛酸的?!-- Sunny00217  2021年2月3日 (三) 14:54 (UTC)
@羊羊32521YFdyh000:看来LTA还是需要升格为独立的名字空间,才不会被其他名字空间的设置档左右。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月3日 (三) 18:57 (UTC)
开新讨论吧。--LuciferianThomas留言 2021年2月3日 (三) 22:29 (UTC)
连过去的是WP,可以将该页NOINDEX吧,那么相关捷径就会有同样效果?--台湾杉在此发言 (会客室) 2021年2月4日 (四) 08:39 (UTC)
其实Google搜索似乎没看到这些页面,或许重定向本来就被忽略?--LuciferianThomas留言 2021年2月5日 (五) 01:52 (UTC)
Bing找得到但直接显示目标页面内容。--LuciferianThomas留言 2021年2月5日 (五) 01:55 (UTC)
所以还需要noindex吗 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年2月18日 (四) 03:02 (UTC)
需要是独立的名字空间才能设置noindex—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月18日 (四) 10:12 (UTC)
@羊羊32521:我认为如果可以设置的话会更佳,但可能名字空间化会比较方便。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年3月3日 (三) 05:20 (UTC)
那我周末再提一下 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月3日 (三) 15:00 (UTC)
(?)疑问改这个是否可行?--安忆Talk 2021年3月3日 (三) 15:13 (UTC)
仍支持名字空间案,我只是觉得提升名字空间案一直被人以奇怪的理由关掉很可惜。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年3月3日 (三) 15:21 (UTC)
那就搬新段重开吧,抱歉太乱了。--LuciferianThomas留言 2021年3月6日 (六) 06:51 (UTC)
也没有乱吧,个段落应该分开检视吧,怎么会不能放在两个结束之议案的中间呢?-- 五岁抬☎️·☘️) 2021年3月10日 (三) 06:00 (UTC)
从语法看可以。--YFdyh000留言) 2021年3月3日 (三) 15:22 (UTC)
以往phab有修改此部分的先例吗?-- 五岁抬☎️·☘️) 2021年3月17日 (三) 06:42 (UTC)
如果没有的话,我认为很难实行。-- 五岁抬☎️·☘️) 2021年3月31日 (三) 06:51 (UTC)
实测上Google应没有对重定向进行索引(例如搜索"LTA:苏俞安"找不到该重定向或是目标页面),所以我们应没必要再对其标记NOINDEX。--Xiplus#Talk 2021年3月31日 (三) 08:55 (UTC)
Google搜索重定向时会显示目标页的内容,即会有一行“(重定向自)”,请见[4],但是不影响伪名字空间。-- 2021年4月5日 (一) 07:29 (UTC)
google:detache出现了一个到https://wiki.kfd.me/_en/?title=Detach%C3%A9&redirect=no的搜索结果。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月11日 (日) 14:31 (UTC)

本章节暂时不存档,直到部署完成。欲让机器人存档,请移除本模板。留言请置于本模板上方。

WP:捷径指引草案修订

[编辑此导航模板]

说明

捷径指引草案的讨论,源自于“伪名字空间”的讨论,英语维基百科对于捷径相关的规范及伪名字空间的设立已有成熟的执行方式。中文维基百科中的部分编辑者对于“格式手册”、“长期破坏者”及“专题”这三个主题提出可升级成名字空间或以伪名字空间形式存在,并有正反两方的陈述与看法。

目前较为接近共识的是“专题”提升为正式名字空间,反对者的论述已由支持者回应,且反方无进一步论述。然为求慎重,且将捷径与名字空间等议题作系统性讨论,将会执行阶段修订,以取得最大共识。

本讨论的各阶段分为:

  1. 专题提升为名字空间与否及其细节phab:T271612);
  2. 格式手册及长期破坏者是否成为名字空间或伪名字空间
  3. 伪名字空间规范写入捷径规范内(如前项通过)或是否允许伪名字空间(如前项不通过)
  4. 捷径规范细部讨论并决定是否成为指引。

各阶段不得同时讨论,前一项讨论完结之后,才能进行下一段讨论。台湾杉在此发言 (会客室) 2020年12月10日 (四) 05:47 (UTC)

专题名字空间通过,剩余细节独立讨论。台湾杉在此发言 (会客室) 2021年1月11日 (一) 11:20 (UTC)
伪名字空间和专题空间都设立了。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年3月3日 (三) 05:21 (UTC)

专题名字空间问题

格式手册及长期破坏者名字空间问题

已通过:
已通过,并完成主要设置。-- 五岁抬☎️·☘️) 2021年3月24日 (三) 05:55 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

已移动至伪名字空间台湾杉在此发言 (会客室) 2021年2月1日 (一) 03:47 (UTC)


完成:设置完毕,有问题请在此提出。-- 五岁抬☎️·☘️) 2021年3月24日 (三) 05:55 (UTC)

本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

捷径细部修订

本案进入倒数第二个部分,捷径细节修订。目前伪名字空间部分已成为指引,其余部分仍须修订。

在上次讨论当中,有提及中文捷径等相关问题,欢迎进一步讨论。台湾杉在此发言 (会客室) 2021年1月31日 (日) 07:42 (UTC)

首段建议附加维基专题空间,他们会稍后设立捷径。--LuciferianThomas留言 2021年2月6日 (六) 04:03 (UTC)
(:)回应Wikipedia:互助客栈/方针#第五阶段:讨论重定向与捷径的设立方式讨论已开始。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月14日 (日) 09:51 (UTC)
@Taiwania Justo?--LuciferianThomas留言 2021年2月21日 (日) 00:13 (UTC)
目前在忙着RFC以及其他现实生活事务,且目前还有残余议案等待处理,待完全告一段落后再行整理该案。--台湾杉在此发言 (会客室) 2021年2月21日 (日) 03:46 (UTC)
不急,因为#第五阶段:讨论重定向与捷径的设立方式也还在讨论。-- 五岁抬☎️·☘️) 2021年3月17日 (三) 06:43 (UTC)
上述第五阶段将会在适当的时机公示。-- 五岁抬☎️·☘️) 2021年3月31日 (三) 06:50 (UTC)

有关某年代相关分类命名统一事宜

最近Jarodalien对某年代相关分类进行了大规模的重新命名工作(将“XXXX年代”重新命名为“YY世纪YY年代”、将“创建”重新命名为“创立”),并声称其理由为“先到先得”,然而“先到先得”并不适用于非条目页面。我曾就部分分类的拟议重新命名(移动请求)进行反对,然而被其无视,其不但无视反对意见照样进行移动操作,更反过来诬指我取消重新命名的操作为“破坏”,更牵连到其他本与相关移动请求不相关的分类。在其进行大规模的重新命名工作后,我收到部分用户反映其重新命名工作导致部分由模板自动产生的分类出错,可见其大规模的重新命名工作轻率且窒碍模板维护,构成破坏。请管理员尽快回退其移动操作,并以一切可行的办法阻止其继续进行相关破坏性移动。SANMOSA 誓山海而长在,似日月而无休 2021年2月25日 (四) 10:54 (UTC)

@ATSANMOSA 誓山海而长在,似日月而无休 2021年2月25日 (四) 10:54 (UTC)
@IoksengSANMOSA 誓山海而长在,似日月而无休 2021年2月25日 (四) 10:56 (UTC)
我建议通报至管理员布告版。--AT 2021年2月25日 (四) 10:58 (UTC)
@ATWP:AIV提报过了,但当时我未收到部分用户对于其重新命名工作导致部分由模板自动产生的分类出错的反映。我觉得至少也得把他做的移动操作全数回退,这比较急。SANMOSA 誓山海而长在,似日月而无休 2021年2月25日 (四) 11:00 (UTC)
@Jarodalien:请参与讨论,不然我会考虑禁制您编辑分类空间。谢谢。--AT 2021年2月25日 (四) 11:15 (UTC)
正在回退一部分他移动过的分类,但数量有点多,我移不完。SANMOSA 誓山海而长在,似日月而无休 2021年2月25日 (四) 12:16 (UTC)
?什么意思?是说只允许别的用户把本来是叫“XX世纪XX年代”的分类移动成“XXXX年代”,不允许反过来吗?就像Category:1910年代美国罪案本来是20世纪10年代美国罪案等等。既然先到先得不适用分类,那么为什么不能够移动?为什么“埃及定居地‎”不对只能移动到“埃及聚居地”,“非洲各国定居点‎”不行要移动到繁体的“非洲各国聚居地‎”?--7留言) 2021年2月25日 (四) 12:48 (UTC)
你还记得你上次不允许将“获奖名单”、“获奖列表”等分类移动到“获奖与提名列表”吗?你都会说没事不要移动了,现在突然搞这些是有事吗? --无心*插柳*柳橙汁 2021年2月25日 (四) 13:01 (UTC)
注意翻历史纪录,不只是我的纪录。我一向的主张是先到先得,是楼主说分类不先到先得。以此为由把Category:20世纪10年代美国罪案移动到Category:1910年代美国罪案。我也想确认是不是真的“分类不先到先得”,我个人是觉得很不可思议,因为这就意味着什么谁都明白。--7留言) 2021年2月25日 (四) 13:13 (UTC)
命名常规只规范条目、不规范分类,自然不适用“先到先得”,不要把你自己当成方针。分类的命名看的是更宏观的其他东西。SANMOSA 誓山海而长在,似日月而无休 2021年2月25日 (四) 15:42 (UTC)
不允许反过来吗。前后极其相似或许先到先得(因为没必要改、WP:OWN),改变命名方式已经不只是先到先得的范畴了。--YFdyh000留言) 2021年2月25日 (四) 16:04 (UTC)
  • 根据民智,19世纪50年代可能会被误认为是1950年代,这类移动没有必要。不过有些词,比如创建出版物,成立音乐团体,创建教育机构,不说合不合适,至少是不是可以讨论讨论拿个统一的方案。->>Vocal&Guitar->>留言 2021年2月25日 (四) 13:11 (UTC)
如果有人觉得“19世纪50年代”是“1950年代”,这个人一定不懂汉语。懂汉语的人不需要考虑不懂汉语的人会有什么误解。--7留言) 2021年2月25日 (四) 13:13 (UTC)
我有印象先前有类似的讨论,当时的意见好像是“1950年代”这样的表述比较省,不过我没记得是哪年在哪的讨论。既然音乐条目都开了命名讨论,关于是否统一年代表示,再开一个讨论又不会怎么样。 --无心*插柳*柳橙汁 2021年2月25日 (四) 14:48 (UTC)
这个讨论是Wikipedia:命名常规/有关“20世纪80年代”的写法的问题绀野梦人 恭贺新春 2021年2月25日 (四) 16:25 (UTC)
我不同意“这个人一定不懂汉语”的论断,一时看得较快看错了所导致的误认是非常正常的事情。就此例而言,这是前述情况最为经典的例子。SANMOSA 誓山海而长在,似日月而无休 2021年2月25日 (四) 15:42 (UTC)
这是认知不广泛的“常识”(就像公元1年到公元前1年之间有几年,不一定有过半数人答对),有更清楚且简洁表达的情况下不应该改成更模糊、更容易出错的。--YFdyh000留言) 2021年2月25日 (四) 16:00 (UTC)
@YFdyh000:所以说答案是空集,还是元素为“0年”的单元素集合?⋯⋯--洛普利宁 2021年2月26日 (五) 15:46 (UTC)
这不重要吧……我指看似常识的东西很多人并不清楚,如有没有公元0年,世纪怎么算,年代又怎么算。相比可能模糊但容易猜对的xxxx年代,双重模糊的xx世纪xx年代更难判断。--YFdyh000留言) 2021年2月26日 (五) 16:01 (UTC)
@Jarodalien:无论如何,你进行的重新命名工作导致部分由模板自动产生的分类出错这一点是无庸置疑的,我认为你应该将先前所创建和重新命名的分类(包括但不限于某年代相关分类,我认为其他相关分类很可能也有同样情形)全部统一回模板自动产生的格式,否则这无庸置疑会严重影响模板维护工作。SANMOSA 誓山海而长在,似日月而无休 2021年2月25日 (四) 15:42 (UTC)
为免后患,我建议就各类页面(包括但不限于分类页)引入“命名一致性”的规定,以有效减少页面命名上的纷争,并便利维护。SANMOSA 誓山海而长在,似日月而无休 2021年2月25日 (四) 15:56 (UTC)
支持这个提议,而且可以把“年代分类”当作首要讨论对象,未来可以扩及其他分类原则。我支持“1950年代”这个写法,理由如下:
  1. 此次讨论显示“19世纪50年代”这个用法确实容易导致误判。
  2. “1950年代”写法较为简洁。
  3. 分类与主条目名称统一对读者来说最为便利,按照年代列表目前所有年代主条目都是采取“1950年代”这个写法。
  4. User:Sanmosa在上方已提及的分类维护问题。--回廊彼端留言) 2021年3月6日 (六) 03:10 (UTC)
  • “19世纪50年代”不是相等于“1950年代”吗。--Temp3600留言) 2021年2月26日 (五) 13:29 (UTC)
认真?“19世纪50年代”相等于“1850年代”,“20世纪50年代”才相等于“1950年代”。-游蛇脱壳/克劳 2021年2月26日 (五) 14:16 (UTC)
@Temp3600:想一下2000年是几世纪,称多少年代。以及Category:2000年代怎么整。--YFdyh000留言) 2021年2月26日 (五) 14:20 (UTC)
似乎2000年是20世纪90年代(1991至2000年)的最后一年,以及2000年代(2000至2009年)的第一年⋯⋯像1世纪是1至100年,21世纪是2001年至2100年;而X世纪00年代是这个世纪的第一个十年。所以21世纪00年代是2001年至2010年,和2000年代严格来说还不是一个东西?PS:“21世纪00年代”和“21世纪10年代”怎么读?“二十一世纪零十年代”“二十一世纪一十年代”?--洛普利宁 2021年2月26日 (五) 15:10 (UTC)
这,尴尬了,我记成21世纪了Facepalm3.svg 捂脸--YFdyh000留言) 2021年2月26日 (五) 15:24 (UTC)
读作零零年代、一零年代,就像九零后、零零后。--YFdyh000留言) 2021年2月26日 (五) 16:01 (UTC)
①“20世纪50年代”=“1950年代”=“1950年到1959年”,这应该比较没有争议;②但如您所举例,遇到100的倍数就麻烦了;③“20世纪50年代”、“21世纪00年代”、“21世纪10年代”我会分别读“二十世纪五零年代”、“二十一世纪零零年代”、“二十一世纪一零年代”,至于别人怎么读,我就不知道了。-游蛇脱壳/克劳 2021年2月26日 (五) 16:15 (UTC)
00和10以外的年代,我大概会读作“__十年代”,读法上没问题。--YFdyh000留言) 2021年2月26日 (五) 21:01 (UTC)
@@YFdyh000:说到年代的是,请教大家一个问题,最近我都不太用维基百科了,今天我在找资料时发现有条目里面原有年代的部分被删除了,查了查是有编辑者删除了,可能他认为那是考古专家学者考据的年代,不是当时人写下的年代,譬如,古埃及第三xxx王朝约公元前xxx年-公元前xxx年,所以编辑者把年代删除在内容改成不知道,现在可以这样吗?><?我怕搞不清楚状况所以问问。--User:浪子鱼|爱偷懒的鱼🐠※User talk:浪子鱼|留言 2021年2月26日 (五) 16:43 (UTC) ──以上未签名的留言由浪子鱼讨论贡献)加入。
@浪子魚:不太清楚您的意思,是条目内容还是分类,年代与条目主题的关系。麻烦您将签名加上内部链接,不然别人不方便查阅和回复,您的ping也不会生效。--YFdyh000留言) 2021年2月26日 (五) 21:01 (UTC)
@YFdyh000:好,谢谢你告诉我浪子鱼留言) 2021年3月9日 (二) 07:12 (UTC)

针对性决议

通过:
通过。SANMOSA Σουέζ 2021年3月29日 (一) 09:11 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

我这里的建议是:为便利分类维护,并避免由模板自动产生的分类出错,当将所有以“YY世纪YY年代”格式命名的分类重新命名为“XXXX年代”格式、将所有以“创立”格式命名的分类重新命名为“创建”格式。页面命名一致性的通用(普遍性)条文会稍后草拟,针对性的决议应该先通过。SANMOSA 江南好,风景旧曾谙 2021年3月15日 (一) 08:18 (UTC)
现公示以下针对性决议7日:将所有以“YY世纪YY年代”格式命名的分类重新命名为“XXXX年代”格式、将所有以“创立”格式命名的分类重新命名为“创建”格式。SANMOSA 江南好,风景旧曾谙 2021年3月22日 (一) 10:15 (UTC)
(+)赞成--YFdyh000留言) 2021年3月22日 (一) 11:06 (UTC)
前者同意,以便于维护,减少因格式之混杂不一所造成的分类维护困难;但后者则建议以既有母分类(诸如“各年创建的OOO”等,后续子分类一并以“创建的OOO”为原则)的命名格式为主,倘若尚无母分类者建议以“创建”为主要命名格式。--Steven |_-。) 2021年3月23日 (二) 14:52 (UTC)
两者皆赞成,理由如下:
XXXX年代部分-
  1. 以上讨论显示“19世纪50年代”这个用法容易误判。
  2. “1950年代”写法较为简洁。
  3. 分类与主条目名称统一对读者来说最为便利,按照年代列表目前所有年代主条目都是采取“1950年代”这个写法。
  4. User:Sanmosa在上方已提及的分类维护问题
创建部分-
  1. 以“创立”为名的分类数量明显少于以“创建”为名的分类。--回廊彼端留言) 2021年3月23日 (二) 15:15 (UTC)

本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
@YFdyh000StevenK234迴廊彼端:决议已通过。名为“创立”的分类已经全部处理。以“YY世纪YY年代”格式命名的分类太多,未能全部重新命名,暂时只处理了“19世纪00年代”、“19世纪10年代”、“21世纪10年代”、“21世纪20年代”和整个18世纪,其他可能需要请求bot,或靠各位的帮助自行移动,我会尝试移动一部分。移动理由应使用“Special:diff/64972159决议通过统一命名格式”。SANMOSA Σουέζ 2021年3月29日 (一) 09:28 (UTC)

页面命名一致性的通用(普遍性)条文

暂时不太想得到该怎样写。我可能要再看一看英文维基百科的对应规定,7日内应该能够写好。各位如果有其他的草案提议,也可以直接提。SANMOSA Σουέζ 2021年3月29日 (一) 11:35 (UTC)

本章节暂时不存档。欲让机器人存档,请移除本模板。留言请置于本模板上方。

提议创建“元维基用户查核指南”

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

对象:Wikipedia:删除方针#9
提案:
现行条文

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

提议条文

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

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

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

提议条文

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

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

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

提议条文

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

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

合并后新提案

现行条文

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

提议条文

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

参考资料

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

参考资料

请求第三方管理员参与评估和总结可靠来源讨论


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

本章节暂时不存档,直至问题解决。欲让机器人存档,请移除本模板。留言请置于本模板上方。

关于Wikipedia:命名常规 (音乐)

延续上次Wikipedia talk:命名常规#关于Wikipedia:命名常规#使用外文命名时的专门要求,请问音乐作品名称是否能算是专有名词?的讨论,我写了一篇Wikipedia:命名常规 (音乐)

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

提示:阁下该次ping操作没有一个人会收到,因为您一次性同时ping了超过五十人。--Milky·Defer 2021年3月14日 (日) 20:08 (UTC)
@MilkyDefer:(´_ゝ`)你没提,我都忘了我人数超标了。 --无心*插柳*柳橙汁 2021年3月15日 (一) 06:13 (UTC)
我有ping到人吗?TreasureBabe325Hijk910Jacklamf1d14Ericliu1912NaveradSoftyuSammypanTw dramaShingkei李新阳CHih-See HsiePv163JoJo_appendLopullinenAnYiLinYel D'ohanTemp3600Bigbullfrog1996陈寅恪TenhumantenokPrince of EreborK.Y.K.Z.K.ArivgaoFredYYooApple vTfcheng5597Comrade JohnAdsa562Austin ZhangMoonLight3650GracellleeShwangtianyuan --无心*插柳*柳橙汁 2021年3月15日 (一) 14:05 (UTC)
有ping到。请简单归纳一下你觉得讨论者需要注意的重点。谢谢。-hiJK910 七一七二一 2021年3月15日 (一) 14:10 (UTC)
@Hijk910:注意的重点嘛...,当属于上次关于外文问题所写的“外文规范”,另外我也把上次羊羊32521大的古典音乐内容放入其中。而括号的使用和消歧义,想说借由这次讨论一起解决。 --无心*插柳*柳橙汁 2021年3月15日 (一) 15:11 (UTC)
有。我被ping了两次。—— Eric Liu 创造は生命(留言留名学生会 2021年3月15日 (一) 14:14 (UTC)
(!)意见:1. “够格”一词不够正式。2. 关于““‘(歌曲)’:适用于所有歌曲,通常命名时优先使用”,请问是不是指像炎 (歌曲)这些“(歌曲)”跟“(单曲)”皆可的条目,“必须”还是“建议”以“(歌曲)”为消歧义呢?-hiJK910 七一七二一 2021年3月15日 (一) 14:18 (UTC)
我这个人最没有主见了,关于“(单曲)”,我上次被百战天虫大说服后[5],觉得很有道理。当然,如果是像ARRIVAL OF EVERGLOW这种单曲专辑使用“(单曲)”,我就觉得还行。
但就目前而言,都是歌曲不用“(歌曲)”而使用“(单曲)”到底是为什么?我这边问一下@Ryokie38:,当初创建½ (川本真琴单曲)使用单曲而不像1/2 (川本真琴の曲)日语1/2 (川本真琴の曲)使用歌曲的原因是什么?。 --无心*插柳*柳橙汁 2021年3月15日 (一) 14:46 (UTC)
被Tag两次啦(茶),基本上名称方面没有多大问题。顺带一提,自己也比较倾向于用“(人名歌曲)”或“(人名单曲辑)”或“(人名专辑)”三种来命名...好奇其他人的看法。-by 全速前进~~Yosoro!!~~的Tsuna Lu留言) 2021年3月15日 (一) 16:07 (UTC)
@Adsa562:我赞同人名的部分,直接使用人名可以避免以后移动的麻烦是好事,但如果是像胡萨维克 (歌曲)这种冷门的名称或是像妮裳马戏团 (歌曲)专门到极点的,不用加人名也没问题。 --无心*插柳*柳橙汁 2021年3月15日 (一) 16:27 (UTC)
要跟en:Wikipedia:Naming conventions (music)链接吧,然后可以顺便参考一下,像关于单曲/歌曲的问题,我觉得宜与英维一样“尽量避免使用单曲”(If possible, avoid using other terms like "(single)", "(cassette)" or "(CD single)", etc.)--Austin Zhang留言) 2021年3月15日 (一) 19:53 (UTC)
对于单首发行的歌曲,消歧义时用歌曲没有问题,但是当单曲发行时有附带B面歌曲且该条目也有介绍该B面歌曲(而不是顺带提及)的时候,用单曲消歧义更合适吧。--无所事事/想要狗带 2021年3月16日 (二) 19:05 (UTC)
@Softyu:我也有这么想过,但鉴定不容易。我在下面列出几个,你觉得哪些可以保留其单曲消歧义。 --无心*插柳*柳橙汁 2021年3月17日 (三) 15:49 (UTC)
  1. 四季 (单曲)
  2. Gravity (LUNA SEA单曲)
  3. CLEAR (坂本真绫单曲)
  4. 矛盾心理 (榉坂46单曲)
  5. Lemon (米津玄师单曲)
个人观点来说,保留单曲的程度是2<5=3<1=4,4有不止一首B面曲得到有效介绍,1则是在制作及商业成绩方面皆有充分介绍B面曲,3的介绍相比1单薄,但也算有效,5是仅有一句话的顺带提及,2则是完全没有来源,不过实际操作中,可以考虑对包含B面曲的或所有歌手自身称之为单曲(single)的条目以单曲消歧义,毕竟无论如何也要“名从主人”。
我这边再给几个增加样本数,世界的尽头 (单曲)Yellow (木村KAELA单曲)FACE (NU'EST单曲)MAGIC (SHOW单曲)崖上的波妞 (单曲)Reflection (林原惠单曲)口唇 (GLAY单曲)发夹 (单曲)。“名从主人”方面你说名称那还有道理,但消歧义也如此就...(也不是不行啦,这在命名常规写仔细一点)。 --无心*插柳*柳橙汁 2021年3月17日 (三) 23:56 (UTC)
主要是有D (BIGBANG单曲)H (滨崎步单曲)这种无法以“歌曲”消歧义的条目存在,导致其他单曲类型条目如果以“歌曲”消歧义的话会产生问题,如果把Moments (滨崎步单曲)改成Moments (滨崎步歌曲)肯定会产生争议的吧。--无所事事/想要狗带 2021年3月18日 (四) 06:29 (UTC)
D (BIGBANG单曲)H (滨崎步单曲)这两个使用单曲没有问题(就像我前面提到的ARRIVAL OF EVERGLOW)。我引用星巴克女王大的说法来讲就是“单曲是偏向介绍某张CD,而歌曲是偏向介绍某首歌曲,而我们写的主要与歌曲内容有关,而不是介绍某张单曲CD。” --无心*插柳*柳橙汁 2021年3月19日 (五) 01:19 (UTC)
为什么“我们写的主要与歌曲内容有关,而不是介绍某张单曲CD”??我从来的看法是介绍某张单曲,及其中收录的歌曲。->>Vocal&Guitar->>留言 2021年3月25日 (四) 07:42 (UTC)
单曲与歌曲是明显不同的概念,只要以单曲形式发行的作品,不论是一首歌几首歌,都应称为单曲。对于某些特殊的歌曲,比如我和你 (歌曲)之类,其制作背景不是以发行单曲为目的,或没有发行单曲,此时才合适用歌曲。->>Vocal&Guitar->>留言 2021年3月25日 (四) 07:42 (UTC)
@Ohtashinichiro:当条目只是一首歌的时候,讨论其格式根本没有意义,你只会介绍一首歌,也只有这么一首歌可以介绍,这种情况下没有迫切需要“ (单曲)”做消歧义。再来讨论“筛选条件”,我反对以“制作背景不是以发行单曲为目的”及“没有发行单曲”作优先处理。首先“制作背景不是以发行单曲为目的”要怎么辨别,Say So一开始没打算打单、Eyes on Me以游戏主题曲为目的创作,但这两首最后都打单了。唱片公司的举动是否属于制作背景以发行单曲为目的?
二来,现在这年头,你没有发行公司也能自己发歌。以Spotify为例,只要你加入Spotify的创作项目,哪怕你没有公司也能发歌。但单曲是Spotify的最低计量单位,创作者上传的作品是否等于发行单曲?(例如PewDiePi的歌曲Congratulations (PewDiePie、Roomie和Boyinaband歌曲))。 --无心*插柳*柳橙汁 2021年3月25日 (四) 11:51 (UTC)
如果您只介绍歌曲的背景、词曲、意涵、影响,我觉得您使用歌曲没有问题。但您也会介绍这首歌作为单曲发行的信息比如日期地区形式唱片公司,以及作为单曲发行后的反应比如销量评价奖项,这些都属于单曲而不是歌曲的范围。至于您的举例都是完完全全的商业作品,商业作品当然都是以发行为目的且结果也都是已发行,我前面的表述可能会引起您的误解,也希望您可以研究一下您的举例和《我和你 (歌曲)》的区别在哪,能有一个合适的表述。另外spotify好像已经结束了自行发歌[6]。->>Vocal&Guitar->>留言 2021年3月26日 (五) 00:19 (UTC)
@Ohtashinichiro:spotify结束自行发歌不等于整个项目没有发生过,对于以前参与项目的歌该算?而Ohtashinichiro大你给出的这些条件,歌曲一样可以使用,《家 (陈洁仪歌曲)》难道有出单曲他就活该倒楣只能是商业作品。我不能理解你一直提《我和你 (歌曲)》是想表达什么,他们都是歌曲。不论有没有出单曲、派台还是其他单曲形式,歌曲就是该用歌曲,没有必要过度分类。 --无心*插柳*柳橙汁 2021年3月26日 (五) 04:20 (UTC)
单曲是“一碗饭”,歌曲是“碗里的饭”,您可能只想吃饭,我希望不要忽略这只碗。只是看起来您对这一点并不认同,那其他的讨论也没有意义了。->>Vocal&Guitar->>留言 2021年3月26日 (五) 05:01 (UTC)
很抱歉,我不能理解只在乎容器,而忽视它终究是饭的事实。关于单曲与歌曲的问题就看其他维基人的意思,再来评断。 --无心*插柳*柳橙汁 2021年3月26日 (五) 05:44 (UTC)
  • "上次讨论"的链接失效了。--Temp3600留言) 2021年3月17日 (三) 17:55 (UTC)
Temp3600"上次讨论"的链接以补充。 --无心*插柳*柳橙汁 2021年3月17日 (三) 23:56 (UTC)

Wikipedia:命名常规 (音乐)1.0更新报告

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

  1. “古典音乐作品”叙述修正
  2. “使用中文”内容增加
  3. “外文规范”内容增加
  4. “括号的使用”修改为“符号使用”,并增加“斜线”、“书名号”和“特殊符号”的说明与示例。
  5. “消歧义”内容增加
  6. “注释”叙述修正
ShingkeiHikki李新阳CHih-See HsiePv163JoJo_appendLopullinenAnYiLinYel D'ohanTemp3600Bigbullfrog1996陈寅恪TenhumantenokPrince of EreborK.Y.K.Z.K.ArivgaoFredYYooApple vTfcheng5597Comrade JohnAdsa562Austin ZhangGracellleeShwangtianyuan星巴克女王金善贤老奋Lilychen1388Drippinpunch由于人数众多,这边分开ping相关讨论用户。 --无心*插柳*柳橙汁 2021年3月25日 (四) 05:42 (UTC)
  • 我本来就对“古典音乐作品”第一行“对序号是10(不含)以上的作品,‘号’字省略”有点疑虑,这样分类讨论,不利于条目名的统一性。[1]希望能交付社群讨论。另ping一下之前参与过相关讨论的@FoampositeIoksengAnakharsis: ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月25日 (四) 06:05 (UTC)
  • 我认为日文罗马化可能需要详细规定,例如shi或si到底要使用何者,《日语罗马字》中有写到三种罗马化方式,看是要采用哪一种。 2021年3月25日 (四) 10:24 (UTC)
    我建议如果官方没有给出罗马字的话,全部统一用平文式罗马字。SANMOSA 江南好,风景旧曾谙 2021年3月25日 (四) 10:27 (UTC)
    我也是这样认为。 2021年3月25日 (四) 10:48 (UTC)
    @Pseudo ClassesSanmosa:以新增。 --无心*插柳*柳橙汁 2021年3月25日 (四) 11:05 (UTC)
@Milkypine:“对序号是10(不含)以上的作品,‘号’字省略”是此类音乐作品的常用名称的做法吗?SANMOSA 江南好,风景旧曾谙 2021年3月26日 (五) 09:57 (UTC)
@Sanmosa:古典音乐的部分主要根据User:Anakharsis/沙盒#创建条目编写,至于是否为此类音乐作品的常用名称做法...这部分需要古典音乐的编辑来回答(技术上来讲我会写原声带但不等于我熟悉古典音乐)。 --无心*插柳*柳橙汁 2021年3月26日 (五) 12:41 (UTC)
@Milkypine:我看了一下应该是对现行做法的总结。然而,我也看过了来源一下,似乎即使号码大过10,加“号”字还是比较常见。我建议基于常用名称的原则,将‘序号使用阿拉伯数字,前面有“第”字;作曲家名字放在半角括号内,括号之前有一个半角空格。对序号是10(不含)以上的作品,“号”字省略’的规则改为‘序号使用阿拉伯数字,前面有“第”字,后面有“号”字;作曲家名字放在半角括号内,括号之前有一个半角空格’。SANMOSA 江南好,风景旧曾谙 2021年3月27日 (六) 05:28 (UTC)
有关“号”的问题,综观惯常一般音乐会场刊的处理,通常都没有特意加上“号”的,但本人自最初编写肖斯塔科维奇交响曲时,经观察和有前人提醒过名称上要加上“号”,所以才不论第1还是第15都有加上“号”,且也觉得没有问题,至于“超过10就不用加号”的说法,倒没有听过,不过User:Sanmosa建议不论序号,统一采用“第X号○○○ (某某)”的写法,个人表示认同和支持。-Foamposite留言) 2021年3月27日 (六) 07:40 (UTC)
@IoksengAnakharsis:两位的看法如何? --无心*插柳*柳橙汁 2021年3月28日 (日) 03:29 (UTC)
  • 我不知道现在还可不可以为这个讨论作出贡献。我主要编辑古典音乐这方面,所以以下是我对于该方面的浅见:
1)我注意到大家关于“号”的讨论,我赞成“第”后面加“号”,不需要去管超过10什么的。我注意到很多的条目中超过10的也使用“号”,如:第11号钢琴奏鸣曲 (莫札特)第12号交响曲 (肖斯塔科维奇)第40号交响曲 (莫扎特)等。我不太懂为啥非要减少一个“号”。
2)哦,对了,维基百科:命名常规 (音乐)这里的降E大调弦乐五重奏(贝多芬作品)的括号好像用成了中文的()而非(),我觉得咱们可以着重的说一下我们的括号问题用的是英文的那种,我认为新手会喜欢犯这样的错误(比如我,哈哈哈哈)
3)关于调性的问题,我认为我们还应当注意对于音名和字母大小写的统一,如我们真的要写“降E大调弦乐五重奏 (贝多芬)”,我们需要着重指出到底是用“降E”还是“E♭ ”;亦或是“降e”还是“降E”。探讨这个问题很重要,因为在很多命名下面的条目内容出现不一致的情况,比如第3号交响曲 (贝多芬)中我们说“E♭大调第3号交响曲”,但是在第39号交响曲 (莫扎特)中,我们又说降E大调第39号交响曲。我的建议是我们应当使用“大写字母”以及“降”或“升”。
4)关于维基百科:命名常规 (音乐)这个地方的“如果该作品的名称是独一无二的,则作曲家名字也可以省略”,这个可能会有点争议,比如其中说到的大地之歌,这玩意儿可能指的是大地之歌 (电影)。我不是在这里杠呀,我是说类似这样的东西需要注意是否已经有不一样的体裁同样名字的东西已在维基百科中出现,比如查拉图斯特拉如是说库勒沃,咱们需要加上查拉图斯特拉如是说 (斯特劳斯)库勒沃 (西贝柳斯);乃至于有些时候同属于音乐类的《传奇》,是西贝柳斯?还是维尼亚夫斯基?当然,我认为这个可以直接套用“作品在体裁内的序号+作品体裁+作...”的方式,只是需要稍加说明。我的建议是说明如果维基百科里已经有不同体裁但相同名字的条目则在新条目创建时的括号内加上作曲家名字,如果没有就无所谓了(自己看着办吧)。
5)注意到我们在古典音乐类编辑中有惯例但无有实质的关于“命名优先性”的规定(或者因为我是个新手没有注意到,哈~),我以我指的“优先性”举一个例子,我们是应该叫第6号交响曲 (柴可夫斯基)还是悲怆交响曲。我知道大家都很聪明,而且我个人感觉我们的惯例通常是用体裁加序号再加作曲家的方式,但是我认为需要在维基百科:命名常规 (音乐)对命名的优先性中做具体的说明,要不然!!!就会像某度那样出现憨憨的“悲怆交响曲”和“柴可夫斯基第六交响曲”那样的重复词条,我笑死了哈哈哈哈哈。

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

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

Wikipedia:命名常规 (音乐)2.0更新报告

Ohtashinichiro和平至上LeehsiaoSanmosaTombus20032000百战天虫Kriz Ju生米一粒Pseudo ClassesKodokunaSmileEasterliesAT卡达YumetoSickManWP羊羊32521EdwardAlexanderCrowleyZhaoweizhi0325MoonLight3650HXXXXPunkhippieLouis0921geePeace 621WhykittyMoonshimmer93夜来南风起Fake12345TreasureBabe325Hijk910Jacklamf1d14Ericliu1912NaveradSoftyuSammypanTw drama感谢大家的意见回馈,这次根据上次1.0的讨论修改古典音乐,并增加“ (单曲专辑)”的消歧义。欢迎大家查阅。 --Loving You Is A Losing Game 2021年4月10日 (六) 07:04 (UTC)

ShingkeiHikki李新阳CHih-See HsiePv163JoJo_appendLopullinenAnYiLinYel D'ohanTemp3600Bigbullfrog1996陈寅恪TenhumantenokPrince of EreborK.Y.K.Z.K.ArivgaoFredYYooApple vTfcheng5597Comrade JohnAdsa562Austin ZhangGracellleeShwangtianyuan星巴克女王金善贤老奋Lilychen1388DrippinpunchKulivLienwingyan由于人数众多,这边分开ping相关讨论用户。 --Loving You Is A Losing Game 2021年4月10日 (六) 07:06 (UTC)
括号一节举的例子不是有全形字元(中文字)吗?如果我没理解错误的话,不应该是要用全形括号? 2021年4月10日 (六) 07:20 (UTC)
@Pseudo Classes:你的意思是说“中文是全形字元”吗?如果不是的话,习惯 (超快感)姐姐 你太美了 (Replay)这两个例子都没有全形字。 --Loving You Is A Losing Game 2021年4月10日 (六) 07:26 (UTC)
@Milkypine:是的,中文字理应也属于全形字元,这样写会有歧义。 2021年4月10日 (六) 07:31 (UTC)
斜线一节也有这个问题。-- 2021年4月10日 (六) 07:34 (UTC)
@Pseudo Classes:已修改为“全形符号”避免歧义。 --Loving You Is A Losing Game 2021年4月10日 (六) 08:01 (UTC)
@Milkypine:感谢修正,另外我想请问关于斜线和括号有相关的共识吗?不然我想再针对这个问题讨论一次。 2021年4月10日 (六) 15:18 (UTC)
@Pseudo Classes姑且算吧,就算当初没有共识,现在也可以有,我就不信我ping了快百位编辑没人没感觉。 --Loving You Is A Losing Game
已查阅,感谢贡献。--SickManWP欢迎参与♥️边缘人小组的活动·✏签到发表于 2021年4月10日 (六) 08:25 (UTC)
  • 条目名称须符合“大调大写,小调小写”,如“D大调”、“d小调”。

或是

  • 条目名称须符合“大调大写,小调小写”,如“D大调”、“d小调”。

例:降B大调升f小调

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

@羊羊32521:页面第一个字虽然必须大写,但d小调和iPhone一样,都在其(乐理)领域属于特定词语,因此使用小血没有问题。 --Loving You Is A Losing Game 2021年4月10日 (六) 16:50 (UTC)
好 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月11日 (日) 02:26 (UTC)

参考资料

(重提)Wikipedia:共识#提案讨论及公示时间的执行力度

最近客栈的提案实在是不胜Wikipedia:共识#提案讨论及公示时间的困扰,但不太想尽废,因此提一个修正案:

现行条文

为了确保所有用户有充足的时间发表意见以及得悉改动,如果在互助客栈中被提出的提案在七天内没有新留言或至少讨论达一个月以上的情况下,只要取得共识便可公示,为期七天。公示期间若无异议,则提案算作通过;如果有新意见,请通过协商解决问题。存档后如果要重新提出公示的话,应同时补回相关讨论链接,以便社群查阅。

提议条文

为确保所有用户有充足的时间发表意见及得悉改动,在互助客栈中被提出的提案若在7日内无新留言[1],又或讨论已持续28日以上的情况下,只要讨论取得共识,即可公示,公示为期至少7日。公示期间若无合理异议,作通过论,若有新合理意见,应经协商解决问题。

参考资料

以上。SANMOSA 江南好,风景旧曾谙 2021年3月14日 (日) 15:31 (UTC)

主要影响:
  1. 不对提案进行实则性点评的支持意见不造成重算7日。
  2. 与提案本身无关的意见不造成重算7日。
  3. 将浮动的时间范围“1个月”界定为固定的时间范围“28日”。
  4. 容许公示在有必要时可长于7日。
以上。SANMOSA 江南好,风景旧曾谙 2021年3月14日 (日) 15:36 (UTC)
(?)疑问
  1. 原条文有“如果在互助客栈中被提出的提案”一句,在新条文要删去吗?
  2. 参阅Wikipedia:互助客栈/条目探讨#春晚及春晚 (消歧义),这种在Wikipedia:互助客栈/条目探讨的提案是否需要遵守WP:7DAYS?或是要将WP:7DAYS限定在Wikipedia:互助客栈/方针?--CaryCheng留言) 2021年3月15日 (一) 02:41 (UTC)
@CaryCheng:(1)漏留意,已补回。(2)理论上要遵从。SANMOSA 江南好,风景旧曾谙 2021年3月15日 (一) 05:53 (UTC)
@CaryCheng:就(2)作补充:我是说如果决定要进行公示的话,理论上要遵从WP:7DAYS,但是如果不涉及修改方针指引或修改高风险模板的话,一般性的争议解决讨论好像是不用进行公示的,基本上争议解决了就可以直接关。SANMOSA 江南好,风景旧曾谙 2021年3月15日 (一) 08:45 (UTC)
(?)疑问:这个提案改过很多次,而且30天和28天就差两天,有必要改来改去吗?而且一年就只有二月会有28天,大家都会以30天为一个月的概念,这种修改有什么意义呢?--虫虫飞♡♡→♡℃留言 2021年3月15日 (一) 03:52 (UTC)
1年有7个月是31日,何来“以30天为一个月的概念”?再者,1年12个月的日数不同,假设我在2月1日提案,我最迟可以在28日后公示,但假设我在3月1日提案,我最迟在31日后才能公示(4月同理,最迟在30日后才能公示),这对于在有30日/31日的月份提案的人非常不公平,但如果统一为30日,这会损害在2月提案者的公平性,因为30日的时间必定比2月长,这样在2月提案的人就会要在多于一个月的时间后才能公示。因此,最公平的方式为统一成28日。SANMOSA 江南好,风景旧曾谙 2021年3月15日 (一) 05:53 (UTC)
(?)疑问:大致同意,而且也会看到这里用雪球快速公示,好像也没完全照规定走。但是这里有些疑问要问一下,如何界定“已取得共识”、“合理异议”,“合理意见”?合理异议、意见会不会变成两集团互斥对方不合理。只有一人提问,无人赞成、反对,算不算已取得共识,然后可以公示?这些提案人可以一并考虑,把规定写更好一些。--2001:B042:1:A9ED:F58C:12D4:4C7B:B776留言) 2021年3月15日 (一) 06:32 (UTC)
(1)没人抓的话其实是没人会遵守这规定。(2)以前的人进行公示的时候都是说“现公示7日,无合理异议者即作通过”,跟以前的做法处理。(3)提案与现行办法对于“只有一人提问,无人赞成、反对”的提案的态度是原则上可以公示,这当然会产生一些奇怪的现象(当然如果提案人能够好好处理提问的话,我倒是觉得可以照样公示通过),先前讨论也谈论过,但没人管。SANMOSA 江南好,风景旧曾谙 2021年3月15日 (一) 07:54 (UTC)
回答的很完整。不缩小“无新留言”范围,结果时间等太久,没人抓大家就不走规定。不讨论“已达成共识”定义,结果“一人提问,无人赞成、反对”,反而7日后就可以公示。这是不见得会有问题,但又有一些奇特的现象。--2001:B042:1:ABD5:F58C:12D4:4C7B:B776留言) 2021年3月15日 (一) 08:27 (UTC)
所以有时候我会抓一下7日的计算(虽然我自己也不满现在这规定)。如果“只有一人提问,无人赞成、反对”的提案出现的话,提案人能不能够好好处理提问是一个重点,如果不能的话,理论上可以抓“已取得共识”一条来说有程序性问题。SANMOSA 江南好,风景旧曾谙 2021年3月15日 (一) 08:42 (UTC)
(-)反对:重看了一下,注脚很有问题,而且只会增加争议,应删去。--虫虫飞♡♡→♡℃留言 2021年3月15日 (一) 06:41 (UTC)
不同意。这是修订提案的主要目的之一。之前的讨论的主流意见都认同不应该使所有意见都能导致重算7日(我个人比较看重的是DrizzleD的意见)。我邀请一下之前参与过讨论的@KirkLUDrizzleDBureibuNekoUjuiUjuMandanFire-and-Ice来好了。SANMOSA 江南好,风景旧曾谙 2021年3月15日 (一) 07:49 (UTC)
不是说增加争议就不好。举个简单例子,根据中华人民共和国刑法,故意杀人的,处死刑、无期徒刑或者十年以上有期徒刑;情节较轻的,处三年以上十年以下有期徒刑,显然在不少案件中具体判罚轻重会有“争议”,但为什么不干脆故意杀人的都处死刑呢?因为不同的案件真的不一样,不能统一判罚。这里类似,单纯支持也好,给建议也好,反对也好,无关意见也好,对共识形成的作用完全不同,却都能导致重算7日,这就背离了WP:7DAYS帮助确认共识的初衷。--DrizzleD (按此给我留言) 2021年3月15日 (一) 09:41 (UTC)
  • (+)支持:这四点都没什么问题。关于第一点,先前讨论中已有不少论据,不再赘述(但愿)。简而言之,在没有其他意见的情况下,支持的人越多,提案越晚被公示,这是说不通的。--DrizzleD (按此给我留言) 2021年3月15日 (一) 09:46 (UTC)
(?)异议:您误解了WP:7DAYS的初衷,当时AT就是为了解决在讨论不足的情况下,用户火速公示,然后强行通过提案的问题。原先是要30天后才公示,后来才七天后没有留言公示。七天算是合理时间,没必要再缩短,否则又会回到以前火速公示,强行通过提案的问题,然后争议不断,问题多多。而且现在WP:7DAYS未见有什么问题,没必要再放寛。--虫虫飞♡♡→♡℃留言 2021年3月15日 (一) 13:12 (UTC)
不不不,是您误解了我的意思,我说它帮助确认共识,意思是它告诉我们什么时候算是确认了共识,不是说它帮助加速通过提案。然后:1. 七天算是合理时间,没必要再缩短,我同意,但这个修正案完全没说要缩短七天这个时间,此说法和此修正案不相关 不相关。2. 又会回到以前火速公示,强行通过提案的问题,当然不,留言支持者越多,说明通过提案越不强行,而不是相反。 3. 而且现在WP:7DAYS未见有什么问题,这个我现在不太活跃确实不太清楚,但Sanmosa似乎能够确认如此,@Sanmosa可以来说说。--DrizzleD (按此给我留言) 2021年3月15日 (一) 13:47 (UTC)
(3)现成的问题SANMOSA 江南好,风景旧曾谙 2021年3月16日 (二) 05:53 (UTC)
(※)注意:请看一下这个提案,有一大堆支持,也已经讨论了一个月,还是有人反对,当时也有人催快点公示,也有朋友对说我要快公示,怕夜长梦多,会出现(-)反对,但提案的目的是要寻求共识,而不是快快通过,然后出现争议,因此急于通过是不必要的,有共识的提案也不怕多放几天。--虫虫飞♡♡→♡℃留言 2021年3月16日 (二) 06:13 (UTC)
你对互助客栈讨论的想法完全违背进行互助客栈讨论应有的健康心态。SANMOSA 江南好,风景旧曾谙 2021年3月16日 (二) 06:58 (UTC)
@蟲蟲飛:不吸烟也可能患肺癌,这不代表我们不用去倡导戒烟,关键是可能性。类似地,同样是暂时没有反对意见,一个有许多人支持的提案和一个没人理的提案,哪一个有潜在问题的可能性更大?这是不言自明的。
要解决所谓“已经讨论了一个月,还是有人反对”的问题,相关的方案是延长WP:7DAYS中7天或者是1个月的限制(当然可能会有一些别的问题),但这与本案无关。本案的要求是赞成或不相关的意见不影响时间(不管是7天还是什么其他时间)的重算。--DrizzleD (按此给我留言) 2021年3月17日 (三) 02:13 (UTC)
  • 提案讨论就不应存在不相关的意见,而且有时什么如何定义“不相关”也有争议,因此我觉得AT现行版本较佳,没必要改为一个具争议性的版本。--虫虫飞♡♡→♡℃留言 2021年3月17日 (三) 02:40 (UTC)
然而方针指引不能阻止任何用户发表不相关的意见。SANMOSA 江南好,风景旧曾谙 2021年3月17日 (三) 05:43 (UTC)
如何定义“不相关”?谁去决定?双方也可以互相指责对方的留言“不相关”,为什么要令提案增加不必要的争议?AT现行版本是最好的,“七天没留言”是客观标准,没有争议空间。--虫虫飞♡♡→♡℃留言 2021年3月17日 (三) 12:12 (UTC)
(1)依据“共识应当考虑到所有正当合理的意见”此条方针来定义。(2)最极端的情况就找行政员,天仍然不会因此塌下来。(3)极端严格的“7天没留言”是客观标准没错,然而违反常识、惯性、正常讨论生态和“共识应当考虑到所有正当合理的意见”此条方针。SANMOSA 江南好,风景旧曾谙 2021年3月17日 (三) 12:43 (UTC)
所以,这种提案还是,被改完的7days拦下吧?-- Sunny00217  2021年3月22日 (一) 16:25 (UTC)
从现存留言上来看,应该会,因为相邻两条有说理的评论之间均小于7天。当然,改了WP:7Days之后同时可能会促使反对的人更早留言,这就是另一回事了。--DrizzleD (按此给我留言) 2021年3月28日 (日) 06:27 (UTC)
@Sunny00217SANMOSA 江南好,风景旧曾谙 2021年3月16日 (二) 05:56 (UTC)
(-)反对:啥叫合理,啥叫不合理?谁有权判定?个中操作空间太大,不得不反对。芄兰留言) 2021年3月15日 (一) 13:22 (UTC)
啥叫曾在可靠来源中发表过的重要观点,啥叫不重要?谁有权判定?
啥叫恰当地改进或维护维基百科,啥叫不恰当?谁有权判定?
我们能收录可靠来源中的所有观点吗?我们能废除WP:5P5去墨守成规吗?不能。这种操作空间不是洪水猛兽,它是必要的,也是维基百科时时刻刻都在使用的东西
当然,要是操作规范能写得更细、更准确,那更好,就像WP:WEIGHT较详细叙述了第一个问题。可假设还没人去写WP:WEIGHT的时候,我们订立原则的时候同样应该加上“重要”两个字,因为这就是应该的,而不是去害怕什么“操作空间”。--DrizzleD (按此给我留言) 2021年3月15日 (一) 14:14 (UTC)
提案人有邀请讨论,我稍微简单说一下自己的浅见:
  1. 类似于“最后一天有编辑补了个‘支持’,结果导致要重新计算公示前的无留言时间”的情况客观存在;
  2. 个人是支持上例的这种问题能够更灵活化的处理(毕竟,表达一下支持,甚或——更宽泛一点——由于方针通过、问题解决的喜悦在讨论串下面开了个适当的玩笑,都不是什么不合理的事情;让这种表达起到延长公示前时间的效果,并非方针的本意,也一定程度上压抑了这种合理表达的机会——毕竟既然赞成提案,谁也不希望自己表达的支持反而造成了拖延的反效果);
  3. 我能理解反对此种灵活化处理的编辑有种种疑虑,此种情况下不改变现有方针我觉得也是可以理解、认同;
  4. 但即使方针不变,只要翻看存档,就会发现此种灵活化处理在往例中比比皆是,在这些案例中大家某种程度上用一种“默示共识(或称沉默共识,或称通过不提出异议来支持)”的方式使得灵活化缩短时程得以实现;
  5. 也因此,如3,方针改不改在我看来也许真的问题不大(如果大家真的不期待太明确地以规则确认上述惯例,或至少有些编辑还对此存在很大疑虑,如3,我个人觉得也是能一定程度理解),只是希望即使不改方针,至少这种实践中自然而然的习惯不被刻意地挑战,只要大家觉得适当的情况,就可以稍微灵活一点。事实上,我觉得这也最大程度体现出维基的精神。
以上。--Kirk★ # 2021年3月15日 (一) 17:02 (UTC)
  • 您是忽略了修订版本中争议性的问题,因为如何定义“不相关”有时也有很大争议,否则之后提案又出现是否合法公示的问题,以前已经出现过很多次公示争议,不应加一个具争议性的注脚。我觉得AT现行版较佳,没有修改的必要。--虫虫飞♡♡→♡℃留言 2021年3月17日 (三) 02:45 (UTC)
不如此修订的话,会对互助客栈的讨论生态造成严重扭曲。SANMOSA 江南好,风景旧曾谙 2021年3月17日 (三) 05:43 (UTC)
“讨论被扭曲”是您说的,不是事实。客栈的提案不是为了收集支持,而是看看有没有(-)反对,因为提案如果没有反对,公示后就可以通过,因此公示的过程就是要令提案收集更多的意见,而这七天已经是下限,没必要再缩减。--虫虫飞♡♡→♡℃留言 2021年3月17日 (三) 12:08 (UTC)
DrizzleD的1和2已经驳斥了你上面声称的东西(这个修正案完全没说要缩短七天这个时间;留言支持者越多,说明通过提案越不强行,而不是相反)。SANMOSA 江南好,风景旧曾谙 2021年3月17日 (三) 12:14 (UTC)
那也要看回应的理据是否成立,不是回应了就算。我在上面还没看到有任何理据是成立。--虫虫飞♡♡→♡℃留言 2021年3月17日 (三) 12:21 (UTC)
我真诚相信这是因为你中文理解能力有问题的缘故。换作任何其他一个人,他们都必定能够理解提案的原因,并认为其合理。SANMOSA 江南好,风景旧曾谙 2021年3月17日 (三) 12:43 (UTC)
您请保持礼仪及文明﹗也请不要诉诸人身﹗--虫虫飞♡♡→♡℃留言 2021年3月17日 (三) 12:51 (UTC)
没有对“不修改”、“现行版较佳”的观点表示反对。核心是认为可以没有明示规定但要尊重实操中的默契。(比如,规则上尽可以挑战Wikipedia:互助客栈/方针/存档/2021年3月#修订R3适用情形五的公示[毕竟严格意义上他远没有7天],但缺乏意义,只会把程序性修订也拖得冗长。于我个人而言,如果有挑战,我一定会尊重这种挑战,因为方针如此,效果也不过是拖到下个月再公示。但缺乏意义。)--Kirk★ # 2021年3月17日 (三) 13:36 (UTC)
不肯定您记得不记得,之前就试过有提案因为公示没有严格依从7days去进行,结果即使提案通过了多天,仍然引发了社群对提案的有效性的质疑。请注意方针修订是要面对整个社群,而不是几个讨论的人同意就可以绕过方针。而且方针指引的有效性不是一时的,可以在几年后,十几年后,用户翻阅存档时,也可以再次质疑提案的有效性。此外,如果提案是有共识,就不要心急通过,也不用怕多放几天会有反对。--虫虫飞♡♡→♡℃留言 2021年3月17日 (三) 13:45 (UTC)
这是因为此规则存在。假设此规则不存在,该公示理论上是完全没问题的。极端严格的“7天没留言”规则会带来游戏规则的可操作性。SANMOSA 江南好,风景旧曾谙 2021年3月18日 (四) 05:47 (UTC)
整理一下这里看到的一些东西喔。WP:CONLIMITED说方针与指引的重大修改一定要先充分讨论,但是小修改可以直接编辑,然后写编辑摘要,谨慎一些就到客栈开话题知会一下,没人回退就定了,有人反对再走程序,不过现在不知道方针小修改还能不能这样。所以现在这个WP:7DAYS好像就是要让人在重大修改,需要经过公示的话,希望能放上一个月,7天没新留言会不会是当时支持方的妥协,所以现在他们不想在缩小新留言范围,因为精神上他们认为至少放一个月比较好。--2001:B042:1:A908:F58C:12D4:4C7B:B776留言) 2021年3月18日 (四) 04:40 (UTC)
  • 现在7days的实际执行情况也不是很好。一些提案会根据SNOW和IAR缩短公示时间,一些提案会在数日无新留言时直接进入公示(并加长公示时间)。 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月18日 (四) 15:23 (UTC)
    也是啦,这个可以在观察,一个规定常常会被SNOW、IAR、无视,是可以检讨一下规定。以后大家真的觉得“至少放一个月的精神”真的太长的话,看看能不能不要管7天新留言,全部改成至少放14天又取得共识才能公示,然后公示至少要放7天。这样的14+7规定也不比人事任免、荣誉票选短了,等于提案至少有放21天的知会、反对、讨论时间了,然后难聚共识的大提案一定还会在更长。--2001:B042:1:A5B3:7CCD:E884:C570:5D6A留言) 2021年3月19日 (五) 03:33 (UTC)
IAR不能乱用,只有在现行规则阻碍您维护维基,才可以用,而且要准备受到社群的质疑,提案多讨论几天,有利于收集更多意见,因此不适宜引用IAR。此外,不依7DAYS会引发很多争议,之前就试过有提案因为公示没有严格依从7days去进行,提前公示了,结果即使提案通过了多天,仍然引发了社群对提案的有效性的质疑。--虫虫飞♡♡→♡℃留言 2021年3月19日 (五) 06:35 (UTC)
这IAR连其他管理员自己也有用到,那次我就懒得抓7日了,结果就直接过了。SANMOSA 江南好,风景旧曾谙 2021年3月19日 (五) 09:28 (UTC)
其他用户怎样做,我不评论,但IAR是不能乱用。而且我觉得现行方针较佳,没必要修改,而且提案也带出了新的争议。--虫虫飞♡♡→♡℃留言 2021年3月20日 (六) 08:41 (UTC)
正是因为不能一直IAR下去,所以才要改规定啊。--DrizzleD (按此给我留言) 2021年3月21日 (日) 05:21 (UTC)
剩下两点。1.没必要 不是只有“必要”的事我们才做,有益于维基百科就可以了。2.新的争议 争议不是个天生的坏东西,当区分有益的时候,有争议也要区分。--DrizzleD (按此给我留言) 2021年3月21日 (日) 05:36 (UTC)
@蟲蟲飛:既然这都不能IAR了那IAR存在的意思是?然后滥用IAR的您也可以送一张反对票让它重写公示,真的能起争议的还是能被7DAYS框住的。-- Sunny00217  2021年3月22日 (一) 16:32 (UTC)
  • IAR是用于紧急情况,例如管理员失控,删去首页,其他管理员可以不用drv,直接还原;或者管理员失控狂封人,其他管理员可以直接解封及封了失控管理员等紧急情况。相反,如果可以任意用,方针指引也没用,人人都可以引用IAR。--虫虫飞♡♡→♡℃留言 2021年3月22日 (一) 22:33 (UTC)
    从来没有说法说IAR只能用于紧急情况,只要忽略的是妨碍你恰当地改进或维护维基百科的规则就可以了。--DrizzleD (按此给我留言) 2021年3月28日 (日) 06:39 (UTC)
  • (?)异议:方针修订属于重大提案,如果出现任何争议都会令提案的合法性受到质疑,所以我觉得AT现行版本较佳,修订版本不但没有解决问题,而且带出了新的问题。--虫虫飞♡♡→♡℃留言 2021年3月21日 (日) 06:17 (UTC)
增加争议是有益的[来源请求]-- Sunny00217  2021年3月22日 (一) 16:34 (UTC)
论据已经写在上面(并已链接到)了。WP空间内容不是条目,来源不一定有必要,不然讨论没办法进行。--DrizzleD (按此给我留言) 2021年3月28日 (日) 06:43 (UTC)

调适案1

现行条文

为了确保所有用户有充足的时间发表意见以及得悉改动,如果在互助客栈中被提出的提案在七天内没有新留言或至少讨论达一个月以上的情况下,只要取得共识便可公示,为期七天。公示期间若无异议,则提案算作通过;如果有新意见,请通过协商解决问题。存档后如果要重新提出公示的话,应同时补回相关讨论链接,以便社群查阅。

提议条文

为确保所有用户有充足的时间发表意见及得悉改动,在互助客栈中被提出的提案若在7日内无新留言[1],又或讨论已持续28日以上的情况下,只要讨论取得共识,即可公示,公示为期至少7日。公示期间若无异议,作通过论,若有新合理意见,应经协商解决问题。存档后如果要重新提出公示的话,应同时补回相关讨论链接,以便社群查阅。

参考资料

我还是想做到一些东西,退而求其次一下好了。SANMOSA 江南好,风景旧曾谙 2021年3月25日 (四) 08:03 (UTC)

主要影响:
  1. 不对提案进行任何点评的支持或中立意见不造成重算7日。
  2. 与提案本身无关的意见不造成重算7日,而意见是否与提案有关根据《讨论页指引》的规定界定。
  3. 将浮动的时间范围“1个月”界定为固定的时间范围“28日”。(依旧)
  4. 容许公示在有必要时可长于7日。(依旧)
以上。SANMOSA 江南好,风景旧曾谙 2021年3月25日 (四) 08:09 (UTC)
(-)反对:理由同上,我还是觉得AT现行版本较佳,而且提案不但没有解决问题,而且注脚部分带出更多的公示争议。--虫虫飞♡♡→♡℃留言 2021年3月26日 (五) 13:31 (UTC)
“不对提案进行任何点评的支持或中立意见”是很容易看出来的事情,多一句话就已经是“点评”了,非常明确,怎么可能“带出更多的公示争议”?《讨论页指引》的规定也应该很清楚明白吧,难道说《讨论页指引》也是形同虚设的?将浮动的时间范围界定为固定的时间范围也是明确指引的处理。修订容许公示时间可长于7日,但没容许可短于7日,因此公示时间上也不可能产生争议。综以上,我完全不认同调适案1“带出更多的公示争议”。SANMOSA 江南好,风景旧曾谙 2021年3月26日 (五) 13:39 (UTC)
现在方针修改频繁,AT版七天已经算是很合理的时间,频繁的方针修订中,让社群有足够时间去消化,及让提案有足够时间收集更多意见是必须的。--虫虫飞♡♡→♡℃留言 2021年3月26日 (五) 13:47 (UTC)
频繁的方针修订正是因为社群有迫切的需求,如果社群不理解方针修订的内容,理当向提案人发问(这样做无论是在原始提案下,抑或在调适案1下,都仍然会造成重算7日),我不明白社群怎么在遇到看不明白的事情都不会发问。一味压抑社群的迫切需求对社群而言并不健康,我仅是希望将equilibrium position稍稍推回到提案人一边一些而已。SANMOSA 江南好,风景旧曾谙 2021年3月26日 (五) 14:07 (UTC)
像下方#交通关注度指引修订这样的方针修订,我是不见得需要多长的时间来“消化”。需要较长的时间来“消化”可能是像下方#分案1这样的方针修订,那为何不像MINQI这样去发问?这可能比自己自行“消化”提案内容来得更有效率,使自己更快清楚明白提案内容。SANMOSA 江南好,风景旧曾谙 2021年3月26日 (五) 14:11 (UTC)
您搞错了两者因果关系,正因为修订频繁,提案更不应急于公示,应该收集更多意见,而不是火速公示,强行通过,然后有些用户来不及表达意见,结果争议不断。--虫虫飞♡♡→♡℃留言 2021年3月26日 (五) 14:14 (UTC)
不,方针指引修订频繁是社群的迫切需求的结果。现行条文只是在无视社群实际存在的迫切需求,并将之强行压抑。社群的迫切需求是方针指引修订频繁的产出来源,应当做的是满足需求,而非压抑需求。再者,现实上方针指引修订频繁不可能等到所有人发表了意见才能处理,否则这就属于游戏共识形成程序的情形。SANMOSA 江南好,风景旧曾谙 2021年3月27日 (六) 10:36 (UTC)
@Sanmosa:不能认可方针的快速频繁修订(及提案和公示)。方针应该是总结归纳长久的共识,仅在争议严重时依充分讨论规定妥协方案(如COVID-19命名)。将未成熟的方针及公示作为约束或指导后续编辑的手段是不正确的,WP:BURO:“不是盲目跟随默认的方针和程序。要避免编写过分冗长的指示。”。应更多以讨论确认意见、指引,而非编立方针来不必要的规约。设立规则来制止他人反而会有GAME之嫌。--YFdyh000留言) 2021年3月27日 (六) 12:16 (UTC)
既然社群存在如此的迫切需求,那相关的规约自然是必要的。必要性取决于需求。SANMOSA 江南好,风景旧曾谙 2021年3月27日 (六) 13:13 (UTC)
“迫切需求”是您的意见,不是社群,方针属于重大提案,应该让社群有足够时间消化及表达意见,千万不要心急,有共识的提案就不用怕多放几天有(-)反对,而且急于通过,火速公示,然后争议不断,那通过的提案也不是反映共识。--虫虫飞♡♡→♡℃留言 2021年3月28日 (日) 04:54 (UTC)
方针快速频繁修订是个问题,但如果真的要修订,这里的关注点是,单纯支持之意见不该导致重算。--DrizzleD (按此给我留言) 2021年3月28日 (日) 06:53 (UTC)
要说多少遍本提案和“七天”没有任何关系。实话说,您要是觉得时间短,延长到十天我也没意见,但“不对提案进行任何点评的支持或中立意见”能导致重算,究竟合理吗?--DrizzleD (按此给我留言) 2021年3月28日 (日) 06:50 (UTC)
  • 您说没有评点就提前公示,为什么要以不同名目去提前公示呢?请了解AT版当时订的版本就是为了解决社群急于公示而带出的争议问题,为什么不能让提案多收集一些意见呢?而且要注意不是每个用户都很活跃,让提案多放一些时才能收集更多意见,因此我觉得AT现行版本较佳。--虫虫飞♡♡→♡℃留言 2021年3月28日 (日) 06:58 (UTC)
    我明白您的意思。您可以看看下面的方案如何。或许看了之后您可以更了解我的想法。--DrizzleD (按此给我留言) 2021年3月28日 (日) 07:06 (UTC)
说到这个,为了拯救陷入同义反复的讨论,我决定提出一个新想法,看看能不能抛砖引玉。改成:
为确保所有用户有充足的时间发表意见及得悉改动,在互助客栈中被提出的提案若在10日内无新留言[1],又或讨论已持续28日以上的情况下,只要讨论取得共识,即可公示,公示为期至少7日。公示期间若无异议,作通过论,若有新合理意见,应经协商解决问题。存档后如果要重新提出公示的话,应同时补回相关讨论链接,以便社群查阅。

参考资料

即额外把7日改成10日,这下新提案的讨论时间应该不会比旧的情况少了。“应该让社群有足够时间消化及表达意见,千万不要心急,有共识的提案就不用怕多放几天有(-)反对,而且急于通过,火速公示,然后争议不断,那通过的提案也不是反映共识”,那多几天总没问题吧。--DrizzleD (按此给我留言) 2021年3月28日 (日) 07:01 (UTC)
  • 我还是觉得注脚部分有争议,因为“有没有点评”不同人都有可能有不同的解读,而且客栈遇到激烈争议时,这个注脚只会带出更多争议,而且本站社群还没有达到英维的客观与理性,无视反对意见,指鹿为马等奇怪的事常有,因此我还是(-)反对注脚部分。反而,Sanmosa想争取28天,减两天,这个我没有异议。--虫虫飞♡♡→♡℃留言 2021年3月28日 (日) 07:19 (UTC)
    好,Sanmosa想争取28天,减两天,这个我没有异议,看来我们已经达成了第一个共识,讨论是有成果的了。
    下一个点是,您是否觉得不对提案进行任何点评的支持意见不导致重算合理。如果是的话,那我们就达成了下一个共识,只需要关心有没有办法解决“有没有点评”不同人都有可能有不同的解读这个问题就可以了。--DrizzleD (按此给我留言) 2021年3月28日 (日) 07:51 (UTC)
“不对提案进行任何点评的支持或中立意见不造成重算7日”这句话的意思我要解释一下,就是只写了“支持”、“中立”、“没意见”、“不反对”之类的,我认为定义已经足够明确。我不要求只有“实则性点评”才能导致重算7日已经是很大的让步了。SANMOSA ······ 2021年3月28日 (日) 23:51 (UTC)
  • 这是不必要,而且这是您的理解,实际的争议时,不同人都可能有不同的解读,我还是觉得AT现行版本较佳,即“七天没有留言”就可以公示,完全没有争议。但您以不同名目去缩短公示期限,这是不必要,而且容易造成争议。提案的公示一旦有争议,提案的合法性就会受到质疑,过去是有先例的。--虫虫飞♡♡→♡℃留言 2021年3月29日 (一) 05:05 (UTC)
    • 问题在于,现在有些人看到讨论过了几天,避免重算也不敢支持也不敢中立,我觉得反而不好收集社群意见。 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年3月29日 (一) 06:07 (UTC)
  • 您有所不知,客栈的提案不是收集支持或中立,而是看看有没有(-)反对,因为提案放出来,七天完全没有留言,已经可以公示,公示后,没异议就通过,其他维基也是一样,因此提案的反对意见比支持的意见重要。而且,“七天没留言”在维基可视为默认共识,见WP:TALKDONTREVERT:“假如编者已停止在讨论页内回复相关讨论,便可以假定共识已经形成。”--虫虫飞♡♡→♡℃留言 2021年3月29日 (一) 06:30 (UTC)
    如果相关支持意见或中立意见里面有其他建设性的提议的话,那些意见和反对意见是同等重要的,然而现行条文有可能阻碍相关附有有其他建设性的提议的话支持意见或中立意见的表达。SANMOSA ······ 2021年3月29日 (一) 06:36 (UTC)
所以我希望最后的共识能确立该条条文以我上方的解读为准。SANMOSA ······ 2021年3月29日 (一) 06:36 (UTC)
  • 还是回到那个问题,什么叫“有建设性的意见”?标准谁定?争议时互相指责对方的意见“无建设性”,结果把本来不应有的公示争议,变得非常有争议。虫虫飞♡♡→♡℃留言 2021年3月29日 (一) 06:53 (UTC)
我请你重看我的调适案1,我的调适案1完全无提及过“有建设性的意见”,我不知道你是从哪里看到的,还是你不小心看到了什么一般人看不到的东西。如果你是从我上面的留言看到的话,那我只能够说你真的没有一般人应有阅读中文的能力,我说的是现行的条文让人不愿意留下附有其他建设性的提议的支持意见或中立意见,而不是直接阻止,具阻止性质的效果有时候并不需要直接言明的条文达到;至于这事情会产生的问题,那就是只有反对意见得以显现,使实际的意见比例和表面上所看到的意见的比例不符。SANMOSA Σουέζ 2021年3月29日 (一) 10:00 (UTC)
  • 请重看您于“2021年3月29日 (一) 06:36 (UTC)”的留言。而且“进行任何点评”也是换了不同的名目,性质也是一样,这些都是不必要的,AT现行版本已经很清晰,没有修改的必要。--虫虫飞♡♡→♡℃留言 2021年3月29日 (一) 14:02 (UTC)
完全不一样,这制限条件已经完全不同了。我真的只能认为你真的没有一般人应有阅读中文的能力,这分明已经是两种完全不同的情况。SANMOSA Σουέζ 2021年3月31日 (三) 07:49 (UTC)
请不要人身攻击﹗您是换了不同名目去缩短公示期,这是与AT版解决火速公示的提案原意不合。而且我反而我看到您平时公示时一有异议就重新公示,我觉这个操作很不错,所以建议加一条“公示期间如有异议应重新公示”。--虫虫飞♡♡→♡℃留言 2021年3月31日 (三) 10:35 (UTC)
“缩短公示期”从不存在,不论是原案抑或调适案也如是。我认为所有用户均有重新公示的意识,而且重新公示的操作可以依规进行,无须特别规范。SANMOSA Σουέζ 2021年4月1日 (四) 00:51 (UTC)
(-)反对,赞同虫飞飞的意见。AT的版本已经很清晰。Walter Grassroot留言) 2021年4月1日 (四) 01:34 (UTC)
(咦?)SANMOSA Σουέζ 2021年4月2日 (五) 08:43 (UTC)
提案目的并非让方针更“清晰”。--DrizzleD (按此给我留言) 2021年4月4日 (日) 16:24 (UTC)
(-)反对:在此种情况下应依据常识进行判断,而不是拘泥于方针细节之中。--Yining Chen留言|签名) 2021年4月4日 (日) 12:05 (UTC)
就在WP:UCS这一页的图表:是否是规则错了?是→改变规则。--DrizzleD (按此给我留言) 2021年4月4日 (日) 16:29 (UTC)

台湾原住民族人条目命名(第二次)

承上次讨论,现拟议为Wikipedia:命名常规 (人名)加入以下一条:

以上。此条确立使用汉人姓名或台湾原住民族人名命名台湾原住民族人士的传记条目时均应使用中文命名的原则,但不对以非本名见称的台湾原住民族人士的传记条目造成影响。SANMOSA 江南好,风景旧曾谙 2021年3月22日 (一) 00:53 (UTC)

@YumetoLt2818克勞棣Y0529543SANMOSA 江南好,风景旧曾谙 2021年3月22日 (一) 01:00 (UTC)
这规定并不能解决究竟是命名为“张惠妹”还是“古历来·阿密特”的问题。若针对上次事件的话,我觉得重点在于强调人物命名须用汉字。--Lt2818留言) 2021年3月22日 (一) 03:33 (UTC)
@Lt2818:(1)应该是能解决的。张惠妹的户籍是用什么名字登记的?(我看到一些台湾政府网站把她的名字继续写成“张惠妹”,台湾原住民族人名仅为括注,估计应该还是用汉名登记的。)(2)“台湾原住民族人物命名须用汉字”这点确实也是我希望确立的。SANMOSA 江南好,风景旧曾谙 2021年3月22日 (一) 07:11 (UTC)
户籍登记姓名可能难以查证。况且,即使张惠妹真的登记为“古历来·阿密特”,用这个名字命名条目恐怕也不合适。刚刚发现Wikipedia:命名常规已写明“使用中文”,那么再加上既有的常用名原则,就无须对台湾原住民族作特别规定。--Lt2818留言) 2021年3月22日 (一) 09:04 (UTC)
如果是这样的话,那就根本不需要另立规则,因为现行命名常规已经有“使用中文”和“使用常用名称”的规定,直接搬这两条出来用就可以,这两条的应用现时也已经具备相当的灵活性。SANMOSA 江南好,风景旧曾谙 2021年3月22日 (一) 10:12 (UTC)
于2021年3月22日 (一) 07:17 (UTC)在不更改提案大意的前提下重写提案。SANMOSA 江南好,风景旧曾谙 2021年3月22日 (一) 07:17 (UTC)
(-)强烈反对。先前U:克劳棣所称“谷辣斯·尤达卡不仅仅是中文翻译,这就是她身为中华民国国民的本名”并非事实,原住民提供翻译或另取的中文名字,时常只是为了配合汉人的风俗习惯以及汉人政权的法律,不见得代表那就是这个人的本名。例如Kolas自己就有公开说他希望人们用拉丁转写来表示他的名字,这才叫名从主人。中维对娱乐创作的标题以及艺名那么重视官方想要的呈现方式,不旦包括无法念出的符号、区分外观相同只是Unicode编码不同的符号、通融各种违反中文文法、不存在于中文的文字、或忽视英文大小写习惯,然而遇到原住民想用自己的方式表示名字时,却打压得这么起劲?
另外,关于张惠妹/阿密特,如果他有表达比较想用哪个名字,那就用那个,没有表态或两者都用的情况下才换用常用名。--C9mVio9JRy留言) 2021年3月24日 (三) 00:24 (UTC)
@C9mVio9JRy君:不!这就是事实,只不过您不想承认而已。①请不要断章取义,我完整的发言的意思明明是“谷辣斯·尤达卡是她身为中华民国国民的本名之一”,她想叫Kolas Yotaka,《姓名条例》也是允许加注的,谷辣斯·尤达卡与Kolas Yotaka两者都是她的本名;②中华民国国民就该遵守中华民国法律,这无分河洛人、客家人、外省人、新住民或原住民,一律平等。不然要是有个河洛人想叫“张Davidoff”或“张さゆり”或“张πΣαβγ”,甚至是“张☆△∞”,是否也要允许?不然就是打压?③汉人只能用中文字当唯一本名,无权像原住民、新住民一样加注拉丁字母,这是不是也不公平?-游蛇脱壳/克劳 2021年3月24日 (三) 02:29 (UTC)
看来我们对“本名”的定义不同。在我看来“名从主人”不是“名从国家法律”。人类早在世上有国家这种东西之前就有名字了。至于汉人想叫别的,君不见ØZI走路痛WalkToneHowHowJ.SheonJoeman全都用艺名?我就不信大家讲话的时候会念/ø.zi.ai/或“ㄗㄡˇ ㄌㄨˋㄊㄨㄥˋ wɔːk toʊn”。叫汉人用汉字和叫原住民用汉字意义完全不同,一个是用母语,一个是用外语。--C9mVio9JRy留言) 2021年3月24日 (三) 10:45 (UTC)
那请问阁下认为Kolas Yotaka的“母语的本名”怎么写?人类早在世上有国家这种东西之前就有名字了固然没错,但Kolas Yotaka明显是人类有国家的概念之后才诞生的人类。另外,请问阁下为什么未经其他用户同意,就把他们打的“她”都窜改成“[他]”?-游蛇脱壳/克劳 2021年3月24日 (三) 11:04 (UTC)
已代改回。SANMOSA 江南好,风景旧曾谙 2021年3月24日 (三) 11:38 (UTC)
抱歉我的火狐插件设了性别中立转换,似乎造成了干扰,以后会注意。Kolas自己选用了Kolas这个写法,这就是他的名字。--C9mVio9JRy留言) 2021年3月24日 (三) 12:38 (UTC)
Kolas是拉丁字母,一样是借来音译用的外语,不是她的母语。拉丁字母Kolas并没有比中文谷辣斯更正统、更能代表阿美语。-游蛇脱壳/克劳 2021年3月24日 (三) 13:36 (UTC)
Kolas觉得“Kolas”比“谷辣斯”更能代表他自己,那就够了,你一位路人对拉丁文字或汉字的看法与他的名字无关。--C9mVio9JRy留言) 2021年3月24日 (三) 15:32 (UTC)
好,无关。-游蛇脱壳/克劳 2021年3月24日 (三) 17:07 (UTC)
甘仔辖·阿拉米Kamachat Aslamie)是大肚王国君主,属于(广义上的)台湾原住民,那时候的大肚王国根本没有文字,上面我给出来的拉丁字母是荷兰人音译出来的荷兰文。试问甘仔辖·阿拉米的“母语的本名”又是什么?该用中文还是荷兰文?SANMOSA 江南好,风景旧曾谙 2021年3月24日 (三) 11:38 (UTC)
当时原住民没有自己的文字而且当事人已过世,那就用现代中文转译,这和现代人的情况不同。--C9mVio9JRy留言) 2021年3月24日 (三) 12:41 (UTC)
可能要考虑不愔拉丁字母的人士的需求。SANMOSA 江南好,风景旧曾谙 2021年3月24日 (三) 00:52 (UTC)
重定向可以带到条目,条目内也列了汉译。如果真的很在意有人不懂拉丁字母,我们应该先动手的是hide改成松本秀人、Microsoft Windows改成视窗、甚至iPhoneLINE改成哀凤和赖。--C9mVio9JRy留言) 2021年3月24日 (三) 01:05 (UTC)
使用率不同。你提到的后三个例子基本上都直接被当成中文使用,但人名并非如此。SANMOSA 江南好,风景旧曾谙 2021年3月24日 (三) 02:07 (UTC)
我身边发音为哀凤和赖的人比用英语发音成i-phone和line的人更多。--C9mVio9JRy留言) 2021年3月24日 (三) 10:26 (UTC)
可能是所在地不同的情况,我身边的情况和你身边的情况完全相反。SANMOSA 江南好,风景旧曾谙 2021年3月24日 (三) 11:24 (UTC)
(+)支持,理据充份,需要有一个可行的维基方针。另提醒维基百科不是宣传工具,这边不是宣传族名拼写运动或是去中文化的地方(来到中文维基推动去中文化本身目的就抵触和相反了),这里只是民间团体的写作网站,政策方面如有疑义请自行前往监督政府。--章安德鲁留言) 2021年3月26日 (五) 18:42 (UTC)
于2021年3月27日 (六) 10:54 (UTC)修改提案,不影响文意。SANMOSA 江南好,风景旧曾谙 2021年3月27日 (六) 10:54 (UTC)
仍然(-)反对。理由再重复写一下:“使用中文”是冗言,理当如此。户籍登记姓名则难以查证,此规定无意义。--Lt2818留言) 2021年3月27日 (六) 11:32 (UTC)
(1)非冗言。WP:命名常规#使用中文:“……惟若原文名称比中文翻译的名称在中文中更加常用,或如果不存在中文翻译的名称,则应使用原文名称。至于个别专题下之条目之命名,如有对应子方针,则应以该子方针指引之规则为优先。”根据此条,“理当如此”的关系不存在,一来是子方针优先性高于母方针,二来是罗马拼音可能比中文翻译在中文中更加常用。(2)政府网页或身份证上的姓名和户籍登记的姓名一致。SANMOSA 江南好,风景旧曾谙 2021年3月27日 (六) 13:20 (UTC)
举个例子,国际单位制的重新定义之所以拖到2019年,是因为先前对相关物理常数的测量精确度不足。同样,除非中华民国能提供所有公民的登记姓名查询,否则其不应作为判别依据写入方针。--Lt2818留言) 2021年3月27日 (六) 15:28 (UTC)
反对理由不充份,看不懂国际单位制的例子跟这里的关联。另外,以人物传记条目蔡英文为例,“性别、别名、出生、籍贯、民族、国籍、父母”etc.这些资料同样都不是来源自(也不可能会有)所谓的“公民登记查询”数据库。--章安德鲁留言) 2021年3月29日 (一) 05:00 (UTC)
国际单位制的例子为类比。公制确立的时候,把“一米”定义为子午线两千万分之一或者米原器长度都没问题,但不能定义为光在1/299792458秒内行进的距离,因为当时没人测得出光速。提议条文中的“户籍登记姓名”同理,哪怕张惠妹亲属以其身份证为凭,也不能把条目命名为张鲑鱼,正因户籍登记姓名对于公众而言无法查证,也不可能让主张者上传身份证来证明。--Lt2818留言) 2021年3月29日 (一) 07:18 (UTC)
还是没有回答到问题:“性别、别名、出生、籍贯、民族、国籍、父母”etc.同样也没有开放可直接线上查询的登记数据库,所以反对理由不够合理。另外虽然不具参考性,但是维基上确实是有老蒋的身份证。--章安德鲁留言) 2021年3月30日 (二) 10:55 (UTC)
@Ch.Andrew:我不是说身份信息查询合理。这个条件和“山无陵,江水为竭,冬雷震震”为同样性质,作为另一命题的归谬,本身并非重点。后者应该见过,毕竟溪口、慈湖都曾游览过。--Lt2818留言) 2021年3月30日 (二) 11:48 (UTC)
想到一个问题:如果我们认定iPhone和Windows是否已经成为中文外来语的依据是它是否常用,那实质上就是用“常用名称”作为条目名,比照办理的话,原住民的名字也应该以常用名优先;如果常用名是拼音,那该用拼音作条目名。然而此提案第二点却说当拼音确实比中文翻译更常用时,“应将该常用名称音译处理”。我不懂如果iPhone和Windows这两个常用名称可以当作外来语使用,不用翻译成哀凤和视窗,为什么原住民的名字却必须以中文优先?一方面我们接受西方和日本的科技及娱乐主题用原文,一方面我们不允许少数民族用原文,这除了双重标准和差别待遇之外,我看不出别的解释。--C9mVio9JRy留言) 2021年3月28日 (日) 15:10 (UTC)
总结来说,我的立场有两点:(1) 当事人明确表态希望用某种方式表示他的名字时,这是他的基本人权(联合国人权事务委员会,Coeriel and Aurik v. the Netherlands),应予以尊重,尤其当他们是历史上曾遭受不正义的少数族群时更应如此,凌驾于常用名称或使用中文的规定(至于那些单纯因商业效果而搞得怪里怪气的官方作品名或产品名,因不涉人权,可以常用名优先)。(2) 若当事人未表态,但有广泛接受的常用名,此常用名优先,不管是拼音还是中文,如同电子产品和一些亚洲艺人的情况。--C9mVio9JRy留言) 2021年3月28日 (日) 18:29 (UTC)
因为《姓名条例》对所有中华民国国民都有约束力,并没有双重标准。如果一位台湾原住民不是出于商业因素,而是真心非常非常喜欢数学,喜欢的程度多过他的族群传统文化,阁下认为他可以用e^(iπ)+1=0作为本名吗?这也是他的基本人权?那么台湾汉人有无这样的基本人权?-游蛇脱壳/克劳 2021年3月29日 (一) 00:24 (UTC)
1. 提案中的“将该常用名称音译处理”并非使用符合《姓名条例》的法定姓名。2. 姓名条例对中华民国国民的法定姓名有约束力,但对维基百科的条目名没有约束力。3. 我倾向认为不论法律是否允许,你都有权昭告天下说你的名字是“许星光流连击鲑鱼”,大家也应该尊重。4. 用数学公式当名字目前没有判例,如果有一般人念不出来的符号或是技术上难以显示的格式,我猜人权事务委员会可能会同意国家有权禁止该姓名。5. 汉人当然有权利用别的文字当名字,而且维基百科对这些另取名字的汉人可尊重得很,我前面已经举例了:ØZI走路痛WalkToneHowHowJ.SheonJoeman。--C9mVio9JRy留言) 2021年3月29日 (一) 00:53 (UTC)
虽然《姓名条例》对服务器在美国的维基不具约束力,但是仍是一项重要的参考基准。“姓名”和“商标、艺名、产品名、书名”etc.的法律意义及社会意义上都有所不同,姓名是别人如何称呼你并且令每个人与社会链接的工具。后现代主义让许多人自我中心惯了,法律和契约这些基本观念仿佛通通当成空气一样。实务上不可能让姓名权无限上纲,若有人主张自己的姓名是“以微秒变换、以鲑鱼起头接续所有中文字集进行无穷级数排列组合的姓名光谱”,请问该如何呈现?另外还要考虑到姓名跟转型正义抵触时被禁止的情况,例如纳粹系列的姓名。显然不可能对於姓名权毫无限制。--章安德鲁留言) 2021年3月30日 (二) 11:25 (UTC)
我的要求从来就不是无限上纲,而是把一个技术上可行、在中文维基中本来就存在的写法(拉丁字母),延伸到既有的“名从主人”规则,并且实行上目前唯一的案例还符合“常用名称”的规则。你想象的滑坡例子不会有可靠来源,并且可以简单用技术理由禁止。--C9mVio9JRy留言) 2021年3月31日 (三) 05:40 (UTC)
(-)反对Kolas比谷辣斯更常用、广为人知,用google去找结果也是这样。一位原住民符合常用、广为人知的是拉丁字,还一定要改成汉字,那就请把艺人、运动员、作家...的广为人知拉丁名条目全部设方针改成汉字,不要只针对原住民。相反若只是原住民自己想要的拉丁名,却不是广为人知的常用名,那就不用迁就那个。--2001:B042:1:A724:7CCD:E884:C570:5D6A留言) 2021年3月29日 (一) 05:20 (UTC)
正有此意,规定不应专门针对台湾原住民。合适的行文可以为“人物若以本名命名,应当使用汉字”。--Lt2818留言) 2021年3月29日 (一) 07:38 (UTC)
不管是物件、人物、官方名、艺名……,若他的广为人知的常用名是拉丁字,倒是不一定要音译成汉字。可是只要标准是一致的,不是只针对特定族群,这里就不会去反对了。--2001:B042:1:AF30:7CCD:E884:C570:5D6A留言) 2021年3月29日 (一) 08:27 (UTC)
补充一下,若认为Kolas是中文的话,请加上间隔号书写为Kolas·Yotaka,毕竟中文不用空格作标点。--Lt2818留言) 2021年3月29日 (一) 12:42 (UTC)
Microsoft WindowsiPhone 12 Pro想见 想见 想见你怎解?--C9mVio9JRy留言) 2021年3月29日 (一) 16:12 (UTC)
皆非人名。前两者相当于直接引用原文,都能接受(但对人名不适用);第三者为日本作品,对比该国其他混乱命名(如《你的名字。》《写不出来!?~编剧 吉丸圭佑的无情节生活~》)则相形见绌。我上面的话过于绝对,中文也会使用全形空格,如挪擡等情形。--Lt2818留言) 2021年3月30日 (二) 05:54 (UTC)
提供一个参考,英文维基对人物传记的指引en:MOS:MULTIPLENAMES有这句:“If a person, or more typically a group, has adopted a new name because they determined the old name to be offensive, generally use the new name for all time periods. ”简言之,如果某个人认为原本的名字有冒犯性而改名(可能因为牵涉到历史正义或传统信仰),英文维基的指引是所有内文都要尽量改成新的名字。依照此精神,如果有位原住民认为汉字名有冒犯性,也应使用族语名。--C9mVio9JRy留言) 2021年3月29日 (一) 16:53 (UTC)
我要解释一下为何要避开罗马拼音:假设台湾原住民的原住民族姓名格式名字的罗马拼音版本可以当成条目名,那理论上维基百科大部分非华裔传主的条目的名字也不该音译,而应该把那串拉丁字母当成条目名,但这显然是荒谬的。另一方面,严格上来说,罗马拼音根本不是台湾原住民族语言的“文字”,台湾原住民族语言本来就没有“文字”(或已失传),是后来才引入拉丁字母来拼写的。甘仔辖·阿拉米Kamachat Aslamie)的名字应该是拍瀑拉语,但拍瀑拉文根本不存在,我上面给出来的字母是荷兰文。SANMOSA Σουέζ 2021年3月30日 (二) 00:02 (UTC)
1.现在的命名原则是标题通常是中文的,可是原文比中文翻译在中文中更常用,或没有中文翻译,就能使用原名。这规则用在原住民身上没几位本名能用拉丁字的,暂时也就看到Kolas。若这规则用在非华裔传主的条目会造成很多拉丁字,然后大家又认为人物本名不能用拉丁字,艺名和各种物件才可以,那就设计一套不是只针对原住民的规则来用。2.这个也是有国家、族群,因为被殖民、向往种种情形,引入拉丁字母、汉字当成自己语言的书写方式,现在原住民的母语也还是用拉丁字母在书写,所以语言去区分是不是严格上自己民族发明的文字,也不是太重要的。--2001:B042:1:AFA9:7CCD:E884:C570:5D6A留言) 2021年3月30日 (二) 04:31 (UTC)
不住在华语圈的人,他们的生活中不会面对名字要怎么写的问题,也没有被汉人压迫的历史,所以他们的名字音译成汉字并不会让他们感到不愉快,但原住民不然;这在Talk:谷辣斯·尤达卡的讨论中U:Reke说明得很清楚。至于你质疑拉丁字母本来不是原住民语言,那是带有隐性歧视的论述。你去跟闽南语维基百科说他们用的白话字不是闽南语原有的文字,或是要求英文维基改用卢恩字母看看。甚至中文在甲骨文出现以前,本来也是没有文字的,而且现代这套标准化的楷书是Unicode或中华民国教育部出现之后才有的,我们没有因此说华语、英语、闽南语没有文字,为什么原住民语言却单独被指出来?现代原住民语言用拉丁字母书写,这是客观的事实,就像中华民国是主权独立的国家一样是客观的事实,只不过有些人受意识型态影响而拒绝承认原住民的文字是文字。--C9mVio9JRy留言) 2021年3月30日 (二) 12:00 (UTC)
美洲原住民同样也有受压迫的历史,却没有禁用拉丁字母拼写族语姓名的呼声,据此我合理怀疑en:MOS:MULTIPLENAMES指引对台湾原住民姓名的适切性。今天如果是要求台湾原住民的条目必须强制用汉名“林〇〇”“陈〇〇”我想在座各位都不会同意。但是针对族语姓名禁用特定语种文字的拼音,类似的作法在维基上并没有他语种的先例,叙事逻辑倒是跟十年前蒋为文公开骂黄春明的“台湾作家不用台湾语文,却用中国语创作,可耻!”相当类似。最重要的是,我不认为禁用的作法对族语的推广与保存具有正面效益,罗塞塔石碑的存在证明了多语言平行对译的重要性,施加过多的种种限制反而限缩了族语的自身发展空间。同时我不觉得Sanmosa的论述带有隐性歧视,他应该是联想或注意到相较于台湾原住民族,地球上的许多民族具有明确的自身创制文字系统,例如彝族彝文马雅文明马雅文字。另外还有一类,是援用现有文字系统并加以改造的,有加拿大原住民音节文字(援引印度天城文并且改良)、苗族柏格理苗文(参考前者的经验而创制)。而台湾原住民族语罗马字是法定的书写系统,跟前两者不同的是,既不是自有创制或是援引改良,而是直接套用拉丁字母的文字系统,顺带一提台湾原住民族语也有使用过日文假名注音字母这2种文字系统[7]甲骨文其实是相对成熟的文字系统,就像化石也有“失落的环节”那样,比起甲骨文更早之前一定还有文字,只是考古出土和解读的资料有限而已。至于楷书的标准化明显跟此事没有可类比性,这点就直接略过。其余的政治类论述则是不在我这次的关注范围内。--章安德鲁留言) 2021年3月30日 (二) 19:25 (UTC)
在维基上想替原住民争取特殊规则,他也只是论述而已,没有提案或强制大家接受,这种论述他是出于善良的、有同理心的。就好像COVID-19的命名,有人认为部分人被歧视了,想要去禁止一些用词。现在的提案情形是,原住民传主的本名就算符合命名原则的原文标题,也一定要音译成汉字,然后其他主题却没有限制。这样的话针对性比较强,原住民传主暂时也只看到Kolas本名能用拉丁字母命名而已,远远没有其他艺名、动漫、各种物件主题的拉丁字泛滥的。--2001:B042:1:A95D:C809:62F5:44EC:18E5留言) 2021年3月31日 (三) 03:40 (UTC)
中文维基本来就已经允许很多情况下采用拉丁字母,所以就算MULTIPLENAMES不曾受到美洲原住民的挑战,也还是可以在此作为参考。我要求的不是禁用汉字音译,而是在当事人明确表达对拉丁字母的偏好时,采用此写法。关于其他文字系统的部分,目前有Wikipedia:命名常规#罗马化,所以不会有蒙古文、苗文、满文、维文之类的问题。虽然这也有西方霸权的嫌疑,但该原则另外也考虑到所有华人国家都在义务教育中纳入有英语或拼音的现实(也就是说拉丁字母对多数读者来说是可识别的,其他文字不然),而且也顾及到一般人能否简单输入的技术考量。--C9mVio9JRy留言) 2021年3月31日 (三) 05:30 (UTC)
前面我误解了阁下的意思,的确,就算《姓名条例》约束所有中华民国国民都要有一个用中文表示的法定名字,也不代表维基必然要用这个法定名字作为条目名,但是,只要符合“当事人明确表达对拉丁字母的偏好”就应该要使用拉丁字母吗?前面同意“名从主人”的维基人似乎都认为至少还要同时符合“常用名称”吧?-游蛇脱壳/克劳 2021年4月1日 (四) 15:34 (UTC)
在下还真的不认为白话字台罗拼音是台语的文字,台语的文字应该是中文,尽管台语并不是唯一一种以中文为书写系统的语言。个人认为像𣍐、囡、佮、媠、𡳞这些台语常用、但中华民国国语几乎不用的“台语正字”也都是中文。白话字或台罗拼音都只是拼音而已,不是文字,用六书造出来的台语正字才是文字。-游蛇脱壳/克劳 2021年4月1日 (四) 15:34 (UTC)
我重看了一下规则,WP:常用名称只要求“尽量使用……常见的名称”,并未要求使用“常见的那一个名称”。如果99.9%的人都用某常用名称,当事人自己偏好的名字只有0.1%的人用,那我也相信用常用名是合理的,但假如两个名称的使用率是60%对40%(甚至51%对49%),或者有三个以上的名称各有一定的使用率,那么“常用名称”不足以表示任一名称比其他名称更好。总而言之,常用度和当事人的偏好的取舍,是连续分布,目前的规则并未强制以“最”常用的名字优先,我也不认为应该这么做。不过目前还没遇到实例(Kolas是最常用名称),这部分的问题或可搁置。--C9mVio9JRy留言) 2021年4月3日 (六) 15:00 (UTC)
我没有说以“最”常用的名字优先,我的意思是,“名从主人”与“常用名称”谁都没有比谁优先,所以如果“名从主人”与“常用名称”恰好是同一个名称,那就应该用这个名称,如果不是同一个名称,那就需另议了。另外,请阁下也看一下WP:名从主人Kolas Yotaka其实并不符合“名从主人”(但符合“常用名称”),彭定康陆克文郎世宁才符合。-游蛇脱壳/克劳 2021年4月3日 (六) 16:15 (UTC)

命名常规拟议修订

有关新增伪名字空间的提议

现时MOS和LTA均为伪名字空间,其中MOS专门指向站内各已正式通过和未正式通过的格式手册。我有一个想法是能不能为命名常规和关注度指引也设立专门的捷径伪名字空间?SANMOSA 江南好,风景旧曾谙 2021年3月24日 (三) 09:02 (UTC)

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

交通关注度指引修订

模板颜色相关规范

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

可参见WCAG 2.1 AA。--痛心疾首 2021年3月22日 (一) 13:34 (UTC)
Wikipedia:格式手册/文字格式#颜色及内联图像算不算?SANMOSA 江南好,风景旧曾谙 2021年3月22日 (一) 13:52 (UTC)
导航模板不算正文(逻辑上)。就是此前处理了一个WCAG 2.1有问题的模板我才开启讨论。1233 T / C 2021年3月23日 (二) 03:51 (UTC)
Wikipedia:格式手册/文字格式#颜色及内联图像的确无法处理导航模板。 --无心*插柳*柳橙汁 2021年3月24日 (三) 03:31 (UTC)
@1233Milkypine:可以扩大Wikipedia:格式手册/文字格式#颜色及内联图像的适用范围。SANMOSA 江南好,风景旧曾谙 2021年3月25日 (四) 04:40 (UTC)
完全支持扩大适用范围。 --无心*插柳*柳橙汁 2021年3月25日 (四) 05:13 (UTC)
可解决问题,故支持。唯此格式手册的修订将会影响大量的模板,故需要更深入的讨论。--1233 T / C 2021年3月25日 (四) 15:23 (UTC)
@痛心疾首Milkypine1233:已移动讨论至方针区。SANMOSA 江南好,风景旧曾谙 2021年3月26日 (五) 09:01 (UTC)
拟修改如下:
现行条文

颜色及内联图像

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

只有在背景颜色可帮助阐释条目内容,且没有其他更佳的表达方式时,才可对表格或其他的内文元素加入背景颜色。为了照顾视障或色觉障碍读者的需要,请避免单独地使用背景颜色来表达某一含义,而应适当地同时以文字方式表述。为了保障条目的可读性,请避免使用饱和度过高,或与文字对比度不足的颜色作为表格的背景色。禁止使用CSS代码对表格背景加入花俏的样式(如渐层色等)。

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

提议条文

颜色及内联图像

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

只有在背景颜色可帮助阐释条目内容,且没有其他更佳的表达方式时,才可对表格或其他的内文元素加入背景颜色。为了照顾视障或色觉障碍读者的需要,请避免单独地使用背景颜色来表达某一含义,而应适当地同时以文字方式表述。为了保障条目的可读性,请避免使用饱和度过高,或与文字对比度不足的颜色作为表格的背景色。禁止使用CSS代码对表格背景加入花俏的样式(如渐层色等)。

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

以上。SANMOSA 江南好,风景旧曾谙 2021年3月26日 (五) 23:40 (UTC)

似乎应该是不在条目里用带特殊颜色的模板,而不是规定模板不得带颜色。所以建议“条目正文、表格及各类模板”→“条目正文、表格及条目中使用的各类模板”。--DrizzleD (按此给我留言) 2021年3月28日 (日) 08:04 (UTC)
@DrizzleD:然而这里最原始的提议就是禁止所有模板着色(如果我没理解错的话),@1233SANMOSA ······ 2021年3月28日 (日) 23:48 (UTC)
@DrizzleDSanmosa:我的概念是应当创建相关Accessibility的指引(例如对规范模板中文字和背景色的对比度)。而又当此等指引未达成共识前,则不应对模板着色。--1233 T / C 2021年3月29日 (一) 02:39 (UTC)
禁止所有模板着色恐怕不现实。且不提{{支持}}这种模板或者就在本句话中使用的{{tq}},单是为数众多的多彩用户框就不可能处理过来啊。--DrizzleD (按此给我留言) 2021年3月29日 (一) 14:48 (UTC)
如果我没理解错误的话,是不是Infobox系列模板都不能自订文字和背景的颜色? 2021年3月29日 (一) 04:28 (UTC)
是的(如果我没理解错1233的意思的话)。SANMOSA ······ 2021年3月29日 (一) 05:31 (UTC)
就Accessability这个理由,完全支持禁止对模板、表格等上色。🌟🌟Talk 2021年3月29日 (一) 04:53 (UTC)
(-)反对:信息框内的文字在某些情况下应允许使用不同的颜色,否则将无法很好地表意;导航模板同理,例如{{柑橘属}}和{{地质年代}}模板使用了不同的底色,但也只是起到辅助区分相关信息的作用,并不影响色盲色弱等特殊群体阅览,取消这些底色后,非但不能照顾到少部分特殊群体(因为在色盲色弱看来,无论普通模板还是上色模板基本都是一片灰,并无本质上的区别),并且对于绝大部分正常读者而言将是一大损失。让绝大部分正常群体去迁就少部分特殊群体,属于西方式政治正确(就好比硬说黑人和白人一样聪明),英维的做法不可取。--萧漫留言) 2021年3月29日 (一) 12:51 (UTC)
同意需要有指引规范相关模板的着色。另外我处理的部分模板出现严重的"撞色"问题,才要求模板应暂时停止着色。这不是西方不西方的问题,而是此等问题已经燃烧至影响正常的阅读体验了。--1233 T / C 2021年3月29日 (一) 13:30 (UTC)
西不西方我是不清楚,但肯定是眼残级别追梦 Do Re Mi。尤其是像Template:Weki_Meki,这边上色的意义何在? --Loving You Is A Losing Game 2021年3月29日 (一) 15:21 (UTC)
不同意柑橘属跟地质年代这两个举例,柑橘属的颜色仅仅是阶层式架构,以排版就足以区分,不需要再加上颜色;至于地质年代的颜色更是没有意义,部分底色与文字颜色对比度不高,对正常人来说也是难以阅读。--Xiplus#Talk 2021年4月3日 (六) 06:01 (UTC)
@Xiplus:像这三个案例{{中国历史}}、{{Geological_range}}、和{{古近纪图形时间线}}呢,有本事你对Geological_range和古近纪图形时间线的英维版禁止着色啊。反对一刀切致使中维倒退的方针。你少代表正常人对地质年代发表看法,也只是对你来说难以阅读而已。U:Lab06 N 参与 2021年4月3日 (六) 12:46 (UTC)
(-)强烈反对:对地质和生物学相关等特殊模板有严重影响!1.减轻服务器负担这个理由就经不起推敲,难道现在的服务器机能还不如以前的服务器?2.另外照顾色盲色弱群体这个理由已经有人反驳了。U:Lab06 N 参与 2021年3月30日 (二) 13:57 (UTC)
那完全不是合理的反驳理由。“因为在色盲色弱看来,无论普通模板还是上色模板基本都是一片灰,并无本质上的区别”是错的,普通模板的话全色盲至少还能分得到浅色和深色(白色和黑色),上色模板全色盲就完全分不到了。全色盲还是能分辨白色和黑色的,他们只是cone cell不能function而已,rod cell还是能function的。SANMOSA Σουέζ 2021年3月31日 (三) 07:53 (UTC)
既然已经了解提案禁止对Infobox等模板上色,那么我(-)反对此提案,毕竟有些Infobox模板的颜色对辨别条目类型有很大的帮助,不能因为视觉障碍人士而选择单一的格式,不过如果是限制背景颜色和文字颜色之间的对比度,这我能够接受。 2021年4月1日 (四) 14:20 (UTC)
仔细想了想,倾向不赞同:
  1. (主要)现行方针能够确保色盲(弱)人士能够获取充分信息,根据现行方针要旨,只需避免“单独地使用背景颜色来表达某一含义”,同时避免“饱和度过高,或与文字对比度不足”,上述举措——
    • 确保了色盲(弱)人士能够不依赖颜色获取足够信息,确保所有人阅读的文字是清晰的;
    • 在此基础上,不对辅助性背景填色进行“一刀切”,能保障更多色觉正常的人士能借背景色获得获取信息上的便利。
  2. (次要)变更宜乎审慎行事,仅高速公路一类就有逾千条条目和大量模板受到影响,即便上述修改要实施,修正案也未能列出批量变动的页面范围和变动的具体方案。
以上。--Kirk # 2021年4月1日 (四) 14:33 (UTC)
个人认为对现行模板应当是采取没坏别修的态度:应当先行禁止新(类型)的模板着色,再讨论如何界定为“可行”且为辅助性的背景着色,再解决“应当在何时着色”和“怎样才是可行的着色”的两个问题--1233 T / C 2021年4月3日 (六) 02:41 (UTC)
  • (-)反对,限制面太广,用户框、导航模板等都会受影响。可行的着色可以按常识判断。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月3日 (六) 04:56 (UTC)
  • 拆分投票:
    • (+)倾向支持在条目正文中禁用内联图像。
    • (-)反对一刀切地禁止上色。限制使用过分复杂的上色可以理解,但一刀切的话就过犹不及了。📕📙📒📗📘📚📖 2021年4月3日 (六) 05:12 (UTC)
  • 支持要求条目用导航模板使用预设配色。使用其他颜色可以,但应该给出理由;而且这个理由是领域内讨论出的统一的配色方案。像Template:Citrus为什么要上成黄色而不是其他颜色?是属级导航框的统一用黄色,纲级导航框又用另一种颜色;还是觉得这个颜色是柑橘的主题色(那孔雀呢);还是编辑没理由随便上的颜色?而且导航模板和信息框还不一样:条目可以放多个导航模板,随意上色的结果就是花花绿绿,不同颜色搭配起来很不美观。如果其他导航框用默认颜色,比较次要的那个导航模板又私自上色,那它会不会有抢镜头的嫌疑?总之,导航模板上色需要极其保守,找不到必须上色的理由就别上。--洛普利宁 2021年4月3日 (六) 16:13 (UTC)
  • 支持楼上所述,另参考各语言维基百科也对上色趋于保守或严格规范。即便不全面禁止也需有个合理的规范,哪些领域的确有这需求,哪些领域又该严格禁止或者限定。不该完全置之不理任由问题累积未来才以影响范围大而放弃讨论制定规范。立ち直り中 2021年4月5日 (一) 12:47 (UTC)
  • 上色这种东西如果能够靠自由心证或常识解决,那就不会有像追梦 Do Re Mi这样的上色乱象。的确我不是地理条目相关编辑,但前面提到的{{中国历史}}、{{Geological_range}}、和{{古近纪图形时间线}}请问有哪个一定需要颜色?或者说这些颜色必须一定要有的理由为何?(当然也可以直接开民调调查有颜色大家会不会比较OK)。如果这些颜色有一定的存在理由,那就针对这点做改善(例如常用习惯等)。 --Loving You Is A Losing Game 2021年4月5日 (一) 13:11 (UTC)
意见颇为分歧,我建议就此进行投票,不知各位意下如何。SANMOSA Σουέζ 2021年4月10日 (六) 06:39 (UTC)
这不是投票就能解决的问题,一来是不能只因为视觉障碍人士而选择单一的样式,再者是影响范围过大,投票并不能体现所有用户的意见(匿名用户不能投票,请留意维基百科并非专给注册用户阅读)。如果您要发起民调,我没意见,但是我反对发起投票。 2021年4月10日 (六) 07:05 (UTC)
然而现时的状况确实对视障人士构成严重的歧视,我认为所有人现在最基本要知道的就是现时模板的着色情形已经严重影响到视障人士的阅读体验。投票的选项亦非只有两种(至少我初步的项目如是)。在陷入复杂讨论的泥潭时,投票显然是一种快速收集意见以凝聚共识的方法,不能单纯因为“影响范围过大”和“不能体现所有用户的意见”而反对发起投票和变相剥削视障人士的合理阅读体验。SANMOSA Σουέζ 2021年4月11日 (日) 14:26 (UTC)

变通提案

以下是小弟的变通提案:

现行条文

颜色及内联图像

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

只有在背景颜色可帮助阐释条目内容,且没有其他更佳的表达方式时,才可对表格或其他的内文元素加入背景颜色。为了照顾视障或色觉障碍读者的需要,请避免单独地使用背景颜色来表达某一含义,而应适当地同时以文字方式表述。为了保障条目的可读性,请避免使用饱和度过高,或与文字对比度不足的颜色作为表格的背景色。禁止使用CSS代码对表格背景加入花俏的样式(如渐层色等)。

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

提议条文

颜色及内联图像

条目正文表格及各类模板(包括信息框中,使用源代码或其他模板将文字或背景颜色染成非预设颜色,应以帮助阐释条目内容为第一目的同时,编者也需要考虑色盲、色弱或使用黑白版本的读者的实际需求。[1]

除非编者有正当理由,并且能在讨论页自证有理,否则:

  • 同一表格或模板只能使用一种边界色、一种标题栏背景色、一种标题栏文字色,且总共不能超过三种颜色;
  • 请避免单独地使用背景颜色来表达某一含义,而应适当地同时以文字方式表述;
  • 边界色、标题背景色、标题文字色之间应该有可视的对比度;
  • 内容背景色和内容文字色之间也应该有可视的对比度;
  • 表格/模板边界色和内容背景色两者的饱和度不能太高;
  • 禁止手动将表格或模板的内容文字染成其他颜色。
  • 禁止使用CSS代码对表格/模板的任何部分加入花俏的样式(如渐层色等)。

为避免编辑争议,建议编者在编辑的同时,即在编辑摘要或讨论页中说明上色的理由。

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

  • “一种颜色”的定义为一个RGB值。例:#FFFFFF和#FFFFFE视为两种颜色。
  • “饱和度不能太高”定义为红绿蓝三原色中,任何一种原色数值低于EE。

小弟主要编辑体育相关条目,因此在这里用个和体育相关的例子:编者在编辑某足球队的球员名单(表格)时使用的标题背景/文字颜色组合,如果和该足球队队徽或主场队服的配色相同,即视为能够“帮助阐释条目内容”。反之,如果编者用的是另一支球队的队徽或主场队服的配色,则视为无助于阐释条目内容,要么重新上色,要么改用预设颜色。举例说明:加拿大国足的主场球衣(守门员除外)的主色调为红色(#FF0000或更深),球衣字体为白色,而且红色和白色之间的差距足够大,因此加拿大国足的导航模板的标题可以染成红色背景、白色文字。美国国足的主场球衣的主色调为蓝色,因此如果把加拿大国足的导航模板的标题染成蓝色背景、白色文字,则视为无助于阐释条目内容。

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

交通关注度指引适用范围的扩展

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

提议对WP:DYKC的投票须知进行修改

现行条文

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

提议条文

投票者可用{{支持}}{{反对}}(或{{support}}{{oppose}})进行投票,动用到自定义参数修改预设显示文字的模板不计票。可用其他模板作为引子来表述观点

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

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

代增补一条。SANMOSA Σουέζ 2021年4月2日 (五) 05:07 (UTC)
(+)支持此提议。另外,建议增加{{Support}}{{Oppose}}写明于说明内(首字母大写不同),使叙述更加明确涵盖到此二模板的各种表示法。不过如果要考虑到点票作业方便,鉴于{{Support}}、{{Oppose}}为较泛用型的意见表达模板,建议可以仿照FA、GA评选,创建评选投票专用模板(比如仿照{{YesFA}}、{{NoGA}}的呈现方式,修改既有{{YesDYK}}、{{NoDYK}},使其做为DYK评选投票专用)。如此应可以增加点票作业程序的稳定性。--Bowleerin留言) 2021年4月3日 (六) 08:17 (UTC)
那么如果真的有意见或疑问,想要咨询主编怎么办?例如条目内文中出现“……于昭和二十年(1955年)创立”这样的年份错误,想要请主编确认到底是昭和二十年还是1955年。-游蛇脱壳/克劳 2021年4月3日 (六) 13:10 (UTC)
啊就(!)意见(?)疑问啊,这两个模板本来就不计票。—— Eric Liu 创造は生命(留言留名学生会 2021年4月3日 (六) 13:29 (UTC)
公示7日。SANMOSA Σουέζ 2021年4月10日 (六) 05:59 (UTC)

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

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

所以你自己这个案会怎样处理?-某人 2021年4月4日 (日) 08:06 (UTC)
是指权限不足?方针改了的话,这个问题就迎刃而解了。后来的人没问题就行了,我自己可以暂时在需要的时候拜托其他是管理员的人。--安忆Talk 2021年4月4日 (日) 08:22 (UTC)
让您成为唯一一位例外并不太好; 可是要求您辞职又更过分了。--Temp3600留言) 2021年4月4日 (日) 18:40 (UTC)
我想这不是一个特别难解决的矛盾,不看这个,就方针本身的变动而言,请问有什么意见吗?--安忆Talk 2021年4月5日 (一) 02:30 (UTC)
由于我一向支持将技术组与行政组尽量分拆,我反对您的建议。--Temp3600留言) 2021年4月10日 (六) 12:36 (UTC)
我认为,界面管理员确实有跛脚的问题,但尚没有到必须要所有界管都一定要管理员权限的境地。有最好,但没有的话也不是没法开展工作。--痛心疾首 2021年4月5日 (一) 04:14 (UTC)
目前界面管理员没有deleteeditcontentmodelmovemove-subpagessuppressredirect等权限,就您的个案来看,这个提案是很实际的。不过对于临时申请界面管理员的用户(外站也有可能),这些权限可能不是那么重要。如果提案通过,界面管理员将永远不能申请临时权限。-- 2021年4月5日 (一) 07:15 (UTC)
可以临时授权管理员,历史上有过先例,所以在迫切需要的时候,应该也可以临时授权界管。--安忆Talk 2021年4月5日 (一) 07:23 (UTC)
我相信当初从管理员拆分出界面管理员有一定的道理,如果提案通过,那么拆分还有什么意义呢?临时许可管理员又是另一回事了,因为管理员和界面管理员的业务内容不同,双重许可必须要从许多方面考量,但是只依申请者的需求来单一许可,手续就不会那么繁琐,毕竟临时许可可能是紧急的,如果从太多方面考量,时间必定会被拖延。这是我的个人意见。-- 2021年4月5日 (一) 17:59 (UTC)
(-)反对提案,不明白“达到逻辑和运作上的自洽”是什么意思,根本上界面管理员跟管理员做的事大都有所分别,如果一个人被信任在有权限编辑界面,不代表他/她能解决编辑争议且能获得Special:UserGroupRights#sysop中非常多的权限(不止上面列举的那些)而不滥权。虽然不知道设立这方针时是怎么想的,但我觉得介管不须管理员权限才能申请也是因为希望两者是分工合作。--Sun8908 怯就输一世 2021年4月5日 (一) 12:27 (UTC)
不赞同。理由同痛心疾首和空气小猫。我认为只要可信任+有技术就可以当界面管理员。目前还没有到需要先当上管理员来证明可信度的地步。至于权限不足,也不是什么事情都不能做,而且可以由界面管理员提出编辑请求,让管理员协助。--dqwyy (talk) 我们终将成为枫音乡的过客 2021年4月6日 (二) 06:58 (UTC)
我还是觉得直接让界面管理员扩权就可以。SANMOSA Σουέζ 2021年4月7日 (三) 05:36 (UTC)
@Sanmosa早在近三月前,我便问过了编辑类权限。但连编辑类权限都要不来,更不要说其他杂七杂八的权限。--安忆Talk 2021年4月8日 (四) 05:08 (UTC)
我认为这是单纯因为你使用个人名义请求的缘故。如果有社群共识的话,我估计可能会有所不同。SANMOSA Σουέζ 2021年4月8日 (四) 05:10 (UTC)
我也是这么认为的,所以才有了之后的几个提案,但现在看起来还是不太可行。--安忆Talk 2021年4月8日 (四) 05:18 (UTC)
  • @sanmosaAnYiLin: 我建议,可以授予界面管理员目前没有的editcontentmodel、move、move-subpages和suppressredirect四个和界面调整直接相关且相对不敏感权限。删除权限让人联想到页面的存废,或许太过敏感,可以日后再说。--痛心疾首 2021年4月10日 (六) 07:56 (UTC)
    同意。可以一步一步来。SANMOSA Σουέζ 2021年4月10日 (六) 09:32 (UTC)
    (✓)同意。根据界面管理员实际,我提出了下面的条文,以一劳永逸地解决上述大部分问题,请各位参考:SanmosaAnYiLin痛心疾首DqwyySun8908Pseudo ClassesAINH
现行条文

界面管理员持有下列权限:

  • editinterface︰修改MediaWiki名字空间页面。
  • editsitecss︰修改MediaWiki名字空间下之CSS页面。
  • editsitejs︰修改MediaWiki名字空间下之JS页面。
  • editsitejson︰修改MediaWiki名字空间下之json页面。
  • editusercss︰修改用户名字空间下之CSS页面。
  • edituserjs︰修改用户名字空间下之JS页面。
  • edituserjson︰修改用户名字空间下之json页面。
  • oathauth-enable︰可以开启双重认证(2FA)。
提议条文

界面管理员持有下列权限:

  • editcontentmodel:编辑页面的内容模型。
  • editinterface︰修改MediaWiki名字空间页面。
  • editsitecss︰修改MediaWiki名字空间下之CSS页面。
  • editsitejs︰修改MediaWiki名字空间下之JS页面。
  • editsitejson︰修改MediaWiki名字空间下之json页面。
  • editusercss︰修改用户名字空间下之CSS页面。
  • edituserjs︰修改用户名字空间下之JS页面。
  • edituserjson︰修改用户名字空间下之json页面。
  • move-subpages:可以在移动主页面时一并移动子页面(上限100个)。
  • oathauth-enable︰可以开启双重认证(2FA)。
  • suppressredirect:可以移动时并不保留重定向。
  • templateeditor:编辑保护级别为“仅允许模板编辑员和管理员”的页面。
请各位审阅。--悔晚齋臆語) 2021年4月10日 (六) 14:57 (UTC)
(-)反对新增不是只有管理员