本页使用了标题或全文手工转换
Semi-protection-shackle.svg

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

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

Breezeicons-apps-48-cantor.svg
发表前请先搜索存档,参考旧讨论中的内容可节省您的时间。
公告板
# 话题 发言 参与 最新发言 最后更新(UTC+8)
1 专题名字空间(第五至六阶段) 80 11 A2569875 2021-07-19 20:42
2 WP:捷径指引草案修订 36 4 羊羊32521 2021-07-20 15:49
3 设计一个制度解决部分速删模板挂不上去的页面的删除问题 92 6 A2569875 2021-07-18 11:19
4 订立影片加入相关指引 35 8 Ericliu1912 2021-06-10 09:00
5 再次推动破坏者(LTA)成为名字空间 43 13 Xiplus 2021-07-17 21:23
6 修改WP:命名常规#书名号 268 28 Milkypine 2021-07-21 23:36
7 针对WP:小小作品的事实性修订 107 16 Koala0090 2021-07-19 22:33
8 修改WP:编辑禁制方针,新增“解除禁制”一节 26 11 Ericliu1912 2021-07-22 17:41
9 设置新的保护类型 94 25 虫虫飞 2021-07-24 18:18
10 修订书籍关注度 38 8 虫虫飞 2021-07-19 12:42
11 1E需澄清是否适用于死者 1 1 Jimmy-bot 2021-07-25 00:14
12 命名常规(方针) § 括号的使用 30 8 Bus Follower 2021-07-17 18:15
13 提议修改关注度_(人物) 14 10 Milkypine 2021-07-21 23:22
14 (续)条目标题、内文及重定向页标题中对SARS-CoV-2的变种的称呼 18 3 Liu116 2021-07-17 10:06
15 关于管理员方针中“避嫌”一节的探讨 1 1 Jimmy-bot 2021-07-25 00:14
16 Wikipedia:格式手册#地区用词的格式(指引) 3 3 落花有意12138 2021-07-23 20:44
17 确立 Wikipedia:字词转换处理为指引 4 3 XComhghall 2021-07-19 00:32
18 确立 Wikipedia:地区词处理为指引 5 4 XComhghall 2021-07-19 00:43
19 关于wp:srcu的讨论 13 6 Itcfangye 2021-07-22 08:21
20 鉴于默杀主义汎滥 提议废除WP:ANM内对未解决提报的自动存档功能 5 3 Sunny00217 2021-07-23 19:26
21 关于针对纯虚构对象免除一手来源的限制的提案 5 3 落花有意12138 2021-07-23 12:46
发言更新图例
  • 最近一小时内
  • 最近一日内
  • 一周内
  • 一个月内
  • 逾一个月
特殊状态
已移动至其他页面
或完成讨论之议题
手动设置
当列表出现异常时,
请先检查设置是否有误

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

[编辑此导航模板]

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

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

各阶段不得同时讨论,前一项讨论完结之后,才能进行下一段讨论。-- ナナチ果物プリン🐰🥭🍮(宇帆·☎️·☘️) 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)

捷径指引修正

依据前次讨论所收集的意见,已在“捷径的命名”段修改成可在字尾使用中文简写。然而其中文字上限多少字仍没有规定,请讨论。台湾杉在此发言 (会客室) 2021年6月25日 (五) 05:23 (UTC)

以上。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年6月30日 (三) 05:51 (UTC)
(+)不反对,所以WP:贵宾室WP:VIP)可以咯 --路西法人留言 2021年7月7日 (三) 13:59 (UTC)
这两种都可以,不过我认为字数硬上限还是要存在,主要理由就是捷径太多字是否还能称作捷径?不无疑问。--台湾杉在此发言 (会客室) 2021年7月9日 (五) 11:43 (UTC)
“捷径尽量不能有成为新的项目页的潜力”其实也没差吧,任何维基人都可以把重定向页改为独立页面。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年7月16日 (五) 15:18 (UTC)
但是这样还要改链入-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年7月20日 (二) 07:49 (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 去问Xiplus 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)


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

技术案阶段二点五:JSON纯文字分类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“自动加入分类”的特殊页面仅有二种JSON纯文字,因此流程可以照走,模板照挂,或许设置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“自动加入分类”的特殊页面有二种JSON纯文字。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月20日 (日) 03:50 (UTC)

修改WP:快速删除方针
现行条文

...(略)...由于技术限制,在JSONFLOW讨论页纯文字放置模板后暂时不会自动被加入分类,因此在提删此类页面时可能还需要另外通知一位管理员来执行删除。

提议条文

...(略)...由于技术限制,在JSONFLOW讨论页纯文字放置模板后暂时不会自动被加入分类,因此在提删此类页面时可一并将请求提报至Wikipedia:特殊页面的快速删除请求,或另外通知一位管理员来执行删除。

以上,请讨论。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月22日 (二) 13:16 (UTC)
所以管理员删除后还得从这个页面移除提报?--Xiplus#Talk 2021年6月25日 (五) 02:13 (UTC)
@Xiplus:像其他提报一样(请求保护页面关注度提报疑似侵权提报管理员注意的用户名等),机器人自动删除“已处理的提报”之模式。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月25日 (五) 03:14 (UTC)
最好先找到人愿意处理。--Xiplus#Talk 2021年6月26日 (六) 03:03 (UTC)
@Xiplus:在有机器人之前也可以手动删除,因为“JSON纯文字”的速删请求应该不多,而其他“大量讯息发送列表CSS已过滤的CSSJavaScriptLuaWikitext等页面”的速删请求本来的Category:快速删除候选就可以处理了,不会需要用到Wikipedia:特殊页面的快速删除请求。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月26日 (六) 05:42 (UTC)
把速删模板或分类挂在讨论页,删除时讨论页也会同时删除,管理员也不需要额外操作(主页面挂模板不变,讨论页仅是为了加入分类)--Xiplus#Talk 2021年6月26日 (六) 06:21 (UTC)
@Xiplus:此案(模板挂讨论页)在#就规范部分特殊页面的删除方式征求社群建议就已经否决了,见存档的Wikipedia_talk:快速删除方针#就规范部分特殊页面的删除方式征求社群建议时戳为“2021年4月25日 (日) 12:34 (UTC) ”的User:虫虫飞留言。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月26日 (六) 07:05 (UTC)
否决原因是因为没有在主页面的历史留记录,但现在保证留记录了啊。--Xiplus#Talk 2021年6月26日 (六) 07:24 (UTC)
我没意见,Ping一下所有参与者[email protected]TranveAntigngSunny00217蟲蟲飛Shizhao霧島聖:想看看其他参与者的想法或意见。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月26日 (六) 09:49 (UTC)

我不是管理员,不好评论。我只能说,既然管理员认为此方案不合适,那么此方案一定有问题。我个人希望管理员能说出解决方案。毕竟本案自始自终要解决的问题都是围绕提请速删的用户和管理员,既然我们用户认为没有问题,接下来就轮到管理员提出自己的意见和建议了。--Tranve () 2021年6月26日 (六) 11:07 (UTC)

  • (:)回应@Tranve:,关于这个,U:Xiplus是管理员,Xiplus觉得在讨论页提删没有问题。他似乎认为{{special wikitext}}解决了挂模板问题,因此主页面必定有模板,解决了虫虫飞的“在讨论页挂模板,而主页面没有模板会陷管理员于不义”问题,因此“在讨论页挂模板案可以实施”。 但我觉得这样“JSON纯文字”的速删请求主页面要挂模板,讨论页也要挂模板,共要挂2次,似乎哪里怪怪的。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月26日 (六) 11:14 (UTC)
案别 说明 来源 条文更改
原条文 新条文
虫虫飞案 维持原案。 2021年5月26日 (三) 06:03 (UTC)的留言
“其实只要在管理员讨论页留句话,管理员已经可以很简单地处理了。”
维持原条文
Tranve案 适用提报页面Wikipedia:特殊页面的快速删除请求处理 2021年6月17日 (四) 11:46 (UTC)的留言
“要不先创建一个Wikipedia:特殊页面的快速删除请求,让 JSON 的速删请求堆到这里来”
...因此在提删此类页面时可能还需要另外通知一位管理员来执行删除... ...因此在提删此类页面时可一并将请求提报至Wikipedia:特殊页面的快速删除请求,或另外通知一位管理员来执行删除...
Xiplus案 同时在欲删页和讨论页挂提删模板 2021年6月26日 (六) 06:21 (UTC)的留言
“把速删模板或分类挂在讨论页,删除时讨论页也会同时删除,管理员也不需要额外操作(主页面挂模板不变,讨论页仅是为了加入分类)”
...因此在提删此类页面时可能还需要另外通知一位管理员来执行删除... ...因此在提删此类页面时需要确保欲提删的主页面与其讨论页均挂上速删模板,以令页面分类运作,让管理员来执行删除...
A2569875案 设立O9快速删除规则,在相关页面提及要删除的页面,管理员要删除当中提到的删除目标页和O9页面。(才可以处理FLOW讨论页 设立O9快速删除规则-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年7月4日 (日) 13:44 (UTC) ...因此在提删此类页面时可能还需要另外通知一位管理员来执行删除... ...因此在提删此类页面时除了欲提删的主页面要提删模板外,可在与欲提删相关的页面(如讨论页)挂上CSD#O9,以令页面分类运作,让管理员来执行删除...
O8. 在伪名字空间中创建的非重定向页。 O8. 在伪名字空间中创建的非重定向页。
O9. 用于提删不支援页面分类之页面的相关页面。
由于技术限制,在JSON纯文字放置模板后暂时不会自动被加入分类,因此在提删这类页面时可于其相关页面(如讨论页)挂上此款快速删除模板,让管理员在删除目标页面时此页页一同被删除。
Sunny00217案 用机器人定期扫描JSON纯文字分类BUG的删除候选,整理到某页(目前没有找到要编写此机器人的维基人。) 2021年6月20日 (日) 01:21 (UTC)的留言
“那就是要监视进期更改扫描把他扫出来?”
维持原条文
以上,请讨论。Ping一下所有参与者[email protected]TranveAntigngSunny00217蟲蟲飛Shizhao霧島聖Xiplus:想看看其他参与者的想法或意见。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年7月4日 (日) 13:44 (UTC)
其实我那个可以是算基于Tranve的(也就是扫到Wikipedia:特殊页面的快速删除请求),只是一个是提删者要自己加,一个是由BOT扫-- Sunny00217  2021年7月4日 (日) 14:38 (UTC)
结构式讨论(无论是讨论页本身或是话题Topic)明明就会进分类啊,谁说不会进分类的。--Xiplus#Talk 2021年7月5日 (一) 03:38 (UTC)
已修正。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年7月5日 (一) 06:01 (UTC)
虫虫飞案
  • 老实说我觉得去催公单比起其他方案好-- Sunny00217  2021年7月14日 (三) 03:06 (UTC)
    • (※)注意此留言与虫虫飞案矛盾。一是,如果推行让json 支持分类,代表根本不会再需要“找一个管理员来删除”,反而需要驳回本案。二是,就算推行了,仍无法适用于纯文字内容模型。 此外 恕我直言,目前phab:T235798的实作有很大的潜在问题,我认为其代码需要重写,然而目前没人重写,故我不认为应该对该工单抱持着“短时间有办法部署”的期望。 —- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年7月14日 (三) 03:22 (UTC)
Tranve案
  • (+)支持,认为讨论页提删模式还会有不必要的创建条目的操作,会增加创建条目被删除的记录。故不是很支持Xiplus案。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年7月14日 (三) 02:30 (UTC)
Xiplus案
A2569875案
Sunny00217案
讨论区

技术案阶段三: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年5月5日 (三) 09:15 (UTC)意见,预留此节。-- 五岁抬☎️·☘️) 2021年5月5日 (三) 09:19 (UTC)
  • 预计会在上两案(提删申请、删后复检)完成技术支援布署后,开放本区收集反馈意见。—- 五岁抬☎️·☘️) 2021年5月8日 (六) 17:52 (UTC)
    • 接收到的反馈1(于WP:TG):预览、和已删页面看不到题删模板;页面历史版本题删模板与页面历史版本内容不匹配
      解决方案:已提出#技术案阶段二:页面预览功能,并商讨全站布署
    • 接收到的反馈2:小BUG:语言调成非中文会无法显示模板
      解决方案:已解决
    • 接收到的反馈3:未有
    -- 五岁抬☎️·☘️) 2021年5月10日 (一) 05:29 (UTC)
    • 我想问一下,显示出来的模板不能简繁转换是预期行为吗?--Tranve () 2021年5月11日 (二) 13:02 (UTC)
      • (:)回应@Tranve:本案以界面文字实现。界面文字本身不支援自动繁简转换-{}-。因此仅能修改你想要放置在特殊页面的对应模板,用{{lan}}实现-- 五岁抬☎️·☘️) 2021年5月11日 (二) 13:13 (UTC)
    提删受保护页面该怎么处理?--Xiplus#Talk 2021年7月17日 (六) 13:20 (UTC)
    @Xiplus:本案处理的都是“可编辑”的页面,因此“本来就无法编辑”的页面原本就不在本案考量的范围内。受保护页面要能够被编辑留下删除模板,可能只能编辑请求,请求有编辑权限的人挂来模板。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年7月17日 (六) 13:27 (UTC)
    假设是全保护的话,管理员是否可以直接删除页面,如果是的话,那么主页面没有留下历史则与本案问题相同。--Xiplus#Talk 2021年7月18日 (日) 01:57 (UTC)
    @Xiplus:不认为一样,因为本案解决的是“模板显示问题”,受保护页面根本无法编辑,何来“显示问题”?本案解决的是已经贴上模板源代码却无法显示,受保护页面连模板源代码都贴不上去,对于不存在的东西,“怎么显示”?建议受保护页面提删的部分提一个新提案处理。本讨论已经又臭又长,大部分有参与讨论的维基人ping了又ping、ping了又ping就是不愿来回应,合理的解释是WP:太长不看,没人讨论根本无法达成共识,建议与json/txt一起另提新案。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年7月18日 (日) 03:19 (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)
如果扩展有希望,也许可以试看看。—- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年7月7日 (三) 07:01 (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)
(?)疑问意思是,启用的机会提高了?—- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月27日 (日) 16:06 (UTC)
DreamerBlue君是担心说,不是基金会开发的,有坏掉的风险。后来他发现作者是WMF的,所以可能没有这层考虑了。启用应该还是要走下面提到的mw:Writing an extension for deployment#Preparing for deployment……(但是首先得有社区共识)-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年6月30日 (三) 05:35 (UTC)
或许可以公示看看?—- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年7月14日 (三) 05:48 (UTC)
不启用扩展就没有设立名字空间的必要性。--Xiplus#Talk 2021年7月17日 (六) 13:23 (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语法,需要最新的浏览器才能显示正确效果(实际应用时应扩写以实现兼容)。保存时会提示错误,忽略即可。

(7月5日更新:由于存在斜体的使用场景,改用<cite>标签表示双书名号。)

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

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

