跳转到内容

维基百科讨论:模板限制

页面内容不支持其他语言。
维基百科，自由的百科全书

关于2MB的限制

[编辑]

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

模板限制

[编辑]

本主题或以下段落文字，移动自Wikipedia:互助客栈/技术。执行者：Jimmy-bot（留言） 2021年2月19日 (五) 16:14 (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)[回复]
自行测试，不过看到好像不少解析器方法，感觉不靠谱。——Sakamotosan路过围观杯弓蛇影 | 避免做作，免敬 2021年2月4日 (四) 12:06 (UTC)[回复]

又有用户想引起红链斗绿链吗 ? 又有用户想改变行之有效的做法吗 ? 模版超限，不就消绿就是，不用怨来怨去的。任何限制自由使用绿链的提案，是不可行和不可取的。-- 约翰同志－条目裱糊匠（留言） 2021年2月6日 (六) 09:02 (UTC)[回复]

至于Alancrh的问题，将“诺贝尔化学奖获得者”、“美国国家科学奖章得主”、“阿尔伯特·拉斯克基础医学研究奖获得者”和“加拿大盖尔德纳国际奖获得者”这四个模版，按年代和类别，拆分成多个小模版，就大大瘦身了。-- 约翰同志－条目裱糊匠（留言） 2021年2月6日 (六) 09:23 (UTC)[回复]

提示模板限制的小工具

[编辑]

本主题或以下段落文字，移动自Wikipedia:互助客栈/技术。执行者：Jimmy-bot（留言） 2022年6月1日 (三) 08:14 (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:引用模板后大小超过限制的页面

[编辑]

本主题或以下段落文字，移动自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:模板限制里以外的，还有：
  • 悬挂过多模板
如果我的修改有待改进，也请不吝指教。--回廊彼端（留言） 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|<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>
可以看到“测试的内容（英语：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)[回复]
[编辑]

如果能放弃目前的对未启用任何“跨语言链接”小工具/未启用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://wiki.zwnes.eu.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://wiki.zwnes.eu.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://wiki.zwnes.eu.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}}”→“雪菲（维基数据所列：Q107002031）”；③持有Q编号和P编号都可以查询相应中文名称；④“链Wikidata是ill效果”并非，两年前已有{{WikidataLink}}，是“ilh效果”，例如“{{WikidataLink|Q107002031}}”→“雪菲（维基数据所列：Q107002031）”。以上。若上一节ilh优化有结论，{{Link-wd}}、{{WikidataLink}}基本可以立即跟进。-- [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鲜果茶☕]（☎️·☘️） 2022年4月13日 (三) 03:25 (UTC)[回复]
我支持红链下标的形式，至少是在APP端。目前APP端“（语言：外文名）”显示方式很有迷惑性，私以为在一般人理解来看，“AAA（英语：BBB）”会让人理解为“BBB”是“AAA”的英文名，但在使用中很多的情况下都不是对应的，例如“角色（英语：List of The Last of Us characters）”这种中英文对应不上的可能会让新来的读者感到迷惑。此外，读者只需要知道“这个东西在其它语言版本有条目”即可，而不需要知道“其它语言版本的条目叫什么名字”。综上，我认为红链下标的形式能解决这些问题。--BlackShadowG Pray for Ukraine 2022年4月14日 (四) 12:58 (UTC)[回复]
支持红链下标，至少在文档流内。大家可以试试当一个短绿链不幸正好位于换行的位置上的时候会有多难看。 --MilkyDefer 2022年4月16日 (六) 05:45 (UTC)[回复]
提醒一下，测试的时候不要忘记测试在维基百科Android和iOS App中是否正常工作。--Tranve (✉) 2022年5月9日 (一) 13:54 (UTC)[回复]
暂未测试相关环境，但与移动版网页+模拟触控应该相差不多？截至目前，没有人进一步参与测试和给出意见，所以开发暂时搁置，我不确定是否有人不同意这种方案。--YFdyh000（留言） 2022年5月9日 (一) 14:32 (UTC)[回复]

Template:Translink简化

[编辑]

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

@Xiplus：，测试过没异常的话就更新吧。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月25日 (一) 23:29 (UTC)[回复]
  1. 会否影响已启用任何“跨语言连结”小工具的用户的绿链和伪蓝链的显示 ?
  2. 会否影响Translink和Internal link helper的原代码输入 ?
  3. 可以减少几多“展开后的引用大小” ?
  4. 页面编辑、保存、解析问题会否有所改善 ?-- 约翰同志－条目裱糊匠（留言） 2022年4月27日 (三) 08:12 (UTC)[回复]
    1. 不会。 2. 不会。 3. -35%。 4. 不会、不会、会。--Xiplus#Talk 2022年4月27日 (三) 08:21 (UTC)[回复]
请教User:Xiplus我这边Template:Translink/testcases倒数两项的旧版显示“{{ilh|lang={{langname|aa}}|lang-code=aa|1=Test2|2=Test2|d=|nocat=}}”、“{{ilh|lang={{langname|aa}}|lang-code=aa|1=測試2|2=Test2|d=|nocat=}}”，是否有些问题呢？--回廊彼端（留言） 2022年4月27日 (三) 11:55 (UTC)[回复]
就是现行版本有bug。--Xiplus#Talk 2022年4月27日 (三) 12:10 (UTC)[回复]
我不知道为何Cwek要这样设计Special:Diff/42823985。--Xiplus#Talk 2022年4月27日 (三) 12:12 (UTC)[回复]
@Xiplus：我也忘了……大概就是如果已经存在link-XX的就复用（有对应已配置的语言信息），如果没有的话，就利用{{langname}}来生成，然后需要依靠模块:langname来解决？这部分也是参照改动前的调整。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月27日 (三) 12:49 (UTC)[回复]
这个我知道，但为什么要使用{{!}}？--Xiplus#Talk 2022年4月27日 (三) 13:12 (UTC)[回复]
{{#ifexist:Template:link-{{{1}}}
|link-{{{1}}}<!--快捷模板-->
|ilh{{!}}lang={{langname{{!}}{{{1}}}}}{{!}}lang-code={{{1}}}<!--通用模板-->
}}——Sakamotosan路过围观 | 避免做作，免敬 2022年4月27日 (三) 13:19 (UTC)[回复]
但是把这个按照正常使用又是没问题的。扔到Special:展开模板也是能跑的。 囧rz……——Sakamotosan路过围观 | 避免做作，免敬 2022年4月27日 (三) 12:52 (UTC)[回复]
@Cwek，没有：Special:PermaLink/71346024。--Xiplus#Talk 2022年4月27日 (三) 13:11 (UTC)[回复]
有可能是当时没测试覆盖到，但思路是通过ifexist判断，是的话输出link-XX，不是的话输出后面ilh+参数lang和lang-code的的部分。如果不用{{!}}的话，管道符会成为ifexist的参数分割。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月27日 (三) 13:19 (UTC)[回复]
或者刚好把这个部分在这个调整给修复了。——Sakamotosan路过围观 | 避免做作，免敬 2022年4月27日 (三) 13:26 (UTC)[回复]

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

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

检测模板限制

[编辑]

本主题或以下段落文字，移动自Wikipedia:互助客栈/技术。执行者：Jimmy-bot（留言） 2024年7月19日 (五) 16:14 (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)[回复]
检索自“https://wiki.zwnes.eu.org/w/index.php?title=Wikipedia_talk:模板限制&oldid=83743536”