維基百科

維基百科:互助客棧/技術/存檔/2019年5月

< Wikipedia:互助客栈 | 技术 | 存档
由Jimmy-bot在話題{{infobox aircraft occurrence}}的第二飛機圖片出不來了上作出的最新留言：5 年前

Infobox museum

最新留言：5 年前1則留言1個人參與討論

本主題全部或部分段落文字，已移動至Template talk:Infobox_museum。執行人：Jimmy-bot（留言） 2019年5月7日 (二) 08:14 (UTC)。

圖像縮圖疑似出現混疊失真

最新留言：5 年前8則留言3個人參與討論
於Phabricator查看
編號T222010的任務

近期發現條目正多邊形鑲嵌（歷史版本）中圖像File:Tile_4,4.svg縮圖疑似出現混疊(Aliasing)失真情況，如下圖，與原圖對比（右側為原圖顯示情況）

 

由於正方形鑲嵌最重要的就是要能辨識出圖像網格，如圖，整張細節完全遺失的情況不曉得是甚麼情形

疑似混疊(Aliasing)失真/採樣不足失真的情況：

     

如果這是一個Bug，我認為有必要報告到phab:

以上--宇帆（留言·歡迎簽到R₁R₂NKC） 2019年4月26日 (五) 20:27 (UTC)

phab:代為提報協助請求

關於ESNI和維基百科的一些想法

最新留言：5 年前31則留言10個人參與討論
於Phabricator查看
編號T205378的任務

各位維基百科人大家好： 有鑑於最近牆對維基百科實行SNI RST封殺，我有以下三點想法和大家分享一下（第一個想法不涉及到ESNI）：

  1. 這次封殺涉及所有的維基百科語種，只留下其它的一些Wikimedia項目比如維基文庫，維基教科書等未被封殺。而維基百科與未被封殺的這些Wikimedia項目是共用IP位址和安全證書的，所以是否可以採取像以前單單中文維基被封殺時那樣，先連接到比如維基文庫上去，然後利用維基文庫建立好的HTTPS通訊信道的餘熱來打開維基百科？
  2. 如果由於域名差別太大（因為各語種維基百科二級域名都是wikipedia，而維基文庫的二級域名就不是wikipedia了）導致無法利用維基文庫建立好的HTTPS通訊信道的餘熱來打開維基百科，那麼由於Wikimedia伺服器的IP位址群尚未被封殺，可否考慮在Wikimedia伺服器上開啟ESNI，這樣至少使用Firefox並且已經打開DoH選項和ESNI選項的用戶可以免翻牆繼續瀏覽維基百科。
  3. 如果ESNI的開啟導致Wikimedia伺服器的IP位址群被整體封殺，那可否考慮把維基百科託管到Cloudflare上，如此一來就解決IP位址群被封殺的問題了。（Cloudflare上所有網站均自動開啟ESNI）

以上三個想法非常初步，可能有不周到的地方，望各位維基百科人不略賜教。 65.92.206.79（留言） 2019年4月28日 (日) 19:05 (UTC)

第一個方法就是現在有推薦的；第二個，ESNI仍是草案，CF和FX只是先行實現測試（FX還是地雷版才有）；第三個，好像主要是考慮私隱而避免使用CDN，當然你可以去元維基問一下使用公共CDN的的考慮。——路過圍觀的Sakamotosan | 避免做作，免敬 2019年4月29日 (一) 00:47 (UTC)
嗯，從私隱角度考慮應當避免使用CDN，因為CDN能夠知道用戶訪問細節比如具體訪問了維基百科那些網頁以及在維基百科上寫了什麼東西。當然，如果使用的是維基百科的證書而不是CDN的證書，那麼可以大大降低私隱泄露給CDN的風險。（我是65.92.206.79，現在使用電話發言所以IP位址不一樣）207.164.79.114（留言） 2019年4月29日 (一) 13:32 (UTC)
對於CDN的終端來說，你的數據還是被CDN解密，用誰的證書都一樣。除非基金會願意花大價錢建立大型的CDN網絡。雖然現在荷蘭、三藩市、新加坡三個就是相當於CDN服務入口般的緩存入口。——路過圍觀的Sakamotosan | 避免做作，免敬 2019年4月30日 (二) 01:18 (UTC)
為什麼數據還是被CDN解密？CDN的目的不就是為目標網站提供一種前置緩衝服務嘛？CDN把加了密的數據中專一下不就可以了？再說了，用維基百科證書加密的數據怎麼可能被CDN解密？CDN又沒有維基百科的私鑰。（我是65.92.206.79，現在使用電話發言所以IP位址不一樣）216.221.73.248（留言） 2019年4月30日 (二) 13:52 (UTC)
我這樣分析：
  • 如果需要ESNI，現在應該只有CF實驗性提供（畢竟是起草者之一），而ESNI需要使用DNS來分佈加密公鑰，DNS要交給CF託管，而且只有CF能處理ESNI，所以TLS連接的終結是由CF負責，這就意味內容已經脫了TLS了。
  • 如果不考慮SNI RST的話，CF只做端口轉發，私鑰不用交由CF託管，也就是只是借CF的內部網絡轉發到基金會的入口網絡，一來中國大陸的網絡對CF不一定友好（不容易分配到靠近的接入點，中途需要通過網絡狀況差的中繼），二來CF雖然有中國大陸的接入點，但需要網站備案，而且這樣幾乎是動態流量，沒得在CF緩存。
  • 同上，如果希望CF能緩存的話，必然在CF上終結TLS連接，也就是已經脫密的。回到ESNI的說法。
