跳转到内容

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

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

本頁用作讨论在编辑时遇到的技术问题;發表問題或討論前,請先參閱常見問題解答帮助信息MediaWiki基本問題及搜索舊討論記錄。另請注意:

請注重礼仪、遵守方針與指引,一般問題請至互助客棧其他區知识问答提出,留言后请务必签名(点击 )。


發表前請先搜索存档,參考舊討論中的内容可節省您的時間。
公告欄
# 💭 話題 💬 👥 🙋 最新發言 🕒 (UTC+8)
1 《通用規範漢字表》以外的簡體字是否應該類推簡化 34 10 What7what8 2024-06-14 11:12
2 Module:Mapframe、Module:Location map报错 5 3 Shizhao 2024-06-09 20:36
3 Wikiplus导致Navbar被换行 28 8 Dabao qian 2024-07-05 16:41
4 美国县级行政区地图显示故障 8 5 Nostalgiacn 2024-07-07 10:53
5 请求修改Cite book对统一书号的支持 2 2 Nostalgiacn 2024-06-30 14:47
6 TW部分功能故障 14 5 Xiplus 2024-07-01 22:45
7 Attached KML模板的display=title显示位置有问题 2 2 Shizhao 2024-07-05 11:30
8 機器人給隱退用戶發消息的情況 3 2 Nostalgiacn 2024-07-01 10:25
9 维基百科:其他语言的维基百科典范条目/英語版這樣的標題是否屬於繁簡混用? 4 3 Midleading 2024-07-06 20:29
10 2024年第27期技術新聞 1 1 MediaWiki message delivery 2024-07-02 07:57
11 跨語言連結 4 2 暁月凛奈 2024-07-03 19:47
12 在导航模板中淘汰过时的可折叠表格支持 34 3 Cwek 2024-07-06 08:27
13 条目标题左侧出现多余的“维基百科” 13 5 Shizhao 2024-07-07 14:16
14 深色模式現在可供所有使用者使用! 11 6 SickManWP 2024-07-05 16:19
15 Twinkle關閉存廢討論無法在Vector 2022使用 3 2 Sinsyuan 2024-07-05 11:42
16 Timeless显示错误 2 2 Kethyga 2024-07-05 16:42
17 小工具“编辑段落链接([编辑])靠右排列”使编辑按钮较正常位置偏高 1 1 自由雨日 2024-07-07 11:04
18 T:Summer Olympics by year category navigation 1 1 ItsLiana 2024-07-07 12:15
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時,
請先檢查設定是否有誤

正在廣泛徵求意見的議題

以下討論需要社群廣泛關注:重新整理

維基百科技術議題與模板

Template talk:Bd § 編輯請求 2024-05-19

Wikipedia talk:互助客栈 § 互助客棧(或是任何討論)存檔到空的討論頁需改為加上Template:Talk header

通用規範漢字表》以外的簡體字是否應該類推簡化[编辑]

這說來有點話長,但日前因為在修理相關條目時遇到了「𫛚」這種字(該字位於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)[回复]
@T45614631InteraccoonaleEricliu1912我根据知乎上的一些文章整理出来了未被收录进《通用规范汉字表》的科学技术用字,见我的子页面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)[回复]
@ShizhaoInteraccoonaleT45614631Ericliu1912所以几位觉得需要处理这些繁简问题吗?还是放着不用理?我个人是觉得需要简化。--微肿头龙留言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:MapframeModule:Location map的Lua错误[1][2],如天门山寺和合石。--Kcx36留言2024年6月9日 (日) 10:35 (UTC)[回复]

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

本討論章節會維持開放,暫時不按最後意見發表時間存檔。欲讓機器人存檔,請移除本模板。留言請置於本模板上方。

Wikiplus导致Navbar被换行[编辑]

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

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

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

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

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

是批量出了問題,我建了很多個縣都是這樣子。經調查,這不是本人能力範圍內能解決的,只能坐等一天恢復正常。--維基病夫邀請您加入❤️邊緣人小組·🖊️簽到 2024年6月17日 (一) 15:51 (UTC)[回复]
是維基共享使用的底圖出問題了,各種語言維基都有顯示問題。這邊不動手,英維那邊也會吵起來,讓相關人員處理。這個應該算是技術問題?大概很快就有{{Tracked}}的工單。--Nostalgiacn留言2024年6月17日 (一) 16:59 (UTC)[回复]
怀疑与最近librsvg版本升级有关--百無一用是書生 () 2024年6月18日 (二) 03:02 (UTC)[回复]
根据phab:T367645#9902624的说法,svg文件原本就有问题,只是没有表现出来,librsvg升级后这个问题变严重了。可以参考下这个[3],一大堆的报错--百無一用是書生 () 2024年6月19日 (三) 02:25 (UTC)[回复]
舉例的圖片,以上傳新圖片解決了。不過仍然有很多圖片沒有上傳新圖片取代。如右圖(Virginia)
Virginia
--Nostalgiacn留言2024年6月30日 (日) 06:50 (UTC)[回复]
工單上編者Nux已經使用機器人替換相關圖片,美國相關圖片已經替換。不清楚是否有有其他國家或地區使用同類圖片,Phabricator上的工單已經標記完成,關閉了。--Nostalgiacn留言2024年7月7日 (日) 02:53 (UTC)[回复]

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

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

