Avoid creating multi domain modules

Every now and then, someone gets the idea of using several po directories in the same module, i.e. multiple po domains. While this is technically possible, it almost always turns out to be a bad idea in practice. There are several reasons:

• It confuses translators. Almost all other modules (99%) use a single po directory named "po", and modules that don't are bound to cause trouble, not at least because the po directory naming will be non obvious to translators. Remember, translators deal with hundreds of modules.
• It makes the module much more prone to errors. Translators may forget to add translations to all of the po directories and still add their language code to ALL_LINGUAS in configure.in, which will break the module badly. This happens all the time in multidomain modules.
• It unnecessarily complicates the module's Makefile setup.
• It is usually a sign of the module needing a split up in several smaller and independent modules for maintenance and release purposes anyway.

So please avoid multi domain modules. Either use a single domain in your module, or use several modules, each with their own domain.

Using external domains

If you want to use external domains in your application (like for language and country names), please follow best practice:

• If your module includes several translation domains, read the intltool README which contains important instructions on how to achieve that so translation status pages keep working

• For other things, just use the dgettext("translation-domain",...), but be sure to check that you also have bindtextdomain("translation-domain", PATH-FOR-translation-domain) if it's different from where your translations are otherwise installed (eg. check this during configure, so that app installed in /usr/local will find translations in /usr)

• Language and country names: use iso-codes package (see what eg. Epiphany does). For those who want it short and simple, domains to use in dgettext calls are "iso_639" and "iso_3166"