翻訳文中のリッチテキストタグ — マークアップを言語をまたいで壊さないために

ゲームのテキストの多くはプレーンテキストではありません。一行のセリフやツールチップには、キーワードを強調する色タグ、強調のための太字や斜体、発音を示すルビ、表示時にボタンのアイコンに差し替えられるトークンなど、インラインマークアップが含まれるのが普通です。こうしたマークアップはすべて翻訳を経ても有効なまま、ペアが崩れず、周りの言葉との位置関係も正しいまま残らなければなりません。

これは一般的な翻訳品質の問題よりも範囲が狭く、はるかに機械的な問題です。だからこそ、言語的なレビューとは切り離して扱う価値があります。

マークアップの実際の見た目

プロジェクトごとに具体的な構文は違っても、ゲームテキストのインラインマークアップはほぼ常に、テキストの範囲を挟むペアのトークンという形をしています。HTMLやBBCodeに近い形です。

You found a <color=gold>legendary sword</color>!
Press <icon=button_a/> to continue.
The <ruby=en>English</ruby> reading is shown above.

よくある壊れ方

翻訳者が意図せず引き起こすタグの崩れは、ほとんど決まった数種類のパターンに集約されます。

• 閉じ忘れ — 開始タグは翻訳文に残るが、対応する終了タグが落ちてしまい、それ以降の行すべてが書式を引き継いでしまう
• ネストの順序崩れ — タグが入れ子になっている場合、翻訳で語順が変わりすぎて、終了タグ同士が開いた順の逆にならず交差してしまう
• タグ名や属性の翻訳 — 急いで作業する翻訳者が、周りの文章と一緒にタグの中身の単語まで訳してしまい、コードが探しているトークンを壊してしまう
• タグの内側に入り込んだ余分な空白 — タグを打ち直す際に紛れ込んだスペース(<color = gold> のような)は目には見えにくいが、厳密なパーサーには無効な記述になる
• タグが違う範囲を囲んでしまう — 翻訳文で語順が変わり、本来強調すべき単語とは違う単語をタグが囲んでしまう

翻訳者に先に伝えておくべきルール

短く明確なルールを事前に渡しておくことで、事後に見つけるのではなく、そもそも起きないようにできます。

• 山括弧などのタグの区切り文字の内側は、単語のように見えても絶対に翻訳しない — タグの中身は文章ではなくコードである
• 翻訳文の各行で、すべての開始タグに対応する終了タグが、開いた順と対応する相対的な順序で存在しなければならない
• 語順が変わった場合、タグのペアを違う単語に移動させるのは問題なく、むしろ必要なことが多い — ただしペアは必ず一緒に移動させる
• タグの区切り文字のすぐ内側にスペースを追加したり削除したりしない

このチェックが機械的で低コストである理由

トーンや自然さの判断とは違い、タグの整合性を確認するのに対象言語を理解する必要は一切ありません。翻訳文が、ソース文と同じ集合のタグを、正しくペアになりネストされた状態で持っているかどうか — これは一定時間で判定できる構造的な比較であり、スクリプトがすべての文字列、すべての実行で行えます。

だからこそタグの整合性チェックは、QAパイプラインの中で費用対効果が最も高い自動チェックの一つになります。実行コストはほぼゼロで、判断に迷う余地もなく、それでいて、スプレッドシートのレビューでは見えず画面に表示されて初めて分かるという種類のバグを確実に拾い上げます。