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” - 这个问题已经修复。我发现了 这个 关于 https://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 特指密码)
  • perspective-api → “Perspektiven-api”
  • backups → “Sicherungen”
  • design-experiment → “Experimententwurf” - 可以是"design-experiment",也可以是“草稿实验”。考虑到前者我本应保留"design"一词,而在 Discourse 中讨论草稿非常普遍,我认为这里指的是后者。

"Discourse"的翻译问题

大多数指代"Discourse"的标签都被翻译了,导致不再包含软件名称。discourse-hub 是一个例外。

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

这是一个涉及所有与主题(theme)相关标签的系统性问题。在德语中,“theme"和"topic"都翻译为"Thema”,但在 Discourse 语境下,这两者截然不同。这使得主题标签读起来像是关于特定讨论话题的。

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

因缺乏上下文而导致的翻译错误

  • composer → “Komponist” - 这是指创作音乐的人,而我们通常将输入字段称为“编辑器”(Editor)。
  • tablet → “Tablette” - “药片”或“平板电脑”。
  • copy-post → "kopierbeitrag” - “复制费”(问题在于词语组合。"Beitrag"表示帖子是正确的,但因为 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 自身的 UI 使用了不同的术语。这使得标签更难被直观地找到,特别是对于依靠界面语言导航的用户。

  • 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” - “消息/新闻”(可能会产生误导,因为消息是另一个功能,界面中“官方公告”使用的是 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"是一个相当长的词。

更多示例

这些例子表明,翻译过程需要更多的上下文——理想情况下需要知道标签属于哪个插件或功能,并能参考现有的 Discourse 界面翻译。如果其他人也在其他语言中注意到了类似的模式,我很乐意听到。


@nat(应个人请求)


  1. Lernunterlagen ↩︎

6 个赞

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

另外,哈哈哈

感谢带来的欢笑::hugs:

4 个赞

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

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

3 个赞

嗯,这是个不错的主意 @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 上实现完美翻译会非常容易。

我不认为任何模型会像德语翻译为 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 可能性的地方。