Template talk:Internal link helper/en

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

本主題或以下段落文字，移動自Wikipedia:互助客栈/技术。执行者：Jimmy-bot（留言） 2022年6月3日 (五) 08:14 (UTC)。[回复]

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

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

如果实在不行那我考虑另外建模板吧，所有模板分红链版和绿链版。--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}}→測試的內容（英语：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|context for test]]}-）

」，裏頭許多都應須瘦身。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 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|context for test]]}-）

可以看到「測試的內容（英语：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：我认为绿链有些时候是意义不明的。比如一个日本动漫角色只在阿拉伯语版有条目，且中文版认为它没有关注度。该角色名字使用假名，没有统一的中文翻译，所以需要标注日文名。

条目中提到这个角色时：

应该标注日文原名以便对照。
不适合链接阿拉伯语维基。不能期望中文维基用户看懂阿拉伯文条目（加入链接的编者可能也看不懂）。当初禁止跨语言直链的一个理由就是如此。
不适合加入红色链接，因为它没有关注度，不应该放红链引诱读者创建条目。
可能适合链接Wikidata。读者可能看到他的基本信息，比如所属作品、画师等。

现行绿链问题有：

日文维基没有条目，编辑无法链接日维，因此无法提示日文名。如果在绿链后标注日文，手机版会显示“XXX（阿拉伯文：<阿文条目名>）（日文：XX）”的双重标记。这对于一个全站级工具是不应该的。
读者无法提前知道链接指向阿拉伯语维基，滑动鼠标的结果是浪费时间。
绿链强制带红色链接，可能会亦引诱编者创建不合适的条目。但是没有办法去掉红色连接。

之前讨论我也留言问过，这种语种冲突的问题如何解决。您回复的是绿链行之有效，此问题不值得讨论。有编辑是尽可能加绿链，但上述情况加绿链我认为并不是行之有效的做法。所以想问您，上述例子（如果不考虑技术问题）您认为怎样做合适？--洛普利寧 2022年3月27日 (日) 10:59 (UTC)[回复]

這是手機版問題，非綠鏈。「該角色名字使用假名，沒有統一的中文翻譯，所以需要標註日文名。」這是多此一舉，直接使用日文名，直至官方譯名出現就是。
滑動鼠標的結果是浪費時間。各有各看法吧。
有冇綠鏈，也會有編者創建不合適條目，故非綠鏈問題，而是編者不熟識方針吧。

所以，在小工具解決他們的問題吧，沒有必要為了少數，限制多數人的行為，這是倒退。-- 約翰同志－條目裱糊匠（留言） 2022年3月27日 (日) 11:19 (UTC)[回复]

@Comrade John：感谢您的回应！这个问题我的想法是增加参数：

增加一个参数控制外语显示文字，将“外语维基标题”和“外文标注”独立开。（中文读者无法辨识日文假名，而且ACG领域地区词问题比较明显；需要附注原文的情况确实不少）
小工具允许用户定制js设定副语言，比如en, fr。然后优先链接设定的副语言，如果这两个语言没有条目就链接到wikidata。未注册用户可以考虑预设指向en或wikidata等。（就是感觉技术上不现实）
增加一个参数控制红链的显隐。

实际上第一个问题我之前提过，不过是有编辑认为参数太多会混淆。所以这个绿链的服务对象是读者还是编者，我就比较困扰。毕竟英文维基是连WP:ACCESS这种细节都能立指引的。

另外按照现行WP:MOSIW，可能会得出WP:OVERTSL这样的结论。当然这个结论和现实不符就是了。但MOSIW诞生时主要是为了规制[[:en:XXX]]直链，可能没想到十年后会出现的各种新技术和各种解读。所以我是认为，绿链要想做的更好，无论制度还是技术上，确实需要再重新讨论一下。--洛普利寧 2022年3月27日 (日) 12:00 (UTC)[回复]

这就是为何我推荐使用{{illm}}的原因。illm的好处有一下几点：

