多言語対応はいつやるか — 同時発売、発売後、その中間

多言語対応のタイミングは「やるかやらないか」の二択で語られがちですが、実際にはいくつもの妥当な答えがあるスケジューリングの問題です。発売前にやる、発売後にやる、段階的にやる。どれもリスクとコストと速度のトレードオフが違い、正解は予算の大小以上に、そもそもテキストがどう作られているかに左右されます。

同時発売(サイマルシップ)

初日から対象言語すべてをリリースすれば、どの言語も発売直後の露出 — ストアのアルゴリズム、プレスの記事、初期レビュー — を一度に受け取れます。また、プレイヤーが最も早く気づき最も許してくれない「言語が混ざったビルド」を出すこと自体を避けられます。

コストは、開発中にまだ変わり続けているテキストを対象に翻訳を進めることになる点です。チームが望むより早くテキストを凍結するか、変更された文字列を発売直前の時間的プレッシャーの中で再翻訳するかのどちらかになります。また、需要がまだ推測でしかない言語にも、フル翻訳のコストを先払いすることになります。

発売後の多言語対応

発売後に対応すれば、ウィッシュリストの地域分布、コミュニティからの要望、特定言語を求めるレビューといった証拠のある言語に翻訳予算を使えます。発売時点の推測に頼る必要がありません。対象テキストもすでに安定しているため、手戻りが少なく、単語あたりのコストも下がります。

トレードオフは、あとから追加する言語では発売時の露出を取り逃すことです。また、追加言語のためにQAやストアページの更新、コミュニティへの告知といった一連の作業を、二度目のリリースサイクルとしてもう一度こなすことになります。

「あとから作り直す」という落とし穴

発売後対応が高くつく本当の原因は、計画そのものではなく、テキストが最初から書き出せる構造になっていなかったと後で気づくことです。実行時に断片を連結して作る文字列、画像に焼き込まれたテキスト、ゲームロジックのすぐ横にハードコードされたセリフ、短い英単語を前提にしたUI — これらはすべて、翻訳作業の前にまずエンジニアリングの作業を発生させます。

簡単な例を挙げます。実行時に断片から組み立てられる英語の文は、言語ごとに語順や文法が違うため、そのままでは正しく翻訳できません。

// 翻訳できない — 語順は言語ごとに違う
const message = "You found " + itemCount + " " + itemName + "s";

// 書き出し可能 — ロケールごとにプレースホルダー付きの1文
const message = t("found_items", { count: itemCount, item: itemName });

「今がタイミング」のサイン

固定のカレンダー日付より、具体的なサインのほうが信頼できます。

• 未対応の言語圏からのストアページ流入やウィッシュリスト登録がある
• レビューやコミュニティで特定言語への対応が繰り返し求められている
• 更新頻度が落ち着き、安定したテキストを翻訳するのが現実的になっている
• 文字量を数えており、予算が把握できる範囲に収まっている

中間案という選択肢

サイマルシップと発売後対応は両極端であって、選択肢のすべてではありません。まずストアページだけを翻訳するのは、需要を測る最も安いテストです。ゲーム本編の全訳に比べればごくわずかなコストで、ウィッシュリストやページ閲覧数という実際のシグナルを、本格的にコミットする前に得られます。もう一つよくある中間案は、すでにある最も強いシグナルに基づいて優先言語を一つだけ選んでゲーム内テキストを対応し、その言語の反応を見てから広げていくやり方です。

どの道を選ぶにせよ、あとの選択肢を実質的に決めるのはもっと早い段階の判断です。最初の一行から、テキストをコードの外に、安定したキーを持つ書き出し可能なファイルとして置いておくこと。この選択があってはじめて「発売後にやる」が作り直しではなく現実的な選択肢になります。