グローバルアプリ向けアプリ国際化ガイド

あなたのアプリは次の市場に備えています。製品チームは翻訳されたコピーを承認し、Marketingチームはリリースを準備し、カスタマーサポートチームはスクリプトを更新しました。しかし、テストではチェックアウトボタンが英語でハードコードされていることが判明し、日付は間違った順序で表示され、通貨は不慣れな区切り文字を使用し、長い翻訳が主なアクションを画面外に押し出していることがわかりました。ただし、翻訳の質だけではリリースがブロックされません。それがコードベースで数ヶ月前に行われた決定によるものです。

その状況はアプリ国際化の実践的な出発点です。 アプリ国際化国際化は通常、i18nと省略され、言語、地域、書式、文化規範を追加することなくビジネスロジックを書き直さなくても済むように製品を準備することを目的としています。すると、ローカライゼーションは特定の市場に適応させることができます。

商業的なケースはアプリ経済で見ることができます。730,024のiOS App Storeアプリの2026年のスナップショットでは、メディアンアプリは正確に 1つの言語をサポートし、 68.6% 1つの言語で配信されます。月額 $10,000以上を稼ぐアプリは、 5つの言語, and 50.7% of that top revenue tier ships in five or more languages. Those figures don’t prove that localization alone creates revenue, but they show that multilingual support is much more common among apps with broader commercial ambitions.

This guide moves from the mental model to engineering patterns, platform differences, workflow automation, testing, and migration. It applies to native mobile products, web applications, Capacitor hybrid apps, and Electron desktop software. Privacy and regional compliance also belong in the launch plan, so teams working through regulatory requirements can pair this guide with a このガイドは、メンタルモデルからエンジニアリングパターン、プラットフォームの差異、ワークフローアutomation、テスト、移行まで、Nativeモバイル製品、Webアプリケーション、__CAPGO_KEEP_0__ハイブリッドアプリ、Electronデスクトップソフトウェアに適用される。プライバシーと地域の法令遵守も、規制要件を通して作業するチームが、このガイドとともにGDPRの遵守チェックリストを使用できるようにする必要がある。.

アプリの国際化の導入とその重要性
アプリの国際化とは何を意味する?
- 3つの用語、3つの責任
- 基盤がリスクを軽減する理由
国際化されたアプリに必要なコアパターン
モバイルWebとElectron向けのプラットフォーム固有の考慮事項Capacitor
スケーラブルな翻訳ワークフローとツールライブラリ
- パイプラインの重要性
- リリースエンジニアリングにおけるライブアップデート
グローバルアプリケーション向けのテストQAパフォーマンスとセキュリティ
- 攻撃的なコンテンツから始める
- ロケールマトリックスの自動化
Codeの例と移行チェックリストで全てをまとめる

アプリケーションの国際化入門とその重要性

市場リリースの数日前までに、チームは国際化を発見することがよくあります。製品は言語セレクターを要求し、デザインは何度も画面を調整し、エンジニアはユーザーフェイスのテキストがコンポーネント、バリデーションルール、通知、分析ラベル、ネイティブ設定ファイルに分散していることを発見します。日付と数字も同じ問題を引き起こします。表示テキストとして保存された日付は安全に再フォーマットできず、別のロケールでは別の順序で組み立てられた価格は誤解を招く可能性があります。

遅すぎた発見は、3つの高コストな選択肢を生み出します: リリースを遅らせる、可視的な欠陥を受け入れる、またはcodeを変更する。i18nをアーキテクチャ的能力として扱うことで、ワークフローが変わります。市場拡大は、リソース、プレゼンテーション、テスト、リリース設定を含むコントロールされたオペレーションになります。

実践的なルール: アプリケーションを構築するには、ロケールが新しくなったときにリソースとプレゼンテーションが変化するのではなく、ビジネスルールが変化するようにします。

翻訳はグローバルな準備のただ一つの部分です。 翻訳された文は、長さを考慮していないレイアウトを破壊する可能性があります。正しく翻訳された通貨は、値がフォーマットされたテキストとして保存されている場合にユーザーを誤解させる可能性があります。言語セレクターは、Web層とネイティブ層が異なるロケールを検出する場合に不一致な動作を生み出す可能性があります。

