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

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

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

Breezeicons-apps-48-cantor.svg
发表前请先搜索存档,参考旧讨论中的内容可节省您的时间。
公告板
# 话题 发言 参与 最新发言 最后更新(UTC+8)
1 专题名字空间(第五至六阶段) 77 10 Sanmosa 2021-06-10 22:15
2 WP:捷径指引草案修订 30 4 A2569875 2021-06-17 12:04
3 设计一个制度解决部分速删模板挂不上去的页面的删除问题 63 6 A2569875 2021-06-20 11:50
4 订立影片加入相关指引 35 8 Ericliu1912 2021-06-10 09:00
5 再次推动破坏者(LTA)成为名字空间 38 13 羊羊32521 2021-06-20 11:13
6 “格式手册/两岸四地用语”之国籍章节规定"PRC国籍"应该直接写为"中国国籍"的中立性问题 75 18 Sanmosa 2021-06-19 08:34
7 修改WP:命名常规#书名号 188 24 Lewix 2021-06-20 00:43
8 7DAYS的第七次讨论 40 9 落花有意12138 2021-06-20 16:58
9 针对WP:小小作品的事实性修订 39 9 NHC 2021-06-18 18:51
10 将WP:命名常规 (音乐)列为指引 31 7 Sanmosa 2021-06-13 12:35
11 有关节目列表条目 37 11 LuciferianThomas 2021-06-17 08:15
12 加强封杀内容农场,容许于MediaWiki:Spam-blacklist预防性加入中文农场网址 17 6 Temp3600 2021-06-13 02:18
13 将WP:封禁方针#管理员注意事项中的“如果你反对某个封禁”一节移动到“解除封禁”一章下并进行修改 75 17 虫虫飞 2021-06-15 21:23
14 修改WP:编辑禁制方针,新增“解除禁制”一节 25 10 悔晚斋 2021-06-04 16:49
15 重写是否在繁简破坏的范畴 320 16 Lt2818 2021-06-20 02:40
16 细化有关用户讨论页编辑的两条规定(续) 4 3 Ericliu1912 2021-06-16 13:44
17 设置新的保护类型 28 17 LuciferianThomas 2021-06-20 15:46
18 拆分中文维基百科的可行性 27 12 Sunny00217 2021-06-18 13:24
19 是否接受CC BY-NC-ND 4.0类图片上传至维基百科 3 2 Leon3289 2021-06-20 13:31
发言更新图例
  • 最近一小时内
  • 最近一日内
  • 一周内
  • 一个月内
  • 逾一个月
特殊状态
已移动至其他页面
或完成讨论之议题
手动设置
当列表出现异常时,
请先检查设置是否有误

专题名字空间(第五至六阶段)

[编辑此导航模板]

导航模板请参阅此。导言请参阅此

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

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

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

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

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

第五阶段:小结

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

总结以上讨论意见:

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

R2. 跨名字空间重定向

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

R2. 跨名字空间重定向

包括以下几种类型:
  1. 从条目名字空间指向非条目名字空间的重定向(包括将用户页从条目名字空间移动至用户页名字空间时遗留的重定向);
  2. 从草稿名字空间指向非草稿名字空间的重定向;
  3. 从项目名字空间(Wikipedia)指向维基专题名字空间(WikiProject)的重定向;及
  4. 从维基专题名字空间(WikiProject)指向项目名字空间(Wikipedia)的重定向。
经社群同意设立的伪名字空间属于本规则之例外。
注意:有时新加入的维基人偶尔会在主条目空间误建用户页。使用“移动”页面工具将用户页移回用户名字空间会保留页面历史,在删除遗留的重定向页前,考虑保留一到两天;草稿重定向速删前,请确保草稿已经完成其作用,并且草稿的历史已经合适地移动到相应的正式页面。
  • 使用模板{{d|R2}}或{{d|interwk}}。

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

Module:Template:Delete/data模块的对应修改见User:Sanmosa/R2模块SANMOSA Σουέζ 2021年4月17日 (六) 04:24 (UTC)
现时有3502个WP->WPJ的重定向,33个WPJ->WP的重定向。--Xiplus#Talk 2021年4月17日 (六) 05:07 (UTC)
上面的结论有指明“清理链入页面后删除现有跨WP与PJ空间的捷径重定向”,所以应该需要bot,再不然发通知邀请社群协力清理也可。SANMOSA Σουέζ 2021年4月17日 (六) 11:00 (UTC)
(!)意见:“2. 将用户页移出条目名字空间时遗留的重定向”真包含于“1. 由条目名字空间指向非条目名字空间的重定向”,可以删去。另外那个看起来怪怪的,建议删去。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月20日 (二) 04:57 (UTC)
@羊羊32521:(1)1是(条目名字空间)→(非条目名字空间),2是(非条目名字空间)→(条目名字空间),2不能删。(2)完成。SANMOSA Σουέζ 2021年4月21日 (三) 03:38 (UTC)
查CSD历史,R2最初加入于Special:Diff/284065通过将用户页移出条目名字空间而创建的重订向。 (有时新的维基人偶尔会在主条目空间创建用户页。使用“移动”页面工具将用户页移入用户名字空间会保留页面的历史,考虑在删除作为移动结果的重定向页前,保留一到两天。) 所以是说:①在主名字空间创建用户页;②将该用户页移动到用户名字空间(留重定向);③快速删除重定向页。故2亦是“(条目名字空间)→(非条目名字空间)”。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月21日 (三) 15:55 (UTC)
阁下这一改意思都变了 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月21日 (三) 15:59 (UTC)
@Sanmosa-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月24日 (六) 14:39 (UTC)
另外我认为WP→PJ可能不适合速删,上方讨论有提到
或者先开机器人把历史遗留问题解决掉 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年4月21日 (三) 16:08 (UTC)
容许我再多等待三日,上面的提案会稍为调整。SANMOSA Σουέζ 2021年4月21日 (三) 03:38 (UTC)
@羊羊32521:有道理。已再调整。7日后我再重行公示。SANMOSA Σουέζ 2021年4月25日 (日) 08:19 (UTC)
针对“WP→PJ可能不适合速删”一点,我也曾经表示需要bot处理,但我认为人手逐个处理亦非不可,情况如同enwiki曾经有过的X1,分别仅在于这变成永久措施,并禁止日后同类重定向的创建。SANMOSA Σουέζ 2021年4月25日 (日) 08:25 (UTC)
@Xiplus:请求WP->WPJ的重定向及WPJ->WP的重定向的具体清单。另见上。SANMOSA Σουέζ 2021年4月30日 (五) 06:00 (UTC)
@Sanmosa列表于此,另您想让我注意什么?--Xiplus#Talk 2021年4月30日 (五) 06:10 (UTC)
@Xiplus:关于我对速删WP->WPJ的重定向的意见。当然我仍然希望有bot能协助清理链入(初步构思:[[WP:AA]]→[[WPJ:BB|WP:AA]]、[[WP:AA|自定義文字]]→[[WPJ:BB|自定義文字]])。SANMOSA Σουέζ 2021年4月30日 (五) 06:15 (UTC)
看起来无问题,不过我个人是觉得有大量链入的重定向就不应删除,这样也不需要去修正。--Xiplus#Talk 2021年4月30日 (五) 11:43 (UTC)
注意编辑摘要里也可能引用快捷方式(虽然专题页的引用量可能不会很大)。(▲)同上有大量链入的重定向不应删除-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月1日 (六) 05:49 (UTC)
此类提案应该不太可能涉及“有大量链入的重定向”,如有,请另表列出。SANMOSA Σουέζ 2021年5月1日 (六) 07:57 (UTC)
应该是没有-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月1日 (六) 09:19 (UTC)
178万6641个页面需要更新,占全部页面27%,我认为修复重定向是不明智的。--Xiplus#Talk 2021年5月1日 (六) 10:01 (UTC)
(:)回应有些是模板链入造成的,修改模板就可能可以大幅减少。—- 五岁抬☎️·☘️) 2021年5月1日 (六) 12:31 (UTC)
我本来也是以为是模板链入造成,但再次检查后,其实不然,可靠地估计需编辑的页面至少在156万以上。--Xiplus#Talk 2021年5月1日 (六) 12:44 (UTC)
@Xiplus:我要求就每个捷径分别排查链入数,并分别区分模板链入和非模板链入。我不相信大部分此类捷径都能产生逾100万的链入。SANMOSA Σουέζ 2021年5月4日 (二) 05:36 (UTC)
没办法透过查询链入来知道是否透过模板产生的链入,自己用搜索功能比较准。--Xiplus#Talk 2021年5月4日 (二) 07:52 (UTC)
@Xiplus:那能不能就每个捷径分别给出链入数?我仍然觉得此类捷径不可能每一个都能产生逾100万的链入。SANMOSA Σουέζ 2021年5月6日 (四) 01:50 (UTC)
Special:PermaLink/65497881。--Xiplus#Talk 2021年5月6日 (四) 02:13 (UTC)
刚才用正规表达式insource:/\[\[:?WP:MEA\|?/精准匹配结果也至少是130万 截图 因为正则会跑很久[1],但相信这只是特定专题这样而已,大部分的专题链入应该都很少,有的专题甚至无链入。-- 五岁抬☎️·☘️) 2021年5月4日 (二) 06:14 (UTC)
保留这个吧,这个是{{Welcome}}/{{Welcomeip}}的链接之一,当然非常常见。提议加个豁免条款,截至通过日,除本身多于一万直接链入的常用捷径豁免快速删除外其他都机器人修正呗。--LuciferianThomas留言 2021年5月4日 (二) 07:17 (UTC)
这应该要保留,不仅是大量链入,还会导致修改大量用户的讨论页 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月4日 (二) 10:56 (UTC)
我维持我的提案(快速删除从Wikipedia指向WikiProject的重定向,并由bot协助清理链入),但可以容许WP:专题/首页的缺失条目WP:MEA这两个例外(只有这两个产生了逾150万的链入,其余都少于10万,而且大部分估计是模板链入,即使假设全部为非模板链入也不会构成太大的工作量),但也就只有这两个能例外,而且也不便明文规定,因此会走Liangent G15的路线,只在模块进行限制。@A2569875XiplusSANMOSA Σουέζ 2021年5月6日 (四) 09:27 (UTC)
Module:Template:Delete/data模块的对应修改见User:Sanmosa/R2模块,已在2021年5月6日 (四) 09:33 (UTC)更新。有劳Xiplus检查对应修改的代码是否正常。SANMOSA Σουέζ 2021年5月6日 (四) 09:33 (UTC)

重行公示7日。SANMOSA Σουέζ 2021年5月14日 (五) 13:12 (UTC)


本讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。
@羊羊32521LuciferianThomas:不知道能不能找到人写bot。不然我们也可以先根据之前就每个WP=>WPJ的捷径分别的链入数排查出来的结果手动进行“先消除链入、后提R2”的工作,但可能会涉及模板链接跟EPWPJ=>WP的捷径应该比较容易处理,可以不用bot。SANMOSA Σουέζ 2021年5月22日 (六) 02:46 (UTC)
我可能可以写,但没时间跑Bot (这一看就知道要跑很久)。 所以到时如果真没人写,我可以提供代码,然后再请有时间的维基人帮忙跑bot。-- 五岁抬☎️·☘️) 2021年5月22日 (六) 03:03 (UTC)
最近现实发生一些状况,暂无法开发Bot。@Sanmosa:,User:LuciferianThomas好像有意愿接手?Wikipedia:机器用户/申请#User:LuciferianBot。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月10日 (四) 11:41 (UTC)
已留意。我支持他这样做。SANMOSA Σουέζ 2021年6月10日 (四) 14:15 (UTC)
@A2569875:可能可以先写代码。我已经处理好所有WPJ=>WP的捷径了,至于WP=>WPJ的捷径我打算先手动处理链入数少的那些,让它们先走快速删除程序。(话说bot是怎样跑的,我不太清楚相关事宜,所以想学一下,之后或许能帮到一些忙)SANMOSA Σουέζ 2021年5月25日 (二) 02:22 (UTC)
Special:PermaLink/65497881更新为Special:PermaLink/65827060SANMOSA Σουέζ 2021年5月28日 (五) 07:04 (UTC)
Draft:WP-WPJ重定向链入数量。--Xiplus#Talk 2021年6月1日 (二) 13:31 (UTC)
@Xiplus:完全没有0链入的数据?SANMOSA Σουέζ 2021年6月1日 (二) 14:56 (UTC)
是,此列表是让你们清理链入的,所以应该没必要列出?--Xiplus#Talk 2021年6月2日 (三) 01:55 (UTC)
有必要列出,清理完链入还要R2速删,0链入的重定向的处理工作最少(但有时候检查链入时还是会发现还有一些链入和引用)。SANMOSA Σουέζ 2021年6月2日 (三) 15:04 (UTC)
@Xiplus:实测过一下,在Module:Template:Delete/data下,只有在WP:MEA挂R2才能显示警告字句,WP:专题/首页的缺失条目显示不到,不知道是怎么一回事。SANMOSA Σουέζ 2021年6月1日 (二) 13:26 (UTC)
没看到编辑记录,你怎么测的?--Xiplus#Talk 2021年6月2日 (三) 02:30 (UTC)
@Xiplus:页面预览功能。现在没事了,我查了一下Mediawiki,发现我不应该用rootText,而应该用text。SANMOSA Σουέζ 2021年6月2日 (三) 15:00 (UTC)
@XiplusA2569875:话说WPBannerMeta的模板应该有隐藏的“Wikipedia:”开首专题链接,不知道是怎么一回事,有空要fix一下。SANMOSA Σουέζ 2021年6月10日 (四) 14:15 (UTC)

参考资料

第六阶段:其他议题讨论

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

  • 以下暂时备注
  1. 方针或指引修订(一点五阶段已修改部分,如有未尽之事宜请在此提出)
    Wikipedia:互助客栈/方针#第一点五阶段:内容事实修订
    Wikipedia:互助客栈/方针#修订CSD#G14
  2. 专题主页与专题委员会存放处
  3. WP空间中的专题介绍、Help的专题说明
  4. 专题指引存放处
  5. 未调整好的模板或模块
  6. 这几个月的使用反馈
  7. 其他未尽之事项
-- 五岁抬☎️·☘️) 2021年5月8日 (六) 19:25 (UTC)

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

WP:捷径指引草案修订

[编辑此导航模板]

说明

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

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

本讨论的各阶段分为:

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

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

专题名字空间通过,剩余细节独立讨论。台湾杉在此发言 (会客室) 2021年1月11日 (一) 11:20 (UTC)
伪名字空间和专题空间都设立了。—- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年3月3日 (三) 05:21 (UTC)
  • 说明剩下的第四点,有部分项目正在等待专题、格式手册、LTA等名字空间的相关议题之讨论或公示。-- 五岁抬☎️·☘️) 2021年4月21日 (三) 02:51 (UTC)
  • 说明专题、格式手册、LTA等名字空间的相关议题之讨论或公示已完成(部分已存档)。本案将继续进行。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月17日 (四) 04:04 (UTC)

专题名字空间问题

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

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

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


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

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

捷径细部修订

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

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

首段建议附加维基专题空间,他们会稍后设立捷径。--LuciferianThomas留言 2021年2月6日 (六) 04:03 (UTC)
(:)回应Wikipedia:互助客栈/方针#第五阶段:讨论重定向与捷径的设立方式讨论已开始。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 2021年2月14日 (日) 09:51 (UTC)
@Taiwania Justo?--LuciferianThomas留言 2021年2月21日 (日) 00:13 (UTC)
目前在忙着RFC以及其他现实生活事务,且目前还有残余议案等待处理,待完全告一段落后再行整理该案。--台湾杉在此发言 (会客室) 2021年2月21日 (日) 03:46 (UTC)
不急,因为#第五阶段:讨论重定向与捷径的设立方式也还在讨论。-- 五岁抬☎️·☘️) 2021年3月17日 (三) 06:43 (UTC)
上述第五阶段将会在适当的时机公示。-- 五岁抬☎️·☘️) 2021年3月31日 (三) 06:50 (UTC)
上述第五阶段曾于2021年4月14日 (三) 03:45 (UTC) 进入公示阶段。-- 五岁抬☎️·☘️) 2021年5月4日 (二) 06:46 (UTC)
说明由于目前有些其他意见,第五阶段公示暂停。-- 五岁抬☎️·☘️) 2021年5月13日 (四) 04:33 (UTC)
上方第五阶段已恢复公示-- 五岁抬☎️·☘️) 2021年5月20日 (四) 06:22 (UTC)
上方第五阶段已公示通过-- 五岁抬☎️·☘️) 2021年5月27日 (四) 09:36 (UTC)
说明上方第五阶段已进行到技术阶段Wikipedia:机器用户/申请#User:LuciferianBot,伪名字空间亦同(半保护案视为无共识或否决),因此方针修订的部分皆已完成。本讨论可继续进行了。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月10日 (四) 11:43 (UTC)
(?)疑问@Taiwania Justo:上述残余议案之处理已接近尾声,请问阁下近期有空整理此案吗?-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月2日 (三) 14:51 (UTC)
正在整理中。--台湾杉在此发言 (会客室) 2021年6月4日 (五) 04:37 (UTC)

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

目前讨论状态:

(更新) -- U:a2569875 UT:a2569875 2021年6月13日 (日) 13:34 (UTC)

参见Wikipedia:互助客栈/求助/存档/2021年4月#请帮忙删除 User:Tranve/工坊/workshop.json,像 JSON 和 Module: 名字空间的页面,速删模板挂不上去。希望可以在方针制度层面解决这个问题。--Tranve () 2021年4月5日 (一) 13:07 (UTC)
[email protected]蟲蟲飛XiplusSunny00217 --Tranve () 2021年4月5日 (一) 13:09 (UTC)
说到这个,才想去WT:TW提案让.json的速删能不能转到AFD之类的呢xxdd-- Sunny00217  2021年4月5日 (一) 13:43 (UTC)
注:可参考英文维基方针。--Tranve () 2021年4月10日 (六) 06:30 (UTC)
同上意见。-门可罗雀的雾岛诊所三天打鱼两天晒网神社的羽毛飘啊飘 2021年4月18日 (日) 03:54 (UTC)

提案1:参考英文维基的模式讨论页放置提删模板

无共识,结以待续并存档:
由于互助客栈内容已经过长,因此,已无共识,结以待续的子议案已先行存档。--U:a2569875 UT:a2569875 2021年5月26日 (三) 04:39 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

说明由于互助客栈内容已经过长,因此,已无共识,结以待续的子议案先行存档,请查阅历史版本或至Wikipedia_talk:快速删除方针#提案1:参考英文维基的模式讨论页放置提删模板查阅先前讨论。--U:a2569875 UT:a2569875 2021年5月26日 (三) 04:39 (UTC)


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

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

无共识,结以待续并存档:
由于互助客栈内容已经过长,因此,已无共识,结以待续的子议案已先行存档。--U:a2569875 UT:a2569875 2021年5月26日 (三) 04:39 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

说明由于互助客栈内容已经过长,因此,已无共识,结以待续的子议案先行存档,请查阅历史版本或至Wikipedia_talk:快速删除方针#就规范部分特殊页面的删除方式征求社群建议查阅先前讨论。--U:a2569875 UT:a2569875 2021年5月26日 (三) 04:39 (UTC)


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

引入能够在特殊页面挂模板的模块

已通过并存档:
由于互助客栈内容已经过长,因此,已通过的子议案已先行存档。(原议案通过时间 2021年5月7日 (五) 13:45 (UTC))-- 五岁抬☎️·☘️) 2021年5月25日 (二) 09:59 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

说明由于互助客栈内容已经过长,因此,已通过的子议案先行存档,请查阅历史版本或至Module talk:Module wikitext#引入能够在特殊页面挂模板的模块Module talk:Documentation#引入能够在特殊页面挂模板的模块MediaWiki talk:Scribunto-doc-page-does-not-exist#引入能够在特殊页面挂模板的模块Module talk:Special wikitext#引入能够在特殊页面挂模板的模块MediaWiki talk:Clearyourcache#引入能够在特殊页面挂模板的模块查阅先前讨论。-- 五岁抬☎️·☘️) 2021年5月25日 (二) 09:59 (UTC)


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

技术案:处理状况

项目 办理状况 需编辑的页面 页面patch 效果预览
Module 完成 Module:Module wikitext (已布署) Module:沙盒/a2569875/ModuleWikitextDemo
完成编辑请求 Module:Documentation Module:Doc...sandbox
完成编辑请求 MediaWiki:Scribunto-doc-page-does-not-exist User:A25...-does-not-exist
(需要语言变种微调)
JS、CSS 完成 Module:Special wikitext (已布署) 留言WP:TG1) 、 互连群图床
完成编辑请求 MediaWiki:Clearyourcache User:A25...yourcache
(需要语言变种微调)
JSON 完成模板已可放置
开发中分类问题开发中
phab:T235798 gerrit:r/c/543934
WP:模板样式 完成编辑请求 修改方法见Template...SpecialWikitext 图像图床对应页面
页面预览功能 完成编辑请求
(注:防预览原码过长414 Error)
T:Special....sandbox.js
WP:TW 火速赶工中...... Xi-Plus/twinkle #222 copyvio/speedy/xfd: Handle non-wikitext pages
方针 公示完成 Wikipedia:快速删除方针 Special:Diff/65468329 #方针注记案
总进度 85% (项目8.5/10) 搁置项目
  • JSON分类
  • LUA已删预览
  • TW小工具
已实行项目
  • 挂模板功能
  • 已删预览
不适用
(更新)-- 五岁抬☎️·☘️) 2021年5月8日 (六) 05:29 (UTC)
更新办理进度75%-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年5月30日 (日) 09:46 (UTC)

技术案阶段二:页面预览功能

已通过并存档:
由于互助客栈内容已经过长,因此,已通过的子议案已先行存档。(原议案通过时间 2021年5月25日 (二) 09:06 (UTC))-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月8日 (二) 12:56 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

说明由于互助客栈内容已经过长,因此,已通过的子议案先行存档,请查阅历史版本或至MediaWiki talk:Gadget-SpecialWikitext.js#技术案阶段二:页面预览功能查阅先前讨论。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月8日 (二) 12:56 (UTC)


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

技术案阶段二点五:JSONFLOW讨论页纯文字分类BUG问题

(节删)以下为在WP:TG/IRC中关于JSON分类问题的讨论之部分节录(注:下方工单指的是phab:T235798,关于JSON分类无法正确归档问题的工单)

  • 工单布署后。所以现在可能需要讨论工单布署前的时期怎么渡过 -- User:A2569875 5月8日 11:38 (UTC+8)
  • “Re [T - a2569875] : 暂时要用什么解决方案呢?”暂时维持现状吧 -- User:Antigng 5月8日 11:38 (UTC+8)
  • IE11 这两个 keyword 大部分功能都是支持的,但是站内好像没有小工具使用。 是因为什么呢?-- User:Tranve 5月8日 11:39 (UTC+8)
  • 因为mediaWiki似乎会先parse过 连样板字面值都会坏掉-- User:A2569875 5月8日 11:39 (UTC+8)
  • 怎么说呢,多亏了IE让我们写前端代码的想(节删)-- User:MilkyDefer 5月8日 11:39 (UTC+8)
  • 加不进分类可能没好办法,总不能让机器人实时监视吧 那样开销太大了 而且也没有实时性 不符合CSD的宗旨 -- User:Antigng 5月8日 11:39 (UTC+8)
  • “Re [T - a2569875] : 现状是指,挂完模板后 找一个管理员处理?”对 -- User:Antigng 5月8日 11:40 (UTC+8)
  • (ES6支援什么时候才到啊-- J C 5月8日 11:40 (UTC+8)
  • 然后管理员不用担心所谓“被陷害的问题”——现在先不管这是真问题还是伪问题——假定是真问题 因为条目删除的时候页面上的确有模板存在 虽然部分维持现状但是相较于过去的处理方式也有所进步 -- User:Antigng 5月8日 11:42 (UTC+8)
  • 这个就算是大耀进了吧 -- User:A2569875 5月8日 11:43 (UTC+8)

以上。(一些可能不雅的词汇已{{节删}})-- 五岁抬☎️·☘️) 2021年5月22日 (六) 08:55 (UTC)

  • 目前除了等待phab布署外,还有一个方式,即用页面搜索方式汇整有“_addText”的JSON页,
    算法如下(实作于User:A2569875/JSONCAT.js):
    ① 用页面搜索功能全站全文搜索“_addText”关键字,
    ② 整理出该页中内容模型为JSON的页面(可能位于任何名字空间),
    ③ 送一次API:parse并分析分类,
    ④ 整理各页面的分类,并显示出来,
    然而由于其中用到的十分高开销的页面搜索功能全站全文搜索(insource:)因此就不提议全站引用。
    此方法已知缺点
    • 高开销,运作速度缓慢
    • 页面搜索功能对内容可能会有数小时至数天的延迟
    我的看法
    • 让有想处理JSON速删的管理员安装JSON分类工具即可
    • 页面搜索功能功能虽有延迟,但还是会被索引到的吧,再怎么慢也不会慢于AFD
    以上,请讨论。-- 五岁抬☎️·☘️) 2021年5月25日 (二) 11:00 (UTC)
    @A2569875:我有一个方案:要不先创建一个Wikipedia:特殊页面的快速删除请求,让 JSON 的速删请求堆到这里来?我不想让 AFD 处理,这样会和 AFD 的原有功能混淆。既然小工具没有优雅的做法,还不如这样干。--Tranve () 2021年6月17日 (四) 11:46 (UTC)
    那就是要监视进期更改扫描把他扫出来?-- Sunny00217  2021年6月20日 (日) 01:21 (UTC)
    (:)回应@Sunny00217:不用吧。根据下方方针修订案条文“...由于技术限制,在JSON、FLOW讨论页、纯文字放置模板后暂时不会自动被加入分类,因此在提删此类页面时可能还需要另外通知一位管理员来执行删除...”,无法被MediaWiki“自动加入分类”的特殊页面仅有三种JSONFLOW讨论页纯文字,因此流程可以照走,模板照挂,或许设置TW在该3种技术限制的特殊页面挂模板后自动让他转发到User:Tranve提议的“Wikipedia:特殊页面的快速删除请求”也不失一个好办法。毕竟“...需要另外通知一位管理员来执行删除...”也太空泛,整合成“Wikipedia:特殊页面的快速删除请求”或许是一个不错的方案。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月20日 (日) 03:04 (UTC)
    我的意思是用机器人扫进期更改然后贴到Wikipedia:特殊页面的快速删除请求啦qwq-- Sunny00217  2021年6月20日 (日) 03:25 (UTC)
    提报人自己贴过去不是更有效率?而且FLOW讨论页机器人能够有效扫描吗?-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月20日 (日) 03:33 (UTC)
    flow讨论页的内容的内容模块不是json阿-- Sunny00217  2021年6月20日 (日) 03:48 (UTC)
    (※)注意无法被MediaWiki“自动加入分类”的特殊页面有三种JSONFLOW讨论页纯文字。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月20日 (日) 03:50 (UTC)

技术案阶段三:WP:TW

  • 若前面阶段顺利布署,接着的步骤主要是要让相关放置维护模板之工具能符合上述技术修改,详见#206 : speedy/xfd: Add delete-templates on non-wikitext pages#215 : morebits: Add addMaintenanceTag。-- 五岁抬☎️·☘️) 2021年5月20日 (四) 08:22 (UTC)
    • 有鉴于上方技术案的公示即将进入尾声,想请教一下(?)疑问@Xiplus:目前#215 : morebits: Add addMaintenanceTag的办理进度大致上到哪个阶段了? 以便决定接下来是要搁置还是继续推行方针修订案。感谢-- 五岁抬☎️·☘️) 2021年5月25日 (二) 03:29 (UTC)
      请直接进行方针修订案。--Xiplus#Talk 2021年5月25日 (二) 03:36 (UTC)
      除非技术有困难,否则通常是小工具依循方针改变。Twinkle作为常用的小工具,进行事前咨询及事后告知是好的做法,但Twinkle也只是众多小工具之一,小工具不支援并不会阻止你们以此种方式提删,你们还是可以手动按照这个规则进行编辑来提删,所以Twinkle在此不应成为一个阻碍。当然Twinkle总有一天会跟上(近期繁忙见谅),以上。--Xiplus#Talk 2021年5月29日 (六) 15:03 (UTC)

技术案阶段四:试行期反馈

方针注记案

已通过:
公示结束,通过-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月16日 (三) 06:39 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

  • 搁置中...,等待上方公示。在技术案公示结束并布署完成之前请先在上方章节讨论。-- 五岁抬☎️·☘️) 2021年5月3日 (一) 04:01 (UTC)
    • 上方议案已公示并布署,且WP:TW维护者指出先继续跑完修订案,因此本节再度开放。-- 五岁抬☎️·☘️) 2021年5月25日 (二) 09:25 (UTC)
现行条文

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

提议条文

……

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

  • JSON页面:请在根据页面的格式加入语法:
    • 最外层的格式为花括弧{...}的JSON页面(示例),将以下语法放置在最外层的{...}之内:(参考示例
      "_addText":"{{Delete|快速删除理由}}",
    • 最外层的格式为中括弧[...]的JSON页面(示例),将以下语法放置在最外层的[...]之内:(参考示例
      {"_addText":"{{Delete|快速删除理由}}"},
    • 如JSON页面无最外层格式(示例),请将原有的JSON源代码置入中括弧[...]中,并以最外层的格式为中括弧的JSON页面放置删除模板。(参考示例
注:如要加入JSON的行位于最外层之花括弧{...}中括弧[...]内部的最后一行,请移除行尾的逗号(,)。
  • 位于模块名字空间的页面(文档页面除外):请在需要删除的页面中加入以下语法:
    require('Module:Module wikitext')._addText('{{Delete|快速删除理由}}')
  • CSS页面:请在需要删除的页面中加入以下语法:
    ._addText{
    	content:"{{Delete|快速删除理由}}";
    }
    
  • JavaScript页面:请在需要删除的页面中加入以下语法:
    var _addText="{{Delete|快速删除理由}}";
  • 纯文字CSS(包括“已过滤的CSS”)和JavaScript(不包括JSON)也能通过在需要删除之页面的注释中加入以下语法来放置模板。
    /* _addText: "{{Delete|快速删除理由}}" */
  • 对于部分有特殊编辑界面的特殊页面(如FLOW讨论页大量讯息发送列表等)请直接将提删模板放置于对应页面的描述或摘要字段即可。
    例如,提删FLOW讨论页时,请使用“编辑话题摘要”功能将{{Delete|快速删除理由}}填入;而提删大量讯息发送列表时,请将提删模板放置在“描述”字段中。
注:由于技术限制,在JSONFLOW讨论页纯文字放置模板后暂时不会自动被加入分类,因此在提删此类页面时可能还需要另外通知一位管理员来执行删除。

管理员操作注意事项 ……

准备中...-- 五岁抬☎️·☘️) 2021年5月3日 (一) 04:01 (UTC)
  • 其实只要在管理员讨论页留句话,管理员已经可以很简单地处理了。--虫虫飞♡♡→♡℃留言 2021年5月26日 (三) 06:03 (UTC)
    • (?)疑问@蟲蟲飛:还是要挂模板吧?目前技术上已经完全克服挂模板问题,所有页面都能挂模板了。您不是会怕提删时没挂模板会“陷管理员于不义”吗?指引注记“模板怎么挂”有什么问题吗?“注:由于技术限制,在JSONFLOW讨论页纯文字放置模板后暂时不会自动被加入分类,因此在提删此类页面时可能还需要另外通知一位管理员来执行删除。”正是在指引页提示“需要另外通知一位管理员来执行”理应跟您于 2021年5月26日 (三) 06:03 (UTC) 的留言没有冲突。(节删)。-- 五岁抬☎️·☘️) 2021年5月26日 (三) 06:15 (UTC)
  • 您误会了人家的话,您说要通知管理员,通知的方法很多,可以到管理员讨论页留言,当然您也可以ping管理员。--虫虫飞♡♡→♡℃留言 2021年5月26日 (三) 06:32 (UTC)
    • 我认为方针指引没有必要限制或指定用户通知管理员的方式,认为提议条文中的“通知管理员”并无不妥。-- 五岁抬☎️·☘️) 2021年5月26日 (三) 06:41 (UTC)

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

订立影片加入相关指引

我发现最近有很多条目中都被加入了影片,虽然其中不少都对条目大有裨益,但是我也发现相当一部分条目中被加入了与条目本身关系不大的内容或与条目本身不对称的内容(比如在青藏高原条目加入中科院院士的演讲影片和在小条目加入长达20分钟的影片),所以想请问一下社群是否需要订立相关指引来规范条目中的影片加入?--Newbamboo留言) 2021年4月20日 (二) 04:11 (UTC)

谢谢,这个是我在Telegram提起来的,WP:AGF的话是我确定这些内容是对维基百科的内容大有益处(尤其很多内容是我们这些普通编者很难接触到或者获取到的)的也非常感谢把他们传到commons的同仁,但是视频尤其新闻报道可能会涉及WP:NPOV的问题,即使没有NPOV问题也涉及到篇幅的问题(一个小作品里出现几十分钟的视频肯定是读者没有耐心去看的),我想了一下,有以下几个点可能可以改进:
  1. 针对新闻视频,提供新闻供稿人的名称,供读者自行辨识观点。
  2. 针对过长的视频,考虑进行剪辑或者进行截图,然后将截图插入条目进行展示。
  3. 或者如果实在认为新闻信息对条目非常宝贵,将新闻视频转写成文字的形式作为来源扩充条目。
不知道各位意向如何?--ParkerTian 2021年4月20日 (二) 04:21 (UTC)
@NewbambooPark1996:已有相关规范,见WP:VUPSANMOSA Σουέζ 2021年4月20日 (二) 04:28 (UTC)
虽然说针对视频资料过度使用影响阅读体验的问题,去年就已经修订相应方针来加以限制。不过就现在的情况来看,相关方针执行力度并不算强。--🔨留言) 2021年4月20日 (二) 06:25 (UTC)
@Liu116:有什么条目是违反相关方针的,请列出来,我动手清理一下,有人回退的话,我就依方针提报。SANMOSA Σουέζ 2021年4月20日 (二) 12:55 (UTC)
……这个我没法完整列出,我顶多只知道脱贫攻坚战条目中原本被移除掉的视频后来又都被加了回来,还有2019冠状病毒病疫苗条目,以及部分“202X年X月中国大陆”的条目也有这样的问题。--🔨留言) 2021年4月20日 (二) 13:08 (UTC)
我看到的是驻港部队有过多视频。好像很多都是WG君加入的,能不能跟他说一下让他自己改正呢--ParkerTian 2021年4月20日 (二) 18:33 (UTC)
当中两段影片未获正文提及,另有一段与正文关系不够密切,已代为删除。--Yangwenbo99 2021年4月20日 (二) 23:33 (UTC)
对于“加入影片”这一行为,已有相关规定——Wikipedia:文件使用方针#使用守则,即必须同时满足
  1. 与条目有密切关连、
  2. 在条目内文有所提及、
  3. 符合中立的观点(包括旁白、注释),且比重需合理,及
  4. 仅保留具代表性之文件,每条目一般不应同时存在多于五条影片。
