AI 生成タグ翻訳は完璧に機能しない

ドイツ語のタグ翻訳をスクロールしている際、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” - 「錠剤」(薬品であり、デバイスではない)

異なるタグに対する同一の翻訳

これが実務上で最も影響の大きい問題です。2 つのタグが同じ翻訳になると、トピックを区別する能力を失ってしまいます。

  • year-in-review & yearly-review → “Jahresrückblick” - 現在、プラグイン名は翻訳されていないようです(管理サイドバーやインストール済みプラグインのリストで英語名が表示されています)。そのため、プラグイン名を指す場合は英語の用語を使用するのが妥当でしょう。将来的にはすべてのプラグインに翻訳された名前がつくことを願っていますが、ここでは年次レビューのトピックをまとめる方に「Metas」を追加して「Metas-Jahresrückblick」(Meta の年次レビュー)と区別することを提案します。
  • surveys & polls → “Umfragen” - 両方のプラグインの翻訳も同じのようですが、これまで誰も気づいていないようです。これは「voting(投票)」とも簡単に競合する可能性があるため、良い解決策についてもう少し考える必要があります:exploding_head:
  • docs & documentation → “Dokumentation” - 年次レビューの docs がドイツ語に翻訳されていないのと同様に、このタグも翻訳しないことをお勧めします(将来的に翻訳される可能性は極めて低いです)。
  • 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」を残し、Discourse では草案について話すことが一般的であるため、後者(草案実験)を意味すると考えられます。

「Discourse」の翻訳

「Discourse」を指すタグの多くは、ソフトウェア名が含まれないように翻訳されていました。例外は discourse-hub です。

「Theme」が一貫して「Thema(トピック)」と誤訳されている

これはテーマ関連のタグ全体にわたる体系的な問題です。ドイツ語では「theme」と「topic」の両方が「Thema」と訳されますが、Discourse の文脈ではこれらは全く異なるものです。これにより、テーマタグが特定の議論トピックに関するもののように読めてしまいます。

  • theme-welcome → “Willkommens-Thema”(デフォルトでピン留めされた歓迎スレッドのような「歓迎トピック」として読める)
  • theme-creator → “Themenersteller” - 「トピック作成者」
  • horizon-theme → “Horizont-Thema”
  • meta-theme-feedback → “Meta-Themen-Feedback”
  • foundation-theme → 同じパターン
  • fully-theme → “vollständig-thematisiert” - 「完全に扱われた」

これは公式テーマグループのすべてのタグに影響します。

文脈が欠落していた翻訳

  • 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”(これは逐語的な翻訳です。通常、ドイツ語の翻訳は「about us page」のようなものです。Über は「about」だけでなく「above(上)」も意味します)
  • 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」が非常に長い単語であるため、すぐに長くなりすぎます。

more examples
  • pause-notifications → “benachrichtigungen-anhalt”(en)
  • theme-site-settings → “thema-website-einstellung”(en)
  • staff-action-log → “mitarbeiter-aktionsprotok”(le)
  • lazy-load-categories → “kategorien-verzögert-lade”(n)
  • unsupported-install → “nicht-unterstützte-instal”(lation)
  • categories-navbar → “kategorien-navigationslei”(ste)
  • remove-name-suppression → “namenunterdrückung-entfer”(nen)
  • right-sidebar-blocks → “rechte-seitenleiste-blöck”(e)
  • user-field-prompt → “benutzerfeld-eingabeauffo”(rderung)
  • top-contributors-sidebar → “seitenleiste-der-top-beit”(ragenden)
  • hide-users-column → “benutzer-spalte-ausblende”(n)
  • topic-footer-buttons → “thema-fußzeilen-schaltflä”(chen)
  • scrollable-post-content → “scrollbarer-beitrag-inhal”(t)
  • custom-inline-codeblocks → “benutzerdefinierte-inline” (-codeblöcke)
  • hide-muted-categories → “stummgeschaltete-kategori”(en-verstecken)
  • custom-header-icons → “benutzerdefinierte-kopfze”(ilen-symbole)
  • custom-header-links → “benutzerdefinierte-kopfze”(lein-links)(注:これらはカットされたため上記と同じです)
  • new-topic-header-button → “neuer-themen-header-butto”(n)(通常、button には「Schaltfläche」を使用します)
  • sidebar-theme-toggle → “seitenleisten-themenumsch”(alter)(もちろん、この場合も「theme」を使用し「topic」を使用しないため、「n」は不要です)
  • custom-profile-link → “benutzerdefiniertes-profi”(l-link)、文法を見ると「link」がかなり早期に失われたように見えますが、custom は link ではなく profile に一致します。「benutzerdefinierter-profil-link」であるべきだと思います。
  • easy-responsive-footer → “einfacher-responsiver-fuß” 上記と同様に、easy と responsive はタグが切り捨てられたフッターではなく、foot を指しているように見えます。「einfache-responsive-fußzeile」であるべきです。

