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

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

发表新议题

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

公告欄

• [投票] 2026年春节标志方案投票正在进行中，欢迎参与。
• [分享] 2026年1月15日是维基百科成立25周年，一起写下你对维基百科的美好祝愿！
• [公告] Reaction小工具加入MediaWiki:Gadgets-definition、維基百科生日模式彩蛋、修改全站侧栏（MediaWiki:Sidebar）、更新電子遊戲格式手冊「外文标注」內容、修訂被不限期封鎖者的除權相關規定及修訂非原創研究方針有關翻譯的規定已經通過。
• [公告] 在《討論的發起位置》中討論發起處部分添加「專題討論頁」字眼、合并大量账号建立者和活动组织者、修訂快速刪除方針G14條、引入英文維基百科快速刪除方針C4條及修訂快速刪除方針A2、A3與A6條正在公示，如有意見請盡快提出。
• [討論] 互助客栈正在討論维基百科25周年和新年标志、再次提议“特色列表”改名及默认使用text-autospace为中英文之间添加空白的后续，歡迎踴躍參與。
• [討論] 社群正在討論Hang on模板在文件命名空间的使用、人物出生及逝世日期分類問題、釐清提刪模板模組前的必要手續、有關非編號命名的城市軌道交通鐵路綫的條目命名、確立列表收錄標準為正式指引、电子游戏角色外文标注及「臺灣光復節」條目章節排版問題，歡迎踴躍參與。
• [广告] 为协助基金会开发者将字词转换系统适配到本年将部署的Parsoid解析器，欢迎完善字词转换系统的英语文档或审阅其简介草稿。

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

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	提議：高亮哈佛参考文献格式短鏈指向的完整資料引用	56	9	Ericliu1912	2026-01-21 07:42
2	改善字体的讨论怎麼又死了	14	7	Diskdance	2026-01-27 11:44
3	中文字元與拉丁字母、數字之間在顯示上被自動加入空格	25	11	Diskdance	2026-02-10 11:51
4	徵求意見：Reaction 小工具加入 MediaWiki:Gadgets-definition	150	12	SuperGrey	2026-02-10 19:25
5	Request for Translation of LanguageConverter documentation	17	5	魔琴	2026-02-03 16:50
6	提議公開過濾器39	8	5	Exusiai	2026-02-01 17:00
7	提議以機器人自動為條目添加Authority control模板	10	6	Shizhao	2026-01-31 19:29
8	-{}-在 Wikipedia:互助客栈/条目探讨 的簡體變體頁面疑似失效了	2	2	Srapoj	2026-02-01 20:18
9	2026年第6期技術新聞	4	3	Shizhao	2026-02-04 10:57
10	Template_talk:Talk_header#回報問題：存檔只能存為簡體格式的相關討論	1	1	Saimmx	2026-02-04 15:51
11	Search怎么了	8	4	Kurgenera	2026-02-10 18:54
12	使用特定模板之外部連結吃封鎖網域通知的問題	1	1	AromaTake	2026-02-09 18:01
13	{{Infobox PRC legislation}}的修訂相關參數不顯示	2	2	Kcx36	2026-02-10 01:19
14	2026年第7期技術新聞	1	1	MediaWiki message delivery	2026-02-10 07:27
15	iOS无法登陆	1	1	Babala745	2026-02-10 19:50

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

正在廣泛徵求意見的議題

議題清單

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

MediaWiki talk:Gadget-MarkRights.css § 編輯請求 2025-02-21

有鉴于过滤器编辑者用户组已经正式部署，在此建议使用同管理员颜色一样的“滤”标记过滤器编辑者。这样，相较于“编”，可以使用户更好理解标记含义。Iming 彼女の愛は、甘くて痛い。 2025年5月30日 (五) 18:01 (UTC)

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

此討論正在公示7天，直至2026年2月15日 (日) 15:44 (UTC)結束，如有意見，請盡快提出。

最近在看优良条目广州市时发现，该条目之前多次参与优良条目评选和优良条目重审，导致其讨论页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:互助客栈/其他 § RfC：翻新新手引导系列页面

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

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

--PexEric 2025年11月16日 (日) 13:14 (UTC)

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

@Dabao qian：是否可代為提出請求？我不懂技術，不知道應該應用什麼方案。是這個麼？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年1月20日 (二) 23:42 (UTC)

副知@Shizhao。@Dabao qian：不過這個現在是什麼情況？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2025年12月3日 (三) 08:57 (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)

這個討論現在是什麼情況？另外，間隔號真的不能使用全形麼？又若無法統一推廣，是否可能提供個人小工具？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年1月20日 (二) 23:43 (UTC)

我说，要不先上我之前说的尽可能贴近默认UI字体的做法吧。一点点改进总比不改好。

像这样：font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif;。Minerva的字体列表基本上就是这个。--碟之舞📀💿 2026年1月27日 (二) 03:44 (UTC) 👍1

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

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

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

简体的font也是占一格的，不管是繁简体的设计，都是左边有半格的空白。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年2月3日 (二) 10:16 (UTC)

其实「是有的，U+FF62 ｢ HALFWIDTH LEFT CORNER BRACKET，但这并不影响什么（ ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年2月3日 (二) 10:14 (UTC)

（feature or bug?）發現在firefox上，半形符號與中文相連時，中間沒有autospace，例如「1%至2%」中「%」與「至」之間沒有autospace（但chromium系似乎沒有此問題）。--有線耳機（留言） 2026年2月5日 (四) 06:23 (UTC)

%属于Unicode character category Po (Punctuation, other)，因此Firefox的行为看起来符合text-autospace: normal的要求（只在汉字与字母或数字间加入空格）。--Srapoj（留言） 2026年2月5日 (四) 11:50 (UTC)

這裡的空格不會指望我們手動加吧？Firefox應該通融一下這種例外情況。 --SuperGrey (留言) 2026年2月5日 (四) 22:20 (UTC)

Firefox应该是严格按照spec实现的，所以spec的bug也抄过来了。--碟之舞📀💿 2026年2月10日 (二) 03:51 (UTC)

一味追新？

我检查了MDN文档。text-autospace的支援矩阵惨不忍睹，最早提供支援的是Safari和它的Webkit；但也不到一年。如此行为完全违反了基金会的compatibility指南。 MilkyDefer 2026年2月3日 (二) 09:51 (UTC)

(～)補充：根据CanIUse的统计，这个属性只能覆盖到九成的手机使用者和六成的电脑使用者，难谓成熟技术。--MilkyDefer 2026年2月3日 (二) 10:02 (UTC)

这又不是什么缺了会明显影响使用的必需功能，对旧浏览器用户来说显示效果和以前没有区别（属于老话说的progressive enhancement）。真被废弃的只有原来的js小工具，本身是给登录用户用的。--Srapoj（留言） 2026年2月3日 (二) 11:14 (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-feature.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=Wikipedia: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)

对列入小工具无意见，但不应设置为默认启用。另外希望可以在文档中写明如何屏蔽reaction（指在自己的commons.css里display none）。 Stang¹⁰⁹⁸ 2026年1月19日 (一) 02:19 (UTC)

私自怎麼屏蔽都可以，但是文檔中我不能這樣教——您可能沒有想那麼多，但這樣的做法就相當於屏蔽他人的評論，是不道德的行為。 --SuperGrey (留言) 2026年1月19日 (一) 05:49 (UTC)

個人覺得不無道理，本質上reaction不是Mediawiki內建的功能，可以考慮設置為只有使用者啟用了reaction才顯示，猜測Stang君想表達的也是這個意思。--Hamish T 2026年1月19日 (一) 07:13 (UTC)

