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

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

发表新议题

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

公告欄

• [人事] Bosco Sin的管理員申請程序因故暫停（修改后禁令）；請社群關注仲裁委員會有關立案請求及委員動議。
• [广告] 2025年亚洲月已經開始，歡迎踴躍參與編輯。
• [公告] 整合各命名一致性決議頁面為單一頁面及设立名人暱稱收錄及刪除準則已經通過。
• [公告] 消歧義括號不應用在條目正文（除非指代條目本身）、明確擾亂和破壞的定義、將六名前用戶查核員離任日期定為基金會行動當日、爲增刪條文模板增加深色模式配色、正式启用安全投票布告板、調整快速刪除方針有關檔案的規定、新增有關「討論後未達成共識」的規定、修正WP:BALL反應未來條目的行文及在封禁方针中新增关于封禁临时账号一节正在公示，如有意見請盡快提出。
• [討論] 互助客栈正在討論维基百科25周年和新年标志、確定Wikifunctions的中文譯名、考慮将消歧義括号修正为全形括号、人物出生及逝世日期分類問題、默认使用text-autospace为中英文之间添加空白、使用webfont解决生僻字显示问题及建議整頓部分主題和專題，歡迎踴躍參與。
• [討論] 社群正在討論存档数个“新手论坛”页面、就模板、模組等內容需要符合核心內容方針的補丁、提议废除快速删除O3、集中選舉时以「報備區」替换「提名區」、增添对临时账号封禁建議及修订封禁时标记用户页指南、提议将WP:游戏维基规则改名、修订國籍與公民權填写标准、引入英维折叠讨论中明显LLM文本的做法、半共识制DYKC方案、更新Module:Lang以提升對不規範用例的兼容性、明確行政員權力範圍、釐清行政員及仲裁委員會於管理人員申請事宜的權責、補充對於用戶被軟封鎖後另創帳戶並不違反傀儡方針的事實性修訂、仲裁及Unblock-zh.org相關事實適應性修訂及修訂自由提名下公開投票之執行規範，歡迎踴躍參與。
• [評選] 優良條目評選新程序已中止試行，感謝大家參與。

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

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	提議：高亮哈佛参考文献格式短鏈指向的完整資料引用	49	9	Srapoj	2025-10-28 22:45
2	应将Category:各日出生和Category:各日逝世的参数加入Template:Bd模板	88	13	Ericliu1912	2025-10-02 10:52
3	{{transl}}模板跳红字	8	4	優枰	2025-11-01 16:04
4	提议：默认使用text-autospace为中英文之间添加空白	45	12	SuperGrey	2025-11-03 19:09
5	生僻字webfont	68	10	Srapoj	2025-11-09 21:41
6	封禁显示	9	4	Kurgenera	2025-10-31 23:25
7	自動清理重複重新導向模板標記	2	2	Kanashimi	2025-11-07 06:53
8	一个明显的显示异常。	19	4	Ericliu1912	2025-11-06 00:07
9	改善字体的讨论怎麼又死了	7	4	Ericliu1912	2025-11-06 00:08
10	介绍：WebFont-ZH服务及小工具	51	7	SuperGrey	2025-11-04 14:39
11	侧边栏模板在移动版的显示问题	4	4	Srapoj	2025-11-02 01:09
12	Template:NYSE 問題回報	1	1	Srapoj	2025-11-03 21:11
13	maplink幾乎相同的參數卻無法顯示	5	2	Srapoj	2025-11-04 06:22
14	2025年第45期技術新聞	3	3	Ericliu1912	2025-11-05 06:40
15	在桌面端測試閱讀清單功能	1	1	EBlackorby-WMF	2025-11-04 06:29
16	統一Template:RSNG的圖示內部連結	2	1	Olaf8940	2025-11-06 16:30
17	怎麼回退一人的所有編輯	4	3	Olaf8940	2025-11-06 15:56
18	行動版註腳斜體問題	3	3	Diskdance	2025-11-06 10:21
19	改善封禁提示在窄屏下的显示效果	3	3	Bluedeck	2025-11-07 18:14
20	跨语言链接增强工具已更新	1	1	Diskdance	2025-11-06 17:29
21	一时脑抽找不到按钮了	3	3	PexEric	2025-11-08 21:20
22	系统就不能把模板大小限制设的大一点吗？？？	2	2	Ericliu1912	2025-11-09 23:35

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

正在廣泛徵求意見的議題

議題清單

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

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

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

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

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

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

Template talk:NoteTA § 匿名參數次序

從古至今，本模板的全文轉換匿名參數都是從1起計的嗎？印象中，以往似乎是不占用已設有的數字（次序）？如果一直確實都從1起計，今後可否改爲（1）以最下方的匿名參數為最大數字序號並往上遞減，或（2）使匿名參數跳過已設有的數字（次序）？--— Gohan 2025年10月7日 (二) 08:23 (UTC)

Module talk:Delete § 編輯請求 2025-10-25

讓分類拖延到輸出前才添加，防止多次插入分類（雖然目前看起來無害？）及分類索引字被無意中覆蓋--SunAfterRain 2025年10月25日 (六) 11:51 (UTC)

Wikipedia:互助客栈/技术 § 介绍：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)

Module talk:Lang § 有關更新模組以提升對不規範用例的兼容性

根據追蹤分類，本模組相關模板仍在約1500個條目存在不規範用例，目前此類情況只會顯示紅字錯誤。考慮到短時間內無法修正，現提議修改模組，將此類情況改爲嘗試正常顯示文字，並將紅字錯誤改爲預設不顯示，以此提升模板兼容性。新版本目前位於Module:Lang/sandbox，測試時尚未發現有問題，不過測試仍可能不足，若決定更新還需要各位協助測試。——枰（留言） 2025年11月1日 (六) 08:00 (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)

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

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

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

{{transl}}模板跳红字

最近发现多个使用 {{transl}} 的国家条目都跳红字（如阿塞拜疆，伊拉克，均已修改）。推测是近年3月该模板修改后的结果，使得很多原来可接受的不规范写法现在都显示为红字。大量国家条目都使用该模板，阅读量高，频繁红字的观感不佳，容易给读者留下本项目的不佳印象。是否有办法排查？或者，是否有办法加强其兼容性，使得不规范写法不显示为红字？--三猎（留言） 2025年10月4日 (六) 09:59 (UTC)

