RE: Definition of i18n

Chair hat on:

I've put this on our agenda for this week.

Chair hat off:

Generally speaking, the definition below is fine, but I really dislike a number of things about the text. My personal comments interlinearly below.


Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> 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.
[Addison Phillips] 

If you don't define 'globalization' you should lose all mention of it. I don't believe anyone actually uses 'globalization' to mean internationalization by itself, as implied here, and a crisp definition of it is key to using it effectively.
> Internationalization (often written as "i18n", where 18 is the number of
> letters between 'i' and 'n')
[Addison Phillips] 

The number of letters between the 'I' and the 'n' in English. I don't care for 'i18n' very much and would like it to be deemphasized as much as possible. I can't tell you how many times I get people sending me messages about various letter-number combinations: just this morning I got "l13n" in an email from a colleague. Put it as an aside; our weird jargon is off-putting and distracting from the main message.

 is the design and development of a product,
> application or document content that is *enabled* for multinational, and
> possibly multilingual, deployment.
[Addison Phillips] 

This implies the wrong things, I think. "Multinational deployment" suggests that a product is capable of supporting more than one locale at a time. While this is eminently desirable, single-language-at-a-time enabling is perfectly valid.
> Internationalization typically entails:
>    * Providing support for features that may not be used until
> localization occurs (e.g., markup to support bidirectional text in DTDs).
[Addison Phillips] 

I would move this down. It is really a Web-centric version of the more general need to prepare content for localization: don't concat strings; use substitution variables; don't make inter-string dependencies; don't depend in code on specific string values; etc. 

While in GEO this definition might need to "ride high", in a more general definition it is misplaced, I think.

I also dislike the gerund form of these bullets. Very difficult to read.
>    * 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).
[Addison Phillips] 

Ick. I really dislike this bullet and "localization data" is the wrong phrase altogether. Might I suggest:

Provide support for different cultural or language related preferences. These features are often derived from existing libraries or system capabilities and may need to interact with a user's particular preferences. Some of the many culturally affected aspects of a system include:

 - date and time formats
 - number formats
 - the decimal and grouping separator in numbers
 - presentation and ordering of lists or collections
 - quote marks and other linguistically derived presentations
 - forms of personal address
 - and much more...
>    * 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.
[Addison Phillips] 

This is mostly fine. A link to "localization" goes here, of course.
> The success of the i18n process will significantly affect the ease of the[Addison Phillips] 
[Addison Phillips] 

Even if you define i18n, do not use it in text. You will note that the Internationalization Core WG is stamping it out slowly in its materials. And don't get me started on the capitalization thing.

> 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.
[Addison Phillips] 

Uh... "Internationalization is an architecture. It is not a feature." It is also not a "step" :-). 

Thus "... internationalization is a fundamental part of the design and development process, rather than a possibly awkward and expensive afterthought."

Received on Monday, 19 September 2005 16:44:18 UTC