Re: Localization without translation? (was: Re: Business Case for i18n?)

This is a huge topic! However, here are just a few 'best practices' from 
our globalization practice:

Typically, text-based UI (not content) date and time strings (in formats 
like MM-DD-YYYY) should not be used and should definitely not show up in external resource files at all. Using locale-sensitive code, 
all date/time/currency related UI strings should be generated 'on the fly' 
using substitution variables (%date) that allow the process to display the 
correct format for the user locale (provided the user locale has been 
communicated to the process through querying the client or profile 
settings submitted by the user). 

Date and time strings that are an integral part of content (as in: "After 
his birthday, which was on 02/03/2001, he suddenly felt his age") should 
NOT be extracted into external resource files and localized separately 
from that content. If and when the content gets localized, the date/time 
strings will get properly localized as well (by the localizer). It is 
generally bad globalization practice to mix locale formatting conventions 
within the same 'logical unit' of content. 

A third caveat has to do with transferring date, time or numeric values 
formatted as strings across machine boundaries: The sending and receiving 
processes may be using different date, time and numeric formatting rules. 
If the receiving process must parse, interpret or process these values, 
and it parses or performs string-to-xx conversions based on its local 
formatting rules, the operation will fail. For example, a French process 
will format the date "12/25/98" as "25/12/98", the time "6:31pm" as 
"18:31", and the number "13,244.89" as "13 244,89". A Japanese or 
Portuguese process will use different formats for the same data. To 
correctly interpret incoming data formatted as strings, the receiving 
process must know the locale of the sending process, and the formatting 
rules associated with it. The safer and more efficient way is to transfer 
dates, times and numbers as binary data (or any other locale-neutral 
representation), and let the receiving process perform the formatting 
according to its local rules. 

Kind regards,

Robert VanRaamsdonk
Global Engagement Consultant
Lionbridge Technologies
phone: +1 (508) 960 2363
efax: +1 (815) 327 3745
mobile: + 1 (617) 899 8704
robert_vanraamsdonk@lionbridge.com




Martin Duerst <duerst@w3.org>
Sent by: www-international-request@w3.org
06/14/01 05:43 AM

 
        To:     Andrea Vine <avine@eng.sun.com>, www-international@w3.org
        cc: 
        Subject:        Localization without translation? (was: Re: Business Case for i18n?)


Hello Andrea,

At 11:43 01/06/13 -0700, Andrea Vine wrote:
>Along that line, I'm wondering what folks are doing about their English
>products.  I'm trying to convince folks that even though the product is 
in
>English, it should not be designed only for the USA.  That is, 
locale-related
>formats should be dynamically selected, or user selectable, rather than 
in a
>localizable resource file.  So for example someone using the English 
>product in,
>say, Germany won't see their dates in MM/DD/YY format.

Thanks for bringing up this point. It's something that I have
tried to think about for quite a while, but I still wonder
what's the right thing to do.

If I see a MM/DD/YY date format in an English text, I may get
confused (given my Swiss-German origin).

But if I saw DD. MM. YY (the German format) in an English text,
I would definitely also get confused. And even more somebody
in a locale that has DD/MM/YY. And in addition, confusion
would increase if different applications or documents use
different conventions.

And this is only for the short date formats. For the longer
format versions, the confusion is somewhat reduced because
they make it more explicit what is day, what is month, and
what is year. But localizing then gives you German (or
whatever) text in the middle of an English document,
which also doesn't look that good.

Is it possible to have some general guidelines? What are the
factors that affect a good solution?

Regards,   Martin.