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

维基百科，自由的百科全书
跳到导航 跳到搜索

快捷方式

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

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


發表前請先搜索存档，參考舊討論中的内容可節省您的時間。

5月9日之后没有新回應的议题會移动至相应的讨论页或存档。跳至本頁的：目錄 · 底端

公告欄
# 話題 發言 參與 最新發言 最後更新(UTC+8)
1 “𢄂买县 (北𣴓省)”条目名显示崩了 26 8 A2569875 2022-05-12 12:10
2 Category:引用模板后大小超过限制的页面 108 17 A2569875 2022-05-18 22:02
3 所有带有Latex标题副标题的页面显示都不正常 4 3 A2569875 2022-04-30 21:43
4 Module:Citation language参数翻译问题 25 7 YFdyh000 2022-04-26 21:00
5 偽綠鏈二三事 7 3 Comrade John 2022-05-10 02:26
6 是否能開發搜尋紀錄統計工具 8 6 Gqqnb 2022-05-15 16:06
7 模板:Infobox ship begin等子模板合併事宜 14 5 Comrade John 2022-05-11 17:27
8 Google 错误地索引 .m 链接 11 8 Kethyga 2022-05-09 09:51
9 2022年第18期技术新闻 14 5 SunAfterRain 2022-05-07 21:55
10 特定页面的目录简繁转换异常 7 2 YFdyh000 2022-05-09 11:40
11 百度百科查看历史方法 7 6 Kethyga 2022-05-15 20:39
12 2022年第19期技术新闻 1 1 50829! 2022-05-14 14:18
13 新出现的引文格式1错误 4 2 YFdyh000 2022-05-16 22:31
14 请教如何让-{}-中的参考资料不要显示多次？ 2 1 Raccoozzy 2022-05-12 10:50
15 如何解决关注度提报栏被提报条目太多导致超出模板限制的问题 5 3 Cwek 2022-05-16 08:00
16 提议更新RefToolbar布局 11 5 BlackShadowG 2022-05-16 14:49
17 移动版bug 5 4 Cwek 2022-05-15 09:08
18 源代码编辑界面的重定向链接 2 2 Shizhao 2022-05-13 11:55
19 “从URL上传文件”功能已启用 6 4 Shizhao 2022-05-18 10:29
20 Bank Financial Information模板能否加上統一編號參數？ 1 1 Z7504 2022-05-14 11:42
21 关于移动端展开所有部分的设置项 1 1 850710247liu 2022-05-14 23:52
22 2022年第20期技术新闻 0 0
23 更新Citation/CS1模块中的“s2cid”参数限制 5 3 Kethyga 2022-05-19 10:52
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時，
請先檢查設定是否有誤

“𢄂买县 (北𣴓省)”条目名显示崩了[编辑]

本主題或以下段落文字，在討論結束後應存檔至Talk:𢄂买县 (北𣴓省)、MediaWiki talk:Common.js。

本主題或以下段落文字，已存檔副本至Talk:㶲#條目名顯示崩了存檔副本。執行人：[娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年5月12日 (四) 04:10 (UTC)[回复]

已解決：
未有新的問題回報，視為問題已解決。—- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年5月11日 (三) 07:47 (UTC)[回复]
下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

点入即可见：𢄂买县 (北𣴓省)。--Bigbullfrog1996（𓆏） 2022年3月13日 (日) 04:26 (UTC)[回复]

在2022年4月24日 (日) 15:57 (UTC)時刻我檢查您提供的連結標題顯示已恢復正常。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年4月24日 (日) 15:57 (UTC)[回复]

以下内容移动自Talk:㶲#㶲标题显示不正常，新留言请置于框外。执行人：-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年5月12日 (四) 03:05 (UTC)[回复]

㶲标题显示不正常

本主題或以下段落文字，移動自Wikipedia:互助客栈/技术#㶲标题显示不正常。执行人：Jimmy-bot（留言） 2022年4月4日 (一) 16:14 (UTC)。[回复]

本主題或以下段落文字，在討論結束後已存檔至Talk:㶲。

已解決：
見上#已解決條目名顯示崩了。—- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年5月12日 (四) 03:54 (UTC)[回复]
下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

--Fireattack（留言） 2022年3月14日 (一) 19:36 (UTC)[回复]

模板里有个换行符（\n）。--安忆Talk 2022年3月15日 (二) 03:41 (UTC)[回复]
@AnYiLin：我不認為是這個問題，不然去年11月為何沒出錯? 相關模板亦無其他改動。研判是近期標題又加了其他相關字元跳脫機制。另見Wikipedia:互助客栈/技术#“𢄂买县_(北𣴓省)”条目名显示崩了-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月15日 (二) 04:05 (UTC)[回复]
@AnYiLin、WhitePhosphorus：重新考察認為换行符（\n）必須存在，不然缺字提示會崩。能否給標題轉換加入换行符（\n）→「&#010;」的轉換？-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月15日 (二) 04:51 (UTC)[回复]
（註：這可能不是主要原因）考察原始碼發現「&#039;」，@WhitePhosphorus：能否給標題轉換加入「&#039;→'」、「&#034;→"」支持以解決問題？@AnYiLin：-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月15日 (二) 04:32 (UTC)[回复]
已確認原因：「&#10;」導致。需要在瀏覽器端將换行符（\n）替換為「&#10;」才能解決問題。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月15日 (二) 09:11 (UTC)[回复]
所以現在解決了嗎？—— Eric Liu 創造は生命（留言・留名・學生會） 2022年3月25日 (五) 03:29 (UTC)[回复]
@ Ericliu1912： 沒有管理員願意在MediaWiki:Common.js#L-243加入「firstHeadingNew = firstHeadingNew.replace(/\n/g, '&#10;');」加入將換行符換回「&#10;」的代碼，故無法解決問題（）—- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月25日 (五) 09:03 (UTC)[回复]
本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。
@SD hehua，我也遇到了这个问题。你能解释一下吗？--Q28（留言） 2022年3月13日 (日) 07:18 (UTC)[回复]
您好，我不能，这个问问娜娜奇或者白磷或者Xiplus之类的吧--在下荷花，请多指教（欢迎签到） 2022年3月13日 (日) 07:31 (UTC)[回复]
簡而言之，就標題暫時不支援HTML標籤（如<span></span>）或其他擴展標籤（如<math></math>），因此在工單phab:T294612修好之前，暫時只能使用有限制的腳本補上（有限制的原因是安全問題，全部恢復的話難防有心人士植入代碼），剛好遇到該「有限制的腳本」之技術限制：不對稱的標籤，所以沒有轉換。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月13日 (日) 15:08 (UTC)[回复]
類似的問題亦發生於e進制、鿫和p進數。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月13日 (日) 15:15 (UTC)[回复]
@SD hehua：我解答了，現在需要 等待管理员處理-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年4月23日 (六) 02:20 (UTC)[回复]
@SD hehua、Q28、魔琴：找到原因了，（表象是</span>缺少）實際原因是{{僻字}}裡面有「&#10;」在轉換過程中變成了換行符，導致字串損毀（在字串引號"間出現換行符導致Syntax Error以至於瀏覽器無法解析字串），因而造成Span標籤損壞。可能要在MediaWiki:Common.js#L-243再加入將換行符換回「&#10;」的代碼才能解決問題（例如 firstHeadingNew = firstHeadingNew.replace(/\n/g, '&#10;');）。@AnYiLin、WhitePhosphorus、Shizhao：-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月15日 (二) 05:01 (UTC)[回复]
调试时发现，phab:T294612 workaround 在本页运作时，</span>不见了，<span>未被恢复。目前暂时用{{DISPLAYTITLE}}并多插入一个</span>暂时解决显示问题。 ——魔琴 [ 留言 贡献 ] 2022年3月13日 (日) 12:53 (UTC)[回复]
看來絕大部份的越南喃字都掛掉了。真不知道怎樣修。--owennson（聊天室、獎座櫃） 2022年3月15日 (二) 07:18 (UTC)[回复]
已改。--安忆Talk 2022年4月23日 (六) 09:59 (UTC)[回复]
麻煩@Bigbullfrog1996、Q28、SD_hehua、Fireattack：@Ericliu1912、魔琴、owennson、Newbamboo：麻煩幫忙複查下問題是否已解決，感謝。（含先前客棧已存檔的Talk:㶲#㶲标题显示不正常）-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年4月24日 (日) 15:55 (UTC)[回复]
已解決
--在下荷花，请多指教（欢迎签到） 2022年4月25日 (一) 00:28 (UTC)[回复]
@SD hehua： 以此为例，点进去的一瞬间还是会闪一下那一大长串字的。--Bigbullfrog1996（𓆏） 2022年4月26日 (二) 01:24 (UTC)[回复]
@Bigbullfrog1996嘛，这玩意是用js做的临时措施，闪一下应该是正常情况，毕竟不是根本上解决的。--在下荷花，请多指教（欢迎签到） 2022年4月26日 (二) 01:28 (UTC)[回复]
(：)回應@Bigbullfrog1996：如果確認已解決就要關討論囉。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年5月2日 (一) 14:06 (UTC)[回复]
本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

Category:引用模板后大小超过限制的页面[编辑]

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:模板限制、Module talk:Ilh、Template talk:Internal link helper、Template talk:Internal link helper/en、Template talk:Translink。

现在写的尤利西斯·格兰特因模板里面的绿链，页面编辑、保存巨慢，而且从刚开始写就存在解析问题。

能否在解决上述技术问题前不要在模板里面用绿链？页面解析负担大好多，上十万字节的页面基本上都有问题。但如果全部是红链不管打开、编辑、保存都快多了，而且出现模板无法解析的情况会小很多。

如果实在不行那我考虑另外建模板吧，所有模板分红链版和绿链版。--7（留言） 2022年3月19日 (六) 13:46 (UTC)[回复]

建议社群出台一项方针限制绿链的使用，避免条目过大造成访问和编辑上的不便，比如规定模板大小超过一定字节后不得使用绿链，将模板体量控制在一个合适范围内，或是给条目中的绿链数量设置一个硬性上限，达到该上限后编者即无法再加入绿链。许多条目页底的导航模板都因超出大小限制而无法正常显示，有必要对此问题集中讨论一下。--蕭漫（留言） 2022年3月21日 (一) 16:01 (UTC)[回复]
應提升的是模板參數上限，而非限制綠鏈的使用。如果不提升編輯模板的地位、權益和榮譽，任何嘗試對模板的編輯行為設限，提升至類同條目般的，都是無理的。-- 約翰同志－條目裱糊匠（留言） 2022年3月22日 (二) 10:25 (UTC)[回复]
可以参考WP:模板限制关于“嵌套展开”的部分，这个我所知道对模板展开数影响较大。但是这涉及到“$wgMaxArticleSize”的调整，这个参数似乎同时控制源代码的输入字节大小，展开后大小、模板参数入参大小，08年这个解析限制设计时选了2MB，可能需要找当年的讨论，但从防DDoS的话，输入字节大小的控制这个是必要的，但基于“嵌套展开”和我们的模板应用的现状，我认为是有需要分开设置，单独提升展开后大小的设值。但可能需要技术开发的人去研究能开多大，我提过相应的问题（phab:T301308），但没人回应过。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月22日 (二) 10:38 (UTC)[回复]
如果现状的话，想要Navbox等不展开超载，控制{{ilh}}等类似的可能是无奈的策略。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月22日 (二) 10:39 (UTC)[回复]
另一方面也建議各位一同關注Category:引用模板后大小超过限制的页面，我歸納起來大概有幾個問題：
  • 上面各位提的綠鏈（跨語言連結）過多，這個最常見
  • 模板語法尚有精簡空間。除了上述WP:模板限制裡以外的，還有：
  • 懸掛過多模板
