维基百科:互助客栈/技术/存档/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://wiki.matr1x.workers.dev/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)

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

應該可行，但麻煩 --  Sunny00217  2020年8月17日 (一) 07:20 (UTC)

真想要彻底根除那就干脆不要用Cache了，直接每次新开 W+ 窗口都读取原文算了。
另外，谁来看看这里啊，这可能是一个有效的解决办法呢！
然后我的感觉是这个问题主要出在Cache和当前页面不匹配的问题。--🍀 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)