ローカライズ テスト
ローカライズテストの進め方
ローカライズテストは、訳文だけを見る作業ではありません。言語、画面動作、翻訳ファイルの三つを分けると、問題の原因と担当を整理しやすくなります。
対応形式：JSON、YAML、XLIFF、Android XML、Apple .strings/.xcstrings、Java .properties
例
三つの確認レイヤー
言語: 自然さ・用語・文脈 画面: 文字切れ・配置・操作 ファイル: キー・トークン・タグ・構造
推奨する順序
1. 翻訳ファイルQA 2. ビルド・画面テスト 3. 言語レビュー 4. 修正版の再チェック
最初にテスト範囲を分ける
翻訳の自然さ、UI上の文字切れ、ファイルのキー漏れは、それぞれ確認方法も修正担当も異なります。すべてを一つのレビュー表で扱うと、構造ミスが表現コメントに埋もれたり、同じ問題を複数担当者が追ったりします。
自動化できるファイル差分を先に確認し、その後に実機・画面と言語の判断へ進むと、ビルド前に止められる問題を早く切り分けられます。
翻訳ファイルQAで確認する項目
原文と訳文でエントリが揃っているか、プレースホルダーとタグが維持されているか、原文のまま残った候補がないかを確認します。日本語では、トークン記号の全角化、文字コード、意図しない半角スペースも確認対象になります。
- キー・ユニットの欠落
- 余分な旧エントリ
- プレースホルダー不一致
- タグの欠落・追加
- 未翻訳候補
- 全角・半角の不整合
画面テストと人の判断を残す
ファイルが正しくても、ボタン幅、改行、日付や数値の形式、右から左の表示、画像内テキストなどは実際の画面で確認します。訳語の自然さやブランドトーンも人のレビューが必要です。
LocaleQAはファイル構造の決定論的チェックを担当し、実機テストや翻訳品質評価を置き換えません。役割を限定することで、同じ入力に対して同じ結果を返します。