如果我的修改有待改進，也請不吝指教。--迴廊彼端（留言） 2022年3月22日 (二) 14:45 (UTC)[回复]
link-xx的wrapper設計就是造成容易觸發模板限制的元兇，navbox也有相同問題。--Xiplus#Talk 2022年3月24日 (四) 11:31 (UTC)[回复]
請教Xiplus前者有辦法改善嗎？後者的解法是使用{{NavboxV2}}嗎？--迴廊彼端（留言） 2022年3月24日 (四) 12:27 (UTC)[回复]
換個問法，請教Xipluslink-xx跟navbox有辦法只靠調整模板自身語法、而非更換模板（例如說改用NavboxV2模板）的方式改善嗎？--迴廊彼端（留言） 2022年3月24日 (四) 12:27 (UTC)[回复]
例如Special:Diff/46653006/70806470這樣，「展開後的引用大小」可減少約3分之1。--Xiplus#Talk 2022年3月25日 (五) 11:03 (UTC)[回复]
可以，而且这也大致符合WP:模板限制提到的嵌套倍增问题。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月26日 (六) 09:08 (UTC)[回复]
{{tsl}}也有同樣問題，應該是3倍引用大小？--Xiplus#Talk 2022年3月26日 (六) 10:42 (UTC)[回复]
@Xiplus：，我认为可以替换为直接调用Lua模块代替模板嵌套。tsl的方式可以将注释标注“模板选择”的部分替换掉。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月27日 (日) 02:12 (UTC)[回复]
但需要把link-xx的資料全部移到模組內。--Xiplus#Talk 2022年3月27日 (日) 06:00 (UTC)[回复]
@Xiplus：，可能不用这么复杂？{{Translink}}实际是重排参数顺序的{{Internal_link_helper}}，既然你在link-xx将调用{{Internal_link_helper}}模板部分转为直接调用模块，Translink看上去也可以，可能需要整合{{Langname}}的部分。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月28日 (一) 08:35 (UTC)[回复]
可是語言名稱是保留在Template:Internal link helper/en上面，應該需要把這筆資料移動到Module內？--Xiplus#Talk 2022年3月28日 (一) 08:34 (UTC)[回复]
@Xiplus：，可以将語言名稱即{{Langname}}的处理移入Lua里面，也可以减少多一层模板嵌入。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月28日 (一) 08:54 (UTC)[回复]
@Xiplus：，好像分两种情况：link-xx已存在的话，有使用{{lan}}（有模块版本）的，这个可以整理一个集合来收集不同xx的lan集合数据；没有link-xx的，会使用{{Langname}}（有模块版本）生成，这个可以不用整理集合。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月28日 (一) 09:09 (UTC)[回复]
如要修改模組，請留意一下模組:WikidataLink，裡面有直接call 到綠鏈模組內部的相關function 。從上次法國城鎮模板大爆炸拖垮維基伺服器被基金會人員來本地直接刪法國城鎮模板後，被基金會要求應從wikidata抓資料之後，就已經大量投入使用了。—- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月27日 (日) 09:03 (UTC)[回复]
把Category:有蓝链却未移除内部链接助手模板的页面这个维护分类相关语法去掉会怎样？--洛普利寧 2022年3月27日 (日) 11:16 (UTC)[回复]
@Lopullinen：沒用的，因為大部分的綠鏈根本不會輸出那段，且有輸出Category:有蓝链却未移除内部链接助手模板的页面這東東的模板多半被機器人替換引用掉了。問題是在「連結還綠的時候」的內文，可參考Template:Softsubst#使用方法就會知道他們都爆炸長了：「{{ilh|測試的內容|context for test}}→測試的內容（英语：context for test）」，裏頭許多<span></span>都應須瘦身。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月27日 (日) 16:02 (UTC)[回复]

以下內容為替換引用後的預期內容，請自行拷貝原始碼完成替換引用。

<span class="ilh-all " data-orig-title="測試的內容" data-lang-code="en" data-lang-name="英語" data-foreign-title="context for test"><span class="ilh-page">[[:測試的內容|測試的內容]]</span><span class="noprint ilh-comment">（<span class="ilh-lang">英語</span><span class="ilh-colon">：</span><span class="ilh-link">-{[[:en:context for test|<span lang="en" dir="auto">context for test</span>]]}-</span>）</span></span>
可以看到「測試的內容（英语：context for test）」當中「測試的內容」頁面不存在，因此壓根沒有輸出「Category:有蓝链却未移除内部链接助手模板的页面」，所以即使刪了「Category:有蓝链却未移除内部链接助手模板的页面」綠鏈仍然是那麼肥。所以還是要想辦法給他瘦身，看看能不能讓小工具以更短的語法就能識別綠鏈（不知技術上有沒有辦法）。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年3月27日 (日) 16:05 (UTC)[回复]
註：因技術問題，上述部分代碼已Subst，詳見Wikipedia:互助客栈/技术#Category:未完成替換引用的頁面。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年4月13日 (三) 15:41 (UTC)[回复]
同建议提高模板展开后大小上限--Yinyue200（留言） 2022年4月4日 (一) 15:36 (UTC)[回复]
我覺得問題這個條目不應該使用{{南北戰爭}}這個雞肋的模板，沒有導航的作用，資料量也過多。--Ghren🐦🕛 2022年3月24日 (四) 04:38 (UTC)[回复]
我把美國共和黨模板（暫時）註釋掉以後就可以正常顯示了。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年3月24日 (四) 12:02 (UTC)[回复]
如果「編輯、保存」原始碼就很慢，不是綠鏈、模板的問題，而是條目真的太長了（WP:SIZERULE）。--Xiplus#Talk 2022年3月24日 (四) 09:09 (UTC)[回复]
条目长的情况我很清楚会如何，毕竟上十万字节条目我写的超过任何十人总和，我上面说了那个是从一开始写就这样，你拿几个绿链模板试一下就知道。--7（留言） 2022年3月24日 (四) 10:30 (UTC)[回复]
您說的應該是預覽時的問題，而不是編輯時的問題吧？--Xiplus#Talk 2022年3月24日 (四) 11:28 (UTC)[回复]
单纯为了避免模板限制，我还是建议恢复{{ill}}这个基于红链的跨语言链接模板，相比绿链，用这个模板的页面加载速度（似乎）能快很多。--BlackShadowG（留言） 2022年3月27日 (日) 08:43 (UTC)[回复]
這樣就沒有意思吧，模板限制始終是少數，沒有必要為了它們，倒退至這個舊式跨語言連結。-- 約翰同志－條目裱糊匠（留言） 2022年3月27日 (日) 10:00 (UTC)[回复]
我觉得旧式链接+括号外语挺好的。我可以不动鼠标直接看到原文，而且一看链接是de我不懂就直接跳过了--洛普利寧 2022年3月27日 (日) 10:09 (UTC)[回复]
綠鏈的優越一直在這裏，只是站內機能追不上而已。-- 約翰同志－條目裱糊匠（留言） 2022年3月27日 (日) 10:07 (UTC)[回复]
@Comrade John：我认为绿链有些时候是意义不明的。比如一个日本动漫角色只在阿拉伯语版有条目，且中文版认为它没有关注度。该角色名字使用假名，没有统一的中文翻译，所以需要标注日文名。
条目中提到这个角色时：
  1. 应该标注日文原名以便对照。
  2. 不适合链接阿拉伯语维基。不能期望中文维基用户看懂阿拉伯文条目（加入链接的编者可能也看不懂）。当初禁止跨语言直链的一个理由就是如此。
  3. 不适合加入红色链接，因为它没有关注度，不应该放红链引诱读者创建条目。
  4. 可能适合链接Wikidata。读者可能看到他的基本信息，比如所属作品、画师等。
现行绿链问题有：
  1. 日文维基没有条目，编辑无法链接日维，因此无法提示日文名。如果在绿链后标注日文，手机版会显示“XXX（阿拉伯文：<阿文条目名>）（日文：XX）”的双重标记。这对于一个全站级工具是不应该的。
  2. 读者无法提前知道链接指向阿拉伯语维基，滑动鼠标的结果是浪费时间。
  3. 绿链强制带红色链接，可能会亦引诱编者创建不合适的条目。但是没有办法去掉红色连接。
之前讨论我也留言问过，这种语种冲突的问题如何解决。您回复的是绿链行之有效，此问题不值得讨论。有编辑是尽可能加绿链，但上述情况加绿链我认为并不是行之有效的做法。所以想问您，上述例子（如果不考虑技术问题）您认为怎样做合适？--洛普利寧 2022年3月27日 (日) 10:59 (UTC)[回复]
  1. 這是手機版問題，非綠鏈。「該角色名字使用假名，沒有統一的中文翻譯，所以需要標註日文名。」這是多此一舉，直接使用日文名，直至官方譯名出現就是。
  2. 滑動鼠標的結果是浪費時間。各有各看法吧。
  3. 有冇綠鏈，也會有編者創建不合適條目，故非綠鏈問題，而是編者不熟識方針吧。
所以，在小工具解決他們的問題吧，沒有必要為了少數，限制多數人的行為，這是倒退。-- 約翰同志－條目裱糊匠（留言） 2022年3月27日 (日) 11:19 (UTC)[回复]
@Comrade John：感谢您的回应！这个问题我的想法是增加参数：
  1. 增加一个参数控制外语显示文字，将“外语维基标题”和“外文标注”独立开。（中文读者无法辨识日文假名，而且ACG领域地区词问题比较明显；需要附注原文的情况确实不少）
  2. 小工具允许用户定制js设定副语言，比如en, fr。然后优先链接设定的副语言，如果这两个语言没有条目就链接到wikidata。未注册用户可以考虑预设指向en或wikidata等。（就是感觉技术上不现实）
  3. 增加一个参数控制红链的显隐。
实际上第一个问题我之前提过，不过是有编辑认为参数太多会混淆。所以这个绿链的服务对象是读者还是编者，我就比较困扰。毕竟英文维基是连WP:ACCESS这种细节都能立指引的。
另外按照现行WP:MOSIW，可能会得出WP:OVERTSL这样的结论。当然这个结论和现实不符就是了。但MOSIW诞生时主要是为了规制[[:en:XXX]]直链，可能没想到十年后会出现的各种新技术和各种解读。所以我是认为，绿链要想做的更好，无论制度还是技术上，确实需要再重新讨论一下。--洛普利寧 2022年3月27日 (日) 12:00 (UTC)[回复]
这就是为何我推荐使用{{illm}}的原因。illm的好处有一下几点：
  1. 直接以红链显示，读者无需划滑动鼠标即可得知链接到哪个语言。且红链与链接对于读者而言并无二致，都是指中文维基百科不存在的条目，用两种不同的颜色标注反而很奇怪
  2. 可以很大程度上节省页面加载速度
  3. 可以同时链接多个条目，例如：神經胚​（英语；​俄语）
  4. 可以直接链接到维基数据项，这在不确定哪个语言的条目质量更高时会显得非常好用：神經胚​（其他語言）
  5. 在不确定条目对应的中文名称时（例如上方提到的没有官方译名的情况），可以只提供维基数据的ID：{{Interlanguage link multi|WD=Q575877}}——>神經胚​（其他語言），其显示的文字由维基数据的label提供。这样只需要有中文名称时修改维基数据的label即可，可以有效避免“同一个外文条目，中文版的译名却不同”的问题。
