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

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

发表新议题

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

公告欄

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

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

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	提議：高亮哈佛参考文献格式短鏈指向的完整資料引用	56	9	Ericliu1912	2026-01-21 07:42
2	改善字体的讨论怎麼又死了	14	7	Diskdance	2026-01-27 11:44
3	中文字元與拉丁字母、數字之間在顯示上被自動加入空格	26	11	Srapoj	2026-02-10 21:00
4	徵求意見：Reaction 小工具加入 MediaWiki:Gadgets-definition	231	15	Sksawf	2026-02-13 21:34
5	Request for Translation of LanguageConverter documentation	20	6	Diskdance	2026-02-11 18:03
6	Search怎么了	11	6	Srapoj	2026-02-12 23:15
7	使用特定模板之外部連結吃封鎖網域通知的問題	2	2	Srapoj	2026-02-11 22:39
8	{{Infobox PRC legislation}}的修訂相關參數不顯示	3	2	三猎	2026-02-14 16:02
9	2026年第7期技術新聞	1	1	MediaWiki message delivery	2026-02-10 07:27
10	iOS无法登陆	2	2	SCP-2000	2026-02-10 20:06
11	提議{{current}}模板不得合併至{{multiple issues}}模板？	6	5	Srapoj	2026-02-11 14:10
12	第一階段：行動版目錄實驗	1	1	EBlackorby-WMF	2026-02-12 01:47
13	{{cite journal}}模板publication_date以及year参数同时存在时，page参数填写的页码会与publication_date的日期黏连	2	2	1F616EMO	2026-02-13 07:46
14	Series overview模板的Lint錯誤「night-mode-unaware-background-color」要怎麼修正？	4	3	Dabao qian	2026-02-14 01:47

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

正在廣泛徵求意見的議題

議題清單

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

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)

Wikipedia:防滥用过滤器/过滤器请求 § 提議批量修改過濾器批配規則

提議將過所有過濾器中的"autoconfirmed" in user_groups和"confirmed" in user_groups改為"autoconfirmed" in user_rights，以避免阻止可信全域使用者（例如：全域回退員、監管員、基金會員工）的編輯。--象象🐘(留言|貢獻) 2026年2月14日 (六) 10:34 (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)

@Dabao qian：上面提到的代碼要加在哪一列？是否需要註釋？—— Eric Liu _{創造は生命（留言・留名・學生會）}

副知@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)

看到有w3c/csswg-drafts#9479。--Srapoj（留言） 2026年2月10日 (二) 13:00 (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 🔥3 (＋)支持1

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

感謝反饋！

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

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

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

存檔頁已經隱藏了反應功能，不過部分地方還有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) 😱2

之前有遇過使用者在存檔的討論裡補讚，暫時沒找到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)

我認為還是有疑慮未解決，開放者認為這是留言的一部分，但是配套的方針指引卻沒有同步考慮，既然這個小工具被開發者解讀為視同留言，但居然是可以允許任何使用者對他人留言加上emoji，卻不允許被加的使用者移除他不想要的emoji；其次，若是出現不適切的emoji，該如何處理？不適切的留言可被屏蔽，那emoji呢？還有看似這小工具是只要注冊帳號就可使用，那麼使用時是否算進編輯記錄？請考量配套的方針指引如何運作，若是出現爭議行為提報到ANM會否造成管理員判斷不易。--提斯切里（留言） 2026年2月10日 (二) 13:47 (UTC)

1. 現在已經有黑名單功能了，就不要再提「移除他不想要的emoji」了。我覺得要就要、不要就不要，只接受讚美不接受批評可不行。
2. 「使用時是否算進編輯記錄」⸺您用過一次就知道了，編輯記錄中當然有。
3. 「不適切的emoji該如何處理/配套的方針指引如何運作」⸺本質上是「{{Reaction}}是不是留言」的問題，既然我的個人解讀讓您產生了WP:GAME的疑問，那我就不解讀了，您自己判斷「{{Reaction}}是不是留言」。分類討論一下：
   • 如果是，那麼您可以徑自按照討論頁指引去移除「不適切的emoji」；管理員也不會「判斷不易」，按照留言的處理方法，該怎麼辦怎麼辦。
   • 如果您要讓他不是，那您就援引討論頁指引，對其「修正排版」改成普通留言，然後再送進去ANM，其實也是一樣的。

--SuperGrey (留言) 2026年2月10日 (二) 14:00 (UTC)

我的重點從來不是只接受讚揚而不接受批評，即使您立刻寫出個反向小工具，在我看來只是合理化地允許被人拍肩罷了，您解釋為這是留言的一部分，為甚麼會認為可以單向給人emoji而不同意自由移除？還有emoji的數量和範圍是？遇到不當使用emoji小工具的使用者該如何應對？外部社群網站僅只有限制幾個emoji能使用，考量的也是網路霸凌的一部分，因為我沒有安裝所以不清楚，貴維的小工具是所有的emoji自由使用？關於新注冊帳號部分，注冊馬上就能使用，那是否有短時間衝高編輯數疑慮，遇到這樣的使用者該不該提報還是假定善意他是來交朋友aka論壇？--提斯切里（留言） 2026年2月10日 (二) 14:32 (UTC)

