跳转到内容

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

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

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

按此刷新页面。

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

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

查看全部讨论

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

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

消息

This Month in Education: April 2025

Apologies for writing in English. Please help to translate in your language.

This Month in Education

Volume 14 • Issue 4 • April 2025

In This Issue

This Month in GLAM: April 2025



Headlines
Read this edition in full • Single-page

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

Wikidata weekly summary #679

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

Events

Press, articles, blog posts, videos

Tool of the week

  • Wdactle game -- is a Wikidata version of Redactle! It's a game where you are shown a Wikidata Item with all labels and words redacted and have to figure out what it is. Guessing a word reveals all the places where it is used. Built by Luca Werkmeister during the Wikimedia Hackathon 2025.

Other Noteworthy Stuff

  • ⚠️ Wikidata Query Service graph split: As you know Wikidata Query Service was no longer able to handle the complete set of data Wikidata has. To address this the graph in Wikidata Query Service has now been split into a main graph (that continues to be at query.wikidata.org) and a scholarly graph (that is at query-scholarly.wikidata.org). For more details please see Wikidata:SPARQL query service/WDQS graph split.
  • Join the Wikidata:Impact stories global campiagn. We're celebrating the amazing Wikidata community - editors, developers, librarians, and creators - and inviting you to share how Wikidata is used. Your story can inspire others and grow the community. Submit yours or nominate a cool project by June 6.

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

  • mul language code: We are fixing an issue where Items can't be found by their mul language label or alias (phab:T392058)
  • Wikibase REST API: We are working on phrase matching for the simple search (phab:T389011)
  • Dark mode: We fixed a color contrast bug with the entity selector when making new statements (phab:T393641)
  • Ontology: We’re working on an updated, more complete version of the wikibase.owl ontology file (phab:T371752)

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

Books & Bytes – Issue 68

The Wikipedia Library: Books & Bytes
Issue 68, March–April 2025

In this issue we highlight two resource renewals, #EveryBookItsReader, a note about Phabricator, and, as always, a roundup of news and community items related to libraries and digital knowledge.

Read the full newsletter

Sent by MediaWiki message delivery on behalf of The Wikipedia Library team --2025年5月13日 (二) 10:19 (UTC)[回复]

—此条未加入日期时间的留言是于2025年5月13日 (二) 16:14 (UTC)之前加入的。

The Signpost: 14 May 2025

News, reports and features from the English Wikipedia's newspaper
Read this Signpost in full · Single-page · Unsubscribe · Global message delivery 2025年5月14日 (三) 22:01 (UTC)

临时账户：存取 IP 位址和后续步骤

本主题全部或部分段落文字，已移动至Wikipedia:互助客栈/其他。执行者：--此条未正确签名的留言由SGrabarczuk (WMF)（讨论｜贡献）于2025年5月14日 (三) 23:47 (UTC)加入。。[回复]

征求《通用行为准则》协调委员会（U4C）候选人

《通用行为准则》执行指南和《通用行为准则》协调委员会(U4C)宪章的投票结果可在Meta-wiki上获得。

您现在可以提交您在U4C服务的候选人资格，截至2025年5月29日12:00 UTC止。有关资格、程序、和时间表的资讯请参阅 Meta-wiki。候选人投票将于2025年6月1日开始，为期两周，于2025年6月15日12:00 UTC结束。

如果您有任何问题，可以在选举讨论页面上提出。-- 感谢您与U4C合作

Keegan (WMF) (留言) 2025年5月15日 (四) 22:07 (UTC)[回复]

公告: unblock-zh.org 地理区域转移

为了让占主要用户数量的亚洲用户访问更加迅速，现在unblock-zh.org的地理区域已经转移至韩国首尔（原新泽西）。（如果遇到打不开，可能跟DNS扩散有关，稍等片刻后问题会自行解决）Bluedeck 2025年5月16日 (五) 17:47 (UTC)[回复]

🤯 —— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月16日 (五) 17:50 (UTC)[回复]

Wikidata weekly summary #680

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

Discussions

Events

Press, articles, blog posts, videos

Tool of the week

  • Wikidata-Taxonomy is a Command-line tool and library to extract taxonomies from Wikidata.

Other Noteworthy Stuff

  • We are improving and expanding our Help and documentation pages, please tell us what you think: Parser Functions

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

  • UI: We are putting the finishing touches on the new search box that will make it easier to search for Properties, Lexemes and EntitySchemas as well (phab:T321543)
  • Dark mode: We fixed the last known issues and are getting ready to roll it out
  • Mobile statement editing: We are refining prototypes for testing and started technical investigations
  • Wikibase REST API: We are continuing the work on simple search, focusing on phrase matching now (phab:T389011)
  • Query Service: We are working on a small experiment to show a notification for simple queries that are better run on other APIs (phab:T391264)

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


方针

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

本准备移动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:Templates_for_discussion）页面提删的。这样可能更有助于集中分析比对，且扩大讨论参与度。 ——自由雨日🌧️❄️ 2025年5月13日 (二) 23:36 (UTC)[回复]

原则上我同意这个作法。不过人手问题（实际来说，就是有多少人愿意讨论）可能需要注意一下。--Saimmx（留言） 2025年5月14日 (三) 03:04 (UTC)[回复]

据方针WP:讨论发起位置“讨论结束后亦应让讨论原地存档，避免重复在多个页面存档后出现讨论分支。”，移除了{{存档至|Wikipedia talk:非原创研究|Wikipedia talk:导航模板}}模板。可在这些讨论页发送讨论通告来表示客栈有过关于该主题的讨论。 ——自由雨日🌧️❄️ 2025年5月14日 (三) 12:34 (UTC)[回复]

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

近日整理交通相关条目屡遇交通迷持续加入过度着色的文字以及原创研究内容，因此在此重提建立相关指引，已知目前已有的相关草案有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)[回复]
不同意您说的“除了维基百科，中国大陆已经没有别的地方可以放置这些琐碎资讯了，这是很可怕的事情。”，(►)移动到维基学院是可行的选择。--自由米花🌾🌼 2025年5月10日 (六) 08:18 (UTC)[回复]
我在广州地铁四号线南延段列车条目那里进行过移动尝试，移动内容包括电机、主逆、辅逆的参数，乘客信息系统，以及定型编号列表。结果后来，维基主条目那里，编号表格又被别人加了回去 囧rz…… 表格现在被我改成了默认折叠状态，但是说实话，那个表格其实只要两句话就能说明清楚。BIT0865 · Discussion · 燕房线永远的神！ 2025年5月10日 (六) 12:08 (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)[回复]
(！)意见：后半句不赞同（该内容发表时已划去）。现场拍摄的照片，是在案件发生现场直接拍摄而成的，它记录了案件发生时的真实情况，没有经过复制或转述，因此符合原始证据的定义。现场拍摄的照片在法律上为原始证据，即在佐证层级方面属第一手来源。依据维基百科:非原创研究:第一手来源只能用于描述性断言。若该照片反映的是一件简单事实且理性且受过教育的非专业人士能够加以验证，则不属于原创研究范畴。—— 西行寺海苔子 ハナノモトニテ 2025年5月9日 (五) 14:34 (UTC)[回复]
您所说的这些看似更符合在维基学院发布。个人(－)反对此案。--自由米花🌾🌼 2025年5月10日 (六) 08:23 (UTC)[回复]
最后一段的最后一句 —— 若其涉及的内容确实适合写入维基学院 —— 可以去掉。至于其他修改部分，我们有必要就何种信息为“琐碎信息”达成共识 —— 对普通乘客而言，确实只需要稍稍介绍外观和内装即可，但是有的爱好者可能会觉得不够。BIT0865 · Discussion · 燕房线永远的神！ 2025年5月10日 (六) 12:24 (UTC)[回复]
在下是认为，如果是来自公开可靠来源所介绍的可以写入，但来自非公开或原创研究的则不予收录，就目前已查询到的，汽车也是有介绍引擎型号等。--🚊　铁路Railway 论．签 2025年5月13日 (二) 06:49 (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)[回复]
明显地不是每一条公交线路都满足关注度，利用GNG评判是合理的选择。--自由米花🌾🌼 2025年5月10日 (六) 08:21 (UTC)[回复]
此提案文字涉及事项，铁路车站、物理线路部分业已在维基百科:收录标准/交通中有规定（尽管我个人觉得该方针有后续细化空间），直接内链反而更好。另外，正如此前讨论在下与MNXANL观点，仍呼吁此提案全文应依据依据具体类别分情况讨论。-- 西行寺海苔子 ハナノモトニテ 2025年5月10日 (六) 08:32 (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) 😄2[回复]
如果你不用人话，偏要用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)[回复]
我认为，可以使用AI生成内容，但是提交编辑之前应当（shall）仔细检查，修正格式等以符合质量要求。——Fthasdd（留言） 2025年5月14日 (三) 10: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)[回复]
现阶段拟定的方案是WP:权限申请移除“简介”与“要求”的全部内容，WP:申请解除权限引述现WP:解除权限方针的部分代之以现WP:权限申请“解任”的内容，并将其中指向WP:申请解除权限的内部链接替换为“本页”。另外，为确保页面命名一致性，现建议WP:权限申请更名为“WP:申请权限”，所有子页面同。Sanmosa 新朝雅政 2025年5月8日 (四) 23:48 (UTC)[回复]
会废除方针？--Xiplus#Talk 2025年5月10日 (六) 02:55 (UTC)[回复]
@Xiplus：会，WP:权限申请的方针地位会被废除。Sanmosa 新朝雅政 2025年5月10日 (六) 10:01 (UTC)[回复]

“IP封锁豁免权及确认使用者权限除外之权限切勿于本页外申请”一句应修订到各方针页。--Xiplus#Talk 2025年5月11日 (日) 00:53 (UTC)[回复]

@Xiplus：可，我明天再看看具体要放到哪个方针页里。Sanmosa 新朝雅政 2025年5月11日 (日) 12:22 (UTC)[回复]
所有权限的方针都要吧（这两个除外），除非另立申请权限方针。--Xiplus#Talk 2025年5月11日 (日) 12:55 (UTC)[回复]
@Xiplus：刚才统计了一下，理论上需要修订的页面应该包括WP:新页面巡查、WP:回退功能、WP:巡查豁免权、WP:大量讯息发送者、WP:AutoWikiBrowser、WP:大量账号建立者、WP:档案移动员、WP:跨维基汇入者、WP:模板编辑员、WP:过滤器助理、WP:IP封锁豁免权授予者、WP:活动组织者与WP:过滤器编辑者，然而其中大部分的页面似乎已经有相关的描述了。此外，我留意到这些页面虽然大多数是方针，但还是有少数几个是指引，是否需要把那几个指引与现非规则的WP:巡查豁免权也提升为方针？Sanmosa 新朝雅政 2025年5月12日 (一) 07:39 (UTC)[回复]
用词不一样，并没有禁止在其他地方申请。提升方针与此无关，另案讨论。--Xiplus#Talk 2025年5月12日 (一) 13:01 (UTC)[回复]
@Xiplus：那可以调整既有条文的用词至有禁止在其他地方申请的意思，但需要提具体方案吗？感觉这要做比较占这里的版面。提升为方针的事情我打算之后才处理，我也只是询问一下意向而已。Sanmosa 新朝雅政 2025年5月15日 (四) 13:51 (UTC)[回复]
（其实不用什么东西都提去方针⋯⋯）—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月15日 (四) 16:17 (UTC)[回复]
应该要提具体方案。--Xiplus#Talk 2025年5月18日 (日) 05:13 (UTC)[回复]
@Xiplus：具体方案：
以上。Sanmosa 新朝雅政 2025年5月18日 (日) 06:38 (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)[回复]

@ASid：如果是这样的话，倒不如把讨论拆得更完整些，两个提案各自一个小标题。Sanmosa 新朝雅政 2025年5月12日 (一) 07:44 (UTC)[回复]
OK的，不过现在没什么人要参予讨论，看起来又要凉了。:(--~~Sid~~ 2025年5月16日 (五) 01:32 (UTC)[回复]
edit.~~Sid~~ 2025年5月16日 (五) 01:33 (UTC)[回复]
@SunAfterRain、YFdyh000、Python6345、Kurgenera、自由雨日、鐵路1、August.C、Shizhao、Aqurs1、Znppo、花开夜：Hi here!很抱歉打扰各位了，鉴于讨论冷掉，故我把各位ping过来，
先不说提高巡查员标准的事情，为什么我说不用特地讨论标准的问题，因为“将自动巡查与巡查员权限组分离”已经一定程度上降低巡查员的标准，所以我才会说不用太过在意标准的部分。“允许巡查员自我增加与移除自动巡查权”，则是牵扯到自制力的部分，至于如果有人担心滥用自我授权自动巡查的问题，则以巡查员权限组将报告提到WP:RFDR即可（这部分可以在方针修订特别注明），再麻烦各位多加参予讨论了，谢谢。:)
Sanmosa我就不特别ping了。--~~Sid~~ 2025年5月16日 (五) 01:53 (UTC)[回复]
静等具体提案。--__Don't bite! 2025年5月16日 (五) 02:04 (UTC)[回复]
我觉得就算把自动巡查拆掉，巡查员依旧要拉高一些标准，毕竟没有帽子其实也能巡查条目（只是没办法用巡查员的那几个功能而已），并且要巡查条目也要基本理解怎么读条目，我不觉得要求应该比回退员低。--SunAfterRain 2025年5月16日 (五) 11:33 (UTC)[回复]
(－)倾向反对：提高硬门槛会让一定巡查经验者被迫再次检查被标记为已巡查之条目，虽必要时可IAR但可能引不必要之争议。如允许非巡查员使用隐藏已巡查的条目则对此(＝)中立。Python6345（查论编） 2025年5月16日 (五) 11:58 (UTC)[回复]
拔掉之后管理员授予巡查员时就不太需要考虑巡查豁免权的问题，尽管巡查员可以自我授权，但社群仍然可以监察，如果该巡查员让社群觉得他需要被巡查，那他就不该自我授权，如果自我授权就应该提报到WP:RFDR让社群讨论拔掉巡查员权限组的事情。额外一提但管理员与社群在考虑人选时就要特别评估该人过往的行为是否让人信任他自己的自制力，不过我觉得社群平时就会考虑这点，所以没什么好担心的。--~~Sid~~ 2025年5月17日 (六) 12:32 (UTC)[回复]
我依然认为由巡查员自行决定是否拥有巡免权是极其无理的，对单独取得巡免权者也非常不公。要拆就完全拆分，两权不再有任何相关。唯有一点我当时想了一阵也认为可以退让，即让巡查员可以巡查自己的条目，这样可以明确巡查动作与职权相符，避免某些因为他可以巡查其他条目所以他也一定可以保证自己条目质量的逻辑死亡。->>Vocal&Guitar->>留言 2025年5月18日 (日) 02:58 (UTC)[回复]
这也可行。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月18日 (日) 06:42 (UTC)[回复]
有条件支持：需可在Special:最近更改中排除巡查员之编辑。Python6345（查论编） 2025年5月18日 (日) 07:40 (UTC)[回复]
这个页里任何人的编辑都会列在其中，你是要排除什么？--。->>Vocal&Guitar->>留言 2025年5月19日 (一) 07:21 (UTC)[回复]
一般可使用未巡查变更排除巡免和巡查之编辑。如拆巡查之巡免权且不允许自我授权，则本人需有办法在最近更改中排除巡查员之编辑以避免重复检查可能不需要复核之编辑。( π )题外话本人对回退员之编辑无法单独排除亦不满，但技术上无法排除故未提案。Python6345（查论编） 2025年5月19日 (一) 07:47 (UTC)[回复]
我理解了，技术问题恕我我无能为力。--。->>Vocal&Guitar->>留言 2025年5月19日 (一) 23:46 (UTC)[回复]
要这么做当然可以，但我只能说你们看要不要也讨论一下顺便也把管理员的自动巡查一并拆掉，原因是对于巡查员有自动巡查，本就是基于巡查员理应能处理好自己创建条目的信任，现在这种信任要单独拉出来讨论当然可以，管理员也理应如此，因为不是所有管理员都会写条目，我过往也不是没看过管理员写的东西，需要做一步处理。至于无理的部分我只能说这是对现有巡查员极度的不信任，对单独取得巡查豁免权的人不公的部分，如果这样的话我认为社群早该把巡查员权限组的自动巡查拆掉，而不是拖到现在，所以这里我不是很明白不公在哪，巡查员相对于巡查豁免权本就是比较好申请的，这我不否认，然而在怎么样都不该说这是不公，如果不公的话那社群早该拆解巡查员权限组。:(
额外一提，要这样做的话请自己说服表示这会大幅度增加巡查员负担的意见。:)
有人说管理员拆掉自动巡查，那自动巡查要谁授予，那当然还是管理员可以自我授权，同样的管理员滥用自我授权，那这种就应视为滥用权限，该除权，不过我知道社群没那个时间与精力以这种理由除管理员权就是。:(--~~Sid~~ 2025年5月18日 (日) 13:53 (UTC)[回复]
有些常年提案在若干年后也会有通过的一天，我不认为社群过往的决定能说明什么问题，相反反映出社群对巡查问题、对条目质量问题一贯的漠视。
经常创建新条目的巡查员自然已经达到巡查豁免者门槛，那么他们当然可以直接申请巡免权，不存在大幅增加巡查员负担的问题。
另外关于管理员，Stang已经提过相同意见，我完全同意。--。->>Vocal&Guitar->>留言 2025年5月18日 (日) 23:30 (UTC)[回复]
即便如此我仍认为“单独取得巡查豁免权的人不公”这里不该说不公，这个说法相当的不好至少我来说。此外你的想法我没意见，然而基于过往的讨论，我看到大家最可以接受的方式，仍然是这个，这次的讨论以目前来看也没什么人反对这个变革方式，我还是建议你可以考虑接受这个变革，起码有在改变，而不是僵持不下导致原地踏步。我不是要改变你的想法什么的，你可以继续坚持您的想法，但起码让情况有所转变，如果未来社群或您发现很多巡查员滥用自我授权，您再将情况提出来要求移除也不迟不是么。:)
管理员权限拆解的部分，我认为可能要再等等，因为过往的讨论针对这部分没有很多，应该没办法一并处理，社群对此可能会有很多地方需要磨合，我建议先处理巡查员权限组的部分。:)--~~Sid~~ 2025年5月19日 (一) 01:09 (UTC)[回复]
句句没意见，句句在反对，大可以直接一点反对就行了，我的案也不缺你一票反对。这个案过不过对我一点影响都没有，甚至我也是巡查员我的权限还会变少，我倒是很希望反对我案的巡查员一起来对赌，只要我案通过，大家一起永久辞任巡查员，看看到底是谁舍不得这顶帽子。
上一句还在说管理员也理应如此，下一句就变成认为可能要再等等，变脸变这么快不怕自己信用破产吗？--。->>Vocal&Guitar->>留言 2025年5月19日 (一) 07:21 (UTC)[回复]
?--~~Sid~~ 2025年5月19日 (一) 08:24 (UTC)[回复]
我会说要再等等是因为这件事情不是我一个人说得算，社群过往也没有讨论，我没有任何基础推动。
我会说理应如此，这是基于我的观察而得出想法。
我建议你试着接受，是因为社群目前并整体上并不怎么接受你的意见。
我没意见也确实是真的，我不知道我话讲这么白，原因也说明白，还要被你冠上一句信用破产，你要跟别人对着干，对着骂我没意见，请不要坡及我。--~~Sid~~ 2025年5月19日 (一) 08:32 (UTC)[回复]
另外我也不知道你这是要赌什么，这有什么好赌的，不是很明白你的逻辑。--~~Sid~~ 2025年5月19日 (一) 08:36 (UTC)[回复]
我也再次澄清
Wikipedia:互助客栈/方针#c-ASid-20250519010900-Ohtashinichiro-20250518233000这里我有说到“基于过往的讨论，我看到大家最可以接受的方式，仍然是这个，这次的讨论以目前来看也没什么人反对这个变革方式，我还是建议你可以考虑接受这个变革，起码有在改变，而不是僵持不下导致原地踏步。我不是要改变你的想法什么的，你可以继续坚持您的想法，但起码让情况有所转变，如果未来社群或您发现很多巡查员滥用自我授权，您再将情况提出来要求移除也不迟不是么。”
我是要说服你暂时接受，让变革有所推动而不是在原地踏步，这是基于社群的讨论，而不是我的意见，你要坚持照着你的想法变革你可以说，用一副咄咄逼人的样子在对话，那你请自便。--~~Sid~~ 2025年5月19日 (一) 08:49 (UTC)[回复]
要这么做当然可以也是你说的，说服你暂时接受也是你说的，从我的角度我只看到你在变来变去，而没有对提案的实质意见。你如果真的没有意见，为什么反复搬出社群（还是两年前的），要建议我说服我接受呢？这一次的讨论里连你在内只有三个人回复了我，你为什么就判定现在的社群不接受我的意见呢？你有没有研究过我上一次为什么故意提一个很奇怪被社群全面反对的方案？？为什么你的案就是变革有所推动，那如果你来支持我的案不就是变革大大地推动吗？--。->>Vocal&Guitar->>留言 2025年5月19日 (一) 23:44 (UTC)[回复]
大致上支持“默认不巡查但可自行选择”的这个方向，有具体方针上的新增再看。--Aqurs 2025年5月19日 (一) 03:24 (UTC)[回复]

为管理人员申请制度检讨事

大家可以讨论一下之后有什么需要改动的？比方说临时管理员续任问题之类。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月8日 (四) 18:07 (UTC)[回复]

根据WP:讨论发起位置，这是不是应该在WT:管理员发起？思考... ——自由雨日🌧️❄️ 2025年5月8日 (四) 18:58 (UTC)[回复]
我想各类管理人员都算，另外标题虽说取了管理人员申请，实际上可能也不止（ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月9日 (五) 04:47 (UTC)[回复]
@自由雨日 @Ericliu1912 不是在Wikipedia talk:申请成为管理人员？Пусть от победы☆к победе ведёт! 2025年5月9日 (五) 12:13 (UTC)[回复]
(＋)支持临管可以续任，同一个得票率，普通用户可以当选临管，临管却落选并不合理。从确保参选人数以及促进站务角度来说，临管续任也未见有弊处。--AT⊿⁴⁶ 2025年5月9日 (五) 04:42 (UTC)[回复]
同我在这里的意见，临时管理员第二次选举若在65%—75%之间，仍应继续续任临管。 ——自由雨日🌧️❄️ 2025年5月9日 (五) 04:44 (UTC)[回复]
(▲)同上。若第二次投票仍然大于65%小于75%，可考虑续杯。--花开夜 留言 ·签名 ·贡献 2025年5月16日 (五) 02:47 (UTC)[回复]

提案修改

修订记录一：Ericliu1912于2025年5月10日 (六) 17:27 (UTC)将“一年”改为了“六个月”。 ——自由雨日🌧️❄️ 2025年5月15日 (四) 01:53 (UTC)[回复]
现行条文
投票结果

（...）而管理员申请支持率达65%、但不足75%者，亦得获授予为期六个月的“临时权限”。此种权限与一般不限期权限无异，但应于任期结束前重新申请成为管理员，且申请支持率达75%，才能保留并取得不限期权限；否则权限到期时将予取消，必须待下次再行申请。

提议条文
投票结果

（...）而管理员申请支持率达65%、但不足75%者，亦得获授予为期六个月的“临时权限”。此种权限与一般不限期权限无异，但应于任期结束前重新申请成为管理员，且申请支持率达75%，才能取得不限期权限，而若仍达到前述临时权限授予标准，亦可继续授权六个月；否则，权限到期后将予取消，必须待下次再行申请。

-某人✉ 2025年5月9日 (五) 05:53 (UTC)[回复]

把“否则权限到期时将予取消”一句挪到新增条文之后似乎比较合理。—AT⊿⁴⁶ 2025年5月9日 (五) 07:17 (UTC)[回复]
完成-某人✉ 2025年5月9日 (五) 07:21 (UTC)[回复]
如果第三次或之后还是65%以上，75%未满的话还是续一年吗？--Aqurs 2025年5月9日 (五) 08:41 (UTC)[回复]
我是这样想的--某人✉ 2025年5月9日 (五) 09:11 (UTC)[回复]
(＋)支持--Aqurs 2025年5月9日 (五) 10:55 (UTC)[回复]
那追加的句子后面要不要再补一句“每次选举后皆可借此续期”之类的让语意完整一点？不然个感有机会未来会因此描述模糊空间，会须再补述。另我也(＋)支持此提案。--WiTo🐤💬 2025年5月9日 (五) 14:45 (UTC)[回复]
无论多少次，只要支持率在中间，都一样是续期一年。Пусть от победы☆к победе ведёт! 2025年5月9日 (五) 12:36 (UTC)[回复]
(＋)支持。Sanmosa 新朝雅政 2025年5月9日 (五) 12:55 (UTC)[回复]
(＋)支持--August讨论‧签名‧回复请ping 2025年5月9日 (五) 13:17 (UTC)[回复]
我修订精简了行文（门槛标准不必重复），但语意不变。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月9日 (五) 14:49 (UTC)[回复]
(＋)支持，复活SCP2000！Пусть от победы☆к победе ведёт! 2025年5月9日 (五) 14:55 (UTC)[回复]
如果信任度支持度都没有提升，为什么第一次给半年第二次就给一年？。->>Vocal&Guitar->>留言 2025年5月10日 (六) 00:13 (UTC)[回复]
+1--在下荷花，请多指教（欢迎签到） 2025年5月10日 (六) 00:15 (UTC)[回复]
但半年就要人家参选一次，这样对候选人的精神不太好。Пусть от победы☆к победе ведёт! 2025年5月10日 (六) 03:46 (UTC)[回复]
同认为临时管理员如果续选临界的话，应该比照初选那样给半年。但临界意味着在试用期内仍无法达到社群足够的信任或者认可，可能就是力所不能，没必要持续临界就持续给半年或者一年那样的滚雪球，应该退下来再评估一下怎样让取得社群更多的信任（或者至少减少别人的反对票）。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月10日 (六) 03:58 (UTC)[回复]
确实半年为妙，如对选举感到压力则可以自行弃选。--AT⊿⁴⁶ 2025年5月10日 (六) 11:57 (UTC)[回复]
要么第一次就临时管理员直接给一年，不要第一次半年，第二次一年这样子。--Ghren🐦🕒 2025年5月10日 (六) 07:02 (UTC)[回复]
先改回六个月了（毕竟这是同样标准），若要延长第一次成功或是分开第二次以后成功，都可以商议。搞不好弄个交叉任期制，每半年选举一批一年期管理员，也不错吧？另参酌元维基标准，以本站这样的支持（信任）规模，临时管理权限一次授权一、两年都不是问题。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月10日 (六) 17:27 (UTC)[回复]
您维是“朝令夕改”的最佳典范。我原始推动临时管理员机制的时候本来就是这样的机制，这个机制在上一个选举期之前才被改掉，然后现在又改回来了？我固然是支持我自己的原始提案（或任何能表达同样意思的方案），甚至对于整个标准可以从半年调升至一年（我心脏强大没问题，但RFA还是不利身心健康XD），反正目标是解决管理员短缺问题，而不再是一般的信任问题。我不觉得几乎达到三分之二绝对多数有多么不被信任，是您维病了觉得80%、75%很正常而已。--路西法人 2025年5月12日 (一) 00:43 (UTC) 😄️1[回复]
(＋)支持临时管理员续任投票仍在65%至75%继续续任，对每次临时管理员授权多久我目前是没什么意见，半年、一年甚至两年都可以。--冥王欧西里斯（留言） 2025年5月12日 (一) 03:06 (UTC)[回复]
(－)反对，如果续任的话就相当于把要求降到65%了。--Martin 去我的签名簿签名！！ 2025年5月13日 (二) 19:18 (UTC)[回复]
续任又不是永久续任，也还是等于再次当选临时管理员而已，“相当于把要求降到65%”论据在逻辑上不成立。--路西法人 2025年5月15日 (四) 01:44 (UTC)[回复]
你说得没错，续任本身确实不是永久任命，理论上只是延续临时管理员的任期。但问题不在于制度的形式，而在于它的实际效果。
当一个人只需要维持65%的支持率就可以无限期连任“临时”管理员时，结果上就等于把“继续拥有管理权限”的门槛长期定在了65%。虽然名义上仍有“75%转正”的机制，但如果临时管理员可以反复续任而不担心被撤职，那就很少有动力去争取更高的支持率，也很难体现出社区对“完全信任”（75%）和“有限信任”（65%）之间的区别。
所以，“要求被降到 65%”这个说法，并不是在说制度文本上写成了 65%，而是指出在实际操作层面，这种安排等效于将门槛降低了。--Martin 去我的签名簿签名！！ 2025年5月15日 (四) 04:51 (UTC)[回复]
“很少有动力去争取更高的支持率”：所以你是不知道一次选举有多累多消耗精力吗。。 ——自由雨日🌧️❄️ 2025年5月15日 (四) 04:55 (UTC)[回复]
而且只要达不到75%，每次选举都有无法再续任的焦虑，因为谁都无法保证支持率不低于65%。将这种需要隔半年一年就提心吊胆地折腾一次的情况说成是“相当于把要求降低至65%”，实在令人匪夷所思。 ——自由雨日🌧️❄️ 2025年5月15日 (四) 05:08 (UTC)[回复]
你说得没错，65% 本身不是轻松就能拿到的，而且也没有人敢说一定能保住。但从制度设计的角度来看，只要一个人稳定在 65%～74.9% 区间内，他就可以无限续任。这意味着在实质效果上，管理员权限是可以被“长期保有”的，而不是一个真正过渡性质的“临时”安排。--Martin 去我的签名簿签名！！ 2025年5月15日 (四) 05:36 (UTC)[回复]
所以为什么管理员权限不可以“长期保有”？只能拿六个月管理权限又怎么不是“临时”安排？？一直没有取得永久管理员权限，只是延长了“过渡期”（每次延续半年），这又怎么不是过渡性质？？？ ——自由雨日🌧️❄️ 2025年5月15日 (四) 05:42 (UTC)[回复]
(▲)同上，无法理解怎么就“相当于把要求降到65%了”。 ——自由雨日🌧️❄️ 2025年5月15日 (四) 01:48 (UTC)[回复]
等我组织一下语句再回答上面两位的问题，先说说我的想法。那些第二次选举75%以下的失去管理员权利，在等6个月之后可以再次发起投票，若不到75%还是可以当临时管理员的。--Martin 去我的签名簿签名！！ 2025年5月15日 (四) 04:26 (UTC)[回复]
这不就是以前的制度吗？所以那请问中间6个月凭什么不能当临时管理员？也就是说假设某个人的社群支持率稳定在65%和75%之间（即相当于每次任期结束都需要复检），那么如果某次选举是偶数次选举，他接下来半年就不能作管理员；如果是奇数次，则接下来半年可以当管理员。这是什么诡异的规定？ ——自由雨日🌧️❄️ 2025年5月15日 (四) 04:39 (UTC)[回复]
那不就是把门槛定在65%了吗 囧rz……--Martin 去我的签名簿签名！！ 2025年5月15日 (四) 05:24 (UTC)[回复]
要是认为诡异的话也可以这样，支持率每次应该上升，直到75%，比如65，68，71，75。--Martin 去我的签名簿签名！！ 2025年5月15日 (四) 05:35 (UTC)[回复]
理由？ ——自由雨日🌧️❄️ 2025年5月15日 (四) 05:42 (UTC)[回复]
什么神逻辑。我无法理解为什么离任后六个月重新申请可重新适用65%标准的话，为什么申请翻新任期就不能以相同的标准？如自由雨日所说，中间6个月凭什么不能（以相同的当选标准）当临时管理员？什么叫“不就是把门槛定在65%”，65%是supermajority啊，正正就是维持65%到75%表示社群信任此用户担任管理员，但仍未确定此用户是否适合持续除权，仍需定期重新投票确认而已。65%既然能当临时管理员，那公平原则同样的标准也应该要可以续任临时管理员。“临时权限”（定期重选）跟“长期持有”（不断继续选上）根基上从来不冲突。--路西法人 2025年5月15日 (四) 06:38 (UTC)[回复]
先不说“相当于把要求降到65%”是错误理解的事情，我至今还是嫌门槛过高了，要我看要是真降了才是好事。Sanmosa 新朝雅政 2025年5月15日 (四) 13:46 (UTC)[回复]
考虑预留点空间给未来如果重新容许公开投票再调低，否则现在就降到太低，往后很难有个合理的差距来确保两个投票机制间的平衡。--路西法人 2025年5月16日 (五) 05:49 (UTC)[回复]
支持。也支持继续降低当选支持率要求。先前的调查中不少人有意向将70%作为门槛。可以将管理员降低到70%，临时管理员降低到60%。--Steven Sun（留言） 2025年5月16日 (五) 02:27 (UTC)[回复]
同意，既防止续任的管理员长期垄断在维基上， 同时鼓励新的维基管理员积极参选。--183.179.129.14（留言） 2025年5月17日 (六) 07:52 (UTC)[回复]

建议把Wikipedia:使用条款和Wikipedia:通用行为准则改为软重定向

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:使用条款、Wikipedia talk:通用行为准则。

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

在先前禁止歧视提案通过后，我还看到Wikipedia:使用条款和Wikipedia:通用行为准则这些比之前还离谱的页面。里面只有几句废话，之后就是两条链接了，竟然还能成为正式方针。我在此建议取消Wikipedia:使用条款和Wikipedia:通用行为准则的方针地位，并改为软重定向。Пусть от победы☆к победе ведёт! 2025年5月9日 (五) 12:28 (UTC)[回复]

副知之前参与讨论的用户@Sanmosa @August.C @S8321414 @1F616EMO Пусть от победы☆к победе ведёт! 2025年5月9日 (五) 12:30 (UTC)[回复]
(＋)支持。不过很有趣的一点是enwiki的本地使用条款页面虽然只是软重新导向，但还是保留了名义上的方针地位。Sanmosa 新朝雅政 2025年5月9日 (五) 12:54 (UTC)[回复]
我去英维问了（Пусть от победы☆к победе ведёт! 2025年5月9日 (五) 13:39 (UTC)[回复]
(＋)支持--August讨论‧签名‧回复请ping 2025年5月9日 (五) 13:16 (UTC)[回复]
(＋)支持。另若界面文字或其他模板有连结至这些页面，建议改为跨维基连结。--1F616EMO（喵留言～回复请ping） 2025年5月9日 (五) 14:02 (UTC)[回复]
(＋)支持。--Hamish T 2025年5月10日 (六) 10:15 (UTC)[回复]
(＋)支持：这些本来就是基金会方针，本站既无额外条款则应改为软重新导向。话说，如果真要在软重新导向标示全域方针的话，我是觉得可以做一个类似现在Wikipedia:通用行为准则页顶放的提示框，提醒读者这是基金会方针（不过这个没做也没什么差就是了，效力不会因此而有所不同）。--冥王欧西里斯（留言） 2025年5月11日 (日) 04:01 (UTC)[回复]
已经获得大量支持， 公示7日。Пусть от победы☆к победе ведёт! 2025年5月11日 (日) 05:22 (UTC)[回复]
公示通过。Пусть от победы☆к победе ведёт! 2025年5月18日 (日) 05:22 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

在人物传记条目合理使用人物配偶的图片

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:使用非自由内容。

各位可先参考维基百科:档案存废讨论/记录/2025/01/29，我多年前上载一幅何才夫人图片作合理使用，但近日被管理员Wcam滥权删除，理据如下：

  1. 提删投票中大多数意见和共识同意保留图片；
  2. Wcam对相关方针凭空解读，穿凿附会，无法提供合理解释和出处支持其说法；
  3. Wcam无视保留意见，亦无法解答对其提出的质疑，一味只靠“人数是否占多数不是判定结果的唯一标准”作尚方宝剑行掩耳盗铃之实，滥用管理员权力凌驾正当讨论；及
  4. Wcam作为提删者却拖延提删讨论和投票，导致投票不合理地长期积压。逃避多日后，Wcam突然在5月7日抛出一些似事而非的理据，并在另一管理员SCP-2000配合下，在约9小时后突然草草结束并绕过讨论和投票，自行决定删图，也不予足够时间让人回应。总言之就是一贯图片我先删，之后你自己慢慢看着办的态度和技俩。两人行政失当和缺乏操守的问题已在编辑历史中清楚记录。

