アプリをローカライズ可能にする

2025-06-10

ローカライズされたアプリは、アプリの機能上の欠陥を明らかにすることなく、他の市場、言語、または地域向けにローカライズできるアプリです。ローカライズ可能なアプリの最も重要なプロパティは、実行可能コードがローカライズ可能なリソースからクリーンに分離されていることです。そのため、ローカライズする必要があるアプリのリソースを決定する必要があります。アプリを他の市場向けにローカライズする場合は、何を変更する必要があるかを自分に問い合わせてください。

また、グローバリゼーションのガイドラインを理解することをお勧めします。

リソースファイル (.resw) に文字列を配置する

命令型コード、XAML マークアップ、アプリパッケージマニフェストで文字列リテラルをハードコードしないでください。代わりに、リソースファイル (.resw) に文字列を配置して、アプリのビルドされたバイナリとは別にさまざまなローカル市場に適応できるようにします。詳細については、「UI とアプリパッケージマニフェストので文字列をローカライズする」を参照してください。

このトピックでは、既定のリソースファイル (.resw) にコメントを追加する方法についても説明します。たとえば、非公式の音声やトーンを採用している場合は、必ずコメントで説明してください。また、経費を最小限に抑えるために、翻訳する必要がある文字列のみが翻訳者に提供されていることを確認します。

アプリパッケージマニフェストソースファイル ( Package.appxmanifest ファイル) で、アプリの既定の言語を適切に設定します。既定の言語は、ユーザーの優先言語がアプリのサポートされている言語のいずれにも一致しない場合に使用される言語を決定します。すべてのリソースにその言語を示すマークを付けてください（既定の言語のリソースも含めて、例えば \Assets\en-us\Logo.pngなど）。これにより、システムはリソースがどの言語であるか、および特定の状況でどのように使用されるかを判断できるようになります。

言語に合わせて画像やその他のファイルリソースを調整する

理想的には、イメージをグローバル化できます。つまり、カルチャに依存しません。不可能なイメージやその他のファイルリソースの場合は、必要な数の異なるバリエーションを作成し、適切な言語修飾子をファイル名またはフォルダー名に配置します。詳細については、「言語、スケール、ハイコントラスト、その他の修飾子に合わせてリソースを調整する」を参照してください。

ローカライズコストを最小限に抑えるために、テキストや文化的に機密性の高い素材を画像に入れないでください。自分の文化に適したイメージは、他のカルチャで不快または誤って解釈される可能性があります。世界中で一般的ではないメールボックスなどのカルチャ固有のイメージを使用しないようにします。宗教上のシンボル、動物、政治的、または性別に固有の画像は避けてください。肉、身体部分、手のジェスチャーの表示も、機密性の高いトピックになる可能性があります。これらすべてを回避できない場合は、イメージを慎重にローカライズする必要があります。読み取り方向が自分とは異なる言語にローカライズする場合は、対称イメージと効果を使用すると、ミラーリングのサポートが容易になります。

また、画像内のテキストやオーディオ/ビデオファイルでの音声の使用は避けてください。

アプリでの色の使用

色を使用する場合は注意してください。各国の旗や政治運動に関連する色の組み合わせを使用すると、問題が発生する可能性があります。色の選択は、カルチャの専門家が確認する必要がある場合があります。色の使用に関するアクセシビリティの問題もあります。色を使用して意味を伝える場合は、サイズ、図形、ラベルなど、他の方法でも同じ情報を伝える必要があります。

文字列を文に分解することを検討する

適切なサイズの文字列を使用します。短い文字列は翻訳が簡単で、翻訳のリサイクルが可能になります (同じ文字列が複数回ローカライザーに送信されないため、費用を節約できます)。また、ローカリゼーションツールでは、非常に長い文字列がサポートされない場合があります。

しかし、このガイドラインとの緊張は、異なるコンテキストで文字列を再利用するリスクです。 "on" や "off" などの単純な単語でも、コンテキストに応じて異なる翻訳が行われる場合があります。英語では、フライトモード、Bluetooth、デバイスの切り替えに "オン" と "オフ" を使用できます。しかし、イタリア語では、翻訳はオンとオフのコンテキストによって異なります。コンテキストごとに文字列のペアを作成する必要があります。 2 つのコンテキストが同じ場合は、文字列を再利用できます。たとえば、サウンドの音量と音楽の音量の両方に文字列 "Volume" を再利用できます。これは、どちらもサウンドの強度を指しているためです。コンテキストと意味が異なり、単語の翻訳方法が異なる可能性があるため、ハードディスクボリュームを参照する場合は、同じ文字列を再利用しないでください。

