跳转到内容

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

添加话题
维基百科,自由的百科全书

本頁用作讨论在编辑时遇到的技术问题;發表問題或討論前,請先參閱常見問題解答帮助信息MediaWiki基本問題及搜索舊討論記錄。另請注意:

請注重礼仪、遵守方針與指引,一般問題請至互助客棧其他區知识问答提出,留言后请务必签名(点击 )。
發表前請先搜索存档,參考舊討論中的内容可節省您的時間。
公告欄
# 💭 話題 💬 👥 🙋 最新發言 🕒 (UTC+8)
1 提議:高亮哈佛参考文献格式短鏈指向的完整資料引用 60 10 MilkyDefer 2026-03-25 22:58
2 改善字体的讨论怎麼又死了 18 9 魔琴 2026-03-19 07:02
3 Request for Comment: VisualEditor automatic reference names 5 3 ShuQizhe 2026-03-21 15:05
4 Wcam-bot自动存档修复 11 3 Linxingjun 2026-04-07 15:03
5 2026年第15期技術新聞 1 1 MediaWiki message delivery 2026-04-07 00:16
6 2026年第16期技術新聞 4 4 SunAfterRain 2026-04-15 03:05
7 提請互助客棧方針及條目探討版存檔機器人拒絕執行存檔至多處的指令 4 2 Shizhao 2026-04-16 10:56
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時,
請先檢查設定是否有誤

正在廣泛徵求意見的議題

議題清單

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

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

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)
Wikipedia:互助客栈/方针 § 新增RSP命名空间或伪命名空间

最近WP:RSPWikipedia:可靠来源/常见有争议来源列表)改用分页格式。RSP分页多,而且常(?)在社群讨论中引用,应该考慮统一的快捷方式(捷徑)。设置一個伪命名空间可以方便链接,避免快捷方式衝突(比如英维RSP有一些链接是WP:RSP开头,比如WP:RSPANI)。

此外,我想到或许可以设置为「真」命名空间,这樣也不用麻烦建重定向了,还能避免繁简问题。如果需要给各页面设置NOINDEX的话也能顺便设置。之前獨立格式手冊爲單獨命名空間的反對意見包括會分散方針指引,但是RSP並非方針指引,所以沒有這方面的問題。命名空间中文名称我提议为「信源评估/信源評估」。 ——魔琴留言 贡献 PJ:小學 PJ:兩岸 2026年4月2日 (四) 14:01 (UTC)
Wikipedia talk:联络我们/封禁 § 关于unblock-zh.org
现在unblock-zh.org已经运行很久,但这一页面上的封禁申诉和IPBE申请的方式仍然未被更新,因此本人提议在“通过向 unblock-zh邮件列表发邮件提交封禁申诉”下方增加一行字:“在unblock-zh上创建解封工单。”同理,在“如阁下正使用代理且没有账号”下方增加一行字:“在unblock-zh上请求代为注册账号或授予IP封禁豁免权。”当然,具体的措辞可以再调整。--Ascchrvalstr留言) 2026年4月3日 (五) 20:37 (UTC)
Wikipedia talk:可靠来源/常见有争议来源列表 § 对等记录模板的逻辑重写

鄙人尝试把目前的各大页面的记录整合入Module:RSP/Data了,并通过Module:RSP/Infobox重写了信息框逻辑使其对接RSP/Data。原先的想法是打算写现在的{{Source reliability link}}视觉化Wikipedia:可靠来源/常见有争议来源列表#列表,效果如下:

由于修改模板影响数百个页面,故请求社群讨论以决定是否修改。--__( •̀ ω •́ )<✧ 2026年4月4日 (六) 14:30 (UTC)
MediaWiki talk:Blockiptext § 提议调整界面的措辞

该模板写道:只有在防止蓄意破坏,及符合方针与指引,或是用户违反封禁方针的情况下才可采取此行动。,但这句话读起来很怪异:首先,根据破坏的定义,只有蓄意损毁维基百科的行为才能被称为破坏,所以“蓄意破坏”中的“蓄意”是冗余的;其次,“用户违反封禁方针”没有“用户违反方针与指引”来得通顺。因此,我建议把这句话改为如下:

