维基百科:互助客栈/技术
 |
發表前請先搜索存档，參考舊討論中的内容可節省您的時間。 |
 存檔 |
|---|
|
2005年 12 月 |
- [公告] 中文维基百科第十八次动员令于2020年7月11日至9月13日举行，欢迎参与。
- [請求] 請協助處理字词转换的地区词候选以及修复请求積壓。
- [公告] 進行中的內容評選所有的列表永久半保護、外部連結指引修訂及增设“模板编辑员”权限组已經通過。
- [公告] 進行中的內容評選新增「Wikipedia:新聞動態候選/列表」一欄問題、用户名方针修订、增设小作品化提案及可靠來源指引修訂正在進行公示，如有意見請盡快提出。
- [討論] 技术區正在討論利用脚本实现半自动化提报内容评选，請踴躍參與討論。
- [討論] 条目探讨區正在討論統一所有分類中「橋樑」與「橋梁」之繁體用字問題、Featured picture模板全保護問題、Template:Infobox bilibili personality内小电视成就的图标问题及关於“歌手·当打之年”，請踴躍參與討論。
- [討論] 其他區正在討論第2000個GA紀念問題、香港社群對國安法在香港施行對香港編輯實際影響的關注及为典范条目/特色列表评选新增即时不合标准之规定，請踴躍參與討論。
- [討論] 维基共享资源互助客栈之中文版正在討論建立繁簡與地區詞轉換方針，請踴躍參與討論。
| 發言更新圖例 |
|---|
|
|
|
|
|
| 特殊狀態 |
| 已移動至其他頁面 或完成討論之議題 |
| 手動設定 |
| 當列表出現異常時， 請先檢查設定是否有誤 |
請求增加Icon模板的功能和修改內文[编辑]
Tech News: 2020-31[编辑]
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
- The Starter kit is now available for wiki communities. This page lists technical resources, tools, and recommendations. These are essential to operate a wiki project. This is mostly useful for smaller wikis where the community has limited experience with this. [1]
- The first features of the Desktop Improvements project are available for logged-in users on all wikis. In order to use them, uncheck 使用旧版Vector皮肤 in your local or global preferences in section 皮肤偏好. More improvements are planned. Feedback is welcome.
On multiple wikis, a UTCLiveClock gadget is available. For wikis that import the gadget directly from mediawiki.org, end users can now choose a different timezone to show instead of UTC.
On multiple wikis, a UTCLiveClock gadget is available. For wikis that import the gadget Problems
- The deployment train for MediaWiki has been blocked this week. [2][3]
- Translation Notification Bot was sending the same message multiple times to every translator. This has been fixed. [4]
- Some users were receiving the same notification multiple times. This has been fixed. [5]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from July 28. It will be on non-Wikipedia wikis and some Wikipedias from July 29. It will be on all wikis from JUly 30 (calendar).
The Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
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)
- 话说，谁知道正常的新皮肤是什么样子？看了mw:Reading/Web/Desktop Improvements，怀疑中文版的是不是不正常？正常情况下右边有大片空白吗？--百無一用是書生 (☎) 2020年7月28日 (二) 00:50 (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)
- (※)注意：我用翻譯工具沒甚麼問題，反而我最近也遇到另一些問題，但不是翻譯器，而是基本的編輯也出現問題，輸入的字形符號都變成亂碼，一定要從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)
- @Winter Moment：因為有人惡意破壞，覆蓋整個頁面。已警告相關用戶此舉已造成其他用戶困擾。若再次發生相關問題，請回報至WP:VIP。-- 娜娜奇🐰楓香花茶☕（宇帆·☎️·☘️） 2020年7月30日 (四) 18:11 (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)
- 不知問題出在哪[為何？]，我看問題很明顯欸，你看你語法「pattern====%s*(.-)%s*===」明顯是匹配 ===文字=== 所以當然「錯誤回報區」、「6月23日」都會被列入啊 = = ，換一個匹配語法或更改標題級數就能解決問題。— 娜娜奇🐰楓香花茶☕（宇帆·☎️·☘️） 2020年7月31日 (五) 07:32 (UTC)
- 把 「===文字===」 改成匹配 「article=文字」效果如下
- 香港與美國關係－印度快運航空1344號班機空難－2019冠状病毒病疫情－2020年貝魯特爆炸事故－胡安·卡洛斯一世－伊爾法安·阿里－[[:Wikipedia:新闻动态候选#|]]－2019冠状病毒病疫情－載人天龍號太空船示範2號－巴拉卡核能發電廠－2021年香港立法會選舉－北斗卫星导航系统－詹尼·因凡蒂諾－2019冠状病毒病疫情－毅力號火星探測器－李登輝
- 不過若下方討論區有人寫「Blabla article = 我是BUG，你的List失效吧 --~~~~」就會出事。-- 娜娜奇🐰楓香花茶☕（宇帆·☎️·☘️） 2020年7月31日 (五) 07:52 (UTC)
- 把 「===文字===」 改成匹配 「article=文字」效果如下
- 但後半段顯示的「錯誤回報區」、「6月23日」就是問題了（錯誤回報區不等同新聞候選吧？），所以就算互助客棧提議最後能實現，技術區也得搞定才行。可惜，暫時不知道問題出在哪。--Z7504非常建議必要時多關注評選（留言） 2020年7月31日 (五) 06:22 (UTC)
就了解一下情况[编辑]
新用户不能用户名中英混合？--Herobrine 303🍀留名 疫情尚未结束，切勿放松警惕!🦠 2020年8月1日 (六) 03:57 (UTC)
- 不行。以“中Eng”測試的結果是：“已禁止使用使用者名稱 "中Eng"，以避免混淆或欺騙使用者名稱：包含不兼容的混合文字。 請使用其他使用者名稱。”SANMOSA SPQR 2020年8月9日 (日) 03:19 (UTC)
能幫忙把Template:DC8/talk右上角半保護模板圖示只顯示一個嗎？[编辑]
完成，感謝，問題已修復。--- 下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。
如標題，經查發現重複顯示了，可不知道問題出在哪（可能有bug，其它的DC都正常顯示一個半保護模板圖示而已），希望能獲得解決。--Z7504非常建議必要時多關注評選（留言） 2020年8月1日 (六) 15:19 (UTC)
- 本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。
Tech News: 2020-32[编辑]
維基媒體技術社群现發出最新技術新聞。請告知其他用戶以下變更。當然，未必所有變更都會影響閣下。有提供其他語言的翻譯版本。
问题
- 在7月23日星期四的17:50至17:59 UTC之间，Wikidata Query Service的所有查询都失敗了，有些查询在更長的时间段上失敗。 [6]
- 在过去的几周，跨语言链接的順序錯誤，此問題已在兩週前的技術新聞中提到，现已修复。 [7]
- 全局偏好設定的「使用旧版Vector皮肤」选项目前有问题，开发人員正在進行修复。 [8]
- 在維基共享資源上，Wikibase擴充功能中的一個錯誤導致「移動」和「建立」保護類型在主要（Gallery）命名空間中被停用，無法設定新的保護，現存的保護也無法作用，導致允許了某些原本不應被允許的頁面移動和建立。現已修復。 [9]
本週後期變更
- 影片播放器將變得更簡單、更現代，目前的測試版功能將在本週成為維基百科以外的維基上所有人使用的影片播放器，舊版播放器將移除。 [10]
- 使用者的
global.js和global.css頁面即將也在移動版網站上載入，您可以閱讀說明文件來了解如何避免將樣式套用到移動版外觀上。 [11] - MonoBook外觀上的
searchGoButton識別字現在改為searchButton，這會影響CSS和JS小工具，可以在T255953上找到遷移說明。這個更改曾在第27期新聞中提到過。 - 機器人操作者可以使用Pywikibot來定時存檔討論，為了防止存檔過大而由機器人使用的
counter變數行為被修改。 [12] - 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)
多個不同頁面的介面訊息以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}}後可以一併正確顯示
二哈，要不然還是手動填寫比較妥當。--Z7504非常建議必要時多關注評選（留言） 2020年8月5日 (三) 05:47 (UTC) - 当然(＋)支持，不过技术上的问题可不少。--👻Cryberghost 2020年8月6日 (四) 11:23 (UTC)
- @Cryberghost：比如说？--百战天虫（留言） 2020年8月7日 (五) 16:53 (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)
維基百科:用戶框/政治團體上方的小圖標出現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...，所以還是想請熟悉翻譯模板的幫忙。－
gg.sxbb.me[编辑]
(？)疑問：某編者的這個編輯、這個編輯、這個編輯、這個編輯，將ref中books.google.com網址冠上gg.sxbb.me，他說是視覺化編輯自動帶入的，請問這是正常的嗎？--Hjh474（留言） 2020年8月7日 (五) 10:57 (UTC)
说几句重话。使用第三方反向代理编辑而不仅仅是阅读，这件事情从一开始就是错的。无论是直接访问，还是使用诸如VPN，TOR之类的工具间接访问本站，wmf服务器的运作方式，以及所涉及的协议（HTTPS，TOR等等）保证了在成功的情况下，你所接收到的内容是绝对完整与正确的。但是第三方反向代理不同，它根本就在最底层就把https请求和/或响应给拆开了，它可以对收到的数据作任意修改，再转发给使用这些反向代理的用户，而在用户一端，是没有机制去保证他/她所获取的内容确实是wmf的服务器想发给他/她的——这内容可不仅限于页面内容，也可以是js脚本——也自然没有机制去保证第三方没有窃取相应信息。
纵观本站使用被某些编者使用得比较频繁、允许编辑的第三方反向代理，其中有多少在技术上可以做到与wmf提供同等的安全性？那些使用源自中国大陆的VPS提供者来搭建的第三方反向代理，能否从根本上避免为响应北京政府的执法请求，而造成用户隐私数据泄露的问题？对wmf而言，隐私权的重要性自然是不言而喻的，这也是其激进地推行HSTS的其中一个原因。这些站点中，有些居然连单独的TOU或介绍隐私权政策的页面都没有，却在另一方面暗示编者可以透过申请WP:IPBE加以编辑——从技术上说，有了IPBE，即使再严厉的IP封禁也奈何不了使用如此站点加以编辑的编者；然而这种在技术上可行的行为，又是否与wmf保护用户隐私权的精神相符呢？本人持强烈的保留意见。
最后谈谈技术问题。第三方反向代理为了改善用户体验，会对链接甚至文本中的链接进行一定程度的重写，将其改为指向反向代理的链接。这正是造成上述问题的根源。是否可能对反向代理的规则进行优化，以保证浏览的时候不替换，编辑的时候替换，给用户提供完全等同于原站的编辑体验呢？答案当然是否定的。想象一下如下的两个场景：
- 某脚本利用本站的解析器提供的html内容配上更好的排版方式，来改善读者的浏览体验。
- 某脚本利用本站的解析器提供的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)
- --安忆Talk 2020年8月8日 (六) 05:14 (UTC)
- 感謝資訊分享，頗有收穫。若如此，編者提交編輯前是不是應該檢查與清理？強迫（點選ref的）讀者連上gg.sxbb.me，似乎不太好，編者雖無惡意，但是反代站如此替換似乎並非善意。--Hjh474（留言） 2020年8月8日 (六) 06:00 (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，那是主域名。其用来反代的域名是这个，是香港阿里云。
- 至于您提到的两个功能性方面的问题，您不要忘了，使用者是人，而不是机器。可以把选择发给前端让用户自己选择。
(？)疑問：我們該怎麼做，才能不被「gg.sxbb.me」持續侵入ref呢？只能靠偶然發現+手動清理嗎？--Hjh474（留言） 2020年8月8日 (六) 11:11 (UTC)