应该都在Category:Transliteration模板错误。我没研究这个模板参数的变迁，先ping一下修改该模板的@Vozhuo。--Srapoj（留言） 2025年10月4日 (六) 14:46 (UTC)

好欸，有汇总的话就可以先改起来了。——三猎（留言） 2025年10月5日 (日) 05:19 (UTC)

lang系列模板時不時出問題，那麼久了都還沒修完，竟然還有人想著把舊模板刪了，XD —— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年10月4日 (六) 18:03 (UTC)

发现一个非常典型的问题，就是{{transl}}会内嵌在一些模板中，当编者想要加入中文说明时，就会跳红字。例如卜肉条目。——三猎（留言） 2025年10月5日 (日) 05:46 (UTC)

这个有人在Template talk:Taiwanese报过，还没人处理。--Srapoj（留言） 2025年10月5日 (日) 08:44 (UTC)

我在Module:Lang/sandbox改了一個儘量顯示內容、不直接報錯的版本。——枰（留言） 2025年10月31日 (五) 06:33 (UTC)

請關注Module talk:Lang§有關更新模組以提升對不規範用例的兼容性。——枰（留言） 2025年11月1日 (六) 08:04 (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)

原则上(＋)支持。细节上需要讨论是作为默认小工具启用还是添加到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)

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

生僻字webfont

过往讨论应有提到透过webfont解决生僻字显示问题。有以下挑战：1.生僻字界定。各系统的字库支持情况不明。如果要支持{{僻字}}模板以外出现的字，一种可能的解决方法是动态判断显示效果，但兼容性问题又是大坑。2.动态分包。书生有提到如字蛛，但他说的普遍存在一些问题我不太清楚。我尝试了一下cn-font-split，似乎效果还可以，能基本做到为每个页面动态分包。不过，每次不同的新页面都要重新分一次包，还就那一两个字，有点大炮打蚊子了😂；理想的方案是为每个字（高频字）预先分出一份woff2文件，这就牵扯下面的静态资源托管问题。3.托管。现成只能用Toolforge。但我想没有专门的CDN，很难支持本站的访问量？要做这种事，必须经由基金会，社群如何参与/以何种形式参与不得而知？

跑了一个User:PexEric/数据库报告/生僻字，全站拢共出现的也就1059个字，比较省事的做法或许是一次性打包为一个字体文件（测试后大概不到200KiB），定期维护更新（像维护繁简转换表一样）？--PexEric 2025年10月19日 (日) 13:27 (UTC) 👍1

附知书生、魔琴和刘君；以及我觉得在这个问题上或许有见解的@Diskdance、SuperGrey。--PexEric 2025年10月19日 (日) 13:39 (UTC)

最理想的就是由基金會託管生僻字字體，比如天珩全字庫(TH-Tshyn)支援到了Unicode 17.0，然後採用預分包的方式，即cn-font-split載入（不必動態，做靜態的分包就可以了）。我覺得不應篩選限定範圍在1059字內，我對有基金會參與的「定期維護更新」不太樂觀 😂（很可能變成無人打理的廢墟），而使用全字庫的好處就是，下次Unicode 18.0暫時沒有漢字，預計這次託管字體後，至少兩三年內不必再更新維護。--SuperGrey (留言) 2025年10月19日 (日) 21:48 (UTC)

雖然全字庫字體看起來很大，但是只要用cn-font-split拆分得足夠細，每次實際被加載的字體大小可以做到很小。@PexEric你可以測試一下。--SuperGrey (留言) 2025年10月19日 (日) 21:52 (UTC)

天珩恐怕存在商用侵权问题，那个描述像是“侵删”。不确定文津宋体是否可靠和适用。--YFdyh000（留言） 2025年10月19日 (日) 22:59 (UTC)

看起來也支援到Unicode 17.0了，不錯。--SuperGrey (留言) 2025年10月19日 (日) 23:03 (UTC)

数據库报告衹有用了僻字模板的吧，实际不知道会不会多。另外，这個僻字模板裏面什麼都有啊…… ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2025年10月19日 (日) 22:40 (UTC)

實際可能會比1059個字多很多，全站跑了一次User:What7what8/生僻字統計--User:What7what8🏠 2025年10月23日 (四) 17:53 (UTC) 👍1

这么说，突然又想到一个统计上的难点😂。有些在源代码中或许不是“生僻字”，经过转换表类推简化成简体字后可能就是“生僻字”了。--PexEric 2025年10月23日 (四) 18:10 (UTC)

好奇您是怎么做的？拿基金会每月的xml dump然后匹配文字吗？@What7what8：

PexEric用的paws脚本倒是能直接翻出来：https://public-paws.wmcloud.org/User:PexEric/1%20time/pizi/Untitled.ipynb --Srapoj（留言） 2025年11月4日 (二) 21:50 (UTC)

动态分包存在问题是我好几年前了解的，现在可能已经不是问题了？以前的问题就是不是每次split都会成功，有小概率失败（好像不同字体失败的地方还不一样？）好像google字体工具不支持中文字体的分包也是出于这个原因--百無一用是書生 (☎) 2025年10月20日 (一) 03:13 (UTC)

另外，“为每个字（高频字）预先分出一份woff2文件”，其实完全可以用字形wiki的数据。我觉得比较合适的方法是用字形wiki的数据，转成woff2格式，然后托管在toolforge。对了，好像基金会那边有个豆腐字检测算法，不知道能不能用得上--百無一用是書生 (☎) 2025年10月20日 (一) 03:20 (UTC)

T65122、T135465，在4f3461a被移除了。要做的话，本地小工具可以做。不清楚站内谁有这个能力😂。--PexEric 2025年10月20日 (一) 07:27 (UTC)

以前写过一个小工具，是依托字形wiki提供的API，但后来不允许跨站点脚本，字形wiki中间还出过很长一阵子技术问题，小工具就没法用了。要重新弄的话，需要全部数据本地化（至少是toolforge），工程量一下子就大了很多，许多地方要想清楚规划好（而且字体生成这一块我是真不太会了）--百無一用是書生 (☎) 2025年10月20日 (一) 07:43 (UTC)

對的，我建議就用靜態的分包。--SuperGrey (留言) 2025年10月20日 (一) 07:18 (UTC)

其实更懒一些的话，直接把字形wiki的数据全部或部分制成webfont格式，然后配合豆腐字检测算法，应该就能搞定绝大部分。但其实我觉得IDS方法或许会更好一些（如果能把生成图片改为生成字体）--百無一用是書生 (☎) 2025年10月20日 (一) 07:35 (UTC)