您解釋為這是留言的一部分，為甚麼會認為可以單向給人emoji而不同意自由移除⸺恕我沒理解您想表達的含義是？您前面提「這是留言的一部分」，然後緊接著問出「可以單向給人emoji而不同意自由移除」，難道留言就可以自由移除嗎？沒看懂。 --SuperGrey (留言) 2026年2月10日 (二) 14:57 (UTC)

對於emoji濫用、霸凌、短時間衝高編輯數等行為，您可以用常理判斷，不必拘泥於規定。畢竟人心向背太複雜，你維討論頁指引如此簡短和籠統，我猜也是因為根本沒法給出明確規定吧？按照您的理解去推斷和提報就好。 --SuperGrey (留言) 2026年2月10日 (二) 15:00 (UTC)

您把這小工具認為是留言，是留言的一部分是您認定的，您說出來我也很驚訝，「別人給我emoji變成我的留言的一部分，這是怎麼回事？」我只想知道，寫進方針指引了沒？您設計這個小工具的用意，是可以給他人留言emoji，等於給該留言賦予意思，可以說是給人emoji的使用者先修改了他人的留言，卻斷言被emoji的使用者（請注意這裡是指都有使用該小工具的使用者）不能移除他不想要的emoji，這樣是強制一方通行。我強烈建議開發者請先提出使用方針草案，我不認同emoji直接套用討論頁指引。此外您也不想考慮有衝高編輯數疑慮的新使用者是否會被提報的疑慮，另外若不規範，沒有任何方針指引說不能移除，我一直到您說了才「咦不能移？」，好吧那還是回到頭，寫在哪個方針指引裡？不知道的使用者若出現了emoji的編輯戰（但是在我看來他們沒有錯），請問是要提報使用者互動禁制還是有立刻緊急停用的機制？--提斯切里（留言） 2026年2月10日 (二) 17:23 (UTC)

这不是在他人讨论页对其的个人留言，而是对公开讨论的追加留言，所以视同他人回复，不能由被追加者直接移除。这种追加留言是无留言内容的，节省版面所以直接在被追加留言的后方、默认缩起名字和时间。这类似于现有的将其他人的留言块标记折叠，或者如早期存废讨论曾会标记此留言者权限不满足要求，但意见仍可参考。--YFdyh000（留言） 2026年2月10日 (二) 19:23 (UTC) 👍2

編輯戰還能看起來沒有錯？您的邏輯太混亂了。該提報的提報就好，不必想得這麼複雜。
您已經先入為主把他人在您的留言後面貼的emoji當成自己留言的一部分，然後再拋出「他人修改了自己的留言」的結論和「為什麼不讓刪」的疑惑，但您有沒有想過，那不一定是自己留言的一部分，他人也並未修改您的留言？您如果堅持己見，認定「自己的留言」範圍必須佔據一整行、不容他人在後面貼表情，就趕緊把自己加入小工具黑名單吧，眼不見為淨。 --SuperGrey (留言) 2026年2月11日 (三) 00:05 (UTC)

假定善意，因為沒有方針指引確認，拒絕安裝和使用這項小工具的使用者，可以自由移除他的留言後方出現的任何不想要的emoji，不會違反任何方針指引，同樣的emoji編輯戰也沒問題，新使用者可以合理化衝編輯數，都是因為眼不見為淨。--提斯切里（留言） 2026年2月11日 (三) 00:41 (UTC)

您既然這麼有善心，他人做法怎樣都合理、怎樣都自由，那我還能說什麼呢？那就合理吧。反正我比您心眼小，要是看到了emoji編輯戰，是會提報到ANM的。 --SuperGrey (留言) 2026年2月11日 (三) 01:04 (UTC)

這是要提醒您，沒有任何方針指引可以規範，請認真考慮配套措施，不要發生事情了才想方設法，結果您都在順我的話？您的小工具都在左手打右手，可以預設不啟用，又讓人眼不見為淨，編輯戰只有啟用的人看得到，衝編輯數的問題您不考量，LTA非常需要這項功能幫助避開關注，因為達到自動確認用戶門檻的時候不會有人發現。--提斯切里（留言） 2026年2月11日 (三) 01:16 (UTC)

我已經說了我會把emoji編輯戰提報到ANM；如果有人用它來刷編輯數也一樣。「左手打右手」是因為您不認同「{{Reaction}}是留言」；換個思路就能考慮得比較清楚了。 --SuperGrey (留言) 2026年2月11日 (三) 01:19 (UTC)

跑題一下，reaction工具如何啓用？我沒在偏好設定中找到，不知道爲什麼之前的common.js也失效了。--糯米花🌾🌼 2026年2月11日 (三) 04:24 (UTC) 👍1

看看WP:REACTION的教程。 --SuperGrey (留言) 2026年2月11日 (三) 06:15 (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)

