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

Yes and no.  Whose English is that anyway?  I'd interpret the date different
on both sides of the Atlantic.  Another argument against short date formats,
but since people are going to use them, I think they should show up in the
reader's locale format even if the language doesn't match.

Which is a little different question from how software should behave.  If I
create a spreadsheet in France and send it to the US, I would want all the
numbers to display in the viewer's locale format, except currency amounts,
which ought to be sticky and carry an international currency label.  But you
could argue that even those formats ought to use locale-appropriate decimal
and grouping symbols.

-----Original Message-----
From: Lacoursiere, Guy [mailto:Guy.Lacoursiere@Cognos.COM]
Sent: Thursday, June 14, 2001 11:04 AM
To: 'Robert_vanRaamsdonk@Lionbridge.com'; Martin Duerst
Cc: Andrea Vine; www-international@w3.org;
www-international-request@w3.org
Subject: RE: Localization without translation? (was: Re: Business Case
for i18n?)


Robert,

> -----Message d'origine-----
> De: Robert_vanRaamsdonk@Lionbridge.com
>
> 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.

I agree with you: date and time that are integral part of content should
remain in the locale of the text, not that of the user.  However, for dates
that are part of text, like in your example, I always favor long date
formats.  Otherwise, in your example, how are localisers supposed to know
whether this date represents February 3, 2001 or March 2, 2001 without
knowing the "locale" of the sentence? ;-)  In this case, you risk having not
only a small ambiguity, but rather "data integrity" in your translated
content...

Guy Lacoursière
Software Globalisation Consultant
Cognos Incorporated

Received on Thursday, 14 June 2001 12:15:37 UTC