维基百科:互助客栈/技术

维基百科,自由的百科全书
跳到导航 跳到搜索

Breezeicons-categories-32-applications-development.svg

本頁用作讨论在编辑时遇到的技术问题;發表問題或討論前,請先參閱常見問題解答帮助信息MediaWiki基本問題及搜索舊討論記錄。另請注意:

請注重礼仪及遵守方針與指引,一般問題請至互助客棧其他區知识问答提出,留言后请务必签名(点击 Signature icon april 2018.png )。


發表前請先搜索存档,參考舊討論中的内容可節省您的時間。
公告板
# 話題 發言 參與 最新發言 最後更新(UTC+8)
1 請求增加Icon模板的功能和修改內文 1 1 Jimmy-bot 2020-08-09 00:14
2 Tech News: 2020-31 5 3 Shizhao 2020-07-30 10:48
3 Chrome下翻译工具Bug 11 7 VulpesVulpes825 2020-08-02 21:08
4 马来西亚航空370号班机空难條目出現bug 2 2 A2569875 2020-07-31 02:11
5 Reply tool as a Beta Feature 6 3 Xiplus 2020-08-08 21:56
6 請為檔案上傳精靈適配非自由內容使用依據模板功能 5 5 TimWu007 2020-08-09 11:36
7 希望技術區能幫忙看看問題出在哪 8 3 Z7504 2020-07-31 17:49
8 就了解一下情况 2 2 Sanmosa 2020-08-09 11:19
9 能幫忙把Template:DC8/talk右上角半保護模板圖示只顯示一個嗎? 3 2 Z7504 2020-08-04 21:16
10 Tech News: 2020-32 2 2 Cwek 2020-08-04 09:18
11 如何修改用户common.js实现中文与外文、数字之间含半角空格 2 2 AnYiLin 2020-08-04 09:20
12 多個不同頁面的介面訊息以HTML原樣顯示的問題 2 2 百战天虫 2020-08-04 14:02
13 提议利用脚本实现半自动化提报内容评选 4 3 百战天虫 2020-08-08 00:53
14 Technical Wishes: FileExporter and FileImporter become default features on all Wikis 6 4 Xiplus 2020-08-08 21:59
15 維基百科:用戶框/政治團體上方的小圖標出現BUG 1 1 Cbls1911 2020-08-07 00:30
16 垃圾链接过滤器有时候连T:URL也不让加 2 2 Antigng 2020-08-07 23:03
17 請求翻譯Template:Infobox beauty pageant模板 3 2 Nickice 2020-08-08 22:17
18 gg.sxbb.me 12 3 AnYiLin 2020-08-08 19:20
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時,
請先檢查設定是否有誤

請求增加Icon模板的功能和修改內文[编辑]

Tech News: 2020-31[编辑]

2020年7月27日 (一) 13:51 (UTC)

刚切到新皮肤吓了一跳,还以为我浏览器渲染出问题了...--百無一用是書生 () 2020年7月28日 (二) 00:45 (UTC)
话说,谁知道正常的新皮肤是什么样子?看了mw:Reading/Web/Desktop Improvements,怀疑中文版的是不是不正常?正常情况下右边有大片空白吗?--百無一用是書生 () 2020年7月28日 (二) 00:50 (UTC)
當你把側欄摺疊起來的時候,左右兩邊都有空白。--Xiplus#Talk 2020年7月28日 (二) 09:51 (UTC)
这是Wikimedia的设计选择(见T246420)。但如果您是使用大屏幕访问维基百科的话,新Vector留的空白实在是太多了。我已经提报到Phabricator(见T258277#6343629)。 VulpesVulpes825留言) 2020年7月29日 (三) 07:35 (UTC)
这样留白的话,页面内容部分很多地方的样式可能需要重新设计了。首页可能也需要改进才行--百無一用是書生 () 2020年7月30日 (四) 02:48 (UTC)

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)

马来西亚航空370号班机空难條目出現bug[编辑]

