多言語対応を前提に設計する — 作り始める前に決めておくこと

いまゲームを企画している段階だとします。企画書があるかもしれないし、プロトタイプがあるかもしれないし、アイデアとフォルダしかないかもしれません。翻訳の話は、いつか来るかもしれない未来の自分の問題に見えます。実際、1言語のまま出して十分うまくいくゲームはいくらでもあります。その判断自体はまったく合理的で、この記事はそれに反対するものではありません。

厄介なのは、翻訳を安く済ませるか、それとも作り直し級の出費にするかを決める分岐が、翻訳のことなど考えていない企画・設計の段階で通過してしまう点です。テキストをどこに置くか、UIが文字の長さについて何を前提にしているか、どのフォントに惚れ込むか、絵の中に文字を焼き込むか。どれも、翻訳しやすい方向に倒すコストはほぼゼロで、あとから逆向きに直すと相応の改修になります。

つまりこれは、予算を確保しろとか対応言語を決めろという話ではありません。開けたままにしておく扉のリストです。この習慣で作られたプロジェクトは数週間で1言語追加できますが、そうでないプロジェクトは、最初の1文が訳される前に全シーンに手を入れる作業が要ることがあります。

1言語しか出さなくても、テキストはコードの外に出す

このリストで最も価値が高い決定であり、しかも仕組みではなく習慣です。プレイヤーが読む文字列は、使う場所に直接書かない。安定したキーの下でテーブルかリソースファイルに置き、コードはキーで問い合わせる。初日から始めれば1文字列あたり数秒の手間です。2万行書いたあとから始めると、終わりの見えない発掘作業になります。コードの中では、プレイヤー向けの文とログ用の文字列とデバッグ表示を機械的に区別する手がかりが、どこにもないからです。

この恩恵は、翻訳よりずっと早く回収できます。誤字をソースコードから探し回らずに直せます。ゲームが表示するメッセージを一覧で見られるので、同じ警告を微妙に違う言い回しで3回書いていたことに気づけます。文字数もいつでも数えられます。これは、いつか翻訳の見積もりを取るときに最初に聞かれる数字です。書き手とプログラマが別人なら、書き手はコードに触れずに作業できます。

形式の選択は、習慣ほど重要ではありません。CSVでもJSONでもエンジン標準の文字列テーブルでも構いませんし、形式の移行は、コードから文字列を掘り出す作業に比べればはるかに簡単です。大事なのは、最初のコミットの時点で「プレイヤー向けの文が置かれる場所は1か所だけ」と決まっていること、そしてデバッグ用の文字列をそこに混ぜないことです。

対応言語は「約束」ではなく「制約」として仮決めする

中国語版を出すと決める必要はありません。出す可能性があるかどうかを把握しておけば十分です。企画段階で書き出すこのリストは予算項目ではなく、他のいくつもの決定を静かに左右する技術的制約です。書くコストは企画書の1段落です。

早い段階で効いてくる性質は3つです。1つ目は文字の収録範囲。候補に中国語・日本語・韓国語が入るなら、必要なフォントの規模も描画の設計も桁が変わります。2つ目は文字数の増減。日本語や英語からドイツ語やロシア語に訳すと目に見えて長くなり、逆に日本語版はかなり短くなることが多いので、UIは両方向に耐える必要があります。3つ目は書字方向。アラビア語やヘブライ語は右から左に書き、インターフェース自体を左右反転させる必要があります。この記事で扱う中では、あとから対応するのが最も高くつく性質です。

だから、正直な形で書いてください。ありうる言語、可能性が低い言語、そして明確に対象外とする言語。企画段階で「右から左に書く言語は本作では対象外」と決めるのは、まっとうで説明可能な判断です。発売2か月前にパブリッシャーから聞かれて初めて気づくのは、そうではありません。

フォントは見た目の話ではなく、パイプラインの話

1言語しか出さないなら、表示用フォントを後回しに決めるのは普通のことです。別の文字体系が視野に入った瞬間、それは普通ではなくなります。ラテン文字だけのフォントと日本語を収録したフォントでは、ファイルサイズも、ライセンス条件も、配布時に埋め込めるか・サブセット化できるかも大きく違います。手描きの凝った表示用書体は、キリル文字や漢字を表示できる版がそもそも存在しないこともあります。

UIがまだラフの段階で答えておく価値がある問いは3つです。インターフェース用のフォントは仮決めした言語の文字体系をカバーする必要があるのか、それとも言語ごとにフォントを差し替えるのか。収録されていない文字が来たときに何が起きるのか(フォールバックの連鎖があるのか、プレイヤーに空の四角が見えるのか)。そして、そのフォントのライセンスは商用ゲームへの埋め込みを許可しているか、必要ならサブセット化を許可しているか。

ドット絵向けのピクセルフォントには特に注意が要ります。インディーでの採用率が高く、そして収録文字が狭いことが多いからです。英語向けに作られたピクセルフォントには日本語の文字が1文字も入っていないのが普通ですし、漢字を収録したものにも、判読できる最小サイズがあり、それがUIの想定より大きいことがあります。ドット絵の見た目が作品の核なら、アートを固めたあとの「テキストの問題」として先送りせず、早い段階で決着させてください。