:is(#firstHeading, #section_0) b::before,
:is(#firstHeading, #section_0) :is(cite, b) :is(cite, b):lang(zh-Hans)::before {
	content: "〈";
}
:is(#firstHeading, #section_0) b::after,
:is(#firstHeading, #section_0) :is(cite, b) :is(cite, 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)
我建议使用<cite>元素替代一般斜体标记书名,毕竟元素做出来就是干这个的。——Artoria2e5 讨论要完整回复请用ping 2021年7月4日 (日) 16:15 (UTC)
@Artoria2e5:刚刚用<cite>元素替换了原先<i>元素的使用场景,此为测试用例。--Lt2818留言) 2021年7月5日 (一) 01:33 (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)
我不懂为什么这东西大家还可以吵这么久没有定论,是各位都想看当天使用书名号?一句话要还是不要用,这到底有什么难的,“反对在条目名称中禁用书名号的提案”所以你是支持吗?如果不是,那干嘛不表明支持使用书名号。 --Loving You Is A Losing Game 2021年6月22日 (二) 12:52 (UTC)
  1. 你问我为什么说“反对在条目名称中禁用书名号的提案”?提案就是禁用书名号啊,这叫切题。
  2. “禁用书名号”,“可以使用书名号”,“必须使用书名号”这是三个选项,不太清楚阁下为什么一定要非此即彼?去掉一个错误答案?[开玩笑的]
  3. 我也很奇怪这么简单的东西为什么要吵这么久没有定论。上面都有调查了至少一部分人认同可以用书名号,为什么还会有认为个人的想法就是“顾及并考虑读者的需要”?诉诸群众请看一下? -- I'm Lewix.|I'm sorry for your loss.| 2021年6月25日 (五) 12:39 (UTC)
以我个人而言反对“禁用书名号”还是没有解决“要不要使用书名号”这根本问题,反对禁用到底解决了什么?而照目前留言看下来,说要使用的都没有“大家都该使用书名号”的担当,仿佛表示我爽用就用不爽用就不用。当然这是过度解读,但各位不想禁用后该如何打算?是考虑统一使用还是希望看到有书名号和没书名号条目林立的混乱场面。 --Loving You Is A Losing Game 2021年6月25日 (五) 13:36 (UTC)
问题是"条目林立的混乱场面"也只是你自己的想象而已,我个人极其厌恶条目名和标题名不一致的情形,那我是不是更有理由可以说“XXXX的混乱情形”?
其次,我本来就没有“必须使用书名号”的立场,为何要把我不认的“担当”塞进来?
而且,已经有那么多先到先得了,多这一个也不多。
最后,可用可不用也是一种一致性,就算有不一致,这也是外部标准不同造成的不一致,而非技术要求或技术限制,我不觉得强制要求一致有任何意义。 -- I'm Lewix.|I'm sorry for your loss.| 2021年6月25日 (五) 19:30 (UTC)
(1、2)到时候维护问题的烂摊子,恐怕你们还是随手一摊、直接抛给管理员处理,完全管也不管,而且你还要考虑到书名号本身在显示上有时候还要再转换一次。我的理解是处理后续维护问题的烂摊子就是Milkypine所说的“担当”。(2、3、4)方针不支持你的看法,因此没办法先到先得。现在的情况是只能统一为一种样式。SANMOSA Σουέζ 2021年6月28日 (一) 10:46 (UTC)
其实说白了就是你们看书名号在条目名里不爽而已,你也不是管理员,为何非得说什么“维护问题的烂摊子”、“条目林立的混乱场面”、“读者的需要”,拿大帽子扣人?如果认为“可用可不用”,保持现状,那么何来的维护问题?而且阁下一直做着自行解读方针的事,就说“命名一致性”,在Wikipedia:命名常规里,“命名一致性”是一个三级标题,上面的二级标题是“技术要求”,请问有任何技术要求或技术限制不能用书名号吗?能不能用书名号,根本就不适用于“技术要求”这一条。 -- I'm Lewix.|I'm sorry for your loss.| 2021年6月28日 (一) 12:42 (UTC)
@lewix:先不提哪里可以看出我不爽,就保持现状方面,不使用书名号才是保持现状吧(至少回顾Jarodalien创立大量含有书名号的维基条目前)。“"条目林立的混乱场面"也只是你自己的想象而已”,Category:电影获奖与提名列表如果是我的想像,我会轻松许多,但是并没有= =。 --Loving You Is A Losing Game 2021年6月28日 (一) 12:54 (UTC)
保持现状是指“不禁用书名号”。而对于Category:电影获奖与提名列表,恕我不能体会阁下的感受。 -- I'm Lewix.|I'm sorry for your loss.| 2021年6月28日 (一) 13:18 (UTC)
你的解读是有争议的。上面不止一个人认为现状是标题禁止使用书名号。SANMOSA Σουέζ 2021年6月29日 (二) 01:44 (UTC)
书名号本身在显示上有时候还要再转换一次,这里已经有维护问题了,因为有些时候书名号要转换成引号,有些时候书名号要转换成另一种书名号,有些时候书名号不转换,同时书名号的使用就已经出现3种不同的情况,而且你还要逐个条目去看和设置书名号转换,这里难道你还可以说“没有维护问题”吗?我说的事情其实是非常现实的。我不相信任何人能把所有页面(包括但不限于条目)的标题的书名号转换都能设置妥当。SANMOSA Σουέζ 2021年6月29日 (二) 01:48 (UTC)
现状就是“没有禁止”,上面多数人都认同这一点,不然你的提案改方针做什么用的?
而且你怎么把“书名号显示”扯进来了,不管条目名禁与不禁书名号,你说的情况都存在。你的提案对此没有任何帮助。 -- I'm Lewix.|I'm sorry for your loss.| 2021年6月29日 (二) 02:08 (UTC)
容许我追加说明:(1)我不认为多数人认同这一点。(2)现在的情况是容许标题存在书名号,而在容许标题存在书名号的情况下,社群却忽略如何让书名号正确显示,这样就会产生地域中心问题,然而社群完全无心考虑在容许标题存在书名号以后如何处理因标题存在书名号而产生的地域显示差异问题,这样是变相地鼓励地域中心,对来自其他地域的编者和读者造成不友善。如果标题完全不存在书名号,那即使没有另外特别处理标题,由于标题本来就没有书名号,因此也不存在处理书名号的问题,自然也不会衍生更多的地域中心问题。SANMOSA Σουέζ 2021年7月7日 (三) 05:27 (UTC)
你的提案是禁用一个东西,这已经是直接鼓励地域中心。如果你认为存在“书名号正确显示”的问题,则不管条目名禁与不禁书名号都存在该问题,那么请专注于显示的问题。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月7日 (三) 06:27 (UTC)
“你的提案是禁用一个东西,这已经是直接鼓励地域中心”是什么逻辑?另:标题中书名号不正确显示的问题是由容许标题存在书名号的情况产生的,因此如果容许标题存在书名号,则须连带处理标题中书名号不正确显示的问题,否则会造成日后维护困难;然而上方有个别用户明显是在罔顾日后的维护困难和地域中心问题,这并非维基百科社群协作的应有态度。SANMOSA Σουέζ 2021年7月9日 (五) 03:53 (UTC)
逻辑即是你试图禁用的东西是某个地域的标准,上方已经有用户做充分阐述。
很简单的逻辑:“条目名”中若无书名号,不通过其他技术手段,则标题中必然无法显示书名号,更遑论“正确显示”?莫非阁下想赞成“条目名中必须包含书名号”的观点? -- I'm Lewix.|I'm sorry for your loss.| 2021年7月9日 (五) 04:11 (UTC)

Wikipedia:命名常规#书名号修改公示

最近我注意到前管理员、资深编辑长夜无风的留言。这一留言充分表明,Sanmosa同志的根本不具备中文标点符号的基本常识。鉴于:Sanmosa提出的相关指引案显然不具备任何可操作性,本讨论中多为Sanmosa一案的反对者,对Sanmosa的相关观点予以了充分反驳,并充分参考讨论中出现的所有意见,考虑到现有社群共识并非在标题中禁止使用书名号,根据WP:7DAYS,现将上文中Super Wang的草案 公示7日

现行条文

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

提议条文

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

以上。--悔晚齋臆語) 2021年7月2日 (五) 05:53 (UTC)

  • (-)反对:社群不反对在条目标题中使用书名号,跟支持在标题中一定要使用书名号是两回事。现在对于书名号问题社群实务上是实行先到先得原则,如果不能就选择一种格式达成共识的话,那还不如维持现状。—— Eric Liu 创造は生命(留言留名学生会LEP 2021年7月2日 (五) 07:43 (UTC)
  • (!)意见:啊这个{{书名号重定向}}是谁? --Loving You Is A Losing Game 2021年7月2日 (五) 09:37 (UTC)
  • 我认为既然因为政治正确需要简繁不分家,那么别的族群怎么做我们管不着,咱们大陆人还是要容许不同族群的语言习惯,把“应用”改为“可用”就行。另外我期望能够从实际效果层面确保不同族群的汉语版本(即中文版本)彻底分离,比如我编辑正文时就专门编辑noteTA下的zh-cn项,至于zh-tw、zh-hk这些外语我缺乏了解,就由使用这些语言的族群编写,如果没有人编辑,那么这些语言的显示留空。全文从头到尾都这么写,默认选择显示zh-cn的,如果zh-cn项无人编辑,则条目内容为空,其他各项也一样。不同语种间的内容不需要有任何联系,比如zh-cn项如果是电影明星传记,zh-hk项完全可以是体育比赛,zh-tw项可以是党派争端。如果技术上难以实现,可以使用手动模式,比如zh-cn:《肖申克的救赎》是1994年的美国剧情片;zh-hk:留空;zh-tw:民进党发言人表示,此次老妇摔掉大牙事件彰显国民党不管百姓死活,并提醒大家不要忘记几个月前自民党高层身陷黑金政治丑闻;zh-sg:留空……--7留言) 2021年7月2日 (五) 14:58 (UTC)
    • 先不吐槽楼上提这种大家反对的提案。光是一个条目被这样搞,你觉得你的电脑可以一次应付这种超占空间的编辑方式吗?334,920字节的清朝条目编辑起来对电脑都有一定要求了,这大小*2是打算让内存危机降临吗? --Loving You Is A Losing Game 2021年7月2日 (五) 16:50 (UTC)
    • 为什么您动不动就要“咱们大陆人”,你是谁啊能代表全大陆的维基人,那请你开除我的中国国籍?而且根本没有人在提强国,反倒是你自己一直上升到种族问题还贼喊捉贼--Austin Zhang留言) 2021年7月3日 (六) 22:17 (UTC)
  • (!)意见 “则条目标题中仍正常使用书名号”,改成“则条目名称中仍可使用书名号”。标题显示成什么样子是另外的主题,建议转Wikipedia:互助客栈/技术。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月2日 (五) 23:02 (UTC)
  • (-)反对刀剑神域角色列表要改成“《刀剑神域》角色列表”了。--Mewaqua留言) 2021年7月3日 (六) 01:25 (UTC)
鉴于上方存在对Super Wang案的明确合理反对意见,现依WP:7DAYS的“如果有新意见,请通过协商解决问题”条中止对Super Wang案的公示的程序。SANMOSA Σουέζ 2021年7月3日 (六) 03:49 (UTC)
Facepalm3.svg 捂脸你们开心就好。--💐1.2 mil Articles🎉J2068🛫PEK-GYD🛬via URC???🤦‍ 2021年7月6日 (二) 22:54 (UTC)
我请所有到现在还在主张标题可以存在书名号的人回应上方所有对容许标题存在书名号的反对观点。如果没有任何合理的回应的话,我只能够假定上面的反对意见都是不合理的,因为我一直以来只看到多部复读机不断在复读,而从未有真正地就事论事。SANMOSA Σουέζ 2021年7月7日 (三) 05:31 (UTC)
不知道是他的表达有问题还是你的阅读理解有问题。反正他是给你撑腰的。。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月7日 (三) 06:15 (UTC)
  1. 开头的总结很对:“本讨论中多为Sanmosa一案的反对者,对Sanmosa的相关观点予以了充分反驳,并充分参考讨论中出现的所有意见,考虑到现有社群共识并非在标题中禁止使用书名号
  2. 上一节里我的意见也没见你们回应,你们就视而不见了?
  3. “多部复读机不断在复读,而从未有真正地就事论事”? 你在说楼上某反对意见吗?
  4. 之所以不回,情绪化的输出总结下来就是一条“我看书名号不爽” 这叫合理的反对意见?
  5. 你不适合对该主题做总结,你已经很根深蒂固地存有某个观点了,希望在这个话题里你可以做论述,但总结请其他人来做,你麻烦回避。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月7日 (三) 06:15 (UTC)
  • 并不是对书名号不爽,是认为“文件名称、档案名称没有必要包含标点符号”,条目内部名称就类似于其文件名。如何证明我不是对书名号不爽,可以从《五十九种二十面体》看到,我主编这条目时不是就有好好地使用书名号的了吗?我觉得内文中包含书名号是重要且必须的。—- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年7月7日 (三) 06:33 (UTC)
  • 如果你们认为上方太情绪化,那我冷静下来重新说明总行了吧。
  1. 储存条目时的内部名称有书名号会影响排序
  2. 储存条目时的标题有书名号会影响条目汇整工作
  3. 导航模板或一些特定的条目链接应尽量使用直接链接而非重定向链接。若储存条目时的内部名称有书名号输入将会十分不便,只少我手机还要安装额外的输入法才能处理
  4. 不反对“条目显示出了包含书名号”但反对条目储存时的内部名称有书名号
  5. 不使用温尼尔《多面体模型》列表是因为温尼尔多面体模型列表想要强调温尼尔学者提出的多面体模型,而不想强调他是书,但是那个规范导致无法这样命名
  6. 不认为动漫角色列表需要故意再加上书名号,多此一举
  7. 同理,科学书籍或论文研究的相关标题,加上书名号是多此一举
  8. WorldEdit (我的世界模块)依照上方规定要变成变成“WorldEdit (《我的世界》模块)”,恕我直言,这样套娃括号,很影响观感;例2:血小板 (工作细胞)变成血小板 (《工作细胞》)实在多余。
— [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年7月7日 (三) 05:53 (UTC)
这才有可以讨论的基础
你们要禁用某个东西,请提供一些更紧急,更强,而不得不这么做的理由。2,4,5,6,7,8 总结下来还是“不符合我的习惯,我看书名号不爽”. 1.影响什么“排序”?按照汉字排序也没有任何意义。DEFAULTSORT请用起来。3.请用重定向。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月7日 (三) 06:15 (UTC)
并非“看书名号不爽”,我写条目时还是会用书名号,但认为条目内部名称就如文件名一般,一般文件命名应该也不会有书名号吧,文件打开再显示书名号不是很棒吗?为什么连文件名内部都“必需”包含书名号呢?我不理解,能否请详细说明吗?。—- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年7月7日 (三) 06:24 (UTC)
  1. 消除歧义。看这些条目名吧:她获奖名单4月3周又2天获奖与提名列表从前,有个好莱坞获奖与提名列表 房间获奖列表 年轻的维多利亚获奖名单 地心引力获奖列表 小妇人获奖与提名列表 小丑获奖与提名列表。还有楼上的例子“《对〈关于...〉和〈关于...〉的意见》的社会影响”,不加分隔符的话完全不可读。
  2. 上面已经提过的:《标点符号用法》(GB/T 15834-2011)#4.15.3 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月7日 (三) 06:39 (UTC)
我同意上方条目需要,但也有不放书名号不影响阅读且没有歧义的案例,例如温尼尔《多面体模型》列表,不加书名号时还能彰显列表的主题(多面体模型)与该等模型的提出者。因此我主张“内部名称/文件名”有歧义时再使用书名号、无歧义“内部名称/文件名”中之书名号可选择省略。—- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年7月7日 (三) 06:45 (UTC)
你的主张有一个问题是没有一个简单的标准来判定“有歧义”。既然已经有部分条目名需要书名号分割了,那么推广到“可以使用”应该是没有任何障碍的。
而且你说的例子“温尼尔《多面体模型》列表”恰巧是有问题的,“多面体模型”是“温尼尔”提出?这些模型都是自然存在的,他只是将其归类编号吧? -- I'm Lewix.|I'm sorry for your loss.| 2021年7月7日 (三) 07:07 (UTC)
或许我举的例子不好,确实学术上的多面体模型与《多面体模型》不同,没有书名号的多面体模型是几何模型,所指之物确实自然存在,有书名号的《多面体模型》是学者温尼尔的著作,当中确实仅列了该学者对特定自然存在的多面体模型的描述与归类编号,因此,此例还是需要书名号做区别。虽然这个例子不好,但我还是认为会有不必加书名号的案例存在。有的必须要加并不代表“所有的”都必须要加。不认同“所有的”都必须要加。我的主张并不是要“禁用”他,而是主张不要“滥用”他。条目内文全部都要加书名号我是(+)支持,条目显示出来必需要有书名号我也是(+)支持的,我(-)反对的是强制所有“非内文”场合都“必需”使用书名号的规定。同时习惯上我写条目,条目的“内文”我习惯上“都会使用”书名号,根本没有“看书名号不爽”这回事。而且我写条目“内文”全部“都会使用”书名号,因此也没有“使用习惯不符”一说,建议不要断章取义。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年7月8日 (四) 12:05 (UTC)
情绪化的输出总结下来就是一条“我看书名号不爽,是谁?你才是那个情绪化的人吧,直接将反对意见打成情绪化,无理取闹也该有个限度吧。你无法体会Category:电影获奖与提名列表的混乱感,并不代表他不混乱。同样地,她获奖名单4月3周又2天获奖与提名列表作为条目名称有辨识问题,那《她》获奖名单《4月3周又2天》获奖与提名列表会不会有搜索问题,毕竟“到底有多少人会在搜索时打书名号”(甚至都没有人敢说自己搜索时会打书名号),要验证大概跟没有书名号造成的辨识问题一样,除非你给出具体数据、民调或任何佐证的资料,你有资料甚至是勇敢说出我都用书名号搜索,我肯定支持。没有?那就不要求,采用先得先到,看大家喜欢哪个就用哪个。 --Loving You Is A Losing Game 2021年7月8日 (四) 15:42 (UTC)
你跟你楼上不看他人的观点就巴拉巴拉说一大堆,有意思咩?我何时说过“必需使用书名号”?
Category:电影获奖与提名列表,转述一下,不就是你看着这个分类里的书名号觉得混乱觉得不爽?别人非得要和你有相同的感受?
“搜索问题”?提案里给出了解决方法啊,你们倒是给出“辨识”“歧义”的解决办法来啊。
“无理取闹”?我上面一节和这一节说了这么多“理”,就见到你们拿一点两点说事,可曾见到你们全部的回应?
你们如果要禁用某个东西,请提供一些更紧急,更强的理由。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月8日 (四) 16:55 (UTC)
  • (:)回应就算你没有说“必需使用书名号”,或者“必需使用书名号”不是你说的,但是目前提案的新增条文“......而是介绍与之相关事物的条目,则条目标题中仍正常使用书名号......”,不就是摆明了要“必需使用书名号”?条目内文全部都要加书名号我是(+)支持,条目显示出来必需要有书名号我也是(+)支持的,我(-)反对的是强制所有“非内文”场合都“必需”使用书名号的规定。强制“必需使用书名号”,基本就是“不分青红皂白地将书名号塞好塞满”,然而这并不妥当,标点符号是辅助文字记录语言的符号,是书面语的组成部分,用来表示停顿、语气以及词语的性质和作用,标点符号应当适度使用,不是越多越好,过度使用是不好的。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年7月9日 (五) 02:02 (UTC)
  • (:)回应“...你们如果要禁用某个东西...”我哪时候说我要禁用书名号了,我都说了我的生活习惯上使用书名号,同时习惯上我写条目,条目的“内文”我习惯上“都会使用”书名号,根本没有“看书名号不爽”这回事。而且我写条目“内文”全部“都会使用”书名号,这样的观点被你说成我想要“禁用”书名号?,建议不要断章取义。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年7月9日 (五) 02:05 (UTC)
  • 我的观点很明确,一开始就说了:“则条目标题中仍正常使用书名号”,改成“则条目名称中仍可使用书名号”。。 Anyway,既然你不寻求禁用书名号,我向你道歉。下意识里我被情绪化的输出误导以及被人挑拨了,我把你的观点和别人的混同了。。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月9日 (五) 03:06 (UTC)
    • 我也很抱歉,我一开始用了较激烈的表达方式,一度造成双方误会。如果是这样的话,我(+)倾向支持你的观点(即“条目名称中仍可使用书名号”的提案)。((※)注意仍对现行提案“则条目标题中仍正常使用书名号”意义为“强制需要不分青红皂白地全面滥用使用书名号”一事持(-)反对立场)。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年7月9日 (五) 05:59 (UTC)
  • 回头看了一下,一不小心还是中招,被人挑拨了。既然同意“先到先得”,那么就此打住吧。关闭再提一个提案。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月8日 (四) 17:02 (UTC)
    • @lewix:技术上来讲“先到先得”只是我对上述意见的心得感想,保险一点是认证各位是不是支持,不然最后还是白忙一场。 --Loving You Is A Losing Game 2021年7月21日 (三) 15:36 (UTC)

关于上方结合DISPLAYTITLE和CSS的方案的一个想法

我个人是支持这个(三级标题所述的)方案的。上面的讨论中提到不宜占用斜体标记的问题因而无果。这里我想说两句。

由于在中文维基百科,DISPLAYTITLE支持嵌入HTML标签,不限于b和i。所以以下代码是完全可行的,不会显示出html标签,同时于解析器输出结果中包含该标签:

{{DISPLAYTITLE:<span class=doublebookbracket>几何原本</span>}}

此外,DISPLAYTITLE当中是可以使用模版的。因此我认为使用模版为标题中需要书名号的部分添加span标记,再配合CSS就可以解决斜体或粗体与其他用法冲突的问题。此外,通过加class的手段,CSS脚本可以将其与其他在DISPLAYTITLE当中使用span达成“换字体换颜色”效果的用法区分开来。对于其他试图从输出HTML解析维基百科内容的第三方程序(如谷歌搜索)等,span也算是一个恰当的语义。 --Milky·Defer 2021年7月2日 (五) 09:09 (UTC)

  • @Lt2818MilkyDefer:或许可以考虑创建专用模板({{标题书名号}}、{{标题书名号2}}),编者输入书名号、模板后台转成CSS?
    斗阵特攻角色列表:条目顶部放上{{标题书名号|斗阵特攻}},模板自动提取标题中的词,套上双书名号CSS。
    对Beat It的评价:条目顶部放上{{标题书名号|Beat It|单}},模板自动提取标题中的词,因区域分别套上单/双书名号CSS。
    女神异闻录3与4系列角色列表:条目顶部放上{{标题书名号|女神异闻录3|4}},模板自动提取标题中的两个词,套上双书名号CSS。
    对Beat It的评价:条目顶部放上{{标题书名号2|对〈Beat It〉的评价}},大陆用户故意输入单书名号,方便繁体地区正确显示单书名号CSS(大陆界面最外层恒常显示双书名号CSS)。此处也可以用西文字母< ><< >>做语法标记;正好<>也是非法标题字符,标题本身也不会出现。
    女神异闻录3与4系列角色列表:条目顶部放上{{标题书名号2|《女神异闻录3》与《4》系列角色列表}},模板自动解析,套上书名号CSS。
  • 另外有个问题,NoteTA和DISPLAYTITLE的顺序有讲究的,编者乱放位置的话……。另一个问题,如果按前三个例子,编者输入的内容和实体标题简繁/地区词不一致,会不会导致运作失败?再另一个问题,DISPLAYTITLE会不会干涉不转换界面显示的实体标题?(我使用不转换用字做维护,可以检查简繁体混用等问题,这点对我影响挺大)--洛普利宁 2021年7月2日 (五) 14:34 (UTC)
    • NoteTA一般不会和DISPLAYTITLE混合使用吧。如果有NoteTA了的话,就写在T那里即可T也是能插模版的。说起来真的存在能提取标题中的词然后做出修改的模版吗? --Milky·Defer 2021年7月2日 (五) 15:13 (UTC)
      好吧我没分清魔术字{{DISPLAYTITLE:}}和模板{{DISPLAYTITLE}}。T参数处理很不利于维护:一是直接写死标题、后期移动无论是否涉及地区词移动,都要多一步手续修改T;二是要求同时打出简繁、对编辑要求较高;三是要和1=等转换手动同步。
      {{DISPLAYTITLE}}可以依赖NoteTA,自动处理转换标题,至少避开了上面二和三的缺点。(例子)提取标题模块+PAGENAME可以干,但可惜的这只能处理未转换的标题。{{标题书名号|斗阵特攻}}这个方法本来连问题一也能解决,但不知道或不方便看实体标题的话,就没法用了。{{标题书名号2}}稍微差点,但是只敲一种用字就可以,还算比T=方便。--洛普利宁 2021年7月2日 (五) 16:28 (UTC)
  • 没被ping到。MilkyDefer君的方案只需把上面的代码调整一下即可,效果一样。Lopullinen君的方案,{{标题书名号}}不看好,考虑标题中存在多个关键词的情况,或许不是每处都要加书名号;{{标题书名号2}}可以实现,而若要书名号无法选中,也需借助MilkyDefer君的方案。--Lt2818留言) 2021年7月4日 (日) 09:51 (UTC)
    @Lt2818:几个做法不冲突。就像顶注简单情况用{{for}}就够,复杂情况有{{other uses}}补充,真极端情况再{{hatnote}}手写。就是有一个元模版,再创造一批套壳模版构成快捷语法(?);编辑依据复杂情况各取所需。
    像我编辑的领域基本都“XXXX作品列表”“XXXX角色列表”这样,一个词重复两次的情况几乎不会存在。抛开实体标题问题(虽然关键就是抛不开这点)来说,{{标题书名号}}的语法是最实际的。
    另外我的意思是,编者输入“《”,模块后台替换成<span class=doublebookbracket>。大众直接输HTML太难了。—洛普利宁 2021年7月4日 (日) 11:41 (UTC)
    举个关键词重复的例子:你不希望看到《女神异闻录3》与《4》系列角色列表 (201《4》年)吧?
    考虑到用户各种可能的输入,如单双书名号不匹配、只有一边书名号等情况,简单替换或许不足够,需要稍微复杂一些的匹配。--Lt2818留言) 2021年7月4日 (日) 12:12 (UTC)
    第二条的话,考虑用Lua实现简单的括号匹配,发现不匹配问题就抛错误,同时拒绝解析,开个维护分类,什么的……--Milky·Defer 2021年7月4日 (日) 15:26 (UTC)
    我当然不希望看到《女神异闻录3》与《4》系列角色列表 (201《4》年)。但是一方面这个例子虚构的,事实上我活跃的领域,《女神异闻录3》与《4》系列角色列表这种出现两个书名号的标题已经是极端例子了。另一方面,就算真的有《女神异闻录3》与《4》系列角色列表 (2014年)这种标题,也可以用{{标题书名号2}}解决;{{标题书名号}}本身就是为了谋取实用和简洁的平衡,我们不能指望它解决所有问题。
    第二段确是关键点,我们要考虑怎样避免用户犯错。所以我才想,既然同样都要左开右合,那和HTML和乃至('{2,3}).+?\1相比,书名号做标识已经是最直观、最不容易犯错的了。当然我活跃的领域(电子游戏)没有单双书名号或书名号嵌套的问题,所以有些复杂的方面可能还想不周全。这里也希望音乐类(单双书名号)和社科类(大概会有“《对〈关于...〉和〈关于...〉的意见》的社会影响”之类的复杂标题)的编者参与,举出一些真实的复杂例子供分析。此外,大陆用户打单书名号不是很方便,我们能不能考虑用参数处理?总之希望99%问题都有简洁的办法解决。--洛普利宁 2021年7月4日 (日) 19:21 (UTC)
    想到一个判断的方法。简体书名号嵌套是单双交替的,这不用管源代码如何输入,Lua都可以运算判定。繁体用字下根据开书名号顺序,用2、3、4等参数依次指定单双性。比如:
    • {{标题书名号2|对《一剪梅》和《雪花飘飘,北风啸啸》的评价|单|单}} → 对〈一剪梅〉和〈雪花飘飘,北风啸啸〉的评价
    • {{标题书名号2|对《论费玉清专辑〈一剪梅〉及同名歌曲〈一剪梅〉》的评价|单|双|单}} → 对〈论费玉清专辑《一剪梅》及同名歌曲〈一剪梅〉〉的评价
    • {{标题书名号2|对〈论费玉清专辑《一翦梅》及同名歌曲〈一翦梅〉〉的评价}} → 对〈论费玉清专辑《一翦梅》及同名歌曲〈一翦梅〉〉的评价(未指定的原样输出)
    书名号不平衡的可以拒绝套用。书名号是正常标题一部分,又要套用本模板加虚拟书名号的,可以有nowiki包围,Lua视为普通文字解释。--洛普利宁 2021年7月4日 (日) 20:58 (UTC)
    书名号使用单还是使用双,是有地区差异的。实际上可能还要考虑地区差异的问题,单纯的单双单双指定不一定奏效。比如说,对于歌曲,中国大陆使用双书名号,香港就是单书名号。--Milky·Defer 2021年7月7日 (三) 15:02 (UTC)
    @MilkyDefer:又想了一下,条目标题考虑两层书名号,应该能解决绝大多数问题了;两层以上书名号嵌套,正文我都没见过几次。两层的话大陆就是外双内单,模板自动处理即可。我上面说的事情,就是如何方便解决繁体部分——用附加参数指定单双状态。如果再通用一点,可以构思这样的模板:{{标题书名号2|对《论费玉清专辑〈一剪梅〉及同名歌曲〈一剪梅〉》的评价|简=双单单|繁=单双单}}。简体通常不用手工指定,输入的内容自动转成外双内单;繁体可能需要手动定义。--洛普利宁 2021年7月7日 (三) 15:59 (UTC)
  • 刚刚跟随Artoria2e5君建议,改用<cite>元素标记双书名号,语义上更合适。关于“简体书名号嵌套单双交替”,虽见过这个说法,但不见于正式标准;这里是外推《标点符号用法》规定,将内层一律显示为单书名号。--Lt2818留言) 2021年7月5日 (一) 02:34 (UTC)
    见正处于提案阶段的meta:Shared Citations,他们计划占用cite标签。--Milky·Defer 2021年7月5日 (一) 03:45 (UTC)
    看到他们的出发点是为了与<ref>区分开,然而<cite>为HTML元素,我认为最终不大可能改变/增加其语义。--Lt2818留言) 2021年7月5日 (一) 06:08 (UTC)
    但如果他们真的改变了,那事情就需要推倒重来。有没有一些肯定不会造成冲突的代码?SANMOSA Σουέζ 2021年7月7日 (三) 05:33 (UTC)
    使用已知且常用的标签(如div、span等基础元素)加class可以保证没有冲突。如果某个皮肤用了一个冲突的class,我们在本地直接换个class名字就行,不用麻烦别人phab。--Milky·Defer 2021年7月7日 (三) 14:54 (UTC)
    那用其他class吧。只要最后显示出来的标题(非网址标题)的书名号显示可以妥当处理即可。SANMOSA Σουέζ 2021年7月9日 (五) 03:48 (UTC)
