Internationalizing Applications Android

Android users hail from many different parts of the world. They speak different languages, use different currencies, and format their dates in different ways—just to name a few examples.Android application internationalization generally falls into three categories:

  • Providing alternative resources such as strings or graphics for use when the application is running in different languages
  • Implementing locale-independent or locale-specific code and other programmatic concerns
  • Configuring your application for sale in foreign markets—a topic we discuss further in Chapter “Selling Your Android Application”

We already discussed how to use alternate resources, but perhaps another example is in order—let’s look at an application that loads resources based upon the device language settings. Specifically, let’s consider a simple application that loads different string and graphic resources based upon the language and region settings of the device.

Internationalization Using Alternative Resources

Let’s look at two examples of how to use alternative resources—this time, to localize an application for a variety of different languages and locales. By language, we mean the linguistic variety such as English, French, Spanish, German, Japanese, and so on. By locale, we are getting more specific, such as English (United States) versus English (United Kingdom) or English (Australia).There are times when you can get away with just providing language resources (English is English is English, right?) and times when this just won’t fly.

Our first example is theoretical. If you want your application to support both English and French strings (in addition to the default strings), you can simply create two additional resource directories called /res/values-en (for the English strings.xml) and /res/values-fr (for the French strings.xml).Within the strings.xml files, the resource names are the same. For example, the /res/values-en/strings.xml file could look like this:

<?xml version="1.0" encoding="utf-8"?>
<string name="hello">Hello in English!</string>
Whereas, the /res/values-fr/strings.xml file would look like this:
<?xml version="1.0" encoding="utf-8"?>
<string name="hello">Bonjour en Français!</string>

A default layout file in the /res/layout directory that displays the string refers to the string by the variable name @string/hello, without regard to which language or directory the string resource is in. The Android operating system determines which version of the string (French, English, or default) to load at runtime. A layout with a TextView control to display the string might look like this:

<?xml version="1.0" encoding="utf-8"?>
android:text="@string/hello" >
The string is accessed programmatically in the normal way:
String str = getString(R.string.hello);

It’s as easy as that. So, we move on to a more complex example, which illustrates how you can organize alternative application resources in order to provide functionality based upon the device language and locale.

Again, this application has no real code to speak of. Instead, all interesting functionality depends upon the judicious and clever use of resource folder qualifiers to specify resources to load. These resources are

  • The default resources for this application include the application icon stored in the /res/drawable directory, the layout file stored in the /res/layout directory, and the strings.xml string resources stored in the /res/values directory. These resources are loaded whenever there isn’t a more specific resource available to load. They are the fallbacks.
  • There are English string resources stored in the /res/values-en directory. If the device language is English, these strings load for use within the default layout.
  • There are French Canadian string resources stored in the /res/values-fr-rCA directory. If the device language and locale are set to French (Canada), these strings load for use within the layout. But wait! There’s also an alternative layout stored in the /res/layout-fr-rCA directory, and this alternative layout uses a special drawable graphic (the Quebec flag) stored in the /res/drawable-fr-rCA directory.
  • Finally, there are French string resources stored in the /res/values-fr directory. If the device language is French (any locale except Canada), these strings load for use within the default layout.

In this way, the application loads different resources based upon the language and locale information, as shown in Figure. This figure shows the project layout, in terms of resources, as well as what the screen might look like when the device settings are set to different languages and locales.

Changing the Language Settings

Generally, a device ships in a default language. In the United States, this language is English (United States). Users who purchase devices in France, however, are likely to have a default language setting of French (France), while those in Britain and many British territories would likely have the language set to English (United Kingdom)—that said, Australia and New Zealand have their very own English settings and Canada has both an English (Canada) option and a French (Canada) language option.

Using alternative resources for different language string resources.

Using alternative resources for different language string resources.

To change the locale setting on the emulator or the device, you need to perform the following steps:

  1. Navigate to the Home screen.
  2. Press the Menu button.
  3. Choose the Settings option.
  4. Scroll down and choose the Language & keyboard settings.
  5. Choose the Select Language option.
  6. Select the locale you want to change the system to, for example, French (France), English (United States), or English (United Kingdom).

Make sure you memorize the steps (and related icons, such as the Settings icon) required to change the language settings, as you need to navigate back to this screen in that foreign language, in order to change the settings back.

Changing device language settings.

Changing device language settings

The Settings icon in English and French (left) and the Settings menu in French (right).

The Settings icon in English and French (left) and the Settings menu in French (right).

Internationalization forces design choices on the development team. For example, will you build one big project for all languages, or will you break the applications up by region? For some projects with light internationalization, you might be able to get away with one project with all internationalized resources. For deep internationalization, you might need to reorganize projects so that no application becomes too large or cumbersome for the user.

Because much of the work for application localization revolves around alternative resources, this means that this work might fall not to a developer who knows how to use Eclipse and the Android tools well, but to a designer who needs some training on how Android internationalization works, how resources can be layered, and the drawbacks of over-internationalizing (resulting in very large package files with many graphics and such). On the plus side, this leaves developers free to do what they do best: developing code.

Finally, you’ve likely noticed that the Android alternative resource structure isn’t perfect—especially for countries with multiple official (and unofficial) languages. It is possible to work around these issues, when necessary, by loading graphics programmatically based upon the current locale setting on the device, but this should only be attempted when absolutely necessary.

Implementing Locale Support Programmatically

There are times in which you should ensure that your application code is “locale-aware.” Often, this means writing code that is flexible enough to run smoothly regardless of the locale. However, when your application needs to be locale-aware—for example, to download appropriate content from a remote application server—you should rely upon localefriendly methods.

Here are some pointers for developing applications that work in a variety of locales:

  • Begin by accepting that different parts of the world have different ways of expressing common information. Respect these differences and support them when feasible.
  • Apply standard methods for internationalizing Java applications.
  • Most localization issues with application code revolve around the use and formatting of strings, numbers, currencies, dates, and times. Audio and video containing speech is also routinely localized.
  • Don’t make assumptions about character encodings or what locale your application is running in.
  • Always use locale-friendly methods, when they are available. Often, a class has two versions of a method: one that uses the current locale, and another that includes a locale parameter that you can use when necessary to override behavior.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Android Topics