跳转到内容

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

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

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

按此刷新頁面。

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

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

查看全部討論

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

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

消息

Sub-referencing: User testing

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

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

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

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

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

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

Wikidata weekly summary #677

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

Discussions

Events

Press, articles, blog posts, videos

Tool of the week

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

Other Noteworthy Stuff

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

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

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

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

Weekly Tasks

對《通用行為準則執行規範及其協調委員會章程》的修訂投票

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

通用行為準則執行規範協調委員會(U4C)是一個全域性的組織，致力於公平、一致地實施UCoC。本年度審查由U4C規劃和實施。如需更多資訊和 U4C 的責任，您可以檢閱U4C的章程。

請酌情以您的語言與您的社群成員分享此訊息，以便他們也能參與。

與U4C共同合作 --

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

The Signpost: 1 May 2025

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

Wikidata weekly summary #678

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

Discussions

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

Events

Press, articles, blog posts, videos

Tool of the week

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

Other Noteworthy Stuff

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know ?

Development

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

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

Weekly Tasks


方針

再议明确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年地震}}（标题为「2025年主要地震」）似乎两样都不符合。我猜没有可靠来源会讲「缅甸地震是2025年主要地震」，现在也没有人写说「本导航模板可能不完整」。但是我不是很能接受它是违反NOR的。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年5月6日 (二) 10:23 (UTC)[回复]
快点提吧，别墨迹了，Zhenqilin两面三刀的态度您也不是没看见，当社群一致认为其违规事实时，ta非但拒不接受，却反而指责社群有意“滑坡论证”针对ta，赤裸裸的IDHTta却不知道是啥。--Liuxinyu970226（留言） 2025年5月6日 (二) 10:30 (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)[回复]

公共交通路線條目指引

路線條目目前似乎還很不完善，需再仔細討論。--🚊　鐵路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)[回复]

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

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

近年来，以大型语言模型（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)[回复]

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

本主題或以下段落文字，在討論結束後應存檔至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)[回复]

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

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

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

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

WP:翻译有言：

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

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

提議提升巡查員的門檻

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

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

巡查員

現行條文

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

提議條文

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

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

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

提議條文

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

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

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

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

我想知道的是为什么英文维基百科的自动确认用户门槛低，而中文维基百科的自动确认用户门槛很高，是不是因为有编辑战所以才提高的？--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:新條目推薦（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) 👍1[回复]
感謝您的回應，我理解您對「條目連入」重要性的質疑，也同意不是每一個條目都需要有大量連入才會被閱讀或維護良好。
不過這裡提出的觀點，並非要將「條目可見度不高＝危害」劃上等號，而是想探討在 DYK 這樣一個「曝光機會高」、「條目仍在早期發展階段」的情境下，是否能善用這個時機，促進條目更快進入條目網絡，讓讀者不只能從首頁點進來，也能在主題相關條目中自然找到它。
當然，有些冷門主題條目本身就很難建立內部連結，那自然不會強求。而我希望討論的是：在可以的情況下，是否能鼓勵建立這種串聯，而不是將其完全忽略。
至於維護與刪除問題，我同意不是靠點閱數來決定，但條目若無上下文關聯、無人接續擴充或修訂，常常會面臨「維護者孤軍奮戰」的窘境。這是我觀察到的狀況，僅供大家參考。--David Jackson(留言) 2025年5月6日 (二) 02:11 (UTC)[回复]
我好几年前一直在追踪每一篇参与DYK评选的条目的链入情况，近一两年因为个人精力有限没再追踪了。不过我就算是发现有DYKC条目缺乏链入页面，我做的第一件事情也是尽量自己去动手在别的条目当中添加链接至该条目的链接，除非我自己找不到合适的地方去添加条目链接，否则我一般不会在评选当中提出相关意见，本来这就不是DYK条目的硬性要求，只是能够避免孤立状态当然更好。--💊✖️2️⃣3️⃣（留言） 2025年5月6日 (二) 01:02 (UTC)[回复]
追蹤連入狀況是件很累人的事情(吃力不討好)，但就是希望集眾人之力或憑一己之力誕生的DYK條目，它的能見度能再提高。我一向認為每個條目都有它誕生的意義，能入選DYK更彰顯它的獨特之處，如果能在評選規則內加入善意提醒，請編者盡量在相關條目內增加引用與連結，這樣就可以避免產生孤立狀態。當然目前也只是先討論交流，並沒有說一定要執行。是否納入提醒內容，仍需建立共識後再作後續調整。--David Jackson(留言) 2025年5月6日 (二) 02:08 (UTC)[回复]
R-5 (导弹)那个可以通过{{俄罗斯和苏联导弹}}汇链入，已修正，连不上是因为导航模板对应链接名不对应。至于缺少链入的问题，参见Wikipedia:孤立页面，保障条目的链入度一定程度是有必要的。另外创建低链入的条目很可能是与其主要关联的条目还没有创建，或者没意识到可以通过已有的条目进行链入。我自己的例子就是避难所 (波特·鲁滨逊和麦狄恩歌曲)（2016年10月），这个条目就是看到相关的MV才考虑开题弄的，主要关联条目波特·羅賓森当时还没创建（题材不太熟，而且内容颇多而没准备翻译），可以关联并已存在的条目A-1 Pictures也是2016年11月才链出过去。现时一部分链入是依靠{{A-1 Pictures}}带入的。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月6日 (二) 05:11 (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 會報，--内์์์์์์์存๎๎๎๎溢出์์์์์์์的๎๎๎๎猫瞄?喵! 2025年4月21日 (一) 01:37 (UTC)[回复]
模組討論:Lang/data/is latn data#編輯請求2025-04-22去掉了一些內容，能修，但是這種做法不太好，最好修改或去除這個拉丁字母檢測功能。——枰（留言） 2025年4月22日 (二) 05:34 (UTC)[回复]
@優枰：更新之后会导致新的问题，例如2030年亚洲运动会，里面的转写因为有个‘会报错。我觉得像{{lang|zh-hant|，}}这种用法有点问题，因为lang模板是为了标明某种语言的文本，而标点符号不是专属于某个语言的，这样用有些不妥。--Vozhuowhisper 2025年5月3日 (六) 16:42 (UTC)[回复]
沒注意到這個問題，抱歉，我在編輯請求那裏請求恢復了，然後新建了{{lang old}}臨時用在此條目。關於{{lang|zh-hant|，}}，我覺得現有用法有些道理，畢竟瀏覽器可以藉此以不同方式顯示標點符號。然後這個問題，最好的方法可能是拆開Latn和Zyyy，也許應該回報到英文維基百科。——枰（留言） 2025年5月3日 (六) 19:50 (UTC)[回复]
模板{{Vi-nom}}也有類似問題。--Kethyga（留言） 2025年4月24日 (四) 11:29 (UTC)[回复]
英維直接使用<span lang="vi-Hani" class="vi-nom" {{{attr|}}}>{{{1}}}</span>进行标记。--Kethyga（留言） 2025年4月24日 (四) 11:32 (UTC)[回复]
ToolsRedirect的輔助選項「ToolsRedirect選項：取得生物學學名為重新導向候選」疑似因為這個更新失效了，我剛剛新建頁面發現他完全抓不到lang-xm下的學名（更新之前我常用這功能，當時只要有學名：{{Sname}}時是可以運作的）。--WiTo🐤💬 2025年4月23日 (三) 06:16 (UTC)[回复]
@WiTo7946 似乎因为html源码中多了<span lang="la"--Kethyga（留言） 2025年4月29日 (二) 09:02 (UTC)[回复]
Module talk:Lang/data#編輯請求 2025-04-27需要管理員盡快處理。Sanmosa 新朝雅政 2025年4月27日 (日) 02:14 (UTC)[回复]
巴勒斯坦解放組織首句：「Lang-xx：拉丁字母轉寫第 99 個字元「嵌」不是拉丁字母。」，但直接把該lang-ar呼叫過來這裡又正常了的樣子。「阿拉伯语：منظمة التحرير الفلسطينية，羅馬化：Munaẓẓamat at-Taḥrīr al-Filasṭīniyyahⓘ」--WiTo🐤💬 2025年5月5日 (一) 10:22 (UTC)[回复]
错误提示应该是{{Audio}}模板有关，lang模板估计只检测主命名空间（条目空间），在个人沙盒测试也未报错。--Kethyga（留言） 2025年5月5日 (一) 10:55 (UTC)[回复]
若直接展開看起來就沒問題了，如果是Audio的問題的話，那可能是lang抓到Audio模板內的{{#ifeq:{{NAMESPACE}}|{{ns:0}}|[[Category:嵌入hAudio微格式的條目]]}}了。--WiTo🐤💬 2025年5月6日 (二) 05:18 (UTC)[回复]

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

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

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

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

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

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

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

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

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

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

建議用{{efn}}和{{notelist}}。--SuperGrey (留言) 2025年4月20日 (日) 14:41 (UTC)[回复]
興奮地試了一下，遺憾的是，除了refnest，全部都有同樣問題 囧rz……--惣流·明日香·蘭格雷不姓式波 2025年4月21日 (一) 04:31 (UTC)[回复]
这个缺陷目前是修不好还是怎么说？不能回退吗？--【拒绝编辑霸凌，拒绝拉扯性讨论，谢绝拉票，谢绝提名，谢绝豢养人肉傀儡】（有建议可以留言） 2025年5月4日 (日) 16:40 (UTC)[回复]

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

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

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

完成：
經檢查，Vector 2022介面已能正常運行Twinkle關閉AFD的功能，故該功能已重新在Vector 2022介面啓用。Sanmosa 新朝雅政 2025年4月30日 (三) 01:49 (UTC)[回复]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

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

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

@SunAfterRain：關閉使用者提問也不是這樣隨便的吧？還是說你知道Twinkle內部的維護細節？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月21日 (一) 11:11 (UTC)[回复]
@Ericliu1912：[2]，理由是Vector-2022的HTML原始碼一直變來變去造成維護困難所以暫時不支援（順帶一提，東八區的下午我有在AC群貼過這段話）
另外我認為既然這位都沒有要好好認真提問了，那很隨便關閉也是理所當然的--SunAfterRain 2025年4月21日 (一) 13:46 (UTC)[回复]
意思就是Vector 2022现在还不是稳定版？--熊猫火狗（留言） 2025年4月21日 (一) 13:56 (UTC)[回复]
@Ericliu1912、SunAfterRain：（其實我也有一個相關的問題要問，所以這樣直接關掉討論串確實不太妥當）我覺得我就順便問這個問題吧：有沒有辦法可以在Vector 2022介面下強制運行Twinkle關閉AFD的功能？就算可能有bug我也不介意，但現在關AFD就要不斷來回切換介面對我來説比較麻煩。Sanmosa 新朝雅政 2025年4月28日 (一) 11:44 (UTC) +11[回复]
你問錯人了，你應該問@Xiplus、Hamish--SunAfterRain 2025年4月28日 (一) 12:07 (UTC)[回复]
我不懂技術，別問我XD —— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月28日 (一) 12:19 (UTC)[回复]
目前Twinkle的關閉AFD功能部分暫時還沒有加入vector2022的適配，強制運行現有的代碼也沒有辦法實現，“關閉討論”的程式入口都不會顯示。--Hamish T 2025年4月28日 (一) 19:04 (UTC)[回复]
@Hamish：“‘關閉討論’的程式入口都不會顯示”是指無法顯示按鈕嗎？但我是能看到按鈕的。Sanmosa 新朝雅政 2025年4月29日 (二) 00:55 (UTC)[回复]
我是指，關閉討論點開以後，程序入口是不會顯示任何東西的，只會提示用不了，我可能稍後測試一下當前的2022外觀直接運行現有的代碼會不會出大問題，沒有大問題的話，會考慮加入一個option打開vector2022上這個功能。--Hamish T 2025年4月29日 (二) 01:26 (UTC)[回复]
“關閉討論點開以後，程序入口是不會顯示任何東西的，只會提示用不了”確實如此。如果能開這個option的話就再好不過了，我記得一開始Vector 2022介面下還能運行Twinkle關閉AFD的功能的時候，這功能基本上都是在正常運作的（至少就我自己而言）。Sanmosa 新朝雅政 2025年4月29日 (二) 01:53 (UTC)[回复]
剛去翻了一下Twinkle和Vector2022的代碼提交記錄，當時2022的HTML標籤有問題，這個問題會導致twinkle根本無法正常顯示“關閉討論”按鈕，也無法正常關閉討論，但現在看應該是修復了，吧。等待技術帝意見。--Hamish T 2025年4月29日 (二) 02:19 (UTC)[回复]
@SunAfterRain和@Hamish說的是對的，已重新在vector-2022上啟用。--Xiplus#Talk 2025年4月29日 (二) 11:34 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

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

應該是因為使用Template:Querylink的關係，被提合併請求的條目的链入页面並不包含合併請求頁，且未被執行的合併請求不如Wikipedia:存廢覆核般會在討論頁留下討論的連結，導致編者無法簡易查看過往的合併討論。--惣流·明日香·蘭格雷不姓式波 2025年4月23日 (三) 04:20 (UTC)[回复]

@Sohryu Asuka Langley Not Shikinami，合併討論需要在被合併的條目中的討論頁討論，合併請求只是一個媒介提供不知道怎麼合併或是不確定怎麼合併提交的地方。-- Willy1018（留言） 2025年4月28日 (一) 18:10 (UTC)[回复]
但顯然WP:合併請求中亦有討論，或至少對於“未被執行的合併請求”會有不執行的原因，現時情況是一存檔就很難快速找到（需人手搜索，前提是知道曾提至WP:合併請求）。--惣流·明日香·蘭格雷不姓式波 2025年4月29日 (二) 01:12 (UTC)[回复]

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

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

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

附：追踪分类列表

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

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

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

原标题：繁简重定向的负面问题及解决方案（“废除繁简重定向？使用机器人维护该负面问题？”二选一）。修改理由：改变讨论主题焦点。修改者：自由雨日🌧️❄️ 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)[回复]
您怎麼判斷對方是不是「為了『刷編輯數』而創建」呢？如果我每寫一個新條目就創建幾個（比如說，因為有了后藤一里這個條目，就建立後藤一里、後藤獨、后藤独、小孤獨、小孤独），這算是「刷編輯數」嗎？還是說應當限制呢？--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)[回复]

有關Template:Jct模板問題

本主題或以下段落文字，在討論結束後應存檔至Template talk:Jct、Module talk:Road data/strings/TWN。

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

我在雲嘉南#高速公路、中山高速公路交流道列表發現使用{{Jct}}會出現 Module:Jct第187行Lua錯誤：bad argument #2 to 'format' (string expected, got table) 的錯誤，再深入發現使用Module:Road_data/strings/TWN下的國道、國道全名、省道快速道路全名都會出現完全相同的錯誤：


測試情況
案例 程式碼 預期顯示效果 實際情況
國道1號（中山高速公路，使用簡名） {{Jct|country=TWN|NH|1}} 國道一號 國道一號
中山高速公路（使用全名） {{Jct|country=TWN|NH-ALL|1}} 中山高速公路 中山高速公路
台68線（使用簡名） {{Jct|country=TWN|PH|68}} 台68線 台68線
南寮竹東線（使用全名） {{Jct|country=TWN|PH-ALL|68}} 南寮竹東線 南寮竹東線

我不知道如何修正錯誤？ --—— Matt Zhuang表示有事按「此」留言 2025年4月25日 (五) 18:03 (UTC)[回复]

將Module:Road data/parser回退到先前版本可以臨時解決，徹底解決的辦法應該需要重構Module:Road data/strings/TWN--Hamish T 2025年4月27日 (日) 00:28 (UTC)[回复]
剛认真去看了下parser，其实应该加个default就好了。有使用者經已修復。--Hamish T 2025年4月27日 (日) 14:18 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

建議簡化提刪的步驟

現在如果要進行提刪，需要分別在條目掛上提刪模板、在存廢討論提交新項，以及通知條目創建人，步驟複雜繁鎖。能否對整個提刪發起流程進行簡化，比如在存廢討論提交後，機器人即時自動在條目以及條目創建者討論頁面掛上模板以及通知？這樣可以節省不少的麻煩。--owennson（聊天室、獎座櫃） 2025年4月25日 (五) 18:44 (UTC)[回复]

请求批量移动Template:PRC admin中的页面

广州市从化区的统计代码从44/01/84更改为44/01/17（存档），导致从化区下全部村庄的模板页面都需要移动。本人手动移动了乡镇级页面至44/01/17，但村庄条目繁多，请求有批量移动页面权限者协助移动，感谢。--自由米花🌾🌼 2025年4月26日 (六) 13:00 (UTC)[回复]

PRC admin系列模板屬於遠古模板，欠缺維護，我早前嘗試過重構，但一直沒能弄好。既然如此，我會在未來慢慢著手重新嘗試。--Hamish T 2025年4月26日 (六) 13:38 (UTC) ♥1[回复]
村级页面不影响条目内容，不用移动。--Kcx36（留言） 2025年4月26日 (六) 15:44 (UTC)[回复]
其實應該是會影響的，那時批量建立的鎮級條目頁面會顯示下轄地區。--Hamish T 2025年4月27日 (日) 01:35 (UTC)[回复]
正解。我在建立村庄条目后需要到维基数据关联，发现镇级条目页面需要把44/01/84改成44/01/17，才能显示村级条目的链接。（如：这个编辑）--自由米花🌾🌼 2025年4月27日 (日) 02:41 (UTC)[回复]
{{PRC admin/children}}调用Module:PRC_admin取维基数据d:Property:P150，不涉及村级PRC admin子页面。Special:PermaLink/85127198也能显示下级行政区划。--Kcx36（留言） 2025年4月27日 (日) 10:15 (UTC)[回复]
需要移动的是镇本级的PRC admin/data和PRC admin/list页面，然后需要更新条目各模板中的行政区划代码。--Kcx36（留言） 2025年4月27日 (日) 10:21 (UTC)[回复]
我表達錯誤了，不重要，這遠古級模板要大改只能慢慢弄了。--Hamish T 2025年4月27日 (日) 11:43 (UTC)[回复]

Android應用程式 編輯互助客棧 RFC bug

使用Android應用程式編輯 /方針、/技術、/條目探討、/其他 時，點選章節旁的編輯鍵會跳到“點選章節的下一章”的編輯頁面，例如在special:diff/87017721，我想編輯“#繁簡重定向的負面問題...”一章，但正常點下去只能編輯下一章“#有關Template:Jct模板問題”，結果我要點“#{{Infobox road}}相关追踪分类建立”才能跳到我想編輯的地方。
鑒於 /消息 和 /求助沒有這個問題，我懷疑跟頁面頂部的RFC清單（#正在廣泛徵求意見的議題）有關。手頭上沒有蘋果產品測試不了。--惣流·明日香·蘭格雷不姓式波 2025年4月28日 (一) 07:13 (UTC)[回复]

Android應用程式 互助客棧 話題目錄 bug

用Android應用程式瀏覽互助客棧的六大分頁時，目錄内的標題如含有命名空間連結時（如WP:、Category:等），會跳轉失敗。假設章節的完整連結為“zh.wikipedia.org/wiki/Wikipedia:互助客栈/技术#Wikipedia:xxx”，程式會嘗試訪問“zh.wikipedia.org/Wikipedia:xxx"（即砍了“wiki/Wikipedia:互助客栈/技术#”）並失敗，繼而用瀏覽器打開，不過依然會page not found。
舉例一些會觸發問題的章節有/方针#再议明确WP:NOR方针对模板的适用性、/方针#提议修正Wikipedia:界面管理员、/技术#Category:非条目级XXX条目错误。
Wikipedia:互助客栈底部的目錄沒有這個問題。--惣流·明日香·蘭格雷不姓式波 2025年4月28日 (一) 07:33 (UTC)[回复]

新脚注风格：用户测试

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

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

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

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

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

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

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

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

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

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

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

自行解决了喵(≧^.^≦)~--KurGenera(留言) 2025年4月28日 (一) 16:47 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

2025年第18期技術新聞

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

近況更新 - 面向編輯者

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

  • 維基媒體設計系統——Codex預定於2025年4月29日發布下一個主要版本。技術編輯者將能於2025年5月5日當週使用該版本。本次更新將包含一些不向下相容的重大變更和輕微的視覺變更。該頁面記載了處理重大變更和視覺變更的說明。發布前的測試在T386298中回報，發布後的問題則在T392379和T392390中追蹤。
  • Wiki Replicas的使用者將會注意到ipblocks、ipblocks_ipindex和ipblocks_compat這幾個資料庫檢視表現已棄用。使用者可以查詢block和block_target這二個新的檢視表，這些新檢視表會反映生產資料庫中的新表格。棄用的檢視表將於2025年6月從Wiki Replicas中完全移除。
  • 經常項目 本週稍晚代码更新細節： MediaWiki

深入了解

會議與活動

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

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

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

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

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

看了一下{{Jpn}}的改法，改用{{langx}}仅仅是为了显示“日语”两个字。日语原文、假名以及／、〔、〕符号全在一个<span lang="ja">里面，可能会影响屏幕阅读器的使用。|link=参数的两种情况代码竟然是分开写的，维护困难。--Kcx36（留言） 2025年4月29日 (二) 12:31 (UTC)[回复]
新的{{lang}}模板无法自定义提示文字。日语汉字、平假名、片假名、罗马字、旧字体全都只显示「日语文本」，不如以前的清楚标明所使用的文字好。可能还得改进{{lang}}、module:lang。--Kethyga（留言） 2025年4月30日 (三) 04:23 (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)[回复]

模板:分类重定向

本主題全部或部分段落文字，已移動至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)[回复]
其SettingsUI似乎有问题，无法保存。--YFdyh000（留言） 2025年5月5日 (一) 14:09 (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)[回复]

