跳转到内容

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

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

本頁互助客棧 (全部)是供以方便瀏覽所有討論而特別設置。如果您想要新增討論內容，請在互助客棧中選擇最合適的版面。

按此刷新頁面。

  歡迎光臨互助客棧！  
   
  互助客栈是維基人議事相助之處，用以討論消息、方针、技术以及编辑、求助等議題。
發表議題之前請搜索先前文章，遵守指導及禮儀。任何與維基百科無關的問題，请前往知识问答。

消息
方针
技术
求助
條目探討
其他
討論維基相關新聞與消息 討論方針與草案 解決或報告技術疑難 解決在維基百科中所遇疑難 條目、模板、主題相關探討 未符任何分區之議題
发表 | 监视 发表 | 监视 发表 | 监视 发表 | 监视 发表 | 监视 发表 | 监视

查看全部討論

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

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

消息

The Signpost: 1 May 2025

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

Wikidata weekly summary #678

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

Discussions

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

Events

Press, articles, blog posts, videos

Tool of the week

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

Other Noteworthy Stuff

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know ?

Development

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

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

Weekly Tasks

維基媒體基金會公報2025年第8期

帶您快速了解維基媒體基金會自上一期公報〔4月18日〕以來的亮點。請協助翻譯。

近期活動和對話
「來談吧」進行中


年度目標進展 基礎設施
參見其他電子報：維基媒體App · Growth · 研究 · 網頁 · 維基函數與抽象維基百科 · 技術新聞 · 語言與國際化 · 其他MediaWiki.org電子報


年度目標進展 知識公平
參見：維基媒體運動活動的清單 · WikiLearn新聞


年度目標進展 安全與誠信
參見博客：全球倡議博客 · 全球倡議電子報 · 政策博客


年度目標進展 有效性
參見：季度指標報告


理事會和理事會委員會新訊
參見：維基媒體基金會理事會布告板 · 地方自治體委員會電子報


維基媒體運動的其他電子報與新聞
參見：Diff博客 · Goings-on · 維基媒體星球 · Signpost (en) · Kurier (de) · Actualités du Wiktionnaire (fr) · Regards sur l'actualité de la Wikimedia (fr) · Wikimag (fr) · 教育 · GLAM · 維基百科圖書館 · 里程碑 · 維基數據 · 中歐及東歐 · 其他電子報

訂閱或退訂 · 協助翻譯

參閱元維基的專案頁面了解本公報的資訊以及閱讀舊期數。如果您有任何意見回饋或改進建議，寄信給askcac(_AT_)wikimedia.org！


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

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


方針

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

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:非原创研究、Wikipedia talk:导航模板。

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

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

先前意见总结

应该受到限制的意见

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

不应该受到限制的意见

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

其他意见

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

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

讨论区

参见：Wikipedia_talk:非原创研究/存档4 § 关于WP:非原创研究方针是否适用于模板；以及判定模板为“原创研究”的客观标准
参见由Zhenqinli加于2025年3月31日 (一) 05:00 (UTC)。 ——自由雨日🌧️❄️ 2025年3月31日 (一) 05:08 (UTC)[回复]
  • 虽然本讨论的發起者“总结”了双方的意见，但很遗憾，我并未从中看到我的意见。如果是發起者自己总结的，我仍表示感谢；如果是借助AI总结的，我衹能再度表示我向来对AI的排斥以及对“若使用AI，必须声明”的立场。我的意见见@U:猫猫的日记本半年前在《非原创研究》讨论页的留言。另邀请@Sanmosa关注本讨论。 ——自由雨日🌧️❄️ 2025年3月30日 (日) 17:37 (UTC)[回复]
    我在原讨论看到你声称在任何条目选择写入什么内容都是“主观选择”。这些模板违反NOR的原因是暗示“巴黎名胜包含且仅包含这些元素”。我认为将其总结为会导致读者误认为相关内容只有这些是合理的，如果你认为有误，或有其他我整理时未注意的意见，请修改整理意见或告知我。
    另外我是人工整理未使用AI。Python6345（查论编） 2025年3月31日 (一) 01:23 (UTC)[回复]
补充了U:猫猫的日记本的意见。Python6345（查论编） 2025年3月31日 (一) 01:46 (UTC)[回复]
我“在任何条目选择写入什么内容都是“主观选择””一句的前半句是“我从来不认为“主观选择”是NOR”（注意是逗号连接，和後方则是句号连接）。後面也在大段强调了我对大部分列出“相关内容”的导航模板都没有类似的标准（即猫猫的日记本总结的“主题类导航模板”），而且留言的最後又列出了过往讨论的链接（例如裏面就可以看到简单的例子）。总结确实是一项不容易的工作，值得鼓励，但我认为既然总结，就应当全面阅读所有过往讨论以防止片面。猫猫的日记本的意见其实就是对我的观点的总结（当然，他条理清晰，且提出新“术语”的完美总结已经可以说完全超出了“总结”了）。
你刚刚补充的猫猫的日记本的意见（86634608）我仍认为对“列表类导航模板”的描述完全不准确（甚至相反）。他（也是我）的主要意思很明显是，“列表类导航模板”应当照单全收，或明确收录门槛，否则容易导向原创研究，即主要规制的列表类而非主题类（最近提删的也大多是“列表类导航模板”），上述总结直接反了。 ——自由雨日🌧️❄️ 2025年3月31日 (一) 02:32 (UTC)[回复]
改好了，另阅读了之前的过往讨论，补充了几条意见，另邀请@U:0xDeadbeef参与讨论，英维相关指引有哪些本地可以借鉴。Python6345（查论编） 2025年3月31日 (一) 03:42 (UTC)[回复]
“导航模板上进行原创研究会导致读者误认为相关内容只有这些。”这句应该可以删了？似乎没有人表达过类似的观点（而且您说就是跟我说的总结的）。就我的观点而言，是“对有确定元素的集合（例如 Harry Potter 系列有7本书）衹收录其中一些元素（例如4本）会错误暗示衹含部分元素（例如该系列衹含4本书），所以应全收或明确收录范围”，这衹涵盖一小部分模板即猫猫的日记本说的“列表类导航模板”，并未扩展到所有模板（例如{{藏传佛教}}模板就根本就不是一个“有确定元素的集合”，而是一个“主题”）。此外，也不是“进行原创研究会导致……”（逻辑上反了，是仅收录一些元素 —导致-> 读者误认为进而 —导致-> 违反原创研究——而非“进行原创研究导致……”）。 ——自由雨日🌧️❄️ 2025年3月31日 (一) 03:56 (UTC)[回复]
修改了一下总结意见。Python6345（查论编） 2025年3月31日 (一) 04:54 (UTC)[回复]
最近没啥时间看，如果还需要这周末再ping我一次。--beef [talk] 2025年4月2日 (三) 02:05 (UTC)[回复]
我沒有參與半年前的討論，但我的意見是WP:非原创研究適用的對象是顯示於條目中的內容，如果導航模板本身放置於條目，那該導航模板自然是顯示於條目中的內容，並因而受到WP:非原创研究的規制。因其為模板而聲稱其不適用WP:非原创研究實際上是在試圖以不修訂WP:非原创研究的方式繞過WP:非原创研究的必要規制。Sanmosa 新朝雅政 2025年3月31日 (一) 01:37 (UTC)👍 自由雨日觉得这挺赞的。[回复]
但我需要補充一點，就是如果導航模板本身並不放置於條目，而且並不預期將被放置於條目，那WP:非原创研究與該導航模板本身並無任何直接關係。Sanmosa 新朝雅政 2025年3月31日 (一) 06:27 (UTC)[回复]
是的。我觉得上面两点应当是常理才对……大半年前Shizhao亦这么说过。 ——自由雨日🌧️❄️ 2025年3月31日 (一) 06:31 (UTC)[回复]
同意。所以這可以衍生出另一個做法，將疑似是原創研究的導航模板從條目中移除就好，而不需要刪除到導航模板本身。--Justin545（留言） 2025年4月10日 (四) 04:47 (UTC)[回复]
不放在条目中的“导航模板”，存在价值可疑，该做法恐怕很难用到。--YFdyh000（留言） 2025年4月11日 (五) 10:03 (UTC)[回复]
是的，所以導航模板在從條目中移除後需要經過「調整」後再重新放入條目。而不是直接「銷毀」，如此不符合環保的原則，少了物盡其用的概念，也相當是代表完全不給予任何「改進」的空間與機會，而與wp:不要傷害新手的指引不相符。--Justin545（留言） 2025年4月11日 (五) 11:03 (UTC)[回复]
条目所有内容（含模板）适用非原创研究，但不能将任何东西都归于原创研究、暗示观点。假如我说脚注1放在脚注2前面是暗示观点，信息框字段排列也暗示观点，难道能找来源反驳吗。共识下的合理范围内的疏漏、调整或便利性该被允许，异议者请提供合理建议（必须删除/必须标注/补充来源/优化写法/……），而不是扣个帽子一删了之。--YFdyh000（留言） 2025年3月31日 (一) 04:49 (UTC)[回复]
（至少我从未说过这些会暗示观点，我衹针对客观上非常明确含有哪些元素的集合。我对扩大化“暗示”的解读也是强烈反对的。） ——自由雨日🌧️❄️ 2025年3月31日 (一) 04:57 (UTC)[回复]
同意。如果不符合方針或指引的刪除規範，導航模板的刪除我認為應該是最後的手段，異議者應提出意見，給予導航模板作者當作改進的參考。--Justin545（留言） 2025年4月10日 (四) 04:40 (UTC)[回复]
我覺得導航模板的排列方式不應該視作原創研究，因為分類籠統而不足以暗示某種「觀點」者亦很多（例如按年份列出歷史事件能算原創研究嗎？），而有時收錄架構也不是刪除的理由（收錄不完整不等於原創研究），所以應該總是個案探討。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月1日 (二) 14:36 (UTC)[回复]
阅读同类模板和列表类条目后我认为对于列表类导航模板应确保模板列出条目符合WP:收录标准并告知读者可能不完整。另可参见WP:独立列表制订导航模板指引。Python6345（查论编） 2025年4月7日 (一) 05:27 (UTC)[回复]
我认为任何导航模板都应尽量确保所列出条目为独立条目（类似Python6345所说的符合或潜在符合收录标准——不过不完全一样，因为符合收录标准并不一定必须创建独立条目）。导航模板和重定向/消歧义不一样，後者用于帮助读者搜索，输入一个词跳转到介绍该词的内容，完全可以作为子主题跳转到条目对应章节内容（无歧义时直接重定向，有歧义时重定向後再加消歧义顶注/用独立消歧义页平等消歧义等）；但导航模板应主要在独立条目之间进行导航。不过若某个集合无法满足所有条目为独立条目，我的处理意见并非“告知读者可能不完整”，而是——若绝大多数是（或可成为）独立条目，则允许余下列出部分非独立条目通向某条目的一个章节等；若有较多无法成为独立条目，则限定范围（如一定面积以上的湖泊）以尽量使绝大部分可成独立条目。总之仍认为“尽量枚举”。 ——自由雨日🌧️❄️ 2025年4月7日 (一) 05:38 (UTC)[回复]
我想我還是說個兩句吧：一個可以和導航模板對比的是分類。Wikipedia:分類、列表與導航模板似乎也是認為如此。在我看來，導航模板是分類的延伸與補足。
我們不會對分類，提出如條目本身那麼嚴格的原創研究標準，至少我是沒看過哪個分類非要有可靠來源支持不可；但這不代表什麼分類都能放：亂放分類也會被回退。我想，我們對導航模板的收錄標準，應該要比照性質相近的分類：也就是不強求條目般的原創研究，但必須滿足一目了然、還有Wikipedia:中立的觀點。--Saimmx（留言） 2025年4月13日 (日) 15:56 (UTC)[回复]
这些话我均认为有待商榷乃至基本不正确。以原创研究为例，我和你的感受完全相反，分类幾乎均要有可靠来源支持，甚至很多时候要比条目内容还要严格（须是“无可争议的事实”）。 ——自由雨日🌧️❄️ 2025年4月13日 (日) 16:37 (UTC)[回复]
「分類幾乎均要有可靠來源支持」與「須是『無可爭議的事實』」，如果能提供相關連結或舉例說明，會不會比較清楚？--Justin545（留言） 2025年4月13日 (日) 17:07 (UTC)[回复]
「分類幾乎均要有可靠來源支持」我沒找到，但「無可爭議的事實」我倒是能給。维基百科:頁面分類#幾點重要的共識說明：除非显而易见而且没有争议（例如張國榮一定是香港人），不然不要对條目归类。請您寧可先到分類的討論頁提出問題，也不要贸然分類。--Saimmx（留言） 2025年4月13日 (日) 17:10 (UTC)[回复]
後者已经暗含了前者。如果分类是没有争议的事实，他们要么是“verifiable, even if not verified”（用中维的话说就是，不对孙中山是男性提供来源，这在“来源”指引层面尚可以成为问题，但NOR层面的问题无法成立）的内容，要么是已在条目中已出现的有inline citation（文内引注）的内容（尤其是首句定义句；分类一般都是定义性特征）。如果分类出现争议（编者间的争议，而非可靠来源中本身的争议），如何说明某个页面是否需要加入某个分类，当然是通过可靠来源，而非通过编者主观分析（若这种争议性内容最终认定为加入分类，则必然应在条目中出现，且具文内引注）。总之，分类在技术上没有ref ≠ 分类无需满足非原创研究要求。 ——自由雨日🌧️❄️ 2025年4月13日 (日) 17:40 (UTC)[回复]
方纔@Nostalgiacn就因“无来源”移除了幾个条目中的某分类（如86833074）。 ——自由雨日🌧️❄️ 2025年4月15日 (二) 06:51 (UTC)[回复]
為什麼分類要來源，不糾結於具體條文，給一個簡單易懂的，用常識就能理解的例子。現實人物，有編者在不提供任何資料下，加入一個「2025年去世」，其他編者是否應該去質疑這個判斷是準確性，如果沒資料證明這個人物真的去世了，默認應該不加這個分類（WP:BLP）.--Nostalgiacn（留言） 2025年4月15日 (二) 07:35 (UTC)[回复]
經過三位的說明，確實是比較清楚了。這樣的話我想到了：
方針和指引如果對於條目中的「標題名稱」或「章節名稱」（== 標題名稱 ==）沒有給出明確的規範，根據NOR，標題名稱 是否也需要有來源依據？
除了這裡說的「導航模板group名稱」，「附錄」中也可能帶有原創研究或觀點，因此「注釋、相關條目、外部連結、延伸閱讀、...」是否也需要有來源依據？
另外，更基本的，是關於「方針和指引」在詮釋或解讀的方面：
可能沒有說明「適用範圍」
導航模板group名稱、標題名稱、討論頁、知識問答、...是否被包含在NOR的適用範圍裡？
條目中 數學式的推導 是否屬於原創研究？是否被包含在NOR的適用範圍裡？
模糊、灰色地帶
不少方針和指引依賴於「常識」判斷，或以「合理」作衡量標準，所以「常識」、「合理」的 "明確" 定義是什麼？
不自洽、矛盾 或 衝突
五大支柱提到：「請您大胆但不要轻率地去編輯、移動或修改條目」，或是「忽略所有規則」，當方針和指引發生矛盾時應該如何解決？
--Justin545（留言） 2025年4月16日 (三) 01:35 (UTC)[回复]
  1. 要對「章節名稱」給出來源，說真的，實在是很困難，如果不是不切實際的話。我想不透要怎麼做。「標題名稱」見命名常規。
  2. 有關附錄：
    • 注釋：這個需要來源，但用語解釋或明顯事實或許能以WP:孫中山為由省略來源。我覺得沒有大疑問。
    • 相關條目：這個我自己比較不太確定。不過看格式手冊，需要靠共識決定。
    • 外部連結：請參考外部链接。
    • 延伸閱讀：對來源做出取捨或許是編者的原創研究，不過這應該是必要的。延伸閱讀我認為應如是。WP:LAYOUT#延伸閱讀：延伸閱讀……目的是編輯者透過推薦合理數量的出版物幫助有興趣的讀者了解更多關於條目的內容主題……延伸閱讀所提到的內容也不應該與外部連結或者是參考資料部份有所重複。另外延伸閱讀其目的……希望讀者能透過延伸閱讀來作為創建條目的參考資料。
--Saimmx（留言） 2025年4月16日 (三) 04:37 (UTC)[回复]
「要對『章節名稱』給出來源，說真的，實在是很困難，如果不是不切實際的話。我想不透要怎麼做」，這確實也與目前多數看到的標題符合，個人經驗幾乎沒印象有看過在標題加注來源。--Justin545（留言） 2025年4月16日 (三) 08:12 (UTC)[回复]
適用範圍：WP:NOR有說明是適用於條目。所以討論頁與知識問答不包含。數學式的推導不屬於原創研究。標題名稱則按照命名常規處理。可能不是原創研究的事。
常識：一個難以理解的概念。有些人甚至認為不存在（平衡報導）。我覺得應該是沒有明確的定義。
忽略所有規則：與常識有關。我會說要靠共識解決。見File:Diagram of IGNORE zh-hans.png。--Saimmx（留言） 2025年4月16日 (三) 04:51 (UTC)[回复]
對常識的理解，確實是因人而異，也許某些常識只是 某一小群人 在某一段時間內與特定的地點上 所具有的共識。可惜認為不存在最後那句：「所以，在維基百科遇到任何問題，請依照方針和指引來解決。」，有一點循環論證的味道，因為如同我前面提到「不少方針和指引依賴於『常識』判斷」。--Justin545（留言） 2025年4月16日 (三) 08:28 (UTC)[回复]
NOR是内容方针，一切条目内容都需要满足NOR。标题毫无疑问要满足NOR，不信你可以取个原创译名试试。附录等当然也要满足NOR，前段时间就有用户在某个介绍《1984》中某事物的条目中加入朝鲜相关条目而被我回退。另外（我不知道你是否有混淆），NOR是限制编者提出新观念、發表不可靠来源中的观念，或排列组合（常使用关联词）可靠来源中的信息来暗示新结论；而不是“任何内容都要文内引注”。不妨再看下这条留言。 ——自由雨日🌧️❄️ 2025年4月16日 (三) 05:05 (UTC)[回复]
譯名確實是個問題，像是台灣通常稱「川普」，而大陸可能常稱「特朗普」，直接用原文可能是快速的解法，但方針或指引有較好且不模糊的規範我認為是更理想。--Justin545（留言） 2025年4月16日 (三) 09:13 (UTC)[回复]
「the statement "the capital of France is Paris" does not require a source to be cited, nor is it original research, because it's not something you thought up and it is easily verifiable; therefore, no one is likely to object to it and we know that sources exist for it even if they are not cited. The statement is verifiable, even if not verified.」，這個法國首都是巴黎的例子，因為它舉例的是國際知名的地點，我想確實大部份人都知道，不過如果地點被換成是偏鄉的地名，那麼是否引注可能是新的問題，這時可能就是考驗「常識」的時侯了，常識對不同背景的人來說可能會不同，導致意見分歧是有可能的，所以可能會回到前述基本的「方針和指引」在詮釋或解讀方面的問題。--Justin545（留言） 2025年4月16日 (三) 09:34 (UTC)[回复]
有些觀點槽點過多，「章節名稱」我倒是可以說幾句，其實各專題有樣式（如WP:VG），英維那邊其實各類條目都有樣式的，比中文齊全多了。另外「章節名稱」可以編者自定，是根據條目文段的內容取名的，「章節名稱」和章節內容是強相關的，不能亂起名。例如一個章節的內容是關於作品的創作背景，取名「今天是週三」，絕對會被改掉，不予保留。--Nostalgiacn（留言） 2025年4月16日 (三) 06:43 (UTC)[回复]
「有些觀點槽點過多」這指的是什麼呢？--Justin545（留言） 2025年4月16日 (三) 09:18 (UTC)[回复]

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

在列表不全的導航模板附上可能不全的聲明，類似於條目的作法，這也是避免直接刪除導航模板非常不錯的方法。因此，於導航模板加上聲明，或是暫時將有問題的導航模板呼叫從條目內容中暫時移除並改善導航模板，兩種方式都能有效地避免NOR及誤導讀者的問題，目前看來已經沒有直接刪除導航模板的必要性。--Justin545（留言） 2025年4月20日 (日) 22:21 (UTC)[回复]
（对“列表类导航模板”而言）如果作类似声明，在一些导航模板可以避免误导读者（如《中国湖泊》），另一些则仍有原创研究问题（如《巴黎名胜》）。关键就在于这个集合本身是客观存在（衹是没列全）还是编者自行综述的。 ——自由雨日🌧️❄️ 2025年4月21日 (一) 00:40 (UTC)[回复]

沒錯，集合是客觀存在的，甚至集合的成員是隨著時間或條件而改變的（如：名勝的除名與新增）。如果集合發生變動時，相關的列表也能「即時地」更新，讓列表與集合同步，這是最理想的情況。

條目本身可能也有類似的情況，條目的內容也可能是過時的資訊，此外其實目前還有為數不少的條目是屬於內容較缺乏深度與廣度的小作品（stub）（見Category:小作品类别），其中一部份是類似於work in progress的狀態。當然理想上如果能一步到位，在條目建立的當下就讓它變成完美條目是再好不過，不過嚴格要求一個條目在廣度上要 無所不包 這在實行上會有一定的困難，因為貢獻者對條目所知道的有限，可以用在維基上的資源也有限（許多是忙碌上班族/學生，時間較不自由），所以要靠眾人的力量讓條目趨近於完美，這中間通常會有一段可長可短的 過渡期 是處於非常不完美的狀態。

假如 列舉不全 與 資訊不完整 被視為原創研究或原創總結，可能就會有些類似將小作品的條目也當作原創研究或原創總結的概念。個人認為比較有建設性的是設法去編輯它並完善它，這可能會比直接刪除相對較好也較友善。

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

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

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

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

{{2025年地震}}（标题为「2025年主要地震」）似乎两样都不符合。我猜没有可靠来源会讲「缅甸地震是2025年主要地震」，现在也没有人写说「本导航模板可能不完整」。但是我不是很能接受它是违反NOR的。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年5月6日 (二) 10:23 (UTC)[回复]
以模板讨论:2010年地震来看，入选标准确实是原创的。按此标准，也确实可能处于“不完整”状态，例如没有条目或者标准不一致。可靠来源可能讲年度典型震例[1]，但仍缺通用收录标准。--YFdyh000（留言） 2025年5月6日 (二) 11:33 (UTC)[回复]
因为没人解答此项疑慮，双重(－)反对。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年5月7日 (三) 10:01 (UTC)[回复]
快点提吧，别墨迹了，Zhenqilin两面三刀的态度您也不是没看见，当社群一致认为其违规事实时，ta非但拒不接受，却反而指责社群有意“滑坡论证”针对ta，赤裸裸的IDHTta却不知道是啥。--Liuxinyu970226（留言） 2025年5月6日 (二) 10:30 (UTC)[回复]
閣下這是屬於抒發情緒嗎？--Justin545（留言） 2025年5月6日 (二) 14:53 (UTC)[回复]
(－)反对“有最少一个可靠来源证实有条目属于此类即可”：这会导致衹要有一个可靠来源称“埃菲尔铁塔”是巴黎名胜，我就可以随手收录其他任何地点来创建{{巴黎名胜}}模板都不算原创总结。我的观点是即便所有义项都有可靠来源提及，这样的“巴黎名胜”模板依然为原创总结（即哪怕去掉“即可”我尚反对）。“有最少一个可靠来源证实有条目属于此类”（则可创建在其他标準满足的情况下）应当是分类的标準而非导航模板。 ——自由雨日🌧️❄️ 2025年5月6日 (二) 11:35 (UTC)[回复]
(：)回應已修正歧义。Python6345（查论编） 2025年5月6日 (二) 11:42 (UTC)[回复]
（上方Python6345的修改内容见此）我之前理解的是“创建”，但未看出“进入导航模板”和“可据此创建导航模板”在实践上有什么区别，而且主要聚焦的问题本就是後者。另外，改前语句已经有点不通，将“需要”（必要条件）和“即可”（充分条件）两个词放在同一句表述；改後更是杂糅难读。 ——自由雨日🌧️❄️ 2025年5月6日 (二) 11:50 (UTC)[回复]
实践上区别为修改后明确规定是具体条目是否可出现于对应导航模板，本人认为导航模板内收录条目标准影响模板是否为原创研究，因此需定明。Python6345（查论编） 2025年5月6日 (二) 12:00 (UTC)[回复]
“具体条目是否可出现于对应导航模板”对暂无的导航模板来说就是“可以创建”，因而我说实践上没有区别。例如现在无《巴黎名胜》，有可靠来源说埃菲尔铁塔是巴黎名胜，那根据你的拟议方案就可以创建《巴黎名胜》模板，故反对。另邀请@红渡厨参与讨论。 ——自由雨日🌧️❄️ 2025年5月6日 (二) 12:11 (UTC)[回复]
本人认为此处模板可能对读者的误导在于标题中立性，属MOS:不要华而不实不推荐的范围。阁下此例本人认为可移除活动与传统部分并将名称改为符合收录标准的巴黎建筑或简称巴黎建筑并在模板头部标示符合收录标准之巴黎建筑。Python6345（查论编） 2025年5月6日 (二) 14:34 (UTC)[回复]
“华而不实”确实也存在，但那是另一个问题，即便（其他模板）无华而不实问题也同样存在我说的问题（例如{{黄河沿岸城市}}）。“符合收录标准”并非是可靠来源中的概念，而是维基百科编者判断，将其直接写在条目（包括以导航模板形式嵌入条目）中就构成了原创研究（就像我们可以通过Google搜索等确定哪个是常用名称来确定条目标题，这并非原创研究而是编者判断，但将确定结论“X比Y常用”直接写入条目就是原创研究）。
就导航模板的问题我再解释一遍吧，我觉得逻辑很简单：如果可靠来源表述的是“a属A”（a为条目介绍对象），那么在a底部加入分类A（当然非必需）就反映了可靠来源的状态；如果可靠来源表述的是“A包括了a、b、c……”，那么用导航模板列出整个表格（表头为A，元素为a、b、c……）就反映了可靠来源的状态；如果是多个可靠来源描述了“a属A”“b属A”“c属A”而没表述“a、b、c……属A”，那么将其制作成（表头为A，元素为a、b、c……）导航模板当然就是原创总结，反映了任何可靠来源没有表述的观点。当然，如果A本身具有那些元素是客观、无争议的，那不在此列，例如“巴黎有哪些建筑”确实是客观的，不会有原创研究——当然我仍不赞同建《巴黎建筑》模板，这不是这裏讨论的原创研究问题而是我认为不适宜以导航模板处理，不展开了。 ——自由雨日🌧️❄️ 2025年5月6日 (二) 14:51 (UTC)[回复]
如果是多個可靠來源描述了「a屬A」「b屬A」「c屬A」而沒表述「a、b、c……屬A」，那麼將其製作成（表頭為A，元素為a、b、c……）導航模板當然就是原創總結，如果是按照閣下的說法，是否可以將模板拆成三份，分別為「a屬A」、「b屬A」、「c屬A」三個模板？--Justin545（留言） 2025年5月6日 (二) 15:10 (UTC)[回复]
“a为条目介绍对象”，是单个元素。衹包含一个元素的导航模板是没有“导航”意义的。 ——自由雨日🌧️❄️ 2025年5月6日 (二) 15:45 (UTC)[回复]
那麼如果是改為下面的設計呢？主要還是把相關資訊集中在一起，方便將讀者導航到對應的頁面。實際上 來源1 可能也不是單純表述「a屬A」，而可能是表述更多像是「a,d,e,f,...屬A」或。也有建議提到一些共同的資訊可以在導航模板計畫頁面說明即可，避免標註過於冗贅，這也關係到模板的標註方式。
--Justin545（留言） 2025年5月6日 (二) 22:09 (UTC)[回复]
看不出这样的模板有什么导航意义，这是编者在研究哪些文献将什么事物归类为A。 ——自由雨日🌧️❄️ 2025年5月7日 (三) 02:31 (UTC)[回复]
閣下說得很有道理，上面的例子因為每個集合裡都只有一個集合元素，所以看起來挺空泛，缺少內容，這些可能要放到 相關條目／參見／參看 章節比較適當。不過如同我之前所說，若集合裡面有更多的集合元素像是「a,d,e,f,...,i屬A」、「b,j,k,l,...,o屬A」、「c,p,q,r,...,s屬A」，那麼模板的資訊量就變大了，放到 相關條目 會顯得過長，不便閱讀。而就我觀察您的觀點，也許重點還是「不違反方針和指引」（WP:NOR），所以只要在符合方針和指引的前提下，是不是應該給編者更大的自由會比較好？其實現在的方針和指引已經夠多了，真正可以把方針和指引完全掌握的編者我想也是十分有限，再增加太多規則或更多細節可能不見得會有非常巨大的幫助。--Justin545（留言） 2025年5月7日 (三) 03:04 (UTC)[回复]
这不是在增加规则，而是没有任何导航意义，且很可能更加违反《非原创研究》（类似学术文献尤其是综述/元分析的写法，“研究哪些文献将什么事物归类为A”）。我相信除你以外没有读者或编者会认为下面的导航模板有存在的意义。
此外，group（即来源）这种包含一些元素的集合在这种导航模板中本身也成为了一种元素，此时模板就成了更高层面的“非客观存在”“无明确收录标准”的集合，这同时会导致更严重的原创研究问题。
再次请你不要再像这裏的讨论一样长篇大论地發散。——自由雨日🌧️❄️ 2025年5月7日 (三) 03:13 (UTC)[回复]
  1. 首先，您連結到我先前在「知識問答」的討論，與這裡「互助客棧/方針」討論，兩者是不同且分開的討論，之前知識問答若有發散，也不表示在此的討論也必然會發散，若您認為我在此的討論有發散或離題，請您具體指出是哪些部份。Wikipedia:討論頁指引#如何使用條目的討論頁：「表達出您的看法，但不要忘記闡述您的理由。提出一個觀點有助於説服別人並達成一致。」，個人認為這三天以內在此的論討幾乎都是在闡述我的理據、理由、疑問、意見、看法，並不自覺有任何的離題或發散。
  2. 我相信除你以外沒有讀者或編者會認為下面的導航模板有存在的意義，類似於我前述所提，基本上只要不違反方針和指引，您上面所舉出帶有三個來源的巴黎名勝模板是否有其存在的意義並非絕對地那麼重要，所以我才提到在規範以外所能做的，是否皆應屬於編者個人的自由或選擇？然而，您舉出的模板難以否認確實有它的功能性，畢竟它列舉出了9個法國地點的相關條目供讀者點擊，不能說完全沒有它的意義，在我看來導覽模板還有一個重要的功能：組織條目的連結，我覺得其實現有導覽模板的做法就已經很好，條目連結的組織清淅且明確，只是為了要符合這裡NOR的提議，所以才要特別針對不同的來源去做拆分，此拆分動作在某種程度上只是為了符合NOR提議下的必要之惡。
