Hour 19. Bonjour, World! Localizing Your Apps
What You’ll Learn in This Hour
Android as a global marketplace
Supporting multiple languages
Calendar, currency, and other localization concerns
Localization checklist
The Android marketplace is global—serving many countries and locales. The global market provides an opportunity to bring your app to more people. You might also find that your app is a catching on in a particular country. So being international can expand both the number of people who use your app and increase the possibility of your app catching on in a particular locale. This hour covers localization features on the Android platform and strategies for localization.
General Internationalization Principles
With a global marketplace, developers can maximize profits and grow their user base by supporting a variety of different languages and locales. Let’s make a distinction between languages and locales. You understand what a language is. Languages may include a number of different locales commonly called dialects. For example, the Spanish spoken in Spain is different from that spoken in the Americas; the French spoken in Canada differs from that spoken in Europe and Africa; and the English spoken in the United States differs from that spoken in Britain. English is a language, while English (United States), English (United Kingdom), and English (Australia) are locales. The Android platform provides support at the locale level.
Applications are made up of data and functionality. For most applications, the functionality is the same, regardless of the locale. However, the data must be localized. This is one of the key reasons resource files exist—to externalize application data. Locale and language differences include different word spellings, meanings, slang, and format of regional data such as date and time and primary currency. The most common type of application data that requires localization is the strings of text used by the application. For example, a string of data might represent a user’s name, but the text label for that value on an application screen needs to be shown in the proper language (for example, Name, Nom, Nombre).
Development platforms that support internationalization typically allow for string tables, which can be swapped around so that the same application can target different languages. The Android platform is no exception.
Do not hard code localizable data such as string information into the application source files, particularly in Java and layout resource files. Doing so hinders internationalization efforts. (Note that for simplicity and clarity of code examples, the authors have not followed this practice in earlier examples in this book.)
Working with Localization with Android
The Android SDK provides extensive support for internationalization through the use of locales.
Android localization considerations fall into three main categories:
The languages and locales supported by the Android platform (an extensive list—the superset of all available languages)
The languages and locales supported by a specific Android device (a list that varies—a subset of languages chosen by a device manufacturer or operator)
The countries, languages, and locales supported by the Android Market application (the countries and locales where Google can sell legally; this list grows continuously)
At a high level, a locale is specified by language code and country code. For example, the constants en_US, en_GB, and en_AU represent the English language as spoken in the United States, Great Britain, and Australia, respectively.
The only locale that is guaranteed to be available is en_US locale. Not all devices will have all locales. A device sold in the US will likely support en_US and es_US (English and Spanish for the U.S.), but will not necessarily support en_GB (English Great Britain).
Note: Language Codes and Country Codes
Languages codes and country codes are defined by ISO standards. Language codes are defined in ISO 639-1 and country codes are defined in ISO 3166-1.
Handling Locales with Android
Much like other operating systems, the Android platform has a system setting for locale. This setting has a default setting that the mobile operator can modify. For example, a German mobile operator might make the default locale Deutsch (Deutschland) for its shipping devices. An American mobile operator would likely set the default locale to English (American) and include an option for the locale Español (Estados Unidos)—thus supporting American English and Spanish of the Americas.
A user can change the systemwide setting for locale in the Settings application. The locale setting affects the behavior of all applications installed on the device. Some apps might support the selected language and others might not. If the app does not support the selected language, the default language for that app will be used.
Figure 19.1 shows the Settings application.
Using Applications to Handle Locales
Now take a look at how the systemwide locale setting affects an 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 include language and locale resources by providing resources in specially named resource directories of the project. You can localize any application resource, whether it is a string resource file, a drawable, an animation sequence, or some other type. Considering setting locales for layout is important resources. Layouts that are carefully reviewed in English might need to change for other languages. A short word in one language might be a long word in another language. If your buttons just fit in a layout, you might need to change them for other locales.
Specifying Default Resources
Hour 3 introduced using a resource file, and in Hour 4, you saw how to use resource qualifiers such as layout-land to specify alternative resources for different conditions.
A default resource is a resource that has no resource qualifiers.
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).
Specifying Language-Specific Resources
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. 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 an application to support English, German, and French strings. To do so, 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 can 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 are used.
Similarly, you could provide German-specific drawable resources to override the default graphics in the /res/drawable/ directory by supplying versions (each with the same name) in the /res/drawable-de/ directory.
Tip: Limit Text in Image Resources
Your app might require different images for different locales, but using most images in all locales is ideal. Changing a text file is easier and relatively less time consuming than changing an image. So, try to minimize, or ideally eliminate, all text in image resources.
Specifying Region-Specific Resources
You might have noticed that the previous example specifies high-level language settings only (English, but not American English versus British English versus Australian English). Adding the region or locale as part of the resource directory name is a straightforward process as well.
To specify strings for a specific language and locale, you must store the localized resource under a specially named directory that includes the two-letter language code provided in ISO 639-1 followed by a dash, then a lowercase r, and finally the ISO 3166-1-alpha-2 region code. 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.
To support these three versions of English, do the following:
1. Create a strings.xml resource file for each language. You can leave any strings you don’t want to localize 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, start with a default set of resources, which should be in the most common language your application will rely on. Then, 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.
Reviewing Apps in Multiple Languages
In the earlier Try It Yourself section, you saw how to change the locale on the phone. Changing locales is an easy way to review apps that you are familiar with in another language. It can be helpful for doing simple translations. You might be able to see the words for OK, Cancel, Settings, and playlist in another language. The best way to translate an app is to work with a native speaker, but for a simple app, looking at other apps in the target language can be helpful.
Figure 19.2 shows the Google+ menu in Spanish. It provides a hint about the words for profile and photos among others.
Translation services are also available for websites and apps. As part of the Android publishing process in Google Play, you have the option to get a professional translation. It is a paid service, but one that might be worthwhile for your app.
Open-source Android projects might include language resource files that can be helpful to start translating an app.
Android Internationalization Strategies
Internationalization might be important to your project or a nice enhancement, or it might not be particularly important. Therefore, give some thought to how important internationalization is to your application during the design phase of your project. Develop a strategy that suits your specific needs and follow through on that strategy.
You might “discover” a strategy as you develop your app and see how it is used.
A typical sequence for internationalizing an app would be to
Create a prototype in your target locale. You might have some hard-coded text values as you develop the product.
Externalize your strings—move any hard-coded text resources into resource files.
Add one language for a market where your app is doing well by adding a language-specific resource file.
Add more customizations for your new market by customizing the graphics and layouts as needed.
Add another language and continue on through this process.
Work through the new issues that come up as you perform these steps, but realize that Android has a robust way of handling internationalization.
No single rule exists for internationalization, but you can consider three approaches:
No internationalization
Limited internationalization
Implement robust internationalization for target audiences
The following sections consider each of these strategies in more detail.
Forgoing Application Internationalization
Whenever possible, save your development and testing teams a lot of work—don’t bother to internationalize your application. This is the “one size fits most” approach to mobile development, and using it is often possible with simple, graphic-intensive applications such as games that do not have a lot of text to display. If your application is simple enough to work smoothly with internationally recognized graphical icons (such as play, pause, stop, and so on) instead of text labels, then you might be able to forgo internationalization entirely. Games such as tic-tac-toe and chess are games that require little, if any, text resources.
Tip: Always Put Strings in Resource Files
Even if you are not planning on internationalizing your app, externalizing strings is a best practice. When a text value is in the res/values resource folder in the strings.xml file, it is a single point of reference for the value. You can use them in multiple source files and then if you need to change it, you make the change in one place.
Some of the pros of this strategy are the following:
Simplified development and testing
Smallest application size (only one set of resources)
Some of the cons of this strategy are the following:
For text- or culture-dependent applications, this approach greatly reduces the value of the application. It is simply too generic.
This strategy automatically alienates certain audiences and limits your application’s potential marketplaces.
This technique works only for a subset of applications. If your application requires a help screen, for example, you’re likely going to need at least some localization for your application to work well all over the world.
Limiting Application Internationalization
Most applications require only some light internationalization. This often means internationalizing string resources only, but other resources, such as layouts and graphics, remain the same for all languages and locales.
Some of the pros of this strategy are the following:
Modest development and testing requirements
Streamlined application size (specialized resources kept to a minimum)
Some of the cons of this strategy are the following:
This strategy might still be too generic for certain types of applications. Overall design (especially screen design) might suffer from needing to support multiple target languages. For example, text fields might need to be large enough to support verbose languages such as German but look odd and waste valuable screen real estate in less verbose languages.
Because you’ve headed down the road of providing language-specific resources, your users are more likely to expect other languages you haven’t supported. In other words, you’re more likely to start getting requests for your app to support more languages if you’ve supported some. That said, you’ve already built and tested your application on a variety of languages, so adding new ones should be a straightforward process.
Implementing Robust Application Internationalization
Some types of applications require complete internationalization. Providing custom resources for each supported language and locale is a time-intensive endeavor. This approach often necessitates breaking the individual languages into separate APK files for publication, resulting in more complex configuration management. However, this allows a developer to tailor an application for each specific marketplace to a fine degree.
Some of the pros of this strategy are the following:
The application is fully tailored and customized to individual audiences; this strategy allows for tweaks to individual locales.
It builds user loyalty by providing users with the best, most customized experience. (This is also a technique used by Google.)
Some of the cons of this strategy are the following:
It is the most lengthy and complicated strategy to develop.
Each internationalized version of the application must be fully tested as if it were a completely different application (which it might well be, if you are forced to split it into different APK files due to application size).
Using Localization Utilities
The Android SDK includes support for handling locale information. For example, the Locale (java.util.Locale) class encapsulates locale information.
Determining System Locale
If you need to modify application behavior based on locale information, you must be able to access information about the Android operating system. You can do this by using the getConfiguration() method of the Context object, as follows:
Configuration sysConfig = getResources().getConfiguration();
One of the settings available in the Configuration object is the locale:
Locale curLocale = sysConfig.locale;
You can use this locale information to vary application behavior programmatically, as needed.
Formatting Date and Time Strings
Another aspect of internationalization is displaying data in the appropriate way. For example, U.S. dates are formatted MM/DD/YY and October 26, 2013, whereas much of the rest of the world uses the formats DD/MM/YY and 26 October 2013. The Android SDK includes a number of locale-specific utilities. For example, you can use the DateFormat (android.text.format.DateFormat) class to generate date and time strings in the current locale, or you can customize date and time information as needed for your application.
Handling Currencies
Much like dates and times, currencies and how they are formatted differ by locale. You can use the standard Java Currency (java.util.Currency) class to encapsulate currency information. Use the NumberFormat (java.text.NumberFormat) class to format and parse numbers based on locale information.
Summary
This hour covered basic internationalization principles such as externalizing project resources. You learned how the Android platform handles different countries, languages, and locales. Finally, it covered several strategies for internationalization.
Q&A
Q. Which languages and locales should I target in my Android applications?
A. The answer to this question depends on a variety of factors and is particular to your app and your business plan for the app. The short answer is this: The fewest you can get away with. The answer boils down to knowing your user audience and target markets.
Q. What languages should I use for default resources such as strings?
A. Your default resources should be in the language/locale used by your largest target audience—the most generic and likely values that appeal to the most users. If you’re targeting the world at large, the choice is often English, but it need not be. For example, if your application allows turn-based directions anywhere in China, then you probably want your default language/locale to be one of the Chinese options.
Q. I changed the locale to Spanish. Why do some applications still display in English?
A. If an application has its default strings in English and has no Spanish resources available, then the defaults are used, regardless of the language chosen.
Workshop
Quiz
1. True or false: An Android application can support multiple languages within a single APK file.
2. What language should your default resources be?
A. English
B. The language that most appeals to your target audience
C. En_US
Answers
1. True. An application can be compiled with resources in several different languages. The Android platform can switch between these resources on-the-fly, based upon the locale settings of the device.
2. The correct answer is B. Your default resources should be the ones that are most likely to load and be used. Therefore, designing these resources to be in the language and locale that appeals to the most number of users makes sense.
Exercises
1. Add a new set of string resource values to an app from a previous hour in the language or locale of your choice.
2. Change any app from a previous chapter so that it loads a custom drawable or color resource for a specific language or locale.
3. Review Hour 3 and Hour 4 with a focus on how to use resource files and resource qualifiers for localization. In particular, review the qualifier types listed in Table 4.1 (refer to Hour 4).