2025年第19期技術新聞

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

本週要聞

近況更新 - 面向編輯者

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

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

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

求助

动物物种中文名称可靠来源？以及【南极中爪鱿】这个名称？

本主題全部或部分段落文字，已移動至Talk:哈氏中爪鱿。执行者：Jimmy-bot（留言） 2025年5月5日 (一) 16: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)[回复]

請求協助上傳檔案 2025-04-25 10:54

我想要上傳的圖片來源是輕軌規劃圖，想要使用在澳門輕軌的<資訊框/未來發展路線段落>。 --Zctptuc（留言） 2025年4月25日 (五) 10:54 (UTC)[回复]

請問是你畫的還是你從網路找的？是你畫的請上傳至共享資源，是你從網路找的則請給出網址。可以的話，建議自己畫，著作權比較不會有問題。--Saimmx（留言） 2025年4月28日 (一) 18:31 (UTC)[回复]

元素周期律的跨语言链接

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

看起來應該要在維基數據整併 週期性趨勢 (Q10889792) 和 週期性趨勢 (Q2622089)--—— Matt Zhuang表示有事按「此」留言 2025年4月27日 (日) 18:47 (UTC)[回复]
还有就是周期性规律这个条目用大陆简体是没法搜到的，是不是转换上有点问题。--Yankees from Canada 🪶 2025年4月28日 (一) 04:51 (UTC)[回复]
已于wikidata合并。--伞木 霙留言 2025年4月29日 (二) 06:06 (UTC)[回复]

請求協助上傳檔案 2025-04-27 10:35

我想要上傳的圖片來源是<https://drive.google.com/file/d/1nUHhrVnlqUN2Ca3f2tZ8M66fqnSUto4O/view>，想要使用在世新廣播電臺的<電臺圖片檔案>。 --N.7.1214（留言） 2025年4月27日 (日) 10:35 (UTC)[回复]

完成--Saimmx（留言） 2025年4月28日 (一) 02:45 (UTC)[回复]

請求創建頁面

我想將對黑種人的稱呼#nigger搬到nigger，但黑名單攔住了。--惣流·明日香·蘭格雷不姓式波 2025年4月29日 (二) 12:22 (UTC)[回复]

可能先等一下Wikipedia:頁面存廢討論/記錄/2025/04/29#對黑種人的稱呼的結果。--惣流·明日香·蘭格雷不姓式波 2025年4月29日 (二) 15:45 (UTC)[回复]

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

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

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

党卫队和親衛隊

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

举例：

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

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

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

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

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

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

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

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

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

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

我想要上傳的圖片來源是https://mp.weixin.qq.com/s/dlOsUYvj4TGS5wDrGraBRQ，想要使用在請提供條目名稱https://zh.wikipedia.org/wiki/周集中的infobox person。

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

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


條目探討

参考資料

誤用Wikipedia:持续出没的破坏者/User:Qqqyyy惡作劇內容的書籍

本主題全部或部分段落文字，已移動至Wikipedia talk:持续出没的破坏者/User:Qqqyyy。执行者：Jimmy-bot（留言） 2025年5月5日 (一) 16:14 (UTC)。[回复]

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

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

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

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

关于设立残疾人奥林匹克运动会专题及举办残奥编辑松的建议

本主題全部或部分段落文字，已移動至Talk:残疾人奥林匹克运动会、WikiProject talk:奥运会。执行者：Jimmy-bot（留言） 2025年5月6日 (二) 08:14 (UTC)。[回复]

「丁先皇」的本名說法

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

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

「Đinh Bộ Lĩnh」（丁部領）是《大越史記全書》跟《欽定越史通鑑綱目》的官方說法；「Đinh Hoàn」（丁桓）是陳仲金的《越南史略》著作說法；「Đinh Hoàn」（丁環）跟「Đinh Hoàng」（丁璜）是潘繼炳的《南海異人列傳》著作說法；「Đinh Bái Đính」（丁沛嵿）是越南民間傳說其父丁公著跟其母譚氏在華閭某地的「沛嵿山」（現代沛嵿寺的所在地）所生，因地名而命名的。--羅宋王（留言） 2025年4月21日 (一) 08:21 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

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

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

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

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

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

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

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

本議題因收錄標準而起，諸君也大多圍繞收錄標準討論存廢，但各位必須意識到收錄標準的背後是可供查證。可供查證是你站三大核心內容方針之一，若是無法堅守，就變成維基學院了，你站就塌了，還不如去元維基申請關站，和學院合併一下。絕大多數ACG角色列表（無論是獨立的還是嵌入的）甚至其他影視劇集列表都沒有列明來源，甚至包含原創研究，使得有關內容無法查證。這樣的弊端上面已經說過了，我們的讀者可不會自己突然懂得分辨是非，把垃圾撒他們一臉他們還感恩戴德如獲至寶。所以諸君要是看見沒有來源的東西，請大膽的、用力的刪，不用怕條目變成小小作品，因爲會變成這樣的條目值得刪後重建伺候。我們必須確立一個事實，即「無來源就得刪」，停止以「耗時太久」、「歷史原因」詭辯、當縮頭烏龜。1F616EMO（喵留言～回覆請ping） 2025年4月27日 (日) 09:53 (UTC)[回复]

甚至這也不用去「確立」：要是讓若干理性自然人去判斷「無來源可以保留否」，一定一致通過對無來源條目的大屠殺。吉米·威爾士如是說：

这一点我怎麼強調都不過分。若干編者似乎有個糟糕的傾向，將臆測性的『我自某處聽聞』的假偽資料加上『來源請求』標記。错了，这些东西应该被積極地移除，除非可以为它注明来源。這點適用於所有資料，特別是在世人物的负面资料。

——吉米·威爾士，“零資訊勝過錯誤或不實的資訊”
--1F616EMO（喵留言～回覆請ping） 2025年4月27日 (日) 10:00 (UTC)[回复]
諸君以收錄標準判斷列表去留的做法是不可取的。注意收錄標準的用詞：

如果一個主題得到了可靠來源的有效介紹，並且這些來源獨立於主題實體，則可假定該主題或符合獨立條目的收錄標準。

因此，收錄標準不是擋箭牌，不構成在條目完全不符合可供查證以及非原創研究方針的情況下保留的理由。要是某條目中有足夠的可靠來源，就自動符合WP:GNG，反之就算符合收錄標準，也不符合可供查證。--1F616EMO（喵留言～回覆請ping） 2025年4月27日 (日) 10:21 (UTC)[回复]
对呀，这里Category:缺少来源的条目可是有不少符合你想删除的缺少来源的条目，快上啊。有没想过为什么缺少来源也不一定是可被提删的理由，旧账不可能靠这样大手大脚就能解决的。不能单单靠法条主义去这样对待的。这类条目如果考虑来源的话，可以引用一手来源（作品本身）来解决，当然要对描述的话，需要仔细阅读来源来对应，编辑实在无法逐一核对来源详细的话，也可以靠单纯列出纯书籍来源而不用句子脚注。至于是否“原创研究”的话，连来源都没做审阅的话，怎么判断描述是符合还是不合来源？如果能核实来源，确定描述不符的话，可以自行删除语句并附编辑摘要，一般其他编辑会善意认同（除非硬杠的话，自行讨论决定）。对于部分涉及真实社会的人事需要严格遵循提供来源，我认同这很必要，但至于其他内容，乃至这类作品内元素的描述的来源情况，我认为应该需要但现实上有难度，尤其涉及建站初期十来年积累下来这批东西，问就是那些老编辑就是没有养成这种良好习惯，不及一些新人这么血气方刚，比廉署还刚。如果要处理这些老条目的问题，逐点提出并改善的话，或者可以接受；但这样大批量的大刀阔斧，我认为会超出相关编辑和社群的处理能力，纯属添乱。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月2日 (五) 10:57 (UTC)[回复]
「添加或恢復內容的編輯者應承擔舉證的責任」，路過的巡查者沒有義務去舉證。因此缺少來源的內容絕對不用小心查證，反之更應該勇敢刪除，最好通知添加該內容的的編者（在此G11一下WikiBlame，對於尋找句子原作者十分有用），達成有效的溝通。「建站初期十來年積累下來」導致積壓嚴重是確實存在的問題，但這並不妨礙有人路過看到了並意識到這內容不符合可供查證而去移除，更不是保留的藉口。只是你維對此事不怎麼積極，也因此沒有處理先例，我也只好暫且蝸居新條目巡查和最近更改巡查，免得被一大堆人用收錄標準保留糊一臉還被管理員忽略可供查證這一最大共識決定保留，費力不討好。--1F616EMO（喵留言～回覆請ping） 2025年5月2日 (五) 14:00 (UTC)[回复]
補充一下爲什麼我會認爲「可供查證是最大共識」：每一個維基媒體基金會的專案都會有其成立宗旨，這是將該專案和其他專案乃至第三方方針區分開的重要元素。對於維基百科而言，「成立宗旨」是共構百科全書，並通過落實三大內容方針管轄內容。這些成立宗旨不可以由社羣共識改變——試想有人去維基學院說「不如我們改爲什麼事都找來源說事情」，就算社羣糊里糊塗通過了，基金會也一定不會允許這修訂發生，因爲這樣一來，維基學院就不再是維基學院了。--1F616EMO（喵留言～回覆請ping） 2025年5月2日 (五) 16:21 (UTC)[回复]
可是有时候我不明白某些人，明明有些条目有足够的可靠来源和第三方来源，居然还提删。--Whq19911224（留言） 2025年5月4日 (日) 02:14 (UTC)[回复]
请问此例如何能够使其满足收录标准？？ ——自由雨日🌧️❄️ 2025年5月5日 (一) 02:27 (UTC)[回复]
虽然我也认同编辑要善始善终，不过涉及到条目内容的一些问题，更多看重的是结果，最理想的结果是条目内容完整性和可供查证两者都要，而这就要靠更好的手段来实现，有些地方本来靠改善优化就能解决，却非要用一刀切删除的手段，这不是大家愿意看到的。处理以前编者遗留下来的问题诚然不是我们的义务，但不代表为了纠结所谓义务的问题就要放弃达成更好的结果。--💊✖️2️⃣3️⃣（留言） 2025年5月5日 (一) 01:24 (UTC)[回复]
（編輯衝突，正在回覆修訂版本87141433上的留言）我想表達的正是可供查證性凌駕於完整性，或者說，如果沒有來源，我們不能作什麼。既然有可供查證這一核心內容方針存在（其超然性已經在上面敘述，見此，不再重複），我們寫條目的資料來源就只限於可靠來源（只有極少數例外，請看方針指引），任何其他內容都屬於原創研究，該殺、該打、該移除。既有此一限制，「條目內容是否完整」的擔憂就不存在——因爲我們作爲編者，「根本不知道」來源外的信息的存在。君所言「這不是大家願意看到的」只是社羣扭曲的結果，是社羣對待無法查證內容不作爲的結果，而非維基百科的初衷。參與維基百科本身就設有限制，要是行事方式不符合維基百科的宗旨，就該離開。--1F616EMO（喵留言～回覆請ping） 2025年5月5日 (一) 02:01 (UTC)[回复]
（回覆當前版本留言）「更好的結果」是什麼？如果是指「追求條目完整性」，見上。--1F616EMO（喵留言～回覆請ping） 2025年5月5日 (一) 02:02 (UTC)[回复]
另外我沒有糾結義務問題。維基百科不強迫任何人參與，所以也沒必要談「義務」什麼的，看見就處理，心累了也不要緊。至於「是不是我們要做的事」，我上面已經說的很清楚了，巡查路過愛做就做，沒人強迫，也沒人說不可以。--1F616EMO（喵留言～回覆請ping） 2025年5月5日 (一) 02:11 (UTC)[回复]
如果您認爲「讀者不會想看一條不完整的條目」：即使是讀者，也要尊重維基百科的規則。維基百科不是愛好者內容網站等核心內容方針的實踐已經說明維基百科並不服務所有讀者，而只服務認真地當維基百科是百科全書的人。作爲一本百科全書，最重要的就是內容的可靠性——傳統百科全書使用同行評審或其他評審程序達成，維基百科則選擇了向外查證，共同點是質高於量。要是讀者不認同這些原則，大可去其他地方，Fandom上就有不少愛好者內容維基，還滿好看，內容豐富完整，要不閣下也去貢獻一下？--1F616EMO（喵留言～回覆請ping） 2025年5月5日 (一) 02:25 (UTC)[回复]
那只能说贵兄台你，站着说话不要痛，本项目老问题一摞摞，就喜欢抓软柿子捏的，引经据典一道道的，抱怨和扔破烂是最容易的，花时间去修复是最麻烦的。如果按照贵兄台这样严格要求的话，前面说了Category:缺少来源的条目都是“铁定有问题”的条目，尽管提删，保证符合道义，没人能阻拦的，作品元素列表至少有对应作品条目可以归并，这些“没来源”的单独事物条目那就难说了，如果贵兄台能这样严于律己的话，实属项目的一大善事，立一个专门项目页面赞扬贵兄台的伟绩也不为过。还是类似观点，对于涉及现实人事影响的描述，我认为必须补充来源以引证；但对于其他情况，尤其是涉及超过快5~10年没再大的实质改动，或者这类作品元素列表条目，基于项目的人员活跃程度，适量提出并协作修正或者处理倒是可行，但这样大量提报并如此大义凛然的说辞，我认为这纯属添堵，或者说“挖旧账，满手脏”的活了。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月6日 (二) 04:17 (UTC)[回复]
我從來沒有將「批量」和「刪除」掛鉤。關於「刪除」，維基百科講求可供查證，故刪除無來源內容是天經地義的，若閣下不同意就請離開；至於「批量」，方針無限制者即可為，但維基百科也不強迫任何人參與，故路過喜歡做就做，批量就批量。另提刪絕對不構成強迫主編或專題參與者參與，因條目主編或其他人大可通過DRV恢復草稿繼續編寫（在此慨嘆你維草稿化用例太少了，該大大推動）。--1F616EMO（喵留言～回覆請ping） 2025年5月6日 (二) 05:34 (UTC)[回复]
我前陣子批量提刪了大愛電視劇，又不見您以「快5~10年沒再大的實質改動 」為由去保留？同為無來源舊條目，沒有不一視同仁之理。--1F616EMO（喵留言～回覆請ping） 2025年5月6日 (二) 05:36 (UTC)[回复]
至於實踐，近來我多做生者傳記小作品化，因為最近更改巡查常常看到IP君們在好心做壞事。你維BLP又是另一大糞缸。--1F616EMO（喵留言～回覆請ping） 2025年5月6日 (二) 05:39 (UTC)[回复]

