WordPressにおける翻訳用語集と用語の一貫性

WooCommerceストアのドイツ語版を開き、「カート」という言葉がインターフェース上をどのように移動するかを見てみましょう。ヘッダーボタンにはWarenkorbとあります。チェックアウトページにはEinkaufswagenとあります。確認メールにはKorbとあります。これら3つはすべて、ショッピングカートを表すドイツ語として技術的には有効であり、ファイルを一つずつ作業する人間の翻訳者であれば、どれを使ってもおかしくありません。しかし、サイトを読む顧客は3つの同義語を見ているわけではありません。彼らは、自身の語彙を統一できていないサイトを目にしており、Eコマースサイトでは、クレジットカード情報を求めているまさにその瞬間に、その一貫性の欠如は不注意と映ります。

これこそが、翻訳用語集が解決する問題です。用語集（タームベースとも呼ばれます）とは、特定の用語を各言語でどのように表現すべきか、どの用語は一切翻訳してはならないか、そしてどの用語は常に同じ方法で翻訳されなければならないかを定めた権威あるリストです。このガイドでは、用語集の概念、最も重要な2つの用語カテゴリ、大きなファイルをチャンクに分割することがいかにひそかに一貫性を損なうか、そしてチャンク間で用語集を維持する翻訳パイプラインがどのようにこれを修正するかを説明します。

翻訳用語集とは

翻訳用語集とは、言語ごとに維持される、原文用語と承認された翻訳語との構造化されたマッピングです。最もシンプルな形では、原文用語、必須の訳語、そしてその用語がロックされているか翻訳可能かを示すメモを含むテーブルです。翻訳者と翻訳エンジンは、同じ概念が2つの異なる方法で表現されることがないよう、これを唯一の信頼できる情報源として参照します。

小さな用語集の断片は、JSONで次のように見えるかもしれません。

{
  "en": "Cart",
  "translations": {
    "de": "Warenkorb",
    "es": "Carrito",
    "fr": "Panier"
  },
  "translatable": true
},
{
  "en": "Acme Pro",
  "translations": {},
  "translatable": false,
  "note": "Brand product name. Never translate."
}

あるいは、チームがフラットなスプレッドシートを好む場合は、同じデータをCSVで示します。

source,de,es,fr,translatable
Cart,Warenkorb,Carrito,Panier,yes
Checkout,Kasse,Pagar,Commander,yes
Acme Pro,,,,no
Add to Cart,In den Warenkorb,Añadir al carrito,Ajouter au panier,yes

用語集は2つの役割を同時に果たします。翻訳可能な用語に対しては、承認された1つの表現を強制します。翻訳不可能な用語に対しては、変更禁止リストとして機能します。

フォーマット自体はほとんど重要ではありません。JSON、CSV、スプレッドシート、または単純なキーバリューファイル、どれでも機能します。なぜなら、用語集の価値はファイル拡張子ではなく、合意された参照としての役割にあるからです。重要なのは、それが存在し、唯一の信頼できるコピーであり、文字列を翻訳するものが実際にそれを参照することです。翻訳プロセスが参照しない共有ドライブに置かれた用語集は、単なるドキュメントに過ぎません。パイプラインがすべての文字列に強制する用語集は、品質保証となります。

ほとんどのチームは、最初の不一致が本番環境で問題を引き起こした後、事後的に用語集を導入し始めます。より良い方法は、最初の翻訳パスの前に、明らかなエントリ（製品名、上位20のインターフェース用語、間違った選択が顧客を混乱させる可能性のある業界用語など）でシードすることです。適切に選択された20のエントリで、一貫性の問題の大部分を防ぐことができます。

用語集なしでは破綻する2種類の用語

実際に用語集で管理する必要があるのはどの用語でしょうか？2つのカテゴリがあり、それぞれ逆方向に失敗します。

決して翻訳してはならないブランド用語

製品名、ブランド名、機能名、商標は、翻訳プロセスを通じて完全に変更されないままであるべきです。Acme Proがスペイン語でAcme Profesionalになったり、QuickShipという配送機能がEnvíoRápidoになったりすると、ブランド認知が損なわれ、多くの場合、その正確な文字列がコード内で一致しているUIも破損します。

これは最も一般的で、最も損害の大きい用語集の失敗です。機械翻訳は、Pro、Plus、Cloud、その他一般名詞のように見える単語を親切にも翻訳してしまいます。なぜなら、それらの単語がブランドの一部であることを知る術がないからです。用語集こそが、それを止める役割を果たします。

一貫して翻訳されなければならない用語

その反対の問題が、WarenkorbとEinkaufswagenの状況です。これらは翻訳されるべき実際の単語ですが、常に同じ方法で翻訳されなければなりません。カート、チェックアウト、アカウント、ウィッシュリスト、注文、配送といったインターフェース用語は、すべての画面、メール、ボタンにおいて1つの固定された訳語にマッピングされる必要があります。ここでの危険は誤訳ではなく、ブレです。個々の正しい選択は単独では問題ありませんが、サイト全体での一貫性の欠如こそが欠陥となります。

これが信頼を損なう問題です。ユーザーはインターフェースを利用する際に、その語彙のメンタルモデルを構築します。単語が変わるとモデルが崩れ、認知的な摩擦が「このサイトは品質が低い」という漠然とした感覚として認識されます。顧客がその理由を明確に説明できなくても、です。