可以做一个基于KAGE2的动态生字引擎，并以类似LaTeX的形式作为MediaWiki扩展，这个就是后话了。字统网好像也是这样处理生僻字SVG的。--PexEric 2025年10月20日 (一) 07:51 (UTC)

简单说一下我的思路，没什么新的😂，还是小工具+Toolforge。在Toolforge为每个生僻字（如上预先统计过的1059个字）都独立分为一个woff2包托管。遇到新的字，再请求给Toolforge分包并缓存，下次直接命中缓存。还有不用JS的方案，利用TemplateStyles为每个字编写font-face css，字体文件（woff2）以base64硬编码存储（可能要改mw:Extension:TemplateStyles#Configuration的实现，比如允许base64的文件）。测试了单个汉字的woff2不到1KiB，写成base64不会太夸张。这个两个方案可以同时进行，比如高频生僻字直接请求站内css，减少网络请求。--PexEric 2025年10月20日 (一) 07:47 (UTC) 👍1

如果Toolforge程式真的做到無人值守、自動分包+緩存，感覺挺不錯。--SuperGrey (留言) 2025年10月20日 (一) 07:52 (UTC)

我觉得最好把字体文件base64后塞进JS、由机器人更新到站内。这样才能利用ResourceLoader的基础设施（主要是CDN以及本地的长缓存时间），也是用JS而非CSS的原因。
但说实话，我感觉这样一套机制的复杂度像是可以拿出去卖方案的程度了（虽说有时候商业公司产品可能没比优秀的本科生作业强太多），即使做出来了真的能长期维护吗？--Srapoj（留言） 2025年10月30日 (四) 20:56 (UTC)

User:PexEric/数据库报告/生僻字在我电脑上大概有20几个字显示不了--百無一用是書生 (☎) 2025年10月21日 (二) 02:11 (UTC)

字体与字形

最大的问题应该还是字体本身。首先风格来说，数位时代的屏显字体基本都是黑体，如果生僻字换成宋体，我个人觉得可能比较奇怪😂，不知道各位怎么想。不过unihan标准本身（以及字形wiki、传统的大字集字体等）倒是以宋体为基准。或者就是走黑体+宋体的双轨制，我目前觉得没有必要。其次就是地区字形问题，可能需要根据地区，使用不同的字体。比如部分中国大陆字体会“假想G源”，与unihan标准本身不符，但是对于大陆用户似乎还可以接受？最后就是版权，大字集+无版权风险，只能选择现有的开源项目。（毕竟不能每个字都本站单独设计吧😂，而且要保证风格统一。）要为不同地区分包选取字体项目，并取得社群共识。--PexEric 2025年10月20日 (一) 08:09 (UTC)

能顯示出來就很不錯了，生僻字不要講究那麼多。明體(宋體)就明體，難看就難看，@YFdyh000找到的「文津宋體」就OK了。--SuperGrey (留言) 2025年10月20日 (一) 08:16 (UTC)

也不必考慮地區字形，生僻字就用Unicode規定的字形即可。--SuperGrey (留言) 2025年10月20日 (一) 08:17 (UTC)

也许是我理解错了，不过Unicode code chart的字体仍是由商业公司提供的，条款[2]限制了复用。--Srapoj（留言） 2025年10月30日 (四) 20:56 (UTC)

陆标的话，我觉得文津宋体和遍黑体就是最佳的，没有更好的了。台标的话可以考虑源樣黑體，fallback到隙间黑体，明体可以考虑花园明朝和Jigmo。--PexEric 2025年10月20日 (一) 08:24 (UTC)

優先考慮黑體，但是如果有明體支援更多，那就用明體。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年10月20日 (一) 16:28 (UTC)

btw，不知道目前支援最多漢字的字體是什麼？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年10月21日 (二) 15:03 (UTC)

又看到一個支援Unicode 17.0的宋體字：全宋體。--SuperGrey (留言) 2025年10月22日 (三) 01:57 (UTC)

基于KAGE的全汉字无衬线字体：LorchinSans--PexEric 2025年10月24日 (五) 18:15 (UTC) 👍1

如果字體放很多，會不會影響效能？如果會，怎麼折衷？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年10月26日 (日) 06:47 (UTC)

如果用cn-font-split拆分得足夠細，理論上對性能的影響有限。不過還需PexEric君實測。--SuperGrey (留言) 2025年10月26日 (日) 09:20 (UTC)

隐私问题

由于基金会已经声明不会支持添加新字体到WebFonts，而且Toolforge不符合维基百科的隐私方针（WMCS使用自己的隐私方针），另外维基百科上只允许版权开放的字体。这几点综合看，目前是不能解决生僻字显示问题的，至少读者必须注册维基百科账号，并且主动同意WMCS的隐私方针，启用并非默认启用的小工具才行。--Midleading（留言） 2025年10月30日 (四) 15:35 (UTC)

搞不懂他们的政策。看那意思像是要管托管在wmcs的js和wmcs工具中的非wmf站点请求。看mw:Requests for comment/Content-Security-Policy，分发字体应该属于Stage 7，倒也提到了诸如MapSources可允许例外；我想必要时说明本站的情况，或许可成为例外。wikitech:Wikimedia_Cloud_Services_team/EnhancementProposals/Third-party_interaction_consent_tool可能也相关，但是去年的新倡议。总结是目前好像没有具体限制措施？要是预设脚本不能请求toolforge，那我真白干了😅。那去做成MediaWiki扩展，封装成API，正好我还嫌Toolforge性能不行呢，直接用Wikipedia的infrastructure，只要不觉得API乱。--PexEric 2025年10月30日 (四) 16:24 (UTC)

在WMF站点部署新扩展的流程很麻烦(mw:Writing an extension for deployment)，建议死心（--Srapoj（留言） 2025年10月30日 (四) 17:26 (UTC)

ULS的webfont已叫停（T135464），加载woff2文件都不行的话，确实属于堵死这个事了。当然真到那种时候，相信本地社群能找到IAR的自洽。--PexEric 2025年10月30日 (四) 17:48 (UTC)

基金会的人怎么配置软件不是社群自治能决定的，IAR管不着。--Srapoj（留言） 2025年10月30日 (四) 20:56 (UTC)

Sometimes, volunteers may place a data-collecting tool, such as a script, gadget, tracking pixel, or share button, on a Wikimedia Site without our knowledge. This Policy does not cover how third parties handle the information they receive as a result of such a tool. If you come across such a third-party tool, and you believe it violates this Policy, you can remove the tool yourself, or report it to privacy@wikimedia.org so we can investigate.