遅い国際化の発見は運用コストを上げます。エンジニアは古いコンポーネントの文字列を追跡する必要があります、翻訳者は不完全なコンテキストを受け取ります、レビュアーは急いで変更をテストし、リリースチームは複数のプラットフォームパッケージ間で修正を調整する必要があります。CapacitorとElectronチームにとって、ライブアップデートのワークフローは、ストアのレビューの待ちなしで承認されたローカライズリソースとプレゼンテーション修正を提供することで、このループを短縮できます。プラットフォームとリリースポリシーが許可する場合、重要なシフトはローカライズの変更を管理されたリリースアーティファクトとして扱うことです。

これから進む道は簡単です:

準備の基盤: ユーザーフェイスのリソースとアプリケーションロジックを分離し、モデルロケール感受性の値を正しく設定する。
言語の振る舞いを扱う: 複数規則、テキストの拡張、書き方の方向、フォーマット、そしてアクセシブルな言語の変更をサポートする。
各プラットフォームを適応させる: iOS、Android、ブラウザ、CapacitorのWebViews、そしてElectronのパッケージングを考慮する。
リリースを進める: 抽出、翻訳、レビュー、テスト、そしてデプロイを接続することで、新しい文字列が遅いプロジェクトフェーズを待つ必要がなくなる。
インターフェイスを確認する: 長いテキスト、右向左のレイアウト、ロケールの組み合わせ、フォールバックの動作、パフォーマンス、そしてアップデートの安全性をテストする。

アプリの国際化は、リリースエンジニアリングの分野です。後続の製品変更をローカライズ可能にし、適切な配信パスを通じてチームが言語問題を修正し、地域のプライバシー作業を含むGDPRの適合性チェックリストを含みます。アプリの国際化とは何ですか?.

家の例で始めましょう。

国際化は、誰も部屋を装飾する前に、家に取り付ける可変の配管と配管です。 ローカライズは、特定の地域のために家を装飾し、家具を整えることです。翻訳はラベル、指示書、看板の言語を変更することです。 順序は重要です。壁に設計されたアパレンツに配管を埋め込んだ場合、新しいアパレンツを追加することは高価になります。ソフトウェアでは、ハードコードされた文字列、固定幅のコントロール、連結された文、ロケール固有のビジネスロジックは、同じ制約を生じます。

3つの用語、3つの責任

国際化、またはi18n

アプリを異なる言語と地域をサポートできるようにする設計と開発作業です。リソースの読み込み、ロケールの選択、フォーマット、テキストの方向、フォントのサポート、フレキシブルなレイアウトを含みます。ローカライズ、またはl10n

準備されたアプリを特定のロケールに適応させることです。その場合、翻訳されたインターフェイスコピー、地域固有のフォーマット、ローカル用語、文化的に適切なイメージ、市場固有のデフォルトを含みます。 GDPRの適合性チェックリスト

翻訳 1つの言語から別の言語にコンテンツを変換する。主に意味と表現に関係するが、良い翻訳ワークフローにはコンテキスト、スクリーンショット、文字数制限、各文字列がどの場所で表示されるかについての情報も必要である。

アプリの国際化、ローカライズ、翻訳の概念を表す図。家のメタファを使用する。

ロケールリソースは実装境界として便利です。代わりに、 Payment failed コンポーネント内で直接、セマンティックキー（semantic key）などの意味のあるキーを要求します。 payment.errorリスクを軽減する理由

The same separation applies beyond strings. Store monetary values as values, not as strings with symbols attached. Store timestamps as timestamps, not as already-formatted dates. Pass locale information to formatters instead of embedding separators or month names in business code.

リスクを軽減することの意味

アプリの国際化、ローカライズ、翻訳の概念を表す図。家のメタファを使用する。

国際化も所有権の分離を改善します。デザイナーは拡張可能なコンポーネントを定義できます。翻訳者はコンテキストを確認できます。製品マネージャはサポートする市場を決定できます。エンジニアは欠落するキーとフォールバックルールを強制できます。各分野はワークフローで明確な役割を果たします。

i18nを省略するチームは、通常、各新しいロケールを特別な例外として扱います。i18nを設計するチームはロケールを入力として扱います。この単一のシフトにより、グローバルサポートを推論することが容易になります。

国際化されたアプリに必要なコアパターン

