翻訳テキストは実際のUIで見る必要がある

翻訳された文字列は、ファイル上では完全に正しくても、画面上では間違って見えることがある。フォントはスプレッドシートのセルとは違う見え方でレンダリングされ、テキストボックスには翻訳支援ツールが知らない実際のピクセル制限があり、ある言語では問題なかった改行が別の言語では不自然な場所で入ることもある。これらを見つける唯一の方法は、プレイヤーが実際に見る場所 — 動いているUI、実機、実際のフォント — でテキストを目視することだ。

スプレッドシートと実際のゲームで何が違うのか

いくつかの問題は実機での表示に固有で、ほかのどの段階でもほぼ見えない。

• オーバーフローと切り詰め — 原文より長い訳文が固定幅のボタンからはみ出す、あるいは単語の途中で切れる
• 誤った位置での改行 — 自動折り返しが、原文とは文字間や文字幅の慣習が異なる言語で単語や名前を不自然な場所で割ってしまう
• フォントのカバー範囲 — 原文の言語は問題なく表示できるフォントでも、別の文字体系のグリフをまるごと欠いていて、空白の四角や代替文字が表示される
• 入力と操作 — オンスクリーンキーボード、テキスト入力欄、コントローラーの操作案内は言語やプラットフォームごとに挙動が変わることがある

テスターのための素早い言語切り替え

実機テストを妨げる実務上の壁は、たいてい「手間」だ。言語を切り替えるたびにゲームの再起動が必要だったり、いくつものメニューをたどったり、ロード画面を毎回待ったりするなら、テスターが実際に確認する画面数は本来あるべき数よりずっと少なくなる。アクティブな言語を素早く切り替える仕組み — デバッグメニューの項目、コマンドライン引数、ホットキー — への投資はすぐに元が取れる。遅くて省略されがちなチェックを、テスターが一回のセッションで何十回も行えるものに変えるからだ。

スクリーンショットパスを回す

スクリーンショットパス — 各言語でゲームの主要な画面を体系的に巡って画面をキャプチャすること — は、レビュアー全員がすべての言語のネイティブスピーカーである必要なく、オーバーフローや切り詰めを見つけるための単純で低コストな方法だ。正しさの確認はあとでネイティブスピーカーがスクリーンショットを見て行えばよい。パス自体はレイアウトが崩れていないかを確認する作業であり、チームの誰でも担当できる。

どの画面を優先するか

すべての画面が同じリスクを持つわけではない。一度レビューされてから変わらない静的なテキストは相対的にリスクが低い。もっとも確認する価値が高いのは、表示テキストが実行時に組み立てられ、翻訳の時点で誰も「最終的な形」として実際に目にしていない画面だ。

• プレースホルダーを含む画面 — アイテム名、プレイヤー名、数値がテンプレート文字列に差し込まれる箇所。組み合わさった長さがレイアウトに対して一度も確認されていない
• 数量表示、特にその言語の数の書式や単数・複数の扱いが原文と異なる場合
• テキストの長さがプレイヤーの状態に依存する画面 — 所持数、通貨量、プレイヤーが自由に付けた長い名前
• 今回のアップデートで新規追加された画面。過去のパスを一度も通っていない

スクリーンショットに何を写しているかを記録する

メタデータのないスクリーンショットは、価値をあっという間に失う。どこかに登録する前に、キャプチャしたビルドのバージョンと言語をそれぞれ明記しておく。そうしなければ、バグ報告は「あるとき、このテキストがおかしく見えた」になってしまい、再現も、現在のビルドで依然として問題かどうかの確認も難しくなる。

screenshot: shop-menu_ja_release-2026.08.1.png
  build: release-2026.08.1
  language: ja
  screen: ショップメニュー、アイテム説明パネル

ツールより大事な習慣

これを始めるのに凝ったツールは要らない。デバッグ用のホットキーと、命名規則を決めた共有スクリーンショットフォルダがあれば、ほとんどのチームは十分な水準まで到達できる。それより重要なのは、実機での確認をUIやテキストの変更に対する必須の工程として扱うことだ。たまに行う抜き取りチェックではなく。ここで挙げたレイアウトの問題は、他のどのレビュー段階でも見えないからだ。