返回何才夫人的图片，该图用于其丈夫何才的条目。何才条目对其妻子有完整的介绍，但篇幅又不适合为何才夫人开设单独条目，因此在其丈夫的条目使用图片符合合理使用原则，具体理据如下：

  1. 维基百科:使用非自由内容的第8项方针指出：“条目中的意义。只有当其呈现将有助于加深读者对条目主题的理解，而其缺失将妨碍理解时，非自由内容才能被使用。”就此，何才夫人作为何才的发妻，与何才本人高度相关，在何才条目内有有效的描述，因此在何才条目内使用何才夫人的相片绝对有助读者了解何才，缺失图片自然会妨碍对条目主题的了解。
  2. 参考英文维基，“条目主题”英文是“article topic”，不是“article title”（条目标题），何才夫人明显地与“何才”的“主题”密切相关。
  3. 英文维基建基于维基基金会决议和相关的全域方针，在Wikipedia:Non-free content制定了很清晰的指示，说明已逝世人物的图片可作合理使用，可作参考，原文如下：“Pictures of deceased persons, in articles about that person, provided that ever obtaining a free close substitute is not reasonably likely.”。请留意，当中的“articles”是众数而非单数，而且是广义的“articles about that person”，不是狭义的“articles of that person”。因此，用于辨认已逝世人物的合理使用图片，并没有规定只可用于该人物的条目，与“条目主题”互相呼应。
  4. 图片已上载逾15年，很难理解图片为何在方针政策无大变动的情况下突然被提删。

我认为有关的提删讨论和投票应予重启和继续进行，欢迎各位发表意见，谢谢。--Clithering（MMXXV） 2025年5月9日 (五) 16:45 (UTC)[回复]

回应如下：
  1. 我仅是将此图片提报至存废讨论并参与讨论，绝无行使任何管理权限。
  2. Wikipedia:档案存废讨论：有较多的(○)保留票不一定等于档案不会被删除。
  3. MOS:第一句：第一句应告诉非专业的读者条目的主题是什么或谁。这是经社群共识确立的正式指引，而何才条目第一句没有提及其他人物，故何才条目的主题不是其他人物。
  4. WP:NFCC#8：只有当其呈现将有助于加深读者对条目主题的理解，而其缺失将妨碍理解时，非自由内容才能被使用。此图片违反这一点。
  5. 此图片上传于2009年，根据基金会版权方针“决议”第5条，2007年3月23日之后上传的文件如不能符合非自由内容使用规定则必须删除。
  6. 综上，Clithering以上主张均与本地方针、指引和基金会方针相违背。
--Wcam（留言） 2025年5月9日 (五) 19:26 (UTC)[回复]
先说一句，这不是Wcam删的，是已离任的管理员SCP-2000删的。--在下荷花，请多指教（欢迎签到） 2025年5月10日 (六) 00:14 (UTC)[回复]
我一直以来都很怀疑Wcam过度诠释了NFCC。考虑到Wcam对IFD持续与庞大的影响力，就算具体执行删除操作的人不是Wcam，这很难说不是Wcam的意思。SCP-2000倒不是Wcam的传声筒，但Wcam对IFD持续与庞大的影响力本身就会影响处理IFD者的判断。Sanmosa 新朝雅政 2025年5月10日 (六) 12:41 (UTC)[回复]
我的绝大多数意见都有方针作为依据，并非我的影响力大，而是相当数量的维基用户对于著作权相关方针规定有准确的认识。--Wcam（留言） 2025年5月10日 (六) 17:25 (UTC)[回复]
你的影响力还不大吗，你都处理IFD很多年了，而且你还是IFD的主要处理者，哪有人敢没事跟你在IFD那边叫板啊。Sanmosa 新朝雅政 2025年5月12日 (一) 07:41 (UTC)[回复]
确实，鉴于这个原因，我甚至怀疑阁下（指Wcam，非Sanmosa）是否仍适合作为共享资源的管理员，已有数个使用者反馈滥用PCP成瘾。--Liuxinyu970226（留言） 2025年5月18日 (日) 01:00 (UTC)[回复]
Wcam对于“条目主题”的理解过于窄了。Wcam给我的感觉就是一个独立的小小作品的人物写二三十字，也可以用非自由图片；一节内容对于某人物谈三四百字，也不能使用非自由图片。这种硬生生解读“条目主题”不见得是法律上和基金会的原意。--Ghren🐦🕛 2025年5月10日 (六) 16:40 (UTC)[回复]
这并非我的理解，而是经社群共识确立的正式指引的规定。--Wcam（留言） 2025年5月10日 (六) 17:27 (UTC)[回复]
我是觉得应该整体看“有助于加深读者对条目主题的理解”，而不是单把“条目主题”这四个字揪出来。比如人物传记条目不能放有版权图片的花的照片，原因应该是“这张花的照片不能加深读者对传主的理解”，而“花不是条目主题”只能算二级结论/经验法则。--For Each element In group ... Next 2025年5月10日 (六) 18:13 (UTC)[回复]
补充：能说的地方在于是否（显著）有助于。比如是传主发现并首次研究了那种花，可以说“放这张花的照片，能帮助读者理解，传主他到底发现了怎样的花”，这确实有助于理解条目主题。如果这张图片是自由版权，那是可以放上去的，不算离题。但能帮助读者理解多少，有没有到显著（significantly）的程度，非自由版权图片还要看重这点。虽然这个“显著”想吵也有得吵就是了🤣--For Each element In group ... Next 2025年5月10日 (六) 18:31 (UTC)[回复]
我也觉得Wcam对于某些著作权原则诠释过于狭隘。虽然他自己总是说这样解读符合基金会有关精神（大意），但这类细节本应是社群可以讨论的议题，不是死板的禁脔。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月10日 (六) 17:24 (UTC)[回复]
对非自由内容相关规则做出较严格的解读，符合基金会著作权方针的规定。维基百科本就是“自由的百科全书”，对待著作权问题向来严格。--Wcam（留言） 2025年5月10日 (六) 17:28 (UTC)[回复]
但是按这里的说法，强调自由使命可能会伤害分享知识的愿景，所以应该在中间取得平衡。一些人认为较严格会被另一些人认为过度严格？--For Each element In group ... Next 2025年5月10日 (六) 17:38 (UTC)[回复]
你这句话正好就是我上面说的意思（ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月11日 (日) 16:10 (UTC)[回复]
我认为还是应将该人物单独写成条目。不愿意写短条目是个人偏好，但既然有专门介绍该人物的来源，那么这张图片是可以有条件恢复的。而条目主题到底能指多大范围是一个字眼问题，如何理解终究是众人标准不一、不断互煮。说不定方针当初这么写就没考虑这些，大家不如讨论一下自己眼中的条目主题到底是怎样的范围，把这个先明确出来。——暁月凛奈 (留言) 2025年5月10日 (六) 21:15 (UTC)[回复]
我会觉得强行分出来一条独立条目的处理过于死板，而且你们也没能说明到底不分立的所增加的版权风险在哪里。我会认为“主题”指的是关注度中“值得收录的主题”，能达到关注度标准的，可以算是一个“主题”。但是这个“主题”是要独立成条，还是并在其他条目里，编者可以有自己的考虑（假定：意味着可靠来源的有效介绍只假定而不保证某主题可在维基百科拥有独立条目。即使某个主题符合上述标准，编者们也有可能达成共识，认为不应该为其另立一篇条目。）。何才夫人（黛玛·哈金斯）本身已经一个有关注度的主题，只是编者认为放在何才条目记述更为方便，读者观感更佳而已。--Ghren🐦🕛 2025年5月11日 (日) 04:51 (UTC)[回复]
谢谢您的意见，题外话，我觉得Wcam由提删讨论中期开始改用“黛玛·哈金斯”称呼何才夫人有点带风向的企图，似乎想借此拉开何才夫妇的关系。但我想指出，哈金斯是何才夫人的娘家姓氏，人家25岁已嫁给何才，一早按西方传统改跟夫姓成为何才夫人，仍然以对方娘家姓氏作为称呼，除非是该人本来的选择，否则可视作语带有不敬之意的。--Clithering（MMXXV） 2025年5月14日 (三) 15:53 (UTC)[回复]
谢谢以上各位发表的意见，抱歉这几天要先处理条目写作和修缮，加上公私事忙，未能及早回应。我对于Wcam的留言有以下几点回复：
  1. 请Wcam不要再拿什么“有较多的保留票不一定等于档案不会被删除”拿来作挡箭牌，这已近乎是对所有参与讨论者的侮辱！现在不是维基新手在空谈阔论（对不起，我无意冒犯任何新手），有关的提删讨论涉及好几位一直有关注相关议题的维基编辑（包括好几位资深的维基编辑），Wcam是否认为其他维基编辑提供的深入意见是废话？抑或是Wcam当这些意见透明？Wcam是否觉得其他维基编辑过度清闲？Wcam是否理解其他维基编辑花了多少时间与他认真地就议题进行讨论？Wcam的意见的含金量是否较多，怎由得他一再拖延讨论、再而（配合SCP-2000）如此目中无人地草草结束讨论？他们凭什么有如斯漠视多位资深编辑的作为，一手包办提名和执行自己参与其中而且有身份冲突的裁决？说到这里，我的确感到愤怒。即使是上面新发起的讨论，也再次看到Wcam的个人见解受到质疑，我强烈认为有关的提删讨论必须予以重启以示公允。
  2. Wcam口口声声说他跟方针办事，但他没有，这在提删讨论和上面已清楚指出，再归纳如下：
  • Wcam说“MOS:第一句：第一句应告诉非专业的读者条目的主题是什么或谁”，用这句话来作为图片不可合理使用的理据是无关宏旨。MOS有关第一句的方针当然只是用来规范引文第一句如何扼要地描述条目主题，仅此而已，当中没有延伸规范条目图片的使用。Wcam的延伸解读是原创研究。此外：
  • Wcam引用“WP:NFCC#8：只有当其呈现将有助于加深读者对条目主题的理解，而其缺失将妨碍理解时，非自由内容才能被使用”。这句话的重点除了“条目主题”，还有对“条目主题”的“理解”。参考英文维基，“条目主题”英文是“article topic”，不是“article title”（条目标题），何才夫人作为何才的妻子，在条目内具有有效的叙述和篇幅，在何才条目加入何才夫人的妻子的图片，无论程度有多深或浅（亦可能因人而异），的确“有助于加深读者对条目主题的理解，而其缺失将妨碍理解”。在提删讨论中，我也已回应Wcam，何才夫人不是张三李四，而是何才的发妻，并比喻说如果透过认识Wcam的妻子不能加深对Wcam的妻子，而不认识Wcam的妻子不会妨碍对Wcam的认识，那相信Wcam的妻子（甚至是Wcam本人）都会很伤心。
  • Wcam表示“根据基金会版权方针“决议”第5条，2007年3月23日之后上传的文件如不能符合非自由内容使用规定则必须删除”。不过，基卡上述原因，有关图片根本没有违反。此外，英文维基建基于上述的基金会决议和相关的全域方针，在Wikipedia:Non-free content制定了很清晰的指示，并说明已逝世人物的图片可作合理使用，原文如下：“Pictures of deceased persons, in articles about that person, provided that ever obtaining a free close substitute is not reasonably likely.”。请留意，当中的“articles”是众数而非单数，因此，用于辨认已逝世人物的合理使用图片，并没有规定只可用于该人物的条目。再者，这里用的是“about”，不是“of”。如果方针是写“in articles of that person”（该人物的条目），我可以理解适用范围会收窄很多，例如“刘德华的条目”包括“刘德华”和“刘德华影视作品列表”等。但是，方针写的是“in articles about that person”（与该人物相关的条目），很简单的英语常识就是指该人物和与该人物有关的事物。例如英文“Talk about yourself”(请介绍一下您自己)，很标准的答案您会介绍您自己的名称、身份、兴趣，然后也会介绍一下您的家人，例如妻子。网上随手找一个网站作例子（例如英伦银行），网页“About”选单下并不只介绍银行的历史，而是还有银行的董事会、银行高管人员、银行与社区的关系等，题材是很广泛的。同理，在何才条目介绍何才夫人的相关章节中使用何才夫人的图片，完全符合“in articles about that person”（与该人物相关的条目）的要求。
我同意上面其他维基编辑的意见，由于合理使用图片的规定具复杂性，因此很难用一把尺硬套到所有个案，反而要逐案处理，亦正因如此解释了因何维基百科有提删的投票和讨论专页，不是Wcam一言堂。如果Wcam有这么厉害，那倒不如关掉互助客栈？这里和上面所有讨论由他说了算好不好？谢谢。--Clithering（MMXXV） 2025年5月14日 (三) 15:43 (UTC)[回复]
@Liuxinyu970226：87335408抱歉，方针WP:讨论发起位置有言：讨论结束后亦应让讨论原地存档，避免重复在多个页面存档后出现讨论分支。因而我移除了您加的存档。若需留存记录的话，可以在这些讨论页发送{{讨论通告}}。 ——自由雨日🌧️❄️ 2025年5月18日 (日) 02:32 (UTC)[回复]

希望在改进“MOS:ACG”后将它提升为指引

如题。目前，每个ACG页面都很“与众不同”，有从日维翻过来的、有从英维翻过来的，导致格式、模板、名字各有不同。而因为MOS:ACG没有正式规范，从而延伸了一些问题：

  1. 问题一、“監督”这个字应该是日文汉字，意思大致为“导演”或“指导”。但是在ACG页面却被大量使用。不如说，有很多ACG页面都很喜欢直接使用日文汉字，而且不太有人去改。
  2. 问题二、“Episode”的名字在ACG页面分别有使用“话”（又是日文汉字…）和“集”，而“Episode list”，有各话列表、各集列表、话数列表、集数列表、剧集列表等不同名字。而其中呢，表格的格式各不同、而也会用不同模版来做表格，例如使用{{Episode table}}和{{Episode list}}（英维）、{{剧集列表/base}}（日维），有些页面也会直接建立表格。导致每一个页面完全不同。

除了希望在MOS:ACG修复以上问题外，MOS:ACG所写的内容也需要进行修改，例如把“不建议建立的章节”直接用大概一段左右的内容带过，其他不重要内容直接删去。暂时就是这样，以上。

( π )题外话：如果以上内容有一些你看不懂的地方，真的十分抱歉，因为我真的不太会解释QAQ（对了，我摆错位置的话，提醒我一下，谢谢。
--HelloYu0910（留言） 2025年5月13日 (二) 15:09 (UTC) 👍2[回复]

好吧，看起来我解释得不太清楚…总而言之呢，先谈谈“Episode”的名字吧。虽然目前大多数的ACG页面都是使用“话”字，但我认为使用“集”字较好，因为始终“话”字是日文汉字，而“集”才是中文。--HelloYu0910（留言） 2025年5月14日 (三) 04:44 (UTC)[回复]
中文维基百科用中文的用语，我感觉不需要讨论🤣。《现代汉语词典》的话根本没有收录“集”的意思，而且显然“话”是直译直接使用的日文汉字。可以收录一点常见的日文汉字被使用的例子（还有一例是“羁绊”），在MOS:ACG提及一下就好了。--深鸣（留言） 2025年5月14日 (三) 06:44 (UTC)[回复]
也对www，那“监督”这个字呢? 例如“作画监督”，该翻译成“导演”还是“指导”呢?--HelloYu0910（留言） 2025年5月14日 (三) 07:01 (UTC)[回复]
我对动画制作的过程不熟悉。就“作画监督”来说的话，好像是修正其他人的作画的（[2]）？个人感觉“监督”可能也未尝不可，一是这本来能够作为名词，表示做监督工作的人；二是一些期刊和论文也这么用[1][2]。但是中文有不代表这么用合适（个人感觉反例是把《孤独摇滚！》的“結束バンド”直译直接使用汉字，变成“结束乐队”，汉语也用“结束”，但意思大不相同），如果不是做汉语里监督工作的话，建议还是别用这个词吧。指导像是动词一般，或许不太合适？“作画导演”被一些媒体采用[3][4]，感觉可能更合适。然后我感觉这个标题有点大了，或许可以拆成几部分分别讨论？另附知@SuperGrey、Nostalgiacn、Summerize、Aqurs1。--深鸣（留言） 2025年5月14日 (三) 07:33 (UTC)[回复]
那标题要改成什么比较好? 🤔--HelloYu0910（留言） 2025年5月14日 (三) 07:40 (UTC)[回复]
您指的是“作画监督”吗？我感觉“作画监督”和“作画导演”都行，但是我确实不熟悉动画的制作过程。然后单独某个用词和MOS:ACG的关联似乎不大🤣。--深鸣（留言） 2025年5月14日 (三) 07:43 (UTC)[回复]
也对，那不如说一下“Episode list”的译名、模板和格式? 这些应该和MOS:ACG的关联性较大?--HelloYu0910（留言） 2025年5月14日 (三) 07:57 (UTC)[回复]
对我来说，不用“话数列表”就行。写法规范先前有过讨论（Wikipedia talk:格式手册/电视/存档二 § 剧集列表类条目的写法规范）。上面列出的两套列表，感觉差异也不大？--深鸣（留言） 2025年5月14日 (三) 08:06 (UTC)[回复]
好像的确如此，那参考之前的讨论以及使用{{剧集列表/base}}作之后剧集列表的表格? 🤔--HelloYu0910（留言） 2025年5月14日 (三) 11:49 (UTC)[回复]
这两个模板感觉重复度很高，且{{剧集列表/base}}为中维和日维独有？我倒是建议合并到前者🤣。纯列表的那种我个人是不喜欢的，感觉列出了对普通读者没什么作用的详细的制作人员名单，却连剧情都不写。--深鸣（留言） 2025年5月14日 (三) 14:12 (UTC)[回复]
{{剧集列表/base}}的话是日维那边翻译过来的，也支援写剧情简介，基本上写剧情的话可以用，不影响。--HelloYu0910（留言） 2025年5月14日 (三) 14:16 (UTC)[回复]
我的意思是两套模板好像高度雷同。我觉得要么合并，要么就允许两种模板同时使用，没有必要仅指定其中的一种（即要么把两个模板合并，要么允许{{Episode table}}和{{剧集列表}}同时使用）🤣。--深鸣（留言） 2025年5月14日 (三) 14:20 (UTC) 👍1[回复]
哦，我懂意思了w
那么就两种模板可以同时使用吧，不过一个页面中不要两个同时出现比较好?--HelloYu0910（留言） 2025年5月14日 (三) 14:23 (UTC)[回复]
是的。不过这俩模板看似也没法混用？--深鸣（留言） 2025年5月14日 (三) 14:24 (UTC)[回复]
我指的是同一个页面两个模板都在使用w--HelloYu0910（留言） 2025年5月14日 (三) 14:26 (UTC)[回复]
那感觉一篇条目里统一比较好，毕竟样式上还是有细微差别的。--深鸣（留言） 2025年5月14日 (三) 14:38 (UTC)[回复]
对，我就是想说这个www--HelloYu0910（留言） 2025年5月14日 (三) 14:39 (UTC) 😄1[回复]
因为涉及到专题内大量条目，兹事体大，且日文各职称与中文尚无一锤定音的对应关系，故待讨论确定中文对应词汇后，建议采用公用字词转换的方式来实现，即添加到Module:CGroup/Anime中。例如：
Item('監督', 'zh-hant:監督; zh-hans:监督; zh-tw:導演; zh-hk:導演; zh-cn:导演; zh-sg:导演;'),
Item('美術監督', 'zh-hant:美術監督; zh-hans:美术监督; zh-tw:美術指導; zh-hk:美術指導; zh-cn:美术指导; zh-sg:美术指导; 美術導演=>zh-tw:美術指導; 美術導演=>zh-hk:美術指導; 美術導演=>zh-cn:美术指导; 美術導演=>zh-sg:美术指导; 美术导演=>zh-tw:美術指導; 美术导演=>zh-hk:美術指導; 美术导演=>zh-cn:美术指导; 美术导演=>zh-sg:美术指导;'),
这样就可以在不改变原文的情况下，对专题内条目进行转换，且为将来共识变化或译名变化提供操作空间。--SuperGrey (留言) 2025年5月14日 (三) 12:54 (UTC)[回复]
可以，不过“美術監督”、“攝影監督”，以及“音響監督”好像要改成“美术指导”、“摄影指导”，以及“音效指导”吗? 还是这些也用“导演”?--HelloYu0910（留言） 2025年5月14日 (三) 13:48 (UTC)[回复]
可以也加入字词转换，并不冲突。--SuperGrey (留言) 2025年5月14日 (三) 13:50 (UTC)[回复]
我知道，我指的是这三个是对应“指导”的吧，因为我怕我弄错。--HelloYu0910（留言） 2025年5月14日 (三) 13:57 (UTC)[回复]
我刚刚发现日文维基百科区分ja:美术监督（ja:アートディレクターArt Director）和ja:プロダクションデザイナーProduction Designer（对应中文美术指导）。--SuperGrey (留言) 2025年5月14日 (三) 14:07 (UTC)[回复]
这种区分是对的吗？感觉不太好下判断。附知@For Each element In group ... Next、BrianBYBYBY、自由雨日。--SuperGrey (留言) 2025年5月14日 (三) 14:10 (UTC)[回复]
陆术语在线中，“art director”在编辑与出版学中译“艺术指导”、新闻学与传播学中译“美术总监”，“production designer”无结果，“美术指导”无结果。《中国大百科全书》中“美术指导”却对应“art director”。CNKI中搜索“art director”多得“艺术指导”其次是“艺术总监”，搜索“production designer”得“美术指导”。
《香港电影美术及服装专业文化发展概览》一文称，香港电影工业的『部门架构通常为一名 Production Designer 之下再设立 Art Director 及 Costume Designer，由 Production Designer 负责涵盖美术及服装造型的电影视觉总体呈现，是美术部门最高职位的负责人。但在对 Production Designer 的中文职位名称翻译上却出现了混乱，直至今日仍未达成统一，其中文译名包括“美术总监”、“美术顾问”、“艺术指导”、“美术统筹”等等。』
另外找到这篇文章，不过看起来并非可靠来源……
总之，似乎是个比较混乱的两个概念……肯定在一些情境（部分地区/部分工业体系）下有区分，但另一些情境下可能区别比较模糊？ ——自由雨日🌧️❄️ 2025年5月14日 (三) 21:02 (UTC)[回复]
这下不太好办。日文“美术监督”译为哪个更好呢？还是说，只能搁置争议，不译了？--SuperGrey (留言) 2025年5月14日 (三) 22:31 (UTC)[回复]
大陆的话，应该“艺术指导”比较好？（按术语在线和CNKI结果。）不译应该不太行，毕竟日语“監督”意思和中文“监督”差得有点大。 ——自由雨日🌧️❄️ 2025年5月14日 (三) 22:35 (UTC)[回复]
当然，更好的做法是每篇来源单独辨析选择用词。 ——自由雨日🌧️❄️ 2025年5月15日 (四) 03:22 (UTC)[回复]
同意，这确实是比较好的做法。--HelloYu0910（留言） 2025年5月15日 (四) 17:21 (UTC)[回复]
台湾的国家电影及视听文化中心写的“Art Director”是指“美术指导”，而关键评论网则写“Art Director”等于“艺术总监”...--HelloYu0910（留言） 2025年5月15日 (四) 03:20 (UTC)[回复]
各地的制片系统不同、分工不同，衍生出来的职位也不同[5]，直接强行套用中文地区惯用职称是不理想的。“某某监督”的职称，也已被部分中文地区片商采用。个人认同Ghren君下方主张，但若必须要译，则采用“某某指导”。--冰融s 🧊 2025年5月16日 (五) 09:29 (UTC)[回复]
我的想法是：
  • “演出”⮕ 直接使用“演出”
  • “监督”⮕“导演”
  • “美术监督”⮕“美术指导”
  • “摄影监督”⮕“摄影指导”
  • “音响监督”⮕“音效指导”
其他的...应该暂时没有了吧?--HelloYu0910（留言） 2025年5月16日 (五) 09:46 (UTC)[回复]
还有“作画監督”、“特撮監督”或“特技監督”等。随着3D技术普及，部分动画也有“3D監督”。更离谱一点的，我还见过“演出监督”一职称。另不理解为何“演出”保留为“演出”，“监督”则翻译为“导演”。--冰融s 🧊 2025年5月16日 (五) 10:33 (UTC)[回复]
因为我不太确定演出能够翻译成什么，还是说您有什么提案?--HelloYu0910（留言） 2025年5月16日 (五) 10:40 (UTC)[回复]
参考测试用例：Special:Permalink/87290783。--SuperGrey (留言) 2025年5月14日 (三) 14:01 (UTC) 👍1[回复]
字词转换是用来修正错译的吗？如果是真的错了，用bot修正比较好吧。“Item('监督', zh-hant:监督; zh-hans:监督;… ”这样的写法也很怪，上边你们都主张“监督”是日文了，那自然不是繁体，也不是简体了。我是主张有时候搬过来也不是有错的，“演出”也是导演，“监督”也是导演，非得要保留原语言那个文化意思，其实最方便就是照搬。形译也是翻译。尤其是“监督”这类词在ACG方便我看已经是流毒甚久了。--Ghren🐦🕛 2025年5月15日 (四) 16:55 (UTC)[回复]
鲁迅有言：“其实地上本没有路，走的人多了，也便成了路。”如果有一些可靠来源以“监督”称此职业，那么即使再“错译”，也已经将错就错进入了大众视野。故使用字词转换来修正这些译名也未尝不可，既尊重可靠来源、也尊重符合中文语义的“正译”。--SuperGrey (留言) 2025年5月18日 (日) 09:53 (UTC)[回复]
MOS:ACG看过去讨论，其实从建立之初就不被认可，一直被批评是个别编辑的规范。之后都是小修小补。
MOS:ACG目前不具备成为格式手册的先决条件，上面提及的统一用词只是一个小问题。如果某些用词达成共识，建议归档维基百科:条目命名一致性决议。
  1. 内容太旧，相关内容并无达成共识，跟不上一些新的规范和用语，例如还在用“关注度”这些陈旧的说法。不说WP:原创译名了，主题曲和插曲的建议格式，技术上与其他格式手册是冲突的（WP:CHEATS），被认为是违反WP:NOTDATABASE
  2. 内容太杂乱。“作品条目布局”更像在说如何写一个“系列条目”，具体特定作品类型（Wikipedia:格式手册/日本动漫游戏#跨媒体）除了动画和音乐，其余只有寥寥几句。动画、漫画、游戏、小说每个单拿出来都能建一个格式手册分页。目前只有游戏格式手册，缺失动画/电视剧格式手册、音乐格式手册、漫画格式手册、小说格式手册、动画/电影格式手册。
个人建议脚踏实地，先将动画/电视剧格式手册、音乐格式手册、漫画格式手册、小说格式手册、动画/电影格式手册逐一建立好，完善成格式手册标准，再更新MOS:ACG的内容。
--Nostalgiacn（留言） 2025年5月16日 (五) 08:26 (UTC)[回复]
这里指的“动画/电视剧”以及“动画/电影”是指电视动画和电影动画吗?--HelloYu0910（留言） 2025年5月16日 (五) 09:48 (UTC)[回复]
是的，两种格式是完全不同的写法，又会与同类型的专题格式手册重合。--Nostalgiacn（留言） 2025年5月16日 (五) 10:03 (UTC)[回复]
“系列条目”化是因为相当一部分条目是同时记录对应多个媒介版本，每个媒介只有一个（例如漫画、小说的出版物）或一组（例如动画）章节而甚少单独拆分一个条目。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月19日 (一) 09:50 (UTC)[回复]
建议先看能不能把动画术语列表写好，为每个用语加入中文可靠来源。“监督”的问题我都觉得算小的，比如“优”在现代汉语已经几乎不作演员之义，“声优”却照样在今汉语世界通行。如果要把“监督”改为“导演”，“声优”也应该改为“日本配音员”。其实我还有个疑惑，“配音”相比en:Dubbing（日语作ja:吹き替え）更像是en:Voice acting吧？--PexEric 2025年5月17日 (六) 07:27 (UTC)[回复]
声优的话直接“配音员”可以了，不需要特别的加“日本”吧?--HelloYu0910（留言） 2025年5月17日 (六) 07:39 (UTC)[回复]
既然条目中的声优可以直接写作配音员，那么“声优”的主条目似乎也可考虑改名成“日本配音员”。观察英维的en:Voice acting in Japan，则是有“Voice acting in XX”的命名一致性。--PexEric 2025年5月17日 (六) 07:58 (UTC)[回复]
可以，我觉得没有问题。--HelloYu0910（留言） 2025年5月17日 (六) 13:08 (UTC)[回复]
那…有人对于把“声优”改成“（日本）配音员”有意见吗?--HelloYu0910（留言） 2025年5月19日 (一) 02:52 (UTC)[回复]
本讨论是关于MOS:ACG，“配音员”的讨论最多涉及条目中统一用语，如Wikipedia:格式手册/日本动漫游戏#登场人物的“关于配音”一节。
条目改名，需要在条目置顶加入{{Requested move}}，并在条目发起移动请求讨论，给出改名理由。这里讨论离相关主题太遥远，缺乏广泛讨论。--Nostalgiacn（留言） 2025年5月19日 (一) 05:21 (UTC)[回复]
配音员之前讨论是统一使用“配音员”作为消歧义词，其他说法可以作重定向（维基百科:条目命名一致性决议）。--Nostalgiacn（留言） 2025年5月17日 (六) 07:42 (UTC)[回复]
“声优”一定程度在中文语境已经特化为指“日本的配音员”，这没必要再在地化的适配。至于其中日汉形式的动画职位名称，是否已经存在借入汉化的情况（也就是写作“监督”，但理解为“导演”），可以参考动画术语列表的描述？另外关于格式指引这部分，其实就是存在一种偏近于日语区的编写风格（例如日式动画类的职务、作品内曲目点列表、每集列表的纯wikicode表格等）还是偏向英语区的编写风格（对应的，职务信息略微简化、和作品内曲目一起文段化，每集列表使用规范的的模板组合等，会稍微多些关注现实评价与介绍并脚注来源）的不同取向，当新条目创建（例如每季度的动画对应作品创建）时会倾向日语区化，但如果进行进一步评级的话会稍微向英语区的风格偏移。同时也要考虑众多已有条目的风格可能更偏日语区化，如果尝试规范为英语区化，会不会变成一些以新法治旧例的情况。所以这个格式规范可能需要考虑已有条目的情况来对应，但在兼顾一些信息性的情况，鼓励进一步向行文质量更好的英语区的风格进行条目修葺（尤其如果考虑条目评级的情况）。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月19日 (一) 09:47 (UTC)[回复]
“新法治旧例”，只要新法不是叫人“小作品化”那种程度，也不会有什么问题。哪怕是琐碎资料，我也认为列总也比不列强。--PexEric 2025年5月19日 (一) 16:38 (UTC)[回复]
  • 行话问题。行文中当然要着力避免，除非避无可避。“声优”（既然是我提的）当然我是认为和现在所谓的“吧唧”“谷子”等词没有本质区别，只是华语圈引入的早而流传广而已。词典查不到其是配音演员的意思，意即这个词根本不是现代汉语常用词，但好在汉语有“配音员”可用。“话”，同，应作“集”。而“特撮监督”“特技监督”“演出监督”等，问题则应该是中文可能都没有完全对等的概念，不同来源叫法不一，本地统一用词恐怕也不太合适。这种情况，需要思考的是：用日文汉字词是否也不失一种为读者方便的考量？而行话避无可避的情况要是想解决其实也不难：比如如果“制作”章节涉及大量职位分工信息，可以在章节顶部加入导向动画术语列表的hatnote（当然前提也是该列表品质较好）。这种做法常见在生物学领域，如{{Entomology glossary hatnote}}。
  • 对于本案。要做指引，MOS:ACG应该是要完全重写。基本认同Nostalgiacn的意见，最好一步步来。另外有编者提到的，英维日维写法风格不一的问题，现行本地的评级体系已经能很好解释。日维好列琐碎资料，流毒中维已久了，相关做法更不应出现在MOS:ACG。
总之，您提的问题倒是小的；MOS:ACG要做指引还有很长的路。--PexEric 2025年5月19日 (一) 16:34 (UTC)[回复]
这样避重就轻的说法那才是问题。现时ACG类条目的编写风格的两端化，如何在避免影响大幅度过往条目的情况，容许这类在通用评级上存在问题的新条目存在但鼓励逐步过渡至能满足于条目评价的发展后的条目，我认为规范应该往这个方向考虑，所以规范对于编写风格上可能存在两种级别，一种是初始性的类似日语区风格，例如动画类的职务列项、作品引用曲目列项、每集列表、播放平台信息等，这类别的目标是便于条目内容的初始化建立；另一种类似于英语区并且满足更高级别的评级，包括文段化、并且抽简部分信息等。这两个问题其中一个目标是对条目格式的规范化（现在MOS:ACG列出的格式一定程度上也有对过往编写风格的规范）。另外，ACG涵盖的条目范围不少，从涉及真人的声优、工作人员，到各类作品条目，而且这些条目也存在系列化和单独媒介化的差异，这些如果需要的话，可能还需要针对地规范。关于“声优”，可能类似于“官方名称”与“常用名称”的情况，和涉及日语翻译一直沿袭的“日汉”直接借入的情况，官方语言机构没有认可“声优”的中文指定意，但日常使用上已经认可了其作为“日本的配音员”的中文指定意，并且在一些学术文献中有所应用，所以执著于“声优”的“本地化”是否有点庸人自忧。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月20日 (二) 01:18 (UTC)[回复]

参考资料

  1. ^ 刘桂华. 日本动画人生存现状调查 (硕士论文). 吉林艺术学院. 2008. CNKI 2008019356.nh需注册账号查阅 （中文（中国大陆））. 
  2. ^ 李若源. 真实的表现力——近藤喜文的作画魅力. 当代动画. 2018, (2): 122–128. CNKI DDDH201802024需注册账号查阅 （中文（中国大陆））. 
  3. ^ 刘颖颖; 丁涛. 导演新海诚：《天气之子》让人“又笑又哭”. 人民网. 2019-10-29 [2025-05-14] （中文（中国大陆））. 
  4. ^ 盛倩倩. 《你的名字》爆红，但新晋“百亿导演”新海诚真不是宫崎骏第二. 第一财经. 2016-10-31 [2025-05-14] （中文（中国大陆））. 
  5. ^ 张楠. 观众业内都困惑？动画的“演出”到底是谁？. 动画学术趴. 2022-09-22 [2025-05-16] –通过微信公众平台 （中文（中国大陆））. 

按照MOS:IWL共识，“不应在条目中以跨语言链接“[[:語言代碼:條目名稱|顯示內容]]”（如[[:en:Article Name|條目名稱]]）等方式，直接将内容链接至其他语言维基百科”。现存{{Interlanguage link multi}}模板便是采用这种格式，明显与共识相悖，应禁止使用，同时将存量引用改成{{tsl}}模板。--1.162.129.9（留言） 2025年5月15日 (四) 04:18 (UTC)[回复]

我之前在条目编辑时加上“[[:en:Article Name|條目名稱]]”，结果被过滤器拦截。--Sinsyuan✍️ 2025年5月16日 (五) 12:50 (UTC)[回复]
最近已设立相关过滤器拦截该类编辑，自然会被拦截（或被标记）。建议红链或使用{{Internal link helper}}。--WiTo🐤💬 2025年5月18日 (日) 03:54 (UTC)[回复]
已提出申请，见Special:Diff/87358633。--Jeffchu2014（留言） 2025年5月19日 (一) 18:30 (UTC)[回复]
(－)反对禁用理据，{{Interlanguage link multi}}不属于MOS:IWL禁止的格式。--Kcx36（留言） 2025年5月19日 (一) 19:15 (UTC)[回复]

移动不留重定向

是否应该对有内部链接的条目限制不得“移动不留重定向”，或者是限制有相关权限者“移动不留重定向”的频率。--Kethyga（留言） 2025年5月16日 (五) 12:09 (UTC)[回复]

WP:R#SUPPRESS提到一般情况下除非有充分理由移动时不留重定向，最好将其留下。不当使用“移动而不留重定向”当以除权处理。相关方针已经有限制了，感觉是缺了一个申诉通道？--Nostalgiacn（留言） 2025年5月16日 (五) 14:09 (UTC)[回复]
@Nostalgiacn：事见此处。另查近期移动日志，几乎所有均不留重新导向，其中亦有大量不妥操作（如未查证原标题非原创名称即擅予移动），而若干情况更是令人匪夷所思（疑似是为了修订自己沙盒草稿的连结），其他维基人有时亦须协助纠正，而前述多数操作即使先不论本身正确与否，仍根本没有必要不留重新导向移动，结果不过是雪上加霜；当事人并非初犯，理应考虑除权，甚至编辑禁制。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月16日 (五) 14:21 (UTC)[回复]
难不成又要搞个用户警告（WP:UTM），继续就除权？希望不会引起不快。--Nostalgiacn（留言） 2025年5月16日 (五) 14:37 (UTC)[回复]
又看到了几个案例，这已经不是单纯不慎的问题，甚至涉及可供查证原则；当事人并非偶尔使用权限，这实在过于躁进。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月16日 (五) 14:40 (UTC)[回复]
回复时，没看到新留言。是再犯，就按既定程序处理吧。--Nostalgiacn（留言） 2025年5月16日 (五) 14:44 (UTC)[回复]
@Ericliu1912：讨论似乎未通知当事人？这不太好吧。@Sanmosa： ——自由雨日🌧️❄️ 2025年5月18日 (日) 03:27 (UTC)[回复]
@Ericliu1912：此前把桂园时代重新导向至西园寺公望显然不妥，桂园时代里桂太郎在任内阁总理大臣的时间较长。中文维基百科有类似问题的再重新导向非常多，这点在以前一般是以R7处理的，然而部分管理员似乎不接受以R7处理外文维基百科有条目的重新导向删除请求。Sanmosa 新朝雅政 2025年5月18日 (日) 03:45 (UTC)[回复]
一、且不论西园寺公望条目里面确有相关内容，你这里也不是重新导向到桂太郎，重新导向到当时压根儿没内容的西园寺家作什么呢？这才是“显然不妥”。二、其他很多案例还是莫名其妙啊。三、无论如何，判断重新导向是否“有类似问题”（以及可能的善后清理）是社群的责任，依然要走正常程序，如此使用不留重新导向权限并不合理。此外，你这样回复，似乎并未认识到问题核心，有解释跟没解释一样，而且让人有避重就轻之感，很不愉快。重新导向并非单纯可以任凭挪移、切割、置换的网页标题；你都知道提出快速删除有时也会有争议，那直接删除（不留重新导向）或改动导向目标，岂不是更有问题？我想，恐怕必须结合此前情况，认真考虑提出除权或停权申请。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月18日 (日) 04:53 (UTC)[回复]
@Ericliu1912：那我好奇你说的“正常程序”又是什么。另见下。Sanmosa 新朝雅政 2025年5月18日 (日) 05:23 (UTC)[回复]
？？？有需要重新导向就新建立一个啊，然后觉得某个重新导向不适合保留，可以提存废讨论（偶尔也能提交快速删除）；仅有非常少数情况，可以直接移动而不留重新导向。不然呢？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月18日 (日) 06:39 (UTC)[回复]
然而在遇到我在下方提到的错误连结的问题的时候，你说的“正常程序”似乎无法作出有效的处理，而且AFD的讨论有可能会无视错误连结的问题客观存在的事实，因此有必要确保R7能有效处理这种错误连结的问题。Sanmosa 新朝雅政 2025年5月18日 (日) 07:24 (UTC)[回复]
这般偏差歪理，恕难以理喻。另此处所论实为不当移动操作，亦与快速删除原则无关。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月18日 (日) 10:56 (UTC)[回复]
其实是有关系的。为了使产生错误连结的重新导向错误连结的情况不再持续，在R7无法有效处理这种错误连结的问题的情况下，调整产生错误连结的重新导向成为唯一的办法。你要把事实说成“偏差歪理”我也实在是没办法，但有类似问题的重新导向非常多这点我随手点一下就能找到例证。比如持明院是一处宅邸的名称，而且还是一个公家（日语：持明院家）的家名，现在却是指向持明院统条目的重新导向，这情况与把大觉寺 (京都市)条目改成指向大觉寺统条目的重新导向一样诡异。然而，如果我就此例提请R7而且由你经手的话，那你肯定会直接退回我的请求，这就是我说的“‘正常程序’似乎无法作出有效的处理”，而如果我真的遇到必须要设置指向宅邸“持明院”的连结的情况的话，在R7无法有效处理这种错误连结的问题的情况下，我将会无可避免地需要让“持明院”的重新导向页换个名字。不过我现在写的东西暂时还没涉及到宅邸“持明院”，因此我也不会现在动“持明院”的错误重新导向，但如果可以的话不妨考虑现在用R7处理一下。Sanmosa 新朝雅政 2025年5月18日 (日) 12:41 (UTC)[回复]
其实也有另一种解方，就是直接现写一个条目覆盖掉原本的重新导向，然而这某程度上算是强迫用户从写条目与无视错误连结的问题之间做选择，而且维基百科本身也无法保证所有人一定有时间为了错误连结的问题现写一个（有相当品质的）条目，就比方说我此后自jawiki临时翻译了一小部分内容占位，以终止桂园时代错误连结的问题，但这临时翻译的品质实在无法过我自己的那关，我要自己为自己的翻译放维护模板其实也挺尴尬的，当然我现在又重写了那条目就是了。Sanmosa 新朝雅政 2025年5月18日 (日) 13:01 (UTC)[回复]
“错误连结”的问题，有就让社群存废讨论去，大轮不到快速删除的事，何况R7准则很多时候根本不是这样使用的，且你对“错误”的解释有时过于宽泛，这都另当别论。无论如何，所谓“错误连结”，不过占你不当操作的一部分，绕去讨论个案以偏概全，并不能回避其余问题。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月18日 (日) 14:46 (UTC)[回复]
R7在以前向来都是如此使用的（我指以R7处理外文维基百科有条目的重新导向删除请求），因此我一直都对于你拒绝执行此类R7有很大的困惑。此外，我现在才留意到你一直在把我的几种不同的移动不留重新导向情形混为一谈，我在此之前一直以为你只是在说其中一种情形，我就其他情形的具体回应见此。Sanmosa 新朝雅政 2025年5月19日 (一) 00:07 (UTC)[回复]
那我就问一句，这所谓“调整产生错误连结的重新导向”，是不是规避常规删除（或快速删除）程序？是不是不尊重社群讨论的空间（亦请注意直接改标题跟改导向目标算是两回事）？为什么你觉得面对这种明知社群尚有歧见、可能发生争议（包括重新导向目标及有关条目内容调整等）的情况，可以全部自个儿用移动不留重新导向的功能处理？这功能的本意是让你这样使用吗？甚至若用权谨慎，且结果都是“正确”移动，那还勉强能接受，但情况有时并非如此，如我前面随便都能看到两三例错误、值得商榷或至少不应直接操作的情况，一路清查下去还得了？因此这般强说辞，更难以令人信服。你自谓无奈，别人更无奈，时不时还要帮忙善后。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月18日 (日) 15:03 (UTC)[回复]
这整桩事件里面唯一可以善意推定的就是不留重新导向代表有也直接移回原标题的可能，但这好像没什么值得说的== —— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月18日 (日) 15:27 (UTC)[回复]
已经提出除权申请。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月18日 (日) 15:27 (UTC)[回复]
Wikipedia:重定向#何时不可移动而不留重定向这里，我看没提到和内部链接有关的描述。建议加上相关描述，更加明确地要求针对不符快速删除方针的重定向，要确保其已经没有内部链接才能移动时不留重定向，特别是模板、模块名字空间如果移动时不留重定向，会引起技术问题。分类名字空间如果这么做，会影响机器人执行“尚未清空的已重定向分类”的清理工作。--💊✖️2️⃣3️⃣（留言） 2025年5月17日 (六) 08:57 (UTC)[回复]
“移动时不留重定向”章节已经提到这个操作的前置条件了：一般情况下，重定向是历史纪录中一个有用的条目，所以除非有充分理由移动时不留重定向，最好将其留下。重定向留下帮助读者找到旧文章一条线索，以防在其先前位置创建新文章，并防止连结失效。因此，我们通常既不移动时不留重定向，也不删除重定向。不要只盯着“何时不可移动而不留重定向”哪里的一句话。“防止连结失效”就是你想要的内部链接有关的描述。--Nostalgiacn（留言） 2025年5月17日 (六) 10:43 (UTC)[回复]
我看到了，不过我个人认为还不够清晰，特别是考虑其他名字空间的情况，移动页面不留重定向的后果不止是“连结失效”。--💊✖️2️⃣3️⃣（留言） 2025年5月17日 (六) 11:46 (UTC)[回复]
@Liu116：这种规定有一种问题，就是比如A有B、C等不同含义，A是指向B的重新导向页面，并存在一定数量的连入，但该等连入实际上应该指向无条目的C，如果要求“没有内部链接”将会导致错误连结的问题难以被察觉。Sanmosa 新朝雅政 2025年5月18日 (日) 04:07 (UTC)[回复]
你说的对，论述确实完善的空间。（申明一下，我只是认为我提议的论述确实有改善空间，不代表我认同指出我提议有问题的用户先前所采取的一些有争议的编辑）--💊✖️2️⃣3️⃣（留言） 2025年5月18日 (日) 12:43 (UTC)[回复]
然而从上方可见，部分用户（包括管理员）并不把错误连结的问题当成问题，甚至还促成错误连结被恢复。Sanmosa 新朝雅政 2025年5月18日 (日) 12:44 (UTC)[回复]
根本是两回事，又在造谣。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月18日 (日) 14:43 (UTC)[回复]
然而我上面说的事情是真实发生的，客观上来说，我上面提到的错误连结确实一度被恢复了。Sanmosa 新朝雅政 2025年5月19日 (一) 00:12 (UTC)[回复]
即便你说的问题存在，有关连结去留本亦应由社群经讨论程序（不管是客栈还是存废讨论等）决定，跟前述不当移动操作的实质显然毫无关联。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月18日 (日) 14:59 (UTC)[回复]
如上所言，这类错误连结向来就是以R7处理的，“本亦应由社群经讨论程序决定”这种说法可能有过度引用R7“未解决的争议”条款的疑虑。Sanmosa 新朝雅政 2025年5月19日 (一) 00:15 (UTC)[回复]
个人认为在本案的情境下加不加这行根本没有用，反倒会创造更多七奇八怪的例外问题（存废讨论要不要滤？沙盒要不要滤？讨论页要不要过滤？外部链接要不要过滤？……），难以支持，更好的做法是劝人尽可能不要用这个功能并提交到存废讨论。--SunAfterRain 2025年5月19日 (一) 17:25 (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)[回复]

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

就辽宁省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)[回复]

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

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

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

例如《二十八宿》，显示错误：{{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)[回复]
已提交编辑请求。--Vozhuowhisper 2025年5月9日 (五) 08:02 (UTC)[回复]
使用ko-hanja的条目也报错了（应该用ko-hani）。检查情况貌似只有思源宋体一个条目在用，已经手动修正。--Dabao qian℡ 2025年5月13日 (二) 20:03 (UTC)[回复]

视觉化编辑器加入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)[回复]

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

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)[回复]
User:Hamish/Catalot.js是commons现时版本加入变体识别后的版本，已尝试该操作且正确移除。@Ericliu1912、YFdyh000、Yumeto，展开的错误没有复现。--Hamish T 2025年5月9日 (五) 10:18 (UTC)[回复]
@Hamish：，此版本在触发变体识别后，会添加不必要的空行（示例），是否可修复？十分感谢。--Tim（留言） 2025年5月13日 (二) 03:06 (UTC)[回复]
您好，似已修复。--Hamish T 2025年5月13日 (二) 04:09 (UTC)[回复]
👍 赞—Tim（留言） 2025年5月13日 (二) 04:13 (UTC)[回复]
@Hamish：您好，我刚刚再次试了一批页面（已清除浏览器缓存、重新登入账号），部分页面仍有问题（具体可见我刚才的编辑记录）：涉及变体识别1、涉及变体识别2、不涉及变体识别--Tim（留言） 2025年5月13日 (二) 04:44 (UTC)[回复]
好的，因为这个是从commons生搬硬套过来的，没有太看其他代码，我写完手上这个twinkle再晚些会进一步查看，再次抱歉。--Hamish T 2025年5月13日 (二) 04:47 (UTC)[回复]
有劳阁下有空时看看了，感谢。另我之前是使用的Commons版本，不会出现添加空格的情况（例），供您参考。--Tim（留言） 2025年5月13日 (二) 04:51 (UTC)[回复]
似已修复x2。--Hamish T 2025年5月13日 (二) 06:15 (UTC)[回复]
试了一批页面确实没有空行了，十分感谢！--Tim（留言） 2025年5月13日 (二) 06:22 (UTC)[回复]
@Hamish 您好，下午使用一段时间后还发现以下小问题：移除分类时没有将多余空行删除（[3]）；Cat-a-lot激活状态下打开另一个分类页面，自动弹出的Cat-a-lot是空白的，需要关闭再打开恢复。还请方便的时候帮忙看看，感谢。--Tim（留言） 2025年5月13日 (二) 09:12 (UTC)[回复]
您好，第一个问题我下午已经发现了，忘记将设备上的程式码同步。第二个问题我早已发现，还没来得及修。谢谢。--Hamish T 2025年5月13日 (二) 09:18 (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)[回复]
本地似乎已经可用[4]--百無一用是書生 (☎) 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)[回复]
@Shizhao：“现在图表大小和颜色等似乎还都不能自定义”可参见此说明文档。“共享资源的Data数据也没有提供连结过去方便修改”可参见开发人员对问题二的回复，似乎已有相应工单但暂时未有进展。谢谢。--SCP-0000（留言） 2025年5月14日 (三) 18:15 (UTC)[回复]
不支持用lua产生数据吗? 这样{{函数图形}}就死掉了耶QQ-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2025年5月8日 (四) 11:23 (UTC)[回复]
@A2569875： 在 mediawiki.org 上有与 lua 和页面浏览量数据相关的讨论，也许可留意一下。谢谢。--SCP-0000（留言） 2025年5月14日 (三) 18:36 (UTC)[回复]
{{函数图形}}与页面浏览量无关。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2025年5月14日 (三) 22:34 (UTC)[回复]
能反馈这些问题回开发组？——Sakamotosan路过围观 | 避免做作，免敬 2025年5月8日 (四) 12:52 (UTC)[回复]
@Sannita (WMF): Hello, thank you for your information! The community shared some comment in this discussion as follow:
  1. Shizhao: The Charts extension does not support access to external sources, e.g., it cannot access the number of page views. Moreover, the size and color of the graph cannot be changed by community, and there is no link to the Commons Data namespace for editing data.
  2. @A2569875: The extension cannot support the use of Lua to generate data; therefore, the template {{函数图形}} (Graph of a function) cannot be used to create the graph of a function.
--SCP-0000（留言） 2025年5月19日 (一) 10:38 (UTC)[回复]
Thank you @SCP-2000 for pinging me and reporting me your comments, very much appreciated. I'll pass it on to the team, and see that they work on what you reported. Anyway, the team is currently working on leveraging Lua for data transformations, and exploring changes to support Lua in order to provide an interface with external data sources. We're still in the initial phase, but there are already ideas about it. I hope to let you know soon, but in any case, please ping me here or on my talk page, I'll be happy to answer.--Sannita (WMF)（留言） 2025年5月19日 (一) 13:37 (UTC)[回复]

Cat-a-lot一次最多只能批量操作20个页面，请求修复

如题，本人近期计划把分类XXXX年启用的铁路车站下面位于中国境内的车站批量移动到分类XXXX启用的中国铁路车站下面。使用Cat-a-lot小工具实操的时候发现一次最多只能移动20个条目，选择多于20个条目的时候就会从第21个条目开始显示修改成功，但是点进条目页面却发现分类没有变动（在commons上面使用Cat-a-lot批量操作的时候不会出现类似问题）。不知道和@Yumeto阁下提到的问题是不是同一个或者类似的问题，希望能予以定位修复，谢谢！--4084470 0.smil（留言） 2025年5月8日 (四) 16:40 (UTC)[回复]

@4084470 0.smil：你的编辑被第8号防滥用过滤器拦住了--SunAfterRain 2025年5月8日 (四) 16:44 (UTC)[回复]
@Xiplus 可否考虑适当放宽限制，现在使用Cat-a-lot太不方便了qvq……使用的Commons版Cat-a-lot貌似已经限定频率为一秒一次编辑了。--Tim（留言） 2025年5月10日 (六) 17:14 (UTC)[回复]
个人建议在Cat-a-lot端放缓速度，污染最近更改和突然拦住编辑哪个都不好--1F616EMO（喵留言～回复请ping） 2025年5月10日 (六) 23:09 (UTC)[回复]
该过滤器已多次放宽，不考虑再放宽。您应该申请机器人相关权限。--Xiplus#Talk 2025年5月11日 (日) 00:54 (UTC)[回复]

请问条目“利奥十四世”标题繁简转换的来源是？

我想知道 良十四世 在zh-cn下是如何显示为 列奥十四世 的？ 我查阅 https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/languages/data/ZhConversion.php 和 https://zh.wikipedia.org/wiki/Wikipedia:%E5%AD%97%E8%AF%8D%E8%BD%AC%E6%8D%A2/%E5%9C%B0%E5%8C%BA%E8%AF%8D%E5%80%99%E9%80%89 都未看到这一转换。望好心人解答。 --FloatingQueen（留言） 2025年5月12日 (一) 12:52 (UTC)[回复]

Module:CGroup/Popes。您都能自己查ZhConversion.php了怎么会不知道公共转换组……——暁月凛奈 (留言) 2025年5月12日 (一) 13:02 (UTC)[回复]
感谢您的回复。看了繁简处理、地区词处理、公共转换组中的前两项。第三项见列表长未有仔细阅读。感谢您的答疑解惑。--FloatingQueen（留言） 2025年5月12日 (一) 13:16 (UTC)[回复]
ZhConversion.php涉及的是比较基本、没什么争议的转换，而公共转换组是站内用户自行创建维护，需要灵活处理的词汇一般都采取这种方式，比如电影译名/人名。——暁月凛奈 (留言) 2025年5月12日 (一) 13:25 (UTC)[回复]
感谢您的耐心解释。--FloatingQueen（留言） 2025年5月12日 (一) 13:27 (UTC)[回复]
另外，使用noteTA模板设置了字词转换的页面上方会出现本页使用了标题或全文手工转换，点击即可查看具体设置的转换规则和公共转换组（如有）。——暁月凛奈 (留言) 2025年5月12日 (一) 13:29 (UTC)[回复]
这个功能非常方便。谢谢您。--FloatingQueen（留言） 2025年5月12日 (一) 13:34 (UTC)[回复]

Twinkle更新 (2025-05-12) @dca85a4

近期变更
  • 警告：加入uw-disruptive系列模板。
  • 关闭存废讨论：在Vector-2022外观上重新启用此功能。
  • 封锁：如选择以{{Blocked sockpuppet}}标记用户页，日志理由会显示为“（原有理由） - （主账户）的傀儡”。
  • 提删：修正“收录标准不足条目”语病至“不符合收录标准条目”；修正当提报不符合收录标准的条目标题包含“=”时，{{findsources}}模板未能正确传入页面标题的问题。
  • 告状：报告当前的破坏和编辑争议时，不再加入“处理”一行。
  • 内建文字提示因应指引更名作出相应修改。

如果近期变更有任何错误，或是认为未来变更会造成任何问题，请在Twinkle讨论页、互助客栈技术版或Github择一报告。--Hamish T 2025年5月12日 (一) 15:20 (UTC)[回复]

2025年第20期技术新闻

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

本周要闻

  • 侧边栏的“获取短链接”连结（功能说明）现在会同时显示QR码，供使用者扫描或下载。维基媒体网站使用者现在多了一个便利的方式来快速分享维基媒体网站和存取分享内容。

近况更新 - 面向编辑者

  • 维基媒体基金会正在开发名为Edge Uniques的系统，该系统可用于实现A/B测试，帮助抵御DDoS攻击，并让我们更容易了解维基媒体网站的访客数量。有了Edge Uniques，基金会可以更有效率地打造能帮助读者的工具，让读者更容易找到他们要找的东西。技术新闻先前曾撰文介绍过该系统。该系统将逐步进行部署。有些人可能会在5月19日当周见到Edge Uniques的Cookie。相关讨论在此讨论页进行。
  • 2025年5月19日开始，已启用CampaignEvents扩充功能的维基中的活动筹办人员可以在专案命名空间（例如“Wikipedia:”、“Wikidata:”等）中使用活动报名功能。有了这项变更，社群不需要管理员也能进行活动报名。不想要这项变更的维基可以在Special:CommunityConfiguration/CampaignEvents中移除／新增允许使用的命名空间。
  • 已新建努佩语维基百科（w:nup:）。这是一种主要在尼日利亚中北部地区使用的语言。邀请使用该语言的人士来为新的维基百科做出贡献。
  • 经常项目 上周有27件社群提交的工单得到解决。

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

  • 开发者现在可以透过结构化内容快照（Beta）存取7个维基百科（英语、德语、法语、西班牙语、葡萄牙语、意大利语、荷兰语）的预解析内容。这些内容包括已解析的维基百科摘要、描述、主要图片、资讯框、条目章节和参考资料。
  • REST API的/page/data-parsoid端点已不再使用，并将被弃用。预定2025年6月7日关闭。
  • 经常项目 本周软件更新细节： MediaWiki

深入了解

  • 云端服务现已支援IPv6，这将大幅提升维基媒体平台的可扩缩性与安全性，为未来做好准备。欲知详情的技术贡献者可参阅这篇博文，深入了解我们迈向IPv6的历程。

会议与活动

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

MediaWiki message delivery 2025年5月12日 (一) 22:37 (UTC)[回复]

可视化编辑时，使用“引用”功能，概率会将引用来源Cite模板内容替换掉条目最上方的note TA模板

现象可见[5]第1行的变化，非编辑刻意而为。这种问题在可视化编辑下没有办法第一时间发现，只有在提交编辑或者切换为代码编辑的时候才会发现。--【拒绝编辑霸凌，拒绝拉扯性讨论，谢绝拉票，谢绝提名，谢绝豢养人肉傀儡】（有建议可以留言） 2025年5月14日 (三) 03:34 (UTC)[回复]

更新问题

Wikipedia:最多语言版本的待撰条目/自动更新中BOT已逾月未自动更新，请问如何解决--Kanshui0943（留言） 2025年5月15日 (四) 07:42 (UTC)[回复]

@Kanashimi：。--Hamish T 2025年5月15日 (四) 08:23 (UTC)[回复]
fixing...--Kanashimi（留言） 2025年5月15日 (四) 13:50 (UTC)[回复]

界面显示

是不是有人搞爆CSS了，修订版本那个框框跟巡查按钮原本都是小字，突然变成大字⋯⋯ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月15日 (四) 15:43 (UTC) 👍1[回复]

(～)补充：“发生错误，编辑未发布”还变小字了，预览出错那里也变小字了。( π )题外话：还以为是技术更新_(:з”∠)_--__Don't bite! 2025年5月15日 (四) 16:09 (UTC)[回复]
已经几天了，还没解决。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月18日 (日) 14:35 (UTC)[回复]
我没能复现你们说的问题--百無一用是書生 (☎) 2025年5月19日 (一) 03:08 (UTC)[回复]
Timeless用户有看到巡查按钮突然变很大。--Tim（留言） 2025年5月19日 (一) 13:56 (UTC)[回复]

关于<br>、<br/>、<s></s>和<del></del>

新手求问：

  1. <br>和<br/>有什么不同？为什么许多人要多打一个斜杠？
  2. <s></s>和<del></del>都是删除线，难道这两个有技术上的不同？( π )题外话：印象里几年前在萌娘百科编辑时有用户提到<s></s>容易出bug，是真的吗？

--__Don't bite! 2025年5月15日 (四) 16:17 (UTC)[回复]

这是WP:知识问答范畴。询问AI大模型应该能给您提供很多信息。自闭合标签，不同规范要求不同。语义、可用参数及视觉表现可能不同。没有听说过。--YFdyh000（留言） 2025年5月15日 (四) 16:49 (UTC)[回复]
@Kurgenera：去问LLM https://felo.ai/search/jsMv6a6Agwkudv9kC2srsw?invite=B84klorrag5PV --SunAfterRain 2025年5月15日 (四) 19:10 (UTC)[回复]
本页用作讨论在编辑时遇到的技术问题，源码编辑可以用HTML所以在这问也行。本站应该对此没有要求，所以<br>和<br/>用哪个都没问题，前者省1个字节。<s>是过时的HTML，“容易出bug”大概是指这个，所以建议<del>，只要别在条目里用就好（MOS:删除线）--Kunjinkao（留言） 2025年5月16日 (五) 08:55 (UTC)[回复]
https://www.youtube.com/watch?v=jISSlNmrvW8 Bluedeck 2025年5月17日 (六) 09:39 (UTC)[回复]
@Kunjinkao：我怀疑<s>是过时的HTML是贵站自己弄出的谣言呢，网络上找到的都是废弃<strike>--SunAfterRain 2025年5月18日 (日) 05:59 (UTC)[回复]
<s>在HTML 4里是deprecated：HTML 4.01 A.3.1，不过HTML 5里反而建议用<s>和<del>代替<strike>[6]--Kunjinkao（留言） 2025年5月18日 (日) 08:36 (UTC)[回复]
那就相当于弃用被逆转了嘛 囧rz……--SunAfterRain 2025年5月18日 (日) 12:35 (UTC)[回复]

哈萨克语

报错，“错误：{{Lang}}：代码 kk 无法和书写系统 cyrl 一起使用”。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月16日 (五) 14:14 (UTC)[回复]

@Ericliu1912 {{Lang}}模板和相关模块的问题，未支持该种语言中主要的文字系统（这里需要去掉cyrl），该板块之前有个用来讨论相关模板善后问题的串存档了。--Kethyga（留言） 2025年5月18日 (日) 13:31 (UTC)[回复]
@Kethyga：那理当回退更改吧？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月18日 (日) 14:35 (UTC)[回复]
仓促上架，见相关更新善后和{{lang}}模板的更改，不过更改快有2个月了。相关代码只有Vozhuo一人熟悉，个人感觉重要模板和模块的大改，未经他人检视和测试便上架，有些不负责任。--Kethyga（留言） 2025年5月18日 (日) 14:50 (UTC)[回复]
模板:Infobox Hokkien name似乎也有出现类似错误（之前修了一半另一半修不来直接搁置），不知lang更改后有没有解决？--__Don't bite! 2025年5月18日 (日) 15:26 (UTC)[回复]
早就讲过了== —— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月19日 (一) 09:25 (UTC)[回复]
噢，原来之前正好就讨论过⋯⋯但没下文。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月19日 (一) 09:41 (UTC)[回复]

Join the 6th Wikipedia Pages Wanting Photos Campaign – 2025 Edition

Dear Wikipedia community,

(Please help translate to your language)

We invite your community to participate in the 6th edition of the Wikipedia Pages Wanting Photos Campaign, a global campaign taking place from July 1 to August 31, 2025.

Participants will choose among Wikipedia pages without photos, then add a suitable photo from among the many thousands of photos in the Wikimedia Commons, especially those uploaded from thematic contests (Wiki Loves Africa, Wiki Loves Earth, Wiki Loves Folklore, Wiki Loves Monuments, etc.) over the years.

More than 80 Wikimedia affiliates have participated since the campaign was launched in 2020 and have added images to more than 400,000 Wikipedia articles in over 245 Wikipedia languages. Thanks to the volunteer contributors!

We now invite your community to organize and lead the campaign within your community. As a local organizer, you may:

  • Encourage individual members to take part by adding images to Wikipedia articles.
  • Host edit-a-thons focused on improving visual content.
  • Organize training workshops to teach contributors how to correctly integrate images into Wikipedia.

These activities will help build local capacity and increase visual content across Wikipedia.

Please note that for participants to be eligible to participate in the campaign, they need to have registered an account for at least a year before the official start date of the contest. That is, for the 2025 edition, they must have registered an account on or before July 1, 2025. The account can be from any Wikimedia project wikis.

The organizing team is looking for a contact person to coordinate WPWP participation at the Wikimedia user group or chapter level (geographically or thematically) or for a language Wikipedia.

We would be glad for you to sign up directly at WPWP Participating Communities.

With kind regards,

User:Reading Beans On behalf of the Wikipedia Pages Wanting Photos campaign 2025. MediaWiki message delivery（留言） 2025年5月18日 (日) 21:53 (UTC)[回复]

以删除线划去被封禁的用户

小工具里的这个功能只对受本地封禁的账户有效，被全域锁定者也应该适用？或技术上做不到？。->>Vocal&Guitar->>留言 2025年5月18日 (日) 23:38 (UTC)[回复]

@Ohtashinichiro：技术上做的到，这个重责大任就交给你实现了（）--SunAfterRain 2025年5月19日 (一) 17:15 (UTC)[回复]

2025年第21期技术新闻

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

本周要闻

  • 编辑团队和机器学习团队正在开发一项面向新手的检查：华辞检查。这项检查利用预测模型和AI，鼓励编辑者改善其编辑的语调。团队邀请志愿者参与审查下列语言的华辞模型的初版：阿拉伯语、西班牙语、葡萄牙语、英语和日语。如果您来自上述维基并有兴趣参与审查该模型，欢迎至MediaWiki.org报名参加。报名截止日期为5月23日，当天亦为测试开始日。

近况更新 - 面向编辑者

  • 2025年5月20日开始，监督员和用户查核员必须用双重验证（2FA）保护其账号，才能使用其高级权限。所有属于这两个群组但未启用2FA的使用者都已收到通知。未来这项要求可能会扩大到其他高级权限群组。阅读完整公告。
  • 愿望清单项目 本月底，多重封锁将开始大规模部署至多个维基：5月26日当周将部署至所有非维基百科专案以及加泰罗尼亚语维基百科；6月2日当周将部署至所有其他维基百科。如有任何疑虑，请联络团队。管理员现在可以在本地浏览Special:封禁?usecodex=1来测试新UI，或是在测试维基测试完整功能。多重封锁可让管理员同时对同一使用者施加多种不同类型的封锁。详情请参阅说明页面。 [7]
  • 本周稍晚，列出几乎所有特殊页面的Special:特殊页面将更新整体设计。经过重新设计后，该特殊页面在数个方面改善了使用者体验，包括：名称与别名搜寻功能、排序功能、更明显的“受限特殊页面”标示，以及更适合移动设备的外观。您现在可以在Beta Cluster预览新版本，并在Phab工单分享反馈意见。 [8]
  • 更多维基现已可以使用Chart扩充功能。详细部署资讯请参阅部署时间表。
  • 5月27日，维基函数将部署至5个维基词典：豪萨语、伊博语、孟加拉语、马拉雅拉姆语和迪维希语。这是维基函数的第二批部署。部署完成后，这些专案将能够从维基函数呼叫函数，并在页面中使用。函数能接受一个或多个输入，并将其转换成预期的输出，例如：相加两数、换算单位、计算时间跨度或转换大小写。有了维基函数，使用者只需呼叫一个稳定的全域函数即可达成目的，无需使用本地模板。
  • 本周稍晚，维基媒体基金会将发布一个实验中心，用于展示和获得使用者对产品实验的反馈。这些实验协助维基媒体运动了解新使用者、他们如何与网络互动，以及他们如何影响维基媒体运动。一些实验例子包括生成影片、维基百科Roblox速通游戏和Discord机器人。
  • 经常项目 上周有29件社群提交的工单得到解决。 例如：使用API建立账号时会遇到一些问题，现已得到修复。 [9]

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

  • 部分与Special:封禁互动的小工具与脚本需要更新才能与新的管理封锁界面互动。请查阅开发者手册以了解更多资讯。如果您需要任何协助或您的脚本无法与新的界面互动，请在此讨论页留言让技术团队知道。 [10]
  • Lua的mw.title物件可用来取得特定维基页面的资讯。本周开始，该物件将新增名为isDisambiguationPage的属性，可用来检查页面是否为消歧义页面。 [11]
  • 高级项目 脚本开发者可以使用新的反向代理工具来透过mw.loader.load从gitlab.wikimedia.org载入JavaScript和CSS。工具的作者希望这个工具能实现脚本的协同开发工作流程，包括gitlab.wikimedia.org上的linting、单元测试、代码生成和代码审查，而无需另外将脚本复制贴上到维基媒体维基上以进行整合和验收测试。详情请参阅Wikitech上的 Tool:Gitlab-content。
  • 经常项目 本周软件更新细节： MediaWiki

会议与活动

  • 2025年维基工作坊（第12届）将于5月21日至22日线上举行，探索维基媒体专案方方面面的研究人员将在此论坛齐聚一堂。立即报名。

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

MediaWiki message delivery 2025年5月19日 (一) 23:11 (UTC)[回复]


求助

请求协助上传档案 2025-05-09 13:21

我想要上传的图片来源是<https://namu.wiki/jump/vBkwHyzy%2B6sI5lo9cLXmwCU31L%2F7uiAJsgqlSvnpEaILxhazO7QrmpCp6pWumpHj2URCFhCk6dTO%2FkRFW9uly4JX7EDGVPDrRdC1OYqOfEW0JoRt6DEDa%2BJlq2KePY%2BG>，想要使用在我培育的S絬们）的<资讯框>。 --Drogon629831（留言） 2025年5月9日 (五) 13:21 (UTC)[回复]

未完成：草稿不可使用非自由媒体，请在提交审核并转正后再申请。另初步判断该图片并不能带给读者有效的信息，违反WP:NFCC#8，建议寻找游戏封面等视觉辨识度高的图像。--1F616EMO（喵留言～回复请ping） 2025年5月14日 (三) 08:38 (UTC)[回复]
@Drogon629831--1F616EMO（喵留言～回复请ping） 2025年5月14日 (三) 08:39 (UTC)[回复]

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

我想要上传的图片来源是<https://weibo.com/7905262090/5135501776126560>，想要使用在[[12]]的<资讯框>。 --Jane0498hiha（留言） 2025年5月11日 (日) 16:05 (UTC)[回复]

这个作者有说可以搬运，我要上传第一张的，谢谢尼😭--Jane0498hiha（留言） 2025年5月11日 (日) 16:09 (UTC)[回复]
@Jane0498hiha：“作者有说可以搬运”这句不太明确。请您请求原作者以WP:DONATEIMAGE的流程，在微博上里面声明图片以CC-BY-SA 4.0协议授权。有疑虑的话，请她私下发信至 [email protected] 也可以。授权也可以选择CC-BY或CC-0授权。有明确授权的话，您可将图片上传至共享资源。 --Saimmx（留言） 2025年5月12日 (一) 07:46 (UTC)[回复]
好的了解，谢谢你--Jane0498hiha（留言） 2025年5月14日 (三) 12:04 (UTC)[回复]
在世人物不接受非自由图片。--Miyakoo（留言） 2025年5月11日 (日) 16:33 (UTC)[回复]
明白了，谢谢你--Jane0498hiha（留言） 2025年5月14日 (三) 12:05 (UTC)[回复]

阿基米德大战与The Great War of Archimedes（英语：The Great War of Archimedes）

本主题或以下段落文字，在讨论结束后应存档至Talk:阿基米德大战。

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

条目阿基米德大战有中文版日文韩文版，而条目The Great War of Archimedes（英语：The Great War of Archimedes）则有英文版德文版法文版，但两边居然没有跨语言链接，请问这是怎么发生的？如何发现其他的例子？如何改善？如何预防？在中文维基百科直接建立The Great War of Archimedes指向阿基米德大战有帮助吗？--2603:8000:500:FB00:7DA9:554A:F361:66EC（留言） 2025年5月11日 (日) 18:07 (UTC)[回复]

前后两者介绍的对象类型好像不一样呢😅
中日韩版介绍的是漫画本身；英德法版则是介绍改编电影，
所以就算在Wikidata用​Gadget-Merge.js小工具尝试合并，也会因为互为衍生作品跟改编自的关系直接被拒绝
(实际上，这样↑合并跨语言链接大概也是个不甚正确的做法就是了)--竹林下小径，月光映一叶 2025年5月12日 (一) 01:29 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

为何在公立学校网域内不能编辑维基百科?

您现在使用的IP地址目前不能编辑维基百科 您可以浏览页面，但不能编辑或建立页面 目前，IP地址区段“2001:288:0:0:0:0:0:0/32”已被‪ATannedBurger‬封禁，而您所使用的IP地址正位于被封禁的范围内。该IP地址区段被封禁的--Liaohungping（留言） 2025年5月12日 (一) 07:30 (UTC)[回复]

学校网域常被用来破坏，您可以参考WP:IP封锁豁免权来获取相关权限以编辑。--Sakurase留言 2025年5月12日 (一) 07:34 (UTC)[回复]

共享资源分类添加说明后成为了隐藏分类

commons:Category:Longxing Temple, Yishui，我为新创建的分类添加说明模板后，这个分类变成了隐藏分类，根据提示框信息是和英语语言有关，但是我不太明白具体要修改什么。---- ★WPTO★ 2025年5月12日 (一) 09:10 (UTC)[回复]

不要使用模板，直接写说明文字就行。--Kcx36（留言） 2025年5月12日 (一) 14:30 (UTC)[回复]

回退和撤销有什么区别？

想问一下，在历史记录中如果开启了TW工具就会有“回退”选项，回退就是和撤销一样也是把词条恢复到以前的版本，那这两个有什么区别，请管理员帮忙回答下这个问题，谢谢。--Peterxy12（留言） 2025年5月12日 (一) 11:49 (UTC)[回复]

除了一些技术细节以外，没有区别。--SuperGrey (留言) 2025年5月12日 (一) 11:54 (UTC)[回复]
既然没有区别，那当回退员有什么意义？--Peterxy12（留言） 2025年5月12日 (一) 11:55 (UTC)[回复]
当涉及那些“技术细节”问题的时候，才有意义。--SuperGrey (留言) 2025年5月12日 (一) 12:03 (UTC)[回复]
Help:回退#类似功能的区别、Wikipedia:回退功能#回退功能的优点。撤销或者工具模拟的撤销（回退一系列编辑）是获取旧修订版本源代码、附编辑摘要提交源代码，而回退员的回退按钮是告知服务器回退某个页面的来自特定用户的最后一系列编辑，服务器会直接处理，用户端无需处理源码。--YFdyh000（留言） 2025年5月12日 (一) 14:03 (UTC)[回复]
回退权的优点如下：
  1. 相关编辑由服务器直接处理，节省来回时间和带宽；
  2. 回退不受过滤器影响，即使还原编辑会触发过滤器（例如破坏移除了现处于垃圾连结过滤器的来源）也不会被阻挡；
  3. 附带移动不留重定向功能，可以更有效回退移动破坏，以及进行审核草稿等其他操作（巡查员也拥有此权）。
--1F616EMO（喵留言～回复请ping） 2025年5月14日 (三) 08:35 (UTC)[回复]

请求协助上传档案 2025-05-12 13:01

我想要上传的图片来源是从https://bkimg.cdn.bcebos.com/pic/91529822720e0cf3d7ca3ac5ec0ee51fbe096b637cfe?x-bce-process=image/format,f_auto/resize,m_lfit,limit_1,h_901下载，想要使用在争座位帖的资讯栏及内文。 --GameCkd3r（留言） 2025年5月12日 (一) 13:01 (UTC)[回复]

未完成：条目已经被WP:草稿化，请在条目提交审核并转正后再次提交申请。另此图片疑似为其他平台的内嵌内容，下次请直接提供原页面的连结，方便判断版权状况。--1F616EMO（喵留言～回复请ping） 2025年5月14日 (三) 08:30 (UTC)[回复]
@GameCkd3r--1F616EMO（喵留言～回复请ping） 2025年5月14日 (三) 08:30 (UTC)[回复]

扩写三下乡

我想要扩写三下乡,这是因为该条目大多为结论,因此难于找到可靠来源,通过扩写来找到数据，从而进行论证结论--Vertin,do you want to be the timekeeper?（留言） 2025年5月13日 (二) 13:02 (UTC)[回复]

@Linxingjun：感谢阁下的贡献。阁下可以寻找WP:可靠来源，将其中所记述的事实记下，各来源有冲突之处则按提及来源的数量和可靠性按比重列出。至于“结论”亦需按来源加入，只能写由可靠来源记述的结论，不可WP:原创研究、自行总结。--1F616EMO（喵留言～回复请ping） 2025年5月14日 (三) 08:32 (UTC)[回复]
感谢您的建议，我已写完，将无WP:可靠来源以及涉及WP:原创研究的句子删除。这是链接--Vertin,do you want to be the timekeeper?（留言） 2025年5月15日 (四) 09:19 (UTC)[回复]
我现在已在其他条目加入该条目的Wikipedia:内部链接。参见：
支教
裴小倩
马俊 (花儿歌手)
无锡市第六高级中学
湘西民族职业技术学院
长沙电力职业技术学院--Vertin,do you want to be the timekeeper?（留言） 2025年5月15日 (四) 09:28 (UTC)[回复]

关于乌鲁木齐广播电视台和伊犁广播电视台的维吾尔语名称

如题，本人曾经在去年10月的时候请求过相关广播电视台的维吾尔语名称，可惜不了了之。好在随着人工智能的发展，OCR技术也变得越发成熟，目前已经从成功从相关电视台的版权页提取到相关文字。对比了一下提取的效果不错并体现在了相关条目的编辑里面（乌市、伊犁）。现在需要请懂维吾尔语的维基人帮忙验证准确性并添加拉丁维文，谢谢！@HaziiDozen--4084470 0.smil（留言） 2025年5月13日 (二) 17:22 (UTC)[回复]

您好，乌鲁木齐电视台目前挂的牌子是“乌鲁木齐广播电视台（维吾尔语：ئۈرۈمچى رادىيو-تېلېۋىزىيە ئىستانسىسى‎）”和乌鲁木齐广播电视集团（维吾尔语：ئۈرۈمچى رادىيو-تېلېۋىزىيە گۇرۇھى‎）的牌子。以前挂的是“乌鲁木齐人民广播电台（维吾尔语：ئۈرۈمچى خەلق رادىيوئىستانسىسى‎）”和“乌鲁木齐电视台（维吾尔语：ئۈرۈمچى تېلېۋىزىيە ئىستانسىسى‎）”的牌子。所以我将加黑部分从“乌鲁木齐电视台”改为“乌鲁木齐广播电视台”，与维吾尔语同（并改写了下两个条目的维吾尔语拼写），以及首句表述。若以后编写或谁有心编写可将以前名字的维吾尔文作为参考。--HaziiDozen🂢🀑🁲（给HaziiDozen留言） 2025年5月14日 (三) 04:20 (UTC)[回复]
万分感谢！后续本人创建新疆其他地市州广播电视台条目的时候（参见：{{新疆维吾尔自治区广播电视机构}}），阁下也可以留心看一下几个电视台的维吾尔语名称拼写是否准确。没记错的话博州、吐鲁番、哈密、巴州、阿克苏、克州、和田这几个地市州是有自己的维语频道，所以需要在条目里面体现维吾尔语名称的。克拉玛依似乎没有自己专门的维语频道，只会在九点半到十点半期间转播新疆二套。--4084470 0.smil（留言） 2025年5月14日 (三) 15:40 (UTC)[回复]
克拉玛依可以@木子子羊翔问问。--HaziiDozen🂢🀑🁲（给HaziiDozen留言） 2025年5月19日 (一) 05:00 (UTC)[回复]
克拉玛依有的，我印象2台还是3台来着--一般路过白学家(去打死他) 2025年5月19日 (一) 12:20 (UTC)[回复]
讨论重构：使用冒号缩排。1F616EMO（喵留言～回复请ping） 2025年5月14日 (三) 08:28 (UTC)[回复]

请求协助新增 烟波国际观光集团的条目

您好，烟波国际观光集团为台湾本土连锁饭店，我认为可以上架维基百科，麻烦大家协助，谢谢!--Yuhsiang Huang88（留言） 2025年5月14日 (三) 08:24 (UTC)[回复]

@Yuhsiang Huang88：请阁下先阅读WP:收录标准，确定该公司确实符合收录标准，否则维基百科无法收录。若确定符合，则请通过WP:建立条目流程建立条目。另若阁下受雇于烟波国际观光集团，请特别注意WP:利益冲突和WP:有偿编辑相关规定。--1F616EMO（喵留言～回复请ping） 2025年5月14日 (三) 08:27 (UTC)[回复]
我不太知道怎么声明利益关系--Yuhsiang Huang88（留言） 2025年5月14日 (三) 08:45 (UTC)[回复]
就有偿编辑（即阁下为公司雇员）而言，请看Wikipedia:有偿编辑 § 如何作出申报；就一般利益冲突而言，请见Wikipedia:利益冲突 § 申报利益冲突。若阁下确实不知如何操作，也可在此清晰说明，我可以协助添加相关模板。--1F616EMO（喵留言～回复请ping） 2025年5月14日 (三) 15:04 (UTC)[回复]
我是公司雇员，麻烦您协助添加模板，非常感谢!!!!--Yuhsiang Huang88（留言） 2025年5月15日 (四) 00:55 (UTC)[回复]
若阁下为雇员，则不应该使用{{User COI}}，而应该使用{{paid}}。--1F616EMO（喵留言～回复请ping） 2025年5月15日 (四) 05:22 (UTC)[回复]
完成，见修订版本87297516。--1F616EMO（喵留言～回复请ping） 2025年5月15日 (四) 05:25 (UTC)[回复]
您可以在自己的沙盒编辑这个主题的草稿。如果您认为草稿可以发布，请在草稿中加入{{subst:submit}}，并等待有经验的用户进行审核。--Bosco Sin 2025年5月15日 (四) 04:55 (UTC)[回复]
好的，我试试看，谢谢!--Yuhsiang Huang88（留言） 2025年5月15日 (四) 05:01 (UTC)[回复]
我现在编辑了一个沙盒，但好像还是有问题，请问可以帮我确认可以怎么调整吗?
https://zh.wikipedia.org/wiki/User:Yuhsiang_Huang88/%E6%B2%99%E7%9B%92--Yuhsiang Huang88（留言） 2025年5月15日 (四) 07:37 (UTC)[回复]
您的草稿因未符合收录标准而未能移动。请您补充可靠来源以满足该指引。--Bosco Sin 2025年5月15日 (四) 10:13 (UTC)[回复]
补充下可靠来源，主要是有信誉、且独立于烟波国际观光集团的新闻、论文、书籍等已出版的可验证资料。烟波饭店这边看到几份可能有用的来源：
  1. 联合
  2. 自由
  3. 中央社
这两篇看来新闻稿或置入行销有点多，所以虽然他们在商业财经方面是可信的媒体来源，但我有疑问：
  1. 商周
  2. 今周刊
--Saimmx（留言） 2025年5月15日 (四) 16:29 (UTC)[回复]
我已更新，再麻烦您们协助审阅，谢谢!--Yuhsiang Huang88（留言） 2025年5月16日 (五) 00:54 (UTC)[回复]

提问，关于禁制的问题

我现在是禁制，不能建立条目和新分类这个我知道。那么，如果我是建立草稿或沙盒，先整理找到的资料来源内容。那样行不行？这里我问下。这个那（留言） 2025年5月14日 (三) 22:17 (UTC)[回复]

阁下可以在草稿空间或用户页建立草稿，并使用{{subst:submit}}提交审核。另建议阁下先处理旧有条目的格式问题。参：阁下用户页下的讨论。--1F616EMO（喵留言～回复请ping） 2025年5月15日 (四) 09:42 (UTC)[回复]
哪里建立草稿空间？这个那（留言） 2025年5月15日 (四) 11:35 (UTC)[回复]
WP:草稿命名空间--1F616EMO（喵留言～回复请ping） 2025年5月15日 (四) 11:58 (UTC)[回复]
找了下，草稿是不是就“draft:条目名”，先问下？这个那（留言） 2025年5月15日 (四) 12:31 (UTC)[回复]
是的。阁下也可以使用WP:建立条目流程操作，确保无误。--1F616EMO（喵留言～回复请ping） 2025年5月15日 (四) 15:14 (UTC)[回复]
那大概知道了，那么分类呢？这个那（留言） 2025年5月16日 (五) 15:54 (UTC)[回复]
关于分类请见WP:分类。简而言之，分类的建立分两个步骤：
  1. 为页面添加分类：将[[Category:分类名]]加入至页面的底部，就会将该页面添加进该分类。顺带一提，若希望显示分类连结而非将页面添加进分类，需要在连结前面加一个半形冒号，即[[:Category:分类名]]。
  2. 建立分类页面：如果页面“Category:分类名”尚未存在，阁下可以为其建立描述页面。分类描述页面亦为一般页面，即阁下也可以（也通常应该）为分类添加分类，此时新的分类即成为其他分类的子分类。
--1F616EMO（喵留言～回复请ping） 2025年5月16日 (五) 22:54 (UTC)[回复]
那请问怎为分类创建描述页面？这个那（留言） 2025年5月18日 (日) 02:12 (UTC)[回复]
旧条目不少，需要在整理的不少，我可以一个个先慢慢来，那个急不了。另外，一些妖怪、自然精、鬼、恶魔。天使、神兽、神……，有不少的有关系的条目，缺预览图的，谁也帮忙补下古图？古图不少应该过版权公有领域了，应该可以用。不过我自己不清楚怎么百科里上传图片，谁也能有空的话帮忙下？--此条未正确签名的留言由这个那（讨论｜贡献）于2025年5月16日 (五) 16:27 (UTC)加入。[回复]
问下，为分类建立描述页面，那个怎么弄？这个那（留言） 2025年5月17日 (六) 13:41 (UTC)[回复]
讨论重构：删除@这个那留言的过多缩排。1F616EMO（喵留言～回复请ping） 2025年5月17日 (六) 15:01 (UTC)[回复]
@这个那：阁下上次的留言存在错误。请勿直接编辑讨论页源代码，请使用“回复”按钮。若找不到“回复”按钮，请前往参数设置上启用“启用快速回复”。--1F616EMO（喵留言～回复请ping） 2025年5月17日 (六) 15:13 (UTC)[回复]
那如果是原来留言，像有些字什么打错，来修正的话呢？这个那（留言） 2025年5月18日 (日) 02:21 (UTC)[回复]
阁下不熟悉讨论页源代码和讨论页指引，故不宜修改。阁下可以改为回应该留言，提出阁下的问题。--1F616EMO（喵留言～回复请ping） 2025年5月18日 (日) 04:07 (UTC)[回复]
那知道了，还是先感谢告知。这个那（留言） 2025年5月18日 (日) 14:21 (UTC)[回复]
为分类指派母分类的方式和条目相同，即在分类页底部加入[[Category:分类名]]。以Category:参孙为例，其页底内容包括[[Category:士师]]，即参孙为士师的子分类。--1F616EMO（喵留言～回复请ping） 2025年5月17日 (六) 15:20 (UTC)[回复]

请求草稿审阅 2025-05-15 05:44

原标题：请求协助上传档案。修改理由：内容为草稿探讨。修改者：竹林下小径，月光映一叶 2025年5月15日 (四) 08:31 (UTC)[回复]

https://zh.wikipedia.org/wiki/User:XIXIANGRUI/%E6%B2%99%E7%9B%92 更改了几次还是不行 现在没有更改的头绪 希望各位如果看出其中存在问题请多多指教 （来自菜鸟新手的求助）--XIXIANGRUI（留言） 2025年5月15日 (四) 05:44 (UTC)[回复]

格式问题和来源问题需要改善--尘埃之歌（留言） 2025年5月15日 (四) 08:22 (UTC)[回复]
@XIXIANGRUI：请不要重复提问，见建立条目专题询问桌上Mirfaek的回应。--1F616EMO（喵留言～回复请ping） 2025年5月15日 (四) 09:44 (UTC)[回复]
@XIXIANGRUI：做了一点小改善，目前唯一的主要问题就是翻译腔，遍布整个条目，需要处理。--__Don't bite! 2025年5月16日 (五) 00:11 (UTC)[回复]

香港繁体和澳门繁体有什么区别？

我想问一下，既然香港繁体和澳门繁体在叫法上，字形上一模一样，那为什么要把港澳繁体拆分开来呢？--Peterxy12（留言） 2025年5月15日 (四) 12:32 (UTC)[回复]

还是有细微不同的，例如copyright，澳门官方好像一般叫“著作权”，香港官方叫“版权”。--Hamish T 2025年5月15日 (四) 13:35 (UTC)[回复]
既然都一样，那为什么还要拆分开--Peterxy12（留言） 2025年5月15日 (四) 13:39 (UTC)[回复]
显示效果被转换组自动转换了。请看页面源码：澳門官方好像一般叫“著作權”，香港官方叫“版權”。--YFdyh000（留言） 2025年5月15日 (四) 13:45 (UTC)[回复]
那除了著作权，还有什么？--Peterxy12（留言） 2025年5月15日 (四) 13:46 (UTC)[回复]
港澳分别称呼eraser为擦胶和胶擦等等，主要是一个用语习惯的问题，一时让我说我可能还真说不上来几个。其实电箱150号用户应该能解答你的问题，但不知道他会不会看到。--Hamish T 2025年5月15日 (四) 19:25 (UTC)[回复]
去翻公共转换组，找到一例：洁西卡·雀丝坦（Item('Chastain, Jessica', 'zh:傑西卡·查斯坦;zh-hant:潔西卡·崔絲坦;zh-hk:謝茜嘉·謝西婷;zh-mo:謝茜嘉·翠絲頓;zh-tw:潔西卡·雀絲坦;zh-cn:杰西卡·查斯坦;zh-sg:杰西卡·查斯坦;zh-my:洁西卡·雀丝坦;'),）—— Matt Zhuang表示有事按“此”留言 2025年5月15日 (四) 19:56 (UTC)[回复]
还有曼诺·迪·奥利维拉(曼奴·迪·奧莉菲拉 vs 曼諾·迪·奧利維拉)—— Matt Zhuang表示有事按“此”留言 2025年5月15日 (四) 20:02 (UTC)[回复]
但是中文译名港澳写的是谢茜嘉·谢西婷--Peterxy12（留言） 2025年5月17日 (六) 06:09 (UTC)[回复]

Commons中图片日期“19世纪”在中维错误显示为“1850年”

见《柴可夫斯基》条目的信息框图片，commons.wikimedia.org/wiki/File:Tchaikovsky2.jpg显示的是“19世纪”，但在中维点开来却显示“创作时间：1850年”。副知@MykolaHK。 ——自由雨日🌧️❄️ 2025年5月15日 (四) 19:04 (UTC)[回复]

在条目标的话就加来源。--Mykola（留言） 2025年5月15日 (四) 19:08 (UTC)[回复]
我的重点是这个显示问题已有较大可能会误导读者😂就算条目不标，读者点开图片的可能性也是不小的。 ——自由雨日🌧️❄️ 2025年5月15日 (四) 19:29 (UTC)[回复]
嗯⋯这个是要修一修了。--Mykola（留言） 2025年5月15日 (四) 19:31 (UTC)[回复]

高风险条目被破坏

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

条目六四事件的概述被破坏，加上了“不对不对”四个字。望各位检查。( π )题外话：概述怎么改？--__Don't bite! 2025年5月15日 (四) 23:40 (UTC)[回复]

准确来讲，应该是条目包含的那行黑字，就和英维{{short description}}一个东西的那个。--__Don't bite! 2025年5月15日 (四) 23:42 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。
IP用户破坏，已自行解决。--__Don't bite! 2025年5月15日 (四) 23:45 (UTC)[回复]
中维用的是Wikidata，所以去条目的“维基数据项目”页就可以编辑了。——ZhaoFJx(Talk) 2025年5月16日 (五) 00:01 (UTC)[回复]
@ZhaoFJx：话说对应的wikidata是否可以申请保护或半保护？--__Don't bite! 2025年5月16日 (五) 00:04 (UTC)[回复]
@Kurgenera 请参见维基数据:保护方针。——ZhaoFJx(Talk) 2025年5月16日 (五) 00:11 (UTC)[回复]
@ZhaoFJx：多谢，已提报破坏。--__Don't bite! 2025年5月16日 (五) 00:18 (UTC)[回复]

请求协助上传文件 2025年5月16日 (五) 01:23 (UTC)

en:Azur Lane上的游戏插图。如果有人帮忙上传简中/繁中版插图就更好了。--__Don't bite! 2025年5月16日 (五) 01:23 (UTC)[回复]

您拥有上传图片的权限，可截图后自行上传，或于enwiki下载后上传。--伞木 霙留言 2025年5月17日 (六) 06:30 (UTC)[回复]

请求协助导出文件至维基共享资源 2025-05-16 11:10

2018年重庆万州公交车坠江事故的事故现场照片。该图片为对向车辆行车记录仪的影像，固定机位拍摄，符合PD-Automated的定义，属于公有领域。

本人尝试截取中新社视频里面的图片并上传，但是奈何码率太低导致图像太糊，且文件描述里面的来源视频（YouTube ID：W6N_Z5n4Da8）已经失效。故希望能有人协助导出分辨率缩小前的事故照片至维基共享资源，谢谢！--4084470 0.smil（留言） 2025年5月16日 (五) 11:20 (UTC)[回复]

BBC报道有同一帧的稍大尺寸图片。视频。--YFdyh000（留言） 2025年5月16日 (五) 11:56 (UTC)[回复]
感谢提供，已上传 并在条目中添加，且在原图片页面提交了速删请求。--4084470 0.smil（留言） 2025年5月16日 (五) 12:28 (UTC)[回复]

翻译是否可以用机翻

我想知道的是如果需要按照来进行扩充，但是扩充的内容被回退了，原因就是因为机翻，那我要问一下，是不是从外语维基百科扩充时是否可以用机翻，麻烦回答道这个问题，谢谢。--Peterxy12（留言） 2025年5月17日 (六) 07:01 (UTC)[回复]

请停止使用任何大语言模型或者机器翻译提交混乱不堪的内容。你在 meta 及本地提交的翻译已需要多人为你擦屁股，此等行为不但对项目没有任何贡献，反而需要额外的人力来为你善后。如果你的母语并非中文，请在中文水平达到一定程度后再来编辑中文维基项目；否则请解释为何上面的留言病句连篇，甚至连封禁申诉都使用 LLM 来生成申诉理由。--广雅 范★ 2025年5月17日 (六) 07:17 (UTC)+1 [回复]
我的母语是中文，上面留言是我自己写的，不是AI生成的--Peterxy12（留言） 2025年5月17日 (六) 07:22 (UTC)[回复]
那你之前的封禁申诉呢？--广雅 范★ 2025年5月17日 (六) 07:27 (UTC)[回复]
也是我自己写的--Peterxy12（留言） 2025年5月17日 (六) 07:32 (UTC)[回复]
理论上只要你翻译质量令人满意，没人在乎。但你要是质量不过关那不管你用不用机翻都该被回退。——Mirfaek 2025年5月17日 (六) 07:19 (UTC)[回复]
怎么证明质量不过关--Peterxy12（留言） 2025年5月17日 (六) 07:23 (UTC)[回复]
如果你甚至不知道你的翻译质量有问题，那么我求你别碰翻译了。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月17日 (六) 08:47 (UTC)[回复]
确实，但如果上面出现了粗劣翻译的提示，那是否都要使用G13？--Peterxy12（留言） 2025年5月17日 (六) 10:19 (UTC)[回复]
你爱怎么用没人管你，只要不要其他人会觉得你这是机翻文字就好。--SunAfterRain 2025年5月17日 (六) 10:37 (UTC)[回复]
怎么判断是否使用机翻呢？--Peterxy12（留言） 2025年5月17日 (六) 14:54 (UTC)[回复]
如果你需要扩充大批量机翻的内容的话，建议先把翻译出来的内容临时存储到个人沙盒里面，然后自己检查一遍，确认翻译内容准确、语句通顺、没有重大失误后再添加到条目里面。
举个栗子，我大学搞毕设那会儿需要参考几篇讲混凝土泌水的英文论文。“泌水”的英文是“bleeding”。然后我把相关论文提交到谷歌翻译进行翻译的时候，所有的“bleeding”都被翻译成了“流血”或者“出血”，就，，，
所以说在不加以检查的情况下就往条目里面添加扩充机翻的内容，确实是不负责任的行为。--4084470 0.smil（留言） 2025年5月17日 (六) 15:07 (UTC)[回复]
补充，如何在个人页面下面创建子页面可以参考Help:用户页。理论上只要子页面不涉及人身攻击、侵权文字、广告推销或者其他什么严重的问题，都是可以的。--4084470 0.smil（留言） 2025年5月17日 (六) 15:10 (UTC)[回复]
那是不是用机翻必定会回退--Peterxy12（留言） 2025年5月18日 (日) 13:19 (UTC)[回复]
并不是所有机翻都会被回退。你可以用机翻，但问题是读者能否读懂你的译文。内容翻译工具限制延伸确认以下的用户只能放草稿是有原因的。如果你不太确定大家如何文章的翻译品质或是否机翻的话，请读通维基百科:翻译腔这篇论述、还有里面的实例说明。里面有说明常见的翻译错误。如果想找相关的翻译论述看，也建议去。--Saimmx（留言） 2025年5月19日 (一) 07:07 (UTC)[回复]

帽子收集狂中的跨维基帽子收集狂是否包括跨语种

由于之前我不了解权限申请的基本要求，所以申请了很多不必要的权限；但在维基百科:帽子收集狂中的跨维基帽子收集狂中，并没有提及跨语种，希望能回答这个问题，谢谢。--Peterxy12（留言） 2025年5月18日 (日) 00:13 (UTC)[回复]

那你觉得呢？——暁月凛奈 (留言) 2025年5月18日 (日) 00:56 (UTC)[回复]
我不知道跨维基帽子收集狂是否包括跨语种--Peterxy12（留言） 2025年5月18日 (日) 01:00 (UTC)[回复]
请阅读并理解请确定您有真实的需求再申请权限。--Python6345（查论编） 2025年5月18日 (日) 01:51 (UTC)[回复]
你说的没错，那前面提到的为什么没有跨语种帽子收集狂呢？--Peterxy12（留言） 2025年5月18日 (日) 02:05 (UTC)[回复]
(！)意见，我个人认为，各语种维基百科自治，九龙治水、各管一滩，东海龙王不会去管西海龙王的业务。
按此理，中文维基百科社群人员，通常只会管中维发生的事情，这也包含meta元维基，属跨维基语种的上辖阶层，所以中维也会参看一下那边的申请情形。来辅助判断是否属于“Wikipedia:帽子收集狂”。
至于，英语维基百科、日语维基百科、或其它任一语种，这些其它语种维基百科，和中文维基百科是平行职权机构，互不隶属。
中维这边社群人员若没在该语种维基百科活跃，自然也不晓得你在那边语种搞了什么活，也不会特地去该语种调查你申请了啥，大家都很忙，通常仅会聚焦在自己活跃语种维基百科所发生的事。
阁下若在这些语种百科，假设若仍旧申请一堆权限，这行为是否属于他们眼里的“Wikipedia:帽子收集狂”，则要看那些语种之当地社群人员，对你这类行为的自行认定。每个语种的社群人员有他们自己的玩法（社群认定、规定），各语种之间不见得会相同。--Znppo（留言） 2025年5月18日 (日) 02:29 (UTC)[回复]
既然在meta元维基上的权限申请别人会知道，那如果是从其他语种百科申请的权限是不是也会被知道？--Peterxy12（留言） 2025年5月18日 (日) 02:37 (UTC)[回复]
当然，只要看你的全域贡献就好了。--Sakurase留言 2025年5月18日 (日) 02:44 (UTC)[回复]
(！)意见，全域贡献仅能查到你已申请到的权限，正在申请中的权限“无法显示”。--Znppo（留言） 2025年5月18日 (日) 02:49 (UTC)[回复]
谢谢提醒，我没说清楚，是点进去看他其他维基的贡献纪录有没有在权限申请页进行申请的编辑。(如meta:Special:diff/28531763)--Sakurase留言 2025年5月18日 (日) 02:57 (UTC)[回复]
(：)回应，meta是管底下各语种维基百科，属上辖阶层，自然中维人员会多关注这边。
至于其它语种维基百科，你如果在该语种搞了什么活，想要查你的人，还要翻到该语种看你那边的编辑贡献，调查你到底作了啥事，然后再回到中维回报调查结果。没啥人有那么闲时间。
除非你是在该语种被封禁，在使用者贡献里，会自动显示著全域封禁，可以直接看到你在哪语种被封。--Znppo（留言） 2025年5月18日 (日) 02:48 (UTC) 👍1[回复]
阁下为什么要执着于知道不知道呢？我说过了，用常识想想申请权限有没有用。重点不在我们知不知道阁下有没有申请其他权限，而在于阁下是否确实有需要使用该权限，以及能否谨慎的使用该权限。--1F616EMO（喵留言～回复请ping） 2025年5月19日 (一) 09:06 (UTC)[回复]
自己用常识想想您申请的权限有没有用。只要过多或故意的申请无用或明显不可能成功申请的权限就是帽子收集狂。--1F616EMO（喵留言～回复请ping） 2025年5月18日 (日) 02:17 (UTC)[回复]

请求协助移动条目“和平旗”至主命名空间

发起人此前已在WP:互助客栈/条目探讨发起：
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

大家好，

我在使用者空间建立了一个条目：User:WUXIAOTONG Bancy/Peace flag，内容为英文条目Peace flag的翻译版本，条目已补充参考资料、图片、分类等内容，格式也符合中文维基百科标准。

因我目前权限不足，无法将页面移动到主命名空间。烦请有权限的编辑者协助我将该条目移动至主命名空间，标题为“和平旗”，并帮助添加与英文条目的跨语言连结（Wikidata 绑定）。

非常感谢！--WUXIAOTONG Bancy（留言） 2025年5月18日 (日) 03:26 (UTC)[回复]

@WUXIAOTONG Bancy：我在“条目探讨”说的是下次请在此发起……而不是已经发起后再在这里开个话题…… ——自由雨日🌧️❄️ 2025年5月18日 (日) 03:30 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

Land Run

请问条目Land Run（英语：Land Run），也就是电影远离家园末尾千军万马争着圈地的高潮戏，所展现出的行为，到底该叫什么名字？还是直接用Land Run建立条目？

注：此处原有文字，因为广告宣传，已由1F616EMO（喵留言～回复请ping）于2025年5月19日 (一) 05:50 (UTC)删除，尚祈见谅。若有异议请至互助客栈或向管理员反映。[回复]

--2603:8000:500:FB00:F00F:E42E:F3D1:FA8F（留言） 2025年5月19日 (一) 04:44 (UTC)[回复]

请勿在维基百科宣传。另若阁下不确定中文名，亦可先使用英文名按WP:建立条目流程建立草稿，待审核转正前再检查是否有可用中文名。1F616EMO（喵留言～回复请ping） 2025年5月19日 (一) 05:50 (UTC)[回复]
wikidata写说是“土地抢占”。可以试试看。--Saimmx（留言） 2025年5月19日 (一) 07:12 (UTC)[回复]
私以为不妥。Wikidata上面的译名未必有来源，我之前写海水吸入综合症的时候就被坑过一次。如果没有可靠来源译名，用英文也是可以的，参NC:USECHINESE。--1F616EMO（喵留言～回复请ping） 2025年5月19日 (一) 15:03 (UTC)[回复]

如何加作品列表于条目草稿

请教：一个人物的作品列表或大事纪该如何正确地加在其人条目的末端？谢谢。--Allpeoplearepeopleofcolor（留言） 2025年5月19日 (一) 17:03 (UTC)[回复]

关于作品列表，请见Wikipedia:作品列表；关于大事记，建议使用散文形式写作，见Wikipedia:格式手册/嵌入列表 § 散文与列表。无论何者，都只能够记述Wikipedia:可靠来源中的记载。--1F616EMO（喵留言～回复请ping） 2025年5月19日 (一) 23:47 (UTC)[回复]


条目探讨

参考资料

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

