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

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

发表新议题

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

公告欄

• [人事] 管理人员申请提名正在进行中，欢迎关注参与。
• [公告] 请汇报由于新近上线的安全措施而工作异常的用户脚本。
• [公告] 取消人物生日分類、廢除大量帳號創建者的方針地位、確立WP:模板命名空間為指引及將分類名稱中的「撤消」更正為「撤銷」已經通過。
• [公告] 常見有爭議來源列表新格式、修改同行評審存檔程序及调整“维基百科不是水晶球”的早期翻译正在公示，如有意見請盡快提出。
• [討論] 互助客栈正在討論提议“特色列表”改名及2027丁未年新年标志联合票选，歡迎踴躍參與。
• [討論] 社群正在討論有關非編號命名的城市軌道交通鐵路綫的條目命名、確立列表收錄標準為正式指引、检讨不限期封禁的用户页标记、有關國際學校導航模板的命名、仲裁委員會組織調整、活動組織者該由行政員還是管理員賦權、昆虫专题问题、修訂資訊框格式手冊有關表示國籍與公民權的規定、取消快速刪除方針G14條的14日等待期、停止人工解除隐退用户的多余权限、簡化命名常規與格式手冊的命名、「合理使用」改為「非自由內容」並提升為指引及尚在规划的城市轨道交通线路是否应独立成文，歡迎踴躍參與。

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

#	💭 話題	💬	👥	🙋 最新發言	🕒 (UTC+8)
1	提議：高亮哈佛参考文献格式短鏈指向的完整資料引用	58	9	Ericliu1912	2026-03-22 17:01
2	改善字体的讨论怎麼又死了	18	9	魔琴	2026-03-19 07:02
3	中文字元與拉丁字母、數字之間在顯示上被自動加入空格	1	1	Jimmy-bot	2026-03-24 16:14
4	Request for Translation of LanguageConverter documentation	1	1	Jimmy-bot	2026-03-24 16:14
5	Search怎么了	18	8	Kurgenera	2026-03-15 15:25
6	请汇报由于加载站外资源而报错的用户脚本和小工具	17	6	SunAfterRain	2026-03-25 04:30
7	第二階段：圖片瀏覽實驗成果及下一步	4	3	Nostalgiacn	2026-03-16 13:51
8	Lint錯誤（Template:Ahnentafel-compact5）	7	4	George6VI	2026-03-15 21:06
9	原始碼編輯下點擊引用模板沒有反應	13	9	Shwangtianyuan	2026-03-22 23:53
10	2026年第12期技術新聞	1	1	MediaWiki message delivery	2026-03-17 03:33
11	InternetArchiveBot​怎么把重定向页面恢复为正常页面？	3	3	臺灣象象	2026-03-19 22:17
12	维基登录	2	2	12З4567	2026-03-19 11:00
13	Request for Comment: VisualEditor automatic reference names	5	3	ShuQizhe	2026-03-21 15:05
14	誠邀參與Wikipedia:防滥用过滤器/过滤器请求§修复过滤器101的討論	1	1	臺灣象象	2026-03-20 00:32
15	2026年第13期技術新聞	1	1	MediaWiki message delivery	2026-03-24 00:48
16	Phase 2: Reading lists results and scaling	1	1	EBlackorby-WMF	2026-03-25 02:19

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

正在廣泛徵求意見的議題

議題清單

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

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有歧义

最近在看优良条目广州市时发现，该条目之前多次参与优良条目评选和优良条目重审，导致其讨论页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 talk:可靠来源/常见有争议来源列表 § 新RSP格式

新RSP格式已完成，索引頁在此：Wikipedia:可靠來源/常見。預計索引頁中的列表和搜尋框將嵌入到Wikipedia:可靠来源/常见有争议来源列表以替換原表格。存檔方式等資訊，可以就直接放在各個頁面裡面（開個「存檔」章節）。已有的頁面也可以補充收錄電子遊戲專題、ACG專題的來源評語（例如Wikipedia:可靠來源/常見/17173.COM）。雖然RSP只是論述，但還是需要來個徵求意見，讓大家再討論看看。Ping「收錄存檔資訊」一事的討論參與者：@1F616EMO、Ericliu1912、Liu116、Olaf8940、Sksawf、YFdyh000、魔琴。--SuperGrey (留言) 2026年3月3日 (二) 14:44 (UTC)

Wikipedia talk:保護 § 提議引入Extension:Approved Revs 取代部分半保護

鑑於部分頁面受長期低頻率破壞而被半保護，現有的提供修改建議及建立草稿方式不僅不利於新使用者上手、阻礙其貢獻，該方法亦不利於效率及頁面歷史整合。在此提議引入此功能，並授予管理員、回退員approverevisions權限（亦可透過自動化程序為自動／延伸確認用戶編輯審批，待討論）。僅在此提供意見 駭客呼吸焉—☎️— 2026年3月7日 (六) 07:52 (UTC)

Wikipedia:防滥用过滤器/过滤器请求 § 提議修改不可靠來源過濾器的結構

提議將不可靠來源過濾器改為以下面的架構加上識別是否為自確的規則，以汰換效能較差且有時會誤判新加入的外部連結的added_links變數：