更名程序的基準

本主題或以下段落文字，在討論結束後應存檔至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)[回复]

請求搬出沙盒條目：戰神賽特（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)[回复]

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

你维条目质量堪忧/WP:编辑数

菜单打开，随机条目，嗯，十有八九的Stub。

想水编辑数的可按照上述建议改善条目。--KurGenera(留言) 2025年5月3日 (六) 03:36 (UTC)[回复]

說的對，一大堆品質低劣的條目，嘖嘖。--August討論‧簽名‧回復請ping 2025年5月3日 (六) 11:44 (UTC)[回复]
抱怨和直接扔进垃圾桶（指一股脑的提删）最容易。动手改善最难。呵呵（恭喜你你又水到一个议题）。——Sakamotosan路过围观 | 避免做作，免敬 2025年5月6日 (二) 03:58 (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)[回复]

模板爆炸

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

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

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

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

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

Alzheimer's 臺灣用語

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

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

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

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

想請教一下大陸及香港方面對於此一疾病的正式稱呼及最通俗稱呼各是什麼？確定以後，可據此調整地區詞轉換。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月6日 (二) 05:45 (UTC)[回复]
大陆方面，术语在线、《ICD-11 精神、行为与神经发育障碍临床描述与诊断指南》、《精神病学》（第9版）等均称“阿尔茨海默病”。 ——自由雨日🌧️❄️ 2025年5月6日 (二) 05:56 (UTC)[回复]

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

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

要處理的問題是什麼？閣下列舉的浦東新區、濱海新區現時皆為行政區劃上的市轄區，但我知道您想要討論的對象應該是湘江新區這種。單指標題的問題的話，如果是浦東、濱海，完全且應該算作市轄區，但湘江新區這種顯然不算市轄區。--Hamish T 2025年5月6日 (二) 05:30 (UTC)[回复]
浦东新区、滨海新区是国务院发文批复（国函〔1992〕145号、国函〔2009〕125号）、民政部正式登记的县级行政区。其他新区、开发区大多是黑区。--Kcx36（留言） 2025年5月6日 (二) 08:31 (UTC)[回复]

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

本主題或以下段落文字，在討論結束後應存檔至Template talk:电影信息框、Template talk:电视节目信息框、Template talk:Infobox book。

以往中華民國行政院新聞局對其審查的書刊賦予編號——登記證號，此非國際標準書號（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)[回复]

其他

管理操作覆核請求：對Wildcursive的處理

本主題或以下段落文字，在討論結束後應存檔至Wikipedia:管理操作覆核請求/存檔。

已解決
鑑於社群共識，覆核有關操作為不妥，並予以推翻。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月28日 (一) 09:06 (UTC)[回复]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

此請求是根據Wikipedia:管理操作覆核請求所提出，請先閱讀相關內容。

操作： [14]
执行者： Ch.Andrew （討論 · 貢獻 · 日誌）
先前讨论：維基百科:管理员布告板/其他不当行为#Wildcursive

@Wildcursive：首先，這位用戶對於自己討論頁上由Cindyzs寫出的宣傳性內容置之不理，經我移除後再次加回。引用@薏仁將的話：……雖然WP:TPG對於用戶討論區使用自由度是相對寬鬆的，而本案被提報人對於相對當事者用戶採取寬容容忍的態度去看待那些個人主觀意識的政治觀點宣傳，然而被提報用戶是可以有多次機會對相對用戶進行勸告及以相關方針教導其用戶避免再度出現不適當的行為，但被提報用戶選擇被動、消極的方式選擇不作為的冷處理，此等則會被相對用戶認為不反對即表認同的錯誤認知而持續性的做出不適當的行為；雖然該用戶暫時已被封鎖一週，但是難保解封後不再出現相同的不適當行為，而身為當事者的您，難道某個角度立場來說是無任何責任？又或者這種消極寬容的態度不也是變相的縱容對方行為？

而管理員章安德魯對於此次提報，作出以下處理： 還原。以User:Wildcursive自行決定的版本為準/態度指引WP:OWNTALK：「對於用戶討論頁而言，這些方針的遵循度會比其他討論頁較為寬鬆」「以上方針並不限制用戶在自己的討論頁移除留言」、編輯指引WP:PUT：「您可以按照您認為合適的方式將討論串刪除、存檔，或者是簡要地總結以前的討論」等語可以清楚得知，用戶對於自身帳號的討論頁具有裁量權，保留或刪除內容由帳號所有者自行決定即可，其他非當事用戶無須干涉。

然而，很明顯，方針（這甚至只是指引)中註明的是「較為寬鬆」而非「完全無需執行」，當然無法輕率得出「保留或刪除內容由帳號所有者自行決定即可」的結論。同時，WP:NOT中寫明：「維基百科拒絕宣傳。維基百科不是演講台、討論區、宣傳工具、廣告場所或者展覽平台。此項適用於用戶名、條目、分類、檔案、討論頁、模板及用戶頁。」

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

(～)補充：被提報用戶在ANM進行政治宣傳，而管理員完全沒有考慮這點。--WiiUf🐉 2024年12月20日 (五) 05:26 (UTC)[回复]
(＋)支持复核。——自由雨日🌧️❄️ 2024年12月20日 (五) 05:54 (UTC)[回复]
(＋)支持覆核：剛注意到這邊有討論，把我剛在那裡留的意見改一下放這：
Ch.Andrew 解釋他的處置理由有不少問題：不限制使用者在自己的討論頁『移除』留言並沒有「不限制使用者『還原』因違反方針而被其他人移除的留言」之意，而他又以指引導出使用者對於自身帳號的討論頁具有裁量權，保留或刪除內容由帳號所有者自行決定即可，其他非當事使用者無須干涉，然而他引用的WP:PUT是指引，WP:SOAP是方針，指引和方針衝突時是方針優先，遭移除的內容是違反方針，用指引當理由說可以保留違反方針的內容根本是無效的：
  1. 用這邏輯，每個使用者都可以在自己討論頁放這些違反方針的內容，因為自己的討論頁自己當然有裁量權啊。
  2. 當 A 把自己討論頁上被移除之違反方針內容加回去，那就是 A 的編輯行為了，原本加的人違反方針，A 當然也違反方針。
