跳转到内容

Wikipedia:互助客栈/方针：修订间差异

本页使用了标题或全文手工转换
维基百科，自由的百科全书
以互动方式浏览历史
←上一版本下一版本→
删除的内容 添加的内容
可视化wikitext
蟲蟲飛（留言 | 贡献）
78,870次编辑
无编辑摘要
Antigng（留言 | 贡献）
54,465次编辑
第2,175行： 第2,175行：
::#“基本上您要解釋的東西，方針都已經有記述”并不是事实。以本人引入的第一条解释为例，其指出，“有效介绍”是为了在不进行原创总结的情况下写出一篇基本完整的条目，而非简单定义或只言片语。这里提及了三个概念：[[WP:SYN|原创总结]]、[[WP:NOTDICT|简单定义]]（条目不是词典解释）、[[WP:SUBSTUB|只言片语]]（小小作品），皆是既有条文所不涵盖的。“要解釋的東西，方針都已經有記述”无从谈起。
::#“基本上您要解釋的東西，方針都已經有記述”并不是事实。以本人引入的第一条解释为例，其指出，“有效介绍”是为了在不进行原创总结的情况下写出一篇基本完整的条目，而非简单定义或只言片语。这里提及了三个概念：[[WP:SYN|原创总结]]、[[WP:NOTDICT|简单定义]]（条目不是词典解释）、[[WP:SUBSTUB|只言片语]]（小小作品），皆是既有条文所不涵盖的。“要解釋的東西，方針都已經有記述”无从谈起。
::#“但您改為「廣告」，就和方針精神有差異，而且範圍擴大了”。并非如此。本人没有将“独立于主题实体”、“主题与来源不得存在明显利益冲突”的要求改为广告；而是在解释，考察独立性的目标是要确保依据该等来源写出的条目没有“广告宣传”或“严重偏颇”的问题。这有利于为“关联”和“明显利益冲突”划下相对明确的界限。科学工作者可能因研究其所研究的对象而获得资助；第三方咨询机构可能因为向某一实体提供咨询服务而获取薪酬；政府有介绍本地事物的倾向；某一媒体可能在形式或实质上受到某个团体或政党的控制。但这些都算“关联”、“明显利益冲突”么？不尽然吧。这些情况下就要考量，这种潜在的利益关联是否足以使得其支持的条目内容“严重偏颇”乃至沦为“广告宣传”。
::#“但您改為「廣告」，就和方針精神有差異，而且範圍擴大了”。并非如此。本人没有将“独立于主题实体”、“主题与来源不得存在明显利益冲突”的要求改为广告；而是在解释，考察独立性的目标是要确保依据该等来源写出的条目没有“广告宣传”或“严重偏颇”的问题。这有利于为“关联”和“明显利益冲突”划下相对明确的界限。科学工作者可能因研究其所研究的对象而获得资助；第三方咨询机构可能因为向某一实体提供咨询服务而获取薪酬；政府有介绍本地事物的倾向；某一媒体可能在形式或实质上受到某个团体或政党的控制。但这些都算“关联”、“明显利益冲突”么？不尽然吧。这些情况下就要考量，这种潜在的利益关联是否足以使得其支持的条目内容“严重偏颇”乃至沦为“广告宣传”。
⚫
::#基于以上两条，3/4中的异议没有说服力。--[[User:Antigng|Antigng]]（[[User talk:Antigng|留言]]） 2021年6月28日 (一) 03:14 (UTC)
:{{回應}}
:{{回應}}
#重複的部分，如果您希望再說明，我不反對，但您把「來源獨立於主題」新加了不同的附加條件，令來源更難符合GNG要求，我還是{{反對}}；此外您把「合併」的要求改為以模糊的標準「更好的呈現方式」來增加合併的藉口，我也是{{反對}}
#重複的部分，如果您希望再說明，我不反對，但您把「來源獨立於主題」新加了不同的附加條件，令來源更難符合GNG要求，我還是{{反對}}；此外您把「合併」的要求改為以模糊的標準「更好的呈現方式」來增加合併的藉口，我也是{{反對}}
第2,180行： 第2,181行：
#基於上面兩點，提案的「釋法」目的已經不成立。
#基於上面兩點，提案的「釋法」目的已經不成立。
:以上。--[[User:蟲蟲飛|<span style="color:#E63995;"><big>'''蟲蟲飛♡♡→♡℃'''</big></span>]]※[[User talk:蟲蟲飛|留言]] 2021年6月28日 (一) 03:26 (UTC)
:以上。--[[User:蟲蟲飛|<span style="color:#E63995;"><big>'''蟲蟲飛♡♡→♡℃'''</big></span>]]※[[User talk:蟲蟲飛|留言]] 2021年6月28日 (一) 03:26 (UTC)
::{{question}}，关于合并的问题，请问“在特{{删除条文|定}}{{新增条文|殊}}情况下，{{新增条文|编者亦可能通过讨论达成共识，认定}}{{删除条文|对于}}{{新增条文|某一}}符合关注度准则的主题{{删除条文|亦可能}}{{新增条文|可以}}有更好的呈现方式（例如，合并至母主题的条目中加以介绍）而无需独立成文。关注度准则并不为此等{{删除条文|建设性的编辑行为}}{{新增条文|共识的建立}}设下限制。”这种表述您是否能接受？--[[User:Antigng|Antigng]]（[[User talk:Antigng|留言]]） 2021年6月28日 (一) 03:45 (UTC)
⚫
::#基于以上两条，3/4中的异议没有说服力。--[[User:Antigng|Antigng]]（[[User talk:Antigng|留言]]） 2021年6月28日 (一) 03:14 (UTC)
:{{反對}}現行方針很全面，而且要求已經很高，沒有必要在進一步提高門檻，否則沒有什麽條目了，外面已經有論壇對中維亂刪條目表示不滿。大部分創建者和編輯者對於每個條目都花了很多心血和時間，除非條目有明顯的質量問題，不應該動不動就以關注度來作爲提刪理由。[[User:Sammypan|Sammypan]]（[[User talk:Sammypan|留言]]） 2021年6月27日 (日) 23:31 (UTC)
:{{反對}}現行方針很全面，而且要求已經很高，沒有必要在進一步提高門檻，否則沒有什麽條目了，外面已經有論壇對中維亂刪條目表示不滿。大部分創建者和編輯者對於每個條目都花了很多心血和時間，除非條目有明顯的質量問題，不應該動不動就以關注度來作爲提刪理由。[[User:Sammypan|Sammypan]]（[[User talk:Sammypan|留言]]） 2021年6月27日 (日) 23:31 (UTC)
::{{reply}}{{ping|Sammypan}}，该案未“进一步提高”关注度门槛，而恰恰是在解释关注度门槛与写出的条目可能存在的质量问题之间的关联性。--[[User:Antigng|Antigng]]（[[User talk:Antigng|留言]]） 2021年6月28日 (一) 02:23 (UTC)
::{{reply}}{{ping|Sammypan}}，该案未“进一步提高”关注度门槛，而恰恰是在解释关注度门槛与写出的条目可能存在的质量问题之间的关联性。--[[User:Antigng|Antigng]]（[[User talk:Antigng|留言]]） 2021年6月28日 (一) 02:23 (UTC)

2021年6月28日 (一) 03:45的版本

快捷方式

此页面探讨维基百科的方针与指引。


请注重礼仪、遵守方针与指引，一般问题请至互助客栈其他区或知识问答提出，留言后请务必签名（点击 ）。


发表前请先搜索存档，参考旧讨论中的内容可节省您的时间。

议题最后回应时间为12月24日之前（正在公示者除外）或者该议题已经标记为结束达三日，则该议题会存档至相关讨论页或存档页。讨论存档至相关讨论页后，相关讨论标题则会于一日后存档。跳至本页的：目录 · 底端

公告栏
# 💭 话题 💬 👥 🙋 最新发言 🕒 (UTC+8)
1 关于Wikipedia:避免地域中心#地理，建议增加关于“来”字的论述 54 12 Sanmosa 2024-12-28 22:16
2 修订WP:外文重定向方针与首句MOS:外语名称格式指引，并将他们对应 1 1 Sanmosa 2024-12-27 17:09
3 将WP:格式手册所有方针与论述移动到MOS命名空间，并将MOS命名空间更名为“格式手册” 70 12 Ericliu1912 2025-01-03 16:11
4 提议维基百科:抄袭并入维基百科:不要包含原始资料的副本 61 9 Ericliu1912 2024-12-28 07:29
5 请求社群关注仲裁委员会在管理员的离任讨论中相关的权限问题 1 1 Sanmosa 2024-12-25 21:54
6 公共交通路线条目格式手册的相关讨论 24 5 Ericliu1912 2024-12-28 07:29
7 提议DYK/GA/FA引入cooldown time(或译冷静时间) 197 13 Hotaru Natsumi 2025-01-03 14:18
8 电子游戏与日本动漫条目命名的标点符号使用规定 8 2 Sanmosa 2025-01-01 10:48
9 WP:SW 11 8 屠麟傲血 2025-01-02 19:03
10 重提为可供查证方针与可靠来源指引调整有关用户生成内容的规定 48 10 Abcet10 2024-12-30 23:54
11 可否在标题置入繁体地区词的简体字／简体地区词的繁体字？ 15 3 Sanmosa 2025-01-03 14:55
12 现行用户页指引条文规定的定义问题 18 3 Sanmosa 2024-12-29 22:41
13 关于请辞问题 5 3 Ericliu1912 2024-12-31 18:06
14 紧急修正快速删除O1款 6 3 自由雨日 2025-01-04 06:03
15 WP:RELIST 15 11 Patrickov 2025-01-04 02:04
16 提议将WP:关注度改名 183 53 YFdyh000 2025-01-04 07:08
17 移动时不留重定向、大面积红链与批量清理链入 9 5 Hotaru Natsumi 2025-01-03 16:33
18 “无有效合理固定收录标准”是不是删除导航模板的充分理由？ 1 1 Sanmosa 2025-01-03 19:47
19 提议废除{{深夜动画}}模板 3 3 Sanmosa 2025-01-03 21:51
发言更新图例
  • 最近一小时内
  • 最近一日内
  • 一周内
  • 一个月内
  • 逾一个月
特殊状态
已移动至其他页面
或完成讨论之议题
手动设置
当列表出现异常时，
请先检查设置是否有误

正在广泛征求意见的议题

议题清单

