新規登録
ファイル形式・標準規格Read this article in English

TMXとTBXを理解する — 翻訳メモリと用語集のためのポータブルな形式

ローカライズプロジェクトで最も価値のある成果物は、どれか1つの翻訳済みファイルではありません。これまでに翻訳された全ての文と、チームが合意した全ての用語の蓄積された記録です。この記録をツール間で失うことなく持ち運ぶために存在するオープンでベンダー中立なXML形式が2つあります。翻訳メモリのためのTMXと、用語集のためのTBXです。どちらもアプリを出荷するときに使うUI文字列形式ではありません。どちらも、いま使っているツールが何であれ、言語資産をそこに出し入れするための交換形式です。

TMX — 翻訳メモリが実際に保存しているもの

翻訳メモリは辞書ではありません。実際の翻訳作業から得られた「原文と訳文のペア」が積み上がっていくデータベースです。翻訳者が確定させた文はすべて、その訳文とペアになったエントリとなり、次の翻訳者にはそれが提案や完全一致として示されます。TMX(Translation Memory eXchange)は、このデータベースを特定ベンダーのメモリストアの中に閉じ込めるのではなく、ツール間で移動させられるようにする形式です。

中核となる構造単位はtranslation unit(翻訳ユニット)で、その中に言語ごとのtranslation-unit-variantが1つずつあり、それぞれがsegment(セグメント) — その言語での実際の文・句のテキスト — を保持します。

<tu>
  <tuv xml:lang="en">
    <seg>Are you sure you want to log out?</seg>
  </tuv>
  <tuv xml:lang="de">
    <seg>Möchten Sie sich wirklich abmelden?</seg>
  </tuv>
</tu>

翻訳ユニットはセグメントと並んでメタデータ(作成日時、生成したツールや翻訳者、どのプロジェクト由来か)を持てます。これにより、後で翻訳ツールが翻訳者に一致する文を示すだけでなく、その一致がどこから来たものか、どれだけ信頼できるかという文脈も併せて示せるようになります。

TMXの実務的な価値は可搬性にあります。1つのツールの中で何年もかけて積み上げた翻訳メモリは、そのツールの中に取り残されずに済みます。TMXとして書き出し、別のツールに取り込めば文ペアは保たれるので、ツールを変える、外部の翻訳会社を新たに迎える、あるいは単に自分たちの蓄積作業のバックアップが欲しいといったチームは、その記憶をゼロから作り直す必要がありません。

TBX — 用語データベースが実際に保存しているもの

用語集は翻訳メモリとは種類の異なる資産で、解決する問題も違います。翻訳メモリは「これまで何が翻訳されたか」を記録するのに対し、用語データベースは「ある特定の用語は、それが現れる文とは無関係に常にどう訳すべきか」を記録します — 絶対に翻訳してはいけない製品名、承認された訳語が1つだけ決まっている専門用語、スタイルガイドで明示的に禁止された言い回しなどです。TBX(TermBase eXchange)は、この用語データベースのためのポータブルな形式で、TMXと同じLISA/OASIS系列の中で標準化されています。

TBXは、term entry(用語エントリ)を文ではなくconcept(概念)を中心に構造化します。1つの概念に1つのエントリがあり、言語ごとのterm section(用語セクション)を持ち、たいてい用語集のスプレッドシートでは失われてしまう種類のメタデータ — 品詞、使用上の注記、承認済み/非推奨といったステータス、定義 — を入れる余地があります。

<termEntry id="c001">
  <descrip type="definition">The in-game currency spent on cosmetic items</descrip>
  <langSet xml:lang="en">
    <tig><term>Gem</term><termNote type="partOfSpeech">noun</termNote></tig>
  </langSet>
  <langSet xml:lang="de">
    <tig><term>Edelstein</term><termNote type="status">approved</termNote></tig>
  </langSet>
</termEntry>

ユニットとセグメントの構造、その考え方

どちらの形式も、粒度は違えど同じ発想で組み立てられています。TMXの単位はtranslation unitで、1つの原文と各言語への訳の集まりであり、segmentはそのうち1言語分の実際のテキストです。TBXの単位はconceptで、名前を必要とする世界の中の1つの物事であり、term entryはその概念に対する各言語の承認済みの名称を保持します。それを含む文そのものではありません。

この違いこそが、1つの形式ではなく2つの形式が存在する理由です。翻訳メモリの一致は本質的に近似的です。2つの文は、完全に同一でなくても有用な提案となるほど似ていることがあり、翻訳者はその一致を受け入れるか、編集するか、却下するかをケースバイケースで判断します。一方、用語エントリはルールに近いものであることを意図しています。ある用語がapproved(承認済み)とマークされたら、QAチェックは同じ原語に対して異なる訳語が使われている箇所にフラグを立てられます。通常の文の翻訳のような許容できるバリエーションは、たいてい存在しないからです。

ポータブルな形式が言語資産を「自分のもの」にする理由

両形式が、各ツールが独自形式を発明するのではなくオープンな標準として存在している理由は明快です。翻訳メモリや用語データベースは長く使われる資産であり、それを作ったツールより長生きするのが普通だからです。あるゲームスタジオの承認済み用語や蓄積された翻訳メモリは、何年もの判断と有償の翻訳作業の集積を表しています。もしその記録が1つのツールの独自ストレージの中にしか存在しないなら、ツールを変える、あるいは別のツールを使う翻訳者と組む、というだけで最初からやり直しになってしまいます。

TMXとTBXは、まさにそれを起こさないために存在します。XMLベースで、特定ベンダーに縛られない形でオープンに仕様化されているため、本格的な翻訳ツールであればほぼどれでもこの両方を入出力できます。これにより、基盤となる言語資産は、今年たまたま使っているツールが何であれ、チームが実際に「所有」しているものになります。

スプレッドシートの用語集との違い

原語・訳語・言語ペアごとに1行、というスプレッドシートの用語集は、一見TBXと同じ仕事をしているように見えます。小規模で言語ペアが1つだけのプロジェクトなら、それで十分なこともあります。しかし、TBXが特に避けるように設計されている点でスプレッドシートは破綻します。

  • スプレッドシートには、用語に定義・使用上の注記・承認ステータスを付与する標準的な方法がなく、それらはツールが読めない自由記述のコメントになりがち
  • 言語ごとに1列というスプレッドシートは、言語数が少し増えただけでスケールしなくなり、言語追加のたびに全行の再構成が必要になる
  • スプレッドシート形式には、1つの用語エントリが1つの概念を表すことを強制する仕組みが何もなく、同じ英単語が2つの異なる意味で使われていても見分けのつかない2行になりがち
  • スプレッドシートは翻訳ツールに構造化された形で取り込めないため、用語チェックはそれに対して手作業で構築するしかなく、自動実行できない

小規模なプロジェクトにとってスプレッドシートが間違っているわけではありません。単に、他の何かがそれを読めるように作られていない形式だというだけです。TBXは、用語がツールによって強制される必要が出てきたとき、外部の翻訳者と共有する必要が出てきたとき、あるいはそのスプレッドシートを作った本人より長く信頼して使い続ける必要が出てきたときのために存在します。

関連記事