Subject: Re: how should we localize locale names?
From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Fri Mar 16 2001 - 04:48:15 CST
> Paul:
> 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.
>
Yes, I agree with this virtually completely (see a note at the very
end).
> 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?
Yes, it is a list control. And, the two might be different, because
they are about two different things (see below).
> 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?
To do this at runtime is fair enough, but (1) and (2-3) are only
related by sharing similar font-related problems. So I think they do
not need same UIs. (1) is about the environment in which AW runs;
if the environment does not support a particular locale, that is the
user's problem, and we will not try to run under such a locale,
since we cannot. On the other hand, (2-3), or at least (3), is about
capabilities of AW that are not dependent on the enviroment. If the
user does not have suitable fonts to display Arabic text, we are still
able to do everything that the lang property is for (providing we have
the dictionaries available); basically I think the contents of the lang
list should be static, it is about what AW can do.
The list could be dynamic, based on what languages we can
display, in which case you could have them presented in their
native form, but that does not remove the need for a translation of
the language name to the language of the current locale. Say that
a user does not have Arabic fonts, but she gets an English doc
with some limited Arabic in it for the purposes of proofreading the
English. She does not want to display the Arabic, which she
cannot read anyway. She will make some changes to the English
and then decide to spellcheck the document. What should happen
when the spellchecker gets to the Arabic portions? (1) If we have
an Arabic dictionary (and presumably we will be shipping
dictionaries with AW), we can spellcheck the Arabic; we will run
into difficulties if there are errors, but could at least let her know
that there are errors, and she can pass let the author know, but
that is not, IMO, very good approach. (2) We could silently ignore
the Arabic, but that is not a good idea, because the user may in
fact assume that spellcheking means spellchecking everything. (3)
Thus, as another option we could display a message saying, "we
will ignore Arabic, since you cannot display it". This is probably
most sensible, but in order to do that, we will have to be able to
translate the lang value for Arabic into English, so that we can tell
her it is Arabic that we are ignoring. Thus, irrespective of what and
how gets displayed in the lang listbox, we need to be able to
translate the lang property into the language of the interface,
precisely because we need to be able to refer to the language
when we *cannot* display it in its native shape. We could of course
provide a romanised name of the language, but imagine the
ugliness of the message, if it is in a non-roman alphabet locale,
say Russian ... It is this ugliness that I am against, because it
would give us a name for slopiness.
> 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
ugly interface is not an option I am prepared to consider; either we
can support given locale, and then we can have a nice interface, or
we cannot, and then we should not pretend we can :-). Ugly
content is a different issue, because documents can contain
languages that the current locale cannot handle; we display the
lovely circles, and hope the user gets the hint and moves to utf-8 :-).
> >P.S. I do not think you are stupid at all :-)
>
> Thanks. It really was an outrageous hack, wasn't it? :-)
I would not say outrageous, it would have solved the problem. We
will need something equally hackish, but more portable and
requiring less work. The question concerning the dialogue which
allows the user to choose the language of the UI is should we (a)
display only the languages that the current setup can handle, or (b)
display all languages that AW can handle but grey out those the
environment does not support. I personally would prefer (b),
because it makes it clear who is at fault and what AW can do if
given the oportunity. One way such a list could be created would
be by using bitmap snaps of the languages we can support, but we
would have to create a custom listbox made of bitmaps. Not sure
this is any less work than your solution, but it would be 100%
portable.
Tomas
This archive was generated by hypermail 2b25 : Fri Mar 16 2001 - 04:48:24 CST