以下讨论需要社群广泛关注：（重新整理） 维基百科格式与命名

Talk:加油！中村同学！！ § 建议更名：“加油！中村同學!!”→“加油！中村同學！！”

“加油！中村同學!!” → “加油！中村同學！！”：! or ！--HeihaHeihaHa-麻瓜了……（留言） 2024年11月21日 (四) 06:30 (UTC)

Talk:南华大学 (湖南) § 建议更名：“南华大学 (湖南省)”→“南华大学 (湖南)”
“南华大学 (湖南省)” → “南华大学 (湖南)”：原本的条目名是“南华大学 (湖南)”，不知道为什么要被移动到“南华大学 (湖南省)”。“湖南”已足够消歧义，且更符合习惯，类似中国地质大学（北京）（这里的括号不是维基百科的消歧义，但能体现常用的命名习惯）。--小林子冲（留言） 2024年11月23日 (六) 22:00 (UTC)
Wikipedia talk:条目命名一致性决议 § 有关日本内阁条目的命名问题

现时，各国家／地区（非国家之独立或高度自治政治实体）内阁条目的命名格式一般为“第X次某某某内阁”，如第二次苏贞昌内阁（台湾）、第二次约翰逊内阁（英国）、第四次默克尔内阁（德国）等，由此可见“第X次某某某内阁”是各国家／地区（非国家之独立或高度自治政治实体）内阁条目的通用命名格式，而且也符合中文的使用惯例。然而，日本内阁条目的命名在2022年10月6日被TKsdik8900由“第X次某某某内阁”批量移动至“第X届某某某内阁”，我认为这种表达方式不合中文的使用惯例（尤其是他把“第X次改组”也改成“第X届改组”的举动完全有悖于中文文法），而且在内阁条目的命名一般通用“第X次某某某内阁”的格式的情况下，此举也有悖于条目命名一致性的要求。因此，我认为中文维基百科现有的日本内阁条目的命名应该批量移回或移至“第X次某某某内阁”格式的名称，此外条目名称带“第X届改组”字样者亦应改回“第X次改组”。Sanmosa 新朝雅政 2024年12月4日 (三) 14:09 (UTC)

Talk:亨利·比索 § 有关为非汉字文化圈人事物拟定香港译名的问题
此讨论正在公示7天，直至2025年1月7日 (二) 02:15 (UTC)结束；如有意见请尽快提出。

现拟确立“香港的街道名作为香港政府给予的译名的一种，属于WP:非原创研究#翻译所述的‘可靠来源’”的结论。Sanmosa 兰絮 2024年12月31日 (二) 02:15 (UTC)

Wikipedia talk:条目命名一致性决议 § 提议：规范部分铁路条目站名的译法
此讨论正在公示7天，直至2025年1月7日 (二) 02:22 (UTC)结束；如有意见请尽快提出。

现拟确立“日文中的‘貨物駅’与‘貨物ターミナル駅’在所有显示模式下统一翻译为‘货运站’”的结论。Sanmosa 兰絮 2024年12月31日 (二) 02:22 (UTC)

维基百科方针与指引

Wikipedia talk:保护方针 § 对于全保护的一些建议

对《破·地狱》现在的全保护有感，觉得需对管理员提出一点意见。我对全保护的观感，始于2023年3月《中年好声音》，在播映期间因部分延伸确认用户发生编辑战而全保护3个月之久，过长的全保护漠视了其他没有参与编辑战用户的权利，且当时交战双方在对方的个人讨论页进行指责，却没有人试图在条目讨论页发起讨论，连事后其他人追溯到底发生过什么事都有困难。这次破·地狱全保护的时长合理，但一般人根本难以注意有讨论存在于Wikipedia:互助客栈/条目探讨#电影条目过度收录问题，希望管理员也能多做一点促进讨论。就此，我建议如下：

  1. 全保护后如未有人发起讨论，管理员可在条目讨论页发起，通知有关用户。
  2. 如管理员得知已有人发起相关讨论，但并非在条目讨论页，管理员可在条目讨论页留下链接。
  3. 保护模板可否进化一下，能加入相关讨论链接？--Factrecordor（留言） 2024年11月24日 (日) 12:33 (UTC)
Wikipedia talk:维基百科不是什么 § 出版书籍、杂志是否为WP:NOT

如题所述，请教以下情况什么时候属WP:NOT及判定依据?

  • A)条目收录自行出版之书籍或论文(有一手来源、但没有二手、三手来源)；
  • B)条目收录自行出版之书籍或论文(有二手、三手来源)；
  • C)条目收录非自行出版之杂志，杂志内容包括照片、采访(有一手来源、没有二手、三手来源)；
  • D)条目收录非自行出版之杂志，杂志内容包括照片、采访(有二手、三手来源)；
  • E)条目收录非自行出版之杂志，杂志内容包括照片，但没有采访(有一手来源、没有二手、三手来源)；
  • F)条目收录非自行出版之杂志，杂志内容包括照片，但没有采访(有二手、三手来源)；--Abcet10（留言） 2024年12月4日 (三) 14:31 (UTC)
Wikipedia talk:用户框 § 应根据WP:用户页对WP:用户框进行修订

从范围上来看，用户框是用户页的子集。用户框的内容也应受到WP:UPNOT的限制。想起这一点是因为近日又有新用户（Carl66066）连续创建多个在我看来并不合适的用户框。以该用户此前的用户页为例：

  • 视觉效果十分糟糕：颜色搭配不当，背景颜色和文字颜色接近，文本框宽度参差不一；
  • 反复宣告自己的观点：使用大量文本详细描述自己的观点，而这些观点基本上与维基媒体运动及社群协作毫无关联；
  • 名称不明确：模板名称与文本内容不相符，或存在歧义。

由于类似的编辑者以往也存在，我认为有必要按照WP:UP修订WP:UBX，把Template:Subcat guideline-en从WP:UBX移掉，对目前的用户框进行整理，将文本内容过于注重表达个人意见的改为中性的陈述或简单的宣告，无可救药的模板批量送存废。——暁月凛奈 (留言) 2024年12月4日 (三) 15:19 (UTC)

(＋)支持。另外除了根据中维的《WP:用户页》修订之外，也可以根据目前英维的en:WP:Userboxes修订？因为似乎中维的版本有些落后了…… ——自由雨日🌧️❄️ 2024年12月4日 (三) 15:27 (UTC)
Wikipedia talk:关注度 (音乐) § 重新讨论NT:MUSIC

各位编辑，在下长期以来在浏览编辑维基百科的过程中，发现存在大量的近似爱好者内容，这些作品大多以单曲、演唱会和部分音乐综艺节目为主，通常无法证明其关注度，内文更是不重要的内容堆砌。但是，这些条目又往往能绕过当前NT:MUSIC的相关论述，使编者很难在存废问题或其他条目编辑问题上达成共识。依在下所见，当前的NT:MUSIC至少存在以下问题：

  • 在关于来源的问题上，现今条文是他们曾经被多份独立于该音乐家或团体以外的已出版可靠来源所提及，但是根据中国大陆当前现状，由于充斥大量的内容农场和宣传内容，使许多看似可靠来源实则存在潜在的不中立现象，如自己按门铃自己听中的中国网来源（《歌手·当打之年》今晚终极奇袭 周深首秀未发布新曲）之类，在下看不到任何属于可靠来源的证据。
  • 在关于音乐作品的内容中，维基百科:商业排行与认证是部分维基编者编辑部分单曲条目的重要依靠，但是中国大陆的音乐榜单要么是平台的自嗨、要么是粉丝的刷榜，毫无公信力可言。如被部分编辑推崇的腾讯音乐由你榜，就曾被举报过开通年会员可大大提高用户打榜（主要包括播放、收藏、下载、分析、点赞歌曲等）权重（1），并且该榜单仅限腾讯拥有著作权的音乐，此类排行榜获得什么周榜月榜第几名、有多少可信度自有公论，其他类似网易、酷狗等等推出的野鸡榜单更是不用再浪费时间。
  • 另外，在相当多内容的条目中存在大量毫无意义的内容，几乎要把维基百科变成Fandom。如“天外来物”世界巡回演唱会中什么“衢州新闻媒体中心在抖音官方账号上发布了视频，表达了对薛之谦的感谢”、自己按门铃自己听中类似“周深在演唱的时候，身穿一件珍珠装饰的牛仔夹克，搭配黑色T恤和牛仔裤亮相”的表述，在下看不出放在条目内的必要。
  • 现存的NT:MUSIC中没有关于演唱会关注度的表述。

综上所述，现存的NT:MUSIC及其他相关页面均为论述或指引，并且部分表述相当模糊，大量的条目游走在关注度的边缘，因此在下建议社群对上述内容进行重新讨论并争取达成共识并升格为方针。由于刚刚提起讨论，在下暂不提出新的方案内容，待社群讨论后再进行总结。--SheltonMartin留言|签名 2024年12月11日 (三) 01:22 (UTC)

Wikipedia talk:消歧义 § 没有目标条目的独立消歧义页

参见Wikipedia:消歧义，一般独立消歧义页，应该列出存在和消歧义名相同的目标项目的链接，例如“XXX”为名，则存在“XXX (AAA)”、“XXX (BBB)”的列项和目标链接，但@Sdf：创建了若干不属于这种情况的独立消歧义页，主要是虚构作品内姓名相同的角色名（秋山美月、三千院帝），这些角色至少暂时不太可能创建符合关注度的独立条目，是否视为类似全红链的独立消歧义页不保留？——Sakamotosan路过围观 | 避免做作，免敬 2024年12月12日 (四) 12:28 (UTC)

反对删除，参见w:MOS:DABMENTION。英文版有类似的：w:Maggie Anderson (disambiguation)--GZWDer（留言） 2024年12月12日 (四) 12:49 (UTC)
Wikipedia talk:申请解除权限 § 被不限期封禁用户不应默认复审移除IP封禁豁免权限

Wikipedia:申请解除权限在议的多项提议和既往“判例”表明，永封用户经由“已封禁或除权用户复审”快速剥夺IPBE权限。然，本站用户对IPBE权限的使用多是因为GFW封锁下被迫使用代理编辑，为正常编辑所必须之权限，在用户尚未被移除编辑其讨论页权限前移除其IPBE权限在实践上剥夺了被封禁用户编辑其讨论页进行初步申诉的能力，显然是越俎代庖。此外，依据Wikipedia:IP封禁豁免#移除权限一节，被封禁用户虽可能已不被社群信任，但亦不太可能滥用其权限（IPBE），被完全封禁的用户的权限也会因为不活动而自动移除，并无主动快速移除其IPBE权限的必要性。综上所述，提议：