在原始碼中也有出現的、用wikitext模板紀錄的內容，如果預設不顯示出來，不是更加迷惑？而且這還是帶有簽名和時間戳的「準評論」，再怎麼說也是他人的發言，用「非內建功能」也難以合理解釋屏蔽的做法吧⋯⋯這又不是什麼「投票模板」之類的可以寫一個「以純文本替代投票模板」的小工具；您二位如果讓我寫一個「以純文本替代Reaction模板」的小工具或許還更合乎常理一些？ --SuperGrey (留言) 2026年1月19日 (一) 10:15 (UTC)

reaction出来的emoji不能够直接表达意见或者说表达的意见不够明确，而且许多emoji本身是可以具有两面性的（当然文字也可以），以😂举例，假设我对某一条意见使用这个emoji，一方面可以讲我认为这个意见“很有意思，值得支持”，一方面也可以说这个意见“啼笑皆非”。就好像如果我或者其他人直接回复您这条意见“笑哭”二字，这种评论应该还是没有正当合理到“忽略其是不道德的”这个地步。不过，不可否认这个事情确实要遵从开发者意愿进行取舍。--Hamish T 2026年1月19日 (一) 10:22 (UTC)

上一条是回复的时候编辑冲突了直接复制下来的，对于原始码这个事情吧，其实我觉得无所谓哈，但是就如我上一条的最后一句话，看开发者如何取舍。--Hamish T 2026年1月19日 (一) 10:32 (UTC)

對，Reaction模板是有此問題，如果使用者使用的不是👍、👎之類的態度明確的emoji，含義會不那麼清楚。但即使是這樣的留言也是留言，因為別人存在「沒有表達清楚」的可能性，就可以都屏蔽起來？「以純文本來顯示Reaction」還算合理訴求，畢竟只是替代顯示；直接屏蔽實在是不道德，偷偷做可以，教學不行。 --SuperGrey (留言) 2026年1月19日 (一) 10:45 (UTC)

「以純文本來顯示Reaction」或许是个折中解，但需要耗精力就是了。这就类似于用iMessage给非ios设备发送一些表情，对方会显示纯文本，一个道理。--Hamish T 2026年1月19日 (一) 10:49 (UTC)

我只是拿來舉例子，我相信Stang君提到「把如何屏蔽寫進教程」，目的上應該沒有要看「純文本版Reaction」的意思 。 --SuperGrey (留言) 2026年1月19日 (一) 10:54 (UTC)

我想了想，倒是可以做一個「隱藏/顯示『添加Reaction』按鈕」的開關，放在p-cactions？這樣至少可以把介面上到處都是的添加按鈕隱藏起來，乾淨一些？ --SuperGrey (留言) 2026年1月19日 (一) 11:10 (UTC)

@Stang、Hamish：我想了想，應該接入全局開關，小工具預設狀態為不能修改/添加Reaction（相當於未登錄狀態），在右側工具欄手動開啟小工具後，方顯示添加按鈕、可編輯Reaction。這樣的做法不知是否會讓您滿意？這樣即使是預設啟用，小工具除tooltip popup以外的所有功能也不會加載；當需要使用時，再從工具欄打開（記憶狀態）。 --SuperGrey (留言) 2026年1月20日 (二) 05:53 (UTC)

新版本已經部署。不知是否符合預期？ --SuperGrey (留言) 2026年1月20日 (二) 06:43 (UTC)

个人认为工具栏项会不太好找。+反应 按钮的显隐可能不需与追加反应的功能（能力）绑定。“屏蔽reaction”的需求我认为应予尊重，reaction的重要性和严肃性尚未明显，更接近一个赞踩而不是投票的工具，明确的态度仍以留言为准，例如计票时不会考虑反应、原有{{+1}}类模板的设计相当不起眼，也不容易考量表达反应者的具体态度、时间点、是否阅读了其余留言。或许可以有“+反应”及各个反应的缩小化、折叠的设计。Reaction工具的开关、“+反应”的显示等设置，在已有反应的悬停框中是否能有表现呢。--YFdyh000（留言） 2026年1月20日 (二) 07:23 (UTC)

我把開關改在了「外觀」中，這樣或許更有親和力，也更明顯一些。另外我也在懸停框中加入了連結，以把使用者引導到此處。您看看效果如何？ --SuperGrey (留言) 2026年1月20日 (二) 20:47 (UTC)

注：原來在工具欄的開關保留，但是只在其他skin顯示；Vector 2022不顯示。 --SuperGrey (留言) 2026年1月20日 (二) 20:52 (UTC)

还行。不确定启用下的悬停框是否要加引导文字，用户可能不知能隐藏。不关联思考“+反应”按钮时的“反应”选项可能不太直观，但我没有更好想法，但或许可以加tooltip说明。--YFdyh000（留言） 2026年1月20日 (二) 22:02 (UTC)

想停用的使用者當然知道如何停用，因為小工具的預設狀態就是停用，是他們手動開啟的。
不太直觀的問題，我想或許做個引導彈窗（很多網站都有的那種，帶圖文的）可以解決。但是那樣就有點intrusive（侵入性）了，和Wikipedia的設計語言不太貼合 。 --SuperGrey (留言) 2026年1月21日 (三) 23:30 (UTC)

