新規登録
プロセス・運用Read this article in English

ローカライズキット(ロックキット)とは — 翻訳発注前に揃える資料と列構成

ローカライズキット(業界では「ロックキット」と略されます)とは、翻訳を外部に依頼するときにテキスト本体と一緒に渡す資料一式のことです。中身は、文字列ファイル、用語集、スタイルガイド、キャラクター表、画面のスクリーンショット、そしてプレースホルダ・ファイル形式・納品条件の取り決めです。必要な理由は単純で、文字列の一覧だけでは「語が何か」しか伝わらず、「そのゲームの中でどう訳すべきか」が一切伝わらないからです。

この記事では、キットの構成一覧を「無いと何が起きるか」とセットで示し、そのまま使える列構成、用語集とキャラクター表の実物、プレースホルダ規則を載せます。あわせて、翻訳者からほぼ必ず来る4つの質問、引き渡し前のチェックリスト、個人開発での最小構成も扱います。

キットに入れるものと、抜けたときに起きること

入れるかどうかの判断基準は一つで、「それが防ぐ失敗を言えるか」です。言えないものは入れる必要はありません。以下は各項目と、それが無いときに実際に起きることの対です。

  • 文字列ファイル。翻訳者が実際に開く形式で、キーが安定していること。キーが安定していないと、再エクスポートで行順が変わり、次のバッチで別の行の訳が当たります。
  • 文字列ごとの文脈。どこに出て、何が起きている場面か。無いと推測になり、たとえば Fire の一語が、呪文名のラベルなのに動詞として訳されます。
  • セリフ行ごとの話者。無いと一人称も敬体・常体も決められず、同じキャラクターが一つの場面の中で三通りの口調になります。
  • 固定幅の枠に入る文字列の文字数上限。無いと、訳は正しいのに製品上で末尾が切れます。
  • UI文字列ごとのスクリーンショット参照。無いと、ボタンと見出しとツールチップの区別がつかず、三つとも同じ言い回しになります。
  • 固定用語の用語集。アイテム、キャラクター、勢力、システム用語。無いと、同じ剣がファイルごとに三つの名前になり、翻訳者が複数なら二つの名前が併存します。
  • スタイルガイド。敬体か常体か、語調、禁止語、数字や日付の書き方(最初のローカライズの前に読む本で基準を決めておくと早い)。無いと、全体が各翻訳者の癖の寄せ集めとして読まれます。
  • プレースホルダとタグの規則。各トークンが何に展開され、どんな型で、位置を動かしてよいか。無いと、トークンごと訳される、語順に合わせて壊れる、消える、のいずれかが起きます。
  • 戻してほしいファイル形式、文字エンコーディング、締め切り。無いと、取り込めないファイルが、文字化けするエンコーディングで返ってきます。
  • 質問先の担当者名。無いと、キットが想定しきれなかった疑問が推測で埋められ、その推測はレビューで初めて表に出ます。

文字列ファイルの列構成と、引用符・文字数の単位

キットの価値の大半は7列で運べます。このセクションの末尾に置いた表が、そのヘッダーと3行です。CSVにしているのは、ほぼどのエンジンも表計算ソフトも、出力と読み込みの両方ができる形式だからです。キーの設計自体は文字列キーの命名と設計で扱っています。この表が引き渡しを無事に通るかどうかは、次の3点で決まります。

まず引用符です。表の2行で引用符が必要になっていて、手作りのキットが壊れるのはまさにここです。カンマを含むフィールドは二重引用符で囲まないと、そのカンマが列の区切りとして読まれます。実際、2行目の文脈欄を引用符なしで「playful, not angry」と書くと、パースした結果は7列のヘッダーに対して8フィールドになります。カンマ以降が話者欄に入り、それより後ろの列が一つずつずれます。テキストエディタで見るぶんには問題なく見えます。送る前に一度パースして、全行のフィールド数をヘッダーと突き合わせてください。ずれはエラーにならずに起こり、原文欄に入っているものがそのまま訳されます。

文字数の列には単位を書き添える必要があります。もっともらしい答えが複数あって食い違うからです。cafe の e に結合用のアクセント記号を別符号で付けた表記は、UTF-16のコード単位で5、コードポイントで5、見た目の文字数で4になります。合成済みの1文字で書けば4・4・4です。炎の絵文字1個はUTF-16のコード単位で2、見た目では1文字です。日本語ではさらに、その枠で全角1文字を半角1文字と同じ幅として数えるのか、という問題が重なります。どの数え方かを書いていない上限は、制約ではなく願望になります。

空欄は「該当なし」の意味に固定し、「まだ埋めていない」の意味では使わないでください。UIラベルの話者が空欄なのは情報です。セリフ行の話者が空欄なのは、メールになる前の質問です。すでに構造化形式を使っているなら、平らな表よりそちらを優先してください。XLIFFファイル形式は文脈・注記・単位ごとの状態を仕様として持っており、ここで挙げた列はそのまま対応します。エンジン側の取り込みはUnityのローカライズCSVワークフローで扱っています。

key,source_en,context,speaker,max_chars,screenshot,note
UI_SHOP_CONFIRM,Confirm,Bottom-right button of the shop dialog; beside Cancel,,12,shop_dialog.png,Same width as Cancel
DLG_ARA_0031,"Don't touch that, it's mine!","Ara catches the player at her workbench; playful, not angry",Ara,,workbench_02.png,
ITEM_DESC_EMBER,"Burns for {0} damage, and sets the target alight.",Item tooltip; {0} is an integer,,80,tooltip_ember.png,"{0} can be 1, so avoid plural-only phrasing"

用語集の1行と、声を固定するキャラクター表