[...]

If you ever come across a third-party data collection tool that has not been authorized by you (such as one that may have been mistakenly placed by another user or administrator), please report it to us at privacy@wikimedia.org.
— wikimedia:Policy:Privacy policy

考虑到隐私政策中personal data包括IP地址［和user agent信息］等，我的理解是使用外部资源的小工具都是"data-collecting tool"，所以需要opt-in。我搜到的还有m:Third-party resources policy，但和PexEric找到的两个一样都是草案状态。另见wikitech:Wikitech:Cloud Services Terms of use。

说回来，我认为默认启用的、会连接到第三方控制的服务器（即使是toolforge/WMCS）的脚本便会引发问题，包括WMF隐私政策以及服务器运维（毕竟本站的请求量不小）。--Srapoj（留言） 2025年10月30日 (四) 20:26 (UTC)

正常情况下toolforge/WMCS上的访问日志是不记录IP地址的--百無一用是書生 (☎) 2025年10月31日 (五) 03:34 (UTC)

抱歉因为没用过所以不了解toolforge网络配置的细节。我想那就是WMCS ToU §7.2单独出现的原因了。按照wikitech:Help:Toolforge/Web以及wikitech:Portal:Toolforge/Admin/Kubernetes/Networking and ingress，我猜用户请求的IP是被某层nginx隐藏了、没写进Forwarded头？--Srapoj（留言） 2025年10月31日 (五) 12:39 (UTC)

真是我知识盲区了😂……下面搬出Gemini：

根据您提供的文件和图表，是的，Toolforge 开发者在技术上可以获取用户的部分信息。

文件本身主要描述的是网络拓扑和架构，而不是数据隐私政策。然而，从这个架构和文件中提供的日志示例可以推断出以下几点：

1. 工具（Tool Pod）的特性

用户的请求最终会到达“actual tool pod”（图中的步骤9）。这个“pod”是工具开发者自己编写和控制的应用程序。为了让工具能够响应用户的请求，它必须接收到请求的详细信息。这些信息通常包括：

• 用户请求的 URL 路径和查询参数。
• HTTP 标头（Headers），其中可能包含：
  • User-Agent：用户的浏览器、操作系统等信息。
  • Referrer：用户在访问该工具之前所在的页面。
  • X-Forwarded-For：用户的原始 IP 地址（尽管文件中未明确提到，但这是代理的标准做法）。

2. 日志中记录的信息

在“How to test the setup”部分，文件展示了 nginx-ingress（步骤4）的日志示例。这些日志明确显示系统会记录可被视为隐私的信息：

• IP 地址：示例中显示了 IP 地址（例如 192.168.50.0），尽管这可能是内部代理的 IP，但它仍然是访问链的一部分。
• 完整的请求路径：例如 GET /potd-feed/potd.php/commons/potd-400x300.rss HTTP/1.1。
• User-Agent：例如 FeedFetcher-Google; (+http://www.google.com/feedfetcher.html) 或 Mozilla/5.0...。
• Referrer（来源页）：例如 "https://tools.wmflabs.org/wikisense/Gallery.php?&wikifam=commons.wikimedia.org&img_user_text=Hoanglong2807"。

有权访问这些日志的系统管理员或开发者可以看到这些信息。

3. HTTPS 终止

文件在描述 haproxy（步骤2）时提到，它负责“terminating inbound HTTPS traffic”（终止入站 HTTPS 流量）。这意味着在 haproxy 之后，流量在 Kubernetes 集群内部（从 haproxy 到 nginx-ingress 再到 actual tool pod）是以未加密的形式传输的。

总结：是的，该架构允许（并且为了工具能正常运行而必须）将用户的请求数据（包括 URL、User-Agent、Referrer 等）传递给工具开发者控制的“actual tool pod”。此外，系统的中间组件（如 nginx-ingress）会记录这些信息，有权访问日志的管理员也可以看到这些信息。

--PexEric 2025年10月31日 (五) 13:15 (UTC)

toolforge上的访问日志大概是这样：

192.168.209.148 itnsyn.toolforge.org - [16/Aug/2022:14:20:06 +0000] "GET / HTTP/1.1" 200 125991 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:103.0) Gecko/20100101 Firefox/103.0"

记录的IP地址用的全都是C类的内网IP--百無一用是書生 (☎) 2025年11月2日 (日) 07:24 (UTC)

“data-collecting tool”从下面的“third-party data collection tool”看和例子看，不像是指客户端获取外部数据吧，毕竟外部的服务端没有data collection的逻辑（我也没那本事😂）。当然，toolforge自身的networking可能有对IP、UA等的记录？--PexEric 2025年10月31日 (五) 03:37 (UTC)

根据foundation:Policy:Privacy_policy#Definitions，IP address和user-agent information都是隐私信息，不光是IP。另外维基百科用户浏览器支持的字体可以算是user-agent information，因为可以用来构成浏览器指纹。--Midleading（留言） 2025年10月31日 (五) 04:14 (UTC)

看了看。对于WMCS，wikitech:Wikitech:Cloud Services Terms of use管的是开发者，而wikitech:Wikitech:Cloud Services End User Terms of use才是管使用者。按照前者和Toolforge的规则，我的项目已经开源，没有也没能力写收集IP、UA等隐私信息的逻辑。后者则没有提及如何处理隐私信息，按照wikimedia:Policy:Privacy policy的意思，那就是遵循基金会的通用隐私方针。Toolforge自身的networking有没有收集隐私信息，这与WMF直接相关，已经不属于third party。用户浏览器支持的字体更不可能了，没有浏览器提供这种接口，不然不会有那么多旁门左道。--PexEric 2025年10月31日 (五) 08:20 (UTC)

但Toolforge的配置让您能够得知UA信息。（按照我的理解，WMCS End User ToU已经把WMF/WMCS撇清成GDPR意义上的data processor（中国大陆PIPL的“受托人”）；而您作为WMCS上服务的开发者，是需要提供一份隐私政策的data controller（PIPL“个人信息处理者”）。）
但对于Toolforge的情况，收集访问日志（包括IP）的做法属于平台自己决定purposes and means（PIPL“自主决定处理目的、处理方式”）的范畴，开发者甚至看不到数据，所以他们仍是这部分数据的data controller？（disclaimer：我不是律师，并且常识是个人服务通常不会被找茬。单纯的访问日志在GDPR下应该能算作无需consent的legitimate interest类用途）--Srapoj（留言） 2025年10月31日 (五) 12:39 (UTC)

