AIゲームローカライズ
Updated 2026-09-05
つながりのない文字列一覧ではなく、プレイヤーの一連の体験を翻訳します。安定した識別子から始め、ゲームプレイの意味を保ち、エクスポートしたゲーム内で結果をレビューします。
プレイヤーが実際に遭遇する文字列を抽出する
タイトル、設定、チュートリアル、ゲームプレイのフィードバック、勝敗、再開を含む一つの完全な体験から始めます。会話だけでなく、エラーメッセージとセーブの確認も含めてください。すべてのメッセージに安定したキーを与えれば、翻訳者がどの同一英語表現を意図したか推測せずに修正できます。
画面、話者、操作、トーン、スペースの制約をテキストのそばに保存します。chargeという語は価格、攻撃、蓄積エネルギーを指す可能性があります。短いコンテキスト欄があれば、その曖昧さがバッチ全体に広がるのを防げます。識別子を文章から分離し、英語の表現が変わっただけでキーを改名しないでください。
クリーンなGodotソーステーブルを準備する
Godotでは、固有キーと言語列を持つCSV翻訳入力が文書化されています。アンダースコアで始まる列にはコメントを入れられます。以下の例はオリジナルの英語ソース用フィクスチャです。翻訳レビュー後に対象ロケールの列を追加します。引用符、カンマ、改行を維持できるよう、CSV対応のエディタまたはパーサーを使ってください。
操作、アイテム、繰り返し登場するメカニクスの用語集を用意します。どの用語が名前で、どれを適応してよいか翻訳者に伝えてください。バッチの前にソースリビジョンを固定し、その後の変更をキー単位で追跡します。これにより、承認済みの行をすべて再生成するのではなく、変更されたメッセージをレビューできます。
keys,en,_context
MENU_START,Start game,Title screen action
MENU_RESTART,Restart round,Shown after win or loss
SCORE_TOTAL,Score: {score},HUD; preserve the named placeholder
SAVE_FAILED,Progress could not be saved.,Error after a failed saveプレースホルダーとゲームプレイの事実を保護する
変更可能なテキストと、ゲームが実行時に挿入する値を分けます。Godotでは名前付きフォーマット引数を持つ翻訳文字列に対応しており、変数を維持したまま文の順序を翻訳者が変えられます。以下の例は翻訳リソースが設定済みで、score_labelが既存のLabel参照であることを前提にしています。
プレースホルダーの集合、必須キー、指示に埋め込まれた数値、プロジェクトで使うマークアップを検証します。人間のレビュアーには意味を独立に確認してもらいます。構造的に有効な翻訳でも、操作指示を逆にしたり目標を変えたりする可能性があります。構造チェックと言語承認を別の結果として扱い、それぞれの失敗が適切なレビュアーに届くようにします。
score_label.text = tr("SCORE_TOTAL").format({"score": score})コンテキストごとに翻訳し、難しいメッセージをレビューする
関連する画面や会話をまとめて、モデルが用語と語り口を保てるようにします。各バッチにはソースのコンテキスト、承認済み用語集、保護されたトークン、対象読者を渡してください。元の識別子をキーにした構造化出力を求め、マージ前に不足または想定外の項目を却下します。
曖昧なメカニクス、ユーモア、キャラクターの声、文化的に慎重なテキストは、能力のある言語レビュアーへ回します。短いボタンラベルは、使える空間が小さいため、長い説明文より判断が必要なことがあります。適切な場合はレビュアーの修正を用語またはコンテキストの更新として保存し、次のバッチで同じ誤解を繰り返さないようにします。
翻訳をインポートして登録する
インポート後、GodotのProject Settings、Localization、Translationsで意図した翻訳リソースを確認します。CSVファイルが存在するだけで登録に成功したと判断しないでください。エンジンのバージョンに対応するドキュメントを使い、実際のリソース一覧を確認します。
実行中のプロジェクトで言語を切り替え、新しいキーを使う画面を訪れます。キーがそのまま表示されるなら、キーの綴り、リソース登録、選択したロケールを調べます。テキストが消えるなら、フォントと必要な字形のカバレッジを確認します。正しい翻訳もビルドで描画できなければ役に立たないため、フォントの権限とフォールバックの選択をアセット記録とともに保持してください。
すべてを翻訳する前にレイアウトに負荷をかける
Godotの疑似ローカライズツールを使い、レイアウトの前提を早期に明らかにします。その後、同じ画面で実際にレビュー済みの対象言語文字列をテストします。長いラベル、複数行、右から左への並び、句読点、数字の混在は、ソース言語のスクリーンショットでは見えない問題を明らかにします。
サポートする最小ウィンドウサイズと意図した入力方式で操作をレビューします。ラベルが隣の操作部を覆わず読みやすいこと、プレイヤーが重要な操作へ到達できることを確認してください。スプレッドシートだけでなく、プレイの一部として会話の進行と字幕のタイミングをテストします。視覚的な判断が必要な問題には、実際のビルドのスクリーンショットを保持します。
ストアコピーと対応言語を一致させる
承認済みの機能インベントリからストア説明を翻訳します。インターフェースのテキスト、字幕、音声対応を分けて追跡し、ストアの表現をビルドが実際に提供する内容と一致させます。魅力的なローカライズ説明によって、未出荷のモード、プラットフォーム、アクセシビリティ機能を約束しないでください。
Steamには独自のローカライズワークフローと言語設定があります。提出前に、ゲームのリリースパッケージと照合してください。現在のContent Surveyレビューに向けて、プレイヤー向けのAI支援翻訳を製品の寄与インベントリに含めます。ストア公開はローカライズファイルの準備とは別の操作なので、レビューと公開の責任を明確に保ちます。
ローカライズした体験を承認し、その差分を維持する
対象ロケールごとに、選択したプレイヤー体験を完全なラウンドまで実行し、設計どおりに言語設定を保持した状態で再起動します。ソースリビジョンとビルドに対して、キーの欠落、フォーマット不具合、視覚的問題、意味の修正を記録します。関係するレビュアーがそれらを解決した場合にだけロケールを承認します。
後の更新では、ソースの意味が変わった翻訳を無効にし、変更のない承認済みエントリは保持します。このガイドはドキュメントに基づく手順と例示フィクスチャを提供するもので、実行済みのローカライズ結果を報告するものではありません。全スクリプトや追加言語へ広げる前に、この小さな体験を最初の検証範囲にします。
よくある質問
ゲーム全体のスクリプトを一つのリクエストで送るべきですか?
まとまりのあるシーンまたは画面と共有用語集から始めます。返されたキーを検証し、バッチを広げる前にプレイヤーの一連の体験をレビューしてください。
モデルに翻訳キーを改名させてもよいですか?
キーは安定させ、編集可能なテキストから分離します。翻訳の副作用ではなく、意図したコードとコンテンツの移行としてのみ改名してください。
ゲームに翻訳ではなくキーが表示されるのはなぜですか?
選択したロケール、正確なキー、登録済みの翻訳リソースを確認します。プロジェクト内にCSVファイルがあるだけでは、問題の診断には不十分です。
疑似ローカライズで翻訳品質を証明できますか?
レイアウトとローカライズの問題を見つけやすくします。対象言語の実際の意味には、言語レビューとゲーム内テストがなお必要です。
ストアの言語に関する主張は翻訳スプレッドシートに従うべきですか?
テスト済みビルドに従うべきです。インターフェース、字幕、音声を分けて追跡し、ストア設定と照合してください。