以上。如果要用的話，需要對可公開的靜態來源和私隱的用戶數據進行大量的分離工作。另外據我所知的，萌百有用CDN，不過好像曾經請求過寫一個功能用於刷新CDN的緩存，主要需要MW的緩存動作聯動到CDN中，不過現在來看還是沒搞好。——路過圍觀的Sakamotosan | 避免做作，免敬 2019年4月30日 (二) 14:36 (UTC)
多謝Sakamotosan詳細的回答問題，我還是有一點不明：為什麼只有CF能處理ESNI？ESNI作為IETF的草案，應該是一種open standard，應該是和提出者機構無關的，CF應該是不能壟斷ESNI的。我個人對ESNI在維基百科上的應用的理解是這樣的：加密SNI的公鑰是【維基媒體】的，適用於所有已封的和未封的項目（也就是所有在維基媒體旗下的域名），全程不關CF什麼事，其實我開始說的第二種方案（打開ESNI）是和CF【完全不相干】的，而ESNI作為一種open standard也應該和CF【完全不相干】，我實在不明白為什麼ESNI需要被CF處理。（我是65.92.206.79，現在使用電話發言所以IP位址不一樣）216.221.73.248（留言） 2019年4月30日 (二) 14:58 (UTC)
另外關於Sakamotosan所說的「中國大陸的網絡對CF不一定友好」：我的理解就是這就是「依附的自由」的定義：儘管中國大陸的網絡對CF不一定友好，但是基於經濟利益的考慮，還是不得不放行CF的流量。但是現在明文SNI還是可以讓GFW選擇性封殺某些域名（當然GFW已經再也不能選擇性封殺單個網頁了）。以後使用了DoH和ESNI，則GFW就再也不能選擇性封殺任何CF的流量了--要麼放行全部CF流量（包括維基百科），要麼封殺所有CF流量（造成巨大經濟損失），所以和中國大陸的網絡對CF友不友好是無關的，這就是「依附的自由」最最厲害的地方。邏輯上再延伸一步：在百無一用是書生提交的phab:T205378，就有老外說了「我們逐步把【整個】牆外互聯網都變成完全加密的，opaque的網絡，除了IP位址以外不再有任何其它明文的東西，（也就是把「依附的自由」做到極致：把整個互聯網作為封殺或者放行對象，而不是單個的域名或者CDN），這樣我們就可以逼迫封殺網絡的政府做出一個決定：要麼參加國際互聯網，要麼封殺整個國際互聯網，而一旦政府決定封殺整個國際互聯網，那麼其國民就可以察覺到他們用的網絡有很大的不對勁了」。我非常贊同這種說法。（我是65.92.206.79，現在使用電話發言所以IP位址不一樣）216.221.73.248（留言） 2019年4月30日 (二) 15:12 (UTC)
我一直都說，ESNI仍是草案，CF和Mozilla是起草者之一，現在的ESNI實現實際上是實驗性的，所以對此支持基本上只此兩家，在未標準化之前，其他廠商更多是觀望。理論上ESNI的公鑰的確可以不由CF託管，那就回到端口轉發模式，那就回到前面所說的ESNI實現問題，而且還要回到CF的網絡質量問題。而且即使使用CF的話，還是避不開SNI RST，並不是單單路由黑洞的麻煩。我建議對相關技術進行深入了解後，你就不會問這些問題，因為基本上自己能理解大部分結論。——路過圍觀的Sakamotosan | 避免做作，免敬 2019年4月30日 (二) 15:24 (UTC)
睡前最後一句，看了shizhao的p區提報，實際上只討論：主要接待認為可能需要更新開發源(意味着可能不穩定)的nignx，而且認為這是在提問，應該通過其他渠道來提問；有人認為這對對抗審查有好處；有人建議開quic，但接待認為實質應該還是tls的sni機制，然並卵。最多認為知道有這件事，做不做事還另一回事。--路過圍觀的Sakamotosan | 避免做作，免敬 2019年4月30日 (二) 15:42 (UTC)
好吧，看來我還是需要對相關技術進行深入了解，多謝さかもとさん耐心的解答🙇🙇🙇。閉關修煉閱讀ESNI草案去也！（我是65.92.206.79，現在使用電話發言所以IP位址不一樣）216.221.73.248（留言） 2019年4月30日 (二) 17:52 (UTC)
喔，原來第一個方法現在果然還是可行，學習了。另外順便問一下，牆外有沒有什麼好的方法可以模擬牆內網絡環境？謝謝！65.92.206.79（留言） 2019年4月29日 (一) 01:59 (UTC)
使用國內代理？--及時雨 留言 2019年4月29日 (一) 02:14 (UTC)
謝謝及時雨（我是65.92.206.79，現在使用電話發言所以IP位址不一樣）。你可否知道牆內有哪些比較靠譜的代理？謝謝！207.164.79.114（留言） 2019年4月29日 (一) 13:32 (UTC)
這裏有兩個網站供你參考[2][3]--及時雨 留言 2019年5月2日 (四) 02:41 (UTC)
多謝多謝！（我是65.92.206.79，現在使用電話發言所以IP位址不一樣）172.97.230.191（留言） 2019年5月3日 (五) 20:29 (UTC)
啟用ESNI，見phab:T205378--百無一用是書生 (☎) 2019年4月29日 (一) 03:25 (UTC)
謝謝百無一用是書生把ESNI這個task在Phabricator上發出，不過似乎討論到最後沒有一個明確的說法。（我是65.92.206.79，現在使用電話發言所以IP位址不一樣）207.164.79.114（留言） 2019年4月29日 (一) 13:32 (UTC)
喔喔，never mind，我又把thread仔細的看了一遍，在最後，2019年1月26日，有一行「Phabricator_maintenance moved this task from Backlog to Acknowledged on the Operations board.」也就表示維基媒體伺服器管理員已經「認知」此task了，放入議事日程了，讓我們靜待佳音吧。再一次感謝百無一用是書生手腳如此麻利，在Firefox去年12月剛宣佈支持ESNI以後就把此task在Phabricator上發出！（我是65.92.206.79，現在使用電話發言所以IP位址不一樣）207.164.79.114（留言） 2019年4月29日 (一) 14:14 (UTC)
在SNI審查的技術並不是破不了的情況下，推出ESNI或許未必是必要的，那些標準的制定者應該要綜合考慮到那些審查嚴重的國家會否擴大審查範圍，令繞過審查更加困難。近年來封鎖範圍的擴大實際上和https的普及不無關係。假如說讓IP成為唯一明文的內容，我覺得牆可能會不顧一切代價封鎖IP，畢竟這就是牆當年完全封鎖BBC所體現的作風（BBC當時分析稱牆完全封鎖BBC與其推出https有關）。--№.N（留言） 2019年5月2日 (四) 01:30 (UTC)
ESNI結合CDN的話，可能是會投鼠忌器（因為黑洞CDN的誤傷程度不可控制，需要解釋可能還會導致直接承認系統的實際存在）。不過對於基金會來說，有，可能只會更糟糕。——路過圍觀的Sakamotosan | 避免做作，免敬 2019年5月2日 (四) 03:49 (UTC)
@№.N 封鎖CDN的IP位址會造成重大的經濟損失，這也就是「依附的自由」所依靠的前提思想。但是我覺得HTTPS和以後的ESNI普及有保護私隱的重大意義，不都和翻牆有關係。我們生活在牆外的人們也不希望自己的ISP監視自己訪問了那些域名（特別是像PornHub這類的）。（我是65.92.206.79，現在使用電話發言所以IP位址不一樣）184.151.246.184（留言） 2019年5月2日 (四) 17:16 (UTC)
@さかもとさん：追求的正是這種「投鼠忌器」和「黑洞CDN的誤傷程度不可控制」的效果，不是嗎？這就是「依附的自由」。把封殺IP的經濟損失代價提到最高，這樣逼使牆放行所有流量。我不覺得需要解釋任何東西，也不用承認任何系統實際存在與否。等到牆外互聯網只剩下明文IP位址了，那麼牆就面臨着：要麼完全封殺牆外互聯網，要麼完全放行牆外互聯網。其實說實話現在的情況和完全封殺牆外互聯網已經沒有什麼兩樣了，封的只剩下GitHub了。我真的不覺得如果開啟了ESNI對於基金會來說會更加糟糕，因為已經不可能比現在所有語種的維基百科都被封殺了的情況更加糟糕了。（我是65.92.206.79，現在使用電話發言所以IP位址不一樣）184.151.246.184（留言） 2019年5月2日 (四) 17:16 (UTC)
近年來的政治環境表明，網絡審查只會往越來越糟糕的方向發展，而牆針對維基百科的封鎖手段不斷升級表明，維基百科在牆心目中的地位是如此之高。「因為已經不可能比現在所有語種的維基百科都被封殺了的情況更加糟糕了」，我覺得更糟糕的就是IP封鎖，但現在還沒到這境地，意味着只要想辦法繞過SNI這裏就行了。要真正逼牆放行所有流量，我覺得幾乎不可能，牆搞個白名單制度，就能解決「封殺IP的經濟損失代價提到最高」的問題。所以應對日益嚴格的審查，我覺得一味追求逼牆未必是正確的。--№.N（留言） 2019年5月3日 (五) 12:38 (UTC)
「一味追求逼牆」--①牆封殺向來就是權力的傲慢，是無理可循的，就算我們為牆考慮，不去逼牆，但是也難保牆抽風起來不會突然封殺所有維基媒體IP。②ESNI不光和翻牆有關，更加重要的是保護用戶私隱。HTTPS的普及也不是因為翻牆的緣故，而是因為斯諾登爆料PRISM計劃以後引起了軒然大波才導致大網站比如谷歌開始HTTPS化，進而推動所有牆外網站HTTPS化。所以可以想像未來ESNI的普及也不會是由於翻牆原因，而是因為需要保護用戶私隱。畢竟世界和互聯網不是圍繞牆轉的。（我是65.92.206.79，現在使用電話發言所以IP位址不一樣）172.97.230.191（留言） 2019年5月3日 (五) 20:26 (UTC)
「牆搞個白名單制度」--如果把依附的自由發揮到極致的話，就可以讓白名單制度也失效。試想一下：以後如果任何一個牆外IP位址都可以代理任何一個網站，然後除了IP位址以外其餘信息全部加密，試問這時牆究竟還能白名單什麼IP位址呢？在這種情況下牆白名單任何一個IP位址，都可以讓人們通過這個IP位址訪問所有牆外網站！（我是65.92.206.79，現在使用電話發言所以IP位址不一樣）172.97.230.191（留言） 2019年5月3日 (五) 20:35 (UTC)
牆畢竟是國家級別的，然而很可惜的是有的人還是想得太簡單，我去年以為搞了DNS加密就可以不怕牆了，沒想到剛好這時牆搞了個SNI。審查與反審查之間不存在最終贏家，兩者之間的戰爭不會終止，這和正版和盜版之間是一個道理。今年是兩大周年，一個30，一個70，肯定會有新動作。我覺得我把該說的都說了，我也不說什麼了。--№.N（留言） 2019年5月3日 (五) 23:37 (UTC)
@Liu116：70：1949年-2019年（PRC），30：1989年-2019年（？）-- Sunny00217 - 2019年5月4日 (六) 00:43 (UTC)
@Sunny00217 「30：1989年-2019年（？）」--指的是六四事件（我是65.92.206.79，現在使用電話發言所以IP位址不一樣）172.97.230.191（留言） 2019年5月4日 (六) 15:15 (UTC)
@№.N 我最後想說的就是ESNI上與不上不會是因為牆的原因，更加不會是因為你我的意志，而是外網上保護用戶私隱（以EFF為首）和ISP流量監測（以AT&T和Verizon公司為首）兩大陣營的角力為主。牆外的ISP進行流量監測主要是區別premium content，比如Verizon和臉書達成商業協議，所有使用臉書網站產生的流量不計算在移動數據流量之內，那這時就需要SNI來識別臉書流量了。兩大陣營角力的最終結果決定ESNI究竟是上還是不上。所以我覺得你完全沒有必要覺得ESNI會逼牆，因為上不上ESNI是完全與牆無關的。（我是65.92.206.79，現在使用電話發言所以IP位址不一樣）172.97.230.191（留言） 2019年5月4日 (六) 15:23 (UTC)
@№.N 「牆畢竟是國家級別的」--國家機器當然是強大的。如果有必要的話，甚至物理斷網都是可能的。「審查與反審查之間不存在最終贏家，兩者之間的戰爭不會終止，」--牆所進行的審查的最終結果無非就是封殺整個外網，而現在牆內互聯網的狀態已經和封殺整個外網沒有兩樣了（所有外網重要基礎設施網站比如谷歌、推特、臉書、油管、維基、Ins都被封殺殆盡），所以也早就見怪不怪了。【但是】（我要說但是了）如果要尋找外網，還是沒有什麼能擋住一個人的：比如可以到橫琴島澳門大學圍牆外蹭網，比如可以肉翻，等等。（我是65.92.206.79，現在使用電話發言所以IP位址不一樣）172.97.230.191（留言） 2019年5月4日 (六) 15:34 (UTC)

