維基百科:互助客棧/技術/存檔/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)