而若在无共识的情况下将原本被删除的影片重新加入,即属蓄意挑起WP:编辑战
建议加入一条“一般而言,新闻报导与条目所论述内容有关,并不代表其内容与条目主题直接相关。仅在该影片所论述之内容本身为所在条目或所在章节之主要论述内容时,方可被认为与条目主题直接相关。
另外,可以考虑将与内容相关,但是不便加入条目的影片放置于外部链接当中。甚至可以订立指引,表示外部链接中可以设一节放置相关影片,以及规定收录影片的标准。
此外,同意就编辑影片以便加入条目订立指引。
以上。--Yangwenbo99 2021年4月20日 (二) 23:26 (UTC)
我总结一下上面的意见,并得出以下的提议条文:

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

虽然说追加视频时长的限制是好事,不过就目前的情况来看比起进一步追加条文,我觉得更重要的还是解决执行力的问题……不然加再多条文也没用……--🔨留言) 2021年4月21日 (三) 04:56 (UTC)
这可能要请管理员长期持续监察才能成事。SANMOSA Σουέζ 2021年4月21日 (三) 08:54 (UTC)
(-)反对:原有条文足矣,不必更易。这些问题不是条文的问题,而纯属执行力问题。--痛心疾首 2021年4月21日 (三) 07:24 (UTC)
原有条文的执行力差,部分原因是条文本身部分论述较为笼统,所以应当具体化。如“仅保留具代表性之文件”,但对于文件长度的要求未有规定。以及未有规定如何处理不应放置于内文,但有相当重要性的影片。--Yangwenbo99 2021年4月21日 (三) 15:31 (UTC)
意见大致同Liu116阁下及痛心疾首阁下。若方针无人执行,增加再多规范也是无用。—— Eric Liu 创造は生命(留言留名学生会 2021年4月21日 (三) 12:57 (UTC)
过滤器能不能帮忙?SANMOSA Σουέζ 2021年4月22日 (四) 04:07 (UTC)
@Sanmosa:可以设立过滤器“标签”“条目同时存在多于五条影片”的情况;但是既然方针规定“一个条目一般不应同时存在多于五条影片”,设立过滤器加以警告乃至阻止就需要社群共识后才能设立。--Antigng留言) 2021年4月22日 (四) 05:51 (UTC)
@Antigng:既然技术上过滤器能帮忙,我尝试征求社群对过滤器的意见,有共识的话就有劳你代为设立了。SANMOSA Σουέζ 2021年4月25日 (日) 08:07 (UTC)
@Liu116痛心疾首Yangwenbo99Ericliu1912:不好意思,最近疏于关注了。上面Antigng指出了技术上可以以过滤器防止条目同时存在多于五条影片(我估计技术上也可以以过滤器防止加入曾被移除的影片),因此我建议设置过滤器,阻止使条目同时存在多于五条影片的操作,并对加入曾被移除的影片的操作予以警告,同时对此两类操作予以标签。相信此提议应可增强相关方针的执行力度,还请各位发表意见。SANMOSA Σουέζ 2021年4月25日 (日) 08:07 (UTC)
加入超过五条影片,偶尔也是合理的。例如化学史的条目,如果有编者分别为不同时期的历史制作影片并放入对应章节,那么即使超过五条也依旧可以接受。使用过滤器强制条目中影片数量少于五条则完全否定了这种行为的正当性,并且会衍生大量技术问题。例如,有编者将原本冗长的一条影片提换成两条截取至原影片的精炼影片,则可能因为增加影片被阻拦。私以为过滤器可以用于提供警告,但不适宜直接禁止。--Yangwenbo99 2021年4月25日 (日) 08:46 (UTC)
@Yangwenbo99:此情况罕见。而且方针已明定加入超过五条影片者要给予合理解释,也即是须先取得社群共识方得为之。这种情况下,应先取得社群共识,然后到过滤器错误回报区请求代为加入。(另一办法是对所有使条目存在超过五条影片的编辑予以警告。)SANMOSA Σουέζ 2021年4月30日 (五) 05:35 (UTC)
我认为应该予以一次警告并进行标记,阻止不是必需的。--痛心疾首 2021年5月5日 (三) 15:46 (UTC)
VUP没有通过的话确然如此,然而这已经被现在已经通过的VUP明确为属于违反方针的举动了,这样阻止反而是必需的。SANMOSA Σουέζ 2021年5月6日 (四) 01:54 (UTC)
Sanmosa所以现在打算如何?—— Eric Liu 创造は生命(留言留名学生会 2021年5月21日 (五) 13:56 (UTC)
Ericliu1912我分成两个提案(如下),这样做的原因是社群成员对于条文执行力低下的原因有不同的解读,而部分提案(或解决办法)也并非单纯只处理条文执行力低下的问题。SANMOSA Σουέζ 2021年5月22日 (六) 02:23 (UTC)

分案A

建议设置过滤器,阻止加入曾被移除的影片的操作(通过Twinkle或回退功能恢复加入则不阻止),并对所有使条目同时存在多于五条影片的操作予以警告,同时对此两类操作(无论是否已被阻止或警告)予以标签(注意此处的表述和我一开始的建议的表述有差异)。此分案与分案B可以分开处理。SANMOSA Σουέζ 2021年5月22日 (六) 02:23 (UTC)

  • 我不建议直接阻止,但可以警告或过滤器标记。阻止加入曾被移除的影片的操作,但通过Twinkle或回退功能恢复加入则不阻止,纯属掩耳盗铃,但直接阻止会便宜了破坏者。--痛心疾首留言) 2021年5月26日 (三) 14:44 (UTC)

@Sanmosa:或可先处理A案。—— Eric Liu 创造は生命(留言留名学生会 2021年6月10日 (四) 01:00 (UTC)

分案B

建议修改‘影片适用的使用守则’部分如下:

以上。此分案与分案A可以分开处理。SANMOSA Σουέζ 2021年5月22日 (六) 02:23 (UTC)

  • 本人(-)反对长期未经讨论共识而强行重新加入遭到非破坏性移除的影片,或长期在未作出合理解释的情况下在大量条目内加插多条影片的用户则会被视为长期破坏者,应予以较长时间的封禁”这一段。长期未经共识而编辑战本就是封禁理由,但长期编辑战和破坏无关。你维对破坏的定义是“通过增删或修改内容,故意危害维基百科正确性与完整性”,假如添加的内容和条目相关,则绝无可能是破坏行为,为何要被视为长期破坏者?假若他真的反复加入猥亵内容,那就是破坏,什么叫做视同破坏?既然上文已经规定了合理措施,那就是执行力度问题。综上,显而易见,新增条文和上文是重复且完全矛盾的。--痛心疾首留言) 2021年5月25日 (二) 05:38 (UTC)
@痛心疾首:即使添加的内容和条目相关,仍有可能是破坏行为,见WP:NOTGALLERYSANMOSA Σουέζ 2021年5月26日 (三) 00:01 (UTC)
NOTGALLERY啊,那不是破坏WP:VAND定义何为破坏。而且阁下离题了,这里的问题是用户固执己见加入图片,《破坏》方针称,“这的确令人遗憾,但不是破坏行为”。我认为提案人根本没明白什么叫破坏。本案通过无助于任何问题,只能给特定加文件的人扣破坏的帽子而已。--痛心疾首留言) 2021年5月26日 (三) 01:11 (UTC)
@痛心疾首WP:VAN:“图片破坏:以破坏性的方式上载或使用文件”、“只要这些文件具有百科全书性,并且使用在合适的地方,这种上载/使用就不属于破坏”。WP:VUP其实算是某程度上已经界定了使条目同时存在多于五条影片的操作与加入曾被非破坏性移除的影片的操作为“破坏性的方式使用文件”的一种,并且不属于文件“使用在合适的地方”的情形,那这样的修订自然是合理的。再退一步来说,WP:VAN:“破坏类型:常见的破坏性编辑通常具有以下一个或多个特征”,使条目同时存在多于五条影片的操作与加入曾被非破坏性移除的影片的操作也可以算成“非常见的破坏性编辑”,因为这条文是之前有个别用户故意大规模加入大量影片到不同的条目里头才出现的,这不是过往会见到的问题,但出现有人仿效的情形,所以才立例。SANMOSA Σουέζ 2021年5月26日 (三) 14:01 (UTC)
WP:VUP其实算是某程度上已经界定了使条目同时存在多于五条影片的操作与加入曾被非破坏性移除的影片的操作为“破坏性的方式使用文件”的一种[来源请求]
阁下还是离题了。这里的问题根本不是进行图片破坏,也根本不是所谓的非常见破坏性编辑。请参见破坏的根本定义,即“故意危害维基百科正确性与完整性”。假若相关用户加入的内容是相关的,那就并未故意危害维基百科正确性与完整性,显然就不是破坏。用其他方针定义超出这个定义范围的“破坏”是危险的,因为这会让破坏的概念泛化,从而变成一个人人皆可得而扣之的帽子。Antigng--痛心疾首留言) 2021年5月26日 (三) 14:31 (UTC)
@痛心疾首Antigng:不,只要社群的共识认为某种行为是破坏,那该种行为就是破坏,我认为当初WP:VUP的制定本身就体现了这点。退一步来说,这方针算是从一开始就假定影片都会“危害维基百科正确性与完整性”,因此需要加入的用户自行举证相关影片不会“危害维基百科正确性与完整性”(这部分是原本的条文就有的)。SANMOSA Σουέζ 2021年6月1日 (二) 09:32 (UTC)

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

再次推动破坏者(LTA)成为名字空间

首批伪名字空间已行月余,我希望推动LTA成为真·名字空间。好处是可以设置所有页面为NOINDEX,增设页面查看权限(体现WP:RBI),且不会被其他名字空间的设置档左右。此外,LTA与Project空间联系性不大,没有维护问题。

至于LTA页面数量少。窃以为设立名字空间没有页面数量门槛。另附先前讨论之部分内容:

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

随着讨论发展,由于确有如此需求,我不反对设LTA为真名字空间。SANMOSA Σουέζ 2021年4月25日 (日) 08:34 (UTC)
(1) wgNamespacesToBeSearchedDefault本来就预设条目空间,Wikipedia空间本来就不在列,等于LTA页面目前就是预设关闭的,增设名字空间没有改变现状。 (2) 目前所有LTA页面都透过NOINDEX魔术字来指示爬虫不索引了,增设名字空间没有改变现状。 (3) 可能是好主意,但没有有效的技术手段达成(安装扩充功能无望,CSS相当容易绕过...等)--Xiplus#Talk 2021年4月25日 (日) 09:48 (UTC)
基于WP:BEANS,应该还是要隐藏一下(((-- Sunny00217  2021年4月25日 (日) 11:44 (UTC)
如果仅用CSS,不需增设名字空间也能达到,这样上方所列的三个需求都不需要增设名字空间了。--Xiplus#Talk 2021年4月26日 (一) 09:21 (UTC)
会搜到重定向页?SANMOSA Σουέζ 2021年4月30日 (五) 06:03 (UTC)
实际上也只有那一个例子,整体来说,重定向应是全部都不索引的。--Xiplus#Talk 2021年5月5日 (三) 01:41 (UTC)
Sanmosa意见,如现在确实有此需求,不反对设立,反正设这个没有WPJ那么乱XD--LuciferianThomas留言 2021年4月26日 (一) 09:12 (UTC)
@LuciferianThomas:WPJ麻烦的是移动和模板模块处理而已,吧?-- Sunny00217  2021年4月26日 (一) 09:47 (UTC)
第三点同Xiplus。要真正实现仅特定用户组可查看,只能通过后端。在判断逻辑甚至页面内容都已经发给前端情况下…是在掩耳盗铃。--安忆Talk 2021年4月27日 (二) 11:44 (UTC)
如果目的在避免普通访客被记载方式干扰和误导,而非保密性,掩耳盗铃未尝不可。类似,具有权限要求的某些内容(如已删除版本)或功能(如回退),并不限制其他用户用别的手段做到。--YFdyh000留言) 2021年4月28日 (三) 09:56 (UTC)
只要求在表面上看不见全放在前端当然没什么问题。(另,回退不要后端鉴权吗?)--安忆Talk 2021年4月28日 (三) 12:40 (UTC)
js可以实现与回退效果几乎等价的操作。—- 五岁抬☎️·☘️) 2021年4月28日 (三) 13:05 (UTC)
加个class?--LuciferianThomas留言 2021年4月28日 (三) 22:45 (UTC)
是可以透过LUA写脚本让后端不要输出页面内容,前端在用JS判断权限后,再向后台要源代码以AJAX填入内容。这样是可以在“用户检视页面”的层面达到权限控制之内容隐藏,但问题是,这个很好破解,任何人只要按下编辑就能从页面源代码看到内容,即使页面被保护了,源代码也是能够被所有人阅读的....(而且想破内容的人只要研究前端发送AJAX的方式照样能得到内容,即使LUA端写了加密校验码也没用,Module空间的信息都是能公开检视的.....mw:Extension:Lockdown扩展的第一行也有说,不保证其“不会被绕过”...)-- 五岁抬☎️·☘️) 2021年5月19日 (三) 14:12 (UTC)
  • 如果是追求保密性的话,倒不如放在其他网站及仅容许某些人士浏览。使用css和js来避免被浏览,尤其是LTA,在个人来看就是自欺欺人。当然如果仅是用来避免普通访客浏览,这不失是个好方法,但意义不大(真的会有普通访客特地浏览LTA页面吗?)。--SCP-0000留言) 2021年4月30日 (五) 18:46 (UTC)
我补充一个意见:我认为不需设置LTA页面的检视权限,但这并不影响LTA空间的设立必要性。SANMOSA Σουέζ 2021年5月1日 (六) 01:41 (UTC)
可以试试看 如果说明是反破坏用的,维基媒体会不会启用? ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月4日 (二) 10:59 (UTC)
(?)疑问你是指新插件?—- 五岁抬☎️·☘️) 2021年5月4日 (二) 16:20 (UTC)
Green tickY mw:Extension:Lockdown-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月5日 (三) 11:18 (UTC)
请问您熟悉Phab站吗,能不能帮忙提一下?-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月12日 (三) 04:59 (UTC)
关于其社群,不熟。 我也只提供过一次程式码,即专题空间而已。-- 五岁抬☎️·☘️) 2021年5月19日 (三) 13:38 (UTC)
有人可以协助评估一下可行性吗?-- 五岁抬☎️·☘️) 2021年5月27日 (四) 09:31 (UTC)
说实话,我觉得可以像SCP2000君一样,单独开一个wiki(就像已删百科)且只对回退员等有反破坏类权限的用户开放,这从根本上防止了被绕过的问题。--What color are you, Sibyl System? |欢迎订阅维猫报! 2021年5月27日 (四) 12:14 (UTC)

有个疑问。假如LTA页面不对全体自动确认用户开放,而只对有更高权限的用户开放,那么,对于想要申请权限的用户怎么考查?之前有人拿LTA创建的条目来考核一个人的巡查员申请。会不会出现死循环的尴尬场景? --Milky·Defer 2021年5月29日 (六) 13:19 (UTC)

我想可以第一次申请都是临时授权,在第二次申请的时候进行这样的考核。--What color are you, Sibyl System? |欢迎订阅维猫报! 2021年5月30日 (日) 12:19 (UTC)
@羊羊32521wikt:en:AFAICS,据我所知-- Sunny00217  2021年6月6日 (日) 12:12 (UTC)
看起来好像是要我们去meta:Tech问问?然后,同时也要跑一遍mw:Writing_an_extension_for_deployment的流程?(我不太确定。)-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月6日 (日) 14:44 (UTC)
显然是要我们去咨询“meta:Tech”,但是我对meta:Tech不熟,谁可以去帮忙问问?-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月10日 (四) 14:31 (UTC)
@羊羊32521:—- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月18日 (五) 11:42 (UTC)
已在meta提问。另,User:DreamerBlue在站外提醒:
也许我们应该先试看 能不能 在不启用扩展的情况下 设立名字空间?-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年6月19日 (六) 03:41 (UTC)
(~)补充:作者已入职WMF。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年6月19日 (六) 13:51 (UTC)

“格式手册/两岸四地用语”之国籍章节规定"PRC国籍"应该直接写为"中国国籍"的中立性问题

已通过:
经过公示7日,无反对意见,一致通过。--路西法人留言 2021年6月6日 (日) 23:07 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

(注:此讨论章节原本附属于“格式手册对于国籍的规定有缺陷,有用户借此删除知名人士的前国家国籍”的讨论章节底下,于2021年5月10日 (一) 10:32(UTC)独立出来成为新的讨论章节)

  • 发现一个很明显的问题:Wikipedia:格式手册/两岸四地用语内容本身似乎自相矛盾,前后相互对打。格式手册的前面的大原则已经说了:“在描述国家或政权时,应尽量以确切的国家或政权名称取代“中国”一词,以避免歧义。如:“大清/清朝”、“中华民国”和“中华人民共和国”等”,“在1949年之后的相关条目中,应尽量使用中华人民共和国和中华民国等全称”。但是在相同页面的Wikipedia:格式手册/两岸四地用语#国籍章节的样式4:[[中华人民共和国|中国]][2]却直接违反这个大原则。

去年底的Wikipedia:避免地域中心方针版本明确说明:“故此“中国”一词不应该与任何单一独立政治实体或政府相当,尤其不应被用作表述现时属中华人民共和国管治下的地区[3],改版后大方向与精神没变,但是Wikipedia:格式手册/两岸四地用语#国籍章节却偏偏很突兀故意一直写着“中国”一词,而且Wikipedia:格式手册/两岸四地用语#国籍章节将1949年--1971年间的"中华人民共和国"直接独占简称"中国",Wikipedia:格式手册/两岸四地用语#国籍章节完全无视"中华民国"在此时期为大多数国际社会与联合国所认定"代表中国"的事实,就逻辑来说,此格式手册的"国籍章节",难道没有违反中立、占人便宜的问题?--Barter84留言) 2021年5月7日 (五) 12:29 (UTC)

国籍的表达有国际标准(具中华人民共和国国籍者会直接被标注为“CHINESE”),且{{CHN}}使用量过大,不能全数清理(即使以bot清理亦不可能,大概会动到数以十万计的页面,请自行请教熟悉技术的管理员),因此有此折衷设置。另条文已指明与中华民国相对时仍当用{{PRC}}(或{{PRC-HKG}}、{{PRC-MAC}})。SANMOSA Σουέζ 2021年5月7日 (五) 12:47 (UTC)
@Barter84SANMOSA Σουέζ 2021年5月7日 (五) 12:53 (UTC)
(*)提醒,请诸位注意,""指定样式表"的"指定样式4":[[中华人民共和国|中国]],这种写法已经越线了,现今的中国国籍并非全等同于中华人民共和国国籍;就现实面而言,现今的中国政权也并非全等同于中华人民共和国,华人世界也并非都认同中华人民共和国的一中原则,去年底讨论的用户,是不是没有去详细审视这一处的编辑会造成与事实有所落差并且会引发不同意见者的争端?--Barter84留言) 2021年5月9日 (日) 01:22 (UTC)
@Barter84:你这不是在断章取义吗,“在1949年之后的相关条目中,应尽量使用中华人民共和国和中华民国等全称”后面还有一句“若单一条目内的‘中国’一词指涉对象相同,可使用置顶模板宣告条目内的‘中国’指涉政权为何”,挂{{China means|PRC}}已经可以处理,指引本来就已经容许这样做。另一方面,我也早已说明现时护照对国籍显示的国际标准中,中华人民共和国国籍会直接被标示为“CHINESE”(“中国籍”)。再者,如果出现需与中华民国国籍并列的情况,条文也已经说明这种情况下就只能用指定样式7。我也直接说清楚好了:请不要在看指引时看一半不看一半,如果你继续进行断章取义,我会将你视作游戏规则,并直接交由管理员处理(虽然我并不希望如此)。SANMOSA Σουέζ 2021年5月9日 (日) 04:05 (UTC)
@Sanmosa:阁下所说的这个叙述难道不是去年底才生出来的?而且还是阁下放进来维基百科:格式手册/两岸四地用语的。维基百科:格式手册/两岸四地用语的修改频率很高,而且这个格式指引只要求"尝试遵守",此格式指引上方的模板写着:“用户应该尝试遵守此指引。如果出现例外情况,最好使用常识判断此指引是否合适。”维基百科:避免地域中心方针有要求维基百科本身的两岸政治用语要使用国际标准吗?大家都知道中华人民共和国联合国系统的势力有多大,阁下确定维基百科的两岸政治用语就是得走国际标准那一套吗?请阁下公开表态。--Barter84留言) 2021年5月9日 (日) 07:03 (UTC)
当时如此条文的订立某程度上也是为了避免大规模替换“中国”一词,这里我建议你参考先前的讨论。另一方面,还是回到{{CHN}}使用量过大,即使用bot也不能全数清理的问题,我就不重复了。就现状而言,条目行文上,没国际标准的、一般性的东西(大部分情况下)一般无须参考非中文圈用语;有国际标准的东西(少部分情况下)则基本上依循国际标准,在这部分情况下真的出现极端情形才会脱轨(如Wikipedia:格式手册/两岸四地用语#非官方机构及国际活动所提及到的情形)。另:Wikipedia:格式手册/两岸四地用语有此规定(说明):“请注意,由于以下规范皆基于《避免地域中心方针》〈政治〉一节,因此违反本格式手册者必同时违反《避免地域中心方针》规定。”SANMOSA Σουέζ 2021年5月9日 (日) 08:13 (UTC)
此次修订的目的不在中华人民共和国国籍,而是两岸四地过去的日籍、英籍和葡籍,我不希望浪费时间在与修订的目的无关的话题上。SANMOSA Σουέζ 2021年5月9日 (日) 08:23 (UTC)
(:)回应@Sanmosa
  1. 敝人检讨的是维基百科:格式手册/两岸四地用语本身的问题内容,阁下可以不要一直拿维基百科:格式手册/两岸四地用语本身的内容当作理据来要求敝人接受吗?更何况维基百科:格式手册/两岸四地用语还是不久之前由阁下所参与制造出来的页面。
  2. {{CHN}}使用量过大,一个很大的原因难道不是维基百科:格式手册/两岸四地用语本身的问题内容所引起的?现在有人一直大量将"中华人民共和国"改成"中国",一周内就改大约3000个条目[4],请问阁下要阻止否?还是阁下乐观其成?
  3. 此讨论话题就是维基百科:格式手册/两岸四地用语国籍章节内容问题,阁下怎么会称无关话题??实在很讶异。阁下若不希望浪费时间,则请由别人来处理,因为维基百科不强迫任何人参与,请让其他更懂的人来。--Barter84留言) 2021年5月9日 (日) 12:45 (UTC)
@Barter84:(1、3)你提出的问题并不是是次修订的重心(是次修订的重心是前国籍与多重国籍的标示),你不应要求在是次修订中处理。我建议你另开一个新讨论串(虽然上方拟议修改已进行了一些调适,但仍不是是次修订的重心)。(2)GnolizX这方面的事情我不清楚,我建议你先和他进行讨论(不过我觉得这事情确实有不妥,烦请到时在讨论的位置ping我)。SANMOSA Σουέζ 2021年5月9日 (日) 12:58 (UTC)
Barter84的质疑可以理解,但中华人民共和国公民的国籍能标示为中国,是在“中国相关条目”格式手册里实施已久的规定,后来才一并整合进来两岸四地用语。实施已久的规定也不是不能质疑和改变共识,建议另开主题讨论此点。--223.138.89.36留言) 2021年5月9日 (日) 14:58 (UTC)
回应User:223.138.89.36,阁下称“是在“中国相关条目”格式手册里实施已久的规定”,请阁下提供创建该问题规定的"用户名",以及"页面前后的差异链接"以供检视,看看这到底是何方人物的杰作,谢谢。--Barter84留言) 2021年5月9日 (日) 15:58 (UTC)
仔细一看,实施已久用词不精确,应说已实施两年。该存档已移动整并至两岸四地用语讨论页,可前往阅读完整记录。讨论标题是:“统一中国大陆人物信息框国籍栏的格式”,该案于2019年2月21日通过公示。通过后页面条文为:1949年以后出生的中华人民共和国公民,其国籍应当表述为中国。--111.82.160.105留言) 2021年5月9日 (日) 16:54 (UTC)
回应User:223.138.89.36,请阁下务必提供"该案于2019年2月21日通过公示"的网址链接,以供检视其过程内容,看看到底是何方人物在主导?--Barter84留言) 2021年5月10日 (一) 09:25 (UTC)
OK. 晚点手边工作告一段落定会处理,或者其他人有空直接帮忙贴上存档链接。十分感谢。--111.82.160.105留言) 2021年5月10日 (一) 10:07 (UTC)
统一中国大陆人物信息框国籍栏的格式”,已将存档链接置于引号内。十分感谢采纳拆分话题的意见,祝福讨论过程平和顺利。--111.82.160.105留言) 2021年5月10日 (一) 11:58 (UTC)
感谢User:223.138.89.36提供的链接:“统一中国大陆人物信息框国籍栏的格式”,会造成现今这种问题的原因已经很清楚了,就是该链接文章显示之前有一个J字开头的用户在带头操作,该J用户竟然宣称:“WP:PB的规定只应当适用于同一个条目中不能并列出现“中国”与“中华民国”,上述该用户的这种个人说法直接窄化了WP:PB方针的约束范围,以规避WP:PB方针的普遍原则:“纵然联合国及世界上大部分独立国家都已经承认,中华人民共和国政府为代表中国的唯一合法政府,但维基百科应该反映中立的现实,从而应认为“中国”一词不应该与任何单一独立政治实体或政府相同。尤其“中国”一词不应被用作与现时属中华人民共和国管治下的地区”[5],该用户以其个人说法(粗体字部分)来规避此项WP:PB方针的普遍原则,就是为了实现其将"PRC国籍"直接改为"中国国籍"的个人目的,就是因为这样才制造出了这种貌似遵守方针,实则违背方针的格式手册"问题规则",事出必有因,证据会说话。--Barter84留言) 2021年5月10日 (一) 16:24 (UTC)
(+)支持修改国籍标示规范,此明显与方针本身自相抵触和矛盾。难道中华民国国民的国籍标示用“ 台湾”或也写“台湾地区 中国”?这不合理吧。“中国”与“中华民国”不应对应,而当中华民国国民的国籍标示需要标为“ 中华民国”时,以“ 中国”标示中华人民共和国国籍明显不合理,也明显为地域中心。--LuciferianThomas留言 2021年5月11日 (二) 05:16 (UTC)
@LuciferianThomas:现行条文已有规定在需要与中华民国国籍对比时不得使用{{CHN}}而只可使用{{PRC}}。SANMOSA Σουέζ 2021年5月12日 (三) 06:55 (UTC)
此修订是要求在没有对比下也需使用{{PRC}}作国籍模板以示公允,否则对同样声明为唯一中国的中华民国有不公平待遇。--LuciferianThomas留言 2021年5月12日 (三) 08:59 (UTC)
@LuciferianThomas:中华民国现在并不声明自身为唯一的“中国”(现在不是两蒋时代),而且中华民国国籍的国际表达式现在是“中华民国”。另根据Wikipedia:格式手册/两岸四地用语#使用“中国”一词,在1949年之后的相关条目中,“若单一条目内的‘中国’一词指涉对象相同,可使用置顶模板宣告条目内的‘中国’指涉政权为何”,因此在不需要与中华民国(国籍)对比时,用{{CHN}}的同时加挂一个{{China means|PRC}}在条目顶部不会有任何问题。同样道理,如果是1971年前死亡的中华民国国民,只要不需要与中华人民共和国国籍对比,用{{ROC|name=中国}}的同时加挂一个{{China means|ROC}}在条目顶部也不会有任何问题。SANMOSA Σουέζ 2021年5月12日 (三) 09:15 (UTC)
根据台当局立法机构公布的《两岸地区人民关系条例》现行条文第二条第三、第四项,台湾当局承认两岸之间不存在国籍之别,只存在设有户籍之别。说句在一些台湾用户眼里政治不正确的:现今两岸人民是同属一个国籍的。另,大陆当局公布的《国籍法》,其自第二条起便将“中华人民共和国国籍”简称为“中国国籍”,我不知道相关用户将国籍一栏“中华人民共和国”改成“中国”是不是有这个考虑。——悔晚齋臆語) 2021年5月11日 (二) 10:33 (UTC)
回应User:悔晚斋,维基百科并不断言两岸究竟是不是同一国,而且“维基百科:避免地域中心方针”已经有明确规定,用语方面,应优先采用"事实"论述,而非"法理"论述。--Barter84留言) 2021年5月11日 (二) 11:47 (UTC)
正因采用"事实"论述,我才会查证两种国籍是否是同一个,事实证明如此。--悔晚齋臆語) 2021年5月12日 (三) 13:21 (UTC)
回应User:悔晚斋,阁下认为"中华人民共和国"和"中华民国"是同一国,那是阁下的观点,除非阁下能确定台湾海峡两岸的人民全部都接受这种观点,否则维基百科根本不会做这种断言来挑起争议而违反“维基百科:中立的观点”方针。--Barter84留言) 2021年5月12日 (三) 15:32 (UTC)
您哪只眼睛看到我在论证“两岸同属一个中国”?我在论证两岸同属一个国籍,至于是不是一个国家,不是我论证的范畴,也不关维基百科的事情,毕竟我说出的是台湾的两国论者都必须承认的事情。--悔晚齋臆語) 2021年5月13日 (四) 02:46 (UTC)
回应User:悔晚斋,阁下想要论证某一种观点,是阁下的自由,但是要说台湾海峡两岸的人民全部都必须承认阁下的这种说法:“两岸同属一个国籍”,这似乎已经过头了,所称“两岸同属一个国籍”的说法,并没有得到两岸学界的一致认可,而且就两岸统派各自的论述主张彼此也是天差地远,更不用说其他派别了。WP:NOT方针说明:“条目当然可以客观地描述某人或事物,但必须符合中立观点。如有观点或意见希望得到其他人支持,请......。”这是维基百科方针说的,不是敝人说的,请阁下能善加了解维基百科本身的属性。--Barter84留言) 2021年5月13日 (四) 10:48 (UTC)
如确需修订,现有的样式4、6、8(上方拟议修改的样式6、8、10)与{{CHN-HKG}}、{{CHN-MAC}}需要联动修改(就香港和澳门的部分而言,不会有很大的操作成本就是了,就是重定向一下而已)。如果这里是有共识修改PRC国籍的表达式的话,我会看着WP:7DAYS来办。SANMOSA Σουέζ 2021年5月12日 (三) 06:55 (UTC)
这种标示方法并无不妥,中华人民共和国护照上的国籍是“中国”,所以在条目的国籍栏应用{{CHN}}而非{{PRC}}。见CHN-all的解释--Br2 2021年5月12日 (三) 10:01 (UTC)
回应User:Brror(Br2),“维基百科:格式手册/两岸四地用语”的制定奠基于《避免地域中心方针》,而《避免地域中心方针》的精神在于确保“维基百科:中立的观点”方针的实现。所以“维基百科:格式手册/两岸四地用语”就是为了实现“维基百科:中立的观点”方针而来制定出来的页面。如果不遵从“中立的观点”,而只顾及与认同某一方自己所制定的格式,秉持某一方自己的本位中心立场,那么其最高法律效力的中华人民共和国宪法明文规定:“台湾是中华人民共和国的神圣领土的一部分”,这个规定为什么不能在维基百科发挥?可见其中的问题并不是哪一方说了就算,而是在维基百科编辑就要遵守“维基百科:中立的观点”核心内容方针。--Barter84留言) 2021年5月12日 (三) 10:51 (UTC)
所有{{XXX-all}}模板是可以修改的。SANMOSA Σουέζ 2021年5月13日 (四) 00:39 (UTC)
(!)意见-建议遵循维基百科对两岸政治不持立场的态度,建议以“中华民国”“中华民国(台湾)”“台湾”对比“中华人民共和国”。依照维基上原则,PRC国籍,是否不当然一贯完全等同中国国籍?至于是写 中国籍、或PRC国籍,过去看到一些例子的印象,似乎是看编辑者的写法,有些状况可能编辑者会考虑 条目主人翁的自我认同感。Wetrace欢迎参与人权专题 2021年5月13日 (四) 07:37 (UTC)
Barter84请你不要FORUMSHOP,你在此页的留言基本上都落入此讨论串的范围下,把同一概念重复张贴到其他讨论串没有意思。SANMOSA Σουέζ 2021年5月13日 (四) 23:57 (UTC)
请问Sanmosa阁下做底下这种争议性的修改提议,有去跟其他维基人讨论吗?为什么还要节外生枝?为什么要强化1949年以后将"中华民国"简称"中国"的提议?阁下有去问过大家吗?
在不需与中华人民共和国国籍(指定样式7至指定样式12)并列的情况下,1949年至1971年的中华民国国民,其为中华民国国民期间的国籍应表述为指定样式5或指定样式6。
中國({{ROC|name=中国}},僅適用於1971年前),[[中華民國|中国]](僅適用於1971年前)[6][7]--Barter84留言) 2021年5月14日 (五) 09:57 (UTC)
@Barter84:我在这里回应(因为这里比较适合回应这问题)。上面有用户要求我对“同样声明为唯一中国”(现在我不清楚还是不是)的中华民国公允处理,因此我打算以这新条款作为(临时性质的)祖父条款,平衡一下现在国籍字段中“中国”在1949年后只代表“中华人民共和国”的情况,而在使用置顶模板宣告条目内的“中国”指涉政权为何的前提下,这是符合Wikipedia:格式手册/两岸四地用语#使用“中国”一词中的要求的(因为新条文的范围是1971年前)。你所主张的国籍字段中完全不使用“中国”代表“中华人民共和国”或“中华民国”可能没那么快凝聚得到共识(你自己也能看到,不是所有人也认同你的见解;虽然我个人认同,但我希望循序渐进地来),所以当初我希望你另开讨论串讨论。在到了你的这个主张能凝聚得到共识的时候,上方拟议条文中的第14条与指定样式5、指定样式7、指定样式9、指定样式11会联动废除。SANMOSA Σουέζ 2021年5月14日 (五) 10:10 (UTC)
Sanmosa阁下于昨日早晨所径行修改的提议内容[8][9],自认为对中华民国公允处理、平衡"中国"字段,而另外设置1971年以前的中华民国等同于中国的叙述规定,这种效果,实际上却是同时在维基百科加强合理化全时段的"中华人民共和国"等同于"中国"的叙述规定。Sanmosa阁下难道不知道华人世界对于所认知的中国,到底是中华人民共和国、还是中华民国,各自有所不同?到底中华民国称为中国是到1949年为止、或1971年为止、或是直到现在都还认为中华民国就是中国,每个人的认知都不尽相同,为何阁下要在维基百科径自替别人做规定?请阁下退回昨日早晨所径行修改的提议内容[10][11],不要在此讨论议题再节外生枝增添争议。--Barter84留言) 2021年5月14日 (五) 11:12 (UTC)
就联合国而言,1971年前的中华民国确然是“中国”,这是历史事实而非个人主张,无可不满之处。难道说我们可以改写历史?SANMOSA Σουέζ 2021年5月14日 (五) 23:58 (UTC)
既然1971年前的中华民国确然是中国,为何阁下不将1971年前被排除在联合国外面“不代表中国”的中华人民共和国红色政权“与中国断除链接”?阁下这种说法难道不是采取双重标准吗?退一万步说,除了联合国,1949年后的中华人民共和国和中华民国,双方各自都有一群承认其自身为中国的邦交国,这岂是维基人所能视而不见当作没有这么一回事的?如果阁下就是要以联合国的认定为事实依归,那么联合国不承认现今在台湾的中华民国,为何阁下不在方针里面制定规则不得承认中华民国的存在?这又难道不是不同的标准吗?全部以上所述还只是现今华人世界当中一部分的观点而已,还存在有很多不同的意见。要知道,维基百科并不断言两岸彼此间的政治关系,维基人不应超出自己的身份范围,去制定一个没有得到学界所共同认定的规则去约束大家来共同遵守,更何况“格式手册/两岸四地用语”的制定目的是来消除争议,而不是秉持某方面的说法为准则来引发争议的。--Barter84留言) 2021年5月15日 (六) 01:44 (UTC)

