日本語のゲームを英語でも遊べるようにする：翻訳より先に決める画面設計

文字量の変化を先に見積もる

日本語は漢字1文字に多くの情報を詰められる。「開始」は2文字で済むが、英語にすると Start Game と10文字になる。「設定」が2文字、Settings は8文字だ。W3C Internationalizationの資料（Text size in translation）はCJK言語の情報密度の高さを指摘し、「これらの言語から翻訳したテキストは、訳文のほうが原文より長くなる傾向がある」と述べている。この傾向は日本語から英語へ翻訳する場面にも当てはまる。

なかでもボタンラベルやメニュー項目のような短い文字列は、実感として膨らみやすい。「保存」が Save に変わるだけのケースもあるが、「ゲームを終了する」が Quit to Title Screen になるように、意味を正確に伝えようとすると日本語より長くなるケースが多い。長い説明文は割合としての増加が目立たなくても、改行位置が変わって視覚的なバランスが崩れやすい。

翻訳者に依頼する前に、ゲーム内で使っているテキストを一覧にしておくと作業が効率的になる。ボタンラベル、エラーメッセージ、説明文、メニュー項目を別々に並べ、日本語の文字数と暫定的な英訳の文字数を比較する。この段階の英訳は機械翻訳でも構わない。目的は翻訳品質の確認ではなく、どの箇所でテキスト長が大きく変わるかを特定することだ。増加が大きそうな箇所から画面設計を見直す順番で進めると、後からの修正量を絞れる。

段落の最大幅（max-width）を設定しておくと、英語に切り替えた後も改行位置を調整しやすい。固定幅のコンテナに長い英語文字列が流れ込むと、想定外の折り返しが起きやすい。

ボタンとラベルのサイズはmin-widthで設計する

固定幅のボタンは最もレイアウト崩れが起きやすい場所だ。CSSで width: 80px のように幅を固定している場合、英語ラベルが収まるかどうかは翻訳後に確かめるまでわからない。対策として、最小幅を確保しつつテキスト長に合わせて伸縮する設計に切り替えておくと、多言語対応の際に後戻りが少ない。翻訳前にダミー英語テキストで崩れを確認する

/* 説明用コード例：最低幅を確保し、テキストに合わせて幅が伸びる設定 */
.btn {
  min-width: 7em;
  padding: 0.5em 1.2em;
  white-space: nowrap;
}

white-space: nowrap を使う場合、テキストが一行に収まるかを実際の英語文字列で確認する。overflow: hidden で見た目を整えても、ラベルが切れた状態ではUIとして機能しない。翻訳前の段階で想定される最大長の英語文字列をダミーとして入れ、レイアウトが崩れないかを確認しておく。たとえば Continue Game や View Inventory のような語を仮で入れてみて、幅が足りなければ min-width の値を調整する。

テキストが画面外にはみ出す可能性がある場所（スクロールしないモーダル、固定位置のHUDなど）は特に注意する。テキストが収まらない場合の代替表示（省略記号の表示や折り返し）をデザインの段階で決めておくと、翻訳テキストが届いてから慌てずに済む。

数字・単位・記号は翻訳テキストと分けて管理する

スコア・残り時間・アイテム数などの数値表示は、翻訳テキストとは別の問題として扱う。日本語では「1万5千点」のように助数詞と組み合わせて表示することがあるが、英語では 15,000 pts のようになる。桁区切り記号はロケールによって異なる。たとえばドイツ語では、日本語・英語でカンマを使う箇所にピリオドを、小数点にカンマを用いる。

ゲーム内の数値フォーマットを翻訳テキストに直接埋め込んでいると、ロケール対応が難しくなる。JavaScriptを使っている場合は Intl.NumberFormat を使うと、ロケール文字列を渡すだけで桁区切りや書式を切り替えられる。

// 説明用コード例：ロケールに合わせた数値整形
const score = 15000;
const enFormatted = new Intl.NumberFormat('en-US').format(score); // -> "15,000"
const deFormatted = new Intl.NumberFormat('de-DE').format(score); // -> "15.000"