这些角色列表通常是昔日从各自虚构作品的主条目里分割出来的。用角色列表的条目名去反证关注度不足，根本是找错方向，要找至少也该用各虚构作品的名称去找吧？
还是各位想看到此分类的角色列表，通通合并回主条目呢？
就算要挂模板，也应该改挂{{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)[回复]
你对ACG方面不熟悉，那你就不要搞人。无来源可以补，但漫画实在不容易，例如，我解绍一个角色整个生平，我需要逐个CHAPTER去引用? 就算是单行本，都可能几十本，这不是小说。--亚历士陈（留言） 2025年5月8日 (四) 17:17 (UTC)[回复]
如果以缺少来源为删除依据的话，Category:缺少来源的条目里面有的是，但有人真的会认真如此？——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[回复]
看到上面又提到因过长而拆分，这些动漫很多主体条目之所以长，根本就是充斥住各种没来源内容，或者大量使用一手来源的，本就应该精简。但ACG在中文WIKI的强势跟其他影视内容是不能比的，其他影视作品条目除非是真正的名作大作，很少会编写到拆分，或者建角色个人条目的风气。--Underconstruction00（留言） 2025年5月10日 (六) 06:55 (UTC)[回复]
来源上，若角色列表只是在主体条目中的一部分，只要长度合理也不是个性分析那种原创，作品自己可以是来源，这原则讨论过多次，如同优良和典范条目的故事大纲就算没来源都可写得很长，故事大纲和角色介绍的比重分配可商榷，以前有这样的意见。但到了拆分条目应该采取更严的标准。我以前也批评过WP:虚构集合的标准太宽松，若有3项事物有独立条目，带上其他10项(用一手/官方或略带提及的来源佐证)，这样还算合理，但带上100项就太过分了。--Underconstruction00（留言） 2025年5月10日 (六) 07:40 (UTC)[回复]

( π )题外话刚在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)[回复]
公海的事，不宜在此讨论。足球小将是一个40多年的漫画，自然多人关注，亦证明真的有人关注。--亚历士陈（留言） 2025年5月8日 (四) 17:12 (UTC)[回复]
但那条拉票的留言应该不是你发的吧......
I mean FB拉票的account叫Alexander Chan, 同你wiki用户名好似......
利申我反对删除。--VAMPIRE!VAMPIRE! All Hands Brace For Shock!Birds Away. Missile intercepted（留言） 2025年5月8日 (四) 21:51 (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)加入。[回复]
此事诸多争议，我认为应该暂时停止处理这些人的提删请求。毕竟要改善都要时间。我都正值考试期间，只能于下班后赶到大学校院温书再回家于此凌晨时份与各位讲几句。修改条目之事，需要以月计。就足球小将角色列表条目本身，十年时间花了不少人心机去写，不是你说给30天删除就删除的，那个条目累积60万浏览数，也不是少数目。所以做事不是那么死板，我非常同意。--亚历士陈（留言） 2025年5月8日 (四) 17:27 (UTC)[回复]
我倒也不反对暂时将现有条目留在条目空间，因为我今年早些时候重写参孙也是把发臭的旧版本留在了条目空间；只是这样做的前提是确实有进度，且可预期一两个月内完成，免得搁置太久，最后不了了之。足球小将角色列表也可以比照办理，先开草稿页重写，之后再决定是剪贴移动并保留历史（例如U:1F616EMO/条目存档/参孙）还是合并历史（可以直接去你维御用历史合并员Iokseng的讨论页，会比较快）。不过该列表目前是爱好者内容和原创研究的大杂烩，后者难以辨别，私以为可以先清理前者，至少给这篇条目恢复百科性，服务我们应该服务的读者。诸君若有心完成，实在是一大乐事。--1F616EMO（喵留言～回复请ping） 2025年5月8日 (四) 23:44 (UTC)[回复]
本来不想就这话题插嘴，但牵涉对批量提删手法的讨论，又有香港网民的题外话，不吐不快。
一如以往，我对缺乏体谅的批量提删心态有所反感。当然，我在意的是那些因来源不够而要删除的条目。这些子页型列表爱好者内容、琐碎内容太多，不是单纯地以补充来源去解决。
这是一个我以前较情绪化的留言：“之前我曾经在一个批量提删建议以专案慢慢处理，曾被指意图拖延。找一大堆条目来提删要多少时间？一小时够认真了吧？找来源会是相同的时间吗？因应条目的篇幅，说不好是百倍千倍。对于漠视这个压力的人，我近来愈发觉得自己也不需要予以任何尊重。”还有一次在Wikipedia:页面存废讨论/记录/2025/01/06#杨政龙较冷静地具体阐述过自己的看法：“问题还是出于以往屡次提及的人手比例失衡，纯粹按照当前内容判断哪条目有有问题（连可回退版本也不管，且也不会有机制追究提报失败），是轻易和快速的，深挖是更需经验及花费很多时间的，就算一半人做前者一半人做后者，已经是比例失衡了，后者需要比前者多数倍的人手。……只谈WP:REQUIRED，前者可以选择今天什么都不干，但也可以选择随时一口气作大量提报，而后者则必须跟随其节奏去跟进，当然后者也可以选择，选择躺平不管那么多。……那可不可以作一个改善计划，让别人不用跟着你的节奏去行动。尤其一口气作数量庞大的提报，一两个月好像时间不少，但你是义工，别人也不是全职维护维基的，试问每星期实际能拿出多少小时。……不过，对于上文我说的节奏问题，也不是这样简单，我可以作一些更具体、实战的举例。……这种细致却又对找来源效率有重大影响的经验，只有真正的熟悉者才会提出，并不是热心看条目和参与站务就能累积到的，所以主张批量提删前应先发起讨论。”初步评估条目应怎样挂板，只是门槛颇低的任务，甚至我们也不会要求批量提删的人必须展示自己对该类话题有多认识。而可以负起改善之责的人必须有足够能力与精力寻找来源，门槛高。愿意来维基担当前者的人很多，担当后者的人似乎越来越少了。坦白说，我认为一个后者的价值是一个前者的十倍百倍，应更注意后者的感受。从上文提到的哆啦A梦神奇法宝列表挂板之例，还有同期周深歌曲挂板的争议，可见门槛低、代价少的前者批量提报屡有追求效率而不耐心检视的情况，而这些常显得冰冷与官僚的行动，真的会影响后者的情绪与士气。维基人手不足，与这种风气有一定关系。另外，杨逸德与导演大全那事也反映了维基众生平等地讨论，还要强调礼貌文明，表面上很好，但也是双刃剑，相比一般网上讨论区，有能者花费更多精力在夏天解释什么是冰，更易烦厌，水平不够者因受到温室保护更想留下来，在人手上更易劣币驱逐良币。
对于这些列表，我不反对草稿化一类做法，也认同暂时保留的前题是有人站出来，示范自己能如何改善，有个方案才行。但正如上一段引述，时间应该先由提出改善方案者建议，社群再讨论是否合理，而不是由讲求删除效率的一方来决定。“历史因素”虽然不是永久保留的借口，但中维不是今天才删删删的，具有“历史因素”的条目一定程度上反映了承载的感情较多，在真有改善方案的情况下，应该予以更多体谅。例如如果有人只想改善足球小将，那么一个月内需拿出一定成果，通常来说是合理的，除非有什么特别的方案，来源准备时间较长。但是如果目标是拯救几十个列表，全部完成就不可能一两个月，应该要求在一两个月内先改善个别列表，让社群判断是否继续给予时间。其他意见稍后再发表。--Factrecordor（留言） 2025年5月10日 (六) 14:17 (UTC)[回复]
至于那些香港网民所言，虽然我有时也会思考维基孤芳自赏、不面向“市场”（或下文再说一说），但那些小粉红和反日什么的，只是低劣的上纲上线，无需理会。我在站外曾发表对某著名讨论区如何看维基的观察，正好分享一下。有些网民确是只把维基当作自己的游乐场、后花园，以其他平台任意发表的一套模式去乱编百科，没有好好锻炼编写和争取内容保留的技巧。最典型的笑话就是中维已被港铁公司收买，理据可以是自己夹杂“围方是全香港唯一一个要求顾客以“𨅬”或“爬”方式进入的商场”等等的版本不获接受。某天一个极敏感政治话题的香港相关条目被一个中国内地用户大幅修改，在一些网络社群间有人开始讨论，我注意到其中一个讨论区的帖子，不少人在说维基被内地立场渗透，却对这个长期半保护的条目表现得无能为力，数小时后有管理员恢复了旧版本并暂时全保护，此结果不久也传到那个帖中，并且也有人去介绍2021年维基媒体基金会针对中文维基百科的行动一事，但那个帖并没有热烈庆祝，而是明显地迅速冷却、散场。我认为那些讨论区的网民喜欢沉醉于两种浪漫之中，其一是成功地集体追捧或拉倒某人或事，显示自己是有力量的。而对于他们无能为力之处，通常就会归咎于被打压，营造一种悲情浪漫。想像出政治理由，或只手遮天的某大势力，去圆这种悲情。若有人试图泼醒他们，例如维基并没有打压他们的立场，反而是对付过敌对阵营，他们想写的东西被删，有些人连建一个能长期使用的账号都有困难，纯粹就是自己无能，或懒散，或言行偏激到连基本的中立客观都做不到（哪怕是装出来），对这样的真相会尽量冷处理、逃避。但我以前也在WikiProject_talk:电视#关于电视类条目和列表的将来说过：我还有一点经验，其实也值得维基人思考一下（虽然应该有不少人会感到不屑）：维基讲究来源且需要可靠来源，而较为宽松的香港网络大典则容许采用讨论区帖子这种不可靠来源。然而，偶有发现一些条目，香港网络大典列出的可靠来源比维基更关键甚至更多。任何学术、爱好的最高境界都是能做出原创研究，从这角度我有时会想维基的定位是有点反人性的，但也需要如此。相信“爱好者内容”这一块，外面必存在更多受不了维基限制的能人。--Factrecordor（留言） 2025年5月10日 (六) 16:26 (UTC)[回复]
  • @Ericliu1912：（87344095）我未见到本讨论是“政策讨论”，至少肯定不是在讨论虚构事物的收录标准；而主要是在讨论提删本身——发起人的留言显示其不熟悉基本指引，例如“notability不能继承”等等，显然不是意在正式讨论收录标准本身的问题，只是类似提问或闲聊；后面的留言我一时也根本找不到哪讨论收录标准了。因此删除了你加的存档模板。你又在未回应我这条留言的情况下做了一样的事情（这里主要涉及第一句话，“硬凑相关页面”。）另@1F616EMO看有没有什么意见？ ——自由雨日🌧️❄️ 2025年5月20日 (二) 00:42 (UTC)[回复]

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

众所周知，已封用户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[回复]
抱歉，我不会像十九君那样客气。此事及日前看见京剧名剧目龙凤呈祥 (京剧)报不满足收录标准，让我对糯米花的判断力及知识水平十分失望，世事不是有善意就足够。而且，已参加评选条目显然与生米一粒的风格截然不同，不去了解发生过何事，然后只用挂板来发表看法，绝对不是好手法。--Factrecordor（留言） 2025年5月9日 (五) 13:22 (UTC)[回复]
@Sinsyuan：据方针WP:讨论发起位置“讨论结束后亦应让讨论原地存档，避免重复在多个页面存档后出现讨论分支。”，我移除了你添加的{{存档至|Talk:周深|WT:收录标准/音乐}}模板，也请之后不要再添加了。若需留讨论记录可以向这些信息框的讨论页发送讨论通告来链接。 ——自由雨日🌧️❄️ 2025年5月8日 (四) 06:51 (UTC)[回复]
@自由雨日@Sinsyuan，这和Wikipedia:互助客栈/条目探讨#关于各虚构作品的列表因为关注度被大量提删差不多，何以不存档至Talk:周深？例如很相似的凤飞飞专辑讨论也是存档至Talk:凤飞飞。--Factrecordor（留言） 2025年5月11日 (日) 01:58 (UTC)[回复]
囧rz……原本我有设定本讨论{{存檔至|Talk:周深}}，后来被自由雨日移除后提及我了。--Sinsyuan✍️ 2025年5月11日 (日) 02:01 (UTC)[回复]
@Factrecordor：上方已说明，“据方针……”。“凤飞飞”当时方针还没有正式通过虽然试行案中也有一样的表述，但相比“发起位置”，存档相关内容不太被编者遵守，只有路西法人等几位在留意，当然于理也是不应存档的（否则方针不会用强硬的“应”措辞）。详可见此，存档会导致讨论分支等问题；如果要“留讨论记录”的话，在“talk:周深”发个讨论通告即可。 ——自由雨日🌧️❄️ 2025年5月11日 (日) 04:51 (UTC)[回复]
在多个页面存档造成的问题能理解，我以前也对此疑惑，感谢你们完善。但只存档至其中一个（如talk:周深），何以会出现分支？像Wikipedia:互助客栈/条目探讨#唐五代十国、宋辽金元的皇帝谥号也是存档至某一个talk。像关于各虚构作品的列表因为关注度被大量提删及Wikipedia:互助客栈/条目探讨#Alzheimer's 台湾用语，更预设了存档至两页。究竟他们有何分别？--Factrecordor（留言） 2025年5月11日 (日) 05:48 (UTC)[回复]
@Factrecordor：如果讨论内容只涉及单一条目或同主题的多个条目，那么应当在条目讨论页或专题讨论页发起（若错误在客栈发起，直接移过去便是）；如果讨论内容涉及多个主题的条目或未有条目，那么在客栈发起——由于“涉及多个主题的条目或未有条目”，那么自然没有理想的单一存档位置。“talk:周深”应当主要讨论或记录关于《周深》这个条目（即“如何为周深这一人物撰写传记”）的讨论内容，而这里讨论的周深歌曲和《周深》条目关联其实已经不大了，和“cat:周深歌曲”、通用收录标准、“WP:收录标准/音乐”、单个周深歌曲条目先前笔误，漏了“歌曲”两字。意指所有讨论涉及到的周深歌曲。 2025年5月11日 (日) 22:04 (UTC)等等均有关联，那么自然不适合存档至“talk:周深”。（但可以在“talk:周深”发一条讨论通告，表示客栈有过这一讨论，供编者查阅。）不过如果未来有“PJ:周深”，那我觉得完全可以存档至“PJ:周深”（或者直接在“PJ:周深”发起讨论）。“talk:周深”和“PJ:周深”区别很大。
“#唐五代十国、宋辽金元的皇帝谥号”我的理解是他其实涉及单一主题（中国主题）条目，其实理应在“中国”专题发起，但目前客栈压力不大，也不必“严格执法”，在这里讨论然后开放式地（不关闭讨论）“存档”过去即可。可以理解为是“延后了移动时间”。“#Alzheimer's 台湾用语”我之前也有留意，我认为存档至两个位置是不合适的，我是想等待讨论一段时间后看看如何处理更好（移到某个位置然后在另一页面发通告，或是存档到“PJ:医学”，或是原地存档，等等）。 ——自由雨日🌧️❄️ 2025年5月11日 (日) 06:51 (UTC)[回复]
原来如此--Factrecordor（留言） 2025年5月11日 (日) 11:57 (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)[回复]
反修例太长了，我筛了一下主条目基本上没有什么模板可以替换了（除非把cite改成invoke？）。这个条目也应该精简，特别是一大堆没有用的图片，还有什么东西都往里面塞的资讯框。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月10日 (六) 04:55 (UTC)[回复]
直接在一层源码引用图片和表格等并不会影响展开量，主要是关注模板。一些条目（类似反送中运动、中华人民共和国）使用cite模板注引，正常编写条目后注引数接近800+，会容易遇到模板扩展限制，这类情况需要重新提炼一些章节的内容作为更短的章节描述，然后分拆这部分内容到内容覆盖面更细化的拆分条目中。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月10日 (六) 06:10 (UTC)[回复]
还有一类是noteTA，像电影、电影作品、地名等，量大但对应相应条目并不需要那么多相应转换，有点高射炮打蚊子，需要抽简一部分转换出来而不引用这些“大炮”。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月10日 (六) 06:13 (UTC)[回复]
英维出现了一种<ref>{{#invoke:cite news|}}<ref>的引用方式，在en:Gaza war有700+参考文献的情况下也不会出现模板爆炸的情况，不过本地这么使用会报错（可见加沙战争），如果有效的话可考虑配置到本地。--东风（留言） 2025年5月13日 (二) 07:04 (UTC)[回复]
英维现在计划删除en:Module:Cite news、en:Module:Cite web等模块，使用en:Module:Cite代替。--Kcx36（留言） 2025年5月13日 (二) 07:11 (UTC)[回复]
中文和英文的Module:Citation/CS1不同，Module:Cite news、Module:Cite还需要修改才能用。--Kcx36（留言） 2025年5月13日 (二) 09:06 (UTC)[回复]

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

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

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

MOS:信息框旗帜，另见该指引的讨论页。--YFdyh000（留言） 2025年5月5日 (一) 13:35 (UTC)[回复]
那岂不是和MOS:NATL冲突？--自由米花🌾🌼 2025年5月12日 (一) 18:50 (UTC)[回复]
怎么会冲突呢？不用带有旗帜的模板不就好了。--Cygz（留言） 2025年5月12日 (一) 20:44 (UTC)[回复]
如果是体育竞技等赛事代表的国家/地区，仍建议添加旗帜模块。该方针是参照英维翻译而来。--Cygz（留言） 2025年5月8日 (四) 18:22 (UTC)[回复]
@YFdyh000、Cygz：谢谢两位指教，原来信息框的人物信息本来就不应该挂国旗的，只是大家都不遵守罢了。。。--侧耳·倾听 2025年5月10日 (六) 08:45 (UTC)[回复]

Alzheimer's 台湾用语

本主题或以下段落文字，在讨论结束后应存档至Talk:阿兹海默症。

“阿茲海默症”才是“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)[回复]
也有叫阿尔茨海默症的，比如：1，2，3--Fthasdd（留言） 2025年5月15日 (四) 23:06 (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)[回复]
那就差港澳方面的通称了。给了以后我有空就把条目改改。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月9日 (五) 15:00 (UTC)[回复]
@Ericliu1912管理员，@Sohryu Asuka Langley Not Shikinami有做回应（Special:Diff/87193154），香港的通称是“阿茲海默症”。我找了几个香港新闻网站（香港01、大公文汇网、明报新闻网），这看来确实是最普遍的用语。--Seanetienne（留言） 2025年5月9日 (五) 15:16 (UTC)[回复]
传媒可能不太够，需要一些辞典或医学文献。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月9日 (五) 18:18 (UTC)[回复]
香港的话，单说“阿兹海默症”就挺多实例的，港怡医院卫生署港大医学院港中文医院立法会。--Hamish T 2025年5月10日 (六) 10:28 (UTC)[回复]
通知这里被提及的当事用户@Yyfroy： ——自由雨日🌧️❄️ 2025年5月11日 (日) 13:54 (UTC)[回复]
看在老友份上，说明本人立场：
1. Parkinson's disease dementia（PDD）[13] 要翻译成：【帕金森氏“症”失智“症”】吗？另外，为何称失智症？不称失智病？是因为太多脑部疾病可以引发此症，反之，帕金森或阿兹海默两医学家发现的疾病是很特定的疾患。
2. 病 [14] 、症 [15] 、教育部词典 [16] ，都有明确的定义，从来都没有什么“syndrome才能翻成“症””这种说法。
3. 医学的原理如下：人体不知为何不舒服或不正常而有了“症”，再去找是什么“病”引起的“症”，有时可以发现有一大堆“病”都可引起此“症”，有时却是新的未知“病”引起此“症”，必须新定名称。道理很简单，大家都懂，有正确的术语可以使用 [17] 不用，却要选择人云亦云的名词？并非绝对不可，但条目名宜谨慎使用病名，再附注：常称“某某症”，较符合科学严谨的精神。此处翻译成“某某症”的这些人士，真的有认真思考过术语的精确性吗？还是新发现的疾病还未命名，先给个症称呼一下，然后就因循下来。
4. 科学的研究或真理，不是靠票选决定出来的。Yyfroy（留言） 2025年5月13日 (二) 06:10 (UTC)[回复]
基于维基百科的命名原则，“阿兹海默症”属常用名称，而此名称是否严格或绝对准确，则是另一回事。又此一病症发现已百年，众多来源（包含各种医学或官方文献）仍然沿用，显然并非纯粹因循成例可以解释。毕竟本站的目标并非正名，而是反映人类现有知识的总和。若确有来源指出“阿兹海默症”一词谬误之处，仍尽可注释于条目中，本人相信不会有人阻拦。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月13日 (二) 14:11 (UTC)[回复]
如果您是台湾医界人士，应知道平时同事沟通病名与打字都用英文术语，中文病名根本没医师会重视，就算有正确名称来源摆在那里，也是不予理会，大家说什么中文名词就跟着说（医师也是会人云亦云的），毕竟只是说给民众听的。
拿个最常听到的例子，国际上GOT/GPT不知已废了几年，结果，还是有医师用此说给民众听，而且几乎没人能说出中文名，想怎么翻译就怎么翻译；ectopic gland翻译成异生腺体，tonsil早已证明非腺体但仍说扁桃腺，例子很多。并不是能翻译正确有多了不起，而是不能翻译或错误翻译却毫不在乎，明明有正确术语放在那里，懒的理。是“病”是“症”，有很重要吗？自然不会有医界人士提出论文讨论。Yyfroy（留言） 2025年5月14日 (三) 06:51 (UTC)[回复]
如果有来源指出“阿兹海默症”一词亦存在此一现象，可以写入条目。此外，亦可考虑致信有关机构，表示其“偏差译名”应予调整。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月15日 (四) 03:40 (UTC)[回复]
感谢@Yyfroy君愿意阐述论据，可以理解这种不平的心理，还有捍卫心目中“最准确”名称的使命感，毕竟我也有过（“Volodymyr”的中译）。然而，维基百科的编纂原则是述而不作，求描述（description）而非规范（prescription）。在这里，即使与压倒性多数背道而驰，仍从事硬操作，就是明显违反原则了。您在tonsil那里的操作亦然（提醒：“扁桃體”似乎也是大脑“杏仁核”（amygdala）的别称之一）。--Seanetienne（留言） 2025年5月15日 (四) 16:25 (UTC)[回复]
已经修改有关条目及公共转换组，并补充几种别称于条目资讯框。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月13日 (二) 06:02 (UTC)[回复]
据方针WP:讨论发起位置，本讨论应属于“影响多个属相同主题”的条目，其实理应不该在客栈发起。不过由于客栈压力不大，我之前一直未移动；但存档至多个位置是方针所禁止的。由于看争议主要发生在公共转换组，我删去了至“talk:阿尔茨海默病”的“存档”，等讨论完成会移动至“Module talk:CGroup/Medicine”，相当于延后了移动时间。若需在“talk:阿尔茨海默病”留记录可以在那里发送{{讨论通告}}。（另见这条留言。） ——自由雨日🌧️❄️ 2025年5月15日 (四) 05:25 (UTC)[回复]
反了，应该是要存档至“阿兹海默症”条目，这本质上涉及条目命名，转换组是其次（至少也是随条目而连动）。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月15日 (四) 05:41 (UTC) 👍1[回复]

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

浦东新区、滨海新区在中文里最后一个字是区，因此不太存在和区相比的分辨。然而“新区”似乎是一个整体性的专有名词，似乎不应被视为市辖区。前者在英文里对应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）、[18]，浦东新区、滨海新区是市辖区。根据[19]，行政区划名称没有官方英文名，只有官方罗马字母拼写（汉语拼音）。--Kcx36（留言） 2025年5月6日 (二) 15:13 (UTC)[回复]
附议K君。同时我也重复一遍，阁下列举的浦东新区、滨海新区现时皆为行政区划上的市辖区。这两个区是有行政区划代码的。您不必纠结这两个区，您要纠结的是湘江新区等这些没有行政区划代码的“新区”，所以您要纠结的问题是条目内如何标注这些区域的属性吗？--Hamish T 2025年5月6日 (二) 19:36 (UTC)[回复]
不用太纠结英文和历史问题，现在这俩地方四套班子齐全，而不是什么管委会之类的，行政区划也没有和别的地区有重叠，就是正经的市辖区。--侧耳·倾听 2025年5月10日 (六) 08:50 (UTC)[回复]

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

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

以往中华民国行政院新闻局对其审查的书刊赋予编号——登记证号，此非国际标准书号（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)[回复]
那么请问今后在维基百科，“公映许可”／“发行许可”的编号等是应当不再向读者显示，抑或是继续显示？（不显示不等同清除）--— Gohan 2025年5月12日 (一) 09:08 (UTC)[回复]
@YFdyh000@糯米花--— Gohan 2025年5月16日 (五) 08:06 (UTC)[回复]
不显示很容易被顺手清除，所以如果打算不显示，建议先迁移数据。--YFdyh000（留言） 2025年5月16日 (五) 09:31 (UTC)[回复]
如未有人手动搬运或编写机器人，一时间难以迁移。粗查甚至不见相应数据项，也不了解数据项需要何种条件方可开设。所以如果迁移之后方可不再显示，那么不再显示会是遥遥无期。“顺手清除”大概不会发生；只要不设为未知或废弃参数，一般无人留意。--— Gohan 2025年5月19日 (一) 08:26 (UTC)[回复]
据方针WP:讨论发起位置“讨论结束后亦应让讨论原地存档，避免重复在多个页面存档后出现讨论分支。”，移除{{存档至|Template talk:电影信息框|Template talk:电视节目信息框|Template talk:Infobox book}}模板。若需留讨论记录可以向这些信息框的讨论页发送讨论通告来链接。 ——自由雨日🌧️❄️ 2025年5月6日 (二) 11:39 (UTC)[回复]
明确标记讨论关闭以后，理当可以存档多处。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月9日 (五) 14:59 (UTC)[回复]
@Ericliu1912：然而如果讨论位置发起正确的话，在互助客栈发起讨论内容理论上并不涉及特别的条目等页面，如果要存档，估计大概率会是“硬凑相关页面”吧？这似乎没有必要。然后是，大部分互助客栈讨论均不会特意有人去标记讨论关闭，所以在关闭前就加模板的大概率最终结果就是以开放形式直接存档（这一句说明在确认关闭前默认不标存档位置的合理性）。其次，即便是关闭的情况下存档，只要没有进入正式的“存档页”，通常仍然可以在关闭的框外留言（例如此例），这仍然会造成“在多个页面存档后出现讨论分支”的问题。最后，“存档至客栈”仅占一处存档空间，而“存档多处”则将同一讨论复制多份，这似乎同样没有必要。我的理解是存档的最大作用是可以让编者点击讨论页时知道“关于这个页面，曾经有过这一讨论”，而这未必需要通过复制所有内容的存档来实现，也可以通过{{讨论通告}}来实现（要再方便的话，等内容存档至互助客栈存档后，再在讨论通告下方留一条言给出至存档的链接，这样就更清楚了）。综上，存档有多种弊端且似乎难以完全解决，而存档的好处则可以通过其他方式（讨论通告）来实现。 ——自由雨日🌧️❄️ 2025年5月10日 (六) 10:10 (UTC)[回复]

是否加入球形地图

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

@Gdagys：WP:ENWP!，当然你可以在WP:MOS找找有没有社区共识。--__Don't bite! 2025年5月14日 (三) 12:52 (UTC)[回复]

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

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

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

——{{Unreferenced}}

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

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

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

——{{BLPsources}}

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

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

——{{Unreferenced}}

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

——{{Onesource}}

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

——{{Refimprove}}

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

——{{BLPsources}}

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

(＋)支持，之前完全没想到这一点，我觉得想法非常好。另外看到这一提案，我个人主要想到的理由倒没有“要求‘将可靠来源的各个主要观点都写下来”那么强（当然这绝对是最应该做的事），我想到的是：无来源内容大多是编者随手写的低质内容，本身就并非是来自于可靠来源，因而改善途径自然不应是“找可靠来源去生拼硬凑地来佐证原本就并非出自可靠来源的表述”，而是重写。 ——自由雨日🌧️❄️ 2025年5月8日 (四) 13:20 (UTC)[回复]
(！)意见 大部分是需要基于可靠来源证明并重写或改写完善，但有些表述确实只需补上有效来源即达标（如新闻报道），引导“重写”是非必要的。所以表述中性一些为好，如请基于可靠来源改善这篇条目、请补充可靠来源以改善这篇条目。
Unreferenced变成{{重写}}是不必要的。Onesource并非第一手来源而是唯一来源，如依赖单篇报道。“重写目前无法查证的内容以改善这篇条目”可能错误引导，某些可能该移除而非重写。BLP“将被立即移除”长期未有做到，是否有必要改说“应被”（理应、引导）或者“可能被”（警示，符合事实）？--YFdyh000（留言） 2025年5月9日 (五) 08:56 (UTC)[回复]
不支持“重写”这样的强硬措辞，只能说，虽然我们很期望所有条目的描述应该有来源引证以满足Wikipedia:可供查证的要求，但基于长期的现实情况，而且这个要求并不是系统技术上的限制，而是业务上的要求而可以被“强制”遵照，不少老旧甚至是涉及基础事物的条目都存在类似的问题。所以这种标示更多是请求去做，而不是要求去做，有时候是Wikipedia:能力亦为必需的情况——有能力尽量去做（补充来源等），没能力的尽量不要弄（至少挂个标示提示，自己动手很多做多错多）。与其纠结于这些标示是否需要更强硬的语气去“驱使”其他人，倒不如自己动手先逐点解决这类已有来源缺的逐个个例，如果连这都做不到，放下，去做其他自己能做的工作，或者至少严于律己也可。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月10日 (六) 03:04 (UTC)👍1[回复]

所以这种标示更多是请求去做，而不是要求去做

这里是要把错误的“请求”修正为正确的“请求”，如果“根据可靠来源重写”的措辞太“强硬”，那么“补充多方面可靠来源”是不是也像一种“驱使”？我们是不是该改成“拜托拜托，能不能加个外部链接습니다，PTT还是知乎都没问题的ありがとうございました”？ ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月10日 (六) 04:17 (UTC) 👍1[回复]
“请协助补充多方面可靠来源以改善这篇条目。”我认为这样的“请求”已经足够。至于你那种乐子话一样的来源“肯求”，你这么喜欢这样的话， 耸肩。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月10日 (六) 05:36 (UTC)[回复]
(：)回应，回复给使用者魔琴User:魔琴，我维的过滤器会挡PTT批踢踢网址，我曾尝试在讨论页贴上PTT批踢踢网址，却一律被我维的过滤器挡下来，不给贴。
所以诚如阁下所言，加个PTT外部链接，在我维上是不可能的，因为早已被我维的过滤器视为“不可靠来源”。--Znppo（留言） 2025年5月10日 (六) 05:46 (UTC)[回复]
是否跑题了？请补充来源以改善，请重写，都可能变成“错误请求”。“重写目前无法查证的内容”是明确但单一解法，排除了补充可靠来源使原有内容可查证的方案，且潜在排除了直接移除无法查证内容的做法。--YFdyh000（留言） 2025年5月10日 (六) 05:50 (UTC)[回复]
也就是除非涉及会影响现实人事的描述，包括一些实体间的评论，指控等类似描述，我认为必须在编写时同时附上来源引注。而其他一部分的条文描述，可能是编辑根据自己确信可靠的来源补充进去，同时未能像某些“严格遵守”规则的编辑那样附注来源。或者说，在没有来源明确彰显下，这些描述无法即时判断为可靠的或者不可靠的描述，可以先善意判断为“可靠”（当然某些编辑不会善意地判断可靠——编辑不同，态度不同，不置评），其他编辑可以从有能力的，即时找到对应的描述并且符合可靠来源的脚注来进行注引、确认到相应来源但判断描述与来源不合后去修正描述、确信没有来源引证描述下声明清楚后移除描述，到没能力的，先加fact，到加维修标注，让其他编辑协助，我认为这才是我们社群应该的善意态度。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月10日 (六) 05:55 (UTC)[回复]
我不赞成要求或请求重写来自于不可靠来源的内容，因为不可靠来源的内容不一定错误。如果有人根据“每日头条”这种内容农场写了句“244497-1是1979年发现的梅森质数”，单就这句话而言，请问如何重写？又为何需要重写？替换成可靠来源是必须的，但重写不是必须的。-游蛇脱壳/克劳棣 2025年5月10日 (六) 07:07 (UTC)[回复]
是否重写按情况而定，没必要预设需重写。--Factrecordor（留言） 2025年5月10日 (六) 09:56 (UTC)[回复]
(－)反对：试问我路过一个条目发现有段文字没来源，然后我自己帮他找到来源，并验证得知别人写的东西没半点问题，我帮忙补好来源就行干嘛多此一举还要重新写一遍？--💊✖️2️⃣3️⃣（留言） 2025年5月10日 (六) 14:37 (UTC)[回复]
我看到许多以“现有文字不一定全然错误”为反对理由的意见，在此统一回应：诚然内文可以有事实，但我们应当无视谨慎对待修改于2025年5月11日 (日) 08:58 (UTC)并质疑一切无法查证的内容。若内文有误，“补充来源”也无济于事，这个改善方式更可能连编者也一并误导，使其采信以偏概全的来源，或断章取义；若内文无误，则应当将无法查证的原文视为巧合，并从来源补充其他观点或更多资讯。因此，所谓“符合来源或事实而无需重写”和“不符合事实而重写”在本质上是一样的，都是寻找来源，并使条目文字符合来源，差别只在工作量大不大而已。--1F616EMO（喵留言～回复请ping） 2025年5月11日 (日) 02:09 (UTC)[回复]
对“应当无视”一语感到厌恶，而且既然“无视”又何用再“质疑”？“无视”就像法庭上证据因通过不当方式获取而不被接纳，陪审团当没见过。有一句名对白：“这里不是法庭，我双眼就是证据。”我们不可双眼就是证据，但也不需变成法庭。抱怀疑态度是应该的，但没来源的内容有时亦未尝不是线索，正常人有能力按不同性质判断，从而决定以哪种程度处理。“应当无视”就算在维基层面也不过是字面上大义凛然，有时未必实际，例如在Wikipedia:新条目推荐/候选#五月风暴对补充来源所作出的正面鼓励也很有用（而没有谁在批判内容）。若在维基以外采取此“无视”态度，更是没必要、可能误事。--Factrecordor（留言） 2025年5月11日 (日) 05:20 (UTC)[回复]
感谢补充，没想到这一点，已经部分撤回。不过无法查证的内容有可能以偏概全，谨慎依然是好的，只是“无视”有点太过火了。1F616EMO（喵留言～回复请ping） 2025年5月11日 (日) 08:58 (UTC)[回复]
不可否认一般无来源内容相对于有来源内容而言更容易引起质疑。然而有的时候有的人写条目附上可靠来源了，都会被别的编者指出条目内容和来源对不上，特别是来源的语言不是中文的时候（典型的就是折毛事件）；而有的人写的内容没有来源，别人检查来源确定内容和来源完全对的上，搞不好加上相关内容的人刚好从那个来源直接复制粘贴的。所以说，我们应该更多鼓励对条目内容和来源进行交叉比对，而且是一视同仁：不管是有来源还是没来源，只要看到内容有可疑就要更仔细检查；不管是扩充内容的同时加了来源，还是为无来源内容补上来源，顺手检查确定内容无误才按“发布更改”的按钮本来都是应有的习惯。--💊✖️2️⃣3️⃣（留言） 2025年5月15日 (四) 01:17 (UTC)[回复]
(～)补充：话说我们还有{{Disputed}}、{{Disputed-section}}、{{TotallyDisputed}}等模板，不管是有来源还是没来源，只要能看出明显可疑，都可以挂上相应的模板，经过更详细的检查之后，要么重写，要么提删。--💊✖️2️⃣3️⃣（留言） 2025年5月15日 (四) 02:04 (UTC)[回复]
“被别的编者指出条目内容和来源对不上”本质上也是“没有任何参考来源”可以证明该断言，所以说的事情是一样的。定期巡查目前有来源的内文是否符合来源是需要的，但完全无来源或明显缺乏来源的条目更容易看出可供查证性问题，故有直接标模板甚至整篇删除之可行性。--1F616EMO（喵留言～回复请ping） 2025年5月15日 (四) 10:43 (UTC)[回复]
你这句话显然并未考虑专业壁垒、语言壁垒等的影响，比如我是接触过不少冷门语言的来源的，什么德语、法语、西班牙语、俄语等等等等，虽然用浏览器内置的翻译功能，勉强能看出来大致的意思是什么，但难免理解上存在偏差，而能够做替代的英文来源又没有，虽然我大多数情况会很谨慎，只把一些有足够把握理解不会出错的部分写进条目里面，但写进去的东西多多少少还是会受到一些影响。到时如果被更厉害的人指出来，告诉我如何纠正过来，我自然觉得是好事；但如果有人说“这个地方跟来源的描述有差异，本质上是没有任何参考来源”，不说其他人看到会怎么想，至少我是相当不爽的，我找个合适的来源去用都要浪费几十分钟的时间，说这种话出来倒是轻轻松松。Cwek说你站着说话不腰疼都算客气的了，巡查的大手一挥就行，写条目的要考虑的事情就多了。--💊✖️2️⃣3️⃣（留言） 2025年5月18日 (日) 03:49 (UTC)[回复]
修订：为免理解误会，移除“（部分撤回）”字样，仅保留删除线。副知@自由雨日。1F616EMO（喵留言～回复请ping） 2025年5月18日 (日) 14:20 (UTC)[回复]
这个提案的概念似乎是为了强调WP:非原创研究，如果是针对非原创研究，(＆)建议调整成"请补充可直接支持条目内容的可靠来源，并重写或移除那些未被支持的内容。"--Rastinition（留言） 2025年5月11日 (日) 02:39 (UTC)[回复]
不全然是。WP:可供查证亦为核心内容方针之一，且我说过了看内文选来源容易出错，建议“补充可直接支持条目内容的可靠来源”因此不太妥当。不过为免万一出现没有常识的编者发现来源符合叙述后执意重写的滑稽状况，或可调整为“请寻找介绍本条目主题的可靠来源，根据来源重写和可靠来源不符的内文，并移除无法查证的文字。”--1F616EMO（喵留言～回复请ping） 2025年5月15日 (四) 10:47 (UTC)[回复]
副知@Liu116--1F616EMO（喵留言～回复请ping） 2025年5月15日 (四) 10:48 (UTC)[回复]
(－)反对，同U:Liu116。此外已经有{{重写}}了。--__Don't bite! 2025年5月14日 (三) 13:16 (UTC)[回复]
{{重写}}是针对整体质量问题相当大的条目，往往不只是缺来源那么简单的事情了。--💊✖️2️⃣3️⃣（留言） 2025年5月15日 (四) 02:04 (UTC)[回复]
所以我说“重写”这个说法有点过度了，因为也存在描述部分能找到对应符合可靠来源的参考，只需要补充来源就可以解决，所以“改善”就能对应这类情况。至于来源质量问题，那是另一回事。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月15日 (四) 07:48 (UTC)[回复]
条目的文字只有两类，一是可以查证的内容，二是不可查证的内容。对于使用WP:可靠来源的文字，自然归于第一类；对于使用低质量来源的文字，则需要看能不能用，如果不能用，和无来源没有任何分别。--1F616EMO（喵留言～回复请ping） 2025年5月15日 (四) 10:37 (UTC)[回复]

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

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

添加上“计划通车时间”是一名匿名用户的贡献。
但是通过观察优良条目北京地铁中未来发展的章节，则发现实际上除了是今年确定开通的线路，其余的通车时间要不是没有来源，要不是计划赶不上变化。而再观察规模比广州地铁更大的上海地铁，则发现其对于线路规划及建设的通车时间的参考来源则更少。而再参考比广州地铁开通更早的天津地铁，其对于未来发展的参考来源中的描述，则更表现出“计划赶不上变化”。
其实现在城市轨道交通的建设已不是十几年前那般迅速，市政工程的计划赶不上变化是常常发生的，社会上有不少观点认为中国的大基建时代已经过去了，地铁的建设也被新的国家标准束缚。
回到广州地铁这方面说，2017年就说21号线会在当年开通[20]，2022年说11号线会在当年开通[21]，而这两条线都因各种原因推迟通车时间，但官方均未确认，仅仅是“预计”、“初定”等措辞。而对于今年开通的几条线路，官方的措辞[22]则没有用预计的词语。
因此，我更倾向于不单独加上“计划通车时间”这一列。如果通车时间已被官方确认，或有相关方的官方回复（如人民网的领导留言板、12345等），则可如该版本或该版本中在土建进度中加以备注。当然，需要一列备注栏以存放参考来源，无论是刚开始建设线路的环评报告等文件，还是确认通车时间的新闻。--Cygz（留言） 2025年5月8日 (四) 18:19 (UTC)[回复]
鄙人未参与相关条目修缮，但据我经验，城市轨道交通的“预计通车时间”大部分比较固定，但也存在变动的情况，建议以各工程环评文件内的通车时间为准，若后续有公告、问政回复等信息确定新的通车时间则以后者为准。--—远方传来风笛（Talk） 2025年5月9日 (五) 05:45 (UTC)[回复]
一般这种工程开工前后都有官方宣传，按照那个来就行，以后明确有新说法再改；规划线路还没开工的没有必要写。--Nanhuajiaren（留言） 2025年5月10日 (六) 10:21 (UTC)[回复]
预计时间通常就不是很准确，建议删除。--自由米花🌾🌼 2025年5月12日 (一) 18:48 (UTC)[回复]
如果有可靠来源引述，可以引述；没有来源明确声明的，建议打fact。例如今年广州地铁10、12已经声明能在今年开通并且报道过的，可以引述来源；13二期的其中一段推测过今年有可能，报道上也是“力争”开通。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月14日 (三) 03:49 (UTC)[回复]

