docs/html-intl/intl/ko/preview/features/multilingual-support.jd - platform/frameworks/base - Git at Google

 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> 앱이 사용자의 두 번째 선호 로케일 설정에만 일치할 때
 리소스 결정.</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에서 지원되는 로케일 세트가 확장되면서
 단일 로케일 내에서조차
 날짜, 시간, 통화 및 유사 정보에
 큰 차이가 생길 수 있게 되었습니다. 형식 하드코딩은
 최종 사용자에게 혼란을 줄 수 있습니다.  그러므로 Android N을 개발할 때는
 숫자와 날짜 문자열을 하드코딩하는 대신 포맷터를 사용하도록 하세요.</p>

 <p>가장 좋은 예시로는 아랍어가 있습니다. Android N에서 아랍어 지원이
 {@code ar_EG} 1개에서 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> 앱이 사용자의 두 번째 선호 로케일 설정에만 일치할 때
	리소스 결정.</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에서 지원되는 로케일 세트가 확장되면서
	단일 로케일 내에서조차
	날짜, 시간, 통화 및 유사 정보에
	큰 차이가 생길 수 있게 되었습니다. 형식 하드코딩은
	최종 사용자에게 혼란을 줄 수 있습니다. 그러므로 Android N을 개발할 때는
	숫자와 날짜 문자열을 하드코딩하는 대신 포맷터를 사용하도록 하세요.</p>

	<p>가장 좋은 예시로는 아랍어가 있습니다. Android N에서 아랍어 지원이
	{@code ar_EG} 1개에서 27개 아랍어 로케일로 확장되었습니다. 이러한 로케일은 대부분의 리소스를 공유할 수 있지만
	어떤 로케일은 ASCII 숫자를 선호하고 어떤 로케일은 네이티브 숫자를 선호합니다. 예를 들어,
	"4자리 PIN 선택"과 같은 숫자 변수가 포함된 문장을 생성하려면
	아래와 같이 포맷터를 사용합니다.</p>

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