维基百科讨论:模板限制

关于2MB的限制

在en的oldid=779958657（客栈技术版，About some question of Wikipedia:Template_limits）问过能不能加大，有人解释了因为是转化为HTML输出的话，2MB已经不小了，对于其他性能差的用户可能会很糟糕，所以一般2MB为原则上限。——路过围观的Sakamotosan 2017年5月12日 (五) 02:12 (UTC)

模板限制

最近mediawiki对模板限制是否有所增加？一些很简单的条目若套用几个稍微大一点的导航模板（NavBox）就已经无法正常显示，例如托马斯·切赫，在一段时间以前还没有发现这样的问题。请问有没有方法绕过对于导航模板的长度上限或者其他更好的解决办法？受这个问题所影响的条目数量极多，希望能尽快处理。--Alancrh（留言） 2021年2月3日 (三) 03:50 (UTC)

少用几个绿链比啥都强。--GnolizX（留言） 2021年2月3日 (三) 05:42 (UTC)

取消這個不知所謂的模板限制比啥都強。那麼多年來，這個模板限制除了令到某些模板無法顯示之外還有甚麼作用？--49.130.131.165（留言） 2021年2月3日 (三) 06:01 (UTC)

然而不可能取消。虽然不要担心性能，但是编者们也不是什么都不用在乎了。最简单的方法就是在导航模板中干掉不知所谓的绿链，这比啥都强，绿链不知道导的哪门子航，是因为應避免紅字連結所以要用绿链吗？--GnolizX（留言） 2021年2月3日 (三) 06:13 (UTC)

少用幾個綠連+1。綠連的使用時機應該和紅連一致，而不是像藍連的一樣應連盡連。正文中就不說了，紅連本來就是順便的東西，再加個綠連也無妨（而且我認為主要目的是起辨識/原文對照作用，而不是真的期待讓讀者去讀外語條目）。而導航模板、{{main}}、參見章節不是行文的一部分；其目的就是讓讀者點開其他文章擴展閱讀，所以應該連結已存在的文章；提前加入連結本來就屬本末倒置。那這裡使用綠連，意思是引導讀者看不存在的文章，還是引導讀者看非中文文章？當初禁止[[:en:XXX|XXX]]外語直連，大前提之一是就是假定中文維基讀者不懂外文，感覺現在又走回老路了。--洛普利宁 2021年2月3日 (三) 14:45 (UTC)

@GnolizX：如果WP:EXISTING是正式方針指引，WP:MOSIW第二段又被嚴格執行，這裡是無法用綠連的。按WP:MOSIW，綠連的使用前提是“在不过度使用内链的前提下”；所以不能用紅連的場合，是輪不到綠連登場的。只可惜這兩段條文存在感都不高。--洛普利宁 2021年2月3日 (三) 15:07 (UTC)

乾脆寫個論述抱怨一下吧。--洛普利宁 2021年2月3日 (三) 19:42 (UTC)

過度連結的部分是寫在WP:OLINK，雖尚非方針指引，也常被用來清理條目內文。不過導航模板本來就是一堆連結的集合，大概不會算是「過度使用」。綠鏈其實還是有一些好處，比如對有心的編者或是懂英文的讀者。。。--Hjh474（留言） 2021年2月4日 (四) 02:01 (UTC)

有心的编者和懂英文的读者自己看英文版不就好了吗？真有心的读者亲自Google都不嫌累，更何况一个几乎已经送到嘴边的跨语言链接栏？而且如果我懂阿拉伯文但不懂英文，我能否先到先得使用{{link-ar}}，并拒绝其他编者换成英文链接？导航模版对部分读者有一点好处，但问题也不是没有；现在模版超限就是一个例子。

目前的条目都是基于蓝链－红链体系制定的，而绿链有游离于这个体系之外感觉。（我们的体系是照搬英文区的，但他们可没有绿链这东西）包括WP:OLINK在内的条文，都很难清楚的说明绿链使用时机。以导航模版为例，它更准确的说是「一堆已建立条目之链接的集合」，并且明确倾向不收不存在的条目（红链）。那绿链，或者说对纯中文使用者没有帮助的外语维基文章，该算已建立还是没建立的条目？