回头看了一遍WMCS End User ToU，里面说WMF隐私政策适用于所有Toolforge项目；且它连同WMCS ToU都在privacy statement要求部分排除了Toolforge。我感觉最好还是写信问基金会能否允许默认启用使用toolforge的脚本。@Midleading：--Srapoj（留言） 2025年10月31日 (五) 22:39 (UTC)

Jdforrester (WMF)：Note that hot-loading from the Toolforge CDN on a production Wikimedia site without user opt-in consent is a privacy policy violation, as the Toolforge privacy policy is different.──Project:Village Pump/Flow上的Add Chart.js as a hidden gadget。似乎不行。--YFdyh000（留言） 2025年11月1日 (六) 11:25 (UTC)

这是用Toolforge CDN热加载站外资源，可能和这种情况还是有点区别。--PexEric 2025年11月3日 (一) 06:20 (UTC)

如果需要opt-in的话，其实相当于没有默认启用。--碟之舞📀💿 2025年11月6日 (四) 06:17 (UTC)

其实应该能通过设计好引导流程、让有需要的用户能主动打开目前这版已经实现的网络字体开关配置界面吧（比如显示一个气泡、过几秒或有动作就消失）。（倒是想起您第一版Variant Ally的弹窗--Srapoj（留言） 2025年11月6日 (四) 20:52 (UTC)

顶置横条会更醒目便捷吧，但是否与UI政策抵触。可能需要一个“不再显示”，记录于账户和/或cookie。不清楚需要怎样的“隐私声明”。--YFdyh000（留言） 2025年11月7日 (五) 09:48 (UTC)

“不再显示”的Cookie也会违反Cookie声明。（除非我们获得您的允许。否则我们绝对不会在我们的维基站上使用第三方Cookie。）正确的做法是在没有Cookie时，认为用户不同意使用该功能并且不同意存储第三方Cookie。--Midleading（留言） 2025年11月9日 (日) 04:44 (UTC)

第三方在哪？--PexEric 2025年11月9日 (日) 04:45 (UTC)

第三方是Toolforge，Toolforge与维基百科不是一个域名。--Midleading（留言） 2025年11月9日 (日) 04:47 (UTC)

“不再显示”横幅的cookie需要何种Toolforge的技术？--PexEric 2025年11月9日 (日) 04:52 (UTC)

PexEric想象中的Cookie應該是存於瀏覽器本地的吧？或者建立User:<帳戶名>/webfont.json 之類的。並不存於Toolforge。 --SuperGrey (留言) 2025年11月9日 (日) 07:19 (UTC)

真要设置cookie也是放在域名zh.wikipedia.org下的，不会被浏览器发送到toolforge的域名，所以不算第三方cookie。况且这种配置也可以放在浏览器的localStorage里，无需发给服务器（隐私法律的要求我就不清楚了，印象里存non-essential的cookie类似物的动作就需要consent，但客观地说这种配置项能用于追踪的信息量很小）。--Srapoj（留言） 2025年11月9日 (日) 13:41 (UTC)

成果

见下。--PexEric 2025年10月31日 (五) 08:22 (UTC)

a6d6337d77.catalyst.wmcloud.org可以在线体验。［目前暂时设置一个月有效期。］--PexEric 2025年10月31日 (五) 13:25 (UTC)

申请向ULS加入大字库字体

根据上方讨论，现考虑申请向ULS加入大字库字体。现在需要达成共识的是加入什么字体。

因为本站资源要求自由版权，因此首先排除天珩字库、MiSans L3等。结合上方讨论，综合考虑下来个人建议使用遍黑体。

不清楚社群是否介意字形的地区问题？个人观点是此类字体能消除豆腐块就已经不错了，字形什么的就不要奢求了。--碟之舞📀💿 2025年11月4日 (二) 02:12 (UTC)

(－)反对加入太大的字体文件，如果非要加入，建议拆分成多个小文件（至少要删掉中文环境下必然能正常显示的字形），最好还是要配合豆腐字检测技术--百無一用是書生 (☎) 2025年11月4日 (二) 02:42 (UTC)

ULS提供的字体文件有设置1年的缓存，我在下方也提到过，再配合前端小工具视情况请求，在这种情况下是否可以接受？

再次申明，个人主要担心的是在默认启用的情况下，Toolforge的性能和稳定性问题。解决方案之一是前端小工具配合ULS的字体资源，但如果相关后端代码可以作为扩展直接并入MediaWiki，这也是一种解决方案。--碟之舞📀💿 2025年11月4日 (二) 05:49 (UTC)

@Diskdance：移到上面了。ULS托管后，还是要结合前端小工具根据生僻字字符请求。我比较担心unicode-range是不是真正好用。或者PHP大佬把我的动态分包逻辑加入在ULS扩展。--PexEric 2025年11月4日 (二) 02:43 (UTC)

unicode-range我印象中得需要字体文件支持才行？--百無一用是書生 (☎) 2025年11月4日 (二) 02:51 (UTC)

按照MDN文档和spec，这个CSS属性的效果是让浏览器在检测到范围内code point时才加载字体，并只对那些code point使用对应字体。看起来和字体无关。--Srapoj（留言） 2025年11月4日 (二) 20:35 (UTC)

你这么一说我想起来了，应该是别的webfont特性与字体支持有关，unicode-range并不能把字体文件变小--百無一用是書生 (☎) 2025年11月5日 (三) 02:29 (UTC)

cn-font-split的做法是拆包，把一個字體文件拆成很多個小文件，每個文件對應一個unicode-range。這樣就能只加載需要用到的部分，節省流量。--SuperGrey (留言) 2025年11月5日 (三) 02:53 (UTC)

封禁显示

阿南之人（讨论 | 貢獻）应该是被部分封禁，但是打开“用删除线划去被封禁的用户”时，显示与被限期封禁用户相同。这应当需要调整？--${\mathfrak {Kurwa}}$__^{BITTEN and DEAD} 2025年10月23日 (四) 15:35 (UTC)