equals_to_any(page_namespace, 0, 118)
& (
black := "https?://\S*((?<!archive\.|biblio\.)wiki(?!leaks|sky|mapia)|[^a]bbs|hudong|forum|baike\.baidu|tieba\.baidu|hi\.baidu|zhidao\.baidu|knowledge\.yahoo|msn\.cn|uncyclopedia|grokpedia|littleoslo\.com|isaacmao\.com|sclub|facebook\.com/pages|zhihu\.com|pincong|epochtimes|lagranepoca\.com|etindonesia\.com|zhbus|toutiao\.com|guo\.media|quora\.com|breitbart\.com|blog\.udn\.com|www\.ixueshu\.com|jikipedia\.com|guancha\.cn|passport\.weibo\.com|163\.com/dy|c\.m\.163\.com|bendibao\.com|(haokan|baijiahao)\.baidu\.com|1drv\.ms|drive\.google\.com|jianshu\.com|meipian\.cn|bangumi\.tv|bgm\.tv|chii\.in|ecured\.cu|moegirl\.(org\.cn|tw)|hkgpao\.com|speakout\.hk|ntdtv(\.(com(\.tw)?|jp|kr)|\-dc\.com)|ntd\.com|schooland\.hk|huanhaoba\.com|bendibao\.com|hao\.cnyes\.com|globaltimes\.cn|homeway\.com\.cn|cgtn\.com|goosedaily\.com|wyzxwk\.com|militarywatchmagazine\.com|msn\.com/zh\-cn)\S*([\s$\|\]]|}}|</span>)";
white := "https?://\S*(wikipedia|wikimedia|wikisource|wiktionary|wikibooks|wikiquote|wikinews|wikidata|toolserver\.org|openoffice\.org|wmflabs|geohack\.toolforge\.org)\S*([\s$\|\]]|}}|</span>)";
black_links := rcount(black, added_lines) - rcount(black, removed_lines);
white_links := rcount(white, added_lines) - rcount(white, removed_lines);
black_links > 0
& black_links > white_links
)
& !(new_html contains "<div class=\"abusefilter-marking-copyvio\"></div>")

--象象🐘(留言|貢獻) 2026年3月13日 (五) 16:39 (UTC)

Module talk:Adjacent stations § 編輯請求 2026-03-14

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

實現{{Rail color box}}裏small但不帶後面的條目連結（title）的效果與在title前插入鐵路系統的條目連結（system title）的方案，具體效果範例如下：

港鐵

• {{Rail color box/sandbox|港鐵|TWL|syes}}→     港鐵荃灣綫
• {{Rail color box/sandbox|港鐵|TWL|ssmall}}→  港鐵荃灣綫
• {{Rail color box/sandbox|港鐵|TWL|sdot}}→● 港鐵荃灣綫
• {{Rail color box/sandbox|港鐵|TWL|ssquare}}→■ 港鐵荃灣綫
• {{Rail color box/sandbox|港鐵|TWL|lsmall}}→ 

北京地鐵

• {{Rail color box/sandbox|北京地铁|1|syes}}→     北京地铁1号线
• {{Rail color box/sandbox|北京地铁|1|ssmall}}→  北京地铁1号线
• {{Rail color box/sandbox|北京地铁|1|sdot}}→● 北京地铁1号线
• {{Rail color box/sandbox|北京地铁|1|ssquare}}→■ 北京地铁1号线
• {{Rail color box/sandbox|北京地铁|1|lsmall}}→ 

以上。參見User talk:Benteds#各路线标志模板的繁複設置問題。Sanmosa _风林火山 2026年3月14日 (六) 00:38 (UTC)

Template talk:Country data Chinese Taipei § 編輯請求 2026-03-15

将有关足球（包括但不限于11人制、5人制、沙滩足球等）的图片改为最新版，而非2010年在奥运会上停用的错版旗帜。根据目前国际足联之信息（男子、女子、男子五人制，女子五人制），且参照近年赛事使用旗帜之情况（可访问亚足联亚洲杯的YouTube频道查看回放），均为正确的新版旗帜，而非继续沿用之前赛事主办方的错误。--Cygz（留言） 2026年3月15日 (日) 16:19 (UTC)

Template talk:Fb cl3 team § Vector 2022 暗色模式文本显示问题

在类似2025年非洲國家盃#最终排名和2023年亞足聯亞洲盃#最終排名的表格里，在Vector2022的暗色模式下，{{Fb cl3 team}}里的字体颜色和背景颜色一样，完全看不见表格里的字。但在Vector2010的暗色模式下就没有问题，字体颜色为正常的白色。--𝓧𝓩𝓣𝓓𝓮𝓪𝓷  2026年3月18日 (三) 12:25 (UTC)

Template talk:G15-exempt § G15-exempt还是G15 Placeholder？

我就原{{CSD Placeholder}}是否应当被重命名为{{G15-exempt}}多次（1、2、3）向Sanmosa提出异议，但是我们无法说服对方，请求社群介入。 ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年3月18日 (三) 20:05 (UTC)

Wikipedia:互助客栈/技术 § Request for Comment: VisualEditor automatic reference names

Hi, I’m Johannes from Wikimedia Deutschland’s Technical Wishes team. Apologies for writing in English. 请帮助翻译至您的语言! We are considering to work on Community Wishlist/W17: Improve VE references' automatic names and reuse. This has been a long-term issue for wikitext editors (see e.g. en:WP:VisualEditor/Named references) which has been among the top-voted wishes in several Community Wishlist Surveys, e.g. 2017, 2019, 2022 or 2023.

更多信息：m:WMDE Technical Wishes/References/VisualEditor automatic reference names

We would like your input on the solutions proposed on our project page. We are considering several options, which can be combined if desired by the community.