且illm长期缺乏维护，很多英维的功能没有引进，若维护完善后，优点可能更多。
虽然在绿链已经普及的今天，完全推广illm的使用的可能性不大，但我还是希望绿链能向这个方向发展，这对中维帮助很大。--BlackShadowG（留言） 2022年3月27日 (日) 14:10 (UTC)[回复]
illm從視覺上不能分辯偽藍鏈，ilh和tsl能，這不利維護。-- 約翰同志－條目裱糊匠（留言） 2022年3月27日 (日) 18:10 (UTC)[回复]
illm是直接以红链显示条目名称，外语版链接是小字下标，我觉得维护上应该没有问题。--BlackShadowG（留言） 2022年3月27日 (日) 23:55 (UTC)[回复]
可能需要测量数据来确定哪个展开量更好。illm看代码复杂度（不少switch和if的解析器），感觉更容易触发模板限制。ilh和tsl基本上消除了解析器调用，有一个涉及模板嵌套的问题，但有解决的可能。主要问题是里面有大量的辅助标签用于给ilh配套的7个样式脚本用于重构显示形态，这可能是必要的浪费。而移动版显示的ilh应该是其原始输出没有通过配套的重构脚本处理过的真正输出效果。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月28日 (一) 08:23 (UTC)[回复]
link-en：Special:固定链接/70860289，预展开为810字节；Interlanguage link multi：Special:固定链接/70860283，预展开为798字节。相差不大，但如果在Special:展开模板对比原始输出的话，Interlanguage link multi的效率不太好。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月28日 (一) 08:51 (UTC)[回复]
上方的讨论混杂了多个问题，大致总结：1.绿链是否影响了编辑和保存性能。2.模板超限是否值得和可能通过消除绿链解决。3.绿链哪些算滥用，是否要有政策限制用法与用量。4.其他模板/显示效果是否比绿链更好。5.绿链是否可能在技术上改进以缓解当前问题。个人声明，我是绿链使用和赞成者，但对向读者提供绿链不置可否，仅赞成它对维基编者（和专业读者）的维护作用。
  1. 问题1，我认为更多是条目过长或其他脚本（如语法高亮、其他扩展或绿链本身）的因素，绿链至多导致预览结果较复杂而变慢。如果是绿链脚本性能问题，应能进一步优化。
  2. 问题2，我认为绿链滥用可能存在，但其维护性和说明性作用目前难以替代，单纯移除绿链将影响说明性（对应和查阅相应主题外文条目）或布局变丑（默认显示很长原文或大量存在如(英文)），条目过长、导航模板太多太大等问题同时存在。
  3. 问题3，值得讨论一些案例和考虑一个指引，限制条目正文中不必要、短期内不会创建条目的绿链。对于导航模板中的绿链，值得单独讨论，影响更大但作用也更大，因其中不能提供上下文介绍。对于“短期内不会创建”的标准，可以基于主题的常见性（很常见而没人建，绿链就可能不太有用），外文条目的热门度（编辑量、浏览量）、新鲜度、条目质量等。
  4. 问题4，我记得讨论过不止一次，并且数百人投票得出如今的折衷方案，再次争论细节并改变现状可能不现实，但用法和替代品可以讨论和列明。
  5. 问题5，值得进一步研究，如尽力缩减展开大小或改变当前实现方式。另外有个想法，针对导航模板，是否可以用机器人自动生成不调用模板（亦不检查条目是否存在）的伪绿链版本，作为模板子页面（如/cache），必要时引用它避免占用模板配额。以及也想过将目前绿链各版小工具整合为一个用户前端可切换显示效果的小工具，固定用户因此可能选用更多更理想的展示效果（上面讨论有若干细节），但这需要较多技术资源。--YFdyh000（留言） 2022年4月2日 (六) 05:15 (UTC)[回复]

缩减Internal link helper输出的代码[编辑]

如果能放弃目前的对未启用任何“跨语言链接”小工具/未启用JavaScript的用户提供如“（英语：……）”的后缀链接，我想T:Internal_link_helper的输出能节省约70%。注，“跨语言链接：光标悬浮时显示Tooltip”目前对所有人（包括IP用户）默认启用。长度比较见此版源码。代码原型（需后续开发）。有个问题是，其他效果也需改写或放弃，Special:GadgetUsage显示其他各版internalLinkHelper效果各有几百人启用、几十人活跃，代码改写难度目测中等。另外，当前代码所用的Tipsy库已停更，基金会推荐用OOUI/Widgets/Popups代替。--YFdyh000（留言） 2022年4月2日 (六) 10:20 (UTC)[回复]

我用的ilh是自己改的（ ——魔琴 [ 留言 贡献 ] 2022年4月3日 (日) 13:48 (UTC)[回复]

已尝试和确认目前各效果可以改用简化后的输出。输出量对比：

原输出
<span class="ilh-all " data-orig-title="测试的内容" data-lang-code="en" data-lang-name="英语" data-foreign-title="context for test"><span class="ilh-page">[[:测试的内容|显示文字]]</span><span class="noprint ilh-comment">（<span class="ilh-lang">英语</span><span class="ilh-colon">：</span><span class="ilh-link">-{[[:en:context for test|<span lang="en" dir="auto">context for test</span>]]}-</span>）</span></span>
新输出
<span class="ilh-all" data-la="测试的内容" data-fc="en" data-fn="英语" data-fa="context for test">[[:测试的内容|显示文字]]</span>

@AnYiLin、A2569875等有空看一下。文件较多，代码放Github了。测试用页面。代码较乱需要整理与合并，网址构造部分待优化。修改后的小工具目前未做旧格式兼容，需要定个方案应对缓存刷新阶段。--YFdyh000（留言） 2022年4月3日 (日) 22:29 (UTC)[回复]

另外，现有代码其实可以整合到一个小工具里，只需弄一下界面，及迁移用户设置/用户重选。但或许不必要？--YFdyh000（留言） 2022年4月3日 (日) 22:47 (UTC)[回复]

原輸出（筆誤）原始輸出可以考慮用跨語言連結而非紅連？讓讀者有相關條目可以閱讀。--Xiplus#Talk 2022年4月4日 (一) 01:31 (UTC)[回复]
小工具用data属性替换成现有效果，变更不影响功能。如果用户禁用JS/取消全部效果，那么原版看到绿色的“红链”及“（英语：context for test）”，修改后只有红链。--YFdyh000（留言） 2022年4月4日 (一) 01:46 (UTC)[回复]
如果指默认输出跨语言链接，争议比较大，小工具也得调整，我认为没必要，悬停查看小工具是默认启用的。--YFdyh000（留言） 2022年4月4日 (一) 01:49 (UTC)[回复]
(！)意見後面的括弧X語「（英語：English）」理論上應該也可以由小工具輸出，或者讓使用者選擇哪種小工具功能-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年4月4日 (一) 02:18 (UTC)[回复]
修改后括弧部分是小工具输出，见“新输出”。如果指原“data-lang-name”，考虑过由脚本转换，但本身不长、百余项塞进代码有点多，并或许牵扯到多种变体和维护问题，所以搁置了。“data-orig-title”也可能从链接中提取，但稳定性和兼容性可能下降，将增加维护成本。--YFdyh000（留言） 2022年4月4日 (一) 02:29 (UTC)[回复]
我知道，對於有開啟小工具的人這個更改是無感的，我考慮的是App使用者（以及禁用JS等類似情況）。--Xiplus#Talk 2022年4月4日 (一) 02:23 (UTC)[回复]
直接讓他們看到跨語言連結？有小工具的再「js」ing to 綠鏈-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年4月4日 (一) 02:27 (UTC)[回复]
App情况不了解。绿链和直接跨语言链接本就有争议（应该可以翻那次大投票），上文也提过我对向读者直接展示绿链存疑。原有的“（外文：条目链接）”我也觉得明显增加了内容凌乱程度，对阅读器用户恢复最初的直接红链促进创建似乎不成问题，而且阅读器用户可能只存了中文维基的离线镜像。如果想输出别的，我建议单开讨论。--YFdyh000（留言） 2022年4月4日 (一) 02:39 (UTC)[回复]
App情况不了解。绿链和直接跨语言链接本就有争议（应该可以翻那次大投票），上文也提过我对向读者直接展示绿链存疑。原有的“（外文：条目链接）”我也觉得明显增加了内容凌乱程度，也许增加了对绿链的反感。对“阅读器”用户恢复最初的直接红链促进创建也许不成问题？而且阅读器用户可能只存了中文维基的离线镜像。如果默认输出别的，建议单开讨论，可邀请这些环境的用户来谈。--YFdyh000（留言） 2022年4月4日 (一) 03:14 (UTC)[回复]
App的情況就是不開啟小工具的情況，因為現在的修改直接影響到不開啟小工具的結果，如果問跨語言連結跟紅連要保留哪個，我覺得跨語言連結是比較好的。--Xiplus#Talk 2022年4月4日 (一) 02:44 (UTC)[回复]
非要说需求的话，我觉得T:ill的效果不错，但字小是否不好点。跨语言链接误点（看不懂、误认为中维是翻译站）和降低条目创建率这两点问题很大。--YFdyh000（留言） 2022年4月4日 (一) 03:14 (UTC)[回复]
@Xiplus：下文新增的效果如何，我觉得不会那么乱和喧宾夺主。至于颜色，Mediawiki:common.js等是否生效？--YFdyh000（留言） 2022年4月4日 (一) 14:26 (UTC)[回复]
我發現App似乎有載入部分的小工具，但綠連小工具沒有載入。--Xiplus#Talk 2022年4月5日 (二) 02:42 (UTC)[回复]
綠連小工具沒有設計適配移動版網頁，所以設定為不載入。--Xiplus#Talk 2022年4月5日 (二) 02:44 (UTC)[回复]
我试了试，Gadget-internalLinkHelper-cravix.js可以改写适配zh.m.wikipedia.org界面。因改版方式未定，源码非常乱，整理好再发。如果移动版可以用“鼠标点击时显示Tooltip”，对默认输出格式有什么建议吗。另外，我尝试了不输出任何“data-”属性，小工具JS解析链接，但稳定性不如属性写出，代码有点复杂。--YFdyh000（留言） 2022年4月5日 (二) 07:21 (UTC)[回复]
不好意思我不懂技術，請教一下這邊的討論跟上面提的「link-xx模板的wrapper」設計有關嗎？Template:Navbox的wrapper設計稍後也會討論嗎？--迴廊彼端（留言） 2022年4月5日 (二) 07:30 (UTC)[回复]
Navbox的结构我不了解，可能无能为力。如果导航框中用了许多绿链，这边会有帮助，否则无关联。--YFdyh000（留言） 2022年4月5日 (二) 07:35 (UTC)[回复]
User:Xiplus、User:Cwek請教一下這個討論還能繼續嗎？上面提的「link-xx、navbox模板的wrapper」設計如果沒太大問題可以先修改嗎？--迴廊彼端（留言） 2022年4月13日 (三) 02:55 (UTC)[回复]
正在观望YFdyh000对缩小ilh代码输出量的考虑，无论是这个（还有配套的js脚本改写和移动版的适配改造等），还是合并部分语言标签到ilh的Lua代码中，都需要管理员的编辑权限，所以只有想法，其他爱莫能助。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月13日 (三) 03:05 (UTC)[回复]
@cwek、迴廊彼端：如果能定案，公示，出現共識的話就能提出編輯請求請管理員編輯上列js、css、Lua等高風險全保護頁面。先改是不可能的，因為根據現行的相關《保護方針》此等修改「需要共識」，共識「需要公示」，公示「需要定案」，定案全體參與討論者的「初步共識」，上面看起來無論可行不可行皆未見可定案的初步共識。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年4月13日 (三) 03:11 (UTC)[回复]
既然需要公示，有空我再弄一下吧，需要方便预览的版本。之前在等更多技术层面意见，如是否放弃data属性、与旧版模板的兼容性等。--YFdyh000（留言） 2022年4月13日 (三) 15:56 (UTC)[回复]
(？)疑問：这种做法究竟到底是在减少服务器端的执行开销还是纯粹绕避技术限制？究竟是在加快页面加载速度还是拖慢页面加载速度？
  • 原理上说，目前ilh的红/蓝/绿链判断是通过后端代码直接向内网的数据库服务器查询来实现的。一方面wmf的反向代理服务器会缓存形如https://zh.wikipedia.org/wiki/<页面名>的访问请求，另一方面mediawiki的解析器也有缓存，以至于相关的Lua代码只要执行一次，数据库查询只需要进行一次，就能在相当长的一段时间内响应多个非登录用户对页面的访问需求。
  • 该修改方案等于是将相关的逻辑改由前端实现，默认启用的前端代码通过公网以向服务器查询页面是否存在，从而输出红/蓝/绿链。因此，访问带ilh的页面时，浏览器的开销必然会增加；通过外网查询页面是否存在也远较目前后端代码直接通过内网进行数据库查询来得慢，页面加载速度也会变慢。这些暂且都不论。更要紧的是，wmf的反向代理服务器是不缓存mediawiki api查询请求的。换言之，采用这个方案之前，是“后端代码执行一次，数据库查询进行一次”，就能满足一段时间内多个用户访问页面的需求；采用该方案以后，是“无论非登录还是登录用户，只要访问一次带ilh的页面，就前端相关代码就得执行一次，就得向服务器发起一次api请求查询相关页面存在与否——这些api请求因为不缓存的缘故，到最后都还是会被mediawiki代码翻译成数据库的查询请求。”
  • 所以，这个方案非但没有减轻wmf运行mediawiki的服务器乃至数据库服务器的开销，在特殊情况下反而会令后者大幅增加——例如，如果一个带有几百个ilh链接的页面上了首页，或者因为各种原因热门起来，访问量一天好几万。即使按api请求可以10个页面一起查询来算，这就相当于访问量直接变相翻了几十倍，原先5万一天，可能在服务器那边看来就是一天几百万。原先5万一天的请求中90%以上都会在反代层面上终止（因为有缓存），现在变几百万以后还统统不缓存地进了运行mediawiki的服务器和数据库服务器。--Antigng（留言） 2022年4月13日 (三) 13:22 (UTC)[回复]