历任教宗译名

某些教宗译名地区词多有不同，或许要修订一下。另外我前几天寄信问台湾地区主教团，他们说自己也参考香港教区的历任教宗名单，所以确定台湾方面的“官方中文译名”当是不能指望了，就看教会或世俗文献常用名称吧（但他们自己文献也到处混用Orz）。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月8日 (四) 17:52 (UTC)[回复]

根据WP:讨论发起位置的要求，已在WikiProject_talk:基督教发送讨论通告。 ——自由雨日🌧️❄️ 2025年5月8日 (四) 17:58 (UTC)[回复]
大陆这边似乎没有规范？不过《世界人名翻译大辞典》提到了一些教皇的译名，可作参考，我前段时间搞了几个重定向。——杰里毛斯（留言） 2025年5月8日 (四) 18:21 (UTC) 👍1[回复]
我随便举几个例子：
Pius PP.：“庇护”、“比约”、“碧岳”等（btw梵二文献全用比约，不用庇护）；
Gregorius PP.：“额我略”、“格列哥里”、“格里哥利”、“国瑞”等；
Clemens PP.：“克莱孟”、“克勉”、“格肋门”、“格来孟”、“格肋孟”、“克来孟”等；
Innocentius PP.：“依诺增爵”、“依诺森”、“诺森”等；
Caelestinus PP.：“策肋定”、“雷定”等；
Callistus PP.：“加里多”、“嘉礼”等；
Nicolaus PP.：“尼各老”、“尼阁”、“尼古拉”等，
多不胜数。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月8日 (四) 18:28 (UTC) 👍1[回复]
在台湾有新教、天主教译名系统，如：彼得／伯多祿；約翰／若望；保羅／保祿。就观察，当代人物使用后者居多，像“方濟各”即属之；“历史人物”像圣徒之类的，则常用前者。--Seanetienne（留言） 2025年5月9日 (五) 15:58 (UTC)[回复]
单就教会文献来看，参考各地的礼仪年历和弥撒经书可以得知部分名号在各地的翻译，特别是封圣的教宗，但无法涵盖全部。根据这篇文章的研究，天主教会内对圣人名称的中文翻译应该至少存在三类，即所谓旧译法，新译法，新教理译法。例如教宗Clement I，参照台湾版感恩祭典和新竹教区2024年礼仪年历可确认为所谓新译法（聖克勉一世教宗等），参照中国大陆版感恩祭典可确认使用了所谓旧译法（圣格勒盂一世教宗等），参照香港教区及澳门教区使用的礼仪年历可确认使用了包含所谓新教理译法在那的其他译法（教宗聖克萊孟一世等）。但这只代表了各地某种程度上的官方翻译，实际民间的使用情况十分混乱，很难说哪一种是在某地真正通用的，因此教宗条目使用地区词转换应谨慎。--立日（留言） 2025年5月9日 (五) 20:47 (UTC)[回复]
香港教区的历任教宗名单有标注来自《台湾地区天主教手册2001》，怎么他们反而说是参考这个列表的呢。不知道最新版手册还有没有这个名单。--立日（留言） 2025年5月9日 (五) 21:51 (UTC)[回复]
不确定是不是同一本，但天主教手册有2024。 --窝法乙烷 儿法梦碎 2025年5月10日 (六) 03:26 (UTC)[回复]
他们那张表还有参阅闻道出版社的“历代教宗简史”（见附录三，第414页起），但这里提供的译名也比较混乱。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月10日 (六) 06:22 (UTC)[回复]
顺便@An Macanese、Jeffchu2014、Will629、Patlabor Ingram，我想模板等讨论确定再直接改转换组比较好。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月10日 (六) 06:17 (UTC)[回复]
这些问题很难有共识的，最后总会造成有些译名会湮没，然后造成另一种霸权。不过当然现在已经出现。但归根究底，有些译名不更改的话，就会销声匿迹，就是如此残酷（和不知所谓，我认为）。--Will629（留言） 2025年5月10日 (六) 14:28 (UTC)[回复]
地区词处理指引规定，“各地中文变体版本对此以“地区词转换”方式显示当地可靠来源的最常用用法。”目前仅就利奥十四世而言，外交部新闻稿已经使用“利奥十四世”名称。由于外交部译名及新华社译名在中国大陆地区的权威地位及中国大陆来源目前的使用情况，中国大陆地区词应使用“利奥十四世”。--PATLABOR 英格拉姆Ingram Talk 2025年5月10日 (六) 14:40 (UTC) 👍1[回复]
『Talk:良十四世#大陆简体模式下是否应当将标题转换成“利奥十四世”？』亦有同样讨论进行，敬请这里的编者留意（有关该教皇的译名可能还是在那个讨论页讨论更好？）。 ——自由雨日🌧️❄️ 2025年5月10日 (六) 14:47 (UTC)[回复]
“利奥”以外的教宗译名可在此处讨论。毕竟通常都涉及几位甚至十几位教宗。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月10日 (六) 17:19 (UTC)[回复]
把我这个澳门人tag来了？据明报的报导，译名可能还真的和澳门有关，且看刘伟杰神父的解释。如参照维基百科:命名常规中“名从主人”以及“先到先得”的原则，那翻译肯定是天主教澳门教区优先啦--An Macanese 2025年5月11日 (日) 17:24 (UTC)[回复]
既然教宗总共二百多位而已（且重复名号貌似仅八十出头），不如先把能找到的译名都找一找，尤其是两岸四地教会文献及政府官方资料，以处理各项单、多向转换。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月10日 (六) 17:37 (UTC)[回复]
抛砖引玉，先参考能找到的各地教会礼仪出版物（主要是感恩祭典和礼仪日历）创建了一个十分有限的列表，但新加坡和马来西亚的情况手上没有可靠来源。注意这些翻译仅在某种程度上代表各地教会官方观点，不代表实际使用情况。能检验的以被封圣因而被列入礼仪日历的教宗为主，而大部分未在礼仪中提到的教宗名号需要其他来源。--立日（留言） 2025年5月11日 (日) 19:07 (UTC)[回复]
我补了香港教区档案“历任教宗”及前述“历代教宗简史”两种资料。大陆方面也还需要文献。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月12日 (一) 09:04 (UTC)[回复]
新加坡的海星报以及马来西亚的先锋报可能可以作为两地用词来源参考，不过整理起来比较麻烦，成果可能也有限。--立日（留言） 2025年5月13日 (二) 13:11 (UTC)[回复]
星马等地译名无需多虑。只要zh-hans、zh-hant用于填写教廷译名，zh-cn、zh-tw、zh-hk等用于填写地区词，正确各司其职，不相干扰混淆即可。例如良十四世，教廷明明译作“罗伯多”，为何会有编者非要写作“zh-hans:罗伯特;”，以zh-hans充当zh-cn？--— Gohan 2025年5月13日 (二) 08:38 (UTC)[回复]
虽然原因不明，但梵蒂冈新闻网改过新闻稿中的译名（简繁版均是）。最早用“多”，后被改为“特”。见8日与12日同一篇报道的存档。因此其他媒体可能两种译名都有在用。--立日（留言） 2025年5月13日 (二) 09:14 (UTC)[回复]
大陆宗教人士使用的译名与世俗界使用的译名应该是不一样的。中国天主教官网[23]没找到什么译名用例，信德网[24]的译名我粗略搜了几个，都与梵蒂冈方面保持一致，不过信德网的主办方是河北信德文化学会，似乎不够官方？我个人感觉宗教界（天主教界）译名在世俗界的影响力不是很大，如“Gregorius”被信德网译作“额我略”，但我从来没在生活中见到过这个译名，见到的一般是“格”开头的译名，如“格里高利”“格里高里”“格列高利”“格雷果里”“格利高里”等（可参见各大工具书“公历”词条对教皇Gregoius XIII）的译名。——杰里毛斯（留言） 2025年5月14日 (三) 13:39 (UTC)[回复]
列举一下《世界人名翻译大词典》收录的教皇、敌对教皇与传说中女教皇的译名，虽然不一定符合大陆的实际使用情况，但应该可以当作参考。删去了解释与“一世”等次序，其中“Sergius I， Saint”为“圣塞尔吉乌斯一世”，“Stephen I-X， Saint”的顺序与本站不同，个人推测是列入了“当选教宗斯德望”。

Boniface 卜尼法斯 Calixtus 加里斯都 Constantine 君士坦丁 Deusdedit，Saint 圣狄乌迪弟 Dionysius，Saint 圣狄奥尼西 Eugenius 犹金 Eulalius 攸拉利乌斯 Felix 菲利克斯 Formosus 福尔摩苏斯 Gregory 格列高利 Hilary 圣奚拉里 Hippolytus of Rome，Saint 圣希波里图斯 Honorius 洪诺留 Joan，Pope 若安 Nicholas 尼古拉 Novatian 诺瓦替安 Paschal 帕斯加尔 Pelagius 贝拉基 Philip 腓力 Pius 庇护 Sergius 塞尔吉乌斯 Stephen I-X， Saint 圣司提反一世至圣司提反十世 Theodore 狄奥多尔 Theodoric 狄奥多里克 Zacharias， Saint 圣扎迦利

——杰里毛斯（留言） 2025年5月14日 (三) 14:32 (UTC)[回复]
感谢，我今天也去图书馆翻阅了一下《世界人名翻译大词典》，发现要找出教宗的名称实在是大海捞针。请问您参考的是第一版还是修订版呢？--立日（留言） 2025年5月14日 (三) 15:24 (UTC)[回复]
比较惭愧，我没用过正版的大词典，一直用的是网络上流传的电子版，从其他词条看应该是修订版。——杰里毛斯（留言） 2025年5月14日 (三) 15:40 (UTC)[回复]
我先补充到表格里，改天再确认一下是否与纸质版一致（我手里也没有纸质版）。--立日（留言） 2025年5月14日 (三) 15:43 (UTC)[回复]
@Ericliu1912：您这笔87300243添加存档的记录我又看不懂了。根据WP:讨论发起位置，如果您认为这一讨论只影响基督教主题，那么就不应该在客栈发起；如果您认为是影响多个主题条目需要在客栈发起，那就不应该存档——所以您的行为完全就是自相矛盾的。更重要的是，我已经在WikiProject talk:基督教发送了讨论通告，已经“为之后的编者留下了讨论记录”，再存档至之显然是多此一举重复累赘（如果是我的话，其实应该会在WikiProject talk:基督教发起讨论；但看您在客栈发起，我觉得要说成“影响多个主题”也说得通——比如历史学、伊斯兰教等条目也都会出现教皇译名——就尊重您的意思，按“影响多个主题的条目”处理了。结果您又莫名其妙加了存档）。另希望@LuciferianThomas关注一下，近期Ericliu1912持续不遵守《讨论发起位置》方针，且拒绝沟通（常不阐述理由或回应他人质疑）径自操作的行为。 ——自由雨日🌧️❄️ 2025年5月15日 (四) 17:37 (UTC)[回复]
@自由雨日请问那个讨论通告是有标准模板的吗？有没有功能键能（像TW那种）能协助发出？--Factrecordor（留言） 2025年5月17日 (六) 13:00 (UTC)[回复]
@Factrecordor：{{讨论通告}}。要替换引用，即自己添加一个标题，然后写上{{subst:讨论通告|talk:基督教|〈简要说明的文字〉}}这样的内容。TW目前还不支持，不知是否可以加入，或者让技术大佬用别的方式做个脚本？ ——自由雨日🌧️❄️ 2025年5月17日 (六) 13:13 (UTC)[回复]
（当然也并非必须要使用该模板，直接手打一段文字，只要能起到通知作用即可。——此外还有起到记录作用，用于代替存档的功能。） ——自由雨日🌧️❄️ 2025年5月17日 (六) 13:15 (UTC)[回复]
就我所了解，天主教的译名跟大部分译名都不一样，这一套译名体系是澳门翻译的（毕竟澳门接触天主教最早）。方济变成方济各就是澳门译名。另外通常教宗上任前也会自行制定自己的名称，通常采用前任教宗的任一名称，这是惯例。--owennson（聊天室、奖座柜） 2025年5月20日 (二) 01:31 (UTC)[回复]

这篇近现代的古文（文言）有自由版权吗？

本主题或以下段落文字，在讨论结束后应存档至Talk:纯贞孝皇后。

我注意到韩国末代皇后尹曾顺在1966年过世后，有一篇以他小叔、英亲王李垠名义写的《纯贞孝皇后上谥号玉册文》，全文在韩国藏书阁可见。这篇文言可以放进条目吗，或者到维基文库？这是不到一甲子之内的文章，是李垠亲作还是他人捉刀我不清楚，因为他晚年病重缠身，1970年也过世了。


这是我自加标点、段落的版本：

维岁次丙午正月辛巳朔十三日癸卯，英王臣垠，谨再拜尚言。窃以鸰泪未干，尚添如丧之痛。鸿号崇贲，式阐盛德之休；情文既敶，慕怀曷抑？

恭惟禀性中正、饬躬温恭，兹乃天降之硕媛，允矣坤象之正体。于归代邸，靡懈承事之诚；逮践中闱，克著赞化之绩。克休声于一国，歌咏方腾；才母仪之四年，禅綍亟下。当险而顺受，第会上困臲卼之时；释位而就闲，爰有肥遁宽绰之德。自顾眇躬之支保，实赖代母之庇阴。

愿奉永年，惟祝玉度之亨旺；梦惊中夜，遽罹柰簪之新哀。嗟仙驭之远游，攀留莫及；遗徽音而茂实，摹绘何能？祇伸崇终之忱，敢举弥文之典；谨遣宗亲寿吉，奉册上尊谥曰“纯贞孝皇后”。仰冀昭鉴，俯膺殊穪。忆平素之懿行，倬云汉而是仰；尚汗青之昭载，弥岁月而不湮。呜呼哀哉！谨言。

加上读音：

维岁次丙午正月辛巳朔（sìshuò）十三日癸卯（guǐmǎo），英王臣垠（yín），谨再拜尚言。窃以鸰（líng）泪未干，尚添如丧之痛。鸿号崇贲（bēn），式阐盛（chănshèng）德之休；情文既敶（chén），慕怀曷（hé）抑？

恭惟禀性中正、饬（chì）躬温恭，兹乃天降之硕媛（yuàn），允矣坤象之正体。于归代邸，靡懈（mǐxiè）承事之诚；逮践（dàijiàn）中闱（wéi），克著（zhù）赞化之绩。克休声于一国，歌咏方腾；才母仪之四年，禅綍亟（shànfúqì）下。当险而顺受，第会上困臲卼（nièwù）之时；释位而就闲（xián），爰（yuán）有肥遁（dùn）宽绰之德。自顾眇（miǎo）躬之支保，实赖代母之庇阴（yìn）。

愿奉永年，惟祝玉度之亨旺；梦惊中夜，遽罹柰簪（nàizān）之新哀。嗟（jiē）仙驭之远游，攀留莫及；遗徽（huī）音而茂实，摹绘何能？祇（qí）伸崇终之忱，敢举弥文之典；谨遣宗亲寿吉，奉册上尊谥（shì）曰“纯贞孝皇后”。仰冀昭鉴，俯膺（chēng）殊穪（yīng）。忆平素之懿（yì）行，倬（zhuó）云汉而是仰；尚汗青之昭载（zài），弥岁月而不湮（yīn）。呜呼哀哉！谨言。

此外，有些词可能有典故，太过艰深，我读了都半懂不懂的。不知道有没有人能做得出逐句翻译。——George6VI（留言） 2025年5月12日 (一) 03:24 (UTC)[回复]

著作权还没到期，韩国应该是身后+70（对于1963年以后离世者而言）。--银色雪莉（留言） 2025年5月14日 (三) 12:55 (UTC)[回复]
根据韩国著作权法第39至44条，大韩民国政府司法管辖区内的所有版权作品在作者死亡后70年（多位作者以最后一位作者死亡计算）或以机构名义公开发表70年后进入公有领域。
因此该作品并非公有领域。--__Don't bite! 2025年5月14日 (三) 13:01 (UTC)[回复]
@George6VI：补ping。--__Don't bite! 2025年5月14日 (三) 13:02 (UTC)[回复]
@银色雪莉、Kurgenera：照这样算，或许可以假定这一篇要到2040年才能放上来？还是更久以后？——George6VI（留言） 2025年5月15日 (四) 01:05 (UTC)[回复]
@George6VI：理论上是2040年之后吧。如果藏书阁那里有表明这篇文章可以自由使用那另说。（我看不懂谚文所以我没找到 囧rz……）既然藏书阁那里能搬也许就是它有著作权或著作权使用权，如果情况允许你也可以尝试联系一下他们。--__Don't bite! 2025年5月15日 (四) 01:16 (UTC)[回复]
先帮忙添入维基文库的“未来进入公有领域作品列表”了。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月15日 (四) 03:46 (UTC)[回复]

战争相关分类用词需要厘清

如题，目前情况部分分类用词不清，如：

en:Category:Battles and operations of World War II→Category:第二次世界大战战役和行动

en:Category:Theaters and campaigns of World War II→Category:第二次世界大战战区和战役

也就是battle和campaign都有译成“战役”的情况，中文是否需要厘清两个词的名称，并统一相关分类标题。--东风（留言） 2025年5月12日 (一) 05:52 (UTC)[回复]

根据美华军语辞典，battle是“作战，会战”， campaign是“战役”。但是大陆不采用美军术语，翻译可能不同。--欢颜展卷（留言） 2025年5月12日 (一) 07:31 (UTC)[回复]
或许小规模可以翻译成“战斗”，中规模“战役”，大规模“会战”或“战争”。大陆辞典对于这些词汇的翻译其实也差不多。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月13日 (二) 05:40 (UTC)[回复]
又或者干脆就不要照抄英文方面的用词，中文这边自己拟好分类区别也行吧。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月13日 (二) 05:41 (UTC)[回复]

关于日本国会选举的命名问题

日前经社群讨论，所有日本国会选举的条目名称从届数+名称被移动到了年数+名称。但是本站日本国会选举的条目仍带有“总选举”“通常选举”之名，然而经过搜索，台湾中央社、经济时报、公视等媒体使用名称为“众议院大选”，中国大陆更倾向使用“众议院选举”，故在此发起更名之话题，还请社群参考。--Skyjjjjjjzzh（留言） 2025年5月13日 (二) 00:27 (UTC)[回复]

(＆)建议：多建立重定向就好了。--__Don't bite! 2025年5月14日 (三) 13:20 (UTC)[回复]

草稿条目请求协助审阅

我在Draft:潮厝华德福教育实验国民小学撰写了一篇条目草稿，内容关于云林县一所公立教育实验小学，采用华德福教育理念。已加入教育处、县政府与官方网站的第三方来源，并注意中立性撰写。

恳请有经验的编辑者帮忙检阅内容是否符合Wikipedia:显著性与Wikipedia:中立的观点指引。谢谢！ --Wikictes（留言） 2025年5月13日 (二) 03:10 (UTC)--Wikictes（留言） 2025年5月13日 (二) 03:10 (UTC)[回复]

我在您的草稿放置了送审用的模板，在您觉得完成时请按按钮提交审核。--Sakurase留言 2025年5月13日 (二) 03:15 (UTC)[回复]
稍微帮你规范了一下格式。语句不中立，需要重写。--__Don't bite! 2025年5月15日 (四) 01:46 (UTC)[回复]
编修了一下，其实问题似乎不大。语句不是很通顺。另外建议（不强制）使用{{Cite news}}。--__Don't bite! 2025年5月15日 (四) 05:26 (UTC)[回复]

请求审查条目《苏信义》

您好，我在页面完成了条目《苏信义》的草稿，内容包括生平、创作风格、展览经历与作品典藏，并附上公开可查的来源与分类标签（Category:台湾战后时期画家）。

草稿位置如下： []

恳请有经验的编者协助审查，若合适可帮我搬出草稿，建立正式条目。非常感谢！--Stickeritai（留言） 2025年5月13日 (二) 03:39 (UTC)[回复]

@Stickeritai以下是我的提议：
  1. 条目的参考来源尽量内文引用，最好每几句话就列明来自哪一个参考资料，而不是好几段都不提，参考资料全堆在下面。
  2. 就算是列举经历，也请改成散文分段，避免列表太多。如孔垂长、奥地利的玛丽亚·安东妮亚。
  3. 参考资料越丰富越好，越多权威的新闻机构报导、书籍纪载尤佳。如果参考资料不够，被质疑不符维基百科收录标准甚至被提报删除也不是不可能。
——George6VI（留言） 2025年5月14日 (三) 00:36 (UTC)[回复]
Hi @George6VI, @Kurgenera: 我已经根据您们的建议，增加可信度引用和修改内容。请协审核，谢谢。--Stickeritai（留言） 2025年5月15日 (四) 04:57 (UTC)[回复]
@Stickeritai：稍微修改了一下，现在大概看下去问题不大。--__Don't bite! 2025年5月15日 (四) 05:15 (UTC)[回复]
@Kurgenera:感谢您很快地回复并协助编辑。若有更多需要增添修订的部分请不吝说明，谢谢。--Stickeritai（留言） 2025年5月15日 (四) 05:46 (UTC)[回复]
@Stickeritai：可以等审核怎么说，个人感觉应该能过。--__Don't bite! 2025年5月17日 (六) 08:16 (UTC)[回复]
@Kurgenera 谢谢!
@TimWu007: 我已经根据您的建议，增加可信度引用和修改内容。请协审核，谢谢。--Stickeritai（留言） 2025年5月17日 (六) 16:51 (UTC)[回复]
@Stickeritai：{{Unreferenced}}--__Don't bite! 2025年5月15日 (四) 01:27 (UTC)[回复]
(～)补充：如果审核通过，记得把{{WikiProject banner shell|blp=yes|class=Start|{{台湾专题|importance=low}}{{美术专题|importance=low}}}}贴上讨论页。如果有(？)异议，可以自行更改importance处的内容，但需参照相应标准。--__Don't bite! 2025年5月17日 (六) 16:58 (UTC)[回复]
@Stickeritai：补ping。--__Don't bite! 2025年5月17日 (六) 17:00 (UTC)[回复]
好的，谢谢提醒。--Stickeritai（留言） 2025年5月19日 (一) 16:10 (UTC)[回复]
@Stickeritai：我合并了几个段落，跟之前几个版本变化不小。我觉得改得差不多了，但还是若有其他人愿意最后审核再通过草稿更好。——George6VI（留言） 2025年5月19日 (一) 01:11 (UTC)[回复]
@George6VI谢谢帮忙编篡。感觉更通顺了。--Stickeritai（留言） 2025年5月19日 (一) 16:11 (UTC)[回复]

请求移动草稿《和平旗》至主名字空间并添加跨语言链接

大家好，

我在用户空间创建了一个条目：User:WUXIAOTONG Bancy/Peace flag，内容为英文条目 Peace flag 的翻译版本，条目已补充参考资料、图片、分类等内容，格式也符合中文维基百科标准。

因我目前权限不足，无法将页面移动到主名字空间。烦请有权限的编辑者协助我将该条目移动至主名字空间，标题为“和平旗”，并帮助添加与英文条目的跨语言链接（Wikidata 绑定）。

非常感谢！

WUXIAOTONG Bancy（留言） 2025年5月16日 (五) 06:21 (UTC)[回复]

@WUXIAOTONG Bancy：暂时(－)反对：没有概述。我会尽量帮忙修改以符合WP:MOS。--__Don't bite! 2025年5月17日 (六) 07:53 (UTC)[回复]
@自由雨日：个人感觉明显机翻，是否符合G13？--__Don't bite! 2025年5月17日 (六) 08:12 (UTC)[回复]
@Kurgenera：我不好判断是否为机翻Orz不过确实翻译得不太好。成为正式条目确实可能还不太行，不过G13感觉不至于？另，WP:G13目前是用不了的，因为不适用用户空间，不过你应该知道（）然后，在用户页的内容，最好还是等原作者请求或同意，再帮他修改吧，不必过度热心（）一般来说是不应修改没有挂{{允许编辑}}模板的他人用户页的。
另@WUXIAOTONG Bancy：该话题下次应发在WP:互助客栈/求助而非条目探讨。 ——自由雨日🌧️❄️ 2025年5月17日 (六) 08:58 (UTC)[回复]
@WUXIAOTONG Bancy：建议阁下再重写一下条目，现在的条目质量挂上去也是提删G13--__Don't bite! 2025年5月17日 (六) 08:27 (UTC)[回复]
已经通过PJ:建立条目系统审核阁下的草稿，往后请循该流程提交。--1F616EMO（喵留言～回复请ping） 2025年5月18日 (日) 04:03 (UTC)[回复]

朝鲜民主主义人民共和国国旗条目需要大幅改写

本主题全部或部分段落文字，已移动至talk:朝鲜民主主义人民共和国国旗。执行者：自由雨日🌧️❄️ 2025年5月16日 (五) 09:01 (UTC)。移动理由：WP:讨论发起位置[回复]

中国人物条目

近日巡查，发现众多中国人物皆使用百度百科式的“XXX，性别，XX族，XXXX年加......”写法。（或是根本就是百度抄来的）

另，其条目中常仅出现该人物的经历如“XXXX年XX校毕业，XXX任XXX......”的制式写法，除极易构成抄袭外也有关注度问题。请问该问题应当如何遏止，否则徒增CCI及巡查员困扰。--Kanshui0943（留言） 2025年5月16日 (五) 17:00 (UTC)[回复]

百度百科式，可能并不。如上格式应是中国大陆政治（及其他领域）公众人物简历的规范体例，当然在本站未有相关格式要求，惟需注意WP:近似复述可能。--PexEric 2025年5月17日 (六) 08:18 (UTC)[回复]
只要不侵权，此类写法也可接受，毕竟相关人物除了公开简历，可能鲜有媒体报道。单一来源的简历资料当然难以写成百科全书式的条目。--PexEric 2025年5月17日 (六) 08:22 (UTC)[回复]
我记得格式手册里有提及避免上述开头，且若鲜有媒体报导又涉及WP:关注度，那这些条目真有可能继续留存吗--Kanshui0943（留言） 2025年5月17日 (六) 08:32 (UTC)[回复]
@Kanshui0943：问问WP:VPT造自动过滤器？--__Don't bite! 2025年5月17日 (六) 08:19 (UTC)[回复]
这个话题我有印象，之前Wikipedia:互助客栈/条目探讨/存档/2024年10月#为什么有的中国大陆人物条目会这样开头？讨论中认为“不违规”。讨论中提到这是中国大陆各级政府官网或新闻报导的样式。百度百科只是沿用而已，其实这种基本事实，应该不涉及查重和版权问题。--Nostalgiacn（留言） 2025年5月17日 (六) 12:41 (UTC)[回复]
维基毕竟不是百度，一昧使用而不跟随格式手册似有不妥。且事实说明也定有避免抄袭的方法。--Kanshui0943（留言） 2025年5月17日 (六) 12:55 (UTC)[回复]
“跟随格式手册”指怎样。单纯调整句式其实也有洗稿之说，对于难以润改的单纯事实来说，可能意义有限。--YFdyh000（留言） 2025年5月17日 (六) 14:32 (UTC)[回复]
中国畸形体制造就的陋习要拉整个中维陪葬?那干脆繁简中分开算了--Kanshui0943（留言） 2025年5月17日 (六) 14:39 (UTC)[回复]
您若已经先入为主，讨论再多也没意义。--花开夜 留言 ·签名 ·贡献 2025年5月17日 (六) 14:50 (UTC)[回复]
我一直主张繁简两边分开各自安好--Kanshui0943（留言） 2025年5月17日 (六) 15:07 (UTC)[回复]
你主张什么，我不在乎。但这里是中文维基百科。你只是因为“我不喜欢”而在互助客栈打开了这个毫无意义的讨论，仅此而已。条目说的是什么，维基百科的作用是什么，这才是作为编辑应该关心的事情。维基百科的条目应该服务于读者，以内容作为导向，而不是为了满足您个人偏好而设计的。如果您执意仅仅以“大陆用语”、“百度百科式”等莫须有的借口试图将条目修改成你个人希望的样式，那么您最好可以看一看其他平台，而非维基百科。另外，我已经在其他地方看见过您多次发布过此类观点了。--花开夜 留言 ·签名 ·贡献 2025年5月17日 (六) 15:41 (UTC)[回复]
或许你没跟到另一边的讨论，这不是我个人偏好问题，而是让维基百科免于大量抄袭、侵犯版权的地方。--Kanshui0943（留言） 2025年5月17日 (六) 15:55 (UTC)[回复]
所以您在指控的是构成侵权，还是风格不符合本站要求（应有条文明确禁止，那边讨论似乎多人能接受），或者复制剪贴建立条目太轻易，或者条目质量问题。如果相关内容未侵权，那么只是人工做类似用公开数据+机器人建立条目的行为？--YFdyh000（留言） 2025年5月17日 (六) 18:46 (UTC)[回复]
该风格的制式化会让条目极易侵权，而可想而知的是复制贴上的条目品质不会多好--Kanshui0943（留言） 2025年5月18日 (日) 04:03 (UTC)[回复]
陋习[为何？]以及中国畸形体制造就的[来源请求] ——自由雨日🌧️❄️ 2025年5月17日 (六) 20:15 (UTC)[回复]
招笑。反倒是平平无奇的简历才是避免华而不实的应有之义。--PexEric 2025年5月18日 (日) 08:36 (UTC)[回复]
大部分人物基础资讯，实几无可改，至多是减少“官式”写法、改置于资讯框等。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月17日 (六) 18:23 (UTC)[回复]
很多人物格式都比较类似，见中国作协会员辞典、院士讣告，在人手不足的时候，参考一定模板，可以快速建立条目。即使如《重编国语辞典修订本》（李时珍）也没有明显的不同。--Kethyga（留言） 2025年5月19日 (一) 09:05 (UTC)[回复]
如果不是直接抄袭，而且并非{{Onesource}}，我认为问题不大。全部直接抄袭是侵权，应快速删除。若仅是{{Onesource}}，那就挂{{Onesource}}模板，改善的方法是增加来源，扩充改写。--欢颜展卷（留言） 2025年5月17日 (六) 19:21 (UTC)[回复]
这是中国大陆官员简历的基本句式，不会构成抄袭侵权。而值得关注的是，中国大陆或任何主流百科全书是否盛行此句式？否则均应改写。--— Gohan 2025年5月18日 (日) 08:35 (UTC) 👍1[回复]

关于旧条目审查

最近仍然在审查随机条目：很多市镇类条目{{subst:No footnotes/auto}}，请问是否有人造个bot出来挂维护模板？（感觉这样做的意义是WP:Growth）--__Don't bite! 2025年5月17日 (六) 07:59 (UTC)[回复]

刚才看到与Template:GeoSouthAsia连结的中文翻译，看不懂

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

似乎

     南亚地理     
喜马拉雅山 | 西高止山 | 东高止山 | 阿拉瓦利岭 | 尼尔基里山脉 | 温迪亚山脉 | 萨特普拉山脉 | 格罗山脉 | 西瓦利克山脉 | 卡西山地 | 安纳马莱山地 | 豆蔻山地 | 苏莱曼山脉 | 喀喇昆仑山 | 兴都库什山 | 吉大港山区 | 德干高原 | 塔尔沙漠 | 玛克兰海岸 | 焦达讷格布尔高原 | 那加山脉 | 迈索尔高原
中央平原 | 印度河三角洲 | 恒河盆地 | 恒河三角洲 | 马尔代夫珊瑚礁 | 科罗曼德尔海岸 | 康坎平原 | 拉克沙群岛 | 安达曼和尼科巴群岛 | 孙德尔本斯 | 喀奇湿地
主要地区 印度 | 巴基斯坦 | 尼泊尔 | 不丹 | 斯里兰卡 | 孟加拉国 | 马尔代夫

与英文版无法对应。不知先进的看法如何？--ThomasYehYeh（留言） 2025年5月17日 (六) 13:16 (UTC)[回复]

你可以直接更新模板（ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月18日 (日) 06:52 (UTC)[回复]

WP:两岸中非官方机构及国际活动的用语规范

根据格式手册中的规范，香港、澳门自回归后所派出的代表队应称为“中国香港（队）”及“中国澳门（队）”。但是，有关足球比赛中，关于香港足球代表队的描述绝大多数都称之为 香港而不是 中国香港，但实质上，在亚洲运动会、2026年国际足联世界杯外围赛 (亚洲区)等等，对于香港、澳门所派出的队伍，其正式名称均为 中国香港和 中国澳门。

“正式名称称呼”指的是主办方的名称还是派出代表队的名称？同时，对于Template:Country data Macau中，是否应如Template:Country data Hong Kong般添加上“中国澳门”的描述呢？--Cygz（留言） 2025年5月18日 (日) 10:27 (UTC)[回复]

对于此种情况，或应考虑全部使用“中国香港”、“中国澳门”。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月18日 (日) 14:40 (UTC)[回复]
题文不太相符。如有正式中文会籍名称者则应用之。--— Gohan 2025年5月19日 (一) 08:30 (UTC)[回复]

建议书写完整地址加入WP:避免地域中心

本主题全部或部分段落文字，已移动至WT:避免地域中心#建议书写完整地址加入WP:避免地域中心。执行者：自由雨日🌧️❄️ 2025年5月19日 (一) 00:18 (UTC)。移动理由：WP:讨论发起位置。[回复]

其他

管理操作复核请求：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)[回复]
@SCP-2000：那如果是当下为回退员然后已经有同意过测试功能的IP资讯的资料存取规则这样的条件有可能可行吗？（我印象中就算开启测试功能也还要optin点同意一个东西？）--SunAfterRain 2025年5月11日 (日) 17:34 (UTC)[回复]
问过了，他们说不行。说“不上这个view-ip权限跟任何用户组连上关系，避免让他们带来相关风险”。--Aqurs 2025年5月11日 (日) 17:38 (UTC)[回复]
既然是独立用户组那让有需求的人自行申请就好了，为什么非要依附在其他组，到底是什么心态？。->>Vocal&Guitar->>留言 2025年5月11日 (日) 23:24 (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相比差得远。
— [25]

这样一句话，我觉得有点危言耸听，不能一个人随便吹牛说大话就能让整个社群人心惶惶吧。--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)[回复]
监管员执行本地查核时需要临时授予自己查核权限，查核完毕后应除权，这会体现在用户权限日志，可通过GRStalker工具查询。这可能相当于某种“公开的查核日志”。--dringsim 2025年5月8日 (四) 16:55 (UTC)[回复]
我觉得他问的是“假如有本地CUer的话”...--（☎）dt 2025年5月8日 (四) 22:22 (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)[回复]

不要SecurePoll还是引入CU

目前大概的症结点就是这个了：要SecurePoll的话就要引入CU，否则监票将难以进行。前几天我也顺便查阅了先前SecurePoll的讨论，貌似当初原本是要请监管员监票的 (类似英维ARBCOM的选举模式) ，但后来不知为何改由本地监督员负责。由于当初是否启用SecurePoll最终是以投票决定，在现在可合理怀疑当时投票存在资讯不对等的情况下，我想提请重新投票决定是否应该继续使用SecurePoll并 (若有需要的话) 加入引入CU的部分。副知参与讨论的@Aqurs1、ASid、0xDeadbeef、SunAfterRain、Elvaaae、沈澄心、Ericliu1912、SCP-2000、Sanmosa、Hamish、LuciferianThomas、Stang、Shizhao、ZhaoFJx、Iming、Peacearth、魔琴、1F616EMO、Python6345、自由雨日、Hehua、AINH、阿南之人、August.C、CopperSulfate、Shawwww、花开夜：--（☎）dt 2025年5月8日 (四) 22:39 (UTC)[回复]

