アプリ ローカライズ
アプリのローカライズで確認すべきポイント
アプリのローカライズでは、訳文の自然さだけでなく、各プラットフォームが読み込む翻訳ファイルの構造を壊さないことがリリース条件になります。
対応形式:JSON、YAML、XLIFF、Android XML、Apple .strings/.xcstrings、Java .properties
例
プラットフォーム別の代表形式
iOS: Localizable.strings / .xcstrings Android: res/values/strings.xml Web: JSON / YAML 共通交換形式: XLIFF
リリース前に検出したい問題
キー・リソースの欠落 %1$s や %@ の変更 タグ・複数形ユニットの崩れ 原文のまま残った文字列
アプリのローカライズはファイル実装まで含む
画面上の日本語が自然でも、翻訳ファイルからキーが消えていたり、実行時に値を差し込むトークンが変わっていたりすると、表示欠落やクラッシュにつながります。アプリのローカライズは翻訳、ファイル受け渡し、組み込み、画面確認を分けて管理する必要があります。
iOS、Android、Webでは形式が異なりますが、原文と訳文でエントリを対応させ、プレースホルダーやタグを維持するという基本は共通です。
iOS・Androidで壊れやすい箇所
iOSでは %@、%d、位置指定子、String Catalog内のローカリゼーションが重要です。Androidでは strings.xml のリソース名、書式指定子、plurals の quantity、インラインタグを維持します。IME入力による記号の全角化も日本語案件で起きやすい問題です。
- Localizable.stringsのキー
- .xcstringsのロケール
- strings.xmlのname属性
- pluralsのquantity
- 位置指定プレースホルダー
- タグとエスケープ
どの段階でQAするか
翻訳会社や担当者からファイルが戻った直後、開発ブランチへマージする前、ローカライズ済みビルドを作る前の三点が確認しやすいタイミングです。ファイルQAを先に終えると、実機テストではレイアウト、文脈、操作性に集中できます。
LocaleQAは同じ形式の原文と訳文を比較し、決められたルールで構造上の差分をレポートします。翻訳表現の良し悪しは判定しません。