现行条文
提议条文

出于保留受GFW影响的用户在被封禁后使用其讨论页进行申诉的能力，对于拥有IPBE权限的无限期封禁用户，在无证据证明该用户可能滥用其IPBE权限的情况下，不应在其被不限期禁止编辑其讨论页前主动移除其IPBE权限。

此提议需要熟悉反破坏工作（如傀儡调查）的社群成员讨论，另ping之前在布告板参与讨论的@自由雨日、Ericliu1912、Allervous、Manchiu、阿南之人。--HeihaHeihaHa-戒慎恐惧……（留言） 2024年12月13日 (五) 13:40 (UTC)

Wikipedia talk:管理员布告板/其他不当行为 § 控制复杂ANM案例

提议对WP:ANM过长的案例进行分子页讨论，现在部分案件是长的，目的是WP:ANM作为目录，有连接到每一个子页面，这样页面分离会好一些。 -Lemonaka 2024年12月20日 (五) 00:46 (UTC)

Wikipedia talk:维基百科不是什么 § 修改WP:SOAP

所谓维基百科不是宣传工具，应适用于所有命名空间，假使今天一个账号到处投放支持蔡英文，反对国民党之类的话语，投样100个账号，有52个支持，那今天就合理的在52个用户讨论页上宣传，因此建议

现行条文

维基百科拒绝宣传。维基百科不是演讲台、论坛、宣传工具、广告场所或者展览平台。此项适用于用户名、条目、分类、文件、讨论页、模板及用户页。因此，请勿于维基百科：

提议条文

维基百科拒绝宣传。维基百科不是演讲台、论坛、宣传工具、广告场所或者展览平台。此项适用于所有命名空间。因此，请勿于维基百科：

这样可以有效避免宣传，惟其需待社群讨论，祝编安。-- A0(讨论·签名) 2024年12月22日 (日) 01:48 (UTC)

Wikipedia talk:过滤器助理 § 赋予过滤器助理修改滥用过滤器权限
此讨论正在公示7天，直至2025年1月7日 (二) 01:54 (UTC)结束；如有意见请尽快提出。

注意到防滥用过滤器错误报告和防滥用过滤器请求积压，管理员及行政员负担较重，导致部分请求无法及时处理，这降低了过滤器阻止破坏的能力，亦增加了社群维护其的难度。因此，谨提议授予过滤器助理修改权限，协助管理滥用过滤器，尚祈社群商议为荷。Iming 彼女の爱は、甘くて痛い。 2024年12月28日 (六) 03:12 (UTC)

Wikipedia talk:关注度 (组织) § 修改学校关注度指引
此讨论正在公示7天，直至2025年1月7日 (二) 02:10 (UTC)结束；如有意见请尽快提出。

拟修订WP:关注度 (组织)如下。Sanmosa 兰絮 2024年12月30日 (一) 01:04 (UTC)

维基百科提议

Wikipedia:互助客栈/其他 § 在本地启用安全投票及electionadmin权限

本主题或以下段落文字，移动自Wikipedia:互助客栈/技术。执行者：即请秋安 ZhaoFJx(论•签) 2024年10月17日 (四) 20:53 (UTC)。

原标题：SecurePoll elections with the electionadmin right

（我很抱歉用英语写作。请随意翻译此消息。）

Hello! My name is Joe Sutherland and I'm on the Trust and Safety team at the Wikimedia Foundation. In the past, your community has shown interest in holding elections with SecurePoll — perhaps you already have through votewiki. We are now looking into making this available to local communities to run elections themselves. This will require the "electionadmin" right to be enabled on your project, which is a right that allows access to sensitive information.

As such, it is likely that you will need to run a Request for Comment (or similar process) to ascertain consensus for the implementation of this feature. To help guide such a discussion, we've put together a Meta-Wiki page with more information about what enabling the right will mean for your community.

If your community does discuss and decides to move forward with this, T&S would like to support you — please let us know via email ( ca@wikimedia.org ) if and when consensus is reached. Thank you!--JSutherland (WMF)（留言） 2024年10月17日 (四) 20:07 (UTC)

Wikipedia:互助客栈/其他 § 重启Automoderator部署讨论
于Phabricator查看
编号T367306的工单

十余月前，该讨论向社群引介了自动化反破坏Automoderator工具，然其因热度不足而无疾而终。因此，我谨引用原留言：

大家好，我的名字是Sam Walton，是管理员工具（Moderator Tools）团队的产品经理。我们正在开发一个名为Automoderator的项目，该项目让社群能够根据社群自定义的规则自动回退破坏性编辑。我们正在寻求对我们项目的意见，并有一些问题需要巡查员和管理员的参与，以帮助我们更好地理解。除了项目主页面上的概述和问题之外，我们还有两个子页面提供更具体的资讯：

如果您想研究Automoderator的准确率，并查看它在不同编辑上的表现，我们设置了一个测试流程。您可以帮助我们找到新的模式，并在Automoderator部署之前将其纳入考虑范围（译注：例如怎样改善误判问题、使用什么程度的准确率（cution levels）比较好）。 评估计划是用来确定Automoderator是否实现目标且不会产生负面影响的计划初稿。如果您对我们收集的数据或制定的指标有任何想法，那么您可以在这里分享！

如果您对Automoderator有任何疑问，或者您的社群是否想要使用这个工具，请告诉我！
— User:Samwalton9_(WMF)

还请社群评估该工具部署之可能性及价值为荷。——敬颂冬绥 ZhaoFJx(论•签) 2024年12月18日 (三) 19:45 (UTC)

Wikipedia:互助客栈/其他 § 提议将每日提示内容同步到首页“提示”版块展示

经过Tisscherry君最近一段时间的不懈努力，Wikipedia:提示的所有每日提示内容已经建设完成（终于完成了一个天坑orz）。有鉴于此，如Wikipedia:每日提示维护小组#任务所述，现提议将“提示”内容同步到首页“每日提示”版块更新，特此征求社群意见。--Jeffchu2014（留言） 2024年12月19日 (四) 10:43 (UTC)

专题命名空间（第五至六阶段）

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:命名空间/2021年设立新命名空间及伪命名空间（错误：Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间是重定向页面）。

[编辑此导航模板]

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

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

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

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

——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年2月14日 (日) 12:57 (UTC)[回复]

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

第五阶段：小结

下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

总结以上讨论意见：

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

R2. 跨命名空间的重定向。

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

R2. 跨命名空间的重定向。

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

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

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

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
@羊羊32521、LuciferianThomas：不知道能不能找到人写bot。不然我们也可以先根据之前就每个WP=>WPJ的捷径分别的链入数排查出来的结果手动进行“先消除链入、后提R2”的工作，但可能会涉及模板链接跟EP。WPJ=>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/65827060。SANMOSA Σουέζ 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)[回复]
@Xiplus、A2569875：话说WPBannerMeta的模板应该有隐藏的“Wikipedia:”开首专题链接，不知道是怎么一回事，有空要fix一下。SANMOSA Σουέζ 2021年6月10日 (四) 14:15 (UTC)[回复]

参考资料

  1. ^ 图床链接（站内存档）。此正则会匹配链接到WP:MEA的内部链接或管道|链接。※注：由于/:?/有尔会导致搜索功能错误，因此以/:*/替代；由于/\|?/有尔会导致搜索功能错误，因此以/[\|\]]/替代。

第六阶段：其他议题讨论

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

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

本讨论章节会维持开放，暂时不按最后意见发表时间存档，直到部署完成。欲让机器人存档，请移除本模板。留言请置于本模板上方。

WP:捷径指引草案修订

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:捷径、Wikipedia talk:命名空间/2021年设立新命名空间及伪命名空间（错误：Wikipedia talk:名字空间/2021年设立新名字空间及伪名字空间是重定向页面）。

[编辑此导航模板]

说明

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

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

本讨论的各阶段分为：

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

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

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

专题命名空间问题

本主题全部或部分段落文字，已转移至Wikipedia_talk:专题#专题命名空间（第一至二阶段）。执行人：台湾杉在此发言 (会客室)。标记人：来人啊，喂宫子吃布丁！ ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年1月14日 (四) 06:44 (UTC)。[回复]

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

本主题全部或部分段落文字，已转移至Wikipedia_talk:命名空间/2021年设立新命名空间及伪命名空间#伪命名空间（阶段一：设立前）。执行人：台湾杉在此发言 (会客室)。标记人：来人啊，喂宫子吃布丁！ ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年3月24日 (三) 05:54 (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)[回复]
(？)疑问@Taiwania Justo：快整理好了吗？-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2021年6月24日 (四) 02:32 (UTC)[回复]

捷径指引修正

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

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

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:快速删除方针。

参见Wikipedia:互助客栈/求助/存档/2021年4月#请帮忙删除 User:Tranve/工坊/workshop.json，像 JSON 和 Module: 命名空间的页面，速删模板挂不上去。希望可以在方针制度层面解决这个问题。--Tranve (✉) 2021年4月5日 (一) 13:07 (UTC)[回复]
cc@蟲蟲飛、Xiplus、Sunny00217 --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：参考英文维基的模式讨论页放置提删模板

本主题或以下段落文字，已存档至Wikipedia_talk:快速删除方针#就规范部分特殊页面的删除方式征求社群建议。执行人：--U:a2569875 UT:a2569875 2021年5月26日 (三) 04:39 (UTC)[回复]

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

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

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

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

本主题或以下段落文字，已存档至Wikipedia_talk:快速删除方针#就规范部分特殊页面的删除方式征求社群建议。执行人：--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)[回复]

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

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

本主题或以下段落文字，已存档至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)[回复]

已通过并存档：
由于互助客栈内容已经过长，因此，已通过的子议案已先行存档。（原议案通过时间 2021年5月7日 (五) 13:45 (UTC)）-- 五岁抬头雪菲（☎️·☘️） 2021年5月25日 (二) 09:59 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

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

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

技术案：处理状况

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

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

本主题或以下段落文字，已存档至MediaWiki talk:Gadget-SpecialWikitext.js#技术案阶段二：页面预览功能。执行人：-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2021年6月8日 (二) 12:56 (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、FLOW讨论页、纯文字分类BUG问题

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

