维基百科

维基百科:互助客栈/技术/存档/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”