要注意:有些时候某些地方用(双)书名号,某些地方用引号(A情况);有些时候某些地方用单书名号,某些地方用双书名号(B情况)。比较复杂的地方大概是这两点。参数上除了“单”和“双”以外,应该至少还需要“引书”(A情况)和“单双”(B情况)。SANMOSA Σουέζ 2021年7月9日 (五) 04:01 (UTC)

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

“禁用书名号”和“必须使用书名号”的方案都社区意见颇多无法达成共识。故提出如下草案,根据WP:7DAYS,予以 公示7日

现行条文

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

提议条文

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

以上。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月12日 (一) 06:53 (UTC)

上面就是有些人连创建不带书名号的重定向也不愿意的情况下,坚持在标题中添加书名号。btw不带书名号的重定向使用书名号重定向模板不合适吧?--AT 2021年7月12日 (一) 07:31 (UTC)
抱歉插入讨论。刚刚看到Sanmosa几天前回复说要考虑地区间标点符号使用的差异,甚至可能牵扯到引号。请问有没有考虑到这个问题?假如惯用引号的地区的用户来了,这个提案只许可了书名号,是否与先到先得有所抵触? --Milky·Defer 2021年7月12日 (一) 15:29 (UTC)
现有方针没有任何地方限制条目名称使用引号,也没有限制除书名号外任何标点符号(除非技术限制),为什么这会是问题?难道现在的方针是必须明确说允许的才能做,没说就不能做?如果这样的话,维基百科的方针及制定方针的人未免太把自个儿当葱了。--7留言) 2021年7月13日 (二) 14:04 (UTC)
问题在于并非所有人都认为标题中书名号的使用没有限制。SANMOSA Σουέζ 2021年7月15日 (四) 11:00 (UTC)
那又怎么样,一方是要禁止,一方是反对禁止,要禁止的不能说服对方,反对禁止也不能说服对方,这就足以说明没有足够理由来禁止。禁止当然要足够压倒的理由,莫非你们香港台湾立法规矩是没有明确允许就算禁止?香港和台湾有立法允许在大街上呼吸吗?--7留言) 2021年7月15日 (四) 14:33 (UTC)
我认为你把焦点放错了。现在争论的地方是“书、篇、报纸、刊物、歌曲、戏曲的条目”的定义,而不是“法无禁止即许可”抑或“法无许可即禁止”。基本上只要“书、篇、报纸、刊物、歌曲、戏曲的条目”的定义明确,整件事情其实就明朗了。(至于你问香港现在的立法规矩是否没有明确允许就算禁止,你明知我是不方便回答的。我或许真的是有不合法呼吸的疑虑。)SANMOSA Σουέζ 2021年7月16日 (五) 13:38 (UTC)
有个问题。提案人的理由像是“禁用和必须使用书名号的方案没有共识,所以消极性的先到先得”,而不是“社区积极达成共识,创建人自行决定是否使用书名号”。题外话:全用、全不用、有条件混用,各自都有各自的好处,谁有理按谁走。当然说“社区就是否使用书名号没有共识”也是陈述事实,但我不赞同写成规定无条件混用。毕竟无论是读者感受、编者维护,随意混用都没有任何好处。
现行Wikipedia:命名常规_(电子游戏)#列表第2点已有规定,“列表应命名为“××××列表”,此处游戏名不加书名号”。对于大多数条目而言,这两种思路执行上没有差别。但电子游戏条目因为已有方针,所以这里会产生规则抵触。如果按意思一解释,则条文保留并按“领域另有规定的除外”解释;如果按意思二解释,就是社群形成了“禁止规定是否使用书名号”的新共识,电子游戏和其他子命名常规(虽然似乎没有其他)的类似条文废除。如果要通过此条文,希望此处能明确立意,避免后续出现争议,或给未来讨论留下明确前提。--洛普利宁 2021年7月13日 (二) 05:16 (UTC)
个别专题内部所达成的共识,不应被显无共识的全站性讨论凌驾。—— Eric Liu 创造は生命(留言留名学生会LEP 2021年7月13日 (二) 08:28 (UTC)
这提案技术上并未进行公示({{Bulletin}}),而且一提案就立即公示也并非正当程序。SANMOSA Σουέζ 2021年7月15日 (四) 11:00 (UTC)

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

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

现行条文

小作品与小小作品的差别

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

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

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

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

提议条文

小作品与小小作品的差别

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

示例 ......

小小作品的定义

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

看到小小作品怎么办

  • 任何人可以在小小作品上,加上小小作品限期修改模板,并标上添加模板的日期。(例如{{substub|7|25}}) ,这样该条目会自动列到该月的小小作品分类中。
  • 在一个月的期限内,任何人可以扩充该条目之后将模板拿掉。如果该条目尚未完整,请改加上各类的小作品模板。(参见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)
  • 目前支持人数多于反对者,欢迎关注此案的人发表一些意见。---Koala0090留言) 2021年6月25日 (五) 15:46 (UTC)
  • (!)意见:我认为这一句“对于条目仅包含信息框,而正文部分完全无内容”重点应该在“完全无”。信息框内容包含有意义的内容,所以不如按照与图片类似的处理方式?“有图片即可视为正文10个汉字(但为了避免条目成为图片收集处,图片共只限减10个汉字,亦即有图片只需40个汉字)。”,具体数字可以商量,比如:可视为20/30个汉字;或者按照有意义的汉字数除2,但不超过20/30。 -- I'm Lewix.|I'm sorry for your loss.| 2021年6月25日 (五) 19:58 (UTC)
    @Lewix:感谢建议,但大多数的信息框其实字数不会那么多,而且重点是所谓“有意义的汉字”判断起来相当困难。例如说CD59浅盘轴孔珊瑚这两篇,有意义的汉字要如何认定呢?如果每位巡查员的标准和算出来的字数不一,我就认为不应该执行,但可能可以出于鼓励信息框创建的性质,对于完整翻译的信息框酌减五个汉字。--Koala0090留言) 2021年6月26日 (六) 05:13 (UTC)
    我的意见即是认为将信息框视为0字是不合理的。以方便执行的角度,不如就和图片一样,将信息框固定视为若干个汉字?具体数字我认为不应低于图片。 -- I'm Lewix.|I'm sorry for your loss.| 2021年6月26日 (六) 05:31 (UTC)
    阁下提出的解决方案,既考虑到可操作性,也给予infobox一定的支持。在下愿意支持您的解决方法。--懒癌哪天行Lazy, as no today's excuse. 2021年7月3日 (六) 10:49 (UTC)
    @Lewix:我认为可以,可能可以统一算10个字,看看大家有没有其他建议。--Koala0090留言) 2021年6月26日 (六) 05:44 (UTC)

先提出计入信息框的方案,看看大家是否支持新方案

现行条文

小作品与小小作品的差别

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

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

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

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

提议条文

小作品与小小作品的差别

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

示例 ......

小小作品的定义

  1. 正文50个汉字以下:外文字母和数字算半个汉字。包含表格及列表内的文字,不包含讯息框的内容和其他模板本身。
  2. 必须有起码有用的内容以及适合的条目:(例如xxx是一个中国演员),因此,涂鸦、测试、与主题无关内容或仅有网址链接的等适用快速删除的条目,以及侵权、广告、个人简介、不适当条目等由删除投票处理的条目,都不在此办法的处理范围之内。

字数减免 若条目符合以下条件,可减免部分所需字数。在同时符合多条标准的情况下可累加减免字数:

  1. 有图片即可视同正文10个汉字(但为了避免条目成为图片收集处,图片共只限减10个汉字,亦即有图片只需40个汉字)。
  2. 信息框可以视为正文10个汉字。但除非必要,不得有未翻译外文及程式错误警示,否则不予计入正文。
  3. 列明出处资料可视为正文5个汉字。

看到小小作品怎么办

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

@和平奮鬥救地球Temp3600SanmosaAn MacaneseNHC:@Lewix:可以看一下新修改方案是否可行---Koala0090留言) 2021年6月26日 (六) 08:24 (UTC)

  • (+)支持:看起来应该可行。-Peacearth留言) 2021年6月26日 (六) 17:27 (UTC)
  • (+)支持:乐见其成。--Temp3600留言) 2021年6月27日 (日) 01:40 (UTC)
Infobox内有时会放图片,需要明确这种时候Infobox+图片是计10个字还是20个字。SANMOSA Σουέζ 2021年6月27日 (日) 02:30 (UTC)
已有“有图片即可视同正文10个汉字”的规定,且并未限定说图片放在哪里,自然是20个字。-Peacearth留言) 2021年6月27日 (日) 02:56 (UTC)
@Sanmosa: 我把相关规定修改了一下,您再看一下---Koala0090留言) 2021年6月27日 (日) 03:49 (UTC)
因应地区用语差异,再微调了一下。大意是OK的。SANMOSA Σουέζ 2021年6月27日 (日) 13:11 (UTC)
“程式”是地区词-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年6月30日 (三) 06:07 (UTC)
@羊羊32521:了解,如果提案通过再加上公共转换组。--Koala0090留言) 2021年6月30日 (三) 08:28 (UTC)
(-)反对,50字这个要求本来已经过低了,随便写都能有50字,现在还变相拉低小小作品要求,倒还不如不要设小小作品存废?一个来源、一个信息框加一张图就变25字,两句都没有,这样的内容根本不应该成为独立条目,例如那些什么人大委员、地理的小条目直接合并到一个独立列表条目都比创建一个只有两行的条目好。上述类型的条目的内容基本上都是信息框内,直接放进同一个表格的栏目内也能表达那一个空泛条目的所有意思。试图变相调低小小作品的议案我不敢苟同。--路西法人留言 2021年7月1日 (四) 09:51 (UTC)
协同路西法人之意见:不支持所谓的“字数减免”。
  1. “字数减免”这用词本身就有点问题:为何能字数减免,是因为这些东西的品质等价于正文字数?
  2. 图片并非创建条目的要求(意不会被A2),亦不能取代正文内容。确实图片可为条目提供更多信息,但多数情况下图片并非为条目的“必需品”:即使有的条目的确需要图片(例如蒙娜丽莎)不然可能会无法理解,但绝大多数的图片对条目而言只是个装饰品,甚至你说在能斯特方程式放个方程式自己的图片来得字数减免我只能说是画蛇添足。
  3. 同上,信息框并非创建条目的要求,亦不能取代正文内容,因某条目有信息框使其得字数减免等于另类降低小小作品原有50字的标准且多数信息框不过是重复提及正文会提到的内容。
  4. 来源本就不属于正文部分,只供符合可供查证,不知为何可得正文字数减免。如果您是说条目没来源也没关系那是违反五大支柱的可供查证。
总言:(-)反对且部分理由(▲)同上LuciferianThomas。我认为根据其主题不同,把“字数减免”套用到全部条目是不合理也应该被禁止的行为。--请多关注评选 2021年7月2日 (五) 09:09 (UTC)
@LuciferianThomasTimmyboger:不能只看提案表面,应该整串讨论一起看,至于通过这个规则究竟是调低还是调升标准,希望先看完下面的说法再评断。
其实我也认为50字的要求非常少,我也认为不应该做这些减免。但问题就是在于现行的方针本文对于小小作品就同时出现两个定义(“小作品与小小作品的差别”一节跟“小小作品提升项目”一节各自出现不同的定义),而对于信息框是否应该计入正文就有两个解释(信息框不算是正文 vs 信息框非预设字段),所以才会导致一开始“宽语”这篇条目我认定是小小作品,但却有用户三番两次来我讨论页表示反对。按照他的说法连这个版本的作品都不能算小小条目。
因此问题很清楚,会导致这些劣质的小小作品继续存在的理由,正是因为规则混乱的关系,甚至我必须为了一篇如此劣质的条目,花费这么多时间与其它巡查员争论这些条目到底是否算是小小条目。所以我认为尽速明确小小作品的定义,乃是解决这个问题的当务之急,但一开始提案直接排除计入信息框的作法遭到一些反对,因此才会妥协将信息框加入字数减免的要求。
所以我认为,如果你们觉得连是否满50字都是个问题的话,更应该尽速让这次的规则先通过,否则刚刚上述的所有作品(宽语、浅盘轴孔珊瑚)都没有办法处理。对我来说,放宽10-20字,比起原先某些巡查员对于信息框字数毫无限制地计入,至少能够处理部分的条目。至于之后要不要维持字数优免、每个物件的折抵次数应该如何微调,可以之后再提案修改。否则明明我们的目标同样都是要解决这些劣质条目,却因为不愿意妥协造成现在这个混乱的状况继续延续,这样不是很可惜吗。--Koala0090留言) 2021年7月2日 (五) 17:12 (UTC)
强烈要求改变以下规则:
  1. 任何描述真实人物、作品(包括但不限于音乐、电视、书籍、小说)以及其附属内容(包括但不限于角色、地点)等内容的小小作品门槛调升至100字(含上述“宽减规则”),不符合以上规则的现有大量创建的条目(例如什么人大委员条目)应合并至独立列表条目;
  2. 来源不计入正文,列出来源是必须做的事情,不应该获得其他方面的内容优惠。
  3. 不可堆叠不同宽免以获得更多的字数宽免,有信息框+有图片就变30字不可取,我宁可你将所有信息框内的内容写进正文也不要你放了信息框然后没多少内容。有信息框图片共最多减免10字。
以上。--路西法人留言 2021年7月2日 (五) 22:37 (UTC)
@LuciferianThomas:我觉得要先考虑现实状况,我的提案算是除错性修改,目标是希望这套方针能得以执行。但您的改动算是影响极大的调整(调升到100字),现实就是还有非常大一部分的人士站在保留立场,你这样的要求只会让明确化小小作品的规则难度倍增,对我来说有些为难。我的精力有限,已经在这个简单的议题上面弄了一个半月了,没道理大家轮流刁难一句我就要自动帮大家找妥协方案,所以如果这个状况持续下去,我就会放弃本次提案。以后大家如果遇到类似问题,对不起,请自己重新提案来过。
本次提案是否通过,对我来说其实没差,大不了之后不对小小作品挂模板。但如果大家诉求是希望尽快处理这件事,那希望大家各退一步,剩下的细节之后自行讨论,我不会干预,感谢。--Koala0090留言) 2021年7月3日 (六) 11:31 (UTC)
  • (+)支持:针对小小作品明确订定标准的作法,予以支持--Wolfch (留言) 2021年7月2日 (五) 22:47 (UTC)
  • (+)支持路西法人提出的方案。我个人强烈认为使用来源本来就是条目内要有的,不应该适用“字数减免”。--请多关注评选 2021年7月3日 (六) 03:03 (UTC)
    所以你用错模板了吧 囧rz……-- Sunny00217  2021年7月3日 (六) 12:30 (UTC)
(-)反对:这样改会严重影响到现存条目的存废,提案通过后会出现新的提删潮。--虫虫飞♡♡→♡℃留言 2021年7月3日 (六) 04:45 (UTC)
Substub有30天的修改时间,加上AFD关于这块也有人维护,应该不会有太大问题。我觉得这个东西社群不能将错就错,是时候改进了。--请多关注评选 2021年7月3日 (六) 10:25 (UTC)
我觉得条目50字是一个合理要求,而且行之有效;把要求提高到100字,中维的条目很快跌穿百万大关。--虫虫飞♡♡→♡℃留言 2021年7月3日 (六) 11:18 (UTC)
如果阁下如此认为“量”就是评判维基百科成功的准则,建议阁下提出将中维定位为索引网站,废除A2、小小作品存废、关注度等方针,那样就能达到您眼中有量就可以不用质的中文维基百科,这样中文维基百科的条目量就能翻倍了。事实上我观察到的正是存在大量仅仅勉强超过50字的条目,尤其为模板式大量创建的条目。这些条目要嘛就不适合创建,要嘛就认真写写就能扩充;但这些模板式条目从来都是建了没人扩充,就放了在那里没人管,很多甚至都是直接用一个独立列表条目也能完全表示这些条目的所有内容。如果你对“条目量下跌”一事感到不满,我不反对此案前所创建不符合新要求的小小作品不直接提删处理而是挂模板要求改善,在限期(一年足够时间了吧?)内扩充或合并至列表,以保证“质”“量”并存。--路西法人留言 2021年7月3日 (六) 12:12 (UTC)
@Timmyboger:我这次提案的目标不是要调升或调降小小作品的标准,而是因为现行方针中同时并存两种标准,因此有必要选择其中一套标准,否则根本无法执行,因此我无意对现行方针做太大幅度的改动。
本次算是除错性修改,让方针得以执行,因此可以算是“具有急迫性的修改”。而调整字数算是“非急迫性修改”,就算不调整也不至于让整套方针无法执行。且如果你们希望调整字数,必须涉及社群共识,我没有责任因为你们“觉得这个东西社群不能将错就错”,就要自动帮你们达成共识。如果你真的很希望社群解决这件事情,希望您担起责任,在本次提案通过后,提议修改这件事情,而不是把这件事情丢给另一个人去弄,这样等于是用一个“非急迫性修改”去杯葛这次“具有急迫性的修改”,希望您重新考虑一下。--Koala0090留言) 2021年7月3日 (六) 11:57 (UTC)
表面上看起来并没有调低标准,但事实上有没有您自己心知肚明。原有方针对“内文”没有明确定义,但事实证明怎么算,拿模板、图片甚至本来就强制要求需要的来源都能拿来抵销字数,正正是变相容许出现“20字条目”的情况。while我提出提高部分经常出现滥建的类别条目的字数要求一项可押后处理,将可抵销字数设限却是本案必要的修改,否则中维就会沦为索引网站。如果你是说改成60字+最多宽免10字我还能理解,不设限的宽免绝不赞同。另,来源不应视为可宽免条件,信息框、图片尚能理解为提升条目的元素,来源是条目的必要元素,不应将加入来源视为可以把条目越写越短的“优惠条件”。--路西法人留言 2021年7月3日 (六) 12:22 (UTC)
@LuciferianThomas:可能回去看一下讨论,我一开始是建议不计入信息框,是因为有成员反对才做出调整。本来任何提案就应该根据社群共识做出妥协,没必要讲这种什么“你自己心知肚明”这种话。这方面的提议是@Lewix:给出的,可以和他讨论一下。----Koala0090留言) 2021年7月3日 (六) 12:36 (UTC)
@LuciferianThomas:另外,图片和参考文献字数减免的部分并不是我订出来的,而是原条文在小小作品提升项目中写的,我并没有调低字数。---Koala0090留言) 2021年7月3日 (六) 12:53 (UTC)
我认为确实100字有些非急迫,毕尽Substub长久以来都是以50字作为标准,但这并不代表会有编者使用“字数减免”来规避50字的原则是可被允许的,尤其关于来源的减免。我理解您是“具有急迫性的修改”,但为何不在新的“得以执行”方针上路前先做好完善,避免可能的曲解?--请多关注评选 2021年7月3日 (六) 13:44 (UTC)
图片和参考文献字数减免的部分,是Wikipedia:小小作品#小小作品提升管理办法中所订定的内容。--Wolfch (留言) 2021年7月3日 (六) 13:46 (UTC)
@Timmyboger:该草案是依据原本小小作品提升管理办法的办法提出,本质上并无对字数限制做出太大的修改。况且若本次草案没有通过,该方针基本上是处于一个无用的状态,因此我认为有急迫性。
至于为什么“不连同非急迫性修改一起做?”100字属于重大修改,这讨论下去恐怕半年跑不掉也未必会有结论。如果你有兴趣,可以另开讨论串负责此一部分,但如果包裹式地要我耗半年在这个议题,那我会连同此案一起放弃,谢谢。--Koala0090留言) 2021年7月3日 (六) 14:35 (UTC)
@蟲蟲飛:,我赞成Koala0090的修正。若此修改后会造成提删潮,会被提删的应该是“本文字数不到50个字,若模版算10个字,图片算10个字,参考资料算5个字,仍不到50个字,但加上模版文字后,超过50个字”的条目,我觉得新的小小条目比较会提删(在旧的条目中,找符合上述条件的条目,有相当难度,至少我用Special:短页面,不太好找),而且小小条目要30天后才能提删。真正提报存废讨论后,又常有维基人会抢救条目,我认为问题没那么大。--Wolfch (留言) 2021年7月3日 (六) 12:02 (UTC)

关于字数优免的调整

@和平奮鬥救地球Temp3600SanmosaAn MacaneseNHC:@LewixWolfchTimmyboger蟲蟲飛:@羊羊32521LuciferianThomas: 由于社群有人要求本次连同字数优免一起进行调整,因此希望大家针对两版本进行讨论。即日起一周(至7月10日),请大家针对各方案进行讨论及方案提供,一周后会对各版本进行投票。---Koala0090留言) 2021年7月3日 (六) 14:51 (UTC)

方案一:Koala0090版本(小小作品不少于50字)

现行条文

小作品与小小作品的差别

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

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

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

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

提议条文

小作品与小小作品的差别

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

示例 ......

小小作品的定义

  1. 正文50个汉字以下:外文字母和数字算半个汉字。包含表格及列表内的文字,不包含讯息框的内容和其他模板本身。
  2. 必须有起码有用的内容以及适合的条目:(例如xxx是一个中国演员),因此,涂鸦、测试、与主题无关内容或仅有网址链接的等适用快速删除的条目,以及侵权、广告、个人简介、不适当条目等由删除投票处理的条目,都不在此办法的处理范围之内。

字数优免 若条目符合以下条件,可减免部分所需字数。在同时符合多条标准的情况下可累加减免字数:

  1. 有图片即可视同正文10个汉字(但为了避免条目成为图片收集处,图片共只限减10个汉字,亦即有图片只需40个汉字)。
  2. 信息框可以视为正文10个汉字。但除非必要,不得有未翻译外文及程式错误警示,否则不予计入正文。
  3. 列明出处资料可视为正文5个汉字。

看到小小作品怎么办

  • 任何人可以在小小作品上,加上小小作品限期修改模板,并标上添加模板的日期。(例如{{substub|7|25}}) ,这样该条目会自动列到该月的小小作品分类中。
  • 在一个月的期限内,任何人可以扩充该条目之后将模板拿掉。如果该条目尚未完整,请改加上各类的小作品模板。(参见category:小作品
  • 在一个月限期内,未能有人使之至少成为50汉字以上的小作品,则可将该条目提交存废讨论,实际删除与否则由存废讨论决定。
  • 相关问题可以到小小作品提升工作小组提出讨论。
方案1意见区
  • (+)支持 信息框,图片等均包含有效信息,仅仅计算正文是不合理。我作为编者,认为,“增加信息框,图片等”比“仅仅写50个汉字”编写难度要高得多。我作为读者,更愿意看到包含正文、信息框、图片的条目,而不是50个没有维基化的汉字。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月4日 (日) 01:38 (UTC)
  • (-)反对:原版本并无明说信息框内容可得字数减免(意原版本并无写“信息框的内容属正文”,而是一些人假定“信息框的内容属正文”)。另我还是坚持来源不应得到减免:来源是证明条目的内容,而非条目本身的内容。--请多关注评选 2021年7月4日 (日) 02:27 (UTC)
  • “信息框的内容属正文”反倒是方案1,方案2 的共识。原版本当然并没有明确写,如果有,那么就不需要这两个方案了;但也没有排除,仅有的文字是“不包含讯息框的预设字段名称和其他模板本身” 。信息框,图片等均包含有效信息,据此,非预设的字段应算入文字数 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月4日 (日) 03:07 (UTC)
(+)支持:50字才是合理要求。--虫虫飞♡♡→♡℃留言 2021年7月4日 (日) 12:35 (UTC)
(-)反对,只支持案三的调整版。--路西法人留言 2021年7月8日 (四) 05:51 (UTC)

方案2:LuciferianThomas版本(小小作品不少于100字)

已撤回:
原提出者撤案--Koala0090留言) 2021年7月5日 (一) 05:46 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

现行条文

小作品与小小作品的差别

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

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

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

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

提议条文

小作品与小小作品的差别

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

示例 ......

小小作品的定义

  1. 正文50个汉字以下:外文字母和数字算半个汉字。包含表格及列表内的文字,不包含讯息框的内容和其他模板本身。
  2. 任何描述真实人物、作品(包括但不限于音乐、电视、书籍、小说)以及其附属内容(包括但不限于角色、地点)等内容的小小作品门槛为100字
    1. 不符合以上规则的现有大量创建的条目应合并至独立列表条目
  3. 必须有起码有用的内容以及适合的条目:(例如xxx是一个中国演员),因此,涂鸦、测试、与主题无关内容或仅有网址链接的等适用快速删除的条目,以及侵权、广告、个人简介、不适当条目等由删除投票处理的条目,都不在此办法的处理范围之内。

字数减免 若条目符合以下条件,可减免部分所需字数。在同时符合多条标准的情况下可累加减免字数:

  1. 有图片或信息框,最多可视同正文10个汉字

看到小小作品怎么办

  • 任何人可以在小小作品上,加上小小作品限期修改模板,并标上添加模板的日期。(例如{{substub|7|25}}) ,这样该条目会自动列到该月的小小作品分类中。
  • 在一个月的期限内,任何人可以扩充该条目之后将模板拿掉。如果该条目尚未完整,请改加上各类的小作品模板。(参见category:小作品
  • 在一个月限期内,未能有人使之至少成为50汉字以上的小作品,则可将该条目提交存废讨论,实际删除与否则由存废讨论决定。
  • 相关问题可以到小小作品提升工作小组提出讨论。
方案2意见区
  • 等方案1有结论,再另外提案吧。两个方案不是并列关系,而是递进的。方案1主要议题是 是否同意“信息框”和“图片”可视作10个汉字。这在方案2里也是认同的。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月4日 (日) 01:38 (UTC)
  • (+)倾向支持:支持是支持,但感觉100字可能会无共识结案。另楼上可能搞错了,方案1是透过增加信息框减免来另类降低小小作品标准,另外方案2是说“信息框”“图片”可视作10个汉字(讯息框可得10字减免,图片得10字减免,讯息框+图片还是10字减免),这跟方案1是完全不同的。--请多关注评选 2021年7月4日 (日) 02:27 (UTC)
  • 未见完全不同,“方案1是透过增加信息框减免来另类降低小小作品标准”是你的解读,并非议题1本身。议题1核心是“信息框”是否可视为10个汉字。 在方案2中亦有同样的文字。同意方案2即为同意该议题
  • 字数减免叠加是WP:小小作品的既有内容。如果对字数有意见,哪些属于减免范围,对字数叠加有异议 请另提方案。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月4日 (日) 02:50 (UTC)
  • 我只能说方案1的核心是“信息框”是否可视为10个汉字,而方案2的核心是“信息框图片”是否可视为10个汉字。如果您是要问这句里单独信息框是否等价于10个汉字那请您问@LuciferianThomas:,上面的叠加纯属我自己的见解。--请多关注评选 2021年7月4日 (日) 12:07 (UTC)
  • 我不清楚为什么要来对中文阅读理解进行争论。
  • 如果文字模糊到很简单的理解都需要去问作者,那么这根本不适合作为方针或指引。
  • 方案2写的是“图片信息框”。我不知道你总结的“信息框图片”从何而来?
  • 从方案2呈现的文字,方案2是:1.某些条目门槛改为100字 2.来源不算字数 3.信息框可算10个汉字 4.信息框和图片文字数不叠加。 对于方案1“信息框”是否可视为10个汉字,方案2里有相同的文字,两个方案是递进的,根本不是并列的两个议题。
  • 说了“如果对字数有意见,哪些属于减免范围,对字数叠加有异议 请另提方案。”。如果你们对方案2有信心,大可单独提案,看看社区对方案的态度,而不是把议题捆绑,拔高要求,让合理的修改都进行不下去。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月4日 (日) 23:13 (UTC)
  • 虽然这不是投票,但我觉得这样支持的下去我实在有点好奇到底有没有认真看草案。这是我根据LuciferianThomas的“强烈建议”作出的初步修改,尚在等待Thomas自行完善方案。我并没有完全否定Thomas的看法,但目前的版本明显有非常严重的缺陷,严重到根本无法施行。例如说,定义第2点复杂到我完全不知道怎么用,什么叫做“真实人物、作品的附属内容”?附属内容的定义是什么?---Koala0090留言) 2021年7月4日 (日) 03:03 (UTC)
(-)反对:100字门槛太高了,可预期中维条目会跌穿百万大关。--虫虫飞♡♡→♡℃留言 2021年7月4日 (日) 12:37 (UTC)

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

方案三:Timmyboger版本(折衷方案)

现行条文

小作品与小小作品的差别

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

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

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

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

提议条文

小作品与小小作品的差别

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

示例 ......

小小作品的定义

  1. 正文50个汉字以下:外文字母和数字算半个汉字。包含表格及列表内的文字,不包含讯息框的内容和其他模板本身。
  2. 必须有起码有用的内容以及适合的条目:(例如xxx是一个中国演员),因此,涂鸦、测试、与主题无关内容或仅有网址链接的等适用快速删除的条目,以及侵权、广告、个人简介、不适当条目等由删除投票处理的条目,都不在此办法的处理范围之内。

字数减免 若条目符合以下条件,可减免部分所需字数:

  1. 有图片即可视同正文10个汉字(但为了避免条目成为图片收集处,图片共只限减10个汉字,亦即有图片只需40个汉字)。
  2. 信息框可以视为正文10个汉字。但除非必要,不得有未翻译外文及程式错误警示,否则不予计入正文。
  3. 符合上述两点,单一条目最多可得减免正文10个汉字。

看到小小作品怎么办

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

经过初步与Koala0090和LuciferianThomas讨论后提出此版本。此方案唯一变动为在字数减免方面,其余部分与方案1无异。--请多关注评选 2021年7月5日 (一) 02:38 (UTC)

方案3意见区
  • (+)支持,100字稍后再谈。--路西法人留言 2021年7月5日 (一) 02:58 (UTC)
  • (※)注意: 该方案与方案1的差别为“1.来源不算字数 2.信息框和图片文字减免数不叠加”,而非描述中所说的“唯一变动为在字数减免方面,其余部分与方案1无异” -- I'm Lewix.|I'm sorry for your loss.| 2021年7月5日 (一) 03:12 (UTC)
  • 我觉得可以,也许可以考虑方案2直接撤案,以增快讨论速度。---Koala0090留言) 2021年7月5日 (一) 04:03 (UTC)

讨论区

  • (※)注意:wp:投票不能取代讨论, 现在较有共识的应是Koala0090版,请就Koala0090版进行讨论。--虫虫飞♡♡→♡℃留言 2021年7月3日 (六) 15:01 (UTC)
  • 投票至少可以显示社群对于不同版本的支持程度,如果决定出来大家支持的是LuciferianThomas版本,我会尊重社群共识。若各位有其它想法,欢迎继续提案。---Koala0090留言) 2021年7月3日 (六) 15:10 (UTC)
  • 就算您要进行民意测试,最终所选版本也要经过讨论和公示,没(?)异议,才能通过;不能绕过wp:共识方针,直接以投票取代讨论。--虫虫飞♡♡→♡℃留言 2021年7月3日 (六) 15:21 (UTC)
    • 那就请在上述两方案中表态,以彰显那一个方案是社群共识。---Koala0090留言) 2021年7月4日 (日) 04:09 (UTC)
  • 争论的由来是“信息框内容是否算是正文”,经过讨论,各方表态一致认同“信息框”可视为10个汉字(&)建议:我认为可以先就这一点讨论和公示。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月4日 (日) 03:23 (UTC)
    • 现在问题就是目前看起来不处理这个问题,整个提案就都无法通过,我也很无奈。---Koala0090留言) 2021年7月4日 (日) 04:17 (UTC)

方案投票