短連結工具

最新留言：5 年前1則留言1個人參與討論

做了一個Wikimedia URL Shortener的短連結工具User:Shizhao/shorturl.js，在左側導航條「工具」處，點擊後會給出該頁面的短連結--百無一用是書生 (☎) 2019年5月5日 (日) 09:33 (UTC)

Tech News: 2019-19

維基媒體技術社群發出最新技術新聞。請告知其他用戶以下變更。當然，未必所有變更都會影響閣下。翻譯本於此。

問題

  • Special:監視列表顯示了錯誤的資訊，它不能正確顯示哪些編輯已看過，哪些尚未看過。開發人員正在處理並解決這個問題。 [4]

本週後期變更

  •   MediaWiki新版本將於5月7日部署至測試維基及MediaWiki.org，及於5月8日部署至非維基百科站點及部分維基百科，並於5月9日部署至所有站點，參見日曆。

會議

技術新聞由技術大使製作並由MediaWiki信息遞送送達 • 貢獻 • 翻譯 • 獲取幫助 • 提供反饋 • 訂閱或退訂。

2019年5月6日 (一) 16:28 (UTC)

字詞誤轉換問題

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

在用大陸簡體查看汶川大地震條目時發現，公共轉換組「人物譯名」把「占」轉換為「吉姆」，導致出現了很多誤轉換的情況。比如「四川省佔總損失的91.3%」變成了「四川省吉姆總損失的91.3%」。這種問題在添加公共轉換組，或者在公共轉換組裏添加新字詞時很難發現。請問有什麼好的避免方法嗎？--藍色☆楓葉♂拉呱 2019年5月12日 (日) 03:33 (UTC)

