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

Godotのローカライズの仕組みは、頭の中で把握しやすい考え方でできています。翻訳はキー1列と言語ごとに1列を持つ表として存在し、それをエンジンにインポートし、表示時にコードはキーを渡して翻訳関数を呼び出すと、現在アクティブなロケールに応じた文字列が返ってきます。あるコントロールでロケールを切り替えたときにテキストが自動で更新されるなら、この仕組みがきちんと働いている証拠です。更新されないなら、その文字列はキー経由で参照される代わりに一度だけリテラルとしてセットされてしまっている可能性が高いです。

インポート設定の具体的な項目や列の命名規則、翻訳関数のシグネチャはGodot自身のドキュメントに記載されており、記憶に頼った又聞きの説明よりも直接読む価値があります。この種の細部は記憶違いが起きやすいためです。ここから先で扱うのは、キーと文字列を結びつける具体的な仕組みが何であっても変わらない部分です。

キーは英語テキストではない

特にCSVベースの仕組みでは、英語の原文そのものをキーとして使いたくなります。最初の列にすでに読みやすい文字列が並んでいるのだから、もう1列増やす必要はないのでは、と。この問題が表面化するのは、英語の文言のタイポを直したり言い回しを変えたりする最初のタイミングです。キーもそれに合わせて変わってしまい、その行の翻訳列すべてが孤立します。コード上のどこにも存在しなくなったキーに、静かに切り離されてしまうのです。

代わりに、テキストが登場する場所ごとにグループ化した短く安定した識別子を使い、英語テキストは行の識別子ではなく表の中のただの1列として扱ってください。

key,en,ja
ui.settings.title,Settings,設定
dialogue.ch1.guard01.line03,"Halt! Who goes there?","止まれ!何者だ?"

1つのCSV、単一の原本

CSVベースの翻訳表には実際の利点があります。エンジニアと翻訳者の両方が開ける単一のファイルであり、各言語のカバー率が一目でわかります。空セルは未翻訳を意味し、列を眺めるだけで即座に見つけられます。この状態を崩さないよう、翻訳をシーンやスクリプトの中に散らばった文字列に分散させないでください。プレイヤーに見えるテキストは1つにつき置き場所も1つだけであるべきで、それは表であるべきです。`Label`ノードのデフォルトテキストや、たまたま原語では正しく表示されているスクリプト中の文字列リテラルであってはいけません。

コメントや別途のメモ列は、インポート処理が無視するものであっても作業用のファイルには残しておく価値があります。どのキャラクターのセリフか、どの画面で表示されるか、口調は緊急なのかくだけているのかといった、キーだけでは自然に伝わらない文脈を補うためです。

プレースホルダーと複数形

プレイヤー名、個数、場所などパーツを組み合わせて作る文字列には、翻訳者が信頼して並べ替えられる書式の規約が必要です。どのプレースホルダー記法を採用するにせよ、ルールはどのエンジンでも同じです。翻訳者はその言語の語順に合わせてプレースホルダーの位置を動かしてよく、むしろ動かすべきですが、トークンの名前を変えたり削除したり重複させたりしてはいけません。反対側のコードはそのトークンを厳密に照合しているからです。

複数形は後回しにせず、キー設計の段階で本気で考える必要があります。英語には複数形のルールが1つしかありませんが、多くの言語には単純な単数/複数の区別ではなく、正確な数量に応じた複数のカテゴリがあります。複数形を考慮しない構造の1本のフラットな文字列では、翻訳がどれだけ上手でも、それを正しく表現する手段が翻訳者には与えられません。

フォントとグリフの網羅

Godotはコントロールに割り当てられたフォントリソースを通じてテキストを描画し、そのフォントは実際に含まれているグリフしか描けません。現在のフォントがカバーしていない文字体系の言語 — 一般的なデフォルトフォントに対する日本語、韓国語、アラビア語など — を追加すると、足りない文字は空白の四角として表示され、エラーにはなりません。そのため、実際に誰かがその言語でその画面を見るまでは気づかれません。

これは実行中のシーンで、対象言語の実際の(あるいは現実的な長さの)テキストを使って直接テストしてください。メニュー、セリフ、特定のラベルに割り当てたカスタムフォントを含め、すべてのUI要素と使用フォントが対象です。単体のフォントプレビューだけでは、実際のレイアウトの中でどう振る舞うかはわかりません。

文字数の増減とロケールの選択

英語テキストに合わせて調整されたコンテナサイズやラベル幅は、翻訳されるとそのままでは崩れます。多くの言語は同じ意味でも意味のある差で長くなり、CJKのテキストは文字数としては短くなることが多い一方、1文字あたりの幅は広くなります。伸縮できるレイアウトを作り、本物の翻訳が来る前に対象言語の現実的な長さに合わせたダミー文字列でテストしておくと、翻訳バッチが届いた後ではなく早い段階でオーバーフローの問題を見つけられます。

ロケールの選択自体も意図を持って設計すべきです。システムからそれらしい初期ロケールを検出しつつ、プレイヤーが明示的にゲーム内で上書きできる手段を必ず用意してください。自動検出が誤ることは珍しくなく(共用のパソコンだったり、ゲームの好みとは無関係な理由で言語が設定されていたり)、プレイヤーが自分の設定画面すら読めない状態に閉じ込められることがあってはなりません。

• すべての文字列に安定したキーがあり、シーンやスクリプトに直書きされず翻訳表に存在する
• プレースホルダーは目視ではなく自動チェックで検証されている
• フォントは単体プレビューではなく実行中のシーンで対象文字体系ごとに確認されている
• 本物の翻訳が来る前に、現実的な長さの文字列でレイアウトをテストしている
• プレイヤーはシステム検出任せにせず、明示的にアクティブなロケールを変更できる