@Antigng：（無論新舊版）小工具並沒有向mediawiki api發出請求，紅/藍連都是在後端執行。--Xiplus#Talk 2022年4月13日 (三) 13:55 (UTC)[回复]
撤回发言。--Antigng（留言） 2022年4月13日 (三) 14:19 (UTC)[回复]
  • 抱歉拖得有点久，说一下进展。一直考虑如何提供“预览”供评测，以及版本切换期间的兼容性，目前做了一个整合的单js文件版本。稳定性是Alpha版本。需关闭现有的绿链小工具。然后浏览器中按F12-执行下列代码（或者加入common.js）：
mw.loader.load("https://zh.wikipedia.org/w/index.php?action=raw&ctype=text/javascript&title=User:YFdyh000/Gadget-internalLinkHelper-one-dev.js");
  • 侧栏会有一个“跨语言链接效果”供切换选项（使用HTML5本地存储，暂不能跨设备同步）。现有页面及效果应该正常运行。新版输出代码和预览见此版本，或者[2][3]这两个实验站页面。预期存在一些bug，架构等方面没有太大的信心但看上去能用，期待有人帮忙。js代码较长是含有旧版兼容代码，模块更替后可大幅删减。移动版页面已做兼容，加载脚本后应可以单击查看绿链信息。“[英语]”可以变小和隐藏，如果能放入全局css/模板样式并生效。默认效果、已过时的tipsy尚未完成重写，代码逻辑仍有些凌乱。没有做设置迁移功能。悬停模式的链接颜色目前有bug。
  • 指标方面，参考上面提到的实验站页面的网页元素/源码。当前版本：“Post‐expand include size: 247927/2097152 bytes Template argument size: 4775/2097152 bytes”，修改后版本：“Post‐expand include size: 81642/2097152 bytes Template argument size: 4775/2097152 bytes”，缩减67%（81642/247924=0.329）。站内的该页面是“Post‐expand include size: 209649/2097152 bytes”，或许是Template:Internal link helper/en直接调用模块而不经Template:Internal link helper的功劳？--YFdyh000（留言） 2022年4月25日 (一) 13:37 (UTC)[回复]

无小工具环境下的输出格式[编辑]

见上文。如空缺条目——红链，其他颜色的空缺条目，空缺条目——直接联到外文维基，空缺条目（外文条目名）——不带语言名、可能与后面已有括号重复，空缺条目（英语）——T:ill，等格式，是否有优劣，是否替代纯红链。--YFdyh000（留言） 2022年4月4日 (一) 03:14 (UTC)[回复]

再一种效果：显示文字[英语] 或 显示文字[英语]--YFdyh000（留言） 2022年4月4日 (一) 14:26 (UTC)[回复]
我是认为应该对读者（未注册用户）生成一个效果，无论有无小工具。所有编者都以这个为前提使用模板。个人来看：
  • 链接外维时，“空缺条目（英语版）”比较灵活，后面再有括号显示出来也说得过去。（小中括号、上标下标、加不加“版”字可以再议）
  • Wikidata是多语言环境有中文，可以考虑直链。
  • 或者模板加入参数控制效果。比如你认为这里直链英文版有利于排版，那就调参数设成直链enwp。这里只用考虑操作对典型中文维基读者是否有利，不用考虑维护是否方便。维护人员认为这样创建条目麻烦，设js把这类操作打回绿链popup便是。
--洛普利寧 2022年4月4日 (一) 17:58 (UTC)[回复]
或者就是只套一层默认没有效果的HTML。比如{{ilhx|[[aaaaa]]|en:XXXX}}对读者就效果是aaaaa，{{ilhx|aaaaa|d:Q123456}}对读者效果是aaaaa。然后编辑和高级用户在js里设置：比如我只会英语和日语，那就当项目有英文版和日文版时绿链弹窗；我专注维护Wikidata，那就全部指向d站等等。--洛普利寧 2022年4月4日 (一) 18:24 (UTC)[回复]
类似红链方案，也是第一版方案。但上一节中Xiplus认为App读者（不支持小工具）需要跨语言链接。按语言隐藏、凸显等可开发单独的脚本/CSS解决。--YFdyh000（留言） 2022年4月4日 (一) 18:32 (UTC)[回复]
我是认为中文维基不要对普通读者到处贴跨语言连接。一两个拿不准的翻译为避免误导读者，贴个链接方便对照也就OK。（此处是希望读者通过信息框生卒年份定位人，不是期望读者真的读一篇外文维基条目；实际这里连Wikidata更合适）en:Elections in Germany这种没有翻译难度的短语，真的就不要给读者跨维基链接了。现在绿链对读者用的太滥了。但现在编者模式和读者模式分不开，结果就是编者把适合自己的效果强加给读者了。--洛普利寧 2022年4月4日 (一) 19:03 (UTC)[回复]
感谢回应。现有效果来说，未注册用户及默认设置是绿链悬停提示，没有小工具的场景下则是（语言：外文名）的后缀。small和括号也是个选择，下标我这里看有点错位感，但我认为[]更节省空间且不会与后文的括号重复。链Wikidata是ill效果，功能更多但会否不习惯，以及可能因技术原因暂不可行（如何查Q编号）。参数控制可行，但整体调整不如直接改模块，有按模板或上下文调整效果的需求和意义吗，将增加编辑战。JS控制就是小工具/做界面，但本章节主要讨论无JS环境下的效果。原有效果源码太长了，显示我也认为比较冗余。--YFdyh000（留言） 2022年4月4日 (一) 18:27 (UTC)[回复]
@YFdyh000：①{{WikidataEntity}}可查詢Q編號；②若持有Q編號可查詢對應條目，此功能幾年前已實作於綠鏈{{Link-wd}}中例如「{{link-wd|Q107002031}}」→「雪菲（維基數據所列：Q107002031）」；③持有Q編號和P編號都可以查詢相應中文名稱；④「链Wikidata是ill效果」並非，兩年前已有{{WikidataLink}}，是「ilh效果」，例如「{{WikidataLink|Q107002031}}」→「雪菲（維基數據所列：Q107002031）」。以上。若上一節ilh優化有結論，{{Link-wd}}、{{WikidataLink}}基本可以立即跟進。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年4月13日 (三) 03:25 (UTC)[回复]
我支持红链下标的形式，至少是在APP端。目前APP端“（语言：外文名）”显示方式很有迷惑性，私以为在一般人理解来看，“AAA（英语：BBB）”会让人理解为“BBB”是“AAA”的英文名，但在使用中很多的情况下都不是对应的，例如“角色（英语：List of The Last of Us characters）”这种中英文对应不上的可能会让新来的读者感到迷惑。此外，读者只需要知道“这个东西在其它语言版本有条目”即可，而不需要知道“其它语言版本的条目叫什么名字”。综上，我认为红链下标的形式能解决这些问题。--BlackShadowG Pray for Ukraine 2022年4月14日 (四) 12:58 (UTC)[回复]
支持红链下标，至少在文档流内。大家可以试试当一个短绿链不幸正好位于换行的位置上的时候会有多难看。 --MilkyDefer 2022年4月16日 (六) 05:45 (UTC)[回复]
提醒一下，测试的时候不要忘记测试在维基百科Android和iOS App中是否正常工作。--Tranve (✉) 2022年5月9日 (一) 13:54 (UTC)[回复]
暂未测试相关环境，但与移动版网页+模拟触控应该相差不多？截至目前，没有人进一步参与测试和给出意见，所以开发暂时搁置，我不确定是否有人不同意这种方案。--YFdyh000（留言） 2022年5月9日 (一) 14:32 (UTC)[回复]

Template:Translink簡化[编辑]

Translink直接呼叫模組的patch已完成：Template:Translink/sandbox、Module:Ilh/sandbox、Module:Ilh/data、Template:Internal link helper/en/sandbox，測試樣例請見Template:Translink/testcases、Template:Internal link helper/en/testcases，cc User:Cwek。--Xiplus#Talk 2022年4月25日 (一) 15:45 (UTC)[回复]

@Xiplus：，测试过没异常的话就更新吧。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月25日 (一) 23:29 (UTC)[回复]
  1. 會否影響已啟用任何「跨語言連結」小工具的用戶的綠鏈和偽藍鏈的顯示 ?
  2. 會否影響Translink和Internal link helper的原代碼輸入 ?
  3. 可以減少幾多「展開後的引用大小」 ?
  4. 頁面編輯、保存、解析問題會否有所改善 ?-- 約翰同志－條目裱糊匠（留言） 2022年4月27日 (三) 08:12 (UTC)[回复]
    1. 不會。 2. 不會。 3. -35%。 4. 不會、不會、會。--Xiplus#Talk 2022年4月27日 (三) 08:21 (UTC)[回复]
請教User:Xiplus我這邊Template:Translink/testcases倒數兩項的舊版顯示「{{ilh|lang={{langname|aa}}|lang-code=aa|1=Test2|2=Test2|d=|nocat=}}」、「{{ilh|lang={{langname|aa}}|lang-code=aa|1=測試2|2=Test2|d=|nocat=}}」，是否有些問題呢？--迴廊彼端（留言） 2022年4月27日 (三) 11:55 (UTC)[回复]
就是現行版本有bug。--Xiplus#Talk 2022年4月27日 (三) 12:10 (UTC)[回复]
我不知道為何Cwek要這樣設計Special:Diff/42823985。--Xiplus#Talk 2022年4月27日 (三) 12:12 (UTC)[回复]
@Xiplus：我也忘了……大概就是如果已经存在link-XX的就复用（有对应已配置的语言信息），如果没有的话，就利用{{langname}}来生成，然后需要依靠模块:langname来解决？这部分也是参照改动前的调整。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月27日 (三) 12:49 (UTC)[回复]
這個我知道，但為什麼要使用{{!}}？--Xiplus#Talk 2022年4月27日 (三) 13:12 (UTC)[回复]
{{#ifexist:Template:link-{{{1}}}
|link-{{{1}}}<!--快捷模板-->
|ilh{{!}}lang={{langname{{!}}{{{1}}}}}{{!}}lang-code={{{1}}}<!--通用模板-->
}}——Sakamotosan路过围观 | 避免做作，免敬 2022年4月27日 (三) 13:19 (UTC)[回复]
但是把这个按照正常使用又是没问题的。扔到Special:展开模板也是能跑的。 囧rz……——Sakamotosan路过围观 | 避免做作，免敬 2022年4月27日 (三) 12:52 (UTC)[回复]
@Cwek，沒有：Special:PermaLink/71346024。--Xiplus#Talk 2022年4月27日 (三) 13:11 (UTC)[回复]
有可能是当时没测试覆盖到，但思路是通过ifexist判断，是的话输出link-XX，不是的话输出后面ilh+参数lang和lang-code的的部分。如果不用{{!}}的话，管道符会成为ifexist的参数分割。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月27日 (三) 13:19 (UTC)[回复]
或者刚好把这个部分在这个调整给修复了。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月27日 (三) 13:26 (UTC)[回复]

