RE: 1st Working Draft of Authoring Techniques for XHTML & HTML Internationalization Published

I'm with Addison on this one. ISO 8601 for machines,
something more readable for end users.

And I like Addison's summary below a lot.

Regards,    Martin.


At 14:37 04/04/10 -0700, Addison Phillips [wM] wrote:

>Month names don't necessarily require more localization effort: APIs
>generally have them built in. It's a question of matching format, input,
>etc. together most effectively/efficiently.
>
>At webMethods I've always decreed an ISO 8601-like format for logs and
>administrative applications, but the usability ginks get (rightly) annoyed
>when I try to do so for non-technical user interfaces.
>
>Like most internationalization problems, the answer to any question begins
>with the phrase "Well, it depends...", so I guess I'm with Tex on this one.
>The presentation of "month" should be joined with considerations for the
>audience in presenting the value.
>
>I recognize that the section isn't fully baked, so my criticism should
>probably be reserved. If we wait for everything to be perfect we'll never
>publish anything.....
>
>Personally I favor:
>
>  - static text for non-technical audiences, use the "long" form (least
>ambiguous) for the locale
>      January 2, 1980
>  - input fields for non-technical audiences, use popup controls and a
>shorter form
>      [ Jan 2, 1980 ] (click in field to get popup calendar)
>  - use separate fields when they cannot be avoided, but note the additional
>effort for localizers
>      [January v][02 v][1980 v]
>  - preferably use 8601 format whenever possible for both static and input
>text, lists, etc.
>      1980-01-02
>  - and whenever possible avoid user input of dates as text
>      see http://www.inter-locale.com/CodesetTesting4.jsp (although the demo
>is a bit hard to understand at the moment, i18n folks will probably
>understand the problem.....)
>
>But that's just me. I'm interested to hear other's thoughts.
>
>Addison
>
>Addison P. Phillips
>Director, Globalization Architecture
>webMethods | Delivering Global Business Visibility
>http://www.webMethods.com
>Chair, W3C Internationalization (I18N) Working Group
>Chair, W3C-I18N-WG, Web Services Task Force
>http://www.w3.org/International
>
>Internationalization is an architecture.
>It is not a feature.
>
> > -----Original Message-----
> > From: public-i18n-geo-request@w3.org
> > [mailto:public-i18n-geo-request@w3.org]On Behalf Of Tex Texin
> > Sent: samedi 10 avril 2004 00:33
> > To: aphillips@webmethods.com
> > Cc: Martin Duerst; Richard Ishida; 'Jungshik Shin';
> > public-i18n-geo@w3.org
> > Subject: Re: 1st Working Draft of Authoring Techniques for XHTML & HTML
> > Internationalization Published
> >
> >
> >
> > With respect to date format and month names:
> > http://www.w3.org/TR/i18n-html-tech/#ri20030510.103018444
> >
> > We should not publish strategies which aren't either established
> > i18n practices
> > or derived from standards, at least not without a clear warning.
> > Are there any
> > references for the month name approach?
> >
> > I agree with Jungshik and prefer the ISO 8601 approach with all
> > numbers and
> > haven't run into a situation where it was considered ambiguous
> > with a 4 digit
> > year. If there is ambiguity, provide an indicator (such as
> > "yyyy-mm-dd") or a
> > footnote on the page.
> >
> > Using month names increases the localization effort and therefore
> > runs against
> > internationalization.
> >
> > ISO 8601 is also recommended in the W3C date time note
> > http://www.w3.org/TR/NOTE-datetime
> > and many other places, and is not mentioned in the guidelines (yet).
> >
> > I would prefer we endorsed 8601 as the first choice, and offered textual
> > alternatives as a last resort (or not at all).
> >
> > My 2 yen.
> > tex

Received on Monday, 12 April 2004 03:53:31 UTC