This document is copyrighted by Daniel Egger and distributed under the GPL which is available from your favourite GNU mirror. If you want to mirror this please tell me so I can notice you after I changed something....

If you do have any additional questions you like to add please consult either one of us...

Q: What is this fuzz all about i.e. why internationalisation?

A: Think about living let's say in Poland, you've got a computer and all you know about English is what you got from school. Wouldn't you like to have programms in your native language?

Q: How?

A: The GIMP is using a common system for creating localised programms called gettext which is an important system to todays UNIX architectures; it's even important enough to get integrated in glibc2 which is used on nowadays Linux systems.
If you are not familiar with this system and want to know more about it you may read the gimp/README.i18n file in the GIMP main distribution and the documentation of gettext which is available in the gettext-0.10.* package on your favourite GNU mirror (e.g. ftp.prep.ai.edu/pub/gnu/. Please Note: For developping anything with multilanguage support it is mandantory for you to get this package; the glibc support is sufficient for running those programs but not for developping them because there are no tools in it.

Q: What issues not mentioned in the README.i18n file do I have to care for?

A: The README.i18n file was written for developping the GIMP itself i.e. it won't tell you anything about plugin development which is the purpose of this document.

Q: How do I start?

A: Generally it's a good thing to create a new domain for your plugin which has the same name as your plugin itself. To achieve this you better copy the directory structure of an already localised plugin to minize the effort.
Then you include in your plugin and do an INIT_LOCALE("<name of your domain>"). Then you can mark strings for translation with N_("<string to mark>") and _("<string to mark>"). Which one you use depends on the situation: In structures you always use N_() but you have to care for a proper translation afterwards because N_() is a macro for no operation and thus does nothing but mark the string for catalog creation. Anywhere else you use _() which is a macro used for marking but also for translation i.e. the such marked string will be looked up at runtime and translated if a translation is available and otherwise just return the original string.

Q: What should I translate?

A: Generally spoken: Everthing that is visible to the user. It doesn't make sense to mark debugging messages for translation (maybe if plugin throws out debugging messages in Welsh :)) as do messages which are not important to a normal user like help messages for the internal database.
IMPORTANT: Do NOT ever think about marking menunames! This will cause severe problems where double menustructures is just a small one. We are working hard for a really solution for this problem but until then just leave it English, the plugin is at least in the right structure then.
With version 1.2 of the GIMP, the following rules should be enforced:

Wrap all messages and dialog texts in _() or N_() calls.
Do not wrap the HELP, BLURB, AUTHOR or DATE fields in the call to gimp_install_procedure.
Wrap the menupath into a call to N_(), unless it's a <Load> or <Save> plug-in.

Q: I do have severe problems. Whom may I consult?

A: You can ask your questions on the gimp-developer mailinglist (see http://www.gimp.org/ for information how to subscribe). You may also tell me your problem and I'll try to help you.