以下内容抄录自WP:TG/IRC此留言附近，新留言请置于框外。执行人：-- 五岁抬头雪菲（☎️·☘️） 2021年5月22日 (六) 08:55 (UTC)[回复]

  • 工单布署后。所以现在可能需要讨论工单布署前的时期怎么渡过 -- 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)[回复]

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

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

提议条文

...(略)...由于技术限制，在JSON、FLOW讨论页、纯文字放置模板后暂时不会自动被加入分类，因此在提删此类页面时可一并将请求提报至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、FLOW讨论页、纯文字”的速删请求应该不多，而其他“大量讯息发送列表、CSS、已过滤的CSS、JavaScript、Lua、Wikitext等页面”的速删请求本来的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一下所有参与者cc@Tranve、Antigng、Sunny00217、蟲蟲飛、Shizhao、霧島聖：想看看其他参与者的想法或意见。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2021年6月26日 (六) 09:49 (UTC)[回复]

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

技术案阶段三：WP:TW

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:Twinkle。

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

方针注记案

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
现行条文

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

提议条文

……

放置快速删除模板时的注意事项 部分页面放置提删模板时需要符合相应内容模型，因此在放置快速删除模板时需要遵从特定方式，同时，下面列举的模板放置方式，亦适用于其他模板，如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|快速删除理由}}填入；而提删大量讯息发送列表时，请将提删模板放置在“描述”栏位中。
注：由于技术限制，在JSON、FLOW讨论页、纯文字放置模板后暂时不会自动被加入分类，因此在提删此类页面时可能还需要另外通知一位管理员来执行删除。

管理员操作注意事项 ……

准备中...-- 五岁抬头雪菲（☎️·☘️） 2021年5月3日 (一) 04:01 (UTC)[回复]
  • 其实只要在管理员讨论页留句话，管理员已经可以很简单地处理了。--虫虫飞♡♡→♡℃※留言 2021年5月26日 (三) 06:03 (UTC)[回复]
    • (？)疑问@蟲蟲飛：还是要挂模板吧？目前技术上已经完全克服挂模板问题，所有页面都能挂模板了。您不是会怕提删时没挂模板会“陷管理员于不义”吗？指引注记“模板怎么挂”有什么问题吗？“注：由于技术限制，在JSON、FLOW讨论页、纯文字放置模板后暂时不会自动被加入分类，因此在提删此类页面时可能还需要另外通知一位管理员来执行删除。”正是在指引页提示“需要另外通知一位管理员来执行”理应跟您于 2021年5月26日 (三) 06:03 (UTC) 的留言没有冲突。（节删）。-- 五岁抬头雪菲（☎️·☘️） 2021年5月26日 (三) 06:15 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

订立影片加入相关指引

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:文件使用方针。

我发现最近有很多条目中都被加入了影片，虽然其中不少都对条目大有裨益，但是我也发现相当一部分条目中被加入了与条目本身关系不大的内容或与条目本身不对称的内容（比如在青藏高原条目加入中科院院士的演讲影片和在小条目加入长达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)[回复]
@Newbamboo、Park1996：已有相关规范，见WP:VUP。SANMOSA Σουέζ 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、痛心疾首、Yangwenbo99、Ericliu1912：不好意思，最近疏于关注了。上面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:NOTGALLERY。SANMOSA Σουέζ 2021年5月26日 (三) 00:01 (UTC)[回复]
NOTGALLERY啊，那不是破坏，WP:VAND定义何为破坏。而且阁下离题了，这里的问题是用户固执己见加入图片，《破坏》方针称，“这的确令人遗憾，但不是破坏行为”。我认为提案人根本没明白什么叫破坏。本案通过无助于任何问题，只能给特定加文件的人扣破坏的帽子而已。--痛心疾首（留言） 2021年5月26日 (三) 01:11 (UTC)[回复]
@痛心疾首：WP:VAN：“图片破坏：以破坏性的方式上载或使用文件”、“只要这些文件具有百科全书性，并且使用在合适的地方，这种上载/使用就不属于破坏”。WP:VUP其实算是某程度上已经界定了使条目同时存在多于五条影片的操作与加入曾被非破坏性移除的影片的操作为“破坏性的方式使用文件”的一种，并且不属于文件“使用在合适的地方”的情形，那这样的修订自然是合理的。再退一步来说，WP:VAN：“破坏类型：常见的破坏性编辑通常具有以下一个或多个特征”，使条目同时存在多于五条影片的操作与加入曾被非破坏性移除的影片的操作也可以算成“非常见的破坏性编辑”，因为这条文是之前有个别用户故意大规模加入大量影片到不同的条目里头才出现的，这不是过往会见到的问题，但出现有人仿效的情形，所以才立例。SANMOSA Σουέζ 2021年5月26日 (三) 14:01 (UTC)[回复]
WP:VUP其实算是某程度上已经界定了使条目同时存在多于五条影片的操作与加入曾被非破坏性移除的影片的操作为“破坏性的方式使用文件”的一种[来源请求]
阁下还是离题了。这里的问题根本不是进行图片破坏，也根本不是所谓的非常见破坏性编辑。请参见破坏的根本定义，即“故意危害维基百科正确性与完整性”。假若相关用户加入的内容是相关的，那就并未故意危害维基百科正确性与完整性，显然就不是破坏。用其他方针定义超出这个定义范围的“破坏”是危险的，因为这会让破坏的概念泛化，从而变成一个人人皆可得而扣之的帽子。@Antigng：--痛心疾首（留言） 2021年5月26日 (三) 14:31 (UTC)[回复]
@痛心疾首、Antigng：不，只要社群的共识认为某种行为是破坏，那该种行为就是破坏，我认为当初WP:VUP的制定本身就体现了这点。退一步来说，这方针算是从一开始就假定影片都会“危害维基百科正确性与完整性”，因此需要加入的用户自行举证相关影片不会“危害维基百科正确性与完整性”（这部分是原本的条文就有的）。SANMOSA Σουέζ 2021年6月1日 (二) 09:32 (UTC)[回复]

本讨论章节会维持开放，暂时不按最后意见发表时间存档。欲让机器人存档，请移除本模板。留言请置于本模板上方。

再次推动破坏者（LTA）成为命名空间

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

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

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

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

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

我想可以第一次申请都是临时授权，在第二次申请的时候进行这样的考核。--What color are you, Sibyl System? |欢迎订阅维猫报！ 2021年5月30日 (日) 12:19 (UTC)[回复]
于Phabricator查看
编号T284362的工单
@羊羊32521：wikt: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)[回复]

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

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:格式手册/两岸四地用语。

已通过：
经过公示7日，无反对意见，一致通过。--路西法人 • 留言 2021年6月6日 (日) 23:07 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

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

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

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

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

本主题或以下段落文字，移动自#格式手册对于国籍的规定有缺陷，有用户借此删除知名人士的前国家国籍。

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

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

国籍

快捷方式

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

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

指定样式表

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

国籍

快捷方式

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

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

指定样式表

编号 指定样式
1
  1.  中国（{{CHN-1862}}，仅适用于1889年前）
  2.  大清（{{QING-1862}}，仅适用于1889年前）
  3.  中国（{{CHN-1889}}）
  4.  大清（{{QING-1889}}）
  5. [[清朝|中国]]
  6. [[清朝|大清]]
2
  1.  中国（{{CHN-1912}}）
  2.  中华民国（{{ROC-1912}}）
  3. [[北洋政府|中国]]
  4. [[北洋政府|中华民国]]
3
  1.  中国（{{CHN-1928}}）
  2.  中华民国（{{ROC-1928}}）
  3. [[中華民國大陸時期|中国]]
  4. [[中華民國大陸時期|中华民国]]
4
  1.  日本（{{JPN-1868}}）
  2. [[大日本帝国|日本]]
6
  1.  中华民国（{{ROC}}）
  2. [[中華民國]]
8
  1.  中华人民共和国（{{PRC}}）
  2. [[中华人民共和国]]