(-)反对第5点提议的内容:5.在不需与中华人民共和国国籍(指定样式7至指定样式12)并列的情况下,1949年至1971年的中华民国国民,其为中华民国国民期间的国籍应表述为指定样式5或指定样式6。 1949年海峡两岸分立以后,并不是每个人都认同将1971年前的"中华民国"表述为"中国"(指定样式5),开这种方便大门会更加引发争议。--Barter84留言) 2021年5月14日 (五) 10:17 (UTC)

同样道理,也不是每个人都认同将1949年后的“中华人民共和国”表述为“中国”,但这条文至今仍然存在,因此“不是每个人都认同某种观点”并不能构成对该条的反对理由。我仍然希望你的主张在下方的讨论串取得共识后才来提议废除拟议条文中的第14条与指定样式5、指定样式7、指定样式9、指定样式11,这样对于循序渐进完善Wikipedia:格式手册/两岸四地用语的进程较好。我的思路、方向和大原则是循序渐进完善、不操之过急。SANMOSA Σουέζ 2021年5月14日 (五) 10:44 (UTC)
不然我问一下其他人的意见好了,真的不妥的话我改回来。@Ericliu1912(请参考我在#“格式手册/两岸四地用语”之国籍章节规定"PRC国籍"应该直接写为"中国国籍"的中立性问题对Barter84的回应,视为补充说明)。SANMOSA Σουέζ 2021年5月14日 (五) 10:51 (UTC)
如果用户Sanmosa真正了解到华人世界,尤其是台湾,对于中国属谁的认知复杂性(大部分海外的中华民国派、大陆与香港国粉、台湾的传统蓝营:现在的中华民国才是真正的中国。中间型统派:中华民国和中华人民共和国现在都是中国。绿营:中华民国在1949年以后就不再是中国......),就不会做出这种提议了。这个议题不是维基百科可以断言的,更别说设立规定来指定编辑,这种制式化提议已经背离中立的观点,并且会引发不同意见者的不满。--Barter84留言) 2021年5月14日 (五) 11:48 (UTC)
就联合国而言,1971年前的中华民国确然是“中国”,这是历史事实而非个人主张,无可不满之处。SANMOSA Σουέζ 2021年5月14日 (五) 23:56 (UTC)
既然1971年前的中华民国确然是中国,为何阁下不将1971年前被排除在联合国外面“不代表中国”的中华人民共和国红色政权“与中国断除链接”?阁下这种说法难道不是采取双重标准吗?退一万步说,除了联合国,1949年后的中华人民共和国和中华民国,双方各自都有一群承认其自身为中国的邦交国,这岂是维基人所能视而不见当作没有这么一回事的?如果阁下就是要以联合国的认定为事实依归,那么联合国不承认现今在台湾的中华民国,为何阁下不在方针里面制定规则不得承认中华民国的存在?这又难道不是不同的标准吗?全部以上所述还只是现今华人世界当中一部分的观点而已,还存在有很多不同的意见。要知道,维基百科并不断言两岸彼此间的政治关系,维基人不应超出自己的身份范围,去制定一个没有得到学界所共同认定的规则去约束大家来共同遵守,更何况“格式手册/两岸四地用语”的制定目的是来消除争议,而不是秉持某方面的说法为准则来引发争议的。--Barter84留言) 2021年5月15日 (六) 01:42 (UTC)
  • 回应User:BlackShadowG,不赞成将"PRC国籍"直接写为"中国","中国国籍"在维基百科并非PRC所独占。请阁下了解“维基百科:格式手册/两岸四地用语”的制定是奠基于《避免地域中心方针》,而《避免地域中心方针》的精神在于确保“维基百科:中立的观点”方针的实现。所以“维基百科:格式手册/两岸四地用语”就是为了实现“维基百科:中立的观点”方针而来制定出来的页面。如果不遵从“中立的观点”,而只顾及与认同某一方自己所制定的格式,秉持某一方自己的本位中心立场,那么其最高法律效力的中华人民共和国宪法明文规定:“台湾是中华人民共和国的神圣领土的一部分”,这个规定为什么不能在维基百科发挥?可见其中的问题并不是哪一方说了就算,而是在维基百科编辑就要遵守“维基百科:中立的观点”核心内容方针。--Barter84留言) 2021年5月16日 (日) 16:32 (UTC)
    前面几位编者提出护照上的国籍是因为国籍是国家的规定[1]。PRC不控制台湾,但台湾是中华人民共和国法定领土的一部分是事实;PRC护照上将国籍写成中国也是事实。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月17日 (一) 16:01 (UTC)
  • 我建议,虽然PRC和ROC都将国籍写作“中国”,但维基百科不可能二者都写作中国。既然PRC和ROC对应时,都分别要写各自国名全称,何不如无论如何都写成全称?至于已经用{{China means}}的条目,再作讨论。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月17日 (一) 16:06 (UTC)
我先假设如果我上面的提案通过的话,要再修改可以怎么改:
现行条文

国籍

在人物信息框中表述两岸四地近现代人物国籍时,应当遵循下列原则。对于具体条目而言,条目编者可以通过共识决定该条目人物信息框中是否使用旗帜模板。以下各条所指的“指定样式”为下列指定样式表中的指定样式。

  1. 1912年(不含)前(未内渡的台湾(含澎湖)人则为住民去就决定日前)的大清臣民,其为大清臣民期间的国籍应表述为指定样式1[注 1]
  2. 1912年至1928年的中华民国国民,其为中华民国国民期间的国籍应表述为指定样式2[注 2]
  3. 1928年至1949年的中华民国国民,且此后未赴台湾者,其为中华民国国民期间的国籍应表述为指定样式3[注 2]
  4. 住民去就决定日后、中华民国接管台湾(含澎湖)前未内渡或出生的台湾(含澎湖)人,其为(未内渡)台湾(含澎湖)人期间的国籍应表述为指定样式4[注 3]1949年以后的中华民国国民,其为中华民国国民期间的国籍应表述为指定样式6。若其在1928年至1949年间亦为中华民国国民,其在1928年至1949年间为中华民国国民期间的国籍同样以指定样式6表述,而无须另外以指定样式3表述。
  5. 在不需与中华民国国籍(指定样式3指定样式5指定样式6)并列的情况下,1949年以后的中华人民共和国公民,如其在中国大陆设有户籍,其为中华人民共和国公民期间的国籍应表述为指定样式7指定样式8。如出现需与中华民国国籍(指定样式3指定样式5指定样式6)并列的情况,则其为中华人民共和国公民期间的中华人民共和国国籍应表述为指定样式8
  6. 在不需与中华民国国籍(指定样式3指定样式5指定样式6)并列的情况下,1997年以后具中华人民共和国国籍香港永久性居民(无论是在何时获得香港永久性居民身份),其在1997年后为香港永久性居民期间的国籍应表述为指定样式9指定样式10。如出现需与中华民国国籍(指定样式3指定样式5指定样式6)并列的情况,则其在1997年后为香港永久性居民期间的国籍应表述为指定样式10
  7. 在不需与中华民国国籍(指定样式3指定样式5指定样式6)并列的情况下,1999年以后具中华人民共和国国籍澳门永久性居民(无论是在何时获得澳门永久性居民身份),其在1999年后为澳门永久性居民期间的国籍应表述为指定样式11指定样式12。如出现需与中华民国国籍(指定样式3指定样式5指定样式6)并列的情况,则其在1999年后为澳门永久性居民期间的国籍应表述为指定样式12
  8. 1997年以前获得香港永久性居民身份,并于1983年至1997年间具英国属土公民国籍者,其具英国属土公民国籍期间的国籍表述应为指定样式13
  9. 1997年以前获得香港永久性居民身份,并于1987年起具英国国民(海外)国籍者,其具英国国民(海外)国籍期间的国籍表述应为指定样式14
  10. 以下人物的国籍应表述为指定样式15[注 4]
    1. 1983年以前获得香港永久性居民身份,并具英国国籍者;或
    2. 1997年以前获得香港永久性居民身份,并于1983年至1997年间只具英国属土公民国籍,及于1997年以后不具中华人民共和国国籍者。
  11. 1999年以前获得澳门永久性居民身份,并于1999年以前具葡萄牙国籍,又未于1999年以后具中华人民共和国国籍者,其为葡萄牙国民期间的国籍应表述为指定样式16
  12. 如使用指定样式7指定样式9指定样式11三者中的一个或多个,条目顶部应依使用“中国”一词的规定,使用{{China means|PRC}}进行置顶模板宣告。
  13. 以上各条不限制前国籍与多重国籍的标示,除非前国籍与多重国籍本身同样符合以上各条的情形。就以上各条的情形,如相关人物在任何同一时间点实际上具多于一个国籍,无论是否上方提及的任何国籍,在有来源支持相关声称的情况下,应同时标记相关国籍。如有需要,可以括注或注释形式说明其国籍变更情况,以配合相关国籍模板或链接的使用。

指定样式表

编号 指定样式
1
  1.  中国({{CHN-1862}},仅适用于1889年前)
  2.  大清({{QING-1862}},仅适用于1889年前)
  3.  中国({{CHN-1889}})
  4.  大清({{QING-1889}})
  5. [[清朝|中国]]
  6. [[清朝|大清]]
2
  1.  中国({{CHN-1912}})
  2.  中华民国({{ROC-1912}})
  3. [[北洋政府|中国]]
  4. [[北洋政府|中华民国]]
3
  1.  中国({{CHN-1928}})
  2.  中华民国({{ROC-1928}})
  3. [[中華民國大陸時期|中国]]
  4. [[中華民國大陸時期|中华民国]]
4
  1.  日本({{JPN-1868}})
  2. [[大日本帝国|日本]]
5
  1.  中华民国({{ROC}})
  2. [[中華民國]]
6
  1.  中华人民共和国({{PRC}})
  2. [[中华人民共和国]]
7
  1. 中华人民共和国香港)({{PRC-HKG}})
  2. [[中华人民共和国]]([[香港居民#永久性居民|香港]])
8
  1. 中华人民共和国澳门)({{PRC-MAC}})
  2. [[中华人民共和国]]([[澳門居民#永久性居民|澳门]])
9
  1. 英国 英国属土({{BDTC}})
  2. [[英國海外領土公民#香港英國屬土公民(BDTC)|英国属土]]
10
  1. 英国国民(海外)({{GBN}})
  2. [[英國國民(海外)]]
11
  1.  英国({{GBR-1801}},仅适用于1922年/1927年前)
  2.  英国({{GBR}})
  3. [[大不列颠及爱尔兰联合王国|英国]](仅适用于1922年/1927年前)
  4. [[英国]]
12
  1.  葡萄牙({{POR-1578}},仅适用于1615年前)
  2. 葡萄牙王国 葡萄牙({{POR-1616}},仅适用于1639年前)
  3.  葡萄牙({{POR-1640}},仅适用于1666年前)
  4.  葡萄牙({{POR-1667}},仅适用于1706年前)
  5.  葡萄牙({{POR-1707}},仅适用于1815年前)
  6. 葡萄牙({{POR-1816}},仅适用于1829年前)
  7.  葡萄牙({{POR-1830}},仅适用于1910年前)
  8.  葡萄牙({{POR-1910}},仅适用于1926年前)
  9. 葡萄牙 葡萄牙({{POR-1926}},仅适用于1933年前)
  10.  葡萄牙({{POR-1933}},仅适用于1974年前)
  11.  葡萄牙({{POR}})
  12. [[葡萄牙王國|葡萄牙]](仅适用于1910年前)
  13. [[葡萄牙]]
提议条文

国籍

在人物信息框中表述两岸四地近现代人物国籍时,应当遵循下列原则。对于具体条目而言,条目编者可以通过共识决定该条目人物信息框中是否使用旗帜模板。以下各条所指的“指定样式”为下列指定样式表中的指定样式。

  1. 1912年(不含)前(未内渡的台湾(含澎湖)人则为住民去就决定日前)的大清臣民,其为大清臣民期间的国籍应表述为指定样式1[注 1]
  2. 1912年至1928年的中华民国国民,其为中华民国国民期间的国籍应表述为指定样式2[注 2]
  3. 1928年至1949年的中华民国国民,且此后未赴台湾者,其为中华民国国民期间的国籍应表述为指定样式3[注 2]
  4. 住民去就决定日后、中华民国接管台湾(含澎湖)前未内渡或出生的台湾(含澎湖)人,其为(未内渡)台湾(含澎湖)人期间的国籍应表述为指定样式4[注 3]
  5. 1949年以后的中华民国国民,其为中华民国国民期间的国籍应表述为指定样式6。若其在1928年至1949年间亦为中华民国国民,其在1928年至1949年间为中华民国国民期间的国籍同样以指定样式6表述,而无须另外以指定样式3表述。
  6. 1949年以后的中华人民共和国公民,如其在中国大陆设有户籍,其为中华人民共和国公民期间的国籍应表述为指定样式8
  7. 1997年以后具中华人民共和国国籍香港永久性居民(无论是在何时获得香港永久性居民身份),其在1997年后为香港永久性居民期间的国籍应表述为指定样式10
  8. 1999年以后具中华人民共和国国籍澳门永久性居民(无论是在何时获得澳门永久性居民身份),其在1999年后为澳门永久性居民期间的国籍应表述为指定样式12
  9. 1997年以前获得香港永久性居民身份,并于1983年至1997年间具英国属土公民国籍者,其具英国属土公民国籍期间的国籍表述应为指定样式13
  10. 1997年以前获得香港永久性居民身份,并于1987年起具英国国民(海外)国籍者,其具英国国民(海外)国籍期间的国籍表述应为指定样式14
  11. 以下人物的国籍应表述为指定样式15[注 4]
    1. 1983年以前获得香港永久性居民身份,并具英国国籍者;或
    2. 1997年以前获得香港永久性居民身份,并于1983年至1997年间只具英国属土公民国籍,及于1997年以后不具中华人民共和国国籍者。
  12. 1999年以前获得澳门永久性居民身份,并于1999年以前具葡萄牙国籍,又未于1999年以后具中华人民共和国国籍者,其为葡萄牙国民期间的国籍应表述为指定样式16
  13. 以上各条不限制前国籍与多重国籍的标示,除非前国籍与多重国籍本身同样符合以上各条的情形。就以上各条的情形,如相关人物在任何同一时间点实际上具多于一个国籍,无论是否上方提及的任何国籍,在有来源支持相关声称的情况下,应同时标记相关国籍。如有需要,可以括注或注释形式说明其国籍变更情况,以配合相关国籍模板或链接的使用。

指定样式表

编号 指定样式
1
  1.  中国({{CHN-1862}},仅适用于1889年前)
  2.  大清({{QING-1862}},仅适用于1889年前)
  3.  中国({{CHN-1889}})
  4.  大清({{QING-1889}})
  5. [[清朝|中国]]
  6. [[清朝|大清]]
2
  1.  中国({{CHN-1912}})
  2.  中华民国({{ROC-1912}})
  3. [[北洋政府|中国]]
  4. [[北洋政府|中华民国]]
3
  1.  中国({{CHN-1928}})
  2.  中华民国({{ROC-1928}})
  3. [[中華民國大陸時期|中国]]
  4. [[中華民國大陸時期|中华民国]]
4
  1.  日本({{JPN-1868}})
  2. [[大日本帝国|日本]]
6
  1.  中华民国({{ROC}})
  2. [[中華民國]]
8
  1.  中华人民共和国({{PRC}})
  2. [[中华人民共和国]]
10
  1. 中华人民共和国香港)({{PRC-HKG}})
  2. [[中华人民共和国]]([[香港居民#永久性居民|香港]])
12
  1. 中华人民共和国澳门)({{PRC-MAC}})
  2. [[中华人民共和国]]([[澳門居民#永久性居民|澳门]])
13
  1. 英国 英国属土({{BDTC}})
  2. [[英國海外領土公民#香港英國屬土公民(BDTC)|英国属土]]
14
  1. 英国国民(海外)({{GBN}})
  2. [[英國國民(海外)]]
15
  1.  英国({{GBR-1801}},仅适用于1922年/1927年前)
  2.  英国({{GBR}})
  3. [[大不列颠及爱尔兰联合王国|英国]](仅适用于1922年/1927年前)
  4. [[英国]]
16
  1.  葡萄牙({{POR-1578}},仅适用于1615年前)
  2. 葡萄牙王国 葡萄牙({{POR-1616}},仅适用于1639年前)
  3.  葡萄牙({{POR-1640}},仅适用于1666年前)
  4.  葡萄牙({{POR-1667}},仅适用于1706年前)
  5.  葡萄牙({{POR-1707}},仅适用于1815年前)
  6. 葡萄牙({{POR-1816}},仅适用于1829年前)
  7.  葡萄牙({{POR-1830}},仅适用于1910年前)
  8.  葡萄牙({{POR-1910}},仅适用于1926年前)
  9. 葡萄牙 葡萄牙({{POR-1926}},仅适用于1933年前)
  10.  葡萄牙({{POR-1933}},仅适用于1974年前)
  11.  葡萄牙({{POR}})
  12. [[葡萄牙王國|葡萄牙]](仅适用于1910年前)
  13. [[葡萄牙]]

大家可以先看一看。以上。SANMOSA Σουέζ 2021年5月18日 (二) 00:10 (UTC)

(+)支持。--路西法人留言 2021年5月20日 (四) 06:39 (UTC)
(+)支持 这样标注国籍无歧义,且人物的不同时期国籍和同一时期的多重国籍本就应一并标示。另外{{ROC-1912}}应该链接至中华民国大陆时期,因为五色旗在1912年—1913年的中华民国临时政府(1912年1月—3月政府驻于南京,1912年3月—1913年10月政府驻于北京)以及1913年—1928年的北洋政府均作为中华民国国旗使用。--Joker Twins留言) 2021年5月22日 (六) 08:00 (UTC)
  • 本人反对在政权更迭但人没迁移的情形下同时标注不同时期国籍,其他暂无异议。--痛心疾首 2021年5月22日 (六) 14:48 (UTC)
其实就算人没有迁移还在原地,但只要经历政权更迭,就该把其所经历的政权更迭所导致的国籍变动在信息框一一列出,这才符合常理,也是Sanmosa本次提案的题中应有之意,只给出最终国籍了事,对于人物早年的国籍而言,只会给人以穿越时空的错乱感,显然很不恰当。--Joker Twins留言) 2021年5月22日 (六) 15:28 (UTC)
理解了,我现在不反对这种标注,只是觉得这么做有点繁琐罢了。--为鄂 2021年5月23日 (日) 06:35 (UTC)
  • (+)支持--Nrya留言) 2021年5月22日 (六) 17:43 (UTC)
  • (?)疑问 中华民国 中华民国的分界线为何定死在1928年?依据中华民国国旗条目,国民政府从一开始就用的青天白日旗。北伐军1927年3月攻克上海后,上海即已开始使用青天白日旗;而1927年8月在上海出生的何祚庥难道还需要使用五色旗?(目前条目中用五色旗作为出生地点)--曾晋哲反对五个一留言·Q) 2021年5月23日 (日) 18:17 (UTC)
    @Njzjz:请留意各版方针与现版本拟议修订均保留“割据政权可采用注释形式另行说明”的注释。国民政府那时候属于割据政权,其控制的领土下照用{{ROC-1928}}是没问题的。SANMOSA Σουέζ 2021年5月24日 (一) 00:41 (UTC)
差不多一个礼拜没有回应,且没有反对意见。 公示7日,2021年6月6日 (日) 14:11 (UTC) 结束。--路西法人留言 2021年5月30日 (日) 14:11 (UTC)
(+)支持,但有一个问题(不中断公示也可以,因为是后续处理问题)。提案通过后,目前使用{{CHN-HKG}}的具中华人民共和国国籍的香港永久性居民将要全数改为{{PRC-HKG}},唯涉及条目众多,人手修改恐怕不太现实,所以会不会考虑直接将{{CHN-HKG}}重定向至{{PRC-HKG}}或者直接修改为后者的样式?(这个模板应该没有在其他场合使用)不然的话使用AWB也可以,不过需要具有相关权限的用户协助。--【和平至上】💬 2021年6月1日 (二) 16:53 (UTC)
@和平至上:到时会改重定向(而且即使有在其他场合使用,这样改也不会出问题)。问题更大的反而是{{CHN}}的使用。SANMOSA Σουέζ 2021年6月2日 (三) 00:16 (UTC)

通过。--路西法人留言 2021年6月6日 (日) 23:07 (UTC)


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

参考资料

国籍栏使用模板后续处理

@和平至上Sanmosa:预留新段给你们。--路西法人留言 2021年6月6日 (日) 23:07 (UTC) 重签--路西法人留言 2021年6月6日 (日) 23:16 (UTC)

{{CHN-HKG}}与{{CHN-MAC}}两个模板已经重定向处理。{{CHN}}转{{PRC}}需要逐个人手处理。SANMOSA Σουέζ 2021年6月7日 (一) 07:53 (UTC)
{{CHN-HKG}}中的“中华人民共和国”的内链指向“人大国籍法解释”会不会比较好?Jasonloi1997留言) 2021年6月8日 (二) 09:52 (UTC)
这样可能引起混淆,不妥。—— Eric Liu 创造は生命(留言留名学生会 2021年6月10日 (四) 01:01 (UTC)
请问是哪部分的混淆呢?让其他汉语用户了解更多香港居民的“中华人民共和国国籍”的根据不是更清晰吗?Jasonloi1997留言) 2021年6月12日 (六) 13:57 (UTC)
读者点选“中华人民共和国”,期望进入的条目应当是“中华人民共和国”,而不是“人大国籍法解释”。参见格式手册对于管道链接的说明。此外,我记得以前这类型模板有些确实会链接到国籍相关条目,但后来都已统一形式不再这么做了了。—— Eric Liu 创造は生命(留言留名学生会 2021年6月13日 (日) 14:15 (UTC)
明白你的意思,不过点选“中华人民共和国”也会存在“为什么是中华人民共和国”的可能,想了解原因;现在“ 英国国民(海外)”和“英国 英国及其殖民地”还是连接国籍相关条目的Jasonloi1997留言) 2021年6月13日 (日) 15:12 (UTC)
我是觉得无所谓,但我不想贸然改链接。SANMOSA Σουέζ 2021年6月12日 (六) 14:33 (UTC)
另@SanmosaWikipedia:格式手册/两岸四地用语#使用“中国香港”及“中国澳门”两词的国籍述部分是否需要更新?Jasonloi1997留言) 2021年6月18日 (五) 18:40 (UTC)
正式来说,确实没有这样的国籍表达式,这是zhwiki原创的,理论上来说是可以调整一下。我会就此另提一案。SANMOSA Σουέζ 2021年6月19日 (六) 00:34 (UTC)

修改WP:命名常规#书名号

现拟修改WP:命名常规#书名号如下:

现行条文

书名号 书、篇、报纸、刊物、歌曲、戏曲的条目名称不带书名号。但在条目内部书名号正常使用。

提议条文

书名号 条目名称中凡出现书、篇、报纸、刊物、歌曲、戏曲等在一般中文行文中使用书名号的名词,无论是否书、篇、报纸、刊物、歌曲、戏曲等的条目本身,在条目名称中均不使用书名号。此条不影响条目正文中书名号的正常使用。就非书、篇、报纸、刊物、歌曲、戏曲等的条目本身的条目而言,此条不影响条目中显示的标题中书名号的使用。

以上。SANMOSA Σουέζ 2021年5月10日 (一) 03:48 (UTC)

反对,条目名中不用书名号没有任何道理可言,也与任何技术限制无关,“她获奖名单”听起来仿佛“谁获奖”?万一有个“惊天动地获奖名单”、“石破天惊获奖名单”就更扯,“地心引力获奖名单”不看电影的还以为给地球颁奖,一开始的命名常规就根本是想当然。--7留言) 2021年5月10日 (一) 05:39 (UTC)
(-)反对。为什么要改成不规范的形式?--2, 3, 5, 7, 11, 13, 17... 2021年5月10日 (一) 09:52 (UTC)
同上。不过,不如先说说为什么要改。--安忆Talk 2021年5月10日 (一) 10:00 (UTC)
@JarodalienSuper Wang安忆:(1)现时此类列表多无书名号,故“‘改成’不规范的形式”不成立。(2)基于现已生效的命名一致性规则,须确立同类条目统一的标题表达式。(3)原始标题若需输入书名号则不利链接。(4)条目内显示的标题可通过-{T|}-或{{noteTA}}的参数显示回书名号,依上案修改该条不会限制此举,我也不打算限制此举(老实说,通过-{T|}-或{{noteTA}}的参数只在条目内显示的标题显示回书名号才是我的完整想法)。SANMOSA Σουέζ 2021年5月10日 (一) 13:54 (UTC)
@SanmosaJarodalienSuper Wang安忆YumetoHijk910:我这边帮大家整理为什么又有这种事。
  1. jarodalien大创建了《复仇者联盟4:终局之战》获奖名单等条目,并将其提交DYK
  2. 我看到后表示“条目名称不符合Wikipedia:命名常规#书名号
  3. Yumeto大回复“Wikipedia talk:命名常规#维基百科:命名常规#书名号之商榷未有定论”
  4. 我回答“上次讨论没有结果不等于命名常规#书名号会自动失效啊”
  5. Yumeto大接着说“命名常规是“书、篇、报纸、刊物、歌曲、戏曲的条目名称不带书名号”,而无规定“书、篇、报纸、刊物、歌曲、戏曲”获奖名单的条目名称。”
  6. Sanmosa大出现并说“Wikipedia:命名常规#命名一致性
  7. Hijk910大路过。←大概是这样
其实就目前的方针,究竟这段“书、篇、报纸、刊物、歌曲、戏曲的条目名称”是涵盖了包含作品名称的条目名称,还是只针对作品本身而已。 --Loving You Is A Losing Game 2021年5月10日 (一) 13:28 (UTC)
  • 我路过,大家继续。hiJK910 I'm sorry, I couldn't hear your question, Yvonne 2021年5月10日 (一) 13:35 (UTC)
  • “此类列表多无书名号”本身即是错误格式,不是占多数的一定就是正确的,此乃闯红灯。至于命名一致,一致与否和书名号到底有什么关系?所谓一致就是标题里不能带标点符号吗?我的理解是使用“名单”还是“列表”才叫一致。有关不利于链接,我认为正确格式比利于链接更重要,不能因为一时的“方便”就视《标点符号用法》为无物。海峡对岸可以不遵守GB/T,一国两制下的香港非要不遵守我也没办法,但是简体至少要符合用法。--2, 3, 5, 7, 11, 13, 17... 2021年5月10日 (一) 23:19 (UTC)
    条目内显示的标题可通过-{T|}-或{{noteTA}}的参数显示回书名号。“原始标题若需输入书名号则不利链接”的意思是你加了书名号以后根本没有人会被连到那个条目,那条目就没人看,这不是和维基百科的宗旨背道而驰吗。SANMOSA Σουέζ 2021年5月11日 (二) 01:27 (UTC)
    中华民国《重订标点符号手册》与中华人民共和国推荐性国家标准《标点符号用法》都有书名号用法。 绀野梦人 肺炎退散 2021年5月13日 (四) 14:24 (UTC)
  • 什么一致,我准备大建特建《XXX》获奖名单,数量超过现有不就完事,不同语种的人不要管大陆汉语,语言不通。--7留言) 2021年5月11日 (二) 03:55 (UTC)
    此类标题仍有违反现行WP:命名常规#书名号的可能性,你这样是公然游戏规则,请你留意。SANMOSA Σουέζ 2021年5月11日 (二) 04:31 (UTC)
    说了语言不通,你说的规则别人理解和你不一样。--7留言) 2021年5月11日 (二) 05:43 (UTC)
    我请一个管理员过来理解一下即可,但你可能要预期如上次一般又被编辑禁制。SANMOSA Σουέζ 2021年5月11日 (二) 12:04 (UTC)
    那么上次一堆人反对获奖名单的命名也没看你打算改啊= =。还是一句话,觉得好就提,什么都不说谁会知道你想干嘛。 --Loving You Is A Losing Game 2021年5月11日 (二) 13:59 (UTC)
    @Milkypine:是了,依Wikipedia:命名常规#命名一致性,你可以重新提出那个话题了。SANMOSA Σουέζ 2021年5月11日 (二) 22:43 (UTC)

那我的想法是修改成下面这样:

现行条文

书名号 书、篇、报纸、刊物、歌曲、戏曲的条目名称不带书名号。但在条目内部书名号正常使用。

提议条文

书名号 介绍书、篇、报纸、刊物、歌曲、戏曲本身的条目名称不带书名号,但在条目内部书名号正常使用;但如果不是介绍该作品本身而是介绍与之相关事物的条目,则条目标题中仍正常使用书名号,此时可以创建不带书名号的重定向,并使用{{书名号重定向}}标记该重定向页

这样既符合书名号的使用规范,也解决了“输入书名号不便链接”的问题。至于什么“命名一致性”,原文说的是“格式”一致,没有强行规定在同类型条目里非得用什么特定用字不可。--2, 3, 5, 7, 11, 13, 17... 2021年5月11日 (二) 08:13 (UTC)

(1)命名一致性可要求用词一致(“条目(包括列表条目,下同)的命名的格式(包括但不限于用词)应与其他同类条目的命名的格式一致”)。(2)不可能强制用户必须创建重定向,因为用户创建条目时根本没时间思考这些,中文维基百科也无能力自动或人工排查所有的此类条目是否有相应的重定向,因此此提议我认为现实上不可能实行。SANMOSA Σουέζ 2021年5月11日 (二) 12:04 (UTC)
难道不应该是反过来吗?或至少不强制编者选择哪一种格式。默认反直觉不太好吧。—— Eric Liu 创造は生命(留言留名学生会 2021年5月11日 (二) 14:00 (UTC)
(1)“难道不应该是反过来吗?”原始标题若需输入书名号不利链接。你加了书名号以后,根本没有人会被连到那个条目,也没人有时间在创建条目时思考链入问题,结果也没有人建重定向,后者在现实上又不可能强制,那条目就没人看。(2)“或至少不强制编者选择哪一种格式。”Wikipedia:命名常规#命名一致性,不能不统一格式。SANMOSA Σουέζ 2021年5月11日 (二) 22:43 (UTC)
Sanmosa我就是这个意思,请看好缩排,我不是在回复您⋯⋯ —— Eric Liu 创造は生命(留言留名学生会 2021年5月12日 (三) 06:55 (UTC)
@Ericliu1912:2来说的话,我自己是确实打算回复你,因为我原本的提案就会强制编者使用特定格式命名条目。1的话你当成我重复一次补充说明好了。SANMOSA Σουέζ 2021年5月12日 (三) 07:00 (UTC)
  • 支持删除书名号章节,也支持后一种分开处理,谴责这种根本没有任何道理的命名规则。命名常规说“使用地区词处理至一致也算作一致”,几地本来就是用不同的语言,同一条目在大陆人看是人物传记,台湾人看是电影,香港人看是化学非常正常。既然香港台湾已经不用书名号,那我双手双脚赞成两地版本不用。要统一那全世界核平最方便统一。--7留言) 2021年5月12日 (三) 12:31 (UTC)
既然香港台湾已经不用书名号[来源请求]。Super Wang的方案我给予支持,不过实际还是等更多人参与讨在下结论。 --Loving You Is A Losing Game 2021年5月12日 (三) 13:00 (UTC)
不能删除书名号章节,否则会出现圣经需要被命名为《圣经》的诡异情形。SANMOSA Σουέζ 2021年5月12日 (三) 23:37 (UTC)
@Super Wang:我想问一下,超犀利趴三《团团团团团》演唱会 LIVE这个条目根据Super Wang的方案该怎么写? --Loving You Is A Losing Game 2021年5月12日 (三) 17:04 (UTC)
@Milkypine:如果不追究演唱会的名称为什么用书名号表示的话,我的想法是条目标题保持现有的“超犀利趴三《团团团团团》演唱会 LIVE”,因为该条目介绍该专辑本身;而正文中,专辑的名字要打书名号,首句为“《超犀利趴三〈团团团团团〉演唱会 LIVE》(英语:Super Slipper LIVE Part 3)是收录2012年的超犀利趴3《团团团团团》演唱会精华片段的现场专辑”。当然我这是大陆的用法,台湾可以单用〈这种书名号〉,这方面我不是很了解,但在用不用书名号的问题上我的答案是肯定的。--2, 3, 5, 7, 11, 13, 17... 2021年5月13日 (四) 01:11 (UTC)
Super Wang的方案有违反命名一致性规定的疑虑。SANMOSA Σουέζ 2021年5月12日 (三) 23:39 (UTC)
我没有强制用户创建重定向的意思,我说的是“此时可创建不带书名号的重定向”。请注意我用的是哪个情态动词。--2, 3, 5, 7, 11, 13, 17... 2021年5月13日 (四) 01:11 (UTC)
我说的是条目标题,不是重定向标题。另如不强制用户创建重定向,提案还是回到了链入问题。另参下方AT的留言,不同地方使用书名号的习惯均不同。SANMOSA Σουέζ 2021年5月13日 (四) 23:18 (UTC)
支持Jarodalien和Super Wang对相关事实的看法(不包含其中的情绪化表达),Super Wang的方案我给予支持。--悔晚齋臆語) 2021年5月13日 (四) 02:49 (UTC)
根据新提案,哈利·波特的创作灵感来源及相似作品的条目名称是不是要改成“《哈利·波特》的创作灵感来源及相似作品”?--Mewaqua留言) 2021年5月13日 (四) 11:11 (UTC)
韩诗外传》,《〈韩诗〉外传》还是《〈韩《诗》〉外传》? 绀野梦人 肺炎退散 2021年5月13日 (四) 14:24 (UTC)
单纯的疑问,不加书名号有碍理解的话,为什么就不能通过转换之类来更改条目标题?以带书名号名作为条目标题,之后又要创建重定向,而且可能还有单双书名号的问题(像香港单书名号就非常罕见,结果可能又需要转换)。因此,我认为有需要的话允许转换标题就够了,没看到必须添加书名号至条目标题的充分理据。--AT 2021年5月13日 (四) 15:58 (UTC)
同上,请@JarodalienSuper Wang留意并回应,否则我考虑不视你们两个对原提案的意见为合理反对意见。SANMOSA Σουέζ 2021年5月13日 (四) 23:18 (UTC)
极其反感这种“我考虑不视你们两个对原提案的意见为合理反对意见”的论调,好像有谁会在乎一样。回AT,我更加看不出有任何理由要禁止书名号,你们香港人不用书名号我管不着,反过来别的地方学校教语文说应该要有书名号,也请不同地方的人管好自己的事。--7留言) 2021年5月14日 (五) 11:40 (UTC)
我没有禁止书名号的意思,而是想说明为什么不能通过转换来将书名号反映至条目标题?将书名号加进条目的原始标题中所带来的技术问题与添加转换相比,后者显然简单得多,反之添加书名号至条目标题仍然可能需要加入转换,还有内部链接的问题引致需要另建重定向,加上各地对于书名号理解的不一致也可能引发移动战,也就是说如果容许书名号加进条目标题的话,那显然之后的跟进工作要做得更多,而且重复。再者,中文维基是各地区共同参与的协作项目,不可能说只理自己所处的地区,而不顾及其他地区,管好自己不等同于就要不理别人,读者本身也就来自五湖四海海,因此各人自扫门前雪的做法绝不可行。最后,关于添加书名号至条目标题的问题我已经说明清楚,如果刘兄有比添加转换更佳的解决方法,欢迎提出,或是认为转换有实际上的问题的话也欢迎指正。谢谢。--AT 2021年5月14日 (五) 12:07 (UTC)
没有禁止那就行了,我看不出用书名号有任何“技术问题”,有问题的是人,是长期形成而且谁也不知道最开始到底有没有理由的习惯。还是那个老例子,谁偏要用eyeglasses代指眼镜,创建标题也用这个词,别人管不着,但要是这人居然要说别人用glasses不对,标题就要用eyeglasses,还要立方针说不管哪个国家的条目标题都要统一用eyeglasses,我想对付的也就是这种人而已,会不会有人因eyeglasses和glasses不统一要移动我不在乎,谁移动对付谁不就完事了。你说的后面这一堆所谓加书名号会有的问题,在我看来没有任何一个是问题,更不要说没有任何一个就可以用来证明汉语应该放弃本身逻辑,放弃使用书名号——很遗憾,标题不(准)用也是一样。这和简繁转换一样,谁不知道统一方便?那要怎么办?干嘛要搞转换系统,把用不同语种的人种全部肉体消灭不是更彻底吗?你说的所有问题放在简繁地区词差异上也是一样,现在主张用书名号的是我们大陆人,“加入转换,另建重定向,加上各地对汉语号理解的不一致也可能引发移动战”,“也就是说如果容许”简繁转换系统,“那显然之后的跟进工作要做得更多,而且重复”。--7留言) 2021年5月14日 (五) 12:58 (UTC)
既然您认为我提到的问题不成问题,那请问您是否愿意去承担这些跟进工作?--AT 2021年5月14日 (五) 13:17 (UTC)
@Jarodalien:你不会做的事情当然不是问题啊。移动对付谁不就完事了,那这次通过之后你是否该自行处理这些有书名号需求的条目?问题一开始就不在转换身上,而是该方针到底有没有允许让大家可以这命名,而且就算转换了,不符方针依旧要被删除。统一当然方便,但这不就是阁下当初说的没事找事做?你要知道你现在做的可不只是允许大陆人添加书名号,是自此之后维基百科创立的条目一旦有作品出现都要有书名号,反应在分类上就更多了。如果阁下有处理的决心,我绝对支持你。 --Loving You Is A Losing Game 2021年5月14日 (五) 15:34 (UTC)
“考虑不视……为合理反对意见”是因为Wikipedia:共识#什么是共识有“共识应当考虑到所有正当合理的意见”的条文,我依规为保险计应行如此宣告。SANMOSA Σουέζ 2021年5月14日 (五) 12:42 (UTC)
@悔晚斋SANMOSA Σουέζ 2021年5月14日 (五) 00:06 (UTC)
“《哈利·波特》的创作灵感来源及相似作品”这个标题我认为没有问题,不加书名号不会让人理解成哈利·波特创作了作品吗?另外回Sanmosa,如果所有问题,包括covid-19和书名号都让你算作地区词问题,那我可能还真没什么好说的。你愿意咋理解就咋理解吧。但是我要说一点,就是我如果有天写了标题里带有书名号的条目,我也会创建重定向。这叫包容。--2, 3, 5, 7, 11, 13, 17... 2021年5月14日 (五) 00:58 (UTC)
这时我就要引用Jarodalien大的留言了,“只要没有错字,头脑正常的人不会理解错误就行了”,因此我还是认为没有必要加上书名号。 --Loving You Is A Losing Game 2021年5月14日 (五) 02:40 (UTC)
你要这么理解我OK啊,但现在的情况是有人想要禁止,“统一”,你觉得“没有必要加”,是否等同于你觉得“有必要禁止加”呢?所以我和有些人的区别是:我有自知之明,只会agree to disagree,你们香港台湾人不用书名号写一百万个条目我也是不会理睬的,反过来我们大陆人用书名号写条目也请你们保持距离。--7留言) 2021年5月14日 (五) 11:47 (UTC)
同上AT所言,“各人自扫门前雪”不可行。我和AT不同,我先小人后君子,你这样我可以把你当成符合NOTHERE的情形。SANMOSA Σουέζ 2021年5月14日 (五) 12:46 (UTC)
然而不同地方在书名号上的使用均有不同,Wikipedia:格式手册/标点符号#书名号已经指明了中国大陆和台湾在书名号的使用标准上已经有差别,至于香港、澳门、马来西亚、新加坡就根本不存在书名号的使用标准,难道不能算是地区词问题?这是很现实的事情。SANMOSA Σουέζ 2021年5月14日 (五) 02:49 (UTC)
“‘《哈利·波特》的创作灵感来源及相似作品’……不加书名号不会让人理解成哈利·波特创作了作品吗”无论是理论上抑或实务上均不可能。(理论上)“哈利·波特”是“创作灵感来源及相似作品”的修饰语(即“创作灵感来源”和“相似作品”两者的共同修饰语)。如果你将“哈利·波特”理解为人或角色,那你可以思考的一点是人或角色本身会否被视为“作品”。这答案无疑是否定的,故在将“哈利·波特”理解为人或角色的情况下,“哈利·波特”不存“(相似)作品”,而这只有两种可能性:(1)标题中的“相似作品”是赘语;或(2)将标题中的“哈利·波特”理解为人或角色是错的。(实务上)如果并非该条目本身,管道链接处理即可,无须直接动页面标题。如果是该条目本身,读者点入条目时不会只看条目(原)标题,而会看条目的内容,此时读者已能确定“哈利·波特”是书,而非人或角色。再退一步来说,条目内显示的标题可通过-{T|}-或{{noteTA}}的参数显示回书名号,因此即使条目原标题没书名号,只要条目的源代码有妥善处理,显示出来的效果仍然会有书名号,因此不可能产生因不加书名号而使人误解的情形。SANMOSA Σουέζ 2021年5月14日 (五) 03:08 (UTC)
  • (-)反对,本提案简直滑天下之大稽。就“《哈利·波特》的创作灵感来源及相似作品”的例子就足以说明问题,去除书名号后,谁知道你说的是小说系列还是虚构人物创作呢?英文和中文并不一样,中文里表示书名必然会用到引号、书名号、专名号,英文里只需要一个斜体。你完全可以从编辑者的角度考虑,做链接的时候输入书名号、引号还要切换输入法;从读者的角度考虑,Super Wang的提案才是合理的。Sanmosa阁下还是多体恤读者情罢,求您了。--痛心疾首 2021年5月14日 (五) 13:16 (UTC)
  • (-)反对Sanmosa提案:要么原始标题与显示标题都用书名号(普通文章),要么都不用(特殊体例,像消歧义用“_()”),一边不用书名号,另一边用魔术字、模板加上多此一举。对Super Wang提案(=)中立绀野梦人 肺炎退散 2021年5月14日 (五) 14:41 (UTC)
  • (-)反对,per 痛心疾首。--安忆Talk 2021年5月14日 (五) 14:56 (UTC)
我认为上方各位的意见未有考量不同中文使用地区有不同的使用书名号的情形(Wikipedia:格式手册/标点符号#书名号),请上方各位重新考量,不要想当然。SANMOSA Σουέζ 2021年5月15日 (六) 03:00 (UTC)
@痛心疾首YumetoAnYiLinSANMOSA Σουέζ 2021年5月15日 (六) 03:07 (UTC)
补充:我质疑“中文里表示书名必然会用到引号、书名号、专名号”一说,在中文应用的实例上,表示书名时不附任何标点符号的情况存在(你总不能说这不是中文)。请痛心疾首不要将中国大陆的读者的习惯当成全部中文使用地区的读者的习惯。SANMOSA Σουέζ 2021年5月15日 (六) 03:25 (UTC)
仅就一些用户宣称香港不使用书名号一事进行事实查证:
台湾是否使用单双书名号,大家都清楚,台教育部门重订标准也好各种用例也好都是存在的,我不一一列举了。
至于在不使用书名号也不会混淆的情况,我认为维基百科应力求严谨,不应该以这种特例抬杠。--痛心疾首 2021年5月15日 (六) 03:34 (UTC)
(1)实际使用情况和所订立的标准可以不同,就如同我上面给出的链接一样,即使标准存在,也不代表是强制性、必须跟随的。而且上面(就香港)所举出的仅为个别范畴上的标准,而非所有领域的通用标准,维基百科不是刊物、学术论文或政府公文。痛心疾首上方得出的如此结论明显属于以偏概全。(2)而且我上方说的并不是只有使不使用书名号的情况,还包括怎样使用书名号的情况。有些情况下,有些地方用双书名号,有些地方用单书名号,有些地方用引号,这里就已经有不同了,但其他情况下又有可能一致,如果开许在标题直接使用书名号,就会产生大规模的命名紊乱情况,因为书名号在有些情况下需要转换,有些情况下不需要转换,还有些情况下只有一部分需要转换。书名号使用的乱象才会真正导致读者的困惑,这也是我跟大家说“不要想当然”的原因。SANMOSA Σουέζ 2021年5月15日 (六) 03:45 (UTC)
我对标题加不加书名号没有意见,但原始标题不加书名号的话没必要改实际标题,可以视作特殊体例,像消歧义的“_()”也没改成“()”;加书名号的话不同地区参维基百科:格式手册/标点符号即可。 绀野梦人 肺炎退散 2021年5月15日 (六) 03:41 (UTC)
如果一开初就加了书名号的话,会产生转换困难,见上。SANMOSA Σουέζ 2021年5月15日 (六) 03:55 (UTC)
(✓)同意我觉得条目名称加书名号很奇怪,如果真的想要书名号的话,可以使用手动转换的形式即可,“就‘《哈利·波特》的创作灵感来源及相似作品’的例子就足以说明问题,去除书名号后,谁知道你说的是小说系列还是虚构人物创作呢?”我是不觉得会有人把这个当成虚构人物创作的灵感来源,如果怕有人真的看不懂可以加上“哈利·波特系列的创作灵感来源及相似作品”这样,另外我就不说上面有些人的发言真的很情绪化呢。--Fglffer留言) 2021年5月17日 (一) 06:08 (UTC)
@痛心疾首YumetoAnYiLinJarodalienSANMOSA Σουέζ 2021年5月17日 (一) 06:57 (UTC)
不是反对不加书名号,是原始标题不加书名号的话实际标题也不用改。 绀野梦人 肺炎退散 2021年5月17日 (一) 08:21 (UTC)
@Yumeto:你稍早操作wikiplus的过程可能发生了一起MediaWiki无法识别的编辑冲突,麻烦您前来看一下,或者尝试修复,谢谢。我不敢删除他人留言,以免被人骂。-- 五岁抬☎️·☘️) 2021年5月17日 (一) 08:37 (UTC)
可笑之极,既然“可以使用手动转换的形式即可”,那又凭什么创建时标题不能有,不同种族、语言、文化的那些看不惯、觉得“很奇怪”的人,有谁劝阻你们用转换把标题转成你们觉得不奇怪的样式吗?你就是转成“zh-cn:《XXX》获奖名单;zh-hk:书名号真奇怪呀真奇怪真呀真奇怪奇怪性太强奇怪性极强太有奇怪性了;zh-tw:书名号真奇怪呀真奇怪真呀真奇怪奇怪性太强奇怪性极强太有奇怪性了”我也极力赞成。其次,反对用书名号的这都有些什么理由:一直没有,之前建没有,“很奇怪”,要转换很麻烦,说来说去这几类吧。这些理由能不能凌驾于汉语语法里面到底有没有书名之上?两岸N地简繁、地区词转换麻烦不?标题里面书名号奇怪,难道又有哪个标点符号放在标题不会有人觉得奇怪?日本ACG里面那些千奇百怪的标题,奇形怪状的符号也只有说因为技术限制没有办法显示所以用不了,书名号完全没有显示不了的问题居然都很奇怪,到底是不是少见多怪?还是那句话,我讲这些不期望不同种族、语言、文化的人也用书名号,但也请这些不同种族、语言、文化的人不要干涉他人用。--7留言) 2021年5月17日 (一) 12:11 (UTC)
“可以使用手动转换的形式”,那我创建时为何不能有呢?另外,Sanmosa,不是我想批评,但看到支持您的观点便广而ping之,颇有种捡到救命稻草的味道。--痛心疾首 2021年5月17日 (一) 12:16 (UTC)
让我按照这个提议条文来模拟一下条目标题有或无书名号下的情况
  • 无书名号
    1.添加转换→完成
  • 有书名号
    2.添加转换→创建重定向→完成
