リリース前日、最後にチェックすべきローカライズ項目

ローカライズのバグの多くは開発中に見つかります。出荷まで残ってしまうバグは、たいてい最後の1週間で誰もチェックしようと思わなかったものです。この時期は関心がすでにビルドの安定性やストア審査の方に移っているからです。ここでは、その最終チェックのための具体的な項目と、それぞれがリストに入る理由をまとめます。

ビルドと起動

これらは判断の余地がない合否チェックなので、本来は最終段階でも一番安く拾えるはずの項目です。ただし「ビルドが通った」ことと「その言語できちんと動く」ことは別で、誰かが実際に各言語で起動して確認して初めて成立します。

• 対応するすべての言語が、対象のすべてのプラットフォームでビルドされ起動する — ある言語専用のアセットやフォントの読み込み失敗は、その言語のビルドだけをクラッシュさせることがあり、テスト時間が限られているとその言語だけ見落とされがち
• ゲーム内メニューだけでなく、プラットフォームが宣言する端末の言語設定に基づいて正しい言語が起動時に読み込まれる — 設定画面を一度も開かないプレイヤーも、初回起動でシステム言語が表示されるべき

最初の1時間

プレイ開始から最初の1時間は、不釣り合いなほど多くの人の目に触れます。配信者が見せる部分であり、レビュー用ビルドの評価対象であり、プレイヤーが続けるかどうかを決める材料です。オープニング、チュートリアル、序盤エリアのセリフにある未翻訳テキストや仮文言は、20時間目の同じ問題よりはるかにダメージが大きいものです。

• オープニングの流れのどこにも、仮文言(lorem ipsumやTODO、ui.button.confirmのようなデバッグキー)がそのまま表示されていない
• チュートリアルの案内やオンボーディングのテキストが完全に翻訳されている — ゲーム全体の中で最も読まれる可能性が高いテキスト

外部との整合性

プレイヤーの体験はタイトル画面から始まるわけではありません。ストアページから始まります。ストアが約束する内容とゲームが実際に提供する内容にズレがあると、両方とも個別には正しくても「雑に作られている」という印象を与えます。

• ストアページの用語(アイテム名、機能名、モード名)がゲーム内の実際の表記と一致している — ストア用のコピーを書いた後に機能名が変更された、というズレが起きやすい典型例
• マーケティング用のスクリーンショットや予告編が、初期の下書きではなく出荷版の訳文を反映している

表示と書式

この種のバグは、自分の言語だけでテストしていると見えません。自分の言語の書式は、自分にとってはデフォルトで「正しく」見えてしまうからです。

• 対応するすべての言語で使われる文字を、句読点や特殊記号も含めてフォントが表示できる — 文字が表示されない四角(いわゆる豆腐)は、最も目立つローカライズ失敗の一つ
• 日付・時刻・数値の書式が、単一の決め打ち形式ではなく、各ロケールの慣習(日付の並び順、小数点・桁区切り記号)に従っている
• 各言語で最も長くなる文字列でも、UIレイアウトが省略や重なりなしに保たれる — ドイツ語やフィンランド語は、同じ意味でも英語より文字数が多くなりやすい

ローカライズに関わる機能

テキストそのもの以外にも、ローカライズと関わるゲームシステムがいくつかあり、それぞれ確認が必要です:

• ゲーム内での言語切り替え機能を提供している場合、再起動なしで反映されるか、再起動が必要であればその旨が明確に案内されている
• セーブデータ、クラウドセーブ、ユーザー生成テキストが、対応するすべての文字セットを壊さずに扱える

クレジットと発売後の計画

最後の2項目は見落とされがちです。バグではなくプロセスであり、プロセスの欠如を検知する失敗テストは存在しないからです。

テキストの問題がゼロの状態で出荷されるリリースは存在しません。すぐに立て直せるチームは、最初のバグ報告が来てから慌てて決めるのではなく、発売前に「誰が直すか」「どう出荷するか」を決めていたチームです。

• 翻訳者がクレジットに記載されている — 基本的な礼儀であり、多くの場合は契約上の義務でもある
• 発売後のテキスト修正について具体的な計画がある — プレイヤーから報告されたローカライズバグを誰がレビューするか、フルパッチのサイクルを待たずにテキストのホットフィックスをどう作って出すか、発売後に追加されるコンテンツの翻訳を誰が担当するか