Subject: selecting localizations (was Re: id_ID translation update)
From: Paul Rohr (paul@abisource.com)
Date: Thu Mar 23 2000 - 10:44:29 CST
At 11:09 PM 3/23/00 +1100, Tim Allen wrote:
>I had an enquiry from someone a few days ago who wanted to use AbiWord in
>Indonesian. He had downloaded AbiWord from the AbiSource site, but had
>been unable to work out how to set up his local config files to make it
>use his language of choice. Can't say I blame him; it's not really obvious
>yet. I explained it to him, but presumably there are other non-English
>users in a similar predicament.
Actually, I'm not sure that predicament is all that widespread any more.
There's platform-specific code in the Unix, QNX, and Windows versions which
should automatically detect the user's locale and select the appropriate
localization. There's a prefs switch (useenvlocale=[0,1]) which can be used
to turn this behavior off, but we ship by default with it on.
There's a chance I may have broken that logic when we did the IETF renaming,
so here are pointers to the relevant methods:
AP_QNXPrefs::overlayEnvironmentPrefs()
AP_UnixPrefs::overlayEnvironmentPrefs()
AP_Win32Prefs::loadBuiltinPrefs()
Once that logic is working properly, the only time anyone should need to use
AbiWord mechanisms for switching languages is when they want to use a
language *other* than their default locale.
>One obvious solution is for me to just
>write the appropriate dialog to let the user specify the language, but
>that isn't likely to happen soon if you wait for me to do it :-).
This does sound like a worthwhile project, though. If anyone's interested
in messing with it, there are (at least) two gotchas to watch out for:
1. Rebuilding the UI. We currently load menus, toolbars, and keybindings
as early as possible in the frame construction process and then leave them
there. If the UI language changes, then these will all need to be rebuilt
to reflect the new language. (This is similar to the problem faced by
whoever implements the View Toolbars menu.)
Likewise, I'm not sure whether persistent dialogs would need to be reloaded
or not.
Overall, this can certainly be done, but it'll definitely involve some
long-overdue code refactoring in the framework.
2. GUI design. The trick is to make it easy for our target user -- the
oft-mentioned Church Secretary -- to figure out how to get their default
language changed when the entire UI is in a language they don't speak.
For example, by scanning the strings directory, it shouldn't be hard to
produce an Options pane which contains two controls:
- a checkbox to disable auto-detection
- a list box (or combo) which enumerates all supported languages
As a first pass, it'd be easy to just list the IETF names for each
translation.
However, it'd be a lot nicer if someone extended the Strings file format a
bit to also include the name of the language being translated. This way, the
available choices could look something like this:
English -- United States (en-US)
Espanol -- Espana (es-ES)
Francais -- France (fr-FR)
Doing the up-front work may be a bit of a pain, but the end result is a lot
friendlier than the combinatorial explosion of translating the names of
every supported language into every other supported language.
>A more
>immediately practical solution might be to include with the standard
>distribution a set of example config files (~/AbiSuite/AbiWord.Profile),
>one for each supported language, and a readme file for each language
>giving directions for where to put the file.
I'm not sure I have a better solution, but keeping a bunch of parallel
config files in sync sounds like a maintenance nightmare, because they'll
easily get out of date.
>Assuming no-one convinces me this is a particular silly idea, I shall
>hopefully during the next few days produce the files needed for
>Indonesian, leaving other languages to other people. One thing I'm not
>sure of, however, is for binary distributions, where would one put these
>files?
We currently don't install a language-specific README, but that's not a bad
idea. User-specific files installed with binary distributions are stored in
the abi/user tree, and built via the make canonical target here:
abi/src/wp/Makefile
To get included in the Win32 setup program, the files also need to get
mentioned here:
abi/src/pkg/win/setup/abisuite.ask
Hope that helps.
Paul
This archive was generated by hypermail 2b25 : Thu Mar 23 2000 - 10:38:58 CST