那很自然地我会选择1,因为简单直接,而且效果一样。当然有人要选择2的话,只要愿意不厌其烦地创建重定向的话我认为也没有问题。--AT 2021年5月17日 (一) 14:09 (UTC)
另外,鉴于目前规定仍然是不允许条目标题有书名号,因此请7停止在条目标题中添加书名号的行为,否则等同违反WP:POINT,敬请合作。--AT 2021年5月17日 (一) 14:15 (UTC)
第一、你觉得“很自然”要选择哪个,我觉得别的任何人也管不着,同时正常人的话应该也不会在乎。第二、看不出为什么第一种情况就一定没有“创建重定向”这步,也无法理解为什么第二种情况就一定要有。比如在我们大陆种族来看,带上书名号是理所当然的,不带才奇怪,所以应该是看到不带的才会创建重定向,带的根本不知道为什么要建别的。反过来也一样,香港和台湾的种族如果觉得书名号那就是奇怪,就是不正常,然后就要建重定向,那谁也管不着啊,爱咋咋滴,这不正是世界大同之道么?--7留言) 2021年5月17日 (一) 14:21 (UTC)
创建重定向当然是因为要配合内连。至于为什么第一种不需要创建重定向,因为既然在已经转换的情况下,那就不会还有什么需要去创建带书名号的重定向,一般人搜索的时候不加书名号去找的可能性远比加书名号要大吧?也正因如此,在标题有书名号的情况下无书名号重定向是有必要的。--AT 2021年5月17日 (一) 14:49 (UTC)
刚刚没看到上面的另外,你这句“另外”那我就谴责一下,至少这里我和Y、SuperWang对这句方针的理解没有你们几个那么卡死,认为现有方针只针对条目名就是作品名,没有其他文字的情况。而且你们耍的这种手段已经见得太多了,如果现在退让,你们只需“坚持”,继续高呼“无共识”所以不能改方针,反过来又说方针是如何如何规定禁止,他人违反方针、违反WP:POINT,进而又用这种威胁把“一直以来都是如何如何”长久稳固下去。而且这种手法还可以持续挑衅,一直采用各种手段移动,反正他们无论怎么移动都OK,我移回来就是WP:POINT,WP:OWN等等一堆帽子。--7留言) 2021年5月17日 (一) 14:48 (UTC)
请AGF,觉得规定有问题可以提出,但是在尚未形成共识的情况下,不应通过以身试法来试图证明自己的观点,这是基本原则。您认为理所当然的东西,别人却认为有问题的时候,就理应停止相关动作,并且展开讨论。--AT 2021年5月17日 (一) 14:57 (UTC)
你族对我族扣WP:POINT、WP:OWN等帽子的时候,就不要再来说什么AGF了。“您认为理所当然的东西,别人却认为有问题的时候,就理应停止相关动作,并且展开讨论”这话很对,请放到你族身上试试。而不是只来要求我族。--7留言) 2021年5月17日 (一) 15:05 (UTC)
我从来都是以这个信条来编辑,不存在只要求谁,希望您能够配合。谢谢。--AT 2021年5月17日 (一) 15:20 (UTC)
@痛心疾首:不是救不救命的问题,而是难得有人能清楚说明我的观点的问题,难道我就不能想办法让你们对我的观点再了解得清楚一些吗。另外AT算是回应了你问的东西,我想看你的回应。不过你要看成“救命稻草”也不是不可以,只要是真的能救命的,那就确实是“救命稻草”,至少比不能救命的稻草和连不能救命的稻草也没有来得强。SANMOSA Σουέζ 2021年5月17日 (一) 23:55 (UTC)
@安忆:同上,我寻求你对AT说的东西的回应。SANMOSA Σουέζ 2021年5月18日 (二) 02:26 (UTC)
怎么说呢,有书名号在我看来是正常的,没有则是不合语法的。英语没有书名号是因为它用斜体,我认为需要书名号是因为我这面语文就是这么教的。希望可以考虑一下不同地区中文的差异。至于浏览器地址栏里那个名字带不带书名号,我只能说有人如果不嫌标题转换麻烦的话,我无所谓的,页面内容看着对就行。--安忆Talk 2021年5月18日 (二) 03:08 (UTC)
同上。--痛心疾首 2021年5月18日 (二) 04:59 (UTC)
@安忆痛心疾首:如果是这样的话,那就算是我的提案也能做到这事情,因为我的提案并没有禁止在标题进行转换。这类型的页面所牵涉的作品名本来在不同地方就有不同的译名,因此那些条目本来就有标题转换的需要,我的提案只是让标题转换同时负责书名号显示的事情而已,而且这事情早就有中文维基百科的条目在做。后续工夫并不多,在转换码中显示的名称补回书名号即可(不然我在我的提案写“此条不影响条目中显示的标题中书名号的使用”是在做什么)。SANMOSA Σουέζ 2021年5月18日 (二) 07:58 (UTC)
“标题转换同时负责书名号显示的事情而已”?标题转换是拿来给你转换书名号的吗?又要来一次“武肺”“新冠”相互转换是不?按阁下这提案,跟中维分家有什么区别?--痛心疾首 2021年5月19日 (三) 14:42 (UTC)
@痛心疾首:如果在该范畴使用书名号的方式不同(例如单曲的名称的表达时,简体用双书名号,繁体用单书名号),那“转换书名号”的情形是确实会出现的。如果在该范畴使用书名号的方式相同的话,那“转换书名号”的情形不会出现,情况就是所有转换模式加入的书名号完全一样。SANMOSA Σουέζ 2021年5月19日 (三) 14:48 (UTC)
  • 比较赞成Yumeto的看法--Temp3600留言) 2021年5月17日 (一) 12:35 (UTC)
  • 单纯地(...) 吐槽:这不能讨论到最后也变成“先到先得”吧…--安忆Talk 2021年5月17日 (一) 14:19 (UTC)
加书名号提案的影响范围似乎包括“XX角色列表”,例如刀剑神域角色列表可能要移动至“《刀剑神域》角色列表”。--Mewaqua留言) 2021年5月17日 (一) 14:28 (UTC)
@Mewaqua:你说的情况太恐怖,一大推“XX角色列表”条目全要加书名号,岂不是要推翻一堆条目命名,还不如保持现状不加书名号呢。--驻军留言) 2021年5月19日 (三) 15:38 (UTC)
  • 所以说那个方案?大家都反对→但原本的方针又没支持→建议含有书名号的名称被移动→产生争议。大家陷入无限循环之际,还是记得写一下方针。 --Loving You Is A Losing Game 2021年5月17日 (一) 14:37 (UTC)
    Wikipedia:共识#什么是共识:“共识应当考虑到所有正当合理的意见”,我会想办法处理。SANMOSA Σουέζ 2021年5月17日 (一) 23:58 (UTC)
  • 意见大致同AT阁下。我认为对于这类条目,规定预设标题不带书名号,并强制创建带书名号的标题显示转换为宜。不管各地对于书名号的书面使用惯例如何,读者自己在搜索时基本不会带著书名号一起搜,这是反人类惰性直觉的。某种程度上,这跟“常用名称”与“名从主人”原则之间的关系有点类似。—— Eric Liu 创造は生命(留言留名学生会 2021年5月18日 (二) 16:38 (UTC)
    • 以常用来讲,书名号打出来要很多步骤...,懒人情况下根本不会打。这边可以调查一下各位搜索作品得奖列表(清单)会不会加书名号,至少我没看到有人这么乖会打“《三体》得奖”之类的。 --Loving You Is A Losing Game 2021年5月19日 (三) 13:13 (UTC)
  • 我比较认同这几种方案:
    • 规定原始标题不用书名号→不处理实际标题[视作特殊体例,像消歧义的“_()”并不会改成“()”]
    • 规定原始标题用书名号→原始标题有单双书名号之别则转换,无则不处理实际标题(按一般行文处理)
    • 先到先得→原始标题有单双书名号之别则转换,其余则不处理实际标题

绀野梦人 肺炎退散 2021年5月18日 (二) 16:55 (UTC)

我补充一点:通过-{T|}-或{{noteTA}}的参数只在条目内显示的标题显示回书名号也不是强制性安排(但不会强制不显示),可以看编者的意愿。SANMOSA Σουέζ 2021年5月18日 (二) 23:58 (UTC)
上面几位大陆用户都已经说明了,看起来对于大陆种族的意见,香港和台湾种族是无法正视、理解或接受的,大陆种族在此人数又太少,所以连语言文化都要以其他种族为准。他们除了一次又一次说明、强调不同以外什么也做不了,那就再多说一遍吧,立此存照:
  1. 对于大陆种族来说,遇到文艺作品名称而不用书名号,首先这是根本的语法错误,小学语文都无法接受;
  2. 对于其他种族所谓的“惰性”、“直觉”,大陆种族无法理解,反过来很显然大陆种族眼中的语法错误,其他种族也无法理解,可惜的是简繁又总是不能分家,所以大陆种族什么办法都没有。大陆种族觉得这种“一般人搜索的时候不加书名号去找的可能性远比加书名号要大吧”、或者“书名号打出来要很多步骤...,懒人情况下根本不会打”、或者“读者自己在搜索时基本不会带著书名号一起搜,这是反人类惰性直觉的”这种意见,首先是确立在错误的语法基础上,其次是确立在之前长期使用错误的语法大家习惯了,第三是少字(少符号)的搜索永远比多字(多符号)要“常见”,如果来说,比尔·克林顿应该移动到克林顿;两个布什应该分别移动到老布什和小布什,几乎所有总统都应该移动到姓氏不要名字,因为用全名肯定更“反人类惰性直觉的”、“打出来要很多步骤...,懒人情况下根本不会打”、“只用姓氏的可能性远比全名要大”、“读者自己在搜索时基本不会带着全名一起搜”;
  3. 大陆种族不期望其他种族也按他们的习惯行事,只希望能够按小学就教过的语法行文;
  4. 大陆种族无法理解为什么自身意见就一定要打折扣,标题就是一定要按其他种族的要求行事,不知道香港人是否很希望智利人来教他们白话语法,台湾人会不会很乐意让冰岛人来教他们《金包银》要怎么唱才比蔡秋凤对味。大陆人不是很喜欢让不同种族、语言、文化的人来说你们在标题里用书名号是不对的,不应该用,你非要看书名号我最多可以“让”你们用noteTA来加,不然你们太麻烦了,太反直觉了,太不让读者方便了,太多步骤了等等等等。--7留言) 2021年5月19日 (三) 14:11 (UTC)
所以你搜索相关内容的时候会不会打书名号? --Loving You Is A Losing Game 2021年5月19日 (三) 14:13 (UTC)
请你不要说到好像只有中国大陆的那套语法才是唯一的中文语法标准(而且有些时候你的那套语法也不是中国大陆的那套语法)。读者不会关注browser内的标题,而只会关注页面内显示的标题,因此我才会建议通过-{T|}-或{{noteTA}}的参数在条目内显示的标题显示回书名号,而且上面已经有部分之前反对我的提案的用户表明接受这样的处理了,请你不要把自己当成所有中国大陆用户的代表。刻意塑造二元分立对中文维基百科社群的和谐完全无用。SANMOSA Σουέζ 2021年5月19日 (三) 14:18 (UTC)
你哪个眼睛看到我任何一句话有任何地方明示或暗示“只有中国大陆的那套语法才是唯一的中文语法标准”?我自始至终强调的都是你们和我们种族、文化、语言完全不同,你们要用哪种我们管不着也不会管也不在乎。“读者不会关注browser内的标题,而只会关注页面内显示的标题”这是你们种族的理解,我们种族的理解就是不管标题还是正文,文艺作品名称没有书名号那就是错误语法,小学语文都要打叉,这种也要听你们种族的才对?“中文维基百科社群的和谐”来自于每个种族对不同种族有基本的尊重,而不是用尽一切手段要让其他种族连自身语言、文化的根本语法、习惯都放弃。--7留言) 2021年5月19日 (三) 14:28 (UTC)
我重申一次:上面已经有部分之前反对我的提案的用户(其中包括来自中国大陆的用户)表明接受我提议的处理方式,请你不要把自己当成所有中国大陆用户的代表SANMOSA Σουέζ 2021年5月19日 (三) 14:31 (UTC)
那又怎么样?又有哪些人明确表态“赞成标题里无论如何都不能有书名号,不管是单文艺作品名称,还是《文艺作品名称》+各种描述语言文字”?你的提案无非就是要在标题禁止书名号,要求“想看到书名号”的用noteTA、displaytitle这类辅助手段来显示,还是按照你们种族的语言,有人觉得“用noteTA、displaytitle这类辅助手段来显示”可以接受,就完全等同于“标题里无论如何都不能有书名号,不管是单文艺作品名称,还是《文艺作品名称》+各种描述语言文字”?即使加上很多非大陆种族,认为“完全可以不用”的用户,彻底主张“无论如何都不能有书名号”除了你还有谁?--7留言) 2021年5月19日 (三) 14:52 (UTC)
所以我应该怎样?应该把自己当成全人类的代表说“读者不会关注XXXX”,还是应该说upload就是上载,上传是错译?--7留言) 2021年5月19日 (三) 16:00 (UTC)
容许我在这里举一个反例:中国大陆的同类百科网站的条目(词条)页面在browser内的标题也不会显示书名号,那也可以证明(有相当一部分的)中国大陆读者不会关注browser内的标题。SANMOSA Σουέζ 2021年5月19日 (三) 14:35 (UTC)
《标点符号用法》(GB/T 15834-2011)#4.15.3,某些网站语文没学好罢了。--安忆Talk 2021年5月19日 (三) 14:45 (UTC)
有官方标准却不依循,根本的原因是不便依循,而不依循也不会让读者产生问题而已。Inertia的出现不是没有原因的。SANMOSA Σουέζ 2021年5月19日 (三) 14:48 (UTC)
我国实行的标准、教育界一致教授的用法被您说成“不便依循、Inertia”,我也没什么可说的了。没提为什么不实际名称就用书名号,港台加地区词转换完全是因为这煮起来没头,说不定还会被扣个POINT,可不是让您整什么“不便依循”云云。您还有所克制,没借用上面的什么“懒人说”说事,真是谢谢您。--安忆Talk 2021年5月19日 (三) 15:00 (UTC)
这可以算作是替那些不遵循国标的网站开脱了吧。--2, 3, 5, 7, 11, 13, 17... 2021年5月20日 (四) 11:27 (UTC)
或许我这样问:你身边的人真的会有人这么执著于页面在browser内的标题吗?有的话,是多数吗?SANMOSA Σουέζ 2021年5月19日 (三) 14:51 (UTC)
您知道为什么用错误用法的网站还存在吗?是因为暂时还没有那么严格,不是出版机构。--安忆Talk 2021年5月19日 (三) 15:03 (UTC)
不,这单纯是因为技术问题不好处理而已。有些网站(中国大陆以外的)中,页面标题显示的标点符号在网址里全部直接转成hyphen。网址里标点符号的处理从来就没有一个所谓的“正确”的处理办法,没有多少中国大陆以外的网站会真的在网址里加入全形书名号,为何中文维基百科只能跟随中国大陆的一个没人遵守的官方标准?SANMOSA Σουέζ 2021年5月20日 (四) 00:50 (UTC)
sanmosa阁下指出的争议,相信为本案讨论之关键点,基于本站规例与自治运作之自行决定等脉络,认为理应由社群内不同编辑之立足点而更多样化处理,如引用单一外部规则恐有超界干预本站编辑之立基,有妨碍本地达成共识之公正。--约克客留言) 2021年5月22日 (六) 03:06 (UTC)
表示“不关注地址栏内的名字,页面内容看着对就行”完全是一种妥协。这提案反过来可以让我更习惯,即实际名称就用书名号,港台加地区词转换,但显然这争下去没头。这妥协不是让您去说别人“把自己当成所有中国大陆用户的代表”的。同时,不同的意见亦非POINT。--安忆Talk 2021年5月19日 (三) 14:33 (UTC)
@AnYiLin:见上。我得出如此结论不是单凭站内妥协的,我也是讲求实例的。SANMOSA Σουέζ 2021年5月19日 (三) 14:35 (UTC)
读者的惰性是不分所谓“种族”的,虽说我完全不知道为什么这里要提到什么“种族”。—— Eric Liu 创造は生命(留言留名学生会 2021年5月19日 (三) 14:50 (UTC)
但语法是分地区的,大陆有统一的教育标准和应用规定。--安忆Talk 2021年5月19日 (三) 15:18 (UTC)
一个没人遵守的官方标准,不见得能够真的作准。即使能够真的作准,还是回到这个问题:为何中文维基百科只能跟随中国大陆的标准?SANMOSA Σουέζ 2021年5月20日 (四) 00:50 (UTC)
因为那个标准在我方看来是对的,教材那么教,标准那么规定。我没看出中文符号有什么技术问题,又不是英文。您这个问题真的很没意思,说了没头,完全可以反过来,“为什么中文维基百科只能跟随你香港的用法走”。--安忆Talk 2021年5月20日 (四) 01:18 (UTC)
我问“为何中文维基百科只能跟随中国大陆的标准?”这个问题,是因为定了书名号使用的官方标准的地方不是只有中国大陆。SANMOSA Σουέζ 2021年5月20日 (四) 05:20 (UTC)
不遵守标准的早被国家新闻出版署给干烂了,刊号和发行许可都给你回收了,只是你没看到而已。--痛心疾首 2021年5月20日 (四) 01:57 (UTC)
我建议你们重新留意你们一向会留意的网站多几次,这官方标准的执行力度远远没有你们想像中的那么大。SANMOSA Σουέζ 2021年5月20日 (四) 05:20 (UTC)
毕竟GB后有/T。 绀野梦人 肺炎退散 2021年5月20日 (四) 07:23 (UTC)
所以Jarodalien大你知不知道你自己在做什么?要加书名号没有问题,但最后的结果就是“强制”大家一起加。怎么,只有你可以强制我们我们不能强制你就对了?再来就是方针,阁下除了“我要加书名号”的口号外,到底有什么规划?你一个规划都没有谁知道你要干嘛,具体该怎么做,还是这个时候又可以说“头脑正常的人不会理解错误就行了”,那没加书名号也不会理解错误啊= =。你规划提出来我才好给予意见给予支持。 --Loving You Is A Losing Game 2021年5月19日 (三) 15:06 (UTC)
这更证明我们种族不同了,我根本看不出上方任何发言有“强制”你们任何人的意思,我的主张就是要加的人能加就行了,不愿意加的人关我什么事啊?你看过任何时候我在乎其他种族怎么写标题吗?无法理解为什么你会有“只有你可以强制我们我们不能强制你”、“最后的结果就是“强制”大家一起加”的理解。--7留言) 2021年5月19日 (三) 15:53 (UTC)
@Jarodalien:跟种族没关,是你没有意识到后果。根据命名一致性,这部分当然会强制,不管你有没有你那个意思,最终导致的结果仍是“强制”你们任何人。这就是方针。 --Loving You Is A Losing Game 2021年5月19日 (三) 16:03 (UTC)
这显然和种族、语言有关,把不带改成可带,或是先到先得不就完了,直接删掉原有条文也不会强制要求一定要有或是没有书名号。--7留言) 2021年5月19日 (三) 16:20 (UTC)
和种族、语言有关...,大陆人又不是盲人,你眼瞎看不到“根据命名一致性,这部分当然会强制”就别扯种族啦。话说不提命名一致性,改成可带还有先到先得只会让日后点开分类看到一半有加一半没加的条目名称,那绝对会很混乱。 --Loving You Is A Losing Game 2021年5月19日 (三) 16:37 (UTC)

在书名号加与不加的问题上,不同地区理应没啥差别。希望大家就事论事,不要强调地区身份来寻衅,对寻衅的部分也不必理会。

观乎原条文,其本义只是“条目主体能放入书名号的话,最外侧的书名号不出现在条目名称中”(仅禁止《这样的条目名称》)。若有其他理解属于误读,改掉原先有歧义的表述即可,无需做更多规定。--Lt2818留言) 2021年5月19日 (三) 15:07 (UTC)

