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

维基百科，自由的百科全书
< Wikipedia:互助客栈

这是本页的一个历史版本，由Ericliu1912（留言 | 贡献）在2022年5月1日 (日) 00:24编辑。这可能和当前版本存在着巨大的差异。

快捷方式

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

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


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

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

公告欄
# 💭 話題 💬 👥 🙋 最新發言 🕒 (UTC+8)
1 Template:Weather box 14 6 Kethyga 2024-04-26 09:30
2 MobileFrontend侧边栏故障 6 2 Shizhao 2023-12-25 15:47
3 引文模板不应该报错全部的零宽空格 5 3 Cookai1205 2024-04-24 12:58
4 “阅读无障碍”功能和本站小工具兼容问题以及字号选择 32 8 SCP-2000 2024-04-20 00:09
5 Template:Authority control 1 1 Jimmy-bot 2024-04-29 00:14
6 關於使用 ToolsRedirect 創建的繁簡重定向 7 4 迴廊彼端 2024-04-15 22:16
7 關於「Template:Cite interview」和「Template:Cite letter」的問題 3 2 薄蛍 2024-04-21 08:49
8 请求修复Template:navy、Template:Armed forces、Template:air force 3 2 BlackShadowG 2024-04-20 11:53
9 Template:Cite web 印尼语 2 2 Liuxinyu970226 2024-04-21 13:51
10 页面信息/基本信息/过去30天的页面访问量 蓝链问题 1 1 Zzhtju 2024-04-20 20:54
11 2024年第17期技術新聞 1 1 MediaWiki message delivery 2024-04-23 04:26
12 Cite book模板預設支援哈佛式註腳 2 1 Ericliu1912 2024-04-24 14:28
13 infobox book出现问题 9 4 Kethyga 2024-04-26 17:58
14 自動評級？ 8 5 A2569875 2024-04-26 16:56
15 首页“历史上的今天”炸了 2 2 YFdyh000 2024-04-26 01:48
16 關於褒揚令、碑文的藍色方框的 CSS 樣式建議 5 3 Chu Tse-tien 2024-04-29 09:57
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時，
請先檢查設定是否有誤

正在廣泛徵求意見的議題

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

維基百科技術議題與模板

Wikipedia talk:字詞轉換處理/公共轉換組 § 思路：條目預儲公共轉換組中匹配的規則，減少載入時間

MediaWiki talk:Common.css § 編輯請求 2023-11-20

Template talk:Twitter § Twitter改為X

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

Template talk:电影信息框 § 影／視 資訊框互斥、難記

條目主題
非條目主題
提示
要將某一個討論加入上述列表中：
  • 在討論頁中的對應討論章節頂端加上{{rfc|xxx}}標籤，其中「xxx」為分類縮寫。各類分類縮寫已列於上方項目中，並應將其插入{{rfc}}中。多個分類請使用管道符號分開，如{{rfc|xxx|yyy}}，其中「xxx」為第一個分類，「yyy」為第二個分類。
更多資訊請參閱Wikipedia:徵求意見。請在Wikipedia talk:徵求意見回報有關錯誤。本列表由LuciferianBot於每個小時進行更新。

本地是否启用Commons deletion notification bot？

於Phabricator查看
編號T298881的工單

我们是否可以在本地启用Commons deletion notification bot？当共享资源上的文件被提删时，该bot会在本地使用了该文件的页面的对话页发出通知。该bot由基金会的Community Tech提供支持--百無一用是書生 (☎) 2021年12月30日 (四) 07:43 (UTC)[回复]

(＋)支持。—— Eric Liu 創造は生命（留言．留名．學生會） 2021年12月30日 (四) 15:49 (UTC)[回复]
(＋)支持。桐生ここ★[讨论] 2022年1月6日 (四) 15:30 (UTC)[回复]
( ✓ )同意。--东风（留言） 2022年1月9日 (日) 13:45 (UTC)[回复]
(＋)支持----👻Cryberghost 2022年1月11日 (二) 13:07 (UTC)[回复]
(＋)支持--0906（回復請Ping我） 2022年1月11日 (二) 15:34 (UTC)[回复]
(＋)支持--在下荷花，请多指教（欢迎签到） 2022年1月29日 (六) 06:40 (UTC)[回复]
(＋)支持，之前经常看到条目中共享资源的图片不知什么时候就没了，想在本地合理使用又找不到图片存档……有了这个机器人会方便许多。——BlackShadowG（留言） 2022年2月1日 (二) 15:24 (UTC)[回复]
(＋)支持。--Leiem（留言·签名·维基调查） 2022年2月4日 (五) 18:37 (UTC)[回复]
(＋)支持。 Have a good day! -- doge24190（☎） 2022年4月5日 (二) 04:13 (UTC)[回复]
(＋)支持——诚挚的 ZhaoFJx论•编 2022年4月12日 (二) 13:40 (UTC)[回复]
(＋)支持，commons的文件經常不知不覺就被刪了。-- 人人生來平等·留言 2022年4月13日 (三) 14:27 (UTC)[回复]

部署相關問題

phab那边给了一些意见需要社群给予回应：

  • 这个东西的i18n相关问题需要社群给予关注。translatewiki.net上面CommunityTechBot分zh-hans和zh-hant，而且两者很多用语都不一样，需要确定提示信息具体使用哪一种语言变体（这应该意味着必须牺牲一部分地区词，如果我没理解错的话）。
  • 同时，社群需要决定什么时候给讨论页上留通知。commons常见的删除方式有快速删除、删除讨论（类似于存废讨论，需要7天的讨论）以及npd (no permission)（可以理解成需要提交上传者确实是版权持有人或者得到了授权，否则文件会在7天后删除）——默认设置是前两者得到通知。如果认为有必要的话，可以在第三种情况下也进行通知。
  • 最后是有没有必要给这个通知的账户bot flag的问题——这个交给BAG的人商量比较好。

-- Stang★ 2022年2月20日 (日) 21:43 (UTC)[回复]

