W3C home > Mailing lists > Public > public-i18n-core@w3.org > July to September 2005

definition of i18n

From: Addison Phillips <addison.phillips@quest.com>
Date: Tue, 27 Sep 2005 11:03:07 -0700
Message-ID: <FA13712B13469646A618BC95F7E1BA8F0E249D@alvmbxw01.prod.quest.corp>
To: "Richard Ishida" <ishida@w3.org>
Cc: <public-i18n-core@w3.org>, "GEO" <public-i18n-geo@w3.org>
Hi Richard,

I thought about this a lot more (while in the shower, actually) and thought I could contribute some text to help. Herewith my suggestions as a complete article. As I said before, you are free to steal from this as appropriate or ignore it if you feel that it is not useful:

Definitions of internationalization vary. This is a high-level working definition for use with W3C Internationalization Activity material. Some people use other terms, such as 'globalization' to refer to the same concept.  

Internationalization is the design and development of a product, application or document content that is *enabled* to handle the needs of different target audiences that vary in culture, region, or language. Internationalization allows the same software or content to be deployed without modification into any of these environments. 

Ideally, internationalization is a fundamental part of the architectural approach to design and development, rather than a possibly awkward and expensive afterthought.

Internationalization is sometimes written as 'i18n', where 18 is the number of letters between the "i" and the "n" in the English word.

Internationalization typically entails:

   * Enabling the use of Unicode or ensuring the proper handling of legacy character encodings where appropriate, in order to ensure that textual content in other languages or scripts can be supported, processed and exchanged reliably.

   * Planning for international support at design time. This may include providing support for features that support international usage before they are needed. For example, adding support in your DTD for markup to support bidirectional text or for identifying language in certain elements. 

   * Enabling code to support local, regional, language, or culturally related preferences. Normally this includes providing support for the incorporation of predefined localization data and features derived from existing libraries or user preferences. Some examples of this include:
      - date and time formats
      - local calendars
      - number formats
      - sorting and presentation of lists
      - handling of personal names and forms of address
      - and many other things...

   * Separating localizable elements from source code or content, such that localized alternatives can be loaded or selected based on the user's international preferences as needed.

Notice that these items do not necessarily include the localization of the content, application, or product into another language; they are design and development practices which allow such a migration to take place easily in the future but which may have significant utility even if no localization ever takes place.

Internationalization significantly affects the ease of the product's localization. Retrofitting a linguistically- and culturally-centered deliverable for a global market is obviously much more difficult and time-consuming than designing a deliverable with the intent of presenting it globally. (Think back to the Y2K effort and trying to "undo" two-character year fields that were built on the assumption of "19xx").


Addison P. Phillips
Globalization Architect, Quest Software

Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

Received on Tuesday, 27 September 2005 18:03:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:23:00 UTC