感谢对其他人几乎不可见，即便有感谢日志，看不出感谢了哪笔。感谢记录不太好重新查阅。所以这是个公开表态，其他人再有疑问或相关话题时应追问、邀请讨论。--YFdyh000（留言） 2026年2月10日 (二) 19:30 (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: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)

你就是令我無從選擇並非事實。我只是援引方針和指引與您交流罷了。
我發現了我們爭論的問題之所在。您似乎誤解了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)

为修正评论顺序，下方留言为对Iflwlou 2026年2月10日 (二) 03:24 (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)

会有，+1模板以前就有人在用，不被视为修改他人意见。Reaction是大幅拓展了能用的表情，某些表情可能偏负面或意味不明。--YFdyh000（留言） 2026年2月10日 (二) 19:37 (UTC)

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

期望是添加动作执行前检测，即点“+反应”之后就检测和尽快提示（如检测完成前停用保存按钮），降低扫兴感。--YFdyh000（留言） 2026年2月10日 (二) 19:42 (UTC)

就是這樣做的。雖然查詢是異步的，但一旦查詢到，在emoji選取器上的提示就會變成此使用者禁止他人對其做出「反應」。 --SuperGrey (留言) 2026年2月11日 (三) 00:08 (UTC)

你把我的程式：User:Saimmx/Reaction-config.js這裡面的程式碼，貼到User:Tisscherry/Reaction-config.js裡面就可以了。至少SuperGrey的意思是這樣。--Saimmx（留言） 2026年2月10日 (二) 14:55 (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)

機械人操作者沒有義務為非MediaWiki系統設計的特別情況作出處理。我的機械人確有處理Reaction模板的相關問題，但你不能期望機械人操作者有義務為社群一年來只有默認而沒有明確納入本地「必然考量」的功能。若未來有全域機械人或網站須通過相類似的方式讀取留言資料，而有關功能的外地操作者不熟悉本地環境而只為系統基本設計作出處理，如何能稱之為「維護義務」？--路西法人 2026年2月11日 (三) 00:42 (UTC)

WP:BOTACC：操作者有責任確保機器人運作正常。⸺當然有義務，這是方針裡寫的。 --SuperGrey (留言) 2026年2月11日 (三) 00:46 (UTC)

基於MediaWiki預設系統，我絕對可以直接説留言日期後被添加其他文字是malformed comment/signature，然後是為garbage in garbage out而排除處理，正確符合MediaWiki規範的簽名自然仍然運作正常，自然符合WP:BOTACC要求。--路西法人 2026年2月11日 (三) 00:49 (UTC)

您都說「基於MediaWiki預設系統」了。設計機械人的時候，是以MediaWiki預設系統為準就好了，還是要按照社群實際使用情況為準？我不太想跟您吵這個，但我相信您也知道BOT必須考慮這些「預設系統以外的情況」。 --SuperGrey (留言) 2026年2月11日 (三) 00:52 (UTC)

機械人沒有義務考慮預設系統以外的情況。機械人操作者「可以」善心處理GIGO問題，但GIGO問題從來沒有必須處理的義務，只要正確排除不炸掉程序就自然不須處理而可算作運作正常。--路西法人 2026年2月11日 (三) 00:55 (UTC)

隨您。反正維基百科還不強迫任何人參與呢。不考慮就不考慮好了，只要別讓機械人造成破壞，確實就可「算作運作正常」。 --SuperGrey (留言) 2026年2月11日 (三) 00:57 (UTC)

再舉個例子。{{移動自}}、{{移動至}}的格式也非MediaWiki預設系統、而是社群自定的格式，BOT要不要考慮這些情況呢？我前一個月才上報給Convenient Discussions作者，希望他能支援中維的{{移動自}}、{{移動至}}格式。 --SuperGrey (留言) 2026年2月11日 (三) 00:55 (UTC)

自然沒有義務考慮。--路西法人 2026年2月11日 (三) 00:59 (UTC)

見此留言。 --SuperGrey (留言) 2026年2月11日 (三) 01:01 (UTC)

若是Reaction模板從來置於新行而不影響讀取，已經可以完全解決此問題，而不需要機械人操作者手動添加特殊偵測，有關問題就能徹底解決。只想着「預設要為你們讓步」，要迫使整個社群改變預設系統假設，可不作出這一簡單改動？--路西法人 2026年2月11日 (三) 00:47 (UTC)

問題是，在{{Reaction}}之前，{{+1}}、{{like}}也曾被使用者這樣使用。由來已久的用法，當然機械人操作者要考慮在內。抱怨歸抱怨，這是機械人操作者的職責。 --SuperGrey (留言) 2026年2月11日 (三) 00:50 (UTC)

同樣是可視為不符合要求的簽名而排除處理，同樣沒有義務考慮在內。--路西法人 2026年2月11日 (三) 00:52 (UTC)

「排除處理」也是一種「考慮」。如果完全不考慮而產生了破壞，那肯定是不行的吧？Anyway，只要有做例外情況處理就OK。 --SuperGrey (留言) 2026年2月11日 (三) 00:59 (UTC)