單字不宜放入轉換組，容易誤轉換。可以考慮單向轉換。@Wilson Wong123：[5]--YFdyh000（留言） 2019年5月12日 (日) 12:47 (UTC)

魔法連結？

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

如題，[6]-- Sunny00217 - 2019年5月4日 (六) 00:38 (UTC)

User:Sunny00217  已修復。-- tang891228 留⁠言 2019年5月12日 (日) 15:30 (UTC)

嚴重例外類型?

最新留言：5 年前4則留言4個人參與討論
於Phabricator查看
編號T222628的任務
於Phabricator查看
編號T222857的任務
  • 在檢視薩塞克斯公爵夫人梅根條目的最新一次編輯時發現，使用"比較被選版本"功能，只要其中一筆是最新版本（由User:SSYoung編輯），另外畢比不管使用哪一個舊版本，都會跳出這個錯誤資訊：[XNOTogpAMEkAAIRoR-UAAABQ] 2019-05-09 02:42:42: 嚴重例外類型 "Wikimedia\Assert\ParameterTypeException"。想請問這是哪方面的問題？（檢視同一個用戶的其他編輯並無問題，目前我只有在這個條目發現這問題）風鳴（留言） 2019年5月9日 (四) 02:44 (UTC)
可重現。建議提報phab:--百無一用是書生 (☎) 2019年5月9日 (四) 02:56 (UTC)
我也見過類似的。（[7]）——路過圍觀的Sakamotosan | 避免做作，免敬 2019年5月11日 (六) 09:18 (UTC)
遇到同樣的問題[8]，看來不是個例--Leon3289（留言） 2019年5月13日 (一) 13:54 (UTC)

