- From: Addison Phillips [wM] <aphillips@webmethods.com>
- Date: Sat, 10 Apr 2004 14:37:06 -0700
- To: "Tex Texin" <tex@xencraft.com>
- Cc: "Martin Duerst" <duerst@w3.org>, "Richard Ishida" <ishida@w3.org>, "'Jungshik Shin'" <jshin@i18nl10n.com>, <public-i18n-geo@w3.org>
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 Saturday, 10 April 2004 17:43:19 UTC