只有在防止[[Wikipedia:破坏|破壞]],或是用戶違反其它[[維基百科:方針與指引|方針與指引]]的情况下才可根据[[Wikipedia:封禁|封禁方針]]採取此行動。。--Ascchrvalstr留言) 2026年4月4日 (六) 17:10 (UTC)
Template talk:Article history § 編輯請求 2026-04-09
請求移除「撤銷資格」連結,因為VFD已決議刪除。(參數:GAR/FAR/FLR;removed)--Sinsyuan✍️祝賀臺北捷運通車30週年! 2026年4月9日 (四) 07:22 (UTC)
Template talk:Country data Hong Kong § 編輯請求 2026-04-11
| link alias-football = 香港{{{mw|}}}足球代表隊需要在“香港”后添加上{{{age|}}},否则{{fbu}}、{{fbwu}}都无法正确导向。--Cygz留言) 2026年4月11日 (六) 09:56 (UTC)
Template talk:Country data Chinese Taipei § 編輯請求 2026-04-11
| link alias-football = 中華台北{{{mw|男子}}}足球代表隊需要在“中華台北”后添加上{{{age|}}},否则{{fbu}}、{{fbwu}}都无法正确导向。--Cygz留言) 2026年4月11日 (六) 09:58 (UTC)

提議:高亮哈佛参考文献格式短鏈指向的完整資料引用

[编辑]

此已存檔的討論仍有未完的部分,因此從存檔中粘貼過來,還盼望各位有所關心。——  桁霽  ↹ 晚來天欲雪,能飲一杯無   2025年7月25日 (五) 00:47 (UTC)回复

存檔前討論

[编辑]

具體而言,點擊引用部分的的短鏈(t:sfnt: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-340Kcx36留言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喵留言回覆請ping2025年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)回复
小意见:可以写成直接字符串拼接<templatestyles src="Module:Citation/CS1/styles.css" />,因为用frame:extensionTag会生成出<templatestyles src="..."></templatestyles>,略为啰嗦。--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的应该只有<templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>这一段文本,不算太长吧。但从性能的角度说我不觉得把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的小更新(?)。
虽说在输出里加个<templatestyles />本质也是小更改,然而我会担心在没有维护者的情况下向屎山堆砌结构修改会令它滑向缝合怪(我承认这像是滑坡谬误,又没有参数变化之类的,想不到会怎么阻碍未来的铲屎者把它炸了重来,顶多需要兼顾其他使用这个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)回复
@Ericliu1912Module_talk:Citation/CS1#編輯請求_2025-08-18。--MilkyDefer 2026年3月25日 (三) 14:51 (UTC)回复
展開來說,若要轉正需要有兩步驟。
  1. 首先,將 Module:Citation/CS1/sandbox/styles.css 的草稿內容轉正; Diff了一下沒區別。
  2. 然後才能把 Module:Citation/CS1/sandbox 的內容轉正,並且需要改掉 src= 後面用引號包裹的文字(從 "Module:Citation/CS1/sandbox/styles.css" 變為 "Module:Citation/CS1/styles.css" 即對應正式頁面的名字)。我待會兒去看一下styles.css的內容是否合適。
--MilkyDefer 2026年3月25日 (三) 14:58 (UTC)回复
副知@Shizhao@Dabao qian不過這個現在是什麼情況?—— Eric Liu 創造は生命(留言留名學生會 2025年12月3日 (三) 08:57 (UTC)回复

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

改善字体的讨论怎麼又死了

[编辑]

 ——魔琴留言 贡献 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)回复

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

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.

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)回复

Wcam-bot自动存档修复

[编辑]

我感觉是我的页面代码有问题...

没办法自动存档QAQ..

附上我的两个存档页:

User_talk:Linxingjun/Feeds

User_talk:Linxingjun--Vertin,do you want to be the timekeeper? 2026年4月3日 (五) 07:00 (UTC)回复