Tech News: 2019-20

維基媒體技術社群發出最新技術新聞。請告知其他用戶以下變更。當然，未必所有變更都會影響閣下。翻譯本於此。

本週後期變更

  •   MediaWiki新版本將於5月14日部署至測試維基及MediaWiki.org，及於5月15日部署至非維基百科站點及部分維基百科，並於5月16日部署至所有站點，參見日曆。

會議

技術新聞由技術大使製作並由MediaWiki信息遞送送達 • 貢獻 • 翻譯 • 獲取幫助 • 提供反饋 • 訂閱或退訂。

2019年5月14日 (二) 00:49 (UTC)

討論頁無法解除Flow

最新留言：5 年前1則留言1個人參與討論

在參數設置里解除了Flow勾選，但是討論頁仍是Flow，內容也沒有被存檔。安提洛夫斯基 2019年5月18日 (六) 09:35 (UTC)

Tech News: 2019-21

維基媒體技術社群發出最新技術新聞。請告知其他用戶以下變更。當然，未必所有變更都會影響閣下。翻譯本於此。

最近更改

問題

  • 在最近幾天，其他維基媒體wiki上沒有正確顯示維基共享資源的檔案描述，例如缺少了圖片描述和授權條款。這已經被修復了。 [9][10]
  • 當您嘗試檢視某些編輯差異時會顯示錯誤訊息，開發人員正在努力修復，這可能是因為一些編輯摘要所導致的。 [11][12]

本週後期變更

  •   MediaWiki新版本將於5月21日部署至測試維基及MediaWiki.org，及於5月22日部署至非維基百科站點及部分維基百科，並於5月23日部署至所有站點，參見日曆。

會議

未來更新

  • 維基百科上的內容翻譯工具可以使用機器翻譯。有個系統可以阻止編輯者發佈沒有修復機器翻譯錯誤的翻譯，如果他們僅是複製機器翻譯提供的內容，此系統會警告或阻止他們。如果這個系統太嚴格或不夠嚴格，你可以通知語言團隊。 [13]
  •   當向維基數據的wbeditentityAPI終端發出空的別名請求，它將會刪除所有別名，這是所預期的行為，但由於程式錯誤一直沒有正常工作。將在6月12日起正常運作。 [14]


技術新聞由技術大使製作並由MediaWiki信息遞送送達 • 貢獻 • 翻譯 • 獲取幫助 • 提供反饋 • 訂閱或退訂。

2019年5月20日 (一) 13:04 (UTC)

