維基百科:互助客棧/技術

互助客棧： 消息  方針  技術  求助  條目探討  其他 |  知識問答

發表新議題

發表前請先搜尋存檔，參考舊討論中的內容可節省您的時間。

公告欄

• [人事] 人間百態的管理人員申請意向調查舉行中，請踴躍參與討論。
• [公告] 引入英維摺疊討論中明顯LLM文本的做法已經通過。
• [公告] 廢止快速刪除O3款、集中選舉以「報備區」替代「提名區」、啟用新版編輯入門和參與貢獻頁面、存檔各「新手論壇」、默認使用text-autospace為中英文之間添加空白、啟用ProtectionIndicator、Wikipedia talk:命名常規/音樂#提議使用拉丁原名作為歌曲的標題及Wikipedia_talk:收錄標準/音樂#修訂選秀五強，定義釐清正在公示，如有意見請盡快提出。
• [討論] 互助客棧正在討論移除對Tor用戶獲得自動確認的額外限制、修改Sidebar、維基百科25周年和新年標誌及人物出生及逝世日期分類問題，歡迎踴躍參與。
• [討論] 社群正在討論考慮將消歧義括號修正為全形括號、修改文件重定向相關方針、進一步訂正兩岸四地格式手冊有關「中國大陸」、「中國內地」等詞的使用規定、整理檔案系列準則名稱及釐清提刪模板模組前的必要手續，歡迎踴躍參與。

• [協作] 現有172個頁面需維基化，615個條目需清理，18個移動請求正在討論。

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	提議：高亮哈佛參考文獻格式短鏈指向的完整資料引用	55	9	Dabao qian	2025-12-03 17:47
2	應將Category:各日出生和Category:各日逝世的參數加入Template:Bd模板	89	13	Ericliu1912	2025-12-02 17:40
3	提議：默認使用text-autospace為中英文之間添加空白	69	14	Diskdance	2025-12-05 13:38
4	自動清理重複重新導向模板標記	3	3	Stang	2025-11-18 09:11
5	改善字體的討論怎麼又死了	8	5	Sksawf	2025-12-09 22:46
6	介紹：WebFont-ZH服務及小工具	76	11	魔琴	2025-12-02 23:49
7	系統就不能把模板大小限制設的大一點嗎？？？	9	5	Ericliu1912	2025-12-02 17:54
8	是否需要啟用ProtectionIndicator	8	5	Hamish	2025-12-01 23:25
9	分類關鍵字	8	4	Ericliu1912	2025-11-21 13:23
10	近期的格式變更導致在編輯記錄中標示使用者權限小工具顯示異常	20	7	SunAfterRain	2025-12-03 00:37
11	關於{{VG titles/item}}的顯示問題	2	2	Ericliu1912	2025-12-02 19:30
12	為什麼Template:Deprecated_template本身被分類進了Category:已停用模板？	6	4	Sksawf	2025-12-07 14:25
13	兩技術問題請教	10	7	迴廊彼端	2025-12-03 12:55
14	提請保護等提報頁面能否增加對單個提報的訂閱	3	2	Luoniya	2025-12-01 21:22
15	2025年第49期技術新聞	1	1	MediaWiki message delivery	2025-12-02 02:54
16	行動版網頁預設展開標題測試	3	2	SunAfterRain	2025-12-02 09:37
17	關於目前Module:Redirect Template List的修訂版本導致Template:Redirect Template List產生腳本錯誤的問題	1	1	臺灣象象	2025-12-02 23:05
18	檢討在存檔討論時展開模板的做法	6	3	Srapoj	2025-12-04 05:37
19	關於維基專題評級統計數字不符的疑問	4	4	-Zest	2025-12-05 01:33
20	跨語言連結增強工具更新	1	1	Diskdance	2025-12-04 23:57
21	行動版的「相關頁面」沒有繁簡轉換	2	2	魔琴	2025-12-05 18:58
22	從Wikipedia:互助客棧/方針到相關英文網頁的跨語言連結出現錯誤	2	2	魔琴	2025-12-06 03:14
23	如何安裝用戶工具	3	3	PexEric	2025-12-06 14:26
24	2025年第50期技術新聞	1	1	MediaWiki message delivery	2025-12-09 01:41
25	被封禁用戶的邀請討論通知	3	2	Luoniya	2025-12-10 11:49
26	您必須再次登錄以證明您是Sksawf。	2	2	范	2025-12-10 11:54
27	iOS移動網頁一直出錯	1	1	Infodump0	2025-12-10 22:52

發言更新圖例
最近一小時內
最近一日內
一週內
一個月內
逾一個月
特殊狀態
已移動至其他頁面 或完成討論之議題
手動設定
當列表出現異常時， 請先檢查設定是否有誤

