AI生成的标签翻译并不完美

在浏览德语标签翻译时,我注意到了一系列问题,这些问题似乎源于 AI 缺乏上下文——它将标签视为孤立的单词,而不是对特定 Discourse 功能、插件或组件的引用。

注意:德语名词首字母必须大写,但 meta 上的标签是小写的。因此,本文中的翻译大小写不一致——我习惯性地使用了正确的德语大写规则。

先说说有趣的部分

在深入探讨实际问题之前,有些翻译简直令人捧腹:

  • composer(编辑器)→ “Komponist” - 这是指写音乐的人
  • auto-bump(自动顶帖)→ “automatische-erhöhung” - “自动增加”
  • fully-theme(完全主题化)→ “vollständig-thematisiert” - “完全处理”
  • raspberry-pi → “Himbeere-pi”(“raspberry”被当作水果“覆盆子”)
  • post-voting(帖子投票)→ “nach-der-Abstimmung” - “投票后”(“post”被误读为拉丁语前缀,而非论坛帖子)
  • tablet → “Tablette” - “药片”(药物,而非设备)

不同标签使用相同翻译

这是实践中影响最大的问题。当两个标签获得相同的翻译时,它们就失去了区分不同主题的能力。

  • year-in-review(年度回顾)& yearly-review(年度回顾)→ “Jahresrückblick” - 目前看来该插件的名称似乎不可翻译(我在管理侧边栏和已安装插件列表中看到的是英文名称),因此你可能仍会使用英文名称来指代该插件。不过,我希望有一天所有插件都能拥有翻译后的名称,所以我认为我会在用于归类此处年度回顾主题的标签上添加“Metas”,使其变为“Metas-Jahresrückblick”(Meta 的年度回顾)
  • surveys(调查)& polls(投票)→ “Umfragen” - 我认为这两个插件的翻译也是相同的,而且到目前为止没人注意到。我需要再想想这个问题的最佳解决方案,因为它也容易与“voting”(投票)冲突 :exploding_head:
  • docs(文档)& documentation(文档)→ “Dokumentation” - 就像 yearly-review 的文档未被翻译成德语一样,我不会翻译这个标签(在这种情况下,未来进行翻译的可能性非常小)
  • how-to(教程)& tutorial(教程)→ “Anleitung” - 这个问题已经修复。我找到了 thishttps://diataxis.fr/ 的翻译,并建议采用其中使用的术语[1](学习材料))

不应翻译的专有名词和产品名称

有些标签指的是特定的工具、框架或产品。翻译它们会使该功能变得难以识别。

  • raspberry-pi → “Himbeere-pi”(“raspberry”被当作水果)
  • mermaid → “Meerjungfrau”(“mermaid”被当作神话生物“美人鱼”,而非绘图工具)
  • ember → “Glut”(余烬)
  • vanilla → “Vanille”(香草口味)
  • onebox → “einzige-box” - “唯一的盒子”
  • intercom → “Gegensprechanlage”(门铃对讲机,尽管 intercom-widget 翻译得很好)
  • passkey → “Passwort” - “密码”(passkey specifically 不是 密码)
  • perspective-api → “Perspektiven-api”
  • backups → “Sicherungen”
  • design-experiment → “Experimententwurf” - 可以是“设计实验”,也可以是“草稿实验”,我认为后者更合适,因为如果是前者,我会保留“design”,而在 Discourse 中讨论草稿是非常常见的。

“Discourse”的翻译

大多数引用“Discourse”的标签都被翻译了,因此不再包含软件名称。唯一的例外是 discourse-hub

“Theme”(主题)被一致误译为“Thema”(话题)

这是所有与主题相关的标签中的系统性问题。在德语中,“theme”和“topic”都翻译为 Thema,但在 Discourse 的语境中,这两者截然不同。这导致主题标签读起来像是在讨论特定的讨论话题。

这影响了官方主题组中的所有标签。