你不能預期別人必須為你處理你所創造的例外，世界並不圍繞你轉，但絕對圍繞正確的spec轉。我已經提出一個你可以解決不符合正確MediaWiki spec的小工具改變，只是加個line feed和正確indent都不願意接受，何以期望全站各機械人操作者為你強行改變「正常期望」的自私工具額外處理？--路西法人 2026年2月11日 (三) 01:13 (UTC)

我已經提出⸺您不是在這條留言中才提出的嗎？疑惑。 --SuperGrey (留言) 2026年2月11日 (三) 01:17 (UTC)

前面留言已說明這個可改變的方法，若您看到有關意見後即時作出改善，已經直接妥善解決且不需他人再為你一個工具作出例外情況。Instead你選擇了抬槓，偏要他人為你一個工具繞彎走，這說明了你的開發原則和態度。--路西法人 2026年2月11日 (三) 01:22 (UTC)

您可以把我的意見通通打成「抬槓」，這還在討論的範圍內；但當您開始邏輯飛越、指控我的「開發原則和態度」，是否屬於WP:PA？已經不能做到對事不對人了嗎？

若您看到有關意見後即時作出改善，已經直接妥善解決且不需他人再為你一個工具作出例外情況⸺您似乎誤會了修改這一設計的難度。比如說，DiscussionTools和Convenient Discussions首當其衝會受到影響；如果Reaction在下一行，會被軟體判定為是下一條留言的一部分。比如這樣的留言結構：

評論A。
:評論B。{{Reaction|👍|user1=Example|ts1=Timestamp}}
:評論C。

DiscussionTools和Convenient Discussions都可以正常地將Reaction置於該評論的同一位置；而如果換行+縮進：

評論A。
:評論B。
:{{Reaction|👍|user1=Example|ts1=Timestamp}}
:評論C。

則DiscussionTools和Convenient Discussions都會把Reaction視為下一條留言的一部分。修改這一格式之後，要考慮的情況相當繁雜，何談「已經直接妥善解決」？或者如果您有什麼好辦法，煩請賜教？ --SuperGrey (留言) 2026年2月11日 (三) 01:31 (UTC)

添加<div class="mw-notalk">…</div>。--路西法人 2026年2月11日 (三) 01:40 (UTC)

mw-notalk是中維目前預裝的擴展，其他同類不符合MediaWiki基礎留言、簽名樣式的問題，機械人可通過此一個class統一處理所有同類內容。--路西法人 2026年2月11日 (三) 01:43 (UTC)

如果給{{Reaction}}添加mw-notalk，但還是保留在行內，您接受嗎？Module:Reaction#L-266。 --SuperGrey (留言) 2026年2月11日 (三) 01:45 (UTC)

不錯，有了mw-notalk，DiscussionTools可以忽略此內容，不過Convenient Discussions還是識別不了，會把Reaction當作下一條的一部分。 --SuperGrey (留言) 2026年2月11日 (三) 01:43 (UTC)

Convenient Discussions作為用户生成的小工具，其功能已被DiscussionTools大部分覆蓋。你既然都説你的小工具是建基於DT的API，自然只須考慮屬於中文維基百科全面實裝的DT的spec。--路西法人 2026年2月11日 (三) 01:46 (UTC)

小工具的設計，必須考慮coverage和user experience，這才是我的「開發原則和態度」。小工具的開發要不要考慮spec以外的情況，機械人的開發要不要考慮spec以外的情況，對於這兩者我的答案都是「要」。我們可以繼續討論如何找到更好的解決方案，不必在這裡就放棄。 --SuperGrey (留言) 2026年2月11日 (三) 01:51 (UTC)

用户生成工具是插件，並不適用於大多數用户，其相互作用不具任何要求或期望。你要提供額外支援是你的事情，但你沒有權期望或要求所有其他人配合你不符合規格的工具實踐，反而符合規格是你掛在Gadget所需要擔當的責任。--路西法人 2026年2月11日 (三) 01:54 (UTC)

若你要正確實踐全面保證與其他所有系統的互動，且符合其他不希望使用有關工具、甚至不想見到任何反應的用户的期望，整個反應系統根本不應該直接建於wikitext內，而是應該另見database在外部儲存，或在站內其他位置通過JSON等方式儲存。如你自己所認識到一樣，直接在wikitext內添加反應模板會被錯誤視為內容，即反應根本不應該作為內容儲存於wikitext。當開發的前設有誤，只會將小部分用户使用的額外附加自訂功能建基於他人的不便之上。--路西法人 2026年2月11日 (三) 02:01 (UTC)

確實前設有誤，容我思考思考。
以討論頁的子頁另外存儲確實可行，比如Wikipedia:互助客栈/技术/Reactions.json，不過要實裝這個變化，需要給我幾天時間。您覺得這樣的存放和命名方式可以接受嗎？如果可以，我可以開發出來。 --SuperGrey (留言) 2026年2月11日 (三) 02:14 (UTC)

