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

Chrome下翻译工具Bug

近两天来，在Chrome浏览器中使用翻译工具，每打一个字，页面就会往上跳一下，以至于几乎无法正常使用，macOS和Windows均有此问题，基于Chrome的浏览器（如新版Edge）亦存在此问题，其他浏览器无该问题，故请求解决。--Bigbullfrog1996（留言） 2020年7月28日 (二) 23:31 (UTC)

可以考虑不用该工具。推荐用User:Vanished user 1929210/js/link-ts.js--1=0，欢迎加入WP:维基百科维护专题 2020年7月29日 (三) 00:23 (UTC)

• @蟲蟲飛：我之前说的会版面上下乱跳的BUG有人复现了（讨论）。不要再怀疑我夸大了。我一直以来都是实话实说的。谢谢。-- 娜娜奇🐰枫香花茶☕（宇帆·☎️·☘️） 2020年7月29日 (三) 03:44 (UTC)
  • 版面上下乱跳的问题我在普通文本编辑器也遇过，因此这无法归咎于翻译工具，可能是MediaWiki上不同编辑器都有同一个问题，也可能是Chrome的问题。 Xiplus#Talk 2020年7月29日 (三) 05:35 (UTC)

(※)注意：我用翻译工具没什么问题，反而我最近也遇到另一些问题，但不是翻译器，而是基本的编辑也出现问题，输入的字形符号都变成乱码，一定要从doc复制，才能发布文字。在drv也无法输入“+”，结果状态无法显示成蓝色；还有不同用户的权限标签也无法正常显示，总之现在维基整个系统都经常出现问题。--虫虫飞♡♡→♡℃※留言 2020年7月29日 (三) 03:53 (UTC)

@蟲蟲飛：您所说的问题权限标签无法正常显示应该跟#小工具失效属同一问题-- Sunny00217  2020年7月30日 (四) 01:20 (UTC)

请尝试提供更多信息。比如具体的系统版本和浏览器版本，在翻译具体哪个条目的时候会碰到这个情况，并且尝试在Mediawiki的安全模式和Chrome的无痕模式中尝试重现这个问题。如果您会使用Chrome的开发者工具的话，请尝试看看控制台中有哪些错误信息。目前阁下所提供的信息过少，无法定位问题。 VulpesVulpes825（留言） 2020年7月29日 (三) 06:51 (UTC)

• (？)疑问@Bigbullfrog1996：您有没有留下VulpesVulpes825所说的Chrome的开发者工具Console错误讯息资料呢？如有，可不可以发上来？感激不尽。-- 娜娜奇🐰枫香花茶☕（宇帆·☎️·☘️） 2020年7月29日 (三) 10:27 (UTC)

@A2569875：@VulpesVulpes825：Chrome版本是最新的84.0.4147.105，其上一个版本就已经有问题了。至于操作（作业）系统方面，我在macOS Mojave、macOS Catalina与Windows 10上都试了，均有此问题，故问题应该与Chrome有关，与系统无关。在条目方面，我试了翻译各种条目，均存在此问题，而非仅在翻译某特定条目时出现此问题。Console方面我看不太懂，都是些黄叹号，正常的网页打开Console检查其实也是一堆黄叹号，感觉没什么问题吧。--Bigbullfrog1996（留言） 2020年8月1日 (六) 23:02 (UTC)

在隐身模式和Mediawiki的安全模式呢？我这边用Chrome没有问题，这可能是因为您自己安装的Chrome插件或者您启用的小工具导致的问题。VulpesVulpes825（留言） 2020年8月2日 (日) 13:08 (UTC)

此外还有一个bug，就是目前通过翻译工具创建新条目后不自动链入其他语言wiki，只能手动添加。我拿其他浏览器试了，都是这样，不仅限于Chrome。--Bigbullfrog1996（留言） 2020年8月2日 (日) 00:48 (UTC)

Tech News: 2020-32

维基媒体技术社群现发出最新技术新闻。请告知其他用户以下变更。当然，未必所有变更都会影响阁下。有提供其他语言的翻译版本。

问题

• 在7月23日星期四的17:50至17:59 UTC之间，Wikidata Query Service的所有查询都失败了，有些查询在更长的时间段上失败。 [1]
• 在过去的几周，跨语言链接的顺序错误，此问题已在两周前的技术新闻中提到，现已修复。 [2]
• 全局偏好设定的“使用旧版Vector”选项目前有问题，开发人员正在进行修复。 [3]
• 在维基共享资源上，Wikibase扩充功能中的一个错误导致“移动”和“建立”保护类型在主要（Gallery）命名空间中被停用，无法设定新的保护，现存的保护也无法作用，导致允许了某些原本不应被允许的页面移动和建立。现已修复。 [4]

本周后期变更

• 影片播放器将变得更简单、更现代，目前的测试版功能将在本周成为维基百科以外的维基上所有人使用的影片播放器，旧版播放器将移除。 [5]
• 使用者的global.js和global.css页面即将也在移动版网站上载入，您可以阅读说明文件来了解如何避免将样式套用到移动版外观上。 [6]
• MonoBook外观上的searchGoButton识别字现在改为searchButton，这会影响CSS和JS小工具，可以在T255953上找到迁移说明。这个更改曾在第27期新闻中提到过。
• 机器人操作者可以使用Pywikibot来定时存档讨论，为了防止存档过大而由机器人使用的counter变数行为被修改。 [7]
• MediaWiki新版本将于8月4日部署至测试维基及MediaWiki.org，8月5日部署至非维基百科站点及部分维基百科，8月6日部署至所有站点，参见日历。

技术新闻由技术新闻作者制作并由MediaWiki信息递送送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

2020年8月3日 (一) 15:43 (UTC)

mediawiki:prefs-vector-enable-vector-1-label是不是应该改成“使用旧的vector皮肤”才对？--百無一用是書生 (☎) 2020年8月4日 (二) 01:04 (UTC)

translatewiki那边已有人改了。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2020年8月4日 (二) 01:18 (UTC)

如何修改用户common.js实现中文与外文、数字之间含半角空格

根据Wikipedia:格式手册#空格，这些情况不应该有空格，但是为了视觉上更加美观，所以来提这个问题。

以下不可用

var reg = /(?:([0-9A-Za-z_])([\u4e00-\u9fa5]))|(?:([\u4e00-\u9fa5])([0-9A-Za-z_]))/g;
$('.mw-parser-output').textContent = $('.mw-parser-output').textContent.replace(reg, '$1$3 $2$4');

var reg = /(?:([0-9A-Za-z_])([\u4e00-\u9fa5]))|(?:([\u4e00-\u9fa5])([0-9A-Za-z_]))/g;
var result;
$('.mw-parser-output).each(function () {
    while( match = reg.exec(targetText) !== null ) {
        this = this.replace(reg, "$1$3 $2$4");
    }
});

str = document.getElementsByClassName('mw-parser-output')[0].outerText;
let s1 = /([0-9A-Za-z_])([\u4e00-\u9fa5])/g;
let s2 = /([\u4e00-\u9fa5])([0-9A-Za-z_])/g;
temp = str.replace(s1, "$1 $2");
str = temp.replace(s2, "$1 $2");

--Hakuryuu^讨论★ 2020年8月3日 (一) 20:14 (UTC)

importScript('User:AnYiLin/pangu_wiki.user.js'); --安忆^Talk 2020年8月4日 (二) 01:20 (UTC)

多个不同页面的界面讯息以HTML原样显示的问题

于Phabricator查看
编号T259565的任务

已知Bug，仅于此通知。--Xiplus#Talk 2020年8月4日 (二) 04:08 (UTC)

刚发现移动版页面低端的最后修订历史，也就是绿色的那一栏的内链显示异常，用户名变成URL地址。--百战天虫（留言） 2020年8月4日 (二) 06:02 (UTC)

维基百科:用户框/政治团体上方的小图标出现BUG