在下發現马来西亚航空370号班机空难條目被不正常地添上超連結,只要一在條目中用滑鼠點擊任何一處便會進入一個名為「Soundcloud」的網站。未知出現了什麼問題?又可否請各位協助解決?--Win. M. 2020年7月30日 (四) 17:50 (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)

請為檔案上傳精靈適配非自由內容使用依據模板功能[编辑]

現行的精靈不知道在做什麼,例如,我上傳了一張電子遊戲畫面截圖,在介面裡已經勾選了遊戲截圖的選項,結果出來還是用了{{Non-free use rationale 2}},而不是更符合的{{Non-free use rationale video game screenshot}},另外紅色*的「必填選項」都填寫完了,上傳後模板竟然提示replaceability跟commercial參數沒有填寫,違反WP:NFCC,還要手動處理,那麼這倆不是應該預設就放在「必填選項」裡面嗎?希望能夠檔案上傳精靈適配非自由內容使用依據模板功能,勾什麼選項就出來什麼模板。—— Eric Liu 創造は生命(留言留名學生會 2020年7月31日 (五) 03:32 (UTC)

支持,现在有很多非自由檔案文件依據模板,这些模板可以协助编者(尤其是新手)写出比较出色的非自由文件的合理使用依据,如果把这些模板中的已经较为成熟的模板加入上传精灵会很方便,我每次传完Logo图片还得手动把{{Non-free use rationale 2}}替换成{{Non-free use rationale logo}}。——BlackShadowG留言) 2020年8月8日 (六) 11:50 (UTC)
因为那会导致程序行数增多,所以编程的人不喜欢这么做。他们更希望用同一个东西处理更多的情况。--1=0欢迎加入WP:維基百科維護專題 2020年8月8日 (六) 12:59 (UTC)
@Alexander Misel:那至少也要處理“上傳後模板竟然提示replaceability跟commercial參數沒有填寫,違反WP:NFCC,還要手動處理”的問題,我想到Wcam就心煩。SANMOSA SPQR 2020年8月9日 (日) 03:23 (UTC)
(+)支持。另@Sunny00217:在下半年前曾向您反映过相关问题,上传文件向导的部分选项并不会填写{{Non-free use rationale 2}}的replaceability跟commercial参数,如果是logo也不会填入author。每次上传完后都要再换模板或者修改参数十分麻烦。--Tim Wu留言) 2020年8月9日 (日) 03:36 (UTC)

希望技術區能幫忙看看問題出在哪[编辑]

想要新增一個「Wikipedia:新聞動態候選/列表」(如果互助客棧提議可行的話)在「進行中的內容評選」模板。但如果這樣打,顯示會異常,如下:

輸入{{#invoke:PatternedCandidateUtils|list|title=Wikipedia:新闻动态候选|pattern====%s*(.-)%s*===|linkprefix=Wikipedia:新闻动态候选#}},顯示出:
香港與美國關係印度快運航空1344號班機空難2019冠状病毒病疫情2020年貝魯特爆炸事故胡安·卡洛斯一世伊爾法安·阿里兵工廠足球俱樂部2019冠状病毒病疫情載人天龍號太空船示範2號巴拉卡核能發電廠2021年香港立法會選舉北斗三号全球卫星导航系统詹尼·因凡蒂諾2019冠状病毒病疫情毅力號火星探測器李登輝

連結沒問題,問題出在錯誤回報區那邊不應該顯示的。--Z7504非常建議必要時多關注評選留言) 2020年7月31日 (五) 05:04 (UTC)

Special:展开模板展开一下就知道了。章节用了转换语法,模块是直接复制章节的代码,转换语法不是合法的内链语法。——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年7月31日 (五) 06:18 (UTC)
但後半段顯示的「錯誤回報區」、「6月23日」就是問題了(錯誤回報區不等同新聞候選吧?),所以就算互助客棧提議最後能實現,技術區也得搞定才行。可惜,暫時不知道問題出在哪。--Z7504非常建議必要時多關注評選留言) 2020年7月31日 (五) 06:22 (UTC)
「6月23日」和其他类似标题是同一级类的。——Sakamotosan路过围观杯弓蛇影| 避免做作,免敬 2020年7月31日 (五) 07:09 (UTC)
雖然顯示沒錯,先感謝了,不過測試連結後,似乎無法直接對應到相對候選提案的地方(比如點選2019冠狀病毒病疫情,希望可以直接跳到2019冠狀病毒病疫情的候選連結部分,而不是顯示新聞動態候選說明部分)?剩下的則是差互助客棧討論結果,這是一定要等幾天的。剛剛測試過,前面兩個候選的有點問題,其他沒問題。是不是跟條目繁簡體字或重定向有關?--Z7504非常建議必要時多關注評選留言) 2020年7月31日 (五) 09:20 (UTC)
(~)補充第一個北斗卫星导航系统我想,應該只是提名人沒有將條目名和主標題一樣吧,第二個連結突然又正常了,日後應該限制提名人提名新聞候選時候得用條目名稱提名。--Z7504非常建議必要時多關注評選留言) 2020年7月31日 (五) 09:49 (UTC)

