ローカリゼーション テストでは、翻訳された Web サイトまたはアプリが各ターゲット市場の人々にとって正しく動作し、正しく読み取れるかどうかを確認します。次の 4 つのことをカバーしています 言語 (正確、自然、一貫性)、 レイアウト (何も切断されていない、重なり合っている、または誤ってミラーリングされている)、 関数 (フォーム、検索、チェックアウト、電子メールは引き続き機能します)および 地域の慣習 (日付、番号、通貨、住所)。最良のプロセスは、翻訳前に疑似ローカリゼーションを開始し、自動チェックと実際のページでのネイティブ スピーカーによるレビューを組み合わせます。
このハンドブックでは、段階的なプロセス、コピーできるチェックリスト、最小限の労力で最も多くのバグを検出するベスト プラクティスを提供します。
主なポイント
- テスト コンテキスト で、 実際のページやデバイスで。スプレッドシート内の文字列を確認すると、レイアウトと意味に関するほとんどの問題が見逃されます。
- 走る 疑似ローカリゼーション 翻訳する前に、ハードコードされたテキストや拡張できないレイアウトを見つけます。
- の予算 テキスト展開。英語の短いラベルは、他の言語では 2 倍以上の長さになる場合があります。
- 使用 ネイティブスピーカー 言語パスには用語集とスタイル ガイドが付属しているため、フィードバックは一貫しています。
- 発売時だけでなく、コンテンツやデザインが大幅に変更されるたびに再テストします。
ローカリゼーション テストでカバーされるもの
| エリア | 何をチェックするか | 典型的なバグ |
|---|---|---|
| 言語的 | 正確さ、トーン、用語、文法、文化的適合性 | 文字通りの翻訳、一貫性のない用語、間違った形式、翻訳されていない文字列 |
| ビジュアル / UI | テキストのフィット感、フォントのレンダリング、RTL ミラー、画像が市場に適合します | 切り捨てられたボタン、重なり合ったテキスト、グリフの欠落(“豆腐”)、ミラーリングされていないアイコン |
| 機能的な | フォーム、検索、フィルター、チェックアウト、ログイン、電子メール、リンク | 検証ではローカル名や郵便番号が拒否され、検索ではアクセントが無視され、リンクは間違った言語に移動します |
| ロケール規約 | 日付、時刻、番号、通貨、単位、住所、電話番号 | 03/04 は日付が間違っており、小数点区切りが間違っており、価格が間違った通貨で表示されています |
| SEOと技術 | lang 属性、翻訳されたタイトルと説明、フレフラン、正典 | フランス語のページに英語のメタタイトル、フレフランが欠落、正典は英語を指している |
ローカリゼーションテストと国際化テスト
国際化(i18n)テスト 製品であることを確認します できる ローカライズされる: テキストはハードコードされておらず、レイアウトは拡張され、コードは Unicode を処理し、日付と通貨はロケール設定から取得されます。これは機能ごとに 1 回、理想的には翻訳の前に行われます。
ローカリゼーション(l10n)テスト それぞれチェックします 特定の 言語版。追加するすべての言語に対して繰り返されます。
最も厄介なローカリゼーション バグは、実際には遅れて発見された国際化バグです。そのため、以下の最初のステップは翻訳の前に行われます。
ステップバイステップのローカリゼーションテストプロセス
ステップ1: 範囲と優先順位を定義する
言語、市場(スペインとメキシコのスペイン語は異なるテスト対象です)、範囲のページとフロー、訪問者が使用するデバイスとブラウザをリストします。ビジネスへの影響別にフローをランク付けします。サインアップ、チェックアウト、価格設定はキャリア ページの前に表示されます。
ステップ2:参考資料を準備する
翻訳者が使用したのと同じ資料をテスターに提供します
- ある 用語集 製品およびブランドの用語。承認された翻訳と英語のままでなければならない用語が含まれています。
- ある スタイルガイド 言語ごと: 公式または非公式の住所、口調、句読点、数字と単位の書き方。
- スクリーンまたはURL スコープ内のすべてのフローとテスト アカウントに対して。
これらがなければ、査読者はエラーを報告するのではなく、好みについて議論することになります。
ステップ3: 疑似ローカリゼーションを実行する
実際の翻訳の前に、ソース テキストを、たとえば “カートに追加” → “[Àdd ţö çàŕţ !!!!!]” のように、引き伸ばされたアクセント付きのバージョンに置き換えます。これはすぐに次のことを示します:
- ハードコードされた文字列 (彼らは平易な英語で話します)
- 壊れるレイアウト テキストが長くなると
- レンダリングされない文字 あなたのフォントで
- 連結された文字列 (“正しく翻訳できない項目”“があります” + count + items)
今すぐコードまたはテンプレートでこれらを修正してください。後で 12 か国語で見つけるよりもはるかに安価です。
ステップ4: 翻訳してから、コンテキスト内のテキストを確認します
翻訳が入ったら、査読者はそれを読む必要があります ライブまたはステージングページでファイル内ではありません。コンテキストの意味が変わります: “Book” は名詞または動詞になることができます。“Free” はコストや利用不可を意味します。チェック:
- ボタン、エラー メッセージ、ツールチップ、代替テキスト、電子メールなど、表示されているすべての文字列が翻訳されます。
- 用語は用語集に従います。
- トーンとフォーマルさはスタイルガイドと一致します。
- 画像、色、例、慣用句において、不快なもの、混乱を招くもの、文化的に不適切なものは何もありません。
ステップ5: ビジュアルとレイアウトのテスト
デスクトップおよびモバイル サイズですべてのインスコープ ページをテストします。特に注意してください:
- テキスト拡張。 W3Cの記事 翻訳におけるテキストサイズ IBM のガイドラインを引用しています。他のヨーロッパ言語では、最大 10 文字の英語の文字列が 200 から 300% 拡張され、70 文字を超える文字列は約 130% 拡張されます。メニュー、ボタン、タブ、テーブル ヘッダーが最初に壊れます。
- フォント。 空いているボックスや書体の突然の切り替えを探してください。これは、フォントにそれらの文字がないことを意味します。の私たちのリスト 多言語フォント スクリプトでフォントをカバーします。
- 右から左への言語。 アラビア語、ヘブライ語、ペルシア語では、ナビゲーション、方向のあるアイコン、プログレス バー、フォーム フィールドなど、レイアウト全体をミラーリングする必要があります。のガイドをご覧ください RTLデザイン.
- 改行。 日本語、中国語、タイ語などの言語では単語間にスペースが使用されないため、テキストが賢明に折り返されていることを確認してください。
ステップ 6: ロケールごとの機能テスト
各言語の各キーフローを順に説明します
- フォーム ローカル名(アクセント、アポストロフィ、非ラテン文字)、ローカル郵便番号、電話形式を受け入れ、エラー メッセージを適切な言語で表示します。
- 検索とフィルター アクセントの有無にかかわらず結果を見つけ、ローカル順序でアルファベット順に並べ替えます。
- チェックアウト 適切な通貨、税金、支払い方法、配送オプションを表示します。
- メールと通知 フローによってトリガーされ、訪問者の言語で到着します。
- リンクとリダイレクト 訪問者の言語をそのままにしておきます。言語スイッチャーはホームページではなく同じページに移動します。
ステップ7: ロケール形式を確認する
日付(03/04/2026 ヨーロッパの多くの地域では4月3日、米国では3月4日を意味します)、時間(12時間または24時間)、数字(1,234.56 対。 1.234,56 対。 1 234,56)、通貨とその位置、測定単位、住所の順序、暦上の週の最初の日。
ステップ8: SEOと技術チェックを実行する
- の
<html lang>属性は表示されている言語と一致します。 - タイトルとメタディスクリプションが翻訳されています。
- 各言語には独自の URL があり、hreflang はすべてのバージョンと自己参照標準をリンクします。に関する私たちの記事 自己参照hreflangタグ 数分でこれを確認する方法を示します。
- メインコンテンツは実際に翻訳されています。Googleの 多言語サイトガイダンス コードレベルの属性ではなく、“ページの表示コンテンツを使用して言語を決定する” と表示されます。
ステップ9: ログ記録、修正、再テスト
言語、URL、スクリーンショット、現在のテキスト、提案された修正、および重大度を使用して、各問題をログに記録します
- 重要なこと: フローをブロックしたり、意味を変更したりします(間違った価格、壊れたチェックアウト、攻撃的なテキスト)。
- 専攻: 明らかに間違っているか混乱していますが、タスクは完了できます。
- マイナー: スタイル、間隔、または小さな不一致。
1 つのテンプレート修正がすべてのページに影響を与えることが多いため、修正してから、影響を受けるページをすべての言語で再テストします。
ステップ10: 起動後もテストを続ける
ローカリゼーションは起動時に完了していません。新しいページ、新しい製品、デザインの変更により、新しい文字列が作成されます。リリース チェックリストにローカリゼーション チェックを追加し、数か月ごとに言語ごとにトップ ページのレビューをスケジュールします。
ローカリゼーションテストチェックリスト
- テスターと共有される用語集とスタイルガイド
- 擬似ローカリゼーション実行、ハードコードされた文字列を修正
- 表示されているすべてのテキストが翻訳されています(エラー、ツールチップ、代替テキスト、電子メールを含む)
- 一貫して使用される用語集
- デスクトップやモバイルでは、切り捨てられたり、重複したり、オーバーフローしたりするテキストはありません
- フォントはすべての文字をレンダリングします
- RTLレイアウトが正しくミラーリングされました
- フォームでは、現地の名前、住所、電話番号を受け入れます
- 検索、並べ替え、フィルターはローカル文字でも機能します
- 価格、税金、支払い、配送は市場ごとに正しいです
- ローカル形式の日付、番号、単位
- 言語スイッチャーは訪問者を同じページに保ちます
-
lang属性、翻訳されたメタデータ、hreflang および正規表現が正しい - 重要かつ主要な問題が修正され、再テストされました
ベストプラクティス
常にコンテキスト内でテストします。 ほとんどの深刻な問題は実際のページにのみ表示されます。
製品を知っているネイティブスピーカーを使用してください。 あなたの製品を使用したことのない流暢な話者は、用語の間違いを見逃してしまいます。
機械的なものを自動化します。 スクリーンショットの比較、翻訳されていないテキストや不足している hreflang にフラグを立てるクローラー、およびフォーム テストは、すべてのリリースで実行できます。
用語については真実の情報源を 1 つ保持してください。 レビュー担当者が変更に同意したら用語集を更新し、修正がすべてのページに広がるようにします。
根本原因を修正します。 ドイツ語でボタンが壊れた場合、修正は通常、短いドイツ語の単語ではなく、柔軟なレイアウトになります。
ConveyThis がローカリゼーション テストをサポートする方法
ConveyThisは文脈の中で翻訳をレビューすることを中心に構築されています。の ビジュアルエディター 翻訳されたページを訪問者が見たときに表示するため、文言を修正し、レイアウトの問題を同時に特定できます。の 用語集 サイト全体で用語の一貫性を維持し、 チームの役割 言語ごとに翻訳者やネイティブスピーカーの査読者を招待し、翻訳メモリは承認された翻訳を再利用します。翻訳されたページには hreflang を使用して独自の URL が付与され、タイトルと説明も翻訳されるため、ステップ 8 の大部分がカバーされます。
レビュー ワークフローがどのように機能するかを確認してください 翻訳品質 ページ、何が含まれているか 特徴、 およびプランの制限 価格設定ページ。テストを超えた広範なプロセスについては、以下をお読みください ウェブサイトのローカリゼーション.
よくある質問
ローカリゼーションテストとは何ですか? Web サイトまたはアプリの各言語バージョンが正確で、レイアウトに適合し、機能的に動作し、ローカルの規則に従っていることを確認します。
擬似ローカリゼーションとは何ですか? 翻訳前にソース テキストをストレッチされたアクセント付きプレースホルダーに置き換えて、長いテキストを処理できないハードコードされた文字列やレイアウトを見つけます。
ローカリゼーションテストは誰が行うべきですか? 機能的および視覚的なチェックを行う QA テスター、言語レビューのために製品を知っているネイティブ スピーカー、そして理想的には文化的適合性のターゲット市場の人。
ローカリゼーションテストはどのくらいの頻度で実行すればよいですか? 発売時には、テキストやレイアウトを変更するすべてのリリースで、言語ごとに最も重要なページを定期的にレビューします。
訪問者が見る前に、実際のページにあるすべての翻訳を確認したいですか? ConveyThis アカウントを作成します そしてビジュアルエディターでサイトを開きます。