七天已過，所以 ?--約翰同志－條目裱糊匠（留言） 2022年5月1日 (日) 20:32 (UTC)[回复]

已部署。--Xiplus#Talk 2022年5月3日 (二) 14:39 (UTC)[回复]
強制刷新了Category:引用模板后大小超过限制的页面，數量從240下降到227。--Xiplus#Talk 2022年5月3日 (二) 15:20 (UTC)[回复]

所有带有Latex标题副标题的页面显示都不正常[编辑]

於Phabricator查看
編號T295091的任務

如示例1，示例2--Ember Edison 2022年3月28日 (一) 02:34 (UTC)[回复]

有点像WP:LUA里面提到的“strip mark”。可能是bug。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月28日 (一) 02:49 (UTC)[回复]
phab:T295091。——Sakamotosan路过围观 | 避免做作，免敬 2022年3月28日 (一) 02:51 (UTC)[回复]

本章節暫時不存檔。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

Module:Citation language参数翻译问题[编辑]

本主題或以下段落文字，在討論結束後應存檔至Module talk:Citation/CS1、Module talk:Citation/CS1/Language。

部分语言未从英文翻译过来，比如eg （Korean (North Korea)）. Category:CS1韩语来源 (ko)仍然是（Korean (North Korea)）而不是（朝鲜语 (朝鲜)），而不像有的语言eg （中文（新加坡）‎）. 已经有中文翻译。而且还会给出分类:CS1Korean (North Korea)来源 (ko-kp)的红链分类，去年1月请教过大家，但是最终没有解决，请问各位维基人在哪里补充中文翻译。——Zzhtju（留言） 2022年4月4日 (一) 08:39 (UTC)[回复]

建议一并解决既有语言的翻译问题，如“英语”“法语”“德语”“西班牙语”“俄语”等，或可考虑全部改用“xx文”，毕竟口头为语、书面为文，读者从维基百科上获取信息的方式普遍是阅读文字，而非通过语音获取。反对者的意见认为这些语言都是表音文字，根本谈不上拥有自己的文字，只是在借用拉丁字母（或其他字母）而已，故宜称“语”而不宜称“文”，但个人还是觉得书面化的信息称之为“文”更符合中文的表达习惯。“英文”“法文”这样的称呼虽不及“英语”“法语”的使用率高，但同样是被大众普遍接受且习以为常的词汇，百科全书在选用词汇时应更加侧重其严谨性而非使用率。--蕭漫（留言） 2022年4月8日 (五) 18:48 (UTC)[回复]
该议题牵扯甚大，应单独开题，且难有结果。比如英语维基百科该一同更名吗，主要内容是文字而非声音（音标、音视频、有聲條目等）。且按此说法，听读、视障用户听到“你好（英文：Hello）”不会觉得别扭吗，难道因群体不广泛而可忽视。文字可能要算作语言的子集，语言不只是口语。--YFdyh000（留言） 2022年4月8日 (五) 22:10 (UTC)[回复]
确实牵扯面太广，所以我只是针对 CS1 的 language 参数而言，至于本站对外文维基百科的译名，多年来已经约定俗成，恐怕难以全数更改，也没有更改的必要。我注意到在同一篇条目里，当参考资料填写了|language=参数时，会生成“（英语）（法语）”这样的文字，而在“延伸阅读”“外部链接”等章节中，当编者手动添加 {{en}}{{fr}}等模板标注语种时，生成的则是“（英文）（法文）”。为确保条目中的语言标示协调统一，避免出现前后文用词不一致的情况，似乎可以考虑对 CS1 的语言译名进行更改。--蕭漫（留言） 2022年4月9日 (六) 14:15 (UTC)[回复]
這問題此前已有人提出，我建議統一為「文」。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年4月10日 (日) 06:56 (UTC)[回复]
@Zzhtju：，阁下可以将目前系统内部没有提供正确译名的语言代号及对应的译名填写在模块Module:Citation/CS1/Language里的表local_table中。该模块未来数周内将随着CS1系列模块的更新而启用，届时该模块将被自动全保护，故请阁下抓紧时间。--Antigng（留言） 2022年4月9日 (六) 13:48 (UTC)[回复]
谢谢！那如何确认目前系统内部提供正确译名有哪些语言呢？--Zzhtju（留言） 2022年4月10日 (日) 08:41 (UTC)[回复]
@Zzhtju：，您可以参考旧讨论，这里有系统已经提供中文译名的语言代码，这里有所有系统支持的语言代码。--Antigng（留言） 2022年4月10日 (日) 09:01 (UTC)[回复]
谢谢！祝编安！--Zzhtju（留言） 2022年4月10日 (日) 09:31 (UTC)[回复]
@Antigng：请问一下目前cite系列模板使用的是[4]里面的代码吗？目前zh-hant在cite模板显示为“中文（繁体）”，但该链接显示为“繁体中文”。--BlackShadowG Pray for Ukraine 2022年4月16日 (六) 09:16 (UTC)[回复]
@BlackShadowG：，有针对zh-xx的workaround。另，挪威语一项不应删除，原因见注释。--Antigng（留言） 2022年4月16日 (六) 09:44 (UTC)[回复]
已加回。--BlackShadowG Pray for Ukraine 2022年4月18日 (一) 08:15 (UTC)[回复]
總覺得遲早還是提一下補丁為好啊。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年4月16日 (六) 10:43 (UTC)[回复]

语言变体命名[编辑]

觉得这个问题需要单独讨论一下，目前ISO 639-1的标准是“语言名 (地名)”，但中维似乎不太统一，例如：代码“en-US”，ISO对应名称是“English (United States)”，中维是“美国英语”；而代码“zh-cn”，中维是“中文（中国大陆）”，建议一律统一。——BlackShadowG Pray for Ukraine 2022年4月18日 (一) 08:30 (UTC)[回复]

(！)意見：按照中文的表述习惯，应将地名放在语言前面为宜，避免使用不必要的括号。如果采用 ISO 标准，会出现一对圆括号里面又套一对圆括号的形式，视觉效果冗余累赘，并且不符合中文标点符号的使用习惯。至少在中国大陆，比较正式的行文都很少使用双重括号，若实在无法避免，也会采用不同样式的括号，比如以方括号套圆括号。像（美国英语）（简体中文）这样的格式，改成（英语（美国））（中文（简体））实在没什么必要，将原本简洁明了的格式改得更繁琐了。若某篇条目的参考资料部分需使用大量语言标志，括号太多会显得十分杂乱。--蕭漫（留言） 2022年4月20日 (三) 14:42 (UTC)[回复]
那就把所有“[语言名]（[地名]）”统一为“[地名][语言名]”的格式？--BlackShadowG Pray for Ukraine 2022年4月21日 (四) 00:05 (UTC)[回复]
(＋)支持--蕭漫（留言） 2022年4月21日 (四) 01:55 (UTC)[回复]
有点担心，但从搜索结果来看还行，仅少数方言未找到中文结果（如摩尔多瓦俄语）。美国英语、加拿大英语、瑞士德语、智利西班牙语等等，"多米尼加西班牙语"、"厄瓜多尔西班牙语"、"委内瑞拉西班牙语"、"波多黎各西班牙语"等。--YFdyh000（留言） 2022年4月21日 (四) 15:18 (UTC)[回复]
行。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年4月21日 (四) 16:59 (UTC)[回复]
我無法接受將中文（香港）改成香港中文。香港中文指的是粵語白話文的分支，和具香港特色的白話文不同。--Ghren🐦🕖 2022年4月26日 (二) 11:45 (UTC)[回复]
我手頭上由田小琳所著的語言文字應用研究文集說「在香港社會流行的中文書面語有多種形式，主要有通用中文、港式中文、粵式中文、中英混合文等」。所謂的粵式中文就是（粵語），但是港式中文倒不如說是{{yue-hk}}之類的，未必相同。但是我暫時沒有找到很明確指香港中文就是港式中文的名稱，但是同樣地直接用香港中文代指{{zh-HK}}的看來也不多，例如我手上的電腦和手機用的是中文（香港特別行政區）、繁體中文（中國香港特別行政區）。--Ghren🐦🕗 2022年4月26日 (二) 12:25 (UTC)[回复]
也有說法說港式中文是流通在香港社會的一種特殊的中文書面語方式。可能是一個學界討論點？--Ghren🐦🕗 2022年4月26日 (二) 12:45 (UTC)[回复]
试论香港多语人社群的语言生活“香港中文在书面上同时存在通用中文、港式中文和粤式中文3种形态。”，zh-hk可能指三种之一，而非特定一种。{{zh-HK}}（目前为“繁体中文”）是否应该“不推荐”并提供更明确的标签，类似{{PRC}}有若干子标签。[5]提到zh-cmn-Hant-HK、zh-yue-Hant-HK。[6]则是zh-Hans-HK、zh-Hant-HK、zh-yue等。{{zh-yue}}存在，或许该有个{{zh-yue-hk}}=香港粤语。--YFdyh000（留言） 2022年4月26日 (二) 13:00 (UTC)[回复]
我先把涉及中文的转换注释掉。--Antigng（留言） 2022年4月26日 (二) 11:59 (UTC)[回复]

本章節暫時不存檔，直至问题解决。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

偽綠鏈二三事[编辑]

  1. 追蹤偽綠鏈並將這類條目歸入Category:有蓝链却未移除内部链接助手模板的页面的程式碼有待完善。照分類紀錄Special:Diff/71332757這次編輯就已經把該模板從分類中移除，但逐筆比對後可發現仍有「{{link-en|索马里兰银行|Bank of Somaliland}}」（實際連結到索馬利蘭銀行，條目建立於2022年3月28日）、「{{link-en|斯里兰卡中央银行|Central Bank of Sri Lanka}}」（實際連結到斯里蘭卡中央銀行，條目建立於2022年4月9日）。由此可知追蹤程式碼可能無法處理繁簡、地區詞等問題，希望可以修復，也提醒User:Comrade John清理時留意。
  2. 目前User:Cewbot僅清理Category:有蓝链却未移除内部链接助手模板的页面中的條目命名空間、模板、Category 或 Wikipedia，但有部分偽綠鏈存在於Portal空間如Portal:東南亞]、User talk空間如User talk:221.9.13.45/存檔、WT空間如Wikipedia talk:並不是所有頁面都需要標籤難以人力處理窮盡，希望可建立「讓Cewbot請理所有空間」的共識，謝謝，也副知User:Kanashimi。--迴廊彼端（留言） 2022年4月27日 (三) 11:55 (UTC)[回复]
  3. 又希望建立共識加快Cewbot的清理速度。Category:有蓝链却未移除内部链接助手模板的页面近期的數字大致上在15500-14800之間浮動，但User:Cewbot/需要修正的跨語言連結近期的數字是14000以下，Cewbot每週了不起完全清理100多條，差距其實挺大。--迴廊彼端（留言） 2022年4月29日 (五) 17:17 (UTC)[回复]
  1. 我只在乎Category:有蓝链却未移除内部链接助手模板的页面消失與否。閣下所指的問題，我已知悉一段時間，但這並非我能夠獨自處理，而且逐筆比對費時失事，所以我對偽綠鏈，找到的就改，找不到的就算。
  2. 其實Cewbot要提升它的編輯頻率，很懷念上年Category:有蓝链却未移除内部链接助手模板的页面短短幾天，由30000多個頁面，清至10000多個頁面呢。-- 約翰同志－條目裱糊匠（留言） 2022年4月27日 (三) 12:07 (UTC)[回复]
    其實能處理的大概都處理完了。您可以參照使用者:Cewbot/需要修正的跨語言連結，現在留下來的大概都是需要人工判別的。--Kanashimi（留言） 2022年4月27日 (三) 21:19 (UTC)[回复]
