翻訳しやすいゲームテキストの書き方 — 原文の段階で決まること

プレイヤーが読むテキストは、すべて誰かが最初に書いた一行から始まっています。ボタンのラベル、クエストの説明、店で所持金が足りないときに出る一文。そのゲームがいつか翻訳されるとき、翻訳者に渡るのはこの原文だけです。原文の段階で曖昧だったもの、断片に分かれていたもの、文脈がないと意味が決まらないものは、翻訳の過程で直るのではなく、言語の数だけ複製されます。

つまり原文は、まだ一円も使っていない段階で、こちらが完全にコントロールできる数少ない部分です。翻訳を前提に書かれたテキストは、質問が減り、手戻りが減り、返ってくる訳文の精度が上がります。そしてあまり意識されませんが、たいていは日本語のままでも読みやすくなります。訳しやすい文と読みやすい文の条件は、ほとんど同じだからです。

これは、無味乾燥な文章を書けという話ではありません。キャラクターの口調も、冗談も、作品の個性も、翻訳者から見て「何をしている文なのか」が分かる形で書かれていれば問題なく生き残ります。生き残らないのは、意味が紙の上ではなく書き手の頭の中にあるテキストです。以下は、それを紙の上に残しておくための具体策です。

1つの文字列に、1つの完結したメッセージ

文字列は画面上の枠ではなく、意味のまとまりの単位です。構造上いちばん多い失敗は、実行時に文をつなぎ合わせて作ってしまうことです。動詞と名詞、数値とアイテム名、前半の固定文と可変の後半。日本語では助詞さえ合っていれば繋がって見えますが、言語が変われば語順が変わり、数のあとで名詞の形が変わり、形容詞が名詞の性に合わせて変化します。断片を3つ渡された翻訳者には、それを直す手段がありません。結合はコードの中で起きていて、翻訳者はそこに触れないからです。

同じ失敗のもう1つの形が、「日本語では同じ言葉になるから」という理由で1つの文字列を2か所で使い回すことです。宝箱を開けるボタンの「開く」と、扉の現在の状態を示す「開いている」は、日本語では同じ語幹で済むことがありますが、多くの言語では動詞と形容詞という別の単語になります。「新規」「保存」「無料」「戻る」も同じ罠にかかります。原文が重複しても損はしませんが、統合してしまうと画面に間違った単語が出ます。用途ごとにキーを分けてください。

判定方法は単純です。その文字列だけを、コードもスクリーンショットもない表計算の1行として読んでみる。何を意味するのか、品詞は何なのかが自分で分からないなら、翻訳する人にも分かりません。

// 実行時に組み立てている: 翻訳者は完結した文を一度も見られず、
// 語順がプログラム側に固定されている
const msg = "「" + itemName + "」を" + count + "個 見つけた!";

// キーごとに完結した1メッセージ。変数には名前をつける
"pickup.found_items": "「{item}」を{count}個 見つけた!"

// 日本語では同じでも、他言語では別の単語になる: キーを分ける
"menu.file.open":   "開く"       // 動詞。プレイヤーが押すボタン
"door.state.open":  "開いている" // 状態。いまの扉を説明している

日本語が省略できるものを、書いて残す

日本語は主語を省略できます。誰が誰に話しているか、単数か複数か、丁寧なのか砕けているのかも、口調と文脈で伝わるため明示しません。書いている本人は当然すべて分かっているので、この省略は執筆中まったく問題になりません。問題になるのは、その情報がないと文が成立しない言語に置き換える瞬間です。

「準備はいい?」という一行は、英語なら誰に向けているかで言い方が変わり、フランス語やドイツ語やスペイン語なら丁寧形か親称かを選ばなければならず、相手が1人か複数かでも形が変わります。「壊れてる」は、何が壊れているのかを知らないと、名詞の性に合わせる言語では代名詞を選べません。主語のないセリフは、行為者が誰でどの性別なのかを知らないと訳せません。これらは翻訳の問題ではなく情報不足の問題で、質問リストとして返ってくるか、あるいは推測のまま製品に載ります。

対処は、文をぎこちなく書き直すことではありません。足りない事実を、翻訳者が見る場所に添えることです。話者、聞き手、代名詞や指示語が指しているもの。逆に、日本語のプレイヤーにとっても意図的に曖昧にしてある箇所なら、それも伝える価値があります。曖昧さが演出なら、翻訳者はそれを解消せずに保つべきだからです。

変数を含む文の設計

プレースホルダは、実行時に埋めると約束した文の穴です。位置番号ではなく名前をつけてください。翻訳者はしばしば順序を入れ替える必要があり、日本語で先に来る要素が相手の言語では後ろに回ります。番号だけの穴は、並べ替えた瞬間に取り違えが起きます。名前がついていれば入れ替えても壊れません。

数値は特に注意が必要です。日本語には単複の変化がありませんが、英語は1とそれ以外で形が変わり、言語によっては値に応じて3つ以上の形を使い分けます。複数形のルールを表現できるメッセージ形式を使うか、あるいは「アイテム: {count}」のように、どの言語でも複数形を必要としない書き方に設計してしまうかのどちらかです。後者は多くの製品版ゲームが採っている現実解です。

