Now let's look at how the system-wide locale setting affects each Android application. When an Android application uses a project resource, the Android operating system attempts to match the best possible resource for the job at runtime. In many cases, this means checking for a resource in the specific language or regional locale. If no resource matches the required locale, the system falls back on the default resource.
Developers can specify specific language and locale resources by providing resources in specially named resource directories of the project. Any application resource can be localized, whether it is a string resource file, a drawable, an animation sequence, or some other type.
So far, every resource in the Been There, Done That! application is a default resource. A default resource is simply a resource that does not have specific tags for loading under different circumstances.
Default resources are the most important resources because they are the fallback for any situation when a specific, tailored resource does not exist (which happens more often than not). In the case of the Been There, Done That! application, the default resources are all in English.
To specify strings for a specific language, you must supply the resource under a specially named directory that includes the two-letter language code provided in ISO 639-1 (see www.loc.gov/standards/iso639-2/php/code_list.php). For example, English is en, French is fr, and German is de. Let's look at an example of how this works.
Say that you want the Been There, Done That! application to support English, German, and French strings. You would take the following steps:
1. Create a strings.xml resource file for each language. Each string that is to be localized must appear in each resource file with the same name, so it will be programmatically loaded correctly. Any strings you don't want to localize can be left in the default (English) /res/values/strings.xml file.
2. Save the French strings.xml resource file to the /res/values-fr/ directory.
3. Save the German strings.xml resource file to the /res/values-de/ directory.
Android can now grab the appropriate string, based on the system locale. However, if no match exists, the system falls back on whatever is defined in the /res/values/ directory. This means that if English (or Arabic, or Chinese, or Japanese, or an unexpected locale) is chosen, the default (fallback) English strings will be used.
Similarly, you could provide a German-specific drawable resource to override one in the default /res/drawable/ directory by supplying one with the same name in the /res/drawable-de/ directory.
You may have noticed that the previous example specifies high-level language settings only (English, but not American English versus British English vs. Australian English). Don't worry! You can specify the region or locale as part of the resource directory name as well.
To specify strings for a specific language and locale, you must supply the resource under a specially named directory that includes the two-letter language code provided in ISO 639-1 (see http://www.loc.gov/standards/iso639-2/php/code_list.php), followed by a dash, then a lowercase r, and finally the ISO 3166-1-alpha-2 region code (see http://www.iso.org/iso/country_codes/iso_3166_code_lists/english_country_ names_and_code_elements.htm). For example, American English is en-rUS, British English is en-rGB, and Australian English is en-rAU. Let's look at an example of how this works.
If you wanted the Been There, Done That! application to support these three versions of English, you could do the following:
1. Create a strings.xml resource file for each language. Any strings you don't want to localize can be left in the default (American English) /res/values/strings.xml file.
2. Save the British English strings.xml resource file to the /res/values-en-rGB/ directory.
3. Save the Australian English strings.xml resource file to the /res/ values-en-rAU/ directory.
To summarize, you start with a default set of resources—which should be in the most common language your application will rely on. Then you add exceptions— such as separate language and region string values—where needed. This way, you can optimize your application so it runs on a variety of platforms.
Did you Know?
Was this article helpful?