--Justin545（留言） 2025年5月7日 (三) 06:19 (UTC)[回复]
我无法阻止你忽视我前文对该模板更违反NOR的论述。 ——自由雨日🌧️❄️ 2025年5月7日 (三) 06:23 (UTC)[回复]
理解了，认可以此标准定明方针。Python6345（查论编） 2025年5月6日 (二) 15:47 (UTC)[回复]
我的意见基本都是以前说过的那些，没有什么要补充的。--—— 红渡厨（留言・贡献・欢迎监督红渡厨是否仍有违反文明方针的行为，若有请点此举报。） 2025年5月6日 (二) 15:46 (UTC)[回复]
要求有關模板全部標註「明确告知读者可能不完整」過於冗贅，理當直接在「導航模板」計畫頁面統一說明其性質即可。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月6日 (二) 20:14 (UTC)[回复]
閣下這是很好建議，在導航模板計畫頁面統一說明，可以大幅減少額外資訊佔據太多導航模板的版面空間。如果覺得需要加強說明的明確性，頂多再加上一個類似「[說明]」或「[?]」的連結，連到導航模板計畫頁面，這樣或許也行。反之，如果覺得連到導航模板計畫頁面是多餘的，甚至計畫頁面的連結也可以拿掉。--Justin545（留言） 2025年5月6日 (二) 21:18 (UTC)[回复]
同意。事实上维基百科应该製作「读者手册」这樣的页面。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年5月7日 (三) 10:03 (UTC)[回复]
是的，我在这裏就提了（）有了“凡例”页面之後也就可以直接使用“［英］”这样的语种标记了（当然，比起语种标记本身来说，“凡例”没那么紧迫）。 ——自由雨日🌧️❄️ 2025年5月7日 (三) 10:13 (UTC)[回复]
當前版本人类不可阅读，双重(－)反对。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年5月7日 (三) 10:00 (UTC)🤣1[回复]

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

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

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

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

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

  • 十分認同閣下的觀點，編者應該被授予足夠的「自由」，對他（她） 擅長 及 感興趣 的內容寫作，相信這也是不少編者們撰寫維基百科的動力來源。這也更能符合在每個頁面或許多頁面上方標榜的這段話：「維基百科，自由的百科全書」。
  • 附帶一提：就我的理解WP:NOR應該是：對編者所 加入 的內容進行限制，而不是對編者所 排除或忽略 的內容進行限制。要求編者透過類似「窮舉法」的方式去寫百科內容，對特定的編者而言，通常是極度困難的。雖然另外還有WP:NPOV，但條目也很難在「每一個時間點」都完美地符合NPOV，所以在過渡期才會有{{POV}}模板可以使用。授予編者充足的資源（時間資源、人力資源、...）去「改善」其內容，以「改善」取代「刪除」，在我看來這是比較有「建設性」的方式，這可能也較符合維基百科:刪除的序言：「我們應該儘量保留所有合乎百科全書目標的頁面，刪除應該是最後的選擇」。
--Justin545（留言） 2025年5月8日 (四) 02:58 (UTC)[回复]

提议修正Wikipedia:界面管理员

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

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:介面管理員、Wikipedia talk:申请成为管理人员。

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

但哪一邊纔是實際標準？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月15日 (二) 05:55 (UTC)[回复]
抱歉。 取消公示。—WiiUf（留言） 2025年4月15日 (二) 06:40 (UTC)[回复]
雖然我自己正在參選，不應該評論（稍有自肥之嫌），但OS都能七成五當選，界管要八成，也不太合理吧。確實過往討論似乎全程大家都沒提及IA，不過直接跟進（因為當時是修改整個RfA的當選標準）應該不成問題；甚至可以走事實性修訂，確實有社群共識調低「申請成為管理人員」（管理人員定義上包含也要經過RfA的界管）的當選標準。5%的修訂不大，只要在投票結束、確定結果前改方針就行了。--路西法人 2025年4月15日 (二) 13:30 (UTC)[回复]
根據WP:RFA「投票結果」段落：「行政員須按投票中有效的支持票佔總有效票的比例（支持率）判定管理人員申請是否獲得通過。各該申請之有效支持票數至少25票，且支持率達75%者，將獲授予申請之權限。」既然介管屬於管理人員架構內，那就沒有理由高於其他管理人員，況且介管的權限在管理人員中可以說是最少的，當選要求卻更高實在是於理不合。無論如何，基於選舉已經迫在眉睫，需要盡快解決，監督員也有過相同的事實性修訂，這也是我在選舉前發現的。--AT⊿⁴⁶ 2025年4月15日 (二) 14:59 (UTC)[回复]
咱相信是之前的某个RFC里忘掉了IA这个东西，所以那边没有进行修订。感觉可以执行事实性修正：
現行條文

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

提議條文

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

Stang★ 2025年4月16日 (三) 12:40 (UTC)[回复]
本人同意有關修正案，蓋此實符合社群當初全面降低管理人員申請門檻之意旨。若社群確有共識支持，應於近期集體申請正式開始表決以前通過修訂為宜。另副知@WiiUf、LuciferianThomas、AT。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月19日 (六) 05:08 (UTC)[回复]
不反對。--WiiUf（留言） 2025年4月27日 (日) 10:52 (UTC)[回复]
这里还需要公示么，还是说可以直接进行修改？ Stang1364 2025年4月27日 (日) 08:48 (UTC)[回复]
@Stang：我覺得需要公示。另外，是否適用這次申請？也是個問題。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月27日 (日) 13:31 (UTC)[回复]
@Stang 我覺得要公示48小時吧，在投票結束前修改好。Пусть от победы☆к победе ведёт! 2025年4月28日 (一) 04:04 (UTC)[回复]
@WiiUf、Ericliu1912、LuciferianThomas、AT、阿南之人：看到讨论中对于是否适用于这一次存在不一样的看法，我觉得为了谨慎起见，应当在正在举行的选举中使用目前80%的版本，修订的版本在未来生效。不管怎么说，先进行 公示7日，2025年5月6日 (二) 06:17 (UTC)結束。 Stang1362 2025年4月29日 (二) 06:17 (UTC)[回复]
@Stang、AT、LuciferianThomas 本来这个提案是对于本次选举的紧急修正，却因为一些问题而推迟公示。所以我认为新修订方案应该适用于本投票。Пусть от победы☆к победе ведёт! 2025年4月29日 (二) 08:29 (UTC)[回复]
RFD早已提及75%的當選門檻，只是介管頁面未及更新而已，因此理應以75%為準。--AT⊿⁴⁶ 2025年4月29日 (二) 09:14 (UTC)[回复]
以75%為準並無任何問題。--Hamish T 2025年4月30日 (三) 18:39 (UTC)[回复]
@Stang：同AT，目前公示應停止。改就上述的「事實性收訂」緊急公示48小時，並在本次正在舉行的選舉中，實施修正後版本。--Aqurs 2025年4月30日 (三) 18:53 (UTC)[回复]
繼續公示無傷大雅，討論下是否在本次選舉中遵從該事實即可。--Hamish T 2025年4月30日 (三) 19:36 (UTC)[回复]
公示期間如果還沒達成共識這樣跟不公示沒兩樣，只是為了勉強在rfa完結前解決掉。傾向盡快達成共識再緊急公示。--Aqurs 2025年4月30日 (三) 19:56 (UTC)[回复]
75%的標準是既有共識導致的事實性修訂，而不是說近期才達成的共識。個人認為並不需要再達成“在本次RFA中以75%支持作為標準的共識”，這裡公示的條文都完全可以走事實性修訂的程序，沒有必要為了達成這個共識而達成。--Hamish T 2025年5月1日 (四) 01:56 (UTC)[回复]
我說的是不認為現有討論就「在這次rfa採用新版本」有一定的共識。--Aqurs 2025年5月1日 (四) 03:54 (UTC)[回复]
個人認為並不需要再達成「在本次RFA中以75%支持作為標準的共識」，此處要修改到七成五，是因為之前已經有共識通過了“降低管理人員選舉標準至七成五”然後改了WP:RFA沒有改WP:IA，這個修改本身就可以直接執行事實性修改，新共識已經修改了舊共識，拙見沒有必要多此一舉。--Hamish T 2025年5月1日 (四) 04:02 (UTC)[回复]
那麼為什麼上方會出現「我覺得為了謹慎起見，應當在正在舉行的選舉中使用目前80%的版本，修訂的版本在未來生效。」？--Aqurs 2025年5月1日 (四) 04:08 (UTC)[回复]
沒問題啊，我也只是表達我的看法，我認為沒有必要重新公示，直接按照RFA修改的共識走就可以了。而且理論上來說，如果您覺得重新公示是恰當的操作，您也可以直接開始“緊急公示”。--Hamish T 2025年5月1日 (四) 04:21 (UTC)[回复]
@Hamish、Aqurs、AT、阿南之人：不好意思我这里回复的有点晚了。阅读上方的讨论之后可以有以下共识：界面管理员的当选条件属于事实性修订，因此实际上无需进行这么长时间的公示便可以直接修改；由于这一当选条件是事实性修订，因此在本次选举之中使用75%作为当选条件并没有不妥当的地方。我已对方针进行了修订，这一讨论可以关闭了。 Stang1356 2025年5月6日 (二) 00:32 (UTC)[回复]
@Aqurs1：补ping Stang1356 2025年5月6日 (二) 00:36 (UTC)[回复]

公共運輸相關指引再次討論

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:交通車輛條目指引、Wikipedia talk:公共交通路線條目指引、WikiProject talk:城市軌道交通、WikiProject talk:鐵道。

近日整理交通相關條目屢遇交通迷持續加入過度著色的文字以及原創研究內容，因此在此重提建立相關指引，已知目前已有的相關草案有Wikipedia:交通車輛條目指引以及Wikipedia:公共交通路線條目指引，在此提出討論，希望這次有一個結論。相望能做個了結，拖太久了XD--🚊　鐵路Railway 論．簽 2025年4月17日 (四) 04:32 (UTC)[回复]

邀請先前參與討論或編輯的維基人@LuciferianThomas、Ghrenghren、BIT0865、一片枫叶、心平星辰、owennson、台南賴哥、SickManWP、捷利、Cdip150、Olaf8940、Tisscherry、Sanmosa--🚊　鐵路Railway 論．簽 2025年4月17日 (四) 04:53 (UTC)[回复]

交通車輛條目指引

現行條文

無

提議條文

維基百科收錄交通車輛相關主題，機動車輛、鐵路等車款也能開設条目。但為交通車輛開設條目前，編者務需找出若干可靠、獨立的第二手来源，舉證主題具備收錄標準。一方面，收錄標準決定主題是否需要開設獨立條目；另一方面，符合收錄標準就意味著有優質來源支撐，編者能寫出全面的條目。收錄標準得證後，編者就可以編寫條目。

條目在描述車輛概況的同時，還要像可靠來源一樣介紹設計、規格、構造等內容；維基百科不歡迎交通迷內容，編者切勿沉淪於過度的細節。

以下介紹交通車輛主題可能用到的元素，撰寫條目時請按實際情況適時選用和調整。如果您有想法或疑問，請在討論頁面進行討論。除此之外，您還應該熟悉WP:更優秀條目寫作指南。

信息框模板 信息框是展示主題關鍵信息的表格，桌面版瀏覽多置於條目右上角，流動版瀏覽僅次於起首段。交通車輛信息框一般包括車型名稱、製造商、首次出廠年份、圖像等資料。某些技術設定對理解車輛整體至關重要，也會記入信息框。「關鍵」的車輛信息因車種性質而不盡相同。與所有信息框一樣，交通車輛的信息框應該避免瑣碎的細節。

您可以在Category:交通信息框模板找到合適的模板使用，一般來說，鐵路車輛條目通常採用{{鐵路車輛}}、{{鐵路車輛2}}等，機動車輛通常採用{{Infobox Automobile}}等，具體使用方法請見相關信息框內的文檔。 導言 導言應精要概括正文，一般來說會簡述製造商、車輛類型等，如車輛被用於公共客運服務，則車輛所屬的客運或鐵路公司、服務路線、投入服務日期等也可簡述。 背景與概述 本段應說明該型車輛出現的背景與開發緣由，例如是否為因應運量成長、汰換老舊車輛、導入新技術，或配合政府交通政策與營運策略所開發。可說明規劃與製造過程中的主要考量與階段目標。若車輛已退役，亦應交代退役決策背景，包括技術老化、維修成本、替代方案等因素。此外，也可概述該車型在所屬交通系統中的定位與功能，或介紹其在營運歷史中的角色與貢獻，例如是否為首批引進某項技術的車型，或曾參與重大路線開通。 規格與構造 介紹車輛的核心技術，詳細說明其結構、系統與外觀特徵。內容可涵蓋車體材質、設計風格、動力系統（如內燃、電動、混合動力）、機電設備與各項設備規格，並說明編組形式、定員數量及無障礙設施等乘客相關配置。車輛外觀如塗裝、標誌、顯示系統，內裝如座位配置、資訊顯示與空調等。撰寫時應依據可靠來源進行整合與概述，避免過度細節化或直接複製廠商資料，並避免使用過度細節化的術語堆砌內容。 各代歷程 若車輛型號生產超過一代，或具明確的子型號與改良版本，應在本段加以系統性地區分與說明。可依世代順序介紹各版本的開發背景、設計調整、生產時程及投入營運的情況，並指出相較前代在技術或使用層面的主要差異。若某一代僅有小幅修改，可簡要帶過，避免過度拆分。撰寫時應聚焦於型號整體演進的脈絡，避免逐輛記述個別車輛細節，以維持條目的條理性與通用性。 重大事故 若該型車輛曾涉及重大事故，尤其是造成大量人員傷亡或引發媒體廣泛關注者，應於本段簡述相關事故。敘述內容包括事故的時間與地點、涉及單位、造成的損害與影響。若事故本身已具備獨立條目，則可使用{{main}}作主條目導向，以便讀者深入閱讀。事故描述應以中立、簡潔為原則，避免渲染或情緒性文字。 車輛保存 若該型車輛已退役，並有完整保存案例，應介紹其保存狀況與保存地點，包括是否由博物館、學術單位或民間團體保存，是否對外展示，以及保存的原因或文化價值。若保存車輛為特定號碼、原型車或紀念車，也應說明其特殊性與保存背景。此段僅限於有可靠來源佐證之公開保存資訊，不應記錄私人收藏或網路傳言。 参考来源 条目必须遵循可供查证的要求，并將對應的可靠来源以内文引用形式来支持条目。 分類 為方便讀者搜尋，車輛條目可按核心主題或行業元素歸類，如在新幹線行駛的車輛應歸入Category:新幹線車輛。但請注意，分類應簡明扼要地描述主題，不可過濫。以蒸汽機為動力的車輛可歸入Category:蒸汽機車或其子分類；但純粹因有明火出現而歸類則不合適（例如車輛曾發生火燒車事故而將該車輛歸入火災相關分類則不適當）。過度歸類只會淡化分類的應有效用。 應避免的事情 愛好者內容 維基百科不是不經篩選的資訊收集處，車輛車次運用、車號機務段分配、改造期程、交車期程、領牌車號、行駛路線、停靠站牌等瑣碎資訊並不適宜加入到條目內。條目不應存在任何原創研究的內容。如果有必要，可以移到維基教科書、維基學院等其他維基計劃，又或者到其他專門的Wikia撰寫。 大量的短條目 通常一個較大的條目能提供對主題更有條理的介紹與背景聯繫。當大條目能做到時，請不要創建大量小條目。理想的條目是既不過大，也不過小。 過多的圖片 請勿於條目內放置各車號的照片，於資訊框模板一張代表即可，其他照片則放入共享資源並於底下納入共享資源連結導引 大量的粗體與文字上色 請勿於條目內為文字過多粗體與上色，行駛路線、領牌車號、特殊備註等，如路線有顏色區分需求請使用表格填色，不要為每個路線明上色。

以上條文由在下草創Cdip150君重整，在此提出討論與公示。--🚊　鐵路Railway 論．簽 2025年4月17日 (四) 04:39 (UTC)[回复]

不是，你真確定這是寫完的草案嗎？Sanmosa 新朝雅政 2025年4月17日 (四) 05:43 (UTC)[回复]
還沒完成，只是全文拿出來看看各位有哪些修改意見。--🚊　鐵路Railway 論．簽 2025年4月17日 (四) 06:22 (UTC)[回复]
背景與概述、規格與構造、車輛保存三者好歹先擴充一下才拿出來吧，不然我是真的無法給任何的意見。Sanmosa 新朝雅政 2025年4月18日 (五) 13:47 (UTC)[回复]
大致沒有太大意見，若有其他維基人發表看法本人會加以回應。--維基病夫❤️邊緣人小組·簽到 2025年4月18日 (五) 04:03 (UTC)[回复]
同Sanmosa，指引仍尚未完善。--Aqurs 2025年4月20日 (日) 14:23 (UTC)[回复]
@Sanmosa、Aqurs1：已擴充更新，還請指教。--🚊　鐵路Railway 論．簽 2025年4月21日 (一) 08:29 (UTC)[回复]
(＋)支持，一堆交通迷写车辆调动、编号，甚至是牵引系统、空调、电池箱的型号和种类，这些琐碎信息完全不是一般人所关心的，也没必要保留。（举例：廣州地鐵一號線列車、广州地铁三号线北延段列车），我敬佩交通迷实地探访总结资料的能力和勇气，但这不适合维基百科。--自由米花🌾🌼 2025年5月2日 (五) 04:34 (UTC)[回复]
“这些琐碎信息完全不是一般人所关心的”，这一点我同意。但是除了维基百科，中国大陆已经没有别的地方可以放置这些琐碎信息了，这是很可怕的事情。交通爱好者群体内部也是有纷争的，写车辆调动的反感写牵引系统的，写牵引系统的反感写车辆调动的，有必要就保留哪些信息达成共识。至少我认为，空调、电池箱可写可不写，但是电机主逆辅逆这三大件要留——缺少任何一个都无法构成完整的牵引/辅助系统。BIT0865 · Discussion · 燕房线永远的神！ 2025年5月8日 (四) 05:06 (UTC)[回复]
不同意您说的“除了維基百科，中國大陸已經沒有別的地方可以放置這些瑣碎資訊了，這是很可怕的事情。”，(►)移动到维基学院是可行的选择。--自由米花🌾🌼 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年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) 😄1[回复]
如果你不用人話，偏要用LLM生成這堆難以閱讀沒有實質意義的內容的話，我也只能(－)反对，還請您真的要提案就拿出您自己的對策--SunAfterRain 2025年4月19日 (六) 04:25 (UTC)[回复]
我不確定這是不是行為藝術，不過本站目前有人工智慧相關規範嗎？之前討論過幾次，但我不是很確定。順便問問@Shizhao（ —— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月19日 (六) 05:04 (UTC)[回复]
反对2和3。这两条本质上仍是认为ai不如人类，与第1条矛盾。且不利于充分利用新技术的潜力。在我看来，AI的写作能力完全不比许多人类编者弱，没有必要歧视。我认为更合理的方案是进行“含有ai创作“的声明，含有这个声明的内容，可以针对ai的弱点，如编造参考文献等进行针对性的检查。同时应该在方针中提醒编者ai常犯的错误。现有方针没有这方面的指引。--IuyminirC（留言） 2025年4月19日 (六) 07:46 (UTC)[回复]
AI的弱点可能与参数、目标内容、提示词等多重因素相关，不比人类弱、无需歧视的条件不能始终满足。“写作能力”可能是用词书写能力，但编造内容和风格假大空等现象仍严重，编者有时也难以查证与精简──相当于重审与重写？以及这些内容的增长会对人类撰写条目的风格及热情构成影响，就如欧化中文。--YFdyh000（留言） 2025年4月20日 (日) 14:39 (UTC)[回复]
对“以下规范”回应：1. 这可能是理论上的正义，但缺少可行的执行方案。例如，AI生成内容的著作权争议，没有能力与标准做审查评估。2. 理论上正义。AI内容标注规范更有价值，如果真的要接纳一些。3. 复核者的责任和压力较大，要么过松，要么比自己写还累。--YFdyh000（留言） 2025年4月20日 (日) 14:32 (UTC)[回复]
有幸读过你先前疑似用LLM写的一篇草稿（现已被删除），那篇草稿的质量我想足以给这个话题盖棺定论了。——Mirfaek 2025年4月21日 (一) 12:42 (UTC)[回复]
強烈反對用AI生成的條目，但AI翻譯是可以接受的。August討論‧簽名‧回復請ping 2025年4月27日 (日) 04:30 (UTC)[回复]
(－)反对，同U:SunAfterRain君的意见--KurGenera(留言) 2025年4月29日 (二) 16:55 (UTC)[回复]
(～)補充：阁下连ai习惯的markdown代码都没有修成wiki代码，故我正在思考...是否应该(－)強烈反对
毕竟ai写wiki代码的能力真的堪忧，还经常违反WP:5P1和WP:5P2，真的会把所有喂鸡人全部气到精神分裂--KurGenera(留言) 2025年4月29日 (二) 17:05 (UTC)[回复]
讲得很好，所以这個提案提出了什麼新的内容吗？通过之後会有任何变化吗？ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年5月3日 (六) 15:59 (UTC)[回复]
你维的垃圾已经够多了，如果担心垃圾少的话可以往自己的用户页多倒倒。--—远方传来风笛（Talk） 2025年5月7日 (三) 19:53 (UTC)[回复]
讨论还请注意WP:文明--IuyminirC（留言） 2025年5月8日 (四) 01:05 (UTC)[回复]
有人管别人叫牲口都不违反CIV，我说人家写的东西是垃圾怎么了？毕竟这玩意出现在喂鸡白料没见有多少用处。--—远方传来风笛（Talk） 2025年5月8日 (四) 01:28 (UTC)[回复]

有關申請權限與申請解除權限的方針條文與申請區的放置問題

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:權限申請、Wikipedia talk:解除權限、Wikipedia talk:申请解除权限。

WT:方針與指引#修訂方針與指引的命名格式曾經提到有關申請權限與申請解除權限的方針條文與申請區的放置問題，當時Ericliu1912提議WP:解除權限比照WP:權限申請的處理併入WP:申请解除权限，而我則反建議WP:權限申請比照WP:解除權限與WP:申请解除权限的處理分拆方針條文與申請區的頁面。考慮到現在距離批量調整規則頁面名稱已經有一段時間，社羣或許應該探討到底要選擇哪個方案，我自己對於兩個方案均持開放態度。Sanmosa 新朝雅政 2025年4月20日 (日) 10:12 (UTC)[回复]

我主張合併的理由是解除權限方面的方針頁跟申請頁都比權限申請要短，而且兩者並沒有扞格問題，不必分立，也方便檢閱者一次確認有關要件。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月20日 (日) 12:55 (UTC)[回复]
然後剛剛纔注意到甚至申請頁面整段說明都是「包含引用自維基百科:解除權限方針」，沒有任何內容差異，所以實際上兩者完全可以合併在一起啊== —— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月20日 (日) 12:56 (UTC)[回复]
合併在同一頁不易檢視方針指引的修訂歷史。--Xiplus#Talk 2025年4月22日 (二) 15:36 (UTC)[回复]
如果走Ericliu1912方案的話，可以讓除權申請區改為比照現WP:權限申請的申請區處理，也就是每類除權申請一個獨立的子頁面。Sanmosa 新朝雅政 2025年4月25日 (五) 12:35 (UTC)[回复]
@Xiplus？還是說你比較傾向於分拆WP:權限申請頁？Sanmosa 新朝雅政 2025年4月29日 (二) 07:18 (UTC)[回复]
我覺得應該廢除該頁的方針地位，因為該頁面幾乎都是複述各權限方針的內容而已。如果真的有任何應該屬於方針層級的內容，應當拆分到各權限介紹頁或另立「權限申請方針」頁面。--Xiplus#Talk 2025年4月29日 (二) 14:45 (UTC)[回复]
@Ericliu1912。Sanmosa 新朝雅政 2025年4月30日 (三) 01:58 (UTC)[回复]
這很值得考慮！—— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月30日 (三) 05:54 (UTC)[回复]
@Xiplus、Ericliu1912：如此，那WP:權限申請的版面或許需要重新設計，此外WP:申请解除权限引述現WP:解除權限方針的部分也需要作一定的調整，個人建議可以參考現WP:存廢覆核請求頂部的說明文字處理。Sanmosa 新朝雅政 2025年4月30日 (三) 14:45 (UTC)[回复]
改寫成最合適的說明文字當然可以，但我不認為現在兩個申請頁的說明有什麼不得不改的問題。--Xiplus#Talk 2025年5月4日 (日) 04:28 (UTC)[回复]
@Xiplus：那我嘗試在今日稍後給一個方案出來。Sanmosa 新朝雅政 2025年5月8日 (四) 04:47 (UTC)[回复]
現階段擬定的方案是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)[回复]

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