直接以红链显示，读者无需划滑动鼠标即可得知链接到哪个语言。且红链与链接对于读者而言并无二致，都是指中文维基百科不存在的条目，用两种不同的颜色标注反而很奇怪
可以很大程度上节省页面加载速度
可以同时链接多个条目，例如：神經胚（英语；俄语）
可以直接链接到维基数据项，这在不确定哪个语言的条目质量更高时会显得非常好用：神經胚（其他語言）
在不确定条目对应的中文名称时（例如上方提到的没有官方译名的情况），可以只提供维基数据的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，我认为更多是条目过长或其他脚本（如语法高亮、其他扩展或绿链本身）的因素，绿链至多导致预览结果较复杂而变慢。如果是绿链脚本性能问题，应能进一步优化。
问题2，我认为绿链滥用可能存在，但其维护性和说明性作用目前难以替代，单纯移除绿链将影响说明性（对应和查阅相应主题外文条目）或布局变丑（默认显示很长原文或大量存在如(英文)），条目过长、导航模板太多太大等问题同时存在。
问题3，值得讨论一些案例和考虑一个指引，限制条目正文中不必要、短期内不会创建条目的绿链。对于导航模板中的绿链，值得单独讨论，影响更大但作用也更大，因其中不能提供上下文介绍。对于“短期内不会创建”的标准，可以基于主题的常见性（很常见而没人建，绿链就可能不太有用），外文条目的热门度（编辑量、浏览量）、新鲜度、条目质量等。
问题4，我记得讨论过不止一次，并且数百人投票得出如今的折衷方案，再次争论细节并改变现状可能不现实，但用法和替代品可以讨论和列明。
问题5，值得进一步研究，如尽力缩减展开大小或改变当前实现方式。另外有个想法，针对导航模板，是否可以用机器人自动生成不调用模板（亦不检查条目是否存在）的伪绿链版本，作为模板子页面（如/cache），必要时引用它避免占用模板配额。以及也想过将目前绿链各版小工具整合为一个用户前端可切换显示效果的小工具，固定用户因此可能选用更多更理想的展示效果（上面讨论有若干细节），但这需要较多技术资源。--YF dyh000（留言） 2022年4月2日 (六) 05:15 (UTC)[回复]

缩减Internal link helper输出的代码

如果能放弃目前的对未启用任何“跨语言链接”小工具/未启用JavaScript的用户提供如“（英语：……）”的后缀链接，我想T:Internal_link_helper的输出能节省约70%。注，“跨语言链接：光标悬浮时显示Tooltip”目前对所有人（包括IP用户）默认启用。长度比较见此版源码。代码原型（需后续开发）。有个问题是，其他效果也需改写或放弃，Special:GadgetUsage显示其他各版internalLinkHelper效果各有几百人启用、几十人活跃，代码改写难度目测中等。另外，当前代码所用的Tipsy库已停更，基金会推荐用OOUI/Widgets/Popups代替。--YF dyh000（留言） 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了。测试用页面。代码较乱需要整理与合并，~~网址构造部分待优化~~。修改后的小工具目前未做旧格式兼容，需要定个方案应对缓存刷新阶段。--YF dyh000（留言） 2022年4月3日 (日) 22:29 (UTC)[回复]

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

~~原輸出（筆誤）~~原始輸出可以考慮用跨語言連結而非紅連？讓讀者有相關條目可以閱讀。--Xiplus#Talk 2022年4月4日 (一) 01:31 (UTC)[回复]

小工具用data属性替换成现有效果，变更不影响功能。如果用户禁用JS/取消全部效果，那么原版看到绿色的“红链”及“（英语：context for test）”，修改后只有红链。--YF dyh000（留言） 2022年4月4日 (一) 01:46 (UTC)[回复]

如果指默认输出跨语言链接，争议比较大，小工具也得调整，我认为没必要，悬停查看小工具是默认启用的。--YF dyh000（留言） 2022年4月4日 (一) 01:49 (UTC)[回复]

(！)意見後面的括弧X語「（英語：English）」理論上應該也可以由小工具輸出，或者讓使用者選擇哪種小工具功能-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年4月4日 (一) 02:18 (UTC)[回复]

修改后括弧部分是小工具输出，见“新输出”。如果指原“data-lang-name”，考虑过由脚本转换，但本身不长、百余项塞进代码有点多，并或许牵扯到多种变体和维护问题，所以搁置了。“data-orig-title”也可能从链接中提取，但稳定性和兼容性可能下降，将增加维护成本。--YF dyh000（留言） 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情况不了解。绿链和直接跨语言链接本就有争议（应该可以翻那次大投票），上文也提过我对向读者直接展示绿链存疑。原有的“（外文：条目链接）”我也觉得明显增加了内容凌乱程度，对阅读器用户恢复最初的直接红链促进创建似乎不成问题，而且阅读器用户可能只存了中文维基的离线镜像。如果想输出别的，我建议单开讨论。--YF dyh000（留言） 2022年4月4日 (一) 02:39 (UTC)[回复]

