维基百科:互助客栈/其他/存档/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)