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

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

发表新议题

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

公告欄

• [分享] 2026年1月15日是维基百科成立25周年，一起写下你对维基百科的美好祝愿！
• [人事] Dbeef的管理人員申請意向調查舉行中，請踴躍參與討論。
• [人事] 人间百态與Ppolar bear自荐成为管理员，歡迎參與討論和投票。
• [公告] 维基百科25周年标志、Template:Nfur2合併到Template:Nfur、調整微小修訂簡易規定的條文及調整有關選秀節目參賽者的收錄標準已經通過。
• [公告] 將生者傳記方針的適用範圍擴大到最近逝世者、事實性修訂有關草稿化的操作的說明、移除对Tor用户获得自动确认的额外限制、訂正兩岸四地格式手冊有關「中國內地」等詞的使用規定、更新電子遊戲格式手冊「译名注释」內容及明确代替被封禁或禁制用户进行编辑的责任正在公示，如有意見請盡快提出。
• [討論] 互助客栈正在討論Reaction小工具加入MediaWiki:Gadgets-definition、维基百科25周年和新年标志、修改Sidebar、再次提议“特色列表”改名、默认使用text-autospace为中英文之间添加空白的后续及提議商定被無限期封鎖者是否應默認除權，歡迎踴躍參與。
• [討論] 社群正在討論人物出生及逝世日期分類問題、釐清提刪模板模組前的必要手續、美国不受著作权保护但在来源地受保护的文件是否为非自由文件、有關非編號命名的城市軌道交通鐵路綫的條目命名及「公共汽車」條目與「巴士」條目的重組，歡迎踴躍參與。

• [協作] 现有174个页面需维基化，631个条目需清理，15个移动请求正在讨论。
• [獎勵] 現有1名用户獲提名维基奖励，欢迎投票。

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	提議：高亮哈佛参考文献格式短鏈指向的完整資料引用	55	9	Dabao qian	2025-12-03 17:47
2	自動清理重複重新導向模板標記	3	3	Stang	2025-11-18 09:11
3	改善字体的讨论怎麼又死了	13	7	逐风天地	2026-01-13 11:08
4	介绍：WebFont-ZH服务及小工具	83	11	PexEric	2026-01-15 15:41
5	分類關鍵字	12	5	Ericliu1912	2025-12-24 03:05
6	中文字元與拉丁字母、數字之間在顯示上被自動加入空格	16	8	Ericliu1912	2026-01-12 10:41
7	Wikipedia:鐵路系統標示/圖標列表與Wikipedia: 鐵路系統標示/圖標列表/車站#鐵路系統標示圖標的使用說明針對pBHF的定義解釋不一樣	7	5	Srapoj	2026-01-10 02:47
8	內容翻譯所加入的維護分類	5	5	Shizhao	2025-12-30 17:19
9	徵求意見：Reaction 小工具加入 MediaWiki:Gadgets-definition	40	7	SunAfterRain	2026-01-12 23:27
10	請求修復語言模板追蹤分類	7	4	Ericliu1912	2026-01-08 00:14
11	Undrfined 連結	2	1	Kanshui0943	2026-01-05 23:08
12	Request for Translation of LanguageConverter documentation	13	5	Cscott	2026-01-10 14:34
13	{{Infobox person}}签名问题	5	3	Vozhuo	2026-01-13 09:49
14	將鐵路機廠的RDT圖標 (DST)更改為YRD	1	1	~2026-17210-0	2026-01-09 19:38
15	提議公開過濾器39	1	1	Ghren	2026-01-10 00:41
16	新條目推薦候選頁面字詞轉換問題	2	2	優枰	2026-01-13 05:18
17	修改Module:Citation/CS1的语言显示问题	2	1	Kurgenera	2026-01-12 17:32
18	2026年第3期技術新聞	1	1	MediaWiki message delivery	2026-01-13 03:30

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

正在廣泛徵求意見的議題

議題清單

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

Module talk:Article history/config § Module:Article history/config自动添加Category有歧义

最近在看优良条目广州市时发现，该条目之前多次参与优良条目评选和优良条目重审，导致其讨论页Talk:广州市的Special:Categories同时拥有Category:優良條目討論和Category:已撤銷的優良條目。通过找config的代码发现，问题应该是出现在第1376行。而解决的方法应该是仿照第306行起的GA，将categories这一参数放到statuses里面第335行的DGA下而不是放到1376行的地方，FA典范条目亦同理。如果有管理员或对Lua语言熟悉的模板编辑员请协助修改。副知@Shizhao。--Cygz（留言） 2025年10月24日 (五) 18:32 (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)

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

跟进英文维基的更新（讨论见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)

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

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

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

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

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

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

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

Template talk:电视节目信息框 § 建議自動調用Wikidata

一如Template:电影信息框，建議能夠調用Wikidata且比較重要的欄位使用Wikidata資料自動填充，以免人力逐一填寫之苦。--— Gohan 2025年12月29日 (一) 09:36 (UTC)

