Subject: Re: POW -- which locales Just Work?
From: Vlad Harchev (hvv@hippo.ru)
Date: Thu Mar 01 2001 - 06:09:52 CST
On Wed, 28 Feb 2001, Paul Rohr wrote:
> This weeks' project commemorates the recent addition of our 25th (!!)
> localization of AbiWord, by asking the pesky question:
>
> "Yeah, but do they all Just Work?"
>
> As such, it's a perfect task for the army of folks who use the product in
> something other than my native locale (en-US).
>
> scope
> -----
> Your mission, should you choose to accept it, is to test AbiWord in one or
> more of the following locales to figure out whether it Just Works, in *all*
> of the following ways:
>
> 1. Without any manual configuration, AbiWord automatically recognizes and
> honors your platform-specific locale settings. Among other things,
> this would mean invoking the appropriate input method(s), if any.
>
> 2. If set, we should also honor any locale overrides in the system and user
> preferences files.
>
> 3. On launch, the entire application user interface (menus, toolbars,
> dialogs, and messages) is properly localized. None of the dialogs have
> truncated labels.
Why are you talking about truncated labels? I know a gtk bug that caused it,
have fixes (and even pushed them into gtk) - but this problem only appears on
non-latin 8bit locales provided user killed their /etc/gtk/gtkrc.$LANG.
> 4. You can type in the appropriate language. Without swearing. ;-)
>
> 5. Spell check Just Works too, provided you've installed an appropriate
> dictionary.
>
> 6. You can print what you've typed in a WYSIWYG fashion. This may require
> some twiddling with fonts.
>
> 7. You can cut & paste content to & from the clipboard.
>
> 8. The resulting document gets saved as Unicode, if necessary, rather than
> in some platform-specific charset. This file can be opened and read
> properly on a different platform. (For example, Russian documents
> authored on Windows can be read on Linux, and vice versa.)
From this sentence one may think that saving in unicode is a better approach
than saving in native charset. It's wrong - since the charset is specified in
the xml header, storing documents in any charset will work fine (as long as
importing system's iconv understands that encoding). All that is needed is to
detect "current" encoding (used when exporting to .abw) correctly on all
platforms (so correct charset name is written to xml header). It seems that
charset detection is properly implemented only on unix currently (I wish to be
wrong - I didn't examine non-XP non-unix code closel).
To the list of items to check, I would like to add the following:
* Fonts shipped by 'unixfonts' module are sufficient for using in that locale
(it's false for non-latin1 languages) and an URL where fonts for it could be
acquired from
> specific tasks
> --------------
> Unless some polyglot wants to test all 25 locales themselves, this task is
> likely to require coordination among a large set of people. Thus, it might
> be helpful for one such person to create a locale matrix (kind of like the
> existing feature and UI matrices) to record the status of each tested locale
> for the eight columns listed above:
>
> auto, override, ui, typing, spell, wysiwyg, clipboard, & export
>
> I'd be lying if I claimed that all eight columns would start out green for
> most existing locales. (Indeed, there are days when I wonder about en-US.)
> But that's not the point.
Should the results be posted here?
[...]
Best regards,
-Vlad
This archive was generated by hypermail 2b25 : Thu Mar 01 2001 - 07:02:21 CST