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 take a moment to clarify some terms. While you likely know what we mean by language, you may not be aware that each language may have a number of different locales. For example, the Spanish spoken in Spain is quite different from that spoken in the Americas, the French spoken in Canada differs from that of 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 (see Figure 19.1).


People who speak the same language often have localized dialects.


People who speak the same language often have localized dialects.

Applications are made up of data and functions (behavior). For most applications, the behavior 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.

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 would need 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 string information into an application (that is, the Java source file) unless absolutely necessary. Doing so hinders internationalization efforts.

Was this article helpful?

0 0

Post a comment