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

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

发表新议题

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

公告欄

• [人事] 人间百态的管理人員申請意向調查舉行中，請踴躍參與討論。
• [公告] 废止快速删除准则O3款的提案已經通過，俟相关机器人任务停止后再予执行。
• [公告] 修改WP:FILEREDIRECT、整理檔案系列快速刪除規則的名稱與細則、調整有關「中國香港」、「中國澳門」兩詞的規定及整合有關「臺灣地區」、「臺澎金馬」等詞的規定已經通過。
• [公告] 調整快速刪除方針F1、F5與F7條的表述方式、重組快速刪除方針G15條，並增設全新快速刪除方針類別、確立WP:收錄標準/表演藝術人物為指引與修訂WP:收錄標準/人物及進一步訂正兩岸四地格式手冊有關「中國大陸」、「中國內地」等詞的使用規定正在公示，如有意見請盡快提出。
• [討論] 互助客栈正在討論人物出生及逝世日期分類問題、维基百科25周年和新年标志、移除对Tor用户获得自动确认的额外限制、修改Sidebar、再次提议“特色列表”改名、默认使用text-autospace为中英文之间添加空白的后续、整合大部分特定語言姓名標示模板至Family name hatnote及廢除語言模板中附上跨語言連結與語言幫助頁面連結的功能，歡迎踴躍參與。
• [討論] 社群正在討論釐清提刪模板模組前的必要手續，歡迎踴躍參與。

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

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	提議：高亮哈佛参考文献格式短鏈指向的完整資料引用	55	9	Dabao qian	2025-12-03 17:47
2	应将Category:各日出生和Category:各日逝世的参数加入Template:Bd模板	1	1	Ericliu1912	2025-12-22 18:18
3	自動清理重複重新導向模板標記	3	3	Stang	2025-11-18 09:11
4	改善字体的讨论怎麼又死了	12	6	PexEric	2025-12-21 15:56
5	介绍：WebFont-ZH服务及小工具	76	11	魔琴	2025-12-02 23:49
6	分類關鍵字	12	5	Ericliu1912	2025-12-24 03:05
7	检讨在存档讨论时展开模板的做法	7	4	Kanashimi	2025-12-25 08:47
8	中文字元與拉丁字母、數字之間在顯示上被自動加入空格	9	6	Sun8908	2025-12-21 22:24
9	分类:重定向级条目	6	3	Ericliu1912	2025-12-24 03:03
10	建议设置过滤器阻止在信息框内添加旗帜图标	7	4	MilkyDefer	2025-12-17 18:05
11	维基百科:新条目推荐/候选/自动筛选	4	2	Shizhao	2025-12-18 20:17
12	ProtectionIndicator已在本站启用	3	3	Hamish	2025-12-18 23:36
13	2025年第52期技術新聞	1	1	MediaWiki message delivery	2025-12-23 05:42
14	Wikipedia:鐵路系統標示/圖標列表與Wikipedia: 鐵路系統標示/圖標列表/車站#鐵路系統標示圖標的使用說明針對pBHF的定義解釋不一樣	3	3	Hamish	2025-12-25 07:25
15	New user message签名出错	3	3	Shizhao	2025-12-25 15:45
16	“CSS”和“已过滤的CSS”	3	3	1F616EMO	2025-12-26 13:41

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

正在廣泛徵求意見的議題

議題清單

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

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)

Wikipedia:互助客栈/方针 § 移除对Tor用户获得自动确认的额外限制

长期以来对于使用Tor进行编辑的用户，存在一种额外的限制约束他们获得自动确认状态。相较于其他用户在“注册达7天+编辑达50次”即可获得自动确认，通过Tor编辑的用户需要“注册达90天+编辑达100次”才能获得自动确认。

这一限制的必要性有待商榷：欲通过Tor编辑必须要申请IPBE权限，这意味着Tor用户必然实现经过了或多或少的人工确认。可能有用户认为“使用Tor的用户是破坏者的可能性更高，所以提高门槛存在必要”，但是我认为对于本站来说找不到支撑这个论点的证据。移除这一限制的另一好处是让判断一名用户有无获得自动确认更加简单，减少了一些可能的误解。结合其他社群来看，英文维基百科近期将这个额外限制移除了。

综上，建议本站移除对Tor用户获得自动确认的额外限制，让使用Tor进行编辑的用户也能在“注册达7天+编辑达50次”后获得自动确认状态。请求社群讨论，谢谢。 Stang¹¹⁶³ 2025年11月14日 (五) 09:15 (UTC)

Wikipedia:互助客栈/其他 § RfC：翻新新手引导系列页面

主要包括以下任务，邀请社群讨论批准。

1. 存档2011版新手入门，启用H:入门
   修改MediaWiki:Sidebar，包含一个“编辑入门”的链接指向H:入门
2. 将WP:参与贡献替换为文字版WP:新手简明指南，后者移动至前者命名
3. 存档WP:欢迎及其子页面，重定向至2的文字版参与贡献
4. 存档新手相关论坛：
   • WP:新手上路
   • WP:第一印象
   • WP:我是这样认识维基的
   • WP:我为什么写维基
   • WP:第一次编辑的感觉

--PexEric 2025年11月16日 (日) 13:14 (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)

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

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

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

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

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

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

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

Template talk:Delete § 編輯請求 2025-12-13

将“请勿移除本模板”改为“页面创建者或主要编修者请勿移除本模板”，并在O1理由下显示为“如果该用户页仅有您一名编辑者，且不是从其他地方移动而来，页面将在大约10分钟后由User:Xiplus-abot自动删除”--Sksawf（留言） 2025年12月13日 (六) 15:56 (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)

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

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

不知是否有此類機器人？案例在此。—— 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)

有人吗？--Sksawf（留言） 2025年12月15日 (一) 08:08 (UTC)

tq 似乎并没有设置字重，可能只是因为操作系统上的衬线字体不支持多字重而已。（标题的宋体在macOS上似乎很细？）--内存溢出的猫（留言） 2025年12月15日 (一) 10:29 (UTC)

Windows 11，未修改任何字体，未使用MacType等第三方工具--Sksawf（留言） 2025年12月15日 (一) 11:31 (UTC)

仿宋的字体风格就是如此。不过为什么要用仿宋？其实我挺不理解的。--PexEric 2025年12月21日 (日) 07:56 (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（[1]）或外部上游依赖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)

[2]，已更新繁体、香港繁体描述文字并调整部分措辞。--Dabao qian℡ 2025年12月1日 (一) 21:00 (UTC)

 已修复。--碟之舞📀💿 2025年12月2日 (二) 01:58 (UTC)

“字体／字型”没完全转换。--Dabao qian℡ 2025年12月2日 (二) 04:39 (UTC)

 已修复。--碟之舞📀💿 2025年12月2日 (二) 07:48 (UTC)

這是地區詞？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年12月2日 (二) 09:55 (UTC)

至少在Windows里确实是。--Dabao qian℡ 2025年12月2日 (二) 12:53 (UTC)

印象里有人说font对应“字型”、typeface为“字体”、glyph为“字形”，但感觉有些传统概念在DTP普及后就发生了一些断裂，本粗人没有深究，怕被佶屈聱牙的东西误导。--Srapoj（留言） 2025年12月2日 (二) 15:35 (UTC)

参见字体 (消歧义)。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年12月2日 (二) 15:49 (UTC)

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

分類關鍵字

是否能建立機器人，清理重疊於標題的分類關鍵字？例如某模板標題為「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)

詢問下@-Zest：此是否可行？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年12月16日 (二) 07:03 (UTC)

可行，這邊更改一下再送申請。---Zest 2025年12月16日 (二) 08:29 (UTC)

感謝！—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年12月23日 (二) 19:05 (UTC)

年份作为分类关键字、与标题开头重叠的情况，可能是从英文维基带过来的，因为英文的标题中年份并不在开头。

Wikipedia:机器人/申请/Zestbot/9与本案并不一样，该机器人清理的是某分类的排序字与分类名称重复，不考虑页面名称是什么；而本案要清理的是分类排序字与页面名称开头重复。Ericliu1912的这条回复似乎也混淆了……--Kcx36（留言） 2025年11月19日 (三) 11:11 (UTC)

對，不少用例來自英文維基百科，所以到時候可能要設定為定期任務。倒是我的回答沒混淆什麼吧？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年11月21日 (五) 05:23 (UTC)

某用户创建的物种条目里会有[[Category:XXX科|_XXX科]]这样的分类，这一类型也需清理。--。->>Vocal&Guitar->>_留言 2025年12月16日 (二) 01:18 (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)

需要注意的是，我之前曾有個任務要處理Wikipedia:新聞動態候選歷史，卻發現 {{ITNc}} 會被展開存檔，造成機器人很難判別，只好放棄。假如沒展開的話，就很容易搜尋與判別歷史紀錄。因此我個人傾向能不展開就不展開。真有過大改變造成顯示上的問題，不如改名模板，並請機器人把成引用舊模板就好。--Kanashimi（留言） 2025年12月25日 (四) 00:47 (UTC)

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

