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