docs/html-intl/intl/ja/preview/features/multilingual-support.jd - platform/frameworks/base - Gitiles

 page.title=言語とロケール
 page.tags=androidn
 page.image=images/cards/card-nyc_2x.jpg

 @jd:body

 <div id="qv-wrapper">
 <div id="qv">
 <h2>このドキュメントの内容:</h2>
 <ol>
 	  <li><a href="#preN">言語リソースの解決における課題</a></li>
     <li><a href="#postN">リソース解決方針の改善</a></li>
     <li><a href="#design">追加のロケールをサポートするためのアプリ設計
 </a></li>

 </ol>

 </div>
 </div>

 <p>Android N では、複数言語のユーザーのサポートが強化されており、設定で複数のロケールを選択できます。
 Android N ではこの機能を提供するために、サポート対象のロケール数を大幅に拡大し、システムがリソースを解決する方法を変更しました。

 この新しいリソース解決方法は、より堅牢で、既存の APK との互換性を保つよう設計されていますが、予想外の動作には十分に注意してください。

 たとえば、アプリで目的の言語がデフォルトに設定されているかをテストする必要があります。
 また、アプリで複数の言語をサポートする場合、そのサポートが意図したとおりに機能するかを確かめてください。

 最後に、明示的にサポートを設計していない言語については、アプリで適切に処理する必要があります。
 </p>

 <p>このドキュメントでは最初に、Android N より前のバージョンのリソース解決方針について説明します。次に、Android N の改善されたリソース解決方針について説明します。

 最後に、増大したロケールを活用し、より多くの複数言語ユーザーをサポートする方法について説明します。
 </p>

 <h2 id="preN">言語リソースの解決における課題</h2>

 <p>Android N より前のバージョンの Android では、アプリとシステムのロケールを一致させることができない場合がありました。
 </p>

  <p>たとえば、以下の状況を想定します。</p>
  <ul>
  <li>アプリのデフォルトの言語が {@code en_US}（米国英語）で、{@code es_ES} リソース ファイルでスペイン語の文字列もローカライズされています。

 </li>
  <li> 端末は {@code es_MX} に設定されています。 </li>

 <p>Java コードが文字列を参照するときに、アプリでスペイン語のリソースが {@code es_ES} でローカライズされている場合でも、システムではデフォルト（{@code en_US}）リソース ファイルから文字列が読み込まれます。

 これは、システムで完全一致が見つからない場合に、ロケールから国コードを削除して引き続きリソースを探すためです。

 最後に、一致が見つからない場合は、デフォルトである {@code en_US} にフォールバックされます。
  </p>


 <p>ユーザーがアプリでまったくサポートされていないフランス語などを選択した場合にも、システムはデフォルトの {@code en_US} を読み込みます。
 次に例を示します。</p>

 <p class="table-caption" id="t-resource-res">
 <strong>表 1.</strong> ロケールの完全一致がない場合のリソース解決
 </p>
 <table>
 <tbody>
 <tr>
 <th>ユーザー設定</th>
 <th>アプリのリソース</th>
 <th>リソース解決</th>
 </tr>
 <tr>
 <td>fr_CH</td>
 <td>
 デフォルト（en）<br>
 de_DE<br>
 es_ES<br>
 fr_FR<br>
 it_IT<br>
 </td>
  <td>
 fr_CH を試行 =&gt; 失敗<br>
 fr を試行 =&gt; 失敗<br>
 デフォルト（en）を使用
 </td>
  </tr>
  </tbody>
 </table>


 <p>この例では、システムはユーザーが英語を理解できるかどうかを認識せず、英語の文字列を表示します。
 この動作は現在、ごく一般的です。
 Android N では、このような状況が大幅に削減されるはずです。
 </p>

 <h2 id="postN">リソース解決方針の改善</h2>
 <p>Android N は、より堅牢なリソース解決を導入しており、自動的に適切な代替言語を見つけます。
 ただし、解決を迅速化し保守性を向上させるには、最も一般的な親言語でリソースを保存する必要があります。

  たとえば、これまで {@code es-US} ディレクトリにスペイン語のリソースを保存していた場合、{@code es-419} ディレクトリに移動します。ここには、ラテンアメリカのスペイン語が格納されます。

  同様に {@code en-GB} という名前のフォルダにリソースを保存している場合、そのフォルダの名前を {@code en-001}（国際英語）に変更します。<code>en-GB</code> 文字列の最も一般的な親言語は {@code en-001} であるためです。


  次の例では、このような対応がリソース解決のパフォーマンスと信頼性を向上する根拠について説明します。
 </p>

 <h3>リソース解決の例</h3>

 <p>Android N では、<strong>表 1</strong> で説明した例の解決方法が異なります。
 </p>

 <p class="table-caption" id="t-improved-res">
 <strong>表 2.</strong> ロケールの完全一致が存在しない場合の改善された解決方針
 </p>
 <table>
 <tr>
 <th>ユーザー設定</th>
 <th>アプリのリソース</th>
 <th>リソース解決</th>
 </tr>
 <tr>
 <td><ol>
 <li> fr_CH</li>
 </ol>
 </td>
 <td>
 デフォルト（en）<br>
 de_DE<br>
 es_ES<br>
 fr_FR<br>
 it_IT<br>
 </td>
 <td>
 fr_CH を試行 =&gt; 失敗<br>
 fr を試行 =&gt; 失敗<br>
 fr の子言語を試行 =&gt; fr_FR<br>
 fr_FR を使用
 </td>
 </tr>

 </table>


 <p>これで、ユーザーは英語ではなくフランス語のリソースを利用できます。この例は、フランス語の文字列を Android N の {@code fr_FR} ではなく {@code fr} に保存すべき理由も示しています。これが、最も近い親言語と一致させ、迅速に解決し、予測しやすくするための対策になります。


 </p>

 <p>この改善された解決ロジックに加えて、Android では、選択できるユーザー言語を増やしました。
 もう一度上記の例で説明します。今回は、追加のユーザー言語としてイタリア語が指定され、アプリはフランス語をサポートしていません。
   </p>

 <p class="table-caption" id="t-2d-choice">
 <strong>表 3.</strong> アプリがユーザーの 2 番目に優先されるロケール設定のみと一致する場合のリソース解決
 </p>
 <table>
 <tr>
 <th>ユーザー設定</th>
 <th>アプリのリソース</th>
 <th>リソース解決</th>

 </tr>
 <tr>
 <td><ol>
 <li> fr_CH</li>
 <li> it_CH</li>
 </ol>
 </td>
 <td>
 デフォルト（en）<br>
 de_DE<br>
 es_ES<br>
 it_IT<br>
 </td>
 <td>
 fr_CH を試行 =&gt; 失敗<br>
 fr を試行 =&gt; 失敗<br>
 fr の子を試行 =&gt; 失敗<br>
 it_CH を試行 =&gt; 失敗<br>
 it を試行 =&gt; 失敗<br>
 it の子言語を試行 =&gt; it_IT<br>
 it_IT を使用
 </td>

 </tr>

 </table>
 <p>アプリでフランス語をサポートしていなくても、ユーザーが理解できる言語が使用されます。
 </p>


 <h2 id="design">追加のロケールをサポートするためのアプリ設計</h2>
 <h3>LocaleList API</h3>

 <p>Android N では、新しい API {@code LocaleList.getDefault()} が加わりました。これにより、アプリは直接、ユーザーが指定した言語のリストを問い合わせることができます。
 この API を使用すると、アプリの動作がさらに洗練され、コンテンツの表示がより最適化されます。

 たとえば検索で、ユーザーの設定に基づいて複数の言語で結果を表示できます。
 ブラウザ アプリは、ユーザーが理解できる言語の翻訳ページを表示することがなくなり、キーボード アプリは、自動的に最適なレイアウトを有効にすることができます。

  </p>

 <h3>フォーマッタ</h3>

 <p>Android 6.0（API レベル 23）までは、Android は多くの一般的な言語（en、es、ar、fr、ru）に対して 1 つか 2 つのロケールのみをサポートしていました。

 各言語にはわずかなバリエーションしかなかったため、アプリはリソース ファイルでハードコーディングされた文字列として数字や日付を保存し、処理することができました。

 しかし Android で幅広いロケールのセットがサポートされるようになったため、日付、時刻、通貨などの情報は、1 つのロケール内でも形式が大幅に異なる場合があります。


 形式をハードコーディングすると、エンドユーザーが混乱するおそれがあります。
 したがって、Android N で開発するときは、数字や日付の文字列をハードコーディングせず、必ずフォーマッタを使用してください。
 </p>

 <p>その良い例がアラビア語です。アラビア語のロケールのサポートは {@code ar_EG} の 1 つだけでしたが、Android N では 27 に増えました。
 これらのロケールは、ほとんどのリソースを共有できますが、数字は ASCII 表記とネイティブ表記で好みが分かれています。
 たとえば、「4 桁の PIN を選択してください」など、数字の変数を含む文を作成する場合、以下のようにフォーマッタを使用します。

 </p>

 <pre> format(locale, "Choose a %d-digit PIN", 4)</pre>
	page.title=言語とロケール
	page.tags=androidn
	page.image=images/cards/card-nyc_2x.jpg

	@jd:body

	<div id="qv-wrapper">
	<div id="qv">
	<h2>このドキュメントの内容:</h2>
	<ol>
	<li><a href="#preN">言語リソースの解決における課題</a></li>
	<li><a href="#postN">リソース解決方針の改善</a></li>
	<li><a href="#design">追加のロケールをサポートするためのアプリ設計
	</a></li>

	</ol>

	</div>
	</div>

	<p>Android N では、複数言語のユーザーのサポートが強化されており、設定で複数のロケールを選択できます。
	Android N ではこの機能を提供するために、サポート対象のロケール数を大幅に拡大し、システムがリソースを解決する方法を変更しました。

	この新しいリソース解決方法は、より堅牢で、既存の APK との互換性を保つよう設計されていますが、予想外の動作には十分に注意してください。

	たとえば、アプリで目的の言語がデフォルトに設定されているかをテストする必要があります。
	また、アプリで複数の言語をサポートする場合、そのサポートが意図したとおりに機能するかを確かめてください。

	最後に、明示的にサポートを設計していない言語については、アプリで適切に処理する必要があります。
	</p>

	<p>このドキュメントでは最初に、Android N より前のバージョンのリソース解決方針について説明します。次に、Android N の改善されたリソース解決方針について説明します。

	最後に、増大したロケールを活用し、より多くの複数言語ユーザーをサポートする方法について説明します。
	</p>

	<h2 id="preN">言語リソースの解決における課題</h2>

	<p>Android N より前のバージョンの Android では、アプリとシステムのロケールを一致させることができない場合がありました。
	</p>

	<p>たとえば、以下の状況を想定します。</p>
	<ul>
	<li>アプリのデフォルトの言語が {@code en_US}（米国英語）で、{@code es_ES} リソースファイルでスペイン語の文字列もローカライズされています。

	</li>
	<li> 端末は {@code es_MX} に設定されています。 </li>

	<p>Java コードが文字列を参照するときに、アプリでスペイン語のリソースが {@code es_ES} でローカライズされている場合でも、システムではデフォルト（{@code en_US}）リソースファイルから文字列が読み込まれます。

	これは、システムで完全一致が見つからない場合に、ロケールから国コードを削除して引き続きリソースを探すためです。

	最後に、一致が見つからない場合は、デフォルトである {@code en_US} にフォールバックされます。
	</p>


	<p>ユーザーがアプリでまったくサポートされていないフランス語などを選択した場合にも、システムはデフォルトの {@code en_US} を読み込みます。
	次に例を示します。</p>

	<p class="table-caption" id="t-resource-res">
	<strong>表 1.</strong> ロケールの完全一致がない場合のリソース解決
	</p>
	<table>
	<tbody>
	<tr>
	<th>ユーザー設定</th>
	<th>アプリのリソース</th>
	<th>リソース解決</th>
	</tr>
	<tr>
	<td>fr_CH</td>
	<td>
	デフォルト（en）<br>
	de_DE<br>
	es_ES<br>
	fr_FR<br>
	it_IT<br>
	</td>
	<td>
	fr_CH を試行 => 失敗<br>
	fr を試行 => 失敗<br>
	デフォルト（en）を使用
	</td>
	</tr>
	</tbody>
	</table>


	<p>この例では、システムはユーザーが英語を理解できるかどうかを認識せず、英語の文字列を表示します。
	この動作は現在、ごく一般的です。
	Android N では、このような状況が大幅に削減されるはずです。
	</p>

	<h2 id="postN">リソース解決方針の改善</h2>
	<p>Android N は、より堅牢なリソース解決を導入しており、自動的に適切な代替言語を見つけます。
	ただし、解決を迅速化し保守性を向上させるには、最も一般的な親言語でリソースを保存する必要があります。

	たとえば、これまで {@code es-US} ディレクトリにスペイン語のリソースを保存していた場合、{@code es-419} ディレクトリに移動します。ここには、ラテンアメリカのスペイン語が格納されます。

	同様に {@code en-GB} という名前のフォルダにリソースを保存している場合、そのフォルダの名前を {@code en-001}（国際英語）に変更します。<code>en-GB</code> 文字列の最も一般的な親言語は {@code en-001} であるためです。


	次の例では、このような対応がリソース解決のパフォーマンスと信頼性を向上する根拠について説明します。
	</p>

	<h3>リソース解決の例</h3>

	<p>Android N では、<strong>表 1</strong> で説明した例の解決方法が異なります。
	</p>

	<p class="table-caption" id="t-improved-res">
	<strong>表 2.</strong> ロケールの完全一致が存在しない場合の改善された解決方針
	</p>
	<table>
	<tr>
	<th>ユーザー設定</th>
	<th>アプリのリソース</th>
	<th>リソース解決</th>
	</tr>
	<tr>
	<td><ol>
	<li> fr_CH</li>
	</ol>
	</td>
	<td>
	デフォルト（en）<br>
	de_DE<br>
	es_ES<br>
	fr_FR<br>
	it_IT<br>
	</td>
	<td>
	fr_CH を試行 => 失敗<br>
	fr を試行 => 失敗<br>
	fr の子言語を試行 => fr_FR<br>
	fr_FR を使用
	</td>
	</tr>

	</table>


	<p>これで、ユーザーは英語ではなくフランス語のリソースを利用できます。この例は、フランス語の文字列を Android N の {@code fr_FR} ではなく {@code fr} に保存すべき理由も示しています。これが、最も近い親言語と一致させ、迅速に解決し、予測しやすくするための対策になります。


	</p>

	<p>この改善された解決ロジックに加えて、Android では、選択できるユーザー言語を増やしました。
	もう一度上記の例で説明します。今回は、追加のユーザー言語としてイタリア語が指定され、アプリはフランス語をサポートしていません。
	</p>

	<p class="table-caption" id="t-2d-choice">
	<strong>表 3.</strong> アプリがユーザーの 2 番目に優先されるロケール設定のみと一致する場合のリソース解決
	</p>
	<table>
	<tr>
	<th>ユーザー設定</th>
	<th>アプリのリソース</th>
	<th>リソース解決</th>

	</tr>
	<tr>
	<td><ol>
	<li> fr_CH</li>
	<li> it_CH</li>
	</ol>
	</td>
	<td>
	デフォルト（en）<br>
	de_DE<br>
	es_ES<br>
	it_IT<br>
	</td>
	<td>
	fr_CH を試行 => 失敗<br>
	fr を試行 => 失敗<br>
	fr の子を試行 => 失敗<br>
	it_CH を試行 => 失敗<br>
	it を試行 => 失敗<br>
	it の子言語を試行 => it_IT<br>
	it_IT を使用
	</td>

	</tr>

	</table>
	<p>アプリでフランス語をサポートしていなくても、ユーザーが理解できる言語が使用されます。
	</p>


	<h2 id="design">追加のロケールをサポートするためのアプリ設計</h2>
	<h3>LocaleList API</h3>

	<p>Android N では、新しい API {@code LocaleList.getDefault()} が加わりました。これにより、アプリは直接、ユーザーが指定した言語のリストを問い合わせることができます。
	この API を使用すると、アプリの動作がさらに洗練され、コンテンツの表示がより最適化されます。

	たとえば検索で、ユーザーの設定に基づいて複数の言語で結果を表示できます。
	ブラウザアプリは、ユーザーが理解できる言語の翻訳ページを表示することがなくなり、キーボードアプリは、自動的に最適なレイアウトを有効にすることができます。

	</p>

	<h3>フォーマッタ</h3>

	<p>Android 6.0（API レベル 23）までは、Android は多くの一般的な言語（en、es、ar、fr、ru）に対して 1 つか 2 つのロケールのみをサポートしていました。

	各言語にはわずかなバリエーションしかなかったため、アプリはリソースファイルでハードコーディングされた文字列として数字や日付を保存し、処理することができました。

	しかし Android で幅広いロケールのセットがサポートされるようになったため、日付、時刻、通貨などの情報は、1 つのロケール内でも形式が大幅に異なる場合があります。


	形式をハードコーディングすると、エンドユーザーが混乱するおそれがあります。
	したがって、Android N で開発するときは、数字や日付の文字列をハードコーディングせず、必ずフォーマッタを使用してください。
	</p>

	<p>その良い例がアラビア語です。アラビア語のロケールのサポートは {@code ar_EG} の 1 つだけでしたが、Android N では 27 に増えました。
	これらのロケールは、ほとんどのリソースを共有できますが、数字は ASCII 表記とネイティブ表記で好みが分かれています。
	たとえば、「4 桁の PIN を選択してください」など、数字の変数を含む文を作成する場合、以下のようにフォーマッタを使用します。

	</p>

	<pre> format(locale, "Choose a %d-digit PIN", 4)</pre>