截至提案阶段结束之前,共计有三方案提出,为第二案提出者自行撤案,因此由第一、三案进入投票阶段,成案者将进入公示阶段。

  • 投票期至2021年7月18日,共计一周,候选方案内文位于上方。
  • 一人一票,仅计算支持票,以支持票较多的方案进入公示阶段。
  • 若两方案支持票相等,再计算反对票多寡,反对票较少的方案进入公示阶段。

和平奋斗救地球Temp3600SanmosaAn MacaneseNHC@LewixWolfchTimmyboger蟲蟲飛:@羊羊32521LuciferianThomas:--Koala0090留言) 2021年7月12日 (一) 03:02 (UTC)

方案1:Koala0090版本
方案3:Timmyboger版本
  • (+)支持,防止滥用“减免字数”问题,合理的折衷方案。--路西法人留言 2021年7月12日 (一) 07:36 (UTC)
  • (+)支持:其实我觉得两个方案都好,只要能解决信息框内容是否算是正文的问题就好。但如果只能选一个的话就先选这个吧。-Peacearth留言) 2021年7月13日 (二) 20:41 (UTC)
  • (+)支持--Wolfch (留言) 2021年7月14日 (三) 09:38 (UTC)
投票结果

投票期结束,方案一获0票支持,方案三获3票支持,因此以方案三为通过版本,即日起公示7日。---Koala0090留言) 2021年7月19日 (一) 14:33 (UTC)

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

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

考虑到编辑禁制方针根本没有详细的解除禁制的指引,现提议参照WP:BLOCK新增如下条文:

现行条文

例外

被禁者要求阐明禁制范围,或提出禁制上诉不得在编辑禁制之限。上诉者应使用{{Unban}}模板于其用户讨论页上诉。

提议条文

例外

被禁者要求阐明禁制范围,或提出禁制上诉不得在编辑禁制之限。

……

解除禁制 解除禁制可以有许多种原因,包括:有管理员认为禁制不妥当、更改禁制设置及发现有用户被错误禁制,被禁制的用户可以透过{{Unban}}进行申诉,让执行禁制管理员以外的管理员重新审理。

现行条文

(无)

提议条文

禁制申诉 如被禁制用户认为禁制并不合理或有所疑问,可要求管理员或社群对禁制作出复核。如要提出复核,请把{{Unban}}连同对禁制决定的疑问或要求复审的理由(详细请参照模板的使用说明)置于自己用户讨论页顶并于页中展开讨论。模板会把用户分入Category:封禁及禁制申诉中让其他用户得悉。

进行复核的管理员必须不是对该用户作出禁制的管理员,以避免利益冲突。

复核后结果应加入模板中,显示此复审已完成。如确认禁制属于不适当,需在解禁原因中说明,并移除被禁制用户的对话页中相关的禁制通知。用户如仍不服裁决,可在新的模板加入新的理据继续上诉。而先前负责复审该禁制的管理员不应负责复审其后再次提出的复核申请。

此外,所有禁制均可使用电邮申请复核,所有邮件均应寄到封禁申诉专用电邮列表。如打算提交与阁下隐私有关的资料,也建议使用电邮方式提交。

注意︰如被禁制用户滥用申诉渠道,可被禁止编辑其用户讨论页及/或使用邮件功能,以避免重复的无理申诉影响维基百科运作。

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

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

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

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

更改禁制设置 需要更改禁制设置的情况一般只有两种:若被禁制用户被发现涉及其他需要被禁制的行为,管理员会透过更改禁制设置来避免进一步的扰乱;禁制原因有误,管理员需要重新输入正确的禁制原因。

若编辑禁制通过部分封禁实施,MediaWiki系统允许在不解除禁制的大前提之下更改封禁,只需要在用户页再次点选封禁按钮即可,旧有设置会继续显示;若禁制原因时有误,管理员也会透过此程序来重新输入正确的禁制原因,但原先输入的禁制原因仍会在封禁记录显示。若编辑禁制通过其他手段实施,则应相应修改这些手段。

现行条文

记录 管理员实施编辑禁制后,应同时更新维基百科:编辑禁制记录。如果该禁制是以部分封禁功能方式实行,其执行动作将被封禁日志自动记录,但管理员仍应在编辑禁制记录上记录

提议条文

记录 管理员实施、更改或解除编辑禁制后,应同时更新编辑禁制记录。如果该禁制是以部分封禁功能方式实行,其执行动作将被封禁日志自动记录,无需在编辑禁制记录页面上另行记录

以上。--悔晚齋臆語) 2021年5月30日 (日) 15:06 (UTC)

(+)支持。~~Sid~~ 2021年5月30日 (日) 15:28 (UTC)
(+)支持。--TNLHK (Talk) 2021年5月31日 (一) 11:56 (UTC)
建议删除“但管理员仍应在编辑禁制记录上记录。”日志已经有记录的事项没必要重复写入编辑禁制记录,非常麻烦。--AT 2021年5月31日 (一) 12:43 (UTC)
已经更改为“创建或更改记录”,避免出现每笔禁制更改都需要记录的情形。这一条主要是考虑到部分编辑禁制以过滤器或口头形式执行,没地方找封禁日志。--悔晚齋臆語) 2021年5月31日 (一) 13:23 (UTC)
我的意思是连通过封禁而实现的禁制(或应称为部分封禁)也没有写入编辑禁制记录的必要,其他像过滤器什么的可以照样写进编辑禁制记录,部分封禁已有封禁日志作为记录,没必要重复多写一次。--AT 2021年5月31日 (一) 14:15 (UTC)
理解了,已经修改部分表述。--悔晚齋臆語) 2021年6月1日 (二) 00:11 (UTC)
  • 目前只有管理员才能重新审理申诉问题?其他用户或行政员能不能审理申诉?--Poontele留言) 2021年6月1日 (二) 10:52 (UTC)
    @Poontele:行政员是管理员的一种,换句话说,行政员是比一般管理员拥有更多权限的管理员。其他用户在现行机制下由于无解封权,因此无法审理申诉。SANMOSA Σουέζ 2021年6月1日 (二) 13:04 (UTC)
    个人认为通过舆论来影响司法判决是不恰当的做法。--Temp3600留言) 2021年6月2日 (三) 08:33 (UTC)
    维基百科不是官僚体制。--悔晚齋臆語) 2021年6月2日 (三) 08:46 (UTC)
    同样也不是暴民政治。--Temp3600留言) 2021年6月2日 (三) 08:56 (UTC)
    我不认为我正尝试引入的规则属于暴民政治。--悔晚齋臆語) 2021年6月2日 (三) 09:17 (UTC)
    我只回应"目前只有管理员才能重新审理申诉问题?其他用户或行政员能不能审理申诉?"的部分。禁制申诉本身的理论,我还没有意见。--Temp3600留言) 2021年6月2日 (三) 09:28 (UTC)
(+)支持。--Gluo88留言) 2021年6月1日 (二) 19:06 (UTC)
留意到上面的讨论串中出现一些意见。我建议与上方的讨论进行联动,如果该讨论最后的结果认为“如果你不是管理员,可在讨论时请其他管理员复核该封禁,确定是否调整或取消封禁”并不合理,此提案中的“如果你不是管理员,可在讨论时请其他管理员复核该禁制,确定是否调整或取消禁制”一句也联动取消;该讨论中含“如果你不是管理员,可在讨论时请其他管理员复核该封禁,确定是否调整或取消封禁”句的提案获公示或决定不通过时,此提案在同时符合WP:7DAYS的前提下方可开始公示。SANMOSA Σουέζ 2021年6月2日 (三) 14:49 (UTC)
  • 上下两案涉及普通用户的部分,都可以整理为一句话:“普通用户是否有权力,通过WP:7DAYS或其他方式达成的社群决议,指令管理员执行、修改、取消封禁?”--Temp3600留言) 2021年6月2日 (三) 14:58 (UTC)
    @Temp3600:请留意我对上面的讨论串的提案进行了分案处理。我认为上面的讨论串的提案和这里的讨论串的提案中产生你在上方留言中所提及的效果的其实只有“如果你不是管理员,可在讨论时请其他管理员复核该禁制,确定是否调整或取消封禁(禁制)”一句,因此如果该句以外的部分没有任何其他的问题的话,我不建议全案推倒。我会建议就该句与该句以外的部分分开讨论。SANMOSA Σουέζ 2021年6月2日 (三) 15:11 (UTC)
    在下理解,所涉及的提案不是: "普通用户是否有权力,通过WP:7DAYS或其他方式达成的社群决议,指令管理员执行、修改、取消封禁? "。 请注意,上面Itcfangye已经指出: 本提案不是讨论“封禁权”是否为管理员的专属,而是“申诉权”和“意见权”。--Gluo88留言) 2021年6月2日 (三) 17:50 (UTC)
    @Temp3600:即使是我的提案,最终也是需要管理员来复核封禁或禁制,并由管理员决定是否修改或取消的。普通用户的工作是指出封禁或禁制的不合理之处。Itcfangye留言) 2021年6月3日 (四) 00:46 (UTC)
    @temp3600itcfangyesanmosagluo88:我昨晚思考了一夜,认为“(认为封禁时间)过短”是一个严重的问题,没有上诉还加封禁期的道理,诚然如temp3600所言。本案中,已经将“封禁的时间过长或过短”改为“封禁的时间过长”。本人认为,删去这一句之后,本案所涉及问题就是纯粹的申诉和意见权。--悔晚齋臆語) 2021年6月3日 (四) 03:39 (UTC)
    同意悔晚斋阁下的看法。 --Gluo88留言) 2021年6月3日 (四) 12:51 (UTC)
    详细的回应留在上方写。总的来说,是要介定这个“申诉和意见权”到底有几大,这项权力与原有的制度(如ANM的讨论版、被封禁用户的讨论页中的求情)之间的关系。--Temp3600留言) 2021年6月3日 (四) 15:00 (UTC)
  • 社群并不一定是一个理性的角色——尤其是存在拉帮结派的现象时。可以回顾一下守望者爱孟事件的前后经过。--GZWDer留言) 2021年6月3日 (四) 15:42 (UTC)
    如果你真的觉得对守望者爱孟的封禁是合理的话,我无话可说。--悔晚齋臆語

根据实际情况,暂时折叠本讨论,直到上方有关封禁方针的讨论告一段落。--悔晚齋臆語) 2021年6月4日 (五) 08:49 (UTC)


上方讨论因未有进展遭存档,撤销此讨论折叠。—— Eric Liu 创造は生命(留言留名学生会LEP 2021年7月22日 (四) 09:41 (UTC)

设置新的保护类型

无共识:
注册用户保护无共识。--虫虫飞♡♡→♡℃留言 2021年7月24日 (六) 10:18 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

维基百科部分条目被IP破坏者亦有,如直接半保护,可能影响到非自动确认用户进行正常编辑(如果它们不会提起编辑请求),遂提议设置此保护类别。

图标 命名 简介
Missing image text.svg 注册用户保护 受到此保护的页面只有注册用户(不论是非新用户,确认用户或自动确认用户)可以编辑。

--CreeperDigital1903 2021年6月7日 (一) 12:07 (UTC)

(-)倾向反对蛤,才50就自确了啦。--路西法人留言 2021年6月7日 (一) 12:34 (UTC)
我觉得不一定,我从新用户变成自动确认花了快一个月。50说少也不算少了,又不是英维只要10次。问题是这在技术上能否实现,以及是否真的有“IP用户进行破坏但新用户不会”的情况。--Milky·Defer 2021年6月7日 (一) 13:19 (UTC)
如果要这样做的话,那必须将自动确认用户的要求进一步提高(可以把要求提升到与对Tor用户的要求一样,都是注册达90天并编辑达100次)。SANMOSA Σουέζ 2021年6月8日 (二) 03:11 (UTC)
这个级别绝不应用于取代目前的半保护。七日确认机制是阻止即兴破坏者的利器。--Temp3600留言) 2021年6月8日 (二) 08:00 (UTC)
@Temp3600:或许把注册用户保护、原一般半保护(注册满一周用户保护)和原Tor半保护(新半保护)当成3个并行的层级也可。我只是感觉现时zhwiki的自动确认用户的要求真的有点低而已。SANMOSA Σουέζ 2021年6月8日 (二) 14:09 (UTC)
如果真得需要那么多保护级别,或许用AF即可。--银河市长☎️— 2021年6月9日 (三) 08:15 (UTC)
话说我真的无法理解为什么wp:right申请“确认用户”需要有“自动确认用户”--木瓜不是食物#留言 2021年6月8日 (二) 05:33 (UTC)
用来给老用户开合规的分身账户,例如进行涉及确定用户权限的技术测试。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年6月8日 (二) 12:05 (UTC)
不是自确亦可申请。--Hamish with w. 2021年6月8日 (二) 14:15 (UTC)
又被半保护了--木瓜不是食物#留言 2021年6月10日 (四) 03:38 (UTC)
@Jonathan5566:其他版请-- Sunny00217  2021年6月12日 (六) 04:35 (UTC)
(-)倾向反对功效不大-- Sunny00217  2021年6月9日 (三) 09:08 (UTC)
(-)反对。—MintCandy♫ 欢迎参加浙江专题 台州专题 2021年6月10日 (四) 05:04 (UTC)
(-)反对,没有太大作用。--Lanwi1(留言) 2021年6月21日 (一) 15:39 (UTC)
(-)反对,破坏者随便注册账户就能乱改。天蓬大元帅-会客 阅读机器翻译放松一下 2021年7月17日 (六) 07:55 (UTC)

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

引入延伸确认保护

已通过:
已公示七天,有关人事任免条件的条文修订,公示期间没有反对意见,这个修订已通过;但延伸确认保护有少数反对意见,暂时未通过。--虫虫飞♡♡→♡℃留言 2021年7月17日 (六) 10:08 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