缺乏上下文的翻译

  • composer(编辑器)→ “Komponist” - 这是指写音乐的人,相比之下,我们通常将输入字段称为“Editor”(编辑器)。
  • tablet → “Tablette” - “药片”或“平板电脑”。
  • copy-post → "kopierbeitrag” - “复印费”(问题在于词语组合。“Beitrag”对于“post”来说是正确的,但由于“copy”没有被翻译为动词,读起来像是这里的“Beitrag”被用作“费用”的意思)

名词或动词

一些功能被翻译成了动词而不是名词

  • chat → “plaudern” - “聊天”(动词)
  • search → “suchen” - “搜索”(动词)

“post”被误读为拉丁语前缀,而非论坛帖子

  • post-voting → “nach-der-Abstimmung” - “投票后”
  • post-badges → “nach-Abzeichen” - “徽章后”

源自英语标签含义不清的结果

  • hosted-support → “gehosteter-support”(这读起来像是支持服务被托管,而不是针对托管客户的支持)

缩写

  • pm-dropdown(德语相同)没有上下文,m(message)未被替换为 n(Nachricht)

与 Discourse 自身界面术语不匹配的翻译

这些翻译在德语语法上是正确的,但 Discourse 自身的界面使用了不同的术语。这使得标签难以直观地找到,特别是对于通过界面语言进行导航的用户。

  • impersonate → “nachahmen” - “模仿”(但界面使用 Nutzersicht 或 Nutzerrolle)
  • staged-users → “Staging-Benutzer”(但界面显示的是 vorbereitete Benutzer)
  • advertising → “Werbung”(但界面指的是 Anzeigen)
  • assign → “zuweisen”(但插件翻译使用的是 zuordnen)
  • hot-topics → “Top-Themen”(这被翻译为“热门话题”,但这实际上是 Discourse 中的另一个列表)
  • read-only → “nur lesbar”
  • bootstrap-mode → “Bootstrap-Modus”(但翻译人员最初选择了 Starthilfemodus)
  • post-notices → “Nachrichten” - “消息/新闻”(可能会产生误导,因为消息是一个不同的功能,“official notice”在界面中使用 Mitteilung)
  • about-page → “über-Seite”(这是直译。但通常德语翻译类似于“关于我们页面”。Über 不仅意味着关于,还意味着在……之上。)
  • auto-bump → “automatische-erhöhung” - “自动增加”
  • tags → “Etiketten”(但 tag-groups 和大多数包含 tag 的标签使用“tag”,Crowdin 上使用的术语是 Schlagwort)

截断的翻译

这是一种不同类型的问题——不是翻译错误,而是德语复合名词比其英语对应词显著更长,加上标签字符限制的结果。

  • content-security-policy → “inhalts-sicherheitsrichtl”(被截断,应为 inhalts-sicherheitsrichtlinie)
  • ai-custom-prompt → “ai-benutzerdefinierte-auf”(单词中间被截断,应为 ai-benutzerdefinierte-aufforderung)
  • custom-category-boxes → “benutzerdefinierte-katego”(单词中间被截断,应为 benutzerdefinierte-kategorie-boxen,在这种情况下,翻译中完全缺少了“box”)

包含“custom”的标签很容易过长,因为“benutzerdefiniert”是一个相当长的词。

更多示例

这些例子表明,翻译过程需要更多的上下文—— ideally 知道标签属于哪个插件或功能,并能够访问现有的 Discourse 界面翻译作为参考。很高兴听到其他人是否在其他语言中注意到了类似的模式。


@nat (应个人请求)


  1. Lernunterlagen ↩︎

8 个赞

感谢 @Moin,我会着手处理这个问题并优化我们的提示词::blush:

另外,哈哈哈

感谢带来的欢笑::hugs:

5 个赞

@nat 如果我们给代理提供读取工具的访问权限,让它自行收集上下文,会怎样?

对于帖子来说可能成本过高,但对于标签和分类等一次性任务来说,成本较低,且能提升所有模型的质量。

4 个赞

嗯,这是个不错的主意 @falco

我考虑的另一种方法是在翻译标签名称时,将标签的描述作为附加上下文传入。也许这种方式更可预测,你觉得呢?

4 个赞