10
  1. 中华人民共和国（香港）（{{PRC-HKG}}）
  2. [[中华人民共和国]]（[[香港居民#永久性居民|香港]]）
12
  1. 中华人民共和国（澳门）（{{PRC-MAC}}）
  2. [[中华人民共和国]]（[[澳門居民#永久性居民|澳门]]）
13
  1. 英国属土（{{BDTC}}）
  2. [[英國海外領土公民#香港英國屬土公民（BDTC）|英国属土]]
14
  1. 英国国民（海外）（{{GBN}}）
  2. [[英國國民（海外）]]
15
  1.  英国（{{GBR-1801}}，仅适用于1922年／1927年前）
  2.  英国（{{GBR}}）
  3. [[大不列颠及爱尔兰联合王国|英国]]（仅适用于1922年／1927年前）
  4. [[英国]]
16
  1.  葡萄牙（{{POR-1578}}，仅适用于1615年前）
  2. 葡萄牙王国 葡萄牙（{{POR-1616}}，仅适用于1639年前）
  3.  葡萄牙（{{POR-1640}}，仅适用于1666年前）
  4.  葡萄牙（{{POR-1667}}，仅适用于1706年前）
  5.  葡萄牙王国（{{POR-1707}}，仅适用于1815年前）
  6. 葡萄牙巴西联合王国（{{POR-1816}}，仅适用于1829年前）
  7.  葡萄牙王国（{{POR-1830}}，仅适用于1910年前）
  8.  葡萄牙（{{POR-1910}}，仅适用于1926年前）
  9. 葡萄牙 葡萄牙（{{POR-1926}}，仅适用于1933年前）
  10.  葡萄牙（{{POR-1933}}，仅适用于1974年前）
  11.  葡萄牙（{{POR}}）
  12. [[葡萄牙王國|葡萄牙]]（仅适用于1910年前）
  13. [[葡萄牙]]
  1. ^ 1.0 1.1 详见《大清国籍条例》。
  2. ^ 2.0 2.1 2.2 2.3 割据政权可采用注释形式另行说明。
  3. ^ 3.0 3.1 详见大日本帝国《国籍法》（明治三十二年法律第六十六号）。
  4. ^ 4.0 4.1 详见英国国籍法与香港 § 1997年英国国籍（香港）法令。

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

(＋)支持。--路西法人 • 留言 2021年5月20日 (四) 06:39 (UTC)[回复]
(＋)支持 这样标注国籍无歧义，且人物的不同时期国籍和同一时期的多重国籍本就应一并标示。另外{{ROC-1912}}应该链接至中华民国大陆时期，因为五色旗在1912年—1913年的中华民国临时政府（1912年1月—3月政府驻于南京，1912年3月—1913年10月政府驻于北京）以及1913年—1928年的北洋政府均作为中华民国国旗使用。--Joker Twins（留言） 2021年5月22日 (六) 08:00 (UTC)[回复]
其实就算人没有迁移还在原地，但只要经历政权更迭，就该把其所经历的政权更迭所导致的国籍变动在信息框一一列出，这才符合常理，也是Sanmosa本次提案的题中应有之意，只给出最终国籍了事，对于人物早年的国籍而言，只会给人以穿越时空的错乱感，显然很不恰当。--Joker Twins（留言） 2021年5月22日 (六) 15:28 (UTC)[回复]
理解了，我现在不反对这种标注，只是觉得这么做有点繁琐罢了。--指湘为鄂 2021年5月23日 (日) 06:35 (UTC)[回复]
差不多一个礼拜没有回应，且没有反对意见。 公示7日，2021年6月6日 (日) 14:11 (UTC) 结束。--路西法人 • 留言 2021年5月30日 (日) 14:11 (UTC)[回复]
(＋)支持，但有一个问题（不中断公示也可以，因为是后续处理问题）。提案通过后，目前使用{{CHN-HKG}}的具中华人民共和国国籍的香港永久性居民将要全数改为{{PRC-HKG}}，唯涉及条目众多，人手修改恐怕不太现实，所以会不会考虑直接将{{CHN-HKG}}重定向至{{PRC-HKG}}或者直接修改为后者的样式？（这个模板应该没有在其他场合使用）不然的话使用AWB也可以，不过需要具有相关权限的用户协助。--【和平至上】💬 2021年6月1日 (二) 16:53 (UTC)[回复]
@和平至上：到时会改重定向（而且即使有在其他场合使用，这样改也不会出问题）。问题更大的反而是{{CHN}}的使用。SANMOSA Σουέζ 2021年6月2日 (三) 00:16 (UTC)[回复]

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

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

参考资料

  1. ^ 国籍：国籍是指一个人属于一个国家国民的法律资格

国籍栏使用模板后续处理

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

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

模板的历史怎么没了？

我刚才还一头雾水，现在看了下这些模板的“指向本页面的重定向页”，总算搞清了：这些模板原先叫做：{{CHN-HKG}}、{{CHN-MAC}}，doc页是Template:CHN-HKG/doc、Template:CHN-MAC/doc。看起来@Sanmosa：想把它们移动到{{PRC-HKG}}、{{PRC-MAC}}、Template:PRC-HKG/doc、Template:PRC-MAC/doc，但是移动到的目标页已经被创建且有历史了，没有管理员权限，技术上无法进行移动，于是Sanmosa就手动清空原页面，手动复制粘贴所有内容到目标页，然后创建doc页并手动把原内容都复制粘贴过来。请阅读Help:页面重命名#无法移动的情况：这种“剪贴移动”丢掉了所有页面历史，违反CC-by-sa，是被禁止的。请哪位管理员删掉{{PRC-HKG}}、{{PRC-MAC}}、Template:PRC-HKG/doc、Template:PRC-MAC/doc，把{{CHN-HKG}}、{{CHN-MAC}}、Template:CHN-HKG/doc、Template:CHN-MAC/doc重新移动过来？--Tomchen1989（留言） 2021年6月26日 (六) 18:39 (UTC)[回复]

@Xiplus、AT、蟲蟲飛：ping几个管理员来处理上述事宜。||其实违反CC-by-sa的“剪贴移动”和其他WP:侵权需速删的行为没有区别，都是侵犯著作权的行为，理应尽早处理。而上述剪贴移动发生在去年11月，半年了，也没人发现、没人管，即便有关国籍的话题讨论得热火朝天的。麻烦诸位编辑（很多还是挺资深，有许多权限的编辑）认真了解和遵守CC-by-sa以及相关规定，感觉很多人意识里维基百科上的文字好像就是没有著作权的一样。--Tomchen1989（留言） 2021年6月27日 (日) 07:34 (UTC)[回复]
经初步查阅，创建页面与改成重定向的时间差距不少，无法简单认定为剪贴移动，其状况应该是拆分模板后又进行合并模板；对于合并页面，不一定要进行合并历史，但不合并历史的状况下应在讨论页标记{{Merged-from}}；至于本案是否应合并历史，先请@Sanmosa说明相关操作吧。--Xiplus#Talk 2021年6月27日 (日) 11:54 (UTC)[回复]

此外，这些模板记得以前也有很多讨论（好像不仅仅只有Template talk:CHN-HKG列出的两个存废讨论），也不知道存档到哪里了，如果互助客栈的讨论最后没有存档到Template talk页的话，麻烦管理员至少在Template talk:PRC-HKG（即上述移动前的Template talk:CHN-HKG）留个链接。--Tomchen1989（留言） 2021年6月26日 (六) 18:39 (UTC)[回复]

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

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:命名常规。

现拟修改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)[回复]
@Jarodalien、Super Wang、安忆：（1）现时此类列表多无书名号，故“‘改成’不规范的形式”不成立。（2）基于现已生效的命名一致性规则，须确立同类条目统一的标题表达式。（3）原始标题若需输入书名号则不利链接。（4）条目内显示的标题可通过-{T|}-或{{noteTA}}的参数显示回书名号，依上案修改该条不会限制此举，我也不打算限制此举（老实说，通过-{T|}-或{{noteTA}}的参数只在条目内显示的标题显示回书名号才是我的完整想法）。SANMOSA Σουέζ 2021年5月10日 (一) 13:54 (UTC)[回复]
@Sanmosa、Jarodalien、Super Wang、安忆、Yumeto、Hijk910：我这边帮大家整理为什么又有这种事。
  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)[回复]
同上，请@Jarodalien、Super 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)[回复]
@痛心疾首、Yumeto、AnYiLin。SANMOSA Σουέζ 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)[回复]
@痛心疾首、Yumeto、AnYiLin、Jarodalien。SANMOSA Σουέζ 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)[回复]
加书名号提案的影响范围似乎包括“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)[回复]
  • 我比较认同这几种方案：
    • 规定原始标题不用书名号→不处理实际标题［视作特殊体例，像消歧义的“_()”并不会改成“（）”］
    • 规定原始标题用书名号→原始标题有单双书名号之别则转换，无则不处理实际标题（按一般行文处理）
    • 先到先得→原始标题有单双书名号之别则转换，其余则不处理实际标题

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

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

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

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

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

小结

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

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

一种可能的解决方案

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

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

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

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

这样做的优点在于：

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

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

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

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

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

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

--Lt2818（留言） 2021年5月21日 (五) 04:39 (UTC)[回复]

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

所以我说那个方案呢？

@Sanmosa、Jarodalien、Super Wang、安忆、Yumeto、Ericliu1912、悔晚斋、Mewaqua、AT、痛心疾首、AnYiLin、Fglffer、驻军、Longway22、Lt2818、瑞丽江的河水、JasonHK：Jarodalien目前建了一大堆有书名号的条目，看起来大家好像都认同应该加书名号...对吧（还是其实是大家都装死）。那么有谁要那些没有书名号的条目移动？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)[回复]

7DAYS的第七次讨论

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:共识。

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

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

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

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

分案1

下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

依照现有的WP:7DAYS，现公示以下对WP:7DAYS的修订（作为分案A）7日：

现行条文

提案讨论及公示时间

方针快捷方式

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

提议条文

提案讨论及公示时间

方针快捷方式

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

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

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

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

(＋)支持:这个修订不错。--虫虫飞♡♡→♡℃※留言 2021年6月1日 (二) 23:24 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

其余分案

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

分案2

现行条文

提案讨论及公示时间

方针快捷方式

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

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

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

提议条文

提案讨论及公示时间

方针快捷方式

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

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

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

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

分案3

现行条文

提案讨论及公示时间

方针快捷方式

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

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

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

提议条文

提案讨论及公示时间

方针快捷方式

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

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

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

参考资料

  1. ^ 等待期在提案提出的7日后（即最早在第8日）方可宣布开始（可晚于第8日方宣布），为期7天，有异议者可随时停止等待期。
  2. ^ 无使用指定模板样式的留言皆不视作此条文所指的“新留言”。

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

(－)反对:把本来很简单的公示程序复杂化，增加不必要的争议。--虫虫飞♡♡→♡℃※留言 2021年6月13日 (日) 03:53 (UTC)[回复]
请求进一步解释。SANMOSA Σουέζ 2021年6月13日 (日) 04:37 (UTC)[回复]
  • “公示期延后”是对提案人有坏处，但对社群有好处，因为公示期延后，提案能收集更多意见，令提案更少争议；对提案人的坏处是增加了提案出现(－)反对的机会，除此外，没有其他坏处。此外，您看看AT现行版本吧，简明清晰，为什么要把简单的事搞到那么复杂？如果现在版本较佳，就没有修订价值。而且提案忽视了AT当初提案的原因，AT当时就是为了解决用户急于公示，强行通过，结果争议不断的问题，现在提案以不同名目去加快公示，很容易回到以前那个“火速公示”然后带出种种争议问题。--虫虫飞♡♡→♡℃※留言 2021年6月25日 (五) 11:47 (UTC)[回复]
  • @蟲蟲飛：您说的有道理。@Sanmosa：您似乎误解了现行方针（指版本65992576）中“公示期间若无异议，则提案算作通过”一句，这一句话并不会因为“陆陆续续冒出来的支持意见或者一些无关的评论”而导致公示期延长，而是只有反对意见才会终止公示。基于此我认为您关于“新留言”的提案并无实际意义，而仅仅是对现行版本进一步解释，但是您所提出的模板可以作为非强制要求放入方针中——落花有意12138 论 回复请ping我 2021年6月27日 (日) 02:50 (UTC)[回复]
