HOW TO SUPPORT MULTIPLE LANGUAGES ON ANDROID
This article provides basic guidance to help you plan and implement multiple language support in your Android apps.
Android has excellent features that make implementing and managing multiple languages easy, and you should take full advantage of that in your apps.
Android has excellent features that make implementing and managing multiple languages easy, and you should take full advantage of that in your apps.
Supporting multiple languages is the most important aspect of localisation.
Localisation and language support:
Localisation refers to the adaptations required in an app's user interface to support users in different geographies—referred to as locales.
Locale support includes
■ Supporting multiple user languages, including different character sets (accented
characters, special symbols, punctuation)
■ Presentation differences like number seperators and date and time formats
■ Address formats, sorting orders, and time zone and calendar differences
Multiple language support is therefore not the whole story of localisation, but it is an essential first step. Depending on what functionality your app offers, it may be enough. Also, multiple language support depends only on Android features, whereas other aspects of localisation (formats and sorting orders for example) depend on Java language mechanisms.
From a developer perspective, the essential requirement for implementing multiple language support is to provide translations into the languages you intend to support for all strings that your app will display to users.
Why bother with translation?
Some developers take the view that "most" users are "tolerant" of English-only apps.
However, an English-only app does not meet the quality level required for submission app stores in non-English speaking European countries.
Supporting multiple languages is therefore a prerequisite for increasing the number of potential users your app can reach.
Android support for multiple languages:
Android adopts a resource-driven approach to presenting locale-specific app content. To support multiple languages, developers supply language-specific resource files containing translated strings as part of their app source code. At build time, the Android build system generates compact binary representations of all string resources, which are packaged into the final app package.
Android takes care of switching-in the appropriate language strings based on the user's settings.
The essential developer tasks are therefore to:
■ Provide translations for all strings, or subsets of them, that the app presents to users
■ Make the translations available in language-specific resource files at build time
■ Ensure that default resource files are provided in case the user language is not one of
the languages you support.
In Android terminology, the process of separating resources from code and supplying them to the build system in resource files is referred to as "externalization".
As a general rule, you should always take advantage of Android's externalisation facilities, and never hardcode strings (that will be displayed to the user), images (that you may use as backgrounds for UI elements), icons (that launch app functions), or even sounds (for example alerts). Instead, follow Android's resource model.
Supporting multiple languages:
It's important that you serve all of your users, not just those in the biggest markets.
The following tips will help you plan and implement multiple-language support in your Android apps.
Tips 1—String file locations for Vodafone European countries
Use the table below to help manage string resources for multiple languages. Currently, the UK and Germany are the most active markets. Therefore, unless your app really is local to a single country (see Tip 10), you should aim to support at least UK English and German languages, in addition to your own language if different. You should also consider adding more languages in future app upgrades.
You must always support a default language by including a default strings file res/values/strings.xml,see Tip 2
Tips 2—Provide a default string file (and test your default support)
When your app runs on a phone set to a language that you do not explicitly support, Android will use the default strings file (and any other default resources) to display user visible strings.
Similarly, any strings required for display that are not defined in a language-specific strings file will be displayed from the default strings file.
If you don't provide a default strings file, and the phone is set to a language you don't support, your app won't launch (or will be shut down if already running).
The same thing will happen if you omit any string that is required for display from the default strings file.
Always test your app in the default language to ensure that it runs correctly without language-specific resources.
Tips 3—Understand resource switching and locations
Language strings are supplied in a strings.xml file (see Tip 1 for naming details). The default strings.xml is always located in the res/values folder. Translated strings should be supplied in a strings.xml file located in a language specific res/values-<LANGUAGE CODE> folder, one folder (and one strings.xml file) for each language you support.
Android language switching is based on the phone language the user sets from the Settings menu. Note that the languages available depend not just on the Android version, but also on the phone model, and the manufacturer's provision for the local market too.
Tips 4—Be prepared for runtime language changes
If the user changes the phone's language setting while your app is running, the following happens:
■ onDestroy() is called for your currently running Activity
■ onCreate() is called for your currently running Activity
In other words, your Activity is stopped and restarted.
Android calls onSaveInstanceState() to save your Activity's state before onDestroy() is called. This enables you to restore state when your Activity restarts. Your onCreate() method should therefore call onRestoreInstanceState() to restore the app state. This enables you to handle the restart seamlessly.
Tips 5—Useful common accents and special characters
The most obvious written differences between European languages are accents and other special characters. To display translated strings correctly, you must create them correctly in your resource code. Even the list of localisable European languages presents this basic problem, for example:
■ Spanish is written Español, and includes a tilde accent
■ Portuguese is written Português and includes a circumflex accent
Special characters include:
■ Speech-, exclamation-,and question-marks used in Spanish, respectively « and », ¡ and ¿
■ German ligatures including ß (not to be confused with Greek lower-case beta β)
■ The ª and º superscripts used in Italian, Portuguese, and Spanish for ordinal numbers
The HTML5 character reference table provides a convenient list of all the special characters you are likely to need in European language strings.
It is not necessary to generate these characters from the keyboard; use Unicode or HTML encodings directly in your string resources (see Tip 6).
Tips 6—Use HTML encoding to include styles and special characters (like accents) in your Android strings
The HTML5 table lists the Unicode codepoint for each named character entity.
For example, Caffè in Italian requires a grave accent above the "e", Unicode codepoint U+000E8.
You can use the codepoint to create a Java literal \u00e8 (4 digit hexadecimal number); or you can use the HTML character entity in decimal format è (232 is the decimal conversion of hexadecimal E8).
Note that you cannot use the HTML named character entity è (the Android resource compiler rejects it).
For example, the following string defined in strings.xml:
<string name="caffe">Did you say <b>Caffè</b>, or was that <i>Caff\u00e8</i>?</string>
builds and displays as:
Note also the use of HTML markup in the strings file for simple styling—see Find out more, below.
Tips 7—Rewrite strings to make translation easier
Translation can cause unexpected effects. A common problem is that string length for equivalent text varies significantly between languages, which can upset your layout.
Another is that some phrases just do not translate easily. Keep your language style simple. If a phrase is awkward in translation, try rewriting it in your own language to avoid the awkwardness.
Also, although it's not specifically a translation issue, avoid quantity formulations in your displayed text if you can. For example, "You have 1 new messages" will always read badly; but "You have new messages" reads well, even when there is only one message.
Tips 8—Swap translation tasks with others
Most developers won't have the language expertise required for translation, and many won't have the budget to buy in expertise.
Help yourself and others by harnessing the power of the Android developer community to swap translation tasks with developers in the countries you are targetting. Post in your favourite Android developer forums.
Tips 9—Think globally—even the most local apps can have wider appeal
Dutch users are probably are not interested in UK lottery results, but they may be interested in London Tube information, Spanish football results, Italian Slow Food events, and so on.
So even if your app depends on specific local content, it may still appeal to users in other countries.
Think globally, and your app may have a bigger market than you realised.
Find Out ....
Localisation and language support:
Localisation refers to the adaptations required in an app's user interface to support users in different geographies—referred to as locales.
Locale support includes
■ Supporting multiple user languages, including different character sets (accented
characters, special symbols, punctuation)
■ Presentation differences like number seperators and date and time formats
■ Address formats, sorting orders, and time zone and calendar differences
Multiple language support is therefore not the whole story of localisation, but it is an essential first step. Depending on what functionality your app offers, it may be enough. Also, multiple language support depends only on Android features, whereas other aspects of localisation (formats and sorting orders for example) depend on Java language mechanisms.
From a developer perspective, the essential requirement for implementing multiple language support is to provide translations into the languages you intend to support for all strings that your app will display to users.
Why bother with translation?
Some developers take the view that "most" users are "tolerant" of English-only apps.
However, an English-only app does not meet the quality level required for submission app stores in non-English speaking European countries.
Supporting multiple languages is therefore a prerequisite for increasing the number of potential users your app can reach.
Android support for multiple languages:
Android adopts a resource-driven approach to presenting locale-specific app content. To support multiple languages, developers supply language-specific resource files containing translated strings as part of their app source code. At build time, the Android build system generates compact binary representations of all string resources, which are packaged into the final app package.
Android takes care of switching-in the appropriate language strings based on the user's settings.
The essential developer tasks are therefore to:
■ Provide translations for all strings, or subsets of them, that the app presents to users
■ Make the translations available in language-specific resource files at build time
■ Ensure that default resource files are provided in case the user language is not one of
the languages you support.
In Android terminology, the process of separating resources from code and supplying them to the build system in resource files is referred to as "externalization".
As a general rule, you should always take advantage of Android's externalisation facilities, and never hardcode strings (that will be displayed to the user), images (that you may use as backgrounds for UI elements), icons (that launch app functions), or even sounds (for example alerts). Instead, follow Android's resource model.
Supporting multiple languages:
It's important that you serve all of your users, not just those in the biggest markets.
The following tips will help you plan and implement multiple-language support in your Android apps.
Tips 1—String file locations for Vodafone European countries
Use the table below to help manage string resources for multiple languages. Currently, the UK and Germany are the most active markets. Therefore, unless your app really is local to a single country (see Tip 10), you should aim to support at least UK English and German languages, in addition to your own language if different. You should also consider adding more languages in future app upgrades.
You must always support a default language by including a default strings file res/values/strings.xml,see Tip 2
| Market | Region Code | Language | Region code | String file | Android Version |
| United Kingdom | UK | English | en_rGB | res/values/strings.xml | Since 1.5 |
| Eire(Republic of Ireland) | IE | English | en_rIE | res/values-ie/strings.xml | Since 2.3 |
| Germany | DE | German | de_rDE | res/values-de/strings.xml | Since 1.1 |
| Greece | GR | Greek | ei_rGR | res/values-el/strings.xml | Since 2.3 |
| Italy | IT | Italian | it_rIT | res/values-it/strings.xml | Since 1.5 |
| Netherlands | NL | Dutch | nl_rNL | res/values-nl/strings.xml | Since 1.5 |
| Portugal | PT | Portuguese | pt_rPT | res/values-pt/strings.xml | Since 2.3 |
| Spanish | ES | Spanish | es_rES | res/values-es/strings.xml | Since 1.5 |
Tips 2—Provide a default string file (and test your default support)
When your app runs on a phone set to a language that you do not explicitly support, Android will use the default strings file (and any other default resources) to display user visible strings.
Similarly, any strings required for display that are not defined in a language-specific strings file will be displayed from the default strings file.
If you don't provide a default strings file, and the phone is set to a language you don't support, your app won't launch (or will be shut down if already running).
The same thing will happen if you omit any string that is required for display from the default strings file.
Always test your app in the default language to ensure that it runs correctly without language-specific resources.
Tips 3—Understand resource switching and locations
Language strings are supplied in a strings.xml file (see Tip 1 for naming details). The default strings.xml is always located in the res/values folder. Translated strings should be supplied in a strings.xml file located in a language specific res/values-<LANGUAGE CODE> folder, one folder (and one strings.xml file) for each language you support.
Android language switching is based on the phone language the user sets from the Settings menu. Note that the languages available depend not just on the Android version, but also on the phone model, and the manufacturer's provision for the local market too.
Tips 4—Be prepared for runtime language changes
If the user changes the phone's language setting while your app is running, the following happens:
■ onDestroy() is called for your currently running Activity
■ onCreate() is called for your currently running Activity
In other words, your Activity is stopped and restarted.
Android calls onSaveInstanceState() to save your Activity's state before onDestroy() is called. This enables you to restore state when your Activity restarts. Your onCreate() method should therefore call onRestoreInstanceState() to restore the app state. This enables you to handle the restart seamlessly.
Tips 5—Useful common accents and special characters
The most obvious written differences between European languages are accents and other special characters. To display translated strings correctly, you must create them correctly in your resource code. Even the list of localisable European languages presents this basic problem, for example:
■ Spanish is written Español, and includes a tilde accent
■ Portuguese is written Português and includes a circumflex accent
Special characters include:
■ Speech-, exclamation-,and question-marks used in Spanish, respectively « and », ¡ and ¿
■ German ligatures including ß (not to be confused with Greek lower-case beta β)
■ The ª and º superscripts used in Italian, Portuguese, and Spanish for ordinal numbers
The HTML5 character reference table provides a convenient list of all the special characters you are likely to need in European language strings.
It is not necessary to generate these characters from the keyboard; use Unicode or HTML encodings directly in your string resources (see Tip 6).
Tips 6—Use HTML encoding to include styles and special characters (like accents) in your Android strings
The HTML5 table lists the Unicode codepoint for each named character entity.
For example, Caffè in Italian requires a grave accent above the "e", Unicode codepoint U+000E8.
You can use the codepoint to create a Java literal \u00e8 (4 digit hexadecimal number); or you can use the HTML character entity in decimal format è (232 is the decimal conversion of hexadecimal E8).
Note that you cannot use the HTML named character entity è (the Android resource compiler rejects it).
For example, the following string defined in strings.xml:
<string name="caffe">Did you say <b>Caffè</b>, or was that <i>Caff\u00e8</i>?</string>
builds and displays as:
Note also the use of HTML markup in the strings file for simple styling—see Find out more, below.
Tips 7—Rewrite strings to make translation easier
Translation can cause unexpected effects. A common problem is that string length for equivalent text varies significantly between languages, which can upset your layout.
Another is that some phrases just do not translate easily. Keep your language style simple. If a phrase is awkward in translation, try rewriting it in your own language to avoid the awkwardness.
Also, although it's not specifically a translation issue, avoid quantity formulations in your displayed text if you can. For example, "You have 1 new messages" will always read badly; but "You have new messages" reads well, even when there is only one message.
Tips 8—Swap translation tasks with others
Most developers won't have the language expertise required for translation, and many won't have the budget to buy in expertise.
Help yourself and others by harnessing the power of the Android developer community to swap translation tasks with developers in the countries you are targetting. Post in your favourite Android developer forums.
Tips 9—Think globally—even the most local apps can have wider appeal
Dutch users are probably are not interested in UK lottery results, but they may be interested in London Tube information, Spanish football results, Italian Slow Food events, and so on.
So even if your app depends on specific local content, it may still appeal to users in other countries.
Think globally, and your app may have a bigger market than you realised.
Find Out ....
Category: Android, Android tips Text, Apk
0 comments