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

2012/02/09

容易にローカライズできるアプリケーションをビルドするには、次のベスト プラクティスを考慮してください。一般的なグローバリゼーションとローカリゼーションの概念の詳細については、「Windows Phone のグローバリゼーションとローカリゼーション」を参照してください。

文字列、画像、ビデオなどのリソースをコードから分離して、独立したリソース専用ファイルを作成します。この処理を行うと、言語に依存しないコードとなり、さまざまな言語エンコーディングをサポートすることができます。Unicode は優先的ソリューションです。独立したリソース ファイルの作成方法の例については、「方法: Windows Phone のローカライズしたアプリケーションを構築する」を参照してください。

タグを除く特定の文字列をローカライズします。次の例を考えてみましょう。

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

適切にローカライズされた文字列

<link>terms of use</link>

terms of use

<link>privacy policy</link>

privacy policy

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

モバイル デバイス上でユーザー インターフェイス用に使用できるスペースは限られています。ローカライズされた言語を調整するには、文字列の長さが、英語に必要な長さよりも約 40% 長いことを確認してください。また、コントロールで複数行のサポートやテキストの折り返しを有効にすると、各文字列を表示するためのスペースがさらに確保されます。

文字列 "The {0} could not be synchronized" を考えてみましょう。{0} は、予定、タスク、ドキュメントなどのさまざまな単語に置き換えることができます。この例は英語では有効ですが、対応する別の言語の文では機能しません。

英語 (U.S.)

ドイツ語 (ドイツ)

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 や普通名詞などの一意の値によって識別されるようにします。その後リソースにアクセスする際は、言語によって変化するリソースの実際の値ではなく、変化することのない固有の値のみを使用してアクセスします。

文字列をリソース ファイルに分離すると、翻訳が可能になります。文字列の翻訳は、プロジェクト内の文字列を最終処理した後に行うことが理想的です。通常、これはプロジェクトの最後に行います。

翻訳プロセスに着手するには、翻訳する文字列の量、翻訳する言語の数、および翻訳の方法 (社内で行う、外部ベンダーに依頼するなど) に応じてさまざまな方法があります。次のオプションを考えてみましょう。

  • リソース ファイルは、プロジェクト内で直接開いて翻訳することができます。文字列の量が少なく、2 ~ 3 の言語に翻訳する必要があるプロジェクトでは、この方法が有効です。この方法は、開発者が複数の言語を使用し、自ら翻訳プロセスを手掛ける場合に適すると考えられます。この方法は迅速でツールを必要とせず、誤訳のリスクが最小限に抑えられるという利点がありますが、拡張性に欠けます。

  • リソース ファイルは .xml 形式であるため、任意のテキスト エディターを使用して翻訳を依頼することができます。その後、翻訳ファイルをプロジェクト内にコピーして戻します。この方法では、翻訳担当者が xml タグを誤って編集するリスクがありますが、Visual Studio プロジェクトの外部で翻訳作業を行うことができます。翻訳する必要がある言語数が少ないプロジェクトでは、この方法が有効と考えられます。

さらに、次の推奨事項を考慮してください。

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

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

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

表示: