维基百科:互助客栈/技术/存档/2024年6月
本页是以往讨论的存档。请勿编辑本页。若您想发起新讨论或重启现有讨论,请在当前讨论页进行。 |
Category:包含规范控制信息的维基百科条目
波斯尼亚和黑塞哥维那的 Infobox 中无链入波斯尼亚和黑塞哥维那国旗的国旗蓝链
请求协助删除MediaWiki:Discussiontools-topicsubscription-notify-unsubscribed-body的本地自定义消息
监视列表的星星图标旋转后不对称
监视列表的星星图标在点击监视按钮后会旋转,旋转过后可以发现图标不对称。这个问题出现在网页端,移动端和PC端都有这个问题。
查看不对称的星星图标截图--Heer Rayy(留言) 2024年6月1日 (六) 08:25 (UTC)
- 没明白怎么不对称?--百無一用是書生 (☎) 2024年6月1日 (六) 11:34 (UTC)
- 因为MediaWiki使用的星星图标File:OOjs_UI_icon_star.svg本身就不是正五角星,下方的两个角要大个5°左右,见[1]。因此旋转之后自然看起来就有点歪。不过说它“不对称”是不准确的,它有一条对称轴,只是它不满足旋转对称。Irralpaca(留言) 2024年6月1日 (六) 13:48 (UTC)
能否列出在Category:在世人物和Category:生者传记分类中,英语维基、维基数据中已经标示死亡的人物传记条目,比如菲利普·罗斯已经去世六七年了,讨论页Talk:菲利普·罗斯 (Special:Diff/80866776/82855802)的模板中有{{Blp}}模板,或者{{WikiProject banner shell}}还有BLP、living参数,并将其列入Category:生者传记分类。--Kethyga(留言) 2024年5月31日 (五) 01:48 (UTC)
- 英维有一个en:Category:Living people on EN wiki who are dead on other wikis这样的分类。希望可以引入中维吧--微肿头龙(留言) 2024年5月31日 (五) 08:00 (UTC)
- 有一说一,这个分类名称有够好笑XD —— Eric Liu 創造は生命(留言・留名・学生会) 2024年6月3日 (一) 02:33 (UTC)
关于Special:Watchlist的变动
最近,监视清单的顶部改用了flex进行实现。flex作为块级元素,和作为右浮动块级div元素的“全域监视列表”按钮位置配合得不是很好。
干脆改成简单的链接算了吧。加个clear感觉不是很好看。 --MilkyDefer 2024年5月30日 (四) 13:49 (UTC)
- 完成,看这样可好?--百無一用是書生 (☎) 2024年5月31日 (五) 13:18 (UTC)
- 我觉得鼠标不移动上去就不知道原来是个按钮、并且可以完美地和上下文的文字融于一体的设计不是好设计。--MilkyDefer 2024年5月31日 (五) 14:07 (UTC)
- 我在想能不能比照元维基改在侧边栏显示?—— Eric Liu 創造は生命(留言・留名・学生会) 2024年6月5日 (三) 00:33 (UTC)
旧版Vector来源弹窗不能显示
当鼠标标向来源时,弹窗不能显示。
又是更新导致吗 ?--约翰同志-条目裱糊匠(留言) 2024年6月6日 (四) 11:20 (UTC)
- 我还以为是我浏览器问题,看来是真的出问题了--百無一用是書生 (☎) 2024年6月6日 (四) 12:22 (UTC)
- 见phab:T366419#9857143,被默认关闭了。需要在Special:参数设置#mw-prefsection-rendering中手工重新开启--百無一用是書生 (☎) 2024年6月6日 (四) 12:29 (UTC)
Cat-a-lot
见展开的编辑历史,是哪里出了问题。--寒吉(留言) 2024年6月6日 (四) 16:02 (UTC)
页面预览功能疑似损坏
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
自昨天下午开始,我登录状态下页面预览似乎被破坏,但在未登录状态下似乎正常。已经勾选了启用页面预览。我尝试过的方法:关闭所有小工具、清空common.js、切换皮肤、换用浏览器(Microsoft Edge、Firefox)、清除浏览器Cookie、新建账户等,均能复现。
另附英维相关讨论。--深鸣(留言) 2024年5月30日 (四) 10:50 (UTC)
- 本讨论已关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
Special:网络书源又映射错误了
2024年第23期技术新闻
维基媒体技术社群现在发布最新的技术新闻。请告知其他用户这些更改;不是所有的更改都会对您造成影响。技术新闻提供其他语言的翻译版本。
最近更改
- 管理员现在无需使用JavaScript,即可在工具侧边栏的底部添加链接。参见手册。 [2]
- WikiHiero追踪分类的定义的讯息名称已从“
MediaWiki:Wikhiero-usage-tracking-category
”修正为“MediaWiki:Wikihiero-usage-tracking-category
”。 [3] - 一个新的维基已创建: 中部杜顺语维基百科 (
w:dtp:
) [4]
本周更改
未来更改
MediaWiki message delivery 2024年6月3日 (一) 22:33 (UTC)
- 新版本对Vector 2010的更改中包含标题HTML的更改,这会导致部分小工具失效,需参考mw:Heading HTML changes对受影响的工具进行修改。——暁月凛奈 (留言) 2024年6月7日 (五) 12:44 (UTC)
- 另外,Vector 2010下,首页的mw-heading mw-heading1会把文字挤到下方……——暁月凛奈 (留言) 2024年6月7日 (五) 13:03 (UTC)
Jimmy-bot存档互助客栈时创建的讨论页面包含存档页模板
Jimmy-bot在存档互助客栈的讨论时,如果存档至一个不存在的讨论界面,创建讨论界面时就会在顶部加上{{存档页|Wikipedia:互助客栈/XX}}
。比如这个讨论页面Special:Diff/82853018,顶部就被加上了“本页是以往讨论的存档。请勿编辑本页。若您想发起新讨论或重启现有讨论,请在当前讨论页进行。”并且当前讨论页的链接也是指向Wikipedia:互助客栈/技术的。不知道问题是不是bot没有区别创建其他讨论页面和创建类似Wikipedia:互助客栈/技术/存档/2024年5月这种存档页。--𝓧𝓩𝓣𝓓𝓮𝓪𝓷 𝕋𝕒𝕝𝕜 2024年6月7日 (五) 07:33 (UTC)
艾奥瓦/艾奧瓦/愛荷華
刚刚编辑姊妹舰题目时,留意到一个小问题。
艾奧瓦號戰艦 (BB-61)和艾奧瓦號戰艦 (BB-4)的名称来自艾奥瓦州。根据Module:CGroup/USState,美国州份Iowa的转换为简体:艾奥瓦;繁體:愛荷華。奥為簡,而奧為繁,艾奧瓦是否合符规范?但我于沙盒测试时,发现台湾字词转换未能正确处理 艾奥瓦(标准简体,显示为繁体奥),而能将艾奧瓦(繁体奥)转为愛荷華。
另同样以该州命名的衣阿华级战列舰是否需要更名?--惣流 明日香 兰格雷不姓 式波 2024年6月7日 (五) 08:33 (UTC)
- @Sohryu Asuka Langley Not Shikinami:似乎涉及译名差异而非纯粹技术问题,建议移步条目探讨区,经讨论后再统一更新各类转换组。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年6月7日 (五) 13:55 (UTC)
- 台湾转换将混入繁体的大陆写法“艾奧瓦”“正确”转为“愛荷華”,将简体大陆写法“艾奥瓦”只“转”成“艾奧瓦”是否技术问题?--惣流 明日香 兰格雷不姓 式波 2024年6月7日 (五) 14:10 (UTC)
帮助备份 援军明日到达 参考链接
Hlist/styles.css
出生日期跟逝世日期需要页面分类吗?
IABOT与哈佛参考文献格式
IABOT是否只能处理<ref></ref>中的链接,而不能处理{{refbegin}}{{refend}}中的链接?--三猎(留言) 2024年6月8日 (六) 15:47 (UTC)
首页顶栏排版错乱
今日下午登入中维时发现首页上的顶栏突现排版错乱,更换不同浏览器和清除Cookie都没能解决这个问题,这个问题似乎仅在使用Timeless或Monobook作为外观皮肤时出现,状况都是“维基百科”四字被放大。--ElectronicGhost丨留言丨签名 2024年5月23日 (四) 13:26 (UTC)
- 可能与#2024年第21期技术新闻的变更有关?--百無一用是書生 (☎) 2024年5月23日 (四) 13:35 (UTC)
- 前次相关讨论。--Cookai饼块🍪(💬留言) 2024年5月23日 (四) 14:19 (UTC)
- 可以给个载图吗?--GX01(留言) 2024年5月25日 (六) 03:48 (UTC)
- 见此:https://t.me/wikipedia_zh_n/1839284--ElectronicGhost|👻 2024年5月25日 (六) 18:12 (UTC)
- 已修复在MediaWiki:Timeless.css和MediaWiki:Monobook.css--百無一用是書生 (☎) 2024年5月31日 (五) 12:55 (UTC)
- Vector皮肤也一样排版错乱(包括粤维也是如此);Vector 2022皮肤在URL最后增加
?safemode=1
禁用JavaScript后正常,以正常模式打开会排版错乱。--Dabao qian℡ 2024年6月10日 (一) 11:09 (UTC)
- Vector皮肤也一样排版错乱(包括粤维也是如此);Vector 2022皮肤在URL最后增加
- 已修复在MediaWiki:Timeless.css和MediaWiki:Monobook.css--百無一用是書生 (☎) 2024年5月31日 (五) 12:55 (UTC)
- 见此:https://t.me/wikipedia_zh_n/1839284--ElectronicGhost|👻 2024年5月25日 (六) 18:12 (UTC)
2024年第24期技术新闻
维基媒体技术社群现在发布最新的技术新闻。请告知其他用户这些更改;不是所有的更改都会对您造成影响。技术新闻提供其他语言的翻译版本。
最近更改
- SVG渲染软件已更新,修复了多项长期存在的SVG渲染错误。 [7]
- 所有标题的HTML标记正在进行更改,以进一步落实无障碍。部分皮肤(旧版Vector(2010)和MinervaNeue)已于上周更改。请于您所在的维基的这些皮肤下测试小工具,并回报任何相关问题,以便在Vector 2022进行更改之前解决这些问题。开发人员仍在考虑引入小工具API,用来向章节标题添加按钮(如果这对工具创作者有帮助的话);开发人员将非常感谢您对此提供任何意见。
- 上周,Parsoid用于引用的HTML标记有一项更改。现在,Parsoid在原本会生成
mw-reference-text
class的地方,会同时生成reference-text
class,以便更好地兼容旧版解析器。详情请见公告。 [8]
问题
- 内容翻译功能的界面出现错误,导致了工具菜单错位。此问题已解决。 [9]
本周更改
- MediaWiki的新版本将于6月11日部署至测试维基及MediaWiki.org,于6月12日部署至非维基百科wiki及部分维基百科,并于6月13日部署至所有站点(参见日程表)。 [10][11]
- MediaWiki的新版本有另一项关于引用的HTML标记更改:Parsoid现在均会为已命名和未命名参考生成
<span class="mw-cite-backlink">
wrapper,以便更好地兼容旧版解析器。请界面管理员确认与引用互动的小工具是否兼容新标记。详情请见公告。 [12] - 在使用
<translate>
系统的多语言维基上,可能过时的翻译会以粉红色背景显示,直到被更新或确认。从本周开始,确认翻译操作将记录在日志中;如果社群提出要求,我们将为确认翻译新增一项用户权限。 [13]
MediaWiki message delivery 2024年6月10日 (一) 20:18 (UTC)
如何在“Template:”以外的 namespace 测试 styles.css?
我在模板沙盒想要测试NumBlk(User:Justin545/沙盒/Template:NumBlk)及其对应的TemplateStyles(User:Justin545/沙盒/Template:NumBlk/styles.css),所以在 模板沙盒 的 沙盒字首 栏位填入“User:Justin545/沙盒”,显示页面 栏位填入“不等”,按下 检视 钮后,结果却看到‘页面Template:NumBlk/styles.css必须具有内容模型“已过滤的CSS”用于模板样式(目前的内容模型是“CSS”)。’的红字。
请问要如何才能在“Template:”及“模板:”以外的命名空间测试含有TemplateStyles的模板?--Justin545(留言) 2024年6月3日 (一) 06:53 (UTC)
- 找管理员帮手改“内容模型”,或者直接在模板空间下面建立CSS页(好像只有模板子页面的css页才是“已过滤的CSS”,可以用于模板样式)。——Sakamotosan路过围观 | 避免做作,免敬 2024年6月3日 (一) 08:05 (UTC)
- 谢谢,看来似乎还是要有特殊权限才行,若是这样“模板沙盒”的用处就比较小了,要在模板空间下的CSS页才能使用。--Justin545(留言) 2024年6月3日 (一) 09:07 (UTC)
- 把你需要的css拉到Template:沙盒/TemplateStyles的子页面吧 ——魔琴[身份声明 留言 贡献 新手2023] 2024年6月3日 (一) 11:44 (UTC)
- 若没错的话,虽然该页面也是属于Template命名空间底下的页面,不过它看来有分配子页面给各别的使用者做测试,可以避免不同使用者抢到同一个页面来测试的问题。
- 其实,原本这个“已过滤的CSS”的错误讯息一开始是在日文维基遇到的问题,后来发现中文也有相同的问题,所以直接在这里提问,毕竟日文也是靠Chrome的翻译,沟通还是可能造成误会。我可能再找找日文维基有没有Template:沙盒/TemplateStyles的类似页面,如果没有的话,可能就直接把日文维基的Lua module搬到中文维基来用了。--Justin545(留言) 2024年6月3日 (一) 15:40 (UTC)
- 注:上述的module为ja:Module:サンドボックス/Ef3/Timeit,看起来像是可以量测模板在做展开时所耗费的时间(第14~20行),不过Lua几乎没经验,也可能有误解。--Justin545(留言) 2024年6月3日 (一) 15:49 (UTC)
- 日文维基我暂时找不到类似的template style放置空间,所以已将前述的Lua module先搬到Module:沙盒/Justin545/Timeit,并加上一点使用的范例。--Justin545(留言) 2024年6月4日 (二) 04:56 (UTC)
- 把你需要的css拉到Template:沙盒/TemplateStyles的子页面吧 ——魔琴[身份声明 留言 贡献 新手2023] 2024年6月3日 (一) 11:44 (UTC)
- 谢谢,看来似乎还是要有特殊权限才行,若是这样“模板沙盒”的用处就比较小了,要在模板空间下的CSS页才能使用。--Justin545(留言) 2024年6月3日 (一) 09:07 (UTC)
- 有一个做法就是随便建一个Template:沙盒/TemplateStyles/TEST20240603.css之类的css页然后再直接移动到你的用户页(这种页面移动不会留下重定向)--SunAfterRain 2024年6月4日 (二) 09:18 (UTC)
- 在Template命名空间先建立好CSS页,然后再把该CSS页移到其他的命名空间(如User),您是指像这样类似的做法可以让移动后的CSS页面其内容模型保持在“已过滤的CSS”吗?--Justin545(留言) 2024年6月4日 (二) 10:05 (UTC)
- 囧rz……如果新标题不能放置那个内容模型是会直接连移都移不了--SunAfterRain 2024年6月11日 (二) 13:14 (UTC)
- 没听说也不这么认为移动页面会改变内容模型,原本只是想再次确认阁下所述的做法以减少自己误会的可能。只是没想到这个再确认“似乎”又造成了另一个误会。后续有需要我再自行试验即可,谢谢建议。--Justin545(留言) 2024年6月11日 (二) 16:43 (UTC)
呃 您从哪里听来移动页面会改变内容模型了
- 囧rz……如果新标题不能放置那个内容模型是会直接连移都移不了--SunAfterRain 2024年6月11日 (二) 13:14 (UTC)
- 在Template命名空间先建立好CSS页,然后再把该CSS页移到其他的命名空间(如User),您是指像这样类似的做法可以让移动后的CSS页面其内容模型保持在“已过滤的CSS”吗?--Justin545(留言) 2024年6月4日 (二) 10:05 (UTC)
互助客栈/条目探讨 的英文连结
现时Wikipedia:互助客栈/条目探讨的英文版本连结至无关的英维法轮功讨论页历史版本--惣流 明日香 兰格雷不姓 式波 2024年6月12日 (三) 03:02 (UTC)
- 找到原因了,Talk:法轮功#从英文维基百科翻译了一段内容有个直链en的跨语言标记,通过RFC嵌入进来了。——Sakamotosan路过围观 | 避免做作,免敬 2024年6月12日 (三) 04:16 (UTC)
- 好奇问一下RFC是什么?--惣流 明日香 兰格雷不姓 式波 2024年6月12日 (三) 04:40 (UTC)
- WP:RFC(征求意见)。不过我也不知道是怎么嵌入到条目探讨的……--自由雨日(留言) 2024年6月12日 (三) 05:15 (UTC)
- 本来的讨论有人写错了跨语言连接。然后被RFC复制到Wikipedia:征求意见/政治、政府与法律,再通过逐层嵌套引入的。
- t:Village pump page header加了判断子页面Wikipedia:互助客栈/条目探讨/rfclist,后者嵌入Wikipedia:征求意见/条目主题,再嵌入Wikipedia:征求意见/政治、政府与法律。——Sakamotosan路过围观 | 避免做作,免敬 2024年6月12日 (三) 06:08 (UTC)
- WP:RFC(征求意见)。不过我也不知道是怎么嵌入到条目探讨的……--自由雨日(留言) 2024年6月12日 (三) 05:15 (UTC)
- 好奇问一下RFC是什么?--惣流 明日香 兰格雷不姓 式波 2024年6月12日 (三) 04:40 (UTC)
简繁重定向不一致
刚刚在1970年约旦内战编辑时看到一个武裝鬥爭链接,重定向至举事,而武装斗争链接,重定向至武装力量。未知是否有其他类似情况。--惣流 明日香 兰格雷不姓 式波 2024年6月5日 (三) 08:34 (UTC)
- 其实可以考虑用机器人侦测列出资料库报告?副知@Kanashimi。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年6月5日 (三) 09:49 (UTC)
- 机器人可以做,不过得有时间写程式。--Kanashimi(留言) 2024年6月5日 (三) 12:56 (UTC)
- Eric Liu 創造は生命(留言・留名・学生会) 2024年6月12日 (三) 19:41 (UTC) 无妨,您若改日有空再看看。——
- 机器人可以做,不过得有时间写程式。--Kanashimi(留言) 2024年6月5日 (三) 12:56 (UTC)
- 又一例:
- 2022年英国政府危机 消歧義
- 2022年英國政府危機 重定向
- --惣流 明日香 兰格雷不姓 式波 2024年6月7日 (五) 09:31 (UTC)
- 目前后者已被更改重定向至前者--—— Matt Zhuang表示有事按“此”留言 2024年6月7日 (五) 10:47 (UTC)
订阅通知之不合适
乐谱无法输出音乐
在丢手绢条目的历史版本中,乐谱可以输出音乐播放。在最新版本中,尽管没有修改乐谱相关的任何代码,却无法播放音乐了,鼠标交互显示为播放File:Undefined。请问是什么缘故?--三猎(留言) 2024年5月21日 (二) 15:37 (UTC)
- 页面上有其他多媒体文件时(您在编辑中加入了File:Le facteur n'est pas passé.webm),Score扩展无法播放。见Phab:T363630。Irralpaca(留言) 2024年5月21日 (二) 16:14 (UTC)
- 其他条目也可见该问题,如义勇军进行曲#歌曲和中华民国国歌#旋律。Irralpaca(留言) 2024年5月21日 (二) 16:17 (UTC)
- 感谢告知。怪不得我前几天在英维上也遇到过这一状况。那就坐等修复啦。——三猎(留言) 2024年5月21日 (二) 17:30 (UTC)
- @三猎:问题已于6月13日部署至中维的1.43.0-wmf.9版本中解决,谨此通知。Irralpaca(留言) 2024年6月13日 (四) 23:32 (UTC)
- @Irralpaca:感谢!——三猎(留言) 2024年6月14日 (五) 05:25 (UTC)
- @三猎:问题已于6月13日部署至中维的1.43.0-wmf.9版本中解决,谨此通知。Irralpaca(留言) 2024年6月13日 (四) 23:32 (UTC)
- 感谢告知。怪不得我前几天在英维上也遇到过这一状况。那就坐等修复啦。——三猎(留言) 2024年5月21日 (二) 17:30 (UTC)
能否取消点击右上角“X种语言”时弹出的“缺少XX、XX及其他语言版本”?
想阅读其他语言版本的条目时,点击右上角的“X种语言”按钮,总会在大约1s后在顶端出现“缺少XX、XX及其他语言版本”横幅。这就导致,比如原本想点击English,结果在按下鼠标时刚好弹出横幅,就点到了English上面的一种语言。所以每次只能要么趁横幅还没弹出来赶紧点,要么就只能等一会儿等横幅跳出来之后再点,严重影响使用体验。 (注:用的是Vector 2022皮肤)--自由雨日(留言) 2024年6月14日 (五) 08:40 (UTC)
- 一年前已有其他用户在Phabricator报告了(Phab:T344028),不过似是没有修复的意向。在bug报告下方有其他用户提供了使用全域CSS的临时解决方案,您可前往Phab链接查看。Irralpaca(留言) 2024年6月14日 (五) 11:29 (UTC)
- 谢谢!不过我照他说的加入了css并刷新了缓存,好像根本没有效果……--自由雨日(留言) 2024年6月14日 (五) 11:42 (UTC)
- 另一种解决方法,如果平时不用内容翻译功能的话,便是在参数设置的测试功能中将内容翻译关闭。Irralpaca(留言) 2024年6月14日 (五) 16:46 (UTC)
- !!好像确实可行!我确实不用翻译功能。没想到这么容易就解决了……?--自由雨日(留言) 2024年6月14日 (五) 21:05 (UTC)
- 另一种解决方法,如果平时不用内容翻译功能的话,便是在参数设置的测试功能中将内容翻译关闭。Irralpaca(留言) 2024年6月14日 (五) 16:46 (UTC)
- 谢谢!不过我照他说的加入了css并刷新了缓存,好像根本没有效果……--自由雨日(留言) 2024年6月14日 (五) 11:42 (UTC)
- 换个皮肤试一下?--Leiem(留言·签名·维基调查) 2024年6月14日 (五) 18:13 (UTC)
- 不太用得习惯其他皮肤啊,而且可能和皮肤无关()--自由雨日(留言) 2024年6月14日 (五) 21:05 (UTC)
- 比如我用的Modern皮肤的语言列表是在左下角的,是一长列的形式。--Leiem(留言·签名·维基调查) 2024年6月15日 (六) 01:50 (UTC)
- 哦哦,很有道理!用惯了Vector(2022)差点忘了其他皮肤语言链接一般是在侧面了。(不过设置里有Modern这个皮肤吗……)--自由雨日(留言) 2024年6月15日 (六) 02:02 (UTC)
- 比如我用的Modern皮肤的语言列表是在左下角的,是一长列的形式。--Leiem(留言·签名·维基调查) 2024年6月15日 (六) 01:50 (UTC)
- 不太用得习惯其他皮肤啊,而且可能和皮肤无关()--自由雨日(留言) 2024年6月14日 (五) 21:05 (UTC)
- 我也需要!—— Eric Liu 創造は生命(留言・留名・学生会) 2024年6月14日 (五) 22:10 (UTC)
- 推荐全域屏蔽cx的广告。可以看看经典语言栏小工具。 ——魔琴[身份声明 留言 贡献 新手2023] 2024年6月15日 (六) 17:21 (UTC)
- cx是什么?内容翻译吗?--自由雨日(留言) 2024年6月15日 (六) 17:36 (UTC)
Infobox 配色
- 下列讨论已经关闭,请勿修改。如有任何意见,请在合适的讨论页提出,而非再次编辑本讨论。
请问最近是改了配色了吗,现在Infobox 边框颜色改了吗,或者是改细了?背景白色和Infobox表格内配色太相近了,边框不清晰,看得眼疼。个人现在这种变化有违无障碍要求的MOS:对比度。--Nostalgiacn(留言) 2024年6月14日 (五) 01:52 (UTC)
- 补充是浏览器的变化,直观感觉是直接套用手机端的样式,手机屏幕小,Infobox显示由上而下,所以不太受影响。PC屏幕长宽比更大,让整体体验变得很糟糕。--Nostalgiacn(留言) 2024年6月14日 (五) 02:03 (UTC)
- Vector 2022皮肤又瞎改,{{Infobox}}和{{Hatnote}}都变成了移动版的样式。--Dabao qian℡ 2024年6月14日 (五) 02:53 (UTC)
- 我是觉得还可以--百無一用是書生 (☎) 2024年6月14日 (五) 03:16 (UTC)
- {{taxobox}}跟{{speciesbox}}家族是不是也遭到一样的改动?我刚刚一点开才发现资讯框设计整个变了,科学分类层从靠左变成靠右对齐,还整个对歪(详见我正在慢慢编辑的红嘴奎利亚雀)看了相当强迫症发作...这有办法修成比较对齐的样子吗?--WiTo🐤💬 2024年6月14日 (五) 03:38 (UTC)
- Infobox 的表格比例也变了,变成1:1。排版都乱了,原本不换行的变换行,还有直接格式崩掉的,如《极速星舞》。--Nostalgiacn(留言) 2024年6月14日 (五) 05:10 (UTC)
- 要不要将放在MediaWiki:Common.css的infobox样式迁移回模板样式中?可能皮肤css对infobox系样式增加了适应性的调整,刚好覆盖了我们的MediaWiki:Common.css对infobox的样式。或者考虑下降到模板样式,这样优先级会更高一些,同时也是专项专用。——Sakamotosan路过围观 | 避免做作,免敬 2024年6月14日 (五) 06:03 (UTC)
- 有相当一部分信息框模板没有使用{{Infobox}}模板编写,而是直接套用表格语法({{Infobox PRCG}}),这样怕会出问题,而且这个问题是所有语言版本都有出现。--Dabao qian℡ 2024年6月14日 (五) 06:45 (UTC)
- 英文版也只迁移了一小部分en:Module:Infobox/styles.css,全部迁移好是好,但是工作量巨大--百無一用是書生 (☎) 2024年6月14日 (五) 06:49 (UTC)
- 从模板空间找
insource:"class=\"infobox"
看看那些没有直接调用{{infobox}},先双线保留(Common和模板样式并存),清理掉前面的,再移除Common,到时仍看到有的再补充模板样式。应该就好了。——Sakamotosan路过围观 | 避免做作,免敬 2024年6月14日 (五) 06:54 (UTC) - 目前的情况,只能是先等phab那边给出方案,尽快修改。如果迟迟不解决,再本地解决--百無一用是書生 (☎) 2024年6月14日 (五) 06:54 (UTC)
- 抛去那些问题不说,新版的infobox还是挺好看的...--百無一用是書生 (☎) 2024年6月14日 (五) 07:02 (UTC)
- 比例问题先不提,改了,大部分条目都要重新适配。新版辨识度,体验很糟糕,不太清楚是否与荧幕材质有关,反正我看得眼疼。--Nostalgiacn(留言) 2024年6月14日 (五) 07:11 (UTC)
- 我说好看,是指整体设计上,细节的确是一大堆毛病。辨识度这点,的确有问题,虽说我电脑上看起来还行,眼睛很舒服,没之前那么刺眼了(的确和荧幕有关系,但本质还是配色问题)--百無一用是書生 (☎) 2024年6月14日 (五) 08:42 (UTC)
- 比例问题先不提,改了,大部分条目都要重新适配。新版辨识度,体验很糟糕,不太清楚是否与荧幕材质有关,反正我看得眼疼。--Nostalgiacn(留言) 2024年6月14日 (五) 07:11 (UTC)
- 抛去那些问题不说,新版的infobox还是挺好看的...--百無一用是書生 (☎) 2024年6月14日 (五) 07:02 (UTC)
- 从模板空间找
- 坚持vector-2010不动摇。不过这部分影响可能只是限定特定皮肤的。虽然navbox、infobox名义上是社群通用设计与mw没直接组件关联,但mw直接插手到样式控制上就有点意外。——Sakamotosan路过围观 | 避免做作,免敬 2024年6月14日 (五) 09:08 (UTC)
- mw一直在插手,只是以前插手少,没感觉罢了。这次这个是要搞dark模式兼容、移动版优化以及flex设计,全都搅在一起了--百無一用是書生 (☎) 2024年6月14日 (五) 09:43 (UTC)
留意到,现在已经换回来了。--Nostalgiacn(留言) 2024年6月15日 (六) 02:00 (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)
- 会影响到Vector 2022, monobook和移动版皮肤--百無一用是書生 (☎) 2024年6月17日 (一) 07:36 (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)
{{Wikipediasister}}不显示图标
2024年第25期技术新闻
维基媒体技术社群现在发布最新的技术新闻。请告知其他用户这些更改;不是所有的更改都会对您造成影响。技术新闻提供其他语言的翻译版本。
最近更改
- 现在,当用户在视觉化编辑器中尝试加入外部链接,而该网域被列入维基项目的黑名单,用户将立即收到回馈。详情请见编辑检查。 [14]
- 新的社群配置扩展可在测试维基使用。此扩展使本地社群能依需求自订特定功能。目前仅能配置Growth功能,但未来将支持其他用例。 [15][16]
- 现在,深色模式测试功能可以在分类、帮助页面以及更多特殊页面上使用。请留意可能存在对比问题。如果您发现任何错误,请在项目讨论页回报。 [17]
问题
- 上周,维基媒体云服务中断了25分钟。这是由于数据中心的缆线故障所致。 [18]
- 上周,Vector 2022皮肤进行了样式更新。这导致了模板、顶注和图片出现意料之外的问题。对模板和顶注的更改已被回退;大多数图片问题已解决。如果您发现任何问题,请在此工单回报。 [19]
本周更改
- MediaWiki的新版本将于6月18日部署至测试维基及MediaWiki.org,于6月19日部署至非维基百科wiki及部分维基百科,并于6月20日部署至所有站点(参见日程表)。 [20][21]
- 从6月18日开始,“参考编辑检查”功能将部署至新一批维基百科。当用户新增内容至维基百科条目时,若未附上引注,此功能将请他们新增引注,借此来协助新手并辅助巡查工作。在涵盖11个维基的测试中,当向用户显示“参考检查”时,新增的引注数量增加了一倍以上。“参考检查”可由社群自行配置。 [22]
- 本周二(18日),维基媒体邮件列表将于10:00至12:00 UTC期间暂停服务约两个小时。这是为了迁移至新伺服器并升级其软体。 [23]
MediaWiki message delivery 2024年6月17日 (一) 23:47 (UTC)
- “参考编辑检查”感觉会挺有用的?—— Eric Liu 創造は生命(留言・留名・学生会) 2024年6月18日 (二) 03:15 (UTC)
- 在过滤最近更改时把拒绝编辑检查的四个标签激活,立刻治好低血压。——暁月凛奈 (留言) 2024年6月19日 (三) 16:41 (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)
- 感谢说明!我确实之前在模板代码中都会看到{{NoteTA}}被
- 说点远的:我觉得将来应该扩展MW自己的字词转换语法,给规则设定作用域,这样就可以最终解决这个长久以来的痛点。--碟之舞📀💿 2024年6月21日 (五) 03:16 (UTC)
- 应该是“模板的作用域”,有些模板不应该透传到其他页面。也就是noteTA不应该放在模板页面中,然后被嵌入时透传到条目页面上。——Sakamotosan路过围观 | 避免做作,免敬 2024年6月21日 (五) 03:25 (UTC)
深色模式界面格式问题:编辑模式对话框文本、SVG图片、代码块背景色及字体
—此条未加入日期时间的留言是于2024年6月21日 (五) 08:14 (UTC)之前加入的。
“为翻译页面标记{{Translated page}}”小工具的bug
应该产生的是“|version=<版本号>”,但是无法正常抓取版本号,变成了“|version=undefined”。--GnolizX(留言) 2024年6月21日 (五) 12:23 (UTC)
繁简分类重新导向问题
归类于繁体标题下之页面,未能自动重新导向至简体;如不丹宗份在“各國一級行政區”,却不能自动分类至既有之“各国一级行政区”分类。Jimmy-bot可能亦需要注意此种分类。我知道手动建立分类重新导向应该可以解决,但本来应该不建立也能运作才是。—— Eric Liu 創造は生命(留言・留名・学生会) 2024年6月23日 (日) 14:32 (UTC)
以浅蓝色背景突显被点选到的数学式其对应的NumBlk模板
我已将{{NumBlk}}的inline styles尽可能地都移到其对应的模板样式CSS页NumBlk/styles.css了。接下来,因为维基百科原本就有一些点选后以浅蓝色背景颜色突显目标的行为(例如:点选条目中的注释编号后注释文字会以浅蓝色突显、点选订阅通知后在讨论章节中新增文字会以浅蓝色突显),所以我想{{NumBlk}}或许也应比照办理。例如,在特征线法里的数学式(6)其源码为:
{{NumBlk|:|<math>
...(省略LaTeX,不是討論的重點)...
</math>|{{EquationRef|6}}}}
它的渲染结果为:
而在条目的源码中加入({{EquationNote|6}})
即可产生连到该数学式的连结(6)。我希望点选前面那个连到数学式的连结后,会变成如下的样式,也就是整个{{NumBlk}}的背景变为浅蓝色:
而不是只有编号的部份其背景变为浅蓝色(这样非常不明显,而且也看不出整个数学式的范围):
以上的需求,不确定能否光靠模板样式或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 ]
,如图
- 但使用Template:沙盒/TemplateStyles测试之后得到以下错误讯息:
- Error: Expected RPAREN at line 1, col 14.
- 似乎
:has()
语法在页面内容模型(ContentModel)为“sanitized-css”(已过滤的CSS),也就是Help:模板样式,似乎还不支援此种语法,所以系统会阻止你在Help:模板样式:“sanitized-css”(已过滤的CSS)页面中提交包含:has()
的css selector,如图- 既然系统已经阻挡,即使绕过阻挡,该规则也会被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)
- (:)回应我用火狐和Chrome在F12 Console下使用
2024年第26期技术新闻
维基媒体技术社群现在发布最新的技术新闻。请告知其他用户这些更改;不是所有的更改都会对您造成影响。技术新闻提供其他语言的翻译版本。
最近更改
- 上周,差异视图中的文字背景颜色以及位元组变化数字的颜色有一些更改。这些改动旨在使文字在浅色模式和深色模式下更容易阅读,是加强落实无障碍的一部分。您可以在专案讨论页提出意见和疑问。 [24]
- 上周,
visited
、hover
和active
链接的颜色也略有改动,以在浅色模式和深色模式下进一步落实无障碍。 [25]
问题
- 点击留言的时间戳可以复制讨论页留言的固定链接。当话题标题过长并且链接被用作wikitext连结时,有一些留言固定链接不起作用。此问题已解决。感谢Lofhi回报错误。 [26]
本周更改
MediaWiki message delivery 2024年6月24日 (一) 22:31 (UTC)
MobileFrontend侧边栏故障
[30] 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)
有没有人去Phabricator报告问题?--Txkk(留言) 2023年12月25日 (一) 06:46 (UTC)
- 我现在是只有关于和免责声明点击后侧边栏缩回,页面不跳转--百無一用是書生 (☎) 2023年12月25日 (一) 07:47 (UTC)
- @Txkk、Shizhao:现在情况如何?—— Eric Liu 創造は生命(留言・留名・学生会) 2024年6月25日 (二) 02:58 (UTC)
未有登入的用户将可以使用外观选单和新的预设标准字体大小
摘要:基金会计划将未登入用户的字体大小改为标准选项(16px),登入用户维持原状及为小选项(15px),所有用户将有选项列表改变字体大小和行高、及开关深色模式。此变更仅影响使用Vector 2022皮肤的用户。如果没有任何重大问题,将会两星期后部署此改动。--SCP-0000(留言) 2024年5月25日 (六) 03:17 (UTC)
大家好! 我们是维基媒体基金会网路团队。作为本年度年度计划“阅读和媒体体验目标的一部分,我们致力于让维基媒体计划的阅读变得更容易。为了实现这一目标,我们推出了“无障碍阅读”测试版功能。这添加了一个适用于 Vector 2022 皮肤的选单,并允许已登入的用户根据个人需求选择不同的字体大小和配色方案。
此选单引入了新的标准字体设定。这稍微增加了字体的大小和高度。它是根据多个来源选择的。您可以在“关于新的标准字体设定”部分找到更多相关资讯。
我们将会发生什么变化
- 我们现在已准备好为未有登入的和已登入的用户提供新的外观选单。
- 同时,我们将标准选项设定为仅适用于未有登入的用户之新预设选项。
- 如果没有发现重大技术问题,我们计划在接下来的两周内进行此更改。
- 稍后,该选单将包括选择深色模式的选项(该功能暂时仍将是测试版功能)。如希望了解更多信息,请查看我们的专案页面。
关于选项列表
新选单将允许为未有登入的和已登入的用户设定以下首选项:
- 文字大小和行高(现以测试版功能提供):使用者将能够在“小”(目前预设值)、“标准”(建议更好的可访问性)和“大”选项之间进行选择。选择一个选项将更改文字的字体大小和行高。
- 深色模式(现以测试版功能提供):使用者将能够选择永久以深色模式查看网站,或选择“自动”设置,根据装置或浏览器首选项设定浅色或深色模式。
- 内容宽度(先前作为切换按钮提供):我们已将内容宽度切换从页面底部的图示移至新选单中标签的单选按钮。其工作原理与切换开关完全相同。之前的切换按钮将不再可用。
此选单已作为测试版功能由不同的维基之专案上的已登入使用者进行了测试,同时我们邀请了一些读者进行了使用者测试。根据这些测试的结果,我们更改了选单,以提高可发现性和易用性,并适应小工具的相容性。
此选单将显示在页面右侧,如果已固定选单,则紧邻“工具”选单的下方。与“工具”选单不同,“外观”选单预设是固定的,但您可以取消固定预设。一旦取消固定预设,这就会折叠在页面顶部的图示下。
关于新的标准字体设置
小字体选项是目前的预设值。对于未有登入的用户,我们将将此预设值更改为“标准”,同时保留小字体选项作为已登入用户的预设值。“标准”和大字体选项是根据以下内容构建和测试的:
- 针对大多数读者的最佳平均字体大小的学术研究和建议。这些建议表明,我们目前的字体尺寸太小无法让大多数人舒适地阅读。这意味著,平均而言,人们阅读速度较慢,阅读时眼睛疲劳,或难以清楚地看清文字。预设增加字体大小可以改善所有使用者的这些问题,包括可能没有足够时间透过外观选单或浏览器调整设定的使用者。资讯密度同时很重要,这就是为什么我们希望在不牺牲资讯密度的情况下增加字体大小。我们不仅透过更改字体大小,同时透过更改行高和段落间距来实现这一目标。
- 由来自 13 个不同语言、脚本和大小的维基专案中 630 多名维基媒体成员提交的设计。这些用户中的大多数(约 450 名)选择了比预设值更大的字体大小。“标准”代表最受欢迎的一组答案(15-20 像素)的平均值。大字体选项代表读者需要更大的字体尺寸选项,例如 21-26 像素之间的一组尺寸。您可以在此阅读更多关于我们如何让志愿者参与此过程并确定这些选项的资讯。
- 测试版功能使用情况表明,至少一次与该功能互动的大多数使用者选择的字体大小大于当前预设值。
我们目前为止的工作和下一步
已登入的用户将暂时保留小字体选项设置作为预设设置,但可以随时更改为任何其他设定。几个月后,我们将研究有多少登入使用者切换到标准字体选项,并开始讨论已登入的用户进行的切换是否具有意义。根据测试版功能的早期数据,与该功能的互动中有 55% 选择使用标准或更大的字体选项设定。
如果您想提供协助,我们有一些简单的请求:
- 请开启测试版功能 (“无障碍阅读(Vector 2022皮肤)”)
- 请尝试一下新选单。请问有什么令人困惑的部分吗?您了解所有标签以及选单的工作原理吗?
- 请尝试不同的字体选项:小尺寸、标准尺寸和大尺寸、配色方案和宽度切换。如果您发现任何错误或有任何疑问,请与我们联络。
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)
- 相关讨论的编者。谢谢。--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:26 (UTC)
- 所以现在未登入与已登入的使用者都是小(15px)、标准(16px)、大(20px),只是未登入使用者预设是标准(16px),已登入使用者预设是小(15px)这样?我是觉得这样没什么问题。--冥王欧西里斯(留言) 2024年5月26日 (日) 02:16 (UTC)
- 理论上是的。--SCP-0000(留言) 2024年5月26日 (日) 02:34 (UTC)
简单而言,未登入用户的字体大小改为标准选项(16px),登入用户维持原状及为小选项(15px),所有用户将有选项列表改变字体大小和行高、及开关深色模式。如果没有任何重大问题,将会两星期后部署此改动。副知曾参与 - 如果真的要更改的话,有必要维持两个选项吗?我觉得这样徒增维护成本。--碟之舞📀💿 2024年5月25日 (六) 03:02 (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)
有没有办法限制重定向在条目正文中的使用?
诸如温哥华白帽、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)
跨项目通知的蓝点
近期发现在中文维基百科的页面中,“常规通知”右侧有蓝点,一般情况下点击之后页面会被标记为已读状态。但是跨语言/跨项目的通知的“总”蓝点无法点掉(原来是可以的),只能一个个点击“子”蓝点来已读。例如:
- 来自另外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)
请求修改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)