維基百科:互助客棧/其他/存檔/2024年3月

對新用戶禁用內容翻譯工具

原標題為：Disable Content Translation from brand new users

已通過：

請等待部署，同時請移步後續的討論。MilkyDefer 2023年10月28日 (六) 15:08 (UTC)

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

---

Morning,

Patrolled around some new pages and played with translation tools for a while, I believed nearly all contents introduced by Content Translation from new users are generally horrible machine translation, some of them are even in bad faith. I suggest disabling this feature from newcomers and limit it only for wikipedia:EXTENDEDCONFIRMED. Here are some examples:

1. 鯨類智力
2. 奧斯朋效應
3. 更新世野化
4. 新宿 尼亞加拉瀑布
5. 醫學藥學大學，河內國家大學
6. 詹姆士·赫伯恩
7. 宇都宮聰 -- bad faith translation (attack page)

P.S. I'd checked them one by one, by putting them in Content Translation tool using different translation engines again.--Lemonaka（留言） 2023年10月17日 (二) 12:31 (UTC)

@Ericliu1912 Lemonaka（留言） 2023年10月17日 (二) 12:32 (UTC)

幫當事人翻譯一下：

他實際巡查條目並上手試驗內容翻譯工具，認為幾乎所有新手使用該工具所產出的作品品質都很惡劣，到能直接以G13準則快速刪除的地步，甚至可能有惡意誤譯者。他認為應該對新手預設禁用內容翻譯工具，只允許達到延伸確認使用者資格的編者使用。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2023年10月17日 (二) 12:36 (UTC)

是我錯覺還是以上文字也是機翻出來的--Iridium(IX) 2023年10月17日 (二) 13:50 (UTC)

十分同意，至少可以減少一下巡查員的壓力，但個人認為自動確認已經夠了。--Hoben7599—論 | 支持立場新聞 2023年10月17日 (二) 13:55 (UTC)

他說得對。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年10月17日 (二) 13:49 (UTC)

偶然遇過一些編輯使用這個工具進行翻譯（也就是編輯會被標籤為「內容翻譯」），經常出現格式不合要求（例如：半角標點（包括逗號、結尾點句號、雙引號、圓括號，甚至有些前面還有半角空格），作品名斜體，數字前後不必要的空格（例如日期、數量詞前））、文句不順暢的疑似機器翻譯未修正、不和本地用語慣例（常見的「也可以看看」）的情況。最近我見過例子有（User:Orrt0000 ）的火焰噴射戰車（偶然抽出看到）、機動防護火力車（提醒過，我可能修改過？），失敗不是一個選項（oldid=79396409），Three（oldid=79314028，之後有修葺，但還不足夠（oldid=79323303））。這非常依賴新頁面巡查的巡視、修葺和指導，但考慮到新頁面巡查現在活躍強度……我甚至覺得有沒必要將新建頁面的級別也拉高一級。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年10月17日 (二) 14:07 (UTC)

這個嘛，上次提出要將新建頁面提昇到自確以上的提案最後以修改A5為G18做收，短期內應該不太可能發生，況且AFC草稿積壓也確實嚴重。--冥王歐西里斯（留言） 2023年10月18日 (三) 03:59 (UTC)

AFC草稿積壓嚴重的話，那新建頁面還是維持不變，允許任何人新建條目，不然就沒多少新條目了。其實一眼看出就要刪除的條目刪的還是挺快的。--日期20220626（留言） 2023年10月18日 (三) 04:15 (UTC)

這東西嘛，雞肋，老人有能力用wikicode從零直接起手，知道大部分格式方針規則，用沙盒（用戶子頁、草稿空間）打底後再轉正，新手用這個工具問題不少。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年10月17日 (二) 14:11 (UTC)

自動確認就足以了，不需要到延伸確認，都延伸確認了可能就不需要用了。--桐生ここ★[討論] 2023年10月17日 (二) 15:18 (UTC)

@Lemonaka: I wish to hear your personal stance. It is acceptable if we restrict the use of translation providers to extended-confirmed users, but leave the standard translate interface accessible for everyone? That essentially means that inexperienced users are forced to translate fron scratch using the standard translation interface (that are also featured in Crowdin, Transifex, etc.), while experienced users have additional access to machine translation providers as a starting point? MilkyDefer 2023年10月17日 (二) 16:03 (UTC)

@MilkyDefer Thanks for your comment.
Oh, that's from my experience on English project. Content Translation interface is strictly limited to extended confirmed user there. But even they are not allowed to use translation providers, meaning machine translation providers are totally disabled.
However, maybe we need some adjustments for Chinese Wikipedia, where I'm not familiar with rules and policies.
TLDR: On the English Wikipedia this tool is limited to extended confirmed editors, and the machine translation component is disabled for all users. Lemonaka（留言） 2023年10月17日 (二) 16:15 (UTC)

