i18n woes

[mjrauhal+linux gnome devel mappi helsinki fi]

Greetings.

As I've been doing and coordinating some finnish translation work, I've
come across two problems which I'd like to see solved with respect to
gnome i18n. In order of current annoyance:

Problem 1: Gnome programs for which there are no translations available
still use stock translations from gnome-libs etc, making the user
interface interestingly multilingual. This is obviously not very nice;
reminds me of the days of high school with Finnish Windows 3.11 with
English applications...

Suggestion: Provide, probably in gnome-libs, an utility function to check
whether there exists a message catalog in the current language for the
program's primary text domain or not. If no such catalog is found,
the particular application in question should revert to using the C locale
for all its messages.

(This functionality should IMO arguably be provided within the gettext
api itself, but it seems lacking, and I don't know if it would be a
good idea to try to cram it into the gnu implementation of gettext.)

If no better suggestions are given and nobody else takes the job of
writing this, I probably will, but not until next month. Of course,
all programs would need to be modified to use it, then.

Problem 2: Strings that are appropriately the same in English must
sometimes be properly translated into different strings in other
languages. The gettext api doesn't really handle this very cleanly -
as is admitted in the documentation.

Now, there are two ways to deal with the problem:
It can be circumvented, though not really cleanly - you'd need to create
a separate text domain for the problematic cases and use dgettext() to
retrieve those messages. 

Also, of course, there is the IMO even more kludgy but perhaps easier
solution to pad some strings with spaces or something, where that would
not cause other harm - for example, strings "Cell..." and "Cell... " could be
used when different translations in different spots are needed. It seems
that the gettext documentation suggests that something like this be
done in the problematic cases.

Now, while I don't really like it, the most realistic solution would
probably be the aforementioned padding. I assume problematic strings
would be best brought to the program's maintainer's attention and be
dealt with appropriately?

But anyway, while I'm at it, I would also present that it might be a good
idea to make a single text domain per application, not per package.
Although this would not completely eliminate the problem (for example,
translating gnumeric to absolutely proper Finnish is impossible in the
current situation), it would help in circumventing it. (Note: I have
not run into problems caused by this bundling yet, but I rather think
it's unavoidable that some day some translation team(s) will have trouble
that could be avoided by splitting the per-package message catalogs into
smaller parts). Of course, the added maintenance cost would have to be
considered before going into action, but seeing as I talked to a KDE
translator who said they'd had similiar trouble and consequently moved
to smaller message catalogs, and considering that KDE is ahead of gnome
in its translation work, it could be a good idea to take heed of the
problems they've already faced before we face them as well.

Any input or alternative solutions to the presented problems would of
course be appreciated. Apologies, if some of the issues are already being
taken care of and I just happened to miss them.

-- 
Mikko Rauhala - mjr@iki.fi - http://www.iki.fi/mjr/

PGP signature