跳转到内容

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

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

快捷方式

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

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


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

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

公告栏
# 💭 话题 💬 👥 🙋 最新发言 🕒 (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被换行 25 8 Shizhao 2024-07-05 11:46
9 美国县级行政区地图显示故障 7 5 Nostalgiacn 2024-06-30 14:50
10 跨项目通知的蓝点 5 4 Ericliu1912 2024-06-26 21:21
11 有没有办法限制重定向在条目正文中的使用？ 4 4 Kanashimi 2024-06-26 06:58
12 请求修改Cite book对统一书号的支持 2 2 Nostalgiacn 2024-06-30 14:47
13 TW部分功能故障 14 5 Xiplus 2024-07-01 22:45
14 Attached KML模板的display=title显示位置有问题 2 2 Shizhao 2024-07-05 11:30
15 机器人给隐退用户发消息的情况 3 2 Nostalgiacn 2024-07-01 10:25
16 维基百科:其他语言的维基百科典范条目/英语版这样的标题是否属于繁简混用？ 3 3 Ericliu1912 2024-07-03 18:59
17 2024年第27期技术新闻 1 1 MediaWiki message delivery 2024-07-02 07:57
18 跨语言链接 4 2 暁月凛奈 2024-07-03 19:47
19 在导航模板中淘汰过时的可折叠表格支持 31 2 Dabao qian 2024-07-05 11:46
20 条目标题左侧出现多余的“维基百科” 4 3 Shizhao 2024-07-05 11:32
21 深色模式现在可供所有使用者使用！ 9 6 SickManWP 2024-07-05 12:48
22 Twinkle关闭存废讨论无法在Vector 2022使用 3 2 Sinsyuan 2024-07-05 11:42
发言更新图例
  • 最近一小时内
  • 最近一日内
  • 一周内
  • 一个月内
  • 逾一个月
特殊状态
已移动至其他页面
或完成讨论之议题
手动设定
当列表出现异常时，
请先检查设定是否有误

正在广泛征求意见的议题

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

维基百科技术议题与模板

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被换行[编辑]

本主题或以下段落文字，在讨论结束后应存档至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)[回复]
话说，修复之后，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升级后这个问题变严重了。可以参考下这个[4]，一大堆的报错--百無一用是書生 (☎) 2024年6月19日 (三) 02:25 (UTC)[回复]
举例的图片，以上传新图片解决了。不过仍然有很多图片没有上传新图片取代。如右图（Virginia）
Virginia
--Nostalgiacn（留言） 2024年6月30日 (日) 06:50 (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)[回复]

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

诸如温哥华白帽、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)[回复]

请求修改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.无法关闭是[5]（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)[回复]

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

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

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

最近更改

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

问题

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

未来更改

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

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

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)[回复]
[13]，分别是固定宽、不固定宽，使用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)[回复]

更新清单[编辑]

  2. 以上完毕了，才需要更新Module:Navbox、Module:NavboxV2的折叠参数调整。
@Dabao qian：如果理解和没异议的话，可以推进下去。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月5日 (五) 02:20 (UTC)[回复]
无异议，宽度和深色模式适配的问题后续再议（当然这不属于本次讨论范围）。--Dabao qian℡ 2024年7月5日 (五) 03:46 (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)[回复]

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

大家好，在过去的一年里，维基媒体基金会的网页团队一直致力于深色模式的开发。这项工作是无障碍阅读计划的一部分（该计划引入了对 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)[回复]

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)[回复]
取自“https://wiki.matr1x.workers.dev/w/index.php?title=Wikipedia:互助客栈/技术&oldid=83286873”