Template talk:Db-notice § 速刪通知模板不應不分皂白用「內容不當」字眼

現在{{db-notice}}無論速刪理由如何都會使用「內容不當」字眼，但部分速刪理由（例如廢棄草稿、剪貼移動）並非「內容不當」，此字眼或會造成誤會或嚇到新手。建議刪除「內容不當」字眼，是否代以其他字眼或按具體速刪理由切換字眼則無意見，就上述兩點提請社羣討論。--1F616EMO（喵留言～求助？） 2026年1月2日 (五) 09:00 (UTC)

Template talk:Jpn § 編輯請求 2026-01-05

改以{{langx}}模板為基礎，並有效化自定義提示文字。Sanmosa _新朝雅政 2026年1月5日 (一) 10:11 (UTC)

Template talk:Kor § 編輯請求 2026-01-05

改以{{langx}}模板為基礎，並有效化自定義提示文字。Sanmosa _新朝雅政 2026年1月5日 (一) 10:11 (UTC)

Template talk:文物保护单位 § 編輯請求 2026-01-07

WP:格式手冊/無障礙/2025#颜色指出“部分讀者有色盲、色弱或視覺障礙。請確保文字與背景的對比度最少能達到Web內容無障礙指南（WCAG）2.0的AA等級，且儘量達到AAA等級”。現時{{文物保护单位}}所採用的文字底色為#FFCC99，然而WebAIM網上對比度檢查器的測試結果顯示該顏色與正常字體大小的內部連結的顏色的對比度無法滿足WCAG AA的要求（未曾點入的內部連結：#3366CC，曾點入的內部連結：#6A60B0），因此現建議比照{{Designation/divbox}}的設定調整底色部分為1毫米的#FFCC99顏色邊框與#FAEEE1（#FFCC9940）顏色的文字底色，使文字底色與正常字體大小的內部連結的顏色的對比度滿足WCAG AA的要求。Sanmosa _新朝雅政 2026年1月7日 (三) 13:23 (UTC)

Wikipedia:互助客栈/技术 § Request for Translation of LanguageConverter documentation

I am working on improving Parsoid's support for LanguageConverter (phab:T380517) and in order to create good test cases it would be helpful to have a full translation of zh:Help:AC in a form which could be maintained as documentation. There was a start made at mw:Writing_systems/LanguageConverter but only the first section was translated. (There is also mw:Writing_systems/Syntax which is a translation of zh:Help:高级字词转换语法 and covers some of the same material, and the relationship between these pages is unclear. Which should be considered authoritative?)

Ideally we'd set this up using the translate extension as a translated document so we could track changes back and forth. There's an error on the translated mw:Writing_systems/Syntax page in the "Combined conversion flag" section (zh-hant and zh-tw actually have the same output as zh-hk in my tests) which appears to be present in the source document zh:Help:高级字词转换语法 as well; it would be good to have a means to make such corrections and have them applied to all the translated versions.--Cscott（留言） 2026年1月7日 (三) 15:56 (UTC)

Wikipedia talk:页面评级 § 分类:重定向级条目

問問社群的看法。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年1月9日 (五) 14:27 (UTC)

Template talk:Hang on § 有关本模板在文件命名空间的使用

此处针对F3、F4、F6、F8、F9、F10这几个快速删除准则，这几个均应在提报5日后删除文件（若无反对意见），即在挂上模板5日后进入快速删除候选分类。但是，如果相关用户提前使用hang on模板申诉，会导致文件直接进入快速删除候选分类（出现在议标记下），有可能导致文件被提前删除（这种问题发生过多次）。所以想提一下有没有什么方法来避免这个问题，之前我想要不要让对这几个的反对直接进文件存废讨论，不过我看前面讨论有说转交速删本来就不是面向新手，我觉得要么就在这个模板中加参数来探测命名空间，让文件命名空间的速删加一个新分类然后过几天再进速删分类？还是怎么搞合适，还是维持现状？期待大家的想法，谢谢。--在下荷花，请多指教（欢迎签到） 2026年1月15日 (四) 09:01 (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)

这两天我在电脑上打开维基百科，加粗和斜体的汉字感觉显示怪怪的，是我电脑设置出了问题，还是中维搞了调整？--大化國史館從九品筆帖式（留言） 2026年1月13日 (二) 03:08 (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)

差不多一个月。今天看了一下后端，已稳定运行34天，重启数0。Plangothic生成了1184个单字符字体文件，WenJinMincho生成了348个单字符字体文件。没见到多字符的，可能和小工具设计有关，不过大多数页面本来就一两个僻字。--PexEric 2025年12月27日 (六) 08:40 (UTC)

应该可以转正。现在只需要考虑是继续用Toolforge单字体，还是把Plangothic或者WenJinMincho上传到ULS？--碟之舞📀💿 2025年12月28日 (日) 07:08 (UTC)

