模板讨论: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)[回复]