From 32e428e78e68a7270ba34d3051e53ec46170208d Mon Sep 17 00:00:00 2001
From: Eric Schmidt Android N provides enhanced support for multilingual users,
-allowing them to select multiple locales in settings. Android N
+ Starting in Android 7.0 (API level 24),
+Android provides enhanced support for multilingual users,
+allowing them to select multiple locales in settings. Android
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 your app supports multiple languages, you should ensure that this support works as
-intended. Finally, 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
-Android N. Next, it describes Android N's improved
-resource-resolution strategy. Last, it explains how to take advantage of
+and changing the way the system resolves resources. This document starts by explaining the resource resolution strategy in
+versions of Android lower than 7.0 (API level 24). Next, it describes
+the improved resource-resolution strategy in Android 7.0.
+Last, it explains how to take advantage of
the expanded number of locales to support more multilingual users. Prior to Android N, Android could not always successfully
+ Prior to Android 7.0, Android could not always successfully
match app and system locales. For example, assume that you have the following situation: In this example, the system displays English strings without
knowing whether the user can understand English. This behavior is pretty common
-today. Android N should substantially reduce the frequency
-of outcomes like this one.Challenges in Resolving Language Resources
-
Android N brings more robust resource resolution, and -finds better fallbacks automatically. However, to speed up resolution and improve +
Android 7.0 (API level 24) 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.
+ 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}.
@@ -105,8 +103,8 @@ reliability of resource resolution.
With Android N, the case described in Table 1 is resolved -differently:
+With versions of Android greater than 7.0, the case described in + Table 1 is resolved differently:
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, + for Android 7.0 or higher. 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 @@ -184,38 +183,48 @@ Use it_IT -
The user still gets a language they understand, even though the app doesnât -support French.
++ The user still gets a language they understand, even though the app doesnât + support French. +
Android N 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 +
+ Starting with Android 7.0 (API level 24), Android exposes the + {@code LocaleList.getDefault()} API + 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.
+ 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 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:
++ 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 7.0 or higher versions, + make sure to use formatters instead of hard coding numbers and date strings.
+ ++ For example, Android 7.0 and higher includes support for + 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)-- 2.11.0