ローカライズキット(lockit)の作り方 — テキストを送る前に送るべきもの

ローカライズキット(業界では「lockit」と略されることもあります)は、翻訳者やスタジオ、エージェンシーに作業を依頼する際に、テキスト本体と一緒に送る資料一式のことです。存在する理由は単純で、テキストファイル単体では絶対に足りないからです。文字列のスプレッドシートは「何を訳すか」は伝えますが、「そのゲームの中で正しく訳すにはどうすればいいか」は伝えません。

よくできたキットは、翻訳者が本来ならプロジェクトを通してメール一通ずつ聞くことになる質問に、あらかじめ答えています。一度キットを作るコストは、同じ質問に文字列一つひとつについて何度も答えるコストより一貫して低くなります。

キットに含めるべきもの

以下のリストの各項目は、特定の予測可能な失敗パターンを防ぐために存在します。それが「キットに含める価値があるか」の判断基準です。

• テキストファイル本体 — 翻訳者が実際に作業するフォーマットで、当て推量でマッチングされないよう安定したキー付きで
• 用語集 — アイテム名、キャラクター名、勢力名、システム用語など、どこでも一貫して訳されなければならない固定用語。ファイル間や翻訳者間で訳語がブレるのを防ぎます
• スタイルガイド — トーン、丁寧さのレベル、キャラクターやUI箇所ごとの語調。テキスト全体が個々の翻訳者の癖の寄せ集めではなく、一つの声として読めるようにするためのもの
• キャラクターノート — 各キャラクターが誰で、性格や人間関係はどうか。すべてのセリフに完全なシーン文脈を付けられなくても、正しいトーンで訳せるようにするため
• UIや主要シーンのスクリーンショットや動画 — 文字列が実際にどこにどう表示されるかを、想像ではなく目で確認できるように
• プレースホルダーの説明 — 各トークンが何に展開され、文法的にどんな役割かを一度まとめておくことで、文字列ごとに聞かれる手間を省く
• 翻訳禁止リスト — 固有名詞やブランド用語、原文のままにすべきUI要素。どれが例外なのかを翻訳者が推測しなくて済むように
• 締め切りと文字数・単語数のサマリー — 翻訳者やエージェンシーが、途中で規模を知って驚くのではなく、最初から正直にキャパシティを計画できるように
• Q&A窓口 — キットが想定していなかった質問のための、担当者名やチャンネル。どんなキットもすべてを想定はできないため

簡単な例

用語集の一項目は、大掛かりである必要はありません。曖昧さがなく、翻訳中に照らし合わせやすいことが重要です。

term: "Ember Blade"
type: アイテム名、一般名詞として訳さない
ja: エンバーブレード (「燃える刃」等への意訳は不可)
note: 固有名詞。アイテムのツールチップ、クエストテキスト、NPCの会話で使用

良いキットは聞かれる前に答えている

キットの価値は前倒しにあります。本来ならプロジェクト途中で翻訳者が聞くはずの質問 — このキャラクターはどんな話し方をするのか、この名前は訳していいのか、このボタンラベルは何文字まで入るのか — が、受信箱で待つのではなく、最初からキットの中に答えとして存在しています。これで質問がゼロになるわけではありませんが、予測可能な質問が減り、Q&A窓口はキットが本当に想定できなかった新しいケースのために使われるようになります。

実際の効果は翻訳そのものだけでなく、レビューの場に表れます。文字列同士の整合性が崩れている件数が減り、トーン調整のための二回目のパスが減り、翻訳者が原文の書き手と同じ情報を持って作業しているぶん、初稿が最終稿に近くなります。

一度作って使い回す

キットは一回の受け渡しのために書く使い捨ての文書ではありません。特に用語集とスタイルガイドは、今後のアップデートや拡張、新しい言語の追加にも引き継がれていく生きた参照資料として扱うべきです。テキストのバッチが来るたびに文脈をゼロから組み立て直しているチームは、不完全なキットのコストをプロジェクトごとに何度も払い続けていることになります。