次の方法で共有

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

  • [アーティクル]

ローカライズされたアプリは、アプリで機能上の欠陥を生じさせることなく他の市場、言語、または地域にローカライズできるアプリです。 ローカライズ可能なアプリの最も重要な特性は、その実行可能コードが、アプリのローカライズ可能なリソースから明確に区別されていることです。 そのため、アプリのリソースのどれをローカライズする必要があるかを判断する必要があります。 他の市場向けにアプリをローカライズすることになった場合には、何を変更する必要があるかよく考えてください。

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

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

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

そのトピックでは、既定のリソース ファイル (.resw) にコメントを追加する方法も示します。 たとえば、くだけた表現を使う場合は、そのことをコメント内で説明してください また、コストを最小限に抑えるため、変換する必要がある文字列だけが翻訳者に提供されることを確認します。

アプリ パッケージ マニフェスト ソース ファイル (Package.appxmanifest ファイル) でアプリの既定の言語を適切に設定します。 ユーザーの優先する言語が、アプリでサポートされる言語のいずれにも一致しない場合、使われる言語は既定の言語によって決定されます。 すべてのリソースをその言語でマークしてください (\Assets\en-us\Logo.png のように既定の言語で作られているものも含む)。こうすることで、システムはリソースで使われている言語と、個々の状況でそのリソースがどのように使われるかを判断できます。

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

イメージをグローバル化する、つまり、文化に依存しないようにできることが理想的です。 それが可能ではないイメージやその他のファイル リソースでは、必要なだけそれらのさまざまなバリエーションを作成し、適切な言語修飾子をそれらのファイル名またはフォルダー名に追加します。 詳細については、「言語、スケール、ハイ コントラスト、その他の修飾子用にリソースを調整する」を参照してください。

ローカライズ コストを最小限に抑えるために、テキストまたは文化的に重要な内容を開始時のイメージに含めないでください。 自分が所属するカルチャでは妥当なイメージでも、別のカルチャでは不快感を与えたり、誤って解釈されたりすることがあります。 世界で一般的ではない、メールボックスなどのカルチャ固有のイメージを使用しないでください。 宗教的なシンボル、動物、政治、性別に固有のイメージを避けます。 肌、手足、指のジェスチャの表示も慎重に扱う必要がある場合があります。 これらのすべてを回避することはできない場合、イメージは慎重にローカライズする必要があります。 読み取り順が自国語とは異なる言語にローカライズする場合は、左右対称の画像や効果を使うと左右反転をサポートしやすくなります。

また、イメージ内にテキストを使用したり、オーディオ ファイルや動画ファイルで音声を使用しないでください。

アプリで色の使用

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

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

適切なサイズの文字列を使用します。 文字列を短くすると翻訳が簡単になり、翻訳データを再使用できます (これにより同じ文字列が 1 回以上ローカライズ担当者に送られなくなるため、コストが削減されます)。 また、非常に長い文字列は、ローカライズ ツールではサポートされていない可能性があります。

ただし、このガイドラインには、異なるコンテキストで文字列を再利用することで生じるリスクが記載されています。 "オン" や "オフ" などの簡単な語句でも、コンテキストに基づいて別の翻訳がなされる可能性があります。 日本語では、"オン" と "オフ" は、フライト モード、Bluetooth、デバイスの切り替えに使うことができます。 しかし、イタリア語では、何がオンで何がオフかというコンテキスト (状況) に応じて翻訳が変化します。 コンテキストごとに 2 つの文字列の組み合わせを作らなければなりません。 2 つのコンテキストが同じである場合には文字列を再使用できます。 たとえば、"ボリューム" という文字列は、サウンド効果のボリュームと音楽のボリュームの両方に使うことができます。どちらもサウンドの強さを意味するためです。 ハード ディスクのボリュームの場合、コンテキストと意味が異なり、この語句が他の言葉に翻訳される可能性があります。このため、ハード ディスクを指す場合には、同じ文字列を再使用してはなりません。

また、"text" や "fax" などの文字列は英語では動詞としても名詞としても使うことができますが、翻訳プロセスを混乱させる可能性があります。 この場合、別の方法として動詞形と名詞形の両方に個別の文字列を作ります。 コンテキストが同じかどうか確信できない場合は、(間違えるとしても) 重大な間違いは避け、明確な文字列を使ってください。

つまり、文字列をすべてのコンテキストで機能する断片に分けます。 場合によっては、文字列が文全体である必要があります。

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