我建議不要綁頁面，因為尤其互助客棧的討論是會存檔的。你的小工具可以搜尋頁面內所有DT所偵測到的留言anchor，並用該anchor作為辨識。資料存於站內就考慮分月、分週或分日建頁（按需求）；讀取時按照DT所偵測到的留言anchor分析要查找哪些資料頁面，最小化載入資料的時間。--路西法人 2026年2月11日 (三) 02:20 (UTC)

確實，這是個好辦法。感謝指點。
DT的anchor最近越來越穩定了、且能跨頁追蹤，確實可以作為參照物。 --SuperGrey (留言) 2026年2月11日 (三) 02:26 (UTC)

如果你有意令你的工具與其他用户生成工具相互正確作用，這可以是你自行研發的問題。現在的問題是你有責任要配合使你通過Gadgets正式向全站用户推廣的小工具正確配合既有（面向所有本地用户）的規格和期望，但僅限於此。--路西法人 2026年2月11日 (三) 01:51 (UTC)

為了讓Reaction儘可能符合已有MediaWiki軟體的運行情況，包括DiscussionTools和Convenient Discussions等很多人在用、影響很大的軟體，必須考慮如何實現此設計。況且為了儘量讓指令碼儘可能的小，Reaction小工具其實基本上使用的是DiscussionTools API；如果DiscussionTools的API失效，這個小工具也運行不了。所以DiscussionTools就是這個小工具的命門，DiscussionTools支援什麼spec，這個小工具就只能使用這樣的spec。 --SuperGrey (留言) 2026年2月11日 (三) 01:41 (UTC)

更甚，昨天的留言已明確指出Reaction模板的做法不符合正常的spec，然而你不是想想如何解決你工具不符合spec的問題，而是硬要吵成為何其他人不為你創造例外，還要我幫你想解決方案，實在不能理解。當然，我昨日留言確實應該明確提供實際改變而不是只指出問題。--路西法人 2026年2月11日 (三) 01:27 (UTC)

整個維基百科中，不符合spec的多了去了。您還說還要我幫你想解決方案，但我確實沒有想到真正可行的解決方案，是我學藝不精，煩請您「技術大牛」賜教。見此留言。 --SuperGrey (留言) 2026年2月11日 (三) 01:35 (UTC)

習非成是都能説成理所當然？--路西法人 2026年2月11日 (三) 01:47 (UTC)

我倒是怀疑所谓spec是否存在——讨论页的留言本就是复用了wikitext列表语法的自由格式wikitext。在DiscussionTools之前，内置关于留言的功能只有签名魔术字而已。不知您指的是否mw:Extension:DiscussionTools/How it works#Parser，但它也算不上spec。--Srapoj（留言） 2026年2月11日 (三) 16:55 (UTC) ❤️1

同Iflwlou意见。解决方案是该工具改成仅在启用工具的用户间相互可用，其他情况一律(－)反对。->>Vocal&Guitar->>_留言 2026年2月11日 (三) 01:50 (UTC)

您似乎誤會了此討論串的主題，就是要不要全站啟用。如果不全站啟用，那麼維持現狀就好了。 --SuperGrey (留言) 2026年2月11日 (三) 01:54 (UTC)

现状是只要启用了该工具就可以对其他任何用户发表情，但我的意思是只能对同样启用这个工具的用户发表情，这么说能解决误会吗？--。->>Vocal&Guitar->>_留言 2026年2月11日 (三) 02:10 (UTC)

做了黑名單功能，不想要接收表情的可以把自己加入黑名單。這樣應該已經實現了您的需求。 --SuperGrey (留言) 2026年2月11日 (三) 02:16 (UTC)

请做白名单而不是黑名单，想玩的人自己去玩，不要对无关的人造成骚扰。--。->>Vocal&Guitar->>_留言 2026年2月11日 (三) 07:36 (UTC)

我好像来晚了，说一下我的想法。

首先，reaction功能毫无疑问是仿照社交网站设计的，该功能最早也出自Facebook，然而我认为最符合本站用例的其实是GitHub。

在GitHub上，reaction的好处非常明显：减少+1等无效留言导致的大量通知。如果本站有类似问题并且需要解决，那引入这个功能就是有用的。

这些无效留言的特征很明显：

1. 除了表达某种态度外，没有任何额外信息；
2. 是谁发的并不重要，重要的是绝对数量。

因此，如果本站要明确reaction的用法，应该像GitHub那样将reaction限制在意义明确的emoji中，比如：

• 👍：赞同、支持、我也遇到这个问题了、投票支持；
• 👎：反对、不同意，但避免直接争吵；
• 🎉：庆祝、大功告成、问题终于修好了；
• 👀：正在关注、维护者表示“已收到，正在排查”、或用户蹲结果。

这样应该就能解决大多数争议，如果还有问题的话其实方针里也可以明确一下。--碟之舞📀💿 2026年2月11日 (三) 10:01 (UTC)

往前追溯的话，Facebook的like button及更早的Digg都使用了这类设计。然而对留言给出反馈的行为就使得这里“变成社交网站”了吗？我只能说我无法把握这个界限——英维有en:WP:NSM与en:WP:ISM两个相反的论述。--Srapoj（留言） 2026年2月11日 (三) 16:55 (UTC)