さらに、"text" や "fax" などの文字列は、英語の動詞と名詞の両方として使用でき、翻訳プロセスが混乱する可能性があります。代わりに、動詞と名詞の両方の形式に対して個別の文字列を作成します。コンテキストが同じかどうかわからない場合は、安全を考慮して、異なる文字列を使用してください。

要するに、文字列をすべてのコンテキストで機能する部分に組み込みます。文字列が文全体である必要がある場合があります。

" {0} を同期できませんでした" という文字列を考えてみましょう。

"appointment"、"task"、"document" など、さまざまな単語が {0}に置き換わる可能性があります。この例は英語に対して機能しますが、対応する文 (ドイツ語など) のすべてのケースでは機能しません。次のドイツ語の文では、テンプレート文字列 ("Der"、"Die"、"Das") の一部の単語がパラメーター化された単語と一致する必要があることに注意してください。

英語	ドイツ語
予定を同期できませんでした。	Der Termin konnte nicht synchronisiert werden.
タスクを同期できませんでした。	Die Aufgabe konnte nicht synchronisiert werden.
ドキュメントを同期できませんでした。	Das Dokument konnte nicht synchronisiert werden.

別の例として、" {0} 分で通知する" という文を考えてみましょう。"分" を使用すると英語に対して機能しますが、他の言語では異なる用語が使用される場合があります。たとえば、ポーランド語では、コンテキストに応じて "minuta"、"minuty"、または "minut" が使用されます。

この問題を解決するには、1 つの単語ではなく、文全体をローカライズします。これを行うことは、余分な作業と無要素のソリューションのように思えるかもしれませんが、次のような理由から最適な解決策です。

文法的に正しいメッセージがすべての言語に対して表示されます。
翻訳ツールは、文字列が何に置き換えられるかについて質問する必要はありません。
アプリの完了後にこのような問題が発生した場合、コストのかかるコード修正を実装する必要はありません。

文字列に関するその他の考慮事項

既定の言語で作成する文字列では、口語やメタファーは避けてください。人口統計グループに固有の言語 (文化や年齢など) は、その人口統計グループのユーザーのみがその言語を使用するため、理解や翻訳が困難な場合があります。同様に、メタファーは一人の人には理にかなっているかもしれませんが、他の人には何の意味もありません。たとえば、「bluebird」とは、スキー文化に特有の用語ですが、その文化に属さない人には理解されません。

技術的な専門用語、省略形、頭字語は使用しないでください。技術言語は、非技術的な対象ユーザーや他の文化や地域のユーザーが理解する可能性が低く、翻訳が困難です。人々は日常会話でこのような単語を使用しません。技術的な言語は、多くの場合、ハードウェアとソフトウェアの問題を識別するためにエラーメッセージに表示されますが、文字列は、そのレベルの情報が必要な場合にのみ技術的な にする必要があります。また、そのレベルの情報を操作するか、できるユーザーを見つけることができます。

文字列で非公式の音声またはトーンを使用することは、有効な選択肢です。既定のリソースファイル (.resw) のコメントを使用して、その意図を示すことができます。

擬似ローカリゼーション

アプリを擬似ローカライズして、ローカライズの問題を明らかにします。擬似ローカリゼーションは、ローカリゼーションドライランまたは開示テストの一種です。実際には翻訳されていないリソースのセットを生成します。彼らはそのように見えるだけです。たとえば、文字列は既定の言語よりも約 40% 長く、区切り記号が含まれているため、UI で切り捨てられているかどうかをひとめで確認できます。

デプロイに関する考慮事項

ローカライズされた言語データを含むアプリをインストールすると、最初に複数の言語のリソースを含めた場合でも、既定の言語のみがアプリで使用できる場合があります。これは、インストールプロセスが、デバイスの現在の言語とカルチャに一致する言語リソースのみをインストールするように最適化されているためです。そのため、デバイスが en-US用に構成されている場合は、en-US 言語リソースのみがアプリと共にインストールされます。

注

最初のインストール後に、アプリの追加の言語サポートをインストールすることはできません。アプリのインストール後に既定の言語を変更した場合、アプリは元の言語リソースのみを引き続き使用します。

インストール後にすべての言語リソースを使用できるようにする場合は、インストール時に特定のリソース (言語リソースを含む) が必要であることを指定するアプリパッケージの構成ファイルを作成します。この最適化されたインストール機能は、パッケージ化中にアプリケーションの .appxbundle が生成されたときに自動的に有効になります。詳細については、「リソースがデバイスに必要かどうかに関係なく、リソースがデバイスにインストールされていることを確認する」を参照してください。