IAbot疑似故障？

最新留言：5 年前5則留言3個人參與討論

此筆編輯中，IAbot將title填寫為「存檔副本」，實際上應當為「Release notes — Anaconda 2.0 documentation」（取自互聯網檔案館的標題）。--泡泡小號028（留言） 2019年5月19日 (日) 09:25 (UTC)

強迫症：Imdb模板中的多餘空格

最新留言：5 年前1則留言1個人參與討論

本主題全部或部分段落文字，已移動至Template_talk:Imdb_title。執行人：Jimmy-bot（留言） 2019年5月30日 (四) 08:14 (UTC)。

Multilingual Shared Templates and Modules

最新留言：5 年前3則留言3個人參與討論
Hello zh-wiki community! (請幫助翻譯至您的語言)

I recently organized a project to share templates and modules between wikis. It allows modules and templates to be 「language-neutral」, and store all text translations on Commons. This means that it is enough to copy/paste a template without any changes, and update the translations separately. If someone fixes a bug or adds a new feature in the original module, you can copy/paste it again without any translation work. My bot DiBabelYurikBot can help with copying. This way users can spend more time on content, and less time on updating and copying templates. Please see project page for details and ask questions on talk page.

P.S. I am currently running for the Wikimedia board, focusing on content and support of multi-language communities. If you liked my projects like maps, graphs, or this one, I will be happy to receive your support. (any registered user group can vote). Thank you! --Yurik (🗨️) 2019年5月11日 (六) 07:50 (UTC)
@Yurik： This is an interesting middle ground and a great way to build templates. But Chinese Wikipedia has already developed a very different sets of templates and maintained by people. We have around 2k7 modules and it would be interesting to connect with other global wikiprojects. Nevertheless, due to the complexity of your proposal, I would like to work with you for a demo firstly. --Fantasticfears（留言） 2019年5月17日 (五) 21:43 (UTC)
@Yurik：(This is the translation for reference.)（此為翻譯內容，僅供參考。）
中文維基百科社區的用戶你們好！
我最近發起了一個在不同語言的維基之間共享模板和模塊的項目。這個項目可以使模板和模塊不再受語言所限制，並且將所有翻譯版本存儲在公共空間中。這意味着之後只需複製/粘貼模板然後更新翻譯內容即可，不用做其他任何更改。如果有人在原始模塊中修復了一個錯誤或添加了一個新功能，您可以在不進行任何翻譯工作的情況下再次複製/粘貼它。我的機械人Dibabelyurikbot可以幫助複製。這樣，用戶可以將更多時間致力於翻譯和撰寫內容上，而在更新和複製模板上花費較少時間。欲知更多詳細信息，請參見項目頁面，並在討論頁提問。
備註：我目前正在維基媒體基金會中競選，主要關注多語言社區的支持相關內容。如果你喜歡我的項目，如地圖，網絡圖，或以上這個項目，如果能收到你的支持我會很高興（任何註冊用戶組都可以投票）。謝謝您！
(PS:I highly support your project.Your project page, however, contains too much content. You know as non-native English speakers it takes so long to read them. So could you introduce a more straight way to experience your templates or modules, and support or vote for your project? )Puresnower（留言） 2019年5月22日 (三) 10:41 (UTC)

推薦一個工具

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

從英文維基搬來一個工具，功能如下：如果模板{{Location map}}在填入多個地圖時，此工具可以提供地圖切換。具體效果可查看Location map文檔（User selection of multiple maps部分），如果你沒有裝這個工具，樣例給出的兩幅地圖都會顯示，裝了這個工具效果就不一樣了。我已經將工具放到了用戶工具中。--Vozhuowhisper 2019年5月22日 (三) 13:46 (UTC)

這個遲早要被Kartographer拋棄掉吧--百無一用是書生 (☎) 2019年5月22日 (三) 14:31 (UTC)

修改火狐瀏覽器關於SNI的部分

最新留言：5 年前1則留言1個人參與討論

本主題全部或部分段落文字，已移動至Help_talk:如何訪問維基百科。執行人：Jimmy-bot（留言） 2019年5月31日 (五) 16:14 (UTC)。

{{infobox aircraft occurrence}}的第二飛機圖片出不來了

最新留言：5 年前1則留言1個人參與討論

本主題全部或部分段落文字，已移動至Template talk:Infobox aircraft occurrence。執行人：Jimmy-bot（留言） 2019年5月31日 (五) 16:14 (UTC)。

Wikiplus

最新留言：5 年前4則留言2個人參與討論
於Phabricator查看
編號T222628的任務

最近Wikiplus的編輯摘要若是開啟頁首摘要的快速編輯，會變成「/* */ // Edit via Wikiplus」，而導致被過濾器phab:T222857和phab:T222628擋下來。因為過去好像沒有出現過這個問題，想請問是否可以修正？---Koala0090（留言） 2019年5月23日 (四) 03:13 (UTC)