我上面的论述认为绿链基本视同红链，沿用红链的原则行事即可：不该用红链的地方也不该用绿链。这个意见是符合方针、抵触方针，还是方针没做解释；社群实际上又是否赞同？英文链接是否又比其他外语链接有优先权？（虽然按照WP:MOSIW，只能链接事物关联的外语）绿链的使用的确缺少明白的理论指导。—-洛普利宁 2021年2月4日 (四) 03:13 (UTC)

我倒是觉得导航模板中确实不应该用绿链（尤其是过度使用），虽说方便编者找对应条目去翻译，但对读者没多大帮助，这个问题其实可以交给方针版讨论下。——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年2月4日 (四) 03:35 (UTC)

个人观点，绿链主要是编者可以参考和翻译外文条目，同时让整个体系更完整、减少比较难看且低价值的红链，而非引导读者去阅读外文条目。模板超限怪绿链，为什么不怪导航模板太多太大了？不过，可以研究是否能给{{ilh}}源码瘦身，或其他方法。--YFdyh000（留言） 2021年2月4日 (四) 03:40 (UTC)

如果绿链只是帮助编者的，那么就不应该让读者负担这个问题--百無一用是書生 (☎) 2021年2月4日 (四) 03:45 (UTC)

也有助读者了解完整的体系结构，这是否重要可能有观点分歧。是技术问题，{{Internal link helper}}目前效率不高，T228716。--YFdyh000（留言） 2021年2月4日 (四) 04:10 (UTC)

有助读者了解完整的体系结构，可以用红链。--百無一用是書生 (☎) 2021年2月4日 (四) 06:56 (UTC)

红链存在着原创译名、重复不同译名、来源不明等问题，如果没有“模板限制”问题和外文维基中心考虑，绿链是更优选择。--YFdyh000（留言） 2021年2月5日 (五) 18:11 (UTC)

纯技术角度，不怪绿链还能怪谁，{{Winners of the National Medal of Science}}调用7次就把页面干爆了，而把绿链去掉之后调用20次都还绰绰有余。--GnolizX（留言） 2021年2月4日 (四) 04:49 (UTC)

技术角度没错，绿链实现需改进，但这与绿链的提供其实是两个议题。（稍离题）不过个人还是认为某些导航模板塞得太多了，这个模板算还好的，某些是真的将导航模板当列表、大地图用了（例如{{台湾海峡两岸主题}}）。两层默认折叠不太符合版式便利性指引。如果不遵循英文维基，可以用参数精简成仅显示特定学科/年代。--YFdyh000（留言） 2021年2月4日 (四) 05:21 (UTC)

@GnolizX、YFdyh000：如果可以，尽量不要用{{tsl}}，因为tsl实际也是找对应{{link-XX}}，{{link-XX}}最终包含调用{{ilh}}，少一层包含，可以减少 T15260 的副作用。尽管整个tsl的调用大部分转为lua，还是架不住解析器的计数膨胀。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年2月4日 (四) 06:50 (UTC)

@cwek：不清楚有多大差别，手打习惯用{{tsl}}了。如果差别明显、暂时解决不了根本问题，或许可用机器人/小工具转换掉受影响页面中的tsl。--YFdyh000（留言） 2021年2月4日 (四) 07:09 (UTC)

原來如此，學了一課。因為懶，一直都用兩個字母的{{le}}{{lj}}。--Hjh474（留言） 2021年2月4日 (四) 09:28 (UTC)

再说消绿，COVID-19可说是现阶段全球关注度最高的话题了吧，但这上面的绿链却挂了一年，它们除了占用资源还有什么用吗？--GnolizX（留言） 2021年2月4日 (四) 04:54 (UTC)

编者的外文维基中心问题，绿链增加了这种行为的合理性。预期不会创建、细分的条目不该加绿链。--YFdyh000（留言） 2021年2月4日 (四) 05:22 (UTC)

認同「預期不會建立、細分的條目不該加綠鏈」。紅鏈也可免了。--Hjh474（留言） 2021年2月4日 (四) 09:25 (UTC)