必要に応じて、(サブセットだけでなく) すべてのリソースがインストールされるように、アプリをパッケージ化するときに .appxbundle の生成を無効にすることができます。ただし、アプリのインストール時間が長くなる可能性があるため、これはお勧めしません。

.appxbundle の自動生成を無効にするには、"アプリバンドルの生成" 属性を "never" に設定します。

Visual Studio で、プロジェクト名を右クリックします。
ストア ->選択しますアプリパッケージの作成...
[ パッケージの作成 ] ダイアログで、[ 新しいアプリ名を使用して Microsoft Store にアップロードするパッケージを作成する ] を選択し、[ 次へ] をクリックします。
[ アプリ名の選択 ] ダイアログで、パッケージのアプリ名を選択または作成します。
[パッケージの選択と構成の ] ダイアログで、[アプリバンドルの生成] [しない] 設定します。

地政学的認識

地図や地域を参照する場合は、政治的な犯罪を避けてください。マップには、議論の余地のある地域や国境が含まれる可能性があり、政治的犯罪の原因として頻繁に発生します。国を選択するために使用される UI は、"国/地域" と見なすように注意してください。 "国" というラベルの付いたリスト (住所フォームなど) に紛争地域を一覧表示すると、一部のユーザーが問題を犯す可能性があります。

言語および地域で変更されたイベント

システムの言語とリージョンの設定が変更されたときに発生するイベントをサブスクライブします。必要に応じてリソースを再読み込みできるように、これを行います。詳細については、修飾子値変更イベントへの応答での文字列の更新と、修飾子値変更イベントに応答したイメージの更新を参照してください。

文字列の書式設定時に正しいパラメーターの順序を確認する

すべての言語がパラメーターを同じ順序で表しているとは考えないでください。たとえば、この形式を考えてみましょう。

    string.Format("Every {0} {1}", monthName, dayNumber); // For example, "Every April 1".

この例の書式指定文字列は、英語 (米国) で動作します。ただし、日と月が逆の順序で表示される場合など、ドイツ語 (ドイツ) には適していません。ターゲット言語に応じて、書式指定文字列 ("{1}{0}" など) の書式項目の順序を逆にできるように、各パラメーターの意図を確実に認識します。

ローカライズを過剰に行わない

翻訳者にのみ自然言語を提出する。プログラミング言語やマークアップではありません。 <link> タグは自然言語ではありません。次の例を考えてみましょう。

これをローカライズしない	これをローカライズする
使用条件<リンク >/link<>	使用条件
<リンク>プライバシーポリシー</link>	プライバシーポリシー

リソースファイル (.resw) に <link> タグを含めると、そのタグも翻訳される可能性が高くなります。そうすると、タグが無効になります。コンテキストを維持し、順序を確保するためにマークアップを含める必要がある長い文字列がある場合は、翻訳しないものをコメントで明確にします。

適切な翻訳方法を選択する

文字列をリソースファイルに分割した後、それらの文字列を変換できます。文字列を翻訳する理想的なタイミングは、プロジェクト内の文字列が完成した後です。これは通常、プロジェクトの末尾に向かって行われます。翻訳プロセスにはさまざまな方法でアプローチできます。これは、翻訳する文字列の量、翻訳する言語の数、および翻訳の実行方法 (社内と外部ベンダーの雇用など) によって異なります。

これらのオプションを検討してください。

リソースファイルは、プロジェクトで直接開くことで変換できます。 この方法は、2 つまたは 3 つの言語に翻訳する必要がある少量の文字列を含むプロジェクトに適しています。開発者が複数の言語を話し、翻訳プロセスを進んで処理するシナリオに適している可能性があります。このアプローチは、迅速であることからメリットがあり、ツールを必要とせず、誤翻訳のリスクを最小限に抑えます。ただし、スケーラブルではありません。特に、異なる言語のリソースが簡単に同期しなくなり、ユーザーエクスペリエンスが悪くなり、メンテナンスの頭痛が生じることがあります。
文字列リソースファイルは XML または ResJSON テキスト形式であるため、任意のテキストエディターを使用して翻訳のために渡される可能性があります。その後、翻訳されたファイルがプロジェクトにコピーされます。この方法では、翻訳者が誤って XML タグを編集するリスクがありますが、翻訳作業は Microsoft Visual Studio プロジェクトの外部で行うことができます。この方法は、少数の言語に翻訳する必要があるプロジェクトに適している可能性があります。 XLIFF 形式は、ローカライズで使用するために特別に設計された XML 形式であり、一部のローカライズベンダーまたはローカライズツールで十分にサポートされている必要があります。多言語アプリツールキットを使用すると、.resw や .resjson などの他のリソースファイルから XLIFF ファイルを生成できます。