通知问题我觉得全部都可以上，bot flag不需要--百無一用是書生 (☎) 2022年2月21日 (一) 02:50 (UTC)[回复]
話說可用本地的LC嗎（感覺有難度）。Hualin~希望の星は青霄に昇る Commons|Talk 2022年2月24日 (四) 14:26 (UTC)[回复]
不是很能理解这个问题，想用lc的话看上去就得定义一种新语言？ Stang★ 2022年3月1日 (二) 02:06 (UTC)[回复]
忘了 囧rz……Hualin~希望の星は青霄に昇る Commons|Talk 2022年3月2日 (三) 05:19 (UTC)[回复]
之前想回覆這件事情結果一直忘記。建議Commons在對話頁的通知維持在英語就可以了。由於英語是Commons的主流溝通用語，雖然可以使用華語，如果自身的英語能力有限還是很難跟人互動，除非我們有強大的翻譯志愿者常駐在Commons上協助使用者。話說Commons許多的方針指引頁面依然還沒翻譯成中文或者翻譯不全以及過時的版本，想要全面理解Commons方針還是要有基本的英語能力才是上策。另外在Commons會接觸到各式各樣的人，將新來的中文使用者導向Commons未必能替他們帶來良好的體驗。--章安德魯（留言） 2022年3月14日 (一) 10:40 (UTC)[回复]
这里是中文站点。如果存在可用的翻译，应尽可能使用翻译的内容。而且不就是一个罐头信息么，改成英文并不能起到实质上“提升英文理解能力”的作用（删除里有不管用什么语言都是不会随之改变的）。 Stang★ 2022年3月15日 (二) 11:29 (UTC)[回复]
我們維基百科有的是地區詞轉換 Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵～ 2022年3月19日 (六) 02:17 (UTC)[回复]
我關心的是：把人引到Commons上會發生什麼事。放置在Commons的檔案被提出刪除請求時，中文的使用者每一個人有能力提出異議嗎、有辦法確保每一個中文使用者熟知Commons的規矩嗎。要知道有一部份Commons的中文使用者其實是來自像是維基愛古蹟之類的場合，他們只是照著簡易流程上傳檔案而已。就算是中文維基本站的使用者，許多人也只是用Commons做為條目所需的圖片空間而已。（1）假使這些人的照片被提刪，在中文維基互助客棧提出需要幫助時，中文維基社群有做好這方面的人力準備嗎。別說這跟中文維基無關，因為你們現在就是以部署機器人在中文維基為前提，理所當然是很合理的質疑。還有就是我前面講過的，（2）Commons上有形形色色的人，請問中文使用者在Commons上遇到糾紛時，中文社群有足夠的人力協助周旋嗎。在我看來這些方面目前都是缺乏具體對策的。--章安德魯（留言） 2022年3月23日 (三) 18:29 (UTC)[回复]
赞同--Yinyue200（留言） 2022年3月26日 (六) 06:29 (UTC)[回复]
对于我来说，假如即使我不明白Commons的存废规则，在得知Commons的文件被提删时，我会先把图片保存下来，以便被删除后在本地合理使用。--BlackShadowG（留言） 2022年3月28日 (一) 08:39 (UTC)[回复]
既然如此，可以要求机器人发布消息时直接调用本wiki的罐头信息吗（如展开某个模板），由本地维护和处理为可地区化的消息，或直接引导到本地的有共享资源经验的团队。如果phab那边没空改，也可设立机器人二度改掉与通知。看了一下，只有十几条消息，讨论用哪个变体有意义但又意义不大……是否要中文版不置可否。bot flag如果加上，监视条目的用户能得到通知吗。如果担心新人去Commons捣乱，设法延迟此通知是否可能和有用呢，如速删立即，其他提删2天或3天后再留言通知，以减少莽撞留言。从工具说明来看，该机器人似乎可以留下非展开的模板，以及可能定制延迟参数（修改源码）。从源码来看自定义延迟难度较大。能否通过翻译消息展开本地模板需要做测试。--YFdyh000（留言） 2022年4月2日 (六) 05:48 (UTC)[回复]
@YFdyh000、Stang：「bot flag如果加上，監視條目的用戶能得到通知嗎」，bot flag與通知功能無關/不影響。--Xiplus#Talk 2022年4月15日 (五) 01:31 (UTC)[回复]

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

Category 页面的次级标题存在冗余的“分类”二字

於Phabricator查看
編號T302161的工單

在 Category 页面的次级标题中，重复出现了“分类”一词。例如 Category:自然科学 这个页面，其第二个次级标题为「分类“分类:自然科学”中的页面」，对比英维的相应页面，该标题作「Pages in category "Natural sciences"」，可见本站应删去此处的“分类:”字样，希望管理人员能处理一下这个 bug。--蕭漫（留言） 2022年2月19日 (六) 17:52 (UTC)[回复]

在“不转换”模式下是正常的，其他变体都有问题。 Stang★ 2022年2月19日 (六) 18:09 (UTC)[回复]

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

Chembox模板更新（技术）

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

先前Chembox模板需要更新的内容已讨论完毕，参见Template_talk:Chembox#Chembox模板更新，模板修改涉及技术问题，希望有熟悉代码的进行更新。--Leiem（留言·签名·维基调查） 2022年2月23日 (三) 06:23 (UTC)[回复]

建議再具體統整一次有什麼需要修改之處。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年4月2日 (六) 08:59 (UTC)[回复]
发现个外部链接问题Wikipedia:互助客栈/条目探讨#模板：Chembox。管理员已经更新。--Kethyga（留言） 2022年4月15日 (五) 02:05 (UTC)[回复]

Template:DNA

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

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

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

在2022年4月24日 (日) 15:57 (UTC)時刻我檢查您提供的連結標題顯示已恢復正常。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年4月24日 (日) 15:57 (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)[回复]
Resolved
--在下荷花，请多指教（欢迎签到） 2022年4月25日 (一) 00:28 (UTC)[回复]
@SD hehua： 以此为例，点进去的一瞬间还是会闪一下那一大长串字的。--Bigbullfrog1996（𓆏） 2022年4月26日 (二) 01:24 (UTC)[回复]
@Bigbullfrog1996嘛，这玩意是用js做的临时措施，闪一下应该是正常情况，毕竟不是根本上解决的。--在下荷花，请多指教（欢迎签到） 2022年4月26日 (二) 01:28 (UTC)[回复]

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

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

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