「有心的編者和懂英文的讀者自己看英文版不就好了嗎？」←有心的編者看英文是要創建中文條目的，綠鏈可以讓編者們互相提醒有外文維基可以參考；懂英文的讀者有綠鏈可以方便快速的找到英文條目，如果綠鏈翻譯得不好，也有英文條目可以確認是指什麼。認同「不該用紅鏈的地方也不該用綠鏈」，相對的，綠鏈本身剛好證明該紅鏈有潛力成為條目，有存在的意義。--Hjh474（留言） 2021年2月4日 (四) 04:03 (UTC)

不是说绿链有问题，而是场合不对。导航模板的定位就是给读者导航已有条目，而不是补完内容并帮助编者创建条目的。编辑层面大可创建对应的XXXX列表慢慢消绿，或者在专题/用户页搞个绿链版navbox。另一方面不同语言维基有不同的收录准则，A语言版有条目，不必然代表在B语言版有潜力成为条目。一个例子是Template:火焰之纹章系列的罗伊，日文版有条目，但英文版条目被重定向了。ACG方面很多虚构设定只有日文维基有条目，而中文维基的收录标准比日文维基高。导航模版作为绿链应连尽连的重灾区，很可能出现这样的情况；萌新参照绿链辛苦翻译完，结果被按本地指引来了个大回退。所以依我看，导航模版中的绿链应该被更严格的限制。PS：中文维基百科的服务对象是中文用户，考虑的应该是方便中文读者快速找到中文资料，而不是方便英文使用者找英文文章。借用WP:NOTONLYFORGAMER的话，“如果什么东西只对懂英文用户有用，那可能是不合适的”；现在什么时候搞得不会英文跟成了原罪一样。—洛普利宁 2021年2月4日 (四) 04:46 (UTC)

感謝說明。了解您的意思。有些參考來源多是中文或日文，相對有些是英文為主（比如醫學期刊），課堂教科書是如此，何況維基，原文有其優勢，翻譯是為了避免落後更多。以讀者角度，翻譯的紅鏈名稱有些有來源支持已廣為使用，有些是編者善意原創翻譯，有些是各地譯名不同，甚者是劣質翻譯，此時若有綠鏈或括號原文，便能幫助讀者確認，但導航模板若添加大量括號原文，似乎不大美觀。。。--Hjh474（留言） 2021年2月4日 (四) 09:50 (UTC)

如果本地通過將模板限制增加為目前兩倍的共識（模板大小：4MB、擴展標籤(unstrip)大小：9.5367431640625MB、LUA大小：100MB），那麼phab會受理嗎？—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月4日 (四) 04:14 (UTC)

可能不会，T189108。--YFdyh000（留言） 2021年2月4日 (四) 04:29 (UTC)

裡面提到what is the methodology behind how you picked 2.5MB? Why not 2500MB or something else?，那麼如果主張「每個項目設定一樣大」會不會比較有機會，例如所有限制設定成跟LUA限制一樣大，50MB，那麼我提出的methodology就是「全部一樣大」。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月4日 (四) 04:50 (UTC)

没看懂。虽然请求为本地提升限制“或许”能通过，但这有些治标不治本，且用户还会猛塞内容到导航模板。--YFdyh000（留言） 2021年2月4日 (四) 05:14 (UTC)

(？)疑問 @YFdyh000：如果問題是出在導航模板太肥，那麼修改common.js把導航模板改成動態載入會不會好一些？例如像Minecraft wiki那樣{{LoadBox}}。——- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月4日 (四) 07:06 (UTC)

但维基百科要考虑无JavaScript的用户环境。--YFdyh000（留言） 2021年2月4日 (四) 07:09 (UTC)

我覺得可以先引入{{LoadBox}}看看效果，可以設定為頁面大小大於一定大小時使用Template:loadBox，其餘小的導航模板完整輸出。—- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月4日 (四) 07:17 (UTC)

@A2569875：看了一下Minecraftwiki的loadbox实现，大致上想法相似：外层是Navbox的外壳table，真正的内容在另外一个页面上，通过jsapi的parse解析加载回来，然后需要一些处理后在填充为Navbox的内层table。不过可能会引入两个问题：ilh链接实现和Navbox对应的折叠实现，这两个的启动脚本是正常页面加载时作为脚本引用后自启动的。用loadbox实现的，ilh链接可能要重新执行一次（有七种启动方法），折叠实现的折叠按钮可能也需要重新实现来支持懒加载（？，如果另外设加载按钮的话，可能没影响）。引入的工程量不一定小。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年2月4日 (四) 10:47 (UTC)