注

画像やオーディオファイルなど、他の資産にもローカライズが必要になる場合があります。

また、次の点も考慮する必要があります。

ローカライズツール リソースファイルを解析し、翻訳可能な文字列のみを翻訳者が編集できるように、さまざまなローカライズツールを使用できます。この方法により、翻訳者が XML タグを誤って編集するリスクが軽減されます。しかし、ローカライズプロセスに新しいツールとプロセスを導入する欠点があります。ローカライズツールは、大量の文字列を含むが言語の数が少ないプロジェクトに適しています。詳細については、「多言語アプリツールキットの使用方法」を参照してください。
ローカライズベンダー アプリケーションに多数の言語に翻訳する必要がある広範な文字列が含まれている場合は、ローカライズベンダーの使用を検討してください。ローカライズベンダーは、リソースファイルの翻訳だけでなく、ツールとプロセスに関するアドバイスを提供できます。これは理想的なソリューションですが、最もコストのかかるオプションであり、翻訳されたコンテンツのターンアラウンド時間が長くなる可能性があります。

アクセスキーとラベルの一貫性を維持する

2 つの文字列リソースは 2 つの異なるセクションに分類されるため、アクセシビリティで使用されるアクセスキーをローカライズされたアクセスキーの表示と "同期" することは困難です。次のようなラベル文字列のコメントを必ず入力してください。 Make sure that the emphasized shortcut key is synchronized with the access key.

並べ替え可能な日本語文字列にふりがなをサポートする

日本語の漢字は、使用する単語に応じて、複数の読み取り (発音) を持つプロパティを持っています。これにより、アプリケーション名、ファイル、曲など、日本語の名前付きオブジェクトを並べ替えようとしたときに問題が発生します。日本語の漢字は、従来、XJIS と呼ばれる機械で理解できる順序で並べ替えられていたのが一般的でした。残念ながら、この並べ替え順序はふりがなではないため、人間にとってはあまり役に立ちません。

ふりがなは、ユーザーや作成者が使用している文字に対してふりがなを指定できるようにすることで、この問題を回避します。次の手順を使用してアプリ名にふりがなを追加する場合は、アプリ一覧の適切な場所で並べ替えられていることを確認できます。アプリ名に漢字が含まれており、ユーザーの UI 言語または並べ替え順序が日本語に設定されているときにふりがなが指定されていない場合、Windows は適切な発音を生成するように最善を尽くします。ただし、まれなまたはユニークな読みを含むアプリ名が、より一般的な読みの下に配列される可能性があります。したがって、日本のアプリケーション (特に名前に漢字を含むアプリケーション) のベストプラクティスは、日本語のローカライズプロセスの一環として、アプリ名のふりがなバージョンを提供することです。

パッケージの表示名とアプリケーションの表示名として "ms-resource:Appname" を追加します。
文字列の下に ja-JP フォルダーを作成し、次のように 2 つのリソースファイルを追加します。
```
strings\
    en-us\
    ja-jp\
        Resources.altform-msft-phonetic.resw
        Resources.resw
```
Resources.reswで、一般のja-JPに対して、アプリ名「希蒼」の文字列リソースを追加する。
Resources.altform-msft-phonetic.resw における日本語のふりがなリソース: AppName "のあ" にふりがな値を追加します

ユーザーは、ふりがな値 "のあ" (noa) と音声値 "まれあお" (mare-ao) を、入力メソッドエディター (IME) の GetPhonetic 関数を使用して、アプリ名 "希蒼" を検索できます。

並べ替えは、 地域コントロールパネル の形式に従います。

日本語のユーザーロケールでは、次の操作を行います。
- ふりがなが有効になっている場合、"希蒼" は "の" で並べ替えられます。
- ふりがながない場合は、「ま」の下に「希蒼」が分類されます。
日本語以外のユーザーロケールでは、
- ふりがなが有効になっている場合、"希蒼" は "の" で並べ替えられます。
- ふりがながない場合、"希蒼" は "漢字" で並べ替えられます。

サンプル

アプリケーションリソースとローカライズのサンプル