ZenMagick in its current form supports both yaml files and pomo files to store language strings. While I think this is good it also creates problems that are, right now, unsolved.

The main issue is that you can’t mix both. With admin using pomo and storefront yaml this causes serious issues for plugins that have to work in both environments.

I’ve created a few tasks for 0.9.13 to track progress for these issues, but since then have come to the conclusion that concentrating on a single system would be much better. With that in mind I had a look at the symfony2 locale component. symfony also uses yaml, albeit in a more sophisticated form. Although that would possibly be all that is needed to get a single codebase for language strings going it leaves the issue of compatibility and the option to host/manage translations in an open shared environment (for example something like transiflex).

For that reason I think it would be best to concentrate on pomo. The code is all there, lots of resources exist to deal with .po and .mo files (poEdit, etc.). The only bit missing would be something that makes it easy for store owners to manage strings without the need to download and learn new tools. Raine pointed out a great looking WordPress plugin that does pretty much what we need.

So, rather than writing more code to try to support inferior formats it might be a lot more fun to try to port this plugin to ZenMagick and have the best of both worlds.

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.