由於先前MW一個代碼提交，導致包含空的自動註釋（/* */）的修訂版本會在被查看或被比較時報錯。——星耀晨曦（留言） 2019年5月23日 (四) 05:04 (UTC)
@星耀晨曦：感謝講解，是否有機會修正呢---Koala0090（留言） 2019年5月23日 (四) 15:15 (UTC)
T222628已經歸類為Unbreak Now!，意味着最高優先級。相關修復補丁正在開發中[15]，估計幾天之內就會被修復。——星耀晨曦（留言） 2019年5月23日 (四) 16:12 (UTC)

音頻播放故障

最新留言：5 年前3則留言2個人參與討論

烏鶇#描述的那幾個音頻我放不出來，點擊播放沒有任何聲音，英文版就沒問題。其他條目似乎存在同樣問題。不知道是什麼緣故。--淺藍雪❉ 2019年5月23日 (四) 16:16 (UTC)

我這裏播放正常--百無一用是書生 (☎) 2019年5月23日 (四) 16:23 (UTC)
我放火狐就沒問題，Chrome用不了改了改設置搞定了。--淺藍雪❉ 2019年5月23日 (四) 16:44 (UTC)

模板展開限制

最新留言：5 年前6則留言4個人參與討論

草地貪夜蛾條目的演化一節，好像是因為{{Clade}}多層套疊的關係，有兩個跨語言連結模板無法正常顯示，有沒有朋友知道怎麼解決呢？非常感謝！--Wikimycota~🍄跬步千里 2019年5月17日 (五) 18:01 (UTC)

好像展開統計上有一些毛病，可能會令擴展字節數虛高。——路過圍觀的Sakamotosan | 避免做作，免敬 2019年5月18日 (六) 00:47 (UTC)
  • view-source:https://zh.wikipedia.org/wiki/%E8%8D%89%E5%9C%B0%E8%B2%AA%E5%A4%9C%E8%9B%BE 顯示：
<!--
Transclusion expansion time report (%,ms,calls,template)
100.00% 1941.213      1 -total
 87.97% 1707.710     29 Template:Clade
 32.33%  627.641      1 Template:Speciesbox
 32.01%  621.366      1 Template:Taxobox/core
 22.94%  445.259      1 Template:Reflist
 19.14%  371.598      1 Template:Taxobox/taxonomy
 13.81%  268.060      1 Template:Taxonbar
  9.99%  193.894     17 Template:Cite_journal
  9.96%  193.379    149 Template:Taxon_info
  9.82%  190.603     56 Template:Link-en
-->

-- Sunny00217 - 2019年5月19日 (日) 09:59 (UTC)

說到模板展開，感覺綠鏈過多容易出這問題。例如印度－美國關係，條目明明沒那麼長Template:美國外交居然無法展開……--№.N（留言） 2019年5月24日 (五) 02:41 (UTC)
顯然也爆了：
<!--
Transclusion expansion time report (%,ms,calls,template)
100.00% 1933.999      1 -total
 90.43% 1748.832      6 Template:Navbox
 72.82% 1408.424    380 Template:Link-en
 70.45% 1362.412    380 Template:Internal_link_helper
 43.44%  840.163      1 Template:美國外交
 42.72%  826.246      1 Template:Navbox_with_collapsible_sections
 39.17%  757.522      1 Template:印度外交
 38.68%  748.149      1 Template:Navbox_with_collapsible_groups
 20.95%  405.194    380 Template:Lan
  5.60%  108.245      1 Template:Infobox_bilateral_relations
-->
但為甚麼美國外交在那個位置（43.44%）還展不開？？？User:Liu116-- Sunny00217 - 2019年5月24日 (五) 13:37 (UTC)

Kotlin 其他語言，連結英文維基異常

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

中文Kotlin左側下方其它語言連結，「English」錯誤連結至en:Type inference而非en:Kotlin (programming language)。但en:Kotlin (programming language)中的語言連結「中文」是正常的指向Kotlin。我在「編輯連結」中，看不出問題在哪？請問這應該如何修改？--幽月暗影 2019年5月25日 (六) 03:01 (UTC)

@幽月暗影：頁面內有一個舊的跨語言連結，影響了wikidata的連結，已經移除。祝好。--AlexLeeCN（留言） 2019年5月25日 (六) 03:22 (UTC)

關於Jimmy-bot

最新留言：5 年前6則留言3個人參與討論

在使用{{Delete}}的F1及F5，需要加上保留檔案名稱，但多年來都會被Jimmy-bot改為<!-- 合理使用文件：xxxxxx.jpg -->，請參見此，我知道是因保留圖片是非自由版權之合理使用圖片而被Jimmy-bot加入隱藏字串，但前陣子Xiplus才修改過模組參數，卻依然會被Jimmy-bot加入隱藏字串，導致速刪模板又會變成「為方便管理員檢查，請加上保留檔案的名稱。」，請問這個問題該如何解決？麻煩@Jimmy Xu了，謝謝。－Bangardi 2019年5月23日 (四) 10:04 (UTC)

