Re: Definition of i18n

The Localization definition looks pretty good.

One issue: it's ok to define i18n and l10n in case people run across it. 
But these oh-so-geeky terms should be otherwise avoided in text.


 >is *enabled* for
 > multinational, and possibly multilingual, deployment.

This is not specific enough. In some sense *all* programs are enabled; 
there are changes you can make to any program to "deploy" it 
"multinationally". And the 'deployment' as a term doesn't really work; 
you want to tie it to the definition of localization, where you can 
define what it means.

We find it much easier to define the adverb first, instead of the noun. 
The definitions we use are the following (adapted to use more of your 

1. A localized product is one that is adapted to meet the language, 
cultural and other requirements of a specific target market (a "locale").

2. An internationalized software product is one that can be localized to 
any single locale without code changes.

3. A globalized software product is one that is internationalized, and 
also supports multiple data locales at runtime. It may also support a 
runtime choice among UI locales.

[One thing that is very important to make clear is the distinction 
between a program that can handle localized *data* vs one that *is 
translated* -- that is, has a localized UI. Many people mix these up, 
and they have different implications. A key goal is to globalize all 
programs for data; that is, they can handle any data, and get the right 
number formats, etc. But they do not necessarily have translated UI, and 
the translations may be follow-ons.]

Richard Ishida wrote:
> Folks,
> The ITS WG would like to include definitions of
> "internationalization" and "localization" in the document
> "Internationalization and Localization Markup Requirements"
>  (The group was surprised that the I18N
> Activity didn't already have something at least for
> "internationalization").
> You may remember that some time ago the GEO WG did some work on
> defining i18n, l10n and g11n. The definition for l10n seemed to be
> ok, but there were some comments on the i18n definition, and a lot of
> different opinions on the g11n definition.
> I suggest we adopt the l10n definition, and revisit the i18n
> definition and agreed on something that can be used as a working
> defintion for the Activity as a whole.  I suggest we abandon the
> attempt to define g11n, and leave people to work that out for
> themselves.
> The short definitions used so far by the ITS-WG are close to the
> drafts worked out by the GEO-WG. So the ITS group is happy to start
> from GEO's definitions. I have however made some modifications based
> on comments made last October and by Yves Savourel. ITS and GEO
> therefore believe we already have a pretty useful definition at this
> point.
> So, see below a proposed wording for "internationalization". Note
> that ITS may not need the last two paragraphs.
> When commenting on this definition, please consider that we need to
> reach a consensus, and that will involve some compromise.  We have
> tried to review and synthesise a large number of definitions.
> (Please do not simply say "I prefer this other definition over
> here".)
> Note that this is a full version that would be useful for GEO
> "Getting Started" materials, but the ITS folks may well omit the last
> two paragraphs.
> Cheers, RI
> ============================================
> Internationalization:
> Definitions of internationalization vary, and some people refer to
> this concept as 'globalization' or using other terms.  We provide
> here a high-level working definition for use with W3C
> Internationalization Activity material.
> Internationalization (often written as "i18n", where 18 is the number
> of letters between 'i' and 'n') is the design and development of a
> product, application or document content that is *enabled* for
> multinational, and possibly multilingual, deployment.
> Internationalization typically entails:
> * Providing support for features that may not be used until
> localization occurs (e.g., markup to support bidirectional text in
> DTDs).
> * Providing support for the incorporation of predefined localization
> data and features derived from existing libraries or user preferences
> (e.g., date and time formats; keyboard usage).
> * 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.
> The success of the i18n process will significantly affect 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").
> So ideally, internationalization occurs as a fundamental step in the
> design and development process, rather than as a possibly awkward and
> expensive afterthought.
> ============ Richard Ishida W3C
> contact info:
> W3C Internationalization:
> Publication blog:

Received on Monday, 19 September 2005 22:38:26 UTC