本主題全部或部分段落文字，已移動至Wikipedia talk:翻譯。执行者：Jimmy-bot（留言） 2025年5月10日 (六) 00:14 (UTC)。[回复]

提議提升巡查員的門檻

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:新頁面巡查、Wikipedia talk:權限申請。

原标题：提議提升巡查員及回退員的門檻。修改者：--此條未簽名留言由Aqurs1（討論｜貢獻）於2025年4月26日 (六) 12:34 (UTC)加入。[回复]
因應此討論串，提議提升巡查員及回退員的門檻。--Aqurs 2025年4月26日 (六) 08:22 (UTC)[回复]
由於已經得知WMF不容許此等方法自動獲取「臨時IP檢視」權限，目前考慮到巡查員門檻仍然過低，繼續討論是否應該提升巡查員的門檻。註冊時間也不需要因「檢視臨時帳戶IP」而有所限制，暫且改為跟回退的90日，目前提案改為是否將巡查員門檻提升至跟回退一樣，謝謝。Aqurs 2025年4月26日 (六) 12:34 (UTC)[回复]

巡查員

提高巡查員門檻

現行條文

巡查員：需編輯至少250次，自首次編輯以來參與維基百科至少30日，最近一年內沒有受到封鎖（不合理封鎖除外），且在過去三個月內（新註冊者由註冊日起計至申請當日）平均每天的編輯次數多於一次。

提議條文

巡查員：需編輯至少1000次，自首次編輯以來參與維基百科至少90日，最近一年內沒有受到封鎖（不合理封鎖除外），且在過去三個月內平均每天的編輯次數多於一次。

(－)反对：巡查回退员有需要且满足查看临时账户IP信息资格可自行申请，且目前WP:RFR未见积压。Python6345（查论编） 2025年4月26日 (六) 11:24 (UTC)[回复]
@Python6345：預見的是社群將會人手授予「檢視臨時帳戶IP」的用戶組，這樣會造成大量積壓，跟現在未見積壓有什麼關係？--Aqurs 2025年4月26日 (六) 11:41 (UTC)[回复]
目前有194名回退员和163名巡查员。而考虑到其中有同时持权者且查看临时账户IP权者可以提前申请并在添加用户组后由机器人一次性授予，亦难以预见积压存在。反而大幅增加巡查员门槛会加重巡查积压。Python6345（查论编） 2025年4月26日 (六) 12:16 (UTC)移除于2025年4月27日 (日) 04:53 (UTC)，因为提案内容改变。[回复]
(＋)支持，加入一个月的新手显然不适合当巡查、回退员。Пусть от победы☆к победе ведёт! 2025年4月26日 (六) 12:27 (UTC)[回复]
@阿南之人：見上方留言，提案修改了，你可能需要再審視一下你的支持票。Aqurs 2025年4月26日 (六) 12:34 (UTC)[回复]
（由“180日”改为了“90日”87000812。）——自由雨日🌧️❄️ 2025年4月27日 (日) 03:17 (UTC)[回复]
也不一定，我印象最深刻的就是@U:Summerize在未成为延确之前就担任了巡查员，而且行事非常成熟。 ——自由雨日🌧️❄️ 2025年4月27日 (日) 03:17 (UTC)[回复]
虽然支持，个人在观察中发现，其实巡查员在事实操作中[來源請求]获取难度高于回退员。--花开夜 留言 ·签名 ·贡献 2025年5月5日 (一) 17:53 (UTC)[回复]
我个人还是建议设定更加详细的标准。比如，创建一定数量的条目和DYK，或者一定数量的WP与主条目编辑数量等。--花开夜 留言 ·签名 ·贡献 2025年5月5日 (一) 17:54 (UTC)[回复]
(！)意見 没有看到明显依据，个人倾向折中，至少500次、至少60日。--YFdyh000（留言） 2025年4月26日 (六) 14:48 (UTC)[回复]
巡查員没必要更严格，巡查员本身没有什么高级权限--百無一用是書生 (☎) 2025年4月27日 (日) 02:31 (UTC)[回复]
@Shizhao：我是同意這點，不過回退員為何要求如此高？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月27日 (日) 05:58 (UTC)[回复]
WP:ROLL#回退功能的优点也可用于在编辑战中占据优势，此外回退员可以访问私有过滤器的日志。Python6345（查论编） 2025年4月27日 (日) 06:39 (UTC)[回复]
1000次确实有些多，另外是否可以增加豁免项，比如老用户以新账号开始、在其他维基有相当权限或者比较多的经验。--Kethyga（留言） 2025年4月27日 (日) 03:12 (UTC)[回复]
“老用户以新账号开始”应该视为一个全新的账户，不应进行豁免；其他站点的情况确实可以作为一些参考来稍微降低一些标准，但是不能达到完全“进行豁免”的程度。 Stang1364 2025年4月27日 (日) 07:04 (UTC)[回复]
(＋)支持提升到與回退員相同。August討論‧簽名‧回復請ping 2025年4月27日 (日) 04:23 (UTC)[回复]
(－)傾向反對：目前巡查员申请需要有巡查记录证实能力，且巡查有问题者会在申请阶段被拒绝，不认为有提升门槛之必要。Python6345（查论编） 2025年4月27日 (日) 04:53 (UTC)[回复]
(＋)支持，原本條件太寬鬆，新使用者在中文維基百科站務規定還不甚了解時，就能輕易申請，這情況著實不合理。我也認為必須施加更嚴謹的申請條件，以免浮濫申請權限的情況發生，有些人就是想當一個帽子（維基頭銜）蒐集狂，最近的不當行為頁面剛好有一個例子。--Znppo（留言） 2025年4月27日 (日) 06:57 (UTC)[回复]
(？)疑問：請問是哪位仁兄？--自由米花🌾🌼 2025年4月28日 (一) 13:30 (UTC)[回复]
U:Peterxy12，编辑数不足100即申请多个本地和全域权限。Python6345（查论编） 2025年4月28日 (一) 13:50 (UTC)[回复]
（编辑冲突）我猜他想说的应该是这位，不过这位我觉得不是帽子收集狂而是扰乱了…… ——自由雨日🌧️❄️ 2025年4月28日 (一) 13:52 (UTC)[回复]
(：)回應，我說的就是他XD。--Znppo（留言） 2025年4月28日 (一) 14:00 (UTC)[回复]
不是扰乱--Peterxy12（留言） 2025年4月29日 (二) 10:27 (UTC)[回复]
硬性門檻似乎不用那麼高，五百次／兩個月應該夠吧？另外或應說明這是一般建議門檻，若有顯著例外，亦可破格申請。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月28日 (一) 18:31 (UTC)[回复]
(＋)支持提高標準--🚊　鐵路Railway 論．簽 2025年4月29日 (二) 04:29 (UTC)[回复]
纯粹给个建议方向：个人觉得提高门槛也不一定只看编辑数量，也可以从条目编写、模拟巡查和参与条目（存废）讨论等方面考察能力。当然这样就难以量化了。--Steven Sun（留言） 2025年4月29日 (二) 07:54 (UTC)[回复]
当前巡查员申请必须有巡查记录，否则会被快速拒绝，且如有用户质疑巡查不当亦需要合理回应。Python6345（查论编） 2025年4月29日 (二) 10:19 (UTC)[回复]
如果要提升巡查員的門檻的話，是否應該考慮要求巡查員同時滿足巡查豁免者的門檻？Sanmosa 新朝雅政 2025年4月29日 (二) 12:02 (UTC)[回复]
我一直很困惑这点。巡查员既然有巡查豁免者的权限，那当然要求不应该低于巡查豁免者，这应该是个逻辑问题吧？（要么就规定巡查员并不能让自己免于巡查，这样也可合乎逻辑。）似乎之前有过多次类似提案但均未通过。 ——自由雨日🌧️❄️ 2025年4月29日 (二) 12:09 (UTC)[回复]
我在WT:新頁面巡查/存檔3#取消巡查员的巡查豁免权已經提出過「醫者不自醫」的情況，而且也明確指出了「巡查員有巡查別人條目的能力也應該有巡查自己條目的能力」這種說法不對應中文維基百科的現況，但還是存在個別用戶對實際情況視而不見的事情。Sanmosa 新朝雅政 2025年4月29日 (二) 12:39 (UTC) 👍1[回复]
巡查员身具巡查豁免权、自动免巡印象中算技术问题。您可换角度看，巡查员的豁免与巡查豁免者是相同权限但不同缘由，场地工作人员免于安检/员工通道，极少数嘉宾或委员免于安检，不等于前者需具后者级别。但我仍支持对巡查员被豁免的页面做统计列出并存档以履行复审，或者变相削弱自动免巡（Sakamotosan拒绝接受机器人workaround方案）。--YFdyh000（留言） 2025年4月29日 (二) 20:45 (UTC)[回复]
正常情況下，如果巡查員確實有有巡查自己條目的能力，那現狀並非一個問題，然而現狀並非正常情況，那也就只能如此管制了。Sanmosa 新朝雅政 2025年4月30日 (三) 14:47 (UTC)[回复]
顯然應該彈劾你所說案例，而非反過來降低全體巡查員授權標準。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月2日 (五) 09:08 (UTC)[回复]
這不現實，真按你這樣説的話，全部巡查員都得除權。Sanmosa 新朝雅政 2025年5月2日 (五) 13:01 (UTC)[回复]
既然全部巡查員都得除權，不妨指出几个近期巡查员滥用巡查豁免的案例。Python6345（查论编） 2025年5月2日 (五) 13:19 (UTC)[回复]
拿日期20220626寫的條目來說好了：他在今年4月30日建立的马达加斯加起义條目裏來源與句號之間不知為何出現了空格，而且條目內的兩個來源實際上是同一個來源（Special:Permalink/87050726）；他在同日建立的九州风神條目裏來源與句號之間、英文與括號之間也不知為何出現了空格，而且內文的表述也不清不楚，我甚至還不知道九州風神是想要在哪個創業板上市（Special:Permalink/87054660）。Sanmosa 新朝雅政 2025年5月3日 (六) 02:56 (UTC)[回复]
然後再拿MykolaHK寫的條目舉例：克里米亞韃靼飲食條目是他在昨天建立的，整個條目只有一個來源，“傳統菜餚”章節完全沒有來源，而且還是點列；開爾文橋站條目是他在今年2月16日建立的，大部分正文文段無來源支持，而且整體的翻譯水平實在不太好（比如“且是迄今為止保留此配置的最繁忙的車站”）。Sanmosa 新朝雅政 2025年5月3日 (六) 03:13 (UTC)[回复]
对于这点我只能认为做翻译的基本上就是忠实翻译，很少人会自己去找来源，当然如果原本的条目有问题那就两边都挂维护模板就好了¯\_(ツ)_/¯翻译腔也是，也得挂上维护模板。--KurGenera(留言) 2025年5月3日 (六) 03:25 (UTC)[回复]
然而巡查權自帶的巡查豁免權使之實際上基本無法實現。Sanmosa 新朝雅政 2025年5月3日 (六) 03:58 (UTC)[回复]
(：)回應Sanmosa：謝謝建議。關於克里米亞韃靼飲食，確實來源較少，會先挂維護模板，但這裏我認爲點列是可以接受的，畢竟這裏是介紹各菜式。而開爾文橋那邊雖然有10個來源，但不得不承認正文來源確實較少，這裏也會先挂維護模板，另外想問您認爲「且是迄今為止保留此配置的最繁忙的車站」這句該如何表達？謝謝。--Mykola（留言） 2025年5月3日 (六) 10:29 (UTC)[回复]
「且是迄今為止保留此配置的車站中最繁忙者」或許較好。Sanmosa 新朝雅政 2025年5月3日 (六) 15:05 (UTC)[回复]
没有感觉更好。虽然之前也觉得两个“的”不太好，但细看我觉得没问题。问题可能在“保留此配置”的具体意涵（淘汰了吗），繁忙统计范围未指明（线路、城市、全球），以及没有列明来源，{{when}}。--YFdyh000（留言） 2025年5月3日 (六) 15:15 (UTC)[回复]
@YFdyh000：你或許需要結合前文來看，不結合前文來看的話，你自然看不出個所以然來。Sanmosa 新朝雅政 2025年5月4日 (日) 01:22 (UTC)[回复]
前文也没说月台。--YFdyh000（留言） 2025年5月4日 (日) 03:00 (UTC)[回复]
我懷疑是沒完全翻譯的鍋。Sanmosa 新朝雅政 2025年5月4日 (日) 13:09 (UTC)[回复]
巡查員理當能巡查任何條目（無論是直接改善或是補充標記），不分對象，那自然也包含自己建立的頁面。做不到這點，那就除權，沒問題。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月4日 (日) 13:23 (UTC)[回复]
很多情况是应该发现、注意和提醒，而做不到弹劾。是提升而非降低标准？--YFdyh000（留言） 2025年5月2日 (五) 22:35 (UTC)[回复]
看了一下Wikipedia_talk:新頁面巡查/存檔3#提案四、Wikipedia_talk:新頁面巡查/存檔3#使巡查员可以移除或增加自己的巡查豁免者权限，社群似乎比較接受這個方向的變革，社群可以嘗試朝著這個方向繼續討論下去，會比較容易形成共識。~~Sid~~ 2025年5月3日 (六) 13:40 (UTC)[回复]
(＋)强烈支持，个人认为：
現行條文

巡查員：需編輯至少250次，自首次編輯以來參與維基百科至少30日，

提議條文

巡查員：需編輯至少3000次2000次1500次，自首次編輯以來參與維基百科至少120日90日，

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

重提允許巡查員自我增加與移除自動巡查權/將自動巡查與巡查員權限組分離

由於我看到上面有這方面的討論需求，所以我單獨拉出來討論提高效率也較易於分別社群共識。
過往討論參見Wikipedia_talk:新頁面巡查/存檔3#提案四、Wikipedia_talk:新頁面巡查/存檔3#使巡查員可以移除或增加自己的巡查豁免者權限
另外我對於提案是沒有什麼特別的意見，請不要因為我單獨拉出討論而視為我支持這個提案，謝謝。~~Sid~~ 2025年5月7日 (三) 14:30 (UTC)[回复]

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

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:用户权限级别。

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

WP:常年提案#修改自动确认用户的门槛。閣下如果能提出個方案解決疑慮，或許也能有共識。--WiTo🐤💬 2025年4月29日 (二) 10:46 (UTC)[回复]
@WiTo7946：但我的困惑是具體的“疑慮”是甚麽？或許先探討“疑慮”本身的合理性，然後再談如何處理或解決“疑慮”會比較好。Sanmosa 新朝雅政 2025年4月29日 (二) 12:00 (UTC)[回复]
老實說我沒怎麼想參與這話題，我認為我無法判斷這上或下調對本維到底有沒有益，與其煩惱這個我還不如多寫幾個條目罷。--WiTo🐤💬 2025年4月29日 (二) 13:21 (UTC)[回复]
(－)強烈反对降低自确门槛编辑次数，但(＋)支持废除验证码或(＋)支持把时间减少到3天。
7天50次编辑，一个有闲的用户随便编修/修理内链都能1天轻松上50次编辑¯\_(ツ)_/¯比如鄙人就是注册3天后编辑次数100+😂不过加入4—7天这会就难受了，一直要输验证码╰（‵□′）╯
但是鄙人建议降低延伸确认用户门槛的时间¯\_(ツ)_/¯90天让鄙人很难受--KurGenera(留言) 2025年4月29日 (二) 16:32 (UTC)[回复]
(～)補充：防马甲。--KurGenera(留言) 2025年5月1日 (四) 18:57 (UTC)[回复]
是否是英文维基的参与度（人数）较多，所以应付破坏者/新人的反破坏力量更充足。另外是否有包容度差异。--YFdyh000（留言） 2025年4月29日 (二) 20:57 (UTC)[回复]
還是沒人能解釋當時具體的“疑慮”是甚麽嗎？我連具體的“疑慮”是甚麽都不知道，我實在無法作任何進一步的評斷。Sanmosa 新朝雅政 2025年4月30日 (三) 02:01 (UTC)[回复]
WP:刷编辑数的难度--YFdyh000（留言） 2025年4月30日 (三) 02:13 (UTC)[回复]
(：)回應，刷編輯數真的不難，舉例，加個分類、取代新分類，來回弄一弄就上百個編輯數了，我個人認為是無難度。中文維基百科自動確認用戶門檻也才50個編輯數，已經很低了。加上中維社群人員不多，沒有像英文維基百科社群人員那麼多，有那麼多雙眼睛幫忙看著，故我認為門檻數高一點還是好的。--Znppo（留言） 2025年4月30日 (三) 14:46 (UTC)[回复]
如果新人手动去干该机器人做的批量重复性业务，可能是引导问题。如果得当或有争议的改动数十次，也能部分看出他对本站的理解，应该不算无难度。假如做出了毫无争议的几十次小编辑，傀儡的概率提升。--YFdyh000（留言） 2025年4月30日 (三) 21:37 (UTC)[回复]
我的看法是既然「刷編輯數真的不難」，那編輯次數的門檻實際上與安全風險無直接關係。Sanmosa 新朝雅政 2025年4月30日 (三) 23:41 (UTC)[回复]
(：)回應，我個人覺得自動確認用戶權限的編輯次數拉長一點，保持目前50次，有其必要性。理由為若是一般新手，由於不熟悉維基百科規則，可能無法如此快速湊到50次編輯數。
我舉個例子，持續出沒的破壞者LTA:人瑞，此君就很不熟悉維基百科規則，他曾有一個分身帳號，未曾被發現，詳見User:Hsiw19372的編輯貢獻，他也是熬了快兩個星期，才湊滿50次編輯數，成功取得自動確認用戶權限，隨即移動草稿條目，進行破壞。我無法想像如果自動確認用戶權限若改為10次，情況會混亂成何種樣子。--Znppo（留言） 2025年5月1日 (四) 11:32 (UTC)[回复]
但我們也總不可能假定所有新用戶為LTA。Sanmosa 新朝雅政 2025年5月2日 (五) 08:34 (UTC)[回复]
可能您好，个人体验是，这个要求也就是7天有硬性压力，至于50次，我个人体验是学会自动确认用户专用的维基语法需要的编辑数大于50次，可以说压力被稀释了。望楼主回复为盼--Mahengrui1（留言） 2025年5月1日 (四) 04:09 (UTC)[回复]
硬编辑次数的确不难，但容易判断为Wikipedia:游戏维基规则，也可以人为判断。我认为正常编辑下，7天+50次编辑基本可以筛走一部分过路用户，并且自动确认用户是很多基础意见表达讨论的基本条件，这样“严”的规定可以间接判断用户对项目的参加程度、一些规则的理解程度和意愿程度。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月2日 (五) 11:11 (UTC)[回复]
我好奇的是，究竟編輯次數還是參與時間門檻比較有利於阻礙擾亂呢？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月2日 (五) 16:10 (UTC)[回复]
都有助预防一鼓作气的扰乱，一个是批量操作可达，一个是耐心等待（处心积虑）可达。--YFdyh000（留言） 2025年5月2日 (五) 22:41 (UTC)[回复]

關於近期 DYK 條目出現「孤立條目」現象之討論與徵詢意見

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:新条目推荐/候选、Wikipedia talk:孤立页面。

无共识：
暂时不硬性要求条目链入其他页面--Jeffchu2014（留言） 2025年5月10日 (六) 15:59 (UTC)[回复]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

近來在瀏覽或參與Wikipedia:新條目推薦（DYK）提名與審查過程時，發現一個值得關注的傾向：有部分條目雖然在內容品質與新穎性方面表現良好，但其與現有條目的連結極少，有的甚至僅存在於消歧義頁面或單一來源條目中，導致這些條目呈現「孤立狀態」。

以往 DYK 評選較常強調條目的首段表述、來源可靠性與是否符合「新建條目」的時間門檻，然而隨著條目主題日益冷門化、專精化，若未與相關條目建立適當的內部連結，恐將影響：

  • 條目的可見度與後續閱讀引導
  • 條目的長期維護與頁面存活率
  • 維基百科條目網絡的整體連貫性與可探索性

因此，想在此向社群提出以下問題，徵詢各位的意見：

  1. 是否認為 DYK 條目應該在可行範圍內盡量避免孤立狀態，例如要求提名者嘗試在主題相關條目中加入內部連結？
  2. 我們是否應考慮在 DYK 提名頁或模板中加入建議性提醒，鼓勵條目與主題主條有互鏈關係？
  3. 有無其他可行方式，能在不過度提高提名門檻的情況下，兼顧條目品質與條目網絡建構？

在下希望透過徵詢與交流，為DYK條目的完整性更上一層樓，歡迎各位編者踴躍提出看法。--David Jackson(留言) 2025年5月5日 (一) 08:31 (UTC)[回复]

@David Jackson：是否可以舉些實例呢？否則難以具體討論。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月5日 (一) 13:18 (UTC)[回复]
提供以下條目讓閣下參閱：
--David Jackson(留言) 2025年5月6日 (二) 01:47 (UTC)[回复]
所以具體危害是什麼？比如說我自己寫的點校本二十四史這樣，我看除了{{二十四史}}導航模板和與之相關的頁面以外，一個連入都沒有。為什麼條目的可見度是危害？為什麼和現有條目連結過少，會影響長期維護？和頁面存活度有什麼關係？頁面刪除與否，本來就是點擊率沒有關係的。你維的條目網絡本來就是一團垃圾，你維的讀者本來就有很大部分是從搜索引擎進入的，沒有其他條目連入影響也不會太大吧。--Ghren🐦🕚 2025年5月5日 (一) 15:52 (UTC) 👍2[回复]
感謝您的回應，我理解您對「條目連入」重要性的質疑，也同意不是每一個條目都需要有大量連入才會被閱讀或維護良好。
不過這裡提出的觀點，並非要將「條目可見度不高＝危害」劃上等號，而是想探討在 DYK 這樣一個「曝光機會高」、「條目仍在早期發展階段」的情境下，是否能善用這個時機，促進條目更快進入條目網絡，讓讀者不只能從首頁點進來，也能在主題相關條目中自然找到它。
當然，有些冷門主題條目本身就很難建立內部連結，那自然不會強求。而我希望討論的是：在可以的情況下，是否能鼓勵建立這種串聯，而不是將其完全忽略。
至於維護與刪除問題，我同意不是靠點閱數來決定，但條目若無上下文關聯、無人接續擴充或修訂，常常會面臨「維護者孤軍奮戰」的窘境。這是我觀察到的狀況，僅供大家參考。--David Jackson(留言) 2025年5月6日 (二) 02:11 (UTC)[回复]
我同意孤立頁面確實是應該儘量避免的問題。不過，這實在不能強求，要靠社群一起努力。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月6日 (二) 17:22 (UTC)[回复]
我好几年前一直在追踪每一篇参与DYK评选的条目的链入情况，近一两年因为个人精力有限没再追踪了。不过我就算是发现有DYKC条目缺乏链入页面，我做的第一件事情也是尽量自己去动手在别的条目当中添加链接至该条目的链接，除非我自己找不到合适的地方去添加条目链接，否则我一般不会在评选当中提这事情，本来这就不是DYK条目的硬性要求，只是能够避免孤立状态当然更好。--💊✖️2️⃣3️⃣（留言） 2025年5月6日 (二) 01:02 (UTC)[回复]
追蹤連入狀況是件很累人的事情(吃力不討好)，但就是希望集眾人之力或憑一己之力誕生的DYK條目，它的能見度能再提高。我一向認為每個條目都有它誕生的意義，能入選DYK更彰顯它的獨特之處，如果能在評選規則內加入善意提醒，請編者盡量在相關條目內增加引用與連結，這樣就可以避免產生孤立狀態。當然目前也只是先討論交流，並沒有說一定要執行。是否納入提醒內容，仍需建立共識後再作後續調整。--David Jackson(留言) 2025年5月6日 (二) 02:08 (UTC)[回复]
你觉得DYK条目应该避免孤立状态，就自己动手去合适的其他条目添加链入，你自己找不到合适的条目，可以去评选页请求他人帮忙，除非必要尽量别在评选页中以哪怕是建议的口吻说链入的事情，本来这就不影响DYK。我要和你一样觉得这值得更多人关注的话，我十年前就来互助客栈提出这问题了。--💊✖️2️⃣3️⃣（留言） 2025年5月6日 (二) 11:23 (UTC)[回复]
R-5 (导弹)那个可以通过{{俄罗斯和苏联导弹}}汇链入，已修正，连不上是因为导航模板对应链接名不对应。至于缺少链入的问题，参见Wikipedia:孤立页面，保障条目的链入度一定程度是有必要的。另外创建低链入的条目很可能是与其主要关联的条目还没有创建，或者没意识到可以通过已有的条目进行链入。我自己的例子就是避难所 (波特·鲁滨逊和麦狄恩歌曲)（2016年10月），这个条目就是看到相关的MV才考虑开题弄的，主要关联条目波特·羅賓森当时还没创建（题材不太熟，而且内容颇多而没准备翻译），可以关联并已存在的条目A-1 Pictures也是2016年11月才链出过去。现时一部分链入是依靠{{A-1 Pictures}}带入的。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月6日 (二) 05:11 (UTC)[回复]
孤立页面一直是个伪概念，对于条目质量的提升似乎也未见帮助巨大，不认为有特别关注的必要。另建议在起草讨论时避免过度使用AI。--—远方传来风笛（Talk） 2025年5月7日 (三) 13:58 (UTC) ❤️1[回复]
我只能說，勉強加上連結沒有必要。我當時還在想如何增加伊萬·斯維特的連結呢：是加在哈爾濱嗎？日本—烏克蘭關係呢？還是其他？很困難吧。勉強給其他條目加上連結，不就如連結農場的作法一般？--Saimmx（留言） 2025年5月7日 (三) 14:53 (UTC)[回复]
(：)回應：感謝各位的意見，讓我可以從不同角度思考，看來就先維持原狀吧。日後只要有空參與DYK評選，會盡我所能增加評選條目的連結，當然不會隨便亂連。再次感謝各位的回應與指教。🙏--David Jackson(留言) 2025年5月8日 (四) 08:26 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

為管理人員申請制度檢討事

大家可以討論一下之後有什麼需要改動的？比方說臨時管理員續任問題之類。—— 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%者，亦得獲授予為期六個月的「臨時權限」。此種權限與一般不限期權限無異，但應於任期結束前重新申請成為管理員，且申請支持率達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)[回复]

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

在人物傳記條目合理使用人物配偶的圖片