@Xiplus：目前是不是除非@Jimmy Xu修改Jimmy-bot的認定判斷，無法另使用修該模組參數的方式避免Jimmy-bot的編輯？－Bangardi 2019年5月25日 (六) 12:15 (UTC)
(：)回應@Sunny00217：Excellent! 這是個好方法！但根本上還是需要從模組或bot端修改，或是在模組自動加入防撞不知是否可行？－Bangardi 2019年5月25日 (六) 13:05 (UTC)
(：)回應@Happy60907：那個除了Jimmy-bot改應該沒其他辦法了，不過Jimmy Xu是很難叫的~~~~，或許只能暫時套用了-- Sunny00217 - 2019年5月25日 (六) 13:14 (UTC)
  已修復，Special:Diff/54550369。--Xiplus#Talk 2019年5月25日 (六) 13:33 (UTC)

Taxonbar

最新留言：5 年前5則留言3個人參與討論

想請問生物條目的Taxonbar和NoteTA是否能比照Authority control請機械人批量懸掛呢，並設計成不需要特別再加入Wikidata編號的方式--Koala0090（留言） 2019年5月23日 (四) 03:18 (UTC)

Tech News: 2019-22

維基媒體技術社群發出最新技術新聞。請告知其他用戶以下變更。當然，未必所有變更都會影響閣下。翻譯本於此。

本週後期變更

  •   資料庫副本將在6月3日進行重大變更，如果維護者沒有更新在Cloud Services上運行的工具以使用新的架構，則一些工具將會停止運作。這或許會影響到用來查詢用戶修訂版本或日誌項目的工具。 [16][17]
  •   MediaWiki新版本將於5月28日部署至測試維基及MediaWiki.org，及於5月29日部署至非維基百科站點及部分維基百科，並於5月30日部署至所有站點，參見日曆。

會議

技術新聞由技術大使製作並由MediaWiki信息遞送送達 • 貢獻 • 翻譯 • 獲取幫助 • 提供反饋 • 訂閱或退訂。

2019年5月27日 (一) 15:34 (UTC)

模板在條目頁面的顯示問題

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

以條目復仇者聯盟：終局之戰為例，底端的模板不能正常摺疊顯示，不知道是我的顯示問題還是大家都這樣？--Anilro（留言） 2019年5月28日 (二) 03:23 (UTC)

navibox太多ilh了，直接解析爆炸了。——路過圍觀的Sakamotosan | 避免做作，免敬 2019年5月28日 (二) 04:17 (UTC)

{{sfnm}}模版標點符號需要修正

最新留言：5 年前2則留言1個人參與討論

近日發現{{sfnm}}中，所使用的逗號是中文的全形，與其他sfn系列模版的半形不相容，排在同一個條目上極度不美觀，但是模版代碼精巧，不知如何修改，希望有大神能相助。

現在的情況是，當我輸入例如{{Sfnm|1a1=Smith|1a2=Jones|1a3=Johnson|1y=2005|1p=15|2a1=Jones|2a2=Johnson|2a3=Smith|2y=2004|2p=50}}時，跑出來的結果會是： [1]

  1. ^ Smith, Jones & Johnson 2005, p. 15; Jones, Johnson & Smith 2004, p. 50.

看得出來當初這個模版是為了中文化才設計成全形的，所以英文開起來格外彆扭，但是現下的狀況是連當輸入中文例如{{sfnm|1a1=黃金老|1y=2001|1p=20|2a1=呂桂玲|2y=2016|2p=97}} 時，跑出來的結果都很奇怪，會變成：[1]

  1. ^ 黃金老 2001, p. 20; 呂桂玲 2016, p. 97.
畫虎不成反類犬。

希望有大神能協助將模版修改成仿照母模版{{sfn}}的樣子，例如這樣：[1]

  1. ^ 黃金老 2001, p. 20.

以期版面美觀。不勝感激。—roughly the same [[w:zh:user ]] 2019年5月27日 (一) 15:23 (UTC)

在首頁加入農曆日期

最新留言：5 年前13則留言8個人參與討論

12年前，中文維基百科曾經有用戶提議並獲得大多數贊同在首頁上加上農曆日期，但貌似當時限於技術原因而未能實現，請問現在在維基百科上的工具可以實現這個要求嗎？ ——C933103(留言) 2019年5月3日 (五) 09:11 (UTC)

Wikipedia:用戶框/媒體裏面的模板炸了！

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

圖1、圖2。小豬佩奇身上紋，掌聲送給社會人。 2019年5月30日 (四) 12:02 (UTC)

User:社會我佩奇  已修復，{{User UFO 897}}裏的{{NoteTA}}造成的。-- tang891228 留⁠言 2019年5月30日 (四) 15:30 (UTC)
取自 "https://zh.wikipedia.org/w/index.php?title=Wikipedia:互助客栈/技术/存档/2019年5月&oldid=60988259"