新規登録
実装Read this article in English

ローカライズファイルはCSVかJSONか — 本当に大事なのは何か

CSVとJSONは、どちらもローカライズテキストの受け渡し形式として頻繁に登場しますが、チームは適性ではなく慣れでどちらかを選んでしまいがちです。それぞれに実際の強みと実際の壊れ方があります。ここでは実践的な比較と、フォーマット選び自体より重要な性質を整理します。

CSV: スプレッドシート親和性が高いが、クオート処理に弱い

CSVの一番の魅力は、翻訳者が誰でもすでにスプレッドシートで開いて、フィルタして、コメントを入れる方法を知っていることです — ツールのインストールが不要です。一番のリスクは、多くの人がきちんと読んでいないクオート規則です。CSVの仕様では、カンマ・二重引用符・改行を含むフィールドは二重引用符で囲む必要があり、そのフィールド内の二重引用符自体は二重にして表記します。

  • クオートされていないフィールド内のカンマは、以降のすべての列を黙ってずらす
  • クオートされたフィールド内のエスケープされていない二重引用符は、フィールドをそこで終わらせてしまう
  • 改行を含む複数行セル(埋め込み改行のある台詞など)はCSVの仕様上は合法だが、自作パーサーの多くはそれを想定しておらず行が分割される
  • スプレッドシートソフトのエクスポート時のエンコーディングは保証されない。システムのロケールによってはデフォルトでレガシーなエンコーディングで書き出されることがあり、非ASCII文字が黙って壊れる
key,en,ja
shop.buyButton,Buy,購入
shop.buyConfirmSentence,"Buy this item, right now?",本当に購入しますか？

JSON: 構造化されていてツール親和性が高いが、生編集には向かない

JSONの強みは構造にあります。ネストがキーの名前空間をそのまま反映し、ほぼすべての言語ランタイムがすでにJSONパーサーを持っているため、独自のパース処理を書いて間違える余地がありません。厳格なフォーマットで、末尾カンマもコメントも不正です — これはまさに機械には都合がよく、人には都合が悪い性質です。

  • コメント用のフィールドがないため、翻訳者への文脈情報は別のキーや別ファイルに置く必要がある
  • 同じネストしたオブジェクトを2人が並行編集すると、マージ衝突が起きやすい。CSVの行のような行単位の粒度がJSONにはないため、手作業での解消が煩雑
  • 生のJSONファイルを翻訳者に渡すと、括弧の欠落やカンマの抜けが起きやすく、それがバリデーションで黙って失敗するか、さらに悪いことに失敗すらせず、ゲームが読み込む段階になって初めてパースできない
{
  "shop": {
    "buyButton": "Buy",
    "buyConfirmSentence": "Buy this item, right now?"
  }
}

フォーマット自体より本当に大事なこと

どちらのフォーマットの弱点も、それ単体で致命的ではありません。ファイルを取り巻くパイプラインが、いくつかの性質を意識して設計されていれば十分に管理できます。

  • 単一の原本: 1つのファイル(または1つの生成済みエクスポート)を正とし、誰も後で突き合わせが必要になるコピーを手編集しない
  • 差分の読みやすさ: 小さなテキスト変更は小さく読みやすい差分になるべき。キーの順序が変わったJSONの再シリアライズや、インデントの変わったCSVは、実際の内容がほぼ変わっていなくてもこれを台無しにする
  • 往復安全性: ファイルをインポートして再エクスポートしたとき、意図した変更以外はバイト単位で安定しているべき。そうすればレビューツールやバージョン管理は、書式のノイズではなく実際の編集を表示できる
  • エンコーディングは前提ではなく明示: どちらのフォーマットで運ぶにせよ、パイプラインに入る前にすべてのファイルがUTF-8であることが明記されているか、検証されている

現実的な使い分け

よくある実践的なパターンは、ツールで検証できる構造化フォーマット(JSONやデータベース)を原本として保持し、翻訳工程専用にCSVエクスポートを生成する方法です。その後、再インポートして再検証してからマージします。こうすれば翻訳者は使い慣れたスプレッドシートのワークフローを得られ、ゲームのデータモデルは、誰かのスプレッドシートアプリを経由した手編集CSVが無傷で往復することに依存せずに済みます。

関連記事