就了解一下情况[编辑]

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

不行。以“中Eng”測試的結果是:“已禁止使用使用者名稱 "中Eng",以避免混淆或欺騙使用者名稱:包含不兼容的混合文字。 請使用其他使用者名稱。”SANMOSA SPQR 2020年8月9日 (日) 03:19 (UTC)

能幫忙把Template:DC8/talk右上角半保護模板圖示只顯示一個嗎?[编辑]

完成,感謝,問題已修復。--Z7504非常建議必要時多關注評選留言) 2020年8月4日 (二) 13:16 (UTC)

下列討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

如標題,經查發現重複顯示了,可不知道問題出在哪(可能有bug,其它的DC都正常顯示一個半保護模板圖示而已),希望能獲得解決。--Z7504非常建議必要時多關注評選留言) 2020年8月1日 (六) 15:19 (UTC)


本討論已經關閉,請勿修改。如有任何意見,請至合適的討論頁進行,並不要再次編輯本討論。

Tech News: 2020-32[编辑]

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:格式手册#空格,这些情况不应该有空格,但是为了视觉上更加美观,所以来提这个问题。

--Hakuryuu 2020年8月3日 (一) 20:14 (UTC)

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

多個不同頁面的介面訊息以HTML原樣顯示的問題[编辑]

已知Bug,僅於此通知。--Xiplus#Talk 2020年8月4日 (二) 04:08 (UTC)

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

提议利用脚本实现半自动化提报内容评选[编辑]

想问下大家,能不能像这次动员令一样制作一个脚本实现半自动化提报内容评选,省去手动填报模板参数的功夫?--百战天虫留言) 2020年8月5日 (三) 05:06 (UTC)

  • 如果技術上辦的到連主持人都能省下填寫模板參數的時間,那當然(+)支持。不過前提得真的辦的到,討論頁在使用過{{Article history}}後可以一併正確顯示Erha.svg二哈,要不然還是手動填寫比較妥當。--Z7504非常建議必要時多關注評選留言) 2020年8月5日 (三) 05:47 (UTC)
  • 当然(+)支持,不过技术上的问题可不少。--👻Cryberghost 2020年8月6日 (四) 11:23 (UTC)

Technical Wishes: FileExporter and FileImporter become default features on all Wikis[编辑]

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)

維基百科:用戶框/政治團體上方的小圖標出現BUG[编辑]

維基百科:用戶框/政治團體上方的小圖標出現明顯大小不一的情況,我對照了編輯紀錄還是找不出來問題出在哪裡。--Cbls1911留言) 2020年8月6日 (四) 16:30 (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)

請求翻譯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)

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)

(?)疑問:我們該怎麼做,才能不被「gg.sxbb.me」持續侵入ref呢?只能靠偶然發現+手動清理嗎?--Hjh474留言) 2020年8月8日 (六) 11:11 (UTC)

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