{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 つの単語ではなく、文全体をローカライズしてください。 このやり方は手間がかかり、洗練されていないように見えるかもしれませんが、次の理由から最善の方法と言えます。

  • どの言語でも、文法的に正しいメッセージが表示される。
  • 翻訳者は、文字列が何に置き換えられるかをたずねる必要がない。
  • アプリが完了した後でこのような問題が浮かび上がったときに、犠牲の大きいコード修正を行う必要がない。

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

既定の言語で作成した文字列に俗語や比喩を使わない。 一部のカルチャや年齢などの集団にしか伝わらない言葉は、その集団の人しか使わないので、理解や翻訳が難しい場合があります。 同様に、比喩も人によって伝わったり伝わらなかったりします。 たとえば、"ブルーバード" はスキーをする人には伝わりますが、スキーをしない人には伝わりません。

専門的な用語、省略形、略語を使わない。 専門用語は、専門知識のないユーザーや他のカルチャまたは地域の人々には意図が伝わりにくく、翻訳も困難です。 このような言葉は日常会話では使われません。 専門用語は、ハードウェアとソフトウェアの問題を特定するため、エラー メッセージ内でよく使われますが、ユーザーがそのレベルの情報を必要し、それに対処できる場合、または対処できる人を探せる場合にのみ文字列に専門用語を使います。

文字列にくだけた表現を使うことは、有効な選択肢です。 コメントは、その目的を示すために、既定のリソース ファイル (.resw) で使用できます。

擬似言語によるローカライズ

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

配置に関する注意事項

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

注意

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

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

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

[アプリケーション バンドルの生成] 属性を "なし" に設定して、.appxbundle の自動生成を無効にします。

  1. Visual Studio で、プロジェクト名を右クリックします。
  2. [ストア] ->[アプリ パッケージの作成] を選択します。
  3. [パッケージの作成] ダイアログで、[I want to create packages to upload to the Microsoft Store using a new app name]\(パッケージを作成して、新しいアプリ名を使用して Microsoft Store にアップロードする\) を選択し、[次へ] をクリックします。
  4. [アプリケーション名を選択] ダイアログで、パッケージのアプリ名を選択または作成します。
  5. [パッケージの選択と構成] ダイアログで、[アプリケーション バンドルの生成] を [なし] に設定します。

地理的な認識

地図や、地域についての言及では、政治的侵害を避ける。 地図には論争の的になっている地域や国境が含まれている可能性があり、それらはしばしば政治的な侵害のきっかけになります。 国家の選択に使う UI は、必ず "国/地域" という名称にしてください。 住所フォームなどで "国" という名称の一覧に領有権未決の領域を含めると、一部のユーザーにとって問題となる可能性があります。

言語- および地域 -変更イベント

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

文字列を書式設定するときに、パラメーターの順番が正しくなるようにします。

どの言語も同じ順番でパラメーターを表現すると想定しないでください。 この書式設定の例を次に示します。

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

この例の書式文字列は英語 (米国) で機能します。 ただし、たとえば、日と月が逆の順序で表示されるドイツ語 (ドイツ) では適切ではありません。 翻訳者が、対象言語に応じて適切に書式文字列の書式項目 (たとえば、"{1}{0}") の順序を逆にすることができるように、各パラメーターの意図を把握していることを確認します。

過度なローカライズを避ける

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

ローカライズ対象外 ローカライズ対象
<link>使用条件</link> 使用条件
<link>プライバシー ポリシー</link> プライバシー ポリシー

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

適切な翻訳方法を選ぶ

文字列がリソース ファイルとして分けられた後、それらを翻訳できます。 文字列を翻訳するのに適したタイミングは、プロジェクト内の文字列が最終的に確定した後です。この最終処理は、通常、プロジェクトの終わりごろです。 翻訳プロセスには、さまざまな方法で取り組むことができます。 どの方法を選ぶかは、翻訳する文字列の量、翻訳する言語の数、翻訳の方法 (社内で行うか外部ベンダーを雇うか) などに応じて決まります。

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

  • リソース ファイルは、プロジェクト内で直接開いて翻訳できます。 この方法は、文字列の量が少ないプロジェクトや、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 は適切な発音を生成しようと最善の努力を尽くします。 しかし、珍しい読み方やユニークな読み方をするアプリ名の場合、比較的一般的な読みで並べ替えられる可能性があります。 このため、日本語アプリケーション (特に名前に漢字が含まれるアプリケーション) で最も望ましい方法は、日本語ローカライズ プロセスの一環として、ふりがなバージョンのアプリ名を提供することです。

  1. [パッケージ表示名] と [アプリケーション表示名] として "ms-resource: Appname" を追加します。

  2. 次に示すように、strings フォルダーの下に ja-JP フォルダーを作り、2 つのリソース ファイルを追加します。

    strings\
    en-us\
    ja-jp\
        Resources.altform-msft-phonetic.resw
        Resources.resw

  3. 通常の ja-JP 用の Resources.resw: アプリ名 "希蒼" の文字列リソースを追加します。

  4. 日本語ふりがなリソース用の Resources.altform-msft-phonetic.resw: AppName "のあ" のふりがな値を追加します。

ユーザーは、ふりがな値 "のあ" と発音値 (入力方式エディター (IME) の GetPhonetic 関数を使う) "まれあお" の両方を使ってアプリ名 "希蒼" を検索できます。

並べ替えは、次に示す [Regional Control Panel] フォーマットに従って行われます。

  • 日本語のユーザー ロケールでは、次の操作を行います。
    • ふりがなが有効になっている場合、"の" の下に "希蒼" が並びます。
    • ふりがなが含まれていない場合、"ま" の下に "希蒼" が並びます。
  • 日本語以外のユーザー ロケールでは、
    • ふりがなが有効になっている場合、"の" の下に "希蒼" が並びます。
    • ふりがなが含まれていない場合、"漢字" の下に "希蒼" が並びます。

サンプル