FW: Lloyd's FAQ resurfaces (long)

The virus problems on the list ate my message...

So here it is again. Slight revision to it in case the first one eventually
surfaces on the list ;-).

Addison

-----Original Message-----
From: Addison Phillips [wM] [mailto:aphillips@webmethods.com]
Sent: Wednesday, August 20, 2003 2:05 PM
To: public-i18n-geo@w3.org
Cc: public-i18n-ws@w3.org
Subject: FW: Lloyd's FAQ resurfaces (long)


All:

Somewhere under Richard's response below is my initial reaction to Lloyd's
FAQ about Accept-Language (A-L) and Locale. I have copied the WSTF list
because our group is active in the area of locales.

I agree with nearly all of the detail in the FAQ, but not with the overall
presentation. I would prefer if the question were rephrased "How can I
obtain a locale from a browser (user-agent)? Can I get it from the
Accept-Language?" I would like the answer to be "Yes", rather than (as it
appears now) to be "No". My concern is that the emphasis is in the wrong
place. If you re-emphasize the first paragraph like the following, the point
is clearer:

"Yes, but it is not a good idea to use HTTP Accept-Language
<emph>alone</emph> to determine the locale preferences of the user."

The page should include reference to the fact that many Web servers, server
side scripting languages, and operating environments, by default, parse and
infer their native locale objects from Accept-Language. For example, .NET
uses the A-L to determine the default CultureInfo, Java Servlet provides a
getLocale() and getLocales() pair of methods that parse A-L, and so forth.
These objects are very useful in obtaining resources and other "language
preference" material. They are less useful, as pointed out by the FAQ, in
determining many of the fine grained attributes of users or in designing the
international behavior of a site. A language preference of es-MX doesn't
necessarily mean that a postal address form should be formatted or validated
for Mexican addresses. The user might still live in the USA (or elsewhere).

The rhetorical question "Do you want to shove Polish content at a user just
because they are running a user agent in Warsaw?" might be answered yes in
some (many) cases. I think that the particular approach that a website takes
when displaying the homepage depends on the application. If you don't have a
cookie, logged in user, or other information about a request, it may
actually be BETTER to follow what limited information you do have (including
A-L) than ignore it. Do you want to shove French content at a user just
because they haven't clicked on Polish yet? When all you have is an
Accept-Language, what should your implementation decision be?

