RE: definition of i18n

> From: Addison Phillips [mailto:addison.phillips@quest.com] 
> Sent: 27 September 2005 19:03
...
> 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. 

Hmm. I know what you mean, but I'm not sure you said it. This is very difficult to express, though.  The way you have written it, I can imagine an uninitiated person thinking to themselves, "Oh, like translation.  That's enabling my product to handle the needs of different target audiences."

> Internationalization allows the 
> same software or content to be deployed without modification 
> into any of these environments. 

That's not always true.  You may need to adapt local, regional, etc preferences, as you mention below.  Your text suggests the 'vanilla' product approach to the neophyte.

How about just this:

Internationalization is the design and development of a product, application or document content that *enables* easy localization for target audiences that vary in culture, region, or language. 


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

Yves wanted to omit this from his use of the definition, which is why we had moved it lower down in my version.  He sees this more as an exhortation than part of the definition. I'm inclined to agree and leave near the end.  I think we've already said that it's a fundamental part of the architectural approach.


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

I propose to restore s/sometimes/often/.  I know you dislike this, but it really is often used.


> 
> 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.

I agree that we should add this in the first bullet point, but encodings are only one example of a particular approach, as you mentioned in your previous note, that includes things like avoiding incorrect use of composite strings.  I'm also going to try to summarise each bullet point in a short sentence at the beginning, so that those who want a really cut-down version of this can take out the examples. I therefore propose the following:

 * Designing and developing in a way that removes barriers to localization or international deployment. This includes such things as enabling the use of Unicode or ensuring the proper handling of legacy character encodings where appropriate, taking care over the concatenation of strings, avoiding dependance in code of user-interface string values, etc.

> 
>    * 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. 

I think "planning for international support at design time" doesn't necessarily mean much to someone without the following text. I prefer to combine my and your versions as follows.  I added another example too.

 * Providing support for features that may not be used until localization occurs. For example, adding markup in your DTD to support bidirectional text, or for identifying language.  Or adding to CSS support for vertical text or other non-Latin typographic features.


> 
>    * 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...

Although I feel my own version was ok, I will go with this, though I will try to make it look shorter.  I'm also adding Daniel's suggestion.

 * Enabling code to support local, regional, language, or culturally related preferences. Typically this involves incorporating predefined localization data and features derived from existing libraries or user preferences. Examples include date and time formats, local calendars, number formats and numeral systems, sorting and presentation of lists, handling of personal names and forms of address, etc.

> 
>    * 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.

No difference here.

> 
> 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.

OK.  This also reinforces the 'i18n is in the architecture' idea.

> 
> 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").

OK. And I add back here a slightly reworded:

So ideally, internationalization occurs as a fundamental step in the design and development process, rather than as an afterthought that can often involve awkward and expensive re-engineering.



This gives  us the following clean copy. Is this acceptable?

============================================


Internationalization is the design and development of a product, application or document content that *enables* easy localization for target audiences that vary in culture, region, or language. 

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:

 * Designing and developing in a way that removes barriers to localization or international deployment. This includes such things as enabling the use of Unicode or ensuring the proper handling of legacy character encodings where appropriate, taking care over the concatenation of strings, avoiding dependance in code of user-interface string values, etc.

 * Providing support for features that may not be used until localization occurs. For example, adding markup in your DTD to support bidirectional text, or for identifying language. Or adding to CSS support for vertical text or other non-Latin typographic features.

 * Enabling code to support local, regional, language, or culturally related preferences. Typically this involves incorporating predefined localization data and features derived from existing libraries or user preferences. Examples include date and time formats, local calendars, number formats and numeral systems, sorting and presentation of lists, handling of personal names and forms of address, etc.

 * 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").

So ideally, internationalization occurs as a fundamental step in the design and development process, rather than as an afterthought that can often involve awkward and expensive re-engineering.

Received on Thursday, 29 September 2005 16:30:02 UTC