我並質疑，這個案子原本已有其他管理員開始處理，為何不常活動的 Ch.Andrew 突然介入迅速處理掉這件案子。--LHD（留言） 2024年12月20日 (五) 05:57 (UTC)[回复]
(？)疑問:另一個矛盾的點，依照處理的管理員認定的標準，那麼:我只要找政治理念相同的用戶B，或者用戶C不反對我個人政治觀點，那麼我可以將那些政治觀點放置在用戶B與用戶C個人討論區，而且只要相對用戶不反對，那麼就不構成WP:SOAP相關限制(因為B、C君用戶有自己裁量自己討論區討論議題權利)？那麼請問WP:SOAP存在的意義是？那麼問題來了，如果依照處理管理員認定的方式，B君與C君不表態、不反對那麼那些已發生的宣傳行為就不算構成WP:SOAP條件(裁量權在對方用戶身上?)，那麼連帶的是否連WP:DE也構不上邊？然後更有趣的是:如果有人刪除那些政治觀點，我可以仿傚他作法警告那些依照理據刪除的用戶要他們不要「越俎代庖」(因為訊息接受者沒反對，裁量權在對方用戶身上)請問是這個意思嗎?請問可以如此作法嗎？蠻好奇這種「特殊」認定標準。--薏仁將🍀 2024年12月20日 (五) 07:29 (UTC)[回复]
可能離題請見諒，其實上次就想提出，不曉得這是否算討論頁的漏洞？我認為可能需要研討是否需要修改，因為雖然看似不妥，但對應現行方針指引確實沒有明確違規，管理員處不處理都很難。感覺上暫時實施封禁的管理員是用了共識封，不過這是中維沒有的方針。若沒有界定標準，往後也可能再發生，故我認為可能需要進一步另行討論。--提斯切里（留言） 2024年12月20日 (五) 09:36 (UTC)[回复]
是的，標準的漏洞，看看屆時發生處理的管理員怎麼認定怎麼解釋或者類推適用，有沒有慣例案例可循，的確需要填補漏洞，不然可能造成仿效效應。--薏仁將🍀 2024年12月20日 (五) 09:42 (UTC)[回复]
我认为不存在漏洞。明显已经违反WP:NOT。--自由雨日🌧️❄️ 2024年12月20日 (五) 09:55 (UTC)[回复]
這樣就有處理落差了，我先前確實覺得這是為不妥，但現在可以理解了這是個人討論頁要如何處理的自由意志，而且以討論頁方針來說，到別人的討論頁進行「討論的狀況」不涉及宣傳，那麼實為不應該封禁的，管理員不處理也是正確的。
我這裡指的漏洞，是要考慮這樣認知差異的，而且確實不明確。--提斯切里（留言） 2024年12月20日 (五) 16:14 (UTC)[回复]
但像是比較敏感性質的議題又或者如本案般主觀意識政治內容的傳遞，那麼在認定標準上這是否為宣傳行為的一種？若屬於宣傳行為，那麼其他用戶是否可依據對應的方針指引予以移除？又或者必須知會訊息接受者相關內容可能有不適當之虞?倘若訊息接收者並無任何表態亦不反對，那麼這些有疑慮的內容是否仍可移除？這些可能屬於比較算認定上會造成的差異(或說灰色地帶)也許值得討論。--薏仁將🍀 2024年12月20日 (五) 23:01 (UTC)[回复]
也认同 這些可能屬於比較算認定上會造成的差異(或說灰色地帶)也許值得討論。。 尽管我认同“管理员不处理也是正确”, 既然社群有分歧，可以就這是個人討論頁要如何處理的自由意志，而且以討論頁方針來說，到別人的討論頁進行「討論的狀況」不涉及宣傳进行专门讨论。--Gluo88（留言） 2024年12月21日 (六) 23:51 (UTC)[回复]
@Tisscherry 在下也认同 而且以讨论页方针来说，到别人的讨论页进行“讨论的状况”不涉及宣传，那么实为不应该封禁的，管理员不处理也是正确的。--Gluo88（留言） 2024年12月21日 (六) 23:45 (UTC)[回复]
版主(：)回應：本人參與維基已約二十年，我自己的討論版面有何文字、如何回應、取捨，向來是本人的自由，幾無人越權干涉，亦屬尊重版主之傳統，包括許多行政管理人員皆能分清界線並協助回退對本人討論頁的真實破壞，違反本人意志亂刪亂動才是無禮。我對於符合《世界人權宣言》、臺灣人民自主意志與「自己的國家自己救」理念及維基百科自由民主多元開放精神的善意留言基本上皆大致不反對、不反感、不反彈。美國法律規範的維基百科可不是獨裁中國、專制共產黨或其百毒等工具，也絕不容遭其可憐打手操控限制。若我不覺得留言不當，屬表達意見、交流新舊條目編輯方向、及我可接受的言論自由，其實輪不到遠不相干之他人管太寬任意置喙。
已不常回維基的我是被動回應、被迫說明，說清楚、講明白、暢所欲言、闡明理據是必要且正常的。既然遠非明顯破壞、亦屬無害（有被害人嗎？只有我吧！），我自然有在個人留言版對合理言論自由沉默不作為、不採取任何行動或回復原狀的權利！我有回應或不回應的自由。之前也有較清醒開明曾多少呼吸過較自由空氣的中國人來我版談上海獨立自治、女權、漢人殺滿人等。或香港人來談魚蛋革命等，具善意的鄰國維基人來我版面跟我談政治，我通常會予以回復，編維基百科不可或缺的事實、史實、真理與普世價值等皆屬越辯越明。
每個人自己的版面多少出現與條目直接或間接相關的文字很平常。大家摸著良心自問自己或他人名下的版面其實歷來有多少連個條目名稱都未出現的瞎扯蛋？要倒查22年嗎？我有本版言論方向尺度的管轄權與裁量權, 這歷來皆屬自主自治自理自決的心證自留地空間。事實上, 許多維基化留言提醒我出現哪些新條目可查閱或補充增刪, 又有哪些我已知的主題議題可加強。這些留言者與其純粹條列出那些條目要我關注, 不如寫成短文表達意見, 更能吸引我的關注而參與編輯, 我看不出兩種方式的關鍵字詞有何太大差別, 但絕對更有效, 引發更多點入的好奇或編輯的欲望, 對維基也自然是好的。無謂與過度禁制對維基生產力只是有害而無益。這跟平舖直敘廣告沒人看、沒人買單是同樣的道理，Did you know的DYK問題指南「請創作可以引起讀者興趣的問題」已驗證了十幾年。留言者想引起我的閱讀編輯興趣，或我的回應能否引起他人的閱讀編輯興趣，從這些留言是「待協作完善清單」的角度解釋，有何不可？誰曰不宜？這與真正編輯條目時需依多重可靠來源，既不違背，也能並存。「不管黑貓白貓，會捉老鼠就是好貓」，這是相同的實用主義功益考量，能促進維基發展才是硬道理。捏死窒息中維才是罪人吧。
寫動漫的能在彼此討論頁邊寫邊聊動漫，沒人說不可。寫日本女星的在留言板互稱某某美很漂亮、喜歡某某子，是不是宣傳？說今天又看了10部，打算下周增補創建其中7條，是不是宣傳？寫交通的小聊維基假期旅遊，說想去臺南高雄玩，是不是宣傳？寫生醫的討論疫情，寫文學的聊戲劇，皆很合理。為何寫法政的就不能在自版小聊法政，礙了誰嗎？這種種文字在本質上有重大區別嗎？
維基百科有多少比例不是「宣傳」？幾乎大多數的圖片文字皆可被解讀為具某種宣傳或反宣傳之意。在某些人眼中耳裏，不習慣的事物都很敏感、大驚小怪，但在早已熟悉如日常生活者看來卻是如呼吸般再自然平常不過。此定義模糊不明而極可能衍生超多重標準的思想與言論警察之例一開，徒費時間精力，如同讓真理部、老大哥與朝陽群眾管到每個人在私宅的言行、門口的對聯、信箱的廣告、牆上的壁畫、鄰居的私語、手機的通信，有人來串門子，還要被檢查，實屬荒謬。每個人的頁面用戶框等自由編排創作就是貼在家門口的宣言標語，用戶對待其個人版面的方式亦屬自介自治的一部份，兩者的性質、內在邏輯與適用對待應屬相近。若縱容少數人企圖在他人版上搞擴大文革糾鬥，將成永無寧日的浩劫。無處不在的監控只會製造更多爭端，茲生更廣衝突，轉移消耗編者注意力，終成反噬人人而成龐大數位極權主義的一九八四。
如果裹小腳的慈禧看到奧運女子金牌就罵人家傷風敗俗成何體統、或如果有個別極端伊斯蘭教徒看到餐廳在賣豬腳火腿貢丸就呼天搶地說違逆真主要斬首、要下地獄、要燒店家，顯非合理，政治控制與資訊封鎖是沒必要的，別讓中國迄今仍時常發生的作法自斃、請君入甕再實現，維基百科不該日益封閉退步。
管理員千村狐兔（[15]）與章安德魯（[16]）均已表明尊重版主的態度，這基本上也是由正規編者自理其個人討論頁的傳統，除非真屬破壞或已被自刪、警告表明不受歡迎者。企圖懲處被留言者或已表明自行判斷篩選者是很奇怪的事。當事人對此個案沒意見、不在意、不覺得被騷擾，那就不需要再浪費時間強入人於罪。
十多年來本版基本自在自適健康無礙，天下本無事，實不煩庸人自擾擾人。--WildCursive（留言） 2024年12月20日 (五) 11:54 (UTC)[回复]
實際上維基百科並不保障你在討論頁的言論自由，維基百科並非論壇，第五點：與維基百科無關的專案內容。請勿存放與維基百科無關的材料，包括使用者空間。請參閱WP:UPNOT了解不得包含的內容的範例。
，WP:UPNOT有此外，您不得在使用者空間中包含可能損害專案聲譽或可能引起廣泛冒犯的材料（例如種族主義意識形態）。無論是嚴肅的還是惡意的，「維基百科不是演講台」與百科全書條目一樣適用於使用者空間，而「維基百科不會審查內容」則適用於條目頁面和圖像；在其他命名空間中則存在一些限制，旨在確保與社群的相關性及不擾亂社群。您在使用者空間確實比其他地方擁有更多的自由度，但不要粗心大意。任何編輯者都可以立即刪除極具冒犯性的材料。，這些是具有冒犯性的，此外管理員的論點並不代表整個維基百科，宣傳政治理念，誹謗民意代表，為不可接受的行為，例如誹謗馬文君為叛國賊明顯違反與維基百科無關的爭論性言論，或攻擊或誹謗編輯群體、個人或其他實體的言論。這些言論均被視為分裂性的並會被刪除，而重新加入將被視為擾亂。，這些都是合理證據，因此刪除該些留言為正當。-- A0(討論·簽名) 2024年12月21日 (六) 12:44 (UTC)[回复]
個人認為甚至可能違反UCoC第3.1 侮辱：這類行為包括惡言、侮蔑、使用刻板印象、基於個人特質的攻擊行為。侮辱可指感知特質，其諸如智力、外貌、民族、種族、宗教（或無宗教信仰）、文化、種姓、性取向、認同性別、生理性別、殘障、年齡、國籍、政治派別或其他特質。在部分情況中，反覆地嘲笑嘲弄、諷刺挖苦、或侵犯攻擊會構成集體侮辱。和引戰：以故意擾亂話題或惡意地發佈言論方式，有意圖地挑釁他人。-- A0(討論·簽名) 2024年12月21日 (六) 12:55 (UTC)[回复]
什麼叫打著維基之名，不適當就是不適當，你認為你可以去公共政策網路參與平台提案說那些嗎，當然不行，因為地方錯了-- A0(討論·簽名) 2024年12月21日 (六) 15:10 (UTC)[回复]
我认为我有处理我的讨论页的自由，我不想要别人插手我讨论页面的事情。实在有不合规的内容我会折叠，但我不认同别人替我删除还不让我处置。 --MilkyDefer 2024年12月20日 (五) 13:45 (UTC)[回复]
你这话就相当于在说你认为你对你的用户页和用户讨论页有所有权。--自由雨日🌧️❄️ 2024年12月20日 (五) 22:56 (UTC)[回复]
我記得使用者對於用戶討論頁面僅有「使用權」，但閣下的說法，恐怕會變成用戶對於自己的討論頁面及相關用戶頁面有「擁有權」，這錯誤的理解吧？。--薏仁將🍀 2024年12月20日 (五) 23:08 (UTC)[回复]
这个事件是一个编者在第三人的讨论页面发布宣传性内容（但是我认为那些内容可以搬到维基新闻做opinion piece），然后第四人意图移除内容后被还原，莫名其妙就要召唤管理员介入。此事之奇葩程度闻所未闻，因为那个编者没有滥用自己的讨论页。你们可以规定任何人不得反对他人在自己的讨论页面严格执法，但是我认为与其把原则法律化并且不断打补丁，不如让所有编者把自己的账号交出来交给三百多万个硬编码规则的机器人。--MilkyDefer 2024年12月21日 (六) 10:34 (UTC)[回复]
所以你的意思是，在条目讨论页、在用户页、在用户空间子页面均不得放置的宣传性内容，可以转而在用户讨论页放置？--自由雨日🌧️❄️ 2024年12月21日 (六) 10:38 (UTC)[回复]
👍 赞--Dryrace（留言） 2024年12月28日 (六) 10:53 (UTC)[回复]
程序問題：Wikipedia:管理操作覆核請求有提到「在發起覆核請求前，建議嘗試與執行操作人（當事人）討論，以解決問題」，請問提請覆核之人等是否已和當事管理員進行過充分討論溝通？雖說這只是「建議」，但是如果以後每個人都在未經充分溝通的情況下就逕行提請社群覆核管理員操作，恐致社群無謂困擾、消耗社群精力。-Peacearth（留言） 2024年12月20日 (五) 16:19 (UTC)[回复]
本人已根據您的建議在有關管理員的討論頁留言。由於本人已於該留言詳述意見，請恕不在此重複。--派翠可夫 (留言按此) 2024年12月21日 (六) 03:50 (UTC)[回复]
若要较真需注意上述WP:NOT中所列只有用户页，并无用户讨论页。WP:TPG#別人的意見中也着重强调（而这也是使用 deltalk 中自动生成的标签所链接到的页面）{{deltalk}}是用来移除非常明显的人身攻击和不文明的留言，而涉及到的留言段落明显不属于这一类。另外想提醒一些编者，并不是所有您看到的不喜欢的内容都要跑到WP:ANM中提一个新提报，特别是本讨论中涉及到的留言并非发送给提报者。您这种行为相当于在两人间对话时擅自插嘴并大叫「我不喜欢这个对话！你们必须停止！」，这样十分不礼貌。若当事人认为此对话不妥自然会自行处理，但既然当事人认为这对话并不冒犯那我认这留言也并无大碍。我知道这留言相对于某些用户来说确实感到冒犯，但正如我之前所说，这些话并不是对您说的，您可以选择无视。参与维基百科所需要适应的一点是需要接受有用户的想法及观点与您不同，且，并不是所有您不喜欢的内容都必须删除。--广雅 范★ 2024年12月20日 (五) 19:06 (UTC)[回复]
NOT中列出了讨论页，显然用户讨论页属于讨论页。此外，《WP:用户页》指引中还列出了更广泛的适用于用户空间的条款。最后一句加粗的留言则属于混淆视听，从一开始所有人提出行为不当的理据就是宣传，而不是所谓“不喜欢的内容必须删除”。--自由雨日🌧️❄️ 2024年12月20日 (五) 23:00 (UTC)[回复]
宣传指的是对多数不特定的人推广自己的观点或者产品，如在条目空间打广告，又如在用户页大肆宣扬自己的政治立场。在讨论页这种两人对话的情况下是怎么成为宣传的呢？再者，也说过了，应由接收方判断这能不能接受，而不是完全不是接收方的第三者。--广雅 范★ 2024年12月21日 (六) 06:25 (UTC)[回复]
照这个逻辑，我放置在自己的用户页或讨论页将属于宣传的内容，我只要放在对方的讨论页，就可以避免被当作“宣传”？那以后大家做宣传只要将这些内容互相往对方讨论页放就行了，只要事先互相打好招呼，同意对方放置。--自由雨日🌧️❄️ 2024年12月21日 (六) 07:19 (UTC)[回复]
这是属于WP:GAME以及WP:POINT的行为。--广雅 范★ 2024年12月21日 (六) 07:32 (UTC)[回复]
是的，所以为什么目前他们二位未落入这个范畴呢？--自由雨日🌧️❄️ 2024年12月21日 (六) 07:36 (UTC)[回复]
范給的前設條件是“對多數不特定的人”，而且要滿足WP:GAME的話一般還需要證明相關用戶是帶有目的性地持續這樣做。Sanmosa 蚌埠 2024年12月21日 (六) 07:40 (UTC)[回复]
“对多数不特定的人”什么意思？至于“带有目的性地持续这样做”的话，从其多次被提报来看，我认为已经可以这样认为了。--自由雨日🌧️❄️ 2024年12月21日 (六) 07:42 (UTC)[回复]
「對多數不特定的人」我會理解為「無差別」，比如「對多數不特定的人攻擊」相當於「無差別攻擊」。Sanmosa 蚌埠 2024年12月21日 (六) 07:47 (UTC)[回复]
我没看到他给这个前设条件？（我这句指的也主要是“两人互相放置宣传材料”，当然多人互相放置也适用）--自由雨日🌧️❄️ 2024年12月21日 (六) 07:52 (UTC)[回复]
#c-范-20241221062500-自由雨日-20241220230000。Sanmosa 蚌埠 2024年12月21日 (六) 08:14 (UTC)[回复]
哦。我的意思是，“放置内容”本身就已经构成了无差别传播，因为它们是公开可见的（邮件则不是），尤其是用户讨论页，曝光率是很高的。--自由雨日🌧️❄️ 2024年12月21日 (六) 08:16 (UTC)[回复]
对多数不特定的人：比如客栈、条目、用户页，放在那里的用意就是被大家看到；带有目的性地持续这样做：被提报者是反对第三方直接修改讨论页内容，并没有持续性进行宣传的意图。--广雅 范★ 2024年12月21日 (六) 07:52 (UTC)[回复]
然而用户讨论页是仅次于用户主页的很多人会查看的页面。--自由雨日🌧️❄️ 2024年12月21日 (六) 07:53 (UTC)[回复]
另外，放置于用户子页面、访问量几乎没有的内容也是可以因宣传而删除的。--自由雨日🌧️❄️ 2024年12月21日 (六) 07:57 (UTC)[回复]
那么本案例中被删除的留言是违反了WP:TPG#別人的意見内的哪一条呢？--广雅 范★ 2024年12月21日 (六) 08:11 (UTC)[回复]
违反了WP:SOAP ——自由雨日🌧️❄️ 2024年12月21日 (六) 08:13 (UTC)[回复]
这是编辑他人的留言，操作需符合WP:TPG#別人的意見中的一点。--广雅 范★ 2024年12月21日 (六) 09:36 (UTC)[回复]
违反了SOAP啊。“移除不允许的资料，例如……等”。--自由雨日🌧️❄️ 2024年12月21日 (六) 12:00 (UTC)[回复]
違反了WP:NOTADVOCACY，作任何遊說、宣傳或招攬，包括商業、政治、科學、宗教、國家、體育或其他性質。條目當然可以客觀地描述某人或事物，但必須符合中立觀點。如有觀點或意見希望得到其他人支持，請移駕至個人網誌或論壇。，即為宣傳政治，且本條適用所有命名空間。-- A0(討論·簽名) 2024年12月21日 (六) 12:51 (UTC)[回复]
還有WP:NOTOPINION-- A0(討論·簽名) 2024年12月21日 (六) 12:52 (UTC)[回复]
還有WP:NPA，攻擊某些特定政治人物-- A0(討論·簽名) 2024年12月21日 (六) 13:06 (UTC)[回复]
(！)意見:一些有趣的問題請教參與議題的諸位
  1. 用戶討論區算不算討論區的一種型態展現？
  2. 承上，若用戶討論區屬於討論區的一種呈現樣態，那麼試問用戶討論區是否也受到WP:SOAP規範限制範疇內？若用戶討論區非討論區定義條件，那麼也請說明其認定意見。
  3. 用戶A傳送高敏感議題(如：政治觀點，如XXXX年的選舉活動理想政治人選)傳遞投放給與其他用戶至其討論區，請問是否構成宣傳行為？
  4. 承上假設這是構成WP:SOAP行為條件定義，而傳遞者也依照前述遭管理員封鎖，那麼請問：消極、被動不表任示何立場的訊息接收用戶B消極不移除那些敏感話題而任憑展示，試問是否同樣構成WP:SOAP相關要件？傳遞者被管理員封鎖，難道相對訊息接收者就無需收到任何管理員口頭提醒警告，告知該等敏感內容有WP:SOAP之虞，要求對方移除？
