維基百科討論:模板限制

關於2MB的限制

在en的oldid=779958657（客棧技術版，About some question of Wikipedia:Template_limits）問過能不能加大，有人解釋了因為是轉化為HTML輸出的話，2MB已經不小了，對於其他性能差的用戶可能會很糟糕，所以一般2MB為原則上限。——路過圍觀的Sakamotosan 2017年5月12日 (五) 02:12 (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)

• 我想請問一下，比起綠鏈，{{Interlanguage link multi}}是否更能有效地避免模板限制且加快模板的加載速度，如果可以的話，不如在達到模板限制時使用{{Interlanguage link multi}}來代替綠鏈。——BlackShadowG（留言）維基百科20歲生日快樂！ 2021年2月4日 (四) 11:43 (UTC)

自行測試，不過看到好像不少解析器方法，感覺不靠譜。——Sakamotosan路過圍觀杯弓蛇影 | 避免做作，免敬 2021年2月4日 (四) 12:06 (UTC)

又有用戶想引起紅鏈鬥綠鏈嗎 ? 又有用戶想改變行之有效的做法嗎 ? 模版超限，不就消綠就是，不用怨來怨去的。任何限制自由使用綠鏈的提案，是不可行和不可取的。-- 約翰同志－條目裱糊匠（留言） 2021年2月6日 (六) 09:02 (UTC)

至於Alancrh的問題，將「諾貝爾化學獎獲得者」、「美國國家科學獎章得主」、「阿爾伯特·拉斯克基礎醫學研究獎獲得者」和「加拿大蓋爾德納國際獎獲得者」這四個模版，按年代和類別，拆分成多個小模版，就大大瘦身了。-- 約翰同志－條目裱糊匠（留言） 2021年2月6日 (六) 09:23 (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:引用模板後大小超過限制的頁面

現在寫的尤利西斯·格蘭特因模板裡面的綠鏈，頁面編輯、保存巨慢，而且從剛開始寫就存在解析問題。

能否在解決上述技術問題前不要在模板裡面用綠鏈？頁面解析負擔大好多，上十萬字節的頁面基本上都有問題。但如果全部是紅鏈不管打開、編輯、保存都快多了，而且出現模板無法解析的情況會小很多。

如果實在不行那我考慮另外建模板吧，所有模板分紅鏈版和綠鏈版。--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}}→測試的內容→

<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>

可以看到「測試的內容」當中「測試的內容」頁面不存在，因此壓根沒有輸出「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)

縮減Internal link helper輸出的代碼

如果能放棄目前的對未啟用任何「跨語言連結」小工具/未啟用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://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的功勞？--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://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也得在之後取消掉。--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}}」→「雪菲」；③持有Q編號和P編號都可以查詢相應中文名稱；④「鏈Wikidata是ill效果」並非，兩年前已有{{WikidataLink}}，是「ilh效果」，例如「{{WikidataLink|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)

• 此修訂影響了其他模組正常運作，如Module:Infobox element isotopes（WP:VPO#××的同位素存在lua錯誤）。應更全盤檢視還有多少淺在地模組出錯影響。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年5月6日 (五) 04:10 (UTC)

  已在對應段落回應，該錯誤不是由Module:Ilh引起。--Xiplus#Talk 2022年5月6日 (五) 04:41 (UTC)

  • @Xiplus：Module:Ilh修改前，LUA不會報錯。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年5月6日 (五) 04:47 (UTC)

    @A2569875：GIGO，不會報錯只是碰巧而已，在顯示上仍有些微的錯誤：Draft:鉛的同位素。--Xiplus#Talk 2022年5月6日 (五) 04:51 (UTC)

  • Special:Diff/71469852，出現「Lua錯誤：too many expensive function calls。」，源自{{美國共和黨}}，是否也是因為Module:Ilh修改 ? --約翰同志－條目裱糊匠（留言） 2022年5月6日 (五) 10:47 (UTC)

    經過測試，若使用舊版本的Module:Ilh，模板超限問題更為嚴重，因此該問題不是Module:Ilh修改造成的，反而能夠證明該修改能夠減輕資源使用。--Xiplus#Talk 2022年5月6日 (五) 11:00 (UTC)

    當然Module:Ilh也有使用expensive function，但該修改前後的使用量不變，在expensive function的耗費並無改變。--Xiplus#Talk 2022年5月6日 (五) 11:04 (UTC)

  • 還有後續動作嗎?-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕]（☎️·☘️） 2022年5月18日 (三) 14:02 (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)