延伸确认保护还比较值得讨论。—— Eric Liu 创造は生命(留言留名学生会 2021年6月10日 (四) 09:47 (UTC)
上面说的有道理。--安忆Talk 2021年6月10日 (四) 13:33 (UTC)
(▲)同上,XC权更值得讨论。--路西法人留言 2021年6月10日 (四) 14:13 (UTC)
(▲)同上--虫虫飞♡♡→♡℃留言 2021年6月18日 (五) 13:40 (UTC)
(+)支持 2021年6月19日 (六) 23:31 (UTC)

初步提案如下:

现行条文
提议条文
延伸确认权限条件
  1. 账户已注册3个月。
  2. 已经编辑条目空间500次。(不含用户页及用户讨论页)
  3. 符合条件后,系统自动许可。
延伸确认权保护
  1. 只能由延伸确认用户编辑。
现行条文
  1. 解任投票联署提出或上任投票开始1个月前,编辑100次或以上;并在联署提出或上任投票开始前3个月内至少有一次编辑(不包括任何用户页及用户对话页);
  2. 编辑3000次或以上,或编辑1500次条目或以上。
提议条文
  1. 解任投票联署提出或上任投票开始1个月前,拥有延伸确认权限;并在联署提出或上任投票开始前3个月内至少有一次编辑;
  2. 编辑3000次或以上,或编辑1500次条目或以上。

以上。--虫虫飞♡♡→♡℃留言 2021年6月20日 (日) 04:14 (UTC)

(-)倾向反对Wikipedia:常年提案#扩展确认用户:没有充分理由证明延伸确认用户比自动确认用户更适合进阶编辑-- Sunny00217  2021年6月20日 (日) 07:07 (UTC)
鉴于刚才有人抗议其实是覆盖编辑表示不满,我就画掉反对了((([开玩笑的]-- Sunny00217  2021年6月20日 (日) 07:24 (UTC)
(+)支持,不过可以参考目前的自动确认用户设立权限申请及除权,还有保护方针可以同时跟进条文“当出现自动确认用户编辑战或半保护时仍无法有效的保护条目管理员即可提高至延伸确认保护”。~~Sid~~ 2021年6月20日 (日) 07:16 (UTC)
(▲)同上,但固然前提是参与编辑战的用户并非延确用户 --路西法人留言 2021年6月20日 (日) 07:46 (UTC)
Wikipedia:常年提案#扩充确认用户的“未通过原因”的回应:不应将设立延确用户视为进行“进阶编辑”或“解决争议”的手段。设立延确应是减少高风险页面的破坏,而非如该页所述“编辑全保护页面”等操作(这个不是延确的工作)。延确应配合设置蓝锁作为破坏行为的防范手段而非争议编辑的处理手段。编辑争议/编辑战的行为依然应该以金锁处理(尤其为政治议题)。现行确实有银锁的编辑战保护,以蓝锁作为防止争议的保护手段的考量应与银锁编辑战保护相似。--路西法人留言 2021年6月20日 (日) 07:38 (UTC)
为什么要用一堆xx锁的非正式用语! -- Sunny00217  2021年6月21日 (一) 00:00 (UTC)
随便啦wwwwww--路西法人留言 2021年6月21日 (一) 02:27 (UTC)
感觉只不过是将自动确认用户的难度延后到ex确认用户的难度吧,并不能根本破坏防范的问题。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年6月21日 (一) 03:21 (UTC)
刷500比刷50难啊,还要90天。--路西法人留言 2021年6月21日 (一) 05:51 (UTC)
(-)反对,延伸确认保护主要针对被破坏的半保护页面,在解决编辑战方面没有太大作用。目前中文维基百科没有足够条件引入延伸确认保护。--Lanwi1(留言) 2021年6月21日 (一) 15:33 (UTC)
阁下哪里来“延确保护必定需要协助解决编辑战”的说法?延确用来保护高风险页面或模板正合适,高编辑战风险也不会拿延确来保护而是全保护了啊。--路西法人留言 2021年6月22日 (二) 02:21 (UTC)
中文维基百科有半保护和模板保护就足够了,我看了一下外文版方针,延伸确认保护仅用来保护被破坏的半保护页面。--Lanwi1(留言) 2021年6月22日 (二) 16:42 (UTC)
这样的话确实和模板保护有点重复。我有个反建议:延伸确认保护可以拿来处理人事任免投票资格@Lanwi1SANMOSA Σουέζ 2021年6月27日 (日) 01:18 (UTC)
(?)疑问 人事任免投票资格?是要把延伸确认资格从500次编辑拉伸到1500或3000次编辑吗?—- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月27日 (日) 01:56 (UTC)
可以把人事任免投票资格第一条的“编辑100次或以上”改为“延伸确认资格”,其他维持不变。--虫虫飞♡♡→♡℃留言 2021年6月27日 (日) 02:19 (UTC)
(+)支持User:虫虫飞案。 -- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月27日 (日) 02:26 (UTC)
把延伸确认资格从500次编辑拉伸到1500次或3000次编辑是可行的,甚至如果技术允许的话,可以让系统自动判别用户是否符合人事任免投票资格,然后为符合资格者自动许可延伸确认用户,许可后不符合资格者自动除权。SANMOSA Σουέζ 2021年6月27日 (日) 02:34 (UTC)
太高了,这最终会过度妨碍想编辑的人。有些职业维基人[开玩笑的]一周不到就可以三千,但非职业维基人[开玩笑的]想要达到千次以上都会花费相当长的时间,可能半年,可能一年,总之太长了。--安忆Talk 2021年6月27日 (日) 03:41 (UTC)
不然一样维持500次,然后把人事任免投票资格第ー条的“编辑100次或以上”改为“延伸确认资格”,其他维持不变,则是变成将人事任免投票资格第ㄧ条改成500次。-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年6月27日 (日) 03:48 (UTC)
人事任免投票资格完全可以计票时审核(就是目前的方式),不需要依赖任何技术上的用户组啊(不用为了这个资格创建用户组的意思)?--Xiplus#Talk 2021年6月27日 (日) 04:35 (UTC)
这样做可以直接省去计票审核的程序,因为不符合资格者自己也投不了票。SANMOSA Σουέζ 2021年6月28日 (一) 00:23 (UTC)
现在计票审核也没多难,都有工具帮助了;前面提的延伸确认资格根本无法完全涵盖人事任免投票资格(技术上根本无法计算“在联署提出或上任投票开始前3个月内至少有一次编辑”),无法省去计票审核的程序;没有资格者应该还是能发表意见,不可能用保护功能。--Xiplus#Talk 2021年6月28日 (一) 02:04 (UTC)
@Sanmosa延伸确认保护也不能处理人事任免投票资格,只能处理被破坏的半保护页面。--Lanwi1(留言) 2021年6月27日 (日) 16:02 (UTC)
@Lanwi1:抱歉,我完全不同意你的看法。中文维基百科不是英文维基百科的中文版,如果中文维基百科的社群共识决议对延伸确认保护有另类的用法的话,那这种另类的用法仍然是可行的。SANMOSA Σουέζ 2021年6月28日 (一) 00:23 (UTC)
@Sanmosa:除了英文版,法文版和日文版也实施延伸确认保护,都是防破坏,若有另类的用法会脱离本来的目的。目前中文维基百科没有如问题编辑频繁发生之类的足够背景支持引入延伸确认保护。--Lanwi1(留言) 2021年6月28日 (一) 19:22 (UTC)
@Lanwi1:我有一个疑问:您认为共产主义现在能否永久半保护(近半年约被破坏了10次以上)?如果说这个是意识形态,那么性交(现在被半保护了约10年)和同性恋呢?从目前中维鼓励一切用户进行编辑的角度来说这些条目确实都不应该半保护,但是过去几个月的经验/历史记录很明显显示出如果不半保护还会继续有破坏,但如果引入了扩展保护,很明显这几个条目就适合进行长期半保护了。当然,对应的原本很有争议的条目自然可以上升至扩展保护,但是如果只有半保护和全保护的话,至少我认为情况是比较尴尬的。--ときさき くるみ 2021年6月29日 (二) 11:28 (UTC)
条目共产主义现在不需要永久半保护的原因是未受到频繁破坏。扩展保护仅用于被破坏的半保护页面,我还认为需要永久扩展保护的基本上都是被LTA破坏的半保护页面,若以针对LTA突破半保护为由引入扩展保护,我表示支持。另外日文版引入扩展保护的背景就是有些LTA喜欢突破半保护,本地只有影武者喜欢突破半保护……--Lanwi1(留言) 2021年6月29日 (二) 20:45 (UTC)
@Lanwi1:您能否大致给出您心目中频繁的标准?在我看来在一个大部分科学类条目两三年没人写的地方,某个条目半年被破坏了接近10次绝对达到频繁的标准了。另,看了一下英维,的确您说的有道理,不过英维同样对波兰种族主义阿以冲突这类高争议但应该没有LTA的条目进行了扩展保护。--ときさき くるみ 2021年6月30日 (三) 07:16 (UTC)
基本上是短期内密集破坏,因此长期又零星的破坏就处于临界情况,我无法直接说一律保护或不保护,要按个案判断,但若是冷清的条目导致看起来编辑全是破坏,那或许会被保护。--Xiplus#Talk 2021年6月30日 (三) 08:01 (UTC)
不同意引入扩展保护会让“这几个条目就适合进行长期半保护”,引入比半保护层级还高的扩展保护不应该变相让半保护的标准放松,如果您认为半保护的标准应该放松,您应该提议社群更改半保护标准,而不是透过引入扩展保护来解决。--Xiplus#Talk 2021年6月30日 (三) 01:23 (UTC)
@Xiplus:我知道,但这更多不是标准的问题:我个人认为(欢迎指出错误),排除掉全保护外只有半保护和不保护,管理员在遇到已被轻至中度破坏的争议条目由于只有这两个选项,自然会更倾向于不保护,让其他编者去自行回退掉破坏的编辑(海纳百川有容乃大,这可是中维的标语),而非进行半保护(但是从实用主义角度来说,我个人认为这并非好事,这样反而浪费了人力去维护本可以不存在的破坏,如果进行了半保护,原本要贡献的编者可以在讨论页请求编辑保护条目,而原本的破坏者的破坏也就自然留在了讨论页,而非条目页)。但如果有了扩展保护,管理员就更自然地会考虑短时进行半保护。--ときさき くるみ 2021年6月30日 (三) 07:16 (UTC)
全面全保护就再也不会有破坏了,但这是不可能的,所以保护跟开放只能取得一个合适的平衡。“扩展保护,管理员就更自然地会考虑短时进行半保护”,我不会,所以我才无法理解引入扩展保护的目的,要达成你的目的只能引入一个比半保护层级还低的保护。--Xiplus#Talk 2021年6月30日 (三) 07:52 (UTC)
@Xiplus:我懂all or nothing的问题,但说实话单从结果来看确实是很多英维半保护且中维(我认为)也应该半保护的条目没有半保护,比如上面那几个例子,如果您认为这不是扩展自确的原因,欢迎您说说您认为是什么原因导致中维更不倾向于半保护。--ときさき くるみ 2021年6月30日 (三) 08:25 (UTC)
英维破坏量更多,自动确认门槛较低。这是一般性原因,不是针对前面您提的条目。--Xiplus#Talk 2021年6月30日 (三) 13:05 (UTC)
英维破坏量多没问题,但其实中维破坏比例可能高一些,我没实际做过数据统计,但是单从个人经验来看感觉如此。我知道,我强调这几个例子只是为了突出现在的问题。不过现在我想问一句:设立一个(全保护之下的)更低门槛和设一个更高门槛真的本质上不等价吗?最后,我希望我是错的,但是每次点开这些常用条目一翻历史就能看到一批扰乱性编辑实在让人恼火,所以我才大力支持,哪怕能稍稍激励一部分管理员更勤的上半保护我个人目前认为也是值得的。--ときさき くるみ 2021年6月30日 (三) 17:22 (UTC)
查阅您提出的几个条目,都没有近期请求保护被拒绝的案例,所以您说这些条目管理员不会保护这点实在有待商榷。--Xiplus#Talk 2021年7月1日 (四) 02:02 (UTC)
好吧,我可妥协,但我还是对上文所述的现状不满。--ときさき くるみ 2021年7月1日 (四) 17:31 (UTC)
(+)支持设立甚至拔高门槛,wikiscan上的数据显示每月活跃自确至少约占每月活跃用户数的6%~7%,今年上半年至少应有超过2700名自确用户进行过编辑,最近更改的筛选栏中也有对初学者和有经验的编者的区分。是,某些条目生来就是有争议的,这些条目的编辑战可能确实没法避免,但至少设立更高门槛的自确可以让想要参与这些条目的人进一步学习中维的规则和过去的案例,而且引入扩展自确之后也可以对一些有相对较少争议(但总体上仍有较大争议)的条目上半保护。--ときさき くるみ 2021年6月27日 (日) 16:27 (UTC)
编辑数与学习规则毫无关联。->>Vocal&Guitar->>留言 2021年6月30日 (三) 04:59 (UTC)
@Ohtashinichiro:Yes, but actually NO. 是,这两者是没有直接关系。但大多数编者的条目编辑水平和辨别来源的水平最终还是在编辑的过程中提升的,您不能指望一个不懂维基语法的新手在中维这种左侧栏里没有“学习如何编辑”的地方一开始就懂如何将他主观想写的东西写出来并引出来源,更别提去辨别来源是否可靠,是否是主流观点了。这么说可能有点太泛泛而谈了,您不妨回想一下您刚开始写维基百科的时候写的条目是什么水平而现在又是什么水平(如果您不介意的话我可以帮您找找您早期的编辑)。--ときさき くるみ 2021年6月30日 (三) 07:16 (UTC)
我和你讲规则,你和我讲技术。对于想闯红灯的人,需要过问他的车技?。->>Vocal&Guitar->>留言 2021年7月3日 (六) 01:27 (UTC)
我是觉得高引用数转换组(CGroup)如果要保护的话,Extended confirmed users这种水准正好比较合适。一般高风险模板可能有各种各样的技术考量,模板编辑员也是技术优秀的用户。但转换组基本就是纯内容向模板,熟悉相关领域、掌握简单语法的编辑都可以胜任修改。50次编辑可能经验不足,500次编辑大概就比较合适了。--洛普利宁 2021年7月3日 (六) 09:54 (UTC)
根据WP:7DAYS,现就延伸确认保护及人事任免的修订提案公示七天。--虫虫飞♡♡→♡℃留言 2021年7月10日 (六) 10:02 (UTC)
对于这一没有经过仔细思考和周全考虑的提案,我是不会支持的。况且提案的疏漏没有得到解决。--Bookwith留言) 2021年7月13日 (二) 18:33 (UTC)
@Bookwith:请说说有什么疏漏。--虫虫飞♡♡→♡℃留言 2021年7月14日 (三) 00:13 (UTC)
应该能看出,连实施细节都没想好就来提案了。--Bookwith留言) 2021年7月14日 (三) 05:43 (UTC)
放心吧,这个很简单,而且之前本站有过模板保护及模板编辑员的引入的经验。--虫虫飞♡♡→♡℃留言 2021年7月14日 (三) 05:51 (UTC)
为什么是条目空间500次?这类要求向来没有指定名字空间的。即使有充足经验,依然应该列出各项实施细节。--Bookwith留言) 2021年7月14日 (三) 06:46 (UTC)
英维日维都是500次条目空间,而且避免用户在用户页刷够500次。至于具体细节,就像英维那边,系统会自动许可;还是您希望像日维那边一样可以通过申请获得?即管理员可以授予可信用户权限,也可移除用户的权限?--虫虫飞♡♡→♡℃留言 2021年7月14日 (三) 06:52 (UTC)
英维日维的要求都不是500次条目空间,请别撒谎。--Bookwith留言) 2021年7月14日 (三) 08:49 (UTC)
英维方针没有写明,但我就亲身试过了,而且取得了英维的延伸确认用户权(500次条目空间后才获得),500次非条目空间,英维是不会授予延伸确认权,您可以去试一下。--虫虫飞♡♡→♡℃留言 2021年7月14日 (三) 09:07 (UTC)
根本不是,那里500次是不限名字空间的,不要再误导他人了。--Bookwith留言) 2021年7月14日 (三) 11:45 (UTC)
我不太了解原因,总之我在英维600次编辑数时,确实没有获得“延伸确认”,要在“条目空间500”才能获得权限。--虫虫飞♡♡→♡℃留言 2021年7月14日 (三) 12:06 (UTC)
既然您担心门槛太高,我把门槛降低至不只限于条目空间。--虫虫飞♡♡→♡℃留言 2021年7月14日 (三) 10:00 (UTC)
到底排除用户/用户讨论页,意义何在。--Bookwith留言) 2021年7月14日 (三) 11:49 (UTC)
意义在于避免用户GAME,刷编辑数。您看VIP存档,经常有人举报有用户刷编辑数以求“自动确认”。--虫虫飞♡♡→♡℃留言 2021年7月14日 (三) 12:00 (UTC)
我反对这一要求,因为实在太没意义了。一些编者们愿意刷到自动确认,不代表他们愿意刷到延伸确认,尤其是500次编辑对于他们来说是个难以达到的目标;甚或有一些只求移动权限、只求上传图片的编者,难道他们会对这一延伸确认权有兴趣?我们必须面对现实,看看各大站点的权限摘要。看,古今中外,有哪个站点的权限要求会像这样排除某些名字空间?无论是需要申请的权限,还是自动授予的权限,没有一个站点会设下这样的限制。为什么?因为稍有智慧的人都不难看出,这样设限对于恶意刷权限的编者来说,几乎没有任何作用。提案前请三思。--Bookwith留言) 2021年7月14日 (三) 17:51 (UTC)
刷???编辑数是用刷的?= =这我有理解错误吗?如果没有那这反对简直胡闹。~~Sid~~ 2021年7月14日 (三) 18:15 (UTC)
就是有这种人啊,-- Sunny00217  2021年7月15日 (四) 03:19 (UTC)
那把门槛降低至不只限于条目空间不就解决了?是在乱吵什么鬼?-- [雪菲🐉蛋糕🎂] >[娜娜奇🐰鲜果茶☕](☎️·☘️) 2021年7月15日 (四) 04:17 (UTC)
要故意排除用户/用户讨论空间,难道不会显得很可笑吗?--Bookwith留言) 2021年7月15日 (四) 04:56 (UTC)
(-)强烈反对该提案, 如果不加限制地滥用保护, 把所有争议条目都加以保护, 不是彻底违背了WP:SOPWP:BB的原则? 那样的话,当时允许IP用户编辑就是一个错误的决定. 最后让维基百科变得与百度百科没有任何区别. --Yining Chen留言|签名) 2021年7月17日 (六) 07:42 (UTC)
@Yining Chen:延伸确认保护不能乱用的,只有半保护无法保护的情况下,才能用,而且可以减少用“全保护”,所以不违反WP:SOPWP:BB,此外也与ip编辑无关,因为半保护下,ip也不能编辑,但您不因此反对半保护,防止破坏也很重要。--虫虫飞♡♡→♡℃留言 2021年7月17日 (六) 08:07 (UTC)
  • 已公示七天,有关人事任免条件的条文修订,公示期间没有反对意见,这个修订已通过;但延伸确认保护有少数反对意见,暂时未通过。--虫虫飞♡♡→♡℃留言 2021年7月17日 (六) 10:08 (UTC)

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

引入延伸确认保护(第二稿)

已通过:
已公示七天,有关延伸确认用户权及延伸保护的条文修订已通过。--虫虫飞♡♡→♡℃留言 2021年7月24日 (六) 10:13 (UTC)
下列讨论已经关闭,请勿修改。如有任何意见,请至合适的讨论页进行,并不要再次编辑本讨论。

现根据第一稿的少数反对意见修订如下,重新公示七天:

现行条文
提议条文
延伸确认权限条件
  1. 账户已注册3个月。
  2. 已经编辑500次。
  3. 符合条件后,系统自动许可。
延伸确认权保护
  1. 只能由延伸确认用户编辑。
  2. 在半保护无法阻止破坏时才能用。
  3. 在半保护无法阻止的编辑战时才能用。

以上。--虫虫飞♡♡→♡℃留言 2021年7月17日 (六) 10:13 (UTC)

  • 已公示七天,有关延伸确认用户权及延伸保护的条文修订已通过。--虫虫飞♡♡→♡℃留言 2021年7月24日 (六) 10:13 (UTC)

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

修订书籍关注度

第三项改为:该书曾经改编成在数个商业剧院中播放的电影、于任何国家或地区的网络电视或有线电视台播放的电视剧、网络平台播放的网络剧

这样改编为网剧的小说也有关注度了。比如同学两亿岁,目前有网剧条目却无小说条目。--Fire Ice 2021年6月28日 (一) 20:11 (UTC)

(+)支持--虫虫飞♡♡→♡℃留言 2021年6月28日 (一) 22:28 (UTC)
“任何国家”应改为“任何国家或地区”(“地区”的定义参照Wikipedia:关注度 (组织)#政府部门的注释)。SANMOSA Σουέζ 2021年6月29日 (二) 01:55 (UTC)
我对此修改有保留,(-)倾向反对,首先“网络平台播放的电视剧”是有语病,在网络平台播放的不会称为“电视剧”;另一方面,如果改为“网剧”,也没有明确定义,在YouTube(“网络平台”)上用户自行上传的低成本影片能不能称之为“网剧”?--【和平至上】💬 2021年7月1日 (四) 11:38 (UTC)
其实说网剧在规格上和电视剧一样吧,只是说是搬上网络媒体播放,假如是‘低成本’,没一个正式剧组,或是发行商,甚至说不是小说官方的改编,都很明显不是正式的网剧,而只是一种民间自制的影片吧,这种东西也自然不能代表着原书籍的关注度。(平台反而不是重点,很多正式的网剧也选择了在Youtube上发行) Iridium(IX)留言) 2021年7月1日 (四) 13:05 (UTC)
(-)倾向反对,除了上面两条,网络平台和网络电视如何定义也是个问题。看网络平台网络电视条目,放在网络上的任何质量的剧集可能都满足条件。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月1日 (四) 14:35 (UTC)
网络电视应该是指把电视节目放进互联网播放的一种方式吧,可能是说那节目本身就有着类近电视剧的规格?质量应该是有保证。还有网络平台就是网页一个更fancy的名字,不明白还能如何定义? Iridium(IX)留言) 2021年7月1日 (四) 15:04 (UTC)
奇怪,用户自制影片当然算不得网剧,根据你维定义,网络剧(英语:web series),即在互联网或率先于互联网播放的剧集。网络剧的播放一般基于视频网站的支持。另外网剧质量当然可能很烂,我们谈的不是质量,而是关注度。Fire Ice 2021年7月2日 (五) 06:48 (UTC)
“用户自制影片”和“网剧”并不存在明显的分界线。“网络平台播放的网络剧”并不能保证该剧符合关注度,更无法保证该剧改编自的书籍符合关注度。建议加上“该电影、电视剧、网络剧需符合关注度”,个人认为这样只是为关注度提供一个方便判定的标准,不能算做违反关注度不能继承的准则。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月2日 (五) 22:48 (UTC)
之所以有人认为电视台播放的电视剧有关注度,是因为它是有可信媒体背书的;而“网络剧”有的是平台发布,有的是用户制作,前者可能是可信媒体,而后者大部分情况不是。我觉得应该从发布者和制作者来区分。——落花有意12138 回复请ping我 2021年7月2日 (五) 10:35 (UTC)
不,你维并不认为电视台播放的电视剧就有关注度了,而改编成该电视剧的小说却有关注度。Fire Ice 2021年7月2日 (五) 14:03 (UTC)
WP:虚构准则 需同步修改。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月2日 (五) 22:48 (UTC)

另外提案

我反而想提议删除第五条,这一条明显抵触了WP:NRVE中关注度不能继承的共识。-【和平至上】💬 2021年6月30日 (三) 18:30 (UTC)
(-)反对:WP:NRVEGNG通用关注度指引的一部分,与此案无关。不同专题关注度都有不同的要求,千万不要把GNG通用关注度指引和其他十几个的专题关注度指引混淆。--虫虫飞♡♡→♡℃留言 2021年7月1日 (四) 04:02 (UTC)
请这位管理员看清楚,WP:NRVE不是GNG的一部分,GNG是WP:N的第一部分,NRVE是第二部分。能说出“WP:NRVE是GNG”令我怀疑阁下究竟有没有看过WP:NRVE。--【和平至上】💬 2021年7月1日 (四) 11:30 (UTC)
  • WP:N就是通用关注度指引,和其他专题关注度指引无关,请勿把专题关注度指引和通用关注度指引混淆,而且最早的关注度指引是BIO,而不是GNG(2007年才有)。--虫虫飞♡♡→♡℃留言 2021年7月1日 (四) 11:50 (UTC)