机器人日志表明它状态正常,未出故障。观察您页面存档配置,目前Feeds是讨论彻底结束3天后(3月31日通知,至少要等到4月3日)清一次,讨论页则是距离最后讨论7天后清一次。然而最近几个月以来,您操作速度太快了,机器人还没开始干活,会话就被存好了。不妨让留言自己挂几天,或者把algo = old(7d)改小点,然后再观察一下。--逆襲のあまのじゃく天邪鬼 (留言) 2026年4月3日 (五) 12:28 (UTC)回复
我手动,单纯是因为它没办法工作
事实上差不多有好几个月了
只不过我是直到现在才有空处理这件事罢了--Vertin,do you want to be the timekeeper? 2026年4月3日 (五) 12:30 (UTC)回复
仔细检查了一下,Feeds确实有问题,比方说2月11日的版本还有几个旧讨论挂在那里。--逆襲のあまのじゃく天邪鬼 (留言) 2026年4月3日 (五) 12:44 (UTC)回复
yeah--Vertin,do you want to be the timekeeper? 2026年4月3日 (五) 12:46 (UTC)回复
@逆襲のあまのじゃく
好了,已经过了我设定的3天期限了,照样不存档
QAQ--Vertin,do you want to be the timekeeper? 2026年4月6日 (一) 09:01 (UTC)回复
也许坏了很久了,2023年9月我尝试过,就不运作。Special:Diff/79595448,用{{Auto-archive}}吧,运作正常。--YFdyh000留言2026年4月6日 (一) 09:54 (UTC)回复
谢谢,能帮忙看看我现在的配置吗--Vertin,do you want to be the timekeeper? 2026年4月6日 (一) 09:59 (UTC)回复
发现三个彼此独立的问题:
  1. Wcam-bot似乎工作异常;
  2. “好了,已经过了我设定的3天期限了,照样不存档”。这个是Linxingjun操作太快了,讨论时间戳还差几个小时,过几个小时之后可以被人工运行的pywikibot正常存档;
  3. 即便人工运行pywikibot,部分版本Special:Permalink/91481665也不会存档。这应该是pywikibot程序问题,因为他发现这个版本里有三个帖子,但没有任何讨论过期。
综上所述,可以考虑YFdyh000的建议,直接彻底解决问题。--逆襲のあまのじゃく天邪鬼 (留言) 2026年4月6日 (一) 10:04 (UTC)回复
我先召唤一下 @Wcam--Vertin,do you want to be the timekeeper? 2026年4月6日 (一) 10:06 (UTC)回复
好了,谢谢各位,已经解决了
感恩--Vertin,do you want to be the timekeeper? 2026年4月7日 (二) 07:03 (UTC)回复

2026年第15期技術新聞

[编辑]

MediaWiki message delivery 2026年4月6日 (一) 16:16 (UTC)回复

2026年第16期技術新聞

[编辑]

MediaWiki message delivery 2026年4月13日 (一) 15:16 (UTC)回复

也就是说以后改内容模型不再需要找管理员了?--碟之舞📀💿 2026年4月14日 (二) 02:56 (UTC)回复
新建页面不用,改已有页面仍然需要找。--逆襲のあまのじゃく天邪鬼 (留言) 2026年4月14日 (二) 03:57 (UTC)回复
我覺得以你維的成員,未來可能有需要把「自訂新頁面的內容模型」限縮到延伸確認用戶就是了(笑)。--SunAfterRain 2026年4月14日 (二) 19:05 (UTC)回复

提請互助客棧方針及條目探討版存檔機器人拒絕執行存檔至多處的指令

[编辑]

共識·討論的發起位置》方針就方針、條目等討論規定「討論結束後亦應讓討論原地存檔,避免重複在多個頁面存檔後出現討論分支」,意即存檔至多處的行爲「需要解釋」才可執行。因此,將方針及條目探討版的討論存檔至多處明顯不是機器人應自動執行的行爲,而應由人類編者等待提請多地存檔者的解釋並判斷是否確實有此需要。

茲提請互助客棧存檔機器人(Jimmy-bot)在方針及條目探討版拒絕執行存檔至多處的指令。由於討論分支的弊端並不限於方針、條目等討論,視乎何者較容易實作,亦不反對在任何存檔任務中拒絕執行存檔至多處的指令。機器人拒絕操作時,應在討論中留言,以通知討論參與者手動處理討論串去向,避免討論被永久掛在互助客棧上。

另一可能性是只存檔至列出的第一個討論頁,並在其餘討論頁中發放通知,以導引日後瀏覽討論頁的編者前往唯一的存檔處。由於此舉亦涉及拒絕部分用戶指令,故亦應在原討論中留言通知。此方法比較不會打擾到編者,但可能導致編者一直沒注意到相關規定,一錯再錯。

以上,通知@Jimmy Xu,並提請社羣討論。--1F616EMO喵留言求助?2026年4月14日 (二) 11:12 (UTC)回复

说的这么严重,不就是程序没开发存檔至多處的功能么...--百無一用是書生 () 2026年4月15日 (三) 07:14 (UTC)回复
印象中以往會出現由機器人存檔至多處的情況,何來「沒開發」?--1F616EMO喵留言求助?2026年4月15日 (三) 07:27 (UTC)回复
那就是机器人bug了呗--百無一用是書生 () 2026年4月16日 (四) 02:56 (UTC)回复
也許如此,也算是將錯就錯。不過建議採取上方提案其中之一而非直接存檔至第一個頁面。--1F616EMO喵留言求助?2026年4月16日 (四) 11:44 (UTC)回复