暫停實裝

雖然徵求意見已經通過了，但我決定暫停實裝。容我花幾天時間按照LuciferianThomas君的建議對小工具進行大幅修改，修訂後會再重新公示。
預計修改後，{{Reaction}}將不會存於頁面內，而是轉移到專門的頁面，亦不再會有「屬不屬於留言」的問題。 --SuperGrey (留言) 2026年2月11日 (三) 02:51 (UTC)

我对DiscussionTools的留言ID的robustness有些担忧。印象中Special:FindComment（含Special:GoToComment）实际在乎的只有留言ID的用户名及时间戳（在本站精确到分钟），后面的部分（上一级用户名、讨论串标题）好像仅用于在页面内供锚点用法来“消歧义”。依赖完整的留言ID难免会受讨论串重构等操作的影响。--Srapoj（留言） 2026年2月11日 (三) 03:17 (UTC)

robustness是不太足，尤其是對於「後面的部分為討論串標題」的那些留言來說。不過不這樣做，這個討論串還能繼續吵到天荒地老，根本沒戲了。 --SuperGrey (留言) 2026年2月11日 (三) 03:23 (UTC)

其實Reaction模板的最大問題在於：MediaWiki系統本身始終不是社交網絡，就算是DT也只是用作輔助編輯者討論而已。若真的大規模推廣這個插件且獲得多人使用，那麼難道40個人react同一個留言，就在討論的wikitext裡放40個param，然後炸25+行wikitext出來嗎？就算只有五個人，每個人加一個不同的reaction也四五行長的wikitext了，對於正常想討論而不使用DiscussionTools的用戶，或者最基本就是頁面長度而言有極大影響，完全是unscalable的設計。這不僅僅是規格的問題，而是如我上面所說，設計理念與前設不相容，使用一個不適合的方式堆疊堆砌危樓是一件非常錯誤的事。目前想到最佳、最小化的方案唯有使用DT的ID，否則就要SuperGrey寫個很複雜的系統去記錄留言了。--路西法人 2026年2月11日 (三) 04:29 (UTC)

如果不嫌事大，甚至可以像英维之前那样按NOTSOCIAL的字面意思提删🙃；但那边让+1和Reaction出现了不同的结果，我估计在本地也只会变成比这里更长的flame war。--Srapoj（留言） 2026年2月11日 (三) 06:23 (UTC)

en:Wikipedia:Village pump (idea lab)/Archive 76#Reactions to comments? - 草，燒得更厲害而且反對聲浪更大。--Saimmx（留言） 2026年2月11日 (三) 13:52 (UTC)

说个可能有些阴谋论的猜测：英文维基百科如果部署Reaction，很可能会被英国和澳大利亚政府彻底认定为“社交媒体”，进而以“保护未成年人”的理由强制所有用户提交实名身份信息--Sksawf（留言） 2026年2月13日 (五) 13:34 (UTC)

若當年Flow有做好且全面推廣，那麼就有了結構完整的論壇式討論，要做reaction就非常容易。可惜Flow太多技術問題黃了。--路西法人 2026年2月11日 (三) 04:33 (UTC)

唉，是這樣，要是Flow做好了就容易多了。 --SuperGrey (留言) 2026年2月11日 (三) 06:17 (UTC)

問題已解決，但(＆)建議在說明處加上：Vector2010的「外觀」選單在頁面上方的「更多」處。--糯米花🌾🌼 2026年2月13日 (五) 01:28 (UTC)

那common.js的工具還會生效嗎？--糯米花🌾🌼 2026年2月11日 (三) 04:27 (UTC) 👍1

都生效，不管安裝幾遍都一樣的，不會衝突。 --SuperGrey (留言) 2026年2月11日 (三) 06:18 (UTC)

我研究了一圈，在偏好設定中沒有找到Reaction/反應；在common.js也有（User:糯米花/common.js），但不知爲何在實際操作中反而找不到這個reaction按鈕了。之前還有的。--糯米花🌾🌼 2026年2月12日 (四) 12:40 (UTC)

補充一下：使用的是Firefox瀏覽器。--糯米花🌾🌼 2026年2月12日 (四) 12:43 (UTC)

此外，手机上的浏览器（电脑模式）也不能显示reaction。--糯米花🌾🌼 2026年2月12日 (四) 15:53 (UTC) Test1

樓上這個Test，也顯示不了嗎？還是你沒有在外觀選單/工具欄中開啟？ --SuperGrey (留言) 2026年2月12日 (四) 16:49 (UTC)

Test可以显示，但是我无法添加。我在用Vector2010的外观，没有找到相关选项。--糯米花🌾🌼 2026年2月13日 (五) 01:19 (UTC)

「偏好設定中」找不到任何「Reaction」/「反應」的選項。--糯米花🌾🌼 2026年2月13日 (五) 01:21 (UTC)

