維基百科

模組討論:Ilh

由Jimmy-bot在話題Category:引用模板後大小超過限制的頁面上作出的最新留言：2 年前

編輯請求 2022-04-26

編輯
最新留言：2 年前2則留言2個人參與討論

  請求已處理

優化性能，參見Wikipedia:互助客棧/技術#Template:Translink簡化。--Xiplus#Talk 2022年4月26日 (二) 01:08 (UTC)回覆

管理員不能逕行部署變更？—— Eric Liu 創造は生命（留言・留名・學生會） 2022年5月4日 (三) 06:49 (UTC)回覆

Category:引用模板後大小超過限制的頁面

編輯
最新留言：2 年前111則留言19個人參與討論

本主題或以下段落文字，移動自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://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}}」→「雪菲（維基數據所列：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)回覆
新增話題
取自「https://zh.wikipedia.org/w/index.php?title=Module_talk:Ilh&oldid=83743522」
返回 "Ilh" 頁面。