一點簡單的澄清。內容翻譯工具和機器翻譯是兩回事。

• 內容翻譯功能提供原文和你的譯文草稿的兩欄對照界面。
• 你的譯文草稿可以從零開始手寫，也可以讓機器翻譯頂上。

	內容翻譯功能	在內容翻譯功能內使用機器翻譯
英維	僅限EC、管理員	完全禁用
德維	所有人	完全禁用
日維	所有人	完全禁用
其他大wiki	所有人	所有人
中維現狀	所有人	所有人
你想要的中維	？	？

仔細看了一下可用的配置，內容翻譯功能可以依照權限啟用，機器翻譯就只有true/false選擇。 --MilkyDefer 2023年10月17日 (二) 16:38 (UTC)

AC, EC and sysop only for the first blank per above discussion, no obvious consensus for the second blank. Just from my perspective, it should be disable. Lemonaka（留言） 2023年10月17日 (二) 16:53 (UTC)

zh: 反正我是在全域停用了CX並且用global.css屏蔽了所有與之相關的element，誰愛用用去。中維的話，至少機翻功能不應該給新手吧？那就沒啥好說的咯。

en: Well, I disabled CX globally and used global.css to block every element associated with it. Whoever like to use it, go ahead. As for zhwiki, I guess at least machine translation tools shouldn't be provided to the new users? Then that left us with few choices.  ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2023年10月17日 (二) 17:08 (UTC)

不知道能否跟開發者提要求，讓機器翻譯可以根據權限啟用。

個人認為內容翻譯對於新手友好，應該對所有人啟用；機器翻譯應該需要權限，但不一定就要禁用。

一般來說中文維基百科需要翻譯其他語言的維基百科，而English Wikipedia不需要翻譯，因為一般都是英文翻譯到其他語言。--桐生ここ★[討論] 2023年10月17日 (二) 18:29 (UTC)

(＋)支持 ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2023年10月18日 (三) 02:01 (UTC)

建議將內容翻譯改為至少自確才能開啟（延確也不反對），至於機器翻譯如果目前只能開或關的話，那麼建議先關掉這個功能。--冥王歐西里斯（留言） 2023年10月18日 (三) 04:02 (UTC)

我覺得禁用機器翻譯沒啥問題，至少我留意到的兩個問題（文段不順、慣用詞）可能是機器翻譯導致的。至於標點和格式，是來自機器翻譯還是內容翻譯系統不適配的問題不確定，裡面這些問題的根本實際是來源於「是英文文法的語法」，這種基礎問題連內容翻譯都沒有解決，這樣將新手的下限拉得太低了。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年10月18日 (三) 00:14 (UTC)

內容翻譯提升到自確暫時沒意見。機器翻譯關掉我會反對（雖然我最近不怎麼翻譯了），如果是技術手段來限制使用則可以，比如編輯次數<500時禁用，或者類似WP:AWB批准制，如何實現尚未研究。猜測是新頁面巡查積壓、新用戶多導致問題更明顯。另外，強制該工具創建的頁面不在條目空間，我覺得會挺好的，因為創建的頁面肯定需要二次修訂來保質量。--YFdyh000（留言） 2023年10月18日 (三) 10:53 (UTC)

就是不知能否技術上強行實現「禁止直接發佈在條目空間」。--日期20220626（留言） 2023年10月18日 (三) 11:02 (UTC)

不了解擴展是否有選項，全局JS能做到，自動檢測和追加標題前綴。問題是發布流程怎麼做，WP:AFC還是允許自行或請求移動，移動後的巡查。--YFdyh000（留言） 2023年10月18日 (三) 11:20 (UTC)

Definitely and a no-brainer yes, but you need to write an AF for specific tags or edit summary. Lemonaka（留言） 2023年10月18日 (三) 13:14 (UTC)

過濾器可以做到。--桐生ここ★[討論] 2023年10月18日 (三) 17:35 (UTC)

不確定內容翻譯頁面是否能顯示過濾器的警告文本，能則還可以，否則體驗糟糕。建議配一個全局JS來實現自動，高概率撞過濾器不太合適。--YFdyh000（留言） 2023年10月18日 (三) 17:42 (UTC)

既然是機械翻譯品質欠佳，以及機械翻譯衍生的格式不當等的問題，關掉機械翻譯功能即可。如果關掉機械翻譯後，新用戶透過內容翻譯發表的條目，相比其他不使用此工具翻譯的條目，存在更多問題以及被刪除和掛模板的比率更高，那到時可考慮禁止新用戶使用。謝謝。--SCP-0000（留言） 2023年10月18日 (三) 16:46 (UTC)