正是因为“最外侧的书名号不出现在条目名称中”并不符合标点符号的基本用法才会招致反对,原文明明执行的好好的,现在倒是在纳闷到底是谁寻衅滋事横插一脚。什么叫“无论是否书、篇、报纸、刊物、歌曲、戏曲等的条目本身,在条目名称中均不使用书名号”?上文讨论中,大家都理解为“XX作品获奖列表”这种不使用书名号,但这显然不合理。再对应下文“就非书、篇、报纸、刊物、歌曲、戏曲等的条目本身的条目而言,此条不影响条目中显示的标题中书名号的使用”,他到底想干什么?这根本就是在互相矛盾。无论是从降低文盲率的角度还是从条文逻辑性的角度,Super Wang的修正案才是更合理的。--痛心疾首 2021年5月19日 (三) 15:15 (UTC)
“书、篇、报纸、刊物、歌曲、戏曲的条目名称不带书名号。”这段原文根本超多槽点好不,“XX作品获奖列表”里面的“XX作品”难道不算“书、篇、报纸、刊物、歌曲、戏曲的条目名称”。我要改的话会是这样“条目名称只有书、篇、报纸、刊物、歌曲、戏曲等名称时不带书名号,如果名称不只书、篇、报纸、刊物、歌曲、戏曲等名称,则带书名号。” --Loving You Is A Losing Game 2021年5月19日 (三) 15:33 (UTC)
“书、篇、报纸、刊物、歌曲、戏曲的条目”跟“与书、篇、报纸、刊物、歌曲、戏曲的属性有关的条目”本身根本是两个概念,我认为阁下的理解可能有一些偏差。--痛心疾首 2021年5月20日 (四) 02:02 (UTC)
ˊ_>ˋ)哪里是两个概念?就算是获奖列表,他仍是书、篇、报纸、刊物、歌曲、戏曲的条目,不会因为多了获奖列表就不是书、篇、报纸、刊物、歌曲、戏曲的条目。 --Loving You Is A Losing Game 2021年5月20日 (四) 03:08 (UTC)
@Lt2818:有分别,见Wikipedia:格式手册/标点符号#书名号SANMOSA Σουέζ 2021年5月20日 (四) 00:50 (UTC)
已修改措辞。--Lt2818留言) 2021年5月20日 (四) 01:06 (UTC)

小结

感觉讨论方向愈来愈迷走,在这里就以下问题,希望了解一下各位的立场。

  1. 书名号是否可以作为条目标题的一部分来使用?
  2. 在条目标题加书名号的对象是否包括所有媒体或文学作品的相关条目(例如XXX得奖列表)?
  3. 添加的话是有歧义的情况才加,还是都加?
  4. 能否接受转换替代直接添加书名号至条目标题?
  5. 添加书名号至标题后是否需要同时创建无书名号重定向?(反之亦然)
  6. 无书名号的条目标题是否可以沿用?
  7. 单书名号等复合情况出现的话如何解决?
  8. 添加书名号与否是否先到先得?
  9. 如果XXX得奖列表需要加书名号来避免歧义的话,在只有XXX的时候也不加书名号的现行规定下,那XXX本身的歧义项是否可以引入至标题,改成例如“XXX得奖列表 (消歧义)”之类?
  10. XXX不加书名号与XXX得奖列表要加书名号的差异在哪里?
    暂时以上。谢谢。—AT 2021年5月19日 (三) 16:33 (UTC)
1.是,如标题内部含书名号的作品。4.否,实际标题有否书名号最好与原始标题一致,同时有或同时无。5.是。7.字词转换。9.中立:有歧义的是×××而非列表,不过也可以视作本百科特有格式。像现代标准汉语的“一”跟在不同音前音调不同,这本教材按实际发音标注,《现代汉语词典》则在“一”字头下说明这种规律,并表示“本词典为简便起见,条目中的‘一’字,都注阴平”。10.一个是作品,一个非作品。2、3、6、8.中立。 绀野梦人 肺炎退散 2021年5月19日 (三) 17:37 (UTC)
我翻到了最早加入该规定的编辑,由Zy26君作出。可以看到其目的只是便于内部链接,无意禁止书名号作为条目标题的一部分使用。书名号有时是必须的,例如项目空间的Wikipedia:是《是英文维基说的!》说的!,没书名号蛮难办。
当然统一用书名号也不合适,要分情况,个人认为无歧义就无需添加。一致性原则在局部有效即可,不必全局统一。--Lt2818留言) 2021年5月19日 (三) 17:44 (UTC)
  1. 可以作为标题一部分;当描述作品本身时,应略去最外层书名号以避免双重书名号的特殊情况
  2. 应该包括
  3. 都加
  4. 当需要进行单双书名号转换时可以接受,其他情况中立
  5. 是的
  6. 中立,视本讨论结果而定
  7. 当条目描述作品本身时,应略去最外层书名号以避免双重书名号的特殊情况
  8. 中立。
  9. 中立。有歧义的是×××而非列表
  10. 描述作品本身和描述作品随附属性(如获奖),二者存在区别。
--痛心疾首 2021年5月19日 (三) 18:08 (UTC)
(1、2、3)完全不加,除非遇着超犀利趴三《团团团团团》演唱会 LIVE这种情况(在省略因作为媒体或文学作品而产生的书名号后仍然有书名号,而且并非因作为媒体或文学作品而产生【标题内部本身含书名号】)这种情况,这时可以例外。(4)这本来就是我的提议,我不可能反对,但我不倾向作为强制性措施。(5)如果遇着(1、2、3)所提及的例外情况,可以不建。如果是连因作为媒体或文学作品而产生的书名号也要加入到标题中,那必须建。(6)我本来就主张无书名号的条目标题,我当然会认为要沿用无书名号的条目标题。(7)沿用无书名号的条目标题的话,基本上出现单书名号等复合情况的几率极小。如果单书名号等复合情况是遇着(1、2、3)所提及的例外情况的话,保留相关书名号。如果再牵扯到书名号使用方式的差异的话,再针对书名号进行转换。(8)这里不能先到先得,Wikipedia:命名常规#命名一致性具备实行优先性。(9)XXX得奖列表本身也有歧义项(同名的不同电影都有获奖与提名的情况)的话,可以这样建,否则完全不应该。(10)完全看不出有任何的差别。SANMOSA Σουέζ 2021年5月20日 (四) 00:43 (UTC)
小妇人当例子,条目会后是变成小妇人获奖与提名列表 (2019年电影)小妇人获奖与提名列表 (2018年电影),要变成这样也需要有复数条目存在才是。关于单书名号,这样可能要变成规定有用单书名号的名称需优先使用单书名号(刚好配合书名号转换),不然处理双书名号会很麻烦(当然前提是该条目直接使用简体→双书名号,繁体→单书名号的单纯转换)。 --Loving You Is A Losing Game 2021年5月20日 (四) 03:08 (UTC)
  • (1) 当条目标题包含文艺作品时应当加入书名号(用公开出版的书籍标题举例:《左传》精读),但当条目介绍文艺作品本身时不应加入书名号(左传)。(2) 是。(3) 都加。(4) 能,但应创建相关重定向,方便内链。(5) 可以。(6) 可以。(7) 因文艺作品的条目本身不含书名号,单书名号几乎不会出现。(8) 中立。(9、10) 同痛心疾首。--| 2021年5月21日 (五) 19:44 (UTC)
  1. 可以
  2. 🤔
  3. 我觉得最好都加埋
  4. 可以接受
  5. 需要
  6. 无论最后系用边个方案都好,个格式最好尽量一致
  7. 🤔
  8. 最好唔好,你咁样做会搞到啲 URL 好乱㗎
  9. 🤔
  10. 咁你觉得叶问《叶问》嘅分别系咩?😏
完。--<JasonHK ✉️ 📝 /> 2021年5月23日 (日) 10:49 (UTC)
我翻译一下这几个题目:
  1. 是否应该用方针为纲领、以指控他人违反方针、WP:POINT乃至封禁为手段,强迫用户不准或必须在条目名称中使用书名号?
  2. 是否应该用方针为纲领、以指控他人违反方针、WP:POINT乃至封禁为手段,强迫用户不准或必须在条目名称中使用书名号?
  3. 是否应该用方针为纲领、以指控他人违反方针、WP:POINT乃至封禁为手段,强迫用户不准或必须在条目名称中使用书名号?
  4. 想加书名号的人应该用转换,用displaytitle或其他手段,所以是否应该在方针上还是禁止条目名称出现书名号,进而以指控他人违反方针、WP:POINT乃至封禁为手段,强迫用户不准或必须在条目名称中使用书名号?
  5. 是否应该要加书名号的人必须同时创建无书名号重定向,反之亦然,否则就不要给大家添麻烦?
  6. 是否应该用方针强迫他人在标题中带或不带书名号?
  7. 两岸N地对书名号规则不同,非常复杂,非常麻烦,所以你们还是放弃,用转换吧,方针应该禁止书名号。
  8. 有些有书名号,有些没有,不“统一”,“不便于管理”,会引发编辑战移动战,增加社区不稳定、不团结隐患,你们还是放弃吧?
  9. 加书名号不能解决消歧义问题,你们还是放弃吧?
  10. 在标题加书名号根本没必要,没差异,标题地位特殊不应该考虑语法。ACG的各种千奇百怪的符号都没关系,但书名号实在难看,你们还是放弃吧?--7留言) 2021年5月25日 (二) 12:15 (UTC)
请勿蓄意破坏社群和谐。SANMOSA Σουέζ 2021年5月26日 (三) 00:03 (UTC)

一种可能的解决方案

我的立场已经在上面说过了。为消除歧义,一些场景下有加上书名号的必要,但不适用于所有情况,如圣经章节加书名号则显得画蛇添足。而上面的讨论中也提到,条目名带书名号不便于搜索,也存在繁简使用形式差异的问题。

看到英文维基百科使用DISPLAYTITLE为标题加上斜体。而中文不用斜体,标题也用不着加粗,因而构思了一种用CSS实现的解决方案。

约定以下语义,适用于各种能修改标题的语法。

  • 在繁体模式下,两个撇号(等价于HTML的<i>标签)包围部分的两边显示双书名号。
  • 在繁体模式下,三个撇号(等价于HTML的<b>标签)包围部分的两边显示单书名号。
  • 在简体模式下,两种标记无异,外层标记总显示双书名号,内层标记总显示单书名号。
  • 若有嵌套使用同种标记的必要性(《《》》以及〈〈〉〉),须以HTML语法辅助,因为wiki语法无法识别。

这样做的优点在于:

  1. 两个撇号的语义与英文一致。
  2. 繁简兼容。对于多数页面,用{{DISPLAYTITLE|标题}}指定一次即可,会适应不同模式。
  3. CSS加上的书名号无法选中,便于复制标题后链接使用,因此消除了创建不同“书名号重定向”的必要性。

实现该功能的CSS如下。为缩短代码长度使用了新的CSS语法,需要最新的浏览器才能显示正确效果(实际应用时应扩写以实现兼容)。保存时会提示错误,忽略即可。

:is(#firstHeading, #section_0) :is(i, b) {
	font-style: inherit;
	font-weight: inherit;
}

:is(#firstHeading, #section_0) i::before,
:is(#firstHeading, #section_0) b:lang(zh-Hans)::before {
	content: "《";
}
:is(#firstHeading, #section_0) i::after,
:is(#firstHeading, #section_0) b:lang(zh-Hans)::after {
	content: "》";
}

:is(#firstHeading, #section_0) b::before,
:is(#firstHeading, #section_0) :is(i, b) :is(i, b):lang(zh-Hans)::before {
	content: "〈";
}
:is(#firstHeading, #section_0) b::after,
:is(#firstHeading, #section_0) :is(i, b) :is(i, b):lang(zh-Hans)::after {
	content: "〉";
}

另外对登录用户而言,页面标题的lang属性是跟用户设置走的,此为系统bug,需更改参数设置中的语言变种才能看到其他模式下的正确效果。

--Lt2818留言) 2021年5月21日 (五) 04:39 (UTC)

刚刚在沙盒里面测试了一下,最大的问题就是在选中标题时无法将书名号一并选中,复制粘贴时书名号效果就消失了。--痛心疾首 2021年5月21日 (五) 07:56 (UTC)
这正是用CSS实现的目的,复制下来的是不带书名号的原名称,可直接用于链接。--Lt2818留言) 2021年5月21日 (五) 08:10 (UTC)
在这种情况下,是否还需要创建带书名号的重定向以便检索?--痛心疾首 2021年5月21日 (五) 10:02 (UTC)
@Lt2818:理论上能做到自动跳转的效果吗?@痛心疾首:如果能做到自动跳转的效果,理论上可以不用另外创建带书名号的重定向页(但可以不限制创建),否则还是需要创建。这概念大概与Wikipedia:重定向#中文繁简体问题说的情况差不多。SANMOSA Σουέζ 2021年5月21日 (五) 10:08 (UTC)
不行,要改软件。前几年支持了 apples 这样形式的链接,正因为英文常用。感兴趣的朋友也可以为改进中文支持做一下贡献。--Lt2818留言) 2021年5月21日 (五) 10:30 (UTC)
当然可以创建,但是不必。若用字词转换的方式解决,直接复制标题必为红链,这时就有创建重定向的必要性。--Lt2818留言) 2021年5月21日 (五) 11:55 (UTC)
@Lt2818:部分情况下繁体和简体同样使用单书名号,这是两个撇号的部分处理的范畴吗?SANMOSA Σουέζ 2021年5月21日 (五) 10:08 (UTC)
这种应写三个撇号。简体按照内外层次区分单双书名号,很容易用代码实现;而繁体看语义,只能用不同的符号表示。我看了台湾《重订标点符号手册》,没有找到书名号内外层次之别,所以在繁体模式中未禁止内层的双书名号。如果有其他信息是我不知道的,欢迎提出。--Lt2818留言) 2021年5月21日 (五) 10:30 (UTC)
刚刚重写了语义表述,应该更清晰一些。--Lt2818留言) 2021年5月21日 (五) 12:05 (UTC)
所以具体如何操作?—— Eric Liu 创造は生命(留言留名学生会 2021年5月21日 (五) 13:58 (UTC)
要测试的话,将以上代码放入Special:MyPage/common.css,随后在任意页面写入形如{{DISPLAYTITLE|'''逍遙遊'''和'''''中國工人'''發刊詞''}}的测试文本,标题在繁简模式下应有不同显示。
如果这种方案被接受的话,将上述代码配置为站点小工具即可。--Lt2818留言) 2021年5月21日 (五) 15:23 (UTC)
我不反对这样设置,但由于“在选中标题时无法将书名号一并选中,复制粘贴时书名号效果就消失了”(痛心疾首)、“复制下来的是不带书名号的原名称,可直接用于链接”(Lt2818),那为免造成混乱,原名称(条目原始标题)反倒变成只能在标题内部本身含书名号的情况下保留书名号了(这种情况是迁就技术因素)。如果有什么理解错的地方,请指出。SANMOSA Σουέζ 2021年5月22日 (六) 02:11 (UTC)
这里是在原始标题不写书名号的时候,提供一种在标题显示书名号的手段。如果选择在原始标题里加书名号,那么不用这个办法即可。--Lt2818留言) 2021年5月22日 (六) 04:49 (UTC)
@Lt2818:这小工具还有一个问题:如果条目原始标题本身也存在地区词,这小工具是要怎么设置?还是直接在{{noteTA}}处理,然后小工具用不着?SANMOSA Σουέζ 2021年5月22日 (六) 02:11 (UTC)
这是一个例子。--Lt2818留言) 2021年5月22日 (六) 04:49 (UTC)
大概理解了。SANMOSA Σουέζ 2021年5月24日 (一) 00:46 (UTC)
  • 伪元素来实作是不是不太好,因为他是“伪”元素,不仅无法被选取,也无法在不支援“伪”元素CSS的装置上显示。我目前看过的伪元素一般仅供视觉效果(排版、表格开头记号、物件的ICON等),比较少拿来做为正式内容,且jQuery(...).text()也会自动忽略伪元素,所以这也只是加上去好看的,实际上可以视为没有加吧。建议用JS加上“真”元素-- 五岁抬☎️·☘️) 2021年5月22日 (六) 02:48 (UTC)
    • 差不多同上。不过不支持伪元素的浏览器也只有IE8-了,不用考虑兼容性。而::is的兼容性过于感人(属草案,Chrome88+),能不能直接贴个兼容写法?--安忆Talk 2021年5月22日 (六) 02:55 (UTC)
      • 兼容的版本写在了User:Lt2818/common.css,不支持minerva皮肤,否则再长一倍。--Lt2818留言) 2021年5月22日 (六) 04:49 (UTC)
        • 经测试,移动端不兼容。--痛心疾首 2021年5月22日 (六) 05:37 (UTC)
          • 移动端就是minerva。刚刚把上述页面扩写为了支持minerva的完全版。--Lt2818留言) 2021年5月22日 (六) 05:56 (UTC)
    • 加真元素直接{{DISPLAYTITLE|《……》}}即可,JS反而带来界面元素的跳变。--Lt2818留言) 2021年5月22日 (六) 04:56 (UTC)
  • 这里应该是有共识可搬运至技术版讨论、关闭上方先吧?上边都是需要技术专业人参与的范畴--约克客留言) 2021年5月22日 (六) 03:13 (UTC)
    • 这与上方的讨论较为独立。因为都加书名号不合理,所以给选择不加书名号的条目提供一种显示书名号的手段。--Lt2818留言) 2021年5月22日 (六) 04:49 (UTC)
  • 所以应该是要找时间公示《是否用站内小工具添加书名号》,通过了才移交技术区,研究该用哪个方式或算法来实装吧。-- 五岁抬☎️·☘️) 2021年5月22日 (六) 03:19 (UTC)
由于这个讨论串长期被闲置,我完全不知道究竟其他人想做什么,所以容许我这里依照A2569875之前的提议,公示“应用Lt2818 CSS办法,并将该办法所涉及的小工具全站启用”此提议7日。如此提议通过,会移交WP:VPT处理。SANMOSA Σουέζ 2021年6月1日 (二) 09:28 (UTC)
@Lt2818:不好意思,你上面是不是提到“中文不用斜体,标题也用不着加粗”,但我突然想起有一种情况是要用DISPLAYTITLE对标题的一部分进行斜体操作的,例子不记得了,不过进行斜体操作的那部分不是中文,而是拉丁字母或希腊字母就是了。SANMOSA Σουέζ 2021年6月1日 (二) 09:38 (UTC)
例子已搜索到:N-乙烯基咔唑(S)-2-羟基脂肪酸脱氢酶。若其中的斜体是必需的,则本方案不可行。
我是Lt2818,懒得登录了。--43.129.16.24留言) 2021年6月2日 (三) 09:32 (UTC)
@A2569875:想请教一下意见,究竟这中文名称里头的拉丁字母斜体部分是否必须斜体?SANMOSA Σουέζ 2021年6月2日 (三) 15:19 (UTC)
化学名称台湾这边有些文献有这种写法。至于大陆那边可能要咨询一下@Leiem:-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月2日 (三) 15:49 (UTC)
是需要斜体(两地好像只有用字差异,这种斜体之类的好像都是从英文IUPAC衍生来的)。但生活场合(比如饮料瓶化学添加剂)不用斜体的也能见到。--Leiem留言·签名·维基调查 2021年6月2日 (三) 16:11 (UTC)
@Lt2818:这样的话,我认为不宜占用斜体作为双书名号的位置,因此我先收回公示。SANMOSA Σουέζ 2021年6月3日 (四) 01:02 (UTC)
同意。该功能也可以用模板实现,不过语法上就没这么直观了。--43.129.16.24留言) 2021年6月3日 (四) 08:14 (UTC)
上面的争议足以说明命名常规>书名号,命名一致的理解和立场存在不可调和的根本分歧,以前“通过”所谓方针的共识已经不存在。如果“Lt2818解决方案”的代价是上述方针依然有效,部分用户依然可以用来强迫他人创建条目时加或不加书名号,那么我极力反对。--7留言) 2021年6月1日 (二) 10:16 (UTC)
这是两个不同的提案,我拒绝Jarodalien的故意捆绑行径。SANMOSA Σουέζ 2021年6月1日 (二) 13:00 (UTC)

所以我说那个方案呢?

SanmosaJarodalienSuper Wang安忆YumetoEricliu1912悔晚斋MewaquaAT痛心疾首AnYiLinFglffer驻军Longway22Lt2818瑞丽江的河水JasonHKJarodalien目前建了一大堆有书名号的条目,看起来大家好像都认同应该加书名号...对吧(还是其实是大家都装死)。那么有谁要那些没有书名号的条目移动?Jarodalien大? --Loving You Is A Losing Game 2021年6月1日 (二) 17:34 (UTC)

我自己是不认同,而且现在的情况仍然是没有书名号的条目更多。SANMOSA Σουέζ 2021年6月2日 (三) 00:04 (UTC)
“而且现在的情况仍然是没有书名号的条目更多”是必然,不足以为据…--安忆Talk 2021年6月3日 (四) 04:45 (UTC)
没理由要故意增加工作量(不只是移动的工作量,还有设置书名号转换的工作量)。SANMOSA Σουέζ 2021年6月3日 (四) 06:41 (UTC)
我倾向于支持上文中Super Wang的方案(“介绍书、篇、报纸、刊物、歌曲、戏曲本身的条目名称不带书名号,但在条目内部书名号正常使用;但如果不是介绍该作品本身而是介绍与之相关事物的条目,则条目标题中仍正常使用书名号,此时可以创建不带书名号的重定向,并使用{{书名号重定向}}标记该重定向页”),但如果是“条目标题不加书名号、加书名号的名称予以重定向”我不反对。--悔晚齋臆語) 2021年6月2日 (三) 08:39 (UTC)
我支持预设不加书名号,加书名号者作为重定向,并以小工具或魔术字调整实际显示标题。这样可以兼顾读者搜索方便(而且不必再经过一次重定向),并满足部分维基人对于标题显示格式的要求。—— Eric Liu 创造は生命(留言留名学生会 2021年6月3日 (四) 05:04 (UTC)
容许我重新组织并表达一次自己的意见:考量到移动的工作量与设置书名号转换的工作量,我只支持条目标题不加书名号、加书名号的名称予以重定向的方案。SANMOSA Σουέζ 2021年6月7日 (一) 07:58 (UTC)
这里调整一下我对于修改WP:命名常规#书名号的提案如下:
现行条文

书名号 书、篇、报纸、刊物、歌曲、戏曲的条目名称不带书名号。但在条目内部书名号正常使用。

提议条文

书名号 条目名称中凡出现书、篇、报纸、刊物、歌曲、戏曲等在一般中文行文中使用书名号的名词,无论是否书、篇、报纸、刊物、歌曲、戏曲等的条目本身,在条目名称中均不使用书名号。书、篇、报纸、刊物、歌曲、戏曲等的标题内部本身含书名号者,仅使用标题内部本身所包含的书名号。此条不影响条目正文中书名号的正常使用。就非书、篇、报纸、刊物、歌曲、戏曲等的条目本身的条目而言,此条不影响条目中显示的标题中书名号的使用。

以上。SANMOSA Σουέζ 2021年6月8日 (二) 03:31 (UTC)

(-)反对,所以我上面怎么说来着,呵呵。--7留言) 2021年6月8日 (二) 03:37 (UTC)
然而你并没有考虑书名号转换的处理的工作量,这样对于全体用户与读者而言是极其不负责任的。你从来都没考虑读者真正的需求。SANMOSA Σουέζ 2021年6月8日 (二) 13:22 (UTC)
哇,你真了不起,真厉害,读者编者需求、工作量、全体用户都是你说了算。连他人的思想都清清楚楚,你就是神啊。--7留言) 2021年6月9日 (三) 01:28 (UTC)
请你明白讥讽他人或诱使他人作出不文明行为是不文明行为的一种。而且,我认为这些事情的turnout是很明显可以用至为简单的常识推断的。SANMOSA Σουέζ 2021年6月9日 (三) 03:31 (UTC)
我们大陆这种小地方的人思想上还不够开化,看法还很保守。这话怎么说呢,比如走在大街上,旁边有人跑过碰到我,我一歪结果撞到另一边的人,这时候按照我们这里人的教养,我得向撞到的人赔个不是,情非得已,绝非蓄意。即便对方不爽骂我一句,也只能找前边儿撞我的人算账,绝对没有以“我又不是故意的”、“是他撞我你要骂去骂他”反击的道理。乘车时被挤到结果踩了人的脚、开车时为避让乱跑的小孩碰到别人家栏杆都是一个道理。如果有人不这么做,我们往往会讽刺他一句,比如北京这边儿坐地铁坐公车啦,要是有人踩到别人的脚却不表示歉意,被踩的那位就会主动“道歉”:唉哟对不住您,耽搁您脚捞地了。翻译一下这话意思就是:唉哟我这脚放得还真不是地方,导致您的脚没能直接踩着实地,您原谅我。
对于这两个人,我们这小地方没有谁会觉得被人踩到脚这位不文明、讽刺他人、挑衅,只会觉得另一个人没教养。我本以为这是人之常情,来这里才知道并非如此。比如香港这位每句话必带方针、必然强调文明的方针帝,他直接删掉我提名的GAN连存档都没有,我过好久才意外发现;或是在条目评选页面删除我的留言、投票后,自始至终甚至不需要表达歉意,在我质疑他怎么能这么干的时候,他可以反呛说不要找他,去找设计某个功能的人,拿这种事来说他可以视我为挑衅等等。或者这就是香港的礼仪标准吧,毕竟种族不同,咱也不知道,咱也不敢问。
上面有多少用户明确表示“标题中一定不能用书名号”?书名号如此让人不爽,ACG作品标题里那此千奇百怪的符号怎么办,要是不怎么办那这算什么?标点符号在网址里的技术问题怎么样,大量网站至今不能完善支持带有汉语的网址,维基百科要不要考虑全部用英语标题?上面明确支持“可用”书名号,甚至完全没有强制之意,不愿意加的完全可以不加又有多少位,方针帝他在乎吗?他改来改去最后还是“在条目名称中均不使用书名号”,上面的人听到了吗?你们算什么呀,“很明显可以用至为简单的常识推断”你们“并没有考虑书名号转换的处理的工作量,这样对于全体用户与读者而言是极其不负责任的。你从来都没考虑读者真正的需求”。小心发言,小心他“文明”你哦,至于香港种族会觉得怎么样才算文明、才不算“蓄意破坏社群和谐”、不算“NOTHERE”、WP:GAME、WP:OWN,咱也不知道,咱也不敢问。--7留言) 2021年6月10日 (四) 15:27 (UTC)
容许我搬在FLC的话过来:“这完全和你之前所谓的‘种族’无关,所以我也说清楚好了:以后你的论调但凡再牵扯到所谓的‘种族’,我一概当成无效意见处理,因为即使是和你身处同一所谓的‘种族’,其他人也照样可以和你有不同的意见。”另外,维基百科所真正面向的是读者,因此顾及并考虑读者的需要是应当的。试问真的有人有想过这个问题吗?SANMOSA Σουέζ 2021年6月12日 (六) 01:04 (UTC)
(-)反对 反对在条目名称中禁用书名号的提案。不清楚如何能与“读者的需要”挂钩,未见有数据证明是“读者”而不是个人的需要。 -- I'm Lewix.|有话好说| 2021年6月19日 (六) 16:43 (UTC)

7DAYS的第七次讨论

先前讨论WP:7DAYS的执行有疑义。

该规定实施后,客栈中正等待七天的提案会因为陆陆续续冒出来的支持意见或者一些无关的评论而导致公示时间延后。其中,陆陆续续冒出的支持意见能体现出该提案得到认同,公示期但却因为该规定一延再延;然而没多少人关注留言的提案却能符合7DAYS的规定而进入公示。7DAYS是为了确认共识而设立,虽然共识不是点票,但很明显后一种提案体现的共识没有前一种的强,实际上妨碍了形成共识的认定。而无关的评论造成讨论“续命”更是妨碍提案的正常推动。由于上述原因,本规定的执行力度不是很强,部分提案者会通过引用WP:IAR,以WP:SNOW直接进入公示,不管该提案是否适合 IARSNOW。此外,7DAYS没有对一个月有明晰的认定。据此,我提议修改7DAYS,以规范提案的公示程序

 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月15日 (六) 08:21 (UTC)

  • 目前我想到的是:
    1. 将7DAYS的七天改为“等待期”,等待期过再进入公示期。
    2. 等待期应在提案后第八天及之后宣布开始,为期七天,反对方可以随时停止等待期。
    3. 等待期间的留言建议用模板为引子,看看这些行不行,以明确观点,避免先前讨论对“无新留言”限制的争议。
    4. 若等待期开始后,自除了宣布等待期开始的最后一条留言算起已有7日无新留言(宣布等待期开始之留言不计),则进入公示期。
  • 以上。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年5月15日 (六) 08:31 (UTC)
(-)反对:以前就是因为用户急于公示,强行通过,然后出现很多争议,AT才提出这个WP:7DAYS,目的就是为了收集更多的意见。考虑到不是每个用户那么闲,每天都上维基,所以确保提案能收集足够意见是必须的。而且IAR 不是这样用的,只有现行规则妨碍您贡献维基的时候,才适用于IAR,而提案多放几天对社群有好处,因此不适用于IAR。此外,以前已经有提案由于不依方针规定,急于公示,结果提案通过多天后,仍然有人质疑提案的合法性。--虫虫飞♡♡→♡℃留言 2021年5月15日 (六) 08:45 (UTC)
那七天内没有新留言这个规定的意义是在哪里?--【和平至上】💬 2021年5月15日 (六) 10:51 (UTC)
  • 讨论没新留言,显示共识已经逐步完成,但持续有新留言,而每个意见其实社群都在看,都可能改变对提案的表态。--虫虫飞♡♡→♡℃留言 2021年5月15日 (六) 11:13 (UTC)
  • 倒不如取消7days的特快通道,回复30日讨论期的旧规则。这亦与现实生活中的立法步调较一致。--Temp3600留言) 2021年5月15日 (六) 10:37 (UTC)
  • 方针修订属于重大提案,很多人很忙,未消化提案内容已经通过了,确实不太好。我也觉得七天时间太短,可以改为更长时间,让提案收集更多意见,而且急于通过提案,对社群确实不太好。--虫虫飞♡♡→♡℃留言 2021年5月15日 (六) 11:06 (UTC)
    作为7DAYS的提议者,我稍作说明一下。首先,羊羊提到的无限延期问题在初期讨论时便已经有提及到。根据目前条文,确实存在这样的疑虑,不过由于另有“至少讨论达一个月以上”的条文,因此无论如何延长,当超过一个月的时候便没有影响,也就是说原本的7+7也至少要两周,这仅仅是将两周推迟至一个月而已,这要看到底社群认为哪一类议案应该快速通过,哪一类又需要从长计议。其次,我认为对于考虑如何减轻这类同调或无意义票对形聚共识的影响是有意义的,过去也有过类似的修订案,不过未能取得共识,您提到的等待期方案中用模板标示,我认为是不错的想法,不过可能又加大讨论发起人的负担或变成指控共识过程无效的反证,仍然需要多加讨论。其三,关于和平至上提到的问题,七天内没有新留言的意义在于尽快通过一些较没有争议的提案,同时又确保至少有两周的时间可以知会社群,是用作平衡雪球通过和冗长讨论的对策。最后,Temp3600提到所谓“回复30日讨论期的旧规则”,我认为这是个误解,因为其实本来就不存在所谓30日的明文规定,7DAYS完全后来补上的条文,而并未有修改共识原本的条文,在这之前关于公示日期的长短或是应有的讨论期均没有明确的规定,因此不存在所谓“回复30日讨论期的旧规则。”的可能性。当然,30天的讨论我也是完全没有异议,甚至我最初在考虑此条文也是这种取态,后来吸纳各种意见,才引入您所谓的特快通道的条文。--AT 2021年5月15日 (六) 13:13 (UTC)
  • 原来如此。--Temp3600留言) 2021年5月15日 (六) 16:04 (UTC)
@AT:不好意思,想请你出面说明当初写成“一个月”的时候你是预期“一个月”等同多少天。我个人倾向理解成28天,但之前和现在有部分用户倾向理解成30天。SANMOSA Σουέζ 2021年5月19日 (三) 14:25 (UTC)
30天,不过既然一个月的日数有争议的话,明文化也不是坏事,理论上30天也比28或31要好算,比较倾向支持改成30天。--AT 2021年5月19日 (三) 14:36 (UTC)
支持改为30天。一来30天是加权平均每月天数;二来其他规则都是以30天作为单位来算月(如关注度、不活跃管理员等),与其他规则看齐。--街燈電箱150號 开箱维修 抄表 检验证明 2021年5月19日 (三) 15:30 (UTC)
(如果严格按照格里历或儒略历的话,加权平均每月天数应该是30.436875日或30.4375日,更接近的数字是30.5日才对。)明确成30日也可以。SANMOSA Σουέζ 2021年5月20日 (四) 00:53 (UTC)
(当然是把30.436875直接在小数点四舍五入变整数30天,我想这个场合无什么可能定成小数位吧)--街燈電箱150號 开箱维修 抄表 检验证明 2021年5月20日 (四) 02:20 (UTC)
另外我认为公示期不需要硬性定作7日,有需要的话时长可以调整,以表慎重,故建议改为要求公示期长至少7日(可长于7日、不可短于7日)。SANMOSA Σουέζ 2021年5月20日 (四) 05:16 (UTC)
(-)反对:7天公示期其实已经太短,现在还还要缩短,不要假设每个用户都很闲,不可能几天内就上维基。--虫虫飞♡♡→♡℃留言 2021年5月20日 (四) 11:55 (UTC)
这里应该就没有人说要改短于7天,不知道你在反对什么?依我记忆你已经不是第一次不看清楚别人的发言就胡乱反对,希望你以后提出反对能先至少理解别人的提议。--【和平至上】💬 2021年5月22日 (六) 19:47 (UTC)
“依我记忆你已经不是第一次不看清楚别人的发言就胡乱反对”[来源请求]--虫虫飞♡♡→♡℃留言 2021年5月24日 (一) 13:24 (UTC)
你不是第一个就这一点提醒过他的人。SANMOSA Σουέζ 2021年5月23日 (日) 15:53 (UTC)
  • 您不只一次把人家的性别搞错了,非常不尊重人家!请您保持基本的文明和礼仪。--虫虫飞♡♡→♡℃留言 2021年5月24日 (一) 05:25 (UTC)
    汉语的代词通通不分性别,唯国语书写受西方影响,搞了【他她它祂牠】这些花头出来,其实只用第一个字即可。英文世界现在追求性别中立,专门发明了单数they,不知在translatewiki.net坑了多少翻译者。汉语则没这问题。--Lt2818留言) 2021年5月24日 (一) 12:29 (UTC)
同上,“他”这个字本来就是所有性别通用的(难道你要说早期的白话文作家都不尊重女性?)。“它”、“牠”有时候有机会混用,“祂”基本上是宗教场合才会用,我就不评论了。SANMOSA Σουέζ 2021年5月25日 (二) 01:39 (UTC)
与分案A无关但与原始提案有关的其他内容请勿在分案A标题下讨论。SANMOSA Σουέζ 2021年6月1日 (二) 09:20 (UTC)

分案1

分案1通过。SANMOSA Σουέζ 2021年6月8日 (二) 13:55 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

依照现有的WP:7DAYS,现公示以下对WP:7DAYS的修订(作为分案A)7日:

现行条文

提案讨论及公示时间

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

提议条文

提案讨论及公示时间