請參與該議題的諸位好好思考一下提問內容，思考這件議案處理是否妥適，謝謝。--薏仁將🍀 2024年12月21日 (六) 00:23 (UTC)[回复]
用户命名空间相对起维基百科命名空间及条目命名空间来说更具有私人性质，正如一般不允许随意修改他人用户页一样，用户讨论页的内容也应该由页主自行定夺。您的第三点确实构成了宣传，但如果 A 因为宣传被封这是因为他做出了「宣传」这种不当行为，而不是单凭他发的内容。B 作为宣传材料的接收者，若觉得无需理会则不移除并没有什么问题。不像维基百科命名空间会有多人同时参与讨论与条目命名空间会被索引，用户讨论页一般是对该用户的留言区，依我看来不是「任凭展示」。--广雅 范★ 2024年12月21日 (六) 06:34 (UTC)[回复]
感謝閣下特地撥冗協助釐清與回覆，所以閣下認為:用戶討論區亦屬於討論區的樣態形式，但是由於定位上屬於個別用戶「私人」性質，所以界定上，即便他人傳遞高敏感內容議題，則裁量權(刪除、存檔、保留)這些權益則屬於個別用戶的權利範圍之內，而若沒明顯違反不文明、人身攻擊，對方用戶不排斥亦不反對情形下，第三方用戶則毋須介入處理，請問如此解釋是否正確？--薏仁將🍀 2024年12月21日 (六) 06:54 (UTC)[回复]
是的，我是这样认为的。--广雅 范★ 2024年12月21日 (六) 07:02 (UTC)[回复]
那這樣子的話，基本上，照原處理管理員處理方式(還原對方用戶遭他方用戶介入移除的內容)是沒有太多問題的，感謝閣下協助釐清。--薏仁將🍀 2024年12月21日 (六) 07:11 (UTC)[回复]
WP:NOTSOCIAL，WP:NOTHERE，显著违反方针的内容，移除行为无需经由任何人同意。->>Vocal&Guitar->>留言 2024年12月21日 (六) 07:18 (UTC)[回复]
這裏我覺得值得關注的一點是“與維基百科相關的資料”應該如何解讀，因為不同的解讀方式會影響Ch.Andrew的操作具備正當性與否。Sanmosa 蚌埠 2024年12月21日 (六) 07:31 (UTC)[回复]
@WiiUf。Sanmosa 蚌埠 2024年12月21日 (六) 07:32 (UTC)[回复]
順便也ping一下@薏仁將。Sanmosa 蚌埠 2024年12月21日 (六) 07:41 (UTC)[回复]
這個要看切入的點是什麼，所以我才會設置那些問題問參與討論的諸位，貌似范君與原處置的管理員看法立場是近似的，但是我仍傾向認為即便是私人的性質，則也不應當消極任憑放置具有敏感爭議的宣傳材料，這邊可能需要諸位需進一步釐清討論，我個人覺得可能會有用戶會利用這種認知判斷差異落差而作仿效，屆時倘若要規範，恐怕也許會被對方說嘴。--薏仁將🍀 2024年12月21日 (六) 07:54 (UTC)[回复]
我的問題是「與維基百科相關的資料」到底是說「與維基百科此一項目本身相關的資料」還是說「與維基百科的內容相關的資料」？Sanmosa 蚌埠 2024年12月21日 (六) 08:12 (UTC)[回复]
應該是被定義成:「與協作改善維基百科條目或者商討相關姐妹計畫、本身或內容相關聯性議題」不論是個人前述定義或者您提出的二個要件，傳送個人政治觀點給與他人這已經很明確是「宣傳行為」，不用懷疑；但是那些政治觀點內容放置，似乎不像是「與維基百科存在相關性的資料」，就直接開門見山的問:一則202X年XXX直轄縣市長選舉理想人選被放置於用戶討論區，你能說明它關條目協作改善或維基百科相關性質議題資料有甚麼相關性？沒有啊，不就是個人主觀評價的內容？好像根本與條目改善協作或者相關議題商討無關聯性吧？--薏仁將🍀 2024年12月21日 (六) 08:35 (UTC)[回复]
我提這點主要是給大家一個思考的方向，我大致理解你的意見了。亲，我簽名那刻的時間是 2024年12月22日 (日) 08:49 (UTC)[回复]
其實有关页面内容的方针是可適用於使用者頁面空間的，標題以User（使用者）和User talk（使用者討論）開頭的頁面都被視為使用者頁面。另外當用戶發現其用戶討論頁面有使用不當情形，則應優先發布{{subst:uw-userpage}}提醒通知。--薏仁將🍀 2024年12月26日 (四) 11:02 (UTC)[回复]
@薏仁將：我留意到用戶頁指引在今年11月有過一次修訂，我在VPP那邊就著那個修訂提了一些問題，其中就牽涉到“用戶頁（面）”一詞的理解，這恐怕也會影響這裏的結果。Sanmosa 蘭絮 2024年12月28日 (六) 15:30 (UTC)[回复]
但至少“用户讨论页”无疑是属于“讨论页”的，故用户讨论页肯定是适用WP:SOAP的。--自由雨日🌧️❄️ 2024年12月28日 (六) 15:34 (UTC)[回复]
說「無疑」太絕對了，至少敝人個人是持疑的。敝人認為，「討論頁」和「用戶討論頁」是不同的頁面，WP:SOAP僅適用於前者。--Matt Smith（留言） 2024年12月29日 (日) 02:23 (UTC)[回复]
那你得拿出证据，而不是空穴来风。--自由雨日🌧️❄️ 2024年12月29日 (日) 03:53 (UTC)[回复]
法律無明文規定者，不為罪。WP:SOAP說適用對象是「用戶名、條目、分類、檔案、討論頁、模板及用戶頁」，這些對象中關於用戶的只有「用戶頁」，沒有「用戶討論頁」。--Matt Smith（留言） 2024年12月29日 (日) 04:38 (UTC)[回复]
WP:UP，標題以User（使用者）和User talk（使用者討論）命名空間開頭的頁面都被視為使用者頁面。-- A0(討論·簽名) 2024年12月29日 (日) 04:41 (UTC)[回复]
我前面早已回复“用户讨论页”属于“讨论页”。--自由雨日🌧️❄️ 2024年12月29日 (日) 04:44 (UTC)[回复]
標題以User（使用者）和User talk（使用者討論）開頭的頁面都被視為使用者頁面，皆須受內容方針規範，只是為了用戶使用用戶討論頁便利性及彈性，規定較寬鬆，但寬鬆不代表完全不受限制，這點要先釐清，而前面內容皆在使用者頁面有相同說明。--薏仁將🍀 2024年12月29日 (日) 04:56 (UTC)[回复]
了解，謝謝。--Matt Smith（留言） 2024年12月29日 (日) 05:04 (UTC)[回复]
您好，使用者頁面上的衍生定義應當是不妨害影響這邊的討論結果，因為它可以幫助釐清究竟使用者頁面的範圍包括在哪？限制又在哪？還是說其實定義所指向的標的為全然不同的東西？--薏仁將🍀 2024年12月28日 (六) 21:19 (UTC)[回复]
於我而言，新版條文的規定無法使我有效判斷兩者是否為全然不同的東西，因此這個問題我無法解答，而這也是我要在VPP尋求解決方案的原因。Sanmosa 蘭絮 2024年12月29日 (日) 03:49 (UTC)[回复]
我想問大家，那今天夏土賢如果是在討論頁發表的話，照以上的邏輯，是不是就可以了-- A0(討論·簽名) 2024年12月21日 (六) 10:08 (UTC)[回复]
這樣説吧，發表是一回事，移除是另一回事。用戶不能任意發表不當言論或許並不意味用戶可以任意移除不當言論。亲，我簽名那刻的時間是 2024年12月21日 (六) 13:36 (UTC)[回复]
这好像转移焦点了吧？假如目前被提报（及复核）的是移除留言的人，这条评论（评价移除操作是否恰当）才对题。但这里讨论的是将宣传性内容加回的用户的“加回”操作。——自由雨日🌧️❄️ 2024年12月21日 (六) 21:48 (UTC)[回复]
然而這裏也涉及到一個邏輯問題，就是如果移除操作本身並不恰當，那移除操作是應該要被無效化的，那Ch.Andrew的操作就不能被認為不具備正當性。亲，我簽名那刻的時間是 2024年12月21日 (六) 23:29 (UTC)[回复]
哦，那就是我前面论证的我认为这一内容本身确实不应存在了（毕竟放置于几乎无人访问的用户子页面、且我认为宣传意味并不如本案高的内容，社群共识也是删除）——即我认为移除是正当合理的。--自由雨日🌧️❄️ 2024年12月21日 (六) 23:32 (UTC)[回复]
然而我這裏也主張言論本身是否不當與移除是否正當合理不存在直接的關係。亲，我簽名那刻的時間是 2024年12月22日 (日) 00:09 (UTC)[回复]
你的意思是二個問題(行為)要分開看分開討論，對嗎？--薏仁將🍀 2024年12月22日 (日) 00:16 (UTC)[回复]
是的，你可以這樣理解。亲，我簽名那刻的時間是 2024年12月22日 (日) 08:48 (UTC)[回复]
是說之前好像有個民眾黨黨工因為宣傳被封進了是吧，剛才翻了一下討論頁，守望者愛孟在2017年說了Wild閣下這裡是維基百科的民進黨總部，Jackac就是深愛台灣的請願民眾。。。哈哈哈，大概好久前就是這樣了-- A0(討論·簽名) 2024年12月22日 (日) 01:16 (UTC)[回复]
(！)意見： 从讨论中看到，对是否可以删除其他人个人讨论页上的这类留言，以及恢复自己个人讨论页被他人删除的这类留言争议不小。当对立双方的判断不一致时，往往会导致编辑删除和恢复的反复。
  1. 鉴于双方的判断具有主观性，是否可以看作是编辑争议， 是否可以通过提报到编辑争议页面，由社群讨论并形成共识后再处理？
  2. 若有人违反共识进行操作，则可再提报至“维基百科:管理员布告板/其他不当行为”，并在此阶段请求管理员介入处理, 注重讨论建设性与公平性。
--Gluo88（留言） 2024年12月21日 (六) 19:12 (UTC)[回复]
Cindyzs等用户在该讨论页所作所为显然与建设维基百科毫无关联。若Wildcursive想恢复其留言，唯一合理的理由就是这些留言与维基百科及社群相关，而不是其对讨论页的所有权，因为用户并没有对这种绝对的裁量权。至于拿着自由民主及思想自由说事的部分用户，仿佛是搞不清Wikimedia不是政府、第一修正案并不适用于此一样。看上去仿佛自己是民主斗士，实际上和拿法律条文要求维基百科自我审查的用户没什么区别，完全是无效论据。不重视社群共识，恰恰是与维基媒体运动的行事方式背道而驰的。——暁月凛奈 (留言) 2024年12月22日 (日) 00:37 (UTC)[回复]
那今天他說剷除親中國勢力者，是否會造成大陸編者或政治立場偏向大陸之編者之不快或感受到人身威脅，這明顯非文明，又或是否違反UCoC第2.1我們期望所有維基媒體人都能對他人表示尊重。不論在維基媒體的線上還是線下環境，在與他人交流過程中，我們要以互相尊重的態度對待對方。，分明是不行的，明顯具有重大違規事宜，那怎麼能夠保留，又說他人是無恥政客，亦不尊重對面政治立場的人，所以維基百科根本是不容許這些的。-- A0(討論·簽名) 2024年12月22日 (日) 09:15 (UTC)[回复]
什麼叫做「那今天他說剷除親中國勢力者」，請你不要把我沒說過寫過的話塞給我！如果你指的是Cindyzs說的，他留言以來，我對話頁也沒出現那樣的文字。這已是你至少第二次胡亂把我沒寫的文字栽贓給我，易生誤會。至於Cindyzs在我討論頁明白引用黃國昌的前一個黨時代力量及其黨主席王婉諭批他是「無恥政客」，這是有來源轉述，我不認為他這樣寫有何大問題。至於為何他要特別提黃國昌，我猜是因為那其實是我於2013年創建的頁面[17]，無論他是奚落暗諷我、感嘆我為何當年如此，我都沒意見，這也算針對編輯史交換意見。我看不出有什麼好屢屢刪除的。--WildCursive（留言） 2024年12月24日 (二) 04:01 (UTC)[回复]
我指的本來就不是你啊，這裡是說soap的爭論-- A0(討論·簽名) 2024年12月24日 (二) 04:45 (UTC)[回复]
戒嚴那邊-- A0(討論·簽名) 2024年12月24日 (二) 04:46 (UTC)[回复]
WP:OWNTALK，有提到對於使用者討論頁而言，這些方針的遵循度會比其他討論頁較為寬鬆，雖然留言內容看起來處處和方針指引相悖，也引起了反應，但這實質都不屬於違規的部分，因為使用者對於自己的討論頁擁有自主權，而且發布的位置不是被嚴格規範的。試問，今天若是情況相反，Wildcursive使用者無法移除他不想留的內容，而到布告板尋求幫助，但是大家都跟他說這沒有違規所以不能刪除，適當的處理狀況不應該是，讓使用者自己決定什麼留言可以留什麼不留，只要他不剪貼拼接扭曲意思，要幫助的時候管理員適當地提供協助，這樣才是合乎討論頁自主權的。
這邊另外想建議@Wildcursive，我留意到同樣內容的留言您放了幾個地方，在個人討論頁是為寬鬆的留言，但若上了客棧或布告板就有為難的狀況，我先前沒表達很好，不過我想請您考慮自行減去會違反討論頁方針的內容，這樣或許會對討論的結果較為友善。--提斯切里（留言） 2024年12月22日 (日) 10:04 (UTC)[回复]
較為寬鬆並不代表不適用-- A0(討論·簽名) 2024年12月22日 (日) 10:06 (UTC)[回复]
@Tisscherry： 我就是在個人討論頁回應，主文也放被提報頁及此客棧，我不可能期待大家都翻來翻去的看，總該讓我在被公審處完整陳述吧。有人說刪了還是有紀錄，有心人都看得見，我也沒啥好隱藏的。人有偏好與慣性，我刪了這，說不定你想的是那，若直接告訴我還可商榷或討論。父子騎驢討好不了誰，我還是集中擺在一起，也會再抽空增修。我是被動回應、被迫說明，難得一次自辯，如同答辯書給各審不算超過，這是程序正義，稱不上宣傳。--WildCursive（留言） 2024年12月24日 (二) 05:29 (UTC)[回复]
@Wildcursive君，我主要指的是最新的金牌的那段，放在客棧和布告板就不太妥當，且平心而論，這含有的身分識別較為強烈，可能不是那麼公允，這讓我想到之前曾經介入個體育項目的溝通，該名使用者認為不懂籃球的都是女性，後來一直用「妳」指稱本人，一直要我去問男朋友或老公（？？？）。我想您應該能夠明白，就點到為止了。刪了的記錄可以請求版本刪除做隱藏，如果不會請求，直接找線上管理員也是可以的。--提斯切里（留言） 2024年12月24日 (二) 11:22 (UTC)[回复]
@Tisscherry： 既然妳/你點明，請管理員刪除似乎耗些工程也未必即時、全面，本想用刪除線，想想還是略修。--WildCursive（留言） 2024年12月25日 (三) 00:26 (UTC)[回复]
這人也跟夏土賢一樣整天嘴上掛著文革-- A0(討論·簽名) 2024年12月24日 (二) 12:21 (UTC)[回复]
@Wildcursive君，您可以直接找Manchiu管理員，他處理很有經驗的。謝謝您願意考量，就看您的決定了。--提斯切里（留言） 2024年12月25日 (三) 01:12 (UTC)[回复]
(＋)支持覆核，本人不認為管理員此舉得當，理應予以討論頁編輯禁制。--Talimu0518（留言） 2024年12月23日 (一) 14:07 (UTC)[回复]
我是觉得，如果有谁移除了不合适的内容，讨论页主人不应该恢复，否则应该要算到他头上。我自己对于我自己的讨论页也是很开放，胡话我不小心回退了都会撤回。但是来反破坏的移除留言我是不会加回来的。不过没收别人的星章还是不妥，我觉得W应该恢复这条。 ——魔琴［身份声明 留言 贡献 PJ:NEW23］ 2024年12月24日 (二) 11:59 (UTC)[回复]
(－)反对覆核，方針或指引未明文限制用戶處置其對話頁的內容。--Matt Smith（留言） 2024年12月25日 (三) 02:57 (UTC)[回复]
(！)意見:在使用者頁面開宗名義的就已經說明:「使用者頁面用於維基人之間的交流與協同運作。雖然您可以自由地個性化和管理您的使用者空間，但它們是社群專案頁面，而不是個人網站、部落格、社群網路媒體或維基百科條目。它們應該用於更好地參與社群，而不是過度用於無關目的或損害專案的聲譽。」而同一個規範章節對於使用者頁面定義是:「使用者頁面主要用於人際討論、通知、測試和草稿（參見沙盒），以及（如果需要）有限的自傳和個人內容。標題以User（使用者）和User talk（使用者討論）命名空間開頭的頁面都被視為使用者頁面。」，是故，如果以定義去結合相關前述條件限制，消極的置放政治觀點議題是不允許的，只是解釋的人沒有前後上下文的關聯性給找出來罷了，所以縱使訊息接收用戶認為政治觀點屬於一種言論表達的自由，但綜合前述對於使用者頁面定義與限制條件，仍不可以放置於用戶討論頁面，因為視為宣傳行為。這樣子解釋有清楚嗎？--薏仁將🍀 2024年12月26日 (四) 09:05 (UTC)[回复]
(～)補充:被提報者目前已被管理員做出相關限制措施，請參照WP:ANO#Wildcursive及Special:Diff/85443983描述案件處理，詢問@WiiUf君是否考慮撤銷提案？--薏仁將🍀 2024年12月26日 (四) 09:17 (UTC)[回复]
管理操作复核重点是复核“管理操作”本身（WP:管理操作复核请求），被提报者后续是否有被限制，并不影响这里的复核吧？--自由雨日🌧️❄️ 2024年12月26日 (四) 09:22 (UTC)[回复]
瞭解。--薏仁將🍀 2024年12月26日 (四) 09:46 (UTC)[回复]
(！)意見：看了以上一大串，很驚訝這會有這麼大的討論。相關慣例已行之有年，並形成指引。用戶討論頁是用來讓編輯之間討論的，尊重用戶編輯本身的意願是慣例，應以用戶以及跟他正在交流中的編輯為主。第三方直接進入，介入對話，強制進行刪除，不符合指引，也不禮貌。指引方針為「一般情况下，应避免大量编辑其他人的用户页和用户讨论页，除非编辑可能会有帮助。如果不确定，请询问。 」如果第三方編輯對留言有意見，不應該直接進入刪除別人的留言，因為這會影響到原本兩位編輯之間的交流，扭曲留言的意思。「如果对某个用户的页面有顾虑，最好的办法是通过讨论页引起对方的注意。如果对方同意，就让对方自己编辑。」如果認為這段對話真的有必要移除，用戶不願意主動進行，應該在社群頁面發起議題討論，經過社群達成共識之後，再根據共識，禮貌的請用戶移除相關段落。以尊重慣例來進行處理，為最好方向。--Alfredo ougaowen（留言） 2024年12月26日 (四) 15:08 (UTC)[回复]
刚刚看到他已经被部分封锁了，这个复核请求可以关闭了吧。Пусть от победы☆к победе ведёт! 2024年12月26日 (四) 16:22 (UTC)[回复]
上面我有提過看看原提出用戶是否願意撤回提案，但自由雨日君認為，這並不影響覆核程序進行。--薏仁將🍀 2024年12月26日 (四) 22:57 (UTC)[回复]
其實有关页面内容的方针是可適用於使用者頁面空間的，標題以User（使用者）和User talk（使用者討論）開頭的頁面都被視為使用者頁面。另外當用戶發現其用戶討論頁面有使用不當情形，則應優先發布{{subst:uw-userpage}}提醒通知。另並非用戶討論頁面不受其拘束，而是標題以User（使用者）和User talk（使用者討論）開頭的頁面都被視為使用者頁面，皆須受內容方針規範，只是為了用戶使用用戶討論頁便利性及彈性，規定較寬鬆，但寬鬆不代表完全不受限制，這點要先釐清。--薏仁將🍀 2024年12月26日 (四) 22:52 (UTC)[回复]
我仍然希望能夠繼續此次覆核請求（至少應移除該用戶討論頁中的廣告內容）。—WiiUf🐉 2024年12月27日 (五) 10:21 (UTC)[回复]
同上，我认为应该移除该用户讨论页的违反方针内容，因此(＋)支持复核。还有上面某位前管理员的言论，感觉根本没有理解方针，或者说是为反驳而反驳。--Dryrace（留言） 2024年12月28日 (六) 10:51 (UTC)[回复]
(＋)支持复核。我认为仅移除与维基百科无关的政治宣传即可，用户讨论页存在过多的与维基百科无关的内容会容易被认为滥用。--Lanwi1Talk 2024年12月29日 (日) 09:05 (UTC)[回复]
( π )题外话讨论以过两个星期有余，差不多可以下个定论啦。--花开夜（留言） 2025年1月7日 (二) 17:28 (UTC)[回复]
@Ericliu1912：“切勿直接存档尚未正式关闭的评论。” ——自由雨日🌧️❄️ 2025年1月18日 (六) 00:24 (UTC)[回复]
@范：（87005281）“切勿直接存档尚未正式关闭的评论。” ——自由雨日🌧️❄️ 2025年4月28日 (一) 03:07 (UTC)[回复]
這個該準備關閉了--August討論‧簽名‧回復請ping 2025年4月28日 (一) 04:04 (UTC)[回复]
那也得由管理员正式关闭後纔能存档😂不能像那样直接存档，WP:申请成为管理员/0xDeadbeef/第2次#Mirfaek的问题这裏甚至还在讨论相关问题呢。 ——自由雨日🌧️❄️ 2025年4月28日 (一) 04:53 (UTC)[回复]