謝謝User:Comrade John、User:Kanashimi兩位辛苦，我會提出上述方案就是希望Cewbot清理簡單、但沒人注意到的偽綠鏈，讓有志者可以專心處理使用者:Cewbot/需要修正的跨語言連結，裡面問題真的太多。我目前找到的清法是把該頁面紀錄的原文人名、媒體名等專有名詞做重定向，像是Los Angeles Daily News、亚马逊MP3這類的讓機器人去跑，前陣子認真做的時候算蠻有成效，每週可以清一百多個。不過另一方面真的建議Cewbot加快速度，像凌晨一點到六點這種伺服器理應比較空閒的時段（如果我講錯請指正我），也常看到Cewbot除更新討論列表外只清了五、六筆偽綠鏈。--迴廊彼端（留言） 2022年4月29日 (五) 17:17 (UTC)[回复]
歸納一下討論狀況，目前我跟User:Comrade John都認為Cewbot應加快清理速度，請問一下Comrade John那邊有建議速率嗎？此外我昨天修了一筆將近兩年都沒被Cewbot修復的偽綠鏈（井上和香這個條目建立於2019年5月），這個效率真的是有點不妙。--迴廊彼端（留言） 2022年5月9日 (一) 17:40 (UTC)[回复]
速率吧.....它的速率其實沒有問題，而是頻率的問題，Cewbot每星期才清理偽藍鏈一次，可以說那一次所清理的數量，遠遠不及一星期所增加的偽藍鏈數量，最好是每日一次。確實，維基百科:不要搶機械人的工作，但前提是它們完全能夠獨自清理某些工作吧。-- 約翰同志－條目裱糊匠（留言） 2022年5月9日 (一) 18:26 (UTC)[回复]

是否能開發搜尋紀錄統計工具[编辑]

如題，有時候在寫條目時，會思考「讀者是否能成功搜尋到條目」、「讀者最希望看到什麼條目」。但因為現行的瀏覽工具僅能看到已經創立條目的瀏覽量，無法看到未創立的條目。因此希望能夠開發「搜尋紀錄統計工具」，表列讀者最常用的搜尋字串，並排除已有條目的搜尋結果，作為創建條目及創建重定向的思考方向---Koala0090（留言） 2022年4月28日 (四) 07:18 (UTC)[回复]

可能有滥用的风险？例如，频繁刷不文明用语，那它就会在工具中自动显示出来。--Antigng（留言） 2022年4月28日 (四) 10:18 (UTC)[回复]
这种工具又不是给读者看的，是给编者参考的。就算是有可能滥用的风险，影响也仅限于编者，不会外溢到读者身上啊。--MilkyDefer 2022年4月28日 (四) 11:20 (UTC)[回复]
本地难以开发，涉及用户隐私/底层软件。至多作为重定向候选，读者来搜不存在条目的情况可能不多，大多数一般读者是从搜索引擎来的吧？以及有条目请求和相关页面，缺的是编者数量和条目质量，而不是满足热度。“希望看到什么条目”，明星绯闻怎么办。--YFdyh000（留言） 2022年4月28日 (四) 13:40 (UTC)[回复]
@YFdyh000：沒有滿足熱度的問題，要不要寫都是維基人自己決定，讀者的搜尋量只是做為參考和搜尋改善工具，並不是績效指標。---Koala0090（留言） 2022年5月8日 (日) 03:36 (UTC)[回复]
我记得以前的搜索是有統計的，现在用的mw:Extension:CirrusSearch不确定有没有。而且现在的搜索功能支持很多的搜索语法，这样即使展示统计，也挺麻烦的，比如要不要过滤掉那些带搜索语法的搜索？--百無一用是書生 (☎) 2022年4月29日 (五) 02:22 (UTC)[回复]
@Shizhao：可能要先撈出來看一次大概長什麼樣子，我的想法是排除搜尋成功的結果，之後將最大家最常輸入的字串排序出來。如果有很多人都輸入同一個字串，那理論上應該可以排除一些比較複雜的輸入法。----Koala0090（留言） 2022年5月8日 (日) 03:36 (UTC)[回复]
Google有热搜字词 https://trends.google.com/trends/trendingsearches/daily?geo=US 你如果想从需求入手编写条目的话，不如就看看这些热搜字词有没有对于的维基百科条目，或者改善现有条目。--Gqqnb（留言） 2022年5月15日 (日) 08:06 (UTC)[回复]

模板:Infobox ship begin等子模板合併事宜[编辑]

本主題或以下段落文字，在討論結束後應存檔至WikiProject talk:船舶、Template talk:Infobox ship、Template talk:Infobox ship begin。

英維社群目前正在討論模板:Infobox ship begin等子模板合併為一個模板事宜，詳情請看此。

如英維社群決定合併，一定會影響有引進此模板的中維，如果我們不跟着它們合併，長遠會影響中維翻譯英維船舶條目的工作（需要轉換原始碼，費時失事）。

我想問：有沒有熟悉模板編輯（主要是熟悉模板合併）的用戶處理此等事宜 ? 有沒有能夠進行成千上萬的船舶條目的原始碼轉換的機器人 ?--約翰同志－條目裱糊匠（留言） 2022年4月30日 (六) 20:22 (UTC)[回复]

副知@Cwek、Vozhuo：可能需要進行模板合併的準備。-- 約翰同志－條目裱糊匠（留言） 2022年4月30日 (六) 20:45 (UTC)[回复]

首先Template:Infobox_ship是跟随en的更新？其次可以以并行切换的方式，逐步淘汰基于模块思路的Infobox ship XX模板组（告知不要使用，和转换方法），如同{{BS}}RDT系列逐步从模板型转为Lua型。思路可以跟随en，但做法可以有所调整。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月1日 (日) 01:32 (UTC)[回复]
Infobox ship在英維現時是重定向至Infobox ship begin，想不到在中維還在。令人擔心引進英維模板框架的中維與英維的滯後。-- 約翰同志－條目裱糊匠（留言） 2022年5月1日 (日) 07:32 (UTC)[回复]
是英语太快，Infobox ship目前有35个外语版呢，Infobox ship begin有48个。是否等英语那边稳定和出现实际问题再研究。Infobox ship begin有1178个链入，似乎没有那么严重。相较而言，PRC admin系列的可维护性更值得中维关注，比如数据难以修订；比如暨南街道坏了，目前坏了53条。--YFdyh000（留言） 2022年5月1日 (日) 08:14 (UTC)[回复]
是否等英語那邊穩定和出現實際問題再研究，我也是這樣認為的。我出帖的目的，是提醒社群，英維社群對該模板可能有大動作，以免別人合併了，我們還慒然不知，影響中維翻譯英維船舶條目的工作。-- 約翰同志－條目裱糊匠（留言） 2022年5月1日 (日) 08:33 (UTC)[回复]
我觉得首先应该先把{{軍艦模板}}（1287引用）、{{軍艦艦型模板}}（111引用）、{{潜艇}}（121引用）、{{艦型模板}}（18引用）这四个以中文参数为主的模板合并成一个覆盖范围更广的模板，比如{{船舶信息框}}。然后再以这个新合并的模板为基础，去扩展兼容英文的参数（从英维提议合并的作者的想法来看，中维上面这几个模板在结构上会和英维合并后的单一模板相似，就有了扩展的可能）。中文维基一直以来就有中英文两套船舶模板，正好趁这个机会先把自己的问题解决了，要不然等英维模板变成新的，中维再引进，就变成三套了，以后就越来越乱了。其实{{軍艦模板}}是有英文参数的，它的英文参数应该是原来英维的{{Infobox_ship}}，你把中维引用Infobox_ship条目的模板名字换成"軍艦模板"显示出来的参数也少不了几个，这是一个很好的合并起点。--Vozhuowhisper 2022年5月1日 (日) 14:00 (UTC)[回复]
@Vozhuo：雖然沒有解決中維的問題，但直接跟隨英維的做法，不是更容易嗎 ? 進行翻譯英維船舶條目的工作的用戶，哪有心機去將Template:Infobox ship轉換成自家的船舶模板。-- 約翰同志－條目裱糊匠（留言） 2022年5月1日 (日) 15:43 (UTC)[回复]
我说的都是进行模板合并的工作，和写条目的用户没有关系的。事实上我刚才就已经做了一个初步的版本{{Template:軍艦模板/sandbox}}，把上面我说的四个模板合并了起来（样例：Template:軍艦模板/testcases），比我想象中要简单的多。到时候把英文合并后的模板和这个模板做个整合，也未必是件困难的事情。--Vozhuowhisper 2022年5月1日 (日) 16:37 (UTC)[回复]
@Vozhuo：模板:Infobox service record能兼容嗎 ? 有些潛艇條目帶有這個模板。字體能和Infobox ship begin等子模板一樣大小嗎 ? 最後，Infobox ship begin等子模板有不同國家服役和多次服役退役的功能，能放上去嗎 ? 謝謝。-- 約翰同志－條目裱糊匠（留言） 2022年5月1日 (日) 18:41 (UTC)[回复]
这得等到英文那边整合好了再说。--Vozhuowhisper 2022年5月2日 (一) 05:02 (UTC)[回复]
同意。-- 約翰同志－條目裱糊匠（留言） 2022年5月2日 (一) 07:33 (UTC)[回复]
目標應該是全部整合進Infobox ship，相容中文與英文參數。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年5月2日 (一) 01:02 (UTC)[回复]

英維社群已同意將模板:Infobox ship begin等子模板合併為一個模板，現正整合中。-- 約翰同志－條目裱糊匠（留言） 2022年5月11日 (三) 09:27 (UTC)[回复]

本章節暫時不存檔，直到英文維基百科完成子模板合併，中文維基百科更新完成為止。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

Google 错误地索引 .m 链接[编辑]

本主題或以下段落文字，移動自Wikipedia:互助客栈/求助#桌上型電腦以google搜尋進入維基百科會變成行動版。执行人：--Xiplus#Talk 2022年5月7日 (六) 05:51 (UTC)。[回复]

於Phabricator查看
編號T307359的任務

目前只在搜索中文维基百科遇到过这种情况。比如搜索“机甲小宝 Wikipedia”，第一条是 https://zh.m.wikipedia.org/zh-hans/%E9%93%81%E7%94%B2%E5%B0%8F%E5%AE%9D

--Fireattack（留言） 2022年5月1日 (日) 12:43 (UTC)[回复]

Google还会索引可视化编辑器（?veaction=edit [7][8]）呢！--Txkk（留言） 2022年5月5日 (四) 13:42 (UTC)[回复]

現在google似乎將行動版wiki設為預設，使敝人必須每次手動切換成電腦版。不知其他維基人如何解決這問題？--es91213（留言） 2022年5月7日 (六) 05:43 (UTC)[回复]

奇怪，“机甲小宝+Wikipedia”我反而搜到wiki没语言缀的为第一条。不过偶然会搜到zh-tw语言缀的，可能与Google个人搜索算法有关。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月7日 (六) 07:38 (UTC)[回复]
希望Google編制搜尋索引時能只收集一種網址版本（無論是內容變體還是行動版／電腦版等等），避免混亂。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年5月7日 (六) 10:23 (UTC)[回复]
对于手机📱版网页可以让浏览器强制重定向，在用的工具Redirector，感觉可以移植到维基里。--Kethyga（留言） 2022年5月8日 (日) 09:12 (UTC)[回复]
Special:Diff/70642469/71502073。--Xiplus#Talk 2022年5月8日 (日) 14:09 (UTC)[回复]
似乎未有反应。--Kethyga（留言） 2022年5月8日 (日) 23:05 (UTC)[回复]
“User:Xiplus/common.js”，他自己的……意思是供参考。--YFdyh000（留言） 2022年5月9日 (一) 01:02 (UTC)[回复]
我已经添加到自己的common.js里面了--Kethyga（留言） 2022年5月9日 (一) 01:51 (UTC)[回复]