伸び縮みするUIを作り、絵に文字を焼き込まない

どの文字列も、設計時に想定したものよりかなり長く、あるいはかなり短くなりうると考えてください。固定幅の箱に入れるのではなく自分で幅を決めるラベル、何かを覆わずに次の行へ折り返せるテキスト領域、特定の行に特定の文字数が収まる前提に依存しないレイアウト。要するに一般的なレスポンシブ設計の作法ですが、言語が1つで全文字列が既知だと、つい省略されます。

これは翻訳が1文字もない段階で検証できます。インターフェースを水増しした仮テキスト(同じ文言に余分な文字とアクセント付きの文字を足したもの)で埋め、全画面を見て回り、はみ出しと重なりを探します。これは擬似ローカライズと呼ばれる手法で、翻訳者も予算も使わずに、設計段階でレイアウトの破綻を見つけられるところに意味があります。

もう半分は、画像に焼き込まれた文字です。ロゴ、看板、チュートリアル図、文字を描き込んだボタン。これらは1つにつき言語分の書き出し作業になり、しかも作業できるのは元データを持っている人だけです。テーブルの1行を編集するのとはコストの性質が違います。素材を作るたびに判断してください。これはプレイヤーが読む文字で、翻訳が必要になるものか。それとも文字の形をした装飾か。本当に文字であるものは、画像に描き込むのではなく、画像の上にエンジンで描画します。

キーの命名は最初に一度だけ決める

キーの命名規則を決めるのは最初なら5分ですが、あとから変えるのは本当に面倒です。改名は全言語ファイルで同時に適用しないと、訳文が対応する文字列から静かに外れてしまうからです。多少下手な規則でも致命傷にはなりませんが、規則なしで成り行きに任せると、ずっと不便が続きます。

押さえるべきは2点です。階層構造にすること。関連する文字列が並んで見え、どの画面のキーなのかが一目で分かります。そして、原文の文言から機械的に作らず、意味で名付けること。英語や日本語の文面から作ったキーは、その文面を書き直した瞬間に改名が必要になります。改名こそが避けたい操作です。

命名規則と合わせて、ファイル構成も決めておきます。言語ごとに全キーを含む1ファイルにするか、言語ごとのフォルダを機能単位で分割するか。どちらでも動きます。困るのは規則がないことで、半年後に内容が一部重複した3つのファイルが存在し、どれが正なのか誰にも分からなくなります。

# 安定・階層的・意味ベース。文言を直しても変わらない
ui.shop.button.buy
ui.shop.error.insufficient_gold
dialogue.ch01.mira.greeting_first

# 原文の文言から作ったキー。書き手が一文直すたびに改名が必要になる
buy_this_item_now
not_enough_gold_error

後回しにすると実際に何が起きるか

ここは具体的に書く価値があります。「あとで対応する」は作業を先送りしているように聞こえますが、実際には習慣をプロジェクトに交換しているからです。最初からやれば、上記はすべて、普通に開発しながら守る小さな取り決めの集まりです。あとからやると、終わりの見えない一連の仕事になります。コードベース中の直書き文字列をすべて見つけ、文を断片から組み立てている箇所を発見して設計し直し、元の言語の文字数を前提にしたUIを作り直し、文字入りの素材を言語分書き出し、そして全画面に触ったので全画面をテストし直す。

作業量より厄介なのは日程です。この作り直しが穏やかな月に行われることはまずありません。発売日が決まっているとき、翻訳者が着手を待っているとき、パブリッシャーが対応言語をすでに告知したときに起きます。つまり、プロジェクトで最も後戻りしにくい改修が、最も時間に追われた状況で行われます。

これは「必ず多言語対応すべきだ」という主張ではありません。選択肢を開いたままにしておくコストが、企画段階ではほぼゼロだという話です。そして、それがゼロで済む期間は、プロジェクトの中でこの時期しかありません。

だから、企画書に他に何も書き残さないとしても、以下のリストだけは書いてください。1ページに収まりますし、どれも「2つ目の言語が来るかどうか」を知らないまま今日決められる項目です。

• プレイヤーが読むテキストは、最初のコミットからキー付きの外部ファイルに置く
• デバッグ・ログ・開発用の文字列は、意識的にそのファイルから除外する
• 仮の言語リストがある(ありうる/可能性が低い/明確に対象外の3分類)
• フォントがそのリストの文字体系をカバーし、未収録文字が来たときの挙動も決めてある
• フォントのライセンスが商用ビルドへの埋め込みを許可している
• 文字数を固定前提にしたUI要素がない(すべてのラベルが折り返しまたは可変幅)
• プレイヤーが読む必要のある文字は、画像に描き込まず、テキストとして描画する
• キーの命名規則とファイル構成を、2人目が参加する前に文書化する
• 実行時に文を断片から組み立てない。変数は名前付きのプレースホルダを使う