App情况不了解。绿链和直接跨语言链接本就有争议（应该可以翻那次大投票），上文也提过我对向读者直接展示绿链存疑。原有的“（外文：条目链接）”我也觉得明显增加了内容凌乱程度，也许增加了对绿链的反感。对“阅读器”用户恢复最初的直接红链促进创建也许不成问题？而且阅读器用户可能只存了中文维基的离线镜像。如果默认输出别的，建议单开讨论，可邀请这些环境的用户来谈。--YF dyh000（留言） 2022年4月4日 (一) 03:14 (UTC)[回复]

App的情況就是不開啟小工具的情況，因為現在的修改直接影響到不開啟小工具的結果，如果問跨語言連結跟紅連要保留哪個，我覺得跨語言連結是比較好的。--Xiplus#Talk 2022年4月4日 (一) 02:44 (UTC)[回复]

非要说需求的话，我觉得T:ill的效果不错，但字小是否不好点。跨语言链接误点（看不懂、误认为中维是翻译站）和降低条目创建率这两点问题很大。--YF dyh000（留言） 2022年4月4日 (一) 03:14 (UTC)[回复]

@Xiplus：下文新增的效果如何，我觉得不会那么乱和喧宾夺主。至于颜色，Mediawiki:common.js等是否生效？--YF dyh000（留言） 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解析链接，但稳定性不如属性写出，代码有点复杂。--YF dyh000（留言） 2022年4月5日 (二) 07:21 (UTC)[回复]

不好意思我不懂技術，請教一下這邊的討論跟上面提的「link-xx模板的wrapper」設計有關嗎？Template:Navbox的wrapper設計稍後也會討論嗎？--迴廊彼端（留言） 2022年4月5日 (二) 07:30 (UTC)[回复]

Navbox的结构我不了解，可能无能为力。如果导航框中用了许多绿链，这边会有帮助，否则无关联。--YF dyh000（留言） 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属性、与旧版模板的兼容性等。--YF dyh000（留言） 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的功劳？--YF dyh000（留言） 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也得在之后取消掉。--YF dyh000（留言） 2022年5月24日 (二) 07:46 (UTC)[回复]

无小工具环境下的输出格式

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

再一种效果：显示文字 [英语] 或显示文字_[英语]--YF dyh000（留言） 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解决。--YF dyh000（留言） 2022年4月4日 (一) 18:32 (UTC)[回复]

我是认为中文维基不要对普通读者到处贴跨语言连接。一两个拿不准的翻译为避免误导读者，贴个链接方便对照也就OK。（此处是希望读者通过信息框生卒年份定位人，不是期望读者真的读一篇外文维基条目；实际这里连Wikidata更合适）en:Elections in Germany这种没有翻译难度的短语，真的就不要给读者跨维基链接了。现在绿链对读者用的太滥了。但现在编者模式和读者模式分不开，结果就是编者把适合自己的效果强加给读者了。--洛普利寧 2022年4月4日 (一) 19:03 (UTC)[回复]

感谢回应。现有效果来说，未注册用户及默认设置是绿链悬停提示，没有小工具的场景下则是（语言：外文名）的后缀。small和括号也是个选择，下标我这里看有点错位感，但我认为[]更节省空间且不会与后文的括号重复。链Wikidata是ill效果，功能更多但会否不习惯，以及可能因技术原因暂不可行（如何查Q编号）。参数控制可行，但整体调整不如直接改模块，有按模板或上下文调整效果的需求和意义吗，将增加编辑战。JS控制就是小工具/做界面，但本章节主要讨论无JS环境下的效果。原有效果源码太长了，显示我也认为比较冗余。--YF dyh000（留言） 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)[回复]

支持红链下标，至少在文档流内。大家可以试试当一个短绿链不幸正好位于换行的位置上的时候会有多难看。 --Milky Defer 2022年4月16日 (六) 05:45 (UTC)[回复]

提醒一下，测试的时候不要忘记测试在维基百科Android和iOS App中是否正常工作。--Tranve (✉) 2022年5月9日 (一) 13:54 (UTC)[回复]

暂未测试相关环境，但与移动版网页+模拟触控应该相差不多？截至目前，没有人进一步参与测试和给出意见，所以开发暂时搁置，我不确定是否有人不同意这种方案。--YF dyh000（留言） 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)[回复]

會否影響已啟用任何「跨語言連結」小工具的用戶的綠鏈和偽藍鏈的顯示 ?
會否影響Translink和Internal link helper的原代碼輸入 ?
可以減少幾多「展開後的引用大小」 ?
頁面編輯、保存、解析問題會否有所改善 ?-- 約翰同志－條目裱糊匠（留言） 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)[回复]