@落花有意12138：你才是误解的人吧，产生“陆陆续续冒出来的支持意见或者一些无关的评论”而导致公示期延长的情形的条文是“如果在互助客栈中被提出的提案出现以下情形之一：1. 在7日内没有新留言”。SANMOSA Σουέζ 2021年6月27日 (日) 02:55 (UTC)[回复]
提案不能太心急，多放一两天，收集更多意见，可以令提案更少争议，这是对社群有好处；真正有共识的提案不论放多长时间，也不怕出现(－)反对--虫虫飞♡♡→♡℃※留言 2021年6月27日 (日) 03:06 (UTC)[回复]
@Sanmosa：您说的对，是我误解了。但若是“同意”之列的留言而使用了模板，似乎并没有防止这一情况产生。我的意见是，将提案中“新留言”改为“反对意见”，并要求以{{反对}}模板标识。
另外，据我的理解，按照此提案，一个提案要在获得共识后依次经过7日的等待期和7日的公示，是吗？如果这样，似乎等的有点长了，我建议将“等待期”与“公示期”合并——落花有意12138 论 回复请ping我 2021年6月27日 (日) 03:18 (UTC)[回复]
为凝聚共识，收集更多意见，只有纯支持和纯评论才能视为无效留言。如果有对提案的实质意见，说明提案共识还未形成，应该终止等待期。我提出要用 无异议支持和 评论是要强调您的支持意见只能是无异议的，或者纯属评论。用 终止等待期则是强调等待期已经终止。-- ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年6月27日 (日) 04:01 (UTC)[回复]
问题在于提案有很多概念的标准不明，而且很复杂，像“如果有对提案的实质意见，说明提案共识还未形成，应该终止等待期。”客栈提案就有很多争议，如何定义“实质意见”？而且为什么要判断“纯支持和纯评论”为“无效留言”？争议激烈时，大家可能互相指责对方的留言不是“实质意见”，甚至互相指责对方的意见为“无效留言”，这样情况就很糟糕，AT现行版较佳，而且不会出现上述问题。本站提案时间已经太短了，您看元维基那边，动辄几个月的提案比比皆是，为了社群利益，没必要以“不同名目”去加速公示。--虫虫飞♡♡→♡℃※留言 2021年6月27日 (日) 04:13 (UTC)[回复]

分案4

现行条文

提案讨论及公示时间

方针快捷方式

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

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

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

提议条文

提案讨论及公示时间

方针快捷方式

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

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

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

参考资料

  1. ^ 不对提案进行任何点评的支持意见及与提案本身无关的意见，皆不视作此条文所指的“新留言”。

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

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

等待期案

  • (：)回应：其实这个提案的核心就是“用{{stop7d}}来终止等待期”，而且写在{{等待期}}里：

----

提案已提出超过7日，等待期开始，为期7日，至2025年1月10日 (五) 23:10 (UTC) 结束并进入公示。

  • 等待期间请使用{{无异议}}来支持，{{converse}}来评论。若有异议或补充，请用{{stop7d}}终止等待期。
{{无异议}}、{{converse}}都不会影响等待期的计算。如果遇到明显意见（包括反对和补充）又没用模板的，他人可以直接用{{stop7d}}终止等待期。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年6月24日 (四) 06:04 (UTC)[回复]
(：)回应
  1. 所谓的“问题”指“因为有新留言”，而导致“公示期延迟一两天”，这是对提案人有坏处，对社群有好处，因为延迟一两天公示，能收集更多意见，令提案更少争议，此外，我理解“延迟公示”会增加出现(－)反对风险，但这正是提案的目的，因为提案是要看看有没有人反对，如果没反对，就算没有支持，提案也可以通过，而且真正有共识的提案，不论放多久都不怕出现反对。
  2. 此案确实没有出现火速公示，但太复杂了，社群不容易掌握，客栈提案本来就容易有争议，把公示程序复杂化，只会令本来有争议的提案，变得更有争议。所以我还是觉得AT现行版本较佳，AT版也较简单易明。
以上。--虫虫飞♡♡→♡℃※留言 2021年6月27日 (日) 02:59 (UTC)[回复]
  • (：)回应：问题不在此。
    1. 妨碍了形成共识的认定。前文说了，陆陆续续冒出的支持意见能体现出该提案得到认同，公示期但却因为该规定一延再延；然而没多少人关注留言的提案却能符合7DAYS的规定而进入公示。……很明显，后一种提案体现的共识没有前一种的强。如果说延迟一两天公示，能收集更多意见，令提案更少争议，那后一种提案为什么不用多收集意见？
    2. 降低讨论效率。平衡效率和共识，这点见仁见智，虫虫飞君可能认为共识更加重要，我也没有合适的反驳理据。
    3. 执行力度不强。前文说了，为了规避以上两点，部分提案者会通过引用WP:IAR，以WP:SNOW直接进入公示，不管该提案是否适合 IAR 和 SNOW。而同样因为不想讨论效率低下，很少有人会去阻止纠正[来源请求]。用等待期卡死7+7+7天可以一定程度上解决这个问题。
    4. 我再补充一点，不利于收集更多意见：延迟一两天公示，能收集更多意见，令提案更少争议是没错，但普通路人来投(＋)支持的时候，考虑到“我投这一票，公示时间会延期”，一般不会投下(＋)支持票。那这样，公示就不会延迟，他这点支持意见也不会被社群收集。确实，(－)反对票比(＋)支持票在优化提案上更加重要，但可能在后续讨论中（比如出现争议，或者优化提案时），这个路人和他的意见不被社群所知，也不会被ping来参加讨论。个人认为这样不利于收集更多意见。
以上。 ——羊羊 [ 留言 贡献 维猫报 古典音乐专题 ] 2021年6月27日 (日) 03:49 (UTC)[回复]
(：)回应
  1. “陆陆续续冒出的支持意见”最多是一两天，您看看下面“延伸确认保护”的提案，也是“陆陆续续冒出的支持意见”，但最后还是“陆陆续续冒出的(－)反对意见”，因此多放一两天提案才能看到提案是否确实反映共识。
  2. “形成共识”需要深入而全面的讨论，所以不能急于通过提案，而且不是每个用户都很忙，一两个星期才上维基的人很多，如果提案匆匆就公示通过了，然后争议不断，对社群，对维基都不好。
  3. IAR不能乱用，只有在现行规则阻碍您贡献维基才适用，事实上提案多放一两天，收集更多意见，对社群有好处。至于您的提案，我觉得最大的问题是大复杂，而且有很多概念很难有客观标准，容易有争议。
  4. 不要看到开始时有很多支持意见就以为提案有共识，您看下面“延伸确认保护”，开始时“陆陆续续冒出的支持意见”，但最后还是“陆陆续续冒出的(－)反对意见”，所以提案不能太心急，多放一两天，对社群有好处。
以上。--虫虫飞♡♡→♡℃※留言 2021年6月27日 (日) 04:33 (UTC)[回复]

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

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:小小作品。

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

现行条文

小作品与小小作品的差别

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

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

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

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

提议条文

小作品与小小作品的差别

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

示例 ......

小小作品的定义

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

看到小小作品怎么办

  • 任何人可以在小小作品上，加上小小作品限期修改模板，并标上添加模板的日期。（例如{{substub|1|3}}） ，这样该条目会自动列到该月的小小作品分类中。
  • 在一个月的期限内，任何人可以扩充该条目之后将模板拿掉。如果该条目尚未完整，请改加上各类的小作品模板。（参见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)[回复]

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

现行条文

小作品与小小作品的差别

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

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

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

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

提议条文

小作品与小小作品的差别

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

示例 ......

小小作品的定义

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

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

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

看到小小作品怎么办

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

@和平奮鬥救地球、Temp3600、Sanmosa、An Macanese、NHC：@Lewix：可以看一下新修改方案是否可行---Koala0090（留言） 2021年6月26日 (六) 08:24 (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)[回复]

有关节目列表条目的删除标准

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:格式手册/电视。

已通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

定义

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

前言

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

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

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

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

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

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

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

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

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

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

在此希望征询各位编者对于“此等节目内容表格是否适合保留在维基百科，或是更适合汇出至爱好者维基”的看法。 邀请相关用户：虫虫飞、Jimmy13576、Gillian14777、Donnowin1、简浩廷、Littletingting、Ryusakura、Gagen、Mark85296341、Iw1.everything、小席、Tkwongken、ROCK8120、Photoyi、Weilunlin、风魔小翔、Mikemikekwok、MK99992、KonaYukiCrash、Almostman、F1W06、叶又嘉、Tong606、Guangzhesun、Namgninnur、Kikasin、Chinyen Lu、Wangpengda1210、Mico121、Pv163、To91、Louis0917、PoWaiFung、HIMGOR、Penguin Shido、斑点王、Joker9、Tombus20032000、Raymond siu、Mint2005、简小庆、Amy051023、Case98796、Shinwill、Onlymyself65536、Dansonncf、Yandsam1001、FRDian、★小郑☆、夜来南风起、NCTCLINE530、MichaelWhite246、KingGiang、Arronwan、爱子棋枰、A012525wing、穆雷夏、YFdyh000、Dabao qian、KOP-SEE、Sana1205、OUOIFGAN、TNLHK。

以上，路西法人 • 留言 2021年5月28日 (五) 03:56 (UTC)[回复]

讨论

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

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

正式提案

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

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

以上，并通知参与讨论的用户@Ohtashinichiro、Itcfangye、Arronwan、EclipsedL、Temp3600、忒有钱、Dabao qian、TNLHK。--路西法人 • 留言 2021年6月7日 (一) 01:11 (UTC)[回复]

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

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

没有规范的公示问题
你这公示公到哪里去了？连Template:Bulletin都没挂。--无所事事/想要狗带 2021年6月21日 (一) 08:53 (UTC)[回复]
已就此询问管理员，并无方针、指引讲明公示必须挂Bulletin。公示继续至6月24日。--路西法人 • 留言 2021年6月22日 (二) 02:15 (UTC)[回复]
@LuciferianThomas：
(※)注意:原来提案未发出公告，我现在才看到，请注意涉及重大的共识提案应发出公示公告,并重新公示七天，否则会被认为公告不足，而被质疑共识的合法性。请发出公示公告。--虫虫飞♡♡→♡℃※留言 2021年6月22日 (二) 12:20 (UTC)[回复]
请问阁下在那个方针指引中看到“涉及重大的共识提案应发出公示公告”的说法？且“应”是否指并非“必须”作出此操作？--路西法人 • 留言 2021年6月22日 (二) 23:16 (UTC)[回复]
方针是写得不好，但有相关记述，见wp:共识:“通告板:绝大多数方针与指引页面，以及许多维基百科专题，都为对其感兴趣的编辑提供了通告板。如果一项争议处于某个专题的领域内，或有关于某项方针或指引的具体执行；在通告板上发出请求，将有助于征求熟悉该领域事务编者的意见。”--虫虫飞♡♡→♡℃※留言 2021年6月23日 (三) 00:05 (UTC)[回复]
提案涉及封禁及删除条目，属于重大提案，维基除了方针指引外，也有惯例，您也看到上面有意见说您没有发公示公告；提案没发公示公告，所形成的共识容易受到质疑，人家可以质疑提案公示不足。--虫虫飞♡♡→♡℃※留言 2021年6月23日 (三) 00:03 (UTC)[回复]
我的天，你引用的通告板的时候有看清楚吗？那段是说明征求外部意见的方式，并不是用来说明公示。更何况，能公示的提案本身就有一定的共识了，如果提案没有共识，怎么能公示呢？请你引用方针的时候，不要断章取义。 2021年6月24日 (四) 02:22 (UTC)[回复]
（编辑冲突）反正没有明文规定也不能怎样。--路西法人 • 留言 2021年6月24日 (四) 02:25 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

