W3C home > Mailing lists > Public > www-international@w3.org > April to June 2009

Re: New translation: 使ç?¨<select>é??�µ?å?�æ?�å?�å??å?�容

From: Ed Trager <ed.trager@gmail.com>
Date: Thu, 30 Apr 2009 14:39:40 -0400
Message-ID: <416e2cf10904301139r3af2u61ad35589abbfe54@mail.gmail.com>
To: John Cowan <cowan@ccil.org>
Cc: w3c-translators@w3.org, www-international@w3.org
Hi, John,

On Thu, Apr 30, 2009 at 11:09 AM, John Cowan <cowan@ccil.org> wrote:
> Ed Trager scripsit:
>> One can also argue with equal if not greater force that undoubtedly
>> there are plenty of Japanese (or any other nationality) business
>> people travelling through the major cities of France every single day
> [snip]
>> I've been thinking a lot recently about web site localization issues,
>> including this very issue.  Here is a solution I am considering
>> implementing:  It is now quite easy to use Geolocation to get an
>> approximate fix on the geographic origin of the computer requesting a
>> web page.  Based on the country of origin determined from geolocation,
>> it would be possible to use a lookup table to map the "top" languages
> Unfortunately, your first point undercuts your second point.  It is more
> and more true that where you are has little to do with your preferred
> locale.

Well, not exactly ...  I think I was just pointing out two different
aspects of reality, both of which should be considered by localization

Japanese speakers in France are definitely a very small minority, much
smaller in numbers than those who in France speak, for example,
Alemannisch or Auvergnat or Italian.  If I had localized pages in
Japanese, I would still keep "日本語 (Japanese)" in the <select> list --
it just would not be at the top of the list where "français (French)"
and the other more populous languages would be listed.

Another point I neglected to mention:  In principle, it seems sensible
to look at the HTTP "Accept-Language" header and maybe also the
"navigator.language" (or IE equivalent) variable.  If geolocation
tells you "France", but the "Accept-Language" list starts with
"Japanese", that seems informative : maybe the user prefers Japanese.

The only problem --and I think it is a big problem-- is that *way* too
often "Accept-Language" and/or "navigator.language" just say "en-US"
-- which is much less informative.  Even in the USA, if geolocation
says "USA" and "Accept-Language" says "en-US", the user still might
*actually* prefer Spanish -- but of course the user has no clue how to
set that preference in the browser.

And if geolocation says something like "Bhutan" but Accept-Language
still says "en-US", well in that case "Accept-Language" is nearly
useless (see Chris Fynn's points about the lack of Dzonghka
localization on most computers in Bhutan in a related posting on the
Unicode.org mailing list a few weeks ago).

So just because two items of data (geolocation + Accept-Language) are
in agreement that it is "English" does not, unfortunately, provide
confirmation that "English" is wanted.  It is definitely not the same
as say, two pregnancy tests both saying that one is pregnant ...

HTTP "Accept-Language" remains a conundrum -- I'm still not sure what
to do with it ...

Best - Ed

> Useful tip:  If you find yourself talking to Google in the wrong language
> when abroad, go to http://www.google.com/preferences?hl=<iso-639-code>
> and you can lock in your preferred language on that computer.
> Just click on the "Save Preferences" (or "Einstellungen speichern" or
> "Konservu Agordojn" or whatever) button in the upper right.  You will
> get English if Google isn't localized in the specified language,
> so don't go expecting http://www.google.com/preferences?hl=tlh to work.
> (Disclaimer: I work for Google, but not on i18n, and I'm not telling
> you anything that isn't public.)
> --
> John Cowan            http://www.ccil.org/~cowan     cowan@ccil.org
> Uneasy lies the head that wears the Editor's hat! --Eddie Foirbeis Climo
Received on Thursday, 30 April 2009 18:40:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 22:37:30 UTC