如果实在不行那我考虑另外建模板吧，所有模板分红链版和绿链版。--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}}」→「雪菲」；③持有Q編號和P編號都可以查詢相應中文名稱；④「链Wikidata是ill效果」並非，兩年前已有{{WikidataLink}}，是「ilh效果」，例如「{{WikidataLink|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)[回复]

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

修改CS1系列引文格式模板（第四阶段）：新增name-list-style参数并增加“&”格式，新增url-access参数并兼容既有registration、subscription参数

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

已通過
无反对意见，已通过。--Antigng（留言） 2022年4月12日 (二) 08:18 (UTC)[回复]
下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。
有生之年系列，您辛苦了。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年3月27日 (日) 19:45 (UTC)[回复]
(＋)支持，url-access终于来了，您辛苦了。--BlackShadowG（留言） 2022年3月27日 (日) 23:58 (UTC)[回复]
旧有的“|last-author-amp=”参数在填写yes或ture后也会在最后两名作者之间生成“&”符号，不知引入新参数后是否能兼容这个旧参数？若像英维那样删除这个旧参数，估计会导致本站使用该参数的页面出现红字警告，需安排机器人逐一将“last-author-amp=yes”替换为“name-list-style=amp”。此外，上次更新时加入的 CN 号参数链接已经失效，原因是新闻出版署的网页定位符改成了纯数字的 id，而不再是之前的 CN 号，由此导致本站的 CN 号链接无法指向正确页面（目前维基数据也还在沿用之前的失效链接，未作出任何更新）。
链接变更情况如下：
若新闻出版署的网页不再使用 CN 号作为定位方式，那旧链接将永久失效，这种情况下除了移除失效链接外，是否还有更好的处理方式？比如通过某种技术手段，让 CN 号能够跳转至新闻出版署的当前页面？若只能移除链接而无其他解决方案，CN 号参数的参考价值将大打折扣，甚至可能没有再保留该参数的必要。--蕭漫（留言） 2022年3月28日 (一) 17:17 (UTC)[回复]
(：)回應，1.兼容，优先级last-author-amp>name-list-style/name-list-format。事实上先后这四次CS1的更改都是本着“不废弃既有参数，兼容新参数，如无必要尽可能不改变既有显示方式”的原则进行的。2. 目前暂无解决方案。--Antigng（留言） 2022年3月29日 (二) 01:12 (UTC)[回复]
关于既有显示方式，建议在后续修改中按照英维改进两点：
  1. 在填写了作者或编者参数时，年份或日期以半角括号括起，显示于作者或编者之后；未填写作者或编者时，年份或日期不带括号，显示于出版者之后 （即维持现有的显示格式）。
  2. 为各类 id（ISBN、doi、pmc……）前部标示 id 类型的文字添加内链，使其不再与后方的字符串合为一个指向外部的整体链接，便于读者快速直接地获知各类 id 的信息。--蕭漫（留言） 2022年3月29日 (二) 14:39 (UTC)[回复]
再下一个版本将是主模块的大幅度拆分与重构，同时修复一些bug/微调一些格式。抱歉可能您提到的其中一些功能可能要下下个版本才能实现。--Antigng（留言） 2022年3月30日 (三) 16:17 (UTC)[回复]
最后一条意见于七日前留下。现公示七日。--Antigng（留言） 2022年4月6日 (三) 05:21 (UTC)[回复]
注意到还有个“chapter-url-access”参数，不知这次是否一同引进？该参数用于书籍章节的链接，若某本书的被引章节乃至全书均有一定的访问限制时，便有必要使用该参数，引文示例大概如下：
  • Jefferies, R.P.S. The Origin of Chordates — A Methodological Essay需註冊. House, M.R. (编). The Origin of Major Invertebrate Groups需註冊. London; New York: Academic Press for The Systematics Association: 443–447. ISBN 0123574501. LCCN 78-73884. OCLC 5844063. NLC 000271189.
--蕭漫（留言） 2022年4月8日 (五) 14:33 (UTC)[回复]
  • 已经做好了，将于再下一个版本引进：
当前版本：Glut, Donald F. Appendix: Dinosaur Tracks and Eggs. Dinosaurs: The Encyclopedia. 3rd Supplement. Jefferson, North Carolina: McFarland & Company, Inc. 2003: 613–652. ISBN 0-7864-1166-X.  已忽略未知参数|chapter-url-access= (帮助)
引入该参数之后的效果：Glut, Donald F. Appendix: Dinosaur Tracks and Eggs需要免费注册. Dinosaurs: The Encyclopedia. 3rd Supplement. Jefferson, North Carolina: McFarland & Company, Inc. 2003: 613–652. ISBN 0-7864-1166-X. 

--Antigng（留言） 2022年4月10日 (日) 14:49 (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)[回复]

Template:DNA

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

Template:DNA

修改CS1系列引文格式模板（第五阶段）：新增chapter-url-access、map-url-access参数；临时修复语言代码显示问题；改善模板信息的显示方式；模板内部逻辑大规模拆分整理

本主題或以下段落文字，在討論結束後應存檔至Module talk:Citation/CS1、Module talk:Citation/CS1/COinS、Module talk:Citation/CS1/Configuration、Module talk:Citation/CS1/Error、Module talk:Citation/CS1/Identifiers、Module talk:Citation/CS1/People、Module talk:Citation/CS1/Languages、Module talk:Citation/CS1/Utilities、Module talk:Citation/CS1/Whitelist。

已通過
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

本站CS1系列模板先后历经四轮小规模更新，目前英文站模板较常用而本站模板过去没有的参数，如url-access，url-status，name-list-style，各种文献标识符及对应的-access参数均在这四轮更新中逐步引进。Category:含有未知参数的引用的页面中页面的数量也从去年的四千余个降低至目前的约1500个 ，足见更新之成效。本轮CS1模板更新，表面上主要涉及以下三方面：

  • 一是启用chapter-url-access（section-url-access为其别名）和map-url-access参数，分别用于填写chapter-url（section-url）和map-url的访问状态（有限度免费访问/需要注册/订阅等）。效果如下：
  • 二是临时在本地修复了由于mediawiki内部代码缺乏更新而引起的语言参数不正常显示的问题。见上方讨论。
  • 三是调整完善了模板的一些显示方式，特别是错误信息的显示，较为明显的改动有：
    • a. 本轮更新后，模板未填写作者（author系列参数）或贡献者（contributor系列参数），但填写编者（editor系列参数）时，模板将依所填写的编者参数生成元数据（COinS）作者栏位的信息。考虑到部分性质的来源（如百科全书），编者等同于实质上的作者，这一处理应当是合理的。
    • b. CS1系列模板中各模板支持的参数略有不同。例如，{{cite news}}模板填写卷（volume参数）是没有意义的，{{cite book}}模板填写邮件列表（mailing-list）参数是没有意义的。现在模板的处理方式是直接丢弃这些参数而不告知使用者。本轮更新后，遇到相应的情况模板会红字报错，并将页面纳入追踪分类Category:引文格式1错误：已知参数被忽略。这有助于编者及时发现参数使用方面的错误（其中有一些还很隐蔽，例如bookTitle参数很容易被“望文生义”成“书名”，但实际上仅有{{cite conference}}模板支持，{{cite book}}模板反而不支持）。以下是一些例子：
      • 例2b1：
        {{cite book| author=Herbst, T. M.; Rix, H.-W.|year=1999 |editor=Guenther, Eike; Stecklum, Bringfried; Klose, Sylvio|title=Star Formation and Extrasolar Planet Studies with Near-Infrared Interferometry on the LBT |book-title=Optical and Infrared Spectroscopy of Circumstellar Matter, ASP Conference Series, Vol. 188. |isbn=1-58381-014-5|pages=341–350 |bibcode=1999ASPC..188..341H |publisher=Astronomical Society of the Pacific |location=San Francisco, Calif.}} 注：bookTitle参数仅{{cite conference}}模板支持
      • 更新前：Herbst, T. M.; Rix, H.-W. Guenther, Eike; Stecklum, Bringfried; Klose, Sylvio , 编. Star Formation and Extrasolar Planet Studies with Near-Infrared Interferometry on the LBT. San Francisco, Calif.: Astronomical Society of the Pacific. 1999: 341–350. Bibcode:1999ASPC..188..341H. ISBN 1-58381-014-5.  |book-title=被忽略 (帮助)
      • 更新后：Herbst, T. M.; Rix, H.-W. Guenther, Eike; Stecklum, Bringfried; Klose, Sylvio , 编. Star Formation and Extrasolar Planet Studies with Near-Infrared Interferometry on the LBT. San Francisco, Calif.: Astronomical Society of the Pacific. 1999: 341–350. Bibcode:1999ASPC..188..341H. ISBN 1-58381-014-5.  |book-title=被忽略 (帮助)
      • 例2b2：
        {{cite web| author=Vijverberg et al. | title=Similar mode of action of pyrethroids and DDT on sodium channel gating in myelinated nerves | url=http://www.nature.com/nature/journal/v295/n5850/abs/295601a0.html | journal=Nature | volume=42 | issue=295 | year=1982 | accessdate=2012-04-28}}注：{{cite web}}不支持volume与issue
      • 更新前：Vijverberg; et al. Similar mode of action of pyrethroids and DDT on sodium channel gating in myelinated nerves. Nature. 1982 [2012-04-28].  参数|journal=与模板{{cite web}}不匹配（建议改用{{cite journal}}或|website=） (帮助); |volume=被忽略 (帮助); |issue=被忽略 (帮助)
      • 更新后：Vijverberg; 等. Similar mode of action of pyrethroids and DDT on sodium channel gating in myelinated nerves. Nature. 1982 [2012-04-28].  参数|journal=与模板{{cite web}}不匹配（建议改用{{cite journal}}或|website=） (帮助); |volume=被忽略 (帮助); |issue=被忽略 (帮助)
      • 例2b3：
        {{cite journal/Antigng|author=許宗傑| title=《清代澎湖方志研究》 | date=2011-01 | degree=中國文化大學中國文學系碩士 |url=https://hdl.handle.net/11296/723f6b | pages=15-16 | registration=yes }}注：仅{{cite thesis}}支持degree参数
      • 更新前：許宗傑. 《清代澎湖方志研究》需要免费注册: 15–16. 2011-01.  |degree=被忽略 (帮助)
      • 更新后：許宗傑. 《清代澎湖方志研究》需要免费注册. 2011-01: 15–16.  |degree=被忽略 (帮助)
    • c. 此外，引用模板内部的参数之间存在较为复杂的关系，可能出现“某个参数填写以后另一个参数的值被丢弃”的情况。当前模板的做法是直接丢弃有关参数。本轮更新后，将尽可能地以红字报告“只需其一”错误，方便编者查错。如下例所示：
      • 例2c：
        {{cite web|title=Title|url=http://example.com/|quote = "this is a test"|postscript = "test"}}注：quote参数填写后，post-script参数会被丢弃
      • 更新前：Title. this is a test  |quote=和|postscript=只需其一 (帮助)
      • 更新后：Title. this is a test  |quote=和|postscript=只需其一 (帮助)
    • d. 特别地，当日期与年份同时填写，两者的参数值都有效，但彼此不兼容的情况下，将红字报错：
      • 例2d：
        {{cite web|title=Title|url=http://example.com/|date=2020-01-01|year=2021}}
      • 更新前：Title. 2020-01-01.  |year=与|date=不匹配 (帮助)
      • 更新后：Title. 2020-01-01.  |year=与|date=不匹配 (帮助)
    • e. 最后，完善了部分界面文字的显示方式：
      • 例2e1：
        {{cite thesis|title=xxx研究|publisher=xx大学学报|year=2022}}
      • 更新前：xxx研究 (学位论文). xx大学学报. 2022. 
      • 更新后：xxx研究 (学位论文). xx大学学报. 2022. 
      • 例2e2：
        {{cite speech|title=Economic Isolationism Isn't an Option|first=Mike |last=Eskew |author-link= |event=Executive Speeches |location=Washington, D.C. |date=December 30, 2004 |url= |access-date= |medium=演讲 }}
      • 更新前：Eskew, Mike. Economic Isolationism Isn't an Option (演讲). Executive Speeches. Washington, D.C. December 30, 2004. 
      • 更新后：Eskew, Mike. Economic Isolationism Isn't an Option (演讲). Executive Speeches. Washington, D.C. December 30, 2004. 
      • 例2e3：
        {{cite book |title=Title |url=//example.com |archive-url=//archive.org |archive-date=2020-07-29 |url-status=bot: unknown}}
      • 更新前：Title. （原始内容存档于2020-07-29）.  无效|url-status=bot: unknown (帮助)
      • 更新后：Title. （原始内容存档于2020-07-29）.  无效|url-status=bot: unknown (帮助)
      • 例2e4：
        {{cite newsgroup |title=Title |newsgroup=sommat.sommat.sommat |publisher=Publisher}}注：当前模板显示实际上没有填写的|url=参数有问题，是因为模板的内部逻辑将输入的|publisher=参数当成url的一部分处理，更新后已正确反映这一点
      • 更新前：Title. Newsgroup: Publisher 请检查|publisher=值 (帮助).  |newsgroup=和|publisher=只需其一 (帮助)
      • 更新后：Title. Newsgroup: Publisher 请检查|publisher=值 (帮助).  |newsgroup=和|publisher=只需其一 (帮助)

最后，欢迎大家用沙盒版本的CS1模板（例如：{{Cite web/Antigng}}，{{Cite book/Antigng}}）进行测试。--Antigng（留言） 2022年4月12日 (二) 17:34 (UTC)[回复]

@Antigng 请问，{{cite book}}里面的 id={{XXX}}，这个参数id的选项是否可以多加几个，比如说几十年前没有ISBN、且没有录入OCLC的书籍，用类似NDL 12345677. NLC 12345677去定位。--Kethyga（留言） 2022年4月13日 (三) 02:48 (UTC)[回复]
@Kethyga：目前引文模板中|id=参数起到的就是后备用途，也就是所有模板本身没有支持的文献标识符参数都可以填写在|id=参数中；该参数没有任何格式上的限制，想填什么填什么。当然如果您的需求是像|doi=，|pmid=一样另设文献标识符参数并统一格式，可以在后续更新中予以考虑。由于本人对之不甚熟悉，可能需要麻烦您提供相关参数的定义，以及合法的范围等信息。--Antigng（留言） 2022年4月13日 (三) 03:22 (UTC)[回复]
重新测试了下，Special:diff/71124395，可以用形如|id={{NLC|12345678|01}}. {{NDL|12345678}}的方式添加多个。之前想法固定在只能添加一个模板上了。--Kethyga（留言） 2022年4月13日 (三) 06:35 (UTC)[回复]
(！)意見：目前沙盒版本“chapter-url-access=free”会出现“可免费查阅”的绿锁，但根据英文版的解释，一般而言这类网址是被假定为可免费访问，所以兼容free参数值是没有必要的。应该是：
  • url-access/article-url-access/chapter-url-access/contribution-url-access/entry-url-access/map-url-access/section-url-access = registration / limited / subscription
  • bibcode-access / doi-access / hdl-access / jstor-access / ol-access / osti-access / s2cid-access = free--BlackShadowG Pray for Ukraine 2022年4月14日 (四) 13:25 (UTC)[回复]
简单来说，编者提供的链接（如：url、chapter-url）默认是能免费查阅的，只需要标记需要付费或注册的即可；文献标识符自动生成的链接（如：doi、jstor）默认是不能免费查阅的，只需要标记免费的即可。--BlackShadowG Pray for Ukraine 2022年4月14日 (四) 13:31 (UTC)[回复]
已修正，请复查。--Antigng（留言） 2022年4月14日 (四) 14:38 (UTC)[回复]
公示七日。--Antigng（留言） 2022年4月20日 (三) 15:31 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

優良條目展示報告未顯示

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:首頁/優良條目展示報告。

2021年4月16日首頁的優良條目世界遺產在優良條目展示報告並未有顯示展示時間，望有人能協助機器人修改這個錯誤，感謝！--CBNWGBB（留言） 2022年4月16日 (六) 02:41 (UTC)[回复]

@Kanashimi君看看。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年4月24日 (日) 16:25 (UTC)[回复]
維基百科:優良條目/2021年4月16日似乎不是世界遺產?--Kanashimi（留言） 2022年4月26日 (二) 21:22 (UTC)[回复]
@CBNWGBB。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年4月28日 (四) 00:03 (UTC)[回复]
@Kanashimi我打錯時間了啊啊啊啊，應該是2022年4月16日的世界遺產，麻煩Kanashimi君能幫忙讓世界遺產在優良條目展示報告顯示展示時間。CBNWGBB（留言） 2022年4月28日 (四) 00:40 (UTC)[回复]
@Kanashimi也能順便麻煩您清理一下優良條目展示報告的問題頁面嗎😢？CBNWGBB（留言） 2022年4月28日 (四) 00:46 (UTC)[回复]
清理過維基百科:首頁/特色內容展示設定的cache後已回復正常。近來比較忙，其他問題頁面可能有時間再看看。--Kanashimi（留言） 2022年4月28日 (四) 13:25 (UTC)[回复]

參考文獻模板的問題

按理而言，在{{reflist}}中插入了參考文獻後，在內文不顯示應該要報錯，但是目前不會顯示，請問這是feature還是個bug？

reflist：

  1. ^ 朱耀偉. 書評：Readings in Chinese Literary Thought. 人文中國學報. 
  2. ^ 樂黛云. 突破中西文體系的“雙向闡發”——介紹《中國文論:英譯與評論》. 社會觀察. 2003, (S1): 44-45. 
  3. ^ 邸小松; 王確. 在中國發現文學理論——評宇文所安《中國文論:英譯與評論》. 中國文學研究. 2016, (1): 118-121. 

<references>：

引证错误：在<references>标签中name属性为“朱耀偉”的参考文献没有在文中使用
引证错误：在<references>标签中name属性为“樂黛云”的参考文献没有在文中使用
引证错误：在<references>标签中name属性为“邸小松”的参考文献没有在文中使用

依我認為應該還是要報錯以提醒編者為宜，以避免參考文獻出現空引注的問題，而且參考文獻在內文不使用不應該是一個正常現象。Ghren🐦🕒 2022年4月17日 (日) 19:32 (UTC)[回复]

您把reflist用錯了，參考文獻是放在{{{refs}}}，不是放在{{{1}}}。正確的樣本見此，可正常報錯。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年4月20日 (三) 03:31 (UTC)[回复]
啊... 囧rz……。不好意思了，問了個蠢問題。--Ghren🐦🕚 2022年4月21日 (四) 15:27 (UTC)[回复]
似乎我是被{{notelist}}的用法誤導了。--Ghren🐦🕒 2022年4月22日 (五) 07:17 (UTC)[回复]

Template_talk:Welcome#为什么这个模板的内容和用户讨论页中的内容不一样？的相關討論

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

诚邀阁下参与Template_talk:Welcome#为什么这个模板的内容和用户讨论页中的内容不一样？的相關討論。--GUT412454（留言） 2022年4月19日 (二) 02:03 (UTC)[回复]

本主題或以下段落文字，移動自模板讨论:Welcome。执行者：在下荷花，请多指教（欢迎签到） 2022年4月25日 (一) 00:32 (UTC)。[回复]

这个模板中有有偿编辑这一项，而用户讨论页的内容中没有这一项。--GUT412454（留言） 2022年2月7日 (一) 13:55 (UTC)[回复]

我想这应该是机器人没有更新的原因。--GUT412454（留言） 2022年4月19日 (二) 02:02 (UTC)[回复]
@GUT412454用户讨论页的模板替换引用过了，不会更新为新版本--在下荷花，请多指教（欢迎签到） 2022年4月19日 (二) 03:21 (UTC)[回复]
那些新加入的模板（比如User_talk:王立妍上的模板）也是旧版本。--GUT412454（留言） 2022年4月19日 (二) 05:26 (UTC)[回复]
@SD_hehua：所以应该不是这个原因--GUT412454（留言） 2022年4月19日 (二) 10:54 (UTC)[回复]
@GUT412454恐怕是新用户欢迎的配置问题，[7]试了试没问题--在下荷花，请多指教（欢迎签到） 2022年4月19日 (二) 11:03 (UTC)[回复]

如何避免讓大家在翻譯條目時使用無用模板跟錯誤追蹤分類？

如題，模板部分像英文維基才有效的Template:short description，分類部分有Category:內容翻譯維護分類中的子分類跟不少隱藏分類，導致Category:带有简短描述的條目等追蹤分類內容越來越多。分類部分似乎是翻譯工具自行帶上所以我有去mediawiki那邊反應，short description則似乎是使用者直接從原文條目複製貼上比較麻煩，希望可以有效阻止，謝謝。--迴廊彼端（留言） 2022年4月19日 (二) 13:29 (UTC)[回复]

社群如果真有停用这模板的共识，我看贵方可以直接去提过滤器请求了虽然很有可能会等很久。--185.217.119.9（留言） 2022年4月19日 (二) 23:49 (UTC)[回复]
謝謝IP君的啟發，也想請教User:Tjmj您的看法，我目前傾向加入過濾器以防止未來花更多時間清理。--迴廊彼端（留言） 2022年4月29日 (五) 17:17 (UTC)[回复]

我把“Category:全部設置索引條目”搞坏了，对不起

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

我看到“Category:全部設置索引條目”名字翻译得不对（站内一致是叫“同类索引”），心想着我能找到加这个分类的模板把它改了，就先顺手移动到Category:全部同類索引條目去了。移好之后我傻眼了：我看了看{{set index}}的模板，也没找到插入这个分类的代码…………

我现在：

  • 首先是没办法把页面移回去。这问题其实也不大，毕竟分类重定向不会真的把页面重定向过去。
  • 其次是很想找到哪里插入这个分类的把它改掉，但我真的找不到。
  • 最后是希望把Template、Wikipedia、Help、Category三个名字空间里的“設置索引”都看一眼，应该改正翻译的都改了。我不知道这个和TWN有没有关系，有的话也要改。这个我自己能做。

对不起。对不起。--Artoria2e5编 讨论要完整，回覆请用ping。 2022年4月21日 (四) 03:22 (UTC)[回复]

Template:Dmbox#L46。@Artoria2e5： Stang★ 2022年4月21日 (四) 09:29 (UTC)[回复]
Template talk:Dmbox。--紺野夢人 2022年4月21日 (四) 10:34 (UTC)[回复]
分类问题应已解决。--东风（留言） 2022年4月22日 (五) 04:45 (UTC)[回复]

reflist 与 authority control

本主題或以下段落文字，在討論結束後應存檔至Template talk:Reflist、Template talk:Authority control。

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

模板{{reflist }}与模板{{authority control}}之间如果没有空一行，authority control就不会显示，不知道是否是被reflist覆盖了。见Special:diff/71276375--Kethyga（留言） 2022年4月23日 (六) 05:37 (UTC)[回复]

我似乎能在上面的diff看到authority control？--Hamish with w. 2022年4月23日 (六) 09:37 (UTC)[回复]
同上，此版本未见显示问题。--YFdyh000（留言） 2022年4月23日 (六) 09:45 (UTC)[回复]
目前显示正常了……Kethyga（留言） 2022年4月23日 (六) 09:54 (UTC)[回复]
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

2022年第17期技术新闻

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

最近更改

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

本週後期變更

  • MediaWiki新版本將於4月26日部署至測試維基及MediaWiki.org，於4月27日部署至非維基百科站點及部分维基百科，於4月28日部署至所有站點，參見日曆。
  • 出于定期数据库维护的原因，某些维基站点将进入只读模式数分钟。维护将于4月26日7:00 (UTC) 对s2数据库组的维基站点进行。
  • 部分非常旧的浏览器和操作系统将不受支持。在Internet Explorer 9或10、Android 4、Firefox 38及更旧版本上，维基站点上的部分内容会看上去很奇怪或无法正常工作。 [10]

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

中维就在S2。 --MilkyDefer 2022年4月26日 (二) 02:53 (UTC)[回复]

2022年4月25日 (一) 22:53 (UTC)

谁帮忙找一下引用错误

User:Neonlight185/沙盒，东西都写完了，不知道出错的地方在哪--Neonlight185（留言） 2022年4月26日 (二) 00:59 (UTC)[回复]

@Neonlight185：我做了这笔编辑，帮您改好了。--50829! Talk · 496,547,958 2022年4月26日 (二) 01:14 (UTC)[回复]
感謝！--Neonlight185（留言） 2022年4月26日 (二) 02:35 (UTC)[回复]

模板超限問題

冠狀病毒條目幾週前還正常，但現在突然出現模板超限的問題（4月25日已超限，當時有維基人將{{Reflist}}替換成<reference/>以避免參考文獻顯示異常），期間條目並沒有任何改動，且現在查看去年的條目版本也會出現模板超限的問題，顯見此問題是其他模板的編輯連帶影響了本條目，而非本條目本身編輯所致。有沒有懂技術的幫忙看一下？謝謝。--Sanchytriomycota🧬 2022年4月26日 (二) 08:34 (UTC)[回复]

@Antigng：可能和你近期的编辑有关。清空Module:Citation/CS1/Antigng预览该條目不会超限。--Lt2818（留言） 2022年4月26日 (二) 09:55 (UTC)[回复]
(：)回應，今天晚些时候将更新CS1模块，见上方讨论。由于新旧模块不兼容，为避模块逐个修改/调试期间引用模板显示不正常，拟采用倒接方案，即在各引用模板中插入“倒接开关”{{cutover}}；通过操作{{cutover/switch}}可将全部的引用模板一次性切换为沙盒版本。这样就可以安全地修改Module:Citation/CS1系列模块。同时，如果沙盒版本发现了任何之前未发现的bug，都可以通过{{cutover/switch}}迅速切换回旧版本。
采用这种方案的一个副作用就是模板更容易超出限制产生如您所报告的问题，但这是临时性的：模块正式“割接”后，将陆续拆除“倒接开关”，届时条目也会恢复正常。目前有类似问题的条目数量并不多，本人也会持续做好监测工作。--Antigng（留言） 2022年4月26日 (二) 10:26 (UTC)[回复]
@Cookai1205 ：你的名字問題是因為這裏才出現的，在這個問題解決後有需要可以加回轉換組。另外，出現類似問題的不至上面的，有些條目只是炸了Navbox，又或者只是炸了些少參考模板。可以的話這個倒接開關還是和正式修改時間距離越短越好。--Ghren🐦🕖 2022年4月26日 (二) 11:49 (UTC)[回复]
有问题的条目不止这些，如蔣經國、毛泽东条目末尾导航模板亦受影响。Category:引用模板后大小超过限制的页面现有428个页面。损害已经不容忽视，这种修改方式不宜成为今后常例。--Lt2818（留言） 2022年4月26日 (二) 14:29 (UTC)[回复]
應該只有200個頁面左右受影響，今天沒有了cutover之後只有251個頁面超出限制。--Ghren🐦🕒 2022年4月27日 (三) 07:44 (UTC)[回复]
这里尽可能简单地解释一下采用“倒接方案”的技术背景：
首先，Module:Citation/CS1模块是极高使用量模块。对极高使用量模块进行的修改须以确保“无感”为前提；不能进行任何有潜在导致大量条目出现错误的风险的操作。
第二，Module:Citation/CS1不是单一一个模块，而是一系列模块，需要与Module:Citation/CS1/Configuration等一系列的子模块配合工作。mediawiki不允许批量提交页面修改，如果一个模块一个模块手动提交修改，而新旧版本的模块又彼此不兼容，那么有可能出现“某个模块先更新，但与之配套的模块没有随之更新”导致的报错。如果刚提交完某个模块的修改，接着就断网了或是浏览器崩溃了，没法及时提交配套模块的修改，那后果就可能很严重。这种风险是不能容忍的。
本次CS1模块的大更新就涉及这方面的问题。具体来说，主模块Module:Citation/CS1与子模块Module:Citation/CS1/Configuration，无论先更新何者，都会产生不兼容性，有引起大面积报错的风险：
新版本Module:Citation/CS1用到了新版本Module:Citation/CS1/Configuration中的periodical表，而这是旧版本Module:Citation/CS1/Configuration中没有的；
旧版本Module:Citation/CS1用到了旧版本Module:Citation/CS1/Configuration中的message['subscription']，而新版本Module:Citation/CS1/Configuration已将上述冗余代码删除。
当然，除Module:Citation/CS1/Configuration之外，本次修改还涉及Module:Citation/CS1/Utilities和Module:Citation/CS1/Identifiers，主模块与三个既有子模块之间存在复杂的相互依赖关系，更增加了不兼容而导致错误的风险。
因此，唯一可行的方法即是将所有CS1系列引用模板先“切换”到已经修改、调试完成的沙盒版本Module:Citation/CS1/Antigng，待Module:Citation/CS1下线之后，便可安全地对其及相关子模块进行修改和调试，再之后便可“切换”回正式版本。
此外，由于本次CS1模块更新力度大而既有测试用例覆盖面不够广，需使用线上环境对新版本的模块进行调试。一旦发现之前测试中未发现的bug，需第一时间下线新版本的模块，切换回旧版本的模块。
基于上述考虑，本次修改采用“倒接开关”{{cutover}}模板实现正式/沙盒版本模块的快速切换。大约一周以前，风险最低的{{cite interview}}、{{cite thesis}}等模板接入倒接开关，随后进行了几轮倒接试验，其间确实发现并修复了一些测试中未能发现的bug。之后，按照风险由低到高的顺序，{{cite encyclopedia}}、{{citation}}、{{cite journal}}也陆续接入“倒接开关”并参与试验；最终于昨日将“三大引用模板”{{cite news}}、{{cite book}}、{{cite web}}一次性接入“倒接开关”，模块“倒接”完成。

--Antigng（留言） 2022年4月27日 (三) 16:05 (UTC)[回复]

基本上是把替换变成原子操作，但“倒接开关”本身的开销不容忽视。不用倒接开关的办法也不是没有：测试新CS1模块可将上游模板直接调用测试版本；修改CS1模块时开多个编辑窗口尽量同时点击发布，怕断网或浏览器崩溃亦可先提醒其他管理员留意，若出现不一致则及时回退。--Lt2818（留言） 2022年4月28日 (四) 02:09 (UTC)[回复]
與其盡量同時點擊發布，不如用api比較快吧......--SunAfterRain 2022年4月28日 (四) 12:36 (UTC)[回复]

為什麼Copyvio加不上黑名單網站

如題，我在提報侵權時被垃圾過濾器擋掉了，想請教一下有沒有什麼解決辦法----烏●克●蘭 2022年4月26日 (二) 11:24 (UTC)[回复]

没什么办法。网址中间放些东西截断，能看懂就可以。--YFdyh000（留言） 2022年4月26日 (二) 12:29 (UTC)[回复]
网址不加 https/http，不过不要滥用。--Kethyga（留言） 2022年4月26日 (二) 12:33 (UTC)[回复]
例如：www.example.com→www.exam<!---->ple.com。--12З4567（留言） 2022年4月26日 (二) 16:55 (UTC)[回复]
那麼再請教一下，能夠用TinyURL繞過去嗎？----烏●克●蘭 2022年4月27日 (三) 02:10 (UTC)[回复]
如果短链接本身没被屏蔽。但这没必要且不好，如果短链接服务失效，后人就很难重新查证了。--YFdyh000（留言） 2022年4月27日 (三) 02:36 (UTC)[回复]
謝謝。後來才發現短連也會被擋。----烏●克●蘭 2022年4月27日 (三) 03:01 (UTC)[回复]
如果用TW提交的话，我记得会将http头转换成实体字符来代替，用于避开过滤器的。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月27日 (三) 03:56 (UTC)[回复]

Template:Infobox station

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

之前我分拆了貴生川站、熱海站和薄野站時在上面加入了Template:Infobox station，不過它無論怎樣都會顯示車站圖片和位置，即使我只用{{日本車站資訊}}，這是見鬼了嗎？有沒有人可以幫我找出問題？Choi Chin Long 歡迎簽名 2022年4月27日 (三) 05:15 (UTC)[回复]

请阅读文档：车站图片，请不要添加File:,直接填写名称即可。如果没有填写会尝试从维基数据源调取第一张照片。不限于最新的站台照片。--Tim Wu（留言） 2022年4月27日 (三) 05:31 (UTC)[回复]

Twinkle维护模板的默认参数

使用Twinkle加入维护模板，条目会被加入隐藏分类​Category:模板中使用无效日期参数的条目。-- ★WPTO★ 2022年4月27日 (三) 08:17 (UTC)[回复]

分類必須建立，要由機器人自動建立，母分類必須如此標記 Special:Diff/71342557。--Xiplus#Talk 2022年4月27日 (三) 09:22 (UTC)[回复]

引入英维新版rater

英文版的旧版rater已被新版的en:User:Evad37/rater取代，望擅长这方面的人士帮忙更新中维的对应工具，谢谢各位。--BlackShadowG Pray for Ukraine 2022年4月27日 (三) 11:18 (UTC)[回复]

在很久很久以前@Ericliu1912有过尝试，我当时的意见是移植很难。如果有人愿意写个更鲁棒一些的版本我倒是愿意提供协助。--MilkyDefer 2022年4月27日 (三) 11:50 (UTC)[回复]
要是您能給我解說一下這工具的原理，正常的來肝應該是能行的。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年4月27日 (三) 14:52 (UTC)[回复]
大致上需要解析讨论页上的专题评级模板（专题评级模板的定义是位于评级模板分类中的模板），提取里面的参数，并且提供写入。说的简单，实际上涉及到比如说各个专题模板支持参数的不同（比如VG专题特有的小列表等级什么的），以及GUI的构建。--MilkyDefer 2022年4月28日 (四) 06:30 (UTC)[回复]
似乎早已讨论过但需要很多配套设施？--YFdyh000（留言） 2022年4月28日 (四) 16:15 (UTC)[回复]
User:YFdyh000/RATER。不清楚有哪些案例不能用，希望了解的讲一下。VG特有参数能否支持我还没细看，英文维基维护分类作用同上。界面简繁用wgUVS(简体,繁体)很好解决，有兴趣的建议提交PR。--YFdyh000（留言） 2022年4月28日 (四) 23:45 (UTC)[回复]
問題跟我的版本一樣。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年4月29日 (五) 01:31 (UTC)[回复]
差不多，但你直接改min.js太那啥了……另外，我觉得命名空间显示本地名称可有可无，英文名兼容性还更好。--YFdyh000（留言） 2022年4月29日 (五) 03:51 (UTC)[回复]
我简要说一下要解决的问题。首先是从专题模版分类中找出专题模版。英维的专题模版主要从四个分类去找，其中有一个是Women什么什么的，这种东西中维完全没有，所以这部分的逻辑需要定制。此外还有从模版名提取专题名的功能，这个功能是用作界面显示用的。英维的专题模版是固定的「Template:WikiProject XXXXX」模式，因此很好提取；中维的专题模版命名格式就非常灵活，比如「Template:WikiProject XXXX」（XXXX可以是英语也可以是中文）、「Template:XXX专题」（可以是简体中文，也可以是繁体中文），不统一，因此很麻烦。英维支持利用机器学习自动为专题提供条目品质预测，这项服务中维不提供，所以相关功能要完全屏蔽。还有的话，这个rater检测一个专题有哪些重要度或者品质等级的方式是将自己知道存在的重要度等级和品质等级两两配对，比如「XX级重要度YY级ZZ条目」，检测有没有叫这个名字的分类。恕我直言，这个方法很蠢。--MilkyDefer 2022年4月29日 (五) 03:36 (UTC)[回复]
那个是英维WikiProject:當紅女人的大量模板，直接删掉应该就好。名称问题我之后看。机器学习那个，测试没看到出问题，且默认关掉/隐藏就行。是中文的分类命名比较随意吗。“重定向”那个选项我不太清楚作用。--YFdyh000（留言） 2022年4月29日 (五) 03: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)[回复]
    1. 又希望建立共識加快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)[回复]

是否能開發搜尋紀錄統計工具

如題，有時候在寫條目時，會思考「讀者是否能成功搜尋到條目」、「讀者最希望看到什麼條目」。但因為現行的瀏覽工具僅能看到已經創立條目的瀏覽量，無法看到未創立的條目。因此希望能夠開發「搜尋紀錄統計工具」，表列讀者最常用的搜尋字串，並排除已有條目的搜尋結果，作為創建條目及創建重定向的思考方向---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)[回复]
我记得以前的搜索是有統計的，现在用的mw:Extension:CirrusSearch不确定有没有。而且现在的搜索功能支持很多的搜索语法，这样即使展示统计，也挺麻烦的，比如要不要过滤掉那些带搜索语法的搜索？--百無一用是書生 (☎) 2022年4月29日 (五) 02:22 (UTC)[回复]

HotCat修改多个分类和保存

本主題或以下段落文字，在討論結束後應存檔至Wikipedia talk:维基百科工具/HotCat。

发现HotCat在添加多个分类的时候需要保存多次，如果在HotCat自动添加的编辑摘要基础上再任意添加一些文字，就能一次直接保存，感觉HotCat已经提供编辑摘要的情况下不太需要多这个步骤，一般情况下也不太会出现分类错误。--Kethyga（留言） 2022年4月29日 (五) 07:26 (UTC)[回复]

HotCat可以一次添加多個分類啊？直接多按末端的加號幾次就行了。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年4月29日 (五) 13:40 (UTC)[回复]
可能没有描述清楚。在点击了左下角的"分类(+)"，开启复变更模式（单次修改/添加多个分类）后，添加分类，再点击左下角"分类(保存)"，会先进入类似编辑预览模式，没有直接保存。--Kethyga（留言） 2022年4月29日 (五) 14:32 (UTC)[回复]
喔這個倒是挺麻煩的。我也希望能夠直接儲存變更。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年4月30日 (六) 03:00 (UTC)[回复]
c:Help:Gadget-HotCat#Intercepting the page edit HotCat will make。--紺野夢人 2022年4月30日 (六) 07:52 (UTC)[回复]

Coming soon: Improvements for templates

Fundamental changes in the template dialog.

Hello, more changes around templates are coming to your wiki soon:

The template dialog in VisualEditor and in the 2017 Wikitext Editor (beta) will be improved fundamentally: This should help users understand better what the template expects, how to navigate the template, and how to add parameters.

In syntax highlighting (CodeMirror extension), you can activate a colorblind-friendly color scheme with a user setting.

Deployment is planned for May 10. This is the last set of improvements from WMDE Technical Wishes' focus area “Templates”.

We would love to hear your feedback on our talk pages!

-- Johanna Strodt (WMDE) 2022年4月29日 (五) 11:14 (UTC)[回复]

模板:Infobox ship begin等子模板合併事宜

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

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

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

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

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