Subject: Re: Locale choice
From: Paul Rohr (paul@abisource.com)
Date: Mon Mar 05 2001 - 15:13:40 CST
At 06:09 PM 3/5/01 +1100, Tim Allen wrote:
>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).
Right.
>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.
Agreed. But let's do a quick reality check on the scale of this potential
problem. The screw case here is that we auto-launch in a language, because
it was the only match for your language *or* country. It's spoken in your
country, but not by you. Your only hope is that there's some *other*
supported language (not yours) spoken in some other country (not yours) that
you can make do with.
For example, I "speak" en-US, and if I find myself on a computer that has
Sioux, but no en-* localizations, then having it auto-launch in Sioux
probably isn't helpful. Ditto for an es-ES speaker "forced" into Catalan,
or an es-MX speaker "forced" into using Mayan.
We probably need better examples, because my reaction in both cases is to
chuckle and say "serves you right." :-)
>True. So the "present the user a short list of alternatives" plan sounds
>like the way to go.
Yep. I think you've convinced me that we should only auto launch if there's
a single language match.
Instead of auto-launching for a single-country match (the Sioux example), we
should go ahead and pop up the dialog. That lets me confirm that I'm
willing to use Sioux or pick another off the complete list. Ditto for the
far more likely case -- a Sioux speaker forced into using en-US.
>> 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.
Agreed. Again, I don't think that this extra bit of knowledge should be
used to auto-launch on a single match, but it'd help seed the popup with
more useful suggestions.
>> 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.
Sorry. I thought we were only talking about the "first launch" scenario.
Any dialog in the UI should *always* let you choose *any* locale. At
various times in school, I did assignments in English, French, German,
Russian, and abstract mathematician. No filtering algorithm is going to
guess that mix properly.
>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.
I just checked the languages popup dialogs on IE 4 (over 100) and Netscape 4
(over 50). In both cases, scrolling through the list wasn't that bad at
all, because the list itself showed about a dozen at a time.
But hey, don't let me stop you from trying out pruning algorithms. ;-)
>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
Agreed. We only auto-launch (without asking) if there's a single language
match. In all other cases (below), we always ask.
>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
Sounds fine by me, as long as the user only ever sees at most two dialogs:
- a short list of the algorithm's best guesses, and
- the full list.
Having a longer series of guesses presented in order just sounds annoying.
>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.
Cool.
Paul
This archive was generated by hypermail 2b25 : Tue Mar 06 2001 - 02:23:36 CST