• Changing the default pattern for automatically generated reference names (currently ":n", e.g. ":0", ":1"...) to use the reference type instead (e.g. "book_reference-1").
• Providing a simple mechanism for communities to configure a different default name.
• Generating automatic reference names based on the domain name (if it’s a web citation).
• Generating automatic reference names based on template parameters (e.g. "title" or "last"+"first") – defined by the community.

Feedback

Visit our project page to read about our proposal in detail and share your thoughts on metawiki.

Please note: We will only implement a solution if there’s clear consensus among the global community. Our intention is not to build the perfect solution, but to find a simple and lean one that alleviates the pain caused by auto generated names. We are aware that some experienced VisualEditor users might prefer an option to manually change reference names in VisualEditor, but such a UX intervention is difficult to achieve across reference types and thus out of scope for our team, we can only improve the auto-naming mechanism. We are happy about suggestions for improving certain details of the proposed solutions. Any other feedback and alternative proposals are also welcome – even though it’s out of scope for us, it might still be relevant for future work on this topic.

Please support us interpreting consensus by clearly indicating your opinion (e.g. by using support/neutral/oppose templates). We are aware of en:WP:NOTVOTE, but given that we are facilitating this discussion with users from different wikis, potentially commenting in their native language, clearly indicating your position helps us avoid misunderstandings.

