Subject: Re: how should we localize locale names?
From: Paul Rohr (paul@abisource.com)
Date: Mon Mar 12 2001 - 16:11:47 CST
At 08:51 AM 3/11/01 -0000, Tomas Frydrych wrote:
>> Sam:
>> Are we asking people who don't speak the language that AbiWord is
>> using to select a language? Or are we asking people who are currently
>> using a localized version of AbiWord to select a *different* langauge
>> to type some text in?
>>
>> If the former, then I agree with Paul and Tim, since when you have to
>> choose your language, having it presented in your language is
>> optimal. If the latter, I agree with Tomas, for all the reasons he
>> has given.
>>
>> I'm confused. What do people think we are discussing?
>
>The Language menu on the 'Tools->Spelling and Language' and the
>associated class UT_Language that sparked this disussion has to
>do only with the latter -- people who are using a version of AW
>localised to their own laguage and are selecting a language for the
>particular text they are typing for the purposes of spellchecking,
>thesaurus, ...
>
>I quite agree that the former case, where poeple are telling AW to
>provide them with the interface in a whole different language will
>require a different approach, but that is not what 'Tools->Spelling
>and Language' and UT_Language class are about.
Oh dear. I'm kind of in a quandry here.
I really, really want to defer to the judgement of folks like Tomas and Vlad
and Tim on issues like this. They're far more expert than I am on charset-
munging and the day-to-day needs of people in locales I've never even been
to. I just sit here in my familiar en-US locale and try to get things
rolling.
My only goal here is to try to drill though and come up with:
- a pragmatic solution,
- that works over the long haul, and
- that I can explain.
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?
Do we have real-life use cases where all three of the following apply?
1. someone wants to use a language (for UI *or* content), and
2. we do support that locale (for that purpose), but
3. they won't recognize the name of that locale in that language?
If so, then my modest proposal is clearly inappropriate, and should
definitely be withdrawn. Can anyone think of any?
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. :-)
Theory A
--------
We do a worse job of rendering charsets in the UI than we can for the
content. In other words, we *could* allow people to type stuff in a
"foreign" charset, and perhaps even spell-check it, but platform limitations
prevent us from accurately displaying the name of that language in the
relevant GUI dialog.
If this is in fact the case, then my proposal should (again) clearly be
withdrawn.
I'd been assuming that it wasn't the case; that we do an equally bad (or
good) job in both places. Thus, if the language is going to be gibberish in
the document (because of font and/or charset issues), then it doesn't much
matter that the name of that language is also gibberish in the dialog. If
we don't want gibberish one place, we should suppress it both places.
According to that style of reasoning, the fact that we have a codebase that
theoretically supports zh-TW doesn't do me any good if I can't see or work
with that content, so being able to choose a clean name for it in my
language wouldn't matter much, at least for me.
Theory B
--------
There are valid use cases where I want to be able to know that a particular
span of gibberish in my document happens to be in Chinese rather than
Hebrew. I speak neither language, and can't recognize either on sight,
either because I don't know what they look like, or charset/font problems
are munging them. But, I still want to know which is which, so labelling
them both using my language (en-US) is worthwhile for me.
Note that you could make the same argument reversing the locales, where
"gibberish" = en-US or fr-FR, and "my language" = Chinese or Hebrew.
(This would be more of an issue for reading content than authoring my own,
since presumably I'd never be able to usefully type in either language,
which is what the features in question were designed for.)
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.
Theory D
--------
Something else entirely that I missed in this barrage of posts. :-)
Paul
This archive was generated by hypermail 2b25 : Mon Mar 12 2001 - 17:06:44 CST