维基百科:用户框/政治团体上方的小图标出现明显大小不一的情况，我对照了编辑纪录还是找不出来问题出在哪里。--Cbls1911（留言） 2020年8月6日 (四) 16:30 (UTC)

请求翻译Template:Infobox beauty pageant模板

请求熟悉翻译模板操作的帮忙翻译en:Template:Infobox beauty pageant到中文维基。－日月星辰 | 留言簿 2020年8月6日 (四) 22:11 (UTC)

翻译模板其实就是把英文那边的内容贴过来，把label翻译一下，没有什么难的。你可以自己尝试一下。另外最好还要把模板的doc翻译一下--1=0，欢迎加入WP:维基百科维护专题 2020年8月7日 (五) 01:20 (UTC)

翻译不过关，有些地方感觉翻得不到位 囧rz...，所以还是想请熟悉翻译模板的帮忙。－日月星辰 | 留言簿 2020年8月8日 (六) 14:17 (UTC)

就了解一下情况

新用户不能用户名中英混合？--Herobrine 303🍀留名 _{疫情尚未结束，切勿放松警惕!🦠} 2020年8月1日 (六) 03:57 (UTC)

不行。以“中Eng”测试的结果是：“已禁止使用使用者名称 "中Eng"，以避免混淆或欺骗使用者名称：包含不兼容的混合文字。 请使用其他使用者名称。”SANMOSA _SPQR 2020年8月9日 (日) 03:19 (UTC)

AF可以做到拦截某一个页面里列出的所有域名这种功能吗?

如题。即使用AF实现类似Spamblacklist的功能，但因为是过滤器，因此较Spamblacklist更为灵活。相关讨论：[8]。--Yining Chen（留言|签名） 2020年8月9日 (日) 09:57 (UTC)

Technical Wishes: FileExporter and FileImporter become default features on all Wikis

The FileExporter and FileImporter will become a default features on all wikis until August 7, 2020. They are planned to help you to move files from your local wiki to Wikimedia Commons easier while keeping all original file information (Description, Source, Date, Author, View History) intact. Additionally, the move is documented in the files view history. How does it work?

Step 1: If you are an auto-confirmed user, you will see a link "Move file to Wikimedia Commons" on the local file page.

Step 2: When you click on this link, the FileImporter checks if the file can in fact be moved to Wikimedia Commons. These checks are performed based on the wiki's configuration file which is created and maintained by each local wiki community.

Step 3: If the file is compatible with Wikimedia Commons, you will be taken to an import page, at which you can update or add information regarding the file, such as the description. You can also add the 'Now Commons' template to the file on the local wiki by clicking the corresponding check box in the import form. Admins can delete the file from the local wiki by enabling the corresponding checkbox. By clicking on the 'Import' button at the end of the page, the file is imported to Wikimedia Commons.

If you want to know more about the FileImporter extension or the Technical Wishes Project, follow the links. --For the Technical Wishes Team:

Max Klemm (WMDE) 2020年8月6日 (四) 09:14 (UTC)

此改动不会对我们有影响-- Sunny00217  2020年8月6日 (四) 10:54 (UTC)

有影响。配置文件居然放在mediawiki里边，而不是存储在本站的Mediawiki名字空间下？现在一大堆非自由版权的文件都显示可以移动到commons。--Antigng（留言） 2020年8月7日 (五) 14:47 (UTC)

Antigng例如哪个档案？--Xiplus#Talk 2020年8月8日 (六) 13:25 (UTC)

Xiplus，比如File:Linyi_jichang_logo.jpg。--Antigng（留言） 2020年8月8日 (六) 13:56 (UTC)

Antigng您是不是没有实际按过汇出。--Xiplus#Talk 2020年8月8日 (六) 13:59 (UTC)

所以是要用户实际操作了，才知道无法导出？毕竟本站不会向非管理员显示封禁/保护按钮，不会向非回退员显示回退按钮；TW在设计的时候也不会在主名字空间显示“告状”按钮，或是在非File名字空间显示提报文件侵权的按钮。该新功能要求用户实际操作以后方知可行与否，恐怕在设计上并不合理。--Antigng（留言） 2020年8月9日 (日) 13:53 (UTC)

反例是受标题黑名单禁止的页面仍会显示编辑按钮，在尝试编辑时才显示无法编辑。如果使用者“永远不会”有权限执行操作，则不会显示按钮（例如封锁），如果“有些情况可以、有些不行”，则会显示按钮。如果不能转移的图片没有显示按钮，使用者无法看到为何该档案无法转移，甚至可能会认为该功能坏了。--Xiplus#Talk 2020年8月9日 (日) 14:05 (UTC)

垃圾链接过滤器有时候连T:URL也不让加

如题，往U:Rowingbohe/玉环市的条目信息框加入{{URL}}时出现。错误：垃圾过滤器禁止保存您刚才提交的页面，这可能是由于您所加入的外部网站链接所产生的问题。您可以使用此工具测试您加入的链接匹配哪条本地或全域垃圾链接黑名单，并请参见外部链接使用指引。如果您确认垃圾过滤器封锁有误，请在垃圾链接黑名单讨论页面提交修复请求。如果您只是允许一个特定的链接，而不是要移去黑名单上的整个链接，您可以到垃圾链接白名单的对话页提出请求。以下文本触发了我们的垃圾链接过滤器：%20

但刚刚在其他条目复现时未见此问题，很奇怪。--—Rowingbohe♫ _{欢迎参与浙江专题 台州专题} 2020年8月6日 (四) 20:19 (UTC)

Spamblacklist功能不保存触发黑名单的问题编辑，所以我无法确切地知悉您到底在这个页面里干了什么事情。但是根据垃圾链接黑名单日志，您试图加入的是"http://www.yuhuan.gov.cn%20www"这个非法的网址，它与黑名单规则%20是匹配的。您加入的模板，在展开以后包含的链接肯定是非法的。可能是模板的问题，也可能是您的输入一开始就是非法的。为了搞清楚，请您提供相应编辑的具体内容，谢谢。--Antigng（留言） 2020年8月7日 (五) 15:03 (UTC)

我刚开始进行的是大幅扩充，遇到拦截分段查看，发现问题后进行多次复现，源代码直接加入{{URL|和}}。—Rowingbohe♫ _{欢迎参与浙江专题 台州专题} 2020年8月10日 (一) 10:07 (UTC)

无法重现，Special:Diff/61099224。--Antigng（留言） 2020年8月10日 (一) 10:34 (UTC)

1.我指的是在http://www.yuhuan.gov.cn左侧加入{{URL|，右侧加入}}（非要我加上<code>？）2.本人发讨论串时候已经说了在其他页面无法复现，请见第二段，所以很奇怪。谢谢合作。—Rowingbohe♫ _{欢迎参与浙江专题 台州专题} 2020年8月10日 (一) 10:44 (UTC)

刚刚复现成功，本人授权您编辑此用户页以复现。—Rowingbohe♫ _{欢迎参与浙江专题 台州专题} 2020年8月10日 (一) 10:46 (UTC)

