Subject: Re: POW -- which locales Just Work?
From: Karl Ove Hufthammer (huftis@bigfoot.com)
Date: Thu Mar 01 2001 - 17:46:38 CST
----- Original Message -----
From: "Paul Rohr" <paul@abisource.com>
To: "Karl Ove Hufthammer" <huftis@bigfoot.com>; <abiword-dev@abisource.com>
Sent: Thursday, March 01, 2001 7:25 PM
Subject: Re: POW -- which locales Just Work?
> Any chance we could also get you to whip up a locale matrix with a single
> partially-green row?
Something like this (attachment: locale_matrix.xml)? Since it's in XML, it's
pretty easy to maintain.
Using the (attached) XSLT style sheet, we can transform it into HTML
(attachment: locale_matrix.html). (We can create a XSLT style sheet to transform
it into an AbiWord document when we support tables! :) ).
>>The right (i.e. best) thing to do is probably to pop-up a dialog box
>>asking which language you want AbiWord to use the first time you run it
>>(for *all* languages, not just Norwegian).
>
>Hmm. I'd rather not ask at all unless we have to.
No, it's of course best to let it happen automagically. But we will need a
language tab in Preferences someday. People might want to run AbiWord in other
languages than their OS language, and manually editing configuration files is
not a good solution.
>Here's a modest proposal, assuming that the OS is getting the country
>right, but the language wrong.
>
>IIRC, our current logic prefers to match both the language and country.
>If there's no country match, it'll take just a language match. Couldn't
>we just add the other corner case? If there's no language match, but
>there is a single country match, then use that.
*After* having tried matching language, I presume.
>The dialog should only be a last resort when there's still ambiguity for
>the user to resolve:
>
> 1. no language *or* country match
> 2. language matches, country doesn't, several others available
> 3. country matches, language doesn't, several others available
Sounds good to me.
>One other nit -- in each of these cases, you have to decide which language
>to *ask* the question in (and default the selection to). My proposal:
>
> 1. en-US (it's our default anyhow)
> 2. whichever locale has the default flag set in the strings file
> 3. toss-up (but all should be familiar to someone in that country)
>
>Does that make sense, or is it being too clever?
I think that should work. It's pretty obvious what you should do when you're
presented with a list of languages anyway (choose the one you prefer).
>Thanks for filing the bug. As mentioned in my note to Vlad, this is still
>an outstanding POW which needs to be addressed once for each platform.
>The ideal time to do so is:
>
> - before 1.0
> - after the dialogs have settled down
>
>A dry run before 0.9 might be nice, though.
The 'dumpstrings' perl script shows how much longer than the en-US strings each
localized string is, BTW. This will probably be useful. (Though it only counts
*characters*, so IIIII is longer than WWWW.)
>>'en-US' users would have 'Letter' as the default size. Is there a bug
>report for
>>this?
>
>Two obvious hacks come to mind:
>
>1. Ask the native locale mechanisms on the OS.
If this information is available.
>2. Add this as an argument to the strings files.
Or a separate locale resource file. There are other things (defaults) that are
localizable too, and I think the strings file should just contain that, strings.
>On a related note, if we're going to add any more locale-specific info to
>the strings files like this, I'd also like to suggest that we also add a
>user-visible name for the locale here (which does NOT get translated).
>
> http://www.abisource.com/mailinglists/abiword-dev/00/March/0391.html
Good idea. This could be shown in the 'Select Language' dialog too (perhaps in
both translated and English?).
>This'll come in very handy when we start implementing dialogs to allow
>folks to pick languages.
>
>>> 7. You can cut & paste content to & from the clipboard.
>>
>>Yes, even with Unicode characters.
>
>Excellent! Does this work with other apps, too, or just inside Abi?
It works in other apps too. I tried copying to and from Word several strange
Unicode characters, and it worked perfectly.
>>But there are some bugs. En- and em-dashed (possibly other characters
>>too)
>are
>>saved as ordinary *hyphens*. If I manually edit the document to use
>– and
>>—, the document opens and the characters are displayed as en- and
>>em-dashes, respectively, but when I save it, they're converted to
>>hyphens. I guess the answer to question 8 should be 'no' or 'partially'.
>
>Ick. Please file a bug on this.
I will.
>>It's been a while (~a month) since I tested this, but Linux documents
>could be
>>opened correctly on Windows, and vice versa. I doubt this has changed.
>
>Excellent! I'm really looking forward to the day when this is true on all
>locales.
I haven't tested bidi support, though (this wasn't available in 0.7.13).
-- Karl Ove Hufthammer
This archive was generated by hypermail 2b25 : Thu Mar 01 2001 - 18:03:38 CST