发现大量由中国标准出版社出版的中华人民共和国国家标准纸质出版物,将统一书号的第二部分添加了短横线(如 GB/T 10302-2010 的 155066·1-40495GB/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)[回复]
    @ManchiuWikipedia:頁面存廢討論/記錄/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)[回复]
    @ManchiuWikipedia:頁面存廢討論/記錄/2024/06/23也有錯位的問題。-- 2024年7月1日 (一) 03:43 (UTC)[回复]
    我重新回退后,全手工处理了一遍,请复查--百無一用是書生 () 2024年7月1日 (一) 02:28 (UTC)[回复]
2.無法關閉是[4](TW刪除)、Special:Diff/83221043(手動關閉)
3.錯位是Special:Diff/83212283-- 2024年7月1日 (一) 01:08 (UTC)[回复]
已確認這是由Vector2022引起的,Vector2010運作正常。--Xiplus#Talk 2024年7月1日 (一) 14:04 (UTC)[回复]
根據 Heading HTML changes,應該所有的標題(h1-h6)都會被加上 mw-heading,但不知為何在 Vector 2022 僅有 h2 被加上,導致計算章節數量時錯誤而造成此問題,為避免 Vector 2022 後續再次更改,我暫時決定在 Heading HTML changes 完成前不會支援 Vector 2022,請改用其他外觀,經測試本功能在 Vector 2010 運作正常。--Xiplus#Talk 2024年7月1日 (一) 14:45 (UTC)[回复]

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

{{Attached KML}}模板的display=title在Vector2022皮肤下,显示位置有问题。示例:美國國道41號商業線 (密西根州馬凱特)。对照英维的话,“路线图”显示在与“坐标”相同的位置比较好。--深鸣留言2024年6月30日 (日) 07:02 (UTC)[回复]

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

機器人給隱退用戶發消息的情況[编辑]

隱退用戶理論上不再使用賬號了,但是我留意到機器人還是會繼續給這些用戶發消息,如這個。請問是否有改善的空間,例如隱退就自動屏蔽所有消息?--Nostalgiacn留言2024年6月30日 (日) 11:00 (UTC)[回复]

可以nobots或者保护页面。但,是否有显著的必要性?--YFdyh000留言2024年6月30日 (日) 12:20 (UTC)[回复]
儘管浪費的這些性能和佔用的空間可能微不足道,但是給我一種感覺,人已經搬走了,外面的信箱還一直收到郵件。不清楚隱退後,討論頁的電子郵箱的通知功能是否也一併自動除去,否則也是給用戶電郵寄送垃圾郵件。--Nostalgiacn留言2024年7月1日 (一) 02:25 (UTC)[回复]

维基百科:其他语言的维基百科典范条目/英語版這樣的標題是否屬於繁簡混用?有很多這樣的頁面需要移動。--Midleading留言2024年7月1日 (一) 09:38 (UTC)[回复]

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

2024年第27期技術新聞[编辑]

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

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

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

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

更新清单[编辑]

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

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

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

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

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

大家好,在過去的一年裡維基媒體基金會的網頁團隊一直致力於深色模式的開發。這項工作是無障礙閱讀計劃的一部分(該計劃引入了對 Vector 2022 和 Minerva 皮膚的更改)。這提高了可讀性,並允許每個人(無論是未登入的使用者還是已登入的使用者)自訂以閱讀為中心的設定。

自今年年初以來,深色模式已作為測試版功能在行動版和桌面版網站上向大家提供。我們一直在與模板編輯者和其他技術貢獻者合作,為此功能準備不同的維基專案。這項工作包括修復模板並確保許多頁面均可以以深色模式顯示,而不會出現任何無障礙問題。我們對參與此事的所有人表示衷心的感謝。因為已經做了很多工作,深色模式已經可供未登入及已登入的使用者在行動版網站上使用。在接下來的兩週內,我們將向桌面版網站的使用者釋出此功能!