Finally, I think that the bulleted list at the bottom isn't all that
appropriate. Of the items listed, only one (date/time formats) can be wholly
or partially inferred from a locale. The remainder (timezone, currency,
measurement system, paper size, Tex's shoe size, physical location) are all
orthogonal or, at best, distantly related to locale systems. In proper
international design, one would not necessarily infer any of these from the
user's concrete locale setting, let alone from A-L.

Thanks for the opportunity to comment.

Addison

Addison P. Phillips
Director, Globalization Architecture
webMethods, Inc. -- "Global Business Visibility"

432 Lakeside Drive, Sunnyvale, CA, USA
+1 408.962.5487 (office)
+1 408.210.3569 (mobile)
mailto:aphillips@webmethods.com

Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International/ws

Internationalization is an architecture.
It is not a feature.

-----Original Message-----
From: Richard Ishida [mailto:ishida@w3.org]
Sent: Wednesday, August 20, 2003 11:46 AM
To: aphillips@webmethods.com
Cc: Richard Ishida
Subject: RE: Lloyd's FAQ resurfaces


Hi Addison,

Don't worry, I still like you ;)  I think these are generally good
comments.  You could, if you want, send these to public-i18n-geo@w3.org
now - I signed you up a few days ago.

I guess what you're missing is some information: we do have John Yunker
working on more comprehensive guidelines for navigation (and he's quite
keen on this topic).  The guidelines are more appropriate for 'how to'
type of information such as you are suggesting.  Ideally that would
exist already, and this FAQ would point to it, but one step at a time...

> If A-L is good for content selection, why not locale selection?

Hmm. I'm wavering on this...  Maybe we should soften the text a little.

Some of the points you make lower down (eg. Currency) would be worth
sending to the geo list.  Would you like to do that, adapting the stuff
relating to how-to's in the light of my earlier comment?

RI


============
Richard Ishida
W3C

contact info: http://www.w3.org/People/Ishida/

http://www.w3.org/International/
http://www.w3.org/International/geo/

See the W3C Internationalization FAQ page
http://www.w3.org/International/questions.html



> -----Original Message-----
> From: Addison Phillips [wM] [mailto:aphillips@webmethods.com]
> Sent: 19 August 2003 20:11
> To: ishida@w3.org
> Subject: RE: Lloyd's FAQ resurfaces
>
>
> Gee... you're not going to like me any more...
>
> I don't like the flavor of this FAQ. I agree with the exact
> wording of the first couple of paragraphs. They capture the
> point perfectly. But this is a non-trivial topic. My big
> concern here is that it is basically too negative: it leaves
> the impression of "don't use A-L to be the locale" without
> suggesting the approaches that should be used to infer locale
> (which, in my opinon, should start with A-L!). In fact, it
> should say more of the opposite. The point here should really
> be (and the stress moved around to make clear) that
> Accept-Language can help indicate default locale and language
> settings as a starting point to a user session, but that
> these settings are not sufficient in all cases and in all
> applications.
>
> For starters, you might mention that some users expect the
> content to be related to the web address (e.g. example.de is
> in German, while example.com is in English).
>
> Mentioning or having an FAQ link to how to do language choice
> on a web page would also be useful. The design of a
> particular application's handling of A-L will depend on your
> applications users and requirements. For example, google.com
> or hotmail/MSN displays their user interfaces in the topmost
> language in the user-agent A-L stack. Other sites (altavista
> or macromedia, for example) use the country-based site as the
> starting point and allow visible navigation to other language
> versions (they also allow the user to select specific
> language preferences that are then stored in cookies to save
> future navigation). A good example of tailoring is that if
> you go to www.hotmail.com you will see the login page in your
> current A-L language (for me at the moment this is Japanese),
> but once I log in I always see English becuase that's how my
> profile is set up.
>
> If A-L is good for content selection, why not locale selection?
>
> Well, why NOT locale selection? You can use A-L to create
> locale objects or settings in many web platforms. .NET and
> Java servlet both use and endorse the use of Accept-Language
> to create the locale (CultureInfo or
> java.util.Locale) default settings in web pages: this is the
> default behavior in these systems. These may actually be used
> to load system resources (resource bundles) in a particular
> language, relating back to the original intent, which was
> language selection and content loading/formatting at display time.
>
> There are places where the locale you obtain from the A-L is
> inappropriate. Inferring more than user language choice is
> potentially dangerous. Just because my langauge is set to
> de-CH doesn't mean that I want to have you ship products that
> I order from you to Switzerland. User profile and application
> preferences should be carefully thought through and
> country-of-origin information should probably not be inferred
> from a locale, no matter how the locale is obtained.
>
> I'm not wild, as a result, about the bullet items in the
> background section. These are all orthogonal or a bad idea to
> infer from a locale to begin with. For example, inferring the
> currency symbol is an awful idea in all cases. One should get
> the currency associated with the data itself, not rely on
> inference from locale. A-L as a locale indicator is no better
> or worse at this than anything else. Mixing up concepts like
> this is fatal to many applications. Why blame RFC3066 for this?
>
> So the summary of this is that I think the point is
> insufficiently clear. We appear to be "taking away" the
> existing locale mechanism without explaining what to do instead.
>
> Just my two cents.
>
> Addison
>
> Addison P. Phillips
> Director, Globalization Architecture
> webMethods, Inc. -- "Global Business Visibility"
>
> 432 Lakeside Drive, Sunnyvale, CA, USA
> +1 408.962.5487 (office)
> +1 408.210.3569 (mobile)
> mailto:aphillips@webmethods.com
>
> Chair, W3C-I18N-WG, Web Services Task Force
> http://www.w3.org/International/ws
>
> 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 Richard Ishida
> > Sent: Tuesday, August 19, 2003 11:03 AM
> > To: 'GEO'
> > Subject: Lloyd's FAQ resurfaces
> >
> >
> >
> >
> > I have just had a editorial session with Lloyd and posted
> what we hope
> > is a final version of his FAQ 'Accept-Language used for locale
> > setting' at
> >
> http://www.w3.org/International/questions/qa-accept-lang->
locales.html
> >
> > I propose we announce this to the world a week on Thursday.
> >
> > RI
> >
> > ============
> > Richard Ishida
> > W3C
> >
> > contact info: http://www.w3.org/People/Ishida/
> >
> > http://www.w3.org/International/
> http://www.w3.org/International/geo/
> >
> > See the W3C
> Internationalization FAQ page
> > http://www.w3.org/International/questions.html
> >
>

Received on Monday, 25 August 2003 12:38:47 UTC