回答。

自動テストの最初の波は、主に英語のインターフェースに焦点を当てていたため、ローカリゼーション (i18n) のチェックにはほとんど関与していませんでした。しかし、アプリケーションのグローバル化が進むにつれて、ローカリゼーションの品質に対する要求が高まりました：インターフェースはすべてのサポートされている言語で正しく表示され、テキストリソースやフォーマットされた文字列は選択されたロケールに応じて正しく読み込まれる必要があります。

主な問題は、手動チェックが非常にコストがかかることであり、フォーマット、文脈、言語の特異性（例えば、右から左へのテキストや文法的な特徴）によるバリエーションのために自動テストが複雑であることです。フラグメントの翻訳が存在しない、フォーマットエラー、レイアウトの破損などの問題がある可能性があります。

解決策には、各ロケールのテストデータの使用、スナップショットテストの実施、UI要素を基準と比較すること、「キー-バリュー」方式によるリソースファイル用の検証ユーティリティの導入、APIインターフェースを介した行の自動抽出と比較、およびリソースファイルに対するリンターの定期的な実行が含まれます。

主な特徴:

すべてのサポートされている言語の存在と正しい表示の確認。
基準翻訳とインターフェース上の現在の表示の比較。
レイアウトの破損を避けるためのテキストの長さとフォーマットのバリデーター。

騙しの質問。

1つのスクリプトで任意のロケールを検証するユニバーサルテストを作成できますか？

部分的には可能ですが、言語のニュアンス（格、性、入力の方向）はしばしば手動の調整や追加の条件を必要とします。100% のユニバーサル性は不可能です。

翻訳ファイルが存在し、正常に読み込まれている場合、それは i18n テストが合格していることを意味しますか？

いいえ。ファイルがアプリケーション側で正しくリンクされていない可能性があり、キーにエラーがあるかもしれません。翻訳の使用文脈が壊れている可能性や、考慮されていない特殊文字が存在する場合があります。

1%未満のユーザーのための言語のローカリゼーションテストを自動化する意味はありますか？

はい。たとえ1人のユーザーでもビジネス的に重要である場合、契約上の義務の履行や特別な要件を持つ市場において、それは避けられません。自動化は手動のチェックに比べて、リソースを大幅に節約できます。

一般的なエラーとアンチパターン

ファイルの存在だけを確認し、UI内での実際の表示を確認しない。
言語の文法やフォーマットの特性を考慮せずに文字列を厳密に比較する。
手動調整なしでロケールからロケールにテストを盲目的にコピーする。

実生活の例

ネガティブケース

チームは、.poファイルのキーを元の英語のテキストと比較する自動テストを導入し、それだけで十分だと考えました。UIテストは作成せず、アラビア語版のリリースで、すべてのテキストがボタンの境界を超えてズレて表示され、いくつかの行は誤ったキーのために全く翻訳されなかったことが判明しました。

利点:

i18nにおける自動化の迅速な導入。

欠点:

実際のユーザーシナリオのカバレッジが低い。
重大なUXエラーが見逃されました。

ポジティブケース

リソースのリンティングと自動テストが実装され、すべての言語のインターフェースを回転させ、スクリーンショットを撮影し、基準となるレイアウトと比較しました。RTL/LTR要素の混在を発見したチームは、その根本原因を特定し、リリース前に修正しました。