WP:N从逻辑和现有内容来看,应当包含WP:GNG和专题关注度指引。可以考虑创建 专题关注度 的二级标题,将其明确化,并检阅复审专题关注度和WP:N的冲突抵触。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月1日 (四) 14:22 (UTC)
已经有了,见WP:GNGRL,而且WP:N第一段已经说了:“如果某一主题符合下述的通用关注度指引,那么我们便可认为该主题的受关注程度满足创立条目的要求。此外,如果某一主题符合任何一项专题关注度指引之标准,则其同样可视为具备关注度。”其他专题关注度如BIO也有类似的叙述,但不能说其他专题关注度包含GNG的。--虫虫飞♡♡→♡℃留言 2021年7月1日 (四) 14:28 (UTC)
这跟你所说的“WP:N就是通用关注度指引,和其他专题关注度指引无关” 自相矛盾啊。。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月1日 (四) 14:42 (UTC)
没有矛盾,因为WP:GNGRL本来是没有的,因为本站的用户没有习惯通读方针指引,而且同一个方针指引也没耐性读完,很多用户不太了解方针,才有人在WP:N加了WP:GNGRL。--虫虫飞♡♡→♡℃留言 2021年7月1日 (四) 14:46 (UTC)
(~)补充:《通用关注度》不是唯一的收录标准,也不应以《通用关注度》的观念及概念去理解不同主题的关注度指引。维基收录标准有:通用关注度、书籍、人物、地理特征、数字、几何图形、发明研究、物质性质表、交通、组识与公司,这十多把尺子是同等的,条目只要符合其中一个标准就可以收录。例如,根据地理特征收录标准WP:NGEO,一个地方只要有人住,就可以收录,而无须符合《通用关注度》;《通用关注度》以外的十多个收录标准并非要对相关的主题增加额外的要求,而是这十多个收录标准都是独立和同等的。--虫虫飞♡♡→♡℃留言 2021年7月1日 (四) 15:37 (UTC)
只有“通用关注度指引”一节的内容才是通用关注度指引,我以为这是常识。否则,难道WP:NNCWP:FAILN也不适用于其他专题关注度指引吗?另外,我不知道你为什么要将你的发言里的GNG改为通用关注度指引,因为两者完全等义。--【和平至上】💬 2021年7月3日 (六) 16:01 (UTC)
有些用户确实只看通用关注度指引,但作为巡查员,您应该所有专题关注度指引也要看一下。此外,WP:NNCWP:FAILN也是后来才加进通用关注度指引,前者是内容方针的简介,后者其实是删除方针的撮要,这两段只是方便用户了解一下还有其他方针要注意,而且不能只看这两个章节,详情要看可供查证、删除、非原创等方针。此外,GNG 只是一个通用关注度指引的一个章节捷径,方便用户引用,因为大家都习惯了,我才用GNG来表述。而且要注意,您不能在一个指引去约束另一个指引,每个指引都是独立的。WP:NNCWP:FAILN只能约束GNG,不能约束专题关注度指引,但WP:NNCWP:FAILN的原方针,如可供查证、删除、非原创等方针则适用于所有专题关注度指引。--虫虫飞♡♡→♡℃留言 2021年7月3日 (六) 16:18 (UTC)
我的理解:WP:N≠《通用关注度》,WP:NWP:GNG和“专题关注度指引”组成,WP:N包含WP:NRVEWP:NNCWP:FAILN等内容。 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月4日 (日) 02:00 (UTC)
WP:N是《通用关注度》,就是有人加了这两个章节,才有这个误解。WP:NNCWP:FAILN,前者是内容方针的简介,后者其实是删除方针的撮要,而且不能只看这两个章节,详情要看可供查证、删除、非原创等方针。WP:N不包含“专题关注度指引”,例如学者关主度指引,您在WP:N哪里看到有论文引用量来证明关注度?而且英维的学者关主度指引已经明确说了由于GNG的限制,无法有效证明学者的关注度,才有学者关注度的出现。此外,BIO在2004年已经有了, WP:N要2007年才有,一个后出的 WP:N怎么会包含之前和之后所有专题关注度指引,而且各关注度指引的收录条件完全不同,GNG是方便,但不能只看GNG。WP:N是有很多章节,但都只是与GNG有关;学者关注度、BIO等也有不同章节,但也与其他关注度指引无关,您也不能用一个指引去约束另一个指引。--虫虫飞♡♡→♡℃留言 2021年7月4日 (日) 02:38 (UTC)
WP:N不是《通用关注度》!WP:N不是《通用关注度》!WP:N不是《通用关注度》!请容许我强调这点,并且不要再曲解指引!WP:N的引言已经明言“如果某一主题符合下述的通用关注度指引,那么我们便可认为该主题的受关注程度满足创立条目的要求。此外,如果某一主题符合任何一项专题关注度指引之标准,则其同样可视为具备关注度。”,而且删除方针根本就没有讲过关注度不足的处理方式,何来“WP:FAILN是删除方针的撮要”,除了WP:N之外根本就没有其他的方针或者指引页面有讲过关注度不足的处理方式,你的意思是不是以“专题关注度指引”为准的条目全部都不适用于这个删除流程?我恳请你不要再乱解释方针!否则我真的要质疑你作为管理员解释方针及指引的能力。--【和平至上】💬 2021年7月8日 (四) 18:33 (UTC)
  • 首先,请您先保持基本的文明和礼仪,而且讨论时不要太激动,删除方针的删除原因第七条已经明确说了关注度不足的的处理方法:“彻底尝试后仍无法由可靠来源查证的条目,尤其是不符合任何关注度指引(《通用关注度指引》或者其它专题关注度指引),且已经挂相应模板30天的条目”,而且其他段落也已经详述了处理方法,虽然用语不完全一样。此外,WP:FAILN是后期才加进通用关注度指引的,英维那边就没WP:FAILN。--虫虫飞♡♡→♡℃留言 2021年7月8日 (四) 23:34 (UTC)
    你自己看一看WP:GNG到底是连到WP:N全文还是只有其中一节。WP:N的标题是“维基百科:关注度”,而且删除方针也没有写要提报到WP:NP;那我想问问你,WP:NNC的内容是不是不适用于以“专题关注度指引”为准的条目?我不明白你到底在坚持写什么,WP:N里除了WP:GNG一节之外适用于所有条目,好吗?难道以WP:NGEO的关注度就可以无限延伸?我希望找其他管理员解释这一个本来应该是常识的争论。--【和平至上】💬 2021年7月14日 (三) 11:30 (UTC)
  • 我觉得WP:NNC是废话,可以删去,因为条目内容怎样写不应看WP:NNC,而是看格式指引,因为WP:NNC里就加了一个格式指引的链接,所以真正限制不同专题关注度指引的是格式指引、可供查证、非原创研究等方针,而不是通用关注度指引里的一个小章节WP:NNC。此外,您的想法就像等于说WP:NBIOWP:BIO,但其实都是人物关注度指引的不同章节。--虫虫飞♡♡→♡℃留言 2021年7月14日 (三) 11:39 (UTC)
(+)支持 -- I'm Lewix.|I'm sorry for your loss.| 2021年7月2日 (五) 22:48 (UTC)

新提议

第三项改为:该书已改编为电影、电视剧、网络剧,相应电影、电视剧、网络剧有关注度。

很好地解决了对改编剧集放映于质量较低的播放平台的疑虑,但是变相调高了书籍关注度的门槛,因此还需更多讨论。Fire Ice 2021年7月3日 (六) 15:56 (UTC)

其实我有一个疑问,为什么我们要假定相应电影、电视剧、网络剧条目有关注度就代表原作具有关注度?如果一本书籍的条目里面只有改编作品的内容有二手可靠来源支持(否则便可以直接使用GNG),而改编作品本身已经有另一个条目,那么这个原作书籍的条目的存在意义是什么?--【和平至上】💬 2021年7月3日 (六) 16:10 (UTC)
介绍原作的角色和剧情。原作的人设和情节可能和改编作品不一样。Fire Ice 2021年7月4日 (日) 16:55 (UTC)
关注度指引的意义是寻求一个证明主题有关注度的证据,书籍当然要有关注度才有人去改编电影或电视剧,这可能比GNG更能证明关注度。--虫虫飞♡♡→♡℃留言 2021年7月3日 (六) 16:23 (UTC)
个人认为重点根本不是在书籍引申出来作品的关注度,它引申出来作品关注度如何,也不关原本书籍的关注度事。最重要的是有机构愿意把这书籍改编成 电影,电视剧,网络剧 等需要极大投入的作品,就证明了原本书籍一定有一定关注度而令到改编它的决定是可取的。这便是我强调引申出来作品的质素的原因,因为这样才能保证当初引申作品的制作时的投入和严谨度,反向证明当初原书籍的关注度。不然的话像民间影片这些制作门槛那么低的东西可不证明当初书籍是有关注度,而可能只是有个别小众狂热粉丝也能去改编吧。 Iridium(IX)留言) 2021年7月4日 (日) 04:01 (UTC)
(!)意见:仔细想了一下,建议删去“条目有关注度”,因为有关注度,不一定有条目。--虫虫飞♡♡→♡℃留言 2021年7月4日 (日) 04:10 (UTC)
根据WP:7days,提案公示七天。--虫虫飞♡♡→♡℃留言 2021年7月17日 (六) 04:39 (UTC)
考虑到未有人有效回应SIridiuM28的意见,暂时撤回公示。--虫虫飞♡♡→♡℃留言 2021年7月19日 (一) 04:42 (UTC)

1E需澄清是否适用于死者

命名常规(方针) § 括号的使用

Bus FollowerIokseng、与我就以下条目的命名在 User_talk:Iokseng#错误的重定向衍生的问题 展开了一场讨论。

Iokseng 君称:“不论您觉得这些括号的使用是不是消歧义,它们在维基百科的定义就是消歧义”。然而,上述条目没有相同或相似名称的条目,因此“没有消歧义命名的必要”,不应使用括号。

我认为,因为上述条目没有歧义,所以没有消歧义的问题,使用括号也与消歧义无关。法无禁者即可为,方针与指引没有禁止,亦即,允许在除了消歧义外的情况使用括号。

根据 Bus 君的调查,上述条目使用括号,是数年前通过讨论形成的共识决定的、命名常规允许的、例外的括号的使用。之所以说“例外”,是因为命名常规仅对“用作消歧义的括号”进行了规定,没有对其他情况使用的括号作规定。没有规定、没有禁止,法无禁者即可为。根据 Bus 君的调查,数年前关于上述条目命名的讨论形成的共识为,在上述条目的标题中,在括号内标明公车线路的停驶年份,以表明该线路已停驶。

一个类似的例子是 1990年广州白云机场劫机相撞事件。该事件的常用名称为“10·2空难”,不包含年份 1990 年,亦不包含地点“广州白云机场”或对事件简单的描述“劫机相撞”。“1990年广州白云机场劫机相撞事件”这个名称,虽然不符合命名常规的“使用常用名称”原则,但是符合命名常规的“易于识别”原则,方便读者“识别条目主题”。

我认为,“台中市公车16路 (2016年)”等称呼同样符合“易于识别”原则。在括号内加上年份,能够明确条目主题为已停驶的公车路线,方便读者识别,不至于误解条目主题为仍在运行中的路线。

本互助客栈页面要求“提出或讨论维基百科政策、方针”。本讨论目的虽然并非提议修改命名常规(方针),但是讨论命名常规及对命名常规的理解,且可能引发关于补充或修改命名常规的讨论。

Iokseng 君于 2021年7月13日 (二) 00:23 (UTC) 亦要求称:“应该要提到WP:VPP让所有用户有机会讨论,并将结果公告后写进命名规范中。这是唯一的办法”。

谢谢!

XComhghall留言) 2021年7月13日 (二) 02:27 (UTC)

  • 我对于公交路线是否要加括号的看法是:如果该线路号之后被复用,则需要对之前用过该线路号的线路消歧义,现有的线路则作为主页面(“主从消歧义”)。对于撤销后线路名称没有复用的,未见消歧义必要。--DreamerBlue留言) 2021年7月13日 (二) 03:39 (UTC)
  • 括号会使用年份通常都是表示“开始”而非“结束”,例如小岛制作小岛制作 (2015年),我还是第一次看到使用停驶年分当作消歧义。 --Loving You Is A Losing Game 2021年7月13日 (二) 05:11 (UTC)
识别是否仍在运行中的路线理应是在正文,而不是标题。使用这种标题违反了使用常用名称的要求。除非是有号码重用而需要消歧义,不过这一般都是以开办日期作消歧义。--【和平至上】💬 2021年7月13日 (二) 12:52 (UTC)
  • 岔开话题:这些条目要不要送去AFD?Itcfangye留言) 2021年7月13日 (二) 21:49 (UTC)
命名常规已经明确了半角圆括后缀是用于消歧义,也没有留意到其他使用的讨论,所以这样的命名会给人认为是消歧义的作用。因此,我认为除非因为消歧义,不应该这样使用半角圆括后缀写法,除非能找到相关的讨论。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年7月14日 (三) 02:25 (UTC)
就算是Category_talk:台中市公车路线#废线条目名称,一来讨论得不太彻底,二来现有命名规则对此用法是有限制的,所以除非符合规则所要求的,否则不太认同提出的用法。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年7月14日 (三) 08:43 (UTC)
应该这样说:如果存在两个条目名称相同都是“XXX”,则两个页面都需要进行消歧义处理,格式为“XXX (YYY)”,一般情况这两个因素都是充分必要的。所以如果出现“XXX (YYY)”,但实际上并不存在两个同为“XXX”的事物条目,也就是不需要消歧义处理,则不应该使用“XXX (YYY)”。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年7月14日 (三) 08:57 (UTC)
@和平至上君:我在上文举了 1990年广州白云机场劫机相撞事件的例子。该条目同样不符合命名常规的“使用常用名称”原则。该事件的常用名称为“10·2空难”,不包含年份 1990 年,亦不包含地点“广州白云机场”或对事件简单的描述“劫机相撞”。其他常用名称包括“广州10.2空难”、““10.2”劫机大空难”、“白云机场“10·2”特大空难”、“1990年厦航客机空难”、“1990年广州白云机场“10·2”空难”、“1990年10·2广州白云机场空难”。条目首句列出的常用名称“广州白云机场劫机相撞事件”不包括年份。
条目使用的名称“1990年广州白云机场劫机相撞事件”,虽然不符合命名常规的“使用常用名称”原则:

一般情况下,常用的名称也是较为简短的,可以避免条目名称过于冗长

但是符合命名常规的“易于识别”原则,方便读者“识别条目主题”。
我认为,“台中市公车16路 (2016年)”等称呼同理,虽然不免冗长,但是符合“易于识别”原则。在括号内加上年份,能够明确条目主题为已停驶的公车路线,方便读者识别,不至于误解条目主题为仍在运行中的路线。
@DreamerBlueMilkypine 君:目前多数的意见看上去是反对使用括号标明停驶年份。我的想法是,“台中市公车16路 (2016年)”等条目名使用括号根本不是消歧义,仅是出于命名常规的“易于识别”原则:在括号内加上年份,能够明确条目主题为已停驶的公车路线,方便读者识别,不至于误解条目主题为仍在运行中的路线。
先前的讨论在Category_talk:台中市公车路线#废线条目名称
@Sakamotosan 君:了解您的意见了。感谢您参与讨论。
关于“这样的命名会给人认为是消歧义的作用”,我理解维百编者可能会有这样的感觉、印象。我的想法是,对于读者而言,只是出于命名常规的“易于识别”原则,明确条目主题,与仍在运行中的公交线路区分而已。
关于“现有命名规则对此用法是有限制的”,我认为命名常规仅对“用作消歧义的括号”进行了规定,没有对其他情况使用的括号作规定。没有规定,没有禁止,亦没有限制,所以法无禁者即可为。
关于先前的讨论,固然讨论并不长,“不太彻底”,但参与讨论的 5 位编者:
辛庚己戊Neillin1202UgnJimmy40326福克大叔
均赞成停驶公交路线的条目名称中加入停驶时间。其中最后发言的三位编者明确表示支持仅标注年份,不标注月份或日期,其他二位编者或许是默许。
台中市公车22路确有分歧义的必要。台中客运、仁友客运均运营过同名的不同路线。我将作出分歧义处理。
谢谢! — XComhghall留言) 2021年7月15日 (四) 03:12 (UTC)
若考虑命名易于识别的原则,是否可以将“台中市公车16路 (2016年)”改为“台中市公车16路 (2016年停驶)”?毕竟对不常编辑公车条目的人而言, 看到年份不太容易联想到是停驶的年份。--Wolfch (留言) 2021年7月15日 (四) 03:44 (UTC)
作为消歧义的话,可以这样选择,但既然没有同名消歧义的需要,用更简短的名字,在可区分事物的情况,应该更好。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年7月15日 (四) 03:50 (UTC)
一般情况下,规则是以适配编辑的判断而非读者的判断,或者说读者的判断可能有错误的,不可依靠。“易于标识”仅限于原名(也就是我提及例子的“XXX”的部分),半圆括后缀写法一直是作为同名事物消歧义命名的处理方法,也没有允许过其他的使用,除非引用IAR,不过上面也提及到这些额外信息可以在正文中体现,因为这种另类用法会影响编辑的判断(也就是如之前处理的Iokseng所说,会认为存在事物同名的消歧义情况,但实际上并没有)。仅在一个分类讨论页(分类讨论页一般是冷门的,除非其作用仅限于该分类的页面,不包括归于该分类的页面)的“共识”是不充分,这是影响整个维基项目的页面命名规则,建议扩大讨论(例如方针版),可以引述该次讨论然后作为命名规则针对特定题材条目的命名规则来处理。不过,我不太看好这个讨论。免礼。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年7月15日 (四) 03:48 (UTC)
另,关于常用名称,另参看下面还有关于使用全称的说明。也就是为什么使用美国而不是美利坚合众国英国而不是大不列颠及北爱尔兰联合王国IBM而不是国际商业机器公司1990年广州白云机场劫机相撞事件的例子可能不太恰当?——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年7月15日 (四) 03:54 (UTC)
@Wolfch:多谢您的建议。
@Sakamotosan:亦多谢您的建议。
“没有允许过其他的使用”,准确地说是没有规定,没有禁止过其他的使用,所以实际上是允许其他的使用(当然讨论、共识也很重要)。如果“没有允许就是禁止”,是不是有点有罪推定举证责任倒置了?“法无禁止即可为”是引用中国大陆的法律思想,但我想这点是世界各国还有这里的大家都有共识的。另外,如果说“没有允许过”的话,“‘易于标识’仅限于原名(也就是我提及例子的‘XXX’的部分)”这种话,也是命名常规没有允许过的解释。可见您也是 liberally 自由地理解方针,只不过我是以方针为最低标准,您却把方针的标准又拔高了许多,禁止了方针允许、没有禁止的行为。
分类讨论页的讨论自然是只影响该分类的,不会“影响整个维基项目的页面命名规则”。如同同样没有共识,方针暂时没有规定、没有禁止的全形括号一样,个别情况个别讨论,我认为是再恰当不过的。讨论这个个别情况,从来就没有将最后达成共识的决定施加于全部情况的意图。
“建议扩大讨论(例如方针版)”我们现在不就是在方针版吗?
  1. 使用全称是惯例。易于识别是原则。根据命名常规,原则高于惯例。
  2. “1990年广州白云机场劫机相撞事件”不是全称(官方名称)。上文引述的常用名称是中国大陆官方的名称。“1990年广州白云机场劫机相撞事件”更冗长,但实际上是维基百科编者采纳或创造的非常用名称、非全称、非官方名称。
  3. “美国”易于识别,“英国”易于识别,'IBM' 易于识别,“10·2空难”(全称,官方名称)不易于识别,所以维基百科编者创造了一个易于识别的非常用名称、非全称、非官方名称:“1990年广州白云机场劫机相撞事件”。
  4. 同理,“台中市公车16路 (2016年)”、“台中市公车16路 (2016年停驶)”易于识别,“台中市公车16路”不免使人与其他运行中的公教线路混淆、分辨不清。
