コンソール移植でローカライズに増える仕事 — 要件の構造を先に知る
PCでのリリースでは、言語に関するほとんどのことを自分で決められます。どの言語を出すかを選び、システム関連の文言も自分の言葉で書き、誤字の報告が来たその日の午後に修正を配信できます。同じゲームをコンソールに移植すると、この前提がかなり変わります。しかも変わる部分の多くはコードではなく、手続きと用語と「誰が承認するか」なので、外からは見えにくく、見積もりから漏れやすい領域です。
この記事で扱うのは、その違いの構造であって、各社の要件の中身ではありません。どのプラットフォームも、登録した開発者に対して秘密保持契約のもとで詳細な要件を配布しており、具体的な内容についてはその文書だけが正しい情報源です。事前に知っておいて役に立つのは「どういう種類の作業が発生するのか」で、それが分かっていれば、提出の段階で発見するのではなく、あらかじめ予算と日程に載せられます。
移植を検討中の方や、移植を請ける会社と条件を詰めている方は、記事末尾の質問リストを、契約が固まる前に確認してみてください。
対応言語が「自分だけの判断」ではなくなる
PCでは、言語は準備ができたときに足せるものです。コンソールでは、言語はストアの側に近い位置にあります。各プラットフォームは複数の地域ストアで販売しており、その地域で製品に何が期待されるかは一様ではありません。地域と製品の種類の組み合わせによっては、提示する言語について前提がある場合があり、何が自分に適用されるかを決めるのは自社のロードマップではなく、パブリッシング契約とプラットフォームの要件です。
実務上の影響は、言語のリストを早い段階で確定させる必要があり、あとから気軽に変えにくくなる、ということです。PCなら静かなアップデートで10言語目を足すのは小さな判断ですが、コンソールでは地域ごとのストア情報の追加が発生し、提出をもう一度通し、追加したテキストの内容によってはレーティングにも影響します。
これは移植の範囲を決める時点で判断すべきことで、あとからではありません。移植の予算がエンジニアリングだけを見込んでいて、言語については「PC版にあるものをそのまま」と暗黙に扱われている場合、そのずれは最も都合の悪いタイミングで表面化します。
語彙の一部はプラットフォームのもの
どのコンソールにも、ゲームが言及せざるを得ないシステム層があります。コントローラーとそのボタン、アカウントとオンラインサービス、セーブデータとその保存先、ストア、そしてゲームが呼び出す各種のシステム画面です。各プラットフォームホルダーは、これらについて自社が定めた用語を、対応する各言語ぶん維持しており、ゲーム側にはその表記どおりに書くことを求めます。妥当な同義語では通りません。
理由はプレイヤー体験の一貫性です。同じボタン、同じアカウントの概念を、ゲームごとに違う名前で呼んでいたら、そのプラットフォームの操作は覚えられないものになります。開発側から見ると、これは「テキストの一部は自由に訳せない」ということを意味します。会話文はゲームにとって最善の形に訳してよい一方、システム概念に触れる箇所ではプラットフォームの語を採用しなければならず、その語が言語ごとにどうなっているかは推測できません。だからこそ用語集が配布されています。
対処法は、プラットフォーム用語を翻訳の最後に当てる修正ではなく、最初からの制約として扱うことです。まだ自社のツールの中にある段階で、システム概念に触れる文字列に印を付けておけば、翻訳者は制約のかかる行だけを正確に把握できます。すでに全言語ぶん訳し終わった数千行に対してあとから用語を当て直す作業は、事前に数十個のキーへ印を付けるのとは比較にならないほど高くつき、抜けも出ます。
- コントローラー、ボタン、スティック、入力表示に言及する文字列
- アカウント、プロフィール、サインイン状態、オンラインサービスに関する文字列
- セーブデータと保存先、およびその成功・失敗を伝えるメッセージ
- ストア、サブスクリプション、追加コンテンツへの言及
- 終了確認や再接続の案内など、システム由来の内容を自前の文言で出している箇所
ビルドの外にあるテキスト
PCでは、プレイヤーの目に触れるテキストのほぼ全部が自分のプロジェクトの中にある、という状態に慣れているかもしれません。コンソールでは、いくつかの種類のテキストがプラットフォーム側に別途提出され、あちらのシステムに保存され、あちらのインターフェースに表示されます。分かりやすい例が実績・トロフィーの名称と説明です。言語ごとに入稿するメタデータであり、表示するのはシステムのUIで、意識して同期しない限り自分の文字列テーブルには存在しません。
地域ごとのストア掲載情報、レーティングに関する表記や画像、追加コンテンツの名称、システムのライブラリ上での見え方なども同様です。一つひとつは難しい作業ではありません。これがバグの温床になるのは、こうした文字列が「エクスポートしたファイル」ではなくウェブのコンソールの中にあるために、そもそも翻訳者のところへ届かないまま終わりやすいからです。
対策は、テキストが表示される面をすべて列挙した一覧を移植作業の一部として持ち、プラットフォーム側の項目もゲーム内の項目と同じ表に載せることです。一覧にない面は、公開されるまで誰も未翻訳に気づきません。
レーティング審査は地域ごとの別ライン
コンソールでは通常、販売する地域ごとに該当する審査機関のレーティングが必要です。各機関は独立した組織で、手続きも、質問票も、所要期間も、費用も別々です。これは単体で日程項目になりますし、ローカライズとは二方向で関係します。
一つは、レーティングがゲームの内容に基づいて決まり、テキストもまた内容だという点です。言い回し、言及の対象、描写の仕方は結果に影響しますし、何を重く見るかは機関によって違います。ある市場では何でもない一行が、別の市場では確認の対象になることがあります。だからこそ、翻訳後のテキストが申告した内容から離れていかないようにする必要があります。
もう一つは、得られたレーティングを、地域ごとに定められた形で正しく表示しなければならない点です。地域固有の素材がもう一種類増えるということであり、この手の項目は開発中ではなく提出時に落ちます。
どれも、その地域を避ける理由にはなりません。レーティングの提出を翻訳と同じ日程表に載せる理由になるだけです。どちらも、最後の一週間で頑張っても縮まらないリードタイムを持っています。
パッチが無料ではなくなる
コンソールでローカライズの手触りが最も変わるのがここです。PCなら、間違った一行は一日ぶんの恥で済みます。コンソールでは、ビルドはプレイヤーに届く前にプラットフォームの提出プロセスを通ります。実際のカレンダー時間がかかり、指摘があれば直して再提出することになり、双方の人手を消費します。誤字の修正もクラッシュの修正も、通るプロセスは同じです。
この費用構造の変化こそが、コンソール移植において提出前チェックに本気で投資する価値を生みます。そして落ちやすい項目は、たいてい機械的なものです。原文の長さに合わせたUIから文字がはみ出している。フォントが対応していない文字が表示されない。訳文からトークンが失われてプレースホルダーがそのまま出ている。テスト中に誰も開かなかったメニューに未翻訳の文字列が残っている。プラットフォーム指定の用語と表記が合っていない。
これらはすべて、提出前に、実機で各言語を読む人がいれば見つかります。さらに多くは、ファイルの段階で機械的に検出できます。PCではそこまでの重さがなかったから省略してきただけで、コンソールでは「提出1回」と「提出3回」の差になります。
- 各言語を実機で、モニタのエディタ上ではなくテレビ画面で通して読む
- セーフエリアに対して文字を確認する。コンソールのUIはPCと違い、オーバースキャンと視聴距離に耐える必要がある
- 出荷するすべての文字体系について、すべてのUI要素でフォントの収録範囲を確認する。プレイヤーが到達できる隠れた画面も含める
- 全言語で、プレースホルダーとマークアップが翻訳後も壊れていないことをビルド前に確認する
- プラットフォーム用語に関わる文字列を、1年前にダウンロードした版ではなく最新版の用語集と突き合わせる
移植を決める前に確認したいこと
コンソール移植におけるローカライズの痛みは、たいてい担当範囲の隙間から生まれます。移植作業がエンジニアリングとして見積もられ、言語まわりは「PC版がその言語で出ているのだから済んでいる」と暗黙に前提されるパターンです。取り決めが文書になる前に、次を詰めておいてください。
- 販売予定の各地域で、必要または期待される言語は何か。それを現行の要件と突き合わせて確認するのは誰か
- 開発者アカウントを誰が保持しているか。つまり、遵守すべき要件文書と用語集を読めるのは誰か
- すでに訳されたテキストにプラットフォーム用語を当てる作業は誰の担当か。それは移植の予算に入っているか
- ビルドではなくプラットフォーム側に保存されるテキストはどれで、各言語の入稿を誰が行うか
- 地域ごとのレーティング提出を誰が準備し、費用を誰が持ち、どれだけのリードタイムを見込んでいるか
- 計画は提出を何回と想定しているか。1回目が通らなかった場合、発売日はどうなるか