跳转到内容

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

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

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

按此刷新頁面。

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

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

查看全部討論

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

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

消息

邀請參與確定Wikifunctions的中文譯名

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:维基媒体姊妹项目。

Wikifunctions是維基媒體運動的新成員，中文維基媒體社羣正在討論爲Wikifunctions確定中文譯名，歡迎參與討論。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月17日 (五) 23:31 (UTC)[回复]

暫不存檔。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月22日 (三) 16:05 (UTC)[回复]
维基函数?直接用字面意思，就像学院一样，如果不是的话，学院我建议改为图书馆-- ZYXXXX 2025年11月4日 (二) 14:52 (UTC)[回复]
維基文庫比較像圖書館（ —— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月8日 (六) 18:10 (UTC)[回复]
韓維將 Wikifunctions 翻譯爲「위키함수」，直譯爲「維基函數」，因此直譯名稱是可採用。但考慮到 function 有「work or operate in a proper or particular way（透過合適或考究的方式進行運作或操作）」的動詞含義，不知是否需要考慮此含義。--Didaictor（留言） 2025年11月10日 (一) 15:43 (UTC)[回复]

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

This Month in Education: October 2025

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

This Month in Education

Volume 14 • Issue 10 • October 2025

In This Issue

Wikidata weekly summary #704

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

Discussions

  • Closed request for adminship: Samoasambia
  • New requests for permissions/Bot: langCodesBot - Task(s): Python script to automate the cleanup of deprecated language codes (e.g., kr) from Wikidata items. Delete or move labels, descriptions, and aliases based on comparisons with fallback and related languages. The script uses the Pywikibot framework to process each item and logs cases it skips due to data inconsistencies or ambiguity to a CSV file for manual review.
  • New request for comments: Exhibition models by Hexatekin - This proposal focuses on standardizing models for art exhibitions. There is not a consistent data model used for art exhibitions that factors in parent-child relationships for traveling exhibitions, show series, or biennials, despite these being important and common types of events in international art history.

Events

Press, articles, blog posts, videos

Tool of the week The Wikidata Reference Validator by User:JosefAnthony helps check and replace broken or outdated references — keeping Wikidata’s knowledge verifiable and trustworthy. It checks whether external references are still accessible or offline, so we can ensure that every statement on Wikidata shows how we know what we know.

Other Noteworthy Stuff

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know? 

(Q167634) - political movement for reformation within the Communist Party of the Soviet Union during the 1980s, widely associated with Soviet leader Mikhail Gorbachev and his glasnost policy reform
  • Showcase Lexemes:baseline (L46097) - English noun (ˈbeɪslaɪn) meaning "a starting point for comparison", "a benchmark in budgeting", or "a reference line in typography or surveying"

Development

  • Mobile editing of statements: We are continuing the work on qualifiers and reference editing
  • GraphQL: We are continuing the work on making labels of linked entities available in GraphQL (phab:T404692)
  • Dumps: We are continuing to look into improvements for the dump process

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

Weekly Tasks

This Month in GLAM: October 2025



Headlines
Read this edition in full • Single-page

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

The Signpost: 10 November 2025

News, reports and features from the English Wikipedia's newspaper
Read this Signpost in full · Single-page · Unsubscribe · Global message delivery 2025年11月10日 (一) 12:56 (UTC)

Wikidata weekly summary #705

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

Discussions

Press, articles, blog posts, videos

Tool of the week

  • User:Difool/WikidataCleanup.js: gadget allowing to do, in one click, a wide series of cleanups in an item: normalize labels, descriptions, and aliases (double spaces, certain Unicode characters), remove weak references, remove weakly referenced dates when they have lower precision than a strongly referenced date and downgrade unnecessary preferred ranks; about the general issue of redundancies in Wikidata, you can check WikiProject Redundancy
  • Ghanasupremecases is a webapp that dynamically pulls and displays over 2,000 Supreme Court of Ghana cases from Wikidata, allowing users to access case details linked directly to Wikidata items. The goal is to make African legal data more open, structured, and discoverable, and to demonstrate how Wikidata can serve as a foundation for national-level legal archive

Other Noteworthy Stuff

  • Temporary accounts rollout: Starting November 12, the community will see logged‑out edits handled through temporary accounts instead of IPs, prompting tool and bot checks.
  • Help shape the future WikidatCon! If you attended WikidataCon 2025, please take 10 minutes to share your feedback in this anonymous GDPR-compliant survey (sslsurvey)

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development The development team were involved in roadmap planning meetings so not much happened in the past week.

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


方針

RfC：考慮将消歧義括号修正为中文括号

本主題或以下段落文字，已移動至Wikipedia talk:消歧义。执行者：Eric Liu 創造は生命（留言・留名・學生會） 2025年11月9日 (日) 15:33 (UTC)。[回复]

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

在下方已打开新的讨论空间“Rfc：關於解冻用户查核员的討論”，故关闭这里的讨论，欲参与讨论请前往下方。 Stang1215 2025年9月23日 (二) 07:13 (UTC)[回复]
“Rfc：關於解冻用户查核员的討論”已總結RFC共識，所有RFC中的反對意見均已獲妥善回應，新的反對意見亦已獲回應並改為中立。於下方新章節#重行公示。--路西法人 2025年10月23日 (四) 03:31 (UTC)[回复]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

方针修订

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

感觉视作任期结束比较優雅。現有的幾個推定離任都是不符合持权硬条件（NDA、管理员），但是這兩位不是。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年9月17日 (三) 09:43 (UTC)[回复]
抱歉，RFC2025非常混亂，看不懂；冒昧問一下，爲什麼需要添加權限，而非按需爲用戶查核員添加scrutineer用戶組？--1F616EMO（喵留言～回覆請ping～求助？） 2025年9月17日 (三) 09:59 (UTC)[回复]
这个是抄别的站的一个想法，目前同样启用了本地安全投票的enwiki和fawiki都是直接把监票相关权限授予用户查核员；而本站因为指定方针时用户查核员仍在冻结，因此创建了一个新的组。不知可否解答疑问。@1F616EMO： Stang1221 2025年9月17日 (三) 10:08 (UTC)[回复]
感謝解答，沒有問題。可無需影響公示期。--1F616EMO（喵留言～回覆請ping～求助？） 2025年9月17日 (三) 11:00 (UTC)[回复]
沒什麼問題。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年9月19日 (五) 08:13 (UTC)[回复]
注：以上一条留言为魔琴针对“解任”和“稽核”部分的留言，由于讨论串结构调整放在这里。 Stang1215 2025年9月23日 (二) 07:04 (UTC)[回复]
(？)疑問是否应该将匿名账号与临时账号区分比较好？毕竟现在有了临时账号，匿名账号应该特指ip账号----脳補｡◕‿◕｡讨论 2025年9月19日 (五) 18:28 (UTC)[回复]
既然已经造好轮子的话，可以考虑继续沿用……分开管理这些权限会更优雅，鉴权也更方便。——ZhaoFJx(Talk) 2025年9月20日 (六) 01:51 (UTC)[回复]
达成了解冻用户查核员权限的共识。共识在哪？5A并没有就恢复用户查核权公示，最新留言是人间百态4天前的总结，他的第一句话提到此案争论颇多，如何解读出共识？认为在没有明确恢复用户查核权的共识的基础上，直接以此为由进行修订方针公示有非常严重的程序问题。恕我必须(－)反对。--PexEric 2025年9月20日 (六) 03:27 (UTC)[回复]
@Stang：能否解释阁下理解的共识所在？？？如果认为人间百态的总结适用“回应起计的3日后无进一步再回应”，那只是因为在他总结的时候RFA2025的“意见征集期”已经结束了🤣，所以没有人回应。退一步讲，哪怕是抛开意向调查规则不谈，也可以理解是他受托对讨论进行总结，其中的回应有他及提案支持者的回应，不是新的东西和新的回应。再退一步，哪怕共识为引入，也不代表可以直接开始对修改方案公示。最后再再退一步，现在仍处于“结果总结及公示”期间，“共识存疑讨论维持开放留言”，共识还能被挑战。所以现在这一串讨论是(？) 啥玩意？？这个程序到底是怎么走的？？？？@魔琴、1F616EMO、脳内補完：谁能告知我。我要(！)強烈抗议了。--PexEric 2025年9月20日 (六) 05:29 (UTC)[回复]
同上，恕难以看出共识，(－)反对。--浅村しき（留言・来签个名吧） 2025年9月20日 (六) 23:48 (UTC)[回复]
同上，(－)反对。--Jackyming（留言・貢獻・這位編輯者是一位奶味藍🤩) 2025年9月21日 (日) 13:40 (UTC)[回复]
RFA2025那边主持人改为认定议案5A无共识了。这边的方针修订是否应该调整一下并继续公示，还是不修订了？--Srapoj（留言） 2025年9月21日 (日) 23:01 (UTC)[回复]
已先取消整體公示。不過，本人認為方針修訂本身（與權限恢復拆分）可以繼續，並希望就此部分先行公示。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年9月22日 (一) 05:05 (UTC)[回复]
另外，本人對於社群是否確實達成恢復使用者查核權的共識，亦大有疑慮。此一重大決定，也應該值得更充分的討論；前次討論參與者約三十人，不過微幅超過一次申請人數的門檻下限而已，也不見得有安全投票等其他議題討論周全。在社群相當一部分同志不能充分信任體制時，貿然恢復使用者查核員申請，唯有加深社群分裂及疑慮，短期內還可能導致優秀人才遭遇原則反對而折損（眾所周知，管理人員申請常常直接把維基人「登出社群」）；理性論之，即使目前恢復權限本身，客觀而言可能利大於弊，外部威脅亦沒有意料中大，仍不應直接排除這一決定對社群自治體制長遠信任的負面影響——尤其當年取消權限的決定，本身就是極嚴重的打擊。建議如本人此前所提出，先以基金會說明修正有關方針以符合未來需要，但開放繼續討論是否正式恢復為宜。（註：本人原則同意恢復使用者查核權，但我住在臺灣，所以可以「隔岸觀火」，同意得很輕鬆，其他人就不必然如此）—— Eric Liu 創造は生命（留言・留名・學生會） 2025年9月20日 (六) 13:32 (UTC)[回复]
不反對放緩正式開放用戶查核員，但反對無視RFC達成的引入用戶查核員共識。這次RFC無論是從通知廣度還是討論時間都滿足能達成共識的標準，更何況對於該議題的意見總結不僅是對本次討論的總結，更是對自2018年來多次試圖引入該機制討論的總結。我不認為在就引入本身上還有什麽可以討論的空間。不可否認的是，用戶查核員制度還有很多地方需要討論完善，和WMF之間也需要進一步溝通，但這些討論都應建設在本次RFC所得出的共識之上。如果得出的共識不給出合理理由反駁而選擇拉布不承認，這不僅是對過往討論和RFC規則的漠視，更是在玩弄共識方針--人间百态,独尊变态(讨论)(签名) 2025年9月20日 (六) 23:34 (UTC)[回复]
請問你所謂的達成共識是社群同意恢復此權限還是不同意恢復此權限？--Jackyming（留言・貢獻・這位編輯者是一位奶味藍🤩) 2025年9月21日 (日) 13:38 (UTC)[回复]
至少在我發出那段話的時候該共識已進入公示階段且我已回答反對方的意見，才此情形下我假定社群存在此共識並以此為基礎發表相關意見雖然在程序上有些瑕疵，但總體上來看問題不是很大。--人间百态,独尊变态(讨论)(签名) 2025年9月21日 (日) 13:52 (UTC)[回复]
当初对社群打击到现在仍未恢复之前的社群活跃度，稽留了太多非常多管理任务未完成了，可以说至少没看出恢复此项权限对社群造成的弊端。而根据基金会的发言，看得出他们还是想要恢复中文社区的历史繁荣。----脳補｡◕‿◕｡讨论 2025年9月22日 (一) 15:42 (UTC)[回复]
注：以上5条留言为原始讨论串针对“RFC中5A是否达成共识”的留言，由于讨论串结构调整放在这里。 Stang1215 2025年9月23日 (二) 07:04 (UTC)[回复]

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

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

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

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

现有的两位暂时冻结权限的用户查核员應該如何處理？RfC中的建議是視作任期結束而自動解任，Stang提的方案是说明这两位用户“推定离任”。個人認爲「任期結束」的說法較爲優雅，沒有引入新的模式。雖然「推定離任」也是已有的說辭，但是幾名推定離任都是不符合持权硬条件而離任的：Kegns、Alexander Misel、Lanwi1是由於NDA失效而「離任」，Mys 721tx是因爲不再持有管理員權限而「離任」。Cdip150、Jimmy Xu均符合繼續持權的「硬條件」，似乎不能算是「推定」離任，我覺得應該表述爲新制的設立而離任——視作任期結束而自動解任也是符合這種看法的。由於不涉及方針文本，爲避免影響公示，現拆分討論。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年9月19日 (五) 08:20 (UTC)[回复]

對於離任的名義我偏好「任期結束」，但就如我在意象調查的意見！保留他們參選查核員的權利（甚至可以是第一次選舉時自動提名），但反對在不重新參與選舉的情況直接復任。Lily135（留言） 2025年9月19日 (五) 08:47 (UTC)[回复]
私以爲可以這樣：
  1. Kegns、Alexander Misel、Lanwi1由於NDA失效而於NDA失效的一刻「自動離任」；
  2. Mys 721tx因管理員解任投票而於管理權被解除的一刻「被社羣解任」；
  3. Cdip150、Jimmy Xu「被社羣解任」，追溯到對方針進行修改而重啓用戶查核權的一刻。
前兩類是按事實錨定離任時間，第三類是因爲社羣普遍不希望當時的查核員直接復權，可推定爲社羣共識解任。--1F616EMO（喵留言～回覆請ping～求助？） 2025年9月19日 (五) 09:24 (UTC)[回复]
我記得在哪裏看過被除權之後要六個月後才能再次申請權限，不確定是否非管理權限才有的規定。如果此規定1️亦適用於用戶查核權，應視爲社羣同意這兩位用戶就這次解任獲豁免。（我記得RFC2025有不少用戶認爲這兩位應該重新選舉，可推定爲忽略其他限制而支持重選。）--1F616EMO（喵留言～回覆請ping～求助？） 2025年9月19日 (五) 09:29 (UTC)[回复]
不要搞這麼多東西。當初基金會就是去除了這幾位的用戶查核員權限及用戶組，而不論是基金會還是社群都不允許不經任何選舉復任。如此，當初去除權限即為離任即可，不要去自己定義是因為什麼離任，也不要搞什麼推定不推定的，根本沒任何實際意義。C、J兩位是符合再次參選的條件，也是視作離任後再次參選即可，而「繼續」「保持」「恢復」權限這些都不符合事實。--路西法人 2025年9月19日 (五) 10:31 (UTC)[回复]
亦可，支持追溯至基金會行動時解任。只是記得有人提過當初基金會沒有決定去除個別查覈員的權限，只是決定用戶查核權暫不適用於中維本地而已。--1F616EMO（喵留言～回覆請ping～求助？） 2025年9月19日 (五) 11:29 (UTC)[回复]
User:滥权管理员/2018年WMF关于CU除权解释的原文。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年9月20日 (六) 12:14 (UTC)[回复]
電郵雙方都是以revoke（除權）為動詞。--路西法人 2025年9月22日 (一) 09:38 (UTC)[回复]
支持，被暂停的两位经过他们本人同意后再举行选举投票即可，其他人毕竟都有争议，不建议继续任职，并且可以考虑加入到引言里，如果是被解任的一般无权继续选举投票----脳補｡◕‿◕｡讨论 2025年9月19日 (五) 18:35 (UTC)[回复]
很明顯，應該將兩人任期結束設定為「未來首批申請結束（或第二位申請通過者上任，以至滿足本地使用者查核自主要件）」之際，這樣社群自治體制上就不會有任何「空窗期」；若兩人選擇參與申請並通過，也方便直接接軌，就更不用擔心；如果未來首批申請沒有任何人選通過（機率並非很低），那就繼續保持任期凍結，反正也沒有實質影響，或者兩人有參加但沒通過，那一樣視為任期結束，與前者相容很方便。所以本人不贊同其餘任何方案，包含錨定於當年「基金會行動」，或此次方針修訂案通過等時間點，尤其不贊同前者，因為基金會不過是not allow [the elected] to serve，不是直接demoted或nullify the election [RfCU]。有些不恰當的比喻，就相當於基金會出了一次超級大技術毛病，phab任務一直沒修好，阻礙本地同志行使權限，但不代表那些人一開始就直接被解任了（至於基金會後來「天降詔諭」，那就另當別論）。現在更新共識之際，本人仍希望社群以新人上任為原則，來規劃既有同志任期有尊嚴地結束。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年9月20日 (六) 13:22 (UTC)[回复]
事實上社群自治體制確實存在過空窗期，承認歷史對本地社群的發展很重要。以接軌、空窗期為理由去推定、空泛訂立的新日期作為離任日並不合適。--路西法人 2025年9月23日 (二) 13:22 (UTC)[回复]
基金會都不承認正式離任，憑什麼社群自己退縮？實際上，此處未經管理人員解任投票，即要求當事人離任，本身就已非平常情況，理論上根本不能這樣；承認基金會剝奪本地行使查核權限的恥辱，與承認有關同志未經社群程序正式離任的事實，兩者並沒有衝突。我不喜歡用「職業」來稱呼站內權限，但停職檢查能等於開除嗎？當然不。另外，社群既有共識，是區分各類情況，將「停職」及離任分開看待。若當初即算兩人離任，豈不是把他們的離任日期拉到後面因故離任同志之前？若強迫大家一致，又會牽扯別的問題，這纔是「空泛訂立」而不符合歷史事實的選擇，幹嘛如此？所以，無論是為了堅守社群自治原則，抑或避免額外發生規則適用問題，本人所提「擱置」（延遲考慮）方案，均可謂（相對）務實可行，起碼也是對體系衝擊最小。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年9月25日 (四) 22:14 (UTC)[回复]
您前述留言引用的是關於未上任用戶查核員not allowed to serve，而前半句卻是針對既有用戶查核員說明是the other local CUs who were revoked，基金會確實是正式撤銷權限。而把他們的離任日期拉到後面因故離任同志之前的說法存在明顯謬誤也不是我前面所說的處理方法：如果是視為當時已撤銷權限，那麼自然就不存在「後面因故離任」，因為前面已經離任了。至於若強迫大家一致，又會牽扯別的問題一說，您並未提供有關如何構成空泛訂立、不符合歷史事實的情況，無法作為有效論據；相反我能指出的是在該段時間本地確實不存在用戶查核員。所謂「堅守社群自治原則」無非是想把眼睛遮住假裝社群自治沒有失效，而至於基金會要出手行動；既然都基金會行動了，那事實就是當時這個社群自治被剝奪了，這個才是歷史事實。--路西法人 2025年10月3日 (五) 01:57 (UTC)[回复]
另外，您有關承認基金會剝奪本地行使查核權限的恥辱，與承認有關同志未經社群程序正式離任的事實，變相表示基本上是同樣性質的WP:OA2021中被除權（且可經重新選舉復權）的用戶未經社群程序正式離任（社群未曾正式通過共識承認有關離任），所以仍然是停職管理人員？此說法明顯不合道理。CU一案是基金會（暫時）剝奪本地用戶查核權，故移除持權用戶的權限，是為除權。兩次OA的除權性質、結果和復權處理是完全相同的，不可能OA是除權，而CU卻是停職。--路西法人 2025年10月3日 (五) 02:02 (UTC)[回复]
基金會不僅說是not allowed to serve，更說這一操作是臨時性的block（見下），很明顯與後來基金會行動性質不同。當年基金會行動有關說明，更直接指出除權當事人應（可）重新申請，而這裡顯然不是如此；基金會當年並（或還）沒有要求遭暫時凍結使用者查核權限者必須重新申請，不過是因為拖太久，到現在形成僵局罷了。停職檢查能跟正式「雙開」處分比嗎？當然也不能。即使基金會後來指出需要重新申請，那也是對於新制上任的要求，不應構成舊制下任期的中斷。我們對於本地事實上無法行使權限沒有爭議，標記也清清楚楚；問題在於認定這是臨時措施（即「凍結」），還是如同基金會行動般的最終處分。我不認為將基金會二〇一八年的操作認定為最終處分，對中文維基百科社群或當事人而言是公正的。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月3日 (五) 07:49 (UTC)[回复]
你的說法存在極大量的謬誤。WMF通知原文存檔，完全沒提過「凍結」用戶查核權，從頭到尾只有說過「移除所有本地用戶查核員權限」。Block跟凍結或是移除無直接關聯，所謂「停職」仍是社群自己解讀的說法，從頭到尾基金會從來沒說過前CU員可以恢復權限，任期制之下則等同重新申請而非「恢復」，跟OA後被除權者再次選上並不等同「恢復」權限毫無分別。基金會過往也從來沒說過這個是臨時處分。編輯權限跟用戶查核權限不同，編輯權限是直接跟隨用戶存在的權限，獲得解封自可恢復；用戶查核權則絕對不是跟隨用戶存在的權限，事實上2018年3月至今本地是沒有用戶查核員而不是無法行使權限——僅有在保留用戶持有用戶組而移除權限的情況下才是「凍結」權限。--路西法人 2025年10月13日 (一) 05:09 (UTC)[回复]
另外，當年暫時除權之際，還有申請正進行中；雖然最後沒通過，但如果有通過，請問按你這個算法，他將是什麼時候被「開除」？這矛盾更大了。既然基金會不禁止本地繼續提交申請（"We would not stop an election from happening but they would not be able to gain the tools"），不就正是not allow to serve而已（當然，實務上社群也不再辦理申請，這是後話）？與此同時，閣下前述論點，不僅本身沒有道理，更與當年社群認為本地申請可以繼續，作為未來復任基礎，以及允許有關申請正常完結的討論不合。如果要尊重歷史，就應該承認彼時尚無人認為基金會係打算永久除權（直至今日亦然），而社群不過是要改革制度，順便尋找一個正式的「人工斷點」，為事態長年未能解決的僵局解套；我認為新申請結束是一個適合的斷點，而二〇一八年並不適合，因為不符實況。還是沒共識，那就提案付諸表決，我沒意見。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月3日 (五) 08:01 (UTC)[回复]
我有必要提個醒，基金會的決定是可以逾越本地社羣共識的，因此本地社羣當時討論出來的東西對於理解基金會的決定的性質並沒有多少參考價值，更別說本地社羣當時已經被WMCUG之流滲透影響了。“We would not stop an election from happening but they would not be able to gain the tools”的實際意涵應該是“你們大可以繼續進行選舉，反正我們無論如何都不承認選舉結果”，因為如果基金會承認選舉結果的話，基金會不會阻止（潛在的）當選人獲授權，基金會阻止（潛在的）當選人獲授權的唯一合理解釋是基金會不承認選舉結果；這點可以從電郵中對“Say, it is futile to elect any CUs during this period, since WMF will not recognize them anyway?”一句的回應“Yes, for now this is correct.”證明。Sanmosa 新朝雅政 2025年10月4日 (六) 02:08 (UTC)[回复]
基金會不承認臨時處分改變以前的本地申請結果，並不代表不准本地日後重新要求授權；「WMF will not recognize」（即阻礙本地申請通過者履任）跟本地是否recognize，本身是兩個問題。就現在而論，這些猜測固然沒有意義，但基金會當時顯然並未決定永久除權（即立即要求所有在任者必須重新申請），也沒預料暫時處分會持續如此之久（甚至其間還發生一整個基金會行動），這則是事實。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月4日 (六) 10:03 (UTC)[回复]
因為時間過久，社群想法產生變化，要求當事人重新提交申請、確認社群信任，此本可理解，基金會當年亦已指出「for example a month away from the tools is very different then a couple years」；但不能據此反而認定，當年基金會操作本身即屬永久除權。本地亦至今長期承認在任者理論上仍持有權限，僅其實際行使處於凍結（不明）狀態，否則今天就不會討論此類問題。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月4日 (六) 10:18 (UTC)[回复]
你還是在這裏說一些與事實完全相反的話啊。我在上面也不是沒有提過“本地社羣當時已經被WMCUG之流滲透影響了”這話，當時的本地社羣就算真有“承認在任者理論上仍持有權限”的結論，由於滲透的緣故，這種結論是無效的。而且我看了一下，我相信你對“block”一詞的意思有著相當大程度的誤解，“block”一詞指的是基金會不承認選舉結果且不容許將CU權授予任何中文維基百科用戶，而不是基金會suspend中文維基百科當時的CUer的權限，因為“block”一詞在4封電郵出現的5處討論的都是當時正在選CUer的Techyan的選舉的有效性。Sanmosa 新朝雅政 2025年10月4日 (六) 11:58 (UTC)[回复]
「由於滲透的緣故，這種結論是無效的」，你是要在本站開搞轉型正義？何況講話的又不僅是他的支持者，除了貶低有關當事人、打壓其意見「正當性」云云，完全不知道你提這事是為了什麼。還是你覺得@Bluedeck、Cwek、Lnnocentius等人都是他們的附庸？那可厲害了。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月4日 (六) 19:59 (UTC)[回复]
我的意思是WMCUG之流的滲透會導致社羣的部分用戶（曾經一度包括我自己在內）被他們誤導，並進而支持或認同不成立的結論。再者，WMCUG之流的滲透涉及偽造共識（這點OA2021應該有提過），說真的，他們主導過的各種規則的制訂我都認為應該重新檢視一遍。Sanmosa 新朝雅政 2025年10月6日 (一) 15:09 (UTC)[回复]
即使加入這一因素，當年社群應該是普遍不理解基金會決定的內涵（因為當時說明相當模糊），且基金會至今也沒有指出具體是誰犯了錯。這些問題，我想改制能過去的話也就算了。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月7日 (二) 05:32 (UTC)[回复]
那要不現在再發一次e-mail請求澄清現狀？Sanmosa 新朝雅政 2025年10月9日 (四) 14:47 (UTC)[回复]
也行。不過基金會目前理事選舉爭議瀰漫（見客棧消息區），信任及安全部門應該也是火燒眉毛，建議等一些時候再打擾他們。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月9日 (四) 16:02 (UTC)[回复]
另外，當年暫時除權之際，還有申請正進行中；雖然最後沒通過，但如果有通過，請問按你這個算法，他將是什麼時候被「開除」？：因基金會剝奪本地用戶查核權，所以根本沒有「如果有通過」一說，未曾上任就不存在所謂「開除」。前文有說：so no new elections will be honored at this time，基金會也是明確表明選上的人不是on-hold用戶查核員——and he will not become an on-hold CU，所以這個選舉根本不存在「如果通過」一說，而是無論如何都是不獲通過的選舉，那自然不存在「什麼時候被除權」的問題，因為就算得票高於80%也不會獲授權，自然不存在除權的問題。
郵件還有下文如下：
問：Just to make it crystal clear: WMF will not admit any local CUs elected after this office action and before the block is released? Say, it is futile to elect any CUs during this period, since WMF will not recognize them anyway?
答：Yes, for now this is correct. We would not stop an election from happening but they would not be able to gain the tools.
基金會說的是隨便你選，但對於他們來說這個選舉根本沒有效力，是不獲承認的結果。--路西法人 2025年10月13日 (一) 05:19 (UTC)[回复]
基金會是否承認與本地是否承認申請結果，本來是兩個問題。本地社群當初是傾向承認申請結果，等待基金會方面解決癥結所在，再來考慮全域授權事宜；不過是為了避免可能衝突（以及考慮基金會態度的現實），乾脆暫時不再辦理申請而已。所以，因為這類申請不存在實例（不包含當年那一未通過者），無法推知結果如何；就現在而言，亦已無甚意義。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月14日 (二) 04:40 (UTC)[回复]
本地完全可以搞個天花龍鳳的共識說自己不接受WMF管轄，但基金會和Meta顯然也不會承認這樣的共識。在於CU議題而言，本地是否承認當初的選舉結果根本就毫無意義，這是本地沒有話語權的部分，唯一考慮的只有基金會是否承認這個結果、用戶是否獲得授權。所謂本地社群當初是傾向承認申請結果，等待基金會方面解決癥結所在，再來考慮全域授權事宜更是天荒夜譚，那SCP是不是也能在修改選舉規則後拿這之前的74%去要求追授管理權了（誤）？再說，基金會都能把整個權限從本地所有查核員手中拔走，以基金會效率來說，這不可能是一年半載能解決的問題。試問基金會又怎麼可能會接受一年半載前的選舉結果當作最新的社群授權呢？把移除本地CU的日期作為離任日期乃是不帶任何觀點的事實陳述，也確實是當天這些用戶就不再擔任CU（直至未來重新被選上為止），請不要再拒絕接受現實和事實，去堅稱他們是沒有正式離任了。--路西法人 2025年10月15日 (三) 02:52 (UTC)[回复]
同意，既然大家对主观评价达不成共识，那就客观描述就行了。--Vertin,do you want to be the timekeeper? 2025年10月15日 (三) 03:09 (UTC)[回复]
其實我上方表達的意思與你這裏說的話是一樣的，但他似乎不認為這點很重要。Sanmosa 新朝雅政 2025年10月15日 (三) 13:35 (UTC)[回复]
怎么说呢..并不是每个人都那么客观。共识制还是太把人当人了,居然认为每个参与讨论的人都是对事不对人的.--Vertin,do you want to be the timekeeper? 2025年10月15日 (三) 14:33 (UTC)[回复]
我們對於基金會禁止本地使用者查核員行使職權（所謂「除權」）的事實從來沒有爭議，好像也沒有討論空間。我不過是認為應該尊重本地社群當初認為有關權限係屬凍結（且相當程度延續至今）的看法，並在這個基礎上討論正式任期結束問題。從暫時拖成（半）永久，基金會難免有自己的原因，固然無可奈何，但本地是否要連帶吞下結果？既然我們不是幫基金會籌劃，我認為在這一問題，將基金會「承認」視為本地處理有關問題的唯一要件，以及將這一漸進產生論據基礎的觀點視為自始至終的存在，本身就是很大的不公，甚至錯誤。「把移除本地CU的日期作為離任日期乃是不帶任何觀點的事實陳述」當然也是觀點，而從社群自治的角度來說，「凍結」也可以成為客觀描述；社群多年來，多少就此決定予以區分，前面也已有人提到「軟條件」與「硬條件」的差異，而堅持改變條件，將不同情況混於一起，是否較好？這不純粹是什麼主觀評價與否的問題。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月15日 (三) 14:57 (UTC)[回复]
那就写成,针对基金会的这一决定,一些人认为xxx,另外一些人认为xxx.
就像写条目一样有何不可--Vertin,do you want to be the timekeeper? 2025年10月15日 (三) 16:03 (UTC)[回复]
「基金會凍結本地用戶查核機制」為事實，「基金會凍結本地用戶查核員之權限」是超譯，基金會從頭到尾只說過「revoke」（撤銷）權限，不論當時或是現在都沒說過可以「解凍」恢復。請不要再將明顯的非事實個人觀點扭曲成事實。唯一的事實就是2018年3月29日基金會「revoke」撤銷六名用戶查核員權限，自該日起六名用戶查核員已卸任，將事實扭曲成觀點並不會使這個事實變成非事實。--路西法人 2025年10月16日 (四) 03:44 (UTC)[回复]
另，所謂「不公」乃是明顯存在謬誤的說法。對於用戶生成內容及用戶管理，在極大部分情況下不需要基金會「下放」權限，也不涉及任何必須有基金會決定的問題；相反，用戶查核權限卻絕對是涉及基金會本身法律問題，是基金會要「下放」的權限。用戶查核需要基金會承認乃是理所當然，本來就沒有「不公」。保密協定是簽給基金會的，身份確認是給基金會的，這些就算本地存在具有保密協定維護的仲裁委員會，也仍然不是能由本地處理的問題，這一點已經能證明用戶查核從來都不僅僅是「本地問題」。--路西法人 2025年10月16日 (四) 04:13 (UTC)[回复]
補充：若當事人參加有關新一批申請，理應視為當事人接受社群之「信任投票」；若不參加「信任投票」，即無意繼續爭取社群信任者，則確可視為離任，本人對此不持異議。當然，本人還是希望兩位同志均同意繼續運用經驗，為社群服務，這是最理想的「方案」。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年9月25日 (四) 22:24 (UTC)[回复]
這樣會存在一個問題，就是當初該二人選上CU時社羣同意給予的是永久權限，然而現在（基金會同意）的CU權限是有任期限制的，如果該二人的任期被視為未曾中斷的話，那該二人的連續任期就超出了（基金會同意）的CU任期限制。Sanmosa 新朝雅政 2025年10月2日 (四) 08:00 (UTC)[回复]
此外，剛才看了一下當時的電郵原文，Ericliu1912這裏說的話似乎與當時的實際情況不相符。Sanmosa 新朝雅政 2025年10月2日 (四) 08:03 (UTC)[回复]
當年已說是block，而且可以lift（當然最後稀裡糊塗，沒有直接解決）。綜上所述，我沒看出來有什麼「不相符」。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月3日 (五) 07:49 (UTC)[回复]
那我很懷疑你是否處於某個平行時空，見上。Sanmosa 新朝雅政 2025年10月4日 (六) 02:09 (UTC)[回复]
原話還你== —— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月4日 (六) 10:12 (UTC)[回复]
至於任期問題，新申請通過，那就自有mandate，基金會哪有可能故意阻擋有經驗者？就新制而言，自是重新起算就好（@普丁），根本不構成什麼任期限制。何況新制與舊制權限取得及運作多有不同，若硬要一體適用算在一起，祇為了提前結束幾位同志的舊制任期，那又有什麼好處？不是很理解。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月3日 (五) 07:52 (UTC)[回复]
我的意思是視為「信任投票」並不合適，因為這種情形下該二人的連續任期就超出了（基金會同意）的CU任期限制（n+2>2）。如果要使該二人毫無阻礙地參選新制CU，那該二人的任期需要被視為在2018年已結束。Sanmosa 新朝雅政 2025年10月4日 (六) 01:58 (UTC)[回复]
基金會說的任期，當然是指新制任期。沒看出他們有意將改制前規劃納入計算，否則對於其他任何可能（或已）改制社群，均將產生體制連續問題。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月4日 (六) 10:03 (UTC)[回复]
問題在於“視為‘信任投票’”，這代表著一旦候選人當選，社羣在投票中變相授權候選人獲得自2018年起開始、超過兩年的任期。Sanmosa 新朝雅政 2025年10月4日 (六) 12:05 (UTC)[回复]
舊制信任投票，授予無限任期，他們已經通過了，此處不論。新制信任投票，是允許他們恢復（或繼續，視角或有不同）持有權限，並重新授予兩年任期。基金會說明提到的兩年任期，是新制下的兩年任期吧？這一條款，實際上是表示新上任者要每兩年更新一次社群信任，並沒有包含疊加計算所謂「任期」的意涵，且他們哪裡會去管已經（將）失效的舊制？所以不確定閣下所稱「變相授權」何指。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月4日 (六) 19:48 (UTC)[回复]
或者換句話說，新申請通過，本身就算是一次「更新信任」，那兩年任期起算，下一次確認就是兩年後。我不認為這有問題。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月4日 (六) 19:59 (UTC)[回复]
那我希望如果之後真的能舉行投票的話，相關頁面務必聲明這點。Sanmosa 新朝雅政 2025年10月6日 (一) 15:15 (UTC)[回复]
有必要可以在方針修訂案內加入「落日條款」。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月7日 (二) 05:32 (UTC)[回复]
另@魔琴：我覺得以新制設立為斷點也不盡適合，因為從新制通過到至少一位新人上任（不一定可履任），其間仍有落差，而且從目前社群討論進度看來，辦理申請可能還需要一些時候。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月3日 (五) 09:08 (UTC)[回复]
另外似乎有些权限申请规定近期被除权者无资格，可能要考慮到这個问题。包括现有两名查覈员，以及未来可能落选的查覈员，是否应當適用这個规定。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月12日 (日) 10:14 (UTC)[回复]
不將此視為「（被）除權」即可。我不知道管理人員有沒有這類要求？至於基金會，應該是沒有特別意見吧。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月12日 (日) 18:58 (UTC)[回复]
@Sanmosa：早前我已就此事致信基金會洽詢，相信之後將有回覆。在此之前，社群仍應維持既有記載，予以區分為宜。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月24日 (五) 19:32 (UTC)[回复]
此討論明顯已達共識——僅Eric一人堅持應視作「凍結」，其餘包括本人、Linxingjun、脳内補完、1F616EMO等均同意2018年離任的事實陳述，而Eric對事實陳述的反對意見亦已被多人反駁，未見再有有效的回應意見支撐其反對意見，是為共識方針所視的「已獲解決的反對意見」。請User:Ericliu1912勿再反覆強推某一明顯不獲社群共識接受的觀點。--路西法人 2025年10月25日 (六) 03:21 (UTC)[回复]
其實無論是要推翻共識、確立共識、新生共識或什麼的說辭也好，甚而現在已有多少人支持云云，哪還有像你這樣明確知道社群正討論到一半，自己先跑去改掉頁面，還拿基金會當擋箭牌，禁止別人回退。既然都知道社群不少意見支持你，多等個幾天是會礙到你什麼？總按你這更新共識的路數，還有誰敢反對？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月28日 (二) 02:30 (UTC)[回复]
我沒要反對了，但既然這可算是一個掛了幾年的重要問題，還請你把程序走完，起碼貼個幾天公告欄吧。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月28日 (二) 02:33 (UTC)[回复]
既頁面（還）不是方針（無影響任何規則），當年這樣改又沒有經過任何共識形成流程（除權後原始第一版本與我所寫版本無異）。當前只是退回當年未得共識之修改（也非事實性修改），如此恕我斗膽直接更新頁面。另外，拿基金會當擋箭牌（即說成是基金會不讓你回退）跟拿事實來做事是兩回事，請不要搞混。--路西法人 2025年10月28日 (二) 03:01 (UTC)[回复]
也請不要再拿着一個沒有任何共識明確支持的聲稱，去退回一個符合原始版本且目前具社群共識的事實陳述。為了儘量留存符合個人意願的版本，即使自己的寫法已經被社群拒絕，仍不斷找茬阻礙具共識的版本，這樣的做法絕對不具建設性。--路西法人 2025年10月28日 (二) 03:12 (UTC)[回复]
依據共識方針，有關提案至少須公示七日；即按所謂「簡易規定」，至少也要三日。社群是否達成共識，一般以公示決定。公示亦可確保社群最大程度知悉並參與討論。此一問題至少有六年歷史，本人並不認為可以如此輕易帶過了之。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月30日 (四) 02:35 (UTC)[回复]
…刘君的犟又犯了。--GrandCeres（留言） 2025年10月28日 (二) 03:35 (UTC)[回复]
我不認為反對處理一個多年懸置問題如此隨便叫「犟」。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月30日 (四) 02:38 (UTC)[回复]

此處已就六名前用戶查核員離任按事實認定為除權日期即2018年3月29日，並移除非事實性的「推定」離任日期達成明確共識。為配合Ericliu1912的拉布，因下方恢復用戶查核方針的討論即將通過，謹此 公示7日，2025年11月6日 (四) 03:10 (UTC)結束。--路西法人 2025年10月30日 (四) 03:10 (UTC)[回复]

(...) 吐槽真的不知道為何偏不按事實，硬要留着非事實的觀點陳述。六年來只是沒人去關注，本身就不能反映社群共識的非事實陳述說成是「更新共識」。該嚴格遵循方針的時候不循，在明顯可以忽略規則執行共識的時候就硬要走官僚流程，此人還真的是不可理喻。--路西法人 2025年10月30日 (四) 03:24 (UTC)[回复]
不管社群如何，本人不会承认此共识。本人在未来仍会按原写法表述。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月30日 (四) 05:05 (UTC)[回复]
任何人都有按照自己意願的方式去敘述事件性質的權利，但寫在社群頁面的資訊不能純粹按照個人意願，還要顧及事實陳述。你或Eric劉想怎麽自行陳述與我無關，此處僅針對社群頁面的說明進行修改。--路西法人 2025年11月3日 (一) 03:52 (UTC)[回复]
不反對。我對這幾位如何離任不再持任何意見，只要確保這幾位確實離任就可以了。--1F616EMO（喵留言～求助？） 2025年10月30日 (四) 05:50 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

Rfc：關於解冻用户查核员的討論

2025年管理人员制度改革已於今日結束，但關於是否應解凍用户查核员仍未有定論。在此就該議題進行進一步辯論，以求得出一個令社群信服的共識。--人间百态,独尊变态(讨论)(签名) 2025年9月23日 (二) 06:39 (UTC)[回复]

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

（合併有關討論）—— Eric Liu 創造は生命（留言・留名・學生會） 2025年9月23日 (二) 07:26 (UTC)[回复]
請先多發個小結以便開展討論。--路西法人 2025年9月23日 (二) 13:17 (UTC)[回复]
反對意見 回應意見
社群難以選出符合標準的人選 沒有任何證據證明社群選不出符合標準的人選，此與引入用戶查核權限不衝突。
  • 監管員查核制度運行良好，無需變動
  • 目前沒有引入用戶查核員的迫切需求
  • 由於调查助理的人手不足和監管員處理時間較長，該制度很難達到即時處理的效果。
  • 監管員不熟悉中文，處理識別LTA和處理需參考私密證據等案件時難以下手。
  • 單純沒有迫切性不能成為決定性的否決反對意見。沒有迫切性跟落實引入也並非互斥關係
  • 用戶查核作為高危权限，基金会和社群都没有办法保证这个权限绝对安全。
  • 中維曾經发生过隱私泄漏问题，若再出現濫用問題社群根本解決不了。
  • 待仲裁委员会足夠制衡CU出現的濫用問題，才可恢復用戶查核。
  • 將用戶查核權相關問題交給全域機構屬於“因为‘管不着’所以‘不用管’”
  • 權限理論的風險並不影響其存在的必要性，安全問題可通過居住在海外地區盡可能規避。更何況既然基金會當初允許恢復權限說明目前的風險根本不構成引入權限的合理反對意見。
  • 多個存在政治風險的維基媒體項目都設有用戶查核權限，政治因素也不應左右權限的設立。如果出現濫用可通過申訴專員委員會處理。
  • 仲裁委員會目前沒有處理CU問題的能力，可預見的將來也不會處理相關問題。在有WMF和申訴專員委員會的背書下權限被濫用的風險並不高。
  • 監管用户查核的机制只有基金会和符合保密条款的仲委会，而且相當一部分設立用戶查核員的wiki并沒有設立仲裁委員會。因此认为“用户查核目前状态恢复后是没法管”的说法不符合事实。
  • 中國大陸地區的用戶由於無法簽署保密协议而無法獲得用戶查核權，這對中國大陸地區的用戶不公平。
  • 中國大陸地區的用戶可能因为无人知道其确切居所而成功簽署保密协议，這會給社群帶來安全風險。
  • 基金會僅針對居住中國大陸地區進行風險規避，出身中國大陸地區的用戶可通過僑居海外地區簽署保密协议。
  • 簽署保密协议的用戶需要提供居住地證明，無法通過隱瞞居住地來簽署保密协议。如果簽署後僑居無法訪問維基媒體的地區，將會撤銷該用戶的保密協議。

應路西法人意見整理了一下對RFC討論的總結。--人间百态,独尊变态(讨论)(签名) 2025年9月23日 (二) 14:41 (UTC)[回复]

我从未想象到解冻CU权的根基本身提案5A都通过不了，我只感觉到非常喜感，看到各位大人物试图通过议程论证论证出共识已达成更喜感Ember Edison 2025年9月24日 (三) 07:23 (UTC)[回复]
没有建设性的意见可以不用发言的。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年9月24日 (三) 15:26 (UTC)[回复]
那我之前的表态本来就是支持恢复CU啊，还圈我过来干啥，来跳忠字舞吗，我很确定我的监视列表里面没有提案5A--Ember Edison 2025年9月25日 (四) 12:16 (UTC)[回复]
当然，我也可以应你邀请，更有建设性的发表我的评论：以人间百态（讨论 | 貢獻）为首的正方似乎打算向社区推销这样的一种理论：即使中维的管理团队本身不受信任，也可以恢复中维的CU权。这在逻辑上似乎没错，（也说服了我），但从逻辑上，正方也不应该对社区拒绝对这一理论授予信任并且最终导致5A不获通过感到奇怪。正方大可以继续发明更加奇妙绚丽的新理论继续绕过信任问题以图恢复CU权，或者真正的付出行动获得信任，但无论选择什么，直接宣布共识已达成没有异议都不是正方应该做的。Ember Edison 2025年9月25日 (四) 12:48 (UTC)[回复]
你的聲稱顯然與共識方針所定之規則相悖。共識方針注釋一訂明任何一方可以在合理回應反駁意見後三天認定該則意見已獲回應和處理，從而認定共識。套用到此例，反方提出反對意見，而正方正當的回應指出意見當中存在的問題，以至有關的反對意見的邏輯或基礎不再成立，那麼根據方針，自然可以在冷靜期過後視為已獲有效回應的反對意見，這則反對意見就不作為阻擋共識形成的意見。--路西法人 2025年9月26日 (五) 19:40 (UTC)[回复]
在此留言中已論證反對方的意見存在謬誤，包括論證不符合事實、反對論點與恢復本地用戶查核不存在互斥關係、與基金會的評估相悖等問題。如反對方未能回應其意見中的謬誤，應被視作已獲回覆的反對意見處理。--路西法人 2025年9月25日 (四) 04:46 (UTC)[回复]
另回應Midleading在先前討論關閉前的最後留言這句話的意思也可以是指像現在這樣的情況，也就是「社群難以選出符合標準的人選」→不在中文維基百科社群選出查核員，而是依靠國際維基百科社群選出的監管員。：此為已獲回應的非互斥關係情況——社群可以存在本地機制去容許選出查核員，但同時因不信任候選人而一直沒選出查核員，兩者並非互斥。機制存在不代表必須選出人去擔任，只是當有人適任的時候就可以選出來擔任而已；因此選不出人不能論證機制不應該存在/恢復。--路西法人 2025年9月25日 (四) 04:50 (UTC)[回复]
只是談要不要恢復CU機制，沒回應社群的實質關切點。理論上CU機制是可以恢復，關鍵是CU如果要恢復的話應該怎麼選。如果提議中文維基百科恢復CU，但是只有兼任監管員的使用者才可以擔任CU，那我100%同意。問題是這樣表面上的恢復有意義嗎，為什麼哪怕只是表面上的恢復也一定要現在恢復呢？--Midleading（留言） 2025年9月26日 (五) 13:39 (UTC)[回复]
很簡單的道理：如果現在不恢復，在真正出現合適擔任職務的用戶出現時，就沒有機制可以去把這類人選上去。恢復了而宣布出來是社群問題（機制無法處理），沒恢復而有人適合選就是機制問題。--路西法人 2025年9月26日 (五) 19:35 (UTC)[回复]
現在的機制是全域監管員選舉，而不是沒有機制。如果社群認為只通過本地投票就可以選出CU並且不需要全域選舉，恢復CU才有實際意義。基金會允許恢復權限僅代表基金會信任本地可以繼續完善機制並在條件成熟時恢復CU，不能說明基金會比本地社群更了解中國的安全環境。繼續完善CU機制確有意義，同意應盡快研究CU機制如何恢復。但是在拿出足夠安全的CU選舉機制之前（並且不同於候選人直接參加全域監管員選舉），仍然有必要等待，恢復CU應該連同具體的CU機制同時通過。--Midleading（留言） 2025年9月30日 (二) 03:25 (UTC)[回复]
一、「本地可以選出CU」跟「恢復本地CU選制」並無任何邏輯關聯。沒有選舉機制、無人可以參選，而去說沒有人適任所以不應該恢復，這乃是循環論證。只有恢復了選制才能知道是否有人適合成為用戶查核員。
二、用戶查核涉及敏感個人資訊，是涉及現實法律考量的決定。法務部門顯然會作出真正專業的法律決定，這當然包括本地的安全環境，才決定容許恢復本地用戶查核（以及不接受某類用戶成為用戶查核員）。因為如果真的出了政治、法律問題，基金會本身有責任，說成基金會無能力判斷這是明顯不合理的。相反，本地的眾口云云完全不能做出任何真正、確實的安全決定，不可能作出比基金會法務部門更專業的考量。
三、現在確實是沒有選舉本地用戶查核的機制，監管員亦非本地用戶查核員的對等替代機制。監管員不能在本地實施封鎖（不同於本地用戶查核員皆為本地管理員），也不能（也無法）長期處理大量雜項申請（如IPBE檢查）等。故此，監管員作為本地用戶查核的機制一說本質上、事實上皆不成立。--路西法人 2025年10月1日 (三) 13:21 (UTC)[回复]
一、「本地可以選出CU」跟「恢復本地CU選制」應該同時通過才不會自相矛盾，只有「本地可以選出CU」但是沒有「恢復本地CU選制」就是自相矛盾。
二、基金會法務部門現在完全不知道中維會選出什麼人當CU，只能基於中維可能存在適合當CU的人這一假設作出決定，但是具體選出什麼人當CU仍然需要社群決定。鑒於有部分隱私信息對於用戶是否適合在中維當CU關系重大（如是否居住在大陸地區），仍然需要明確社群與基金會合作的機制。首先，本地作出真正、確實的安全決定是理所當然的，因為CU選舉在本地舉行。其次，由基金會進一步確保CU的安全性，不是中維搞完選舉，基金會就必須授權當選的人成為CU。
三、目前監管員執行用戶查核的機制仍然運行良好，或者至少比過去中維存在本地CU時運行更加良好。--Midleading（留言） 2025年10月5日 (日) 12:09 (UTC)[回复]
一、正是因為只有「本地可以選出CU」但是沒有「恢復本地CU選制」就是自相矛盾，所以現在就是只有「恢復本地CU選制」，本地「才可以選出CU」，所以正在討論恢復本地CU選制。不知道你有何誤解。
二、既然基金會會把關中維選出的人是否符合期望，那麼代表中維不需要過分擔心選出來的人存在問題而仍然上任，同時也因此而不需要因此而過分猜忌沒問題的用戶。
三、顯然非也。本地仍有不少需要用戶查核的操作只是通過不甚合理的繞行而暫時免除，理應所有IPBE授權工作都是需要CU審核（因為可以繞過封鎖），WP:CUP#2和WP:CUP#3根本無法執行，有缺失的機制何以稱作運行良好？--路西法人 2025年10月6日 (一) 02:47 (UTC)[回复]
一、完全沒有看到要恢復的到底是什麼本地CU選制。
二、因為不知道本地CU選制會是什麼，所以完全無法評價基金會能否在這個機制下發揮正常作用（或者是只能通過基金會行動保護本地安全）。
三、中文維基百科從來沒有過無缺失的CU機制，CU隱私資料泄露足以說明之前的CU機制是徹底失敗的。因此，我們可以繼續討論本地CU選制怎麼制訂，但關鍵是確保不會出現CU隱私資料泄露，而這點要比WP:CUP#2和WP:CUP#3重要得多，如果做不到，那就是CU機制的徹底失敗及基金會行動的開端。--Midleading（留言） 2025年10月14日 (二) 04:31 (UTC)[回复]
一、二、恢復的本地CU選制從來只有一個可選，就是2022年1月基金會提供的方案，沒有第二個。通告在此，請自己閱讀。
三、CU隱私資料洩漏是管治問題，而不是CU機制問題。只要有CU員蓄意、惡意洩漏隱私資料，這個洩漏是無可避免的，甚至手抄寫都能洩漏這個私密資訊。這一點不論是本地CU還是全域CU（即監管員）都存在——你永遠無法阻止抱壞惡意的人去作出損害他人的事情。在這一點上，負責管轄的是基金會，不論是全域CU還是本地CU都是一樣，本地管不上這個資訊洩漏的問題。就算本地沒有CU，這個洩漏風險仍然存在於全域CU，甚至在基金會內部也可以有這樣的資安洩漏風險。所以認為本地恢復CU就會出現了新的風險乃是極大的謬誤，這個風險未曾也不會消失。唯一能做的就是社群選上更可靠不受團夥、政權控制的人，而基金會加緊監管。--路西法人 2025年10月15日 (三) 03:37 (UTC)[回复]
Wikipedia:用戶查核上寫着“但本地至今仍在籌劃更新制度。”現在沒有考慮補充或增加條款，而是直接恢復且不需要更新嗎？--Midleading（留言） 2025年10月16日 (四) 02:04 (UTC)[回复]
?这取决于共识,从冻结到启用也算是更新了--Vertin,do you want to be the timekeeper? 2025年10月16日 (四) 02:06 (UTC)[回复]
未見有人提出獲得共識支持、比基金會方案更嚴格的要求。本地本身有接近但未符合基金會要求，可管轄用戶查核機制的本地機關（仲裁委員會），所以也沒有任何新增條款可以加進去。就是兩年就重新確認、基金會負責稽核，就這樣。其餘有不同的就是改為使用當前的WP:SPI機制而已，也不是方針修改。--路西法人 2025年10月16日 (四) 04:29 (UTC)[回复]
我认为本地完全可以考虑在基金会方案的基础上提出更多要求，例如需要候选人向基金会申报工作单位，或者要求用户查核员定期提供透明度报告并由可以查看用户查核日志的仲裁员批准等等。现在还没有看到，所以我暂时表示(＝)中立。--Midleading（留言） 2025年10月20日 (一) 14:36 (UTC)[回复]
有關仲裁委員會的管轄部分，須待新一屆仲裁委員會上任再討論（新一屆人選較多符合保密協議要求）。我不太清楚基金會是否會允許本地已簽署保密協議的仲裁員查看用戶查核資訊，還是會要求這些社群允許查看用戶查核資訊的仲裁員也與用戶查核員給基金會的同等申報。另一方面，社群要求用戶查核員向基金會申報工作單位這一部分，這個首先我不清楚是否已經存在；其次就算社群要求了，基金會不要求提供而查核員沒提供，社群也無法執行這項要求。--路西法人 2025年10月22日 (三) 02:57 (UTC)[回复]
社群也无法执行这项要求。
反悔会直接除权不行吗？或者干脆不选他。--Vertin,do you want to be the timekeeper? 2025年10月22日 (三) 03:00 (UTC)[回复]
如果基金會沒有要求當選人提供某些資訊，請問你又如何得知、驗證他是否按照社群期望向基金會提供該等資訊？--路西法人 2025年10月22日 (三) 03:56 (UTC)[回复]
那确实--Vertin,do you want to be the timekeeper? 2025年10月22日 (三) 04:50 (UTC)[回复]
我正在思考一个问题，OA2021中的一个当事方总结出了一套绕过CU的方法，CU的用途是处理傀儡。这套绕过方法现在还能用吗？--Vertin,do you want to be the timekeeper? 2025年10月11日 (六) 02:25 (UTC)[回复]
这个问题我认为还是挺重要的。如果现在还可以使用,那也就意味着哪怕CU重回本地,OA2021还可以再重来一遍,还可以创立一堆傀儡。如果是这样的话,我倾向于反对。因为我想不到CU会有什么好处。--Vertin,do you want to be the timekeeper? 2025年10月11日 (六) 13:00 (UTC)[回复]
（你反对什麼？难道监管员不用CU？我宣佈以上意见不是合理意见。） ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月11日 (六) 18:33 (UTC)[回复]
……我还没了解清楚情况，这么快给俺下定论吗……--Vertin,do you want to be the timekeeper? 2025年10月12日 (日) 03:47 (UTC)[回复]
可能我没把话说清楚吧,我的意思是说:如果可以绕过CU,那么就意味着CU无法用于防止傀儡,或者说是无法用于防止OA2021那种程度的。
监管员用CU是监管员的事,我只是在思考CU引入的利与弊
显然，CU肯定会被类似于OA2021那样的团体争取,毕竟可以用来法律威胁。
如果可以过,那么就可以创一堆傀儡来冲票了
出于这种风险的考虑,我倾向于反对,但反对的前提依然是CU这种漏洞没有被修复.如果已经被修复了,那么我会支持--Vertin,do you want to be the timekeeper? 2025年10月12日 (日) 04:12 (UTC)[回复]
还是不理解。你是说，监管员用CU搞用户查覈就没问题，但是本地搞CU就有风险？ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月12日 (日) 10:01 (UTC)[回复]
两个都有风险是显然意见的。但是前者比后者风险小很多。因为全域比本地难多了--Vertin,do you want to be the timekeeper? 2025年10月12日 (日) 10:13 (UTC)[回复]
那这個意见不是早就回应过了…… ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月12日 (日) 10:15 (UTC)[回复]
好吧，那我撤回。--Vertin,do you want to be the timekeeper? 2025年10月12日 (日) 10:17 (UTC)[回复]
先提前叠个甲，不要说什么安全投票的监督员可以看到CU。安全投票大不了不投就是了,可百科我想大伙们很难说大不了不编辑吧,你要是说什么百科不强迫任何人参与,那我的评价是你赢了--Vertin,do you want to be the timekeeper? 2025年10月12日 (日) 09:30 (UTC)[回复]
TLDR：要這麼說，那大概可以連網都不要上（誤）。絕大多數網站都會收集個人資料，而這個所謂的「個人資料」正正就是CU所能展示的技術資訊。一般而言，這些瀏覽者的技術資訊僅能由網站的技術人員接觸到。另外，任何一個有登錄機制的網站都會將這些技術資訊綁到用戶記錄上面，而維基百科也是相同；只是維基百科讓社群選舉而出來的可信人士（即CU員）可以去查看這類資訊而已。維基媒體的CU員都需要簽署保密協議和向基金會提供身分和居住地認證，以確保能連結到用戶帳號的隱私資訊不被輕易接觸。相對於在網絡上開任意一個小型網站的人都能接觸到所有這些資訊，其實還要嚴謹很多。如果是說擔心這些資訊會被人看到，那還真的不要上網最好，基本上你一開谷歌或百度，他們都有你相等甚至更多的資訊了。--路西法人 2025年10月15日 (三) 03:51 (UTC)[回复]
反驳:你维有过泄露新闻，可很多网站都没有。--Vertin,do you want to be the timekeeper? 2025年10月15日 (三) 03:54 (UTC)[回复]
那你就大錯特錯了。Data breach幾乎天天都發生，也有大量技術新聞報道，不知是您沒去看還是真的不知道有這樣的事情。每年總會有幾個大型網站出現重大的data breach，當中完全包括這些技術資訊，甚至還包括該等用戶提交上去的個人資訊。您維發生的惡意洩漏事件也並非您維特有，這類的事件多的很，甚至全都比您維的事件嚴重。--路西法人 2025年10月15日 (三) 03:58 (UTC)[回复]
……
那也有很大区别，这些信息泄露了还不至于被人知道翻墙然后报警抓起来，可你维确确实实有人打算这么干。--Vertin,do you want to be the timekeeper? 2025年10月15日 (三) 04:02 (UTC)[回复]
這就是這個留言所說的問題了。惡意人士可以在任何地方出現。你甚至不會知道哪個網站的內部有人把你的資訊會報告回牆內，只是你維這個被人發現而已。另外，正是因為有人這樣做，所以基金會已經不讓居住在某些地區的用戶當用戶查核員了。--路西法人 2025年10月15日 (三) 06:09 (UTC)[回复]
好吧，那我撤回--Vertin,do you want to be the timekeeper? 2025年10月15日 (三) 06:11 (UTC)[回复]
討論持續已久，在RFC中的反對意見均已獲合理回應；而在此處討論中新出現的合理反對意見亦已消失。RFC及提案發起人@人间百态、Stang可考慮重行公示？--路西法人 2025年10月22日 (三) 03:57 (UTC)[回复]
不如先把RFC中的討論成果合併至上面的表格供討論者參考。--人间百态,独尊变态(讨论)(签名) 2025年10月22日 (三) 04:07 (UTC)[回复]
(＋)支持--Vertin,do you want to be the timekeeper? 2025年10月22日 (三) 04:49 (UTC)[回复]
可以的话支持公示吧，毕竟本地CU有个可以看编辑倾向来进一步判定傀儡这个无法被取代的优势。----脳補｡◕‿◕｡讨论 2025年10月22日 (三) 15:54 (UTC)[回复]

重行公示

通過：
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
現行條文
流程
  • 自由提名：集中选举之外，另可随时提出自荐或提名其他用户。

...

从2018年3月30日起，維基媒體基金會基於保安原因，暫停本地所有查核员权限並將本地用戶查核事宜交回監管員處理。如希望全域监管员们对中文维基百科用户进行用户查核，请前往此頁提交申請。欲申请成为本地的用户查核员者，请参阅基金会对重新引入中文維基百科用戶查核權限的说明。

...

投票结果

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


...

从2018年3月30日起，維基媒體基金會基於保安原因，暫停本地所有查核员权限並將本地用戶查核事宜交回監管員處理。基金会于2022年1月就恢复用户查核员权限进行了声明；2025年9月，社群在2025年管理人员制度改革意向调查中达成了解冻用户查核员权限的共识。

...

投票结果 ...

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

...

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

...

任命本地用户查核员

...

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

...

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

中文维基百科的用户查核请求在傀儡調查页面进行。調查助理和管理員會針對各個帳號的編輯傾向進行調查，并在认为需要的情况下要求用户查核员进行查核以協助他們判斷。如果本地没有用户查核员，案件会由调查助理轉交至元維基，由监管员处理。

...

任命本地用户查核员

...

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

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

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

調查助理和管理員會針對各個帳號的編輯傾向進行調查。如果他們認為編輯傾向調查所得未至於可以直接判定為傀儡帳號的情況下，將會由用戶查核員調查帳號的技術數據以協助他們進行判斷。由於基金會決定2018年3月30日起暫時取消本地用戶查核員權限，本地的用戶查核請求目前由監管員處理。管理員或調查助理會在需要進行用戶查核的時候轉交至元維基處理。

根據用戶查核方針，監管員只會處理有合理證據懷疑帳號之間關係的請求。未有合理編輯傾向證據而請求查核技術資訊的請求將會被拒絕。此外，根據私隱政策，監管員一般不會公開將匿名帳號（IP帳號）與註冊帳號進行聯繫，故本頁不接受查核匿名帳號與註冊帳號之間技術關係的請求。
提議條文
...

調查助理和管理員會針對各個帳號的編輯傾向進行調查。如果他們認為編輯傾向調查所得未至於可以直接判定為傀儡帳號的情況下，將會由用戶查核員調查帳號的技術數據以協助他們進行判斷。在本地没有用户查核员时，監管員處理本地的用戶查核請求；管理員或調查助理會在需要進行用戶查核的時候轉交至元維基處理。

根據用戶查核方針，用戶查核員只會處理有合理證據懷疑帳號之間關係的請求。未有合理編輯傾向證據而請求查核技術資訊的請求將會被拒絕。此外，根據私隱政策，用戶查核員一般不會公開將匿名帳號（IP帳號）與註冊帳號進行聯繫，故本頁不接受查核匿名帳號與註冊帳號之間技術關係的請求。
  • Wikipedia:安全投票：为本地用户查核员添加添加securepoll-create-poll、securepoll-edit-poll、securepoll-view-voter-pii权限，并指明由用户查核员进行“划去存在问题的选票”的操作，同时微调部分表述。scrutineer用户组继续保留用于避免未来出现没有本地用户查核员的情况。
  • 所有2018年遭移除权限的用户查核员，欲重新取得權限，均需重新提交申請。

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

現行條文
移除权限

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

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

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

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

...
提議條文
移除权限

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

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

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

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

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

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

...

稽核

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

以上摘錄自上方Stang的方針修訂提議。討論持續已久，在RFC中的反對意見均已獲合理回應；而在此處討論中新出現的合理反對意見亦已消失（改中立）。現重行 公示7日，2025年10月30日 (四) 03:27 (UTC)結束。

重要：鑑於恢復用戶查核機制須與基金會溝通合作，本公示僅作方針修訂，表示本地有恢復本地用戶查核的意願，而不代表在公示後能即刻開展用戶查核員選拔。實際恢復用戶查核機制的時機仍須待與基金會溝通準備再定。另，從基金會允許本地恢復用戶查核機制至今，本地已成立全新的仲裁委員會。社群須與基金會溝通討論這個不強制所有委員簽署ANPDP的仲委會在用戶查核中是否及在何程度上具稽核角色。--路西法人 2025年10月23日 (四) 03:27 (UTC)[回复]

非打断公示，但仍不建议将监票权限捆绑至CU用户组。——ZhaoFJx(论) 2025年10月23日 (四) 03:34 (UTC)[回复]
就現階段而言，應該是允許使用者查核員與監管員共同監票為宜。另外，也要考慮本地無使用者查核員時是否指派監督員代行。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月23日 (四) 04:57 (UTC)[回复]
@ZhaoFJx：enwiki和fawiki是这么绑定的。我觉得公示的版本其实也还好吧，本地有CUer就让CUer来，没有的话就由比如OSer来兼任。 Stang1184 2025年10月24日 (五) 05:38 (UTC)[回复]
關於「用戶查核員僅可由安全投票產生，且強制為任期制。投票支持率達70%者會被授予2年的臨時權限。」，
建議改為「投票支持率達80%會被授予2年的臨時權限，投票支持率達70%會被授予1年的臨時權限」，其他不改。--Jackyming（留言・貢獻・這位編輯者是一位奶味藍🤩) 2025年10月23日 (四) 04:55 (UTC)[回复]
理解JM君的安全担忧，但是对于安全投票来说，得票率八成以上实属困难；拿英维的例子来说，英维的仲裁委员兼任cu与os，50%以上一年任期，60%以上两年任期（实际上离任后仍可以保留cu与os），英维去年的仲裁委员会选举，12人里面只有两位候选人得票率超过80%，因此认为本地80%以上两年任期似乎窒碍难行。--GrandCeres（留言） 2025年10月23日 (四) 11:21 (UTC)[回复]
以CU來說，我其實同意標準應該可以訂得比較高的，惟實際上這樣的高同意標準確實窒礙難行，那我是覺得反正能當一年，也沒差能當更久了。70%已經是很高的比率了。--路西法人 2025年10月24日 (五) 12:11 (UTC)[回复]
有关“现有的两位暂时冻结权限的用户查核员”是不是需要改一下，看上面讨论了很长关于这个的内容。就按照当前“使用者查核員任期時間線”模板的内容来吗，即所有CUer都在2018年被移除权限？ Stang1184 2025年10月24日 (五) 05:38 (UTC)[回复]
已劃去。按照事實陳述，2018年至2025年間就是沒有用戶查核員。--路西法人 2025年10月24日 (五) 09:48 (UTC)[回复]
原則不同意，社群並未就此取得共識，有關模板亦本由當事人自行更改，不能用作依據，仍應依循本地既有記載，將現有權限凍結者予以區分。但完全可以在不提及確認權限是否凍結情況下，指出所有2018年遭基金會暫時移除權限的使用者查核員，均需要重新提交管理人員申請（其中自然包含兩人）以取得（恢復）授權，此一部分顯有共識。我已就此修正行文。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月24日 (五) 19:22 (UTC)[回复]
「冻结」是基金会幹的，社群从未達成冻结CU的共识，因此无法说「達成解冻用户查核员权限的共识」，也没有权利「解冻」？ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月28日 (二) 08:25 (UTC)[回复]
註：此留言已被原作者（User:LuciferianThomas）移除。2025年10月28日 (二) 11:59 (UTC)[回复]
修改方針的條文與「表示本地有恢復本地使用者查核的意願」應沒有直接關係，由於事關重大，而且該權限的運作是黑箱作業，缺乏透明度，如正式重設本地使用者查核是需要更廣泛的諮詢，到時或需要進行投票等方式確認社群支持在本地重設該權限。--Uranus1781（留言） 2025年10月28日 (二) 09:02 (UTC)[回复]
若社群已對恢復CU的意願有初步共識的話未見有投票的需要。--aqurs 🍧 2025年10月28日 (二) 09:12 (UTC)[回复]
徵求意見已是共識機制下最廣泛的諮詢；相反WP:共識不是點票，閣下所指之到時或需要進行投票等方式確認社群支持在本地重設該權限不受方針支持。如同方針所述：我們的目標是提出有說服力的理由來作出決定，而不是根據公開支持的比重來作出決定。如上方論述，經WP:RFC/RFA2025以及上方的延長討論持續已久，所有正當合理的反對意見又已被盡數回應，更有提及通知所有參與者，仍未有人提出就回應意見提出質疑，依方針屬已獲妥善解決的異議。在無有效異議下，自然存在「恢復本地用戶查核的共識」。--路西法人 2025年10月28日 (二) 10:00 (UTC)[回复]
重啟本地用戶查核，與條目內容的編輯爭議、存廢討論及修改方針細節明顯有別，這個權限比管理員、巡查員及回退員所持的權限敏感得多。通過修改方針條文與重啟權限是各自獨立的，即使基金會同意賦權，也不能以目前的條文獲得通過，就立即啟動推選程序。沒有本地用戶查核又不是不行，監管員雖不熟悉中文，但正由於監管員少有在中維活動，不牽涉本地的編輯或管理爭議，純以技術上做出判斷及回覆，其實這也是監管員相對本地查核員的優點，不會捲入本地的地域爭議、用戶組、在站外的通訊群組。--Uranus1781（留言） 2025年10月28日 (二) 10:53 (UTC)[回复]
有關權限敏感的問題為重複提出，在早時討論已獲解決，依共識方針不須重複作回應。至於「不能以目前的條文獲得通過，就立即啟動推選程序」不知是想表達什麼，這不是一個反對恢復選制（即讓本地用戶有機會取得權限）的論據。解凍權限只是基金會恢復承認本地選舉結果，沒人能選上就沒人有這個權限，不代表權限及選制沒有恢復。另，監管員亦可由與本地有關的用戶擔任，本地用戶存在於各種全域體系內，只是當前沒有本地出身的監管員。監管員不涉本地爭議之說並非恆久不變之事實。--路西法人 2025年10月28日 (二) 11:56 (UTC)[回复]

公示期間無有效異議，提案通過。將陸續進行方針修訂。--路西法人 2025年10月30日 (四) 03:32 (UTC)[回复]

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

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

真的「在早時討論已獲解決」嗎，之前的討論強調本地查核員懂中文，但沒有提及監管員不在中維也有明顯的好處，至於本地用戶做監管員是目前不用考慮的話題。不如看看之前的這個回應「安全問題可通過居住在海外地區盡可能規避」，「簽署保密協議的使用者需要提供居住地證明，無法通過隱瞞居住地來簽署保密協議。如果簽署後僑居無法訪問維基媒體的地區，將會撤銷該使用者的保密協議。」請問目前有沒有機制，用戶在中國大陸境外以「規避」方式呈交居住證明簽署保密協議後，在返回或遷居到中國大陸時必須申報，或能夠得知該用戶回到中國大陸而沒有主動提請撤銷其保密協議。--Uranus1781（留言） 2025年10月30日 (四) 03:44 (UTC)[回复]
監管員亦可由與本地有關的用戶擔任，本地用戶存在於各種全域體系內，只是當前沒有本地出身的監管員。監管員不涉本地爭議之說並非恆久不變之事實。沒人說過監管員不能由旅居海外的中國大陸人擔任，也沒有人說過監管員不能由中文維基百科的人擔任，只是當前沒有，監管員不在中維的說法從根基上不成立。--路西法人 2025年10月30日 (四) 03:51 (UTC)[回复]
問您目前有沒有處理用戶簽署保密協議後返回或遷居到中國大陸的機制，主因是之前論及本地查核員需要簽署保密協議時，您提到可以「規避」，可是您在上述的回應並未提到目前有沒有機制處理此情況，不過現時也無意追問下去，畢竟重設本地查核權限是基金會行動。--Uranus1781（留言） 2025年10月30日 (四) 11:20 (UTC)[回复]
毕竟重设本地查核权限是基金会行动。
你确定不是允许重设?--Vertin,do you want to be the timekeeper? 2025年10月30日 (四) 11:30 (UTC)[回复]
我是不明白為何你會覺得在這裡問這個問題會有人能回答你，你該問的是基金會，這不是社群負責稽核的部分。查核員個人隱私資訊只有基金會職員可以接觸，此部分稽核如何處理跟社群本地考量無關。本地能做的都做了，剩餘的就是基金會的問題。--路西法人 2025年10月31日 (五) 01:21 (UTC)[回复]
抱歉，来晚了。Lemonaka说过一句“所有用户查核员都能浏览checkuserwiki，这里面记载了大量的涉及各方的隐私内容，这才是最为危险的”，这推翻了Dbeef所说的“cuwiki只存储长期破坏者（WP:LTA、长期在WP:SPI出没的用户）的信息，此前cuwiki信息泄露，无法代表本地查核日志就被泄露，也无法代表任何人就能直接进行用户查核”
（虽然这和讨论主题不太相关，覆水难收，就算本地不恢复CU权，已经被泄露的信息还是没法倒退回去，更何况我们现在连有没有人非法访问过checkuserwiki、谁非法访问过都不知道，也永远无法知道）--~2025-30706-61（留言） 2025年10月31日 (五) 12:50 (UTC)[回复]
补充：本人不想钻牛角尖，无意和社群共识较劲。--~2025-30706-61（留言） 2025年10月31日 (五) 12:52 (UTC)[回复]
呃，為何你選擇取信從來未曾有權限瀏覽cuwiki的Lemonaka，而不是取信很可能有cuwiki瀏覽權限的U4C成員Dbeef？一個沒有看過任何東西的一般用戶的個人推測「推翻」了很有可能能看到真實情況的委員？這除非Lemonaka不是一般用戶而是某些曾具權用戶的新號，不然不可能有這個「推翻」的邏輯吧。--路西法人 2025年11月1日 (六) 01:31 (UTC)[回复]
Dbeef是enwiki的checkuser、任何项目的checkuser都能访问checkuserwiki => Dbeef能访问cuwiki。另外我完全搞不懂以上所说这里面记载了大量的涉及各方的隐私内容究竟是在说什么。然而无端揣测是很阴谋论了。dbeef（留言） 2025年11月4日 (二) 04:34 (UTC)[回复]
我都忘了你是enwiki的CU了，你確實能直接看到cuwiki（）。另外陰謀論是在說什麼？（節刪）--路西法人 2025年11月4日 (二) 05:02 (UTC)[回复]
这里面记载了大量的涉及各方的隐私内容 为阴谋论。dbeef（留言） 2025年11月4日 (二) 05:04 (UTC)[回复]
啊。我確實不清楚cuwiki能存取到什麼內容，不過這Lemonaka所說的話……還是那句，顯然是不知情者亂說吧，不至於到陰謀論。--路西法人 2025年11月4日 (二) 05:32 (UTC)[回复]
确实不至于，不过....不知道还是建议不要乱讲--Vertin,do you want to be the timekeeper? 2025年11月4日 (二) 07:30 (UTC)[回复]
@LuciferianThomas Lemonaka不是元维基派来的卧底吗（ --~2025-30736-80（留言） 2025年11月4日 (二) 06:16 (UTC)[回复]
这话过分了--Vertin,do you want to be the timekeeper? 2025年11月4日 (二) 07:30 (UTC)[回复]
到底通过了甚么？我看WP:申请成为管理员好像没有改？而且也没有人回复我这条留言，这也能通过吗？ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月4日 (二) 14:31 (UTC)[回复]
Special:Diff/89789957這個？這和修正案也不一樣啊？ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月4日 (二) 14:34 (UTC)[回复]
Special:Diff/89736243。至於你的留言，此處僅為修訂用戶查核員選制以符合基金會要求，並徵詢基金會是否同意解凍。公示文字而說明須待基金會確認才恢復算則，並非單純通過此修訂即恢復選制。--路西法人 2025年11月5日 (三) 01:22 (UTC)[回复]

跟進措施

於Phabricator追踪
工單T408902
狀態：已解決

新開一段作後續跟進。--路西法人 2025年10月30日 (四) 03:34 (UTC)[回复]

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

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

既然是基金會要求，本地既有恢復本地CU共識，選舉規則自然應最少按基金會要求舉行。支持略過公示直接修訂。--路西法人 2025年10月31日 (五) 08:21 (UTC)[回复]
同路西法人，私以爲可以當作事實適應性修訂處理，只需於公告欄通知社羣即可。--1F616EMO（喵留言～求助？） 2025年10月31日 (五) 15:13 (UTC)[回复]
同上述的意見。--Polar Bear 2025年11月1日 (六) 14:12 (UTC)[回复]
已经为CU赋权了安全投票相关权限。——ZhaoFJx(论) 2025年11月4日 (二) 06:12 (UTC)[回复]
对了，原公告所说的learn.wiki和训练是两回事，不是说培训是要在learn.wiki上进行，实际上可能就开一个会普通lecture一下--dbeef（留言） 2025年11月4日 (二) 15:50 (UTC)[回复]

RfC：启用新版Article Wizard

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

2.1版本流程图

本地目前的Article Wizard 1.0版参考英维创建于2010年。2017年，英维因1.0版流程繁琐，换用了2.0简化版本；本地于2018年引入于“WP:条目向导”。现提议启用新版Article Wizard，就部署方案及旧版处置，付社群讨论以企共识。

  • 2.0版本的特点：更优雅的界面，导引按钮更清晰。流程从6步降为5步。仅提供创建草稿选项。
  • 本地2.1版本与英维的主要差异：新增一步“主题与收录标准”，将利益冲突选项提前。

--PexEric 2025年10月6日 (一) 09:43 (UTC)[回复]

@魔琴、ZhaoFJx、Nishino Asuka、Wikij1089、Hehua、Mikelolggmrox、SickManWP、ByH1995：附知PJ:NEW23参与者并于PJT:AFC张贴讨论公告。--PexEric 2025年10月6日 (一) 09:47 (UTC)[回复]
支持。1.0版的UI/UX實在有點老了。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月6日 (一) 09:54 (UTC)[回复]
舊版應當遷移到「/1.0版」，可以考慮和en:Wikipedia:Article wizard/version1, tr:Vikipedi:Madde sihirbazı/1. versiyon用跨語言鏈接連起來。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月6日 (一) 10:00 (UTC)[回复]
比起/1.0版，我倒是覺得可以直接/舊版。--Hamish T 2025年10月7日 (二) 22:57 (UTC)[回复]
哪天2.0也退役了怎麼办（虽然可能是幾十年以後的事） ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月13日 (一) 07:57 (UTC)[回复]
說得好，那就學習Vector，/2010版。--Hamish T 2025年10月21日 (二) 23:40 (UTC)[回复]
(＋)支持--SickManWP❤️邊緣人小組·簽到 2025年10月6日 (一) 12:18 (UTC)[回复]
可。--路西法人 2025年10月6日 (一) 14:02 (UTC)[回复]
表示支持。--ByH1995（留言） 2025年10月6日 (一) 14:44 (UTC)[回复]
(＋)支持 ZhaoFJx(Talk) 2025年10月6日 (一) 15:30 (UTC)[回复]

译名

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

還有一個問題就是，能不能統一譯名。「建立條目精靈」和「創建條目嚮導」的差別實在是有點太大了。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月6日 (一) 10:01 (UTC)[回复]

「精靈」跟「嚮導」是地區詞嗎？因為我實在覺得「嚮導」比較直觀。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月6日 (一) 10:02 (UTC)[回复]
精靈 (軟體)的规则是这么写的。--Srapoj（留言） 2025年10月6日 (一) 10:09 (UTC)[回复]
是地區詞。精靈 (軟體)，Module:CGroup/IT：Item('wizard', 'zh-cn:向导; zh-tw:精靈;'), ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月6日 (一) 10:11 (UTC)[回复]
我在想能不能忽略Wizard这个问题😂，直接将Article Wizard命名为WP:创建条目，并将现在的WP:AFC移动到WP:创建条目流程并参考英维扩充文字作为简介说明页面。--PexEric 2025年10月6日 (一) 10:29 (UTC)[回复]
就算躲掉標題，也不一定躲得掉內文，建議還是趁早釐清為宜。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月7日 (二) 19:58 (UTC)[回复]
既然Eric觉得向导没问题，而且当前版本也确实都叫「向导」，我建议就保持现有译名「条目向导」，不转换地区词。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月7日 (二) 20:08 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

部署

已通過
完成。存档遵从原子页面的繁简。--PexEric 2025年10月31日 (五) 09:35 (UTC)[回复]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

现就部署Article Wizard 2.1版，并统一译名为“条目向导”一事 公示7日，2025年10月22日 (三) 09:59 (UTC)結束。--PexEric 2025年10月15日 (三) 09:59 (UTC)[回复]

公示通过，现给出具体部署方案：

现名称 拟移动名
Wikipedia:建立條目精靈 Wikipedia:条目向导/2010版
Wikipedia:建立條目精靈/basics Wikipedia:条目向导/2010版/basics
Wikipedia:建立條目精靈/不能确定 Wikipedia:条目向导/2010版/不能确定
Wikipedia:建立條目精靈/中立的觀點 Wikipedia:条目向导/2010版/中立的观点
Wikipedia:建立條目精靈/主題 Wikipedia:条目向导/2010版/主题
Wikipedia:建立條目精靈/來源 Wikipedia:条目向导/2010版/来源
Wikipedia:建立條目精靈/內容 Wikipedia:条目向导/2010版/内容
Wikipedia:建立條目精靈/內容/用戶頁 Wikipedia:条目向导/2010版/内容/用户页
Wikipedia:建立條目精靈/內容分歧 Wikipedia:条目向导/2010版/内容分歧
Wikipedia:建立條目精靈/分類 Wikipedia:条目向导/2010版/分类
Wikipedia:建立條目精靈/分類/editintro Wikipedia:条目向导/2010版/分类/editintro
Wikipedia:建立條目精靈/分類/editintro/sub Wikipedia:条目向导/2010版/分类/editintro/sub
Wikipedia:建立條目精靈/创建其它页面 Wikipedia:条目向导/2010版/创建其他页面
Wikipedia:建立條目精靈/删除 Wikipedia:条目向导/2010版/删除
Wikipedia:建立條目精靈/利益衝突 Wikipedia:条目向导/2010版/利益冲突
Wikipedia:建立條目精靈/創建分類 Wikipedia:条目向导/2010版/创建分类
Wikipedia:建立條目精靈/原創研究 Wikipedia:条目向导/2010版/原创研究
Wikipedia:建立條目精靈/可供查證 Wikipedia:条目向导/2010版/可供查证
Wikipedia:建立條目精靈/命名常規 Wikipedia:条目向导/2010版/命名常规
Wikipedia:建立條目精靈/廣告 Wikipedia:条目向导/2010版/广告
Wikipedia:建立條目精靈/建立分類 Wikipedia:条目向导/2010版/创建分类
Wikipedia:建立條目精靈/建立條目 Wikipedia:条目向导/2010版/创建条目
Wikipedia:建立條目精靈/成為維基百科傳記的標準 Wikipedia:条目向导/2010版/成为维基百科传记的标准
Wikipedia:建立條目精靈/收錄標準/數字 Wikipedia:条目向导/2010版/收录标准/数字
Wikipedia:建立條目精靈/收錄標準/書籍 Wikipedia:条目向导/2010版/收录标准/书籍
Wikipedia:建立條目精靈/收錄標準/網站 Wikipedia:条目向导/2010版/收录标准/网站
Wikipedia:建立條目精靈/收錄標準/虛構事物 Wikipedia:条目向导/2010版/收录标准/虚构事物
Wikipedia:建立條目精靈/收錄標準/電影 Wikipedia:条目向导/2010版/收录标准/电影
Wikipedia:建立條目精靈/收錄標準/音樂 Wikipedia:条目向导/2010版/收录标准/音乐
Wikipedia:建立條目精靈/模板 Wikipedia:条目向导/2010版/模板
Wikipedia:建立條目精靈/消歧义页/editintro Wikipedia:条目向导/2010版/消歧义页/editintro
Wikipedia:建立條目精靈/消歧义页/editintro/sub Wikipedia:条目向导/2010版/消歧义页/editintro/sub
Wikipedia:建立條目精靈/消歧义页/preload Wikipedia:条目向导/2010版/消歧义页/preload
Wikipedia:建立條目精靈/消歧義 Wikipedia:条目向导/2010版/消歧义
Wikipedia:建立條目精靈/消歧義頁 Wikipedia:条目向导/2010版/消歧义页
Wikipedia:建立條目精靈/版權常見問題解答 Wikipedia:条目向导/2010版/版权常见问题解答
Wikipedia:建立條目精靈/用户页 Wikipedia:条目向导/2010版/用户页
Wikipedia:建立條目精靈/結束 Wikipedia:条目向导/2010版/结束
Wikipedia:建立條目精靈/維基百科不是什麼 Wikipedia:条目向导/2010版/维基百科不是什么
Wikipedia:建立條目精靈/自傳 Wikipedia:条目向导/2010版/自传
Wikipedia:建立條目精靈/詞典內容 Wikipedia:条目向导/2010版/词典内容
Wikipedia:建立條目精靈/通用收錄標準 Wikipedia:条目向导/2010版/通用收录标准
Wikipedia:建立條目精靈/重定向/editintro Wikipedia:条目向导/2010版/重定向/editintro
Wikipedia:建立條目精靈/重定向/editintro/sub Wikipedia:条目向导/2010版/重定向/editintro/sub
Wikipedia:建立條目精靈/重定向/preload Wikipedia:条目向导/2010版/重定向/preload
Wikipedia:建立條目精靈/重新導向 Wikipedia:条目向导/2010版/重定向
Wikipedia:建立條目精靈/重新導向建立 Wikipedia:条目向导/2010版/重定向创建

说明：因为主页面为简体，希望维持子页面繁简统一，故统一为简体，并修改部分地区词。因上方部署方案仍在讨论未进行公示，为求程序正义，就部署方案再行 公示，爲期7日，2025年10月30日 (四) 07:15 (UTC)結束。并附知@魔琴、Hamish君。--PexEric 2025年10月23日 (四) 07:15 (UTC)[回复]

子页面繁简混用我不清楚是不是就没有规定🤔，若允许的话，其实直接保留混用的繁简即可？--PexEric 2025年10月23日 (四) 07:27 (UTC)[回复]
我認為可以全部保留繁體，連帶前綴。命名規定唯有禁止繁簡混用。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月24日 (五) 19:44 (UTC)[回复]
连同前缀统一的话，不知道有没有其他问题。毕竟主页面创建一个繁简重定向，技术上好像就不是原来的主页面的子页面了？--PexEric 2025年10月28日 (二) 15:08 (UTC)[回复]
沒吧，參考維基專題:電子遊戲/簡訊（ —— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月30日 (四) 02:30 (UTC)[回复]
算了，我保留混用的繁简吧，因为好像本来就是有几个繁简混用的🤣。--PexEric 2025年10月31日 (五) 08:43 (UTC)[回复]
完成。--PexEric 2025年10月31日 (五) 09:21 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

WP:建立條目是否需要修改

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

如题，现时作为Article Wizard的入口点，颇有叠床架屋之感。并且相比英文的Articles for creation，中文名称极其令人困惑。en:WP:Article creation、en:WP:Create an article均重定向至en:Help:Your first article，宜考虑废除此入口点。--PexEric 2025年10月12日 (日) 09:41 (UTC)[回复]

這我記得幾年前也討論過整合問題？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月12日 (日) 13:58 (UTC)[回复]
3年前有提及。不过本次处理的话，我会希望重定向到H:创建第一篇条目。我正撰写其新版草稿，届时WP:创建新条目宜同样并入。--PexEric 2025年10月12日 (日) 14:10 (UTC)[回复]
這之中最早建立的門戶頁面為何？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月14日 (二) 04:48 (UTC)[回复]
看样子应该是Help:创建新条目，本来是技术向的，不知道怎么现在又成没什么内容的门户了。--PexEric 2025年10月15日 (三) 07:15 (UTC)[回复]
不知道这个事怎么推进。还要公示吗？🤣H:创建第一篇条目新版我已经写完，观察本串子讨论最后留言逾3日未有回应，自认为有将WP:建立條目重定向到前者的共识。那就 公示7日，2025年11月7日 (五) 09:46 (UTC)結束。附知@Ericliu1912。--PexEric 2025年10月31日 (五) 09:46 (UTC)[回复]
要直接重新導向，還是標記不活躍即可？如果是合併，記得在編輯摘要或討論頁標記，之類的。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月1日 (六) 12:13 (UTC)[回复]
认为可以直接重定向，理由在上面。--PexEric 2025年11月2日 (日) 05:07 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

是否有必要界定“理由无意义”之反对票？

如果反对票给出的修改意见并不符合事实、或者会让行文变得更差，是否仍应被计为有效反对票？如不，如何界定理由无意义之反对票？--∮♩♪♫♬♭♮♯☧⚧☦︎ 2025年10月20日 (一) 08:24 (UTC)[回复]

建议添加这样的规则：在1个有效反对票被提出后，如果其他编辑有就该反对票的反对理由做出合理回应，或改进且有留言知会提出者，48小时内提出者未能做出回应，则此时第三方（即不包括涉及条目主编）编辑可以针对此反对票添加“已改进”模板，如有2个“已改进”模板，视为该反对票被划去。--∮♩♪♫♬♭♮♯☧⚧☦︎ 2025年10月20日 (一) 08:53 (UTC)[回复]
以我的印象，對不合理、不符合事實的反對票較有力的反制是其他人提出，基於正當理由的支持票，而且反對票不合理的情形越嚴重，其他人的支持票也就會越多，因此我反對針對反對票做特殊的處理（另外，反對票有可能不合理，不符合事實，那支持票是否也有可能如此呢？若是，為何只處理反對票？）--Wolfch (留言) 2025年10月20日 (一) 15:43 (UTC)[回复]
你的印象應該有點過時了，現在投不合理反對票的人會公然出言威脅其他用戶，使其他用戶不敢投支持票反制。（就評選而言）只處理反對票的原因是支持票不須附理由，制訂處理支持票的條文實際上無用，支持票如果附了不合理的理由，那直接移除掉理由就能使支持票重新有效，但反對票是必須附上理由的。Sanmosa 新朝雅政 2025年10月21日 (二) 10:41 (UTC)[回复]
如果这样子的话，安全投票不行吗(--Vertin,do you want to be the timekeeper? 2025年10月22日 (三) 04:51 (UTC)[回复]
這又有點過了吧，評選用不着SecurePoll。Sanmosa 新朝雅政 2025年10月24日 (五) 06:43 (UTC)[回复]
投不合理反对票的人会公然出言威胁其他用户
安全投票不就是防这个的吗？--Vertin,do you want to be the timekeeper? 2025年10月24日 (五) 07:34 (UTC)[回复]
（以每個條目計）評選的參與人數相對RF(D)A而言少很多，評選用SecurePoll屬於殺雞用牛刀了。Sanmosa 新朝雅政 2025年10月24日 (五) 07:52 (UTC)[回复]
这话确实
那就改改
当发生这种情况的时候,管理员(或者其他的什么管理人员)可以要求该条目的评选使用安全投票--Vertin,do you want to be the timekeeper? 2025年10月24日 (五) 07:54 (UTC)[回复]
「已改進」這種說法有問題，假如真的是毫無道理的反對理由的話，那應該做的就是直接不予採納，「已改進」有表示該毫無道理的反對理由仍被全部或部分採納的意思。Sanmosa 新朝雅政 2025年10月21日 (二) 10:46 (UTC)[回复]
经典一真带九假，纠1个真的有的小毛病，带上9条瞎编废话--∮♩♪♫♬♭♮♯☧⚧☦︎ 2025年10月25日 (六) 07:23 (UTC)[回复]
評審的目的是判斷條目是否符合標準，而不是讓條目可以在評審期間改到過關。條目在評審期間根據反對意見作出改善固然是好，但這並不意味著反對票理應無效，提名人理應在提名前已確保條目達標，既然條目在評審期間被發現有問題，這就是有力的一票，不應輕易被劃去。--黑暗魔君（留言） 2025年10月27日 (一) 02:22 (UTC)[回复]
我們有必要在這裏重新開展一次有關評選的本質的爭論嗎？Sanmosa 新朝雅政 2025年10月27日 (一) 10:44 (UTC)[回复]
當時有其他意見表示「現在的評選過程中允許修改使意見消失已經是開了口子了」，我非常同意，評選已經可以允許一邊審一邊改了，再允許反對票可以因為意見得到回應而被強制劃去，那麼反過來反對票是否亦應可以強制劃去此前的支持票？--黑暗魔君（留言） 2025年10月28日 (二) 01:10 (UTC)[回复]
那么本来就是虚假或仅仅是个人偏见的反对理由（例：“我觉得维基百科条目只有不出现汉字和标点符号以外的内容才能进dyk”），可否被划？--∮♩♪♫♬♭♮♯☧⚧☦︎ 2025年10月28日 (二) 02:04 (UTC)[回复]
明顯擾亂的投票可被檢查員劃掉。--黑暗魔君（留言） 2025年10月28日 (二) 03:30 (UTC)[回复]
假如是那种看似中规中矩罗列了一堆理由（可能上千字，七八条），但是仔细核查发现全是假的，或者可能有一条是一个细节上的小问题，剩下的全是虚假或个人偏见式理由的，单靠少数几个检查员能完成核实判断吗？--∮♩♪♫♬♭♮♯☧⚧☦︎ 2025年10月28日 (二) 06:20 (UTC)[回复]
既然都發現全是假的，那麼理應可以輕易反駁，同上所述，「反對票不合理的情形越嚴重，其他人的支持票也就會越多」。--黑暗魔君（留言） 2025年10月28日 (二) 08:02 (UTC)[回复]
需要跟条目内容仔细对照才能核实，现在能活跃关注dyk的检查员有多少，人均要查验多少条目的反对票，怎么可能会都能查的出呢？另外您需注意，人都有厌难心理，如果是自己本来有读过、关注过的条目突然出来一个很长的反对文段，然后去一一核实也就罢了，对于绝大多数路人来说，在评审dyk的过程中，如果他看到一个条目有很长的争论文段，他很可能会觉得这个条目的状态应该比较复杂，判断起来很耗时间，姑且“后面再来看吧”。并不是一定就会“反对票不合理的情形越严重，支持票就会越多”的。恰恰相反，一个不合理的长文段反对意见在现行制度下可以很轻易的摧毁一个本来还不错的条目的被信任感。--∮♩♪♫♬♭♮♯☧⚧☦︎ 2025年10月29日 (三) 11:22 (UTC)[回复]
支持票不是也一樣？很少有人會去核實其他用戶投支持票是否合理，如果用戶向一個不合格的條目投了支持票，那又該怎麼處理？--黑暗魔君（留言） 2025年10月30日 (四) 02:07 (UTC)[回复]
说明现行制度却有许多不足，在一切值得改进的地方都应做改进探索，而不是拿“这个改革不能解决全部问题”阻塞改革--∮♩♪♫♬♭♮♯☧⚧☦︎ 2025年10月30日 (四) 05:17 (UTC)[回复]
不認同有效反對票可以被後來的意見自動劃去是「阻塞改革」？--黑暗魔君（留言） 2025年11月9日 (日) 09:15 (UTC)[回复]
這是你和他對於「有效」的定義不同而已，至於這個不同的背後原因我之前也不是沒和你爭論過。Sanmosa 新朝雅政 2025年11月10日 (一) 00:50 (UTC)[回复]
其實我的意思是我們沒有必要在這裏重新開展一次有關評選的本質的爭論，真要這樣做的話，應該開一個新的討論串。Sanmosa 新朝雅政 2025年10月31日 (五) 08:29 (UTC)[回复]
社群無數實踐經驗顯示，此類限制沒有意義。因為所謂「理由無意義」或「毫無道理」與否，本來就是由社群所定義，而理由本身是可以照抄的，許多時候符合情理，於是不可能就此單獨制定足以解決前述問題的標準，至多是個案處理。我認同Wolfch的看法，社群對於不合理情況，往往會予以反制。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月21日 (二) 13:27 (UTC)[回复]
見上。如果這是能「個案處理」的話，我關注能否就此建立一個具體的機制。Sanmosa 新朝雅政 2025年10月22日 (三) 00:49 (UTC)[回复]
「公然出言威脅」顯然是投票者的問題，不是社群的問題。如果有實際案例，亦請提出讓社群批評。就評選而言，每篇條目內容不一，於是評選標準亦不一，無從談起建立統一官僚機制。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月22日 (三) 15:47 (UTC)[回复]
倒是想到一點，過往個別評選面臨爭議之際，不時經共識暫停程序（包含暫不予以結果），以等待社群討論；這應該也算一種「個案處理」的具體機制，若有必要，可將此種慣例明文載入各該評選規則。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月22日 (三) 15:50 (UTC)[回复]
支持--Vertin,do you want to be the timekeeper? 2025年10月22日 (三) 17:03 (UTC)[回复]
我說的“具體機制”正是如此，我的想法是進一步細化這個現行做法，並再引入一些額外規定。Sanmosa 新朝雅政 2025年10月24日 (五) 06:44 (UTC)[回复]
@静魔魔女已投支持票的人能算第三方麼? 如不能算，即已投支持票的人不能使用「已改善」幫忙劃去反對票。若是這樣，同理兩個未投票的人用了「已改善」劃去反對票，也不應再投支持票，對他們來說還不如直接投支持。所以如投支持票的人不能用「已改善」劃去反對票，這方案沒甚麼意義，但如果能劃，未知大家會否覺得支持方變相多了0.5票。--Underconstruction00（留言） 2025年10月25日 (六) 06:58 (UTC)[回复]
我认为已投支持票的人可以算第三方。--∮♩♪♫♬♭♮♯☧⚧☦︎ 2025年10月25日 (六) 07:24 (UTC)[回复]
在我看來,這就解釋了為什麼劃票不可取。--Temp3600（留言） 2025年11月2日 (日) 07:45 (UTC)[回复]
(？)疑問：在DYKC/GAC/FAC/FLC，我看到反對票的附加理由是「同上」（如使用者A在投反對票時依規定附上意見，下一個投票者隨之附上「同上」），這算不算有效理由？--Sinsyuan✍️PJTW 2025年11月3日 (一) 02:08 (UTC)[回复]
這要看他「同」的「上」本身是否有效的理由了。Sanmosa 新朝雅政 2025年11月3日 (一) 02:13 (UTC)[回复]
除非基本资格不过关，我是很反对同上的，否则岂不是一个没能检查出来的错别字可以被雪球一堆反对票，如果有恶意阻挠式投票的话--∮♩♪♫♬♭♮♯☧⚧☦︎ 2025年11月3日 (一) 11:41 (UTC)[回复]

建议征求意见里添加“翻译”主题

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

探讨缺乏中文来源的内容究竟该如何翻译成中文是经久不衰的议题，很常见，这些讨论应该被集中在同一个分类，不应该被条目内容切割成不同分类--∮♩♪♫♬♭♮♯☧⚧☦︎ 2025年10月28日 (二) 02:00 (UTC)[回复]

我是覺得徵求意見的主題應該按照知識的結構來分類，可以參考圖書分類法。而非將「傳記」「翻譯」等，實際上每項知識要求分得很開的歸為一類。--Ghren🐦🕐 2025年10月30日 (四) 05:58 (UTC)[回复]
我认为应该按探讨的具体问题来分--游魂2025复活版（留言） 2025年10月31日 (五) 05:08 (UTC)[回复]
好像也不是不行，畢竟現在徵求意見通常一定標好幾個主題。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月1日 (六) 12:12 (UTC)[回复]

新條目推薦評選中的支持票會因「投票內容與條目或DYK問題無關」而無效嗎？

本主題或以下段落文字，已移動至Wikipedia_talk:新条目推荐/候选。执行者：1F616EMO（喵留言～求助？） 2025年10月31日 (五) 14:59 (UTC)。移动理由：WP:CON/RULES#POL[回复]

討論通知：维基百科讨论:申请成为管理人员#修訂自由提名下公開投票之執行規範

维基百科讨论:申请成为管理人员 § 修訂自由提名下公開投票之執行規範有用戶正在徵求社群意見，敬請編者關注。

--路西法人 2025年11月3日 (一) 08:02 (UTC)[回复]

整理WP空間可檢索到的主題摘要(或較偏向兩岸四地相關)

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

下面是曾經直接或間接提及台灣相關出生地的討論，比較有參考價值的主題是2017年2月及4月的條目探討、2007年的方針。如果共識沒有變化，大致上針對出生地這個主題，與台灣這個詞相關時，較主流的2種處理模式是"先到先得"或"使用台灣比中華民國台灣省為佳"。因為2007年和2017年都是相當久遠的主題，是否有意見上的變更，社群或許可以提供看法。若沒有需要變更，則仍以過往主題的相對主流意見為主（因共識未被推翻）。

  1. Wikipedia:当前的破坏/存档/2020年3月#Matt_Smith
    • 編輯要與來源一致，但可能存在折衷作法
  2. Wikipedia:当前的破坏/存档/2020年3月#BN73411(Special:diff/58520075)
    • 提報文只提到經常修改人物條目的國籍與出生地資訊，但抓出差異連結，大致上包含但不限於LTA:C7的領域，其他兩岸四地相關模板也有被處理。
  3. Wikipedia:互助客栈/其他/存档/2018年9月#對於使用_台灣_還是_中華民國_的想法
    • LTA:C7(Changshaone)的言論在這邊似乎被刪除，但對討論本身似乎影響不大。但討論因為混有中國主題而離題，產生額外的爭議而無共識。
  4. Wikipedia_talk:避免地域中心/存檔5#反對“但是我們可以在與政府、法律、政治等無關的條目內容中，以台灣作為中華民國的簡稱。”
    • 從發起主題和覆議的帳號及整體話題狀態，應是無效主題。參與者政治意識過度極端，僅針對帳號活動紀錄，似乎有傀儡議題。
  5. Wikipedia_talk:避免地域中心/存檔5#WP:BIAS：“‘台湾省’一词在部分泛绿人士看来可能含侮辱性”？！
    • 概要性陳述即台灣省通常狀況下不使用。
  6. Wikipedia:互助客栈/条目探讨/存档/2017年4月#台湾人籍贯问题
    • 大致上可以得出籍貫仍有意義，但具備或需要使用相關概念的使用者下降
  7. Wikipedia:互助客栈/条目探讨/存档/2017年2月#（代问）1998年以前台湾岛上出生的艺人条目，出生地使用_台湾_还是_中华民国台湾省(Special:Contributions/218.250.217.137、Special:diff/43708878)
    • 總體而言，幾乎不支持將原已經是X灣的替換成中XX國XX省等情形。採先到先得的概念，反之亦然，即原先是中X民X台XX時，不替換成X灣。( π )题外话IP的活動模式很LTA:C7。
  8. Wikipedia:防滥用过滤器/过滤器请求/存档/2018年#標籤在條目內更改國籍模板(2017年2月)
  9. Wikipedia:互助客栈/方针/存档/2007年7月#「台湾」的问题
    • 大致上產生旗幟模板低效無用的觀念，並初步提及出生地的資訊以台灣陳述較佳。主題有一部分離題與中國主題有關。

--Rastinition（留言） 2025年11月4日 (二) 10:04 (UTC)[回复]

@Rastinition：我好奇你是否由此得出了甚麽結論。Sanmosa 新朝雅政 2025年11月4日 (二) 11:46 (UTC)[回复]
我不能肯定我看到的是否是全部，以我的視角看到的可能是
  1. 比較新近且稍牢固的觀點應是遵循可供查證且先到先得，較古老且或許曾被推翻的觀點是用台灣比較恰當。(！)意見個人認為不管意見方向，基本仍須符合"不強調國籍"這個概念，不管用國籍模板或內部連結，多次陳列，都不符合"不強調國籍"的概念。用台灣如果較恰當可能會立基在它屬於代稱，所以剛好符合不強調國籍。
  2. 大致上有相對明確共識的可以照2017年2月的處理(先到先得)，如果混入2017年4月的觀點，或許出生地不再特別陳列籍貫，因為概念及使用不普及。(！)意見個人認為仍有用，可以用再哪些位置需要再確認。
--Rastinition（留言） 2025年11月4日 (二) 12:00 (UTC)[回复]
@Rastinition：你這裏的前提是“共識沒有變化”，然而我不太確定2020年下半年設立CS4D規則的討論是否算共識“有變化”的情形，而現時的CS4D沒有任何有關使用「中華民國」一詞的直接規制，因此可能的方向會是是否需要就此作任何直接規制。Sanmosa 新朝雅政 2025年11月4日 (二) 14:09 (UTC)[回复]
如同台灣省產生有條件不使用的共識，如果談及中華民國不使用，應也是有條件時(不)可使用，滿足哪些條件件下(不)可使用。你檢附的連結稍晚再閱覽。( π )题外话在我發佈的這個主題前1個月內應還有一個還沒形成共識或修改條文完成的討論進行中。--Rastinition（留言） 2025年11月4日 (二) 15:12 (UTC)[回复]
@Sanmosa大概看完，理解原討論中更偏向以事實採認的精神，並大幅簡化敘述。大致上比較明顯有形成共識的，雖然後續有新的討論，但精神沒有被改變，或許有新增。
--Rastinition（留言） 2025年11月5日 (三) 10:39 (UTC)[回复]
@Rastinition：循例提醒一下，命名常規一般不適用於內文。「臺灣」、「中華民國」兩詞的規制理論上是可以來個系統性的重構的，因此你說“明顯不太可能被調整的共識”倒不一定，我現在的想法可能傾向於1950年起（1949年末時中華民國還沒完全失去對中國大陸的控制）表示在金門、馬祖（、東沙羣島、南沙羣島）外的臺灣地區地名時規定使用「臺灣」，其他情況下則規定使用「中華民國」。Sanmosa 新朝雅政 2025年11月5日 (三) 10:53 (UTC)[回复]
大致認知這是基於事實採認的精神，2025-1949=76，把你的概念套入目前的頁面，且形成共識，建立時間少於76年的公司用台灣。這個陳述是基於我認知到你並非只針對人物，所以替換指稱對象。
--Rastinition（留言） 2025年11月5日 (三) 11:07 (UTC)[回复]
“建立時間少於76年的公司用臺灣”也不一定，1945年以前就在臺灣存在的公司也是用“臺灣”，當然內部連結的指向也會有變化。此外，提述1945年至1949年之間的行文中如果不牽涉任何當時的臺灣省以外的地名，而且也不牽涉具體的正式省級行政區劃的話，那我也傾向於用“臺灣”。Sanmosa 新朝雅政 2025年11月5日 (三) 12:53 (UTC)[回复]
你要作什麼？看不懂。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月4日 (二) 11:47 (UTC)[回复]
若要相當簡化動機，以現有或過去的討論禁止LTA:C7、LTA:香港藝人破壞者等類似特徵的操作者針對性的變更或添加國籍模板，或者是在不使用國籍模板時嘗試以其他手段強調特定國籍、屬地、行政區等可以廣義定論為強調國籍的行徑--Rastinition（留言） 2025年11月4日 (二) 12:10 (UTC)[回复]
如果是“添加國籍模板”的行為的話，現有的MOS:ICON能直接規制。此外，WP:格式手册/信息框#國籍與公民權現有的規定有特別說明“當傳主出生的國家／政權與具備國籍／公民權相同時，資訊框應避免使用|nationality=或|citizenship=”，但此條的執行情況似乎不是特別好。Sanmosa 新朝雅政 2025年11月4日 (二) 14:16 (UTC)[回复]
我比較關注的是，原先可能透過國籍模板或國籍的區塊強調國籍，因為被禁止而利用其他區塊強調國籍，如居住地、出生地點，逝世地點，遺體發現地，失蹤地點等任何一個可能有機會植入國籍的區塊，實際上結果等同禁止一個區塊顯示，而試圖用更多區塊呈現，達到強調國籍的目標。這個狀況在近期我注意到的符合部份LTA:C7特徵帳號上顯現。概要的陳述即因為MOS:FLAGCRUFT，改用內部連結自帶的顏色特效達到強調效果，並特意在任何可能可以陳列的區塊展示相關資料即強調特效(如內部連結，重合WP:OVERLINK)。--Rastinition（留言） 2025年11月4日 (二) 15:12 (UTC)[回复]
顺带，旗帜废除之后很多地方写[[臺灣]]，但其实应该是[[臺灣地区|臺灣]]。不会有谁出生地或者什么销售区域写「海南岛」的，「台湾」也同理。要不就把「台湾」移到「台湾岛」，把「台湾」重定向到「台湾地区」。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月4日 (二) 16:20 (UTC)[回复]
整篇「臺灣」條目現在是四不像，又中華民國，又臺灣島。或許這倒是符合事實啦，但百科全書是有分工的。倒是中華民國條目被改到現在這樣，效果雖然見仁見智，但內容上剛好能跟多數地方寫「臺灣」實際上應指示的目標配合。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月4日 (二) 16:46 (UTC)[回复]
你不介意和KOKUYO再冗長辯論的話，你可以正式提議這樣做。我之前也不是沒有這樣做過，但沒能討論出甚麼來。Sanmosa 新朝雅政 2025年11月5日 (三) 01:12 (UTC)[回复]
怕了。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月5日 (三) 06:28 (UTC)[回复]
我不知道KOKUYO的那些冗長辯論能不能算“嚴重用戶衝突”，如果算的話，那這可能能走仲裁流程。這裏正好有仲裁員，我直接讓仲裁員在這裏給個初步判斷就是了。Sanmosa 新朝雅政 2025年11月5日 (三) 10:43 (UTC)[回复]
不如先修訂格式手冊，同時允許使用「[[臺灣]]」跟「[[臺灣地区|臺灣]]」，至於具體怎麼統一，可以後議。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月6日 (四) 16:07 (UTC)[回复]
我擔憂允許使用「[[臺灣地區|臺灣]]」相當於暗示「臺灣（福建省）金門縣」、「臺灣（福建省）連江縣」的表述是合理的，因為金門、馬祖等地也屬於臺灣地區。Sanmosa 新朝雅政 2025年11月7日 (五) 02:23 (UTC)[回复]
如果「臺灣」的主要含義是臺灣地區而非臺灣島、臺灣島及其附屬島嶼（≈1949年之臺灣省）、今日臺灣省，那麼寫「臺灣金門縣」其實是合理的。衹是可能會引發誤解和不必要的爭端，所以因而繼續禁止這樣的寫法也是有道理的，比如要求這種情況下寫出「地區」兩字。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月7日 (五) 03:00 (UTC)[回复]
不斷言是否比較適當，但套用這個主題WP:互助客栈/求助/存档/2025年10月#資訊框中「國家」一欄是否應該帶有連結的概念處理或許可行。或許可延伸出不承認也不否認的作用。不承認也不否認屬於任一種連結所代表的對象。--Rastinition（留言） 2025年11月7日 (五) 15:33 (UTC)[回复]
可以就此規定，本來不能用的，今後仍不能用。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月8日 (六) 14:37 (UTC)[回复]

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

本主題或以下段落文字，已移動至Wikipedia:互助客栈/其他。执行者：Eric Liu 創造は生命（留言・留名・學生會） 2025年11月9日 (日) 15:25 (UTC)。[回复]

「Wikipedia talk:格式手册/标点符号#明確消歧義括號不應用在條目正文」正在公示

Wikipedia_talk:格式手册/标点符号#明確消歧義括號不應用在條目正文正在公示，爲期7日。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月9日 (日) 16:29 (UTC)[回复]

技術

提議：高亮哈佛参考文献格式短鏈指向的完整資料引用

此已存檔的討論仍有未完的部分，因此從存檔中粘貼過來，還盼望各位有所關心。—— 　桁霽　 ↹　晚來天欲雪，能飲一杯無　　 2025年7月25日 (五) 00:47 (UTC)[回复]

存檔前討論

具體而言，點擊引用部分的的短鏈（t:sfn或t:harvnb）後，讓頁面在跳至完整文獻引用處的同時，使之高亮。有時完整文獻列表處分兩欄顯示，部分情形下讀者須對照原短鏈確認具體所指。不知道在技術上能否實現，亦不知是否有他人支持。個人認為這是一個讓本站更加讀者友好化的提議，姑且一言。—— 　桁霽　 ↹　晚來天欲雪，能飲一杯無　　 2025年6月27日 (五) 09:39 (UTC)[回复]

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

感謝@Diskdance君、@Eric君、@Hamish君、@Kcx36君諸位傾力支持，無論是技術上還是決策上。下一步是否需要提請社群表決？還是直接應用？—— 　桁霽　 ↹　晚來天欲雪，能飲一杯無　　 2025年7月13日 (日) 02:37 (UTC)[回复]

新討論

來日瀏覽條目，越發堅信此舉錯確為必要，希望此懸而未決之議有所進展。—— 　桁霽　 ↹　晚來天欲雪，能飲一杯無　　 2025年7月25日 (五) 00:47 (UTC)[回复]

其實你可以直接貼上原討論連結（ —— Eric Liu 創造は生命（留言・留名・學生會） 2025年7月25日 (五) 06:33 (UTC)[回复]
支持進行高亮，建議添加進模板樣式內，因MediaWiki:Common.css會在所有頁面加載。--1F616EMO（喵留言～回覆請ping） 2025年7月25日 (五) 14:33 (UTC)[回复]
见Module_talk:Citation/CS1/styles.css#編輯請求_2025-08-14。--PexEric 2025年8月14日 (四) 10:28 (UTC)[回复]
好像没效果？--碟之舞📀💿 2025年8月17日 (日) 14:58 (UTC)[回复]
模板样式没加载，所以需要更新CS1模块。--Dabao qian℡ 2025年8月17日 (日) 16:49 (UTC)[回复]
	return table.concat ({
		frame:extensionTag ('templatestyles', '', {src='Module:Citation/CS1/styles.css'}),
		do_citation (config, args)
	});
end

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

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

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

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

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

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

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

@Jeffchu2014、Dabao qian、YFdyh000、重庆轨交18、TimWu007、1F616EMO、Cwek：考慮到手工添加分類極不利於維護，也為避免上面接近遊戲規則的編輯操作繼續，本人建議：為Bd模板「臨時」引入生卒月、日參數（同時刪除所有條目的手動分類）；惟目前就此議題本身暫時不置可否，留待後續討論，並應於Bd模板說明頁面強調有關參數之技術性（尚未正式達成共識）。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年8月21日 (四) 08:35 (UTC)[回复]

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

現向社群徵求意見，命題為：「本站（中文維基百科）是否應為傳記條目添加生卒日期分類，如『分類:10月10日』？」—— Eric Liu 創造は生命（留言・留名・學生會） 2025年8月27日 (三) 08:06 (UTC)[回复]

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

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

{{transl}}模板跳红字

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

最近发现多个使用 {{transl}} 的国家条目都跳红字（如阿塞拜疆，伊拉克，均已修改）。推测是近年3月该模板修改后的结果，使得很多原来可接受的不规范写法现在都显示为红字。大量国家条目都使用该模板，阅读量高，频繁红字的观感不佳，容易给读者留下本项目的不佳印象。是否有办法排查？或者，是否有办法加强其兼容性，使得不规范写法不显示为红字？--三猎（留言） 2025年10月4日 (六) 09:59 (UTC)[回复]

应该都在Category:Transliteration模板错误。我没研究这个模板参数的变迁，先ping一下修改该模板的@Vozhuo。--Srapoj（留言） 2025年10月4日 (六) 14:46 (UTC)[回复]
好欸，有汇总的话就可以先改起来了。——三猎（留言） 2025年10月5日 (日) 05:19 (UTC)[回复]
lang系列模板時不時出問題，那麼久了都還沒修完，竟然還有人想著把舊模板刪了，XD —— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月4日 (六) 18:03 (UTC)[回复]
发现一个非常典型的问题，就是{{transl}}会内嵌在一些模板中，当编者想要加入中文说明时，就会跳红字。例如卜肉条目。——三猎（留言） 2025年10月5日 (日) 05:46 (UTC)[回复]
这个有人在Template talk:Taiwanese报过，还没人处理。--Srapoj（留言） 2025年10月5日 (日) 08:44 (UTC)[回复]
我在Module:Lang/sandbox改了一個儘量顯示內容、不直接報錯的版本。——枰（留言） 2025年10月31日 (五) 06:33 (UTC)[回复]
請關注Module talk:Lang§有關更新模組以提升對不規範用例的兼容性。——枰（留言） 2025年11月1日 (六) 08:04 (UTC)[回复]

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

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

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

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

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

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

翻查制定时的讨论，發现「官方宣佈」一段衹是假想的豁免条款。因此建议直接删掉。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月19日 (日) 20:55 (UTC)[回复]
建議分開討論。無論如何，不應在過渡期考慮此類最終措施。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月20日 (一) 16:30 (UTC)[回复]
MOS:空格「在反映一个具体数量时」一段似乎也是渲染需要，而且也有争议（Wikipedia_talk:格式手册/存档4#空格），不知道是否能够一併通过渲染手段处理？ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月19日 (日) 20:56 (UTC)[回复]
要是手动把单位部分标记出来自然是能处理的，否则应该没办法——毕竟程序无法自动区分一串文字是「数量加单位」还是「产品型号」或者别的什么东西。
另外text-autospace只管汉字和日文假名与字母和数学之间的空白，管不到别处。--lilydjwg 交流 2025年10月20日 (一) 04:31 (UTC)[回复]
「在阿拉伯數字與計量單位字母符號之間插入一個空格」是英文也會遵守的格式，因此text-autospace不管這個。
沒學過西文標點符號用法的可能不知道這個格式的由來；在西文中，阿拉伯數字和計量單位也被算作单词，故需要用空格隔開。舉個例子：
The supermarket is 1.5 kilometers away. => The supermarket is 1.5 km away.
因此，添加這個空格是西文書寫的常識，不論是現在還是以後我看都不會被text-autospace或是其他CSS特性接管，還是乖乖寫空格吧。--SuperGrey (留言) 2025年10月20日 (一) 07:14 (UTC)[回复]
但这不是中文，所以可能要用某種其他方式解决？ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月20日 (一) 09:32 (UTC)[回复]
什麼其他方式？自己加個空格就好了。--SuperGrey (留言) 2025年10月20日 (一) 09:42 (UTC)[回复]
我的意思是在中文環境下可能不應該加空格。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月2日 (日) 11:45 (UTC)[回复]
沒聽說過這種「可能」……--SuperGrey (留言) 2025年11月2日 (日) 17:48 (UTC)[回复]
参见先前讨论。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月3日 (一) 03:40 (UTC)[回复]
现在加空格的格式已实践已久，再改回去工程量较大。况且GB 3100-1993要求要有“空隙”，加空格又不是错的（反而当年有人坚持的不加空格且不做任何调整才是错误用法）。--Steven Sun（留言） 2025年11月3日 (一) 08:35 (UTC)[回复]
那还是不动这边了，继续“建议”下去，相信後人的智慧 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月3日 (一) 09:21 (UTC)1[回复]
在这里做了个纯CSS版本，供各位参考。--碟之舞📀💿 2025年11月2日 (日) 11:32 (UTC)[回复]
(＋)支持 --Steven Sun（留言） 2025年11月2日 (日) 12:20 (UTC)[回复]
@Diskdance：建議把chws也寫進去。--SuperGrey (留言) 2025年11月2日 (日) 17:50 (UTC)[回复]

本討論章節會維持開放直到2025年11月30日 (日) 16:00 (UTC)，暫時不按最後意見發表時間存檔。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

生僻字webfont

过往讨论应有提到透过webfont解决生僻字显示问题。有以下挑战：1.生僻字界定。各系统的字库支持情况不明。如果要支持{{僻字}}模板以外出现的字，一种可能的解决方法是动态判断显示效果，但兼容性问题又是大坑。2.动态分包。书生有提到如字蛛，但他说的普遍存在一些问题我不太清楚。我尝试了一下cn-font-split，似乎效果还可以，能基本做到为每个页面动态分包。不过，每次不同的新页面都要重新分一次包，还就那一两个字，有点大炮打蚊子了😂；理想的方案是为每个字（高频字）预先分出一份woff2文件，这就牵扯下面的静态资源托管问题。3.托管。现成只能用Toolforge。但我想没有专门的CDN，很难支持本站的访问量？要做这种事，必须经由基金会，社群如何参与/以何种形式参与不得而知？

跑了一个User:PexEric/数据库报告/生僻字，全站拢共出现的也就1059个字，比较省事的做法或许是一次性打包为一个字体文件（测试后大概不到200KiB），定期维护更新（像维护繁简转换表一样）？--PexEric 2025年10月19日 (日) 13:27 (UTC) 👍1[回复]

附知书生、魔琴和刘君；以及我觉得在这个问题上或许有见解的@Diskdance、SuperGrey。--PexEric 2025年10月19日 (日) 13:39 (UTC)[回复]
最理想的就是由基金會託管生僻字字體，比如天珩全字庫(TH-Tshyn)支援到了Unicode 17.0，然後採用預分包的方式，即cn-font-split載入（不必動態，做靜態的分包就可以了）。我覺得不應篩選限定範圍在1059字內，我對有基金會參與的「定期維護更新」不太樂觀 😂（很可能變成無人打理的廢墟），而使用全字庫的好處就是，下次Unicode 18.0暫時沒有漢字，預計這次託管字體後，至少兩三年內不必再更新維護。--SuperGrey (留言) 2025年10月19日 (日) 21:48 (UTC)[回复]
雖然全字庫字體看起來很大，但是只要用cn-font-split拆分得足夠細，每次實際被加載的字體大小可以做到很小。@PexEric你可以測試一下。--SuperGrey (留言) 2025年10月19日 (日) 21:52 (UTC)[回复]
天珩恐怕存在商用侵权问题，那个描述像是“侵删”。不确定文津宋体是否可靠和适用。--YFdyh000（留言） 2025年10月19日 (日) 22:59 (UTC)[回复]
看起來也支援到Unicode 17.0了，不錯。--SuperGrey (留言) 2025年10月19日 (日) 23:03 (UTC)[回复]
数據库报告衹有用了僻字模板的吧，实际不知道会不会多。另外，这個僻字模板裏面什麼都有啊…… ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月19日 (日) 22:40 (UTC)[回复]
實際可能會比1059個字多很多，全站跑了一次User:What7what8/生僻字統計--User:What7what8🏠 2025年10月23日 (四) 17:53 (UTC) 👍1[回复]
这么说，突然又想到一个统计上的难点😂。有些在源代码中或许不是“生僻字”，经过转换表类推简化成简体字后可能就是“生僻字”了。--PexEric 2025年10月23日 (四) 18:10 (UTC)[回复]
好奇您是怎么做的？拿基金会每月的xml dump然后匹配文字吗？@What7what8：
PexEric用的paws脚本倒是能直接翻出来：https://public-paws.wmcloud.org/User:PexEric/1%20time/pizi/Untitled.ipynb --Srapoj（留言） 2025年11月4日 (二) 21:50 (UTC)[回复]
动态分包存在问题是我好几年前了解的，现在可能已经不是问题了？以前的问题就是不是每次split都会成功，有小概率失败（好像不同字体失败的地方还不一样？）好像google字体工具不支持中文字体的分包也是出于这个原因--百無一用是書生 (☎) 2025年10月20日 (一) 03:13 (UTC)[回复]
另外，“为每个字（高频字）预先分出一份woff2文件”，其实完全可以用字形wiki的数据。我觉得比较合适的方法是用字形wiki的数据，转成woff2格式，然后托管在toolforge。对了，好像基金会那边有个豆腐字检测算法，不知道能不能用得上--百無一用是書生 (☎) 2025年10月20日 (一) 03:20 (UTC)[回复]
T65122、T135465，在4f3461a被移除了。要做的话，本地小工具可以做。不清楚站内谁有这个能力😂。--PexEric 2025年10月20日 (一) 07:27 (UTC)[回复]
以前写过一个小工具，是依托字形wiki提供的API，但后来不允许跨站点脚本，字形wiki中间还出过很长一阵子技术问题，小工具就没法用了。要重新弄的话，需要全部数据本地化（至少是toolforge），工程量一下子就大了很多，许多地方要想清楚规划好（而且字体生成这一块我是真不太会了）--百無一用是書生 (☎) 2025年10月20日 (一) 07:43 (UTC)[回复]
對的，我建議就用靜態的分包。--SuperGrey (留言) 2025年10月20日 (一) 07:18 (UTC)[回复]
其实更懒一些的话，直接把字形wiki的数据全部或部分制成webfont格式，然后配合豆腐字检测算法，应该就能搞定绝大部分。但其实我觉得IDS方法或许会更好一些（如果能把生成图片改为生成字体）--百無一用是書生 (☎) 2025年10月20日 (一) 07:35 (UTC)[回复]
可以做一个基于KAGE2的动态生字引擎，并以类似LaTeX的形式作为MediaWiki扩展，这个就是后话了。字统网好像也是这样处理生僻字SVG的。--PexEric 2025年10月20日 (一) 07:51 (UTC)[回复]
简单说一下我的思路，没什么新的😂，还是小工具+Toolforge。在Toolforge为每个生僻字（如上预先统计过的1059个字）都独立分为一个woff2包托管。遇到新的字，再请求给Toolforge分包并缓存，下次直接命中缓存。还有不用JS的方案，利用TemplateStyles为每个字编写font-face css，字体文件（woff2）以base64硬编码存储（可能要改mw:Extension:TemplateStyles#Configuration的实现，比如允许base64的文件）。测试了单个汉字的woff2不到1KiB，写成base64不会太夸张。这个两个方案可以同时进行，比如高频生僻字直接请求站内css，减少网络请求。--PexEric 2025年10月20日 (一) 07:47 (UTC) 👍1[回复]
如果Toolforge程式真的做到無人值守、自動分包+緩存，感覺挺不錯。--SuperGrey (留言) 2025年10月20日 (一) 07:52 (UTC)[回复]
我觉得最好把字体文件base64后塞进JS、由机器人更新到站内。这样才能利用ResourceLoader的基础设施（主要是CDN以及本地的长缓存时间），也是用JS而非CSS的原因。
但说实话，我感觉这样一套机制的复杂度像是可以拿出去卖方案的程度了（虽说有时候商业公司产品可能没比优秀的本科生作业强太多），即使做出来了真的能长期维护吗？--Srapoj（留言） 2025年10月30日 (四) 20:56 (UTC)[回复]
User:PexEric/数据库报告/生僻字在我电脑上大概有20几个字显示不了--百無一用是書生 (☎) 2025年10月21日 (二) 02:11 (UTC)[回复]

字体与字形

最大的问题应该还是字体本身。首先风格来说，数位时代的屏显字体基本都是黑体，如果生僻字换成宋体，我个人觉得可能比较奇怪😂，不知道各位怎么想。不过unihan标准本身（以及字形wiki、传统的大字集字体等）倒是以宋体为基准。或者就是走黑体+宋体的双轨制，我目前觉得没有必要。其次就是地区字形问题，可能需要根据地区，使用不同的字体。比如部分中国大陆字体会“假想G源”，与unihan标准本身不符，但是对于大陆用户似乎还可以接受？最后就是版权，大字集+无版权风险，只能选择现有的开源项目。（毕竟不能每个字都本站单独设计吧😂，而且要保证风格统一。）要为不同地区分包选取字体项目，并取得社群共识。--PexEric 2025年10月20日 (一) 08:09 (UTC)[回复]

能顯示出來就很不錯了，生僻字不要講究那麼多。明體(宋體)就明體，難看就難看，@YFdyh000找到的「文津宋體」就OK了。--SuperGrey (留言) 2025年10月20日 (一) 08:16 (UTC)[回复]
也不必考慮地區字形，生僻字就用Unicode規定的字形即可。--SuperGrey (留言) 2025年10月20日 (一) 08:17 (UTC)[回复]
也许是我理解错了，不过Unicode code chart的字体仍是由商业公司提供的，条款[2]限制了复用。--Srapoj（留言） 2025年10月30日 (四) 20:56 (UTC)[回复]
陆标的话，我觉得文津宋体和遍黑体就是最佳的，没有更好的了。台标的话可以考虑源樣黑體，fallback到隙间黑体，明体可以考虑花园明朝和Jigmo。--PexEric 2025年10月20日 (一) 08:24 (UTC)[回复]
優先考慮黑體，但是如果有明體支援更多，那就用明體。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月20日 (一) 16:28 (UTC)[回复]
btw，不知道目前支援最多漢字的字體是什麼？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月21日 (二) 15:03 (UTC)[回复]
又看到一個支援Unicode 17.0的宋體字：全宋體。--SuperGrey (留言) 2025年10月22日 (三) 01:57 (UTC)[回复]
基于KAGE的全汉字无衬线字体：LorchinSans--PexEric 2025年10月24日 (五) 18:15 (UTC) 👍1[回复]
如果字體放很多，會不會影響效能？如果會，怎麼折衷？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月26日 (日) 06:47 (UTC)[回复]
如果用cn-font-split拆分得足夠細，理論上對性能的影響有限。不過還需PexEric君實測。--SuperGrey (留言) 2025年10月26日 (日) 09:20 (UTC)[回复]

隐私问题

由于基金会已经声明不会支持添加新字体到WebFonts，而且Toolforge不符合维基百科的隐私方针（WMCS使用自己的隐私方针），另外维基百科上只允许版权开放的字体。这几点综合看，目前是不能解决生僻字显示问题的，至少读者必须注册维基百科账号，并且主动同意WMCS的隐私方针，启用并非默认启用的小工具才行。--Midleading（留言） 2025年10月30日 (四) 15:35 (UTC)[回复]

搞不懂他们的政策。看那意思像是要管托管在wmcs的js和wmcs工具中的非wmf站点请求。看mw:Requests for comment/Content-Security-Policy，分发字体应该属于Stage 7，倒也提到了诸如MapSources可允许例外；我想必要时说明本站的情况，或许可成为例外。wikitech:Wikimedia_Cloud_Services_team/EnhancementProposals/Third-party_interaction_consent_tool可能也相关，但是去年的新倡议。总结是目前好像没有具体限制措施？要是预设脚本不能请求toolforge，那我真白干了😅。那去做成MediaWiki扩展，封装成API，正好我还嫌Toolforge性能不行呢，直接用Wikipedia的infrastructure，只要不觉得API乱。--PexEric 2025年10月30日 (四) 16:24 (UTC)[回复]
在WMF站点部署新扩展的流程很麻烦(mw:Writing an extension for deployment)，建议死心（--Srapoj（留言） 2025年10月30日 (四) 17:26 (UTC)[回复]
ULS的webfont已叫停（T135464），加载woff2文件都不行的话，确实属于堵死这个事了。当然真到那种时候，相信本地社群能找到IAR的自洽。--PexEric 2025年10月30日 (四) 17:48 (UTC)[回复]
基金会的人怎么配置软件不是社群自治能决定的，IAR管不着。--Srapoj（留言） 2025年10月30日 (四) 20:56 (UTC)[回复]

Sometimes, volunteers may place a data-collecting tool, such as a script, gadget, tracking pixel, or share button, on a Wikimedia Site without our knowledge. This Policy does not cover how third parties handle the information they receive as a result of such a tool. If you come across such a third-party tool, and you believe it violates this Policy, you can remove the tool yourself, or report it to privacy@wikimedia.org so we can investigate.

[...]

If you ever come across a third-party data collection tool that has not been authorized by you (such as one that may have been mistakenly placed by another user or administrator), please report it to us at privacy@wikimedia.org.
— wikimedia:Policy:Privacy policy

考虑到隐私政策中personal data包括IP地址［和user agent信息］等，我的理解是使用外部资源的小工具都是"data-collecting tool"，所以需要opt-in。我搜到的还有m:Third-party resources policy，但和PexEric找到的两个一样都是草案状态。另见wikitech:Wikitech:Cloud Services Terms of use。
说回来，我认为默认启用的、会连接到第三方控制的服务器（即使是toolforge/WMCS）的脚本便会引发问题，包括WMF隐私政策以及服务器运维（毕竟本站的请求量不小）。--Srapoj（留言） 2025年10月30日 (四) 20:26 (UTC)[回复]
正常情况下toolforge/WMCS上的访问日志是不记录IP地址的--百無一用是書生 (☎) 2025年10月31日 (五) 03:34 (UTC)[回复]
抱歉因为没用过所以不了解toolforge网络配置的细节。我想那就是WMCS ToU §7.2单独出现的原因了。按照wikitech:Help:Toolforge/Web以及wikitech:Portal:Toolforge/Admin/Kubernetes/Networking and ingress，我猜用户请求的IP是被某层nginx隐藏了、没写进Forwarded头？--Srapoj（留言） 2025年10月31日 (五) 12:39 (UTC)[回复]
真是我知识盲区了😂……下面搬出Gemini：

根据您提供的文件和图表，是的，Toolforge 开发者在技术上可以获取用户的部分信息。

文件本身主要描述的是网络拓扑和架构，而不是数据隐私政策。然而，从这个架构和文件中提供的日志示例可以推断出以下几点：

1. 工具（Tool Pod）的特性

用户的请求最终会到达“actual tool pod”（图中的步骤9）。这个“pod”是工具开发者自己编写和控制的应用程序。为了让工具能够响应用户的请求，它必须接收到请求的详细信息。这些信息通常包括：

  • 用户请求的 URL 路径和查询参数。
  • HTTP 标头（Headers），其中可能包含：
    • User-Agent：用户的浏览器、操作系统等信息。
    • Referrer：用户在访问该工具之前所在的页面。
    • X-Forwarded-For：用户的原始 IP 地址（尽管文件中未明确提到，但这是代理的标准做法）。

2. 日志中记录的信息

在“How to test the setup”部分，文件展示了 nginx-ingress（步骤4）的日志示例。这些日志明确显示系统会记录可被视为隐私的信息：

  • IP 地址：示例中显示了 IP 地址（例如 192.168.50.0），尽管这可能是内部代理的 IP，但它仍然是访问链的一部分。
  • 完整的请求路径：例如 GET /potd-feed/potd.php/commons/potd-400x300.rss HTTP/1.1。
  • User-Agent：例如 FeedFetcher-Google; (+http://www.google.com/feedfetcher.html) 或 Mozilla/5.0...。
  • Referrer（来源页）：例如 "https://tools.wmflabs.org/wikisense/Gallery.php?&wikifam=commons.wikimedia.org&img_user_text=Hoanglong2807"。

有权访问这些日志的系统管理员或开发者可以看到这些信息。

3. HTTPS 终止

文件在描述 haproxy（步骤2）时提到，它负责“terminating inbound HTTPS traffic”（终止入站 HTTPS 流量）。这意味着在 haproxy 之后，流量在 Kubernetes 集群内部（从 haproxy 到 nginx-ingress 再到 actual tool pod）是以未加密的形式传输的。

总结：是的，该架构允许（并且为了工具能正常运行而必须）将用户的请求数据（包括 URL、User-Agent、Referrer 等）传递给工具开发者控制的“actual tool pod”。此外，系统的中间组件（如 nginx-ingress）会记录这些信息，有权访问日志的管理员也可以看到这些信息。

--PexEric 2025年10月31日 (五) 13:15 (UTC)[回复]
toolforge上的访问日志大概是这样：
192.168.209.148 itnsyn.toolforge.org - [16/Aug/2022:14:20:06 +0000] "GET / HTTP/1.1" 200 125991 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:103.0) Gecko/20100101 Firefox/103.0"
记录的IP地址用的全都是C类的内网IP--百無一用是書生 (☎) 2025年11月2日 (日) 07:24 (UTC)[回复]
“data-collecting tool”从下面的“third-party data collection tool”看和例子看，不像是指客户端获取外部数据吧，毕竟外部的服务端没有data collection的逻辑（我也没那本事😂）。当然，toolforge自身的networking可能有对IP、UA等的记录？--PexEric 2025年10月31日 (五) 03:37 (UTC)[回复]
根据foundation:Policy:Privacy_policy#Definitions，IP address和user-agent information都是隐私信息，不光是IP。另外维基百科用户浏览器支持的字体可以算是user-agent information，因为可以用来构成浏览器指纹。--Midleading（留言） 2025年10月31日 (五) 04:14 (UTC)[回复]
看了看。对于WMCS，wikitech:Wikitech:Cloud Services Terms of use管的是开发者，而wikitech:Wikitech:Cloud Services End User Terms of use才是管使用者。按照前者和Toolforge的规则，我的项目已经开源，没有也没能力写收集IP、UA等隐私信息的逻辑。后者则没有提及如何处理隐私信息，按照wikimedia:Policy:Privacy policy的意思，那就是遵循基金会的通用隐私方针。Toolforge自身的networking有没有收集隐私信息，这与WMF直接相关，已经不属于third party。用户浏览器支持的字体更不可能了，没有浏览器提供这种接口，不然不会有那么多旁门左道。--PexEric 2025年10月31日 (五) 08:20 (UTC)[回复]
但Toolforge的配置让您能够得知UA信息。（按照我的理解，WMCS End User ToU已经把WMF/WMCS撇清成GDPR意义上的data processor（中国大陆PIPL的“受托人”）；而您作为WMCS上服务的开发者，是需要提供一份隐私政策的data controller（PIPL“个人信息处理者”）。）
但对于Toolforge的情况，收集访问日志（包括IP）的做法属于平台自己决定purposes and means（PIPL“自主决定处理目的、处理方式”）的范畴，开发者甚至看不到数据，所以他们仍是这部分数据的data controller？（disclaimer：我不是律师，并且常识是个人服务通常不会被找茬。单纯的访问日志在GDPR下应该能算作无需consent的legitimate interest类用途）--Srapoj（留言） 2025年10月31日 (五) 12:39 (UTC)[回复]
回头看了一遍WMCS End User ToU，里面说WMF隐私政策适用于所有Toolforge项目；且它连同WMCS ToU都在privacy statement要求部分排除了Toolforge。我感觉最好还是写信问基金会能否允许默认启用使用toolforge的脚本。@Midleading：--Srapoj（留言） 2025年10月31日 (五) 22:39 (UTC)[回复]
Jdforrester (WMF)：Note that hot-loading from the Toolforge CDN on a production Wikimedia site without user opt-in consent is a privacy policy violation, as the Toolforge privacy policy is different.──Project:Village Pump/Flow上的Add Chart.js as a hidden gadget。似乎不行。--YFdyh000（留言） 2025年11月1日 (六) 11:25 (UTC)[回复]
这是用Toolforge CDN热加载站外资源，可能和这种情况还是有点区别。--PexEric 2025年11月3日 (一) 06:20 (UTC)[回复]
如果需要opt-in的话，其实相当于没有默认启用。--碟之舞📀💿 2025年11月6日 (四) 06:17 (UTC)[回复]
其实应该能通过设计好引导流程、让有需要的用户能主动打开目前这版已经实现的网络字体开关配置界面吧（比如显示一个气泡、过几秒或有动作就消失）。（倒是想起您第一版Variant Ally的弹窗--Srapoj（留言） 2025年11月6日 (四) 20:52 (UTC)[回复]
顶置横条会更醒目便捷吧，但是否与UI政策抵触。可能需要一个“不再显示”，记录于账户和/或cookie。不清楚需要怎样的“隐私声明”。--YFdyh000（留言） 2025年11月7日 (五) 09:48 (UTC)[回复]
“不再显示”的Cookie也会违反Cookie声明。（除非我们获得您的允许。否则我们绝对不会在我们的维基站上使用第三方Cookie。）正确的做法是在没有Cookie时，认为用户不同意使用该功能并且不同意存储第三方Cookie。--Midleading（留言） 2025年11月9日 (日) 04:44 (UTC)[回复]
第三方在哪？--PexEric 2025年11月9日 (日) 04:45 (UTC)[回复]
第三方是Toolforge，Toolforge与维基百科不是一个域名。--Midleading（留言） 2025年11月9日 (日) 04:47 (UTC)[回复]
“不再显示”横幅的cookie需要何种Toolforge的技术？--PexEric 2025年11月9日 (日) 04:52 (UTC)[回复]
PexEric想象中的Cookie應該是存於瀏覽器本地的吧？或者建立User:<帳戶名>/webfont.json 之類的。並不存於Toolforge。 --SuperGrey (留言) 2025年11月9日 (日) 07:19 (UTC)[回复]
真要设置cookie也是放在域名zh.wikipedia.org下的，不会被浏览器发送到toolforge的域名，所以不算第三方cookie。况且这种配置也可以放在浏览器的localStorage里，无需发给服务器（隐私法律的要求我就不清楚了，印象里存non-essential的cookie类似物的动作就需要consent，但客观地说这种配置项能用于追踪的信息量很小）。--Srapoj（留言） 2025年11月9日 (日) 13:41 (UTC)[回复]

成果

见下。--PexEric 2025年10月31日 (五) 08:22 (UTC)[回复]

a6d6337d77.catalyst.wmcloud.org可以在线体验。［目前暂时设置一个月有效期。］--PexEric 2025年10月31日 (五) 13:25 (UTC)[回复]

申请向ULS加入大字库字体

根据上方讨论，现考虑申请向ULS加入大字库字体。现在需要达成共识的是加入什么字体。

因为本站资源要求自由版权，因此首先排除天珩字库、MiSans L3等。结合上方讨论，综合考虑下来个人建议使用遍黑体。

不清楚社群是否介意字形的地区问题？个人观点是此类字体能消除豆腐块就已经不错了，字形什么的就不要奢求了。--碟之舞📀💿 2025年11月4日 (二) 02:12 (UTC)[回复]

(－)反对加入太大的字体文件，如果非要加入，建议拆分成多个小文件（至少要删掉中文环境下必然能正常显示的字形），最好还是要配合豆腐字检测技术--百無一用是書生 (☎) 2025年11月4日 (二) 02:42 (UTC)[回复]
ULS提供的字体文件有设置1年的缓存，我在下方也提到过，再配合前端小工具视情况请求，在这种情况下是否可以接受？
再次申明，个人主要担心的是在默认启用的情况下，Toolforge的性能和稳定性问题。解决方案之一是前端小工具配合ULS的字体资源，但如果相关后端代码可以作为扩展直接并入MediaWiki，这也是一种解决方案。--碟之舞📀💿 2025年11月4日 (二) 05:49 (UTC)[回复]
@Diskdance：移到上面了。ULS托管后，还是要结合前端小工具根据生僻字字符请求。我比较担心unicode-range是不是真正好用。或者PHP大佬把我的动态分包逻辑加入在ULS扩展。--PexEric 2025年11月4日 (二) 02:43 (UTC)[回复]
unicode-range我印象中得需要字体文件支持才行？--百無一用是書生 (☎) 2025年11月4日 (二) 02:51 (UTC)[回复]
按照MDN文档和spec，这个CSS属性的效果是让浏览器在检测到范围内code point时才加载字体，并只对那些code point使用对应字体。看起来和字体无关。--Srapoj（留言） 2025年11月4日 (二) 20:35 (UTC)[回复]
你这么一说我想起来了，应该是别的webfont特性与字体支持有关，unicode-range并不能把字体文件变小--百無一用是書生 (☎) 2025年11月5日 (三) 02:29 (UTC)[回复]
cn-font-split的做法是拆包，把一個字體文件拆成很多個小文件，每個文件對應一個unicode-range。這樣就能只加載需要用到的部分，節省流量。--SuperGrey (留言) 2025年11月5日 (三) 02:53 (UTC)[回复]

封禁显示

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

阿南之人（讨论 | 貢獻）应该是被部分封禁，但是打开“用删除线划去被封禁的用户”时，显示与被限期封禁用户相同。这应当需要调整？--__BITTEN and DEAD 2025年10月23日 (四) 15:35 (UTC)[回复]

@Hamish、Shizhao、Xiplus、Jimmy Xu：复知界面管理员。--__(´▽`ʃ♡ƪ) 2025年10月29日 (三) 06:09 (UTC)[回复]
被禁止编辑，似乎正常？--百無一用是書生 (☎) 2025年10月29日 (三) 07:17 (UTC)[回复]
应该是没有考虑到这种情况，因为仅禁用电邮的封禁不常见。小工具目前只通过API query blocks返回的restrictions字段（例如禁止编辑某几个页面）来判断部分封禁。处理这里禁用全站电邮的情况需要解析flags字段。--Srapoj（留言） 2025年10月29日 (三) 21:22 (UTC)[回复]
不是，这个用户是全站禁止编辑+停用电子邮件+停用自动封禁，所以没问题啊--百無一用是書生 (☎) 2025年10月30日 (四) 03:17 (UTC)[回复]
他没被禁止编辑，日志内容也是“特定非编辑操作”（MediaWiki:Logentry-non-editing-block-block）。--Srapoj（留言） 2025年10月30日 (四) 11:31 (UTC)[回复]
但是看这里的话Special:Block/阿南之人，是禁止了全站编辑--百無一用是書生 (☎) 2025年10月31日 (五) 03:29 (UTC)[回复]
@Shizhao 我还没被禁止编辑 囧rz……Пусть от победы☆к победе ведёт! 2025年10月31日 (五) 04:34 (UTC)[回复]
打开popups显示是“被部分封禁”。--__(´▽`ʃ♡ƪ) 2025年10月31日 (五) 15:25 (UTC)[回复]

自動清理重複重新導向模板標記

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

是否有辦法建立一個追蹤類別?--Kanashimi（留言） 2025年11月6日 (四) 22:53 (UTC)[回复]
本討論章節會維持開放，暫時不按最後意見發表時間存檔，直至問題解決。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

一个明显的显示异常。

截图 提示框的文字消失了。--LBLaiSiNanHai（留言） 2025年10月28日 (二) 06:19 (UTC)[回复]

看起來像是discussiontool的提示，我去確定一下。--Hamish T 2025年10月28日 (二) 06:29 (UTC)[回复]
印象里是首次使用discussiontools才会弹的(option discussiontools-seenautotopicsubpopup）。--Srapoj（留言） 2025年10月28日 (二) 11:50 (UTC)[回复]
是这个，忘记回了，但我始终无法复现这个提示框的标题和内容消失的情况，弹出来的都是正常显示的。--Hamish T 2025年10月28日 (二) 11:53 (UTC)[回复]
麻烦您告诉我如何让他再次弹出 我自己看一下dom--LBLaiSiNanHai（留言） 2025年10月28日 (二) 11:54 (UTC)[回复]
JS: mw.user.options.set('discussiontools-seenautotopicsubpopup', 0)
去Special:Preferences#mw-input-wpdownloaduserdata可以检查这个配置项的状态。--Srapoj（留言） 2025年10月28日 (二) 12:10 (UTC)[回复]
试了下，对话框没弹，mw.user.options.get('discussiontools-seenautotopicsubpopup')确实是0，用你说的wpdownloaduserdata看到的还是1--LBLaiSiNanHai（留言） 2025年10月28日 (二) 12:19 (UTC)[回复]
我现在试一下api.saveOption('discussiontools-seenautotopicsubpopup', '0')--LBLaiSiNanHai（留言） 2025年10月28日 (二) 12:23 (UTC)[回复]
这个是能用的。--Hamish T 2025年10月28日 (二) 12:26 (UTC)[回复]
建议您看一下有没有什么adblocker之类的东西拦截掉了。--Hamish T 2025年10月28日 (二) 12:27 (UTC)[回复]
抱歉是我没仔细读文档。是得用mw.Api()对象的方法。--Srapoj（留言） 2025年10月28日 (二) 12:25 (UTC)[回复]
我试过了，用api保存选项后虽然查到的是0，但是框还是没弹--LBLaiSiNanHai（留言） 2025年10月28日 (二) 12:26 (UTC)[回复]
您得取消订阅。--Hamish T 2025年10月28日 (二) 12:27 (UTC)[回复]
ooo感谢感谢我试试--LBLaiSiNanHai（留言） 2025年10月28日 (二) 12:28 (UTC)[回复]
test--LBLaiSiNanHai（留言） 2025年10月28日 (二) 12:30 (UTC)[回复]
这一次又好了，暂时不知道怎么回事，那么完成吧--LBLaiSiNanHai（留言） 2025年10月28日 (二) 12:31 (UTC)[回复]
 是，我第一次用的时候就是弹的这个--LBLaiSiNanHai（留言） 2025年10月28日 (二) 11:54 (UTC)[回复]
这儿通常没太多人。您如果有意自己查问题，可以去mediawiki.org找文档、在phabricator.wikimedia.org翻bug，以及用mw:Codesearch（或者 https://github.com/wikimedia ）直接搜源码。--Srapoj（留言） 2025年10月28日 (二) 22:31 (UTC)[回复]
通常會來提問的就是不知道去哪裡（ —— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月5日 (三) 16:07 (UTC)[回复]

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

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

第一个估计很难有共识。屏显时代的间隔号，似乎都是偏爱“半角”，本站改了，堪比教科书改汉字读音😂，意义不甚大。这么说我想起来，古早的中文互联网，数字也是偏爱全角——你可以试试看全角数字写的中文日期，好像确实好看点——总之现在是没人这么干了。第二个对部署小工具本身没有意见，但Dabao qian阁下还是要提供更有价值的css方案，不然很像是劣化。--PexEric 2025年10月28日 (二) 15:26 (UTC)[回复]
半形間隔號（音界號？）可能是我們看久習慣了，但跟其他中文標點符號混排依然很難看，還是建議姑且修補一下。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月28日 (二) 16:52 (UTC)[回复]
同意，我怎么看都觉得字体改善工具应该是浏览器层面的事情--百無一用是書生 (☎) 2025年10月29日 (三) 03:01 (UTC)[回复]
屏显时代的间隔号，似乎都是偏爱“半角”：那是因为U+0087不分全半角，而繁体地区又误用U+FF0E，导致字体不支持。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月29日 (三) 08:23 (UTC)[回复]
字体设计师能自定义字形的宽度（advance width），咱能谈「修复」也是因为有字体把U+00B7做成全形的了。为何设计中文字体（其实我觉得兼容西文就是伪命题，西文字体和中文字体基本都是分开的），业界普遍不把U+00B7设计为全形，这根本就不清楚了。本站也没有必要考虑这些。--PexEric 2025年10月29日 (三) 09:03 (UTC)[回复]
無論如何，我們作為介質獨一無二的網路百科全書（先驅），應該還是能自訂標點格式。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月5日 (三) 16:08 (UTC)[回复]

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

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

各位维基人好，

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

后端：WebFont-ZH

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

前端：僻字小工具

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

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

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

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

🗺️ 下一步做什么？

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

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

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

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

其他Q&A：

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

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

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

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

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

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

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

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

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

	document.fonts.add(fontFace);
}

const fontName = 'ZCOOL KuaiLe';

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

document.body.innerHTML = '';
document.body.setAttribute('style', `font-family: '${fontName}'`);
document.body.append(
	Object.assign(document.createElement('p'), {
		innerText: '正在',
	})
);
--安忆Talk 2025年11月3日 (一) 09:09 (UTC)[回复]

侧边栏模板在移动版的显示问题

有用户反馈Template:聖公宗、蓝牙的表格在纵向的移动版下表现不佳。社群目前对于此类模板或表格的布局问题是否有比较好的解决方案？——暁月凛奈 (留言) 2025年11月1日 (六) 04:32 (UTC)[回复]

最佳实践好像是sidebar干脆不在移动版显示吧。--PexEric 2025年11月1日 (六) 06:28 (UTC)[回复]
我認為聖公宗模板能在移動版直接不顯示，不過藍芽的表格是否能讓他換行顯示，不要左邊是文章，右邊是表格，各佔一部份--~2025-30774-56（留言） 2025年11月1日 (六) 08:06 (UTC)[回复]
Module:Sidebar其实指定了class=nomobile，所以会被Extension:MobileFrontend移除。但本地的{{聖公宗}}没在用这个模板。
{{Infobox}}会用上mw:Extension:WikimediaMessages内置的给Minerva主题的media query (ext.wikimediamessages.styles/infobox.less)，窄屏下（断点min-width: 640px）不会float: right。要想解决蓝牙的表格问题可能得找个模板加这类media query。--Srapoj（留言） 2025年11月1日 (六) 17:09 (UTC)[回复]

Template:NYSE 問題回報

本主題或以下段落文字，已移動至Template talk:NYSE。执行者：Srapoj（留言） 2025年11月3日 (一) 13:11 (UTC)。[回复]

maplink幾乎相同的參數卻無法顯示

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

於Phabricator追踪
工單T409119

Special:PermaLink/89795194中3種{{maplink}}寫法幾乎相同，但兩處無法正常顯示。但在英維en:User:Nebulatria/sandbox卻全部可以正常顯示。請問問題可能出在哪裏。--Nebulatria 2025年11月3日 (一) 17:27 (UTC)[回复]

經過進一步測試（User:Nebulatria/沙盒/1），發現|title=马德留-佩拉菲塔-克拉罗尔谷無法正常顯示，但移除連接改用|title=马德留-佩拉菲塔-克拉罗尔谷即正常，但其他長連結如|title=高雄市立高雄高級工業職業學校卻沒有問題。不理解出現此類錯誤的原因，不知有無修復可能。--Nebulatria 2025年11月3日 (一) 17:37 (UTC)[回复]

我用zh-cn来看1、2正常，3不行；换成zh-tw就是1不行，2、3正常。另外很神秘的是用预览没法重现，只影响已保存的版本（含历史版本）。
Module:Mapframe本身和英维版本几乎没差别，那大概率就是和字词转换系统相关了。不知道和Template talk:Maplink列出的旧问题有没有关系。--Srapoj（留言） 2025年11月3日 (一) 18:28 (UTC)[回复]
仿照您的例子按mw:Help:Extension:Kartographer做了一份没用wikidata的，放在我的沙盒：Special:Permalink/89796014。
现象同样是marker消失，但因为我指定了初始经纬度，所以没像您沙盒那样跑到经纬度都是0的海域点。--Srapoj（留言） 2025年11月3日 (一) 19:57 (UTC)[回复]
交到phab:T409119了。--Srapoj（留言） 2025年11月3日 (一) 22:22 (UTC)[回复]

2025年第45期技術新聞

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

近況更新 - 面向編輯者

  • Special:MergeHistory獲更新，大幅提升了合併功能的靈活性，以便管理員使用。該特殊頁面現在能夠從來源頁面歷史的中段提取段落進行合併，而不僅限於從開頭提取；同時，它也能將修訂版本插入目標頁面歷史中的任意位置，而不僅限於插入開頭。 [3]
  • 現在，對於在偏好設定中啟用「自动订阅话题」功能的使用者，無論其透過何種編輯介面來新增或回覆話題，系統皆會自動為其訂閱該話題。先前，僅當使用討論工具（DiscussionTools）的「添加话题」或「回复」按鈕時才會觸發自動訂閱。討論工具最初推出時，既有帳號並未預設啟用自動訂閱話題功能，因此本次變更主要影響較新帳號，以及曾主動更改偏好設定的使用者。 [4]
  • Scribunto模組現在能夠生成SVG圖像。此功能能透過Lua來動態建立圖表、圖形及其他視覺化內容，減少外部製圖後上傳檔案的需求。 [5]
  • 維基媒體網站現在為所有匿名使用者提供啟用深色模式（黑底白字配色方案）的選項。這項改進旨在提供更舒適的閱讀體驗，尤其是在光線昏暗的環境下。 [6]
  • 存有龐大監視清單的使用者長期以來在編輯Special:EditWatchlist頁面時遭遇逾時（timeout）問題。如今透過分頁（paging）機制更新，該頁面將分批載入項目，而非一次性載入全部內容，使所有使用者皆能順暢編輯監視清單。作為資料庫更新的一部分，我們移除了按到期時間排序的功能，因其速度比按標題排序慢100倍以上。我們提交了一件社群願望，探討恢復按到期時間排序功能的替代方案。若該功能對您至關重要，敬請投票支持該願望！ [7]
  • 經常項目 上週有31件由社群提交的工單得到解決。 例如，之前在視覺化編輯器的「尋找與取代」功能中，即使修改尋找欄位的文字，頁面中原先的文字仍持續高亮顯示，此問題現已修正。 [8]

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

  • 自2019年起，維基媒體縮網址服務（網址：https://w.wiki）開放所有維基媒體維基站點使用，可為條目、永久連結、差異頁面等內容建立短網址。該功能可透過側邊欄的「获取短链接」連結存取。目前仍有30個維基站點同時安裝舊版「ShortUrl」擴充功能。舊版擴充功能即將移除，意味著/s/短網址（以帶有class="title-shortlink"的標籤包裹）將不再直接顯示於條目標題下方。但/s/短網址將持續正常運作。 [9]
  • 10月30日（四），MediaWiki介面團隊與SRE服務運營團隊開始將Action API流量重新路由至共同API閘道。各維基站點將依據標準MediaWiki版本更新分組進行更新，整體流量將隨時間逐步提升。此變更應為非中斷更新。若發現任何問題，請至Phabricator的服務運營團隊看板提交工單。
  • MediaWiki部署列車將於2025年最後兩週（12月22日、29日）暫停。向後移植窗口亦將於2025年12月22日（一）至2026年1月2日（四）期間暫停。向後移植窗口係指預定執行錯誤修正與配置變更等作業的時段。2025年尚餘七次列車部署作業。 [10]
  • 經常項目 本週軟體更新細節： MediaWiki

深入了解

  • 維基媒體基金會指出，由於AI系統與搜尋引擎頻繁引用維基百科內容，卻未能將使用者導向該網站，導致2025年真人瀏覽量較2024年下降8%。在觀察到機器人偽裝成真人的現象後，維基媒體更新了流量數據以反映此變化。關於維基百科當前使用者趨勢，請參閱Diff文章。

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

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

虽然这个新的合并历史功能上上周已经部署了，但@Iokseng：应该是您的好消息，可以少倒腾几次。--Srapoj（留言） 2025年11月3日 (一) 20:15 (UTC)[回复]
欸我剛看到正打算要在下面ping他，被搶先了笑死XD —— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月4日 (二) 22:40 (UTC)[回复]

在桌面端測試閱讀清單功能

大家好，

正如我們先前所分享的，讀者體驗團隊將於11 月 10 日當週啟動一項實驗，將「閱讀清單」引入桌面端和行動網頁端體驗。此實驗將允許活躍讀者保存他們想稍後再閱讀的文章。文章將被整理成一個清單，讀者可以在他們的帳戶中存取。

我們為何要進行這項實驗？

讀者體驗團隊致力於確保現有的讀者——那些已經在網站上花費時間的讀者——擁有工具，以便他們能夠盡可能深入且頻繁地閱讀維基百科。我們認為，這種與維基百科的積極聯繫可以讓現有讀者更接近完成他們的首次編輯。

加強這種聯繫的一種方式，是為讀者提供更多塑造閱讀體驗的方式。例如：儲存文章以供稍後閱讀、突出顯示突出的句子，或收集文章片段。這些功能將使人們能夠更靈活地以最適合自己的方式使用維基百科。

為此，我們希望首先探索最簡單的方法——允許讀者將文章儲存到清單中以供日後閱讀。目前，閱讀清單和標籤等策展功能是 Android 和 iOS 應用程式中最常使用且最受歡迎的功能之一，長期以來，用戶一直希望能夠實現包括桌面裝置在內的跨裝置同步。

模型圖:

https://commons.wikimedia.org/wiki/File:Saved_Pages_Wikipedia_Demo_1.gif

這個專案處於哪個階段？

在 A/B 測試完成後，我們將共同討論結果，並決定是否繼續進一步測試以及在行動端和桌面端建構此功能。

時間安排

我們將從11 月 10 日當週開始，與一小部分已登入的讀者（帳戶編輯次數為 0）一起測試原型。該實驗將持續四週。

此實驗包括哪些內容？

在本次實驗中，我們將首先針對已經熟悉維基百科的極少數受眾測試閱讀清單功能。因此，我們選擇了一群已登入的讀者，他們擁有帳戶但尚未成為編輯者（即編輯次數為 0，且尚未使用過編輯相關功能）。對於這一群體，我們希望測試以下功能：

  • 允許讀者將文章儲存到個人清單以供日後閱讀
  • 允許讀者訪問他們的清單並刪除不再相關的文章

如果此實驗成功，團隊將考慮添加其他功能，例如將清單與應用程式同步、建立多個自訂清單，或將文章的不同部分儲存到集合中。

有關實驗時間安排、研究問題及其他詳細資訊，請參閱專案頁面。

歡迎在此分享您的想法和問題！我們在上一則貼文中也提出了一些更具體的問題。--EBlackorby-WMF（留言） 2025年11月3日 (一) 22:29 (UTC)[回复]

統一Template:RSNG的圖示內部連結

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

小弟發現Wikipedia:可靠来源/布告板/评级指引#來源評級的所有來源分級圖示均有內部連結，但在Template:RSNG僅有 加入防濫用過濾器、 应停用、 列入黑名單有內部連結外，其他均沒有。是否有想統一的打算，因為在WP:RSP中若使用{{RSNG}}，僅有三種來源分級有內部連結，其實看起來滿奇怪的。--英國皇家歐拉夫王子（留言） 2025年11月4日 (二) 14:02 (UTC)[回复]

因RSP屬論述，故直接更改完成。--英國皇家歐拉夫王子（留言） 2025年11月6日 (四) 08:30 (UTC)[回复]

怎麼回退一人的所有編輯

我記得以前有一個小工具，會在使用者貢獻下拉選單給出回退編輯按鈕，但現在找不到了，反破壞有點麻煩。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月4日 (二) 22:38 (UTC)[回复]

User:Alexander_Misel/smart_rollback.js，在用户贡献页面右上角显示“智能回退”按钮。--ChasingAir留言 2025年11月5日 (三) 06:00 (UTC)[回复]
我有裝，但以前有一個直接跳框回退的，應該更強一些？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月5日 (三) 16:12 (UTC)[回复]
請試試看這版本m:User:Hoo_man/Scripts/Smart_rollback是否合用。--英國皇家歐拉夫王子（留言） 2025年11月6日 (四) 07:56 (UTC)[回复]

行動版註腳斜體問題

似乎至今沒有修好，社群是否有解方？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月5日 (三) 16:10 (UTC)[回复]

需要修订MediaWiki:Minerva.css，在最开头加入cite {font-style: normal;}，附@Diskdance。--Dabao qian℡ 2025年11月5日 (三) 16:30 (UTC)[回复]
完成，请复查。--碟之舞📀💿 2025年11月6日 (四) 02:21 (UTC)[回复]

改善封禁提示在窄屏下的显示效果

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

本站封禁提示的实现近期由U:Dabao qian完成了翻新（讨论）。然而见到小红书上的截图后，我意识到当前{{Blockedtext}}在手机上的效果很糟糕：边距过宽，使得留给封禁原因和申诉方式的框的宽度过少。我考虑过把<div style="margin: auto; width: 70%;">换成<div style="margin: auto; max-width: 600px; padding: 0 0.25em;">，但它内部两个带背景的框可能必须要用media query设置断点才能做的好看。

目前这版的样式是U:Bluedeck在2017年初设计的（讨论），不便被封的朋友可以去T:Blockedtext/doc预览常见封禁情况的显示效果。因本人美工过差、且没想好怎么改它，遂发到这里征求意见。--Srapoj（留言） 2025年11月5日 (三) 20:05 (UTC)[回复]

{{Blocked proxy}}等封禁理由模板也需要更新，避免在移动设备上使用<table>，<table>元素应尽量替换为<div>。--Dabao qian℡ 2025年11月6日 (四) 06:48 (UTC)[回复]
谢谢报告问题！我觉得margin-auto + max-width-600 + width 90% 或者类似的数值应该能实现不错的效果。至于背景其实要不要都可以，只要最终的设计不可怕就可以。有时间的话我这几天搞搞看。Bluedeck 2025年11月7日 (五) 10:14 (UTC)[回复]

跨语言链接增强工具已更新

本次更新主要解决了移动版一处问题。如果发现对应功能出现问题，请于此处回报，谢谢。--碟之舞📀💿 2025年11月6日 (四) 09:29 (UTC)[回复]

一时脑抽找不到按钮了

存草稿键在哪来着-- YX Z 2025年11月7日 (五) 19:11 (UTC)[回复]

意思是创建新草稿？
按钮--Luoniya（留言） 2025年11月8日 (六) 01:54 (UTC)[回复]
不知道是不是和article wizard改版有关。新版Wikipedia:条目向导点击下方小字“跳过”即可直接展示创建草稿页面。或者使用捷径WP:WIZGO。--PexEric 2025年11月8日 (六) 13:20 (UTC)[回复]

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

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

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

好問題，好問題 :( —— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月9日 (日) 15:35 (UTC)[回复]

求助

我沒看到中文維基百科的「中華民國憲法」條目「編輯」的按鈕

您好！ 有關中文維基百科的「中華民國憲法」條目內容有問題，最主要的問題是完全沒有講到中華民國憲法的根本—真平等，其次是內容過於繁瑣，看不出中華民國憲法的重點是甚麼、在講些甚麼。我想要去編輯修改，卻沒看到「編輯」的按鈕，希望有人能幫我或教我怎麼做。謝謝！--王果雄（留言） 2025年10月12日 (日) 14:34 (UTC)[回复]

请给出来源,有哪些可靠来源说明了宪法的根本是真平等?另外,估计是保护页面,你可以提出编辑请求。把你所要改的部分写一下。--Vertin,do you want to be the timekeeper? 2025年10月12日 (日) 18:18 (UTC)[回复]
中華民國憲法並沒有被保護，應該能按下右上角的「編輯」修改。可能是你的IP位置被封鎖了？--Saimmx（留言） 2025年10月13日 (一) 10:08 (UTC)[回复]
不对呀，要是ip被封禁的话他怎么编辑这里的。--Vertin,do you want to be the timekeeper? 2025年10月13日 (一) 10:11 (UTC)[回复]
我這邊稍微改了下中華民國憲法的序言，把權利等核心價值放到第二段。序言理論上應當要發揮解釋「中華民國憲法的重點是甚麼、在講些甚麼」的作用，但我不確定您想知道什麼，卻無法找到。另，何謂「真平等」？平等不是已經放在文中了嗎？--Saimmx（留言） 2025年10月13日 (一) 10:15 (UTC)[回复]
我估计他的意思是说,宪法的平等不是写在纸面上的,是社会上的平等。但是叫他列可靠来源他又不列。。这里毕竟不是一个搞原创研究的地方--Vertin,do you want to be the timekeeper? 2025年10月13日 (一) 10:38 (UTC)[回复]
非常謝謝各位提供意見！
我的外文能力和電腦知識都極低劣，碰到外文和電腦知識極不容易理解。
甚麼是中華民國憲法？中華民國憲法就是中華民國治國的規矩；要講中華民國憲法，就要講中華民國治國的規矩是怎麼樣、中華民國治國的規矩重點是怎麼樣—這才是中華民國憲法的重點，其他都是枝微末節。維基提供的內容繁瑣儘是在枝微末節上作文章，就難怪國人都不知道中華民國憲法在說些甚麼。所以我才想去編輯，編輯的的檔案我已經寫好了，內容有1萬2千餘字，希望有人能幫助我編輯或上傳，在此僅列出一小部分。
中華民國有一樣最根本也是最重要的東西，那就是中華民國憲法，記載了中華民國治國的規矩。可惜國人沒有人用心去認識它，可謂中華民國憲法已經被國人遺棄；就因為如此，國人沒有人知道中華民國憲法在說些甚麼，同時也給國人自己帶來災難。
中華民國憲法前言提到「中華民國憲法依據孫中山先生創立中華民國之遺教制定」、憲法第1條載「中華民國基於三民主義為民有民治民享之民主共和國」，孫中山先生遺教最重要的部分就是他的真平等治國理念，亦即他的真平等治國理念就是中華民國憲法的根本；不知道孫中山先生的真平等治國理念，就不知道中華民國憲法在說些甚麼。要看懂憲法，就一定要把憲法與孫中山先生治國理念串連在一起看，才能看得懂憲法在說些甚麼。
中華民國憲法就是中華民國治國的規矩，在講些甚麼？要由『中華民國憲法前言提到「中華民國憲法依據孫中山先生創立中華民國之遺教制定」、憲法第1條載「中華民國基於三民主義為民有民治民享之民主共和國」』講起。
壹、中華民國憲法的靈魂及軀幹
中華民國憲法係由國民政府於民國36年（西元1947年）公布施行。
三民主義有2個版本，內容都包含民族主義、民權主義、民生主義，孫中山先生於8年（西元1919年）完成第1版；後經修改，13年（西元1924年）他公開演講第2版。
滿清末期，孫中山先生鼓吹、領導革命；他於14年（西元1925年）過世，13年（西元1924年）他演講三民主義第2版；這是他最後也是最新、最重要、最具體、最完整治國理念的呈現。民權主義第2版提到【革命的始意，本是在打破人為的不平等】，推翻滿清就是為了要打破人為的不平等，建立民國就是為了要實現真平等，真平等就是中華民國治國的根本。
甚麼是不平等？國家由人民組成；古時候，皇帝率領官吏統治人民，一切都是皇帝、官吏說了算，人民位於最底層，只能被任意宰割，沒有反抗的餘地，是為不平等；今日，民國已經建立114年，仍是官吏統治人民，一切都是官吏說了算，人民位於最底層，被官吏任意宰割，沒有反抗的餘地，依舊是不平等；基本上就違反民國、中華民國憲法真平等根本精神。
甚麼是真平等？民權主義第2版提到【管理眾人的事便是政治（管理國家的事就是管理眾人的事）…必要各人在政治上的立足點都是平等…那才是真平等】，亦即「每個人在政治上的立足點不平等—就是不平等；每個人在政治上的立足點都是平等—就是真平等」。孫中山先生的整個真平等治國理念就是「國家由人民組成，中華民國施行的是民權政體，不是代議政體：人民是皇帝、統治者、國家主人，每個人都是皇帝、統治者、國家主人，此即為每個人在政治上的立足點都是平等、每個人在關於國家治理上的地位都是平等，是即為真平等；由每個國人行使皇帝權，也就是政權、統治權、主宰權，大家共同一起統治治理主宰民國，凡事都由人民大家一起作主。政府官員（即官吏）是由人民選用，支付酬勞，來為人民工作的臣僕，要將人民交付的工作做好，協助人民將民國治理好，基本上臣僕要聽國家主人的；參酌古代君臣主僕相處之道，由人民視需要分配給予臣僕權、治權，使臣僕能夠順利適當完成交付的工作；臣僕要適時、即時將工作情形陳報，視情形提出意見、建議，依人民的授權、認可辦理」—這是中華民國憲法的靈魂及軀幹，這也就是憲法第1條「中華民國基於三民主義為民有民治民享之民主共和國」、第2條「中華民國之主權屬於國民全體」的含意，憲法內容細節即係依此真平等根本精神做出規範，基本上是官吏要聽人民的，人民有最高決定權，不是「官吏說了算」。家庭裡雇用僕人，主人與僕人的相處，基本上，亦是依此原則辦理，主人擁有最高決定權，僕人要聽主人的，道理是一樣的。要看懂憲法，就一定要把憲法與孫中山先生治國理念串連在一起看，才能看得懂憲法在說些甚麼。
中華民國憲法少了孫中山先生的治國理念，那就不再是中華民國憲法了！「憲法為國家根本大法，人民權利的保證書」就成了空言。114年（西元2025年，今年）-36年（西元1947年，憲法公布施行時間）=78年，超過了4分之3個世紀，國人沒有人用心研讀憲法、孫中山先生遺教，以致國人完全沒有「全民共同一起統治治理民國，人民是皇帝，政府官員是人民的臣僕」想法，也就不知道中華民國憲法其實一直未施行、臣僕一直集體騎在人民頭上眾口鑠金玩法弄權，這是中華民國國家與人民的不幸。我們的總統會依憲法第48條於就職時宣誓：「余謹以至誠，向全國人民宣誓，余必遵守憲法，盡忠職務，增進人民福利，保衛國家，無負國民付託。如違誓言，願受國家嚴厲之制裁。謹誓」別傻了，總統是臣僕之首，帶領其他臣僕都一直在反民國、反憲法，拒絕「全民共同一起統治治理民國，人民是皇帝，政府官員是人民的臣僕」，這些人一直都在造反篡位奪權、權力分贓利益分贓，他們一直都在反平等；人民是皇帝，這些奸臣惡僕就是要當太上皇，把人民踩在腳底下、欺騙愚弄壓榨人民。
憲法第79條記載「司法院大法官解釋憲法」，解釋憲法就是說明清楚憲法在說些甚麼。我們的大法官臣僕從來沒有提過孫中山先生的任何治國理念，只會儘說些有利於他們的謊言，亦即大法官臣僕壓根兒從來就沒有說明憲法在說些甚麼、也就是大法官臣僕從來就根本沒有在解釋憲法，而是在假解釋之名行詐騙之實、趁機歪曲及變更憲法的意思。憲法所說的「解釋憲法」用意是在說明清楚憲法在說些甚麼，性質上屬不具約束力的意思表示；憲法所說的法律、命令，則是講「臣僕想要約束別人遵守其想法之具約束力的意思表示」；我們的大法官臣僕已經把憲法所規定的大法官解釋全部改用大法官命令取代，要大家都聽他們的，基本上就與憲法第79條的本意違背；當然，大法官全部違憲命令依憲法第172條「命令與憲法或法律牴觸者無效。」是當然無效的。我們的大法官臣僕之全部解釋、教育及研究單位講的法學知識以及法學專家講的法學觀點，你有看到過、聽到過有人提到孫中山先生的治國理念「全民共同一起統治治理民國，人民是皇帝，政府官員是人民的臣僕」嗎？這可是中華民國不可動搖的治國根本，我是從來都沒有看到過、聽到過。在這些劣質臣僕操弄下，憲法已經完全變質，早就已經去除了孫中山先生的治國理念，這些人一直在給國人洗腦「人民要服從政府官員」，說的其實只是「這些人犧牲國人利益、獲取其個人私利」的謊言，講的完全違背中華民國憲法的意思。我們的政府官員們包含總統、大法官等等在內，對於憲法前言及憲法內容包含第1、2條等等，不想遵守的就一律視之為空話、贅字，從來都是惡意避而不談，政府早就被叛亂團體詐欺集團盤據佔領把持壟斷。
憲法並未列明孫中山先生遺教，國人須自行查閱，圖書館、舊書攤或國父紀念館的中山學術資料庫網頁可以參考。因為我有人人真平等的基本觀念，稍微用心看過孫中山先生遺教，才能夠理解他的治國理念，以致至今只有我一個人清楚知道中華民國憲法在說些甚麼。--王果雄（留言） 2025年10月21日 (二) 22:17 (UTC)[回复]
請自行屏蔽移除你的Mail位址，開設議題討論就討論，僅限於此討論，請避免將個人聯絡資訊暴露於此站，知會@王果雄君。--薏仁將🍀 2025年10月22日 (三) 01:07 (UTC)[回复]
笑死根本就发不到他邮件上。 怀疑他打错字了--Vertin,do you want to be the timekeeper? 2025年10月22日 (三) 02:05 (UTC)[回复]
好了，已经拿到了，我已经传了
我并不太了解中华民国宪法,所以请由大家判断
User:王果雄/中华民国宪法--Vertin,do you want to be the timekeeper? 2025年10月23日 (四) 02:38 (UTC)[回复]
补充一下 一些链接触发过滤器了 估计是因为不可靠来源--Vertin,do you want to be the timekeeper? 2025年10月23日 (四) 02:45 (UTC)[回复]
所以我自己先删掉了--Vertin,do you want to be the timekeeper? 2025年10月23日 (四) 02:45 (UTC)[回复]
依照目前达成的共识已经对该页面提删。--Vertin,do you want to be the timekeeper? 2025年10月25日 (六) 16:35 (UTC)[回复]
「依照目前達成的共識已經對該頁面提刪。」不瞭解是甚麼意思?--王果雄（留言） 2025年10月27日 (一) 09:31 (UTC)[回复]
说白了就是绝大部分人都觉得你这篇文章不适合出现在wiki上，所以提议删除。--Vertin,do you want to be the timekeeper? 2025年10月27日 (一) 09:34 (UTC)[回复]
神秘长篇大论--~2025-29463-67（留言） 2025年10月23日 (四) 10:58 (UTC)[回复]
明显WP:OR。--__BITTEN and DEAD 2025年10月24日 (五) 00:13 (UTC)[回复]
貳、「中華民國」的意義
中華民國憲法講的是中華民國治國的規矩，要知道中華民國憲法在說些甚麼，宜由「中華民國」的意義開始著手。
民國5年，孫中山先生演講「中華民國的意義」，提到「國民者，民國之天子也」，他主張民國的時代，人民就是皇帝、統治者、國家主人，人人地位平等，民國由人民大家一起當家作主。
（壹）「中華」就是指我們每個人都是中華民族這個大族群中的一份子，大家不要固持本位主義，彼此不要再去硬分我是哪裡人你是哪裡人，不要再去硬分漢、滿、蒙、回、藏、苗…族別、地域…，製造對立磨擦，大家要團結。
（貳）「民國」的意義
民前6年（西元1906年）孫中山先生在革命階段中國同盟會成立時期，訂出入會誓詞：「驅除韃虜，恢復中華，建立民國，平均地權」；當時正值滿清帝國時期，此民前6年起誓要建立的民國，應該是怎麼樣的民國？
國家由人民組成；帝國者帝王之國，帝王就是統治者、主宰者、國家主人，擁有統治權、主權（主宰國家之權），統治、主宰全國；官國者官員之國，世上有不少國家採用代議政體，人民放棄權力不直接管理國事，交由政府管理，定位政府官員就是統治者、主宰者、國家主人，擁有統治權、主權，統治、主宰全國；民國的「民」就是指人民，民國者人民之國，如果人民大家能夠一起合力推翻滿清舊朝代，人民全體就能取代滿清皇帝成為民國新朝代的皇帝、統治者、主宰者、國家主人，擁有統治權、主權，由人民大家共同一起統治治理主宰全國，這是「建立民國」的本意。
6年後人民合力推翻滿清，成功建立起民國，民國就是人民生出來的，人民就是民國的父母、主人、皇帝、統治者；「民國」2字有正名、正本清源的含意，也是孫中山先生後續所生治國理念的根源。
早在民前17年（西元1895年），孫中山先生在革命初始興中會成立時期，亦曾訂出入會誓詞：「驅除韃虜，恢復中華，創立合眾政府」，合眾政府即指由人民大家一起推舉出政府統治治理國家，亦即革命初始他是主張採用代議政體的官國。經過11年的考察深思，人民如能推翻滿清舊朝代創建起人民為國家主人的新朝代，如此，人民既為民國新朝代的開創者、統治者，卻仍要如同唐宋元明清或外國代議政體官國，繼續承受人民選用之政府官員的頤指氣使，政府官員卻可不受約束不負責任唯我獨尊官官相護作威作福結黨營私膽大妄為？民國當然不該是這樣的，乃確認代議政體的官國，對全民而言，不是適當的選擇；參考古代，定位人民是皇帝，政府官員是人民的臣僕、是受薪從旁協助人民治理國家的幫手，要受人民的約束管理；故不再主張創立合眾政府、代議政體，改為主張建立民國，由人民大家共同一起統治治理主宰民國。--王果雄（留言） 2025年10月24日 (五) 02:34 (UTC)[回复]
请勿长篇大论，这样子容易阻碍其他不看这个议题的人的阅读体验，反正我也传到wiki，他们自己会看的。你大可以直接说第几段第几段。--Vertin,do you want to be the timekeeper? 2025年10月24日 (五) 02:38 (UTC)[回复]
您好！Vertin,您問到do you want to be the timekeeper?麻煩您說一下工作情況如何，謝謝您！--王果雄（留言） 2025年10月26日 (日) 23:01 (UTC)[回复]
那句話是他的簽名，直譯為：「維爾汀，你想當時空管理者嗎？」。我想應該是遊戲梗，與他的維基百科工作無關。
再來，我不認為你的內容會被接受：因為你的內容與立論幾無來源直接支持，而維基百科很難允許無法驗證（內容都要有來源依據）或個人研究（來源說什麼就要寫什麼，不應摻有編輯的觀點）的內容。--Saimmx（留言） 2025年10月26日 (日) 23:35 (UTC)[回复]
其实是有的，它的来源触发了过滤器所以我就删了。--Vertin,do you want to be the timekeeper? 2025年10月27日 (一) 02:34 (UTC)[回复]
哥们，那是我的签名…………………………
补充一下，需要可靠来源。--Vertin,do you want to be the timekeeper? 2025年10月27日 (一) 02:33 (UTC)[回复]
维基百科不是博客，阁下可自行前往博客或者微博网站发表意见。--GrandCeres（留言） 2025年10月24日 (五) 07:01 (UTC)[回复]
{{citation needed}}--Saimmx（留言） 2025年10月25日 (六) 11:49 (UTC)[回复]
我想，我知道你們的問題出在哪兒了。
中華民國憲法前言提到「中華民國憲法依據孫中山先生創立中華民國之遺教制定」、憲法第1條載「中華民國基於三民主義為民有民治民享之民主共和國」，你們以為這2句是空話、贅字，一般人讀憲法也都把這2句當做是空話、贅字忽略過去，沒有人去深入瞭解。一般文章很少會有空話、贅字，憲法提到這2句，這麼多個字更不可能是空話、贅字，再者制憲國代將其排在前言及第1條更是具有非常重要的份量；少了這2句，憲法的意義就完全不同，前後也會銜接不起來，會有衝突。再說這2句如果是空話、贅字，制憲國代根本就不需要多此一舉寫出這2句。
因此我在文內引述這2句的相關內容，你們都以為只是我自己的主觀想法無關緊要，犯了把憲法的重點當做空話、贅字的錯誤。--王果雄（留言） 2025年10月27日 (一) 16:37 (UTC)[回复]
完全不是，很明顯這裡沒人在解讀閣下的對中華民國憲法的見解，請閣下停止發表與維基百科無關的言論與個人觀點。--Sakurase留言 2025年10月27日 (一) 16:42 (UTC)[回复]
這與我們如何看待憲法無關，而是和中文維基百科的網站性質有關。中文維基百科的核心內容政策是：可驗證性、非原創研究、中立觀點這三個。可驗證性是指：所有内容和引用，都可能被质疑，须带有可靠、公开的来源，以供检验；非原創研究是指：所有内容都应由已发表的可靠来源支持，不能包含有对已发表材料的新式分析和总结；中立的觀點則是說：所有内容要以中立的觀點，撰寫出平等、成比例且不带偏见地表达重要的观点。
中文維基百科強調重複專家說過的話、並把編輯的主觀想法壓到最小。出於非原創研究與中立的觀點政策，我們不會自行解讀中華民國憲法前言、或中華民國憲法第一條的意義：「少了這2句，憲法的意義就完全不同，前後也會銜接不起來，會有衝突」應該是由張君勱、翁岳生、或葉俊榮口中說出才有意義。
這大概就是為什麼你會發現，我們對你的主觀想法，「以為」到接近無關緊要的原因吧：你應該找法學專家支持你的看法，這樣才有意義。但如果你本身是像教授憲法的法律系教授那種專家，那我們也會收錄你對中華民國憲法的看法。
關於中華民國憲法前言的意義，我們對李震山與張淑中的想法比較有興趣；憲法第一條，釋字499的說法比個別編輯的說法有價值。就這樣。--Saimmx（留言） 2025年10月28日 (二) 01:21 (UTC)[回复]
維基「中華民國憲法」條目名稱，既然是「中華民國憲法」，內容講的就應該是「中華民國憲法」實質的東西，而不是某些人對「中華民國憲法」的看法、意見。
世上有一條很重要的規則，就是「誠信原則」。甚麼是「誠信原則」？中華民國憲法前言提到「中華民國憲法依據孫中山先生創立中華民國之遺教制定」，沒有再提到其他參考、引據的東西，這是制憲國代們共識定案的結論，看不懂憲法，就要去找找看孫中山先生遺教怎麼說就對了。你要去找個別制憲國代、其他專家學者表達意見或參考制憲實錄，那都只是個別制憲國代、其他專家學者個人的意見，不是制憲國代們共識定案的中華民國憲法結論；制憲實錄記載的只是制憲過程，亦不是制憲國代們共識定案的中華民國憲法的結論，只有「中華民國憲法依據孫中山先生創立中華民國之遺教制定」才是制憲國代們共識定案的結論。「中文維基百科的核心內容政策是：可驗證性、非原創研究、中立觀點這三個。」其實只有孫中山先生遺教符合條件，個別制憲國代、其他專家學者個人或集體的意見其實並不符合條件，想要符合條件，就要找齊制憲國代們肯為他們背書的證據。
憲法的重點不是孫中山先生遺教、三民主義這幾個字，而是孫中山先生遺教的內容、三民主義的內容才是憲法的重點，我一直在講的孫中山先生遺教、三民主義重點內容，就是憲法的重點，你們如果認為我說的不對當然可以提出質疑，我會再說明清楚。
「應該是由張君勱、翁岳生、或葉俊榮口中說出才有意義…像教授憲法的法律系教授那種專家，那我們也會收錄你對中華民國憲法的看法。…我們對李震山與張淑中的想法比較有興趣；憲法第一條，釋字499的說法比個別編輯的說法有價值。」迷信這些被認為是專家的說法，不知道這些專家的說法已經背離中華民國憲法、孫中山先生遺教、三民主義本意。其實只有一個人說的才是對的、才具有權威性，別的人說的都不準、都不具有權威性，誰？那就是孫中山先生；孫中山先生已逝，就要去查明孫中山先生遺教是怎麼說的，而不是人云亦云聽信這些被標榜為專家的人胡扯。--王果雄（留言） 2025年10月28日 (二) 06:26 (UTC)[回复]
技术上来看：中華民國憲法现时没有设置页面保护状态，理论上任何用户都能编辑，包括“User:王果雄”；业务上，其实前有述中文維基百科的核心內容政策是：可驗證性、非原創研究、中立觀點這三個。可驗證性是指：所有内容和引用，都可能被质疑，须带有可靠、公开的来源，以供检验；非原創研究是指：所有内容都应由已发表的可靠来源支持，不能包含有对已发表材料的新式分析和总结；中立的觀點則是說：所有内容要以中立的觀點，撰寫出平等、成比例且不带偏见地表达重要的观点。，可以最简单理解为“维基百科上的条目内容应该是且只是反映引述参考来源的表述”。如果你认为条目“完全没有讲到中华民国宪法的根本—真平等，其次是内容过于繁琐，看不出中华民国宪法的重点是什么、在讲些什么”，至少这样做：尝试从已有符合WP:可靠来源的来源（可能包括一些公开的传统媒体报道、学术文献、或者符合要求的介绍文章）作为参考，以此为参考注脚去引述这些观点（例如：“中华民国宪法的根本—真平等”）；如果是“内容过于繁琐，看不出中华民国宪法的重点是什么、在讲些什么”，可以尝试基于已有或者能找到符合WP:可靠来源的来源和已有的条目描述上，并基于前述的可驗證性、非原創研究、中立觀點三个核心标准，重新组织文段，来尝试满足你认为的“中华民国宪法的重点”。但如果涉及只是编辑你自认为的不符合，没有来源引述支撑的话，可能会与三个核心标准不符，其他编辑可能不会认可这样的编辑，甚至容易演变成WP:编辑战或者WP:破坏行为。如果你认为现有条目没有反映你认为缺失的观点或者行文不佳，并且存在合适的来源支撑你的文段思路，可以尝试去修改条目，至少技术上并没有限制编辑这个条目（编辑的帮助信息可看这个Help:编辑页面）。——Sakamotosan路过围观 | 避免做作，免敬 2025年10月28日 (二) 07:43 (UTC)[回复]
不过从User:王果雄/中华民国宪法的论述来看，更像是“你对中华民国宪法实质的评论”，或者引述其他来源（可能还不符合WP:可靠来源）的评论论文，而且不是给读者介绍主题的說明文。条目应该是作为介绍某个主题为核心，例如中华民国宪法这类法律文献类型的条目，包括了制定的历史背景信息（“制憲歷史”）、内容架构（“憲法内容”）、后续应用（“行憲與修憲沿革”、“发展”）、来自其他方面的评价（“評價”）等方面。这个论述更像是把三民主義的来源、背景说了遍，和打着这些名义去抱怨现实世界罢了。 耸肩——Sakamotosan路过围观 | 避免做作，免敬 2025年10月28日 (二) 08:02 (UTC)[回复]
壹、有關Sakamotosan10月28日
（壹）提到「業務上，其實前有述中文維基百科的核心內容政策是：可驗證性、非原創研究、中立觀點這三個。可驗證性是指：所有內容和引用，都可能被質疑，須帶有可靠、公開的來源，以供檢驗；非原創研究是指：所有內容都應由已發表的可靠來源支持，不能包含有對已發表材料的新式分析和總結；中立的觀點則是說：所有內容要以中立的觀點，撰寫出平等、成比例且不帶偏見地表達重要的觀點。」
回應：我的文章，Vertin,do you want to be the timekeeper?表示 10月23日 已經拿到了，且已經傳了，10月24日交待我「請勿長篇大論，這樣子容易阻礙其他不看這個議題的人的閱讀體驗，反正我也傳到wiki，他們自己會看的。你大可以直接說第幾段第幾段。」如需參考我的文章，請逕洽Vertin,do you want to be the timekeeper?。
我的文章，在講中華民國憲法，完全引用的就是中華民國憲法、孫中山先生遺教、三民主義（以下簡稱「這三者」）內容，也就是來源就是「這三者」，並沒有其他來源，這些是制憲國代們共識定案的中華民國憲法結論，本人只是略微加以說明。我的說明是因為考慮國人看不懂「這三者」內容，看得懂「這三者」內容，可以略過我的說明不看；如果對我的說明認為不對或有疑義，當然可以提出質疑，我會再說明清楚（質疑請具體，不過至今亦未看到有具體質疑）。基本上，我的說明並不至於逾越「這三者」內容，只是要把「這三者」融合匯集起來看，才會知道中華民國憲法在講些甚麼，才會知道我在說些甚麼；國人不知道要把「這三者」融合匯集起來看，才會不知道中華民國憲法在講些甚麼。
我想起來，沒有很久前（大約1、2個月前吧），有電視台播出記者訪問一位年輕人時，他表示他不知道中華民國憲法第1條的意思。光看中華民國憲法，是不可能知道憲法第1條意思的；一定要把「這三者」融合匯集起來看，才會知道憲法第1條的意思，在我的文章裡已依據「這三者」給出憲法第1條的答案，及整個憲法的答案。絕大多數人不知道「中華民國憲法依據孫中山先生創立中華民國之遺教制定」、「中華民國基於三民主義為民有民治民享之民主共和國」含意，看到孫中山先生遺教內容龐雜，多半會心想這要怎麼去找需要的答案？甚至連三民主義內容也不去暸解，因此極易放棄去找孫中山先生遺教、三民主義裡的答案，只會依個人主觀的想法去想像憲法第1條的意思，乃至整個憲法的意思，難怪會誤入歧途。看到孫中山先生遺教內容龐雜，絕多數人不會花心思去找答案，所以在世界上你找不到憲法第1條的正確說明。我也連帶看到維基的中華民國憲法第1條條目裡只載錄了1條孫中山先生遺教，沒有提到三民主義內容，以致對中華民國憲法第1條條目名稱而言，仍是說明得殘缺不全不夠準確未講明清楚。
我的文章所有內容，都是引用「這三者」，亦列明出處，「這三者」是我引述參考的來源，也就是維基條目裡的〝參見〞，不算可靠、公開的來源可供檢驗？不符合可驗證性？除了中華民國憲法在全國法規資料庫網站找得到外，「孫中山先生遺教、三民主義」在國父紀念館的中山學術資料庫網頁仍可以找得到，應該算已發表的可靠來源，我的文章既是引用「這三者」，亦列明出處，並無對已發表材料（「這三者」）的新式分析和總結，不能算由已發表的可靠來源（「這三者」）支持？不符合非原創研究？我的文章所有內容，完全是引用「這三者」，亦列明出處，只有說明「這三者」並無對「這三者」的評論，尚談不上有何偏頗情形，應屬符合中立觀點；如果你們覺得不符合中立觀點，請提出具體明確質疑，俾利本人說明澄清。我想我的文章內容應屬「是且只是反映引述參考來源（「這三者」）的表述」。其實我想引用「這三者」，應該無需再就可驗證性、非原創研究、中立觀點說明吧。
（貳）提到「不過從User:王果雄/中華民國憲法的論述來看，更像是「你對中華民國憲法實質的評論」，或者引述其他來源（可能還不符合WP:可靠來源）的評論論文，而且不是給讀者介紹主題的說明文」「這個論述更像是把三民主義的來源、背景說了遍，和打著這些名義去抱怨現實世界罷了。」
回應：我想如果你們能將「這三者」融匯貫通瞭解，或許就能知道我在說些甚麼不致有此誤會吧。
（參）提到「嘗試從已有符合WP:可靠來源的來源（可能包括一些公開的傳統媒體報道、學術文獻、或者符合要求的介紹文章）作為參考」
回應：「公開的傳統媒體報道、學術文獻、或者符合要求的介紹文章」其實很多都是與「這三者」牴觸，比對應可發現。
貳、有關Saimmx 10月28日提到的張君勱、翁岳生、葉俊榮、李震山、張淑中、釋字499
回應：這些人不會去找孫中山先生遺教內容，甚至也不去查三民主義內容，連憲法第1條的含意「國家由人民組成，中華民國施行的是民權政體、不是代議政體：人民是皇帝、統治者、國家主人，每個人都是皇帝、統治者、國家主人，此即為每個人在政治上的立足點都是平等，亦即是為真平等；由每個國人行使皇帝權，也就是政權、統治權、主宰權，大家共同一起統治治理民國，凡事都由人民大家一起作主。政府官員（即官吏）是由人民選用，支付酬勞，來為人民工作的臣僕，協助人民將民國治理好，基本上臣僕要聽國家主人的；參酌古代君臣主僕相處之道，由人民視需要分配給予臣僕權、治權，使臣僕能夠順利適當完成交付的工作；臣僕要適時、即時將工作情形陳報，視情形提出意見、建議，依人民的授權、認可辦理」都不知道，看這些人的說詞，會發現與憲法第1條就已牴觸，這些人說的是對是錯，直接拿「這三者」比對，就可立見真章；不應人云亦云、聽信眾口鑠金。民權主義表示「民權政體、民主政治、全民政治、民主都是指「凡事都是由人民共同作主，每個人都是皇帝，人人地位平等。」國家凡事都是由人民共同一起作主，政府官員是人民的臣僕，國家凡事政府均無權作主。目前政府、政府官員公佈的決定，未經人民共同一起複決、作主，都是與憲法牴觸無效的，釋字499就是明白的例子；問題就出在這些人無視並違背「中華民國憲法依據孫中山先生創立中華民國之遺教制定」、「中華民國基於三民主義為民有民治民享之民主共和國」含意。這些人的說詞並不可信，如果認為符合WP:可靠來源的話，我認為WP:可靠來源需要重新定義。--王果雄（留言） 2025年11月6日 (四) 15:44 (UTC)[回复]
首先文章我已经放了 他们应该是看了 毕竟是站内链接
引用的话建议用tq模板
孙中山遗教这方面你可以给一个比较权威的链接吗？--Vertin,do you want to be the timekeeper? 2025年11月6日 (四) 15:55 (UTC)[回复]
还有那个是我的签名 我的名字都没那么长 叫我林兴俊就好
我现在在用手机，本着不要伤害新手的原则，在这里请求帮我套一下链接(--Vertin,do you want to be the timekeeper? 2025年11月6日 (四) 15:56 (UTC)[回复]
有關林興俊君11月6日提到
1.「引用的話建議用tq模板」
回應：很抱歉，我在10月21日留言說「我的外文能力和電腦知識都極低劣，碰到外文和電腦知識極不容易理解。」我也查了「tq模板」網頁，講些甚麼還是沒有看懂，只能再次說抱歉，或者您能教我怎麼做。
2.「孫中山遺教這方面你可以給一個比較權威的連結嗎？」
回應：我在10月21日留言說「憲法並未列明孫中山先生遺教，國人須自行查閱，圖書館、舊書攤或國父紀念館的中山學術資料庫網頁可以參考。」我的文章引述參考的孫中山先生遺教數位檔，很久以前都是由中山學術資料庫下國父全集網頁下載相關檔案；今日進去卻不順遂，國父全集下面的網頁我進不去打不開，或許你們恐要洽國父紀念館處理。我可提供以前下載的檔案供參，不過我不知道如何上傳。
孫中山先生於14年（西元1925年）過世，至今已過百年，孫中山先生遺教即亦已有逾百年歷史，當時尚無電腦，只有書面文字記載，我想現今恐怕沒有別的人去研究孫中山先生遺教了。書面的國父全集原是由國民黨出版，國家圖書館及國立臺灣圖書館應該也有吧；目前圖書館也講數位化，有無數位檔可洽詢看看。國民黨有無數位檔及有無書面存貨可洽詢國民黨看看。很久以前在舊書攤我有買了書面的第1、2冊，我的版本是70年8月1日再版共有6冊，我提到的孫中山先生遺教內容，都在第1、2冊裡面，如有需要我可以掃描（A4大小）傳給你們。
3.「我現在在用手機…在這裡請求幫我套一下連結」
回應：看不懂你的意思，不曉得如何處理。--王果雄（留言） 2025年11月9日 (日) 03:57 (UTC)[回复]
使用{{tq|引用文字}}可以得到引用文字来达到引用效果--亚蓝青空 2025年11月9日 (日) 04:02 (UTC)[回复]
2.我在中国大陆,所以去不了。这个，要请其他编者帮忙了。如果是电子书籍的话，您可以直接邮箱传给我，我看看能不能搜到他的标识码。
3.这个是我跟别人交流，因为手机不方便编辑源代码，所以基本上套不了模板。--Vertin,do you want to be the timekeeper? 2025年11月9日 (日) 04:04 (UTC)[回复]

用户权限显示有关问题

请问为何手机端显示用户权限时，现在在diff页的用户权限不会换行了，导致显示不全？如一名用户身兼数职，后面的权限显示不出来。--GrandCeres（留言） 2025年10月24日 (五) 07:03 (UTC)[回复]

本来以为您指的是WP:MarkRights小工具，试了一下发现您指的是Minerva自带的用户组显示功能。它的样式(.mw-diff-userroles)确实近期被改过，溢出时会变成省略号，见commit eaea264。您要不去phab:T357352说？--Srapoj（留言） 2025年11月3日 (一) 00:50 (UTC)[回复]

无法创建SPI案件

本页已被禁止创建和编辑，只有管理员可以取消此创建限制。因为标题“Wikipedia:傀儡調查/案件/Hkfj123456789”和本地或全域黑名单 (?!(?:User|User talk|Template|Template talk|Draft):).*(?<!\/patch\/)([\d０-９①-⒛⓫-⓿🄀-🄊㉈-㉏㉑-㉟㊱-㊿㊀-㊉㈠-㈩〇一二三四五六七八九零壹贰叁肆伍陆柒捌玖]\s*){7,}.* <autoconfirmed>配合。这通常是为了防止破坏性的编辑。 如果您看到此讯息并想作出修改，创建或移动现在的标题页面，请遵照以下指示：

其他问题可在互助客栈提出，请明确说明您要编辑或创建的页面名称，尤其是标题名称容易被误解（例如是一个不正确名称），并简述您要进行的操作。 您也可以在管理员的讨论页留言或以电子邮件联系他们。 谢谢您。

请各位管理员临时解除此限制，感谢。

--莱斯男孩儿（查·论·编） 2025年10月31日 (五) 01:36 (UTC)[回复]

@LBLaiSiNanHai：权限不够的问题，等确认用户下来，或者等自动确认吧……--__(´▽`ʃ♡ƪ) 2025年10月31日 (五) 13:26 (UTC)[回复]

CCI調查需要協助

我在處理CCI時發現這筆編輯的來源有paywall,而web archive 等手段也過不到這來源的paywall, 因此請求能看到全篇文章的編者協助檢查或email全文給我，謝謝。---VAMPIRE!VAMPIRE! All Hands Brace For Shock!Birds Away. Missile intercepted（留言） 2025年10月31日 (五) 15:26 (UTC)[回复]

已发邮箱。--__(´▽`ʃ♡ƪ) 2025年10月31日 (五) 15:39 (UTC)[回复]

G5處理標準是否一致

根據User_talk:Manchiu#c-1F616EMO-20250522135700-自由雨日-20250522130900的說明，User:Cheng Edmund/在地下城尋求邂逅是否搞錯了什麼登場人物列表已被G5，那麼User:Cwek/工作室/在地下城寻求邂逅是否搞错了什么登场人物列表是否也應該同樣被G5？否則可能會造成標準不一致，敬請指教。--~2025-30750-31（留言） 2025年11月1日 (六) 08:50 (UTC)[回复]

应该不用G5，因为不是同个页面，如果内容一致，应该要A5吧，G5大概率是不适用的，各位有经验的前辈也可以详细说一下，这只是我的猜测--莱斯男孩儿（查·论·编） 2025年11月1日 (六) 10:58 (UTC)[回复]
肯定不适用A5。--__(´▽`ʃ♡ƪ) 2025年11月1日 (六) 12:53 (UTC)[回复]
已删版本查询再比对吧……WP:G5：如果页面重建后的版本：与被删除的版本明显不同；或其现时的内容已不再适用此前页面存废讨论、文件存废讨论或存废复核请求中提出的删除理由，而提请者认为需要删除，请重新提交到页面存废讨论、文件存废讨论或存废复核请求。如果提请者对此不肯定，请先联系上次执行删除的管理人员。--__(´▽`ʃ♡ƪ) 2025年11月1日 (六) 12:54 (UTC)[回复]
@Shizhao、Manchiu：代為通知執行頁面存廢討論和執行快速刪除的管理人員。--~2025-30820-69（留言） 2025年11月1日 (六) 13:32 (UTC)[回复]
請有自動確認權限的使用者幫忙掛G5，讓管理員判斷，麻煩@Kurgenera。--~2025-30905-38（留言） 2025年11月2日 (日) 02:36 (UTC)[回复]
完成，挂上了--莱斯男孩儿（查·论·编） 2025年11月2日 (日) 02:38 (UTC)[回复]
感激不盡。--~2025-30905-38（留言） 2025年11月2日 (日) 02:41 (UTC)[回复]
内容相同：Special:AbuseLog/5403739。--伞木 霙留言 2025年11月2日 (日) 03:27 (UTC)[回复]
那么我再挂个A5--莱斯男孩儿（查·论·编） 2025年11月2日 (日) 03:28 (UTC)[回复]
WP:A5：“页面”在此条指位于用户命名空间与草稿命名空间之外的所有页面。--__(´▽`ʃ♡ƪ) 2025年11月2日 (日) 04:28 (UTC)[回复]
不适用G5，不符合“删除后被重建”。--12З4567（留言） 2025年11月2日 (日) 07:47 (UTC)[回复]
那User:Cheng Edmund/在地下城尋求邂逅是否搞錯了什麼登場人物列表怎麼說？G5雙標嗎？--~2025-30871-38（留言） 2025年11月2日 (日) 07:51 (UTC)[回复]
两者均不符合速删准则。原删除理据仅适用于条目而非用户页。--12З4567（留言） 2025年11月2日 (日) 08:48 (UTC)[回复]
或許可以存放到藍桌圖書館--象象🐘(留言|貢獻) 2025年11月2日 (日) 07:59 (UTC)[回复]
我已存放，不过若G5适用用户命名空间，那么蓝桌图书馆的所有内容岂不是都要删？--Luoniya（留言） 2025年11月2日 (日) 08:06 (UTC)[回复]
@Luoniya我後來發現之前的討論中的重點在於著作權問題，因此建議聲明其來自主命名空間--象象🐘(留言|貢獻) 2025年11月2日 (日) 08:33 (UTC)[回复]
我剛剛在寫回應意見的時候，才發現如果無論如何都完全按G5標準審查，則藍桌圖書館這個服務應該完全被快速刪除。--小過兒（留言） 2025年11月2日 (日) 08:07 (UTC)[回复]
或許是在於cc-by-sa中的by，因為藍桌圖書館有註明是來自主命名空間--象象🐘(留言|貢獻) 2025年11月2日 (日) 08:26 (UTC)[回复]
另外見G5標準中：「如果頁面重建後的版本：
與被刪除的版本明顯不同；或
其現時的內容已不再適用此前頁面存廢討論、檔案存廢討論或存廢覆核請求中提出的刪除理由，
而提請者認為需要刪除，請重新提交到頁面存廢討論、檔案存廢討論或存廢覆核請求。如果提請者對此不肯定，請先聯絡上次執行刪除的管理人員。」，收錄標準僅適用於主命名空間。--象象🐘(留言|貢獻) 2025年11月2日 (日) 08:04 (UTC)[回复]
不過如果有著作權問題還是需要被刪除，但是理論上應該用其他理由--象象🐘(留言|貢獻) 2025年11月2日 (日) 08:22 (UTC)[回复]
按WP:CSD#G5，頁面此前根據頁面存廢討論、檔案存廢討論、侵權審核或存廢覆核請求的結果而刪除，並在刪除後被重建，而頁面重建後需同時符合兩個情況：其首個版本的內容與被刪除的版本的全部或部分內容完全相同或非常相似；且其目前版本的內容與其首個版本的全部或部分內容完全相同或非常相似，則得以WP:CSD#G5提請快速刪除。惟該標準有但書，如果頁面重建後的版本與被刪除的版本明顯不同；或其現時的內容已不再適用此前頁面存廢討論、檔案存廢討論或存廢覆核請求中提出的刪除理由，而提請者認為需要刪除，請重新提交到頁面存廢討論、檔案存廢討論或存廢覆核請求，則不適用快速刪除。
本案，經檢視已刪除條目最後編輯紀錄（請注意未具有管理權限無法檢視）與User:Cwek/工作室/在地下城寻求邂逅是否搞错了什么登场人物列表的版本85488264，其內容與被刪除的版本的全部或部分內容完全相同或非常相似，且其目前版本的內容與其首個版本的全部或部分內容完全相同或非常相似，又考量到但書部分，重建後的版本確實與被刪除的版本未有明顯不同，其現時內容亦適用此前頁面被存廢討論時之樣態，固然應符合WP:CSD#G5。
因此，據前闡述，爭議頁面被掛WP:CSD#G5係有理由，惟管理員是否僅據G5之規定予以審查後做出刪除結論，我有不同意見。
參酌WP:UPYES，除了交流之外，使用者自治空間的其他合理用途包括但不限於：「正在進行的工作或您將來可能會回顧的內容（一般在子頁面）：草稿，尤其是您希望首先討論或徵求其他使用者意見的情況，例如擬議的重大變更」。考量到U:Cwek將爭議頁面放置於其使用者子頁面當中，又參酌該爭議頁面之上層頁面（即User:Cwek/工作室），直接且明確闡明计划或正在施工项目，基於WP:FAITH，我認為U:Cwek係為改善該爭議頁面，因此將其備份至子頁面當中，至前次於該頁面之編輯時間，應屬個該使用者之自由時間衡量，即使用者自治空間草稿沒有有效期限，因此不能也不應該僅僅因為其時間太長而將其刪除，WP:STALEDRAFT參照。
故綜上所述，我個人會認為個該爭議頁面均不應被刪除，謹此表達個人裁量供其他管理員與其他社群夥伴們參考。--小過兒（留言） 2025年11月2日 (日) 08:05 (UTC)[回复]
這樣一來，或許應該將User:Cheng Edmund/在地下城尋求邂逅是否搞錯了什麼登場人物列表提交至存廢覆核處理。--~2025-30871-38（留言） 2025年11月2日 (日) 08:38 (UTC)[回复]
以我的見解是如此沒錯。--小過兒（留言） 2025年11月2日 (日) 08:56 (UTC)[回复]
建议对G5有关适用命名空间的要求进行修改，参见英维G4其不包括转换为草稿空间和移动到用户空间的页面。
因为草稿之所以被称为草稿就是因为不够完善，如果将草稿、用户空间列为适用范围，那么就有些不合理了。--Luoniya（留言） 2025年11月2日 (日) 08:15 (UTC)[回复]
其實目前有限定要符合原提刪理由，不然如果限定不包括轉換為草稿空間和移動到使用者空間的頁面的話，有些內容不當的頁面而被刪除的頁面也會無法速刪。--象象🐘(留言|貢獻) 2025年11月2日 (日) 08:18 (UTC)[回复]
后一种情况无法符合SD的话，就应该放存废讨论。——Sakamotosan路过围观 | 避免做作，免敬 2025年11月2日 (日) 10:23 (UTC)[回复]
比如說之前達成共識不能放使用者命名空間的用戶框，其實因為有社群共識支撐是可以直接速刪的。--象象🐘(留言|貢獻) 2025年11月2日 (日) 12:32 (UTC)[回复]
SD应该针对有害的（G11）、可以立即判断（O1）的情况处置。用户页是一个用户自己的“半”自治空间，在不涉及广告、（外部）侵权内容、不严重违反用户页不允许放置的内容情况、不像是伪装条目的话，说真的，给我处理，我不觉得到需要删除的情况。就算针对“使用者命名空間的用戶框”，自用且不对应于Wikipedia:用戶框的“用户框应该用来显示专业，强烈不建议使用挑衅、冒犯或是反映不中立观点的用户框。”和同样对于用户页的不允许放置的内容情况，轻则不管，需要的话还是提报讨论并引述前一次讨论存废的意见。这也就是某些管理员过于教条主义，要有一定程度的自由裁量权，的需要。——Sakamotosan路过围观 | 避免做作，免敬 2025年11月3日 (一) 13:07 (UTC)[回复]
邀請當時參與User_talk:Manchiu#WP:G5适用于用户页討論的使用者參與討論@自由雨日、1F616EMO、Liu116。--~2025-30871-38（留言） 2025年11月2日 (日) 08:23 (UTC)[回复]
待处理的用户页页面草稿，Wikipedia:用戶頁，未动的原因就是没空。相关IP用户有点骚扰性。——Sakamotosan路过围观 | 避免做作，免敬 2025年11月2日 (日) 08:36 (UTC)[回复]
骚扰应该不至于。IP用户只是对两个相同内容的不同处理方式（或称“双重标准”）有所疑问。--12З4567（留言） 2025年11月2日 (日) 09:00 (UTC)[回复]
看其贡献，我被提移除回退权，居然是因为9月份一次恢复部分删除电视动画播放表的信息。而且真无聊到翻用户子页的内容？——Sakamotosan路过围观 | 避免做作，免敬 2025年11月2日 (日) 09:10 (UTC)[回复]
既然这几个临时账户都是同一人操作，这样看来IP确实有些过分。--12З4567（留言） 2025年11月2日 (日) 09:30 (UTC)[回复]
G5我所知道的常用场景是某个条目因为特定原因被删除（讨论删除或SD）后，以相似的形式原地重建，如果有人（可能是相应处理过的新页面巡查）留意到后，才提出G5处理。现在G5的操作有点侵犯用户页空间的自主性。——Sakamotosan路过围观 | 避免做作，免敬 2025年11月2日 (日) 08:39 (UTC)[回复]
原则是上User:Cheng_Edmund/在地下城尋求邂逅是否搞錯了什麼登場人物列表，只要放到用户空间，可能基于用户计划处理的草稿，不是原地重建的话，就不应该G5，就算放存废讨论，也可以声明为待处理的用户页草稿保留。问题是当时哪个管理员能这样理解偏差？——Sakamotosan路过围观 | 避免做作，免敬 2025年11月2日 (日) 08:44 (UTC)[回复]
WP:FAKEARTICLE这一条本身就有点问题，我认为应该需要注意的是，看上去像条目并且连页面标题都都伪装成的条目（也就是用DISPLAYTITLE将用户页的前缀也消除）的情况。这类页面的草稿要求也就是去除原有条目用分类、不打开搜索索引（用户页默认没有爬虫索引）就足够了。——Sakamotosan路过围观 | 避免做作，免敬 2025年11月2日 (日) 08:50 (UTC)[回复]
G5最近的修改应该是这个：Wikipedia_talk:快速删除#調整快速刪除方針G5條的用辭與適用範圍（2025年8月），要看当时讨论。至少我看来，这个修改大幅拓权了G5的效力。——Sakamotosan路过围观 | 避免做作，免敬 2025年11月2日 (日) 09:05 (UTC)[回复]
其實這次修訂對於爭議頁面意義不大，就算按舊規則解釋效果是相同的。--小過兒（留言） 2025年11月2日 (日) 09:27 (UTC)[回复]
我认为可能有影响：“此条不要求页面被删除前与被重建后所在的命名空间必须为同一命名空间。适用于所有命名空间，包括用户命名空间与草稿命名空间。”，看上去和原来“无论标题是否相同”对应，但常见情况下是针对条目空间下A标题内容提报删除后，以B标题内容方式躲避。对于这种情况是可能有冲突，因为A标题内容在非G11、侵权的情况，放到用户空间的，可能是基于用户空间自治下的草稿化处理。所以G5意外拓展了并且没考虑这类情况。——Sakamotosan路过围观 | 避免做作，免敬 2025年11月2日 (日) 10:27 (UTC)[回复]
其實綠字那一條是贅言，G系列的快速刪除本來就一直以來都是用於所有命名空間，並不是本次修訂後才出現的。--小過兒（留言） 2025年11月2日 (日) 12:07 (UTC)[回复]
不過G5的前提是刪除條件仍然符合，但是該條目是以收錄標準刪除的--象象🐘(留言|貢獻) 2025年11月2日 (日) 12:24 (UTC)[回复]
(※)注意：鑑於User:Cwek/工作室/在地下城寻求邂逅是否搞错了什么登场人物列表的G5已被拔除兩次，而上方標記的管理員並未受理，先前討論的參與者亦未回應，因此我已提出Wikipedia:存廢覆核請求#User:Cheng_Edmund/在地下城尋求邂逅是否搞錯了什麼登場人物列表。我先預言此事最終可能會被冷處理，隨後逐漸被遺忘。--~2025-31028-82（留言） 2025年11月3日 (一) 06:40 (UTC)[回复]
上面討論又長又臭沒看，我直接說自己意見：除非刪除原因是侵權或開盒等法律原因，或除非該用戶頁有被index；否則作為用戶自治空間放置草稿完全是正常操作，不應該予干涉。-某人✉ 2025年11月3日 (一) 13:00 (UTC)[回复]
希望有人能幫忙把這串討論搬去Wikipedia:互助客栈/方针謝謝。--~2025-30754-27（留言） 2025年11月3日 (一) 15:58 (UTC)[回复]
另外說一下我沒有很在意上面兩個條目到底要刪要留（那是方針的事），看看這串討論的標題「G5處理標準是否一致」，我要的只是相同標準。--~2025-30754-27（留言） 2025年11月3日 (一) 16:02 (UTC)[回复]
最後補充說明，本串討論及存廢覆核以行動版編輯的臨時帳號皆為我本人。由於個人原因是使用公用手機編輯，為了安全起見而使用無痕模式，因此未紀錄Cookie，導致每次都是不同帳號。--~2025-30754-27（留言） 2025年11月3日 (一) 16:10 (UTC)[回复]
真发方针版转头就会被人按WP:CON/RULES#POL送去WT:快速删除。如果你想在客栈煮就在这煮。--Srapoj（留言） 2025年11月3日 (一) 16:25 (UTC)[回复]
G5要求在删除后被重建，Cwek的内容不符合G5，但是可以提报著作权侵犯，或者根據WP:UPNOT提删。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月3日 (一) 16:05 (UTC)[回复]
其實因為cc-by-sa，再加上這裡可以查到以前的作者，理論上只要標明來源為被刪除的在地下城尋求邂逅是否搞錯了什麼登場人物列表即可（，因為）--象象🐘(留言|貢獻) 2025年11月3日 (一) 16:14 (UTC)[回复]
確實有時間線的問題，屬實沒想到，那其實算是方針有漏洞，只要在頁面即將被刪除前備份就可以躲掉G5。--~2025-30754-27（留言） 2025年11月3日 (一) 16:16 (UTC)[回复]
我认为G5用于处理转移到草稿类页面的页面本来就有问题，或者具有灰色空间，管理员可以不执行这个SD。WP:COPIES（不许长期复制条目空间内容）和WP:STALEDRAFT（偷用户稿到公共稿）这两个本身有对用户自治的合理使用权限，应该适当放松。——Sakamotosan路过围观 | 避免做作，免敬 2025年11月5日 (三) 07:10 (UTC)[回复]
Cheng Edmund当时说过自己想搞个备份，没有动手改善的想法，如果不符合现行规则，那确实只能删除掉。Cwek有明确改善重建的意图，虽然很明显是没空，这时明显就不能速删，至于以前参与该条目编辑者名单的问题，上面有用户说是可以查到的，而且若条目确实能够改善的话，可以走存废复核讨论程序连带页面编辑历史一起恢复，然后再将改善后的版本覆盖上去，毕竟地错小说21册，哪怕是精简角色介绍，从头开始写起角色列表条目也是一项大工程啊。--#MilanoCortina2026Countdown94Days 2025年11月4日 (二) 10:04 (UTC)[回复]

关于一些问题

主页面：Draft_talk:星绽OS § WP:LLM嫌疑

请各位前辈先看该讨论页，我的主要问题是由于我的经验不足，还想请各位一起就这个话题发表一下意见，具体该如何处理等等--莱斯男孩儿（查·论·编） 2025年11月1日 (六) 10:56 (UTC)[回复]

都快两天了WP:RFCONFIRM还没回复吗

都快两天了WP:RFCONFIRM还没回复吗，我现在提存废讨论都做不到ww--莱斯男孩儿（查·论·编） 2025年11月1日 (六) 11:07 (UTC)[回复]

草，用safesubst提上了，但是这个权限还是需要的，希望能够处理一下，十分感谢--莱斯男孩儿（查·论·编） 2025年11月1日 (六) 11:17 (UTC)[回复]

請求協助上傳檔案 2025-11-01 15:20

我想要上傳的圖片來源是<自行拍攝>，想要使用在Capper的<图片 = >。 --Koiigoodnite（留言） 2025年11月1日 (六) 15:20 (UTC)[回复]

@Koiigoodnite：自行拍摄请上传至维基共享资源。--__(´▽`ʃ♡ƪ) 2025年11月2日 (日) 04:10 (UTC)[回复]

如何簡寫“（台灣人士）訪問中國大陸”？

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

根據MOS:兩岸中的MOS:中，“訪問中國大陸”似乎不宜簡寫成“訪中”。但該方針亦沒有提到可以將“大陸”進一步簡寫為“陸”，故不太清楚該如何處理。部分條目中，如果每次提及該行為都寫作“訪問大陸”，會造成一定冗餘，故請教正確的編輯方式。--Michael nju（留言） 2025年11月2日 (日) 13:31 (UTC)[回复]

那就不要简写吧。首次提到写“访问中国大陆”，之后可选简写“访问大陆”。引文除外。--YFdyh000（留言） 2025年11月2日 (日) 13:53 (UTC)[回复]
主要是一些條目中可能反復提及，比如“此次訪問大陸行程由……策劃”、“此次訪問大陸意義……”感覺看著好像會有一點點太囉嗦。
不過我剛才又想了一下，兩岸四地方針似乎應該理解為“不要這麽做”（黑名單機制），比如大陸稱對岸總統為“台當局領導人”，台灣稱對岸為“中共國”/“敵對勢力”，兩岸四地方針主要是禁止這些仇恨言論。
而對於“訪問中國大陸”這一行為，藍綠媒體大概有“訪陸”和“訪中”兩種說法，而僅有後者不被兩岸四地方針認可，前者未提到的話，感覺似乎意味著使用“訪陸”應該沒有問題？
或者如果在不強調目的地的時候，寫為“此次訪問”可能也是一個解方？🤔--Michael nju（留言） 2025年11月2日 (日) 17:21 (UTC)[回复]
「訪陸」或「訪中」。後面這個有「兩國論」嫌疑，但前者又可能違反格式手冊，除了可靠來源轉引，最好還是使用全稱。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月3日 (一) 07:31 (UTC)[回复]
同意YFdyh000的见解，后可称“访问大陆”，我认为这是最简称。如果觉得过于啰嗦的话可以直接删去“大陆”二字，仅提及“访问”，在段内应该不会有歧义。--Cygz（留言） 2025年11月3日 (一) 15:25 (UTC)[回复]
前面提及了中国大陆當然可以简称陆啊，MOS:CS4D也没有禁止说「陆」，你维语文不行是这樣的。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月4日 (二) 05:20 (UTC)[回复]

請求協助上傳檔案 2025-11-03 19:46

我想要上傳的圖片來源是<從某個網址下載，請提供網址 / 自行拍攝>，想要使用在請提供條目名稱（如果条目还不存在，请先建立条目再请求上传文件）的<資訊框/某個段落，請說明>。 --Phoenix dance school（留言）──此條未正確附上簽名时间的留言于2025年11月3日 (一) 19:46 (UTC)加入。[回复]

？--Vertin,do you want to be the timekeeper? 2025年11月5日 (三) 03:48 (UTC)[回复]
话说用户名违规了吧--亚蓝青空 [ 🕊️UT 📝签] 2025年11月5日 (三) 04:08 (UTC)[回复]
原請求人的Username已更改。--竹林＝月光 2025年11月5日 (三) 05:48 (UTC)[回复]
@Norazhang7787：请提供url和条目名称。--__(´▽`ʃ♡ƪ) 2025年11月5日 (三) 10:44 (UTC)[回复]

請求協助上傳檔案 2025-11-05 14:50

我想要上傳的圖片來源是<http://www.shijieditu.net/ditu/allimg/170829/1-1FR9234945520.jpg>，想要使用在中蒙俄经济走廊的<通道>条目里，作为对该条目的直观显示。 --Cattt1（留言） 2025年11月5日 (三) 14:50 (UTC)[回复]

相关性似乎不大？来源给的似乎只介绍一带一路，而且明显有其他自由来源可以使用（WP:F10）。--__(´▽`ʃ♡ƪ) 2025年11月5日 (三) 15:16 (UTC)[回复]
这是我能找到的最清晰的，包含中蒙俄经济走廊的示意图了，并没有单独示意此条目的自由来源--Cattt1（留言） 2025年11月5日 (三) 15:59 (UTC)[回复]
我上傳了一張依照該圖所繪製的SVG地圖，以CC-BY-SA+CC0双授權（因為地圖本身以CC-BY-SA授權）後放到條目中了。可能位置不算那麼精準，但足夠自由。--Saimmx（留言） 2025年11月6日 (四) 03:57 (UTC) 👍1[回复]
看到了您创建的作品了，谢谢🙏，画的很好，说实话我也想在学如何自己画图--Cattt1（留言） 2025年11月6日 (四) 04:04 (UTC)[回复]
本人這張是用Inkscape疊著那張地圖後描出來的。有興趣的話Inkscape官方網站和共享資源都有對應資源可試。SVG的技術細節則可去MDN看看。--Saimmx（留言） 2025年11月6日 (四) 04:11 (UTC)[回复]
好的谢谢--Cattt1（留言） 2025年11月6日 (四) 04:14 (UTC)[回复]

請求移動頁面 2025-11-07 03:31

想要新增條目的中文頁面，由於沒有權限我是先寫在草稿內． 目前大致上校對完成但是沒有權限移動到公開頁． 請問有辦法協助移動嗎？謝謝． 頁面：Draft:TOMOO--Attain0235（留言） 2025年11月7日 (五) 03:31 (UTC)[回复]

已代為提交草稿審核。另外，您也可以看看T:AFC submission/doc的說明，來自行放入對應情況的提交草稿審核用模板，祝編安～--竹林＝月光 2025年11月7日 (五) 03:58 (UTC)[回复]
謝謝幫忙！--Attain0235（留言） 2025年11月7日 (五) 13:57 (UTC)[回复]

請求協助上傳檔案 2025-11-07 08:37

我想要上傳的圖片來源是<從某個網址下載，請提供網址 / 自行拍攝>，想要使用在請提供條目名稱（如果条目还不存在，请先建立条目再请求上传文件）的<資訊框/某個段落，請說明>。 --DrSohailKhan（留言） 2025年11月7日 (五) 08:37 (UTC)[回复]

请提供完整信息--Luoniya（留言） 2025年11月7日 (五) 13:38 (UTC)[回复]

請求協助上傳檔案 2025-11-07 11:14

我想要上傳的圖片來源是<自行拍攝>，想要使用在請提供條目名稱（如果条目还不存在，请先建立条目再请求上传文件）的<資訊框/某個段落，請說明>。 --Postgraduates（留言） 2025年11月7日 (五) 11:14 (UTC)[回复]

请提供完整信息--Luoniya（留言） 2025年11月7日 (五) 13:38 (UTC)[回复]

條目「神職 (神道)」被破壞

條目神職 (神道)被惡意破壞。--JimmyKcrty（留言） 2025年11月8日 (六) 04:51 (UTC)[回复]

已有其他編者回退。--Sakurase留言 2025年11月8日 (六) 04:53 (UTC)[回复]

关于T:user info模板的问题

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

请问关于T:user info，为什么改image参数图片仍然显示的是File:How_Wikipedia_Works.jpg，参见我沙盒User:GVZpedia/沙盒/测试页的源代码。--𝑮𝑽𝒁𝓹𝓮𝓭𝓲𝓪 📭 2025年11月8日 (六) 05:36 (UTC)[回复]

已修改，参数应当为image name--Luoniya（留言） 2025年11月8日 (六) 05:42 (UTC)[回复]
虽然但是这样来看Image参数不就是无效的吗？--𝑮𝑽𝒁𝓹𝓮𝓭𝓲𝓪 📭 2025年11月8日 (六) 05:49 (UTC)[回复]
看了模板参数确实，英维上这个是可以用的--Luoniya（留言） 2025年11月8日 (六) 06:22 (UTC)[回复]
我调了一下模板源码，现在支持image了（其实不过是因为模板文档照搬英维版本，所以与实际代码不符；比方说英维支持传blank值来隐藏图片，这边的版本仍不支持）。--Srapoj（留言） 2025年11月8日 (六) 18:59 (UTC)[回复]

請問en:Template:Indian people sidebar可否中文化？

如果可以的話，應該在原始碼中修訂哪個部分？我今早嘗試，找不到訣竅。謝謝。--ThomasYehYeh（留言） 2025年11月10日 (一) 00:15 (UTC)[回复]

所引用的模板名在本地不存在，已建立相应页面（重定向）。--YFdyh000（留言） 2025年11月10日 (一) 00:36 (UTC)[回复]
建議參考Wikipedia:互助客栈/求助/存档/2025年10月#我嘗試把en:Template:Indian people sidebar翻譯為中文，似乎不行中，Kcx36君提供的沙盒版本之原始碼修改--竹林＝月光 2025年11月10日 (一) 01:56 (UTC)[回复]

另外，有關en:Quit India movement中{{Infobox protest | title = Quit India Movement的中文化問題

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

我在沙盒中也發現似乎不能中文化，不曉得是否有先進可指教？謝謝。--ThomasYehYeh（留言） 2025年11月10日 (一) 00:20 (UTC)[回复]

我说一下方法。您预览会看到红色的 Template:Infobox protest 链接，点击打开，然后在浏览器地址栏将zh改为en并打开以前往英文维基相应页面。去复制那里的模板代码到本地对应页面以创建和中文化，或者观察到那里是重定向、重定向后的页面有相应中文页面（在侧栏）则只需在本地为红色的名称建立相应重定向，或者源码中将调用的模板名称改为本地相应模板名称。--YFdyh000（留言） 2025年11月10日 (一) 00:41 (UTC)[回复]
不需要這麼做，因為英維的Template:Infobox protest是指向Template:Infobox civil conflict的重定向，現已在中維建立該重定向。--竹林＝月光 2025年11月10日 (一) 01:41 (UTC)[回复]

編輯爭議

我是LTA:SM，我認為Seven Flame Red在古洞站的這一筆編輯Special:Diff//89827902是對的，只是還沒附上參考來源而已，我不明白那個奇怪的薏仁將為何把它回退，我希望有人能夠幫忙研究一下這個頁面。--萬里狐兔（留言） 2025年11月10日 (一) 04:56 (UTC)[回复]

@千村狐兔君，提問者有問題請求您協助，我想你大概懂提問者在問什麼，你懂這是什麼意思的:)--薏仁將🍀 2025年11月10日 (一) 05:01 (UTC)[回复]
原創研究，你要拿來公審，那沒問題，看看誰理虧。--薏仁將🍀 2025年11月10日 (一) 05:03 (UTC)[回复]

註：此處原有文字，因為違反不要人身攻擊方針，已由真理果是我推的V（留言）於2025年11月10日 (一) 05:23 (UTC)刪除，尚祈見諒。若有異議請至互助客棧或向管理員反映。[回复]

我不明白加个来源有多难？简简单单引用Instagram官方post就可以了，什么是只是還沒附上參考來源而已，如果个个都像你这么做，维基百科全都是原创研究怎么办？--Cygz（留言） 2025年11月10日 (一) 05:11 (UTC)[回复]
我也有尋找參考來源的，但我只是詢問一下這個編輯有沒有問題而已。--萬里狐兔（留言） 2025年11月10日 (一) 05:14 (UTC)[回复]
有模板给你用还会有什么问题？你补充上来源一点问题没有，不补充来源被回退肯定是你的问题啊？你读过维基百科的WP:五大支柱吗？有可靠来源总比完全不列举好吧？希望您能意识该问题。--Cygz（留言） 2025年11月10日 (一) 05:16 (UTC)[回复]
你有你就直接補就可以啦…明知道刪除的理由是哪個環節那個點，結果你自己也沒補直接發文公審，你是想？--薏仁將🍀 2025年11月10日 (一) 05:16 (UTC)[回复]
我今次回來其實也想大家給我一個機會，可以再能夠在維基百科繼續生存，之後我被封鎖也不要緊，我會繼續在討論頁中寫道歉啟示。--萬里狐兔（留言） 2025年11月10日 (一) 05:19 (UTC)[回复]
您已被封禁10年了，请您自重。我没有义务帮你擦屁股。--Cygz（留言） 2025年11月10日 (一) 05:21 (UTC)[回复]
我再次聲明，我沒有刻意做明顯破壞行為，不像其他LTA如夏土賢等不停重複類似行為。--萬里狐兔（留言） 2025年11月10日 (一) 05:27 (UTC)[回复]
人家刻意假扮我，我也覺得很討厭。--萬里狐兔（留言） 2025年11月10日 (一) 05:28 (UTC)[回复]

請問如何合併或刪除條目？

事由我想合併/刪除［石片］條目，但把2個都變成同一個名稱了⋯⋯--夜機（留言） 2025年11月10日 (一) 12:30 (UTC)[回复]

石片公具--夜機（留言） 2025年11月10日 (一) 13:07 (UTC)[回复]

請問如何保留使用者自治空間？

無法參與使用者自治空間存廢討論是因為沒有付費嗎?--黨主席莊葛格（留言） 2025年11月10日 (一) 15:06 (UTC)[回复]

你不是參與了嗎？另外維基百科不會要求編輯者付費。--象象🐘(留言|貢獻) 2025年11月10日 (一) 15:42 (UTC)[回复]


條目探討

建議整頓部分主題和專題

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

據我自己的發現，有部分的主題和專題存在內容重疊的問題（比如Portal:城市軌道交通和WikiProject:城市軌道交通），而且無論是主題、專題，都有不少不活躍的（比如Portal:香港巴士總站、Portal:香港小巴路線、Portal:香港巴士路線等等）。我認為維基百科需要認真整頓一下，乃至研究合併兩者方便維護。不知道大家的意願如何？--owennson（聊天室、獎座櫃） 2025年7月29日 (二) 10:00 (UTC)[回复]

主題是讀者向內容，專題是編者向內容，沒有什麼重疊可說。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年7月29日 (二) 10:06 (UTC)[回复]
同意。目前中文维基有大约363个主题，大部分似乎10年多没有更新了。如果有人愿意，可以考虑挑出几十个值得维护的主题，予以特别标记、关注和更新。 --Zhenqinli（留言） 2025年9月5日 (五) 00:02 (UTC)[回复]
專題「定義條目如何編寫、格式等規範，並用以擬定編輯計畫等活動，以提供編者如何編輯為主」、主題「展示領域條目供讀者閱讀，乃該領域條目整理，以讀者展示為主」，差那麼大，合併個毛。人家日維專題空間和主題空間運作得好好的，有甚麼問題？ 我之前花那麼多時間和心力Wikipedia:专题/提升为命名空间分離整理专题命名空間，你故意當我努力是假的是不是？，(！)強烈抗议合併兩者！-- 宇帆-娜娜奇🐰桑朵菈🌿草茶☕（留言☎️·簽到☘️） 2025年7月29日 (二) 10:12 (UTC)[回复]
這樣做只會進一步分散維護能力。專題都已經那麼多不活躍的了，還要再疊加主題上去，你確定整個社群有能力同時維持兩者的運作，而且不會丟空？不少Portal的新聞都已經是N年前的舊聞了，從來沒有人更新過，合理麼？--owennson（聊天室、獎座櫃） 2025年7月29日 (二) 12:02 (UTC)[回复]
修正討論格式，改星號縮排爲冒號縮排。1F616EMO（喵留言～回覆請ping） 2025年7月29日 (二) 16:18 (UTC)[回复]
你冷靜一下，根本沒人說要廢除專題。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年7月29日 (二) 16:56 (UTC)[回复]
。？ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年7月29日 (二) 20:02 (UTC)[回复]
(－)反对：明顯用途不同。反對一刀切，明明還有活躍的，反對只因為存在不活躍的就要把活躍的也拉下水。-- 宇帆-娜娜奇🐰桑朵菈🌿草茶☕（留言☎️·簽到☘️） 2025年7月30日 (三) 03:40 (UTC)[回复]
同魔琴意見，兩者有本質不同，不宜直接合併。但同意兩者存在重疊，或可鼓勵專題參與者協助維護主題；對於專題管轄範圍和主題收錄範圍高度重疊的情況（如閣下提到的「城市軌道交通」），甚至可以讓相關專題專責管理該主題（非只允許該專題管理該主題，因維基百科人人可編輯，但社羣可預期該專題會積極維護該主題）。--1F616EMO（喵留言～回覆請ping） 2025年7月29日 (二) 16:25 (UTC)[回复]
同意由專題參與者管理主題，至少不會沒人管。但某些長年累月都沒人管的主題和專題，恐怕要研究其去留了。--owennson（聊天室、獎座櫃） 2025年7月29日 (二) 16:47 (UTC)[回复]
另一个想法是把小主题合并为大主题，比如把Portal:鐵路、Portal:中国铁路、Portal:城市轨道交通整合到Portal:交通之类。不过主题创建者不一定愿意🤣
PS：感觉中文维基连许多领域条目更新都不及时，就更不用说更新主题页了🤣--𝐹𝑜𝑟 𝐸𝑎𝑐ℎ ... 𝑁𝑒𝑥𝑡 2025年7月29日 (二) 16:30 (UTC)[回复]
小主題合併為大主題或許不一定必要，也可以指定小主題為大主題的子主題，這就不牽涉主題合併的問題了。Sanmosa DC23 2025年7月31日 (四) 07:56 (UTC)[回复]
希望能夠確定兩者之間的關係。另外，目前確實許多主題或專題可以整併，也可以討論一下處理原則。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年7月29日 (二) 16:56 (UTC)[回复]
反對主題與專題的合併，但不反對主題與主題、專題與專題的合併。Sanmosa DC23 2025年7月31日 (四) 07:57 (UTC)[回复]
倒不如先將所有專題及主題列出？我以前曾經想試著釐清專題狀態，但到現在都沒空處理。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年8月3日 (日) 03:21 (UTC)[回复]
列表
专题与主题列表
# 专题 主题
1 WikiProject:2009年H1N1流感大流行（论）
2 Portal:2012_Chinanews-brow（论）
3 WikiProject:2019冠状病毒病（论） Portal:2019冠状病毒病（论）
4 WikiProject:ACG（论）
5 WikiProject:Android（论） Portal:Android（论）
6 WikiProject:BDSM（论）
7 Portal:Fate（论）
8 WikiProject:Google（论） Portal:Google（论）
9 WikiProject:Growth（论）
10 Portal:GUNDAM（论）
11 WikiProject:Hello!_Project（论）
12 Portal:Keroro軍曹（论）
13 WikiProject:LGBT（论） Portal:LGBT（论）
14 WikiProject:Linux（论） Portal:Linux（论）
15 Portal:MAD（论）
16 Portal:MUN（论）
17 Portal:Nuvola_apps_bookcase.svg（论）
18 Portal:PlayStation（论）
19 Portal:Samsung_Galaxy（论）
20 WikiProject:TED（论）
21 Portal:VRMMO（论）
22 Portal:Xbox（论）
23 WikiProject:YouTube（论）
24 WikiProject:一級方程式（论） Portal:一級方程式（论）
25 WikiProject:三国（论） Portal:三国（论）
26 WikiProject:上海（论） Portal:上海（论）
27 Portal:上海公交（论）
28 Portal:上海新闻动态（论）
29 Portal:世嘉（论）
30 WikiProject:世界遗产（论） Portal:世界遗产（论）
31 Portal:东京（论）
32 Portal:东北（论）
33 Portal:东德（论）
34 WikiProject:两栖动物和爬行动物（论）
35 Portal:中世纪（论）
36 Portal:中华人民共和国（论）
37 WikiProject:中华文化（论）
38 WikiProject:中华民族（论）
39 WikiProject:中国（论） Portal:中国（论）
40 WikiProject:中国交通（论）
41 Portal:中国共产党（论）
42 WikiProject:中国君主（论）
43 WikiProject:中国城市（论）
44 Portal:中国建筑（论）
45 Portal:中国数学史（论）
46 WikiProject:中国文化遗产（论） Portal:中国文化遗产（论）
47 WikiProject:中国河流（论）
48 WikiProject:中国省份（论）
49 WikiProject:中国行政区划（论）
50 WikiProject:中国铁路（论） Portal:中国铁路（论）
51 WikiProject:中国高校（论） Portal:中国高校（论）
52 WikiProject:中國傳統聲音（论）
53 Portal:中國國民黨（论）
54 Portal:中國大陸新聞動態（论）
55 WikiProject:中外交通史（论） Portal:中外交通史（论）
56 WikiProject:中药（论）
57 Portal:中華民國（论）
58 WikiProject:中華民國政府（论）
59 WikiProject:丹麥（论）
60 WikiProject:主题（论）
61 WikiProject:乒乓球（论）
62 Portal:习近平（论）
63 WikiProject:云南（论） Portal:云南（论）
64 Portal:云南新闻动态（论）
65 WikiProject:互联网（论） Portal:互联网（论）
66 WikiProject:亚洲（论） Portal:亚洲（论）
67 Portal:亚运会（论）
68 WikiProject:亞利桑那州（论） Portal:亞利桑那州（论）
69 WikiProject:亞美尼亞（论） Portal:亞美尼亞（论）
70 WikiProject:交通（论） Portal:交通（论）
71 WikiProject:交通运输（论）
72 WikiProject:人体解剖学（论）
73 WikiProject:人名学（论）
74 WikiProject:人權（论） Portal:人權（论）
75 Portal:人物（论）
76 WikiProject:人类学（论） Portal:人类学（论）
77 WikiProject:以色列（论） Portal:以色列（论）
78 Portal:任天堂（论）
79 Portal:伊斯兰教（论）
80 WikiProject:伊朗（论） Portal:伊朗（论）
81 WikiProject:传统百科全书条目（论）
82 WikiProject:传记（论）
83 Portal:体育运动（论）
84 WikiProject:佛教（论） Portal:佛教（论）
85 WikiProject:佛羅里達州（论） Portal:佛羅里達州（论）
86 WikiProject:來源（论）
87 WikiProject:來源互助（论）
88 WikiProject:侵犯維基人版權調查（论）
89 WikiProject:俄羅斯（论） Portal:俄罗斯（论）
90 WikiProject:保齡球（论）
91 WikiProject:倫敦（论） Portal:倫敦（论）
92 Portal:假面騎士（论）
93 WikiProject:傳播媒體（论）
94 WikiProject:優良條目（论）
95 WikiProject:元素（论）
96 Portal:兩棲爬行動物（论）
97 WikiProject:公司（论）
98 WikiProject:公路（论） Portal:公路（论）
99 Portal:六四事件（论）
100 WikiProject:共产主义（论） Portal:共產主義（论）
101 WikiProject:兴化（论）
102 Portal:内蒙古新闻动态（论）
103 Portal:农业和农学（论）
104 Portal:冷战（论）
105 Portal:几何（论）
106 WikiProject:几何学（论） Portal:几何学（论）
107 WikiProject:分子與細胞生物學（论） Portal:分子与细胞生物学（论）
108 WikiProject:列表（论）
109 WikiProject:創作物專案互進（论）
110 WikiProject:加利福尼亞州（论） Portal:加利福尼亞州（论）
111 Portal:加尔文主义（论）
112 WikiProject:加拿大（论） Portal:加拿大（论）
113 Portal:加泰隆尼亞（论）
114 Portal:动漫（论）
115 WikiProject:動畫（论） Portal:动画（论）
116 WikiProject:動物（论） Portal:動物（论）
117 WikiProject:勞工運動（论）
118 WikiProject:匈牙利（论） Portal:匈牙利（论）
119 WikiProject:化學（论） Portal:化学（论）
120 WikiProject:化学工程（论）
121 WikiProject:化学物质（论）
122 WikiProject:北京（论） Portal:北京（论）
123 Portal:北京新闻动态（论）
124 Portal:北大西洋公約組織（论）
125 Portal:南亚（论）
126 WikiProject:南京（论） Portal:南京（论）
127 Portal:南开大学（论）
128 Portal:南投（论）
129 WikiProject:南满洲铁道（论）
130 WikiProject:南非（论） Portal:南非（论）
131 WikiProject:博物馆（论）
132 WikiProject:印度（论）
133 Portal:危險性物質（论）
134 WikiProject:历史（论） Portal:历史（论）
135 Portal:原子核物理学（论）
136 WikiProject:原核生物（论）
137 Portal:原神（论）
138 WikiProject:叙利亚（论）
139 WikiProject:古典音乐（论） Portal:古典音乐（论）
140 WikiProject:古巴（论）
141 Portal:古希臘宗教（论）
142 WikiProject:古生物学（论）
143 Portal:古羅馬（论）
144 WikiProject:另類搖滾（论）
145 WikiProject:可再生能源（论） Portal:可再生能源（论）
146 Portal:可持续发展（论）
147 WikiProject:可用性（论）
148 WikiProject:台州（论） Portal:台州（论）
149 Portal:台灣基進（论）
150 Portal:台灣獨立運動（论）
151 Portal:史克威尔艾尼克斯（论）
152 Portal:吉卜力工作室（论）
153 WikiProject:吉林（论）
154 WikiProject:吉林市（论）
155 Portal:吉林新闻动态（论）
156 Portal:名偵探柯南（论）
157 WikiProject:含能材料（论）
158 Portal:咖啡（论）
159 WikiProject:品牌（论）
160 Portal:哆啦A夢（论）
161 WikiProject:哈利波特（论） Portal:哈利波特（论）
162 WikiProject:哈尔滨（论）
163 WikiProject:哈薩克（论）
164 WikiProject:哥倫比亞（论）
165 WikiProject:哲学（论） Portal:哲学（论）
166 Portal:唐朝（论）
167 Portal:唐納·川普（论）
168 WikiProject:商业（论）
169 WikiProject:啤酒（论） Portal:啤酒（论）
170 WikiProject:喜剧（论）
171 WikiProject:喬治亞（论）
172 WikiProject:四川（论） Portal:四川（论）
173 Portal:四川新闻动态（论）
174 WikiProject:园艺学（论）
175 WikiProject:国家和地区（论）
176 WikiProject:國際關係（论） Portal:国际关系（论）
177 Portal:国际歌（论）
178 Portal:图书馆和博物馆（论）
179 WikiProject:图像与多媒体（论）
180 Portal:國際足協世界盃（论）
181 WikiProject:圍棋（论）
182 Portal:園藝（论）
183 WikiProject:圖書館（论）
184 WikiProject:土耳其（论） Portal:土耳其（论）
185 WikiProject:地图（论） Portal:地圖（论）
186 WikiProject:地球科學（论） Portal:地球科學（论）
187 WikiProject:地理學（论） Portal:地理学（论）
188 WikiProject:地質（论）
189 WikiProject:地震（论）
190 Portal:埃及（论）
191 WikiProject:城市（论）
192 WikiProject:城市軌道交通（论） Portal:城市轨道交通（论）
193 WikiProject:基督教（论） Portal:基督教（论）
194 WikiProject:基礎條目（论）
195 WikiProject:基辅罗斯（论）
196 Portal:基隆（论）
197 WikiProject:堪薩斯州（论） Portal:堪薩斯州（论）
198 Portal:夏洛克·福尔摩斯（论）
199 WikiProject:多面體（论）
200 WikiProject:大学（论） Portal:大学（论）
201 WikiProject:大蒙古帝國（论）
202 Portal:大阪（论）
203 Portal:大陸地區（论）
204 WikiProject:大韩民国（论） Portal:大韩民国（论）
205 Portal:天主教（论）
206 WikiProject:天文（论）
207 Portal:天文学（论）
208 WikiProject:天津（论） Portal:天津（论）
209 Portal:天津新闻动态（论）
210 WikiProject:太平洋颱風季（论） Portal:太平洋颱風季（论）
211 Portal:太空（论）
212 WikiProject:太阳系（论） Portal:太阳系（论）
213 WikiProject:奖项（论）
214 Portal:奥地利（论）
215 WikiProject:奥运会（论） Portal:奥运会（论）
216 Portal:奧斯卡金像獎（论）
217 WikiProject:女性（论）
218 WikiProject:女性主義（论） Portal:女性主義（论）
219 WikiProject:女性科学家（论）
220 WikiProject:妇女史（论）
221 WikiProject:孟加拉（论）
222 WikiProject:学术期刊（论）
223 WikiProject:學校（论）
224 Portal:宁夏（论）
225 Portal:宁夏新闻动态（论）
226 WikiProject:宁德（论） Portal:宁德（论）
227 WikiProject:宁波（论） Portal:宁波（论）
228 Portal:安哥拉（论）
229 WikiProject:安徽（论） Portal:安徽（论）
230 Portal:安徽新闻动态（论）
231 WikiProject:宗教（论） Portal:宗教（论）
232 Portal:宜蘭（论）
233 WikiProject:密码学（论） Portal:密码学（论）
234 WikiProject:寺庙（论）
235 Portal:導盲犬（论）
236 WikiProject:小作品分類（论）
237 WikiProject:小作品改進（论）
238 WikiProject:小學（论）
239 WikiProject:小行星列表（论）
240 WikiProject:小說（论） Portal:小說（论）
241 Portal:少女漫畫（论）
242 Portal:尼日利亚（论）
243 WikiProject:山东（论） Portal:山东（论）
244 Portal:山东新闻动态（论）
245 WikiProject:山脉（论）
246 WikiProject:山西（论） Portal:山西（论）
247 Portal:山西新闻动态（论）
248 WikiProject:岛屿（论） Portal:岛屿（论）
249 Portal:岡山（论）
250 Portal:島根（论）
251 Portal:工程（论）
252 WikiProject:工程学（论）
253 WikiProject:巴哈伊信仰（论） Portal:巴哈伊信仰（论）
254 WikiProject:巴基斯坦（论）
255 WikiProject:巴士（论） Portal:巴士（论）
256 WikiProject:巴西（论） Portal:巴西（论）
257 Portal:希腊（论）
258 WikiProject:希腊神话（论）
259 WikiProject:年（论）
260 WikiProject:年代学分类（论）
261 WikiProject:年号（论）
262 WikiProject:广东（论） Portal:广东（论）
263 Portal:广东新闻动态（论）
264 WikiProject:廣州（论） Portal:广州（论）
265 Portal:广德（论）
266 Portal:广西新闻动态（论）
267 WikiProject:库尔德（论） Portal:库尔德（论）
268 WikiProject:康乃狄克州（论） Portal:康乃狄克州（论）
269 Portal:廣島（论）
270 WikiProject:广西（论） Portal:廣西（论）
271 WikiProject:建立條目（论）
272 WikiProject:建築（论） Portal:建築（论）
273 WikiProject:开始结束时间（论）
274 Portal:彝族与彝语支民族（论）
275 Portal:形而上学（论）
276 Portal:彰化（论）
277 WikiProject:影片維基（论）
278 WikiProject:微格式（论）
279 WikiProject:微软（论） Portal:微軟（论）
280 WikiProject:德国（论） Portal:德国（论）
281 WikiProject:德国历史（论）
282 WikiProject:心理學（论） Portal:心理学（论）
283 Portal:性（论）
284 WikiProject:性与性学（论）
285 WikiProject:性别（论）
286 Portal:怪物彈珠（论）
287 Portal:恐怖主義（论）
288 WikiProject:恐龍（论） Portal:恐龙（论）
289 WikiProject:恒星（论） Portal:恒星（论）
290 WikiProject:惊悚（论） Portal:惊悚（论）
291 WikiProject:惠州（论） Portal:惠州（论）
292 WikiProject:意大利（论）
293 WikiProject:愛荷華州（论） Portal:愛荷華州（论）
294 Portal:戏剧（论）
295 WikiProject:成语（论）
296 Portal:我的世界（论）
297 Portal:战列舰（论）
298 Portal:战国（论）
299 Portal:戰車（论）
300 Portal:手机版首页（论）
301 WikiProject:技术（论） Portal:技術（论）
302 Portal:拉脱维亚（论）
303 WikiProject:拜占庭帝国（论） Portal:拜占庭帝国（论）
304 Portal:捕鱼（论）
305 Portal:推想小說（论）
306 WikiProject:摄影（论） Portal:摄影（论）
307 WikiProject:撞球（论）
308 WikiProject:政治（论） Portal:政治（论）
309 Portal:政黨（论）
310 WikiProject:教育（论） Portal:教育（论）
311 WikiProject:数（论）
312 WikiProject:数学（论） Portal:数学（论）
313 WikiProject:文件格式（论）
314 Portal:文化（论）
315 WikiProject:文字（论） Portal:文字（论）
316 WikiProject:文學（论） Portal:文学（论）
317 Portal:文莱（论）
318 WikiProject:斯諾克（论）
319 WikiProject:新加坡（论） Portal:新加坡（论）
320 WikiProject:新疆（论） Portal:新疆（论）
321 Portal:新疆新闻动态（论）
322 Portal:新竹（论）
323 Portal:新聞動態（论）
324 WikiProject:新闻事件（论）
325 WikiProject:新闻学（论）
326 Portal:新陈代谢（论）
327 Portal:无政府主义（论）
328 WikiProject:无线电（论） Portal:无线电（论）
329 WikiProject:日（论）
330 WikiProject:日本（论） Portal:日本（论）
331 WikiProject:日本天皇（论）
332 Portal:日本新聞動態（论）
333 WikiProject:日本行政區劃（论）
334 Portal:日本鐵路（论）
335 Portal:日食（论）
336 WikiProject:日食及月食（论）
337 WikiProject:时间（论）
338 WikiProject:时间分类（论）
339 WikiProject:明尼苏达州（论）
340 WikiProject:星座（论）
341 Portal:星球大战（论）
342 WikiProject:星际旅行（论）
343 Portal:星际迷航（论）
344 Portal:時代力量（论）
345 WikiProject:智利（论）
346 WikiProject:智能手机（论）
347 Portal:暮光之城（论）
348 WikiProject:书籍（论） Portal:書籍（论）
349 WikiProject:月球（论） Portal:月球（论）
350 Portal:有机化学（论）
351 WikiProject:有聲維基百科（论）
352 WikiProject:朝代（论）
353 WikiProject:朝鮮半島（论） Portal:朝鮮半島（论）
354 WikiProject:朝鲜民主主义人民共和国（论） Portal:朝鮮民主主義人民共和國（论）
355 WikiProject:木工（论） Portal:木工（论）
356 WikiProject:机器人学（论） Portal:机器人学（论）
357 WikiProject:杭州（论） Portal:杭州（论）
358 WikiProject:東南亞（论） Portal:東南亞（论）
359 WikiProject:板球（论）
360 WikiProject:柬埔寨（论）
361 WikiProject:核心本體工程（论）
362 WikiProject:核技术（论） Portal:核技术（论）
363 Portal:桃園（论）
364 WikiProject:桥梁（论）
365 WikiProject:條目質量評級（论）
366 Portal:梵蒂岡（论）
367 WikiProject:棒球（论） Portal:棒球（论）
368 WikiProject:植物（论） Portal:植物（论）
369 WikiProject:概念藝術（论）
370 WikiProject:概率与统计（论） Portal:概率与统计（论）
371 WikiProject:槍械（论）
372 WikiProject:橄榄球（论） Portal:橄榄球（论）
373 WikiProject:欧洲历史（论）
374 WikiProject:歌手和演员（论）
375 WikiProject:歌曲（论）
376 WikiProject:歌舞伎（论）
377 WikiProject:欧洲（论） Portal:歐洲（论）
378 Portal:歐洲新聞動態（论）
379 WikiProject:欧洲联盟（论） Portal:歐洲聯盟（论）
380 WikiProject:武汉（论） Portal:武汉（论）
381 Portal:武漢新聞動態（论）
382 WikiProject:武術（论） Portal:武術（论）
383 Portal:歧视（论）
384 WikiProject:死亡（论） Portal:死亡（论）
385 WikiProject:比利时（论） Portal:比利时（论）
386 Portal:民主進步黨（论）
387 WikiProject:气象（论） Portal:氣象（论）
388 WikiProject:水浒传（论）
389 Portal:汉朝（论）
390 WikiProject:江苏（论） Portal:江苏（论）
391 Portal:江苏新闻动态（论）
392 WikiProject:江西（论） Portal:江西（论）
393 Portal:江西新闻动态（论）
394 WikiProject:池州（论）
395 WikiProject:汽车（论）
396 WikiProject:沈阳（论）
397 WikiProject:沙盒（论）
398 WikiProject:河北（论） Portal:河北（论）
399 Portal:河北新闻动态（论）
400 WikiProject:河南（论） Portal:河南（论）
401 Portal:河南新闻动态（论）
402 WikiProject:河流（论）
403 WikiProject:法国（论） Portal:法国（论）
404 WikiProject:法国市镇（论）
405 WikiProject:法国省份（论）
406 WikiProject:法律（论） Portal:法律（论）
407 Portal:法輪功（论）
408 WikiProject:波兰（论） Portal:波兰（论）
409 WikiProject:泰国（论） Portal:泰國（论）
410 WikiProject:浙江（论） Portal:浙江（论）
411 Portal:浙江新闻动态（论）
412 Portal:海军（论）
413 WikiProject:海南（论） Portal:海南（论）
414 Portal:海南新闻动态（论）
415 WikiProject:海峽兩岸（论）
416 WikiProject:海洋生物（论）
417 Portal:消防（论）
418 Portal:温州（论）
419 WikiProject:湖北（论） Portal:湖北（论）
420 Portal:湖北新闻动态（论）
421 WikiProject:湖南（论） Portal:湖南（论）
422 Portal:湖南新闻动态（论）
423 WikiProject:溫帶氣旋（论） Portal:溫帶氣旋（论）
424 WikiProject:溫泉（论）
425 WikiProject:滁州（论）
426 WikiProject:满族（论）
427 Portal:滨海新区（论）
428 Portal:滨海新区新聞動態（论）
429 WikiProject:漢字文化圈（论） Portal:漢字文化圈（论）
430 WikiProject:漢字文化圈專題佈告板（论）
431 WikiProject:漫画（论）
432 WikiProject:漫画家（论）
433 WikiProject:漳州（论）
434 Portal:澎湖（论）
435 WikiProject:澳大利亞（论） Portal:澳大利亚（论）
436 WikiProject:澳門（论） Portal:澳門（论）
437 WikiProject:澳門巴士（论）
438 WikiProject:澳門文化（论）
439 Portal:澳門新聞動態（论）
440 WikiProject:澳門街道（论）
441 WikiProject:火山（论） Portal:火山（论）
442 WikiProject:火星（论） Portal:火星（论）
443 WikiProject:灭绝（论）
444 Portal:灭绝与濒危物种（论）
445 Portal:災害（论）
446 WikiProject:災害管理（论）
447 WikiProject:乌克兰（论） Portal:烏克蘭（论）
448 Portal:烏茲別克（论）
449 WikiProject:热带气旋（论） Portal:熱帶氣旋（论）
450 Portal:爱沙尼亚（论）
451 Portal:物理化學（论）
452 WikiProject:物理学（论） Portal:物理学（论）
453 WikiProject:特拉華州（论） Portal:特拉華州（论）
454 WikiProject:特摄片（论）
455 Portal:特色內容（论）
456 WikiProject:犯罪和犯罪人物（论）
457 Portal:犹太教（论）
458 Portal:狗（论）
459 WikiProject:獨立國家聯合體（论） Portal:獨立國家聯合體（论）
460 WikiProject:珠海（论） Portal:珠海（论）
461 WikiProject:琉球（论）
462 WikiProject:琉球專題佈告板（论）
463 Portal:琉球群島（论）
464 WikiProject:瑞典（论） Portal:瑞典（论）
465 WikiProject:瑞士（论） Portal:瑞士（论）
466 WikiProject:環境（论） Portal:環境（论）
467 WikiProject:甘肃（论）
468 Portal:甘肃新闻动态（论）
469 Portal:甜點（论）
470 WikiProject:生态（论） Portal:生态（论）
471 WikiProject:生物（论）
472 WikiProject:生物學（论） Portal:生物学（论）
473 Portal:生物技術（论）
474 WikiProject:用戶警告（论）
475 WikiProject:田徑（论）
476 Portal:电信（论）
477 WikiProject:电子游戏（论） Portal:电子游戏（论）
478 Portal:电子音乐（论）
479 WikiProject:电影（论） Portal:电影（论）
480 WikiProject:电脑和信息技术（论）
481 WikiProject:當紅女人（论）
482 WikiProject:病毒（论） Portal:病毒（论）
483 WikiProject:白俄羅斯（论） Portal:白俄羅斯（论）
484 Portal:目录（论）
485 WikiProject:真菌（论） Portal:真菌（论）
486 WikiProject:矿物学（论）
487 Portal:社会（论）
488 WikiProject:社会主义（论） Portal:社会主义（论）
489 WikiProject:社會學（论） Portal:社会学（论）
490 Portal:社會科學（论）
491 Portal:社會運動（论）
492 WikiProject:神社与神宫（论）
493 Portal:神秘博士（论）
494 WikiProject:神經科學（论） Portal:神經科學（论）
495 WikiProject:神話（论） Portal:神話（论）
496 Portal:神道（论）
497 WikiProject:福州（论） Portal:福州（论）
498 WikiProject:福建（论） Portal:福建（论）
499 Portal:福建新闻动态（论）
500 WikiProject:科學（论） Portal:科學（论）
501 Portal:科學新聞（论）
502 WikiProject:科幻（论）
503 WikiProject:科羅拉多州（论） Portal:科羅拉多州（论）
504 Portal:科舉（论）
505 Portal:立陶宛（论）
506 WikiProject:童軍（论） Portal:童軍（论）
507 WikiProject:笔记本电脑（论）
508 Portal:第一次世界大戰（论）
509 Portal:第二次世界大戰（论）
510 Portal:第二次冷戰（论）
511 Portal:算法（论）
512 WikiProject:篮球（论） Portal:籃球（论）
513 WikiProject:粒子（论）
514 Portal:粵劇（论）
515 WikiProject:粵語配音員（论）
516 WikiProject:紋章及旗幟（论） Portal:紋章及旗幟（论）
517 WikiProject:納粹德國（论） Portal:納粹德國（论）
518 Portal:紙幣（论）
519 Portal:索尼（论）
520 WikiProject:組織（论）
521 WikiProject:維基拾遺（论）
522 WikiProject:維基百科幽默（论）
523 WikiProject:維基百科發展（论）
524 WikiProject:維基百科維護（论）
525 WikiProject:网球（论） Portal:網球（论）
526 WikiProject:红楼梦（论） Portal:红楼梦（论）
527 WikiProject:經濟學（论） Portal:经济学（论）
528 Portal:维基日报（论）
529 WikiProject:維基百科（论） Portal:维基百科（论）
530 WikiProject:维基规划（论）
531 WikiProject:维基规划小组（论）
532 WikiProject:羅馬尼亞（论）
533 WikiProject:美国州份（论）
534 WikiProject:美国总统（论） Portal:美国总统（论）
535 WikiProject:美国（论） Portal:美國（论）
536 WikiProject:美國國會（论）
537 Portal:美國新聞動態（论）
538 Portal:美國軍事（论）
539 Portal:義大利（论）
540 WikiProject:羽毛球（论） Portal:羽毛球（论）
541 WikiProject:考古学（论） Portal:考古学（论）
542 WikiProject:职业摔角（论）
543 WikiProject:聯合國（论） Portal:联合国（论）
544 WikiProject:聖經（论）
545 Portal:聯盟90／綠黨（论）
546 WikiProject:職業安全健康（论）
547 Portal:肇庆（论）
548 WikiProject:能源（论） Portal:能源（论）
549 Portal:自由主义（论）
550 Portal:自由軟體（论）
551 WikiProject:臺中（论） Portal:臺中（论）
552 Portal:臺北（论）
553 WikiProject:臺南（论） Portal:臺南（论）
554 WikiProject:臺灣（论） Portal:臺灣（论）
555 WikiProject:臺灣1000（论）
556 WikiProject:臺灣原住民族宗教與神話（论）
557 Portal:臺灣新聞動態（论）
558 WikiProject:臺灣行政區劃（论）
559 WikiProject:臺灣鐵路運輸（论） Portal:臺灣鐵路運輸（论）
560 Portal:舞蹈（论）
561 WikiProject:航天（论） Portal:航天（论）
562 WikiProject:航空（论） Portal:航空（论）
563 WikiProject:船舶（论）
564 WikiProject:色情（论） Portal:色情（论）
565 WikiProject:艺术（论） Portal:艺术（论）
566 WikiProject:节日（论）
567 WikiProject:节肢动物（论） Portal:节肢动物（论）
568 WikiProject:芬蘭（论） Portal:芬兰（论）
569 Portal:苏州（论）
570 WikiProject:苏格兰（论）
571 Portal:苏里南（论）
572 Portal:苗栗（论）
573 WikiProject:英国（论） Portal:英国（论）
574 WikiProject:英國地理（论）
575 Portal:英國新聞動態（论）
576 WikiProject:英格蘭（论）
577 WikiProject:苹果公司（论） Portal:苹果公司（论）
578 WikiProject:药学（论） Portal:药学（论）
579 WikiProject:荷蘭（论） Portal:荷兰（论）
580 WikiProject:荷兰主题讨论（论）
581 WikiProject:荷兰语译音表（论）
582 WikiProject:荷语人名（论）
583 Portal:菲律賓（论）
584 Portal:葡萄酒（论）
585 Portal:蔡英文（论）
586 Portal:藥用植物（论）
587 WikiProject:苏联（论） Portal:蘇聯（论）
588 WikiProject:虚构角色（论）
589 WikiProject:蝴蝶（论）
590 WikiProject:行政區劃（论）
591 Portal:西安（论）
592 WikiProject:西安公交（论）
593 WikiProject:西班牙（论） Portal:西班牙（论）
594 WikiProject:西藏（论）
595 Portal:西藏新闻动态（论）
596 WikiProject:視覺藝術（论）
597 WikiProject:言论自由（论） Portal:言论自由（论）
598 WikiProject:设计（论） Portal:設計（论）
599 Portal:詩歌（论）
600 WikiProject:警察與執法（论） Portal:警察與執法（论）
601 Portal:讣闻（论）
602 Portal:认识论（论）
603 WikiProject:语言（论） Portal:语言（论）
604 WikiProject:语言学（论） Portal:语言学（论）
605 WikiProject:貓（论） Portal:貓（论）
606 Portal:資訊科技（论）
607 WikiProject:贵州（论） Portal:贵州（论）
608 Portal:贵州新闻动态（论）
609 WikiProject:贸易（论）
610 WikiProject:越南（论） Portal:越南（论）
611 WikiProject:足球（论） Portal:足球（论）
612 WikiProject:跆拳道（论）
613 WikiProject:跨媒體製作（论）
614 WikiProject:跨性别（论） Portal:跨性别（论）
615 WikiProject:跨語言維基（论）
616 WikiProject:跨语言链接（论）
617 WikiProject:身心障礙（论） Portal:身心障礙（论）
618 WikiProject:軍事（论） Portal:軍事（论）
619 WikiProject:软件（论） Portal:软件（论）
620 Portal:软件测试（论）
621 WikiProject:農業（论）
622 WikiProject:辽宁（论）
623 Portal:辽宁新闻动态（论）
624 WikiProject:迪士尼（论） Portal:迪士尼（论）
625 WikiProject:选区（论）
626 Portal:道教（论）
627 Portal:遗传学（论）
628 Portal:遵义（论）
629 WikiProject:邮政及集邮（论）
630 WikiProject:醫學（论） Portal:醫學（论）
631 WikiProject:重庆（论） Portal:重庆（论）
632 WikiProject:重庆公共交通（论）
633 Portal:重庆新闻动态（论）
634 Portal:金庸（论）
635 Portal:金門（论）
636 Portal:鐵路（论）
637 WikiProject:鐵道（论）
638 Portal:钓鱼岛（论）
639 WikiProject:钱币学（论） Portal:钱币学（论）
640 WikiProject:错误检查（论）
641 WikiProject:长春（论）
642 Portal:閩南語（论）
643 Portal:阿富汗（论）
644 WikiProject:阿拉伯世界（论） Portal:阿拉伯世界（论）
645 WikiProject:阿拉巴馬州（论） Portal:阿拉巴馬州（论）
646 WikiProject:阿拉斯加州（论） Portal:阿拉斯加州（论）
647 WikiProject:阿根廷（论） Portal:阿根廷（论）
648 WikiProject:阿波羅計畫（论）
649 WikiProject:阿肯色州（论） Portal:阿肯色州（论）
650 WikiProject:陕西（论）
651 Portal:陕西新闻动态（论）
652 WikiProject:隧道（论）
653 Portal:雲林（论）
654 WikiProject:電子學（论） Portal:電子學（论）
655 WikiProject:電腦和資訊科技專題佈告板（论）
656 Portal:電腦程式設計（论）
657 WikiProject:電視（论） Portal:電視（论）
658 Portal:電視劇（论）
659 WikiProject:青岛（论） Portal:青岛（论）
660 Portal:青海新闻动态（论）
661 WikiProject:非洲（论） Portal:非洲（论）
662 Portal:韩国流行音乐（论）
663 WikiProject:音樂（论） Portal:音乐（论）
664 WikiProject:音乐理论（论） Portal:音乐理论（论）
665 WikiProject:音樂劇（论）
666 WikiProject:页面分类（论）
667 WikiProject:颜色（论）
668 WikiProject:食蟲植物（论）
669 WikiProject:飲食（论） Portal:飲食（论）
670 Portal:首頁（论）
671 WikiProject:首页的缺失条目（论）
672 WikiProject:香港（论） Portal:香港（论）
673 WikiProject:香港住宅屋宇及商業物業（论）
674 WikiProject:香港小姐競選（论）
675 Portal:香港小巴路線（论）
676 Portal:香港巴士總站（论）
677 WikiProject:香港巴士路線（论） Portal:香港巴士路線（论）
678 WikiProject:香港政治（论）
679 Portal:香港新聞動態（论）
680 WikiProject:香港行政區劃（论）
681 WikiProject:香港車站（论）
682 WikiProject:香港道路（论）
683 Portal:香港鐵路運輸（论）
684 WikiProject:香港電視（论）
685 WikiProject:马来西亚（论） Portal:马来西亚（论）
686 Portal:體操（论）
687 WikiProject:體育（论）
688 WikiProject:體適能（论）
689 WikiProject:高速鐵路（论）
690 WikiProject:高雄（论） Portal:高雄（论）
691 WikiProject:魚類（论）
692 Portal:鳥取（论）
693 Portal:鸟（论）
694 WikiProject:鸟类（论）
695 WikiProject:黎巴嫩（论）
696 WikiProject:黑龙江（论）
697 Portal:黑龙江新闻动态（论）
但是只有几百个，真的有这么少吗？--𝐹𝑜𝑟 𝐸𝑎𝑐ℎ ... 𝑁𝑒𝑥𝑡 2025年8月3日 (日) 10:35 (UTC)[回复]
Portal可以理解为某个专题预期给读者看到的门面，WikiProject可以理解为给编辑的交流门面。一般Portal是归对应的WikiProject的运营编辑去更新（作为专题的宣传门面），只是有些专题很少关注Portal的手工数据更新部分，甚至WikiProject和Portal的名称不一定相对的（例如WikiProject:ACG对应Portal:动漫（但同名的重定向））。可能需要跟相关仍活跃的专题编辑小组反馈更新问题，怎样做只能看相关专题编辑的想法。更何况有相当一部分专题已经“死掉”了（例如WikiProject:广东，对应Portal:广东）。——Sakamotosan路过围观 | 避免做作，免敬 2025年8月3日 (日) 12:06 (UTC)[回复]
如果統計方式沒錯，那就是這麼多啦。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年8月4日 (一) 05:07 (UTC)[回复]
從上述清單還可以看出，部分主題和專題其實內容重疊。另外也有命名比較類似的，比如WikiProject:鐵道和Project:鐵路，也可視為相同。另外，長期不活躍的專題和主題，真的需要研究去留。整頓看來是必要的了。--owennson（聊天室、獎座櫃） 2025年8月6日 (三) 16:01 (UTC)[回复]
就某些基礎專題及主題而言，重疊是必然。我覺得更需要先考慮合併小規模專題或主題。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年8月8日 (五) 01:29 (UTC)[回复]
我同意合併小規模的專題或主題，看大家（尤其該些主題和專題參與者）的意願了。--owennson（聊天室、獎座櫃） 2025年8月24日 (日) 13:30 (UTC)[回复]
部分认可A2569875君的意见。WP:专题委员会和PJ:主题可能需要引入对新主题和专题的审核机制。--PexEric 2025年8月13日 (三) 07:02 (UTC)[回复]
我認為長期無人維護的專題標示半活躍或不活躍即可，不一定要刪。主題比較需要更新或是維護。
另外，贊成對新主題和專題的審核機制。--Wolfch (留言) 2025年8月15日 (五) 16:24 (UTC)[回复]
對於主題和專題需要更新的項目（尤其新聞動態之類的東西），可以考慮設計一個模板呼籲參與者共同更新。--owennson（聊天室、獎座櫃） 2025年8月16日 (六) 17:27 (UTC)[回复]
谨慎。是不是名字相同？整治与合并不太一样吧。主题是文章，专题是团体（是人群），这怎么合并--Mahengrui1（留言） 2025年8月22日 (五) 17:02 (UTC)[回复]
...我一直都在說整頓，可以研究合併這個建議...從來沒說過必須合併。--owennson（聊天室、獎座櫃） 2025年8月24日 (日) 13:28 (UTC)[回复]
无妨，不是指议事。请问，文章怎么与人群合并--Mahengrui1（留言） 2025年8月26日 (二) 09:54 (UTC)[回复]
除了對新主題的審核機制外，我認為也有必要對現存的主題頁建立存廢標準。典型的問題嚴重的主題包括：
整頓主題頁比整頓專題頁更加迫切，因為專題只是編者交流的中心，主題是實實在在會給讀者看的。因此主題頁應該使用和條目一樣的處理方式——劣質頁面就應該刪除，而不是像項目頁面那樣掛上{{historical}}就完事。--Nebulatria 2025年8月26日 (二) 10:14 (UTC)[回复]
若是如此，可能需要制定主題頁的存廢標準。另外可能需要建立專題-主題一對一的關係，現在居然可以WikiProject:交通和WikiProject:交通運輸並行實在太不合理了。--owennson（聊天室、獎座櫃） 2025年8月30日 (六) 16:37 (UTC)[回复]
如果無其他意見，那麼我認為已經達成了專題需要與主題一對一，合併內容相近的主題，以及對無內容或長期未有更新的主題需進行存廢討論的三點共識。如有異議請儘快提出。--owennson（聊天室、獎座櫃） 2025年9月4日 (四) 17:09 (UTC)[回复]
這樣吧，目前優先建議超過5年以上未有更新的主題頁面將自動進入AFD，內容相近的主題也會在AFD合併，若出現專題與主題不對應的情況，可考慮更名或開設新主題或專題。--owennson（聊天室、獎座櫃） 2025年9月7日 (日) 14:41 (UTC)[回复]
長期未更新的主題掛update就好，如果是一開始就沒有做成實際內容的主題，應該進存廢。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年9月9日 (二) 08:50 (UTC)[回复]
赞成对长期未更新的主题挂 Update模板。但中文维基的Update模板疑似缺少英文维基模板所支持的 updated的参数。建议增加上一次更新时间的选择，这对读者及编者/页面维护者都是有价值的信息。--Zhenqinli（留言） 2025年9月9日 (二) 19:21 (UTC)[回复]
  1. 一般来说，專題面对编者，任务比主题范围更广泛；与主题不对应是正常情况。
  2. 从维护角度而言，建议用有限资源更新尚为活跃的主题；对常年未有更新的主题，重点在标识，不必急于提删或合并。
專題與主題--Zhenqinli（留言） 2025年9月9日 (二) 07:39 (UTC)[回复]
@Zhenqinli：修正留言格式，請檢查縮排是否有誤。1F616EMO（喵留言～回覆請ping～求助？） 2025年9月9日 (二) 08:22 (UTC)[回复]
專題與主題可能不一定是一對一關係；專題因為涉及評級體系，有「大帳篷」的傾向。本人認為主題分類可以比專題細緻。當然，太細導致難以維護，確實也是問題。此外，本人依然認為徹底刪除（相對於停用或合併等管道）不是好解方，也可能導致更長期復興困難。希望在這個基礎上討論解決方案。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年9月9日 (二) 08:47 (UTC)[回复]
這就是AFD的作用了。如果到了AFD仍然沒有人去救主題的話，也基本說明了這個主題不值得救。--owennson（聊天室、獎座櫃） 2025年9月9日 (二) 13:48 (UTC)[回复]
若同時有許多主題出現在AFD裡，想救也不太容易吧--Wolfch (留言) 2025年9月9日 (二) 14:29 (UTC)[回复]
确实，大多数主题的创建或编辑者，或者像@User:Z7504那样被封，或者已不再活跃于中维。过分急于提删的话，缺乏建设性。--Zhenqinli（留言） 2025年9月9日 (二) 14:42 (UTC)[回复]
主題作為面向讀者的內容，其實其存廢完全可以與普通條目同等視之。既然普通條目都有可能因為各種原因而被提刪，那為甚麼只有提刪主題才「沒有建設性」呢？--owennson（聊天室、獎座櫃） 2025年9月9日 (二) 16:04 (UTC)[回复]
个人认为维基所有的资源（主题、普通条目、导航模板等）都是半成品（work in progress），原则上都可以通过编辑更新改善。除非有违反维基方针的特殊情况，限定短期时间盒（timeboxing）否则予以提删的做法，个人以为对于维基百科一般没有建设性。--Zhenqinli（留言） 2025年9月9日 (二) 16:25 (UTC)[回复]
那是你個人認為。而且，條目之類的內容，同樣有要求，比如需要符合GNG等等，被掛了Notability之後30天還沒有人改善，照樣會提刪。我這個限時提刪建議正是參考了Notability的做法。--owennson（聊天室、獎座櫃） 2025年9月9日 (二) 16:48 (UTC)[回复]
为什麼要參考notability的做法？假设「Portal:中国」有100年没更新，这個主题页面违反任何东西了吗？进了存廢也不可能删除。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年9月9日 (二) 18:17 (UTC)[回复]
那不是正好說明維基人自己會作出合適的判斷嗎？--owennson（聊天室、獎座櫃） 2025年9月10日 (三) 03:05 (UTC)[回复]
如果已經明顯沒有可能，或是有其他改進方案，還是堅持要直接提刪，那可能構成POINT。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年9月18日 (四) 02:19 (UTC)[回复]
有改進方案的話早就做了，根本不用拖到要上AFD，就是沒人在乎的主題才需要上去。--owennson（聊天室、獎座櫃） 2025年9月18日 (四) 05:12 (UTC)[回复]
停停停，有什么误解，有些主题是根本不需要手动更新的。专题主题一对一也是不可能的，因为有些专题（和/或工作组）没有能力搭建相应主题。个人看法是主题应作为吸纳新参与者的纽带，因此每个主题需要反映社群的共识，亦即有相应专题体系中的维护组织，这也是为了避免主题页没有实质内容属性。我这样看专题是要比主题更细致，但我也不认为刘君说的没有道理；这反而更加说明主题和专题不能因为维护之便利而合并。［回复的是这条留言，注意辨识。］--PexEric 2025年9月13日 (六) 13:48 (UTC)[回复]
除此之外，也可以考慮將部分專題「降格」為工作組。粗看上面那個清單，似乎就有不少可以取消獨立專題的地位。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年9月15日 (一) 07:57 (UTC)[回复]
部分可以，部分還是建議直接AFD，比如XX新聞動態但最後更新是2012這種。--owennson（聊天室、獎座櫃） 2025年9月16日 (二) 12:44 (UTC)[回复]
个人认为应该首先对中文维基300多个主题做出系统考察和比较，对具体每一个主题尽量用 Template:Portal maintenance status 及Template:Update模板进行标注。对于 “broken=yes, major or serious”/“incomplete=yes”，并长期无人维护的主题，再行提删。--Zhenqinli（留言） 2025年9月16日 (二) 20:38 (UTC)[回复]
若然如此，首先就需要開發出對應的模板。問題是，我們有這樣的模板嗎？--owennson（聊天室、獎座櫃） 2025年9月17日 (三) 05:43 (UTC)[回复]
上述两个模板现在就可以用。有关Portal:戏剧的例子，参见 Special:diff/89174426。 --Zhenqinli（留言） 2025年9月17日 (三) 08:21 (UTC) 👍1[回复]
而且，就算掛上了模板，也不代表問題解決了。我個人還是建議制定一個期限，如果期限前還沒有人進行改進的話，仍需進行AFD處理。--owennson（聊天室、獎座櫃） 2025年9月17日 (三) 08:41 (UTC)[回复]
您不妨以Portal:鳥取、Portal:戏剧等具体主题为例，提出细化的整顿或提删步骤、程序。--Zhenqinli（留言） 2025年9月17日 (三) 14:26 (UTC)[回复]
正常條目的話，掛上update或是wikify等模板後，可能十年都不更新。這其實同樣也需要避免（題外話了），我的建議是參考Notability模式，掛模板後限制一定時間，比如30天，如果30天內仍然沒有人進行改善，就提上AFD。--owennson（聊天室、獎座櫃） 2025年9月17日 (三) 15:38 (UTC)[回复]
我的感觉是，如果没有人对于主题做包括挂模板等在内的具体的维护、修改工作，泛泛而谈地讨论宏观方针，意义不是很大。所以希望看到有人能就Portal:鳥取、Portal:戏剧等有明显问题的主题，推动、走完维修或提删的周期，在实践当中吸收社群的反馈。--Zhenqinli（留言） 2025年9月17日 (三) 16:00 (UTC)[回复]
要直接做也是可以，不過基本上是在罵聲中優化，我個人是可免則免。但如果還是沒有人在乎，那相信也不會有人罵我，那我就可以開始推進了。--owennson（聊天室、獎座櫃） 2025年9月17日 (三) 18:32 (UTC)[回复]
另外，有跨語言連結者亦可儘量保留。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年9月25日 (四) 22:32 (UTC)[回复]
也許我可以整理出一些有問題的主題和專題，然後變成一個計劃，讓大家來參與。--owennson（聊天室、獎座櫃） 2025年10月1日 (三) 18:46 (UTC)[回复]
同意。不負責任講個笑話，按照往例這問題肯定十幾年前就有人想過甚至弄出一個工作小組然後沒幾個月就死了（x —— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月2日 (四) 12:13 (UTC)[回复]
我簡單地初步整理了一下，放在這裡。歡迎繼續補充。--owennson（聊天室、獎座櫃） 2025年10月2日 (四) 15:52 (UTC)[回复]

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

赖清德「團结国家十讲」条目的合併悬案

本主題或以下段落文字，在討論結束後應存檔至Talk:團結國家十講。

这並不是一個非常複杂的问题，但是拖了一個月都没有解决，被迫来到互助客栈请求合作。

涉及三個页面：

按照建立顺序，应當合併到页面「1A」，但是「1A」被删，且常用名称是「2」。另外三個页面的内容质量都堪憂，需要删掉很多东西，但是各有一些东西是有用的。

为什麼我不在条目讨论页提出？待会被删了怎麼办。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年8月10日 (日) 07:16 (UTC)[回复]

通知「2B」页面存廢讨论參与者：@August.C、Ericliu1912、Huangwith、Jlstone0330、Manchiu、MilkyDefer、MykolaHK、Ojvolleyball、RainBeforeSun、Saimmx、Sanmosa、Shizhao、Shwangtianyuan、Sinsyuan、Skyjjjjjjzzh、SunAfterRain、Talimu0518、Uranus1781、Yeh david、~2025-25141-4、夢我阿須羅鳳凰、巴波、愛喝奶茶、日期20220626、自由雨日 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年8月10日 (日) 07:17 (UTC)[回复]
通知「3」页面贡献者：@TimWu007、UU、Huangwith、Xiluo233、Pathfinbird、Saimmx。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年8月10日 (日) 07:20 (UTC)[回复]
通知「2B」页面贡献者：@A2093064-bot、Shizhao、Manchiu、自由雨日、Sakurase、夢我阿須羅鳳凰、SingBow、Coolapk28、Saimmx、~2025-28200-0、~2025-29278-1、~2025-30609-1 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年8月10日 (日) 07:20 (UTC)[回复]
通知「1A」页面存廢讨论參与者：@Jackyming、Jlstone0330、Shizhao、SunAfterRain ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年8月10日 (日) 07:22 (UTC)[回复]
通知「1B」页面创建者：@~2025-30663-3。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年8月10日 (日) 07:23 (UTC)[回复]
已经向以下讨论页發送通知：《WikiProject talk:臺灣》、《Talk:團結國家十講》、《Talk:「團結國家十講」》、《Draft talk:团结十讲》、《Wikipedia talk:換個燈泡需要多少維基百科人？》、《Wikipedia talk:合并请求》 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年8月10日 (日) 07:35 (UTC)[回复]
徵求意见：政治、政府与法律；维基百科格式与命名；维基专题与协作。掛上公告栏。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年8月10日 (日) 07:37 (UTC)[回复]
啊呀，本人只是那一篇草稿的审核者，那一篇草稿在被拒绝后似就已无再更进，建议是可以直接以重复页面为由速删？--Pathfinbird🦅 2025年8月10日 (日) 08:51 (UTC)[回复]
我可能需要看到被刪除前的1A的內容才能作進一步判斷。Sanmosa DC23 2025年8月10日 (日) 07:20 (UTC)[回复]
@Sanmosa：被刪除前的1A的內容。--Cmsth11126a02 (留言) 國民黨的正確名稱是大陸國民黨！ 2025年8月31日 (日) 07:11 (UTC)[回复]
併入「大罷免」或「賴清德」，並適當標註重新導向性質，避免再遭提刪。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年8月10日 (日) 10:03 (UTC)[回复]
应達收錄标準。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年8月10日 (日) 10:07 (UTC)[回复]
我本人只希望「團結國家十講」這個主題實體能通過收錄標準，以獨立條目存在，不合併至其他條目。內容無所謂，反正哪個版本都要苦幹一番。另外我不確定自由雨日提到的著作權問題如何、也不希望再找人換燈泡了所以不做；但如果著作權是無法解決的大問題的話，可能要ping一下Wcam諮詢。--Saimmx（留言） 2025年8月10日 (日) 15:27 (UTC)[回复]
达收录标准。1A的原内容我看过，里面有一些有关争议的内容，可以丰富现条目的内容。现条目需要精简演说内容。不过著作权问题还是一个大坑，尤其是你百在这方面很看重的…--Skyjjjjjjzzh（留言） 2025年8月11日 (一) 01:23 (UTC)[回复]
條目本身是可以保留的，但是因其品質極差，需要整個重寫。--August 2025年8月11日 (一) 15:13 (UTC)[回复]
「2B」的存廢讨论结果为「允许併入」。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年8月24日 (日) 16:17 (UTC)[回复]
1A已经恢復到Draft:「團結國家十講」。现在应该怎麼合併为妥？@Sanmosa。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年9月8日 (一) 16:34 (UTC)[回复]
@Sanmosa？ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年9月16日 (二) 08:52 (UTC)[回复]
@Sanmosa？ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年9月23日 (二) 18:57 (UTC)[回复]
好像有人把內容合併得差不多了。目前的演說內容，也許可以參考「Draft:团结十讲」合併之。--Saimmx（留言） 2025年9月16日 (二) 08:56 (UTC)[回复]
那就申请让管理员先把1A的歷史先合併到2B？［还是说该反过来合併？还是说合併歷史无所谓哪個合併哪個？］ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年9月16日 (二) 08:58 (UTC)[回复]
我覺得都可以。我對這種過度細節的東西，已經不太清楚了。--Saimmx（留言） 2025年9月16日 (二) 09:10 (UTC)[回复]
如果Saimmx所言不錯的話，我感覺我沒有需要進一步補充意見的地方了。頁面歷史合併可能是必要的。Sanmosa 新朝雅政 2025年9月23日 (二) 23:55 (UTC)[回复]
請問是我的哪個發言？
如果是獨立條目的發言，早就是了。
如果是合併完成的發言，魔琴不同意我的解讀。似乎是沒有報告存廢结果進度以及署名問題。--Saimmx（留言） 2025年9月24日 (三) 07:23 (UTC)[回复]
存废讨论的结果是「允许并入」，不是「允许并回来」。而并入（其他地方）的理由是应该并入较早创建的页面。为什么要这样做，我不知道，所以这里要再通知一次提出此问题的@自由雨日。我记得@Sanmosa似乎在「大罢免」条目的存废中也提过类似意见，想请问一下这个条目合并历史是不是就行了？不需要再把内容扔进「1A」了？如果是的话，可能得提DRV复核改变存废结论？条目合并和著作权处理这方面我确实不在行，如果我明白怎么做我自己就处理了（我有suppresredirect权限，不过合并历史还是得找管管）。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年9月24日 (三) 10:15 (UTC)[回复]
應該併入較早建立的頁面是不更動頁面歷史的情況下的處理，如果有頁面歷史合併的操作的話，那只要保證相關頁面歷史紀錄完整就可以了。Sanmosa 新朝雅政 2025年9月24日 (三) 12:04 (UTC)[回复]
目前看來團結國家十講雖然品質有問題（我倒不意外這種過程），但已經穩定下來。請問魔琴是否需要繼續徵求意見？還是可以先關閉？--Saimmx（留言） 2025年9月19日 (五) 20:45 (UTC)[回复]
存廢结果仍未执行，「1A」和「3」这两份草稿併入「2B」的内容也没有合理署名。通知提出合併问题的@自由雨日。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年9月23日 (二) 18:56 (UTC)[回复]
以目前的進度而言是以「2B」為主。「內容」章節部分主要是「3」，不過也有「1A」的部分內容。我想應該是合併完成了。接著「爭議」章節，似乎也已經把「1A」和「3」这两份草稿內容併入「2B」了，所以實質上來說，我認為應該已經執行存廢結果的共識了。
目前還剩下打磨內容章節的文筆，以及把合併資訊確實記錄好。前者等徵求意見結束後再做也不遲。但後者是我不熟悉的地方，歷史紀錄也太過複雜。我想我需要進一步的操作說明。--Saimmx（留言） 2025年9月24日 (三) 07:48 (UTC)[回复]
現在情況怎麼樣了？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月2日 (四) 12:15 (UTC)[回复]
大部分的內容放在了「2B」。我覺得這樣應該能結案，但魔琴反對這個說法，認為歷史紀錄尚未正確合併。而歷史紀錄出於著作權問題必須解決。但是著作權問題已經超出我能理解的範圍了，所以我不確定。--Saimmx（留言） 2025年10月2日 (四) 15:44 (UTC)[回复]
我认为可以将3（“团结十讲”）移动到条目空间、作为{{合併重定向}}保留。重定向前的最后一个版本可以删到只剩“演說內容”以示@Saimmx在9月16日对2B的剪贴移动(Special:Diff/89162861/89163123)用了这些内容；或者直接改成重定向。虽然它有效的修订版本早于2B的创建时间，但硬要合并历史的话会很莫名其妙（除非2B的早期版本文字已经在9月16日完全被取代，那样可以考虑扔掉2B的那些版本）。
1A的标题是带引号的「團結國家十講」，应该无法作为重定向存在。可能需要采用en:WP:PV描述的方法，即把它丢到讨论页的子页面，如Talk:團結國家十講/1A。硬要说的话，2B的“爭議”一节是1A对应章节的原作者@Yeh david在8月18日自行剪切移动的（可对比1A版本88226754和2B版本88788963），“內容”一节是Saimmx在9月24号剪贴了一些(Special:Diff/89252652/89266444)。
如果各位没有异议，那就移动页面并在2B的讨论页用{{Copied}}标记这些内容来源即可结案。@魔琴、Sanmosa、自由雨日：--Srapoj（留言） 2025年11月2日 (日) 14:22 (UTC)[回复]
没意见，除了「團結國家十講」也是能开重定向的，衹要用G8把「1B」删了就好。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月2日 (日) 14:49 (UTC)[回复]
啊，如果是“棱镜”监听项目这种好像还合理，但为什么要给整个标题被引号括起的情况建立重定向？并且您在{{引号重定向}}写的“引导标题至使用不同引号的条目”按我理解是给页面标题本身含有引号时建立直、弯引号间重定向用的（类似{{简繁重定向}}）。--Srapoj（留言） 2025年11月2日 (日) 15:07 (UTC)[回复]

名人暱稱收錄及刪除準則

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:可供查證、Wikipedia talk:生者傳記、Wikipedia talk:格式手册/信息框。

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

本人最近於西莉拉可·鄺中加入了暱稱「叉燒姐」，Tisscherry指出「WP:F未有可靠來源下請勿放人」，後來本人按照Tisscherry的指引下，加入暱稱所需要的新聞媒體報導來源文章，其後他又指因為來源「非藝人本身發出的聲明」，然後直接將暱稱連同來源刪除。

本人因對此類名人條目上暱稱的收錄準則不太了解，於是在Tisscherry用戶討論頁向他請教，不過他可能因事繁忙未有繼續回覆，所以現改到互助客棧向其他資深編輯請教。以下是他的回覆：

暱稱一向就是粉絲產物，這牽涉到兩個問題，（1）請見Wikipedia talk:可供查證#提請社群確認是否以ONUS提案中的註解1.4取代現行做法，即便有看似可靠的來源，但這是「別人取的」，明顯是節目效果，我不認為因此就要加入，條目主到下個節目被新增了「別人取的」暱稱，那舊的「別人取的」呢？因此（2）非官方或本人發布的暱稱，不應加入。

本人最大的疑問在於「非官方或本人發布的暱稱，不應加入」此一原則是否維基百科社群經討論後已設立的方針？如果是既定方針，有沒有資深維基人能夠提供相關編輯名人條目的教學或指引？

而且當本人隨意地瀏覽了一個偶像團體中成員的條目，發現大部份暱稱均有問題，例如沒有來源（如姜濤、楊樂文），只有註解沒有來源（如陳卓賢、呂爵安），即使有來源，亦只是新聞來源而非來自本人聲明（如陳瑞輝、盧瀚霆）。如果「非官方或本人發布的暱稱，不應加入」是屬於維基百科既定指引，本人為名人加入暱稱時卻被指不妥而被刪除尚且能夠理解，但不少例子令人感覺似乎此準則未有於其他條目上執行。

結果本人完全無法判斷Tisscherry提及的收錄準則是維基百科既定方針還是他的個人意見，因為如果此準則屬實，似乎有大量有相同問題的條目需要進一步修改。如果其他維基人認為加入此等暱稱並無不妥，本人希望可以於西莉拉可·鄺條目中加入了暱稱「叉燒姐」，因為此暱稱實在是廣泛地被香港媒體所報導，不加入實在有點於理不合，謝謝。--heitung221（留言） 2025年9月19日 (五) 15:12 (UTC)[回复]

感謝閣下提出討論。我倒覺得趁現在現在確立藝人條目不放非官方暱稱是好事，您舉的例子叉燒姐明顯就是節目效果，我再舉個更偏差的例子好了，今天你到一個新的地方第一天，那裡的人看到你，長官說你長得很像菠蘿麵包，我們大家以後就用菠蘿麵包這個綽號叫你了。WP:NOTNEWS，我也說明過了，下次再換個暱稱，理所當然出現您說的一日廣泛報導，記者必須寫稿啊這是工作，這時候就又要繼續收錄了？不能是停留觀察，這有沒有可能是熱度過了根本沒有收錄的價值內容？另外最近新聞很多的泰勒·斯威夫特，這位藝人的暱稱我想應該更可觀，但一個都沒有，再看WP:闖紅燈，可不可以是「別人違規但我不跟著做，我應該要自己判斷這是不是具有百科價值的內容」。--提斯切里（留言） 2025年9月20日 (六) 00:26 (UTC)[回复]
(！)意見：我認為其一是此稱呼是否廣泛被不同媒體使用：搜尋後我認為可以。其二是時間是否長久：從其開始為人所知的2022年至今年均仍可在媒體上看到叉燒姐一稱，我也認為可以。其三，搜尋後得知此綽號是最初請她幕前演出的胡慧沖在節目中所起的，兩人合作的時間不短，她有沒有在節目中親自認可我不知道，但能合理推測她應在節目中知道此綽號。縱觀以上，實非長官說過一次你長得很像菠蘿麵包可比。此外，䁥稱必須要本人直接或間接認同，常理來說未必，需要討論，例如一些以犯罪聞名的人物，「小丑殺手」约翰·韦恩·盖西、「雨夜屠夫」林過雲，都是在當地家傳戶曉的綽號，顯然都是大眾起的，還有連環殺手裡的其他列舉，這些負面綽號得到本人親自公開認可的機會很微，但不論維基和現實，也沒見過誰走出來說有問題。--Factrecordor（留言） 2025年9月20日 (六) 01:27 (UTC)[回复]
我認為應該就此討論收錄標準，不要雙標。--提斯切里（留言） 2025年9月20日 (六) 01:33 (UTC)[回复]
感觉媒体报道艺人昵称的叔叔还不如政治人物以及相关争议的别称多，例如哭包祥、赖皮寮和张大妈。----大筒木博人是杀掉了七代目火影的人。 2025年9月20日 (六) 01:32 (UTC)[回复]
暱稱以及粉絲名，我認為是屬於沒有百科價值的內容，偏向瑣碎以及粉絲感興趣的項目，應該明定除非條目主本人公告認可，否則不應收錄。--提斯切里（留言） 2025年9月20日 (六) 01:37 (UTC)[回复]
還有像IShowSpeed，本身稱簡Speed，在中國內地通稱甲亢哥，不是出自其本人或其來自的地區，但在華人地區就是對他標誌性的稱呼。--Factrecordor（留言） 2025年9月20日 (六) 01:41 (UTC)[回复]
在中國內地暱稱甲亢哥，這沒有地域中心？廣泛來源？那這樣是否應該加上臺灣對他的暱稱呢？--提斯切里（留言） 2025年9月20日 (六) 01:45 (UTC)[回复]
臺灣如起另一稱呼當然可以，但好像只用英文原名或引用中國內地暱稱甲亢哥[11][12][13][14][15][16]，香港也沒另起名稱。至於中國內地的廣泛性，你不清楚就自己了解，別浪費別人時間了。--Factrecordor（留言） 2025年9月20日 (六) 02:08 (UTC)[回复]
毕竟按照那边的反中情绪可能不会主动了解中国大陆的相关事物的。----大筒木博人是杀掉了七代目火影的人。 2025年9月20日 (六) 02:51 (UTC)[回复]
我認為臺灣人對中國大陸事物不認識是人之常情，畢竟每人所關注的事物也不盡相同，但也正因如此，將被廣泛使用的暱稱收錄入維基百科就更顯得有價值，百科的本質就是讓不認識某事物的人可以透過百科認識該事物，本人雖不是活躍編輯，但也自認是非常依賴維基百科來獲取不認識的資訊，相信將被廣泛使用的暱稱收錄可令大眾獲取更多有關某名人的資訊。甚至就以上例子而言，更極端來説可能有人會知道「甲亢哥」是誰而不知道「IShowSpeed」是他，這情況下就更顯得收錄暱稱的重要性。
相信Tisscherry最擔心可能是有人會將過於小眾的暱稱放上維基百科，本人亦能理解，但這一問題就要靠不同的編輯努力了，如您到本人提供的例子中逐個暱稱查一查，可能也能夠發現一些較小眾的暱稱現時已被收錄且沒有來源，這一點本人也只能為各位活躍的編輯加油。--heitung221（留言） 2025年9月20日 (六) 03:49 (UTC)[回复]
( ✓ )同意「叉燒姐」不屬小眾。姜濤只有姜b一稱，街知巷聞，盧瀚霆的教主也是，AL亦是常見的英文名縮寫，其他舉出的MIRROR成員暱稱可能真屬小眾。亦( ✓ )同意暱稱不一定需要來自本人聲明，這個要求是不設實際。--Underconstruction00（留言） 2025年9月20日 (六) 04:53 (UTC)[回复]
叉燒姐是這幾天才來加的，此前沒有。許多演藝人員沒有寫出暱稱也不會影響閱讀。--提斯切里（留言） 2025年9月20日 (六) 05:02 (UTC)[回复]
不成理由，百科有很多舊事物的條目都是後人突然新建的，有很多已有的舊事物條目都是後人突然擴充的，縱使沒有任何更新資訊。按你這樣想，難道全部需要質疑沒價值?--Underconstruction00（留言） 2025年9月20日 (六) 05:15 (UTC)[回复]
暱稱有價值，有時暱稱象徵一些個人特質或代表性的事情，越廣泛使用的暱稱反映該些象徵為人所關注的程度。有時如今朝Factrecordor說暱稱會用為代稱，讀者可能會在其他平台或媒體遇上不提該人原名，只用暱稱代指的情況，越廣泛使用的暱稱越可能發生這情況，若讀者不知暱稱就會理解不到在說甚麼，所以讀者在認識一個人物時也需要認識非小眾的暱稱。--Underconstruction00（留言） 2025年9月20日 (六) 05:34 (UTC)[回复]
我認為最重要是廣泛性，生者認可方面只要沒本人明確提出反對即可，政治人物要是介意那些稱呼自會反駁。還有一點可參考，是否常用作代稱（代替原名，不列出原名），如甲亢哥這方面就很強。叉燒姐固然差很遠，但在部分新聞標題上也有所體現[17][18][19]。--Factrecordor（留言） 2025年9月20日 (六) 01:55 (UTC)[回复]
余承东中也有本人回应，没有明确反对，我觉得没问题。--内存溢出的猫（留言） 2025年9月20日 (六) 07:39 (UTC)[回复]
本人完全無意WP:闖紅燈，提出例子的原意是，因閣下希望為名人暱稱確立收錄準則，所以為您提供現時不符合您所提出的準則的條目作參考例子而供討論。--heitung221（留言） 2025年9月20日 (六) 03:59 (UTC)[回复]
沒聽說Taylor Swift有甚麼特別綽號。一個明星有多知名和他暱稱多不多，有沒有代表的暱稱，從來都沒有正比關係。--Underconstruction00（留言） 2025年9月20日 (六) 04:21 (UTC)[回复]
最初是不是節目效果也不重要，藝人的成名作或代表作成為長久象徵，產生出長久暱稱，比比皆是，只要迴響達至上面說的廣泛和非一時就行。--Underconstruction00（留言） 2025年9月20日 (六) 05:06 (UTC)[回复]
那麼為甚麼假定這位藝人在退出演藝圈之前，都會使用這個暱稱，他上其他節目的自我介紹有說請大家叫我叉燒姐？--提斯切里（留言） 2025年9月20日 (六) 05:11 (UTC)[回复]
我或本討論串其他人，都沒有說藝人在退出演藝圈之前都會使用的暱稱才值得收錄，只要時間不短而且非小眾就可以，好像除了你，暫時沒有人反對。必須本人聲明過也是你自己在強調。如果擔心數量太多，大可引入資訊框代表作的最多五個原則。還有，暱稱不限於藝人，所有人物都可以有暱稱或稱號，如上，林過雲一定沒說過請大家叫我「雨夜屠夫」，IShowSpeed也應該沒說過請大家叫我「甲亢哥」，但WIKI不可以寫下「雨夜屠夫」和「甲亢哥」就是荒唐之極。--Underconstruction00（留言） 2025年9月20日 (六) 06:29 (UTC)[回复]
我一開始的回應大家似乎都視若無睹。現在是有使用者認為我雙標，但條目太多了要靠大家互相幫忙，而現實狀況就是，有些演藝人員根本不放暱稱，有些卻有的沒的粉絲自己取的都收錄，剛好現在也在討論ONUS，既然以往對於暱稱收錄標準沒有標準，那是不是趁現在一起討論清楚，如果能夠規範清楚也是功德一件。我不在乎叉燒姐是不是只有他能用，還是往後又有叉燒姐藝人出現需要消歧義，我的重點是看各位要不要順勢討論出個規範，如果要參與討論的各位重點只有叉燒姐，僅只小規模討論一開始發起討論的條目主題，那發起位置根本錯誤應該移回條目內的。--提斯切里（留言） 2025年9月20日 (六) 05:50 (UTC)[回复]
你們都有各自的道理，溝通好就可以。不算雙標，你或其他巡查維基人不是不理其他，只是剛好留意到某個，暫未留意到其他，或未有空判斷。這討論也不是只談叉燒姐，有對通用判斷方式的意見，就是我自己也對叉燒姐以外的其他舉例發表了意見。--Underconstruction00（留言） 2025年9月20日 (六) 06:38 (UTC)[回复]
@Heitung221@Tisscherry，她曾自己解釋叉燒姐的由來[20]。--Underconstruction00（留言） 2025年9月20日 (六) 07:00 (UTC)[回复]
本人亦曾以此影片作為來源，不過被指「回退到由Tisscherry（討論）做出的修訂版本89182438：YT不是可靠來源。」--heitung221（留言） 2025年9月20日 (六) 09:16 (UTC)[回复]
YT不是可靠來源是錯誤說法。YT作為一個平台，本身並不能定論是不是可靠來源，是不是可靠來源要看影片的性質與發佈者的性質。例如屬於可靠來源之媒體官方YT頻道所發佈之新聞影片，那就和其出版的報刊無異。現在想要的是傳主的「聲明」（一手來源），那段片有電視頻道J2標記，應是電視節目的節錄，除非是AI偽造（因非官方發佈），否則正常來說就是可証明事實的一手來源，由於是電視節目內容，應可找出來查證。但相信大家都明白，片段是偽造的可能性很微，且如前文所說，就算沒有傳主的直接聲明，她也沒什麼可能否定此稱呼，顯然胡慧沖經常在節目這樣當面介紹她，尤如這段胡慧沖自己頻道的影片[21]，繼續死纏爛打鑽空子根本沒意思。原來有連結跳往電視台官方頻道發佈的相同片段[22]，那就連偽造都能排除了。--Factrecordor（留言） 2025年9月20日 (六) 12:08 (UTC)[回复]
藉此另外問一個問題，官方有時僅將一些重要事實發表在YouTube或X而已，而在此情況下我們可以使用那些來源來撰寫條目嗎？（包括活動以及新專輯發行等等）--Louischen88888（留言） 2025年9月21日 (日) 04:53 (UTC)[回复]
@Louischen88888這些屬於一手來源或自行出版物，見WP:PRIMARY、WP:ABOUTSELF，不完全禁止使用但應謹慎使用，嚴格來說條目中這樣的內容佔比應保持在小量，如果大量收錄只有官方來源的內容，很易會被認為是愛好者內容。--Factrecordor（留言） 2025年9月22日 (一) 13:41 (UTC)[回复]
而且應盡可能使用文字版本，因文字來源可以在備份網站進行備份，影片通常不行。萬一刪除了，就算你自行備份了影片再上載，也會像上面那樣被質疑不可靠。--Factrecordor（留言） 2025年9月22日 (一) 13:45 (UTC)[回复]
他個人都同意並且使用甚至解釋了這個綽號，那應該就可以使用了--Louischen88888（留言） 2025年9月21日 (日) 13:53 (UTC)[回复]
( π )题外话：Wiktionary 收录昵称较为宽松，如果能写进百科，那么一般都符合 Wiktionary 的标准，欢迎来贡献。
查看维基词典中的词条「en:Category:zh:Nicknames for individuals」。
—内存溢出的猫（留言） 2025年9月20日 (六) 07:44 (UTC)[回复]
題外話：為何條目名稱不叫鄺玲玲？她的ig帳戶、微博帳戶，以至是中文新聞媒體和她代言的中文廣告都一面倒使用鄺玲玲，注意這裡是中文維基百科。--Clithering（MMXXV） 2025年9月20日 (六) 17:32 (UTC)[回复]
大体上人物的别称的规范是存在的，可以参见已有的WP:BLPBALANCE（虽然列在生者传记方针下，不过沿用于一切人物想来也不碍事，毕竟其要求算是完善的）：人物的别称除需可靠来源支撑外，亦需证明此别称并非一时收录标准。，亦即WP:V和NT:TEMP，也就是说需要可靠来源对该别称作出有效介绍。私以为除此以外，不需要另定新规则，除非该别称有不符合如NPOV或BLP等要求的情况。作为偶然会处理一些演艺人员的条目的用户，我同意需要留意昵称栏的填写——但是用上述的规则也就可以了；自然，在这种情况下，对于“有效介绍”，要抓紧底线，避免“顺带提及”当“有效介绍”用的情况出现。--银色雪莉（留言） 2025年9月20日 (六) 19:39 (UTC)[回复]
感謝提醒都忘記了，這麼說來我曾在哪個條目引過這條，但被回這不是規範演藝人員。--提斯切里（留言） 2025年9月20日 (六) 23:22 (UTC)[回复]
西莉拉可·鄺是從泰國出道的，Google登錄搜尋結果第一條都是「西莉拉可·鄺」，用哪個搜兩個名字都會出現不影響辨識，建立之初名從主人我認為合理。--提斯切里（留言） 2025年9月20日 (六) 23:35 (UTC)[回复]
我們中文維基百科的條目名本就對google有頗大影響。--Factrecordor（留言） 2025年9月21日 (日) 02:50 (UTC)[回复]
王菲初出道時叫王靖雯，莫非條目現在也應命名作王靖雯？我覺得命名應參照名從主人和常用原則，而不是取決於她在哪裡出道。--Clithering（MMXXV） 2025年9月21日 (日) 06:36 (UTC)[回复]
@银色雪莉@Tisscherry，「有效介紹」需要商榷，這個概念來自Wikipedia:收錄標準，針對的是整個條目的收錄標準，而非條目中的個別內容。WP:BLPBALANCE沒提及「有效介紹」，有沒有其他相應指引提及這點？而且，就算需要此要求，怎樣才是「有效介紹」，怎樣才是「順帶提及」，對於整個條目主題，與對於個別一項內容，明顯不應該是同一標準。正如上文有提到一個人有多少暱稱，未必與其名氣成正比關係，一個暱稱的被介紹程度，也未必和其代表性成正比關係，介紹程度的最主要因素應是讀者是否易於自行理解，例如「叉燒姐」就頗需要介紹，姜B就不需怎樣介紹。--Factrecordor（留言） 2025年9月21日 (日) 03:25 (UTC)[回复]
@Factrecordor：WP:BLPBALANCE指出“...亦需证明此别称并非一时收录标准”，而NT:TEMP则指出“符合收录标准的资格不是一时的：条目的主题一旦在可靠来源中有效介绍，便能满足通用收录标准之要求，不需要新闻来源对其持续报道。”在我看来，这应该是文理逻辑上的可关联内容。诚然条目主题（在本件中，即是传主）与其一项别称因其对象有异而“不应该是同一标准”，但我想指出的是，这个“不应该同一”应该是在“有效介绍的程度”上来谈——不是说一定要像字词分析那样，而是起码简介别名的出处、来源或成因——而不是说在“有效介绍”和“顺带提及”的区别上而言，否则，我们就会苦于应对泛滥的“人名（绰号）今天到中环出席活动”型来源。正儿八经的绰号别名，有媒体介绍其来由，并不是多意外的事情，叉烧姐或者姜B，都能找得到。--银色雪莉（留言） 2025年9月22日 (一) 06:12 (UTC)[回复]
@大筒木博人@内存溢出的猫甚至有一整個條目收錄生者不可能認可的稱呼：對習近平的負面稱呼。--Factrecordor（留言） 2025年9月21日 (日) 03:07 (UTC)[回复]
此外針對這個條目是否要提出存廢討論--Louischen88888（留言） 2025年9月21日 (日) 13:57 (UTC)[回复]
綜合上述建議，本人認為於條目西莉拉可·鄺加入暱稱「叉燒姐[23][24]」並無不妥，如沒有進一步反對，本人將會執行此項變更。--heitung221（留言） 2025年9月21日 (日) 05:53 (UTC)[回复]
@Heitung221沒有討論出結論啊？--提斯切里（留言） 2025年9月21日 (日) 11:52 (UTC)[回复]
是否有慣例要過了多少日沒有反對再算有結論？現在亦請教其他資深維基人，此討論如何繼續進行才可能得出結論？還是逐一再次發表意見再舉行投票才可以加入「叉燒姐」三字？可能本人尚未能判斷此討論要到那個地步才算有結論，但現已有不同人就各項細節提出了不同觀點，如閣下對此等觀點不認同，請進一步逐一回覆。--heitung221（留言） 2025年9月21日 (日) 12:47 (UTC)[回复]
關注度不能是一時的，認為頂多於條目內說明，如同上方舉例甲亢哥或是Taylor Swift，也僅只於條目內做連續文字介紹，這加到infobox沒完沒了。況且再說到，在你們來加之前，沒有這個綽號也甚麼影響。--提斯切里（留言） 2025年9月21日 (日) 12:54 (UTC)[回复]
就您此回應，本人會理解為您認為在西莉拉可·鄺加入「叉燒姐」並無不妥，您只是認為該內容不應加進infobox中「暱稱」的一項資訊中，而應該要如IShowSpeed條目中以內文（在中國大陸網民稱他「甲亢哥」）方式介紹。是否正確？如本人理解有誤，請再解釋。--heitung221（留言） 2025年9月21日 (日) 13:14 (UTC)[回复]
Tisscherry閣下以此理由回退「回退到由~2025-65160-0（討論）做出的修訂版本89198552：沒有關閉討論啊」，是否表示要等到此討論串於10天左右再沒有人發言，而且此討論要被認定為得出共識可以有正當理由加入「叉燒姐」三字？還是要經過那一種既定程序才可以獲得編輯權？--heitung221（留言） 2025年9月21日 (日) 13:00 (UTC)[回复]
沒有共識的內容不要強加為有共識，很簡單一時收錄標準的內容反對寫入，維基百科不是反應粉絲興趣的網站，我提甲亢哥的例子真的很抱歉讓你誤會了我甚至覺得根本不能放，外國人為甚麼要寫入中國大陸的暱稱。但那不是我要關心的。這個討論現在有兩個方向，再度重申討論沒有共識前請不要自行解釋，也不要幫我曲解我的意思，我從來沒有推敲他人意見的意思，請停止這樣做。--提斯切里（留言） 2025年9月21日 (日) 13:36 (UTC)[回复]
(－)反对&(！)抗议，我第一個留言已明確認為非一時，以向來對「一時」的判斷，持續三年已不能算「一時」，從上面的討論可見，你的意見只是你個人的意見，我們不可能因為你自己一直不同意而不達成共識，而且就算沒共識，誰說沒共識的做法就是不能寫，存廢討論所有沒共識都是暫時保留。完全(＋)支持恢復叉燒姐內容。--Factrecordor（留言） 2025年9月21日 (日) 14:08 (UTC)[回复]
維基百科的使用者本來就可以決定條目內要寫甚麼不寫甚麼，這條目存在多久了，都沒寫這個暱稱過，為甚麼現在一定非加不可？有沒有這個暱稱從來都沒有差別啊。--提斯切里（留言） 2025年9月21日 (日) 14:12 (UTC)[回复]
已有人反駁過「不成理由，百科有很多舊事物的條目都是後人突然新建的，有很多已有的舊事物條目都是後人突然擴充的，縱使沒有任何更新資訊。按你這樣想，難道全部需要質疑沒價值?」重複也沒用。--Factrecordor（留言） 2025年9月21日 (日) 14:16 (UTC)[回复]
這是牽涉到生者傳記的內容，現在是要無視所有規則嗎？上面銀色雪莉寫的你們就是要無視了是吧？為甚麼不考慮這東西若真的存在這麼久了，這幾天才有人來想方設法要加入？這不奇怪？--提斯切里（留言） 2025年9月21日 (日) 14:20 (UTC)[回复]
現在在討論的ONUS也是在這個範疇內，雖然討論中，要考量的是，即使有來源，我們也可以選擇不寫進百科裡。--提斯切里（留言） 2025年9月21日 (日) 14:23 (UTC)[回复]
(－)強烈反对你這段邏輯不明而且並非事實的言論。你說我或其他用戶「無視所有規則」顯然非事實，本討論中提出過的「規則」，我們都有作出合理回應，又或者像「一時」那樣，在明確的條文未被提出前我就分析過了，heitung221君在下文對回應的脈絡已梳理了一部分，何來無視之說？現時所見「叉燒姐」的來源能滿足各項規則，除了暱稱是否屬於垃圾粉絲向這種挺見仁見智的論題上，滿足不了你個人對愛好者內容那種近乎你認為是垃圾就是垃圾的無敵見解，但至少暫時沒人附和你。
「為甚麼不考慮這東西若真的存在這麼久了，這幾天才有人來想方設法要加入？」也是你自己想出來的一種額外的判斷方式，從沒見過指引提出應該這樣判斷內容的去留。當中的可能性有多種，要知道編寫百科不是世界的中心，世上願意去編寫百科的人數其實也很小眾，就算喜歡製造所謂垃圾的那種人，出現在百科的也只是冰山一角而已。除了非常熱門的話題，少數編者的個人偏好或疏忽絕對足以長期影響個別條目的內容。正如我們拯救那些烏煙瘴氣的條目時，清理之餘經常會發現有一些具可靠來源的內容沒寫，如果因此而質疑這些內容的價值，不如維基百科就別寫了。而且，今天下午U君已發現「叉燒姐」以前是有被寫過的。我們維基人應該盡量以來源說話，「若真的存在這麼久了」大可以用來源去驗證：
  • 2022年鄺玲玲在加入香港電視節目《冲遊泰國》系列，在節目中獲得「叉燒姐」這稱呼，該季節目開播之初傳媒有對她介紹，當中有提及「叉燒姐」[25]，也有有介紹稱呼的由來[26][27]
  • 2022年至2023年關於節目內容的報導很多，多有提及「叉燒姐」，這種來源就不贅了。也有介紹過稱呼由來的來源[28]。
  • 2024年似乎沒有參與《冲遊泰國》，後因為主演泰劇《我們的秘密》而爆紅，聲價十倍，但「叉燒姐」之名未有隨之而被遺忘，來源仍有提及[29]，亦不乏有解釋由來的來源[30][31][32][33]
  • 2025年的報導及專題介紹中，亦多有提到「叉燒姐」並解釋由來[34][35][36][37][38][39][40][41]
請@銀色雪莉君評評理，這能算一時嗎？能算缺乏有效介紹嗎？能算突然出現的小眾玩意嗎？
請@Tisscherry君注意自己的言論，如繼續在此討論中不實描述其他用戶，不排除向管理員舉報。--Factrecordor（留言） 2025年9月22日 (一) 11:48 (UTC)[回复]
@Factrecordor 想向您請教，出現此類爭論時，無論本人等待至哪一個時間點加入內容，亦只會再次被回退版本，按一般慣例是否有措施可以防止相關問題發生，例如是否有慣例，當討論到某個階段後，由一位用戶等級較高的資深維基人（甚至管理員）代為編輯，甚至保護條目？--heitung221（留言） 2025年9月21日 (日) 14:33 (UTC)[回复]
管理員僅執行共識。相關人物的各語言版本，英文維基沒有暱稱欄位，泰文維基只有他的小名，粵語維基不好說。--提斯切里（留言） 2025年9月21日 (日) 14:49 (UTC)[回复]
其實我也不熟悉程序。主要條文有Wikipedia:解決爭議#請求其他編者協助調解內容爭端、Wikipedia:共识#提案討論及公示時間。
Wikipedia:共识有云：「共識不強求一致同意。理想情況下，共識不會存在任何反對意見；但假如無法實現這點，共識應採納多數人的意見，並和重要少數的意見作出適當妥協。」「我們的目標是提出有說服力的理由來作出決定，而不是根據公開支持的比重來作出決定。」「在與不肯讓步的編者共事時，可以考慮請求管理員幫助」（Wikipedia:管理员布告板/编辑争议吧？）--Factrecordor（留言） 2025年9月21日 (日) 15:47 (UTC)[回复]
原來根據指引，維基百科鼓勵Wikipedia:勇于更新页面，而根據維基百科:編輯戰所述，回退超過一定次數（WP:3RR）就構成編輯戰，可以轉到Wikipedia:管理员布告板/编辑争议，不過原則上不鼓勵編輯戰。而根據Wikipedia:共識，「互助客棧及徵求意見中的提案僅在7日內無新留言時或已討論達30日後，方可在已取得共識的前提下公示。」，但對未有共識的情況下卻未有似乎訂明時限，而編輯戰限定的時限是24小時內回退多於3次，現在亦可算是未達此標準。不過根據Wikipedia:沉默與共識，如果討論陷入停滯時，似乎又鼓勵假定取得共識而應該勇於更新頁面。
本人數小時前發現有多項觀點已有24小時未有回覆，看似可以被假定已達成共識，當然現在討論繼續時，則應該被視為未有共識。不過問題在於在未有達成明顯共識時，條目應該保持哪一種狀態？根據Wikipedia:修改、回退、討論循環，「只要不是破壞，任何編輯都是維基百科最歡迎的行為，請不要對是否要動手編輯猶豫。同樣的，若你在頁面的討論頁留言建議如何修改，過段時間未獲回應，那麼你就直接修改吧！有時其他編者可能很忙或是沒在看這個頁面，你的修改可以引起他們的注意，不然也至少是單純的改善了條目，兩者都帶來了好的結果。」，所以在此討論進行期間，就算未有達成明顯的共識，各位應該要在不同時間點上（如24小時內沒有反對意見），根據討論內容結果更新頁面，如發現再有新意見，則可以再加入或回退內容，相信不會被認為是發起編輯戰。--heitung221（留言） 2025年9月21日 (日) 16:47 (UTC)[回复]
@Heitung221沒有回應僅代表沒有任何志工注意到或想理會你的文字，就跟條目太長、瑣碎及冗餘相同，過多的資訊會消耗讀者的耐心。亦即願意讀你的完整文字的人相當罕見，至多只看一部份。如你這段我僅看完12%左右。
  • 你的處理很容易被當成POINT。這次屬於(＊)提醒，下次類似POINT的狀況會升級至警告。如以共識強度，無意見可以當成無反對無支持的極弱共識產生。極弱共識在編輯戰情境虛弱到可以當成沒有任何意義。"覆蓋共識需要強度更高的共識"。
--Rastinition（留言） 2025年9月21日 (日) 23:08 (UTC)[回复]
上面談到這樣，都能說成無反對無支持，你真厲害。--Underconstruction00（留言） 2025年9月22日 (一) 01:57 (UTC)[回复]
因为上面那位不是中文圈人士。----大筒木博人是杀掉了七代目火影的人。 2025年9月22日 (一) 02:10 (UTC)[回复]
本人「多項觀點未有回覆」的意思是指上述被回退內容有其他用戶表示支持加回條目後，於一定時間內再未有反對該支持意見的回覆，而非無意見下的「無反對無支持的極弱共識」。--heitung221（留言） 2025年9月22日 (一) 03:47 (UTC)[回复]
參與討論的人x位，實際表達意見的x位，更多的是混合議題討論，參與討論的使用者不能在不中立的狀態下得出對自己有利的結論。--提斯切里（留言） 2025年9月22日 (一) 04:00 (UTC)[回复]
( π )题外话 在「叉燒姐」一暱稱被加入之前，該條目infobox的暱稱資訊為「Lingling (หลิงหลิง)、00、00K、玲玲、鄺總、CEO、Jeje」，且存在了相當長的時間。--heitung221（留言） 2025年9月21日 (日) 14:47 (UTC)[回复]
都從粵語維基來的啊。為甚麼要把其他語言版本不對的內容搬過來？好的不看？--提斯切里（留言） 2025年9月21日 (日) 14:50 (UTC)[回复]
因篇幅較長，現嘗試概括上述討論。
就加入暱稱一事，@銀色雪莉表示目前已有足夠規範「不需要另定新規則，除非該別稱有不符合如NPOV或BLP等要求的情況。」，@Tisscherry表示「關注度不能是一時的，認為頂多於條目內說明」，@Factrecordor表示「反對，我第一個留言已明確認為非一時，以向來對「一時」的判斷，持續三年已不能算「一時」」。Tisscherry反駁理由為「這條目存在多久了，都沒寫這個暱稱過，為甚麼現在一定非加不可？有沒有這個暱稱從來都沒有差別啊。」，並認為「牽涉到生者傳記的內容」，要根據討論決定是否寫進百科，並指出「這東西若真的存在這麼久了，這幾天才有人來想方設法要加入？這不奇怪？」。Factrecordor及@Underconstruction00認為不能以以前內容不存在為反對加入某內容的理由。--heitung221（留言） 2025年9月22日 (一) 04:37 (UTC)[回复]
其實幾矛盾，一方面說不要一時，一方面質疑為甚麼以前沒有，太早有不就未知是否一時? 2024年9月1日的版本導言就有暱稱「叉燒姐」，只不過寫的人沒有加進資訊框而已。--Underconstruction00（留言） 2025年9月22日 (一) 07:03 (UTC)[回复]

程序討論

有鑒於上面的討論被屢次被侷限範圍，且目前現況確實是沒有一致標準，影響所有生者傳記的條目，故本人提起於Wikipedia:生者傳記#批评和赞扬新增內容，以求格式統一，茲提出草案如下：

現行條文
人物的別稱除需可靠來源支撐外，亦需證明此別稱並非一時收錄標準。
提議條文
別名不是暱稱，見例徐熙媛的大S。人物的别称與暱稱除需可靠来源支撑外，亦需证明此稱號并非一时收录标准，这意味着在摒除短时效新闻来源的影响的前提下，此稱號应得到可靠來源对该别称（的意义、成因或渊源等）作出有效介绍。暱稱不是必須，收錄的暱稱若有爭議，請適時發起討論是否需要保留，時間推移之下不符合收錄標準的暱稱須隨時調整移除。數量別超過5個。版本4--提斯切里（留言） 2025年10月1日 (三) 11:51 (UTC)[回复]
--提斯切里（留言） 2025年9月22日 (一) 12:12 (UTC)[回复]
(－)反对，如上文所說，必然存在大量沒有傳主官方發布但具代表性的別稱，草擬人一直無視這些意見。我在上文的意見是符合現有標準的別稱，按理是廣泛使用及並非一時，只要我們沒發現傳主否定過此別稱，就沒問題。當然，正如任何負面內容都是需要維基人依靠常識去分辨的，對於明顯帶有負面意味的別稱，我不反對更謹慎些，然而Wikipedia:生者傳記#批评和赞扬的精神也不是傳主說了算，別稱一欄又如何影響當中所指的比重合理與否及注重條目結構？不明所以。相反地，如推行傳主說了算，豈非會褒揚過重？
另，鄺玲玲曾親自在節目解釋其別稱，見電視台官方YT頻道發佈的節錄[42]，草案通過與否都無助解決最初爭議。--Factrecordor（留言） 2025年9月22日 (一) 12:25 (UTC)[回复]
我說過不要雙標。必然存在大量沒有傳主官方發布但具代表性的別稱，是啊，有來源有效介紹，允許另開章節使用連續文字介紹，這樣也可以避免infobox擁擠不堪沒有標準，訂出標準就可以寫了，也能夠造福所有的生者傳記條目。這樣的爭議往後會在出現，為甚麼不現在趁勢解決。--提斯切里（留言） 2025年9月22日 (一) 13:58 (UTC)[回复]
節目來源您真的會拿來在條目內引用？典優條目也這麼作？--提斯切里（留言） 2025年9月22日 (一) 14:00 (UTC)[回复]
INFOBOX比正文更嚴格，或說資訊應更精選，這個方向確有道理。不反對設標準加強篩選或限制數量，但以官方發佈作為篩選方式，我始終深感疑慮。--Factrecordor（留言） 2025年9月22日 (一) 14:22 (UTC)[回复]
官方設定的考量是在偶像團體方面，通常官方會於初始公布團員暱稱以及粉絲名，許多演藝人員也都有這樣的處理，在出道的時候會用暱稱拉進距離製造親切感。以鄺玲玲的例子看，Lingling這個小名是打從出道就有的，使用時間最長，疑慮較小，放在infobox我認為沒有爭議，而其他別名存在時間不一，在找尋得到有多方來源之下適合另開章節敘述，例如演出劇中的CP暱稱；至於叉燒姐（我找到的來源還有叉燒妹），我認為應該是於別名章節介紹，不過也有認定是官方確認的第2（或3）別名的意見，有爭議的狀況下就可以開啟討論是否放人infobox或是連續文字介紹。說到這裡，或許應該要確立，infobox的暱稱可以放到幾個，我的意見是維持1個，也就是跟著演藝人員出道的，數量越多就會造成如代表作的爭議，只能放5個的限制下，經常看到各方人馬在換作品，回到暱稱就是叉燒姐和Lingling要放哪個，若確立以出道時的暱稱為主，我想爭議會到最小。稍微離題enwiki似乎是不在infobox放人暱稱欄位，我沒去深入探討，若有使用者知道還請幫忙補充。--提斯切里（留言） 2025年9月22日 (一) 14:50 (UTC)[回复]
如果設數量限制，以官方發布優先，那還算合理。但這個修訂不是針對某群體的傳記格式手冊，偶像團體成員只是藝人之中的一部分，藝人只是所有人物中的一部分，更何況也不一定所有偶像團體都會官方發布成員暱稱。因此仍難以接受官方發布作為必然標準。--Factrecordor（留言） 2025年9月23日 (二) 06:18 (UTC)[回复]
@Factrecordor@Tisscherry僅針對代表作，在處理代表作要怎麼被定義前，討論數量沒有意義，最簡單的作法是來源定義那是代表作。
  • 如果代表作的定義並未被明確定義清楚，討論數量沒有意義，當被陳列的並非真正的代表作是基於WP:OR產生的一堆文字及名詞時，那只是為了陳列而被陳列的無意義資訊。
  • 而如果代表作過多時，或者極端的狀態下所有作品都是代表作時，取捨的標準是什麼，這仍是定義問題。部分過往的討論結論是以#作品取代，至少以最極端的狀態而言，不需要再處理取捨問題，非極端狀態，僅是在作品很多時，這樣處理同樣可以迴避定義收錄標準的問題。
你們處理完這些問題再討論數量更適當。至少相對比較知道如何面對or或v等基於方針要求的理據。如果問我的意見，我會這樣陳述，基於我的經驗，曾發現將來源可以佐證或依常識可以認可的代表作（如出道作品）移除，逕行替換成最新作品。排除最新的作品是否等同代表作這個問題外，被移除的項目若確實是來源可斷言的代表作，對應操作所陳列的資訊正當性不存在。
(～)補充我不參與定義的處理，如果要確認我的意見，我僅陳述我只支持明確用來源斷言及佐證是代表作的資訊或者用#作品替代。出道作是例外，但出道作也必須要由來源斷言，不能綜合多個來源推斷。不能排除是否有更早期的作品，而那個作品沒有被收錄在條目中而誤將非出道作認為是出道作的狀態。--Rastinition（留言） 2025年10月8日 (三) 11:31 (UTC)[回复]
如遇爭議，較客觀的標準是按得獎紀錄評估，其次是參考對傳主事業進行總結的文獻如何羅列，不認為應考慮新舊，但這點可能會自然地反映在來源上。--Factrecordor（留言） 2025年10月8日 (三) 12:28 (UTC)[回复]
晚来了（抱歉，我再多线程也没那么多2333），如果不介意，请诸位容我讲一点“简单”看法（主要是因为上面太长doge问题是我讲话可能也很长23333）：我感觉这个话题里太混合了（上面已经有用户指出过），请允许我尝试分离来说明，并请诸位就各点指正：
1、（忽略讨论程序问题的）关于是否收录昵称这个问题：我之前列出的规范是WP:BLPBALANCE中的“人物的别称除需可靠来源支撑外，亦需证明此别称并非一时收录标准”，我认为这为人物的别称（或昵称）提供了相当清晰的规范（就我个人的看法而言）：鉴于“可靠来源支撑”WP:V和“并非一时收录标准”NT:TEMP两点均可对应到具体的规范，我个人认为这意味着当可靠来源对该昵称作出有效介绍（在我而言，这里的有效介绍具体是指，对该昵称的成因或者意义作出必要程度的介绍）时，这个昵称可以被收录。另外，我个人认为上述讨论中对于“一时”的理解似乎存在一些误会，请允许我概括引用NT:TEMP说明我的观点：1、一旦在可靠来源中有效介绍，便能满足通用收录标准之要求，不需要新闻来源对其持续报道，亦即我们并不要求持续的报道（基于此，我个人也认为并不需要多久多久以后还存在报道），只需要来源作出足够有效的介绍，便能突破“一时”的藩篱；2、对于“短时效的突发新闻内容”和“对宣告、体育的日常新闻”的评价也是基于它们不符合“有效介绍”的要求而作出的。综上，如果来源作出有效介绍，那么“一时”的问题其实就已经解决。所以我想，还是应该抓住有效介绍这个点。尽管如此，个人基于WP:DUE，对于流传时间不长的一些绰号，即使有有效介绍，也对于把它们列出不是太感冒。
2、关于昵称应该放在什么位置的问题：我对这个问题还没有什么很明确的想法，只有几个小点：（1）英维的infobox里头把nickname这个参数整合在了other names里头，参数说明也只说“Other notable names for the person”，这与Template:艺人的说法在我看来是类似的；（2）基于前，我对是否要限定说“除了传主官方发布之外，一律不放入Infobox内的昵称一栏”目前还比较犹豫，但我会认为如果官方明确拒绝的昵称，即便有可靠介绍，也不要写在infobox（但可以写在内文并作必要介绍），这是基于BLP的考虑（对死者我也认为如此较好），毕竟昵称一栏你没法说明什么，实际上等于给人就安下这顶帽子了，写在内文则还有说明介绍，也許可以做到较为中立——但如果不符合NPOV和BLP等要求，那就不用審理，好走不送；（3）我建议不要鼓励（或者说不要示明）“可以另创章节”——那在我看来会造成一个很XXXXX的章节（不是要讲脏话，而是负面感一下涌上心头无言以表），很可能臃肿，很可能成为Fanpov集散地。
3、关于讨论程序问题：暂时没想法，我对这部分不熟悉。
以上，再次请各位指正，如果各位能分开各点给在下以教诲则更为感激。--银色雪莉（留言） 2025年9月22日 (一) 15:29 (UTC)[回复]
另外實在有太多條目使用了一堆不知名的暱稱，不管最後這裡的討論結果為何，是否應當盡力審視各個人物條目，並刪除奇怪的暱稱。--Louischen88888（留言） 2025年9月23日 (二) 02:35 (UTC)[回复]
為免之後沒時間跟進變化，先記下自己的立場：
  • 維持現有的標準：不反對。
  • 資訊框收緊標準，資訊框以外維持現有的標準：不反對。
  • 整個條目一致收緊標準：很關注，請提醒我回來。
  • 正文是否應設暱稱章節：是否都接受，沒意見。
  • 對於如何收緊資訊框的標準：接受設數量限制。反對以「官方發布」作為必然條件，但不反對作為優先條件。
--Factrecordor（留言） 2025年9月23日 (二) 06:32 (UTC)[回复]
不過暱稱很難證明是否有長期標準，這樣會不會造成收錄標準太高，官方或本人自己有解釋或者是介紹的暱稱應該就可以。--Louischen88888（留言） 2025年9月26日 (五) 09:55 (UTC)[回复]
回應銀色雪莉，關於另開章節您的疑慮我也是有想過，但目前的狀況是，大多數的使用者已經把維基百科當作粉絲記事本，我想是可以明確寫下來的，而且這些內容得要是經過篩選的，前提以大方針WP:NOT以及WP:BLP為主，不符合的內容隨時可以清除，明確寫下來了，對於後續維護清理的志工也有更清晰的指引依據。回應Factrecordor，在考慮infobox不過度收錄下，我認為限制標準在跟著傳主發出的第一個暱稱為主是爭議較小的做法，媒體給的或是其他人給的，多數屬於強迫接受類型，放在infobox很像是給傳主貼標籤，我更多時候是這樣看待所謂暱稱的，這裡舉個例子，先前有林家謙的粉絲希望我能加上林伯的暱稱，無論如何我是不想寫的，即使有來源（很多媒體這麼寫他），條目主本人也經常處於自嘲狀態，但這個暱稱無論有沒有寫進維基百科裡，對於認識條目主是一點影響也沒有的。回應Louischen88888，您可以具體表達對於此指引修訂的方向想法，怎麼訂定才不會變向成為粉絲堆疊內容的地方。—-提斯切里（留言） 2025年9月23日 (二) 07:02 (UTC)[回复]
有关于明说可以建立（我完全明白这只是一种建议）“章节”这事儿还是请允许我保留——就像我总不喜欢“轶事”这种章节那样，在我看来，“轶事”这种章节就是条目排版状况混乱的一个缩影，变成了堆砌信息；而如果对于维护清理的用户而言，其实只要咬紧有效介绍等要求就可以了。
上方Factrecordor阁下提议infobox的昵称设数量限制我表示赞成，但我完全理解您为什么提议infobox只收官方认可的昵称（其实我个人赞成这种逻辑；但是我又总想到如今这里谈的是人物别称，不仅仅是偶像这种容易fanpov的条目，在一些历史人物等情况下，由他人提出的别称可能有相当重要的地位，乃至于没理由不让用户在infobox列出，像是李贺的“诗鬼”——自然，它不是昵称，但现在这个方针本来指的是“别称”，范围就会广些）。
您提的这个林家谦的例子让我想到了几个问题：（1）我赞成像这种昵称对于认识传主毫无价值，因为在我看来它就真的是一个很没有什么含义的说法（我个人观点），但是像姜B这种也跟林伯的结构上看上去没什么差别（在我看来没有什么特定含义）、然后好像也不是他自己取的（请原谅我对于他着实不熟悉）？如果说存在一个逻辑让“林伯”不要收录在infobox（甚至不收录），那么这个逻辑我想就会适用于姜B，而我又很难想象因为某个逻辑而拒绝在姜涛条目中收录这个昵称；（2）我在想，如果说“条目主本人也经常处于自嘲状态”的话，那么可能存在意见会认为“这跟官方公布也没差什么，ta自己都说”，我认为这样的类比固然是不准确的，但我发现如果这样的逻辑被提出时，似乎很难把这个类比逻辑干净地否定掉，因此我无法确定会不会这个争议的情况其实并未因限定官方公布而有所减少。我想，我们也许要继续斟酌一下应该如何表述。--银色雪莉（留言） 2025年9月23日 (二) 17:15 (UTC)[回复]
因為我晃來晃去，看到銀色雪莉的留言才想到（）依據大家的意見暫時置換為版本2。
首先我要道歉，我沒有先確認人物模板的欄位，以致於我今天才確認{{藝人}}模板包含「暱稱」與「別名」兩個欄位，別名似乎爭議較小，立刻想到的是大S，於是看一下徐熙媛，別名是放大S無誤，暱稱放了2個，然後再看en:Barbie Hsu，因為條目命名緣故，「Other names」包含本名。於是若用這個邏輯下去寫，那麼藝人出道時的暱稱放到別名，而暱稱欄位若規範在2個以內，於是回到鄺玲玲，Lingling應該放在別名欄位，那麼大家心心念念的叉燒姐似乎就能放上暱稱，還有一個位置就能給戲劇的CP暱稱。
若是從這個方向下去探討，那麼另開章節的規劃，就可以不規範，而且是能夠限制不能收集。
不過在此之前，可能要先確認一下我們人物模板有多少款式，是不是都包含「暱稱」與「別名」兩個欄位。--提斯切里（留言） 2025年9月23日 (二) 18:14 (UTC)[回复]
另外@自由雨日，若有空也有興趣能否給點意見，謝謝。--提斯切里（留言） 2025年9月23日 (二) 18:18 (UTC)[回复]
@银色雪莉@Tisscherry應先了解Template:藝人的描述，全盤檢討，暱稱是指「經常出現在新聞媒體上的暱稱，多個暱稱時請用「、」做分隔，最多別超過五個。」原來確是和代表作一樣限制5個，我早提出過可同樣限制5個。別名是指「曾使用或在外地發展時所使用的藝名。」--Underconstruction00（留言） 2025年9月26日 (五) 05:15 (UTC)[回复]
藝人也會有不是藝名也不算暱稱的別名(別稱)，現在的架構不理想。--Underconstruction00（留言） 2025年9月26日 (五) 05:20 (UTC)[回复]
(－)反对定到上限5個，Infobox不應該放入這麼多粉絲向內容，若要訂數量勉強接受2個，別稱只能1個。--提斯切里（留言） 2025年9月26日 (五) 06:35 (UTC)[回复]
別稱(不指藝名)是「詩鬼」那種，也未必只有一個，像林沖 (藝人)的大盜歌王、鑽石歌王，基本上是兩個來由相同，普及性差不多的稱呼。--Underconstruction00（留言） 2025年9月26日 (五) 06:43 (UTC)[回复]
@银色雪莉我不認為林伯與姜B相類。B看上去就可能是傾向對可愛人物表達親暱的通用用法，但伯不是這種用字，林伯不是林家謙的諧音，一個年青的人被稱為伯一定有特別原因或有舊事相關。但林伯似乎也不像叉燒姐那樣輕易找到第三方「有效介紹」，姜B也較易搜到[43]。--Underconstruction00（留言） 2025年9月26日 (五) 07:01 (UTC)[回复]
在下此前指出过，我们不是作字词分析，在我看来只要能具体介绍称呼的意义或成因，其实都可以视为有效介绍，可以假定收录。但是这些有效介绍的类型，确实是不同的。在这一点上，姜B和林伯处在同等的逻辑水平，它们不是复合人名结构的传统组成部分（如字、号）、不具备增进了解传主客观事实程度的功能（尤其是一些已经由严肃知识图谱确认的外号，如“诗鬼”），只是或大部分地归属于“亲昵的称呼”（注意这里“亲昵的”未必表明褒贬，而是一种对形成路径的描述）——尽管阁下会认为“林伯”是“一个年青的人被称为伯一定有特别原因或有旧事相关”，但就我阅读所得而言，我认为这名称中“亲昵的称呼”占了绝大比重。我从不反对基于可靠来源有效介绍下收录这种“亲昵的称呼”，事实上，如果阁下再读读在下的一些陋言，会发现我提出的这个逻辑，正是意图指出“很难在不收录林伯的情况下收录姜B”（这是在不考虑有效介绍等因素的情况下），因而进一步推出“可靠来源有效介绍应是核心的假定收录的依据”。--银色雪莉（留言） 2025年9月26日 (五) 07:52 (UTC)[回复]
他自己在演唱會解釋了因為早年被朋友笑稱神態像老人家[44]--Underconstruction00（留言） 2025年9月26日 (五) 09:43 (UTC)[回复]
我完全认同这种解释，但我倾向于不以此为收录依据——可靠来源的原因。--银色雪莉（留言） 2025年9月26日 (五) 17:37 (UTC)[回复]
我认为这里的讨论过于繁杂了。先明确具备可靠来源有效介绍的这一点会较好。“时间推移”等表述可能需要调整，现在的表述会有歧义，让人以为别称可以由“符合收录标准”变为“不符合”。“原本没有放入...不用强加介绍”实际上会造成“不能加”的叙述空间。--银色雪莉（留言） 2025年9月26日 (五) 07:22 (UTC)[回复]
在下想先总结一下可能比较容易汇集共识的部分，我提议将数量等形式问题跟收录标准问题分离开来各自讨论，我想惟有这样才能继续有效讨论。以下是我就此的个人看法：

人物的别称除需可靠来源支撑外，亦需证明此别称并非一时收录标准，这意味着在摒除短时效新闻来源的影响的前提下，此别称应得到相关来源对该别称（的意义、成因或渊源等）作出有效介绍。

声明：我完全支持就各处收录别名的数量等问题继续作出讨论，同时我感到现在的讨论以艺人这一特定圈层为核心而试图修改普适性的规定，这会引发观点的不平衡，在此谨请各位考虑我的此种疑虑是否妥当。--银色雪莉（留言） 2025年9月26日 (五) 08:07 (UTC)[回复]
別名和暱稱的區別有時候是不是不好呈現，例如江蕙二姐，周杰倫周董等等。
另外很多條目，尤其是偶像的條目，關於暱稱的部分時常過多，且沒有任何來源，也要一起進行整理改善。--Louischen88888（留言） 2025年9月26日 (五) 08:32 (UTC)[回复]
另外我的看法是偶像的粉絲都喜歡幫自己的偶像取一些特別的外號，但通常都不太會有相應的來源，反而有來源的一些，甚至是收錄在百科中的粉絲都不常用僅講述事實，沒有想要把沒有來源的暱稱都收錄的意思。--Louischen88888（留言） 2025年9月26日 (五) 09:21 (UTC)[回复]
叉燒姐是別名還是暱稱也很疑惑。重點早已不是討論有沒有來源，現在是想限制到就算有多個第三方來源都未必能放進資訊框。--Underconstruction00（留言） 2025年9月26日 (五) 09:45 (UTC)[回复]
應收窄為對Template:藝人的共識?
我覺得首先可以要求技術人員將別稱及其他藝名分為兩個欄位，不論討論結果如何，都是應分開的。--Underconstruction00（留言） 2025年9月26日 (五) 09:12 (UTC)[回复]
我認為暱稱對於了解傳主本人有限，但篇幅不大，不會嚴重影響到整個條目，因此可以訂定最多5個的收錄原則，但當然都要有來源。
另外有來源是公定的標準，不管最終的結果為何都應該要做到這個，但現在的人物暱稱部分基本都不會有來源，能否補足仍要看有無編輯者願意投入心力，我個人暫時沒有餘力。
另外問一下在代表作的部分，如果是影視歌三棲的藝人要怎麼處理，221嗎？--Louischen88888（留言） 2025年9月26日 (五) 09:42 (UTC)[回复]
(？)疑問，還是回到老問題，認為一個名會帶來標籤（應該是指負面），縱使藝人親自解釋了這個稱呼的由來，期間沒有呼籲人別這樣叫他，但也推斷藝人是被逼接受，並將此推斷凌駕於廣泛性（且非一時）之上，這是中立還是不中立（Wikipedia:中立的观点），這是符合Wikipedia:生者傳記要求的謹慎還是不必要地過度隱「惡」揚「善」？？？
我本來以為藝人對別人所起的䁥稱顯得接受即可，但看來「官方公布」是頗狹義。而且這種狹義的官方䁥稱，相信只有很少數的藝人才會有，我實在沒法認同，只能再說句(－)反对。--Factrecordor（留言） 2025年9月26日 (五) 13:10 (UTC)[回复]
他親自解釋並且敘述喜歡，或者是他親自說他想要的暱稱呢--Louischen88888（留言） 2025年9月26日 (五) 13:39 (UTC)[回复]
回覆自己說的話，有點主觀且，難度太高沒有參考性質--Louischen88888（留言） 2025年9月26日 (五) 13:44 (UTC)[回复]
若果有媒體報導來源，那要不要放完全看參與編輯的使用者了。我覺得要討論就是，先不要管之前吵甚麼，看要寫入方針的文字怎麼修，規範定好了，也方便大家做事。--提斯切里（留言） 2025年9月26日 (五) 13:50 (UTC)[回复]
為甚麼又繞回來，感覺上真的很像立法院開會耶，事情好像有進展了又回頭辯這個。請移步看一下徐熙媛，大S的Infobox我覺得很能作為範例，上面也有提到江蕙「二姐」雖然我不太知道她但聽到二姐我都有印象。「反對的話那就別界定了，所有能喊的暱稱通通放進infobox裡吧，我想每個藝人都會被自己的粉絲稱小可愛，我不介意所有的藝人都放入小可愛。」這是我心裡的OS，討論事情不要老是究責啦二分法，現在如銀色雪莉意見要緊咬有來源的標準，暱稱數量設定的問題就一併討論，我的意見2個最理想，粉絲要去編輯戰就到時候再處理，我上面說了有別稱和暱稱兩個欄位，麻煩請看清楚再反對謝謝。--提斯切里（留言） 2025年9月26日 (五) 13:39 (UTC)[回复]
我個人認為如果要訂定具有收錄來源等等的標準的話，難度會很高，也許許多的別暱稱都無法收錄，但說實話暱稱對於了解傳主並沒有到非常重要，所以沒有或許不會造成太大的問題。--Louischen88888（留言） 2025年9月26日 (五) 13:48 (UTC)[回复]
我的想法跟您差不多，沒有暱稱完全無礙於認識這個人，但現實上這是很粉絲向的東西，除非{{藝人}}模板廢掉這兩欄，這是阻止不了人寫的，既然現在沒有規範那就定好，沒有來源就是全刪，有來源只能收幾個。這裡再提一個韋禮安，我看到他的別名有注解，這蠻有意思的。--提斯切里（留言） 2025年9月26日 (五) 14:04 (UTC)[回复]
暱稱的可靠標準，真的會很困難，因為暱稱或許不到很重要，有可能藝人本人在自己的影片或者是節目或者是直播提及而已。
另外訂定2個只是徒增大家困擾，因為現在絕大多數的暱稱都是兩個以上，更改會很麻煩，而且這樣子會突然變成很多條目都不符合收錄的標準。--Louischen88888（留言） 2025年9月27日 (六) 00:56 (UTC)[回复]
剛剛嘗試隨意在條目中加入暱稱，觸發以下警告

警告：系統檢測到閣下或許正試圖變動人物傳記條目的「暱稱」相關內容。按照維基百科的方針要求，凡加入維基百科的內容均需要提供可靠來源，而對於生者傳記類的條目，來源要求則更加嚴格。任何在不提供可靠來源的情況下，增改條目既有人物暱稱的行為，均違反維基百科規定，無論所添加的暱稱是否真實存在。此類編輯將有可能隨時被其他編輯者移除；在不提供可靠來源的情況下反覆添加這類內容者，將有可能被管理員封禁。

條目中暱稱一欄一般最多只需要列舉三五個即可，大量羅列平時不甚使用且無來源佐證的暱稱也屬於違反規定的舉動。請為閣下的變動提供參考資料。
這一警告是由系統自動提示的，故有時會誤報。如果閣下確信自己的編輯沒有問題，請再次點擊「發布更改」按鈕，頁面即可遞交。
也就是說其實已經有既有規定可以參考，我們是不是都忽略了。--Louischen88888（留言） 2025年9月27日 (六) 04:32 (UTC)[回复]
先說這裡討論的人，從沒有人反對這些規定。數量限制之前大家都沒怎注意，但也沒抗拒，反倒是自己把數量限制想出來。情況一直是發起人認為不夠嚴格，要更嚴格，受到其他人質疑，若你認為這些規定已經足夠，就不需任何修訂。
你可能發現在很多人物頁面都有不符規定的情況，在維基百科當然是很常見的，任何人都可以編輯，有多少人清楚了解規定?--Underconstruction00（留言） 2025年9月27日 (六) 06:10 (UTC)[回复]
考量到Louischen88888所提的，過濾器是僅有想添加的使用者才會觸發及閱讀，阻止作用有限，公開明示的版本要繼續討論，若訂下數量過濾器也需要請求修改，這裡提出版本3的修正，再請參與討論的各位給出有效意見，謝謝。--提斯切里（留言） 2025年9月30日 (二) 00:29 (UTC)[回复]
我發起了Template_talk:藝人#別名與暱稱欄目，大意為：
暱稱、綽號雖都常譯為nickname，但在中文用語裡暱稱、綽號含意實有分別（如同日語的「愛称」及「異名」），而藝名與它們的性質分別更大，嚴格來說實應分為暱稱、綽號、藝名。WP:BLPBALANCE的「人物的別稱除需可靠來源支撐外，亦需證明此別稱並非一時收錄標準。」及修訂討論，其指的「別稱」應是暱稱、綽號。藝名不應受到此條文限制，藝名只會是傳主自己官方所定，它用於辨別傳主身份，就算只在一個作品中用過一次，就算不是廣為人知，只要有可靠來源（包含可靠的一手來源）就應該全部列出。像Template:Infobox_writer，「筆名」（pseudonym）與「別名」（other_name）是分開的。不管修訂是否達成，「別名」欄目應改作直接顯示為「其他藝名」，以免造成混淆。在修訂討論未有共識前，暱稱、綽號應列於「暱稱」(nickname）欄目，事實上現在通常就是這樣。如果能增加欄目，將來應討論暱稱、綽號分作兩個欄目。
補充，我覺得暱稱與綽號區別：
  • 綽號：較常與人物本名並列介紹，不常用作代稱。
  • 暱稱：常用作代稱。
--Underconstruction00（留言） 2025年9月30日 (二) 03:53 (UTC)[回复]
(－)反对增加欄位綽號欄位，變相鼓勵粉絲行為。--提斯切里（留言） 2025年9月30日 (二) 08:06 (UTC)[回复]
@Tisscherry：几点意见供推敲：
1、人物的别称及昵称不是必须的。不佳，假如我滑坡称据此李白的别称栏里“诗仙”不是必须的，然后删掉，我想不会有谁为我发声在下此前就提过，当我们在修订的是全局方针时，我们实在有必要把自己的视角从确实广泛存在fanpov情况的艺人类条目处抽离出来。我提议删去此句。
2、符合收录标准的资格不是一时的之别称与昵称，别称栏位仅只放置1个，通常是由传主本身最早发出或最广泛流传；昵称栏位须注意不能违反生者传记的方针指引以及维基百科不是新闻报导，仅只放置3个昵称。收录的昵称若有争议，请适时发起讨论，时间推移之下不符合收录标准的昵称须随时调整移除。，这里的问题容在下拆分：
（1）别称——视角从艺人抽离，不赘——一个比较典型的情况是包括笔名以及曾用名，像鲁迅那样有大量笔名以至于要单开一节的情况并不多见，这种情况下固然有必要引流到正文章节；但如果只能填1个，毛泽东“二十八画生”的笔名可能最早，但“李德胜”的化名想必最为广泛流传，这种情况下我也不知道谁来为我的选择发声。事实上笔名、曾用名等并不是fanpov的主要发生地，我认为在此处与其限制个数，更关键的应该是明确“昵称不是别名”。
（2）昵称：对个数不介入。但我对于“时间推移之下不符合收录标准”的说法有疑虑，因为那似乎与NT:TEMP对于“不是一时的”的表述存在语义模糊，我提议调整说法。
3、原本没有放入别称内容的人物条目，不用强加介绍。：“原本”的时点不明，条目始创时？该方针修订生效时？“不用强加介绍”可能滑坡。
4、我在认真思考一个问题：这个修订是否不应该发生于对该方针？因为一般人物很少出现这种昵称泛滥的情况；同时，对于方针而言，这也显得过细。我在想，我们应该改为对Template:艺人的说明文档作出修订，又或者改为（假如各位认为其他一般人物条目也应该一并修订）在Wikipedia:格式手册/信息框增加细则，而让该方针保持原样。如果说诸位仍认为应该改方针，我的提议条文如下：

人物的别称除需可靠来源支撑外，亦需证明此别称并非一时收录标准，这意味着在摒除短时效新闻来源的影响的前提下，此别称应得到相关来源对该别称（的意义、成因或渊源等）作出有效介绍。

我想这应该能包含阁下各版本中除个数具体规定外的多数共识较强的内容（不加“不能违反生者传记的方针”是因为这页本来就在BLP）。--银色雪莉（留言） 2025年9月30日 (二) 13:09 (UTC)[回复]
另，假如是去Template:艺人或者Wikipedia:格式手册/信息框，可以这样（大致意思）：

收录于信息框的人物别称应符合WP:BLPBALANCE，其中：（1）别名（含曾用名、笔名和艺名或其他排他性指代传主的称呼）参数不应填入昵称或绰号；（2）昵称参数限制填写3个注：我对这里没有很明确立场，请各位讨论。

以上，请诸位看看。--银色雪莉（留言） 2025年9月30日 (二) 13:36 (UTC)[回复]
另外提個討論，一般藝人我不確定，但是真的許多韓國偶像會拍q&a，裡面有問到關於自己喜歡的暱稱這個問題，像是我今天又有一個喜歡的偶像拍了影片，這個到底算不算完全可靠沒有辦法完全確定，但卻可以完全確定這個是傳主本人喜歡的名稱。--Louischen88888（留言） 2025年9月30日 (二) 15:02 (UTC)[回复]
原則上(－)反对此修訂的數量限制，不認為Template:藝人原有限制䁥稱5個有問題，沒必要收窄是3個，一來有其他條件限制，二來按上文討論，䁥稱一欄現時可能已承載了其他別稱，如綽號；別稱欄位1個更加要(－)強烈反对，上文其他人已指出怎可能足夠，再說，近日討論已揭示了各類infobox對於別稱的定義根本沒有一致標準。且經深思後，(－)反对此修訂的層面，現在討論變得越來越多問題，節外生枝，歸根究柢是因為討論範圍本來只是討論藝人，卻去修訂一個影響所有人物的方針，範圍過度擴大所致，想再討論的話倒不如像以前一些先例在格式手冊層面修訂一個藝人專屬的共識。
而且這版草案從細節上看也實在太稚嫩，有些銀色雪莉君已經指出了。我對大家談及問題及修訂細節的(！)意見如下：原條文不是只限制infobox，但修訂的目的之前曾說只針對infobox，就算原則沒問題也不應該這樣改（當然我本人已決定反對在生者傳記層面修訂）。u君指出了Template:藝人中藝名與別名的混淆需解決，那麼修訂會不必要地影響藝名。u君認為Template:藝人的䁥稱應拆分為䁥稱與綽號兩欄目，我看雖有些名是難以區分，但分欄目也無傷大雅，沒有意向；大家之緊張無非是因為數量限制，一分為二等同加了配額，我想了一會，亦認為我們不應把精神用於分辨䁥稱與綽號，所以主張分欄也好，不分欄也好，兩者都共享同一組配額；當然我認同藝名不屬此類，不應受到同樣數量限制。銀色雪莉君提出了很多非藝人例子，可見從一個圈子出發想出來的收得很緊的準則，難以套用到所有地方，不過另一方面，這些例子都不是生者，擔心大家思路越想越不清晰了。
討論至今，感覺是本來已有合理且足夠的規則，只是守規則的人不多，甚至連規則知的人也不多而已。--Factrecordor（留言） 2025年10月1日 (三) 08:19 (UTC)[回复]
我覺得延用既有警告的規則可以，不過是否要嚴格執行可以再討論，因為僅針對藝人的部分似乎有過多的暱稱或過少的暱稱似乎都不會造成太大的影響，但是如果訂得很嚴苛的話還要勞煩各位一一去檢視各個藝人的條目來進行刪減，而且會不會造成尤其是偶像條目的編輯戰，會有粉絲認為這個暱稱比較重要之類的，另外我不贊同這個規則沿用到古人等等的人物，就如同銀色雪莉君說的狀況。--Louischen88888（留言） 2025年10月1日 (三) 08:55 (UTC)[回复]
其實我們最初的討論的不是數量的多寡，而是是否要有來源，其實我現在看了各種條目，發現有超過五個的真的不多，但在來源的部分我也沒有到確定要怎麼做，大家可以再討論一下。--Louischen88888（留言） 2025年10月1日 (三) 09:12 (UTC)[回复]
感謝提供意見的各位，以銀色雪莉的版本以及綜合了有效意見做了版本4的修正。我的想法是，因為原本沒有明確寫出來，即時有過濾器也沒能有效阻止沒有來源的暱稱增減，而大部分的志工或可能不知道沒有來源是可以移除的，明確寫出來方便大家維護清理，如同目前清理中的旗幟。有甚麼能夠有效修改方向的，或是我有理解錯誤的地方請再麻煩撥冗提出。—提斯切里（留言） 2025年10月1日 (三) 11:51 (UTC)[回复]
再細心分析，我覺得「別稱」或other name字面上包含範圍很大，先不要被這個用詞牽住走，要先把不同性質的對人稱呼從定義上分類確立，再重新給予名稱或審視現時欄目名稱是否能對上。我覺得先分兩大類：
  • 第一類：傳主曾用於署名或登記的名字，藝名、筆名、化名、曾用於在政府或公共機構作身份登記的姓名，都屬於此類，也是完全屬於傳主官方性質。
  • 第二類：䁥稱、綽號等不一定由傳主自己主導的稱呼。
我認為第二類應受到WP:BLPBALANCE有關「別稱」的條款管制，包括「並非一時」，也應受到資訊框模板所定的䁥稱最多5個數量限制，或將來的數量修訂限制。但第一類是對身份識別有作用的，不應受「並非一時」及數量限制所管，只要有可靠來源（包含可靠的一手來源）證明就可寫進去。第一類的性質不可能違反WP:BLPBALANCE強調的中立，避免不適當批評和讚揚的原則。現時藝人資訊模板也只是限「䁥稱」欄最多5個名，對於實際上是「其他藝名」的「別名」欄沒有數量限制。
另外我想提醒WP:BLPBALANCE那段全文是「条目内容应从可靠来源中获取，并且应只与条目主角有关。对罗织入罪的主张须保持警惕，留心那些针对在世人物的具有偏见和恶意的内容。如果有人试图推销带有偏见的观点，则应坚持可靠的第三方已出版来源以及与人物收录标准相关的明确论证。人物的别称除需可靠来源支撑外，亦需证明此别称并非一时收录标准。」所說的可靠來源是包含可靠的一手來源，好比傳主自己發佈/出版物，傳主之言的紀錄，在質疑有帶偏見觀點的情況下才需要可靠的第三方來源。--Underconstruction00（留言） 2025年10月2日 (四) 01:49 (UTC)[回复]
  • 4版「別名不是暱稱，見例徐熙媛的大S。」無助改善界定問題，甚至乎令人更疑惑，或是錯誤的，對不少人來說本名以外的都是別名，暱稱也是別名，別名條目也是這樣寫。大S不是好例子，此名有很多來源指出是出道時的藝名，但同時又有暱稱的感覺，查流星花園片頭，名字是「徐熙媛」，不是「大S」或「大S徐熙媛」，可能她漸漸用回本名「徐熙媛」，「大S」本身又很適合作暱稱那樣使用，「大S」的性質可能隨時間推移而漸變。
  • 一句寫「別名」，一句寫「別稱」。
  • 限5個是規管資訊框，未有指明這點。之前的內容應該是規管全文。
  • 「時間推移之下不符合收錄標準的暱稱須隨時調整移除。數量別超過5個。」「收錄標準」在WIKI是特定用語，這裡可能不宜稱為「收錄標準」。時間推移之下不再符合，不是現有概念的延伸，甚至乎是背道而馳。NT:TEMP的精神是一旦符合了就可永遠保留，不需要考慮幾年後多年後情況如何。概念應是隨時間推移有更重要更具代表性的內容可以加入，在正文來說如果條目內容過長到臨界標準，必需精簡，可能先拿它開刀，但這和廢話一樣，要特地提？在資訊框來說就是當數量達上限，將來可能有新名替代舊名位置。所以我覺得「收錄的暱稱若有爭議，請適時發起討論是否需要保留」之後便寫「資訊框收錄的暱稱數量別超過5個」，再指出「時間推移之下可能應以更具代表性的新暱稱取代舊暱稱在資訊框的位置，可適時檢討。」
--Underconstruction00（留言） 2025年10月2日 (四) 03:38 (UTC)[回复]
最後，我重申(－)反对收錄傳主曾用於署名或登記的名字，包括藝名、筆名、化名、曾用於在政府或公共機構作身份登記的姓名，要受到可靠來源、私隱以外的任何附加規管。若「別名」「別稱」包含此類，就唯有全盤反對4版了。新加入的「有效介紹」更是不可能接受用在這類，確認是誰藝名、筆名但沒有解釋起名由來，天下間多的是。--Underconstruction00（留言） 2025年10月2日 (四) 04:37 (UTC)[回复]
那麼接下來可以進一步討論，infobox暱稱或藝名或別稱的欄位存留，過濾器日誌要強制禁止放入。所有人物條目都不能放入相關內容，這樣？--提斯切里（留言） 2025年10月4日 (六) 07:21 (UTC)[回复]
(－)強烈反对，從上述討論，完全看不出能得出「不能放入相關內容」這個方向，不要扭曲大家的意見。此外(＊)提醒，經這一段時間討論，我們已發現現有生者傳記方針有相關條文可依，Template:藝人對暱稱也有5個上限的要求，對藝人暱稱收錄均屬於具針對性、具體的指引，並不如較早前的討論以為沒有這樣的條文，只是各自說自己的道理，急需達成共識。且現在討論焦點變成非暱稱類別。是以任何新修訂草案達成共識前，繼續按照現有條文要求收錄藝人暱稱即可。--Factrecordor（留言） 2025年10月5日 (日) 06:17 (UTC)[回复]
把過濾器提醒的文字明文寫出您們也反對，另外一邊還要增加欄位並且抵觸違反方針指引允許不用來源，我覺得兩位是在WP:POINT了。--提斯切里（留言） 2025年10月5日 (日) 06:45 (UTC)[回复]
你們沒有要達成共識，你們是因人廢言--提斯切里（留言） 2025年10月5日 (日) 06:46 (UTC)[回复]
最新修訂僅只是將過濾器日誌的文字整合寫出來，連過濾器日誌文字內容都反對，你們從一開始就是因人廢言，真的太失望了。我一直以為德高望重可以溝通，都是假的。討論的進行是，沒用的意見可以忽略不處理，若只能反對的兩位沒有辦法提出有效意見，只能頻頻違反WP:V及WP:RS的WP:FAN發言，沒有辦法協助討論進行的兩位停止發言，謝謝。--提斯切里（留言） 2025年10月5日 (日) 06:53 (UTC)[回复]
銀色雪莉君和我曾經有過衝突的88888君都還能好好說話，這個討論到現在我的感覺很明確就是寫了多少條目的使用者，對於改善方針指引這麼的不NPOV，是不是主持人換任何其他人你們才會好好說話？--提斯切里（留言） 2025年10月5日 (日) 07:01 (UTC)[回复]
過濾器文字應該是指上文抄下來的這一段：

警告：系統檢測到閣下或許正試圖變動人物傳記條目的「暱稱」相關內容。按照維基百科的方針要求，凡加入維基百科的內容均需要提供可靠來源，而對於生者傳記類的條目，來源要求則更加嚴格。任何在不提供可靠來源的情況下，增改條目既有人物暱稱的行為，均違反維基百科規定，無論所添加的暱稱是否真實存在。此類編輯將有可能隨時被其他編輯者移除；在不提供可靠來源的情況下反覆添加這類內容者，將有可能被管理員封禁。

條目中暱稱一欄一般最多只需要列舉三五個即可，大量羅列平時不甚使用且無來源佐證的暱稱也屬於違反規定的舉動。請為閣下的變動提供參考資料。
這一警告是由系統自動提示的，故有時會誤報。如果閣下確信自己的編輯沒有問題，請再次點擊「發布更改」按鈕，頁面即可遞交。
草案版本4如下：

別名不是暱稱，見例徐熙媛的大S。人物的别称與暱稱除需可靠来源支撑外，亦需证明此稱號并非一时收录标准，这意味着在摒除短时效新闻来源的影响的前提下，此稱號应得到可靠來源对该别称（的意义、成因或渊源等）作出有效介绍。暱稱不是必須，收錄的暱稱若有爭議，請適時發起討論是否需要保留，時間推移之下不符合收錄標準的暱稱須隨時調整移除。數量別超過5個。

兩者算有多少分相似？？？？？--Factrecordor（留言） 2025年10月5日 (日) 12:15 (UTC)[回复]
你一直執意修訂方針級的生者傳記，而過濾器文字只是用於人物模板「暱稱」欄目的提醒，其實連正式指引都算不上，但我不覺得這段文字有問題，有問題的是你那與它差別很大的草案。在討論第3版時我主張在格式手冊層面作出專門針對藝人的共識，自然不會支持生者傳記方針層面的修訂，但我也沒有反對第4版，我反對的是你突然冒出來的一句「所有人物條目都不能放入相關內容」，不明所以。在這一個留言的上一層是underc對第4版的意見，亦應該是第4版發表後的唯一意見，那段意見並沒有完全反對第4版，只是反對其中一部分，但你沒有予以回應，而是說「那麼接下來可以進一步討論，infobox暱稱或藝名或別稱的欄位存留，過濾器日誌要強制禁止放入...」，整句話都不明所以。仔細看看underc的意見，他指「別名不是暱稱，見例徐熙媛的大S。」一句有問題，這句跟過濾器文字究竟有什麼關係？他說要指明哪些條文規管條目全文，哪些條文規管infobox，過濾器文字本身只為infobox而設，自然不會有相同問題。他指藝名、筆名、化名不應與䁥稱、綽號等受同等規管，特別強調不需「有效介紹」，過濾器文字本身只為「暱稱」欄目而設，也沒有「有效介紹」之說。你把第4版說成源自過濾器文字，真是不知所云。--Factrecordor（留言） 2025年10月5日 (日) 12:58 (UTC)[回复]
對，無理指責他人因人而廢違反善意推定。請提斯切里自重。請老實回應我們的意見。--Underconstruction00（留言） 2025年10月6日 (一) 03:14 (UTC)[回复]
我想從你們最新的發言裡找出可以用來修正草案的文字，我找不到。可以請兩位自己整理出「重點」嗎？謝謝。--提斯切里（留言） 2025年10月6日 (一) 03:27 (UTC)[回复]
檢視各種人物資訊框模板：
除了收錄當前真實姓名、全名，及當前通用名/藝名/筆名的欄目，通常都有出生名（Birth name）。
  • Template:藝人：
    • 「暱稱」（nickname）：參數有「暱稱」、「綽號」，說明是「經常出現在新聞媒體上的暱稱，多個暱稱時請用「、」做分隔，最多別超過五個。」
    • 「其他藝名」（other_name）：閱讀時我見到顯示的是「別名」，參數有「其他藝名」、「別名」， 說明是「曾使用或在外地發展時所使用的藝名。」
  • Template:Infobox_football_biography、Template:Infobox_badminton_player：
    • 只有「暱稱」（nickname）
    • 沒有other name類別
  • Template:Infobox_writer：
    • 「筆名」（pseudonym）：說明是「作家筆名或其他別名。」
    • 「別名」（other_name）：沒說明
    • 微格式有列出nickname
  • Template:Infobox_officeholder：
    • 「原名」（original_name）：參數有「原名」、「本名」、「其他名字」
    • 「其他姓名」、「別名」/ othername、different name：沒說明
    • 微格式有列出nickname
  • Template:Infobox_scientist ：
    • 「別名」（other_names）：說明是「曾用名或者暱稱 – 使用Plainlist分隔多個值」
    • 微格式有列出nickname
--Underconstruction00（留言） 2025年10月6日 (一) 07:10 (UTC)[回复]
(＆)建議：別稱、別名是多種不同類型稱呼的泛稱，會引起混淆，所有人物資訊框及方針指引條款都應避免使用別稱、別名這一用詞。
建議相關方針指引以下列劃分方式註明規管範圍，對不同類別的稱呼各設置不同程度的要求。建議所有人物資訊框以下列方式劃分欄目：
  • 「䁥稱」收錄所有䁥稱、綽號等可能不屬於官方性質類別的稱呼。
  • 「藝名」、「筆名」
  • 「曾用姓名」收錄所有曾用於身份登記的姓名。（另有欄目的當前身份登記姓名及出生名除外）
  • 化名視乎情況歸入「曾用姓名」或「藝名」、「筆名」。
@银色雪莉--Underconstruction00（留言） 2025年10月6日 (一) 07:35 (UTC)[回复]

版本5草案討論

我對Wikipedia:生者傳記#批评和赞扬修訂草案如下：

現行條文
人物的別稱除需可靠來源支撐外，亦需證明此別稱並非一時收錄標準。
提議條文
人物的姓名及對其的稱呼分為多種，包括曾用於身份登記的姓名、筆名和藝名或其他由傳主親自使用的排他性指代其本人的稱呼，這些名稱屬於官方性質；亦有暱稱或綽號這類不一定屬於官方性質的稱呼。收錄所有名稱都需可靠來源支撐。對於暱稱或綽號，另需證明此稱呼並非一時收錄標準，這意味着在摒除短時效新聞來源的影響的前提下，這類稱呼應得到可靠來源對其意義、成因或淵源等作出有效介紹。暱稱或綽號不是必須，收錄的此類稱呼若有爭議，請適時發起討論是否需要保留。暱稱或綽號在人物資訊框模板收錄的數量合共不應超過5個，隨時間推移可能應以更具代表性的此類新稱呼取代舊稱在資訊框的位置，可適時檢討。版本5
--Underconstruction00（留言） 2025年10月6日 (一) 08:26 (UTC)[回复]
(！)意見，需要重提我對@银色雪莉君「有效介紹」主張的疑慮。此概念出於通用收錄標準（對整個條目主題），相對的是順帶提及，兩者沒有很明確的界線，非常依靠維基人按自身常識判斷及集體討論。對於一個稱呼的介紹，很可能只是一句，篇幅或在文中的重要性只是等同對整個主題的順帶提及程度。而且「並非一時」和「有效介紹」本是兩個概念，沒有因果關係。因此經思考後我還是只能接受「介紹」，加上「有效」會惹人誤解或助長惡意刁難。此外也提過「一個暱稱的被介紹程度，也未必和其代表性成正比關係，介紹程度的最主要因素應是讀者是否易於自行理解，例如「叉燒姐」就頗需要介紹，姜B就不需怎樣介紹。」進一步解釋，有些演變自藝人本名而純粹加入親䁥元素的䁥稱，由於一望而知，恐怕不一定有介紹，傳媒可能只會寫一句「人稱XX」「䁥稱XX」。雖然上文已證姜B能找到介紹，但我新近想到另一事例，郭富城的「城城」，這個䁥稱我自幼就知道，街知巷聞自然不下於姜B（至少在粵語圈），現在google會搜到很多「郭富城（城城）」「城城（郭富城）」，或直接代指，但介紹真的沒發現半個，甚至「人稱城城」「䁥稱城城」也好像沒有，恐怕是成名太久、過往地位太高，特地解釋的來源都不在能google的年代了。再綜合較早期談及的官方認可、貶稱，我認為應這樣修訂：

......對於暱稱或綽號，另需證明此稱呼並非一時收錄標準，即符合以下三項條件的其中一項：

  1. 在摒除短時效新聞來源的影響的前提下，這類稱呼需應得到可靠來源對其意義、成因或淵源等作出介紹。
  2. 被2個出版時間相隔至少1年的第三方可靠來源提及或使用，並獲得傳主認可，例如由傳主官方發佈，或傳主曾直接表示樂意接受此稱呼（並非經由編者推斷、總結）。
  3. 較廣泛及長期地被第三方可靠來源提及或使用，佐證這點需有至少4個第三方可靠來源，各來源的出版年份、作者、出版機構不可相同，最早及最近出版的來源至少相隔5年。
暱稱或綽號不是必須，收錄的此類稱呼若有爭議，請適時發起討論是否需要保留。暱稱或綽號在人物資訊框模板收錄的數量合共不應超過5個，應以代表性及持續使用時間作為篩選準則（參考文獻記載情況），這意味着隨時間推移，舊稱呼在資訊框的位置可能會被新稱呼取代，可適時檢討。傳主曾表示反感的暱稱或綽號，不管迴響有多大，都不可收錄於資訊框。
--Factrecordor（留言） 2025年10月7日 (二) 07:50 (UTC)[回复]
利申：被现充，因此许久未回复。（PS：在Template talk:藝人也有类似讨论，我就不两边跑了，以下作（对@T君第四版、@U君第5版及@F君5版修订案的）总体性回复，陈述我的一点浅见；若因未一一对应回复而有所词不达意处，谨此致歉。）
1、不知道我理解是否准确，在我看来，别称中的自源性称呼（简称“自称”。PS：也许有人觉得这简称像废话，抱歉你想错了，这也是我为什么不直接用“自称”的原因）和他源性称呼（简称“他称”，以下我将以此代替“昵称”、“绰号”等称呼，但不代表我要求在infobox中更动这些称呼，相应的处理我将在自己的提案中作成）存在区别似乎在各位的意见中已经达成一定程度的共识（注：以下其他“达成共识”均是个人看法，如果有认为我的概括有误时请指出）；但对于如何区别及处理似乎还有不同观点。
2、对于自称：
（1）这种别称不应使用“官方性质”来作修饰词。自称具备内源性，即其源于自身而非外部，其成因和底层逻辑是不可逆的；“官方性质”则一定程度上提供了“官方-粉丝”这一可逆逻辑存在的空间。A是B的粉丝，以某一称呼来称呼B，B（不管出于什么原因）接受这个称呼并进一步将其作为自称（而不仅停步于接受这个称呼），这很官方，但这整个流程本质上是一个FAN的行为。因此，以其成因源头来分类而不以“官方”与否来分类，有助于抵消不必要的FAN观点。我认为“官方性质”这个修饰词应该拿掉就好，除非诸位打算接受有用户以来源表明传主说了一句“大家好我是你们的XX”为由就要把“XX”视为自称而“不应受“并非一时”及数量限制所管”——那样将导致这种“形自实他”的称呼泛滥。严格地界定自称与他称以避免不适当的适用规则的变化（PS：主体词是黑体——我不会管着传主用什么名字），在我个人看来有利于厘清问题。也许会有看法说，那传主把他称用成艺名也不行吗？我们都知道，艺名是指传主从艺发表作品（这个作品的形式自然是多样的，可以是综艺节目的署名、也可以是电影作品的署名等等）时使用的自称，如果真出现这样的情况，那么这实际上是原始来源的性质变更，就不会存在问题。
（2）使用可靠来源我想这个大家不会有异议（需要申明的是，我在上方对可靠来源的定义使用了WP:V，它并不排斥WP:ABOUTSELF允许下的例外；WP:BLP也早就明言WP:BLPSELFPUB）。至于对于“可靠介绍”、“介绍”和“支撑”的选词，我赞成使用“支撑”——本来而言，如果一本地方志介绍人物的字、号或笔名时也只是简单一句，而这就足够作为条目来源了，那么在有意见忧虑在这个语境下“有效介绍”可能引起纷争，那么使用“支撑”应该是合适的。
3、对于“他称”：
（1）对他称的限制无疑应严格于自称。这可以说是对于FANPOV的必要限制。从上方诸君意见看，我想这大概应是共识。同样地，我也不赞成使用“非官方的”来作为修饰词，这还是会给我在前述提出的那个逻辑创造空间——简而言之，即便是“官方接受”了的“非官方他称”（或者甚至升级为“官方接受”了的“官方他称”），它就是一个“他称”，不能因而摇身一变——除非它达到了上面提到的艺名的举例的程度。
（2）条文中对佐证他称使用的可靠来源要加“第三方”作为定语以抵消FANPOV。至于说“有效介绍”、“介绍”还是“支撑”等何种程度，我认为F君的后两项条件在执行上不免多有不便，具体的量化标准也可能会引起争议（不是就“应否量化”的争议，而是就“量化标准如何为佳”的争议），我的建议版本是“在摒除短时效新闻来源的影响的前提下，此他称应得到相关来源对他称（的意义、成因或渊源等）作出有效介绍又或者佐证该称呼等效地代替传主姓名此处有注，见下”，就像[45]这样，除了开头外下文全是用“城城”称呼之，我想不会有人质疑“城城”作为一个他称的地位。“并非一时”和“有效介绍”可以存在因果关系，见NT:TEMP，在存在“等效地”一项例外后，对于绝大多数他称作出有效介绍，我认为是应有之义。
（3）关于“XX不是必须”这个表述以上三版似乎都有，这一点我在此前已表示反对，我的立场没有变化——我们没有必要做这样的定性；但三版中都有的“收录的昵称若有争议，请适时发起讨论是否需要保留”我完全赞成。鉴于infobox对他称的数量限制，检讨机制又是三版共识，应亦无大碍。我对于传主曾表示反感的昵称或绰号，不管回响有多大，都不可收录于信息框。这一表述存在疑虑——我们应从第三方观点来表述这个问题。
4、综上，在下在此提一个复合修订案如下（这也是我此前的一贯意见：有些东西改到方针里去可能是古怪的。）：
（1）对WP:BLPBALANCE的修订：

人物的别称依其起源性质可分为自源性（如曾用名、艺名和笔名等，以下简称“自称”）和他源性（如昵称和绰号，以下简称“他称”）[a]。自称的收录需可靠来源支撑。他称的收录需可靠第三方来源证明此别称并非一时收录标准，这意味着在摒除短时效新闻来源的影响的前提下，此他称应得到相关来源对他称（的意义、成因或渊源等）作出有效介绍又或者佐证该称呼等效地代替传主姓名[b]。

（2）对Wikipedia:格式手册/信息框的修订：

他称
他称（对应昵称、绰号等参数）在人物信息框模板收录的数量合共不应超过5个。对他称的收录若有争议，请适时发起关于是否保留该他称的讨论，这表明随着时间推移，旧称呼在信息框的位置可以被更具代表性及持续使用时间更长的新称呼取代。他称的收录应遵守WP:BLP及WP:NOT的相应规定。

備註

  1. ^ “起源性质”不一定以最原始来源为约束，而应着眼于其性质是否发生根本变化。
  2. ^ 后者仅应用于该他称与传主姓名存在关联时，“等效地”意味着来源内文压倒地以该他称代替传主姓名。
以上，请诸位不吝赐教，如果有未能回应各位上述意见之处，也请一并指出。--银色雪莉（留言） 2025年10月9日 (四) 23:49 (UTC)[回复]
PS：在第二项修订案中，会加入第一项修订案的参见链接，所以“他称”的定义及其区别于“自称”处（即对应及不对应何种参数），仍由修订后的WP:BLPBALANCE界定。--银色雪莉（留言） 2025年10月9日 (四) 23:54 (UTC)[回复]
謝謝雪莉君的仔細回應，學習了許多。對您的修改版本表達支持，您若認為合適，後續推動麻煩您，我會適時支持推進。--提斯切里（留言） 2025年10月10日 (五) 02:27 (UTC)[回复]
@银色雪莉
  1. 當初我說官方性質只是臨時想出來，叫自稱也不違我所想。大家想的都是作品的署名一類(藝名筆名)，不會認為是說了一句「大家好我是你們的XX」，只要在說明講清楚是用作作品署名或身份登記的自稱，就不會有誤會。
  2. 不過原來針對暱稱和綽號的部分，改叫他稱會有問題，暱稱和綽號未必是他稱，可能是自稱，所以我的字眼是「不一定」。在我看來，沒法反對「暱稱不是必須」，但作品的署名是必須。假設有個作家曾經很厚面皮，有個筆名叫「上天下地唯我獨尊大文豪」，真是出版書籍時的正式署名，參加作家協會時也用過這個名，應當收錄此名，但是若他有個正常的筆名，自己起了一個「上天下地唯我獨尊大文豪」的稱號，就應該按被關注情況來衡量是否收錄，不可以引起只要一手來源証明他喜歡這樣自稱就可收錄的錯覺(一手來源也不違反可靠來源)。WP:BALANCE的核心就是BALANCE平衡，若凡自稱的東西就寬容那也不BALANCE，不應該給予自稱就寬他稱就緊的觀念，正確精神只是其中一些自稱不需要附加規管(用作作品署名或身份登記的自稱)，自己起的暱稱和綽號是應該和別人起的同樣有附加規管。在上次檢視資訊框後發現前人也是以暱稱和綽號作為定義上的命名，既然如此就直接在說明寫暱稱和綽號，相信這兩詞已經覆蓋90%我們心目中要加以規管的「他稱」，實在不一定要寫一段完全排除所有能鑽空子情況的定義。按之前所想過的情況，用作作品署名或身份登記的自稱此種性質是容易判斷出來的，就算像大S我認為它本是藝名，後趨向暱稱化，確定曾經是藝名就自然可以寫在藝名那一欄。反而只是暱稱和綽號兩者之間界線較模糊，但只要兩者不分開處理那就沒所謂了。總結我見解，沒有必要用上「他稱」一詞，應先分為「用作作品署名或身份登記的自稱」，以及「暱稱或綽號」，最多加句「等類似稱呼」。
--Underconstruction00（留言） 2025年10月10日 (五) 09:07 (UTC)[回复]
@Underconstruction00：
我能理解阁下的意见，不过我与您有不同的看法。采取“用作作品署名或身份登记的自称”和“昵称或绰号”的区分的问题在于：表字、自号，这些是完全有可能不出现在作品署名或身份登记当中的——请注意，字、号正是最典型的“自称类”别称。以沈竹礽为例，街外多说“竹礽”是字，而如果不查《钱塘沈氏家乘》（即其家谱），是难以确证“字莲生”的信息的。这类自称不用于作品署名（我想表字是什么用途大家都了解），而不用一手来源则无法确证。这种情况下，显然用“用作作品署名或身份登记的自称”来界定是否允许使用一手来源的逻辑是不妥的。事实上，自称本来就应采取与他称不同的做法，而不是将“他称严于自称”片面等价于“自称就宽他称就紧”——还是说诸君以为人物的表字也需要考量BALANCE？BALANCE针对的是观点，他称是一种观点的凝结，管起来是应该的；但对于自称也管，则是免不了“管这就得管那，而那不能管”的逻辑怪圈的，因为自己起了一个“上天下地唯我独尊大文豪”的称号这件事，和自己起了一个叫四明狂客、齐天大圣又或者徐青藤门下走狗，从形成机制上并没有本质的区别；而如果是谈文义——每个名字都是好寓意，齐天大圣甚至超凡入圣嘞，我总不能因为齐天大圣这名字这么拽而开始讨论BALANCE问题吧？因此，因为文义如何而对自称来开展这种讨论恐怕也是不妥的。我想真正有效的，是：
（1）将自称的收录需可靠来源支撑。加入注释，强调WP:ABOUTSELF的作用，如果其使用的一手来源（这里是自行发布来源，作个例子）存在“过度的自我宣扬”等情况（注意，是来源，不要搞成名字的文义分析），那么完全可以移除这个来源，也就无法收录这个自称。
（2）他源性（如昵称和绰号，以下简称“他称”）改为“他源性（如他人命名的昵称和绰号，以下简称“他称”）”，把话讲清楚些。至于“昵称和绰号未必是他称，可能是自称”，昵称我没太多源于自称的印象，可能要请阁下给例子；自封的绰号，那就是齐天大圣了，这个机制我在上面提及过，就不多说了。
以上，再请各位指正。--银色雪莉（留言） 2025年10月11日 (六) 10:15 (UTC)[回复]
我需要時間消化新留言--Factrecordor（留言） 2025年10月11日 (六) 10:48 (UTC)[回复]
@银色雪莉，提斯切里一早講過藝人有官方公布的暱稱，所以「自稱」的暱稱是存在。--Underconstruction00（留言） 2025年10月16日 (四) 08:52 (UTC)[回复]
我这也没说过“不存在”，只是请您举个例子，以便“对齐一下颗粒度”doge；这样，我姑且僭越一下举个例子，例如柏木由纪自称“ゆきりん”，您看是否算您说的“自称”型昵称？如果算的话，其实也并不会对上面的修改产生冲击，一则它是自称，就还是可以走与上边后面提到的自封的绰号这个路径；二则在下再把上面原方案第二部分他称（对应昵称、绰号等参数）在人物信息框模板收录的数量合共不应超过5个。改成人物信息框模板的昵称、绰号等参数收录他称的数量合共不应超过5个。，这样的话整个说法应该算是更自洽。--银色雪莉（留言） 2025年10月16日 (四) 11:00 (UTC)[回复]
@银色雪莉，實在對不起，可能我看漏了或者忘記了有關自封綽號路徑的論述，請明示。一個鮮活例子是林作自封「香港抽水王」[46]及「香港恩沙基」[47]。抽水王是符合他的個性，恩沙基只是在刻意誇張，製造笑話。--Underconstruction00（留言） 2025年10月17日 (五) 01:41 (UTC)[回复]
@Underconstruction00：请见此。林作这两个甚至都有第三方来源了，就算按您说的“正确精神只是其中一些自称不需要附加规管(用作作品署名或身份登记的自称)，自己起的昵称和绰号是应该和别人起的同样有附加规管”，这似乎也没法束缚这两个自称。我完全理解您的忧虑，但是我想它并非能在这部分条文中去解决的问题，因为这将会涉及到文义鉴定，文义鉴定的问题我上面提过，它是一个不可能量化的问题，需要编者就事论事讨论，而到那时，NPOV、ABOUTSELF等要求仍然普遍地适用于约束该问题。事实上，我想进一步指出的是，目前在这部分条文中，对于来源的要求是一种必要性要求而非充分性要求（我确信目前的表述如此），也就是说“想收就得如何”，但不是“如何就能收”。--银色雪莉（留言） 2025年10月17日 (五) 05:45 (UTC)[回复]
我對自稱他稱沒意見，不過倒見過一個小眾的自稱綽號，在陳蕾舊版本[48]裡有一個被來源請求的「國民家姐」，其實是在某次Live中自封[49]，屬於一時興起，然後被一部分歌迷所喜愛，但挺小眾的，雖然連一手來源（Live的片段）都未必能找到，但可以想像一個藝人在自己的社交平台這樣貼文自封（有一手來源），只有粉絲才知道的情況。--Factrecordor（留言） 2025年10月17日 (五) 18:22 (UTC)[回复]
銀色雪莉君最後修訂版本已消除我的最大疑慮，故不反對。--Factrecordor（留言） 2025年10月17日 (五) 18:27 (UTC)[回复]
像倖存者偏差，容易想起的都是來源多，小眾的存在但不易知道。不過我也接受@银色雪莉的解釋。--Underconstruction00（留言） 2025年10月18日 (六) 05:00 (UTC)[回复]
@银色雪莉@Tisscherry最後版本可進入正式發布公示程序了吧--Underconstruction00（留言） 2025年10月20日 (一) 03:01 (UTC)[回复]
(＋)支持。--提斯切里（留言） 2025年10月20日 (一) 03:13 (UTC)[回复]
我在下面把最后的讨论中达成的一些调整共识又加入了进去，以便大家阅读比对，仍请@Factrecordor、Underconstruction00、Tisscherry各位把把关看看调整后文字上是否有什么不妥或遗漏的地方。我没在互助客栈搞过公示等事宜，也请各位能否协助处理或指点一下程序事宜？在此先表示感谢（话说这些可以在这里公示吗？还是要在方针版公示的？）。--银色雪莉（留言） 2025年10月20日 (一) 03:39 (UTC)[回复]
對最新版的修訂文字沒有意見。可以在這裡直接公示，一般是7天，沒有意見通過後就可以依據修改了。不介意的話我再發起。不過我對資訊框有點沒看懂，現在對應暱稱相關幾個欄位？或沒有新增欄位只是增加說明？--提斯切里（留言） 2025年10月20日 (一) 03:51 (UTC)[回复]
不介意，就请您发起吧。信息框一节，在这里没有新增参数（栏位），说的是各种栏位中的他称总数不能超过五个。--银色雪莉（留言） 2025年10月20日 (一) 03:55 (UTC)[回复]
了解了，沒更多意見，等其他使用者確認，沒問題我再發起公示。--提斯切里（留言） 2025年10月20日 (一) 03:59 (UTC)[回复]
最新話題：張敬軒不滿被叫軒公[50]，但他之前又用軒公之名做代言slogan「信軒公，用何濟公！」[51]--Underconstruction00（留言） 2025年10月20日 (一) 07:18 (UTC)[回复]
我觉得这是算“短时效新闻”，这个他称没有明显的不合规之处，不触犯BLP和NOT，有第三方来源（不是上面这俩），使用时间和广度也够——退一万步讲，等他把自己那油管节目下架再说吧doge--银色雪莉（留言） 2025年10月21日 (二) 00:57 (UTC)[回复]

拟公示版本

1、对Wikipedia:生者傳記#批评和赞扬修订如下：

現行條文
人物的別稱除需可靠來源支撐外，亦需證明此別稱並非一時收錄標準。
提議條文
人物的别称依其起源性质可分为自源性（如曾用名、艺名和笔名等，以下简称“自称”）和他源性（如他人命名的昵称和绰号，以下简称“他称”）[a]。自称的收录应基于可供查证的前提[b]。他称的收录需可靠的第三方来源证明此别称并非一时收录标准，这意味着在摒除短时效新闻来源的影响的前提下，此他称应得到符合要求的来源对他称（的意义、成因或渊源等）作出有效介绍又或者佐证该称呼能等效地代替传主姓名[c]。

2、在Wikipedia:格式手册/信息框中新增一节“他称”：

提議條文
他称
参见：Wikipedia:生者傳記 § 批评和赞扬
人物信息框模板的昵称、绰号等参数中收录他称的数量合共不应超过5个。对他称的收录若有争议，请适时发起关于是否保留该他称的讨论，这表明随着时间推移，旧称呼在信息框的位置可以被更具代表性及持续使用时间更长的新称呼取代。他称的收录应遵守WP:BLP及WP:NOT的相应规定。

備註

  1. ^ “起源性质”不一定以最原始来源为约束，而应着眼于其性质是否发生根本变化。
  2. ^ 其中，就可能存在的一手来源使用问题，尤其应考虑WP:ABOUTSELF等约束。
  3. ^ 后者仅应用于该他称与传主姓名存在关联时，其中“等效地”意味着来源内文压倒地以该他称代替传主姓名。

--此條留言由银色雪莉（討論｜貢獻）於2025年10月20日 (一) 03:39 (UTC)加入。[回复]

( ✓ )同意--Underconstruction00（留言） 2025年10月20日 (一) 04:55 (UTC)[回复]
這裡僅只是提醒，銀色雪莉君提出的版本，若在10月27日前沒有其他修改意見，將於當天03:39 (UTC)之後發起公示。--提斯切里（留言） 2025年10月24日 (五) 13:46 (UTC)[回复]
(＋)支持--重庆轨交18（留言） 2025年10月29日 (三) 16:18 (UTC)[回复]
对条文框的格式做了一些小调整。--Srapoj（留言） 2025年10月30日 (四) 21:38 (UTC)[回复]

就拟公示版本發起 公示7日，2025年11月3日 (一) 13:10 (UTC)結束--提斯切里（留言） 2025年10月27日 (一) 13:10 (UTC)[回复]

@银色雪莉君，已經通過佈局再麻煩您，完成後會關閉。謝謝。--提斯切里（留言） 2025年11月4日 (二) 00:33 (UTC)[回复]
@Tisscherry：完成--银色雪莉（留言） 2025年11月4日 (二) 03:57 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

genre和type的翻譯及相關分類

本主題或以下段落文字，在討論結束後應存檔至Category talk:各類型分類。

前情提要：WikiProject_talk:电子游戏#category:各类型游戏和category:游戏类型应该重新命名分类

在嘗試處理分類時，發現上遊母分類有很嚴重的問題。genre和type的中文翻譯都可以是「類型」，加上分類系統翻譯自英維，所以導致創建分類，wikidata連結存在混淆。大概影響數以十萬計的條目吧。

特別是目前上遊母分類，是以「類型」的繁體和簡體建立的，而且同時存在，進一步造成混亂。Category:各类型分类（Category:Categories by genre）、Category:各類型分類（Category:Categories by type）。

如果繼續延續英維的genre和type分類方式，兩者的中文翻譯應當不同。在此尋求意見，那個用「類型」，另一個用什麼翻譯。或者重新構建一套對應功能的一系列分類出來。--Nostalgiacn（留言） 2025年9月30日 (二) 05:16 (UTC)[回复]

问grok给的解答
  1. 适用范围Type：适用范围更广，可用于任何领域的分类（如物品、行为、概念等）。Genre：主要用于艺术、文学、娱乐等领域，强调风格或创作形式。
  2. 语感与语境：Type：更中性、通用，侧重于功能性或描述性分类。Genre：带有文化或艺术色彩，常用于讨论创作作品的风格或流派。
  3. 翻译倾向：在非艺术领域，翻译“type”时多用“类型”或“种类”。在艺术领域，“genre”常译为“流派”或“体裁”
--重庆轨交18（留言） 2025年9月30日 (二) 08:28 (UTC)[回复]
和這篇文章查重率100%。
那個好用，可以先套到既有內容上，看中文是否也在用：
type
類型：動畫類型、漫畫類型、電子遊戲類型、小說類型、音樂類型、電影類型、專輯類型
種類：動畫種類、漫畫種類、電子遊戲種類、小說種類、音樂種類、電影種類、專輯種類
genre
流派：動畫流派、漫畫流派、電子遊戲流派、小說流派、音樂流派、電影流派、專輯流派
體裁：動畫體裁、漫畫體裁、電子遊戲體裁、小說體裁、音樂體裁、電影體裁、專輯體裁
一些不存在的，如專輯流派、電子遊戲流派，就不用建這個分類。--Nostalgiacn（留言） 2025年9月30日 (二) 10:43 (UTC)[回复]
感觉type可以区分无关内容的功能性类型，例如单人游戏，双人游戏，多人游戏，网页游戏，手机游戏，电脑游戏等等。
genre可以区分有关内容的体裁类型，例如恐怖游戏，恋爱游戏，动作游戏，角色扮演游戏等等。
topic可以区分内容具体的叙事主题，例如平行世界，人工智能，太空战争，时间旅行等等。--重庆轨交18（留言） 2025年9月30日 (二) 11:30 (UTC)[回复]
「體裁」似可用。另外，或須提供分類實例，方便敲定名稱。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年9月30日 (二) 22:07 (UTC)[回复]
其實可以折中，「各類型及種類」（type）和「各類型及體裁」（genre），增加描述，保留「類型」，各自表述。不過這種方式，還是不免有望文生義的誤解。如「電影類型」（Film Genre），不清楚的人，會以為兩個都放😂--Nostalgiacn（留言） 2025年10月1日 (三) 12:12 (UTC)[回复]
现在就是该解决这些望文生义就会放错分类的时候，要不然分类里看着太凌乱了--重庆轨交18（留言） 2025年10月2日 (四) 10:39 (UTC)[回复]
建议将 Category:Categories by genre 译为 Category:各体裁分类 。Type译为类型，适用范围更广泛；genre 译为体裁，适用于大部分作品。后者子分类可酌情译为“风格”或“流派”。--Zhenqinli（留言） 2025年10月14日 (二) 03:35 (UTC)[回复]
这是我比较倾向( ✓ )同意的译法。可能跟我第一次接触genre看到的解释有关。我看到的就是体裁。type翻译成类型我也无异议--重庆轨交18（留言） 2025年10月14日 (二) 04:43 (UTC)[回复]
請勿先入為主，下面的編者在搜索之後，就改變了genre用「體裁」的想法，認為genre用「類型」更常見。WP:分类要求「使用通用名」，當然「不会有歧义」也是要求之一。--Nostalgiacn（留言） 2025年10月15日 (三) 07:21 (UTC)[回复]

@Howard61313：讓一切混亂的始作俑者，也來說幾句吧。2018年作出將「Category:依種類來作的分類 」（Categories by type）移動到「Category:各類型分類」（[52]），導致與2009年就存在的「Category:各类型分类」同名重複。

因循舊制，也基於新規Wikipedia:分类名称#命名一致性，將type所有相關分類改為「種類」也是一種處理方式。

子分類現在有兩種寫法，具體請到分類看，「各種類XX」（各種類公園、各種類城市、各種類學生、各種類爭議），也有「XX種類」（公園種類、城市種類、學生種類、爭議種類）--Nostalgiacn（留言） 2025年10月3日 (五) 02:26 (UTC)[回复]

(：)回應率先悖離「Wikipedia:假定善意」的始作俑者@Nostalgiacn：以及濫用字眼給人汙名化的始作俑者@Nostalgiacn：來收看一下您所要求的「說幾句」吧。我2018年做出此移動的宗旨，並不是為了製造混亂，反而是為了解決另一個混亂，也就是將「依...做出的分類」這種冗長的分類名改為「各」，這部分的更改有助於Wikipedia:分类名称所要求的簡潔目標。至於種類跟類型的差別，並不是我一開始做出此移動時的改善重點，而且我當年移動「Category:各類型分類」的時候，完全沒收到新名稱與「Category:各类型分类」重複的系統通知，也完全無從察覺此類分類已經存在，並不是有意為之。或許我對詞語沒像您講究到這種程度，對於一時不察的部分，我虛心受教，但您這種在討論中率先扣人帽子的方式實在也是混亂討論風氣的始作俑者，畢竟您tag我來，應該是為了確認雙方對一個議題的理解，甚至探討是否能達成共識，而不應該是為了這種對於討論沒有幫助的扣帽子吧？「假定善意」的葉面裡也寫的很清楚，「大多數時候，我們可以通過簡單的提醒來糾正此類錯誤」。
(！)意見：請您收回「一切混亂的始作俑者」這種有悖於假定善意的無謂評語，我也會將我對您的評語收回，並且很樂意跟您討論相關分類用法如何改善。--Howard61313（留言） 2025年10月14日 (二) 02:02 (UTC)[回复]
個人對事不對人，我只是对發生的事實（包括但不限於条目内容、用戶行為等）發表意見（WP:PA）。你的操作不論緣由為何，造成現在繁簡體「类型」分類共存的混亂是當前事實。如果你感到冒犯，個人在此致歉。另外，個人不介意「始作俑者」的說法，你不用致歉。--Nostalgiacn（留言） 2025年10月14日 (二) 05:39 (UTC)[回复]
(：)回應@Nostalgiacn：您說對了，確實有感到冒犯的情形發生，也很感謝您百忙之中願意為此作出的致歉。然而，比起致歉，相信直接收回那種有爭議的說法會有更大的效果，也對於兩邊共識的達成有更大的幫助。另外，您不介意「始作俑者」的說法，並不表示他人也不介意。畢竟當您使用了一個容易造成誤會的「混亂始作俑者」標籤，又祈使被您指責的人「說幾句」，會讓人難以理解到底要說哪幾句才會合您的意思，以及又為何要按照您的意思說，更重要的是，讓人不知道您到底希望別人做什麼。因此，很抱歉還是不得不懇請您收回那句評語，更何況您對相關條目做出的改善建議，並不需要加上這句多出來的評語也能讓人認同。--Howard61313（留言） 2025年10月14日 (二) 12:17 (UTC)[回复]
@Nostalgiacn：必須強調的是，我(＋)支持並( ✓ )同意您對於此次分類名稱改善的建議，以上對於您冒犯敝人的(－)反对及懇求您收回評語是另一回事，這個部分已經對敝人造成冒犯及困擾，對於您提出此次建議的善意及美意也沒有更多幫助。--Howard61313（留言） 2025年10月19日 (日) 01:38 (UTC)[回复]
「種類」、「類型」、「體裁」等等，其實都可互換，所以很難解決上面所說的「望文生義」問題。頂多就命名確立一種自洽體系吧，沒法再多。至於「各」，更多是為了統一需要，畢竟有些主詞用法也難予捨去。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月3日 (五) 07:44 (UTC)[回复]
這是無奈之舉，儘管中文兩個概念差別不大，但是強制不同，如type（種類）和genre（類型），起碼能走下去。現在「各類型分類」（type）「各类型分类」（genre）是最混亂的狀態，錯了七年都湊合著用，除了證明中文的熵遠高於英文，還說明兩者可能不分也沒問題。合併兩者，走中維特殊路線未嘗不可，但是以傳統上參考英維建分類的習慣，後續新建分類，對不了解的人會造成混亂。--Nostalgiacn（留言） 2025年10月5日 (日) 02:52 (UTC)[回复]
看中心语会比较好理解，其实是两条线：
这样就有个让人一下摸不着头脑的地方——「Category:讽刺小说」的主条目不是同名的「讽刺小说」，而是「讽刺小说列表」--𝙵𝚘𝚛 𝙴𝚊𝚌𝚑 ... 𝙽𝚎𝚡𝚝 2025年10月3日 (五) 16:08 (UTC)[回复]
以Category:讽刺小说为例，这个分类的定义不明确。他是收录「讽刺小说」这个分类概念，还是收录作品实例？如果是前者，什么讽刺小说作家、讽刺小说编年史、讽刺小说改编漫画，只管建子分类往里招呼；如果是后者，原则上连「讽刺小说」这个条目都不应该放进去（实践中一般是排序字设成*，表示属性不同的强关联项目）。现在分类朝末端走了第一条线，向上级走又和第二条线揉到一起了😂--𝙵𝚘𝚛 𝙴𝚊𝚌𝚑 ... 𝙽𝚎𝚡𝚝 2025年10月3日 (五) 16:22 (UTC)[回复]
理論上可以單開一個「諷刺小說作品」吧？當然很多時候都分在一起，本身也沒什麼大不了。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月3日 (五) 18:00 (UTC)[回复]


目前給出方案是type（種類）和genre（類型），之後所有子分類在核對是否有混淆之後，統一以type（種類）和genre（類型）命名，以用字上區分，避免歧義，有需要時，如Category:各類型電影和Category:各種類電影般在兩個分類都作出簡要說明。禁止「各類XX」等模棱兩可的命名。

  • 各種類分類
    • 各種類XX / XX種類
  • 類型
    • 各類型分類
      • 各類型XX
    • XX類型

至於「各類型XX（作品）」和「XX類型（術語）」（genre）的問題，平級分類，放置在更高一級的Category:類型。如有時間，請看附屬條目是否有混淆，如時裝劇的分類應當是「電影類型」而不是「各類型電影」。有需要時，也請在兩個分類都作出簡要說明。

type（種類）的分類，是同時存放作品和術語，如Category:各类图书、Category:專輯種類。這個可以斟酌是否統一為「各種類XX」或者「XX種類」。--Nostalgiacn（留言） 2025年10月6日 (一) 08:58 (UTC)[回复]

“类型”已经在现代汉语被滥用了，如果要区别，真是最好彻底别用了。en:Genre对应的中文条目今年年初被移动到藝術體裁，这也许还是更易于识别的选择；电影类型等命名基本没列有可靠的中文来源，都还要打问号。另外我认为如果分类其实是容器分类，其实后缀都可以加一个“分类”，“各类型小说分类”好于“各类型小说”；当然，我还是倾向于“各艺术体裁小说分类”。--PexEric 2025年10月6日 (一) 13:01 (UTC) 👍1[回复]
我也倾向让genre使用体裁这种更具体的翻译，至少不至于让后续编者继续望文生义，而「种类」和「类型」在语义上就很容易让新手产生混淆--重庆轨交18（留言） 2025年10月6日 (一) 13:41 (UTC)[回复]
感觉那个「各」已经是抽象基类容器分类的意思了，约定好需要替换成具体的名词，才能变成普通分类？--𝙵𝚘𝚛 𝙴𝚊𝚌𝚑 ... 𝙽𝚎𝚡𝚝 2025年10月6日 (一) 18:21 (UTC)[回复]
來源想找是找到的，电影类型:作为惯例和经验的系统(2004年)。本來就是兩可，使用中變得模糊。
不認同genre（類型）的譯名。另一側type（種類）是認同嗎。
Category:流派不能用了，已經有分類佔坑了。--Nostalgiacn（留言） 2025年10月7日 (二) 04:01 (UTC)[回复]
搜寻了一下，看来genre译作类型还是更常见😂。type译作种类没有意见。--PexEric 2025年10月7日 (二) 06:45 (UTC)[回复]

感觉如果不嫌长，直接「作品」两个字直接写到分类名称上就不会混淆，比如电影类型、各类型电影作品（「按电影类型划分的作品」形式上最清晰，但会不会有人觉得拧巴😂）；有「各」字的不能放条目。然后构建框架就会很清晰。比如：

第一条线，母分类到子分类，全是对应具体的电影作品：

另一条线，术语、作品都可以有：

两条线的顶层大概是这样，写得比较糙：

不想用「类型」这个词，换别的对应genre就可以了。--𝙵𝚘𝚛 𝙴𝚊𝚌𝚑 ... 𝙽𝚎𝚡𝚝 2025年10月6日 (一) 18:56 (UTC) 👍1[回复]

是的，「按電影類型劃分的作品」太「擰巴」了（如果「擰巴」一詞的意思是「彆扭」的話），而且也不符合WP:CATNAME所說要保持簡潔名稱的目標。--Howard61313（留言） 2025年10月14日 (二) 03:18 (UTC)[回复]

小結

考慮到有一些專有名詞，如詞類，不合適「各種類詞類」（目前是Category:各式詞類）。而「type」也有Category:各種職業的翻譯，「各種」（type）和「各類」（genre）似乎也是一種可選方案。也符合保持简洁的名称要求（WP:CATNAME）

上面提到的「電影類型」（Film Genre）或者說「類型電影」也是一個術語，雖然沒有來源，條目那麼多年沒變，一定是有點道理的，畢竟不是很冷門的東西。這個說法很很早就有：香港電影類型論（香港-1997）、类型电影（大陸-2001），電影類型與類型電影（香港-2005）、何謂「類型電影」？ （台灣-2006）。

𝙵𝚘𝚛 𝙴𝚊𝚌𝚑 ... 𝙽𝚎𝚡𝚝提到的「作品」問題，也是對齊英文大，但是中文熵太高的鍋，可見以下兩個分類：Category:香港電影（Category:Cinema of Hong Kong），Category:香港電影作品（Category:Hong Kong films），各類型電影是「Films by genre」，各種類電影是「Films by type」。Cinema 和films 中文都是「電影」，所以理解上會有誤差。

溯源，其實是因為WP:CATNAME本身就要求保持简洁的名称。沒考慮到實際操作上會出現歧義。結果，就是能看各人的閱讀理解能力了（Wikipedia:互助客栈/条目探讨/存档/2024年11月#修改XXXX年電影之名稱）。--Nostalgiacn（留言） 2025年10月12日 (日) 13:06 (UTC)[回复]

我翻看了《文学术语词典（中英对照）》（影子圖書館），其中202-203頁，提到「它（形式）常被用来仅指文学类型或体裁」（It is often used merely to designate a genre or literary type），217頁有詞條「Genres 文学类型」解释是「术语文学类型源自法语，指文学作品的类型、种类」（A term, French in origin, that denotes tpyes or classes of literature）。再參考我們的「中國風」怎麼唱？ 華語流行音樂之中國意象文類分析和西方“文类”： 观念史与形态史新述，「文类」是「genre」的說法，也可視為「文学类型」的縮寫。@Zhenqinli：基於找到的資料，「各体裁作品」（Works by genre）在學術上不夠準確，也並不合適。如今分類的範圍並不至於文學作品，也有影視作品，考慮到Genres作為一個外來詞，「類型」應該是更準確的翻譯。
参考香港法律的中英條文，tpye也可以翻譯作「類別」（知識產權類別和專利的類別），作為「種類」的備選。--Nostalgiacn（留言） 2025年11月3日 (一) 10:05 (UTC)[回复]

我重寫了文類，在條目中對文類、文體、體裁相關概念做了區分解釋。如果我們不尋求自建一套分類系統，而是延續英文genre分類系統，genre翻譯為「體裁」，可以說是沒了genre一半的含義，不過可以作為子分類（這需要自建分類，另外運作）。雖然「類型」在不同學科的術語有不同翻譯（例如類型系統/type system），但是在文學領域，genre翻譯作「類型」更準確。

如果沒有其他意見補充，我會以「genre」（類型），「type」（種類）處理相關分類。--Nostalgiacn（留言） 2025年11月5日 (三) 08:22 (UTC)[回复]

Zhenqinli的操作

@Zhenqinli：：你最近移動操作Category:各体裁作品（Works by genre）和Category:各体裁分类（Categories by genre）操作，也是造成混亂，子分類都沒處理，而且「Category:各类型艺术家」（Artists by genre），也不能改為「Category:各体裁艺术家」吧。「Category:各类作家」（Writers by genre）也是。請修改時，考慮一致性。--Nostalgiacn（留言） 2025年10月26日 (日) 15:27 (UTC)[回复]

当初改分类为Category:各体裁分类 是为了与更广义容器Category:各类型分类 相区分。如您愿意，将Category:各体裁作品 改为 Category:各体裁或类型作品 或 Category:各体裁或类别作品 也可以。--Zhenqinli（留言） 2025年11月3日 (一) 14:19 (UTC)[回复]
就算以保持原樣而言，「Categories by type」在2018年之前都是「依種類來作的分類」，要改也應該改為「各種類分類」，genre繼續使用類型作分類更符合學術用法。
承上文提到文學批評，西方概念翻譯，體裁在作品範疇更對應的應該是「type」而非「genre」。就算按照中文，根據學者顏崑陽《「文體」與「文類」的涵義及其關係》（[53]）一文，提到「文體」（文類體裁）與「文類」（文章類型）有不少學者都混為一談，但是實際上有差異。「體製」當指文體之「形構」。「「文體」指涉的是諸多文章群「自身」在「形構」 與「樣態」這些面向的相似特徵；而「文類」指涉的是諸多具 有某些相似特徵的文章因而形成「類聚」相對「群分」的狀態。和西方文學批評差不多，「形構」（體製）只是「文類」其中一個特點，並不是全部。
簡而言之，在作品範疇，類型包括體裁，但是體裁不等於類型。--Nostalgiacn（留言） 2025年11月4日 (二) 03:55 (UTC)[回复]
@Nostalgiacn：要移回嗎？還是怎麼處理？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月6日 (四) 05:21 (UTC)[回复]
我在等WP:7DAYS，Categories by type會改成「各種類分類」，待所有子分類改名後，再處理genre的分類。目前Categories by type和Categories by genre中維分類有不少內容混淆。
為了避免與其他術語造成歧義，主分類Category:Genres，我會改為「Category:藝術類型」，子分類延續之前的各類型XX、xx類型的寫法。--Nostalgiacn（留言） 2025年11月6日 (四) 07:27 (UTC)[回复]

对中国境内高速公路的移动请求

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

本主題或以下段落文字，移動自Talk:京哈高速公路。执行者：TransportationMEE（留言） 2025年10月2日 (四) 17:09 (UTC)。移动理由：牵涉到多个条目的整体命名，采纳@Iokseng的建议。[回复]

“京哈高速公路” → “京哈高速”：这是对中国大陆所有高速公路的移动请求，时间限制就不一一提出了。
中国大陆的高速公路的名称基本都是AA-BB高速公路，简称AB高速，“AB高速公路”用简称加四个字，不是原创研究吗？而且似乎11年前就有人提出这个问题了。--TransportationMEE（留言） 2025年9月30日 (二) 07:45 (UTC)[回复]

不過當年下方也有不同意見。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月1日 (三) 01:49 (UTC)[回复]
這牽涉到多個條目的整體命名，建議移到互助客棧討論。--Iokseng（留言） 2025年10月2日 (四) 01:07 (UTC)[回复]
感谢建议，已移动。--TransportationMEE（留言） 2025年10月2日 (四) 17:04 (UTC)[回复]
@Siyuwj 该用户最近活跃，ping一下看看ta的意见。--TransportationMEE（留言） 2025年10月2日 (四) 17:06 (UTC)[回复]
"京哈高速" site:gov.cn结果可见很多官方文稿也称“京哈高速公路”。虽然“xx高速”是常用名称、正式简称（s:JTG_A03-2007_国家高速公路网命名和编号规则），但“xx高速公路”也是易于识别的一个常用名称吧，相比没有“公路”二字，至少读者更容易知道该实体的属性（而不是铁路、列车或别的东西）。“xx至xx高速公路”则是完整名称（例子）。所以这不是原创研究，只是不太符合（未被涵盖于）那份“命名和编号规则”。另外，新华社和央视也会这样说[54][55]。--YFdyh000（留言） 2025年10月2日 (四) 21:49 (UTC)[回复]
这么看确实不是原创研究。但论常用程度仍然远不及“京哈高速”。--TransportationMEE（留言） 2025年10月3日 (五) 05:42 (UTC)[回复]
不太認同這種縮減行為，反而認為應當使用全名，某某高速公路，以便維持與其他地區的高速公路命名大體一致。--owennson（聊天室、獎座櫃） 2025年10月3日 (五) 01:11 (UTC)[回复]
真正的全名是“北京—哈尔滨高速公路”。另外与其他地区命名一致是不必要的，香港的公路系统都用数字的。--TransportationMEE（留言） 2025年10月3日 (五) 05:44 (UTC)[回复]
那我寧可用XX—YY高速公路。多的是地方用某某高速公路命名，比如M25高速公路。--owennson（聊天室、獎座櫃） 2025年10月3日 (五) 07:26 (UTC)[回复]
确实不伦不类，改成“AA—BB高速公路”的全名为宜。--PexEric 2025年10月3日 (五) 05:48 (UTC)[回复]
附议。--Hamish T 2025年10月4日 (六) 13:14 (UTC)[回复]
附议。--Kcx36（留言） 2025年10月7日 (二) 16:51 (UTC)[回复]

根据目前的状况来看，共识是使用“北京—哈尔滨高速公路”这样的全称。那么我们怎么执行呢？是人工处理还是使用机器人？这段讨论应当存档至哪里？--TransportationMEE（留言） 2025年10月7日 (二) 09:21 (UTC)[回复]

建議先統計頁面清單。此一討論可歸檔於公路專題或中國專題。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月7日 (二) 11:09 (UTC)[回复]
Category:中国高速公路可供参考。--TransportationMEE（留言） 2025年10月7日 (二) 17:09 (UTC)[回复]
考虑了一下，感觉存档至Talk:中华人民共和国高速公路似乎更恰当。--TransportationMEE（留言） 2025年10月9日 (四) 02:43 (UTC)[回复]
乱存档。条目讨论页是讨论该条目的。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月15日 (三) 05:48 (UTC)[回复]
简单看了一下，太不好处理了……先挂{{不存档}}了。有空我再想想办法吧。--PexEric 2025年10月12日 (日) 14:21 (UTC)[回复]
涉及的条目较多，为了程序上更正当，根据WP:7DAYS的规定，本提案已经“7日内无新留言”且“已取得共识”，现对中国大陆的高速公路条目改用全称作为标题一案 公示7日，2025年10月21日 (二) 16:19 (UTC)結束。公示通过后将适时按照下方的重命名表格移动条目。--Kcx36（留言） 2025年10月14日 (二) 16:19 (UTC)[回复]

见WikiProject:中国交通/高速公路重命名，需要人工审核。@TransportationMEE、YFdyh000、Owennson、Hamish、Kcx36、Ericliu1912。--PexEric 2025年10月12日 (日) 18:23 (UTC)[回复]

人工确认后的名称填到哪里？--Kcx36（留言） 2025年10月12日 (日) 18:26 (UTC)[回复]
划到上面就好了，像这样Special:Diff/89504805/89504902。--PexEric 2025年10月12日 (日) 18:40 (UTC)[回复]
稍微看了一下匹配失敗的，個人認為如果不是JTG A03-2007 国家高速公路网命名和编号规则有明文的，假如現有名稱在找到的名稱n出現，那不動應該也可以，具體沒細看。--Hamish T 2025年10月12日 (日) 18:30 (UTC)[回复]
第一次知道有這專題⋯⋯XD —— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月12日 (日) 18:34 (UTC)[回复]
确实，而且中华人民共和国高速公路页面似乎WikiProject:公路有在管，讨论页也有标注，而且更活跃。--TransportationMEE（留言） 2025年10月15日 (三) 04:45 (UTC)[回复]
我刚刚也搞了个表：User:Kcx36/沙盒50。--Kcx36（留言） 2025年10月12日 (日) 18:37 (UTC) ❤1[回复]
稍微看了看，感觉很多用首字法或简称法可以一眼得出全称，不过根据Talk:杭绍甬高速公路#未提供來源的原創名稱「杭州—绍兴—宁波高速公路」的讨论，似乎我们要给每个全称找到可靠来源。是这样吗？这可能带来不小工作量。--TransportationMEE（留言） 2025年10月15日 (三) 04:40 (UTC)[回复]
特别是在有些高速只是国家高速和省高速中的一段。--TransportationMEE（留言） 2025年10月15日 (三) 04:42 (UTC)[回复]
@自由雨日。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月15日 (三) 06:12 (UTC)[回复]
看了一下，并不是太难。各地有地方标准。诸如“杭绍甬高速公路”之类有争议者，不在移动考虑范围。--PexEric 2025年10月15日 (三) 06:31 (UTC)[回复]
举个例子吧，杭金衢高速公路，是G2504 杭州绕城高速和G60 沪昆高速的一部分，没有独立的编号，因此你很难从国家规划和省级规划中找到它。根据可供查证的信息，该条高速途径杭州、金华、衢州，但在该页面的参考资料里是找不到“杭州—金华—衢州高速公路”这样的字眼的。根据这一个讨论，这会属于原创研究。--TransportationMEE（留言） 2025年10月15日 (三) 14:20 (UTC)[回复]
懂您的意思。不过其实想找还是能找到的[56]，取自09年7月的《浙江省高速公路命名和编号规则》。像这种情况都是后来被延伸并网，民间和媒体保留了之前的简称。--PexEric 2025年10月15日 (三) 14:44 (UTC)[回复]
在各个省高速公路导航模板的右侧白底蓝字的无编号高速路段中可以见到很多例子。--TransportationMEE（留言） 2025年10月15日 (三) 14:25 (UTC)[回复]
各位编者：本提案公示期已结束，未见异议提出。
@PexEric、YFdyh000、Owennson、Hamish、Kcx36、Ericliu1912--TransportationMEE（留言） 2025年10月23日 (四) 12:45 (UTC)[回复]
@PexEric：请问找到的名字是怎么找到的？--Hamish T 2025年10月27日 (一) 04:03 (UTC)[回复]
在条目序言的加粗部分和infobox的名称参数。--PexEric 2025年10月27日 (一) 05:47 (UTC)[回复]
还剩177个条目没有移动（其中部分条目并不需要移动）。--Kcx36（留言） 2025年10月27日 (一) 12:46 (UTC)[回复]
强！膜技术帝orz--PexEric 2025年10月31日 (五) 09:54 (UTC)[回复]

党员的有关分类和翻译的问题

本主題或以下段落文字，在討論結束後應存檔至Category talk:政治人物。

目前相当多党员分类与英语分类的politicians相链接，但很显然这存在一个问题，党员的上级分类最终将是政治人物，也就是politicians，而政治人物里才会细分政治家、党员以及所有政治有关人物。因此将党员与politicians分类链接是不准确的。

初步理清关系后，应将所有的党员/成员与members有关分类链接，政治人物与politicians有关分类链接，被开除/退党的党员因为不再拥有合法的党员身份，因此只作为政党历史上的人物，也不应与members有关分类相链接，而应该加入其上级分类政治人物。

【举例】

  1. 分类:xx党政治人物，etc，与Category:xx Party politicians链接
  2. 分类:xx党党员，etc，与Category:members of xx Party链接（并且放入1. xx党政治人物）
  3. 分类:被开除xx党党籍者，etc，与Category:Expelled members of xx Party链接，（并且放入1. xx党政治人物）

欢迎社群探讨，本人会在获得相关认可意见后再开始进行有关分类的重新链接工作--重庆轨交18（留言） 2025年11月2日 (日) 12:08 (UTC)[回复]

這問題不是之前討論過了嗎？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月2日 (日) 18:29 (UTC)[回复]
另外有關「前」不「前」的問題，人死了都不會再有俗世身分，所以除了開除黨籍可細分，不應予以區別。這之前應該也討論過。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月2日 (日) 18:57 (UTC)[回复]
Ericliu阁下，我是在讨论与wikidata英文链接的问题，不是在讨论是不是前党员的问题😂。——重庆轨交18（留言） 2025年11月2日 (日) 22:48 (UTC)[回复]
不，實際上中文這邊若是有分類命名規範，則不能直接套用英文的邏輯。尤其我記得在「黨員」及「政治人物」分類格式問題上，社群有過結論。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月3日 (一) 07:33 (UTC)[回复]
又話說，分類是取相關程度，偏要擇一，「前黨員」當然還是優先分類到「黨員」裡面去。畢竟要喪失身分，本須先取得。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月3日 (一) 07:35 (UTC)[回复]
是不是也存在从未获得党员身份的人群存在，例如为xx党工作的志工、在xx党的总部工作的非党员？以及一些长期为xx党捐款、支持xx党的非党员，这些应该可以放入xx党的政治人物里，而现存的党员分类显然无法把上述人群全部放入--重庆轨交18（留言） 2025年11月3日 (一) 07:47 (UTC)[回复]
那些都不能算「政治人物」（此處實語近「政客」而非「政治相關人物」）吧？另外是否值得分類也頗值懷疑。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月3日 (一) 15:47 (UTC)[回复]
或许日语版直接用人物更方便，总之党员不适合与politicians链接，前者理论上必须要查证入党的证据，而后者不需要提供党员身份证据而是其他可供查证的信息。秘密党员或者追认党员的，在人物的生平中和公开秘密身份前其实并无党员的身份，类似于名誉教授是否放入学校教职工，名誉市民是否可以放入xx人分类？如果有更合适的上级分类就可以，但是没有更合适的上级分类，迟早也让后续的编者发现问题继续开始讨论。
一言蔽之，例如宋庆龄的生平无论添加什么党员，前党员，秘密党员等分类，都不如直接添加中国共产党政治人物的分类最方便最贴切——重庆轨交18（留言） 2025年11月3日 (一) 21:10 (UTC)[回复]

詢問希尔达、藍髮女孩進城記、希爾達 (人名)如何消歧义？

本主題或以下段落文字，在討論結束後應存檔至Talk:希尔达 (消歧义)、Talk:Hilda。

@BigBullfrog：各位好，我是希爾達 (人名)和Hilda的作者。我在檢視「希尔达」的相關條目時，發現這詞條會導引至一德國小鎮。我這邊看得很困惑，所以想弄好消歧义。但是我有想要請教的地方：

首先，根據「希尔达」的瀏覽數量，人名與城鎮蠻接近的，但作為作品、中國譯為「希尔达」的《藍髮女孩進城記》則高於人名與城鎮。Google搜索紀錄方面，則是作品多於人名多於城鎮（"希尔达"、"希爾達"+-site%3Awikipedia.org "希爾達"）。這讓命名很困難：雖然作為作品的《藍髮女孩進城記》由於標題不同，所以可以排除在命名問題之外，但人名與城鎮我很不確定。

接著，命名常規的「先到先得」方針似乎和消歧义方針，尤其是裡面的「另外建立消歧義頁」章節有矛盾：如果按照命名常規的「先到先得」方針，我不應該移動目前的城鎮條目，而是在該條目直接寫消歧义、或導引到獨立的消歧義頁面；但如果是按照消歧义方針，基於前述的觀看數據和搜索紀錄，我似乎應該把「希尔达」導引至《藍髮女孩進城記》，或起碼建立消歧義頁。但這兩個方針看起來很矛盾，我無所適從，所以只好來這邊問如何消歧義？

至於Hilda，如果前面的問題能解決，這個消歧義的問題應該也會解決。--Saimmx（留言） 2025年11月4日 (二) 14:31 (UTC)[回复]

已处理。--BigBullfrog（𓆏） 2025年11月7日 (五) 12:10 (UTC)[回复]
感謝BigBullfrog關注該問題並予以解決。本人發現您似乎選擇重定向「希爾達」至「藍髮女孩進城記」，請問您是透過哪個方針，認為重定向比維持現狀更合適？您在Special:Diff/89849480說要「让位」，但為什麼不是方針的「先到先得」勝過「让位」？
我不是質疑您的選擇，事實上我覺得這可能就是我會做的移動，但我感覺自己無法掌握命名常規方針，找不出能這麼做的理由，又發現很難忽略該方針，所以不敢移動，所以希望您說明。--Saimmx（留言） 2025年11月7日 (五) 13:57 (UTC)[回复]
我也不是特别懂命名常规，我是凭过往经验和感觉而作的。如果确实是“希尔达”多指这部作品的话，甚至是多过该城镇几个数量级，那就该让位。--BigBullfrog（𓆏） 2025年11月7日 (五) 14:03 (UTC)[回复]
感謝提供意見。--Saimmx（留言） 2025年11月7日 (五) 14:09 (UTC)[回复]

藝人條目網絡節目、電台節目、音樂節目(甚至於演唱會)是否應一視同仁按照娛樂產業內容相關共識處理?

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:娛樂產業內容相關共識。

如標題，現時娛樂產業內容相關共識僅限制綜藝節目不應在藝人（及相關獨立列表）條目羅列非班底綜藝節目之列表。但網絡節目、電台節目、音樂節目暫時未有限制，如BOYNEXTDOOR影視作品列表，因此想向大家詢問意見。而且演唱會嘉賓是否亦應該一視同仁，因為大多數演唱會嘉賓亦沒有可靠的獨立來源，維基百科:維基百科不是什麼以及維基百科不是新聞報道，過度統計清單降低條目的可讀性和整潔以及應該只有符合收錄標準的事件或讀者可能感興趣的內容才值得納入。--Wongan4614（留言） 2025年11月5日 (三) 02:15 (UTC)[回复]

WP:ENTVAR的定义句是“综艺节目”，并没有电视与否的前缀，网络节目、电台节目（具体形式具体分析，例如广播剧那种就不算在内）大体上是一视同仁的（在下此前对于不少条目亦作同类处理，如最近的I.O.I影視作品列表），不会是没有限制，相信这一点不必重新讨论——除非诸位有意推倒ENTVAR重来。一般情况下只是上去表演打歌的音乐节目也不例外。演唱会嘉宾是哪一种状况，能否请阁下举例？列表条目所属表演者在自己的列表收录到别人演唱会的嘉宾纪录吗？还是列表条目所属表演者在自己的条目收录别人来自己演唱会当嘉宾的纪录？--银色雪莉（留言） 2025年11月5日 (三) 02:32 (UTC)[回复]
例子如：羅啟豪的演唱會及其他活動，當中其他活動的數量超過二十項，而當中演唱會及其他活動即使有來源亦僅有一兩句。--Wongan4614（留言） 2025年11月5日 (三) 03:07 (UTC)[回复]
本人的演唱会不会有问题。（点列式的）去别人的演唱会做嘉宾这种我个人认为照NOT就可以移除，不应该有什么争议。至于说像一些拼盘演唱会（或拼盘节目，例如文艺晚会或文艺汇演或筹款节目）往往众说纷纭，我不预期会有讨论结果。--银色雪莉（留言） 2025年11月5日 (三) 04:18 (UTC)[回复]
我覺得有時候還是可以放這些東西，並沒有那麼的細膩，反正有時候維基百科變得很空洞，會覺得這樣真的是好的嗎？--Louischen88888（留言） 2025年11月5日 (三) 04:20 (UTC)[回复]
恕我不太清楚您指的“这些东西”是哪些东西。--银色雪莉（留言） 2025年11月5日 (三) 04:26 (UTC)[回复]
拼盤演唱會我覺得是可以和WP:ENTVAR一樣移除，因為本身「若因參與節目而引起對人物事件的關注（如爭議），應當以摘要格式寫進條目內文中。」，放在拼盤演唱會（可能包括去別人的演唱會做嘉賓）同理，若嘉賓而引起對人物事件的關注（如爭議），應當以摘要格式寫進條目內文中，如陳蕾演唱會2024《念》中邀請了被批評後首個公開活動的魏念恩，魏念恩（如有條目）該段就可放到條目，但放在爭議或內文中。--Wongan4614（留言） 2025年11月5日 (三) 04:41 (UTC)[回复]
我是覺得的確在綜藝節目或者是嘉賓等等的不能收錄，但如果有來源可以改用內文的方式來補充，不過我在拼盤演唱會的部分不太同意，賺
傳主是主角，只是這個活動有多個主角而已。--Louischen88888（留言） 2025年11月5日 (三) 04:56 (UTC)[回复]
支持，嘉賓出演可移除，雖然這樣我找資料會變麻煩，但此類內容意義不明且缺乏更新。--Louischen88888（留言） 2025年11月5日 (三) 03:52 (UTC)[回复]
綜藝節目也包含網絡節目等。但在於音樂節目的部分我持反對看法，因為已經是主持，就算只是當週特別主持也應予收錄。--Louischen88888（留言） 2025年11月5日 (三) 03:59 (UTC)[回复]
當週特別主持我覺得有點模稜兩可，這個位置要再討論--Wongan4614（留言） 2025年11月5日 (三) 04:11 (UTC)[回复]
BIGBANG影視作品列表我不知道怎麼處理，大家可以一起討論。--Louischen88888（留言） 2025年11月5日 (三) 04:06 (UTC)[回复]
對了借問一下，在歌曲條目整理打歌舞台是可以的嗎？--Louischen88888（留言） 2025年11月5日 (三) 04:07 (UTC)[回复]
我覺得做法應同藝人條目一樣，即如沒有可靠來源不應加入到條目，且不應獨立列表。--Wongan4614（留言） 2025年11月5日 (三) 04:14 (UTC)[回复]
不獨立要怎麼處理--Louischen88888（留言） 2025年11月5日 (三) 04:21 (UTC)[回复]
WP:ENTVAR，若因參與節目而引起對人物事件的關注（如爭議），應當以摘要格式寫進條目內文中。--Wongan4614（留言） 2025年11月5日 (三) 04:23 (UTC)[回复]
不過我覺得按照目前的慣例，設一個表格，並清楚註明哪一天，哪一個節目，官方影片應該還是可以收錄。--Louischen88888（留言） 2025年11月5日 (三) 04:24 (UTC)[回复]
一些多集的、長期播出的電台節目及網絡節目，( ✓ )同意按照類似情況的綜藝節目共識處理。當然，如當中涉及能補充生平的專訪，則應以來源或註的形式展示。一如往年的討論，我(－)反对一次性節目、音樂會需要設此限制。--Factrecordor（留言） 2025年11月5日 (三) 12:38 (UTC)[回复]
照現行的方針文字，應更偏向在一次性節目、音樂會未符合收錄標準(更嚴格些需建有獨立條目)下仍應移除對應資訊。WP:NOT"不是名人生活的方方面面、個人細節，每一場比賽、進球、或揮手都有足夠意義寫進人物傳記內，只有符合收錄標準的事件或讀者可能感興趣的內容才值得納入。"
  • 惟如果將"讀者可能感興趣作為但書"保留資訊時，仍需要符合WP:NOT"條目內容須可供查證，亦應附有來源，而其篇幅則應按合理比重分配。"
--Rastinition（留言） 2025年11月5日 (三) 12:49 (UTC)[回复]
一次性節目、音樂會應按照維基百科:娛樂產業內容相關共識相同處理，即若因參與非固定參與的節目而引起對人物事件的關注（如爭議），應當以摘要格式寫進條目內文中。--Wongan4614（留言） 2025年11月6日 (四) 01:15 (UTC)[回复]
(－)反对，一個綜藝節目固定班底的人數也可以不少，音樂會難以定義誰是固定班底。強烈(！)抗议Rastinition的理由，一個藝人參加音樂會是其事業，怎能與名人去揮手相題並論? 提議特別注明開球禮之類不收錄就成。--Underconstruction00（留言） 2025年11月6日 (四) 02:16 (UTC)[回复]
我同意有關說法，但我參照娛樂產業內容相關共識有一個提議條文：
該藝人為主角的演唱會：若演唱會本身符合收錄標準並存在條目，則直接連結節目條目即可。若節目本身可能符合收錄標準但未有建立條目，或並未符合收錄標準要求，則應當可靠來源佐證演唱會的日期。
非該藝人為主角的演唱會（即為嘉賓），則屬於瑣碎資訊，同綜藝節目，歌手或藝人可能會透過大量參與演唱會而獲取曝光，且並不對於有關人物構成足夠的影響或重要性從而被寫進條目中。若因參與演唱會而引起對人物事件的關注（如爭議），應當以摘要格式寫進條目內文中。--Wongan4614（留言） 2025年11月6日 (四) 02:27 (UTC)[回复]
"可能會透過大量參與____而獲取曝光"這一句其實有問題，翻看那個共識，最初的想法似是台灣那種專跑綜藝節目的通告藝人，這不是所有地區演藝圈都有的生態，參加音樂會也不是這種生態。下有"很多情況下都未必能有參與節目本身的影片以外的多條可靠來源支持"，其實綜藝嘉賓有不少報導，甚至乎是報導的重點，對台灣專跑綜藝節目的通告藝人，報導量對比出席密度應會很低，但其他真有其他主業的藝人就不一定。而你的演唱會草擬沒有這一句，是不是也察覺說不過去?--Underconstruction00（留言） 2025年11月6日 (四) 03:01 (UTC)[回复]
非也，這個香港也存在有關情況，可以參照李佳 (香港)，就如你所說的一樣，李佳存在大量作為表演嘉賓，但報導量對比出席密度對比很低--Wongan4614（留言） 2025年11月6日 (四) 03:13 (UTC)[回复]
還不如限制在音樂會當嘉賓需有獨立第三方可靠來源，比較公平。原本共識既說"很多情況下都未必能有參與節目本身的影片以外的多條可靠來源支持"，根本就該以此來畫界。--Underconstruction00（留言） 2025年11月6日 (四) 03:41 (UTC)[回复]
這個我覺得可以，但我始終覺得亦應該以摘要格式寫進條目內文中，因為如果音樂會擔任嘉賓而同時有獨立第三方可靠來源，即是有一些內容可以寫進條目內文，否則亦不會有來源。--Wongan4614（留言） 2025年11月6日 (四) 03:49 (UTC)[回复]
不清楚你內文的意思，必須散文? 我認為不用硬性規定。整合在一塊的話，是散文還是列表，前陣就見到有草案寫參考MOS:LIST WP:WORKS按情況而定。如果不專門整合在一塊，插進那些生平何年何月做甚麼(大量藝人條目就是這樣子)，更加差。--Underconstruction00（留言） 2025年11月6日 (四) 06:45 (UTC)[回复]
簡單一點就是，如果音樂會嘉賓因事件有獨立第三方可靠來源，即是音樂會不是重點，所以放在經歷/爭議以散文解釋即可。
反之，如果音樂會嘉賓本身就沒有獨立第三方可靠來源，代表該次擔任嘉賓並沒有讀者可能感興趣的內容，因此不應加入到內容。--Wongan4614（留言） 2025年11月6日 (四) 09:57 (UTC)[回复]
我說了，寫在經歷，逐一插進那些平何年何月做甚麼，不是好的格式。--Underconstruction00（留言） 2025年11月7日 (五) 07:13 (UTC)[回复]
那麼如何才是好的格式？沒有人說要「逐一插進那些平何年何月做甚麼」，請參考2022年11月時的討論，有人提出維基採WP:摘要格式，並且「好的條目實際上是各章各段都很精要，更細節但重要的東西拆出子條目來寫，（對主條目過細，但對子條目來說不是過細而是精要），而同樣細節但不重要的東西就不該寫」，所以以散文解釋並非指全寫入條目，而是把內容摘要。如果把音樂會擔任嘉賓全放進列表只會過長。--Wongan4614（留言） 2025年11月10日 (一) 06:58 (UTC)[回复]
@Underconstruction00當時方針原文的定稿我沒有參與，你嚴重抗議方針文字的用法我可以理解，但你的陳述並未將如果將"讀者可能感興趣作為但書"保留資訊時，仍需要符合WP:NOT"條目內容須可供查證，亦應附有來源，而其篇幅則應按合理比重分配。"考量。所以我認知到你回覆給我的文字無效。而Wikipedia:互助客栈/条目探讨#c-Wongan4614-20251106022700-Underconstruction00-20251106021600這個意見的發佈者有考量到這個意見。僅做為額外(～)補充。另(＊)提醒冷靜，思考遭遇非冷靜狀態會失真負片化。--Rastinition（留言） 2025年11月6日 (四) 10:12 (UTC)[回复]
"讀者可能感興趣作為但書"是甚麼意思???--Underconstruction00（留言） 2025年11月6日 (四) 10:29 (UTC)[回复]
"如果將讀者可能感興趣作為但書"的"在輸入時放錯位置--Rastinition（留言） 2025年11月6日 (四) 10:33 (UTC)[回复]

公共廣播的節目中，非長期節目的數量並不如長期綜藝節目那樣多。而針對例如李佳的情況，應先限制記者會與宣傳活動。

故此，建議在電視或電台廣播頻道播出的非長期節目可收錄，在未經廣播的活動中擔任表演嘉賓則必須具有非一手可靠來源介紹，才可收錄。記者會、宣傳活動，及非以表演嘉賓性質出席的活動不論廣播或有來源與否，則都不應收錄。--Will629（留言） 2025年11月8日 (六) 07:52 (UTC)[回复]

(－)反对：如果非長期節目的數量並不如長期綜藝節目那樣多就可以放進條目，那麼是否可以類比到所有內容？維基百科不是名人八卦和日記，過去的電視或電台廣播頻道播出的非長期節目是否讀者可能感興趣的內容？
我認為即使過去的電視或電台廣播頻道播出的非長期節目，也最少要有可靠來源才可收錄到條目。
記者會、宣傳活動，及非以表演嘉賓性質出席的活動，如果因參與活動而引起對人物事件的關注（如爭議），應當以摘要格式寫進條目內文中。
以表演嘉賓性質出席則我認為要同記者會、宣傳活動，及非以表演嘉賓性質出席的活動相同處理，因為必須要有讀者可能感興趣的內容。--Wongan4614（留言） 2025年11月10日 (一) 08:43 (UTC)[回复]

宗教信仰为共产主义

注意到有部分条目将人物的宗教信仰设置为共产主义，然共产主义不属于宗教，是否应当一律删减。--Luoniya（留言） 2025年11月6日 (四) 11:27 (UTC)[回复]

「宗教信仰」（x），「宗教／信仰」（o）？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月6日 (四) 12:14 (UTC)[回复]
信仰确实可行，但是没见过这一栏填共产主义的，共产主义人物一般没有这一栏，或者填无神论--Luoniya（留言） 2025年11月7日 (五) 02:19 (UTC)[回复]

《孝女彩金》电影是否有足够的知名度成为条目

如题，如果符合知名度收录标准我再起草条目。--Lory H.（V • T • C）吹滅別人的燈，並不會讓自己更加光明。 2025年11月6日 (四) 13:21 (UTC)[回复]

看了下相关来源，主题本身符合收录标准——不过请在条目中利用来源以彰显其符合收录标准。另，知名度不是收录标准。--银色雪莉（留言） 2025年11月6日 (四) 13:59 (UTC)[回复]

民國時期將領劉多荃後人的內容可疑

本主題或以下段落文字，在討論結束後應存檔至Talk:劉多荃、Talk:劉全禮、Talk:喇沙書院校友列表。

本在跟進喇沙書院校友列表，發現IP用戶疑於幾個條目滲入可疑的原創研究或惡作劇內容。 現時版本的劉多荃#家庭主要由IP 211.75.206.X改寫，先是在2020年時Special:Contributions/211.75.206.3加入孫劉繼武等資料[57]，然而到了2022年5月同一IP將兩年前改頭換面，改為長子劉全禮、次子劉全華等，原來的孫劉繼武等多被刪去，並留言家屬提供資料，可注意當時劉全禮條目並未建立。同年11月Special:Contributions/211.75.206.8及翌年1月Special:Contributions/211.75.206.2先後修改內容，加入侄子劉全國，4分鐘就言出錯自行回退。但是這個劉全國及次子劉全華，都稱是香港喇沙書院的校友，被這些IP添加至喇沙書院校友列表，劉全國更有著名紅色間諜的浮誇描述，卻搜不到什麼線索，這些IP還在黃埔軍校同學會加入他曾任副會長，中国人民解放军陆军合成第一一五旅加入他曾任指揮官。而劉全禮條目則是2022年11月16日由@仁者945建立，最初版本已指為劉多荃長子，條目有可靠來源佐證這點[58]，所以IP寫的東西有正確之處，也許仁者945君當時是因此IP對劉多荃的編輯，作出追查。--Factrecordor（留言） 2025年11月6日 (四) 13:33 (UTC)[回复]

近代史及軍事不是我的專長，請其他熟悉的維基人跟進。--Factrecordor（留言） 2025年11月6日 (四) 13:38 (UTC)[回复]
更正，將劉全華加入喇沙書院校友列表，是後來活躍編輯劉多荃的@Bkgnfhf911在2023年所做，當時劉多荃條目已有劉全華是喇沙校友的內容。--Factrecordor（留言） 2025年11月6日 (四) 13:57 (UTC)[回复]
喇沙書院校友列表對劉全國的描述中，紅色間諜與黃埔軍校十九期都是劉全禮的特徵。我認為IP用戶未必是存心偽造內容，他可能是得到一些間接的線索、碎片化的資料（其口中的劉多荃家屬），從中自行拼湊及推斷。--Factrecordor（留言） 2025年11月7日 (五) 16:18 (UTC)[回复]

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

本主題或以下段落文字，在討論結束後應存檔至Talk:江北区 (重庆市)、Talk:渝北区、Talk:北碚区、Talk:两江新区。

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

感到困惑，目前重庆的两江新区究竟在运作吗，还是算已成立行政区但未投入运作？有部分车站与机场条目中我已变更具体地址为两江新区，若不妥也可以先调回旧版本...--1969社论（留言） 2025年11月7日 (五) 04:58 (UTC)[回复]
两江新区本就是经济特区，这次只不过将其类似于浦东新区，直接承担行政区职能，所以运转起来应当是很快的。且没有必要变更地址，因为就算没实际运转，其很快就会有该地址--Luoniya（留言） 2025年11月7日 (五) 05:27 (UTC)[回复]
跟当年滨海新区一样，都是先从经济区升格为行政区。只是感觉手续还没办完..现在只是先官宣了。两江新区的行政区划代码，下属机构等等都还没有呢。在我看来这些已经改了的条目就不用动了，没改的可以再放放（反正早晚都是要改），不知还有无其他意见？--1969社论（留言） 2025年11月7日 (五) 05:45 (UTC)[回复]
根据有关政策和规定，仅有在重庆市人大开会通过决议后才能运作，否则还是承担管委会职能。@1969社论@Luoniya--DaqibaoQi（留言） 2025年11月7日 (五) 07:25 (UTC)[回复]
参见国务院关于同意重庆市调整部分行政区划的批复 (2025年11月)，根据重庆政府的11月6号的新闻稿和上周在社交媒体流传的文件照片看，这个国务院批文应该已经先行发布至少一周了，虽然我暂时还没在网络上找到原文全文，但不需要等到两江新区人民政府挂牌仪式，作为市辖区的两江新区已经是事实上存在了。——重庆轨交18（留言） 2025年11月8日 (六) 07:42 (UTC)[回复]
事实上，仍需等待重庆市人大做出下一步动作。--DaqibaoQi（留言） 2025年11月9日 (日) 00:27 (UTC)[回复]

条目北京地铁平谷线更改为北京地铁22号线

本主題或以下段落文字，在討論結束後應存檔至Talk:北京地铁平谷线。

副中心站已掛牌22号线，应更改--~2025-32433-81（留言） 2025年11月10日 (一) 04:12 (UTC)[回复]

建议等线路正式开通后，再移动页面--Luoniya（留言） 2025年11月10日 (一) 04:18 (UTC)[回复]

其他

2025年10月管理人员选举

本主題或以下段落文字，已移動至Wikipedia talk:申请成为管理人员/存档11。执行者：Eric Liu 創造は生命（留言・留名・學生會） 2025年10月31日 (五) 21:00 (UTC)。[回复]

提议修改滥用过滤器封禁临时账号的设置

本主題或以下段落文字，已移動至Wikipedia:防滥用过滤器/过滤器请求/存档/2025年。执行者：Eric Liu 創造は生命（留言・留名・學生會） 2025年11月3日 (一) 11:43 (UTC)。[回复]

👍1

管理操作覆核請求：对于UjuiUjuMandan的封禁

本主題或以下段落文字，已移動至Wikipedia:管理操作覆核請求/存檔。执行者：Eric Liu 創造は生命（留言・留名・學生會） 2025年11月9日 (日) 15:12 (UTC)。[回复]

控制管理員佈告板的臨時使用者留言

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:管理员布告板/其他不当行为。

幾天前我發現Special:固定链接/89530635#WiiUf，這一提報明顯屬於擾亂性質，既往IP用戶和臨時用戶在該佈告板已經多次在該頁面显而易见的扰乱，紅渡厨在被封禁前曾經提過此問題。

我参考日文维基百科对IP用户在ja:WP:Wikipedia:投稿ブロック依頼的情況，提議考慮

  1. 禁止IP使用者、臨時使用者在WP:ANM再發起新的提報
  2. 保留IP使用者、臨時使用者在WP:ANM評論、回應的權利

請各位集思廣益提供一些見解。至於技術方面，此或可使用過濾器過濾指定的模板達成。 @PÑēüḾôňïę1357、Jackyming：---Lemonaka 2025年10月15日 (三) 02:32 (UTC)[回复]

注意，上次討論的結論于 Wikipedia talk:管理员布告板/其他不当行为#关于IP用户在管理员布告板的提报--Lemonaka 2025年10月15日 (三) 02:35 (UTC)[回复]
@Hotaru Natsumi -Lemonaka 2025年10月15日 (三) 02:35 (UTC)[回复]
(－)傾向反對。如果不让他们去WP:ANM，问题大概率会被带到客栈来发。相比于WP:VIP，ANM被破坏的压力较小，回退纯粹的破坏及让管理员关闭讨论就能应付（吧）？
况且我认为对VIP的半保护影响了新用户以及其他维基用户在本地报告破坏，若可行应当改用过滤器，以便细化条件。--Srapoj（留言） 2025年10月15日 (三) 02:52 (UTC)[回复]
(＋)贊成。📕📙📒📗📘賭博機構最堅定的反對者強烈要求馬上刪除一切含有賭博網站的編輯摘要！ 2025年10月15日 (三) 03:20 (UTC)[回复]
(＋)支持---VAMPIRE!VAMPIRE! All Hands Brace For Shock!Birds Away. Missile intercepted（留言） 2025年10月15日 (三) 09:18 (UTC)[回复]
(－)反对：同此处发言，此外红渡厨的问题我会理解为更多在说他对针对他的、反复的不合理提报感到厌烦，而不是广义的ANM的非自动确认扰乱问题。我仍然认为不应当剥夺临时用户在ANM寻求管理员调停的权利。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2025年10月15日 (三) 16:20 (UTC)[回复]
(－)反对已檢查近一個月的臨時使用者提報，發現擾亂情況不大需要禁止臨時使用者提報，另外也發現多個臨時使用者的提報的確都有給予封禁或警告，貿然禁止可能會影響到為數不多的提報途徑。--雨朝Talk#我要成為神 2025年10月16日 (四) 00:08 (UTC)[回复]
(＋)支持 版本差異--Jackyming（留言・貢獻・這位編輯者是一位奶味藍🤩) 2025年10月17日 (五) 15:02 (UTC)[回复]
你這是亂入？上面在討論臨時用戶，你這個是註冊用戶欸。--路西法人 2025年10月20日 (一) 03:25 (UTC)[回复]
(－)反对，(▲)同上，破坏ANM的压力较小，而且如果要是IP用户真想举报，但是看到不允许举报情绪会很不好。--Martin 去我的签名簿签名！！ 2025年10月19日 (日) 02:14 (UTC)[回复]
花5分鐘開個帳戶不就行了嗎？開個帳戶就不再是臨時用戶了。📕📙📒📗📘賭博機構最堅定的反對者強烈要求馬上刪除一切含有賭博網站的編輯摘要！ 2025年10月23日 (四) 21:49 (UTC)[回复]
部分地方可能存在技術問題而不能如此或如此後無法立即正常使用。Sanmosa 新朝雅政 2025年10月24日 (五) 06:53 (UTC)[回复]
我其实一直不同意IP用户编辑，但是如果让他们编辑，那么就把他们当普通用户看。--Martin 去我的签名簿签名！！ 2025年10月25日 (六) 19:14 (UTC)[回复]
(－)反对:明确反对全面禁止IP用户和临时用户在ANM发起新提报。大部分临时用户的提报扰乱情况不严重，违规行为多由管理员及时处理（封禁或警告）。全面禁止会“一刀切”，容易剥夺正常用户的正当报错渠道。若禁止，他们要么就对不当行为视而不见，要么就可能转向客栈或其他页面发起投诉，反而增加管理难度。建议采取针对性措施：对重复扰乱或明显违规的个别用户使用过滤器或模板限制，而非全局封锁。同时保留临时用户评论、回应及正当提报的权利，以兼顾管理效率和新用户参与。--脳補｡◕‿◕｡讨论 2025年10月25日 (六) 13:36 (UTC)[回复]
如果有其他提報系統給他們「發洩」那倒還行，否則也只能(－)反对--SunAfterRain 2025年11月1日 (六) 03:59 (UTC)[回复]

建議把封禁破壞者和量刑分開

本主題或以下段落文字，已移動至Wikipedia talk:封禁。执行者：Eric Liu 創造は生命（留言・留名・學生會） 2025年11月3日 (一) 11:46 (UTC)。[回复]

對於Grokipedia上線的事情有何看法？

原标题：對於Grokpedia上線的事情有何看法？。修改理由：该网站宣布之初名称即为Grokipedia。修改者：Srapoj（留言） 2025年10月29日 (三) 16:45 (UTC)[回复]

馬斯克即將宣布發表AI生成的百科——Grokpedia 的測試版，大家對於此事有何看法？--IDLCN (菜國人) 讓台灣再次偉大 2025年10月20日 (一) 14:48 (UTC)[回复]

没有必要给其他平台关注度。简而言之：无需理会，因为我们不需要AI生成内容。AI不具有分析和筛选信息的能力。--12З4567（留言） 2025年10月20日 (一) 15:05 (UTC)[回复]
AI noob -Lemonaka 2025年10月20日 (一) 16:09 (UTC)[回复]
縱使是複製維基百科人類生成內容的網站，也從來沒有能打過維基百科的，遑論人工智慧？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月20日 (一) 16:25 (UTC)[回复]
我認為「AI萬能論」在華語地區遠比其他地方盛行的多，有什麼頭緒嗎？--MilkyDefer 2025年10月20日 (一) 22:40 (UTC)[回复]
"Compared with European American respondents, Chinese respondents viewed it as less important to control AI and more important to connect with AI, and were more likely to prefer AI with capacities to influence."華語圈的樣本在某研究中更希望AI對人類有更大影響，也更渴望跟AI有聯繫，不知是否有關。研究報告的預印本見此--S叔 2025年10月21日 (二) 04:10 (UTC)[回复]
To select a relatively geographically diverse Chinese sample, we recruited 172 Chinese participants in Beijing who came from a variety of regions in China, via a Chinese survey platform. 所以可能衹能代表中国大陆，不知道港澳台、新马华人、和其他地区如何？ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月23日 (四) 03:43 (UTC)[回复]
可能在欧美国家那种网络环境搞得成，但是中国搞不成的：巧妇难为无米之炊，中国的好资料都锁在知网万方的付费墙后面，锁在图书馆的纸质书里面，锁在不登陆不给看的封闭平台里面，高质量且开放可机读的资料几乎没有，AI要么输出不了东西，要么直接胡言乱语。别说AI，真人要搞齐那么一堆资料写条目都困难……Nanhuajiaren（留言） 2025年10月21日 (二) 14:51 (UTC) 👍3[回复]
不是沒有資料，是人敢不敢用及承認的問題。歐美付費牆問題也嚴重及無解，不然怎麼有Sci-Hub？。DeepSeek-VL在訓練時吃了源自安娜的檔案的中英文著作（這一點它承認了："We cleaned 860K English and 180K Chinese e-books from Anna’s Archive alongside millions of K-12 education exam questions."）。--S叔 2025年10月24日 (五) 11:38 (UTC)[回复]
想起之前维基百科规划推出AI条目摘要时的一系列反对声浪。--WiiUf（留言） 2025年10月23日 (四) 09:55 (UTC)[回复]
以AI的幻觉能力大概会做成一个超级同人版的百科全书？（用来看乐子似乎不错）----脳補｡◕‿◕｡讨论 2025年10月26日 (日) 13:58 (UTC)[回复]

該站點已正式上線，看起來依然是魔改維基百科。並請參閱英文維基百科有關討論。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月29日 (三) 15:48 (UTC)[回复]

看了幾條條目。大問題就是過於依賴能夠在互聯網公開取得的資料；把一項研究報告的結果當確定性結論使用，而不主要引用綜述，無視樣本的局限。--S叔 2025年10月30日 (四) 01:30 (UTC)[回复]
很差，无目录、无内链、无图片、无简要信息框，很难想象用ai是怎么能写出这么差的前端的--∮♩♪♫♬♭♮♯☧⚧☦︎ 2025年11月9日 (日) 04:43 (UTC)[回复]
上万单词的条目不配一个图…--GrandCeres（留言） 2025年11月9日 (日) 08:52 (UTC)[回复]

仲裁委換任時所留下的仲裁案、動議該如何處理？

如題，不知各位有沒有想過這個有趣的問題，就是如果現任仲裁委沒有在換任時處理好仲裁案、動議，那麼下一屆仲裁委上任時該如何處理上一屆遺留的仲裁案、動議？--🍎 2025年10月24日 (五) 12:21 (UTC)[回复]

對於案件，理應重新指派主任委員，繼續審理；對於表決未結束動議、立案請求等，則考慮以新成員重新表決為宜。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月24日 (五) 12:37 (UTC)[回复]
未來換屆只會換一半人，所以年末鄰近選舉時應安排由不是該期議席重選的仲裁員擔任主委，並在換屆後由這些原有的仲裁員把新任仲裁員進度帶上去（當然，自己參選的時候也最好看着還在跑的仲裁案），最終決定僅由新屆委員投票得出。由於最終本地似乎還是趨向整份報告的形式呈現，相較於英維每個委員各自提案會有頗大的差別。當然，最好是不要跨屆，但總不能在12月末有大爭議發生，卻硬要拖到新任委員上任才處理吧。--路西法人 2025年10月24日 (五) 12:47 (UTC)[回复]
考慮到委員會審理程序，有時不可能一個月結案，所以總歸要考慮交接問題。現在趕緊考慮，好過以後被迫考慮（ —— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月24日 (五) 13:29 (UTC)[回复]
建議新訂仲裁流程內容：
  1. 若有需要立案，而審議程序可預期會慢於下次換屆完成，則應儘量指派任期不會在下次換屆時結束的委員擔任案件主委。
  2. 若某案的主委因故離開仲裁委員會，可另行指定主委，以填補空缺。
另，爲處理本屆仲裁委員會餘下的案件，訂立以下日落條款，並於換屆後由自動廢除：
  1. 爲實踐第 (1) 款的精神，第一屆仲裁委員會在本案通過後指派主委時，應儘量指派有參選下屆仲裁委員會選舉的現屆委員爲主委；若彼時仲裁委員會選舉結果已經確定，則應儘量指派確定在下一屆會擔任仲裁委員的現屆委員擔任主委。
以上條文未必需要原樣收錄，可以不同形式合併進現有流程中。--1F616EMO（喵留言～回覆請ping～求助？） 2025年10月24日 (五) 15:45 (UTC)[回复]
不過以任期或參選與否為主要因素指派特定主任委員是否得宜？略有疑問。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月24日 (五) 19:40 (UTC)[回复]
仲裁方针§参与：……若仲裁员任期于案件审理期间完结，仍可继续参与审理该案直至案件总结。新委任之仲裁员自委任日起可参与任何仲裁事宜。——ZhaoFJx(论) 2025年10月24日 (五) 20:11 (UTC)[回复]
啊，昨天看流程的時候居然看漏了⋯⋯不反對此做法。--1F616EMO（喵留言～回覆請ping～求助？） 2025年10月24日 (五) 23:18 (UTC)[回复]
那動議呢？--🍎 2025年10月25日 (六) 00:54 (UTC)[回复]
這是否也適用於主任委員？另外仲裁委員會技術上的權限是否延續？我覺得還可能有些實務問題。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月25日 (六) 02:15 (UTC)[回复]
我都忘了有這一個條文。如此，舊案件可由兩屆仲裁員共同參與，新案件則只由新屆仲裁員參與，亦為得當。確實如Eric所言有實務問題，我想Eric所指的是「仲裁員」的權限而非「仲裁委員會」。此處我認為站內權限不應予延續，惟ARB私人站點的存取權及VRT存取權可延續，直至案件審理完成。不過我認為該項條款也應該加可限期——最多只能到一月末，如果預期到一月末還沒能處理完，則應如上方我和Eric所提出般整案逐步交接給新屆委員，二月開始的所有動議、投票只能由新屆委員參與。這確保了案件審理的延續和交接，避免了缺乏交流的交接。--路西法人 2025年10月25日 (六) 02:50 (UTC)[回复]
另外各項表決怎麼計算？是要參與審理的都有權表決呢，還是由新一屆委員代表負責？此一問題亦適用於委員動議。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月25日 (六) 08:37 (UTC)[回复]
私認為，在一月進行的表決仍可由兩屆委員共同參與。較為複雜的案件或需時較長去審理，可能橫跨仲裁委員會選舉到年末都還沒處理好。當初在成立仲裁委員會的討論中我有提及過，在案件發生或調查（尤其是特為複雜的社群爭議）期間舉行的選舉可能受爭議事件嚴重影響結果，更多人可能會傾向有較鮮明立場的候選人以維護自己的立場。當初在方針裡留了這一條，大概就是為了避免被選舉使仲裁結果過度失真。由於未來的選舉都是只重選一半席次，那就算真的因爭議事件七上七下，換成7個就有關案件立場較鮮明的用戶上任，則仍有原先的13位仲裁員共同參與表決及控場，佔可參與表決的（最多）20名仲裁員的較多數，能較大程度確保結果客觀中立公正。既能防止就有關爭議事件的裁決過度受輿論影響而有損公正，又不會使社群選上的用戶缺失的代表權。--路西法人 2025年10月27日 (一) 03:10 (UTC)[回复]
另外，前面所述的一月限期應可通過決議延長，由換屆後的仲裁委員會投票，本應卸任的仲裁員在此處無投票權。--路西法人 2025年10月27日 (一) 03:25 (UTC)[回复]
我有另外一個稍微相關的提議：如果當屆仲裁委員會認為明顯無法於任期內審理完畢，可以視情況予以擱置，改由下一屆處理，減少複雜交接問題（是要立案後擱置還是暫緩立案等另議）。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月25日 (六) 08:38 (UTC)[回复]
(＋)支持，另建議暫緩立案方便案件配置--🍎 2025年10月26日 (日) 04:58 (UTC)[回复]
複雜案件十一月立案，預估兩個月完成審理也就是要跨年，那難道就把整個案件拖延整整兩個月才處理嗎？實務上不適合。--路西法人 2025年10月28日 (二) 02:21 (UTC)[回复]
@LuciferianThomas：若為委員會內部流程，則應有自律自由。若在既有規定下不當耽擱審理案件，那是委員個人失格（遊戲規則）問題，應另行考量。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月29日 (三) 15:57 (UTC)[回复]
另外，針對閣下擔憂，本人亦不堅持反對訂出明確時限。不過，本人依然認為在規則上給予委員會一定靈活處理權限並無不妥。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月29日 (三) 15:58 (UTC)[回复]
能交給仲委會審理的都不會是雞毛蒜皮的小事，很多時候都有儘快解決的必要性。仲裁委員會既然是成立來解決爭議的，那解決爭議比起交接問題明顯更為重要。所以我的意見是，交接問題並不應、也沒有重要到要成為擱置審理案件的理由。--路西法人 2025年10月29日 (三) 16:14 (UTC)[回复]
我不確定為了「交接」而總是讓審理表決人數變成兩倍（或二分之三）有沒有問題？何況根據立案時程，到時候其中不少可能是沒幾天就卸任的委員。有關「解決爭議」，社群是否預期某些必然卸任同志「吊車尾」參與解決爭議，本來也可算一種問題。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月30日 (四) 02:19 (UTC)[回复]
修訂方針並明訂即可。（除了這一次換屆）合併兩屆審理人數最多也就20人，實際上還是會有仲裁員連任，除非真的七上七下才會出現20人的壯大場面，正常來說應該只會多了兩三個人。我認為僅有一種情況是已經過了任期的仲裁員應該不被允許繼續參與未完成決議的，就是其在環節選舉是因信任不足50%而落選的情形。其餘情形而言，超過50%已能代表有一定社群支持，只是暫時延長工作參與解決爭議應無大礙。--路西法人 2025年10月31日 (五) 03:18 (UTC)[回复]
考慮到委員會在部分問題上是所謂社群最高機關，我不認為應該留下太多模糊。建議社群就此明定條件，無論是時程，抑或信任要求亦然。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月31日 (五) 20:39 (UTC)[回复]
@Ericliu1912、LuciferianThomas、BadApple、1F616EMO：我有一建議：「每年仲裁委選舉投票開始（一般為10月25日00:00UTC）前立案的只由原有的仲裁員處理，並最多延一個月（至一月末）；投票開始後的案件如不能在十二月末完結，則由原有和新任仲裁員處理；投票開始後的案件如不能在來年一月末完結，則交給新任仲裁員處理。」--Cmsth11126a02 (留言) 國民黨的正確名稱是大陸國民黨！ 2025年11月5日 (三) 03:58 (UTC)[回复]

解禁管理人员自由选举

本主題或以下段落文字，已移動至Wikipedia talk:申请成为管理人员。执行者：Eric Liu 創造は生命（留言・留名・學生會） 2025年11月3日 (一) 11:28 (UTC)。[回复]

建立翻譯腔改進前後範例條目供大家參考

因為有些人將看不慣的用詞專橫地直接定性為翻譯腔（所以既不會修也提不出解釋，只掛模板了事，形成舉證責任倒置），所以建議造出範例讓大家參考，以便有所依循。

方法：先用維基百科的「翻譯此頁面」功能譯出一條尚無中文版的外文條目。先保存起來（或標明在編輯摘要讓後人自己去挖也可以）。最好各大語種各一條，不過這可以慢慢加。條目性質建議以大眾文藝（書籍、電影、電視劇）為佳。因為無論是劇情內容或得奬紀錄都己經固定，而且除非是教父這種等級的經典，否則外間討論也不會再增加。換言之，條目內容不會有大變動，甚至不會有變動了。而且知名度夠高，既具參考價值也方便後續作業。

既然是維基的「翻譯此頁面」，這就是最標準的翻譯腔了（未曾註冊的我沒用過這功能，但看得出哪些用詞滑稽的條目是這麼產生出來的）。然後有興趣的大家集結（例如動員令？）開始修訂。能修出優良條目或典範條目當然是最好，不過這不是主要目的。

修訂完成後，原文、機器翻譯、人力修訂三者並列，就是翻譯腔的定義，及其應當如何修訂，最標準的參照範例。

另外，當有人問起「為什麼不能純粹機翻製造條目」（別懷疑，真有人這樣問過），及「為何維基明明有翻譯功能卻不推薦使用」，和「機翻後要修成什麼樣子才算數」，這就是標準答案。

再者，這也是一份歷史記錄：某年月日，中文維基百科的機器翻譯如此這般，必須以這麼樣的規模的修訂才達到堪用程度。當未來某一天，機翻功能有所進步（或退化），想研究這一方面的學者便有參考比較的標準。--~2025-29411-33（留言） 2025年10月25日 (六) 17:47 (UTC)[回复]

并不会有公认的答案。这似乎在原创“翻译腔”的定义，也不会有多高的学术及参考价值。您是说“翻译此页面”的结果直接输出，还是维基人使用“内容翻译”工具翻译的条目普遍存在翻译腔，前者就是机器翻译的结果而已，且输出结果不一（引擎及版本不同）、不稳定（例如谷歌翻译的输出质量有出现下降，API、网页端等渠道的输出质量存在差异[59]）。AI时代下，机翻已有明显进步，只是传统的机器翻译引擎没有提升而已，可参考小红书的机器翻译[60]、reddit的机器翻译[61][62]，或者其他AI提供的翻译能力。--YFdyh000（留言） 2025年10月25日 (六) 19:02 (UTC)[回复]
我猜上文是WP:互助客栈/其他/存档/2025年8月#模版政策（结果为Template talk:Rough translation#修改模板表述）。
至于“翻译腔”是什么样子，我觉得是用户论述的范畴（应该已经有几篇这种话题的了）。--Srapoj（留言） 2025年10月25日 (六) 19:17 (UTC)[回复]
因為學科分化太細，現代的人有個壞習慣：將無以名之的概念灌進好像是相近的名詞，或者只是哪裡看過就抓過來用。例如「勾兌」一詞本是在酒中兌水調整比例，還要攪一攪（所以叫勾兌），大家看看現在都用在什麼地方。至於翻譯腔，算是這種現象的跨語言版本，而且妙的是，拿字典檢核還找不出錯處來。例如說，alcohol在英文中是拿來喝醉用的，但酒精在中文中是用來清潔或塗傷口消毒的。誰都無法否認alcohol對酒精是毫無疑義的翻譯，但是，以「把錢都用在酒精上」這樣的句子來說，在英文中是很鮮明的意象，但中文不覺得哪裡怪怪的嗎？這就是翻譯腔。因為人工翻譯的話，還要看上下文。如果是錢和酒都要強調，那是花天酒地；如果是一個人悶悶的喝到把錢花光，那是沉湎醉鄉。甚至合適的話，還可以文藝腔一下：「醉鄉路穩宜頻到，此外不堪行」
但因為習於把看不順眼的東西歸諸於找得到的詞彙，所以翻譯腔一詞承載了太多概念，因而也有點走樣。我敢打賭，一定會有人覺得「把錢都用在酒精上」不叫翻譯腔，因為腦筋一轉就知道此酒精非彼酒精，甚至會故意不說酒而說酒精以示與眾不同；卻可能把「醉鄉」當翻譯腔，因為沒看過，或看不順眼。其實這要批評也該說過度翻譯。想要用詞精當，所知詞彙必定要廣，這就很容易令詞彙不夠的人既改不動又看不順眼。
但以上所說純屬一家之言，大家一起弄出個範例才具有參考價值。還是大家比較喜歡看編者之間為了翻譯腔及舉證責任大戰？--~2025-30939-48（留言） 2025年11月2日 (日) 19:04 (UTC)[回复]

亚洲月

没时间解释了，先征集主持人。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月25日 (六) 19:16 (UTC)[回复]

报名，本来想提一下建议今年亚洲月有条件允许中文地区条目的，但有点赶，今年就先这样吧。--FradonStar⭐ · ✍️ 2025年10月26日 (日) 02:02 (UTC)[回复]
( π )题外话：今年编辑松的明信片剩了一些，可以给亚洲月当奖品用，各位觉得合适吗？--FradonStar⭐ · ✍️ 2025年10月30日 (四) 05:29 (UTC)[回复]
我也報名。--SuperGrey (留言) 2025年10月26日 (日) 03:21 (UTC)[回复]
我可以。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月26日 (日) 12:56 (UTC)[回复]
報名。--Ghren🐦🕘 2025年10月26日 (日) 13:50 (UTC)[回复]
報名--Kanshui0943（留言） 2025年10月30日 (四) 13:12 (UTC)[回复]
截。已建立Fountain，望管理員儘快通過。謝謝。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月31日 (五) 13:51 (UTC)[回复]
@魔琴 approved.--SCP-0000（留言） 2025年11月1日 (六) 04:24 (UTC)[回复]
cc @Ericliu1912、FradonStar、Ghren、Kanshui0943、SuperGrey--SCP-0000（留言） 2025年11月1日 (六) 04:26 (UTC)[回复]
壞消息，Fountain掛掉了--Kanshui0943（留言） 2025年11月5日 (三) 08:22 (UTC)[回复]
已经在亚洲月tg群反馈了，他们正在处理。--FradonStar⭐ · ✍️ 2025年11月5日 (三) 08:36 (UTC)[回复]

有关管理人员选举自由提名

本主題或以下段落文字，已移動至Wikipedia talk:申请成为管理人员。执行者：Eric Liu 創造は生命（留言・留名・學生會） 2025年11月3日 (一) 11:28 (UTC)。[回复]

人工智能所生成之媒體之應用

如題。現今，人工智能已可生成圖片、視頻及音頻，這些媒體是否能應用於條目中？又是否能用於討論及計畫頁面？此議題有待社群深度討論。--WiiUf（留言） 2025年10月27日 (一) 13:08 (UTC)[回复]

en:Théâtre_D'opéra_Spatial，此條目已是無可爭議地應使用的例子。即使是當地版權較嚴格的日維也有使用（ja:ご飯にする?お風呂にする?）。為何不可？（誰有空的可以試一下翻譯這兩條目）--S叔 2025年10月27日 (一) 14:58 (UTC)[回复]
AI生成的图片仅需要点几下即可生成，个人觉得能达到受版权保护所需的原创性门槛即可。----脳補｡◕‿◕｡讨论 2025年10月27日 (一) 15:08 (UTC)[回复]
图像使用较多，视频与音频较少。视频未来可能增多，但音频可能没有强烈需求。总体来说，如果没有必要，或是并不契合条目内容的话任何形式都不应使用，但有必要的话，免版权的内容应该会受欢迎。至于训练来源，那是训练者该考虑的，编辑者应该仅考虑生成出来的内容本身是否可能存在版权问题。——暁月凛奈 (留言) 2025年10月27日 (一) 15:46 (UTC)[回复]
有NovelAI的例子（那位“冷床系”曾经用NovelAI生成过大量AI图，在C区有相当争议，但最终只保留少部分有INUSE的）；睢宁社会信用体系曾经也用过一幅，但当时DYKC我认为涉及杜撰而移除掉了，但文件仍在。要从版权性（暂时来看视为公有领域，因为“因为其由计算机算法或人工智能生成，不包含足够的人类作者信息来支持版权主张。”）和题材适合性来判断，NovelAI等用于展示主题生成内容特质的可以考虑，其他为了说明而杜撰的可能不太好。——Sakamotosan路过围观 | 避免做作，免敬 2025年10月28日 (二) 00:59 (UTC)[回复]
Wikipedia:互助客栈/条目探讨/存档/2023年3月#AI藝術类似讨论。——Sakamotosan路过围观 | 避免做作，免敬 2025年10月28日 (二) 02:13 (UTC)[回复]
@Cwek@So47009@暁月凛奈@脳内補完：人工智能生成之图片是否可评选为特色图片？若可，该图像是否拥有可获得“特色图片奖”的原作者？--WiiUf（留言） 2025年10月28日 (二) 10:41 (UTC)[回复]
显然可以，就跟拍摄照片可以从无数角度选择一个最佳角度获得最佳摄影奖一样，AI生成的图片也可以从无数次生成中选择一个最好的获得奖项，需要注意的是大部分平台生成素材需要避免使用版权素材后，基本上很多AI平台生成图片或视频版权归个人所有（比如sora2视频）----脳補｡◕‿◕｡讨论 2025年10月28日 (二) 12:31 (UTC)[回复]
本人建了一個AI指引草案，用於WT:人工智慧升級為指引的討論，誠邀大家參與。--WiiUf（留言） 2025年10月28日 (二) 13:19 (UTC)[回复]
最近刚扩写了幻觉 (人工智能)，或许会有帮助？--百無一用是書生 (☎) 2025年10月29日 (三) 03:06 (UTC)[回复]
我自己在維基共享資源上看到的經驗是，有AI輔助的人物肖像，就算通過審核，只要有編輯者因「使用AI」提刪，最後還是通過被刪除，因為管理員認為AI會使人物失真、不適合用AI來顯示人物的外表。--Loveuu23📮 2025年10月28日 (二) 12:54 (UTC)[回复]
生成資料本身要是可靠來源，而且至少應該徹底禁止在歷史領域相關內容使用。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月29日 (三) 15:30 (UTC)[回复]
除了条目主题本身与AI图片有关，可以使用AI图片作为AI生成的例子进行辅助说明之外，暂未看到在其他领域条目中使用AI图片的必要性。不能因为暂无自由版权的图片就用AI图片代替。一种可接受的情况是利用LLM生成Python/SVG代码制作示意图/统计图。当然这是另一话题了，本节讨论的人工智能生成媒体应该指的是用Diffusion模型直接生成图片。--Steven Sun（留言） 2025年10月30日 (四) 02:30 (UTC)[回复]
我想到的一個可能例外就是叼着麵包快要遲到的少女這類型的日漫刻板角色類型條目。--S叔 2025年10月30日 (四) 03:37 (UTC)[回复]
但人工智慧不是可靠來源，如此產生的圖片無論如何也不適合使用吧？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年10月30日 (四) 16:51 (UTC)[回复]
問題是，現在這類條目的圖片多為編者或外部同人繪師原創，如傲嬌、魔法少女，乃至庫巴姬都是如此。不同語種的眾多性行為相關條目的插圖也由用戶en:Seedfeeder自身繪製。建築物及食物相關條目也有不少由編者拍攝。若追求圖片完全出自可靠來源的那麼維基百科就不應該用這些圖片才對，編者本身不是可靠來源。--S叔 2025年10月30日 (四) 17:13 (UTC)[回复]
我觉得可靠来源应该不适用于图片。WP:原创图像可能适用于此：只要维基百科编者没有在图像中绘制或表现未发表的想法或观点，由维基百科编者创作的原创图像不被视为原创研究。--Steven Sun（留言） 2025年10月31日 (五) 02:25 (UTC)[回复]
这类条目可能是个例外。但我觉得如果存在非AI生成图片且质量不比AI低太多，应该优先使用非AI生成作品。--Steven Sun（留言） 2025年10月31日 (五) 02:14 (UTC)[回复]
(－)反对，目前无法解决版权风险，你文字尚且有方法可以辨别，但是图片就比较难说：最大的风险在于，您的人工智能生成的图像可能无意中复制了现有受版权保护作品的元素。人工智能模型基于数十亿张图像进行训练，其中许多图像受版权保护。当这些系统生成新图像时，有时会生成与训练数据中的图像极为相似的内容。如果发现人工智能生成的图像复制了受版权保护作品的全部或大部分内容，则可能被认定为违反现行版权法。--方的1P（留言） 2025年11月2日 (日) 09:49 (UTC)[回复]
用可靠来源让人工智能生成一些统计图和关联图（例如经济类、社会学类）我认为没什么问题，可以让人的工作负担减轻。至于生成的其他图片（特别是真人类）我感觉不自然 Jyipoley（留言） 2025年11月3日 (一) 11:35 (UTC)[回复]
简易表格不具有版权，因此并不涉及版权问题。--方的1P（留言） 2025年11月3日 (一) 12:47 (UTC)[回复]

如何使用魔术字来显示用户贡献🤔

本主題或以下段落文字，已移動至Help talk:魔术字。执行者：Jimmy-bot（留言） 2025年11月10日 (一) 00:14 (UTC)。[回复]

Internet Archive近來又不靠譜

本主題或以下段落文字，已移動至Wikipedia talk:使用网站时光机。执行者：Jimmy-bot（留言） 2025年11月10日 (一) 08:14 (UTC)。[回复]

LTA創建之條目

如題，LTA創建之條目是否適用Wikipedia:回退、封禁、不理會原則而將條目刪除？--Kanshui0943（留言） 2025年10月31日 (五) 03:21 (UTC)[回复]

须共识认为相关条目是“破坏行为”。--YFdyh000（留言） 2025年10月31日 (五) 06:10 (UTC)[回复]
如果是明顯擾亂的可以用G3速刪--象象🐘(留言|貢獻) 2025年10月31日 (五) 06:36 (UTC)[回复]
正常條目可以留著，純粹破壞條目可以以G3速刪，不確定是否是破壞可以提交afd。--日期20220626（留言） 2025年10月31日 (五) 08:25 (UTC)[回复]
先确定是不是破坏，实事求是就是了。--方的1P（留言） 2025年10月31日 (五) 10:43 (UTC)[回复]
想到LTA:燒賣建立的高爾夫相關條目--—— Matt Zhuang表示有事按「此」留言 2025年10月31日 (五) 11:58 (UTC)[回复]
這些條目在高爾夫領域還蠻重要，顯然應該留著。因人廢言不可取。--日期20220626（留言） 2025年10月31日 (五) 12:02 (UTC)[回复]
雖然LTA大部分都是破壞行為，但有時候還是會建立或加入一些正常的條目或內容，如同日期20220626和方的1P說的判斷一下就行，不是破壞或惡搞也沒違反方針指引就留者，反之就照社群的程序解決就行。--Polar Bear 2025年11月1日 (六) 13:49 (UTC)[回复]

有關跨wiki使用多個帳號

剛剛注意到Creationmedia fay（讨论 | 貢獻）所建立的頁面，其內容與Tonywongcm（讨论 | 貢獻）在wikidata建立的d:Lexeme:L1525221（已被本人在wikidata提刪並已被刪除）內容一模一樣。這兩個帳號也在中文維基註冊。請問這樣是否屬於濫用多重帳號？--~2025-31082-35（留言） 2025年11月3日 (一) 07:51 (UTC)[回复]

兩個帳號沒有同時在本站編輯，我們管不著吧。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月3日 (一) 11:48 (UTC)[回复]
这种情况不一定是同一人，但从内容来看是spam，不必按照多重账号处理。——暁月凛奈 (留言) 2025年11月3日 (一) 15:44 (UTC)[回复]

關於條目標題下新增的圖片行

是否出現了新的共識? 發生了什麼--URI Error404 2025年11月5日 (三) 09:05 (UTC)[回复]

什麼條目？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月5日 (三) 11:57 (UTC)[回复]
所有
  • 提供排除錯誤使用的臨時圖片
--URI Error404 2025年11月5日 (三) 12:12 (UTC)[回复]
我记得是测试，等我翻一下--Luoniya（留言） 2025年11月5日 (三) 12:18 (UTC)[回复]
这个--Luoniya（留言） 2025年11月5日 (三) 12:19 (UTC)[回复]
WMF的人9月在客栈技术版宣传过。现在也还挂着：WP:互助客栈/技术#圖片瀏覽實驗 – 行動版測試即將啟動。--Srapoj（留言） 2025年11月5日 (三) 12:19 (UTC)[回复]
原來是這樣，非常感謝 --URI Error404 2025年11月5日 (三) 12:28 (UTC)[回复]

观猴

动物园：https://www.xiaohongshu.com/explore/690ac5190000000007003da6

（备注：文明投喂，别玩死了）

--~2025-31295-00（留言） 2025年11月5日 (三) 09:41 (UTC)[回复]

@日期20220626 这个帖子的作者和评论区的一些人疑似参与了对维基百科的破坏，并进行人身威胁--~2025-31295-00（留言） 2025年11月5日 (三) 10:01 (UTC)[回复]
你可以在afd提出，而不是急著在這個頁面掛g3。--日期20220626（留言） 2025年11月5日 (三) 10:05 (UTC)[回复]
已经人身攻击+人身威胁了，我都觉得可以提报到元维基乃至基金会了--~2025-31295-00（留言） 2025年11月5日 (三) 10:06 (UTC)[回复]
@日期20220626 之前有过类似“对等反制”的先例，Wikipedia:可靠来源/布告板/存档/2021年12月#因散布垃圾链接降级品葱--~2025-31295-00（留言） 2025年11月5日 (三) 10:09 (UTC)[回复]

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

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

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

请指明讨论在哪、具体条目范围。是机器人创建，还是人工创建或添加的内容。不太理解浪费与内容无用的并存。内容很差的条目，重写为小小作品或小作品是可接受的，如果担心误移除，或可清楚标注（编辑摘要）与记录（工作组摘要），以及特制一些模板来限时保留──类似{{fact}}，但适当高亮，标注时限（30/60/90日）、理由，超期后由机器人移除，这样解决只挂维护而不维护的问题。--YFdyh000（留言） 2025年11月5日 (三) 13:54 (UTC)[回复]
感觉标注时限是一个比较可行的政策。--WiiUf（留言） 2025年11月5日 (三) 14:02 (UTC)[回复]
关于浪费和无用的问题，可能是本人用词不太清楚吧：如果一刀切那些质量低的条目，维基百科可能损失10%以上的内容（别看10%少，实际上其中有相当一部份都是基础条目），影响百科全书完整性；如果留着呢，维基百科的内容准确度又会大幅降低。--WiiUf（留言） 2025年11月5日 (三) 14:08 (UTC)[回复]
也許本百科從建立之初準確度就是不太高。網友眾包的百科本來就不能全信的。😂--日期20220626（留言） 2025年11月5日 (三) 14:11 (UTC)[回复]
如果质量低到误导，切掉是正确之举。如果基础条目但连一个小小条目都没人愿意写，那么没有就没有吧，本站还做不到无所不包，以及很多传媒的准确性也不是很高。--YFdyh000（留言） 2025年11月5日 (三) 14:35 (UTC)[回复]
我是願意寫，但是如果一下子提刪十幾萬個，那感覺就是在胡來了。--日期20220626（留言） 2025年11月5日 (三) 14:59 (UTC)[回复]
请具体指明。既然曾经批量创建十几万个条目能被接受，那么移除十几万个也有可能。--YFdyh000（留言） 2025年11月5日 (三) 15:18 (UTC)[回复]
人和機器賬戶批量創建的有中國大陸和美國的鎮區區劃以及物種條目，這些顯然不能移除。--日期20220626（留言） 2025年11月5日 (三) 15:24 (UTC)[回复]
甚至這些條目反而不存在WiiUf提到的問題。--日期20220626（留言） 2025年11月5日 (三) 15:26 (UTC)[回复]
仓促批量建立的不少条目存在来源不足或失效、格式不佳、缺乏维护、译名原创等等问题，我觉得是符合的，问题条目也将长期污染互联网和大模型的资料库。另外，如果提案所指的问题条目是杂类，理论上适当的计算机程序+小型AI能筛选和标记出许多，虽然无法解决人力改善的成本。--YFdyh000（留言） 2025年11月5日 (三) 15:38 (UTC)[回复]
一這個問題範圍過於宏大（上面已指出）且可能無法改善；二就算改善了後也會有源源不斷的問題條目出來。所以不如就接受維基百科就是品質不那麼高的在線百科好了。對於爛但是有關注度的條目，我是一律主張刪成小作品的。--日期20220626（留言） 2025年11月5日 (三) 13:59 (UTC)--日期20220626（留言） 2025年11月5日 (三) 13:59 (UTC)[回复]
换做以前我可能会想宁滥勿缺吧，但现在看来这个问题就好像是买了一辆破烂的车一样，刚刚好是过了能开的标准，但是漏风漏油四处异响还顿挫。你说他可以修吧，遗憾的是，这辆车直到停产时都只有零零散散的销量，能用的配件稀少，会修它的汽修工也不多，到最后好像还不如直接走路好。
要判定一个条目值不值留还是应该看它能为一般读者带来多少信息，从上面20220626君提到的站内那些被批量创建出来的美国的镇区区划以及物种条目来说，虽然他们的正文大都极短极小，但是大都附有载有一定量有效信息的Infobox，可以说还是有价值的。但像是易安音乐社这样的条目就没有什么有效信息了，我能从中知道什么呢？难道是“噢，我的偶像在维基百科上有条目欸”，或者更( π )题外话一些，这个条目的潜在读者可能大都根本就不会选择维基百科。
当然从实例来说每个人要获取的信息点和信息多少都不一样，我需要为新下载的歌曲手动填充元数据的时候就可以从外语维百中不少短小的音乐条目里获取到相关信息，例如Thermo Plastic这样的条目，虽然正文介绍不多，但是列出了完整的歌曲列表，有完备的Infobox标明流派、发行日期这些关键信息，这对我就足够了。
额......个人觉得，很多时候，打开一个条目见到里面的内容粗制滥造，比直接没有这个条目更容易令人失望。--Pathfinbird🦅 2025年11月5日 (三) 16:52 (UTC)[回复]
易安音樂社不就是介紹了這個組合的基本信息？信息量不少。--日期20220626（留言） 2025年11月5日 (三) 22:46 (UTC)[回复]
條目要是寫的看不懂倒是個問題。--日期20220626（留言） 2025年11月6日 (四) 00:01 (UTC)[回复]
中文维基百科条目质量有问题，是因为像User:ThomasYehYeh那样愿意持续改进条目的志愿编辑人员太少、难以坚持，或像User:Z7504那样被无限期封禁。不认为有“一刀切”的简单改善办法。中维管理人员对维护社群建设性的环境应承担更大责任，避免轻易封禁有长期贡献的编者，或随意删除在中维有长期编辑历史的条目、模板、主题等。
有些条目内容太少、不严谨，但如果所对应的外文条目内容丰富，这样的 interwiki链接也是有价值的。个人认为聊胜于无。--Zhenqinli（留言） 2025年11月5日 (三) 23:37 (UTC)[回复]
从处理快速删除的角度来看，挂模板还是有用的，一直是在慢慢清理的，只是可能有些太慢了。而且维护模板是双向的，告诉编者这个条目存在哪些问题需要处理，告诉读者这些条目可能存在一些问题，阅读要更加谨慎--百無一用是書生 (☎) 2025年11月6日 (四) 02:15 (UTC)[回复]
理想主义——当年一大堆没来源条目都没人管，现在有人（还是新注册的精神小伙，吧唧吧唧）开始践行教条，开始哔哔了。别废话，自己觉得能修就去修。 耸肩——Sakamotosan路过围观 | 避免做作，免敬 2025年11月6日 (四) 03:59 (UTC)[回复]
偶然遇过一些古老条目（可能在10年~09年之前创建，之后基本上极少追加更新），并且部分还是具有基础语义或者就是WP:基礎條目，到现在都没有脚引来源。早期以来人力有限，规则不一定完善或者缺乏人力敦促遵守，人力也有可能没留意这些规则去遵守，变成了房间里的大象，你可以高情商说是善意（添加内容的人，或者发现但没及时修正的人（可能没空、可能不太懂相关方面而动不了手）），低情商说是纵容。现在这样冒出来说“房间里的大象”是个问题，好像只有你看到是个问题，大家没注意到这个问题，有没可能，是大家知道问题，但没有一劳永逸并且尽善尽美的解决方法；或者说，理想状态下，维基百科的条目自始至终，句句都符合三个核心方针，十分完美的存在，但现实不是理想状态？连en都能翻到这类带问题的条目，zh就别想得这么好。如果真想解决的话，自己动手处理呗，别废话，至少把没有来源、或者需要更多来源（脚引来源或尾列来源的量与条目行文量不相配的）的条目，这种可以认为容易“原创研究”的条目，处理一下，或者有些对应外语条目的，可以参考下翻译，也行吧。——谈这个，总是偶然想起像炉这个例子。——Sakamotosan路过围观 | 避免做作，免敬 2025年11月6日 (四) 04:53 (UTC)[回复]
不能認同這是「句句都符合三個核心方針，十分完美的存在」的理想主義。本人從來沒講過條目一定要完美，如果條目僅是欠缺一兩條來源、文法稍微不通順，可在較短時間內改善，這些條目要留著也沒有太大的問題。本人講的是那些存在嚴重問題，甚至根本無法理解的條目。--WiiUf（留言） 2025年11月6日 (四) 13:37 (UTC)[回复]
有关“存在嚴重問題，甚至根本無法理解的條目”，最好能至少举出一、二个例子（基础条目的例子更好）。--Zhenqinli（留言） 2025年11月6日 (四) 16:34 (UTC)[回复]
目前看到的前三级基础条目都还好（还不算有“特别”严重的问题，最差的条目应该是蕉），不过从第四级开始呢……可举出的条目绝对不只一两个。--WiiUf（留言） 2025年11月8日 (六) 05:06 (UTC)[回复]
本人才浏览了不到30个第四级条目，就找到了研究、温度计这些离谱的东西。--WiiUf（留言） 2025年11月8日 (六) 05:09 (UTC)[回复]
溫度計哪裡離譜了？沒覺得這條目定義哪裡錯了。--日期20220626（留言） 2025年11月8日 (六) 05:20 (UTC)[回复]
除了定义之外呢？--WiiUf（留言） 2025年11月8日 (六) 05:26 (UTC)[回复]
之後就列舉了一堆溫度計類型唄。--日期20220626（留言） 2025年11月8日 (六) 05:29 (UTC)[回复]
……--WiiUf（留言） 2025年11月8日 (六) 05:33 (UTC)[回复]
这两个条目我觉得没什么问题，但是确实需要扩充--Luoniya（留言） 2025年11月8日 (六) 05:39 (UTC)[回复]
研究雖然有一個來源，而且大段內容也沒來源，但沒覺得這個條目是在胡說八道。--日期20220626（留言） 2025年11月8日 (六) 05:23 (UTC)[回复]
原创研究。按照编者自己认为的“常识”去写，当然不像是胡说八道。--WiiUf（留言） 2025年11月8日 (六) 05:25 (UTC)[回复]
不管是何種語言的維基百科，無來源的內容都可以算作原創研究，但是無來源的文字佔比不小，清除完根本不可能，比較實際的做法就是掛模版來替代刪除。--日期20220626（留言） 2025年11月8日 (六) 05:28 (UTC)[回复]
是啊，挂模版最实际，可是没啥用。--WiiUf（留言） 2025年11月8日 (六) 05:32 (UTC)[回复]
基础条目没人愿意写是没办法的，毕竟常常写了没有任何好处，或者写下去的难保正确，无人关注乃至遭受破坏。很多人乐于找出问题而非编写，其实在如今，如果用AI来翻译或摘要外文维基的优质条目，再由“专业”编者甄选，得以扩充，可能是个办法，但将面临一些问题，例如水票、不专业审核，风格同质化等。而AI直接输出或翻译其他来源以取内容，面临版权难题，只能作罢。--YFdyh000（留言） 2025年11月9日 (日) 18:41 (UTC)[回复]
像研究这样有关基本概念的条目，虽然中文文献里相对系统、权威的可引资料来源较少，但通过跨Wiki链接很容易找到外文资料来源；而且这条目在维基数据是被使用较多的重要概念。个人不赞成 动不动以原创研究为罪名提删资料来源欠缺的条目、模板等的做法。与其对别人编写的东西求全责备，不如将维基条目、模板等当作半成品（work in progress），予以逐步建设性改进。--Zhenqinli（留言） 2025年11月8日 (六) 23:59 (UTC)[回复]
至少，我认为我们应该有个这样的理想——“近乎完美，符合方针的条目（Wikipedia:条目半衰期中‘完美条目’开始一两年）”，但毕竟现实如此（‘完美条目’后面十来年的状态），我们还有这个Wikipedia:免责声明（维基百科不保证其内容正确无误），如果想趋近这个理想，自己清掉那些有问题的条目（那两个分类的），或者列出希望别人协助一起处理的（像下面基础条目，找Wolfch帮手），这样不就好了？提出问题时，至少心中有这个问题的解决思路或者方案，对不？——Sakamotosan路过围观 | 避免做作，免敬 2025年11月7日 (五) 03:55 (UTC)[回复]
@WiiUf：,（有看到基础条目, 來表達意見好了。）若發現有第三級基礎條目（1000個條目，列表在Wikipedia:基礎條目，討論頁有標示「XXX屬於維基百科XXX主題的基礎條目」）有此問題，請跟我說，會設法修正，謝謝您。--Wolfch (留言) 2025年11月6日 (四) 04:17 (UTC)[回复]
今年動員令有針對基礎條目（第一至三級）設立主題，這也是改善條目的一部分，但並不是每個維基人願意參與條目改善工作，畢竟還有比維基百科編纂更重要的工作要處理，另外我提議自2025年起的每屆動員令都要包含一項為「基礎條目」。--Sinsyuan✍️PJTW 2025年11月7日 (五) 05:30 (UTC)[回复]
@Sinsyuan：,您若有興趣分析的話，可以統計一下，今年動員令中「亟需撰寫的條目」小動員令通過的數量，以及其中第一到第三級基礎條目的數量。--Wolfch (留言) 2025年11月7日 (五) 22:53 (UTC)[回复]
基礎條目第一至三級共一千篇，第23次中文維基百科動員令的「亟需撰寫的條目」開放本站第一至四級基礎條目共一萬篇以及其他傳統百科全書。據了解，本屆動員令「亟需撰寫的條目」有121篇條目達標，另外還有其他主題同時也列入基礎條目前四級（如紐約地鐵為基礎條目第四級，本屆動員令為交通類）。--Sinsyuan✍️PJTW 2025年11月9日 (日) 01:06 (UTC)[回复]
第一至三級的基礎條目，數量分別是10個、100個、1000個。第一級基礎條目本屆動員令「亟需撰寫的條目」的達標條目裡，以我的統計（看條目討論頁的基礎條目對應說明），有一個第一級基礎條目（社會，這也是第二級、第三級基礎條目，後面就不重覆列了）、有一個第三級基礎條目（糖尿病）。另外，有一些第四級基礎條目（我就沒細數數量了，大約二十個左右吧），若要用動員令來改善基礎條目，今年的成效如上--Wolfch (留言) 2025年11月9日 (日) 06:32 (UTC)[回复]
挂模板没有用，抱怨有没有用呢。挂模板是站务精，像英维这样清理来源请求积压是不是也是站务精？思想统一不了什么都干不了。--PexEric 2025年11月7日 (五) 07:51 (UTC)[回复]
以前动员令设立过来源改善项目。之后好像因为记分问题没再延续。--Steven Sun（留言） 2025年11月7日 (五) 08:35 (UTC)[回复]
可以開辦中、小動員令（跳脫年度制），以清理條目為主題。類似英文方面的什麼什麼backlog drive。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月7日 (五) 09:16 (UTC)[回复]
不如干脆把{{Rewrite}}设个提删限期（比如180天）。--WiiUf（留言） 2025年11月8日 (六) 05:11 (UTC)[回复]
反對，那還不如就如Eric Liu所說的那樣放入動員令裡面。--日期20220626（留言） 2025年11月8日 (六) 05:16 (UTC)[回复]
如果条目的跨Wiki链接及维基数据链接本身没有问题，那么从中文维基提删条目、删除这些链接就没有正面意义，不应该作为默认选择。这些（跨Wiki链接及维基数据）链接是维基百科比百度百科等优越、功能更丰富的一个方面：后者仅提供中文条目。--Zhenqinli（留言） 2025年11月9日 (日) 05:12 (UTC)[回复]
直接把建立条目向导和草稿审核废除掉，取消草稿命名空间；禁止新建草稿，改为在所属专题的子页面建立；重建和翻修各大主题和专题页面；如此则能够集中同一领域的编者，在专题内部开展条目评级和质量提升工作，进而有效解决条目质量问题。--12З4567（留言） 2025年11月8日 (六) 17:18 (UTC)[回复]
？不對吧，應該是加強專題組織與草稿連結，不是直接廢除草稿制度。比方說，鼓勵編者加入（簽到）專題，並適時就草稿性質通知有關專題編者，之類的。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月8日 (六) 18:08 (UTC)[回复]

鬥爭

我很好奇。鑑於這裡的編者們廣義上也是文字工作者，或說比一般不愛讀寫的人更加親近文字，那麼，對於用詞含混，甚至含混到內涵都混在一起的場合，真的一點感覺也沒有嗎？現在的人放棄追求一字不可易的精準了嗎？ 例如「鬥爭」一詞，就我在許多條目中所見，吵架也說成鬥爭，打架也算鬥爭，意志的對抗也是鬥爭，請問鬥爭是因為可以隨便亂用而在爭吵、大吵、惡吵、動手動腳、還手、招架、推撞、打鬥、全武行、飽以老拳、對抗、抵抗、反抗、抗拒等數不完的用詞中脫穎而出，還是說在中文圈裡的某些地方，「鬥爭」在現實中真就是這麼浮濫？

就我看來，這應該是機器翻譯搞出來的。而執行機器翻譯的人詞彙量不夠，不知道怎麼改，甚至不覺得要改，就到處「鬥爭」下去。機器翻譯這麼搞有很好的理由。既然有這麼萬用的詞可用，何必花時間精細微調？時間精力用在其他更具展望的專案不好嗎？但是啊，人類啊，你只會「鬥爭」的藉口又是什麼？翻譯全交給機器，那還要中文維基百科幹什麼？機器翻譯七百萬條目的最大版本維基不就好了嗎？

不是我只會抱怨哦。我試過修正，但第二天就被原編者回退，繼續「鬥爭」下去。我知道來回三次才叫編輯戰，但臨時帳號打編輯戰先天吃虧，所以既然對方態度如此，那一次就夠了。

什麼叫翻譯腔？這就是翻譯腔之一，而且諸人視而不見。只會為難看不順眼的文雅用詞，將改不動的用詞一律概括為翻譯腔。

真要鬥爭，是人要和機器鬥爭。我察覺到，用同樣的機器翻譯去處理同一篇文章，其中用詞過一段時間都會變，變好變壞不一定。顯然還在網路上學習詞彙與詞義。不知道維基百科在其間比重若干。但如果人類的用詞含混到令機器以為動口動手或出於意志都一樣是「鬥爭」，而人類又無法自「鬥爭」中分離出各自的形式與意義，那就是1984了。大家應該可以明白，「鬥爭」在此只是一個例子，含混的用詞豈僅於此。所以不要說什麼看上下文解析。同一篇文的每一詞每一句都是彼此的上下文，當含混的字詞太多，就沒有參考之處，也就沒得解析了。--~2025-55225-8（留言） 2025年11月6日 (四) 22:20 (UTC)[回复]

未提供相关编辑，无从判断您的看法。有编者回退就不是“翻译全交给机器”，而是看法冲突。--YFdyh000（留言） 2025年11月7日 (五) 09:50 (UTC)[回复]

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

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

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

副知@金色黎明。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月9日 (日) 15:26 (UTC)[回复]

仿欧洲一些语言维基百科平台每年闭站一日如何？

欧洲一些语言维基百科在遇到当地或欧盟政府欲出台不利于维基百科及网络自由之法规时，会闭站，向访问者说明情况以示抗议，而中国日日封锁我站，我站应否每年择一日，如六四，三一二等，闭站一日（以东八区时区为准），以示抗议？--∮♩♪♫♬♭♮♯☧⚧☦︎ 2025年11月8日 (六) 19:20 (UTC)[回复]

怎麼感覺你很常在客棧提案這種東西XD😅 —— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月9日 (日) 02:54 (UTC) 🤓1[回复]
我提议的关站时间时长一直有修正，其性质也自然有变化--∮♩♪♫♬♭♮♯☧⚧☦︎ 2025年11月9日 (日) 04:38 (UTC)[回复]
类似提案：Wikipedia talk:維基百科標誌#关于本站遭中国大陆屏蔽十年的信息页 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月9日 (日) 04:31 (UTC)[回复]
所以那个事情怎么样了？有后文吗？不过那个图标是真的丑，不建议使用--∮♩♪♫♬♭♮♯☧⚧☦︎ 2025年11月9日 (日) 04:33 (UTC)[回复]
没有。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月9日 (日) 04:35 (UTC)[回复]
六四是外部倡导，参见meta:Special:MyLanguage/Wikimedia Foundation/Legal/Update to banner and logo policies，而且还和政治有关，不可能过的。（三一二是什么？植树节？国父逝世纪念日？和中共、和维基百科有什么联系吗？） ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月9日 (日) 04:35 (UTC)[回复]
三一二是互联网自由日--∮♩♪♫♬♭♮♯☧⚧☦︎ 2025年11月9日 (日) 04:38 (UTC)[回复]
不反对每年三月十二日更换特殊标志或者悬挂横幅，或者五月十九日（本站本次遭屏蔽周年）也可。闭站还是算了。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月9日 (日) 04:41 (UTC)[回复]
可以把主页改成信息页吗？--∮♩♪♫♬♭♮♯☧⚧☦︎ 2025年11月9日 (日) 04:45 (UTC)[回复]
等到信息页不被社群block再说，您可以看看当时的讨论。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月9日 (日) 04:47 (UTC)[回复]
闭站影响颇大，且不利于普通用户。如果没有出现新的不利于信息自由的情况，本人希望中文维基百科不要因为旧事闭站。另附议魔琴君观点。--CuSO4 · 蛇年大吉 2025年11月9日 (日) 04:37 (UTC)[回复]
只闭站一天如何不利？另外欧洲同行不就是用闭站影响来倒闭改革吗？--∮♩♪♫♬♭♮♯☧⚧☦︎ 2025年11月9日 (日) 04:40 (UTC)[回复]
想象一下中文维基百科关站一天，全国人民打电话给自己的人大代表投诉…… ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月9日 (日) 04:47 (UTC)[回复]
闭站一天确实不利，假设你今天急需寻找些什么，结果遇到闭站？--Luoniya（留言） 2025年11月9日 (日) 04:56 (UTC)[回复]
如果只是以結果論，其他語言站點閉站產生了什麼重大影響嗎？其實我是反對包括中維在內的所有站點因為抗議某事而閉站的，但可以通過掛電子橫幅的方式表達抗議。--日期20220626（留言） 2025年11月9日 (日) 05:25 (UTC)[回复]
👍 赞--WiiUf（留言） 2025年11月9日 (日) 11:04 (UTC)[回复]
可挂电子横幅，不需闭站。--— Gohan 2025年11月10日 (一) 04:30 (UTC)[回复]
看到有用戶持之以恆地炒冷飯，本人一時竟然不知從何種角度評價。--Didaictor（留言） 2025年11月10日 (一) 09:01 (UTC)[回复]
除非出现一些极其特殊的情况（例如基金会让所有项目全体闭站这样的，当然能搞到基金会全体闭站的地步，想必是出现非常非常特殊的事态），否则反对闭站。至于电子横幅，最好是确保社群在这块形成统一意见再挂，五年前港版国安法刚实施那会，有人提议将基金会的声明放到ASN那里，照样引来不少反对（虽然反对的主要都是WMC的人）。--#MilanoCortina2026Countdown88Days 2025年11月10日 (一) 09:22 (UTC)[回复]
若是政治問題倒是和是不是wmc無關了，換現在就算不是wmc還會有人反對。--日期20220626（留言） 2025年11月10日 (一) 09:53 (UTC)[回复]
没错，但我回看了那个讨论一圈了，发现当时反对的大多都是WMC成员，或者和WMC有关联的，这也是事实。--#MilanoCortina2026Countdown88Days 2025年11月10日 (一) 10:07 (UTC)[回复]
可以挂抗议横幅，可以让用户在社交媒体上抗议，在把wikipedia的logo临时变一个抗议的logo即可-- YX Z 2025年11月10日 (一) 09:43 (UTC)[回复]

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

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

25周年logo不用本地自己设计，基金会已经有统一logo。明天我做个本地化版本放到commons:Category:Wikipedia 25 localised logos。
--PexEric 2025年11月9日 (日) 14:10 (UTC)[回复]
嗯，參见meta:Wikipedia 25/Celebration toolkit。也是需要本地化的。而且基金会似乎没有给旧版logo设计特殊标誌（不可能维基百科字樣右边突出一块），要不要问问？ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月9日 (日) 14:19 (UTC)[回复]
站内显示的话。我猜应该是把维基球直接变成拼图吧。--PexEric 2025年11月9日 (日) 14:58 (UTC)[回复]
完成了。发现一个逆天的事🤣，本站的简体和繁体logo宽度竟然不一样。--PexEric 2025年11月10日 (一) 06:34 (UTC)[回复]
（這樣2027年10月中文站25週年的標誌衹要把25改成廿五就行了） ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月10日 (一) 09:06 (UTC)[回复]
今年春节暴露出一個问题就是没有提前议定logo悬掛时间。我建议从除夕到元宵全天，除夕按UTC+14计，元宵按AoE（UTC-12）计：
UTC+14 UTC+8 UTC UTC-12
除夕 02-16 00:00 02-15 18:00 02-15 10:00 —
元宵翌日 — 03-04 20:00 03-04 12:00 03-04 00:00
 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月9日 (日) 14:30 (UTC)[回复]

春節標誌聯合票選

之前我在站外提出一個設想。就是我看到越南語維基百科這邊也是會搞春節標誌，有些設計還挺有意思的，至少比本站某幾年一個設計都推不出來的強。我希望如果有機會的話可以兩站聯合票選。大概的想法是，兩個站共享投稿的設計，但是票選的時候還是分別票選，互不干擾，各社羣擁有對於自己想換什麼標誌的最終決定權。以後也許可以邀請日韓、文言、漢語方言等站點加入。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月10日 (一) 08:16 (UTC)[回复]

支持，附历年越南语logo提案--Luoniya（留言） 2025年11月10日 (一) 08:53 (UTC)[回复]
韩文那边可以邀请，日本不过农历春节吧，而且日文维基百科印象中几乎没怎么用过特别标志……PS：本站确实几乎没有会美术设计的人才，至今都觉得百万条目标志过于简陋是最大的遗憾（我现在很后悔我当时支持用那个标志）。虽然跨站共享设计是可以考虑的，不过要看对方同不同意我们这边用（就算是自由版权授权也要有充分沟通），以及如果对方那边的春节标志有对方自己的特色，我们这边的读者与编者能否接受的事情。--#MilanoCortina2026Countdown88Days 2025年11月10日 (一) 09:10 (UTC)[回复]
(～)補充：虽然去年新春标志我一开始不知道是拿了20周年的素材用了的，不过结合那次的讨论及2018年百万条目特别标志的评选讨论，不管是不是要跨站共享设计，我还是觉得今后特别标志再出现像百万条目标志评选那样，九个方案唯一一个长得像样的因为“过于暴力”而遭到否决，最终只能推一个简陋标志上的情况，那宁可不挂，而不是非要追求次次特殊事件次次挂。像日文这样的极少挂特别标志的也不是没有。--#MilanoCortina2026Countdown88Days 2025年11月10日 (一) 13:51 (UTC)[回复]
邀请几个过春节的国家的wiki编者，集思广益呗，最后选一个好的就行，带点汉字文化圈通用元素不就好了-- YX Z 2025年11月10日 (一) 09:38 (UTC)[回复]
不反对。不过如果本站没有拿得出手的稿件，像是白嫖人家的设计，得了便宜再卖乖😂。不过本来就是自由版权，想用直接用就是了（如File:Tết_Canh_Tý_2020_(cnwiki).svg也用过本地的设计）。只看他们愿不愿意，毕竟这种活动似乎对他们不一定有好处。--PexEric 2025年11月10日 (一) 13:09 (UTC)[回复]

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

整改中維的軍事條目

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

本人在編寫維基的時候發現，包括我本人在內，在撰寫條目時常混淆战役（Campaign）跟会战（Battle）的概念，導致中維一堆原文是battle，卻翻成「戰役」的條目出現。我打算盡可能將西方軍事史中，所有在歐洲語言被稱為Battle、Bataille、Schlacht的條目標題都改成「XX之戰」，只有原文為Campaign的才為「XX戰役」。

不過這也導致別的問題，19世紀以前的條目還好改，但是一戰跟二戰無論是中維、歷史書籍或新聞，都把這倆概念徹底混在一起了，故想請問對軍事史條目有貢獻的維基人的意見。--Waylon1104（留言） 2025年11月9日 (日) 15:06 (UTC)[回复]

@Waylon1104：如果可靠來源也這麼寫，我們就不能擅自改動。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月9日 (日) 15:10 (UTC)[回复]
「可靠來源」出現這種錯誤本質上是翻譯者水準不行，但考量到影響，我目前不打算動20世紀後的條目--Waylon1104（留言） 2025年11月9日 (日) 15:13 (UTC)[回复]
（一）可靠來源>真理，（二）漢語翻譯也不總是字句對應。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月9日 (日) 15:23 (UTC)[回复]
有没有可靠来源指出「某应该翻译为某」？如果有类似的学界共识，似乎可以考慮全面修正。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年11月9日 (日) 15:34 (UTC)[回复]
可靠来源常用名称>原创标准。如果是原创译名，定下一个命名统一性的指引（建议性），那可以。大规模变更应慎重，可能无学界和站内共识。--YFdyh000（留言） 2025年11月9日 (日) 17:12 (UTC)[回复]
同上，可靠來源常用優於逐字翻譯。又如，英維（英文）也經將部分類型「事變」翻譯為「（大）屠殺」。另一角度觀之，不當成「翻譯」，即豁然開朗。--— Gohan 2025年11月10日 (一) 03:24 (UTC)[回复]
检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia:互助客栈_(全部)&oldid=63126193”