i18nの良い実践は、繰り返しパターンを通じて具体化されます。コンポーネント、データ、リリース層でそれらを適用するのではなく、単一のロケールコードベースの上に言語切り替え機能を追加するのではなく。

国際化されたアプリのための4つのコアパターンを示すピラミッド図。

文字列をリソースに抽出する

この変換は、実用的第一歩です。

前:

showToast("Your profile was saved");

後:

showToast(t("profile.saved"));

リソースファイル:

{
  "profile": {
    "saved": "Your profile was saved"
  }
}

意味を表すキーの使用、英語の文を使用しない profile.saved 文字列をリソースに抽出することは、実用的第一歩です。

Aプロパーに国際化されたアプリは、ユーザーフェイスの文字列、日付、数字、通貨、記号をすべてロケールリソースまたはフォーマッターに外部化します。このモバイルの国際化のエンジニアリング blue print ロケールリソースまたはフォーマッターに外部化することで、チームは言語を追加することができますが、ビジネスロジックを変更する必要はありません。

メッセージフォーマットを使用して文法

これは安全ではありません:

`${count} items`

ハードコードされたパターンは、すべてのロケールが同じ複数の動作と語順を使用することを前提としています。Unicode CLDRは、日付、時刻、時差、数字、通貨、複数のカテゴリの共通のロケールデータ層を提供します。CLDRのロケール化のベストプラクティスガイドは、複数の規則がロケールによって異なることを説明しており、ロケールに依存した選択が必要であり、1つの固定パターンではありません。

ICUスタイルのメッセージは次のようになります:

