CODEWITHSUNDEEP
phplocalizationmultilingualgettext
Gerben Jacobs
Gerben Jacobs

Reputation: 4583

What are the reasons to use or to not use PHP's native gettext versus a self-build?

To make my application multilingual I'm wondering if there are big advantages to GNU's gettext or if there are big disadvantages of building your own 'library'.

Also if 'build your own' is more advised, what are the best practices? Obviously they have to be stored in the database, I doubt I wanna work with flat files, so at some point I'm better off caching them, how should I go about this?

Upvotes: 6

Views: 1783

Answers (2)

mario
mario

Reputation: 145512

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.

Upvotes: 5

Htbaa
Htbaa

Reputation: 2309

Gettext is not thread-safe.

Before deciding to implement your own I suggest you take a look at Zend_Translate. It has native support for a gettext adapter, as well as TMX, CSV, INI, Array and more formats. It should also be easy enough to write your own adapter if your preferred format isn't supported, such as database storage.

Upvotes: 1

Related Questions