正在廣泛徵求意見的議題

議題清單

以下討論需要社群廣泛關注：（重新整理） 維基百科技術議題與模板

Template talk:新增條文 § 新增條文和刪除條文的暗色模式問題

爲解決{{新增條文}}和{{刪除條文}}在暗色模式下的顯示問題，現提議修改這兩個模板以適配暗色模式，有兩個方案，演示如下：

	一般檢視，修改前後應無分別。上至下： {{新增條文}}、{{刪除條文}} {{新增條文/sandbox}}、{{刪除條文/sandbox}}
	暗色模式，上至下： {{新增條文}}、{{刪除條文}} {{新增條文/sandbox}}、{{刪除條文/sandbox}}（1F616EMO版） {{新增條文/sandbox2}}、{{刪除條文/sandbox2}}（魔琴版）

以上，邀請社羣討論，另知會@魔琴，邀請@SunAfterRain、Xiplus、暁月凛奈。--1F616EMO（喵留言～回覆請ping～求助？） 2025年8月4日 (一) 14:58 (UTC)

Template talk:Editnotice load/core § 編輯請求 2025-08-09

此討論正在公示7天，直至2025年12月13日 (六) 20:53 (UTC)結束，如有意見，請盡快提出。

修訂用詞，將Page notice對應連結文字由「編輯提示」改為「頁面提示」。--Dabao qian℡ 2025年8月9日 (六) 19:55 (UTC)

Module talk:Location map/data/Palestine § RfC：巴勒斯坦國使用的地理位置圖

目前英文維基百科使用File:Palestine location map wide.png（）作為巴勒斯坦國的位置地圖，範圍包括以色列全境；而Commons上亦存在File:West Bank and Gaza Strip location map.svg（），其範圍放大至加沙和西岸的周圍地區。個人認為放大後的圖片更加清晰準確，尤其利於巴勒斯坦國世界遺產列表這種需要密集標注的情形，但不清楚社群的偏好。

因此在此開啓RfC，徵求社群關於這一議題的意見：巴勒斯坦位置地圖應——

• A：顯示以色列全境；
• B：放大至西岸和加沙走廊。

--Nebulatria 2025年11月11日 (二) 23:01 (UTC)

Wikipedia:互助客棧/方針 § 移除對Tor用戶獲得自動確認的額外限制

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

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

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

Wikipedia talk:重定向 § 非中文重定向分類

當前版本，非中文重定向的情況非常多，應該具體分類以便後續維護，以及可能的存廢舌戰。

1. 該外文文本常常直接（不出現相應中文）在中文語境使用，通常為字母詞和英語詞
2. 該外文文本是專有名詞（如人名、地名、作品名、公司名等），且該外語專名和外語語種與目標條目有明確聯繫，尤其是條目標題對應語言的外文專名
   • 若該外文文字不是拉丁字母，通常也可建立對應的羅馬化轉寫文本作為重定向，除非該專名的羅馬化轉寫在中文語境的出現率明顯低於原文（如一些通常以漢字形式出現的原文僅由漢字組成的日語人名、地名等）。若羅馬化轉寫形式不止一種，社群對「是否應建立所有形式的羅馬化文本」未有共識
   • 若該外語不是英語，通常也可建立對應英語的外文重定向，除非英語名稱在中文語境的出現率明顯低於原文名
3. 使用該外語的文化與目標條目有明確聯繫，且外文文本所指事物是目標條目的介紹對象（如使用外語的某一民族的特色飲食的外文名稱）
   • 若該外文文字不是拉丁字母或該外語不是英語，可建額外的羅馬化重定向與英語重定向的規則和上條相同
   • 若該外文文本僅是描述性的（多個單詞的簡單組合），例如「cinema of the United Kingdom」（英國電影），一般不要建重定向
4. 鑑於英語是大部分學術領域的國際通用語言，且大量學科術語中文譯名不統一、不固定（甚至尚無可靠來源譯名），故建議創建通用的專科術語英語名重定嚮導向到對應的條目（除非相關領域學術研究使用中文的情況明顯多於英語）。中英術語對照可參考術語在線（中國大陸）、樂詞網（台灣）等網站，以及各類百科全書、專科辭典、專著、論文等（極少數學術詞彙並非英語，也可比照創建）
5. 生物學名（包括物種名和屬名等分類單元的學名）、國際非專利藥品名稱（INN）等規範名或通用名
6. 其他常會在中文語境（包括中文文本的括注中）出現的外文文本
7. 其他有合理期望中文使用者會使用外文文本指稱目標條目的情況。創建者需在重定向討論頁（或編輯摘要）說明創建理由

