Categories: Symbian C++ | How To | Development Process | Localization | Code Examples

This page was last modified 13:08, 24 June 2008.

From Forum Nokia Wiki

Definition

Internationalization (I18N) is proactive development methodology that aims to minimize the effort required to redeploy software in different languages. The process of reworking software for different languages is known as Localization (L10N). Internationalization requires careful consideration of several design issues from the outset.

Guidelines for developers

The goal of Internationalization is to make it easy for your application to transcend not languages exactly, but locales.A locale is composed of a base language, but it encompasses more than just this. To clarify this concept, consider that the United States (US) and the United Kingdom (UK) use different locales (en_US and en_UK, respectively). Though they share English as their base language, there are still differences in the way that they represent certain information. For example, the US uses the "$" (dollar) currency symbol and the UK uses "£" (pound). Also, date formatting is different for each (typically DD/MM/YYYY for the UK and MM/DD/YYYY for the US). Locales, therefore, encompass not just language, but all regional data-representation conventions.

You must take several things into consideration when creating applications that can be localized efficiently. The three basic things to consider are:

• Be sensitive to all data whose representation is locale specific. This includes various conventions such as date and time, monetary and decimal formatting and so on.
• Understand the concept of a locale, and what this means in S60.
• Understand how applications use resource files.
• Understand how to prepare resources for easy translation.

All data that is not globally recognizable (in other words, data whose formatting is locale specific) needs to be considered from the start, and treated differently. Examples of data that will be different according to the locale are dates, times, currency and, of course, all user-visible text. Perhaps less apparent is the fact that sounds, images and filenames may also need to be locale-specific.

The proper way to treat locale-specific data is to use the special classes offered by the Locale Settings API. These classes represent data according to the locale that is loaded on the given device. So, these special classes work with the application framework in order to deliver output that is correct for a given locale.

Examples

• TLocale

• TLanguage

• tday, TDateName and tdayNameAbb

• TMonth, TMonthName and TMonthNameAbb

• TDateSuffix

• TAmPmName

• TCurrencySymbol

Developers must keep in mind that all user-visible text and locale-specific data will change, once localized—the obvious consequences are that text may take up more (or less) space in some languages than others, and consequently more (or less) memory. This means that users should avoid fixed-size text buffers. Wherever possible, dynamic buffers should be used instead.

The following excerpt demonstrates two ways to create dynamically allocated text buffers, with both methods passing ownership out and leaving the created buffer on the Cleanup Stack:

HBufC* message = StringLoader::LoadLC(R_DIALOG_TEXT);

HBufC* msg1 = iEikonEnv->AllocReadResourceLC(R_MY_TEXT_01);

These functions both dynamically load in a string from a resource, without having to specify the size of the HBufC in the code. CCoeEnv::AllocReadResourceLC() is the traditional Symbian OS method for achieving this and will be commonly seen in old code. The StringLoader class is new to S60 but provides a more flexible API for formatting strings as they are read in.

OS support for localization

The most important aspect of internationalization is to understand that an application's resource files are not loaded until runtime. Furthermore, the framework provides a special nomenclature for resource files—it allows multiple resource files, each localized for a particular language, for any given application. The name of each compiled resource file, such as *.r01, *.r02, *.r03 and so on, indicates to the framework the locale that each file represents. For example, English is 01, French is 02 and so on. When the application is loaded, the framework can then, depending on the device's locale, load the appropriate one.

The typical way to build applications so that they have locale-independent .rss files is to refrain from hard-coding any text strings in the .rss file itself. Instead, the .rss file should include a .loc file. This .loc file then acts as a large switch:

#ifdef LANGUAGE_01
 
#include "Language.l01"
 
#endif
 
#ifdef LANGUAGE_02
 
#include "Language.l02"
 
#endif
 
#ifdef LANGUAGE_03
 
#include "Language.l03"
 
#endif
 
#ifdef LANGUAGE_06
 
#include "Language.l06"
 
#endif

Each individual .loc (*.l01, *.l02 and so on) file then contains all the text strings for each locale. Within the project's .mmp file, you can specify all of the locales for which you want to compile the application using the LANG keyword.