畢竟真的想使用機械翻譯的話，不用內容翻譯也可以達到。我是覺得禁止直接發佈到條目空間最好，而且有新用戶也不見得懂得如何從個人用戶頁移動到條目空間。等到他懂得如何移動了，說明他對維基的編輯有了一定的了解。--日期20220626（留言） 2023年10月18日 (三) 22:36 (UTC)

不太理解為何需要禁止直接發佈到條目空間（在已禁止機械翻譯功能的前提下）。再者，此舉便相令新手創建條目的阻礙增加（相比不透過內容翻譯），那倒不如直接禁止新手使用內容翻譯。另一方面，無論是禁用機械翻譯功能還是整個內容翻譯工具，至少指出為何需要這樣做，不然也難以說服 WMF 關掉它。謝謝。--SCP-0000（留言） 2023年10月19日 (四) 18:06 (UTC)

因為新手提交後可能很快就不管了，外人介入和處理都會很麻煩（如編輯衝突、提存廢不友善），等新手自己摸索完善草稿再提交會更好。而且這工具提交的源代碼常有大大小小的不足，哪怕老手操作，也需要二次編輯源碼來整好，完成前其他人看到的版本可能是不成熟未完工的。--YFdyh000（留言） 2023年10月19日 (四) 22:25 (UTC)

這玩意純屬垃圾，我之前用過，覺得手感真是莫名其妙，而且翻譯出來的參考文獻、配圖之類的錯誤一大堆。暑假還想給它第二次機會，去用它翻譯了美洲麻鳽，結果體驗實在太差，直接丟用戶空間開始手動翻譯。而且直接引導新手翻譯FA/GA簡直是反人類，這些條目動輒數萬字節，一般還有各式從句等翻譯難度較高的英語語法。綜上，我認為內容翻譯應該被徹底掃入歷史的垃圾堆。——Aggie Dewadipper 2023年10月19日 (四) 08:12 (UTC)

支持至少禁用新手使用該機械翻譯（若能限制到延確以上會更好），這翻譯出來的真的不是人讀的，而且還會出現一些不存在的模板跟不合格式手冊的內容出來。且就像前面所說，會使用這種工具的可能會翻譯完就不管條目情況了，無疑增加巡查跟刪除上的負擔。寧願先堆積在草稿慢慢消化。--WiTo^Talk 2023年10月20日 (五) 09:10 (UTC)

@魔琴 @MilkyDefer @Ericliu1912, so who's going to create a phab ticket? Lemonaka（留言） 2023年10月21日 (六) 14:52 (UTC)

We might need to put the consensus onto the bulletin board first. That is the procedure.--MilkyDefer 2023年10月21日 (六) 14:59 (UTC)

參加討論的人全數同意關閉（或者至少限制）內容翻譯工具內建的機器翻譯功能。在此 公示7日：

• 如果phabricator認為將內建的機器翻譯功能依照權限限制在技術上是可以實現的，則優先將該功能限制在EC及以上使用者才能使用；
• 如果上述限制在技術上不能實現，則完全關閉該功能。

--MilkyDefer 2023年10月21日 (六) 15:02 (UTC)

之前部署過一個按權限來限制publish的patch，實際情況是這個功能是不起作用的，而且Language Team並不是很喜歡進行如此的限制。 Stang^★ 2023年10月21日 (六) 16:14 (UTC)

那麼，先在p站問一下？ ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2023年10月21日 (六) 16:53 (UTC)

或者先請求一下zhwiki的數據，輔助更好的決策。-- ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2023年10月21日 (六) 17:00 (UTC)

過往也有受理相似請求 1 2 3，並非完全拒絕之。只是社群需要清晰說明為何需要這樣做，附上相關例子及數據（如可能），而非僅是「我覺得/不覺得」。謝謝。--SCP-0000（留言） 2023年10月21日 (六) 20:18 (UTC)

要不要在其他地方也公示一下？要知道看互助客棧-其他板塊的人並不多，免得到時候有人突然來問機器翻譯怎麼沒法用了。--日期20220626（留言） 2023年10月21日 (六) 16:32 (UTC)

放上公告了。--Hoben7599—論 | 支持立場新聞 2023年10月21日 (六) 17:04 (UTC)

贊同此公示。--桐生ここ★[討論] 2023年10月22日 (日) 14:32 (UTC)

