跳转到内容

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

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

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

按此刷新页面。

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

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

查看全部讨论

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

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

消息

Sub-referencing: User testing

Apologies for writing in English, please help us by providing a translation below

Hi I’m Johannes from Wikimedia Deutschland's Technical Wishes team. We are making great strides with the new sub-referencing feature and we’d love to invite you to take part in two activities to help us move this work further:

  1. Try it out and share your feedback
    Please try the updated wikitext feature on the beta wiki and let us know what you think, either on our talk page or by booking a call with our UX researcher.
  2. Get a sneak peak and help shape the Visual Editor user designs
    Help us test the new design prototypes by participating in user sessions – sign up here to receive an invite. We're especially hoping to speak with people from underrepresented and diverse groups. If that's you, please consider signing up! No prior or extensive editing experience is required. User sessions will start May 14th.

We plan to bring this feature to Wikimedia wikis later this year. We’ll reach out to wikis for piloting in time for deployments. Creators and maintainers of reference-related tools and templates will be contacted beforehand as well.

Thank you very much for your support and encouragement so far in helping bring this feature to life!

Johannes Richter (WMDE) (talk) 2025年4月28日 (一) 15:04 (UTC)[回复]

Wikidata weekly summary #677

Here's your quick overview of what has been happening around Wikidata in the
week leading up to 2025-04-28. Missed the previous one? See issue #676.
Translations are available

Discussions

Events

Press, articles, blog posts, videos

Tool of the week

  • quarry.wmcloud.org is a public querying interface for Wiki Replicas, a set of live replica SQL databases of public Wikimedia Wikis. Quarry is designed to make running queries against Wiki Replicas easy. Quarry can also be used to query public databases stored in ToolsDB.

Other Noteworthy Stuff

  • Scholia is running a user survey until the end of May .
  • Researchers from the University of Regina in Canada invite you to participate in the Open Data Community Survey 2025. Read more!

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

  • Bug: We fixed an issue where newly created Properties became inaccessible after adding a statement with a Property linking to an Item or Lexeme. The fix will go live on Wednesday. (phab:T374230)
  • Search: We continued implementing the new search that will make it easier to search for Properties and Lexemes in the UI (phab:T321543)

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

对《通用行为准则执行规范及其协调委员会章程》的修订投票

《通用行为准则执行规范及其协调委员会章程》修订案的投票期将于世界协调时 (UTC) 2025年5月1日23:59结束（在您的时区查找对应时间）。请在 Meta-wiki 上的UCoC页面投票前，阅读关于如何参与的说明并仔细审阅提案。

通用行为准则执行规范协调委员会(U4C)是一个全域性的组织，致力于公平、一致地实施UCoC。本年度审查由U4C规划和实施。如需更多资讯和 U4C 的责任，您可以检阅U4C的章程。

请酌情以您的语言与您的社群成员分享此讯息，以便他们也能参与。

与U4C共同合作 --

Keegan (WMF) (talk) 2025年4月29日 (二) 03:41 (UTC)[回复]

The Signpost: 1 May 2025

News, reports and features from the English Wikipedia's newspaper

Wikidata weekly summary #678

Here's your quick overview of what has been happening around Wikidata in the
week leading up to 2025-05-05. Missed the previous one? See issue #677.
Translations are available

Discussions

  • Closed request for permissions/Bot: Mr Robot - No consensus reached.

Events

Press, articles, blog posts, videos

Tool of the week

  • OpenStreetMap: OpenStreetMap, is a project that creates and distributes free geographic data for the world. It was started because most maps you think of as free actually have legal or technical restrictions on their use, holding back people from using them in creative, productive, or unexpected ways .

Other Noteworthy Stuff

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know ?

Development

  • Wikidata Query Service: The search platform team finished the remaining work for the graph split and it is going live this week.
  • We took part in the Wikimedia Hackathon in Istanbul
  • Wikipedia and co: We continued working on improving how Wikidata edits are shown on the watchlist on Wikipedia and co. We are focusing on showing labels instead of IDs for the entities (Items, Properties, ...) linked in the edit summaries (phab:T388685)
  • UI: We continued doing small fixes for dark mode support in the UI (phab:T385039)
  • Wikibase REST API: We are continuing the work on the search endpoint (phab:T383126)

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

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

带您快速了解维基媒体基金会自上一期公报〔4月18日〕以来的亮点。请协助翻译。

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


年度目标进展 基础设施
参见其他电子报：维基媒体App · Growth · 研究 · 网页 · 维基函数与抽象维基百科 · 技术新闻 · 语言与国际化 · 其他MediaWiki.org电子报


年度目标进展 知识公平
参见：维基媒体运动活动的清单 · WikiLearn新闻


年度目标进展 安全与诚信
参见博客：全球倡议博客 · 全球倡议电子报 · 政策博客


年度目标进展 有效性
参见：季度指标报告


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


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

订阅或退订 · 协助翻译

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


MediaWiki message delivery 2025年5月6日 (二) 20:00 (UTC)[回复]


方针

再议明确WP:NOR方针对模板的适用性

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:非原创研究、Wikipedia talk:导航模板。

本准备移动WP:互助客栈/其他#再议Wikipedia:页面存废讨论/记录/2025/01/17#批量提删，但没找到移动讨论的脚本，在此发起讨论，另希望在对NOR方针的讨论得出结果之前不要再对单一涉及NOR争议模板的存废进行复核。Python6345（查论编） 2025年3月30日 (日) 16:37 (UTC)[回复]

关于导航模板是否受NOR方针限制，双方意见的总结：

先前意见总结

应该受到限制的意见

  • 模板被放置于条目空间。
  • 列表类导航模板上仅收录部分元素可能会误导读者认为相关内容只有这些。
  • 已有相关涉原创总结列表被删除，即使在其他语言存在。

不应该受到限制的意见

  • 导航模板仅用于提供便利，不属于原创总结。
  • 导航模板很难让读者误认为是一个新结论。
  • 很多条目会列出相关条目，因此导航模板没有问题。
  • 模板无法用于发表和暗示新观念。

其他意见

  • 列表类导航模板的内容应当照单全收，或明确收录门槛，否则容易出现原创研究。主题类导航模板一般不会有问题，但因不同编者认知不一样，如出现比较混乱情况，则应确保可靠来源以避免原创总结的问题。
  • 应该像列表一样为模板单独制定收录标准。
  • 导航模板在数目和子分类存在变化空间，容易出现原创研究，需要详细标准。
  • 借鉴英维指引制定本地指引。
  • 条目名称必须有来源，但章节标题通常很难找出具体来源。
  • 在条目内有提及即可作为依赖。

各方意见最后由Python6345（查论编）整理于2025年5月6日 (二) 10:09 (UTC)[回复]

讨论区

参见：Wikipedia_talk:非原创研究/存档4 § 关于WP:非原创研究方针是否适用于模板；以及判定模板为“原创研究”的客观标准
参见由Zhenqinli加于2025年3月31日 (一) 05:00 (UTC)。 ——自由雨日🌧️❄️ 2025年3月31日 (一) 05:08 (UTC)[回复]
  • 虽然本讨论的发起者“总结”了双方的意见，但很遗憾，我并未从中看到我的意见。如果是发起者自己总结的，我仍表示感谢；如果是借助AI总结的，我只能再度表示我向来对AI的排斥以及对“若使用AI，必须声明”的立场。我的意见见@U:猫猫的日记本半年前在《非原创研究》讨论页的留言。另邀请@Sanmosa关注本讨论。 ——自由雨日🌧️❄️ 2025年3月30日 (日) 17:37 (UTC)[回复]
    我在原讨论看到你声称在任何条目选择写入什么内容都是“主观选择”。这些模板违反NOR的原因是暗示“巴黎名胜包含且仅包含这些元素”。我认为将其总结为会导致读者误认为相关内容只有这些是合理的，如果你认为有误，或有其他我整理时未注意的意见，请修改整理意见或告知我。
    另外我是人工整理未使用AI。Python6345（查论编） 2025年3月31日 (一) 01:23 (UTC)[回复]
补充了U:猫猫的日记本的意见。Python6345（查论编） 2025年3月31日 (一) 01:46 (UTC)[回复]
我“在任何条目选择写入什么内容都是“主观选择””一句的前半句是“我从来不认为“主观选择”是NOR”（注意是逗号连接，和后方则是句号连接）。后面也在大段强调了我对大部分列出“相关内容”的导航模板都没有类似的标准（即猫猫的日记本总结的“主题类导航模板”），而且留言的最后又列出了过往讨论的链接（例如里面就可以看到简单的例子）。总结确实是一项不容易的工作，值得鼓励，但我认为既然总结，就应当全面阅读所有过往讨论以防止片面。猫猫的日记本的意见其实就是对我的观点的总结（当然，他条理清晰，且提出新“术语”的完美总结已经可以说完全超出了“总结”了）。
你刚刚补充的猫猫的日记本的意见（86634608）我仍认为对“列表类导航模板”的描述完全不准确（甚至相反）。他（也是我）的主要意思很明显是，“列表类导航模板”应当照单全收，或明确收录门槛，否则容易导向原创研究，即主要规制的列表类而非主题类（最近提删的也大多是“列表类导航模板”），上述总结直接反了。 ——自由雨日🌧️❄️ 2025年3月31日 (一) 02:32 (UTC)[回复]
改好了，另阅读了之前的过往讨论，补充了几条意见，另邀请@U:0xDeadbeef参与讨论，英维相关指引有哪些本地可以借鉴。Python6345（查论编） 2025年3月31日 (一) 03:42 (UTC)[回复]
“导航模板上进行原创研究会导致读者误认为相关内容只有这些。”这句应该可以删了？似乎没有人表达过类似的观点（而且您说就是跟我说的总结的）。就我的观点而言，是“对有确定元素的集合（例如 Harry Potter 系列有7本书）只收录其中一些元素（例如4本）会错误暗示只含部分元素（例如该系列只含4本书），所以应全收或明确收录范围”，这只涵盖一小部分模板即猫猫的日记本说的“列表类导航模板”，并未扩展到所有模板（例如{{藏传佛教}}模板就根本就不是一个“有确定元素的集合”，而是一个“主题”）。此外，也不是“进行原创研究会导致……”（逻辑上反了，是仅收录一些元素 —导致-> 读者误认为进而 —导致-> 违反原创研究——而非“进行原创研究导致……”）。 ——自由雨日🌧️❄️ 2025年3月31日 (一) 03:56 (UTC)[回复]
修改了一下总结意见。Python6345（查论编） 2025年3月31日 (一) 04:54 (UTC)[回复]
最近没啥时间看，如果还需要这周末再ping我一次。--beef [talk] 2025年4月2日 (三) 02:05 (UTC)[回复]
我没有参与半年前的讨论，但我的意见是WP:非原创研究适用的对象是显示于条目中的内容，如果导航模板本身放置于条目，那该导航模板自然是显示于条目中的内容，并因而受到WP:非原创研究的规制。因其为模板而声称其不适用WP:非原创研究实际上是在试图以不修订WP:非原创研究的方式绕过WP:非原创研究的必要规制。Sanmosa 新朝雅政 2025年3月31日 (一) 01:37 (UTC)👍 自由雨日觉得这挺赞的。[回复]
但我需要补充一点，就是如果导航模板本身并不放置于条目，而且并不预期将被放置于条目，那WP:非原创研究与该导航模板本身并无任何直接关系。Sanmosa 新朝雅政 2025年3月31日 (一) 06:27 (UTC)[回复]
是的。我觉得上面两点应当是常理才对……大半年前Shizhao亦这么说过。 ——自由雨日🌧️❄️ 2025年3月31日 (一) 06:31 (UTC)[回复]
同意。所以这可以衍生出另一个做法，将疑似是原创研究的导航模板从条目中移除就好，而不需要删除到导航模板本身。--Justin545（留言） 2025年4月10日 (四) 04:47 (UTC)[回复]
不放在条目中的“导航模板”，存在价值可疑，该做法恐怕很难用到。--YFdyh000（留言） 2025年4月11日 (五) 10:03 (UTC)[回复]
是的，所以导航模板在从条目中移除后需要经过“调整”后再重新放入条目。而不是直接“销毁”，如此不符合环保的原则，少了物尽其用的概念，也相当是代表完全不给予任何“改进”的空间与机会，而与wp:不要伤害新手的指引不相符。--Justin545（留言） 2025年4月11日 (五) 11:03 (UTC)[回复]
条目所有内容（含模板）适用非原创研究，但不能将任何东西都归于原创研究、暗示观点。假如我说脚注1放在脚注2前面是暗示观点，信息框字段排列也暗示观点，难道能找来源反驳吗。共识下的合理范围内的疏漏、调整或便利性该被允许，异议者请提供合理建议（必须删除/必须标注/补充来源/优化写法/……），而不是扣个帽子一删了之。--YFdyh000（留言） 2025年3月31日 (一) 04:49 (UTC)[回复]
（至少我从未说过这些会暗示观点，我只针对客观上非常明确含有哪些元素的集合。我对扩大化“暗示”的解读也是强烈反对的。） ——自由雨日🌧️❄️ 2025年3月31日 (一) 04:57 (UTC)[回复]
同意。如果不符合方针或指引的删除规范，导航模板的删除我认为应该是最后的手段，异议者应提出意见，给予导航模板作者当作改进的参考。--Justin545（留言） 2025年4月10日 (四) 04:40 (UTC)[回复]
我觉得导航模板的排列方式不应该视作原创研究，因为分类笼统而不足以暗示某种“观点”者亦很多（例如按年份列出历史事件能算原创研究吗？），而有时收录架构也不是删除的理由（收录不完整不等于原创研究），所以应该总是个案探讨。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月1日 (二) 14:36 (UTC)[回复]
阅读同类模板和列表类条目后我认为对于列表类导航模板应确保模板列出条目符合WP:收录标准并告知读者可能不完整。另可参见WP:独立列表制订导航模板指引。Python6345（查论编） 2025年4月7日 (一) 05:27 (UTC)[回复]
我认为任何导航模板都应尽量确保所列出条目为独立条目（类似Python6345所说的符合或潜在符合收录标准——不过不完全一样，因为符合收录标准并不一定必须创建独立条目）。导航模板和重定向/消歧义不一样，后者用于帮助读者搜索，输入一个词跳转到介绍该词的内容，完全可以作为子主题跳转到条目对应章节内容（无歧义时直接重定向，有歧义时重定向后再加消歧义顶注/用独立消歧义页平等消歧义等）；但导航模板应主要在独立条目之间进行导航。不过若某个集合无法满足所有条目为独立条目，我的处理意见并非“告知读者可能不完整”，而是——若绝大多数是（或可成为）独立条目，则允许余下列出部分非独立条目通向某条目的一个章节等；若有较多无法成为独立条目，则限定范围（如一定面积以上的湖泊）以尽量使绝大部分可成独立条目。总之仍认为“尽量枚举”。 ——自由雨日🌧️❄️ 2025年4月7日 (一) 05:38 (UTC)[回复]
我想我还是说个两句吧：一个可以和导航模板对比的是分类。Wikipedia:分类、列表与导航模板似乎也是认为如此。在我看来，导航模板是分类的延伸与补足。
我们不会对分类，提出如条目本身那么严格的原创研究标准，至少我是没看过哪个分类非要有可靠来源支持不可；但这不代表什么分类都能放：乱放分类也会被回退。我想，我们对导航模板的收录标准，应该要比照性质相近的分类：也就是不强求条目般的原创研究，但必须满足一目了然、还有Wikipedia:中立的观点。--Saimmx（留言） 2025年4月13日 (日) 15:56 (UTC)[回复]
这些话我均认为有待商榷乃至基本不正确。以原创研究为例，我和你的感受完全相反，分类几乎均要有可靠来源支持，甚至很多时候要比条目内容还要严格（须是“无可争议的事实”）。 ——自由雨日🌧️❄️ 2025年4月13日 (日) 16:37 (UTC)[回复]
“分类几乎均要有可靠来源支持”与“须是‘无可争议的事实’”，如果能提供相关连结或举例说明，会不会比较清楚？--Justin545（留言） 2025年4月13日 (日) 17:07 (UTC)[回复]
“分类几乎均要有可靠来源支持”我没找到，但“无可争议的事实”我倒是能给。维基百科:页面分类#几点重要的共识说明：除非显而易见而且没有争议（例如张国荣一定是香港人），不然不要对条目归类。请您宁可先到分类的讨论页提出问题，也不要贸然分类。--Saimmx（留言） 2025年4月13日 (日) 17:10 (UTC)[回复]
后者已经暗含了前者。如果分类是没有争议的事实，他们要么是“verifiable, even if not verified”（用中维的话说就是，不对孙中山是男性提供来源，这在“来源”指引层面尚可以成为问题，但NOR层面的问题无法成立）的内容，要么是已在条目中已出现的有inline citation（文内引注）的内容（尤其是首句定义句；分类一般都是定义性特征）。如果分类出现争议（编者间的争议，而非可靠来源中本身的争议），如何说明某个页面是否需要加入某个分类，当然是通过可靠来源，而非通过编者主观分析（若这种争议性内容最终认定为加入分类，则必然应在条目中出现，且具文内引注）。总之，分类在技术上没有ref ≠ 分类无需满足非原创研究要求。 ——自由雨日🌧️❄️ 2025年4月13日 (日) 17:40 (UTC)[回复]
方才@Nostalgiacn就因“无来源”移除了几个条目中的某分类（如86833074）。 ——自由雨日🌧️❄️ 2025年4月15日 (二) 06:51 (UTC)[回复]
为什么分类要来源，不纠结于具体条文，给一个简单易懂的，用常识就能理解的例子。现实人物，有编者在不提供任何资料下，加入一个“2025年去世”，其他编者是否应该去质疑这个判断是准确性，如果没资料证明这个人物真的去世了，默认应该不加这个分类（WP:BLP）.--Nostalgiacn（留言） 2025年4月15日 (二) 07:35 (UTC)[回复]
经过三位的说明，确实是比较清楚了。这样的话我想到了：
方针和指引如果对于条目中的“标题名称”或“章节名称”（== 標題名稱 ==）没有给出明确的规范，根据NOR，标题名称 是否也需要有来源依据？
除了这里说的“导航模板group名称”，“附录”中也可能带有原创研究或观点，因此“注释、相关条目、外部链接、延伸阅读、...”是否也需要有来源依据？
另外，更基本的，是关于“方针和指引”在诠释或解读的方面：
可能没有说明“适用范围”
导航模板group名称、标题名称、讨论页、知识问答、...是否被包含在NOR的适用范围里？
条目中 数学式的推导 是否属于原创研究？是否被包含在NOR的适用范围里？
模糊、灰色地带
不少方针和指引依赖于“常识”判断，或以“合理”作衡量标准，所以“常识”、“合理”的 "明确" 定义是什么？
不自洽、矛盾 或 冲突
五大支柱提到：“请您大胆但不要轻率地去编辑、移动或修改条目”，或是“忽略所有规则”，当方针和指引发生矛盾时应该如何解决？
--Justin545（留言） 2025年4月16日 (三) 01:35 (UTC)[回复]
  1. 要对“章节名称”给出来源，说真的，实在是很困难，如果不是不切实际的话。我想不透要怎么做。“标题名称”见命名常规。
  2. 有关附录：
    • 注释：这个需要来源，但用语解释或明显事实或许能以WP:孙中山为由省略来源。我觉得没有大疑问。
    • 相关条目：这个我自己比较不太确定。不过看格式手册，需要靠共识决定。
    • 外部链接：请参考外部链接。
    • 延伸阅读：对来源做出取舍或许是编者的原创研究，不过这应该是必要的。延伸阅读我认为应如是。WP:LAYOUT#延伸阅读：延伸阅读……目的是编辑者透过推荐合理数量的出版物帮助有兴趣的读者了解更多关于条目的内容主题……延伸阅读所提到的内容也不应该与外部链接或者是参考资料部分有所重复。另外延伸阅读其目的……希望读者能透过延伸阅读来作为创建条目的参考资料。
--Saimmx（留言） 2025年4月16日 (三) 04:37 (UTC)[回复]
“要对‘章节名称’给出来源，说真的，实在是很困难，如果不是不切实际的话。我想不透要怎么做”，这确实也与目前多数看到的标题符合，个人经验几乎没印象有看过在标题加注来源。--Justin545（留言） 2025年4月16日 (三) 08:12 (UTC)[回复]
适用范围：WP:NOR有说明是适用于条目。所以讨论页与知识问答不包含。数学式的推导不属于原创研究。标题名称则按照命名常规处理。可能不是原创研究的事。
常识：一个难以理解的概念。有些人甚至认为不存在（平衡报导）。我觉得应该是没有明确的定义。
忽略所有规则：与常识有关。我会说要靠共识解决。见File:Diagram of IGNORE zh-hans.png。--Saimmx（留言） 2025年4月16日 (三) 04:51 (UTC)[回复]
对常识的理解，确实是因人而异，也许某些常识只是 某一小群人 在某一段时间内与特定的地点上 所具有的共识。可惜认为不存在最后那句：“所以，在维基百科遇到任何问题，请依照方针和指引来解决。”，有一点循环论证的味道，因为如同我前面提到“不少方针和指引依赖于‘常识’判断”。--Justin545（留言） 2025年4月16日 (三) 08:28 (UTC)[回复]
NOR是内容方针，一切条目内容都需要满足NOR。标题毫无疑问要满足NOR，不信你可以取个原创译名试试。附录等当然也要满足NOR，前段时间就有用户在某个介绍《1984》中某事物的条目中加入朝鲜相关条目而被我回退。另外（我不知道你是否有混淆），NOR是限制编者提出新观念、发表不可靠来源中的观念，或排列组合（常使用关联词）可靠来源中的信息来暗示新结论；而不是“任何内容都要文内引注”。不妨再看下这条留言。 ——自由雨日🌧️❄️ 2025年4月16日 (三) 05:05 (UTC)[回复]
译名确实是个问题，像是台湾通常称“川普”，而大陆可能常称“特朗普”，直接用原文可能是快速的解法，但方针或指引有较好且不模糊的规范我认为是更理想。--Justin545（留言） 2025年4月16日 (三) 09:13 (UTC)[回复]
“the statement "the capital of France is Paris" does not require a source to be cited, nor is it original research, because it's not something you thought up and it is easily verifiable; therefore, no one is likely to object to it and we know that sources exist for it even if they are not cited. The statement is verifiable, even if not verified.”，这个法国首都是巴黎的例子，因为它举例的是国际知名的地点，我想确实大部分人都知道，不过如果地点被换成是偏乡的地名，那么是否引注可能是新的问题，这时可能就是考验“常识”的时侯了，常识对不同背景的人来说可能会不同，导致意见分歧是有可能的，所以可能会回到前述基本的“方针和指引”在诠释或解读方面的问题。--Justin545（留言） 2025年4月16日 (三) 09:34 (UTC)[回复]
有些观点槽点过多，“章节名称”我倒是可以说几句，其实各专题有样式（如WP:VG），英维那边其实各类条目都有样式的，比中文齐全多了。另外“章节名称”可以编者自定，是根据条目文段的内容取名的，“章节名称”和章节内容是强相关的，不能乱起名。例如一个章节的内容是关于作品的创作背景，取名“今天是周三”，绝对会被改掉，不予保留。--Nostalgiacn（留言） 2025年4月16日 (三) 06:43 (UTC)[回复]
“有些观点槽点过多”这指的是什么呢？--Justin545（留言） 2025年4月16日 (三) 09:18 (UTC)[回复]

讨论已进行一段时间，我阅读NOR方针提到的原创研究和原创总结认为，其设立目的是为确保条目内容不会误导读者，因此想向各位参与讨论的人(？)疑问：如果根据已收录条目编辑主题类导航模板，根据常识尽可能将列表类导航模板的内容填全（需符合收录标准或在已收录条目有独立章节介绍），在可能不全的导航模板声明可能不全。是否可能出现误导读者的原创研究？Python6345（查论编） 2025年4月20日 (日) 11:37 (UTC)[回复]

在列表不全的导航模板附上可能不全的声明，类似于条目的作法，这也是避免直接删除导航模板非常不错的方法。因此，于导航模板加上声明，或是暂时将有问题的导航模板呼叫从条目内容中暂时移除并改善导航模板，两种方式都能有效地避免NOR及误导读者的问题，目前看来已经没有直接删除导航模板的必要性。--Justin545（留言） 2025年4月20日 (日) 22:21 (UTC)[回复]
（对“列表类导航模板”而言）如果作类似声明，在一些导航模板可以避免误导读者（如《中国湖泊》），另一些则仍有原创研究问题（如《巴黎名胜》）。关键就在于这个集合本身是客观存在（只是没列全）还是编者自行综述的。 ——自由雨日🌧️❄️ 2025年4月21日 (一) 00:40 (UTC)[回复]

没错，集合是客观存在的，甚至集合的成员是随着时间或条件而改变的（如：名胜的除名与新增）。如果集合发生变动时，相关的列表也能“即时地”更新，让列表与集合同步，这是最理想的情况。

条目本身可能也有类似的情况，条目的内容也可能是过时的资讯，此外其实目前还有为数不少的条目是属于内容较缺乏深度与广度的小作品（stub）（见Category:小作品类别），其中一部分是类似于work in progress的状态。当然理想上如果能一步到位，在条目建立的当下就让它变成完美条目是再好不过，不过严格要求一个条目在广度上要 无所不包 这在实行上会有一定的困难，因为贡献者对条目所知道的有限，可以用在维基上的资源也有限（许多是忙碌上班族/学生，时间较不自由），所以要靠众人的力量让条目趋近于完美，这中间通常会有一段可长可短的 过渡期 是处于非常不完美的状态。

假如 列举不全 与 资讯不完整 被视为原创研究或原创总结，可能就会有些类似将小作品的条目也当作原创研究或原创总结的概念。个人认为比较有建设性的是设法去编辑它并完善它，这可能会比直接删除相对较好也较友善。

--Justin545（留言） 2025年4月21日 (一) 02:20 (UTC)[回复]
我从未说过“将小作品的条目也当作原创研究或原创总结”，我一直都在强调只有“列表类的元素列举不全”（实例就看看{{除名太平洋台风名称}}）才会有此问题。我也没见到这里有其他人主动提到非列表的普通条目，请阁下不要再像这里的讨论一样长篇大论地发散。 ——自由雨日🌧️❄️ 2025年4月21日 (一) 08:11 (UTC)[回复]
是的，您讲到了一个重点，并没有看过您说过“将小作品的条目也当作原创研究或原创总结”。而我的意思是 条目 与 列表 在 原创总结概念上 很可能是“相关的”，所以我提到“条目本身可能也有‘类似’的情况”，“列表类的元素列举不全”与“小作品条目内容的广度不足”都是关于“资讯不完整”的问题，您把我之前“知识问答”的内容在这里提出可能就稍微有些失焦了。--Justin545（留言） 2025年4月21日 (一) 08:51 (UTC)[回复]
@0xDeadbeef想问一下英维是如何处理自由雨日提出编者自行综述的导航模板及原因。Python6345（查论编） 2025年4月26日 (六) 11:17 (UTC)[回复]
我对这方面不是非常了解，我个人认为只要条目本身内容里有描述与导航模板相关内容，那么就应该适用添加至模板里。--beef [talk] 2025年5月1日 (四) 01:59 (UTC)[回复]

整理各方意见初步拟议方案如下：

  • 所有导航模板需要有最少一个可靠来源证实模板内条目属于此类即可进入导航模板，如无则属原创总结。
  • 列表类导航模板除显然完整外，必须明确告知读者可能不完整。

@U:Ericliu1912、U:自由雨日、U:YFdyh000、U:Sanmosa、U:Justin545、U:Zhenqinli、U:Liuxinyu970226、U:Nostalgiacn如3日内无反对意见本人将提出方针修订草案。Python6345（查论编） 2025年5月6日 (二) 10:09 (UTC)编辑于2025年5月6日 (二) 11:41 (UTC)[回复]

{{2025年地震}}（标题为“2025年主要地震”）似乎两样都不符合。我猜没有可靠来源会讲“缅甸地震是2025年主要地震”，现在也没有人写说“本导航模板可能不完整”。但是我不是很能接受它是违反NOR的。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月6日 (二) 10:23 (UTC)[回复]
以模板讨论:2010年地震来看，入选标准确实是原创的。按此标准，也确实可能处于“不完整”状态，例如没有条目或者标准不一致。可靠来源可能讲年度典型震例[1]，但仍缺通用收录标准。--YFdyh000（留言） 2025年5月6日 (二) 11:33 (UTC)[回复]
因为没人解答此项疑虑，双重(－)反对。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月7日 (三) 10:01 (UTC)[回复]
快点提吧，别墨迹了，Zhenqilin两面三刀的态度您也不是没看见，当社群一致认为其违规事实时，ta非但拒不接受，却反而指责社群有意“滑坡论证”针对ta，赤裸裸的IDHTta却不知道是啥。--Liuxinyu970226（留言） 2025年5月6日 (二) 10:30 (UTC)[回复]
阁下这是属于抒发情绪吗？--Justin545（留言） 2025年5月6日 (二) 14:53 (UTC)[回复]
(－)反对“有最少一个可靠来源证实有条目属于此类即可”：这会导致只要有一个可靠来源称“埃菲尔铁塔”是巴黎名胜，我就可以随手收录其他任何地点来创建{{巴黎名胜}}模板都不算原创总结。我的观点是即便所有义项都有可靠来源提及，这样的“巴黎名胜”模板依然为原创总结（即哪怕去掉“即可”我尚反对）。“有最少一个可靠来源证实有条目属于此类”（则可创建在其他标准满足的情况下）应当是分类的标准而非导航模板。 ——自由雨日🌧️❄️ 2025年5月6日 (二) 11:35 (UTC)[回复]
(：)回应已修正歧义。Python6345（查论编） 2025年5月6日 (二) 11:42 (UTC)[回复]
（上方Python6345的修改内容见此）我之前理解的是“创建”，但未看出“进入导航模板”和“可据此创建导航模板”在实践上有什么区别，而且主要聚焦的问题本就是后者。另外，改前语句已经有点不通，将“需要”（必要条件）和“即可”（充分条件）两个词放在同一句表述；改后更是杂糅难读。 ——自由雨日🌧️❄️ 2025年5月6日 (二) 11:50 (UTC)[回复]
实践上区别为修改后明确规定是具体条目是否可出现于对应导航模板，本人认为导航模板内收录条目标准影响模板是否为原创研究，因此需定明。Python6345（查论编） 2025年5月6日 (二) 12:00 (UTC)[回复]
“具体条目是否可出现于对应导航模板”对暂无的导航模板来说就是“可以创建”，因而我说实践上没有区别。例如现在无《巴黎名胜》，有可靠来源说埃菲尔铁塔是巴黎名胜，那根据你的拟议方案就可以创建《巴黎名胜》模板，故反对。另邀请@红渡厨参与讨论。 ——自由雨日🌧️❄️ 2025年5月6日 (二) 12:11 (UTC)[回复]
本人认为此处模板可能对读者的误导在于标题中立性，属MOS:不要华而不实不推荐的范围。阁下此例本人认为可移除活动与传统部分并将名称改为符合收录标准的巴黎建筑或简称巴黎建筑并在模板头部标示符合收录标准之巴黎建筑。Python6345（查论编） 2025年5月6日 (二) 14:34 (UTC)[回复]
“华而不实”确实也存在，但那是另一个问题，即便（其他模板）无华而不实问题也同样存在我说的问题（例如{{黄河沿岸城市}}）。“符合收录标准”并非是可靠来源中的概念，而是维基百科编者判断，将其直接写在条目（包括以导航模板形式嵌入条目）中就构成了原创研究（就像我们可以通过Google搜索等确定哪个是常用名称来确定条目标题，这并非原创研究而是编者判断，但将确定结论“X比Y常用”直接写入条目就是原创研究）。
就导航模板的问题我再解释一遍吧，我觉得逻辑很简单：如果可靠来源表述的是“a属A”（a为条目介绍对象），那么在a底部加入分类A（当然非必需）就反映了可靠来源的状态；如果可靠来源表述的是“A包括了a、b、c……”，那么用导航模板列出整个表格（表头为A，元素为a、b、c……）就反映了可靠来源的状态；如果是多个可靠来源描述了“a属A”“b属A”“c属A”而没表述“a、b、c……属A”，那么将其制作成（表头为A，元素为a、b、c……）导航模板当然就是原创总结，反映了任何可靠来源没有表述的观点。当然，如果A本身具有那些元素是客观、无争议的，那不在此列，例如“巴黎有哪些建筑”确实是客观的，不会有原创研究——当然我仍不赞同建《巴黎建筑》模板，这不是这里讨论的原创研究问题而是我认为不适宜以导航模板处理，不展开了。 ——自由雨日🌧️❄️ 2025年5月6日 (二) 14:51 (UTC)[回复]
如果是多个可靠来源描述了“a属A”“b属A”“c属A”而没表述“a、b、c……属A”，那么将其制作成（表头为A，元素为a、b、c……）导航模板当然就是原创总结，如果是按照阁下的说法，是否可以将模板拆成三份，分别为“a属A”、“b属A”、“c属A”三个模板？--Justin545（留言） 2025年5月6日 (二) 15:10 (UTC)[回复]
“a为条目介绍对象”，是单个元素。只包含一个元素的导航模板是没有“导航”意义的。 ——自由雨日🌧️❄️ 2025年5月6日 (二) 15:45 (UTC)[回复]
那么如果是改为下面的设计呢？主要还是把相关资讯集中在一起，方便将读者导航到对应的页面。实际上 来源1 可能也不是单纯表述“a属A”，而可能是表述更多像是“a,d,e,f,...属A”或。也有建议提到一些共同的资讯可以在导航模板计划页面说明即可，避免标注过于冗赘，这也关系到模板的标注方式。
--Justin545（留言） 2025年5月6日 (二) 22:09 (UTC)[回复]
看不出这样的模板有什么导航意义，这是编者在研究哪些文献将什么事物归类为A。 ——自由雨日🌧️❄️ 2025年5月7日 (三) 02:31 (UTC)[回复]
阁下说得很有道理，上面的例子因为每个集合里都只有一个集合元素，所以看起来挺空泛，缺少内容，这些可能要放到 相关条目／参见／参看 章节比较适当。不过如同我之前所说，若集合里面有更多的集合元素像是“a,d,e,f,...,i属A”、“b,j,k,l,...,o属A”、“c,p,q,r,...,s属A”，那么模板的资讯量就变大了，放到 相关条目 会显得过长，不便阅读。而就我观察您的观点，也许重点还是“不违反方针和指引”（WP:NOR），所以只要在符合方针和指引的前提下，是不是应该给编者更大的自由会比较好？其实现在的方针和指引已经够多了，真正可以把方针和指引完全掌握的编者我想也是十分有限，再增加太多规则或更多细节可能不见得会有非常巨大的帮助。--Justin545（留言） 2025年5月7日 (三) 03:04 (UTC)[回复]
这不是在增加规则，而是没有任何导航意义，且很可能更加违反《非原创研究》（类似学术文献尤其是综述/元分析的写法，“研究哪些文献将什么事物归类为A”）。我相信除你以外没有读者或编者会认为下面的导航模板有存在的意义。
此外，group（即来源）这种包含一些元素的集合在这种导航模板中本身也成为了一种元素，此时模板就成了更高层面的“非客观存在”“无明确收录标准”的集合，这同时会导致更严重的原创研究问题。
再次请你不要再像这里的讨论一样长篇大论地发散。——自由雨日🌧️❄️ 2025年5月7日 (三) 03:13 (UTC)[回复]
  1. 首先，您连结到我先前在“知识问答”的讨论，与这里“互助客栈/方针”讨论，两者是不同且分开的讨论，之前知识问答若有发散，也不表示在此的讨论也必然会发散，若您认为我在此的讨论有发散或离题，请您具体指出是哪些部分。Wikipedia:讨论页指引#如何使用条目的讨论页：“表达出您的看法，但不要忘记阐述您的理由。提出一个观点有助于说服别人并达成一致。”，个人认为这三天以内在此的论讨几乎都是在阐述我的理据、理由、疑问、意见、看法，并不自觉有任何的离题或发散。
  2. 我相信除你以外没有读者或编者会认为下面的导航模板有存在的意义，类似于我前述所提，基本上只要不违反方针和指引，您上面所举出带有三个来源的巴黎名胜模板是否有其存在的意义并非绝对地那么重要，所以我才提到在规范以外所能做的，是否皆应属于编者个人的自由或选择？然而，您举出的模板难以否认确实有它的功能性，毕竟它列举出了9个法国地点的相关条目供读者点击，不能说完全没有它的意义，在我看来导览模板还有一个重要的功能：组织条目的连结，我觉得其实现有导览模板的做法就已经很好，条目连结的组织清淅且明确，只是为了要符合这里NOR的提议，所以才要特别针对不同的来源去做拆分，此拆分动作在某种程度上只是为了符合NOR提议下的必要之恶。
--Justin545（留言） 2025年5月7日 (三) 06:19 (UTC)[回复]
我无法阻止你忽视我前文对该模板更违反NOR的论述。 ——自由雨日🌧️❄️ 2025年5月7日 (三) 06:23 (UTC)[回复]
理解了，认可以此标准定明方针。Python6345（查论编） 2025年5月6日 (二) 15:47 (UTC)[回复]
我的意见基本都是以前说过的那些，没有什么要补充的。--—— 红渡厨（留言・贡献・欢迎监督红渡厨是否仍有违反文明方针的行为，若有请点此举报。） 2025年5月6日 (二) 15:46 (UTC)[回复]
要求有关模板全部标注“明确告知读者可能不完整”过于冗赘，理当直接在“导航模板”计划页面统一说明其性质即可。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月6日 (二) 20:14 (UTC)[回复]
阁下这是很好建议，在导航模板计划页面统一说明，可以大幅减少额外资讯占据太多导航模板的版面空间。如果觉得需要加强说明的明确性，顶多再加上一个类似“[说明]”或“[?]”的连结，连到导航模板计划页面，这样或许也行。反之，如果觉得连到导航模板计划页面是多余的，甚至计划页面的连结也可以拿掉。--Justin545（留言） 2025年5月6日 (二) 21:18 (UTC)[回复]
同意。事实上维基百科应该制作“读者手册”这样的页面。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月7日 (三) 10:03 (UTC)[回复]
是的，我在这里就提了（）有了“凡例”页面之后也就可以直接使用“［英］”这样的语种标记了（当然，比起语种标记本身来说，“凡例”没那么紧迫）。 ——自由雨日🌧️❄️ 2025年5月7日 (三) 10:13 (UTC)[回复]
当前版本人类不可阅读，双重(－)反对。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月7日 (三) 10:00 (UTC)🤣1[回复]

根据上方讨论，新拟议如下：

  • 按照自由雨日的标准要求条目内导航模板。
  • 模仿WP:维基志异新建导读并于WP:首页链入。虽为原创，但未出现于条目，读者可知此为编者观点，避免NOR之原创总结。
  • 现有涉原创总结之导航模板逐步移出条目空间整入导读作为索引。

如讨论各位有于条目空间不违反NOR方针且保留现有导航模板之提议，望提出。另邀请@U:Bluedeck参与讨论。Python6345（查论编） 2025年5月7日 (三) 11:05 (UTC)[回复]

(－)反对设立“导读”页面。“导读”一般出现在书名（本身）中，如《〈红楼梦〉导读》，是指导一般读者或初入某领域的学术研究者阅读某部或某些作品，“导读”的含义和“索引”有天差地别。如果要设立类似的索引页面，我认为可以像我在这里说的一样，引入英语维基百科的内容索引（英语：Wikipedia:Contents/Indices）；也可以引入设置像WP:列表用途（那一章也是我重译的）中提到的内容大纲（英语：WP:Contents/Outlines）。 ——自由雨日🌧️❄️ 2025年5月7日 (三) 11:15 (UTC)[回复]
(＋)支持引入内容索引，阁下是否有意主持引入讨论？Python6345（查论编） 2025年5月7日 (三) 11:24 (UTC)[回复]
抱歉，我最近在想消歧义的问题（而且还没从之前的争议中恢复过来），可能暂时没什么心力引入内容索引（）另外我觉得这和导航模板的去留是两个较独立的问题，未必迫切需要讨论。而且“内容索引”也并非方针指引，也未见有明显反对意见，有心者大可直接动手（例如@Zhenqinli就已经引入了《保健类条目目录》等单篇内容索引——虽被提删，但理由是用了英文来索引，不是索引本身的问题）。 ——自由雨日🌧️❄️ 2025年5月7日 (三) 11:52 (UTC)[回复]
内容索引确实不错。最近看到心理学条目目录与保健类条目目录，觉得是个很好的东西。--Saimmx（留言） 2025年5月7日 (三) 12:08 (UTC)[回复]
(＋)支持上述引入索引修订后的版本，索引比模板功能强劲多了。--Liuxinyu970226（留言） 2025年5月7日 (三) 13:40 (UTC)[回复]

谢谢ping，我的意见是导航模版应该完全不受NOR限制。书写百科全书时，总要做出一些“Editorial choice”，也就是编者的主观选择——比如什么内容值得写，段落的划分、排序、比重，各段落标题怎么起，以及有哪些“延伸阅读”可以推荐给读者。这些内容恰恰是维基百科编者作为有思维能力有编纂能力的人存在的意义，也是维基百科的价值所在，而导航模版就属于这部分，因为它的作用是引导读者进行延伸阅读。这些主观选择不是原创研究，而是“编辑”二字的意义所在。纵观其他语言维基百科，基本上都是接受导航模版的。所以导航模版的存废应该一事一议，并且标准不是来源有无，而是作为导航模版是否有价值。Bluedeck 2025年5月7日 (三) 15:39 (UTC)[回复]

  • 十分认同阁下的观点，编者应该被授予足够的“自由”，对他（她） 擅长 及 感兴趣 的内容写作，相信这也是不少编者们撰写维基百科的动力来源。这也更能符合在每个页面或许多页面上方标榜的这段话：“维基百科，自由的百科全书”。
  • 附带一提：就我的理解WP:NOR应该是：对编者所 加入 的内容进行限制，而不是对编者所 排除或忽略 的内容进行限制。要求编者透过类似“穷举法”的方式去写百科内容，对特定的编者而言，通常是极度困难的。虽然另外还有WP:NPOV，但条目也很难在“每一个时间点”都完美地符合NPOV，所以在过渡期才会有{{POV}}模板可以使用。授予编者充足的资源（时间资源、人力资源、...）去“改善”其内容，以“改善”取代“删除”，在我看来这是比较有“建设性”的方式，这可能也较符合维基百科:删除的序言：“我们应该尽量保留所有合乎百科全书目标的页面，删除应该是最后的选择”。
--Justin545（留言） 2025年5月8日 (四) 02:58 (UTC)[回复]

提议修正Wikipedia:界面管理员

原标题：紧急修正Wikipedia:界面管理员

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:界面管理员、Wikipedia talk:申请成为管理人员。

@AT由于界面管理员方针内部所注明的获选标准（八成）与目前所采用的标准（七成五）不同，现提议于RFA投票开始前紧急修正该方针中的获选标准。 公示48小时。--WiiUf（留言） 2025年4月15日 (二) 05:32 (UTC)[回复]

但哪一边才是实际标准？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月15日 (二) 05:55 (UTC)[回复]
抱歉。 取消公示。—WiiUf（留言） 2025年4月15日 (二) 06:40 (UTC)[回复]
虽然我自己正在参选，不应该评论（稍有自肥之嫌），但OS都能七成五当选，界管要八成，也不太合理吧。确实过往讨论似乎全程大家都没提及IA，不过直接跟进（因为当时是修改整个RfA的当选标准）应该不成问题；甚至可以走事实性修订，确实有社群共识调低“申请成为管理人员”（管理人员定义上包含也要经过RfA的界管）的当选标准。5%的修订不大，只要在投票结束、确定结果前改方针就行了。--路西法人 2025年4月15日 (二) 13:30 (UTC)[回复]
根据WP:RFA“投票结果”段落：“行政员须按投票中有效的支持票占总有效票的比例（支持率）判定管理人员申请是否获得通过。各该申请之有效支持票数至少25票，且支持率达75%者，将获授予申请之权限。”既然介管属于管理人员架构内，那就没有理由高于其他管理人员，况且介管的权限在管理人员中可以说是最少的，当选要求却更高实在是于理不合。无论如何，基于选举已经迫在眉睫，需要尽快解决，监督员也有过相同的事实性修订，这也是我在选举前发现的。--AT⊿⁴⁶ 2025年4月15日 (二) 14:59 (UTC)[回复]
咱相信是之前的某个RFC里忘掉了IA这个东西，所以那边没有进行修订。感觉可以执行事实性修正：
现行条文

用户可经申请成为界面管理员，并长期持有权限。界面管理员须经票选产生，用户于权限申请页获提名或自荐后需发公告至公告栏。票选为期十四日，得至少二十五票支持为之有效，而支持者占其中总得票数至少八成才可通过。投票通过后，则由行政员授权。管理员如为2018年7月5日前上任，经三日投票，简单多数支持，则可以获取界面管理员权限。如果三日内未有任何用户投票，则应延长至七日。期后如仍无用户投票，则由行政员决定是否任命。用户如需申请短期权限，则可至行政员布告板申请。用户可参与讨论及表态是否赞同申请，并附以理据支持。最终由行政员按讨论内容决定是否批准申请。

提议条文

用户可经申请成为界面管理员，并长期持有权限。界面管理员须经票选产生，票选为期十四日，得至少二十五票支持为之有效，而支持者占其中总得票数至少七成五才可通过。投票通过后，则由行政员授权。管理员如为2018年7月5日前上任，经三日投票，简单多数支持，则可以获取界面管理员权限。如果三日内未有任何用户投票，则应延长至七日。期后如仍无用户投票，则由行政员决定是否任命。用户如需申请短期权限，则可至行政员布告板申请。用户可参与讨论及表态是否赞同申请，并附以理据支持。最终由行政员按讨论内容决定是否批准申请。

Stang★ 2025年4月16日 (三) 12:40 (UTC)[回复]
本人同意有关修正案，盖此实符合社群当初全面降低管理人员申请门槛之意旨。若社群确有共识支持，应于近期集体申请正式开始表决以前通过修订为宜。另副知@WiiUf、LuciferianThomas、AT。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月19日 (六) 05:08 (UTC)[回复]
不反对。--WiiUf（留言） 2025年4月27日 (日) 10:52 (UTC)[回复]
这里还需要公示么，还是说可以直接进行修改？ Stang1364 2025年4月27日 (日) 08:48 (UTC)[回复]
@Stang：我觉得需要公示。另外，是否适用这次申请？也是个问题。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月27日 (日) 13:31 (UTC)[回复]
@Stang 我觉得要公示48小时吧，在投票结束前修改好。Пусть от победы☆к победе ведёт! 2025年4月28日 (一) 04:04 (UTC)[回复]
@WiiUf、Ericliu1912、LuciferianThomas、AT、阿南之人：看到讨论中对于是否适用于这一次存在不一样的看法，我觉得为了谨慎起见，应当在正在举行的选举中使用目前80%的版本，修订的版本在未来生效。不管怎么说，先进行 公示7日，2025年5月6日 (二) 06:17 (UTC)结束。 Stang1362 2025年4月29日 (二) 06:17 (UTC)[回复]
@Stang、AT、LuciferianThomas 本来这个提案是对于本次选举的紧急修正，却因为一些问题而推迟公示。所以我认为新修订方案应该适用于本投票。Пусть от победы☆к победе ведёт! 2025年4月29日 (二) 08:29 (UTC)[回复]
RFD早已提及75%的当选门槛，只是介管页面未及更新而已，因此理应以75%为准。--AT⊿⁴⁶ 2025年4月29日 (二) 09:14 (UTC)[回复]
以75%为准并无任何问题。--Hamish T 2025年4月30日 (三) 18:39 (UTC)[回复]
@Stang：同AT，目前公示应停止。改就上述的“事实性收订”紧急公示48小时，并在本次正在举行的选举中，实施修正后版本。--Aqurs 2025年4月30日 (三) 18:53 (UTC)[回复]
继续公示无伤大雅，讨论下是否在本次选举中遵从该事实即可。--Hamish T 2025年4月30日 (三) 19:36 (UTC)[回复]
公示期间如果还没达成共识这样跟不公示没两样，只是为了勉强在rfa完结前解决掉。倾向尽快达成共识再紧急公示。--Aqurs 2025年4月30日 (三) 19:56 (UTC)[回复]
75%的标准是既有共识导致的事实性修订，而不是说近期才达成的共识。个人认为并不需要再达成“在本次RFA中以75%支持作为标准的共识”，这里公示的条文都完全可以走事实性修订的程序，没有必要为了达成这个共识而达成。--Hamish T 2025年5月1日 (四) 01:56 (UTC)[回复]
我说的是不认为现有讨论就“在这次rfa采用新版本”有一定的共识。--Aqurs 2025年5月1日 (四) 03:54 (UTC)[回复]
个人认为并不需要再达成“在本次RFA中以75%支持作为标准的共识”，此处要修改到七成五，是因为之前已经有共识通过了“降低管理人员选举标准至七成五”然后改了WP:RFA没有改WP:IA，这个修改本身就可以直接执行事实性修改，新共识已经修改了旧共识，拙见没有必要多此一举。--Hamish T 2025年5月1日 (四) 04:02 (UTC)[回复]
那么为什么上方会出现“我觉得为了谨慎起见，应当在正在举行的选举中使用目前80%的版本，修订的版本在未来生效。”？--Aqurs 2025年5月1日 (四) 04:08 (UTC)[回复]
没问题啊，我也只是表达我的看法，我认为没有必要重新公示，直接按照RFA修改的共识走就可以了。而且理论上来说，如果您觉得重新公示是恰当的操作，您也可以直接开始“紧急公示”。--Hamish T 2025年5月1日 (四) 04:21 (UTC)[回复]
@Hamish、Aqurs、AT、阿南之人：不好意思我这里回复的有点晚了。阅读上方的讨论之后可以有以下共识：界面管理员的当选条件属于事实性修订，因此实际上无需进行这么长时间的公示便可以直接修改；由于这一当选条件是事实性修订，因此在本次选举之中使用75%作为当选条件并没有不妥当的地方。我已对方针进行了修订，这一讨论可以关闭了。 Stang1356 2025年5月6日 (二) 00:32 (UTC)[回复]
@Aqurs1：补ping Stang1356 2025年5月6日 (二) 00:36 (UTC)[回复]

公共运输相关指引再次讨论

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:交通车辆条目指引、Wikipedia talk:公共交通路线条目指引、WikiProject talk:城市轨道交通、WikiProject talk:铁道。

近日整理交通相关条目屡遇交通迷持续加入过度着色的文字以及原创研究内容，因此在此重提建立相关指引，已知目前已有的相关草案有Wikipedia:交通车辆条目指引以及Wikipedia:公共交通路线条目指引，在此提出讨论，希望这次有一个结论。相望能做个了结，拖太久了XD--🚊　铁路Railway 论．签 2025年4月17日 (四) 04:32 (UTC)[回复]

邀请先前参与讨论或编辑的维基人@LuciferianThomas、Ghrenghren、BIT0865、一片枫叶、心平星辰、owennson、台南賴哥、SickManWP、捷利、Cdip150、Olaf8940、Tisscherry、Sanmosa--🚊　铁路Railway 论．签 2025年4月17日 (四) 04:53 (UTC)[回复]

交通车辆条目指引

现行条文

无

提议条文

维基百科收录交通车辆相关主题，机动车辆、铁路等车款也能开设条目。但为交通车辆开设条目前，编者务需找出若干可靠、独立的第二手来源，举证主题具备收录标准。一方面，收录标准决定主题是否需要开设独立条目；另一方面，符合收录标准就意味着有优质来源支撑，编者能写出全面的条目。收录标准得证后，编者就可以编写条目。

条目在描述车辆概况的同时，还要像可靠来源一样介绍设计、规格、构造等内容；维基百科不欢迎交通迷内容，编者切勿沉沦于过度的细节。

以下介绍交通车辆主题可能用到的元素，撰写条目时请按实际情况适时选用和调整。如果您有想法或疑问，请在讨论页面进行讨论。除此之外，您还应该熟悉WP:更优秀条目写作指南。

信息框模板 信息框是展示主题关键信息的表格，桌面版浏览多置于条目右上角，流动版浏览仅次于起首段。交通车辆信息框一般包括车型名称、制造商、首次出厂年份、图像等资料。某些技术设定对理解车辆整体至关重要，也会记入信息框。“关键”的车辆信息因车种性质而不尽相同。与所有信息框一样，交通车辆的信息框应该避免琐碎的细节。

您可以在Category:交通信息框模板找到合适的模板使用，一般来说，铁路车辆条目通常采用{{鐵路車輛}}、{{鐵路車輛2}}等，机动车辆通常采用{{Infobox Automobile}}等，具体使用方法请见相关信息框内的文档。 导言 导言应精要概括正文，一般来说会简述制造商、车辆类型等，如车辆被用于公共客运服务，则车辆所属的客运或铁路公司、服务路线、投入服务日期等也可简述。 背景与概述 本段应说明该型车辆出现的背景与开发缘由，例如是否为因应运量成长、汰换老旧车辆、导入新技术，或配合政府交通政策与营运策略所开发。可说明规划与制造过程中的主要考量与阶段目标。若车辆已退役，亦应交代退役决策背景，包括技术老化、维修成本、替代方案等因素。此外，也可概述该车型在所属交通系统中的定位与功能，或介绍其在营运历史中的角色与贡献，例如是否为首批引进某项技术的车型，或曾参与重大路线开通。 规格与构造 介绍车辆的核心技术，详细说明其结构、系统与外观特征。内容可涵盖车体材质、设计风格、动力系统（如内燃、电动、混合动力）、机电设备与各项设备规格，并说明编组形式、定员数量及无障碍设施等乘客相关配置。车辆外观如涂装、标志、显示系统，内装如座位配置、资讯显示与空调等。撰写时应依据可靠来源进行整合与概述，避免过度细节化或直接复制厂商资料，并避免使用过度细节化的术语堆砌内容。 各代历程 若车辆型号生产超过一代，或具明确的子型号与改良版本，应在本段加以系统性地区分与说明。可依世代顺序介绍各版本的开发背景、设计调整、生产时程及投入营运的情况，并指出相较前代在技术或使用层面的主要差异。若某一代仅有小幅修改，可简要带过，避免过度拆分。撰写时应聚焦于型号整体演进的脉络，避免逐辆记述个别车辆细节，以维持条目的条理性与通用性。 重大事故 若该型车辆曾涉及重大事故，尤其是造成大量人员伤亡或引发媒体广泛关注者，应于本段简述相关事故。叙述内容包括事故的时间与地点、涉及单位、造成的损害与影响。若事故本身已具备独立条目，则可使用{{main}}作主条目导向，以便读者深入阅读。事故描述应以中立、简洁为原则，避免渲染或情绪性文字。 车辆保存 若该型车辆已退役，并有完整保存案例，应介绍其保存状况与保存地点，包括是否由博物馆、学术单位或民间团体保存，是否对外展示，以及保存的原因或文化价值。若保存车辆为特定号码、原型车或纪念车，也应说明其特殊性与保存背景。此段仅限于有可靠来源佐证之公开保存资讯，不应记录私人收藏或网络传言。 参考来源 条目必须遵循可供查证的要求，并将对应的可靠来源以内文引用形式来支持条目。 分类 为方便读者搜寻，车辆条目可按核心主题或行业元素归类，如在新干线行驶的车辆应归入Category:新干线车辆。但请注意，分类应简明扼要地描述主题，不可过滥。以蒸汽机为动力的车辆可归入Category:蒸汽机车或其子分类；但纯粹因有明火出现而归类则不合适（例如车辆曾发生火烧车事故而将该车辆归入火灾相关分类则不适当）。过度归类只会淡化分类的应有效用。 应避免的事情 爱好者内容 维基百科不是不经筛选的资讯收集处，车辆车次运用、车号机务段分配、改造期程、交车期程、领牌车号、行驶路线、停靠站牌等琐碎资讯并不适宜加入到条目内。条目不应存在任何原创研究的内容。如果有必要，可以移到维基教科书、维基学院等其他维基计划，又或者到其他专门的Wikia撰写。 大量的短条目 通常一个较大的条目能提供对主题更有条理的介绍与背景联系。当大条目能做到时，请不要创建大量小条目。理想的条目是既不过大，也不过小。 过多的图片 请勿于条目内放置各车号的照片，于资讯框模板一张代表即可，其他照片则放入共享资源并于底下纳入共享资源连结导引 大量的粗体与文字上色 请勿于条目内为文字过多粗体与上色，行驶路线、领牌车号、特殊备注等，如路线有颜色区分需求请使用表格填色，不要为每个路线明上色。

以上条文由在下草创Cdip150君重整，在此提出讨论与公示。--🚊　铁路Railway 论．签 2025年4月17日 (四) 04:39 (UTC)[回复]

不是，你真确定这是写完的草案吗？Sanmosa 新朝雅政 2025年4月17日 (四) 05:43 (UTC)[回复]
还没完成，只是全文拿出来看看各位有哪些修改意见。--🚊　铁路Railway 论．签 2025年4月17日 (四) 06:22 (UTC)[回复]
背景与概述、规格与构造、车辆保存三者好歹先扩充一下才拿出来吧，不然我是真的无法给任何的意见。Sanmosa 新朝雅政 2025年4月18日 (五) 13:47 (UTC)[回复]
大致没有太大意见，若有其他维基人发表看法本人会加以回应。--维基病夫❤️边缘人小组·签到 2025年4月18日 (五) 04:03 (UTC)[回复]
同Sanmosa，指引仍尚未完善。--Aqurs 2025年4月20日 (日) 14:23 (UTC)[回复]
@Sanmosa、Aqurs1：已扩充更新，还请指教。--🚊　铁路Railway 论．签 2025年4月21日 (一) 08:29 (UTC)[回复]
(＋)支持，一堆交通迷写车辆调动、编号，甚至是牵引系统、空调、电池箱的型号和种类，这些琐碎信息完全不是一般人所关心的，也没必要保留。（举例：广州地铁一号线列车、广州地铁三号线北延段列车），我敬佩交通迷实地探访总结资料的能力和勇气，但这不适合维基百科。--自由米花🌾🌼 2025年5月2日 (五) 04:34 (UTC)[回复]
“这些琐碎信息完全不是一般人所关心的”，这一点我同意。但是除了维基百科，中国大陆已经没有别的地方可以放置这些琐碎信息了，这是很可怕的事情。交通爱好者群体内部也是有纷争的，写车辆调动的反感写牵引系统的，写牵引系统的反感写车辆调动的，有必要就保留哪些信息达成共识。至少我认为，空调、电池箱可写可不写，但是电机主逆辅逆这三大件要留——缺少任何一个都无法构成完整的牵引/辅助系统。BIT0865 · Discussion · 燕房线永远的神！ 2025年5月8日 (四) 05:06 (UTC)[回复]
细化“规格与构造”部分如下：
现行条文

介绍车辆的核心技术，详细说明其结构、系统与外观特征。内容可涵盖车体材质、设计风格、动力系统、机电设备与各项设备规格，并说明编组形式、定员数量及无障碍设施等乘客相关配置。车辆外观如涂装、标志、显示系统，内装如座位配置、信息显示与空调等。撰写时应依据可靠来源进行整合与概述，避免过度细节化或直接复制厂商资料，并避免使用过度细节化的术语堆砌内容。

提议条文

介绍车辆的核心技术，详细说明其结构、系统与外观特征。内容可涵盖外观、内装、动力系统、机电设备等。
外观：包括但不限于车体材质、设计风格（含涂装）、显示系统等。
内装：以座位配置和乘客信息系统（PIDS）为主。可将编组形式、定员数量、无障碍设施等乘客相关配置以折叠表格形式列出。
动力系统：包括但不限于内燃、电动、混合动力等，仅需在 Infobox train 模板中说明，再经该处链入相关维基条目，避免条目间的同质化。
机电设备：包括车上、车下两类设备，根据关注程度分为两类。
① 必选项：牵引及辅助系统（牵引电机、牵引逆变器、辅助电源）。
② 可选项：包括但不限于空调、高压电器箱、蓄电池充电机等，在 Infobox train 模板中归为“其他电气设备”。
机电设备若确有性能优势，可在条目正文内展开说明，并配上机器外观图（若有）。
以上各项在撰写时，应依据可靠来源进行整合与概述，避免直接复制厂商资料，以及使用过度细节化的术语堆砌内容。在已有参考文献佐证的前提下，机电设备的型号若可通过 Commons 内的照片进行佐证，须将照片链接链入；对于佐证资料无法公开的可靠型号，型号提供者须在条目讨论页说明查证过程，接受条目读者监督。

BIT0865 · Discussion · 燕房线永远的神！ 2025年5月8日 (四) 06:17 (UTC)[回复]
“机电设备的型号若可通过 Commons 内的照片进行佐证，须将照片连结连入；对于佐证资料无法公开的可靠型号，型号提供者须在条目讨论页说明查证过程，接受条目读者监督。”原创研究？？🚊　铁路Railway 论．签 2025年5月8日 (四) 06:56 (UTC)[回复]
前半句我说的是 A5 的 TGN51E 那种情况。后半句要不去了。BIT0865 · Discussion · 燕房线永远的神！ 2025年5月8日 (四) 07:01 (UTC)[回复]

公共交通路线条目指引

路线条目目前似乎还很不完善，需再仔细讨论。--🚊　铁路Railway 论．签 2025年4月17日 (四) 04:39 (UTC)[回复]

基本上支持没意见。另想请问例如廉江市#交通，经常于写入交通的条目内看到类似的连结，算是旗帜规范能否清理？--提斯切里（留言） 2025年4月17日 (四) 14:34 (UTC)[回复]
不是旗帜，但是是图标。你举出的例子违反了WP:格式手册/图标#百科性用途，按例应当清理。Sanmosa 新朝雅政 2025年4月18日 (五) 13:48 (UTC)[回复]
清了。--提斯切里（留言） 2025年4月18日 (五) 14:31 (UTC)[回复]
玉湛高速公路，化廉高速公路，理当也要清理？--提斯切里（留言） 2025年4月18日 (五) 14:32 (UTC)[回复]
这两个例子牵涉到表格，图标在其中能起视觉提示与改善导航功能的作用，因此这倒不是需要清理的对象了。Sanmosa 新朝雅政 2025年4月18日 (五) 14:43 (UTC)[回复]
了解。--提斯切里（留言） 2025年4月18日 (五) 14:58 (UTC)[回复]
这样说吧，现WP:公共交通路线条目指引的拟议规定非常生硬、僵化。比如它要求“服务时间及班次：须以表格形式展示数据”、“须以相关模板列出常规优惠”与“分段收费须以表格模式列出”，但这忽略了部分巴士路线的服务时间、班次、常规优惠与分段收费状况较为简单的情形（例：九龙巴士61A线在星期一至五（公众假期除外）只开一班车，故而完全用不着表格；九龙巴士39A线的转乘优惠只需要两个句子就能完全说清楚，故而完全用不着模板；新大屿山巴士36线只有一个分段收费，故而也完全用不着表格）。Sanmosa 新朝雅政 2025年4月20日 (日) 10:26 (UTC)[回复]
这方面确实僵化，按里程计价的多级票价线路也不一定需要表格即可直接表示，不定班的线路时刻表经常性改变也没法罗列班次时刻表。或可更改为“建议以表格形式展示数据”？--Jason2016426（留言） 2025年4月21日 (一) 04:29 (UTC)[回复]
“建议”仍然有一定的约束性质。Sanmosa 新朝雅政 2025年4月25日 (五) 12:36 (UTC)[回复]
那不可能不要这段话的。要是删了，碰到有用新开线路条目时，将一天上百班次的线路时刻表写成一堆数字+顿号怎么办？
要么分类讨论。--Jason2016426（留言） 2025年4月26日 (六) 03:55 (UTC)[回复]
我的意思是应该仅限定资料项较多时以表格表示，比如九龙巴士61M线的班次牵涉到的时段非常多，这种情况不以表格来处理是不可行的。Sanmosa 新朝雅政 2025年4月26日 (六) 08:22 (UTC)[回复]
如此分类规定表格使用相关内容的话，也是( ✓ )同意的。--Jason2016426（留言） 2025年4月26日 (六) 10:00 (UTC)[回复]
( ✓ )同意：北捷所有路线条目，内容结构至今为止仍偏向爱好者内容，主要介绍内容过于稀少。--Sinsyuan✍️ 2025年4月26日 (六) 06:12 (UTC)[回复]
其实现在已经有一定数量的铁路线GFA了（WP:优良条目/分类/交通#铁路交通、WP:典范条目#交通运输），或许可以参考现有的GFA来商讨合理的结构。Sanmosa 新朝雅政 2025年4月26日 (六) 16:09 (UTC)[回复]
现行条文

无

提议条文

维基百科收录交通路线相关主题，包括铁路线、公共汽车线等公共交通路线皆可作为条目建立的对象。然而，在为交通路线建立条目前，编者应先寻找若干具可靠性、独立性且属于第二手来源的资料，以证明该主题符合收录标准。一方面，收录标准决定是否有必要为某主题设立独立条目；另一方面，若能证明符合标准，亦代表有足够优质来源支撑，足以撰写出完整且具中立性的内容。确认收录标准无虞后，即可着手撰写条目。

条目在介绍路线时，不应仅列举总站电话号码与地址，而应如同可靠来源般，清楚说设开设背景、路线技术规格与路线特征。维基百科并非交通迷的资料收集平台，应避免陷入过度细节，确保内容具有百科全书的深度与广度。

以下介绍交通路线条目中可能使用的内容结构，请依实际情况灵活选择与调整。如有疑问或建议，欢迎至讨论页面交流意见。编者亦可参阅WP:更优秀条目写作指南以提升条目品质。

讯息框模板 讯息框是呈现主题关键资讯的表格，于桌面版多位于条目右上角，行动版则紧接导言段落之后。交通路线的讯息框通常包含路线名称、营运商、营运里程与图像等资讯，具体内容可依交通工具类型略有不同。与所有讯息框相同，交通路线讯息框应避免填入过于细琐的资讯，以维持条目整洁性与可读性。

您可以在Category:交通信息框模板找到合适的模板。铁路路线通常使用{{Infobox rail system-route}}或{{Infobox rail}}，而公共汽车路线则多采用{{公共汽車路線基礎資訊}}等模板。详细用法请参见各模板所附的文档说明。

导言 导言应精要概括条目的核心内容，简述营运单位、服务范围、通车年份等基本资讯。如路线属于某特定系统、属延伸路段或重要支线，也可于导言中简单交代，以利读者快速掌握主题背景。

背景与概述 本段应简要说明该路线的开发背景与缘由，说明其是否因应城市发展、运输需求增加、政府政策推动或营运策略调整而规划建设，并可补充规划过程中的关键考量与阶段性目标。若该路线已停止营运，亦应交代废除决策的背景因素，如运量下滑、维护成本过高、重大灾害影响或已有其他替代方案等。此外，可说明该路线在整体交通系统中的定位与功能，或其在营运历史中的角色，例如是否为该系统首条通车路线、工程分期计划、路线延伸计划、改善/改建计划，或对城市交通发展具有指标性意义。

路线与车站 本段应简要说明该路线的起讫点、行经范围与主要站点，并概述沿线车站的设置情形，包括总站数、平均站距，以及是否设有快慢车制度、区间运行或跳站服务等。透过这些资讯，能够清楚展现路线的基本架构与服务方式。

使用车辆 本段应介绍该路线所使用的营运车辆，包括主要型号、现役车种与退役车辆等资讯。相关内容应依据可靠来源撰写，不应使用私人收藏、网络传言等未经查证的资料。为维持条目的中立性与可验证性，应避免仅依赖营运商或监管单位的第一手来源，而应搭配其他次级来源佐证。

参考来源 条目必须遵循可供查证的要求，并将对应的可靠来源以内文引用形式来支持条目。

应避免的事情 爱好者内容 维基百科不是不经筛选的资讯收集处，请勿将车牌、车队编号、车厂等琐碎资讯加入条目内。条目不应存在任何原创研究的内容。如果有必要，可以移到维基教科书、维基学院等其他维基计划，又或者到其他专门的Wikia撰写。

大量的短条目 通常一个较大的条目能提供对主题更有条理的介绍与背景联系。当大条目能做到时，请不要创建大量小条目。理想的条目是既不过大，也不过小。

过多的图片 请勿于条目内放置各车号的照片，于资讯框模板一张代表即可，其他照片则放入共享资源并于底下纳入共享资源连结导引。

大量的粗体与文字上色 请勿于条目内为文字过多粗体与上色，行驶路线、领牌车号、特殊备注等，如路线有颜色区分需求请使用表格填色，不要为每个路线名上色。

以参见几篇优良或典范条目初步编写，看是否还有需要修正的地方。--🚊　铁路Railway 论．签 2025年4月30日 (三) 08:34 (UTC)[回复]

(＋)支持目前的方针提议，以台湾捷运路线条目为例，虽然高捷黄线有稍微提供路线提案规划等内容，但其余路线条目大都只是写的像一篇游记。另外，主条目（XX地铁/捷运）要介绍的东西一定要聚焦在类似目前为优良级的“北京地铁”内容风格，避免让喜欢城市轨道交通的使用者无法了解这条路线和地铁系统的来龙去脉。--Sinsyuan✍️ 2025年4月30日 (三) 08:44 (UTC)[回复]
(！)意见：
1.关于架构
概括起来三个字：“分情况”。
陆地公共交通无非是两大类：陆地上跑的公路交通、铁轨上跑的轨道交通。铁轨上跑的又分两种：运营意义上的线路和工程意义上的线路。对于城市轨道交通，诸如北京地铁的单条线路，工程意义上的线路与运营意义上的线路区别不大，内文也更多以运营意义上的线路为主、工程意义上的线路为辅展开叙述的。以上我都不是特别懂，所以我就不展开叙述，大体来看应适配于此方针。
但是换做是中国大陆的铁路线路来说则不然。中国大陆的铁路线路应是工程意义上的线路为主、运营意义上的线路为辅来叙述——因为中国大陆的铁路线路存在着大量跨线运营的列车，以京广铁路为例，对于运营意义上的线路，记叙应落实到具体车次条目（例如D1/2次列车）和某两地间的动车组条目（例如京广既有线动车组列车）去承担。至于“运营意义上的线路为辅”，具体措施就是应考虑以客货运概述的形式记叙（另根据经验来看，铁路干线的运输性质大多数共通，除大秦铁路这种专用性极强的线路外，往往不需要特别提及客货运情况）。因此现行条文中“使用车辆”一章、“概述沿线车站的设置情形，包括总站数、平均站距，以及是否设有快慢车制度、区间运行或跳站服务等。”云云语句不适用于中国大陆的铁路线路。
综上，我个人觉得这样一个指引应参照维基百科:格式手册/电子游戏那样，先分情况讨论布局，然后列举出什么是“必需”、什么是“不需”，什么是“值得一写”。目前的拟议内容里，必需要素的列举过于详尽且与章节布局混同，而事实上这两者在性质上本就不同；而“应避免的事情”一章又拼凑着内容、格式文风、图片等多个领域的内容，而显然这也是需要分开谈论的。
2.关于内容
第一条提及的问题不赘述。
只另说一处：“使用车辆”中为维持条目的中立性与可验证性，应避免仅依赖营运商或监管单位的第一手来源。首先不明白第一手来源与“可验证性”的联系。另外诚然，避免依赖第一手来源的原因是在于第一手来源会出现偏颇，但我不是很能理解，究竟是在什么情况下，作为与该信息联系最紧密、最直接的消息源，营运商或监管单位需要在使用车辆这一方面出现偏颇。我想这句话应该出现在历史部分和事故部分——因为这些部分才有可能出现偏颇。
我也并非是完全的专门人士，这些浅见只供参考。另邀请常在国铁领域活跃的编者@MNXANL参与讨论。-- 西行寺海苔子 ハナノモトニテ 2025年4月30日 (三) 11:17 (UTC)[回复]
(！)意见“铁路线”条目中，在指引中应明确line还是service：即{{Infobox rail system-route}}和{{Infobox rail service}}，大部分铁路线条目反而用不到{{Infobox rail}}。line和service应该在何时可作为同一主题方面，我基本同意原作者在“关于条目撰写的主张”中的看法。
而对于其具体结构：什么是应该包含的基本要素？
  • line的基本要素：背景、建设及改建的历史、线路走向、车站布置、运营状况、影响等
  • service的基本要素：背景、规划及运营调整的历史、运营模式、使用车辆、运营状态（客流）等
  • bus route不是很了解，应该和service差不多？
因此，应该参照Wikipedia:格式手册/电子游戏#行文结构章节修改指引语言以明确不同“线路”条目（铁路line、铁路service、巴士route/service）的格式规范，然后再去规定编写风格。--MNXANL 贡献 讨论 2025年5月1日 (四) 01:13 (UTC)+11[回复]
(＋)支持此版本的提议条文。(！)意见，小弟总觉得“大量的粗体与文字上色”的部分，可以加入范例供参考，不然大家认为路线的粗体标记与表格填色的定义很广，到时又容易有争议。另提议条文的第一段“然而，在为交通路线建立条目前，编者应先寻找若干具可靠性、独立性且属于第二手来源的资料，以证明该主题符合收录标准。”此段虽然明确列出需有第二手来源，但还是有部分编者的认知有所不同。例如在义大客运讨论页的最新话题。感谢@鐵路1阁下的用心。--英国皇家欧拉夫王子（留言） 2025年5月5日 (一) 02:51 (UTC)[回复]
(！)意见“铁路线”方面，跨线车怎么处理？
公交/巴士线路方面，相关内容呢？我辣么（那么）大个收费、班次、行车路线呢？
实在不行可能还是得学WP:VGORDER，明确“铁路线路”、“巴士线路”两大类条目分别该怎么写吧。--Jason2016426（留言） 2025年5月5日 (一) 12:20 (UTC)[回复]
(！)意见：个人觉得概述章节和序言存在一定程度的功能重复，如果明文写入格式手册会和其他适用于全站的政策相冲突。概述章节可能包含了线路走向、附属设施等内容，在二者不足以分开设置章节的情况下会合并，但应该避免使用“概述”这种命名方法。--屠麟傲血（留言） 2025年5月5日 (一) 13:20 (UTC)[回复]
线路的发展历史和功能意义的重要性大于其站数及站距。参考 User_talk:Nrya#广州公交线路条目品质之探讨，提议以下两处调整：
现行条文

本段应简要说明该路线的起讫点、行经范围与主要站点，并概述沿线车站的设置情形，包括总站数、平均站距，以及是否设有快慢车制度、区间运行或跳站服务等。通过这些信息，能够清楚展现路线的基本架构与服务方式。

提议条文

本段应简要说明该路线的起讫点、行经范围与主要站点，并概述沿线车站的设置情形，以及是否设有快慢车制度、区间运行或跳站服务等。通过这些信息，能够清楚展现路线的基本架构与服务方式。

现行条文

通常一个较大的条目能提供对主题更有条理的介绍与背景联系。当大条目能做到时，请不要创建大量小条目。理想的条目是既不过大，也不过小。

提议条文

通常一个较大的条目能提供对主题更有条理的介绍与背景联系。当大条目能做到时，请不要创建大量小条目。理想的条目是既不过大，也不过小。撰写条目前，需审慎评估线路的有关背景资料是否足够用于创建条目。可将多条背景资料较少，但功能或走向相关联的线路合并为一个条目撰写，或整理为列表形式。

BIT0865 · Discussion · 燕房线永远的神！ 2025年5月8日 (四) 06:54 (UTC)[回复]

关于使用人工智能生成内容的新增规范或指引修订提案

好的，这是一个基于您的想法起草的维基百科提案草稿。请注意，这只是一个起点，您需要在维基百科的相应社群页面（通常是互助客栈/方针或指引区）正式提交，并接受社群的广泛讨论和修改。在提交前，强烈建议您仔细阅读维基百科现有的相关方针和指引，确保您的提案与之不冲突，并能清晰阐述为何需要这些改变。 --- 现状与问题：

近年来，以大型语言模型（LLMs）为代表的人工智能技术取得了突破性进展，其生成文本的能力已达到前所未有的水平。许多维基百科的编辑者开始尝试利用这些工具辅助内容创作。然而，当前的社群讨论和相关指引（若有）大多是在这些先进AI模型出现之前进行的，未能充分预见和应对其带来的新挑战和机遇。

我个人的经历便是一个例子：我曾尝试使用AI工具撰写条目，但由于过度依赖而未进行充分的校对和核查，导致生成的条目逻辑混乱、事实错误、格式不规范，完全不符合维基百科的品质标准，最终不得不进行大量修改甚至推倒重来。这说明，不加限制和审查地使用AI生成内容，极易损害维基百科的品质和可信度。

另一方面，如果能正确、审慎地使用，AI工具或许能在资料搜集、文本组织、语言润色等方面为编辑者提供帮助，提升效率。因此，我们不应简单地禁止AI生成内容，而应制定明确的规范和流程，引导编者负责任地使用AI，确保所有内容最终都符合维基百科的核心方针和指引。

本提案旨在修订或补充现有指引，明确人工智能生成内容的使用界限、审核流程和责任机制，以期在拥抱技术发展的同时，维护维基百科作为可靠知识来源的基石。

提案具体内容：

基于以上考量，建议新增或修订以下规范：

1. 内容原则： 人工智能生成（包括主要依赖AI辅助生成）的文本，若完全符合维基百科的各项品质标准（包括但不限于可查证性、中立性、非原创研究、格式规范、著作权要求等），原则上应被接受。维基百科关心的是内容的最终品质和合规性，而非其原始生成工具。 2. 强制草稿审核流程： 任何主要通过人工智能工具撰写或大幅扩充的新条目，在其首次提交时，不应直接发布到主条目空间（Article namespace）。强制要求此类内容必须先提交至草稿空间（Draft namespace）。 3. 严格审核要求： 放置在草稿空间的AI生成内容，必须经过至少一位熟悉维基百科方针、有经验的编辑进行全面、严格的审核。审核内容应包括但不限于事实核查、来源验证、语句通顺性、逻辑结构、格式规范以及是否符合所有核心方针。只有在确认该草稿完全符合维基百科所有标准后，方可由审核者或原作者（在获得审核者许可后）移动至主条目空间。 4. 经验编辑的豁免与责任： 对于已经获得巡查豁免权、巡查权或管理员权限的编辑者，鉴于其对维基百科方针和编辑规范的熟悉程度及过往贡献记录，在使用AI辅助生成内容时，如果该内容符合其通常的编辑品质水准并符合所有维基百科标准，可以暂免强制提交草稿的限制。然而，这类编辑者对其使用AI辅助生成的所有内容负有完全责任，必须确保其准确性和合规性。如果出现因AI使用不当导致的品质问题（如事实错误、大段不当内容等），应追究编辑者的责任，并可能影响其相关权限。 5. 滥用行为的处理： 对于反复使用人工智能生成明显不符合维基百科标准（特别是低品质、难以阅读、缺乏来源、或包含虚假信息）的内容，且在被其他编辑指出问题、回退或删除后，仍持续将此类内容提交至主条目空间的编辑者，其行为应被视为一种**新型的破坏**（Disruption）。根据维基百科现有的破坏方针，社群或管理员可以对其采取警告、临时封禁甚至永久封禁等处理措施。这旨在阻止通过滥用AI工具来绕过品质控制、浪费社群资源的行为。

理由阐述：

  • 第1点理由： 技术本身无罪，关键在于使用。如果AI能帮助生成符合标准的内容，不应人为设限。这符合“内容为王”的原则。
  • 第2点及第3点理由： AI模型，特别是大型语言模型，虽然能力强大，但其输出并非总是准确可靠的。它们可能“胡说八道”（hallucinate）、引用不存在的来源、生成带有偏见或不中立的文本，或产生结构混乱的语句。强制性的草稿审核流程为内容进入主条目空间设置了一道必要的质量门槛，降低了低品质AI内容直接损害百科全书声誉的风险。由有经验的编辑进行审核，是因为他们更理解维基百科的方针和标准，能更有效地识别问题。
  • 第4点理由： 信任原则在维基百科社群中至关重要。对经验丰富的编辑者给予一定的信任，假定他们能够负责任地使用工具并进行自我审查，可以减轻普遍性的审核负担。但这并非免责条款，而是更高标准的责任要求。如果滥用信任，后果也将更严重。
  • 第5点理由： 反复提交低品质AI内容的行为，与机器人滥建页面、内容灌水等其他形式的破坏本质相似，都是在损害维基百科的品质和社区运行效率。将其明确纳入破坏范畴，为社群处理此类行为提供了明确的依据，有助于维护百科全书的整洁和秩序。

诚邀各位维基人积极参与讨论，提出宝贵意见，共同完善这项提案，以更好地适应技术发展，同时坚守维基百科的品质、可信度和社群规范。

btw，这篇提案是AI（Gemini）写的，我觉得挺不错，没有什么逻辑混乱的地方。--V2eth（留言） 2025年4月19日 (六) 00:45 (UTC)[回复]

所以说人类有必要参加这个话题的讨论吗？--ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩ᠋ᠠᠨMandan 2025年4月19日 (六) 01:46 (UTC) 😄1[回复]
如果你不用人话，偏要用LLM生成这堆难以阅读没有实质意义的内容的话，我也只能(－)反对，还请您真的要提案就拿出您自己的对策--SunAfterRain 2025年4月19日 (六) 04:25 (UTC)[回复]
我不确定这是不是行为艺术，不过本站目前有人工智能相关规范吗？之前讨论过几次，但我不是很确定。顺便问问@Shizhao（ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月19日 (六) 05:04 (UTC)[回复]
反对2和3。这两条本质上仍是认为ai不如人类，与第1条矛盾。且不利于充分利用新技术的潜力。在我看来，AI的写作能力完全不比许多人类编者弱，没有必要歧视。我认为更合理的方案是进行“含有ai创作“的声明，含有这个声明的内容，可以针对ai的弱点，如编造参考文献等进行针对性的检查。同时应该在方针中提醒编者ai常犯的错误。现有方针没有这方面的指引。--IuyminirC（留言） 2025年4月19日 (六) 07:46 (UTC)[回复]
AI的弱点可能与参数、目标内容、提示词等多重因素相关，不比人类弱、无需歧视的条件不能始终满足。“写作能力”可能是用词书写能力，但编造内容和风格假大空等现象仍严重，编者有时也难以查证与精简──相当于重审与重写？以及这些内容的增长会对人类撰写条目的风格及热情构成影响，就如欧化中文。--YFdyh000（留言） 2025年4月20日 (日) 14:39 (UTC)[回复]
对“以下规范”回应：1. 这可能是理论上的正义，但缺少可行的执行方案。例如，AI生成内容的著作权争议，没有能力与标准做审查评估。2. 理论上正义。AI内容标注规范更有价值，如果真的要接纳一些。3. 复核者的责任和压力较大，要么过松，要么比自己写还累。--YFdyh000（留言） 2025年4月20日 (日) 14:32 (UTC)[回复]
有幸读过你先前疑似用LLM写的一篇草稿（现已被删除），那篇草稿的质量我想足以给这个话题盖棺定论了。——Mirfaek 2025年4月21日 (一) 12:42 (UTC)[回复]
强烈反对用AI生成的条目，但AI翻译是可以接受的。August讨论‧签名‧回复请ping 2025年4月27日 (日) 04:30 (UTC)[回复]
(－)反对，同U:SunAfterRain君的意见--KurGenera(留言) 2025年4月29日 (二) 16:55 (UTC)[回复]
(～)补充：阁下连ai习惯的markdown代码都没有修成wiki代码，故我正在思考...是否应该(－)强烈反对
毕竟ai写wiki代码的能力真的堪忧，还经常违反WP:5P1和WP:5P2，真的会把所有喂鸡人全部气到精神分裂--KurGenera(留言) 2025年4月29日 (二) 17:05 (UTC)[回复]
讲得很好，所以这个提案提出了什么新的内容吗？通过之后会有任何变化吗？ ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月3日 (六) 15:59 (UTC)[回复]
你维的垃圾已经够多了，如果担心垃圾少的话可以往自己的用户页多倒倒。--—远方传来风笛（Talk） 2025年5月7日 (三) 19:53 (UTC)[回复]
讨论还请注意WP:文明--IuyminirC（留言） 2025年5月8日 (四) 01:05 (UTC)[回复]
有人管别人叫牲口都不违反CIV，我说人家写的东西是垃圾怎么了？毕竟这玩意出现在喂鸡白料没见有多少用处。--—远方传来风笛（Talk） 2025年5月8日 (四) 01:28 (UTC)[回复]

有关申请权限与申请解除权限的方针条文与申请区的放置问题

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:权限申请、Wikipedia talk:解除权限、Wikipedia talk:申请解除权限。

WT:方针与指引#修订方针与指引的命名格式曾经提到有关申请权限与申请解除权限的方针条文与申请区的放置问题，当时Ericliu1912提议WP:解除权限比照WP:权限申请的处理并入WP:申请解除权限，而我则反建议WP:权限申请比照WP:解除权限与WP:申请解除权限的处理分拆方针条文与申请区的页面。考虑到现在距离批量调整规则页面名称已经有一段时间，社群或许应该探讨到底要选择哪个方案，我自己对于两个方案均持开放态度。Sanmosa 新朝雅政 2025年4月20日 (日) 10:12 (UTC)[回复]

我主张合并的理由是解除权限方面的方针页跟申请页都比权限申请要短，而且两者并没有扞格问题，不必分立，也方便检阅者一次确认有关要件。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月20日 (日) 12:55 (UTC)[回复]
然后刚刚才注意到甚至申请页面整段说明都是“包含引用自维基百科:解除权限方针”，没有任何内容差异，所以实际上两者完全可以合并在一起啊== —— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月20日 (日) 12:56 (UTC)[回复]
合并在同一页不易检视方针指引的修订历史。--Xiplus#Talk 2025年4月22日 (二) 15:36 (UTC)[回复]
如果走Ericliu1912方案的话，可以让除权申请区改为比照现WP:权限申请的申请区处理，也就是每类除权申请一个独立的子页面。Sanmosa 新朝雅政 2025年4月25日 (五) 12:35 (UTC)[回复]
@Xiplus？还是说你比较倾向于分拆WP:权限申请页？Sanmosa 新朝雅政 2025年4月29日 (二) 07:18 (UTC)[回复]
我觉得应该废除该页的方针地位，因为该页面几乎都是复述各权限方针的内容而已。如果真的有任何应该属于方针层级的内容，应当拆分到各权限介绍页或另立“权限申请方针”页面。--Xiplus#Talk 2025年4月29日 (二) 14:45 (UTC)[回复]
@Ericliu1912。Sanmosa 新朝雅政 2025年4月30日 (三) 01:58 (UTC)[回复]
这很值得考虑！—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月30日 (三) 05:54 (UTC)[回复]
@Xiplus、Ericliu1912：如此，那WP:权限申请的版面或许需要重新设计，此外WP:申请解除权限引述现WP:解除权限方针的部分也需要作一定的调整，个人建议可以参考现WP:存废复核请求顶部的说明文字处理。Sanmosa 新朝雅政 2025年4月30日 (三) 14:45 (UTC)[回复]
改写成最合适的说明文字当然可以，但我不认为现在两个申请页的说明有什么不得不改的问题。--Xiplus#Talk 2025年5月4日 (日) 04:28 (UTC)[回复]
@Xiplus：那我尝试在今日稍后给一个方案出来。Sanmosa 新朝雅政 2025年5月8日 (四) 04:47 (UTC)[回复]

应当确立允许使用机翻辅助翻译

我很困惑，明明现在的专业翻译业界的译者都使用机翻工具、翻译行业的招聘流程会要求翻译业者填报自己习惯使用的机翻软件，如果没有习惯的机翻工具甚至会不被视为专业翻译业者，为何反而维基百科对机翻辅助有一种非常不包容的态度，这种态度能如何确保文章质量？--∮♩♪♫♬♭♮♯☧⚧☦︎ 2025年4月22日 (二) 05:29 (UTC)[回复]

如果机翻能被看出来是机翻，就是不合格的翻译--熊猫火狗（留言） 2025年4月22日 (二) 07:03 (UTC)[回复]
我想，专业的翻译从事人员应当知道机翻错在哪里，哪个多义词译错了云云，西化的行文如何改为中文正常的习惯。如果机翻使用者能做到这点，在你站应该不会认为是需要被删除的机翻的。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年4月22日 (二) 07:05 (UTC)[回复]
不包容的多以劣质翻译为目标吧。也有刻板印象或个人偏好。不知是否可能用AI帮助评估（指点）质量。--YFdyh000（留言） 2025年4月22日 (二) 16:31 (UTC)[回复]
如果是AI翻译，其翻译的准确率实际上超高ヽ(○´∀`)ﾉ♪DeepSeek和Grok准确率可以到98%以上，当然一些阉割模型（4o-mini、4.1-nano）翻译出来的东西还不如谷歌翻译_(:з”∠)_
因此，我建议使用机翻后再进行人工校对。WP:机器翻译维护工作小组里面有言（类似于编修）：

如果可以简单修复机器翻译，那就尽量修复。

WP:翻译有言：

机器翻译能避免就避免，因为容易被生硬的语序带跑。

但是实操下来DeepSeek可以成功地避免“生硬的语序”。即使如此，经过人类手改也是可以的（？）而且原话是“避免”，不是“禁止”
所以：
  • (！)强烈抗议照搬机翻。
  • (＋)支持谷歌翻译后进行编修。
  • (＋)强烈支持使用AIGC辅助翻译后校对。
--KurGenera(留言) 2025年4月24日 (四) 11:08 (UTC)[回复]
补充：如果按照Help:翻译（emm上面那个打错了），其实际上还是没有禁止机翻的_(:з”∠)_--KurGenera(留言) 2025年4月24日 (四) 11:10 (UTC)[回复]
不能照本宣科，机翻很有可能被快速删除（WP:G13/WP:G14），百科明显是排挤低质量翻译的。--Nostalgiacn（留言） 2025年4月25日 (五) 04:55 (UTC)[回复]
印象里已经找到好几个明显机翻的页面了，这就去挂G13--KurGenera(留言) 2025年4月25日 (五) 10:03 (UTC)[回复]
DeepSeek和Grok准确率可以到98%以上？不会比任何一位人工翻译都准确吧？那这样看来好像发展挺快的。--日期20220626（留言） 2025年4月25日 (五) 09:47 (UTC)[回复]
补充：ai其实在专有名词翻译上可能不尽人意_(:з”∠)_比如gang rape，grok把它翻译成了集体强奸，但实际上应该翻译成轮奸。
所以翻译后出来的东西还是得校对一下¯\_(ツ)_/¯--KurGenera(留言) 2025年4月25日 (五) 09:59 (UTC)[回复]
不过轮奸的确是集体强奸…--日期20220626（留言） 2025年4月25日 (五) 10:11 (UTC)[回复]
可能算同义或近义词，gang rape也称group rape[2]，它适合作为group rape的译法。另外像是"轮流发生性关系"也是正式描述。所以AI及人类在用词上要考虑场景与上下文，如果没有上下文，无法评价对错？--YFdyh000（留言） 2025年4月25日 (五) 13:52 (UTC)[回复]
至少就现阶段而言，不应推荐使用机器翻译。“你能用，但被抓到那就是你的问题”，之类的。尤其生成式人工智能当道，本人认为此刻放宽有关限制，似无正面帮助。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月25日 (五) 05:56 (UTC)[回复]
如果机翻是过程，那么许多人都在做。如果机翻是结果，那么为何不毙掉？——暁月凛奈 (留言) 2025年4月25日 (五) 10:22 (UTC)[回复]
你当然可以使用机翻，像是chatgpt、grok之类的，别被发现是机器翻译就好，我就有好几篇是使用机器辅助翻译的，只要不到G13，甚至可以上GA、FA，用机翻都是你自己的事。August讨论‧签名‧回复请ping 2025年4月27日 (日) 04:26 (UTC)[回复]
翻译的文字也是（至少会被其他人认为是）编者原创的劳动成果。编者必须对自己发布的内容负责，这是人与人的信任问题。而机翻产出大量低质条目，就是在破坏信任，更甚者误人子弟，根本无益于建设百科全书。在我看来，这和WP:NOP的理念是一样的，代理隐藏了用户的“真实技术信息”，而照搬机翻隐藏了用户的真实认知水平、专业素养、语言组织和表达能力。--PexEric 2025年4月29日 (二) 16:06 (UTC)[回复]
成熟的译者就算使用机器辅助，也一定不教人读出痕迹。因为这是一种黑点，势必会影响别人对他能力的判断，进而影响信誉。--PexEric 2025年4月29日 (二) 16:18 (UTC)[回复]
社群应该在意用户的真实水平，还是用户成果（条目）的水平？如果“产出大量低质条目”，怎么隐藏了真实水平。如果指产出很多胡说八道的条目，没有机器辅助也长期有这种内容存在，尤其是如果选择信任编者而非参考文献。“不教人读出痕迹”但内容胡说才更严重吧，也就是不照搬甚至原创发挥的编者。--YFdyh000（留言） 2025年4月29日 (二) 20:52 (UTC)[回复]
没有什么好确立不确立的。成果是给人读的，那就可以；成果不是给人读的，不管是不是机翻都是不能接受的。就这样。--SunAfterRain 2025年4月29日 (二) 17:17 (UTC)[回复]

提议提升巡查员的门槛

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:新页面巡查、Wikipedia talk:权限申请。

原标题：提议提升巡查员及回退员的门槛。修改者：--此条未签名留言由Aqurs1（讨论｜贡献）于2025年4月26日 (六) 12:34 (UTC)加入。[回复]
因应此讨论串，提议提升巡查员及回退员的门槛。--Aqurs 2025年4月26日 (六) 08:22 (UTC)[回复]
由于已经得知WMF不容许此等方法自动获取“临时IP检视”权限，目前考虑到巡查员门槛仍然过低，继续讨论是否应该提升巡查员的门槛。注册时间也不需要因“检视临时账户IP”而有所限制，暂且改为跟回退的90日，目前提案改为是否将巡查员门槛提升至跟回退一样，谢谢。Aqurs 2025年4月26日 (六) 12:34 (UTC)[回复]

巡查员

提高巡查员门槛

现行条文

巡查员：需编辑至少250次，自首次编辑以来参与维基百科至少30日，最近一年内没有受到封锁（不合理封锁除外），且在过去三个月内（新注册者由注册日起计至申请当日）平均每天的编辑次数多于一次。

提议条文

巡查员：需编辑至少1000次，自首次编辑以来参与维基百科至少90日，最近一年内没有受到封锁（不合理封锁除外），且在过去三个月内平均每天的编辑次数多于一次。

(－)反对：巡查回退员有需要且满足查看临时账户IP信息资格可自行申请，且目前WP:RFR未见积压。Python6345（查论编） 2025年4月26日 (六) 11:24 (UTC)[回复]
@Python6345：预见的是社群将会人手授予“检视临时账户IP”的用户组，这样会造成大量积压，跟现在未见积压有什么关系？--Aqurs 2025年4月26日 (六) 11:41 (UTC)[回复]
目前有194名回退员和163名巡查员。而考虑到其中有同时持权者且查看临时账户IP权者可以提前申请并在添加用户组后由机器人一次性授予，亦难以预见积压存在。反而大幅增加巡查员门槛会加重巡查积压。Python6345（查论编） 2025年4月26日 (六) 12:16 (UTC)移除于2025年4月27日 (日) 04:53 (UTC)，因为提案内容改变。[回复]
(＋)支持，加入一个月的新手显然不适合当巡查、回退员。Пусть от победы☆к победе ведёт! 2025年4月26日 (六) 12:27 (UTC)[回复]
@阿南之人：见上方留言，提案修改了，你可能需要再审视一下你的支持票。Aqurs 2025年4月26日 (六) 12:34 (UTC)[回复]
（由“180日”改为了“90日”87000812。）——自由雨日🌧️❄️ 2025年4月27日 (日) 03:17 (UTC)[回复]
也不一定，我印象最深刻的就是@U:Summerize在未成为延确之前就担任了巡查员，而且行事非常成熟。 ——自由雨日🌧️❄️ 2025年4月27日 (日) 03:17 (UTC)[回复]
虽然支持，个人在观察中发现，其实巡查员在事实操作中[来源请求]获取难度高于回退员。--花开夜 留言 ·签名 ·贡献 2025年5月5日 (一) 17:53 (UTC)[回复]
我个人还是建议设定更加详细的标准。比如，创建一定数量的条目和DYK，或者一定数量的WP与主条目编辑数量等。--花开夜 留言 ·签名 ·贡献 2025年5月5日 (一) 17:54 (UTC)[回复]
(！)意见 没有看到明显依据，个人倾向折中，至少500次、至少60日。--YFdyh000（留言） 2025年4月26日 (六) 14:48 (UTC)[回复]
巡查员没必要更严格，巡查员本身没有什么高级权限--百無一用是書生 (☎) 2025年4月27日 (日) 02:31 (UTC)[回复]
@Shizhao：我是同意这点，不过回退员为何要求如此高？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月27日 (日) 05:58 (UTC)[回复]
WP:ROLL#回退功能的优点也可用于在编辑战中占据优势，此外回退员可以访问私有过滤器的日志。Python6345（查论编） 2025年4月27日 (日) 06:39 (UTC)[回复]
1000次确实有些多，另外是否可以增加豁免项，比如老用户以新账号开始、在其他维基有相当权限或者比较多的经验。--Kethyga（留言） 2025年4月27日 (日) 03:12 (UTC)[回复]
“老用户以新账号开始”应该视为一个全新的账户，不应进行豁免；其他站点的情况确实可以作为一些参考来稍微降低一些标准，但是不能达到完全“进行豁免”的程度。 Stang1364 2025年4月27日 (日) 07:04 (UTC)[回复]
(＋)支持提升到与回退员相同。August讨论‧签名‧回复请ping 2025年4月27日 (日) 04:23 (UTC)[回复]
(－)倾向反对：目前巡查员申请需要有巡查记录证实能力，且巡查有问题者会在申请阶段被拒绝，不认为有提升门槛之必要。Python6345（查论编） 2025年4月27日 (日) 04:53 (UTC)[回复]
(＋)支持，原本条件太宽松，新使用者在中文维基百科站务规定还不甚了解时，就能轻易申请，这情况着实不合理。我也认为必须施加更严谨的申请条件，以免浮滥申请权限的情况发生，有些人就是想当一个帽子（维基头衔）搜集狂，最近的不当行为页面刚好有一个例子。--Znppo（留言） 2025年4月27日 (日) 06:57 (UTC)[回复]
(？)疑问：请问是哪位仁兄？--自由米花🌾🌼 2025年4月28日 (一) 13:30 (UTC)[回复]
U:Peterxy12，编辑数不足100即申请多个本地和全域权限。Python6345（查论编） 2025年4月28日 (一) 13:50 (UTC)[回复]
（编辑冲突）我猜他想说的应该是这位，不过这位我觉得不是帽子收集狂而是扰乱了…… ——自由雨日🌧️❄️ 2025年4月28日 (一) 13:52 (UTC)[回复]
(：)回应，我说的就是他XD。--Znppo（留言） 2025年4月28日 (一) 14:00 (UTC)[回复]
不是扰乱--Peterxy12（留言） 2025年4月29日 (二) 10:27 (UTC)[回复]
硬性门槛似乎不用那么高，五百次／两个月应该够吧？另外或应说明这是一般建议门槛，若有显著例外，亦可破格申请。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月28日 (一) 18:31 (UTC)[回复]
(＋)支持提高标准--🚊　铁路Railway 论．签 2025年4月29日 (二) 04:29 (UTC)[回复]
纯粹给个建议方向：个人觉得提高门槛也不一定只看编辑数量，也可以从条目编写、模拟巡查和参与条目（存废）讨论等方面考察能力。当然这样就难以量化了。--Steven Sun（留言） 2025年4月29日 (二) 07:54 (UTC)[回复]
当前巡查员申请必须有巡查记录，否则会被快速拒绝，且如有用户质疑巡查不当亦需要合理回应。Python6345（查论编） 2025年4月29日 (二) 10:19 (UTC)[回复]
如果要提升巡查员的门槛的话，是否应该考虑要求巡查员同时满足巡查豁免者的门槛？Sanmosa 新朝雅政 2025年4月29日 (二) 12:02 (UTC)[回复]
我一直很困惑这点。巡查员既然有巡查豁免者的权限，那当然要求不应该低于巡查豁免者，这应该是个逻辑问题吧？（要么就规定巡查员并不能让自己免于巡查，这样也可合乎逻辑。）似乎之前有过多次类似提案但均未通过。 ——自由雨日🌧️❄️ 2025年4月29日 (二) 12:09 (UTC)[回复]
我在WT:新页面巡查/存档3#取消巡查员的巡查豁免权已经提出过“医者不自医”的情况，而且也明确指出了“巡查员有巡查别人条目的能力也应该有巡查自己条目的能力”这种说法不对应中文维基百科的现况，但还是存在个别用户对实际情况视而不见的事情。Sanmosa 新朝雅政 2025年4月29日 (二) 12:39 (UTC) 👍1[回复]
巡查员身具巡查豁免权、自动免巡印象中算技术问题。您可换角度看，巡查员的豁免与巡查豁免者是相同权限但不同缘由，场地工作人员免于安检/员工通道，极少数嘉宾或委员免于安检，不等于前者需具后者级别。但我仍支持对巡查员被豁免的页面做统计列出并存档以履行复审，或者变相削弱自动免巡（Sakamotosan拒绝接受机器人workaround方案）。--YFdyh000（留言） 2025年4月29日 (二) 20:45 (UTC)[回复]
正常情况下，如果巡查员确实有有巡查自己条目的能力，那现状并非一个问题，然而现状并非正常情况，那也就只能如此管制了。Sanmosa 新朝雅政 2025年4月30日 (三) 14:47 (UTC)[回复]
显然应该弹劾你所说案例，而非反过来降低全体巡查员授权标准。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月2日 (五) 09:08 (UTC)[回复]
这不现实，真按你这样说的话，全部巡查员都得除权。Sanmosa 新朝雅政 2025年5月2日 (五) 13:01 (UTC)[回复]
既然全部巡查员都得除权，不妨指出几个近期巡查员滥用巡查豁免的案例。Python6345（查论编） 2025年5月2日 (五) 13:19 (UTC)[回复]
拿日期20220626写的条目来说好了：他在今年4月30日建立的马达加斯加起义条目里来源与句号之间不知为何出现了空格，而且条目内的两个来源实际上是同一个来源（Special:Permalink/87050726）；他在同日建立的九州风神条目里来源与句号之间、英文与括号之间也不知为何出现了空格，而且内文的表述也不清不楚，我甚至还不知道九州风神是想要在哪个创业板上市（Special:Permalink/87054660）。Sanmosa 新朝雅政 2025年5月3日 (六) 02:56 (UTC)[回复]
然后再拿MykolaHK写的条目举例：克里米亚鞑靼饮食条目是他在昨天建立的，整个条目只有一个来源，“传统菜肴”章节完全没有来源，而且还是点列；开尔文桥站条目是他在今年2月16日建立的，大部分正文文段无来源支持，而且整体的翻译水平实在不太好（比如“且是迄今为止保留此配置的最繁忙的车站”）。Sanmosa 新朝雅政 2025年5月3日 (六) 03:13 (UTC)[回复]
对于这点我只能认为做翻译的基本上就是忠实翻译，很少人会自己去找来源，当然如果原本的条目有问题那就两边都挂维护模板就好了¯\_(ツ)_/¯翻译腔也是，也得挂上维护模板。--KurGenera(留言) 2025年5月3日 (六) 03:25 (UTC)[回复]
然而巡查权自带的巡查豁免权使之实际上基本无法实现。Sanmosa 新朝雅政 2025年5月3日 (六) 03:58 (UTC)[回复]
(：)回应Sanmosa：谢谢建议。关于克里米亚鞑靼饮食，确实来源较少，会先挂维护模板，但这里我认为点列是可以接受的，毕竟这里是介绍各菜式。而开尔文桥那边虽然有10个来源，但不得不承认正文来源确实较少，这里也会先挂维护模板，另外想问您认为“且是迄今为止保留此配置的最繁忙的车站”这句该如何表达？谢谢。--Mykola（留言） 2025年5月3日 (六) 10:29 (UTC)[回复]
“且是迄今为止保留此配置的车站中最繁忙者”或许较好。Sanmosa 新朝雅政 2025年5月3日 (六) 15:05 (UTC)[回复]
没有感觉更好。虽然之前也觉得两个“的”不太好，但细看我觉得没问题。问题可能在“保留此配置”的具体意涵（淘汰了吗），繁忙统计范围未指明（线路、城市、全球），以及没有列明来源，{{when}}。--YFdyh000（留言） 2025年5月3日 (六) 15:15 (UTC)[回复]
@YFdyh000：你或许需要结合前文来看，不结合前文来看的话，你自然看不出个所以然来。Sanmosa 新朝雅政 2025年5月4日 (日) 01:22 (UTC)[回复]
前文也没说月台。--YFdyh000（留言） 2025年5月4日 (日) 03:00 (UTC)[回复]
我怀疑是没完全翻译的锅。Sanmosa 新朝雅政 2025年5月4日 (日) 13:09 (UTC)[回复]
巡查员理当能巡查任何条目（无论是直接改善或是补充标记），不分对象，那自然也包含自己建立的页面。做不到这点，那就除权，没问题。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月4日 (日) 13:23 (UTC)[回复]
很多情况是应该发现、注意和提醒，而做不到弹劾。是提升而非降低标准？--YFdyh000（留言） 2025年5月2日 (五) 22:35 (UTC)[回复]
看了一下Wikipedia_talk:新页面巡查/存档3#提案四、Wikipedia_talk:新页面巡查/存档3#使巡查员可以移除或增加自己的巡查豁免者权限，社群似乎比较接受这个方向的变革，社群可以尝试朝着这个方向继续讨论下去，会比较容易形成共识。~~Sid~~ 2025年5月3日 (六) 13:40 (UTC)[回复]
(＋)强烈支持，个人认为：
现行条文

巡查员：需编辑至少250次，自首次编辑以来参与维基百科至少30日，

提议条文

巡查员：需编辑至少3000次2000次1500次，自首次编辑以来参与维基百科至少120日90日，

（原本打算想3000次或者5000次的，感觉不现实😂）--KurGenera(留言) 2025年4月29日 (二) 16:44 (UTC)[回复]
改了一下，还是1500次吧。1000次感觉还是太少。--KurGenera(留言) 2025年4月29日 (二) 16:51 (UTC)[回复]
(～)补充：至于巡查豁免权的问题...创建75个有效条目...至少得等鄙人编辑次数上次才有可能吧...因此还是(－)反对需要同时有巡查豁免权程度...--KurGenera(留言) 2025年4月29日 (二) 17:12 (UTC)[回复]
哥们，这标准太高了。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月29日 (二) 20:07 (UTC)[回复]
加到跟回退员一样的门槛就好了，同时有巡免的程度对你维来说还是太难了。--SunAfterRain 2025年4月29日 (二) 17:20 (UTC)[回复]
(！)意见：之前拆权的反对原因为担心巡查员编辑冲刷最近更改，如此可拆巡查员创建操作自动标记为已巡查，但不知是否有技术难题。Python6345（查论编） 2025年5月2日 (五) 03:22 (UTC)[回复]
“之前拆权的反对原因为担心巡查员编辑冲刷最近更改”吗？编辑巡查功能上线没多久，也不温不火。--YFdyh000（留言） 2025年5月3日 (六) 03:42 (UTC)[回复]
阅读之前讨论，我认为这则留言的理据是阻止拆权提案通过的主要原因，可参考Hotaru Natsumi案的支持理由。此外如上述提议因技术难题无法解决，本人倾向拆权但允许自我授权。Python6345（查论编） 2025年5月3日 (六) 03:56 (UTC)[回复]

重提允许巡查员自我增加与移除自动巡查权/将自动巡查与巡查员权限组分离

由于我看到上面有这方面的讨论需求，所以我单独拉出来讨论提高效率也较易于分别社群共识。
过往讨论参见Wikipedia_talk:新页面巡查/存档3#提案四、Wikipedia_talk:新页面巡查/存档3#使巡查员可以移除或增加自己的巡查豁免者权限
另外我对于提案是没有什么特别的意见，请不要因为我单独拉出讨论而视为我支持这个提案，谢谢。~~Sid~~ 2025年5月7日 (三) 14:30 (UTC)[回复]

建议将中文维基百科的自动确认用户的门槛降低

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

我想知道的是为什么英文维基百科的自动确认用户门槛低，而中文维基百科的自动确认用户门槛很高，是不是因为有编辑战所以才提高的？--Peterxy12（留言） 2025年4月29日 (二) 10:34 (UTC)[回复]

WP:常年提案#修改自动确认用户的门槛。阁下如果能提出个方案解决疑虑，或许也能有共识。--WiTo🐤💬 2025年4月29日 (二) 10:46 (UTC)[回复]
@WiTo7946：但我的困惑是具体的“疑虑”是什么？或许先探讨“疑虑”本身的合理性，然后再谈如何处理或解决“疑虑”会比较好。Sanmosa 新朝雅政 2025年4月29日 (二) 12:00 (UTC)[回复]
老实说我没怎么想参与这话题，我认为我无法判断这上或下调对本维到底有没有益，与其烦恼这个我还不如多写几个条目罢。--WiTo🐤💬 2025年4月29日 (二) 13:21 (UTC)[回复]
(－)强烈反对降低自确门槛编辑次数，但(＋)支持废除验证码或(＋)支持把时间减少到3天。
7天50次编辑，一个有闲的用户随便编修/修理内链都能1天轻松上50次编辑¯\_(ツ)_/¯比如鄙人就是注册3天后编辑次数100+😂不过加入4—7天这会就难受了，一直要输验证码╰（‵□′）╯
但是鄙人建议降低延伸确认用户门槛的时间¯\_(ツ)_/¯90天让鄙人很难受--KurGenera(留言) 2025年4月29日 (二) 16:32 (UTC)[回复]
(～)补充：防马甲。--KurGenera(留言) 2025年5月1日 (四) 18:57 (UTC)[回复]
是否是英文维基的参与度（人数）较多，所以应付破坏者/新人的反破坏力量更充足。另外是否有包容度差异。--YFdyh000（留言） 2025年4月29日 (二) 20:57 (UTC)[回复]
还是没人能解释当时具体的“疑虑”是什么吗？我连具体的“疑虑”是什么都不知道，我实在无法作任何进一步的评断。Sanmosa 新朝雅政 2025年4月30日 (三) 02:01 (UTC)[回复]
WP:刷编辑数的难度--YFdyh000（留言） 2025年4月30日 (三) 02:13 (UTC)[回复]
(：)回应，刷编辑数真的不难，举例，加个分类、取代新分类，来回弄一弄就上百个编辑数了，我个人认为是无难度。中文维基百科自动确认用户门槛也才50个编辑数，已经很低了。加上中维社群人员不多，没有像英文维基百科社群人员那么多，有那么多双眼睛帮忙看着，故我认为门槛数高一点还是好的。--Znppo（留言） 2025年4月30日 (三) 14:46 (UTC)[回复]
如果新人手动去干该机器人做的批量重复性业务，可能是引导问题。如果得当或有争议的改动数十次，也能部分看出他对本站的理解，应该不算无难度。假如做出了毫无争议的几十次小编辑，傀儡的概率提升。--YFdyh000（留言） 2025年4月30日 (三) 21:37 (UTC)[回复]
我的看法是既然“刷编辑数真的不难”，那编辑次数的门槛实际上与安全风险无直接关系。Sanmosa 新朝雅政 2025年4月30日 (三) 23:41 (UTC)[回复]
(：)回应，我个人觉得自动确认用戶权限的编辑次数拉长一点，保持目前50次，有其必要性。理由为若是一般新手，由于不熟悉维基百科规则，可能无法如此快速凑到50次编辑数。
我举个例子，持续出没的破坏者LTA:人瑞，此君就很不熟悉维基百科规则，他曾有一个分身账号，未曾被发现，详见User:Hsiw19372的编辑贡献，他也是熬了快两个星期，才凑满50次编辑数，成功取得自动确认用戶权限，随即移动草稿条目，进行破坏。我无法想像如果自动确认用戶权限若改为10次，情况会混乱成何种样子。--Znppo（留言） 2025年5月1日 (四) 11:32 (UTC)[回复]
但我们也总不可能假定所有新用户为LTA。Sanmosa 新朝雅政 2025年5月2日 (五) 08:34 (UTC)[回复]
可能您好，个人体验是，这个要求也就是7天有硬性压力，至于50次，我个人体验是学会自动确认用户专用的维基语法需要的编辑数大于50次，可以说压力被稀释了。望楼主回复为盼--Mahengrui1（留言） 2025年5月1日 (四) 04:09 (UTC)[回复]
硬编辑次数的确不难，但容易判断为Wikipedia:游戏维基规则，也可以人为判断。我认为正常编辑下，7天+50次编辑基本可以筛走一部分过路用户，并且自动确认用户是很多基础意见表达讨论的基本条件，这样“严”的规定可以间接判断用户对项目的参加程度、一些规则的理解程度和意愿程度。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月2日 (五) 11:11 (UTC)[回复]
我好奇的是，究竟编辑次数还是参与时间门槛比较有利于阻碍扰乱呢？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月2日 (五) 16:10 (UTC)[回复]
都有助预防一鼓作气的扰乱，一个是批量操作可达，一个是耐心等待（处心积虑）可达。--YFdyh000（留言） 2025年5月2日 (五) 22:41 (UTC)[回复]

关于近期 DYK 条目出现“孤立条目”现象之讨论与征询意见

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:新条目推荐/候选、Wikipedia talk:孤立页面。

近来在浏览或参与Wikipedia:新条目推荐（DYK）提名与审查过程时，发现一个值得关注的倾向：有部分条目虽然在内容品质与新颖性方面表现良好，但其与现有条目的连结极少，有的甚至仅存在于消歧义页面或单一来源条目中，导致这些条目呈现“孤立状态”。

以往 DYK 评选较常强调条目的首段表述、来源可靠性与是否符合“新建条目”的时间门槛，然而随着条目主题日益冷门化、专精化，若未与相关条目建立适当的内部链接，恐将影响：

  • 条目的可见度与后续阅读引导
  • 条目的长期维护与页面存活率
  • 维基百科条目网络的整体连贯性与可探索性

因此，想在此向社群提出以下问题，征询各位的意见：

  1. 是否认为 DYK 条目应该在可行范围内尽量避免孤立状态，例如要求提名者尝试在主题相关条目中加入内部链接？
  2. 我们是否应考虑在 DYK 提名页或模板中加入建议性提醒，鼓励条目与主题主条有互链关系？
  3. 有无其他可行方式，能在不过度提高提名门槛的情况下，兼顾条目品质与条目网络建构？

在下希望透过征询与交流，为DYK条目的完整性更上一层楼，欢迎各位编者踊跃提出看法。--David Jackson(留言) 2025年5月5日 (一) 08:31 (UTC)[回复]

@David Jackson：是否可以举些实例呢？否则难以具体讨论。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月5日 (一) 13:18 (UTC)[回复]
提供以下条目让阁下参阅：
--David Jackson(留言) 2025年5月6日 (二) 01:47 (UTC)[回复]
所以具体危害是什么？比如说我自己写的点校本二十四史这样，我看除了{{二十四史}}导航模板和与之相关的页面以外，一个连入都没有。为什么条目的可见度是危害？为什么和现有条目连结过少，会影响长期维护？和页面存活度有什么关系？页面删除与否，本来就是点击率没有关系的。你维的条目网络本来就是一团垃圾，你维的读者本来就有很大部分是从搜索引擎进入的，没有其他条目连入影响也不会太大吧。--Ghren🐦🕚 2025年5月5日 (一) 15:52 (UTC) 👍2[回复]
感谢您的回应，我理解您对“条目连入”重要性的质疑，也同意不是每一个条目都需要有大量连入才会被阅读或维护良好。
不过这里提出的观点，并非要将“条目可见度不高＝危害”划上等号，而是想探讨在 DYK 这样一个“曝光机会高”、“条目仍在早期发展阶段”的情境下，是否能善用这个时机，促进条目更快进入条目网络，让读者不只能从首页点进来，也能在主题相关条目中自然找到它。
当然，有些冷门主题条目本身就很难建立内部链接，那自然不会强求。而我希望讨论的是：在可以的情况下，是否能鼓励建立这种串联，而不是将其完全忽略。
至于维护与删除问题，我同意不是靠点阅数来决定，但条目若无上下文关联、无人接续扩充或修订，常常会面临“维护者孤军奋战”的窘境。这是我观察到的状况，仅供大家参考。--David Jackson(留言) 2025年5月6日 (二) 02:11 (UTC)[回复]
我同意孤立页面确实是应该尽量避免的问题。不过，这实在不能强求，要靠社群一起努力。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月6日 (二) 17:22 (UTC)[回复]
我好几年前一直在追踪每一篇参与DYK评选的条目的链入情况，近一两年因为个人精力有限没再追踪了。不过我就算是发现有DYKC条目缺乏链入页面，我做的第一件事情也是尽量自己去动手在别的条目当中添加链接至该条目的链接，除非我自己找不到合适的地方去添加条目链接，否则我一般不会在评选当中提这事情，本来这就不是DYK条目的硬性要求，只是能够避免孤立状态当然更好。--💊✖️2️⃣3️⃣（留言） 2025年5月6日 (二) 01:02 (UTC)[回复]
追踪连入状况是件很累人的事情(吃力不讨好)，但就是希望集众人之力或凭一己之力诞生的DYK条目，它的能见度能再提高。我一向认为每个条目都有它诞生的意义，能入选DYK更彰显它的独特之处，如果能在评选规则内加入善意提醒，请编者尽量在相关条目内增加引用与连结，这样就可以避免产生孤立状态。当然目前也只是先讨论交流，并没有说一定要执行。是否纳入提醒内容，仍需建立共识后再作后续调整。--David Jackson(留言) 2025年5月6日 (二) 02:08 (UTC)[回复]
你觉得DYK条目应该避免孤立状态，就自己动手去合适的其他条目添加链入，你自己找不到合适的条目，可以去评选页请求他人帮忙，除非必要尽量别在评选页中以哪怕是建议的口吻说链入的事情，本来这就不影响DYK。我要和你一样觉得这值得更多人关注的话，我十年前就来互助客栈提出这问题了。--💊✖️2️⃣3️⃣（留言） 2025年5月6日 (二) 11:23 (UTC)[回复]
R-5 (导弹)那个可以通过{{俄罗斯和苏联导弹}}汇链入，已修正，连不上是因为导航模板对应链接名不对应。至于缺少链入的问题，参见Wikipedia:孤立页面，保障条目的链入度一定程度是有必要的。另外创建低链入的条目很可能是与其主要关联的条目还没有创建，或者没意识到可以通过已有的条目进行链入。我自己的例子就是避难所 (波特·鲁滨逊和麦狄恩歌曲)（2016年10月），这个条目就是看到相关的MV才考虑开题弄的，主要关联条目波特·罗宾森当时还没创建（题材不太熟，而且内容颇多而没准备翻译），可以关联并已存在的条目A-1 Pictures也是2016年11月才链出过去。现时一部分链入是依靠{{A-1 Pictures}}带入的。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月6日 (二) 05:11 (UTC)[回复]
孤立页面一直是个伪概念，对于条目质量的提升似乎也未见帮助巨大，不认为有特别关注的必要。另建议在起草讨论时避免过度使用AI。--—远方传来风笛（Talk） 2025年5月7日 (三) 13:58 (UTC) ❤️1[回复]
我只能说，勉强加上连结没有必要。我当时还在想如何增加伊万·斯维特的连结呢：是加在哈尔滨吗？日本—乌克兰关系呢？还是其他？很困难吧。勉强给其他条目加上连结，不就如连结农场的作法一般？--Saimmx（留言） 2025年5月7日 (三) 14:53 (UTC)[回复]
(：)回应：感谢各位的意见，让我可以从不同角度思考，看来就先维持原状吧。日后只要有空参与DYK评选，会尽我所能增加评选条目的连结，当然不会随便乱连。再次感谢各位的回应与指教。🙏--David Jackson(留言) 2025年5月8日 (四) 08:26 (UTC)[回复]

技术

本主题或以下段落文字，在讨论结束后应存档至Template talk:Navbox、MediaWiki talk:Common.css、Template talk:Hlist/styles.css。

之前开过，没人回存档了，例见沙盒。刚刚又稍微研究了一下，虽然不太懂不过应该找到问题所在了，似乎是Template:Hlist/styles.css line 143附近的first-child::before。希望懂行的帮忙处理一下，谢谢。--惣流·明日香·兰格雷不姓式波 2024年11月30日 (六) 04:49 (UTC)[回复]

参照日文维基百科，应该是要把MediaWiki:Common.css#L-162--L-172，改成Template:Hlist/styles.css#L-127--L-102，注释掉的部分，不可有.hlist ol ol:before--Qqkuro66541（留言） 2024年12月2日 (一) 15:23 (UTC)[回复]
在迁移完Navbox和Hatnote之后，接下来准备着手迁移Hlist/Plainlist，只不过需要精力以及人手支援。--Dabao qian℡ 2024年12月17日 (二) 18:15 (UTC)[回复]
@Dabao qian：目前进度如何？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年3月1日 (六) 11:41 (UTC)[回复]
@Dabao qian：似乎没有消息，那就先存档吧，以后有问题再提出来。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月5日 (一) 13:10 (UTC)[回复]

本地安全投票测试

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

于Phabricator追踪
工单T380020

据此前讨论，本地安全投票提案已通过。目前等待软件层面启用本地安全投票后，应先测试以确认是否可行及具体流程，故在此开启讨论串。（当然还是要先等patch过了再说）

cc @Stang、ZhaoFJx、SCP-2000： 请留意。--beef [talk] 2025年1月20日 (一) 13:13 (UTC)[回复]

还是这个页面吗？Special:安全投票--百無一用是書生 (☎) 2025年1月21日 (二) 02:24 (UTC)[回复]
对。 Stang★ 2025年1月21日 (二) 09:41 (UTC)[回复]

感觉根据这条留言要分析处理的技术问题是挺多的，比较悲观的判断可能今年4月轮的定期投票那个时候依旧没法解决……@0xDeadbeef、ZhaoFJx、SCP-2000： Stang★ 2025年2月4日 (二) 08:46 (UTC)[回复]

那就等着吧，WMF写代码就这个样子，没啥可说的。--beef [talk] 2025年2月5日 (三) 11:57 (UTC)[回复]
所有blocker都没了，咱看看能不能往前推进一下。另外两个建议，之前提名期到投票期留了这么长的时间，在本地进行安全投票的时候是不是可以适当缩减一下；目前的共识是管理员来做设置投票的操作，可以写一个详细的操作手册关于怎么配置。@0xDeadbeef： Stang★ 2025年4月24日 (四) 03:47 (UTC)[回复]
管理人员申请流程精简问题，可以等这批申请结束以后一起检讨。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月5日 (一) 13:08 (UTC)[回复]

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

Category:非条目级XXX条目错误

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

在Module:PJBSClass/main于Special:Diff/84547074加入na=true,之后，仍有大量页面被分配到Category:非条目级XXX条目分类，具体页面见Category:非条目级页面，相信是调用{{WikiProject XXX}}等模板所导致的。Пусть от победы☆к победе ведёт! 2025年2月3日 (一) 04:34 (UTC)[回复]

@A2569875：您的看法如何？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月5日 (一) 15:48 (UTC)[回复]

就辽宁省2019年以来行政区划合并维护请求帮助。

本主题或以下段落文字，在讨论结束后应存档至Talk:辽宁省、WikiProject talk:中国行政区划。

按照维基百科:机器人建立条目小组/中华人民共和国行政区划/简明手动维护手册的说明，请求各位帮助。

详细

沈阳市

和平区

1.撤销西塔街道，将其管辖区域划入北市场街道。调整后，北市场街道办事处驻地不变。 2.撤销八经街道，将其管辖区域划入南市场街道。调整后，南市场街道办事处驻地不变。 3.撤销集贤街道，将其管辖区域划入马路湾街道。调整后，马路湾街道办事处驻地不变。

沈河区

1.撤销大西街道，将其管辖区域划入朱剪炉街道。调整后，朱剪炉街道办事处驻地为沈河区万寿寺街161号（原大西街道办事处驻地）。 2.将朱剪炉街道府北、迎宾2个社区划入新北站街道，并将新北站街道更名为北站街道。 3.撤销山东庙街道，将其管辖区域划入风雨坛街道。调整后，风雨坛街道办事处驻地不变。 4.撤销大南街道，将其管辖区域划入滨河街道。调整后，滨河街道办事处驻地为沈河区大南街229-3号（原大南街道办事处驻地）。 5.撤销丰乐街道，将其管辖的丰乐、溪林、长青、沈水4个社区划入南塔街道，将万科、和泰、青阳3个社区划入泉园街道。

铁西区

1.撤销保工街道，将其管辖区域划入兴顺街道。调整后，兴顺街道办事处驻地不变。 2.撤销兴工街道，将其管辖的两洞桥、爱工、九委、南七东路4个社区划入兴华街道，将沈辽东路、飞翔路2个社区划入凌空街道。 3.撤销贵和街道，将其管辖区域划入兴华街道。调整后，兴华街道办事处驻地为铁西区爱工南街17号（原兴工街道办事处驻地）。 4.撤销艳粉街道，将其管辖的永合、永善、光学、光辉、红艳路、红昌、红盛、艳阳、艳华、艳粉街10个社区划入凌空街道，将大天地社区划入工人村街道。 5.将兴华街道的爱心社区划入凌空街道。调整后，凌空街道办事处驻地为铁西区艳粉街32号（原艳粉街道办事处驻地）。 6.撤销七路街道，将其管辖的建设、第一城、创意、星光、开发、育工6个社区划入重工街道，将工人新村一、工人新村二2个社区划入工人村街道。 7.将启工街道启飞社区划入重工街道。调整后，重工街道办事处驻地为铁西区肇工南街25-12号（原七路街道办事处驻地）。 8.撤销西三环街道，将其管辖的七号街、军营、宁新3个社区及张士村划入昆明湖街道，将宁鹏、宁官、宁民3个社区及宁官村划入翟家街道。 9.将翟家街道的大挨金、小挨金、大于、土台子、下地、壕上、翟家、东胜8个村及中央大街社区划入大青中朝友谊街道。 10.将大青中朝友谊街道的余粮、后谟2个村划入翟家街道，将隆湖、熙湖、中央湖畔3个社区及安乐、团结、高明、共和4个村划入昆明湖街道。 11.将大潘街道的后马村划入大青中朝友谊街道，四台子村划入昆明湖街道，岳家、林台、前马3个村划入高花街道。 12.将昆明湖街道办事处驻地由铁西区七号路7甲5-1号，迁至铁西区花海路28号。 13.将翟家街道办事处驻地由铁西区翟家街道曹家村，迁至铁西区开发十八号路21-25号5门。 14.将大青中朝友谊街道办事处驻地由铁西区沈辽西路113-35号8门，迁至铁西区沈辽西路113-49号。

皇姑区

1.撤销辽河街道，将其管辖区域划入北塔街道。调整后，北塔街道办事处驻地为皇姑区巴山路48-3号（原辽河街道办事处驻地）。 2.将北塔街道崇山东路以北区域的新铁、柳条湖、崇东、富裕、嘉麟、金山、富丽阳光、东窑、西窑9个社区划入陵东街道。 3.撤销塔湾街道，将其管辖的怒江街以西区域的汾河、淮北、淮东、百鸟、渭河、怒江6个社区划入舍利塔街道，怒江街以东区域的翔凤、紫荆花西、紫荆花东、舍宅4个社区划入黄河街道。

大东区

1.撤销小东街道，其管辖区域划入万泉街道。调整后，万泉街道办事处驻地由大东区大东路175号，迁至大东区东逸街27号。 2.撤销新东街道，其管辖区域划入东塔街道。调整后，东塔街道办事处驻地不变。 3.撤销北海街道，将其管辖的东方、俪城、卫士、矿北4个社区划入上园街道，将四德、领域、铂悦3个社区划入东站街道，将锦园社区划入津桥街道。 4.撤销洮昌街道，将其管辖的北海、合作、世博、公务员4个社区划入大北街道，将吉祥、梨树、法库、大北桥、铁岭、如意6个社区划入津桥街道。 5.将前进街道的汇泽、福居、蓝庭、新望、宝地、富东6个社区划入二台子街道。 6.将二台子街道北大营西路以南、北大营东街以西区域划入上园街道。

浑南区

1.撤销营城子街道，将其管辖区域划入李相街道。调整后，李相街道办事处驻地不变。 2.撤销望滨街道，将其管辖区域划入满堂街道。调整后，满堂街道办事处驻地不变。 3.撤销永胜街道，将其管辖的永胜、洪台沟、渔樵、前康家、后康家、于胜、潘李、金德胜、东靠山9个村划入王滨街道；将兴农、李相、畜牧场3个村划入东湖街道。

于洪区

1.撤销大兴街道，将其管辖区域划入马三家街道。调整后，马三家街道办事处驻地不变。 2.撤销于洪街道，将其管辖的东民、前民、和平3个社区和光辉、爱国、全胜、兴盛4个村划入沙岭街道；将红旗、世代2个社区划入迎宾路街道。

沈北新区

1.撤销石佛寺街道，将其管辖区域划入兴隆台街道。调整后，兴隆台街道办事处驻地不变。 2.撤销沈北街道，将其管辖区域划入新城子街道。调整后，新城子街道办事处驻地不变。 3.撤销清泉街道，将其管辖的清宇社区和前屯、后屯、前腰堡、中五旗、小洋河、清泉、泥沟堡、崔公堡8个村划入清水台街道，将后腰堡、拥屯、湾道、依路4个村划入马刚街道。 4.撤销尹家街道，将其管辖的沟子沿村划入道义街道，将尹家、光荣、小营子、永丰、茨榆、创业、曙光、东拉拉、新农、穆家10个村划入财落街道。调整后，财落街道办事处驻地不变。 5.将道义街道管辖的正良、柳岸、鑫欣、大学城、晨兴、民丰6个社区和正良、五台子、郭三、郭七、道义一、道义二、东场、孝信汉、孝信鲜9个村划出，设立正良街道。调整后，正良街道办事处驻地为沈北新区沈北路6号（原道义街道办事处驻地）。 6.将道义街道办事处驻地由沈北新区沈北路6号，迁至沈北新区蒲河路41-1号。

苏家屯区

1.撤销湖西街道，将其管辖区域划入解放街道。调整后，解放街道办事处驻地不变。 2.撤销大沟街道，将其管辖区域划入十里河街道。调整后，十里河街道办事处驻地不变。 3.撤销八一街道、红菱街道，合并设立八一红菱街道。调整后，八一红菱街道办事处驻地为苏家屯区八一路62号（原八一街道办事处驻地）。 4.撤销王纲街道、临湖街道，合并设立沈水街道。调整后，沈水街道办事处驻地为苏家屯区枫杨路83号（原临湖街道办事处驻地）。 5.撤销姚千街道、白清街道，将原姚千街道的小堡屯、刘太平、陡子峪、杨千后房、刘千户屯、上瓦房6个村划入佟沟街道，将马耳山、田水、姚千、代官、唐台、佟家6个村和姚千社区与原白清街道合并设立白清姚千街道。调整后，白清姚千街道办事处驻地为苏家屯区广福路200号（原白清街道办事处驻地）。

新民市

1.撤销新城街道，将其管辖区域划入东城街道。调整后，东城街道办事驻地为新民市民族街30号（原新城街道办事处驻地）。 2.将东城街道的烧锅、新建、郭屯、北丁、老君当、东郊、城东、大东8个社区划入新柳街道。 3.将新柳街道办事处驻地由新民市北环路28号，迁至新民市辽河大街152号。

大连市

西岗区

1.将原站北街道和原日新街道进行合并，称日新街道。调整后的日新街道下辖12个社区。 2.将原北京街道和原人民广场街道进行合并，称人民广场街道。调整后的人民广场街道下辖13个社区。

沙河口区

1.拆分兴工街道，把原兴工街道的大庆社区、西山社区、宏发社区、恒苑社区4个社区与马栏街道合并，新成立马栏街道。调整后，马栏街道下辖14个社区，街道办事处驻地：黄河路876C。 2.拆分兴工街道，将原兴工街道的泉涌社区、永吉社区、兴新社区、兴盛社区、兴社社区、如意社区6个社区（含大连机车厂）与中山公园街道合并，新成立西安路街道。西安路街道下辖14个社区，街道办事处驻地：联合路38号。 3.撤销星海湾街道、白山路街道，新成立星海湾街道。星海湾街道下辖17个社区，街道办事处驻地：星海一街19号。

甘井子区

1.撤销中华路街道、兴华街道，重新设立中华路街道，以原两个街道地域范围为新街道地域范围。街道办事处驻地为原中华路街道办事处驻地（甘井子区汇信街22号）。

旅顺口区

1.撤销得胜街道、市场街道，重新设立得胜街道，以原两个街道地域范围为新街道地域范围，街道办事处驻地为原得胜街道办事处驻地（旅顺口区黄金街7-19号）。 2.撤销三涧堡街道、北海街道，重新设立三涧堡街道，以原两个街道地域范围为新街道地域范围，街道办事处驻地为原三涧堡街道办事处驻地（旅顺口区金石路501号）。 3.撤销登峰街道、光荣街道，重新设立登峰街道，以原两个街道地域范围为新街道地域范围，街道办事处驻地为原登峰街道办事处驻地（旅顺口区和顺街32号）。 4.将龙王塘街道盐厂新村、郭家沟村调整至龙头街道管理。调整后，龙头街道地域范围北与长城街道、三涧堡街道接壤，南临黄海，东与龙王塘街道毗邻，西与水师营街道相接，西南与合并后的登峰街道、得胜街道相连。 5.将原龙头街道大连奶牛场划转至龙王塘街道管辖，继续由高新区管委会代管。

金州区

1.将大窑湾街道原归属于马桥子街道、海青岛街道、大孤山街道、湾里街道的辖区范围重新划归四个街道管辖，恢复原有隶属关系。 2.撤销光明街道、中长街道，新设立光中街道，以原两个街道地域范围为新街道地域范围，街道办事处驻地为原光明街道办事处驻地（金州区胜利西小区38号）。

普兰店区

1.太平街道和南山街道合并，撤销南山街道，合并后为太平街道，街道驻地为原太平街道驻地。

鞍山市

海城市

撤销验军街道，将其下辖的15个社区成建制划入兴海街道。

将温泉街道更名为东四方台街道。

台安县

撤销台北街道，将其下辖的6个村、2个社区成建制划入八角台街道。

撤销台南街道，将其下辖的5个村、3个社区成建制划入台东街道。

岫岩县

撤销仙人咀街道，将其下辖的5个村成建制划入雅河街道。

撤销大宁街道，将其下辖的3个村成建制划入阜昌街道。

铁东区

撤销常青街道，将其下辖的5个社区成建制划入湖南街道。

撤销对炉街道，将其下辖的7个社区成建制划入和平街道。

撤销长甸街道，将其下辖的6个社区成建制划入解放街道，并将解放街道办事处的2个社区（？）成建制划入山南街道。

撤销胜利街道，将其下辖的6个社区成建制分别划入站前街道和园林街道。

撤销钢城街道，将其下辖的5个社区成建制划入站前街道。

将东长甸街道更名为长甸街道，并将新兴街道的2个社区（？）成建制划入长甸街道。

铁西区

撤销新城街道，将其下辖的4个村成建制划入永发街道。

撤销启明街道和兴盛街道，将其下辖的7个社区成建制划入八家子街道。

将兴盛街道的1个社区（？）划入永乐街道。

撤销新陶官街道和北陶官街道，将其下辖的9个社区成建制划入繁荣街道。

立山区

撤销滨河街道，将其下辖的6个村、10个社区成建制划入灵山街道。

撤销深南街道，将其下辖的9个社区成建制划入深北街道，并将深北街道更名为深沟寺街道。

千山区

撤销对桩石街道，将其下辖的4个村、1个社区成建制划入东鞍山街道。

高新区

撤销汪峪街道，将其下辖的5个社区成建制划入千山街道。

撤销红岭街道，将其下辖的2个村、6个社区成建制划入齐大山街道。

千山风景区

撤销温泉街道，将其下辖的4个村、4个社区成建制划入铁东区大孤山街道。


抚顺市

新抚区

撤销千金街道，将其所辖的元雪社区、西一路社区、白云社区、千金社区行政区域以及乐园社区西五街铁路以东部分行政区域划归站前街道。站前街道办事处驻浑河南路中段54号。

将千金街道乐园社区西五街铁路以西部分行政区域划归福民街道管辖，并将新抚街道大官社区千金路铁路以南部分行政区域划归福民街道管辖。福民街道办事处驻新抚路25号；新抚街道办事处驻新抚路33号。

撤销南阳街道，将其所辖行政区域划归永安台街道管辖。永安台街道办事处驻南台五街6号。

撤销东公园街道，将其所辖行政区域划归榆林街道管辖。榆林街道办事处驻榆林路47号。

撤销南花园街道，将其所辖行政区域划归刘山街道管辖。刘山街道办事处驻刘山二街57号。

东洲区

撤销张甸街道，将其所辖行政区域划归东洲街道管辖。东洲街道办事处驻庆安路8号。

撤销平山街道，将其所辖行政区域划归老虎台街道管辖。老虎台街道办事处驻虎南街15号。

望花区

撤销古城子街道、五老屯街道，将其所辖行政区域划归演武街道管辖。演武街道办事处驻古城子一路1号。

撤销田屯街道，将其所辖行政区域划归工农街道管辖。工农街道办事处驻丹东路（西段）北厚街。

撤销新民街道，将其所辖的洗化社区、昌盛社区行政区域划归和平街道管辖。和平街道办事处驻雷锋路（东段）52-2号。

将新民街道所辖的凤城社区、台安社区、油研社区、乐园社区、灯塔社区和玫瑰城社区行政区域划归光明街道管辖。光明街道办事处驻光明二街1号。

顺城区

撤销河东街道，将其所辖行政区域划归新华街道管辖。新华街道办事处驻站东街2号。

本溪市

平山区

撤销工人街道办事处，将转山、新和、新德、新麓4个社区划归南地街道，南地街道办事处驻地不变。

将工人街道办事处曙光、和平2个社区和南地街道福利社区、兴隆社区部分（解放南路、转山路、解放南二路与崔东路围合区域）划归站前街道。

将望溪公园区域划入东明街道管辖。

撤销桥头街道和北台街道，区域合并设立桥北街道，桥北街道办事处办公地址：本溪市平山区北府路18号（原北台街道办事处驻地）。

溪湖区

撤销彩北街道，将矿材、彩西、耐火、彩宏、新立、彩新、彩北、新光、彩建9个社区划归东风街道管辖，办公地址迁至原彩北街道办事处（本溪市溪湖区彩屯北路三江天艺亲子园东侧下行30米）。

撤销竖井街道，将竖井、高山、黑金、宝藏、华阳、华丰6个社区划归彩屯街道管辖。办公地址不变（本溪市溪湖区彩胜街）。

将原东风街道三会厂村、原河西街道头道社区划归火连寨街道管辖，火连寨街道办事处办公地址不变（本溪市溪湖区寨中路）。

高新区

撤销张其寨街道，将张其寨、大柳峪、花岭、黄木厂、大翻身、达贝沟6个村划归日月岛街道管辖。

明山区

撤销东兴街道办事处，区域整体并入新明街道办事处，新明街道办事处机关驻地不变，办公地址：本溪市明山区育龙路199号。

撤销金山街道办事处，区域整体并入北地街道办事处，北地街道办事处机关迁移至原金山街道办事处机关驻地，办公地址：本溪市明山区紫金路53号。

南芬区

撤销郭家街道办事处，南芬村、赵家村划归南芬街道办事处，解放村、金坑村划归思家岭街道办事处，永安村、柏峪村划归下马塘街道办事处。

撤销铁山街道办事处，所辖赵家、铁山、三十六户、六百户、对面沟5个社区划归南芬街道办事处。

丹东市

振兴区

撤销西城街道，并入纤维街道。

撤销头道桥街道，并入站前街道。

撤销六道沟街道，并入临江街道。

元宝区

撤销八道街道，并入广济街道。

撤销六道口街道，并入兴东街道。

振安区

撤销金矿街道办事处。

锦州市

古塔区

撤销天安街道，并入保安街道。

撤销站前街道，民治、民族、民生、三宝4个社区并入保安街道，阜康、丰乐2个社区并入新设立的古城街道。

撤销北街街道、南街街道、饶阳街道，设立古城街道，古城街道管辖原北街街道、南街街道、饶阳街道行政区域及原站前街道的阜康、丰乐2个社区。

撤销钟屯街道，并入士英街道。

将敬业街道的兴业社区划归石油街道管辖。

太和区

将汤河子街道与女儿河街道合并，命名为女儿河街道。

将太和街道与营盘街道合并，命名为营盘街道。

将凌西街道更名为太和街道，并将原新民街道星河社区划入新太和街道。

保留新民街道，将原凌西街道南山社区、一五五社区划入新民街道。

将兴隆街道与大薛街道合并，命名为大薛街道。

滨海新区（锦州经济技术开发区）

将天桥街道6个社区划入王家街道，撤销王家街道，合并设立天桥街道。

将天桥街道中山堡、尹屯村划入杏山街道，合并设立杏山街道。

撤销龙栖湾街道，并入娘娘宫街道。

凌河区

撤销凌安街道，并入锦铁街道。

撤销铁新街道，并入榴花街道。

凌海市

撤销大有街道，并入八千街道。

北镇市

撤销沙河子街道，并入沟帮子街道。

营口市

鲅鱼圈区

将海东街道与望海街道合并，命名为望海街道。

将原属海星街道的大董屯、神井子2个社区划入新合并的望海街道管辖。

大石桥市

将石桥街道与青花街道合并，命名为镁都街道。

老边区

将城东街道与老边街道合并，命名为老边街道。

站前区

将东风街道、新兴街道合并，命名为东兴街道。

西市区

将河北街道与渔市街道合并，命名为渔市街道。

将滨海街道与沿海街道合并，命名为[[滨海街道]。

将清华街道与胜利街道合并，命名为清华街道。

阜新市

海州区

撤销新兴街道、和平街道，设立和平街道。

撤销站前街道、西阜新街道，设立站前街道。

撤销五龙街道、工人村街道，设立五龙街道。

撤销平安西部街道、东梁街道，设立平安西部街道。

细河区

撤销东苑街道、华东街道，合并设立玉丰街道。

撤销北苑街道、学苑街道和中苑街道，合并设立玉龙街道。

将西苑街道更名为玉新街道。

太平区

撤销高德街道、煤海街道，合并设立高德街道。

撤销孙家湾街道、城南街道，合并设立孙家湾街道。

新邱区

撤销兴隆街道、中兴街道，合并设立街基街道。

撤销新发街道、益民街道，合并设立新发屯街道。

清河门区

撤销清河街道、艾友街道，合并设立清河街道。

撤销新北街道、六台街道，合并设立新北街道。

辽阳市

文圣区

撤销新城街道，将其辖区整体划入东京陵街道。

将原东京陵街道的稠井子、尖山子、东京陵、东光村划入庆阳街道。

宏伟区

将长征街道、光华街道和新村街道鹏程园社区、火炬街社区合并，命名为长征街道。

将工农街道和新村街道的龙鼎山社区、龙鼎山庄社区合并，命名为工农街道。

弓长岭区

将安平街道和团山街道的安南社区合并，命名为安平街道。

将苏家街道和团山街道的八家子社区、陈家社区、石门社区合并，命名为苏家街道。

太子河区

将铁西街道、望水台街道合并，命名为铁西街道。

白塔区

将站前街道、星火街道、武圣街道、文圣街道、襄平街道合并，命名为文圣街道。

将跃进街道、卫国路街道合并，命名为武圣街道。

将新华街道、南门街道合并，命名为南门街道。

将胜利街道、东兴街道合并，命名为襄平街道。

盘锦市

大洼区

撤销荣滨街道、荣兴街道，将其整建制划归二界沟街道管辖。

兴隆台区

撤销锦采街道、平安街道，并入欢喜街道，欢喜街道更名为欢喜岭街道。

撤销茨采街道、高升街道，并入沈采街道。

撤销新生街道、友谊街道，并入曙光街道。

朝阳市

喀喇沁左翼蒙古族自治县

撤销南哨街道，并入利州街道。

双塔区

撤销南塔街道、北塔街道，合并设立双塔街道。

撤销燕都街道，并入燕北街道。

龙城区

撤销马山街道，并入新华街道。

撤销燕山街道，并入海龙街道。

撤销向阳街道，并入龙泉街道。

建平县

将新城街道、富山街道合并到红山街道。

将东城街道合并到万寿街道。

凌源市

撤销热水汤街道、兴源街道，并入红山街道。

撤销凌北街道，红山、莫胡店、鸿凌、鸿钢东、双圆东、双圆西、鸿远等社区划归东城街道；客车、八间房社区划归北街街道。

北票市

撤销桥北街道，并入城关街道。

撤销三宝街道，并入冠山街道。

撤销双河街道，并入台吉街道。

葫芦岛市

连山区

撤销化机街道，并入化工街道。

撤销水泥街道，并入站前街道。

撤销毛祁屯街道，并入杨家杖子街道。

龙港区

撤销望海寺街道办事处，并入葫芦岛街道办事处，办事处驻原望海寺街道办事处。东街道风采街东侧的东山社区、岭东社区、小仙沟社区及大世界社区、锌小社区、集贸社区的风采街以东部分划归葫芦岛街道办事处。 撤销东街道、西街道，设立马仗房街道，将西街店和东街道风采街西侧的大世界社区、锌小社区、集贸社区、阳光社区合并设立马仗房街道。马仗房街道办事处办公地点在西街道办事处。


南票区

撤销赵家屯街道，并入九龙街道办事处。注：邱皮沟街道已并入赵家屯街道。 撤销三家子街道，并入沙锅屯街道办事处。注：苇子沟街道已并入三家子街道。 撤销龙飞街道、龙翔街道，并入龙腾街道办事处。

兴城市

撤销城东街道，东关、城南、河畔社区，东一、东二、南辛庄、新号地等村划入宁远街道；月亮河社区，韩家沟村、干柴村划入古城街道。 撤销钓鱼台街道，并入四家屯街道。


--tanuki（留言） 2025年2月16日 (日) 02:47 (UTC)[回复]

@Yugaminena：是否有其他省市需要更新？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年2月28日 (五) 21:25 (UTC)[回复]
@Ericliu1912：是更新了辽宁省2019年以来的区划变动。tanuki（留言） 2025年3月10日 (一) 03:14 (UTC)[回复]

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

视觉化编辑器ilh系模板显示bug

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:可视化编辑器。

当外语连结没有空格时会显示成全黑字的“X语：link]]”而非正确带蓝字的“X语：link”，例见沙盒。连到英文之类还好，日文的话就几乎全都是这样了（见币舞桥底部的模板）。看了一下英维貌似不以绿链显示，日维有绿链但无法复现。--惣流·明日香·兰格雷不姓式波 2025年3月5日 (三) 11:08 (UTC)[回复]

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

有关失效连结

本主题或以下段落文字，在讨论结束后应存档至Category talk:带有失效链接的条目。

刚刚心血来潮看了一下Category:带有失效链接的条目，发现2025年2月和3月分别有50k和18k个条目于分类内，而其他月份一般不过100，多的也不过10k，请问这是正常现象吗？--惣流·明日香·兰格雷不姓式波 2025年3月9日 (日) 11:59 (UTC)[回复]

三月份才第9天就有1万8个条目被归类失效连结很明显不正常，有些条目在三月没有编辑却被归类在分类:自2025年3月带有失效链接的条目，例如2008年至2009年天水围飞马赛季、2001年12月阿根廷危机。--2402:7500:93E:31AE:456A:5C20:46FD:EE99（留言） 2025年3月9日 (日) 12:35 (UTC)[回复]
如果均速增加的话本月可能要破6万。看了一下阁下提的两个，天水围飞马分别是2017年12月、2018年2月、2023年3月标记了共30条dead link，阿根廷危机是2021年12月创建时、2023年10月标记了共3条dead link。--惣流·明日香·兰格雷不姓式波 2025年3月9日 (日) 13:03 (UTC)[回复]
补充：2008年至2009年天水围飞马赛季存于Category:自2017年12月带有失效链接的条目及Category:自2018年2月带有失效链接的条目，但不存于Category:自2023年3月带有失效链接的条目。
2001年12月阿根廷危机不存于Category:自2021年12月带有失效链接的条目及Category:自2023年10月带有失效链接的条目。--惣流·明日香·兰格雷不姓式波 2025年3月9日 (日) 13:32 (UTC)[回复]
2008年至2009年天水围飞马赛季不存在Category:自2023年3月带有失效链接的条目是正常的，因为2023年3月编辑并没有填写|data=参数，所以不会列入分类，2001年12月阿根廷危机也是同样情况。我比较疑惑的是，在以前如果没有填写|data=参数，其条目应该列入Category:带有失效链接的条目才对，不晓得是改过分类机制还是我记错。--2402:7500:93E:31AE:8563:9173:6E08:225E（留言） 2025年3月9日 (日) 14:34 (UTC)[回复]
我看源码时都觉得有点违和，原来是没填参数。那问题就变成：
  1. 为什么没填参数会列到本月（2025年3月），又为什么有些会列到2025年2月
  2. IABot从何时起，为何没有填参数
  3. 如何补回参数（顺道把Category:条目有永久失效的外部链接的5.9万条清理一下）（这分类是放fix-attempted=yes的，与此问题无关）2025年3月13日 (四) 08:34 (UTC)
--惣流·明日香·兰格雷不姓式波 2025年3月10日 (一) 01:47 (UTC)[回复]
{{dead link}}不带|date=参数就会归类到当前月，没有及时WP:更新服务器缓存的就是上个月--Kunjinkao（留言） 2025年3月13日 (四) 01:18 (UTC)[回复]
这么说这是“正常现象”？那IABot不填参数是本地设置还是什么问题，我看英维运行得挺正常的，这样下去这些分类就废了。--惣流·明日香·兰格雷不姓式波 2025年3月13日 (四) 08:51 (UTC)[回复]
其他分类（{{cn}}, {{update inline}}）没有这个问题，但{{dead link}}逻辑好像不太一样。另外英维有自动给维护模板加date参数的机器人--Kunjinkao（留言） 2025年3月13日 (四) 09:01 (UTC)[回复]
我们恐怕需要这种机器人。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年3月13日 (四) 12:19 (UTC)[回复]

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

{{lang}}、{{lang-xx}}相关更新善后

标题由优枰所加（86600176）。 ——自由雨日🌧️❄️ 2025年3月28日 (五) 07:49 (UTC)[回复]

本主题或以下段落文字，移动自Wikipedia:互助客栈/求助#模组更新后的善后。执行者：枰（留言） 2025年3月28日 (五) 07:34 (UTC)。[回复]

T:User lzh-3出错了（再看个“劲爆”的，御坂雪奈用户页……）。另外这里的{{lang|en}}模板莫名导致前后分段，不知道为什么……（副知@U:SuperGrey）。 ——自由雨日🌧️❄️ 2025年3月25日 (二) 11:49 (UTC)[回复]

按理说原来zht的写法应该是不对的，标准的写法应该使用zh-hant，严格来说这不是个错误。--Vozhuowhisper 2025年3月25日 (二) 13:06 (UTC)[回复]
建议撤回编辑。{{langx}}兼容性问题太多了，暂不适合正式发布。--SuperGrey (留言) 2025年3月26日 (三) 20:33 (UTC)[回复]

目前Category:Lang和lang-xx模板错误里有近两千页面，考虑到lang模板有几十万的使用量，这次应该没有很重大的问题，我看了几个都是斜体的问题，关于{{lang|en|''xxx''}}的改法我觉得改用外部标记''{{lang|en|xxx}}''比加italic参数要更简洁一些。--Vozhuowhisper 2025年3月25日 (二) 13:18 (UTC)[回复]

其实也有不少是原本错用斜体的，比如这里就是错用斜体，直接删去斜体就好了。 ——自由雨日🌧️❄️ 2025年3月25日 (二) 13:39 (UTC)[回复]
@Vozhuo：您看这条要怎么改？如果lang模板移动到rvw模板内，则lang模板彻底失效，所以只能放在外面。--SuperGrey (留言) 2025年3月27日 (四) 05:54 (UTC)[回复]
应该就是放在外面吧--Vozhuowhisper 2025年3月27日 (四) 06:59 (UTC)[回复]
@Vozhuo：但是现在出现了奇怪的前后换行，不知道要如何解决呢？--SuperGrey (留言) 2025年3月27日 (四) 07:05 (UTC)[回复]
我检查了一下，是rvw模板有语法让lang模板误以为里面有列表，所以就自动前后换行了，我稍微调整了一下rvw模板--Vozhuowhisper 2025年3月27日 (四) 09:03 (UTC)[回复]
原来如此，好神奇的bug。有点好笑 ……感谢修改！--SuperGrey (留言) 2025年3月27日 (四) 09:09 (UTC)[回复]

也有像是{{Engname}}这种里面引用{{lang}}模板的😓，详情见Wikipedia:互助客栈/技术 § Template:engname在条目中出现报错--竹林下小径，月光映一叶 2025年3月26日 (三) 07:50 (UTC)[回复]

(！)意见：这个“文本有斜体标记”的报错有必要在中文维基百科存在吗？英文维基百科似乎是因为要将拉丁字母拼写的非英文自动斜体才如此设计。如果斜体标记不会造成显示问题，那么直接去除这个报错更方便。——枰（留言） 2025年3月26日 (三) 10:45 (UTC)[回复]

考虑到中文维基默认没有斜体，可能这个确实不是很需要，而且影响的条目太多，一时半会也改不了。我在Module:Lang/sandbox中改了一个版本，使其在默认未设置italic参数时不检查是否有斜体，这样应该会移除绝大部分报错。--Vozhuowhisper 2025年3月26日 (三) 13:17 (UTC)[回复]
西文作品名和一些物种学名，习惯上还是使用斜体。--Kethyga（留言） 2025年3月29日 (六) 05:58 (UTC)[回复]
@AT：建议把Module:Lang及所有子模块的编辑权限临时开放给模板编辑员，这样我可以实时去测试，要不然这样太慢了。--Vozhuowhisper 2025年3月27日 (四) 04:45 (UTC)[回复]
支持，至少3万多个条目因为斜体报错，比起批量改条目，改模板也许更合适。--Kcx36（留言） 2025年3月26日 (三) 16:12 (UTC)[回复]
生物学名的可以批量替换成{{lang-xm}}模板，格式也比较固定（例[[学名]]：{{lang|la|''Astragalus lasiophyllus''}}替换成{{lang-xm|Astragalus lasiophyllus}}），未来继续修改格式也比较方便。--Kethyga（留言） 2025年3月27日 (四) 02:12 (UTC)[回复]
我先资询一下其他管理员。--AT⊿⁴⁶ 2025年3月27日 (四) 05:40 (UTC)[回复]
@Vozhuo已暂时开放lang和lang/data，由于子模块甚多，因此其他如果有需要的话请再跟我说，请编辑时务必谨慎处理，无法及时修正的话请即时回退。谢谢。--AT⊿⁴⁶ 2025年3月29日 (六) 04:47 (UTC)[回复]
@AT：被机器人改回去了 囧rz……--SunAfterRain 2025年4月1日 (二) 08:12 (UTC)[回复]
快来参选管理员吧lol--AT⊿⁴⁶ 2025年4月1日 (二) 11:35 (UTC)[回复]

大量中国地级行政区条目报错“语言标签：pinyin 无法识别”。--Kcx36（留言） 2025年3月26日 (三) 16:15 (UTC)[回复]

都用了{{lang|pinyin}}这样的写法，应该用zh-Latn-pinyin。我觉得可以作为别名。在可见的未来不可能有任何一个语言的代码是pinyin。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年3月27日 (四) 01:18 (UTC)[回复]
查到一个邮政式拼音也用pinyin的，有点无语。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年3月27日 (四) 01:19 (UTC)[回复]
其实标准的三字母应该是pny--Vozhuowhisper 2025年3月27日 (四) 05:15 (UTC)[回复]
pinyin报错的问题我已经在沙盒中解决了，我加了特殊处理。--Vozhuowhisper 2025年3月27日 (四) 05:45 (UTC)[回复]
广东省的条目中，用到了{{Infobox Chinese}}，在Wikipedia:沙盒中 (86586258)没报汉语拼音的错，在条目中提示“错误：{{Lang}}：非拉丁文本（pos 99: 嵌）/拉丁字母子标签不匹配”。--Kethyga（留言） 2025年3月27日 (四) 04:15 (UTC)[回复]
粤拼未支持yue-Latn-jyutping，暂时将{{Infobox Chinese/Chinese}}中的yue-Latn-jyutping改成了yue-Latn。--Kethyga（留言） 2025年3月27日 (四) 05:50 (UTC)[回复]
我在辣酱油中发现，{{标音/core}}也有类似的问题：错误：{{Lang}}：对于代码-字母对：yue-latn，变体：jyutping 无法识别（帮助）
已参照楼上方式修正，不过感觉遇到其他标音方式可能会再报一次错😅--竹林下小径，月光映一叶 2025年3月28日 (五) 03:41 (UTC)[回复]
目前jyutping的写法应该是yue-jyutping--Vozhuowhisper 2025年3月28日 (五) 04:01 (UTC)[回复]

错误追踪分类是否需要细化，或者加入排序参数？现在全部混一块不便于研判、难以维护。--Kcx36（留言） 2025年3月26日 (三) 16:16 (UTC)[回复]

(！)意见：#1，在弗拉基米尔·普京条目，鼠标放在罗马化转写文本上弹出“俄语”，此处此前应是“俄语罗马化”，英维中同样是“**-language romanization”。#2，在模板{{Lang-srp}}中，源码中手动设置的“<span title="塞尔维亚语（西里尔字母）">”未能显示，似乎是被{{lang}}覆盖了，应该允许DIY比较好。--Kethyga（留言） 2025年3月27日 (四) 02:05 (UTC)[回复]

我看到的就是“俄语罗马化”，点进去也是对应的条目。--Vozhuowhisper 2025年3月27日 (四) 06:35 (UTC)[回复]
@Vozhuo 将鼠标放在“Vladimir Vladimirovich Putin”上显示“俄语罗马化”，您那有截图吗？现在登录和未登录的情况下，罗马文文本均只提示“俄语”。另外{{langx|ru}}的罗马化默认的情况下缺少了内链。另外自定义提示的<span title="塞尔维亚语（西里尔字母）">也希望能看一下。--Kethyga（留言） 2025年4月30日 (三) 04:19 (UTC)[回复]
哦，那是我搞错了，这个已经改了。罗马化没有内链是因为俄语设置了link=no，这种设置取消了所有的内链，我也可以设置link只作用前面的语言内链，而不包括罗马化，但这样会导致罗马化的内链无法通过设置取消，我不清楚中文维基有没有这种取消罗马化内链的需求，如果没有也可以修改。另外，Lang无法自定义提示，默认会显示“塞尔维亚语西里尔字母文本”。--Vozhuowhisper 2025年4月30日 (三) 06:31 (UTC)[回复]
@Vozhuo 不少模板的自定义提示文字被默认覆盖，比如{{Vie}}，清晰的表示出使用的文字（汉字、喃字或拉丁字母/国语字）比单纯的“越南语文本”要好。上面的“塞尔维亚语西里尔字母文本”英维好像没有加入到语言module中。--Kethyga（留言） 2025年5月1日 (四) 01:00 (UTC)[回复]
默认是可以改的，在Module:Lang/data里面添加就行了。比如vi-Hani就没有定义，那它就不会显示喃字，而会显示越南语。--Vozhuowhisper 2025年5月1日 (四) 14:56 (UTC)[回复]

建议本话题移动至技术区。--Kcx36（留言） 2025年3月27日 (四) 11:15 (UTC)[回复]

@Kcx36：已移动。——枰（留言） 2025年3月28日 (五) 07:35 (UTC)[回复]
既然讨论串搬到VPT了，那我顺便请求一下管理员尽快处理Wikipedia:机器人/作业请求#请求修复lang模板外文斜体设定的问题与Wikipedia:机器人/作业请求#请求批量替换所有lang-xx模板为langx模板，尤其前者需要尽快处理。Sanmosa 新朝雅政 2025年3月29日 (六) 05:15 (UTC)[回复]
(？)疑问@Sanmosa：请问阁下提及的WP:翻译腔/城墙错误具体为何？本人没有找到其中出错，方括号在源代码中就是方括号。——枰（留言） 2025年3月29日 (六) 05:40 (UTC)[回复]
之前两处斜体标记显示为方括号，即源代码输入时为“''A Movie''”，显示效果为“[A Movie]”，但现在显示情况正常了。Sanmosa 新朝雅政 2025年3月29日 (六) 05:43 (UTC)[回复]
原来如此。我想那大概是斜体报错的后续处理，所以在默认未设置italic参数时不检查是否有斜体后斜体不报错就没有问题了。——枰（留言） 2025年3月29日 (六) 05:52 (UTC)[回复]
{{lang-xx}}系列中有一些是自定义模板，需要先确认是否有需要先排除掉的，比如{{lang-srp}}、{{lang-ug}}。英维保留了en:Template:Lang-sr-Cyrl及其他一些Lang-x模板。--Kethyga（留言） 2025年3月29日 (六) 05:45 (UTC)[回复]
@Kethyga：你提到的那些模板不在Category:使用Lang-xx模板的页面之内，因此不是处理的范围。Sanmosa 新朝雅政 2025年3月31日 (一) 01:43 (UTC)[回复]
@Sanmosa 英维有en:Category:Pages using Lang-xx templates，相关语言模板有{{Lang-sr-Cyrl}}、{{Lang-hbs-Cyrl}}……--Kethyga（留言） 2025年3月31日 (一) 11:37 (UTC)[回复]
这些自然也一同排除掉。不过这样看来我可能还需要另开一个排除清单。Sanmosa 新朝雅政 2025年3月31日 (一) 13:08 (UTC)[回复]
（更新）刚才开了一个Module:Lang/data的编辑请求，处理了以后你提到的那两个模板就可以正常替换为{{langx}}了。Sanmosa 新朝雅政 2025年4月1日 (二) 05:11 (UTC)[回复]
也许能实现想要的结果，可能不适合放入Module:Lang/data中。--Kethyga（留言） 2025年4月2日 (三) 05:47 (UTC)[回复]
Module:Lang/data有专门放置非标准代码的地方，因此没有什么不适合的，反正那个放置非标准代码的地方不是我弄出来的。Sanmosa 新朝雅政 2025年4月8日 (二) 14:07 (UTC)[回复]
在Category:使用Lang-xx模板的页面内但仍需要排除的模板暂时仅{{Lang-sq-definite}}一个，但我感觉这个模板存在的必要性是可以商讨的。Sanmosa 新朝雅政 2025年4月2日 (三) 03:59 (UTC)[回复]
更新：{{Lang-he-n}}应该可以删除，但删除前需要subst处理，而非简单替换“lang-”字根。Sanmosa 新朝雅政 2025年4月8日 (二) 14:06 (UTC)[回复]
@Vozhuo： 转至台湾维基社群脸书社团，Template:阿拉伯语显示“錯誤：{{Transl}}：轉寫文本非拉丁字母”，谢谢。--SCP-0000（留言） 2025年3月30日 (日) 07:30 (UTC)[回复]
已修复。--Vozhuowhisper 2025年3月30日 (日) 07:48 (UTC)[回复]
不好意思想查询一下，现时是否能正常使用{{lang|en}}格式，或是否有必要把{{lang-en}}换成{{lang|en}}？鉴于本人持续批量建立条目，希望能了解详情，及早对相关页面作出修改。--维基病夫❤️边缘人小组·签到 2025年3月30日 (日) 07:56 (UTC)[回复]
{{lang-en}}是未来要废除的，应该使用{{langx|en}}代替。{{lang|en}}并没有影响。--Vozhuowhisper 2025年3月30日 (日) 08:09 (UTC)[回复]
了解，感谢。--维基病夫❤️边缘人小组·签到 2025年3月30日 (日) 12:19 (UTC)[回复]
既然在改模块，能否帮忙看看Template talk:Lang-grc#为Lang-grc模板引入多调（polytonic）样式有无什么更加优雅的解决方案（） ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年3月31日 (一) 09:03 (UTC)[回复]
另外也请管理员处理一下Wikipedia:页面存废讨论/记录/2025/03/28#批量Module:Lang相关data提删--SunAfterRain 2025年4月1日 (二) 08:13 (UTC)[回复]
ㄎㄎ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月2日 (三) 16:02 (UTC)[回复]
Template:Infobox_Chinese/Chinese中{{lang|zh-Hant| {{{t}}} }}、{{lang|zh-Hans| {{{s}}} }}对阻断繁简转换的效果似乎失效。--— Gohan 2025年4月3日 (四) 10:08 (UTC)[回复]
已在沙盒中修复Lang模块并提交修改请求。--Vozhuowhisper 2025年4月3日 (四) 11:44 (UTC)[回复]
@Vozhuo：话说您有没有考虑选个界面管理员？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月4日 (五) 13:54 (UTC)[回复]
没兴趣。我之前也没编辑过css js这些。--Vozhuowhisper 2025年4月8日 (二) 14:41 (UTC)[回复]
@Vozhuo：哈萨克语的问题，该国的默认文字可能不再是西里尔/基里尔文，可能会改成拉丁字母。既然支持kk-Latn，kk-Cyrl不应该报错吧。还有像ru-Cyrl，不清楚为什么英维要禁用。--Kethyga（留言） 2025年4月12日 (六) 09:35 (UTC)[回复]
在模块的逻辑里，ru-Cyrl、kk-Cyrl均被视为冗余标签，你可以看Module:Lang/data/iana_suppressed_scripts，这里面记录了一些语言默认用什么字母，比如英语本来就用拉丁字母，俄语哈萨克语本来就用西里尔字母，如果非要写en-Latn、ru-Cyrl、kk-Cyrl就感觉有点奇怪，好像这样让人觉得和en、ru、kk代表的含义不一样，所以模块就不允许这样写。如果哈萨克语改用了拉丁字母，这个子模块就会更新，kk会放到["Latn"]那一行里，到时候kk-Cyrl就不会报错了，但是kk-Latn反而变成了冗余标签就会报错。--Vozhuowhisper 2025年4月12日 (六) 11:43 (UTC)[回复]
假如正式改用拉丁字母，以前用{{lang|kk|xx}}标记的、以西里尔/基里尔字母书写的内容就和拉丁内容不符。到时不免折腾一番。--Kethyga（留言） 2025年4月12日 (六) 12:20 (UTC)[回复]
在沙盒（86805971）中测试蒙古语（另一个可能改变文字系统的），在{{lang|mn-Cyrl|xx}}中输入任意的文字均不会检测字符是否属于西里尔/基里尔字母。 {{lang|rul|xx}}中混合输入西里尔字母、拉丁字母、汉字均不会检测超范围的文字符号。--Kethyga（留言） 2025年4月13日 (日) 02:01 (UTC)[回复]
模块只有对具有后缀标签的代码（不包括ru这种没后缀的）检测拉丁字母的功能，比如mn-Cyrl包含拉丁字母，又或者mn-Latn包含非拉丁字母，除此之外都不会检查。--Vozhuowhisper 2025年4月13日 (日) 10:21 (UTC)[回复]
英维中pt-br明确显示为巴西葡萄牙语，中维建议同步，巴西和欧洲葡萄牙语有一定差异。好像巴西葡语现在是葡语的主流？--Kethyga（留言） 2025年4月14日 (一) 08:22 (UTC)[回复]
已经更新在沙盒里了，要等管理员更新。--Vozhuowhisper 2025年4月17日 (四) 13:47 (UTC)[回复]
英维中区分了en-gb（英式英语）和en-us（美式英语），本地目前未区分二者。--Kethyga（留言） 2025年4月25日 (五) 12:34 (UTC)[回复]
这是个bug，已提交修复。--Vozhuowhisper 2025年4月30日 (三) 07:03 (UTC)[回复]
在纵书与横书中需要使用{{lang|zh-hant|，}}等单个标点符号的情况，此时 text_script_match_test 会报[，] 错误：{{Lang}}：指定的书写系统标签非拉丁字母，但文本为拉丁字母。（帮助）--内์์์์์์์存๎๎๎๎溢出์์์์์์์的๎๎๎๎猫瞄?喵! 2025年4月21日 (一) 01:37 (UTC)[回复]
模组讨论:Lang/data/is latn data#编辑请求2025-04-22去掉了一些内容，能修，但是这种做法不太好，最好修改或去除这个拉丁字母检测功能。——枰（留言） 2025年4月22日 (二) 05:34 (UTC)[回复]
@优枰：更新之后会导致新的问题，例如2030年亚洲运动会，里面的转写因为有个‘会报错。我觉得像{{lang|zh-hant|，}}这种用法有点问题，因为lang模板是为了标明某种语言的文本，而标点符号不是专属于某个语言的，这样用有些不妥。--Vozhuowhisper 2025年5月3日 (六) 16:42 (UTC)[回复]
没注意到这个问题，抱歉，我在编辑请求那里请求恢复了，然后新建了{{lang old}}临时用在此条目。关于{{lang|zh-hant|，}}，我觉得现有用法有些道理，毕竟浏览器可以借此以不同方式显示标点符号。然后这个问题，最好的方法可能是拆开Latn和Zyyy，也许应该回报到英文维基百科。——枰（留言） 2025年5月3日 (六) 19:50 (UTC)[回复]
模板{{Vi-nom}}也有类似问题。--Kethyga（留言） 2025年4月24日 (四) 11:29 (UTC)[回复]
英维直接使用<span lang="vi-Hani" class="vi-nom" {{{attr|}}}>{{{1}}}</span>进行标记。--Kethyga（留言） 2025年4月24日 (四) 11:32 (UTC)[回复]
ToolsRedirect的辅助选项“ToolsRedirect选项：取得生物学学名为重新导向候选”疑似因为这个更新失效了，我刚刚新建页面发现他完全抓不到lang-xm下的学名（更新之前我常用这功能，当时只要有学名：{{Sname}}时是可以运作的）。--WiTo🐤💬 2025年4月23日 (三) 06:16 (UTC)[回复]
@WiTo7946 似乎因为html源码中多了<span lang="la"--Kethyga（留言） 2025年4月29日 (二) 09:02 (UTC)[回复]
Module talk:Lang/data#编辑请求 2025-04-27需要管理员尽快处理。Sanmosa 新朝雅政 2025年4月27日 (日) 02:14 (UTC)[回复]
巴勒斯坦解放组织首句：“Lang-xx：拉丁字母转写第 99 个字元“嵌”不是拉丁字母。”，但直接把该lang-ar呼叫过来这里又正常了的样子。“阿拉伯语：منظمة التحرير الفلسطينية，罗马化：Munaẓẓamat at-Taḥrīr al-Filasṭīniyyahⓘ”--WiTo🐤💬 2025年5月5日 (一) 10:22 (UTC)[回复]
错误提示应该是{{Audio}}模板有关，lang模板估计只检测主命名空间（条目空间），在个人沙盒测试也未报错。--Kethyga（留言） 2025年5月5日 (一) 10:55 (UTC)[回复]
若直接展开看起来就没问题了，如果是Audio的问题的话，那可能是lang抓到Audio模板内的{{#ifeq:{{NAMESPACE}}|{{ns:0}}|[[Category:嵌入hAudio微格式的條目]]}}了。--WiTo🐤💬 2025年5月6日 (二) 05:18 (UTC)[回复]

使用“zhuyin”作语音标签的大量条目报错

例如《二十八宿》，显示错误：{{Lang}}：语言标签：zhuyin 无法识别。注音符号应该是什么语言标签？ ——自由雨日🌧️❄️ 2025年4月15日 (二) 06:19 (UTC)[回复]

（由@Cynroya发现的问题。） ——自由雨日🌧️❄️ 2025年4月15日 (二) 06:19 (UTC)[回复]
应改为zh-Bopo。--伞木 霙留言 2025年4月15日 (二) 06:39 (UTC)[回复]
是否考虑直接在模板内增加相容参数？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月21日 (一) 11:13 (UTC)[回复]
同上，同pinyin-->zh-Latn-pinyin的做法，也应该把zhuyin设置为zh-Bopo的别名。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年4月25日 (五) 13:24 (UTC)[回复]
@自由雨日、魔琴：不过应修改什么模板呢？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月5日 (一) 15:50 (UTC)[回复]
@Vozhuo。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月5日 (一) 22:50 (UTC)[回复]

通过CSS隐藏信息框旗帜是否可行

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

近期通过的MOS:信息框旗帜规定信息框一般不应使用旗帜图标，考虑到对现有条目逐一修改费时费力（即使是由机器人进行），能否通过CSS隐藏旗帜？具体而言，例如由{{Infobox person}}引入.infobox.biography.vcard .flagicon {display: none;}以隐藏旗帜图标，可使用Template:Infobox_person/sandbox测试效果。本人对CSS不太熟悉，仅提出一点粗浅的建议，请各位指正。--Kcx36（留言） 2025年4月15日 (二) 08:04 (UTC)[回复]

我不认为信息框不该放旗帜--熊猫火狗（留言） 2025年4月20日 (日) 15:05 (UTC)[回复]
请另外提出讨论。--Kcx36（留言） 2025年4月20日 (日) 15:07 (UTC)[回复]
掩耳盗铃过于激进，且不利编者日后排查清理。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月21日 (一) 11:13 (UTC)[回复]
可以小工具形式对未注册用户启用，注册用户可以关闭。但是鉴于此类旗帜日后必然清理，掩耳盗铃确实没有意义。--PexEric 2025年4月24日 (四) 05:30 (UTC)[回复]
我(－)强烈反对隐藏旗帜。估计还没等清理这类条目，这规定就被废除了……--31.40.205.42（留言） 2025年5月3日 (六) 14:07 (UTC)[回复]
呵呵。如果你反对MOS:信息框旗帜，你倒应该支持通过CSS隐藏旗帜，因为如果规定日后被废除，改一下模板就能恢复条目中的旗帜，如果是逐个条目清理，想恢复就麻烦了。--Kcx36（留言） 2025年5月3日 (六) 14:14 (UTC) 👏1[回复]

视觉化编辑器加入T:NoteTag bug

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:可视化编辑器。

如题，NoteTag的上下会被加入各两新行，在发布编辑前，不切到源码编辑貌似是拿不走新行。（最终效果见special:diff/86885440）--惣流·明日香·兰格雷不姓式波 2025年4月18日 (五) 13:16 (UTC)[回复]

建议用{{efn}}和{{notelist}}。--SuperGrey (留言) 2025年4月20日 (日) 14:41 (UTC)[回复]
兴奋地试了一下，遗憾的是，除了refnest，全部都有同样问题 囧rz……--惣流·明日香·兰格雷不姓式波 2025年4月21日 (一) 04:31 (UTC)[回复]
这个缺陷目前是修不好还是怎么说？不能回退吗？--【拒绝编辑霸凌，拒绝拉扯性讨论，谢绝拉票，谢绝提名，谢绝豢养人肉傀儡】（有建议可以留言） 2025年5月4日 (日) 16:40 (UTC)[回复]
目前这个缺陷是无法明确哪一笔修改导致的吗？--【拒绝编辑霸凌，拒绝拉扯性讨论，谢绝拉票，谢绝提名，谢绝豢养人肉傀儡】（有建议可以留言） 2025年5月7日 (三) 00:39 (UTC)[回复]
本地搞排除异己的时候三人两人就能成虎、众口两口就能铄金，修个技术缺陷的时候就拖泥带水、没有这个积极性了。--【拒绝编辑霸凌，拒绝拉扯性讨论，谢绝拉票，谢绝提名，谢绝豢养人肉傀儡】（有建议可以留言） 2025年5月7日 (三) 00:43 (UTC)[回复]
目前还有概率性的问题，预览的时候100%上下会被各加一行，提交编辑后概率不会有上下各加一行。--【拒绝编辑霸凌，拒绝拉扯性讨论，谢绝拉票，谢绝提名，谢绝豢养人肉傀儡】（有建议可以留言） 2025年5月7日 (三) 00:50 (UTC)[回复]

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

为什么Twinkle的关闭存废讨论功能不支持Vector 2022皮肤？什么时候才能支持？

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

完成：
经检查，Vector 2022界面已能正常运行Twinkle关闭AFD的功能，故该功能已重新在Vector 2022界面启用。Sanmosa 新朝雅政 2025年4月30日 (三) 01:49 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

--熊猫火狗（留言） 2025年4月20日 (日) 13:56 (UTC)[回复]

不知道呢，嗯。--SunAfterRain 2025年4月21日 (一) 05:11 (UTC)[回复]

@SunAfterRain：关闭使用者提问也不是这样随便的吧？还是说你知道Twinkle内部的维护细节？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月21日 (一) 11:11 (UTC)[回复]
@Ericliu1912：[3]，理由是Vector-2022的HTML源代码一直变来变去造成维护困难所以暂时不支援（顺带一提，东八区的下午我有在AC群贴过这段话）
另外我认为既然这位都没有要好好认真提问了，那很随便关闭也是理所当然的--SunAfterRain 2025年4月21日 (一) 13:46 (UTC)[回复]
意思就是Vector 2022现在还不是稳定版？--熊猫火狗（留言） 2025年4月21日 (一) 13:56 (UTC)[回复]
@Ericliu1912、SunAfterRain：（其实我也有一个相关的问题要问，所以这样直接关掉讨论串确实不太妥当）我觉得我就顺便问这个问题吧：有没有办法可以在Vector 2022界面下强制运行Twinkle关闭AFD的功能？就算可能有bug我也不介意，但现在关AFD就要不断来回切换界面对我来说比较麻烦。Sanmosa 新朝雅政 2025年4月28日 (一) 11:44 (UTC) +11[回复]
你问错人了，你应该问@Xiplus、Hamish--SunAfterRain 2025年4月28日 (一) 12:07 (UTC)[回复]
我不懂技术，别问我XD —— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月28日 (一) 12:19 (UTC)[回复]
目前Twinkle的关闭AFD功能部分暂时还没有加入vector2022的适配，强制运行现有的代码也没有办法实现，“关闭讨论”的程式入口都不会显示。--Hamish T 2025年4月28日 (一) 19:04 (UTC)[回复]
@Hamish：“‘关闭讨论’的程式入口都不会显示”是指无法显示按钮吗？但我是能看到按钮的。Sanmosa 新朝雅政 2025年4月29日 (二) 00:55 (UTC)[回复]
我是指，关闭讨论点开以后，程序入口是不会显示任何东西的，只会提示用不了，我可能稍后测试一下当前的2022外观直接运行现有的代码会不会出大问题，没有大问题的话，会考虑加入一个option打开vector2022上这个功能。--Hamish T 2025年4月29日 (二) 01:26 (UTC)[回复]
“关闭讨论点开以后，程序入口是不会显示任何东西的，只会提示用不了”确实如此。如果能开这个option的话就再好不过了，我记得一开始Vector 2022界面下还能运行Twinkle关闭AFD的功能的时候，这功能基本上都是在正常运作的（至少就我自己而言）。Sanmosa 新朝雅政 2025年4月29日 (二) 01:53 (UTC)[回复]
刚去翻了一下Twinkle和Vector2022的代码提交记录，当时2022的HTML标签有问题，这个问题会导致twinkle根本无法正常显示“关闭讨论”按钮，也无法正常关闭讨论，但现在看应该是修复了，吧。等待技术帝意见。--Hamish T 2025年4月29日 (二) 02:19 (UTC)[回复]
@SunAfterRain和@Hamish说的是对的，已重新在vector-2022上启用。--Xiplus#Talk 2025年4月29日 (二) 11:34 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

Special:链入页面与Wikipedia:合并请求

应该是因为使用Template:Querylink的关系，被提合并请求的条目的链入页面并不包含合并请求页，且未被执行的合并请求不如Wikipedia:存废复核般会在讨论页留下讨论的连结，导致编者无法简易查看过往的合并讨论。--惣流·明日香·兰格雷不姓式波 2025年4月23日 (三) 04:20 (UTC)[回复]

@Sohryu Asuka Langley Not Shikinami，合并讨论需要在被合并的条目中的讨论页讨论，合并请求只是一个媒介提供不知道怎么合并或是不确定怎么合并提交的地方。-- Willy1018（留言） 2025年4月28日 (一) 18:10 (UTC)[回复]
但显然WP:合并请求中亦有讨论，或至少对于“未被执行的合并请求”会有不执行的原因，现时情况是一存档就很难快速找到（需人手搜索，前提是知道曾提至WP:合并请求）。--惣流·明日香·兰格雷不姓式波 2025年4月29日 (二) 01:12 (UTC)[回复]

{{Infobox road}}相关追踪分类建立

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

Infobox road近期似乎在施工，引入了一批新的追踪分类，但没有建立分类页面导致界面上不显示为隐藏分类。其他的没几个，主要是“使用Infobox road的xx道路”，人力穷举显然有困难，要不然开个机器人？

附：追踪分类列表

Nanhuajiaren（留言） 2025年4月25日 (五) 12:40 (UTC

不是很理解意思，如果您是指一个条目已经被分到某个分类，但是这个条目底部没有显示的话，是不对的，因为分到了分类，就算没有建立分类页面，页面底下也会有红色的分类连结。--Hamish T 2025年4月29日 (二) 00:35 (UTC)[回复]
@Hamish：他说的是“没有建立分类页面，导致界面上不显示为隐藏分类”，也就是当成一般分类那样来显示，他希望做到的是在不开启检视隐藏分类的功能的情况下看不到那个分类。Sanmosa 新朝雅政 2025年4月29日 (二) 00:57 (UTC)[回复]
以上有列出来的分类我基本都建了，剩下的就看看特殊页面逐一建立吧。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月5日 (一) 15:58 (UTC)[回复]

2条仅为繁简差异重定向的负面问题及解决方案（“废除这类重定向？使用机器人维护该负面问题？”二选一）

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:重定向、Wikipedia talk:繁简处理。

原标题：繁简重定向的负面问题及解决方案（“废除繁简重定向？使用机器人维护该负面问题？”二选一）。修改理由：改变讨论主题焦点。修改者：自由雨日🌧️❄️ 2025年4月28日 (一) 05:05 (UTC)[回复]

原标题：有关对仅存在简繁差异的重定向是否应该同时存在或是否应当监视变动的讨论。修改理由：清晰表述；经原作者同意后修改。修改者：自由雨日🌧️❄️ 2025年4月25日 (五) 19:20 (UTC)[回复]

原标题：有关对某一个页面的简繁重定向（不含该页面本身）是否应该同时存在或是否应当监视变动的讨论。修改者：--此条未签名留言由Iming（讨论｜贡献）于2025年4月25日 (五) 13:33 (UTC)加入。[回复]
请至下方讨论：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
例子在Special:Diff/86988917中有修改，改于2025年4月25日 (五) 13:30 (UTC)。

前几个月注意到一次在站外Telegram AC群的讨论，发现存在A -> C，B -> C（A、B仅有繁简区别），A修改后B没有修改，而导致仅存在繁简区别的两个重定向指向不同页面，因而当时考虑设置一个机器人来自动化处理此问题。有用户认为，因为目前软件、内链等不需要同时简体繁体标题都存在就可以工作，应当删除A或B其中一个而不是继续保留。我个人认为，因为有一些脚本可以创建此类重定向（且不会提示已存在另外一个仅有繁简差异的重定向），也存在被恶意创建的可能性，因此应当保留此类重定向并由机器人进行监控。应机器人审核小组成员建议，在此开启议题，以便社群检视。

谢谢。Iming 彼女の爱は、甘くて痛い。 2025年4月25日 (五) 13:05 (UTC)[回复]

邀请@魔琴、@0xDeadbeef两位参与讨论。--Iming 彼女の爱は、甘くて痛い。 2025年4月25日 (五) 13:08 (UTC)[回复]
and @自由雨日（（（ Iming 彼女の爱は、甘くて痛い。 2025年4月25日 (五) 13:24 (UTC)[回复]
(＋)支持--Aqurs 2025年4月25日 (五) 13:14 (UTC)[回复]
(＋)支持。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年4月25日 (五) 13:25 (UTC)[回复]
@Iming：咦，这个例子不还是我半年前说的问题吗？你举的例子属于“修复双重重定向”，早已有机器人在维护了；@魔琴和我说的是“A因B的重定向变化而没有跟B同步”的问题。 ——自由雨日🌧️❄️ 2025年4月25日 (五) 13:28 (UTC)[回复]
我的问题，例子举错了，不过机器人等设计的都是正确的。感谢提醒。--Iming 彼女の爱は、甘くて痛い。 2025年4月25日 (五) 13:32 (UTC)[回复]
cc @Aqurs1和@魔琴两位。Iming 彼女の爱は、甘くて痛い。 2025年4月25日 (五) 13:50 (UTC)[回复]
了解。因为这个东西似乎就是我最初提议的，所以我明白Iming的意思。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年4月25日 (五) 18:30 (UTC)[回复]
见下，通知的不是那个（） ——自由雨日🌧️❄️ 2025年4月25日 (五) 19:22 (UTC)[回复]
经站外私聊帮助@Iming传达：上方通知两位（并非主要是通知对我留言的回应，而主要）是由于标题发生了变化——即Iming讨论的本意是希望让在话题下讨论的编者选择“废除繁简重定向”和“使用机器人”方案之一，故两位的“支持”可能得改成具体的“支持某一方案”（） ——自由雨日🌧️❄️ 2025年4月25日 (五) 14:04 (UTC)[回复]
繁简重定向属常年提案，如果本讨论真是讨论在两方案取其一的话，恐怕不得不开始ping之前的编者大规模讨论了。 ——自由雨日🌧️❄️ 2025年4月25日 (五) 14:05 (UTC)[回复]
通知先前讨论过繁简重定向去留问题的（不完全名单）@Yangfl、Cdip150、Cwek、Antigng、PhiLiP、Jasonzhuocn、Bluedeck、Temp3600、淺藍雪、RabbitMeow、RekishiEJ、Jane9306、Michael Chan、Spaghet-Ti、SzMithrandir、M940504、Sanmosa、Mongolian Beef、白布飘扬、EtaoinWu、Hotaru Natsumi、Tomchen1989、Wcam、Chiefwei、Hat600、FRDian、乌拉跨氪、Liangent、Byfserag、DeBit、Wangxuan8331800、GZWDer、SElephant、Shizhao、脳内補完、燃玉、HYH.124、Bnb674、Chmarkine、Byfserag、小躍、日期20220626： ——自由雨日🌧️❄️ 2025年4月25日 (五) 19:20 (UTC)[回复]
我支持“废除繁简重定向”。繁简重新导向的保留理据不足，虽然视觉化编辑器等bug迟迟无人修，但在繁简重新导向在阅读界面并无显示问题，保留重新导向徒增维护压力，并无必要。只需一键删除即可。自动加此类重新导向的小工具本该是罪魁祸首，不应该反而迁就，成为保留此类重新导向的理据。--SuperGrey (留言) 2025年4月25日 (五) 20:42 (UTC)[回复]
繁简重新导向还有另外一大问题：条目更名的时候，需要手动检查并修复旧名的另一/几个变体。即使有机器人自动修复，移动者也有检查的义务，此“旧名+繁简重新导向”是否有存在的必要？有无必须存在的理据？--SuperGrey (留言) 2025年4月26日 (六) 04:22 (UTC)[回复]
这就是“修复双重重定向”，这倒是倒很方便？我一般用小工具几秒钟就能完成；即便不去动它，不出几小时机器人也都会修复。 ——自由雨日🌧️❄️ 2025年4月26日 (六) 04:24 (UTC)[回复]
但有必要徒增烦恼吗？用小工具再方便，不如不建立，更方便，效率提升100%。--SuperGrey (留言) 2025年4月26日 (六) 04:26 (UTC)[回复]
(－)反对,简繁重定向的存在，主要是有时出现转换系统失效时，未建立的页面会直接红链，而不会导向简繁版本，于是这种情况出现时，就会临时建立简繁重定向，并保留下来。另一个是生僻字的转换问题，目前依然有很多生僻字或新的Unicode字符没列入简繁自动转换系统，比如鿳、鿸、志、𰵧、𤦎，𮴅，都需要手动更新，今年又会有中日韩统一表意文字扩展区J启用，预计这种情况会长期存在，所以我觉得简繁重定向应有需要继续存在。--白布飘扬（留言） 2025年4月25日 (五) 23:10 (UTC)[回复]
还有一些简繁多对多的问题，比如“蘋、𬞟、萍、苹”、“乾、幹、榦、干”、“勳、勛、勋”很容易出现过度转换，所以有时必须用简繁重定向来纠正。——白布飘扬（留言） 2025年4月25日 (五) 23:39 (UTC)[回复]
可否举个例子，哪个条目因为“过度转换”而必须用简繁重新导向来纠正？--SuperGrey (留言) 2025年4月26日 (六) 04:13 (UTC)[回复]
而且多对多的条目“如果真的存在”，给这几个建立重新导向即可，必须扩大到非多对多的情况吗？--SuperGrey (留言) 2025年4月26日 (六) 04:28 (UTC)[回复]
另外一个理由是重复页面的问题，当简或繁重定向缺失时，新手或机器人容易建立重复的简繁页面，所以简繁重定向可以减少这些问题。至于链接更新问题，维基编者在更换重定向时，应养成检查简繁页面的习惯。——白布飘扬（留言）--白布飘扬（留言） 2025年4月26日 (六) 00:09 (UTC)[回复]
机器人容易建立，但只要系统能正常跳转，新手并不容易建立。机器人作者写出错误的程式逻辑应自己负责，此理据不成立。--SuperGrey (留言) 2025年4月26日 (六) 04:15 (UTC)[回复]
对生僻字和未收录字建立简繁重新导向就好了，不必扩大化到常用字。“转换系统失效”的时候，最近几年有发生过吗？--SuperGrey (留言) 2025年4月26日 (六) 04:18 (UTC)[回复]
此外繁简重定向仅在中文维基百科有效，链接到维基百科的网址可能会因为删除繁简重定向而404。不少工具不支持繁简通搜，比如intitle:"历年"。可以用机器人或数据库保证繁简指向同一页面。同一上面提及的机器人维护方案。--Kethyga（留言） 2025年4月26日 (六) 03:52 (UTC)[回复]
能否举个404的例子？哪个网址会404？--SuperGrey (留言) 2025年4月26日 (六) 04:16 (UTC)[回复]
以雅羅斯拉夫·莫斯卡利克为例，将其保存到Wayback Machine（网址），如果把网址中最后标题改成简体的雅罗斯拉夫·莫斯卡利克就失效。--Kethyga（留言） 2025年4月26日 (六) 05:51 (UTC)[回复]
这是肯定的。因为Wayback Machine并不是这样用的，不应用于存档重新导向。而且，本来拿Wayback Machine存档维基百科也是挺奇怪的做法。您如果需要存档将被删除的条目，还是去蓝灯图书馆吧。--SuperGrey (留言) 2025年4月26日 (六) 06:15 (UTC)[回复]
(－)反对废除繁简重定向、支持机器人或数据库报告监控，理由同白布飘扬及Kethyga。--回廊彼端（留言） 2025年4月26日 (六) 04:05 (UTC)[回复]
(：)回应,我建立页面User:白布飘扬/沙盒/1/幹的话，相应的页面不会自动链接（乾、幹、榦、干）；
我建立页面User:白布飘扬/沙盒/1/干干的话，则部分繁体字都会链接(:乾乾、幹幹、榦榦、干干）--白布飘扬（留言） 2025年4月26日 (六) 05:08 (UTC)[回复]
在这种情况下，尤其用在人名时，都需要特别处理，来避免错误导向，这会是一个常见的问题，所以现有方针应明确保留。——白布飘扬（留言） 2025年4月26日 (六) 05:08 (UTC)[回复]
赞同。这部分重新导向应该保留。--SuperGrey (留言) 2025年4月26日 (六) 05:13 (UTC)[回复]
(－)反对废除繁简重定向，同白布飘扬阁下。另在去年八月时，我有提出过相关的繁简疑问，但受限于各装置支援字体的不同，有可能有些简化字输入/显示不出来。在本站诸如“栗苇𫛚、栗苇鳽”此类的转换问题解决之前，不该贸然处理掉繁简重定向（何况这举例仅仅是中日韩统一表意文字扩展区C的字，甚至也不用到今年的J）。用机器人产生报告再修改的方式则可以考虑。--WiTo🐤💬 2025年4月26日 (六) 07:09 (UTC)[回复]
如果是利用机器人直接自动维护，其他编者可以根据机器人贡献日志检查呢？--Iming 彼女の爱は、甘くて痛い。 2025年4月26日 (六) 07:24 (UTC)[回复]
如果最终能做到几乎无误那是可以，我个人不希望要帮机器人善后太多东西。--WiTo🐤💬 2025年4月26日 (六) 10:52 (UTC)[回复]
我没什么太大的想法，机器人来做的话错误率应该不会太高？没试验过不太了解。或许可以先这样做（指由机器人自动维护）一段时间，如果错误率比较高的话就改为仅报告这样？--Iming 彼女の爱は、甘くて痛い。 2025年4月26日 (六) 13:05 (UTC)[回复]
近期看一些本站过往的机器人运转纪录，感觉有一些我想不到的部分还是有可能会出错，最好还是小范围起测试，免得直接出现天坑。--WiTo🐤💬 2025年4月26日 (六) 14:02 (UTC)[回复]
(＋)支持让机器人找出目标不一致的简繁连接再修正是好办法。——白布飘扬（留言） 2025年4月26日 (六) 10:35 (UTC)[回复]
修正，反对废除繁简重定向，支持使用机器人维护。Aqurs 2025年4月27日 (日) 02:46 (UTC)[回复]
打算建立多少新繁简重新导向呢？几十万条？--SuperGrey (留言) 2025年4月27日 (日) 04:43 (UTC)[回复]
见上，经脚本整理统计出共有75821例此类情况。至少大规模建立相关页面暂时未见有明显负面效果。--Aqurs 2025年4月27日 (日) 12:48 (UTC)[回复]
75821例都是“简体→繁体”。“繁体→简体”呢？需要多少条重新导向？--SuperGrey (留言) 2025年4月27日 (日) 13:04 (UTC)[回复]
后者确实是未知数，但暂且先用机器人维护有什么负面效果吗？--Aqurs 2025年4月27日 (日) 13:54 (UTC)[回复]
据@Sohryu Asuka Langley Not Shikinami的说法，75821例只是“情况3”。想必您说的“大规模建立相关页面”远远不止7万例吧？要是建立了几十万、上百万条简繁重新导向（维基百科里面现在主名字空间的页面数远不止这个数），以后就变成新的技术债了，故并非“暂时未见有明显负面效果”就没事，而是要充分讨论、凝聚共识之后再去建。--SuperGrey (留言) 2025年4月27日 (日) 14:00 (UTC)[回复]
@SuperGrey：似乎建立重定向属于跑题了，这边讨论串说的是修复现有有问题/有可能会有问题的重定向，不会建立。我是不反对“大规模建立”但这边不是讨论这个东西。--Aqurs 2025年4月27日 (日) 15:38 (UTC)[回复]
“跑题”但题目写的就是“废除重新导向”和“机器人维护重新导向”。看来还是题目和提案有点偏差。建议底下再开一个章节，重新厘清提案内容。--SuperGrey (留言) 2025年4月27日 (日) 23:30 (UTC)[回复]
“使用机器人维护该负面问题”是怎么被您理解成“建立重定向”的……？？ ——自由雨日🌧️❄️ 2025年4月28日 (一) 03:24 (UTC)[回复]
这是在讨论这里的情况3对吧？阁下的7万多例应该是包含1、2、3的情况？我当时提的时候就想过废除繁简重定向，但看了一下过往讨论感觉不会成事。--惣流·明日香·兰格雷不姓式波 2025年4月27日 (日) 12:41 (UTC)[回复]
上述例子是两者均为重定向，标题仅有简繁差异，没有考虑两个重定向的最终目标为何。给这个例子是为了表明存在如此多的页面需要机器人监视是否存在“仅有简繁差异的两个重定向里，其中一个被修改，而另外一个未被修改，导致仅存在繁简区别的两个重定向指向不同页面”。Iming 彼女の爱は、甘くて痛い。 2025年4月27日 (日) 13:28 (UTC)[回复]
如果只对已有的简繁重新导向使用机器人辅助维护，我是没有意见的，(＋)支持。但是此次提案大有推广简繁重新导向、建立几十万条新简繁重新导向的迹象，让人担心。不知参与讨论的大家都真心希望建立这么多条新重新导向吗？真的不是增加维护的烦恼？--SuperGrey (留言) 2025年4月27日 (日) 13:33 (UTC)[回复]
我刚才再读了一遍提案，可能确实是我写的有问题。我的意思是，对现在存在的所有此类重定向和在未来由其他编者自行建立的此类重定向，是否应当删除，或保留并由机器人监控维护。本提案无意推广简繁重定向或新增简繁重定向，机器人只会关注已经存在的简繁重定向。--Iming 彼女の爱は、甘くて痛い。 2025年4月27日 (日) 15:24 (UTC)[回复]
我又看了一遍，其实讨论的根本不是“繁简重定向”，而是“两个仅为简繁差异的重定向”，标题该再改改了。另外，我刚刚想到一个应该禁止的“两个仅为简繁差异的重定向”情况，就是当其中一个有连至wikidata项目时；此时应确保项目所连的是两个页面中较早建的那个（先到先得原则），后来那个就删掉加白纸保护。--惣流·明日香·兰格雷不姓式波 2025年4月27日 (日) 16:09 (UTC)[回复]
@Sohryu Asuka Langley Not Shikinami：我知道“两个仅为简繁差异的重定向”不是严格意义上的繁简重定向，但实务上常会视作繁简重定向，作用也类似。而且如果社群认为处理方式是禁止“两个仅为简繁差异的重定向”存在的话，我想社群也不会认为“繁简重定向”有必要存在，尤其是只要主页面一移动（保留重定向），原先的繁简重定向就会成为“两个仅为简繁差异的重定向”。 ——自由雨日🌧️❄️ 2025年4月27日 (日) 16:32 (UTC)[回复]
不清楚阁下的私聊讨论了什么，但我认为“废除繁简重定向”与“处理两个仅为简繁差异但目标不同的重定向”有很大分别。本来是处理小问题a，然后转为讨论“背后的”大问题A，那如果A的讨论没共识，a怎么办？先关注好a，A应另外讨论。如阁下所知，“废除繁简重定向”是常年提案，某程度上显示“常年不处理”也没有大问题；但“两个仅为简繁差异但目标不同的重定向”显然是值得更积极处理的。--惣流·明日香·兰格雷不姓式波 2025年4月28日 (一) 01:34 (UTC)[回复]
见下方留言；另外你比较一下“反对废除繁简重定向”的那些理由（即“繁简重定向”的作用），同样也是反对废除“两个仅为简繁差异的重定向”的理由，换句话说上面的讨论同时就是在讨论“两个仅为简繁差异的重定向”。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 01:42 (UTC)[回复]
无语了。能不能不要随意扩大化解释？我们还是认真讨论“因移动导致的2条仅为简繁差异的重新导向”吧。--SuperGrey (留言) 2025年4月28日 (一) 01:45 (UTC)[回复]
并不是我在扩大化解释。你后一句更是错了，“因移动导致的2条仅为简繁差异的重新导向”是“修复双重重定向”，早已有机器人在维护了……不是本讨论的主题。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 01:47 (UTC)[回复]
……那本讨论的主题是什么？能一次性说清楚吗？--SuperGrey (留言) 2025年4月28日 (一) 01:51 (UTC)[回复]
还是说刚刚您说的“换句话说上面的讨论同时就是在讨论“两个仅为简繁差异的重定向””并非指“因移动导致的2条仅为简繁差异的重新导向”？那么，您指的是什么？--SuperGrey (留言) 2025年4月28日 (一) 01:52 (UTC)[回复]
@SuperGrey：需要解决的问题是如何处理“2条仅为简繁差异的重定向”。但这些重定向建立的原因多不是因为移动，而是和{{繁简重定向}}作用一样的解决系统无法转换的问题（如生僻字）、消除红字链接的问题等等如果是因为移动，由于机器人会修复双重重定向，反而几乎不可能有“指向页面不一致”的问题，且之前提删“2条仅为简繁差异的重定向”的理由也多为和废除繁简重定向一样的理由；因而我直接以“繁简重定向”开题（你可以看到，上方反对废除“繁简重定向”的理由就是反对废除“2条仅为简繁差异的重定向”的理由；且这条留言显示白布飘扬等并没有弄错讨论的对象）。关于@Sohryu Asuka Langley Not Shikinami说的“2条仅为简繁差异的重定向”是“小问题”，请注意能够创建的“2条仅为简繁差异的重定向”数量远远多过标题的“繁简重定向”。不过如果2位仍然觉得目前讨论不切题的话，就停止吧……按SuperGrey的方式处理，但标题实在要改一下，把“移动”去掉。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 02:17 (UTC)[回复]
明白了。如果将问题扩展到是否废除“ 2条仅为简繁差异的重定向”，那么确实和是否废除繁简重新导向是同一道题。但是因为目前其他讨论者讨论的都不是这个题（而是主要因移动产生的重新导向），故讨论变得非常混乱。如果您希望讨论“是否废除繁简重新导向”这个大题，还是也在底下专门开一个吧，看看大家是否想要新建几十万条繁简重新导向。--SuperGrey (留言) 2025年4月28日 (一) 02:30 (UTC)[回复]
算了。我想了想，还是不要妄下定论。虽然我赞同是“同一道题”，但别人不一定赞同。故还是分开来提案吧，就事论事。如果要讨论全部废除，就讨论全部废除；如果要讨论废除“简繁差异的两个重新导向”，就讨论“简繁差异的两个重新导向”；如果要讨论“因移动产生的重新导向”，就讨论“因移动产生的重新导向”。--SuperGrey (留言) 2025年4月28日 (一) 02:38 (UTC)[回复]
@SuperGrey：目前其他讨论者讨论的都不是这个题（而是主要因移动产生的重新导向）[需要解释]（我刚刚才说“2条仅为繁简差异的重定向”很多不是因为移动建立的，而且因为移动而建立的那些因为有修复双重重定向的机制反而不会出错，甚至不需要机器人监控；讨论的重点就是和“繁简重定向”作用一致的并非因为移动产生的那些“2条仅为简繁差异的重定向”。）另外恕我直言，让我觉得讨论混乱的主要是您（以及Aqurs也有一些莫名的误解），其他人则大都是切题讨论；您莫名将“反对废除”等同于了“要新建”（而且您似乎没留意到我说的“能够新建的‘2条仅为简繁差异的重定向’”数量比标题繁简重定向远远更多）。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 02:41 (UTC)[回复]
@SuperGrey：见此，@Iming一开始确实举错了例子，说到了移动问题，但很快纠正了——目前其他讨论者讨论的都并不主要是因移动产生的重定向（副知@魔琴）。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 03:14 (UTC)[回复]
行。已删去“因移动导致”。--SuperGrey (留言) 2025年4月28日 (一) 03:57 (UTC)[回复]
“简体标题（重定向）”重定向至“繁体标题（条目）”，后“繁体标题（条目）”被移动，变为“繁体标题（重定向）”，就会出现“因移动而产生”的“2条仅为简繁差异的重定向”。虽然机器人会修复双重重定向，但我主要是质疑“这些重定向建立的原因多不是因为移动”这一点。我认为重点在于“指向页面不一致”的情况有多少、能否有效监察。
对于如何处理“2条仅为简繁差异的重定向”及或“指向页面不一致”，我认为下方这两个皆是选项，但废除繁简重定向有点overkill。（可理解为二选一的话支持机器人方案）--惣流·明日香·兰格雷不姓式波 2025年4月28日 (一) 02:42 (UTC)[回复]
我知道这种移动会产生这种重定向，但我也看到很多额外新建的情况——谁更多不重要，重点是前者在目前机器人维护下已经基本不会出现目标不一致的问题。由于“能够新建的‘2条仅为简繁差异的重定向’”数量比标题繁简重定向远远更多，实际上标题繁简重定向只是所有这些繁简重定向的一小部分，所以我不太理解“overkill”的说法……（换句话说，如果是Supergrey等因担心用户大量创建“标题繁简重定向”而决心废除，那么同样的逻辑更该担心的是“2条仅为简繁差异的重定向”……） ——自由雨日🌧️❄️ 2025年4月28日 (一) 02:55 (UTC)[回复]
关于上面@我的“小问题”，我指的是“两个仅为简繁差异但目标不同的重定向”（数量未知，但上限为7万），对比的“大问题”是“繁简重定向”（11万），中间还有“2条仅为简繁差异的重定向”（7万）。至于“能够创建的”，我不太关心这个。“实际上标题繁简重定向只是所有这些繁简重定向的一小部分”，这个有大概的比例吗？--惣流·明日香·兰格雷不姓式波 2025年4月28日 (一) 03:00 (UTC)[回复]
我指的是潜在能创建的数量：因为不少“删除”这些重定向意见理由是“担心有用户大量创建”——那么如果以此为理由认为需废除标题繁简重定向的话，当然更应该以此为理由废除“2条仅为简繁差异的重定向”。这也是我不认同你说的“繁简重定向”是大问题而“2条仅为简繁差异的重定向”是小问题的原因（在我看来刚好相反）。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 03:03 (UTC)[回复]
所以阁下的意思是“标题繁简重定向只是所有这些（潜在能创建的）繁简重定向的一小部分”？重申一次我指的“小问题”是“两个仅为简繁差异但目标不同的重定向”，我瞎猜不到一万，甚至一千例都未必有，所以（现时实际上）比较下来就是小问题，阁下同意吗？--惣流·明日香·兰格雷不姓式波 2025年4月28日 (一) 03:40 (UTC)[回复]
@Sohryu Asuka Langley Not Shikinami：知道你的意思了，你说的“小问题”是“处理两个仅为简繁差异但目标不同的重定向”，但我理解成了你说的小问题是“处理两个仅为简繁差异的重定向”（没有“但目标不同”），在此抱歉。然而如果是这样的话，不得不说您理解错了本提案。本提案并不是针对现存的“大概率不到一千例的”“两个仅为简繁差异但目标不同的重定向”……所有的7万条“两个仅为简繁差异的重定向”必须共同处理，要么删掉其中一种繁简版本，要么全部保留并用机器人维护。@Iming提案的重点也说了，A和B原本重定向至同一页面，但A改了重定向目标但B没改，导致不一致，所以需要机器人随时监控将来可能出现的这种改变，重点并不是讨论如何处理现在那些不一致的页面。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 03:52 (UTC)[回复]
是这样的。Iming 彼女の爱は、甘くて痛い。 2025年4月28日 (一) 03:54 (UTC)[回复]
（以及现在虽只有7万条，但无法预计未来会建立多少条，如果选择不废除，未来会出现的也都必须监控。所以我说才一直在说“潜在能创建的数量”。） ——自由雨日🌧️❄️ 2025年4月28日 (一) 03:56 (UTC)[回复]
我调整了一下下面“原提案”章节的表述，贴合您的提案。--SuperGrey (留言) 2025年4月28日 (一) 04:02 (UTC)[回复]
@自由雨日：仔细想了想，补了一个各退一步的折衷方案(C)维持现状。有了折衷方案或许更有助于结案 😂--SuperGrey (留言) 2025年4月28日 (一) 04:16 (UTC)[回复]
好的，现时各方的观点应该都正确地传递好了。接下来的问题是：如果不必“废除繁简重定向”就能妥善解决“小问题”，那是否还需要废除？要注意即使决定要废除，处理“小问题”的程序还是要先跑一遍的。“潜在能创建的数量”固然很大，但“将来会创建的数量”其实很小（不过得承认不会是0）。老实说我不反对废除，但我实在不觉得这次突然就能成功废除。--惣流·明日香·兰格雷不姓式波 2025年4月28日 (一) 04:23 (UTC)[回复]
确实可以先把已有的小问题处理了。--SuperGrey (留言) 2025年4月28日 (一) 04:29 (UTC)[回复]
如果你指的“小问题”仍是指处理现存的目标不一的页面的话，那根本不需要提案，机器人一通操作就搞定了……提案主要是要管将来（将来会新建的这类页面其实也不是重点，重点是现存的目标一致的页面未来可能发生不一致的情况——包括标题繁简重定向其实也会发生这种情况）。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 04:36 (UTC)[回复]
以防万一我还是确定一下，所以现时确实是在讨论“废除所有繁简重定向”？另，现时的Category:简繁重定向是否包含“两个仅为简繁差异的重定向（不论目标）”？--惣流·明日香·兰格雷不姓式波 2025年4月28日 (一) 01:51 (UTC)[回复]
至少我现在不是很确定@自由雨日君想要讨论的是什么提案。--SuperGrey (留言) 2025年4月28日 (一) 01:53 (UTC)[回复]
行。既然讨论的题目不是“繁简重新导向”而是“两个仅为简繁差异的重定向”，那干脆在下面再开一个章节吧。不然前面这些讨论偏题很远了。--SuperGrey (留言) 2025年4月27日 (日) 23:27 (UTC)[回复]
不用开啊？我上方留言不是才说本质上区别不大吗😂繁简重定向的作用基本就是“两个仅为繁简差异重定向”的作用，而且它们也可以因页面移动互相转化，后者在重定向页挂的模板也常是“繁简重定向”，先前偶尔看到提删或其他讨论时也经常是叫作“繁简重定向”。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 01:22 (UTC)[回复]
定义混乱，混为一谈。怪不得整个讨论都跑偏了。--SuperGrey (留言) 2025年4月28日 (一) 01:43 (UTC)[回复]
我没看到跑偏啊……再见这条留言。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 01:45 (UTC)[回复]
@SuperGrey：我完全没看到这种迹象啊…… ——自由雨日🌧️❄️ 2025年4月28日 (一) 01:09 (UTC)[回复]
看来是我误读了“繁简重定向属常年提案，如果本讨论真是讨论在两方案取其一的话，恐怕不得不开始ping之前的编者大规模讨论了”传达的含义。我以为“两方案”指的是这个“常年提案”，又要再来讨论一遍这个“常年提案”。--SuperGrey (留言) 2025年4月28日 (一) 01:16 (UTC)[回复]
不是很理解您的理解……不过可能是我没有加“废除”两个字造成的误会？因为之前有不少编者反对废除“繁简重定向”（之前有过多次提案废除），所以本讨论其中一个选项涉及“废除”当然应该通知…… ——自由雨日🌧️❄️ 2025年4月28日 (一) 01:20 (UTC)[回复]
哦，明白了，换句话说情况3的upperbound是7万多。--惣流·明日香·兰格雷不姓式波 2025年4月27日 (日) 13:42 (UTC)[回复]
情况3确实值得处理。--SuperGrey (留言) 2025年4月27日 (日) 13:45 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

原提案：目前和将来出现的2条仅为简繁差异的重新导向，(A)使用机器人维护？(B)还是删除？

原标题：原提案：2条仅为简繁差异的重新导向，共7万条，(A)使用机器人维护？(B)还是删除？。修改者：--此条未签名留言由SuperGrey（讨论｜贡献）于2025年4月28日 (一) 04:01 (UTC)加入。[回复]

原标题：原提案：因移动导致的2条仅为简繁差异的重新导向，共7万条，(A)使用机器人维护？(B)还是删除？。修改者：--此条未签名留言由SuperGrey（讨论｜贡献）于2025年4月28日 (一) 03:56 (UTC)加入。[回复]

目前和将来，若出现2条重新导向仅简繁字形存在差异，请大家决定如何处置？此情况目前共有7万条，但未来可能会出现更多。

(A)保留，并使用机器人统一维护管理？

(B)择一删除？--SuperGrey (留言) 2025年4月28日 (一) 01:49 (UTC)[回复]

(C)维持现状：已有的，保留，并使用机器人进一步监视维护；未来凡非移动产生的此类重新导向，视为重复，如无合理理由（如生僻字无法被自动转换之类）不再建立新的。--SuperGrey (留言) 2025年4月28日 (一) 04:12 (UTC)[回复]

目前已有机器人自动处理此类重新导向。我不反对维持现状，故A、B我都支持。--SuperGrey (留言) 2025年4月28日 (一) 01:56 (UTC)[回复]
更准确的描述是：现时有7万对“仅为简繁差异且两者皆为重定向”，其中有部分（数量应该未知）属于“简繁分别重定向至不同目标”，为处理后者，对于这七万对，是应该1.）使用机器人维护，还是2.）删除每对的其中一项。--惣流·明日香·兰格雷不姓式波 2025年4月28日 (一) 02:00 (UTC) 👍1[回复]
“因移动导致的2条仅为简繁差异的重新导向”并不是@Iming的意思…… ——自由雨日🌧️❄️ 2025年4月28日 (一) 03:21 (UTC)[回复]
我给的例子里，七万多例不都是因为移动导致的（我甚至不太确定是否存在仅因为移动导致的两个只有简繁差异的重定向）。我觉得这部分的标题需要更改，需要删掉“因移动导致”。Iming 彼女の爱は、甘くて痛い。 2025年4月28日 (一) 03:37 (UTC)[回复]
而且因移动导致的重定向通常情况下会有机器人维护，所以一般情况下不会出现本提案所述“目标页面不同”的情况。--Iming 彼女の爱は、甘くて痛い。 2025年4月28日 (一) 03:44 (UTC)[回复]
已删去题目中的“因移动导致”。--SuperGrey (留言) 2025年4月28日 (一) 03:56 (UTC)[回复]
我又添加了方案(C)，也就是维持现状。或许这样更简单易行。--SuperGrey (留言) 2025年4月28日 (一) 04:12 (UTC)[回复]
我说一下我的立场吧：上方白布飘扬、Kethyga等论述的这类重定向的作用均既适用于“标题繁简重定向”，也适用于“2条仅为简繁差异的重定向”，且“标题繁简重定向”也可能存在指向另一页面的问题（比如标题为“画图”的条目的繁体版本“畫圖”却指向另一页面。这时候到底是算“标题繁简重定向”还是算“2条仅为简繁差异的重定向”呢？这里向@Iming确认下统计的时候有没有考虑到这些页面？）；此外两者也常可互相转化。且白布飘扬的这条留言也明确表示的是支持机器人维护所有“目标不一致的简繁页面”（并不单针对“标题繁简重定向”）。因而我反对B方案，即反对废除“2条仅为简繁差异的重定向”。对C我不强烈反对，但仍倾向认为除非是为了“刷编辑数”大量产生的重定向，否则不需要限制建立（利益申明：我个人除非确有需要或无意间没看到有繁体版本，否则我是并不会去建立这种重定向的）。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 04:21 (UTC)[回复]
还有一种特殊情况是，我个人一直倾向认为不应要求所有仅繁简差异的重定向标题都必须指向同一页面（应豁免一些特殊情况。比如简体“朝鲜”我认为应重定向至“朝鲜民主主义人民共和国”），如果将来社群能获得共识允许这类繁简同形词导向目标不一，那当然不应删除另一繁/简，以及机器人需要为这些页面“开绿灯”。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 04:31 (UTC)[回复]
不应豁免。“繁简统一”是方针，如果想要修改方针，需要专门拿出提案到“互助客栈/方针”去讨论。--SuperGrey (留言) 2025年4月28日 (一) 04:41 (UTC)[回复]
“繁简统一”是方针[哪里？]我之前找了不少页面都没找到。（条目当然是繁简统一，不能为“法国”创建简体条目/繁体条目两个版本。我说的是重定向/消歧义的情况。） ——自由雨日🌧️❄️ 2025年4月28日 (一) 04:45 (UTC)[回复]
Wikipedia:命名常规#繁简统一。--SuperGrey (留言) 2025年4月28日 (一) 04:46 (UTC)[回复]
您好像完全理解错了……《命名常规·繁简统一》说的是不能使用繁简混杂的条目名称…… ——自由雨日🌧️❄️ 2025年4月28日 (一) 04:49 (UTC)[回复]
还真是……这里倒是还有一个指引：WP:繁简重新导向，不过这里只表达了对双重重新导向的弱反对，没提到指向目标是否要统一。--SuperGrey (留言) 2025年4月28日 (一) 04:57 (UTC)[回复]
还有一条：WP:R#NPOV，这条是方针。--SuperGrey (留言) 2025年4月28日 (一) 05:04 (UTC)[回复]
好吧，这条也没有做出明确规定。看来“重新导向的繁简统一”还未有形成书面共识。--SuperGrey (留言) 2025年4月28日 (一) 05:11 (UTC)[回复]
（编辑冲突）我知道这条方针，这和我说的也没有任何关联……（它说的是“可以创建非中立重定向”的问题。）是否允许繁简重定向目标不一有点跑题了，先打住吧😂 ——自由雨日🌧️❄️ 2025年4月28日 (一) 05:12 (UTC)[回复]
WP:避免地域中心？不过确实跑题，有机会再讨论吧。--惣流·明日香·兰格雷不姓式波 2025年4月28日 (一) 05:20 (UTC)[回复]
我认为应该一律指向同一页面，理由在《User:魔琴/论述/体异页同》已述。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年4月28日 (一) 19:06 (UTC)[回复]
我记得当时在客栈均回应过了（忘了哪个讨论了）。 ——自由雨日🌧️❄️ 2025年5月8日 (四) 13:24 (UTC)[回复]
您怎么判断对方是不是“为了‘刷编辑数’而创建”呢？如果我每写一个新条目就创建几个（比如说，因为有了后藤一里这个条目，就建立後藤一里、後藤獨、后藤独、小孤獨、小孤独），这算是“刷编辑数”吗？还是说应当限制呢？--SuperGrey (留言) 2025年4月28日 (一) 04:34 (UTC)[回复]
和其他刷编辑数的认定方法类似……客观上肯定没有一个标准，但可以结合行为模式判断。我自己不会去建立，但我个人不倾向限制建立（其实我看@Iming就常大批同时建立仅繁简差异的重定向😂），不过如果其他编者倾向C方案，可以认为我“不反对”C。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 04:41 (UTC)[回复]
既然“刷编辑数”的标准模糊不清，不如直接限制不要再添加新的，用规则来约束，就不必在未来看到你我被送交ANM了 --SuperGrey (留言) 2025年4月28日 (一) 04:45 (UTC)[回复]
“画图”的情况属于这里的情况2，我认为可以全自动解决（当然最好处理完再人工检查一下）。另外想确认一下，阁下对“废除繁简重定向”的立场为何？其实除了SuperGrey，貌似没其他用户表达过支持，所以继续讨论（废除繁简重定向）的意义可能不大。--惣流·明日香·兰格雷不姓式波 2025年4月28日 (一) 04:38 (UTC)[回复]
和上方同样的逻辑，自然也是反对废除繁简重定向。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 04:41 (UTC)[回复]
您对(C)怎么看？--SuperGrey (留言) 2025年4月28日 (一) 04:43 (UTC)[回复]
其实“使用机器人监视维护”是必须的，因为未来依然有机会出现这类情况。所以重点是对于“未来产生的此类重新导向”是直接删除还是容许保留。换言之在确定会有机器人监视的前提下，三个选项可以概括为：
(A)现有的(○)保留，未来的(○)保留
(B)现有的(×)删除，未来的(×)删除
(C)现有的(○)保留，未来的(×)删除
（“现有的删除”指删除“后来的”；“未来的删除”指先更新“先来的”的连结目标，再删除“后来的”）
所以说三个选项都差不多，不过我会倾向A或B，执行起来简单一点。--惣流·明日香·兰格雷不姓式波 2025年4月28日 (一) 05:16 (UTC) 👍1[回复]
(－)反对B+C，(＋)支持A，谢谢--Aqurs 2025年4月28日 (一) 14:53 (UTC)[回复]
小工具“PageRedirect ToolsRedirect”似乎会把所有繁简形式都找出来让你创建，如果禁止建立繁简差异重定向，使用起来会非常麻烦。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年4月28日 (一) 12:44 (UTC)[回复]
那就换个小工具。--SuperGrey (留言) 2025年4月28日 (一) 13:09 (UTC)[回复]
现在有替用品吗？--WiTo🐤💬 2025年4月29日 (二) 02:30 (UTC)[回复]
我可以写一个。--SuperGrey (留言) 2025年4月29日 (二) 06:20 (UTC) 👍1[回复]
见此源代码：MediaWiki:Gadget-ToolsRedirect.js。把基于繁简的部分去掉即可。--SuperGrey (留言) 2025年4月29日 (二) 06:25 (UTC)[回复]
距离上一次留言已逾9日，看起来对于使用机器人应该没有什么太大的意见，那么我想我们应该初步达成了一个共识，即“不论是否新建，相关对重定向的修改均由机器人监视并维护”。有鉴于这个提案最开始只是为机器人许可而开的，且我们没有产生什么其他必须要公示的内容，就不公示了。如果您还存在任何意见，请您说明，感谢。Iming 彼女の爱は、甘くて痛い。 2025年5月8日 (四) 13:19 (UTC)[回复]
应该补充一下，对于新建的，由编者自行决定是否提报删除，机器人不会自动提删。--Iming 彼女の爱は、甘くて痛い。 2025年5月8日 (四) 13:22 (UTC)[回复]

有关Template:Jct模板问题

本主题全部或部分段落文字，已移动至Template talk:Jct、Module talk:Road data/strings/TWN。执行者：Jimmy-bot（留言） 2025年5月7日 (三) 16:14 (UTC)。[回复]

新脚注风格：用户测试

原题目：Sub-referencing: User testing --KurGenera(留言) 2025年4月29日 (二) 17:17 (UTC)[回复]

Apologies for writing in English, please help us by providing a translation below

Hi I’m Johannes from Wikimedia Deutschland's Technical Wishes team. We are making great strides with the new sub-referencing feature and we’d love to invite you to take part in two activities to help us move this work further:

  1. Try it out and share your feedback
    Please try the updated wikitext feature on the beta wiki and let us know what you think, either on our talk page or by booking a call with our UX researcher.
  2. Get a sneak peak and help shape the Visual Editor user designs
    Help us test the new design prototypes by participating in user sessions – sign up here to receive an invite. We're especially hoping to speak with people from underrepresented and diverse groups. If that's you, please consider signing up! No prior or extensive editing experience is required. User sessions will start May 14th.

We plan to bring this feature to Wikimedia wikis later this year. We’ll reach out to wikis for piloting in time for deployments. Creators and maintainers of reference-related tools and templates will be contacted beforehand as well.

Thank you very much for your support and encouragement so far in helping bring this feature to life!

Johannes Richter (WMDE) (talk) 2025年4月28日 (一) 15:04 (UTC)[回复]

省流：注释系统大改
--KurGenera(留言) 2025年4月28日 (一) 16:19 (UTC)[回复]
详见第18期技术新闻。--KurGenera(留言) 2025年4月28日 (一) 23:25 (UTC)[回复]

关于T:Republican Calendar的一点啸问题

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

怎样把这玩意的显示从UTC+0改成UTC+8呢？（当然原模板不能动😁，但可以自行测试）--KurGenera(留言) 2025年4月28日 (一) 16:29 (UTC)[回复]

自行解决了喵(≧^.^≦)~--KurGenera(留言) 2025年4月28日 (一) 16:47 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

2025年第18期技术新闻

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

近况更新 - 面向编辑者

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

  • 维基媒体设计系统——Codex预定于2025年4月29日发布下一个主要版本。技术编辑者将能于2025年5月5日当周使用该版本。本次更新将包含一些不向下相容的重大变更和轻微的视觉变更。该页面记载了处理重大变更和视觉变更的说明。发布前的测试在T386298中回报，发布后的问题则在T392379和T392390中追踪。
  • Wiki Replicas的使用者将会注意到ipblocks、ipblocks_ipindex和ipblocks_compat这几个数据库检视表现已弃用。使用者可以查询block和block_target这二个新的检视表，这些新检视表会反映生产数据库中的新表格。弃用的检视表将于2025年6月从Wiki Replicas中完全移除。
  • 经常项目 本周稍晚代码更新细节： MediaWiki

深入了解

会议与活动

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

MediaWiki message delivery 2025年4月28日 (一) 19:31 (UTC)[回复]

Jpn、Kor等模板是否应改以langx等模板为基础？

本主题或以下段落文字，在讨论结束后应存档至Template talk:Jpn、Template talk:Kmr、Template talk:Kor、Template talk:Vie。

如题，{{Jpn}}、{{Kor}}等模板是否应改以{{langx}}等模板为基础？具体提议代码见User:Sanmosa/Template的子页面。Sanmosa 新朝雅政 2025年4月29日 (二) 08:59 (UTC)[回复]

看了一下{{Jpn}}的改法，改用{{langx}}仅仅是为了显示“日语”两个字。日语原文、假名以及／、〔、〕符号全在一个<span lang="ja">里面，可能会影响屏幕阅读器的使用。|link=参数的两种情况代码竟然是分开写的，维护困难。--Kcx36（留言） 2025年4月29日 (二) 12:31 (UTC)[回复]
@Kcx36：我最近才留意到langx可以设置label=none的事情，或许我可以用这个方法简省一些代码。Sanmosa 新朝雅政 2025年5月7日 (三) 11:00 (UTC)[回复]
新的{{lang}}模板无法自定义提示文字。日语汉字、平假名、片假名、罗马字、旧字体全都只显示“日语文本”，不如以前的清楚标明所使用的文字好。可能还得改进{{lang}}、module:lang。--Kethyga（留言） 2025年4月30日 (三) 04:23 (UTC)[回复]
@Kethyga：关注到这个问题。我关注{{lang}}内加span（比如{{lang|ja|<span title="漢字或假名表記（原文）">柳原家</span>}}）能否正确生效（即显示“汉字或假名表记（原文）”而非“日语文本”）。Sanmosa 新朝雅政 2025年5月7日 (三) 10:59 (UTC)[回复]
如果之后要提删这些模板，则恕不能同意。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月6日 (二) 17:25 (UTC)[回复]
@Ericliu1912：Jpn、Kor与Kmr的结构与langx的基础结构差异过大，就算真的改以langx等模板为基础也不可能删除。考虑到Vie的用量，我也不打算提删Vie。Sanmosa 新朝雅政 2025年5月7日 (三) 10:59 (UTC)[回复]

重新导向分类模板填写小工具

每次都要手动填分类模板，实在麻烦，故引入了英维Redirect Helper——User:SuperGrey/gadgets/RedirectHelper。参见源代码。按照中维需要调整了可用的分类模板。暂未做简繁转换，反正功能也不多，以后再做吧……--SuperGrey (留言) 2025年4月30日 (三) 17:59 (UTC) 👍1[回复]

efn爆炸了

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

已解决
提案者使用了错误的模板语法。--PexEric 2025年5月2日 (五) 16:38 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

{{efn|法国精神病学家{{link-fr|罗兰·库唐索|Roland Coutanceau}}在其著作《心理暴力：理解与行动（Les violences psychologiques : Comprendre pour agir）》(Dunod, 2014)[https://books.google.fr/books?id=pGHIAwAAQBAJ&pg=PA206 page 206]，未详细说明地给出7人死亡数字。}}

显示：引用错误：<ref>标签中没有内容

有没有人解答一下发生了什么？--KurGenera(留言) 2025年5月1日 (四) 00:36 (UTC)[回复]

请把你网址里面的等号=换成{{=}}（使用{{=}}魔术字而非模板，语法一样但不传参数），不然“{{efn | 法国精神病学家{{link-fr|罗兰·库唐索|Roland Coutanceau}}在其著作《心理暴力：理解与行动（Les violences psychologiques : Comprendre pour agir）》(Dunod, 2014) … [https://books.google.fr/books?id=pGHIAwAAQBA … J&pg = PA206   page 206 … ]，未详细说明地给出7人死亡 … 数字。}}”会被视为别的参数，而efn的预期参数就变成空的，所以当然引用错误：<ref>标签中没有内容啦，字面上的意思。模板没有炸，是你输入错误。 -- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2025年5月1日 (四) 00:42 (UTC)[回复]
  • (～)补充所以你输入的“{{efn | 法国精神病学家{{link-fr|罗兰·库唐索|Roland Coutanceau}}在其著作《心理暴力：理解与行动（Les violences psychologiques : Comprendre pour agir）》(Dunod, 2014) … [https://books.google.fr/books?id=pGHIAwAAQBA … J&pg = PA206   page 206 … ]，未详细说明地给出7人死亡 … 数字。}}”会被解析为：
    • 名称为“法国精神病学家{{link-fr|罗兰·库唐索|Roland Coutanceau}}在其著作《心理暴力：理解与行动（Les violences psychologiques : Comprendre pour agir）》(Dunod, 2014) … [https://books.google.fr/books?id=pGHIAwAAQBA … J&pg”的参数，并输入了值“PA206   page 206 … ]，未详细说明地给出7人死亡 … 数字。”
    • {{efn}}的必填参数被系统认为没填
因此你等于传了无效参数给{{efn}}。故模板没有爆炸，这是预期行为。模板未损坏，无须修理。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2025年5月1日 (四) 06:20 (UTC)[回复]
补充一下，在引用内容前加上1=也可以，即将{{efn|带等号的引用内容}}改为{{efn|1=带等号的引用内容}}。 ——自由雨日🌧️❄️ 2025年5月1日 (四) 00:46 (UTC)[回复]
这是正确做法。遇到模版参数值有等号的，需要显式指明参数名。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月2日 (五) 12:41 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

请求尽快处理部分模组的页面历史合并

WP:页面存废讨论/记录/2025/04/01#Module:Unicode data/scripts与WP:页面存废讨论/记录/2025/04/13#批量Module:Lang相关data提删。Sanmosa 新朝雅政 2025年5月2日 (五) 12:53 (UTC)[回复]

有无批量检测、系统显示维基页面中红链（失效内部连结）的软件工具？

比如在哲学词汇表页面里找出前直觉主义、人类状况等在中文维基尚无的条目？ --Zhenqinli（留言） 2025年5月2日 (五) 22:24 (UTC)--Zhenqinli（留言） 2025年5月2日 (五) 22:24 (UTC)[回复]

针对单个页面？用CSS或编写JS脚本应该能突出/列出，但有必要吗，不阅读上下文的列出。--YFdyh000（留言） 2025年5月2日 (五) 22:49 (UTC)[回复]
如果有方便合适工具的话，对改善页面是有帮助的。 --Zhenqinli（留言） 2025年5月2日 (五) 22:55 (UTC)[回复]
@Zhenqinli，WP:AWB里面有个功能Links on page (only red links)。-- Willy1018（留言） 2025年5月5日 (一) 23:09 (UTC)[回复]
谢谢！好像需要申请权限？准备稍晚再试。 --Zhenqinli（留言） 2025年5月5日 (一) 23:54 (UTC)[回复]
@Zhenqinli：User:魔琴/gadgets/listredlinks/index.js，在页面底部列出红链，大概没什么问题。想改什么尽管说，但我懂不懂怎么写就不一定了。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月6日 (二) 12:06 (UTC) 👍1[回复]
很好用。谢谢！ --Zhenqinli（留言） 2025年5月6日 (二) 13:07 (UTC)[回复]

模板:分类重定向

本主题全部或部分段落文字，已移动至Template talk:分类重定向#编辑请求 2024-05-04。执行者：SunAfterRain 2025年5月4日 (日) 07:40 (UTC)。移动理由：移为RFC[回复]

Cat-a-lot小工具错误

本主题或以下段落文字，在讨论结束后应存档至MediaWiki talk:Gadget-Cat-a-lot.js。

Cat-a-lot小工具似乎会将展开此一页面到处错误分类（请见编辑历史），不确定是怎么回事。副知其他苦主@HanTsî、Yumeto。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月5日 (一) 10:14 (UTC)[回复]

我用的是维基共享资源版本，E、H用的可能是本站版本，都有出现过这种问题。--绀野梦人 2025年5月5日 (一) 10:30 (UTC)[回复]
本站版本该更新了。getMarkedLabels函数会选中.CategoryTreeBullet的a元素，title属性是“展开”（或“折叠”，但本站还没有折叠条目）。共享资源版本已差异不小，getMarkedLabels函数中的a:not([role])不选有role属性的元素，可避免此误匹配。部署共享资源版本2024年8月8日的修改补丁就可以，U:Yumeto遇到此问题时尚无补丁。--YFdyh000（留言） 2025年5月5日 (一) 10:56 (UTC)[回复]
@YFdyh000：本站是否适合直接移植共享资源现行版本？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月5日 (一) 13:05 (UTC)[回复]
我没用过共享资源版本。询问AI来看，共享资源版本改进了很多方面。从Wikipedia:维基百科工具/Cat-a-lot允许以及U:Yumeto之前在用来看，共享资源版本在本地没有明显的问题，可能应该弃用本地版本？--YFdyh000（留言） 2025年5月5日 (一) 13:29 (UTC)[回复]
共享资源版本只能识别与分类标题正简体一致的源代码，否则不能，而本站版本对部分与分类标题正简体不一致的源代码仍能识别，例如源代码“[[Category:英國]]”不能被共享资源版本，而能被本站版本识别为“Category:英国”。--绀野梦人 2025年5月5日 (一) 23:46 (UTC)[回复]
@Yumeto：那本站现行版本与共享资源版本的差别在哪里呢？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月6日 (二) 17:28 (UTC)[回复]
我只是从使用经验来比较，不是太了解代码上的差异……--绀野梦人 2025年5月6日 (二) 17:34 (UTC)[回复]
共享资源版本只能识别与分类标题正简体一致的源代码，能否具体指出复现步骤？--Hamish T 2025年5月6日 (二) 22:27 (UTC)[回复]
在维基百科:沙盒添加“[[Category:英國]]”（Category:英国）与“[[Category:中華民國]]”（Category:中華民國）（差异），用共享资源版本移除前者时会出现“以下页面已跳过，因为找不到现有分类：Wikipedia:沙盒”，而移除后者时不会（差异）。使用本站版本能移除前者（差异）。--绀野梦人 2025年5月7日 (三) 01:31 (UTC)[回复]
Special:Diff/37158362提供该功能。未对比其他差异。--YFdyh000（留言） 2025年5月7日 (三) 11:08 (UTC)[回复]
其SettingsUI似乎有问题，无法保存。--YFdyh000（留言） 2025年5月5日 (一) 14:09 (UTC)[回复]
无法保存是因为SettingsManager也要更新。--Hamish T 2025年5月7日 (三) 00:31 (UTC)[回复]

关于single_chart的问题

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

我在整理Draft:我的男孩只会亲手毁坏心爱玩具时遇到了这一句{{single chart|UKdownload|88|date=20240426|rowheader=true|access-date=2024-07-09|refname="UKDownload"}}（对应草稿的第72个来源），但我发现：

  1. 页面链接失效（http://www.officialcharts.com/archive-chart/_/6/20240426/ ），而英维条目的对应链接则是 https://www.officialcharts.com/charts/singles-downloads-chart/20240426/7000/ ，可以正常访问。
  2. 不会生成来源，所以第49个来源会变成“引用错误：没有为名为UKdownload的参考文献提供内容”。

我怀疑是错误，希望各位可以查明。--ItMarki探讨人生 2025年5月5日 (一) 10:49 (UTC)[回复]

看起来是T:single chart中第339行开始的|UKdownload那段需要更新--竹林下小径，月光映一叶 2025年5月5日 (一) 11:11 (UTC)[回复]
 已修复，请见版本87151010的修改。
不知道为什么原本的|UKdownload那段中，没用上refname的参数呢XP--竹林下小径，月光映一叶 2025年5月5日 (一) 11:35 (UTC)[回复]
我感觉这个模板还有一些问题，大概还没有和英维那边的同步。--ItMarki探讨人生 2025年5月6日 (二) 14:12 (UTC)[回复]
毕竟两边的Template都挺长的，所以我只有修UKdownload那段而已👉👈(戳手指)--竹林下小径，月光映一叶 2025年5月6日 (二) 17:26 (UTC)[回复]

2025年第19期技术新闻

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

本周要闻

近况更新 - 面向编辑者

  • 已启用CampaignEvents的维基，该扩充功能发布了两项新的功能改进：
    • 管理员现在可以透过社群配置（说明文件）选择哪些命名空间允许活动报名。预设配置允许在“Event”命名空间中进行活动报名，但现在可以新增其他命名空间（例如专案或“维基专题”命名空间）。有了这项变更，维基专题等社群现在可以更轻松地使用活动报名功能来举办协作活动。
    • 编辑者现在可以在维基页面中嵌入协作清单（说明文件）。协作清单自动列出维基上的活动和维基专题，可透过Special:AllEvents查看（范例）。现在，协作清单可以被加进各种维基页面中，例如：维基首页、维基专题页面、自治体页面、活动页面，甚至是使用者页面。
  • 经常项目 上周有27件社群提交的工单得到解决。

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

  • 小工具和使用者脚本的开发者，应将其使用moment函式库的程式码改为使用其他函式库，例如Intl或新的mediawiki.DateFormatter函式库。moment函式库现已弃用，并将开始在浏览器的开发人员主控台中记录警告讯息。需修改的程式码页面，请在Phab工单中提供的全域搜寻结果查看，如有疑问也可在工单中提出。
  • 维护用于查询维基数据词汇（term）储存表（wbt_*）的工具的开发者需要更新其程式码，以连接到单独的数据库丛集。这些表格将被分割到一个独立的数据库丛集中。透过Wiki Replicas来查询这些表格的工具，必须改为连接到新的数据库丛集。参阅说明文件和相关连结。 [4]
  • 经常项目 本周软件更新细节： MediaWiki

深入了解

  • Chart专案电子报新期数发布。 本期包括以下新讯：最快在本周（5月6日开始），Chart将进一步部署至更多wiki，并在接下来的几周内扩大部署规模，此外Chart将探索筛选和转换来源资料。

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

MediaWiki message delivery 2025年5月6日 (二) 00:13 (UTC)[回复]

RefToolbar丢失文字标签

这段时间发现我的RefToolbar丢失了“Cite”、“Templates”、“Named References”、“Error Check”这几个文字标签，还有jQuery对话框的标题。我看了enwiki是正常的。--此条未正确签名的留言由魔琴（讨论｜贡献）于2025年5月6日 (二) 10:57 (UTC)加入。[回复]

We will be enabling the new Charts extension on your wiki soon!

(Apologies for posting in English)

Hi all! We have good news to share regarding the ongoing problem with graphs and charts affecting all wikis that use them.

As you probably know, the old Graph extension was disabled in 2023 due to security reasons. We’ve worked in these two years to find a solution that could replace the old extension, and provide a safer and better solution to users who wanted to showcase graphs and charts in their articles. We therefore developed the Charts extension, which will be replacing the old Graph extension and potentially also the EasyTimeline extension.

After successfully deploying the extension on Italian, Swedish, and Hebrew Wikipedia, as well as on MediaWiki.org, as part of a pilot phase, we are now happy to announce that we are moving forward with the next phase of deployment, which will also include your wiki.

The deployment will happen in batches, and will start from May 6. Please, consult our page on MediaWiki.org to discover when the new Charts extension will be deployed on your wiki. You can also consult the documentation about the extension on MediaWiki.org.

If you have questions, need clarifications, or just want to express your opinion about it, please refer to the project’s talk page on Mediawiki.org, or ping me directly under this thread. If you encounter issues using Charts once it gets enabled on your wiki, please report it on the talk page or at Phabricator.

Thank you in advance! -- User:Sannita (WMF) (talk) 2025年5月6日 (二) 15:07 (UTC)[回复]

Category:图表被禁用的页面，或可考虑将此处列出的页面中的图表替换？谢谢。--SCP-0000（留言） 2025年5月6日 (二) 15:35 (UTC)[回复]
数据和源代码表现形式千差百异，可能全自动切换有点麻烦。讨论页现在很多有使用{{Mostread}}来检查页面浏览量，需要改写。还有一些直接使用{{Graph:Chart}}等。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月8日 (四) 06:21 (UTC)[回复]
本地似乎已经可用[5]--百無一用是書生 (☎) 2025年5月8日 (四) 02:57 (UTC)[回复]
本地需要的Data空间未开放，还是需要手工转内容模型？——Sakamotosan路过围观 | 避免做作，免敬 2025年5月8日 (四) 06:21 (UTC)[回复]
Data空间必需要用共享资源那边的，页面浏览量这种目前不支持外部数据源，目前看起来除非把页面浏览量去data空间建立数据集，否则没其他办法--百無一用是書生 (☎) 2025年5月8日 (四) 11:13 (UTC)[回复]
现在图表大小和颜色等似乎还都不能自定义，而且共享资源的Data数据也没有提供链接过去方便修改--百無一用是書生 (☎) 2025年5月8日 (四) 11:18 (UTC)[回复]
不支持用lua产生数据吗? 这样{{函数图形}}就死掉了耶QQ-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2025年5月8日 (四) 11:23 (UTC)[回复]
能反馈这些问题回开发组？——Sakamotosan路过围观 | 避免做作，免敬 2025年5月8日 (四) 12:52 (UTC)[回复]

模板:Normdaten

看到一个有趣的bug，这明明是模板页面，显示标题却是没有“模板:”的“Normdaten”，不知道是怎么回事？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月6日 (二) 20:34 (UTC)[回复]

好像是{{德语重定向}}的问题。--Miyakoo（留言） 2025年5月6日 (二) 23:04 (UTC)[回复]
准确来说，是{{非中文重定向/template}}。--Hamish T 2025年5月7日 (三) 01:05 (UTC)[回复]

合并分类重新导向设定

今天难得合并一个分类的所有修订版本（见此处），发现系统目前仍然会给原本的页面设定普通重新导向，而非如移动操作般改用分类重新导向模板，是否能够修改此类设定？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月7日 (三) 08:54 (UTC)[回复]

评级页面分类问题

目前似乎所有条目都会分类到“重新导向级条目”，而非条目会分类到“重新导向级页面”（如日本、香港、铁道等专题）；两者实应予以统一，以免造成混乱。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月7日 (三) 09:35 (UTC)[回复]

还有非条目级也是；其他不属于条目的评级，可能亦有这类问题，需要一并清查。无论如何，至少要确定“条目”或“页面”择一。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月7日 (三) 09:36 (UTC)[回复]

翻译文章模板爆开

如Special:Diff/87165735或是Special:Diff/85455404，我在翻译完文章后常出现引用或是绿连爆开的情形（尤其是在翻译时复制贴上），该如何处理？--Kanshui0943（留言） 2025年5月8日 (四) 15:24 (UTC)[回复]

求助

福州地图区划模块问题

本主题或以下段落文字，在讨论结束后应存档至Talk:平潭综合实验区。

我这几天去看了一眼地图发现不对：[6]，为何现在的福州少了平潭？应该紧急修正回去。--御坂雪奈󠄁 2025年4月24日 (四) 07:05 (UTC)[回复]

需要在OpenStreetMap上修改。近日有人把平潭综合实验区改为福建省的subarea。--Kcx36（留言） 2025年4月24日 (四) 11:12 (UTC)[回复]
那这个要怎么修改呢？阁下会搞吗？本人不会搞😭--御坂雪奈󠄁 2025年4月24日 (四) 11:16 (UTC)[回复]
我可以改，但我不清楚怎么改是对的，建议去OSM中国telegram群组或者QQ群（290278518）反映。--Kcx36（留言） 2025年4月24日 (四) 11:22 (UTC)[回复]
只需把平潭县的范围划给福州市就行（或者他们有没有回退功能回退就行）--御坂雪奈󠄁 2025年4月24日 (四) 11:25 (UTC)[回复]
我咨询了OpenStreetMap比较资深的行政区划编者，他作如此答复： 实验区与平潭县政区合一，不应视为平潭县上级。但实验区名字似乎没有合适的表示方法 （参考资料：https://t.me/osmchina/1/161346 ）--蕰川｜公路 2025年4月26日 (六) 09:35 (UTC)[回复]
我是在OpenStreetMap中将平潭县关系移除自福州市关系的用户。
我创建的变更集165267985的全部变更内容包括：
  1. 福州市关系移除平潭边界，以福清-平潭、长乐-平潭界为准
  2. 移除平潭县关系的admin_centre节点，移动平潭县标注至县政府驻地，补充简称
  3. 修改潭城镇人民政府为海坛街道办事处，移动海坛街道标注至街道办驻点，将其作为新的admin_centre
  4. 首次创建平潭综合实验区关系，挂为福建省的subarea
  5. 将平潭县关系移除自福州市关系，挂为平潭综合实验区关系的subarea
  6. 首次创建平潭综合实验区标注，位于金井湾商务营运中心，并设为平潭综合实验区关系的label，在Carto渲染的地图缩放级别为11-14可见。修改实验区管委会大楼和金井湾商务营运中心，创建国旗旗杆节点
根据OpenStreetMap的绘制规则，边界以实际情况为准，实际情况包括合法与争议边界。例如：
青藏界明显不同于法定界线
保定市不包括雄安新区
上海市包括江苏和安徽的部分区域
珠海市不包括横琴粤澳深度合作区
汕尾市不包括深汕特别合作区
我根据实际管辖情况做出将平潭移除自福州的绘制操作。当前阶段平潭县为福州市下辖的法理行政单位，但自2013年起不属福州市管辖，福建省直接管辖平潭综合实验区。
在福州市国土空间总体规划（2021-2035）公众版的封面地图中，福州市海域界线由已确定的福州-宁德，长乐-平潭，福清-平潭、秀屿、涵江海域界和在领海基线的基础上向外延伸12海里的线组成。平潭县不在界线内并被使用第三种颜色标注。
目前OpenStreetMap的平潭范围被其他用户重新划入福州市。
希望能与阁下共同讨论相关问题。--蕉饼（留言） 2025年4月27日 (日) 00:48 (UTC)[回复]
@蕉饼：
  • 依敝人之见，平潭综合实验区属于经济实验区，不涉及政治，即使管理委员会是地厅级（与福州市平级），也不能把平潭作为县从福州划出去，平潭作为县的历史并没有结束，之前在平潭综合实验区是否要与平潭县合并的争论中我也举出了一些论据证明“县”这一级行政区划并没有消失，我认为只有当中国国务院正式批准了平潭县升格为地级行政单位、并废除“平潭县”这一行政区划时，才可以把它从福州市划出去；
  • 从阁下提供的资料来看，虽然福州市的领海已经把平潭分出去了，但文件上关于市域的论述都在强调“不含平潭综合实验区”，也就是说平潭虽然被福建省单独管理，但并没有彻底从福州脱离出去，福州只有在强调了“不含平潭”的前提下才进行了此番划定，说明平潭并不能算是完全独立的subarea；
  • 关于阁下提到的其他例子，青藏高原的边境线尊重事实论据本来就是正确的，这才符合实际情况，但用这个例子来论证中国大陆内部的情况显然是不合理的；除了上海市之外（因为上海市辖的这些被江苏、安徽包围的土地是正式划给上海的，类似的例子包括北京朝阳区下辖的飞地首都机场街道），其他的情况我是均不认同其改动的，这些区并没有真正脱离地级行政区的范畴，只是行政单位比较特殊而已，并不能以“事实论据”来论述这些地区脱离了原本行政区划的范畴，与之相反的例子有天津市滨海新区、上海市浦东新区，这些“新区”正式落地为行政区划后，才能在行政区划的地图中得以实际的表现，在这里用事实论述的话，用维基百科的话说，可以算是有“原创研究”的嫌疑了；
  • 至于如何解决问题，我站在维基编者的角度提供一个思路，就是让这些并未正式成为“行政区划”的“新区”单独划区，以平潭为例，平潭县和平潭综合实验区的范围完全等同，但为两个不同的概念，平潭县仍然为福州市的一部分，平潭综合实验区虽为省辖，但也不应该成为subarea，只是一个经济性质的实验区。由于不清楚技术细节，所以若有什么操作上的问题敬请指出。
--—동방성신✍️ 2025年4月27日 (日) 05:58 (UTC)[回复]
感谢阁下的回复
关于“平潭县”的地图表示，我并没有删除或弃用既有的平潭县关系。实际上，我将“平潭县”作为“平潭综合实验区”的子关系（即关系的subarea成员）表示。隶属关系是“中国-福建省-平潭综合实验区-平潭县”。
我并不否认平潭在名义上是作为福州市辖行政单位的“福州市平潭县”。在实际管辖层面，我个人也不支持“平潭”脱离福州市。
在OpenStreetMap的绘制中，西藏自治区不仅是在中印、中不边境争议地区上与中国行政区划不符，自34.9052, 89.8180至32.6725, 94.6037的青海省-西藏自治区界线也与行政区划不符。OpenStreetMap用户甚至就此问题单独创建新的根据行政区划界线的西藏自治区关系。
根据OpenStreetMap的绘制规则，地图元素应表示on the ground实际情况，中国大陆的具体行政区划边界绘制可参考此日记。因此，OpenStreetMap的边界不应以名义行政区划划分，而是实际管辖情况。在OpenStreetMap数据集中，平潭理应独立于福州，理由是“福建省平潭综合实验区管理委员会”实际管辖此区域。目前OpenStreetMap绘制社区对此问题的主要争议点在于平潭的上级管辖单位问题。
历史上作为功能区的“天津滨海新区”和“上海市浦东新区”的情况与平潭不同。两个区域在当时仍被既有的上级行政单位管辖。正如其名，“天津滨海新区”由“天津”管辖，“上海市浦东新区”由“上海市”管辖。因此理论上仅需绘制出该功能区范围即可。“平潭综合实验区”在成立初期被命名为“福州（平潭）综合实验区”，且由福州管辖。后期被更名为“福建省平潭综合实验区”，并由福建省直接管辖。因此平潭综合实验区不仅仅是类似于转化为行政区前的滨海新区/浦东新区的经济实验区，其在行政管辖上也与滨海新区/浦东新区不同。
在OpenStreetMap将“平潭综合实验区”分离自福州市的这类做法并非首例。正如我先前提到的，雄安新区、横琴粤澳深度合作区、深汕特别合作区在表示时也独立于其隶属之地级行政区——地级行政区的关系边界不包括这些区域；这些区域不作为地级行政区关系的subarea。作为补充，名义上属于广东省的深圳湾口岸香港方面关口与澳门大学在OpenStreetMap中也被划入两个特别行政区的范围，这些表示均符合OpenStreetMap的绘制规则。
提及《福州市国土空间总体规划（2021-2035）公众版》并不是为了证明平潭在名义上不属于福州（这不是事实），而是为了证明福州市不管辖平潭区域以及展示OpenStreetMap福州市关系的边界的理想形态。
感谢阁下对相关问题的关注。--蕉饼（留言） 2025年4月27日 (日) 08:10 (UTC)[回复]
@蕉饼如果按阁下的说法，那么杨凌示范区甚至应该独立出陕西省，有自己的“省界”对吧？那么乌东四州有关被占地区就理应“划入俄罗斯”对吧？--Liuxinyu970226（留言） 2025年4月29日 (二) 03:57 (UTC)[回复]
关于功能区管辖级别与省级同级的表示问题，OpenStreetMap中国大陆并无相关先例。我认为没人会想到/没人会想创造先例。这则关于“平潭分离自福州”的讨论的存在原因正是因为一个原先行政区划与实际管辖不符的区域没有特殊绘制，但在近期被特殊绘制。这说明有一部分没被特殊处理的此类区域在OpenStreetMap是依旧存在的，因此我对于像“杨凌示范区”这种功能区没有单独绘制并不意外。一个在管辖层面上独立于其法理上级行政单位的功能区没有被特殊绘制并不能说明什么，但但凡有任意一个在管辖层面上独立于其法理上级行政单位的功能区被特殊绘制，且这种特殊绘制的操作被绘制社区承认，其他的功能区就应根据这种规则绘制。因此我不认为我的绘制操作存在任何问题。
关于乌东地区在OpenStreetMap上的隶属问题，OpenStreetMap的规则是不对战争进行中的地图以当前战线绘制边界。关于克里米亚地区在地图上同时隶属于乌克兰与俄罗斯国界，这是因为DWG是这么决定的。在规则与DWG之间，DWG显然更高一级。先前克里米亚被完全划分给俄罗斯引发了大型争议，克里米亚重新被划分得同时隶属两国也有社区反对的原因。我个人反对在OpenStreetMap地图上将克里米亚划分给乌克兰。--蕉饼（留言） 2025年4月29日 (二) 05:22 (UTC)[回复]
理论上维基百科的静态地图也应该按此惯例。现在维基媒体的乌克兰地图都用当前实际战线的版本，我觉得也许不是很妥当，应该用2014-2022年期间的版本。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年4月29日 (二) 06:01 (UTC)[回复]
一、功能区≠行政区划。二、在古迹文物的定级方面，仍存有县级，除非它像长乐区一样全部撤销替换，那才算实际脱离出去福州。三、在现行出版的官方地图区划中，无论是省[7]还是市[8]，都是在福州市的范围之内，甚至在省地图中，与福州都是一个颜色。如果真的脱离所谓的“福州市”，那么应当实际情况是与福州市不应该是一个颜色。四、按阁下讲的：汕尾市不包括深汕特别合作区，所以这就是直接把一个功能区划给深圳市控制的借口吗？[9]。把一个省级的功能区给了深圳？什么文件讲的？四、没有正式的通知文件讲平潭彻彻底底脱离福州之前，均不能算作已脱离福州之。再举个例子，我有几套大厝，但我大厝太多了懒得打理，就叫了别人来管理我的部分大厝。那请问，我暂时给别人打理的这几套大厝就是他们了吗？就因为在管理这几套大厝的人不是我在管理吗？--御坂雪奈󠄁 2025年4月27日 (日) 11:50 (UTC)[回复]
我可能重要的部分没有着重强调，在此简单概括：
  1. “平潭”在名义上的确是“福州市平潭县”，是福州的下辖单位。
  2. 若名义边界与实际管辖边界不符，根据OpenStreetMap的绘制规则，"boundary=administrative"线和关系以实际管辖界表示，不表示名义行政区划界。先前提到了，西藏自治区被单独创建出不被渲染的名义边界关系，"boundary=legal"标签首次在中国大陆被运用，可使用此类边界绘制名义行政区界线。
在OpenStreetMap中将“平潭”分离自“福州”并不代表现实中“平潭”完全脱离自“福州”。
关于深汕特别合作区属深圳的问题，我未曾参与过相关绘制。相关政策可参考《关于深汕特别合作区体制机制调整方案的批复》，亦可询问首次将深汕特别合作区边界加入深圳市关系的变更集125104477的发布者和首次将深汕特别合作区关系作为深圳市关系subarea成员的变更集80479569的发布者。
OpenStreetMap边界表示实际管辖情况的这一绘制规则避免了因争议导致的不好现象。我在隔壁县罗源有几间大厝，交给几个罗源人打理。结果这群罗源表看见我的所有势力都只影响得到连江，就动用他们的当地势力把我其中的几间厝强占了，并宣称我在罗源的所有大厝都是他们的。这种情况下争议会从现实延伸到地图表示。为了避免争议使得地图表示摇摆不定，地图社区制定绘制规则，一切以实际管辖情况为主。有了这个绘制规则，就算这几个罗源人安分守己地只打理我厝，地图也会沿用以实际管辖情况表示的这一绘制规则，不会对没有争议但管辖状态与法理状态不同就制定新的绘制规则。--蕉饼（留言） 2025年4月27日 (日) 18:16 (UTC)[回复]
但是阁下还是把平潭界限给全部画出了福州市，这是不争的事实。目前也没有实际文件证明平潭已经彻底脱离福州市（官方地图就是充分的证据），阁下所谓统计数据和规划图以及领导层不能作为直接证据，证明平潭是已经属于独立于福州市的状态。故应该平潭还是不得划出福州市，原因很简单，就是因为没有彻底脱离福州市，故地图上还是要显示平潭在福州。如阁下还认为平潭应该要出于福州，那就在维基这里进行投票表决吧。--御坂雪奈󠄁 2025年4月28日 (一) 15:23 (UTC)[回复]
先提醒一下楼上，维基百科讲共识，不点票数。我个人的意见是在此使用这般“事实论述”或许反倒争议更大，个人认为，以本国行政区划为准，相对于编辑者自行根据各种现象判断的“事实论述”来说，会更少一些争议。我并不清楚osm那边的社群是如何处理争议的，但毕竟它作为直观感受极强的地图，在维基百科中会成为条目的重要部分，所以作为维基百科用户，自然是希望osm这边在处理此类问题的时候照顾到维基百科这边的争议的，在维基百科《福州市》条目中，若不把平潭划入福州市范围，就会给读者以“平潭已经不属于福州”的错觉，所以我认为地图确实应该有所调整。如果osm能做到在福州市中把平潭地区作特殊标注处理后留在福州市管辖范围内，则个人认为相较于直接删除这段边界会更为合理一些。--—동방성신✍️ 2025年4月28日 (一) 15:34 (UTC)[回复]
关于《福州市》的地图问题，其实条目里面既有OSM地图亦有静态地图，只需要将OSM地图的caption标注“未包括平潭县”即可。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年4月28日 (一) 19:58 (UTC)[回复]
OSM大陆区处理争议的方式就是第二天继续各自画各自的，除非不可调和否则就搁置争议摆了，继续画，只要大体上还在理不算很离谱的都还能忍一忍，因为中国很大，目前来说一定要说和wp习惯一样搞投票投出来什么共识，可以说是一次都没有，仅有的一次还是几年前公共交通命名的一次投票，结果是所有选项全是1票（你可以想象到是发生什么了），但并不代表就是完全散乱的。不能用Wikipedia这边事事一定要有完整的流程正义的原则去要求OSM的共识形成，以及OSM就是人很少，每个人能精通的领域非常有限，很多时候搞大投票也不清楚。OSM跳出国服看向全球社区来看也有投票，但投的也多是新标签能不能创设之类的话题。
此外我想明确的是，无论最终结局是什么，OSM上的编辑不应也不会因为要照顾Wikipedia上的任何效果或者利用方式去编辑，只是wikipedia选择依赖这个较为可靠的外部数据来源。就酱。--是可爱的鼠宝宝 | 我要留言,我现在就要留言 2025年4月29日 (二) 07:13 (UTC)[回复]
对于这两次我做出的有争议的编辑，我不认为这些争议被类似于阁下提到的方式处理。事实上，两个争议在后期都被进行了修改。先前的双向道路问题，有些用户“表面一套背后一套”，人前对相关争议进行友好交流，人后在OSMChina社区大肆批判这些编辑，我认为这是不能被接受的。这两次事件的相关问题均是我原以为是毫无争议的。且对于这些编辑的讨论均始于其他用户。所以，我认为这顶挑起争议的帽子不应当戴在我这里。--蕉饼（留言） 2025年4月29日 (二) 07:42 (UTC)[回复]
啊您先提到了双线问题啊，很遗憾相关讨论我应该是一场没漏下，我觉得当有不止一位编辑者指责您这么编辑双线不合理的时候，您应该意识到显然您的绘图习惯猜是并非主流的，未被广泛使用的。此外，友好交流和大肆批判并不冲突，友好是态度上的友好，批判则就是针对画在图上的内容。正如Wikipedia天天一口一个阁下也无法掩盖唇枪舌剑的事实一样。--是可爱的鼠宝宝 | 我要留言,我现在就要留言 2025年4月29日 (二) 07:47 (UTC)[回复]
我并不认为社区用户在涉及相关问题的交流时的态度属于友好，这包括使用我个人不接受的称呼，在社区内直接公布我居住的城市，使用不恰当的语言评价我的编辑（如“麻痹依托”）等。
至少我是真心实意想要与其他用户友好交流的。就算社区内的用户是真正的通过友好交流批判编辑行为，也应当在我本人得知的情况下。很明显，OSMChina社区的部分用户是故意不想让我得知对话内容的，在背后议论其他用户也是OSMChina社区的价值观之一吗？--蕉饼（留言） 2025年4月29日 (二) 08:17 (UTC)[回复]
第一，什么是背后议论？那是否可以认为你在Discord的发言也是一种背后议论呢？是否可以认为在很少有人知道的个人博客小平台的发文也是一种背后议论呢？此外就OSM相关的若干交流渠道而言，其活跃度可谓公共广场了（talk-cn邮件列表也好，community站也好，这些其实基本都没人用，是的，就是没人用，osmwiki上也不是做日常交流的所以要求人一定要在osmwiki上找到什么非常强人所难了）
第二，OSM是和本地经验非常相关的，涉及编辑者和具体城市之间的讨论是不可避免的。此外您在您的OSM用户的个人主页里便已经写明了您是福州人某社区的居民，这是自己先盒自己。
当然部分语言不够文明这件事确实涉及个人素质问题，但这不是主要论点，不能掩盖你顾左右而言他罔顾事实。--是可爱的鼠宝宝 | 我要留言,我现在就要留言 2025年4月29日 (二) 08:27 (UTC)[回复]
此外既然您先前有提到您的大作文一篇，那我觉得您去把其他编辑者的所有编辑全部review一遍（其中包括部分已经在后续逐步改善过的内容）全都拿出来说一遍，这应该也是未在其本人得知的情况下公布其过往历史了。--是可爱的鼠宝宝 | 我要留言,我现在就要留言 2025年4月29日 (二) 08:34 (UTC)[回复]
对方如此点名道姓的批判我的编辑，我只是做了相同的事。
我很确定对方是第一个看到这篇文章的人，我不认为这存在“未在其本人得知”的情况。--蕉饼（留言） 2025年4月29日 (二) 08:48 (UTC)[回复]
我在Discord服务器中仅对案例进行讨论，我从未提及任何用户的昵称吧？
我只将文章的链接发布于一个变更集中，有任何人查看变更集内容才能得知这个链接。说白了链接就是我专门给对面用户看的，链接传播与不被传播的决定权在于对方。事实证明他决定传播链接。
在OSMChina Telegram挂我的个人链接，在我发表这则文章后又疑似将链接转发QQ群组，这是不是一种议论？
我在简介里写明的是我曾经是东南街社区的居民。另外，以“小孩哥也在🇨🇦（YVR）😆”这种评论方式公布我居住的城市，您认为这合理吗？--蕉饼（留言） 2025年4月29日 (二) 08:44 (UTC)[回复]
第一是我不能为其他人的言论负责，而且个人素质问题不是这里主要的论点，此外您亦是全程以“多伦多用户”来特指和您意见冲突的用户（而意见冲突不够激烈的用户则是记载全名，颇有讽刺的意味），您认为这是否是也公布了其他人的城市（多伦多）呢？--是可爱的鼠宝宝 | 我要留言,我现在就要留言 2025年4月29日 (二) 08:49 (UTC)[回复]
第二您先前提及了OSMChina社区是如何“友好的批判”相关问题的，且进行了佐证。我在编纂文章时就决定如此称呼对方，原因和为什么我会这么做我先前提到了。--蕉饼（留言） 2025年4月29日 (二) 08:59 (UTC)[回复]
在OpenStreetMap将平潭移除自福州的操作是根据OpenStreetMap的相关规则和既有案例，以实际管辖界为准，并非全由个人意志做出的决定。我未曾表示平潭完全独立于福州，甚至在先前的留言中强调平潭在名义上属于福州，为“福州市平潭县”。引用自先前的留言，“提及《福州市国土空间总体规划（2021-2035）公众版》并不是为了证明平潭在名义上不属于福州（这不是事实），而是为了证明福州市不管辖平潭区域以及展示OpenStreetMap福州市关系的边界的理想形态。”
我注意到在维基百科中，保定市，深圳市，汕尾市等引用OpenStreetMap边界关系数据的范围均与名义行政区划（官方地图）不符。相同的绘制问题在这些地区似乎并无争议。我不认为不应对平潭地区进行相关修改使其地图表达与中国大陆其他地区相符。
个人认为OpenStreetMap绘制的相关问题不应通过维基百科决定，OpenStreetMap不附属于维基百科。--蕉饼（留言） 2025年4月28日 (一) 17:38 (UTC)[回复]
阁下讲是提及《福州市国土空间总体规划（2021-2035）公众版》并不是为了证明平潭在名义上不属于福州（这不是事实），实际上又却多次证明所谓的“平潭不属于福州管”，已经人尽皆知。不限于利用：领导层、各地方城市，以及利用偷换概念后的“大厝论”来证明自己的正当行为。且我设定下的“大厝论”，前提是基于几套大厝在同一片地区的情况下，而阁下所谓的“大厝论”实则是烟雾弹，混淆视听，是恶意解读我的论点，把一处地方的多座大厝，恶意解读为不是一个地区的多处大厝。如果真要证明阁下所谓的观点平潭不归福州管，且地图上也没有平潭之范围是对的话，请阁下应当拿出正式的文件以及文件编号，像长乐区一样有正式的文件：国务院关于同意福建省调整福州市部分行政区划的批复 国函〔2017〕103号，而不是利用一些不限于统计数据等这些对实际范围情况毫无意义的论点，这是偏信则暗。如果一味的借用所谓的平潭综合实验区来独立出于福州地图，这是极为不正确的，且即使不是官方出版的地图，在网上搜到的绝大部分有关福州的地图，都会带上平潭。谢谢。--御坂雪奈󠄁 2025年4月28日 (一) 19:43 (UTC)[回复]
关于平潭的归属问题，我想我在先前的留言内容中早已解释清楚。法理上、名义上、行政区划中的平潭属于福州；实际管辖情况下的平潭独立于福州。这是两个概念，且互不冲突。我先前所有关于平潭独立于福州的言论均指向后者（实际管辖情况）。
关于我基于阁下的“大厝论”发表的内容属“偷换概念”的陈述：内容中的“厝”，“打理厝的人”和“拥有厝的人”均继承自阁下的所谓“大厝论”。若原“大厝论”不存在“偷换概念”，在此基础拓展的内容何来“偷换概念”的说法？既然这只是基于原先版本的拓展，并无任何解读行为，又何谈“恶意解读”？我表达的是“在隔壁县罗源有几间大厝”，自始至终我描述的所有大厝均在“罗源”，“罗源”是1个地点，基于此，以“不是一个地区的多处大厝”描述我的这部分内容的陈述又如何成立？就算成立，这又怎能对这则内容要表达的意思产生任何变化，又如何构成“恶意解读”？
“平潭”在OpenStreetMap中的地图表达是否应脱离“福州”与卧室墙壁上挂着的“福建省地图”中的“平潭”和“福州其他部分”是否使用同一种颜色填充没有任何关联性。若OpenStreetMap地图应与其他地图边界保持一致，而不是根据OpenStreetMap相关规则与既有案例，我可以立即发表一份以福州市人民政府下辖机构管理范围为主的地图。
关于阁下提到的我引用其他市边界的绘制方法以佐证平潭不受福州管辖：抛开“‘引用’和‘佐证’这两个行为是如何被阁下联系在一起的”这件事不谈，仅考虑“其他市边界的绘制方法”，若阁下可回退这些市边界关系使其边界与名义行政区边界相同，我则会完全支持“OpenStreetMap中福州市关系边界应包括平潭”的陈述。--蕉饼（留言） 2025年4月28日 (一) 23:31 (UTC)[回复]
@蕉饼“这是两个概念，且互不冲突。”？！现在的事实反而是阁下在恶意解读行政区划这个概念而不是我们做错了什么，最起码中的最起码，清河农场可否从北京市关系中取消？毕竟已经在回归谈判了，连黑龙江双河农场都归还了，愣是要刻意体现清河农场是几个意思？？？？？？？？？？...（65535个？）--Liuxinyu970226（留言） 2025年4月29日 (二) 04:02 (UTC)[回复]
请问对我的言论的评价是如何从“恶意解读所谓‘大厝论’”上升到“恶意解读行政区划...概念”的？“法理上、名义上、行政区划中的平潭属于福州；实际管辖情况下的平潭独立于福州”这句话莫非不是事实？对于客观事实的陈述何来“恶意解读”这一说法？我基于OpenStreetMap既有绘制案例处理平潭关系的边界和隶属问题，我不认为这个操作有任何不妥（引用自阁下的留言，我认为“不是我...做错了什么”）。我未曾参与将清河农场编入北京市边界关系的编辑。阁下也提到了该区域正在“回归谈判”阶段，这说明现阶段清河农场由北京管辖？相关操作为何不能待到实际脱离北京管辖之日再执行？--蕉饼（留言） 2025年4月29日 (二) 05:34 (UTC)[回复]
(＊)提醒@蕉饼如果我没记错的话，目前这个地方从编制角度上讲应该是天津未来科技城的一个片区吧？自己在干恶意解读事实性内容，却也同时指责他人“恶意解读”阁下，英维上一个敢这么干的R某（6个字母，我不想指名道姓）已经被永久禁止编辑项目空间及其讨论页了。--Liuxinyu970226（留言） 2025年4月29日 (二) 06:00 (UTC)[回复]
在这里主要讨论的是OSM绘制的问题，我想威胁封禁他应该是没有任何作用。还有，第一个用“恶意”一词的也不是他。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年4月29日 (二) 06:04 (UTC)[回复]
这位蕉饼朋友对OSM社区的部分评价，个人以为实在是过于避重就轻了。在zhwiki是如何行事我很难评价，毕竟我在zhwiki（即使算上隔壁不可说的某站）确实也不算很活跃，但在OSM上来看，如果OSM社区也要按照蕉饼朋友的逻辑搞大辩论，OSM基本可以说是就地解散就好了。因为OSM并非和wikipedia一样，有非常完善的可以指引各种行为的法规判例，OSM更多的是基于十条原则的延申，总的来说明明是更有包容性的，我很期望看到蕉饼朋友指出其援引的具体规范。--是可爱的鼠宝宝 | 我要留言,我现在就要留言 2025年4月29日 (二) 07:04 (UTC)[回复]
此外另有一点比较忍不住说的就是，这到底是zhwiki还是osmwiki还是discord osm intl还是osmchina tg群还是什么地方……给我干哪儿来了这是……--是可爱的鼠宝宝 | 我要留言,我现在就要留言 2025年4月29日 (二) 07:17 (UTC)[回复]
其实是有先例（？）的…… ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年4月29日 (二) 07:56 (UTC)[回复]
充分理解阁下对相关问题的担忧。
在此对话中，我并不认为我有回避主要论点。
对于现在与过去几周的辩论行为，我感到抱歉，但这次的讨论演变成辩论实际上是我没有预料到的。
我个人做出的正常编辑在社区内被评价为错误且不合理的。我不曾认为这些编辑是错误的，因此，我需要为我做出编辑正名。--蕉饼（留言） 2025年4月29日 (二) 07:31 (UTC)[回复]
首先OSM中很难有明确的说是否正确或错误的方式，其次我理解OSM确实存在“just to fix it”的指导原则存在，但如果不断的有您的编辑被修正的事情发生，那说明有不止一位其他编辑者认为您的编辑才是不够妥当的，那么这时候我觉得更应该认真考虑沟通的是您，而不是只是想着“我如何正名”。
因为对现实世界的抽象方法确实就是会有很多种不同的角度，直接指定谁是正确错误确实有钦点的嫌疑，因此准确来说，您或者修正您的编辑的人里面，在这一系列编辑中，确实会有“不被广泛使用”的做法存在。而出现这种情况，我觉得您还是应该尽可能多听听其他OSM编辑者的意见——正如今天在Wikipedia上这轮牵扯进这么多人的大讨论来一样。--是可爱的鼠宝宝 | 我要留言,我现在就要留言 2025年4月29日 (二) 07:38 (UTC)[回复]
此外，OSM在其他社区中我确实不是很了解，但在中国社区里，是比较排斥将小事扩大化引起更多争议的，除非引发难以调和的矛盾，而您所说的您觉得有冤屈的这些编辑呢，我只见到过一些顾左右而言他的不牵扯实际论点的辩解。（因为这里是wikipedia所以我就不牵扯过多涉及站外同一人的具体描述了，不然我觉得说下去就要违规了，个人信息的帽子要戴上了）--是可爱的鼠宝宝 | 我要留言,我现在就要留言 2025年4月29日 (二) 07:42 (UTC)[回复]
正是因为我在思考了我的编辑是否存在任何错误，确定我的编辑不存在任何不合理性，我才发表相关内容以正名这些编辑。例如先前的双向道路问题，黄实线一律绘制为双向这个理论在逻辑上不成立。自从我发表了《关于我在开放街道地图中将福州道路双向路径合并的解释》后，我没有发现有对这上面的内容产生的任何质疑言论。--蕉饼（留言） 2025年4月29日 (二) 08:03 (UTC)[回复]
真的吗？那么文章在哪里呢(发出来让维基众欣赏一下啊)？以及您文章仅能表达您个人的一面观点，您还是无法回答我的问题，是否是有很多其他编辑者对您强制单线的做法表示不满呢？他们就不具备合理性了吗？您既然一边又说共识，一边又只说明“我是正确的我没错”，那我认为这就是无效沟通。
我随手引述几例对您编辑的指责：
> https://t.me/osmchina/93421/158434
> 一个数据集怎么也应该是逻辑优先，它这个直接无视一切行车上的逻辑，形而上学拉满了
> https://t.me/osmchina/93421/158344
> 我算是原教旨物理隔离双线论支持者，但是这个明显是路口的临时不隔离，按照wiki也不应该在这里单线化……
此外您一直以来声称的“根据道路流量划分”，这个，反而才可能是违反了您坚持的OSM原则的观点，您反而明确表达了您是基于这一点来编辑的。这是很难去复现和查询观察的，道路流量即使在一天之类也会有不同的时间段。OSM要求具有一定的verifiable性。我不认为道路流量是易于验证的。或者说如果要画道路需要做非常多的额外查询工作，这也是不利于OSM编辑的。
（很遗憾在这里扯了很多关于OSM而非Wikipedia有关的内容，但这的确是少有的能和当事人蕉饼沟通到的机会）--是可爱的鼠宝宝 | 我要留言,我现在就要留言 2025年4月29日 (二) 08:17 (UTC)[回复]
您在引用评论时似乎特意“避重就轻”，不引用那些带有人身攻击的评价和刻意引导的评论。
在文章被引进（我只在一个变更集中附上了文章的链接，这个链接是如何被传播的呢？）OSMChina Telegram后，我能明显的察觉对于我的编辑的合理性的评价不再是清一色的批判。
以及，这里提到的“共识”是哪个的共识？
关于道路等级问题，我想道路等级本身就是主观的。根据道路流量的意思是根据流量的差距区分两条路的等级。例如在一个十字路口中，纵路明显会比横路的流量多，对于纵路亮的绿灯时间明显会更久。如果这般也能违反原则，那我想所有的编辑都是违反原则的。--蕉饼（留言） 2025年4月29日 (二) 08:32 (UTC)[回复]
友情提示，这个群进入OSM相关群聊，在Telegram侧仅有一次，但在其他平台如QQ等并非只有一次，而且您在变更集中附上过链接，那么关注特定区域变更集或者查看最新comment（而且当然也可以查阅某个用户名下所有发言），有 https://resultmaps.neis-one.org/ 之类工具，它当然是可以被人看到的，为什么不能被传播到Telegram群中？
而个人素质问题上呢您鼠小姐我可能确实做的不太文明，甚至非常粗鄙，哎呀这个确实非常抱歉呀，不过是为什么会变成这样的呢？--是可爱的鼠宝宝 | 我要留言,我现在就要留言 2025年4月29日 (二) 08:42 (UTC)[回复]
先前提到了，作为一段时间内福州仅有的两个活跃用户，对方是会先行看到这篇文章的。且就算我被认为是未经对方许可公布其编辑历史，我也不认为通过相同的方式解决问题有任何不妥。--蕉饼（留言） 2025年4月29日 (二) 08:54 (UTC)[回复]
道路等级的问题，道路等级可以是主观的也可以是客观的，隔壁日本就是用的车道一刀切的方式，但中国没有用，因为中国东西南北基建水平差异是非常大的，西部可能整体基建水平偏低，而政府公开文件中关于道路等级的规划也有各自的特点，因此不宜一刀切，但仍应考虑实际可观测到的基建水平。如果你是要讨论highway这个key后面是primary还是secondary之类哪个value合适，那么osmwiki也有很多例图可供参考。--是可爱的鼠宝宝 | 我要留言,我现在就要留言 2025年4月29日 (二) 08:45 (UTC)[回复]
关于OpenStreetMap中福州市与“平潭”（包括综合实验区和县）的隶属问题的讨论，我感到莫名其妙：
  1. 这个OpenStreetMap的绘制问题被放在维基百科讨论？
  2. 维基百科用户认为我的两段不存在任何解读性质的言论属于“恶意解读”？并称“我指责他人‘恶意解读’”？我不知道我有指责其他人的这回事？
  3. 我在维基百科仅编辑过《中华人民共和国铁路特等站列表》条目中的福州南站部分（加入新站台后的车站规模的微型修改）和我个人的用户页，就这些编辑操作在维基百科足以将我与一个我不认识的被永久禁止的用户挂钩？
  4. 我在举例的时候并没有提及北京和天津，为何阁下如此热衷于质问我关于OpenStreetMap中北京和天津的边界问题？
--蕉饼（留言） 2025年4月29日 (二) 07:17 (UTC)[回复]
> 1. 这个OpenStreetMap的绘制问题被放在维基百科讨论？
是啊，为什么呢？那我问你，那要不要试着在一个能找到更多来自中国的osm编辑者的地方去试着讨论呢？然而并没有看到您有这方面的努力尝试。--是可爱的鼠宝宝 | 我要留言,我现在就要留言 2025年4月29日 (二) 07:19 (UTC)[回复]
最初发表在互助客栈的“头留言”并不由我发表，我在此留言也仅仅是希望其他用户能理解我的编辑行为。但维基百科用户似乎不明白我在留言中都说了什么，例如名义与实际管辖的问题我先前强调了很多次，这些都是我未曾预计到的。--蕉饼（留言） 2025年4月29日 (二) 07:46 (UTC)[回复]
那请问：西咸新区作为一个也是和阁下讲的一样的，由省（中国（陕西）自由贸易试验区）派出人员进行管理（西咸新区公安局正式成立 下设5个新城公安分局），但在OSM的实际操作中，怎么就还是在西安市了呢？[10]--御坂雪奈󠄁 2025年4月29日 (二) 07:03 (UTC)[回复]
这个至今也是一团糊涂账（非常头疼），说实话在OSM里是不太想进行详细的辩经去区分的，毕竟这种区划全国也没多少--是可爱的鼠宝宝 | 我要留言,我现在就要留言 2025年4月29日 (二) 07:05 (UTC)[回复]
先前在留言中的提到的部分内容完全适用于回答此问题。
“这则关于‘平潭分离自福州’的讨论的存在原因正是因为一个原先行政区划与实际管辖不符的区域没有特殊绘制，但在近期被特殊绘制。这说明有一部分没被特殊处理的此类区域在OpenStreetMap是依旧存在的，因此我对于像‘杨凌示范区’[中国（陕西）自由贸易试验区的一部分]这种功能区没有单独绘制并不意外。一个在管辖层面上独立于其法理上级行政单位的功能区没有被特殊绘制并不能说明什么，但但凡有任意一个在管辖层面上独立于其法理上级行政单位的功能区被特殊绘制，且这种特殊绘制的操作被绘制社区承认，其他的功能区就应根据这种规则绘制。”--蕉饼（留言） 2025年4月29日 (二) 07:21 (UTC)[回复]
好了开始了，当真要举例其他城市例子的时候，第一次是先讲的是：我未曾参与过相关绘制。，然后现在又开始讲：一个在管辖层面上独立于其法理上级行政单位的功能区没有被特殊绘制并不能说明什么。要不要看看是谁先开始用其他城市作为论证的？我就不言而喻了吧？阁下能用那我也能用。--御坂雪奈󠄁 2025年4月29日 (二) 07:26 (UTC)[回复]
阁下应当留意留言内容。对方用户提及的其他城市的例子（北京与天津的行政区划问题）并不是为了佐证，而是对我这一个不参与绘制的人员提出相关绘制问题的质疑：为什么我不把清河农场从北京关系中删除？
需要注意的是，“一个在管辖层面上独立于其法理上级行政单位的功能区没有被特殊绘制并不能说明什么，但但凡有任意一个在管辖层面上独立于其法理上级行政单位的功能区被特殊绘制，且这种特殊绘制的操作被绘制社区承认，其他的功能区就应根据这种规则绘制。”是一个连贯的句子，说白了就是：但凡其中有一个功能区在OpenStreetMap独立绘制于他的上级行政区，并且这个绘制操作被认为是对的，那么我就可以这么做；那些没有独立绘制于上级行政区的功能区我能说什么？我只能说政策实行了但没人改，正因如此这些案例并不能佐证独立于其上级行政区运作的功能区应当绘制为上级行政区的一部分。--蕉饼（留言） 2025年4月29日 (二) 07:55 (UTC)[回复]
反正阁下的结论就是：别的城市改了，那就是正确的、应当引用的论点；但有的城市还是原来那样，那就是不可用来佐证的，都给阁下双标完了。有关阁下编辑的争议，似乎也有用户开始对阁下的指责了好吧。在WP这里的有关对平潭的共识阁下也讲不过，真要到OSM那也没有用户同意阁下的修改行政区划的行为。真要论证平潭那就是已经出于福州市，那就拿出相关文件，除非像横琴那样直接官宣脱钩了的，那应该都是明白这个不属于珠海。故很显然平潭问题不是，甚至到现在都没有看到平潭方面有关任何直接官宣脱钩了的文件出来，故不算作已经脱离福州市。--御坂雪奈󠄁 2025年4月29日 (二) 08:33 (UTC)[回复]
有个问题就是，他提到的这些其他地区应该怎么处理？是否应在caption上标注不包括某地区？或者等OSM社群修改？ ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年4月29日 (二) 08:34 (UTC)[回复]
这个就以后让他们用户群体自己讨论吧，现在的问题主要还是福州界的问题。--御坂雪奈󠄁 2025年4月29日 (二) 08:37 (UTC)[回复]
而且真要论共识，现在已经很明白了，无论是WP还是OSM，均是认为平潭肯定是福州市界里。反倒是现阁下却是一意孤行，强行让两边平台用户认同自家的观点。--御坂雪奈󠄁 2025年4月29日 (二) 08:36 (UTC)[回复]
我注意到近期有另一位似乎并不清楚平潭表达争议事件的用户修改平潭隶属问题，使其边界再次不隶属于福州，这能否代表并非全部用户认为其应当划为福州界？
若我选择“一意孤行”，我不会像现在这样暂停对有争议的地图数据的修改操作（不回退）并在此讨论相关事宜。“强行让两边平台用户认同自家的观点”更是无稽之谈，若对争议问题进行讨论便是强行要求以方认同，我想世间所有意见不符的对话均是一方要求另一方认同其观点。
既然一部分功能区（例如编辑相对不活跃的陕西省下的功能区）没有来得及被修改，如何用其佐证另一部分不按照名义行政区划界线划分的区域是错误的？何以将如此简单的逻辑问题牵扯至“双标”？
维基百科的福州市词条引用OpenStreetMap的福州市关系边界，却要求OpenStreetMap地图数据依照维基百科的规则修改？阁下可以选择去除词条中引用维基媒体地图，并改为静态地图，许多城市的词条亦是如此。
我不反对维基百科中对平潭的共识中的任何陈述，但这与OpenStreetMap的编辑操作问题有任何关联性？
阁下持续性的曲解（“恶意解读”）我的相关陈述，这些我本不想点明，只是重新声明相关观点。但阁下持续将我留言中的管辖与隶属情况混淆，在多次重申此为两种概念后，直到现在仍要求我给出类似于行政区划中市改区的相关官方文件。我能否理解为阁下在要求承认平潭隶属于福州但不受其管辖的用户找出平潭不隶属于福州的相关官方文件？
据我所知，隶属于珠海市香洲区的“横琴镇”的概念正如“平潭县”，这些概念现阶段依旧存在。最近的“关于规范使用‘横琴粤澳深度合作区’名称的通告”也只是统一名称使用规范（粤港澳大湾区门户网转载的文章如此解释），并不代表其完全脱离珠海。
反正阁下的结论就是：其他城市的OpenStreetMap边界与行政区划边界不符，交给地图社区解决（约等于不解决）；相同情况下的福州市在OpenStreetMap与行政区划不符，就必须立刻被修改。都给阁下双标完了。
功能区属于其上级行政区在OpenStreetMap的表达中只能是“是”与“否”，而非一个区域比另一个区域更重要，因此前者独立，后者保持隶属关系的主观相对性问题。“平潭综合实验区”挂名于“福建省”，平潭县全境由“平潭综合实验区”管辖，我想这“是”与“否”问题的答案就显而易见了吧？我呼吁其他绘制用户将“黑区”按照行政区划绘制，这样一来我也赞成将平潭重新划入福州。--蕉饼（留言） 2025年5月3日 (六) 00:46 (UTC)[回复]
此外楼上关于不要牵扯其他城市的观点，我认为如果是要看中国的比较特殊的行政区划，还是要总体的去看“非常特殊”到“比较特殊”这种变化的。比如如果要论行政区划的独立性，那么雄安新区是不是独立出来的？横琴是不是独立出来的？平潭是不是独立出来的？它们虽然可能都是俗称的“黑区”，但它们应该不应该属于哪一个上级行政区管辖上，既然您反复言之OSM的原则，“是否存在实际控制”，那么它们这三种真的一样吗？这不是要去看真空中的球形鸡。--是可爱的鼠宝宝 | 我要留言,我现在就要留言 2025年4月29日 (二) 07:53 (UTC)[回复]

请求协助上传档案 2025-04-25 10:54

我想要上传的图片来源是轻轨规划图，想要使用在澳门轻轨的<资讯框/未来发展路线段落>。 --Zctptuc（留言） 2025年4月25日 (五) 10:54 (UTC)[回复]

请问是你画的还是你从网络找的？是你画的请上传至共享资源，是你从网络找的则请给出网址。可以的话，建议自己画，著作权比较不会有问题。--Saimmx（留言） 2025年4月28日 (一) 18:31 (UTC)[回复]

元素周期律的跨语言链接

该条目现存的跨语言链接只有两种语言，请求将之换绑至正确的链接。--Yankees from Canada 🪶 2025年4月27日 (日) 06:00 (UTC)[回复]

看起来应该要在维基数据整并 周期性趋势 (Q10889792) 和 周期性趋势 (Q2622089)--—— Matt Zhuang表示有事按“此”留言 2025年4月27日 (日) 18:47 (UTC)[回复]
还有就是周期性规律这个条目用大陆简体是没法搜到的，是不是转换上有点问题。--Yankees from Canada 🪶 2025年4月28日 (一) 04:51 (UTC)[回复]
已于wikidata合并。--伞木 霙留言 2025年4月29日 (二) 06:06 (UTC)[回复]

请求创建页面

我想将对黑种人的称呼#nigger搬到nigger，但黑名单拦住了。--惣流·明日香·兰格雷不姓式波 2025年4月29日 (二) 12:22 (UTC)[回复]

可能先等一下Wikipedia:页面存废讨论/记录/2025/04/29#对黑种人的称呼的结果。--惣流·明日香·兰格雷不姓式波 2025年4月29日 (二) 15:45 (UTC)[回复]

四灵没有显示在Category:四灵里

如题，不知道怎么回事，这里来反应下。这个那（留言） 2025年4月30日 (三) 13:28 (UTC)[回复]

现在好像解决了，先谢谢帮忙这个那（留言） 2025年5月1日 (四) 05:59 (UTC)[回复]

党卫队和親衛隊

如题。已经对编写PJ:NAZ相关条目造成一定困扰。移动端似乎憋不出重定向条目来，有没有人帮帮忙把党卫队相关条目都创建重定向页面？

举例：

etc. 可能有30—50个条目需要重定向。--KurGenera(留言) 2025年4月30日 (三) 15:37 (UTC)[回复]

请求协助上传档案 2025-05-02 09:22

我想要上传的图片来源是<https://www.ktgh.com.tw/ktgh/home / 自行截图logo>，想要使用在[[11]的<光田医疗社团法人光田综合医院logo图示及通霄光田医院logo图示/在右侧介绍栏>。 因为目前官方希望更新维基百科的资讯，但目前我的权限不足以更新照片，还请各位协助帮忙更新照片，或是能够提供我更新的方式 --Jim941（留言） 2025年5月2日 (五) 09:22 (UTC)[回复]

首先，我看目前的Logo还不错，为什么要换？再来，想自行上传非自由图片并更新的话，请通过自动确认用户（一般而言为注册后7天并编辑了50次）后更新。--Saimmx（留言） 2025年5月5日 (一) 09:19 (UTC)[回复]

特色图片评选现有1个提名，但序言的“特色图片评选”一框显示为0个提名

如题，这是那一个现有提名，请求协助改正。-- GVZpedia 2025年5月2日 (五) 13:07 (UTC)[回复]

完成：改以嵌入方式插入评选页面。--伞木 霙留言 2025年5月2日 (五) 13:26 (UTC)[回复]

2 个页面表述文字不统一, 求助

向前 页面里他的子女资料 和 新义安人物列表 页面里向前的子女资料表述文字不统一, 阅读时实在费劲, 求助--Adyu（留言） 2025年5月3日 (六) 07:12 (UTC)[回复]

请求协助上传档案 2025-05-03 08:11

我想要上传的图片来源是https://mp.weixin.qq.com/s/dlOsUYvj4TGS5wDrGraBRQ，想要使用在请提供条目名称https://zh.wikipedia.org/wiki/周集中的infobox person。

--Liusuo99（留言） 2025年5月3日 (六) 08:11 (UTC)[回复]

未完成：图片受版权保护，且在世人物图片不满足合理使用条件；另有c:File:Photo_Jizhong_Zhou.jpg，等待VRT处理。--伞木 霙留言 2025年5月3日 (六) 13:29 (UTC)[回复]

请求协助上传档案 2025-05-07 02:58

我想要上传的图片来源是俱乐部官方更新的公开文件，想要使用在[大连英博]的<俱乐部LOGO>。 --藤梓昊（留言） 2025年5月7日 (三) 02:58 (UTC)[回复]

能否提供图片来源连结？--1F616EMO（喵留言～回复请ping） 2025年5月7日 (三) 14:38 (UTC)[回复]

请求协助编辑wikidata

刚翻译的NVRAM条目，由于我使用了代理导致被封锁无法编辑,需要帮忙修改 --Emulbnhom（留言） 2025年5月7日 (三) 09:32 (UTC)[回复]

完成--夏冰 2025年5月7日 (三) 09:38 (UTC)[回复]

请求协助上传档案 2025-05-07 14:35

我想要上传的图片来源是 https://minecraftpotato.github.io/wikifile-transferstation/Babybus%20Chinese%20Logo.png ，想要使用在条目"宝宝巴士"的“公司商标”。 --MinecraftPotato（留言） 2025年5月7日 (三) 14:35 (UTC)[回复]

完成。--伞木 霙留言 2025年5月7日 (三) 15:18 (UTC)[回复]

请求协助上传档案 2025-05-08 10:34

我想要上传的图片来源是<https://www.instagram.com/edenchen0324/>，想要使用在陈峻廷的<资讯框>。 --Unperfectwing（留言） 2025年5月8日 (四) 10:34 (UTC)[回复]

Instagram的图片通常是被版权保护的，人像图片不可以使用非自由图片。--Sakurase留言 2025年5月8日 (四) 11:17 (UTC)[回复]


条目探讨

参考资料

唐五代十国、宋辽金元的皇帝谥号

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

明清皇帝的谥号都有相应的一字简谥，比如朱元璋是高皇帝，玄烨是仁皇帝。在此之前，唐五代十国宋辽金元的皇帝，他们的谥号是否也存在类似的简谥？能否直接把谥号里与“孝”字相连的部分不加说明地作为该皇帝的简谥呢？比如唐高祖李渊，是“光孝皇帝”或“唐光帝”？李世民是“广孝皇帝”或“唐广帝”？宋太祖赵匡胤，是“大孝皇帝”或“宋大帝”？条目内如果以在全谥内部分加粗的形式表示加粗部分是该皇帝简谥，又或者在行文中直接以简谥指代该皇帝，是否应该在条目内列明该简谥的文献来源？--大化国史馆从九品笔帖式（留言） 2025年4月15日 (二) 09:38 (UTC)[回复]

简谥如果存在，要列明文献来源，以免被质疑是原创研究。--欢颜展卷（留言） 2025年4月16日 (三) 17:08 (UTC)[回复]
简谥确实存在，但不像明清的简谥一样（具有明确的格式特点，官方民间都认可、都在用），而且不一定是跟“孝”字组合的字眼有关。比如唐朝，唐初诸帝本身有过一二字的谥号，在唐朝墓志中我见过沿用作简谥，比如称李世民为唐文帝、文皇帝，称李渊为太武帝、神尧帝，也有使用后来长谥号一部分作简谥的，比如称李世民为文武皇帝。前蜀开国君主王建墓出土的谥册明确称“尊谥曰神武圣文孝德明惠皇帝，庙称高祖武皇帝”，后蜀多位大臣墓志称孟知祥为“高祖文皇帝”，王建和孟知祥的简谥一武一文，是规定好的。--大化国史馆从九品笔帖式（留言） 2025年4月16日 (三) 18:28 (UTC)[回复]
列明来源确实是必要的。--大化国史馆从九品笔帖式（留言） 2025年4月16日 (三) 18:56 (UTC)[回复]
任何称号都要来源！毕竟总不会是凭空生出来的吧。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月25日 (五) 07:49 (UTC)[回复]
标明来源是肯定需要的，如果您认为条目中的编写方式可能有歧义，可以根据可靠的来源修改条目。--Babaibiaobin（留言） 2025年5月2日 (五) 06:15 (UTC)[回复]

“丁先皇”的本名说法

本主题全部或部分段落文字，已移动至Talk:丁部领。执行者：Jimmy-bot（留言） 2025年5月8日 (四) 08:14 (UTC)。[回复]

命名一致性判决请求：“colleges and universities”的中文翻译

目前在英文维基百科有很多名为“List of colleges and universities in XXX”的条目，列出一个地区的所有大学、学院及专科学校。例如en:List of colleges and universities in Alabama，更多示例可见于en:Wikipedia:Featured lists#Education。但在中文维基百科，这类列表的译名五花八门，因此或有必要进行统一。目前有这几种译法：

希望对此类的译名达成共识，并依据《Wikipedia:命名常规 § 命名一致性》方针统一译名。--Nebulatria È tra le braccia del Padre. 2025年4月22日 (二) 02:29 (UTC)[回复]

其他地区不了解，中国大陆的高校列表（在大陆简体模式下）应使用“高等学校”，这不是中文维基百科的“译法”（应该是英语维基百科条目需要考虑如何用英语表达中国大陆的“高等学校”概念尽管中文这一词本身是“舶来品”，但各地早已形成自己独特的高等教育体系和专门用法）。《中华人民共和国高等教育法》《全国高等学校名单》等官方法律或文件均使用“高等学校”。 ——自由雨日🌧️❄️ 2025年4月22日 (二) 02:41 (UTC)[回复]
这里应该先就中文以外地区讨论，因为两岸四地各有各的命名规矩，基于“名从主人”原则，强行统一也不实际。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月22日 (二) 06:16 (UTC)[回复]
是的，我希望统一的是两岸四地以外的命名，中文地区名从主人即可。--Nebulatria È tra le braccia del Padre. 2025年4月22日 (二) 06:30 (UTC)[回复]
据我所知，“大专院校”“大学”和“学院”所指的范围是越来越窄。“大专院校”包括专科学校（台湾曾有三专与五专）、大学和学院。“大学”必须由至少三个学院组成，所以“XX理工学院”不是大学，因为只有理工两个学院。条目应该根据所指的范围选择准确的称谓。--欢颜展卷（留言） 2025年4月28日 (一) 01:32 (UTC)[回复]
这类条目通常列出所有专科学校、大学和学院，所以个人认为可以有统一的称谓。此外在很多地区，“专科学校”也是一种“学院”，所以我认为没有必要在标题中特别提及“专科学校”一词。--Nebulatria È tra le braccia del Padre. 2025年5月1日 (四) 06:35 (UTC)[回复]

关于各虚构作品的列表因为关注度被大量提删

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:收录标准/虚构、WikiProject talk:ACG。

这些角色列表通常是昔日从各自虚构作品的主条目里分割出来的。用角色列表的条目名去反证关注度不足，根本是找错方向，要找至少也该用各虚构作品的名称去找吧？
还是各位想看到此分类的角色列表，通通合并回主条目呢？
就算要挂模板，也应该改挂{{unreferenced}}而不是用{{Notability}}--P1ayer（留言） 2025年4月24日 (四) 18:24 (UTC)[回复]
@Summerize、SunAfterRain、Nostalgiacn： ——自由雨日🌧️❄️ 2025年4月24日 (四) 18:32 (UTC)[回复]
当初阁下发起的大规模IP角色列表提报，比如 银魂角色列表 FAIRY TAIL角色列表 鬼太郎角色列表 流星花园角色列表 BORUTO-火影新世代-NARUTO NEXT GENERATIONS-角色列表 暗杀教室角色列表 我们这一家角色列表 爆漫王角色列表 足球小将角色列表 钻石王牌角色列表 Fate/Zero角色列表 排球少年！！角色列表 等等，理由是因为缺少第三方资料吗？@自由雨日--Whq19911224（留言） 2025年4月25日 (五) 03:13 (UTC)[回复]
Wikipedia:收录标准/虚构#虚构集合里面提到：“在一个虚构主题实体的集合中，至少需要有2项子主题符合WP:虚构准则或本身具收录标准”，而博人传的角色列表里面，漩涡博人和宇智波佐良娜两位主角都有独立条目，前者在本站上过DYK，后者虽然本站质量不行，但英文版却有足够的可靠来源供中文版改善。请问都这样了，还是要删博人传的角色列表吗？Whq19911224跟我说他是参考自由雨日的做法。如果关于博人传的角色列表的存留，我的理解没有任何问题的话，那就凸显出自由雨日你的做法不仅草率一刀切！更离谱的是还把别人带坏！--💊✖️2️⃣3️⃣（留言） 2025年4月25日 (五) 03:29 (UTC)[回复]
@Liu116 大致看了一下记录，他应该是3月2日开始陆陆续续提报角色列表的。--Whq19911224（留言） 2025年4月25日 (五) 03:40 (UTC)[回复]
所以呢？阁下最开始对notability的判断就同我截然不同（将我认为不符合收录标准的改成符合；将我认为符合的改成不符合），但“出事后”却第一时间说是“学我”提报的；而这里又摇身一变，化身成“审问者”？看阁下在讨论的态度，实在不像是希望删除或合并的立场，反而是强烈倾向保留的立场，实在无法不让人联想到WP:POINT…… ——自由雨日🌧️❄️ 2025年4月25日 (五) 14:13 (UTC)[回复]
  • 我在提报时均对照了收录标准和收录标准/虚构，并简单查看了外文版的条目和网络搜索。至于你提到的用户，我不认为我需要为其他用户的行为负责。我同他没有过任何交流，没有任何鼓励他提报的留言；反而留意到他3月31日在我提报某个角色列表之后13分钟便直接移除了收录标准模板（86637639），所以他去提报其他角色列表（甚至是符合收录标准的列表）我只感到困惑。 ——自由雨日🌧️❄️ 2025年4月25日 (五) 03:58 (UTC)[回复]
    我当然知道你没有鼓励他人效仿你的做法，你当然不需要为别的用户的行为本身负责，但你还是要对这一系列操作所带来的结果和一系列影响负责，就算不符合标准的条目数量较多，体量较大，历史遗留问题要想处理就更应该谨慎谨慎再谨慎，而你很显然没有做到这一点，不仅你自己出现误杀的情况，还连带别人也一起误杀，这就是你带来的结果。不少时候结果是很重要的，特别是处理这类问题时。--💊✖️2️⃣3️⃣（留言） 2025年4月25日 (五) 04:04 (UTC)[回复]
    如果有对明显符合收录标准的列表我判断失误，我在此致歉；如果实际上确实符合但佐证收录标准的来源需要寻找不少时间，则我不认为自己必须有改善这些角色列表使其符合收录标准（然后才能挂notability模板）的义务，中维的提报30日+提删近1月我认为时间已不能说非常紧张。此外，正是出于谨慎，我并未在几日内提报所有的角色列表。至于“连带别人也一起误杀”，同我上条留言。 ——自由雨日🌧️❄️ 2025年4月25日 (五) 04:15 (UTC)[回复]
    就算有30天的时间，如果不是我看到这个讨论，那博人传的角色列表不还是要遭到误杀？针对这样的历史遗留问题，有更好的方式处理，比如自己先不擅自挂模板，而是先在互助客栈里面讨论，这样可以降低误杀的几率，你有本事做到100%不误杀，你可以自己擅自去提删，既然现在已经证明你不能100%做得到，那就不好意思，必须先对你之前对类似条目的提删请求进行搁置，留更多时间让社群讨论及处理了。不论是互助客栈还是AFD，不是人人都会去逛，像我就不会天天去AFD那里去看，但这么重要的问题，两个地方同时展开讨论，总比只在一个地方讨论更好，在公告栏里贴上讨论链接效果更好。--💊✖️2️⃣3️⃣（留言） 2025年4月25日 (五) 04:24 (UTC)[回复]
    @Liu116 我也详细参考一些条目的提删过程 Wikipedia:页面存废讨论/记录/2025/04/19#729声工场 Wikipedia:页面存废讨论/记录/2025/04/23#宇宙世纪 Wikipedia:页面存废讨论/记录/2025/04/23#小书痴的下克上角色列表 。另外，若同样因为存在明显符合收录标准的列表所造成的判断失误，我在此道歉--Whq19911224（留言） 2025年4月25日 (五) 04:24 (UTC)[回复]
    你能否解释一下3月31日将我在《数码暴龙App世代角色列表》挂的{{notability}}改成{{notability unreferenced}}；然后又去明显符合收录标准的《哆啦A梦角色列表》里将{{notability unreferenced}}改成{{notability}}？ ——自由雨日🌧️❄️ 2025年4月25日 (五) 04:55 (UTC)[回复]
    两者对比了一下，你提报两个条目时候仅相隔1分钟：前者当时有11个来源，其中3个第三方资料，你挂notability（后来我增加了一个来源，把notability改成notability unreferenced）；后者当时有4个来源，其中2个第三方来源，你挂notability unreferenced（后来我把notability unreferenced改成notability）--Whq19911224（留言） 2025年4月25日 (五) 06:15 (UTC)[回复]
    明显符合收录标准的条目/主题，还要去挂模板，你可以挂之前去想一下吗？--Aqurs 2025年4月25日 (五) 06:48 (UTC)[回复]
    路过，之前协助fix了几个提报，说说个人观点。前者的11个中不是3个，而是只有1个是相对OK的，那就是电击Hobby的那个来源，可以推WP:NFICT“包括对周边产品的有效介绍...”，虽说有挂价格，但是考虑电击Hobby以及从内容上看，其实还算可以，假设让我（不修的话）我可能会挂notability unreferenced，但要是有人质疑这个来源挂notability，也不是说不行，可以争论——其他10个来源，有播映方、制作方、爱好者百科等等，基本都不行（证明关注度）。后者有超过10个子主题有独立条目，虽然条目内没有列出什么来源，但在这种情况下假设我挂notability，除非是建立在我认为这10个子主题都不“符合WP:虚构准则或本身具收录标准”的前提下，我才会这样做，否则我就会挂notability unreferenced，这是为了充实条目本身的来源，而不是质疑它的关注度——讲真，这两者不是一个级别的情况。个人建议您在处理此类情况时需要仔细一些。--银色雪莉（留言） 2025年4月25日 (五) 07:27 (UTC)[回复]
理由是因为我认为不符合WP:收录标准或WP:收录标准/虚构。 ——自由雨日🌧️❄️ 2025年4月25日 (五) 03:58 (UTC)[回复]
既然有人提起的话，我的看法就是：老条目基本不管，“You dig up the past, all you get is dirty.”，很多这类列表是关注度出现之前或之后没多久就出现的独立列表或分割出来，考虑到这类当时的编辑基本没有加参考注脚的编辑习惯；还有编辑群体的稀少，到近几年，这些条目基本上没有维护（无论是没人是还是缺少新内容补充）。可以考虑保留的依据，或者还可以看一下Wikipedia:资料页是否适合。对于近5~10年新分割的，除非满足Wikipedia:收录标准/虚构的列表分割或者Wikipedia:资料页，说真的，没必要分割。另外，这样大批量加关注度的，我想起某位。——Sakamotosan路过围观 | 避免做作，免敬 2025年4月25日 (五) 00:44 (UTC)[回复]
以前这类条目大多都是因为会占用主条目大量篇幅，才进行拆分的，有的作品的角色列表虽然会不符合收录标准的要求，但其本身体量大，涉及到的对剧情发展起到一定作用的角色也多，如果仅考虑到收录标准的问题将其合并（对内容进行优化后），又会产生将主条目挤爆这一新的问题。所以我主张，对于部分虚构内容集合条目，如果其不符合收录标准要求，但以最严格的标准去除掉所有的冗余内容（包括但不限于琐碎细节，及一些对剧情发展作用较小的角色等等）后，篇幅大到仍然不适合合并到主条目当中的，应给予适当的豁免，但仍需尽量附上一些可靠来源（不论一手、二手还是三手）。--💊✖️2️⃣3️⃣（留言） 2025年4月26日 (六) 02:58 (UTC)[回复]
我同意阁下提及的“琐碎细节、配角”等“最严格的标准”需要执行，惟还有一个标准，即WP:可供查证。若如阁下所言，只是“尽量”附上一些可靠来源，就难免掉进WP:原创研究的陷阱里面。据此进行更严格的优化后，若内容能够并入主条目即并入，若不能也无妨，因为这很可能代表该角色列表其实符合收录标准，又或可以根据NT:NRVE中“由于格式和展示的原因而建立一篇分离的条目”获得保留。
对于这类编者群小、又缺乏可靠来源的主体，我最担心的是这些条目会变成垃圾场，留着发臭，各种原创研究和版权侵犯层出不穷，这我在大爱电视剧和小众生者传记条目已经看过无数次了。所以我很认同下方Nostalgiacn君的留言：“留给我们的唯有一条路，那就是蓝桌图书馆的道路……不删的话，条目永远是‘初级’”，像是人人看到敬而远之却没人想去清理的垃圾桶，倒不如直接砸掉，让有心长期维护的人看到这里缺了个桶或者是一张桌才再立一个，因为可预期负责的条目建立者应该会比较积极维护。--1F616EMO（喵留言～回复请ping） 2025年4月26日 (六) 03:15 (UTC)[回复]
感谢补充，特别是在可供查证方面和“格式和展示的原因”而创建分离条目这方面，后者更是说明收录标准的规则和执行不是死的，所以说，面对一些篇幅很长的角色列表条目，提报notability之前就应该评估一下这当中必要的内容占了多少，或者干脆自己动手进行清理，看看剩下多少，这种方法也能减少误杀概率。--💊✖️2️⃣3️⃣（留言） 2025年4月26日 (六) 03:40 (UTC)[回复]
请注意我上面这番话的重点是可供查证，若非可供查证，一切免谈。维基百科条目是以第二或第三手可靠来源为主写作的，所有无法满足这点的内容都该删除。收录标准是指引，可供查证和非原创研究是方针，还是三项核心内容方针；若诸君连核心内容方针都漠视，就请出门右转Fandom，祝编安。
没有来源的内容就像垃圾桶，一堆没有来源或滥用第一手来源的条目就是堆填区，稍有理解的维基人都会敬而远之，不屑与之为伍；问题是我们的读者不会选择，就像贫民窟的饥民，以为堆填区是珍馐佳肴。--1F616EMO（喵留言～回复请ping） 2025年4月26日 (六) 13:44 (UTC)[回复]
然而Fandom目前因为协议不兼容原因无法收录中文维基百科的内容。----大筒木博人罪大滔天，搞的甜甜圈怨声载道。 2025年4月26日 (六) 15:23 (UTC)[回复]
逃避不是办法，维基百科不接受就是不接受。您有东西不用了，家里满地都是垃圾、没地方放了，想送给朋友，他不接受，你会不会就让它烂在家里，绊倒自己？当然不会，您肯定丢了，若是阁下行为不合常理那没话好说。维基百科内容还好，自己找地方安置几乎零成本，蓝桌图书馆甚至自己电脑的某个文件夹都是存档的地方，何不用也？反正外部站点不收肯定不是反对删除的理由，维基百科是维基百科，Fandom是Fandom。--1F616EMO（喵留言～回复请ping） 2025年4月26日 (六) 15:47 (UTC)[回复]
若阁下说“这样不方便协作改善”，我必须指出添加无法查证的内容在维基百科是在扰乱而非改善。“不能或拒绝遵守可供查证方针”是被明确指出的扰乱性编辑行为之一，违反维基百科的核心内容方针（见上，不再赘述），为维基百科所不容。若阁下希望使用协作的模式完善此类内容，建议阁下看一下如何下载MediaWiki还有Wiki农场（见鬼了，怎么又是一个缺来源条目），自己建一个站。--1F616EMO（喵留言～回复请ping） 2025年4月26日 (六) 16:01 (UTC)[回复]
对了，差点忘了我们隔壁还有个学院，可以去碰碰运气。--1F616EMO（喵留言～回复请ping） 2025年4月26日 (六) 16:39 (UTC)[回复]
WP:页面存废讨论/记录/2025/03/29#魔兽系列地名列表、WP:页面存废讨论/记录/2025/03/29#魔兽系列角色列表…… ——自由雨日🌧️❄️ 2025年4月26日 (六) 17:35 (UTC)[回复]
没想到这俩都可以无共识……( π )题外话私以为这俩已经形成了删除共识，汇入至其他站点其实是删除的连带操作。--1F616EMO（喵留言～回复请ping） 2025年4月26日 (六) 17:39 (UTC)[回复]
实际上我是有将相关内容迁移的想法，但是鉴于外部站点的协议与维基百科目前使用的协议不兼容。只能等到外部站点升级到与维基百科相同的协议之后再迁移。（有前人已经造轮子就不需要再重复造轮子。）并且可供查证这一点的话，英语的ACG条目也有类似的问题。例如漩涡博人在英语的条目关于大筒木博人一词的解释就没有遵守查证。（英文原文:where his constant fights with the Ōtsutsuki celestial resulted in him becoming an Ōtsutsuki genetically, giving him the nickname Boruto Ōtsutsuki (大筒木 ボルト, Ōtsutsuki Boruto) by some. ）----大筒木博人罪大滔天，搞的甜甜圈怨声载道。 2025年4月26日 (六) 22:36 (UTC)[回复]
Miraheze，请。维基百科不是不经筛选的轮子堆放处。--1F616EMO（喵留言～回复请ping） 2025年4月26日 (六) 23:52 (UTC)[回复]
另外英维错了不代表我们也得错。--1F616EMO（喵留言～回复请ping） 2025年4月26日 (六) 23:53 (UTC)[回复]
我没有搞错重点。角色列表条目往往是作为相关作品主条目太长，为不影响阅读而分割出来的（Wikipedia:格式手册/虚构#条目的拆分）。这些列表条目皆以剧情等虚构世界视角的内容为主，来源就是虚构作品本身，所以Wikipedia:格式手册/虚构#来源和引用说：“作品条目的剧情简介不强求引用来源，但为防范原创研究，内文引用多多益善”。当然不可否认的是只有剧情相关内容的角色列表条目确实不符维基百科定位，Wikipedia:格式手册/虚构里面也明确提到“分拆条目要有一定的现实世界信息”，而现实世界信息要求是“尽可能多地使用必要且有用的第二手来源”。改善肯定要改善，该加来源的地方肯定要加，不过你说的什么“维基百科条目是以第二或第三手可靠来源为主写作的，所有无法满足这点的内容都该删除”有点一刀切的味道……还是那句话，条目能救回来的先尽量去救（具体怎么“救”格式手册已经告诉我们了），实在改善不了再谈删除/合并。--💊✖️2️⃣3️⃣（留言） 2025年4月28日 (一) 09:29 (UTC)[回复]
参见WP:ACGN，WP:虚构集合。有一部分是可以保留的。--在下荷花，请多指教（欢迎签到） 2025年4月25日 (五) 01:45 (UTC)[回复]
要搞也是一个一个来，短时间内大量去搞，很容易误杀一些值得保留的，且让有心改善的用户忙不过来。就算是要大量搞，也应该是优先挑那些没有改善空间的，并作具体说明，然后有争议的先放到互助客栈里一个一个具体讨论。三年前有人也是短时间内大量提删虚拟角色条目，结果这些提删请求当中以保留结案的有20个左右，足以说明这样一刀切的做法是有多浪费社群资源，且相当令人反感！--💊✖️2️⃣3️⃣（留言） 2025年4月25日 (五) 01:58 (UTC)[回复]
连火影、海贼王这样的大IP的衍生角色列表都要提notability，真是荒唐到极点！！！--💊✖️2️⃣3️⃣（留言） 2025年4月25日 (五) 02:26 (UTC) 👍1[回复]
目前英语社群是将博人传的角色列表直接合并到主作品的列表内。（还有一些角色本身就没太多关注度，例如波风水门、千手柱间这种连英语都没有条目的角色。）----大筒木博人罪大滔天，搞的甜甜圈怨声载道。 2025年4月26日 (六) 04:17 (UTC)[回复]
英文版的en:Wikipedia:Notability_(fiction)#Lists_of_fictional_elements这里没怎么具体展开，不清楚他们的标准是什么。但按照中文版明文规定的标准还是照常符合的，另外还要考虑到去除冗余内容之后，剩下的内容是不是相对于主条目来说还是太长的问题，就更是要做出谨慎判断。建议以后提删之前，先把条目内容通通清理一遍，反正不论是合并还是不合并，早晚都要做的，合并之前就清理完了，合并的时候就方便不少了。--💊✖️2️⃣3️⃣（留言） 2025年4月26日 (六) 04:31 (UTC)[回复]
我认为提删应抱持谨慎的态度，只针对那些明显不符合收录标准的条目执行，而非大规模地草率提删。像某位使用者大量加入收录标准模板，连WP:虚构集合提到符合收录标准的哆啦A梦神奇法宝列表都加入。昨天加入的模板甚至连日期都打错。--夏冰 25时、ナイトコードで。 2025年4月25日 (五) 02:48 (UTC)[回复]
Wikipedia:收录标准/提报里光是角色列表就被提报超过100条，这样大量提报是要怎么改善，就等于是要让这些条目因大量提删来不及改善就合并回去或删除。--Kevin765432（留言） 2025年4月25日 (五) 03:20 (UTC)[回复]
(＆)建议 我的建议是，因为涉及面太广了，五年前（即2020年之前）创建的角色列表条目可以按照历史因素豁免提报（即使缺少第三方资料），同时提报中的相关条目30天到期后免于提删。--Whq19911224（留言） 2025年4月25日 (五) 03:58 (UTC)[回复]
私以为“缺少第三方资料”的条目不应该因“历史因素”获得保留。Wikipedia:可供查证是自建站以来就存在的核心方针，若说是“历史因素”，那么按照此方针，“缺少第三方资料”的内容应该删除，连带条目也会因没有足够内容而难逃合并或删除命运。私以为这正是收录标准的运作逻辑之一：若没有第三方可靠来源，或这类来源十分稀少，根本就写不了这么多，极端情况下会变得过短，继而被删除。至于大量提报的问题，私以为豁免并非解决问题的方法，此处提出两个想法：
  1. 延长收录标准提删期限，或按专题特定情况添加此类例外：这样可以让编者有更充裕时间改善条目，但前提是他们能确实知道自己的条目（或所关注的专题的条目）被质疑不符合收录标准，不然还是一样。这一点可以通过如同一般提删一样通知条目创建者解决。
  2. 限制同时进行（同专题）收录标准提删的数量，以免相关编者分身乏术；但缺点也很明显，容易造成提报过多但提删额度不足的瓶颈。
--1F616EMO（喵留言～回复请ping） 2025年4月25日 (五) 04:29 (UTC)[回复]
@1F616EMO 按照阁下的说法我可以理解，但是按照@Liu116的说法火影忍者角色列表、ONE PIECE角色列表、宝可梦动画角色列表三个条目又应该保留，所以目前是否达成共识？--Whq19911224（留言） 2025年4月25日 (五) 04:35 (UTC)[回复]
这三部作品都有至少2个角色可以独立成篇。就算忽略方针和指引上面明文的要求，光是删除冗余内容后留下的篇幅也是一望而知应该要留，毕竟作品本身体量大，在角色介绍里面要写的东西自然就会多。--💊✖️2️⃣3️⃣（留言） 2025年4月25日 (五) 04:48 (UTC)[回复]
其实，对于历史因素导致的条目缺少第三方资料，为什么要纠结于去补第三方资料呢？因为有时候时间太久了，第三方资料也很难找到了。但是，基本上日本动漫作品都有官网吧，那为什么不能用官网资料呢？@1F616EMO--Whq19911224（留言） 2025年4月25日 (五) 04:39 (UTC)[回复]
官网资料属于第一手来源，一手来源不能用来证明符合收录标准。--💊✖️2️⃣3️⃣（留言） 2025年4月25日 (五) 05:17 (UTC)[回复]
一个月前 自由雨日 陆续提报的角色列表条目，从前两天开始已经陆续到30天了期限了，仍挂notability的条目已经有被提删了，后期还会有更多，其中大部分条目都没有任何改善，看看到时候有没有什么应急措施或者豁免方法吧@Liu116@1F616EMO--Whq19911224（留言） 2025年4月25日 (五) 07:11 (UTC)[回复]
这类历史遗留问题，要想认真对待，就要做好打持久战的准备，确保得到社群的长期关注，要考虑的问题不仅仅是合并，更多是相关内容移回主条目时，要把一些冗余的内容去除掉，这工作量可不小啊，这更体现擅自提删的坏处。个人认为，应该先整理一个表格，筛出明显有问题的先处理掉，然后有疑问的在社群里进行讨论，有共识了再走notability程序提删或合并。这里有疑问的主要是指，相关的列表可能有至少2个子主题有独立成篇的潜力，只是还没正式独立成篇而已，例如头文字D角色列表里面，头号主角藤原拓海对于互联网亚文化的长远影响大家有目共睹，且改编的电影还是由周杰伦饰演，明显有潜力重新建立独立条目，然后其他主角也可能或多或少有独立成篇的潜力。像这样的情况就可以进入所谓的“观察名单”，毕竟头D都多少年前的作品了，来源不会比近期新出的作品好找。--💊✖️2️⃣3️⃣（留言） 2025年4月25日 (五) 05:07 (UTC)[回复]
其实我并不太熟悉ACG列表条目，只是天天看着新手在加无来源内容，巡查最近更改的时候看着心烦，所以也不好说些什么。不过通知收录标准提报倒是可以独立开案讨论，因为目前条目建立者若不特意查看并不会知道自己的条目已经被打上关注度的标签，也就无从察觉需要改善，变相把所有事情积压到最后一刻。--1F616EMO（喵留言～回复请ping） 2025年4月25日 (五) 05:44 (UTC)[回复]
如果以缺少来源为删除依据的话，里面有的是，但有人真的会认真如此？——Sakamotosan路过围观 | 避免做作，免敬 2025年4月26日 (六) 07:28 (UTC)[回复]
“留给我们的唯有一条路，那就是蓝桌图书馆的道路”
角色条目列表维持品质可比一般条目要难，出名作品还好说，认真找一下一堆资料。而且通常只有部分角色较多资料，导致比重失衡。不知名的作品，例如绝大部分服务型游戏，定期批量生产角色，写出来就是角色名+配音员名字就没了（1、2）。一般直接删掉（WP:VGFICT/WP:VGSTL），不删的话，条目永远是“初级”（WP:QUALITY）。
低品质的角色条目列表，可以说是条目迈向更高品质的障碍，已经有为了符合评选标准的“去芜存菁”行为了。低品质的角色条目列表需要出清，保留和改善要求上面说了，不再重复（WP:ACGN、WP:虚构集合）。改善不了的，格式手册也说了网络上还有其他的百科或者粉丝自建的作品百科，着重全面介绍虚构世界，未必要求现实世界视角。若您的条目不适合维基百科，可考虑前往此类wiki网站（例如Fandom等），请转移到其他百科。如果硬要留在维基百科，也就只有蓝桌图书馆。--Nostalgiacn（留言） 2025年4月25日 (五) 06:53 (UTC)[回复]
(！)意见，我不认为自由雨日阁下此番大量提删虚构作品列表一事，有任何不妥，一切都是按照WP:收录标准或WP:收录标准/虚构的规定，由他个人主观认为，这些虚构作品列表，不符合该相关规定而进行提删。自由雨日阁下按照规定作事，我认为无啥可评击的。
我倒是建议在此议论的所有维基人，可能绝大多数，还兼具著日本ACGN虚构作品爱好者的身份，包含我自己，我自己也是一名爱好者。
我建议可以多看看，香港维基人最近整的花活，详见：Wikipedia:页面存废讨论/记录/2025/04/17#杨逸德、Wikipedia:可靠来源/布告板#香港电影导演大全的来源是否可靠？。
现在《香港电影导演大全》即将被视为可靠来源，这本《网站书籍》它所收录的600多个香港导演，每个导演都即将符合“有效介绍之可靠来源”，包含杨逸德，符合WP:收录标准之标准，未来中文维基百科，只要这其中600多个导演条目被提删存废，关注度方面，全部都可依《香港电影导演大全》有针对该香港导演之有效介绍，来彰显该人具有关注度。
花活人人会整，《香港电影导演大全》这棚已经整给你们看了，日本ACGN虚构作品爱好者，也是中文维基百科中一股很大的势力，这爱好者的人数之庞大，只要聚集起来，弄个啥“虚构作品列表收录标准”其实也不难。
如果觉得旁人阻力太大，也可以缩小范围，也可把真人电影剃除，改立“ACGN虚构作品列表收录标准”。
如果旁人的阻力仍大，也可以再缩小范围，只针对日本动漫，改立“日本ACGN虚构作品列表收录标准”。--Znppo（留言） 2025年4月25日 (五) 07:22 (UTC)[回复]
早就有标准了，也许是太长没看，上面屡次提到的WP:ACGN、WP:虚构集合，就是你说的“ACGN虚构作品列表收录标准”。--Nostalgiacn（留言） 2025年4月25日 (五) 07:35 (UTC)[回复]
您后面提的例子，这事儿我刚好也有参与（利申：我投了通常可靠，但我不是香港维基人——我也不认为那里是“花活”——所以我想我应该还能够不避嫌地讲两句），如果阁下有仔细看两条讨论，会发现大家在讨论并通过的是它是“可靠来源”，但“可靠来源”在利用到条目中时并不会仅仅因为它是“可靠来源”就能被用于佐证收录标准——这一点我想我不止一次提过（且如今看意见上似乎并没有明显批驳这一点的观点，条目在当前状况下（即该来源将被通过可靠来源的情况下）将很可能被移除），另一位参与者Factrecordor阁下也有类似意见——还要考虑“独立性”等NT:GNG中明确提到的要素，这与前面讨论通过“可靠来源”的事情并不相冲突，也不会造成阁下所认为的“全部都可依《香港电影导演大全》有针对该香港导演之有效介绍，来彰显该人具有关注度”。所以我想，这既不是花活，也与本件无关，阁下的判断，恐怕是不准确的。
至于说本件中，不仅仅自由雨日阁下提关注度——还不是提删——也有其他用户提关注度，如果说ACGN方面的编者对这么大量地提关注度（当中有部分的提报不甚妥当）吃不消，作为一个不时处理关注度提报的用户，我得说我也有同感，这是人之常情；但我并不会怪责提报者，只要他们的提报有合理性，那么并没有什么可怪责的，我自己看的话，确实不少值得重新审视，但同样地，也出现了不少不甚妥当的提报。我建议诸位与其口舌，还是开始处理条目比较好——在下暂时贡献了四个（还是五个来着，不全是列表，也有虚构事物），所以应该还是可以站着说话不腰疼的。--银色雪莉（留言） 2025年4月25日 (五) 07:42 (UTC)[回复]
PS：如前面Nostalgiacn阁下所言，标准也是早就存在的。--银色雪莉（留言） 2025年4月25日 (五) 07:45 (UTC)[回复]
路过。我对虚构作品列表存留本身没兴趣，但抱歉不得不对@Znppo说几句：
不管是杨逸德那事还是在虚构作品收录标准这事，你的理解都是错误的。你在虚构作品收录标准的理解错误，上面Nostalgiacn说过，我就不说了。杨逸德那事我下面说。
杨逸德那事：首先，你对第一、第二和第三手来源的理解已经不正确了（我有说过，简单来说，维基不禁止第三手来源本身）；接着在杨逸德那边，你在对三手来源错误理解的基础上，又在评估来源可靠性（布告板说明、“可靠来源”本身说明）方面出了错，导致不正确的结论（由专家主编与监督的《香港电影导演大全》的明显不是台湾棒球维基馆那样的WP:UGC）。
你不好好理解、或起码回应有关来源的推论就算了（毕竟评估来源很难），现在逛逛还不小心逛到你在这边说人“整花活”──我只能说，假定别人想欺骗（台湾的教育部针对“花活”一词的名词解释：指刻意谋取利益或欺蒙他人的把戏）实在不是什么好主意。--Saimmx（留言） 2025年4月30日 (三) 20:40 (UTC)[回复]
(～)补充，最后，我也奉劝User:Liu116，与旁人讨论时，也许不要加入过多情绪性用语，诸如，【这样一刀切的做法是有多浪费社群资源，且相当令人反感！】、【真是荒唐到极点！！！】，我认为此举对于讨论本身无正向帮助，在页面存废讨论里，讲的是理据，阁下是凭着哪条中文维基百科的规定，你可以直接指明出来是根据哪条，若仅凭这种情绪性用语抨击对方，我个人觉得很不妥，也没啥道理。
英语有句俗谚：“ If you don't make things happen then things will happen to you. ”这句话的意思是“因果报应”，“因”和“果”是一组的，而且是相辅相成的，这句话的白话解释就是：你若当初没让制定“日本ACGN虚构作品列表收录标准”的【这件事】让它发生，那么“日本ACGN虚构作品列表”被大量提删存废讨论【这件事】就会发生在你身上。
我建议别去责怪（恨）提删人，要责怪（恨）的其实是中文维基百科这整个收录标准制度，提删人本身并没有过失，完全按照规定提删。我认为你其实应该要怪自己，为何当初没有发起制定“日本ACGN虚构作品列表收录标准”这件事。现在，也只是这个因果组合中的“果”来临了而已。--Znppo（留言） 2025年4月25日 (五) 07:22 (UTC)[回复]
不认为自己的措辞有任何不妥，首先一下就提报这么多条，在处理方面就已经带来了不小的负担了，其次一些符合Wikipedia:虚构集合要求不能再明显的条目都要动，这是相当严重的问题，你说我话说的难听，我说这就是他们低级失误所带来的【果】，没达到违反方针的程度就不算“没啥道理”。--💊✖️2️⃣3️⃣（留言） 2025年4月25日 (五) 14:07 (UTC)[回复]

本议题因收录标准而起，诸君也大多围绕收录标准讨论存废，但各位必须意识到收录标准的背后是可供查证。可供查证是你站三大核心内容方针之一，若是无法坚守，就变成维基学院了，你站就塌了，还不如去元维基申请关站，和学院合并一下。绝大多数ACG角色列表（无论是独立的还是嵌入的）甚至其他影视剧集列表都没有列明来源，甚至包含原创研究，使得有关内容无法查证。这样的弊端上面已经说过了，我们的读者可不会自己突然懂得分辨是非，把垃圾撒他们一脸他们还感恩戴德如获至宝。所以诸君要是看见没有来源的东西，请大胆的、用力的删，不用怕条目变成小小作品，因为会变成这样的条目值得删后重建伺候。我们必须确立一个事实，即“无来源就得删”，停止以“耗时太久”、“历史原因”诡辩、当缩头乌龟。1F616EMO（喵留言～回复请ping） 2025年4月27日 (日) 09:53 (UTC)[回复]

甚至这也不用去“确立”：要是让若干理性自然人去判断“无来源可以保留否”，一定一致通过对无来源条目的大屠杀。吉米·威尔士如是说：

这一点我怎么强调都不过分。若干编者似乎有个糟糕的倾向，将臆测性的‘我自某处听闻’的假伪资料加上‘来源请求’标记。错了，这些东西应该被积极地移除，除非可以为它注明来源。这点适用于所有资料，特别是在世人物的负面资料。

——吉米·威尔士，“零资讯胜过错误或不实的资讯”
--1F616EMO（喵留言～回复请ping） 2025年4月27日 (日) 10:00 (UTC)[回复]
诸君以收录标准判断列表去留的做法是不可取的。注意收录标准的用词：

如果一个主题得到了可靠来源的有效介绍，并且这些来源独立于主题实体，则可假定该主题或符合独立条目的收录标准。

因此，收录标准不是挡箭牌，不构成在条目完全不符合可供查证以及非原创研究方针的情况下保留的理由。要是某条目中有足够的可靠来源，就自动符合WP:GNG，反之就算符合收录标准，也不符合可供查证。--1F616EMO（喵留言～回复请ping） 2025年4月27日 (日) 10:21 (UTC)[回复]
对呀，这里Category:缺少来源的条目可是有不少符合你想删除的缺少来源的条目，快上啊。有没想过为什么缺少来源也不一定是可被提删的理由，旧账不可能靠这样大手大脚就能解决的。不能单单靠法条主义去这样对待的。这类条目如果考虑来源的话，可以引用一手来源（作品本身）来解决，当然要对描述的话，需要仔细阅读来源来对应，编辑实在无法逐一核对来源详细的话，也可以靠单纯列出纯书籍来源而不用句子脚注。至于是否“原创研究”的话，连来源都没做审阅的话，怎么判断描述是符合还是不合来源？如果能核实来源，确定描述不符的话，可以自行删除语句并附编辑摘要，一般其他编辑会善意认同（除非硬杠的话，自行讨论决定）。对于部分涉及真实社会的人事需要严格遵循提供来源，我认同这很必要，但至于其他内容，乃至这类作品内元素的描述的来源情况，我认为应该需要但现实上有难度，尤其涉及建站初期十来年积累下来这批东西，问就是那些老编辑就是没有养成这种良好习惯，不及一些新人这么血气方刚，比廉署还刚。如果要处理这些老条目的问题，逐点提出并改善的话，或者可以接受；但这样大批量的大刀阔斧，我认为会超出相关编辑和社群的处理能力，纯属添乱。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月2日 (五) 10:57 (UTC)[回复]
“添加或恢复内容的编辑者应承担举证的责任”，路过的巡查者没有义务去举证。因此缺少来源的内容绝对不用小心查证，反之更应该勇敢删除，最好通知添加该内容的的编者（在此G11一下WikiBlame，对于寻找句子原作者十分有用），达成有效的沟通。“建站初期十来年积累下来”导致积压严重是确实存在的问题，但这并不妨碍有人路过看到了并意识到这内容不符合可供查证而去移除，更不是保留的借口。只是你维对此事不怎么积极，也因此没有处理先例，我也只好暂且蜗居新条目巡查和最近更改巡查，免得被一大堆人用收录标准保留糊一脸还被管理员忽略可供查证这一最大共识决定保留，费力不讨好。--1F616EMO（喵留言～回复请ping） 2025年5月2日 (五) 14:00 (UTC)[回复]
补充一下为什么我会认为“可供查证是最大共识”：每一个维基媒体基金会的专案都会有其成立宗旨，这是将该专案和其他专案乃至第三方方针区分开的重要元素。对于维基百科而言，“成立宗旨”是共构百科全书，并通过落实三大内容方针管辖内容。这些成立宗旨不可以由社群共识改变——试想有人去维基学院说“不如我们改为什么事都找来源说事情”，就算社群糊里糊涂通过了，基金会也一定不会允许这修订发生，因为这样一来，维基学院就不再是维基学院了。--1F616EMO（喵留言～回复请ping） 2025年5月2日 (五) 16:21 (UTC)[回复]
可是有时候我不明白某些人，明明有些条目有足够的可靠来源和第三方来源，居然还提删。--Whq19911224（留言） 2025年5月4日 (日) 02:14 (UTC)[回复]
请问此例如何能够使其满足收录标准？？ ——自由雨日🌧️❄️ 2025年5月5日 (一) 02:27 (UTC)[回复]
虽然我也认同编辑要善始善终，不过涉及到条目内容的一些问题，更多看重的是结果，最理想的结果是条目内容完整性和可供查证两者都要，而这就要靠更好的手段来实现，有些地方本来靠改善优化就能解决，却非要用一刀切删除的手段，这不是大家愿意看到的。处理以前编者遗留下来的问题诚然不是我们的义务，但不代表为了纠结所谓义务的问题就要放弃达成更好的结果。--💊✖️2️⃣3️⃣（留言） 2025年5月5日 (一) 01:24 (UTC)[回复]
（编辑冲突，正在回复修订版本87141433上的留言）我想表达的正是可供查证性凌驾于完整性，或者说，如果没有来源，我们不能作什么。既然有可供查证这一核心内容方针存在（其超然性已经在上面叙述，见此，不再重复），我们写条目的资料来源就只限于可靠来源（只有极少数例外，请看方针指引），任何其他内容都属于原创研究，该杀、该打、该移除。既有此一限制，“条目内容是否完整”的担忧就不存在——因为我们作为编者，“根本不知道”来源外的信息的存在。君所言“这不是大家愿意看到的”只是社群扭曲的结果，是社群对待无法查证内容不作为的结果，而非维基百科的初衷。参与维基百科本身就设有限制，要是行事方式不符合维基百科的宗旨，就该离开。--1F616EMO（喵留言～回复请ping） 2025年5月5日 (一) 02:01 (UTC)[回复]
（回复当前版本留言）“更好的结果”是什么？如果是指“追求条目完整性”，见上。--1F616EMO（喵留言～回复请ping） 2025年5月5日 (一) 02:02 (UTC)[回复]
另外我没有纠结义务问题。维基百科不强迫任何人参与，所以也没必要谈“义务”什么的，看见就处理，心累了也不要紧。至于“是不是我们要做的事”，我上面已经说的很清楚了，巡查路过爱做就做，没人强迫，也没人说不可以。--1F616EMO（喵留言～回复请ping） 2025年5月5日 (一) 02:11 (UTC)[回复]
如果您认为“读者不会想看一条不完整的条目”：即使是读者，也要尊重维基百科的规则。维基百科不是爱好者内容网站等核心内容方针的实践已经说明维基百科并不服务所有读者，而只服务认真地当维基百科是百科全书的人。作为一本百科全书，最重要的就是内容的可靠性——传统百科全书使用同行评审或其他评审程序达成，维基百科则选择了向外查证，共同点是质高于量。要是读者不认同这些原则，大可去其他地方，Fandom上就有不少爱好者内容维基，还满好看，内容丰富完整，要不阁下也去贡献一下？--1F616EMO（喵留言～回复请ping） 2025年5月5日 (一) 02:25 (UTC)[回复]
那只能说贵兄台你，站着说话不要痛，本项目老问题一摞摞，就喜欢抓软柿子捏的，引经据典一道道的，抱怨和扔破烂是最容易的，花时间去修复是最麻烦的。如果按照贵兄台这样严格要求的话，前面说了Category:缺少来源的条目都是“铁定有问题”的条目，尽管提删，保证符合道义，没人能阻拦的，作品元素列表至少有对应作品条目可以归并，这些“没来源”的单独事物条目那就难说了，如果贵兄台能这样严于律己的话，实属项目的一大善事，立一个专门项目页面赞扬贵兄台的伟绩也不为过。还是类似观点，对于涉及现实人事影响的描述，我认为必须补充来源以引证；但对于其他情况，尤其是涉及超过快5~10年没再大的实质改动，或者这类作品元素列表条目，基于项目的人员活跃程度，适量提出并协作修正或者处理倒是可行，但这样大量提报并如此大义凛然的说辞，我认为这纯属添堵，或者说“挖旧账，满手脏”的活了。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月6日 (二) 04:17 (UTC)[回复]
我从来没有将“批量”和“删除”挂钩。关于“删除”，维基百科讲求可供查证，故删除无来源内容是天经地义的，若阁下不同意就请离开；至于“批量”，方针无限制者即可为，但维基百科也不强迫任何人参与，故路过喜欢做就做，批量就批量。另提删绝对不构成强迫主编或专题参与者参与，因条目主编或其他人大可通过DRV恢复草稿继续编写（在此慨叹你维草稿化用例太少了，该大大推动）。--1F616EMO（喵留言～回复请ping） 2025年5月6日 (二) 05:34 (UTC)[回复]
我前阵子批量提删了大爱电视剧，又不见您以“快5~10年没再大的实质改动 ”为由去保留？同为无来源旧条目，没有不一视同仁之理。--1F616EMO（喵留言～回复请ping） 2025年5月6日 (二) 05:36 (UTC)[回复]
至于实践，近来我多做生者传记小作品化，因为最近更改巡查常常看到IP君们在好心做坏事。你维BLP又是另一大粪缸。--1F616EMO（喵留言～回复请ping） 2025年5月6日 (二) 05:39 (UTC)[回复]
因为ACG有条目变动监控，而且最近现充加自省，消失了一段时间，现在留意到这些操作。只能说你搞了一些太大的动作，触发特定题材编辑的不满了。我认为适当量去修的话可以接受，但过度去弄的话，以前LTA:SM就涉及这种行为的。我在做新页面巡查时，也会稍微严格按照规则去判断这些页面，也一定程度避免堆屎成新山，但对于旧山的话，如果不熟悉对应特定示例题材的话，基本上很难入手改善，也只能挂上标记，如果不涉及影响现实人物声誉等严肃题材必须来源印证外，另可留着先不管，也不要贸然动大动作。或者说对于过往早于关注度确立，乃至更直接关联于的虚构关注度确立之前建立的条目，拿新规去批判旧物，不太好。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月8日 (四) 12:43 (UTC)[回复]
个人以为这个问题其实没那么麻烦，完全就是看社群对自己所在的这部在线百科全书的认知而已。如果说，社群认为你站就是自己闲暇时光中的一所游乐场的话，那么删除或者草稿化那些不符合可供查证或其他相关方针要求的条目完全就是闲的没事给自己找罪受，完全没必要。但是，如果说社群认为中文维基百科是一部在中文世界中有相当影响力的百科全书，并愿意承担相应的社会责任，那么我想对于“不符合可供查证或其他相关方针要求的条目”是否应该删除或草稿化这个问题，答案是显而易见的。Iming 彼女の爱は、甘くて痛い。 2025年5月8日 (四) 15:05 (UTC) 👍1[回复]

( π )题外话刚在FB看到有公海的人注意到这情况，他们除了对这些提删十分不满，也有人在这个post的留言区拉票，大家注意一下--VAMPIRE!VAMPIRE! All Hands Brace For Shock!Birds Away. Missile intercepted（留言） 2025年5月8日 (四) 10:04 (UTC)[回复]

cc @亞歷士陳、1F616EMO、Liu116、自由雨日、Saimmx、Fthasdd、Cwek：--VAMPIRE!VAMPIRE! All Hands Brace For Shock!Birds Away. Missile intercepted（留言） 2025年5月8日 (四) 10:11 (UTC)[回复]
我看不到Facebook，另外“公海”的意思是？ ——自由雨日🌧️❄️ 2025年5月8日 (四) 10:26 (UTC)[回复]
公海我也不懂，不过节录这边看到的：
“✍🏻中文维基有人提出删除足球小将内容，唔明白系咩玩法🤔，有咩办法解决？”
“中文wiki有好多小粉红洗条目，好多都系靠港台user守住”
“妒忌日本足球嘅成功，妒忌日本漫画嘅软实力，不外乎系韩国人同另一个国家嘅人先会做啲咁无聊嘅嘢”
“睇落都几R头,跟手睇下条友做过乜,原来佢已经提出删除好多其他动画角色嘅维基内容,例如高达,面包超人,烙印战士等等.而个理由全部都系"没有足够的可靠资料来源能够让这个条目符合Wikipedia:收录标准中的标准"之但系维基又配合佢,死得.”
“系咪小粉红？提出存废条友系共产党支持者”
“中维嘅空泛执法标准，令到呢班删除派咩睇都唔顺眼乱提存废申请一餐”
自由雨日，简单来说，已经有人质疑中维的删除理由与政治表态了。请在回应时注意措辞：别人对你的印象，已经因为你的表态，认为你是反日的粉红了。--Saimmx（留言） 2025年5月8日 (四) 10:54 (UTC)[回复]
『请在回应时注意措辞』：对《足球小将角色列表》的提删我只说过这一句话，我不认为还需要“注意”什么，更不认为这句话能被联系到“反日的粉红”是我之前有什么措辞不当……更何况哪怕假设我真有过什么强硬的表态，对站外网友的这类纯粹攻击抹黑行为，我认为也不应将“注意”的责任归咎到受害者身上（题外话，就过去别人站外对我的攻击来说，这种描述已经算好的了） ——自由雨日🌧️❄️ 2025年5月8日 (四) 11:13 (UTC)[回复]

所以说方针遵守是要遵守，但过于激进地去执行方针有时候只会带来反效果，你说站外用户拉票、人身攻击什么的过火确实是过火，但这就是结果。有的东西改善总比删除好，能救的先尝试救过来，救不过来再提删除，要尽量用更好的方式为条目争取一个更好的结果。{{Unreferenced}}、{{Citation needed}}等这些维护模板不是拿来做摆设的，他们是为了随时吸引有能力改善的用户亲自动手进行改善。有的东西动不动就因为没来源就删除，有考虑过有的人想救但碍于专业知识有限有心无力的情况吗？有的人好意思对十多年老手说出“阁下不同意就请离开”这样的话，说的好像别人十多年维基经验是水出来的，还不如你两三年的，有本事放这种狠话就先把来源相关的维护模板全删了算了！--💊✖️2️⃣3️⃣（留言） 2025年5月8日 (四) 11:32 (UTC)[回复]

“但这就是结果。”好啊，让不承认维基百科核心方针的爱好者们随便，我们这些拥护各项方针的维基人继续写我们的维基，参与维基百科本身就设有限制。反正不是人多势众就有效，连安全投票都可以查傀儡，顶多就是委屈一下管理员漏夜封禁了。所谓“吸引有能力改善的用户亲自动手进行改善”并不需要条目（或内容）存在，因为所谓“补充可靠来源”根本就是扯谈，我们要做的是全盘根据可靠来源重写，并将符合可靠来源的现有无来源内容视作巧合而非有用的资讯，因为我们“根本不知道”来源外的资讯的存在。如果有人“想救但碍于专业知识有限有心无力”，也不是拖延的借口，因为把内容晾在条目空间也不是办法，且你维地方多得是。--1F616EMO（喵留言～回复请ping） 2025年5月8日 (四) 12:14 (UTC)[回复]
诚然“在删除前应给予加入此内容的编者充足的时间来补充来源，否则可能导致他们的不满”，但无来源的旧条目若说不符合“给予充足的时间”，我是不相信的。至于新条目，草稿化指引已经规定需要给编者一些时间改进条目（当然包含添加来源），故无此方面的问题。--1F616EMO（喵留言～回复请ping） 2025年5月8日 (四) 12:27 (UTC)[回复]
前面说过了，晾着没改的地方（Category:缺少来源的条目）多着呢，只能说社群的态度就是避免这样大动作，就算拖着。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月8日 (四) 12:34 (UTC)[回复]
做事过于死板并不是好事，尤其如此大量的操作，有一定意愿跟进的也很难跟上你这样大刀阔斧的操作，容易与其他编辑不满的。--此条未正确签名的留言由Cwek（讨论｜贡献）于2025年5月8日 (四) 12:46 (UTC)加入。[回复]

更名程序的基准

本主题或以下段落文字，在讨论结束后应存档至Talk:大罢免。

“2025年中华民国大罢免潮”→“大罢免潮”提出讨论仅仅一天就抢快改名符合程序基准吗？近年部分时事主题的条目讨论时程不足或是讨论广泛性不足即迳付更名，是否应照以往惯例通盘检视而非放任选择性破例。--Cbls1911（留言） 2025年4月25日 (五) 11:29 (UTC)[回复]

明明现在大部分媒体都在说“大罢免”，为何还要坚持使用相对较少的“大罢免潮”这一名称？--日期20220626（留言） 2025年4月28日 (一) 00:52 (UTC)[回复]
他反对的可能是去除“2025年中华民国”吧？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月30日 (三) 12:39 (UTC) +11[回复]

哪些周深歌曲符合收录标准

众所周知，已封用户U:生米一粒贡献了超过200条周深歌曲的条目（见Category:周深歌曲）。我看了一小部分条目，除了明显的{{advert}}、{{trivia}}问题以外，有的歌曲显然不太符合收录标准的要求的。我一开始根据WP:GNG去筛，把没有新闻报道来源（不含软文和媒体机构在微博的发文）的条目挂上关注度。不过，根据WP:MUSIC，作品至少登上一个具有一定规模的国家或地区月、年商业排行榜或两个周商业排行榜头十名内，但登上同一组织或单位发布榜单的不同类别不在此列，再看到Wikipedia:商业排行与认证中为展现作品的商业成绩须避免以下条件：……仅凭单一发行商或渠道数据制作的榜单：例如QQ音乐、JOOX和mora等平台，我对条目中（如I_See_Us）罗列的林林总总的小榜单、细分榜单是否能佐证收录标准产生了很大的疑问。虽然我个人的立场是除了一些十分知名的歌曲外，琐碎小歌曲都应该(×)删除，但还是要参照站内程序，与各位协商，达成共识后再操作为好。鉴于我在音乐收录标准的处理上曾有欠妥，我在此和各位探讨：

  • QQ音乐、酷狗音乐等音乐平台的……
    • 总榜单可以佐证收录标准吗？
    • 分榜单（国风榜、飙升榜、内地榜、热评榜、新歌榜等等）可以佐证收录标准吗？
  • 除了WP:GNG以外，就周深歌曲而言，哪些奖项/榜单符合NT:MUSIC的收录条件？

以上。--自由米花🌾🌼 2025年4月29日 (二) 17:55 (UTC)[回复]

既然没人回应，那我继续排查和提报了，扔到存废讨论再说吧。--自由米花🌾🌼 2025年5月8日 (四) 02:45 (UTC)[回复]
@糯米花：一、我个人认为总榜单可以佐证收录标准，另外符合通用关注度的也应予以保留，而不是以主观的知名或琐碎来决定是否保留条目。二、阁下的排查和提报是批量进行吗？其中大鱼 (歌曲)及小美满条目我已经打捞重写过了，还是被阁下加上了{{fanpov}}模板。阁下可否先看过条目内容再添加模板，而不是对着周深歌曲的分类直接批量添加？——〚 十九 〛 2025年5月8日 (四) 06:33 (UTC)[回复]
十九君您好，理解您的忧虑，也借此机会说明在下挂模板的标准：
  • {{Notability}}：条目内的source排除不可靠来源后，剩下的来源仅为软文者，或来源仅作顺带提及，非有效介绍者。
  • {{trivia}}或{{fanpov}}：条目内事无巨细地记录了这首歌在哪里被唱过。个人认为，这些资讯琐碎且无用，即使有可靠来源也是顺带提及之用，非专注于介绍歌曲本身。
  • {{advert}}，条目内引用了知名或不知名的乐评人，说这首歌如何好听、温柔、委婉、动感等。即使开头加上了“XXX评价”，但大量的正面评价堆砌也是有宣传之嫌。
具体到您所提及的大鱼和小美满，个人认为在评价和演出的环节还是有些琐碎的。当然，和其他条目相比，这两个条目做的也相当不错了，个人觉得属于可挂可不挂的范畴。就算撤下模板，本人也没有异议。
最后请您保持善意推定，所有的条目本人都是看过后再添加模板的，并不是对着条目批量添加。有些歌曲本人看了之后觉得条目篇幅较少，没有琐碎宣传内容堆砌，source也不是软文，便没有添加。（如：同行同往，虽然source有强烈的利益相关，但至少还是写成了一篇新闻的样子。）当然，模板添加与否可能和其他人有所争议，指出有疑虑的部分进行探讨以确定边界也是有必要的。谢谢您。--自由米花🌾🌼 2025年5月8日 (四) 09:31 (UTC)[回复]
@糯米花：感谢阁下的回应。适才实在是看到自己花了时间重写的条目被挂模板有些气恼了，就上面和阁下讨论页中带情绪的言论向阁下道歉。评价和演出的部分，我是参考了女神和老派约会之必要等获选优良条目的条目来写的。除此以外，也感谢阁下付出心力来清理相关条目，我想做这样的事情很久了。——〚 十九 〛 2025年5月8日 (四) 11:51 (UTC) 👍1[回复]
@Sinsyuan：据方针WP:讨论发起位置“讨论结束后亦应让讨论原地存档，避免重复在多个页面存档后出现讨论分支。”，我移除了你添加的{{存档至|Talk:周深|WT:收录标准/音乐}}模板，也请之后不要再添加了。若需留讨论记录可以向这些信息框的讨论页发送讨论通告来链接。 ——自由雨日🌧️❄️ 2025年5月8日 (四) 06:51 (UTC)[回复]

请求搬出沙盒条目：战神赛特（War God Seth）

条目位于：User:Superich58/沙盒

条目为原创虚构角色“战神赛特”之介绍，包含角色设定、出处与应用背景，语气中立，格式完整，无外部导流。希望能协助搬入主空间，谢谢！

--Superich58（留言） 2025年4月30日 (三) 02:12 (UTC)[回复]

缺乏参考来源以佐证收录标准。--自由米花🌾🌼 2025年4月30日 (三) 02:38 (UTC)[回复]
您需要添加更多的参考文献，更加完善和增加条目内容，不然即使移入主空间了，也可能因为不符合收录标准而导致条目被删除。也许可以参考这个链接https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Video_games/Sources 来添加参考来源，或者任何您找到的可靠来源的参考文献--Babaibiaobin（留言） 2025年5月2日 (五) 06:00 (UTC)[回复]

关于闽越都城的争议

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

详见我与@御坂雪奈：在User_talk:御坂雪奈#闽越都城的讨论。争论焦点是城村汉城是否是闽越都城--Perinbaba（留言） 2025年4月30日 (三) 17:10 (UTC)[回复]

有关首都只有福州而拒汉六城不是首都的文献论证就有：2001年的闽越文化的几个问题——兼论武夷山汉城不是闽越王城、2004版《福建历史地图集》（西汉闽越王国、汉军入闽）、2014年欧潭生：汉初闽越国冶都考、2019年黄荣春：闽越国都城与东冶港、2024黄荣春的《闽都考古录》。正如在2004版《福建历史地图集》所标注的，如果所谓的拒汉六城就是所谓的首都，那为何在当时也还具有争论的情况下，却不同时像冶城那样，两城同时用上首都的图标？其次，如果在后期的“汉军入闽”时也升为首都的话，那为何所谓的闽越国王城不直接和闽越国都城一样，使用不同的字体和颜色加粗？而如果，真有那位阁下讲的所谓：而且官方的态度就是有两个都城，那请问为何为何所谓的闽越国王城是首都的观点不占据主流？反倒是以福州论的闽越国都城的说法占据主流？？？--御坂雪奈󠄁 2025年4月30日 (三) 17:25 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
有关讨论发起位置等的讨论
——自由雨日🌧️❄️ 2025年5月1日 (四) 18:23 (UTC)[回复]

“冨”

本站标题是否应用此字，或改用“富”为宜？如富岳三十六景（部分转换）、冨㭴义博等。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月1日 (四) 15:11 (UTC)[回复]

这个字只是富的异体字吧。感觉合并为佳。--The Puki desu（留言） 2025年5月2日 (五) 06:10 (UTC)[回复]
如果是新旧字体差异的话，应当推回旧字体，然而如果异体字的话，则应比照苏姿“丰”和谢衣“鳯”保留。--赤羽苍玄（留言） 2025年5月2日 (五) 06:52 (UTC)[回复]
前面两个算是中文异体字，这个算吗？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月4日 (日) 05:34 (UTC)[回复]
似乎是算的。--Hamish T 2025年5月4日 (日) 10:06 (UTC)[回复]
应该使用中文常用字形。中文主要工具书甚至都没收这个字。--Kethyga（留言） 2025年5月2日 (五) 10:44 (UTC)[回复]
此类汉字问题可分为以下情形：
  • 如属中文异体字：（依WP:异体字）
    • 且在所有地区罕用于所在语词，则改为常用字；
    • 且在至少一地常用于所在语词，则先到先得，不得修改，例如谢衣鳯；
  • 如非中文异体字：
    • 所在语词属于中文专有名词，则保留此字，例如含有“の”的中文品牌或作品名称；
    • 所在语词不属中文专有名词：（依NC:USECHINESE）
      • 且不比中文翻译的名称在中文中更加常用，则改为中文翻译的名称；
      • 且比中文翻译的名称在中文中更加常用，或不存在中文翻译的名称，则保留此原文名称；
“冨㭴义博”显然不合修改情形，而符合保留情形；“富岳三十六景”仅经Google则较难判断。--— Gohan 2025年5月6日 (二) 03:21 (UTC)[回复]

主席的玉照没了

本主题或以下段落文字，在讨论结束后应存档至Talk:毛泽东。

(＊)提醒：条目毛泽东之前使用的那张官方肖像被删除了，虽然后面有人补回去，但似乎影响到了一些条目（比如竹幕）和模板（比如T:User 毛泽东）。可能有大量相关模版和条目需要修复。--KurGenera(留言) 2025年5月1日 (四) 20:28 (UTC)[回复]

[12][13]，[14][15]。--YFdyh000（留言） 2025年5月1日 (四) 21:21 (UTC)[回复]
不能换回去吗？放一张又模糊又有污渍的扫描件也说不过去吧。--The Puki desu（留言） 2025年5月2日 (五) 06:08 (UTC)[回复]

标题已修改

由于与本讨论页或讨论主题无关，本框内讨论文字已关闭，相关文字不再存档。
如有异议，请咨询互助客栈或其他管理员。执行人：—KurGenera(留言) 2025年5月8日 (四) 00:03 (UTC)

（节删）

说的对，一大堆品质低劣的条目，啧啧。--August讨论‧签名‧回复请ping 2025年5月3日 (六) 11:44 (UTC)[回复]
抱怨和直接扔进垃圾桶（指一股脑的提删）最容易。动手改善最难。呵呵（恭喜你你又水到一个议题）。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月6日 (二) 03:58 (UTC)[回复]
不明白这个讨论串的意义在哪里，比起还算有点意义的stub，感觉在客栈讽刺除了刷存在感毫无意义啊。--—远方传来风笛（Talk） 2025年5月7日 (三) 16:33 (UTC)[回复]
(：)回应，开串主当时一发起这农场标题，我那时在监视列表瞬时看到，就想立即回复吐槽他，“我维何时变得如此空泛虚谈？！”，但还是忍下来了，隐而不发。
后来看到首先回复的用戶U:August.C，这使用者“自称是个高中生”，忽然间我就似乎意会到了什么。我猜想大概就是年龄的原因吧。
老实讲，我想不出发这标题有何具体意义，完全没提到任何具体条目，只丢个标题说我维如何，然后空泛虚谈地要旁人改善，要旁人【洗编辑数】，看了实在让人“黑人问号？！”。我内心只觉得发这类农场标题文有何意义？
没指定哪个条目需要改善→变成标题农场，易流于空泛虚谈。
要旁人改善此情形→我维中文条目达140余万条，到底要人改善哪个条目？！让人看得黑人问号。
能待在我维里面，几乎都是老骨头了→编辑次数超过500次后，为何要响应发串者洗编辑数？难道是为了取得超资深延伸确认使用者权限？--Znppo（留言） 2025年5月7日 (三) 17:14 (UTC)[回复]
(！)意见，我的结论，发起这种空泛议论似乎完全不会有任何效果，自然也不会有旁人听从你的空泛号召，所以又轮回到，起始循环Loop，发这类农场标题文有何意义？
只能说年轻真好，看了开串使用者User:Kurgenera在Wikipedia:权限申请/申请巡查权里，在申请文中提到他最近课业如何，看来亦是一个学生。
再搭配，首先回复的用戶U:August.C，这使用者“自称是个高中生”。
结论，我只能说年轻真好，如无太大意外的话，实际年龄和心智年龄，两者似乎是正相关。--Znppo（留言） 2025年5月7日 (三) 17:14 (UTC)[回复]
@Znppo：调整了一下语法：我将您第一条留言和第二条留言之间的<br />改为了“回车”+:（87186343）。如果用<br />或<br>的话，其他编者如果对您第一条留言点按回复，您的下一条留言就会被自动缩进（见我在沙盒的测试［一］、［二］，导致您第二条留言错误显示为回复其他留言——如［二］中直接变成了回复test留言），另见这一实例。 ——自由雨日🌧️❄️ 2025年5月7日 (三) 17:34 (UTC)[回复]
也没说是年轻人就一定有问题吧，我看到不少老人依旧是我行我素。----Cat on Mars 2025年5月7日 (三) 18:00 (UTC)[回复]

籍贯与出生地

中文维基百科应该有不少混淆了籍贯与出生地，特别是将籍贯写入出生地的情况可能会比较多。另外分类“**人”是否合适或者准确，比如分类Category:北京人，在分类中写着本类仅收录籍贯（出生地或祖籍地）是北京的人（people from Beijing）。其他北京相关人物请见母类:北京人物。，把籍贯和出生地放在同一人分类中不准确，至少在信息提取的时候，无法直接从分类中区分北京是出生地，还是籍贯。--Kethyga（留言） 2025年5月4日 (日) 08:05 (UTC)[回复]

“将籍贯写入出生地的情况可能会比较多”能否举例。关于分类，请指出具体问题和可行方案？某地人的概念非常复杂，不止于籍贯和出生地，分类的说明是一个建议做法。--YFdyh000（留言） 2025年5月4日 (日) 12:29 (UTC)[回复]
分类比较宽泛，不应该限制过多，否则就会出现大量“北平出生人物”这种过度分类（北平本身倒还好，要命的是极小的行政区划也要分立的情况）。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月4日 (日) 13:50 (UTC)[回复]
中维应将行政区划方面的人物分类全部弃用定义长期不精准、混乱、有歧异的“**人”，改为更大范围的“**相关人物（People associated with xx / People of xx）” (68110385)，底下新增定义明确的“**出生人物（Births in xx）”，同时使“**相关人物”与“**出生人物”和其他语言对应分类的定义更加吻合。--HanTsî（留言） 2025年5月5日 (一) 04:01 (UTC)[回复]
与籍贯 / 故乡 / 家乡、户籍地 / 居住地、学籍（“**（高级中等以下学校）校友”）、工作地（“**（学校）教职员”、“**政治人物”（北京市政治人物 / 台北市政治人物））等有关行政区划人物和分类属于“**相关人物”。--HanTsî（留言） 2025年5月5日 (一) 04:25 (UTC)[回复]
写入相关人物更加不精准吧。是否不少人物可能出现10个以上的xx地相关人物分类。--YFdyh000（留言） 2025年5月5日 (一) 04:27 (UTC)[回复]
那还请你提出一个大家长期能够接受、精准、不混乱的具体“**人”定义出来。并非直接出现在“**相关人物”，而是透过现有子分类与“**出生人物”间接出现，就如同国家方面的“在**的外国人”，传主条目不应直接出现在“在**的外国人”，应透过子分类（如大使 / 运动员 / 学者 / 演艺人员 / 留学生）间接出现，直接在传主条目添加“在**的外国人”就会出现被用户移除的行为（76216789、76219044），直接让传主条目出在“**相关人物”当然也会出现类似行为，所以一定是间接。每个人都有迁徙自由（当然也有被迫迁徙的情况），间接出现在复数个、甚至超过10个的“**相关人物”里头本来就是件再正常不过的事，“在**的外国人”亦同。--HanTsî（留言） 2025年5月5日 (一) 05:08 (UTC)[回复]
弃用“**（行政区划）人”的想法在2023年8月就表达过。--HanTsî（留言） 2025年5月5日 (一) 05:51 (UTC)[回复]
“籍贯”本就是各地定义大相径庭的概念，不宜如此使用。其条目目前的定义句“籍贯，通常指父亲与祖父的长居地”涉嫌以中国大陆为中心；况且“父亲与祖父的长居地”几乎不会出现在条目序言，毋庸置疑无法define人——defining是英维分类相较中维分类更为宽松的要求，更遑论合乎中维更为严格的“定义性特征”。“父亲与祖父的长居地”若为任何分类标准，则会导致此等分类灭绝。--— Gohan 2025年5月6日 (二) 03:44 (UTC)[回复]
@Sinsyuan：据方针WP:讨论发起位置“讨论结束后亦应让讨论原地存档，避免重复在多个页面存档后出现讨论分支。”，我移除了你添加的{{存档至|WT:生者传记}}模板，也请之后不要再添加了。籍贯问题也远不止包括生者传记。若需留讨论记录可以向这些信息框的讨论页发送讨论通告来链接。 ——自由雨日🌧️❄️ 2025年5月8日 (四) 06:54 (UTC)[回复]

模板爆炸

一些大型条目模板爆炸了，比如反送中运动和五月风暴。遇到类似情况如何处置？╮(╯_╰)╭--KurGenera(留言) 2025年5月4日 (日) 14:57 (UTC)[回复]

分类:引用模板后大小超过限制的页面。有时候把{{NoteTA}}改为{{NoteTA-lite}}可以解决。--Kcx36（留言） 2025年5月4日 (日) 20:11 (UTC)[回复]
@Kcx36：改了改反送中运动，它的模板还是炸的。还是说放着不管等有人清理好？（400K字节还是太多了）--KurGenera(留言) 2025年5月5日 (一) 03:30 (UTC)[回复]

人物信息框不用挂国旗了？

我看很多人物条目信息框里的国籍、政党、居住地等内容不再挂国旗了，例如带国旗的“ 中华人民共和国”变成了纯文字的“中华人民共和国”，是出了什么新的方针指引吗？求教。--侧耳·倾听 2025年5月5日 (一) 13:28 (UTC)[回复]

MOS:信息框旗帜，另见该指引的讨论页。--YFdyh000（留言） 2025年5月5日 (一) 13:35 (UTC)[回复]

Alzheimer's 台湾用语

本主题或以下段落文字，在讨论结束后应存档至Talk:阿尔茨海默病、Module talk:CGroup/Medicine。

“阿茲海默症”才是“Alzheimer's disease”在台湾的主流中文用语，以下5个数据库（横跨坊间、官方、学术）的搜寻结果分布显而易见：

数据库 阿茲海默症 阿茲海默氏症 阿滋海默症 阿滋海默氏症 阿茲海默病 阿茲海默氏病 阿滋海默病 阿滋海默氏病
自由时报 1,769 81 54 5 14 3 - 1
中时新闻网 530 23 4 - 10 - 1 -
康健杂志 742 55 9 1 4 1 - -
卫生福利部 1,870 454 4 225 47 153 1 6
台湾硕博士论文系统 1,463 323 99 42 50 14 4 2
注：卫福部全文检索系统使用“关键字搜寻”结果（""）；论文系统勾选“论文名称”、“关键词”、“摘要”，查询模式选“精准”

--Seanetienne（留言） 2025年5月5日 (一) 16:03 (UTC)[回复]

想请教一下大陆及香港方面对于此一疾病的正式称呼及最通俗称呼各是什么？确定以后，可据此调整地区词转换。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月6日 (二) 05:45 (UTC)[回复]
大陆方面，术语在线、《ICD-11 精神、行为与神经发育障碍临床描述与诊断指南》、《精神病学》（第9版）等均称“阿尔茨海默病”。 ——自由雨日🌧️❄️ 2025年5月6日 (二) 05:56 (UTC)[回复]
香港的通俗称呼是“阿兹海默症”，正式的话不太清楚。--惣流·明日香·兰格雷不姓式波 2025年5月8日 (四) 07:25 (UTC)[回复]
台湾地区词最佳设定值是谁，一目了然，某用户还是坚持disease要翻成“病”、syndrome才能翻成“症”，非按此规则就是“错误”的，殊不知台大医院早就示范台湾人充足的理解力：“阿茲海默症是一种不可逆，进展性的脑部疾病。”以为一份挂在台湾临床失智症学会网站的对照表具有绝对权威性（Special:Diff/84214853、Special:Diff/84214885），但同一份文件Alzheimer's作“阿茲海默氏病”而Parkinson's作“巴金森氏症”，况且从该学会的其他发布看来，“阿茲海默氏病”不尽然是他们的政策。
此问题也发生在Parkinson's那里，屡次不听劝阻（Special:Diff/84198874，Special:Diff/84202322，Special:Diff/84203456），而且不讳言瞧不起台湾的用语形式（Special:Diff/84202316）。如今，具体数据摆在眼前，共识状态明确——大众媒体压倒性90%以上用的正如我所说；政府机关、学界也有过半使用特定形式，且90%以上者用“症”不用“病”。在Wikidata那里的举动不说，现在明确证据摊出来了，干脆不演了，直接冲了（Special:Diff/87161376）。他的一意孤行，做了错误表述，边缘化了90%的台湾读者。像这样，跟本不屑地区用词实务者，没有资格着手用语转换，就此例而言，尤其是台湾的用语。--Seanetienne（留言） 2025年5月6日 (二) 15:28 (UTC)[回复]
如果可以，请给出一些适合用来注释台湾方面译名的官方文件或医学辞典（至少能对标大陆地区词）。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月6日 (二) 20:40 (UTC)[回复]
Google上查到的有：2008年行政院卫生署主编的《实用医学辞典》；国家教育研究院2015年出的《医学名词》，看来已经纳入乐词网了（医学名词中译手册- 医事司）。Seanetienne（留言） 2025年5月7日 (三) 17:02 (UTC)[回复]

浦东新区、滨海新区这样的区划能不能算市辖区？

浦东新区、滨海新区在中文里最后一个字是区，因此不太存在和区相比的分辨。然而“新区”似乎是一个整体性的专有名词，似乎不应被视为市辖区。前者在英文里对应new area，后者则是district，浦东新区历史上也是历经八年才开始有人民政府、人民代表大会等建制的，维基百科应该如何处理这个问题为宜？--∮♩♪♫♬♭♮♯☧⚧☦︎ 2025年5月6日 (二) 05:28 (UTC)[回复]

要处理的问题是什么？阁下列举的浦东新区、滨海新区现时皆为行政区划上的市辖区，但我知道您想要讨论的对象应该是湘江新区这种。单指标题的问题的话，如果是浦东、滨海，完全且应该算作市辖区，但湘江新区这种显然不算市辖区。--Hamish T 2025年5月6日 (二) 05:30 (UTC)[回复]
浦东新区和滨海新区是上海和天津下辖的行政单位没错，但属不属于“市辖区”类目，应不应该这么描述我认为似乎有讨论空间--∮♩♪♫♬♭♮♯☧⚧☦︎ 2025年5月6日 (二) 14:55 (UTC)[回复]
浦东新区、滨海新区是国务院发文批复（国函〔1992〕145号、国函〔2009〕125号）、民政部正式登记的县级行政区。其他新区、开发区大多是黑区。--Kcx36（留言） 2025年5月6日 (二) 08:31 (UTC)[回复]
1992-145和2009-125确实是有批复，但是这个批复并没有认定浦东新区和滨海新区是这个地方本来的那种市辖区，新区和区甚至采用了不同的英文单词，而且尤其是浦东新区，在1992-145后8年才正式建立人民政府和人民代表大会，在这之前浦东新区就只是个管委会管理的新区，很明显不符合一般认知的“市辖区”，是否应该认为浦东新区和滨海新区不属于“市辖区”，而是一种特殊的、扩权的“新区”？--∮♩♪♫♬♭♮♯☧⚧☦︎ 2025年5月6日 (二) 15:00 (UTC)[回复]
根据中华人民共和国民政部 (编). 《2018中华人民共和国行政区划简册》. 北京: 中国地图出版社. 2018. ISBN 978-7-5204-0423-5. 、《中华人民共和国行政区划代码》（GB/T 2260-2007）、[16]，浦东新区、滨海新区是市辖区。根据[17]，行政区划名称没有官方英文名，只有官方罗马字母拼写（汉语拼音）。--Kcx36（留言） 2025年5月6日 (二) 15:13 (UTC)[回复]
附议K君。同时我也重复一遍，阁下列举的浦东新区、滨海新区现时皆为行政区划上的市辖区。这两个区是有行政区划代码的。您不必纠结这两个区，您要纠结的是湘江新区等这些没有行政区划代码的“新区”，所以您要纠结的问题是条目内如何标注这些区域的属性吗？--Hamish T 2025年5月6日 (二) 19:36 (UTC)[回复]

新闻局登记证号等纯审查／分级编号可否纳入资讯框？

以往中华民国行政院新闻局对其审查的书刊赋予编号——登记证号，此非国际标准书号（ISBN）或图书分类法等可为大众索引的编码；如今多国多地仍有影视以至唱片、游戏等的纯供审查或分级的编号，之于普罗大众亦无索引作用。故有以下问题：

  1. 对于大众，美中以外多国标准书号或图书分类法编号似比任何审查／分级编号更具索引价值，是否比审查／分级编号更值得纳入资讯框？
  2. 审查／分级的公开意见／结果是否比其编号更具百科价值？更值得纳入条目？或应置于较其编号更显眼的位置？
    • 如审查结果（例如（不）通过）的百科价值不低于其编号，{{电影信息框}}的“公映许可”／{{电视节目信息框}}的“发行许可”栏可否在列明可靠来源的前提下填写为“有”、“无”或“撤销”？“有”、“无”或“撤销”是否比一串数码更符合“许可”一词的意指？
  3. 审查／分级编号是否爱好者资讯？可否纳入资讯框？
    1. 如可，任何政治实体的审查／分级编号可否平等地纳入资讯框？
      1. 如可，{{电影信息框}}的“公映许可”／{{电视节目信息框}}的“发行许可”栏可否填入中国大陆以外的“许可”情形，抑或另设参数？
        • 已知中国大陆的公映、电视节目、网络视听节目、音像制品分有不同审查系统及编码字样，即电影在中国大陆不获公映许可而仍可通过网络视听节目或音像制品审查并合法发行；故在{{电影信息框}}可否增设“网络视听节目”、“音像制品”的“发行许可”栏目？
      2. 如可，已知新加坡、香港等豁免部分类别电影分级；可否对获豁免电影的“许可”情形填入“豁免”等表述？
    2. 如可，已知台湾等分级、中国大陆的审查均对同一电影的不同（语音／格式等）版本分别赋予编号；{{电影信息框}}的“公映许可”栏可否列出全部版本编号？抑或仅可列出首轮公映2D原声最高分级版本的编号？
    3. 如可，已知申请中国大陆公映的电影在初审通过后即可取得许可证编号，但有许可证编号不意味通过终审或获得公映许可证，则在中国大陆通过初审而不通过终审的电影在{{电影信息框}}的“公映许可”栏，如列明可靠来源，可否一并填写“不获公映许可”及其编号，或仅填写其编号？

--— Gohan 2025年5月6日 (二) 10:02 (UTC)[回复]

结构化数据首先考虑维基数据。如果有官方页面可查编号得到较多的进一步信息，可考虑以外链意义放在信息框，否则单纯编号不建议提供给读者，读者无法快速理解和运用。如果“无”“撤销”是不常见、通常会被条目正文介绍的，信息框写入千篇一律的“有”或者无额外信息的“无”可能意义不大？提供单纯索引号而无功用价值可能WP:RAWDATA？注明“情形”可能需要理解因果，比如相关内部链接。不同版本，我倾向维基数据及其优先级、修饰符功能。编号旁的状态，如果能统一写法规格，不反对加注。--YFdyh000（留言） 2025年5月6日 (二) 10:26 (UTC)[回复]
以较多需要当局审查或分级的电影为例，美国、新加坡、台湾、香港、中国大陆等结果均无网址单独固定的网页。单纯编号的确意义不大。维基数据确是现有编号的理想归宿。--— Gohan 2025年5月7日 (三) 08:46 (UTC)[回复]
(＋)支持写入维基数据内。--自由米花🌾🌼 2025年5月8日 (四) 13:03 (UTC)[回复]
据方针WP:讨论发起位置“讨论结束后亦应让讨论原地存档，避免重复在多个页面存档后出现讨论分支。”，移除{{存档至|Template talk:电影信息框|Template talk:电视节目信息框|Template talk:Infobox book}}模板。若需留讨论记录可以向这些信息框的讨论页发送讨论通告来链接。 ——自由雨日🌧️❄️ 2025年5月6日 (二) 11:39 (UTC)[回复]

是否加入球形地图

英维国家信息中的地图绝大部分国家的都是第一张为球形地图，之后才是局部，中维是否应该仿照英维编写。--Gdagys（留言） 2025年5月6日 (二) 14:04 (UTC)[回复]

关于征求来源系列维护模板的字句修订

这其实算是我在条目探讨一则留言的后续。维基百科目前存在大量征求来源维护模板，大多措辞如下：

维基百科所有的内容都应该可供查证。请协助补充可靠来源以改善这篇条目。无法查证的内容可能会因为异议提出而被移除。

——{{Unreferenced}}

请协助补充多方面可靠来源以改善这篇条目。

——{{Onesource}}、{{Refimprove}}

请协助补充可靠来源，无法查证的在世人物内容将被立即移除。

——{{BLPsources}}

由此可见，这些模板都要求我们“补充来源”。这本是好事，但既然“可供查证是维基百科内容的门槛”，我们要做的不单是“补充”，更是“根据新来源重写”；不是“用来源证明现有文字”，而是“将可靠来源的各个主要观点都写下来”。因此，我提议征求来源维护模板和相关模板中的“补充来源”替换为“根据新来源重写”，例子如下：

维基百科所有的内容都应该可供查证。请协助根据可靠来源重写本条目。无法查证的内容可能会因为异议提出而被移除。

——{{Unreferenced}}

请协助根据可靠来源重写目前依赖第一手来源的内容以改善这篇条目。

——{{Onesource}}

请协助根据可靠来源重写目前无法查证的内容以改善这篇条目。

——{{Refimprove}}

请协助根据可靠来源重写目前无法查证的内容，无法查证的在世人物内容将被立即移除。

——{{BLPsources}}

以上，提请诸君讨论。1F616EMO（喵留言～回复请ping） 2025年5月8日 (四) 13:16 (UTC)[回复]

(＋)支持，之前完全没想到这一点，我觉得想法非常好。另外看到这一提案，我个人主要想到的理由倒没有“要求‘将可靠来源的各个主要观点都写下来”那么强（当然这绝对是最应该做的事），我想到的是：无来源内容大多是编者随手写的低质内容，本身就并非是来自于可靠来源，因而改善途径自然不应是“找可靠来源去生拼硬凑地来佐证原本就并非出自可靠来源的表述”，而是重写。 ——自由雨日🌧️❄️ 2025年5月8日 (四) 13:20 (UTC)[回复]

有关在建城市轨道交通条目中的计划通车时间

留意到近期广州地铁条目中的未来发展一栏，针对一些在建线路的“计划通车时间”遭到多次删改，看看各位的意见认为要不要添加“计划通车时间”以寻求共识？ @Cygz、TimWu007、Jackycheung0929--Nissangeniss（留言） 2025年5月8日 (四) 14:57 (UTC)[回复]

其他

管理操作复核请求：对Wildcursive的处理

本主题或以下段落文字，在讨论结束后应存档至Wikipedia:管理操作复核请求/存档。

已解决
鉴于社群共识，复核有关操作为不妥，并予以推翻。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月28日 (一) 09:06 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

此请求是根据Wikipedia:管理操作复核请求所提出，请先阅读相关内容。

操作： [18]
执行者： Ch.Andrew （讨论 · 贡献 · 日志）
先前讨论：维基百科:管理员布告板/其他不当行为#Wildcursive

@Wildcursive：首先，这位用户对于自己讨论页上由Cindyzs写出的宣传性内容置之不理，经我移除后再次加回。引用@薏仁将的话：……虽然WP:TPG对于用户讨论区使用自由度是相对宽松的，而本案被提报人对于相对当事者用户采取宽容容忍的态度去看待那些个人主观意识的政治观点宣传，然而被提报用户是可以有多次机会对相对用户进行劝告及以相关方针教导其用户避免再度出现不适当的行为，但被提报用户选择被动、消极的方式选择不作为的冷处理，此等则会被相对用户认为不反对即表认同的错误认知而持续性的做出不适当的行为；虽然该用户暂时已被封锁一周，但是难保解封后不再出现相同的不适当行为，而身为当事者的您，难道某个角度立场来说是无任何责任？又或者这种消极宽容的态度不也是变相的纵容对方行为？

而管理员章安德鲁对于此次提报，作出以下处理： 还原。以User:Wildcursive自行决定的版本为准/态度指引WP:OWNTALK：“对于用户讨论页而言，这些方针的遵循度会比其他讨论页较为宽松”“以上方针并不限制用户在自己的讨论页移除留言”、编辑指引WP:PUT：“您可以按照您认为合适的方式将讨论串删除、存档，或者是简要地总结以前的讨论”等语可以清楚得知，用户对于自身账号的讨论页具有裁量权，保留或删除内容由账号所有者自行决定即可，其他非当事用户无须干涉。

然而，很明显，方针（这甚至只是指引)中注明的是“较为宽松”而非“完全无需执行”，当然无法轻率得出“保留或删除内容由账号所有者自行决定即可”的结论。同时，WP:NOT中写明：“维基百科拒绝宣传。维基百科不是演讲台、讨论区、宣传工具、广告场所或者展览平台。此项适用于用户名、条目、分类、档案、讨论页、模板及用户页。”

综上所述，管理员的此次决定是不恰当的，因此我提出操作复核。 --WiiUf🐉 2024年12月20日 (五) 05:20 (UTC)[回复]

(～)补充：被提报用户在ANM进行政治宣传，而管理员完全没有考虑这点。--WiiUf🐉 2024年12月20日 (五) 05:26 (UTC)[回复]
(＋)支持复核。——自由雨日🌧️❄️ 2024年12月20日 (五) 05:54 (UTC)[回复]
(＋)支持复核：刚注意到这边有讨论，把我刚在那里留的意见改一下放这：
Ch.Andrew 解释他的处置理由有不少问题：不限制使用者在自己的讨论页‘移除’留言并没有“不限制使用者‘还原’因违反方针而被其他人移除的留言”之意，而他又以指引导出使用者对于自身账号的讨论页具有裁量权，保留或删除内容由账号所有者自行决定即可，其他非当事使用者无须干涉，然而他引用的WP:PUT是指引，WP:SOAP是方针，指引和方针冲突时是方针优先，遭移除的内容是违反方针，用指引当理由说可以保留违反方针的内容根本是无效的：
  1. 用这逻辑，每个使用者都可以在自己讨论页放这些违反方针的内容，因为自己的讨论页自己当然有裁量权啊。
  2. 当 A 把自己讨论页上被移除之违反方针内容加回去，那就是 A 的编辑行为了，原本加的人违反方针，A 当然也违反方针。
我并质疑，这个案子原本已有其他管理员开始处理，为何不常活动的 Ch.Andrew 突然介入迅速处理掉这件案子。--LHD（留言） 2024年12月20日 (五) 05:57 (UTC)[回复]
(？)疑问:另一个矛盾的点，依照处理的管理员认定的标准，那么:我只要找政治理念相同的用户B，或者用户C不反对我个人政治观点，那么我可以将那些政治观点放置在用户B与用户C个人讨论区，而且只要相对用户不反对，那么就不构成WP:SOAP相关限制(因为B、C君用户有自己裁量自己讨论区讨论议题权利)？那么请问WP:SOAP存在的意义是？那么问题来了，如果依照处理管理员认定的方式，B君与C君不表态、不反对那么那些已发生的宣传行为就不算构成WP:SOAP条件(裁量权在对方用户身上?)，那么连带的是否连WP:DE也构不上边？然后更有趣的是:如果有人删除那些政治观点，我可以仿效他作法警告那些依照理据删除的用户要他们不要“越俎代庖”(因为讯息接受者没反对，裁量权在对方用户身上)请问是这个意思吗?请问可以如此作法吗？蛮好奇这种“特殊”认定标准。--薏仁将🍀 2024年12月20日 (五) 07:29 (UTC)[回复]
可能离题请见谅，其实上次就想提出，不晓得这是否算讨论页的漏洞？我认为可能需要研讨是否需要修改，因为虽然看似不妥，但对应现行方针指引确实没有明确违规，管理员处不处理都很难。感觉上暂时实施封禁的管理员是用了共识封，不过这是中维没有的方针。若没有界定标准，往后也可能再发生，故我认为可能需要进一步另行讨论。--提斯切里（留言） 2024年12月20日 (五) 09:36 (UTC)[回复]
是的，标准的漏洞，看看届时发生处理的管理员怎么认定怎么解释或者类推适用，有没有惯例案例可循，的确需要填补漏洞，不然可能造成仿效效应。--薏仁将🍀 2024年12月20日 (五) 09:42 (UTC)[回复]
我认为不存在漏洞。明显已经违反WP:NOT。--自由雨日🌧️❄️ 2024年12月20日 (五) 09:55 (UTC)[回复]
这样就有处理落差了，我先前确实觉得这是为不妥，但现在可以理解了这是个人讨论页要如何处理的自由意志，而且以讨论页方针来说，到别人的讨论页进行“讨论的状况”不涉及宣传，那么实为不应该封禁的，管理员不处理也是正确的。
我这里指的漏洞，是要考虑这样认知差异的，而且确实不明确。--提斯切里（留言） 2024年12月20日 (五) 16:14 (UTC)[回复]
但像是比较敏感性质的议题又或者如本案般主观意识政治内容的传递，那么在认定标准上这是否为宣传行为的一种？若属于宣传行为，那么其他用户是否可依据对应的方针指引予以移除？又或者必须知会讯息接受者相关内容可能有不适当之虞?倘若讯息接收者并无任何表态亦不反对，那么这些有疑虑的内容是否仍可移除？这些可能属于比较算认定上会造成的差异(或说灰色地带)也许值得讨论。--薏仁将🍀 2024年12月20日 (五) 23:01 (UTC)[回复]
也认同 这些可能属于比较算认定上会造成的差异(或说灰色地带)也许值得讨论。。 尽管我认同“管理员不处理也是正确”, 既然社群有分歧，可以就这是个人讨论页要如何处理的自由意志，而且以讨论页方针来说，到别人的讨论页进行“讨论的状况”不涉及宣传进行专门讨论。--Gluo88（留言） 2024年12月21日 (六) 23:51 (UTC)[回复]
@Tisscherry 在下也认同 而且以讨论页方针来说，到别人的讨论页进行“讨论的状况”不涉及宣传，那么实为不应该封禁的，管理员不处理也是正确的。--Gluo88（留言） 2024年12月21日 (六) 23:45 (UTC)[回复]
版主(：)回应：本人参与维基已约二十年，我自己的讨论版面有何文字、如何回应、取舍，向来是本人的自由，几无人越权干涉，亦属尊重版主之传统，包括许多行政管理人员皆能分清界线并协助回退对本人讨论页的真实破坏，违反本人意志乱删乱动才是无礼。我对于符合《世界人权宣言》、台湾人民自主意志与“自己的国家自己救”理念及维基百科自由民主多元开放精神的善意留言基本上皆大致不反对、不反感、不反弹。美国法律规范的维基百科可不是独裁中国、专制共产党或其百毒等工具，也绝不容遭其可怜打手操控限制。若我不觉得留言不当，属表达意见、交流新旧条目编辑方向、及我可接受的言论自由，其实轮不到远不相干之他人管太宽任意置喙。
已不常回维基的我是被动回应、被迫说明，说清楚、讲明白、畅所欲言、阐明理据是必要且正常的。既然远非明显破坏、亦属无害（有被害人吗？只有我吧！），我自然有在个人留言版对合理言论自由沉默不作为、不采取任何行动或回复原状的权利！我有回应或不回应的自由。之前也有较清醒开明曾多少呼吸过较自由空气的中国人来我版谈上海独立自治、女权、汉人杀满人等。或香港人来谈鱼蛋革命等，具善意的邻国维基人来我版面跟我谈政治，我通常会予以回复，编维基百科不可或缺的事实、史实、真理与普世价值等皆属越辩越明。
每个人自己的版面多少出现与条目直接或间接相关的文字很平常。大家摸着良心自问自己或他人名下的版面其实历来有多少连个条目名称都未出现的瞎扯蛋？要倒查22年吗？我有本版言论方向尺度的管辖权与裁量权, 这历来皆属自主自治自理自决的心证自留地空间。事实上, 许多维基化留言提醒我出现哪些新条目可查阅或补充增删, 又有哪些我已知的主题议题可加强。这些留言者与其纯粹条列出那些条目要我关注, 不如写成短文表达意见, 更能吸引我的关注而参与编辑, 我看不出两种方式的关键字词有何太大差别, 但绝对更有效, 引发更多点入的好奇或编辑的欲望, 对维基也自然是好的。无谓与过度禁制对维基生产力只是有害而无益。这跟平铺直叙广告没人看、没人买单是同样的道理，Did you know的DYK问题指南“请创作可以引起读者兴趣的问题”已验证了十几年。留言者想引起我的阅读编辑兴趣，或我的回应能否引起他人的阅读编辑兴趣，从这些留言是“待协作完善清单”的角度解释，有何不可？谁曰不宜？这与真正编辑条目时需依多重可靠来源，既不违背，也能并存。“不管黑猫白猫，会捉老鼠就是好猫”，这是相同的实用主义功益考量，能促进维基发展才是硬道理。捏死窒息中维才是罪人吧。
写动漫的能在彼此讨论页边写边聊动漫，没人说不可。写日本女星的在留言板互称某某美很漂亮、喜欢某某子，是不是宣传？说今天又看了10部，打算下周增补创建其中7条，是不是宣传？写交通的小聊维基假期旅游，说想去台南高雄玩，是不是宣传？写生医的讨论疫情，写文学的聊戏剧，皆很合理。为何写法政的就不能在自版小聊法政，碍了谁吗？这种种文字在本质上有重大区别吗？
维基百科有多少比例不是“宣传”？几乎大多数的图片文字皆可被解读为具某种宣传或反宣传之意。在某些人眼中耳里，不习惯的事物都很敏感、大惊小怪，但在早已熟悉如日常生活者看来却是如呼吸般再自然平常不过。此定义模糊不明而极可能衍生超多重标准的思想与言论警察之例一开，徒费时间精力，如同让真理部、老大哥与朝阳群众管到每个人在私宅的言行、门口的对联、信箱的广告、墙上的壁画、邻居的私语、手机的通信，有人来串门子，还要被检查，实属荒谬。每个人的页面用户框等自由编排创作就是贴在家门口的宣言标语，用户对待其个人版面的方式亦属自介自治的一部分，两者的性质、内在逻辑与适用对待应属相近。若纵容少数人企图在他人版上搞扩大文革纠斗，将成永无宁日的浩劫。无处不在的监控只会制造更多争端，兹生更广冲突，转移消耗编者注意力，终成反噬人人而成庞大数位极权主义的一九八四。
如果裹小脚的慈禧看到奥运女子金牌就骂人家伤风败俗成何体统、或如果有个别极端伊斯兰教徒看到餐厅在卖猪脚火腿贡丸就呼天抢地说违逆真主要斩首、要下地狱、要烧店家，显非合理，政治控制与资讯封锁是没必要的，别让中国迄今仍时常发生的作法自毙、请君入瓮再实现，维基百科不该日益封闭退步。
管理员千村狐兔（[19]）与章安德鲁（[20]）均已表明尊重版主的态度，这基本上也是由正规编者自理其个人讨论页的传统，除非真属破坏或已被自删、警告表明不受欢迎者。企图惩处被留言者或已表明自行判断筛选者是很奇怪的事。当事人对此个案没意见、不在意、不觉得被骚扰，那就不需要再浪费时间强入人于罪。
十多年来本版基本自在自适健康无碍，天下本无事，实不烦庸人自扰扰人。--WildCursive（留言） 2024年12月20日 (五) 11:54 (UTC)[回复]
实际上维基百科并不保障你在讨论页的言论自由，维基百科并非论坛，第五点：与维基百科无关的专案内容。请勿存放与维基百科无关的材料，包括使用者空间。请参阅WP:UPNOT了解不得包含的内容的范例。
，WP:UPNOT有此外，您不得在使用者空间中包含可能损害专案声誉或可能引起广泛冒犯的材料（例如种族主义意识形态）。无论是严肃的还是恶意的，“维基百科不是演讲台”与百科全书条目一样适用于使用者空间，而“维基百科不会审查内容”则适用于条目页面和图像；在其他命名空间中则存在一些限制，旨在确保与社群的相关性及不扰乱社群。您在使用者空间确实比其他地方拥有更多的自由度，但不要粗心大意。任何编辑者都可以立即删除极具冒犯性的材料。，这些是具有冒犯性的，此外管理员的论点并不代表整个维基百科，宣传政治理念，诽谤民意代表，为不可接受的行为，例如诽谤马文君为叛国贼明显违反与维基百科无关的争论性言论，或攻击或诽谤编辑群体、个人或其他实体的言论。这些言论均被视为分裂性的并会被删除，而重新加入将被视为扰乱。，这些都是合理证据，因此删除该些留言为正当。-- A0(讨论·签名) 2024年12月21日 (六) 12:44 (UTC)[回复]
个人认为甚至可能违反UCoC第3.1 侮辱：这类行为包括恶言、侮蔑、使用刻板印象、基于个人特质的攻击行为。侮辱可指感知特质，其诸如智力、外貌、民族、种族、宗教（或无宗教信仰）、文化、种姓、性取向、认同性别、生理性别、残障、年龄、国籍、政治派别或其他特质。在部分情况中，反复地嘲笑嘲弄、讽刺挖苦、或侵犯攻击会构成集体侮辱。和引战：以故意扰乱话题或恶意地发布言论方式，有意图地挑衅他人。-- A0(讨论·签名) 2024年12月21日 (六) 12:55 (UTC)[回复]
什么叫打着维基之名，不适当就是不适当，你认为你可以去公共政策网络参与平台提案说那些吗，当然不行，因为地方错了-- A0(讨论·签名) 2024年12月21日 (六) 15:10 (UTC)[回复]
我认为我有处理我的讨论页的自由，我不想要别人插手我讨论页面的事情。实在有不合规的内容我会折叠，但我不认同别人替我删除还不让我处置。 --MilkyDefer 2024年12月20日 (五) 13:45 (UTC)[回复]
你这话就相当于在说你认为你对你的用户页和用户讨论页有所有权。--自由雨日🌧️❄️ 2024年12月20日 (五) 22:56 (UTC)[回复]
我记得使用者对于用户讨论页面仅有“使用权”，但阁下的说法，恐怕会变成用户对于自己的讨论页面及相关用户页面有“拥有权”，这错误的理解吧？。--薏仁将🍀 2024年12月20日 (五) 23:08 (UTC)[回复]
这个事件是一个编者在第三人的讨论页面发布宣传性内容（但是我认为那些内容可以搬到维基新闻做opinion piece），然后第四人意图移除内容后被还原，莫名其妙就要召唤管理员介入。此事之奇葩程度闻所未闻，因为那个编者没有滥用自己的讨论页。你们可以规定任何人不得反对他人在自己的讨论页面严格执法，但是我认为与其把原则法律化并且不断打补丁，不如让所有编者把自己的账号交出来交给三百多万个硬编码规则的机器人。--MilkyDefer 2024年12月21日 (六) 10:34 (UTC)[回复]
所以你的意思是，在条目讨论页、在用户页、在用户空间子页面均不得放置的宣传性内容，可以转而在用户讨论页放置？--自由雨日🌧️❄️ 2024年12月21日 (六) 10:38 (UTC)[回复]
👍 赞--Dryrace（留言） 2024年12月28日 (六) 10:53 (UTC)[回复]
程序问题：Wikipedia:管理操作复核请求有提到“在发起复核请求前，建议尝试与执行操作人（当事人）讨论，以解决问题”，请问提请复核之人等是否已和当事管理员进行过充分讨论沟通？虽说这只是“建议”，但是如果以后每个人都在未经充分沟通的情况下就径行提请社群复核管理员操作，恐致社群无谓困扰、消耗社群精力。-Peacearth（留言） 2024年12月20日 (五) 16:19 (UTC)[回复]
本人已根据您的建议在有关管理员的讨论页留言。由于本人已于该留言详述意见，请恕不在此重复。--派翠可夫 (留言按此) 2024年12月21日 (六) 03:50 (UTC)[回复]
若要较真需注意上述WP:NOT中所列只有用户页，并无用户讨论页。WP:TPG#别人的意见中也着重强调（而这也是使用 deltalk 中自动生成的标签所链接到的页面）{{deltalk}}是用来移除非常明显的人身攻击和不文明的留言，而涉及到的留言段落明显不属于这一类。另外想提醒一些编者，并不是所有您看到的不喜欢的内容都要跑到WP:ANM中提一个新提报，特别是本讨论中涉及到的留言并非发送给提报者。您这种行为相当于在两人间对话时擅自插嘴并大叫“我不喜欢这个对话！你们必须停止！”，这样十分不礼貌。若当事人认为此对话不妥自然会自行处理，但既然当事人认为这对话并不冒犯那我认这留言也并无大碍。我知道这留言相对于某些用户来说确实感到冒犯，但正如我之前所说，这些话并不是对您说的，您可以选择无视。参与维基百科所需要适应的一点是需要接受有用户的想法及观点与您不同，且，并不是所有您不喜欢的内容都必须删除。--广雅 范★ 2024年12月20日 (五) 19:06 (UTC)[回复]
NOT中列出了讨论页，显然用户讨论页属于讨论页。此外，《WP:用户页》指引中还列出了更广泛的适用于用户空间的条款。最后一句加粗的留言则属于混淆视听，从一开始所有人提出行为不当的理据就是宣传，而不是所谓“不喜欢的内容必须删除”。--自由雨日🌧️❄️ 2024年12月20日 (五) 23:00 (UTC)[回复]
宣传指的是对多数不特定的人推广自己的观点或者产品，如在条目空间打广告，又如在用户页大肆宣扬自己的政治立场。在讨论页这种两人对话的情况下是怎么成为宣传的呢？再者，也说过了，应由接收方判断这能不能接受，而不是完全不是接收方的第三者。--广雅 范★ 2024年12月21日 (六) 06:25 (UTC)[回复]
照这个逻辑，我放置在自己的用户页或讨论页将属于宣传的内容，我只要放在对方的讨论页，就可以避免被当作“宣传”？那以后大家做宣传只要将这些内容互相往对方讨论页放就行了，只要事先互相打好招呼，同意对方放置。--自由雨日🌧️❄️ 2024年12月21日 (六) 07:19 (UTC)[回复]
这是属于WP:GAME以及WP:POINT的行为。--广雅 范★ 2024年12月21日 (六) 07:32 (UTC)[回复]
是的，所以为什么目前他们二位未落入这个范畴呢？--自由雨日🌧️❄️ 2024年12月21日 (六) 07:36 (UTC)[回复]
范给的前设条件是“对多数不特定的人”，而且要满足WP:GAME的话一般还需要证明相关用户是带有目的性地持续这样做。Sanmosa 蚌埠 2024年12月21日 (六) 07:40 (UTC)[回复]
“对多数不特定的人”什么意思？至于“带有目的性地持续这样做”的话，从其多次被提报来看，我认为已经可以这样认为了。--自由雨日🌧️❄️ 2024年12月21日 (六) 07:42 (UTC)[回复]
“对多数不特定的人”我会理解为“无差别”，比如“对多数不特定的人攻击”相当于“无差别攻击”。Sanmosa 蚌埠 2024年12月21日 (六) 07:47 (UTC)[回复]
我没看到他给这个前设条件？（我这句指的也主要是“两人互相放置宣传材料”，当然多人互相放置也适用）--自由雨日🌧️❄️ 2024年12月21日 (六) 07:52 (UTC)[回复]
#c-范-20241221062500-自由雨日-20241220230000。Sanmosa 蚌埠 2024年12月21日 (六) 08:14 (UTC)[回复]
哦。我的意思是，“放置内容”本身就已经构成了无差别传播，因为它们是公开可见的（邮件则不是），尤其是用户讨论页，曝光率是很高的。--自由雨日🌧️❄️ 2024年12月21日 (六) 08:16 (UTC)[回复]
对多数不特定的人：比如客栈、条目、用户页，放在那里的用意就是被大家看到；带有目的性地持续这样做：被提报者是反对第三方直接修改讨论页内容，并没有持续性进行宣传的意图。--广雅 范★ 2024年12月21日 (六) 07:52 (UTC)[回复]
然而用户讨论页是仅次于用户主页的很多人会查看的页面。--自由雨日🌧️❄️ 2024年12月21日 (六) 07:53 (UTC)[回复]
另外，放置于用户子页面、访问量几乎没有的内容也是可以因宣传而删除的。--自由雨日🌧️❄️ 2024年12月21日 (六) 07:57 (UTC)[回复]
那么本案例中被删除的留言是违反了WP:TPG#别人的意见内的哪一条呢？--广雅 范★ 2024年12月21日 (六) 08:11 (UTC)[回复]
违反了WP:SOAP ——自由雨日🌧️❄️ 2024年12月21日 (六) 08:13 (UTC)[回复]
这是编辑他人的留言，操作需符合WP:TPG#别人的意见中的一点。--广雅 范★ 2024年12月21日 (六) 09:36 (UTC)[回复]
违反了SOAP啊。“移除不允许的资料，例如……等”。--自由雨日🌧️❄️ 2024年12月21日 (六) 12:00 (UTC)[回复]
违反了WP:NOTADVOCACY，作任何游说、宣传或招揽，包括商业、政治、科学、宗教、国家、体育或其他性质。条目当然可以客观地描述某人或事物，但必须符合中立观点。如有观点或意见希望得到其他人支持，请移驾至个人网志或论坛。，即为宣传政治，且本条适用所有命名空间。-- A0(讨论·签名) 2024年12月21日 (六) 12:51 (UTC)[回复]
还有WP:NOTOPINION-- A0(讨论·签名) 2024年12月21日 (六) 12:52 (UTC)[回复]
还有WP:NPA，攻击某些特定政治人物-- A0(讨论·签名) 2024年12月21日 (六) 13:06 (UTC)[回复]
(！)意见:一些有趣的问题请教参与议题的诸位
  1. 用户讨论区算不算讨论区的一种型态展现？
  2. 承上，若用户讨论区属于讨论区的一种呈现样态，那么试问用户讨论区是否也受到WP:SOAP规范限制范畴内？若用户讨论区非讨论区定义条件，那么也请说明其认定意见。
  3. 用户A传送高敏感议题(如：政治观点，如XXXX年的选举活动理想政治人选)传递投放给与其他用户至其讨论区，请问是否构成宣传行为？
  4. 承上假设这是构成WP:SOAP行为条件定义，而传递者也依照前述遭管理员封锁，那么请问：消极、被动不表任示何立场的讯息接收用户B消极不移除那些敏感话题而任凭展示，试问是否同样构成WP:SOAP相关要件？传递者被管理员封锁，难道相对讯息接收者就无需收到任何管理员口头提醒警告，告知该等敏感内容有WP:SOAP之虞，要求对方移除？
请参与该议题的诸位好好思考一下提问内容，思考这件议案处理是否妥适，谢谢。--薏仁将🍀 2024年12月21日 (六) 00:23 (UTC)[回复]
用户命名空间相对起维基百科命名空间及条目命名空间来说更具有私人性质，正如一般不允许随意修改他人用户页一样，用户讨论页的内容也应该由页主自行定夺。您的第三点确实构成了宣传，但如果 A 因为宣传被封这是因为他做出了“宣传”这种不当行为，而不是单凭他发的内容。B 作为宣传材料的接收者，若觉得无需理会则不移除并没有什么问题。不像维基百科命名空间会有多人同时参与讨论与条目命名空间会被索引，用户讨论页一般是对该用户的留言区，依我看来不是“任凭展示”。--广雅 范★ 2024年12月21日 (六) 06:34 (UTC)[回复]
感谢阁下特地拨冗协助厘清与回复，所以阁下认为:用户讨论区亦属于讨论区的样态形式，但是由于定位上属于个别用户“私人”性质，所以界定上，即便他人传递高敏感内容议题，则裁量权(删除、存档、保留)这些权益则属于个别用户的权利范围之内，而若没明显违反不文明、人身攻击，对方用户不排斥亦不反对情形下，第三方用户则毋须介入处理，请问如此解释是否正确？--薏仁将🍀 2024年12月21日 (六) 06:54 (UTC)[回复]
是的，我是这样认为的。--广雅 范★ 2024年12月21日 (六) 07:02 (UTC)[回复]
那这样子的话，基本上，照原处理管理员处理方式(还原对方用户遭他方用户介入移除的内容)是没有太多问题的，感谢阁下协助厘清。--薏仁将🍀 2024年12月21日 (六) 07:11 (UTC)[回复]
WP:NOTSOCIAL，WP:NOTHERE，显著违反方针的内容，移除行为无需经由任何人同意。->>Vocal&Guitar->>留言 2024年12月21日 (六) 07:18 (UTC)[回复]
这里我觉得值得关注的一点是“与维基百科相关的资料”应该如何解读，因为不同的解读方式会影响Ch.Andrew的操作具备正当性与否。Sanmosa 蚌埠 2024年12月21日 (六) 07:31 (UTC)[回复]
@WiiUf。Sanmosa 蚌埠 2024年12月21日 (六) 07:32 (UTC)[回复]
顺便也ping一下@薏仁將。Sanmosa 蚌埠 2024年12月21日 (六) 07:41 (UTC)[回复]
这个要看切入的点是什么，所以我才会设置那些问题问参与讨论的诸位，貌似范君与原处置的管理员看法立场是近似的，但是我仍倾向认为即便是私人的性质，则也不应当消极任凭放置具有敏感争议的宣传材料，这边可能需要诸位需进一步厘清讨论，我个人觉得可能会有用户会利用这种认知判断差异落差而作仿效，届时倘若要规范，恐怕也许会被对方说嘴。--薏仁将🍀 2024年12月21日 (六) 07:54 (UTC)[回复]
我的问题是“与维基百科相关的资料”到底是说“与维基百科此一项目本身相关的资料”还是说“与维基百科的内容相关的资料”？Sanmosa 蚌埠 2024年12月21日 (六) 08:12 (UTC)[回复]
应该是被定义成:“与协作改善维基百科条目或者商讨相关姐妹计划、本身或内容相关联性议题”不论是个人前述定义或者您提出的二个要件，传送个人政治观点给与他人这已经很明确是“宣传行为”，不用怀疑；但是那些政治观点内容放置，似乎不像是“与维基百科存在相关性的资料”，就直接开门见山的问:一则202X年XXX直辖县市长选举理想人选被放置于用户讨论区，你能说明它关条目协作改善或维基百科相关性质议题资料有什么相关性？没有啊，不就是个人主观评价的内容？好像根本与条目改善协作或者相关议题商讨无关联性吧？--薏仁将🍀 2024年12月21日 (六) 08:35 (UTC)[回复]
我提这点主要是给大家一个思考的方向，我大致理解你的意见了。亲，我签名那刻的时间是 2024年12月22日 (日) 08:49 (UTC)[回复]
其实有关页面内容的方针是可适用于使用者页面空间的，标题以User（使用者）和User talk（使用者讨论）开头的页面都被视为使用者页面。另外当用户发现其用户讨论页面有使用不当情形，则应优先发布{{subst:uw-userpage}}提醒通知。--薏仁将🍀 2024年12月26日 (四) 11:02 (UTC)[回复]
@薏仁將：我留意到用户页指引在今年11月有过一次修订，我在VPP那边就著那个修订提了一些问题，其中就牵涉到“用户页（面）”一词的理解，这恐怕也会影响这里的结果。Sanmosa 兰絮 2024年12月28日 (六) 15:30 (UTC)[回复]
但至少“用户讨论页”无疑是属于“讨论页”的，故用户讨论页肯定是适用WP:SOAP的。--自由雨日🌧️❄️ 2024年12月28日 (六) 15:34 (UTC)[回复]
说“无疑”太绝对了，至少敝人个人是持疑的。敝人认为，“讨论页”和“用户讨论页”是不同的页面，WP:SOAP仅适用于前者。--Matt Smith（留言） 2024年12月29日 (日) 02:23 (UTC)[回复]
那你得拿出证据，而不是空穴来风。--自由雨日🌧️❄️ 2024年12月29日 (日) 03:53 (UTC)[回复]
法律无明文规定者，不为罪。WP:SOAP说适用对象是“用户名、条目、分类、档案、讨论页、模板及用户页”，这些对象中关于用户的只有“用户页”，没有“用户讨论页”。--Matt Smith（留言） 2024年12月29日 (日) 04:38 (UTC)[回复]
WP:UP，标题以User（使用者）和User talk（使用者讨论）命名空间开头的页面都被视为使用者页面。-- A0(讨论·签名) 2024年12月29日 (日) 04:41 (UTC)[回复]
我前面早已回复“用户讨论页”属于“讨论页”。--自由雨日🌧️❄️ 2024年12月29日 (日) 04:44 (UTC)[回复]
标题以User（使用者）和User talk（使用者讨论）开头的页面都被视为使用者页面，皆须受内容方针规范，只是为了用户使用用户讨论页便利性及弹性，规定较宽松，但宽松不代表完全不受限制，这点要先厘清，而前面内容皆在使用者页面有相同说明。--薏仁将🍀 2024年12月29日 (日) 04:56 (UTC)[回复]
了解，谢谢。--Matt Smith（留言） 2024年12月29日 (日) 05:04 (UTC)[回复]
您好，使用者页面上的衍生定义应当是不妨害影响这边的讨论结果，因为它可以帮助厘清究竟使用者页面的范围包括在哪？限制又在哪？还是说其实定义所指向的标的为全然不同的东西？--薏仁将🍀 2024年12月28日 (六) 21:19 (UTC)[回复]
于我而言，新版条文的规定无法使我有效判断两者是否为全然不同的东西，因此这个问题我无法解答，而这也是我要在VPP寻求解决方案的原因。Sanmosa 兰絮 2024年12月29日 (日) 03:49 (UTC)[回复]
我想问大家，那今天夏土贤如果是在讨论页发表的话，照以上的逻辑，是不是就可以了-- A0(讨论·签名) 2024年12月21日 (六) 10:08 (UTC)[回复]
这样说吧，发表是一回事，移除是另一回事。用户不能任意发表不当言论或许并不意味用户可以任意移除不当言论。亲，我簽名那刻的時間是 2024年12月21日 (六) 13:36 (UTC)[回复]
这好像转移焦点了吧？假如目前被提报（及复核）的是移除留言的人，这条评论（评价移除操作是否恰当）才对题。但这里讨论的是将宣传性内容加回的用户的“加回”操作。——自由雨日🌧️❄️ 2024年12月21日 (六) 21:48 (UTC)[回复]
然而这里也涉及到一个逻辑问题，就是如果移除操作本身并不恰当，那移除操作是应该要被无效化的，那Ch.Andrew的操作就不能被认为不具备正当性。亲，我签名那刻的时间是 2024年12月21日 (六) 23:29 (UTC)[回复]
哦，那就是我前面论证的我认为这一内容本身确实不应存在了（毕竟放置于几乎无人访问的用户子页面、且我认为宣传意味并不如本案高的内容，社群共识也是删除）——即我认为移除是正当合理的。--自由雨日🌧️❄️ 2024年12月21日 (六) 23:32 (UTC)[回复]
然而我这里也主张言论本身是否不当与移除是否正当合理不存在直接的关系。亲，我签名那刻的时间是 2024年12月22日 (日) 00:09 (UTC)[回复]
你的意思是二个问题(行为)要分开看分开讨论，对吗？--薏仁将🍀 2024年12月22日 (日) 00:16 (UTC)[回复]
是的，你可以这样理解。亲，我签名那刻的时间是 2024年12月22日 (日) 08:48 (UTC)[回复]
是说之前好像有个民众党党工因为宣传被封进了是吧，刚才翻了一下讨论页，守望者爱孟在2017年说了Wild阁下这里是维基百科的民进党总部，Jackac就是深爱台湾的请愿民众。。。哈哈哈，大概好久前就是这样了-- A0(讨论·签名) 2024年12月22日 (日) 01:16 (UTC)[回复]
(！)意见： 从讨论中看到，对是否可以删除其他人个人讨论页上的这类留言，以及恢复自己个人讨论页被他人删除的这类留言争议不小。当对立双方的判断不一致时，往往会导致编辑删除和恢复的反复。
  1. 鉴于双方的判断具有主观性，是否可以看作是编辑争议， 是否可以通过提报到编辑争议页面，由社群讨论并形成共识后再处理？
  2. 若有人违反共识进行操作，则可再提报至“维基百科:管理员布告板/其他不当行为”，并在此阶段请求管理员介入处理, 注重讨论建设性与公平性。
--Gluo88（留言） 2024年12月21日 (六) 19:12 (UTC)[回复]
Cindyzs等用户在该讨论页所作所为显然与建设维基百科毫无关联。若Wildcursive想恢复其留言，唯一合理的理由就是这些留言与维基百科及社群相关，而不是其对讨论页的所有权，因为用户并没有对这种绝对的裁量权。至于拿着自由民主及思想自由说事的部分用户，仿佛是搞不清Wikimedia不是政府、第一修正案并不适用于此一样。看上去仿佛自己是民主斗士，实际上和拿法律条文要求维基百科自我审查的用户没什么区别，完全是无效论据。不重视社群共识，恰恰是与维基媒体运动的行事方式背道而驰的。——暁月凛奈 (留言) 2024年12月22日 (日) 00:37 (UTC)[回复]
那今天他说铲除亲中国势力者，是否会造成大陆编者或政治立场偏向大陆之编者之不快或感受到人身威胁，这明显非文明，又或是否违反UCoC第2.1我们期望所有维基媒体人都能对他人表示尊重。不论在维基媒体的线上还是线下环境，在与他人交流过程中，我们要以互相尊重的态度对待对方。，分明是不行的，明显具有重大违规事宜，那怎么能够保留，又说他人是无耻政客，亦不尊重对面政治立场的人，所以维基百科根本是不容许这些的。-- A0(讨论·签名) 2024年12月22日 (日) 09:15 (UTC)[回复]
什么叫做“那今天他说铲除亲中国势力者”，请你不要把我没说过写过的话塞给我！如果你指的是Cindyzs说的，他留言以来，我对话页也没出现那样的文字。这已是你至少第二次胡乱把我没写的文字栽赃给我，易生误会。至于Cindyzs在我讨论页明白引用黄国昌的前一个党时代力量及其党主席王婉谕批他是“无耻政客”，这是有来源转述，我不认为他这样写有何大问题。至于为何他要特别提黄国昌，我猜是因为那其实是我于2013年创建的页面[21]，无论他是奚落暗讽我、感叹我为何当年如此，我都没意见，这也算针对编辑史交换意见。我看不出有什么好屡屡删除的。--WildCursive（留言） 2024年12月24日 (二) 04:01 (UTC)[回复]
我指的本来就不是你啊，这里是说soap的争论-- A0(讨论·签名) 2024年12月24日 (二) 04:45 (UTC)[回复]
戒严那边-- A0(讨论·签名) 2024年12月24日 (二) 04:46 (UTC)[回复]
WP:OWNTALK，有提到对于使用者讨论页而言，这些方针的遵循度会比其他讨论页较为宽松，虽然留言内容看起来处处和方针指引相悖，也引起了反应，但这实质都不属于违规的部分，因为使用者对于自己的讨论页拥有自主权，而且发布的位置不是被严格规范的。试问，今天若是情况相反，Wildcursive使用者无法移除他不想留的内容，而到布告板寻求帮助，但是大家都跟他说这没有违规所以不能删除，适当的处理状况不应该是，让使用者自己决定什么留言可以留什么不留，只要他不剪贴拼接扭曲意思，要帮助的时候管理员适当地提供协助，这样才是合乎讨论页自主权的。
这边另外想建议@Wildcursive，我留意到同样内容的留言您放了几个地方，在个人讨论页是为宽松的留言，但若上了客栈或布告板就有为难的状况，我先前没表达很好，不过我想请您考虑自行减去会违反讨论页方针的内容，这样或许会对讨论的结果较为友善。--提斯切里（留言） 2024年12月22日 (日) 10:04 (UTC)[回复]
较为宽松并不代表不适用-- A0(讨论·签名) 2024年12月22日 (日) 10:06 (UTC)[回复]
@Tisscherry： 我就是在个人讨论页回应，主文也放被提报页及此客栈，我不可能期待大家都翻来翻去的看，总该让我在被公审处完整陈述吧。有人说删了还是有纪录，有心人都看得见，我也没啥好隐藏的。人有偏好与惯性，我删了这，说不定你想的是那，若直接告诉我还可商榷或讨论。父子骑驴讨好不了谁，我还是集中摆在一起，也会再抽空增修。我是被动回应、被迫说明，难得一次自辩，如同答辩书给各审不算超过，这是程序正义，称不上宣传。--WildCursive（留言） 2024年12月24日 (二) 05:29 (UTC)[回复]
@Wildcursive君，我主要指的是最新的金牌的那段，放在客栈和布告板就不太妥当，且平心而论，这含有的身份识别较为强烈，可能不是那么公允，这让我想到之前曾经介入个体育项目的沟通，该名使用者认为不懂篮球的都是女性，后来一直用“你”指称本人，一直要我去问男朋友或老公（？？？）。我想您应该能够明白，就点到为止了。删了的记录可以请求版本删除做隐藏，如果不会请求，直接找线上管理员也是可以的。--提斯切里（留言） 2024年12月24日 (二) 11:22 (UTC)[回复]
@Tisscherry： 既然你/你点明，请管理员删除似乎耗些工程也未必即时、全面，本想用删除线，想想还是略修。--WildCursive（留言） 2024年12月25日 (三) 00:26 (UTC)[回复]
这人也跟夏土贤一样整天嘴上挂着文革-- A0(讨论·签名) 2024年12月24日 (二) 12:21 (UTC)[回复]
@Wildcursive君，您可以直接找Manchiu管理员，他处理很有经验的。谢谢您愿意考量，就看您的决定了。--提斯切里（留言） 2024年12月25日 (三) 01:12 (UTC)[回复]
(＋)支持复核，本人不认为管理员此举得当，理应予以讨论页编辑禁制。--Talimu0518（留言） 2024年12月23日 (一) 14:07 (UTC)[回复]
我是觉得，如果有谁移除了不合适的内容，讨论页主人不应该恢复，否则应该要算到他头上。我自己对于我自己的讨论页也是很开放，胡话我不小心回退了都会撤回。但是来反破坏的移除留言我是不会加回来的。不过没收别人的星章还是不妥，我觉得W应该恢复这条。 ——魔琴［身份声明 留言 贡献 PJ:NEW23］ 2024年12月24日 (二) 11:59 (UTC)[回复]
(－)反对复核，方针或指引未明文限制用户处置其对话页的内容。--Matt Smith（留言） 2024年12月25日 (三) 02:57 (UTC)[回复]
(！)意见:在使用者页面开宗名义的就已经说明:“使用者页面用于维基人之间的交流与协同运作。虽然您可以自由地个性化和管理您的使用者空间，但它们是社群专案页面，而不是个人网站、部落格、社群网络媒体或维基百科条目。它们应该用于更好地参与社群，而不是过度用于无关目的或损害专案的声誉。”而同一个规范章节对于使用者页面定义是:“使用者页面主要用于人际讨论、通知、测试和草稿（参见沙盒），以及（如果需要）有限的自传和个人内容。标题以User（使用者）和User talk（使用者讨论）命名空间开头的页面都被视为使用者页面。”，是故，如果以定义去结合相关前述条件限制，消极的置放政治观点议题是不允许的，只是解释的人没有前后上下文的关联性给找出来罢了，所以纵使讯息接收用户认为政治观点属于一种言论表达的自由，但综合前述对于使用者页面定义与限制条件，仍不可以放置于用户讨论页面，因为视为宣传行为。这样子解释有清楚吗？--薏仁将🍀 2024年12月26日 (四) 09:05 (UTC)[回复]
(～)补充:被提报者目前已被管理员做出相关限制措施，请参照WP:ANO#Wildcursive及Special:Diff/85443983描述案件处理，询问@WiiUf君是否考虑撤销提案？--薏仁将🍀 2024年12月26日 (四) 09:17 (UTC)[回复]
管理操作复核重点是复核“管理操作”本身（WP:管理操作复核请求），被提报者后续是否有被限制，并不影响这里的复核吧？--自由雨日🌧️❄️ 2024年12月26日 (四) 09:22 (UTC)[回复]
了解。--薏仁将🍀 2024年12月26日 (四) 09:46 (UTC)[回复]
(！)意见：看了以上一大串，很惊讶这会有这么大的讨论。相关惯例已行之有年，并形成指引。用户讨论页是用来让编辑之间讨论的，尊重用户编辑本身的意愿是惯例，应以用户以及跟他正在交流中的编辑为主。第三方直接进入，介入对话，强制进行删除，不符合指引，也不礼貌。指引方针为“一般情况下，应避免大量编辑其他人的用户页和用户讨论页，除非编辑可能会有帮助。如果不确定，请询问。 ”如果第三方编辑对留言有意见，不应该直接进入删除别人的留言，因为这会影响到原本两位编辑之间的交流，扭曲留言的意思。“如果对某个用户的页面有顾虑，最好的办法是通过讨论页引起对方的注意。如果对方同意，就让对方自己编辑。”如果认为这段对话真的有必要移除，用户不愿意主动进行，应该在社群页面发起议题讨论，经过社群达成共识之后，再根据共识，礼貌的请用户移除相关段落。以尊重惯例来进行处理，为最好方向。--Alfredo ougaowen（留言） 2024年12月26日 (四) 15:08 (UTC)[回复]
刚刚看到他已经被部分封锁了，这个复核请求可以关闭了吧。Пусть от победы☆к победе ведёт! 2024年12月26日 (四) 16:22 (UTC)[回复]
上面我有提过看看原提出用户是否愿意撤回提案，但自由雨日君认为，这并不影响复核程序进行。--薏仁将🍀 2024年12月26日 (四) 22:57 (UTC)[回复]
其实有关页面内容的方针是可适用于使用者页面空间的，标题以User（使用者）和User talk（使用者讨论）开头的页面都被视为使用者页面。另外当用户发现其用户讨论页面有使用不当情形，则应优先发布{{subst:uw-userpage}}提醒通知。另并非用户讨论页面不受其拘束，而是标题以User（使用者）和User talk（使用者讨论）开头的页面都被视为使用者页面，皆须受内容方针规范，只是为了用户使用用户讨论页便利性及弹性，规定较宽松，但宽松不代表完全不受限制，这点要先厘清。--薏仁将🍀 2024年12月26日 (四) 22:52 (UTC)[回复]
我仍然希望能够继续此次复核请求（至少应移除该用户讨论页中的广告内容）。—WiiUf🐉 2024年12月27日 (五) 10:21 (UTC)[回复]
同上，我认为应该移除该用户讨论页的违反方针内容，因此(＋)支持复核。还有上面某位前管理员的言论，感觉根本没有理解方针，或者说是为反驳而反驳。--Dryrace（留言） 2024年12月28日 (六) 10:51 (UTC)[回复]
(＋)支持复核。我认为仅移除与维基百科无关的政治宣传即可，用户讨论页存在过多的与维基百科无关的内容会容易被认为滥用。--Lanwi1Talk 2024年12月29日 (日) 09:05 (UTC)[回复]
( π )题外话讨论以过两个星期有余，差不多可以下个定论啦。--花开夜（留言） 2025年1月7日 (二) 17:28 (UTC)[回复]
@Ericliu1912：“切勿直接存档尚未正式关闭的评论。” ——自由雨日🌧️❄️ 2025年1月18日 (六) 00:24 (UTC)[回复]
@范：（87005281）“切勿直接存档尚未正式关闭的评论。” ——自由雨日🌧️❄️ 2025年4月28日 (一) 03:07 (UTC)[回复]
这个该准备关闭了--August讨论‧签名‧回复请ping 2025年4月28日 (一) 04:04 (UTC)[回复]
那也得由管理员正式关闭后才能存档😂不能像那样直接存档，WP:申请成为管理员/0xDeadbeef/第2次#Mirfaek的问题这里甚至还在讨论相关问题呢。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 04:53 (UTC)[回复]

社群普遍认为，使用者页面（包含讨论页）内容，若与百科全书建设无关，乃至于涉及政治宣传等，则可能构成对有关页面之滥用，而使用者留置此类内容的自由裁量权应受限制。与此同时，社群亦认知到相关方针与指引对于使用者讨论留有些许余地，不过就本案而言，此一方面理据未较前者稳固，而政策执行方面，社群亦倾向以前者为优先，即所谓“宽松不等于无限制”。据此，认为本案有关操作不妥，并予以推翻。诚然，认定前述不当内容，除少数显然违规者外，或有流于主观之虞，而使用者直接操作之际，亦往往容易造成无谓冲突；故处理此类问题，仍建议按个案情况，或提醒、督促当事人自行移除，乃至于寻求社群更广泛讨论，此后再行决定为妥，并此叙明。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月28日 (一) 09:06 (UTC)[回复]

个人意见一向是应尽量宽容，但显然社群对此并不太青睐（ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月28日 (一) 09:06 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

管理操作复核请求：对T407210009的两周临时封禁

本主题或以下段落文字，在讨论结束后应存档至Wikipedia:管理操作复核请求/存档。

已解决
社群就检讨封锁时长问题略有共识，惟因指控无从确证，故不迳予复核。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月28日 (一) 09:22 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

此请求是根据Wikipedia:管理操作复核请求所提出，请先阅读相关内容。

操作： [22]
执行者： Manchiu （讨论 · 贡献 · 日志）
先前讨论：[23]

对此封禁时长提出异议，简短原因在此：若是临时封禁，至少应参考不当行为持续长度，而侵犯著作权的行为（此为直接机翻来源）至少在2023年11月就开始，从而使短短两周的封禁在其编辑历史上起到微不足道的预防作用。其二：用户已经多次收到提醒，而此前也已有因侵权行为被封禁，光是去查核其此前的所有编辑以移除侵权内容就大量消耗编者时间，在T407210009上次被封禁一周后，解封后一个月又回到编辑继续添加侵权内容，此严重、持续性侵权行为明显已经无法仅仅由有限期封禁防止。 --beef [talk] 2025年1月31日 (五) 04:14 (UTC)[回复]

  • (＋)推翻到不限期封禁。如上。beef [talk] 2025年1月31日 (五) 04:15 (UTC)[回复]
  • (－)反对：在操作者已经证明了被封禁者近来编辑并没有故意侵权的事实之后，提请人仍然在此提请的行为如同追杀，令人不寒而栗。--MCC214（Sign | Contributions） 2025年1月31日 (五) 05:25 (UTC)[回复]
    很抱歉，但是Manchiu的说法实际上并不很准确。光是在这位用户最近的50笔编辑中，就有两笔违反原创研究：1、2，一笔抄袭原文：3。如果阁下认为两周的封禁能够让此用户回心转意，那在下自然是支持这次操作。--人间百态,独尊变态(讨论)(签名) 2025年1月31日 (五) 05:58 (UTC)[回复]
    抱歉，因为扰乱而辗转难眠的人不是造成扰乱的编者，而是需要跟在后面收拾烂摊子的编者。封禁，有效阻止侵犯著作权后我才能睡个好觉。你能把我的简单诉求说成追杀实在是让我大开眼界。我的背上已经有足够多的稻草了，每次在维基百科上看到这样子睁着眼睛说瞎话的行为就像是一个刀片在我的心脏上划过一样。伤害了我对中维编者的信任和期盼，您满意吗？--beef [talk] 2025年2月1日 (六) 09:01 (UTC)[回复]
    听到这里和下面你写的那堆文字，我总算明白你去年提名某个人当管理员的原因了，原来所有的逻辑和某个人一模一样，不读条目就要离开维基百科，派翠可夫深明得饶人处且饶人的道理，但你却没有，维基百科的用户身份和社会一样，有高低之分，你要令其不限期封锁，相当于以大欺小，人家经你一封，到了站外向着想加入本计划的人说“维基百科的用户和管理怎样严格那样严格，机会也不给人啊”，那人家会对这里的印象会好吗？为何站外会有类似伪基百科和香港网络大典那样批评维百的声音（另见对维基百科的批评)，按照某个人的逻辑，难道你不想想其中的原因吗？况且操作者说明其封禁理由所提到很重要的一点是“之后也检查过他最近的数十笔编辑，并无侵权行为，这种正常编辑与侵权编辑间杂用户，我不知道他是否了解侵权方针，因此才短期禁止以阻止其继续添加侵权行为，后续无改善方应施行更长时期封锁。”，但你不断强调的是“他以前、现在和将来都只会有侵权编辑”，是不是有点以偏概全呢？而人家用到“我不知道他是否了解侵权方针”这句话，这是假定善意的一种，AGF本身就是我们必需遵守的原则，难道操作者有错吗？--MCC214（Sign | Contributions） 2025年2月1日 (六) 09:51 (UTC)[回复]
    按照阁下的逻辑，那咱觉得到不如直接将不限期封禁删除。因为只要我们“不限期封禁”，就可能会有人到站外说维基百科的不好。那还不如让维基百科当个“好好百科”更有利于外宣。--人间百态,独尊变态(讨论)(签名) 2025年2月1日 (六) 10:11 (UTC)[回复]
    请你不要偷换概念，不限期封禁是在极端和非不得已的情况之下才能利用的手段，而不是用来解决任何人（包括阻碍你清理扰乱的人），派翠可夫也说过似乎在他第一次被封禁后的五个月也没有人Ping过他。这样的话，时间显然对事件规模有所影响；而社群是否曾经跟他做好沟通，本人也是有疑问的，你不要假定每个维基人会明白这些有预设文字而苍白无情的罐头警告信息，也不要假定每个维基人会在没有任何人用自己的文字教育别人的情况下很自制地改善自身的问题吧。--MCC214（Sign | Contributions） 2025年2月1日 (六) 10:21 (UTC)[回复]
    那么我挺好奇您认为什么样的行为属于极端和非不得已的情况。而且如果阁下认为现在对于此用户来说比起封禁更需要的是用自己的文字教育别人，那么您是否认同现在就解封此用户并在讨论页对他的侵犯版权行为进行劝导。--人间百态,独尊变态(讨论)(签名) 2025年2月1日 (六) 10:34 (UTC)[回复]
    封锁和教育本身就是软硬兼施的手段，两者必须合理运用，缺一不可，规则也表明“用户可使用一系列的警告模板用以传送简单的罐头提示，但按情况量身编写的讯息更佳。封锁应为最后的手段，管理员应在封锁违规用户前确认有关用户知晓或已获告知相关的规范，并已给予足够时间让其停止不当行为。”，但我看过其的讨论页警告，一是就是罐头警告信息，一是就是意义不明的自身编写信息，对于一个维基人来说是无法从中认识到自身扰乱的行为。--MCC214（Sign | Contributions） 2025年2月1日 (六) 10:54 (UTC)[回复]
    感谢您的回复。只是在下仍存在疑惑。按照阁下所引管理员应在封禁违规用户前确认有关用户知晓或已获告知相关的规范，并已给予足够时间让其停止不当行为。，可阁下又说一个维基人来说是无法从中认识到自身扰乱的行为。我是否可以认为之前罐头提示并不符合已获告知相关的规范，从而这个封禁本身就不应该成立。--人间百态,独尊变态(讨论)(签名) 2025年2月1日 (六) 11:16 (UTC)[回复]
    我认为如果给了罐头信息+自己撰写的警告无效之后封锁一个人那才有说服力，才有封锁一个人的正当理由，而被封的人才会觉得心服口服，但依本站情况来看，似乎只有“发了罐头信息警告后相关用户依然故我就封锁”的常识，而没有要自身编写警告信息后相关用户依然故我才能封锁的原则（虽然原理上并不能照本宣科，但你不做这个动作似乎不能成为一个封人“无可挑剔且不容置疑”的理由）。--MCC214（Sign | Contributions） 2025年2月1日 (六) 11:34 (UTC)[回复]
    如果阁下认为必须要有自己撰写的警告才有封禁一个人的正当理由，那么我建议阁下去提议修改对应的方针而不是容忍这种常识。--人间百态,独尊变态(讨论)(签名) 2025年2月1日 (六) 11:44 (UTC)[回复]
    我本身的论点就是取自方针，所以并没有需不需要修改的问题，问题只在你有没有仔细阅读相关的内容和明白其当中的含意罢了，总而言之，封锁一个人要考虑很多事情，包括会不会遇到别人的质疑而已嘛，一个人不考虑清楚到最后就好像Longway22和Wpcpey的事情一样，封禁者以一个根本就不存在的规则而作封禁理由被质疑，最后因为了避免一案多审和重复封禁，而只能撤销相关封禁决定一样。--MCC214（Sign | Contributions） 2025年2月1日 (六) 11:50 (UTC)[回复]
(！)意见：如果纯粹从Deadbeef君的角度出发，不限期封禁确实是唯一选项。虽然正式的说法应以“社群”为本位，但也可以看出在这次之前，除了Deadbeef君或者人间百态君之外，没有人留意过T君的编辑。在这个场合，说Deadbeef君或者百态君的意见可以代表整个社群，并不为过。
另一方面，本人认为在确定是否不限期封禁前，有以下问题要考虑。
第一，“T君恢复权限后一个月即恢复有问题编辑”这事，查阅其贡献纪录即可得知；但从这件事至他再被指侵权，好像隔了三、四个月，而本人看他的用户页的连入页面列表，似乎在他第一次被封禁后的五个月也没有人Ping过他。这样的话，时间显然对事件规模有所影响；而社群是否曾经跟他做好沟通，本人也是有疑问的。
第二，Deadbeef君指出，不限期封禁可以令社群毋需再为其可能再次破坏而耗费资源。本人认为，用户始终是人，不能排除其以滥用傀儡之类的手段作进一步破坏的可能性。当然，维基百科对于这种情况早有表述，就是回退、封禁、不理会，但是这样一来，社群还是要监察相关条目的情况或者是否有类似形式的编辑出现，而把人封了可能还要寻找新的用户名，是多了一重工夫。这样的话，本人承认自己并不知道Deadbeef君这个理据是否成立。
第三，这两天刚刚有两名用户（Ironbolt及Joker Twins）因为对社群的质询或管理员的封禁表示对抗而被不限期封禁。相比之下，T君被三次封禁都没有噤声。虽然不能排除T君拒绝沟通的可能性，但T君亦曾经回复过他人的Ping，似乎又未必如此。
由于本人未能就以上三点得出明确结论，请恕本人未能即时认同对有关用户作不限期封禁。然而，本人希望大家就Deadbeef君的理据，以及本人上面提出的三点作出思考，再决定应予何种处理为宜。
以上--派翠可夫 (留言按此) 2025年2月1日 (六) 08:05 (UTC)[回复]
第一，T407210009有充分的机会去了解复制粘贴新闻报道在维基百科上是不可接受的。在其讨论页的留言我就找到版权相关的提醒：[24][25][26]。对于他人在其讨论页的提示，他一次都没有回复或表现出了解，反而你去说社群没有做好沟通？是请问中文维基百科应该围绕着T407210009才行吗？
第二，根据既往贡献可以得出：T407210009若重返编辑，几乎必然会持续侵犯著作权，而一般用户受WP:ABK功能影响下根本没有实际创建傀儡的技术。我严重怀疑你这种态度是站着说话不腰疼，不论是所谓封禁之后需要“监察相关条目或相似编辑”、“寻找新用户名”，或是没封禁时及时查核并清除侵犯著作权内容，我都没见你参与。请问WP:编者著作权调查/T407210009下你要不要来打扫一下呢？对实际情况不清楚，你又有什么依据得出“封禁后反而更多消耗社群时间”这样的言论呢？
第三，我见过这个差异，但是令人感到荒谬的是你能觉得从2023年11月编辑到2025年1月的历史中，只要有一次回复他人的留言或Ping就能算“并非拒绝沟通”。
对于这种编者产生圣母或拯救情结，实际是在对于辛苦总结来源中的内容从而写条目的编者不尊重、对于不知疲倦巡查最近更改的编者不尊重、对于耗费二十多分钟只查核了4个潜在侵犯著作权差异的编者不尊重。多共情干正事的编者，少共情不干正事的编者。--beef [talk] 2025年2月1日 (六) 08:55 (UTC)[回复]
如果本人不体谅、不尊重您，本人就不会写下引言（即认为即使您的主张能代表整个社群亦不为过）以及第二点（提问不限期封禁是否能杜绝下次这种麻烦），也不会使用{{意见}}（而非任何反对模板）了。
一、您举的三个连结是7月封禁之前的事，本人也有看到，但承认自己是集中在后面的事态发展，因为您提出复核的是前几天的封禁；而有关著作权调查之所以这么长也是因为事情累积了五个月。本人说社群没有好好沟通或留意，换个说法也可以是本人认为，事情搞到要您（和百态君）这样辛苦地调查，是社群对您（们）不起，如果能够更早留意和使他回应（如前所言，也不是没有成功的例子），可能不用等到现在就已经能作出更有效的手段。
二、如果已有机制能防止用户在被不限期封禁后滥用傀儡，那本人没有其他问题。
三、如前所言，本人“……不能排除T君拒绝沟通的可能性”。您指本人认为他“……并非拒绝沟通”，并非事实，惟本人也想指出有其他可能性。您身为最直接受影响者，当然有最大的理由对此不表认同，但请不要随便用“荒谬”来形容其他不是您预期内的意见。
事实上，本人没有认为自己提出的几点一定有效，相反更多的是本人认为自己有些地方不明白而已。本人承认在您找Manchiu时已经开始尝试调查和思考，如果结果不能令您满意，本人谨此致歉，但希望您不要预设本人的立场。
最后关于完成T君的著作权调查，本人承认自己不知道怎样做才对（本人担心自己犯错，尤其是担心自己作出伪阴性结论），本人可以私下请教您具体做法吗？--派翠可夫 (留言按此) 2025年2月1日 (六) 09:43 (UTC)[回复]
已在你的讨论页下留言，稍后我会将更完善的教程写到一个用户子界面上。--beef [talk] 2025年2月1日 (六) 10:37 (UTC)[回复]

另外我想多一嘴：虽然此复核属于社群讨论仍在进行中，这不妨碍任何管理员以单独管理员操作来对T407210009进行处理，谨应遵循WP:WHEEL，不过将有限期封禁改为不限期封禁是不算回退管理员操作的。beef [talk] 2025年2月1日 (六) 10:40 (UTC)[回复]

多天已无新留言，且仅有提案人支持，视无共识关闭之。--SCP-0000（留言） 2025年2月16日 (日) 11:43 (UTC)[回复]

不见仅有提案人支持，建议重开。--（☎）dt 2025年3月22日 (六) 18:52 (UTC)[回复]
被提报人疑似被傀儡封禁，此案再讨论无意义。个人认为关闭存档掉或许可行。--花开夜 留言 ·签名 ·贡献 2025年4月10日 (四) 09:37 (UTC)[回复]
(！)意见单是我打扫的44个条目中就有26个条目（其中两个他创的检查后被我直接丢版权验证）有侵权，当初的封禁两周真的太少......--VAMPIRE VAMPIRE VAMPIRE!!!（留言） 2025年4月12日 (六) 15:42 (UTC)[回复]

(！)意见：目标用户已因滥用傀儡被不限期封禁多日且仍在创建新傀儡，已无解封可能，无需换个灯泡。--此条未正确签名的留言由Python6345（讨论｜贡献）于2025年4月2日 (三) 12:49 (UTC)加入。[回复]

社群对于此一封锁，倾向认为原先一月二十六日封锁，时长或有不妥，应斟酌当事人过往贡献性质予以加长；与此同时，尚曾指出过往与当事人沟通可能不足，而对于是否直接改为无限期封锁，正反意见则多有辩驳，未见绝对共识形成。惟当事人自一月五日首遭封锁后即无任何编辑，迄后再因分身账号故而别遭无限期封锁，今已殊难确证有关封锁时长不妥之指控，且纯以后见之明检讨此一操作是否适当并无意义，故不予复核而结案。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月28日 (一) 09:22 (UTC)[回复]

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
我本来是在休维基假期的，看着这个我乐了。你所说的当事人自1月5日封禁后跑到了另一个帐号上作出了750余（其中有许多侵权内容的）编辑，现在又是开各种新号恶心社群，现在却说“啊，虽然现在发生了这么多事情，这么多编者在这里也留下了他们的意见，原来其实我也不知道当初究竟是不限期封禁更好还是有限期封禁更好，谁也辩不出来当时究竟是不限期好还是有限期”，究竟是什么样的人会写下这样的结案语，真让我怀疑你有没有实际去读讨论，总结两边的观点，根据是否符合方针与指引作出关闭决定？真要以Moot来关闭，就以Moot来关闭，不要扯什么“无法确证”、“不予复核”这种和稀泥语言。beef [talk] 2025年4月28日 (一) 11:47 (UTC)[回复]
因为必然有人会说当事人已封锁本身不影响复核，所以不用此一理由结案。你说的那些行为都是后来发现的，不能用作检核理由。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月28日 (一) 12:25 (UTC)[回复]
如果你能将“已经封禁，所以已无复核必要”这一逻辑贯彻到底，我倒根本不会有意见。如果你能只按复核当时T407210009本人的行为与历史，及讨论中不同观点是否符合方针与指引、哪些更有力来分析总结此讨论，我更是很高兴。
很明显，你这里尝试两个都做，结果两个都做的很差。和稀泥。--beef [talk] 2025年4月28日 (一) 12:37 (UTC)[回复]
尊重你的意见。平心而论，此案确实应该及早复核。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月28日 (一) 17:07 (UTC)[回复]
Stab in the back.jpg?--VAMPIRE!VAMPIRE! All Hands Brace For Shock!Birds Away. Missile intercepted（留言） 2025年4月28日 (一) 13:20 (UTC)[回复]

管理操作复核请求：Ericliu1912实行之双向互动禁制（Tisscherry）

本主题或以下段落文字，在讨论结束后应存档至Wikipedia:管理操作复核请求/存档。

已解决
鉴于社群共识及本人意见，认为有关操作不妥，并予以推翻。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月28日 (一) 09:30 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

此请求是根据Wikipedia:管理操作复核请求所提出，请先阅读相关内容。

操作： 双向互动禁制
执行者： Ericliu1912 （讨论 · 贡献 · 日志）
先前讨论：Wikipedia:管理员布告板/其他不当行为/存档/2024年8月#Chinuan12623 5、Wikipedia:互助客栈/其他#管理操作复核请求：不认为Ericliu1912在8月28日的双向互动禁制处理符合方针指引等社群共识

看到之前的管理操作复核请求通过了，而且Tisscherry君说过：我当时是以为，因为自由雨日和我有互相宣称，如果其中一人被封锁，那请连带处理，类似这样的发言（我没去找diff，晚点想到再找）我想Ericliu管理员是看到了，故我当时欣然接受没有其他意见。以此逻辑，自由雨日申请操作复核，我会跟随( ✓ )同意和(＋)支持。基本上我尊重管理员判断，但我希望他若要做出说明，请尽量使用浅显易懂的文字，维基百科不是官僚体系，不要刻意画线拉距离。--提斯切里，但因二人之复核背景略有不同，因此需要另开一笔复核。副知@Tisscherry、自由雨日。 --Пусть от победы☆к победе ведёт! 2025年2月4日 (二) 04:28 (UTC)[回复]

多谢费心代劳，我没有很想复核，辛苦了。--提斯切里（留言） 2025年2月4日 (二) 04:56 (UTC)[回复]

多天已无新留言，且仅有提案人支持，视无共识关闭之。--SCP-0000（留言） 2025年2月16日 (日) 11:47 (UTC)[回复]

无法认同此关闭合理。beef [talk] 2025年2月17日 (一) 09:26 (UTC)[回复]
+1，@SCP-2000 Пусть от победы☆к победе ведёт! 2025年2月17日 (一) 09:55 (UTC)[回复]
不妨解释一下为何认为“无法认同此关闭合理”，谢谢。--SCP-0000（留言） 2025年2月17日 (一) 10:24 (UTC)[回复]
@SCP-2000：请参考Wikipedia:管理操作复核请求#关闭提报，请说明为什么此请求与以上请求为经过充分讨论，并且达成共识或显然不会达成共识。--beef [talk] 2025年2月17日 (一) 13:03 (UTC)[回复]
@SCP-2000：请重新开启这些复核请求。--beef [talk] 2025年2月18日 (二) 11:30 (UTC)[回复]
@0xDeadbeef、阿南之人： 其一，就个人对社群的理解，当一个讨论展开十多天后仍没有任何新留言，通常最后只会成为不活跃的讨论，更遑论可以达到“充分讨论”的条件。个人此做法某程度上是WP:SNOW的体现。但如果社群认为管理员只能够在“充分讨论”的情况下才能关闭，那么个人不反对重新开启。
其二，参考本站及英维过往复核，通常只有一定人数支持/反对复核的情况下才会视为达成共识，而上述复核仅有少数人参与及表示支持，故个人认为未至达成共识。当然这一部分原因可归咎于讨论时间较短，但正于个人上述指出当一个讨论不活跃一段时间，那可预期只会一直不活跃，自然不可能出现一定人数参与的情况。
另外，尽管管理操作复核请求已运作一段时间，但实质上有效及达成共识的请求仍属少数，在缺乏前例及明确指引的情况，管理员惟有只能依靠自身的经验作出判断（这也是一部分原因为何只有极少数管理员愿意处理此类请求）。所以个人以管理员角度来看，期望社群能够提供更多意见及指引，指出我们应如何操作及才能实现社群的共识。谢谢。--SCP-0000（留言） 2025年2月19日 (三) 02:16 (UTC)[回复]
@SCP-2000：我不想消磨你对于处理这些请求的耐心，因为相比其他管理员之下，至少你还愿意去处理这些事情。但是这些关闭已经体现很多问题了：首先，本站没有英维那么多编者参与，就不应该要求英维那么多的人来参与才算有共识。英维可以做到大型RFC有68个人发表意见，你维之前的管理人员改革也就做到英维的三分之一。像上面红渡厨提出来的，这么多天无人反对，应当认定已有共识而不是“无共识”。
至于其他的请求这样结案只能说明社群再一次失能，该讨论出结果的东西讨论不出结果，T40再一次让Manchiu认为自己的操作合理，导致临时封禁被继续错误地使用，造成已封禁多次的用户还能在今天蹦蹦跳跳，左手创建一个侵权条目，右手再随意复制粘贴新闻来源中的内容。没事，今天有这个“ㄨ”，明天就能有很多个这样的用户。他们都根本不屑于你们这些人这些年来留下多次的警告，各种临时封禁，让我感觉可笑的是还有人认为要是我们不去人家门口跪下求他不要再侵权了还显得我们中维社群没有诚意。
从我观察发现，中维好像至少有两个很擅长掩耳盗铃的管理员，有些时候别人直接指出问题所在的时候都能直接把眼睛闭上，一个是Manchiu，一个就是Eric。但是我没意见。指出问题是我，提出解决方案也是我，至于问题是否真的能得到解决，就看看中维究竟还剩下多少说人说的话，干人干的事的人了。--beef [talk] 2025年2月19日 (三) 09:37 (UTC)[回复]
( π )题外话其他的话我不发表意见，关于社群失能的问题我认为根源在于人太少＋管理员数量不够。理想状态下，中维至少需要现在三倍活跃的核心维基人(我定义为指延伸确认用户且一个月内编辑超过50次)，才能维持类似英维的运转。中维很大程度上依靠直接民主，导致很多弊端和乱象难以解决。--花开夜 留言 ·签名 ·贡献 2025年2月19日 (三) 11:36 (UTC)[回复]
谢谢批评。非常遗憾。我无意掩耳盗钟欺骗任何人，擅长更不知从何谈起；但一切批评都虚心接受。关于封锁时长，社群可以深入讨论。@Ericliu1912作为管理员表现是有目共睹。
但求无愧，非敢请尔，固所愿也。再次谢谢你的意见。--千村狐兔（留言） 2025年2月20日 (四) 10:13 (UTC)[回复]
ㄎㄎ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年2月20日 (四) 12:28 (UTC)[回复]
以上两位有时间在这里回复却选择不去处理我提出的长期侵犯著作权的用户实在让我遗憾。
不过能够无视别人指出的实际问题当然也能够无视别人指出的实际批评啦。--beef [talk] 2025年2月21日 (五) 04:19 (UTC)[回复]
就在20分钟之前又继续侵权。管理员多一天不作为，维基百科就多一天的复制粘贴垃圾。别忘了这里首先是一部百科全书。--beef [talk] 2025年2月21日 (五) 04:43 (UTC)[回复]
@0xDeadbeef 但似乎你还没有提报ANM……Пусть от победы☆к победе ведёт! 2025年2月21日 (五) 04:51 (UTC)[回复]
提报ANM是处理问题用户的必要条件吗？所以为什么说管理员这么喜欢在问题面前选择闭眼。我不提报，不去提删修订请求，管理员就是无能的了吗？管理员有没有能力在社群成员没有请求操作的时候，单独执行应当的操作呢？--beef [talk] 2025年2月21日 (五) 04:54 (UTC)[回复]
大家都是志愿者，管理员没有必要长期盯着最近更改做巡查/反破坏，以至于我们有巡查员回退员去做这些，提报在目前看来就是最好解决办法。看到侵权用户不提报然后要管理员长期盯rc/某些人的贡献也太不实际。--Aqurs 2025年2月21日 (五) 05:00 (UTC)[回复]
我又没有要求管理员去一直盯着最近更改。我在原本的留言中，除了点名批评这两位管理员之外，也附上了实际侵权内容的链接。看到我那个留言的管理员至少有三个了，但却没有任何人去对这些侵权编辑作任何处理。我没意见，我只是说与其闲得没事干去回复我的批评，不如去干点实际有益的事情。看到了批评你无视去干活我实在无所谓，选择回复了又不去处理，这不是无视问题是什么呢？

或许我对所谓常识的理解有问题，但是如果我被这样批评，我至少会先看看链接里的内容有没有真正需要处理的东西。如果真有反思、接受批评的意愿，那就用行动来体现，在这里拉拉扯扯的很浪费时间。beef [talk] 2025年2月21日 (五) 05:08 (UTC)[回复]

看了看原来禁制时给出的原因：基于严重冲突，实施为期一周之双向互动禁制，以遏止情势继续恶化，但原讨论中使事态不断升级的只有Chinuan12623，如果只是为了防止恶化，单向互动禁制或许已经足矣。此次操作不合理，故我认为应该(＋)推翻此操作。cc @Eric Liu。beef [talk] 2025年2月23日 (日) 13:38 (UTC)[回复]

同beef，支持(＋)推翻此不合理禁制。 ——自由雨日🌧️❄️ 2025年3月5日 (三) 15:22 (UTC)[回复]
倾向该案件保留至仲裁委员会处理。 -Lemonaka 2025年3月30日 (日) 10:11 (UTC)[回复]
Tisscherry是否傀儡不影响此复核。Пусть от победы☆к победе ведёт! 2025年3月30日 (日) 10:24 (UTC)[回复]

本人承认此一操作以今日情况视之或有不妥，且社群就互动禁制行使要件似略有共识，我想就不必浪费诸位时间及客栈篇幅，自行复核而推翻为宜。但仍想重申，彼时局势诡谲，本人不认为有关操作无助于降低双方（或其他各方）冲突，而单向互动禁制不过是独许某方发言，亦难称绝对公平。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月28日 (一) 09:30 (UTC)[回复]

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

@Ericliu1912：请问阁下所言“复核”是否指“推翻决定”？“复核”指“审查核对”，正是本讨论串存在的目的，即让社群参与这一“审查核对”过程，故不为讨论关闭的理由。再者“管理员在所牵涉事宜中应避嫌”，如此径行关闭，恐怕不合方针本意。建议阁下重开本复核案，在操作完成后汇报社群，由另一管理员核对阁下的操作是否符合本次共识。副知@阿南之人、Tisscherry、自由雨日。1F616EMO（喵留言～回复请ping） 2025年4月28日 (一) 09:59 (UTC)[回复]

避嫌不包含对自己做出不利的决定吧？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月28日 (一) 10:07 (UTC)[回复]
像是推翻，结果还是double down（本人不认为有关操作无助于降低双方（或其他各方）冲突、亦难称绝对公平（而且这个公平更是在诡辩：社群中有一些人被不限期封禁，有一些人不被不限期封禁，这公平吗？））。所以你到底清楚不清楚管理员是负责执行社群共识的？--beef [talk] 2025年4月28日 (一) 12:23 (UTC) ❤️1[回复]
社群共识是推翻本人操作，此何有问题？另外，后面那段是我的个人意见，因为并非社群共识，故两顶帽子分开。可能我上面结论措辞写得不太好而且挤在一起，那就在这里把意思说清楚了。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月28日 (一) 17:06 (UTC)[回复]
另修改了下结案措辞。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月28日 (一) 10:09 (UTC)[回复]
（修改链接见此。） ——自由雨日🌧️❄️ 2025年4月28日 (一) 12:06 (UTC)[回复]

提议将Mediawiki保护改名及更改图标

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

本主题或以下段落文字，移动自WT:保护。执行者：WiiUf 2025年3月9日 (日) 06:42 (UTC)。[回复]

我认为目前Mediawiki保护的名称不够准确、且图标无法同模板保护区分。希望能改成较为直观的“界面保护”等名称，并设立相关图标。如有共识可设立相关投票。--WiiUf 2025年3月8日 (六) 04:38 (UTC)[回复]

(＋)支持--August讨论‧签名 2025年3月8日 (六) 04:45 (UTC)[回复]
不能认同界面保护的名称。该名称抛弃该保护的本质原理，易导致后续含义失准。此外，由MediaWiki自动施加的JSON保护亦为此保护，但JSON不应视作影响界面。--MilkyDefer 2025年3月9日 (日) 15:30 (UTC)[回复]
Mediawiki其实就是系统配置文件，那么叫做“系统保护”应该会比较合适。Bluedeck 2025年3月10日 (一) 06:43 (UTC)[回复]
这个名字还不错。--碟之舞📀💿 2025年4月6日 (日) 03:24 (UTC)[回复]
@August.C@Bluedeck@Diskdance@MilkyDefer若无异议， 公示48小时，稍后将举行投票。--WiiUf（留言） 2025年4月6日 (日) 09:24 (UTC)[回复]
@August.C@Bluedeck@Diskdance@MilkyDefer投票页面已建立。--WiiUf（留言） 2025年4月7日 (一) 14:35 (UTC)[回复]
反对投票... 目前社群有人反对“系统保护”吗？为什么不讨论出共识而要投票？--Aqurs 2025年4月7日 (一) 14:38 (UTC)[回复]
我想组织投票是因为有类似先例（之前决定各类保护用名及图标都用的是投票）。--WiiUf（留言） 2025年4月8日 (二) 10:12 (UTC)[回复]
同Aqurs，可以用共识通过的就不必投票了--August讨论‧签名‧回复请ping 2025年4月7日 (一) 14:41 (UTC)[回复]
(▲)同上，反对投票。既然投票的本质其实是问卷，常规共识方法能够解决之事，何必诉诸投票？--1F616EMO（喵留言～回复请ping） 2025年4月7日 (一) 14:44 (UTC)[回复]
投票是共识达不成退而求其次的方案，这里大家并没有达不成共识吧。--碟之舞📀💿 2025年4月8日 (二) 10:09 (UTC)[回复]
所以这种保护究竟能保护什么？若像诸位所说，似乎Bluedeck建议的“系统保护”是个好方案。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月28日 (一) 09:39 (UTC)[回复]
公示7日，2025年5月6日14：22（UTC)通过。--WiiUf（留言） 2025年4月29日 (二) 14:20 (UTC)[回复]
@WiiUf：新图标在什么位置？？--Aqurs 2025年4月29日 (二) 14:26 (UTC)[回复]
公示的方案是？界面保护还是系统保护？以及下次公示请一并更新Template:Bulletin。——ZhaoFJx(Talk) 2025年4月29日 (二) 15:35 (UTC)[回复]
抱歉，重新公示“系统保护”名称7日，2025年5月6日23：35（UTC）结束。--WiiUf（留言） 2025年4月29日 (二) 23:32 (UTC) 👍1[回复]

管理操作复核请求：Wcam关闭文件存废讨论的程序问题

本主题或以下段落文字，在讨论结束后应存档至Wikipedia:管理操作复核请求/存档。

此请求根据Wikipedia:管理操作复核请求提出，请先阅读相关内容。
操作： 结案存废讨论
执行者： Wcam （讨论 · 贡献 · 日志）
先前讨论：https://w.wiki/DNAS

管理员Wcam在参加了存废讨论的同时也关闭了该存废讨论，依据关闭存废讨论指引，“...一名未参与提删和讨论的管理员或富有经验的编者将依《关闭存废讨论指引》关闭存废讨论...”。按理其不应关闭此讨论，因此提出此复核请求。本复核针对的是结案程序问题，不一定要对存废讨论的结论作出复核，有用户在站外指出不应该提交DRV，故重新提交于此，先前讨论内容位于上方链接。此外，搜索存废讨论记录可知，这不是Wcam第一次如此操作了，谢谢。 --在下荷花，请多指教（欢迎签到） 2025年3月10日 (一) 10:54 (UTC)[回复]

补一下链接吧：Wikipedia:档案存废讨论/记录/2025/02/27 § File:HOYO-MiX - La vaguelette.ogg--深鸣（留言） 2025年3月10日 (一) 10:58 (UTC)[回复]
谢谢。--在下荷花，请多指教（欢迎签到） 2025年3月10日 (一) 10:59 (UTC)[回复]
我看后，同意wcam的说法，即他针对NFCC标准和模板的发言并不算参与存废讨论发表意见。这些发言可以看作他结案的理论依据。不过如果二位认为继续存废讨论有必要，那么我可以按共识不足来重开启讨论（如果删去wcam的讨论，那么我觉得共识是不足的）。此外，同时我觉得我们的NFCC标准可以向英维同步，如果条目中有音乐评论，就允许使用。我认为英维能够实施一段时间的方针就可以看作基金会也认为在法律上没问题。单看fair use的法律原文，严格程度目前是 中维 >> 英维 > 法条。如果您想正式提出这个提案，我会支持。Bluedeck 2025年3月11日 (二) 05:55 (UTC)[回复]
感谢评论，我觉得可以，那应该提议修改WP:NFCC还是哪条方针？--在下荷花，请多指教（欢迎签到） 2025年3月11日 (二) 06:44 (UTC)[回复]
个人感觉修NFCC就可以了。Sanmosa 新朝雅政 2025年3月11日 (二) 13:24 (UTC)[回复]
@Bluedeck：感谢您的意见，但对于英维能够实施一段时间的方针就可以看作基金会也认为在法律上没问题不敢苟同。某一维基计划的某一方针的实施时间长短，与基金会对相关方针的态度，没有必然的逻辑关系。基金会全域版权方针明确规定“所有计划都只应该寄存符合自由内容许可协议的内容”和“（允许非自由内容的）‘豁免原则方针’必须尽可能少”，所以越少使用非自由内容越符合基金会的意愿。从现状来看，使用非自由文件的维基百科计划的数量少于半数，若算上所有维基计划，则使用非自由内容的计划更是少数。因此，我们不能无视这些事实和基金会全域方针的规定，而单看某一计划的非自由内容限制较为宽松就与之看齐。--Wcam（留言） 2025年3月11日 (二) 20:54 (UTC)[回复]
EDP这文章我第一次看，谢谢你指出。文章确实写明EDP的适用范围应该尽可能少。不过，同段内指出EDP可以接受的适用范围包括：“... or to complement (within narrow limits) articles about copyrighted contemporary works. 【中：……或者作为补充，放在描写受版权保护的现代作品的条目里】”，我一看，这个似乎恰好适用于芙宁娜条目的情景？Bluedeck 2025年3月11日 (二) 22:54 (UTC)[回复]
其实基金会的声明本质上就是在各方妥协的情况下，作为自由文化的一面旗帜尽量倡导自由文化（可参考自由软件运动）--百無一用是書生 (☎) 2025年3月12日 (三) 01:36 (UTC)[回复]
@Bluedeck：请注意这里within narrow limits是个相当关键的限制。本案中的copyrighted contemporary work是“轻涟”歌曲，而芙宁娜条目并不是直接关于该作品本身的条目，故在within narrow limits的前提下我不认为符合您提到的可以接受的适用范围。--Wcam（留言） 2025年4月8日 (二) 15:45 (UTC)[回复]
我对我关闭存废讨论的操作有被视为违反WP:CLOSEAFD的嫌疑表示歉意，今后会多加留意。--Wcam（留言） 2025年3月11日 (二) 20:23 (UTC)[回复]
谢谢您--在下荷花，请多指教（欢迎签到） 2025年3月12日 (三) 00:14 (UTC)[回复]

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

引入临时账户功能后，谁应该能够看到 IP 位址？

透过临时账户，我们可以用新的唯一识别码替换未注册编辑者的 IP 位址。此次更改后，未注册编辑者的 IP 位址将不再对外开放。我们做出这项改变是为了加强对安全和隐私的支持，以确保我们的贡献者继续感到安全。

另一方面，在某些情况下，保护维基媒体专案（打击垃圾邮件、破坏行为、骚扰等）的使用者需要查看未注册编辑者的 IP 位址才能有效地进行工作。为了平衡这些需求，我们的政策是继续向某些使用者提供临时账户 IP 位址的存取权限，使用下面描述的流程。

在今年稍后我们在 本 wiki 上推出临时账户之前，我们需要明确谁可以查看临时账户的 IP 位址。我们希望征求您的意见。

问题

目前，该权限会自动授予以下使用者：

  1. 拥有扩充权限（例如管理员、CheckUsers、全域系统操作员、监管员——请参阅政策以取得更多范例）
  2. 没有扩充权限，但其本地账户至少已使用 6 个月，并且对本地专案进行了至少 300 次编辑。

我们的问题仅仅与#2有关。在任何维基媒体专案上部署临时账户之前，我们已经选择了这些数字阈值。然而，我们清楚地认识到，这些门槛相当低，恶意行为者仍然很容易取得临时账户 IP 位址。我们听到了多个社群对此的担忧，包括第一批试点社群。我们希望临时账户能够真正改善编辑者的隐私，因此在拥有大型社群的维基上推出此功能之前，我们需要采取更严格的限制。

在与管理员、一些试点维基媒体专案的社群成员以及活跃于英语 Discord 的社群成员就其他选择进行磋商后，我们希望在最终确定这项变更之前得到您的回馈。

我们的新方法

我们建议没有扩展权限的使用者可以申请查看临时账户的 IP 位址的权限，由管理员或监管员决定是否授予权限。我们的目标是更一致地限制 IP 位址存取权限，仅允许需要存取 IP 位址的人存取。这将需要人工操作，但与我们继续自动授予权利相比，负担应该会更小。

当我们将临时账户部署到更多维基媒体专案时，我们可以评估其影响并根据需要调整我们的方法。

这将如何运作

  • 当没有扩展权限的使用者需要查看临时账户IP地址时，需要申请加入“临时账户IP查看者”群组。他们会向管理员（当地社群将能够决定该流程）或监管员（对于没有当地管理员的维基媒体专案）提交请求。
  • 该功能要求使用者至少有 300 次编辑且账户使用时间至少为 6 个月。管理员和监管员将无法向不符合该标准的账户授予临时账户 IP 存取权限。这是最低限度，我们鼓励社群——特别是较大的社群——执行更高的门槛。根据临时账户试点社群的评论，我们建议至少将 600 次编辑作为门槛。
  • 审查请求的使用者将检​​查申请权利的使用者是否符合要求以及是否提供了有效的理由。权利本身将透过 Special:UserRights 授予。
  • 授予权利请求的使用者同时将拥有删除处理的权利。

请注意，存取 IP 资讯功能的要求与存取临时账户 IP 位址的要求相同。

我们考虑过的其他选项

我们考虑过一系列选项，包括：

  • 仅向具有扩展权限的使用者授予权利。
    • 优点：从使用者安全的角度来看，这是理想的，因为只有经过社群审查的使用者才能获得存取权限。  
    • 缺点：限制性太强。许多巡查活动都是由没有扩展权限的编辑进行的。如果我们这样做，就会增加具有扩展权限的使用者的巡逻负担。
  • 增加编辑次数和/或账户年龄的门槛。该权利仍将自动授予。
    • 优点：从技术上来说，这是一个简单的改变。
    • 缺点：恶意编辑者取得临时账户 IP 的风险仍然较高。恶意使用者可以在自动化工具或脚本的帮助下达到任意阈值计数，无论多高。这同时将使小型专案的善意编辑更难透过常规编辑获得此存取权限。

我们的问题

  • 新的提案是否充分解决了隐私问题？
  • 当我们执行这项政策时，是否应该知道这会对您的社群产生什么影响？我们希望在 2-3 周内更新该政策。


在接下来的几周内，我们将向您提供有关临时账户和相关功能的更多更新资讯和素材。

我们在此再次感谢所有帮助我们找到不同选择的成员。如果您希望了解有关该专案的更多信息，请阅读 Diff 部落格，访问我们的专案页面和常见问题解答。请订阅新闻通讯以保持联系。谢谢！NKohli (WMF) 与 SGrabarczuk (WMF)（留言） 2025年3月11日 (二) 23:45 (UTC)[回复]

六百次编辑够多吗？虽说现在本来谁都可以看就是了（ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年3月12日 (三) 04:01 (UTC)[回复]
Hey @Eric Liu. If I interpret your comment correctly, you doubt if a higher number would be a better solution? Yeah, it's fairly easy for people with bad intentions to meet the criteria if these are just numbers of this or that. The essence of the change is that users who are not admins, CheckUsers, etc. would need to be granted the right manually by people, as opposed to a script.--SGrabarczuk (WMF)（留言） 2025年3月12日 (三) 08:34 (UTC)[回复]
@SGrabarczuk (WMF)： I think he means that 600 edits may not be enough for this flag.But that is not the key point.The key point, as you say, is that it should be up to the community to judge whether or not to grant this flag based on the credibility of the user, and the number of edits is only one of the criteria used to assist the judgment.--人间百态,独尊变态(讨论)(签名) 2025年3月12日 (三) 14:46 (UTC)[回复]
Thanks @人间百态!--SGrabarczuk (WMF)（留言） 2025年3月12日 (三) 15:35 (UTC)[回复]
不展示实际地址，而只允许查看ISP、用户间IP相似度等简要信息，不是更好吗。--YFdyh000（留言） 2025年3月12日 (三) 04:19 (UTC)[回复]
@YFdyh000, for almost everyone, only temporary account name (like ~2025-12345) will be visible. People with access to IP addresses of temporary accounts will also have access to IP Info, and that tool gives this data - just like on this screenshot.--SGrabarczuk (WMF)（留言） 2025年3月12日 (三) 16:26 (UTC)[回复]
傀儡调查助理很有必要能获授予此类权限，检查IP地址及后面的电信商、地理位置等资讯的关联显然是傀儡调查的核心之一。只检视相似度就变成另类CU，还要搞另一轮。--路西法人 2025年3月12日 (三) 09:49 (UTC)[回复]
我觉得应该反过来思考，足以取得前述权限者乃为傀儡调查助理之基本条件。不过其他人说得也对，标准或许定得低一点也非全然坏事。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年3月12日 (三) 16:09 (UTC)[回复]
确实有这么一回事，认同你的反向思维。--路西法人 2025年3月13日 (四) 04:49 (UTC)[回复]
我说临时用户的IP和ISP的相似度，展示相对距离而非明文。--YFdyh000（留言） 2025年3月12日 (三) 22:27 (UTC)[回复]
要搞相似度也还是一件很难搞的事情，究竟什么为之“相似”什么是“无关”并非自动化程序可以判定。--路西法人 2025年3月13日 (四) 04:46 (UTC)[回复]
就是例如弄一个在线程序，显示临时用户A与B的ISP是否相同，网段距离（比如同一或相近D段内），辅助判断傀儡而不揭示真实归属，以满足权限下放而不敏感。--YFdyh000（留言） 2025年3月13日 (四) 08:58 (UTC)[回复]
zhwiki特有的IPBE授予者应自动加入此组。--Akishima Yuka（留言） 2025年3月12日 (三) 13:40 (UTC)[回复]
不见得IPBE授予者在哪个步骤需要用到这个检视的权限。--路西法人 2025年3月12日 (三) 15:20 (UTC)[回复]
Thanks for your comment, @Akishima Yuka. In my opinion, users with IPBE don't have that much in common with this topic, because they (passively) benefit from something, whereas this topic is meant to be about users who (actively) need information about other users' IP address. For example, I have the IPBE flag on Spanish Wikipedia, but I'm not really involved in fighting vandalism there. Does that make sense? What do you think?--SGrabarczuk (WMF)（留言） 2025年3月12日 (三) 17:55 (UTC)[回复]
@SGrabarczuk (WMF)：Hi there, I believe what Akishima talked about is 'IPBE Grantor' instead of IPBE, which is a special user right that only exists in zhwiki due to high backlog of IPBE request. Though, I think it's stil not relevant because granting IPBE doesnt matter with viewing temp accounts IP Address(es), and if it's the qualification of viewing temp accounts IP Address, it would be too high obviously.--Aqurs 2025年3月12日 (三) 18:03 (UTC)[回复]
You may regard the public proxy IP address as a verification of their request, or else the IPBE granting would have no threshold at all. The technique and possible money cost of using a proxy can be a threshold for the uninvited.--Akishima Yuka（留言） 2025年3月12日 (三) 18:24 (UTC)[回复]
Thanks both! Google or DeepL translated the comments as IPBE grantee, not IPBE grantor, that's why I didn't understand initially. The requirements for IPBE Grantor are higher than the ones which we'd like to apply to IP reveal - that's good.
I think that technically, the easiest solution will be for the community to adopt a local (just for zhwiki) policy that all IPBE Grantors are given IP reveal (as an integral part of 权限申请/申请IP封锁豁免授予权), and then whoever grants the IPBE Grantor permission, would also grant IP reveal. So it would be the manual way.
Why the manual way? I seriously doubt if, for the sake of several users, our team would adjust the global policy and the global script adding the rights.--SGrabarczuk (WMF)（留言） 2025年3月12日 (三) 23:22 (UTC)[回复]
个人认为巡查回退员必须拥有此“检视临时账户ip”的权限。临时账户大多是一次性用，若此权利获取难度太高会严重影响用户巡查工作。个人不反对600次编辑可以自动获得此权利，毕竟目前所有人都是可以查看未注册维基人的ip地址。--Aqurs 2025年3月12日 (三) 15:35 (UTC)[回复]
个人支持将获取权利的门槛定为延伸确认用户。--Aqurs 2025年3月12日 (三) 15:41 (UTC)[回复]
(▲)同上 ——敬颂冬绥 ZhaoFJx(论•签) 2025年3月12日 (三) 23:50 (UTC)[回复]
基本上能假定申请回退权的使用者是为了进行反破坏，可以检视账户IP没什问题，但是无法假设所有延伸确认使用者都在进行反破坏，我不认为需要让延伸确认使用者自动获得权限，使用者应该自行申请权限。--2402:7500:93E:31F0:C42C:BB2F:8912:A99C（留言） 2025年3月13日 (四) 16:33 (UTC)[回复]
@Aqurs1、ZhaoFJx：延伸确认用户只需注册达90天即可自动被授予，此与“临时账户IP检视者”的最低要求“账户使用时间至少为6个月”不符。个人认为部署初期可先人手授予，如果往后有实际需要可届时讨论是否改为自动授予。谢谢。--SCP-0000（留言） 2025年4月3日 (四) 03:33 (UTC)[回复]
赞同，延伸确认用户可以在权限申请页面申请查看临时账号IP。——ZhaoFJx(Talk) 2025年4月3日 (四) 18:48 (UTC)[回复]
只有符合“临时账户IP检视者”的最低要求（600次编辑且账户使用时间至少6个月）才行吧。--SCP-0000（留言） 2025年4月4日 (五) 01:05 (UTC)[回复]
技术上是否可以同时满足延伸确认用户+注册后6个月自动授予权限？或者考虑提高延伸确认用户条件至6个月？当然个人不反对初期人工授权。--Steven Sun（留言） 2025年4月4日 (五) 01:39 (UTC)[回复]
@Steven Sun：理论上授予“临时账户IP检视者”条件可改为500次编辑 + 注册满6个月。谢谢。--SCP-0000（留言） 2025年4月4日 (五) 12:26 (UTC)[回复]
@SGrabarczuk (WMF)：Hello, I would like to know the reason why the recommended threshold is more than 600 edits, rather than 500 or 1000 edits. It seems that it is simply double the minimum requirement of 300 edits?
Secondly, the threshold for the extended confirmed user in Chinese Wikipedia is more than 500 edits, and the account must be at least 30 days old. Based on the above comments in this discussion, it seems that the community may want the threshold similar to that of the extended confirmed user. Therefore, I am curious to know if it is possible to access a temporary account's IP address if the account has more than 500 edits (instead of the recommended 600 edits) and is at least 6 months old. Thank you!--SCP-0000（留言） 2025年4月4日 (五) 12:28 (UTC)[回复]
Hey @SCP-2000, thanks for pinging me. 600 edits is the softer part of our recomendation. Technically, we will be requiring 300 edits, and that's it. The key however is the manual granting (instead of the automatic way), and the requirement for providing a reason for asking for the right. Not everybody who is active and fairly experienced really needs access to other users' data - this is the point we would like to make.
So, personally, I guess it would be best to not connect this right with extended confirmed. Even though the requirements are similar, the purposes for these groups are not related, really. On the other hand, SPI Clerks (傀儡调查助理) and maybe maybe IPBE Grantors (IP封锁豁免权授予者) - that sounds related. Thanks,--SGrabarczuk (WMF)（留言） 2025年4月4日 (五) 16:30 (UTC)[回复]
@SGrabarczuk (WMF)： I noticed from a screenshot that you attached above – what is this "Users on this IP" thing? Is it just for "Temporary users on this IP" (I hope it is)?--路西法人 2025年3月13日 (四) 04:48 (UTC)[回复]
@LuciferianThomas It means "The average number of clients that have been observed on this IP address by Spur. It takes into account all activity from this IP address. This is calculated over a 24 hour period." If you click "ⓘ" next to "Users on this IP", you can see the above description. You may visit this page to learn more about this feature. Thanks.--SCP-0000（留言） 2025年3月13日 (四) 10:22 (UTC)[回复]
So "all activity" would include those from registered users? Even if it is only across a 24-hour period, I would strongly oppose this right being allocated to any user without a necessity to view such information. Please clarify whether registered activity is also accounted for in this data. --路西法人 2025年3月14日 (五) 00:49 (UTC)[回复]
@LuciferianThomas: The source of this data is from Spur, an external service, rather than from Wikimedia. So the data does not include any on-wiki users.--SCP-0000（留言） 2025年3月14日 (五) 00:55 (UTC)[回复]
What and how exactly does it count as a client to the IP? If that is not clarified, I could only taken into account the textual description of "all activity" (including any registered user editing Wikipedia).--路西法人 2025年3月14日 (五) 01:15 (UTC)[回复]
Great questions, @LuciferianThomas. I've asked the team because I wasn't sure myself :D
SCP-2000 is correct. IP Info only presents data about IPs pertaining to 1. IP users on wikis without temporary accounts 2. temp accounts on wikis with temp accounts.--SGrabarczuk (WMF)（留言） 2025年3月14日 (五) 15:06 (UTC)[回复]
Thank you for your response. Please ask the team to clarify such information at mw:Trust_and_Safety_Product/IP_Info#Information_available to avoid further misunderstandings, as the current wording seems to imply that registered account traffic is also accounted into "all" activity. Thanks!--路西法人 2025年3月14日 (五) 15:46 (UTC)[回复]
Yup, 100%. You can join the discussion here: IPInfo: Update confusing label for "Users on this IP".--SGrabarczuk (WMF)（留言） 2025年3月14日 (五) 16:30 (UTC)[回复]
Thanks!--路西法人 2025年3月15日 (六) 00:37 (UTC)[回复]
目前政策好像是除WP:LTA外，需要广域封禁的IP段无法WP:VIP上公开报告，以后应该如何报告这种IP段？Python6345（查论编） 2025年3月29日 (六) 14:57 (UTC)[回复]
“Appropriate venues for such disclosures include pages dedicated to Long-term abuse. ”这是指包括但不限于。个人认为只要在有需要的情况下（例如是无法在不披露 ip 及仅提及某临时账号的情况下制止有关破坏行为），任何用于提报违反方针指引的页面，皆可于该处公开提报 IP。谢谢。--SCP-0000（留言） 2025年4月3日 (四) 03:45 (UTC)[回复]
(～)补充：本人提报/16主要从单一破坏IP发现，现有政策There must be a valid reason to investigate a temporary user. Note that using multiple temporary accounts is not forbidden, so long as they are not used in violation of policies (an example of a violation includes to evade blocks or bans).是否禁止仅因单一临时账户破坏查/16下编辑，必须合理怀疑其使用傀儡？--Python6345（查论编） 2025年5月3日 (六) 05:29 (UTC)[回复]
这句仅是指出使用多个临时账号并无问题，除非目的是用来违反方针指引。个人未见必须要求“合理怀疑其使用傀儡”才能检查，只要有合理理由（valid reason）就可以了。谢谢。--SCP-0000（留言） 2025年5月3日 (六) 07:35 (UTC)[回复]
一个问题：这个引入会让Wikipedia:常年提案#限制IP创建条目提案过时吗？我看英维的说法，似乎有影响到类似提案，但我不是很确定里面的“这份提案在演变中”的意思、还有他们如何应对。
Is the introduction of Temporary Accounts makes prohibiting unregistered users from creating article proposal obsolete? Looks like a similiar proposal on the English Wikipedia also affected by the introduction of temporary accounts, but I am not sure the meaning of This issue is currently evolving and how they react.--Saimmx（留言） 2025年4月23日 (三) 23:14 (UTC)[回复]
@Saimmx：就个人理解，临时账号和IP用户本质上都是“未有注册”的用户，尽管技术和实务上有所不同，但未至使该提案过时或无效。当然，个人认为可参照 en 的做法，在常年提案页面补充相关变化。但无论如何，该提案的状态应该是由社群决定，而非基金会。谢谢。--SCP-0000（留言） 2025年4月24日 (四) 02:56 (UTC)[回复]

小结

@Ericliu1912、人间百态、YFdyh000、LuciferianThomas、Akishima Yuka、Aqurs1、ZhaoFJx、Steven Sun、Python6345、Saimmx：依照上方讨论，社群似乎倾向支持500次编辑以上（参照延伸确认用户（extended confirmed user））及账户使用时间至少6个月（基金会方针规定）才能获得“临时账户IP检视者”（Temporary Accounts IP viewers）权限。而 SGrabarczuk (WMF) 指出（见上留言），尽管延伸确认用户与“临时账户IP检视者”的申请门槛相近，但其用途并不相同，故不建议采用相同的门槛（即500次编辑）。我个人认为或可考虑采用回退员（Rollbacker）的门槛（即1000次编辑）？

再者，除编辑次数这门槛外，要求申请者说明有反破坏等实际需要，账号最近一年内未有被封禁；且需透过人手授予（参见“我们考虑过的其他选项”段落），这几点应该没太大意见？副知所有曾参与讨论的编者。谢谢。--SCP-0000（留言） 2025年4月26日 (六) 03:40 (UTC)[回复]

支持试用初期人工授予，反对永久，不过这可以之后再谈。另外巡查及回退用户组必须包括此权限。--Aqurs 2025年4月26日 (六) 04:41 (UTC)[回复]
@Aqurs1：巡查员的申请门槛为编辑至少250次和参与本站至少30日，不符基金会方针规定的临时账户IP检视者的最低要求。个人认为巡查员的门槛至少应提升至与本站的临时账户IP检视者相等要求，如果只符合基金会方针但不符本站要求，未免有人借巡查来得到检视临时账户IP的权限。谢谢。--SCP-0000（留言） 2025年4月26日 (六) 05:17 (UTC)[回复]
如果申请人有担任巡查的资格，个人认为不应该剥夺其检视IP的权利。刻意借巡查而检视，但又没有应有的能力，自然可以雪球关闭。--Aqurs 2025年4月26日 (六) 06:02 (UTC)[回复]
“如果申请人有担任巡查的资格，个人认为不应该剥夺其检视IP的权利。”然而在基金会的方针下，基本上只有两个解决方案：一、将巡查的申请门槛提高；二、检视IP的权限不包括在巡查员，而需另外申请。不然会出现申请人有担任巡查的资格，但因不符基金会方针要求而不能授予巡查之情况发生。谢谢。--SCP-0000（留言） 2025年4月26日 (六) 06:36 (UTC)[回复]
是否预设开放回退员持有此权限（我不确定有没有这回事）？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月26日 (六) 07:53 (UTC)[回复]
@Ericliu1912：个人较早前在英文 Discord 询问将检视临时账号IP的权限加入至现有权限组（如回退员）的可能性，对此基金会的开发人员回应称，他们不愿这样做，这会令现有权限组的用户因存取临时账号IP（即非公开个人资讯）而承担额外风险，而那些用户并未对此表示同意（consented to）。
但如果是自动为回退员增加“临时账户IP检视者”权限组的可能性，考虑到他们似乎有相应 global script，似乎未必不行就是了，但我需要询问一下。谢谢。--SCP-0000（留言） 2025年4月26日 (六) 10:22 (UTC)[回复]
刚才 Aqurs1 在英文 Discord 询问能否为现有权限组的用户（如回退员）自动授予“临时账户IP检视者”，得到的回应是法律上并不可行。似乎现在还需要讨论的只有编辑次数这门槛？谢谢。--SCP-0000（留言） 2025年4月26日 (六) 17:30 (UTC)[回复]
以下提议条件为在基金会要求基础上新增，符合任意一项管理员即可授权：
  • 甲：需编辑至少600次，最近一年内没有受到封禁（不合理封禁除外），于反破坏工作中保持活跃。
  • 已：需已是巡查员或回退员，最近一年内没有受到封禁（不合理封禁除外），于反破坏工作中保持活跃。
  • 丙：需已是傀儡调查助理，最近一年内没有受到封禁（不合理封禁除外）。
Python6345（查论编） 2025年4月26日 (六) 17:51 (UTC)[回复]
@Python6345：个人认为可简化成这样：
申请者需符合基金会方针的最低要求，且需符合以下任一条件
  1. 需编辑至少600次，最近一年内没有受到封锁（不合理封锁除外），且活跃于反破坏工作，或有其他存取临时账号IP之需要。
  2. 现任巡查员、回退员、傀儡调查助理、过滤器助理或过滤器编辑者，最近一年内没有受到封锁（不合理封锁除外）。
不知意下如何？谢谢。--SCP-0000（留言） 2025年4月27日 (日) 07:22 (UTC)[回复]
无异议。Python6345（查论编） 2025年4月27日 (日) 12:40 (UTC)[回复]
7日无新留言，准备公示？Python6345（查论编） 2025年5月4日 (日) 03:41 (UTC)[回复]
就个人所知，基金会正更新相关政策，个人认为可稍等一下。谢谢。--SCP-0000（留言） 2025年5月6日 (二) 11:56 (UTC)[回复]
异想天开，能不能把当前回退员变成一个祖父用户组“回退员（旧）”，新设“回退员（新）” ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月3日 (六) 17:10 (UTC)[回复]
这有点异想天开了（--SCP-0000（留言） 2025年5月3日 (六) 17:31 (UTC)[回复]

非洲月

本主题全部或部分段落文字，已移动至Wikipedia talk:维基百科非洲月/2025。执行者：Jimmy-bot（留言） 2025年5月8日 (四) 08:14 (UTC)。[回复]

对各位是否了解监票员在安全投票机制中作用的简易调查

截至本讨论发布时，根据一项在站外（主要是 Telegram 自动确认用户群组和维基人的私人群组）的调查结果[1]显示，在收到的35张投票中，约有49%的用户不了解监票员可以查看投票者的IP地址、XFF和用户代理等信息（与用户查核员在进行用户查核时可查看的信息相同）。

因此，我在此邀请各位参与此调查，以便更加完整地确认中文维基百科社群对安全投票功能的了解。同时，在一段时间后，如若结果同在站外群组中获得的结果相同或不了解的人更多的话，那么我认为我们应当重新考虑是否在未来的管理人员选举中使用此功能。

谢谢。Iming 彼女の爱は、甘くて痛い。 2025年4月23日 (三) 11:03 (UTC)[回复]

所见画面长这样（即下方Stang提到的那张截图，经询问同意放在共享资源上）
--SunAfterRain 2025年4月23日 (三) 13:08 (UTC)[回复]

调查区

我了解监票员可以查看投票者的IP地址和用户代理信息

  1. Iming 彼女の爱は、甘くて痛い。 2025年4月23日 (三) 11:03 (UTC)[回复]
  2. Stang★ 2025年4月23日 (三) 11:21 (UTC)[回复]
  3. ZhaoFJx(Talk) 2025年4月23日 (三) 12:58 (UTC)[回复]
  4. -Peacearth（留言） 2025年4月23日 (三) 13:42 (UTC)[回复]
  5. 除此之外，倒是更希望顺便讨论监督员是否适合继续监票（抑或能转交其他适当人士负责）？这毕竟是一种非常的现象，而目前社群此一方面信任，更多是对于持有权限的维基人（以及有监管员辅助等因素），而非真切认为“监督员”此一权限实体应持久负责监票程序。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月23日 (三) 13:44 (UTC) 👍2[回复]
  6. Hamish T 2025年4月23日 (三) 13:58 (UTC)[回复]
  7.  ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年4月23日 (三) 16:04 (UTC)[回复]
  8. 一直知道监票员相当于CU员，只是不知到确实能拿到什么（本来以为可以看投票意向）1F616EMO（喵留言～回复请ping） 2025年4月24日 (四) 05:40 (UTC)[回复]
  9. (▲)同上。Python6345（查论编） 2025年4月25日 (五) 00:15 (UTC)[回复]

我不了解监票员可以查看投票者的IP地址和用户代理信息

  1. 自由雨日🌧️❄️ 2025年4月23日 (三) 11:05 (UTC)[回复]
  2. Aqurs 2025年4月23日 (三) 11:10 (UTC)[回复]
  3. 在下荷花，请多指教（欢迎签到） 2025年4月23日 (三) 11:23 (UTC)[回复]
  4. 维基病夫❤️边缘人小组·签到 2025年4月23日 (三) 11:26 (UTC)[回复]
  5. 用户名能看到吗？-某人✉ 2025年4月23日 (三) 12:09 (UTC)[回复]
    @AINH：安全投票是用户名 => IP，不是 IP => 用户名--SunAfterRain 2025年4月23日 (三) 12:12 (UTC)[回复]
    所以只可以看到ip，不能看到谁投哪票？--某人✉ 2025年4月23日 (三) 12:14 (UTC)[回复]
    只能看到谁投了票，且投票人员的IP与用户代理信息，不能看到用户具体投了什么票。--beef [talk] 2025年4月23日 (三) 12:17 (UTC)[回复]
    (？)疑问：如果看不到投了什么票，之前的安全投票如何排除无效票？Python6345（查论编） 2025年4月27日 (日) 03:58 (UTC)[回复]
    FYI: 截图（CC-0@0xDeadbeef） Stang★ 2025年4月23日 (三) 12:27 (UTC)[回复]
  6. SunAfterRain 2025年4月23日 (三) 12:12 (UTC)[回复]
  7. Пусть от победы☆к победе ведёт! 2025年4月23日 (三) 12:21 (UTC)[回复]
  8. August讨论‧签名‧回复请ping 2025年4月23日 (三) 13:53 (UTC)[回复]
  9. CuSO4 · 龙年大吉 2025年4月26日 (六) 08:30 (UTC)[回复]
  10. Shawwww（留言） 2025年4月26日 (六) 08:38 (UTC)[回复]
  11. 花开夜 留言 ·签名 ·贡献 2025年5月2日 (五) 01:05 (UTC)[回复]

讨论区

  • 另请参阅英文维基百科近期预备展开之有关征求意见；本地社群日后或可用作参考。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月23日 (三) 14:39 (UTC)[回复]
    静待本地部署安全投票.jpg ——ZhaoFJx(Talk) 2025年4月23日 (三) 15:11 (UTC)[回复]
    为啥不了解，就要重新考虑是否使用此功能？--百無一用是書生 (☎) 2025年4月24日 (四) 02:22 (UTC) +11[回复]
    @Shizhao：因为你维目前依然是没有CU存在的，上次恢复的议案好像也不了了之了，而安全投票这个看到的数据就是CU的数据。※我是认为如果有人有质疑这件事锅应该推给WMF，而不是现在在这里“调查”“重新考虑”就是 囧rz……--SunAfterRain 2025年4月24日 (四) 02:55 (UTC)[回复]
    换个说法：我们知道目前本站仍对于本地处理用户查核请求存在疑虑。根据调查可以看到，半数用户并不了解监票与用户查核本质上是一致的，那“本地来进行监票”对于这些不了解的用户就是一种信息的不透明，所以有必要考虑是否应该停止让本地来进行监票操作。 Stang★ 2025年4月24日 (四) 07:32 (UTC)[回复]
    但实际上当初引进安全投票时，“常见问题”已明言指出：“所有人（包括选举管理员）在选举期间都不会看到谁投给了谁，选举管理员在选举期间也只能看到谁已经投票。在选举结束后，选举管理员会看到包括投票者在投票当刻的CU Data（例如IP地址），目的是用作解决拉票或傀儡投票的问题。”所以本人认为，除非社群当年投票时泰半眼瞎或不负责任，否则恕不能认为大部分参与社群的维基人对此一事实毫无认知（这安全投票有多达八百余人参加，应该是个纪录）。而前述所谓“半数使用者”倚靠样本极小，亦显不能与之相比。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月24日 (四) 12:15 (UTC)[回复]
    当然，这不能代表社群同时认为授权监督员长久负责这一任务妥当，因为那时“常见问题”亦仅指出“选举管理员由监管员担任”，监督员之兼任当始自后来，故严格论之，祇能视作彼时社群明白负责可能管理选举者所肩负的权限。不过，早在第一场安全投票，也就是引进投票本身的表决之际，本地监督员即有参与，时日已久，已为成例；而自那时至今，社群就此亦未有多论，大抵是因为编者普遍信赖监管员及监督员共同执行监票工作。另外，单纯忘记此事的可能也是有的（我认为上面投“不了解”者，除当年未投票者外，应多数属之）。无论如何，这些事实都不妨碍社群重新讨论安全投票机制如何运行（甚至包含使用者查核权恢复等议题）。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月24日 (四) 12:16 (UTC)[回复]
    除非社群当年投票时泰半眼瞎或不负责任：什么时候给到Eric君“社群会负责任地分析情况再投票”的印象了……不就是什么都是风向而已。--路西法人 2025年4月24日 (四) 23:53 (UTC)[回复]
    啥啦== —— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月25日 (五) 02:07 (UTC)[回复]
    虽然但是，刚刚看到当年的讨论，我还是要吐槽一下：
    Stang added 2 subscriber(s): Wong128hk, jimmyxu.Dec 2 2021, 12:54
    Do we yet know who these people will be? :)
    We decided to set local oversights @Wong128hk and @jimmyxu as election admins, representing the community.
    所以您应该也算是“忘记”的那一边（ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月25日 (五) 06:40 (UTC)[回复]
  • 讨论重构：尝试处理电脑端示范图像超出可显示范围的问题。1F616EMO（喵留言～回复请ping） 2025年4月24日 (四) 05:31 (UTC)[回复]

重新引入CheckUser

监督员的职责明显跟“监票”不相关，纯粹请求有签署NDA的监督员担任此工作，导致参选监督员的候选人需要回答“CU技术性问题”也不理想。个人在此询问社群两个问题，而决定是否有需要再举行相关的RfC。

  1. 本站是否有重新引入CU的需要？
  2. 本站是否信任当选的CU执行所有用户查核工作（包括查核、监票等等）

--Aqurs 2025年4月25日 (五) 09:06 (UTC)[回复]

肯定会有人因为User:PMDdeSN而反对。我也是觉得很奇怪啦，2017年9月在任的本地CU，到2022年1月无一人隐退，WMF居然觉得CU还回来没事了。如果他们都没问题，那WMF拔权限做什么？如果他们还有有问题的可能，那我们把有问题的人选回来怎么办？WMF还不告诉我们解决没解决，让我们猜谜吗？ ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年4月25日 (五) 11:07 (UTC)[回复]
原有CU团队泄露过任何资讯不代表整站都有问题吧，当然了WMF有什么其他疑虑不知道，至少开了绿灯目前还是先看社群意见。--Aqurs 2025年4月25日 (五) 11:31 (UTC)[回复]
2017年时是CU的人，不把他们再选成CU不就行了。相信社群有办法选出来受信且有技术能力的用户。--beef [talk] 2025年4月25日 (五) 11:45 (UTC)[回复]
既然你说“2017年时是CU的人，不把他们再选成CU不就行了”，那能否基于此直接否定所有2017年时是CU的人的CU参选权？Sanmosa 新朝雅政 2025年4月29日 (二) 12:43 (UTC)[回复]
不应该，因为管理人员申请本身就是一套信任机制。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月30日 (三) 06:14 (UTC)[回复]
我的意思是有这方面的疑虑的人完全可以合理地将2017年的事情作为反对理由。也会有人认为已经过了8年，而应该给人一次机会。我不觉得直接否定参选权是一个公平的决定。--beef [talk] 2025年5月1日 (四) 02:02 (UTC)[回复]
引用个人过去的意见“尽管基金会不愿透露相关事件是否解决，但既然已允许 CU 重新引入，可合理推断基金会认为本地可安全地进行 CU（前提符合基金会提出的条件）。”
现时最大的问题是社群互相之间的信任程度，正如魔琴君早前在 ac 群引用来自 WMF T&S 主管于 2022 年一次会议中的说法“the challenge really is whether the local community trusts itself, that the people trust each other, together elect such a group and then trust the volunteer serving in the group on the broad community’s behalf,”，而 2017 年的事件有否解决已非重要，谢谢。--SCP-0000（留言） 2025年4月28日 (一) 15:18 (UTC)[回复]
其实应该添加第三个问题（或第一个问题，看优先层级）：若本地未有使用者查核员，是否应允许监督员继续代行此一任务？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月25日 (五) 13:29 (UTC)[回复]
@Ericliu1912：议案不通过就是维持现状，那也是默许了，所以我觉得不用特别列出来没关系。--SunAfterRain 2025年4月30日 (三) 14:32 (UTC)[回复]
仅从我之前协助处理火腿的体验来说，我个人觉得重新引入CU是有必要的，但是CU牵扯到太多事情了。。。。--Hamish T 2025年4月29日 (二) 00:24 (UTC)[回复]
还有人记得这个吗？2021年之前的用户查核数据有可能（而且是大概率）已经被泄露光了。。。--2A14:7581:8400:0:0:2:0:A30A（留言） 2025年4月30日 (三) 14:20 (UTC)[回复]
请注意这不是贵站的问题。--Aqurs 2025年4月30日 (三) 14:39 (UTC)[回复]
2017年查核信息被泄露，随后中国大陆维基人用户组领导人守望者爱孟被基金会全域封禁；2018年基金会剥夺了本地所有查核员的权限；2021年基金会禁止中国大陆用户签保密协议（也就是禁止授予中国大陆用户监督权与查核权），随后就是震惊全网的OA2021，中国大陆维基人用户组第二任领导人Techyan被封、曾任用户查核员与监督员的Alexander Misel被剥夺管理员权限。

我们再看看基金会给出的理由“以及有证据表明被除权者滥用站务工具支持该组织某些被禁制成员的活动，包含人肉搜索”，以及某人在站外的口出狂言“举报”，可想而知，重新引入查核权会给本站所有用户（尤其是中国大陆和中国香港用户）带来极为严重的安全隐患。--2A14:7581:8400:0:0:2:0:A30A（留言） 2025年4月30日 (三) 14:48 (UTC)[回复]
除此之外，还有个问题：如果重新引入查核权，Jimmy Xu和Cdip150是立刻复职呢，还是重新选举呢？--2A14:7581:8400:0:0:2:0:A30A（留言） 2025年4月30日 (三) 14:49 (UTC)[回复]
本人倾向于所有用户查核员都应该重新选举。--beef [talk] 2025年5月1日 (四) 02:05 (UTC)[回复]
（意见同上）—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月1日 (四) 09:08 (UTC)[回复]
我不觉得社群能够再给予足够的信任了，保护人身安全比抓到傀儡更重要。Elvaaae（留言） 2025年4月30日 (三) 17:47 (UTC)[回复]
IP君跟Elvaaae君，我想问一个问题，2017发生的事故要所有人背锅吗？贵站曾经发生事故就代表了不信任来自中文社区的“用户查核员”？目前有参与到中文社区的用户，有だ＊ぜ跟0xDeadbeef分别担任申诉专员跟英维用户查核员，请问他们获得用户的CU资讯会对社群的隐私造成有什么影响吗？请不要因为过去曾经发生事故而带有偏见。--Aqurs 2025年4月30日 (三) 19:02 (UTC)[回复]
根据本地WP:CUP#1下列出的所有方针，若引入本地用户查核，所有使用用户查核的情况都必须在WP:SPI提出，完全无法发生用户查核员随便获取任何人的IP地址信息的现象，本地的其他用户查核员会时常关注查核日志并检查每一次查核是否有理有据，所以若发生滥用查核权的现象相信能够很快发现。
至于cuwiki相关：cuwiki只存储长期破坏者（WP:LTA、长期在WP:SPI出没的用户）的信息，此前cuwiki信息泄露，无法代表本地查核日志就被泄露，也无法代表任何人就能直接进行用户查核。
至于此前的

至少3个管理员，说过：把自己的管理员账户给我。但都被我拒绝。我回答：等你们什么时候混成CUer了，再把账户给我。现在CUer才是王道。管理员虽然也重要，但可CUer相比差得远。
— [27]

这样一句话，我觉得有点危言耸听，不能一个人随便吹牛说大话就能让整个社群人心惶惶吧。--beef [talk] 2025年5月1日 (四) 02:22 (UTC) 👍1[回复]
想问下查核日志（不包含敏感资讯的）有公开给所有人查看的可能吗？--Elvaaae（留言） 2025年5月2日 (五) 15:25 (UTC)[回复]
或许可以，但是难以设计。比如说如果只公开针对用户的查核日志，也有可能会公开链接账户和IP地址的联系，我觉得我们应该先讨论一下让选举出来的查核员互相监督是否可行，又或者可以由其他方案，例如设立新的用户组仅有只读权限起到监督的作用（然而实际上只读权限需要的信任也是很高的）--beef [talk] 2025年5月3日 (六) 02:38 (UTC)[回复]
我说难听一点啦，你翻墙出来本来就要保护好自己了，就算没有CU人家想抓你依然有办法抓好吗...--SunAfterRain 2025年5月2日 (五) 03:31 (UTC)[回复]
且不说翻墙的中国人怎么样，很多香港使用者本就没有用VPN编辑你维的习惯好吗--Elvaaae（留言） 2025年5月2日 (五) 15:26 (UTC)[回复]
@Elvaaae：这个我真的只能说自己的国情就是那样请多小心，如果你自己都不注重保护自己的话就算基金会今天下了一百道保护也拦不住政府搜到你--SunAfterRain 2025年5月3日 (六) 14:45 (UTC)[回复]
@SunAfterRain 嗯，那监督员也不应该删掉侵犯隐私的内容，毕竟是“你自己不小心被人肉的”；基金会也不应该OA2021，毕竟保护自己是你自己的事；可供查证方针也应该取消，因为上维基的人应该学会自己辨认内容的真实性--103.196.21.39（留言） 2025年5月3日 (六) 13:43 (UTC)[回复]
请不要自己无限上纲。--SunAfterRain 2025年5月3日 (六) 14:45 (UTC)[回复]
如果是仅因需要监票的话，那可以考虑另设立electionadmin（监票员）而非直接引入CUer。在当前SPI转交元维基查核没有系统性问题的情况下，无需仅因监票（毕尽CUer也不是只监票而已）而将之前已证明有问题的体制重新引入。WP:没坏别修（指SPI）。--（☎）dt 2025年5月2日 (五) 00:07 (UTC)[回复]
@ATannedBurger：我记得你说的这个监票员是被技术问题本地安全投票的任务卡住了--SunAfterRain 2025年5月2日 (五) 03:29 (UTC)[回复]
英文维基百科那边正在讨论，等他们讨论完，技术阻碍应该就清得差不多了。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月2日 (五) 15:49 (UTC)[回复]
“之前已证明有问题的体制重新引入”当基金会已经处理了 WMC 相关用户时（且 OA2021 已是四年前的事），他们也愿意让社群重新引入 CU 时，那还有什么潜在的问题社群尚未解决？谢谢。--SCP-0000（留言） 2025年5月2日 (五) 15:53 (UTC)[回复]
您如果要认为这种事是偶发性事件也罢，虽然我自己是比较没有信心就是了。一次（2017）还好说，两次（2017 + 2021）恕我没办法认为不存在系统性的问题，而系统性的问题（你要把这个称为“特定群体对CU的不信任”也好，虽然我认为这是表现出的结果，不是问题本身）可不是只能靠处理几名使用者解决的。
我认为的问题无非就是当前CU当选门槛过低且缺乏监管（监管员有申诉专员定期监督，申诉专员则是直接由WMF指派），当然我也认知到有其他问题我先前是还没想到的，比如上方提到的隐私，以及对CU数据泄露0容忍的立场。“如何客观的确保CU数据不会被泄露，尤其是在缺乏CU本身公开透明的情况下”这我认为是个很好的问题。--（☎）dt 2025年5月2日 (五) 17:26 (UTC)[回复]
基金会将会定期稽核中文维基之用户查核活动至少一年，此举包含一年后是不是要继续持续这样的稽核机制等 - WMF都说他们愿意监督中维的查核使用，为什么不可以引入CU呢？
你所说的系统性问题，究竟是什么系统性问题？据我所知，我们现在讨论的是可否引入CU，而不是如何引入CU，“当选门槛过低”是第二阶段的问题，见我RfA的留言。
如何客观的确保CU数据不会被泄露，尤其是在缺乏CU本身公开透明的情况下 你觉得这是一个合理的问题吗？没错，只要没有本地CUer，那么本地CU数据就不会泄露给除监管员或其他全域权限用户之外的人。至于CUwiki上的远古中维数据，也是任何项目的CU都可以访问，反正不讲中文的人获取本地数据我们无所谓，只要说中文的人中维社群就不信任了吗？
公开透明与数据泄露又有什么关系呢？“公开透明”的理由还能说成“为了防止数据泄露”吗？
既然大家都是人类，我们是在人类与人类之间的对话，我就这样和你说吧，不管怎么样你都无法防止数据泄露。唯一的方法就是选出社群足够信任的用户。但是，抛开有没有能被社群信任而担任CU的用户不提，对于本地引入CU你还有什么意见吗？--beef [talk] 2025年5月3日 (六) 02:48 (UTC)[回复]

由于讨论已偏离到私人恩怨，本框内讨论文字已关闭，相关文字请在本页面保留并不再编辑。
如有异议，请咨询互助客栈或其他管理员。执行人：--SunAfterRain 2025年5月5日 (一) 02:52 (UTC)
真不知道您是在急什么，急到只选择性回复部分的论点，其余的则被随意归类为属于“如何引入CU”。我认为呢，在我上方提到的问题没有得出对应且可被接受的解答前 (不论事实上还是方针而言) 是不能引入CU的。另外，我并没有要把CU搞公开透明的意思。尽管我不曾担任过CUer，但作为SPI助理也是略懂一二这方面的红线。
还有，我不认为这样拆成几个阶段的方式是好的。像我的话一旦到了某个环节就会反对，然后可能因那项的相对多数搞到出局，但这种事对我来说是个dealbreaker (指没这个我就反对设立了)。环节越多，越多这样的情况就会发生，最后导出你或许like但不一定代表多数的结果，因为反对意见都在这个过程中被逐渐filter掉了，这也是为什么我认为尽管ARBCOM是有经过讨论，有你口中的“共识”，但到实际执行的时候不少用户仍有微词的原因。--（☎）dt 2025年5月3日 (六) 03:17 (UTC)[回复]
真不知道您是在急什么，急到只选择性回复部分的论点 我的天哪，为了防止我第二次被你在讨论社群程序时的发言恶心到而导致我又没有心态去参与中维社群讨论，以后只要有你参与的讨论我都不会发言了，很抱歉，但是我实在看不出任何其他的办法。一而再再而三地顾左右而言他，说话说不到重点上，我真的受够了。--beef [talk] 2025年5月3日 (六) 15:02 (UTC)[回复]
毕竟能写出 你那时候又在做什么？的，今天便能说我很急。那你跟不急的人讨论吧。你也说了，一次还好说，两次就没办法了。没错，我2024犯了认为和你能正常、心平气和、就事论事讨论的错误，那么2025再犯一次我就知道不会再犯了。--beef [talk] 2025年5月3日 (六) 15:25 (UTC)[回复]

哎呀这说到底还是道德问题，虽然我很不想这么说，社群应该也挺多人不会认同我这个观点的。我为什么说是道德问题呢?因为规则是死的人是活的，人只要自身道德上的自制力不够高，一旦处在阴影下或规则无法顾及之处，又有特定诱因(如达成某种目的)，此时隐私泄漏问题就很容易发生，至于规则无法顾及之处，当规则写的不够全面，一或者是文字上可以以另外一种方式解读，此时就会出现“文字游戏”这种情况。：（
申明一下：我不是说规则不重要。--~~Sid~~ 2025年5月3日 (六) 14:02 (UTC)[回复]
剩下恢复信任的心理建设吧？因为终究是人身安全问题，难以用所谓理性彻底排除疑虑。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月5日 (一) 12:55 (UTC)[回复]
回到我先前的论点，我自己是高度怀疑因监督员的职责明显跟“监票”不相关，纯粹请求有签署NDA的监督员担任此工作，导致参选监督员的候选人需要回答“CU技术性问题”也不理想所以需要引入CU的必要性。你要说这是纯粹的心理建设不足也罢，起码我认为我下面提到的方案接受度会比较高一些。先一步一步来，试试水温也好。--（☎）dt 2025年5月5日 (一) 16:14 (UTC)[回复]
这可以算是其中一个推动的原因，但是引入CU是不必要吗？你没有提出合理原因去表达这是不必要，终究是“过去的人有问题不代表体制有问题”。如果你说引入CU有什么必要，可以自行去看一下SPI现在处理得有多慢。--Aqurs 2025年5月5日 (一) 16:24 (UTC)[回复]
现在SPI处理慢的原因不是因为监管员不愿查或不活跃（监管员通常在转交后24小时内就能给出结果，除非需要更多资讯），而是因为本地助理人手不足以尽速转交请求，请先搞清楚真正的问题在哪里再拿出来说。就算有本地CUer，在助理人手不足的情况下仍无法有效提高SPI处理效率。--（☎）dt 2025年5月5日 (一) 18:36 (UTC)[回复]
本地CU当然可以直接接受/拒绝查核请求。。。至少比现在要助理审核一次，然后转过去元维基效率来得更高。这反倒是取决于CUer办事能力，你没有回答我为什么引入CU是不必要。--Aqurs 2025年5月6日 (二) 02:36 (UTC)[回复]
我认为在此处提起是否需要CU是杀鸡焉用牛刀...另设electionadmin反而是更practical的解决办法，这样清楚了么。你提到的处理SPI效率来的更高也并不代表引入CU具有必要性。
监票并不是只能CUer来做，也不存在“参选监督员的候选人需要回答“CU技术性问题”也不理想...[所以]本站是否有重新引入CU的需要”这一命题，参选人在选监督员前应当清楚监督员当前的职责，而非事后因候选人自身的能力不足，反而对制度进行全方面的检讨。当初社群决定监督员来负责监票或许事后看来是个无奈之举，但不代表为了监票就应该引入CUer。
然后你说是因为SPI处理慢好了，请问一下假设我现在去SPI把所有请求都处理了 (该转交meta的转交meta，该请管理处理的挂请管理处理)，那是不是就不用引入CU了呢？--（☎）dt 2025年5月6日 (二) 03:32 (UTC)[回复]
你的不信任源自于过去曾经发生“数据泄漏”事件，但是用户查核这一套系统有问题吗？所有有用户查核权限的用户都有可能会泄露数据，偏偏只有贵站会有这一问题？你上面说CU欠缺监管，WMF都会来亲自监督了，你的不信任难道不就是你的偏见吗？--Aqurs 2025年5月6日 (二) 03:52 (UTC)[回复]
我总觉得你还卡在“我不信任CU”这种偏见来看我的言论。不过说真的，我能叫你不要这么做吗？CU有没有问题不代表本地需不需要。--（☎）dt 2025年5月6日 (二) 04:15 (UTC)[回复]
设立“electionadmin”的问题是监票得到的资讯是跟用户查核一样，那么不是同样会有泄露的风险吗？为什么你认为“换了个包装”就代表安全呢。--Aqurs 2025年5月6日 (二) 03:54 (UTC)[回复]
可差的多了，没投票的话就不会被记录相关资讯。使用者查核可是只要一登入就会被记录相关资讯了。这不仅是换了个包装，连内容物都不一样了呢。--（☎）dt 2025年5月6日 (二) 04:12 (UTC)[回复]
根据本地WP:CUP#1下列出的所有方针，若引入本地用户查核，所有使用用户查核的情况都必须在WP:SPI提出，完全无法发生用户查核员随便获取任何人的IP地址资讯的现象，本地的其他用户查核员会时常关注查核日志并检查每一次查核是否有理有据，所以若发生滥用查核权的现象相信能够很快发现。请看一下上面的内容，恕至少个人认为纯监票的风险跟用户查核没两样，甚至更高。--Aqurs 2025年5月6日 (二) 04:16 (UTC)[回复]
我是觉得没有可比性。纯监票只有在选票投下的时候才会看的到投下选票当下的技术资料，而使用者查核能看到查核当下过去90天的所有资料。--（☎）dt 2025年5月6日 (二) 04:26 (UTC)[回复]
监票员（即你提出的electionadmin）有权限查阅“投下选票当下的技术资料”就代表有泄露的风险吧，风险是对等的，不是说这资料重要度较低就没有风险。那么如果“引入CU有信任问题”，为什么社群会信任监票员？不认为这是更practical的解决方法。--Aqurs 2025年5月6日 (二) 04:33 (UTC)[回复]
本地需要监票人(不管是现在的监督员、之后的监票员或CUer）来报选票。Practical指的是这个不会囊括其他当前不需要用的权限这样的practical。
如果是要解决监督员的选票问题的话，那就是分拆监票员，专门报选票。
如果是要含括SPI的话，那就是CUer。
至于说SPI看的到的资料和安全投票看的到的资料的差别，我上面已经提到了。要不然就是将监票正式列入监督员的responsibility。
当然，如果本地要放弃安全投票的话，那不妨也是个解决方式。--（☎）dt 2025年5月6日 (二) 04:50 (UTC)[回复]
重点其实是如果本地信任引入CU的话就应该引入去处理“监票+SPI”，不信任的话没问题，但不应该弄一个新用户组去监票或是让监督负责这工作。--Aqurs 2025年5月6日 (二) 05:02 (UTC)[回复]
尽管我认为监票和SPI还是有本质上的不同，但同意你不应该弄一个新使用者群组去监票或是让监督负责这工作的结论。@Elvaaae：你觉得呢？貌似不能既要又要的样子。
其实也可以根据这点重新再办个投票 (不管是否要用安全投票来进行投票)，我记得最初谈及是否该启用安全投票的时候，最后也是透过投票的方式决定的。--（☎）dt 2025年5月6日 (二) 05:25 (UTC)[回复]
(～)补充我认为在此处提起是否需要CU是杀鸡焉用牛刀，CU涉及到太多争议了。另设electionadmin反而是更practical的解决办法。--（☎）dt 2025年5月2日 (五) 17:33 (UTC)[回复]
英维的electionadmin只负责配置，而scrutineer（能看到用户数据的）则只能由CU处理，这里和这里的讨论怎么没见你参与？
CU涉及到太多争议了 - 那咱们就特定争议讨论争议可以吗？--beef [talk] 2025年5月3日 (六) 02:33 (UTC)[回复]
什么时候我说中维的electionadmin和英维的electionadmin职责相同了？还有，既然你说scrutineer（能看到用户数据的）则只能由CU处理，那为何本地监督员能在技术上兼任scrutineer?--（☎）dt 2025年5月3日 (六) 03:20 (UTC)[回复]
不能认同这是“没坏别修”，这不是现在转交元维基没有“系统性问题”就一直拖延下去的，CU体制没有问题，有问题的是人。--Aqurs 2025年5月5日 (一) 16:20 (UTC)[回复]

参考资料

  1. ^ https://t.me/wikipedia_zh_ac/191729

两岸四地用词问题

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

仍然有大量人物条目的出生地点使用的是 中国而非 中华人民共和国，是否应当一致使用PRC？（当然，mos:信息框旗帜）--KurGenera(留言) 2025年4月28日 (一) 23:39 (UTC)[回复]

若未提到“中华民国”或“台湾”等词汇，或当事人本为一九四九年以后出生， 或可斟酌使用“中国”。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年4月29日 (二) 05:55 (UTC)[回复]
写就“中国某省某市”云云，很显然地读者能辨明此地（在人物生时）属何种政治实体管辖，没有歧义的来由。--PexEric 2025年4月29日 (二) 16:44 (UTC)[回复]

请求保护页面

本主题全部或部分段落文字，已移动至Wikipedia:请求保护页面。执行者：ZhaoFJx(Talk) 2025年4月29日 (二) 15:40 (UTC)。[回复]

Sidebar问题

长久以来，有大量计划和帮助页面罗列超过一个sidebar，这实在是让我难以理解的中维传统。在我看来这样不仅难以起到索引作用（索引的事应交给navbox），反而大大影响页面布局。Sidebar应该只加入范围最小最相关者即可，真的犯不着什么都来个{{policylist}}。恳请就此事达成共识，不想我清理一回就被回退一回。--PexEric 2025年5月3日 (六) 12:49 (UTC)[回复]

“Sidebar应该只加入范围最小最相关者即可”是否有共识基础。是有人当成自定义目录（大纲）在用？底栏与侧栏的navbox，我没有特别的偏好。布局是否好看，可能看情况、与访客分辨率相关？类似于图文混排是否好看。--YFdyh000（留言） 2025年5月3日 (六) 13:04 (UTC)[回复]
试举几例：WP:NOT中，因非要保留sidebar致使只能加入{{clear}}产生近乎整屏的留白，即使限制页面宽度还是有空白。而不加入clear则有可能像WP:BLP那样把{{shortcut}}被挤得分不清哪个是哪个；WP:条目用了3个sidebar，WP:IUP用了4个。除了这些极端的，其实还好。--PexEric 2025年5月3日 (六) 13:24 (UTC)[回复]
“整屏的留白”是特定分辨率下适配问题？820*1180px的设备仿真能看到，912x1368的仿真则没有出现留白。具体技术原理不太清楚。本站是否没有访客推荐（常见）分辨率及相关适配要求的检查单。--YFdyh000（留言） 2025年5月3日 (六) 15:21 (UTC)[回复]

DYKC发生什么事了？好多提名都没处理

（今天早上看到有人给我的页面写了点建议，后来才反应过来应该早就结束了？）4月30日提名的“列支敦士登大选列表”，最后留言是5月3日，票数达标也没有什么问题，都已经到第8天了，从这一条往下一直到5月4日还有不少提名都是这样，发生什么事了？--Nanhuajiaren（留言） 2025年5月8日 (四) 07:33 (UTC)[回复]

看到了并手动通过部分（）--千村狐兔（留言） 2025年5月8日 (四) 10:51 (UTC)[回复]
检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia:互助客栈_(全部)&oldid=63126193”