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

XLIFF とは — 翻訳作業の可搬性を支える交換フォーマット

XLIFF(XML Localization Interchange File Format)は OASIS の標準規格で、ある特定の問題を解決するために設計されています。翻訳作業は特定のツールの中で行われますが、そのテキストは最終的に、まったく別のシステムに戻さなければなりません。共通の交換フォーマットがなければ、原文フォーマットと翻訳ツールの組み合わせごとに専用の変換処理が必要になり、変換のたびにデータを失うリスクが生まれます。

XLIFF はその共通フォーマットです。原文ファイル(PO ファイルでも JSON のリソースファイルでも、ゲーム独自のテキスト形式でも)を置き換えるものではありませんが、原文が何であれ、翻訳者と翻訳ツールが一貫した構造の中で作業できるようにします。

構造 — file・unit・segment

XLIFF ドキュメントは入れ子になった XML です。1つ以上の file 要素があり、それぞれが unit を含み、各 unit が1つ以上の segment を含みます。unit はおおよそ「翻訳対象のメッセージ1つ」、segment はその中の文レベル・節レベルの断片で、メッセージより細かい単位で翻訳するツールにとって重要になります。

各 segment は source 要素(原文、決して書き換えない)と target 要素(訳文)を持ちます。原文を上書きせず、source と target を別々のペア要素として保持することが、往復変換を可能にする要点です。ファイルを XLIFF に変換し、また戻すツールは、正しい訳文が正しい原文の隣にあることを常に検証できます。

<xliff version="2.0" srcLang="en" trgLang="ja">
  <file id="dialogue">
    <unit id="tutorial.press_button">
      <segment>
        <source>Press %s to open your inventory.</source>
        <target>%s を押してインベントリを開く。</target>
      </segment>
    </unit>
  </file>
</xliff>

state 属性 — セグメントがワークフローのどこにいるか

翻訳は1ステップの作業ではありません。あるセグメントは未翻訳から翻訳済みへ、そしてレビュー済みへと進み、時には「要再確認」の状態に置かれます。XLIFF は target 要素の state 属性でこれを表現し、initial・translated・reviewed・final といった値を取ります。

これによって、プロジェクトが複数のツールと複数の人の手を経ても進捗を見失わずに済みます。翻訳メモリのシステムも、レビュアーのツールも、最終的な取り込み処理も、同じ state の値を読み、何がまだ残っているかについて合意できます。

インラインマークアップ

原文にはしばしば書式や埋め込みマークアップ(太字タグ、リンク、インラインアイコンの参照など)が含まれ、翻訳者がその構文を理解したり誤って壊したりすることなく、翻訳を経ても保持される必要があります。XLIFF は生のマークアップを翻訳対象テキストの中にそのまま残すのではなく、専用のインライン要素で表現します。

  • ph — 非テキストの内容(画像タグ、改行など)のプレースホルダー。翻訳者は移動できるが編集はできない
  • pc / sc / ec — 太字の範囲などマークアップの区間を表すペアまたは単独のコード。翻訳者は生のタグを見ずに、書式がどこから始まりどこで終わるかを把握できる
  • mrk — 訳してはいけない用語など、テキストの一部分に注釈を付けるマーク

ノート(注釈)

note 要素は unit や segment にコンテキストを添付します。翻訳者が必要とするが、テキスト自体には含まれない情報 — UI 上のどこに表示されるか、文字数制限、プレースホルダーの順序を変えてはいけないという注意など — です。ノートはパイプライン上のすべてのツールを通じて unit と一緒に運ばれます。これが重要な点で、表計算ソフトのコメントやチャットのメッセージにしか存在しないコンテキストは、ファイルの受け渡しの瞬間に失われてしまいます。

翻訳会社と CAT ツールがなぜここに収束するか

翻訳会社や CAT(コンピュータ支援翻訳)ツールは、多数のクライアントの、多数の異なる原文フォーマットを横断して扱います。交換レイヤーとして XLIFF を標準にすれば、何らかの形で XLIFF への変換・逆変換さえ用意されていれば、単一のツールがどんな原文フォーマットにも対応でき、クライアントの原文ファイルがどんな形であっても翻訳者の作業環境は変わりません。

これが最終的に守っているのは往復変換です。XLIFF に抽出され、翻訳され、また統合されたテキストが、翻訳された内容以外は元のファイルと構造的に同一になるという保証です。この保証があるからこそ、チームはパイプラインをそのたびに作り直すことなく、ツールやベンダーの間で翻訳作業を移動させられます。

関連記事