Internationalization and localization

In computing, internationalization and localization (American) or internationalisation and localisation (Commonwealth), often abbreviated i18n and l10n respectively, are means of adapting to different languages, regional peculiarities and technical requirements of a target locale.

Internationalization is the process of designing a software application so that it can be adapted to various languages and regions without engineering changes. Localization is the process of adapting internationalized software for a specific region or language by translating text and adding locale-specific components.

Localization (which is potentially performed multiple times, for different locales) uses the infrastructure or flexibility provided by internationalization (which is ideally performed only once before localization, or as an integral part of ongoing development).

Naming

The terms are frequently abbreviated to the numeronyms i18n (where 18 stands for the number of letters between the first i and the last n in the word internationalization, a usage coined at Digital Equipment Corporation in the 1970s or 1980s) and l10n for localization, due to the length of the words. Some writers have the latter term capitalized (L10n) to help distinguish the two.

Some companies, like IBM and Oracle, use the term globalization, g11n, for the combination of internationalization and localization.

Microsoft defines internationalization as a combination of world-readiness and localization. World-readiness is a developer task, which enables a product to be used with multiple scripts and cultures (globalization) and separates user interface resources in a localizable format (localizability, abbreviated to L12y).

Hewlett-Packard and HP-UX created a system called "National Language Support" or "Native Language Support" (NLS) to produce localizable software.

Some vendors, including IBM use the term National Language Version (NLV) for localized versions of software products supporting only one specific locale. The term implies the existence of other alike NLV versions of the software for different markets; this terminology is not used where no internationalization and localization was undertaken and a software product only supports one language and locale in any version.

Scope

right|thumb|400px|The internationalization and localization process<br />(based on a chart from the [[Localization Industry Standards Association|LISA website)]]

According to Software without frontiers, the design aspects to consider when internationalizing a product are "data encoding, data and documentation, software construction, hardware device support, and user interaction"; while the key design areas to consider when making a fully internationalized product from scratch are "user interaction, algorithm design and data formats, software services, and documentation". Other grammar rules might also vary, e.g. genitive.

Different languages use different punctuation (e.g. quoting text using double-quotes (" ") as in English, or guillemets (« ») as in French)
Keyboard shortcuts can only make use of buttons on the keyboard layout which is being localized for. If a shortcut corresponds to a word in a particular language (e.g. Ctrl-s stands for "save" in English), it may need to be changed.

National conventions

Different countries have different economic conventions, including variations in:

Paper sizes
Broadcast television systems and popular storage media
Telephone number formats
Postal address formats, postal codes, and choice of delivery services
Currency (symbols, positions of currency markers, and reasonable amounts due to different inflation histories) – ISO 4217 codes are often used for internationalization
System of measurement
Battery sizes
Voltage and current standards

In particular, the United States and Europe differ in most of these cases. Other areas often follow one of these.

Specific third-party services, such as online maps, weather reports, or payment service providers, might not be available worldwide from the same carriers, or at all.

Time zones vary across the world, and this must be taken into account if a product originally only interacted with people in a single time zone. For internationalization, UTC is often used internally and then converted into a local time zone for display purposes.

Different countries have different legal requirements, meaning for example:

Regulatory compliance may require customization for a particular jurisdiction, or a change to the product as a whole, such as:
Privacy law compliance
Additional disclaimers on a website or packaging
Different consumer labelling requirements
Compliance with export restrictions and regulations on encryption
Compliance with an Internet censorship regime or subpoena procedures
Requirements for accessibility
Collecting different taxes, such as sales tax, value added tax, or customs duties
Sensitivity to different political issues, like geographical naming disputes and disputed borders shown on maps (e.g., India has proposed a bill that would make failing to show Kashmir and other areas as intended by the government a crime)
Government-assigned numbers have different formats (such as passports, Social Security Numbers and other national identification numbers)

Localization also may take into account differences in culture, such as:

Local holidays
Personal name and title conventions
Aesthetics
Comprehensibility and cultural appropriateness of images and color symbolism
Ethnicity, clothing, and socioeconomic status of people and architecture of locations pictured
Local customs and conventions, such as social taboos, popular local religions, or superstitions such as blood types in Japanese culture vs. astrological signs in other cultures

Business process for internationalizing software

To internationalize a product, it is important to look at a variety of markets that the product will foreseeably enter. A broader approach takes into account cultural factors regarding for example the adaptation of the business process logic or the inclusion of individual cultural (behavioral) aspects.

Already in the 1990s, companies such as Bull used machine translation (Systran) on a large scale, for all their translation activity: human translators handled pre-editing (making the input machine-readable) and post-editing. The GNOME project, for example, has volunteer translation teams for over 100 languages. MediaWiki supports over 500 languages, of which 100 are mostly complete .

When translating existing text to other languages, it is difficult to maintain the parallel versions of texts throughout the life of the product. For instance, if a message displayed to the user is modified, all of the translated versions must be changed.

Independent software vendor such as Microsoft may provides reference software localization guidelines for developers. The software localization language may be different from written language.

Commercial considerations

In a commercial setting, the benefit of localization is access to more markets. In the early 1980s, Lotus 1-2-3 took two years to separate program code and text and lost the market lead in Europe over Microsoft Multiplan. When Tandy Corporation needed French and German translations of English error messages for the TRS-80 Model 4, the company's Belgium office and five translators in the US produced six different versions that varied on the gender of computer components.

However, there are considerable costs involved, which go far beyond engineering. Further, business operations must adapt to manage the production, storage and distribution of multiple discrete localized products, which are often being sold in completely different currencies, regulatory environments and tax regimes.

Finally, sales, marketing and technical support must also facilitate their operations in the new languages, to support customers for the localized products. Particularly for relatively small language populations, it may never be economically viable to offer a localized product. Even where large language populations could justify localization for a given product, and a product's internal structure already permits localization, a given software developer or publisher may lack the size and sophistication to manage the ancillary functions associated with operating in multiple locales.

Examples and counterexamples

One example of the pitfalls of localization is the attempt made by Microsoft to keep some keyboard shortcuts significant in local languages. This has resulted some (but not all) programs in the Italian version of Microsoft Office using "CTRL + S" (sottolineato) as a replacement for "CTRL + U" (underline), rather than the (almost) universal "Save" function. Before the advent of 'AutoSave', the net result could be a lot of underlined words in an unsaved revision of the document.

The team responsible Microsoft Excel localization decided to translate the tokens used in formulas, as a byproduct of localizing number and date formats. For example, =SUM(A1:A10) becomes =SOMME(A1:A10) in French or =SUMME(A1:A10) in German.

While making the formulas easier to understand for users with no knowledge of the English language, it has also meant that, before machine translation of web pages, a search for help on the internet could not count on examples from other languages. Manuals and tutorials required translations of every formula in examples and exercises.

References

External links

Localization vs. Internationalization by The World Wide Web Consortium