これらの例は、翻訳プロセスにさらなる文脈が必要であることを示唆しています。理想的には、タグがどのプラグインまたは機能に属しているかを知り、既存の Discourse インターフェース翻訳を参照できるようにする必要があります。他の言語でも同様のパターンに気づいた方がいれば、ぜひ聞かせてください。


@nat(個人的な依頼により)


  1. Lernunterlagen ↩︎

「いいね!」 6

@Moin さん、ありがとうございます。これを確認し、プロンプトを改善いたします :smiling_face:

それにしても、笑ってしまいました LOL

笑いをもたらしてくださり、ありがとうございます :hugs:

「いいね!」 4

@nat、エージェントに読み取りツールのアクセス権を与えて、自分で文脈を収集できるようにしたらどうでしょうか?

投稿にはコストがかかりすぎますが、タグやカテゴリのような単発のタスクではコストが安く済み、すべてのモデルの品質向上が期待できます。

「いいね!」 3

Hmm、良いアイデアですね @falco

私が検討したもう一つの方法は、タグ名を翻訳する際に、タグの説明を追加のコンテキストとして渡すことです。この方がより予測可能かもしれませんが、どうお考えですか?

「いいね!」 4

Crowdin の用語集にアクセスできれば、翻訳を行うボットにとって非常に役立ちます(すべてのサイトではありませんが、特に Meta において)。もしそこで「composer」を「Editor」と訳すことが記載されており、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を実験場として、また実際の顧客が直面する可能性のある状況の代理として活用し、その結果として全ユーザー向けに機能を改善することを目指しています。

Metaで完璧な翻訳を得るのは、最も高価なLLMを使用し、ソースコードへのアクセスやウェブ検索といったツールを利用可能にすることで、非常に簡単になるでしょう。

どのモデルも、Discourse インターフェースのドイツ語翻訳者が選んだのと同じ翻訳を Meta で選ぶとは思えません。「Mitarbeiter」は「staff」の完璧な翻訳です。しかし、一部の翻訳者が数年前に、それが「staff」が有給従業員を意味する小規模な趣味のフォーラムには適合しないと考え、「Team」という言葉を選んだ事実は、AI には推測できません。それは単に正しい翻訳ではないからです。まさにここで Crowdin の用語集が役立ちます。用語集がなければ、AI が生成した用語は、管理者が実際にインターフェースで見るものとは一致しません。それは AI が翻訳できないからではなく、人間が下したのと同じローカライズの判断を下さないからです。これは翻訳とローカライズの違いです。
「bootstrap mode」や「impersonation」といった他の用語についても、同様のことが言えます。

それは可能です。参考として、config/locales/**/*.yml ファイルにある同じ選択肢にアクセスできるためです。

その通りです。カテゴリやタグのような少数の列挙可能なグループについては、エージェントがソースコードの一部である既存の翻訳にアクセスできるようにすることで、その根拠を明確にするのに役立ちます。

投稿については、コストが高すぎるためそれをすることはできませんが、小規模なサイトや翻訳予算が大きい顧客にとっては選択肢の一つです。

それなら、DocumentationNews and Events > Announcements に対して AI 翻訳を無効にするべきかもしれませんね :wink: これらの翻訳が役立つことを保証するのは不可能だと思います。特に、提案された編集がトピックを最新化しないため、トピックが更新されたことに気づく簡単な方法がないからです。

一般的に、コストの問題から、すべての翻訳を含むファイルではなく、用語集の使用を提案しました。なぜなら、用語集には最も関連性の高い選択肢が一度だけ含まれると期待でき、すべてのテキストを追加する必要がないからです。

それは仕組みが異なります。エージェントはコード内の一致するチャンクを検索でき、全体をコンテキストに読み込むことはありません。

それは少し「赤子をお風呂の水ごと捨ててしまう」ようなものではないでしょうか?

ちょうど Calendar subscription URLs for external calendar apps を PT-BR(ブラジルポルトガル語)で確認しましたが、素晴らしい翻訳になっており、何もない状態よりはるかに優れています。

監督なしの機械翻訳ワークフローには常に改善の余地があり、@nat はあなたのフィードバックのおかげで今日すでにそれを改善してくれました。

完璧であることを期待している人はいません。Meta は、Discourse のユーザーや顧客に対して、早期に機能を導入し、何が可能かを実証できる場所です。