我補充意見。如果phabricator拒絕了部署按用戶組限制，但本地有能力JS實現限制，依情況和後續共識實施，而非phab部署/完全關閉的二選一。如果得出共識和界管配合，不phab也可以，已知能限制和友好提示為什麼不能用。--YFdyh000（留言） 2023年10月28日 (六) 03:19 (UTC)

我的意見是，其一：很容易繞過去，有時候甚至網絡連接不是很好就能繞過去了（比如在查明自動登出問題起因之前的臨時規避措施）；其二：增加網頁加載的難度。--MilkyDefer 2023年10月28日 (六) 06:00 (UTC)

---

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

後續工作

於Phabricator查看
編號T349959的工單

這個章節用來探討後續的工作，包括回應Phabricator提出的問題，以及與受到影響的使用者之間的溝通事項。 --MilkyDefer 2023年10月28日 (六) 15:12 (UTC)

(：)回應 接上方討論與表明立場。如果在MediaWiki:Common.js或全局小工具里，不會很容易繞過（以及檢測完全可加強。目前未出現持續對抗風險），也不會增加網頁負擔。考慮過技術性繞過與傳播，但這對阻止一般新用戶已足夠，適合靈活部署，而技術性濫用有更多做法和挑戰，如AI翻譯。以及，或許能用JS和濫用過濾器做出相關標記。(＊)提醒 上方Hoben7599、桐生等認為自確足夠，而冥王歐西里斯認為自確也可，所以請注意符合共識，phab請求的描述在我看來不完全準確。--YFdyh000（留言） 2023年10月28日 (六) 17:56 (UTC)

我直接跟你說吧，你那個所謂的js方案，這是技術上不可能的。理由是翻譯工具的運作機理。在翻譯界面中，你先點擊新建段落翻譯的按鈕，然後系統默認提供了機器翻譯的結果，之後你才有機會選擇這一段是使用機器翻譯還是其他的。也就是說，如果不在phab的層面限制住，你所謂的js限制只會發生在機器翻譯已經被提供了的既成現實之後，所謂的限制將毫無意義。--MilkyDefer 2023年10月29日 (日) 03:00 (UTC)

並非如此，我試過可運作，新建和編輯段落時工具不會再提供機器翻譯的選項與請求，請再試試。--YFdyh000（留言） 2023年10月29日 (日) 15:45 (UTC)

當前使用機器翻譯的體驗

我復現不了你所謂的嘗試。我錄製了影片來證明我的說法。--MilkyDefer 2023年10月30日 (一) 05:34 (UTC)

對Phabricator的回應

以下是Pginer-WMF的回應。

As a reference, in the last 3 months on Chinese Wikipedia: 27% of the translations were published by users with an edit count below 100, and 73% by users with an edit count of 100 or more.

Currently, we could limit the access for publishing into the main namespace. However, machine translation cannot be restricted to specific groups.