社群普遍認為，使用者頁面（包含討論頁）內容，若與百科全書建設無關，乃至於涉及政治宣傳等，則可能構成對有關頁面之濫用，而使用者留置此類內容的自由裁量權應受限制。與此同時，社群亦認知到相關方針與指引對於使用者討論留有些許餘地，不過就本案而言，此一方面理據未較前者穩固，而政策執行方面，社群亦傾向以前者為優先，即所謂「寬鬆不等於無限制」。據此，認為本案有關操作不妥，並予以推翻。誠然，認定前述不當內容，除少數顯然違規者外，或有流於主觀之虞，而使用者直接操作之際，亦往往容易造成無謂衝突；故處理此類問題，仍建議按個案情況，或提醒、督促當事人自行移除，乃至於尋求社群更廣泛討論，此後再行決定為妥，併此敘明。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月28日 (一) 09:06 (UTC)[回复]

個人意見一向是應儘量寬容，但顯然社群對此並不太青睞（ —— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月28日 (一) 09:06 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

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

本主題或以下段落文字，在討論結束後應存檔至Wikipedia:管理操作覆核請求/存檔。

已解決
社群就檢討封鎖時長問題略有共識，惟因指控無從確證，故不逕予覆核。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月28日 (一) 09:22 (UTC)[回复]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

此請求是根據Wikipedia:管理操作覆核請求所提出，請先閱讀相關內容。

操作： [18]
执行者： Manchiu （討論 · 貢獻 · 日誌）
先前讨论：[19]

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

  • (＋)推翻到不限期封禁。如上。beef [talk] 2025年1月31日 (五) 04:15 (UTC)[回复]
  • (－)反对：在操作者已經證明了被封禁者近來編輯並沒有故意侵權的事實之後，提請人仍然在此提請的行為如同追殺，令人不寒而慄。--MCC214（Sign | Contributions） 2025年1月31日 (五) 05:25 (UTC)[回复]
    很抱歉，但是Manchiu的说法实际上并不很准确。光是在这位用户最近的50笔编辑中，就有两笔违反原创研究：1、2，一笔抄袭原文：3。如果阁下认为两周的封禁能够让此用户回心转意，那在下自然是支持这次操作。--人间百态,独尊变态(讨论)(签名) 2025年1月31日 (五) 05:58 (UTC)[回复]
    抱歉，因为扰乱而辗转难眠的人不是造成扰乱的编者，而是需要跟在后面收拾烂摊子的编者。封禁，有效阻止侵犯著作权后我才能睡个好觉。你能把我的简单诉求说成追杀实在是让我大开眼界。我的背上已经有足够多的稻草了，每次在维基百科上看到这样子睁着眼睛说瞎话的行为就像是一个刀片在我的心脏上划过一样。伤害了我对中维编者的信任和期盼，您满意吗？--beef [talk] 2025年2月1日 (六) 09:01 (UTC)[回复]
    聽到這裏和下面你寫的那堆文字，我總算明白你去年提名某個人當管理員的原因了，原來所有的邏輯和某個人一模一樣，不讀條目就要離開維基百科，派翠可夫深明得饒人處且饒人的道理，但你卻沒有，維基百科的用戶身份和社會一樣，有高低之分，你要令其不限期封鎖，相當於以大欺小，人家經你一封，到了站外向着想加入本計劃的人說「維基百科的用戶和管理怎樣嚴格那樣嚴格，機會也不給人啊」，那人家會對這裏的印象會好嗎？為何站外會有類似偽基百科和香港網絡大典那樣批評維百的聲音（另見對維基百科的批評)，按照某個人的邏輯，難道你不想想其中的原因嗎？況且操作者說明其封禁理由所提到很重要的一點是「之後也檢查過他最近的數十筆編輯，並無侵權行為，這種正常編輯與侵權編輯間雜用戶，我不知道他是否了解侵權方針，因此才短期禁止以阻止其繼續添加侵權行為，後續無改善方應施行更長時期封鎖。」，但你不斷強調的是「他以前、現在和將來都只會有侵權編輯」，是不是有點以偏概全呢？而人家用到「我不知道他是否了解侵權方針」這句話，這是假定善意的一種，AGF本身就是我們必需遵守的原則，難道操作者有錯嗎？--MCC214（Sign | Contributions） 2025年2月1日 (六) 09:51 (UTC)[回复]
    按照阁下的逻辑，那咱觉得到不如直接将不限期封禁删除。因为只要我们“不限期封禁”，就可能会有人到站外说维基百科的不好。那还不如让维基百科当个“好好百科”更有利于外宣。--人间百态,独尊变态(讨论)(签名) 2025年2月1日 (六) 10:11 (UTC)[回复]
    請你不要偷換概念，不限期封禁是在極端和非不得已的情況之下才能利用的手段，而不是用來解決任何人（包括阻礙你清理擾亂的人），派翠可夫也說過似乎在他第一次被封禁後的五個月也沒有人Ping過他。這樣的話，時間顯然對事件規模有所影響；而社群是否曾經跟他做好溝通，本人也是有疑問的，你不要假定每個維基人會明白這些有預設文字而蒼白無情的罐頭警告信息，也不要假定每個維基人會在沒有任何人用自己的文字教育別人的情況下很自制地改善自身的問題吧。--MCC214（Sign | Contributions） 2025年2月1日 (六) 10:21 (UTC)[回复]
    那么我挺好奇您认为什么样的行为属于极端和非不得已的情况。而且如果阁下认为现在对于此用户来说比起封禁更需要的是用自己的文字教育别人，那么您是否认同现在就解封此用户并在讨论页对他的侵犯版权行为进行劝导。--人间百态,独尊变态(讨论)(签名) 2025年2月1日 (六) 10:34 (UTC)[回复]
    封鎖和教育本身就是軟硬兼施的手段，兩者必須合理運用，缺一不可，規則也表明「用戶可使用一系列的警告模板用以傳送簡單的罐頭提示，但按情況量身編寫的訊息更佳。封鎖應為最後的手段，管理員應在封鎖違規用戶前確認有關用戶知曉或已獲告知相關的規範，並已給予足夠時間讓其停止不當行為。」，但我看過其的討論頁警告，一是就是罐頭警告信息，一是就是意義不明的自身編寫信息，對於一個維基人來說是無法從中認識到自身擾亂的行為。--MCC214（Sign | Contributions） 2025年2月1日 (六) 10:54 (UTC)[回复]
    感谢您的回复。只是在下仍存在疑惑。按照阁下所引管理员应在封禁违规用户前确认有关用户知晓或已获告知相关的规范，并已给予足够时间让其停止不当行为。，可阁下又说一个维基人来说是无法从中认识到自身扰乱的行为。我是否可以认为之前罐头提示并不符合已获告知相关的规范，从而这个封禁本身就不应该成立。--人间百态,独尊变态(讨论)(签名) 2025年2月1日 (六) 11:16 (UTC)[回复]
    我認為如果給了罐頭信息+自己撰寫的警告無效之後封鎖一個人那才有說服力，才有封鎖一個人的正當理由，而被封的人才會覺得心服口服，但依本站情況來看，似乎只有「發了罐頭信息警告後相關用戶依然故我就封鎖」的常識，而沒有要自身編寫警告信息後相關用戶依然故我才能封鎖的原則（雖然原理上並不能照本宣科，但你不做這個動作似乎不能成為一個封人「無可挑剔且不容置疑」的理由）。--MCC214（Sign | Contributions） 2025年2月1日 (六) 11:34 (UTC)[回复]
    如果阁下认为必须要有自己撰写的警告才有封禁一个人的正当理由，那么我建议阁下去提议修改对应的方针而不是容忍这种常识。--人间百态,独尊变态(讨论)(签名) 2025年2月1日 (六) 11:44 (UTC)[回复]
    我本身的論點就是取自方針，所以並沒有需不需要修改的問題，問題只在你有沒有仔細閱讀相關的內容和明白其當中的含意罷了，總而言之，封鎖一個人要考慮很多事情，包括會不會遇到別人的質疑而已嘛，一個人不考慮清楚到最後就好像Longway22和Wpcpey的事情一樣，封禁者以一個根本就不存在的規則而作封禁理由被質疑，最後因為了避免一案多審和重複封禁，而只能撤銷相關封禁決定一樣。--MCC214（Sign | Contributions） 2025年2月1日 (六) 11:50 (UTC)[回复]
(！)意見：如果純粹從Deadbeef君的角度出發，不限期封禁確實是唯一選項。雖然正式的說法應以「社群」為本位，但也可以看出在這次之前，除了Deadbeef君或者人間百態君之外，沒有人留意過T君的編輯。在這個場合，說Deadbeef君或者百態君的意見可以代表整個社群，並不為過。
另一方面，本人認為在確定是否不限期封禁前，有以下問題要考慮。
第一，「T君恢復權限後一個月即恢復有問題編輯」這事，查閱其貢獻紀錄即可得知；但從這件事至他再被指侵權，好像隔了三、四個月，而本人看他的用戶頁的連入頁面列表，似乎在他第一次被封禁後的五個月也沒有人Ping過他。這樣的話，時間顯然對事件規模有所影響；而社群是否曾經跟他做好溝通，本人也是有疑問的。
第二，Deadbeef君指出，不限期封禁可以令社群毋需再為其可能再次破壞而耗費資源。本人認為，用戶始終是人，不能排除其以濫用傀儡之類的手段作進一步破壞的可能性。當然，維基百科對於這種情況早有表述，就是回退、封禁、不理會，但是這樣一來，社群還是要監察相關條目的情況或者是否有類似形式的編輯出現，而把人封了可能還要尋找新的用戶名，是多了一重工夫。這樣的話，本人承認自己並不知道Deadbeef君這個理據是否成立。
第三，這兩天剛剛有兩名用戶（Ironbolt及Joker Twins）因為對社群的質詢或管理員的封禁表示對抗而被不限期封禁。相比之下，T君被三次封禁都沒有噤聲。雖然不能排除T君拒絕溝通的可能性，但T君亦曾經回覆過他人的Ping，似乎又未必如此。
由於本人未能就以上三點得出明確結論，請恕本人未能即時認同對有關用戶作不限期封禁。然而，本人希望大家就Deadbeef君的理據，以及本人上面提出的三點作出思考，再決定應予何種處理為宜。
以上--派翠可夫 (留言按此) 2025年2月1日 (六) 08:05 (UTC)[回复]
第一，T407210009有充分的机会去了解复制粘贴新闻报道在维基百科上是不可接受的。在其讨论页的留言我就找到版权相关的提醒：[20][21][22]。对于他人在其讨论页的提示，他一次都没有回复或表现出了解，反而你去说社群没有做好沟通？是请问中文维基百科应该围绕着T407210009才行吗？
第二，根据既往贡献可以得出：T407210009若重返编辑，几乎必然会持续侵犯著作权，而一般用户受WP:ABK功能影响下根本没有实际创建傀儡的技术。我严重怀疑你这种态度是站着说话不腰疼，不论是所谓封禁之后需要「监察相关条目或相似编辑」、「寻找新用户名」，或是没封禁时及时查核并清除侵犯著作权内容，我都没见你参与。请问WP:编者著作权调查/T407210009下你要不要来打扫一下呢？对实际情况不清楚，你又有什么依据得出「封禁后反而更多消耗社群时间」这样的言论呢？
第三，我见过这个差异，但是令人感到荒谬的是你能觉得从2023年11月编辑到2025年1月的历史中，只要有一次回复他人的留言或Ping就能算「并非拒绝沟通」。
对于这种编者产生圣母或拯救情结，实际是在对于辛苦总结来源中的内容从而写条目的编者不尊重、对于不知疲倦巡查最近更改的编者不尊重、对于耗费二十多分钟只查核了4个潜在侵犯著作权差异的编者不尊重。多共情干正事的编者，少共情不干正事的编者。--beef [talk] 2025年2月1日 (六) 08:55 (UTC)[回复]
如果本人不體諒、不尊重您，本人就不會寫下引言（即認為即使您的主張能代表整個社群亦不為過）以及第二點（提問不限期封禁是否能杜絕下次這種麻煩），也不會使用{{意見}}（而非任何反對模板）了。
一、您舉的三個連結是7月封禁之前的事，本人也有看到，但承認自己是集中在後面的事態發展，因為您提出覆核的是前幾天的封禁；而有關著作權調查之所以這麼長也是因為事情累積了五個月。本人說社群沒有好好溝通或留意，換個說法也可以是本人認為，事情搞到要您（和百態君）這樣辛苦地調查，是社群對您（們）不起，如果能夠更早留意和使他回應（如前所言，也不是沒有成功的例子），可能不用等到現在就已經能作出更有效的手段。
二、如果已有機制能防止用戶在被不限期封禁後濫用傀儡，那本人沒有其他問題。
三、如前所言，本人「……不能排除T君拒絕溝通的可能性」。您指本人認為他「……並非拒絕溝通」，並非事實，惟本人也想指出有其他可能性。您身為最直接受影響者，當然有最大的理由對此不表認同，但請不要隨便用「荒謬」來形容其他不是您預期內的意見。
事實上，本人沒有認為自己提出的幾點一定有效，相反更多的是本人認為自己有些地方不明白而已。本人承認在您找Manchiu時已經開始嘗試調查和思考，如果結果不能令您滿意，本人謹此致歉，但希望您不要預設本人的立場。
最後關於完成T君的著作權調查，本人承認自己不知道怎樣做才對（本人擔心自己犯錯，尤其是擔心自己作出偽陰性結論），本人可以私下請教您具體做法嗎？--派翠可夫 (留言按此) 2025年2月1日 (六) 09:43 (UTC)[回复]
已在你的讨论页下留言，稍后我会将更完善的教程写到一个用户子界面上。--beef [talk] 2025年2月1日 (六) 10:37 (UTC)[回复]

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

多天已無新留言，且僅有提案人支持，視無共識關閉之。--SCP-0000（留言） 2025年2月16日 (日) 11:43 (UTC)[回复]

不見僅有提案人支持，建議重開。--（☎）dt 2025年3月22日 (六) 18:52 (UTC)[回复]
被提报人疑似被傀儡封禁，此案再讨论无意义。个人认为关闭存档掉或许可行。--花开夜 留言 ·签名 ·贡献 2025年4月10日 (四) 09:37 (UTC)[回复]
(！)意見單是我打掃的44個條目中就有26個條目（其中兩個他創的檢查後被我直接丟版權驗證）有侵權，當初的封禁兩週真的太少......--VAMPIRE VAMPIRE VAMPIRE!!!（留言） 2025年4月12日 (六) 15:42 (UTC)[回复]

(！)意見：目标用户已因滥用傀儡被不限期封禁多日且仍在创建新傀儡，已无解封可能，无需换个灯泡。--此條未正確簽名的留言由Python6345（討論｜貢獻）於2025年4月2日 (三) 12:49 (UTC)加入。[回复]

社群對於此一封鎖，傾向認為原先一月二十六日封鎖，時長或有不妥，應斟酌當事人過往貢獻性質予以加長；與此同時，尚曾指出過往與當事人溝通可能不足，而對於是否直接改為無限期封鎖，正反意見則多有辯駁，未見絕對共識形成。惟當事人自一月五日首遭封鎖後即無任何編輯，迄後再因分身帳號故而別遭無限期封鎖，今已殊難確證有關封鎖時長不妥之指控，且純以後見之明檢討此一操作是否適當並無意義，故不予覆核而結案。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月28日 (一) 09:22 (UTC)[回复]

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

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

本主題或以下段落文字，在討論結束後應存檔至Wikipedia:管理操作覆核請求/存檔。

已解決
鑑於社群共識及本人意見，認為有關操作不妥，並予以推翻。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月28日 (一) 09:30 (UTC)[回复]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

此請求是根據Wikipedia:管理操作覆核請求所提出，請先閱讀相關內容。

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

看到之前的管理操作复核请求通过了，而且Tisscherry君说过：我當時是以為，因為自由雨日和我有互相宣稱，如果其中一人被封鎖，那請連帶處理，類似這樣的發言（我沒去找diff，晚點想到再找）我想Ericliu管理員是看到了，故我當時欣然接受沒有其他意見。以此邏輯，自由雨日申請操作覆核，我會跟隨( ✓ )同意和(＋)支持。基本上我尊重管理員判斷，但我希望他若要做出說明，請儘量使用淺顯易懂的文字，維基百科不是官僚體系，不要刻意畫線拉距離。--提斯切里，但因二人之复核背景略有不同，因此需要另开一笔复核。副知@Tisscherry、自由雨日。 --Пусть от победы☆к победе ведёт! 2025年2月4日 (二) 04:28 (UTC)[回复]

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

