One of the added features between Gimp 1.0 and 1.2 is the ability of Gimp
to use the user's native language. It might not be obvious to all here,
but most people in the world actually don't speak English, especially
English laced with terms from the computing and imaging jargons.
These people nowadays prefer proprietary OSes and packages since these, at
least, make the necessary efforts of adapting to their language.

Alas, i18n is lagging, especially in plugins.

It is very easy to mark a plugin for internationalization. The author of
the plugin needs not do any translation work himself; he only needs to add
a few hooks to his code, and maybe add some comments to ease the burden of
the traductor.

I remind all that Gimp is always compiled with English in. i18n loads
dynamically message translation files.

Here's a quick summary on how to internationalize plugins.

[Refer to, say, plug-ins/common/decompose.c for examples.]


I/ #include "libgimp/stdplugins-intl.h"

and a call to INIT_I18N() to the query() function
and a call to INIT_I18N_UI() to the run() function.

II/ Mark all strings in the program with either _("string") or
N_("string"). _(xxx) means "mark xxx as translatable" and "translate it on
the fly". N_(xxx) only marks xxx as translatable.
gettext(xxx) translates xxx on the fly. _() and N_() are macros.

Here's some explanation: i18n with gettext is a two-step process:
1. xgettext extracts from the source code strings marked for translation.
   It outputs a file containing the untranslated strings to that
   traductors know what to translate.
2. When compiled with i18n enabled, the program loads a file containing
   the translations, then looks up strings as needed in that file.
The logical consequence is that if you put strings into a static array
like const char *messages[]={"Xxxx", "Yyyy"} and you want to translate
it, you have to replace it by:
const char *messages[]={N_("Xxxx"), N_("Yyyy")} and replace uses of
messages[i] by gettext(messages[i]).

III/ Some messages shouldn't be translated at all. Error messages that
refer to internal Gimp structures are anyway not understandable without
reading the source code, which itself requires knowledge of technical
On the other hand, you might want to do the following: make up the message
using a sprintf-like function
_("Internal error: %s"), "ttt->iorkw<5, underflow in getmunchkinsize()".

IV/ List your file in po-plug-ins/POTFILES.in

Have I forgotten something?

David Monniaux     Tel: +33 1 44 32 20 66    Fax: +33 1 44 32 20 80 
Laboratoire d'informatique de l'École Normale Supérieure,
45 rue d'Ulm - 75230 PARIS cedex 5 - FRANCE

Reply via email to