ローカリゼーション
このガイドでは、"国際化" と "ローカライズ" の背景にある概念を説明し、それらの概念を使用して Xamarin モバイル アプリケーションを作成する方法を掲載した記事へのリンクを示します。
Xamarin アプリのローカライズに関する技術的な詳細に直接進むには、次のいずれかのプラットフォーム固有のハウツー記事から開始できます。
- RESX ファイルを使用した Xamarin.Forms クロスプラットフォームのローカライズ。
- Xamarin.iOS ネイティブ プラットフォームのローカライズ。
- Xamarin.Android ネイティブ プラットフォームのローカライズ。
i18n と L10n
"国際化" とは、コードでさまざまな言語を表示し、さまざまなロケール (数値や日付の書式設定など) に合わせてその表示を調整するようにコードを記述するプロセスです。 これは、"グローバリゼーション" とも呼ばれます。
"ローカライズ" とは、言語ごとにリソース (文字列や画像など) を作成し、それらを国際化アプリにバンドルする、という手順です。
国際化 (Internationalization) はよく、i18n と短縮されることがあります。これは、"i" と "n" の間の 18 文字を短く表したものです。 ローカライズ (Localization) も同様に L10n と短縮されます ("L" と "n" の間に 10 文字あることを表す)。
概要
このドキュメントでは、国際化とローカライズに関連する概念と、それらがモバイル アプリケーションの開発全般にどのように適用されるかについて説明します。 アプリケーションの設計およびビルド時に、以前にハードコーディングした可能性があるが、ローカライズのためにパラメーター化する必要があるものは、次のとおりです。
- 画面レイアウトとテキスト
- アイコン、グラフィックス、色
- ビデオ ファイルとサウンド ファイル
- 動的テキストとテキストの書式設定 (数値、通貨、日付など)
- 右から左 (RTL) に読む言語用のレイアウト変更
- データの並べ替え
アプリがどのようなモバイル プラットフォームをターゲットとしているかに関係なく、次のヒントは、高品質なローカライズされたアプリの構築に役立ちます。
デザインに関する考慮事項
そのコンテンツをローカライズできるようにアプリケーションを設計することは、国際化と呼ばれます。 国際化を適切に行うことは、実行時にさまざまな言語の文字列を読み込むことができるようにするだけではありません。適切に設計されたアプリでは、言語とロケール (画像、サウンド、ビデオを含む) に基づいてすべてのリソースを変更でき、さまざまなサイズの文字列に合わせて書式設定とレイアウトを調整できる必要があります。
このセクションでは、国際化されたアプリケーションを作成する際に考慮すべき設計上のいくつかの考慮事項を紹介します。
レイアウトと文字列の長さ
中国語と日本語の文字列は非常に短い場合があり、入力フィールド ラベルでは 1 文字または 2 文字で十分に意味を持つ場合があります。
英語では比較的短い単語が、(たとえば) ドイツ語の文字列など他の言語では非常に長くなる場合があり、切り落とされたり、予期せずレイアウトがリフローされたりすることがあります。
iOS ホーム画面の英語、ドイツ語、日本語の項目の文字列の長さを比較してみましょう。
英語の [Settings] (8 文字) では、ドイツ語の翻訳には 13 文字が必要ですが、日本語では 2 文字のみであることに注意してください。
表示ラベルと入力フィールドが並んでいるレイアウトは、ラベルの長さが大きく変わりやすいので、扱いが困難になります。 多くの場合、ラベルがフィールドの上に表示されるレイアウトは、画面の全幅をラベルと入力の両方で使用できるため、ローカライズが容易になります。
一般的なルールとして、固定されたレイアウト (特に横並びの要素) を構築する場合は、ラベルとテキストに必要な英語の文字列よりも少なくとも 50% 多くの幅を設けます。 これによりすべての問題が解決されるわけではありませんが、多くの場合に機能するバッファーを確保できます。
入力の検証
検証規則を記述する際、前提条件に注意してください。 1 文字に意味があることがほとんどないため、テキスト フィールド入力には、英語で少なくとも 3 文字を "必須" とするのが妥当かもしれません。 ただし、中国語と日本語では、1 文字が有効な入力になる可能性があり、"少なくとも 3 文字が必要です" という検証メッセージは、これらの言語では意味がありません。
メール アドレスや Web サイト URL の検証など、一見単純な他の作業は、ASCII サブセットに限定されない文字ではより複雑になります。
国際化を念頭に置いて検証規則を記述しましょう。最も制限の緩い規則を選択するか、言語ごとにさまざまに機能するようにロジックを記述します。
画像と色
画像はすべて、ユーザーの言語の選択に応じて変更が必要というわけではありません。 多くのアイコンや写真は、話される言語に関係なく、すべてのユーザーに適しています。 ただし、ローカライズに意味があるリソースもあります。次のようなものです。
- 人物または特定の場所を描写した画像 – 地元の住民や場所が表示されると、ユーザーはアプリに親近感を覚えます。
- アイコン – 一部のアイコン画像は文化に固有であり、現地の意味合いを反映するように画像をローカライズすることで、アプリをより使いやすいものにすることができます。
- 色 – 色の受け止め方は文化によって異なります。赤はある地域では警告を意味し、別の地域では幸運を意味する場合があります。 アプリの設計時にネイティブ スピーカーと話して、色をローカライズするメカニズムを構築する必要があるかどうかを判断してください。
ビデオとサウンド
ビデオとサウンドは、アプリケーションをローカライズする際に特別な課題を提示します。これは、文字列の翻訳は比較的簡単なものの、複数のボイスオーバー トラックやビデオ クリップの録音 (録画) はコストが高くなり、難しい場合があるためです。
また、ビデオ ファイルやサウンド ファイルの複数のコピーにより、アプリケーションのサイズが非常に大きくなる可能性があります (特に、多数の言語にローカライズしている場合や、多くのメディア ファイルがある場合)。 ユーザーがアプリをインストールした後、必要な言語資産のみをダウンロードすることを検討できますが、低速なネットワークでユーザー エクスペリエンスが低下する可能性もあります。
多くの場合、ローカライズの問題を解決する方法は複数あります。最も重要なことは、それらを事前に検討し、問題に対処するようにアプリケーションを設計することです。
日付、時刻、数値、通貨
.NET 書式設定関数を使用する場合は、小数点区切り記号が正しく解析されるようにカルチャを指定する (変換の例外がスローされないようにする) 必要があります。 たとえば、ロケールに応じて、1.99 と 1,99 が有効な 10 進表現です。
データが既知のソース (つまり、独自のコードまたは制御する Web サービス) から取得される場合は、標準の英語の書式設定で機能する InvariantCulture などの書式設定に一致するカルチャ識別子をハードコーディングできます。
double.Parse("1,999.99", CultureInfo.InvariantCulture);
データがアプリ ユーザーによって入力されている場合は、ロケールを反映する CultureInfo インスタンスを使用してそれを解析します。
double.Parse("1 999,99", CultureInfo.CreateSpecificCulture("fr-FR"));
詳細については、数値文字列の解析と日付と時刻文字列の解析に関する MSDN の記事を参照してください。
右から左に読む (RTL) 言語
アラビア語、ヘブライ語、ウルドゥー語などの一部の言語は、右から左に読む言語です。 これらの言語に対応するアプリケーションでは、次のような右から左に読むリーダーに合わせた画面デザインを採用する必要があります。
- テキストは右揃えにする必要があります。
- ラベルは、入力フィールドの右側に表示されるようにします。
- 通常、既定値のボタンの配置は逆になります。
- コンテキストの方向を使用する階層ナビゲーション スワイプとアニメーション (およびその他のナビゲーション メタファーとアニメーション) も逆にする必要があります。
iOS と Android はどちらも、前述の調整に役立つ組み込みの機能により、右から左に読むレイアウトとフォントのレンダリングをサポートしています。 現在、Xamarin.Forms は、RTL レンダリングを自動的にサポートしていません。
並べ替え
同じ文字セットを使用する場合でも、言語によってアルファベットの並べ替え順序が異なります。
言語 (CultureInfo) が並べ替え順序に影響する例については、.NET Framework で文字列を使用するためのベスト プラクティスに関する記事の「文字列比較の詳細」を参照してください。
モバイル プラットフォームの組み込みのデータベース機能で言語固有の並べ替え順序がサポートされることはほとんどありません。そのため、ビジネス ロジックに追加のコードを実装する必要がある場合があります。
テキスト検索
複数の言語を念頭に置いて、検索アルゴリズムを記述してテストしてください。 次のような考慮事項があります。
- オートコンプリート – オートコンプリート機能を構築している場合は、ユーザーの言語に関連する候補が表示されるようにします。
- クエリをデータに一致させる – 特定の言語で入力される検索クエリは、その言語で記述されたコンテンツのみに対して実行されますか? またはアプリ内のすべてのコンテンツに対して実行されますか?
- ステミング – 類似の語や語源を検索したり、その他の検索の最適化用に検索が構築されている場合、それらの最適化はサポートしているすべての言語に対して構築されていますか?
- 並べ替え – 結果が正しく並べ替えられることを確認します (上記を参照)。
外部ソースのデータ
多くのアプリケーションは、Twitter、RSS フィードから、天気、ニュース、株価まで、外部のソースからデータをダウンロードします。 これをユーザーに表示する場合は、無関係な、または読み取れない情報の画面をユーザーに表示してしまう可能性を考慮する必要があります。
ユーザーに関連するデータがアプリに表示されるようにするために使用できる戦略がいくつかあります。
- さまざまなソース – アプリケーションは、ユーザーの言語やロケールに応じてさまざまなソースからデータをダウンロードする可能性があります。 現地のニュース、天気、株価は、北米のフィードからダウンロードしたものよりも理にかなっているはずです。
- 表示のローカライズ – Twitter または写真フィードを表示する場合は、コンテンツ自体が元の言語で表示されても、メタデータ (かかった時間など) をユーザーの言語で表示する必要があります。
- 翻訳 – アプリに翻訳オプションを組み込んで、入ってくるデータの機械翻訳を行えます。 これは自動でも、ユーザーの独自の判断でも構いませんが、機械翻訳は決して完璧ではないため、これを行った場合は必ずユーザーに知らせてください。
これは、オーディオ トラックやビデオへの外部リンクにも影響がある可能性があります。アプリケーションを設計するときは、翻訳されたコンテンツのソーシングを事前に計画するか、コンテンツがユーザーの言語で表示されない場合にユーザー インターフェイスによって適切に通知されるようにする必要があります。
過剰に翻訳しない
アプリ内の一部の文字列は、翻訳を必要としない場合や、少なくとも翻訳者による特別な注意を必要としない場合があります。 以下は一例です。
- URL – URL を一覧表示する場合は、言語によって調整する必要がある場合と調整が不要な場合があります。 たとえば、facebook.com は翻訳を必要とせず、メイン サイトで言語が自動検出されます。 ロケール固有のコンテンツを持つサイトもあります。その場合は、yahoo.com に対して yahoo.fr や yahoo.it など、さまざまな URL を提供できます。
- 電話番号 – 特に、特定の言語を話す通話者の、国コードや番号が異なる電話番号。
- 連絡先の詳細 – 住所などの情報は、言語やロケール応じて異なる可能性があります。
- 商標と製品名 – 一部の文字列は常に同じ言語で記述されているため、翻訳の必要がない場合があります。
最後に、特定の文字列に特別な処理が必要な場合は、翻訳者用に詳細な指示を必ず含めてください。
書式付きテキスト
文字列は一般的にリッチ形式のテキストではないため、通常はモバイル アプリでは問題になりません。 ただし、アプリでリッチ テキスト (太字や斜体の書式設定など) が必要な場合は、翻訳者が書式設定の入力方法を知っていること、文字列ファイルがこれを正しく格納すること、ユーザーに表示される前にこれが適切に書式設定されていることを確認します (つまり、誤って書式設定コード自体をユーザーに表示したりしないでください)。
翻訳のヒント
アプリケーションで使用される文字列の翻訳は、ローカライズ プロセスの一部とみなされます。 通常、この作業は翻訳サービスに委託され、貴社のアプリケーションやビジネスを知らない可能性のある多言語スタッフによって行われます。
次のヒントは、正確に翻訳しやすく、結果としてローカライズされるアプリの品質を向上させる文字列を生み出すのに役立ちます。
単語ではなく、完全な文字列をローカライズする
場合によっては、開発者は、アプリケーション全体で再利用できるように、単一の単語または文の "スニペット" を指定しようとする場合があります。 たとえば、"5 件のメッセージがあります" というテキストでは、翻訳用に次の文字列を指定します。
不適切:
"You have"
"no"
"message"
"messages"
次に、文字列連結を使用して、コード内で正しい句をその場しのぎで作成しようとします。
不適切:
"You have" + " " + numMsgs + " " + "messages"
"You have" + " no " + "messages"
これは、必ずしもすべての言語で機能するとは限らず、翻訳者が短い各セグメントのコンテキストを理解することが難しくなるため、推奨されません。 また、翻訳された文字列の再利用に繋がり、後で別のコンテキストで使用された場合 (またその後更新された) 場合に問題が発生する可能性があります。
パラメーターの並べ替えを許容する
一部のプログラミング言語では、文字列内のパラメーターの順序を指定する追加の構文が必要ですが、.NET では番号付きプレースホルダーの概念が既にサポートされているため、
適切:
"a {0} b {1} cde {3}"
は、次のように変換できます (プレースホルダーの位置と順序が変更されている)
"{2} {3} f g h {0}"
トークンは翻訳者の希望どおりに並べ替えられます。 翻訳者に文字列を送るときに、各プレースホルダーに何が含まれているかの説明を必ず含めるようにしてください。
カーディナリティに複数の文字列を使用する
"You have {0} message/s." などの文字列を使用しないでください。ユーザー エクスペリエンスを向上させるために、状態ごとに固有の文字列を使用しましょう。
適切:
"You have no messages."
"You have 1 message."
"You have 2 messages."
"You have {0} messages."
アプリ内でコードを記述して、表示される数値を評価し、適切な文字列を選択する必要があります。 一部のプラットフォーム (iOS や Android を含む) には、現在の言語/ロケールの設定に基づいて最適な複数形文字列を自動的に選択する機能が組み込まれています。
性別を考慮する
ラテン語ベースの言語では、主語の性別に応じて異なる単語が使用される場合があります。 アプリが性別を認識する場合は、翻訳された文字列にこれが反映されるようにする必要があります。
英語でも、文字列が特定の人物またはアプリのユーザーを言及する、明らかなケースがあります。 たとえば、一部のサイトでは "Bob commented on his post" のようなメッセージが表示されるため、男性、女性、ノンバイナリー、または不明な性別に合わせた文字列が必要です。
適切:
"{0} commented on his post"
"{0} commented on her post"
"{0} commented on their post"
文字列を再利用しない
または正確には、文字列自体の目的や意味が異なる場合に、似ているという理由だけで文字列を再利用しないでください。
たとえば、アプリにオン/オフ スイッチがあり、スイッチ コントロールで "オン" と "オフ" のテキストのローカライズが必要だとします。 また、その設定の値を、アプリ内の別の場所のテキスト ラベルにも表示するとします。 スイッチの表示とスイッチの状態にそれぞれ別の文字列を使用する必要があります (既定の言語でそれらが同じ文字列であっても)。次に例を示します。
- "On" – スイッチ自体に表示される
- "Off" – スイッチ自体に表示される
- "On" – ラベルに表示される
- "Off" – ラベルに表示される
これにより、翻訳者は、最大限柔軟に翻訳できます。
- 設計上の理由から、たとえば、スイッチ自体では小文字の "on" と "off" を使用しますが、表示ラベルでは大文字の "On" と "Off" を使用します。
- 一部の言語では、ユーザー インターフェイス コントロールに収まるようにスイッチ値を短縮する必要がある一方で、完全な (翻訳された) 単語をラベルに表示できます。
- または、一部の言語では、スイッチのレンダリングでカルチャに合わせて "I" と "O" を使用し、ラベルには "On" または "Off" を使用できます。
翻訳サービス
機械翻訳
翻訳機能をアプリに組み込むには、Azure Translator Text API を検討します。
テスト目的の場合は、多くのオンライン翻訳ツールの 1 つを使用して、開発中に、ローカライズされたテキストをアプリに含めることができます。
他にも多くの選択肢があります。 一般に、機械翻訳の品質は、プロの翻訳者やネイティブ スピーカーによって先にレビューおよびテストされることなくアプリケーションをリリースするには十分とはいえません。
プロフェッショナルな翻訳
また、文字列を受け取り、自社の翻訳者に配布して、完成した翻訳を有料で提供する専門の翻訳サービスもあります。
最もよく知られているサービスの 1 つは、LionBridge です。 ほとんどの専門サービスでは、文字列、XML、RESX、POT/PO など、あらゆる一般的なファイルの種類がサポートされています。
まとめ
この記事では、アプリを国際化してからリソースをローカライズする前に理解しておく必要がある概念の一部を紹介し、各プラットフォームの言語設定を変更する方法についても紹介しました。
これらの概念は、Xamarin で可能なさまざまなプラットフォーム固有かつクロスプラットフォームの国際化手法に適用できます。
目的のプラットフォームの技術的な詳細を引き続きお読みください。
- RESX ファイルを使用した Xamarin.Forms クロスプラットフォームのローカライズ。
- Xamarin.iOS ネイティブ プラットフォームのローカライズ。
- Xamarin.Android ネイティブ プラットフォームのローカライズ。