如果有意向，可以继续推进。维持现状的话，运维压力也不大。我就无所谓了，权衡利弊，我觉得目前的方案问题不大😂。--PexEric 2025年12月28日 (日) 07:25 (UTC)

要给小工具建一个Wikipedia空间页面吗，还是说这些讨论就地存档即可？--Srapoj（留言） 2026年1月8日 (四) 16:11 (UTC)

我建議建一個頁面。另外最好寫個文檔記錄一下僻字工具的技術細節，便於以後維護。 --SuperGrey (留言) 2026年1月8日 (四) 16:26 (UTC)

刚好看到W3C新出的草案：增量字体传输（Incremental Font Transfer）(demo)，或许未来可用于咱们这边？--百無一用是書生 (☎) 2026年1月9日 (五) 01:34 (UTC) 👍1

在客栈就地存档吧。文档我想一下怎么写。--PexEric 2026年1月15日 (四) 07:41 (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)

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

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

中文字元與拉丁字母、數字之間在顯示上被自動加入空格，不知道是何時的改動？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

text-autospace后续

先前讨论：Wikipedia:互助客栈/技术/存档/2025年12月#h-提议：默认使用text-autospace为中英文之间添加空白-20251017153500

先前的讨论存档了，故重启讨论。需要讨论的后续有：

1. 是否将行首的上引号、左括号等设为半角（trim-start效果）；
2. 关于是否需要默认启用额外的JS处理标题间距；
3. 是否/如何提示浏览器不兼容。

另外，先前提到的iOS上部分地方遗漏空白的问题疑似为WebKit bug。以及貌似<bdi>周围空白也会出现问题，是否是spec有意为之还是实现bug暂不得而知。

以上。--碟之舞📀💿 2025年12月28日 (日) 07:17 (UTC)

前兩項都支持。瀏覽器不兼容個人認為可以不提。 --SuperGrey (留言) 2026年1月8日 (四) 12:39 (UTC)

我用webkit nightly能够复现U:TimWu007之前报告的链接与数字间未加空白的问题。此问题应该算是webkit项目issue tracker里的bug 299306。

( π )题外话：如果其他人要在非苹果设备上测试WebKit/Safari，可以在Linux下用WebKitGTK的port（如Epiphany，即GNOME Web），Windows下可以找WinCairo port的二进制（参见文档和帖子，虽说从CI只能下载到nightly版的）。--Srapoj（留言） 2026年1月8日 (四) 22:14 (UTC)

不同意標點半角，不雅觀且容易誤會。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年1月9日 (五) 14:28 (UTC)

左邊為trim-start，右邊為normal

無論「還是“都沒有所謂半角、全角之分，這兩個符號都只有1種Unicode字符，故 @Ericliu1912說的「誤會」實在是不知所云。
至於雅觀與否。做了個擷圖，讓大家來評判。 --SuperGrey (留言) 2026年1月9日 (五) 21:44 (UTC)

而且如我先前所言，trim-start 是 W3C中文排版要求 § 行首行尾標點擠壓 之規範。文字「左端對齊」，個人認為遠比「留一個大空白、對不齊」要美觀多了。 --SuperGrey (留言) 2026年1月9日 (五) 21:48 (UTC)

可能簡體有問題吧，但繁體引號設計就是占一格。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年1月12日 (一) 02:41 (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)

c:File:BSicon pBHF.svg最初版本看起来是来自英维的，德语de:Wikipedia:Formatvorlage Bahnstrecke/Richtlinien#Symbolvorrat没有列出这个前缀。按我理解它指快车不停靠的车站。然而它的图片描述页的德语版本现在被误读成那种平时不开放的车站了（例如东铁线的马场站）。--Srapoj（留言） 2025年12月31日 (三) 23:35 (UTC)

前缀p在此处的解释有误

WP:铁路系统标示/图标列表#前缀示例：快车通过不停车的车站
c:BSicon/Catalogue/stations#Limited_service：Limited Service（有限服务）
c:BSicon/Catalogue#Examples：Station passed by express train（被快速列车经过不停的车站）
WP:铁路系统标示/图标列表/车站#客運車站圖標（本页面）：线路中间站，带越行线 ——这里的解释似乎违背了原意

在宁波轨道交通6号线RDT 的编辑冲突中，@~2025-41704-23和@~2025-42650-05根据此页面的解释回退了我的编辑，我感觉这是违背BSicon原意的。如有进一步的解释请提出。--TransportationMEE（留言） 2026年1月9日 (五) 16:52 (UTC)

另，在这一例子中汇士路和谢墅有提供直快列车越行的轨道，而其他只是不停站，并无越行线的配置--TransportationMEE（留言） 2026年1月9日 (五) 16:55 (UTC)

內容翻譯所加入的維護分類

如Category:維基數據存在坐標數據的頁面、Category:使用WikiMiniAtlas小工具的頁面等 ，見搜尋結果此項即數千條。可能還有其他分類。

這些分類只應該由相關模版加入的分類，經檢查是由內容翻譯或內容翻譯2代加入的，可以考慮用機器人移除，並使用過濾器禁止加入，是否有建議方式。是否可能在追蹤分類的相關模版如T:Tracking_category或T:Maintenance_category標註是只能由模版添加而不可手動添加的分類（同時作為機器人自動運行的依據），或者是Category:追蹤分類抑或擴大到Category:隐藏分类都不該被手動加入。

怎樣設置比較好，請社群提供意見。---Zest 2025年12月29日 (一) 18:08 (UTC)

反對使用過濾器，因內容翻譯觸發過濾器時不會留下記錄。可考慮向基金會反映問題，避免加入由模板加入的分類。對是否使用機器人無意見。--1F616EMO（喵留言～求助？） 2025年12月30日 (二) 02:05 (UTC)

加到Category:內容翻譯維護分類然后机器人批量清理？——暁月凛奈 (留言) 2025年12月30日 (二) 02:10 (UTC)

還有一種分類是「含有影片剪輯的頁面」、「含有某語言的頁面」（沒記錯的話），都是不應手動加入的自動分類，應一同考慮清理。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年12月30日 (二) 08:09 (UTC)

可以用机器人清理Category:追蹤分類中的页面--百無一用是書生 (☎) 2025年12月30日 (二) 09:19 (UTC)

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

徵求意見：Reaction 小工具加入 MediaWiki:Gadgets-definition

邀請大家討論：meta:Reaction 小工具是否可以加入 MediaWiki:Gadgets-definition？
此小工具自 2025 年 4 月推出以來，已經成為你維基礎設施之一 😄。希望能入庫「偏好設定」，供更多人快捷使用。

• 小工具定義：Reaction[ResourceLoader]|Reaction.js|Reaction-zh-hans.js|Reaction-zh-hant.js，建議放置於editing章節。
  • Gadget-Reaction.js、Gadget-Reaction-zh-hans.js、Gadget-Reaction-zh-hant.js 內容由 此 GitHub release 提供。
• 小工具描述：{{Gadget-desc|self=Gadget-Reaction|extwiki=1|user=1|name=Reaction|為你喜愛的評論添加反應表情。|doc=User:SuperGrey/gadgets/Reaction}}。

向大家徵求意見。 --SuperGrey (留言) 2026年1月1日 (四) 09:02 (UTC) 1 🔥2 (＋)支持1

初次了解该工具。能否有常用表情的菜单供选。有点担心用于（与判断是否属于）滥用和骚扰。悬停的工具提示的时间能否转本地时区。存档页中可能应禁止添加反应。--YFdyh000（留言） 2026年1月2日 (五) 13:49 (UTC) 👍1

感謝反饋！

表情選單確實可以做一個，我考慮考慮怎麼設計。

濫用和騷擾應該程度比較有限，這個小工具不發送通知，即使訂閱了也不會收到提醒。

本地時區也可以做，可能會做成設定。

存檔頁已經隱藏了反應功能，不過部分地方還有bug，我這幾天再改一改原始碼。--SuperGrey (留言) 2026年1月3日 (六) 01:33 (UTC)