@Hamish、Shizhao、Xiplus、Jimmy Xu：复知界面管理员。--${\mathfrak {Kurwa}}$__^{(´▽`ʃ♡ƪ)} 2025年10月29日 (三) 06:09 (UTC)

被禁止编辑，似乎正常？--百無一用是書生 (☎) 2025年10月29日 (三) 07:17 (UTC)

应该是没有考虑到这种情况，因为仅禁用电邮的封禁不常见。小工具目前只通过API query blocks返回的restrictions字段（例如禁止编辑某几个页面）来判断部分封禁。处理这里禁用全站电邮的情况需要解析flags字段。--Srapoj（留言） 2025年10月29日 (三) 21:22 (UTC)

不是，这个用户是全站禁止编辑+停用电子邮件+停用自动封禁，所以没问题啊--百無一用是書生 (☎) 2025年10月30日 (四) 03:17 (UTC)

他没被禁止编辑，日志内容也是“特定非编辑操作”（MediaWiki:Logentry-non-editing-block-block）。--Srapoj（留言） 2025年10月30日 (四) 11:31 (UTC)

但是看这里的话Special:Block/阿南之人，是禁止了全站编辑--百無一用是書生 (☎) 2025年10月31日 (五) 03:29 (UTC)

@Shizhao 我还没被禁止编辑 囧rz……Пусть от победы☆к победе ведёт! 2025年10月31日 (五) 04:34 (UTC)

打开popups显示是“被部分封禁”。--${\mathfrak {Kurwa}}$__^{(´▽`ʃ♡ƪ)} 2025年10月31日 (五) 15:25 (UTC)

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

不知是否有此類機器人？案例在此。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年10月28日 (二) 06:03 (UTC)

是否有辦法建立一個追蹤類別?--Kanashimi（留言） 2025年11月6日 (四) 22:53 (UTC)

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

一个明显的显示异常。

截图 提示框的文字消失了。--LBLaiSiNanHai（留言） 2025年10月28日 (二) 06:19 (UTC)

看起來像是discussiontool的提示，我去確定一下。--Hamish T 2025年10月28日 (二) 06:29 (UTC)

印象里是首次使用discussiontools才会弹的(option discussiontools-seenautotopicsubpopup）。--Srapoj（留言） 2025年10月28日 (二) 11:50 (UTC)

是这个，忘记回了，但我始终无法复现这个提示框的标题和内容消失的情况，弹出来的都是正常显示的。--Hamish T 2025年10月28日 (二) 11:53 (UTC)

麻烦您告诉我如何让他再次弹出 我自己看一下dom--LBLaiSiNanHai（留言） 2025年10月28日 (二) 11:54 (UTC)

JS: mw.user.options.set('discussiontools-seenautotopicsubpopup', 0)
去Special:Preferences#mw-input-wpdownloaduserdata可以检查这个配置项的状态。--Srapoj（留言） 2025年10月28日 (二) 12:10 (UTC)

试了下，对话框没弹，mw.user.options.get('discussiontools-seenautotopicsubpopup')确实是0，用你说的wpdownloaduserdata看到的还是1--LBLaiSiNanHai（留言） 2025年10月28日 (二) 12:19 (UTC)

我现在试一下api.saveOption('discussiontools-seenautotopicsubpopup', '0')--LBLaiSiNanHai（留言） 2025年10月28日 (二) 12:23 (UTC)

这个是能用的。--Hamish T 2025年10月28日 (二) 12:26 (UTC)

建议您看一下有没有什么adblocker之类的东西拦截掉了。--Hamish T 2025年10月28日 (二) 12:27 (UTC)

抱歉是我没仔细读文档。是得用mw.Api()对象的方法。--Srapoj（留言） 2025年10月28日 (二) 12:25 (UTC)

我试过了，用api保存选项后虽然查到的是0，但是框还是没弹--LBLaiSiNanHai（留言） 2025年10月28日 (二) 12:26 (UTC)

您得取消订阅。--Hamish T 2025年10月28日 (二) 12:27 (UTC)

ooo感谢感谢我试试--LBLaiSiNanHai（留言） 2025年10月28日 (二) 12:28 (UTC)

test--LBLaiSiNanHai（留言） 2025年10月28日 (二) 12:30 (UTC)

这一次又好了，暂时不知道怎么回事，那么完成吧--LBLaiSiNanHai（留言） 2025年10月28日 (二) 12:31 (UTC)

 是，我第一次用的时候就是弹的这个--LBLaiSiNanHai（留言） 2025年10月28日 (二) 11:54 (UTC)

这儿通常没太多人。您如果有意自己查问题，可以去mediawiki.org找文档、在phabricator.wikimedia.org翻bug，以及用mw:Codesearch（或者 https://github.com/wikimedia ）直接搜源码。--Srapoj（留言） 2025年10月28日 (二) 22:31 (UTC)

通常會來提問的就是不知道去哪裡（ —— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年11月5日 (三) 16:07 (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)

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

介绍：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：條目標題和左側「目次」欄仍無法顯示僻字。--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)

小工具本身的设计没有问题，但是我依然担心默认从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)

我上面考虑过利用模板样式和内联文件。但是wikitech-l那边忽略了一个很要命的问题，就是中文字体，通常是数十MiB的，甚至因为OpenType的字符数限制要以多个十几MiB的文件分发（遍黑体有两个文件，文津宋体有三个文件，每个都是十几MiB），MediaWiki命名空间的JS和CSS限制20KiB，不可能写在一个页面。模板样式目前不允许内联base64文件。也许只有用户子页JS可以允许这样的某种意义上的细粒度数据托管，但这维护太复杂了，逆生产力。除非让基金会重新搞ULS的webfont，但是阿三程序员觉得这不必要😂。--PexEric 2025年11月3日 (一) 03:38 (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)

前端脚本请求远程字体文件，将返回的二进制数据以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)

侧边栏模板在移动版的显示问题

有用户反馈Template:聖公宗、蓝牙的表格在纵向的移动版下表现不佳。社群目前对于此类模板或表格的布局问题是否有比较好的解决方案？——暁月凛奈 (留言) 2025年11月1日 (六) 04:32 (UTC)

最佳实践好像是sidebar干脆不在移动版显示吧。--PexEric 2025年11月1日 (六) 06:28 (UTC)

我認為聖公宗模板能在移動版直接不顯示，不過藍芽的表格是否能讓他換行顯示，不要左邊是文章，右邊是表格，各佔一部份--~2025-30774-56（留言） 2025年11月1日 (六) 08:06 (UTC)

Module:Sidebar其实指定了class=nomobile，所以会被Extension:MobileFrontend移除。但本地的{{聖公宗}}没在用这个模板。

