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

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

快捷方式

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

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


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

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

公告栏
# 💭 话题 💬 👥 🙋 最新发言 🕒 (UTC+8)
1 Template:Weather box 14 6 Kethyga 2024-04-26 09:30
2 MobileFrontend侧边栏故障 6 2 Shizhao 2023-12-25 15:47
3 引文模板不应该报错全部的零宽空格 5 3 Cookai1205 2024-04-24 12:58
4 “阅读无障碍”功能和本站小工具兼容问题以及字号选择 32 8 SCP-2000 2024-04-20 00:09
5 关于使用 ToolsRedirect 创建的繁简重定向 8 5 PexEric 2024-05-02 17:35
6 Cite book模板预设支援哈佛式注脚 2 1 Ericliu1912 2024-04-24 14:28
7 infobox book出现问题 9 4 Kethyga 2024-04-26 17:58
8 自动评级？ 8 5 A2569875 2024-04-26 16:56
9 首页“历史上的今天”炸了 2 2 YFdyh000 2024-04-26 01:48
10 关于褒扬令、碑文的蓝色方框的 CSS 样式建议 5 3 Chu Tse-tien 2024-04-29 09:57
11 2024年第18期技术新闻 3 3 Cookai1205 2024-05-02 13:47
12 Template:Douban people 11 3 Kcx36 2024-05-03 03:33
13 请求有能力者修改邛崃市南宝山镇的维基数据 2 2 Kcx36 2024-05-03 00:27
发言更新图例
  • 最近一小时内
  • 最近一日内
  • 一周内
  • 一个月内
  • 逾一个月
特殊状态
已移动至其他页面
或完成讨论之议题
手动设定
当列表出现异常时，
请先检查设定是否有误

正在广泛征求意见的议题

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

维基百科技术议题与模板

Wikipedia talk:字词转换处理/公共转换组 § 思路：条目预储公共转换组中匹配的规则，减少载入时间

MediaWiki talk:Common.css § 编辑请求 2023-11-20

Template talk:Twitter § Twitter改为X

Template talk:Infobox person § 修改 Infobox person 中 native_name 参数位置

Template talk:电影信息框 § 影／视 资讯框互斥、难记

Template talk:No source § 一个问题

Template talk:Hang on § {{hangon}}

条目主题
非条目主题
提示
要将某一个讨论加入上述列表中：
  • 在讨论页中的对应讨论章节顶端加上{{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)[回复]

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

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

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

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

本主题或以下段落文字，在讨论结束后应存档至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)[回复]

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

“阅读无障碍”功能和本站小工具兼容问题以及字号选择[编辑]

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

测试功能中Vector 2022的“阅读无障碍”功能之前和本站大字体小工具存在兼容性问题，目前主要问题已经修正，但是存在若干遗留问题。

该测试功能有三个挡位，“小”对应14px，“标准”对应16px，“大”对应20px，并无本站目前使用的15px。本来该功能是有望让小工具在Vector 2022下直接退役的，但由于缺少15px所以目前不行。

目前个人认为有以下解决方案，请社群评估：

  1. 维持现状（大字体小工具将“小”修改为15px，其他不变）。
  2. 让大字体小工具在打开“阅读无障碍”时直接失效，之后在正式部署“阅读无障碍”时调整为默认启用16px，小工具退役。注意会导致默认字号改变。
  3. （新增）让基金会加上15px的挡位，正式部署时默认启用，小工具退役。

以上。--碟之舞📀💿 2024年2月23日 (五) 02:13 (UTC)[回复]

