Template talk:Annotated link

Annotated link模板在处理简体与繁体条目名称时功能有别

例如无法展示(简体)查询语言的维基数据描述；但如果用繁体（查詢語言）的话可以展示：

• 查詢語言——计算机语言用于查询数据库和信息系统

@User:YFdyh000能否帮看一下？--Zhenqinli（留言） 2025年8月14日 (四) 19:01 (UTC)

wikibase函数调用没有中文维基百科的自动匹配到简繁异体页面的功能。Special:Diff/88733421，引入字词转换模块，可能解决了，但不确定覆盖所有用例。引入模块使“Lua内存使用情况”从6MB增加到12MB。人工智能术语表条目中的破折号（描述显示）从119个提升到126个。--YFdyh000（留言） 2025年8月14日 (四) 20:13 (UTC)

不过，隐式强制转换是否可能造成错误显示，比如异体字条目不存在而对应到简体字的维基数据描述思考... 要不要限制仅对1或2个字的短名称尝试转换。--YFdyh000（留言） 2025年8月14日 (四) 20:15 (UTC)

谢谢，这个问题您确实解决了。但是好像某些引用此模板较多（但少于500次）的条目提前触发了“Lua错误：too many expensive function calls”，如 经济学词汇表 历史版本。后面这个问题，虽然可以一些内链取代模板作为变通，但希望以后能有比较稳定的解决办法。 --Zhenqinli（留言） 2025年8月14日 (四) 21:42 (UTC)

该版本之前是“高开销解析函数数量 487/500”，本次修改后584/500。按文档，isRedirect, exists等是高开销的，所以好像没有很好的办法来兼顾自动检测和大量调用。除非写个脚本或机器人来转换源码，在源码中改为引用QID？--YFdyh000（留言） 2025年8月15日 (五) 10:58 (UTC)

有无变通办法，将调用其他模板生成的模板（如Template:科技、自然与学术术语词汇表）rendering后生成的非动态源代码存为缓存，避免递推调用模板产生的动态错误？ --Zhenqinli（留言） 2025年8月15日 (五) 15:26 (UTC)

不太懂是怎么做、能否通用、Template:科技、自然与学术术语词汇表中的QID是怎么得来的。开销是读取页面带来的。--YFdyh000（留言） 2025年8月16日 (六) 07:39 (UTC)

中文科学分支列表调用Annotated link模板不到400次，尾部Template:科技、自然与学术术语词汇表模板即触发高开销错误，而对应的英文列表用了超过700次，而没有问题，可能是什么原因？ --Zhenqinli（留言） 2025年8月16日 (六) 16:15 (UTC)

他已经解释了。每次给新的页面名使用.exists就会让expensive parser function count加1，而当前的实现需要检查繁简的可能性，自然令数量膨胀了。--Srapoj（留言） 2025年8月16日 (六) 16:24 (UTC)

我早前看到过类似“缓存”的实现，见Module:China Expwy Name涉及image_refs的代码。让机器人扫所有对Annotated link的调用、检查目标标题的繁简/重定向情况然后将映射表导出成json或Lua代码，这样就能避免对已知的标题调用expensive parser function了。感觉应该是个比较容易且well-defined的工作（LLM就能写出这种代码？）。相比于让机器人改条目页对模板的调用或者生成一堆中间结果页面也更干净。--Srapoj（留言） 2025年8月16日 (六) 18:22 (UTC)

好像是建立繁简重定向的又一力证了……--PexEric 2025年8月15日 (五) 03:26 (UTC)

@PexEric：不不不，繁簡重定向根本無法解決問題，你是不是誤會了什麼😏--SunAfterRain 2025年8月15日 (五) 06:40 (UTC)

没有啊。我看模块刚好前段时间才引入对重定向的处理。［当然，我是不会支持建立繁简重定向的😂］。--PexEric 2025年8月15日 (五) 07:27 (UTC)

但治標不治本就是了，而且這種寫法會導致刻意連結到維基數據的重定向無法使用XD--SunAfterRain 2025年8月15日 (五) 14:59 (UTC)

之前读讨论看到U:SunAfterRain有一个将LanguageConverter暴露给Lua的patch (gerrit:1104273)，但很久没动静了。--Srapoj（留言） 2025年8月15日 (五) 04:04 (UTC) 👍1

您有空的話可以自己嘗試，反正我今年實在懶得繼續研究w--SunAfterRain 2025年8月15日 (五) 06:39 (UTC)

其实还是指定QID最好了：{{#invoke:WikidataDescription|fromQID|Q845739}}→计算机语言用于查询数据库和信息系统。--PexEric 2025年8月15日 (五) 07:25 (UTC)

我调整了一下这个Lua模块的逻辑，现在可以正常渲染“经济学词汇表”去掉靠后的{{annotated link}}前最后的历史版本了。--Srapoj（留言） 2025年8月26日 (二) 20:49 (UTC)

另@Zhenqinli：如果不会造成过多不便的话，还是建议您调这个模板的时候使用条目的原名（地址栏里/在编辑界面/选择“不转换”看到的）。至少按现在的实现用原名能省掉不少事（反映在parser report里）。--Srapoj（留言） 2025年8月27日 (三) 00:56 (UTC)

您是说如果条目里都用简体，调用annotated link模板时繁简转换会耗用更多资源？--Zhenqinli（留言） 2025年8月27日 (三) 01:04 (UTC)

目前这版的做法是先直接尝试获取传入的标题的QID，如果失败才进行繁简转换及解析重定向目标（这步会增加expensive function计数），并再查询一次QID。如果传入的标题就是条目的原名，那就省掉重试的步骤了。条目原名不一定都是繁体的，依创建者的选择而定。

 吐槽：2019年U:Artoria2e5在文档Template:Annotated link#注意事项已经写明了需要使用原名。如果用什么脚本/机器人把标题参数规范为原名不就没这么多事了🤦。虽然期间确实有上游以及本地的新工具使得这个问题能勉强被解决了。--Srapoj（留言） 2025年8月27日 (三) 01:49 (UTC)

顺便在这里写点笔记。

Lua的mw.wikibase有文档，不过具体什么会增加expensive function计数还是得去Extension:Wikibase的代码仓库里搜incrementExpensiveFunctionCount。相关代码似乎都在mw.wikibase.lua，可以看到操作非本页的mw.wikibase.entity对象（由mw.wikibase.getEntity返回）或者调用wikibase.getBadges会增加计数，其他的操作似乎不会触发。

这里理论上涉及到两个限制：expensive parser function count (ExpensiveParserFunctionLimit)以及number of Wikibase entities loaded (entityAccessLimit)。前者在WMF站点很早就设为500了，后者是在phab:T384455调到了500。不过后面这个限制貌似只针对真的完整加载了某个entity的情况，像Module:WikidataDescription这样只用mw.wikibase.getEntityIdForTitle拿QID、然后调.getDescriptionWithLang拿描述的情况目前不计入。因此需要担心的只有前者，幸运的是这两个方法也都没被算作expensive function。所以查询wikidata的部分并非瓶颈，需要优化的只有本地为work around重定向和繁简问题实现的代码。

剩下要做的就是在尽量避免调用expensive function的前提下获得某个标题的正规形式了。也许有其他模块实现过，但反正这里又造了一次轮子。--Srapoj（留言） 2025年8月27日 (三) 00:00 (UTC)

也许应该从Module:WikidataLink里抄一些代码。没仔细读过它。--Srapoj（留言） 2025年8月27日 (三) 00:31 (UTC)