所以引入LoadBox的進度如何？現在還有大量國家條目受這個不知所謂的模板限制影響，是時候解決了。--45.64.240.30（留言） 2021年2月8日 (一) 08:14 (UTC)

未獲社群共識無法執行。-- ナナチ果物プリン🐰🥭🍮（宇帆·☎️·☘️） 2021年2月9日 (二) 13:49 (UTC)

Lua的运行量十分充足。主要是能不能在不扩大页面代码大小限制的情况扩大页面展开大小（实际上这两个值现在似乎设计成同一个值），另外扩大页面展开大小会对服务器性能有多大的影响？扩大页面展开大小我曾经问个en技术版，更多会征求是对应哪个页面和简易优化页面的内容，似乎没有实质性的意义。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年2月4日 (四) 05:57 (UTC)

• 我想请问一下，比起绿链，{{Interlanguage link multi}}是否更能有效地避免模板限制且加快模板的加载速度，如果可以的话，不如在达到模板限制时使用{{Interlanguage link multi}}来代替绿链。——BlackShadowG（留言）维基百科20岁生日快乐！ 2021年2月4日 (四) 11:43 (UTC)

自行测试，不过看到好像不少解析器方法，感觉不靠谱。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年2月4日 (四) 12:06 (UTC)

又有用戶想引起紅鏈鬥綠鏈嗎 ? 又有用戶想改變行之有效的做法嗎 ? 模版超限，不就消綠就是，不用怨來怨去的。任何限制自由使用綠鏈的提案，是不可行和不可取的。-- 約翰同志－條目裱糊匠（留言） 2021年2月6日 (六) 09:02 (UTC)

至於Alancrh的問題，將「諾貝爾化學獎獲得者」、「美國國家科學獎章得主」、「阿爾伯特·拉斯克基礎醫學研究獎獲得者」和「加拿大蓋爾德納國際獎獲得者」這四個模版，按年代和類別，拆分成多個小模版，就大大瘦身了。-- 約翰同志－條目裱糊匠（留言） 2021年2月6日 (六) 09:23 (UTC)

提示模板限制的小工具

相信关注客栈的各位会注意到，隔一段时间就能在技术版看到有人问为什么模板显示不出来。MediaWiki 对超限模板的显示就仅仅是变成一个内链，外加在生成页面的 html 注释里给一个警告，以及隐藏分类默认也是隐藏的，所以如果没听说过模板限制这个概念，很难找到为什么会显示成这样。我觉得我们可以做一个全站默认启用的小工具给这些超限的链接加上一些样式，鼠标放上去能显示提示文字，简单说一下为什么会显示成这样，鼓励大家精简、拆分页面，再给一个Wikipedia:模板限制这个信息页的链接。下面这个代码可以找出页面中所有因为模板超限被隐藏的模板：

// 显示成 Template:xxx 的链接，可以筛掉绝大部分不符合的内链
let template_links = $('a[title^="Template:"]');
// 下一个元素是注释，并且是 MediaWiki 的模板超限警告（写死了警告文字可能以后不好维护，能找到哪里有警告文字的变量吗？）
let omitted_template_links = template_links.filter((_, e) => e.nextSibling && e.nextSibling.nodeType === Node.COMMENT_NODE && e.nextSibling.textContent.includes("WARNING: template omitted"));

而具体样式上还是希望能集思广益，比如像跨语言链接那样显示成其他颜色，鼠标放上去会显示一个 tooltip 这样。--砜中嘌呤的白磷_{萃取 打谱} 2022年5月22日 (日) 01:35 (UTC)

警告註釋本來就是寫死的。--Xiplus#Talk 2022年5月22日 (日) 03:02 (UTC)

需要再加上顯示成#invoke:navbox的--Xiplus#Talk 2022年5月22日 (日) 03:05 (UTC)