中文字元與拉丁字母、數字之間在顯示上被自動加入空格

中文字元與拉丁字母、數字之間在顯示上被自動加入空格，不知道是何時的改動？Sanmosa _新朝雅政 2025年12月15日 (一) 02:17 (UTC)

几乎所有页面都被改动了。(！)強烈抗议此次修改，deltalk极不方便，还违反MOS:SPACE。--${\mathfrak {Kurwa}}$__^{( •̀ ω •́ )＜✧} 2025年12月15日 (一) 03:33 (UTC)

各位，上面討論好幾個月了，也有經過正規公示程序。另外，沒有違反格式手冊，因為並非手動加入空格，而是以技術手段自動排版。我個人的建議是，減少自動排版所用空格間距，方便與應予清理的手動空格相區別，不然確實對編者不便。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年12月15日 (一) 04:48 (UTC)

是的。如果要关闭可以在参数设置中关闭“^预改善中文与其他字符混排时的字距 [文档]”小工具。--碟之舞📀💿 2025年12月15日 (一) 05:03 (UTC)

我建议还是暂时不要默认启用为好--百無一用是書生 (☎) 2025年12月16日 (二) 07:42 (UTC)

這點可以徵詢社羣的意見。Sanmosa _新朝雅政 2025年12月16日 (二) 10:57 (UTC)

想請問可以把全形括號改回原本的樣子嗎？我編輯的時候分辨不了是全形括號還是半形括號。（吐槽：因為標點符號都連在一起，我還以為我手機壞了。）-- Sun8908 2025年12月21日 (日) 14:24 (UTC)

以及默认情况下排除了各种编辑界面（包括文本框和可视化编辑器），不会加空白。--碟之舞📀💿 2025年12月15日 (一) 05:23 (UTC)

另外，之前一直没有提到，给元素加上gadget-nospace class可以排除加空白。--碟之舞📀💿 2025年12月17日 (三) 02:15 (UTC) 👍1

分类:重定向级条目

到現在還有一大堆，「重新導向級某某條目」分類應該移動到「重新導向級某某頁面」、條目也應該重新歸類，但我找不到哪裡參數還沒改掉。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年12月15日 (一) 05:12 (UTC)

其实我觉得重定向级可以根据命名空间细分条目和页面，前者作为后者的子分类。不过我在想，追踪非条目命名空间的重定向真的有意义吗？--PexEric 2025年12月15日 (一) 06:00 (UTC)

目前評級系統是不區分条目與页面的，不是條目，就是頁面。後者通常是一些非優先頁面，改成上下關係的話，會造成許多疊床架屋。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年12月15日 (一) 12:41 (UTC)

因为当初完全是乱搞，本来所有都是条目从来也没事，非要正个屁名。评级系统到现在连繁简问题都搞不定，生成的繁简混用分类还有一大堆卡在那边。--。->>Vocal&Guitar->>_留言 2025年12月16日 (二) 01:13 (UTC)

沒辦法，社群改革很多時候都是改半套。現在要嘛清理完，要嘛取消更改，卡在中間總不是辦法（隔壁方針區「典範」、「特色」的問題也是）。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年12月16日 (二) 12:52 (UTC)

至少也應該確認標準用法為何吧？問問@A2569875。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年12月23日 (二) 19:03 (UTC)

建议设置过滤器阻止在信息框内添加旗帜图标

例如 Special:Diff/90534255/90534316 --Sksawf（留言） 2025年12月15日 (一) 08:06 (UTC)

範圍太廣了，不可能。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年12月15日 (一) 12:48 (UTC)

按目前指引，也不是所有資訊框都不能使用旗幟圖標。--迴廊彼端（留言） 2025年12月15日 (一) 13:12 (UTC)

那就先警告，提醒用户检查一下是不是Wikipedia:格式手册/图标#避免在資訊框使用旗幟圖標的允许情形--Sksawf（留言） 2025年12月15日 (一) 14:43 (UTC)

設過濾器是否觸發頻率太高？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年12月15日 (一) 21:06 (UTC)

能否单独匹配“国籍”和“出生地”这两个参数？--Sksawf（留言） 2025年12月16日 (二) 05:33 (UTC)

我覺得現有的過濾器語法很難做到。完全基於正規表達式，在有限的資源下做不成語法分析，形同上下文無關。--MilkyDefer 2025年12月17日 (三) 10:05 (UTC)

维基百科:新条目推荐/候选/自动筛选

维基百科:新条目推荐/候选/自动筛选中，凡是user:*angys*创建的条目均无法显示，应该是其用户名的原因，导致T:ndyk无法正常调用。希望有能力的人能够解决此问题--Luoniya（留言） 2025年12月16日 (二) 21:28 (UTC)

修了一下，虽然用户名显示还有问题，但至少表格不会错乱了--百無一用是書生 (☎) 2025年12月18日 (四) 03:25 (UTC)

我发现这个列表似乎还会字词转换用户名--Luoniya（留言） 2025年12月18日 (四) 04:33 (UTC)

页面没有使用任何转换表--百無一用是書生 (☎) 2025年12月18日 (四) 12:17 (UTC)

ProtectionIndicator已在本站启用

见phab:T412710，另帮助文档：mw:Help:Protection indicators--百無一用是書生 (☎) 2025年12月17日 (三) 03:07 (UTC)

{{pp-meta}}系列模板需要适配一下了，现在右上角显示两个保护图标:( --ChasingAir^留言 2025年12月17日 (三) 16:19 (UTC)

已修訂。--Hamish T 2025年12月18日 (四) 15:36 (UTC)

2025年第52期技術新聞

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

近況更新 - 面向編輯者

• 明年1月起，編輯過濾器可以設定成自動監督隱藏過濾器詳情，這包括觸發條件以及觸發過濾器的編輯和操作等。監督員可以用這項功能來防止個人資料外洩或其他應隱藏內容的傳播。 [3]
• 因應年末假期，下一期技術新聞將於2026年1月12日發送。感謝今年所有協助翻譯、貢獻內容以及提供寶貴意見的各位。
• 上週有16件由社群提交的工單得到解決。 例如，先前在Android版維基百科年度回顧功能中，點擊「第一步」時可能會發生崩潰，現已修正此問題，該功能可正常開啟。 [4]

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

• 過去，MediaWiki生成的介面元素（如差異比較與分類）會用data-mw="interface"屬性來區別於維基內容。此屬性現已改為data-mw-interface=""，以避免與由Parsoid生成的其他data-mw屬性產生潛在衝突。 [5]
• 本週及下週沒有MediaWiki版本更新。

會議與活動

• 2026年西北歐維基媒體黑客松將於2026年3月13日至14日在荷蘭阿納姆舉行。報名期限為12月中旬至1月中旬，額滿即止。場地僅能容納約100人，請盡早報名。

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

MediaWiki message delivery 2025年12月22日 (一) 21:42 (UTC)

Wikipedia:鐵路系統標示/圖標列表與Wikipedia: 鐵路系統標示/圖標列表/車站#鐵路系統標示圖標的使用說明針對pBHF的定義解釋不一樣

希望能查明pBHF究竟為快車停靠站或是附帶越行線的車站，這對頁面會有許多的影響--~2025-42516-56（留言） 2025年12月23日 (二) 17:56 (UTC)

根據c:BSicon/Catalogue，p前綴的定義為「partial service」，應較為貼近「快車停靠站」。--1F616EMO（喵留言～求助？） 2025年12月23日 (二) 23:31 (UTC)

我感覺“快車通過不停車的車站”是“豎直方向客運車站 線路中間站，帶越行線”的一種吧，前者是常見的“帶越行線的線路中間站”的一種，後者算是對這個車站本身特點的定義，似乎不衝突？--Hamish T 2025年12月24日 (三) 23:25 (UTC)

New user message签名出错

Special:diff/90824366。--${\mathfrak {Kurwa}}$__^{( •̀ ω •́ )＜✧} 2025年12月25日 (四) 03:08 (UTC)

• @PexEric、Shizhao：原因是Special:Diff/90800408，機器人會自動補上簽名，而加入~~~~，將會產生機器人的簽名。 Willy1018（留言） 2025年12月25日 (四) 03:30 (UTC)

   已修复--百無一用是書生 (☎) 2025年12月25日 (四) 07:45 (UTC)

“CSS”和“已过滤的CSS”

页面……必须具有内容模型“已过滤的CSS”用于模板样式（目前的内容模型是“CSS”）。

这两个是什么意思？--${\mathfrak {Kurwa}}$__^{( •̀ ω •́ )＜✧} 2025年12月26日 (五) 00:42 (UTC)

页面的内容类型。无限制的CSS与有所限制而安全的CSS。类型仅限管理员修改。[6]。--YFdyh000（留言） 2025年12月26日 (五) 00:59 (UTC)

若希望在模板空間以外的地方使用模板樣式（如用於用戶頁），可先在Template:沙盒/TemplateStyles的子頁面創建模板樣式，然後移動至目標頁面。--1F616EMO（喵留言～求助？） 2025年12月26日 (五) 05:41 (UTC)