{{Infobox}}会用上mw:Extension:WikimediaMessages内置的给Minerva主题的media query (ext.wikimediamessages.styles/infobox.less)，窄屏下（断点min-width: 640px）不会float: right。要想解决蓝牙的表格问题可能得找个模板加这类media query。--Srapoj（留言） 2025年11月1日 (六) 17:09 (UTC)

maplink幾乎相同的參數卻無法顯示

於Phabricator追踪
工單T409119

Special:PermaLink/89795194中3種{{maplink}}寫法幾乎相同，但兩處無法正常顯示。但在英維en:User:Nebulatria/sandbox卻全部可以正常顯示。請問問題可能出在哪裏。--Nebulatria 2025年11月3日 (一) 17:27 (UTC)

經過進一步測試（User:Nebulatria/沙盒/1），發現|title=马德留-佩拉菲塔-克拉罗尔谷無法正常顯示，但移除連接改用|title=马德留-佩拉菲塔-克拉罗尔谷即正常，但其他長連結如|title=高雄市立高雄高級工業職業學校卻沒有問題。不理解出現此類錯誤的原因，不知有無修復可能。--Nebulatria 2025年11月3日 (一) 17:37 (UTC)

我用zh-cn来看1、2正常，3不行；换成zh-tw就是1不行，2、3正常。另外很神秘的是用预览没法重现，只影响已保存的版本（含历史版本）。
Module:Mapframe本身和英维版本几乎没差别，那大概率就是和字词转换系统相关了。不知道和Template talk:Maplink列出的旧问题有没有关系。--Srapoj（留言） 2025年11月3日 (一) 18:28 (UTC)

仿照您的例子按mw:Help:Extension:Kartographer做了一份没用wikidata的，放在我的沙盒：Special:Permalink/89796014。
现象同样是marker消失，但因为我指定了初始经纬度，所以没像您沙盒那样跑到经纬度都是0的海域点。--Srapoj（留言） 2025年11月3日 (一) 19:57 (UTC)

交到phab:T409119了。--Srapoj（留言） 2025年11月3日 (一) 22:22 (UTC)

2025年第45期技術新聞

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

近況更新 - 面向編輯者

• Special:MergeHistory獲更新，大幅提升了合併功能的靈活性，以便管理員使用。該特殊頁面現在能夠從來源頁面歷史的中段提取段落進行合併，而不僅限於從開頭提取；同時，它也能將修訂版本插入目標頁面歷史中的任意位置，而不僅限於插入開頭。 [3]
• 現在，對於在偏好設定中啟用「自动订阅话题」功能的使用者，無論其透過何種編輯介面來新增或回覆話題，系統皆會自動為其訂閱該話題。先前，僅當使用討論工具（DiscussionTools）的「添加话题」或「回复」按鈕時才會觸發自動訂閱。討論工具最初推出時，既有帳號並未預設啟用自動訂閱話題功能，因此本次變更主要影響較新帳號，以及曾主動更改偏好設定的使用者。 [4]
• Scribunto模組現在能夠生成SVG圖像。此功能能透過Lua來動態建立圖表、圖形及其他視覺化內容，減少外部製圖後上傳檔案的需求。 [5]
• 維基媒體網站現在為所有匿名使用者提供啟用深色模式（黑底白字配色方案）的選項。這項改進旨在提供更舒適的閱讀體驗，尤其是在光線昏暗的環境下。 [6]
• 存有龐大監視清單的使用者長期以來在編輯Special:EditWatchlist頁面時遭遇逾時（timeout）問題。如今透過分頁（paging）機制更新，該頁面將分批載入項目，而非一次性載入全部內容，使所有使用者皆能順暢編輯監視清單。作為資料庫更新的一部分，我們移除了按到期時間排序的功能，因其速度比按標題排序慢100倍以上。我們提交了一件社群願望，探討恢復按到期時間排序功能的替代方案。若該功能對您至關重要，敬請投票支持該願望！ [7]
• 上週有31件由社群提交的工單得到解決。 例如，之前在視覺化編輯器的「尋找與取代」功能中，即使修改尋找欄位的文字，頁面中原先的文字仍持續高亮顯示，此問題現已修正。 [8]

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

• 自2019年起，維基媒體縮網址服務（網址：https://w.wiki）開放所有維基媒體維基站點使用，可為條目、永久連結、差異頁面等內容建立短網址。該功能可透過側邊欄的「获取短链接」連結存取。目前仍有30個維基站點同時安裝舊版「ShortUrl」擴充功能。舊版擴充功能即將移除，意味著/s/短網址（以帶有class="title-shortlink"的標籤包裹）將不再直接顯示於條目標題下方。但/s/短網址將持續正常運作。 [9]
• 10月30日（四），MediaWiki介面團隊與SRE服務運營團隊開始將Action API流量重新路由至共同API閘道。各維基站點將依據標準MediaWiki版本更新分組進行更新，整體流量將隨時間逐步提升。此變更應為非中斷更新。若發現任何問題，請至Phabricator的服務運營團隊看板提交工單。
• MediaWiki部署列車將於2025年最後兩週（12月22日、29日）暫停。向後移植窗口亦將於2025年12月22日（一）至2026年1月2日（四）期間暫停。向後移植窗口係指預定執行錯誤修正與配置變更等作業的時段。2025年尚餘七次列車部署作業。 [10]
• 本週軟體更新細節： MediaWiki

深入了解

• 維基媒體基金會指出，由於AI系統與搜尋引擎頻繁引用維基百科內容，卻未能將使用者導向該網站，導致2025年真人瀏覽量較2024年下降8%。在觀察到機器人偽裝成真人的現象後，維基媒體更新了流量數據以反映此變化。關於維基百科當前使用者趨勢，請參閱Diff文章。

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

MediaWiki message delivery 2025年11月3日 (一) 19:33 (UTC)

虽然这个新的合并历史功能上上周已经部署了，但@Iokseng：应该是您的好消息，可以少倒腾几次。--Srapoj（留言） 2025年11月3日 (一) 20:15 (UTC)

欸我剛看到正打算要在下面ping他，被搶先了笑死XD —— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年11月4日 (二) 22:40 (UTC)

在桌面端測試閱讀清單功能

大家好，

正如我們先前所分享的，讀者體驗團隊將於11 月 10 日當週啟動一項實驗，將「閱讀清單」引入桌面端和行動網頁端體驗。此實驗將允許活躍讀者保存他們想稍後再閱讀的文章。文章將被整理成一個清單，讀者可以在他們的帳戶中存取。

