From: Christopher Fynn (cfynn@gmx.net)
Date: Sat Apr 18 2009 - 02:32:36 CDT
I don't know how easy or reliable detecting locale is. Here in Bhutan I
find 95% of computers set to locale USA and the input language also set
to en-US. Of course on Windows there is no dz-BT or en-BT locale
available - Though you can choose "Bhutan" as location in Regional
Settings, you then have to go somewhere else to select "(GMT+6) Dhaka"
in Time Zones. - Why didn't they link "location" and "time zone" together?.
This causes all kinds of problems ~ time zone is wrong, printers assume
8.25 x 11in paper instead of A4, month and date are in the wrong
order, and spell check assumes US English. Even when users manage to
change the input to en-GB they then get problems with their keyboard
because they don't seem to know how to configure for English GB with US
Keyboard layout. (Why do computers shipped in South & SE Asia inevitably
come with a US keyboard layout instead of international?)
Even though I have always had the preferred language in my browser set
to en-gb, for a long time Google thought I was in Hong Kong and
defaulted to a zh-HK search page. My guess this was because my ISP was
using a satellite that down-linked to HK.
- Chris
Ed Trager wrote:
> Hi, everyone,
>
> I'm working on some ideas for providing better support for localization
> in some "Web 2.0" applications.
>
> For example, consider a typical web form that asks for name, address,
> date of birth, etc. For better or for worse, we can envision presenting
> the user with a default form in English. At the top of the page, the
> form might have a drop-down selection list allowing users to choose
> alternate languages for the form - French, German, Arabic, Thai,
> Chinese, etc. ...
>
> If we can detect the user's locale, we can present the form immediately
> in the language specified by (any non-English) locale instead of the
> English fallback. Of course we will still have the drop-down selection
> list so users can still get any of the alternative language versions of
> the form if they want.
>
> Browsers such as Firefox (FF), Opera (OP), and Safari (SF) appear to
> provide:
>
> navigator.language
>
> ... while versions of Microsoft Internet Explorer (IE) provide:
>
> navigator.browserLanguage
> navigator.systemLanguage
> navigator.userLanguage
>
> My first question: Is this all that is available?
>
> From a limited investigation on a Windows Vista "en-US" PC, I see that
> navigator.language is set to "en-US" in FF and SF, but Opera only
> returns "en". IE also returns "en-US" but in the IE-specific
> variables. When I installed the Thai version of FF, I got just "th",
> not "th-TH" or, say, "th-US".
>
> So my 2nd question: Beyond the basic "language" code ("en", "th", "fr",
> etc.) I guess there is no reliable way within the browser environment to
> determine more specific locale information?
>
> For example, (3rd question...) am I correct in assuming that I *cannot*
> determine date format preferences? For example, if a browser like Opera
> is only going to tell me "en" and not "en-GB" or "en-US" or
> "en-AnywhereElse", then I guess there's no way to localize the date
> format to a preferred locale?
>
> (As an aside, I just want to make it known to everyone that I personally
> *despise* localised date formats and think *everyone* all over the world
> should just use ISO YYYY-MM-DD format. That's my own "Ivory Tower"
> opinion, of course ... But here I am just asking the question ... )
>
> (4th Question ...) So I guess it is completely moot to think one could
> find out about preferred currency or numeric formats, or anything else
> that a "thick" client might be able to discover from operating system
> environment variables that I suppose are never really exposed within the
> browser environment?
>
> - Ed
This archive was generated by hypermail 2.1.5 : Sat Apr 18 2009 - 02:36:18 CDT