我个人会倾向2。--冥王欧西里斯（留言） 2024年2月23日 (五) 03:56 (UTC)[回复]
@S8321414：刚刚加了个3，提醒一下。--碟之舞📀💿 2024年2月23日 (五) 13:36 (UTC)[回复]
有看到，但我个人还是倾向2，但不排斥3。--冥王欧西里斯（留言） 2024年2月23日 (五) 13:59 (UTC)[回复]
阅读方面14px和15px我感觉都行，但排版变化明显。顺便一提，Timeless皮肤下是15.2px。16px感觉较大，但部分用户和繁体用户可能偏爱。--YFdyh000（留言） 2024年2月23日 (五) 14:02 (UTC)[回复]
依据“阅读无障碍”功能的文档“Small is the current default”，而本站预设启用“大字体”小工具及实际上本站预设字体为 15px 而非 14px，故“小”选项应由现时的 14px 增加至 15px，或是增加 15px 的选项及成为预设选择。至于“大字体”小工具，当“阅读无障碍”功能仍在测试阶段时应改为不覆盖该功能字体设定，待该功能正式部署后才仅在 Vector 2022 暂停使用。谢谢。--SCP-0000（留言） 2024年2月23日 (五) 15:22 (UTC)[回复]
另外，没坏就不要修，除非有明确共识或证据支持其他字体大小比现时预设的 15px 更佳。--SCP-0000（留言） 2024年2月23日 (五) 15:30 (UTC)[回复]
“小”选项由现时的 14px 增加至大字体的 15px，大家不觉得这让很多人难以理解吗？小变成了大，但却还是叫做小。。。
总的来说，15px是中文网页（可能也包括日文网页）最常见的字体大小（可认为是最优），但是随着近几年显示技术和网页技术的变化，是否15px还是最优可能需要再探讨。另外，偶数大小（14、16）从网页设计上来说更方便计算和取整，可以避免一些页面排版和渲染方面意外的发生。所以最后还是要权衡利弊，是保守原来的不变，还是拥抱新变化，还是只要最优大小，还是虽然不是最优但能够更灵活？--百無一用是書生 (☎) 2024年2月26日 (一) 02:27 (UTC)[回复]
更新：Jon (WMF)表示可以针对不同语言调整预设值大小。--碟之舞📀💿 2024年2月24日 (六) 02:21 (UTC)[回复]
那正好，基于最小修改原则，新版外观预设字体大小应该就设定为原本者。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年2月25日 (日) 16:52 (UTC)[回复]
@SGrabarczuk (WMF): BTW, I have read the analysis of the community prototype testing and I found that the analysis mixed up the data from communities using Latin and CJK characters. Since Latin and CJK is quite different (FYR the comparison by Google), perhaps re-analysis and only focus on the data from communities using CJK character (Chinese, Japanese, and Korean Wikipedia) if possible? Thanks.--SCP-0000（留言） 2024年2月28日 (三) 05:39 (UTC)[回复]
Hey @SCP-2000, that's interesting, thank you for pointing this out! Our designer broke down that data by different scripts. So he must have taken this into consideration. But as I can see, this breakdown didn't make it to the wiki page. I'll ask him.--SGrabarczuk (WMF)（留言） 2024年3月6日 (三) 16:22 (UTC)[回复]
@SGrabarczuk (WMF): Hello, any update of this matter? Thanks.--SCP-0000（留言） 2024年3月24日 (日) 17:23 (UTC)[回复]
Hello @SCP-2000, I'm happy to share that I do have an update :D
Ultimately, it will be possible for local users (specifically, admins, if I'm not mistaken) to change the settings (only by increasing the values) for the entire wiki. This will be possible via the Community configuration tool. It was originally built for newbies and mentors, but it's gonna be connected with other features as well.
In the meantime though, our team will be happy to make those changes for you.
However, if I'm not mistaken, it will not be necessary since our proposed new default ("Standard", 16px) is a bit larger than the current default on this wiki (15px). Am I forgetting about something?
What do you think about all this? Thanks!--SGrabarczuk (WMF)（留言） 2024年3月29日 (五) 22:37 (UTC)[回复]
@SGrabarczuk (WMF): Hello, thanks for your information:)
We are currently in a discussion about which font size (i.e. 14, 15 or 16px) is better. That was why I asked if there is any data from communities using CJK characters, so that help us make a better decision. Anyway, we'll let you know if we reach the consensus.--SCP-0000（留言） 2024年3月30日 (六) 12:31 (UTC)[回复]

