# General Translation Knowledge Base: 疑似ローカライゼーションとは？ URL: https://generaltranslation.com/ja/kb/pseudo-localization.mdx Docs index: https://generaltranslation.com/llms.txt Description: 疑似ローカライゼーションは、原文をアクセント記号付きで約40%長く水増しし、括弧で囲んだ改変版に置き換えるテストです。これにより、ハードコードされた文字列、切り詰め、フォントの表示崩れ、文の連結といった問題を、翻訳を用意する前に発見できます。Android にはこの用途向けに en-XA と ar-XB の疑似ロケールが用意されています。 Category: 国際化 Last updated: 2026-10-20 Authors: Kevin Wu, Jackie Chen Published: 2026-10-20 疑似ローカライゼーション (pseudolocalization とも表記) は、翻訳の品質ではなく、コードが翻訳に対応できる状態になっているかをテストする手法です。改変後のテキストもそのまま読めるため、チームの誰もが疑似ロケールでアプリを操作し、表示が崩れる箇所を見つけられます。数秒で実行でき、コストもかからず、開発初日から取り入れられます。 ## 疑似翻訳と疑似ロケールの違いは何ですか？ [Microsoft のグローバリゼーションに関するドキュメント](https://learn.microsoft.com/en-us/globalization/methodology/pseudolocalization)では、これを2つに分けて説明しています。 * **疑似翻訳 (Pseudotranslation) ** は文字列そのものを変換します。たとえば「Save changes」は `[Šáṽé çĥáñĝéš~~~~~]` のような文字列になります。 * **疑似ロケール (Pseudo-locale) ** は、Windows の `qps-ploc` や Android の `en-XA` のような架空のロケールコードで、実在の言語と同じように選択できます。中には、フォーマット処理のコードをテストするために、あえて変則的な日付・時刻・数値の書式を持たせたものもあります。 Microsoft は、形式としては正しいものの、実在のロケールを表すことが決してないコードの使用を推奨しています。たとえば Windows の `qps-` コードは、BCP 47 が私用のために予約している範囲に含まれます。これは Microsoft 自身の苦い経験に基づく教訓です。同社が最初に使った疑似ロケールは `tk-TM` (トルクメン語、トルクメニスタン) でしたが、後にこれが実際の Windows ロケールとして提供されることになり、ビルドシステムやテストシステムで衝突が起きてしまいました。 ## 疑似ローカライゼーションで検出できるバグ * **ハードコードされた文字列。** i18n レイヤーを経由していないテキストは、周囲がアクセント付き文字に変わる中で英語のまま残るため、どの画面でもすぐに目に付きます。 (コード内でこれらを見つける方法については、[翻訳されていないハードコードされた文字列を見つけるには？](/kb/find-hardcoded-strings)を参照してください) * **テキストの伸長による切り詰めやはみ出し。** 文字列をパディングすることで、どのボタン、タブ、テーブルヘッダーが見切れるか、不自然に折り返すか、コントロールを画面外に押し出してしまうかがわかります。 * **エンコーディングとフォントの問題。** アクセント付き文字や非ラテン文字を表示すると、エンコーディングの破損、グリフが含まれていないフォント、ダイアクリティカルマークが欠けてしまう行の高さなどが明らかになります。 * **文字列の連結。** 断片を組み合わせて作られた文は、1 つの文ではなく `[Ýöû ĥáṽé~~~~] 3 [íţéɱš~~]` のように角括弧で囲まれた複数の断片として表示されます。つまり、翻訳者には文全体ではなく断片だけが渡されてしまうということです。 * **右から左への対応漏れ。** RTL の疑似ロケールを使うと、レイアウトが左右反転するか、どのアイコンを反転させる必要があるか、左から右の値がどこで崩れるかを確認できます。 ([CSS で RTL (右から左) 言語に対応するには？](/kb/right-to-left-css)を参照してください) ## 疑似ローカライゼーションはどのように機能するのか？ ほとんどのツールは、次の手法をいくつか組み合わせています。 * **アクセント記号と他の文字体系。** Microsoft のガイドにあるように、`a` を `á`、`ä`、`å` などの文字に、数字を丸囲み数字に置き換えます。 * **長さの拡張。** 各文字列を長くします。翻訳元が英語の場合、Microsoft は目安として約 40% の拡張を推奨しています。また、翻訳後に 200%、場合によっては 400% も長くなる文字列があり、特に 1〜2 語の短い文字列ほど大きく伸びると指摘しています。 * **区切り文字。** 各文字列を角括弧やキャレットなどのマーカーでラップします。閉じマーカーが見当たらなければ、テキストが途中で切り詰められています。 * **識別子。** 必要に応じて各文字列に短い ID を付け、テスターが翻訳元を特定できるようにします。 * **右から左。** テキストの方向を反転させ、アラビア語やヘブライ語と同じ状態で UI の挙動を確認できるようにします。Android の `ar-XB` や、Windows のミラー化された `qps-plocm` がこの方式です。 翻訳によって逆に短くなることもあります。幅の変化は、特定のフォント、サイズ、ウェイトでレンダリングされた個々の文字列ごとに生じるものであり、言語全体で一定の割合になるわけではありません。パディングした疑似翻訳で確認できるのは拡張です。ラベルが短くなる場合や余白、配置については、実際の翻訳でも確認してください。 ## 疑似ロケールを標準搭載しているプラットフォームは？ | プラットフォーム | 疑似ロケール | 機能 | 有効にする方法 | | ------------------- | ---------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | | Android | `en-XA`、`ar-XB` | `en-XA` はアクセント記号の付加、テキストの伸長、各メッセージの括弧囲みを行います。`ar-XB` はメッセージを右から左の表示に切り替え、文字を逆順にします | debug ビルドタイプで `pseudoLocalesEnabled` を設定します。次に開発者向けオプションを有効にしてデバイスを再起動し、言語設定で疑似ロケールを選択します | | Xcode (iOS, macOS) | Double-Length、Right-to-Left、Accented、Bounded String、Tall などの疑似言語 | 文字列長を 2 倍にする、書字方向を反転する、アクセント記号を付加する、文字列を囲んで切り詰めを検出しやすくする、縦方向の高さを増やす | **Product > Scheme > Edit Scheme > Run > Options** を開き、**App Language** メニューから選択します | | Windows | `qps-ploc`、`qps-plocm`、`qps-ploca` (Windows 10 以降は `qps-Latn-x-sh` も) | 日付、フォント、文字列長のテストデータを含む、基本・ミラー (右から左) ・東アジア向けの疑似ロケール | `GetLocaleInfoEx` などの NLS API に疑似ロケール名を渡します。Microsoft の Multilingual App Toolkit を使うと、リソースを擬似翻訳できます | | Lingui (JavaScript) | `pseudo-LOCALE` など、任意の名前のロケール | コンパイル時にアクセント付きのメッセージを生成します。右から左のバリアントも任意で生成できます | Lingui の設定の `pseudoLocale` キー | Android では、[疑似ロケールのガイド](https://developer.android.com/guide/topics/resources/pseudolocales)のとおり、モジュールの Gradle ファイルで有効にします: ```kotlin title="build.gradle.kts" android { buildTypes.getByName("debug") { isPseudoLocalesEnabled = true } } ``` [Gradle リファレンス](https://developer.android.com/reference/tools/gradle-api/8.3/null/com/android/build/api/dsl/BuildType)によると、`resourceConfigurations` フィルターを使えば APK から疑似ロケールのリソースを除外できます。Xcode では、同じスキーム設定画面に **Show non-localized strings** というオプションもあり、Xcode がエクスポートしない文字列をすべて大文字でレンダリングします (Apple の [Preparing your interface for localization](https://developer.apple.com/documentation/xcode/preparing-your-interface-for-localization) を参照) 。Windows では [Pseudo-Locales](https://learn.microsoft.com/en-us/windows/win32/intl/pseudo-locales) ページにコードの一覧が掲載されており、これらはデフォルトではシステムロケールとして列挙されないと説明されています ([Using pseudo-locales](https://learn.microsoft.com/en-us/windows/win32/intl/using-pseudo-locales-for-localization-testing)) 。Lingui のセットアップ方法については、[疑似ローカライゼーションガイド](https://lingui.dev/guides/pseudolocalization)に記載されています。 ## JavaScriptで文字列を疑似ローカライズする Web には組み込みの疑似ロケールがありませんが、変換処理は数行で実装できます。以下の例では、ASCII 文字にアクセント記号を付け、文字列を約 40% 長くし、結果を括弧で囲みます。`{placeholders}` と HTML タグには手を加えないため、補間とマークアップはそのまま機能します: ```js title="pseudo.mjs" // ASCII 文字に似たアクセント付き文字 const ACCENTS = { a: 'á', b: 'ƀ', c: 'ç', d: 'ð', e: 'é', f: 'ƒ', g: 'ĝ', h: 'ĥ', i: 'í', j: 'ĵ', k: 'ķ', l: 'ļ', m: 'ɱ', n: 'ñ', o: 'ö', p: 'þ', q: 'ǫ', r: 'ŕ', s: 'š', t: 'ţ', u: 'û', v: 'ṽ', w: 'ŵ', x: 'ẋ', y: 'ý', z: 'ž', A: 'Á', B: 'Ɓ', C: 'Ç', D: 'Ð', E: 'É', F: 'Ƒ', G: 'Ĝ', H: 'Ĥ', I: 'Í', J: 'Ĵ', K: 'Ķ', L: 'Ļ', M: 'Ṁ', N: 'Ñ', O: 'Ö', P: 'Þ', Q: 'Ǫ', R: 'Ŕ', S: 'Š', T: 'Ţ', U: 'Û', V: 'Ṽ', W: 'Ŵ', X: 'Ẋ', Y: 'Ý', Z: 'Ž', }; // {name} のようなプレースホルダーや のようなタグは変更せずに保持する必要がある const PROTECTED = /(\{[^}]*\}|<[^>]+>)/; export function pseudoLocalize(text, { expansion = 0.4 } = {}) { const accented = text .split(PROTECTED) .map((part, i) => i % 2 === 1 ? part : part.replace(/[A-Za-z]/g, (ch) => ACCENTS[ch]) ) .join(''); // 翻訳後にテキストが長くなる状況を再現するため、翻訳元の長さの約 40% 分をパディングする const padding = '~'.repeat(Math.ceil(text.length * expansion)); // 角括弧で文字列の開始位置と終了位置を示し、切り詰めが一目でわかるようにする return `[${accented}${padding}]`; } ``` ```js title="demo.mjs" import { pseudoLocalize } from './pseudo.mjs'; for (const source of ['Save changes', 'Hello, {name}!', 'Read the terms']) { console.log(pseudoLocalize(source)); } ``` Node.js 24 で `node demo.mjs` を実行した結果: ```text title="Output" [Šáṽé çĥáñĝéš~~~~~] [Ĥéļļö, {name}!~~~~~~] [Ŕéáð ţĥé ţéŕɱš~~~~~~~~~] ``` 使用するには、デバッグ用のフラグまたは疑似ロケールが有効になっている間、i18n レイヤーが返すすべてのメッセージにこれを適用します。そうすれば、連結された文はひと目でわかります： ```js title="concatenation.mjs" import { pseudoLocalize } from './pseudo.mjs'; // ❌ 3つに分割されている：翻訳者が文全体を目にすることはない console.log(pseudoLocalize('You have') + ' 3 ' + pseudoLocalize('items')); // ✅ プレースホルダーを含む1つのメッセージ console.log(pseudoLocalize('You have {count} items')); ``` ```text title="Output" [Ýöû ĥáṽé~~~~] 3 [íţéɱš~~] [Ýöû ĥáṽé {count} íţéɱš~~~~~~~~~] ``` このプレースホルダー用の正規表現は、単純な `{name}` 変数を処理します。ICU の plural や select のメッセージでは波括弧が入れ子になるため、生のメッセージではなく書式設定後の出力に対して疑似ローカライズを行ってください。 [`pseudo-localization`](https://github.com/tryggvigy/pseudo-localization) npm パッケージについても同様です。`pseudoLocalizeString('Hello, {name}!')` は `Ħḗḗŀŀǿǿ, {ƞȧȧḿḗḗ}!` を返し、プレースホルダー名にもアクセントが付いてしまうため、README に示されているとおり翻訳済みの出力に対して実行してください。 このパッケージには、右から左 (RTL) 表示のテスト用の `bidi` ストラテジーや、ページ全体を疑似ローカライズする DOM モードもあります。RTL を自前で確認する場合は、疑似ロケールが有効になっている間、`` 要素に `dir="rtl"` を設定してください。 ハードコードされた文字列を見つけるには、変換を i18n の境界で行ってください。ページ全体の DOM を変換するとハードコードされたテキストまで変更されるため、レイアウトの確認には使えますが、どの文字列が翻訳呼び出しを経由していないのかがわからなくなります。また、書式設定済みの出力を変換すると、補間された名前などのデータも変更されてしまいます。そうした出力の変換はテスト用の UI 内にとどめてください。 ## 疑似ローカライゼーションでテストできないこと 疑似ローカライゼーションでは、翻訳の品質、語順、トーンについては何もわかりません。また、複数形規則の検証もできません。英語の複数形は2つ、アラビア語は6つありますが、アクセント記号を付けた英語の文字列でも、複数形は英語の2つのままです。Microsoft のガイドでも、疑似ローカライゼーションは翻訳済みアプリケーションの検証を「完全に置き換えるものではない」と述べられています。リリース前には実際の言語でもテストしましょう。確認すべき項目については、[多言語アプリのリリースチェックリスト](/kb/multilingual-app-launch-checklist)を参照してください。 ## 疑似ローカライゼーションと実際の翻訳を組み合わせる General Translation を使えば、開発中に実際の翻訳をテストできます。実行時翻訳の権限を持つプロジェクトAPIキーを使用すると、`gt-next` は GT のサービスにオンデマンドで翻訳をリクエストします。ドイツ語に切り替えて実際の文言やレイアウトを確認したり、複数形規則が異なる言語に切り替えて各分岐の動作を検証したりしましょう。[``](/docs/react/reference/components/t) や翻訳関数で囲まれていないテキストは、翻訳元の言語のまま表示されます ([Next.js クイックスタート](/docs/react/nextjs-quickstart)を参照) 。初期段階のレイアウト確認には、テスターが読める疑似ローカライゼーションを使い、その後 [CLI](/docs/cli/reference/commands/translate) でリリース用の翻訳を生成して、GT の[翻訳エディター](/docs/platform/dashboard/guides/reviewing-translations)と実行中のアプリの両方でレビューしてください。英語の文字数を水増ししただけでは、翻訳文が正しいかどうかも、同じスペースに収まるかどうかも判断できません。 ## 重要なポイント * 疑似ローカライゼーションは、原文をアクセント付き、パディング付き、括弧付き、または鏡像化したテキストに置き換えることで、翻訳を始める前に i18n のバグを見つける手法です。 * ハードコードされた文字列、切り詰め、フォントやエンコーディングの問題、文の連結、右から左への表記への未対応などを検出できます。 * Android (`en-XA`、`ar-XB`) 、Xcode (スキームのオプション内の疑似言語) 、Windows (`qps-ploc`、`qps-plocm`、`qps-ploca`) には標準で組み込まれています。Web では、短い変換関数を書くか `pseudo-localization` パッケージを使えば十分です。 * 翻訳の品質や複数形規則はテストできません。これらは実際の翻訳を使ってテストしてください。`gt-next` を使えば、開発中に翻訳をオンデマンドで生成できます。 ## Related questions - [翻訳されていないハードコードされた文字列を見つけるにはどうすればよいですか？](https://generaltranslation.com/ja/kb/find-hardcoded-strings.mdx): CI でリンターを実行し、ユーザー向けの文字列リテラルを検出します。たとえば JSX なら eslint-plugin-i18next の no-literal-string ルール、Android なら Android Lint の HardcodedText チェック、Rails なら erb_lint の HardCodedString リンターが使えます。さらに、疑似ロケールでアプリを一通り操作し、静的チェックでは追跡できないテキストを洗い出します。 - [CSS で RTL（右から左）言語をサポートするには？](https://generaltranslation.com/ja/kb/right-to-left-css.mdx): lang だけでは書字方向は変わらないため、html 要素に dir="rtl" と lang の両方を指定します。そのうえで、margin-left などの物理的な CSS を margin-inline-start などの論理プロパティに置き換えます。flex の行、グリッドの列、デフォルトのテキストの配置は自動的に反転しますが、translateX()、left、right は反転しません。 - [多言語アプリのローカライゼーションテスト チェックリスト](https://generaltranslation.com/ja/kb/multilingual-app-launch-checklist.mdx): 本番環境のビルドで、サポート対象のすべてのロケールについて次の9項目をテストしてください：エラー状態やメールを含むジャーニー全体、言語の切り替え、複数形、通貨とタイムゾーン、テキストの伸長、右から左のレイアウト、アクセシビリティ、翻訳の配信、クロール可能な言語別URL。各項目には明確な合格条件を設けてください。 - [国際化とローカライゼーションの違い（i18n vs. l10n）](https://generaltranslation.com/ja/kb/internationalization-vs-localization.mdx): 国際化（i18n）とは、1つのプロダクトで多数のロケールをサポートできるようにするためのコードと設計の作業です。たとえば、Intl を使った日付のフォーマットや、右から左に書くテキストへの対応などがこれにあたります。ローカライゼーション（l10n）は、プロダクトを特定のロケールに合わせて最適化する作業で、翻訳に加えて通貨、日付形式、単位、トーン、法的な細部などを扱います。 ## Previous and next questions - Previous question: [多言語SEOにおけるサブディレクトリ・サブドメイン・ccTLDの比較](https://generaltranslation.com/ja/kb/multilingual-url-structure.mdx) - Next question: [翻訳されていないハードコードされた文字列を見つけるにはどうすればよいですか？](https://generaltranslation.com/ja/kb/find-hardcoded-strings.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/ja/kb/sitemap.md) for every article.