參考資料

當前已有「某語重定向」的分類在語言維度分類所有非中文重定向，這裏建議在功能這一維度分類爲：

1. 外語詞語重定向
2. 外文專有名詞重定向
3. 外語文化重定向
4. 外文術語重定向
5. （其他對應類別，如「學名重定向」）
6. （不特殊規定）
7. （不特殊規定）

並通過類似於{{重定向類別|ISO 639語言代碼}}的方式分類到對應的子分類中，如

1. 英語詞語重定向
2. 英語專有名詞重定向
3. 英語文化重定向
4. 英語術語重定向

其中，Category:英語詞語重定向同時從屬於Category:英語重定向和Category:外語詞語重定向。

所有「語言維度」分類從屬於Category:按語言分類的非中文重定向，所有新的「功能維度」分類*從屬於Category:按功能分類的非中文重定向；二者從屬於Category:非中文重定向。

註：不包括最後三類，如「學名重定向」似乎應該進入「拉丁語術語重定向」。

例子：

mitosis→有絲分裂，標註{{外文術語重定向|en}}，使得其分類進Category:英語術語重定向。

• Category:非中文重定向
  • Category:按語言分類的非中文重定向
    • Category:英語重定向
      • Category:英語術語重定向
        • mitosis
  • Category:按功能分類的非中文重定向
    • Category:外文術語重定向
      • Category:英語術語重定向
        • mitosis

以上。 ——魔琴［留言 貢獻 PJ:小學 PJ:兩岸］ 2025年11月26日 (三) 06:55 (UTC)

Module talk:Check for unknown parameters § 編輯請求 2025-11-28

此討論正在公示7天，直至2025年12月13日 (六) 11:25 (UTC)結束，如有意見，請盡快提出。

跟進英文維基的更新（討論見en:Module talk:Check for unknown parameters），允許通過|mapframe_args=y批量載入Module:Infobox mapframe的全部有效參數。優勢：1、使用Module:Infobox mapframe的模板的已知參數列表，不需要複製粘貼大量參數名稱；2、日後Infobox mapframe參數發生改變時，僅需更新本模塊即可，不需要逐個更新模板。--Kcx36（留言） 2025年11月28日 (五) 08:08 (UTC)

Template talk:Rfc § RFC的RFC

現在似乎有位機器人每10分鐘就會把新出來的徵求意見討論加到頁面當中，因此，我提議：以上。--【超權威的L79】發布於 2025年11月29日 (六) 04:54 (UTC)

Template talk:WMF-legal banned user § 關於分類Category:被維基媒體基金會封禁的維基人

該模板會把用戶加入分類Category:被維基媒體基金會封禁的維基人，但這是錯誤翻譯，因為Wikipedia:禁制#基金會行動禁制已經明確說明維基媒體基金會的行動被稱為禁制而非封禁，因此此分類應該移動到Category:被維基媒體基金會禁制的維基人。--Ascchrvalstr（留言） 2025年11月29日 (六) 21:31 (UTC)

Wikipedia talk:快速刪除 § 再提使用機器人處理O7

承前討論等，本地現行的O7條款已適應性平衡過度刪除草稿內容的情況，故提議將適用O7條款的頁面交由機器人自動執行刪除，且在刪除前7日發送通知至頁面創建者用戶討論頁以期拯救部分草稿。--Hamish T 2025年11月30日 (日) 10:41 (UTC)

Wikipedia talk:刪除 § 釐清提刪模板模組前的必要手續

在Module:Check for unknown parameters 2的存廢討論中，我和@Kcx36就是否可以直接提刪模板保護的模板模組進行了一番爭論，然完全無法討論出一個結果。有鑑於每次未完全清理引用的模板模組都會引起不必要的麻煩，希望社群就非特殊案件提刪模板模組前的先決條件進行討論，包含：

1. 帶有保護狀態的是否可以直接提刪，抑或是需要先將引用清除到得以移除保護？若是，需要給半保護開例外嗎？
2. （假設引用涉及到更改大量頁面，非少數編輯（請求）能解決）提刪前需要先清理全數引用，包括但不限於替換引用、標記模板已停用？抑或是需要先使用RFC先執行這些程序？還是在存廢討論達成共識後再來想辦法移除引用？

註：本提案不參與DP#9的提刪條件的爭論，只是要釐清流程應該事先處理還是交到存廢討論後再處理比較妥當，就我個人觀點應該先清除引用以免造成長時間卡在存廢討論不了了之。

副@-Zest--SunAfterRain 2025年12月1日 (一) 23:57 (UTC)

Wikipedia:互助客棧/技術 § 應將Category:各日出生和Category:各日逝世的參數加入Template:Bd模板