@Diskdance、S8321414、YFdyh000、Shizhao、Ericliu1912： 考虑到现时未见有广泛共识同意更改预设字体大小，个人认为较佳的做法是维持现况（即 15px）。而 WMF 愿意依据社群意见更改字体大小，故个人建议将 Vector 2022 未来的预设“标准”选项（ “our proposed new default ("Standard", 16px)”）改为本站现时的 15px。至于“大字体”小工具，当“阅读无障碍”功能仍在测试阶段时改为不覆盖该功能字体设定，待该功能正式部署后才仅在 Vector 2022 暂停使用。不如各位意下如何？谢谢。--SCP-0000（留言） 2024年3月30日 (六) 12:59 (UTC)[回复]

个人支持SCP所述做法。但是需要考虑是否要相应调整“大”选项的字号。--碟之舞📀💿 2024年3月30日 (六) 13:13 (UTC)[回复]
所以现在是变成要把“标准”改为15px而非把“小”改为15px？我个人仍是比较倾向让这三个选项维持原本的14、16、20px，让小工具在Vector 2022失效，但也不反对将“标准”改为15px就是（是说原本选15px究竟是什么原因？）。--冥王欧西里斯（留言） 2024年3月30日 (六) 13:27 (UTC)[回复]
“所以现在是变成要把“标准”改为15px而非把“小”改为15px？”是的，这是基于维持现况的考量。而“标准”未来将成为预设选择。
“我个人仍是比较倾向让这三个选项维持原本的14、16、20px，让小工具在Vector 2022失效”或许能否详细说明理由？谢谢。--SCP-0000（留言） 2024年3月30日 (六) 13:33 (UTC)[回复]
主要是现在用“阅读无障碍”的“标准”也没遇到什么排版上的问题，另外没那么重要的应该是跨站点的一致性，至于“大字体”小工具在“阅读无障碍”功能预设开启后（在Vector 2022）就不需要了。--冥王欧西里斯（留言） 2024年3月30日 (六) 13:44 (UTC)[回复]
理解。大字体那句是不小心引用的（）。至于跨站点的一致性，这确实是合理的担忧，不过只要本站愿意作出改动，个人认为其他使用中文的 wikis 也会跟进改动。至于中文以外的 wikis，正如您所说其实不太重要。谢谢。--SCP-0000（留言） 2024年3月30日 (六) 14:02 (UTC)[回复]
现在中文站点的字号设定并不完全相同，所以我反而不觉得其他中文站点会跟进本站改“标准”为15px就是XD，毕竟改了反而也是跟原先的排版不同。--冥王欧西里斯（留言） 2024年3月30日 (六) 23:26 (UTC)[回复]
原本选15px是因为当时中文网页字体大小的最佳实践是15px--百無一用是書生 (☎) 2024年3月31日 (日) 12:09 (UTC)[回复]
那就是看现在的最佳实践是不是还是15px了。--冥王欧西里斯（留言） 2024年3月31日 (日) 12:14 (UTC)[回复]
啊，“最佳实践”我在这里是有点反讽的意思的....意思就是别人都这么做，所以这么做，效果上是不是“最佳”则未必，但成本上肯定是“最佳”的--百無一用是書生 (☎) 2024年4月8日 (一) 03:21 (UTC)[回复]
既然此讨论已过一个月多，而本提案已过七天且无合理异议，故现公示七天，如无合理异议即视达成共识及通过。谢谢。--SCP-0000（留言） 2024年4月7日 (日) 16:01 (UTC)[回复]
  • 根本就不是这问题，是这个基金会本身的问题。强迫人换成Vector 2022的皮肤外观不说，还要登入使用者的账号才能选择，跟字体大小可能没什么影响了，字体大小也不是决定条目质量的主要因素，而且一堆多余空白就影响阅读品质。再说，为何不自己用缩放功能调整字体大小就好？真的懒成这样吗？--Z7504非常建议必要时多关注评选（留言） 2024年4月18日 (四) 14:10 (UTC)[回复]
    良好的网站设计不应要求使用者透过缩放功能来调整字体大小，而字体大小确实会影响读者的阅读品质（参见相关研究）。至于预设选项及空白的问题，与本讨论无关，个人便不评论。谢谢。--SCP-0000（留言） 2024年4月18日 (四) 16:13 (UTC)[回复]
    字体大小的确是会影响读者的阅读品质，但哪些读者是真的会管您维基百科要是14px还是15px的大小啊？讲这个几px大小也不是维基百科所有的读者都能一目了然。基金会也没有要发明这个功能啊？为啥不给维基百科本身阅读时能自己决定字体大小的功能建议比较快？电脑有缩放字体功能，手机也有缩放萤幕大小的功能，那字体显示的大小当然是取决自己要不要去决定而已。（独裁）基金会做为一个维基百科全书网页始祖之一，却连这点功能都办不到，那和其他网络百科全书基本差不多功能而已，就（独裁）社群的维基百科功能性而言，没有比较突出。与其讨论字体选择性功能，真的建议直接看看这个（独裁）基金会的意愿吧，（独裁）社群光只在互助客栈这讨论半天是没有屁用的。--Z7504非常建议必要时多关注评选（留言） 2024年4月18日 (四) 17:04 (UTC)[回复]
    相信做过网站开发和应用系统设计工作的，绝不会说出这种不专业的话--百無一用是書生 (☎) 2024年4月19日 (五) 03:29 (UTC)[回复]