部署配置和時間表

  • 第 1 級別與第 2 級別維基百科:與淺色模式相比,深色模式的問題數量並不顯著的維基百科。這些維基專案已經為未登入及已登入的使用者提供深色模式。不過,模板中可能仍存在一些小問題。我們將添加報告這些問題的方法,以便我們可以繼續與編輯者一起修復模板。
  • 第 3 級別維基百科:與淺色模式相比,深色模式的問題數量非常多的維基百科。這些維基只會為已登入的使用者提供深色模式。我們希望為所有用戶提供深色模式。然而,有些維基專案仍然需要社群的工作來調整模板。與上面的群組類似,這些維基專案同時會收到一個報告問題的鏈接,這將有助於識別剩餘的問題。
  • 7 月 1 日的當週:第 1 級別的維基百科(包括中文維基百科)上的行動版網站(Minerva 皮膚)
  • 7 月 15 日的當週:所有維基百科上的桌面版網站(Vector 2022 皮膚);行動版網站:在第 2 級別維基百科上已登入的使用者和未登入的使用者,第 3 級別維基百科僅限於已登入的使用者

如何開啟深色模式

此功能會與文字和寬度選項一起出現在「外觀」功能列表中。根據相容性和技術架構的不同,某些頁面可能無法在深色模式下使用。對於這些頁面,選單中會出現一則通知,提供更多資訊。

如何讓深色模式變得更好!

如果您想協助讓更多頁面適合深色模式,請前往我們先前的訊息並查看「我們希望您做什麼(模板編輯者、介面管理員、技術編輯者)」部分。

謝謝大家。我們期待您的問題、意見和評論!(Translated by VLui (WMF) and SCP-2000)--SGrabarczuk (WMF)留言2024年7月4日 (四) 13:48 (UTC)[回复]

可喜可贺!L'Internationale, Sera le genre humain! ✏️ 2024年7月4日 (四) 14:05 (UTC)[回复]
Note: I bolded some sentences for easier reading. Thanks. --SCP-0000留言2024年7月4日 (四) 14:15 (UTC)[回复]
借个楼顺便说一下中维导航模板的深色模式适配还是有问题,Shizhao做完深色模式适配之后“查论编”链接在正常模式下无法更改颜色了。--Dabao qian 2024年7月4日 (四) 15:56 (UTC)[回复]
@Dabao qian深色模式兼容性問題可在Wikipedia:徵求意見/深色模式反映。--SCP-0000留言2024年7月5日 (五) 01:06 (UTC)[回复]
楼上的签名在深色模式下不适配....--百無一用是書生 () 2024年7月5日 (五) 03:33 (UTC)[回复]
能否有高人幫我看一下本人的簽名和主編條目肯塔基州城市列表堪薩斯州城市列表等在深色模式下是否有問題?本人怎麼設置也無法在Vector 2022中試用深色模式。--維基病夫邀請您加入❤️邊緣人小組·🖊️簽到 2024年7月5日 (五) 04:32 (UTC)[回复]
@SickManWP如果您是使用桌面版,現階段您需要先在測試功能設定中啟用「無障礙閱讀」才能使用。而行動版可在設定中啟用。--SCP-0000留言2024年7月5日 (五) 04:41 (UTC)[回复]
已設置完成。不過我希望看看其他用戶對條目的意見,避免過幾天本人編寫更多類似列表時出現顯示問題,影響條目評選。--維基病夫邀請您加入❤️邊緣人小組·🖊️簽到 2024年7月5日 (五) 04:48 (UTC)[回复]
两个条目的表格颜色有问题--百無一用是書生 () 2024年7月5日 (五) 08:15 (UTC)[回复]
相關條目的問題本人已於Wikipedia:徵求意見/深色模式中提出,目前正在尋找解決辦法。--維基病夫邀請您加入❤️邊緣人小組·🖊️簽到 2024年7月5日 (五) 08:19 (UTC)[回复]

Twinkle關閉存廢討論無法在Vector 2022使用[编辑]

最近幾天有使用Vector 2022介面的使用者,可以發現在WP:AFDWP:FFD無法用Twinkle關閉存廢討論,需要改以Vector 2010介面才能使用,有甚麼方法修復這樣錯誤?謝謝!--Sinsyuan✍️🌏🚀 2024年7月5日 (五) 01:27 (UTC)[回复]

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

Timeless显示错误[编辑]

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

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

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

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

參見Category:2024年夏季奧運足球賽(簡)、Category:2024年夏季奧運足球賽陣容(繁),想請問有什麼方法可以讓此模板同時在簡中/繁中標題的分類中使用?--Liebhart 💬👩‍🚀 2024年7月7日 (日) 04:15 (UTC)[回复]