The localization pack used during application execution is defined by a locale. In practice, a locale is more granular than a simple language specification, and is often defined by three components: a language, a country/region, and an optional variant. This level of granularity is needed because a localization pack can contain more than just translations. For example, Australia and the United Kingdom both use English, but they have different currency symbols. There can also be differences in the texts themselves among countries using the same language (e.g. 'center' in the US vs 'centre' in the UK). Most systems use the ISO 639 two-letter code for language and the ISO 3166 two-letter code for country/region. For example, en-US would represent English in the United States and zh-CN would represent Chinese in Chin). Adopting such a standard within a company will enable applications developed in different parts of the company to share the same locale definition.
A simple implementation of localization packs will have one localization pack per locale. But in some cases the data differences between two locales are relatively small. Keeping separate locale packs for each locale will result in duplications and make it more complicated to maintain. Furthermore, there needs to be a fallback mechanism so that when a locale is not available, the user will be presented with the 'best-fit' locale rather than an error. For example, a user requesting French for Canada may be presented with French for France if Canadian French is not available; or a request for Amharic might be presented with English information. Such behaviors can be implemented by adopting a hierarchical locale model so that only the differences need to be stored, and there is a series of fallbacks. The diagram below is a schematic representation of such a hierarchy:
Figure 2
In this example, a menu item has the value 'colour.' The Root Locale means that this value will be used if a localization pack cannot be found for the locale specified. This value will also be used for all en (English) locales (e.g. Australia, New Zealand, Singapore, etc) except for U.S. where it will be spelled as 'color.' The value is translated to 'couleur' for French locales, and so forth. This way, when a user requests en-US, the word 'color' will be presented. A request for en-SG will not find a localization pack for that locale but will use 'colour' in the en locale instead. Though the Root Locale in this example uses English, it could use any language.
To ensure consistency across applications and to reduce development and translation costs, standards should be adopted for storing locale data, for managing terminology, and for the use of translation memory. |
