Subject: Re: Locale choice
From: Tim Allen (tim@proximity.com.au)
Date: Mon Mar 05 2001 - 01:09:40 CST
On Fri, 2 Mar 2001, Paul Rohr wrote:
> Tim,
>
> That was a *very* clear explanation. Thanks. It's an interesting idea, but
> I suspect that less cleverness would suffice.
On thinking about it again, I tend to agree, up to a point. I think we
need one fairly simple new concept.
> 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.
>
> 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.
The "language A is similar enough to language B" cases won't pass this
technique, iff they do not occur in the same country (eg nn-NO vs nb-NO
works, id-ID vs my-MY doesn't).
> 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.
As Pierre points out, other languages spoken in your own country are not
guaranteed to be ones you are comfortable using; not all Spaniards speak
Catalan (and not all residents of the USA speak Sioux). I don't think this
eliminates the usefulness of the country code match, it's just a reminder
that we shouldn't rely on it exclusively.
> >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.
True. So the "present the user a short list of alternatives" plan sounds
like the way to go.
> 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 is the crucial bit of knowledge that I think could be added, with
relatively little effort: a set of pair of language codes that are
interchangeable. It might also be the case that pairs of country codes
could work (eg, setting intractable political considerations aside for the
moment, any CN (People's Republic of China) locale is probably usable in
TW (Taiwan) and vice-versa). A country code match is, in general, much
more likely to give you bogus options than a language code match, so it
would be important to only use the country code if the language code
doesn't give you any decent options.
> 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.
If we ever support a user who changes locales/languages, then it's much
more often than just the once.
> >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.
A complete list could be very long. AbiWord's current set of supported
locales probably fits ok in a scrollable list, but imagine what it would
be like if AbiWord really took off, and, say, half the countries in the
world had a supported locale in AbiWord. I'd certainly be grateful for a
sensible means of pruning the list down to a reasonable size. And if I was
in the habit of switching between locales/languages, I'd certainly like
that to be painless.
> >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. :-)
Probably not as strongly as you think :). It's a matter of
degree. Certainly, at the moment AbiWord doesn't really have enough
supported locales to make it worthwhile expending a lot of effort on this.
I'd better summarize the logic I think _will_ work, since my comments are
scattered all over the place:
1) exact match, use it
2) look for language code matches, if you find one use it, if you find
several give the user a choice of the matches
3) look for country code matches, if you find one or more show the options
to the user, let the user choose one or reject them all (rejection means
fall-through to next step)(note we do not automatically choose a locale
here, since we don't trust country codes as much)
4) look for matches on similar languages, if you find one or more show the
options to the user, let the user choose one or reject them all
5) look for matches on similar countries, let user choose one or reject
them all
6) show the user all the English language locales, let the user choose one
with no option of rejection
This is somewhat more complicated than your suggestion, Paul, but not by
all that much. However I'm not going to try to push anyone into making
this happen just yet. Let's get some more locales supported first.
> Paul
Tim
-- ----------------------------------------------- Tim Allen tim@proximity.com.au Proximity Pty Ltd http://www.proximity.com.au/ http://www4.tpg.com.au/users/rita_tim/
This archive was generated by hypermail 2b25 : Mon Mar 05 2001 - 01:09:53 CST