为了确保所有用户有充足的时间发表意见以及得悉改动,如果在互助客栈中被提出的提案出现以下情形之一:

  1. 7日内没有新留言
  2. 至少讨论达30日或以上,

该提案只要取得共识便可公示,为期至少7日。公示期间若无异议,则提案算作通过;如果有新意见,请通过协商解决问题。存档后如果要重新提出公示的话,应同时补回相关讨论链接,以便社群查阅。

以上。SANMOSA Σουέζ 2021年6月1日 (二) 09:20 (UTC)

(+)支持:这个修订不错。--虫虫飞♡♡→♡℃留言 2021年6月1日 (二) 23:24 (UTC)

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

其余分案

这里会处理分案1没有处理的提案内容。为免再有人无视不同分案之间的区别,我这里就直接把不同的分案都下一个4级标题,请就个别分案在其所属4级标题下留言,不要留在错的地方,留错地方的麻烦各位协助移回到正确的地方。SANMOSA Σουέζ 2021年6月12日 (六) 14:18 (UTC)

分案2

现行条文

提案讨论及公示时间

为了确保所有用户有充足的时间发表意见以及得悉改动,如果在互助客栈中被提出的提案出现以下情形之一:

  1. 在7日内没有新留言;或
  2. 至少讨论达30日或以上,

该提案只要取得共识便可公示,为期至少7日。公示期间若无异议,提案作通过;如果有新意见,请通过协商解决问题。存档后如果要重新提出公示的话,应同时补回相关讨论链接,以便社群查阅。

提议条文

提案讨论及公示时间

为了确保所有用户有充足的时间发表意见以及得悉改动,如果在互助客栈中被提出的提案出现以下情形之一:

  1. 在7日内新留言;或
  2. 至少讨论达30日或以上,

该提案只要取得共识便可公示,为期至少7日。公示期间若无异议,提案作通过论。公示期间若有新意见,应经协商解决问题。存档后要重公示,应同时补回相关讨论链接,以便社群查阅。

分案2主要是字眼调整,没对意涵作出实际更改。字眼调整的效果是用词更简洁,并避开一个地区词(“通过”在台湾作“透过”)。SANMOSA Σουέζ 2021年6月12日 (六) 14:18 (UTC)

  • @Sanmosa:除了“通过”以外的修改并没有实际意义,并不能优化维基百科,因此(-)反对――user 落花有意12138 2021年6月20日 (日) 08:58 (UTC)

分案3

现行条文

提案讨论及公示时间

为了确保所有用户有充足的时间发表意见以及得悉改动,如果在互助客栈中被提出的提案出现以下情形之一:

  1. 在7日内无新留言;或
  2. 至少讨论达30日或以上,

该提案只要取得共识便可公示,为期至少7日。公示期间若无异议,提案作通过论。公示期间若有新意见,应经协商解决问题。存档后若要重行公示,应同时补回相关讨论链接,以便社群查阅。

提议条文

提案讨论及公示时间

为了确保所有用户有充足的时间发表意见以及得悉改动,如果在互助客栈中被提出的提案出现以下情形之一:

  1. 在7日的等待期[1]内无新留言[2];或
  2. 至少讨论达30日或以上,

该提案只要取得共识便可公示,为期至少7日。公示期间若无异议,提案作通过论。公示期间若有新意见,应经协商解决问题。存档后若要重行公示,应同时补回相关讨论链接,以便社群查阅。

参考资料

这里是依照羊羊32521的提案初衷所提的其中一案,是我依照我的理解能力完全按著羊羊32521的想法来写的(分案3与分案4不能同时实施)。我尽我的能力理解羊羊32521的意思后,得出上面的东西,如有不准确之处,还请羊羊32521直接动手修改。(这里我直接把分案2拿来做对照版本,因为我不认为分案2的字眼调整能出多大的问题,能过的几率很大,而且即使没有过,它的意思也和现在的条文完全一样,因此直接把分案2拿来做对照版本不会产生理解上的问题。)SANMOSA Σουέζ 2021年6月12日 (六) 14:18 (UTC)

(-)反对:把本来很简单的公示程序复杂化,增加不必要的争议。--虫虫飞♡♡→♡℃留言 2021年6月13日 (日) 03:53 (UTC)
请求进一步解释。SANMOSA Σουέζ 2021年6月13日 (日) 04:37 (UTC)

分案4

现行条文

提案讨论及公示时间

为了确保所有用户有充足的时间发表意见以及得悉改动,如果在互助客栈中被提出的提案出现以下情形之一:

  1. 在7日内无新留言;或
  2. 至少讨论达30日或以上,

该提案只要取得共识便可公示,为期至少7日。公示期间若无异议,提案作通过论。公示期间若有新意见,应经协商解决问题。存档后若要重行公示,应同时补回相关讨论链接,以便社群查阅。

提议条文

提案讨论及公示时间

为了确保所有用户有充足的时间发表意见以及得悉改动,如果在互助客栈中被提出的提案出现以下情形之一:

  1. 在7日内无新留言[1];或
  2. 至少讨论达30日或以上,

该提案只要取得共识便可公示,为期至少7日。公示期间若无异议,提案作通过论。公示期间若有新意见,应经协商解决问题。存档后若要重行公示,应同时补回相关讨论链接,以便社群查阅。

参考资料

这里是依照羊羊32521的提案初衷所提的另一案,但并非完全按著羊羊32521的想法来写的,要看完全按著羊羊32521的想法来写的提案请看分案3(分案3与分案4不能同时实施)。这提案参考了之前Wikipedia talk:共识#调适案1的内容,排除把“不对提案进行任何点评的支持意见”和“与提案本身无关的意见”的情形触发重算7日。(这里我直接把分案2拿来做对照版本,因为我不认为分案2的字眼调整能出多大的问题,能过的几率很大,而且即使没有过,它的意思也和现在的条文完全一样,因此直接把分案2拿来做对照版本不会产生理解上的问题。)SANMOSA Σουέζ 2021年6月12日 (六) 14:18 (UTC)

(-)反对:此修订案之前已经被否决过,除了增加争议外,新加的注脚只会增加公示的争议,AT的现行版本较佳。--虫虫飞♡♡→♡℃留言 2021年6月13日 (日) 03:55 (UTC)
请求进一步解释(请检查语病)。另外,提案为常年提案本身不构成反对提案的理由,中文维基百科此前已有常年提案获通过且成事的例子。SANMOSA Σουέζ 2021年6月13日 (日) 04:40 (UTC)

等待期案

  • 提案有点复杂,对于一些新手不容易掌握,而且对于一些具争议性的提案,容易出现是否公示的争议,AT的现行版本较佳。--虫虫飞♡♡→♡℃留言 2021年6月20日 (日) 04:03 (UTC)
  • 确实复杂,建议将不加模板的视为评论,明显是意见的,由他人提醒加模板。
  • @蟲蟲飛:“是否公示的争议”与此提案并无关系,而是公示期带来的――落花有意12138 回复请ping我 2021年6月20日 (日) 09:21 (UTC)
  • “争议”可以是源于用户没用模板发言,那该怎样处理?AT现行版本就已经很好,七天没留言,就公示,完全没有争议,而且简单易明。--虫虫飞♡♡→♡℃留言 2021年6月20日 (日) 09:29 (UTC)

针对WP:小小作品的事实性修订

在条目宽语中,由于正文未及50字,因此被我挂上小小条目的模板。但有其他巡查员认为规范中所写的是“扣除来源脚注等标注”,里面不包含信息框模板,应计入信息框模板的字数。虽然个人觉得把信息框当作正文不合理,但还是有请教其他巡查员的做法,所有人都认为信息框内容不能计入内文之中。且在下方的“小小作品提升管理办法”中提及正文“不包含讯息框的预设字段名称和其他模板本身”,因此认为办法中所叙述的正文不包含模板殆无疑义。但既然有巡查员有此疑义,提议下列事实性修订,并整合“小小作品提升管理办法”:

现行条文

小作品与小小作品的差别

  • 小小作品标准是扣除来源脚注等标注,正文内容只有50字以下过于短小的文章,而小作品事实上已经够长到拥有一些少量的有用信息在里面,通常里面的信息都是大家普遍知道的。对于条目仅包含信息框,而正文部分完全无内容,则不属于小小作品且符合快速删除标准之A2
  • 小作品通常比较容易去扩充,因为它们拥有一些能够让人发展的基本信息,就像一个工匠画的房子蓝图一样,你可以得到一些细节平面图,而小小作品包含的信息非常少,甚至更糟的情况是,那些信息是错误或者会误导别人的,就像你要一个三岁的小孩画房子,你可能会得到一个方块当作房子,而一个三角形当作屋顶。
  • 创建小作品出来的人,通常是希望这篇文章能够被他自己或者是其他真正了解该主题的人继续扩充,创建小小作品的人,通常只是因为他们可以这样做,然后就不再去管它们了。
  • 如果小小作品没有任何和其主题相关的信息,那它可能就是一个胡言乱语,在查询相关的资料确认之后,可以根据标准进行快速删除

示例 ...... 小小作品提升管理办法 本办法的讨论及投票通过过程请参见对话页

  • 管理办法的目的:借由限期提升的方式,将小小作品内容提升而保留,并借由较明确的规定,解决小小作品删除问题产生的争议。
  1. 小小作品的定义:
    1. 正文50个汉字以下:外文字母和数字算半个汉字,不包含讯息框的预设字段名称和其他模板本身。
    2. 必须有起码有用的内容以及适合的条目:(例如xxx是一个中国演员),因此,涂鸦、测试、与主题无关内容或仅有网址链接的等适用快速删除的条目,以及侵权、广告、个人简介、不适当条目等由 删除投票 处理的条目,都不在此办法的处理范围之内。
    3. 有图片即可视为正文10个汉字(但为了避免条目成为图片收集处,图片共只限减10个汉字,亦即有图片只需40个汉字)。
    4. 列明出处资料可视为正文5个汉字。
  2. 任何人可以在小小作品上,加上小小作品限期修改模板,并标上添加模板的日期。(例如{{substub|6|20}}) ,这样该条目会自动列到该月的小小作品分类中。
  3. 在一个月的期限内,任何人可以扩充该条目之后将模板拿掉。如果该条目尚未完整,请改加上各类的小作品模板。(参见category:小作品
  4. 在一个月限期内,未能有人使之至少成为50汉字以上的小作品,则可将该条目提交存废讨论,实际删除与否则由存废讨论决定。

管理方式的相关问题可以到小小作品提升工作小组提出讨论。

提议条文

小作品与小小作品的差别

  • 小小作品是正文内容不及50字以下的短小文章(细节定义请参见定义一节),而小作品事实上已经够长到拥有一些少量的有用信息在里面,通常里面的信息都是大家普遍知道的。对于条目仅包含信息框,而正文部分完全无内容,则不属于小小作品且符合快速删除标准之A2
  • 小作品通常比较容易去扩充,因为它们拥有一些能够让人发展的基本信息,就像一个工匠画的房子蓝图一样,你可以得到一些细节平面图,而小小作品包含的信息非常少,甚至更糟的情况是,那些信息是错误或者会误导别人的,就像你要一个三岁的小孩画房子,你可能会得到一个方块当作房子,而一个三角形当作屋顶。
  • 创建小作品出来的人,通常是希望这篇文章能够被他自己或者是其他真正了解该主题的人继续扩充,创建小小作品的人,通常只是因为他们可以这样做,然后就不再去管它们了。
  • 如果小小作品没有任何和其主题相关的信息,那它可能就是一个胡言乱语,在查询相关的资料确认之后,可以根据标准进行快速删除

示例 ......

小小作品的定义

  1. 正文50个汉字以下:外文字母和数字算半个汉字。包含表格及列表内的文字,不包含讯息框的内容和其他模板本身。
  2. 必须有起码有用的内容以及适合的条目:(例如xxx是一个中国演员),因此,涂鸦、测试、与主题无关内容或仅有网址链接的等适用快速删除的条目,以及侵权、广告、个人简介、不适当条目等由 删除投票 处理的条目,都不在此办法的处理范围之内。
  3. 有图片即可视为正文10个汉字(但为了避免条目成为图片收集处,图片共只限减10个汉字,亦即有图片只需40个汉字)。
  4. 列明出处资料可视为正文5个汉字。

看到小小作品怎么办

  • 任何人可以在小小作品上,加上小小作品限期修改模板,并标上添加模板的日期。(例如{{substub|6|20}}) ,这样该条目会自动列到该月的小小作品分类中。
  • 在一个月的期限内,任何人可以扩充该条目之后将模板拿掉。如果该条目尚未完整,请改加上各类的小作品模板。(参见category:小作品
  • 在一个月限期内,未能有人使之至少成为50汉字以上的小作品,则可将该条目提交存废讨论,实际删除与否则由存废讨论决定。
  • 相关问题可以到小小作品提升工作小组提出讨论。

--Koala0090留言) 2021年5月16日 (日) 03:43 (UTC)

一开始信息框模板的所有内容(包含信息框的预设字段名称)是计算进字数的,是后来才改成不包含信息框的预设字段名称的,所以这提案的实际效果是再进一步收紧条文,详情请参阅过往讨论。信息框的预设字段名称以外的内容并非如其他模板一样是固定的,因此预设字段名称以外的内容是具备百科性的,应该计算进字数里(因为容易写入正文)。不反对重组指引排版格式。SANMOSA Σουέζ 2021年5月16日 (日) 08:35 (UTC)
原文写的是“正文”,信息框模板不管从哪一角度都不应该理解为“正文”,我刚刚爬梳了过往讨论并没有此一共识。--Koala0090留言) 2021年5月16日 (日) 11:07 (UTC)
@Koala0090:请你先看过讨论存档才来说话。SANMOSA Σουέζ 2021年5月17日 (一) 05:44 (UTC)
@和平奮鬥救地球SANMOSA Σουέζ 2021年5月17日 (一) 05:44 (UTC)
过往讨论可以追溯到极为久远的年代,社群从来不认为信息框模板内容是正文。--痛心疾首 2021年5月17日 (一) 05:52 (UTC)
由于原条文似未说明清楚信息框内容是否计入正文,个人(+)支持本提案对于相关标准之厘清。个人认为信息框(Infobox)内的内容不应被计入“正文”。
首先,信息框的内容性质更类似于维基数据,而不是文章叙述,自然不应被视作百科的“正文”。且若条目内仅含信息框,是符合快速删除标准的,可见其与正文之性质仍有不小差异。
再者,我们不如来考虑一种极端状况:一个只有不到十个字(甚至只有五、六个字)的条目,配上一个有40甚至50字以上的信息框。如果将信息框内容计入正文,此类显然过于短小之条目将不符小小作品之定义,个人认为并不合理。
另外,其实现行的Wikipedia:小小作品Special:Permalink/63838536)指引中,有着这么一句话:
从文意中,其实可以理解为信息框内容并不能算是正文,否则上述加粗文字就会产生矛盾(若信息框属于正文,就不会有“有信息框但正文部分完全无内容”这种情况)。
因此,个人认为信息框的内容不应视为正文,并支持本案厘清相关规范。同时,也(+)支持本案对排版的改善。以上。-Peacearth留言) 2021年5月16日 (日) 23:56 (UTC)
wp中表述存在矛盾的相信不止此处,我们更应该探讨本身的意义。在下之前跟阁下提出的如果按您的理解也会产生矛盾。在下认为不应该因为表述上的矛盾来证明观点,而是理清逻辑后修正有问题的表述。--懒癌哪天行Lazy, as no today's excuse. 2021年5月28日 (五) 13:07 (UTC)
以上论述并非以“表述上的矛盾来证明观点”,反而正是在对该指引本身“理清逻辑”、“探讨本身的意义”。您似乎对于本人的论述有些误读。
首先,上面有三项各自独立的论述,当中只有第三个有提及“矛盾”。不宜以偏概全。
再者,该项论述亦非以“表述上的矛盾来证明观点”,您所说的“wp中表述存在矛盾的相信不止此处”更不适用于此。毕竟,当今的状况并非“存在有两段指引互相矛盾”,而是指出“信息框内容计入正文”的假设并不符合现行Wikipedia:小小作品指引的定义。
以上。-Peacearth留言) 2021年6月1日 (二) 00:35 (UTC)
(▲)同上--OceanCove留言) 2021年5月17日 (一) 05:47 (UTC)
本讨论最后发言时间为5月17日,若至5月24日无其他意见便公示7日。---Koala0090留言) 2021年5月21日 (五) 10:24 (UTC)
自即日起公示至5月31日。---Koala0090留言) 2021年5月24日 (一) 17:34 (UTC)
@Koala0090和平奮鬥救地球:不知为何二位未在此讨论中ping在下。在下刚刚看到此讨论,下面发表一下在下的观点。--懒癌哪天行Lazy, as no today's excuse. 2021年5月27日 (四) 08:13 (UTC)
请教高见--Koala0090留言) 2021年5月27日 (四) 12:30 (UTC)
@Lantx:如果未发表意见,我们会按照原定时程完成公示。---Koala0090留言) 2021年5月28日 (五) 11:11 (UTC)
在下最近较忙,不方便发布完整的长篇大论。先引一点在下觉得需要质疑的地方。“小作品事实上已经够长到拥有一些少量的有用信息在里面,通常里面的信息都是大家普遍知道的。”这是指引中的表述,在下认为这是区分小小作品与小作品的明显区别,而infobox中的信息明显是为了提升信息的阅读性而提炼出来的。如各类语言、生物等明显具有层级分类的信息,并不需要在引言中对所有信息长篇大论,用infobox更加清晰明了。如果infobox中的信息也少于50字,则证明的确没有提供一定的有效信息。关于正文的部分,不知您二位是否认为列表、表格等信息是否归属正文,如果归属,请指教与infobox的区别。--懒癌哪天行Lazy, as no today's excuse. 2021年5月28日 (五) 13:04 (UTC)
另外,在下认为如果要修改此指引,当前的讨论参与的人太少了,至少应该知会当前仍然活跃的且之前参与此内容讨论的编辑发表观点。--懒癌哪天行Lazy, as no today's excuse. 2021年5月28日 (五) 13:10 (UTC)
  1. 我不确定就汉语来说,有哪一种理解模式会将信息框模板内的文字视为“内文”或“正文”。
    1. 如果将信息框模板视为正文,那为何仅有信息框但缺乏内文的条目会以A2删除?显见即使是当初该政策的制定者,也完全不认为信息框内文为正文,仅是对于信息框文字的“百科性”给予尊重及鼓励。但个人认为这是极度本末倒置的一种做法,信息框的文字应该是正文的总结,让读者可以快速获取正文的部分信息。根本不应该鼓励仅完成信息框却留空内文的做法,该计算方法会造成巡查员极大的困扰,且可能导致不同巡查员的计算结果不同。
    2. 如果阁下认定infobox内的文字具有百科性,将里面的信息展开成50字以上的文字并不是太过严苛的要求。小小作品的模板从挂上到真正被提删有长达30天的时间可以处理,如果连这样都做不到的话,那只有两个可能:该作者在完成条目之后就不再为该条目的品质负责任,不然就是该条目缺乏扩充价值。
    3. 现行规则有模糊及前后矛盾之处,且显然各编辑的认知不同问题已经造成社群的困扰,对该方针的文字修订势在必行。个人认为阁下所认知的方式会造成认定标准不一的问题。综上所述,我主张维持我的提案。
  2. 根据维基礼仪,我不应该为了增加讨论人数,在没有对方的同意下,任意ping对方,滥用ping功能可以被视为一种骚扰。--Koala0090留言) 2021年5月28日 (五) 17:52 (UTC)
不同意最后一点。或许这样说:我也可以反过来说你不ping知会当前仍然活跃的且之前参与此内容讨论的用户过来发表观点是故意的,而且是为了伪造共识(我个人不相信Koala0090是这样的人,但部分有心的用户确实会有这样的情况,我实在疲于应对)。SANMOSA Σουέζ 2021年5月29日 (六) 06:31 (UTC)
我早在8天前就已在原讨论串告知移步互助客栈讨论,不应该责怪没人提醒他。另外我对于阁下的影射极度不满。--Koala0090留言) 2021年5月29日 (六) 06:57 (UTC)
@Koala0090:在下身为巡查当然认为直接数段落内的自数是容易的,在下想引起注意的一点是,“如各类语言、生物等明显具有层级分类的信息,并不需要在引言中对所有信息长篇大论”,并不会有人在具体某科生物的介绍中从界开始写,但这部分信息会体现在infobox中。如果诸位觉得此类信息可以誊写到“段落”之中来维护50字之小小条目之标准,在下无异议。另,事实上,您在告知时也并未ping在下,同时在下没有收到您消息的提醒。您说ping会造成骚扰,可否去相关人士的讨论页留言邀请呢?不过关于此,目前离题了,在下不想讨论过多。--懒癌哪天行Lazy, as no today's excuse. 2021年5月31日 (一) 15:38 (UTC)
@Lantx:我实在没办法认为50字的要求是长篇大论欸,在者身为一个生物条目写作者之一,我并不觉得生物信息框的设计足够做为理据,反而正可以说明计算困难的问题点。现行的生物分类框分为两大类,一个是自动化分类框,一个是未自动化分类框。自动化分类框仅需填入学名即可自动生成所有分类阶层,未自动化分类框则真的必须自界级分类一路填下来,所以面对这样的差别,所谓的“非预设字段”究竟如何认定?蛋白质信息分类框甚至不需要填入任何信息,可以完全自wikidata撷取信息,这又如何认定?
综上,我主张维持提案--Koala0090留言) 2021年6月2日 (三) 03:24 (UTC)
@Koala0090:在下认为只要在条目的编辑页面有信息而非其索引则可认为是有效的信息,尽管有些是自动生成,但自动生成本质和bot一样,并没有否定其的意义。另外请您不要曲解词语的含义,“长篇大论指滔滔不绝的言论”,而非在字数上的多少,如果infobox中10个字能说明白的意思,为了字数强行凑到50字,在下认为有违维基百科的初衷,而在下在此处所说“长篇大论”是指“人一般指动物界脊索动物门哺乳纲灵长目人科人属中的人”这种将infobox中显然的信息拿过来凑字数的行为。此处请您了解后再来评论。--懒癌哪天行Lazy, as no today's excuse. 2021年6月4日 (五) 05:06 (UTC)
@Lantx
  1. 请勿曲解我的意思,我从来没有否定信息框存在的意义,而是我认为信息框的应该是内文的辅助,信息框中的信息仅是内文的摘要。而且先前和平奋斗救地球和我都已经分别论证过“信息框并非内文”,因此我并没有收紧该规范,而是因为某几次未经深思熟虑的讨论贸然修改规范,造成后来的执行困难,本次提案仅是将文字厘清,并回归最初无争议的规范。
  2. 我没有认为自动生成的信息框不好,而是根据原先的规范根本无法计算。举例来说,CD59的信息框要如何计算?浅盘轴孔珊瑚的信息框又应该如何计算?如果这里面自动生成的讯息可以列入计算,要不要干脆废除小小条目规范算了?
  3. 如果一个写作者会仅因50个字的要求就必须写出“人一般指动物界脊索动物门哺乳纲灵长目人科人属中的人”这种没有营养的语句来凑字数,那是这个写作者的问题,违背违基百科初衷的也是“这个写作者”,而不会是“执行这个规范的人”,请勿本末倒置。--Koala0090留言) 2021年6月4日 (五) 07:27 (UTC)
@Lantx:如果阁下还是不懂,我就用阁下自己的操作来举例,在这个操作中,你认定这篇是小小条目而提出存废讨论,请阁下自己检视自己的思路和标准是否有矛盾之处。--Koala0090留言) 2021年6月4日 (五) 09:32 (UTC)
@Koala0090:抱歉最近没上,刚看到,现在进行回应。
  1. 在下此处提删是因为其存在大量英文内容,此处误会已于提删页面解释清楚。同时在下也认为按照英文字母计字数的规则欠妥,不过没有什么讨论的必要,我保留观点即可。
  2. 我们在谈论的是规则的合理性,任何规则都会有漏洞,我们的讨论时为了尽可能减少漏洞。如果出现问题就说是人的问题,那我们还有必要讨论规则么?
  3. 干脆废除一段在下认为您有滑坡谬误之嫌疑,在下查看了您给出的两个示例,如果按照在下之前所表述的数法是可以给出的,建议您认真阅读。
  4. 关于正文的部分,不知您二位是否认为列表、表格等信息是否归属正文,如果归属,请指教与infobox的区别。在下在之前提出的此问题,并未得到您的回复。
  5. 在下无意与您进行太多的争辩,费心费神。在下只是指出在下理解的当前的规则及执行的方法、背后的原则,提醒您修改后可能造成的影响。如果您认为您修改的影响是可接受并在未来其他矛盾产生时可以给予解释,在下并不反对。请您端正心态,实在不必如此咄咄逼人。--懒癌哪天行Lazy, as no today's excuse. 2021年6月7日 (一) 05:14 (UTC)
@Lantx
    1. 如果一个规则订出来没办法改善任何问题,只会制造更多问题,那就不应该订立。如果这些模板可以计入,那要算几个字?不妨你在公布自己的答案前,自己先找几位巡查员,看能不能给出一个一致的答案,如果不行,那就代表这个规范毫无基准可言。
    2. 此外若蛋白质模板可直接计入正文字数,绝对超过50个字以上。等于说条目正文仅需写一句“XXX是一种蛋白质”即可符合要求,这跟废除小小条目规则有什么两样?
    3. “列表、表格等信息是否归属正文”这是我目前看到唯一有讨论价值的问题。列表大概没有什么问题,在多种文献中,表算是一种正文信息的陈述方式,因此大概可以认定为内文。表格目前实务上是会计入,理由跟列表的原因差不多。真的硬要说跟信息框的差异在于表格缺乏自动生成的问题,且常可以作为内文的表述方式,相对来说信息框具有摘要性。不过这确实是一个好问题,如果之后要修正我会提议计入表格及列表。
    4. 但我倒是反问一句,如果你认为根据现行规范应该计入信息框,那条目底下那些导航模板是否应该计入?如果你认为不应该计入,根据阁下对规范的了解又要怎么自圆其说呢--Koala0090留言) 2021年6月7日 (一) 06:46 (UTC)
@Koala0090:在下生活忙碌,故而回复较慢,之前也跟您表示过歉意,请不要急躁。下面是在下的回复:
1.我之前的操作就是与几位探讨之后的结果,在下原来也持有您当前的意见,但后来被说服,故在此与您阐述清楚。
2.针对您2和4提出的问题,在下认为您还是没有理解我说的内容。我再说一次希望您能够认真理解。如果在代码页面能体现的信息则属于此页面的信息,如果只是引用了模版,则具体内容归属到模版中而非条目。如您所说,信息框中有的信息与其他并无差异(摘要性问题,摘要也算作正文的。另请您不要一再使用“自动生成”这一模糊的表述。代码中有就是有属于条目的信息,代码中没有就是没有条目自身的信息,只是将模版的信息展示了出来。)
3.重申,在下无意争辩。不必一次次的回复一样的内容,这样会使整个讨论停滞不前。
在下本次回复,重新阐述了如何理解以及观点的来源,未来有任何相关信息将不再回复。--懒癌哪天行Lazy, as no today's excuse. 2021年6月12日 (六) 09:17 (UTC)
@Lantx:先感谢您抽空上来回复
  1. 但我不知道四天无回应询问一下这样也叫“急躁”,先前似乎还用兴师问罪的口吻说我没ping你。如果过段时间我没ping你打算推进讨论进度,是不是还会再把你怠于追踪讨论的责任推卸到我头上呢?
  2. 对于脱离文本和条文的解释,没有人有义务理解你怎么想,至少从条文中完全没有办法看出来必须区分什么“非预设字段须计入内文”。或许先前讨论有人提过这块,但完全没有具体呈现在条文中,那就是一个无效的讨论。--Koala0090留言) 2021年6月12日 (六) 09:38 (UTC)