对此我有两个意见：对留言的附属意见（“反应”）如果在单独页面保存和显示，乃至默认隐藏（即白名单），存在不同人看到不同视角的隐患，编外讨论性质，以及不能被网页存档，反破坏不及时等问题，虽然部分隐患目前也存在。如果问题仅限于表态是否单占一行，可以考虑表态真的单占一行来显示，通过插入或呈现时的兼容模式选项。理论上，似乎无禁止用小工具来插入一个表情+可选内容的留言，就类似于维基友爱的设计。--YFdyh000（留言） 2026年2月11日 (三) 19:40 (UTC)

Request for Translation of LanguageConverter documentation

👍1

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)

en:Wikipedia:Language_recognition_chart#Simplified_Chinese_(简体)_vs_Traditional_Chinese_(繁體)這邊的如何？但是要注意日文漢字就是了。--Saimmx（留言） 2026年2月10日 (二) 14:59 (UTC)

这位开发者写的test case已经合入主线了（tests/parser/langParserTests2.txt），虽说再去改也不是不行。
我觉得应考虑的问题仍然是文档里用什么例子能方便外国人理解LanguageConverter要解决的问题。Diskdance现在写的那份可以发布到mw:Writing systems/LanguageConverter（对应本地的H:AC），而mw:Writing systems/Syntax（H:高级字词转换语法）则仍需琢磨。--Srapoj（留言） 2026年2月10日 (二) 15:21 (UTC)

题外话，我觉得H:AC写得也不行，需要大幅翻修。我本来想直接翻译的，发现问题后就直接自己写了。--碟之舞📀💿 2026年2月11日 (三) 10:03 (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)

Search怎么了

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

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

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

未重现，已经好了？--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)

需要补充一下，似乎只有桌面端受到了影响，移动端的Search应该可以正常使用？至少搜出来两边不一样。--${\mathfrak {Kurwa}}$__^{( •̀ ω •́ )＜✧} 2026年2月12日 (四) 09:40 (UTC)

我也发现了，但是我还以为是自己的问题。。。--Zyx快困死了 2026年2月12日 (四) 11:51 (UTC)

问题的触发条件是桌面环境在搜索框输字母后切换到中文输入法，此时搜索建议请求只含有输入法最近一次输入的文本。我在phab:T393819#11611413提了。--Srapoj（留言） 2026年2月12日 (四) 15:15 (UTC)

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

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

abusefilterblockeddomainhit这个功能靠过滤器的added_links变量实现，效果应该与spamblacklist相同，所以同样得找管理员才能绕过。对于该条目可能可以调整规则（改回spamblacklist、让正则排除它的首页）？--Srapoj（留言） 2026年2月11日 (三) 14:39 (UTC)

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

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

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

赞。——三猎（留言） 2026年2月14日 (六) 08:02 (UTC)

2026年第7期技術新聞

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

近況更新 - 面向編輯者

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

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

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

會議與活動

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

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

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

iOS无法登陆

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

@Babala745：您可以依照此說明回報問題。另外，如果您使用測試版本會否遇上此問題？--SCP-0000（留言） 2026年2月10日 (二) 12:06 (UTC)

提議{{current}}模板不得合併至{{multiple issues}}模板？

在Twinkle的機制中，可以選擇將各種條目問題的模板合併至一個更大但顏色與介紹集成的{{multiple issues}}模板；然而，對於新聞動態而言，通常這並不意味著這是一個條目的「嚴重問題」，更不像其他的問題模板一樣正在告訴編者要對此進行修理；換句話說，{{current}}的功能不是表示條目有什麼問題，而只會是陳述事件是一個剛剛發生的新聞動態。

如果一片條目同時有{{current}}和{{multiple issues}}的話，那麼其配色都會是橙色，而沒有{{current}}的藍色與標誌；此外，在定義上也有明顯分別，而且總體而言，假設同時呈現{{current}}和其他問題，將兩者分別疊加的話反而更加顯眼和有用。

希望大家對此提出建議。本人的要求是希望將所有之後的{{current}}和{{multiple issues}}不再合併，而在twinkle中也說明二者即使同時出現，也不會被整合。

希望諸位參與討論決定是否接受這一提議。（同時，乞求各位參與「對於市鎮行政首長選舉的一些建議」一欄目的討論）--FK8438（留言） 2026年2月1日 (日) 13:54 (UTC)

我覺得合理。TW的調整則要問問維護人。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年2月3日 (二) 18:46 (UTC)

支持提案，表示條目主題狀態的模板明顯不應和「條目問題」放在一起。--1F616EMO（喵留言～求助？） 2026年2月10日 (二) 12:30 (UTC)

支持，{{In-progress TV show}}等适用于特定主题的状态模板同样不应该并入{{multiple issues}}模板。--Dabao qian℡ 2026年2月11日 (三) 04:38 (UTC)

此问题可能纯粹是关于Twinkle的？机器人U:Cewbot/規範多個問題模板設定似乎不处理Template:Current。--Srapoj（留言） 2026年2月11日 (三) 06:10 (UTC)

第一階段：行動版目錄實驗

大家好，

