英語から日本語へ — ゲームの日本語化で実際に変わること
自作の英語版を日本語にする場合も、海外ゲームの日本語化を受ける場合も、最初につまずくのは文字数と表示幅の関係です。よく使われるUI文字列8本で実測すると、日本語は書記素(見た目上の1文字)で50字、英語は108字で46パーセント。一方、等幅で全角を2セル・半角を1セルとして数えた概算幅では、日本語100セルに対し英語108セルで93パーセントでした。つまり文字数は半分近くまで減るのに、描画幅はほとんど減りません。もっとも短いボタンラベルでは、日本語のほうが広くなります。
文字数は半分、表示幅はほぼ同じ
長い文は実際に縮みます。終了確認は30セルから22セルへ。ところが短いラベルは逆に増えます。Save は4セルから6セルへ、Continue は8セルから10セルへ。つまり英語で4文字から8文字のラベルが並ぶタイトルメニューが、ゲーム全体でもっとも文字あふれを起こしやすい場所になります。
注意点が2つあります。1つは、この数え方が「半角1文字は全角の半分」を前提にしていて、プロポーショナルフォントはそうならないということ。Arialで送り幅を実測すると小文字の平均は0.49emで前提どおりですが、大文字と空白が入るとラベルはそれより広がります。Save は半角4セルではなく4.6セル、New Game は8セルではなく10.0セルで、「はじめから」とちょうど同じ幅です。それでも最短のラベルでは日本語が広く、「セーブ」はArialの Save より32パーセント広くなります。ただし差の大きさはフォント依存なので、表の比率は目安として使い、最後は自分のフォントで測ってください。もう1つは、訳語は定数ではなく選択だということ。Settings は「設定」なら4セル、「環境設定」なら8セルです。枠の上限を伝えていなければ、翻訳者が短い側を選ぶ理由はありません。
対処は、文字列テーブルに描画側が実際に測っている単位で幅の上限を持たせることです。確認の順番は、英語の短い文字列から先に見るのが効率的です。
下の数値は推定ではなく実測です。日本語側は逐語訳ではなく、実際の製品で使われそうな訳を当てています。
英語 書記素 幅 日本語 書記素 幅
Save 4 4 セーブ 3 6
Continue 8 8 つづきから 5 10
New Game 8 8 はじめから 5 10
Settings 8 8 設定 2 4
Inventory 9 9 持ち物 3 6
Not enough gold. 16 16 お金が足りません。 9 18
Press any key to continue 25 25 何かキーを押してください 12 24
Are you sure you want to quit? 30 30 ゲームを終了しますか？ 11 22
----------------------------------------------------------------------------------------
合計 108 108 50 100
英語比 46% 93%先に直すのはエンジン側 — 禁則処理・フォント・文字コード
日本語は単語をスペースで区切りません。空白でしか改行判定をしない実装では、日本語の段落には改行位置が1つも見つからず、枠からあふれるか固定文字数で切られます。逆に、文字境界ならどこでも折り返す実装も不十分です。日本語の組版では、閉じ括弧や「、」「。」、小書きの「ゃゅょっ」は行頭に置けず、開き括弧は行末に置けません。この文字クラスはJIS X 4051(日本語文書の組版方法)に規定されています。実装しなければ、いずれ行頭に「。」が単独で現れます。症状の直し方は行頭に「、」や閉じ括弧が来る不具合、アルゴリズム側の考え方は日本語の改行処理にまとめています。
フォントも前提条件で、字形の網羅範囲は数字で押さえられます。JIS X 0208の文字表には第1水準2,965字・第2水準3,390字の計6,355字の漢字があり、いま多くのフォントが目標にする範囲は内閣告示の常用漢字表2,136字です。常用漢字までのフォントはメニューは問題なく描けて、キャラクター名で破綻します。人名用漢字の多くが常用漢字の外にあるからです。不足した字は代替の四角になるか、黙ってシステムフォントに差し替わって字形とウェイトが変わります(文字が四角い箱になるのはフォントの問題)。低解像度のドット絵では、日本語と英語を同じピクセルフォントで成立させるための最低字高という制約も加わります。漢字はラテン文字より縦のピクセル数を必要とします。
既存資産がUnicode以前のものなら、文字コードの上限も引き継ぎます。CP932(Shift_JISのマイクロソフト拡張)で表せる漢字は6,716字で、JIS X 0208より多いものの閉じた集合です。「𠮟」「𩸽」のように範囲外の字は表現できず、書き出し処理が黙って別の字に置き換えると、エラーではなく名前の化けとして残ります。テキスト経路は全体をUTF-8に統一し、必要な境界だけで変換してください。Shift_JISとCP932は同じではない点にも注意が必要です。
プレースホルダと語順、複数形がない代わりの助数詞
日本語は動詞が文末に来ます。固定の前半と値と固定の後半をコードで連結して組み立てているメッセージは、同じ順序では日本語になりません。必要なのは、翻訳側で位置を入れ替えられる名前付きプレースホルダです。コード内での文字列連結は、それを不可能にします。
日本語には、数に応じて名詞が変化する文法的な複数形もありません。実行環境に日本語の複数形カテゴリを問い合わせると other の1つだけが返り、英語では one と other の2つが返ります。つまり日本語のメッセージは1つの形で足ります。逆に、単数形と複数形の欄を必ず要求する形式のファイルを渡されると、同じ文が2回入るだけになります。ICU MessageFormatは、この差を言語ごとに文字列を分岐させずに表現するための仕組みです。
代わりにあるのが助数詞です。数の後ろに、数える対象の種類や形状で決まる語が付きます。細長いものや瓶は「本」、平たいものは「枚」、人は「人」、小動物は「匹」、汎用的な物には「個」。英語の {count} items のような1つのテンプレートを、アイテム種別をまたいで再利用することはできません。助数詞をアイテム定義側に持たせるか、種別ごとにメッセージを書くかのどちらかです。ここを当てで済ませると、文法的には正しいのに翻訳臭い文章になります。
桁区切りは英語と同じですが、省略表記は違います。日本語は大きな数を1万単位で区切るため、12,345,678のコンパクト表記は日本語で「1235万」、英語では 12M になります。1000で割ってKを付ける自作のヘルパーを日本語に出すと、プレイヤーが頭の中で換算することになります。日本語文中の数字は半角に統一し、桁区切りはロケール対応の数値フォーマッタに任せてください。
en "You found {item}!" ja "{item}を手に入れた！"
en "{count} potions left" ja "ポーション残り{count}本"
en "{name} joined the party." ja "{name}が仲間になった。"英語原文が決めていない判断 — 敬体/常体・一人称・カタカナ
受注側でも自社開発でも、翻訳を始める前に合意しておくべき判断があります。まず文体です。敬体(です・ます)と常体(だ・である)はどちらも正しいものの、同じ画面の中で混ざると雑に見えます。システムメッセージやUIは敬体、ナレーションは常体という切り分けが一般的ですが、どちらを選ぶにしてもスタイルガイドに先に書いてください。後から変えるのは修正ではなく書き直しです。
キャラクターはさらに情報が必要です。英語の I は1語ですが、日本語では一人称を選ばなければならず、その選択が年齢・性別・立場・自己像を伝えます。語尾や終助詞も同じです。英語のセリフ1行からこれを推定できる翻訳者はいません。話者ごとに一人称・敬語の段階・その口調のサンプル1行を並べたキャラクター表が、もっとも効果の大きい資料です。完成した訳文から巻き戻すより、先に作るほうが安く済みます。
カタカナ語の採否は辞書引きではなくプロジェクトの決定事項です。「セーブ」と「保存」、「アイテム」と「道具」、「ダメージ」と「損傷」はいずれも成立します。唯一の間違いは、同じ概念に画面ごとに違う語を当てることです。用語集で固定してください。約物の慣習はより明確です。読点と句点は「、」「。」、会話は「」、作品名や引用の入れ子は『』、三点リーダーは「…」を2つ重ねるのが一般的です。一方で数字とラテン文字の略語は日本語文中でも半角のままにするのが通例で、全角・半角の扱いは文字種ごとに違います。
残る2つはテキストではなくレイアウトの判断です。対象年齢が低いなら、どこにルビを振るかを決め、その分の行高を確保します。縦組みは印刷物では一般的ですが、ゲームのUIでは少数派です。採用するなら早く決めてください。変わるのは文字列ではなくテキストエンジン側で、句読点や括弧、小書きの仮名がすべて回転・再配置を必要とします。
何を先に渡し、何を実機で確認するか
用語集・キャラクター表・幅の上限は、最初の1行を訳す前に渡します。文字列ごとの文脈情報も同じで、避けられる手戻りの大半はここが欠けていることから生まれます。1文字列あたり、次を添えてください。
- 話者。キャラクター表の項目と対応付ける
- 文体。敬体か常体か、そしてUI文言かセリフか
- 表示される画面またはシーン。訳者が場面を想像できるように
- 幅の上限。描画側が測っている単位で。あわせて許容行数
- 各プレースホルダが何を入れるか、と現実的なサンプル値
- 折り返し可否と、同じ文字列を他画面でも使い回しているか
出荷されてしまう失敗
テキストを送る前に送るべきものを揃えることが、翻訳をローカライズに変えます。そのうえで、日本語でビルドを遊んでください。表計算で見つかるのは訳文の問題だけで、残りは動いているゲームでしか見つかりません。この工程がLQA(ローカライズQA)で、必要なのは原稿の校正ではなく、ビルドを手元で動かせる日本語話者です。役割も分けてください。訳す人、日本語をレビューする人、統合を確認する開発者の3者です。次に挙げる失敗は、日本語が読めない開発者でも見つけられます。
- 機械翻訳を1文字列ずつ貼り込んだ結果、同じメニューの中で語尾が「です・ます」と「だ」で混在している
- 原文がいちばん短く見えた場所で、ラベルが切れている、あるいはあふれている
- キャラクター名だけが四角い箱になっている
- 全角の文章の中に半角のカンマ・ピリオド・感嘆符が混ざっている
- 省スペースのために半角カタカナを使い、デザインではなく古いシステムのように見えている
- ゲーム本体は全訳済みなのに、ストアページ・スクリーンショット・トレーラーの字幕が英語のまま