關於提示文字，已經有維護模板Template:引用模板後大小超過限制的頁面。--Xiplus#Talk 2022年5月22日 (日) 03:07 (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:模板限制裡以外的，還有：
  • 誤用語法如Special:Diff/70523894（這樣清完省下約一萬位元組，大概是4－5筆Cite系列書目模板，或者1/20到半個不等的導航模板）
  • 沒搭配Template:Nowrap begin、Template:Nowrap end使用的各種禁止換行模板Special:Diff/70693799（這樣清了五千多位元組）
  • 模板本身內鑲或使用其他模板如Template:Metalworking navbox，也有看過在條目裡使用新創Navbox包覆數個模板的
  • 模板內容過於龐大
• 懸掛過多模板

如果我的修改有待改進，也請不吝指教。--迴廊彼端（留言） 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}}→測試的內容→

<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></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>

可以看到「測試的內容」當中「測試的內容」頁面不存在，因此壓根沒有輸出「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本地存储，暂不能跨设备同步）。现有页面及效果应该正常运行。新版输出代码和预览见此版本，或者[1][2]这两个实验站页面。预期存在一些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)

  @YFdyh000：雖然快一個月了但我還是要吐槽一下，為何一定要一堆鑲套，一個$.when($.ready, mw.loader.using('mediawiki.util','jquery.tipsy','ext.gadget.site-lib'), mw.loader.getScript('https://zh.wikipedia.org/w/index.php?title=MediaWiki:Tooltips.js&action=raw&ctype=text/javascript')).then(...)不就得了 囧rz……--SunAfterRain 2022年5月24日 (二) 00:03 (UTC)

  @SunAfterRain：因为这是现有数个小工具效果合并而来，最初打算单独维护和修订各效果，为了方便测试才整合了one版本，代码清理合并是功能稳定后的事。jquery.tipsy也得在之后取消掉。--YFdyh000（留言） 2022年5月24日 (二) 07:46 (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)

提醒一下，测试的时候不要忘记测试在维基百科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)

• 此修訂影響了其他模組正常運作，如Module:Infobox element isotopes（WP:VPO#××的同位素存在lua错误）。應更全盤檢視還有多少淺在地模組出錯影響。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年5月6日 (五) 04:10 (UTC)

  已在對應段落回應，該錯誤不是由Module:Ilh引起。--Xiplus#Talk 2022年5月6日 (五) 04:41 (UTC)

  • @Xiplus：Module:Ilh修改前，LUA不會報錯。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年5月6日 (五) 04:47 (UTC)

    @A2569875：GIGO，不會報錯只是碰巧而已，在顯示上仍有些微的錯誤：Draft:鉛的同位素。--Xiplus#Talk 2022年5月6日 (五) 04:51 (UTC)

  • Special:Diff/71469852，出現「Lua錯誤：too many expensive function calls。」，源自{{美国共和黨}}，是否也是因為Module:Ilh修改 ? --約翰同志－條目裱糊匠（留言） 2022年5月6日 (五) 10:47 (UTC)

    經過測試，若使用舊版本的Module:Ilh，模板超限問題更為嚴重，因此該問題不是Module:Ilh修改造成的，反而能夠證明該修改能夠減輕資源使用。--Xiplus#Talk 2022年5月6日 (五) 11:00 (UTC)

    當然Module:Ilh也有使用expensive function，但該修改前後的使用量不變，在expensive function的耗費並無改變。--Xiplus#Talk 2022年5月6日 (五) 11:04 (UTC)

  • 還有後續動作嗎?-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年5月18日 (三) 14:02 (UTC)

檢測模板限制

模板限制很煩人，而且往往不知問題具體出在何處。是否有工具可協助編者確認哪裡調用特別多資源？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年7月9日 (二) 10:38 (UTC)

好像没有很好的方法？页面“div.mw-parser-output”里面结尾有段HTML注释“NewPP limit report”和“Transclusion expansion time report”，可以看那个模板消耗时间和调用次数较多。或者借助WP:SB将内容逐点替换来分析。不过大部分情况，WP:模板限制基本上都说了：Navbox（尤其是包含大量ilh系的），包含了大量Navbox的Navboxlist，还有太多脚注的reflist系脚注模板。——Sakamotosan路过围观 | 避免做作，免敬 2024年7月9日 (二) 11:21 (UTC)