也算是怪我之前没有说的很明白，在我个人看来reaction这类行为本身信息量很低且可能引起误会，是没法跟平常的回复、评论相提并论的；另外也算是一点非常自我的想法，就是看着这个感觉不怎么喜欢 :(（其实telegram中群组里的也一样）。给出一个关闭的选项这一折衷我觉得可以接受，但也需要说明上加上诸如“你发出的reaction其他人可能无法看到”这种提示。@SuperGrey： Stang¹⁰⁹⁶ 2026年1月20日 (二) 15:23 (UTC)

OK，做好了。您看看效果如何？ --SuperGrey (留言) 2026年1月20日 (二) 20:43 (UTC)

看来我没猜错Stang君的意思。--Hamish T 2026年1月24日 (六) 18:03 (UTC)

至於要不要成為預設小工具，我提供一個角度：
行動版視圖的使用者，他們可以看到Reaction卻不能查看tooltip，這其實是不太好的，accessibility有虧；之前英維有人提出這個質疑，所以我才另外做了一個對手機電腦都能清楚顯示的浮窗，用於確保讀者可以便捷看到每個Reaction的作者和時間戳。這或許是預設的好處——讓行動版視圖的使用者也可以檢視作者和時間戳，而並非只有安裝了的使用者能看到。 --SuperGrey (留言) 2026年1月19日 (一) 11:01 (UTC)

提供屏蔽方法+1。有些不同於Stang君，我不喜歡這個東西、也不認為這是討論該用的東西（首先，情緒表達不應替代討論；再來，按讚數很容易帶風向；最後，我不想看到維基百科變得像臉書或是知乎那樣。總之原因多得不想多說），但在如此受歡迎的情況下，最起碼，我希望知道如何屏蔽。我不同意這個要求不道德。Hamish提到的預設不顯示，只有開啟了才顯示，這也許是個好辦法。--Saimmx（留言） 2026年1月29日 (四) 06:21 (UTC)

目前已經提供了屏蔽功能（在「外觀設定」中）；預設不使用也做好了⸺現在新使用者將不會啟用「反應」功能，必須手動在「外觀設定」中開啟。 --SuperGrey (留言) 2026年1月29日 (四) 06:33 (UTC)

啊，謝謝啦。我很久以後才能回這個。--Saimmx（留言） 2026年1月29日 (四) 06:51 (UTC)

本地时区代码目前有bug，我的mw.user.options.get("timecorrection");是'Offset|480'，脚本目前将时间显示为 (UTC+5:20)。parseOffsetMinutes的逻辑有误[1]，正则表达式错误匹配，将"480"解读为4小时80分钟。--YFdyh000（留言） 2026年1月19日 (一) 03:00 (UTC)

感謝反饋！我稍後修復看看。 --SuperGrey (留言) 2026年1月19日 (一) 05:51 (UTC)

 已修复。煩請複查問題是否還存在。 --SuperGrey (留言) 2026年1月20日 (二) 06:45 (UTC)

可以了，已解决。--YFdyh000（留言） 2026年1月20日 (二) 07:10 (UTC) 👌1

对匿名用户的留言的反应似乎有问题，“[Reaction] 原文中找不到时间戳：2026年1月25日 (日) 03:45 (UTC) (timestamp found but none of the signatures matched author "~2026-51566-3")”。错误提示也有误导，是源码中找到了时间戳但找不到签名，可能因为源码中～被转义了。以及，移动设备里面板左侧可能轻微展示不全，[2]viewport宽度360px。--YFdyh000（留言） 2026年1月26日 (一) 00:29 (UTC)

 已修复：現在應該可以發出Reaction了。樣式表也做了修訂。 --SuperGrey (留言) 2026年1月26日 (一) 02:49 (UTC) 👌1

討論滿30天，看大家已經都接受此小工具預裝載，故 公示7日，2026年2月8日 (日) 09:38 (UTC)結束。 --SuperGrey (留言) 2026年2月1日 (日) 09:38 (UTC)

通過。請求介面管理員處理。 --SuperGrey (留言) 2026年2月8日 (日) 10:28 (UTC)

等等，請回應我這些疑慮，另參見維基百科:互助客棧/方針#Template:Reaction：

第一，我認為這項功能主要是用來向留言表達態度，但卻讓使用者免於說明理由或承擔解釋的責任。

第二，這項功能對維基的討論有何必要性？徵求意見的說明中並未指出具體目的，感覺更像是出於社交用途。

第三，目前的使用方式毫無準則，完全可以被濫用來網路霸凌持不同意見的使用者，畢竟留下個emoji並不需負責任。我完全不同意「騷擾應該程度有限」的說法，天知道User:糯米花留下的「😄」代表什麼意思？我完全不懂怎回應（參見維基百科:互助客棧/方針#Template:Reaction）。

第四，我並沒有拒絕這項功能的選項，不只是預設關閉，而是預設拒絕，不是讓我只能被動接受。

第五，關於如何防範「濫用與騷擾」，假如使用者明確表示不希望他人使用此功能，但其他人仍照舊貼上emoji，這樣是否就構成了「濫用與騷擾」？

第六，那麼其他使用者又該如何得知某位使用者（例如我本人）拒絕在留言上被他人加上emoji呢？

第七，如果本人刪去他人留下的emoji，算不算等同刪去他人留言而觸犯方針？--Iflwlou ☯I♨I☀ 2026年2月10日 (二) 00:12 (UTC)

Iflwlou君說出我的想法，有時候當看到管理員也在用的時候，難免會想，這是不是對某些用戶表達了喜歡或偏愛或討厭，而不是因為說對了或說錯了甚麼。公示通過後，我想拒絕安裝也拒絕被emoji是無從選擇的，若是往後某條留言被加上大量的emoji造成了該使用者產生暫不可緩解的壓力，這樣能有地方申訴？--提斯切里（留言） 2026年2月10日 (二) 01:39 (UTC)

我好肯定「大家已經都接受」這東西的前設不存在。--Iflwlou ☯I♨I☀ 2026年2月10日 (二) 01:55 (UTC)

其實我一直到剛剛看到Iflwlou君的留言才恍然大悟，原來要邁向預設安裝之路啊（--提斯切里（留言） 2026年2月10日 (二) 01:58 (UTC)

引用我自己在維基百科:互助客棧/方針#Template:Reaction的留言：留下一個emoji但不用負解釋的責任（而且我不知該emoji反映什麼態度，不想回答就不要丟emoji，回答了emoji更加沒用處，多此一舉），而刪去了就要負上觸犯方針的問題（我個人認為沒有，留下emoji既然沒有解釋的義務，我刪去沒有任何意義的emoji，等同把他人留在的身邊的垃圾丟走一樣，不負解釋的責任，不要指望跟留言有同一保障），沒有任何拒絕的方法，還要動用到互动禁制才可以治標不治本，我認為這個東西非常有問題，漏洞百出，對維基弊大於利，我極不同意其實施，簡直荒謬。

而且對討論有害，例子：

用戶甲：我認為XX是對的。😄1😱1

用戶乙：你在說什麼啊，XX是錯的，這是常識！👍4🔥2

我在看來，這是一眾覺得自己反駁不了用戶甲，就以emoji來為用戶乙助威的效果，導致看起來用戶乙更有理。這個emoji對維基沒意義，擾亂討論，甚至於有違反wp:文明和WP:持眾凌寡的嫌疑。--Iflwlou ☯I♨I☀ 2026年2月10日 (二) 02:16 (UTC)

我拒絕這東西的「預設安裝」，我不想維基淪為某些牌子的「反電腦病毒防衛軟體」，預設安裝有毒的東西。--Iflwlou ☯I♨I☀ 2026年2月10日 (二) 02:32 (UTC)

您上來就指控社群已經討論一個月並公示通過的事物「有毒」，是否符合WP:CIV方針？ --SuperGrey (留言) 2026年2月10日 (二) 02:53 (UTC)

那您肯定沒關注Bulletin。已經掛在上面很久了。 --SuperGrey (留言) 2026年2月10日 (二) 03:02 (UTC)

您的指控缺乏實據，反而具有一些邏輯謬誤和無端猜測。

1. 畢竟留下個emoji並不需負責任是您的猜測而非事實。實際上，在任何頁面加入任何內容都是需要負責任的。
2. 我並沒有拒絕這項功能的選項⸺其實是有的，小工具裝載後，便可以在小工具內找到停用和隱藏的選項。選擇「隱藏」後，即可完全隱藏所有{{Reaction}}，可以實現真正的「眼不見為淨」；反而如果小工具不裝載，則無法實現完全隱藏所有{{Reaction}}之功能。
3. 關於如何防範「濫用與騷擾」⸺您不能阻止他人對您的評論進行表態，無論是通過留言還是{{Reaction}}。互動禁制是由管理員來決定的。您如果不希望某人與您互動，可以去申請，但我不能保證通過。

--SuperGrey (留言) 2026年2月10日 (二) 03:08 (UTC)

關於第2點，所以一定要裝載才能「眼不見為淨」是嗎？假設若是有A用戶會一直對B用戶的留言留下emoji，A用戶B用戶認為此舉已經造成騷擾，也申請互動禁制也可能造成失敗，因為假定善意？--提斯切里（留言） 2026年2月10日 (二) 03:14 (UTC)

對，裝載後就可以使用「眼不見為淨」功能了。
至於您舉例情況是否造成騷擾，需要由社群判斷。我個人認為，如果A用戶明確表態「B用戶造成騷擾」，並通告B用戶，B用戶仍窮追不捨，應該屬於騷擾，可以進ANM了。 --SuperGrey (留言) 2026年2月10日 (二) 03:17 (UTC)

另外我想請問，因為我沒有理解這個小工具怎麼使用。所以想知道預設通過後，若是不知道怎麼關掉或拒絕使用的用戶，有沒有懶人包教學關閉或是實現拒絕使用呢？--提斯切里（留言） 2026年2月10日 (二) 03:18 (UTC)

其實裝載後的預設狀態是「不啟用」的。「啟用」或「完全隱藏」則是需要手動進行的，有對應的提示。 --SuperGrey (留言) 2026年2月10日 (二) 03:19 (UTC)

提示介面管理員⸺小工具通過公示後的新討論，其實與Reaction小工具本身是否實裝無關（參見#實裝小結），而是與WP:討論頁指引、「{{Reaction}} 是否為留言」相關。故小工具應該繼續推進實裝。實裝之後，才得以提供「行動版視圖顯示反應留言者」、「隱藏全部反應的選項」，這也是小工具徵求意見期間的主要訴求。 --SuperGrey (留言) 2026年2月10日 (二) 05:24 (UTC)

另外我想問，有沒有可能有個反向小工具，讓用戶可以安裝，拒絕留言被emoji？--提斯切里（留言） 2026年2月10日 (二) 05:56 (UTC)

這確實可以考慮。技術上就是另外弄個黑名單，不喜歡的用戶就在黑名單填入自己的名字，接著在發表表情時，透過前端制止。這不一定能阻止真的發送，但技術上制止應該可以有效減少數量。--Saimmx（留言） 2026年2月10日 (二) 06:19 (UTC)

我可以做一個黑名單功能看看。 --SuperGrey (留言) 2026年2月10日 (二) 07:18 (UTC)

功能已實現，參見此留言。 --SuperGrey (留言) 2026年2月10日 (二) 09:29 (UTC)

後續討論

有沒有人提供Template:Reaction的相關討論，我想知道其為何出現，對討論有什麼必要性，使用方針如何？--Iflwlou ☯I♨I☀ 2026年2月9日 (一) 12:10 (UTC) 😄1

部分讨论在Wikipedia:互助客栈/技术#徵求意見：Reaction 小工具加入 MediaWiki:Gadgets-definition--YFdyh000（留言） 2026年2月9日 (一) 19:48 (UTC)

第一，我認為這項功能主要是用來向留言表達態度，但卻讓使用者免於說明理由或承擔解釋的責任。

第二，這項功能對維基的討論有何必要性？徵求意見的說明中並未指出具體目的，感覺更像是出於社交用途。

第三，目前的使用方式毫無準則，完全可以被濫用來網路霸凌持不同意見的使用者，畢竟留下個emoji並不需負責任。我完全不同意「騷擾應該程度有限」的說法，天知道User:糯米花留下的「😄」代表什麼意思？我完全不懂怎回應。

第四，我並沒有拒絕這項功能的選項，不只是預設關閉，而是預設拒絕，不是讓我只能被動接受。

第五，關於如何防範「濫用與騷擾」，假如使用者明確表示不希望他人使用此功能，但其他人仍照舊貼上emoji，這樣是否就構成了「濫用與騷擾」？

第六，那麼其他使用者又該如何得知某位使用者（例如我本人）拒絕在留言上被他人加上emoji呢？

第七，如果本人刪去他人留下的emoji，算不算等同刪去他人留言而觸犯方針？--Iflwlou ☯I♨I☀ 2026年2月9日 (一) 22:21 (UTC)

免于理由+1。解释责任我认为仍有，虽然不是强制性的回答义务，但拒绝回答或回答方式本身是种态度。

免于理由的表态或回应。节省时间及版面，有时有可能避免在讨论中吵起来或非必要延伸话题。避免将表态立即通知话题订阅者。没那么社交，还应是表态为主，应禁止社交（滥发）。

是的，我有这个担心。

您说功能还是显示，显示而言以往也有{{+1}}模板被手工使用。该工具已在侧栏提供“停用”和“全部隐藏”的功能。我觉得表态通常不需要回应，不是留言本就没期望乃至不想被回应。

目前没有相关规范，也无法拒绝。部分极端情况可由互动禁制介入。

我认为算。--YFdyh000（留言） 2026年2月9日 (一) 23:03 (UTC)

留下一個emoji但不用負解釋的責任（而且我不知該emoji反映什麼態度，不想回答就不要丟emoji，回答了emoji更加沒用處，多此一舉），而刪去了就要負上觸犯方針的問題（我個人認為沒有，留下emoji既然沒有解釋的義務，我刪去沒有任何意義的emoji，等同把他人留在的身邊的垃圾丟走一樣，不負解釋的責任，不要指望跟留言有同一保障），沒有任何拒絕的方法，還要動用到互动禁制才可以治標不治本，我認為這個東西非常有問題，漏洞百出，對維基弊大於利，我極不同意其實施，簡直荒謬。--Iflwlou ☯I♨I☀ 2026年2月9日 (一) 23:11 (UTC)

这个和“感谢”有何不同？--糯米花🌾🌼 2026年2月10日 (二) 02:52 (UTC)

我不認為表態「👎」或「❌」是「感謝」……另外我看沒有人會用🖕，但技術上要表態「🖕」，似乎是可以辦到的。--Saimmx（留言） 2026年2月10日 (二) 03:34 (UTC)

如果有人這麼做，不是主動把自己送進ANM嗎？表達惡意的途徑有很多，這與功能本身無關啊。 --SuperGrey (留言) 2026年2月10日 (二) 03:38 (UTC)

既有署名也有時間戳，與普通「評論」並無不同，故當然按照評論的處理辦法來處理即可。
刪去他人emoji的確等於刪去他人留言。 --SuperGrey (留言) 2026年2月10日 (二) 02:56 (UTC)

我怎麼覺得，應該要立一條，使用者可以刪去他人對自己的文字留下的emoji。有添加的自由，也可以擁有移除的自由。--提斯切里（留言） 2026年2月10日 (二) 03:33 (UTC)

同意。如果我不安裝就無法不顯示的話。--Saimmx（留言） 2026年2月10日 (二) 03:35 (UTC)

您看仔細他表達的意思，不要直接就跟。 --SuperGrey (留言) 2026年2月10日 (二) 03:40 (UTC)

但是很抱歉，刪除他人留言不屬於您的自由。 --SuperGrey (留言) 2026年2月10日 (二) 03:37 (UTC)

這並不相悖的，只有在這項小工具使用的方針，除非過濾器判斷emoji是留言的一種。--提斯切里（留言） 2026年2月10日 (二) 03:42 (UTC)

我是不想安裝派，未來也不會啟用，但若看到有人對我的留言emoji，我可以自由移除，這是我認為可以的。--提斯切里（留言） 2026年2月10日 (二) 03:44 (UTC)

「我認為可以」≠「可以」，您先辨析這二者的區別。如我留言，您可以另外推動方針修訂。 --SuperGrey (留言) 2026年2月10日 (二) 03:47 (UTC)

就跟任何一位使用者，在不違背討論頁使用方針下，可以決定甚麼內容留在自己的討論頁，是可以擁有的一項自由，維基百科不強迫任何人參與，emoji應該也能跟隨這指引。--提斯切里（留言） 2026年2月10日 (二) 03:48 (UTC)

可以決定甚麼內容留在自己的討論頁。「互助客棧」等於「自己的討論頁」嗎？您的理據不對。 --SuperGrey (留言) 2026年2月10日 (二) 03:49 (UTC)

emoji是留言的一種，請問這在方針指引的哪裡？我要去推動方針修訂嘛、誒這應該是小工具推動者要想到的配套措施的吧？--提斯切里（留言） 2026年2月10日 (二) 03:50 (UTC)

那怎麼會覺得，任何一位使用者對任一其他使用者留下emoji，就不是修改他人的留言呢？--提斯切里（留言） 2026年2月10日 (二) 03:52 (UTC)

我認為我的留言被他人修改了，不被允許移除，這太奇怪了吧？--提斯切里（留言） 2026年2月10日 (二) 03:53 (UTC)

可是在他人留言（含簽名）的後面添加{{Reaction}}，並不屬於留言被他人修改啊？您的理據是？ --SuperGrey (留言) 2026年2月10日 (二) 03:56 (UTC)

……這麼說好了，如果我開啟編輯，在你的留言背後（「2026年2月10日 (二) 03:56 (UTC)」）寫了「好」、「讚」、或「爛」甚至「🤣」後，寫了四個波浪號送出的話，這個行為是「修改他人留言」嗎？你可能認為不是，但確實有不少人認為是。一般的回覆是，在下面多開一行，不是嗎？你似乎認為，這是把回覆放到同一行，所以沒什麼區別？ --Saimmx（留言） 2026年2月10日 (二) 04:33 (UTC)

您說的對，所以我也認同WP:TPG可以修訂。
不過我想到一個主意：您可以援引WP:TPG#別人的意見，將他人的{{Reaction}}改成換一行的完整留言，這算是指引範圍內允許的做法？（個人觀點和解讀） --SuperGrey (留言) 2026年2月10日 (二) 04:37 (UTC)

或許可以，當成「格式錯誤」、「維護正常運作」、甚至「明顯不文明」的話。某種程度來說，{{Reaction}}確實有那麼些，與「避免過多的文字特效」衝突的地方。所以才能引起這麼強烈的情緒？--Saimmx（留言） 2026年2月10日 (二) 04:43 (UTC)

確實可以，見這條留言；雖然我個人覺得「幫忙改成換一行的留言」穩妥一點。
至於{{Reaction}}，我覺得問題的關鍵在於emoji而非模板設計，畢竟你維一點也不缺華麗的討論模板。部分emoji具有一定歧義，有些emoji還帶有點攻擊力。不過目前你維確實也沒有禁止在留言中加入emoji。
總而言之，還是「格式錯誤」比較通用；而對於「明顯不文明」的{{Reaction}}，當然直接援引「明顯不文明」即可。 --SuperGrey (留言) 2026年2月10日 (二) 05:08 (UTC)

目前WP:TPG未有對「何為留言」做出定義，但從當前表述上看，任何文本的添加，即使沒有時間戳或簽名，也屬於WP:TPG管理的範疇（WP:TPG推薦對此留言補充{{Unsigned}}）。故目前「{{Reaction}}屬於留言」的判斷是符合常理的。 --SuperGrey (留言) 2026年2月10日 (二) 03:55 (UTC)

所以望文生義？這是不是WP:GAME了，指引沒有明確定義，不應自行推測為是。--提斯切里（留言） 2026年2月10日 (二) 04:20 (UTC)

我的留言只是表達我的觀點。您直接搬出來WP:GAME是否是惡意推定？ --SuperGrey (留言) 2026年2月10日 (二) 04:23 (UTC)

過度解釋方針指引沒有的內容有可能會GAME，我也只是疑問。--提斯切里（留言） 2026年2月10日 (二) 05:51 (UTC)

在另外立法前，由此小工具進行的「反應」可以視為留言的一種，故也受到討論的規則限制。
您如果感興趣，可以另外推動立法。但我不太覺得「將『反應』刪除的權利」在法理上有說服力。 --SuperGrey (留言) 2026年2月10日 (二) 03:45 (UTC)

您要是希望他人對留下的emoji做出解釋，可以ping對方。「不想回答就不要丟emoji，回答了emoji更加沒用處，多此一舉」是您個人的看法，並非社群的看法。既然Reaction已有一定的社群基礎，且也有提供關閉與隱藏Reaction功能的選項，既沒有強迫您使用、也沒有強迫您去看，您不必如此應激。 --SuperGrey (留言) 2026年2月10日 (二) 02:59 (UTC)

另外，我對您的部分無據指控和謬誤進行了反駁，請見Wikipedia:互助客栈/技术#c-SuperGrey-20260210030800-Iflwlou-20260210001200。 --SuperGrey (留言) 2026年2月10日 (二) 03:21 (UTC)

將此討論與徵求意見討論串合併。請您遵守WP:CON/RULES方針。 --SuperGrey (留言) 2026年2月10日 (二) 03:15 (UTC)

「無據指控和謬誤？」我對此東西的批評不構成WP:CIV，因為我的立論就是此東西（我不知怎形容此東西）對維基有害，我可沒有針對任何人。

1. 所謂公示，不過是在互助客栈/技术的小天地的討論，然後就預期所有維基人留意（另一個維基弊病），我是剛好見到討論中出現奇奇怪怪的emoji，所以才問一問，越想就覺越有問題。
2. 我指的「責任」是「說明理由或承擔解釋的責任」而不是丟個emoji「向留言表達（意義不明）的態度」。
3. 小工具裝載後，便可以在小工具內找到停用和隱藏的選項。，那就是「預設安裝」，我不只是預設關閉，而是預設拒絕，沒有我同意,不得在我留言留下這東西，而非「眼不見為淨」。
4. 這種emoji表態沒有意義，一個沒有意義的東西沒有資格得到留言一樣的保障。--Iflwlou ☯I♨I☀ 2026年2月10日 (二) 03:24 (UTC)

1. 您是否關注過公告{{Bulletin}}？此徵求意見可是在上面待了將近一個月。
2. WP:COMPULSORY：維基百科不強迫任何使用者做任何事，這包括「對自己的留言做出解釋或說明理由」。
3. 沒有我同意,不得在我留言留下這東西才是您的核心觀點吧？您不能阻止任何人給您留言，但您可以申請互動禁制，讓管理員來幫您阻止。
4. 這種emoji表態沒有意義，一個沒有意義的東西沒有資格得到留言一樣的保障⸺我尊重您的個人觀點，但是移除他人留言違反方針。而{{Reaction}}與「僅由emoji組成的留言」，在實質上是相同的，都包含留言文本+使用者簽名+時間戳，故地位也應當相同。

--SuperGrey (留言) 2026年2月10日 (二) 03:33 (UTC)

1. 既沒有強迫您使用、也沒有強迫您去看？你現在是「預設安裝」，不能拒絕，我只能眼不見為淨啊。
2. 留下的emoji做出解釋，可以ping對方。那emoji有什麼用呢，又不能彰顯意思，又要再ping對方，這不是「多此一舉」是什麼，要參與討論，只得留言。
3. 您不必如此應激，人身攻擊我不代表你有理的。--Iflwlou ☯I♨I☀ 2026年2月10日 (二) 03:33 (UTC)

1. 當您點擊「隱藏全部」後，即可「眼不見為淨」了。
2. 您需要尊重他人的留言，即使他人的留言僅有emoji。這是WP:CIV。
3. 您是否應激，可以從先後連續違反WP:CIV、WP:CON/RULES看出，我不過是指出並善意提醒您。

--SuperGrey (留言) 2026年2月10日 (二) 03:36 (UTC)

1. 「拒絕」和「眼不見為淨」兩個概念,不要混為一談。
2. 「emoji」不是「留言」，不要混為一談，我已經說得很清楚。
3. 即使他人的留言僅有emoji，與討論無關的留言都會被刪除，何況emoji。
4. 先後連續違反WP:CIV、WP:CON/RULES，又加罪名，依上方其他用戶的留言，很明顯emoji不是共識啊。我想拒絕安裝也拒絕被emoji是無從選擇的--提斯切里
5. 方針可沒有寫是同一東西，這是你個人觀點，我尊重你的個人觀點，但我不同意。
6. 我不能阻止任何人給我留言，我也沒有意願阻止任何人給我留言，但不是留言的東西，我堅決拒絕，而且不單止我，我相信其他人也會這樣子做。不緊要，發生了就是討論這方針中「留言」定義的時候。
7. 最後，這東西對維基有什麼必要性?--Iflwlou ☯I♨I☀ 2026年2月10日 (二) 04:02 (UTC)

1. 「emoji」不是「留言」，不要混為一談，我已經說得很清楚⸺您又把自己的觀點當作事實了。請您分清「觀點」和「事實」後再繼續討論。另請參看此留言。至於我對方針的解讀是否合理，我亦沒有將我的解讀當作事實，故您的觀點和我的觀點是對等的。您可以提議修訂方針，明確「什麼是留言」，以合理的方式解決此分歧。
2. 很明顯emoji不是共識啊⸺請您參見WP:共識：共識不強求一致同意。我尊重您的合理意見，也請您尊重支持或使用Reaction小工具的其他人。

--SuperGrey (留言) 2026年2月10日 (二) 04:08 (UTC)

1. 目前WP:TPG未有對「何為留言」做出定義，你第一句倒說清楚。
2. 也請您尊重拒絕Reaction這東西的用戶，而你就是令我無從選擇。
3. 最後，這東西對維基有什麼必要性?--Iflwlou ☯I♨I☀ 2026年2月10日 (二) 04:15 (UTC)

我在某人的留言下放一个👍和令开一行写“支持”加四个波浪号有什么区别吗？前者还省空间。留言也有可能会有骂人、讽刺等，已经有现有的制度去处理这些问题，emoji本身并无问题。--糯米花🌾🌼 2026年2月10日 (二) 05:43 (UTC)

這不能視為表達明確意見或是共識的推動，除非方針指引明確寫出可以，那麼變成要界定哪些符號是同意，哪些符號是反對，哪些符號是中立。--提斯切里（留言） 2026年2月10日 (二) 05:54 (UTC)

正好适用于“我大体同意但又不完全想支持”的场景，换句话说，不那么正式的支持。--糯米花🌾🌼 2026年2月10日 (二) 09:06 (UTC)

「我在某人的留言下放一个👍和令开一行写“支持”加四个波浪号有什么区别吗？」

有的：這個技術上很像是「我開啟編輯，在你的留言（「"糯米花🌾🌼 2026年2月10日 (二) 05:43 (UTC)"」）背後寫了「好」、「讚」、或「爛」甚至「🤣」後，寫了四個波浪號送出」這樣的動作。在Reaction以前不會有人這樣作，作了大概也會被認為是修改意見。但現在難說。--Saimmx（留言） 2026年2月10日 (二) 06:17 (UTC)

你就是令我無從選擇並非事實。我只是援引方針和指引與您交流罷了。
我發現了我們爭論的問題之所在。您似乎誤解了Reaction小工具與{{Reaction}}的關係。即使沒有裝載Reaction小工具，您亦能看到{{Reaction}}。而正是裝載Reaction小工具後，您才能決定是否隱藏{{Reaction}}。故「Reaction小工具是否預裝載」與「{{Reaction}}如何使用、如何拒絕」是兩回事。
您不要上價值判斷。{{Reaction}}有助於以簡短的方式表達對某個留言的態度，故對於一些使用者有其實用性。沒有什麼東西是必要的，包括任何人是否要參與維基百科，故討論必要性實屬無理。 --SuperGrey (留言) 2026年2月10日 (二) 04:21 (UTC)

我是「拒絕」，不論是{{Reaction}}還是Reaction小工具，某圈子喜歡用emoji是他們的事，我不在意，但我拒絕被使用，我有這權利。

基本上在留言加emoji，刪emoji都是討論區舉手之勞的事，按發佈變更即可，還要裝載Reaction小工具？還要裝載Reaction小工具後才能決定是否隱藏{{Reaction}}，你這叫實用性？我尊重你的努力，但這比起「按發佈變更」，多此一舉。--Iflwlou ☯I♨I☀ 2026年2月10日 (二) 04:35 (UTC)

我剛剛想到一個有趣的主意：Wikipedia:互助客栈/技术#c-SuperGrey-20260210043700-Saimmx-20260210043300。
您可以以「協助他人排版留言」為理由，把別人的{{Reaction}}改成完整留言？如果您把{{Reaction}}看作排版錯誤，然後對其進行「修正」，這似乎不算違反WP:TPG（畢竟確實沒規定）？當然我這個主意也屬於我的個人觀點和解讀就是了，還是您自行判斷可不可以刪吧。 --SuperGrey (留言) 2026年2月10日 (二) 04:41 (UTC)

話到至此，大家都是各自表述，再討論下去沒有必要，肯定的是，我被使用emoji，我會將之視為非討論內容屏蔽，投訴，儘管，我相信那時的討論會對令「留言」會有更清晰的定義。--Iflwlou ☯I♨I☀ 2026年2月10日 (二) 04:46 (UTC)

我想至少您把不文明的emoji移除是不太會有阻力的。至於其他情況，我覺得「幫忙改成換一行的留言」穩妥一點，不容易引起爭議，但您如果是按照WP:TPG規則內允許的做法去做，我想應該問題都不大。 --SuperGrey (留言) 2026年2月10日 (二) 04:59 (UTC)

實裝小結

容我對Reaction小工具實裝後的現狀做個小結，以方便後來者參照：

一、{{Reaction}}性質為何？符合哪個方針？是否可以拒絕/移除他人對自己留言的{{Reaction}}？

這算我的個人觀點：目前WP:TPG未有對「何為留言」做出定義，但從當前表述上看，任何文本的添加，即使沒有時間戳或簽名，也屬於WP:TPG管理的範疇（WP:TPG推薦對此留言補充{{Unsigned}}）；WP:INDENT雖「建議」使用縮排符號，但並未禁止在他人留言後，以不換行的形式添加留言。

歡迎大家對「{{Reaction}}是否為留言」進行討論，以及，如果大家覺得有需要，我對修訂此指引表示歡迎。

二、Reaction小工具與{{Reaction}}的關係

Reaction小工具用於控制{{Reaction}}的顯示、添加和移除。故即便是希望完全隱藏所有{{Reaction}}的使用者，也需要裝載Reaction小工具，以隱藏{{Reaction}}。

目前Reaction小工具的預裝版本，預設「不啟用」添加或移除{{Reaction}}功能。使用者須手動在「外觀」菜單中「開啟」，也須手動在「外觀」菜單中「隱藏全部」；小工具有專門設計介面引導，以幫助使用者找到「外觀」菜單。

三、「通過實裝決議2天後的爭議」小結

Reaction小工具並非{{Reaction}}。關於{{Reaction}}的爭議並不直接影響Reaction小工具的實裝；相反，只有Reaction小工具實裝，才能滿足徵求意見過程中各討論者提出的意見，包括「隱藏全部{{Reaction}}」、「在行動版視圖中顯示簽名和時間戳」等。 --SuperGrey (留言) 2026年2月10日 (二) 04:32 (UTC)

1. 作為機械人操作者，對用户反應幾耐的實踐方式極度不滿。我不反對有關概念，但直接在Wikitext留言後留下反應本非MediaWiki系統設計。預設認知應是簽名置於留言的最後，在留言簽名的後方再另外添加Wikitext迫使機械人操作者增加非必要的排除檢查，對於站內所有代碼的穩定性亦有影響。
2. 強烈抗議必須手動安裝完整的反應小工具才可隱藏。安裝小工具影響頁面載入時間，即使只是毫秒計亦是負面影響。應提供最小化小工具只用作隱藏反應，而不會添加任何其他界面，將隱藏不想見到的內容這個個人選擇的用户體驗代價最小化。

--路西法人 2026年2月10日 (二) 08:21 (UTC)

黑名單功能正在開發中，會把黑名單做成完全不須安裝也能手動添加。另外，添加反應等核心功能將剝離出來為單獨的JS，異步加載，而主JS只有「外觀設定」邏輯，只有在設定為未隱藏時才載入核心功能，這樣如何？ --SuperGrey (留言) 2026年2月10日 (二) 08:26 (UTC)

建立Special:MyPage/Reaction-config.js，內容如下，即可將自己加入黑名單，今後任何人通過小工具將不可對自己添加反應表情：

ujsReactionConfig = {
	blacklist: true
};

以上原始碼是提供給非小工具使用者的，免安裝；若安裝了小工具，可通過直觀的圖形介面便捷地修訂此配置。副知@Iflwlou。 --SuperGrey (留言) 2026年2月10日 (二) 09:28 (UTC)

不太明白怎用😅要建立一個頁面？免安裝的意思是🤔️--提斯切里（留言） 2026年2月10日 (二) 11:15 (UTC)

意思是您即使在不安裝小工具的情況下亦可將自己加入黑名單。他人使用小工具對您進行「反應」時，小工具會讀取您的Special:MyPage/Reaction-config.js，如果存在此頁面且內容如上，則對方的「反應」將無法發出，並收到此使用者禁止他人對其做出「反應」的提示。 --SuperGrey (留言) 2026年2月10日 (二) 11:19 (UTC)

您如果還是不太明白怎麼用，那就還是安裝小工具吧。我剛剛對小工具功能進行了拆分，安裝外圍「加載器」（22KB）後即可通過圖形介面配置是否隱藏、是否加入黑名單；而只有「不隱藏」的情況下，核心功能才會加載（1.7MB）。現在「加載器」已經相當小，應該可以接受其預裝了吧？ --SuperGrey (留言) 2026年2月10日 (二) 11:25 (UTC)

感謝您。我已經好了。--Saimmx（留言） 2026年2月10日 (二) 11:51 (UTC)

核心功能已拆分。現在Gadget-Reaction.js只剩下22KB的空殼，用於提供隱藏和黑名單功能；如果不隱藏，才會另外載入Gadget-Reaction-feature.js。Ping @LuciferianThomas。SuperGrey (留言) 2026年2月10日 (二) 11:15 (UTC)

不滿歸不滿，{{Reaction}}在中維已存在超過1年，活躍的機械人操作者理應都已注意到其存在。影響已經造成，而真正受其影響的站內代碼也應已有做排查？如果還有重要代碼受影響而未做更動，我可以幫忙修改，但這確實是機械人操作者的職責，故十分理解您的不滿。 --SuperGrey (留言) 2026年2月10日 (二) 08:43 (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)

@Cscott: I've created mw:User:Diskdance/Overview_of_LanguageConverter with the hope of it becoming an overview document of LC which is currently absent in MW.org. It is partially based on Help:AC but tailored a lot to be more understandable by non-Chinese readers. Could you please check if there are anything hard to understand, erroneous or missing in it? Thanks.--碟之舞📀💿 2026年2月1日 (日) 13:58 (UTC)

It's better to distinguish between the conversion rules of characters and words. I created mw:User:魔琴/Chinese conversion as a supplement to your essay. ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年2月3日 (二) 08:23 (UTC)

@魔琴：character是单个汉字，word是单个词语，他们的转换规则我在Background部分已经分开叙述了，是否还有不够详尽的地方？--碟之舞📀💿 2026年2月3日 (二) 08:43 (UTC)

我看到Ideal conversion framework#1了，但就是改之前的小標題可能引發誤解。現在沒有問題。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年2月3日 (二) 08:50 (UTC)

提議公開過濾器39

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

支持，不可信来源的列表是公开的。 Stang¹⁰⁹⁸ 2026年1月19日 (一) 02:25 (UTC)

(＋)支持，未见隐藏之必要。--浅村しき（留言・签名） 2026年1月27日 (二) 14:16 (UTC)

看起来没人反对？咱先 公示3天，或者请其他管理员/过滤器编辑者在他们认为可以直接实施更改的情况下公开过滤器。cc@Ghren@Stang@ShuQizhe。Exusiai（留言） 2026年1月28日 (三) 09:02 (UTC)

通过，相关过滤器已设置为公开。Exusiai（留言） 2026年1月31日 (六) 08:55 (UTC) 👍1

或許也可以考慮公開92號過濾器。--象象🐘(留言|貢獻) 2026年1月31日 (六) 11:02 (UTC)

@臺灣象象、Exusiai：与39号相同，但不对自动确认用户发出警告，如果要更新请同时更新39号-- Bencmq

那我觉得直接公开应该没问题；不过觉得不太妥当的话再开个讨论也行。--浅村しき（留言・签名） 2026年1月31日 (六) 13:44 (UTC)

忘了这事了，已设置为公开。cc@臺灣象象@ShuQizhe--Exusiai（留言） 2026年2月1日 (日) 09:00 (UTC) 👍2

提議以機器人自動為條目添加Authority control模板

在上方討論中討論參與者似乎有使用機器人自動為條目添加Authority control模板的共識，故提出此提議以進行進一步的討論。--象象🐘(留言|貢獻) 2026年1月30日 (五) 12:41 (UTC)

邀請@Ashlike、Ericliu1912、Shizhao、YFdyh000參與討論。--象象🐘(留言|貢獻) 2026年1月30日 (五) 12:43 (UTC)

说实话我没有实际用到过该模板。我对自动添加没太多意见，但建议对该模板的所在位置（如导航模板顺序）有清晰约定。--YFdyh000（留言） 2026年1月30日 (五) 12:47 (UTC)

根據我的經驗，目前好像都是放在條目最底部（導航模板下面）？--象象🐘(留言|貢獻) 2026年1月30日 (五) 12:49 (UTC)

是的。也许Wikipedia:格式手冊/版面佈局#導航模板可以稍作约定，导言和附录目前有定顺序表。--YFdyh000（留言） 2026年1月30日 (五) 13:11 (UTC)

Wikipedia:格式手冊/版面佈局#附錄這節已經規定把Authority control放在「導航模板」和「地理坐標標示模板」之下，不過我好像沒看過把地理坐標標示模板放這麼下面的。--迴廊彼端（留言） 2026年1月30日 (五) 13:28 (UTC)

感谢提醒，读太快真不行……确实。--YFdyh000（留言） 2026年1月30日 (五) 13:53 (UTC)

實際上地理坐標通常都放在條目頂部。如果有導航模板，規範控制直接貼在下面，這樣就不會有空列。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年1月31日 (六) 07:15 (UTC)

地理坐标模板是建议放在底部，见mw:Recommendations for mobile friendly articles on Wikimedia wikis#Meta data (including coordinates) should be positioned at the bottom of the article，主要出于技术层面的考虑--百無一用是書生 (☎) 2026年1月31日 (六) 11:29 (UTC)

同意。

印象都是在索引跟分類，其他模板之後--死灰（留言） 2026年1月31日 (六) 02:34 (UTC)

-{}-在 Wikipedia:互助客栈/条目探讨 的簡體變體頁面疑似失效了

已在版本91353997解决，由于此处仅为讨论提醒，本框内討論文字已關閉，相關文字不再存檔。

如有異議，請諮詢互助客棧或其他管理員。執行人：Srapoj（留言） 2026年2月1日 (日) 12:18 (UTC)

點此查看。 --~2026-67999-9（留言） 2026年1月31日 (六) 15:22 (UTC)

2026年第6期技術新聞

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

近況更新 - 面向編輯者

• 「页面信息」功能（範例）現在自動包含目次。若您的維基站點有在本地建立MediaWiki:Pageinfo-header頁面，現可將它刪除。 [3]
• 上週有21件由社群提交的工單得到解決。 例如，之前視覺化編輯器會在連結顯示文字內添加粗體或斜體格式，導致wikitext複雜化，現已修正此問題。 [4]

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

• 1月20日沒有生成XML轉儲。即日起，轉儲將改為每月生成一次。 [5]
• MediaWiki介面團隊已停止支援MediaWiki REST API中所有帶有結尾斜線的轉換端點。目前仍呼叫這些端點的API使用者，請盡快轉用不帶結尾斜線的版本。如有疑問或遇到問題，請至Phabricator的#MW-Interfaces-Team面板提交工單。
• 本週軟體更新細節： MediaWiki

本週要聞

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

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

MediaWiki message delivery 2026年2月2日 (一) 17:40 (UTC)

“自動包含目次”是啥啊？没看到有何不同啊？--百無一用是書生 (☎) 2026年2月3日 (二) 03:06 (UTC)

@Shizhao：是不是指資訊頁最頂端的目次？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年2月3日 (二) 08:21 (UTC)

难道是说的那个目录吗？--百無一用是書生 (☎) 2026年2月4日 (三) 02:57 (UTC)

Template_talk:Talk_header#回報問題：存檔只能存為簡體格式的相關討論

诚邀阁下参与Template_talk:Talk_header#回報問題：存檔只能存為簡體格式的相關討論。--Saimmx（留言） 2026年2月4日 (三) 07:51 (UTC)

Search怎么了

网页默认的搜索框坏掉了，例如按照简体输入“WP:用户框”或按照重定向“WP:VP”都会导向条目命名空间的结果。由于导致特定命名空间的搜索不方便（尤其Wikipedia空间和Template空间），故请求改回原来的样子。--${\mathfrak {Kurwa}}$__^{( •̀ ω •́ )＜✧} 2026年2月8日 (日) 03:56 (UTC)

是啊，我也遇上了这个问题，相当不方便。

不过我去其他站点搜的时候发现也是这个问题，可能这个问题是全域性的？--浅村しき（留言・签名） 2026年2月8日 (日) 06:29 (UTC)

未重现，已经好了？--YFdyh000（留言） 2026年2月8日 (日) 19:13 (UTC)

好像这几天都这样。比如我要用逐字词输入的形式进入“中国国旗”条目，下面的候选项就变成“国旗”开头的条目。--Shwangtianyuan 让中国再次伟大 2026年2月9日 (一) 15:01 (UTC)

现在似乎是 已解决了。--${\mathfrak {Kurwa}}$__^{( •̀ ω •́ )＜✧} 2026年2月10日 (二) 03:45 (UTC)

我这边还是不行。刚试了，拆词依次输入“中国”、“共产党”，本来排第一的搜索建议是中国共产党，但跳出来的建议变成了共产党。--Shwangtianyuan 让中国再次伟大 2026年2月10日 (二) 06:55 (UTC)

我发现是Wikipedia命名空间修复了，但是WikiProject命名空间还是坏的。--${\mathfrak {Kurwa}}$__^{( •̀ ω •́ )＜✧} 2026年2月10日 (二) 10:20 (UTC)

好吧还是没有修复……只有搜索重定向和繁简被修复了……--${\mathfrak {Kurwa}}$__^{( •̀ ω •́ )＜✧} 2026年2月10日 (二) 10:54 (UTC)

使用特定模板之外部連結吃封鎖網域通知的問題

我在NET (品牌)裡看到Infobox和§外部連結的官方網站看到網址有(部分)防繁簡轉換的標籤，想說用{{Official}}或{{Official URL}}給替換掉，結果系統彈出了封鎖網域的通知。
雖然前者可以手動改連結URL，不方便豁免；但是只使用在Infobox、且URL資料來自於Wikidata的{{Official URL}}之外部連結可以豁免封鎖網域的限制嗎?--竹林＝月光 2026年2月9日 (一) 10:01 (UTC)

{{Infobox PRC legislation}}的修訂相關參數不顯示

{{Infobox PRC legislation}}的修訂參數不顯示。如中华人民共和国治安管理处罚法條目中，寫了“最新修订日期”和“修订次数”這兩個參數，但信息框中沒有顯示。——三猎（留言） 2026年2月9日 (一) 14:58 (UTC)

{{Infobox legislation}}中“最新修訂日期”“修訂次数”只有繁体参数名，已加入简体。--Kcx36（留言） 2026年2月9日 (一) 17:19 (UTC)

2026年第7期技術新聞

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

近況更新 - 面向編輯者

• 監視清單中存有大量頁面的編輯者現可用新功能「監視清單標籤」^※來整理與篩選監視清單，幫助優化工作流程。透過新增自訂標籤（如：自己建立的頁面、需監控破壞行為的頁面、討論頁），使用者能更快速辨識需關注的編輯，降低認知負荷，並更有效率地應對。此功能讓監視清單更容易使用，對活躍編輯者尤為助益。（※＝Watchlist labels，勿與編輯標籤「tag」混淆）
• Special:Contributions推出新功能，可顯示很可能由同一人操作的臨時帳號，從而減少巡查耗時。當查核臨時帳號的貢獻時，具有臨時帳號IP位址存取權限的使用者，現在能查看其他相關臨時帳號的貢獻。此功能會在資料保留期間內，查詢與特定臨時帳號關聯的所有IP位址，並顯示曾使用這些IP位址的所有臨時帳號的貢獻紀錄。了解更多。 [6]
• 預覽wikitext編輯時，頂部顯示的提醒框（「這只是預覽……」）背景色已由警告黃底改為中性灰底。此變更有助於區分預覽提示與實際警告訊息（如編輯衝突或重定向目標錯誤），後者現改以獨立的警告框或錯誤框呈現。 [7]
• 全域監視清單讓使用者能夠在一個頁面檢視多個維基站點的監視清單。此擴充功能目前正持續改進，現已完整支援多個Wikibase站點，例如同時涵蓋維基數據與測試版維基數據。此外，已修正右至左（RTL）文字顯示問題。 [8][9]
• 因缺乏彈性且難以本地化，wikitext中為ISBN、RFC、PMID編號自動生成連結的「魔術連結」功能已於2021年棄用。RFC與PMID魔術連結能以等效外部連結取代（部分維基站點已完成替換），但ISBN魔術連結通常需要模板才能完成替換。現已推出內建解析器函數{{#isbn}}，可取代ISBN魔術連結的基本功能，方便完成替換作業。 [10]
• 已新建兩個維基：
  • 卡捷語维基百科 (w:kaj:) [11]
  • Nawat語维基百科 (w:ppl:) [12]
• 上週有23件由社群提交的工單得到解決。

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

• 新增了一個全域使用者群組：Local bots。此群組將由軟體內部使用，允許社群機器人繞過針對惡意網頁抓取工具所施加的速率限制。凡在至少一個維基媒體站點獲准為機器人的帳號，將自動加入此群組。此舉不會改變機器人原有的使用者權限。 [13]
• 本週軟體更新細節： MediaWiki

會議與活動

• 2026年春季MediaWiki使用者與開發者大會將於3月25日至27日在美國鹽湖城舉行。本活動由第三方MediaWiki社群主辦，並面向該社群。您可以提出議程並報名參加。 [14]

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

MediaWiki message delivery 2026年2月9日 (一) 23:27 (UTC) 👏1

iOS无法登陆

我是IP豁免者,但是我无法登入iOS版本的维基百科,总是显示登录错误，在以往的登录中，我还无法进行编辑，现在直接无法登录--Babala745（留言） 2026年2月10日 (二) 11:50 (UTC)