{"id":444,"date":"2011-08-29T19:52:37","date_gmt":"2011-08-29T18:52:37","guid":{"rendered":"http:\/\/www.streppone.it\/cosimo\/blog\/2011\/08\/internationalization-i18n-with-mojolicious-and-template-toolkit\/"},"modified":"2011-08-29T19:52:37","modified_gmt":"2011-08-29T18:52:37","slug":"internationalization-i18n-with-mojolicious-and-template-toolkit","status":"publish","type":"post","link":"https:\/\/www.streppone.it\/cosimo\/blog\/2011\/08\/internationalization-i18n-with-mojolicious-and-template-toolkit\/","title":{"rendered":"Internationalization (i18n) with Mojolicious and Template Toolkit"},"content":{"rendered":"

In a previous post<\/a> I talked about this new Mojolicious<\/a>-based application that I've been working on, that btw was rolled out in production today (yay!)<\/p>\n

Classic I18N with TT<\/h3>\n

One of the required features of this app was "i18n", internationalization. To be less vague, the requirement was to present the UI in different languages. We're using Template Toolkit, so our templates need to have strings marked in a special way to allow translation to kick-in at run-time. Usually in TT you do this with:<\/p>\n

\r\n<html>\r\n \r\n<head>\r\n<title>[% l('This is the title of the page') %]<\/strong><\/title>\r\n<\/head>\r\n \r\n<body>\r\n<h1>[% l('Hello, world!') %]<\/strong><\/h1>\r\n<p>\r\n[% l('Some text here') %]<\/strong>\r\n<\/p>\r\n<\/body>\r\n<\/html>\r\n<\/pre>\n
so all the strings that have to be translated according to the user language have to be marked up with:<\/p>\n
\r\n[% l('<your string here>') %]\r\n<\/pre>\n
Enter Mojolicious<\/h3>\n
Mojolicious includes a built-in I18N<\/a> plugin that simplifies your life allowing the <% l('somestring)' %><\/code> syntax to work. That is, it gives you a l()<\/code> helper.<\/p>\n
Helper?<\/h3>\n
A helper<\/strong> is a method that it's available both as part of your controller object, and<\/strong> within templates.<\/p>\n
Back to Mojolicious…<\/h3>\n
In the example helper syntax I wrote <% l('somestring)' %><\/code> because that's Mojolicious default templating system syntax. However, under Template Toolkit, you can't use that syntax!<\/strong> You have to pass through an extra level, as in:<\/p>\n
\r\n<!-- This is my TT template -->\r\n[% c.l('<your string here>') %]\r\n<\/pre>\n
I'm not exactly sure why that c.<\/code> is required, but that's how it is.<\/p>\n
I18N workflow: extracting the strings<\/h3>\n
Everything would be fantastic, except there's one tricky problem. After you worked so hard on your TT templates, now it's time to collect all the marked up strings, presumably to build a .PO file to be shipped to translation agencies or whatever system you're using for that. More on that later.<\/p>\n
In the Perl world, there is an equivalent of GNU xgettext, which is xgettext.pl<\/code>. This tool is part of the Locale::Maketext::Lexicon<\/a> CPAN distribution, which is kind of "the standard" way to i18n in Perl. Or it is for us here anyway since we started building i18n for my.opera.com in 2008.<\/p>\n
The tricky problem is that even though xgettext.pl<\/code> understands quite a few syntax variants, it didn't understand [% c.l('string') %]<\/code>. After a few Perl debugger sessions, I managed to teach Locale::Maketext::Extract::Plugin::TT2<\/code> how to parse Mojolicious-style syntax<\/strong>. I knew that Clinton Gormley, the maintainer of L::M::Lexicon had a source repository for it on Github, so I forked his repository<\/a> and pushed my changes on a dedicated branch<\/a>.<\/p>\n
CPAN, Github and the Community<\/h3>\n
This is where the Github + CPAN model really shines<\/strong>. You're using a CPAN module. You stumble on a problem. Fix the problem. Find its repository on Github. Fork it, push your fix, and if you're lucky<\/strong>, you have your fix merged and out on CPAN the same day.<\/p>\n
This is what actually happened. Clinton got in touch the very same day I sent him the pull request and later pushed out the changes on CPAN. If you ask me, that's just awesome. I wish everything worked that way :)<\/p>\n
Closing the i18n workflow<\/h3>\n
Fixed the c.l()<\/code> problem, everything else was easier. xgettext.pl<\/code> allows you to collect strings from your code and templates and build a master .PO file with all the strings. Then msgmerge<\/code>, a standard GNU gettext tool, allows you to take the generated master PO file and merge it with any existing language-specific PO if any. If you don't have any, just copy the master PO file (usually called POT, or reference PO file) to <language>.po<\/code> and start translating.<\/p>\n
Last step is either:<\/p>\n