{count, plural,
  =0 {No items}
  one {# item}
  other {# items}
}

フォーマッターは正しいbranchを選択します。翻訳者が文法によって数値と名詞を並べ替えることができるように、全メッセージを保持してください。

値をロケールに依存したAPIでフォーマットします。

日付を手動で組み立てるのではなく、フォーマッターを使用してください。

`${day}/${month}/${year}`

同じ原理が数字と通貨にも当てはまります:

new Intl.DateTimeFormat(locale, {
  dateStyle: "medium"
}).format(date)

数字や通貨も同じ原則が適用されます。

new Intl.NumberFormat(locale, {
  style: "currency",
  currency: currencyCode
}).format(amount)

IntlICU、CLDRバックアップのライブラリは、地域によって異なる慣習を処理します。また、表示ロジックは、プレゼンテーション層に近い位置に保つ必要があります。

方向と拡張のための設計

テキストは予測できないように、言語によって拡大します。ボタンは可変幅が必要です。カードは可変高さが必要です。ラベルは1行に依存してはなりません。レイアウトシステムを使用して、コンテンツが成長できるようにし、翻訳者が最終レビューを開始する前に長い偽翻訳をテストしてください。

右向きのサポートには、テキストの配置を反転するだけでは十分ではありません。アイコン、ナビゲーション順序、パディング、アニメーション、方向のジェスチャーも反映する必要があります。 margin-inline-start logical

For interface-specific guidance, teams using Capacitor can also consult these インターフェース固有のガイダンスについては、__CAPGO_KEEP_0__を使用するチームは、以下の.

Platform Specific Considerations for Mobile Web Capacitor and Electron

プラットフォーム固有の考慮事項

Platform	コアのルールは一貫していますが、各ランタイムは異なるロケールシグナルとパッケージ制約を提供します。ネイティブアプリは、プラットフォームAPIを使用してデバイスの設定を読み取ることができます。ブラウザは、ブラウザ設定とJavaScript APIを使用して言語設定を公開します。ハイブリッドアプリには、WebViewとネイティブシェルがあり、チームはロケールの真実がどこにあるかを決定する必要があります。	フォーマットアプローチ	重要な注意事項
iOS	デバイスまたはアプリの言語設定、サポートされる場合にアプリ固有の動作	Foundation フォーマッタと JavaScript `Intl` ウェブコンテンツ用	ネイティブスクリーンと WebView スクリーンは、別のロケール状態を使用する場合にずれが生じる可能性があります
Android	デバイスとアプリの言語設定、実装に依存	Android ロケール API と JavaScript `Intl` ウェブコンテンツ内	リソースクォリファイアと WebView リソースには、故意のフォールバック戦略が必要です
Web	ブラウザの言語設定、ユーザーの選択、またはURLとアカウントの設定	JavaScript `Intl`, ICUバックアップのライブラリ、サーバーサイドのロケールハンドリング	サーバーとクライアントのロケール決定は一致する必要があります。非一致したレンダリングを避けるため
Capacitor	ネイティブ設定プラス WebView ステート	ネイティブのプリスペファレンスプラスウェブビューの状態 `Intl`ネイティブのフォーマッター、JavaScript	, 共有リソースバンドル
Electron	Electron	JavaScript `Intl`, Node側ロジック、そしてレンダラーのリソース	生産ビルドで、パッケージされたロケールアセットが正しく含まれ、読み込まれている必要があります。

ネイティブモバイルアプリケーション

iOS と Android はそれぞれのネイティブのローカライズシステムを提供していますが、多くのチームは JavaScript を使用して大きな UI をレンダリングしています。ネイティブとウェブ層がロケールコード、翻訳キー、フォールバックルールを共有するかどうかを決定する必要があります。ロケールの選択を明示的にすることで、ユーザーが選択した言語がデバイスの設定によって次の起動時に置き換えられないようにすることができます。

アプリのメタデータには別の注意が必要です。ローカライズされたアプリでも、タイトル、サブタイトル、説明文が一言語のままだと、見つけられなくなる可能性があります。 2023年米国主要アプリの外国市場への進出分析見つけた 60% iOSのタイトルをローカライズした 90% 製品の説明をローカライズしました。 6 in 10 Android上では、サブタイトルをローカライズしました。 70% ローカライズしたタイトルと 89% ローカライズした説明を割り当てました。これは、ストアフロントの決定であり、実行時UIの決定ではありません。したがって、エンジニアリングのバンドルがそれらを処理するのではなく、リリースチェックリストに割り当ててください。

Webアプリケーション

URL、サーバーレンダリング、ブラウザの設定、およびアカウントの設定間の安定した関係がWebに必要です。サーバーが英語をレンダリングし、ブラウザがすぐにドイツ語に切り替えると、ユーザーはフラッシュまたはヒュイダリゼーションミスマッチを経験する可能性があります。優先順位を選択し、ユーザーの選択を永続化し、フォールバックロケールを決定論的に設定してください。

アプリケーションが大量の翻訳されたコンテンツを持つ場合、ロケールバンドルを遅延ロードしてください。デフォルトのエクスペリエンスは速いままにし、オフラインまたはフェッチ失敗のパスで安全なフォールバックをレンダリングできるようにしてください。

CapacitorとElectron

Capacitorアプリケーションは、iOS、Android、ブラウザ間で共有されたWebコードベースを持つことがよくあります。これにより、共有リソースは効率的ですが、ネイティブプラグインは依然としてプラットフォーム固有のロケール動作を露出します。WebViewは、ブラウザとデバイスの設定から独立して推測するのではなく、1つの権威あるソースから標準化されたロケールを受け取る必要があります。評価中のチームは、Capacitorがプラットフォームの差異をどのように処理するかを確認できます。 Capacitorはプラットフォームの差異をどのように扱うか.

Electronはパッケージングの懸念を追加します。レンダラーは開発とパッケージされたアプリケーションでロケールファイルを読み込む方法が異なる可能性があるため、プロダクションビルドではリソースが存在し、アクセス可能であり、更新が同時に行われることを確認する必要があります。JavaScriptバンドルがライブアップデートを受け取る場合、ロケールファイルが同じ署名されたバンドルの一部であるかどうかを定義し、更新が失敗した場合にロールバックする方法を定義する必要があります。

ツールライブラリとスケーラブルな翻訳ワークフロー

i18next、FormatJS、またはネイティブの機能を使用するチームでも、翻訳ライブラリだけではローカライゼーションワークフローを実現することはできません。 Intl APIs and still miss a release if key ownership, context, review, delivery, and rollback are unclear. Treat every new string like a software artifact that moves through the same controls as code.

開発者は意味的なキーを追加します。

キーにはコンテキスト、スクリーンショット、変数、文字数制限が含まれます。 自動化はキーを抽出または検証し、翻訳管理システムに送信します。
翻訳者とレビュアーは同じソースを使用します。 ビルドはプレースホルダーと必要なロケールをチェックします。
CIは承認されたリソースを取得します CIは承認されたリソースを取得します
CIは承認されたリソースを取得します とアプリケーションとともにパッケージ化するか、承認されたアップデートチャンネルを通じて送信します。
QA チェックでロケールが変更されます。 最初からすべての言語のレビューを繰り返すのではなく、
リリース管理は露出の管理です。内部ユーザー、ベータ版ユーザー、ターゲットユーザーなど、より広範なロールアウトよりも先に始まります。

ソフトウェア国際化、翻訳管理、継続的なローカライゼーションワークフローのための4ステップのスケーラブルなプロセスを示す図。

パイプラインの重要性について

The bottleneck is often waiting for approved content, not writing the code. A 2026年の開発者調査では、i18n ワークフローに関する調査で、回答者 64% 翻訳ワークフロー効率を最優先課題として挙げました。 78% 翻訳を待つことでリリースが遅れると 52% 翻訳の体系的なQAは、手動のスポットチェックのみで行われていました。同様のソースは、 41% オーバー・ザ・エアシステムを採用し、2026年には実施する予定であると報告しています。 28% これらの発見は、ローカライゼーションをリリースの配信と関連付けるのではなく、別のコンテンツサイクルとして扱うのではなく、ローカライゼーションとリリースの配信を関連付けるものです。

CIは、パッケージング前に予測可能なエラーをキャッチするようにするべきです:

キーが欠けている: ソースキーがフォールバックキーを持たない場合にエラーまたは警告を発生させる。
プレースホルダーがずれている: 変数である {count} すべての翻訳メッセージに存在することを確認する。
孤立したキー: アプリケーションに表示されなくなったリソースをフラグする。
無効な構文: JSON、ICUメッセージ、リソースファイルの不正を拒否します。
ロケールカバー: サポートされているロケールの変更とまだレビューが必要なものを報告します。

CI統合パターンについては、開発者体験ツールの概要.

リリースエンジニアリングとしてのライブアップデート

CapacitorとElectronチーム向けに、ローカライズ修正は署名されたJavaScript、CSS、コピー、構成、資産バンドル内で移動できます。ライブアップデートプラットフォームとしては Capgo はチャンネルをターゲットにし、変更されたファイルのみを含む差分アップデートを配信し、採用と失敗のメトリクスを公開し、自動ロールバック保護を提供します。このようにすると、チームがアップデートポリシー、レビュープロセス、署名ルール、ネイティブ互換性境界を定義した場合、不正翻訳ラベルまたはレイアウトルールの修正に必要なリリースエンジニアリングのパスが作成されます。

ライブアップデートはストアリリースを置き換えません。ネイティブ文字列、権限、プラットフォームAPI、インストール済みネイティブランタイムが超える変更は、適切な配布パスを必要とします。ライブアップデートは、互換性のあるローカライズ変更のための高速なレーンを提供し、単純なコンテンツ修正は、通常、次のアプリケーションリリースを待つ必要があります。

グローバルアプリケーション向けのテスト、QA、パフォーマンス、セキュリティ

国際化テストは、ユーザーがそれを実行する前に、仮定を暴きます。単一の翻訳されたスクリーンショットでは十分ではなく、失敗は特定のロケール、データ長、画面サイズ、書き方、プラットフォームの組み合わせに依存することがよくあります。

世界中のソフトウェアアプリケーションにおけるQAパフォーマンスとセキュリティのテストのための4ステップのチェックリスト。

Hostile contentの開始

Pseudolocalizationは、テスト用のテキストに意図的に長い、アクセントのある、またはマーカーで囲まれたテキストを置き換えることで、正常な文字列を置き換えます。ハードコードされた文字列、クリップしたラベル、固定高さのカード、英語のみで機能するコントロールを発見するのに役立ちます。空の状態と埋められた状態の両方をテストする必要があります。複数のメッセージと検証エラーは、異なるレイアウトパスをとることがよくあります。

RTLテストには、完全なナビゲーションパスが必要です。テキストの配置、戻るボタン、アイコン、グラフ、スワイプジェスチャー、フォームフィールド、方向が異なるコンテンツ（例：アラビア語の文に製品codeが含まれるもの）を確認します。アイコンを自動的に反転するのではなく、方向のアイコンは反転する必要があるかもしれませんが、ブランドマークやオブジェクトアイコンは変更する必要はありません。

ロケールマトリックスの自動化

サポートされている言語と地域の組み合わせのテストマトリックスを構築する必要があります。言語名だけではありません。特に日付、数字、通貨、カレンダー、タイムゾーンについては、言語ごとに異なる慣習があることがよくあります。

機能チェック: ロケールの選択、保持、フォールバック、複数のbranch、エラーメッセージの確認
視覚チェック: 長い文字列、RTL有効、狭い幅の画面をキャプチャする
言語チェック: レビューワーにコンテキスト、スクリーンショット、変数、目的のアクションを提供する
バグ検証: アップデートのインストール、ダウンロードの中断、オフラインの起動、およびロールバックの動作をテストします。

パフォーマンスはロケールリソースの増加に伴って厳しくなります。ロケールまたは機能ごとに大きなバンドルを分割するか、非必須言語を遅延ロードし、検証済みリソースをキャッシュしてください。最初の画面が遅い翻訳要求に依存しないようにするには、信頼できるフォールバックがある場合にのみ、最初の画面を遅い翻訳要求に依存させてください。

セキュリティは同じレビューに含まれます。ロケール識別子とユーザーが提供した翻訳されたコンテンツを入力として扱い、リソース構造を検証し、翻訳管理クレデンシャルを保護し、リモートで配信されたバンドルの整合性を検証してください。ライブアップデートワークフローは署名されたアーティファクトを使用し、制御されたチャネル、バージョン互換性のチェック、観察可能なエラー、テストされたロールバックパスを使用してください。デプロイメントコントロールを設計するチームは、このガイドをレビューしてください。マルチリージョンディプロイメント.

すべてをまとめるにはCodeの例と移行チェックリスト

チェックアウト画面は、移行順序の重要性を示しています。まずcodeでユーザーが最も触れる画面から始め、次に各アサムションをロケールに適応させます。ハードコードされたラベル、日付、通貨、複数のメッセージ、固定幅レイアウトは、フォールバックロケールが欠落したリソースを空白のコントロールから逃れるように、別々の移行タスクとして扱ってください。

たとえば、既存のコンポーネントで通貨の連結を置き換えます。

前:

price.textContent = currencySymbol + amount;

後:

price.textContent = new Intl.NumberFormat(locale, {
  style: "currency",
  currency: currencyCode
}).format(amount);

残す amount 数値としての原値です。フォーマッターは記号の配置、区切り、小数点の規則、地域の詳細などを決定します。これにより、チェックアウトロジックに地域規則を散らばらせる必要がなくなります。

実用的な移行チェックリスト:

インベントリ: ユーザーフェイスの文字列、フォーマットされた値、テキストを含む画像、地域の仮定を探します。
外部化: 意味的なキーと翻訳者のコンテキストを持つリソースファイルにコピーを移します。
地域の状態を標準化: 検出、ユーザー上書き、保存、フォールバックの動作を定義します。
手動フォーマットを置き換え: プラットフォームまたはJavaScriptの地域対応フォーマッターを使用します。
レイアウトを強化: 拡張、切り捨て、 bidirectionalテキスト、フォント、RTLの反射をテストします。
自動検証: CIで、欠落しているキー、プレースホルダー、リソースの構文、変更されたロケールを確認する。
安全にリリース: ストアプロセスまたは制御されたライブアップデートチャネルを使用して、署名、ステージドエクスポージャー、監視、ロールバックを含む互換性のあるローカライゼーションチェンジを配信します。

まず、オンボーディングまたはチェックアウトなどの高トラフィックフローを選択し、リソース境界と検証パイプラインが機能するようになり次に同じ規則をアプリ全体に適用するのではなく、制御されていないリライトを試みるのではなく、同じ規則をアプリ全体に適用します。

CapacitorJSとElectronチーム向けに、Capgoは互換性のあるJavaScript、CSS、コピー、構成、資産の変更に対応する署名付きライブアップデートパッケージをサポートしています。チャンネル、差分配信、観察性、ロールバック保護は、既存のCI/CDワークフローとローカライゼーション修正を接続することで、ストアレビューが必要な互換性のある修正ごとに依存性を減らすことができます。リリースパスを展開する前に、展開制御と比較して評価します。

グローバルアプリの国際化ガイド

目次