ゲームのストーリー内に単位（距離・重さ・時間など）が含まれる場合も同様だ。翻訳文字列の中に数値を直書きするのではなく、数値部分をプレースホルダーで分離して管理すると、後からフォーマットだけを変えやすい。たとえば「残り {time} 秒」のように変数を使い、表示時に整形済みの文字列を埋め込む方式にする。これにより翻訳者が変えるのは文字列の構造だけになり、数値フォーマットの変更は実装側で完結する。

入力フィールドはIMEとの関係を確認する

日本語入力では、ユーザーがIME（入力メソッドエディタ）を通じて文字を変換・確定する操作が入る。英語環境ではIMEを使わず直接入力するため、入力フィールド自体は通常そのまま動作する。ただし、リアルタイムの文字数チェックや候補表示をIMEのイベントを考慮せずに実装していると、日本語入力中に誤動作する場合がある。

英語UIにしたときに入力周りで確認しておくポイントは2つある。ひとつは、変換中（compositionstart から compositionend の間）にリアルタイム処理が走らない設計になっているかどうか。もうひとつは、maxlength 属性で文字数を制限している場合に、英語の最大入力長として適切な値になっているかどうかだ。日本語で10文字の名前フィールドは、英語ではフルネームを入れると足りない場合がある。

キーボードショートカットにアルファベット1文字を割り当てているゲームでは、英語UIへの切り替え時にショートカット表示の文言と実際のキーが合っているかを確認する。

lang属性と文字コードをHTML側で設定する

言語を切り替えたとき、ブラウザが正しいフォントや改行ルールを適用するためには、HTMLの lang 属性が実際に表示している言語と一致している必要がある。W3C Internationalizationは、ページのテキストに使うデフォルト言語を html タグの属性で宣言するよう推奨している。ゲームUIが日本語の場合は html lang='ja'、英語に切り替えたときは lang='en' に更新する。ゲーム内のUIコンテナだけ言語が変わる場合は、そのコンテナ要素にも lang 属性を付けることができる。

文字コードについては、W3C InternationalizationがすべてのコンテンツにUTF-8を選ぶことを推奨している。HTMLファイルの先頭に meta charset='UTF-8' を入れていれば、日本語・英語・記号・絵文字が混在しても文字化けが起きにくい。ZIPファイル投稿・URLリンク投稿いずれの場合も、HTMLファイルの文字コードがUTF-8になっているかを確認してから提出する。lang属性とUTF-8はセットで確認する

CSSでフォントファミリーを指定するとき、英語表示のコンテナに日本語フォントが優先的に適用されると、英語の字形が日本語フォント由来になる場合がある。font-family の並び順で英語用フォントを先に書いておくか、言語ごとに font-family を切り替えるクラス設計にしておくと、見た目の一貫性が保ちやすい。

翻訳依頼前に確認するレイアウトチェックリスト

翻訳テキストを受け取る前に、次の項目をゲームの実画面で確認しておく。翻訳が届いてから初めて気づくレイアウト崩れを減らすためのチェックリストとして使える。

• ゲーム内テキストを一覧化し、日本語と暫定英訳の文字数を比較して、大きく変わる箇所を特定した
• ボタンやラベルに固定幅ではなく min-width を使い、英語の最大想定文字列をダミー入力してはみ出しがないか確かめた
• テキストが収まらない場合の省略表示や折り返しの挙動を設計の段階で決めてある
• 数値・単位・通貨記号を翻訳テキストから分離し、プログラム側で整形する仕組みにしている
• maxlength がある入力フィールドは、英語の一般的な最大入力長に合った値になっている
• HTMLのルート要素またはUIコンテナに lang 属性を設定し、言語切り替え時に更新できるようにしている
• HTMLファイルの文字コードが UTF-8 になっている（meta charset='UTF-8'）

この一覧を翻訳依頼前に処理しておくと、翻訳者が修正なしで文字列を差し込めるレイアウトが整う。翻訳が届いた後の確認を「テキストの意味と文脈の精度」に集中させられるようになり、レイアウト修正と翻訳修正が同時に走る状況を避けやすい。翻訳精度・文字量・入力方式・数字表示は別々の確認作業として進める