用語集の1行に必要なのは4つです。原語、それが何の名前か、承認済みの訳、そして既に却下した訳。最後の列が最も省かれやすく、最も差し戻しを減らします。こちらが黙って持っている好みが、翻訳者が従える規則に変わるからです。

用語集が用語を固定するのに対し、キャラクター表は声を固定します。日本語で効くのは一人称、敬体か常体か、プレイヤーの呼び方の3つです。この3つは日本語では文法上どうしても決めなければならず、英語の原文には存在しません。つまり誰かが決めます。キットが決めなければ翻訳者が行ごとに決め、キャラクターはぶれます。これが英語から日本語へのゲームローカライズで実務上いちばん重い部分です。

# glossary.csv
term,type,ja,do_not_use,note
Ember Blade,item name,エンバーブレード,燃える刃 / 炎の剣,固有名詞。ツールチップとクエストテキストで使用
Ash Covenant,faction name,灰の盟約,アッシュ・コヴェナント,意味で訳す。日本語版で英語表記は出さない
Stagger,mechanic,よろけ,スタガー / ふらつき,状態異常。動詞にしない。UIとチュートリアルで表記を統一

# characters.csv
name,role,first_person,speech_style,formality,addresses_player_as,note
Ara,鍛冶師、40代,オレ,ぶっきらぼうで短い。語尾を落とす,常体,あんた,貴族相手でも敬語は使わない

プレースホルダ規則と、必ず来る4つの質問

どのプロジェクトでも同じ4つの質問が来ます。前倒しにするというのは、その4つの答えがすでにキットの中にある状態を指します。どこに出るのか、は文脈欄とスクリーンショット欄が答えます。誰のセリフか、は話者欄とキャラクター表が答えます。何文字まで入るか、は単位を明記した文字数欄が答えます。この {0} は何か、は文字列ごとに説明するのではなく一度書いたプレースホルダ表が答えます。

トークンの型を書いておく必要があるのは、原文の言語側では意識しなくて済む文法があるからです。1という個数は英語では文法上単数として扱われ、日本語では区別がありません。Unicode の CLDR ロケールデータが定める複数形の分類では、英語は one と other の2つに解決され、日本語は other だけです。したがって {0} items のような文字列は英語では2つの形が必要で日本語では1つです。{0} が数値だと伝えられていない翻訳者には、そのどちらが必要かを知る手がかりがありません。この扱いを仕様として持つ書式はICU MessageFormatの解説で扱っています。

{0} {1}        位置指定の番号付きトークン。型は note 欄に書く
{playerName}   名前付きトークン。プレイヤーが入力した自由文。文字種・長さ不定
%s %d          旧来の printf 系トークン。%d は整数、%s は文字列
[b] ... [/b]   対になるマークアップ。両方残し、囲む範囲も変えない
\n             強制改行。消さない。増やさない

波括弧・角括弧の中身は訳さない。
番号付きトークンは語順に合わせて動かしてよい。番号は値と一緒に動く。
note の無いトークンは、訳ではなくこのキットの不備。質問してよい。

引き渡し前のチェックリストと、抜けやすいテキスト

送る前に通してください。最初の質問が来てからでは遅いものです。

  • 全行がパースできる。各行のフィールド数がヘッダーと一致し、書き出したツール以外のツールでも正しく開ける。
  • セリフ行すべてに話者がある。UI行すべてにスクリーンショット参照がある。
  • ファイル中に出てくるプレースホルダが、すべてプレースホルダ表に載っている。
  • 用語集の語がすべて実際に文字列ファイルに出てくる。逆に、ファイル中の固定用語がすべて用語集に載っている。
  • エンコーディングと戻す形式が明記されている。締め切りと質問先の名前が、送付メールではなくキットの1枚目にある。

個人開発の最小構成と、規模が大きくなったら足すもの

文字列ファイルの外に残りやすいテキストは5種類あります。スクリプトやシーンにハードコードされたまま残っている文字列。これはキットを完成させる前に外へ出す必要があり、ハードコードされた文字列の外部化で扱っています。看板やロゴ、チュートリアル図のように画像に焼き込まれた文字。描き直しかテキストレイヤー化のどちらかが必要です。ストアページの文章。短い説明文やスクリーンショットのキャプションも含みます。実績・トロフィーの名称と説明。これはプロジェクトではなくプラットフォーム側の管理画面にあります。そして年齢表示や必須のクレジット表記のような法務・安全上の文言。ここは翻訳者に推測させず、専門家に文面を確認してもらってください。

個人開発で1言語だけなら、最小構成は4つです。文脈欄と話者欄のある文字列ファイル、固有名詞を網羅した用語集、敬体か常体かとプレイヤーの呼び方を決めた1枚のスタイルガイド、そしてキー名を付けたスクリーンショットのフォルダ。やることが決まっている作業で、これだけで本来質問として飛んでくるものの大半を吸収します。

規模が大きくなったときに足すものは、必要になる順でおおよそこうです。話すキャラクターが数人を超えたらキャラクター表。用語集が通読できない長さになったら翻訳禁止リスト。UIがテキストに合わせて伸びなくなったら文字数の列。2言語以上が同時に走り、テキストだけでなく文字列ごとの進行状態が必要になったら構造化形式。

逆に、規模が大きくなっても入れないほうがよいものが2つあります。翻訳者がテキストにたどり着く手段のないビルドと、前回からの変更を文章で書いた変更履歴です。変更履歴のほうは、文字列ファイルの新旧2版の差分を取れば足ります。そのぶん、用語集とスタイルガイドは案件ごとの添付ではなく、更新し続ける生きた資料として扱ってください。再利用のたびに価値が増える部分であり、かつチェック工程が訳文を突き合わせる基準になる部分です。その工程が何を見るのかはローカライズQA(LQA)とはで扱っています。