答案不是很明显吗，不使用SecurePoll是不可能的，毕竟那方面的风险仍然客观存在。Sanmosa 新朝雅政 2025年5月8日 (四) 22:43 (UTC)[回复]
本人在本次人事任免投票中观察多个以无关理由反对和诽谤留言，但鉴于人身威胁和操纵真人傀儡之可能仍存，本人认为管理人员任命除CU因基金会要求使用安全投票外，应同时废除安全投票和实票当选制，社群讨论后由行政员决定。本人提议试行行政员在70~50%区间决定管理人员任免。Python6345（查论编） 2025年5月9日 (五) 02:20 (UTC)[回复]
行政员决定导致的争议可能会更大XD，其实之前忘记谁提的双轨并行制可以参考。我设想的是进行两轮投票，第一轮SP半数支持则进入第二轮，第二轮实名投票>75%。这样第一轮中“可能不敢发言的人”可能留言或者反对，即使能过第一轮，留言也会给第二轮参考。至于如果我们担心的SP烂票太多导致第一轮没有过，我只能说很遗憾管理员也是需要社群信任的，半数反对即使有很多烂票大概也并不特别适合上任，免增社群争议——或者可能考虑调低到40%？但是并不治本。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月9日 (五) 02:35 (UTC)[回复]
当然正如地球君一直说的，不要美化SP之前的公开投票，当时只是没有这么多甚至是明目张胆违反方针的理由。即使有（“屁 股 不 正”），其实只要一句“不值得信任”就能避免被划。SP只是把一些人内心的龌龊端上台面而已，在某些程度上来说甚至不算是坏事。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月9日 (五) 02:43 (UTC)[回复]
魔琴的双轮投票想法很有趣……这样可以解决当前安全投票意见不公开的痛点——投票结束后才能看见其他选民对候选人的意见。不过有点关切两轮投票会不会徒增工作量，而且因为投票过多，分散总票数和选民精力。——ZhaoFJx(Talk) 2025年5月9日 (五) 02:54 (UTC)[回复]
这个是个特别又新颖的想法，社群可以考虑这么做。--~~Sid~~ 2025年5月9日 (五) 06:54 (UTC)[回复]
本人认为当前RFA的主要问题是不负责任的反对票（如与权限无关的理由）和对候选人的诽谤。本人的观点是RFA应和RFR一样主要看理由，只在支持和反对理由经过讨论且均有道理时才通过票数决定。
管理员无法访问CU和OS数据，能对个人造成的危害可逆且通常可被立即发现和除权，因此本人认为管理员即使有100张反对票如无合适理由且支持票有合适理由，这100张反对票也应被忽略。Python6345（查论编） 2025年5月10日 (六) 12:14 (UTC) 👍1[回复]
安全投票在近期还要不要继续用之前煮过好几遍了.jpg 很多人都担心被威胁，所以安全投票大概率还会被继续使用。况且当前的监督员监票其实已经足够妥善，毕竟监督员本身就受社群信任处理敏感信息。
可能的( π )题外话，翻了翻phab，至少从2022年开始，便是监督员担任votewiki上的计票员了。——ZhaoFJx(Talk) 2025年5月9日 (五) 03:00 (UTC)[回复]
“要SecurePoll的话就要引入CU”，其实光这点就有疑问。若社群同意监督员（继续）临时兼任的话，还真不一定吧？最近几次申请，他们都能正确行使职责。其实这根本都算是伪命题，至少也不应该全绑在一起，真要讨论就一项一项来。我看社群既对使用者查核问题僵持不下，不如就先让他们继续兼任。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月9日 (五) 03:18 (UTC)[回复]
为什么不参考英维做法，参选人自己选择是走Request for Adminiship（公开讨论、投票）或是Administator elections（分批选举、安全投票）？在现在已经存在仲委会的情况下，“被威胁”的问题已经开始逐渐减淡，两者或许就是通过门槛的不同了。如果两机制同时运作，那比较容易出现乱投票、乱评论还不用负责的安全投票的当选门槛要比公开投票低就行。--路西法人 2025年5月9日 (五) 03:23 (UTC)[回复]
社群似有开放并行的共识，往下可以讨论。不过这要等安全投票召集权归于本地（也就是废除强制定期申请制）较好，比较容易协调制度。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月9日 (五) 04:50 (UTC)[回复]
不知道要等基金会积压多久才能处理，我觉得机制上完全可以先行，然后安全投票本地化再因应而修订就可，等别人修东西的过程总是很漫长。--路西法人 2025年5月9日 (五) 08:40 (UTC)[回复]
其实快了，上面就讲过英文维基百科要推。基金会敢无视他们吗？XD —— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月9日 (五) 14:58 (UTC)[回复]
如果社群对只采用公开投票仍然有疑虑的话，(＋)支持魔琴/路西法人提案，反对只采用SecurePoll，SP现在沦落成恶心别人的工具了。重新引入CU的话，可以同时另外讨论。--Aqurs 2025年5月9日 (五) 04:10 (UTC)[回复]
如同Aqurs1、ATannedBurger与0xDeadbeef上方的讨论，双边我认为各有担忧的点，同样的我也有担忧的点，但我还是希望有本地CU，原因是傀儡查核这种事情牵扯到行为证据的部分，有本地CU我想很多事情应该会有不一样的结果，至于担忧的部分怎么处理很看社群的自治能力与当选者的自制力。
我目前的想法是除了社群处理以外，我建议赋予仲裁委员已经签属NDA的成员监察的权限，并且再有任何资讯泄漏的疑虑或情况，规则上赋予仲裁委员会可以停权CU的权限，直到事情处理完毕，如果结果是要解任则不需要任何操作，如果是要复任则恢复权限。为什么我会建议赋予仲裁委员已经签属NDA的成员监察的权限，因为CU日志是属于不公开的，有仲裁委员会成员看着，可以避免事情进入到不可控的地步，而不会事情不可控，社群才注意到隐私资讯疑似或已经泄漏。--~~Sid~~ 2025年5月9日 (五) 07:12 (UTC)[回复]
申明一下我的建议不包含让arbcom任命CU，仅是监察，确保事情在本地处理，而不是WMF或m:omb来处理本地隐私泄漏问题，当然如果社群喜欢让WMF与omb来处理，我没异议。--~~Sid~~ 2025年5月9日 (五) 07:27 (UTC)[回复]
(－)反对路西法人提案：SP并不是反对票涌现的原因。反对意见本身就已经存在，并不会因为SP而突然从石头爆出来。只不过是原本用户碍于人情、同济压力等原因不便反对票。因为反对票而反过来去掉SP无异本末倒置。且如果参选人可以自行选择走哪一种形式，如果真的仍然存在“威胁”情况，只要参选人选择公开投票不也一样可以防止跑票？SP岂不是名存实忙。更何况现在sp也不见得使得当选门槛过高。这期选四人上两人，此外还有一人超临界。完全未见删SP的原因-某人✉ 2025年5月9日 (五) 12:21 (UTC)[回复]
@AINH：遗憾的是现在在安全投票里人身攻击/诽谤没有得到妥善的处理，有什么解决办法吗？让候选人自行弹性决定是否采用安全投票方为上策。--Aqurs 2025年5月9日 (五) 13:15 (UTC)[回复]
旧版就没有人身攻击和诽谤？最著名的“屁股不正”不就是好例子？如果社群真的认为这少数几列的人身攻击真的是这么大问题 (which I don't)，那么直接删掉附言部分不就行了。如我所说，真的要防拉票的话，让候选人自己选还有什么意义？--某人✉ 2025年5月9日 (五) 15:11 (UTC)[回复]
既然中文维基百科目前已有仲裁委员会，最大程度上可以有办法防止出现“管理员不愿处理的争议行为”的情况，那么本身使用安全投票“防止投票人受威胁”的采用根基即已不存在。公开投票中，编者自然可以不加附言而投票，但因公开检视而不可能随便发表任何诽谤言论；相比之下，某些必须采用安全投票的情况（例如RFDA）不可能删掉附言部分（根据方针，附言是必须）。安全投票不能成为被滥用成为人身攻击和诽谤的温床，不可能文明相关规则不适用于安全投票当中。如果你认为“少数几列的人身攻击不是这么大的问题”，那么阁下本身就是问题之一，任何一则人身攻击都不应该被允许--路西法人 2025年5月11日 (日) 09:50 (UTC)[回复]
说得好像你维文明方针在正常讨论就行之有效一样，满嘴牲口就是文明了？过去亮名投票的时候人身攻击又有哪一次曾经被处理过？所谓投票时文明不文明根本就是red herring。而且我再次重申现在匿名投票的意见才是社群真实意向。记名投票只会因人情、同济压力等原因使人有压力不投反对票--某人✉ 2025年5月11日 (日) 16:43 (UTC)[回复]
你就是没有认真读留言，为反而反的人。你说的好像公开投票的RFA就没有反对票一样。你一直提出“亮名投票未曾有被处理过人身攻击”，但忽略我一直提出“现在有仲裁委员会可以处理社群本身机制无力处理的争议”。匿名投票不但不能反映社群的真实意向，存在极大的灌票空间，甚至连在某些安全投票中有人明目张胆公开拉票社群，你都能觉得这是“真实意向”，那么就省省吧。我在上方的留言中早已对“因各种原因不愿在公开投票中投反对”提出解决方案，就是不相等的通过门槛——安全投票，正面看“投票人能更愿意发表意见”反面看“也容许了毫无合理原因的troll投票、甚至是应该可被制裁的人身攻击投票”，通过门槛可以调低（例如65%）；公开投票，正面看“避免了胡乱发言而无责任的问题”，反面看“因同侪压力不愿投反对票”，通过门槛可以维持目前标准（75%）。如此即能确保能两者之间仍存在公正投票，更为未来社群正常化（管理人员投票推进共识制）打好根基。--路西法人 2025年5月12日 (一) 00:31 (UTC)[回复]
首先我对是否取消SP没有看法，但是据我所知，之前实名投票的时候并没有什么票是因为人身攻击而被无效的，最多只是deltalk而已。除非RFA和RFDA一样强制一定要写附言，否则我不认为应该因为一个非必须的投票附言而导致投票无效。--Dryrace（留言） 2025年5月16日 (五) 06:54 (UTC)[回复]
票不会无效，但人可以被封，这是更重要的问题。用户有发表意见的权利，但滥用这种权利自然应该被剥夺往后参与投票的权利。划票当然是比较强制性、比较极端的做法，但我不认为这是完全不可的做法就是了。--路西法人 2025年5月16日 (五) 14:49 (UTC)[回复]
在下愚见，在骚扰和威胁（比如扬言举报不同意见人士）的风险仍然存在的情况下，使用SecurePoll是必然的，现在要做的是进一步改善方式，而非因噎废食。就CU问题，目前由监督员监票足以当之，当然对重新引入CU在下持开放态度，也支持监督员不公开散播他人隐私和明显的人身攻击留言以解决问题。反对废除实票当选制，在重要权限的授予上不应有任何模糊空间。--🎋竹生🎍 2025年5月16日 (五) 12:26 (UTC)[回复]
选管理并非选议员，其他共识亦并非投票，故此不认可废除实票当选制违反在重要权限的授予上不应有任何模糊空间。如实票当选制得以废除，则威胁和骚扰会因票数不再有用而得以减少，但不反对用安全投票征集意见。Python6345（查论编） 2025年5月16日 (五) 12:43 (UTC)[回复]
恢复公开投票不代表要保留原有的模糊空间。修掉就好。--路西法人 2025年5月16日 (五) 14:50 (UTC)[回复]

参考资料

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

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)[回复]
有没有办法折叠侧边栏？另外我以为一篇页面通常仅会收入一种侧边栏？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月12日 (一) 14:12 (UTC)[回复]

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

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

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

看到了并手动通过部分（）--千村狐兔（留言） 2025年5月8日 (四) 10:51 (UTC)[回复]
@Cdip150：好像之前是您在处理吧。。。问一下有没有什么头绪。--（☎）dt 2025年5月9日 (五) 19:07 (UTC)[回复]
不确定解决了没，再@Cdip150一次（ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月16日 (五) 08:19 (UTC)[回复]

关于翻译时遇到的WP:引注炸弹（？）

Песня распространилась среди «дворовых» гитаристов и уличных музыкантов, даже далёких от творчества Егора Летова[1][2][3][4][5][6][7][8][9][10][11].

标题
  1. ^ 引用错误：没有为名为sidorov的参考文献提供内容
  2. ^ Галочкин М. Гражданская Оборона: песни и поклонники, или Анархия как форма протеста （页面存档备份，存于互联网档案馆） // Template:Книга:Я не верю в анархию (СПб. 09.1990 г., Рокмагазин)
  3. ^ Курбановский А. А. Под каблуком потолка （页面存档备份，存于互联网档案馆） // Template:Книга:Я не верю в анархию («RockFuzz», 1992 г.)
  4. ^ Убей в себе государство! （页面存档备份，存于互联网档案馆） // Template:Книга:Я не верю в анархию (Ока. 15.07.1993 г., «Новая газета». СПб.)
  5. ^ Курбановский А. А. «Пуля-Дура, учить меня жить» （页面存档备份，存于互联网档案馆） // Template:Книга:Я не верю в анархию (22-28.07.1994 г., «Северная Столица», СПб.)
  6. ^ Хлудов В. Егор и окоммуняченные （页面存档备份，存于互联网档案馆） // Template:Книга:Я не верю в анархию («Московский Комсомолец», 21.07.1996)
  7. ^ 引用错误：没有为名为semel的参考文献提供内容
  8. ^ Борисова Е. Летов Егор. Русское Поле Эксперимента (акустика)Template:Недоступная ссылка // Fuzz #6, 1998
  9. ^ Крюков Д. Летов, Егор: Акулий пир （页面存档备份，存于互联网档案馆）. Звуки.ру, 27.02.2008
  10. ^ Сапрыкин Ю. Солженицын писал о совсем другом （页面存档备份，存于互联网档案馆） // Блог «Сеанса». — 19 февраля 2011.
  11. ^ Гаррос А. В окрестностях смерти （页面存档备份，存于互联网档案馆） // Блог «Сеанса». — 14 ноября 2010.

所以这是否符合WP:引注炸弹的定义？应当如何处置？--KurGenera(留言) 2025年5月9日 (五) 15:13 (UTC)[回复]

中文维基百科本就不是中文版X语维基。原版有问题就应该在建立条目的时候一并改进，而不是把问题连带一起翻译到中文--某人✉ 2025年5月9日 (五) 15:19 (UTC)[回复]
首要问题是“如何改进”，不是WP:ENWP!吧...主要是不知道要怎么处理这个东西--KurGenera(留言) 2025年5月9日 (五) 15:37 (UTC)[回复]
这样没头没尾，又没有译文没有context我也不知道怎样评论。但如果只是很普通一段话的话，那么只拿最可靠以及最贴切的两个来源，其余删掉不就行了--某人✉ 2025年5月9日 (五) 17:40 (UTC)[回复]
@AINH：原文在这节里：ru:Всё_идёт_по_плану_(песня)#Популярность。至于译文应该是User:Kurgenera/Test101这里吧。--（☎）dt 2025年5月9日 (五) 19:02 (UTC)[回复]
可以在一个ref里写多个cite模板。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月10日 (六) 06:53 (UTC)[回复]

有关维基百科:管理员布告板/其他不当行为的条文更改

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:管理员布告板/其他不当行为。

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

有不少多次侵权的用户被提报至WP:ANM，提报侵权行为的地点是WP:CCI。遂建议修改以下条文：

现条文

破坏、编辑战、滥用傀儡等用户不当行为应分别至WP:AIV、WP:ANEW、WP:SPI提报。

修改后条文

破坏、编辑战、滥用傀儡、侵权等用户不当行为应分别至WP:AIV、WP:ANEW、WP:SPI、WP:CCI提报。

现右侧列表

修改后右侧列表

如有意见请提出，谢谢！--DaqibaoQi（留言） 2025年5月10日 (六) 03:25 (UTC)[回复]

问题是CCI除了我基本没有人理......
Xindoor的case我从4月尾提报后到现在也没有人开case--VAMPIRE!VAMPIRE! All Hands Brace For Shock!Birds Away. Missile intercepted（留言） 2025年5月10日 (六) 08:07 (UTC)[回复]
还是在布告板上的内容....... 多一个链接是不是也能吸引点人？--DaqibaoQi（留言） 2025年5月10日 (六) 08:18 (UTC)[回复]
也对，(＋)支持修改--VAMPIRE!VAMPIRE! All Hands Brace For Shock!Birds Away. Missile intercepted（留言） 2025年5月10日 (六) 16:22 (UTC)[回复]
@Ghostingb 请问你会撤回你的支持吗？Пусть от победы☆к победе ведёт! 2025年5月14日 (三) 14:58 (UTC)[回复]
会--VAMPIRE!VAMPIRE! All Hands Brace For Shock!Birds Away. Missile intercepted（留言） 2025年5月14日 (三) 17:49 (UTC)[回复]
(－)反对：WP:CCI是用来查核侵权用户的编辑，而WP:ANM则用来请求管理员封禁，二者功能不一样。Пусть от победы☆к победе ведёт! 2025年5月13日 (二) 08:44 (UTC)[回复]
是的 所以需要分开 我做的就是指引其到正确的页面提报--DaqibaoQi（留言） 2025年5月13日 (二) 11:43 (UTC)[回复]
(▲)同上，CCI和ANM根本就不是一个层面的东西。而且持续侵权也是破坏的一种，未必不能提报至VIP。(－)反对提案。 ——自由雨日🌧️❄️ 2025年5月13日 (二) 08:54 (UTC)[回复]
那流程上 只有在CCI查核完毕后 才可以确定是否侵权吧--DaqibaoQi（留言） 2025年5月13日 (二) 11:48 (UTC)[回复]
？？？ ——自由雨日🌧️❄️ 2025年5月13日 (二) 11:52 (UTC)[回复]
(：)回应，我个人意见，针对抄袭，VIP和CCI属于双轨运行，两条平行轨道，永远平行，不互相交叉。CCI查核，是根据蛛丝马迹，仔细查核比对，旷日废时，耗费人力。VIP，显而易见之明显抄袭，收效快速，即报即封，制止损害再扩大，掌握时效性。
绝无要先等CCI查核完毕后，才能确定是否侵权，可以两路并行（水陆并进），同时提报VIP、CCI。
在VIP走速效制止，CCI走细水长流、查核具体抄了多少、还有没有属于抄袭，但还没被找到的。--Znppo（留言） 2025年5月13日 (二) 12:38 (UTC)[回复]
Well CCI的立案条件是5笔侵权，所以立案了其实基本己经可以证明有持续侵权。
另外侵权行为成为破坏的条件是仅在已告知该等内容侵权后仍重复添加才构成破坏。类似Wikipedia:编者著作权调查/YikyuenG的案件由于当事人在开case前根本没收过警告，丢去VIP真的合适？--VAMPIRE!VAMPIRE! All Hands Brace For Shock!Birds Away. Missile intercepted（留言） 2025年5月13日 (二) 13:19 (UTC)[回复]
我说的“持续侵权”就是这个意思（其他破坏也一样，虽然未明说，但一般也是“警告后仍继续”或“持续如此”才提报，否则管理员也会以警告做结而不是封禁。所以简单起见我都用“持续”来形容）。YikyuenG的案件，警告于2025年2月5日 (三) 15:31 (UTC)，提报于2025年2月6日 (三) 13:08 (UTC)，当事人在开case前根本没收过警告[来源请求]？（也有可能你根本没注意他已经被警告+提报过了……） ——自由雨日🌧️❄️ 2025年5月13日 (二) 13:34 (UTC)[回复]
Okok, sorry我miss了--VAMPIRE!VAMPIRE! All Hands Brace For Shock!Birds Away. Missile intercepted（留言） 2025年5月13日 (二) 14:03 (UTC)[回复]
(：)回应，有人提报VIP不是先警告，对方不听才提报？所以你现在是在假设你脑中的情境不警告直接丢到VIP？我是有说没警告直接报VIP？然后钻我语病，故意来杠我显得你占据优势地位？
还有提报VIP若不妥，阁下为何不一一对Wikipedia:当前的破坏/存档/2025年4月这十数笔侵权VIP提报进行【阻止提报】？跟这些提报人讲，我们要按照流程SOP慢慢来，必须先来CCI，我们一个一个慢慢查，你们先侵权我当作没看见，等我CCI查完十天半个月后，我先确定你抄袭了再说，这时才能提报到VIP。--Znppo（留言） 2025年5月13日 (二) 13:50 (UTC)[回复]
能给个报VIP侵权的实例吗？你这连结都是一堆各色各样不是侵权的破坏--VAMPIRE!VAMPIRE! All Hands Brace For Shock!Birds Away. Missile intercepted（留言） 2025年5月13日 (二) 14:11 (UTC)[回复]
那么 添加“多次警告过的侵权可至WP:AIV提报。”如何--DaqibaoQi（留言） 2025年5月14日 (三) 11:44 (UTC)[回复]
(－)反对：那是不是所有破坏行为都要写一遍？“警告后继续简破坏可至提报”“警告后多次移动破坏可提报”……？如果你的意思是说必须先提报CCI、满足“多次警告”才能提报VIP，更加反对。你根本不理解CCI的作用和性质。 ——自由雨日🌧️❄️ 2025年5月14日 (三) 11:48 (UTC)[回复]
不是的 现在CCI的积压很严重 我只是想把CCI链接到ANM的页面上 给大家增加一个进入CCI的窗口 让他们也可以解决CCI的积压问题 那请问雨日佬 怎么改合适--DaqibaoQi（留言） 2025年5月14日 (三) 11:55 (UTC)[回复]
ANM属请求管理员操作，CCI任何编者均可参与。如为解决积压问题请考虑加至公告栏或其他合适位置。Python6345（查论编） 2025年5月14日 (三) 12:21 (UTC)[回复]
我知道 但是侵权这事情放ANM合适吗？--DaqibaoQi（留言） 2025年5月14日 (三) 12:35 (UTC)删去于--DaqibaoQi（留言） 2025年5月15日 (四) 11:39 (UTC)[回复]
@Python6345，条文更改我 撤回请求，但是右侧列表能改么 副知参与讨论的@自由雨日@阿南之人@Ghostingb@Znppo（若有打扰 我在此表达最深的歉意）--DaqibaoQi（留言） 2025年5月15日 (四) 11:43 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

有关维基百科:编者著作权调查#调查案件的审阅流程的条文更改

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:编者著作权调查。

不通过：
由于关联提案被雪球关闭，本提案失效。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月14日 (三) 13:17 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

为防止破坏等行为，遂建议以下条文更改：

现条文

如果用户想要参与调查案件的审阅工作，可以在正在进行的调查案件中选择一个案件进行审阅。我们欢迎所有未有过侵权记录的用户参与调查案件的审阅工作，也鼓励那些已设立调查案件的用户协助清理自己的侵权内容。

修改后条文

如果用户想要参与调查案件的审阅工作，可以在正在进行的调查案件中选择一个案件进行审阅。我们欢迎所有未有过侵权记录的延伸确认用户参与调查案件的审阅工作，也鼓励那些已设立调查案件的用户协助清理自己的侵权内容。

若有建议请提出，感谢！--DaqibaoQi（留言） 2025年5月10日 (六) 03:33 (UTC)[回复]

延伸确认用户的资历比自动确认用户及以下的用户 相比之下是高不少的 而另一方面也许能增强延伸确认用户的责任感 @Ghren--DaqibaoQi（留言） 2025年5月11日 (日) 00:31 (UTC)[回复]
(－)倾向反对：WP:IPDIS。(～)补充：延确就几千个，你维闲人没那么多。( π )题外话：这种应该投到WP:VPP吧？--__Don't bite! 2025年5月14日 (三) 05:30 (UTC)[回复]
同下章节。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月14日 (三) 08:33 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

有关维基百科:编者著作权调查#正在进行的调查案件中案件的编辑权限

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:编者著作权调查。

多人反对根据雪球法则 关闭，如有破坏请提至WP:RFP。--Python6345（查论编） 2025年5月14日 (三) 12:29 (UTC)[回复]
下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

为防止破坏，遂建议以下更改：

原状态

任何人都能编辑

修改后状态

仅有延伸确认用户（及以上）才能编辑

若有建议请提出，感谢！--DaqibaoQi（留言） 2025年5月10日 (六) 03:35 (UTC)[回复]

能否告知大家，上案在做什么？为什么？能否按User:Antigng#个人意见整理你的意见。另一项也同。--Ghren🐦🕛 2025年5月10日 (六) 16:48 (UTC)[回复]
现在的状态是IP用户甚至是临时账号持有者都能来进行案件调查 而破坏者常见于这两类人群 所以建议修改--DaqibaoQi（留言） 2025年5月11日 (日) 00:27 (UTC)[回复]
(－)反对此议案及上方议案：目前CCI尚未出现非延伸确认用户进行破坏，可预见的是即使有破坏其他用户亦可迅速回退。不认为需要通过拔高参与人门槛的方式防止破坏，这么做反而有可能会打击非延伸确认用户参与CCI工作的积极性。--人间百态,独尊变态(讨论)(签名) 2025年5月13日 (二) 15:31 (UTC)[回复]
(－)反对：WP:IPDIS。--__Don't bite! 2025年5月14日 (三) 05:24 (UTC)[回复]
(－)反对，不是延伸确认用户组设立时的预期用途，未见合理理由进行预先半保护。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月14日 (三) 08:33 (UTC)[回复]
(－)反对：(▲)同上。 ——自由雨日🌧️❄️ 2025年5月14日 (三) 11:49 (UTC)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

就 Wikipedia:申请成为监督员/Peacearth/第3次 的疑问

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:申请成为监督员/Peacearth/第3次。

各位管理员和维基编者你们好，我在查读了Wikipedia:申请成为监督员/Peacearth/第3次后就其中一票产生了一些怀疑，其中一票的留言是这样的

认为此人的台独政治立场可能干扰其正常履职，并将进一步导致对中国大陆用户的迫害，故反对。

我仔细检查了一些既往我抓过的破坏者的留言，而我发现assifbus（讨论 | 贡献）的发言语气风格和该票的评论非常相似，如

如果是来自中国大陆的高校期刊，也一定会被港台编辑者以"党控制信息"为由，列入不可靠参考来源吧。

，同时该用户也有多次没有确凿证据但指责其他用户台独或港独的历史，如需要相关证据请电邮我，我可以提供对应的证据，我有一定的信心怀疑该票可能是傀儡投出的，请问能否请监管员就此进行调查？

感谢。-Lemonaka 2025年5月13日 (二) 00:57 (UTC)[回复]

有趣的是，最近该用户傀儡的发言在这 Special:Diff/82654004 116.6.234.162（讨论 | 贡献） -Lemonaka 2025年5月13日 (二) 01:01 (UTC)[回复]
有assifbus类似想法的又不止只有他一个，如果你担心非公开投票有漏洞的话那就提议转公开投票。--日期20220626（留言） 2025年5月13日 (二) 02:29 (UTC)[回复]
这和想法是没有关系的，我是说用词 -Lemonaka 2025年5月13日 (二) 03:03 (UTC)[回复]
还有，我没有担心非公开投票有漏洞，我担心监管有问题而导致没有查出傀儡。 -Lemonaka 2025年5月13日 (二) 03:03 (UTC)[回复]
@Lemonaka：欢迎参与Wikipedia:互助客栈/其他#不要SecurePoll还是引入CU--Aqurs 2025年5月13日 (二) 03:41 (UTC)[回复]
注：此处原有文字，因为WP:IDONTLIKEIT、WP:DFTT、Wikipedia:讨论页指引“沟通交流”，已由 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］于2025年5月13日 (二) 10:17 (UTC)删除，尚祈见谅。若有异议请至互助客栈或向管理员反映。[回复]
1.168.166.133（留言） 2025年5月13日 (二) 09:11 (UTC)[回复]
你真是搬💩大王。这种明显恶搞的东西搬到站内来做什么啊？--——🦝Interaccoonale（留言・贡献） 2025年5月13日 (二) 09:31 (UTC)[回复]
该IP鸭子测试一望而知为Assifbus本尊，上面那个大概率不是，Assifbus用IP发的页面为该被全域锁定用户在本地被封禁后于某Miraheze子站点冒充本地某管理员炮制的诽谤性文章，Miraheze方面封禁其并删除相关诽谤内容后有好事者将其搬运至另一子站点，该被全域锁定用户目前仍在Miraheze等Mediawiki网站活动。在此喊话Assifbus：当初就是因为维基新闻实在是太缺人，所以维闻社群才会容忍您这么久才把您封了，同理，要不是本站某硬分叉也挺缺编者，您早就也被他们封了，请您好自为之。--🎋竹生🎍 2025年5月14日 (三) 16:36 (UTC)[回复]
谢谢。@Newbamboo，我在维闻也发现了该用户大量编造的情况，并在进行处理。 -Lemonaka 2025年5月14日 (三) 16:38 (UTC)[回复]
我是上面那个IP，只是看到这篇文章写的挺搞笑就转来了，如果你们不允许转这篇文章，那就算了--163.223.183.11（留言） 2025年5月16日 (五) 15:58 (UTC)[回复]
@Manchiu，这位又来扰乱了，请处理一下。 -Lemonaka 2025年5月18日 (日) 14:06 (UTC)[回复]
@shizhao @AT@Jimmy Xu@Xiplus各位行政员，请注意，由于选举的票数非常临界，我不认为这是一个可以被简单忽视的问题，如若确定这一票是由某个被封禁的用户做的，那么实际上 @Peacearth的选举是通过的，请不要存档这一讨论，谢谢！ -Lemonaka 2025年5月14日 (三) 11:10 (UTC)[回复]
你还不如去推动整个选举制度的改革，因为现在的举动非常像是看到某人落选而到处去找可疑的地方，以达到推翻选举结果的目的。--日期20220626（留言） 2025年5月14日 (三) 11:28 (UTC)[回复]
如果你真的希望Peacearth能当上监督员，在公开投票的情况下，反对票会下降，那他不就当选了？--日期20220626（留言） 2025年5月14日 (三) 11:37 (UTC)[回复]
推动公开投票与复议此事并无矛盾。Python6345（查论编） 2025年5月14日 (三) 11:40 (UTC)[回复]
我根本就没投票，我也没考虑是否希望Peacearth能当上监督员，任何一位投票管理员都可以公开这件事。
我压根就不是为了某人落选的问题来处理这件事的，而是感觉如果，仅仅是如果，一个早就被全域锁定的使用者如此行动干扰投票，如同Poetlister（讨论 | 贡献）选上用户查核一样，会很可笑。 -Lemonaka 2025年5月14日 (三) 16:16 (UTC)[回复]
我不是行政员= =--Xiplus#Talk 2025年5月14日 (三) 11:37 (UTC)[回复]
抱歉，我搞错了。 -Lemonaka 2025年5月14日 (三) 16:19 (UTC)[回复]
@Lemonaka：以后{{不存档}}模板请加在讨论最下方，不要加在消息内部用{{分段}}分割。另感谢@Python6345移动模板位置，不过您忘删{{pb}}了，我已删。 ——自由雨日🌧️❄️ 2025年5月14日 (三) 11:53 (UTC)[回复]
好的。 -Lemonaka 2025年5月14日 (三) 16:21 (UTC)[回复]
虽然行政员可以看到投票对应的用户，但并不意味着行政员可以随意查询每个投票人的信息，从本讨论串给出的理由来看似乎并不能充分确认，就算是放在傀儡调查也并不能一望而知。如果为了站不住脚的理由，或者是为了给投票“翻案”，就要把投票背后的用户全部“看光”，似乎也违背了安全投票设立的初衷，更可能会造成极坏的先例。另外，下次请避免打扰无关人士（比如非行政员的用户），谢谢。--—远方传来风笛（Talk） 2025年5月14日 (三) 14:12 (UTC)[回复]
或者是为了给投票“翻案”，就要把投票背后的使用者全部“看光”？你在假定恶意，请注意，是我先注意到某使用者存在傀儡的可能，才会提出这个，而正是因为该投票者可能是傀儡，所以投票才可能无效。请搞清楚因为和结果，谢谢。 -Lemonaka 2025年5月14日 (三) 16:18 (UTC)[回复]
我不认为可以靠一句留言就判定某句话是不是某人发的，毕竟也可以模仿他人语气和用词，更何况持这种观点的人也不是没有，看不出这票与傀儡有必然关联，您实在是多虑了。--🎋竹生🎍 2025年5月14日 (三) 16:41 (UTC)[回复]
也许是吧，我恐怕是有点焦虑了。毕竟之前该用户也干扰过RFDA和manchiu的RFA。 -Lemonaka 2025年5月14日 (三) 16:42 (UTC)[回复]
(！)意见：本人认为两则留言只能证明两者均为WP:POINT编者，无法作为是同一人的怀疑理据。Python6345（查论编） 2025年5月14日 (三) 16:42 (UTC)[回复]

感谢关注本申请。个人认为，该发言语气风格似乎无法用来作为该留言是否为Assifbus的决定性判断？考虑到长期以来本站部分用户也有类似风格与思路。至于公开投票，个人认为无法实质解决问题，考虑到以往进行公开投票时早已有类似问题存在。而且，如果改为公开投票，反而可能会导致提问期形同虚设（考虑到以往有些用户会用反对票来变相提问或施压），甚至部分无理留言可能还会起到误导其他用户的效果。此类问题由来已久，个人目前尚未想到适合本站的良好解决方案，所以或许SecurePoll仍然是虽然不完美但堪用的方式。至于本人是否能成功选上倒是其次，我并没有很在意，更忧心的是本站长期以来的一些不良风气，但还是很感谢各位的关心。然后澄清一下上面部分用户的误会：目前本站执行监票的不是行政员而是监督员，且他们也只能看到有谁投票而不知道各自投了什么票。以上。-Peacearth（留言） 2025年5月14日 (三) 21:46 (UTC)[回复]

Assifbus君向我这么说：

“我有那么让你们感到恐惧吗？少搞点政治斗争吧，多写点条目”。WMLO被永久全域锁定后，我已经完成了在隔壁的使命。换言之，粪球的选举案我并没有参与，试图利用我来让粪球成为监督员？你还是悠着点吧，如果那个人和那个IP跟我没有任何关系，等待地球的或许就是全域封禁了。

为了成为监督员不择手段，牛逼

我猜他这次应该真的没参加啦。何况证据薄弱而强硬断论，不过引起反感，进一步削弱社群互信基础罢了。Peacearth本人大概也不期望如此。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月15日 (四) 04:50 (UTC)[回复]
请你做出如下回应，我不对任何人感到恐惧，也从未针对过任何人。我针对的是滥用傀儡这种事情，对于一个全域禁制的使用者来说，继续干涉站内事务是一种不可容忍的行为。这与恐惧无任何关系，至于WMLO的全域锁定，与你无关，更多是关于我。如果你不能学会在隔壁闭嘴，你有一天在隔壁也会被永久封禁甚至面临危险。该感到恐惧的是你而不是社群，至于我对地球成不成为监管员没有兴趣，我仍然坚持认为此案存在傀儡。但若不愿继续检查，我无能为力。 -Lemonaka 2025年5月15日 (四) 05:09 (UTC)[回复]
可供判断的证据不多呀，使用者查核都无法查出，社群基本是无能为力。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月15日 (四) 05:30 (UTC)[回复]
这话怎么听上去一股麦卡锡主义的味道？去了XX就是通X是吧。--日期20220626（留言） 2025年5月15日 (四) 05:50 (UTC)[回复]
是对方先放出bullshit的，“为了成为监督员不择手段，牛逼”这话说出来，我倒是没什么好语气可用了。 -Lemonaka 2025年5月15日 (四) 08:14 (UTC)[回复]
我觉得他其实是在骂我（ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月15日 (四) 15:51 (UTC)[回复]
我觉得他是在骂我，或许是又开始幻想他那些阴谋论剧情，把我想像成什么阴险狡诈的大魔王之类的（-Peacearth（留言） 2025年5月15日 (四) 17:21 (UTC)[回复]
据我所知，该被全域锁定者早在被锁定前就一直在用匿名身份大量散播针对您和其他几位管理员的谣言，不少谣言经重重传播后影响甚广，误导了不少维基人，诚挚希望您能用公正无私、胸怀广大来化解误会、破除流言。--🎋竹生🎍 2025年5月17日 (六) 07:12 (UTC)[回复]
比起化解误会，我们不应该处理这人的谣言吗？ -Lemonaka 2025年5月18日 (日) 14:10 (UTC)[回复]
我只觉得莫名其妙＝＝他和那个IP有没有关系，关我什么事？-Peacearth（留言） 2025年5月15日 (四) 06:36 (UTC)[回复]
另外，本人一向主张不应以意见本身的立场划票，此事亦然（虽说有些意见真的离谱）。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月15日 (四) 04:51 (UTC)[回复]

错别字

可以有用户使用机器人帮忙改正错别字吗？“做为”应该批量改为“作为”才对。--TwistyTongue（留言） 2025年5月14日 (三) 08:16 (UTC)[回复]

