As it turned out, .po and .pot file generation based on the current string scraper code wasn’t too hard. In fact, the hardest bit was perhaps to validate the created files.

It’s not so easy to find usable gettext binaries for Windows.. I ended up using a package from CubicWeb. It does crash, but only after having done the bits I want it to do

So, now there is a new translation project ZenMagick with a component admin UI on trasiflex. So far I’ve created a (default) en_NZ and de_DE locale. Since ZenMagick uses default strings in the code the default locale is at a 100% – yay. German is at 0% :[

If you are keen to work on a different language, let me know and I’ll add it to the repository.

I should add that the code is still using the .yaml files that are also located in the locale folders. As long as there isn’t a useful translation I can’t really see any reason to switch yet.

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.