Android N Developer Preview provides enhanced support for multilingual users, +allowing them to select multiple locales in settings. The N Developer Preview +provides this capability by greatly expanding the number of locales supported +and changing the way the system resolves resources. The new method of resolving +resources is more robust and designed to be compatible with existing APKs, but +you should take extra care to spot any unexpected behavior. For example, you +should test to make sure that your app defaults to the expected language. Also, +if it supports multiple languages, you should ensure that this support works as +intended. Last, you should try to ensure that your app gracefully handles +languages that you didn't explicitly design it to support.
+ +This document starts by explaining the resource resolution strategy prior to +the N Developer Preview. Next, it describes the N Developer Preview's improved +resource-resolution strategy. Last, it explains how to take advantage of +the expanded number of locales to support more multilingual users.
+ +Prior to the Android N Developer Preview, Android could not always successfully + match app and system locales. For example, suppose that your app's default language + is US English, but that it also has Spanish strings localized in {@code es_ES} + resource files.
+When your Java code referred to strings, it would resolve string languages as +follows:
+These resolution problems arose because the system stripped the country code + off of the locale if it could not find an exact match. For example:
++Table 1. Resource resolution without an exact locale match. +
+| User Settings | +App Resources | +Resource Resolution | +
|---|---|---|
| fr_CH | +
+default (en) +de_DE +es_ES +fr_FR +it_IT + |
+
+Try fr_CH => Fail +Try fr => Fail +Use default (en) + |
+
In this example, the system displays English strings without +knowing whether the user can understand English. This behavior is pretty common +today. The Android N Developer Preview should substantially reduce the frequency +of outcomes like this one.
+ +The Android N Developer Preview brings more robust resource resolution, and
+finds better fallbacks automatically. However, to speed up resolution and improve
+ maintainability, you should store resources in the most common parent dialect.
+ For example, if you were storing Spanish resources in the {@code es-US} directory
+ before, move them into the {@code es-419} directory, which contains Latin American Spanish.
+ Similarly, if you have resource strings in a folder named {@code en-GB}, rename
+ the folder to {@code en-001} (international English), because the most common
+ parent for en-GB strings is {@code en-001}.
+ The following examples explain why these practices improve performance and
+reliability of resource resolution.
With the N Developer Preview, the case described in Table 1 is resolved +differently:
++Table 2. An improved resolution strategy for when there is no +exact locale match.
+| User Settings | +App Resources | +Resource Resolution | +
|---|---|---|
|
+
+default (en) +de_DE +es_ES +fr_FR +it_IT + |
+
+Try fr_CH => Fail +Try fr => Fail +Try children of fr => fr_FR +Use fr_FR + |
+
Now the user gets French resources instead of English. This example also shows + why you should store French strings in {@code fr} rather than {@code fr_FR} + for Android N. Here the course of action is to match the closest parent dialect, + making resolution faster and more predictable.
+ +In addition to this improved resolution logic, Android now offers more + user languages to choose from. Let’s try the above example again with Italian + specified as an additional user language, but without app support for French.
+ ++Table 3. Resource resolution when the app only matches the +user's second-preferred locale setting.
+| User Settings | +App Resources | +Resource Resolution | + +
|---|---|---|
|
+
+default (en) +de_DE +es_ES +it_IT + |
+
+Try fr_CH => Fail +Try fr => Fail +Try children of fr => Fail +Try it_CH => Fail +Try it => Fail +Try children of it => it_IT +Use it_IT + |
+
+
The user still gets a language they understand, even though the app doesn’t +support French.
+ + +The Android N Developer Preview adds a new API {@code LocaleList.GetDefault()} +that lets apps directly query the list of languages a user has specified. This API +allows you to create more sophisticated + app behavior and better-optimized display of content. For example, Search + can show results in multiple languages based on user’s settings. Browser apps + can avoid offering to translate pages in a language the user already knows, + and keyboard apps can auto-enable all appropriate layouts.
+ +Up through Android 6.0 (API level 23), Android supported only one or two locales + for many common languages +(en, es, ar, fr, ru). Because there were only a few variants of each language, +apps could get away with storing some numbers and dates as hard coded strings +in resource files. However, with Android's broadened set of supported locales, +there can be +significant differences in formats for dates, times, currencies, and similar +information even within a single locale. Hard-coding your formats can produce a +confusing experience for end users. Therefore, when developing for Android N +make sure to use formatters instead of hard coding numbers and date strings.
+ +A prime example is Arabic, whose support the Android N expands from +one {@code ar_EG} to 27 Arabic locales. These locales can share most resources, +but some prefer ASCII digits, while others prefer native digits. For example, +when you want to create a sentence with a digit variable, such as +"Choose a 4 digit pin", use formatters as shown below:
+ +format(locale, "Choose a %d-digit PIN", 4)