新規登録
実装Read this article in English

Unreal Engineでのゲームローカライズ — 最初に押さえておくこと

Unreal Engineのローカライズワークフローは、収集(gather)・翻訳・コンパイルというサイクルを軸に組み立てられています。エンジンがプロジェクト内のプレイヤー向けテキストをスキャンして翻訳ファイルにまとめ、翻訳者がそのファイルを作業し、結果がコンパイルされてランタイムがアクティブなカルチャー(言語・地域設定)ごとに読み込む形に戻ってきます。この流れの具体的なコマンドやエディタのパネル、ファイル構成はEpic Gamesのドキュメントに記載されておりエンジンのバージョンによって変わるため、仕組みそのものについてはそちらを一次情報として扱ってください。

より変わりにくく、どのバージョンや引き継いだプロジェクトでも理解しておく価値があるのは、そのサイクルがそもそもなぜ存在するのか、そしてテキストがそこをきれいに通過するために何が成り立っている必要があるのかという部分です。この記事ではそこに焦点を当てます。

そもそも「収集できる」テキストである必要がある

収集ステップは、そもそもローカライズ可能なテキストとして公開されているものしか見つけられません。コードの中で連結された生の文字列や、テクスチャに焼き込まれたテキスト、出荷する気のないデバッグ文字列は対象外です。Unreal のシステムを使うスタジオは最終的に、どの文字列が本物のプレイヤー向けコンテンツで、どれが内部専用なのかを区別する規約を持つことになりますが、その規約はローカライズを意識したエンジニアだけでなく、UIやセリフのシステムに触れる全員に一貫して適用される必要があります。

これはどのエンジンでも必要になる同じ基本原則を、Unrealの用語で表したものです。あるテキストは概念的に「名前空間(namespace)」に属し、その中に「キー」を持ちます。そのため同じキーでも異なる名前空間の下であれば衝突しません。また同じ原文であっても編集を重ねながら追跡・再追跡でき、翻訳履歴を失わずに済みます。それを宣言する正確なAPIはバージョンによって変わってきたので、推測せずEpic社のドキュメントで確認する価値があります。

文字列テーブルとローカライズファイルの形

概念的には、文字列テーブルはキーとテキストを対応させるものであり、どのエンジンのどんな文字列テーブル型システムでも同じ発想です。プロジェクトごとに違ってくるのはキーの粒度です。粗すぎる(セリフのひとかたまりを1つのキーにする)と部分的な修正を段階的に翻訳することができなくなり、細かすぎる(単語ひとつごとにキーを分ける)と翻訳者が自然な文を作るために必要な文脈を奪ってしまいます。妥当な落としどころは、完結した1行、あるいは完結した1つのUI文字列につき1キーとし、それが属する画面やシーンでグループ化し、キーだけでは翻訳者が推測できない文脈をコメントやノート欄で添えることです。

  • 完結した翻訳単位ごとに1キー — 文の断片ではなく完結した1行単位
  • 画面・クエスト・キャラクターなど関連するまとまりでキーをグループ化
  • 文脈だけで意味が曖昧になる文字列にはノートを添える
  • 英語のテキストがたまたま一致していても、意味が違う2箇所で同じキーを使い回さない

カルチャーごとにコンパイルされるローカライズデータ

翻訳が終わると、Unrealは原文と翻訳をビルドに同梱されるローカライズデータへとコンパイルし、実行時にアクティブなカルチャーに応じて読み込みます。計画を立てるうえで実務的に重要なのは、ローカライズデータは単なるバラバラのファイル群ではなくビルド成果物だということです。つまり翻訳を更新しても、多くの場合コンパイルとパッケージングの工程を経なければ実行中のビルドには反映されず、ある言語をテストするというのは実際にパッケージ化・コンパイルされた状態をテストすることを意味します。ファイルを編集すればどこでも即座に反映される、というわけではありません。

プロジェクトの具体的なツールチェーンが何であれ、アップデートの運用サイクルにこのコンパイル工程の時間を組み込んでおいてください。出荷済みのデータに再コンパイルされない翻訳修正は、プレイヤーにとっては修正されていないのと同じです。

プレースホルダー・書式・複数形

パーツを組み合わせて作るテキスト(`Player {playerName} dealt {damage} damage` のような形)には、翻訳者がプレースホルダーの名前を変えたり削除したりすることなく、自分の言語の文法に合わせて順序を並べ替えられる書式の仕組みが必要です。書式システムの具体的な記法が何であれ、この原則は変わりません。プレースホルダーは文章ではなく、コードと翻訳の間の契約であり、両者は常に厳密なトークンとして一致していなければなりません。

複数形は単純なプレースホルダー置換とは別に注意が必要です。多くの言語は英語の単数/複数という2区分よりも多くの文法的な複数カテゴリを持っており、複数形のサポートがキー構造に組み込まれていない、フラットな1本の文字列だけを渡された翻訳者には、それを正しく表現する手段がありません。

フォント・グリフの網羅・文字数の増減

ここから先はUnrealに固有の話ではありません。フォントアセットはそこに含まれるグリフしか表示できないため、デフォルトのフォントが想定していなかった文字体系 — CJK、キリル文字、右から左に書く文字体系など — にはそれをカバーするフォントが必要で、フォントのプレビューパネルではなく実際にゲーム内でレンダリングされた文字を見て確認する必要があります。また英語のテキストにぴったり合わせて作られたUIは、翻訳された瞬間にはみ出したり切れたりします。ほとんどの言語は同じ意味でも英語より意味のある差で長く、あるいは幅広くなるからです。どちらの問題も、実際に(あるいは現実的な長さのダミーであっても)その画面に文字列を入れてみるまでは見えません。

あるカルチャーを「完了」と判断する前に確認すること

収集・翻訳・コンパイルのサイクルは、テキストがパイプラインを一通り通過したことは教えてくれますが、その結果が正しいことまでは保証してくれません。ある言語を出荷する前に、直接確認してください。

  • 収集されたすべての文字列が、キーを失うことなく翻訳を往復している
  • 翻訳文中のプレースホルダーが原文と厳密に一致している(順序の入れ替えは可)
  • コンパイル済みビルドが対象のすべての文字体系をグリフの欠落なく表示している
  • 英語ではなく実際の翻訳文の長さでUIが崩れないことを確認している
  • 実行時にアクティブなカルチャーを切り替えると、セッション中に以前キャッシュされた画面も含めてすべての画面が更新される

関連記事