各位可先參考維基百科:檔案存廢討論/記錄/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對IPD持續與龐大的影響力，就算具體執行刪除操作的人不是Wcam，這很難說不是Wcam的意思。SCP-2000倒不是Wcam的傳聲筒，但Wcam對IPD持續與龐大的影響力本身就會影響處理IFD者的判斷。Sanmosa 新朝雅政 2025年5月10日 (六) 12:41 (UTC)[回复]
我的绝大多数意见都有方针作为依据，并非我的影响力大，而是相当数量的维基用户对于著作权相关方针规定有准确的认识。--Wcam（留言） 2025年5月10日 (六) 17:25 (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)[回复]

技術

本主題或以下段落文字，在討論結束後應存檔至Template talk:Navbox、MediaWiki talk:Common.css、Template talk:Hlist/styles.css。

之前開過，沒人回存檔了，例見沙盒。剛剛又稍微研究了一下，雖然不太懂不過應該找到問題所在了，似乎是Template:Hlist/styles.css line 143附近的first-child::before。希望懂行的幫忙處理一下，謝謝。--惣流·明日香·蘭格雷不姓式波 2024年11月30日 (六) 04:49 (UTC)[回复]

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

本地安全投票测试

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:安全投票。

於Phabricator追踪
工單T380020

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

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

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

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

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

本討論章節會維持開放，暫時不按最後意見發表時間存檔，直到测试完成。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

Category:非条目级XXX条目错误

本主題或以下段落文字，在討論結束後應存檔至Module talk:PJBSClass/main。

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

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

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

本主題或以下段落文字，在討論結束後應存檔至Talk:辽宁省、WikiProject talk:中国行政区划。

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

详细

沈阳市

和平区

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

沈河区

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

铁西区

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

皇姑区

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

大东区

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

浑南区

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

于洪区

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

沈北新区

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

苏家屯区

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

新民市

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

大连市

西岗区

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

沙河口区

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

甘井子区

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

旅顺口区

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

金州区

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

普兰店区

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

鞍山市

海城市

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

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

台安县

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

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

岫岩县

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

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

铁东区

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

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

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

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

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

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

铁西区

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

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

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

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

立山区

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

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

千山区

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

高新区

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

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

千山风景区

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


抚顺市

新抚区

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

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

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

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

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

东洲区

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

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

望花区

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

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

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

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

顺城区

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

本溪市

平山区

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

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

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

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

溪湖区

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

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

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

高新区

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

明山区

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

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

南芬区

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

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

丹东市

振兴区

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

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

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

元宝区

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

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

振安区

撤销金矿街道办事处。

锦州市

古塔区

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

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

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

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

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

太和区

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

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

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

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

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

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

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

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

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

凌河区

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

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

凌海市

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

北镇市

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

营口市

鲅鱼圈区

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

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

大石桥市

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

老边区

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

站前区

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

西市区

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

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

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

阜新市

海州区

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

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

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

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

细河区

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

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

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

太平区

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

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

新邱区

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

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

清河门区

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

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

辽阳市

文圣区

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

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

宏伟区

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

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

弓长岭区

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

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

太子河区

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

白塔区

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

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

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

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

盘锦市

大洼区

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

兴隆台区

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

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

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

朝阳市

喀喇沁左翼蒙古族自治县

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

双塔区

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

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

龙城区

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

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

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

建平县

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

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

凌源市

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

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

北票市

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

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

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

葫芦岛市

连山区

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

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

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

龙港区

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


南票区

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

兴城市

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


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

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

本討論章節會維持開放，暫時不按最後意見發表時間存檔，直至問題解決。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

視覺化編輯器ilh系模板顯示bug

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:可视化编辑器。

當外語連結沒有空格時會顯示成全黑字的“X語：link]]”而非正確帶藍字的“X語：link”，例見沙盒。連到英文之類還好，日文的話就幾乎全都是這樣了（見幣舞橋底部的模板）。看了一下英維貌似不以綠鏈顯示，日維有綠鏈但無法復現。--惣流·明日香·蘭格雷不姓式波 2025年3月5日 (三) 11:08 (UTC)[回复]

本討論章節會維持開放，暫時不按最後意見發表時間存檔。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

有關失效連結

本主題或以下段落文字，在討論結束後應存檔至Category talk:带有失效链接的条目。

剛剛心血來潮看了一下Category:带有失效链接的条目，發現2025年2月和3月分別有50k和18k個條目於分類内，而其他月份一般不過100，多的也不過10k，請問這是正常現象嗎？--惣流·明日香·蘭格雷不姓式波 2025年3月9日 (日) 11:59 (UTC)[回复]

三月份才第9天就有1萬8個條目被歸類失效連結很明顯不正常，有些條目在三月沒有編輯卻被歸類在分類:自2025年3月帶有失效鏈接的條目，例如2008年至2009年天水圍飛馬賽季、2001年12月阿根廷危機。--2402:7500:93E:31AE:456A:5C20:46FD:EE99（留言） 2025年3月9日 (日) 12:35 (UTC)[回复]
如果均速增加的話本月可能要破6萬。看了一下閣下提的兩個，天水圍飛馬分別是2017年12月、2018年2月、2023年3月標記了共30條dead link，阿根廷危機是2021年12月創建時、2023年10月標記了共3條dead link。--惣流·明日香·蘭格雷不姓式波 2025年3月9日 (日) 13:03 (UTC)[回复]
補充：2008年至2009年天水圍飛馬賽季存於Category:自2017年12月带有失效链接的条目及Category:自2018年2月带有失效链接的条目，但不存於Category:自2023年3月带有失效链接的条目。
2001年12月阿根廷危機不存於Category:自2021年12月带有失效链接的条目及Category:自2023年10月带有失效链接的条目。--惣流·明日香·蘭格雷不姓式波 2025年3月9日 (日) 13:32 (UTC)[回复]
2008年至2009年天水圍飛馬賽季不存在Category:自2023年3月帶有失效鏈結的條目是正常的，因為2023年3月編輯並沒有填寫|data=參數，所以不會列入分類，2001年12月阿根廷危機也是同樣情況。我比較疑惑的是，在以前如果沒有填寫|data=參數，其條目應該列入Category:帶有失效鏈結的條目才對，不曉得是改過分類機制還是我記錯。--2402:7500:93E:31AE:8563:9173:6E08:225E（留言） 2025年3月9日 (日) 14:34 (UTC)[回复]
我看源碼時都覺得有點違和，原來是沒填參數。那問題就變成：
  1. 爲什麽沒填參數會列到本月（2025年3月），又爲什麽有些會列到2025年2月
  2. IABot從何時起，爲何沒有填參數
  3. 如何補回參數（順道把Category:条目有永久失效的外部链接的5.9萬條清理一下）（這分類是放fix-attempted=yes的，與此問題無關）2025年3月13日 (四) 08:34 (UTC)
--惣流·明日香·蘭格雷不姓式波 2025年3月10日 (一) 01:47 (UTC)[回复]
{{dead link}}不带|date=参数就会归类到当前月，没有及时WP:更新服务器缓存的就是上个月--Kunjinkao（留言） 2025年3月13日 (四) 01:18 (UTC)[回复]
這麽說這是“正常現象”？那IABot不填參數是本地設置還是什麽問題，我看英維運行得挺正常的，這樣下去這些分類就廢了。--惣流·明日香·蘭格雷不姓式波 2025年3月13日 (四) 08:51 (UTC)[回复]
其他分类（{{cn}}, {{update inline}}）没有这个问题，但{{dead link}}逻辑好像不太一样。另外英维有自动给维护模板加date参数的机器人--Kunjinkao（留言） 2025年3月13日 (四) 09:01 (UTC)[回复]
我們恐怕需要這種機器人。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年3月13日 (四) 12:19 (UTC)[回复]

本討論章節會維持開放，暫時不按最後意見發表時間存檔。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

{{lang}}、{{lang-xx}}相關更新善後

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

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

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

按理说原来zht的写法应该是不对的，标准的写法应该使用zh-hant，严格来说这不是个错误。--Vozhuowhisper 2025年3月25日 (二) 13:06 (UTC)[回复]
建議撤回編輯。{{langx}}兼容性問題太多了，暫不適合正式發佈。--SuperGrey (留言) 2025年3月26日 (三) 20:33 (UTC)[回复]

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

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

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

(！)意見：這個「文本有斜体标记」的報錯有必要在中文維基百科存在嗎？英文維基百科似乎是因爲要將拉丁字母拼寫的非英文自動斜體纔如此設計。如果斜體標記不會造成顯示問題，那麼直接去除這個報錯更方便。——枰（留言） 2025年3月26日 (三) 10:45 (UTC)[回复]

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

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

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

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

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

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

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

