Subject: Re: how should we localize locale names?
From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Sat Mar 17 2001 - 04:18:36 CST
Hi Paul,
> Please forgive me for overexplaining (again), but I just want to make sure
> we're understanding each other.
You are not the only one who has been verbose on this, but I think
we are beginning to get somewhere :-), I certainly understand your
postion better than a week ago.
> I'm not sure that most users would agree with you. The distinction between
> languages and locales is pretty subtle. In both cases, I want to choose the
> dialect of English or Deutsch that *I* speak.
Except that AW UI might be localised into 25 languages, but we
can support 170 languages for the content at the same time. The
number of languages available for the UI will probably never be the
same as those for the content, because the content language
becomes meaningful as soon as you add a dictionary. Also, the
content language is outwith the control of the user, since one might
be sent a document by someone else.
Basically I think that for each language we have AW UI localised
into we should also provide a dictionary, so that if you choose
Catalan for your UI, you should be able to spellcheck Catalan too.
On the other hand, if we have dictionaries for Sioux available but no
translation of the UI, we should still add Sioux to the content
language list (but obviously not to the UI list). If we do not have
dictionaries, we should not list the language, because we cannot
spellcheck it; the user will simply have to select the pseudo-
language "no proofing" to aviod red squiggles everywhere.
> >(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.
>
> I'm not sure I agree. What's the harm in putting squiggles under misspelled
> content in other languages?
It is not the squiggles I am worried about (by all means let's put the
squiggles in), but running the spellchecker interactively, because
we will not be able to display the mispelled words and the
alternatives. She would not see noise, but just the nice circless we
use for chars we cannot display something like:
Not found: ooooo
Alternatives:
ooooo
ooooo
ooooo
It is one thing to see the circles in the doc, after all, she insisted
on opening it, but we should not bother her with something so
irrelevant and useless as the stuff above.
> Thus, if there are multiple languages in a document, it might be nice to
> have a dialog listing them all, so that you could toggle *off* spell
> checking support for langauges you don't speak and can't fix.
>
> Or, better yet, instead of a document-specific option, it's probably even
> cleaner to have an app-wide option to only *enable* dictionaries for the
> languages you *do* speak.
>
> If we set that expectation, and people agree that it's reasonable, then we
> could safely and silently ignore *any* content that we don't find an enabled
> dictionary for.
That sounds like a very good idea to me, but you will still need to
be able to deal with the case where the user will not set this option
and gets a doc with language for which the fonts are not there.
> OK. I think I get it now. :-) Your big issue is to make sure that the
> interface is never ugly.
> Specifically, this means keeping the names of those locales or languages
> from being displayed in the UI *in* their own language, unless we have the
> proper font & charset support to do so cleanly.
Yes, now you can see right through me :-). There is though one
additonal problem with listing the languages in their own language:
what order will they come in? Notably, where will you put Russian
in relationship to Romanian; will/should/can they be near each
other? And where will the CJK languages, Arabic, Hebrew go?
Will/should Serbian (Cyrilic) and Serbian (Latin) be next to each
other (same language, two alphabets)? This is difficult as is, but
even more so because our UI is 8-bit, so that Russian 'R' will not
be anywhere near English 'R', but will overlap with probably entirely
unrelated letters in Hebrew, Arabic, Thai, etc.
On the UI list, this is less of a an issue, because the list is likely to
be shorter, and we could in fact split it into several smaller lists
that use the same alphabet, indicating what is going on by a few of
letters from the alphabet above each sublist (and having one for any
odd languages). In the content language list this is a problem, for a
person using utf-8 locale (or win NT) may want all the langs we can
handle listed, and under utf-8 we can handle pretty much anything.
It seems to me that the only way to provide easy to use interface in
this case is to have the whole list properly localised.
Please do not get me wrong, I do see the attractivity of a list where
each language is displayed in its native alphabet, but I have serious
doubts that we can get AW Just Work (to borrow your phrase)
without having the ability to refer to each language we support in a
localised manner.
> I think our only difference is that in addition to the following pretty
> list: ...
> I'm also willing to tolerate intelligibly ugly names for ugly content:
>
> #$^%# - #$^% (zh-TW)
> And you're not. :-)
Yes, that pretty much sums it up. Honestly, if you were using
Word 2000 and a string like that (or just the ooooo) poped up at
you somewhere in a dialogue, would you feel it Just Worked, or
would get the pleasant feeling some of us get when they see that
M$ screwed up?
All the best
Tomas
This archive was generated by hypermail 2b25 : Sat Mar 17 2001 - 04:18:52 CST