既然没有合理且与本提案相关的异议，视为达成共识及通过。个人稍后将建立相关工单。谢谢。--SCP-0000（留言） 2024年4月19日 (五) 07:35 (UTC)[回复]
已建立 phab:T362995。
@SGrabarczuk (WMF)： Hello, we agree that change the "Standard" font size from 16 to 15px in Chinese Wikipedia. More information in this phab ticket. Thanks.--SCP-0000（留言） 2024年4月19日 (五) 16:09 (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)[回复]

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

Cite book模板预设支援哈佛式注脚[编辑]

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

有关该模板预设支援哈佛式注脚事，显然社群已有共识，只是不知如何部署，希望有人能够协助指明。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月24日 (三) 06:27 (UTC)[回复]

或可先引进HarvErrors.js做本地系统小工具之一，以为过渡。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月24日 (三) 06:28 (UTC)[回复]

infobox book出现问题[编辑]

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

敝人在光明的花园中发现自动关联到维基数据的oclc参数显示异常（本应显示一串oclc数字，但实际上显示成了“[https://classify.oclc.org/classify2/ClassifyDemo?search-standnum-txt=6451669&startRec=0 6451669]”，请求修复。----FradonStar|八闽风云 2024年4月25日 (四) 05:29 (UTC)[回复]

@BlackShadowG：Special:Diff/82253933的改动原因？--YFdyh000（留言） 2024年4月25日 (四) 06:02 (UTC)[回复]
另外，看了一下d:Property:P5331，该属性对应的网站于2024年1月停止了服务（“Classify was discontinued on 31 January 2024”），BlackShadowG替换的网址对应的应该是d:Property:P243。或许应该直接将P5331替换成P243？--Kethyga（留言） 2024年4月25日 (四) 06:53 (UTC)[回复]
英维en:Template:Infobox book的OCLC对应的网址即BSG填写的网址，建议清理之前可能使用到P5331的条目，P5331感觉没什么用。--Kethyga（留言） 2024年4月25日 (四) 07:01 (UTC)[回复]
 已修复，原来维基数据返回的值带有内链，导致无法嵌入在外链中；我已经改为返回原始值，现在可以正常显示了。抱歉之前没有检查这一点。——BlackShadowG Slava Ukraini! 2024年4月25日 (四) 13:36 (UTC)[回复]
实际上并未完全修复，{{Infobox book}} OCLC处目前使用的值是P5331，而新增加的网址（https://www.worldcat.org/oclc/）实际对应的是P243的值。上述条目光明的花园 (79806831)中OCLC 6451669目前指向的Conversa-phone Malay language course是一部音乐唱片，OCLC 1345622270 对应的才是Les jardins de lumière : roman（光明的花园）--Kethyga（留言） 2024年4月26日 (五) 01:13 (UTC)[回复]
这个或许是维基数据的OCLC编码写错了？----FradonStar|八闽风云 2024年4月26日 (五) 05:41 (UTC)[回复]
已在维基数据页面把OCLC编码调整为正确数值，但在维基数据页面仍然打不开那个已经崩坏于2024年1月的那个网站_(:з」∠)_----FradonStar|八闽风云 2024年4月26日 (五) 05:47 (UTC)[回复]
那个维基数据不改该，因为那是P5331（OCLC classify/work）的值，不是P243（OCLC控制号）的，改的是错的。需要修改的是Infbox book。--Kethyga（留言） 2024年4月26日 (五) 09:58 (UTC)[回复]

自动评级？[编辑]

本主题或以下段落文字，在讨论结束后应存档至Module talk:PJBSClass/main、Talk:台湾的大麻。

我在Talk:台湾的大麻放置专题模板，只填了低重要度，却自动被评为小作品级，这是怎么回事？--世界解放者（留言） 2024年4月25日 (四) 13:29 (UTC)[回复]

分类:自动评级的页面。具体机理没看懂。--YFdyh000（留言） 2024年4月25日 (四) 18:04 (UTC)[回复]
因为条目本身挂了{{Taiwan-stub}}。Irralpaca（留言） 2024年4月25日 (四) 20:55 (UTC)[回复]
@Irralpaca：并不是，见下。评级模板并不读取小作品模板。小作品模板太多命名太乱运算成本高。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月25日 (四) 22:29 (UTC)[回复]
原来如此，makes a lot of sense. --Irralpaca（留言） 2024年4月25日 (四) 22:36 (UTC)[回复]
@YFdyh000、世界解放者：Module:PJBSClass/main#维基代码可判断的评级值，这是2024年1月8日 (一) 04:40 (UTC)通过的修订案。如果已非小作品，您可以手动填入|class=其他评级值来覆盖自动评级（范例：Special:Diff/82397467）。主要是引进了这个机器人User:Cewbot/log/20200122/configuration，评级系统八成自动化了。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月25日 (四) 22:29 (UTC)[回复]
既然说到自动评级的问题，那不知条目评级的那个脚本能否进行调整，以适应现在讨论页挂的新的评级模板？（就是Cewbot修改后的模板形式）----FradonStar|八闽风云 2024年4月26日 (五) 05:44 (UTC)[回复]

首页“历史上的今天”炸了[编辑]

本主题或以下段落文字，在讨论结束后应存档至Wikipedia:历史上的今天/4月26日。

看图（我开启了“首页以本地时间显示。已登录用户以参数设置页面“外观”中的“时差”设置确定，未登录用户以系统时区确定。”）

File:临时图片，修复好就删.png

--Dnaimfz（留言） 2024年4月25日 (四) 17:00 (UTC)[回复]

已获修复--YFdyh000（留言） 2024年4月25日 (四) 17:48 (UTC)[回复]

关于褒扬令、碑文的蓝色方框的 CSS 样式建议[编辑]

目前在维基百科上，获中华民国褒扬令的人物往往会在其页面上刊出褒扬令全文，并以蓝色方框（实现方法为一个加了蓝色实线 border 的 <blockquote>）框之。其他的一些人物的碑文可能也采取这样的做法。

但很经常地，这样的方框的右侧部分会和页面右侧边的其他资讯方块相重叠，导致方框不能显示完全，有时还会使内容发生诡异的换行效果。

现状参考：许虞哲、吴新荣。

要解决这一问题其实很简单，只消为 <blockquote> 添加一个 display: flex; 的 CSS 样式，并将其内的所有内容包在一个 <div></div> 里即可。这样方框就不会与页面上的其他元素重叠了（同时内嵌的 <div> 确保了 <blockquote> 内的内容不会出现排印错误）。

不知道大家是否认可这样的修正，以及是否有技术能人愿意写一段指令码来批次化执行这一修改。

再者，在含有褒扬令的篇目中，落款的总统、行政院院长部分其实也最好采用表格的方式去实现，以获得更好（保证对齐）的排印效果。如下方这般： 

<blockquote style="border: 1px solid blue; padding: 0.5em 0.8em; display: flex;">
<div>
財政部前部長、臺灣期貨交易所股份有限公司董事長許虞哲，洽聞沖簡，素德清材。少歲卒業國立政治大學財稅學系暨財政研究所，旋負笈遊美，獲哈佛大學法學碩士學位，抱志懷才，濬瀹專攻。歷任臺北市稅捐稽徵處處長、五區國稅局局長暨賦稅署署長等職，張拓各項稽徵事宜，調降最高邊際稅率；實施證券交易所得課稅，營造優質租稅環境，折衝圖議，幹濟有聲。尤以出任財政部次長、部長期間，整合通關航港系統，研提電子發票載具；踐履開源節流要旨，置辦跨境電商稅制；釐訂國有財產法規，增益公共建設量能，極智窮思，振裘持領；迴籌轉策，通觀全局。嗣接掌臺灣期貨交易所，博求多元商品創新，簡化交易結算程序；加強風險控管措施，推升期貨市場榮景，謨慮運帷，蜚英騰茂。曾獲頒財政部一、二等財政獎章暨模範公務人員等殊榮。綜其生平，殫瘁臺灣稅務體系興革，丕奠國家財政發展利基，訏猷遠謀，令績遐舉；行誼世範，楷模垂芬。遽聞溘然殂殞，悼惜彌殷，應予明令褒揚，用示政府篤念邦賢之至意。
{| align="right"
| 總　　　統
| style="padding-left: 1em;" | [[蔡英文]]
|-
| 行政院院長
| style="padding-left: 1em;" | [[蘇貞昌]]
|}
</div>
</blockquote>

如果总统、行政院院长的区块需要与右边框留出一点距离，则可简单地在表格部分首行 align 属性右边添加右 margin 样式即可，这些都比如今使用的解决方案能够更好地保证排印效果（当然“总统”字样间的空格理论上亦可透过为“总”字添加 letter-spacing 来解决，也即写成 <span style="letter-spacing: 3em;">总</span>统 的样子，但就不如直接加入全形空格方便了）： 

{| align="right" style="margin-right: 2em;"
| 總　　　統
| style="padding-left: 1em;" | [[蔡英文]]
|-
| 行政院院長
| style="padding-left: 1em;" | [[蘇貞昌]]
|}

--Boreas Sawada 2024年4月27日 (六) 03:49 (UTC)[回复]

建议不错，可以考虑建模板以规范显示效果。不过我有点怀疑刊出全文的正当性，原因有三：一，这难道不应该移至文库？二，所举条目吴新荣中这样的碑文不侵权？三，条目中以大篇幅给出褒扬令、纪念碑文全文有广告宣传之嫌，这要是大陆人物恐怕早就被移除了[开玩笑的]。--Kcx36（留言） 2024年4月28日 (日) 18:59 (UTC)[回复]
Well… 我是一个“惯例主义者”（如果真的有这种东西的话），因此推崇尊重惯例 (convention)，尤其是在一个社群／社会上自发演化形成的惯例。（同时我也了解到中文维基并不推崇此类思想。）因此在如诸如此类的讨论上会天然地偏向于“维持现状、保持不变”。所以我不适合参与“改制”的讨论。对此就不发表意见了。
编辑：由于楼下误会，我特此声明：前段之回应与是否应当为褒扬令等蓝色框文字建立模板无关。是回应有关这类文字是否应该保留的部分的。--Boreas Sawada 2024年4月28日 (日) 21:57 (UTC)[回复]
  • @Chu_Tse-tien：(：)回应：建模板并非是因为“它是惯例”而建的。建模板是指如果有存在某种格式、文字、或可（依条目主题）被程式运算的东西（见{{数字性质}}，已被广泛地用来产生数字条目中的部分条目内容）、板型或模式等内容出现在了在多个条目，又或会在同一条目还会重复出现，则宜“模板化”方便管理（不然到时你改一个，要全部条目都改一遍；模板化了就只要改模板）。如果“褒扬令、碑文”出现在许多条目，且其样式（如CSS等）类似，则宜模板化。因此，并非因为“它是惯例”才建模板，而是很多条目都有相同东西，才“统整”成模板方便管理。因此建模板也算是“维持现状、保持不变”但加上“技术上”的东西来方便进行“管理与维护”，并不变更其内容。毕竟如果某件事“它是惯例”宜“整合管理”减少人力负担，并不意味着“不维持现状、没有保持不变”。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2024年4月28日 (日) 22:37 (UTC)[回复]
    这……我回应的显然不是关于建立模板的部分……--Boreas Sawada 2024年4月29日 (一) 01:57 (UTC)[回复]

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

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

最近更改

讨论页视觉改进的截图
采用新设计的讨论页的示例，图为法语维基百科
  • 下列维基的讨论页外观已更改：阿塞拜疆语维基百科、​孟加拉语维基百科、​德语维基百科、​波斯语维基百科、​希伯来语维基百科、​印地语维基百科、​印尼语维基百科、​韩文维基百科、​荷兰语维基百科、​葡萄牙语维基百科、​罗马尼亚语维基百科、​泰语维基百科、​土耳其语维基百科、​乌克兰语维基百科、​越南语维基百科。这些维基参与的测试为期一年，其中有50%的用户使用了新设计。由于测试结果良好，新设计已作为默认设计部署至这些维基。用户可以在参数设置中选择停用这些更改（“显示讨论活动”）。未来几周内，所有维基均将进行部署。 [2]
  • 七个新的维基已创建：
  • 您现在可以在Translatewiki.net上监视消息组或项目。起初，此功能会通知您这些群组中新增或删除的消息。 [10]
  • 深色模式现在可供所有维基的已登录用户在移动版网站使用，须启用高级模式。这是该功能的抢先发行版。邀请技术编者检查各维基的无障碍问题。参见详细指南。

问题

  • 属性值mapstyle="osm"可让Kartographer地图使用不带地名标注的替代视觉样式。这原本在预览中不起作用，造成它不受支持的错误印象。此问题已解决。 [11]

本周更改

  • MediaWiki的新版本将于4月30日部署至测试维基及MediaWiki.org，于5月1日部署至非维基百科wiki及部分维基百科，并于5月2日部署至所有站点（参见日程表）。 [12][13]

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

MediaWiki message delivery 2024年4月30日 (二) 03:32 (UTC)[回复]

深色模式兼容性本站可以做起来了。--碟之舞📀💿 2024年5月1日 (三) 04:59 (UTC)[回复]
我有提了一些编辑请求，有一些应该有更好的改法，欢迎提出。--Cookai饼块🍪（💬留言） 2024年5月2日 (四) 05:47 (UTC)[回复]

Template:Douban people[编辑]

发现豆瓣电影、豆瓣读书、豆瓣音乐的人物页面目前开始跳转到Douban personage（豆瓣人物）页面，比如蒲松龄豆瓣读书页面跳转到27504363，估计需要一个新的{{Douban personage}}，可能需要将movie/book/musician中的标识符转移到personage上。另外维基数据上在申请建立Douban Personage ID。--Kethyga（留言） 2024年4月30日 (二) 23:42 (UTC)[回复]

我觉得{{douban}}加一个personage参数比较好。--YFdyh000（留言） 2024年5月1日 (三) 01:17 (UTC)[回复]
纠正，我是想说{{douban people}}加personage参数--YFdyh000（留言） 2024年5月1日 (三) 18:19 (UTC)[回复]
不对吧，豆瓣网站改版后人物页面不再分电影、读书、音乐，模板只需要id、title两个参数。--Kcx36（留言） 2024年5月2日 (四) 16:32 (UTC)[回复]
旧的网址目前被重定向、豆瓣电影搜索中仍呈现，有用，模板应保留功能。前些天还有些没重定向，但现在似乎越来越多/全面。如果配合机器人，可以将douban people未指定type默认为movie，改动成默认personage。机器人可以经重定向添加personage值到维基数据。--YFdyh000（留言） 2024年5月2日 (四) 17:40 (UTC)[回复]
我建议用机器人将未填写type的补全type=movie，模板功能改为未指定type则默认personage，type参数不再推荐使用，仅为兼容保留。然后将模板改名为“Douban personage”，而无需建两套模板。--Kcx36（留言） 2024年5月2日 (四) 18:09 (UTC)[回复]
机器人补全type，不如去掉参数自动读维基数据。当然，要确保最终网址正确有效。--YFdyh000（留言） 2024年5月2日 (四) 19:00 (UTC)[回复]
您是说不填type时自动读维基数据的personage ID，还是去掉所有参数，自动读维基数据的personage ID？有的条目，如蒲松龄，使用了多个模板。--Kcx36（留言） 2024年5月2日 (四) 19:11 (UTC)[回复]
去掉所有参数，因为其他type的页面似乎将不再提供服务。该条目为例，多个模板的最终页面现为同一个页面。--YFdyh000（留言） 2024年5月2日 (四) 19:25 (UTC)[回复]
有道理，我支持此方案。这样的话还需要补充Category:不在维基数据的豆瓣影人等的维基数据，以及去掉多次使用的模板。--Kcx36（留言） 2024年5月2日 (四) 19:33 (UTC)[回复]
“未指定type则默认personage”有个小缺点，哪怕机器人处理了所有案例，条目历史版本的效果会改变。--YFdyh000（留言） 2024年5月2日 (四) 19:32 (UTC)[回复]

请求有能力者修改邛崃市南宝山镇的维基数据[编辑]

本主题或以下段落文字，在讨论结束后应存档至Talk:南宝山镇、Talk:油榨乡、Template talk:PRC admin/list/00/00/00/000/000、Wikipedia talk:机器人建立条目小组/中华人民共和国行政区划。

南宝山镇2015年由原南宝乡与油榨乡合并而设立，镇政府驻地在原油榨乡场镇。2019年12月，南宝山镇茶板村、金甲村、常乐村、大葫村所属行政区域划归火井镇管辖，划归火井的区域中就包含了原南宝乡场镇。

然而，维基数据中的南宝山镇就仅仅是原南宝乡改了个名，下属行政区、地点、区划代码等仍是九年前南宝乡的。而百科条目中对行政区划的描述也是通过Template:PRC_admin引用维基数据自动填的，因此南宝山镇的条目内容也成了错误的。与此同时，油榨乡的数据和百科条目也存在，将其描述为现存行政区域。

我对这套数据库理解尚不透彻，暂无能力修改。我姑且将百科条目效果不符事实的模板中能注释掉的都注释掉了，并手动输入正确内容，但数据库不应该一直这样拖下去。况且据Wikipedia:机器人建立条目小组/中华人民共和国行政区划/简明手动维护手册所言，这种行政区划变动后对数据库调整校对的工作是非常繁琐的，建议到互助客栈求助。因此我在此请求诸位同仁的援手。

题外话，据相关文档所言，这套数据库刚建立时应该是有机器人自动更新的。但这个问题遗留了九年、两次区划变动之久，究竟是偶然的漏网之鱼还是自动更新机制已经失灵？若是后者，且以后也没有恢复定期自动更新的话，我对这种路径的前景深感担忧。--樱桃纳米粉（留言） 2024年5月1日 (三) 18:14 (UTC)[回复]

除维基数据的下辖行政领土实体（P150）外已修改。--Kcx36（留言） 2024年5月2日 (四) 16:27 (UTC)[回复]
取自“https://zh.wikipedia.org/w/index.php?title=Wikipedia:互助客栈/技术&oldid=82487417”