本章節暫時不存檔，直到問題解決。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

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

維基媒體技術社群現在發佈最新的技術新聞。請告知其他用户這些更改；不是所有的更改都會對您造成影響。技術新聞提供其他語言的翻譯版本。

最近更改

  • 组2中列出的维基站点上的视频和音频播放器已更换，旧的播放器已移除。一些音频播放器将变得更宽。新版播放器已作为测试功能使用超过四年。 [9][10]

本週後期變更

  • MediaWiki新版本將於5月3日部署至測試維基及MediaWiki.org，及於5月4日部署至非維基百科站點及部分维基百科，並於5月5日部署至所有站點，參見日曆。

未來更新

技术新闻由技術新聞編者制作并由機器人送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

2022年5月2日 (一) 19:31 (UTC)

於Phabricator查看
編號T304363的任務
站内受影响的页面主要是用到了#mw-undelete-revision的MediaWiki:Gadget-SpecialWikitext.js--百無一用是書生 (☎) 2022年5月3日 (二) 12:24 (UTC)[回复]
哪個管理員可以幫忙用開發者模式看一下Special:Undelete裡面的undelete-revision框還有什麼可識別的css選擇器特徵？—- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年5月5日 (四) 01:06 (UTC)[回复]
  • 也就是說，我需要知道Special:Undelete裡面的「查看并恢复被删页面」中「更改可见性」頁面在文字框上方那個框的CSS特徵：
查看并恢复被删页面
（更改可见性）

某頁面由某用戶（讨论 | 贡献 | 封禁）（在XXXX年X月X日 (星期X) XX:XX ）所编辑的已删除版本：

被刪除頁面的內容
 
 
 
上方那個框的CSS特徵是本功能運作所必需的，所以我只能也必須請求管理員幫忙看看。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年5月5日 (四) 01:37 (UTC)[回复]
现在暂时不用担心这个，怎么处理这些ID的方案还没定下来。 Stang★ 2022年5月5日 (四) 03:08 (UTC)[回复]
该说不说，还原得好啊。--185.217.119.27（留言） 2022年5月6日 (五) 00:17 (UTC)[回复]

本章節暫時不存檔，直到問題解決。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

特定页面的目录简繁转换异常[编辑]

於Phabricator查看
編號T303855的任務

Wikipedia:編輯禁制方針页面，有Template:NoteTA/MediaWiki转换组。-{H|紀錄=>zh-cn:记录}-正常转换了正文内容，但简体中文下目录区仍显示“纪录”。预览结果中正常。刷新缓存不见效果。--YFdyh000（留言） 2022年5月8日 (日) 22:51 (UTC)[回复]

好像没有发现“纪录”。内容和界面的设置都是中国大陆简中。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月8日 (日) 23:45 (UTC)[回复]
“5.3 纪录”没有吗。--YFdyh000（留言） 2022年5月9日 (一) 01:05 (UTC)[回复]
好像之前见过目录部分的繁简转换有问题，已经报过P区了。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月9日 (一) 02:09 (UTC)[回复]
Wikipedia:互助客栈/技术/存档/2022年3月，搜“目录问题”。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月9日 (一) 02:11 (UTC)[回复]
竖大拇指 赞！看来是新的已知bug，phab:T303855。--YFdyh000（留言） 2022年5月9日 (一) 03:40 (UTC)[回复]
因为我用脚本把原生目录直接隐藏掉了。 囧rz……——Sakamotosan路过围观 | 避免做作，免敬 2022年5月9日 (一) 02:12 (UTC)[回复]

本章節暫時不存檔，直到問題解決。欲讓機器人存檔，請移除本模板。留言請置於本模板上方。

百度百科查看历史方法[编辑]

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:百度百科对维基百科的侵权。

本人闲时发现了百度百科查看历史的方法，希望对大家判断版权时有帮助

注册个账号，随便在想看历史的词条改几个错字，然后在我的词条中找到被”他人修改版本”一栏，没有链接的情况下面另说，点进去，链接会是这个样子

https://baike.baidu.com/historydiff/A/B/C/D

A是词条名，B不用管，D是阁下的版本名称，我们要改C的内容

然后新开一个百度百科该词条的历史页面，格式如下：

https://baike.baidu.com/historylist/【词条名】

，点开你想查看的版本的“区块链信息”，复制词条版本号，把C处的数字改成那个版本号就可以看diff了。

如果没有他人修改版本，那就在历史页面把D处也替换成阁下的版本号，就可以看到了。 --QiuLiming1（留言） 2022年5月9日 (一) 00:35 (UTC)[回复]

Face-smile.svg謝謝您--在下荷花，请多指教（欢迎签到） 2022年5月12日 (四) 04:08 (UTC)[回复]
谢谢您，百度百科终于可以看历史了--Neonlight185-欢迎参与赣语维基百科（留言） 2022年5月12日 (四) 08:23 (UTC)[回复]
不谢，另补充一下：百度百科扩充来源时，最好照搬参考来源一字不差的补上去，这样容易过审核（机器人审核）。QiuLiming1（留言） 2022年5月12日 (四) 14:19 (UTC)[回复]
B猜测是页面ID，用于消歧义。 ——魔琴 [ 留言 贡献 ] 2022年5月14日 (六) 08:06 (UTC)[回复]
这个也是词条的唯一编号，虽然和几年前旧版的编号不同（两个都可以在网页中获取到）。旧版本的可以用数字编号直接访问，比如孔子2176，新版本其实也可以就是麻烦。--Kethyga（留言） 2022年5月15日 (日) 12:39 (UTC)[回复]
  • 对比历史记录的URL格式是 https://baike.baidu.com/historydiff/词条名/词条编号/新版本号/旧版本号。
  • 其中词条编号是用于消歧义用的，例如 [14] 和 [15] 是「汉字」的两个不同词条，词条编号分别是 114240 和 59874375 。
  • 新版本号与旧版本号必须其中至少有一个是自己的编辑。如果两个版本号都是别人的编辑，那么会跳转到 error.html 页面，显示「抱歉，您所访问的页面不存在」。
  • --Yejianfei（留言） 2022年5月15日 (日) 12:02 (UTC)[回复]

2022年第19期技术新闻[编辑]

維基媒體技術社群現在發佈最新的技術新聞。請告知其他用户這些更改；不是所有的更改都會對您造成影響。技術新聞提供其他語言的翻譯版本。

最近更改

问题

  • 上周维基数据的搜索自动完成功能出现问题，现已修复。 [17]
  • 上周所有wiki的登录用户在访问非缓存页面时有20分钟访问缓慢或无法访问。这是由于数据库更改造成的问题。 [18]

本週後期變更

未来会议

  • 下一次关于Vector（2022）与网页团队的开放会议将于5月17日举行。目前举行会议的计划如下：6月7日、6月21日、7月5日、7月19日。

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

2022年5月9日 (一) 15:20 (UTC)

话说中维有没有可能加入Vector（2022）测试计划？--50829! Talk · 494,974,518 2022年5月14日 (六) 06:18 (UTC)[回复]

新出现的引文格式1错误[编辑]

最近在看到有些条目出现了“newspaper=与模板{{cite web}}不匹配（建议改用{{cite news}}或|website=”的引文格式1错误，例如2022年。按照英文版本的Help:CS1 errors，应该是“Cite <template> requires |<param>=”（期刊引用模板错误）的问题，希望能追踪有相关问题的页面，修复一下。--百战天虫（留言） 2022年5月10日 (二) 03:52 (UTC)[回复]

似乎蛮多的，相关追踪分类共2,476个页面。建议出现该错误的，直接替换为cite news模板。--YFdyh000（留言） 2022年5月12日 (四) 03:28 (UTC)[回复]
那要怎么创建机器人任务？--百战天虫（留言） 2022年5月13日 (五) 11:49 (UTC)[回复]
正在请求Wikipedia:机器人/申请/YFdyh-bot/3。--YFdyh000（留言） 2022年5月16日 (一) 14:31 (UTC)[回复]

请教如何让-{}-中的参考资料不要显示多次？[编辑]

请参见：中華斑嘴鴨, 印度斑嘴鸭

此处使用-{}-是必要的

三个参考文献均被标注为 x.0, x.1, x.2 ，但实际上在任何中文变体中每个参考资料均仅会显示一次。

--——٩(๑❛ᴗ❛๑)۶这里是浣熊君【浣熊窝欢迎您】 2022年5月11日 (三) 15:41 (UTC)[回复]

已解决——٩(๑❛ᴗ❛๑)۶这里是浣熊君【浣熊窝欢迎您】 2022年5月12日 (四) 02:50 (UTC)[回复]

如何解决关注度提报栏被提报条目太多导致超出模板限制的问题[编辑]

原标题为：{{Findsources}}显示异常

如题，目前的显示效果参考Wikipedia:关注度/提报，直接显示为指向模板的链接而模板本身完全没有工作。--忒有钱🌊塩水あります🐳（留言） 2022年5月11日 (三) 18:54 (UTC)[回复]

猜测是因为维基百科:模板限制，关注度提报页面中被提条目太多了，模板在沙盒中测试显示正常。--Kethyga（留言） 2022年5月11日 (三) 20:53 (UTC)[回复]
感谢您的回复，现将讨论串改为讨论如何绕过模板限制的问题。--忒有钱🌊塩水あります🐳（留言） 2022年5月12日 (四) 16:44 (UTC)[回复]
过几天就好了，等清掉一批大量批量提报的项目。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月16日 (一) 00:00 (UTC)[回复]
去掉“猜测”。就是。当年SM大扫荡就能看见这种比这壮观的场景。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月12日 (四) 00:21 (UTC)[回复]

提议更新RefToolbar布局[编辑]

  • 此处讨论的是全站默认启用的在编辑工具栏增加参考文献“引用”功能，可以快捷地使用文献引用模板。参考Wikipedia:RefToolbar 2.0（必须在“参数设置”→“编辑”中勾选“启用增强编辑工具栏”）小工具。涉及源代码编辑时的“引用”工具栏。
  • 一直在用，方便之余感觉布局不怎么合理，常用的一些字段被折叠或者未提供，不常用的反而默认显示。经检查发现MediaWiki:RefToolbarConfig.js久未维护，且更新不难。大致总结个人草拟的修改：
  1. cite web：“日期”字段默认而非折叠显示。提供Via参数字段（用于标识转载平台等）。罕用的“Ref=”参数移入默认折叠。默认折叠区增加“Url-status”参数。
  2. cite news：via和ref=参数同上。page和pages参数默认显示。
  3. cite book："location"（出版地）、"edition"（书籍版本）默认折叠，"chapter"（章节）、"quote"（摘录）、"language"（语言）默认显示。ref=同上。via未决定。
  4. 中维罕用且英维中已移除的“会议引用”、“百科全书引用”，建议移除。
  5. 修改差异。截图见下。也可自行编辑WP:沙盒并浏览器F12-运行mw.loader.load('/w/index.php?title=User:YFdyh000/RefToolbarMessages-loader.js&action=raw&ctype=text/javascript'); 体验效果，以及自行定制个人版。
当前布局

修改前：web折叠、web展开；news折叠、news展开。

修改后布局

修改后：web折叠、web展开；news折叠、news展开。

--YFdyh000（留言） 2022年5月12日 (四) 04:06 (UTC)[回复]