做作好像本来是异体还是同义词来着，到了现代开始分工。随便搜索翻了几页，所有我看到的“做为”都应该是“作为”。即使有句读问题（如“决定做为泰党党员”），也可以理解为old-fashioned的写法。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月14日 (三) 08:30 (UTC)[回复]
可在Wikipedia:机器人/作业请求处请求机器人作业。——ZhaoFJx(Talk) 2025年5月14日 (三) 16:52 (UTC)[回复]
谢谢。已提交申请。--TwistyTongue（留言） 2025年5月15日 (四) 02:35 (UTC)[回复]

临时账户：存取 IP 位址和后续步骤

你好！这是信任与安全产品团队。 我们在3 月份的时候提出了在引入临时账户时谁应该查看 IP 位址的建议——我们与大约 20 个大型社群进行了交谈！谢谢这些对话，同时谢谢您在我们制定答复期间的耐心等待。现在，我们希望讨论一些反复出现的主题，澄清我们在第一条讯息中没有明确提出的方面，并分享下一步的计划。

我们讨论的结果

您的评论帮助我们更了解巡逻的风险和担忧，其中包括：您如何看待管理员的新负担、您如何处理巡查旧编辑、有多少人参与巡查您的维基专案等等。我们非常感激这些想法。

您同时分享了许多评论，询问有关临时账户的问题。您询问这是如何运作、如何显示 IP 位址、是否需要变更等。我们正在为具有进阶权限的使用者开发功能，例如上手对话框，Special:GlobalContributions，Special:IPContributions，全域账户封锁、大规模全域账户封锁等等。这一切都是为了帮助您有效打击滥用行为。

关于存取要求－我们决定继续实施管理员（以及在需要时，监管员）的想法，手动授予需要的人查看 IP 的权利。（T390942） 我们能考虑的选项有限。基本的临时账户 IP 位址存取政策必须适用于所有维基媒体专案，为全域的工作人员和各个社群所接受，并且从不同国家（地区）编辑者的角度和法律风险的角度考虑。这就是为什么我们不能严格遵循当地共识或过于广泛地授予 IP 位址存取权限。今年晚些时候，我们可能会重新讨论政策要求或例外等主题。 （不过，您可以制定本地政策！——有关详细信息，请参见下文。）

我们希望提醒您，所有维基媒体专案的部署均需要在今年完成。部署将分为两个主要阶段——6 月/7 月以及大约 2-3 个月后。

反复出现的主题、我们的回应和澄清

为了方便您，我们同时将在专案常见问题中记录其中一些答案。

存取 IP 位址

  • 将新权利分离(checkuser-temporary-account) 给新群组（临时账户 IP 检视者），而不是从技术上将其附加到任何现有群组（如巡查员）。我们决定这样做有几个原因：
    • 存取 IP 位址存在风险。此权利与用户查核类似。 IP 位址被视为个人识别资讯（一种个人资料/信息）。想要存取 IP 位址的外部参与者现在需要与拥有此权限的使用者互动。拥有此权限的用户应该意识到这一点，并对可疑的存取请求的可能性保持警惕。
    • 隐私保护的良好做法。向受信任但不需要存取权限即可开展工作的使用者授予存取权限不符合处理个人资料的良​​好做法。
    • 取消权利。对 IP 的存取将被记录（范例）。如果发现任何滥用此权利的行为，则可以将其与使用者可能持有的任何其他权限分开剥夺。取消与存取 IP 位址无关的权利将会很困难，有时也是不合理的。
    • 您可以向属于某个现有群组的所有使用者单独授予新权限。不过，这些使用者必须符合临时账户 IP 检视者的标准。
    • 为了清楚起见，所有这些都不会影响管理员、行政员、用户查核者、监管员和全球政策中提到的其他群体。
  • 活动要求。对于需要手动授予存取权限的用户，该政策规定他们“必须在 365 天内至少对本地专案进行一次编辑或记录操作”。此要求不会改变。

授予权利的过程

  • 授予权利的手续。这不需要像请求成为管理员一样长时间的讨论或投票。单一管理员根据自己的判断做出决定就足够了。
  • 对申请该权利的用户的额外要求。
    • 您可以自主决定授予权利的过程。您可以采用高于 300 次编辑的阈值，或禁止“非管理员+”使用者拥有该权限。授予过程可以根据您的需求而变得简单或复杂。
    • 目前尚不清楚管理员在决定是否授予该权利时应该采取哪些标准——如何判断使用者是否需要存取 IP 位址。除了至少 300 次编辑和 6 个月的账户之外，没有其他强制性要求。您可以引入与使用者信任相关的附加标​​准（例如，没有先前的封锁或版权侵犯）或参考巡查活动经验。
  • 给管理员带来额外负担。我们理解授予和删除额外权利为管理员带来的负担。这确实是一个缺点。我们认为，只需一次性努力就能让更多的人享有这项权利。我们很好奇您是否能找到方法来减轻这种负担。

启用临时账户后巡逻如何运作

  • “追溯巡查” 和 90 天。在几个维基媒体专案中，社群成员写道“追溯巡查”（巡查旧编辑）可能是临时账号 IP 90 天限制的问题。根据我们的了解 (这已经咨询监管员)，在一般情况下，编辑 90 天后，主要的挑战是清理工作，而不一定需要连系到滥用者的身份。但我们了解在不同的维基媒体专案上可能有不同的情况，而且有些窜改者很有创意。无论如何，90 天的限制并不适用于行为证据或编辑模式 - 这些都会持续可见。这个数字本身可能会改变，我们会注意您的想法和更难调查的证据。值得注意的是，对于经证实的长期滥用行为事例，我们可以公开记录 IP 位址，以满足巡查需要。
  • 账户建立限制（“速率限制”）。一个IP在24小时内只能建立6个临时账户。此限制旨在防止破坏者在短时间内创建大量账户。注册账户创建的限制相同。这不是一个完美的措施，但这类似于我们都熟悉的旧机制，并且确实定义了基本的保护。

我们希望建议您采取下一步行动

  • 我们鼓励您在临时账户启动之前开始授予权利，以便您在需要时做好准备。
  • 如果您认为需要在全球政策中添加任何内容，我们鼓励您考虑采用授予和删除权利的政策。
  • 我们希望向您展示从我们的角度来看什么程度的维基官僚主义是足够的。在沙盒中，我们建立了一个带有标志请求的页面草稿。当然，页面的最终内容将取决于您的社群。我们不希望暗示我们在指导您处理此事。

保持联系

与往常一样，如果您想了解有关该计划的更多信息，请阅读 Diff 部落格文章，访问我们的计划页面和常见问题解答。请订阅新闻通讯以保持联系。谢谢！NKohli (WMF) 和Venuslui（留言） 2025年5月14日 (三) 23:28 (UTC) --Venuslui（留言） 2025年5月14日 (三) 23:28 (UTC)[回复]

三个问题：
  1. 临时帐号建立达到rate limit之后会怎样？就必须要注册为永久帐号才能编辑？
  2. zhwiki大概是在哪个阶段部署？
  3. “将新权利分离”为何不适用于管理员、全域管理员、全域回退员？
——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月15日 (四) 01:37 (UTC)[回复]
Hey @魔琴, thanks for the questions. 1. Yes, the solution is to create a registered account. This limit is the same as the existing limit for IP addresses. 2. We haven't talked about the time of deployment here yet. 3. We assume that community members holding advanced rights related to fighting abuse (like the ones you mentioned) need access to IP addresses to do their work. Does this answer all your questions?--SGrabarczuk (WMF)（留言） 2025年5月15日 (四) 02:06 (UTC)[回复]
Yes. Thanks. ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月15日 (四) 03:04 (UTC)[回复]
根据先前讨论，本人已拟议方案，请社群讨论。--Python6345（查论编） 2025年5月16日 (五) 06:00 (UTC)[回复]

请协助解除账号名称限制（非自我宣传）

各位维基管理员您好，我是账号“马康伟”的编辑者。

本账号是为协助撰写与纪念已逝牧师“马康伟”之条目，并非本人自我宣传，内容亦全依可靠来源、符合中立原则撰写，并在使用者页已公开声明非本人。

但系统仍自动拦阻所有编辑，无法发布任何内容。恳请协助手动解除此项限制。若仍需更改用户名，我亦乐意配合。

感谢您们的协助与指导！ --本账号“马康伟”为纪念马康伟牧师而设，并非条目主角本人。本人非条目主题本人，仅为协助整理与纪录其公开事迹之维基编辑者。若有不当，愿配合维基社群修订。（留言） 2025年5月15日 (四) 06:49 (UTC)[回复]

(＝)中立：WP:U似乎并没有相关规定。看看其它编者的理由再静观其变。--__Don't bite! 2025年5月15日 (四) 14:14 (UTC)[回复]
Wikipedia:用户名#误导性用户名，容易误会为本人。过滤器“编辑自己的用户名命名的条目”为自动拦截。请您按User_talk:马康伟#05/2025的说明请求更改用户名，或者改建新账户。--YFdyh000（留言） 2025年5月15日 (四) 16:38 (UTC)[回复]

关于“精密模板”

rt。{{Encourage}}似乎只是一个用了一次switch的模板，似乎并不是很“精密”。

新手求问：什么是“精密模板”？{{Republican Calendar}}是不是精密模板？--__Don't bite! 2025年5月15日 (四) 14:22 (UTC)[回复]

感觉写出这个超大型模板的U:Mahogany115也真的是概念神了 囧rz……--__Don't bite! 2025年5月15日 (四) 14:28 (UTC)[回复]
为主观评价。Encourage相关内容见于20年前，时代原因吧。--YFdyh000（留言） 2025年5月15日 (四) 16:41 (UTC)[回复]
以前的模板多半都这么复杂吧（ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月16日 (五) 10:26 (UTC)[回复]

维基百科的责任与淫梦相关条目

因为“民国114年5月14日”的关系，这几天仲夏夜之淫梦获得大量浏览，然而淫梦民也在台北市立动物园引起争议，造成许多人对淫梦民的反感。因此我认为有必要重新检视淫梦相关条目。

目前仲夏夜之淫梦对于负面影响可以说是轻描淡写，然而在条目大改之前，条目明白写出淫梦是极具争议的迷因，也指出淫梦民造成许多困扰。本人曾在讨论页反映过这点，但该编者没有正面回答我的担忧。本次台北市立动物园之石虎淫梦命名骚动，正是条目提到的南投基督教医院的FB小编造成的。当时我认为这种单纯玩梗行为没有纪录的必要，但该编者并不认同。

维基百科并不是淫梦wiki，并非淫梦爱好者网站，更何况淫梦已经造成GV演员与社会的困扰，编辑相关条目时请务必考虑到可能造成的不良影响。由于本人并非淫梦专家，无力大改条目，只能希望各位用户扩充有关负面影响的内容。--世界解放者（留言） 2025年5月16日 (五) 12:35 (UTC)[回复]

您之前想要的内容在下找过来源，确实有一个，但是是一篇以笔名发表的专栏文章，在下对其是否适用于WP:生者传记颇有疑虑，如果您需要在下可以提供给您，（个人认为在不触及生者传记方针下这篇专栏中的东西是有一定使用价值的，毕竟发表于有资质的媒体）。仍然呼吁各位以此条目主题近期得到媒体关注的契机使用WP:可靠来源进一步完善该条目。--🎋竹生🎍 2025年5月16日 (五) 12:46 (UTC)[回复]
我认为维基百科的各种规定，最终目的都是为了避免对社会造成不良影响，如果不能达成目的，仅仅遵守规定是没有意义的。阁下当时大改条目之后就把条目送DYK候选了，如果是我才不想把淫梦送上首页，让原本不知道淫梦、野兽先辈的人看到。
考虑拍片当时的时代，野兽先辈应该不会想成为大众的关注焦点，后来淫梦爆红后，他也不曾像比利·海灵顿一样在公众前露面，现在更是一点消息都没有。
你一边拿WP:生者传记出来讲，却把野兽先辈送上首页，你发现问题了吗？--世界解放者（留言） 2025年5月16日 (五) 13:25 (UTC)[回复]
@世界解放者：你应该关注最近几天有没有新闻媒体报导“114514”这个主题。--GZWDer（留言） 2025年5月16日 (五) 13:43 (UTC)[回复]
台湾媒体对于迷因的报导，除了可能符合维基的可靠来源规定，内容是不怎么可靠的，八成是记者随便从网络抄来的。--世界解放者（留言） 2025年5月16日 (五) 14:06 (UTC)[回复]
…inm是网络流行文化，除了到网上找帖子好像也没有什么写成严肃报道的方法了。并且自由时报那篇报道里面有不少贴子，有很多浏览度也不少。--Skyjjjjjjzzh（留言） 2025年5月16日 (五) 17:34 (UTC)[回复]
我搜了一下，好像有研究淫梦文化的论文，但都是日文的，我不会日文啊。--世界解放者（留言） 2025年5月17日 (六) 01:49 (UTC)[回复]
@Newbamboo：我把你轻描淡写的部分改掉了，这段在条目大改之前是明白写出COAT CORPORATION的公告，提到淫梦民让邻居感到害怕（有人会学野兽先辈大叫），你怎么可以仅仅写成“不满”？说得像是邻居不会包容一样。阁下有不中立的嫌疑。--世界解放者（留言） 2025年5月18日 (日) 05:30 (UTC)[回复]
(！)意见日维同名条目拆分后内容看起来还不错，可以借鉴一下，顺道也能解决条目内容琐碎的问题。--Skyjjjjjjzzh（留言） 2025年5月16日 (五) 17:36 (UTC)[回复]
日维至少有介绍淫梦的起源，而且影响的内容也是着重在有关现实或是公部门。相比之下，一家私人医院的网络玩梗（南投基督教医院）实在没有纪录的必要。--世界解放者（留言） 2025年5月17日 (六) 01:42 (UTC)[回复]
有人将田所浩二编辑成独立条目，然而这是只因一次事件而受关注的人物条目，我建议将其恢复成重定向。--世界解放者（留言） 2025年5月17日 (六) 12:57 (UTC)[回复]
同意田所浩二并入到仲夏夜之淫梦当中，关于他更详细的经历，特别是这部影片发布后的去向不明。--💊✖️2️⃣3️⃣（留言） 2025年5月17日 (六) 13:22 (UTC)[回复]
野兽先辈作为素人演员，只拍了几部片就消失了，关于本人的部分没什么东西可写，能写的都是他的迷因，那就应该并入仲夏夜之淫梦，而不是像一般的色情演员建立独立条目。--世界解放者（留言） 2025年5月17日 (六) 13:38 (UTC)[回复]
(...) 吐槽怎么还没人提存废讨论。。--Skyjjjjjjzzh（留言） 2025年5月17日 (六) 15:49 (UTC)[回复]
已提删。--Skyjjjjjjzzh（留言） 2025年5月17日 (六) 15:57 (UTC)[回复]
甚至他具体拍过哪些片，都没有可靠来源列出来。日本在保护个人隐私这块很严格的，显然制片公司就是为了保护这些人免受骚扰，特意不公布任何演员名单，多田野数人当时就是不知怎么的被揭出这丑闻（有说法说是身边人因为一些矛盾冲突故意捅出这事情），如果不是他自己被迫承认此事或者说确实造成了很大的影响（他最初就是因为这事情进不了日职棒只能去美国大联盟），他演过这部片的事情根本就不能写进维基百科里面。--💊✖️2️⃣3️⃣（留言） 2025年5月19日 (一) 09:41 (UTC)[回复]
是的，以当时的社会环境来说，淫梦造成多田野的社会性死亡，写进条目是为了不让大家忘记淫梦是迫害男同性恋起家的，现在淫梦看起来比较无害，也只是社会风气改变的结果，并不是说淫梦本身是无害的。
野兽先辈还有其他消失的演员，应该是离开GV界回归普通生活了，有道德的GV公司不可能透漏消息。--世界解放者（留言） 2025年5月19日 (一) 12:41 (UTC)[回复]
多田野自己的职业生涯都受到显著影响了，搞到他自己也被迫承认了，我们不写也不行了，只不过还是要结合生者传记，将这事情的描述控制到一个适当的篇幅。相反，“野兽前辈”即便是成为迷因，大众对于他的私生活也是没有任何了解，算是低调的人物，这和COAT的保密工作厉害也离不开关系。--💊✖️2️⃣3️⃣（留言） 2025年5月19日 (一) 13:05 (UTC)[回复]

香港公共图书馆旧报纸数码馆藏改版，影响来源连结

香港公共图书馆网站的数码馆藏中的旧报纸馆藏，是香港相关条目的重要来源之一。最近发现其进行改版，使用体验比以前为差；且以前在维基的连结应已失效，不过通常可以找回，这点需要来报告一下。以下是我以自己早前需要使用到旧报纸库的DYK单慧珠作试验的结果：

  • 首先，有关已失效的连结。以往我自己通常直接复制那串很长的网址，但也见过有人放一些较短的连结，但这方面我向来苦手，所以没有深究，每次都是直接复制那串很长的网址，现在被逼要深究了。譬如这个旧版工商日报1977-01-20跳到第9页highlight单慧珠位置的连结[26]，这是一个新版华侨日报1979-03-09跳到第40页的连结，简短很多[27]，经过实验，前者的“QF757YsWv58W%2BpsjUUZMe8FKBxWd8YJt”及后者的“1b7f1f4c9cb711ef9c2”就是报章与日期的代码，后面mainKeyword就是搜索关键字，只要替换了就能为以往的来源更新连结。
  • 其次是搜索体验。这是新版的旧报纸馆藏首页[28]，与旧版差不多，以往我通常会直接在该页的空格输入关键词作简易搜索，虽然搜索结果中偶尔会有一些情况是根本整份报纸都没有那个关键词，但大致上还是正常的。但是改版完全不是那回事，未知是否还在调整。譬如我记得当时使用旧版搜索，单慧珠这个名的结果不多，数十个以内，但是现在用简易搜索，结果有3000多[29]，换言之有大量不相干的结果，根本完全不可用。试试进阶搜索[30]，设“内容”包含完整词组：“单慧珠”，结果66个[31]，这才合理。而且点进每项结果，它跳到关键词所在位置的时间还比较慢，肉眼可见的两三秒，性急起来就会有所误会。--Factrecordor（留言） 2025年5月17日 (六) 10:35 (UTC)[回复]
在黄志光 (1955年)的这一种简短的旧版连结[32]则能自动跳往新版连结。--Factrecordor（留言） 2025年5月17日 (六) 10:50 (UTC)[回复]
副知@So47009@Will629@Owennson@Underconstruction00@Hoising--Factrecordor（留言） 2025年5月17日 (六) 10:53 (UTC)[回复]
谢通知。早在上一星期体会过高层又愈改愈糟。而新系统的不便也早已知道（指用取票机取票或预约才可用电脑）。顺带一提这系统也在启用前花了不少时间改，但还是这个样子，见多媒体资讯系统#历史。--S叔 2025年5月17日 (六) 12:28 (UTC)[回复]

关于本站遭中国大陆屏蔽十年的信息页

前几日在tg水群时突然意识到，5月19日是你站这次遭中国大陆封锁的十年整，因而考虑总结中国大陆维基社群十年间的成果。在站外讨论后勉强列在User:魔琴/筹备/十年封锁，可能有不少疏漏之处（包括新进FA是还没去统计），现在希望社群能帮忙补充撰写，或者优化美术什么的。至于这一信息页应该如何链入（横幅？ASN？），或者其他相关活动比如换logo或者blackout什么的也希望大家讨论。（似乎只剩一天了orz）

本人身体有恙，强撑着打完这行字就要去睡觉了，可能无法参与后续讨论，希望有热心维基人能主导讨论，谢谢。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月17日 (六) 16:49 (UTC)[回复]

第一段：2004年6月3日...--Akishima Yuka（留言） 2025年5月17日 (六) 17:26 (UTC)[回复]
啊，明白了。这次。--Akishima Yuka（留言） 2025年5月18日 (日) 23:11 (UTC)[回复]
现在改LOGO可能太迟，但ASN是肯定要上的，横幅能的话也可以有。--🎋竹生🎍 2025年5月17日 (六) 17:49 (UTC)[回复]
改logo的话往期也不是没有援引IAR快速上线的先例，但是我怀疑这次能不能援引，而且现在没有合适的logo或是横幅的候选。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月18日 (日) 10:09 (UTC)[回复]
改LOGO会有跟很久以前改汶川大地震LOGO时一模一样的争议，难以支持。不过挂个ASN是可行的。--SunAfterRain 2025年5月18日 (日) 12:12 (UTC)[回复]
那也不一样，汶川大地震和你站没有关系，这个你站就是直接受害者。五一二、九二一、六四什么的你站不纪念自然有人纪念，除了你站之外不会有人纪念你站被封十周年的。-- ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月18日 (日) 13:30 (UTC)[回复]
单论草稿内容，可能要先问看看维基媒体基金会与台湾维基媒体协会的意见吧（如果其他人有想到其他可能需要咨询的单位，麻烦在下面补充）？毕竟现在内容提到的成员与组织，有被维基媒体基金会永久禁制的，有指控台湾分会挑衅大陆用户的，有指控基金会行动是打压行动的，那应该问问看这些被指控的机构是否认为适合以当前内容进行公开发表吧。--KOKUYO（留言） 2025年5月17日 (六) 20:28 (UTC)[回复]
我初撰写时已经极力淡化各活动的实际举办方，现在仅提到WMCUG一次，Techyan一次，均是避无可避之处，并且没有任何一处提到甚或链接到他们的指控，我觉得不会有问题。况且部分同仁已经道不同而分道扬镳，应该要有“以直报怨”的想法客观看待、记载他们曾经的活动。至于联络台湾分会或是基金会，我确实希望能从基金会方面获得他们的看法或者评论，其他自治体我觉得也可以在这一页面发表他们的声明之类。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月18日 (日) 10:56 (UTC)[回复]
如果是“以直报怨”（“应以正直回应怨恨之人”），要么就是公平正直地列出组织的正反面，要么就是因上述内容过多且难以简化而都不提吧？若只记正面而不提负面的部分，在《论语》里面叫做“以德报怨”。--KOKUYO（留言） 2025年5月18日 (日) 16:45 (UTC)[回复]
是的，但是这里主要意在总结中国大陆维基人的成果而不是造成的混乱，不然真是有得写了，从中港编辑战到折毛事件，写上去就不像话了。我确实设想在结尾提到大陆社群的不足这点，但没有想好怎么写，若有意也请不吝笔墨帮忙补充。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月18日 (日) 17:17 (UTC)[回复]
那么直接不写进大陆社群的成就不就好了？既然这个页面为了纪念中国政府封锁维基百科十年，大可列出过往2002年来中国政府及其相关组织打压整个运动的经历，并呼吁中国政府应当开放心态，解除对于维基百科的封锁。--KOKUYO（留言） 2025年5月18日 (日) 17:31 (UTC)[回复]
我个人觉得行此记录抹煞之术难称妥当。至于后者，写是可以写，只是前人留下的材料大概不多。可能可以写封锁的详情？我觉得不如直接链接到那个条目页面。中国维基媒体协会被忽略大概不能算是打压。很多人被“喝茶”只是私下里讲讲，公开可查的可能只有2020年那个浙江读者。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月18日 (日) 18:48 (UTC)[回复]
前面您自己承认满足“以直报怨”的相关内容难以撰写，我才建议您那就依照原本是要针对遭封锁十年的宗旨，把焦点明确聚焦在中国政府对于维基媒体运动打压，结果就要被您说是记忆抹煞术？假若真的要说记忆抹杀术，在一个诉求中文维基百科不应该被中国政府封锁十年的页面，放上一个曾指出想向国安机关举报香港用户的用户组及其活动，这个操作才令人困惑吧。--KOKUYO（留言） 2025年5月18日 (日) 19:08 (UTC)[回复]
另外，前面您提到页面“完全没有任何一处提到甚或连结到他们的指控，我觉得不会有问题。”，那么我想请问一下几个连结页面里的内容，是想要让读者认识到什么呢？
至于当人们进一步点选看到更多内容时会遇到的言论，我觉得就不需要列出全部列了，例如：
  • Wikipedia:《求闻》/2019年/《求闻》和中文维基百科（页面点选求闻，即可见到前往此篇的连结）：“直到现在，港台的一些维基人还在站外、在私下搞敌视大陆维基用户、渲染‘大陆威胁论’的伎俩。……因为少数港台维基人不仅平时发言不按照方针，甚至还故意游戏维基规则，用不适当的称呼来挑衅大陆用户，而台湾分会会讯也在这方面大打擦边球。”
--KOKUYO（留言） 2025年5月18日 (日) 19:34 (UTC)[回复]
前三个点名台湾分会了？我个人认为第一个页面确实不妥，但是我不是很清楚为什么社群经年不移除之。至于继续点选，我们都知道WMCUG一向的恶习，他们出现的链接一个都不能出现了？甚至他们还会在编写条目的讨论页诽谤港台用户，是不是也能链接到相应条目？ ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月18日 (日) 20:02 (UTC)[回复]
第一页的内容已经节删。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月18日 (日) 20:11 (UTC)[回复]
（编辑冲突）我说的“记忆抹煞”自然指您的提议“不写进（去）”。难道三个全国用户组变两个？WMCUG理论上仍是维基媒体项目中的用户组，它本身并没有受到基金会的任何制裁（它本身亦没有说要举报香港人），虽然我是WMGMC的联络人，亦一向反对WMCUG，但我无法说服我自己将WMCUG撤下来。还是说将三个用户组都撤下来？且，如果按照您的看法，WMCUG的活动都撤下，该页面至少会减少1/3内容。WMCUG从2017年至2021年的活跃是大陆社群回避不了的问题，当然有人说他们活动和条目质量不佳，但是他们的活动本身是千真万确存在的。我在生活中或是历史中看到某些集团不断抹煞他们不喜欢的人物、事件、记忆的存在，总是觉得可笑。我不希望这种事情会发生在维基百科上。另外，既然此事涉及香港社群，通知@1233。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月18日 (日) 19:54 (UTC)[回复]
我前面应该讲得很足够清楚才对，既然您无法在一个有限篇幅把所有内容“以直报怨”地统整出来，那这个页面就不要硬是去写大陆社群的成果，而是直接把焦点聚焦在中国政府对于维基媒体运动打压。至于您说中国政府打压的案例不多，是不是您根本没有查询吧？--KOKUYO（留言） 2025年5月18日 (日) 22:21 (UTC)[回复]
@魔琴：移动端显示异常，已经修改源代码，如其它平台显示异常请回退鄙人的编辑 囧rz……--__Don't bite! 2025年5月18日 (日) 15:49 (UTC)[回复]
才留意到中国大陆对维基媒体的封锁似乎没有一个对应的项目页面？日后可考虑编写。对于本案，完成度已经很高，已可考虑移到计划页面，望在东八区早可上ASN。--PexEric 2025年5月18日 (日) 16:46 (UTC)[回复]
若有logo或者横幅的设计希望尽速发布在下面，谢谢。东八区已经跨入19日。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月18日 (日) 17:17 (UTC)[回复]
一、刊登全站公告要有相当共识，望有意刊登者迅即表达意见（当然，反对者亦可留言砥砺）。二、是否有必要言及近年大陆社群分裂问题，与有关负面争议梗概？目前单纯阅览该页面，是难以体会大陆社群除遭遇封锁以外其他许多困难。况且，这些毕竟都是历史事实，措辞固然可以委婉，也没有必要长篇大论“喧宾夺主”乃至于直接抹煞部分贡献，搞得十年来大陆社群仿佛祇剩下凄凄惨惨戚戚一般；但装作任何争议全不存在（或者过度掩饰），则又有些天真。我想，此一方面论述，若能与大陆社群客观成就间两相补充而持平，便比较适合刊登公告了。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月18日 (日) 20:31 (UTC)[回复]
（编辑冲突）我建议是在最尾巴简述如

这二十余年间，中国大陆社群的建设也并非一帆风顺，亦出现分裂、攻讦、结党、造假之负面现象……？……因此我们更需要新鲜的血液、更广泛的编辑群体。

具体的来龙去脉这坨矢自己尝尝就好了，就别给圈外人端上了。而且这坨矢我们自己还没理清楚呢，似乎也应该写个项目页面记述。2021年的事情有鄙人主笔的《维猫报》最后三两期大概可以覆盖一下，再往前的可能只能依靠菲菇未完成的《WMC Timeline》了？ ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月18日 (日) 20:41 (UTC)[回复]
争议确实不用写太多，行文倒也可以留点悬念，不过“有争议”这一事实得讲明白（ —— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月18日 (日) 21:29 (UTC)[回复]
您看看当前版本如何？或者加几个链接？ ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月19日 (一) 07:12 (UTC)[回复]
（针对Ericliu1912修订后内容）似可，大陆社群缺乏正常人这块也可以“归功”于封锁。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月18日 (日) 20:44 (UTC)[回复]
已经稍微补充，单立了一章。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月18日 (日) 21:08 (UTC)[回复]
里面说了有道的项目，却为何没提有道提供的机翻接口项目？--百無一用是書生 (☎) 2025年5月19日 (一) 03:18 (UTC)[回复]
感谢指出，已经补充。初稿时写了不知为何改的时候漏掉了。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月19日 (一) 06:04 (UTC)[回复]

中国文化遗产编辑松

我想在6月中旬动员令开始前后同期举办一个中国文化遗产编辑松的活动。昨天文化遗产TG群的群友发了许多关于文化遗产的新闻，深感现在的维基也需要大规模的更新，想知道社群对举办这个编辑松有没有什么看法。—FradonÉtoile✍️ 2025年5月18日 (日) 04:52 (UTC)[回复]

邀请我所知道的在中国文化遗产方面（不论是条目还是站务）较为积极的编者参与讨论（如果各位发现我有遗漏可帮忙@一下），想征求一下诸位的看法：@Saigyouji-Noriko、MintCandy、Kcx36、HaziiDozen、Baomi、红渡厨、PexEric--—FradonÉtoile✍️ 2025年5月18日 (日) 05:03 (UTC)[回复]
如果并入动员令，或允许同时提报动员令，是否可行？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月18日 (日) 05:06 (UTC)[回复]
“同期举行”的意义就是蹭动员令的热度，自然是可以同时提报动员令的，因为我对文化遗产编辑松的想法和动员令有些出入，所以如果动员令能给文化遗产主题开个“中动员令”甚至“小动员令”我肯定是支持的，但活动可能还是要单独办一个。--—FradonÉtoile✍️ 2025年5月18日 (日) 05:10 (UTC)[回复]
如果可以在动员令立一个项目，然后提报条目也自动适用（合格）于该编辑松，应该不错吧？—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月18日 (日) 06:43 (UTC)[回复]
原则上是可以的，不过还要综合其他因素，比如后续在9月举行的WLM，我也希望能联动上，所以编辑松的相关具体事宜还需更多斟酌。--—FradonÉtoile✍️ 2025年5月18日 (日) 07:10 (UTC)[回复]
我(＋)支持，但我能力有限，写不了太多条目。--—— 红渡厨（留言・贡献・欢迎监督红渡厨是否仍有违反文明方针的行为，若有请点此举报。） 2025年5月18日 (日) 05:09 (UTC)[回复]
我认为阁下是比较有能力来做主持人参与条目评审的。--—FradonÉtoile✍️ 2025年5月18日 (日) 06:10 (UTC) +12[回复]
诚惶诚恐，自认能力不足，但愿尽绵薄之力。--—— 红渡厨（留言・贡献・欢迎监督红渡厨是否仍有违反文明方针的行为，若有请点此举报。） 2025年5月19日 (一) 01:59 (UTC)[回复]
(＋)强烈支持蹭动员令热度，这应该是此类编辑松最佳的机会。在没有动员令或是文化月的情况下开展小编辑松结果一般不佳。比如说我们WMGMC去年搞得中国月，完全无人问津，怎一个惨字得了。我个人建议是6/20-7/20这样，比动员令提前十天半个月，权当是正式开始前的热身活动。——Mirfaek 2025年5月18日 (日) 08:06 (UTC)[回复]
确实，那个时候是完全没注意到中国月，不然可能会多写点😂😂主要是文化遗产方面的内容确实比较需要补充，所以才想办这个编辑松；另外时间我是想和动员令时间差不多，因为9月还有维基爱古迹。--—FradonÉtoile✍️ 2025年5月18日 (日) 09:33 (UTC)[回复]
(＋)支持。--PexEric 2025年5月18日 (日) 08:28 (UTC)[回复]
(＋)支持。但我有几个(？)疑问。请问这是每年举办还是仅限今年，活动会举办多少天？还有能不能扩展一下范围，因为我在DYK偶尔能看见中国文化遗产条目，但其他国家地区的文化遗产条目基本很难看见一篇。--仁克里特（留言） 2025年5月18日 (日) 10:56 (UTC)[回复]
我初步的想法是先在今年搞一搞看看效果，如果效果好就可以可持续性地办下去，具体事宜还要和大家一起商量，时间我初步的想法是和动员令时间一致；至于扩展范围的问题，一个是我个人属于是更关注中国文化遗产，世界范围的内容暂时没有更多的精力去拓展，日后若编辑松比较成功，可以考虑扩展范围，一步一步来吧。不过可以考虑动员令搞大范围的“文化遗产”主题，编辑松这边单独对中国文化遗产专题内容做评审啥的。大家可以集思广益想想有什么比较好的办法。--—FradonÉtoile✍️ 2025年5月18日 (日) 11:48 (UTC)[回复]
形式上如果可以新颖一些就好了，和动员令区分开。可以抛开固定时间内完成数量尽可能多，质量尽可能高的条目这种规则，而是采用大家一起共同完成一定数量/质量的条目之类的规则。（只是一个主意）。--HaziiDozen🂢🀑🁲（给HaziiDozen留言） 2025年5月18日 (日) 12:12 (UTC)[回复]
@HaziiDozen：可以考虑弄个条目品质提升计划的子计划，甚至成为经常性计划，偶尔跟其他活动配合之类的。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月18日 (日) 14:39 (UTC)[回复]
不要一次性的话，我也很喜欢PJ:ACGA的形制。这样可能需要扩大考虑范围，例如放在PJ:中国下开设。但是，以“奖励”为名号，倒是不便于推广，像acg专题奖，也只是为编者提供了一个鼓励评阅条目和交流的管道，不好吸收新鲜血液（无论是吸引人加入专题，还是吸引本站新人）。所以不如叫做“质量提升计划”。惟其近年来似已无成功的范例，值此复活，当然最好。另外这里想附知一下@三猎老师：不如思索一下WP:地方史的未来。而且就WMGMC之既立，也有足够理由整合中国大陆方面兴趣编者编辑评审之激励途径和交流渠道，避免中国月和地方史的悲剧，也使相关地区有更多编者加入。--PexEric 2025年5月18日 (日) 16:20 (UTC)[回复]
😂承认我容易想的比较多。Fradon君若是仅觉得最近文化遗产相关内容薄弱，当然还是办一次编辑松集中更新试试水就好。不过我也是相当好奇现在以本站集中目前中国大陆方面为主的编辑力量办一次活动效果如何。--PexEric 2025年5月18日 (日) 16:29 (UTC)[回复]
确实如您所说，这次活动只是一次试验，还有很长的路要走。--—FradonÉtoile✍️ 2025年5月18日 (日) 18:44 (UTC)[回复]
搞不好维持一股力量，像之前提议那样弄个工作组也不是问题。—— Eric Liu 創造は生命（留言・留名・学生会） 2025年5月18日 (日) 21:30 (UTC)[回复]
(＋)强烈支持。之前客栈有用户提议拆分中国文化遗产专题的时候，就觉得应该早日举办这种活动来振兴专题。文遗应该说是中维的一大长板，但是前几次动员令的文遗小动/中动似乎都不是很热门（在下只记得DC18时，不知道什么原因让本人忝列文遗类得分第一），希望这次编辑松也能振兴中维的地方志遗风。在下这边也愿意拿手头的一些明信片（或者出资定制一些明信片）用作活动奖励，或许可以参考亚洲月等活动设立奖励机制。—远方传来风笛（Talk/欢迎关注中国文化遗产专题及电报交流群） 2025年5月19日 (一) 02:45 (UTC)[回复]
欢迎阁下一起参与编辑松的主持与评审工作。--—FradonÉtoile✍️ 2025年5月19日 (一) 07:36 (UTC)[回复]
检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia:互助客栈_(全部)&oldid=63126193”