你有八成加入的文本是这个：{{URL|http://www.yuhuan.gov.cn ​}}，告结。

P.S. 如果你不理解原理的话，我只能说：Cewbot大法好！--Antigng（留言） 2020年8月10日 (一) 10:50 (UTC)

你说不可见字元（大概是零宽空格？）啊，懂了。。这个东西就应该在条目空间禁止加入，但是应该改进警告方式，像禁止Category的过滤器那样，拦截方式应该人性化一点。如果我知道是不可见字符，就乖乖开启编辑器里那个工具找了。—Rowingbohe♫ _{欢迎参与浙江专题 台州专题} 2020年8月10日 (一) 11:01 (UTC)

经复现，大概是另外两成。—Rowingbohe♫ _{欢迎参与浙江专题 台州专题} 2020年8月10日 (一) 11:07 (UTC)

问题在于{{Infobox China County}}会自动帮你补上{{URL}}，你再加一个URL就等于是嵌套{{url|{{url|www.example.com}}}}，这显然是非法使用，出什么意外都不奇怪。--Antigng（留言） 2020年8月10日 (一) 11:37 (UTC)

哦。你牛逼。—Rowingbohe♫ _{欢迎参与浙江专题 台州专题} 2020年8月10日 (一) 11:55 (UTC)

Tech News: 2020-33

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

• FileImporter and FileExporter became standard features on all Wikis during the first week of August. They help you transfer files from local wikis to Wikimedia Commons with the original file information and history intact. [9]

Problems

• The mobile skin displays a message at the bottom of the page about who edited last. This message showed raw wikitext. This has now been fixed. Some messages in Structured Discussions and content translation may still appear as raw wikitext. Developers are working on it. [10]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from August 11. It will be on non-Wikipedia wikis and some Wikipedias from August 12. It will be on all wikis from August 13 (calendar).

Future changes

• All wikis will be read-only for a few minutes on September 1. This is planned between 13:30 and 15:30 UTC. More information will be published in Tech News and will also be posted on individual wikis in the coming weeks. [11][12]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

2020年8月10日 (一) 16:06 (UTC)

关于Adjacent stations的问题

有熟悉adjacent stations模板的人知道为什么大桥头站的adjacent stations参数note-mid1和note-mid2内容相同，却无法合并成一个储存格的原因吗？--owennson（聊天室、奖座柜） 2020年8月11日 (二) 07:56 (UTC)

• special:permalink/61113158，猜测是{{台北捷运颜色}}的nowiki#　。-Zest 2020年8月11日 (二) 08:19 (UTC)

Twinkle更新 (2020-08-11) @efa3cd6

近期变更

• 回退：已修复先前从IP段的使用者贡献页发起回退时，无法正确地抓取IP而在编辑摘要中错误显示为“已隐藏的使用者”的问题
• 关闭存废讨论：已修复在关闭使用者命名空间的页面时发生的崩溃问题（#137）
• 保护：已修复之前标记无限期保护模板时会出现参数错误的问题（#143）
• 封锁：“确认为傀儡”的封锁预设设定现在分为“根据使用者贡献确定”和“使用者查核确认”，封锁日志摘要将与选项保持一致（#144）
• 警告：已修复在结构式讨论页上无法警告的问题，并会显示不支援自动警告层级的提示讯息（#146）
• 欢迎：新增欢迎使用者的功能，如果您不想要此功能可在偏好设定中关闭。如需增添常用的欢迎模板，请在Twinkle讨论页提出（#138）
• 偏好设定：已移除“在这些类别的回退后打开使用者讨论页”中无用的“恢复此版本”选项（#148）

如果近期变更有任何错误，或是认为未来变更会造成任何问题，请在Twinkle讨论页、互助客栈技术版或Github择一报告。--Hamish论 2020年8月11日 (二) 08:02 (UTC)

• (～)补充：讨论：WT:TW正在讨论无人讨论的建议与漏洞，欢迎参与。-- 霜奶仙在此发言 （会客室｜签名区）_{师..师...师父，什么是孜然自然？} 2020年8月12日 (三) 16:05 (UTC)

gg.sxbb.me

(？)疑问：某编者的这个编辑、这个编辑、这个编辑、这个编辑，将ref中books.google.com网址冠上gg.sxbb.me，他说是视觉化编辑自动带入的，请问这是正常的吗？--Hjh474（留言） 2020年8月7日 (五) 10:57 (UTC)

算是正常的，他可能使用的反代站点编辑的，是其站点的自动替换，提交的时候又没有检查。 --安忆^Talk 2020年8月7日 (五) 12:03 (UTC)

说几句重话。使用第三方反向代理编辑而不仅仅是阅读，这件事情从一开始就是错的。无论是直接访问，还是使用诸如VPN，TOR之类的工具间接访问本站，wmf服务器的运作方式，以及所涉及的协议（HTTPS，TOR等等）保证了在成功的情况下，你所接收到的内容是绝对完整与正确的。但是第三方反向代理不同，它根本就在最底层就把https请求和/或响应给拆开了，它可以对收到的数据作任意修改，再转发给使用这些反向代理的用户，而在用户一端，是没有机制去保证他/她所获取的内容确实是wmf的服务器想发给他/她的——这内容可不仅限于页面内容，也可以是js脚本——也自然没有机制去保证第三方没有窃取相应信息。

纵观本站使用被某些编者使用得比较频繁、允许编辑的第三方反向代理，其中有多少在技术上可以做到与wmf提供同等的安全性？那些使用源自中国大陆的VPS提供者来搭建的第三方反向代理，能否从根本上避免为响应北京政府的执法请求，而造成用户隐私数据泄露的问题？对wmf而言，隐私权的重要性自然是不言而喻的，这也是其激进地推行HSTS的其中一个原因。这些站点中，有些居然连单独的TOU或介绍隐私权政策的页面都没有，却在另一方面暗示编者可以透过申请WP:IPBE加以编辑——从技术上说，有了IPBE，即使再严厉的IP封禁也奈何不了使用如此站点加以编辑的编者；然而这种在技术上可行的行为，又是否与wmf保护用户隐私权的精神相符呢？本人持强烈的保留意见。

最后谈谈技术问题。第三方反向代理为了改善用户体验，会对链接甚至文本中的链接进行一定程度的重写，将其改为指向反向代理的链接。这正是造成上述问题的根源。是否可能对反向代理的规则进行优化，以保证浏览的时候替换，编辑的时候不替换，给用户提供完全等同于原站的编辑体验呢？答案当然是否定的。想象一下如下的两个场景：

1. 某脚本利用本站的解析器提供的html内容配上更好的排版方式，来改善读者的浏览体验。
2. 某脚本利用本站的解析器提供的html内容，做出了一个更好的可视化编辑器。

无论是何者，都需要透过相同的api向本站服务器请求html内容。前者要求第三方反向代理在工作时重写链接，而后者要求第三方反向代理不重写链接，这是做不到的。当然，如果一律重写链接，还可以在后续用户提交编辑的POST请求中将链接替换回来——但另一方面，如果用户真想探讨这个反向代理站的问题呢？不又是错误替换了么？

当然目前真正的ve是通过action=visualeditor工作的，你或许可以辩解在脚本制作者配合的情况下，通过action=parse和action=visualeditor就可以区分这两个场景。但是不要忘了parsoid（现在已经用php重写了）在将来是要取代老版解析器，并移入mediawiki的core里边的，在将来就没这种差异可以利用了。

--Antigng（留言） 2020年8月7日 (五) 16:03 (UTC)

• “使用第三方反向代理编辑而不仅仅是阅读，这件事情从一开始就是错的”——何解？什么人能让GFW网开一面。您我能访问或是编辑不代表所有人都能如此，给想要贡献的人一个途径，也不错。何不食肉糜？
• “你所接收到的内容是绝对完整与正确的”——不一定，GFW或区域网关都有能力做到MITM，修改的数据到了用户侧后依然会被认为是“安全的”。
• “也自然没有机制去保证第三方没有窃取相应信息”——“非礼勿视，非礼勿听，非礼勿言，非礼勿动。”不是所有人都是恶意的，维基用户的数据，收集来除了占用空间之外也没什么其他的意义。
• “有多少在技术上可以做到与wmf提供同等的安全性”——您以为WMF那套很安全？
• “使用源自中国大陆的VPS提供者来搭建的第三方反向代理，能否从根本上避免为响应北京政府的执法请求，而造成用户隐私数据泄露的问题”——据我所知，没有反代使用大陆VPS的。“北京政府的执法请求”又是什么。
• “这也是其激进地推行HSTS的其中一个原因”——HSTS和您说的其实没多大关系，HSTS只验证HTTPS证书链完整而不验证发布者。即只要证书链完整就都是合规的。
• “有些居然连单独的TOU或介绍隐私权政策的页面都没有”——有了又能如何，没有又能如何，一纸空文罢了。
• “另一方面暗示编者可以透过申请WP:IPBE加以编辑”——还是那句话：“何不食肉糜”。
• “这种在技术上可行的行为，又是否与wmf保护用户隐私权的精神相符”——您完全信任WMF，但为什么对第三方持百分百恶意。
• “是否可能对反向代理的规则进行优化，以保证浏览的时候不替换，编辑的时候替换，给用户提供完全等同于原站的编辑体验呢？答案当然是否定的”——答案当然是肯定的。
• “前者要求第三方反向代理在工作时重写链接，而后者要求第三方反向代理不重写链接，这是做不到的”——这也是做得到的。

我虽然不知道您是什么专业，但相关技术上，您不精；道德上，您这百分百的恶意推测实在是令人不敢苟同。对他人稍稍善意一些，也好。

--安忆^Talk 2020年8月8日 (六) 05:14 (UTC)

我稍微总结下，您的意思无外乎也就是这几点：我能用，别人不能用不关我事，是他们自己不行；您的数据超级值钱，所有人哪怕采取各种手段，也都要去得到它们；WMF百分百安全，第三方百分百是小偷。 --安忆^Talk 2020年8月8日 (六) 05:25 (UTC)

以及IPBE，WMF完全可以弄一个信任代理名单，对于名单上的服务器，信任其传递的X-Forwarded-For标头（其包含用户的真实IP），这样就不用IPBE了（因为代理服务器的IP总是被封禁的，WMF现今又只识别实际连接它的IP，X-Forwarded-For标头全都被舍弃），也不用担心XFF标头会被伪造，因为XFF标头是由用户实际连接代理服务器的IP构成的——代理服务器可信，其发送的标头即可信。 --安忆^Talk 2020年8月8日 (六) 05:35 (UTC)

感谢资讯分享，颇有收获。若如此，编者提交编辑前是不是应该检查与清理？强迫（点选ref的）读者连上gg.sxbb.me，似乎不太好，编者虽无恶意，但是反代站如此替换似乎并非善意。--Hjh474（留言） 2020年8月8日 (六) 06:00 (UTC)

反代站不是人，没有善恶之分。设置过滤器即可（如298号过滤器）。顺便说一句，反代站不进行替换的话又该如何去实现反代呢。 --安忆^Talk 2020年8月8日 (六) 06:07 (UTC)

• (：)回应：
• “给想要贡献的人一个途径，也不错”：账户安全性既关乎个人信息的安全，也关乎本站的安全。它并非完全由用户掌控，进而可以随意让渡而换取其它便利的事物。某commons管理员账户被盗，导致站点common.js被插入恶意挖矿脚本的教训还不够深刻么——事后我们设置了界面管理员，但如果用户不注重帐户安全，又如何能保证这样的问题将来不会再发生？就算届时您的账户真被盗用了，我们把您除权、封禁甚至禁制了，对本站造成的损失能弥补么？而且不要以为不是管理员，账户的安全性就不重要。回退员就仅仅有一个回退功能么？别忘了他/她们还可以查看过滤器规则和细节。巡查员只能巡查么？别忘了他/她们自己有巡查豁免权。大量信息发送者，机器人，全域重命名员，这些权限的重要性我还有必要解释么？
• “不一定，GFW或区域网关都有能力做到MITM，修改的数据到了用户侧后依然会被认为是‘安全的’。”：只要你不信任由中国大陆控制的CA机构颁发的根证书，通过什么途径能实现这样的目标？这种说法从根本上是颠覆了HTTPS原理，完全无法理解。
• “您以为WMF那套很安全？”：事实1：根据WMF发布的透明度报告，其声称自成立以来从未响应过非传统意义上的民主国家的政府提出、涉及用户隐私的执法请求；事实2：早在十年以前，WMF就透过IPSEC来保护数据中心间/数据中心内部缓存服务器间的通信，在五年以前开始以HTTPS来保护数据中心内部，缓存服务器与后端应用层之间的通信。
• “HSTS和您说的其实没多大关系，HSTS只验证HTTPS证书链完整而不验证发布者。即只要证书链完整就都是合规的。”：我不要您觉得，我要WMF觉得。早在WMF全面启用HSTS之前的2013年，WMF的职员就已经意识到，启用HSTS一方面可以防范部分中间人攻击的情形，另一方面可能会让部分封杀HTTPS的地区彻底失去访问维基的可能性。最后它还是决定这样做了，中国大陆也在事实上失去了直连部分维基站点的可能性。使用第三方反向代理进行登录和编辑，则恰恰是对这样的原则的妥协。
• “据我所知，没有反代使用大陆VPS的”：请您回到这个讨论的标题，sxbb.me乃中国大陆注册的初创企业“师兄帮帮”，搭在腾讯云之上。
• “有了又能如何，没有又能如何，一纸空文罢了”：这是网站向用户的承诺。连一纸空文都没有，届时倘若网站真的侵犯到了用户的权利，用户如何维权？
• “您完全信任WMF，但为什么对第三方持百分百恶意”：请勿打稻草人靶子。本人并没有断言第三方代理提供者的动机如何，本人强调的是机制。没有机制保证第三方代理会以怎样的方式中继来自WMF服务器的内容，没有机制保证第三方代理如何使用用户的个人数据，部分第三方代理甚至没有在纸面上保证会如何对待这些问题。这本身就是一个问题，无论第三方服务是出于善意还是恶意。
• “这也是做得到的。”：请解释。
• “我虽然不知道您是什么专业”：物理。
• “但相关技术上，您不精”：请指出。
• “道德上，您这百分百的恶意推测实在是令人不敢苟同”：如上，请勿立稻草人。本人没有对第三方反向代理提供者的动机作出任何程度的断言。
• “我能用，别人不能用不关我事”：这的确是本人的想法，因而在过去，我一直是主张按照IPBE方针的字面意思授予相应权限的。本人亦多次对本站滥发IPBE权限的现状有所不满。
• “是他们自己不行；您的数据超级值钱，所有人哪怕采取各种手段，也都要去得到它们；WMF百分百安全，第三方百分百是小偷”：稻草人，这不是本人的想法。本人在乎的是用户隐私和本站自身的安全。

--Antigng（留言） 2020年8月8日 (六) 06:59 (UTC)

• 我知道您在担心什么，也完全能够理解。安全性是重中之重，您担心用户遇到恶意站点，但反代站不都是钓鱼的，总会有正常的站点。像我最开始说的“给想要贡献的人一个途径”，我不觉得有任何问题。虽然用户遇到这二者中的哪一种是完全看运气。但是否继续使用，用户自己还是有选择的自由。俗话说：“用人不疑，疑人不用”。最重要的是，如果在大陆想要浏览或编辑维基百科，无外乎采用这几种方式：“VPN、反代、Tor”，显然，Tor对一般用户来说太遥远，VPN和反代站是最常用的选择。但您认为这两种技术哪种相对安全呢？我认为是反代站——二者的架设者都可以看到一切，但显然VPN能看到的更多。安全是相对的，总不该因噎废食。
• 您信任WMF发布的透明度报告，那为什么就不能多给第三方一些信任呢？使用反代站进行登录和编辑，真的是对安全性的妥协吗？不是所有人都是好人，但也不是所有人都是坏人。您没有断言提供者的动机，您说您强调的是没有机制保证内容的安全，没有机制保证用户的隐私，那么，您上面的回复是使用了何种绝对安全的手段作出的呢？
• 您说您在乎的是用户隐私和本站自身的安全。安全性方面我上两段说了一些我的想法，用户隐私方面，我个人认为，没有价值的用户数据或是隐私没有窃取和窥探的意义。我也搭建了一个反代站：技术上，我可以看到一切；但道德上，我知道自己不能那样做；而利益上，那堆数据对我毫无意义，完全没有犯罪的动机。^{[开玩笑的]}
• 至于您提到的sxbb.me，那是主域名。其用来反代的域名是这个，是香港阿里云。
• 至于您提到的两个功能性方面的问题，您不要忘了，使用者是人，而不是机器。可以把选择发给前端让用户自己选择。

• 我最想说的其实只有一句话：“不该一棒子打死所有人”，仅此而已。

其实有一些站点我也看不上眼，我在这里提到了一些例子和预想的标准。除非GFW被拆了，那么反代站、VPN或是其他的东西就不可能消失，与其说“这件事情从一开始就是错的”，不如做一个好的示范。

--安忆^Talk 2020年8月8日 (六) 10:49 (UTC)

“给想要贡献的人一个途径不觉得有任何问题/不该因噎废食”：这一点放在WMF的语境下是值得商榷的。如果WMF认为提供这样一种相对而言安全风险比较高的途径给受网络封锁的国家/地区的编者“没有任何问题”、“不该因噎废食”，那么当初它就不会在明知风险存在的情况下，堵死明文HTTP访问本站的途径，就不会一刀切强制重定向到HTTPS，防火长城现在可能也不会采取全站点封杀这种策略——但是WMF就是这样做的，连数据中心内部这种安全风险比较低的场景也是一刀切强制HTTPS。本人的bot当初在wmflabs（现在叫toolforge）上工作的时候找了个漏洞继续明文HTTP，被WMF的人发现了还被批评教育了。

“显然VPN能看到的更多”：从原理上完全无法理解。VPN工作在网络层，根本无从知悉应用层的东西，更何况VPN建立以后，若仍按照默认的HTTPS方式直连本站，你想知道HTTPS也不会让你知道，VPN提供者只知道你在什么时间连了什么站，交换了多少数据，而不可能知道这数据的具体内容。这就与反向代理有本质的不同。当然我不是说使用VPN编辑不对本站造成安全隐患——但这种隐患主要来自其对CU工作的干扰，而不是隐私。

另外需要强调的是，恐怕更为常见（或者传统意义上的）翻墙技术是使用正向代理。无论是基于HTTP的正向代理（透过CONNECT机制）还是基于SOCKS的正向代理（例如Shadowsocks），在处理HTTPS流量的时候实际作用都只是建立一条虚拟通道而已，并不会影响到应用层。

“是否继续使用，用户自己还是有选择的自由”：选择的自由是建立在知情的基础之上的。对于一个不熟悉的用户而言，正向代理和反向代理都是“代理”，完全可能会认为它们拥有等同的安全性。--Antigng（留言） 2020年8月9日 (日) 14:51 (UTC)

“给想要贡献的人一个途径”是我觉得没有问题，不需要WMF认为如何如何。WMF那套哪怕再安全，也是它们内部的安全，当使用代理的时候，这种安全就已经是不完整的了。如果大陆的用户现在想要继续参与几乎已经全线被墙的维基媒体计划，就只能使用间接的方式，您前面几次强调了WMF的各种策略，那您能提出来一个对于大陆用户的既安全又实用便捷的访问手段吗？您对反代持反对态度，认为它们“不安全”，但我也一直在说“不该一棒子打死所有人”，因为不是所有人都是好人，但也不是所有人都是坏人。反代在现在的环境下，显然是一种不错的选择。我还是这个观点：除非GFW被拆了，那么反代站、VPN或是其他的东西就不可能消失，与其说“这件事情从一开始就是错的”，不如做一个好的示范。并且，对于一个不熟悉的用户而言，他们压根儿不会去深入了解甚至不会考虑什么安全性，对于他们，是“能用就行”，甚至是“有得用就行了”。

说点儿无关的：现在几乎所有反代站都是非盈利、凭热情而建的，我作为一个反代站的建立者，我个人觉得您这善意缺失的推测还是自己放在心里想想就好。这让我想起了前段时间在群里聊天遇到的一个人，他正上初中的妹妹被班主任骚扰，大家都在为其出谋划策，这时候偏偏有一个人跳出来说“万一是他妹妹勾引老师的”。有的时候，“众人皆醉我独醒”，不好。何况，对于伪装成网银的钓鱼网站来说，有其存在的意义，因为利益可观；但对于维基这套，我只在是想不出那堆没有价值的用户数据和隐私有什么窃取和窥探的意义，也就只能拿来占空间而已吧。

--安忆^Talk 2020年8月9日 (日) 15:42 (UTC)

“当使用代理的时候，这种安全就已经是不完整的了”⸺并非如此。使用（正常的）代理只会比直连更安全，在仍旧享受HTTPS所保证的不可篡改性之时，对目标网站与网络审查者分别隐匿了身份与活动。

使用第三方反向代理，除了考虑对维护者的信任外，也要考虑网站漏洞等问题。就像GoAgent会拆开HTTPS连接导入自己的证书，这已经是不使用它的充分理由了，并非不信任其开发者。--Lt2818（留言） 2020年8月11日 (二) 03:34 (UTC)

这问题很简单，如果某用户担心自己账号被盗，那他自己不用镜像站就可以了。安忆的站之前顶上就有提示了，不信任请勿登录编辑。安全和cross wall编辑总得选一个吧。您举了c站common.js被植入挖矿脚本的例子，举了界管的例子，但是用镜像站的用户真的都是界管吗？真的都可以编辑MW:Common.js吗？—Rowingbohe♫ _{欢迎参与浙江专题 台州专题} 2020年8月10日 (一) 12:01 (UTC)

这可能是一个安全问题，已经在Phabricator上向维基媒体基金会安全部门提交工单（见T260016）。VulpesVulpes825（留言） 2020年8月10日 (一) 07:50 (UTC)

@VulpesVulpes825：太好了，相当感谢，希望有好消息。--Hjh474（留言） 2020年8月10日 (一) 11:50 (UTC)

目测基金会即将封杀反向代理—Rowingbohe♫ _{欢迎参与浙江专题 台州专题} 2020年8月10日 (一) 12:01 (UTC)

虽然……但是……它封不掉的 --安忆^Talk 2020年8月10日 (一) 14:18 (UTC)

封锁IP就行了吧，似乎没必要做技术性改动。--Lt2818（留言） 2020年8月11日 (二) 03:34 (UTC)

反代型的本身就是一个安全和不合适的方法吧，甚至早期镜像站指的还是基于数据库dump构建的静态数据库镜像型的。反代型的是否添加xff属于想不想的问题，而不是必要的，而且无法保证用户安全和编辑数据的安全（想这个把自己反代地址套进去的就不是小问题了）。可能对于反代型的方法并不应该鼓励。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2020年8月13日 (四) 02:30 (UTC)

是不该鼓励，不过却也是一个对于一般用户来说颇为“易用”的方法。在全面封锁的背景下，“可用性”与“安全性”二者之间总该有一个去妥协。 --安忆^Talk 2020年8月13日 (四) 02:51 (UTC)

但除了反代站外，还有一种单纯的“可用性”方法，就是普通的正向代理，这个唯一的问题就是IP地址不符合用户实际位置，但一定程度上默许存在，而反代站对数据安全的潜在影响，我认为不应该鼓励，有必要做一些限制措施。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2020年8月13日 (四) 03:58 (UTC)

正向代理（比如各种协议的VPN）被阻断的几率很高，同时相比于检测到特定协议就会被阻断的正代，只要不大规模公开反代受到阻断的几率也低得多（标准的HTTPS、完全与“黑名单域名”不同的SNI）。虽然部分站点安全性存疑，但维基也是禁止开放代理的（我想就是因为收不到用户真实IP，而反代可以解决这个问题——反代服务器有能力通过XFF标头将用户的真实IP传给维基服务器），所以堵不如疏，我觉得“可信名单”会改善这个情况。至于限制反向代理，我个人认为很难，手段无外乎就是ban IP、Referer验证之类，这些都有解决方案。 --安忆^Talk 2020年8月13日 (四) 04:15 (UTC)

如何处理

(？)疑问：我们该怎么做，才能不被“gg.sxbb.me”持续侵入ref呢？只能靠偶然发现+手动清理吗？--Hjh474（留言） 2020年8月8日 (六) 11:11 (UTC)

一般来说，只能如此。靠手动修正。 --安忆^Talk 2020年8月8日 (六) 11:20 (UTC)

可以考虑列为黑名单，禁止加入相关网址。 【和平至上】^{支持通过港区国安法}💬 2020年8月9日 (日) 12:50 (UTC)

@和平至上：不好意思，请问黑名单是指WP:RSP吗？--Hjh474（留言） 2020年8月9日 (日) 15:11 (UTC)

类似298号过滤器的手段。 --安忆^Talk 2020年8月9日 (日) 15:42 (UTC)

是的。--【和平至上】^{支持通过港区国安法}💬 2020年8月9日 (日) 18:05 (UTC)

题外话：gg.sxbb.me好像是个Google的镜像站。——BlackShadowG^★（留言） 2020年8月12日 (三) 09:37 (UTC)

也是维基的，应该是用的 https://github.com/aploium/zmirror 。 --安忆^Talk 2020年8月13日 (四) 02:15 (UTC)

Reply tool as a Beta Feature

Hello, User:Taiwania Justo and other editors,

I have good news for you.

The mw:Editing team held the mw:Talk pages consultation 2019 last year.  mw:Talk pages project/replying is the first major tool that they built because of that consultation.

Right now, the tool is available at the French, Arabic, Dutch, and Hungarian Wikipedias as a Beta Feature. The Editing team is making a short list of Wikipedias that will get the new 'Reply' tool as a Beta Feature next week. About 8 more Wikipedias will get access to the Reply tool. It will be opt-in. To use the tool, you will have to go to Special:Preferences#mw-prefsection-betafeatures and turn on the tool. If you don't turn it on, nothing will change for you.

The Chinese Wikipedia is currently on their list. I have been using the Reply tool at many wikis, and I love it. However, if, for some reason, you have changed your minds for any reason and do not want this Wikipedia to get access to this tool next week, then please tell me as soon as possible. Otherwise, I will assume that it's okay. Whatamidoing (WMF)（留言） 2020年7月30日 (四) 22:35 (UTC)

You can test it on this page, by clicking https://zh.wikipedia.org/wiki/Wikipedia:互助客栈/技术?dtenable=1 if you want. Whatamidoing (WMF)（留言） 2020年7月30日 (四) 22:37 (UTC)

The Beta Feature is ready! You can go to Special:Preferences#mw-prefsection-betafeatures and turn on "讨论工具" to use it. Then go to any normal, wikitext-based talk page and look for the [ 回复 ] button at the end of existing comments/signatures. Whatamidoing (WMF)（留言） 2020年8月6日 (四) 19:53 (UTC)

Hello, User:Taiwania Justo and other editors,

Something broke yesterday with the Reply tool. The ticket is phab:T259855. The main symptom was that English-language namespaces were replaced with the local content language and that some characters were percent-encoded. At this stage, there should be no more bad diffs being created. Please check for bad diffs. The Editing team apologizes for the difficulties. Please ping me if you see new problems. Whatamidoing (WMF)（留言） 2020年8月7日 (五) 17:36 (UTC)

Hello, it seems that the tool doesn't work on this Wikipedia nowadays? When I press the [回复] button, a pop-up window appeared and said that "由于wikitext中的错误，本页面上的评论将无法被回复。您可以通过[$1阅读文档]以了解这个错误，通过[$2在这里发帖]寻求帮助，也可以通过通过[$3打开全页编辑器]修复这个错误。"——BlackShadowG（留言） 2020年8月8日 (六) 11:44 (UTC)

@BlackShadowG：现在可以了吧，是有人在本页加入造成Lint错误的语法所造成，至于您无法正常地看到错误讯息也是另一个错误，现在应该也修复了？--Xiplus#Talk 2020年8月8日 (六) 13:56 (UTC)

现在可以了，谢谢您。 BlackShadowG^★（留言） 2020年8月9日 (日) 12:55 (UTC)

Thank you for this note about a problem. I'm glad that it has been fixed. If you see any problems with the Reply tool, please post them to mw:Talk:Talk pages project/replying so the Editing team will see them.  You can also leave a note on my talk page, or "ping" me to any page at the Chinese language Wikipedia.

At the moment, they are particularly interested in these problems:

• The Reply Tool doesn't use the correct/expected wikitext.
• The Reply Tool cannot be used to reply to a specific comment (for example, the problem BlackShadowG found).
• The [ 回复 ] button isn't shown on a page where people are talking.

but they are interested in all of your questions, comments, problems, and ideas.  Feedback from the Chinese Wikipedia is very important to the Editing team, and they are happy that the Reply tool is already popular with this community. Whatamidoing (WMF)（留言） 2020年8月13日 (四) 18:29 (UTC)

有没有这类模板

已自行解决Antigng（留言） 2020年8月20日 (四) 08:28 (UTC)

下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

---

为了要让#expr可以运作，有没有模板可以让1,000➡️1000？--卫星 (定位) 2020年8月20日 (四) 06:13 (UTC)

已找到formatnum，感谢：—卫星 (定位) 2020年8月20日 (四) 06:19 (UTC)

---

本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

Wikiplus的造成编辑冲突的bug及其成因

一段时间以来贵站陆续有用户抱怨在条目评选页面使用Wikiplus编辑会导致编辑冲突、特定章节被无故覆盖/移除的情形，以至于有用户甚至提出在评选页面完全禁止Wikiplus、要求客户端代替服务器承担检查编辑冲突、甚至拆分评选页面这样的，头痛断头、脚痛剁脚、治标不治本的方法。Wikiplus的开发者User:镜音铃则声称工具使用了basetimestamp参数检查编辑冲突，理因不会出现这种情况，因而不知问题何在。本人非常好奇的是，既然这是Wikiplus的bug，为什么不简单、直接地对Wikiplus下手，从根本上解决问题呢？

于是本人安装了最新版本的Wikiplus，尝试了两个小时左右便重现出了编辑冲突。复查操作时的步骤和Wikiplus的源码便可立即得出以下的结论：

Wikiplus处理编辑冲突的逻辑存在根本性的缺陷。它虽然遵守了mediawiki的机制，引入了时间戳以便服务器检查编辑冲突，但它却破坏了时间戳和提交的编辑所基于的历史版本的编号（revid）之间至关重要的一一对应关系。一方面，Wikiplus在且仅在页面加载之时，获取一次页面当前版本的时间戳，之后页面上无论进行何种操作，这一时间戳始终保持不变，并将会在提交的编辑中用作basetimestamp参数。而另一方面，Wikiplus仅在用户实际点击“快速编辑”按钮，加载编辑框的时候，才通过index.php?action=raw获取页面的文本。获取basetimestamp和获取页面文本两个时刻之间——可能非常长、取决于用户打开页面阅读多久再点击编辑按钮——的时间差，本质上破坏了版本号与时间戳之间的一一对应关系，这段时间内完全可能有一个或多个新版本被提交。因此，它有机会造成最后提交的编辑“基于某个新版本，但用着一个更旧的版本的时间戳”的错误情形，是绝对不可以接受的。

这种对应关系的破坏如何造成编辑冲突乃至整个章节被覆盖呢？本人能想到、也实际测试成功的最简单情形如下。考虑下列步骤：

1. 在浏览器的新标签页（记为标签页1）中打开任意一个有多于两个章节的讨论页（此时页面的版本记作版本a）；
2. 保持该标签页打开，后续过程中不得对其进行刷新；
3. 打开一个新的标签页（记为标签页2），在标签页2中加载相同的讨论页；
4. 在标签页2中使用常规编辑功能，拿走该讨论页最顶部的章节，提交编辑；
5. 编辑成功后（此时页面的版本记作版本b），回到标签页1，点击除第一节之外任意一个章节的快速编辑按钮，试图使用Wikiplus对其开展编辑；
6. 此时，你会发现Wikiplus的编辑框里出现的，实际上是下面一个章节的内容；
7. 你推断你要编辑的内容实际上位于上面的一个章节，你点开它的快速编辑按钮，发现的确如此；
8. 现在关闭Wikiplus编辑框，转到标签页2；
9. 使用常规的撤销功能，在标签页2中撤销你先前做出的、移除讨论页最顶部章节的操作，完成撤销操作（此时页面的版本记作版本c）；
10. 回到标签页1，此时你知道你要编辑的内容位于实际章节的上面一个章节，你再次点开快速编辑按钮，结果如你所料，编辑框中出现了你想要编辑的章节；
11. 你使用Wikiplus留了言，并保存了编辑；
12. 现在你成功地替换掉了一个章节，造成了编辑冲突。

测试，最后一笔编辑发生了冲突。

之所以会发生冲突，原因是显而易见的。Wikiplus的错误工作机制，导致最后提交的编辑，拿的是版本a的时间戳，而标签页2上进行的删除再撤销的动作又意味着，Wikiplus在提交编辑之前，页面当前版本是版本c，它的内容恰恰和这个时间戳所对应的版本、也就是版本a的内容完全一致，服务器正确地意识到，你在版本a上编辑，和你在当前版本——即版本c——上编辑没有任何实质的区别，一切防编辑冲突的逻辑便理所当然地被短路。但讽刺的是，Wikiplus提交编辑的内容，所基于的恰恰是与版本a和版本c都不相同的版本b，结果当然只会是编辑冲突，造成编辑的内容被移除。

当然本人并没有断言Wikiplus造成的一切编辑冲突都是历经上述12步而发生的，完全可能存在更复杂的情形；但本人有理由相信它们的根源都来自Wikiplus处理编辑时，时间戳和版本的不匹配性。该bug理应得到修复。

以上。

--Antigng（留言） 2020年8月17日 (一) 03:14 (UTC)

@镜音铃：，抄送，检查下这个理论是否符合？——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2020年8月17日 (一) 05:48 (UTC)

我有一个简单的想法，就是在点下“快速编辑”之时也检查是否有编辑冲突，如有则提示刷新页面，如无再将该段落存入缓存，不知是否能解决问题。因未有仔细思考，如有不当，恳请指出。--🍀 CLOVER YAN (^_^) 回复请ping我 2020年8月17日 (一) 07:12 (UTC)

应该可行，但麻烦 --  Sunny00217  2020年8月17日 (一) 07:20 (UTC)

真想要彻底根除那就干脆不要用缓存了，直接每次新开 W+ 窗口都读取原文算了。
另外，谁来看看这里啊，这可能是一个有效的解决办法呢！
然后我的感觉是这个问题主要出在缓存和当前页面不匹配的问题。--🍀 CLOVER YAN (^_^) 回复请ping我 2020年8月18日 (二) 01:25 (UTC)

这也太好笑了，我提案的目的除了解决编辑冲突还有其他目的，而且我说了只是想听听大家的看法（毕竟英维就是这么做的），实在没想到还有人到处逼逼赖赖半天，还“讽刺的是”，这有什么可讽刺的？另外这玩意甚至不应该在技术版出现，应该出现在镜音铃的讨论页。—Rowingbohe♫ _{欢迎参与浙江专题 台州专题} 2020年8月17日 (一) 07:19 (UTC)

(！)意见U:Rowingbohe这很显然应该出现在技术版，任何想要写外部编辑工具的维基人都应该要注意此现象。-- 娜娜奇🐰枫香花茶☕（宇帆·☎️·☘️） 2020年8月17日 (一) 09:28 (UTC)

自这一刻起，不。--Antigng（留言） 2020年8月17日 (一) 09:20 (UTC)

(▲)同上：我觉得安亭可以看看我在这里提到的（和现在这个讨论大同小异）：“同时建议您的语气柔和一些，‘我最近又发现了你的xx的一个bug’可以换成‘您的xx在我这里使用起来好像出现了一点儿小问题，您能抽空帮忙查看一下吗？’，‘我发现xx经常会出现错误，这可能是一个bug，请尽快修复’同理。您给出的只是建议或请求，而不是意见、要求和命令，我建议您通读这篇提问的智慧”，这个放到前段时间的关于反代站的讨论也是一样的，您面对的是有情绪的人，而不是理性人。 --安忆^Talk 2020年8月17日 (一) 07:36 (UTC)

说实话，Antigng写的Bug Report挺好的。出了什么错和错误步骤都写的挺清晰的，符合要求。如果Phabricator上的用户提报都能写的这么清楚就好了。反而Phabricator非常非常非常讨厌这种“我发现xx经常会出现错误，这可能是一个bug，请尽快修复”这种不知所云的工单。 VulpesVulpes825（留言） 2020年8月17日 (一) 16:41 (UTC)

您看错了，“我发现xx经常会出现错误，这可能是一个bug，请尽快修复”是我举例的错误示范…并且我的意思是“同上”，不用什么“讽刺的是”或者什么其他乱七八糟的词，好好委婉点儿说话不好吗？ --安忆^Talk 2020年8月17日 (一) 23:12 (UTC)

客观的问题上是就是是，不是就是不是；是bug就是bug，不是就不是，不确定就是不确定，哪有把确定的是当不确定描述的道理？如果所有的是都要当不确定来表述，那是和不确定有什么区别？别人如何知悉本人是究竟确定还是不确定这是一个问题？如果有人看到这样一篇观点与事实泾渭分明，遣词造句严谨（体会一下“本人能想到、也实际测试成功的最简单情形”、“结果当然只会是编辑冲突”、“完全可能存在更复杂的情形”、“本人有理由相信它们的根源”之类的表述）的论述还会“闹情绪”，那我只能建议他/她多接受一些学术训练，而不是向本人提意见。谢谢。Antigng（留言） 2020年8月17日 (一) 09:30 (UTC)

建议抄送一份直接到User_talk:镜音铃。不过鉴于好像有不少编辑很喜欢使用这个第三方（最早见过这个编辑器的是在萌百上）编辑器，放到技术版好像会有更好的告知。BTW，萌百的维护者账号应该是[13]。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2020年8月17日 (一) 10:36 (UTC)

我认为按照以上流程造成编辑冲突是可能的。只是，如果需要这么复杂的触发条件（页面被编辑而后再撤回，且另一编辑者在此之间开始快速编辑），事情的发生概率应该不会有这么高。不过目前并没有更合理的解释。针对该问题，我计划使用starttimestamp参数代替basetimestamp参数，这一参数与版本没有对应关系。不知各位看法如何。--镜音铃（留言） 2020年8月17日 (一) 11:11 (UTC)

镜音铃不管用。mediawiki仅使用starttimestamp来阻止编辑-删除冲突，见editpage.php中的逻辑；它无法代替basetimestamp解决编辑-编辑冲突的功能。Antigng（留言） 2020年8月17日 (一) 12:57 (UTC)

另外，在只涉及一笔中间编辑的情况下也有可能引发编辑冲突（即使用版本a的时间戳和基于版本b的内容，去提交编辑，不需要引入版本c），导致内容被覆盖；但是这涉及到mediawiki处理编辑冲突的机制，触发条件不稳定。示例：版本a、版本b、冲突。Antigng（留言） 2020年8月17日 (一) 13:17 (UTC)

@Antigng：那么，在获取文本时指定版本号，保证其与打开页面时一致能否防止这种问题的发生。--镜音铃（留言） 2020年8月17日 (一) 15:39 (UTC)

镜音铃可行，这同时也解决了章节不匹配的问题；不过要考虑那个修订版本被删除的情形。Antigng（留言） 2020年8月18日 (二) 00:45 (UTC)

乱写的实现。Antigng（留言） 2020年8月18日 (二) 14:20 (UTC)

这样就有一个问题：对于页面中嵌入带章节页面的情形，如果要编辑的是嵌入的那个页面里边的章节，实际上是要去加载、编辑另外一个页面，但是这个页面的id/basetimestamp并没有在初始化的时候获取。Antigng（留言） 2020年8月19日 (三) 02:32 (UTC)

@All 由于工作繁忙，而且Wikiplus的代码太过陈旧，我需要一些时间熟悉代码再进行修改，这会花一些时间。--镜音铃（留言） 2020年8月20日 (四) 15:45 (UTC)

Twinkle更新 (2020-08-21) @736d210

近期变更

• 保护：
  • 新增模板保护层级（#152）
  • 现在将在界面中显示最近一次的保护日志详情（#145）
• 标记：重大更新（#139）

1. 能更方便地输入重新导向和档案自订维护标记的模板额外参数
2. 对模板额外参数做出检查，并能发现不可同时使用的模板
3. 正确地将维护模板插入在消歧义或删除性模板之下以遵守版面布局格式指引

• 封锁：现在将在界面中显示最近一次的封锁日志（#145）
• 警告：
  • 已修复有时无法在Flow讨论页上发出警告的问题（#155）
  • 在界面、编辑摘要、Flow标题中，警告的5个层级（1至4im）已改称为提醒、注意、警告、最后警告、唯一警告，其中单层级通知及警告分别对应改为提醒和警告（#155）

如果近期变更有任何错误，或是认为未来变更会造成任何问题，请在Twinkle讨论页、互助客栈技术版或Github择一报告。--Hamish论 2020年8月21日 (五) 06:55 (UTC)

请问怎么在字幕蓝连中连结维基文库？

已解决。空气小猫（留言） 2020年8月22日 (六) 08:09 (UTC)

下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

---

如上，如何在蓝连中连结维基文库？--卫星 (定位) 2020年8月21日 (五) 14:09 (UTC)

• 这个Wikipedia:维基文库里边应该有。--Air7538^{不来签个名再走嘛？} 2020年8月22日 (六) 00:18 (UTC)
• [[:s:（您要的名稱）|（您要的名稱）]]，不过要谨慎使用。—— Eric Liu _{创造は生命（留言．留名．学生会）} 2020年8月22日 (六) 01:39 (UTC)

---

本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

Tech News: 2020-34

维基媒体技术社群现发出最新技术新闻。请告知其他用户以下变更。当然，未必所有变更都会影响阁下。有提供其他语言的翻译版本。

最近更改

• 如果您透过撤销连结来回退编辑，您的编辑会标记撤銷标签；现在起只有您没有在发布前修改编辑框内的任何内容才会标记，这是为了防止使用者实际上进行其他操作的编辑被标记为撤销。 [14]
• 新的OOUI版本将无法在Internet Explorer 8上运作，这表示维基将在Internet Explorer 8上看起来奇怪而且无法运作地很好。这已在2020年第17期技术新闻中提过，要让维基在非常旧的浏览器上运作将会导致其他问题。 [15]

本周后期变更

• MediaWiki新版本将于8月18日部署至测试维基及MediaWiki.org，8月19日部署至非维基百科站点及部分维基百科，8月20日部署至所有站点，参见日历。

未来更新

• 所有维基将在9月1日的几分钟内只读，预计在13:30到15:30 UTC之间发生，更多资讯将会在下周于技术新闻和各个维基上发布。这只是一个提醒，您可以帮忙翻译公告讯息。 [16][17]

技术新闻由技术新闻作者制作并由MediaWiki信息递送送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

2020年8月17日 (一) 20:41 (UTC)

---

请问有什么模板有使用到OOUI，我想要为这些模板的/doc页加上{{BrowserUpdate}}--林勇智 2020年8月22日 (六) 01:30 (UTC)

每个页面都会使用到OOUI，包括界面上的图示，因此挂模板没有用。空气小猫（留言） 2020年8月22日 (六) 08:16 (UTC)

Tech News: 2020-35

维基媒体技术社群现发出最新技术新闻。请告知其他用户以下变更。当然，未必所有变更都会影响阁下。有提供其他语言的翻译版本。

本周后期变更

• MediaWiki新版本将于8月25日部署至测试维基及MediaWiki.org，8月26日部署至非维基百科站点及部分维基百科，8月27日部署至所有站点，参见日历。

技术新闻由技术新闻作者制作并由MediaWiki信息递送送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

2020年8月24日 (一) 17:59 (UTC)

请求对MediaWIki命名空间下的所有页面连锁保护

已完成：

问题已解决。空气小猫（留言） 2020年8月26日 (三) 16:52 (UTC)

下列讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

---

如题，管理员积压。空气小猫（留言） 2020年8月22日 (六) 06:46 (UTC)

• 请提供相关讨论。另，如果需要这样做，直接在mediawiki的配置文档里操作比一个一个保护更加方便。Antigng（留言） 2020年8月22日 (六) 07:13 (UTC)

  @Antigng：就是这个意思。虽然没有相关讨论，但是MediaWIki仅限界面管理员，那么其中被引用的模板允许所有使用者说不过去吧？例如Template:Tag description，一个一个请求也不是办法。 空气小猫（留言） 2020年8月22日 (六) 08:07 (UTC)

不是所有MW空间都有使用模板，再加上有些嵌入的模板就是特意开放给非管理员编辑，因此全部保护是不必要也是不正确的。--Xiplus#Talk 2020年8月23日 (日) 06:32 (UTC)

• 刻意开放也需要保证其无法被破坏吧，至少也要半保护或模板保护吧。—- 娜娜奇🐰枫香花茶☕（宇帆·☎️·☘️） 2020年8月23日 (日) 07:43 (UTC)
• @Xiplus：如果是这样的话，目前仍有像是Template:Tag description这样被MediWIki引用的页面未被保护，万一此类页面遭到破坏，可能界面会因此出现问题。空气小猫（留言） 2020年8月23日 (日) 12:25 (UTC)

可以针对性发现后再保护。——Sakamotosan路过围观杯弓蛇影| 避免做作，免敬 2020年8月24日 (一) 00:44 (UTC)

• 有些保护不得，例如Template:Bulletin。-- Sunny00217  2020年8月23日 (日) 13:08 (UTC)
  • 是这样没错，不然就是要自动分类，收录有被MediaWIki引用的页面，方便管理员设定保护。空气小猫（留言） 2020年8月23日 (日) 13:49 (UTC)
  • @Antigng、Xiplus、A2569875、Sunny00217：这样如何？空气小猫（留言） 2020年8月23日 (日) 13:50 (UTC)
    • 如果仅仅是要方便管理员保护，那没有必要添加分类。让@xiplus：多打一个数据库报告就行了。Antigng（留言） 2020年8月26日 (三) 02:19 (UTC)
      • 只有10个MediaWiki页面需要保护，并已执行完毕。--Xiplus#Talk 2020年8月26日 (三) 05:29 (UTC)

---

本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

模组:CGroup/KO TV Show

在模组:CGroup/KO TV Show中“原文：펀치；简体：Punch；繁体：Punch；大陆：重击；台湾：逆转人生180天；香港：绝命反击；澳门：绝命反击；当前显示为：逆转人生180天”导致所有维基百科条目里有套用这个模板都会让韩国歌手Punch被转换，例如：[18](这是修改前的样子)，希望能修改，看要如何调整电视剧与人物之间不影响转换。--～Lonely Smile^★ 2020年8月30日 (日) 03:32 (UTC)

Tech News: 2020-36

维基媒体技术社群现发出最新技术新闻。请告知其他用户以下变更。当然，未必所有变更都会影响阁下。有提供其他语言的翻译版本。

问题

• 提醒各位，所有wiki预计在9月1日14:00到15:00 UTC之间的几分钟内只读，请查看公告讯息以了解详情。 [19][20]

本周后期变更

• 本周没有MediaWiki的新版本。

技术新闻由技术新闻作者制作并由MediaWiki信息递送送达 • 贡献 • 翻译 • 获取帮助 • 提供反馈 • 订阅或退订。

2020年8月31日 (一) 20:10 (UTC)