I’ve finally finished the reorganization of the language/translation code. Yay!

So, what does that mean, you ask? Fair questions:

• ZenMagick now can support the same locale file structure that gettext requires. It is not mandatory, though.
• Translation strings can be stored in either .yaml or .mo (compatible with gettext) files.
• Translations may be split into many files. However, in that case it is your problem to load those. The default behaviour is to load just a single translation map.

That means you can use the homegrown system just like before (with the only change that translations are not store in PHP code anymore, but as YAML hash map).

The code to handle .mo files is named pomo and is used in glotpress and also Wordpress. So far it has lived a quit live as plugin in ZenMagick, but today it moved into core for all to see and enjoy.

I haven’t decided what to do about the new admin UI. Right now the priority is to get it going at all. Once that is sorted it might really become an option to use a place like transifex to mange translations. In that case pomo would come in very handy, indeed.

I’ve been looking at potentially replacing the current string array based translation code with something more mainstream. One obvious candidate is gettext.
gettext has been around for a long time and is used in many applications. One particular downside is that it generally works with a single file for a given language/locale. Now this is great for an application where you have control over all strings. Obviously, this is not the case for ZenMagick. Looking a bit around showed that there are various solutions to handle this.
One particular good solutions is pomo. pomo is a thin layer on top of gettext. It allows to have multiple translation sources (which can be merged). Furthermore, and that might be the main benefit, it is pure PHP, so even works on systems where gettext is not installed.

One prominent application using pomo is Wordpress. I’ll have a play with it and try to write about any progress.