一貫性は、感覚的なものだけでなく、具体的なユーザビリティコストも伴います。サポートドキュメント、ツールチップ、オンボーディングメールはすべてインターフェース用語を参照しています。ボタンにWarenkorbとあるのにヘルプ記事にはEinkaufswagenとあれば、混乱した顧客は指示と画面を結びつけることができません。用語の不一致は、自社のサポートコンテンツをひそかに破壊します。用語集こそが、製品、ドキュメント、マーケティングコピーのすべてが文字通り同じ言葉を話すように保つものです。

大きなファイルをチャンクに分割することが不整合を引き起こす理由

ここでは、一度きりの用語集のわずらわしさが、大規模サイトでシステム的な問題に変わるメカニズムを説明します。大規模なWordPressまたはWooCommerceストアでは、数千もの文字列を含む.poファイルを持つことがあり、これはAIモデルが単一のリクエストで翻訳できる量をはるかに超えます。そのため、ファイルはチャンクに分割され、各チャンクは個別に翻訳されます。

問題は、各チャンクが個別に翻訳される場合、エンジンには3つのチャンク前にどのように用語をレンダリングしたかの記憶がないことです。チャンク1では「Cart」をWarenkorbと翻訳するかもしれません。一方、共有コンテキストなしに独立したリクエストとして処理されるチャンク7では、同じ「Cart」をEinkaufswagenと翻訳する可能性も十分にあります。どちらもそれ自体は間違いではありません。この不一致は、個々の悪い決定によるものではなく、チャンク分割の副産物なのです。

# Chunk 1 - header strings
msgid "Cart"
msgstr "Warenkorb"

# Chunk 7 - footer strings, translated in a separate request
msgid "View Cart"
msgstr "Einkaufswagen ansehen"

ファイルが大きければ大きいほど、チャンク数が増え、同じ用語が分岐する機会も増えます。これこそが、大きなファイルの翻訳が見た目以上に難しい理由であり、大きなPOファイルを翻訳する方法で詳しく説明しています。素朴なチャンク分割は、完全性を一貫性と引き換えにしており、数千の文字列を持つストアでは、その引き換えが至るところに現れます。

用語集対応パイプラインがこれを解決する方法

解決策は、2つのことを同時に行う翻訳パイプラインです。大きなファイルをインテリジェントに分割して処理できるようにし、すべてのチャンクにわたって用語集と用語のコンテキストを維持することで、分割によってブレが生じないようにします。

ここでスマートバッチングとコンテキスト対応AIが連携して機能します。スマートバッチングは10MBを超えるファイルを処理可能なチャンクに分割しますが、チャンクは孤立した未知のものとして翻訳されるわけではありません。パイプラインはチャンク間で用語集と用語の一貫性を強制するため、「Cart」がWarenkorbとして確立されれば、その後の「Cart」を含むすべてのチャンクは同じ表現を受け取ります。ロックされたブランド用語の用語集もすべてのチャンクと共に移動するため、Acme Proは文字列番号5に現れても文字列番号5,000に現れても無傷で維持されます。

その結果、6,000文字列のストアファイルは、パッチワークのような状態ではなく、一貫した語彙で返されます。ブランド名はそのままです。インターフェース用語は統一されます。そして、それらの文字列内のプレースホルダー、つまり%sや{name}トークンも同時に所定の位置にロックされたままになります。まるで完璧な記憶力を持つ一人の注意深い翻訳者が、すべてを一気に処理したかのようなファイルが得られます。

ほとんどの人が頼りがちな代替案と比較してみましょう。それは、ファイルを部分的に翻訳し、後で手動で検索と置換を実行して用語を正規化する方法です。このアプローチは2つの理由で失敗します。第一に、どの用語がブレたかをすでに知っている必要があり、そのためにはまず数千の文字列をレビューして不整合を見つけることになります。第二に、盲目的な検索と置換は危険です。なぜなら、同じ単語でもあるコンテキストでは正しくても、別のコンテキストでは間違っている場合があるからです。翻訳中に用語集を強制することは、エンジンが各文字列の完全なコンテキストをまだ持っている間に行われるため、後から修正するよりも根本的に安全です。

マルチサイトワークフローにおける用語集

多くのクライアントサイトでローカライズを行っている代理店にとって、用語集の規律はより複雑になります。各クライアントは独自のブランド用語と承認された語彙を持っており、あるクライアントの用語集を別のクライアントで再利用すると、確実に問題が発生します。繰り返し可能で用語集主導のワークフローこそが、手動レビューの手間を12倍にすることなく、多数の多言語サイトを一貫して保つ方法であり、これこそが複数のクライアントサイトを管理する代理店向けの理想的なローカライズワークフローの核となります。用語集は、クライアントごとに、そのクライアントのために翻訳するすべてのファイルと共に移動する資産となります。

用語の一貫性は、正しくても誰も意識的に気づかないが、間違っていると誰もが感じる品質シグナルの1つです。すべての画面でWarenkorbを読む顧客は、それについて考えることはありません。カートに対して3つの異なる単語を見る顧客も、苦情を出すわけではありません。ただ、サイトへの信頼が少し薄れ、コンバージョン率が少し悪くなるだけです。すべてのファイルのすべてのチャンクにわたって強制される用語集は、彼らがそう感じる必要がないようにするための方法です。

多言語ストア全体で、すべての用語を一貫して保つ準備はできましたか？SimplePoTranslateを無料で試す — クレジットカードは不要です。無料プランでは、チャンク全体で用語集と用語の一貫性を強制するため、「カート」は常に1つの単語に保たれ、ブランド名は最初の文字列から最後の文字列まで手付かずのまま維持されます。