From: Phillips, Addison (addison@amazon.com)
Date: Tue Apr 21 2009 - 12:37:12 CDT
>
> > [Implementers should read and understand RFC 4647 and the
> "lookup"
> > algorithm to avoid spotty performance]
>
> Even that might not be enough.
> If the available languages are es-ES;en-US;fr-FR and I ask for es-
> MX, es-MX will not match es-ES (by RFC 4647).
> This requires one to be careful when declaring available resources
> (for instance to always include a "generic language", like es)
> But this is not possible in the case where the list of "available"
> comes
> from a 3rd party (for instance Windows, which does not support "es",
> only "es-something")
I... didn't say it was the *whole* answer :-). Defaulting behavior is part of the set of decisions that users/implementers need to deal with.
In my original note I mentioned that language negotiation != locale negotiation. This is an example of that. Locale systems (such as in Windows as you cite) may have idiosyncrasies such as requiring you to map a "generic" locale such as "es" to a specific locale such as "es-ES". I do note, however, that sometimes you need more than any simplistic negotiation mechanism can give you.
>
>
> > Typically the JavaScript locale matches the
> > system or user default locale where the browser is running
>
> Even the meaning of that is fuzzy.
Yes. I probably overgeneralized. However, the case is that the browser's JavaScript engine always has exactly one default locale that is not under programmatic control. It may be tied (depending on OS, browser, etc.) to different things, but the real problem is that, whatever the locale is, it is only right in the cases where that locale and the locale/language of the page/site being viewed happen to be the same. It can happen, but very often it doesn't. For minority language speakers, it is unlikely to happen.
> In general user default locale is the locale used to format
> date/time/number/etc.
> for the current user.
> In the e Windows world the system locale gives the ANSI and OEM
> code pages, but should not be used for much else.
Er... maybe. If you mean formally the system locale (as opposed to the "user locale"), I agree. If you mean instead "the locale you get from the runtime environment" (which was more my intention), then that's different.
>
> In general navigator.language matches the "language of the UI of
> the browser"
> (if I use a French Firefox on a German OS the navigator.language is
> "fr" or "fr-FR")
> In the Mac OS world the language of the UI of the OS, the language
> of the UI of Safari
> and navigator.language are tied together, which might confuse
> things a bit.
My bad. "navigator.language" is not the language you probably want for anything (other than to know what language the menus and dialogs in the browser happen to be in).
>
> So yes, it is a bit of a mess.
It's a fair mess. I've been trying to point out (and work on) these problems for some years now for Web services. There is general recognition of this problem by "I18N professionals", but not much traction outside our professional circles.
>
> > And anyone interested should really consider participating in the
> W3C
> > Internationalization WG. We could use the help.
>
> Ok, I will check my bandwidth and (maybe) offer. No promise yet :-)
>
Please do! There are many ways to participate and not all of them require major commitments.
Addison
This archive was generated by hypermail 2.1.5 : Tue Apr 21 2009 - 12:40:32 CDT