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

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

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

Breezeicons-apps-48-cantor.svg
发表前请先搜索存档,参考旧讨论中的内容可节省您的时间。
公告板
# 话题 发言 参与 最新发言 最后更新(UTC+8)
1 专题名字空间 162 19 Shizhao 2021-03-01 19:46
2 伪名字空间 203 18 A2569875 2021-02-25 13:46
3 WP:捷径指引草案修订 13 4 A2569875 2021-02-25 13:48
4 建议删除姓氏分类 1 1 Jimmy-bot 2021-03-02 00:14
5 关于Wikipedia:命名常规#使用外文命名时的专门要求,请问音乐作品名称是否能算是专有名词? 84 26 Milkypine 2021-03-02 02:06
6 国际关系条目命名常规 18 5 Sanmosa 2021-03-01 14:08
7 悬挂Blocked user模板之利弊 12 7 CreeperDigital1903 2021-02-26 18:28
8 维基百科:管理员解任投票潜在漏洞 16 11 Ericliu1912 2021-03-01 14:34
9 将Wikipedia:回退功能#移动时不留重定向合并到Wikipedia:重定向#移动时不留重定向 24 5 Hjh474 2021-03-01 18:29
10 用户名修改与订阅 3 3 Ericliu1912 2021-02-22 21:16
11 修正WP:PB条文内容 17 8 Sanmosa 2021-02-28 13:37
12 (续)现行日期和数字格式手册条文调适 8 3 Sanmosa 2021-02-22 21:57
13 Wikipedia:格式手册/标点符号#冒号增订 6 4 Sanmosa 2021-03-01 18:37
14 修订维基百科:关注度 (人物) 16 7 Fire-and-Ice 2021-02-28 20:58
15 拟议快速删除方针条文增修(A部分) 10 4 Pseudo Classes 2021-02-26 20:57
16 拟议快速删除方针条文增修(B部分) 16 4 Sanmosa 2021-02-28 18:51
17 拟议快速删除方针条文增修(C部分) 35 4 Xiplus 2021-03-01 19:18
18 提案重启“新设删除员权限”讨论 58 20 Longway22 2021-02-28 12:21
19 Wikipedia:格式手册/两岸四地用语及Wikipedia:格式手册/朝鲜半岛用语 5 2 Sanmosa 2021-03-01 18:51
20 有关某年代相关分类命名统一事宜 31 10 YFdyh000 2021-02-27 05:01
21 买卖维基百科的账户是否合规 14 5 喵呜猫 2021-02-28 22:44
22 重提Wikipedia:集中讨论 2 2 YFdyh000 2021-02-28 18:37
23 在格式手册/标点符号#引号中加入 POV 一节 5 3 Yangwenbo99 2021-03-02 02:00
发言更新图例
  • 最近一小时内
  • 最近一日内
  • 一周内
  • 一个月内
  • 逾一个月
特殊状态
已移动至其他页面
或完成讨论之议题
手动设置
当列表出现异常时,
请先检查设置是否有误

专题名字空间

[编辑此导航模板]

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

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

本讨论的各阶段分为:

  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)

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

各阶段不得同时讨论,前一项讨论完结之后,才能进行下一段讨论。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年1月3日 (日) 19:29 (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)
Wikipedia:专题Wikipedia:专题委员会等部分页面为何还没有移动到新的名字空间?还是这些页面不应该移动?--百無一用是書生 () 2021年2月19日 (五) 02:46 (UTC)
先前讨论有提到将专题介绍留在WP空间。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月19日 (五) 17:12 (UTC)
专题委员会并非专题介绍,Wikipedia:专题似乎也称不上是介绍,更像是WikiProject:首页的作用--百無一用是書生 () 2021年3月1日 (一) 02:54 (UTC)
个人认为跨WP->PJ没差,但PJ->WP的不行-- Sunny00217  2021年2月21日 (日) 13:56 (UTC)

第六阶段:(暂不开放)

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

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

伪名字空间

[编辑此导航模板]

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

  • 格式手册及长期破坏者提升为名字空间,英语名称待定;
  • 格式手册及长期破坏者成为伪名字空间,缩写为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)

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

技术问题处理

名字空间侦测模板以及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)

自动半保护伪名字空间

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

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

提议设立快速删除标准 O8

现行条文

(无)

提议条文

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

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

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

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

将LTA空间设置为noindex

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

条目空间中无法使用noindex魔术字。--Xiplus#Talk 2021年2月3日 (三) 13:54 (UTC)
@Xiplus:意思说部分维护模板的设置是设置辛酸的?!-- Sunny00217  2021年2月3日 (三) 14:54 (UTC)
@羊羊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)

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

WP:捷径指引草案修订

[编辑此导航模板]

说明

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

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

本讨论的各阶段分为:

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

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

专题名字空间通过,剩余细节独立讨论。台湾杉在此发言 (会客室) 2021年1月11日 (一) 11:20 (UTC)

专题名字空间问题

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

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

捷径细部修订

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

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

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

建议删除姓氏分类

关于Wikipedia:命名常规#使用外文命名时的专门要求,请问音乐作品名称是否能算是专有名词?

近日我和用户U:KodokunaSmile在外文名称条目上有不同意见。对于〈HANN (Alone)〉,我表示“按照常用习惯”应该命名为〈Hann (Alone)〉,而KodokunaSmile大则表示“音乐标题应也可以视为专有名词”,认为应该命名为〈HANN (Alone)〉,欢迎各位维基人参与讨论,觉得音乐条目的命名是否该被视为专有名词。 --无心*插柳*柳橙汁 2021年2月6日 (六) 11:32 (UTC)

  • 为什么不是?。->>Vocal&Guitar->>留言 2021年2月6日 (六) 12:02 (UTC)
    • @Ohtashinichiro:因为如果是的话,那么这条根本没有必要存在,因为大家都是专有名词对吧(要这么严格说的话)。而且不说我,翻看过去的移动日志,有能看到许多类似理由的移动(例如U:Leehsiao)。 --无心*插柳*柳橙汁 2021年2月6日 (六) 13:26 (UTC)
    • 就用形成的例子,KMT (歌曲),这是因为他是Kiss My Teeth的缩写所以可以全大写。反之More (K/DA歌曲)Toy (歌曲)还有Ddu-Du Ddu-Du都不行。 --无心*插柳*柳橙汁 2021年2月6日 (六) 13:31 (UTC)
      • 你把enwiki的命名常规拿来这里说不行,还有什么需要讨论的?。->>Vocal&Guitar->>留言 2021年2月6日 (六) 23:54 (UTC)
        • @Ohtashinichiro:我没有拿英维的命名常规,我用的中维,你要不要看看Wikipedia:命名常规到底写了什么?就拿我上面提到的例子,这三个英文名称哪一个是专有名词? --无心*插柳*柳橙汁 2021年2月7日 (日) 05:21 (UTC)
作品标题理应是“专有名词”,而不可能是“普通名词”。--【和平至上】支持通过港区国安法💬 2021年2月6日 (六) 20:11 (UTC)
  • 不认为音乐作品的标题是专有名词,专有名词的意思是专有独一的,如果音乐作品的标题使用的都是既有的英文字或不存在必要全部大写的特殊意义,则不应该使用这种所谓的艺术字体,应该按照首字母大写其他字母小写规范使用。——Leehsiao留言) 2021年2月7日 (日) 03:00 (UTC)
“HANN (Alone)”/“HANN”是完整的专有名词,前者的“(Alone)”非出于消歧义而为之。我认为作“HANN (Alone)”或“HANN”也可。SANMOSA SPQR 2021年2月7日 (日) 03:52 (UTC)
鉴于现在意见胶着,看来是时候请其他音乐发烧友发表一下意见,@Zhaoweizhi0325MoonLight3650HXXXXPunkhippieLouis0921geePeace 621WhykittyAT:@YumetoMoonshimmer93GracellleeTreasureBabe325Hijk910Jacklamf1d14EasterliesNaveradSoftyu夜来南风起:@Pseudo Classes生米一粒百战天虫SammypanTw dramaShingkeiTombus20032000Kriz Ju:,究竟各位觉得音乐作品名称是不是专有名词? --无心*插柳*柳橙汁 2021年2月7日 (日) 15:27 (UTC)

倾向赞同Milkypine的看法--Tom......留言) 2021年2月7日 (日) 15:40 (UTC)

从语言学意义上讲,音乐作品名称并不是严格意义上的专有名词。英文维基专有名词和普通名词英语Proper and common nouns的intro第一句话就讲了,专有名词用来辨认和指明单个实体,具体例子是伦敦、木星、沙拉或者微软,而与之对应的是普通名词,用来辨认和指明一类实体,比如一座城市的“城市”、另一个星球的“星球”、这些人的“人”、我们的公司的“公司”。那么按照这条标准,音乐作品名称可以是专有名词,也可以是普通名词。专有名词的情况下,这个音乐作品名称必须只有一个实体,通俗点说就是只有一首用这个歌名。常见的,比如说各国的国歌,肯定是专有名词了吧,因为国歌是一个国家的代表形象,很少有人会创作和国歌重名的乐曲,所以这类歌曲是专有名词;另外,诸如《命运交响曲》、《威风堂堂进行曲》等有广泛认知度经典古典音乐可能也属于专有名词,现代的乐曲很少会和这些名曲重名。至于流行乐曲,歌名重复的作品太多,单单以“火”作为曲名的歌曲就有几十首英语Fire_(disambiguation),所以绝对不是专有名词,而前面提到的《命运交响曲》的正式名称《第5号交响曲》也肯定不是专有名词了。不过,需要注意到的是,上述的分析只是在音乐作品范围内进行,因为很多时候有些音乐作品的名称会出现在其他领域。最明显的,“马赛曲”除了是法国国歌以外,还可以指法国的一幢同名摩天大楼英语La Marseillaise (skyscraper)。所以,如果没有明确证据显示作品的名称只用在音乐方面,只有一支音乐作品使用,否则无法判断它到底是不是专有名词。有鉴于这个问题的判定有难度,我主张曲名不是专有名词,除非有证据证明这个曲名只有唯一一支作品在使用。所以问题提到的那首歌曲应该命名为《Hann (Alone)》,《HANN (Alone)》只是风格化表现手法,有夸张、强调的效果,英文版也写了“stylized as "HANN (Alone)”。--百战天虫留言) 2021年2月7日 (日) 16:54 (UTC)
敝人无甚创建音乐条目,仅以个人意见参照相关资讯思索一阵后,认为争议颇大。后认同天虫阁下之分析和理据:作品字体之风格化表达不等于该字词为专有名词,而现有方针内规范的用意应该是期许编者尽可能在命名时抱持“以中文优先、还原英文一般行文惯例次之”的思维。窃以为“HANN”应该是韩文(한)的音译写法,如果英文中没特别规定的话(个人没研究),按方针所言“部分语言在罗马化后没有对于大小写的规范,此时参照英文的规则处理。”,所以可能写成“Hann”即可。不过个人较偏好把作品名称大小写按其原样呈现就是了(忽略一切规则的原创方针?),如此或也最少争议且能直接为读者所熟悉(不论视觉或查找时的熟悉感),只是现有方针似乎并非如此。
个人认为在日常生活中,平时遇到作品名称应视为专有名词,原文怎么写就该怎么写,而现有方针规范和条文字面设置范畴似容易造成众热心编者适用和解读不一(究竟何为“专有名词”?)。--Kriz Ju留言) 2021年2月7日 (日) 18:22 (UTC)
中维没有音乐命名常规,现行的方针也没有明确规定。拿我上面提到的例子来讲,More (K/DA歌曲)是副词而Ddu-Du Ddu-Du是...形声字?这两个名称不管怎么样都不是“专有名词”,但如果将范围套用到作品上,这些名称只要“刚好是”作品名称就可以被视为专有名词,但问题是副词不是专有名词,现有方针也没有这样的规定,直接认定“作品名称等于专有名词”算不算原创研究。 --无心*插柳*柳橙汁 2021年2月8日 (一) 04:06 (UTC)
算的,敝人的原创研究(笑,没啦)。那些“单字”常常不是专有名词,而作品的命名呈现其实在现行规范中已有大致的习惯了,所以纯粹是窃以为个人于日常生活中偏好原汁原味呈现作品名称尔,不过这跟维基百科现况不一样。所以就看众热心编者平时迳依现行方针命名即可,或是要特别提议修改规范(自然较费工,如柳橙阁下所言目前这儿没有特别通用的音乐作品命名规范)。其实就是命名的习惯偏好吧,个人意见尔(若没人要提新案其实依惯例应该最简便 ---> 懒散的维基态度)。--Kriz Ju留言) 2021年2月8日 (一) 16:42 (UTC)
不认同百战天虫的说法,否则人名都不能是专有名词;但要注意专辑封面上的大小写不一定是歌曲名称本身,应以Plain text里的用法为准。(例如音乐播放网站的标题等);若大小写未统一则另说,但若统一或者用法频率悬殊,应依照原来的大小写写法。--【和平至上】支持通过港区国安法💬 2021年2月11日 (四) 15:02 (UTC)
  • 看下来觉得两边都有道理啊。然后再看了下油管官方用的是HANN(Alone),中间没有空格,亚马逊用的是HANN (Alone),中间有个空格,还有用HANN之后括号里没有Alone只有韩文的。所以这样就把问题更加复杂化了。然后看了下别的语言中这个条目名称的用法,发现除了泰语是翻译成当地语言之外,别的都是用的Hann (Alone)。所以,如果用HANN(Alone),就是跟官方命名的用法保持一致(但是官方本身用法就有歧义)。如果用Hann (Alone),就是跟维基别的条目的风格保持一致。我现在倾向于跟别的维基条目的风格保持一致的用法Hann (Alone)。 生米一粒留言) 2021年2月7日 (日) 19:30 (UTC)
    • 就一般情况下,将韩文罗马化会用Hann表示(例如billboard和applemusic不写成HANN而是Hann[4][5]),之所以会有大写也主要是官方youtube名称的关系。按现行方针,条目名称主要根据常用名称,但这里的常用名称是两个都有。 --无心*插柳*柳橙汁 2021年2月8日 (一) 04:06 (UTC)