@Kcx36：已移動。——枰（留言） 2025年3月28日 (五) 07:35 (UTC)[回复]
既然討論串搬到VPT了，那我順便請求一下管理員盡快處理Wikipedia:机器人/作业请求#請求修復lang模板外文斜體設定的問題與Wikipedia:机器人/作业请求#請求批量替換所有lang-xx模板為langx模板，尤其前者需要盡快處理。Sanmosa 新朝雅政 2025年3月29日 (六) 05:15 (UTC)[回复]
(？)疑問@Sanmosa：請問閣下提及的WP:翻译腔/城墙錯誤具體爲何？本人沒有找到其中出錯，方括号在原始碼中就是方括号。——枰（留言） 2025年3月29日 (六) 05:40 (UTC)[回复]
之前兩處斜體標記顯示為方括號，即原始碼輸入時為“''A Movie''”，顯示效果為“[A Movie]”，但現在顯示情況正常了。Sanmosa 新朝雅政 2025年3月29日 (六) 05:43 (UTC)[回复]
原來如此。我想那大概是斜體報錯的後續處理，所以在默认未设置italic参数时不检查是否有斜体後斜體不報錯就沒有問題了。——枰（留言） 2025年3月29日 (六) 05:52 (UTC)[回复]
{{lang-xx}}系列中有一些是自定义模板，需要先确认是否有需要先排除掉的，比如{{lang-srp}}、{{lang-ug}}。英维保留了en:Template:Lang-sr-Cyrl及其他一些Lang-x模板。--Kethyga（留言） 2025年3月29日 (六) 05:45 (UTC)[回复]
@Kethyga：你提到的那些模板不在Category:使用Lang-xx模板的页面之內，因此不是處理的範圍。Sanmosa 新朝雅政 2025年3月31日 (一) 01:43 (UTC)[回复]
@Sanmosa 英维有en:Category:Pages using Lang-xx templates，相关语言模板有{{Lang-sr-Cyrl}}、{{Lang-hbs-Cyrl}}……--Kethyga（留言） 2025年3月31日 (一) 11:37 (UTC)[回复]
這些自然也一同排除掉。不過這樣看來我可能還需要另開一個排除清單。Sanmosa 新朝雅政 2025年3月31日 (一) 13:08 (UTC)[回复]
（更新）剛才開了一個Module:Lang/data的編輯請求，處理了以後你提到的那兩個模板就可以正常替換為{{langx}}了。Sanmosa 新朝雅政 2025年4月1日 (二) 05:11 (UTC)[回复]
也許能實現想要的結果，可能不適合放入Module:Lang/data中。--Kethyga（留言） 2025年4月2日 (三) 05:47 (UTC)[回复]
Module:Lang/data有專門放置非標準代碼的地方，因此沒有甚麽不適合的，反正那個放置非標準代碼的地方不是我弄出來的。Sanmosa 新朝雅政 2025年4月8日 (二) 14:07 (UTC)[回复]
在Category:使用Lang-xx模板的页面內但仍需要排除的模板暫時僅{{Lang-sq-definite}}一個，但我感覺這個模板存在的必要性是可以商討的。Sanmosa 新朝雅政 2025年4月2日 (三) 03:59 (UTC)[回复]
更新：{{Lang-he-n}}應該可以刪除，但刪除前需要subst處理，而非簡單替換“lang-”字根。Sanmosa 新朝雅政 2025年4月8日 (二) 14:06 (UTC)[回复]
@Vozhuo： 轉至臺灣維基社群臉書社團，Template:阿拉伯語顯示「錯誤：{{Transl}}：轉寫文本非拉丁字母」，謝謝。--SCP-0000（留言） 2025年3月30日 (日) 07:30 (UTC)[回复]
已修复。--Vozhuowhisper 2025年3月30日 (日) 07:48 (UTC)[回复]
不好意思想查詢一下，現時是否能正常使用{{lang|en}}格式，或是否有必要把{{lang-en}}換成{{lang|en}}？鑑於本人持續批量建立條目，希望能了解詳情，及早對相關頁面作出修改。--維基病夫❤️邊緣人小組·簽到 2025年3月30日 (日) 07:56 (UTC)[回复]
{{lang-en}}是未来要废除的，应该使用{{langx|en}}代替。{{lang|en}}并没有影响。--Vozhuowhisper 2025年3月30日 (日) 08:09 (UTC)[回复]
了解，感謝。--維基病夫❤️邊緣人小組·簽到 2025年3月30日 (日) 12:19 (UTC)[回复]
既然在改模块，能否帮忙看看Template talk:Lang-grc#为Lang-grc模板引入多调（polytonic）样式有无什麼更加優雅的解决方案（） ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年3月31日 (一) 09:03 (UTC)[回复]
另外也請管理員處理一下Wikipedia:頁面存廢討論/記錄/2025/03/28#批量Module:Lang相關data提刪--SunAfterRain 2025年4月1日 (二) 08:13 (UTC)[回复]
ㄎㄎ —— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月2日 (三) 16:02 (UTC)[回复]
Template:Infobox_Chinese/Chinese中{{lang|zh-Hant| {{{t}}} }}、{{lang|zh-Hans| {{{s}}} }}對阻斷繁簡轉換的效果似乎失效。--— Gohan 2025年4月3日 (四) 10:08 (UTC)[回复]
已在沙盒中修复Lang模块并提交修改请求。--Vozhuowhisper 2025年4月3日 (四) 11:44 (UTC)[回复]
@Vozhuo：話說您有沒有考慮選個介面管理員？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月4日 (五) 13:54 (UTC)[回复]
没兴趣。我之前也没编辑过css js这些。--Vozhuowhisper 2025年4月8日 (二) 14:41 (UTC)[回复]
@Vozhuo：哈萨克语的问题，该国的默认文字可能不再是西里尔/基里尔文，可能会改成拉丁字母。既然支持kk-Latn，kk-Cyrl不应该报错吧。还有像ru-Cyrl，不清楚为什么英维要禁用。--Kethyga（留言） 2025年4月12日 (六) 09:35 (UTC)[回复]
在模块的逻辑里，ru-Cyrl、kk-Cyrl均被视为冗余标签，你可以看Module:Lang/data/iana_suppressed_scripts，这里面记录了一些语言默认用什么字母，比如英语本来就用拉丁字母，俄语哈萨克语本来就用西里尔字母，如果非要写en-Latn、ru-Cyrl、kk-Cyrl就感觉有点奇怪，好像这样让人觉得和en、ru、kk代表的含义不一样，所以模块就不允许这样写。如果哈萨克语改用了拉丁字母，这个子模块就会更新，kk会放到["Latn"]那一行里，到时候kk-Cyrl就不会报错了，但是kk-Latn反而变成了冗余标签就会报错。--Vozhuowhisper 2025年4月12日 (六) 11:43 (UTC)[回复]
假如正式改用拉丁字母，以前用{{lang|kk|xx}}标记的、以西里尔/基里尔字母书写的内容就和拉丁内容不符。到时不免折腾一番。--Kethyga（留言） 2025年4月12日 (六) 12:20 (UTC)[回复]
在沙盒（86805971）中测试蒙古语（另一个可能改变文字系统的），在{{lang|mn-Cyrl|xx}}中输入任意的文字均不会检测字符是否属于西里尔/基里尔字母。 {{lang|rul|xx}}中混合输入西里尔字母、拉丁字母、汉字均不会检测超范围的文字符号。--Kethyga（留言） 2025年4月13日 (日) 02:01 (UTC)[回复]
模块只有对具有后缀标签的代码（不包括ru这种没后缀的）检测拉丁字母的功能，比如mn-Cyrl包含拉丁字母，又或者mn-Latn包含非拉丁字母，除此之外都不会检查。--Vozhuowhisper 2025年4月13日 (日) 10:21 (UTC)[回复]
英維中pt-br明确顯示爲巴西葡萄牙语，中维建议同步，巴西和欧洲葡萄牙语有一定差异。好像巴西葡语现在是葡语的主流？--Kethyga（留言） 2025年4月14日 (一) 08:22 (UTC)[回复]
已经更新在沙盒里了，要等管理员更新。--Vozhuowhisper 2025年4月17日 (四) 13:47 (UTC)[回复]
英维中区分了en-gb（英式英语）和en-us（美式英语），本地目前未区分二者。--Kethyga（留言） 2025年4月25日 (五) 12:34 (UTC)[回复]
这是个bug，已提交修复。--Vozhuowhisper 2025年4月30日 (三) 07:03 (UTC)[回复]
在縱書與橫書中需要使用{{lang|zh-hant|，}}等單個標點符號的情況，此時 text_script_match_test 會報[，] 错误：{{Lang}}：指定的書寫系統標籤非拉丁字母，但文本為拉丁字母。（帮助）--内์์์์์์์存๎๎๎๎溢出์์์์์์์的๎๎๎๎猫瞄?喵! 2025年4月21日 (一) 01:37 (UTC)[回复]
模組討論:Lang/data/is latn data#編輯請求2025-04-22去掉了一些內容，能修，但是這種做法不太好，最好修改或去除這個拉丁字母檢測功能。——枰（留言） 2025年4月22日 (二) 05:34 (UTC)[回复]
@優枰：更新之后会导致新的问题，例如2030年亚洲运动会，里面的转写因为有个‘会报错。我觉得像{{lang|zh-hant|，}}这种用法有点问题，因为lang模板是为了标明某种语言的文本，而标点符号不是专属于某个语言的，这样用有些不妥。--Vozhuowhisper 2025年5月3日 (六) 16:42 (UTC)[回复]
沒注意到這個問題，抱歉，我在編輯請求那裏請求恢復了，然後新建了{{lang old}}臨時用在此條目。關於{{lang|zh-hant|，}}，我覺得現有用法有些道理，畢竟瀏覽器可以藉此以不同方式顯示標點符號。然後這個問題，最好的方法可能是拆開Latn和Zyyy，也許應該回報到英文維基百科。——枰（留言） 2025年5月3日 (六) 19:50 (UTC)[回复]
模板{{Vi-nom}}也有類似問題。--Kethyga（留言） 2025年4月24日 (四) 11:29 (UTC)[回复]
英維直接使用<span lang="vi-Hani" class="vi-nom" {{{attr|}}}>{{{1}}}</span>进行标记。--Kethyga（留言） 2025年4月24日 (四) 11:32 (UTC)[回复]
ToolsRedirect的輔助選項「ToolsRedirect選項：取得生物學學名為重新導向候選」疑似因為這個更新失效了，我剛剛新建頁面發現他完全抓不到lang-xm下的學名（更新之前我常用這功能，當時只要有學名：{{Sname}}時是可以運作的）。--WiTo🐤💬 2025年4月23日 (三) 06:16 (UTC)[回复]
@WiTo7946 似乎因为html源码中多了<span lang="la"--Kethyga（留言） 2025年4月29日 (二) 09:02 (UTC)[回复]
Module talk:Lang/data#編輯請求 2025-04-27需要管理員盡快處理。Sanmosa 新朝雅政 2025年4月27日 (日) 02:14 (UTC)[回复]
巴勒斯坦解放組織首句：「Lang-xx：拉丁字母轉寫第 99 個字元「嵌」不是拉丁字母。」，但直接把該lang-ar呼叫過來這裡又正常了的樣子。「阿拉伯语：منظمة التحرير الفلسطينية，羅馬化：Munaẓẓamat at-Taḥrīr al-Filasṭīniyyahⓘ」--WiTo🐤💬 2025年5月5日 (一) 10:22 (UTC)[回复]
错误提示应该是{{Audio}}模板有关，lang模板估计只检测主命名空间（条目空间），在个人沙盒测试也未报错。--Kethyga（留言） 2025年5月5日 (一) 10:55 (UTC)[回复]
若直接展開看起來就沒問題了，如果是Audio的問題的話，那可能是lang抓到Audio模板內的{{#ifeq:{{NAMESPACE}}|{{ns:0}}|[[Category:嵌入hAudio微格式的條目]]}}了。--WiTo🐤💬 2025年5月6日 (二) 05:18 (UTC)[回复]

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

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

（由@Cynroya發现的问题。） ——自由雨日🌧️❄️ 2025年4月15日 (二) 06:19 (UTC)[回复]
应改为zh-Bopo。--伞木 霙留言 2025年4月15日 (二) 06:39 (UTC)[回复]
是否考慮直接在模板內增加相容參數？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月21日 (一) 11:13 (UTC)[回复]
同上，同pinyin-->zh-Latn-pinyin的做法，也应该把zhuyin设置为zh-Bopo的别名。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年4月25日 (五) 13:24 (UTC)[回复]
@自由雨日、魔琴：不過應修改什麼模板呢？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月5日 (一) 15:50 (UTC)[回复]
@Vozhuo。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年5月5日 (一) 22:50 (UTC)[回复]
已提交编辑请求。--Vozhuowhisper 2025年5月9日 (五) 08:02 (UTC)[回复]

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

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:格式手册/图标。

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

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

視覺化編輯器加入T:NoteTag bug

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:可视化编辑器。

如題，NoteTag的上下會被加入各兩新行，在發佈編輯前，不切到源碼編輯貌似是拿不走新行。（最終效果見special:diff/86885440）--惣流·明日香·蘭格雷不姓式波 2025年4月18日 (五) 13:16 (UTC)[回复]

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

本討論章節會維持開放，暫時不按最後意見發表時間存檔。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

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

本主題全部或部分段落文字，已移動至Wikipedia talk:Twinkle。执行者：Jimmy-bot（留言） 2025年5月10日 (六) 08:14 (UTC)。[回复]

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

本主題或以下段落文字，在討論結束後應存檔至Template talk:Infobox road。

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

附：追踪分类列表

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

不是很理解意思，如果您是指一個條目已經被分到某個分類，但是這個條目底部沒有顯示的話，是不對的，因為分到了分類，就算沒有建立分類頁面，頁面底下也會有紅色的分類連結。--Hamish T 2025年4月29日 (二) 00:35 (UTC)[回复]
@Hamish：他説的是“沒有建立分類頁面，導致界面上不顯示為隱藏分類”，也就是當成一般分類那樣來顯示，他希望做到的是在不開啓檢視隱藏分類的功能的情況下看不到那個分類。Sanmosa 新朝雅政 2025年4月29日 (二) 00:57 (UTC)[回复]
以上有列出來的分類我基本都建了，剩下的就看看特殊頁面逐一建立吧。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月5日 (一) 15:58 (UTC)[回复]

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

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:重定向、Wikipedia talk:繁简处理。

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

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

原标题：有关对某一个页面的简繁重定向（不含该页面本身）是否应该同时存在或是否应当监视变动的讨论。修改者：--此條未簽名留言由Iming（討論｜貢獻）於2025年4月25日 (五) 13:33 (UTC)加入。[回复]
请至下方讨论：
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
例子在Special:Diff/86988917中有修改，改于2025年4月25日 (五) 13:30 (UTC)。

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

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

邀请@魔琴、@0xDeadbeef两位参与讨论。--Iming 彼女の愛は、甘くて痛い。 2025年4月25日 (五) 13:08 (UTC)[回复]
and @自由雨日（（（ Iming 彼女の愛は、甘くて痛い。 2025年4月25日 (五) 13:24 (UTC)[回复]
(＋)支持--Aqurs 2025年4月25日 (五) 13:14 (UTC)[回复]
(＋)支持。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年4月25日 (五) 13:25 (UTC)[回复]
@Iming：咦，这个例子不还是我半年前说的问题吗？你举的例子属于“修复双重重定向”，早已有机器人在维护了；@魔琴和我说的是“A因B的重定向变化而没有跟B同步”的问题。 ——自由雨日🌧️❄️ 2025年4月25日 (五) 13:28 (UTC)[回复]
我的问题，例子举错了，不过机器人等设计的都是正确的。感谢提醒。--Iming 彼女の愛は、甘くて痛い。 2025年4月25日 (五) 13:32 (UTC)[回复]
cc @Aqurs1和@魔琴两位。Iming 彼女の愛は、甘くて痛い。 2025年4月25日 (五) 13:50 (UTC)[回复]
瞭解。因为这個东西似乎就是我最初提议的，所以我明白Iming的意思。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年4月25日 (五) 18:30 (UTC)[回复]
见下，通知的不是那个（） ——自由雨日🌧️❄️ 2025年4月25日 (五) 19:22 (UTC)[回复]
经站外私聊帮助@Iming传达：上方通知两位（并非主要是通知对我留言的回应，而主要）是由于标题發生了变化——即Iming讨论的本意是希望让在话题下讨论的编者选择“废除繁简重定向”和“使用机器人”方案之一，故两位的“支持”可能得改成具体的“支持某一方案”（） ——自由雨日🌧️❄️ 2025年4月25日 (五) 14:04 (UTC)[回复]
繁简重定向属常年提案，如果本讨论真是讨论在两方案取其一的话，恐怕不得不开始ping之前的编者大规模讨论了。 ——自由雨日🌧️❄️ 2025年4月25日 (五) 14:05 (UTC)[回复]
通知先前讨论过繁简重定向去留问题的（不完全名单）@Yangfl、Cdip150、Cwek、Antigng、PhiLiP、Jasonzhuocn、Bluedeck、Temp3600、淺藍雪、RabbitMeow、RekishiEJ、Jane9306、Michael Chan、Spaghet-Ti、SzMithrandir、M940504、Sanmosa、Mongolian Beef、白布飘扬、EtaoinWu、Hotaru Natsumi、Tomchen1989、Wcam、Chiefwei、Hat600、FRDian、乌拉跨氪、Liangent、Byfserag、DeBit、Wangxuan8331800、GZWDer、SElephant、Shizhao、脳内補完、燃玉、HYH.124、Bnb674、Chmarkine、Byfserag、小躍、日期20220626： ——自由雨日🌧️❄️ 2025年4月25日 (五) 19:20 (UTC)[回复]
我支持「廢除繁簡重定向」。繁簡重新導向的保留理據不足，雖然視覺化編輯器等bug遲遲無人修，但在繁簡重新導向在閱讀介面並無顯示問題，保留重新導向徒增維護壓力，並無必要。只需一鍵刪除即可。自動加此類重新導向的小工具本該是罪魁禍首，不應該反而遷就，成為保留此類重新導向的理據。--SuperGrey (留言) 2025年4月25日 (五) 20:42 (UTC)[回复]
繁簡重新導向還有另外一大問題：條目更名的時候，需要手動檢查並修復舊名的另一/幾個變體。即使有機器人自動修復，移動者也有檢查的義務，此「舊名+繁簡重新導向」是否有存在的必要？有無必須存在的理據？--SuperGrey (留言) 2025年4月26日 (六) 04:22 (UTC)[回复]
这就是“修复双重重定向”，这倒是倒很方便？我一般用小工具幾秒钟就能完成；即便不去动它，不出幾小时机器人也都会修复。 ——自由雨日🌧️❄️ 2025年4月26日 (六) 04:24 (UTC)[回复]
但有必要徒增煩惱嗎？用小工具再方便，不如不建立，更方便，效率提升100%。--SuperGrey (留言) 2025年4月26日 (六) 04:26 (UTC)[回复]
(－)反对,简繁重定向的存在，主要是有时出现转换系统失效时，未建立的页面会直接红链，而不会导向简繁版本，于是这种情况出现时，就会临时建立简繁重定向，并保留下来。另一个是生僻字的转换问题，目前依然有很多生僻字或新的Unicode字符没列入简繁自动转换系统，比如鿳、鿸、誌、𰵧、𤦎，𮴅，都需要手动更新，今年又会有中日韓統一表意文字擴展區J启用，预计这种情况会长期存在，所以我觉得简繁重定向应有需要继续存在。--白布飘扬（留言） 2025年4月25日 (五) 23:10 (UTC)[回复]
还有一些简繁多对多的问题，比如“蘋、𬞟、萍、苹”、“乾、幹、榦、干”、“勳、勛、勋”很容易出现过度转换，所以有时必须用简繁重定向来纠正。——白布飘扬（留言） 2025年4月25日 (五) 23:39 (UTC)[回复]
可否舉個例子，哪個條目因為「過度轉換」而必須用簡繁重新導向來糾正？--SuperGrey (留言) 2025年4月26日 (六) 04:13 (UTC)[回复]
而且多對多的條目「如果真的存在」，給這幾個建立重新導向即可，必須擴大到非多對多的情況嗎？--SuperGrey (留言) 2025年4月26日 (六) 04:28 (UTC)[回复]
另外一个理由是重复页面的问题，当简或繁重定向缺失时，新手或机器人容易建立重复的简繁页面，所以简繁重定向可以减少这些问题。至于链接更新问题，维基编者在更换重定向时，应养成检查简繁页面的习惯。——白布飘扬（留言）--白布飘扬（留言） 2025年4月26日 (六) 00:09 (UTC)[回复]
機器人容易建立，但只要系統能正常跳轉，新手並不容易建立。機器人作者寫出錯誤的程式邏輯應自己負責，此理據不成立。--SuperGrey (留言) 2025年4月26日 (六) 04:15 (UTC)[回复]
對生僻字和未收錄字建立簡繁重新導向就好了，不必擴大化到常用字。「轉換系統失效」的時候，最近幾年有發生過嗎？--SuperGrey (留言) 2025年4月26日 (六) 04:18 (UTC)[回复]
此外繁簡重定向僅在中文維基百科有效，鏈接到維基百科的網址可能會因爲刪除繁簡重定向而404。不少工具不支持繁简通搜，比如intitle:"历年"。可以用机器人或数据库保证繁简指向同一页面。同一上面提及的机器人维护方案。--Kethyga（留言） 2025年4月26日 (六) 03:52 (UTC)[回复]
能否舉個404的例子？哪個網址會404？--SuperGrey (留言) 2025年4月26日 (六) 04:16 (UTC)[回复]
以雅羅斯拉夫·莫斯卡利克为例，将其保存到Wayback Machine（网址），如果把网址中最后标题改成简体的雅罗斯拉夫·莫斯卡利克就失效。--Kethyga（留言） 2025年4月26日 (六) 05:51 (UTC)[回复]
這是肯定的。因為Wayback Machine並不是這樣用的，不應用於存檔重新導向。而且，本來拿Wayback Machine存檔維基百科也是挺奇怪的做法。您如果需要存檔將被刪除的條目，還是去藍燈圖書館吧。--SuperGrey (留言) 2025年4月26日 (六) 06:15 (UTC)[回复]
(－)反对廢除繁簡重定向、支持機器人或資料庫報告監控，理由同白布飘扬及Kethyga。--迴廊彼端（留言） 2025年4月26日 (六) 04:05 (UTC)[回复]
(：)回應,我建立页面User:白布飘扬/沙盒/1/幹的话，相应的页面不会自动链接（乾、幹、榦、干）；
我建立页面User:白布飘扬/沙盒/1/干干的话，则部分繁体字都会链接(:乾乾、幹幹、榦榦、干干）--白布飘扬（留言） 2025年4月26日 (六) 05:08 (UTC)[回复]
在这种情况下，尤其用在人名时，都需要特别处理，来避免错误导向，这会是一个常见的问题，所以现有方针应明确保留。——白布飘扬（留言） 2025年4月26日 (六) 05:08 (UTC)[回复]
贊同。這部分重新導向應該保留。--SuperGrey (留言) 2025年4月26日 (六) 05:13 (UTC)[回复]
(－)反对廢除繁簡重定向，同白布飄揚閣下。另在去年八月時，我有提出過相關的繁簡疑問，但受限於各裝置支援字體的不同，有可能有些簡化字輸入/顯示不出來。在本站諸如「栗苇𫛚、栗苇鳽」此類的轉換問題解決之前，不該貿然處理掉繁簡重定向（何況這舉例僅僅是中日韓統一表意文字擴展區C的字，甚至也不用到今年的J）。用機器人產生報告再修改的方式則可以考慮。--WiTo🐤💬 2025年4月26日 (六) 07:09 (UTC)[回复]
如果是利用机器人直接自动维护，其他编者可以根据机器人贡献日志检查呢？--Iming 彼女の愛は、甘くて痛い。 2025年4月26日 (六) 07:24 (UTC)[回复]
如果最終能做到幾乎無誤那是可以，我個人不希望要幫機器人善後太多東西。--WiTo🐤💬 2025年4月26日 (六) 10:52 (UTC)[回复]
我没什么太大的想法，机器人来做的话错误率应该不会太高？没试验过不太了解。或许可以先这样做（指由机器人自动维护）一段时间，如果错误率比较高的话就改为仅报告这样？--Iming 彼女の愛は、甘くて痛い。 2025年4月26日 (六) 13:05 (UTC)[回复]
近期看一些本站過往的機器人運轉紀錄，感覺有一些我想不到的部分還是有可能會出錯，最好還是小範圍起測試，免得直接出現天坑。--WiTo🐤💬 2025年4月26日 (六) 14:02 (UTC)[回复]
(＋)支持让机器人找出目标不一致的简繁连接再修正是好办法。——白布飘扬（留言） 2025年4月26日 (六) 10:35 (UTC)[回复]
修正，反對廢除繁簡重定向，支持使用機械人維護。Aqurs 2025年4月27日 (日) 02:46 (UTC)[回复]
打算建立多少新繁簡重新導向呢？幾十萬條？--SuperGrey (留言) 2025年4月27日 (日) 04:43 (UTC)[回复]
見上，經腳本整理統計出共有75821例此類情況。至少大規模建立相關頁面暫時未見有明顯負面效果。--Aqurs 2025年4月27日 (日) 12:48 (UTC)[回复]
75821例都是「簡體→繁體」。「繁體→簡體」呢？需要多少條重新導向？--SuperGrey (留言) 2025年4月27日 (日) 13:04 (UTC)[回复]
後者確實是未知數，但暫且先用機械人維護有什麼負面效果嗎？--Aqurs 2025年4月27日 (日) 13:54 (UTC)[回复]
據@Sohryu Asuka Langley Not Shikinami的說法，75821例只是「情況3」。想必您說的「大規模建立相關頁面」遠遠不止7萬例吧？要是建立了幾十萬、上百萬條簡繁重新導向（維基百科裡面現在主名字空間的頁面數遠不止這個數），以後就變成新的技術債了，故並非「暫時未見有明顯負面效果」就沒事，而是要充分討論、凝聚共識之後再去建。--SuperGrey (留言) 2025年4月27日 (日) 14:00 (UTC)[回复]
@SuperGrey：似乎建立重定向屬於跑題了，這邊討論串說的是修復現有有問題/有可能會有問題的重定向，不會建立。我是不反對「大規模建立」但這邊不是討論這個東西。--Aqurs 2025年4月27日 (日) 15:38 (UTC)[回复]
「跑题」但题目写的就是「废除重新导向」和「机器人维护重新导向」。看来还是题目和提案有点偏差。建议底下再开一个章节，重新厘清提案内容。--SuperGrey (留言) 2025年4月27日 (日) 23:30 (UTC)[回复]
“使用机器人维护该负面问题”是怎么被您理解成“建立重定向”的……？？ ——自由雨日🌧️❄️ 2025年4月28日 (一) 03:24 (UTC)[回复]
這是在討論這裏的情況3對吧？閣下的7萬多例應該是包含1、2、3的情況？我當時提的時候就想過廢除繁簡重定向，但看了一下過往討論感覺不會成事。--惣流·明日香·蘭格雷不姓式波 2025年4月27日 (日) 12:41 (UTC)[回复]
上述例子是两者均为重定向，标题仅有简繁差异，没有考虑两个重定向的最终目标为何。给这个例子是为了表明存在如此多的页面需要机器人监视是否存在“仅有简繁差异的两个重定向里，其中一个被修改，而另外一个未被修改，导致仅存在繁简区别的两个重定向指向不同页面”。Iming 彼女の愛は、甘くて痛い。 2025年4月27日 (日) 13:28 (UTC)[回复]
如果只對已有的簡繁重新導向使用機器人輔助維護，我是沒有意見的，(＋)支持。但是此次提案大有推廣簡繁重新導向、建立幾十萬條新簡繁重新導向的跡象，讓人擔心。不知參與討論的大家都真心希望建立這麼多條新重新導向嗎？真的不是增加維護的煩惱？--SuperGrey (留言) 2025年4月27日 (日) 13:33 (UTC)[回复]
我刚才再读了一遍提案，可能确实是我写的有问题。我的意思是，对现在存在的所有此类重定向和在未来由其他编者自行建立的此类重定向，是否应当删除，或保留并由机器人监控维护。本提案无意推广简繁重定向或新增简繁重定向，机器人只会关注已经存在的简繁重定向。--Iming 彼女の愛は、甘くて痛い。 2025年4月27日 (日) 15:24 (UTC)[回复]
我又看了一遍，其實討論的根本不是“繁简重定向”，而是“兩個僅為簡繁差異的重定向”，標題該再改改了。另外，我剛剛想到一個應該禁止的“兩個僅為簡繁差異的重定向”情況，就是當其中一個有連至wikidata項目時；此時應確保項目所連的是兩個頁面中較早建的那個（先到先得原則），後來那個就刪掉加白紙保護。--惣流·明日香·蘭格雷不姓式波 2025年4月27日 (日) 16:09 (UTC)[回复]
@Sohryu Asuka Langley Not Shikinami：我知道“兩個僅為簡繁差異的重定向”不是严格意义上的繁简重定向，但实务上常会视作繁简重定向，作用也类似。而且如果社群认为处理方式是禁止“兩個僅為簡繁差異的重定向”存在的话，我想社群也不会认为“繁简重定向”有必要存在，尤其是衹要主页面一移动（保留重定向），原先的繁简重定向就会成为“兩個僅為簡繁差異的重定向”。 ——自由雨日🌧️❄️ 2025年4月27日 (日) 16:32 (UTC)[回复]
不清楚閣下的私聊討論了什麽，但我認為“廢除繁簡重定向”與“處理兩個僅為簡繁差異但目標不同的重定向”有很大分別。本來是處理小問題a，然後轉為討論“背後的”大問題A，那如果A的討論沒共識，a怎麽辦？先關注好a，A應另外討論。如閣下所知，“廢除繁簡重定向”是常年提案，某程度上顯示“常年不處理”也沒有大問題；但“兩個僅為簡繁差異但目標不同的重定向”顯然是值得更積極處理的。--惣流·明日香·蘭格雷不姓式波 2025年4月28日 (一) 01:34 (UTC)[回复]
见下方留言；另外你比较一下“反对废除繁简重定向”的那些理由（即“繁简重定向”的作用），同样也是反对废除“两个仅为简繁差异的重定向”的理由，换句话说上面的讨论同时就是在讨论“两个仅为简繁差异的重定向”。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 01:42 (UTC)[回复]
無語了。能不能不要隨意擴大化解釋？我們還是認真討論「因移動導致的2條僅為簡繁差異的重新導向」吧。--SuperGrey (留言) 2025年4月28日 (一) 01:45 (UTC)[回复]
并不是我在扩大化解释。你後一句更是错了，“因移动导致的2条仅为简繁差异的重新导向”是“修复双重重定向”，早已有机器人在维护了……不是本讨论的主题。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 01:47 (UTC)[回复]
……那本討論的主題是什麼？能一次性說清楚嗎？--SuperGrey (留言) 2025年4月28日 (一) 01:51 (UTC)[回复]
還是說剛剛您說的「換句話說上面的討論同時就是在討論「兩個僅為簡繁差異的重定向」」並非指「因移動導致的2條僅為簡繁差異的重新導向」？那麼，您指的是什麼？--SuperGrey (留言) 2025年4月28日 (一) 01:52 (UTC)[回复]
@SuperGrey：需要解决的问题是如何处理“2条仅为简繁差异的重定向”。但这些重定向建立的原因多不是因为移动，而是和{{繁简重定向}}作用一样的解决系统无法转换的问题（如生僻字）、消除红字链接的问题等等如果是因为移动，由于机器人会修复双重重定向，反而幾乎不可能有“指向页面不一致”的问题，且之前提删“2条仅为简繁差异的重定向”的理由也多为和废除繁简重定向一样的理由；因而我直接以“繁简重定向”开题（你可以看到，上方反对废除“繁简重定向”的理由就是反对废除“2条仅为简繁差异的重定向”的理由；且这条留言显示白布飘扬等并没有弄错讨论的对象）。关于@Sohryu Asuka Langley Not Shikinami说的“2条仅为简繁差异的重定向”是“小问题”，请注意能够创建的“2条仅为简繁差异的重定向”数量远远多过标题的“繁简重定向”。不过如果2位仍然觉得目前讨论不切题的话，就停止吧……按SuperGrey的方式处理，但标题实在要改一下，把“移动”去掉。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 02:17 (UTC)[回复]
明白了。如果將問題擴展到是否廢除「 2條僅為簡繁差異的重定向」，那麼確實和是否廢除繁簡重新導向是同一道題。但是因為目前其他討論者討論的都不是這個題（而是主要因移動產生的重新導向），故討論變得非常混亂。如果您希望討論「是否廢除繁簡重新導向」這個大題，還是也在底下專門開一個吧，看看大家是否想要新建幾十萬條繁簡重新導向。--SuperGrey (留言) 2025年4月28日 (一) 02:30 (UTC)[回复]
算了。我想了想，還是不要妄下定論。雖然我贊同是「同一道題」，但別人不一定贊同。故還是分開來提案吧，就事論事。如果要討論全部廢除，就討論全部廢除；如果要討論廢除「簡繁差異的兩個重新導向」，就討論「簡繁差異的兩個重新導向」；如果要討論「因移動產生的重新導向」，就討論「因移動產生的重新導向」。--SuperGrey (留言) 2025年4月28日 (一) 02:38 (UTC)[回复]
@SuperGrey：目前其他讨论者讨论的都不是这个题（而是主要因移动产生的重新导向）[需要解释]（我刚刚纔说“2条仅为繁简差异的重定向”很多不是因为移动建立的，而且因为移动而建立的那些因为有修复双重重定向的机制反而不会出错，甚至不需要机器人监控；讨论的重点就是和“繁简重定向”作用一致的并非因为移动产生的那些“2条仅为简繁差异的重定向”。）另外恕我直言，让我觉得讨论混乱的主要是您（以及Aqurs也有一些莫名的误解），其他人则大都是切题讨论；您莫名将“反对废除”等同于了“要新建”（而且您似乎没留意到我说的“能够新建的‘2条仅为简繁差异的重定向’”数量比标题繁简重定向远远更多）。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 02:41 (UTC)[回复]
@SuperGrey：见此，@Iming一开始确实举错了例子，说到了移动问题，但很快纠正了——目前其他讨论者讨论的都并不主要是因移动产生的重定向（副知@魔琴）。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 03:14 (UTC)[回复]
行。已刪去「因移動導致」。--SuperGrey (留言) 2025年4月28日 (一) 03:57 (UTC)[回复]
“簡體標題（重定向）”重定向至“繁體標題（條目）”，後“繁體標題（條目）”被移動，變為“繁體標題（重定向）”，就會出現“因移動而產生”的“2條僅為簡繁差異的重定向”。雖然機械人會修復雙重重定向，但我主要是質疑“這些重定向建立的原因多不是因為移動”這一點。我認為重點在於“指向頁面不一致”的情況有多少、能否有效監察。
對於如何處理“2條僅為簡繁差異的重定向”及或“指向頁面不一致”，我認為下方這兩個皆是選項，但廢除繁簡重定向有點overkill。（可理解為二選一的話支持機器人方案）--惣流·明日香·蘭格雷不姓式波 2025年4月28日 (一) 02:42 (UTC)[回复]
我知道这种移动会产生这种重定向，但我也看到很多额外新建的情况——谁更多不重要，重点是前者在目前机器人维护下已经基本不会出现目标不一致的问题。由于“能够新建的‘2条仅为简繁差异的重定向’”数量比标题繁简重定向远远更多，实际上标题繁简重定向衹是所有这些繁简重定向的一小部分，所以我不太理解“overkill”的说法……（换句话说，如果是Supergrey等因担心用户大量创建“标题繁简重定向”而决心废除，那么同样的逻辑更该担心的是“2条仅为简繁差异的重定向”……） ——自由雨日🌧️❄️ 2025年4月28日 (一) 02:55 (UTC)[回复]
關於上面@我的“小問題”，我指的是“兩個僅為簡繁差異但目標不同的重定向”（數量未知，但上限為7萬），對比的“大問題”是“繁简重定向”（11萬），中間還有“2條僅為簡繁差異的重定向”（7萬）。至於“能夠創建的”，我不太關心這個。“實際上標題繁簡重定向衹是所有這些繁簡重定向的一小部分”，這個有大概的比例嗎？--惣流·明日香·蘭格雷不姓式波 2025年4月28日 (一) 03:00 (UTC)[回复]
我指的是潜在能创建的数量：因为不少“删除”这些重定向意见理由是“担心有用户大量创建”——那么如果以此为理由认为需废除标题繁简重定向的话，当然更应该以此为理由废除“2条仅为简繁差异的重定向”。这也是我不认同你说的“繁简重定向”是大问题而“2条仅为简繁差异的重定向”是小问题的原因（在我看来刚好相反）。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 03:03 (UTC)[回复]
所以閣下的意思是“標題繁簡重定向衹是所有這些（潛在能創建的）繁簡重定向的一小部分”？重申一次我指的“小問題”是“兩個僅為簡繁差異但目標不同的重定向”，我瞎猜不到一萬，甚至一千例都未必有，所以（現時實際上）比較下來就是小問題，閣下同意嗎？--惣流·明日香·蘭格雷不姓式波 2025年4月28日 (一) 03:40 (UTC)[回复]
@Sohryu Asuka Langley Not Shikinami：知道你的意思了，你说的“小问题”是“处理两个仅为简繁差异但目标不同的重定向”，但我理解成了你说的小问题是“处理两个仅为简繁差异的重定向”（没有“但目标不同”），在此抱歉。然而如果是这样的话，不得不说您理解错了本提案。本提案并不是针对现存的“大概率不到一千例的”“两个仅为简繁差异但目标不同的重定向”……所有的7万条“两个仅为简繁差异的重定向”必须共同处理，要么删掉其中一种繁简版本，要么全部保留并用机器人维护。@Iming提案的重点也说了，A和B原本重定向至同一页面，但A改了重定向目标但B没改，导致不一致，所以需要机器人随时监控将来可能出现的这种改变，重点并不是讨论如何处理现在那些不一致的页面。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 03:52 (UTC)[回复]
是这样的。Iming 彼女の愛は、甘くて痛い。 2025年4月28日 (一) 03:54 (UTC)[回复]
（以及现在虽衹有7万条，但无法预计未来会建立多少条，如果选择不废除，未来会出现的也都必须监控。所以我说纔一直在说“潜在能创建的数量”。） ——自由雨日🌧️❄️ 2025年4月28日 (一) 03:56 (UTC)[回复]
我調整了一下下面「原提案」章節的表述，貼合您的提案。--SuperGrey (留言) 2025年4月28日 (一) 04:02 (UTC)[回复]
@自由雨日：仔細想了想，補了一個各退一步的折衷方案(C)維持現狀。有了折衷方案或許更有助於結案 😂--SuperGrey (留言) 2025年4月28日 (一) 04:16 (UTC)[回复]
好的，現時各方的觀點應該都正確地傳遞好了。接下來的問題是：如果不必“廢除繁簡重定向”就能妥善解決“小問題”，那是否還需要廢除？要注意即使決定要廢除，處理“小問題”的程序還是要先跑一遍的。“潛在能創建的數量”固然很大，但“將來會創建的數量”其實很小（不過得承認不會是0）。老實説我不反對廢除，但我實在不覺得這次突然就能成功廢除。--惣流·明日香·蘭格雷不姓式波 2025年4月28日 (一) 04:23 (UTC)[回复]
确实可以先把已有的小问题处理了。--SuperGrey (留言) 2025年4月28日 (一) 04:29 (UTC)[回复]
如果你指的“小问题”仍是指处理现存的目标不一的页面的话，那根本不需要提案，机器人一通操作就搞定了……提案主要是要管将来（将来会新建的这类页面其实也不是重点，重点是现存的目标一致的页面未来可能發生不一致的情况——包括标题繁简重定向其实也会發生这种情况）。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 04:36 (UTC)[回复]
以防萬一我還是確定一下，所以現時確實是在討論“廢除所有繁简重定向”？另，現時的Category:簡繁重定向是否包含“兩個僅為簡繁差異的重定向（不論目標）”？--惣流·明日香·蘭格雷不姓式波 2025年4月28日 (一) 01:51 (UTC)[回复]
至少我現在不是很確定@自由雨日君想要討論的是什麼提案。--SuperGrey (留言) 2025年4月28日 (一) 01:53 (UTC)[回复]
行。既然讨论的题目不是「繁简重新导向」而是「兩個僅為簡繁差異的重定向」，那乾脆在下面再开一个章节吧。不然前面这些讨论偏题很远了。--SuperGrey (留言) 2025年4月27日 (日) 23:27 (UTC)[回复]
不用开啊？我上方留言不是纔说本质上区别不大吗😂繁简重定向的作用基本就是“两个仅为繁简差异重定向”的作用，而且它们也可以因页面移动互相转化，後者在重定向页挂的模板也常是“繁简重定向”，先前偶尔看到提删或其他讨论时也经常是叫作“繁简重定向”。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 01:22 (UTC)[回复]
定義混亂，混為一談。怪不得整個討論都跑偏了。--SuperGrey (留言) 2025年4月28日 (一) 01:43 (UTC)[回复]
我没看到跑偏啊……再见这条留言。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 01:45 (UTC)[回复]
@SuperGrey：我完全没看到这种迹象啊…… ——自由雨日🌧️❄️ 2025年4月28日 (一) 01:09 (UTC)[回复]
看來是我誤讀了「繁簡重定向屬常年提案，如果本討論真是討論在兩方案取其一的話，恐怕不得不開始ping之前的編者大規模討論了」傳達的含義。我以為「兩方案」指的是這個「常年提案」，又要再來討論一遍這個「常年提案」。--SuperGrey (留言) 2025年4月28日 (一) 01:16 (UTC)[回复]
不是很理解您的理解……不过可能是我没有加“废除”两个字造成的误会？因为之前有不少编者反对废除“繁简重定向”（之前有过多次提案废除），所以本讨论其中一个选项涉及“废除”当然应该通知…… ——自由雨日🌧️❄️ 2025年4月28日 (一) 01:20 (UTC)[回复]
哦，明白了，換句話説情況3的upperbound是7萬多。--惣流·明日香·蘭格雷不姓式波 2025年4月27日 (日) 13:42 (UTC)[回复]
情況3確實值得處理。--SuperGrey (留言) 2025年4月27日 (日) 13:45 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

原提案：目前和將來出現的2條僅為簡繁差異的重新導向，(A)使用機器人維護？(B)還是刪除？

原标题：原提案：2條僅為簡繁差異的重新導向，共7萬條，(A)使用機器人維護？(B)還是刪除？。修改者：--此條未簽名留言由SuperGrey（討論｜貢獻）於2025年4月28日 (一) 04:01 (UTC)加入。[回复]

原标题：原提案：因移動導致的2條僅為簡繁差異的重新導向，共7萬條，(A)使用機器人維護？(B)還是刪除？。修改者：--此條未簽名留言由SuperGrey（討論｜貢獻）於2025年4月28日 (一) 03:56 (UTC)加入。[回复]

目前和將來，若出現2條重新導向僅簡繁字形存在差異，請大家決定如何處置？此情況目前共有7萬條，但未來可能會出現更多。

(A)保留，並使用機器人統一維護管理？

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

(C)維持現狀：已有的，保留，並使用機器人進一步監視維護；未來凡非移動產生的此類重新導向，視為重複，如無合理理由（如生僻字無法被自動轉換之類）不再建立新的。--SuperGrey (留言) 2025年4月28日 (一) 04:12 (UTC)[回复]

目前已有機器人自動處理此類重新導向。我不反對維持現狀，故A、B我都支持。--SuperGrey (留言) 2025年4月28日 (一) 01:56 (UTC)[回复]
更準確的描述是：現時有7萬對“僅為簡繁差異且兩者皆為重定向”，其中有部分（數量應該未知）屬於“簡繁分別重定向至不同目標”，為處理後者，對於這七萬對，是應該1.）使用機械人維護，還是2.）刪除每對的其中一項。--惣流·明日香·蘭格雷不姓式波 2025年4月28日 (一) 02:00 (UTC) 👍1[回复]
“因移动导致的2条仅为简繁差异的重新导向”并不是@Iming的意思…… ——自由雨日🌧️❄️ 2025年4月28日 (一) 03:21 (UTC)[回复]
我给的例子里，七万多例不都是因为移动导致的（我甚至不太确定是否存在仅因为移动导致的两个只有简繁差异的重定向）。我觉得这部分的标题需要更改，需要删掉“因移动导致”。Iming 彼女の愛は、甘くて痛い。 2025年4月28日 (一) 03:37 (UTC)[回复]
而且因移动导致的重定向通常情况下会有机器人维护，所以一般情况下不会出现本提案所述“目标页面不同”的情况。--Iming 彼女の愛は、甘くて痛い。 2025年4月28日 (一) 03:44 (UTC)[回复]
已刪去題目中的「因移動導致」。--SuperGrey (留言) 2025年4月28日 (一) 03:56 (UTC)[回复]
我又添加了方案(C)，也就是維持現狀。或許這樣更簡單易行。--SuperGrey (留言) 2025年4月28日 (一) 04:12 (UTC)[回复]
我说一下我的立场吧：上方白布飘扬、Kethyga等论述的这类重定向的作用均既适用于“标题繁简重定向”，也适用于“2条仅为简繁差异的重定向”，且“标题繁简重定向”也可能存在指向另一页面的问题（比如标题为“画图”的条目的繁体版本“畫圖”却指向另一頁面。这时候到底是算“标题繁简重定向”还是算“2条仅为简繁差异的重定向”呢？这裏向@Iming确认下统计的时候有没有考虑到这些页面？）；此外两者也常可互相转化。且白布飘扬的这条留言也明确表示的是支持机器人维护所有“目标不一致的简繁页面”（并不单针对“标题繁简重定向”）。因而我反对B方案，即反对废除“2条仅为简繁差异的重定向”。对C我不强烈反对，但仍倾向认为除非是为了“刷编辑数”大量产生的重定向，否则不需要限制建立（利益申明：我个人除非确有需要或无意间没看到有繁体版本，否则我是并不会去建立这种重定向的）。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 04:21 (UTC)[回复]
还有一种特殊情况是，我个人一直倾向认为不应要求所有仅繁简差异的重定向标题都必须指向同一页面（应豁免一些特殊情况。比如简体“朝鲜”我认为应重定向至“朝鲜民主主义人民共和国”），如果将来社群能获得共识允许这类繁简同形词导向目标不一，那当然不应删除另一繁/简，以及机器人需要为这些页面“开绿灯”。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 04:31 (UTC)[回复]
不應豁免。「繁簡統一」是方針，如果想要修改方針，需要專門拿出提案到「互助客棧/方針」去討論。--SuperGrey (留言) 2025年4月28日 (一) 04:41 (UTC)[回复]
“繁简统一”是方针[哪裡？]我之前找了不少页面都没找到。（条目当然是繁简统一，不能为“法国”创建简体条目/繁体条目两个版本。我说的是重定向/消歧义的情况。） ——自由雨日🌧️❄️ 2025年4月28日 (一) 04:45 (UTC)[回复]
Wikipedia:命名常规#繁简统一。--SuperGrey (留言) 2025年4月28日 (一) 04:46 (UTC)[回复]
您好像完全理解错了……《命名常规·繁简统一》说的是不能使用繁简混杂的条目名称…… ——自由雨日🌧️❄️ 2025年4月28日 (一) 04:49 (UTC)[回复]
還真是……這裡倒是還有一個指引：WP:繁簡重新導向，不過這裡只表達了對雙重重新導向的弱反對，沒提到指向目標是否要統一。--SuperGrey (留言) 2025年4月28日 (一) 04:57 (UTC)[回复]
還有一條：WP:R#NPOV，這條是方針。--SuperGrey (留言) 2025年4月28日 (一) 05:04 (UTC)[回复]
好吧，這條也沒有做出明確規定。看來「重新導向的繁簡統一」還未有形成書面共識。--SuperGrey (留言) 2025年4月28日 (一) 05:11 (UTC)[回复]
（编辑冲突）我知道这条方针，这和我说的也没有任何关联……（它说的是“可以创建非中立重定向”的问题。）是否允许繁简重定向目标不一有点跑题了，先打住吧😂 ——自由雨日🌧️❄️ 2025年4月28日 (一) 05:12 (UTC)[回复]
WP:避免地域中心？不過確實跑題，有機會再討論吧。--惣流·明日香·蘭格雷不姓式波 2025年4月28日 (一) 05:20 (UTC)[回复]
我认为应该一律指向同一页面，理由在《User:魔琴/论述/体异页同》已述。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年4月28日 (一) 19:06 (UTC)[回复]
我记得当时在客栈均回应过了（忘了哪个讨论了）。 ——自由雨日🌧️❄️ 2025年5月8日 (四) 13:24 (UTC)[回复]
您怎麼判斷對方是不是「為了『刷編輯數』而創建」呢？如果我每寫一個新條目就創建幾個（比如說，因為有了后藤一里這個條目，就建立後藤一里、後藤獨、后藤独、小孤獨、小孤独），這算是「刷編輯數」嗎？還是說應當限制呢？--SuperGrey (留言) 2025年4月28日 (一) 04:34 (UTC)[回复]
和其他刷编辑数的认定方法类似……客观上肯定没有一个标準，但可以结合行为模式判断。我自己不会去建立，但我个人不倾向限制建立（其实我看@Iming就常大批同时建立仅繁简差异的重定向😂），不过如果其他编者倾向C方案，可以认为我“不反对”C。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 04:41 (UTC)[回复]
既然「刷編輯數」的標準模糊不清，不如直接限制不要再添加新的，用規則來約束，就不必在未來看到你我被送交ANM了 --SuperGrey (留言) 2025年4月28日 (一) 04:45 (UTC)[回复]
“畫圖”的情況屬於這裏的情況2，我認為可以全自動解決（當然最好處理完再人工檢查一下）。另外想確認一下，閣下對“廢除繁簡重定向”的立場為何？其實除了SuperGrey，貌似沒其他用戶表達過支持，所以繼續討論（廢除繁簡重定向）的意義可能不大。--惣流·明日香·蘭格雷不姓式波 2025年4月28日 (一) 04:38 (UTC)[回复]
和上方同样的逻辑，自然也是反对废除繁简重定向。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 04:41 (UTC)[回复]
您對(C)怎麼看？--SuperGrey (留言) 2025年4月28日 (一) 04:43 (UTC)[回复]
其實“使用機械人監視維護”是必須的，因為未來依然有機會出現這類情況。所以重點是對於“未來產生的此類重新導向”是直接刪除還是容許保留。換言之在確定會有機械人監視的前提下，三個選項可以概括為：
(A)現有的(○)保留，未來的(○)保留
(B)現有的(×)删除，未來的(×)删除
(C)現有的(○)保留，未來的(×)删除
（“現有的刪除”指刪除“後來的”；“未來的刪除”指先更新“先來的”的連結目標，再刪除“後來的”）
所以説三個選項都差不多，不過我會傾向A或B，執行起來簡單一點。--惣流·明日香·蘭格雷不姓式波 2025年4月28日 (一) 05:16 (UTC) 👍1[回复]
(－)反对B+C，(＋)支持A，謝謝--Aqurs 2025年4月28日 (一) 14:53 (UTC)[回复]
小工具「PageRedirect ToolsRedirect」似乎会把所有繁简形式都找出来让你创建，如果禁止建立繁简差异重定向，使用起来会非常麻烦。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年4月28日 (一) 12:44 (UTC)[回复]
那就換個小工具。--SuperGrey (留言) 2025年4月28日 (一) 13:09 (UTC)[回复]
現在有替用品嗎？--WiTo🐤💬 2025年4月29日 (二) 02:30 (UTC)[回复]
我可以寫一個。--SuperGrey (留言) 2025年4月29日 (二) 06:20 (UTC) 👍1[回复]
見此原始碼：MediaWiki:Gadget-ToolsRedirect.js。把基於繁簡的部分去掉即可。--SuperGrey (留言) 2025年4月29日 (二) 06:25 (UTC)[回复]
距离上一次留言已逾9日，看起来对于使用机器人应该没有什么太大的意见，那么我想我们应该初步达成了一个共识，即“不论是否新建，相关对重定向的修改均由机器人监视并维护”。有鉴于这个提案最开始只是为机器人许可而开的，且我们没有产生什么其他必须要公示的内容，就不公示了。如果您还存在任何意见，请您说明，感谢。Iming 彼女の愛は、甘くて痛い。 2025年5月8日 (四) 13:19 (UTC)[回复]
应该补充一下，对于新建的，由编者自行决定是否提报删除，机器人不会自动提删。--Iming 彼女の愛は、甘くて痛い。 2025年5月8日 (四) 13:22 (UTC)[回复]

Jpn、Kor等模板是否應改以langx等模板為基礎？

本主題或以下段落文字，在討論結束後應存檔至Template talk:Jpn、Template talk:Kmr、Template talk:Kor、Template talk:Vie。

如題，{{Jpn}}、{{Kor}}等模板是否應改以{{langx}}等模板為基礎？具體提議代碼見User:Sanmosa/Template的子頁面。Sanmosa 新朝雅政 2025年4月29日 (二) 08:59 (UTC)[回复]

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

重新導向分類模板填寫小工具

每次都要手動填分類模板，實在麻煩，故引入了英維Redirect Helper——User:SuperGrey/gadgets/RedirectHelper。參見原始碼。按照中維需要調整了可用的分類模板。暫未做簡繁轉換，反正功能也不多，以後再做吧……--SuperGrey (留言) 2025年4月30日 (三) 17:59 (UTC) 👍1[回复]

efn爆炸了

本主題或以下段落文字，在討論結束後應存檔至Template talk:Efn。

已解決
提案者使用了错误的模板语法。--PexEric 2025年5月2日 (五) 16:38 (UTC)[回复]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

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

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

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

請把你網址裡面的等號=換成{{=}}（使用{{=}}魔術字而非模板，語法一樣但不傳參數），不然「{{efn | 法国精神病学家{{link-fr|罗兰·库唐索|Roland Coutanceau}}在其著作《心理暴力：理解与行动（Les violences psychologiques : Comprendre pour agir）》(Dunod, 2014) … [https://books.google.fr/books?id=pGHIAwAAQBA … J&pg = PA206   page 206 … ]，未详细说明地给出7人死亡 … 数字。}}」會被視為別的參數，而efn的預期參數就變成空的，所以當然引用错误：<ref>标签中没有内容啦，字面上的意思。模板沒有炸，是你輸入錯誤。 -- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2025年5月1日 (四) 00:42 (UTC)[回复]
  • (～)補充所以你輸入的「{{efn | 法国精神病学家{{link-fr|罗兰·库唐索|Roland Coutanceau}}在其著作《心理暴力：理解与行动（Les violences psychologiques : Comprendre pour agir）》(Dunod, 2014) … [https://books.google.fr/books?id=pGHIAwAAQBA … J&pg = PA206   page 206 … ]，未详细说明地给出7人死亡 … 数字。}}」會被解析為：
    • 名稱為「法国精神病学家{{link-fr|罗兰·库唐索|Roland Coutanceau}}在其著作《心理暴力：理解与行动（Les violences psychologiques : Comprendre pour agir）》(Dunod, 2014) … [https://books.google.fr/books?id=pGHIAwAAQBA … J&pg」的參數，並輸入了值「PA206   page 206 … ]，未详细说明地给出7人死亡 … 数字。」
    • {{efn}}的必填參數被系統認為沒填
因此你等於傳了無效參數給{{efn}}。故模板沒有爆炸，這是預期行為。模板未損壞，無須修理。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2025年5月1日 (四) 06:20 (UTC)[回复]
补充一下，在引用内容前加上1=也可以，即将{{efn|带等号的引用内容}}改为{{efn|1=带等号的引用内容}}。 ——自由雨日🌧️❄️ 2025年5月1日 (四) 00:46 (UTC)[回复]
这是正确做法。遇到模版参数值有等号的，需要显式指明参数名。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月2日 (五) 12:41 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

請求盡快處理部分模組的頁面歷史合併

WP:頁面存廢討論/記錄/2025/04/01#Module:Unicode data/scripts與WP:頁面存廢討論/記錄/2025/04/13#批量Module:Lang相關data提刪。Sanmosa 新朝雅政 2025年5月2日 (五) 12:53 (UTC)[回复]

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

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

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

模板:分类重定向

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

Cat-a-lot小工具錯誤

本主題或以下段落文字，在討論結束後應存檔至MediaWiki talk:Gadget-Cat-a-lot.js。

Cat-a-lot小工具似乎會將展開此一頁面到處錯誤分類（請見編輯歷史），不確定是怎麼回事。副知其他苦主@HanTsî、Yumeto。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月5日 (一) 10:14 (UTC)[回复]

我用的是維基共享資源版本，E、H用的可能是本站版本，都有出現過這種問題。--紺野夢人 2025年5月5日 (一) 10:30 (UTC)[回复]
本站版本该更新了。getMarkedLabels函数会选中.CategoryTreeBullet的a元素，title属性是“展开”（或“折叠”，但本站还没有折叠条目）。共享资源版本已差异不小，getMarkedLabels函数中的a:not([role])不选有role属性的元素，可避免此误匹配。部署共享资源版本2024年8月8日的修改补丁就可以，U:Yumeto遇到此问题时尚无补丁。--YFdyh000（留言） 2025年5月5日 (一) 10:56 (UTC)[回复]
@YFdyh000：本站是否適合直接移植共享資源現行版本？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月5日 (一) 13:05 (UTC)[回复]
我没用过共享资源版本。询问AI来看，共享资源版本改进了很多方面。从Wikipedia:维基百科工具/Cat-a-lot允许以及U:Yumeto之前在用来看，共享资源版本在本地没有明显的问题，可能应该弃用本地版本？--YFdyh000（留言） 2025年5月5日 (一) 13:29 (UTC)[回复]
共享資源版本只能識別與分類標題正簡體一致的原始碼，否則不能，而本站版本對部分與分類標題正簡體不一致的原始碼仍能識別，例如原始碼「[[Category:英國]]」不能被共享資源版本，而能被本站版本識別為「Category:英国」。--紺野夢人 2025年5月5日 (一) 23:46 (UTC)[回复]
@Yumeto：那本站現行版本與共享資源版本的差別在哪裡呢？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月6日 (二) 17:28 (UTC)[回复]
我只是從使用經驗來比較，不是太了解代碼上的差異……--紺野夢人 2025年5月6日 (二) 17:34 (UTC)[回复]
共享資源版本只能識別與分類標題正簡體一致的原始碼，能否具體指出復現步驟？--Hamish T 2025年5月6日 (二) 22:27 (UTC)[回复]
在維基百科:沙盒添加「[[Category:英國]]」（Category:英国）與「[[Category:中華民國]]」（Category:中華民國）（差異），用共享資源版本移除前者時會出現「以下頁面已跳過，因爲找不到現有分類：Wikipedia:沙盒」，而移除後者時不會（差異）。使用本站版本能移除前者（差異）。--紺野夢人 2025年5月7日 (三) 01:31 (UTC)[回复]
Special:Diff/37158362提供该功能。未对比其他差异。--YFdyh000（留言） 2025年5月7日 (三) 11:08 (UTC)[回复]
其SettingsUI似乎有问题，无法保存。--YFdyh000（留言） 2025年5月5日 (一) 14:09 (UTC)[回复]
無法保存是因為SettingsManager也要更新。--Hamish T 2025年5月7日 (三) 00:31 (UTC)[回复]
User:Hamish/Catalot.js是commons現時版本加入變體識別後的版本，已嘗試該操作且正確移除。@Ericliu1912、YFdyh000、Yumeto，展開的錯誤沒有復現。--Hamish T 2025年5月9日 (五) 10:18 (UTC)[回复]

关于single_chart的问题

本主題或以下段落文字，在討論結束後應存檔至Template talk:Single chart。

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

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

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

看起來是T:single chart中第339行開始的|UKdownload那段需要更新--竹林下小徑，月光映一葉 2025年5月5日 (一) 11:11 (UTC)[回复]
 已修复，請見版本87151010的修改。
不知道為什麼原本的|UKdownload那段中，沒用上refname的參數呢XP--竹林下小徑，月光映一葉 2025年5月5日 (一) 11:35 (UTC)[回复]
我感觉这个模板还有一些问题，大概还没有和英维那边的同步。--ItMarki探討人生 2025年5月6日 (二) 14:12 (UTC)[回复]
畢竟兩邊的Template都挺長的，所以我只有修UKdownload那段而已👉👈(戳手指)--竹林下小徑，月光映一葉 2025年5月6日 (二) 17:26 (UTC)[回复]

2025年第19期技術新聞

維基媒體技術社群現在發布最新的技術新聞。請告知其他用户這些更改；不是所有的更改都會對您造成影響。技術新聞提供其他語言的翻译版本。

本週要聞

近況更新 - 面向編輯者

  • 已啟用CampaignEvents的維基，該擴充功能發布了兩項新的功能改進：
    • 管理員現在可以透過社群配置（說明文件）選擇哪些命名空間允許活動報名。預設配置允許在「Event」命名空間中進行活動報名，但現在可以新增其他命名空間（例如專案或「維基專題」命名空間）。有了這項變更，維基專題等社群現在可以更輕鬆地使用活動報名功能來舉辦協作活動。
    • 編輯者現在可以在維基頁面中嵌入協作清單（說明文件）。協作清單自動列出維基上的活動和維基專題，可透過Special:AllEvents查看（範例）。現在，協作清單可以被加進各種維基頁面中，例如：維基首頁、維基專題頁面、自治體頁面、活動頁面，甚至是使用者頁面。
  • 經常項目 上週有27件社群提交的工單得到解決。

近況更新 - 面向技術貢獻者

  • 小工具和使用者腳本的開發者，應將其使用moment函式庫的程式碼改為使用其他函式庫，例如Intl或新的mediawiki.DateFormatter函式庫。moment函式庫現已棄用，並將開始在瀏覽器的開發人員主控台中記錄警告訊息。需修改的程式碼頁面，請在Phab工單中提供的全域搜尋結果查看，如有疑問也可在工單中提出。
  • 維護用於查詢維基數據詞彙（term）儲存表（wbt_*）的工具的開發者需要更新其程式碼，以連接到單獨的資料庫叢集。這些表格將被分割到一個獨立的資料庫叢集中。透過Wiki Replicas來查詢這些表格的工具，必須改為連接到新的資料庫叢集。參閱說明文件和相關連結。 [2]
  • 經常項目 本週軟體更新細節： MediaWiki

深入了解

  • Chart專案電子報新期數發布。 本期包括以下新訊：最快在本週（5月6日開始），Chart將進一步部署至更多wiki，並在接下來的幾週內擴大部署規模，此外Chart將探索篩選和轉換來源資料。

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 获取帮助 • 提供反馈 • 訂閱或退訂。

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

RefToolbar丢失文字标签

这段时间发现我的RefToolbar丢失了「Cite」、「Templates」、「Named References」、「Error Check」这几个文字标签，还有jQuery对话框的标题。我看了enwiki是正常的。--此條未正確簽名的留言由魔琴（討論｜貢獻）於2025年5月6日 (二) 10:57 (UTC)加入。[回复]

 已修复--百無一用是書生 (☎) 2025年5月9日 (五) 11:22 (UTC)[回复]
這不會自動登出嗎？--Miyakoo（留言） 2025年5月9日 (五) 15:52 (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)[回复]
本地似乎已经可用[3]--百無一用是書生 (☎) 2025年5月8日 (四) 02:57 (UTC)[回复]
本地需要的Data空间未开放，还是需要手工转内容模型？——Sakamotosan路过围观 | 避免做作，免敬 2025年5月8日 (四) 06:21 (UTC)[回复]
Data空间必需要用共享资源那边的，页面浏览量这种目前不支持外部数据源，目前看起来除非把页面浏览量去data空间建立数据集，否则没其他办法--百無一用是書生 (☎) 2025年5月8日 (四) 11:13 (UTC)[回复]
现在图表大小和颜色等似乎还都不能自定义，而且共享资源的Data数据也没有提供链接过去方便修改--百無一用是書生 (☎) 2025年5月8日 (四) 11:18 (UTC)[回复]
不支持用lua產生數據嗎? 這樣{{函數圖形}}就死掉了耶QQ-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2025年5月8日 (四) 11:23 (UTC)[回复]
能反馈这些问题回开发组？——Sakamotosan路过围观 | 避免做作，免敬 2025年5月8日 (四) 12:52 (UTC)[回复]

模板:Normdaten

看到一個有趣的bug，這明明是模板頁面，顯示標題卻是沒有「模板:」的「Normdaten」，不知道是怎麼回事？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月6日 (二) 20:34 (UTC)[回复]

好像是{{德語重定向}}的問題。--Miyakoo（留言） 2025年5月6日 (二) 23:04 (UTC)[回复]
準確來說，是{{非中文重定向/template}}。--Hamish T 2025年5月7日 (三) 01:05 (UTC)[回复]

合併分類重新導向設定

今天難得合併一個分類的所有修訂版本（見此處），發現系統目前仍然會給原本的頁面設定普通重新導向，而非如移動操作般改用分類重新導向模板，是否能夠修改此類設定？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月7日 (三) 08:54 (UTC)[回复]

似乎是mediawiki底層決定的，可以添加文字，但無法改變創建普通重定向的行為。--Hamish T 2025年5月9日 (五) 10:48 (UTC)[回复]

評級頁面分類問題

目前似乎所有條目都會分類到「重新導向級條目」，而非條目會分類到「重新導向級頁面」（如日本、香港、鐵道等專題）；兩者實應予以統一，以免造成混亂。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月7日 (三) 09:35 (UTC)[回复]

還有非條目級也是；其他不屬於條目的評級，可能亦有這類問題，需要一併清查。無論如何，至少要確定「條目」或「頁面」擇一。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月7日 (三) 09:36 (UTC)[回复]

翻譯文章模板爆開

如Special:Diff/87165735或是Special:Diff/85455404，我在翻譯完文章後常出現引用或是綠連爆開的情形（尤其是在翻譯時複製貼上），該如何處理？--Kanshui0943（留言） 2025年5月8日 (四) 15:24 (UTC)[回复]

“内容翻译”工具的问题，只能提交后手动善后源代码。--YFdyh000（留言） 2025年5月9日 (五) 09:10 (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)[回复]

求助

福州地圖區劃模塊問題

本主題或以下段落文字，在討論結束後應存檔至Talk:平潭综合实验区。

我這幾天去看了一眼地圖發現不對：[4]，為何現在的福州少了平潭？應該緊急修正回去。--御坂雪奈󠄁 2025年4月24日 (四) 07:05 (UTC)[回复]

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

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

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

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

請求協助上傳檔案 2025-05-02 09:22

我想要上傳的圖片來源是<https://www.ktgh.com.tw/ktgh/home / 自行截圖logo>，想要使用在光田綜合醫院的<光田醫療社團法人光田綜合醫院logo圖示及通霄光田醫院logo圖示/在右側介紹欄>。 因為目前官方希望更新維基百科的資訊，但目前我的權限不足以更新照片，還請各位協助幫忙更新照片，或是能夠提供我更新的方式。 --Jim941（留言） 2025年5月2日 (五) 09:22 (UTC)[回复]

首先，我看目前的Logo還不錯，為什麼要換？再來，想自行上傳非自由圖片並更新的話，請通過自動確認用戶（一般而言為註冊後7天並編輯了50次）後更新。--Saimmx（留言） 2025年5月5日 (一) 09:19 (UTC)[回复]

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

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

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

2 個頁面表述文字不統一, 求助

向前 頁面裡他的子女資料 和 新義安人物列表 頁面裡向前的子女資料表述文字不統一, 閱讀時實在費勁, 求助--Adyu（留言） 2025年5月3日 (六) 07:12 (UTC)[回复]

請求協助上傳檔案 2025-05-03 08:11

我想要上傳的圖片來源是 https://mp.weixin.qq.com/s/dlOsUYvj4TGS5wDrGraBRQ ，想要使用在周集中的 infobox person。

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

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

請求協助上傳檔案 2025-05-07 02:58

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

能否提供圖片來源連結？--1F616EMO（喵留言～回覆請ping） 2025年5月7日 (三) 14:38 (UTC)[回复]

請求協助編輯wikidata

剛翻譯的NVRAM條目，由於我使用了代理導致被封鎖無法編輯,需要幫忙修改 --Emulbnhom（留言） 2025年5月7日 (三) 09:32 (UTC)[回复]

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

請求協助上傳档案 2025-05-07 14:35

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

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

請求協助上傳檔案 2025-05-08 10:34

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

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

請求協助上傳檔案 2025-05-09 13:21

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


條目探討

参考資料

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

本主題或以下段落文字，在討論結束後應存檔至WikiProject talk:中国。

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

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

命名一致性判決請求：「colleges and universities」的中文翻譯

目前在英文維基百科有很多名為「List of colleges and universities in XXX」的條目，列出一個地區的所有大學、學院及專科學校。例如en:List of colleges and universities in Alabama，更多示例可見於en:Wikipedia:Featured lists#Education。但在中文維基百科，這類列表的譯名五花八門，因此或有必要進行統一。目前有這幾種譯法：

希望對此類的譯名達成共識，並依據《Wikipedia:命名常规 § 命名一致性》方針統一譯名。--Nebulatria È tra le braccia del Padre. 2025年4月22日 (二) 02:29 (UTC)[回复]

其他地区不瞭解，中国大陆的高校列表（在大陆简体模式下）应使用“高等学校”，这不是中文维基百科的“译法”（应该是英语维基百科条目需要考虑如何用英语表达中国大陆的“高等学校”概念尽管中文这一词本身是“舶来品”，但各地早已形成自己独特的高等教育体系和专门用法）。《中华人民共和国高等教育法》《全国高等学校名单》等官方法律或文件均使用“高等学校”。 ——自由雨日🌧️❄️ 2025年4月22日 (二) 02:41 (UTC)[回复]
這裡應該先就中文以外地區討論，因為兩岸四地各有各的命名規矩，基於「名從主人」原則，強行統一也不實際。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月22日 (二) 06:16 (UTC)[回复]
是的，我希望統一的是兩岸四地以外的命名，中文地區名從主人即可。--Nebulatria È tra le braccia del Padre. 2025年4月22日 (二) 06:30 (UTC)[回复]
據我所知，「大專院校」「大學」和「學院」所指的範圍是越來越窄。「大專院校」包括專科學校（台灣曾有三專與五專）、大學和學院。「大學」必須由至少三個學院組成，所以「XX理工學院」不是大學，因為只有理工兩個學院。條目應該根據所指的範圍選擇準確的稱謂。--歡顏展卷（留言） 2025年4月28日 (一) 01:32 (UTC)[回复]
這類條目通常列出所有專科學校、大學和學院，所以個人認為可以有統一的稱謂。此外在很多地區，「專科學校」也是一種「學院」，所以我認為沒有必要在標題中特別提及「專科學校」一詞。--Nebulatria È tra le braccia del Padre. 2025年5月1日 (四) 06:35 (UTC)[回复]

關於各虛構作品的列表因為關注度被大量提刪

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:收錄標準/虛構、WikiProject talk:ACG。

這些角色列表通常是昔日從各自虛構作品的主條目裡分割出來的。用角色列表的條目名去反證關注度不足，根本是找錯方向，要找至少也該用各虛構作品的名稱去找吧？
還是各位想看到此分類的角色列表，通通合併回主條目呢？
就算要掛模板，也應該改掛{{unreferenced}}而不是用{{Notability}}--P1ayer（留言） 2025年4月24日 (四) 18:24 (UTC)[回复]
@Summerize、SunAfterRain、Nostalgiacn： ——自由雨日🌧️❄️ 2025年4月24日 (四) 18:32 (UTC)[回复]
当初阁下发起的大规模IP角色列表提报，比如 银魂角色列表 FAIRY TAIL角色列表 鬼太郎角色列表 流星花园角色列表 BORUTO-火影新世代-NARUTO NEXT GENERATIONS-角色列表 暗杀教室角色列表 我们这一家角色列表 爆漫王角色列表 足球小将角色列表 钻石王牌角色列表 Fate/Zero角色列表 排球少年！！角色列表 等等，理由是因为缺少第三方资料吗？@自由雨日--Whq19911224（留言） 2025年4月25日 (五) 03:13 (UTC)[回复]
Wikipedia:收錄標準/虛構#虛構集合里面提到：“在一个虚构主题实体的集合中，至少需要有2项子主题符合WP:虚构准则或本身具收录标准”，而博人传的角色列表里面，漩涡博人和宇智波佐良娜两位主角都有独立条目，前者在本站上过DYK，后者虽然本站质量不行，但英文版却有足够的可靠来源供中文版改善。请问都这样了，还是要删博人传的角色列表吗？Whq19911224跟我说他是参考自由雨日的做法。如果关于博人传的角色列表的存留，我的理解没有任何问题的话，那就凸显出自由雨日你的做法不仅草率一刀切！更离谱的是还把别人带坏！--💊✖️2️⃣3️⃣（留言） 2025年4月25日 (五) 03:29 (UTC)[回复]
@Liu116 大致看了一下记录，他应该是3月2日开始陆陆续续提报角色列表的。--Whq19911224（留言） 2025年4月25日 (五) 03:40 (UTC)[回复]
所以呢？阁下最开始对notability的判断就同我截然不同（将我认为不符合收录标准的改成符合；将我认为符合的改成不符合），但“出事後”却第一时间说是“学我”提报的；而这裏又摇身一变，化身成“审问者”？看阁下在讨论的态度，实在不像是希望删除或合并的立场，反而是强烈倾向保留的立场，实在无法不让人联想到WP:POINT…… ——自由雨日🌧️❄️ 2025年4月25日 (五) 14:13 (UTC)[回复]
  • 我在提报时均对照了收录标准和收录标准/虚构，并简单查看了外文版的条目和网络搜索。至于你提到的用户，我不认为我需要为其他用户的行为负责。我同他没有过任何交流，没有任何鼓励他提报的留言；反而留意到他3月31日在我提报某个角色列表之後13分钟便直接移除了收录标准模板（86637639），所以他去提报其他角色列表（甚至是符合收录标准的列表）我衹感到困惑。 ——自由雨日🌧️❄️ 2025年4月25日 (五) 03:58 (UTC)[回复]
    我当然知道你没有鼓励他人效仿你的做法，你当然不需要为别的用户的行为本身负责，但你还是要对这一系列操作所带来的结果和一系列影响负责，就算不符合标准的条目数量较多，体量较大，历史遗留问题要想处理就更应该谨慎谨慎再谨慎，而你很显然没有做到这一点，不仅你自己出现误杀的情况，还连带别人也一起误杀，这就是你带来的结果。不少时候结果是很重要的，特别是处理这类问题时。--💊✖️2️⃣3️⃣（留言） 2025年4月25日 (五) 04:04 (UTC)[回复]
    如果有对明显符合收录标准的列表我判断失误，我在此致歉；如果实际上确实符合但佐证收录标准的来源需要寻找不少时间，则我不认为自己必须有改善这些角色列表使其符合收录标准（然後纔能挂notability模板）的义务，中维的提报30日+提删近1月我认为时间已不能说非常紧张。此外，正是出于谨慎，我并未在幾日内提报所有的角色列表。至于“连带别人也一起误杀”，同我上条留言。 ——自由雨日🌧️❄️ 2025年4月25日 (五) 04:15 (UTC)[回复]
    就算有30天的时间，如果不是我看到这个讨论，那博人传的角色列表不还是要遭到误杀？针对这样的历史遗留问题，有更好的方式处理，比如自己先不擅自挂模板，而是先在互助客栈里面讨论，这样可以降低误杀的几率，你有本事做到100%不误杀，你可以自己擅自去提删，既然现在已经证明你不能100%做得到，那就不好意思，必须先对你之前对类似条目的提删请求进行搁置，留更多时间让社群讨论及处理了。不论是互助客栈还是AFD，不是人人都会去逛，像我就不会天天去AFD那里去看，但这么重要的问题，两个地方同时展开讨论，总比只在一个地方讨论更好，在公告栏里贴上讨论链接效果更好。--💊✖️2️⃣3️⃣（留言） 2025年4月25日 (五) 04:24 (UTC)[回复]
    @Liu116 我也详细参考一些条目的提删过程 Wikipedia:頁面存廢討論/記錄/2025/04/19#729声工场 Wikipedia:頁面存廢討論/記錄/2025/04/23#宇宙世紀 Wikipedia:頁面存廢討論/記錄/2025/04/23#小書痴的下剋上角色列表 。另外，若同样因为存在明显符合收录标准的列表所造成的判断失误，我在此道歉--Whq19911224（留言） 2025年4月25日 (五) 04:24 (UTC)[回复]
    你能否解释一下3月31日将我在《數碼暴龍App世代角色列表》挂的{{notability}}改成{{notability unreferenced}}；然後又去明显符合收录标准的《哆啦A梦角色列表》裏将{{notability unreferenced}}改成{{notability}}？ ——自由雨日🌧️❄️ 2025年4月25日 (五) 04:55 (UTC)[回复]
    两者对比了一下，你提报两个条目时候仅相隔1分钟：前者当时有11个来源，其中3个第三方资料，你挂notability（后来我增加了一个来源，把notability改成notability unreferenced）；后者当时有4个来源，其中2个第三方来源，你挂notability unreferenced（后来我把notability unreferenced改成notability）--Whq19911224（留言） 2025年4月25日 (五) 06:15 (UTC)[回复]
    明顯符合收錄標準的條目/主題，還要去掛模板，你可以掛之前去想一下嗎？--Aqurs 2025年4月25日 (五) 06:48 (UTC)[回复]
    路过，之前协助fix了几个提报，说说个人观点。前者的11个中不是3个，而是只有1个是相对OK的，那就是电击Hobby的那个来源，可以推WP:NFICT“包括对周边产品的有效介绍...”，虽说有挂价格，但是考虑电击Hobby以及从内容上看，其实还算可以，假设让我（不修的话）我可能会挂notability unreferenced，但要是有人质疑这个来源挂notability，也不是说不行，可以争论——其他10个来源，有播映方、制作方、爱好者百科等等，基本都不行（证明关注度）。后者有超过10个子主题有独立条目，虽然条目内没有列出什么来源，但在这种情况下假设我挂notability，除非是建立在我认为这10个子主题都不“符合WP:虚构准则或本身具收录标准”的前提下，我才会这样做，否则我就会挂notability unreferenced，这是为了充实条目本身的来源，而不是质疑它的关注度——讲真，这两者不是一个级别的情况。个人建议您在处理此类情况时需要仔细一些。--银色雪莉（留言） 2025年4月25日 (五) 07:27 (UTC)[回复]
理由是因为我认为不符合WP:收录标准或WP:收录标准/虚构。 ——自由雨日🌧️❄️ 2025年4月25日 (五) 03:58 (UTC)[回复]
既然有人提起的话，我的看法就是：老条目基本不管，“You dig up the past, all you get is dirty.”，很多这类列表是关注度出现之前或之后没多久就出现的独立列表或分割出来，考虑到这类当时的编辑基本没有加参考注脚的编辑习惯；还有编辑群体的稀少，到近几年，这些条目基本上没有维护（无论是没人是还是缺少新内容补充）。可以考虑保留的依据，或者还可以看一下Wikipedia:資料頁是否适合。对于近5~10年新分割的，除非满足Wikipedia:收錄標準/虛構的列表分割或者Wikipedia:資料頁，说真的，没必要分割。另外，这样大批量加关注度的，我想起某位。——Sakamotosan路过围观 | 避免做作，免敬 2025年4月25日 (五) 00:44 (UTC)[回复]
以前这类条目大多都是因为会占用主条目大量篇幅，才进行拆分的，有的作品的角色列表虽然会不符合收录标准的要求，但其本身体量大，涉及到的对剧情发展起到一定作用的角色也多，如果仅考虑到收录标准的问题将其合并（对内容进行优化后），又会产生将主条目挤爆这一新的问题。所以我主张，对于部分虚构内容集合条目，如果其不符合收录标准要求，但以最严格的标准去除掉所有的冗余内容（包括但不限于琐碎细节，及一些对剧情发展作用较小的角色等等）后，篇幅大到仍然不适合合并到主条目当中的，应给予适当的豁免，但仍需尽量附上一些可靠来源（不论一手、二手还是三手）。--💊✖️2️⃣3️⃣（留言） 2025年4月26日 (六) 02:58 (UTC)[回复]
我同意閣下提及的「瑣碎細節、配角」等「最嚴格的標準」需要執行，惟還有一個標準，即WP:可供查證。若如閣下所言，只是「儘量」附上一些可靠來源，就難免掉進WP:原創研究的陷阱裏面。據此進行更嚴格的優化後，若內容能夠併入主條目即併入，若不能也無妨，因爲這很可能代表該角色列表其實符合收錄標準，又或可以根據NT:NRVE中「由於格式和展示的原因而建立一篇分離的條目」獲得保留。
對於這類編者群小、又缺乏可靠來源的主體，我最擔心的是這些條目會變成垃圾場，留着發臭，各種原創研究和版權侵犯層出不窮，這我在大愛電視劇和小衆生者傳記條目已經看過無數次了。所以我很認同下方Nostalgiacn君的留言：「留給我們的唯有一條路，那就是藍桌圖書館的道路……不刪的話，條目永遠是『初級』」，像是人人看到敬而遠之卻沒人想去清理的垃圾桶，倒不如直接砸掉，讓有心長期維護的人看到這裏缺了個桶或者是一張桌才再立一個，因爲可預期負責的條目建立者應該會比較積極維護。--1F616EMO（喵留言～回覆請ping） 2025年4月26日 (六) 03:15 (UTC)[回复]
感谢补充，特别是在可供查证方面和“格式和展示的原因”而创建分离条目这方面，后者更是说明收录标准的规则和执行不是死的，所以说，面对一些篇幅很长的角色列表条目，提报notability之前就应该评估一下这当中必要的内容占了多少，或者干脆自己动手进行清理，看看剩下多少，这种方法也能减少误杀概率。--💊✖️2️⃣3️⃣（留言） 2025年4月26日 (六) 03:40 (UTC)[回复]
請注意我上面這番話的重點是可供查證，若非可供查證，一切免談。維基百科條目是以第二或第三手可靠來源爲主寫作的，所有無法滿足這點的內容都該刪除。收錄標準是指引，可供查證和非原創研究是方針，還是三項核心內容方針；若諸君連核心內容方針都漠視，就請出門右轉Fandom，祝編安。
沒有來源的內容就像垃圾桶，一堆沒有來源或濫用第一手來源的條目就是堆填區，稍有理解的維基人都會敬而遠之，不屑與之爲伍；問題是我們的讀者不會選擇，就像貧民窟的饑民，以爲堆填區是珍饈佳餚。--1F616EMO（喵留言～回覆請ping） 2025年4月26日 (六) 13:44 (UTC)[回复]
然而Fandom目前因为协议不兼容原因无法收录中文维基百科的内容。----大筒木博人罪大滔天，搞的甜甜圈怨声载道。 2025年4月26日 (六) 15:23 (UTC)[回复]
逃避不是辦法，維基百科不接受就是不接受。您有東西不用了，家裏滿地都是垃圾、沒地方放了，想送給朋友，他不接受，你會不會就讓它爛在家裏，絆倒自己？當然不會，您肯定丟了，若是閣下行爲不合常理那沒話好說。維基百科內容還好，自己找地方安置幾乎零成本，藍桌圖書館甚至自己電腦的某個文件夾都是存檔的地方，何不用也？反正外部站點不收肯定不是反對刪除的理由，維基百科是維基百科，Fandom是Fandom。--1F616EMO（喵留言～回覆請ping） 2025年4月26日 (六) 15:47 (UTC)[回复]
若閣下說「這樣不方便協作改善」，我必須指出添加無法查證的內容在維基百科是在擾亂而非改善。「不能或拒絕遵守可供查證方針」是被明確指出的擾亂性編輯行爲之一，違反維基百科的核心內容方針（見上，不再贅述），爲維基百科所不容。若閣下希望使用協作的模式完善此類內容，建議閣下看一下如何下載MediaWiki還有Wiki農場（見鬼了，怎麼又是一個缺來源條目），自己建一個站。--1F616EMO（喵留言～回覆請ping） 2025年4月26日 (六) 16:01 (UTC)[回复]
對了，差點忘了我們隔壁還有個學院，可以去碰碰運氣。--1F616EMO（喵留言～回覆請ping） 2025年4月26日 (六) 16:39 (UTC)[回复]
WP:頁面存廢討論/記錄/2025/03/29#魔兽系列地名列表、WP:頁面存廢討論/記錄/2025/03/29#魔兽系列角色列表…… ——自由雨日🌧️❄️ 2025年4月26日 (六) 17:35 (UTC)[回复]
沒想到這倆都可以無共識……( π )题外话私以爲這倆已經形成了刪除共識，匯入至其他站點其實是刪除的連帶操作。--1F616EMO（喵留言～回覆請ping） 2025年4月26日 (六) 17:39 (UTC)[回复]
实际上我是有将相关内容迁移的想法，但是鉴于外部站点的协议与维基百科目前使用的协议不兼容。只能等到外部站点升级到与维基百科相同的协议之后再迁移。（有前人已经造轮子就不需要再重复造轮子。）并且可供查证这一点的话，英语的ACG条目也有类似的问题。例如漩涡博人在英语的条目关于大筒木博人一词的解释就没有遵守查证。（英文原文:where his constant fights with the Ōtsutsuki celestial resulted in him becoming an Ōtsutsuki genetically, giving him the nickname Boruto Ōtsutsuki (大筒木 ボルト, Ōtsutsuki Boruto) by some. ）----大筒木博人罪大滔天，搞的甜甜圈怨声载道。 2025年4月26日 (六) 22:36 (UTC)[回复]
Miraheze，請。維基百科不是不經篩選的輪子堆放處。--1F616EMO（喵留言～回覆請ping） 2025年4月26日 (六) 23:52 (UTC)[回复]
另外英維錯了不代表我們也得錯。--1F616EMO（喵留言～回覆請ping） 2025年4月26日 (六) 23:53 (UTC)[回复]
我没有搞错重点。角色列表条目往往是作为相关作品主条目太长，为不影响阅读而分割出来的（Wikipedia:格式手册/虚构#条目的拆分）。这些列表条目皆以剧情等虚构世界视角的内容为主，来源就是虚构作品本身，所以Wikipedia:格式手册/虚构#来源和引用说：“作品条目的剧情简介不强求引用来源，但为防范原创研究，内文引用多多益善”。当然不可否认的是只有剧情相关内容的角色列表条目确实不符维基百科定位，Wikipedia:格式手册/虚构里面也明确提到“分拆条目要有一定的现实世界信息”，而现实世界信息要求是“尽可能多地使用必要且有用的第二手来源”。改善肯定要改善，该加来源的地方肯定要加，不过你说的什么“維基百科條目是以第二或第三手可靠來源爲主寫作的，所有無法滿足這點的內容都該刪除”有点一刀切的味道……还是那句话，条目能救回来的先尽量去救（具体怎么“救”格式手册已经告诉我们了），实在改善不了再谈删除/合并。--💊✖️2️⃣3️⃣（留言） 2025年4月28日 (一) 09:29 (UTC)[回复]
参见WP:ACGN，WP:虚构集合。有一部分是可以保留的。--在下荷花，请多指教（欢迎签到） 2025年4月25日 (五) 01:45 (UTC)[回复]
要搞也是一个一个来，短时间内大量去搞，很容易误杀一些值得保留的，且让有心改善的用户忙不过来。就算是要大量搞，也应该是优先挑那些没有改善空间的，并作具体说明，然后有争议的先放到互助客栈里一个一个具体讨论。三年前有人也是短时间内大量提删虚拟角色条目，结果这些提删请求当中以保留结案的有20个左右，足以说明这样一刀切的做法是有多浪费社群资源，且相当令人反感！--💊✖️2️⃣3️⃣（留言） 2025年4月25日 (五) 01:58 (UTC)[回复]
连火影、海贼王这样的大IP的衍生角色列表都要提notability，真是荒唐到极点！！！--💊✖️2️⃣3️⃣（留言） 2025年4月25日 (五) 02:26 (UTC) 👍1[回复]
目前英语社群是将博人传的角色列表直接合并到主作品的列表内。（还有一些角色本身就没太多关注度，例如波风水门、千手柱间这种连英语都没有条目的角色。）----大筒木博人罪大滔天，搞的甜甜圈怨声载道。 2025年4月26日 (六) 04:17 (UTC)[回复]
英文版的en:Wikipedia:Notability_(fiction)#Lists_of_fictional_elements这里没怎么具体展开，不清楚他们的标准是什么。但按照中文版明文规定的标准还是照常符合的，另外还要考虑到去除冗余内容之后，剩下的内容是不是相对于主条目来说还是太长的问题，就更是要做出谨慎判断。建议以后提删之前，先把条目内容通通清理一遍，反正不论是合并还是不合并，早晚都要做的，合并之前就清理完了，合并的时候就方便不少了。--💊✖️2️⃣3️⃣（留言） 2025年4月26日 (六) 04:31 (UTC)[回复]
我認為提刪應抱持謹慎的態度，只針對那些明顯不符合收錄標準的條目執行，而非大規模地草率提刪。像某位使用者大量加入收錄標準模板，連WP:虛構集合提到符合收錄標準的多啦A夢神奇法寶列表都加入。昨天加入的模板甚至連日期都打錯。--夏冰 25時、ナイトコードで。 2025年4月25日 (五) 02:48 (UTC)[回复]
Wikipedia:收錄標準/提報裡光是角色列表就被提報超過100條，這樣大量提報是要怎麼改善，就等於是要讓這些條目因大量提刪來不及改善就合併回去或刪除。--Kevin765432（留言） 2025年4月25日 (五) 03:20 (UTC)[回复]
(＆)建議 我的建议是，因为涉及面太广了，五年前（即2020年之前）创建的角色列表条目可以按照历史因素豁免提报（即使缺少第三方资料），同时提报中的相关条目30天到期后免于提删。--Whq19911224（留言） 2025年4月25日 (五) 03:58 (UTC)[回复]
私以爲「缺少第三方資料」的條目不應該因「歷史因素」獲得保留。Wikipedia:可供查證是自建站以來就存在的核心方針，若說是「歷史因素」，那麼按照此方針，「缺少第三方資料」的內容應該刪除，連帶條目也會因沒有足夠內容而難逃合併或刪除命運。私以爲這正是收錄標準的運作邏輯之一：若沒有第三方可靠來源，或這類來源十分稀少，根本就寫不了這麼多，極端情況下會變得過短，繼而被刪除。至於大量提報的問題，私以爲豁免並非解決問題的方法，此處提出兩個想法：
  1. 延長收錄標準提刪期限，或按專題特定情況添加此類例外：這樣可以讓編者有更充裕時間改善條目，但前提是他們能確實知道自己的條目（或所關注的專題的條目）被質疑不符合收錄標準，不然還是一樣。這一點可以通過如同一般提刪一樣通知條目創建者解決。
  2. 限制同時進行（同專題）收錄標準提刪的數量，以免相關編者分身乏術；但缺點也很明顯，容易造成提報過多但提刪額度不足的瓶頸。
--1F616EMO（喵留言～回覆請ping） 2025年4月25日 (五) 04:29 (UTC)[回复]
@1F616EMO 按照阁下的说法我可以理解，但是按照@Liu116的说法火影忍者角色列表、ONE PIECE角色列表、寶可夢動畫角色列表三个条目又应该保留，所以目前是否达成共识？--Whq19911224（留言） 2025年4月25日 (五) 04:35 (UTC)[回复]
这三部作品都有至少2个角色可以独立成篇。就算忽略方针和指引上面明文的要求，光是删除冗余内容后留下的篇幅也是一望而知应该要留，毕竟作品本身体量大，在角色介绍里面要写的东西自然就会多。--💊✖️2️⃣3️⃣（留言） 2025年4月25日 (五) 04:48 (UTC)[回复]
其实，对于历史因素导致的条目缺少第三方资料，为什么要纠结于去补第三方资料呢？因为有时候时间太久了，第三方资料也很难找到了。但是，基本上日本动漫作品都有官网吧，那为什么不能用官网资料呢？@1F616EMO--Whq19911224（留言） 2025年4月25日 (五) 04:39 (UTC)[回复]
官网资料属于第一手来源，一手来源不能用来证明符合收录标准。--💊✖️2️⃣3️⃣（留言） 2025年4月25日 (五) 05:17 (UTC)[回复]
一个月前 自由雨日 陆续提报的角色列表条目，从前两天开始已经陆续到30天了期限了，仍挂notability的条目已经有被提删了，后期还会有更多，其中大部分条目都没有任何改善，看看到时候有没有什么应急措施或者豁免方法吧@Liu116@1F616EMO--Whq19911224（留言） 2025年4月25日 (五) 07:11 (UTC)[回复]
这类历史遗留问题，要想认真对待，就要做好打持久战的准备，确保得到社群的长期关注，要考虑的问题不仅仅是合并，更多是相关内容移回主条目时，要把一些冗余的内容去除掉，这工作量可不小啊，这更体现擅自提删的坏处。个人认为，应该先整理一个表格，筛出明显有问题的先处理掉，然后有疑问的在社群里进行讨论，有共识了再走notability程序提删或合并。这里有疑问的主要是指，相关的列表可能有至少2个子主题有独立成篇的潜力，只是还没正式独立成篇而已，例如頭文字D角色列表里面，头号主角藤原拓海对于互联网亚文化的长远影响大家有目共睹，且改编的电影还是由周杰伦饰演，明显有潜力重新建立独立条目，然后其他主角也可能或多或少有独立成篇的潜力。像这样的情况就可以进入所谓的“观察名单”，毕竟头D都多少年前的作品了，来源不会比近期新出的作品好找。--💊✖️2️⃣3️⃣（留言） 2025年4月25日 (五) 05:07 (UTC)[回复]
其實我並不太熟悉ACG列表條目，只是天天看着新手在加無來源內容，巡查最近更改的時候看着心煩，所以也不好說些什麼。不過通知收錄標準提報倒是可以獨立開案討論，因爲目前條目建立者若不特意查看並不會知道自己的條目已經被打上關注度的標籤，也就無從察覺需要改善，變相把所有事情積壓到最後一刻。--1F616EMO（喵留言～回覆請ping） 2025年4月25日 (五) 05:44 (UTC)[回复]
你對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)[回复]

更名程序的基準

本主題或以下段落文字，在討論結束後應存檔至Talk:大罷免。

「2025年中華民國大罷免潮」→「大罷免潮」提出討論僅僅一天就搶快改名符合程序基準嗎？近年部分時事主題的條目討論時程不足或是討論廣泛性不足即逕付更名，是否應照以往慣例通盤檢視而非放任選擇性破例。--Cbls1911（留言） 2025年4月25日 (五) 11:29 (UTC)[回复]

明明現在大部分媒體都在說「大罷免」，為何還要堅持使用相對較少的「大罷免潮」這一名稱？--日期20220626（留言） 2025年4月28日 (一) 00:52 (UTC)[回复]
他反對的可能是去除「2025年中華民國」吧？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月30日 (三) 12:39 (UTC) +11[回复]

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

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

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

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

既然没人回应，那我继续排查和提报了，扔到存废讨论再说吧。--自由米花🌾🌼 2025年5月8日 (四) 02:45 (UTC)[回复]
@糯米花：一、我個人認為總榜單可以佐證收錄標準，另外符合通用關注度的也應予以保留，而不是以主觀的知名或瑣碎來決定是否保留條目。二、閣下的排查和提報是批量進行嗎？其中大魚 (歌曲)及小美滿條目我已經打撈重寫過了，還是被閣下加上了{{fanpov}}模板。閣下可否先看過條目內容再添加模板，而不是對著周深歌曲的分類直接批量添加？——〚 十九 〛 2025年5月8日 (四) 06:33 (UTC)[回复]
十九君您好，理解您的忧虑，也借此机会说明在下挂模板的标准：
  • {{Notability}}：条目内的source排除不可靠来源后，剩下的来源仅为软文者，或来源仅作顺带提及，非有效介绍者。
  • {{trivia}}或{{fanpov}}：条目内事无巨细地记录了这首歌在哪里被唱过。个人认为，这些资讯琐碎且无用，即使有可靠来源也是顺带提及之用，非专注于介绍歌曲本身。
  • {{advert}}，条目内引用了知名或不知名的乐评人，说这首歌如何好听、温柔、委婉、动感等。即使开头加上了“XXX评价”，但大量的正面评价堆砌也是有宣传之嫌。
具体到您所提及的大鱼和小美满，个人认为在评价和演出的环节还是有些琐碎的。当然，和其他条目相比，这两个条目做的也相当不错了，个人觉得属于可挂可不挂的范畴。就算撤下模板，本人也没有异议。
最后请您保持善意推定，所有的条目本人都是看过后再添加模板的，并不是对着条目批量添加。有些歌曲本人看了之后觉得条目篇幅较少，没有琐碎宣传内容堆砌，source也不是软文，便没有添加。（如：同行同往，虽然source有强烈的利益相关，但至少还是写成了一篇新闻的样子。）当然，模板添加与否可能和其他人有所争议，指出有疑虑的部分进行探讨以确定边界也是有必要的。謝謝您。--自由米花🌾🌼 2025年5月8日 (四) 09:31 (UTC)[回复]
@糯米花：感謝閣下的回應。適才實在是看到自己花了時間重寫的條目被掛模板有些氣惱了，就上面和閣下討論頁中帶情緒的言論向閣下道歉。評價和演出的部分，我是參考了女神和老派約會之必要等獲選優良條目的條目來寫的。除此以外，也感謝閣下付出心力來清理相關條目，我想做這樣的事情很久了。——〚 十九 〛 2025年5月8日 (四) 11:51 (UTC) 👍1[回复]
抱歉，我不會像十九君那樣客氣。此事及日前看見京劇名劇目龍鳳呈祥 (京劇)報不滿足收錄標準，讓我對糯米花的判斷力及知識水平十分失望，世事不是有善意就足夠。而且，已參加評選條目顯然與生米一粒的風格截然不同，不去了解發生過何事，然後只用掛板來發表看法，絕對不是好手法。--Factrecordor（留言） 2025年5月9日 (五) 13:22 (UTC)[回复]
@Sinsyuan：据方针WP:讨论發起位置“讨论结束后亦应让讨论原地存档，避免重复在多个页面存档后出现讨论分支。”，我移除了你添加的{{存档至|Talk:周深|WT:收錄標準/音樂}}模板，也请之後不要再添加了。若需留讨论记录可以向这些信息框的讨论页發送讨论通告来链接。 ——自由雨日🌧️❄️ 2025年5月8日 (四) 06:51 (UTC)[回复]

請求搬出沙盒條目：戰神賽特（War God Seth）

條目位於：User:Superich58/沙盒

條目為原創虛構角色「戰神賽特」之介紹，包含角色設定、出處與應用背景，語氣中立，格式完整，無外部導流。希望能協助搬入主空間，謝謝！

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

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

关于闽越都城的争议

请至讨论页继续讨论：
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

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

有關首都只有福州而拒漢六城不是首都的文獻論證就有：2001年的闽越文化的几个问题——兼论武夷山汉城不是闽越王城、2004版《福建歷史地圖集》（西漢閩越王國、漢軍入閩）、2014年欧潭生：汉初闽越国冶都考、2019年黃榮春：闽越国都城与东冶港、2024黃榮春的《閩都考古錄》。正如在2004版《福建歷史地圖集》所標註的，如果所謂的拒漢六城就是所謂的首都，那為何在當時也還具有爭論的情況下，卻不同時像冶城那樣，兩城同時用上首都的圖標？其次，如果在後期的「漢軍入閩」時也升為首都的話，那為何所謂的閩越國王城不直接和閩越國都城一樣，使用不同的字體和顏色加粗？而如果，真有那位閣下講的所謂：而且官方的態度就是有兩個都城，那請問為何為何所謂的閩越國王城是首都的觀點不佔據主流？反倒是以福州論的閩越國都城的說法佔據主流？？？--御坂雪奈󠄁 2025年4月30日 (三) 17:25 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
有关讨论發起位置等的讨论
——自由雨日🌧️❄️ 2025年5月1日 (四) 18:23 (UTC)[回复]

「冨」

本站標題是否應用此字，或改用「富」為宜？如富嶽三十六景（部分轉換）、冨樫義博等。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月1日 (四) 15:11 (UTC)[回复]

这个字只是富的异体字吧。感觉合并为佳。--The Puki desu（留言） 2025年5月2日 (五) 06:10 (UTC)[回复]
如果是新舊字體差異的話，應當推回舊字體，然而如果異體字的話，則應比照蘇姿「丰」和謝衣「鳯」保留。--赤羽蒼玄（留言） 2025年5月2日 (五) 06:52 (UTC)[回复]
前面兩個算是中文異體字，這個算嗎？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月4日 (日) 05:34 (UTC)[回复]
似乎是算的。--Hamish T 2025年5月4日 (日) 10:06 (UTC)[回复]
应该使用中文常用字形。中文主要工具书甚至都没收这个字。--Kethyga（留言） 2025年5月2日 (五) 10:44 (UTC)[回复]
此類漢字問題可分爲以下情形：
  • 如屬中文異體字：（依WP:异体字）
    • 且在所有地區罕用於所在語詞，則改爲常用字；
    • 且在至少一地常用於所在語詞，則先到先得，不得修改，例如謝衣鳯；
  • 如非中文異體字：
    • 所在語詞屬於中文專有名詞，則保留此字，例如含有「の」的中文品牌或作品名稱；
    • 所在語詞不屬中文專有名詞：（依NC:USECHINESE）
      • 且不比中文翻译的名称在中文中更加常用，則改爲中文翻译的名称；
      • 且比中文翻译的名称在中文中更加常用，或不存在中文翻译的名称，則保留此原文名称；
「冨樫義博」顯然不合修改情形，而符合保留情形；「富嶽三十六景」僅經Google則較難判斷。--— Gohan 2025年5月6日 (二) 03:21 (UTC)[回复]

主席的玉照没了

本主題或以下段落文字，在討論結束後應存檔至Talk:毛泽东。

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

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

标题已修改

由于与本讨论页或讨论主题无关，本框内討論文字已關閉，相關文字不再存檔。
如有異議，請諮詢互助客棧或其他管理員。執行人：—KurGenera(留言) 2025年5月8日 (四) 00:03 (UTC)

（節刪）

說的對，一大堆品質低劣的條目，嘖嘖。--August討論‧簽名‧回復請ping 2025年5月3日 (六) 11:44 (UTC)[回复]
抱怨和直接扔进垃圾桶（指一股脑的提删）最容易。动手改善最难。呵呵（恭喜你你又水到一个议题）。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月6日 (二) 03:58 (UTC)[回复]
不明白这个讨论串的意义在哪里，比起还算有点意义的stub，感觉在客栈讽刺除了刷存在感毫无意义啊。--—远方传来风笛（Talk） 2025年5月7日 (三) 16:33 (UTC)[回复]
(：)回應，開串主當時一發起這農場標題，我那時在監視列表瞬時看到，就想立即回覆吐槽他，「我維何時變得如此空泛虛談？！」，但還是忍下來了，隱而不發。
後來看到首先回覆的用戶U:August.C，這使用者「自稱是個高中生」，忽然間我就似乎意會到了什麼。我猜想大概就是年齡的原因吧。
老實講，我想不出發這標題有何具體意義，完全沒提到任何具體條目，只丟個標題說我維如何，然後空泛虛談地要旁人改善，要旁人【洗編輯數】，看了實在讓人「黑人問號？！」。我內心只覺得發這類農場標題文有何意義？
沒指定哪個條目需要改善→變成標題農場，易流於空泛虛談。
要旁人改善此情形→我維中文條目達140餘萬條，到底要人改善哪個條目？！讓人看得黑人問號。
能待在我維裡面，幾乎都是老骨頭了→編輯次數超過500次後，為何要響應發串者洗編輯數？難道是為了取得超資深延伸確認使用者權限？--Znppo（留言） 2025年5月7日 (三) 17:14 (UTC)[回复]
(！)意見，我的結論，發起這種空泛議論似乎完全不會有任何效果，自然也不會有旁人聽從你的空泛號召，所以又輪迴到，起始迴圈Loop，發這類農場標題文有何意義？
只能說年輕真好，看了開串使用者User:Kurgenera在Wikipedia:權限申請/申請巡查權裡，在申請文中提到他最近課業如何，看來亦是一個學生。
再搭配，首先回覆的用戶U:August.C，這使用者「自稱是個高中生」。
結論，我只能說年輕真好，如無太大意外的話，實際年齡和心智年齡，兩者似乎是正相關。--Znppo（留言） 2025年5月7日 (三) 17:14 (UTC)[回复]
@Znppo：调整了一下语法：我将您第一条留言和第二条留言之间的<br />改为了“回车”+:（87186343）。如果用<br />或<br>的话，其他编者如果对您第一条留言点按回复，您的下一条留言就会被自动缩进（见我在沙盒的测试［一］、［二］，导致您第二条留言错误显示为回复其他留言——如［二］中直接变成了回复test留言），另见这一实例。 ——自由雨日🌧️❄️ 2025年5月7日 (三) 17:34 (UTC)[回复]
也没说是年轻人就一定有问题吧，我看到不少老人依旧是我行我素。----Cat on Mars 2025年5月7日 (三) 18:00 (UTC)[回复]

籍贯与出生地

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

“将籍贯写入出生地的情况可能会比较多”能否举例。关于分类，请指出具体问题和可行方案？某地人的概念非常复杂，不止于籍贯和出生地，分类的说明是一个建议做法。--YFdyh000（留言） 2025年5月4日 (日) 12:29 (UTC)[回复]
分類比較寬泛，不應該限制過多，否則就會出現大量「北平出生人物」這種過度分類（北平本身倒還好，要命的是極小的行政區劃也要分立的情況）。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月4日 (日) 13:50 (UTC)[回复]
中維應將行政區劃方面的人物分類全部棄用定義長期不精準、混亂、有歧異的「**人」，改為更大範圍的「**相關人物（People associated with xx / People of xx）」 (68110385)，底下新增定義明確的「**出生人物（Births in xx）」，同時使「**相關人物」與「**出生人物」和其他語言對應分類的定義更加吻合。--HanTsî（留言） 2025年5月5日 (一) 04:01 (UTC)[回复]
與籍貫 / 故鄉 / 家鄉、戶籍地 / 居住地、學籍（「**（高級中等以下學校）校友」）、工作地（「**（學校）教職員」、「**政治人物」（北京市政治人物 / 台北市政治人物））等有關行政區劃人物和分類屬於「**相關人物」。--HanTsî（留言） 2025年5月5日 (一) 04:25 (UTC)[回复]
写入相关人物更加不精准吧。是否不少人物可能出现10个以上的xx地相关人物分类。--YFdyh000（留言） 2025年5月5日 (一) 04:27 (UTC)[回复]
那還請你提出一個大家長期能夠接受、精準、不混亂的具體「**人」定義出來。並非直接出現在「**相關人物」，而是透過現有子分類與「**出生人物」間接出現，就如同國家方面的「在**的外國人」，傳主條目不應直接出現在「在**的外國人」，應透過子分類（如大使 / 運動員 / 學者 / 演藝人員 / 留學生）間接出現，直接在傳主條目添加「在**的外國人」就會出現被用戶移除的行為（76216789、76219044），直接讓傳主條目出在「**相關人物」當然也會出現類似行為，所以一定是間接。每個人都有遷徙自由（當然也有被迫遷徙的情況），間接出現在複數個、甚至超過10個的「**相關人物」裏頭本來就是件再正常不過的事，「在**的外國人」亦同。--HanTsî（留言） 2025年5月5日 (一) 05:08 (UTC)[回复]
棄用「**（行政區劃）人」的想法在2023年8月就表達過。--HanTsî（留言） 2025年5月5日 (一) 05:51 (UTC)[回复]
「籍貫」本就是各地定義大相徑庭的概念，不宜如此使用。其條目目前的定義句「籍贯，通常指父親與祖父的長居地」涉嫌以中國大陸為中心；況且「父親與祖父的長居地」幾乎不會出現在條目序言，毋庸置疑無法define人——defining是英維分類相較中維分類更爲寬鬆的要求，更遑論合乎中維更爲嚴格的「定義性特徵」。「父親與祖父的長居地」若爲任何分類標準，則會導致此等分類滅絕。--— Gohan 2025年5月6日 (二) 03:44 (UTC)[回复]
同意@神秘悟饭關於「籍貫」缺乏定義性的見解。我推的做法是：剔除「籍貫」為收錄為「xx人」的條件。「people from x」為「xx人」的等價，意為「來自xx的人」。在英文中，「people from x」脫離不了「出生」（born）、「成長」（raised）的脈絡，「xx人」的分類認定宜以此為原則，並搭配個案判斷：
例1：出生於上海，生活直到5歲遷居香港，此後在香港就學成長。→「香港人」（✔）；「上海人」（可以✔）
例2：出生於臺北市的醫院，但只在基隆生活成長。→「基隆人」（✔）；「臺北市人」（✗）
在中國大陸坊間或許有因為父母來自重慶被稱作「重慶人」的習俗。但百科全書的受眾是一般、不特定使用者，因此必須採用「普世觀點」。平時條目內文編纂，應將「xx人」不確定字眼，化為「出生」、「成長」，甚至「籍貫xx」的敘述（若為資料出處限制），再據以判斷分類設定。--Seanetienne（留言） 2025年5月8日 (四) 16:29 (UTC)[回复]
关于例2和普世观点，如果在美国出生但在外国成长生活，不能放在“美国人”分类，可能违背普世观点？xx人与xx人物分类是否等价的问题。--YFdyh000（留言） 2025年5月9日 (五) 09:07 (UTC)[回复]
例2的话还要看具体情况，比如父母有台北人，说他是台北人也不是不可以。有些人经历比较复杂，在很多地方都住过，这个时候根据父母是哪里人来确定他是哪里人也是一种比较常见的做法。--侧耳·倾听 2025年5月9日 (五) 09:14 (UTC)[回复]
感謝@YFdyh000、@Whisper of the heart的提點，說明多元樣態真的有勞個案斟酌...。YFdyh000舉的情境，像是馬友友的案例（父母中國移民／出生於法國／主要成長於美國→美國人）。美國特別，是因為採取「屬地主義」公民籍，看到「在美國出生」就基本上確定是美國公民。至於是否等價，個人認為「xx人」跟「來自xx的人」（people from x）的差異，是在中文語境中，「xx人」相較帶有主觀認同色彩，這也就是這裡有點棘手的地方。--Seanetienne（留言） 2025年5月9日 (五) 14:54 (UTC)[回复]
@Sinsyuan：据方针WP:讨论發起位置“讨论结束后亦应让讨论原地存档，避免重复在多个页面存档后出现讨论分支。”，我移除了你添加的{{存档至|WT:生者傳記}}模板，也请之後不要再添加了。籍贯问题也远不止包括生者传记。若需留讨论记录可以向这些信息框的讨论页發送讨论通告来链接。 ——自由雨日🌧️❄️ 2025年5月8日 (四) 06:54 (UTC)[回复]

模板爆炸

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

分类:引用模板后大小超过限制的页面。有时候把{{NoteTA}}改为{{NoteTA-lite}}可以解决。--Kcx36（留言） 2025年5月4日 (日) 20:11 (UTC)[回复]
@Kcx36：改了改反送中运动，它的模板还是炸的。还是说放着不管等有人清理好？（400K字节还是太多了）--KurGenera(留言) 2025年5月5日 (一) 03:30 (UTC)[回复]
反修例太长了，我筛了一下主条目基本上没有什么模板可以替换了（除非把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)[回复]

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

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

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

Alzheimer's 臺灣用語

本主題或以下段落文字，在討論結束後應存檔至Talk:阿爾茨海默病、Module talk:CGroup/Medicine。

「阿茲海默症」才是「Alzheimer's disease」在臺灣的主流中文用語，以下5個資料庫（橫跨坊間、官方、學術）的搜尋結果分布顯而易見：

資料庫 阿茲海默症 阿茲海默氏症 阿滋海默症 阿滋海默氏症 阿茲海默病 阿茲海默氏病 阿滋海默病 阿滋海默氏病
自由時報 1,769 81 54 5 14 3 - 1
中時新聞網 530 23 4 - 10 - 1 -
康健雜誌 742 55 9 1 4 1 - -
衛生福利部 1,870 454 4 225 47 153 1 6
臺灣碩博士論文系統 1,463 323 99 42 50 14 4 2
註：衛福部全文檢索系統使用「關鍵字搜尋」結果（""）；論文系統勾選「論文名稱」、「關鍵詞」、「摘要」，查詢模式選「精準」

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

想請教一下大陸及香港方面對於此一疾病的正式稱呼及最通俗稱呼各是什麼？確定以後，可據此調整地區詞轉換。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月6日 (二) 05:45 (UTC)[回复]
大陆方面，术语在线、《ICD-11 精神、行为与神经发育障碍临床描述与诊断指南》、《精神病学》（第9版）等均称“阿尔茨海默病”。 ——自由雨日🌧️❄️ 2025年5月6日 (二) 05:56 (UTC)[回复]
香港的通俗稱呼是“阿茲海默症”，正式的話不太清楚。--惣流·明日香·蘭格雷不姓式波 2025年5月8日 (四) 07:25 (UTC)[回复]
台灣地區詞最佳設定值是誰，一目了然，某用戶還是堅持disease要翻成「病」、syndrome才能翻成「症」，非按此規則就是「錯誤」的，殊不知臺大醫院早就示範台灣人充足的理解力：「阿茲海默症是一種不可逆，進展性的腦部疾病。」以為一份掛在台灣臨床失智症學會網站的對照表具有絕對權威性（Special:Diff/84214853、Special:Diff/84214885），但同一份文件Alzheimer's作「阿茲海默氏病」而Parkinson's作「巴金森氏症」，況且從該學會的其他發布看來，「阿茲海默氏病」不盡然是他們的政策。
此問題也發生在Parkinson's那裡，屢次不聽勸阻（Special:Diff/84198874，Special:Diff/84202322，Special:Diff/84203456），而且不諱言瞧不起台灣的用語形式（Special:Diff/84202316）。如今，具體數據擺在眼前，共識狀態明確——大眾媒體壓倒性90%以上用的正如我所說；政府機關、學界也有過半使用特定形式，且90%以上者用「症」不用「病」。在Wikidata那裡的舉動不說，現在明確證據攤出來了，乾脆不演了，直接衝了（Special:Diff/87161376）。他的一意孤行，做了錯誤表述，邊緣化了90%的台灣讀者。像這樣，跟本不屑地區用詞實務者，沒有資格著手用語轉換，就此例而言，尤其是台灣的用語。--Seanetienne（留言） 2025年5月6日 (二) 15:28 (UTC)[回复]
如果可以，請給出一些適合用來註釋臺灣方面譯名的官方文件或醫學辭典（至少能對標大陸地區詞）。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月6日 (二) 20:40 (UTC)[回复]
Google上查到的有：2008年行政院衛生署主編的《實用醫學辭典》；國家教育研究院2015年出的《醫學名詞》，看來已經納入樂詞網了（醫學名詞中譯手冊- 醫事司）。Seanetienne（留言） 2025年5月7日 (三) 17:02 (UTC)[回复]
那就差港澳方面的通稱了。給了以後我有空就把條目改改。—— 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)[回复]

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

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

新聞局登記證號等純審查／分級編號可否納入資訊框？

以往中華民國行政院新聞局對其審查的書刊賦予編號——登記證號，此非國際標準書號（ISBN）或圖書分類法等可爲大衆索引的編碼；如今多國多地仍有影視以至唱片、遊戲等的純供審查或分級的編號，之於普羅大衆亦無索引作用。故有以下問題：

  1. 對於大衆，美中以外多國標準書號或圖書分類法編號似比任何審查／分級編號更具索引價值，是否比審查／分級編號更值得納入資訊框？
  2. 審查／分級的公開意見／結果是否比其編號更具百科價值？更值得納入條目？或應置於較其編號更顯眼的位置？
    • 如審查結果（例如（不）通過）的百科價值不低於其編號，{{电影信息框}}的「公映許可」／{{电视节目信息框}}的「发行许可」欄可否在列明可靠來源的前提下填寫為「有」、「無」或「撤銷」？「有」、「無」或「撤銷」是否比一串數碼更符合「许可」一詞的意指？
  3. 審查／分級編號是否愛好者資訊？可否納入資訊框？
    1. 如可，任何政治實體的審查／分級編號可否平等地納入資訊框？
      1. 如可，{{电影信息框}}的「公映許可」／{{电视节目信息框}}的「发行许可」欄可否填入中國大陸以外的「許可」情形，抑或另設參數？
        • 已知中國大陸的公映、電視節目、網絡視聽節目、音像製品分有不同審查系統及編碼字樣，即電影在中國大陸不獲公映許可而仍可通過網絡視聽節目或音像製品審查並合法發行；故在{{电影信息框}}可否增設「網絡視聽節目」、「音像製品」的「發行許可」欄目？
      2. 如可，已知新加坡、香港等豁免部分類別電影分級；可否對獲豁免電影的「許可」情形填入「豁免」等表述？
    2. 如可，已知臺灣等分級、中國大陸的審查均對同一電影的不同（語音／格式等）版本分別賦予編號；{{电影信息框}}的「公映許可」欄可否列出全部版本編號？抑或僅可列出首輪公映2D原聲最高分級版本的編號？
    3. 如可，已知申請中國大陸公映的電影在初審通過後即可取得許可證編號，但有許可證編號不意味通過終審或獲得公映許可證，則在中國大陸通過初審而不通過終審的電影在{{电影信息框}}的「公映許可」欄，如列明可靠來源，可否一併填寫「不獲公映許可」及其編號，或僅填寫其編號？

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

结构化数据首先考虑维基数据。如果有官方页面可查编号得到较多的进一步信息，可考虑以外链意义放在信息框，否则单纯编号不建议提供给读者，读者无法快速理解和运用。如果“无”“撤销”是不常见、通常会被条目正文介绍的，信息框写入千篇一律的“有”或者无额外信息的“无”可能意义不大？提供单纯索引号而无功用价值可能WP:RAWDATA？注明“情形”可能需要理解因果，比如相关内部链接。不同版本，我倾向维基数据及其优先级、修饰符功能。编号旁的状态，如果能统一写法规格，不反对加注。--YFdyh000（留言） 2025年5月6日 (二) 10:26 (UTC)[回复]
以較多需要當局審查或分級的電影爲例，美國、新加坡、臺灣、香港、中國大陸等結果均無網址單獨固定的網頁。單純編號的確意義不大。維基數據確是現有編號的理想歸宿。--— Gohan 2025年5月7日 (三) 08:46 (UTC)[回复]
(＋)支持写入维基数据内。--自由米花🌾🌼 2025年5月8日 (四) 13:03 (UTC)[回复]
据方针WP:讨论發起位置“讨论结束后亦应让讨论原地存档，避免重复在多个页面存档后出现讨论分支。”，移除{{存档至|Template talk:电影信息框|Template talk:电视节目信息框|Template talk:Infobox book}}模板。若需留讨论记录可以向这些信息框的讨论页發送讨论通告来链接。 ——自由雨日🌧️❄️ 2025年5月6日 (二) 11:39 (UTC)[回复]
明確標記討論關閉以後，理當可以存檔多處。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月9日 (五) 14:59 (UTC)[回复]
@Ericliu1912：然而如果讨论位置發起正确的话，在互助客栈發起讨论内容理论上并不涉及特别的条目等页面，如果要存档，估计大概率会是“硬凑相关页面”吧？这似乎没有必要。然后是，大部分互助客栈讨论均不会特意有人去标记讨论关闭，所以在关闭前就加模板的大概率最终结果就是以开放形式直接存档（这一句说明在确认关闭前默认不标存档位置的合理性）。其次，即便是关闭的情况下存档，衹要没有进入正式的“存档页”，通常仍然可以在关闭的框外留言（例如此例），这仍然会造成“在多个页面存档后出现讨论分支”的问题。最後，“存档至客栈”仅占一处存档空间，而“存档多处”则将同一讨论复制多份，这似乎同样没有必要。我的理解是存档的最大作用是可以让编者点击讨论页时知道“关于这个页面，曾经有过这一讨论”，而这未必需要通过复制所有内容的存档来实现，也可以通过{{讨论通告}}来实现（要再方便的话，等内容存档至互助客栈存档後，再在讨论通告下方留一条言给出至存档的链接，这样就更清楚了）。综上，存档有多种弊端且似乎难以完全解决，而存档的好处则可以通过其他方式（讨论通告）来实现。 ——自由雨日🌧️❄️ 2025年5月10日 (六) 10:10 (UTC)[回复]

是否加入球形地圖

英維國家信息中的地圖絕大部分國家的都是第一張爲球形地圖，之後纔是局部，中維是否應該仿照英維編寫。--Gdagys（留言） 2025年5月6日 (二) 14:04 (UTC)[回复]

關於徵求來源系列維護模板的字句修訂

這其實算是我在條目探討一則留言的後續。維基百科目前存在大量徵求來源維護模板，大多措辭如下：

維基百科所有的內容都應該可供查證。请协助補充可靠来源以改善这篇条目。无法查证的內容可能會因為異議提出而被移除。

——{{Unreferenced}}

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

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

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

——{{BLPsources}}

由此可見，這些模板都要求我們「補充來源」。這本是好事，但既然「可供查證是維基百科內容的門檻」，我們要做的不單是「補充」，更是「根據新來源重寫」；不是「用來源證明現有文字」，而是「將可靠來源的各個主要觀點都寫下來」。因此，我提議徵求來源維護模板和相關模板中的「補充來源」替換爲「根據新來源重寫」，例子如下：

維基百科所有的內容都應該可供查證。请协助根據可靠来源重寫本條目。无法查证的內容可能會因為異議提出而被移除。

——{{Unreferenced}}

请协助根據可靠来源重寫目前依賴第一手來源的內容以改善这篇条目。

——{{Onesource}}

请协助根據可靠来源重寫目前無法查證的內容以改善这篇条目。

——{{Refimprove}}

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

——{{BLPsources}}

以上，提請諸君討論。1F616EMO（喵留言～回覆請ping） 2025年5月8日 (四) 13:16 (UTC)[回复]

(＋)支持，之前完全没想到这一点，我觉得想法非常好。另外看到这一提案，我个人主要想到的理由倒没有“要求‘将可靠来源的各个主要观点都写下来”那么强（当然这绝对是最应该做的事），我想到的是：无来源内容大多是编者随手写的低质内容，本身就并非是来自于可靠来源，因而改善途径自然不应是“找可靠来源去生拼硬凑地来佐证原本就并非出自可靠来源的表述”，而是重写。 ——自由雨日🌧️❄️ 2025年5月8日 (四) 13:20 (UTC)[回复]
(！)意見 大部分是需要基于可靠来源证明并重写或改写完善，但有些表述确实只需补上有效来源即达标（如新闻报道），引导“重写”是非必要的。所以表述中性一些为好，如请基于可靠来源改善这篇条目、请补充可靠来源以改善这篇条目。
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)[回复]

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

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

添加上“计划通车时间”是一名匿名用户的贡献。
但是通过观察优良条目北京地铁中未来发展的章节，则发现实际上除了是今年确定开通的线路，其余的通车时间要不是没有来源，要不是计划赶不上变化。而再观察规模比广州地铁更大的上海地铁，则发现其对于线路规划及建设的通车时间的参考来源则更少。而再参考比广州地铁开通更早的天津地铁，其对于未来发展的参考来源中的描述，则更表现出“计划赶不上变化”。
其实现在城市轨道交通的建设已不是十几年前那般迅速，市政工程的计划赶不上变化是常常发生的，社会上有不少观点认为中国的大基建时代已经过去了，地铁的建设也被新的国家标准束缚。
回到广州地铁这方面说，2017年就说21号线会在当年开通[15]，2022年说11号线会在当年开通[16]，而这两条线都因各种原因推迟通车时间，但官方均未确认，仅仅是“预计”、“初定”等措辞。而对于今年开通的几条线路，官方的措辞[17]则没有用预计的词语。
因此，我更倾向于不单独加上“计划通车时间”这一列。如果通车时间已被官方确认，或有相关方的官方回复（如人民网的领导留言板、12345等），则可如该版本或该版本中在土建进度中加以备注。当然，需要一列备注栏以存放参考来源，无论是刚开始建设线路的环评报告等文件，还是确认通车时间的新闻。--Cygz（留言） 2025年5月8日 (四) 18:19 (UTC)[回复]
鄙人未参与相关条目修缮，但据我经验，城市轨道交通的“预计通车时间”大部分比较固定，但也存在变动的情况，建议以各工程环评文件内的通车时间为准，若后续有公告、问政回复等信息确定新的通车时间则以后者为准。--—远方传来风笛（Talk） 2025年5月9日 (五) 05:45 (UTC)[回复]
一般这种工程开工前后都有官方宣传，按照那个来就行，以后明确有新说法再改；规划线路还没开工的没有必要写。--Nanhuajiaren（留言） 2025年5月10日 (六) 10:21 (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)[回复]
既然教宗總共二百多位而已（且重複名號貌似僅八十出頭），不如先把能找到的譯名都找一找，尤其是兩岸四地教會文獻及政府官方資料，以處理各項單、多向轉換。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月10日 (六) 17:37 (UTC)[回复]

其他

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

本主題全部或部分段落文字，已移動至Wikipedia:管理操作覆核請求/存檔。执行者：Jimmy-bot（留言） 2025年5月10日 (六) 00:14 (UTC)。[回复]

提議將Mediawiki保護改名及更改圖標

本主題全部或部分段落文字，已移動至Wikipedia talk:保護。执行者：Jimmy-bot（留言） 2025年5月10日 (六) 00:14 (UTC)。[回复]

管理操作覆核請求：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)[回复]

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

截至本讨论发布时，根据一项在站外（主要是 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相比差得远。
— [18]

这样一句话，我觉得有点危言耸听，不能一个人随便吹牛说大话就能让整个社群人心惶惶吧。--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)[回复]

参考資料

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

两岸四地用词问题

本主題全部或部分段落文字，已移動至Wikipedia talk:格式手册/两岸四地用语。执行者：Jimmy-bot（留言） 2025年5月10日 (六) 00:14 (UTC)。[回复]

Sidebar问题

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

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

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

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

看到了並手動通過部分（）--千村狐兔（留言） 2025年5月8日 (四) 10:51 (UTC)[回复]
@Cdip150：好像之前是您在處理吧。。。問一下有沒有什麼頭緒。--（☎）dt 2025年5月9日 (五) 19:07 (UTC)[回复]

User:Rastinition繞過程序直接將列表重定向是否涉嫌擾亂？

見Rastinition於5月7日的編輯[19]，Rastinition僅因為華語劇台內存在一句不知真偽的「2019年1月1日起，本頻道不再播放首播劇集」就把所有「華語劇台電視劇集列表」重定向至華語劇台（變相刪除），被回退後，昨天又故意在被重定向的列表內添加Template:收录标准重定向模板[20]，然而這些列表根本就沒有被提報至Wikipedia:收錄標準/提報的記錄，更沒有因此被提刪，擅自繞過程序重定向條目的行為已經與末期的LTA:SiuMai如出一轍，懇請管理員關注。--218.166.20.53（留言） 2025年5月9日 (五) 06:07 (UTC)[回复]

请先与用户交流。Python6345（查论编） 2025年5月9日 (五) 12:55 (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)[回复]

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

有不少多次侵权的用户被提报至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)[回复]

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

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

现条文

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

修改后条文

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

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

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

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

原状态

任何人都能编辑

修改后状态

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

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

能否告知大家，上案在做什麼？為什麼？能否按User:Antigng#个人意见整理你的意見。另一項也同。--Ghren🐦🕛 2025年5月10日 (六) 16:48 (UTC)[回复]
检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia:互助客栈_(全部)&oldid=63126193”