翻訳者に文脈を渡す — 費用対効果が最も高いQAへの投資

後になって発覚するローカライズ品質の問題 — 話しているキャラクターと語調が合っていないセリフ、文法的には一文になってしまっているボタンラベル、警告文なのに落ち着いた口調で訳されてしまったテキスト — の多くは、同じ原因にたどり着きます。翻訳者は、原文を書いた人が見ていたものを見ていない、ということです。文字列のスプレッドシートはゲームそのものではなく、ゲームから言葉以外のすべてを取り除いたものです。

これは「もっと良い翻訳者を雇えば解決する」という品質の問題ではなく、文脈の問題です。そしてこれは、受け渡しを準備する側が完全にコントロールできるレバーです。

文字列テーブルが削ぎ落とすもの

スプレッドシートの一行やJSONの一つのキーが運んでいるのは、テキスト本体と、運が良ければキー名くらいです。それ以外の、ゲーム内でのそのテキストの「生活」— 誰が話しているか、どんな感情の register か、どの画面か、隣に何が表示されているか、表示できる余白がどれくらいか、プレースホルダーが実行時に何に展開されるか — はすべて、原文を書いた側には暗黙のうちに存在していて、翻訳者には見えていません。

これらはどれも「あれば助かる」程度の付加情報ではなく、原文の書き手が意識的にせよ無意識にせよ持っていた情報です。それなしでの翻訳は近道ではなく、推測です。

具体的に何を渡すか

すべての文字列を網羅的にドキュメント化するのが目標ではありません — そのコストはほとんどの場合見合いません。目標は、翻訳の結果を変える文脈だけを添付し、変えない文脈は省くことです。

• 話者とシーンのメモ — 誰が、誰に向かって、どんなトーンで話しているセリフか(同じ言葉でも、鬼教官が怒鳴る場合と穏やかに言う場合ではまったく違う訳になります)
• 実際のUI上での表示位置がわかるスクリーンショットや短い動画
• 文字数・バイト数の上限を、文字列ごと・UI枠ごとに明示する。翻訳が入り切らないと発覚してから翻訳者に発見させるのではなく
• 各プレースホルダーが何に展開され、文法的にどんな役割を持つか — プレイヤー名とパーセンテージとアイテム個数では、数に応じて文法が変わる言語では別問題になります
• その文字列がUIラベルなのか、ボタンなのか、完結した文なのか — 多くの言語でボタンは命令形か名詞句で訳され、判断を誤るとある言語では命令文、別の言語では説明文になってしまいます

具体例

プレースホルダーだけの文字列を例に取ります。文脈がなければ解けません。

"key": "ui.button.craft_item",
"source": "Craft {0}",
"note": "{0} = アイテムの表示名(名詞)。これは文ではなくボタンのラベル。"

完璧な受け渡し資料より、機能するQ&A窓口

どんな受け渡し資料も、すべての疑問を先回りすることはできません。それを目指すと大抵、資料自体が読まれなくなります。実際に手戻りを防ぐのは、共有スレッドやチケット、チャットのような「生きている」窓口で、翻訳者が「ここの{0}は何に展開されますか」と聞いて、次のマイルストーンではなくその日のうちに答えが返ってくることです。

この窓口を用意しないチームは、質問が減るわけではありません。「聞かれない質問」と「静かに立てられた仮定」が増えるだけです。その仮定は後になってレビューの場で、まとめて見直しが必要な文字列の山として表面化します — これは最初に一度質問に答えるより、はるかにコストがかかります。

推測のコスト

文脈が与えられなくても、翻訳者は何かを納品しなければなりません。締め切りは文脈を待ってくれないからです。その結果できあがるのは、それらしい推測です — 文法的には正しく、トーンもそれなりに妥当で、しかし実際に使われる場面としては単に間違っている、ということが起こります。この推測は翻訳工程を通り、多くの場合、最初のレビューも通過します。同じスプレッドシートしか見ていないレビュアーには、翻訳者以上の文脈がないからです。

この誤りが見つかるとすれば、実際のビルドをプレイした誰かによってです。その時点で修正するには、該当の文字列を再び探し出し、翻訳し直し、一度通過したレビュー工程をもう一度回すことになります。受け渡し時に一度渡しておく文脈は、この際限のない後追いの発見を、翻訳者が最初から正しく訳すことに置き換えます。