不认为是专有名词。 2021年2月8日 (一) 04:46 (UTC)
其实无论是否是韩国音乐作品,许多音乐作品其条目命名都有大小写未统一的情况,有些是根据英维的规范有的是根据官方使用,所以希望这部分有个明确规范出来,方便后来者有个依循。立ち直り中 2021年2月8日 (一) 05:02 (UTC)
不应该是专有名词,该小写就小写。--东风留言) 2021年2月9日 (二) 02:34 (UTC)
统计一下目前大家的意愿。根据Ohtashinichiro大的发言,我将其算在“认同”,Sanmosa大主要是讨论该案例所以列在“不清楚”。这里在邀请一次没回应的人@Zhaoweizhi0325MoonLight3650HXXXXPunkhippieLouis0921geePeace 621WhykittyAT夜来南风起Fake12345:@YumetoMoonshimmer93GracellleeTreasureBabe325Hijk910Jacklamf1d14NaveradSoftyuSickManWPSammypan:@Tw dramaShingkei李新阳羊羊32521CHih-See Hsie卡達Pv163JoJo_append:希望能早点达成共识解决。 --无心*插柳*柳橙汁 2021年2月11日 (四) 13:30 (UTC)
倾向认同 倾向反对 不清楚/无倾向
Ohtashinichiro和平至上 MilkypineLeehsiaoTombus20032000百战天虫Pseudo ClassesEasterlies生米一粒Kriz Ju SanmosaKodokunaSmileBigbullfrog1996
题外话,不管是官方名称还是常用名称都必须依照Wikipedia:命名常规。哪怕官方名称是“大写”也会因为不属于“专有名词、部分缩写等总是大写的词”而按照“参照英文的规则处理”。 --无心*插柳*柳橙汁 2021年2月11日 (四) 13:30 (UTC)
柳橙阁下,您好像搞错了吧....。敝人的意思应该是偏向反对,毕竟目前没人提案修改。--Kriz Ju留言) 2021年2月11日 (四) 13:33 (UTC)
而生米阁下也是倾向反对,Smile阁下看似期待新提案;目前如果没人有更多想法,看起来是依原方针解读命名。--Kriz Ju留言) 2021年2月11日 (四) 13:44 (UTC)
我的意见是遵照官方写法,官方写法因为语言等问题显得不明确的话,那应该依从常用名称的写法,仍然无法判断的情况下则头文字大写,其他小写就好。--AT 2021年2月11日 (四) 13:44 (UTC)
意见(▲)同上。--🍫巧克力~✿ 2021年2月12日 (五) 00:38 (UTC)
(▲)同上 Konno Yumeto 恭贺新春 2021年2月12日 (五) 05:15 (UTC)
@AT卡達YumetoSickManWP:以官方发表的名称优先是个很好的方法,但遇到像〈HANN(Alone)〉这样的例子应该如何处理?我这边列出几个官方、Youtube还有几个音源网站。
虽然我有列出官方网站,但符合严格条件的只有〈YESTERDAY LOVE〉〈HANN(Alone)〉,〈you broke me first〉是新闻稿而〈willow〉是官方推特。另外不是许多唱片公司都有作品清单,Youtube遇到没有出MV的歌曲会失去参考价值,音源网站除了Apple比较多元其他都有地区性。 --无心*插柳*柳橙汁 2021年2月12日 (五) 14:12 (UTC)
请问该以哪个官方发表名称为优先度
官方名称\作品名称 you broke me first willow YESTERDAY LOVE HANN (Alone)
官方网站 you broke me first[6] willow[7] YESTERDAY LOVE[8] HANN(Alone)[9]
官方Youtube you broke me first[10] willow[11] YESTERDAY LOVE[12] HANN(Alone)[13]
Apple Music you broke me first[14] willow[15] YESTERDAY LOVE[16] Hann (Alone)[17]
Spotify you broke me first[18] willow[19] 不支援 HANN (Alone)[20]
mora you broke me first[21] willow[22] YESTERDAY LOVE[23] HANN (Alone)[24]
我不清楚韩国是否不会隔空格,否则我认为沿用HANN(Alone)没有什么问题,如果韩国是不会隔空格的话,那可以用HANN (Alone)。--AT 2021年2月12日 (五) 14:21 (UTC)
@Milkypine:容我(...) 吐槽一下,阁下如果是要参阅韩乐相关的话,应该找的会是Genie音乐MelonSoribada英语Soribada等平台吧?--🍫巧克力~✿ 2021年2月12日 (五) 14:23 (UTC):::
@卡達:我没有写Genie、Melon、Soribada、Bug、Flo甚至Gaon是因为《HANN(Alone)》都用韩文表示,而使用韩文肯定不符合,所以我才列出日本。 --无心*插柳*柳橙汁 2021年2月13日 (六) 07:51 (UTC)
我认为这一情况,应该为音乐专辑或歌曲的命名规则订立一个特别的指引。我认为有些特殊情况(例如官方发表的名称是完全细草,而名字空间不支0持小草开头)可以例外,将第一个字改成大草,利用Displaytitle将名称显示为小草。至于以上的命名意见,本人意见同AT。--SickManWP欢迎参与♥️边缘人小组的活动·✏签到发表于 2021年2月12日 (五) 15:01 (UTC)
@SickManWP:介绍一个模板:{{lowercase}}。-hiJK910 七一七二一 2021年2月16日 (二) 18:15 (UTC)
我个人认为命名的次序应该以官方发表的名称优先。在命名此类条目前,需要了解音乐/歌曲的名称是否有背后的意义。以HANN为例,这首单曲的官方名称为全部大草,因此我认为应该以“HANN (Alone)”为条目的名称。至少是否专有名词,我认为音乐类的条目应以特别方式处理,应该视为专有名词。--SickManWP欢迎参与♥️边缘人小组的活动·✏签到发表于 2021年2月11日 (四) 13:47 (UTC)
抱歉,在下比较熟悉古典音乐,对现代音乐不是很了解。窃以为歌曲名称是专有名词,但这种故意写成大写的应该“打回原形”。 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年2月12日 (五) 06:38 (UTC)
当然属于专有名词。这个属于著作人格权,不应该被某些维基的规定覆盖,更没有在此讨论的必要。--E.A.Crowley666✍️ 2021年2月13日 (六) 05:36 (UTC)
某些鬼畜的条目名称可以处理,比如(tItLE,如果真的有人用)但displaytitle必须改--E.A.Crowley666✍️ 2021年2月13日 (六) 05:58 (UTC)
虽然不知道什么是“鬼畜”,但你觉得chAngE行不行?-hiJK910 七一七二一 2021年2月16日 (二) 16:02 (UTC)

音乐条目命名选择方向

按照目前讨论的方向,最后有两个选择,第一“音乐作品不属于专有名词”,第二“命名时已官方名称为优先”,“音乐作品属于专有名词”这个选项应该是不用再出现了,毕竟我们已经从讨论“音乐作品是否属于专有名词”变成讨论“音乐作品命名方针?”,已官方名称为优先刚好可以顺便解决以前的老问题(包括Wikipedia talk:格式手册/标点符号#用浪纹线表示范围Wikipedia_talk:格式手册/标点符号)。鉴于先前我的判断错误,这边我邀请各位在下方表示各自的选择与意见。@Ohtashinichiro和平至上LeehsiaoSanmosaTombus20032000百战天虫Kriz Ju生米一粒Pseudo ClassesKodokunaSmile:@EasterliesAT卡達YumetoSickManWP羊羊32521EdwardAlexanderCrowleyZhaoweizhi0325MoonLight3650HXXXX:@PunkhippieLouis0921geePeace 621WhykittyMoonshimmer93夜来南风起Fake12345TreasureBabe325Hijk910Jacklamf1d14:@Ericliu1912NaveradSoftyuSammypanTw dramaShingkei李新阳CHih-See HsiePv163JoJo_append:@LopullinenAnYiLinYel D'ohanTemp3600Bigbullfrog1996陳寅恪TenhumantenokPrince of EreborK.Y.K.Z.K.Arivgao: --无心*插柳*柳橙汁 2021年2月16日 (二) 14:06 (UTC)

音乐作品不属于专有名词

选择这条后,音乐条目的名称只要不属于专有名词、缩写等条件,就不能使用全大写、全小写等风格样式。这边参照Wikipedia:命名常规#使用外文命名时的专门要求来处理。
  1. (+)支持。 --无心*插柳*柳橙汁 2021年2月15日 (一) 17:36 (UTC)
  2. (+)支持。--Tom......留言) 2021年2月16日 (二) 14:29 (UTC)
  3. 我认为大小写和简繁体类似,更偏向一个名称的两种字体,而非两个不同的名称。就像繁体中文区的事物不强求使用繁体中文命名那样;对于西文字母大小写的问题,中文维基百科有理由使用自己的格式规范。--洛普利宁 2021年2月16日 (二) 16:13 (UTC)
  4. (+)支持。--东风留言) 2021年2月16日 (二) 16:23 (UTC)
  5. (+)支持。--Leehsiao留言) 2021年2月16日 (二) 22:08 (UTC)

命名时以官方名称为优先

选择这条后,音乐条目的名称将根据官方名称命名(但是具体该根据什么的“官方名称”还须另外讨论)。
  1. 支持。—AT 2021年2月16日 (二) 14:23 (UTC)
  2. 支持。-hiJK910 七一七二一 2021年2月16日 (二) 14:32 (UTC)
  3. 支持。--孤山王子查阅马萨布尔之书 2021年2月16日 (二) 15:18 (UTC)
  4. Mısaka Mikoto 悼自由 2021年2月16日 (二) 15:24 (UTC)
  5. 支持。请注意著作人格权在加拿大的案例,连为雕塑绑上红丝带都是侵犯著作人格权,何况是写错名字?须知,一些“现代艺术作品”名字是很重要的。故对所有作品都应尽量保持原文,除非作品名包含不正常的组合(如特殊Unicode、大小写、侮辱性词语)。至于繁简体则视为字体变化,不受约束。--E.A.Crowley666✍️ 2021年2月16日 (二) 15:34 (UTC)
  6. (+)支持,希望能借此解决相关争议,并方便将来创建条目的编者适用(而且尽可能不用动脑,窃以为原方针有点太复杂,涉及太多一层层下来的判断问题)。个人建议直接以作品(专辑或单曲)封面样式优先即可。--Kriz Ju留言) 2021年2月16日 (二) 15:57 (UTC)
  7. 支持。 绀野梦人 恭贺新春 2021年2月16日 (二) 16:01 (UTC)
  8. (+)支持。--SickManWP欢迎参与♥️边缘人小组的活动·✏签到发表于 2021年2月16日 (二) 16:35 (UTC)
  9. (+)支持。--K·Y·K·Z·K 2021年2月16日 (二) 18:02 (UTC)
  10. 参官方网站写法。但有一点要顾虑的是WP:COMMONNAMEWP:名从主人的优先性。SANMOSA SPQR 2021年2月16日 (二) 23:52 (UTC)
  11. (+)支持。--夜来南风起留言) 2021年2月17日 (三) 10:33 (UTC)
  12. (+)支持。--【和平至上】支持通过港区国安法💬 2021年2月17日 (三) 18:28 (UTC)
  13. (+)支持 2021年2月18日 (四) 05:51 (UTC)
  14. (+)支持🍫巧克力~✿ 2021年2月18日 (四) 09:15 (UTC)
  15. (+)支持。-- 天秤P Iūstitia | Spēs

意见

Milkypine意见:我个人选择第一条(音乐作品不属于专有名词)。“官方名称”是个很容统的称呼
  1. 以官方网站为主:并非所有唱片公司都有网站,就算有也不一定都有作品列表,更甚至有已经关门的公司(没错,我就是再说你EMI)
  2. 官方Youtube为主:并非所有官方Youtube都会上传作品,如果遇到没有的作品可能无法适用(不过通常没Youtube也很大机会不符合关注度)
  3. 商业平台为主(这里是指Apple Music、Spotify、Amazon和tower等提供串流与贩卖音乐的平台):平台百百种,该如何抉择?
如果真的选择这条,我希望大家可以想想该使用何者为“官方名称”基准。 --无心*插柳*柳橙汁 2021年2月15日 (一) 17:36 (UTC)
提名musicbrainz,先找官方网站再找元数据。不过我不太清楚哪个网站的元数据靠谱。--E.A.Crowley666✍️ 2021年2月13日 (六) 09:22 (UTC)
我认为像musicbrainz、Discogs这类与维基同样有用户贡献的内容优先度最低,话说不符合三项条件的机会好像也很低...。 --无心*插柳*柳橙汁 2021年2月13日 (六) 11:03 (UTC)
M君上述提出的三点对我而言是杞人忧天。首先,没有官方网站的音乐作品必然占少数,绝大多数的音乐作品也有官方网站,不存在官方名称不明确的问题,也就是说可能产生这类问题的音乐作品只占条目中的极低比重。其次,官方Youtube对我而言也是官方网站的一环,其他平台也一,正常来说如果是官方名称,不同的官方平台也理应一致,就算有差异也只是极少数的情况下才有可能。其三,串流网站确实五花八门,因此我认为这是没有官方平台的时候才应该拿来参考。最后,就因为有些音乐作品可能没有官方平台就要依从命名常规来将其他符合名从主人的名称一并改成符合外文规定的名称是于理不合,这已经是接近原创研究的行为,况且对于那些少数没有任何官方平台的音乐作品,我认为使用最常用名称就好,没必要牵拖有官方名称的音乐作品。以上。—AT 2021年2月16日 (二) 14:34 (UTC)
的确“不存在官方名称不明确的问题”,但如果说要用“官方网站”来举证,许多老歌或是非三大音乐集团的作品很可能没办法。就我上述提到的两首英文歌就是有官方网站但官网并不存在音乐作品的情况(和日韩文歌相比,这两首明显没有作品列表这类明确的官方网站)。
不过这边我应该会等之后确定好再来讨论。 --无心*插柳*柳橙汁 2021年2月16日 (二) 16:41 (UTC)
上面Kriz Ju说得好,看封面不就好了?官方网站只是其中一种举证方法而已。那些老歌或非主流作品没有明确的官方名称的时候,那跟从外文规定当然没有问题。问题就在于当有官方名称的情况下,还要受到外文规定的影响,改到不伦不类的话,那就是本末倒置。很多日韩歌您要是硬把它们改成小写的话,说真的非常奇怪,一来不常用,二来不名从主人,只用外文规定是一种非常差的筛选方式。--AT 2021年2月16日 (二) 17:11 (UTC)
  • 抱歉,在下比较熟悉古典音乐,对现代音乐不是很了解。而据鄙人所知,古典音乐条目或并不存在标题大小写问题,目前也有命名惯例。 ——羊羊 (留言|贡献|维猫报|古典音乐专题) 2021年2月16日 (二) 14:32 (UTC)
    • 日后会把这部分纳入音乐作品命名常规,前提是我们最后真的有生出“音乐作品命名常规”。 --无心*插柳*柳橙汁 2021年2月16日 (二) 16:41 (UTC)

反对依从英维做法。一、英文人跟中文人对英文的看法不一样是很自然。英文人的英文是母语,对其更有规范是自然;对中文人来说是外语,自然会多些玩心。二、就本人活跃的J-POP动画歌曲条目而言,本人编辑时尚未试过对“官方名称”为何有争议。日本人玩英文名称大小写,一直玩得颇为一致。-hiJK910 七一七二一 2021年2月16日 (二) 14:16 (UTC)