✅除了本地時區之外的功能已實現。
本地時區有點不好做，主要是官方JS沒有提供函式，需要用API來實現（{{#time}}），但如果每個時間戳都要走API parse，作為小工具開銷有點大。不知SunAfterRain君有何建議？ --SuperGrey (留言) 2026年1月3日 (六) 11:25 (UTC)

不是有这个吗。--Hamish T 2026年1月3日 (六) 23:48 (UTC)

這是瀏覽器的函式，生成的也是瀏覽器的格式。wiki 上的我只找到 $wgLocaltimezone，但這也不能直接產生wiki規定的格式。 --SuperGrey (留言) 2026年1月4日 (日) 02:04 (UTC)

MediaWiki:Gadget-CommentsinLocalTime.js不能参考吗。--YFdyh000（留言） 2026年1月4日 (日) 02:07 (UTC)

他把脚本搬到meta去了，应该是有需要在其他wiki上能工作的考虑。--Srapoj（留言） 2026年1月4日 (日) 02:21 (UTC)

是的，現在小工具可以在所有wiki工作（ --SuperGrey (留言) 2026年1月4日 (日) 02:34 (UTC)

恕在下愚鈍，能生成瀏覽器的格式不就能直接在js中轉換為想要的格式了嗎？還是我理解有誤？--Hamish T 2026年1月4日 (日) 05:12 (UTC)

各wiki有定義自己的格式。比如在法語維基，就要用法語格式。這個沒有開放函式可用，只能API取得。--SuperGrey (留言) 2026年1月4日 (日) 05:15 (UTC)

噢我大概懂意思了，粗略看了一下source code，其實可以硬適配一下本站的本地時區（如果非要實現的話），其他站就。。。。--Hamish T 2026年1月4日 (日) 05:28 (UTC)

生成签名时间戳的地方是Parser::pstPass2，中文wiki的时间戳格式定义位于MessagesZh_hans.php的zh both。［如果真要做的话，］脚本里可以收集一些常用wiki的格式？

顺便看了眼DiscussionTools解析时间戳的实现，大致是根据格式定义生成出一个regex（CommentParser::getTimestampRegexp）。不过它要处理的本地化问题就多了，l10n是个巨坑。--Srapoj（留言） 2026年1月4日 (日) 05:38 (UTC)

腳本里可以收集一些常用wiki的格式附議。--Hamish T 2026年1月4日 (日) 05:41 (UTC)

我試試看（ --SuperGrey (留言) 2026年1月5日 (一) 00:30 (UTC)

做好了，看看效果（
另外自制了一個 tooltip popup，這樣可以在行動版檢視了（ --SuperGrey (留言) 2026年1月5日 (一) 02:42 (UTC) 😱1

之前有遇過使用者在存檔的討論裡補讚，暫時沒找到diff，建議要限制能在存檔頁使用。—提斯切里（留言） 2026年1月4日 (日) 05:51 (UTC)

已做限制，現在應該不能了。如有發現，煩請反饋。--SuperGrey (留言) 2026年1月4日 (日) 05:55 (UTC)

公示Reaction小工具加入MediaWiki:Gadgets-definition，為期7日，2026年1月15日 (四) 12:36 (UTC)結束。 --SuperGrey (留言) 2026年1月8日 (四) 12:36 (UTC)

复制讨论内容的时候“+反应”也会被复制上，能否考虑将按钮文字设为不可选中？--Kcx36（留言） 2026年1月8日 (四) 13:12 (UTC)

感謝反饋。我修改一下。 --SuperGrey (留言) 2026年1月8日 (四) 13:54 (UTC)

現在複製時應該不會選中「反應」按鈕了。 --SuperGrey (留言) 2026年1月8日 (四) 13:59 (UTC)

基于这是全站小工具，在下认为不宜操之过急，应暂停公示留待讨论。--Hamish T 2026年1月8日 (四) 13:24 (UTC)

行，那就再討論討論。 --SuperGrey (留言) 2026年1月8日 (四) 13:52 (UTC)

小工具是否默认启用？--Kcx36（留言） 2026年1月8日 (四) 14:14 (UTC)

我原以為不是。但按照Hamish管的意思，是希望此小工具預設啟用嗎？
如果需要預設啟用，則Gadget-Reaction.js內容可採v2.1.5 bundled.js程式碼（已更新到章節開頭）。預計小工具以後不會頻繁更新；如有更新的需求，再找管理員幫忙更新也行。 --SuperGrey (留言) 2026年1月8日 (四) 14:21 (UTC)

那我倒不是这个意思，我为可能带来的误解表示歉意。本意是因为互助客棧及徵求意見中的提案僅在7日內無新留言時或已討論達30日後，方可在已取得共識的前提下公示，如果这是一些小修订的话，忽略这个规则也没有那么大的所谓，不过既然客观上是全站小工具，意味着站内各用户都能启用，需要尽可能讨论的全面一点（也能看到下面有一些意见），且符合规定之后的公示也更方便界面管理员执行社群共识。--Hamish T 2026年1月8日 (四) 16:25 (UTC) 👌1

原始碼加上了簡繁emoji在地化後，終於過於龐大，現在拆成了3個文件。改了一下小工具定義，請教您：現在的寫法OK嗎？簡單來說就是分別載入3個JS文件（meta站也改成了這樣）。 --SuperGrey (留言) 2026年1月8日 (四) 19:18 (UTC)

我會建議用-而不是.做分隔，以及僅在talk等需要用到reaction的地方才加載。--Hamish T 2026年1月9日 (五) 04:08 (UTC)

- 我可以改一下。 --SuperGrey (留言) 2026年1月9日 (五) 06:32 (UTC)

已修改。另外現在 shouldSkipPage 已經有 4 重判斷了（src/main.ts, L37-L89）：名字空間、內容模型、魔術字（async），以及 Module:Reaction 是否存在（async）。 --SuperGrey (留言) 2026年1月9日 (五) 07:10 (UTC)

如果默认启用，意味着匿名用户也能用，有点担心被滥用。未登录且代理IP封禁状态下提交，最终报错是“原文中找不到时间戳”（提交失败），或可优化。建议流汗和便便表情移出“常用”，攻击性过强，用unamused表达“不看好”就可以了。如果可能，悬停提示加上中文，例如disappointed表情含义不太明显，像是困了。不确定是否会有敏感人群介意kissing_heart和heart_eyes表情。如果有统计用户或全局使用率，列出真实常用，就更好。--YFdyh000（留言） 2026年1月8日 (四) 14:32 (UTC)

感謝反饋。我再改一改。「常用」理論上是隨著使用者的不斷使用而變化，但目前好像沒有生效；初始的「常用」確實也不好出現一些比較有攻擊性的表情。
未登錄時，要允許使用表情功能嗎？如果要，我再改一改；如果不要，我可以把提示改成「請登錄/註冊帳戶後使用」。 --SuperGrey (留言) 2026年1月8日 (四) 14:39 (UTC)

倾向不允许、不加载工具，避免争议议题站外傀儡低成本扰乱讨论。--YFdyh000（留言） 2026年1月8日 (四) 14:52 (UTC) 👌1

以上反饋均已修復。對於新使用者，他們的「常用」列表已經被我修改為這幾個人畜無害的表情。
如您想要清空「常用」列表，可以參照以下步驟：

1. 按下 Ctrl+Shift+I（Windows/Linux）或 Cmd+Opt+I（Mac）打開「開發人員工具」；
2. 依次點擊「Application ➡️ Storage ➡️ Local Storage ➡️ https://zh.wikipedia.org」（Chromium）或「Storage ➡️ Local Storage ➡️ https://zh.wikipedia.org」（Firefox）找到本地存儲資料；
3. 刪去「emoji-mart.frequently」和「emoji-mart.last」這兩項；
4. 重新載入網頁。

--SuperGrey (留言) 2026年1月8日 (四) 19:06 (UTC)

（或者window.localStorage.removeItem('emoji-mart.frequently'); window.localStorage.removeItem('emoji-mart.last');）--SunAfterRain 2026年1月12日 (一) 15:27 (UTC)

我对于列入小工具列表没意见，但对默认启用有所保留——主要在于提供表情反馈能否算社群提倡的表达意见的方式。--Srapoj（留言） 2026年1月8日 (四) 16:08 (UTC)

目前中維此小工具還是比較受歡迎的。自從去年下半年推出以來，很快就擴散到全站了，現在到處都是 😂。 --SuperGrey (留言) 2026年1月8日 (四) 19:25 (UTC)

是否可以对（正面）反应加一个“感谢”相应编辑的功能，因为添加反应没有讨论系统等通知，被反应人可能感受不到？选项可以是反应并提示/自动感谢/允许仅感谢（界面按钮）。--YFdyh000（留言） 2026年1月11日 (日) 19:00 (UTC)

在閱讀視圖「感謝相應編輯」是一個相當複雜的功能，不容易實現。如果大家有這方面的需求，可以安裝 Convenient Discussions 解決。Reaction 小工具就不考慮實現了，現在 JS 文件已經很龐大了。 --SuperGrey (留言) 2026年1月11日 (日) 19:44 (UTC)

請求修復語言模板追蹤分類

如題，我在高义伯胡同中使用Template:漢語拼音，卻讓條目被分入Category:含有非中文內容的條目而非正確的Category:含有漢語拼音的條目，請求修復，謝謝。--迴廊彼端（留言） 2026年1月3日 (六) 12:34 (UTC)

Module:Lang/data ["pinyin"] = "漢語拼音"，而Template:漢語拼音目前使用cmn-Latn，如果换用pinyin，分类正常。分类是Module:Lang的language_name_get、cat_nonezh而插入。--YFdyh000（留言） 2026年1月4日 (日) 01:30 (UTC)

User:YFdyh000感謝您的回覆，我還有個問題是，這個模板可以整合到既有的模板中嗎？不然目前沒幾個條目在使用。--迴廊彼端（留言） 2026年1月4日 (日) 04:18 (UTC)

我不了解这方面是怎么用的。--YFdyh000（留言） 2026年1月4日 (日) 04:26 (UTC)

已編輯此模板。Module:Lang的編輯請求和Module:Lang/data的編輯請求完成後，此問題即會解決。——枰（留言） 2026年1月4日 (日) 08:36 (UTC)

User:優枰感謝您的幫忙！--迴廊彼端（留言） 2026年1月4日 (日) 14:00 (UTC)

已批准編輯請求。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年1月7日 (三) 16:14 (UTC)

Undrfined 連結

近日在翻譯或是視覺化編輯時，若以自動引用或是Citer貼上引用來源之原始碼，則前一個引用之來源將變為Undrfined，並在發布編輯後變成一樣的來源。

舉例：編輯時添加了A、B來源，在貼上B後，A變成Undrfined，且在發布後二者皆變成B來源。--Kanshui0943（留言） 2026年1月5日 (一) 15:07 (UTC)

且編輯時要ctrl+z數次Undrfined才會變回A，翻譯時更加嚴重，一次數個來源跑掉--Kanshui0943（留言） 2026年1月5日 (一) 15:08 (UTC)

Request for Translation of LanguageConverter documentation

I am working on improving Parsoid's support for LanguageConverter (phab:T380517) and in order to create good test cases it would be helpful to have a full translation of zh:Help:AC in a form which could be maintained as documentation. There was a start made at mw:Writing_systems/LanguageConverter but only the first section was translated. (There is also mw:Writing_systems/Syntax which is a translation of zh:Help:高级字词转换语法 and covers some of the same material, and the relationship between these pages is unclear. Which should be considered authoritative?)

Ideally we'd set this up using the translate extension as a translated document so we could track changes back and forth. There's an error on the translated mw:Writing_systems/Syntax page in the "Combined conversion flag" section (zh-hant and zh-tw actually have the same output as zh-hk in my tests) which appears to be present in the source document zh:Help:高级字词转换语法 as well; it would be good to have a means to make such corrections and have them applied to all the translated versions.--Cscott（留言） 2026年1月7日 (三) 15:56 (UTC)

I'm not too optimistic about the state of LanguageConverter documentation here either. Some content seems outdated (not changed from the initial 2000s versions) and confusingly worded. There are undocumented "magics", such as the special unidirectional status of zh-hans/hant, and the behavior when nesting another tag inside a flagged tag. --Srapoj（留言） 2026年1月7日 (三) 17:02 (UTC)

@Cscott：mw:Writing_systems/Syntax is wrong. I've corrected it. The output given in the same example in the source document is correct.

註：mw:Writing_systems/Syntax有錯誤已修正，Help:高级字词转换语法無誤。——枰（留言） 2026年1月7日 (三) 21:16 (UTC)

Thanks! I've updated my parser tests to match the new page. I also translated a few more sections to make it more complete.--Cscott（留言） 2026年1月9日 (五) 17:07 (UTC)

LC originated from zhwiki. Although the LC supports other languages (m:Wikipedias in multiple writing systems), probably only Chinese wikis use it extensively. Using the translate extension for its syntax document necessiates writing the original version in English (for sensible collaboration), but that would be awkward for Chinese editors: Currently mw:Writing systems/Syntax uses lower and upper cases of Latin alphabets to represent the simplified and traditional Chinese characters in examples, which have to be crafted manually. It's also hard to explain why exotic tags like the combined conversion flag would ever exist, without some knowledge about the messy regional word variations (地区词) in zhwiki. --Srapoj（留言） 2026年1月8日 (四) 00:55 (UTC)

I've started to make some test cases in tests/parser: Add more complete tests for language converter (1220645) which use a limited number of simplified and traditional characters (just 舊/旧, 叢/丛, and 蘭/兰) in order to demonstrate the same test cases as on mw:Writing systems/Syntax while limited the number of characters that folks who are not literate in hanzi need to recognize.--Cscott（留言） 2026年1月8日 (四) 16:42 (UTC)

PRC's character simplification scheme can be classified into multiple methods. The pairs you use belong to those using de novo characters for simplification, where the relationship is difficult to deduce for users proficient in either variant only or foreigners. I propose these pairs: 這/这, 對/对, 學/学, 經/经, 號/号, 報/报, 馬/马, 風/风, 氣/气, 電/电.

我觉得这位开发者挑的例子不便于简体使用者或者外国人猜到简繁字形间的对应关系，所以从常用字里又挑了几个。个人觉得最好看起来要有足够的差异且笔画不应太复杂（毕竟对外国人相当于在看图）。不知道各位有没有别的建议。--Srapoj（留言） 2026年1月8日 (四) 20:34 (UTC)

「舊叢蘭」这三个字看多了我都发怵……
Staring at "舊叢蘭" for too long even gives me the creeps... ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年1月9日 (五) 07:50 (UTC)

Thank you! I've updated the tests to use your suggested character pairs.--Cscott（留言） 2026年1月10日 (六) 06:34 (UTC)

@Cscott: A major problem here is, in contrast to the majority of MediaWiki codebase, LC is initially tailored for Chinese Wikipedia's needs, thus its documentation in Chinese is most comprehensive and may be considered the source of truth, rather than that in English. I doubt if MediaWiki.org allows that.

Help:AC is an introductory article about LC. Help:高级字词转换语法 literally translates to "Advanced language conversion syntax", so I would treat it as a technical documentation on LC.

Anyway, despite the challenges, I may consider translate Help:AC to English and paraphrase it in a way friendlier to English users, if I'm available later.--碟之舞📀💿 2026年1月8日 (四) 13:02 (UTC)

Thanks! Technically the translate extension can use any language as the "base" language, and so one option would be to set the page language for Writing_systems/Syntax to Chinese, and then use the translate extension to put the english translation in Writing_systems/Syntax/en (presumably with a banner at the top to explain the somewhat unusual situation). Extension:Translate isn't enabled on zhwiki, or I'd suggest just keeping the primary page hosted here and using a /en suffix for the translation. Other ideas on how to keep this content up to date and in sync are very welcome.--Cscott（留言） 2026年1月8日 (四) 16:45 (UTC)

https://www.mediawiki.org/wiki/Special:PageLanguage lets you change the "base language" for a page on wikis using the translate extension, although I don't personally have the proper permissions on mediawiki to make that change.--Cscott（留言） 2026年1月8日 (四) 16:59 (UTC)

{{Infobox person}}签名问题

见勒布朗·詹姆斯，将{{Infobox person}}中的签名参数| module = {{Infobox person|embed=yes| signature = LeBron James sig.svg}}套进{{Infobox basketball biography}}中会出现右侧对齐不居中的情况，查看源代码后发现本地代码与en版有较大差别，请求解决这一问题。--东风（留言） 2026年1月8日 (四) 06:09 (UTC)

embed改成child就行了，中文版的Infobox person没有embed这个参数。--Vozhuo_whisper 2026年1月8日 (四) 11:20 (UTC)

@Vozhuo：能夠新增支援嗎？因為不少條目均有使用。應該說，embed跟child是否有區別？—— Eric Liu _{創造は生命（留言・留名・學生會）}

embed就是child的别名，都是一个参数。不过要改的话不知道是否要公示呢？--Vozhuo_whisper 2026年1月12日 (一) 04:00 (UTC)

@Vozhuo：若屬單純新增別名，而非為其他現有功能參數占用，那我認為不用公示，或簡易公示即可。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年1月12日 (一) 16:09 (UTC)

已经修改了。--Vozhuo_whisper 2026年1月13日 (二) 01:49 (UTC)

👍 —— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年1月15日 (四) 14:10 (UTC)

將鐵路機廠的RDT圖標 (DST)更改為YRD

Hamish在討論中提到：DST較偏向貨運站，而YRD更接近其定義，希望能逐步修改各城市的DST至YRD--~2026-17210-0（留言） 2026年1月9日 (五) 11:38 (UTC)

提議公開過濾器39

如題。英維對應的en:Special:AbuseFilter/869是公開的。而且連結基本上在RSP上應該都有？--Ghren🐦🕛 2026年1月9日 (五) 16:41 (UTC)

新條目推薦候選頁面字詞轉換問題

我在特殊:Diff/91077449使用了「-{}-」，結果裡面的字仍然被轉換了。編輯發布前的預覽及其他頁面未遇到此問題。--紺野夢人 ^{未曾立馬向吳山，萬古傳名爲逆賊} 2026年1月12日 (一) 01:41 (UTC)

已修正於Special:Diff/91088716，前面有一個字詞轉換標籤有錯誤。——枰（留言） 2026年1月12日 (一) 21:18 (UTC)

修改Module:Citation/CS1的语言显示问题

沙盒测试参见固定版本91082275。--${\mathfrak {Kurwa}}$__^{( •̀ ω •́ )＜✧} 2026年1月12日 (一) 09:29 (UTC)

具体问题如{{#invoke:Citation/CS1|citation|title=测试|language=ZH-TW}}，显示为“测试 （Chinese (Taiwan)）. ”，其语言版本出现不为应有的“测试 （中文（臺灣））. ”。--${\mathfrak {Kurwa}}$__^{( •̀ ω •́ )＜✧} 2026年1月12日 (一) 09:32 (UTC)

2026年第3期技術新聞

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

本週要聞

• 維基媒體基金會在元維基和Diff平台發布了有關明年度（2026年7月—2027年6月）年度計畫的若干指導性問題。這些問題聚焦於全球趨勢、更快更健康的實驗模式、強化新手支援、提升編輯者與高階權限者的能力、促進跨專案協作，以及擴展與留存讀者群。歡迎在討論頁提供意見與想法。

近況更新 - 面向編輯者

• 作為社群技術團隊目前在「多重監視清單」專案的工作之一，團隊將更新EditWatchlist特殊頁面的介面，向多重監視清單的實現邁出第一步。此外，為回應社群願望「改進分頁/頁面導航」，Search特殊頁面的分頁顯示機制也將更新。 [3]
• 全域監視清單是MediaWiki擴充功能，可查看不同維基的監視清單。現已更新，使其外觀更接近常規監視清單，例如檢視IP位址中臨時帳號的介面已最佳化（包含用戶連結重定向到貢獻頁面），將頁面標題加粗，及以新分頁開啟編輯摘要和標籤中的連結。 [4][5][6][7]
• 上週有28件由社群提交的工單得到解決。 例如，先前全域封鎖介面中沒有停用發送電子郵件的選項，現已修復此問題，將於1月13日當週啟用。 [8]

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

• VisualEditor引用工具和參考文獻預覽現已支援「地圖」方式的文獻類型。 [9]
• 本週軟體更新細節： MediaWiki/MediaWiki

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

MediaWiki message delivery 2026年1月12日 (一) 19:30 (UTC)