多天已無新留言，且僅有提案人支持，視無共識關閉之。--SCP-0000（留言） 2025年2月16日 (日) 11:47 (UTC)[回复]

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

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

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

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

本人承認此一操作以今日情況視之或有不妥，且社群就互動禁制行使要件似略有共識，我想就不必浪費諸位時間及客棧篇幅，自行覆核而推翻為宜。但仍想重申，彼時局勢詭譎，本人不認為有關操作無助於降低雙方（或其他各方）衝突，而單向互動禁制不過是獨許某方發言，亦難稱絕對公平。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月28日 (一) 09:30 (UTC)[回复]

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

@Ericliu1912：請問閣下所言「覆核」是否指「推翻決定」？「覆核」指「審查核對」，正是本討論串存在的目的，即讓社羣參與這一「審查核對」過程，故不爲討論關閉的理由。再者「管理員在所牽涉事宜中應避嫌」，如此逕行關閉，恐怕不合方針本意。建議閣下重開本覆核案，在操作完成後彙報社群，由另一管理員核對閣下的操作是否符合本次共識。副知@阿南之人、Tisscherry、自由雨日。1F616EMO（喵留言～回覆請ping） 2025年4月28日 (一) 09:59 (UTC)[回复]

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

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

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

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

我認為目前Mediawiki保護的名稱不夠準確、且圖標無法同模板保護區分。希望能改成較為直觀的「介面保護」等名稱，並設立相關圖標。如有共識可設立相關投票。--WiiUf 2025年3月8日 (六) 04:38 (UTC)[回复]

(＋)支持--August討論‧簽名 2025年3月8日 (六) 04:45 (UTC)[回复]
不能認同介面保護的名稱。該名稱拋棄該保護的本質原理，易導致後續含義失準。此外，由MediaWiki自動施加的JSON保護亦為此保護，但JSON不應視作影響介面。--MilkyDefer 2025年3月9日 (日) 15:30 (UTC)[回复]
Mediawiki其实就是系统配置文件，那么叫做「系统保护」应该会比较合适。Bluedeck 2025年3月10日 (一) 06:43 (UTC)[回复]
这个名字还不错。--碟之舞📀💿 2025年4月6日 (日) 03:24 (UTC)[回复]
@August.C@Bluedeck@Diskdance@MilkyDefer若無異議， 公示48小時，稍後將舉行投票。--WiiUf（留言） 2025年4月6日 (日) 09:24 (UTC)[回复]
@August.C@Bluedeck@Diskdance@MilkyDefer投票頁面已建立。--WiiUf（留言） 2025年4月7日 (一) 14:35 (UTC)[回复]
反對投票... 目前社群有人反對「系統保護」嗎？為什麼不討論出共識而要投票？--Aqurs 2025年4月7日 (一) 14:38 (UTC)[回复]
我想组织投票是因为有类似先例（之前决定各类保护用名及图标都用的是投票）。--WiiUf（留言） 2025年4月8日 (二) 10:12 (UTC)[回复]
同Aqurs，可以用共識通過的就不必投票了--August討論‧簽名‧回復請ping 2025年4月7日 (一) 14:41 (UTC)[回复]
(▲)同上，反對投票。既然投票的本質其實是問卷，常規共識方法能夠解決之事，何必訴諸投票？--1F616EMO（喵留言～回覆請ping） 2025年4月7日 (一) 14:44 (UTC)[回复]
投票是共识达不成退而求其次的方案，这里大家并没有达不成共识吧。--碟之舞📀💿 2025年4月8日 (二) 10:09 (UTC)[回复]
所以這種保護究竟能保護什麼？若像諸位所說，似乎Bluedeck建議的「系統保護」是個好方案。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月28日 (一) 09:39 (UTC)[回复]
公示7日，2025年5月6日14：22（UTC)通过。--WiiUf（留言） 2025年4月29日 (二) 14:20 (UTC)[回复]
@WiiUf：新圖標在什麼位置？？--Aqurs 2025年4月29日 (二) 14:26 (UTC)[回复]
公示的方案是？界面保护还是系统保护？以及下次公示请一并更新Template:Bulletin。——ZhaoFJx(Talk) 2025年4月29日 (二) 15:35 (UTC)[回复]
抱歉，重新公示“系统保护”名称7日，2025年5月6日23：35（UTC）结束。--WiiUf（留言） 2025年4月29日 (二) 23:32 (UTC) 👍1[回复]

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

本主題或以下段落文字，在討論結束後應存檔至Wikipedia:管理操作覆核請求/存檔。

此請求根據Wikipedia:管理操作覆核請求提出，請先閱讀相關內容。
操作： 结案存废讨论
执行者： Wcam （討論 · 貢獻 · 日誌）
先前讨论：https://w.wiki/DNAS

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

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

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

引入臨時帳戶功能後，誰應該能夠看到 IP 位址？

透過臨時帳戶，我們可以用新的唯一識別碼替換未註冊編輯者的 IP 位址。此次更改後，未註冊編輯者的 IP 位址將不再對外開放。我們做出這項改變是為了加強對安全和隱私的支持，以確保我們的貢獻者繼續感到安全。

另一方面，在某些情況下，保護維基媒體專案（打擊垃圾郵件、破壞行為、騷擾等）的使用者需要查看未註冊編輯者的 IP 位址才能有效地進行工作。為了平衡這些需求，我們的政策是繼續向某些使用者提供臨時帳戶 IP 位址的存取權限，使用下面描述的流程。

在今年稍後我們在 本 wiki 上推出臨時帳戶之前，我們需要明確誰可以查看臨時帳戶的 IP 位址。我們希望徵求您的意見。

問題

目前，該權限會自動授予以下使用者：

  1. 擁有擴充權限（例如管理員、CheckUsers、全域系統操作員、監管員——請參閱政策以取得更多範例）
  2. 沒有擴充權限，但其本地帳戶至少已使用 6 個月，並且對本地專案進行了至少 300 次編輯。

我們的問題僅僅與#2有關。在任何維基媒體專案上部署臨時帳戶之前，我們已經選擇了這些數字閾值。然而，我們清楚地認識到，這些門檻相當低，惡意行為者仍然很容易取得臨時帳戶 IP 位址。我們聽到了多個社群對此的擔憂，包括第一批試點社群。我們希望臨時帳戶能夠真正改善編輯者的隱私，因此在擁有大型社群的維基上推出此功能之前，我們需要採取更嚴格的限制。

在與管理員、一些試點維基媒體專案的社群成員以及活躍於英語 Discord 的社群成員就其他選擇進行磋商後，我們希望在最終確定這項變更之前得到您的回饋。

我們的新方法

我們建議沒有擴展權限的使用者可以申請查看臨時帳戶的 IP 位址的權限，由管理員或監管員決定是否授予權限。我們的目標是更一致地限制 IP 位址存取權限，僅允許需要存取 IP 位址的人存取。這將需要人工操作，但與我們繼續自動授予權利相比，負擔應該會更小。

當我們將臨時帳戶部署到更多維基媒體專案時，我們可以評估其影響並根據需要調整我們的方法。

這將如何運作

  • 當沒有擴展權限的使用者需要查看臨時帳戶IP位址時，需要申請加入「臨時帳戶IP查看者」群組。他們會向管理員（當地社群將能夠決定該流程）或監管員（對於沒有當地管理員的維基媒體專案）提交請求。
  • 該功能要求使用者至少有 300 次編輯且帳戶使用時間至少為 6 個月。管理員和監管員將無法向不符合該標準的帳戶授予臨時帳戶 IP 存取權限。這是最低限度，我們鼓勵社群——特別是較大的社群——執行更高的門檻。根據臨時帳戶試點社群的評論，我們建議至少將 600 次編輯作為門檻。
  • 審查請求的使用者將檢​​查申請權利的使用者是否符合要求以及是否提供了有效的理由。權利本身將透過 Special:UserRights 授予。
  • 授予權利請求的使用者同時將擁有刪除處理的權利。

請注意，存取 IP 資訊功能的要求與存取臨時帳戶 IP 位址的要求相同。

我們考慮過的其他選項

我們考慮過一系列選項，包括：

  • 僅向具有擴展權限的使用者授予權利。
    • 優點：從使用者安全的角度來看，這是理想的，因為只有經過社群審查的使用者才能獲得存取權限。  
    • 缺點：限制性太強。許多巡查活動都是由沒有擴展權限的編輯進行的。如果我們這樣做，就會增加具有擴展權限的使用者的巡邏負擔。
  • 增加編輯次數和/或帳戶年齡的門檻。該權利仍將自動授予。
    • 優點：從技術上來說，這是一個簡單的改變。
    • 缺點：惡意編輯者取得臨時帳戶 IP 的風險仍然較高。惡意使用者可以在自動化工具或腳本的幫助下達到任意閾值計數，無論多高。這同時將使小型專案的善意編輯更難透過常規編輯獲得此存取權限。

我們的問題

  • 新的提案是否充分解決了隱私問題？
  • 當我們執行這項政策時，是否應該知道這會對您的社群產生什麼影響？我們希望在 2-3 週內更新該政策。


在接下來的幾週內，我們將向您提供有關臨時帳戶和相關功能的更多更新資訊和素材。

我們在此再次感謝所有幫助我們找到不同選擇的成員。如果您希望了解有關該專案的更多信息，請閱讀 Diff 部落格，訪問我們的專案頁面和常見問題解答。請訂閱新聞通訊以保持聯繫。謝謝！NKohli (WMF) 與 SGrabarczuk (WMF)（留言） 2025年3月11日 (二) 23:45 (UTC)[回复]

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

小結

@Ericliu1912、人间百态、YFdyh000、LuciferianThomas、Akishima Yuka、Aqurs1、ZhaoFJx、Steven Sun、Python6345、Saimmx：依照上方討論，社群似乎傾向支持500次編輯以上（參照延伸確認用戶（extended confirmed user））及帳戶使用時間至少6個月（基金會方針規定）才能獲得「臨時帳戶IP檢視者」（Temporary Accounts IP viewers）權限。而 SGrabarczuk (WMF) 指出（見上留言），儘管延伸確認用戶與「臨時帳戶IP檢視者」的申請門檻相近，但其用途並不相同，故不建議採用相同的門檻（即500次編輯）。我個人認為或可考慮採用回退員（Rollbacker）的門檻（即1000次編輯）？

再者，除編輯次數這門檻外，要求申請者說明有反破壞等實際需要，帳號最近一年內未有被封禁；且需透過人手授予（參見「我們考慮過的其他選項」段落），這幾點應該沒太大意見？副知所有曾參與討論的編者。謝謝。--SCP-0000（留言） 2025年4月26日 (六) 03:40 (UTC)[回复]

支持試用初期人工授予，反對永久，不過這可以之後再談。另外巡查及回退用戶組必須包括此權限。--Aqurs 2025年4月26日 (六) 04:41 (UTC)[回复]
@Aqurs1：巡查員的申請門檻為編輯至少250次和參與本站至少30日，不符基金會方針規定的臨時帳戶IP檢視者的最低要求。個人認為巡查員的門檻至少應提升至與本站的臨時帳戶IP檢視者相等要求，如果只符合基金會方針但不符本站要求，未免有人借巡查來得到檢視臨時帳戶IP的權限。謝謝。--SCP-0000（留言） 2025年4月26日 (六) 05:17 (UTC)[回复]
如果申請人有擔任巡查的資格，個人認為不應該剝奪其檢視IP的權利。刻意借巡查而檢視，但又沒有應有的能力，自然可以雪球關閉。--Aqurs 2025年4月26日 (六) 06:02 (UTC)[回复]
「如果申請人有擔任巡查的資格，個人認為不應該剝奪其檢視IP的權利。」然而在基金會的方針下，基本上只有兩個解決方案：一、將巡查的申請門檻提高；二、檢視IP的權限不包括在巡查員，而需另外申請。不然會出現申請人有擔任巡查的資格，但因不符基金會方針要求而不能授予巡查之情況發生。謝謝。--SCP-0000（留言） 2025年4月26日 (六) 06:36 (UTC)[回复]
是否預設開放回退員持有此權限（我不確定有沒有這回事）？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年4月26日 (六) 07:53 (UTC)[回复]
@Ericliu1912：個人較早前在英文 Discord 詢問將檢視臨時帳號IP的權限加入至現有權限組（如回退員）的可能性，對此基金會的開發人員回應稱，他們不願這樣做，這會令現有權限組的用戶因存取臨時帳號IP（即非公開個人資訊）而承擔額外風險，而那些用戶並未對此表示同意（consented to）。
但如果是自動為回退員增加「臨時帳戶IP檢視者」權限組的可能性，考慮到他們似乎有相應 global script，似乎未必不行就是了，但我需要詢問一下。謝謝。--SCP-0000（留言） 2025年4月26日 (六) 10:22 (UTC)[回复]
剛才 Aqurs1 在英文 Discord 詢問能否為現有權限組的用戶（如回退員）自動授予「臨時帳戶IP檢視者」，得到的回應是法律上並不可行。似乎現在還需要討論的只有編輯次數這門檻？謝謝。--SCP-0000（留言） 2025年4月26日 (六) 17:30 (UTC)[回复]
以下提议条件为在基金会要求基础上新增，符合任意一项管理员即可授权：
  • 甲：需编辑至少600次，最近一年内没有受到封禁（不合理封禁除外），於反破壞工作中保持活躍。
  • 已：需已是巡查员或回退员，最近一年内没有受到封禁（不合理封禁除外），於反破壞工作中保持活躍。
  • 丙：需已是傀儡调查助理，最近一年内没有受到封禁（不合理封禁除外）。
Python6345（查论编） 2025年4月26日 (六) 17:51 (UTC)[回复]
@Python6345：個人認為可簡化成這樣：
申請者需符合基金會方針的最低要求，且需符合以下任一條件
  1. 需編輯至少600次，最近一年內沒有受到封鎖（不合理封鎖除外），且活躍於反破壞工作，或有其他存取臨時帳號IP之需要。
  2. 現任巡查員、回退員、傀儡調查助理、過濾器助理或過濾器編輯者，最近一年內沒有受到封鎖（不合理封鎖除外）。
不知意下如何？謝謝。--SCP-0000（留言） 2025年4月27日 (日) 07:22 (UTC)[回复]
无异议。Python6345（查论编） 2025年4月27日 (日) 12:40 (UTC)[回复]
7日无新留言，准备公示？Python6345（查论编） 2025年5月4日 (日) 03:41 (UTC)[回复]
异想天开，能不能把當前回退员变成一個祖父用户组「回退员（旧）」，新设「回退员（新）」 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年5月3日 (六) 17:10 (UTC)[回复]
這有點異想天開了（--SCP-0000（留言） 2025年5月3日 (六) 17:31 (UTC)[回复]

2025年4月管理人员选举

本主題全部或部分段落文字，已移動至Wikipedia talk:申请成为管理人员。执行者：Jimmy-bot（留言） 2025年5月6日 (二) 00:14 (UTC)。[回复]

非洲月

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:維基百科非洲月/2025。

非洲月按例应於5月举行，兹讨论筹备事项。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年4月16日 (三) 03:31 (UTC)[回复]

私以为按往例推迟至6月更为妥当。6月中、下旬大部分学校已放暑假，有利于学生维基人投入更多时间撰写条目。比起不在6月举报的2022年非洲月，后两次的条目产出要多50%不止。反观主题相近但不与任何假期（大陆国庆黄金周不算）的拉美月历年参与人数皆寥寥，两次都不到100篇，而同年的两次非洲月都有三位数的条目产出。——Mirfaek 2025年4月16日 (三) 05:59 (UTC)[回复]
但非洲月完接動員令這樣好嗎?--Kanshui0943（留言） 2025年4月16日 (三) 06:50 (UTC)[回复]
最好不要辦活動這麼急促，非洲月完這樣馬上就要動員令了。--August討論‧簽名‧回復請ping 2025年4月16日 (三) 13:56 (UTC)[回复]
但是如果考虑到学生维基人编辑的话那么可能七月上/中旬会更合适？届时大部分有志于参加活动的学生维基人都已经有了足够的时间参加活动，这样一来也许能够有更多成果也说不定︴FujiwaraReisen（留言） 2025年4月17日 (四) 05:35 (UTC)[回复]
也可以移到1、2月避免與動員令對撞--Kanshui0943（留言） 2025年4月17日 (四) 12:09 (UTC)[回复]
已经有动员令为暑假服务了。中文维基百科不是也不能是繞着学生转的。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年4月17日 (四) 12:44 (UTC)[回复]
同意各位的观点，如今年非洲月于5月举办，应立刻开启主持人招募。——Mirfaek 2025年4月18日 (五) 00:24 (UTC)[回复]
查看過往討論，推遲到6月舉行似乎很大程度是由於在5月才有人發起討論而未能趕及而已，基於非洲月本來的意義，建議重新安排在5月舉行。--AT⊿⁴⁶ 2025年4月17日 (四) 14:35 (UTC)[回复]