我們為何要進行這項實驗？

讀者體驗團隊致力於確保現有的讀者——那些已經在網站上花費時間的讀者——擁有工具，以便他們能夠盡可能深入且頻繁地閱讀維基百科。我們認為，這種與維基百科的積極聯繫可以讓現有讀者更接近完成他們的首次編輯。

加強這種聯繫的一種方式，是為讀者提供更多塑造閱讀體驗的方式。例如：儲存文章以供稍後閱讀、突出顯示突出的句子，或收集文章片段。這些功能將使人們能夠更靈活地以最適合自己的方式使用維基百科。

為此，我們希望首先探索最簡單的方法——允許讀者將文章儲存到清單中以供日後閱讀。目前，閱讀清單和標籤等策展功能是 Android 和 iOS 應用程式中最常使用且最受歡迎的功能之一，長期以來，用戶一直希望能夠實現包括桌面裝置在內的跨裝置同步。

模型圖:

https://commons.wikimedia.org/wiki/File:Saved_Pages_Wikipedia_Demo_1.gif

這個專案處於哪個階段？

在 A/B 測試完成後，我們將共同討論結果，並決定是否繼續進一步測試以及在行動端和桌面端建構此功能。

時間安排

我們將從11 月 10 日當週開始，與一小部分已登入的讀者（帳戶編輯次數為 0）一起測試原型。該實驗將持續四週。

此實驗包括哪些內容？

在本次實驗中，我們將首先針對已經熟悉維基百科的極少數受眾測試閱讀清單功能。因此，我們選擇了一群已登入的讀者，他們擁有帳戶但尚未成為編輯者（即編輯次數為 0，且尚未使用過編輯相關功能）。對於這一群體，我們希望測試以下功能：

• 允許讀者將文章儲存到個人清單以供日後閱讀

• 允許讀者訪問他們的清單並刪除不再相關的文章

如果此實驗成功，團隊將考慮添加其他功能，例如將清單與應用程式同步、建立多個自訂清單，或將文章的不同部分儲存到集合中。

有關實驗時間安排、研究問題及其他詳細資訊，請參閱專案頁面。

歡迎在此分享您的想法和問題！我們在上一則貼文中也提出了一些更具體的問題。--EBlackorby-WMF（留言） 2025年11月3日 (一) 22:29 (UTC)

統一Template:RSNG的圖示內部連結

小弟發現Wikipedia:可靠来源/布告板/评级指引#來源評級的所有來源分級圖示均有內部連結，但在Template:RSNG僅有 加入防濫用過濾器、 应停用、 列入黑名單有內部連結外，其他均沒有。是否有想統一的打算，因為在WP:RSP中若使用{{RSNG}}，僅有三種來源分級有內部連結，其實看起來滿奇怪的。--英國皇家歐拉夫王子（留言） 2025年11月4日 (二) 14:02 (UTC)

因RSP屬論述，故直接更改完成。--英國皇家歐拉夫王子（留言） 2025年11月6日 (四) 08:30 (UTC)

怎麼回退一人的所有編輯

我記得以前有一個小工具，會在使用者貢獻下拉選單給出回退編輯按鈕，但現在找不到了，反破壞有點麻煩。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年11月4日 (二) 22:38 (UTC)

User:Alexander_Misel/smart_rollback.js，在用户贡献页面右上角显示“智能回退”按钮。--ChasingAir^留言 2025年11月5日 (三) 06:00 (UTC)

我有裝，但以前有一個直接跳框回退的，應該更強一些？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年11月5日 (三) 16:12 (UTC)

請試試看這版本m:User:Hoo_man/Scripts/Smart_rollback是否合用。--英國皇家歐拉夫王子（留言） 2025年11月6日 (四) 07:56 (UTC)

行動版註腳斜體問題

似乎至今沒有修好，社群是否有解方？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年11月5日 (三) 16:10 (UTC)

需要修订MediaWiki:Minerva.css，在最开头加入cite {font-style: normal;}，附@Diskdance。--Dabao qian℡ 2025年11月5日 (三) 16:30 (UTC)

完成，请复查。--碟之舞📀💿 2025年11月6日 (四) 02:21 (UTC)

改善封禁提示在窄屏下的显示效果

本站封禁提示的实现近期由U:Dabao qian完成了翻新（讨论）。然而见到小红书上的截图后，我意识到当前{{Blockedtext}}在手机上的效果很糟糕：边距过宽，使得留给封禁原因和申诉方式的框的宽度过少。我考虑过把<div style="margin: auto; width: 70%;">换成<div style="margin: auto; max-width: 600px; padding: 0 0.25em;">，但它内部两个带背景的框可能必须要用media query设置断点才能做的好看。

目前这版的样式是U:Bluedeck在2017年初设计的（讨论），不便被封的朋友可以去T:Blockedtext/doc预览常见封禁情况的显示效果。因本人美工过差、且没想好怎么改它，遂发到这里征求意见。--Srapoj（留言） 2025年11月5日 (三) 20:05 (UTC)

{{Blocked proxy}}等封禁理由模板也需要更新，避免在移动设备上使用<table>，<table>元素应尽量替换为<div>。--Dabao qian℡ 2025年11月6日 (四) 06:48 (UTC)

谢谢报告问题！我觉得margin-auto + max-width-600 + width 90% 或者类似的数值应该能实现不错的效果。至于背景其实要不要都可以，只要最终的设计不可怕就可以。有时间的话我这几天搞搞看。Bluedeck 2025年11月7日 (五) 10:14 (UTC)

跨语言链接增强工具已更新

本次更新主要解决了移动版一处问题。如果发现对应功能出现问题，请于此处回报，谢谢。--碟之舞📀💿 2025年11月6日 (四) 09:29 (UTC)

一时脑抽找不到按钮了

存草稿键在哪来着-- YX Z 2025年11月7日 (五) 19:11 (UTC)

意思是创建新草稿？

按钮--Luoniya（留言） 2025年11月8日 (六) 01:54 (UTC)

不知道是不是和article wizard改版有关。新版Wikipedia:条目向导点击下方小字“跳过”即可直接展示创建草稿页面。或者使用捷径WP:WIZGO。--PexEric 2025年11月8日 (六) 13:20 (UTC)

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

--Sksawf（留言） 2025年11月8日 (六) 08:50 (UTC)

好問題，好問題 :( —— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年11月9日 (日) 15:35 (UTC)