ローカライズQA

ローカライズQAとは？

ローカライズQAは、訳文の自然さだけを見る工程ではありません。リリース前に翻訳ファイルがアプリの期待する形を保っているか確認する、実務上かなり重要なチェックです。

例

原文JSON

{
  "checkout.total": "Total: {amount}",
  "checkout.pay": "Pay now"
}

訳文JSON

{
  "checkout.total": "合計: {price}",
  "checkout.cancel": "キャンセル"
}

検出したいこと

キー漏れ: checkout.pay
余分なキー: checkout.cancel
プレースホルダー不一致: {amount} と {price}

訳文が自然でも、キーが欠けていたり、プレースホルダーが変わっていたりすると、画面表示やビルドで問題になります。これは翻訳力の問題というより、ファイルの受け渡しやリリース前チェックの問題です。

開発側はキーと実行時トークンを気にします。PMは納品物として揃っているかを見ます。ベンダーは差し戻しを減らしたい。QA担当は、言語以前のファイル不備でテストが止まるのを避けたい。LocaleQAはその重なる部分を決まったルールで比較します。

JSONとして構文が正しくても、翻訳ファイルとして構造が崩れていれば問題になります。キー漏れ、古いキーの残り、プレースホルダーの書き換え、原文のまま残った文字列は、JSONの構文チェックだけでは見つかりません。

LocaleQAは原文JSONと訳文JSONを比較し、構造上の不整合を決定論的に判定します。翻訳生成や言語品質の採点は行いません。

キー漏れやプレースホルダーの変更は、翻訳者のミスだけでなく、ブランチの差分、古い翻訳ファイルの流用、手作業での編集、翻訳メモリからの再利用などでも発生します。

CIやビルド前のチェック工程に組み込むことで、画面テスト前に検出できます。結果はHTMLやPDFレポートとして共有できるため、開発・翻訳・QA間で確認内容を共有しやすくなります。

リリース前や納品前には、少なくとも次の観点を確認しておくと手戻りを減らせます。