Thank you for participating! --Johannes Richter (WMDE)（留言） 2026年3月19日 (四) 11:40 (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 _{創造は生命（留言・留名・學生會）} 2026年2月13日 (五) 12:23 (UTC)

@Dabao qian？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年3月22日 (日) 09:01 (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

贊成使用全身間隔號。技術方案可另議，但最後的排版效果無疑應當是全身的。早期互聯網技術不發達造成的錯誤毫無因襲之必要。注意到日語有專門的 U+30FB KATAKANA MIDDLE POINT，漢語雖然尚無如此專門符號（U+2027 HYPHENATION POINT？），排版效果上卻無2026年仍不能實現之理。

Xsgzjmxs（留言） 2026年2月16日 (一) 13:44 (UTC)

要不先做幾個方案出来製成小工具我们先测试一下什麼的…… ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年3月3日 (二) 01:01 (UTC)

不太建议应用全站CSS@font-face去强行修改单个字符，因为字体的基线等参数的不同，给所有字体都套上统一的标点可能会遇到垂直不对齐的问题，至少应该用JS检测实际默认字体后再针对性添加CSS。（这个问题其实应该当初和弯引号一起提报标准变体选择符处理的，参见当初弯引号的提案）

覆盖多语言字体的提案不是太建议推动，插件或者Firefox能直接全域地解决这个问题，而操作系统提供的字体经常远不如自定义的，必须要有简单的opt-out方式。--DvXg 📬 2026年3月6日 (五) 15:47 (UTC)

弯引号确实能用变体处理了，但是你站也没办法给所有中文弯引号加上变体选择符，而且用户的字体版本可能非常落后…… ——魔琴［留言 贡献 PJ:小學 PJ:兩岸］ 2026年3月18日 (三) 23:02 (UTC)

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

Search怎么了

於Phabricator追踪
工單T416764

网页默认的搜索框坏掉了，例如按照简体输入“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)

@Kurgenera：才看到。我这边的移动端也不太正常……--浅村しき（留言・签名） 2026年2月18日 (三) 16:44 (UTC)

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

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

确实如此。--${\mathfrak {Kurwa}}$__^{( •̀ ω •́ )＜✧} 2026年2月18日 (三) 16:51 (UTC)

貌似搜索框是捕捉到最后一个输入的字词进行联想，确实是只有桌面端会这样，不知道为什么是这样的，希望改回去。--Cygz（留言） 2026年2月20日 (五) 10:08 (UTC)

所有需要输入法输入的文本都有这个问题，例如在日语维基百科用日语输入法先打“ウィ”再打“キ”，也是只有“キ”的结果。——Vesekskiy正在聽詩超絆 2026年2月20日 (五) 12:00 (UTC)

好像恢复了。——Vesekskiy正在聽詩超絆 2026年3月12日 (四) 18:43 (UTC)

确实。WMF的人自己在英维发现了，报了另外的工单。--Srapoj（留言） 2026年3月13日 (五) 03:31 (UTC)

目前查证已修复。--${\mathfrak {Kurwa}}$__^{( •̀ ω •́ )＜✧} 2026年3月15日 (日) 07:25 (UTC)

请汇报由于加载站外资源而报错的用户脚本和小工具

於Phabricator追踪
工單T419265

於Phabricator追踪
工單T421033

由于维基媒体站点近期的安全事故，WMF于近几天强制启用了CSP（Content Security Policy）功能，用于阻止网页发出未经允许的请求。然而由于该列表采用白名单模式，因此预计可能会导致本站现有的脚本出现问题。

根据现况，只要是正常脚本依赖的站外资源，都可申请添加到白名单中。因此如果您的用户脚本在近期发生故障，且确认是因依赖外部资源而引起，请于此回报，以便集中向Phab反馈。谢谢！--碟之舞📀💿 2026年3月9日 (一) 08:20 (UTC)

InPageEdit會因無法加載部分位於registry.ipe.wiki及cdn.jsdelivr.net的資源而無法載入部分本地化字串及擴展代碼。--1F616EMO（喵留言～求助？） 2026年3月9日 (一) 10:49 (UTC)

Wikiplus也是如此。--Srapoj（留言） 2026年3月9日 (一) 10:53 (UTC)

meta:CVN的用戶標記腳本因無法載入位於intuition.toolforge.org及cvn.wmcloud.org的資源而無法正常載入。--1F616EMO（喵留言～求助？） 2026年3月9日 (一) 10:51 (UTC)

@SuperGrey：meta:Cite Unseen因無法載入位於gitlab-content.toolforge.org的內容而無法更新來源資訊快取，且新用戶無法獲取來源資訊。--1F616EMO（喵留言～求助？） 2026年3月9日 (一) 10:53 (UTC)

我记得toolforge已经被允许了（b815491、6142fb1）。--Srapoj（留言） 2026年3月9日 (一) 11:04 (UTC)

@1F616EMO：*.toolforge.org、*.jsdelivr.net、*.wmcloud.org都在CSP白名单内。不知道为什么，现在同时有content-security-policy和content-security-policy-report-only header，但后者无需理会。--碟之舞📀💿 2026年3月9日 (一) 11:00 (UTC)

那麼影響的應該只有IPE的擴展商店了。--1F616EMO（喵留言～求助？） 2026年3月9日 (一) 13:45 (UTC)

为了方便统计，请各位直接编辑下方代码区域加入需要加白的域名：

*.ipe.wiki # InPageEdit
*.moegirl.org # Moegirlpedia
*.moegirl.org.cn # Moegirlpedia

以上。--碟之舞📀💿 2026年3月11日 (三) 02:14 (UTC)

另@Dabao_qian。--碟之舞📀💿 2026年3月11日 (三) 02:15 (UTC)

用contentmodel:javascript insource:"moegirl.org"搜索了一下用户页空间，还是有人在用，所以加上去了。--Dabao qian℡ 2026年3月15日 (日) 20:24 (UTC)

@Diskdance：IPE會在用戶同意下向analytics.子域名發送資訊，故應允許整個*.ipe.wiki。1F616EMO（喵留言～求助？） 2026年3月11日 (三) 10:47 (UTC)

我對給伺服器架在中國大陸並接受其法律管轄的網站開白名單這件事持保留意見。--MilkyDefer 2026年3月18日 (三) 16:23 (UTC)

不支持給萌娘開白名單，一共也就這些人用而已，我相信請他們想辦法重寫一版或者找其他外部託管比較實際。（Active user 的定義指近半年有出現編輯）--SunAfterRain 2026年3月21日 (六) 15:56 (UTC)

嗯，但是据我观察，他们还是比较在意正常脚本坏掉的，所以可能会支持。--碟之舞📀💿 2026年3月24日 (二) 03:53 (UTC)

不過講真的，目前有問題的也就@在下羊羽君用的那一大票腳本而已。（畢竟死號放著不管沒毛病、wikiplus-highlight.js請@30000lightyears直接複製過來本站存放、@人间百态已經請他處理了、原生實現的功能顯然也不會因此再開白名單）--SunAfterRain 2026年3月24日 (二) 20:30 (UTC)

@1F616EMO、@Dabao qian、@MilkyDefer、@Srapoj、@SunAfterRain：已提交phab:T421033。--碟之舞📀💿 2026年3月24日 (二) 03:46 (UTC)

第二階段：圖片瀏覽實驗成果及下一步

大家好！

我們在去年11月與大家分享了讀者成長團隊正在進行一項實驗，旨在測試如何讓讀者更輕鬆地瀏覽和發現維基百科文章中的圖片及其他多媒體內容。這項圖片瀏覽實驗於11月17日在英語維基百科上線，針對0.1%的讀者進行行動裝置專屬的A/B測試，歷時四周後關閉。我們同時在阿拉伯語、中文、法語、印尼語和越南語維基百科上進行了這項實驗。我們希望在此與大家分享實驗結果，並聽取大家對後續工作的建議。

實驗性功能包含：

• 在文章內容上方嵌入橫向圖片輪播功能，顯示文章圖片的縮圖預覽。
• 當讀者點擊輪播圖片時開啟的詳情視圖覆蓋層，顯示帶有圖說、智能裁剪及操作按鈕（分享/下載/在維基共享資源查看）的大尺寸版本。
• 視覺化目錄（VTOC）——以網格形式呈現所有文章圖片，並包含來自其他維基媒體專案的圖片。
• 透過智能裁剪與主色調提取技術強化視覺呈現效果。

我們發現了什麼？

我們的主要成功指標是文章頁面頂部新增圖片輪播元件的點擊率。在英文維基百科上，我們觀察到點擊率為 8.7%。鑑於典型網頁點擊率介於 1% 到 5% 之間，而本次實驗目標僅為3%，此數據被視為令人鼓舞的積極指標。考慮到典型的網頁點擊率在 1% 到 5% 之間，而我們這次實驗的目標是 3%，我們認為這是一個令人鼓舞的指標。在阿拉伯語、中文、法語、印尼語和越南語維基百科上，我們觀察到點擊率為 7.8%。

我們同時追蹤讀者回訪率，即 21 天內再次造訪維基百科的讀者比例。在非英語維基專案測試站點中，回訪率提升約0.1%，而英語維基百科則無變化。

我們同時發現，當讀者點擊圖片時，他們通常希望進行更深入的互動。在詳情頁面的點擊行為中，61%是讀者選擇查看完整圖片，15%用於下載圖片，9%用於分享圖片，這些比例均高於探索其他圖片的選項。這些數據點表明，讀者默認傾向於與所選圖片進行更深入的互動。

我們的下一步計劃是什麼？

鑑於該功能展現出可觀的點擊率，我們認為這預示讀者將從中受益，因此計劃在三月擴展此功能。根據功能使用數據，我們將首先專注於圖片輪播功能——預設顯示完整圖片，並為所有維基專案上未有登入行動網頁的讀者提供捏合縮放功能。我們同時將允許編輯根據需要從文章中移除圖片輪播功能，並允許已登入的讀者在所有頁面上自行關閉圖片輪播功能。目前，我們暫不擴展查看其他維基專案上的圖片或可視化「目錄」的功能，但我們會進一步探索這些想法，以獲取更多信息，並可能會在未來的實驗中進行，屆時我們會在此處分享相關進展。

此外，我們希望聽到您的更多意見。您對這些結果有何看法？基於這些信息，您是否對上述功能有其他構想？請在此分享您的想法和問題。請訪問我們的專案頁面以獲取更多信息。

謝謝！EBlackorby-WMF（留言） 2026年3月9日 (一) 19:16 (UTC)

翻譯好像有人重複寫了一段（ —— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年3月12日 (四) 12:33 (UTC)

Talk:砂糖_(原神)#圖片，我發現所有在條目中使用的圖片，像素都下降了。對比原文件明顯有壓縮。又如File:夏日時光1.jpg和[1]--Nostalgiacn（留言） 2026年3月16日 (一) 05:34 (UTC)

補充對比圖：https://imgur.com/a/jiEdSE5

目前，在條目上看到的是左側的效果，右側是保存到維基百科上的原文件。就算引用的和原文件大小一致，似乎又會再壓縮一次，品質差很多。之前沒有這個問題，最近只有這個圖片相關測試，可能受到影響。--Nostalgiacn（留言） 2026年3月16日 (一) 05:51 (UTC)

Lint錯誤（Template:Ahnentafel-compact5）

在沙盒中使用模板Ahnentafel-compact5，LintErrors會顯示「night-mode-unaware-background-color」「輸出並非來自單一個模板」，但是單獨檢測相關的模板chart top、chart bottom、Documentation、Ahnentafel以及Module:Ahnentafel都沒有結果，是哪裡有問題？--George6VI（留言） 2026年3月10日 (二) 02:26 (UTC)

它说lint错误来自{{Documentation}}也就说明问题位于模板文档页。查看T:Ahnentafel/doc即可看到它的例子给那些框只设置了背景色，没有文本颜色。
不过本人其实想劝您找点别的lint错误修，比方说在mw:Help:Lint errors可以看到night-mode-unaware-background-color是被归为低优先级的，而有些时候WMF提供的适配样式可以让页面在深色模式下有可接受的显示效果。--Srapoj（留言） 2026年3月11日 (三) 12:49 (UTC)

要不是因為怕這種Lint錯誤可能影響未來條目評選不然我還不想管，這個「錯誤」（或者說找碴）雖然低級可很多條目都被標記而且還很難修正，好像沒什麼通用的辦法……加入inherit設定顏色，還是沒辦法，希望有人幫忙看這次又該怎麼辦。——George6VI（留言） 2026年3月12日 (四) 00:23 (UTC)

您這樣修深色模式下是黑色，是不可行的。--Qqkuro66541（留言） 2026年3月12日 (四) 15:54 (UTC)

……這天書真的不是我擅長的領域，現在我把Template:Ahnentafel/doc放上來，希望其他懂的人修一下吧。——George6VI（留言） 2026年3月14日 (六) 14:57 (UTC)

道理我都懂，但是我看这边根本没有这个Lint错误啊？--MilkyDefer 2026年3月14日 (六) 15:42 (UTC)

看起來現在已經沒有問題了。——George6VI（留言） 2026年3月15日 (日) 13:06 (UTC)

原始碼編輯下點擊引用模板沒有反應

如題，昨天發生的，不曉得有沒有其他編輯君遇到同樣問題。--提斯切里（留言） 2026年3月14日 (六) 03:59 (UTC)

需要有界面管理员花点功夫看看怎么同步英维RefToolbar的更改。应该坏了有段时间了。--Srapoj（留言） 2026年3月14日 (六) 05:01 (UTC)

原來。我是昨天確實感受到，視覺化編輯還可用。--提斯切里（留言） 2026年3月14日 (六) 05:12 (UTC)

这个问题我也碰到了。但是，英文维基是可以正常打开的。不过我最近转为其他工作，问题不大，看问题能否成功解决了。--Shwangtianyuan 让中国再次伟大 2026年3月14日 (六) 12:44 (UTC)

英文版1月份和3月份都做了修改。不知道自动登出有没有修复，如果修复的话，直接引用英文版的代码就好，否则要麻烦一些--百無一用是書生 (☎) 2026年3月16日 (一) 03:46 (UTC)

我也有這個問題。--Freddickfix（留言） 2026年3月16日 (一) 17:17 (UTC)

希望快點解決，否則有時碰到編輯技術問題，很是困擾。--Tp0910（留言） 2026年3月17日 (二) 13:06 (UTC)

如果感觉不方便，在有界面管理员修它之前，可以去设置-编辑换用“2017年版wikitext编辑器”来插入来源。--Srapoj（留言） 2026年3月17日 (二) 13:14 (UTC)

也可以用WP:ProveIt--Saimmx（留言） 2026年3月17日 (二) 19:55 (UTC)

同樣問題+1.--糯米花🌾🌼 2026年3月20日 (五) 05:14 (UTC)

@Shizhao，MediaWiki talk:RefToolbar.js#編輯請求 2026-03-21--YFdyh000（留言） 2026年3月21日 (六) 20:52 (UTC)

已经修复--百無一用是書生 (☎) 2026年3月22日 (日) 12:22 (UTC)

刚试了已经解决了问题。--Shwangtianyuan 让中国再次伟大 2026年3月22日 (日) 15:53 (UTC)

2026年第12期技術新聞

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

近況更新 - 面向編輯者

• 2024年11月，增强版语法高亮（亦稱為CodeMirror 6）以測試功能推出，用於wikitext的語法高亮顯示。此功能預計將於2026年5月正式推出，向所有使用該功能的編輯者提供改進與新功能。若您對此功能的正式推出有任何疑問或顧慮，敬請提出。 [2]
• Some changes to local user groups are performed by stewards on Meta-Wiki and logged there only. Now, interwiki rights changes will be logged both on Meta-Wiki and the wiki of the target user to make it easier to access a full record of user's rights changes on a local wiki. Past log entries for such changes will be backfilled in the coming weeks. [3]
• On wikis using Flagged Revisions, the number of pending changes shown on Special:待定更改 previously counted pages which were no longer pending review, because they have been removed from the system without being reviewed, e.g. due to being deleted, moved to a different namespace, or due to wiki configuration changes. The count will be correct now. On some wikis the number shown will be much smaller than before. There should be no change to the list of pages itself. [4]
• 維基函數的複合語言（composition language）已重新編寫。此次重寫旨在透過降低協調器的記憶體消耗，來提升服務的穩定性。此次重寫還帶來了顯著的延遲降低、代碼簡化以及更好的抽象化，為日後的功能擴展奠定基礎。了解更多。
• Users can now sort search results alphabetically by page title. The update gives an additional option to finding pages more easily and quickly. Previously, results could be sorted by Edit date, Creation date, or Relevance. To use the new option, open 'Advanced Search' on the search results page and select 'Alphabetically' under 'Sorting Order'. [5]
• 上週有28件由社群提交的工單得到解決。 例如，之前維基共享資源的上傳嚮導出現異常，無法從Flickr匯入檔案，現已修正此問題。 [6]

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

• A new special page, Special:LintTemplateErrors, has been created to list transcluded pages that are flagged as containing lint errors to help users discover them easily. The list is sorted by the number of transclusions with errors. For example: Special:LintTemplateErrors/night-mode-unaware-background-color. [7]
• 一段時間以來，對於啟用「增强版语法高亮」測試功能的使用者，在編輯JavaScript、CSS、JSON、Vue、Lua內容頁面時，編輯器已改用CodeMirror取代CodeEditor進行語法高亮。隨著CodeMirror 6的正式推出，我們預計於2026年5月以CodeMirror取代CodeEditor，作為這些內容模型的標準編輯器。歡迎提出意見或疑慮。 [8]
• CodeMirror的JavaScript模組即將升級至CodeMirror 6。在此次升級之前，在小工具和使用者腳本中載入ext.CodeMirror或ext.CodeMirror.lib模組的方法已於2025年7月標為棄用。此外，ext.CodeMirror.switch鉤子的使用亦已於2025年3月標為棄用。貢獻者現在可以修改腳本或小工具，使其與CodeMirror 6相容。詳情請參閱遷移指南。 [9]
• MediaWiki介面團隊正在擴大REST API模組的定義範圍，將「擴充功能API」納入其中。REST API模組是由一系列相關端點組成的群組，可獨立進行管理與版本控制。目前已為GrowthExperiments和維基函數API建立模組。隨著我們將「擴充功能API」遷移至此架構中，相關文件將從MediaWiki OpenAPI主要規格及REST沙盒檢視中移出，改為透過REST沙盒（即Special:RestSandbox，所有維基專案皆可使用）下拉選單中的模組專屬選項存取。
• Scribunto擴充功能透過mw.site函式庫，為模組提供維基站點的各項資訊。自上週起，該函式庫亦提供了一種存取維基站點ID的方式，可用於簡化跨維基模組的維護工作。 [10]
• 本週軟體更新細節： MediaWiki

深入了解

• The 2026 Coolest Tool Award celebrating outstanding community tools, is now open for nominations! Nominate your favorite tool using the nomination survey form by 23 March 2026. For more information on privacy and data handling, please see the survey privacy statement.

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

MediaWiki message delivery 2026年3月16日 (一) 19:33 (UTC)

InternetArchiveBot​怎么把重定向页面恢复为正常页面？

如题：受影响页面。是不是该机器人出现bug了？--万水千山（TuhansiaVuoria）（留言） 2026年3月17日 (二) 07:02 (UTC)

應該是之前排程的吧？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2026年3月19日 (四) 02:36 (UTC)

或許是預先發送API請求，而沒有在編輯前檢查所致--象象🐘(留言|貢獻) 2026年3月19日 (四) 14:17 (UTC)

维基登录

今天用Chrome和Firefox登录维基数据、维基词典，浏览器卡死，到输入用户名阶段浏览器就开始无响应。--Kethyga（留言） 2026年3月19日 (四) 02:11 (UTC)

Request for Comment: VisualEditor automatic reference names

Hi, I’m Johannes from Wikimedia Deutschland’s Technical Wishes team. Apologies for writing in English. 请帮助翻译至您的语言! We are considering to work on Community Wishlist/W17: Improve VE references' automatic names and reuse. This has been a long-term issue for wikitext editors (see e.g. en:WP:VisualEditor/Named references) which has been among the top-voted wishes in several Community Wishlist Surveys, e.g. 2017, 2019, 2022 or 2023.

更多信息：m:WMDE Technical Wishes/References/VisualEditor automatic reference names

We would like your input on the solutions proposed on our project page. We are considering several options, which can be combined if desired by the community.

• Changing the default pattern for automatically generated reference names (currently ":n", e.g. ":0", ":1"...) to use the reference type instead (e.g. "book_reference-1").
• Providing a simple mechanism for communities to configure a different default name.
• Generating automatic reference names based on the domain name (if it’s a web citation).
• Generating automatic reference names based on template parameters (e.g. "title" or "last"+"first") – defined by the community.

Feedback

Visit our project page to read about our proposal in detail and share your thoughts on metawiki.

Please note: We will only implement a solution if there’s clear consensus among the global community. Our intention is not to build the perfect solution, but to find a simple and lean one that alleviates the pain caused by auto generated names. We are aware that some experienced VisualEditor users might prefer an option to manually change reference names in VisualEditor, but such a UX intervention is difficult to achieve across reference types and thus out of scope for our team, we can only improve the auto-naming mechanism. We are happy about suggestions for improving certain details of the proposed solutions. Any other feedback and alternative proposals are also welcome – even though it’s out of scope for us, it might still be relevant for future work on this topic.

Please support us interpreting consensus by clearly indicating your opinion (e.g. by using support/neutral/oppose templates). We are aware of en:WP:NOTVOTE, but given that we are facilitating this discussion with users from different wikis, potentially commenting in their native language, clearly indicating your position helps us avoid misunderstandings.

Thank you for participating! --Johannes Richter (WMDE)（留言） 2026年3月19日 (四) 11:40 (UTC)

Having domain names would be a great idea to identify sources. However, reference types may not help a lot, as a lot of online news media are being classified as web. (Or we could make web the default and not emit any type strings, both would work.) For journals and other works with machine-readable author names, the author's name would also be great, though please note that the Chinese Wikipedia uses the author field instead of first and last for authors with Chinese names. A machine-generated ID may remain anyway to eliminate any chances of duplications.--1F616EMO（喵留言～求助？） 2026年3月19日 (四) 14:38 (UTC)

Oh, forgot the template thing - overall (＋)支持.--1F616EMO（喵留言～求助？） 2026年3月19日 (四) 15:07 (UTC)

Thanks for your feedback! It would be up for the zhwiki community to define which template fields should be used for automatic reference names – that could include a fallback chain of different parameters if the preferred one isn't used in a citation.--Johannes Richter (WMDE)（留言） 2026年3月19日 (四) 16:39 (UTC)

Adding {{rfc}} template per title. 浅村しき（留言・签名） 2026年3月21日 (六) 07:05 (UTC)

誠邀參與Wikipedia:防滥用过滤器/过滤器请求§修复过滤器101的討論

誠邀參與Wikipedia:防滥用过滤器/过滤器请求§修复过滤器101的討論。
請勿回覆此討論通知。若希望就討論主題提出意見，請至該討論串提出；若對本通知有所疑問，請前往我的用户页。

--象象🐘(留言|貢獻) 2026年3月19日 (四) 16:32 (UTC)

2026年第13期技術新聞

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

本週要聞

• 現在，維基媒體網站使用者可以使用通行密鑰（passkeys）無需密碼即可登入。這是一種支援指紋、臉部辨識和PIN碼的安全登入方式。隨著這項變更，所有選擇無密碼登入的使用者，將能更加便捷、快速、安全地使用任何裝置登入帳號。目前，新的通行密鑰登入選項會以「自動填入建議」的形式出現在使用者名稱欄位中。不久後，將為已註冊通行密鑰的使用者提供額外的「使用通行密鑰登入」按鈕。此更新將提升安全性與使用者體驗。參看螢幕錄影影片逐步演示無密碼登入的流程。
• 3月25日，所有維基媒體站點將進入唯讀狀態幾分鐘，預定於15:00 UTC開始。這是資料中心伺服器切換備份測試的必要程序，每年執行兩次。切換作業期間，所有維基媒體網站流量將從主要資料中心轉移至備援資料中心，以測試系統可用性，並確保即使面臨突發狀況，服務依然能維持不中斷。

近況更新 - 面向編輯者

• 維基媒體網站的使用者現在可以透過新的Toolforge工具，匯出超過5年的通知。這將確保使用者能保留重要通知，並避免因先前公告的變更計畫——刪除超過5年的通知——而導致通知遺失。 [11]
• 土耳其語、印尼語、泰語、簡單英語維基百科的編輯者，現已可使用Special:PersonalDashboard。這是該功能的早期版本，旨在引導新編輯者熟悉巡查工作流程，協助他們更容易從編輯工作，過渡到參與專案中的進階維護管理工作。 [12]
• Special:Block頁面有兩項小幅介面調整。管理員現可透過「期限」區塊中的專用單選鈕，輕鬆執行無限期封鎖。此外，選擇「無限期」時，系統會提供另一組常見理由供選擇，可在以下頁面修改：MediaWiki:Ipbreason-indef-dropdown。 [13]
• 得益於Growth團隊最近的更新，多個維基站點的行動版編輯者現在可以看到經過改進的「未登入編輯」警告。這些於上週發布的變更，是我們持續努力和測試的一部分，旨在提升行動端的帳號建立體驗，進而增加參與度。 [14]
• 上週有36件由社群提交的工單得到解決。 例如，之前行動版網頁使用者在受到多重封鎖影響時無法查看封鎖資訊，現已修正此問題。現在，當他們瀏覽維基百科時，可查看所有目前影響他們的封鎖的相關訊息。

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

• 使用Toolforge建立的映像檔即將升級至新版建構包，此版本將支援較新的語言版本，並包含其他上游的改進與修正。如果您使用Toolforge建構服務，請查閱最近的cloud-announce電子郵件，並視需要更新您的建構配置，以確保您的工具相容。 [15][16]

• API Portal這一說明文件維基將於2026年6月關閉。在API Portal上建立的API金鑰將繼續正常運作。api.wikimedia.org端點將自2026年7月起逐步停用。API Portal上的文件將移動至MediaWiki.org。了解更多。
• 本週軟體更新細節： MediaWiki

深入了解

• WMDE技術願望專案正在考慮改進視覺化編輯器中自動生成的參考名稱（name=）。請查看解決方案提案，並參與意見徵詢。

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

MediaWiki message delivery 2026年3月23日 (一) 16:48 (UTC)

Phase 2: Reading lists results and scaling

大家好，

我們曾於去年11月分享讀者體驗團隊正在進行一項實驗，旨在將閱讀清單功能引入桌面和行動網頁瀏覽器體驗。現在，我們帶來了最新的進展和後續步驟。

Mockup of saved articles page on desktop English Wikipedia

由於維基百科的頁面瀏覽量下降，且回訪用戶的數量減少，我們正在嘗試改進讀者體驗。我們認為，透過加強現有讀者與維基百科之間的聯繫，可以幫助扭轉這一趨勢，並吸引潛在的未來編輯者。建立這種聯繫的其中一種方法是為讀者提供更多塑造閱讀體驗的方式。閱讀清單功能將允許登入使用者將希望要稍後閱讀的文章儲存到清單中，並在其帳戶中存取該清單，從而實現這一目標。該功能在維基百科應用程式上已被廣泛使用，並有助於提高讀者留存率。

實驗於11月在阿拉伯語、中文、英語、法語、印尼語和越南語維基百科上線，我們在行動裝置和桌面端收集了為期八週的數據。實驗包括：

• 已登入的用戶可將文章儲存到個人清單以便稍後閱讀。
• 已登入的用戶可以存取其清單，同時可以刪除不再相關的文章。

我們發現了什麼？

此功能的用戶參與度良好。我們的主要成功指標是「儲存文章」圖示的點擊率 (CTR)。點擊率衡量讀者與該功能的互動頻率，幫助我們了解用戶是否注意到並選擇使用此功能。典型的網頁點擊率在 1% 到 5% 之間，但對於需要用戶主動參與的功能，點擊率可能會低得多。在英文維基百科的閱讀清單實驗中，我們觀察到「儲存」按鈕的點擊率為 0.88%。這符合我們對該功能的預期。由於保存文章反映了用戶透過參與而產生的特定意圖——稍後返回閱讀該文章——我們並不預期其參與度能與更一般的導航操作相提並論。

讀者會建立帳號，但需要以閱讀為核心的功能來維持他們的留存。我們的實驗刻意僅限於非編輯者讀者群中的一小部分，以免干擾現有的編輯與審核工作流程。因此，實際看到該功能的人數極少，導致實驗功能的曝光率過低，無法就網頁上的閱讀清單如何影響用戶留存提供確鑿的證據。這項發現對我們頗具啟發：目前，不參與編輯的讀者通常沒有太多理由保留帳號，因為維基百科上多數需登入的功能都是為編輯者設計的。這項測試幫助我們更深入理解，以讀者為核心的功能如何觸及一類與編輯者互動模式截然不同的帳號持有者群體。因此，在全面推廣之前，我們正在測試該功能的測試版，以便我們能夠針對更廣泛的用戶群體，深入了解該功能對用戶留存率的影響。

閱讀清單用戶都是活躍的讀者。此外，我們發現使用此功能的讀者，其內部跳轉率明顯更高——也就是說，他們更頻繁地瀏覽維基百科上的其他頁面。雖然這種關係是屬於相關性而非因果關係，但這表明，那些原本就傾向於花更多時間探索維基百科的讀者，特別看重這項功能。

我們下一步是什麼？

基於上述結果，我們認為閱讀清單是讀者感興趣的功能，並且希望收集更多關於用戶如何使用該功能的數據。為此，我們計劃在桌面版和行動版網站上以測試版的形式向已登入的用戶推出閱讀清單功能。

為了提高閱讀清單的曝光率，我們將為所有新註冊用戶啟用測試版功能。現有用戶可以在用戶偏好設定的測試版部分手動啟用閱讀清單功能。我們將透過快速調查收集測試版用戶的回饋，以了解他們是否認為該功能有用。

我們的計劃時間表如下：

• 4月6日當週：在阿拉伯語、中文、法語、印尼語和越南語維基百科上發佈此功能。
• 4月6日至20日：觀察並修復所有錯誤。
• 4月20日當週：發佈至所有其他語言的維基百科。

我們鼓勵您試用測試版功能，並透過維基百科頁面或問卷調查向我們提供回饋。此外，我們同時希望聽到您的意見。您是否基於這些資訊對閱讀清單功能有其他想法？請在此分享您的想法和問題。如希望了解更多信息，請訪問我們的專案頁面。

謝謝。EBlackorby-WMF（留言） 2026年3月24日 (二) 18:19 (UTC)