出版地在和書籍版本在GB/T 7714-2015不是任意填寫項，怎可能折疊呢？"language"（語言）要麼就是全部都默認顯示，要麼全部都不，只是Cite book也太奇怪了。Cite conference實際上不只是字面上引用會議文章的意思，對應的是標准中「專著中的析出文獻」一節，佔了標准一整頁來著，我自己也經常用。移除對不是不可以，但是我只是很好奇一般用戶是怎樣引用「專著中的析出文獻」，按理使用率應該不低。--Ghren🐦🕛 2022年5月12日 (四) 04:33 (UTC)[回复]
假如真的要移除Cite conference最好可以在Proveit补上，目前还没有Cite conference。Ghren🐦🕛 2022年5月12日 (四) 04:39 (UTC)[回复]
基于个人使用率做的调整和提议，欢迎更多意见。因为屏幕空间有限，不能默认展开太多。language不动也行，原因忘了，可能出于排版。既然有人用就别删了，个人倒是没用过，直接用T:cite journal。Template:Cite conference没有文档，也似乎没有其他介绍。cite系列，“广播和电视节目”等也许不错。Proveit感觉用不惯。--YFdyh000（留言） 2022年5月12日 (四) 04:48 (UTC)[回复]
如果不担心或者自动填好，一般不会查填出版地和版本，有书名/ISBN/出版年等信息足够查准了，就像引用时不一定将作者名逐一填上去。--YFdyh000（留言） 2022年5月12日 (四) 05:07 (UTC)[回复]
离题一下，WP:AUTOLOGOUT……--MilkyDefer 2022年5月12日 (四) 06:21 (UTC)[回复]
一、同意 User:Ghrenghren。根据中华人民共和国国家标准，出版地和版本是专著参考文献中必须著录的信息（只有版次为第一版的专著不需著录版本信息）。个人在使用 {{cite book}} 时也是必填这两项的（版次为第一版的书籍除外），因此不建议折叠。倒是出版地的参数名“location”或可考虑改为“place”，更加简短一些。
二、关于是否移除 {{cite conference}} 和 {{cite encyclopedia}}，个人持(＝)中立意见。因为移除这两个模板会进一步降低它们的使用率，有可能造成误用现象，比如条目中更适合用 {{cite conference}} 和 {{cite encyclopedia}} 的地方却使用了 {{cite journal}} 和 {{cite book}}。此外，本地编辑器的“会议引用”和“百科全书引用”中，还保留着早已弃用的月份（month）参数，并且将年份（year）和日期（date）分成了两个参数，均属过时用法。需要尽快将月份移除，并将年份和日期合并。
三、{{cite conference}} 的引用对象，应该仅限于会议论文集中的单篇文章。“专著中的析出文献”个人习惯以 {{cite book}} 来引用：在“chapter”参数中填写析出文献的名称，对应国家标准中双斜杠（//）之前的部分；在“title”参数中填写专著名称，对应国家标准中 // 之后的部分。--蕭漫（留言） 2022年5月12日 (四) 16:52 (UTC)[回复]
再补充一点，{{cite conference}} 生成的引文有一处 bug，年份或日期（year/date）显示到了最后面，见下方示例。
对照其他引文模板，年份或日期应显示于出版者之后、页码之前（按照英维的显示风格，若填写了作者或编者，则年份或日期应显示于作者或编者之后）。希望 User:Antigng 在下一次 CS1 系列模块大更新时，能顺便修复这一 bug。--蕭漫（留言） 2022年5月12日 (四) 17:26 (UTC)[回复]
「專著中的析出文獻」可以看一標准給的例子：
卷39乞致任第一 // 蘇魏公文集：下冊. 北京：中華書局. 1998
汪學軍 中國農業轉基因生物研發進展與安全管理// 國際環境總局生物安全管理辨公室. 中國國家生物安全框架實施國際合作項目研討會論文集. 北京:中國環境科學出版社. 2002. 22-25
第一例來說當然可以用{{Cite book}}，但是在一些叢書或者一些較大的作者文集之中的話，畢竟用起來不方便，所謂的“chapter”参数也不過是多一個空白分開而已，這還不如直接用空白分開，又或者用「專著中的析出文獻」分開來得清楚。此外，在論文集中，編者和作者不定是固定的，這樣的話{{cite conference}} 就可以將之分開兩個部份。反正我不知道為什麼這個模板叫{{cite conference}}。 「conference」、「place」都不是標准中有的，標准也沒有會議論文集這玩兒。年份或日期（year/date）显示到了最后面這個問題我也問過了，沒有人回我。Ghren🐦🕛 2022年5月13日 (五) 04:23 (UTC)[回复]
{{Cite book}} 和其他 CS1 模板也能分别填写作者（author）和编者（editor），将析出文献和整部著作分成两部分：
  • 汪学军. 中国农业转基因生物研发进展与安全管理. 国际环境总局生物安全管理辨公室 (编). 中国国家生物安全框架实施国际合作项目研讨会论文集. 北京: 中国环境科学出版社. 2002: 22–25. 
    --蕭漫（留言） 2022年5月14日 (六) 22:17 (UTC)[回复]
建议加入editor参数（默认折叠）。--BlackShadowG Pray for Ukraine 2022年5月16日 (一) 06:49 (UTC)[回复]

移动版bug[编辑]

本站的移动版皮肤不知何原因不可查看页面分类和查论编系模版（如Template:印度尼西亚語言打开一片空白），为何会造成此现象，是否可以修复--Neonlight185-欢迎参与赣语维基百科（留言） 2022年5月12日 (四) 08:20 (UTC)[回复]

这不是bug，这是功能--百無一用是書生 (☎) 2022年5月13日 (五) 03:59 (UTC)[回复]

？？？--Neonlight185-欢迎参与赣语维基百科（留言） 2022年5月13日 (五) 06:26 (UTC)[回复]

Mediawiki 软件的功能限制，导航模板及页面分类只能在电脑端查看。--蕭漫（留言） 2022年5月14日 (六) 22:02 (UTC)[回复]
分类好像可以在设置启用高级显示。Navbox等被写死不渲染显示。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月15日 (日) 01:08 (UTC)[回复]

源代码编辑界面的重定向链接[编辑]

本主題或以下段落文字，在討論結束後應存檔至MediaWiki talk:Wikimedia-copyrightwarning。

在源代码编辑窗口下方有这样一行提示：

“同时您同意依据CC-BY-SA-3.0和GFDL协议授权您的贡献，并在CC-BY-SA-3.0的条款下以超链接或URL的方式进行署名。”

其中两次出现的“CC-BY-SA-3.0”均为重定向链接，而在英维编辑界面，这两处链接则是直接指向目标页面，并不存在重定向。虽然该细节对于维基老手并无影响，但对于初来乍到、尚不熟悉维基百科的新手而言，这种重定向链接会分散他们的注意力，并可能使他们感到困惑（不明白为何会多出来一个“重定向自XXX”的字样）。考虑到维基百科应“尽力减少读者感觉到的惊讶”（编者同时也是读者），因此这类与目标页面名称仅有细微差异的重定向链接应尽量避免。

综上，希望界面管理员能修改一下此处的管道链接，令其像英维那样直接指向目标页面。--蕭漫（留言） 2022年5月12日 (四) 20:35 (UTC)[回复]

 已修复--百無一用是書生 (☎) 2022年5月13日 (五) 03:55 (UTC)[回复]

“从URL上传文件”功能已启用[编辑]

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:上传、MediaWiki talk:Upload source url、MediaWiki talk:FileUploadWizard.js。

许久之前的一项允许本站使用“从URL上传文件”功能的提案已于近日正式部署，自动确认用户（及确认用户）目前只需输入文件的URL，即可在本地完成上传。为防止滥用，上传的域名被限制为“仅允许upload.wikimedia.org”。您之后无需下载即可搬运其他站点的合理使用文件。您可在此处体验本功能。 Stang★ 2022年5月12日 (四) 20:52 (UTC)[回复]

6年…… 囧rz……——Sakamotosan路过围观 | 避免做作，免敬 2022年5月12日 (四) 23:34 (UTC)[回复]
看起来要更新Wikipedia:上传，现在只有Special:上传文件才支持从URL上传文件（界面提示文字似乎也应该更新）--百無一用是書生 (☎) 2022年5月13日 (五) 03:21 (UTC)[回复]
已修改MediaWiki:Upload source url的提示文字--百無一用是書生 (☎) 2022年5月13日 (五) 03:45 (UTC)[回复]
MediaWiki:FileUploadWizard.js是不是也要更新？—— Eric Liu 創造は生命（留言・留名・學生會） 2022年5月16日 (一) 02:47 (UTC)[回复]
是的--百無一用是書生 (☎) 2022年5月18日 (三) 02:29 (UTC)[回复]

Bank Financial Information模板能否加上統一編號參數？[编辑]

本主題或以下段落文字，在討論結束後應存檔至Template talk:Bank Financial Information。

個人認為技術上應可行，和{{Infobox Company}}模板一樣都有統一編號，因為臺灣多半都有自己專屬的統一編號，所以{{Bank Financial Information}}應該也能增加此參數讓用戶選填。--Z7504非常建議必要時多關注評選（留言） 2022年5月14日 (六) 03:42 (UTC)[回复]

关于移动端展开所有部分的设置项[编辑]

如果打开这个设置项目，所有页面都展开了，希望在主名字空间展开所有部分，而在讨论板不展开，因为很乱不好找。所以提报一下。如果是个人需求，那么则请问个人该怎么做呢，我试了个人css页。发现ns-0选择器对.client-js .collapsible-block根本没有起到作用，如果有其他方法还请赐教。--850710247liu（留言） 2022年5月14日 (六) 15:52 (UTC)[回复]

2022年第20期技术新闻[编辑]

維基媒體技術社群現在發佈最新的技術新聞。請告知其他用户這些更改；不是所有的更改都會對您造成影響。技術新聞提供其他語言的翻譯版本。

本週後期變更

  • 自周三起，部分维基站点将可以使用添加链接功能。这些站点包括加泰罗尼亚语维基百科、​希伯来语维基百科、​印地语维基百科、​韩文维基百科、​书面挪威语维基百科、​葡萄牙语维基百科、​简单英语维基百科、​瑞典语维基百科、​乌克兰语维基百科。这是逐步向更多维基百科部署这一工具的一部分。社群可以在本地配置这一功能如何工作。 [20]
  • 2022年维基媒体黑客松将于5月20日至22日以线上形式举行。活动使用英语。在德国、加纳、希腊、印度、尼日利亚和美国，当地也会举办线下聚会。对技术感兴趣的维基人可以参与软件项目并学习新技能。您也可以主持一场会议，或发布您想参与的项目。
  • MediaWiki新版本將於5月17日部署至測試維基及MediaWiki.org，於5月18日部署至非維基百科站點及部分维基百科，於5月19日部署至所有站點，參見日曆。

未來更新

  • 您将在不久之后可以使用可视化编辑器编辑可翻译页面。可翻译的页面存在于元维基、维基共享资源等站点。 [21]

技术新闻由技術新聞編者制作并由機器人送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

2022年5月16日 (一) 18:56 (UTC)

更新Citation/CS1模块中的“s2cid”参数限制[编辑]

本主題或以下段落文字，在討論結束後應存檔至Module talk:Citation/CS1/Identifiers。

问题同之前的pmid限制问题。--Kethyga（留言） 2022年5月17日 (二) 15:30 (UTC)[回复]

有问题的条目见 Special:search/s2cid=的值 和 Category:引文格式1错误：S2CID，s2cid的值目前好像未超过2亿5千万（2500000000）。似乎英维设置上限是2亿5千万，见en:Category:CS1_errors:_S2CID--Kethyga（留言） 2022年5月19日 (四) 02:52 (UTC)[回复]

本主題或以下段落文字，移動自WP:VPO。执行人：Ghren🐦🕚 2022年5月18日 (三) 15:30 (UTC)。[回复]

如題（移動者注：題為「Module:Citation/CS1/Identifiers中提高s2cid上限」Ghren🐦🕚 2022年5月18日 (三) 15:30 (UTC)）。近日有編者提出無法使用s2cid的問題，且Special:Search/insource:s2cid中有不少條目使用該參數。故提出來請求社群對提高該參數上限的意見。--1233 （T / C） 2022年5月17日 (二) 14:23 (UTC)[回复]

取自“https://zh.wikipedia.org/w/index.php?title=Wikipedia:互助客栈/技术&oldid=71709911”