再次徵求意見。若一般討論遲遲未能達成共識，唯有考慮定期表決。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年12月2日 (二) 09:40 (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)

小意見：可以寫成直接字符串拼接，因為用frame:extensionTag會生成出，略為囉嗦。--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的應該只有這一段文本，不算太長吧。但從性能的角度說我不覺得把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的小更新（？）。

雖說在輸出里加個本質也是小更改，然而我會擔心在沒有維護者的情況下向屎山堆砌結構修改會令它滑向縫合怪（我承認這像是滑坡謬誤，又沒有參數變化之類的，想不到會怎麼阻礙未來的鏟屎者把它炸了重來，頂多需要兼顧其他使用這個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模板

如題，考慮到兩個分類都沒有提刪成功，近期也有人手動添加，不如直接相關參數引入生卒年份模板，一勞永逸。--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小工具是否需要移除？ Stang¹¹⁶⁰ 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尚不支持。 Stang¹¹⁶⁰ 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)

不覺得有什麼簡單的方法解決這個問題，沒有狀態的東西自然沒法記錄出現了幾次。不如從你加重定向的小工具入手看看哪裡出了問題。 Stang¹¹⁶⁰ 2025年11月18日 (二) 01:11 (UTC)

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

改善字體的討論怎麼又死了

• Wikipedia:互助客棧/技術/存檔/2025年10月#「修復」「半角」間隔號
• Wikipedia:互助客棧/技術/存檔/2025年10月#部署Chromium_Windows字體改善小工具

 ——魔琴［留言 貢獻 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)

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

--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期技術新聞中抽出來。本站是否有意向啟用頁面狀態指示器？它可以在被保護頁面的右上角顯示一個鎖的圖標，基本取代了添加保護模板的操作。 Stang¹¹⁶⁰ 2025年11月18日 (二) 01:22 (UTC)

管理員操作方式是否需要調整？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年11月19日 (三) 09:29 (UTC)

要調整Twinkle的默認配置。我記著使用Twinkle保護頁面的時候，默認情況會添加一個帶small=yes參數的保護模板；如果啟用了指示器，就不需要默認添加了。同時可以把保護模板的small參數刪掉，只在需要顯示橫幅的時候手動添加保護模板。 Stang¹¹⁵⁷ 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維護人員。 Stang¹¹⁴⁷ 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)

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

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

原標題：MediaWiki:Gadget-MarkRights.js爆開了。修改者：SunAfterRain 2025年11月27日 (四) 12:47 (UTC)

於Phabricator追蹤
工單T392775

原先的實現功能是「在編輯記錄中標示用戶權限」，但是這個js的運行邏輯發生了變化，變成全站運行，在顯示上直接把所有user link全部爆開了。--${\mathfrak {Kurwa}}$__^{(´▽`ʃ♡ƪ)} 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)

這個沒問題，原本就這樣。--${\mathfrak {Kurwa}}$__^{(´▽`ʃ♡ƪ)} 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仍然未修復。--${\mathfrak {Kurwa}}$__^{(´▽`ʃ♡ƪ)} 2025年11月29日 (六) 14:21 (UTC)

如參見File:第7任總統蔣經國先生玉照.jpg和Special:WhatLinksHere/File:第7任總統蔣經國先生玉照.jpg（limits=500）。--${\mathfrak {Kurwa}}$__^{(´▽`ʃ♡ƪ)} 2025年11月29日 (六) 14:23 (UTC)

@Kurgenera：也 已修復，請複查。--碟之舞📀💿 2025年11月29日 (六) 14:30 (UTC)

@Diskdance：Special:WhatLinksHere還是壞的，不過文件頁修好了。--${\mathfrak {Kurwa}}$__^{(´▽`ʃ♡ƪ)} 2025年11月29日 (六) 14:33 (UTC)

啊，看錯了……現在應該好了。--碟之舞📀💿 2025年11月29日 (六) 14:38 (UTC)

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

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

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

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

--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]
• 已新建兩個維基：
  • 道本語維基百科 (w:tok:) [6]
  • 奈及利亞皮欽語維基語錄 (q:pcm:) [7]

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

• 本週軟體更新細節： MediaWiki

深入了解

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

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

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

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

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

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

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

• WikiProject:廣州/評級：條目等級合計為 2,259，重要度合計為 2,264，兩者相差 5 個。
• WikiProject:香港/評級：條目等級合計為 10,222，重要度合計為 10,232，兩者相差 10 個。

為何這些核心統計數字會「對不上號」？懇請了解系統機制或相關站務的編者能提供解釋。謝謝。--自由米花🌾🌼 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)