Naninovel のローカライズ実務ガイド — スクリプト・管理テキスト・ボイス
Naninovel は Unity 上でノベルゲームを作るためのフレームワークで、独自のスクリプト形式と独自のローカライズの仕組みを持っています。これは基本的にありがたいことで、2言語目を出すための仕組みが最初から用意されているので自分で発明する必要がありません。ただし同時に、プロジェクトの最初の判断が「どのテキストをどの仕組みが管理するか」になります。Unity 自体にもローカライズ用のパッケージがあり、同じ文字列を両方で管理しようとすると簡単に1日溶けます。
もう一つ、始める前に知っておく価値があるのは、Naninovel の翻訳対象が一つの塊ではないことです。スクリプト内のセリフと、スクリプト外のインターフェース文言は別の場所で管理され、別の手順で生成されます。最初のローカライズでいちばん多い不具合が、セリフは英語なのにメニューが元の言語のまま、というものです。パイプラインの半分しか回っていないために起きます。
この記事では、その2種類の違い、翻訳ドキュメントが原文の行とどう結びついているか、Unity を開かない翻訳者にどう渡すか、そしてテキストの長さが変わった瞬間に出てくるボイスと組版の問題を扱います。
2種類のテキストが、別の経路で翻訳される
1つめはスクリプト内のテキストです。.nani スクリプトの中でプレイヤーが読む行のことで、Naninovel のスクリプトはプレーンテキストです。コマンドを表す記号で始まる行は命令、コメント記号で始まる行はチーム向けのメモ、それ以外が表示される内容 — 地の文か、行頭の識別子でキャラクターに紐づいたセリフ — になります。コマンドの引数としてプレイヤーが読むテキストを持つものもあり、代表が選択肢です。
2つめが、Naninovel でいう管理テキスト(managed text)です。スクリプトの一部ではないけれど画面に出る文字列がここに入ります。キャラクターの表示名、UIのラベル、用語集やヒントの項目、その他の設定可能な文言などで、これらは独立したドキュメントに置かれ、独立した手順で翻訳されます。セリフは訳されているのにメニューが元の言語のままなら、原因はほぼこれです。
そしてどちらでもない領域があります。立ち絵や背景に描き込まれた文字、Naninovel を経由せず自作の Unity UI が表示している文字、ストアページの文章です。これらはエンジンのローカライズの対象外なので、別の計画とスケジュール上の別の行が必要になります。
; コメント行。プレイヤーには表示されない。 @bg village Misaki: そんなの聞いてないよ。 @choice "手紙のことを訊く" goto:.Letter
翻訳ドキュメントと原文はどう結びついているか
Naninovel は、ロケールごとにスクリプトに対応する翻訳ドキュメントを生成します。訳文の各行は、ファイル内の位置ではなく識別子によって原文の行と対応づけられます。これは良い設計ですが、運用上ひとつだけ前提が生まれます。行を移動しても対応は保たれる一方で、原文そのものを書き換えると対応が切れる、ということです。原文の言い回しを直せば、既存の訳文をそのまま最新として扱うことはできなくなります。挙動としては正しく、同時にその行が静かに要対応に戻ることを意味します。
つまりここは、ツールの問題ではなく進行の問題です。翻訳を始める前に原文を凍結するか、以降の原文修正のたびに、探し出して訳し直す行が生まれることを受け入れるかの二択になります。ストア重視のゲームでは、ライターは発売直前まで原文を磨き続けるので、現実的な計画はたいてい部分凍結です。翻訳に出した章はロックし、出していない章は編集を続け、凍結後の変更は全言語にコストが乗る変更依頼として扱います。
行を足したり直したりしたあとにドキュメントを再生成するのは、危険な操作ではなく日常の手順です。ただし、意識して行い、前後をバージョン管理にコミットしてください。何が変わったかを確実に言えるのは差分だけであり、差分から抜き出した40行のリストを翻訳者に渡すほうが、変更箇所を自分で探してくださいと頼むよりはるかに楽です。生成の具体的なメニュー位置や設定項目は、リリースによって変わるので、使っているバージョンの公式ドキュメントで確認してください。
Unity を開かない翻訳者にどう渡すか
翻訳ドキュメントはプレーンテキストでバージョン管理と相性が良く、エンジニアには理想的ですが、多くの翻訳者にとってはそうではありません。ゲーム翻訳の実務者が慣れているのは、原文の横に文脈が並ぶ2列のビューであって、識別子をうっかり編集すると、その行が対応する文からそっと切り離されるテキストファイルではありません。
現実的な選択肢は2つです。ルールシートを添えてドキュメントをそのまま渡し、識別子・コメント行・ドキュメントの構造には絶対に触らないと明示する方法。これは少人数で技術的な抵抗が少ないチームなら回ります。もう一つは、翻訳フェーズだけ表計算形式に変換し、自分が中身を理解している変換スクリプトで戻す方法です。手作業でコピー&ペーストしながら、1年間の更新を通じて整合を保てる第3の道はありません。
変換する場合は、本番の前に往復を証明してください。数行を、書き出し・表計算・取り込み・ビルドまで通します。行の途中にインラインコマンドが入る行と、選択肢を必ず含めます。識別子を落としたり順序を入れ替えたりする変換は、派手に失敗してくれません。数行だけが静かに翻訳されなくなり、プレイヤーが見つけるという形で失敗します。
- 識別子・ラベル・コメント行は編集も翻訳もしない
- 行中の角括弧のインラインコマンドはコード。残す、名前を変えない
- 行頭のキャラクター識別子は残す。表示名は管理テキスト側で翻訳する
- 判断に迷うものは推測で解決せず、質問として上げる
- ドキュメントの構造と行の順序は組み替えない
ボイス — 収録後の行編集が高くつく理由
Naninovel には、スクリプトと行の位置に基づいてボイスクリップを自動的に対応づける仕組みがあります。プロジェクトがその設定なら、行の挿入・削除・分割・結合によって、どこで何が鳴るかがずれる可能性があります。しかもこの失敗はエラーメッセージとして出ません。誰も再確認しなかったシーンで、キャラクターが別の台詞を喋る、という形で出ます。自分の構成でクリップ名がどう解決されるかは公式ドキュメントのボイスの章で確認し、収録後のスクリプト編集は「音を出して確認するまで完了ではない変更」として扱ってください。
これはローカライズと具体的に噛み合います。あるロケールを「原語の音声+翻訳字幕」で出すなら、音声は原文の行に紐づいているので、翻訳側で行の構造を変えてはいけません。読みやすさのために長い1行を2行に分けるのは翻訳者として自然な判断ですが、それがボイスの対応を壊します。ルールシートに明記してください。
そのロケールでも収録する場合は、収録済みの言語ではテキスト修正のコストが跳ね上がること、そして訳文が原文と同じ尺になることはまずないことを見込んでおきます。オートの送り速度、文字送りの演出、原文に合わせて調整したタイミング演出は、新しい長さに対して再確認が必要です。
フォント・文字量・表示まわりの総点検
下は Unity なので、グリフの網羅はフォントアセットの問題になります。フォントアトラスは、生成時に含めた文字しか描けず、足りない文字はエラーではなく空の箱として表示されます。日本語とラテン文字をまたぐプロジェクトで、全ロケール共通のフォント1本がうまくいくことはまずありません。Naninovel はロケールごとのフォント設定に対応していますが、これを使う理由は好みではなく、日本語のために選んだ書体は欧文の字形が弱く、その逆もまた真だからです。
もう一つの定番が文字量です。日本語から訳した英語は表示上長くなりがちで、壊れるのはたいていメインのメッセージ枠ではありません。そこは余裕があることが多いからです。確認すべきなのはバックログ、選択肢ボタン、ヒントや用語集の項目、名前欄、設定画面です。どれも原文に合わせてサイズを決めた場所で、しかもスクリプトの差分には現れません。
最後は、ドキュメント上ではなく動いているゲームで確認します。ゲーム中に設定画面からロケールを切り替え、すでに画面に出ているテキストが更新されること、バックログが前の言語のまま残らないこと、片方のロケールで作ったセーブがもう片方で正しく読めることを見ます。テキストエディタ上では完璧に見えるビルドでも、そもそも配線されていない画面が3つ残っていることはあります。
- 出荷する全ロケールについて、全スクリプトの翻訳ドキュメントが最新であること
- 管理テキストのドキュメントが揃っていること(キャラクターの表示名を含む)
- 選択肢・バックログ・ヒント・設定画面をファイルではなくゲーム内で確認したこと
- フォントをロケールごとに実画面で確認したこと(プレビューではなく)
- 収録後に行を編集した箇所は、ボイスの対応を再確認したこと
- プレイ中のロケール切り替えと、ロケールをまたいだセーブ・ロードを試したこと