后续提案

@Ohtashinichiro、Itcfangye、Arronwan、EclipsedL、Temp3600、忒有钱、Dabao qian、TNLHK。--路西法人 • 留言 2021年6月24日 (四) 02:25 (UTC)[回复]

写入方针或指引

此可写入方针或指引，但需要参考诸位意见决定应当写入WP:FAN、Wikipedia:格式手册/电视还是WP:NOT。--路西法人 • 留言 2021年6月24日 (四) 02:25 (UTC)[回复]

延伸至电视节目以外的无来源爱好者内容

（根据忒有钱提议）是否将此限制延伸至电视节目以外的无来源爱好者内容？--路西法人 • 留言 2021年6月24日 (四) 02:25 (UTC)[回复]

“延伸至电视节目以外的无来源爱好者内容”感觉有点扩大解释了？而且有WP:资料页的存在来规范字面的情况。好像没有这个讨论的需要。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年6月24日 (四) 03:30 (UTC)[回复]
我不知道，当初也不是我提出的。我看忒有钱提出的似乎都是节目列表，而这个本来没有共识，那可讨论了吧？--路西法人 • 留言 2021年6月24日 (四) 03:33 (UTC)[回复]
也就是不限于类似综艺电视节目，可能还包括类似电视剧等的“系列/集数/册数/话数列表”？那不反对讨论。不过我觉得如果没有单独的来源支撑的话，最终还是合并回主条目为较好的处理——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年6月24日 (四) 03:44 (UTC)[回复]
  • 实际上既然已经对电视综艺做出处理和相关条例，那很大程度可以推至ACGN（事实包含于电视节目、电视剧等）再加处理。至于电影续集/系列则大多数符合关注度并且基本不存在因原创研究等以至于提删之现象（也就是剧情那部分，条目本身问题不大，因为抄袭侵权删除的条目最后大多也被删后重建）。本质上AGCN属于网络/电视动画的一部分，我觉得做推及没有问题，但基于其性质并非真人秀等，可对方针稍作放松。--🌒-🌖 2021年6月24日 (四) 05:53 (UTC)[回复]
  • ACG可不是这么容易就能处理的...--Temp3600（留言） 2021年6月27日 (日) 01:36 (UTC)[回复]

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

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:封禁方针。

现行条文

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

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

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

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

提议条文

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

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

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

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

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

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

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

分案处理

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

第一分案
现行条文

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

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

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

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

提议条文

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

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

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

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

第二分案
现行条文

（原始条文）

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

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

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

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

提议条文

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

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

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

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

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

现行条文

（第一分案条文）

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

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

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

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

提议条文

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

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

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

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

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

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

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

(＋)支持 更多支持理由：

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

--Gluo88（留言） 2021年6月2日 (三) 16:09 (UTC)[回复]

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

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

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

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

合案版本
现行条文

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

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

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

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

