As a platform, Android devices are now multilingual “out of the box.” In theory, you can target practically any country, region, or culture in the world with your app. However, your developer conscience is already whispering to you that diving in just anyhow to make versions for every local language under the sun might not be such a bright idea. But with the right approach to app localization, the world is your oyster.
First Make Your Internationalization-localization Plan
What you need first is a plan, often best drawn up with your colleagues in the marketing department. In general, such a plan looks like this:
- Decide which countries and languages your app will support, and in which order of priority. This will depend on factors like the sales potential for your app and any commitments you have already made to customers or business partners.
- Internationalize your app by removing any language dependencies from it, moving content such as text and images out to separate files, and using specific functions to handle different international display formats. This step, when done properly, will require the most of your time and effort.
- Proceed with app localization via the translation of the separate content files from step two, via in-house translators (if you have them) or by using professional translation services. As a developer, your role is to then include the translated content in the app and make sure it displays properly.
Getting Started With Internationalization
Start by identifying the different items in your app, which will need to be internationalized.
- Text strings, images, and audio files are natural candidates.
- Time, date, number, and financial formats, which change as users switch from one language to another, will also need attention.
- New lengths of text may need to be supported. Compared to English, for instance, equivalent phrases in other languages may be 30% longer (certain European languages, for instance) or 50% shorter (some Asian languages, for example.) This may alter screen layout and display requirements.
- Text direction may change. Whereas the direction of English is from left to right, other languages like Arabic and Hebrew are read from right to left.
Android Functionality To Help You
Android already has some built-in internationalization (“i18n” for short) features. The creation of a new Android project using Google’s Android SDK tools will trigger the generation of files needed for app localization. A /res/ directory is created at the top level of the project, containing default files such as res/values/strings.xml for storing string resources separately, instead of hardcoding them into your app. Eclipse, the integrated development environment (IDE) for Android, offers a function (under “Refactor”) to make it easier to move localization-dependent text into separate .xml files for app localization. Android also offers classes and methods to handle internationalization of quantities, dates, number, and so on.
Understanding And Handling Locales
Internationalization (“i18n”), the step before localization (“l10n”), uses three concepts: country, language, and locale. A locale, in its most general sense, represents a geographical, political, or cultural region. It can also be viewed as a combination of a country and a language. Thus, US English and UK English are two different locales. Although American and British people both speak English, some formats and vocabulary are locale-sensitive. That means that operations using the date, for example, must adapt to the locale of the user, as the American date format is month/day/year, but the British format is day/month/year. Other examples of locale-sensitive operations include number formatting: the English format differs from the French, which is in turn different from German, and so on.
Using Resources For App Localization
Resources to be localized include text strings, graphics and images, sounds, layouts, and any other static data used by your Android application. There may be multiple sets of resources, each one corresponding to a specific device configuration. In general, when an app runs, Android automatically loads the resources that best match the device. The same system is used for the locale of the device, which can be modified at any time by the user. Android then selects the most suitable resources for that locale.
The starting point for each app localization is to create specific directories within res/ for each locale (country-language combination) to be supported. For text string resources, the name of each directory uses the format “values-<ISO language code>”. So, for instance, res/values-fr/ contains the strings for French in the file at the location res/values-fr/strings.xml. Locale-specific versions of graphics and layout will then go into res/drawable-<qualifiers>/ and res/layout-<qualifiers>/ folders. To access locale-dependent resources from the Java code of your application you use a reference of the time “R.resource_type.resource_name” or “android.R.resource_type.resource_name”.
Defining Default Resources
The default locale version of app resources is what Android uses, when there is no other version of the app resources for the locale in question. By default, resources for an app exist within the “res/” directory for that application. Localized sets of resources (corresponding to other locales) are placed in other appropriately named subdirectories of the res/ directory (see above.) When a user running Android with a different locale loads your app, Android checks these subdirectories to see if there is one for that locale. If so, the content from that subdirectory will be displayed. Otherwise, Android will either try other related subdirectories or display the default content.
It makes sense to define the default language of your app to be the language you expect most of your application’s users to use. For example, if you are a developer in the US or working for a company in the US, the default language for your app may be US English. Besides storing default text (in the default language) in res/values/strings.xml, put any default text, drawables (graphics), layouts, and other resources into the default resource set as well, using the following subdirectories:
- res/drawable/ (required subdirectory, usually containing at least one graphic file for the icon for the application on Google Play)
- res/layout/ (required subdirectory, containing an XML file to define the default layout)
- res/anim/ (required if the app has any res/anim-<qualifiers> folders)
- res/xml/ (required if the app has any res/xml-<qualifiers> folders)
- res/raw/ (required if the app has any res/raw-<qualifiers> folders)
What Happens If Resource Files Are Incomplete?
If a user chooses a locale for which locale-specific resources are lacking in your app, Android will load the corresponding default resources: for example, the default strings from res/values/strings.xml. If the resource does not exist in a default version, the application will not run and the user will see an error.
Consider the following example. An application uses two text strings, A and B, that have been defined in English for a localized resource file, res/values-en/strings.xml. On the other hand, only text string A has been defined in the default resource file of res/values/strings.xml. If the application is launched on a device configured with its locale set to English, it should run correctly, because both text strings can be accessed. However, if the locale is changed to Spanish, the application will not load. After failing to find text string B in the default resource file, it will generate an error message and a Force Close button.
Check Resources For Completeness
The situation above applies to all resources, not just text strings. It is good practice, therefore, to check that a default resource is defined for each reference in an app to an Android resource. Localized resource string files could theoretically be incomplete, because the default value of a string would be available to prevent the app from displaying an error. However, partial app localizations often make for poor usability and bad impressions. Therefore, any localized resource files should be complete as well, or kept separately from the application until they can provide a completely localized user experience.
Look out for the follow up in Part 2.