没办法(´_ゝ`),命名常规这样写,有这种情况也是在所难免(要怪就怪当时的人,小的我也只是奉命行事)。事实上你看中维的音乐条目,日韩文歌以官方名称为大宗,而英文歌则是按照常规走,甚至目前中维的条规也是如此。 --无心*插柳*柳橙汁 2021年2月16日 (二) 16:41 (UTC)
那你带的讨论方向完全错误,问题是“外文名大小写应否跟随官方”,歌名里面用的字当然会有不是专有的名词啊。-hiJK910 七一七二一 2021年2月16日 (二) 17:08 (UTC)
第二,我认为在“在以某外语(如日文、韩文,甚至中文)处理英文时,‘该语言通常行文的规范’应以该某外语作考虑”。例如在日文歌(或者其他作品名称)以英文作歌名时,‘该语言’指的是日文,在日文中歌名的大小写是怎样,就是怎样;因为“在日文通常行文的规范”中,那东西就是这样表达的。-hiJK910 七一七二一 2021年2月16日 (二) 17:14 (UTC)
@Hijk910:我也说了一开始官方名称不在考虑范围是因为不管官方名称如何都需要依照命名常规。说到底我依照命名常规做事我有理,你们用不成文的规定指责我才该念你们,怎么好像一副我对不起你们的样子。冤有头债有主,不要骂我,骂当初写Wikipedia:命名常规#使用外文命名时的专门要求的人。 --无心*插柳*柳橙汁 2021年2月16日 (二) 17:22 (UTC)
所以我第二句留言你有没有看到?-hiJK910 七一七二一 2021年2月16日 (二) 17:23 (UTC)
你的留言我有看到,但我身为被告也该要解释自己的行为动机,总不能你说我讨论方向完全错误,我就乖乖吞下。 --无心*插柳*柳橙汁 2021年2月16日 (二) 17:30 (UTC)
如果你因为我忽视你的第二句留言感到冒犯,那我这边跟你说声抱歉,我并没有想要忽视,只是对我而言我该为自己辩护。至于详细的内容,则可以等到投票结束后再来讨论。 --无心*插柳*柳橙汁 2021年2月16日 (二) 17:39 (UTC)
我没感到冒犯,还ok。我只是重申,我有理解你的想法了。还有想问问你对我的诠释有何看法。-hiJK910 七一七二一 2021年2月16日 (二) 17:57 (UTC)
另外,谈一点讨论方向的问题。1. “一开始官方名称不在考虑范围”是错误前设,因为命名常规本身是可以改的。定下豁免是其中一个做法。加入诠释(如我对“外文规范”、这个讨论对“专有名词”的理解等等)也是一个做法。2. 我发现很多人(包括我)说“歌名是专有名词”。歌名当然是专有名词,但不是你想讨论的。这是因为我们没有理解到,你是想指出前人定下的规则跟现况有冲突;也是因为你没有在讨论中直接引述原文。这里个个都很忙,没有/不想投入很多时间参与讨论。就我而言,“最想维持原状”“if it ain't broke, don't fix it”“别那么烦”“一切从简”“官方名称也很规范”“韩文大小写不统一跟日文歌名屁事”。大家第一眼看到“歌名不是专有名词”如此白痴的陈述句,也只能反对阁下的提议了,你说是不是?-hiJK910 七一七二一 2021年2月16日 (二) 17:57 (UTC)
你想说的是“若构成非英文区作品名称的英文词语如非专有名词,应跟从‘英文’规范,即(条文说的那样)”,而非“音乐作品不属于专有名词”“命名时以官方名称为优先”就两项简陋的陈述句。顺带一提,再重申,我认为“若构成非英文区作品名称的英文词语如非专有名词,应跟从‘该非英文区使用的语言’规范,即直接跟随官方名称”。-hiJK910 七一七二一 2021年2月16日 (二) 18:06 (UTC)

“名称”是专有名词,属于人、事、物、地所专用的名称。不会因为名称中用了些普通词语,就让名称变成不专有的词语;也不会因为读音相同就用写作所谓规范英文。正如Hunter × Hunter不会因为中间的×不发音,而去删去中间的×。这个讨论完全没有常识。-hiJK910 七一七二一 2021年2月16日 (二) 14:31 (UTC)

  • 我觉得作品名像是书名,属于专有。但我也明白专有名词可能不能统一的问题。--Temp3600留言) 2021年2月16日 (二) 14:47 (UTC)
  • 并不是“使用普通词语,导致变成不专有名词”,而是“他打从一开始就不是专有名词”。所以才要讨论专有名词的范围。 --无心*插柳*柳橙汁 2021年2月16日 (二) 16:41 (UTC)
    就当它不是专有名词,那加一句音乐作品豁免什么的就好了,因噎废食并不可取啊。--AT 2021年2月16日 (二) 17:13 (UTC)

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

总结

经过长久的讨论与一个礼拜的投票,许多维基人皆认为在命名音乐条目时该根据官方名称命名。当然维基并非依据投票数做决定,这边也再次询问支持“音乐作品不属于专有名词”与其他维基人的意见Ohtashinichiro和平至上LeehsiaoSanmosaTombus20032000百战天虫Kriz Ju生米一粒Pseudo ClassesKodokunaSmileEasterliesAT卡达YumetoSickManWP羊羊32521EdwardAlexanderCrowleyZhaoweizhi0325MoonLight3650HXXXXPunkhippieLouis0921geePeace 621WhykittyMoonshimmer93夜来南风起Fake12345TreasureBabe325Hijk910Jacklamf1d14Ericliu1912NaveradSoftyuSammypanTw dramaShingkei李新阳CHih-See HsiePv163JoJo_appendLopullinenAnYiLinYel D'ohanTemp3600Bigbullfrog1996陈寅恪TenhumantenokPrince of EreborK.Y.K.Z.K.ArivgaoGracellleeTjmjKahnballackFredYYooApple v 。如果没有问题,那么将其公示。 --无心*插柳*柳橙汁 2021年3月1日 (一) 18:06 (UTC)

国际关系条目命名常规

先前的社群咨询,现根据在其中所得到的所有合理意见拟定新版国际关系条目命名常规,并拟作方针通过。SANMOSA SPQR 2021年2月8日 (一) 07:41 (UTC)

  • (!)抗议+(-)反对:这不是共识,这是某用户制造出来的所谓“共识”。社群咨询中,明明提议用“—”多于“与”;提议用英文国家名字母顺序多于其他顺序方式,然而该用户一概无视。强烈建议暂缓通过,重新开设投票。-- 约翰同志-条目裱糊匠留言) 2021年2月8日 (一) 11:13 (UTC)
  • 意见大致同上。不建议强行推动修订。—— Eric Liu 创造は生命(留言留名学生会 2021年2月8日 (一) 15:34 (UTC)
@Comrade JohnEricliu1912:前者是我看漏,已更正。后者而言,根据先前的社群咨询的结果,在涉及“中国”与代表“中国”的(历史)政权时,两个主权国家/有限承认国家之间的国际关系的条目的命名排序中,在常用语排序优先以及中文使用惯性的前提下,“中国”与代表“中国”的(历史)政权先行。另外,有用户指出直接明文写明“中国”与代表“中国”的(历史)政权先行会违反避免地域中心方针,因此两个主权国家/有限承认国家之间的国际关系的条目的命名排序难以区分为涉及与不涉及“中国”与代表“中国”的(历史)政权的两种情况处理。考量到在条文实际效果中,如果条目命名上不做到“中国”与代表“中国”的(历史)政权先行,会引来更大规模的社群反对声音,因此我只能作出如此取舍。另一方面,拟议条文是“同等级双边关系中,命名先后顺序按照中文常用语序确定,如无特定中文常用语序则以英文国名字母顺序确定”,考量到在不涉及“中国”与代表“中国”的(历史)政权的情况下,中文一般并无特定常用排列顺序,因此最终的结果也是以英文国名字母顺序确定。综以上,就后者而言,由于实际应用效果相同,我不认为我有错误总结共识。SANMOSA SPQR 2021年2月9日 (二) 00:06 (UTC)
  • 大体上(+)支持,虽然我仍然反对使用不符合中文用语习惯的连接符号,但社群意向如此我也不多说什么。另外,能否对简称的重定向方式进行进一步的规定?如果我没理解错,简称应该重定向至“<国名甲>—<国名乙>关系”为宜。——BlackShadowG留言维基百科20岁生日快乐! 2021年2月14日 (日) 13:16 (UTC)
  • 另,“英文字母顺序”容易引发歧义,比如说美国到底应该用“United States of America”的“U”,还是“America”的“A”?或许应该使用ISO 3166-2的规定。——BlackShadowG留言维基百科20岁生日快乐! 2021年2月14日 (日) 13:24 (UTC)
    • 根据英维做法,美国用“U”。-- 约翰同志-条目裱糊匠留言) 2021年2月14日 (日) 13:50 (UTC)
      • 所以说应该用ISO 3166-2中的规定的代码的顺序,其中美国的代码为“US”。——BlackShadowG留言维基百科20岁生日快乐! 2021年2月14日 (日) 14:57 (UTC)
        • @Comrade JohnBlackShadowG:(1)简称通常应该重定向至“<国名甲>-<国名乙>关系”,但:如条目中国家甲仅涉及一个政权,则重定向至“<国号甲>-<国名乙>关系”,惟如条目中国家乙也仅涉及一个政权,则重定向至“<国号甲>-<国号乙>关系”;如果产生歧义,则作消歧义页面处理。(2)我建议在应用英文字母顺序时参照世界政区索引的排序,有些国家ISO没有收。这好像也是enwiki的办法(?)。(3)另外也请Comrade John回应一下对现案的最新意见,我在2月9日早已进行回应,而且也有ping。SANMOSA SPQR 2021年2月16日 (二) 00:09 (UTC)
  • (离题)话说日本跟北朝鲜没有建交,但条目仍然叫做日本-朝鲜关系,可见现行“-”跟“与”的原创研究区别方法甚至都没能完全实践。—— Eric Liu 创造は生命(留言留名学生会 2021年2月16日 (二) 06:10 (UTC)
  • 英文字母顺序还是不要硬性规定,太多例外,如梵蒂冈,根据圣座“在国际关系中,各国大使不是获梵蒂冈城国而是获圣座所接受;圣座向各国和国际组织派出的外交代表机构或使节,是代表圣座而非所谓梵蒂冈城国。”,所以是用“H”而非“V”。英维大部分通用命名情况是怎样,跟随就是了。-- 约翰同志-条目裱糊匠留言) 2021年2月16日 (二) 08:51 (UTC)
    • @Comrade John:就Holy See那点,我再修改一下。其他情况我认为“其他情况根据编辑者创建的情况‘先到先得’或经包括创建者在内的编辑者讨论达成共识后移动”一条已经包含,就不用再改了。SANMOSA SPQR 2021年2月18日 (四) 01:41 (UTC)
现已无反对意见,依WP:7DAYS公示7日。SANMOSA 誓山海而长在,似日月而无休 2021年2月25日 (四) 02:18 (UTC)
@Comrade JohnEricliu1912:邀请明确意见。个人对“实体名不得使用单字简称”且方针性质倾向反对,中日关系应当改成中国-日本关系吗。其他条款未研究,怀疑是否已有足够共识。--YFdyh000留言) 2021年2月25日 (四) 03:12 (UTC)
@YFdyh000:要移动,移动后原名称要改为消歧义,否则会产生歧义。另外此命名常规意在统一所有两个实体之间的国际关系条目命名,以避免原创研究问题(一些用“-”,一些用“与”,一些用简称,完全没有使用准则,即使有,也是原创研究,而且也没有完全落实执行)。SANMOSA 誓山海而长在,似日月而无休 2021年2月25日 (四) 09:04 (UTC)
(-)倾向反对公示。尽管我个人是赞成移动之后消歧义的,但本地社群的共识似乎并不普遍赞同所谓“实体名不得使用单字简称”的规定,强硬推动并无好处。亦即,多数朋友并不会同意将中日关系移动至中国-日本关系。考虑到常用名称原则,较好的方法应是在中日关系条目直接做消歧义。中日关系悠久,各政权时期皆有其重要性,相信是足以做平等消歧义的。此处顺道提出一个方案,1971年以前与中国建交的国家,其“中某关系”或“中国-某国关系”双边关系条目采用平等消歧义,1971年以后与中国建交的国家,其“中某关系”或“中国-某国关系”双边关系条目则采用主从消歧义,按惯例主为“中华人民共和国”,从为中华民国,兼顾两岸势力消长。—— Eric Liu 创造は生命(留言留名学生会 2021年2月28日 (日) 15:22 (UTC)
@Ericliu1912:我的具体想法是:使用“<国名甲>-<国名乙>关系”的格式命名具体两个国家之间的国际关系条目,条目内容以两国各个时期的关系历史为主;使用“<国号甲>-<国名乙>关系”的格式命名一个国家特定政权甲与另一个国家乙的多个政权之间的国际关系条目,作为甲对外关系史条目的拓展条目。“中某关系”类条目在此规则下通常会演变成三个并立的条目。另一方面,不以简称命名条目的规定也适用于非“中某关系”类条目,如“英美关系”也会更名为“英国-美国关系”。不以简称命名条目的规定意在确立条目命名一致性,使条目命名格式变成只有一种,易于让新用户适从。假设我是一个有志于国际关系条目的新用户,现时的暂行做法很明显会让我不清楚要怎样命名国际关系条目:有些国际关系条目不能用简称,有些国际关系条目能用简称但又不用,有些国际关系条目能用简称而且也用了,我根本不能掌握使用和不使用简称的时机。这和之前Ericliu1912你表示国际关系条目一些用“-”,一些用“与”的使用准则不但是原创研究,而且也没有完全落实执行的情况是完全一致的,我可以断言这两件事是同一个问题。另一方面,不以简称命名条目的规定也意在减少条目命名的地域中心倾向,例如“中朝关系”和“中华人民共和国-朝鲜民主主义人民共和国关系”是完全等同的(朝鲜民主主义人民共和国仅曾与中华人民共和国有邦交),但只有中国大陆的人才会将朝鲜民主主义人民共和国简称为“朝”,中国大陆以外的地方的人只会把朝鲜民主主义人民共和国简称为“北朝鲜”,但条目名称在如此情况下也难以设置转换,结果导致条目命名偏向中国大陆,对中国大陆以外地区的人造成(行文理解上)不友善的情况。拟议版国际关系条目命名常规的大原则是在最大程度上避免地域中心,而且避免地域中心也是中文维基百科极为重要的一个方针,我个人留意到不赞同“实体名不得使用单字简称”的规定的留言都对避免地域中心方针有不同程度的忽视,而且也并非多数意见,根据共识方针,我认为相关意见不应该纳入共识考量。SANMOSA 江南好,风景旧曾谙 2021年3月1日 (一) 06:08 (UTC)

悬挂Blocked user模板之利弊

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

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

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

标记用户页 对于已被永久封禁的用户,请根据以下程序标记此用户的用户页:

  • 若此用户名具有极端侮辱性(比如需要监督),请删除此用户页(如有),并白纸保护此用户页。
  • 其他情况下:
    • 若此用户因滥用傀儡,或被确认为他人的傀儡而被封禁,请以{{sockpuppeteer|blocked}}(对于滥用傀儡的用户)或{{blocked sockpuppet|主帐号}}(对于傀儡帐号)替换原有的用户页内容。
    • 若此用户因其他原因而被封禁,请以{{blocked user}}替换原有的用户页内容。
  • 最后,永久全保护该用户页。
提议条文

标记用户页 对于已被永久封禁的用户,请根据以下程序标记此用户的用户页:

  • 若此用户名具有极端侮辱性(比如需要监督),请务必删除此用户页(如有),并对之进行白纸保护
  • 其他情况下:
    • 若此用户因滥用傀儡或被确认为他人的傀儡而被永久封禁,或在被永久封禁后被查出滥用傀儡或被确认为他人的傀儡,请务必以{{sockpuppeteer|blocked}}(对于滥用傀儡的用户)或{{blocked sockpuppet|主帐号}}(对于傀儡帐号)替换原有的用户页内容(如已创建用户页)或创建用户页(如未创建用户页),并对之进行永久全保护
    • 若此用户因其他原因而被永久封禁:
      • 如此用户已创建用户页,请以{{blocked user}}替换原有的用户页内容,并对之进行永久全保护。
      • 如此用户未创建用户页,请对之进行白纸保护,或以{{blocked user}}创建用户页后对之进行永久全保护。

以上。这比较符合现时的实际使用情况(除了要求必须标记滥用傀儡的用户/傀儡用户一条外,原因是方便查找关连傀儡用户)。SANMOSA SPQR 2021年2月17日 (三) 14:27 (UTC)

支持,因其他原因永封没必要强制都要创建用户页并标记。--Kuailong 2021年2月18日 (四) 18:04 (UTC)
(+)支持-- Sunny00217  2021年2月21日 (日) 13:53 (UTC)
支持。至于提案提到的其他事项,有人愿意推进再说吧。--YFdyh000留言) 2021年2月21日 (日) 14:09 (UTC)
支持,同意,其实我现在基本就是这么操作--浅蓝雪 2021年2月23日 (二) 06:15 (UTC)
(+)支持,很好,很好,很好,很好。凋零铁道运输总署茶室 2021年2月26日 (五) 10:28 (UTC)

维基百科:管理员解任投票潜在漏洞

两个问题。一) 作为弹劾案提案人的资格究竟是自动确认用户还是人事任免投票资格?WP:RFDA/A写的是前者,如此一来是否可以理解为最重要的第一票不需要达到人事任免投票资格,只需自动确认已经可以提出?二) 提案页究竟应该是开始联署就已经建页还是集齐七名连署人,成案后才建页?WP:RFDA/A写的是前者,但社群实际操作多是后者,在互煮集齐七人才建页。以上两个矛盾真正有约束力的方针WP:RFDA本身均没有提及-某人 2021年2月11日 (四) 06:07 (UTC)

  • 抱歉WP:RFDA写的原来都是自动确认已经可以提案,那么又回到我的问题:是否可以理解为最重要的第一票不需要达到人事任免投票资格?-某人 2021年2月11日 (四) 06:10 (UTC)
    Wikipedia:管理员的离任是主页面,里面有写道:“提出:由一名自动确认用户提出…联署:…有投票资格的用户联署”,这个“投票资格”显然是指人事任免票。--安忆Talk 2021年2月11日 (四) 06:22 (UTC)
    “最重要的第一票”前提是“第二步:等待讨论共识;”,所以如果没共识就开案,应该会被雪球关闭。暂不认为已有一定共识时第一票必须符合任免资格,新用户可能更勇于编辑和打破僵局。目前看多是在客栈完成第六步的联署再开案,如有意可提案修改此流程。如果有傀儡用自动确认用户开案,但解任失败,反倒会冻结解任6个月,偷鸡不成蚀把米。--YFdyh000留言) 2021年2月11日 (四) 06:23 (UTC)
    提出存在讨论共识的解任案,不代表提案者肯定具备投票权并计入投票。--YFdyh000留言) 2021年2月11日 (四) 06:34 (UTC)
我的理解是自动确认用户可以提出,但若其不符合人事任免投票资格,则不包括为七人之中;事实上提出的人可以不参与联署,可以当作“第零票”吧。--【和平至上】支持通过港区国安法💬 2021年2月11日 (四) 16:44 (UTC)
我认为和平至上的解读可行。就“提出的人可以不参与联署”的情形,1233曾为之(虽然其具人事任免投票资格)。SANMOSA SPQR 2021年2月12日 (五) 07:12 (UTC)
(!)意见:我觉得是笔误,可以修正,因为自动确认用户是很容易刷自来的。--虫虫飞♡♡→♡℃留言 2021年2月12日 (五) 08:07 (UTC)
  • 那不如提案修正表述,把“一名自动确认用户提名”改成“一名具人事任免投票资格的用户提名”,后跟“共七名符合人事任免资格用户联署”如何?--TP✉️SE🗳️CSCEP 2021年2月14日 (日) 10:40 (UTC)
(✓)同意--虫虫飞♡♡→♡℃留言 2021年2月14日 (日) 13:10 (UTC)
我不认为是笔误,但不反对收紧。SANMOSA SPQR 2021年2月16日 (二) 00:13 (UTC)
我不认为是笔误,在出现明显共识前我不认为需要收紧。--YFdyh000留言) 2021年2月16日 (二) 03:15 (UTC)
  • 提名与联署(票)可分开考虑。--Temp3600留言) 2021年2月16日 (二) 18:47 (UTC)
  • 认同和平至上的方案。自动确认用户可以提案,但若不满足人事任免投票资格则不算联署票。--Wonderwind2002留言) 2021年2月17日 (三) 15:03 (UTC)
(▲)同上支持U:和平至上的意见,将提案资格与投票资格区分开来,不必剥夺自动确认用户的提案资格。若提案人有资格则联署票计7票,无则计6票。(第0票的说法大可不必,着实容易引起误会)--懒癌哪天行Lazy, as no today's excuse. 2021年2月21日 (日) 11:59 (UTC)

Wikipedia:回退功能#移动时不留重定向合并到Wikipedia:重定向#移动时不留重定向

理由如下:

  1. 此权限跟Wikipedia:回退功能没有太大的关连,个人认为纯粹是回退权里包含此权限因此写入此处
  2. 有几率导致像是Wikipedia_talk:重定向#分类重定向的情况

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

WP:回退员重定向到回退功能页面。“如有违反前述原则,当以除权处理。”对方针有意义,需要解决。--YFdyh000留言) 2021年2月11日 (四) 16:12 (UTC)
Suppress redirect 也与反破坏有关,不认为完全无关联。 2021年2月11日 (四) 16:14 (UTC)
因为连巡查员也有-- Sunny00217  2021年2月12日 (五) 06:36 (UTC)
与反破坏有关+1。但若欲改为留下链接,合并重复内文于一处,使未来容易维护,亦无不可。--Hjh474留言) 2021年2月12日 (五) 02:34 (UTC)
现拟议修改WP:重定向WP:回退功能WP:新页面巡查如下:
WP:重定向
现行条文

移动时不留重定向

一般来说,移动页面时,会自动留下重定向。某些用户组(拥有suppressredirect权限的用户)可以通过取消选中标有“保留重定向”的框来阻止创建重定向,称为移动时不留重定向suppressing redirect)。目前,这些群组包括管理员、巡查员、回退员等。在某些情况下,移动页面时自动创建的重定向是不恰当的——例如文章曾被移动破坏至不良标题。不留重定向即可节省移动后删除重定向的时间和麻烦。

一般情况下,重定向是历史纪录中一个有用的条目,所以除非有充分理由移动时不留重定向(例如故意破坏,将放错位置的内容转移到用户空间或释放标题以便另一页面占用),最好将其留下。重定向留下帮助读者找到旧文章一条线索,以防在其先前位置创建新文章,并防止链接失效。因此,我们通常既不移动时不留重定向,也不删除重定向。

提议条文

移动时不留重定向

一般来说,移动页面时,会自动留下重定向。某些用户组(拥有suppressredirect权限的用户)可以通过取消选中标有“保留重定向”的复选框来阻止创建重定向,称为移动时不留重定向suppressing redirect)。目前,这些群组包括管理员、巡查员、回退员等。在某些情况下,移动页面时自动创建的重定向是不恰当的——例如文章曾被移动破坏至不良标题。不留重定向即可节省移动后删除重定向的时间和麻烦。移动而不留重定向依旧会记录在案,不过会加上“不留重定向”的标示。

一般情况下,重定向是历史纪录中一个有用的条目,所以除非有充分理由移动时不留重定向,最好将其留下。重定向留下帮助读者找到旧文章一条线索,以防在其先前位置创建新文章,并防止链接失效。因此,我们通常既不移动时不留重定向,也不删除重定向。

何时可移动而不留重定向 当重定向符合快速删除方针,特别是G3(故意破坏)、O1(应用户要求在该用户空间下移动页面或从该用户空间下将页面移动到主名字空间),或将放错位置的内容转移到用户空间,或须释放标题(腾空页面)以便另一页面占用时候,即可移动而不留重定向。

何时不可移动而不留重定向 用户不得利用权限于命名争议中夺取优势、无视命名争议而使用权限或者将权限用于破坏。巡查员、回退员如有违反前述原则,当以除权处理。

WP:回退功能
现行条文

移动时不留重定向 移动页面时,预设会留下重定向。然而,有时留下重定向会增加后续工作,并不理想,例如回退页面移动破坏,又或者需要腾空页面以便移动其他页面。当拥有“移动时不留重定向”权限时,移动页面时就可以于移动页面界面取消剔选“留下重定向页”框框。如此,就可以移动页面而不留重定向。移动而不留重定向依旧会纪录在案,不过会多一句“不留重定向”。

何时可移动而不留重定向 当重定向符合快速删除方针,特别是G3、O1,即回退移动破坏或应用户要求在该用户空间下移动页面或从该用户空间下将页面移动到主名字空间。

何时不可移动而不留重定向 用户不得利用权限于命名争议中夺取优势、无视命名争议而使用权限或者将权限用于破坏。如有违反前述原则,当以除权处理。

提议条文

移动时不留重定向

WP:新页面巡查
现行条文

移动时不留重定向

移动页面时,预设会留下重定向。然而,有时留下重定向会增加后续工作,并不理想,例如回退页面移动破坏,又或者需要腾空页面以便移动其他页面。当拥有“移动时不留重定向”权限时,移动页面时就可以于移动页面界面取消勾选“留下重定向页”复选框。如此,就可以移动页面而不留重定向。移动而不留重定向依旧会纪录在案,不过会多一句“不留重定向”。巡查员运用此权限时,应遵守回退功能方针相关段落规定。

提议条文

移动时不留重定向

以上。如通过,有关移动时不留重定向权限的规定将统一整合至WP:重定向(包括有关除权规定),而WP:回退功能WP:新页面巡查则只留下章节链接。SANMOSA SPQR 2021年2月18日 (四) 01:15 (UTC)

@Sunny00217YFdyh000Pseudo ClassesHjh474SANMOSA SPQR 2021年2月18日 (四) 01:17 (UTC)
没什么意见。把“纪录”更正“记录”吧。--YFdyh000留言) 2021年2月18日 (四) 01:27 (UTC)
@YFdyh000完成SANMOSA 誓山海而长在,似日月而无休 2021年2月20日 (六) 02:22 (UTC)
@YFdyh000:名词是用“纪录”没错,动词才是“记录”。我改的一处正是本是动词的地方。SANMOSA 誓山海而长在,似日月而无休 2021年2月20日 (六) 02:37 (UTC)
不是名词动词问题吧,纪录用于成绩统计层面(纪录片除外),记录才是文字层面。难道有地区词差异。--YFdyh000留言) 2021年2月20日 (六) 02:51 (UTC)
@YFdyh000《文书处理手册》附录2(第60页)。(意外发现地区词差异)SANMOSA 誓山海而长在,似日月而无休 2021年2月20日 (六) 03:05 (UTC)
有点搞不清,可能需另议或字词转换……在中国大陆,纪录主要是最好成绩或总结归纳,会议记录、历史记录等不会写纪录,个人健康纪录也一般是“个人健康记录”。此博客提到文书所用动词/名词分法,但评论也有不同意见。--YFdyh000留言) 2021年2月20日 (六) 04:11 (UTC)
@YFdyh000:恐怕不能用字词转换处理,因为误转几率太高:有些地方的使用是一样的,但有些地方的使用是完全不同的。《文书处理手册》是台湾官方文件,我给予的链接也是政府网站链接,我认为没办法质疑。繁体来说是会写“会议纪录”、“历史纪录”的(至少前者我非常肯定)。SANMOSA 誓山海而长在,似日月而无休 2021年2月20日 (六) 04:18 (UTC)
指在方针指引页(如Wikipedia:R)转换。浏览器的“历史记录”我是很确定的。--YFdyh000留言) 2021年2月20日 (六) 04:36 (UTC)
(1)问题完全一样,在任何地方转换都会出现一样的问题。(2)科技公司经常会忽略地区用词差异,不能作准。SANMOSA 誓山海而长在,似日月而无休 2021年2月20日 (六) 07:56 (UTC)
你这一“不能作准”,中国大陆所有软件和文献就都是错的了。我非常确定99%+将History称作历史记录,历史纪录是Best record。在此题中讨论可能不大合适。--YFdyh000留言) 2021年2月20日 (六) 08:06 (UTC)
@YFdyh000:至少在繁体不能作准吧。如果是中国大陆公司开发的browser,在中国大陆简体下反而是可以作准的。如果没其他问题的话,我就不再修改提案了。SANMOSA 誓山海而长在,似日月而无休 2021年2月20日 (六) 13:57 (UTC)
代为标示{{新增条文}},请帮确认有无错漏。--Hjh474留言) 2021年2月18日 (四) 02:17 (UTC)
{{删除条文}}也加上了。SANMOSA SPQR 2021年2月18日 (四) 02:26 (UTC)
原来巡查权那里也有一段-- Sunny00217  2021年2月18日 (四) 03:10 (UTC)
是不是需要公示贴公告板?--Hjh474留言) 2021年2月26日 (五) 02:46 (UTC)
@Hjh474:你是不是忘了WP:7DAYSSANMOSA 江南好,风景旧曾谙 2021年3月1日 (一) 10:25 (UTC)
👍。--Hjh474留言) 2021年3月1日 (一) 10:29 (UTC)

用户名修改与订阅

注意到@BureibuNeko的用户名修改后订阅列表12没有更新,是否需要为此修改相关方针?--E.A.Crowley666✍️ 2021年2月13日 (六) 03:41 (UTC)

修正WP:PB条文内容

通过。SANMOSA 江南好,风景旧曾谙 2021年2月28日 (日) 05:37 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

现行条文

维基百科应该中立地表述现实,对于台湾海峡两岸复杂的政治关系争议,维基百科不应预设任何政治立场。除了专有名词、引录人物原话、文件原文、机构标准名称等既有内容之外,为避免使用法理论述所形成的中立性问题,编者应以事实论述为基础,表述两岸四地所涉及的复杂情况。关于具体词语用法,请见Wikipedia:格式手册/两岸四地用语

提议条文

维基百科应该中立地表述现实,对于台湾海峡两岸复杂的政治关系争议及朝鲜半岛南北关系复杂的政治关系与争议,维基百科不应预设任何政治立场。除了专有名词、引录人物原话、文件原文、机构标准名称等既有内容之外,为避免使用法理论述所形成的中立性问题,编者应以事实论述为基础,表述两岸四地及朝鲜半岛南北政权所分别涉及的复杂情况。关于具体词语用法,请见Wikipedia:格式手册/两岸四地用语Wikipedia:格式手册/朝鲜半岛用语

基于MOS:COR条文已经妥善,针对涉及到的WP:PB进行事实性修改。--🍫巧克力~✿ 2021年2月14日 (日) 11:22 (UTC)

  • 不要在方针正文用简写?--Temp3600留言) 2021年2月15日 (一) 02:49 (UTC)
  • @Temp3600:已将捷径修正为完整的名称。--🍫巧克力~✿ 2021年2月15日 (一) 07:03 (UTC)
我认为用词可以再调整一下,如下:
现行条文

维基百科应该中立地表述现实,对于台湾海峡两岸复杂的政治关系及争议,维基百科不应预设任何政治立场。除了专有名词、引录人物原话、文件原文、机构标准名称等既有内容之外,为避免使用法理论述所形成的中立性问题,编者应以事实论述为基础,表述两岸四地所涉及的复杂情况。关于具体词语用法,请见Wikipedia:格式手册/两岸四地用语

提议条文

维基百科应该中立地表述现实,对于台湾海峡两岸、朝鲜半岛南北关系等复杂的政治关系及争议,维基百科不应预设任何政治立场。除了专有名词、引录人物原话、文件原文、机构标准名称等既有内容之外,为避免使用法理论述所形成的中立性问题,编者应以事实论述为基础,表述两岸四地、朝鲜半岛南北政权等所分别涉及的复杂情况。关于具体词语用法,请见Wikipedia:格式手册/两岸四地用语Wikipedia:格式手册/朝鲜半岛用语

以上。SANMOSA SPQR 2021年2月16日 (二) 00:12 (UTC)

  • (:)回应@Sanmosa:这是针对羊羊君所提列的那些议题所做出的小改动吧?--🍫巧克力~✿ 2021年2月16日 (二) 02:28 (UTC)
    加入“等”字来说,是的。另一方面是希望用词更为简洁。SANMOSA SPQR 2021年2月16日 (二) 02:43 (UTC)

若无特别意见,现按Sanmosa所提出的版本进行 公示,时间至2021年2月27日07:50 (UTC)止。--🍫巧克力~✿ 2021年2月20日 (六) 07:51 (UTC)


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

(续)现行日期和数字格式手册条文调适

承前讨论,现拟对WP:格式手册/日期和数字修改如下:

现行条文

数字 (略)

物理量量值的书写 物理量量值必须使用阿拉伯数字,并正确使用法定计量单位。例如:一百五十平方米应写作150平方米或150 m2

(略)

一般量词前的数值 一般量词前面的数字应该使用阿拉伯数字,不应使用汉字表示:

*正确:11个月、50岁、200人、1000名
  • 错误:十一个月、五十岁、两百人、一千名

(略)

金钱单位前的数字 非物理量值的单位应该使用阿拉伯数字。例如:20元、10.1万元、300美元、290亿英镑等。

整数一至十的书写 一至十的整数如果不是出现在具有统计意义的一组数字中,则汉字、阿拉伯数字都可使用,但应保持上下文局部体例一致,例如:一个人、三本书、读了十遍、5个百分点。

*正确:这个地区的高等学校有新闻系6个、新闻专业科系7个
  • 错误:这个地区的高等学校有新闻系6个、新闻专业科系七个

多位数字的分节 对于多位数字的,应该适当分节,以助于读者理解。分节时可使用撇节法划分。

三位撇节法对于小数点前或后超过四位的数,从小数点起,向左和向右每三位数字一组,组间空四分之一个汉字(二分之一个阿拉伯数字)的位置,或以“,”(半角逗号)按千分节,例如:123,456.0789。纯小数通常不省略个位数的“0”,例如:“0.46”而非“.46”。

中文的四位撇节法运用“万”、“亿”两个单位,与阿拉伯数字混用时也可轻易理解,例如:11,3368,2501,意为“11亿3368万2501”;3,4500,0000,意为“三亿四千五百万”,也可写成“3.45亿”、“3,4500万”,但一般不写作“3亿4千5百万”。

提议条文

数字 整数一至十的书写 一至十的整数如果不是出现在具有统计意义的一组数字中,则汉字、阿拉伯数字都可使用,例如:一个人、三本书、读了十遍、5个百分点。

*正确:这个地区的高等学校有新闻系6个、新闻专业科系7个
  • 错误:这个地区的高等学校有新闻系6个、新闻专业科系七个

为保持上下文局部体例一致,若两组或多组数据并列,则必须统一格式。若其中至少一组数据被本指引禁止使用某种格式,则其他与之并列者亦不可使用。

(略)

物理量量值的书写 物理量量值必须使用阿拉伯数字,并正确使用法定计量单位,惟在无关科学的条目中,符合“整数一至十的书写”的规定者例外。例如:一百五十平方米应写作150平方米或150 m2

(略)

一般量词前的数值 一般量词前面的数字应该使用阿拉伯数字,不应使用汉字表示,惟符合“整数一至十的书写”的规定者例外:

*正确:200人、1000名、5000年
  • 错误:两百人、一千名、五千年

“万X”、“亿X”等104的倍数级的中文数字量值当成单位的一部分。

(略)

金钱单位前的数字 非物理量值的单位应该使用阿拉伯数字,惟符合“整数一至十的书写”的规定者例外。例如:20元、10.1万元、300美元、290亿英镑等。

多位数字的分节 对于多位数字的,应该适当分节,以助于读者理解。分节时可使用撇节法划分。

三位撇节法对于小数点前或后超过四位的数,从小数点起,向左和向右每三位数字一组,组间空四分之一个汉字(二分之一个阿拉伯数字)的位置,或以“,”(半角逗号)按千分节,例如:123,456.0789。纯小数通常不省略个位数的“0”,例如:“0.46”而非“.46”。

中文的四位撇节法运用“万”、“亿”两个单位,与阿拉伯数字混用时也可轻易理解,例如:11,3368,2501,意为“11亿3368万2501”;3,4500,0000,意为“三亿四千五百万”,也可写成“3.45亿”、“3亿4500万”,但一般不写作“3亿4千5百万”。四位撇节法不在科学相关条目中使用。

只有四位或五位的阿拉伯数字可不进行分节。

以上。SANMOSA SPQR 2021年2月16日 (二) 03:19 (UTC)

“7.2 整数一至十,如果不是出现在具有统计意义的一组数字中,可以用汉字,但要照顾到上下文,求得局部体例上的一致。”中华人民共和国国家标准出版物上数字用法的规定(节录自香港大学中文教育网)我知道已经有相关段落,但建议将该段置上,或在各段简单说明一至十的例外。--LuciferianThomas留言 2021年2月17日 (三) 00:01 (UTC)
@LuciferianThomas:原案标记错误,已更正为“符合‘整数一至十的书写’的规定者例外”。已调整排版。SANMOSA SPQR 2021年2月17日 (三) 14:07 (UTC)
另外,此案的一个可行变体为“整数一至十的书写”扩为“整数一至一百的书写”。SANMOSA SPQR 2021年2月17日 (三) 14:11 (UTC)
变体也写一次好了:
现行条文

数字 (略)

物理量量值的书写 物理量量值必须使用阿拉伯数字,并正确使用法定计量单位。例如:一百五十平方米应写作150平方米或150 m2

(略)

一般量词前的数值 一般量词前面的数字应该使用阿拉伯数字,不应使用汉字表示:

*正确:11个月、50岁、200人、1000名
  • 错误:十一个月、五十岁、两百人、一千名

(略)

金钱单位前的数字 非物理量值的单位应该使用阿拉伯数字。例如:20元、10.1万元、300美元、290亿英镑等。

整数一至十的书写 一至十的整数如果不是出现在具有统计意义的一组数字中,则汉字、阿拉伯数字都可使用,但应保持上下文局部体例一致,例如:一个人、三本书、读了十遍、5个百分点。

*正确:这个地区的高等学校有新闻系6个、新闻专业科系7个
  • 错误:这个地区的高等学校有新闻系6个、新闻专业科系七个

多位数字的分节 对于多位数字的,应该适当分节,以助于读者理解。分节时可使用撇节法划分。

三位撇节法对于小数点前或后超过四位的数,从小数点起,向左和向右每三位数字一组,组间空四分之一个汉字(二分之一个阿拉伯数字)的位置,或以“,”(半角逗号)按千分节,例如:123,456.0789。纯小数通常不省略个位数的“0”,例如:“0.46”而非“.46”。

中文的四位撇节法运用“万”、“亿”两个单位,与阿拉伯数字混用时也可轻易理解,例如:11,3368,2501,意为“11亿3368万2501”;3,4500,0000,意为“三亿四千五百万”,也可写成“3.45亿”、“3,4500万”,但一般不写作“3亿4千5百万”。

提议条文

数字 整数一至一百的书写 一至一百的整数如果不是出现在具有统计意义的一组数字中,则汉字、阿拉伯数字都可使用,例如:三个人、四十岁、读了50遍、75个百分点。

*正确:这个地区的高等学校有新闻系6个、新闻专业科系7个
  • 错误:这个地区的高等学校有新闻系6个、新闻专业科系七个

为保持上下文局部体例一致,若两组或多组数据并列,则必须统一格式。若其中至少一组数据被本指引禁止使用某种格式,则其他与之并列者亦不可使用。

(略)

物理量量值的书写 物理量量值必须使用阿拉伯数字,并正确使用法定计量单位,惟在无关科学的条目中,符合“整数一至一百的书写”的规定者例外。例如:一百五十平方米应写作150平方米或150 m2

(略)

一般量词前的数值 一般量词前面的数字应该使用阿拉伯数字,不应使用汉字表示,惟符合“整数一至一百的书写”的规定者例外:

*正确:200人、1000名、5000年
  • 错误:两百人、一千名、五千年

“万X”、“亿X”等104的倍数级的中文数字量值当成单位的一部分。

(略)

金钱单位前的数字 非物理量值的单位应该使用阿拉伯数字,惟符合“整数一至一百的书写”的规定者例外。例如:20元、10.1万元、300美元、290亿英镑等。

多位数字的分节 对于多位数字的,应该适当分节,以助于读者理解。分节时可使用撇节法划分。

三位撇节法对于小数点前或后超过四位的数,从小数点起,向左和向右每三位数字一组,组间空四分之一个汉字(二分之一个阿拉伯数字)的位置,或以“,”(半角逗号)按千分节,例如:123,456.0789。纯小数通常不省略个位数的“0”,例如:“0.46”而非“.46”。

中文的四位撇节法运用“万”、“亿”两个单位,与阿拉伯数字混用时也可轻易理解,例如:11,3368,2501,意为“11亿3368万2501”;3,4500,0000,意为“三亿四千五百万”,也可写成“3.45亿”、“3亿4500万”,但一般不写作“3亿4千5百万”。四位撇节法不在科学相关条目中使用。

只有四位或五位的阿拉伯数字可不进行分节。

以上。SANMOSA 誓山海而长在,似日月而无休 2021年2月19日 (五) 02:40 (UTC)

@LuciferianThomasYangwenbo99CwekLopullinen:想看看大家比较倾向我原本的提案还是变体版本。SANMOSA 誓山海而长在,似日月而无休 2021年2月21日 (日) 08:57 (UTC)
倾向后者。另建议“中文的四位撇节法”不在科技条目中使用。——Yangwenbo99 2021年2月22日 (一) 13:05 (UTC)
补充了。SANMOSA 誓山海而长在,似日月而无休 2021年2月22日 (一) 13:57 (UTC)

Wikipedia:格式手册/标点符号#冒号增订

打算增加“同一句子当中应避免使用多个冒号”、“冒号提示的范围不应过窄或过宽”作为注意事项,希望进一步讨论。具体例子后补。--Bookwith留言) 2021年2月20日 (六) 06:15 (UTC)

他认为:建筑工程一再拖延的原因有两个:管理不妥和人手不足。
他认为,建筑工程一再拖延的原因有两个:管理不妥和人手不足。
举例“同一句子当中应避免使用多个冒号”。--Bookwith留言) 2021年2月23日 (二) 06:58 (UTC)
几乎没人愿意参与格式手册修订的讨论。--Bookwith留言) 2021年2月23日 (二) 07:00 (UTC)
我觉得单纯是你例子太晚提出导致很多人不知道你要干嘛而已。 --无心*插柳*柳橙汁 2021年2月23日 (二) 13:24 (UTC)
(▲)同上。我想知道错例在实务中是否常见(例如1个月内>3次),不存在则WP:豆子。--YFdyh000留言) 2021年2月23日 (二) 13:33 (UTC)
@BookwithSANMOSA 江南好,风景旧曾谙 2021年3月1日 (一) 10:37 (UTC)

修订维基百科:关注度 (人物)

删除注1。Fire Ice 2021年2月20日 (六) 16:36 (UTC)

再加码,删除“尽管维基不是纸本出版物,这里还是有一些收录的标准。”,删除“维基百科收录包括重要的历史人物和卷进时事的人的条目。”里的“包括”二字,都是无意义的东西。Fire Ice 2021年2月20日 (六) 16:49 (UTC)

再加码,“其他测试”一节实际毫无意义,建议整节删除。Fire Ice 2021年2月20日 (六) 16:50 (UTC)

  • 干脆这样吧:
现行条文

跟任何百科全书一样,维基百科收录包括重要的历史人物和卷进时事的人的条目。尽管维基不是纸本出版物,这里还是有一些收录的标准。除了此指引,也可以参见《关注度[注 1],该处有一个普遍及通用的收录标准。特别地,运动员的关注度应优先考虑《运动员关注度指引》,学者的关注度应优先考虑《学者关注度指引》。 …… 其他测试

以下方法也可以用来测试某人物是否值得收录于百科全书:

  • 大学教授测试:他是否比一个普通大学教授更广为人知,或出版了更多的书籍?
  • 确证测试:现在或十年以后,条目中的所有资料还可以被独立确证吗?
  • 条目长短:有没有可能加长至超过小作品?有没有可能写成完美条目
  • 百年测试:一百年后,除了当事人的亲戚,还会否有人对他感兴趣?
  • 不是自传:是当事人或当事人近亲以外的人写的吗?
  • Google测试:在Google或其他主要搜索引擎中是否有很多有关的条目?
  • 检查虚构情节:编写虚构人物角色条目时,请务必阅读本忠告。

参见

提议条文

跟任何百科全书一样,维基百科可能收录重要的历史人物和卷进时事的人的条目。关注度决定了一个主题是否有编写独立条目介绍的必要。如果某个人物满足以下任一条件,则可假定该人物符合独立条目的收录标准:

…… 参见

以下方法也可以用来测试某人物是否值得收录于百科全书,但注意它们并非本指引的一部分,不能取代上面的收录标准。

  • 大学教授测试:他是否比一个普通大学教授更广为人知,或出版了更多的书籍?
  • 确证测试:现在或十年以后,条目中的所有资料还可以被独立确证吗?
  • 条目长短:有没有可能加长至超过小作品?有没有可能写成完美条目
  • 百年测试:一百年后,除了当事人的亲戚,还会否有人对他感兴趣?
  • 不是自传:是当事人或当事人近亲以外的人写的吗?
  • Google测试:在Google或其他主要搜索引擎中是否有很多有关的条目?
  • 检查虚构情节:编写虚构人物角色条目时,请务必阅读本忠告。

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

我修了一下。Fire Ice 2021年2月20日 (六) 17:08 (UTC)
(+)支持SANMOSA 誓山海而长在,似日月而无休 2021年2月21日 (日) 02:54 (UTC)
(+)支持:修订版更清晰,这是属于事实性修订,可以在存档后直接修改。--虫虫飞♡♡→♡℃留言 2021年2月21日 (日) 03:57 (UTC)
(+)支持,并做了部分语句修改。--痛心疾首 2021年2月21日 (日) 07:43 (UTC)
(+)支持。 --无心*插柳*柳橙汁 2021年2月23日 (二) 13:22 (UTC)
(-)反对前面的修改可以认同,其他测试那一部分,在下建议创建为参见部分的三级标题。(修改后请通知我改票。)--懒癌哪天行Lazy, as no today's excuse. 2021年2月25日 (四) 08:18 (UTC)
“其他测试”到底有什么意义,为什么不能干脆删了算了。Fire Ice 2021年2月25日 (四) 08:32 (UTC)
@LantxSANMOSA 誓山海而长在,似日月而无休 2021年2月25日 (四) 10:58 (UTC)
@Fire-and-Ice:您也并未删除整节内容呀?与其问在下,不如您先回答一下,为何您要放到参见部分?--懒癌哪天行Lazy, as no today's excuse. 2021年2月25日 (四) 14:38 (UTC)
@GZWDer放到参见部分的。至于参见下搞三级标题,我只能说闻所未闻了。Fire Ice 2021年2月25日 (四) 16:01 (UTC)
在下反对删除其他测试部分,理由:方针是给人读的,多一些能让更多人理解的内容有益处。--懒癌哪天行Lazy, as no today's excuse. 2021年2月28日 (日) 06:23 (UTC)
未见能让更多人理解,反而偏离了主题。Fire Ice 2021年2月28日 (日) 12:58 (UTC)

拟议快速删除方针条文增修(A部分)

由于依WP:R#DELETE第11款(带有“(消歧义)”字样,且无链入的重定向)走AFD程序提删的重定向基本上都会被删除,因此为加快相关重定向的删除处理程序,现拟议在WP:快速删除方针增加以下一条:

如上述修订获通过,将会连带修订WP:重定向如下:

以上。SANMOSA 誓山海而长在,似日月而无休 2021年2月21日 (日) 05:22 (UTC)

请勿将拟议快速删除方针条文增修的其他部分与此部分合并,以免讨论失焦。SANMOSA 誓山海而长在,似日月而无休 2021年2月21日 (日) 05:30 (UTC)
怎么避免消歧义页改成重定向然后速删。比如限定存在已超过1年的重定向?--YFdyh000留言) 2021年2月21日 (日) 05:32 (UTC)
@YFdyh000:拟议条文仅处理带有“(消歧义)”字样的重定向。带有“(消歧义)”字样的重定向通常不会重定向至非消歧义页面。如果是使用平等消歧义抑或主题目消歧义的争议,依拟议条文,应交由存废讨论处理。SANMOSA 誓山海而长在,似日月而无休 2021年2月21日 (日) 05:41 (UTC)
按新增条文,我可以将主题目消歧义的消歧义页改成重定向页(如重定向回主条目)、取消链入、改为顶注消歧义(或者单纯反对而不作任何消歧义),然后悄然请求速删其他人创建的消歧义页面,期间创建人可以不知情。我很好奇“(消歧义)”字样的重定向的成因,似应避免,或者不管、保留。--YFdyh000留言) 2021年2月21日 (日) 05:53 (UTC)
@YFdyh000:“改为顶注消歧义”仍是“应使用平等消歧义抑或主题目消歧义存在未解决的争议”的情况(顶注消歧义为主题目消歧义的一种),依原提议条文,仍应交由存废讨论处理。就“单纯反对而不作任何消歧义”一点,我已再更新提议条文,现提议条文在“单纯反对而不作任何消歧义”的情况下应交由存废讨论处理。SANMOSA 誓山海而长在,似日月而无休 2021年2月21日 (日) 06:05 (UTC)
(-)反对 没有什么价值,只是存不存在罢了-- Sunny00217  2021年2月21日 (日) 13:52 (UTC)
@Sunny00217:请你详细解释一下你的理由。我是想说,如果最后的结果必然是删除,那根据WP:SNOW的思想,应该加快此类提删的删除程序。SANMOSA 誓山海而长在,似日月而无休 2021年2月21日 (日) 23:42 (UTC)
你可以把我这张票视作无效反对票就是了,基本上个人认为这种提案没有什么必要-- Sunny00217  2021年2月22日 (一) 09:48 (UTC)
不是“清除”链入,已改为“清理”。 2021年2月26日 (五) 12:57 (UTC)

拟议快速删除方针条文增修(B部分)

现拟议修改快速删除方针A2与A6条文如下:

以上。SANMOSA 誓山海而长在,似日月而无休 2021年2月21日 (日) 05:38 (UTC)

请勿将拟议快速删除方针条文增修的其他部分与此部分合并,以免讨论失焦。SANMOSA 誓山海而长在,似日月而无休 2021年2月21日 (日) 05:43 (UTC)
增加“若条目内的模板包括资讯框,且资讯框在不包含其预设字段名称的情况下仍有内容,则亦不适用”的原因是资讯框通常具百科性内容。其他部分的修改原因是促进草稿化。SANMOSA 誓山海而长在,似日月而无休 2021年2月21日 (日) 05:46 (UTC)
@PoemSANMOSA 誓山海而长在,似日月而无休 2021年2月21日 (日) 05:48 (UTC)
inuse的部分我认为没必要,按常识按需移除即可,{{inuse|2年}}不适用吗。“有内容”可能非常宽泛,标点和胡言乱语都是内容,不过我还没想到更好表述。A6同上。因此,我不认为有必要修订。--YFdyh000留言) 2021年2月21日 (日) 06:00 (UTC)
@YFdyh000:就“若条目内的模板包括资讯框,且资讯框在不包含其预设字段名称的情况下仍有内容,则亦不适用”来说,你说的情况并不常见(而且可以用A1处理),大多数情况是确有有意义内容,这种情况下不应删除,但我更改一下表达方式。后一点我开放讨论,因为这个提议是照抄旧提议的。SANMOSA 誓山海而长在,似日月而无休 2021年2月21日 (日) 06:12 (UTC)
  • 摘下inuse再提删就行。--Temp3600留言) 2021年2月21日 (日) 14:31 (UTC)
@Temp3600:不排除有诱发编辑战的可能性。SANMOSA 誓山海而长在,似日月而无休 2021年2月21日 (日) 23:44 (UTC)
(※)注意
  1. 用户经常只加了模板及讯息框后后,就一走了之,这些只有模板及讯息框的条目严重影响条目质素,也影响维基的声誉,让外界看到维基的条目只有模板及讯息框。
  2. A6现行条文已经很清晰,用户及管理员也会根据常识判断。
以上。--虫虫飞♡♡→♡℃留言 2021年2月22日 (一) 04:47 (UTC)
(1)一来这条文修改其实是为了促进草稿化,巡查员看到自然懂得怎么样去处理,不要说的像所有巡查员都死了一般。二来中文维基百科品质低下的条目多的是,有些条目的字数只是刚好过50,我看它们的品质跟只有Infobox的条目差不多。(2)这一点我开放讨论,因为这个提议是照抄旧提议的。SANMOSA 誓山海而长在,似日月而无休 2021年2月22日 (一) 12:29 (UTC)
(?)疑问:现行方针下,您要“促进草稿化”,就做不到吗?您可以把符合A2的条目,以移动到草稿的方式去替代提速删,没必要改方针。--虫虫飞♡♡→♡℃留言 2021年2月24日 (三) 12:40 (UTC)
我现在又不是巡查员,所以我能做的东西很少,我总不可能整天盯着Category:快速删除候选吧。那如果我要想办法提醒巡查员的话,最好的办法就是从方针层面提醒,让他们挂A2的诱因减少,草稿化的诱因增加。SANMOSA 誓山海而长在,似日月而无休 2021年2月25日 (四) 02:23 (UTC)
(&)建议:这种常识性的东西,我不认为巡查员会不懂,如果不懂,您改了方针,也不会立刻懂了。建议您可以直接走去巡查员用户讨论页建议,这比您改方针的方式来得有效。--虫虫飞♡♡→♡℃留言 2021年2月25日 (四) 03:52 (UTC)
我不认为草稿化是“常识性的东西”。SANMOSA 誓山海而长在,似日月而无休 2021年2月25日 (四) 09:08 (UTC)
  • 请您论述提案解决了什么问题?现行机制是否无法解决您提到的问题?--虫虫飞♡♡→♡℃留言 2021年2月28日 (日) 02:17 (UTC)
我在2021年2月22日 (一) 12:29 (UTC)的留言中的(1)中的“二来”有说明修订条文后资讯框预设字段名称以外的内容视为条目本身的内容,实际上避免了只有已填写有意义的百科性内容的资讯框的条目被删除,让该等条目有机会被改写出文字段落叙述。SANMOSA 江南好,风景旧曾谙 2021年2月28日 (日) 10:51 (UTC)

拟议快速删除方针条文增修(C部分)

这个其实不太像是拟议条文增修,我这里想提议的是容许bot自动处理以CSD O4CSD O7CSD F7等几条为理由的快速删除请求,但为有效减低错误删除的可能性,自动挂模板和自动进行删除的动作必须分开,而且要间隔足够的时间。SANMOSA 誓山海而长在,似日月而无休 2021年2月21日 (日) 06:32 (UTC)

站务有这个需求吗。担心被破坏者利用。--YFdyh000留言) 2021年2月21日 (日) 07:48 (UTC)
不清楚。可能需要一些数据,还有社群的看法。CSD F7被破坏者利用的可能性不太大。SANMOSA 誓山海而长在,似日月而无休 2021年2月21日 (日) 08:54 (UTC)
F7不清楚,O7对保留派维基人来说可能是不建议用的。O4会被利用,见童孝贤对话页 | 用户贡献)。如果没有严重积压,不认为有必要引入机器人。如果机器人运转良好,也未见需要对方针有所修订。--YFdyh000留言) 2021年2月21日 (日) 09:02 (UTC)
先放着,看看其他人的意见。O7被删除的草稿我没见过几个人管(除删除外)。SANMOSA 誓山海而长在,似日月而无休 2021年2月21日 (日) 09:53 (UTC)
(※)注意
  1. 有时用户不懂得加分类重定向,机器人会以O4提删,管理员要手动加“分类重定向模板”,才能解决机器人反复提删分类重定向;而且之前机器人失灵,把已经放了分类重定向模板的页面也提删,因此必须有管理员判断。
  2. O7的页面可以WP:AR还原,如果机器人自动删除,但令WP:AR出现问题。
  3. 方针规定提删和删除必须两个用户,因此同一个机器人去提删及删除,又会与方针抵触。
  4. 有时用户会把合理使用的文件转载到共享,但原文件不能F7删去。
  5. 之前已经有很多机器人失灵,如果让机器人自动删除,风险很大。
以上。--虫虫飞♡♡→♡℃留言 2021年2月22日 (一) 04:39 (UTC)
@蟲蟲飛:(1)这应该是改善bot检测设置的问题,而且上面我也提到自动挂模板和自动进行删除的动作必须分开,而且要间隔足够的时间,因此管理员应该是有时间检查的。不过也考虑到YFdyh000上面的意见,这点我是开放讨论的。(2)技术上没有这个可能性。bot检测的是最近6个月内是否有编辑,如果最近6个月内完全没有编辑,bot才会挂模板,bot是不会理会最近6个月内的编辑是小修小补充还是大修改的,基本上一恢复页面,并回退挂模板操作,就已经算是一次编辑,对bot而言最近6个月内的编辑就需要重算。(3)zhwiki早已开了大量的bot,另开一个abot或者改用另一个已有的bot不是难事(Jimmy-bot和Jimmy-abot就是两个不同的bot)。(4)正如我上面提到,自动挂模板和自动进行删除的动作必须分开,而且要间隔足够的时间,因此只要设置的间隔时间合理,这问题并不大。(5)bot的运行状况我建议让bot的主人自己解释,@Jimmy XuSANMOSA 誓山海而长在,似日月而无休 2021年2月22日 (一) 12:18 (UTC)
  • Jimmy-bot算是现时技术最强的机器人,除了Jimmy-bot,还有其他机器能做到删除工作吗?如果没有,就是同一个机器人同时进行提删及删除。此外,同一个主人的机器人,只能算一个用户。--虫虫飞♡♡→♡℃留言 2021年2月22日 (一) 12:23 (UTC)
@蟲蟲飛Jimmy-bot是做不到删除工作的,它没有管理员权限,Jimmy-abot才有。理论上所有具有管理员权限的bot都能进行删除工作,而本地除了Jimmy-abot以外,具有管理员权限的bot(也就是abot)至少还有Xiplus-abot一个。SANMOSA 誓山海而长在,似日月而无休 2021年2月22日 (一) 12:42 (UTC)
  • 对,Jimmy-abot才有管理员权限,但两个机器人的主人都是Jimmy,因此只能视为一个用户。--虫虫飞♡♡→♡℃留言 2021年2月22日 (一) 12:46 (UTC)
所以我才把Xiplus-abot找出来啊,Jimmy Xu跟Xiplus总是两个人吧。SANMOSA 誓山海而长在,似日月而无休 2021年2月22日 (一) 12:49 (UTC)
我也ping一下新提到的当事人好了:@XiplusSANMOSA 誓山海而长在,似日月而无休 2021年2月22日 (一) 12:44 (UTC)
1. 挂模板和删除分开的逻辑很怪,假设A机器人的判断标准比B机器人还准确,那么为何不能修改B使其跟A一样好呢?如果A跟B判断标准一样好,那么无论是用1个还是多个机器人准确率都不会改变。 2. 留待人类检查的问题,如果你们觉得需要人类检查,那么就应该直接让人类做最终决策(删除),而不是确认完了又放着,也会有没有管理员复查到的问题。 3. 自提自删的问题,如果机器人做得够好,那么修改方针给予机器人豁免不就好了,死抱着规则可是不好的唷^.<。 4. 总之提案的重点应该是找到一个妥善处理速删的流程,并将其转换为程式码,如果机器人做得到就应该让机器人做,而不是让管理员表现得跟机器人一样。--Xiplus#Talk 2021年2月22日 (一) 13:34 (UTC)
(1)我说“挂模板和删除分开”的最主要原因并不是准确度或需要人类检查的问题,而是被告知者来不来得及反应的问题,我们还是要给一下反应时间,这也是为何提交快速删除请求以后通常要通知创建页面者。就说O7好了,废弃6个月的草稿,如果创建者在那时候突然想再用草稿,他还是有时间直接把快速删除模板移除掉,然后继续编修草稿。WP:AR不是不方便,但不代表就必须走一次AR程序。(2)我是觉得上面三种(其实还有其他另外几种)不太需要人类检查,不然我也不会提议用bot处理,所以我认同你的观点。(3)我本来也是想说豁免就好了,但我又怕虫虫飞之后又会像之前一样再度使对话陷入无限鬼打墙循环,所以我就先避开了,当然我个人不反对豁免。另一方面是Jimmy Xu通常不太现身,所以即使不考虑避嫌的问题,找你的话增加bot任务的事情还是能处理的比较快一些。(4)认同你的观点。SANMOSA 誓山海而长在,似日月而无休 2021年2月22日 (一) 14:06 (UTC)
@XiplusSANMOSA 誓山海而长在,似日月而无休 2021年2月22日 (一) 14:09 (UTC)
(1)然而就算是目前的处理方式,没有规定挂板到删除的期限,有个假装是机器人的管理员在,创建者很难在被删除前阻止,如要创建机器人的机制,建议采通知X天后删除的机制(当然人类也要遵守)。另O4应该就不太需要这个等待期了?--Xiplus#Talk 2021年2月23日 (二) 01:25 (UTC)
可能要设置检测期,检查挂模板后1日内有没有编辑(类似O7的6个月检测期),以及有没有{{hangon}}。如果挂模板后1日内有编辑,O7就肯定不用删了,O4和F7而言可能是有人挂了{{hangon}}。O4还是需要等待期,YFdyh000上面说的事情还是值得忧虑的。SANMOSA 誓山海而长在,似日月而无休 2021年2月23日 (二) 01:34 (UTC)
(※)注意:我上面罗列了那么多问题,好像都被无视了。--虫虫飞♡♡→♡℃留言 2021年2月23日 (二) 01:46 (UTC)
多是机器人能判断和避免的。--YFdyh000留言) 2021年2月23日 (二) 03:07 (UTC)
(也就是说,上面罗列的问题不成问题。)SANMOSA 誓山海而长在,似日月而无休 2021年2月23日 (二) 04:25 (UTC)
(?)疑问:其实大家知道什么叫分类重定向吗?--虫虫飞♡♡→♡℃留言 2021年2月24日 (三) 02:58 (UTC)
(※)注意:不认为机器人有能力解决以下问题:
  1. 有时用户不懂得加分类重定向,机器人会以O4提删,管理员要手动加“分类重定向模板”,才能解决机器人反复提删分类重定向;而且之前机器人失灵,把已经放了分类重定向模板的页面也提删,因此必须有管理员判断。有些管理员也会误判。
  2. O7的页面可以WP:AR还原,如果机器人自动删除,但令WP:AR出现问题。
  3. 有时用户会把合理使用的文件转载到共享,但原文件不能F7删去。有些管理员也会误判,不认为机器人有能力判断著作权。
以上。--虫虫飞♡♡→♡℃留言 2021年2月24日 (三) 02:52 (UTC)
我究竟说过多少次了,2技术上不可能发生SANMOSA 誓山海而长在,似日月而无休 2021年2月24日 (三) 10:32 (UTC)
而且1也不是什么大问题,删除了以后,重建时直接加{{cr}}就好。我没见过挂了{{cr}}还是被自动提删的情形,就虫虫飞说的那种情形,我认为{{cr}}很可能是被自动提删后才挂的,然后虫虫飞又没看过页面历史,结果产生了误解;即使真的是挂了{{cr}}以后才被自动提删,发生的几率实在太低,没必要过度忧虑。SANMOSA 誓山海而长在,似日月而无休 2021年2月24日 (三) 10:34 (UTC)
3来说,既然“有些管理员也会误判”,那凭什么要求bot“解决(误判的)问题”?即使误判,走DRV程序恢复就好,没什么大不了的。这提案本来就只是打算通过bot加快处理流程,仅此而已SANMOSA 誓山海而长在,似日月而无休 2021年2月24日 (三) 10:40 (UTC)
  • 您没看懂我的留言。总之,提案不但没有解决问题,而且当前没有问题,但提案反而制造了问题。--虫虫飞♡♡→♡℃留言 2021年2月25日 (四) 03:55 (UTC)
不,这提案没有制造任何的问题,而且上面所谓的“问题”要么不可能发生,要么就发生几率太低而不成问题。SANMOSA 誓山海而长在,似日月而无休 2021年2月25日 (四) 09:07 (UTC)
  • 请您论述提案解决了什么问题?现行机制是否无法解决您提到的问题?--虫虫飞♡♡→♡℃留言 2021年2月28日 (日) 02:19 (UTC)
这提案本来就只是打算通过bot加快处理流程,请问我是不是连提出一个加快处理流程的提议都不行?SANMOSA 江南好,风景旧曾谙 2021年2月28日 (日) 05:27 (UTC)
您没看懂我上面提到的问题。请再看一下o4、F7及o7的问题,尤其是o4、F7。您不能把机器人误删的问题全推给DRV去处理。--虫虫飞♡♡→♡℃留言 2021年2月28日 (日) 05:42 (UTC)
为何?管理员自己误删也是给DRV去处理,对管理员的容忍度那么高,却对BOT一点都不容忍?提案的目的只有一个:加快。误删率不是我的重点,反正是不会加大的。SANMOSA 江南好,风景旧曾谙 2021年2月28日 (日) 10:48 (UTC)
未见加快的必要,机器人无法辨识破坏者操作和误导,会增加反破坏的查证和复核成本。如果有同类任务积压,人工用机器人或脚本辅助还差不多。--YFdyh000留言) 2021年2月28日 (日) 11:01 (UTC)
我要求实际数据证明此说法。SANMOSA 江南好,风景旧曾谙 2021年3月1日 (一) 10:28 (UTC)
我要求机器人先展示自己的效果。方针未必需要修订,机器人操作者(管理员)承担责任就可以。--YFdyh000留言) 2021年3月1日 (一) 10:31 (UTC)
应该请Sanmosa描述管理员处理该等速删时,应该进行哪些检查和判断,列出详尽步骤,再来看看机器人是否能完美克隆人类的行为。--Xiplus#Talk 2021年3月1日 (一) 11:18 (UTC)

提案重启“新设删除员权限”讨论

“新设删除员权限”讨论最初由User:Kuon.Haku在两年前开启,但最终结果为“暂不予设立”。最近站内存废讨论、侵权验证积压日渐增多,本人强烈建议重启此讨论。不同于管理员,删除员并不具有封禁权和保护权这两个比较敏感的权限,但也可以帮助管理员减少积压。

删除员具体权限以及先前草案全文设在Wikipedia:删除员,先前讨论已存档于Wikipedia_talk:删除员,欢迎大家踊跃参阅并加入讨论。--YOWOT868✌️Tie Up A Habit. 2021年2月21日 (日) 13:44 (UTC)

  • (+)支持本提案,申请方面(+)支持虫虫飞提案(偏向本提案)与提案2(修改),除权方面(+)支持提案2(修改)。--海の向こうは敌だ!|欢迎订阅维猫报! 2021年2月21日 (日) 14:02 (UTC)
  • (+)支持提案,分担管理员工作,降低相关权限的上任与解任难度。赞成提案1;提案2的“酌情”、“也可”太模糊了,落选管理员自己再参选删除员就好;考题有点模糊。除权支持提案2,清晰明确,唯“快速除权”应更名“紧急除权”,参考管理员的紧急除权标准,并在落实原因后可根据共识和行政员决定直接复权或重新参选。解任后重新参选条件、不活跃除权等有待完善。--YFdyh000留言) 2021年2月21日 (日) 14:21 (UTC)
    积压一点也不多啊,发起理由完全不成立。--AT 2021年2月21日 (日) 14:28 (UTC)
    没太关注站务,但解任投票和这里都有人说站务有积压情况——虽然不一定是存废,但存废和侵权验证是很大占比、很费时间的,分摊一些没什么不好,有权用户的增多也能促进一些关注和讨论。悄悄滥用是另一层面,更低的解任和提报难度可弥补。--YFdyh000留言) 2021年2月21日 (日) 14:50 (UTC)
  • (-)反对目前的方案:“删除”权限并不是比“封禁”、“保护”更为不敏感的权限;就本人的观察而言,条目删除对新用户的打击有时并不亚于直接对该用户施与封禁。运用删除权限也意味着提名人需时刻具备向受影响用户解释自己删除操作的能力,而这是管理员的核心能力之一。因此,不应该设立当选门槛低于管理员的删除员。--Antigng留言) 2021年2月21日 (日) 14:35 (UTC)
    1. 就我个人的观察,PJ:AFC对新用户的鼓励与打击程度可能是同等的,期望在意新手的维基人和"提案人'予以关注。2. 不认为提名人无法做到解释自己的删除操作,如果做不到那么离被解任已经很近了,且比管理员更近,部分管理员反而因事务繁忙、解任难度高、疲劳感等原因不详细解释自己的操作依据,或者无视其他人的理由或意见。3. 删除员担任经历可能成为晋升管理员的一步,同时缓解站务压力。4. 其他管理员和删除员可以还原并重启不合适的处理(可能需方针修订;当然,WP:DRV也不错;需明确删除员能否处理DRV,大概是不能)。警告模板和其他不友好行为对新手的打击同样巨大,不是禁止更多人参与站务的理由。--YFdyh000留言) 2021年2月21日 (日) 15:22 (UTC)
    AFC本意上是帮助新手更好创建条目,不过我参与该计划以来好像就没有通过几个条目……虽然确实对新手打击较大,但我也不知道怎么更好平衡条目质量与保护新手两方面。--LightyearsTalk·Sign#订阅维猫报喵! 2021年2月22日 (一) 15:19 (UTC)
    没用AFC提交过,很认可帮助新手和同行评审理念,但实务执行中显然存在问题、似乎小圈子。我认为很简单,增加一个阶段,条目内容满足关注度和基本素质(即基本合格。削减后可作小作品),但内容可进一步完善,这种情况下不要驳回为不通过(尤其是通用意见),会使新手以为现有内容不对、这仍不是合格的条目、做了无用功。状态可以是绿色的合格标识附评语,并等待编写人反馈后续意向,或者移到条目但保留隐藏分类,继续在条目讨论页讨论完善。发现您似乎创建了AFC的两个TG群,您能否转交意见和尝试推进讨论(可以ping我)。--YFdyh000留言) 2021年2月22日 (一) 16:25 (UTC)
    已在您的讨论区留言,我们似乎离题太远,接下来的交流我们可以在您的讨论区进行。再次感谢您的宝贵意见。--LightyearsTalk·Sign#订阅维猫报喵! 2021年2月23日 (二) 04:29 (UTC)
  • 感觉此用户组没有非常大的必要,在和RFA门槛相比差不多的情况下,既然通过的人可以妥善处理删除和恢复,那么我也会相信那个人不会滥用封禁和保护,这个用户组的权限效果和赋权门槛不易平衡,可能只适用于某人确实只需要删除和恢复权限,实在不想处理其他事务的场景。在这种情况下,在申请方面我本是倾向支持提案2,不过投票只需是自动确认用户即可投票,门槛太低。故门槛部分支持虫虫飞版,需任巡查回退一段时间,否则可能会不熟悉删除方针;除权倾向支持提案2。--安忆Talk 2021年2月21日 (日) 14:36 (UTC)
    • 管理员上任投票的提问量和标准我认为过头了,有些人希望上任管理员是多面手、熟练工。模板编辑、界面编辑的分离也是这个趋势,权限就应该“没什么大不了”,当事人善用、不会滥用就应该有权限。关于条件,我倾向看效果再改、更多关注(如试用期),巡查和回退似乎不足以了解存废讨论的流程和习惯。--YFdyh000留言) 2021年2月21日 (日) 14:50 (UTC)
      • (~)补充:或许还可以参考下被提名人的AFD和CSD日志。--安忆Talk 2021年2月21日 (日) 14:52 (UTC)
        怎么说呢…“删除”是一个比较打击编者的操作,我不认为连管理员都感到棘手的删除任务靠独立出来的删除员就能做好。申请门槛低了显然不行,可能会乱删,但较高的申请门槛却只带来了删除和还原,我所能想到的申请心态只有上面提到的“只需要”的情况。有时候在删除的同时又需要保护和封禁,难不成这时候还要再提几个请求?感觉未免有些多此一举。在这种申请门槛和实行情况下,那个人还不如考虑直接申请管理员。--安忆Talk 2021年2月21日 (日) 15:15 (UTC)
        那可以劝慰避免或者条文禁止处理棘手议案。删除同时要保护和封禁,是反破坏吧,管理员可以着重处理WP:VIP,删除员也可以快速处理广告速删(判定层面是个问题,但管理员未必就做的更好)。--YFdyh000留言) 2021年2月21日 (日) 15:27 (UTC)
      • 技术和普通站务维护是相对平行正交的维度,但是站务管理中的“封禁”、“删除”与“保护”则不然,不宜将IA/TE的设立作为设立删除员的论据。--Antigng留言) 2021年2月21日 (日) 14:55 (UTC)
        不太赞成是平行维度,不太懂您的意思。也可理解为我认为将管理员的反破坏职责与站务职责在概念上分拆是好事。--YFdyh000留言) 2021年2月21日 (日) 15:10 (UTC)
        • 已修改措辞为“正交”,抱歉先前用词不当。--Antigng留言) 2021年2月21日 (日) 15:21 (UTC)
        Antigng的意思可能是IA/TE主要的着力点都不是和条目相关的方面,而普通站务维护是。--安忆Talk 2021年2月21日 (日) 15:18 (UTC)
      基本同Antigng,反对。权限就应该“没什么大不了”,所以应该要改变的是管理员上任投票的提问数量问题,而不是设立删除员。另外,若一个用户真的能通过适当的程序,被证明能合理运用删除权限,那么此人就具备对方针的完善理解、足够的自我控制和反省能力以及良好的沟通技能。既然如此,此人已经适任管理员;若并非如此,则此人在删除相关工作中也会遇到麻烦。别忘了草案中还包含了存废复核、修订版本删除等比较复杂的事务,此类站务若出现积压,则更多是由于缺乏执行的共识,而非大家忙得要死顾不过来。--Tiger留言) 2021年2月21日 (日) 15:20 (UTC)
      对于存废复核和修订版本删除,个人也倾向反对,在没有出现积压前,存有争议或操作不显著的权限不适合授权,至少不适合新任删除员使用。--YFdyh000留言) 2021年2月21日 (日) 15:35 (UTC)
(-)反对:现在这个时候设立权限,我认为会让个别管理员无视规则单凭个人好恶删除特定页面的情况变得更为严重(变成管理员以外的人都会这样做),这是申请门槛没办法处理的事情,老用户这样做的潜在可能性更高。另一方面,我担忧会引来权限收集的问题。SANMOSA 誓山海而长在,似日月而无休 2021年2月21日 (日) 23:52 (UTC)
  • (!)意见:中维大校遍地都是,少将却是寥寥无几,更何况中将,上将了。Zhuofan WuCien años de soledad 2021年2月22日 (一) 03:05 (UTC)
  • (+)倾向支持:可以协助处理站务积压,方案方面均支持提案二。不过删除员是否可以选择处理CSD和AFD而非DRV?个人觉得DRV争议比较大。--LightyearsTalk·Sign#订阅维猫报喵! 2021年2月22日 (一) 15:15 (UTC)
    • 该等限制尚无技术手段能够实现。--Antigng留言) 2021年2月22日 (一) 15:57 (UTC)
      可以使用方针限制,不过我认为此案最后会得到和这个差不多的结论。--安忆Talk 2021年2月22日 (一) 16:02 (UTC)
      不需要技术手段,违规处理可以发还讨论、警告和必要时除权。--YFdyh000留言) 2021年2月22日 (一) 16:28 (UTC)
      同意安忆的想法,可以通过方针限制。下面也有设立两个用户组的想法。--LightyearsTalk·Sign#订阅维猫报喵! 2021年2月23日 (二) 10:36 (UTC)
  • (-)反对,同Antigng和Tigerzeng,不认为有此必要。如果是因为选管理员的问题,那么应该去想办法解决管理员难选的问题,而不是通过这种方式绕过去--百無一用是書生 () 2021年2月23日 (二) 02:40 (UTC)
  • 已经有不少封禁及编辑禁制是由删除页面产生的争议引起,删除员的判断能力与信任度的门槛不会比一般管理员低。--Uranus1781留言) 2021年2月23日 (二) 04:41 (UTC)
  • (+)支持设立删除员,但(-)反对权限中包含的“删除和恢复页面的特定版本“及处理DRV。个人认为这些动作需要更受信任的管理员进行处理。对于细节,支持虫虫飞的提议(否则就又变成选管理员了 囧rz……)。支持设立删除员的原因:该权限略不同于管理员权限。个人认为“封禁”和“保护”等管理员操作较“删除”相比,更加“敏感”,需要操作人员更具备社群信任。因此支持设立删除员。且本人看到AFD和侵权验证有时会有部分积压。--Yining Chen留言|签名) 2021年2月23日 (二) 06:50 (UTC)
    • (~)补充:对于“删除和恢复页面的特定版本”,是否可以模仿自动确认用户的方式,让某名用户在担任删除员n个月后或进行m笔删除操作后自动具有该权限?--Yining Chen留言|签名) 2021年2月23日 (二) 07:01 (UTC)
      • 人工评议后授权更好,资历不能证明什么。大概需要两个用户组,删除员、高级删除员(含存废复核和修订删除)。--YFdyh000留言) 2021年2月23日 (二) 07:10 (UTC)
        (+)支持。删除员处理CSD和AFD,而高级删除员可以处理DRV。--LightyearsTalk·Sign#订阅维猫报喵! 2021年2月23日 (二) 10:34 (UTC)
        分设两级可见本人以下建议。--LuciferianThomas留言 2021年2月23日 (二) 11:08 (UTC)
(+)不反对将删除权限局部下放,但我觉得非管理员不适宜处理带有争议的存废,而是比较适合处理符合快速删除标准或明显违反方针指引而没有版本可以回退的页面和页面历史。
(&)建议可设“维护员”一职,设两级制:
  • 初级维护员同时拥有巡查权及回退权;
  • 二级维护员同时拥有巡查权、回退权及删除权。
设立维护员及建议申请安排如下:
  • 巡查员及回退员的申请逐步暂停受理;
  • 初级维护员的申请安排跟从现时回退员/巡查员申请模式,首次申请有期限授予回退、巡查权,试验期届满可再次申请,由行政员判断是否予以升任二级维护员(即授予删除权)、只予续任或除权。
  • 现时已经拥有巡查权回退权超过一定时间(如六个月),活跃参与反破坏事务且能证明其能恰当使用权限的用户可直接申请成为维护员,由行政员判断授予二级或初级维护员身份;
    • (~)补充:“活跃参与反破坏事务”可指申请当下符合回退员申请要求,因某些原因而短暂(三个月内)维基假期可酌情处理。
  • 现时同时拥有巡查员及回退员身份之用户自动获得初级维护员身份(权限相同,不必重复申请);
  • 现时只拥有上述两个身份之一的用户在期限内未申请新职位视为放弃巡查权及回退权。
    • (~)补充:若通过设立此职位,务必透过用户讨论页通知此类别用户,自己看不到就自己问题(当然,可容许这些用户容后再次申请,但行政员怎么想我就不知道。
同上本人所述,维护员不建议处理有争议的存废,但一般的速删等工作则可执行。拥有此权限的用户所受的限制(尤其是使用删除权限方面)必定比现有回退员、巡查员更严格。设立维护员一职可减少以至防止WP:HATC行为;未来更可成为申请管理员一职的指标。希望以上意见能被考虑。--LuciferianThomas留言 2021年2月23日 (二) 11:06 (UTC)
您的意思是取消巡查员与回退员两者,改用维护员?那门槛如何设置,依照250还是1000?其次,我还是认为“二级维护员”需要社群讨论后授权,而不是管理员授权。--LightyearsTalk·Sign#订阅维猫报喵! 2021年2月23日 (二) 12:24 (UTC)
1.比删除员好听。2.权限集成也许不利于快速成长(熟悉权限、规范和任务)和上任解任(巡查的门槛和后果比删除低得多;可能担心影响站务而忽视解任意见)。不赞成改变现有巡查员和回退员机制,动静太大(方针修改)、收益不大。未必叫初级、二级,初级听上去不那么靠谱,以及“升级”或增加HATC行为。3.个人赞成权限分离,那样还可以剥夺部分权限(类似编辑禁制)。以及或可考虑警告+禁制(移除特定权限x周)之类的更灵活处罚(比如模板编辑员目前是一次严重违规就解任)。x. 如果管理员(sysop)叫站务员或操作员就更好了,可惜不可能。--YFdyh000留言) 2021年2月23日 (二) 12:26 (UTC)
(-)反对取消巡查员一职, 个人认为巡查权不仅可帮助改善维基百科, 而且还可让刚接触维基百科的用户更好的熟悉站务. --Yining Chen留言|签名) 2021年2月23日 (二) 13:58 (UTC)
这个意见不可能被接受,至少在“有些用户只想专注于回退破坏,而有些只想巡查”的前提下就不可能,更何况删除权只能由值得信赖的用户操作,与经验无关。-- 2021年2月27日 (六) 15:39 (UTC)
(!)意见:有些管理员专精于特定项目,比如技术、条目合并、字词转换等等,不一定要全能。“如果”社群觉得对删除员的信任度几乎必须比照管理员,其实也就不需要增设删除员,而是需要专精删除的管理员。为了补足人力,可以直接征招对AFD/DRV事务有兴趣与自信者申请管理员。相对于{{Template:User_noAdmin}},可设计一个【这个用户想成为管理员,尤其对XX有热忱。】的用户模板,XX为模板选填参数。有志者先于用户页加入该模板,再积极参与AFD/DRV,现任管理员见其模板也可加强传授指教之;自荐申请管理员时主动表示志在AFD,社群便可按其表现优先支持,因为“社群觉得对删除员的信任度几乎必须比照管理员”,可信的删除员也差不多就是可信的管理员了。以上浅见。--Hjh474留言) 2021年2月23日 (二) 13:43 (UTC)
除非受提名管理员的操作特征非常明显(如专注技术),不然投票和问答总会是方方面面,基于个人好恶。除了提升权限拥有者数量,新权限或许能促进一些讨论和新鲜血液的补充、进阶。--YFdyh000留言) 2021年2月23日 (二) 13:57 (UTC)
管理员不是全能的。如果参选者都表明了自己当选之后的行动方向,还被问一些奇怪问题的话,也挺令人无语的…既然不强制参选者回答所有问题,建议就直接将其忽视掉(如果是我的话)。--安忆Talk 2021年2月23日 (二) 14:09 (UTC)
印象中不少问答质询针对具体类别或案例,不少人将管理员上任当成/盼作解决自己关心问题的“灵丹妙药”。奇奇怪怪、刁钻疑难的问答,以及不信任特定类型操作能力的意见,对管理员上任是个不小的、不一定需要的挑战。就管理员上任难度问题,另一个方法是试用期。--YFdyh000留言) 2021年2月23日 (二) 14:20 (UTC)
试用期+1,建议不可太长。但因为RFA常常耗费社群相当多精力,因此试用期结束后的续任机制,得要想一下。。。--Hjh474留言) 2021年2月23日 (二) 14:28 (UTC)
我认为30天(或者4周)适合。RFA可以投票基本达标(如14天内净支持票数>??)后进入试用阶段和授权,阶段结束后讨论总结是否解任(行政员按共识判定),期间有不足也可多次警告和必要时解任。不能解决非试用期解任难度问题。不好意思又跑题了……--YFdyh000留言) 2021年2月23日 (二) 14:47 (UTC)
试用期不可取,难以定论这个期限有多长,又按什么标准,在我看来只是在为了自己心中的标准二次投票罢了。有问题就和对方说,说过了对方知道了但改不掉却还继续做的话就看情况提除权,没什么大不了的;话说RFA的问题是真的千奇百怪,有的人就是要的圣人,而不是什么管理员、删除员或是什么其他的,严以律人宽以待己。
说回这个删除员,它的很多标准注定是模糊的、量化不了的(包括选举、用权和除权等各个阶段)。管理员的3000次编辑很高吗?其实不是,有的人一周不到就能刷完,所以这类门槛意思意思就行了;假设真有这个删除员了,既然人家是按信任投票上去的,还要人家做管理员的活,那就不要再吝啬自己的信任整什么分级试用等等花活。有人愿意贡献,那就选他,选上来不是做得非常差就够了(不要完美要一般)。况且,什么是做得好?是不犯错是好,还是做得多是好?这看似简单的问题都没办法量化。反正不可能做得又多又没错,因为做得多了肯定会有不合某人意得时候。到时候又会被人翻出某笔远古编辑说话。本来就是闲暇之余做做贡献,居然还要志愿者去打怪升级又不给装备,这恐怕不太合适。我能想象日后是什么光景——做得好没什么人夸,做不好却又有可能被跳出来的一大堆人说。有的人已经忘了“人非圣贤孰能无过”、“知错能改善莫大焉”这些简单的道理。
同意时昭的看法,如果是因为选管理员的问题,那么应该去想办法解决管理员难选的问题,而不是通过这种方式绕过去,没必要单设用户组(甚至还要细分分级)。管理员可以是删除员,反过来也完全可以。值得信任的人、靠谱的人知道自己会做什么、要做什么以及应该做什么。一个是管理员的删除员,多出来的管理员权限可以更好地帮他处理遇到的问题;相反,一个不是管理员的删除员,遇到问题反而会施展不开。都是差不多的标准上去的,后者为的是什么,难不成是为了在删除又需要保护和封禁的时候,再提几个请求刷刷编辑数?
以上是我又看了看历史RFA/RFDA啰嗦的几句,希望不要有人介意。--安忆Talk 2021年2月23日 (二) 15:39 (UTC)
感谢您的意见。我认为社群将RFA视作全能管理员选举的问题中短期内无望解决、无法达成共识,或许还不如尝试分拆权限、快速调整来变相演进。就好似Chrome和Windows 10的快速版本周期,即便屡被吐槽,照样有一定的推进效果,避免大体量的难以调整。--YFdyh000留言) 2021年2月23日 (二) 16:33 (UTC)
又是因为“种种变动牵扯方面过多且复杂,其影响虽深远却现时利益不足”啊…不去推动是永远也没办法前进的,分层/拆分只是在拆了东墙补西墙,剪不断理还乱却又增加新问题。不过也可以理解。--安忆Talk 2021年2月23日 (二) 16:51 (UTC)
YF君:了解您的意思。为了补足人力,并非反对增设,只是提出另一选项,因为会担心删除员效果不彰,比如社群不信其判定,或上任后却因故不积极处理存废。。。--Hjh474留言) 2021年2月23日 (二) 14:12 (UTC)
(~)补充:以专精存废的管理员取代删除员也许还有其他优点。删除员可使管理员AFD工作量下降,但因位阶较低,DRV工作量可能反而上升,不服者可能会期待有管理员出来否决删除员。--Hjh474留言) 2021年2月23日 (二) 13:59 (UTC)
(※)注意更值得关注的认为是可能出现的大规模即时提交,即时删除的无可挽救风险。而这个一旦发生,本地原有的机制是否可衡常发威也是个问题。(?)疑问提案是否清晰考虑过这些。--约克客留言) 2021年2月28日 (日) 04:21 (UTC)
  • (-)反对:被提交到afd的条目(大部分提删理由是关注度)其实不用急着删除,哪怕积压一段时间也没问题,从站外非维基人的评价来看很少有人会批评“维基存在低关注度条目”,反倒是有人吐槽乱删条目[25][26],所以afd积压并非紧急站务,无需额外设置删除员。--Googol19980904留言) 2021年2月24日 (三) 05:11 (UTC)
  • (-)反对,删除页面主要是管理员的职能,若要把这一权限单独授予,选出来的用户必定是受到社群高度信任的用户,若其门槛低于管理员,我觉得是无法接受的。另外,也未见AFD相关站务的明显积压,提案发起的理由都不太成立。——BlackShadowG留言维基百科20岁生日快乐! 2021年2月24日 (三) 13:11 (UTC)
(-)反对,能成为删除员,也必定能成为管理员,因为两者都必须值得信赖,拆分管理员权限并不能解决什么。 2021年2月27日 (六) 15:34 (UTC)
(+)支持但同时建议可以约束删除员在正常情况下仅能处理CSD这类有即时处理必要的页面。--银河市长☎️— 2021年2月28日 (日) 02:49 (UTC)
(~)补充意见类似LuciferianThomas我觉得可以设检修员,同时直辖巡、退权,分初、高阶,但初阶就包含现在删除员的权限,高阶则多封禁权、保护权毕竟我觉得封禁权更需要下放,不然许多条目的历史页都可见回退战,但所有检修员做出的封禁、保护、删除都需上报WP:待审查管理。--银河市长☎️— 2021年2月28日 (日) 03:14 (UTC)
(~)补充但不取消巡、退员。--银河市长☎️— 2021年2月28日 (日) 03:21 (UTC)

Wikipedia:格式手册/两岸四地用语Wikipedia:格式手册/朝鲜半岛用语

现建议在Wikipedia:格式手册/两岸四地用语修改以下条文:

现行条文

下级行政区划 依据“使用常用名称原则”,若非描述法理状况,在描述两岸下级行政区划所属的国家时,应以事实论述为主。

提议条文

下级行政区划 若非描述法理状况,在描述两岸四地下级行政区划所属的国家时,应以事实论述为主。

并在Wikipedia:格式手册/朝鲜半岛用语增补以下条文:

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

(?)疑问这种改法是会有什么作用?以现有的常识判断,条款之适用必须有进一步的限制,才可能确保本地运用不会偏差。如果削弱了第一章的限制力,并扩大任意诠释“事实”、“法理”的风险,这样的修订恐怕并不会有很好的影响效果吧。提案认为必须重新审视实际的作用,不宜缺少更可靠的限制指明,尤其是本地既有规则的制约--约克客留言) 2021年3月1日 (一) 01:28 (UTC)
“依据‘使用常用名称原则’”是错误的描述,因为使用常用名称原则仅在条目名称适用,而从来不在条目内文适用。“事实论述”指的是现在是由哪个政权控制就写成由哪个政权控制。SANMOSA 江南好,风景旧曾谙 2021年3月1日 (一) 05:48 (UTC)
在现行机制开始难以控制部分问题日趋严重的情况下,不认为缺少限制的修订会有较好效果,如已在上所言这样可能会制造新的漏洞。要必须强调非常多的编辑,对于事实(fact)和观点(opinion)的理解还是有很大问题的,缺少限制是可能引发对有关定义新的争锋等情况。建议提案重新考虑--约克客留言) 2021年3月1日 (一) 09:23 (UTC)
我不认为会出这种情况,中文维基百科的人不是白痴。再不然我加注释说“事实论述”是“de facto”、“法理论述”是“de jure”,让人直接参照这两个条目的定义就好了。SANMOSA 江南好,风景旧曾谙 2021年3月1日 (一) 10:51 (UTC)

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

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

@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)
  • “19世纪50年代”不是相等于“1950年代”吗。--Temp3600留言) 2021年2月26日 (五) 13:29 (UTC)
认真?“19世纪50年代”相等于“1850年代”,“20世纪50年代”才相等于“1950年代”。-游蛇脱壳/克劳 2021年2月26日 (五) 14:16 (UTC)
@Temp3600:想一下2000年是几世纪,称多少年代。以及Category:2000年代怎么整。--YFdyh000留言) 2021年2月26日 (五) 14:20 (UTC)
似乎2000年是20世纪90年代(1991至2000年)的最后一年,以及2000年代(2000至2009年)的第一年⋯⋯像1世纪是1至100年,21世纪是2001年至2100年;而X世纪00年代是这个世纪的第一个十年。所以21世纪00年代是2001年至2010年,和2000年代严格来说还不是一个东西?PS:“21世纪00年代”和“21世纪10年代”怎么读?“二十一世纪零十年代”“二十一世纪一十年代”?--洛普利宁 2021年2月26日 (五) 15:10 (UTC)
这,尴尬了,我记成21世纪了Facepalm3.svg 捂脸--YFdyh000留言) 2021年2月26日 (五) 15:24 (UTC)
读作零零年代、一零年代,就像九零后、零零后。--YFdyh000留言) 2021年2月26日 (五) 16:01 (UTC)
①“20世纪50年代”=“1950年代”=“1950年到1959年”,这应该比较没有争议;②但如您所举例,遇到100的倍数就麻烦了;③“20世纪50年代”、“21世纪00年代”、“21世纪10年代”我会分别读“二十世纪五零年代”、“二十一世纪零零年代”、“二十一世纪一零年代”,至于别人怎么读,我就不知道了。-游蛇脱壳/克劳 2021年2月26日 (五) 16:15 (UTC)
00和10以外的年代,我大概会读作“__十年代”,读法上没问题。--YFdyh000留言) 2021年2月26日 (五) 21:01 (UTC)
@@YFdyh000:说到年代的是,请教大家一个问题,最近我都不太用维基百科了,今天我在找资料时发现有条目里面原有年代的部分被删除了,查了查是有编辑者删除了,可能他认为那是考古专家学者考据的年代,不是当时人写下的年代,譬如,古埃及第三xxx王朝约公元前xxx年-公元前xxx年,所以编辑者把年代删除在内容改成不知道,现在可以这样吗?><?我怕搞不清楚状况所以问问。--User:浪子鱼|爱偷懒的鱼🐠※User talk:浪子鱼|留言 2021年2月26日 (五) 16:43 (UTC) ──以上未签名的留言由浪子鱼讨论贡献)加入。
@浪子魚:不太清楚您的意思,是条目内容还是分类,年代与条目主题的关系。麻烦您将签名加上内部链接,不然别人不方便查阅和回复,您的ping也不会生效。--YFdyh000留言) 2021年2月26日 (五) 21:01 (UTC)

买卖维基百科的账户是否合规

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

目前有这样的情况吗?--LightyearsTalk·Sign#订阅维猫报喵! 2021年2月28日 (日) 01:43 (UTC)
无论有无这都是一个较为严重的方针问题,如果有人这么做会对已有方针做出冲击和对维基百科进行可能的破坏—CAT  来讨论嘛  2021年2月28日 (日) 01:51 (UTC)
而且这样破坏者获得一个自确账户就更快了,甚至可以在几天内拿到一堆自确账户进行破坏编辑,而你根本无法把他确认为一个人,因为他可以换手机,换浏览器,使用代理,用毫无关联的自确账户—-CAT  来讨论嘛  2021年2月28日 (日) 01:54 (UTC)
WP:ROLE:“不容许创建一些由多人共享的角色账户”;WP:NOSHARE:“所有与他人分享账户的行为(包括分享账户密码)均被禁止”。并可能比照被盗用的账户直接全域锁定账户。--Xiplus#Talk 2021年2月28日 (日) 01:55 (UTC)
我指的是出售,不是共享,共享指多人同时使用,而出售后仅有一人使用—CAT  来讨论嘛  2021年2月28日 (日) 03:00 (UTC)
前一留言后半已说明共享的定义。--Xiplus#Talk 2021年2月28日 (日) 07:19 (UTC)
但是分享可能严格来说并不能算是出售和交易,分享更多是无偿的,我希望能够单独就买卖账户创建新方针或者扩充已有方针—CAT  来讨论嘛  2021年2月28日 (日) 10:20 (UTC)
@喵呜猫:分享不是这个定义,此条文指将账号控制权交由他人被发现即会被封禁。类似情况有方针上文的“公司/团体名称”,禁止了组内多人持有同一个账号。花钱买账号,大概率还涉及有偿编辑或利益相关。--YFdyh000留言) 2021年2月28日 (日) 10:43 (UTC)
要有自动确认用户愿意卖,您的担忧才成立。-游蛇脱壳/克劳 2021年2月28日 (日) 10:28 (UTC)
如果有人愿意买,肯定有人愿意卖,可以“量产”。--YFdyh000留言) 2021年2月28日 (日) 10:44 (UTC)
既然可以“量产”,为什么不自己生产,还要花钱买?而且想买的人要如何让人知道他想买?更重要的是,“拿到一堆自确账户进行编辑”本身就已经违规了(傀儡)(会招致惩罚),不论是否进行破坏。破坏维基百科又没钱赚,我好奇谁会花钱做这种损人又损己、徒劳无功的事。是不是我太天真?-游蛇脱壳/克劳 2021年2月28日 (日) 11:11 (UTC)
1.需要一些技术和时间(>7天),分工不同,就像代理服务器有人卖、验证码打码有人卖,什么都有人卖。2.如果商品有市场,自然有市场在卖。3.可以绕过半保护和一些反破坏机制。公关公司、饭圈粉丝等,都可能买。这也是WP:CU的作用之一。--YFdyh000留言) 2021年2月28日 (日) 11:18 (UTC)
通过水编辑和自动编辑脚本可以实现无成本的高速量产,并且可以以极低的价格出售,同时也一定有人去买(比如某明星狂热粉丝为了给“偶像”刷数据,但是又没时间编辑维基百科)而且通常会造成破坏,这是我的担忧——CAT  来讨论嘛  2021年2月28日 (日) 14:44 (UTC)

重提Wikipedia:集中讨论

问题背景 Wikipedia:互助客栈/消息因用户查核问题引发大篇幅讨论。此前在COVID-19、朝鲜半岛等问题上,互助客栈也产生过争论。这些讨论占据大量篇幅,不利于其它讨论的进行。
解决方案 Wikipedia:集中讨论升级为指引。启用{{Centralized discussion}}。
此前的类似讨论 Wikipedia talk:集中讨论:2020年有过类似讨论,基本上没有反对意见,但没有进入公示阶段。

--Steven Sun留言) 2021年2月28日 (日) 01:22 (UTC)

不太懂具体怎么做。与公告栏的差别。模板说明页未翻译。--YFdyh000留言) 2021年2月28日 (日) 10:37 (UTC)

在格式手册/标点符号#引号中加入 POV 一节

维基百科部分条目中有一些不大适当的引号使用。例如某些编辑历史甚至是主要为了在看似理性的评论中的个别词组或词语上加入引号。鄙人亦曾对类似用法产生疑惑,后发觉容易被误用/滥用。现建议在WP:格式手册/标点符号#引号下加入一条内容(基本照搬英文维基百科对应内容)。

现行条文

(无)

提议条文

引5:引号应当用于展示情绪化的意见,特别是在此等意见的用词不适合由维基百科直接转述时。在此情形下,来源必须清楚给出。且此等用法不适用于展示文化常态。

  • 张三和李四认为此电影“使人难以忘怀”。
  • 此处所受当地人“厌恶”。

简短而无过分情绪化的意见可以直接转述,而非使用引文。为简单的描述性词语或词组加上引号,反而可能引致歧义。读者可能认为此内容包含反讽或影射,因为一些读者或将此用法视同“所谓”、“理应”。

  • 可接受:张三和李四认为此电影有意思。
  • 可能会产生歧义:张三和李四认为此电影“有意思”。
  • 应当作为引文:张三和李四认为此电影“有意思但十分令人揪心”。

下给出一些类似例子:

  • 习近平条目中,“第十四世达赖喇嘛也称赞习近平“更务实、更开明””。
  • 还愿 (游戏)#争议中,“中国大陆玩家批评团队“夹带私货”(隐蔽或不光明正大地展示个人政治立场)、“侮辱国家领导人”、“侮辱中国公民””。

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

“投射”是影射吧。目前而言不反对。--YFdyh000留言) 2021年3月1日 (一) 08:26 (UTC)
代改了。SANMOSA 江南好,风景旧曾谙 2021年3月1日 (一) 10:33 (UTC)
不反对自英文维基百科补充翻译格式手册,但我觉得应该要说明作为正文内使用引文的部分不能过长(过长的例子:全国脱贫攻坚总结表彰大会,都变成新闻稿了),如果实在是比较长,而且确实有需要列出,应该使用{{cquote}}、{{quote}}之类的模板(很多FA和GA都有这样的使用方式)。SANMOSA 江南好,风景旧曾谙 2021年3月1日 (一) 10:33 (UTC)
建议为此另加一条规则。--Yangwenbo99 2021年3月1日 (一) 18:00 (UTC)