百科全书自然是为读者写的。我们编辑的原则、规则应当是为了读者获取、理解信息更加方便、快捷。WP:NOTPAPER 有提到这点。但就像市场中的供需双方一样,不可能只有读者,没有编者,所以 WP:NOT 开篇就表明了,我们的社群是“对创建和使用高品质百科全书感兴趣的人们”,也就是,编者及读者。我们编辑的原则、规则同样要考虑到使编者编辑、维护维基百科更加便捷,但是不可能只考虑编者的感受,不考虑读者的观感。Wikipedia:IP用户都是人#我们的读者也是IP用户这篇论述就表达了我们对读者的关心。
谢谢各位参与讨论! — XComhghall留言) 2021年7月15日 (四) 13:26 (UTC)
@XComhghall: 方针规定了半角圆括后缀写法就是用于处理同名消歧义的问题,也就是已经有规定可依,而且这对于大部分的编辑而言,“半角圆括后缀写法就是用于处理同名消歧义”就是充分必要的,也就是如果见到“半角圆括后缀写法”,就会认为存在了同名消歧义的情况,既然没有这种情况的话,那就不应该这样写,这不是某些编辑自己认为“这不是消歧义”所能解决的,而且如果不是为了消歧义,将这些额外状态记录在条目名称中是没必要的,因为这都可以在正文中体现,而且你如何知道读者或编者一定是按着你设想的这些记录在条目名称中“状态”的是什么意思?而且易于识别的核心应该在于事物在名字上的区分,而不是事物内的特定属性的状态。另外,即使是个别专题确定的讨论所确立的“共识”,也应该在命名常规中体现(也方便其他编辑留意到),如其下面大量针对特定专题的命名规则的适配,管理员也不可能全部了解这些藏在角落的讨论结论。所以我认为按照现在WP:命名常规的指引下,管理员的处理是合适的,当然共识是可以改变,但至少在一个更普遍的场合,因为这对于命名常规方针有着明显的影响。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年7月16日 (五) 00:42 (UTC)
@cwek:举个例子:Wikipedia:命名常规 (人名),对比:Wikipedia:格式手册/两岸四地用语
“半角圆括后缀写法就是用于处理同名消歧义的问题”、半角括号只能用于同名消歧义,真的是毫无根据。方针从来没有说过这种话。
所有猫都是动物,但你不能反过来说所有动物都是猫。方针规定所有消歧义都用半角括号处理,但你不能反过来说所有半角括号都是消歧义。方针从来没有规定过后者,你不能凭空创造方针没说过的话啊。

用作消歧义的括号,请使用半形括号“(”“)”作为标题中的括号,括号前有一个半形空格。
  ——Wikipedia:命名常规#括号的使用

不是 vice versa:“半形括号,请用作消歧义”。

我从来没说过这话。
  ——方针

我现在真的是无语了。我看我也是说服不了您。再说下去,礼貌、文明我做得到,但我们俩就这样鸡同鸭讲、互不让步、僵死在这里,我不得郁闷到一口老血吐出来?我们还是别白费功夫 go in circles 了。我直接撰写、准备、开始意见调查,确认共识好了。您也别跟我互相伤害了,真的伤不起。意见调查完了大家各回各家,各写各条目好不好?祝
大家所有人都编安! — XComhghall留言) 2021年7月16日 (五) 01:31 (UTC)
Wikipedia:命名常规 (人名)等类似的正正就是因为为了区分“Wikipedia:命名常规 ”同名而作为消歧义的用法,当然Wikipedia:格式手册等各分内容也是通过讨论确立使用子页面的方法区分内容。对于两个事项(使用半角圆括后缀 和 消歧义的作用)的关系,的确方针上并非明言,但也确定如果作为同名的消歧义需要,要使用半角圆括后缀写法(作为充分条件),其长期使用也让相当一部分编者确认了其也作为必要条件,所以也有一些编者会认为这样用法不恰当。我不反对为此重新确立为普遍的共识,作为一种特例处理,如果能通过的话。我认为本质上你的想法(使用括号不代表是因为消歧义)和其他编者(使用括号是因为存在消歧义,或者按照方针的规定,因为要消歧义,所以要这样使用括号)存在出入吧。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年7月16日 (五) 01:46 (UTC)
@XComhghall:,不过我的意见是:同名消歧义的括号使用是技术上必须的,也确立了如此处理的方式。但为了彰显事物内的特性并且非消歧义的需要,既不必要,而且考虑本社群的与现实的交杂的氛围,特例一开,可能带来的问题或争议可能超出技术所需的必要性。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年7月16日 (五) 01:58 (UTC)

消歧义是同名的不同条目,比如两个同名的台风。Wikipedia:命名常规 (人名)却不是一个新的、不同的条目。维基百科只有一个命名方针,只有一个格式手册。Wikipedia:命名常规 (人名) 在我看来实际上是使用括号作为子页面,而非消歧义。当然我理解或许您有不同的看法。

我以为,同名消歧义之所以用半角括号,是因为技术允许半角括号用于标题,是因为标题用半角括号,没有“花括号({ })、方括号([ ])、尖括号(< >)”那样的技术限制,所以我会觉得,方针没有禁止其他情况使用半角括号,那讨论达成共识,允许其他情况使用半角括号了,就可以使用半角括号了。

上面 Lopullinen 君的话我借用一下:“读者感受、编者维护”。加半角括号是为了易于识别,一目了然。读者一看条目名称就知道了:哦,是过去的公交线路,编者也是啊。维基百科无非读者、编者。对两者都有利,自然是有百利尔无一害了。不知道技术上会有什么限制。 — XComhghall留言) 2021年7月16日 (五) 02:24 (UTC)

新添一个例子:舒尔德 (匈牙利)。 — XComhghall留言) 2021年7月16日 (五) 02:33 (UTC)

Wikipedia:命名常规是命名的总方针,然后不同时期引入针对不同专题的命名规则,保留了同一个事物名“Wikipedia:命名常规”,但为了区别,所以才以消歧义的方式处理,如果你检查格式手册的子页面的历史和重定向,实际上格式手册的子页面也是使用过“Wikipedia:格式手册”的同名并以消歧义的方式区分页面。还你一个对应例子舒尔德 (德国)。应该说“需要确立一个普遍的命名共识,用于非消歧义的情况下针对台湾公交线路使用本身特性加圆括来作为其命名”。“易于识别”是为了两个事物的命名差异,而非事物本身属性。对于一条公交线路而言,“台中市公车16路”已经足够易于识别,至于更具体的属性例如几时开办或废除,那应该是正文的内容,除非出现多个同名不同事物“台中市公车16路”,就可以并应该按照消歧义的方式区分。读者是蠢货,编者不要跟着变蠢货。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年7月16日 (五) 04:39 (UTC)
光是“ (2016年)”这段就不易于辨识= =,前面许多言论都有提到“台中市公车16路 (2016年)”对大部分人来讲,是“台中市公车16路 (2016年创立的路线)”而非“台中市公车16路 (2016年停驶的路线)”,况且使用条目名称来阐述已停驶的事实,采用斯洛伐克共和国_(1939年-1945年)的做法还比较合乎常理。如果阁下不满意,现在也可以开民调调查大家怎么看待“ (2016年)”表示的含意 --Loving You Is A Losing Game 2021年7月15日 (四) 13:01 (UTC)

个别专题内部所达成的共识,不应被显无共识的全站性讨论凌驾。

——Eric Liu,Wikipedia:互助客栈/方针#Wikipedia:命名常规#书名号修改,2021年7月13日 (二) 08:28 (UTC)

目前讨论貌似没有什么新观点、新意见了,我打算就按 Milkypine 的意见,撰写、准备、开始意见调查,确认共识好了。 — XComhghall留言) 2021年7月15日 (四) 23:39 (UTC)


我真的非常感谢XComhghall发起了问题及大家的踊跃讨论,我是本次文章最一开始的发起者,很抱歉我在最后才发言,但我强烈建议大家都能先看完以下两个讨论再请发言
  1. 分类讨论:台中市公车路线#废线条目名称
  2. 用户讨论:Iokseng#错误的重定向衍生的问题
另请见我的讨论
为什么我会这样说?!因为看的出来有某自豪的‘资深’编者只看问题就开始他的无俚头辩说!!!


首先,我讲到快烂掉了,我先重申“这不是消歧义”而是‘条目命名问题’,许多人根本搞错重点以【消歧义】等理由“反对”,不知道在消什么消?
请大家先同意此观点:《维基百科成立的目的是为了大家方便查询》
既然大家同意此观点,那就要从标题开始讨论,请注意,若您没有提供任何有效解决方案就不须再讨论了!
讲卡歹听ㄝ,你如果没了解这件事来龙去脉就不要来干涉!那关你什么事?你平常也不会关注相关条目...然后只会讲道理、反对也不会提供具体改进意见!看了就赌烂!我的问题还是没有解决啊!!干脆此讨论页关掉就好了...
你看!这件事情的引发者(就是首位恶意修改条目名称还反控诉我不当移动的Iokseng)及封禁我的虫虫飞没有在这里讲半句话;也不讨论啦吼!
有人就开始说命名规则巴拉巴拉什么的,我就无言,也不想再回复:这个圈的人早于2013年就有共识知道说条目名称写法,这也没违法,为什么就一定要破坏呢?吃饱太闲?


敝请真正有兴趣的人到这里发表您的意见,当然还是感谢大家移拨时间踊跃讨论!


敬祝 万事顺利 -- Bus Follower留言) 2021年7月16日 (五) 09:29 (UTC)


备注:为何我会态度显得些许不佳呢?因为这些问题几乎都是重复的!基本上以上的问题都于2013年有相同或类似的发言,详见第一个讨论。--Bus Follower留言) 2021年7月16日 (五) 09:40 (UTC)
关于“ (2016年)”表达的还易,我已经表达意见就不继续讲,改谈其他内容。关于半括号的使用,大多伴随着消歧义,例如Wikipedia:命名常规#括号的使用写到“用作消歧义的括号,请使用半形括号“(”“)”作为标题中的括号,括号前有一个半形空格。”、Wikipedia:消歧义“如果那些定义拥有另外的名称,或是更完整而又同等清晰的名称,我们就可使用它们。若否,则我们可以在原来名称后面加入一对半形括号,将一个消歧义词放在括号中。”以及Wikipedia:格式手册/标点符号#括号当中的“消歧义页面名称的消歧义部分必须使用半形小括号包裹。”,虽说没有规定半括号不能用于其他地方,但有不少人秉持“半括号=消歧义”表示不该使用半括号,现在想想Wikipedia:命名常规_(音乐)#括号能通过真的是奇迹
接着是所谓的“这个圈的人早于2013年就有共识知道说条目名称写法”,我讲过分点,没有拿到互煮讨论的共识真的就是小圈圈自嗨。前面举出Eric Liu大的意见(话说那个网址我点开是首页)“个别专题内部所达成的共识,不应被显无共识的全站性讨论凌驾。”,这段内容是否有方针保障?就算有,为何WikiProject:巴士看不到,需要深挖历史资料?我建议各位趁这机会好好完善巴士专题 --Loving You Is A Losing Game 2021年7月16日 (五) 14:14 (UTC)
可能通过指引时,对于“遵循事物名称原文”这个观点上从来没人质疑过。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年7月17日 (六) 10:01 (UTC)
Milkypine
本人已收到您的建议,将会把握机会前往该页面讨论,多谢指教! -- Bus Follower留言) 2021年7月17日 (六) 08:40 (UTC)
关于本站点的目标是什么,请看Wikipedia:关于。解决方案,已经有提过,不涉及因为同名消歧义的信息,放到正文就可以了。某个偏僻分类页面上的讨论共识和多个方针指引确立的共识那个更需要普遍的跟从,这个还需要解释?涉及命名结构的问题是一个广泛性的问题,一般建议在方针版过一次,好让大部分编者知道存在这个例子,要不然即使你认为“这不是消歧义”,但对于大部分秉持“半括号=消歧义”的其他编者而言,“这就是消歧义”。——Sakamotosan路过围观杯弓蛇影 | 避免做作,免敬 2021年7月17日 (六) 09:54 (UTC)


cwek及其他人:
已有正式讨论,请有兴趣的人移驾至此,毋需再于此讨论,感谢配合! -- Bus Follower留言) 2021年7月17日 (六) 10:15 (UTC)

提议修改关注度_(人物)

现行条文

音乐人,作品集卖出不少于5000张。

提议条文

音乐人,作品集卖出不少于5000张,或任一网站的粉丝人数达50000人。

理据:现代网络发达,已经不再是以实体贩卖为主,进入数位时代,甚至有些作品不再贩卖,音乐人改以粉丝自主捐献或受邀表演作为收入来源,故新生代歌手已经改以粉丝人数衡量知名度,然而粉丝人数5000关注度仍可能低落,这是因为不需要花任何一毛钱就能成为粉丝,所以需要到50000才有一定的知名度;另外,作品集卖出不少于5000张规则保留,适用全盛时期在网络发达前的歌手(例如:欧得洋陈庆祥李建复等)--天蓬大元帅-会客 阅读机器翻译放松一下 2021年7月14日 (三) 01:58 (UTC)

(+)支持:能证明关注度的标准确实很多。--虫虫飞♡♡→♡℃留言 2021年7月14日 (三) 02:17 (UTC)
(!)意见:5000张的话门槛或许太低,若以数位或串流来说现在出现许多刷榜/成绩的行为,因以至少两张作品为门槛,当然这只是一个观点,可以再修正。另外提一点,音乐人可以参考该艺人母国的主流大型榜单会记录榜单(例:RIAA认证)现在认证已将实体、数位、串流做合并计算,能以此为依据。立ち直り中 2021年7月14日 (三) 06:27 (UTC)
5000张按不同国家来说可以是很多或很少,建议更改为取得金唱片或以上的唱片认证(不论任何国家或地区)。粉丝数目可以刷,有钱的话刷到五万人没有什么难度,按不同国家的人口规模也会存在极大差异,任一网站亦过于随便,因此不太建议添加这种过于浮动的数据作为指标,如果要添加粉丝数目作为标准的话,至少应该限制于在IG、Twitter等的SNS上取得官方认证的账户,并且以世界人口(78亿)或当地人口为基准,达到某个比例(例如1%的话就是780万)的话可以考虑。—AT 2021年7月14日 (三) 06:49 (UTC)
可是人口数很多的国家用比例就不妥,国土过大,很多地方著名歌手无法收录就很可惜。天蓬大元帅-会客 阅读机器翻译放松一下 2021年7月14日 (三) 11:29 (UTC)
我觉得这个很可惜可以通过GNG来弥补,都不满足的话就没什么好可惜的了。--AT 2021年7月14日 (三) 12:42 (UTC)
请问订出这样的数字是以什么为根据的?—— Eric Liu 创造は生命(留言留名学生会LEP 2021年7月14日 (三) 10:31 (UTC)
应该是靠经验吧,藉藉无名的人,可能一张唱片也卖不出,通常是一些著名的歌星才可以吧。--虫虫飞♡♡→♡℃留言 2021年7月14日 (三) 10:46 (UTC)
(-)反对:50000粉丝的门槛太低。--【和平至上】💬 2021年7月14日 (三) 11:22 (UTC)
(-)反对唱片认证好歹会与时俱进,粉丝人数你要用什么当基准?除非你打算让粉丝人数比照串流认证,话说关注度 (人物)不行还有Wikipedia:关注度 (音乐)。 --Loving You Is A Losing Game 2021年7月14日 (三) 11:51 (UTC)
(-)反对:同意AT。地方上的音乐人,也会有地方上的报纸来报导。--Temp3600留言) 2021年7月14日 (三) 15:03 (UTC)
5000张又是根据什么标准定的?Fire Ice 2021年7月16日 (五) 14:09 (UTC)
Fire-and-Ice可惜当事人Peterpan不在,没有办法问。5000张的根据我猜是对应音乐唱片销售认证列表当中最低的销售认证(中文版一段时间没有更新,建议看英文版List of music recording certifications英语List of music recording certifications),不过5000并不是全球通用的标准,例如马来西亚达到5000就有黄金认证,但对日本来说这只是他们的1/20。除了各国标准不依,同一国家也会有不同标准,例如比利时对国内最低标准为10000,外国人则是15000。这段内容我建议直接引导到Wikipedia:关注度 (音乐),毕竟这卖5000张没有国家认证,艺人或公司都有机会自己洗出来,我们都禁止采用其他用户编辑的内容当来源了,关注度这边是否也该升级一下 --Loving You Is A Losing Game 2021年7月21日 (三) 15:22 (UTC)
  • 由于现今粉丝数量可能会含有水分,故难以成为衡量标准。但同意保留原来的“作品集卖出不少于5000张”,因为有些独立音乐人没有公司帮忙对接,可能会出现一种情况:即拥有代表作和知名度,但没有媒体进行报导。--DavidHuai1999Talk 2021年7月18日 (日) 00:38 (UTC)

(续)条目标题、内文及重定向页标题中对SARS-CoV-2的变种的称呼

最近WHO打算以希腊字母命名SARS-CoV-2的变种(希腊字母用尽后就会启用新的命名系统),不过同一声明中WHO也表示现时GISAID、Nextstrain和Pango谱系注册编号可以继续用于科学研究中。因此,我建议追加以下修订,以切合WHO对变种病毒命名的安排与考量:

现行条文

条目标题中对SARS-CoV-2的变种的称呼 条目标题中如须提及SARS-CoV-2的变种,除非这次提及被包含在专有名词内,或该SARS-CoV-2的变种的PANGO谱系注册编号并不存在,否则应使用“〔PANGO谱系注册编号〕谱系”格式称呼之。即使该SARS-CoV-2的变种的PANGO谱系注册编号不存在,除非这次提及被包含在专有名词内,否则仍不应使用不准确且可能有歧义的“〔地名〕〔变异重数〕(变种)〔病名/病毒名〕病毒(株)”等类近格式称呼之。

条目内文中对SARS-CoV-2的变种的称呼 条目内文中如须提及SARS-CoV-2的变种,除非有提及其他称呼的必要,该SARS-CoV-2的变种的PANGO谱系注册编号并不存在,否则应使用“〔PANGO谱系注册编号〕谱系”格式称呼之。条目内文不宜使用不准确且可能有歧义的“〔地名〕〔变异重数〕(变种)〔病名/病毒名〕病毒(株)”等类近格式称呼SARS-CoV-2的变种,若一定要使用“〔地名〕〔变异重数〕(变种)〔病名/病毒名〕病毒(株)”等类近格式称呼,则必须括注宣告其指称对象,且须确保为最低限度的使用。如未有共识支持,手动把SARS-CoV-2的变种的“〔PANGO谱系注册编号〕谱系”格式称呼替换为其他同义词(尤其“〔地名〕〔变异重数〕(变种)〔病名/病毒名〕病毒(株)”等类近格式),将被视同破坏,唯因技术原因、修正笔误或回退破坏等维护性编辑例外。

重定向页标题中对SARS-CoV-2的变种的称呼 重定向页的标题中若出现任何并非使用“〔PANGO谱系注册编号〕谱系”或“〔PANGO谱系注册编号〕”格式的对SARS-CoV-2的变种称呼,只要相关称呼有任何可靠来源使用,该重定向页不应删除,并使用{{COVID-19重定向}}模板予以标记。如该称呼可指代多于一种SARS-CoV-2的变种,该名称则应创建为消歧义页面,或重定向至名称近似且列出多于一种SARS-CoV-2的变种的消歧义页面。

提议条文