我代表維基媒體基金會（WMF）的讀者成長團隊發文說明。自 2 月 16 日當週起，我們將啟動一項測試，在行動網頁版加入「目錄」，並自動展開文章的所有章節，藉此解決上述的導覽困難，幫助讀者更快速地取得資訊。

我們的假設是，透過提供可一眼查看各章節的目錄，讀者將能更容易找到他們想要的內容。

為什麼要進行這項工作？

我們將這項工作視為因應維基百科頁面瀏覽量下降的一部分。我們希望讓網站上的內容更容易存取，特別是在行動裝置上，因為許多新讀者都是從行動裝置進入的。WMF 的「讀者基礎研究」顯示，文章內導覽困難，尤其是在行動裝置上，是讀者最常見的抱怨之一。

因此，我們嘗試在行動網頁版加入目錄，評估其是否能提升瀏覽的便利性。根據數據，目錄有助於導覽。例如，維基百科 Android 應用程式內建目錄，平均每位使用者會開啟將近 4 次，遠高於使用者啟動搜尋的次數（每次工作階段平均僅 1.5 次）。該應用程式的點擊率也高達 71.1%，顯示在小螢幕上的使用情況相當活躍。

These screenshots show the two different table of contents buttons that will be shown to experiment participants in the two treatment options.

我們正在測試什麼想法？

目前，文章章節在行動版預設為摺疊狀態，原本的設計目的是在使用者瀏覽長篇文字時節省時間。然而，我們懷疑這樣的預設設定反而造成導覽困難，因為使用者必須先打開各個章節才能閱讀。

2025 年 12 月，我們在阿拉伯語、越南語、法語、中文與印尼語維基百科上進行了一項實驗：1）預設自動展開文章中的所有章節；2）在捲動時將章節標題固定在畫面頂端。

結果顯示，這項變更實際上讓讀者留存率下降了約 1.5%，且縮短了他們在維基百科上停留的時間。我們推測，在行動裝置上一次展開所有章節，形成了一整面文字，導致讀者感到壓迫或挫折而離開。因此，我們決定嘗試不同的方法。

現在，我們希望了解提供「目錄」是否能改善導覽需求。新的測試將在行動版加入一個目錄按鈕。當使用者點擊該按鈕時，畫面底部會滑出一個面板，顯示文章的章節標題，使用者可點擊直接跳轉至頁面的不同位置。

These screenshots show the two different table of contents interfaces that the two treatment groups will see.

此專案目前處於哪個階段？

本專案目前處於第一階段：推出一個小規模測試，使用這些想法的早期版本。目前尚不確定這項功能是否能改善讀者體驗，因此我們需要透過測試來決定是否進入第二階段：正式建置功能。

時間表為何？

此實驗將於 2 月 16 日當週上線，並持續四週。它將影響阿拉伯語、越南語、法語、中文與印尼語維基百科中 10% 的行動裝置使用者，以及英文維基百科中最多 1% 的行動裝置使用者。取得結果後，我們將回到這裡討論成果，並決定是否繼續推進此想法。

謝謝大家！EBlackorby-WMF（留言） 2026年2月11日 (三) 17:47 (UTC)

{{cite journal}}模板publication_date以及year参数同时存在时，page参数填写的页码会与publication_date的日期黏连

e.g.: 广州开征外地车城市路桥隧道通行费. 粤港澳价格. 2002, (01): 42-432002-01-20. 

本人在引用该来源时，因知网有显示期刊出版发布在该平台上时间，同时也存在该期刊的年份号标定期刊位置，于是使用出版日期及年份参数，但会发生如题所示的bug。

可否有编者帮忙修复一下，如在页码后面加个逗号之类的。--YikyuenG~速速点击 2026年2月12日 (四) 16:41 (UTC)

補充：曾嘗試進行除錯，發現若改為在date參數填入日期，則會導致publication_date（而非date）被判斷為無效：

广州开征外地车城市路桥隧道通行费. 粤港澳价格. 2002, (01): 42-43 (2002-01-20). 

此處可能另有問題，未知是否有關。--1F616EMO（喵留言～求助？） 2026年2月12日 (四) 23:46 (UTC)

Series overview模板的Lint錯誤「night-mode-unaware-background-color」要怎麼修正？

這個模板會觸發Lint錯誤「night-mode-unaware-background-color」，是在color{1-50}這個參數。假如color1、color2、color3這類參數輸入顏色代碼，那麼就會出現Lint錯誤；如果欄位空著不填顏色，那就不會，在這個沙盒舉例。這個模板是不是設計有問題，或者Lint檢測誤判？——George6VI（留言） 2026年2月13日 (五) 01:25 (UTC)

因为color参数没有兼容night mode--百無一用是書生 (☎) 2026年2月13日 (五) 03:16 (UTC)

那麼模板的原始碼、或者模板本身會用到的Module，能改成Lint可以接受的樣式嗎？我不知道這個部分為什麼會需要考慮深色模式，那個色塊是沒有文字的，或者在Lint將這種情況設作例外？——George6VI（留言） 2026年2月13日 (五) 06:00 (UTC)

 已修复--Dabao qian℡ 2026年2月13日 (五) 17:47 (UTC)