@Koala0090:在下第一段陈述是因为您在五天前ping在下,又在昨天ping在下,您也说过ping会造成骚扰,虽然在下无意认为您骚扰在下,但能表现出您的急躁,在下就是如此使用此词的,如果您认为在下用词不当,可以指出您并不急躁,但请谨记WP:假定善意
既然您是这样的讨论态度,认为在下讲再多您也没有义务理解在下的陈述,那么在下也无需在此与您多费口舌了,您可以随意达成您想要达成的“共识”,没有义务与在下讨论。此案到此为止,在下不会再回复任何内容了。--懒癌哪天行Lazy, as no today's excuse. 2021年6月12日 (六) 09:47 (UTC)
虽然说在维基百科认知混乱的人见多了,但每次交流都还觉得很经典。在那边怪我没ping的也是你,现在又说我ping你是在骚扰。要求人把你家进讨论,当对方善意提醒您一句“是否有其他论述需要补充”时,又恶言相向批评对方急躁。从讨论以来,对我们其他人对原条文提出的质疑不断答非所问,只不断要求对方“看懂你自己怎么想”,一直拒绝讨论条文文本本身透露什么讯息。最后,还是要感谢您的交流,至少我看到最后一段是快乐的。--Koala0090留言) 2021年6月12日 (六) 11:58 (UTC)
阁下的理解能力令人心力交瘁,仅以您此处嘲讽的信息为例,在下已经明确表示过“在下无意认为您骚扰在下。”阁下还以此指摘在下。以友善为原则,在下始终只想提醒您认真阅读一下别人的阐述再来发言,却成为您嘲讽的理由,实在是让人哭笑不得。与您沟通过程中此类情景时常出现,实在不愿再在此与您浪费口舌,但您的指摘恕在下不能不作回应。另,此提案在下保留意见,(-)反对。—懒癌哪天行Lazy, as no today's excuse. 2021年6月17日 (四) 07:07 (UTC)
@Koala0090:我完全无意影射,因为我说的都是之前确确切切发生在我身上的事情。SANMOSA Σουέζ 2021年6月1日 (二) 00:44 (UTC)
  • 支持Koala0090。50字正文其实真的很少,而且现在还有发回草稿的处理方式,小小作品被删的危险性已大减。--Temp3600留言) 2021年6月4日 (五) 11:13 (UTC)
  • 乱入路过的我认为现行条文应继续维持不变。要是有心写的话,50字有何难矣?—An Macanese 2021年6月5日 (六) 16:14 (UTC)
    @An Macanese: 本次提案正是明确化正文50字的要求,若无本次修订则有些巡查员会认为信息框内的字数应当计入。--Koala0090留言) 2021年6月6日 (日) 03:50 (UTC)
    我的狗眼确实是不中用呀!本人的意见是条文应当清晰指出任何信息框的内容都不能作正文论(即在计算50字下限时要把信息框忽略)—An Macanese 2021年6月6日 (日) 11:32 (UTC)
  • @Lantx:是否有其他论述需要补充---Koala0090留言) 2021年6月11日 (五) 07:10 (UTC)
  • (+)支持条文修改以明确信息框内文不包含于条目内文字数计算之规范。50字已是极易达成的门槛,若是连内文都需以数据填充方才得以到达50字,该条目存在之必要性令人存疑。--NHC、才不是NPC呢哼!。:.゚ヽ(*´∀`)ノ゚.:。 2021年6月18日 (五) 10:51 (UTC)

WP:命名常规 (音乐)列为指引

上次没公示到,这边再提交一次。现就这个版本提案公示七天。--Loving You Is A Losing Game 2021年5月26日 (三) 14:44 (UTC)

(+)支持。--痛心疾首留言) 2021年5月26日 (三) 15:38 (UTC)
  • 外文规范的第一条和第六条有什么区别?。->>Vocal&Guitar->>留言 2021年5月26日 (三) 23:59 (UTC)
@Ohtashinichir:这边我替换一下顺序。命名时先处理是否有(常用)中文名称>没有中文名称使用原文称呼>英文、西文等拉丁字母维持其原样(例如Dákiti不会变成Dakiti)。 --Loving You Is A Losing Game 2021年5月27日 (四) 10:30 (UTC)
所以编者完全不允许自译歌曲名称?我主张能译尽可能译。--7留言) 2021年5月27日 (四) 10:44 (UTC)
如果只是原文比中文常用的理由,那我觉得原文也是官方命名,不需要{{notchinesetitle}}。->>Vocal&Guitar->>留言 2021年5月27日 (四) 11:55 (UTC)
@JarodalienOhtashinichiro:关于自译歌曲名称这点方针算中立。例如紫光夜就是自译名,但他常用,所以也是常用名(时间到了自然就是常用名称)。但拥护原文派的也不少,依此使用{{notchinesetitle}}这个折衷方式。虽然还是会被移动,但这句“如果您在可靠来源中找到本主题的中文名称,请勇于将其移动至中文标题。”讲求移动考据,要移动也不容易。另外{{notchinesetitle}}的别名为{{非中文标题}},并非{{官方命名}},只要原文不是中文的条目都适用。 --Loving You Is A Losing Game 2021年5月27日 (四) 13:31 (UTC)
外语歌曲可靠文献采用原名的肯定比译名多,这不过是出版业界长年犯懒。译名的确有时不能“正确”反映原文含义,但再以方针限制我个人认为不妥。翻译理应把读者视为完全不懂外语,尽可能采用汉语,谁犯懒不译歌曲名称也就罢了,但要是谁“不犯懒”,本着尽可能翻译的精神译出来后反而“违反方针”,这就有点莫明其妙。--7留言) 2021年5月27日 (四) 13:40 (UTC)
你先看看“Wikipedia:命名常规 (音乐)#使用中文”章节写的内容,章节开宗明义写到“命名音乐条目时,优先使用最为通用的中文名称命名。”,因此只有在连中文都没有的情况下才会接续到后面使用原文。 --Loving You Is A Losing Game 2021年5月27日 (四) 13:50 (UTC)
我的主张就是“连中文都没有”时,汉语维基百科的编者可以自译,并且这个时候自译不违反方针,不比犯懒保留外语低等,进而不强制移动到外语。说句其实不题外的题外话,你猜《长夜漫漫路迢迢》、《夜未央》、《今天》、《圣战》、《死亡天使》这些文艺作品名称是谁译的?--7留言) 2021年5月27日 (四) 13:59 (UTC)
不是啊,方针没讲不能自译,你为什么会觉得限缩到自译名称?“作品连中文名称都没有”不等于“汉语维基百科的编者不能自译”,自译也不会违反方针。而且阁下写条目到现在,有遇过哪位编辑说不能自译吗?顶多只有不建议吧(Talk:今天 (碎南瓜乐队歌曲))。另外不用我猜,搞自译的那位还写过贝尔要退出哩 --Loving You Is A Losing Game 2021年5月27日 (四) 14:30 (UTC)
我对“或不存在中文翻译名称时,应使用原文名称”这句的理解是“原名高于维基百科编者自译名”。--7留言) 2021年5月27日 (四) 14:56 (UTC)
“或不存在中文翻译名称时”,你要有这个条件产生才会到下一步。 --Loving You Is A Losing Game 2021年5月27日 (四) 15:09 (UTC)
如果“自译名”也算“中文翻译名称”,那这句话完全没意义。没有译自然就是外语,何来“不存在中文翻译名称”之说,所以我认为这句话的意思是:译名如果没有可靠来源支撑就不算数,这就会导致上面说的情况。--7留言) 2021年5月27日 (四) 15:14 (UTC)
那么阁下觉得该怎么写(改善现行方针)会比较好?对我来讲你的担忧就像Wikipedia:命名常规禁止自译一样,可问题是这两个方针长得差不多,只是多了细项,这样你就觉得自译不行会违规? --Loving You Is A Losing Game 2021年5月27日 (四) 16:04 (UTC)
“可用原名”。--7留言) 2021年5月27日 (四) 16:28 (UTC)
看一下这样如何。 --Loving You Is A Losing Game 2021年5月27日 (四) 17:00 (UTC)
还请复查。 --Loving You Is A Losing Game 2021年5月30日 (日) 13:58 (UTC)
觉得可以。--7留言) 2021年5月30日 (日) 14:39 (UTC)
上面这样的情况的话,我建议在版本稳定的时候才公示。先把公示撤下来了。SANMOSA Σουέζ 2021年5月29日 (六) 10:02 (UTC)
建议韩文歌曲命名用文观部式而不是马-赖式,韩文歌曲因为众所周知的原因都是来自南韩,南韩现在已经不用马赖式表记了。不过现在纯拟声词(一般只有这样才无法翻译)做歌曲名字的大多都会有官方英文名吧 囧rz……--🌒-🌖 2021年5月31日 (一) 04:36 (UTC)
EclipsedL已做修改。话说即便是现在,仍有许多韩文歌曲没有官方英文名(例如非流行歌手或是OST,看看那首42字的〈사랑하긴 했었나요 스쳐가는 인연이었나요 짧지 않은 우리 함께했던 시간들이 자꾸 내 마음을 가둬두네'와 장범준의〉)。 --Loving You Is A Losing Game 2021年5月31日 (一) 14:03 (UTC)
Milkypine笑死,那个歌名真的太反人类了。好在没有条目,不过真的要有那也只能硬着头皮翻译了。这种我觉得试试翻一下中文来源吧,没有就自己来算了......--🌒-🌖 2021年5月31日 (一) 14:20 (UTC)
不懂就问,这个歌名怎么了?--Milky·Defer 2021年6月4日 (五) 07:43 (UTC)
就是纯粹长,翻译时一句拉完就很难受......(随便乱译:我们到底是曾经相爱过的关系还是擦肩而过的缘分,(“?”会好点吧)在我们过去那段不短而同在的时间里,你一直将我的心牢牢锁住) 囧rz……--🌒-🌖 2021年6月4日 (五) 16:06 (UTC)
已公示7天,提案通过。 --Loving You Is A Losing Game 2021年6月12日 (六) 12:43 (UTC)
@Milkypine:不好意思,其实你没有走过任何的公示程序(我在5月29日曾经撤下公示)。我可以看在你这个留言相隔再前一个留言已经超过7天的份上当成已经符合WP:7DAYS,从现在开始重新来过一次公示程序。SANMOSA Σουέζ 2021年6月12日 (六) 14:30 (UTC)
@Sanmosa:所以说公示要怎么做?曾经撤下公示是在哪里?Template:Bulletin吗?另外阁下的意思是“我Sanmosa透过撤下他人的公示”来否决他人的提案?这是故意还是不小心啊,用这种方式会不会太超过。 --Loving You Is A Losing Game 2021年6月13日 (日) 03:17 (UTC)
@Milkypine:你要把讨论链接放在{{Bulletin}}的公示字段才算是开始了公示程序(你当初公示的时候,链接也是我帮你放的,所以严格上来说如果我完全不帮你这样做的话,我根本不用撤下公示,因为你根本就没有公示过)。我在5月29日撤下公示时也有在这讨论串留言提醒。SANMOSA Σουέζ 2021年6月13日 (日) 04:35 (UTC)
由于Sanmosa的问题,我这边再现就[维基百科:命名常规 (音乐) - 维基百科,自由的百科全书 (wikipedia.org) 这个版本]提案公示七天。 --Loving You Is A Losing Game 2021年6月13日 (日) 04:21 (UTC)
没有,我留言回复你的时候已经重新开始了公示程序,7日应由2021年6月12日 (六) 14:30 (UTC)开始计算。SANMOSA Σουέζ 2021年6月13日 (日) 04:35 (UTC)

有关节目列表条目

定义

节目列表条目/节目内容表格
分拆自电视或网络节目主条目,收集不同电视(或网络)节目的集数和对应的节目来宾、主题、单元、游戏结果等内容。例:康熙来了节目列表 (2016年)2021年Running Man节目列表翡翠台电视节目列表之类则不在此限。

前言

因为一直以来都没人动手,我最近也开始对一些长期存在问题的条目着手清理。首先被我动手清理的就是台湾的八点档条目(尤其LTA作出的原创研究角色说明),这些清理工作基本上完全对着方针指引去做,争议固然有(哪个爱好者内容条目被清理会没有人反弹),但基本上不难得到其他比较熟悉方针指引的用户支持清理这些内容,好在最近这些条目也开始受控了一点。

下一步,我就打算清除一下囤积“节目列表”的问题。(参阅此笔提删

首先理解一下标题和内容:例如2021年Running Man节目列表,内容为“‘Running Man’的‘节目内容表格’”(不符合列表的定义);翡翠台电视节目列表则可按照内容理解为“‘翡翠台电视节目’的‘列表’”(确实为列表)。前者显然非百科内容,这些节目内容表格并不对节目本身作出任何有效的补充说明或介绍,只是一昧大量收录只有节目粉丝或来宾粉丝才会去查找的节目内容(即爱好者内容),不少长期挂着{{Fanpov}}模板。

管理员关闭存废时提出“符合WP:LISTD(独立列表的存废标准)”作为保留理据,然而我觉得这个保留理据站不住脚。Wikipedia:格式手册/列表定义:“列表是一种用来归纳和列举一类相关主题的页面”,而“独立列表或链接列表,是关于一个领域的主题条目链接的列表,例如人物或者地点的列表,亦包括符合Wikipedia:独立列表的条目。”虽然独立列表并未称为正式格式指引,其内容亦可供参考。当中说到“独立列表条目”的常见选择标准如下:

然而,以上都是在说“独立事物”的列表(例如角色正是独立事物,其关注度可独立于作品本身),但显然节目的集数不会有独立于节目或来宾本身的关注度;亦不同于作品角色在撇除关注度后仍然可创建独立条目(例如在一些爱好者维基上就可以找到独立的条目),节目集数创建不出百科性质的内容。

管理员保留的第二点“没有来源,不是删除理据,见WP:DP#REASON”。不论其是否列表条目,理论上都应当符合可供查证方针,列出相关来源。2021年Running Man节目列表外语版确实有相关来源(不过明显onesource),但基本上大部分其他节目列表条目(尤其为陆港台节目)不会有可靠来源给你每集作报道,只会在少数集数有什么挂的时候才报道,根本就是不可以第二、三手来源查证的内容。WP:DP#REASON同样提到第六项“不可能有可靠来源支持的条目”、第七项“彻底尝试后仍无法由可靠来源查证的条目”、第十四项“任何不适合百科全书〔维基百科〕的内容”(爱好者内容,且有关的每集内容不能创建百科式的内容),且“一个页面通常出于下列原因而需要被删除。请在提删、删除页面前注意:若能改善页面的违规部分,使页面仍有保留价值,务必先考虑改善页面,而非提删、删除页面”,但显然列出的问题在很大程度上没有办法解决。

(第三个关于WP:OR保留理由就当作我理解方针错误,不再补充反驳)

除以上理据以外,亦有删除此等节目列表内容的存废案例(不过当时是嵌入表格而非独立列表条目)。凹呜狼人杀条目原先含有一个极大的节目内容表格(现在在wikia:zh.tw-entertainment:凹呜狼人杀/统计与整理#每集概况的这个列表,注意只是这个章节,其他是后来在维基学院加的),经过2019年8月的此次提删,在经过删除这个列表(当时汇出至维基学院)后才容许保留(后来学院那边也按照WV:ISv:zh:WV:NOT提删了,就再一次搬家到Fandom)。此是否证明此等节目列表条目可以经过提删删除?还是这样的列表条目仅仅分拆就变成适合保留?

我个人不是删除派,我也不希望这些由粉丝摘录的节目内容表格直接删除,个人提出此笔提删时是建议按照{{Fanpov}}的说明:

鉴于提删的条目中有最新年份的不少都挂着{{Fanpov}},故没有在每个条目都挂30天(前面那些挂了也没人看,早已archive了)就直接提删。提删时我是建议在中维删除这些内容,汇出至恰当的外部爱好者维基,并在主条目或导览模板上补上{{Fandom}}或{{Further}}链接指向外部爱好者维基的汇出版,容许保留这些内容给有兴趣的人阅读和记录,又不会使中维出现滥收录的情况。

在此希望征询各位编者对于“此等节目内容表格是否适合保留在维基百科,或是更适合汇出至爱好者维基”的看法。 邀请相关用户:虫虫飞Jimmy13576Gillian14777Donnowin1简浩廷LittletingtingRyusakuraGagenMark85296341Iw1.everything小席TkwongkenROCK8120PhotoyiWeilunlin风魔小翔MikemikekwokMK99992KonaYukiCrashAlmostmanF1W06叶又嘉Tong606GuangzhesunNamgninnurKikasinChinyen LuWangpengda1210Mico121Pv163To91Louis0917PoWaiFungHIMGORPenguin Shido斑点王Joker9Tombus20032000Raymond siuMint2005简小庆Amy051023Case98796ShinwillOnlymyself65536DansonncfYandsam1001FRDian★小郑☆夜来南风起NCTCLINE530MichaelWhite246KingGiangArronwan爱子棋枰A012525wing穆雷夏YFdyh000Dabao qianKOP-SEESana1205OUOIFGANTNLHK

以上,路西法人留言 2021年5月28日 (五) 03:56 (UTC)

讨论

  • (×)删除。->>Vocal&Guitar->>留言 2021年5月28日 (五) 07:06 (UTC)
  • 这些节目列表是否值得保留我认为确实可以商讨。之前我(非管理员关闭)的都是离心力青蛙提删的情况。Itcfangye留言) 2021年5月28日 (五) 11:14 (UTC)
    阁下本身意见如何?--路西法人留言 2021年5月28日 (五) 13:21 (UTC)
Tombus20032000虫虫飞ArronwanDabao qianEclipsedL忒有钱TNLHKPoWaiFungAndychan64夜来南风起Hm 1103再ping一次相关用户。--路西法人留言 2021年5月30日 (日) 14:23 (UTC)
在提删时已提出相关意见。对Running Man节目列表这种浏览量高的条目需要谨慎处理,我个人认为只部分保留特殊集数的做法比全部删除更为糟糕,建议是找人协助创建Fandom或者寻找现有的相关Fandom导入。另外,还是建议按照程序将模板挂满日期吧,开了一次例外就会有第二次,这种行为要不得。—玮玮 · 嘎嘎 · 鲸鱼 2021年5月30日 (日) 16:07 (UTC)
  • 我还是那点,挂{{Fanpov}}和无来源不是提删的理由(否则挂无来源的条目全删了重建好了,快速消费品直接提删)一个条目(列表)应不应该存在与其内容无关,一个有足够关注度的条目也可能存在爱好者内容、原创研究等,但这不代表其可以随意被删除,除非其全文均是原创研究/FAN,但此时即便删除也可以重建(只要符要求即可)。假如说符合LIST的标准,个人认为是符合“2.列表每个项目都不符合关注度标准”这条。因为对于收录而言,节目的每一集都不可能收录,即便来源足够详尽。但前文判例中那个确实可取(转移过度细节内容,保留条目本身,因为之前提删很多条目都是篇幅过大分拆,所以分拆子条目应予保留)。我觉得问题不是条目存废,而是“条目内容”是不是不合标准,那毫无疑问有很多内容就是原创研究、爱好者过度细节,应予删除(转移)。{{Fanpov}}讲的很清楚了,“如条目内有爱好者可能感兴趣而不符维基百科收录标准的内容,可考虑将该等内容移至其他专门描写...的百科或网站,或在不存在相关主题的其他爱好者百科或网站时以相关内容为基础进行构建。”。OK,据此操作,过度细节移动至Fandom/删除,列表仅保留必要内容(放送日期、集数、嘉宾、特殊安排),或是直接合并至主条目。简而言之,该被移去Fandom的内容是不合要求的内容,而非有不合要求内容的条目。条目只要符合LIST标准就应该留下,但需要去除违规内容。一刀切不可取,这无异于手指感染整只手截肢一样。我当时给出的建议是需要全文删除的(×)删除、部分违规的去除违规内容(○)保留(►)重定向至关注度主页面,移动保留内容至主页面。原文移动至Fandom或其他保存处。
PS:下次这种情况还是希望阁下直接来这里讨论方针然后再行提删,否则仓促收尾谁都不满意,还不是得来这里争 囧rz……--🌒-🌖 2021年5月30日 (日) 16:39 (UTC)
补充,总数少于50集的收录在维基百科可能尚算合理,但我不敢认同几百几百集的收录下来的那些是适合维基百科收录。那些每天播的节目每天都记录一个项目会真的过多,即使裁减至只有来宾和日期都还是过量。此外,这裁减过后不就成了节目的索引表了吗?那么跟{{Schedule}}的情况太相似了。--路西法人留言 2021年5月30日 (日) 23:03 (UTC)
综艺剧集收录标准现在对于中文维基还是个空白区,收录标准都还没有吧......至于集数多寡问题,从电视剧角度看《老友记》集数列表这种也能存在,既然季播电视剧可以有节目列表,那么对于综艺剧集的收录是不是也该有个标准?还有真的一天一播的那些综艺不可能有节目列表的,周播十年的综艺集数你一年多就超过了,之前提删的大多是周播吧。至于不符{{Schedule}}的情况我同意,过度删减那还不如不要。我觉得应该另立一个标准,现在这些列表属于一个三不管情况,似乎符合收录标准但内容大多违规,再加大篇幅内容导致不得不分拆,但纵观现在相关条目众多,部分存在大浏览量,以及其他语言特别是en都有相关条目的情况,我提请对此方面采用新的方针。

另外就是那些节目内容,综艺作为一种真人秀不符合虚构作品的标准,自然很难以虚构作品衡量。格式手册里相关方针又没有翻译完。建议可以参考英文版(翻译的弃坑了)衡量。Wikipedia:电视剧集英语Wikipedia:Television episodes。--🌒-🌖 2021年5月31日 (一) 05:13 (UTC)

  • 尴尬...但考虑到习非成是,无论规则是怎样写,我都赞成保留这些列表。要是你能提出fandom/xx百科可以将它们都丢过去,又当别论。--Temp3600留言) 2021年5月30日 (日) 16:53 (UTC)
    现在确实建议鼓励将他们全部丢过去然后加以链接,所以阁下对此意下如何?--路西法人留言 2021年5月30日 (日) 22:27 (UTC)
    你得先找到可以让他们搬家的地方。不能搞强拆。大体同意arrow, 但如果现在才创建FANDOM, 显然来不及。--Temp3600留言) 2021年5月31日 (一) 05:12 (UTC)
    首先我得澄清我不叫arrow(笑)其次同上,有能搬而且确实适合搬的地方那就找办法移动过去,如果没有的话那就先保留着。—玮玮 · 嘎嘎 · 鲸鱼 2021年5月31日 (一) 12:44 (UTC)
    唉呀呀,抱歉打错字了。--Temp3600留言) 2021年5月31日 (一) 13:34 (UTC)
  • 移动的话,大陆的节目可能不太好办(据我所知没有专门收录大陆电视节目的的第三方wiki社区)。--忒有钱🌊塩水あります🐳留言) 2021年5月31日 (一) 14:39 (UTC)
    • 某些特定节目基本上可以单独开一个自己专属的wiki社群了,明侦系列就是一个典型案例,六季数十期节目上百位角色以及大量虚构组织和虚构场景,这样算下来数据量可真不小。--Dabao qian每周五22:00《向往的生活第五季》|每周五20:10《谁是宝藏歌手 2021年5月31日 (一) 17:13 (UTC)
  • 已创建浙江卫视的wiki,可将浙江卫视的节目列表移动至此。--忒有钱🌊塩水あります🐳留言) 2021年6月1日 (二) 07:58 (UTC)
  • @ArronwanDabao qianEclipsedL忒有钱TNLHK:或是另一处理方案:现有内容固然需要清理以达相关标准,起码什么节目内容都得清理一下,并在有适合地方迁移有关内容(或给予三个月至六个月的时间创建合适的外部站点)后搬走并删除维基百科上无法符合方针指引的内容(尤其为无来源内容);同时不鼓励或直接不允许创建新的此类型内容(除非显然地存在充足来源)。这样如何?--路西法人留言 2021年6月6日 (日) 05:04 (UTC)
    (✓)同意(&)建议我觉得搬走后直接留个重定向或链接到移动后的地方更好--TNLHK (Talk) 2021年6月6日 (日) 08:32 (UTC)
    同意,时间上亦刚好可以用今年内为限。可能亦要寻找愿意协助或者有创建外部站点经验的维基人。—玮玮 · 嘎嘎 · 鲸鱼 2021年6月6日 (日) 10:49 (UTC)
  • 我觉得可以。时间的话就限定年内吧。--🌒-🌖 2021年6月6日 (日) 05:09 (UTC)

正式提案

就处理长期违规之节目内容列表,提出以下论述及处理方案以达成共识:

  1. 现有“节目内容列表”(包括但不限于曾于2021年5月20日批量提删的项目、主条目内文之相关嵌入列表等)很大程度存在不符合维基百科(“本站”方针或指引之内容,需要予以清理。相关编者应为相关爱好者内容创建相对应之爱好者维基站点,于2021年12月31日前迁移不符合收录标准(包括但不限于长期或显然不能提供充足来源)的内容(“违规内容”)至对应外部站点,并在本站删除该等违规内容,以{{Further}}或{{Fandom}}模板链接相关站点。
    备注1:迁移之内容应明确标注以符合维基百科之内容使用协议
    备注2:删除违规内容手法包括但不限于对独立条目进行提删、手动删除主条目之嵌入列表或表格等。
    备注3:建议相关编者清理内容后,自行删除本站的违规内容。
  2. 经提醒或警告后仍重复创建已经执行清理和删除的违规内容视作扰乱处理。
  3. 今后禁止创建类似违规内容,但仍然容许创建符合方针指引之同类条目(必须提供充足来源以供查证),新创建违规内容将直接被提删。持续创建违规内容者视作扰乱处理。

以上,并通知参与讨论的用户@OhtashinichiroItcfangyeArronwanEclipsedLTemp3600忒有钱Dabao qianTNLHK。--路西法人留言 2021年6月7日 (一) 01:11 (UTC)

(✓)同意萌娘百科已有部分涉及到的条目的相关内容,就不知维百允不允许在模板里加个到那里的链接了。--TNLHK (Talk) 2021年6月7日 (一) 01:19 (UTC)
此项提案是否涉及方针与指引增改?—— Eric Liu 创造は生命(留言留名学生会 2021年6月7日 (一) 02:38 (UTC)
通过后或会再度提案正式列入WP:IINFO,但此前提为通过此议案,故保留在此。--路西法人留言 2021年6月7日 (一) 05:22 (UTC)
呃不对,有Wikipedia:格式手册/电视可以改。--路西法人留言 2021年6月7日 (一) 05:35 (UTC)
(!)意见:本人在Fandom和Miraheze平台各托管了一个站点,但是一个很现实的问题就在于,因为外部wiki缺少中文维基百科使用的海量模板和JavaScript脚本,所以复制之后显示效果会大打折扣,而且字词转换也不能完美实现(Miraheze还好说,Fandom平台最大的阻碍就在于限制MediaWiki名字空间的自由编辑,导致连{{efn}}系列模板都移植不过去),可能需要本地管理员、行政员、界面管理员或者其他具备相关资质的编者协助处理技术问题。--Dabao qian每周五22:00《向往的生活第五季》|每周五20:10《谁是宝藏歌手 2021年6月7日 (一) 04:18 (UTC)
(~)补充可用“MediaWiki:Custom-”开首的自订MW空间。--路西法人留言 2021年6月8日 (二) 09:47 (UTC)
(✓)同意。现在许多famdom用的也是同一套代码,大概不成问题。另:若相关条目需要全文删除者,建议保留重定向(可能存在大量浏览,相关链至外部站点的外链)可以放在主条目里。--🌒-🌖 2021年6月7日 (一) 04:26 (UTC)
创建重定向者删后重建较佳。--路西法人留言 2021年6月7日 (一) 05:20 (UTC)
(?)疑问如何创建到famdom或其网站的重定向?--TNLHK (Talk) 2021年6月7日 (一) 08:32 (UTC)
是指将原条目重定向到主条目的相关位置,在那里放上外部链接。--🌒-🌖 2021年6月7日 (一) 12:09 (UTC)
强烈反对,在各个语言的维基百科都有类似内容,为何只针对中文内容?如果要删除,是否有需要同时间提案删除全世界所有语言以“节目内容列表”出现的内容?--Hm 1103留言) 2021年6月10日 (四) 00:22 (UTC)
WP:ENWIKISAID反对理由不成立(视作无效反对),中文维基百科不是其他维基百科的中文版,不必然跟随其他维基百科的行事方式。--路西法人留言 2021年6月10日 (四) 01:05 (UTC)

七日内无有效反对意见, 公示7日,2021年6月24日 (四) 00:15 (UTC) 结束。--路西法人留言 2021年6月17日 (四) 00:15 (UTC)

加强封杀内容农场,容许于MediaWiki:Spam-blacklist预防性加入中文农场网址

本部分通过:
通过。--Temp3600留言) 2021年6月12日 (六) 18:14 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

各位好。目前MediaWiki:Spam-blacklist的主要用途是阻止不可靠来源被过度使用或发送垃圾信息。然而,考虑到内容农场近年增长颇快,如等待内容农场已被滥用后再移除,未免费时失事。我建议先发制人,容许在中文内容农场未被加入至维基前,已可以提报至blacklist作出封禁。

(※)注意:内容农场一向都是禁制的,但要小心判断,不要误判,因为有些用户把网媒误判为内容农场,因此禁制前,最好先讨论一下,不要私下未经讨论就把来源放进去。--虫虫飞♡♡→♡℃留言 2021年5月29日 (六) 06:10 (UTC)
  • 日后可以规定加入blacklist前,应该先在Wikipedia:可靠来源/布告板讨论; 但这个要考虑到RSN的处理能力,这次先不提出来好了。更进一步的做法是,分割RSN和内容农场判定版,就像VIP和3RR一样。--Temp3600留言) 2021年5月29日 (六) 06:21 (UTC)
    提案不是很多,一个就够了,分开了会分散社群注意力。--虫虫飞♡♡→♡℃留言 2021年5月29日 (六) 06:55 (UTC)
    用社群最原始的方式处理就好。社群最原始的方式:一旦发现有不妥,直接上客栈ping管理员出来问责。SANMOSA Σουέζ 2021年5月29日 (六) 09:36 (UTC)
  • 本部分依WP:7days,公示七日。暂定的文字版本: "没有在本站出现过的内容农场,亦可加入本名单。"--Temp3600留言) 2021年6月4日 (五) 18:15 (UTC)
@Temp3600:上面的共识是“禁制前,要先讨论”,不是“未经讨论,直接禁制”,因为有些用户误判“网媒”为“内容农场”,请修正!--虫虫飞♡♡→♡℃留言 2021年6月5日 (六) 00:48 (UTC)
好的。 "没有在本站出现过的内容农场,经过讨论后,亦可加入本名单。"--Temp3600留言) 2021年6月5日 (六) 19:20 (UTC)

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

附带讨论: 加快内容农场于RSN的认定程序,无须强制等待7+7天

  • 目前维基百科:可靠来源/布告板/评级指引的7+7日规定,应是为了真正的有争议来源而设,而没有考虑到内容农场一类spam的情形。我建议免除内容农场接受本条的规限,当共识形成后,可直接行动,申请加入spam list。考虑到MediaWiki:Spam-blacklist的EP会再有管理员把关,本项对真正有争议来源应无影响。这项新通道类似CSD,将有助尽快阻挡新生内容农场的入侵。--Temp3600留言) 2021年5月29日 (六) 18:40 (UTC)
  • (※)注意:其实现在对内容农场的操作都是机器人存档后就可以处理,也请注意有些用户可能误判,因此提案放七天等机器人存档后才处理是较审慎的做法。--虫虫飞♡♡→♡℃留言 2021年5月30日 (日) 03:15 (UTC)
  • 说明:由于分类:中国酒下的页面滥用内容农场作为来源,而现行方针下确认内容农场需要时间,导致反垃圾链接力度不足,所以提出该提案。部分内容农场使用不同域名建构内容矩阵,导致一些内容农场来源不易发现,事后查补必然无法查尽。此提案以根据外部内容农场及链接列表,结合常识确认并阻挡内容农场,可有效防止维基新人在不熟悉维基规则的情况下,在无人关注的条目内,误将内容农场作为来源使用的情况。社群当前的反破坏人手足够,使用WP:VIP来识别LTA和纯破坏用户的机制成熟,不经讨论直接提报上述显而易见的破坏行为已有先例,社群注意力也未受影响。如果内容平台存在编辑团采编的内容,加入内容时使用MediaWiki:Spam-whitelist来豁免此来来源。--jingkaimori留言) 2021年6月1日 (二) 09:59 (UTC)
  • (※)注意:提案多放几天没坏,可以收集更多意见,做更审慎的决定,现在RSN的有些内容农场的提案已经被指出是误判,因此不应急于禁制,可以多放几天,收集更多意见。--虫虫飞♡♡→♡℃留言 2021年6月1日 (二) 12:26 (UTC)
  • 如何判定一个网站是内容农场?如何在新兴的纯网媒和确实瞎写滥凑的这种营销号网站之间进行评判?难不成要引入ML机制吗?而内容农场条目里面列举的,似乎也大部分是繁体中文地区的网站,真的要加上的话,加一条“百度百家号一律毙掉”,或许效果会更好。国内大部分内容农场形式的营销号,都是依托百度百家号、大鱼号、搜狐等门户网站的,都是自动爬取微信公众号的内容快乐的老鼠宝宝留言) 2021年6月5日 (六) 00:32 (UTC)
  • 同意禁制“内容农场”,但不能误判,现在的问题是有些用户急于禁制来源,把娱乐杂志之类的网媒,误判为“内容农场”,因此禁制前应先在RSN或客栈讨论,让大家先看一下,不要私下未经讨论就走去禁制网媒。--虫虫飞♡♡→♡℃留言 2021年6月5日 (六) 04:08 (UTC)

WP:封禁方针#管理员注意事项中的“如果你反对某个封禁”一节移动到“解除封禁”一章下并进行修改

现行条文

如果你(作为管理员)反对另一个管理员实施的某个封禁,请与该管理员联系并进行讨论。一般需要以下理由中的一个:

  • 封禁该用户的理由不成立;
  • 封禁该用户的理由已经不存在了。

若该封禁为无限期封禁,反对该封禁的管理员须严谨处理,并先使用所有可行方法通知实施封禁的管理员,包括在其讨论页留言、发电邮和向unblock-zh - at - lists.wikimedia.org邮件列表发邮件。若实施封禁的管理员已离开维基百科,应交由行政员处理。

如果封禁明显错误,封禁管理员又不在线,可以解除封禁。解封前务必通知封禁管理员并在互助客栈其他区说明。明显错误封禁如:封禁理由是违反三回退原则,但该用户明显只回退三次。

提议条文

如果你反对管理员对另一用户做出的某项封禁,请与该管理员联系并讨论,该讨论可以在被封禁用户或该管理员的用户讨论页、互助客栈其他区或其他站内你认为合适的地方。一般需要以下理由中的一个:

  • 封禁理由不成立;
  • 封禁理由已不存在;
  • 封禁时间太长或太短。

如果你不是管理员,可在讨论时请其他管理员复核该封禁,确定是否调整或取消封禁。

若该封禁为无限期封禁,复核该封禁的管理员须严谨处理,并确保先使用所有可行方法通知实施封禁的管理员,包括在其讨论页留言、发电邮和向unblock-zh - at - lists.wikimedia.org邮件列表发邮件。若实施封禁的管理员已离开维基百科,应交由行政员处理。

如果封禁决定明显错误,而实施封禁的管理员又不在线,其他管理员可以解除该封禁。但务必解封之前通知实施封禁的管理员并在互助客栈其他区进行说明。明显错误封禁如:封禁理由是违反三回退原则,但很明显该用户只进行了三次回退。

修改目的:方便非管理员的用户对一些可能错误的封禁提出质疑。--Itcfangye留言) 2021年5月30日 (日) 12:12 (UTC)

(+)支持改成这样应该能减少一些误会--TNLHK (Talk) 2021年5月30日 (日) 12:26 (UTC)
(+)支持。然而“在被封禁用户的讨论页”说“该用户被封禁的时长过短”9成会被删留言(笑),当时曾经提出过禁止被封禁用户在当前申诉章节删留言没能通过。--路西法人留言 2021年5月30日 (日) 14:19 (UTC)
(+)支持。--悔晚齋臆語) 2021年5月30日 (日) 14:59 (UTC)
(+)支持。~~Sid~~ 2021年5月30日 (日) 15:27 (UTC)
看了安忆阁下的话,决定改为中立。~~Sid~~ 2021年6月2日 (三) 13:04 (UTC)
@sidishandsome:安忆针对的是悔晚斋说的“管理员执行封禁应该在有共识的情形下进行”。然而,我的提案里从没有这句文字。我从来说的都是“非管理员的用户可以就管理员的封禁提出复核”,而这正是我前几天在VPO做的。管理员的封禁应当依据方针而非共识。--Itcfangye留言) 2021年6月2日 (三) 13:29 (UTC)
我意识到我修改条文的时候忘记加入“对另一个用户”字样(如果文中的“你”是被封禁者,则只能在其自己的讨论页进行)。Itcfangye留言) 2021年5月30日 (日) 23:07 (UTC)
用户页->用户讨论页。--Xiplus#Talk 2021年5月30日 (日) 23:41 (UTC)
“反对该封禁的管理员须严谨处理”不知是否要修改?--Xiplus#Talk 2021年5月30日 (日) 23:45 (UTC)
已调整文字,反对改成复核。Itcfangye留言) 2021年5月31日 (一) 05:25 (UTC)
原文的“交由行政员处理”读起来比“交行政员处理”感觉要好一点。另外个人认为,如果是明显错误的封禁,没必要一定要在其他区说明(事实上我也不确定是否执行到位),而是在日志/unblock中体现就好。--Hamish with w. 2021年6月1日 (二) 02:04 (UTC)
怪,这个由字怎么不见了……最后一段也可以借机更新。Itcfangye留言) 2021年6月1日 (二) 11:34 (UTC)
(+)支持方便非管理员的用户对一些可能错误的封禁提出申述, 如: Wikipedia:互助客栈/其他/存档/2021年2月#Mys_721tx滥权,任意封禁用户。 --Gluo88留言) 2021年6月1日 (二) 18:52 (UTC)
  • (-)反对我认为处理封禁的司法权为管理员的专属权力。立法分支(互助客栈)不应干涉管理员的判断。--Temp3600留言) 2021年6月2日 (三) 07:31 (UTC)
    我认为管理员执行封禁应该在有共识的情形下进行,应该允许社群进行监督。从管理员的产生到共识的形成、执行,你维更像议行合一体制,而不是三权分立体制。另外,维基百科不是官僚体制。--悔晚齋臆語) 2021年6月2日 (三) 08:44 (UTC)
    我认为“社群监督”是陶片放逐制的不祥先兆。--Temp3600留言) 2021年6月2日 (三) 08:54 (UTC)
    我认为你维管理员权力已经大而不倒了,反而是官僚主义和滥权主义的不详先兆。--悔晚齋臆語) 2021年6月2日 (三) 09:14 (UTC)
    管理员滥权,应该是靠同级的管理员纠正,而不是靠月旦评或者下克上。--Temp3600留言) 2021年6月2日 (三) 09:29 (UTC)
    我知道了,管理员确实很不得了(a big deal),管理员所拥有高于其他用户的特权之一就是纠正其他管理员的错误,社群不应该去纠正、去质疑?管理人,管理魂,管理就是人上人,我们中文维基百科实在是太厉害啦!--悔晚齋臆語) 2021年6月2日 (三) 09:34 (UTC)
    你既然都明说了,那确实就是这样。英维方针直接将a big deal这句话搬到history了。"administrator privileges"就是特权。--Temp3600留言) 2021年6月2日 (三) 09:49 (UTC)
    WP:VPO改为WP:ANM,不知意下如何?--SCP-0000留言) 2021年6月2日 (三) 10:07 (UTC)
  • 一个有趣而不相干的问题。要是有一天我俩被封,某君于VP写大字报"悔晚斋与Temp3600为维基千古罪人,应该永封",而又经WP:7days通过,管理员是否就有义务永封我们?--Temp3600留言) 2021年6月2日 (三) 09:58 (UTC)
    @Temp3600:如果是enwiki,然后提案还真的通过的话,这在enwiki的方针上是获得明文允许的,因为enwiki的方针指明社群自己也有禁制权(而不是像zhwiki一样只有管理员才有),而且enwiki施行的其中一种禁制是全站禁制(其实与封禁无区别),如果全站禁制的期限为永久,那管理员自然会施行永久封禁。zhwiki未来如果照搬这个制度的话,这确实会发生,而且完全符合到时的方针。SANMOSA Σουέζ 2021年6月2日 (三) 14:59 (UTC)
    当然,就zhwiki现在的情况而言,由于Wikipedia:共识#共识的级别有所规定,而且Wikipedia:封禁方针#封禁的用途和目的也指明“所有封禁均用作避免维基百科受到破坏,或减低潜在问题发生的机会”,你说的那种提案是违反方针的,因此抵触Wikipedia:共识#共识的级别的规定,即使走7DAYS程序还是无效。SANMOSA Σουέζ 2021年6月2日 (三) 14:59 (UTC)
  • 另一个相关的问题:社群是否有权利要求公开unblock-zh中的证据,以“查明真相”?如果不容许公开证据,社群何以对相关的封禁案进行全面的讨论?--Temp3600留言) 2021年6月2日 (三) 10:02 (UTC)
(-)反对:用户觉得不合理,可以自己申诉,不用其他人代劳;而且对管理员有意见,应该与管理直接沟通,而不是挂大字报声讨,现在管理员人手已经不足,增加管理员压力,只会令更少管理员愿意做事。--虫虫飞♡♡→♡℃留言 2021年6月2日 (三) 08:30 (UTC)
  • 上面说的都有道理,是理想和现实的碰撞,平权、民主和透明是老生常谈的东西了。悔晚斋说:“管理员执行封禁应该在有共识的情形下进行”,但只是因为“管理员的产生和共识的形成”都在社群之中吗?会不会有点吝啬,吝啬我们的信任。社群当然可以监督,但那应该在管理员作出封禁之后,封禁前和封禁时不需要“社群共识”,因为管理员已经持有社群的信任,并且有着自己的良心,按管理员自己的意志就可以了。封禁后,谁对时长和范围等有异议,再去协商也不迟。即使真的是滥权封禁,那也应该走罢免案,而不是朝着管理员做什么都需要“事先共识”的方向发展。管理员经信任案产生,没有做任何一件事之前都需要再回头等社群对那件事“共识”的必要。我不记得是谁,那位之前也问过我类似的问题,关于信任。我说:“一个管理员有问题还有另一个,管理员不行还有行政员,所有的行政员都不行就意味着社群的失败”,反正轮不到社群,大体是这个意思。Temp3600的假设很有意思,管理员不是单纯的工具人,他们在执行社群共识的同时需要加入自己的判断。不然还要管理员做什么,直接弄一个页面,在上面写社群对某某的处理,大家投个票,由有管理员权限的机器人定期执行就好了。作为心理学者,我只能说“群体”真的很盲目而愚蠢。君要臣死,臣不得不死,可怕。条文有很多,什么不是民主试验场、不是官僚体系,甚至五大支柱云云,但那些懂得人都懂,里面总能找到反驳对方的。维基百科不强迫任何人参与,但总不能都剩下“志同道合”的自己人。但近年来风向如此,只是希望在日后,现在还在的人依然在。简而言之,不要吝啬信任,不要对民主、平等、公正和透明等令人向往的东西太过苛求。--安忆Talk 2021年6月2日 (三) 11:55 (UTC)
  • @悔晚斋安忆Temp3600:我提请各位注意,本提案不是讨论“封禁权”是否为管理员的专属,而是“申诉权”和“意见权”。适用于本提案的情况,大多为管理员误读了方针做出了一个有争议的封禁决定,且被非管理员的用户指出了其中的争议的时候。本提案从来不涉及“封禁前”和“封禁时”这两个问题,只涉及“封禁后”。本提案也不针对明显可以走罢免案的情况。Itcfangye留言) 2021年6月2日 (三) 13:43 (UTC)
    这个简单。申诉权只给被封禁的用户本人,除非申诉通道全关,自己被封不自己申诉别人何必“代为”呢;意见谁都可以提,但最好还是先在个人讨论页,贸然寻求社群介入只会徒增时间成本。--安忆Talk 2021年6月2日 (三) 14:07 (UTC)
(※)注意:不同意管理员的封禁就挂大字报声讨,可以预期所有棘手封禁都没管理员敢去处理。--虫虫飞♡♡→♡℃留言 2021年6月2日 (三) 14:22 (UTC)
  • 安忆健笔论述社群面对的困难,我辈自当有所回应。这儿先简短回应Itcfangye:
    本案的最危险之处,在于社群(可能是经VP的决议?)要求延长封禁时间。换言之,社群可以要求加刑。幸好维基的最高刑罚是永封,而不是死刑;幸好提案方仍然认为提出封禁的权力专属于管理员。不然的话,革命法庭的拘捕-公审-断头台一站式服务,将可在中维遍地开花。
    社群舆论从来都存在,维基用户议论封禁案亦不少见。然而,为何本议案仍会被提出? 可见提案方并不满足于目前的状况,而是期望更进一步,要求管理员处理封禁时,考虑舆论。
    舆论的迅速变化,相信诸位深有体会。不知诸位是否有信心,永远当刽子手,自己却可逃过断头台?
    上面两道趣题,仍待各位回应。unblock-zh的保密条款、方针体系本身、封禁时长的惯例,在互助客栈的公审大会面前,是否不值一提?
  • --Temp3600留言) 2021年6月2日 (三) 14:44 (UTC)
  • 也简短回应一下。 任何方法都有利弊,维基的总的方针是要求在决策实践中使用民主方法, 本提案对阁下提出的两个矛盾好像是不错的平衡,也更符合维基的总的方针
    1. “本案的最危险之处,在于社群(可能是经VP的决议?)要求延长封禁时间。换言之,社群可以要求加刑。幸好维基的最高刑罚是永封“ vs. “管理员错误使用最高刑罚永封,并且忽视社群意见”
    2. “社群舆论…要求管理员处理封禁时,考虑舆论。” v.s. “舆论的迅速变化…自己却可逃过断头台?”
--Gluo88留言) 2021年6月2日 (三) 15:28 (UTC)

分案处理

要不然就分案处理一下好了。我先这样分,见下。SANMOSA Σουέζ 2021年6月2日 (三) 14:43 (UTC)

第一分案
现行条文

如果你(作为管理员)反对另一个管理员实施的某个封禁,请与该管理员联系并进行讨论。一般需要以下理由中的一个:

  • 封禁该用户的理由不成立;
  • 封禁该用户的理由已经不存在了。

若该封禁为无限期封禁,反对该封禁的管理员须严谨处理,并先使用所有可行方法通知实施封禁的管理员,包括在其讨论页留言、发电邮和向unblock-zh - at - lists.wikimedia.org邮件列表发邮件。若实施封禁的管理员已离开维基百科,应交由行政员处理。

如果封禁明显错误,封禁管理员又不在线,可以解除封禁。解封前务必通知封禁管理员并在互助客栈其他区说明。明显错误封禁如:封禁理由是违反三回退原则,但该用户明显只回退三次。

提议条文

如果你反对管理员对另一用户做出的某项封禁,请与该管理员联系并讨论,该讨论可以在被封禁用户或该管理员的用户讨论页、互助客栈其他区或其他站内你认为合适的地方。一般需要以下理由中的一个:

  • 封禁理由不成立;
  • 封禁理由已不存在;
  • 封禁时间太长或太短。

若该封禁为无限期封禁,复核该封禁的管理员须严谨处理,并确保先使用所有可行方法通知实施封禁的管理员,包括在其讨论页留言、发电邮和向unblock-zh - at - lists.wikimedia.org邮件列表发邮件。若实施封禁的管理员已离开维基百科,应交由行政员处理。

如果封禁决定明显错误,而实施封禁的管理员又不在线,其他管理员可以解除该封禁。但务必解封之前通知实施封禁的管理员并在互助客栈其他区进行说明。明显错误封禁如:封禁理由是违反三回退原则,但很明显该用户只进行了三次回退。

第二分案
现行条文

(原始条文)

如果你(作为管理员)反对另一个管理员实施的某个封禁,请与该管理员联系并进行讨论。一般需要以下理由中的一个:

  • 封禁该用户的理由不成立;
  • 封禁该用户的理由已经不存在了。

若该封禁为无限期封禁,反对该封禁的管理员须严谨处理,并先使用所有可行方法通知实施封禁的管理员,包括在其讨论页留言、发电邮和向unblock-zh - at - lists.wikimedia.org邮件列表发邮件。若实施封禁的管理员已离开维基百科,应交由行政员处理。

如果封禁明显错误,封禁管理员又不在线,可以解除封禁。解封前务必通知封禁管理员并在互助客栈其他区说明。明显错误封禁如:封禁理由是违反三回退原则,但该用户明显只回退三次。

提议条文

如果你反对管理员对另一用户做出的某项封禁,请与该管理员联系并讨论,该讨论可以在被封禁用户或该管理员的用户讨论页、互助客栈其他区或其他站内你认为合适的地方。一般需要以下理由中的一个:

  • 封禁理由不成立;
  • 封禁理由已不存在;
  • 封禁时间太长或太短。

如果你不是管理员,可在讨论时请其他管理员复核该封禁,确定是否调整或取消封禁。

若该封禁为无限期封禁,复核该封禁的管理员须严谨处理,并确保先使用所有可行方法通知实施封禁的管理员,包括在其讨论页留言、发电邮和向unblock-zh - at - lists.wikimedia.org邮件列表发邮件。若实施封禁的管理员已离开维基百科,应交由行政员处理。

如果封禁决定明显错误,而实施封禁的管理员又不在线,其他管理员可以解除该封禁。但务必解封之前通知实施封禁的管理员并在互助客栈其他区进行说明。明显错误封禁如:封禁理由是违反三回退原则,但很明显该用户只进行了三次回退。

现行条文

(第一分案条文)

如果你反对管理员对另一用户做出的某项封禁,请与该管理员联系并讨论,该讨论可以在被封禁用户或该管理员的用户讨论页、互助客栈其他区或其他站内你认为合适的地方。一般需要以下理由中的一个:

  • 封禁理由不成立;
  • 封禁理由已不存在;
  • 封禁时间太长或太短。

若该封禁为无限期封禁,复核该封禁的管理员须严谨处理,并确保先使用所有可行方法通知实施封禁的管理员,包括在其讨论页留言、发电邮和向unblock-zh - at - lists.wikimedia.org邮件列表发邮件。若实施封禁的管理员已离开维基百科,应交由行政员处理。

如果封禁决定明显错误,而实施封禁的管理员又不在线,其他管理员可以解除该封禁。但务必解封之前通知实施封禁的管理员并在互助客栈其他区进行说明。明显错误封禁如:封禁理由是违反三回退原则,但很明显该用户只进行了三次回退。

提议条文

如果你反对管理员对另一用户做出的某项封禁,请与该管理员联系并讨论,该讨论可以在被封禁用户或该管理员的用户讨论页、互助客栈其他区或其他站内你认为合适的地方。一般需要以下理由中的一个:

  • 封禁理由不成立;
  • 封禁理由已不存在;
  • 封禁时间太长或太短。

如果你不是管理员,可在讨论时请其他管理员复核该封禁,确定是否调整或取消封禁。

若该封禁为无限期封禁,复核该封禁的管理员须严谨处理,并确保先使用所有可行方法通知实施封禁的管理员,包括在其讨论页留言、发电邮和向unblock-zh - at - lists.wikimedia.org邮件列表发邮件。若实施封禁的管理员已离开维基百科,应交由行政员处理。

如果封禁决定明显错误,而实施封禁的管理员又不在线,其他管理员可以解除该封禁。但务必解封之前通知实施封禁的管理员并在互助客栈其他区进行说明。明显错误封禁如:封禁理由是违反三回退原则,但很明显该用户只进行了三次回退。

以上。整理一下排版(第一分案)还是好的。第一分案和第二分案是分开的,第二分案是原提案,第一分案是单纯的重组排版,请不要混同。SANMOSA Σουέζ 2021年6月2日 (三) 14:43 (UTC)

(-)反对:Temp3600对提案理解得很深入,就是修订案同时可以用来对付一个用户,例如“A因某事被封禁了一天”,然后用户可以提案“A 是千古罪人,应改永封”,提案通过后,管理员就执行共识,永封了A。--虫虫飞♡♡→♡℃留言 2021年6月2日 (三) 14:52 (UTC)
@蟲蟲飛:请容许我理解你的意见为对第二分案(原提案)的反对意见。第一分案和第二分案是分开的,第一分案是单纯的重组排版,没有第二分案(原提案)的效果,意思与原条文一致。SANMOSA Σουέζ 2021年6月2日 (三) 15:08 (UTC)

(+)支持 更多支持理由:

  1. 关于上面所说: “另一个相关的问题:社群是否有权利要求公开unblock-zh中的证据,以“查明真相”?如果不容许公开证据,社群何以对相关的封禁案进行全面的讨论?”, 没有全部证据 是对事实认定, 会有一定影响,社群监督和讨论仍然意义很大。比如虫虫飞 被控傀儡案, 虽然社群看不见全部证据, 社群的讨论和监督 保护了社群 任为是合格的并且有贡献很大的管理员。
  2. 关于:“用户觉得不合理,可以自己申诉,不用其他人代劳”, 涉事管理员的个案处理不公正时,不只是应该被处理的编辑的关心问题, 也是维基社区编辑们关心的工作环境问题, 应该从方针上让非涉事编辑们能见到不公正的处理时,能更便利的正式介入。维基社区中,改善看到的不公正处理,同样是非涉事编辑们义务和愿望,帮助相对弱势的普通编辑也是帮助自己, 能有一个公正的工作环境。 对还不到该提请解聘涉事管理员地步时,目前的方针还没有在非涉事编辑们对处理感到不公平时,其它人正式申述的能成功受理了的方法。
  3. 关于:“而且对管理员有意见,应该与管理直接沟通,而不是挂大字报声讨,现在管理员人手已经不足,增加管理员压力,只会令更少管理员愿意做事。”, 目前的提案式由于多个人使用“与管理直接沟通”渠道效果不理想而提出。 关于“更少管理员愿意做事”, 任何事情都有两面性, 应该让社区讨论来权衡利弊。
  4. 关于是否应该用民主方法:
    • 尽管上面安忆阁下的评论: “上面说的都有道理,是理想和现实的碰撞,平权、民主和透明是老生常谈的东西了…公正和透明等令人向往的东西太过苛求。” 从理论上都有一定道理,指出民主和集权方式都有各自的一些问题。 平衡利弊,维基选择决策实践中使用民主方法, 应该遵守。
    • 由于任何个人的见解都会带有主观性, 很需要多听一听维基人“同一事宜”的各种不同看法。维基讨论论题很难像形式逻辑的命题,可以靠纯粹的逻辑推理解决。而更像政治论题评判,主要靠充分的讨论, 理解双方论点和理由, 然后靠民意的多数。 这是民主式的方法,虽然不能保证一定正确, 但的确能排除很多的不正确的东西。
    • 特别是有关方针的修改,一定应该让社群能进行充分的民主讨论。
  5. 关于: “A因某事被封禁了一天”,然后用户可以提案“A 是千古罪人,应改永封”,提案通过后,管理员就执行共识,永封了A, 本提案没有建议这种方法
    • 请注意,上面Itcfangye已经指出: 本提案不是讨论“封禁权”是否为管理员的专属,而是“申诉权”和“意见权”。
    • 也可以看看: 1. 某 管理员个人主观认为A 是千古罪人,实行永封“ 2. “A因某事被封禁了一天”,然后用户可以提案“A 是千古罪人,应改永封”,提案通过后,管理员就执行共识,永封了A。 比较两者, 在社区监督下进行时,提案通过门槛很高,对被告的保护比 “某管理员个人主观认为 A 是千古罪人,实行永封” 作法好多了。 我也认可上面UT:Sanmosa回答, 本提案作法更符合维基精神。 由于本提案只涉及,“申诉权”和“意见权”,也是对民主和集中一个综合平衡, 很不错的建议。

--Gluo88留言) 2021年6月2日 (三) 16:09 (UTC)

  • 我阅读了一下Temp3600的意见,他担忧的可能更多是我随手加入的“(封禁的时间)过短”二字。我现拟考虑去掉这两字,将“封禁的时间过长或过短”改为“封禁的时间过长”。Itcfangye留言) 2021年6月2日 (三) 16:55 (UTC)
    另外需要注意的是,虽然我的提案是让非管理员用户有更好的申诉和意见渠道,但最终还是需要另一个管理员来推翻原判决(如果需要推翻的话)。Itcfangye留言) 2021年6月2日 (三) 17:00 (UTC)
    • 在下也支持: 1.将“封禁的时间过长或过短”改为“封禁的时间过长”, 2. “但最终还是需要另一个管理员来推翻原判决(如果需要推翻的话)”, 觉得这是一个合理平衡利弊的措施。--Gluo88留言) 2021年6月2日 (三) 17:22 (UTC)
    • 本人意见同Gluo88.本人认为,原案将“封禁的时间过长或过短”改为“封禁的时间过长”之后,就是纯粹的申诉和意见权。--悔晚齋臆語) 2021年6月3日 (四) 03:40 (UTC)
      (-)反对新修订。现行机制是管理员反对某封禁下的流程,但是新修订却改成任何用户均有这样的权利,而且还可以选择任何页面去反对,讨论页也就算了,客栈是要贴大字报吗?客栈已经有够多的冗长提案了,没有空间再赋予一般用户在方针上能够随意声讨管理员的权利。因此,如果一般用户反对某封禁,当然应该先联系实施封禁的管理员,也可以寻求其他管理员的介入。另外,也要知道不是所有用户都有足够的能力或经验去理解管理员的操作,如果容许在客栈等不同页面随意声讨管理员的话,对管理员团队必然造成极大困扰,得不偿失。--AT 2021年6月4日 (五) 15:24 (UTC)
      对阁下回复的意见写在下面。--Gluo88留言) 2021年6月5日 (六) 11:34 (UTC)

2021年6月3日修改的提案版本

将“2021年6月3日修改的提案版本”分段, 便于编辑。--Gluo88留言) 2021年6月5日 (六) 12:24 (UTC)

目前看来参与讨论的绝大多数用户认为“或过短”三字应当去除。去除“或过短”之后,我将合案和分案版本均列在下,同时加入了一些补充内容:

合案版本
现行条文

如果你(作为管理员)反对另一个管理员实施的某个封禁,请与该管理员联系并进行讨论。一般需要以下理由中的一个:

  • 封禁该用户的理由不成立;
  • 封禁该用户的理由已经不存在了。

若该封禁为无限期封禁,反对该封禁的管理员须严谨处理,并先使用所有可行方法通知实施封禁的管理员,包括在其讨论页留言、发电邮和向unblock-zh - at - lists.wikimedia.org邮件列表发邮件。若实施封禁的管理员已离开维基百科,应交由行政员处理。

如果封禁明显错误,封禁管理员又不在线,可以解除封禁。解封前务必通知封禁管理员并在互助客栈其他区说明。明显错误封禁如:封禁理由是违反三回退原则,但该用户明显只回退三次。

提议条文

如果你反对管理员对另一用户做出的某项封禁,请与该管理员联系并讨论,该讨论可以在被封禁用户或该管理员的用户讨论页、互助客栈其他区或其他站内你认为合适的地方。一般需要以下理由中的一个:

  • 封禁理由不成立;
  • 封禁理由已不存在;
  • 封禁时间过长。

如果你不是管理员,可在讨论时请其他管理员复核该封禁,确定是否调整或取消封禁。注意调整或取消封禁的决定必须由管理员做出。

若该封禁为无限期封禁,复核该封禁的管理员须严谨处理,并确保先使用所有可行方法通知实施封禁的管理员,包括在其讨论页留言、发电邮和向unblock-zh - at - lists.wikimedia.org邮件列表发邮件。若实施封禁的管理员已离开维基百科,应交由行政员处理。

如果封禁决定明显错误,而实施封禁的管理员又不在线,其他管理员可以解除该封禁。但务必解封之前通知实施封禁的管理员并在互助客栈其他区或对应日志中进行说明。明显错误封禁如:封禁理由是违反三回退原则,但很明显该用户只进行了三次回退。

分案版本
  • 第一案
现行条文

如果你(作为管理员)反对另一个管理员实施的某个封禁,请与该管理员联系并进行讨论。一般需要以下理由中的一个:

  • 封禁该用户的理由不成立;
  • 封禁该用户的理由已经不存在了。

若该封禁为无限期封禁,反对该封禁的管理员须严谨处理,并先使用所有可行方法通知实施封禁的管理员,包括在其讨论页留言、发电邮和向unblock-zh - at - lists.wikimedia.org邮件列表发邮件。若实施封禁的管理员已离开维基百科,应交由行政员处理。

如果封禁明显错误,封禁管理员又不在线,你可以解除封禁。解封前务必通知封禁管理员并在互助客栈其他区说明。明显错误封禁如:封禁理由是违反三回退原则,但该用户明显只回退三次。

提议条文

如果你(作为管理员)反对另一个管理员实施的某个封禁,请与该管理员联系并讨论,该讨论可以在被封禁用户或该管理员的用户讨论页、互助客栈其他区或其他站内你认为合适的地方。一般需要以下理由中的一个:

  • 封禁理由不成立;
  • 封禁理由已不存在;
  • 封禁时间过长。

若该封禁为无限期封禁,复核该封禁的管理员须严谨处理,并确保先使用所有可行方法通知实施封禁的管理员,包括在其讨论页留言、发电邮和向unblock-zh - at - lists.wikimedia.org邮件列表发邮件。若实施封禁的管理员已离开维基百科,应交由行政员处理。

如果封禁决定明显错误,而实施封禁的管理员又不在线,你可以解除该封禁。但务必解封之前通知实施封禁的管理员并在互助客栈其他区或对应日志中进行说明。明显错误封禁如:封禁理由是违反三回退原则,但很明显该用户只进行了三次回退。

  • 第二案
现行条文

如果你(作为管理员)反对另一个管理员实施的某个封禁,请与该管理员联系并进行讨论。一般需要以下理由中的一个:

  • 封禁该用户的理由不成立;
  • 封禁该用户的理由已经不存在了。

若该封禁为无限期封禁,反对该封禁的管理员须严谨处理,并先使用所有可行方法通知实施封禁的管理员,包括在其讨论页留言、发电邮和向unblock-zh - at - lists.wikimedia.org邮件列表发邮件。若实施封禁的管理员已离开维基百科,应交由行政员处理。

如果封禁明显错误,封禁管理员又不在线,可以解除封禁。解封前务必通知封禁管理员并在互助客栈其他区说明。明显错误封禁如:封禁理由是违反三回退原则,但该用户明显只回退三次。

提议条文

如果你反对管理员对另一用户做出的某项封禁,请与该管理员联系并讨论,该讨论可以在被封禁用户或该管理员的用户讨论页、互助客栈其他区或其他站内你认为合适的地方。一般需要以下理由中的一个:

  • 封禁理由不成立;
  • 封禁理由已不存在;
  • 封禁时间过长。

如果你不是管理员,可在讨论时请其他管理员复核该封禁,确定是否调整或取消封禁。注意调整或取消封禁的决定必须由管理员做出。

若该封禁为无限期封禁,复核该封禁的管理员须严谨处理,并确保先使用所有可行方法通知实施封禁的管理员,包括在其讨论页留言、发电邮和向unblock-zh - at - lists.wikimedia.org邮件列表发邮件。若实施封禁的管理员已离开维基百科,应交由行政员处理。

如果封禁决定明显错误,而实施封禁的管理员又不在线,其他管理员可以解除该封禁。但务必解封之前通知实施封禁的管理员并在互助客栈其他区或对应日志中进行说明。明显错误封禁如:封禁理由是违反三回退原则,但很明显该用户只进行了三次回退。

以上。Itcfangye留言) 2021年6月3日 (四) 04:48 (UTC)

(-)反对:同意上面U:AT的意见,提案不是单纯为了帮其他用户申诉,而是鼓励“贴大字报”声讨管理员,可以预期本来已经人手不足,现在还要令管理员动辄得咎,可以预期更加没有管理员愿意处理棘手封禁。--虫虫飞♡♡→♡℃留言 2021年6月5日 (六) 05:41 (UTC)
认同随意让任何用户贴大字报在各个页面声讨管理员,这会严重影响管理员处理站务的意愿。不过我想这个提案的原因是想适度的开放给一些用户检视管理员的操作是否合适,我认为这是好的。AT阁下说的“不是所有用户都有足够的能力或经验去理解管理员的操作”我非常认同。~~Sid~~ 2021年6月6日 (日) 04:31 (UTC)
目前规定并未有禁止用户检查管理员的操作,实际上检查也是应该的,但这不代表明文规定容许用户可以在任一页面大肆声讨管理员的举动是有意义的,相反一般情况下不应鼓励这种行为,有问题的话大可告知、寻求复核、找其他管理员什么的,单纯声讨是没有意义的,如果要展开解任程序的话那倒又是另一回事。总之,没有任何理由去鼓励用户声讨管理员。--AT 2021年6月6日 (日) 12:57 (UTC)
(+)支持 回复User:虫虫飞U:AT两位阁下的意见:
  1. 大字报和这里提社群正常讨论应该不是一回事, 参见大字报
  2. 精英专制的优点在决策正确时是高效率, 这点是对的。 但是,精英专制决策错误时, 缺陷是:不但难以纠正,而且损害更大(如:纳粹和前苏共), 特别是对弱势群体。
  3. 该提案的提出,是因为多人在现行方法的框架决问题遇到了困难(提案者和在下及其它非管理员编辑,在客栈不同处也交流过这些困难的案例, 包括和两位阁下交流), 才提出仅是略加一点民主(申述权和意见权而已), 平衡一下。
  4. 不知是否能不但指出民主的缺陷(效率低些),也能考虑精英专制决策错误时的缺陷, 对现行方法的框架决问题遇到的困难,提出对保护弱势群体的改进方法。
--Gluo88留言) 2021年6月5日 (六) 11:26 (UTC)
  1. 根据过往经验,往往指名道姓的所谓讨论,大多都不是正常讨论,更多是大字报式的声讨。
  2. 理论上管理员是各自基于方针指引作出判断,而不是集体决定,因此可以互相制衡,而不会出现您所说的情况。
  3. 由于本身没有任何规定限制用户在哪一页面评论管理员的做法,而实际上管理员在客栈被声讨的例子也多不胜数,不过这不代表应该鼓励这种行为,甚至是方针化。
  4. 如果哪一位管理员有错的话,请直接告知其本人或其他管理员,甚至可以考虑提出解任,这与订立方针容许用户抨击管理员的提案不在同一个层面之上,修订也不会产生所谓保护弱势群体的效果。--AT 2021年6月6日 (日) 12:48 (UTC)
  • 谢谢阁下分享看法。想先听听其它人的看法后再回复。
--Gluo88留言) 2021年6月6日 (日) 22:16 (UTC)
  • (先鸽一下,会回来写文章的。)--Temp3600留言) 2021年6月7日 (一) 15:18 (UTC)
  • AT的观点挺好的。--安忆Talk 2021年6月10日 (四) 13:32 (UTC)

分案Alpha

不好意思,我认为有需要再将我的第一分案再分案(我这里叫作分案Alpha好了)。此分案的效果是“你”一字明确为“管理员”,其他意思不变,具体如下:
现行条文

如果你(作为管理员)反对另一个管理员实施的某个封禁,请与该管理员联系并进行讨论。一般需要以下理由中的一个:

  • 封禁该用户的理由不成立;
  • 封禁该用户的理由已不存在

若该封禁为无限期封禁,反对该封禁的管理员须严谨处理,并先使用所有可行方法通知实施封禁的管理员,包括在其讨论页留言、发电邮和向unblock-zh - at - lists.wikimedia.org邮件列表发邮件。若实施封禁的管理员已离开维基百科,应交由行政员处理。

如果封禁明显错误,封禁管理员又不在线,可以解除封禁。解封前务必通知封禁管理员并在互助客栈其他区说明。明显错误封禁如:封禁理由是违反三回退原则,但该用户明显只回退三次。

提议条文

如果管理员(非被封禁者本身)反对另一管理员对某一用户施行的某项封禁,请与该施行封禁的管理员联系并讨论,该讨论可以在被封禁用户的用户讨论页、该施行封禁的管理员的用户讨论页、互助客栈其他区,或其他站内该反对封禁的管理员认为合适的地方。一般需要以下理由中的一个:

  • 封禁理由不成立;
  • 封禁理由已不存在。

若该封禁为无限期封禁,复核该封禁的管理员须严谨处理,并确保先使用所有可行方法通知实施封禁的管理员,包括在其讨论页留言、发电邮和向unblock-zh - at - lists.wikimedia.org邮件列表发邮件。若实施封禁的管理员已离开维基百科,应交由行政员处理。

如果封禁决定明显错误而实施封禁管理员又不在线,其他管理员可以解除该封禁。但务必解封之前通知实施封禁的管理员并在互助客栈其他区进行说明。明显错误封禁如:封禁理由是违反三回退原则,但很明显该用户只进行了三次回退。

以上。SANMOSA Σουέζ 2021年6月10日 (四) 14:07 (UTC)

  • (?)异议:上面u:AT已经说了不要贴大字报,有意见直接在讨论页讨论就好了。条文中的“互助客栈其他区”及“并在互助客栈其他区进行说明。”都应删去,不应鼓励“贴大字报”的不良风气。--虫虫飞♡♡→♡℃留言 2021年6月11日 (五) 13:37 (UTC)
    “如果封禁明显错误,封禁管理员又不在线,你可以解除封禁。解封前务必通知封禁管理员并在互助客栈其他区说明。”/“如果封禁决定明显错误,而实施封禁的管理员又不在线,其他管理员可以解除该封禁。但务必解封之前通知实施封禁的管理员并在互助客栈其他区进行说明。”上面的条文是既有规定,这样做的目的是让社群监察潜在的管理战发生的可能性。在此情形下,不容许解封的管理员在客栈通知实施封禁的管理员是不合理的。@ATSANMOSA Σουέζ 2021年6月12日 (六) 00:54 (UTC)
  • “贴大字报”和“车轮战”没有因果关系,而且就算现行条文有这句,在实际操作时,没有管理员那么无聊解封后,走来客栈“贴大字报”声讨其他管理员,所以无用和有问题的条文应该删去。--虫虫飞♡♡→♡℃留言 2021年6月12日 (六) 01:09 (UTC)
我要求你不要擅自随意揣测AT的意思,我还在等他澄清。SANMOSA Σουέζ 2021年6月12日 (六) 10:52 (UTC)
虽然目前规定是“解封前务必通知封禁管理员并在互助客栈其他区说明。”,但是实际操作上根本没有任何管理员在解封的同时在客栈作出说明,甚至通知实施封禁管理员的情况本身也不多。因此,基于实际情况而言,建基于现行规定的新方案必然地不切合目前的实际情况,如果要作出修订的话,方案应该切合实际情况,例如如果社群确认解封需要作出通知的话,可以建议解封时ping或循任何途径知会实施封禁的管理员之类的,而不是将一些可能已经不合时宜的规定上的处理手法进一步扩大。--AT 2021年6月12日 (六) 12:46 (UTC)
好,我了解你的意思了,我可以基于分案Alpha再提出分案Beta。但是我对于虫虫飞经常随意揣测别人的意思的行径感到非常困扰,我认为别人的意思应该由别人自己解释,望关注。SANMOSA Σουέζ 2021年6月12日 (六) 14:42 (UTC)
sanmosa显然是没有认真阅读留言,才会有这样的误会,请sanmosa重新认真阅读上面的所有留言。--虫虫飞♡♡→♡℃留言 2021年6月13日 (日) 02:23 (UTC)
我认为你这句话留给你自己更为适合。我现在确然感到非常困扰。SANMOSA Σουέζ 2021年6月13日 (日) 04:48 (UTC)
如果您无法举证,请您停止胡乱指责别人。--虫虫飞♡♡→♡℃留言 2021年6月13日 (日) 04:57 (UTC)
但现在我非常困扰的感觉是真实的。SANMOSA Σουέζ 2021年6月15日 (二) 05:45 (UTC)

分案Beta

现行条文

如果你(作为管理员)反对另一个管理员实施的某个封禁,请与该管理员联系并进行讨论。一般需要以下理由中的一个:

  • 封禁该用户的理由不成立;
  • 封禁该用户的理由已不存在

若该封禁为无限期封禁,反对该封禁的管理员须严谨处理,并先使用所有可行方法通知实施封禁的管理员,包括在其讨论页留言、发电邮和向unblock-zh - at - lists.wikimedia.org邮件列表发邮件。若实施封禁的管理员已离开维基百科,应交由行政员处理。

如果封禁明显错误,封禁管理员又不在线,可以解除封禁。解封前务必通知封禁管理员并在互助客栈其他区说明明显错误封禁如:封禁理由是违反三回退原则,但该用户明显只回退三次。

提议条文

如果管理员(非被封禁者本身)反对另一管理员对某一用户施行的某项封禁,请与该施行封禁的管理员联系并讨论,该讨论可以在被封禁用户的用户讨论页、该施行封禁的管理员的用户讨论页或其他站内该反对封禁的管理员认为合适的地方。一般需要以下理由中的一个:

  • 封禁理由不成立;
  • 封禁理由已不存在。

若该封禁为无限期封禁,复核该封禁的管理员须严谨处理,并确保先使用所有可行方法通知实施封禁的管理员,包括在其讨论页留言、发电邮和向unblock-zh - at - lists.wikimedia.org邮件列表发邮件。若实施封禁的管理员已离开维基百科,应交由行政员处理。

如果封禁决定明显错误而实施封禁管理员又不在线,其他管理员可以解除该封禁。但务必解封之前通知实施封禁的管理员。明显错误封禁如:封禁理由是违反三回退原则,但很明显该用户只进行了三次回退。

以上。@AT蟲蟲飛Temp3600SANMOSA Σουέζ 2021年6月12日 (六) 14:42 (UTC)

我认为第一段新加的都是废话,倒数第二段的“反对该封禁”与上文有连续性,这些不用改动。其他修改没意见。--Lt2818留言) 2021年6月12日 (六) 17:03 (UTC)
@Lt2818:我认为两段的内容有些不同:前者是通用程序,只要求有意图尽联系并讨论的义务;后者是不限期封禁专用程序,要求必须联系得到对方。SANMOSA Σουέζ 2021年6月13日 (日) 04:51 (UTC)
我只反对把“反对”改成“复核”;加“确保”没问题。--Lt2818留言) 2021年6月13日 (日) 06:01 (UTC)
(+)支持:同意lt2818君的意见,第一段的“废话”可以删去,第二段很不错,如果把通知封禁管理员也删去则更好,因为您通知封禁管理员,他反对解封,可能令用户获得解封的机会减小了。--虫虫飞♡♡→♡℃留言 2021年6月13日 (日) 00:35 (UTC)
不可把“通知(实施)封禁(的)管理员”删去,原因是避免管理战,并对当初实施封禁的管理员予以尊重。管理战的后果我相信大家也很清楚。另一方面,封禁和解除封禁本身也需要慎重。SANMOSA Σουέζ 2021年6月13日 (日) 04:51 (UTC)
我认为如果要改的话,至少应该考虑改成“解封前或解封后通知实施封禁的管理员”,这样比较切合实际情况。另外,这种情况的前题是“如果封禁决定明显错误”,换言之如果并非明显错误,那是不是代表不用通知?这次修订要考虑的事项其实非常多,例如有没有需要通知或什么情况下需要通知,有需要的话在什么时候通知和怎样通知,这种通知是否具备强制性?当接获通知后如果实施封禁管理员依然主张封禁的话,到时候应该要怎样处理?又或者反过来实施封禁的管理员主动要求其他管理员解封时不用另行通知的情况要如何处理等等,这些都是需要进行深入讨论。--AT 2021年6月13日 (日) 09:05 (UTC)
开一个封禁争议通告版呗,AT所言实际上没人做不代表不应做,懒病不可惯。->>Vocal&Guitar->>留言 2021年6月14日 (一) 09:40 (UTC)
您说得对。--AT 2021年6月15日 (二) 02:59 (UTC)
(?)异议:用户有异议就提封禁申诉,没必要弄一个争议通告版,增加不必要的争议。--虫虫飞♡♡→♡℃留言 2021年6月15日 (二) 13:23 (UTC)

修改WP:编辑禁制方针,新增“解除禁制”一节

原标题为:修改WP:编辑禁制,新增“解除禁制”一节