模板討論: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)