提议条文

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

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

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

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

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

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

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

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

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

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

    提议条文

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

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

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

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

    • 第二案
    现行条文

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

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

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

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

    提议条文

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

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

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

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

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

    以上。Itcfangye（留言） 2021年6月3日 (四) 04:48 (UTC)[回复]

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

    分案Alpha

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

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

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

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

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

    提议条文

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

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

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

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

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

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

    分案Beta

    现行条文

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

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

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

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

    提议条文

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

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

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

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

    以上。@AT、蟲蟲飛、Temp3600。SANMOSA Σουέζ 2021年6月12日 (六) 14:42 (UTC)[回复]

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

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

    本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:编辑禁制方针（错误：Wikipedia talk:編輯禁制方針是重定向页面）。

    原标题为：修改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)[回复]
    (＋)支持。--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)[回复]
      @temp3600、itcfangye、sanmosa、gluo88：我昨晚思考了一夜，认为“（认为封禁时间）过短”是一个严重的问题，没有上诉还加封禁期的道理，诚然如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)[回复]

    本讨论章节会维持开放，暂时不按最后意见发表时间存档，直到有关封禁方针的讨论告一段落。欲让机器人存档，请移除本模板。留言请置于本模板上方。

    重写是否在繁简破坏的范畴

    本主题全部或部分段落文字，已移动至Wikipedia talk:繁简处理。执行人：Jimmy-bot（留言） 2021年6月28日 (一) 00:14 (UTC)。[回复]

    设置新的保护类型

    本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:保护方针。

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

    图标 命名 简介
    注册用户保护 受到此保护的页面只有注册用户（不论是非新用户，确认用户或自动确认用户）可以编辑。

    --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)[回复]

    引入延伸确认保护

    延伸确认保护还比较值得讨论。—— 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. 只能由延伸确认用户编辑。

    以上。--虫虫飞♡♡→♡℃※留言 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)[回复]
    这样的话确实和模板保护有点重复。我有个反建议：延伸确认保护可以拿来处理人事任免投票资格。@Lanwi1。SANMOSA Σουέζ 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)[回复]
    (＋)支持设立甚至拔高门槛，wikiscan上的数据显示每月活跃自确至少约占每月活跃用户数的6%~7%，今年上半年至少应有超过2700名自确用户进行过编辑，最近更改的筛选栏中也有对初学者和有经验的编者的区分。是，某些条目生来就是有争议的，这些条目的编辑战可能确实没法避免，但至少设立更高门槛的自确可以让想要参与这些条目的人进一步学习中维的规则和过去的案例，而且引入扩展自确之后也可以对一些有相对较少争议（但总体上仍有较大争议）的条目上半保护（比如0.999…，其实例子还有很多，但是我觉得大部分例子放这会引起部分人的观感不佳，如果执意要找的话，请关注一下各类人人看法不一的意识形态、历史以及性相关内容）。--ときさき くるみ 2021年6月27日 (日) 16:27 (UTC)[回复]
    @Lanwi1：抱歉打扰您，但是我还是想说一下我的看法：引入扩展保护本身可能更多的是防止破坏和阻止一时性急的新编者，而对防止编辑战起到的作用可能不如您所想的那么大，我猜您应该考虑引入仲裁委员会，请求评论和一批更敢于处理问题的管理员（当然这几个都是月经提案），事实上编辑战和编辑争议在现阶段的中维几乎是不可能避免的，即便是仅考虑一些看起来最严格的话题也会有问题：偏执者会拒绝接受0.999…在实数体系下等于1，阴谋论者会认为犹太人、蜥蜴人和共济会秘密的操控着世界，这些甚至连中维日常争议的边还没碰到。--ときさき くるみ 2021年6月27日 (日) 17:37 (UTC)[回复]

    加入对生者传记的定义

    本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:生者传记。

    建议：

    生者传记是在世人物的传记内容（不论其处于哪个条目），会影响到真实人物的生活。

    --Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵～ 2021年6月21日 (一) 05:39 (UTC)[回复]
    @Emojiwiki：你现在是要？-- Sunny00217  2021年6月21日 (一) 10:36 (UTC)[回复]

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

    本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:命名常规 (音乐)。

    下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

    奇怪嘞，机器人怎么又存档了...，根据上次的讨论，本方针以公示超过7天，提案通过。 --Loving You Is A Losing Game 2021年6月26日 (六) 03:48 (UTC)[回复]

    本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

    AFD朴素化

    本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:页面存废讨论。

    反正AFD不计票，像英维那样保留加粗就好了，不必用模板(○)保留。--Fire Ice 2021年6月25日 (五) 15:20 (UTC)[回复]

    您的提议真好，但也要像英维那样删除加粗就好了，不必用模板(×)删除。--虫虫飞♡♡→♡℃※留言 2021年6月26日 (六) 05:24 (UTC)[回复]
    有何不可。甚至加粗也不必。SANMOSA Σουέζ 2021年6月27日 (日) 01:16 (UTC)[回复]

    将WP:命名常规_(技术限制)列为指引

    本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:命名常规 (技术限制)。

    已存档的讨论见此Wikipedia_talk:命名常规_(技术限制)#将Wikipedia:命名常规 (技术限制)列为指引

    跟本案同期且相关之提案《将WP:命名常规_(音乐)列为指引》都通过了，而本案却被存档了。关于Wikipedia:命名常规 (技术限制)，命名常规 (音乐)有部分引用此规范。因此因应命名常规 (音乐)已经列为指引，而该拟列指引所包含“符号使用”一节涉及维基百科的客观技术限制，故拟将命名常规 (技术限制)列为指引。由于还没 公示就被机器人存档，经查，存档之前，从讨论提出的2021年5月26日 (三) 15:09 (UTC)到机器人存档的2021年6月7日 (一) 08:14 (UTC)经过的12天中，基本上也达成列为指引的初步共识的最低标准，且讨论中，偏向反方的意见皆已由支持方回应，同时，在存档前的最后发言时间为2021年5月27日 (四) 03:44 (UTC)，到存档时的2021年6月7日 (一) 08:14 (UTC)已超过一周，可以视为“自最后发言已逾时一周”，因此根据WP:7DAYS已经达捯可以准备开始公示的门槛。由于还没 公示就被机器人存档，因此，这边再提交一次，现就这个版本提案公示七天。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2021年6月26日 (六) 14:13 (UTC)[回复]

    为关注度指引增设“关注度准则之意义”一节

    • 问题的提出：本站现行关注度指引虽指明“如果一个主题得到了可靠来源的有效介绍，并且这些来源独立于主题实体，则可假定该主题或符合独立条目的收录标准”，然而，无论是来源的可靠性、独立性、介绍的有效性，都不是简单非黑即白的概念。究竟多少介绍可谓深入，多有声誉可谓可靠，都没有明确客观的标准。本人多次从站内外渠道接到过部分用户对该指引的投诉。为减小这种模糊性，并引导参与关注度讨论的编者从条目编写的角度考虑问题。拟依英文站现行关注度指引中"Why we have these requirements"的内容，结合本地条文，为本地关注度指引增设“关注度准则之意义”一节，如下所示：

    拟增条文

    快捷方式

    关注度准则并非为条目收录人为、任意地划定的一道门槛——毕竟，维基百科并非印刷品，无限制条目数量之必要。关注度准则设立的初衷，乃是为了确保，为每个符合该准则的主题，皆有可能撰写一篇符合内容方针的合格百科全书条目。具体而言：

    准则 意义
    用以佐证关注度的来源需包含对条目主题的有效介绍。 确保在不进行拼凑来源原创总结的前提下，能够为符合关注度准则的主题能写出一篇基本完整的条目，而非难以扩充的简单定义或只言片语。
    用以佐证关注度的来源须为可靠来源。 确保为符合关注度准则的主题能写出一篇满足可查证性要求，非通篇流言蜚语、虚假资讯、原创研究或琐细信息的条目。
    用以佐证关注度的来源须为独立于主题实体的第三方来源。 确保为符合关注度准则的主题能写出一篇非广告文宣或严重偏颇的条目。
    用以佐证关注度的来源不宜为第一手来源。 确保为符合关注度准则的主题能写出一篇满足非原创研究方针中“应主要依赖二手来源”要求的条目。
    多方来源更受欢迎。 确保为符合关注度准则的主题能写出一篇中立持平、兼顾多方观点的条目。
    关注度准则的满足应视作为某一主题撰写独立条目的必要条件而非充分条件。 在特定情况下，对于符合关注度准则的主题亦可能有更好的呈现方式（例如，合并至母主题的条目中加以介绍）而无需独立成文。关注度准则并不为此等建设性的编辑行为设下限制。

    运用关注度准则衡量条目主题的关注度时，请编者以上列目标为先，合理把握尺度。

    意见区

    该增订妥否？请社群审议。--Antigng（留言） 2021年6月27日 (日) 18:51 (UTC)[回复]

    (－)反对提案有多处与现行条文相抵触及矛盾:
    1. 第一、二、四、五点与现行条文重复，没必要再赘述。
    2. 现行条文的“独立于第三方”是指主题和来源“利益冲突”，包括但不限于付钱打广告，现行条文比修订条文较好，也更符合方针精神。
    3. 现行合并的最合理理据是关注度不足及主题重复，提案却以模糊的标准“更好的呈现方式”来增加合并的借口，与现行条文也相抵触及矛盾。
    4. 本站GNG门槛已经很高，提案是把GNG的门槛再次提高。
    5. 我经常收到用户投诉，现在已经有不少用户热血提删，胡乱提删本来已经符合关注度的条目；而且无故提高关注度门槛会令现存的条目也要删去。
    以上。--虫虫飞♡♡→♡℃※留言 2021年6月27日 (日) 23:00 (UTC)[回复]
    (：)回应@蟲蟲飛：：
    1. “第一、二、四、五点与现行条文重复，没必要再赘述”：该修订旨在解释现行条文存在的意义，自然在表述上力求与现行条文一致。现行条文只是孤立地叙述“独立可靠来源有效介绍”等等要求，而该修订则在解释这其中每一个限定的意义乃至所预期达成的目标。
    2. “现行条文的“独立于第三方”是指主题和来源“利益冲突”，包括但不限于付钱打广告，现行条文比修订条文较好”：现行条文的表述是“并且这些来源独立于主题实体”，本案在“准则”部分采用的表述是“用以佐证关注度的来源须为独立于主题实体的第三方来源”，并指出该修订的目标是为了避免出现“广告文宣”和“严重偏颇”的问题，并未有限于“广告”的情形。本人看不出该份说明中的表述与现行条文有何冲突之处。
    3. “现行合并的最合理理据是关注度不足及主题重复，提案却以模糊的标准“更好的呈现方式”来增加合并的借口，与现行条文也相抵触及矛盾。”：该条来自于现行条文中“意味着可靠来源的有效介绍只构成必要条件，而不能保证某主题一定能收入维基百科。即使某个主题符合上述标准，编者们也有可能达成共识，认为不应该为其另立一篇条目”一条，在表述方式上与该条相一致，未见抵触和冲突之处。
    4. “本站GNG门槛已经很高，提案是把GNG的门槛再次提高”：这不是事实。由以上分析可知，本修订相当于为现行GNG条文作一个“法律解释”，而没有对GNG的门槛进行大幅度的提高或降低。
    5. “我经常收到用户投诉，现在已经有不少用户热血提删，胡乱提删本来已经符合关注度的条目；而且无故提高关注度门槛会令现存的条目也要删去。”：恰恰相反，本案第一句即阐述“关注度准则并非为条目收录人为、任意地划定的一道门槛——毕竟，维基百科并非印刷品，无限制条目数量之必要”，并在最后要求编者“以上列目标为先，合理把握尺度”。这反而有利于抑制您所述的这种不顾条目实际“热血提删”的行为，而非助长之。--Antigng（留言） 2021年6月28日 (一) 02:17 (UTC)[回复]
    (？)异议
    1. 请看一下现行条文吧，除了正文，还有脚注，基本上您要解释的东西，方针都已经有记述，不用再重复。
    2. GNG的“来源独立于主题”是意思避免“利益冲突”，详见脚注四，这也符合方针精神，因为如果是媒体自己访问自己员工或老板，或者您付钱打广告，这就不能反映您因为有知名度而受到访问，而是因为您和媒体有关系。但您改为“广告”，就和方针精神有差异，而且范围扩大了。前者是找证据证明来源与主题“有没有关联”或“利益冲突”，但后者就在考究一篇专访文章的语句是否中立问题，而且这个标准是很主观，而且专访语句与“来源独立于主题”是没有关系的。
    3. 提案声称“本修订相当于为现行GNG条文作一个“法律解释””，但实际上对来源及合并要求都提高了门槛，提案既以“释法”为目的，但实际却提高了GNG要求，因此提案已经不成立。
    4. “抑制您所述的这种不顾条目实际“热血提删”的行为”也不成立，详见上面几点论述。
    以上。--虫虫飞♡♡→♡℃※留言 2021年6月28日 (一) 02:47 (UTC)[回复]
    @蟲蟲飛：(：)回应
    1. “基本上您要解释的东西，方针都已经有记述”并不是事实。以本人引入的第一条解释为例，其指出，“有效介绍”是为了在不进行原创总结的情况下写出一篇基本完整的条目，而非简单定义或只言片语。这里提及了三个概念：原创总结、简单定义（条目不是词典解释）、只言片语（小小作品），皆是既有条文所不涵盖的。“要解释的东西，方针都已经有记述”无从谈起。
    2. “但您改为“广告”，就和方针精神有差异，而且范围扩大了”。并非如此。本人没有将“独立于主题实体”、“主题与来源不得存在明显利益冲突”的要求改为广告；而是在解释，考察独立性的目标是要确保依据该等来源写出的条目没有“广告宣传”或“严重偏颇”的问题。这有利于为“关联”和“明显利益冲突”划下相对明确的界限。科学工作者可能因研究其所研究的对象而获得资助；第三方咨询机构可能因为向某一实体提供咨询服务而获取薪酬；政府有介绍本地事物的倾向；某一媒体可能在形式或实质上受到某个团体或政党的控制。但这些都算“关联”、“明显利益冲突”么？不尽然吧。这些情况下就要考量，这种潜在的利益关联是否足以使得其支持的条目内容“严重偏颇”乃至沦为“广告宣传”。
    3. 基于以上两条，3/4中的异议没有说服力。--Antigng（留言） 2021年6月28日 (一) 03:14 (UTC)[回复]
    (：)回应
    1. 重复的部分，如果您希望再说明，我不反对，但您把“来源独立于主题”新加了不同的附加条件，令来源更难符合GNG要求，我还是(－)反对；此外您把“合并”的要求改为以模糊的标准“更好的呈现方式”来增加合并的借口，我也是(－)反对
    2. “来源独立于主题”重点是“利益冲突”，新加了不同的附加条件，令来源更难符合GNG要求。
    3. 基于上面两点，提案的“释法”目的已经不成立。
    以上。--虫虫飞♡♡→♡℃※留言 2021年6月28日 (一) 03:26 (UTC)[回复]
    (？)疑问，关于合并的问题，请问“在特定殊情况下，编者亦可能通过讨论达成共识，认定对于某一符合关注度准则的主题亦可能可以有更好的呈现方式（例如，合并至母主题的条目中加以介绍）而无需独立成文。关注度准则并不为此等建设性的编辑行为共识的创建设下限制。”这种表述您是否能接受？--Antigng（留言） 2021年6月28日 (一) 03:45 (UTC)[回复]
    (－)反对现行方针很全面，而且要求已经很高，没有必要在进一步提高门槛，否则没有什么条目了，外面已经有论坛对中维乱删条目表示不满。大部分创建者和编辑者对于每个条目都花了很多心血和时间，除非条目有明显的质量问题，不应该动不动就以关注度来作为提删理由。Sammypan（留言） 2021年6月27日 (日) 23:31 (UTC)[回复]
    (：)回应@Sammypan：，该案未“进一步提高”关注度门槛，而恰恰是在解释关注度门槛与写出的条目可能存在的质量问题之间的关联性。--Antigng（留言） 2021年6月28日 (一) 02:23 (UTC)[回复]
    您的提案本意可能没有“进一步提高”关注度门槛，但您把英维对GNG的解释套进中维，不但与本站方针原意不一样，而且间接提高了GNG门槛。--虫虫飞♡♡→♡℃※留言 2021年6月28日 (一) 03:05 (UTC)[回复]
    该案的蓝本是en:WP:WHYN不错。但您也可以看出英文条文与该草稿之间存在者一定程度的差异。例如英文条文的表述是"we require multiple sources"，这里则根据本地条文弱化为“多方来源更受欢迎”；英文条文的表述是"we require at least one secondary sources"，这里根据本地条文放宽到“非一手来源不宜用于论证关注度”（既包括第二手来源也包括第三手来源）。在有差异的地方，该案都遵照本地条文处理，不应出现“间接提高了GNG门槛”的问题。--Antigng（留言） 2021年6月28日 (一) 03:19 (UTC)[回复]
检索自“https://zh.wikipedia.org/zhwiki/w/index.php?title=Wikipedia:互助客栈/方针&oldid=66312157”