The gettext extension has some quirks.
- It keeps translation strings in memory, and thus can necessitate a restart (under the mod_php runtime that is) when catalogs are updated.
- The gettext API wasn't really designed for web apps. (It looks for environment variables and system settings. You have to spoon feed the Accept-Language header.)
- Many people run into problems setting it up.
- On the other hand there is more tool support for gettext.
You will almost always have less trouble with a handicrafted solution. But that being said, the gettext API is unbeatable in conciseness. _("orig text")
is more or less the optimal interface for translating text.
If you want to code something up yourself, I recommend you concentrate on that.
- Use a simple function name. In lieu of
_()
a few php apps use the double underscore __()
. Don't adopt any library that makes it cumbersome to actually use translated strings. (E.g. if using Zend Framework, always write a wrapper function.)
- Accept raw English text as input. Avoid mnemonic translation keys (e.g.
BTN_SUBMT
)
- Do not under no circumstances use the database for translation catalogues. Those texts are runtime data, not application data. (For a bad example see osCommerce.)
You can often get away with PHP array scripts lang/nl.php
containing nothing but $text["orig english"] = "dutch here";
, which are easy to utilize from whatever access method you use.
Also avoid pressing everything into that system. Sometimes it's unavoidable to adopt a second mechanism for longer texts. I for example used template/mail.EN.txt
for bigger blobs.