Subject: Re: Locale choice
From: Paul Rohr (paul@abisource.com)
Date: Fri Mar 02 2001 - 20:15:02 CST
Tim,
That was a *very* clear explanation. Thanks. It's an interesting idea, but
I suspect that less cleverness would suffice.
By comparison, my proposal was a lot simpler. Say the system reports a
locale of xx-YY (both hypothetical). In most cases, that's definitely what
the user wants, or something very close to it.
A. If you get an exact match, use it.
B. Check for language matches next (xx-*). If you get only one, use it.
C. Check for country matches next (*-YY). If you get only one, use it.
If either B or C produces multiple matches, show 'em all (xx-* and *-YY) so
the user can pick which one they really wanted.
The idea is that you want an exact match, if available, or the single
closest match, if there's only one available. Failing that, you should be
able to recognize the untranslated names of your language as spoken in other
locales, as well as all other languages spoken in your country. No
additional automagic is needed, although I suppose some folks would want a
"More" button at the bottom of the dialog which listed *everything*.
Likewise, if no matches are found at all, you have two choices:
- just use English, or
- show every supported locale and let them pick.
Given your examples, which cases wouldn't be addressed by this technique?
Can you think of cases where this "use a unique match or else prompt"
strategy would either:
- get you the wrong answer, or
- hide the "right" one from the list?
Off the cuff, I can't.
At 11:10 AM 3/2/01 +1100, Tim Allen wrote:
>There may be risks in assuming that everyone in a
>particular country has the same preference order, but
I'll claim that there's no need for complex fallback schemes within the en-*
and fr-* families, since you can scroll right to the one you want. (And
you'll quickly get irritated enough by the lack of en-GB that you'll pester
someone to get it for you.)
Likewise, if es-ES is missing, you may be willing to make do with either
another es-* (we don't have any yet), or perhaps another *-ES (we have two
of those). Still, chances are that you *really* want es-ES.
>I think one could
>produce an adequate generalisation that would get it right most of the
>time.
Sure, but the downsode of a fully-automatic solution is that the *rest* of
the time, you piss people off.
>So I speculate that a Malay speaker in Singapore would prefer, in order,
>my_SG, my_MY, my_BN (or whatever Brunei is), my_TH, id_ID, id_SN
>(Surinam). And an Indonesian speaker in Indonesia would prefer id_ID,
>id_SN, my_MY, my_SG, my_BN, my_TH.
>
>So this is trickier than just matching language codes, or matching country
>codes; you have to be able to relate together similar languages.
Exactly. Since there's no overlap between the id-* and my-* countries,
you'd need to know that the two were related. That's a pretty simple rule,
but I'm not sure whether it's worth adding.
This whole discussion assumes that:
- the "ideal" locale (xx-YY) is missing,
- the "next best" locale wouldn't show up on the (xx-*, *-YY) popup, and
- it's too big a bother to scroll through all the locales to find another.
Since the question only gets asked once (at startup, the first time), this
doesn't seem all that burdensome.
>Let's get even more ambitious. A Javanese speaker in Indonesia (I guess
>the language code for Javanese is jw, but don't know) would obviously
>prefer jw_ID. There are Javanese speakers in Surinam, so jw_SN might
>do. And of course, all Indonesians schooled since independence (ie aged 60
>or less, roughly) were taught Indonesian at school, so there is every
>chance that id_ID would also be an adequate fallback, and then we get back
>into the whole my_* chain of preference as well.
Yep. If you can't match jw-ID exactly, then jw-SN followed by id-ID are
both likely to be useful fallbacks.
>Another example, nn_NO, nb_NO. Presumably these are adequate fallbacks for
>each other. I'm told that Norwegian, Swedish and Danish are similar enough
>to be mutually intelligible, so perhaps a fallback chain that involves
>these other languages would also be sensible.
Yep. This is the case I designed for -- no-NO would pop up those two
choices. I'm just not convinced that any further fallback (to other
Scandanavian languages) would be any more worthwhile than falling back to
English or a complete list.
>Simply looking at
>either the language code or the country code and doing string
>matching therewith doesn't really do it.
I guess we disagree, then. :-)
Paul
This archive was generated by hypermail 2b25 : Fri Mar 02 2001 - 20:53:21 CST