さらに2つ。変数の値によって周囲の文法が変わる場所に変数を置かないでください。英語の冠詞、形容詞の語尾、挿入された名詞に一致する動詞の形は、値によって正解が変わり、翻訳者の技量では解決できません。文の文法をこちらのデータが決めてしまっているからです。もう1つは、値がどんな見た目になるかを必ず伝えること。どの文字体系も入りうるプレイヤー名、すでに複数形かもしれないアイテム名、6桁まで伸びる数値。値の形は、その周りの文の書き方を変えます。

// 壊れやすい: 挿入される値によって前後の文法が変わる
const line = "You picked up a " + itemName;   // "a apple" になる

// 安全: 値によって文法が変わらない形にする
"pickup.generic": "入手: {item}"

// 番号だけの穴は、語順を変えると取り違えが起きる
"quest.reward": "{0}が{1}をくれた"
"quest.reward": "{giver}が{reward}をくれた"

ダジャレ・言葉遊び・その言語でしか成立しないもの

言葉遊びは直訳ではまず生き残りません。だからといって、ゲームから面白さを削るのは間違った対処です。正しい対処は、その冗談が何をしているのかを翻訳者に伝えることです。単にその場を楽しくするためのダジャレなら、対象言語で成立する別の冗談に置き換えられますし、ゲーム翻訳に慣れた人ならむしろ喜んでそうします。ただし、それが許可されていると分かっていて、どの場面で笑いが必要なのかが分かっている場合に限ります。

重要なのは、その言葉遊びが他の要素を支えているかどうかです。店主の軽口のダジャレは自由に書き換えて構いません。一方、謎解きの答えになっている言葉、プレイヤーが並べ替える文字列、ボイスの尺に合わせた韻、絵の中に描き込まれている単語は、勝手に置き換えられません。ゲームの他の部分が、その文字そのものに依存しているからです。そういう箇所は明示的に印をつけてください。翻訳者が単独で判断せず、こちらと相談すべき箇所です。

文化前提のネタも同じです。国内の芸能人、テレビの決まり文句、学校制度、コンビニの空気感を知っている前提のギャグ。これらは間違いではなく、むしろ作品の味の大部分を担っていることも多いものです。ただ、印をつけて、その一行で出したい感情を書き添え、現地の等価なネタに置き換えてよいのか、それとも「異国のものである」ことこそが狙いなのかを伝えてください。

覚えているうちにメモを書く

文脈を記録するのに最も安いタイミングは、その一行を書いている瞬間です。誰が話しているか、どの画面に出るか、なぜこの言い回しなのかを、まだ全部覚えています。最も高くつくのは数か月後、翻訳の受け渡し直前に、自分の文字列表を眺めて「ui.warn.03」が何の警告だったかを思い出そうとしている時です。

そのために管理システムを導入する必要はありません。テキストの隣に数列足すだけで、価値の大半は回収できます。話者、聞き手、表示される場所、文字数の上限、そして特記事項の自由記入欄。書きながら埋め、書くことがない行は空のままで構いません。目的はすべての行に注釈をつけることではなく、訳文が変わる情報だけを捕まえることです。

特に文字数の上限は、あとで発見するのではなく、書いた時点で記録する価値があります。あるボタンがそのフォントで12文字までしか入らないなら、その制約は誰が記録しようとしまいと存在しています。書き残せば翻訳者が最初からその範囲で書けますが、書き残さなければ、翻訳済みビルドを組んだあとの不具合報告として戻ってきます。

key,source,speaker,context,limit
shop.no_gold,"お金が足りないよ。",店主,"購入失敗時。ぶっきらぼうな口調",40
ui.button.open,"開く",,"宝箱の調べる画面のボタン。動詞",12
mira.ch02.greet,"……また あんたか。",ミラ,"プレイヤーへ。本当は嬉しいが素直でない",

渡す前に、自分のテキストを一度通しで読む

翻訳者に渡す前に、書き出したファイルを最初から最後まで自分で読んでください。ゲームの外で、一覧として文字列を読むのは最初は落ち着かない作業ですが、それがまさに狙いです。ゲームという背景がないと意味を持たない行が、そこで浮かび上がります。

数百行に対してこの見直しを1回やるのは、半日で終わる作業です。そしてゲーム開発の中では最も安上がりな品質改善でもあります。実際に翻訳する段になれば、確認の質問が減り、手戻りが減り、訳文の質が上がります。翻訳者が、こちらの意図を推理する作業ではなく、書く作業に時間を使えるようになるからです。

仮に一度も翻訳しなかったとしても、すべてのメッセージが完結していて、用語が統一されていて、実行時に文を組み立てていないテキスト層が手元に残ります。それは変更に強いコードであり、日本語のままでも読みやすい文言です。この習慣は、来るかどうか分からない海外プレイヤーのために背負うコストではありません。単に丁寧に書くというだけのことで、おまけにその扉が開いたままになります。

• すべての文字列が完結したメッセージになっていて、コード側で別の断片と連結されていない
• 同じ文字列を、文法上の役割が違う2か所で使い回していない
• 指示語には指す対象が書かれていて、各行に話者と聞き手が記録されている
• プレースホルダは番号ではなく名前で、その値によって周囲の文法が変わらない
• 個数を扱う文は、複数形を表現できる形式か、複数形が不要な書き方になっている
• ダジャレ・韻・文化ネタに印がついていて、書き換えの可否が書いてある
• 文字数の上限が文字列ごとに記録されていて、テスト工程での発見待ちになっていない
• 用語が統一されている(1つの概念に1つの呼び名。UIも含めて)