在 Crowdin 上访问术语表对于执行翻译的机器人可能会非常有帮助(并非适用于所有站点,但对 Meta 站点尤其重要)。如果在那里注明我们将"composer"翻译为“编辑器”,并且 AI 知晓这一点,它就可以在标签、主题标题和帖子中使用该译法。

我曾修复过 Introducing our new composer, making writing on Discourse easier than ever 中的"composer"一词,这引发了我关于在此处编辑翻译的反馈:Feedback on the composer when translating a post to German

在 Meta 站点上,描述通常无法提供太多上下文。例如,所有主题组件的描述仅包含指向该组件主题的链接,而不包含主题开头的那段简短描述。

好主意,我们两个都试试!

我们的想法是以 Meta 为试验场和代理,模拟客户在实际环境中可能遇到的情况,从而让该功能对所有人更加完善。

如果仅仅使用最昂贵的大型语言模型(LLM),并赋予其访问源代码和网络搜索等工具的权限,要在 Meta 上实现完美翻译会非常容易。

1 个赞

我不认为任何模型会像德语翻译为 Discourse 界面所做的那样,为 Meta 选择相同的译文。“Mitarbeiter”是“staff”的完美翻译。事实上,一些翻译人员在多年前决定该词不适用于小型爱好者论坛(因为在此语境下“staff”暗示的是带薪员工),因此选择了“Team”,这是任何 AI 都无法猜到的,因为这根本不是正确的翻译。这正是 Crowdin 术语表可以发挥作用的地方:如果没有它,AI 生成的术语永远无法与管理员在界面中实际看到的术语相匹配——并非因为 AI 无法翻译,而是因为它不会像人类翻译那样做出相同的本地化决策。这就是翻译与本地化之间的区别。
其他术语如“bootstrap mode”(引导模式)或“impersonation”(冒充)的情况也是如此。

确实如此,因为它可以访问完全相同的选项,即 config/locales/**/*.yml 文件作为参考。

完全正确。对于像分类和标签这样的小型可枚举组,让代理访问作为源代码一部分的现有翻译,将有助于为其提供依据。

我们无法对帖子这样做,因为成本太高,但这对于小型网站或拥有较大翻译预算的客户来说是一个可行的选项。

那么,也许您应该为 DocumentationNews and Events > Announcements 禁用 AI 翻译 :wink: 我认为很难确保这些翻译是有帮助的,尤其是因为建议的编辑不会提升主题,所以没有简单的方法能注意到某个主题已更新。

总的来说,成本是我建议使用术语表而不是包含所有翻译的文件的原因,因为我预计术语表只需包含一次最相关的选项,而无需添加所有文本。

事实并非如此;代理可以搜索代码中包含匹配项的代码块,它绝不会将整个内容加载到上下文中。

这有点像是因噎废食,不是吗?

我刚刚在 PT-BR 中检查了 https://meta.discourse.org/t/calendar-subscription-urls-for-external-calendar-apps/398902,看起来翻译得非常出色,比没有好得多。

在无监督机器翻译工作流中,总会有需要改进的地方,而且多亏了你们的反馈,@nat 今天已经让它变得更好了!

没人指望它完美无缺,Meta 是一个我们可以率先采用新功能并向我们的用户和客户展示 Discourse 可能性的地方。

嗨,团队,

我该如何在 Discourse 中禁用由 AI 翻译生成的特定标签?

我发现这些 AI 翻译生成的标签质量参差不齐,因此希望单独关闭它们。

谢谢。

目前,AI 翻译不按模型类型进行范围限定,开启后将对主题、帖子、分类和标签生效。

我的建议是直接在标签设置中编辑标签翻译。只需操作一次,便无需再次处理。

或者,您也可以更新“短文本翻译”代理所使用的提示词。

1 个赞

你能帮我找出自从我发布这个主题以来,哪些标签翻译得到了改进吗?

OP 中提到的标签(以及一些其他标签)现在应该在 meta 上得到处理。非常感谢这份详尽的列表,这让工作变得轻松,我本该早点完成的 :smiling_face:

关于向标签翻译器传递更多上下文,这还需要一些时间,因为目前它并非高优先级任务。

2 个赞