Once upon a time, in the dim, primordial past of software development, a lot of software could only "speak" one human language at a time. Each country or region needed it's own version. In some cases, internationally relevant features were retrofitted onto the shipping English language product. In other cases, the English and international versions might be completely separate products, perhaps sharing some basic code but often sharing little more than the product's name. This was particularly the case with Asian versions of a product developed in North America or Europe. In either case, whether making such changes retroactively to a shipping product or developing parallel versions, the result was usually a lengthy, expensive product cycle.

Even if a piece of software was functionally suitable for use in more than one country, producing an appropriate language version of that product was difficult. This is because the menus, dialog boxes and messages which make up that product's user interface (UI) were often written directly in the program source code (using printf type constructs). Successfully translating source files can be quite difficult, expensive and time-consuming for a number of reasons. It requires a combination of linguistic and engineering knowledge that not commonly available; mistakes are easy to make; and the translated code often does not function as expected, because its authors made assumptions about things like the language of the UI, the length or position of English words (which change when translated to other languages), etc.

This is bad.

Luckily, more and more software developers have realized that if they design their products from the beginning to understand the requirements of multi-locale computing, these products will reach global markets sooner, for less expense, and probably be much more successful than products designed the "bad old fashioned way." Such multi-locale products can be called "globally enabled". Globally enabled software is software that supports a wide range of languages, human cultural conventions, fonts, encodings and other features that make it useful, not just in one country or region, but around the world. Additionally, the user interface for globally enabled products is separate from the core instruction code, allowing the software to be translated without requiring recompilation. Since globally enabled software doesn't make assumptions about language of the user interface, the translated programs are more robust, requiring less "fixing" or special enhancements to support individual languages. This speeds the release of translated programs.

This is good.

The Mozilla family (Navigator and Communicator) is (and must remain) globally enabled. The core Mozilla binary executable for each platform supports computing in North American English, Western European, Central European, Chinese, Japanese and Korean locales. The user interface is contained in resource files and is, for the most part, completely separate from the core binary. Having the UI disconnected from the core code means you do not need a Japanese language version of Mozilla to browse Japanese web pages. You can use an English, a French or whatever version of Mozilla for Japanese browsing and vice versa (with the appropriate fonts and set-up, of course).

This is very good.

The remainder of this document is intended to convey enough information so that you can continue to make Mozilla a globally enabled software project. Future Mozilla products must at the very least continue to support the level of internationalization we have today. As we move forward, we want to extend Mozilla to support more and more languages, encodings and other globally relevant feature sets.

This will be really, totally good.

Definitions

Before proceeding, let's establish some definitions of the major terms and concepts used herein:

Internationalization (a.k.a. Globalization, a.k.a. Enabling)	Designing and developing a software product to function in multiple locales. This process involves identifying the locales that must be supported, designing features which support those locales, and writing code that functions equally well in any of the supported locales.
Localization	Modifying or adapting a software product to fit the requirements of a particular locale. This process includes (but may not be limited to) translating the user interface, documentation and packaging, changing dialog box geometries, customizing features (if necessary), and testing the translated product to ensure that it still works (at least as well as the original).
Localizability	The degree to which a software product can be localized. Localizable products separate data from code, correctly display the target language and function properly after being localized.
i18n	Acronym for "internationalization" ("i" + 18 letters + "n"; lower case i is used to distinguish it from the numeral 1 (one)).
L10n	Acronym for "localization" ("L" + 10 letters + "n"; upper case L is used to distinguish it from the numeral 1 (one)).
L12y	Acronym for "localizability" ("L" + 12 letters + "y"; upper case L is used to distinguish it from the numeral 1 (one)).
Locale	A set of conventions affected or determined by human language and customs, as defined within a particular geo-political region. These conventions include (but are not necessarily limited to) the written language, formats for dates, numbers and currency, sorting orders, etc.
Resource	1. Any part of a program which can appear to the user or be changed or configured by the user. 2. Any piece of the program's data, as opposed to it's code.
Core product	The language independent portion of a software product (as distinct from any particular localized version of that product - including the English language version). Sometimes, however, this term is used to refer to the English product as opposed to other localizations.

Justifications (or "Why Should I Care?")

The Internet is arguably the single biggest revolution in human communications since some forgotten caveman learned to signal the rest of the tribe by beating on a hollow log. This is a global medium with the power to connect the world's disparate peoples, but only if the delivery mechanism can adequately handle the confusing Babel that is the hodgepodge of languages, encodings and local expectations that make up our different cultures. The problems associated with trying to re-engineer mono-lingual products to support different locales was discussed in the opening section of this document. Properly enabled software is the answer here, not a barrage of unique, mono-lingual applications.

If your application is truly only relevant to a limited audience, defined by language or locale, then you probably don't need to care about internationalization or localization issues. However, if your application could be useful regardless of where in the world it is used, or your target users span multiple countries, regions or languages, why make it more difficult to reach them? By following these guidelines it will be much easier to release a successful product worldwide.

If shortcuts are taken and/or mistakes made during the core product's development, it can be time-consuming and expensive to correct these during the localization process. Such delays and expenses eat into the profits from localized releases (both monetarily and in terms of lost opportunities). Properly enabled products can help turn localization from a chaotic and expensive game of "catch up" into a smooth, well-oiled machine.

The justification for presenting these guidelines, then, is to create an environment where internationally enabled, fully localizable products can be released as smoothly and quickly as possible. As you work on your various projects, please keep the following two catchy phrases in mind:

One code base for the world
English is just another language

Mozilla Internationalization & Localization Guidelines

Contents

Overview of Internationalization & Localization

Definitions

Justifications (or "Why Should I Care?")