Subject: Re: how should we localize locale names?
From: Paul Rohr (paul@abisource.com)
Date: Thu Mar 15 2001 - 15:26:46 CST
Tomas,
A couple questions to be sure I've understood your position.
At 07:14 PM 3/13/01 -0000, Tomas Frydrych wrote:
>>Paul:
>> At the risk of disrupting an emerging consensus, I'm afraid I don't see
how
>> the distinction above helps. Why would the fact that I want to use a
>> language for one purpose (pulling down menus) versus another (typing
content
>> in it) matter? Wouldn't I want the names of those languages to be the
same
>> in both cases?
>
>I think what we envisaged in the former case is a dialogue that
>would allow the user to for instance select langauge for the
>interface at startup. In such a situation we would not be able to
>assume that the user understands any other language than the one
>she is looking for, i.e., we would have to present a list of languages
>formed along the lines you suggested.
Have I got this right? When choosing UI locales (especially in first-launch
scenarios), we have no choice but to display locale names in their own
languages, so that people can recognize their own. Moreover, we should
refuse to display any locale name if charset issues prevent it from being
displayed cleanly.
If the UI doesn't work in that language, the user's hosed anyhow, so we
should only present locale names we *can* display. As mentioned very, very
early on in this thread, we need a way to test for this at run time.
>> Tomas -- It's very, very clear that you *hate* this proposal, but I'm
trying
>> to figure out which of the following is the killer issue for you.
Before I
>> agree with you, I want to know what I'm agreeing with and why. :-)
>The killer issue for me is theory D which is slightly modified theory
>C:
>
>> Theory C
>> --------
>> Even if we *could* render all those language names properly in the UI,
it'd
>> still be a bad idea. Speakers of each of the 170 languages in the world
>> just plain *want* that entire list of 170 languages to be rendered in
their
>> language. Period.
>>
>> I admit that it kind of tickled my fancy to ship a product that helped me
>> learn what folks from Wales think their language should be called, rather
>> than what some ancestor of mine called them. ;-) But hey, I got my
degree
>> in liberal arts, where they train you that being ethnocentric is a Bad
>> Thing.
>I think that (a) people expect the menus to be in their UI language
>only;
Menus? I thought this was just another list control in Dom's dialog. If
so, my first (naive) instinct still asks why this dialog should be any
different than the popup one?
I've thought all along that it'd be cool to be able to do any of the
following at run-time by choosing the appropriate menu:
- change the UI locale
- change the default lang for a document
- change the lang of a specific portion of a document
Shouldn't these all have similar UIs with similar choices?
>(b) my basic problem is that in many cases we *will not* be
>able to show the language in the way the people who speak it call
>it, for lack of the necessary glyphs, and so we will end up with
>something ugly half-way in between; this is the one thing I trully
>hate.
I agree that we want to deal with the ugliness. The relevant questions are
where and how. There are two places we can run into charset issues:
- ugly interface ... unable to display localized menus, dialogs, etc.
- ugly content ... unable to cleanly render portions of the document
I've been assuming all along that our UI and content should be symmetrical
in this respect. Ideally, a given charset should be handled equally well
(or badly) in both cases.
That's what the other theories were intended to test, namely whether any of
the following were ever OK:
- ugly interface, pretty content
- ugly interface, ugly content
- pretty interface, ugly content
Theory A asked, in essence, if our charset handling for UI stuff (like
dialogs and menus) was worse than our charset handling when rendering
documents. If dialogs are worse, then we'd be able to type cleanly in a
particular language, but the dialog for choosing that functionality would be
ugly, which is clearly broken.
I take it that this is not the case. If we allow people to choose "ugly"
locale names, the content for that language will also be ugly. The symmetry
is appropriate, and if we don't like that effect, we should be able to
prevent both kinds of ugliness by pruning them from the dialog.
Theory B, which is really a special case of theory A, asked whether there
might be cases where we *want* to expose a "pretty" name (romanized in Tim's
proposal, localized in yours) for "ugly" content. Are there?
>Tomas
>P.S. I do not think you are stupid at all :-)
Thanks. It really was an outrageous hack, wasn't it? :-)
Paul
This archive was generated by hypermail 2b25 : Thu Mar 15 2001 - 15:45:29 CST