Disabling machine translation to all users will impact negatively those making a good use of the tool. Even if the limit system is not perfect for Chinese, it may be preferred to increase the translation limits. That is, having machine translation with the requirement to modify it heavily (even if it requires rewriting some parts that were already correct, rather than having always to start from scratch.

An immediate measure we can take in the direction of reducing access to machine translation could be to: make machine translation as optional, and increase the translation limits.

---

作為參考，在過去的3個月中文維基百科發布的翻譯文章當中，27%的文章由編輯次數少於100次的使用者發布，73%的文章由編輯次數至少為100次的編者發布。

目前，我們可以做的事情是阻止使用者將翻譯的文章發布到主命名空間。但是，無法將機械翻譯功能限定為特定用戶組才能使用。

為所有使用者關閉機械翻譯會對正當使用該工具的使用者產生不利影響。就算對於中文，（原文保留百分比）限制系統並不完美，我依然建議抬高（原文保留百分比）限制。換句話說，保留機械翻譯，但是要求翻譯者做出極大量的修改。有的時候機械翻譯的內容是正確的，該要求依然要求他們重新撰寫本就是正確的內容，但是總比從原文開始要好。

如果要限制機械翻譯的使用，我們當前立刻能採取的措施是將機械翻譯設定為可選項，然後抬高原文保留百分比的限制。

@Lemonaka、Ericliu1912、SIridiuM28、Hoben7599、Cwek、S8321414、日期20220626、桐生ここ、魔琴、YFdyh000、SCP-2000、Dewadipper、Stang：以上是Phabricator的初步回應，大體方向依然是推薦調整發布閾值。我認為這個論點應該可以被反駁。 --MilkyDefer 2023年11月28日 (二) 12:30 (UTC)

從邏輯上的思路來講，Pginer的核心論點是限制機械翻譯弊大於利。主要理由是R1：「會對善意的使用者帶去不便」。R1這個理由蘊含的基礎是A1：「中文維基百科有數量可觀的會正確使用機器翻譯的使用者」。用於佐證A1成立的證據是E1：「有73%的翻譯由編輯數量達到100次的編者做出」。

因此，我初步的想法是證明，C2：「達到100次編輯與他們懂得如何正確使用機械翻譯無關」，為此需要大家確認，Q2：「大於100次編輯、且在使用機械翻譯功能的編者的人數，是否也佔了總使用者人數的7成？」，以及Q3：「達到100次編輯的編者做出的機械翻譯當中，是否大部分的翻譯作品的品質令人滿意？」

另外，針對抬高發布閾值的建議，我個人是認為站不住腳的，因為就算我把所有文字都改了個遍，系統依然提示我由99%的文字雷同。這個閾值機制在中維基本徹底是壞掉的。

大家還有什麼別的論點嗎？--MilkyDefer 2023年11月28日 (二) 12:38 (UTC)

可選項+阻止使用者將翻譯的文章發布到主命名空間+調整發布閾值能不能同時實現？還有可選項的話是什麼意思，是默認不開啟，要用戶手動開啟？--日期20220626（留言） 2023年11月28日 (二) 12:39 (UTC)

諮詢得到的「可選」的解釋：

• 現狀：點擊要翻譯的段落後，在右側的譯文一欄中顯示了使用Google翻譯後的段落，並提供一個下拉菜單供你選擇換成別的翻譯源，或者拷貝原文，或者從空段落開始。
• 變成可選後：點擊要翻譯的段落後，在右側的譯文一欄中顯示了拷貝後的原文，並提供一個下拉菜單供你選擇換成機器翻譯的結果，或者從空段落開始。

我應該說得比較清楚了。--MilkyDefer 2023年11月28日 (二) 17:58 (UTC)

順便讓下面那個問卷調查的發起人@Hanxuan Sun知道一下這件事。--MilkyDefer 2023年11月28日 (二) 12:41 (UTC)

如果禁掉機器翻譯的話，對於修改內鏈不方便，複製原文模式下內鏈是[[中文|xxx]]，xxx對應的是英文原文。--日期20220626（留言） 2023年11月28日 (二) 12:46 (UTC)

基本上同意Pginer的解決方案：

1. 阻止使用者將翻譯的文章發布到主命名空間
2. 機械翻譯設定為可選項
3. 抬高原文保留百分比的限制（前提是此機制正常運作）

--桐生ここ★[討論] 2023年11月28日 (二) 13:08 (UTC)

@桐生ここ： 正如個人下方留言指出「抬高原文保留百分比的限制」做法並不可行，不知您是否還同意僅「阻止發布到主命名空間」以及「機械翻譯設定為可選項」已屬足夠，還是有其他想法？謝謝。--SCP-0000（留言） 2023年12月6日 (三) 17:34 (UTC)

基本上同意「阻止發布到主命名空間」以及「機械翻譯設定為可選項」已屬足夠。阻止發布到主命名空間基本上可以擋掉只想按按鈕就建立條目的新手，如果把翻譯品質爛的草稿移動到條目，就是用戶的問題不是功能的問題了。桐生ここ★[討論] 2023年12月6日 (三) 17:55 (UTC)

現在本站的閾值已是 95%。翻查 2020 年時的工單，曾有未修改百分比達 93% 之草稿（fyi 當時客棧相關討論）被當時閾值為 70% 的系統阻擋。考慮到相關限制之演算法未有任何改進，個人認為現時再出現類近誤判的機率並不低。謝謝。--SCP-0000（留言） 2023年11月28日 (二) 14:03 (UTC)

就是說，你能不能把話說清楚一點。我沒讀懂。

當時的設定是未修訂內容高於70%會被阻擋。所以曾有93%未修改的草稿被阻擋…………應該是合理的才對？--MilkyDefer 2023年11月28日 (二) 14:52 (UTC)

大腦一時不清醒，不好意思（

Anyway，個人的意思是：如果依照 Pginer 的方案，由現在的 95% 未修改內容閾值調低至 90% 或更低，可能出現類似過往 93% 未修改且「翻譯質素正常」的草稿被阻擋之誤判問題。

當然，或許有人考慮調至 93% 便可解決問題，然而其實只差了 2% ，無論是防誤判或防機翻而言作用也不大。謝謝。--SCP-0000（留言） 2023年11月28日 (二) 15:21 (UTC)

95%未修改的機器翻譯文就能發佈？是不是應該調到更低一些？--日期20220626（留言） 2023年11月28日 (二) 15:27 (UTC)

調低就可能出現誤判。以前曾調至 70% ，但後來因誤判（就是上方留言提到的誤判）而改回了。--SCP-0000（留言） 2023年11月28日 (二) 15:33 (UTC)

有時候譯出來和機翻的差不多也是正常的，應該。我記得我之前有被攔過。 ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2023年11月29日 (三) 00:07 (UTC)

( ✓ )同意，以前常遇到這種狀況......--${\ce {Be + He->B+ +e- +H- +e+}}$，這是β衰變和正電子發射，請無視其他能量釋放。 2023年12月10日 (日) 15:11 (UTC)

@MilkyDefer Three points.

Disabling machine translation to all users will impact negatively those making a good use of the tool

Nearly all translations from new users, even some established users are terrible, without revised, and useless for this project, even in draft space.

That is, having machine translation with the requirement to modify it heavily

Per discussion above, the risk of false positive is high. I've tested with the tool for a while, the problem is after you click something for machine translation, even then you remove that paragraph, the tool will sometimes refer it as a 100% similarity, what the hell is that?

make machine translation as optional

Optional? Optional equals encouragement, if it is so convenient for new users to publish an article.
My opinion is always the same, completely disable or completely enable, and if WMF refuses to completely disable this tool, I will support completely leaving it alone. Lemonaka（留言） 2023年11月28日 (二) 21:24 (UTC)

機器翻譯的文字本來就要核對原文修改以及按照漢語的習慣改寫。--日期20220626（留言） 2023年11月29日 (三) 00:11 (UTC)

可選已經是給使用機器翻譯增加阻礙，另外可以禁止將內容翻譯生成的條目發佈到條目主空間。增加阻礙已經可以篩掉一批人了。沒必要一刀切。--日期20220626（留言） 2023年11月29日 (三) 00:15 (UTC)

如果基金會工作人員的論點是這樣，那麼我覺得也可以按他講的限制讓使用機器翻譯的使用者不能直接發佈到條目空間（但我還是更傾向完全停用機器翻譯功能就是，如果不能限制成特定使用者群組才能使用的話）。--冥王歐西里斯（留言） 2023年11月30日 (四) 08:28 (UTC)

@Lemonaka： Looks like there is an overwhelming support to WMF's alternate proposal. There is undoubtfully a concensus that the machine translation problem is terrible and pervasive and we need to action, but there is not enough concensus to go so far as to the very opposite. If my memory serves right, every wiki either "uses machine translation as default and allows publishing articles directly to main namespace", or "completely disallows machine translation at all". Such middle-ground is unprecedented, and there is no data to support some of your claims or speculations such as "optional equals encouragement". I believe it is worth a try, and if the situation does not get any better, you will have more powerful and persuasive evidence to support your idea. Does that sound acceptable to you? MilkyDefer 2023年12月9日 (六) 06:15 (UTC)

Sounds sensible. Since it has been stuck for nearly two months with no consensus, let's pass this proposal.@MilkyDefer -Lemonaka 2024年2月24日 (六) 05:23 (UTC)

已經向 wmf 詢問進展了。--SCP-0000（留言） 2024年2月24日 (六) 07:07 (UTC)

@SCP-2000 Got an idea, do you have their email addresses? Bit annoyed for such delay. -‎Lemonaka‎ 2024年3月1日 (五) 08:32 (UTC)

@Lemonaka: I sent an email on Saturday last week. I suppose they are working on other things at the moment and it is not an urgent request, so they haven't replied yet. If they haven't replied by next week, I may send another email to remind them.

You can find their email on their user page. This page also mention how to contact them (language team). Thanks.--SCP-0000（留言） 2024年3月1日 (五) 08:55 (UTC)

好像沒什麼進展？—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年1月29日 (一) 17:06 (UTC)

可否明示所謂破壞者常用詞彙究竟是哪些詞彙？

我也不想去碰，但要告訴我是什麼禁詞不能碰吧？寫個黑道電影劇情還會有什麼破壞者常用詞彙？這真是從何說起。不要用自動過濾來羞辱人類大腦好嗎？知道沒註冊的人一時興起加點內容有多煩嗎？一定要這樣是不是？然後新增議題還會碰上編輯衝突？不把人氣死不甘心是不是？--2603:8000:500:FB00:E1BC:C954:E9E3:7D18（留言） 2024年3月6日 (三) 03:55 (UTC)

不好意思，這種東西正是因爲不公開，才會有效。--MilkyDefer 2024年3月6日 (三) 04:53 (UTC)

不敢說，可不敢說，非常不敢說。Sanmosa _{Šče ne wmerla Ukrajina, ale ne Wže woskresla Ukrajina} 2024年3月6日 (三) 08:08 (UTC)

可以嘗試分開多次提交編輯。需注意劇情只是用於了解故事主軸，輔助讀者了解現實向的內容，而不是像數據庫般將所有出現的內容記下。可以參見Wikipedia:如何編寫故事簡介--及時雨 ^留言 2024年3月6日 (三) 08:36 (UTC)

感覺之前見過類似的問題，好像是條目名稱和標題黑名單的項目匹配上而觸發的。不過提問題或者請求解決問題時，至少舉個例子，好讓別人幫忙看看具體問題。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年3月6日 (三) 12:09 (UTC)

不，就這一次個例而言，是非常尷尬的情況。就跟「二十四口交換機」一樣尷尬。--MilkyDefer 2024年3月6日 (三) 12:50 (UTC)

這個過濾器是不是只對非自動確認用戶有效，如果只是無奈的誤觸發的話，或者看一下內容是否存在實質性的破壞，沒有的話就代為編輯算了。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年3月7日 (四) 01:15 (UTC)

為什麼不能公開？這東西存在的目的是要避免特定的詞彙，還是要避免詞彙背後的概念，所以同義詞也不准用，繞著講也不准，陰陽怪氣正話反說也不准？來，請跟我唸一次：維基百科，自由的百科全書。

真不能講，那可不可以提示一下，是因為政治，還是歧視，還是色情，還是因為某個有權添加敏感詞的人就是看那個詞不爽？至少讓人知道要截掉哪個部份。

那一堆劇情也不是我一開始就加的。我是看到那一堆劇情既囉嗦又錯置重點，想趁剛看完電影的餘熱貢獻一點熱情。非常感謝建議將一片熱情切段釋出，希望有如此高見的高人遇上幾次切段的時機。如果這麼喜歡作之君作之親作之師的教人需注意什麼，麻煩去建議一下先前把劇情搞成那樣的註冊者。我只是沒註冊，不是文筆只到那種程度，若由我從零開始編寫故事簡介，不會是那樣子的。因為已有現有的東西在，為求禮貌，我沒有全部推倒重來，而是儘量縮小修改的部份。希望經驗豐富的編輯們，文字上的禮貌不要不及我這個未註冊。

以上只是展現一下我喜歡把話繞著講，所以講出敏感詞的機會不多。但故事簡介不能繞著講，所以到底要人怎麼辦？每次都被氣一次，再請求代為編輯好滿足有些人喜歡被人求著做事嗎？在這種地方持續內耗好有理由說管理工作很辛苦人手不夠嗎？

這不是第一次了。上次我在張愛玲的作品上加劇情也是碰上這種就是不明講就是要玩你的詭雷。罵了幾句就乾脆被封了。愛封去封，反正我的ISP每天給我不同IP。但那可真是氣上加氣啊。各位若有幸遇上偏激之至，硬要跟各位卯上的不知名人士，請回頭想想這麼個例子，就是被氣上加氣氣到高血壓的。--2603:8000:500:FB00:F01C:AD04:E266:DA8B（留言） 2024年3月8日 (五) 17:37 (UTC)

本站受到破壞者侵犯二十餘年，被嚴重破壞氣死的維基人估計也不少，但只有實在是應付不過來的極端時候，才會一勞永逸編寫過濾器。希望您別生氣，並先考慮註冊個帳號。另外我不熟悉相關領域條目，還請諸位若有空時協助他將編輯內容更新到條目中。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年3月8日 (五) 18:21 (UTC)

@Ericliu1912：我覺得就這一次我公開一下如何？公開前我給你發一封郵件私下説一下欲公開的內容。--MilkyDefer 2024年3月9日 (六) 07:00 (UTC)

• @MilkyDefer：但我看了一下這次的觸發原因，老實說，公布了也沒什麼用，嚴格來說是因為過濾器沒法有效的處理中文斷詞，兩個不相關的字或詞卡在一起剛好誤觸了過濾器。且有許多的不是在禁「常用詞彙」而是一組用於匹配一個或多個詞彙的代碼，一般人也不一定看得懂，那這樣公布了意義何在？-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月13日 (三) 04:07 (UTC)

我很想知道，所謂破壞者常用詞彙，其存在的目的是什麼？

如果是要人不要去用這些詞彙，那不是該公佈出來才有所依循嗎？如果不可公佈，那是不是在防止別人用同義詞閃過去，照樣表逹同樣的概念？這樣說有沒有錯？

這樣的話，真正在防的，不是破壞者常用詞彙，而是破壞者所想表達的理念，對不對？

防止特定詞彙，雖然對自重的人挺多餘，但還能理解；如果是在防特定理念的話...請跟著我說一次：維基百科，自由的百科全書。

你挖一個坑，然後聲明某處有坑，雖然多餘，還算可以接受。你挖個坑，然後還說不能說哪裡有坑的話，這叫坑人。--2603:8000:500:FB00:4DA3:48E2:8A4F:B6B7（留言） 2024年3月12日 (二) 00:09 (UTC)

不是這個含義，那是人工維護的WP:LTA特徵，匹配的編輯大概率為純粹惡意編輯而不應被提交/保留。關於出現誤報，我認為規則維護者理應及時監看和跟進，但可能人手有限、暫無有效手段優化，也無明確約定多少誤報（數量或比率或其他）是不可接受的。--YFdyh000（留言） 2024年3月12日 (二) 00:50 (UTC)

您對常用詞彙的理解可能有誤，一些喜歡破壞維基百科的人，他們的編輯有明顯的特徵。假設有個人喜歡往維基百科到處貼「蘋果梨子拼盤」，那麼「蘋果梨子拼盤」就會成為敏感詞屏蔽掉。另外自由的百科全書指的是版權自由，並非指其他自由。 ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2024年3月12日 (二) 01:23 (UTC)

請讀Wikipedia:Abusefilter -‎Lemonaka 2024年3月13日 (三) 01:15 (UTC)

我要說，您這次並沒有使用到任何敏感詞，您遇到的問題是技術上的：過濾器無法（或難以）有效地處理中文斷詞，所以誤將兩個不相關的字或詞卡在一起而誤觸了。這次的觸發並非該過濾器的設計原意。中文的斷詞不像英文那樣有空格可以分開，所以我不認為這叫「用自動過濾來羞辱人類大腦」這只是目前的技術限制。我們社群能做的最多是向基金會提願望清單，希望給過濾器實裝個中文斷詞系統。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月13日 (三) 04:21 (UTC)

歡迎新老師生前來品嘗 ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2024年3月13日 (三) 10:54 (UTC)

寫個條目，給個訊息說「內含破壞者常用詞彙」，然後這裡說不是這個含義，說理解可能有誤。理解有誤也是被這個莫名的警告訊息給誤了。所以這裡就值得討教了。究竟是當初寫這訊息的人表達能力不足，還是存心誤導？好我們善意推定，當初非常貼合原意，破壞者常用詞彙就是破壞者常用詞彙。只是後來逐漸變質，變成「不是這個含義」？那到底要不要把誤人的訊息改得比較不那麼誤人，還是就是要留個機會去似輕實重地指摘被誤的人：「您對常用詞彙的理解可能有誤」？

所以這就是個以人廢言的工具了？以過濾器來判斷來人是否為破壞者，是要判斷是破壞者，那就一個字都不准留？強迫人類大腦去遵從自動過濾的判斷，好，這不叫羞辱，這叫專制可以吧？不要講代為編輯什麼的，代為編輯是陷阱！

究竟是什麼不相關的字或詞卡在一起了？不想被當成破壞者所以想避開可不可以？可不可以說要怎麼避啊？還是一定要這麼內耗下去？這麼喜歡內耗的話何不多弄幾篇測試用的文字去試一下自動過濾是過濾了什麼東西出來？還是詞彙設定後就不管了，等別人一頭撞上再回一個「您對常用詞彙的理解可能有誤」來展現優越感？好好好，你很優越，能不能賜教下民，究竟是撞到了什麼東西？

人手當然有限，怎麼可能無限？設這種為難人的東西自我內耗就是元兇之一啊！--2603:8000:500:FB00:75D2:1CB9:BADD:611F（留言） 2024年3月16日 (六) 05:51 (UTC)

• 我明白您的感受。但是因為該過濾器設定為保密，所以我也無法告訴你是哪幾個不相關的字或詞卡在一起誤觸了過濾器，否則我可能會因洩密遭到封禁或除權處分。不能公開是因為如果破壞者可以去看該過濾器的原始碼（過濾器裡面是一段類似程式碼的東西，不單只是檢查單詞，而是條件式加正則表達式）來擬訂繞過方案，繼續破壞維基百科，在該過濾器還沒設立的年代，我們回退員回退破壞性編輯真的是忙不過來，會累死，為了避免維基百科被破壞，我們也有我們的苦衷（我之前為了對抗LTA:X43的破壞還差點精神崩潰），因為真的找不到更好的方案，我們也只能這樣，望能諒解。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年3月16日 (六) 06:43 (UTC)

維基專題:建立條目/參與者/申請

The button on this page is stuck, while I'm using Edge when editing Wikipedia.---Lemonaka 2024年3月26日 (二) 06:08 (UTC)

修了。不知道為什麼之前那樣寫。--YFdyh000（留言） 2024年3月26日 (二) 06:37 (UTC)