主持人招募

烦请有意担任主持人者在下方留言示意。——Mirfaek 2025年4月18日 (五) 00:26 (UTC)[回复]

+1--Kanshui0943（留言） 2025年4月18日 (五) 12:34 (UTC)[回复]
似乎没什么人来，那我也参与主持。——Mirfaek 2025年4月19日 (六) 06:46 (UTC)[回复]
+1--蕰川｜公路 2025年4月21日 (一) 05:23 (UTC)[回复]
我今年可以来帮忙，虽然可能要赶毕业论文，但抽时间评审条目的时间应该是有的--—프라돈스타✍️ 2025年4月23日 (三) 01:28 (UTC)[回复]
+1。Iming 彼女の愛は、甘くて痛い。 2025年4月23日 (三) 10:46 (UTC)[回复]
Wikipedia:維基百科非洲月/2025頁面已創立，部分尚未創建之模板以註釋隱藏。fountain部分已創建草稿等待管理員審核。本人已將諸位列入主持人--Kanshui0943（留言） 2025年4月27日 (日) 16:28 (UTC)[回复]
事態緊急我還是直接ping吧@KOKUYO@Ericliu1912@Manchiu--Kanshui0943（留言） 2025年4月27日 (日) 16:37 (UTC)[回复]
done.--SCP-0000（留言） 2025年4月28日 (一) 02:57 (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相比差得远。
— [23]

这样一句话，我觉得有点危言耸听，不能一个人随便吹牛说大话就能让整个社群人心惶惶吧。--beef [talk] 2025年5月1日 (四) 02:22 (UTC) 👍1[回复]
想問下查核日誌（不包含敏感資訊的）有公開給所有人查看的可能嗎？--Elvaaae（留言） 2025年5月2日 (五) 15:25 (UTC)[回复]
或许可以，但是难以设计。比如说如果只公开针对用户的查核日志，也有可能会公开链接账户和IP地址的联系，我觉得我们应该先讨论一下让选举出来的查核员互相监督是否可行，又或者可以由其他方案，例如设立新的用户组仅有只读权限起到监督的作用（然而实际上只读权限需要的信任也是很高的）--beef [talk] 2025年5月3日 (六) 02:38 (UTC)[回复]
我說難聽一點啦，你翻牆出來本來就要保護好自己了，就算沒有CU人家想抓你依然有辦法抓好嗎...--SunAfterRain 2025年5月2日 (五) 03:31 (UTC)[回复]
且不説翻墻的中國人怎麽樣，很多香港使用者本就沒有用VPN編輯你維的習慣好嗎--Elvaaae（留言） 2025年5月2日 (五) 15:26 (UTC)[回复]
@Elvaaae：這個我真的只能說自己的國情就是那樣請多小心，如果你自己都不注重保護自己的話就算基金會今天下了一百道保護也攔不住政府搜到你--SunAfterRain 2025年5月3日 (六) 14:45 (UTC)[回复]
@SunAfterRain 嗯，那监督员也不应该删掉侵犯隐私的内容，毕竟是“你自己不小心被人肉的”；基金会也不应该OA2021，毕竟保护自己是你自己的事；可供查证方针也应该取消，因为上维基的人应该学会自己辨认内容的真实性--103.196.21.39（留言） 2025年5月3日 (六) 13:43 (UTC)[回复]
請不要自己無限上綱。--SunAfterRain 2025年5月3日 (六) 14:45 (UTC)[回复]
如果是僅因需要監票的話，那可以考慮另設立electionadmin（監票員）而非直接引入CUer。在當前SPI轉交元維基查核沒有系統性問題的情況下，無需僅因監票（畢盡CUer也不是只監票而已）而將之前已證明有問題的體制重新引入。WP:沒壞別修（指SPI）。--（☎）dt 2025年5月2日 (五) 00:07 (UTC)[回复]
@ATannedBurger：我記得你說的這個監票員是被技術問題本地安全投票的任務卡住了--SunAfterRain 2025年5月2日 (五) 03:29 (UTC)[回复]
英文維基百科那邊正在討論，等他們討論完，技術阻礙應該就清得差不多了。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月2日 (五) 15:49 (UTC)[回复]
「之前已證明有問題的體制重新引入」當基金會已經處理了 WMC 相關用戶時（且 OA2021 已是四年前的事），他們也願意讓社群重新引入 CU 時，那還有什麼潛在的問題社群尚未解決？謝謝。--SCP-0000（留言） 2025年5月2日 (五) 15:53 (UTC)[回复]
您如果要認為這種事是偶發性事件也罷，雖然我自己是比較沒有信心就是了。一次（2017）還好說，兩次（2017 + 2021）恕我沒辦法認為不存在系統性的問題，而系統性的問題（你要把這個稱為「特定群體對CU的不信任」也好，雖然我認為這是表現出的結果，不是問題本身）可不是只能靠處理幾名使用者解決的。
我認爲的問題無非就是當前CU當選門檻過低且缺乏監管（監管員有申訴專員定期監督，申訴專員則是直接由WMF指派），當然我也認知到有其他問題我先前是還沒想到的，比如上方提到的隱私，以及對CU數據洩露0容忍的立場。「如何客觀的確保CU數據不會被洩露，尤其是在缺乏CU本身公開透明的情況下」這我認為是個很好的問題。--（☎）dt 2025年5月2日 (五) 17:26 (UTC)[回复]
基金会将会定期稽核中文维基之用户查核活动至少一年，此举包含一年后是不是要继续持续这样的稽核机制等 - WMF都说他们愿意监督中维的查核使用，为什么不可以引入CU呢？
你所说的系统性问题，究竟是什么系统性问题？据我所知，我们现在讨论的是可否引入CU，而不是如何引入CU，「当选门槛过低」是第二阶段的问题，见我RfA的留言。
如何客观的确保CU数据不会被泄露，尤其是在缺乏CU本身公开透明的情况下 你觉得这是一个合理的问题吗？没错，只要没有本地CUer，那么本地CU数据就不会泄露给除监管员或其他全域权限用户之外的人。至于CUwiki上的远古中维数据，也是任何项目的CU都可以访问，反正不讲中文的人获取本地数据我们无所谓，只要说中文的人中维社群就不信任了吗？
公开透明与数据泄露又有什么关系呢？「公开透明」的理由还能说成「为了防止数据泄露」吗？
既然大家都是人类，我们是在人类与人类之间的对话，我就这样和你说吧，不管怎么样你都无法防止数据泄露。唯一的方法就是选出社群足够信任的用户。但是，抛开有没有能被社群信任而担任CU的用户不提，对于本地引入CU你还有什么意见吗？--beef [talk] 2025年5月3日 (六) 02:48 (UTC)[回复]

由於討論已偏離到私人恩怨，本框内討論文字已關閉，相關文字請在本頁面保留並不再編輯。
如有異議，請諮詢互助客棧或其他管理員。執行人：--SunAfterRain 2025年5月5日 (一) 02:52 (UTC)
真不知道您是在急甚麼，急到只選擇性回覆部分的論點，其餘的則被隨意歸類為屬於「如何引入CU」。我認為呢，在我上方提到的問題沒有得出對應且可被接受的解答前 (不論事實上還是方針而言) 是不能引入CU的。另外，我並沒有要把CU搞公開透明的意思。儘管我不曾擔任過CUer，但作為SPI助理也是略懂一二這方面的紅線。
還有，我不認為這樣拆成幾個階段的方式是好的。像我的話一旦到了某個環節就會反對，然後可能因那項的相對多數搞到出局，但這種事對我來說是個dealbreaker (指沒這個我就反對設立了)。環節越多，越多這樣的情況就會發生，最後導出你或許like但不一定代表多數的結果，因為反對意見都在這個過程中被逐漸filter掉了，這也是為甚麼我認為儘管ARBCOM是有經過討論，有你口中的「共識」，但到實際執行的時候不少用戶仍有微詞的原因。--（☎）dt 2025年5月3日 (六) 03:17 (UTC)[回复]
真不知道您是在急什么，急到只选择性回复部分的论点 我的天哪，为了防止我第二次被你在讨论社群程序时的发言恶心到而导致我又没有心态去参与中维社群讨论，以后只要有你参与的讨论我都不会发言了，很抱歉，但是我实在看不出任何其他的办法。一而再再而三地顾左右而言他，说话说不到重点上，我真的受够了。--beef [talk] 2025年5月3日 (六) 15:02 (UTC)[回复]
毕竟能写出 你那时候又在做什么？的，今天便能说我很急。那你跟不急的人讨论吧。你也说了，一次还好说，两次就没办法了。没错，我2024犯了认为和你能正常、心平气和、就事论事讨论的错误，那么2025再犯一次我就知道不会再犯了。--beef [talk] 2025年5月3日 (六) 15:25 (UTC)[回复]

哎呀這說到底還是道德問題，雖然我很不想這麼說，社群應該也挺多人不會認同我這個觀點的。我為什麼說是道德問題呢?因為規則是死的人是活的，人只要自身道德上的自制力不夠高，一旦處在陰影下或規則無法顧及之處，又有特定誘因(如達成某種目的)，此時隱私洩漏問題就很容易發生，至於規則無法顧及之處，當規則寫的不夠全面，一或者是文字上可以以另外一種方式解讀，此時就會出現「文字遊戲」這種情況。：（
申明一下：我不是說規則不重要。--~~Sid~~ 2025年5月3日 (六) 14:02 (UTC)[回复]
剩下恢復信任的心理建設吧？因為終究是人身安全問題，難以用所謂理性徹底排除疑慮。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年5月5日 (一) 12:55 (UTC)[回复]
回到我先前的論點，我自己是高度懷疑因監督員的職責明顯跟「監票」不相關，純粹請求有簽署NDA的監督員擔任此工作，導致參選監督員的候選人需要回答「CU技術性問題」也不理想所以需要引入CU的必要性。你要說這是純粹的心理建設不足也罷，起碼我認為我下面提到的方案接受度會比較高一些。先一步一步來，試試水溫也好。--（☎）dt 2025年5月5日 (一) 16:14 (UTC)[回复]
這可以算是其中一個推動的原因，但是引入CU是不必要嗎？你沒有提出合理原因去表達這是不必要，終究是「過去的人有問題不代表體制有問題」。如果你說引入CU有什麼必要，可以自行去看一下SPI現在處理得有多慢。--Aqurs 2025年5月5日 (一) 16:24 (UTC)[回复]
現在SPI處理慢的原因不是因為監管員不願查或不活躍（監管員通常在轉交後24小時內就能給出結果，除非需要更多資訊），而是因為本地助理人手不足以儘速轉交請求，請先搞清楚真正的問題在哪裡再拿出來說。就算有本地CUer，在助理人手不足的情況下仍無法有效提高SPI處理效率。--（☎）dt 2025年5月5日 (一) 18:36 (UTC)[回复]
本地CU當然可以直接接受/拒絕查核請求。。。至少比現在要助理審核一次，然後轉過去元維基效率來得更高。這反倒是取決於CUer辦事能力，你沒有回答我為什麼引入CU是不必要。--Aqurs 2025年5月6日 (二) 02:36 (UTC)[回复]
我認為在此處提起是否需要CU是殺雞焉用牛刀...另設electionadmin反而是更practical的解決辦法，這樣清楚了麼。你提到的處理SPI效率來的更高也並不代表引入CU具有必要性。
監票並不是只能CUer來做，也不存在「參選監督員的候選人需要回答「CU技術性問題」也不理想...[所以]本站是否有重新引入CU的需要」這一命題，參選人在選監督員前應當清楚監督員當前的職責，而非事後因候選人自身的能力不足，反而對制度進行全方面的檢討。當初社群決定監督員來負責監票或許事後看來是個無奈之舉，但不代表為了監票就應該引入CUer。
然後你說是因為SPI處理慢好了，請問一下假設我現在去SPI把所有請求都處理了 (該轉交meta的轉交meta，該請管理處理的掛請管理處理)，那是不是就不用引入CU了呢？--（☎）dt 2025年5月6日 (二) 03:32 (UTC)[回复]
你的不信任源自於過去曾經發生「數據洩漏」事件，但是用戶查核這一套系統有問題嗎？所有有用戶查核權限的用戶都有可能會泄露數據，偏偏只有貴站會有這一問題？你上面說CU欠缺監管，WMF都會來親自監督了，你的不信任難道不就是你的偏見嗎？--Aqurs 2025年5月6日 (二) 03:52 (UTC)[回复]
我總覺得你還卡在「我不信任CU」這種偏見來看我的言論。不過說真的，我能叫你不要這麼做嗎？CU有沒有問題不代表本地需不需要。--（☎）dt 2025年5月6日 (二) 04:15 (UTC)[回复]
設立「electionadmin」的問題是監票得到的資訊是跟用戶查核一樣，那麼不是同樣會有泄露的風險嗎？為什麼你認為「換了個包裝」就代表安全呢。--Aqurs 2025年5月6日 (二) 03:54 (UTC)[回复]
可差的多了，沒投票的話就不會被記錄相關資訊。使用者查核可是只要一登入就會被記錄相關資訊了。這不僅是換了個包裝，連內容物都不一樣了呢。--（☎）dt 2025年5月6日 (二) 04:12 (UTC)[回复]
根據本地WP:CUP#1下列出的所有方針，若引入本地用戶查核，所有使用用戶查核的情況都必須在WP:SPI提出，完全無法發生用戶查核員隨便獲取任何人的IP位址資訊的現象，本地的其他用戶查核員會時常關注查核日誌並檢查每一次查核是否有理有據，所以若發生濫用查核權的現象相信能夠很快發現。請看一下上面的內容，恕至少個人認為純監票的風險跟用戶查核沒兩樣，甚至更高。--Aqurs 2025年5月6日 (二) 04:16 (UTC)[回复]
我是覺得沒有可比性。純監票只有在選票投下的時候才會看的到投下選票當下的技術資料，而使用者查核能看到查核當下過去90天的所有資料。--（☎）dt 2025年5月6日 (二) 04:26 (UTC)[回复]
監票員（即你提出的electionadmin）有權限查閱「投下選票當下的技術資料」就代表有泄露的風險吧，風險是對等的，不是說這資料重要度較低就沒有風險。那麼如果「引入CU有信任問題」，為什麼社群會信任監票員？不認為這是更practical的解決方法。--Aqurs 2025年5月6日 (二) 04:33 (UTC)[回复]
本地需要監票人(不管是現在的監督員、之後的監票員或CUer）來報選票。Practical指的是這個不會囊括其他當前不需要用的權限這樣的practical。
如果是要解決監督員的選票問題的話，那就是分拆監票員，專門報選票。
如果是要含括SPI的話，那就是CUer。
至於說SPI看的到的資料和安全投票看的到的資料的差別，我上面已經提到了。要不然就是將監票正式列入監督員的responsibility。
當然，如果本地要放棄安全投票的話，那不妨也是個解決方式。--（☎）dt 2025年5月6日 (二) 04:50 (UTC)[回复]
重點其實是如果本地信任引入CU的話就應該引入去處理「監票+SPI」，不信任的話沒問題，但不應該弄一個新用戶組去監票或是讓監督負責這工作。--Aqurs 2025年5月6日 (二) 05:02 (UTC)[回复]
儘管我認為監票和SPI還是有本質上的不同，但同意你不應該弄一個新使用者群組去監票或是讓監督負責這工作的結論。@Elvaaae：你覺得呢？貌似不能既要又要的樣子。
其實也可以根據這點重新再辦個投票 (不管是否要用安全投票來進行投票)，我記得最初談及是否該啟用安全投票的時候，最後也是透過投票的方式決定的。--（☎）dt 2025年5月6日 (二) 05:25 (UTC)[回复]
(～)補充我認為在此處提起是否需要CU是殺雞焉用牛刀，CU涉及到太多爭議了。另設electionadmin反而是更practical的解決辦法。--（☎）dt 2025年5月2日 (五) 17:33 (UTC)[回复]
英维的electionadmin只负责配置，而scrutineer（能看到用户数据的）则只能由CU处理，这里和这里的讨论怎么没见你参与？
CU涉及到太多争议了 - 那咱们就特定争议讨论争议可以吗？--beef [talk] 2025年5月3日 (六) 02:33 (UTC)[回复]
甚麼時候我說中維的electionadmin和英維的electionadmin職責相同了？還有，既然你說scrutineer（能看到用户数据的）则只能由CU处理，那為何本地監督員能在技術上兼任scrutineer?--（☎）dt 2025年5月3日 (六) 03:20 (UTC)[回复]
不能認同這是「沒壞別修」，這不是現在轉交元維基沒有「系統性問題」就一直拖延下去的，CU體制沒有問題，有問題的是人。--Aqurs 2025年5月5日 (一) 16:20 (UTC)[回复]

参考資料

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

两岸四地用词问题

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:格式手册/两岸四地用语。

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

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

请求保护页面

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

Sidebar问题

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

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