情報
要求されたトピックは次のとおりです。しかし、このトピックはこのライブラリには含まれていません。

Windows Phone 8 のローカリゼーションのベスト プラクティス

2014/06/18

対象: Windows Phone 8 および Windows Phone Silverlight 8.1 | Windows Phone OS 7.1

簡単にローカライズできるアプリを構築するには、以下のベスト プラクティスを考慮します。グローバリゼーションとローカリゼーションの一般的な概念の詳細については、「Windows Phone 8 のグローバリゼーションとローカリゼーション」を参照してください。

このトピックは、次のセクションで構成されています。

文字列、イメージ、ビデオなどのリソースをコードから分離して、それらを独立したリソース専用ファイルに移動します。こうすることで、コードが言語非依存となり、異なる言語のエンコーディングをサポートできます。Unicode が推奨されるソリューションです。個別のリソース ファイルを作成する方法の例については、「Windows Phone 8 のローカライズしたアプリの構築方法」を参照してください。

ヒントヒント:

Visual Studio Professional 2012 および Visual Studio Express 2012 for Windows Phone と統合される 多言語アプリ ツールキットは、Windows Phone アプリおよび Windows ストア アプリを作成するための翻訳サポート、翻訳ファイルの管理、およびローカライズのツールを提供します。このツールキットを使用して Microsoft Translator に接続し、翻訳候補をすばやく調べることができます。詳細については、「多言語アプリ ツールキットの使用方法」を参照してください。

ローカライズする必要がある正確な文字列のみを含めます。たとえば、ローカライズ可能な文字列にはタグを含めません。次に例を示します。

過度にローカライズされた文字列

正しくローカライズされた文字列

<link>使用条件</link>

使用条件

<link>プライバシー ポリシー</link>

プライバシー ポリシー

上記の例で、<link> タグをリソースに含めると、それもローカライズされ、タグが無効になります。ローカライズするのは文字列そのものだけにします。

モバイル デバイスでは UI 用のスペースは限られています。ローカライズされた言語を Windows Phone で表示できるようにするには、英語で文字列を表示するのに必要な長さよりも約 40% 長い文字列を使用します。さらに、1 つのコントロールでの複数行のサポートとテキストの折り返しを有効にすると、各文字列を表示するためにより多くのスペースが使用できます。

次の文字列について考えます: "The {0} could not be synchronized".{0} は、"予定"、"タスク"、"ドキュメント" などのさまざまな単語で置き換えられます。この例は英語では機能しているように見えることがありますが、たとえばドイツ語など、別の言語の対応する文では機能しません。

英語 (米国)

ドイツ語 (ドイツ)

The appointment could not be synchronized.

Der Termin konnte nicht synchronisiert werden.

The task could not be synchronized.

Der Aufgabe konnte nicht synchronisiert werden.

The document could not be synchronized.

Der Document konnte nicht synchronisiert werden.

別の例として、"Remind me in {0} minute(s)" という文について考えてみます。"minute(s)" の使用は英語では動作しますが、別の言語では別の用語を使用することがあります。たとえば、ポーランド語では、コンテキストに応じて "minuta"、"minuty"、または "minut" になります。

この問題を解決するために、単一の単語ではなく文全体をローカライズします。このようにすることは余計な作業で洗練されていないソリューションのように見えますが、次の理由から最適なソリューションです:

  • すべての言語について明確なエラー メッセージが表示されます。

  • ローカライズ担当者は、どの文字列に置き換えられるかを明確には知りません。

  • アプリの完成後にこの種の問題が発生した場合に、経費のかかるコード フィックスを実装する必要がありません。

すべての言語でパラメーターを同じ順序で使用するとは限りません。

たとえば、文字列 "Every %s %s" について考えてみます。最初の %s は月の名前で置き換えられ、2 番目の %s は日付で置き換えられます。この例は英語では機能しますが、ドイツ語では日付と月が逆の順序で表示され正常に機能しません。この問題を解決するため、言語に応じて順序を入れ換えることができるように文字列を "Every %1 %2" に変更します。

文字列の再利用は最適な方法のように見えますが、そうすると文字列のコンテキストが変わった場合にローカリゼーションの問題が生じることがあります。

たとえば、文字列 "on" と "off" について考えてみます。英語では、これらの文字の使用はフライト モード、Bluetooth、デバイス切り替えスイッチなどのコンテキストで機能しますが、イタリア語では "on" と "off" の翻訳は何をオン/オフするかによって異なります。この例では、各コンテキストに対して文字列ペアを作成する必要があります。

さらに、"text" や "fax" などの文字列は英語では動詞と名詞の両方として使用されるため、翻訳プロセスで混乱が生じることがあります。代わりに、動詞形式と名詞形式の両方に個別の文字列を作成します。

リソースを設計する際には、ID や名前などの一意の値を使用して各リソースを識別します。すると、リソースにアクセスする際は、言語によって変化するリソースの実際の値ではなく、変化することのない一意の値のみを使用してアクセスできます。

文字列がリソース ファイルに分離された後に、それらを翻訳できます。文字列を翻訳する理想的な時期は、通常は開発プロセスの最後となるプロジェクトの文字列が最終決定された後です。

翻訳する文字列の量、翻訳する言語数、および翻訳の実行方法 (社内または外部ベンダーを使用) に応じて、翻訳プロセスへのアプローチ方法には複数のオプションがあります。次のオプションを考えてみます:

  • リソース ファイルを Visual Studio プロジェクト内で直接開いて翻訳できるようにします。このアプローチは、文字列が少量で、2 言語か 3 言語に翻訳する必要のあるプロジェクトに適しています。また、このアプローチは、開発者が複数の言語を話し、翻訳プロセスを管理する意欲があるシナリオに適しています。このアプローチには迅速で、ツールが不要で、誤訳のリスクが最小限というメリットがありますが、拡張性はありません。

  • リソース ファイルは XML 形式なので、テキスト エディターを使用する翻訳プロセスに引き渡すことができます。その後、翻訳されたファイルをプロジェクトに戻します。この方法では、翻訳担当者が XML タグを誤って編集するリスクがありますが、Visual Studio プロジェクトの外部で翻訳作業を行うことができます。このアプローチは、少数の言語にのみ翻訳する必要があるプロジェクトにも適しています。

また、次の推奨事項の一部またはすべてを考慮してください。

  • ローカリゼーション ツールを使用する。リソース ファイルを解析し、翻訳可能な文字列だけを翻訳者が編集できるようにする多数のローカリゼーション ツールがあります。このアプローチでは翻訳者が誤って XML タグを編集する危険を減らしますが、ローカリゼーション プロセスに新しいツールとプロセスが導入されるという欠点があります。ローカリゼーション ツールを使用する方法は、文字列の量は多いが、ローカライズ先の言語数は少ないプロジェクトで有効です。

  • ローカリゼーション ベンダーを使用する。プロジェクトに多量の文字列が含まれており、多数の言語に翻訳する必要がある場合は、ローカリゼーション ベンダーの利用を考慮してください。ローカリゼーション ベンダーは、リソース ファイルを翻訳するだけでなく、ツールやプロセスに関してアドバイスしてくれる場合もあります。これは理想的な方法ですが、最もコストのかかるオプションであり、翻訳されたコンテンツを受け取るまでの時間が長くなることがあります。

  • ローカライズ担当者に常に情報を提供する。名詞とも動詞とも使用できる文字列については、ローカライズ担当者に連絡します。一般的でない専門用語や技術用語は、用語ツールを使用してローカライズ担当者に説明します。混乱を避けるために、文字列を文法的に正しく、明瞭で、できるだけ非専門的なものにしておきます。

表示: