Running Rails 2.2 with i18n

Posted by Andreas on Thursday, November 27, 2008 at 14:33 (CET)

Just a quick note that this blog is now running Rails 2.2 and makes use of the new i18n framework. Although this site is completely in English, the same application is also serving another blog in German. Moving the blog application from ruby-gettext translations to Rails i18n was quite a bit of work since the i18n simple backend works differently and after all, I had to recreate all translation files.

In the end, it works very well and reliable. While working with i18n views, I had some small ideas for improving translation handling in views – maybe I can come up with some minor improvements after thinking about it some more.

The main difference between gettext and Rails i18n is the usage of translation keys. With gettext, you place full strings of the “master language” (usually English) into the views. With Rails i18n, you build up a hierarchical structure of translation symbols (like “sidebar.latest.title”) and associate them with real text in translation files. Currently there’s no tool to extract symbols used in views to assist you to keep translations complete (like rgettext does for gettext), but I guess helpers will appear soon.

For my translations, I used the i18n simple backend, which comes with Rails and stores translation strings in simply .yml files. However, the Rails i18n framework actually is much more than just translations in .yml-files. It allows translation backends to hook into the Rails core with a documented interface, which promises to be more stable and reliable than monkeypatching solutions (e.g. like ruby-gettext does). In theory, it should be possible to create an i18n backend that utilizes gettext — which certainly is still very interesting e.g. to upgrade existing applications or for large applications with many translators (since the gettext format is widely supported by a lot of tools and services).

Tags ,
6 comments • Permalink

Related posts

6 comments

Gravatar
• iain wrote about 11 hours later:

I am still a bit doubtful if gettext will be able to grep all the translations out, mostly because the i18n framework doesn’t force you to use one single method like _() or t(). How can you scrape methods that perform a translation for you, like AR’s human_name and human_attribute_name?

If you have any ideas, please post them on the rails i18n mailinglist

Cheers!

Gravatar
• Andreas wrote 3 days later:

Probably, a translation for human_name and others won’t ever be automatically extracted (even gettext couldn’t do this well, since these strings usually don’t appear in a view. Gettext simply proposed all table columns for translation, which more or less worked well).

All that rgettext is doing, is to scan all erb/haml files and tries to find calls to _() and similar functions. It should be possible to create a similar tool that tries to extract t() calls and updates existing yml files with new keys. Maybe it wouldn’t catch every call (rgettext also doesn’t get some special cases), but it could be helpful for translating larger applications.

Gravatar
• Michael wrote 4 days later:

Hi Andreas,

just in case you’re interessted, i also decided to recreate my translation files for Daily Fratze. It was quite a lot work (three languages), but in the end, it was worth the stress.

Cheers,
Michael.

Gravatar
• Andreas wrote 4 days later:

Hi Michael,

I’m curious — how many strings are in your locale files and how long did it take you to rework everything? This blog app has about 170 strings and it took me about one afternoon to move everything from static strings to I18n. Another app that is still under development and uses gettext, has about 1100 strings. I’m thinking about converting them to Rails 2.2 I18n so that the app can run with Rails 2.2 but, I don’t like the idea of spending several days with boring view-rewriting.

Gravatar
• Michael wrote 5 days later:

Hey ho,
about 400 strings per locale, 1200 sum.

It took me about 3 days (and 2 nights) to get it all working.

First step was to take all 3 po files and to create ids accordingly. Than i copy and pasted the whole translations.

2nd step was to take the master and search in the project for occurences of the message text.

3rd step was to look for all combinations of _, _"", _’’, _().

I first tried to do this all together but that sucked big time.

Then i decided not to write a po to yml converter as i wanted to have some kind of “speaking ids”.

But to be fair, real fun looks different that rewriting that stuff. But i had so often problems with gettext (memory leaks, monkey patching ofter each rails release etc.), that i thought the time is well spent.

Gravatar
• grosser wrote about 1 month later:

finding all gettext strings is practically impossible, a far better slutions is simply using your test runs to find any word that was translated.

If a word is missing, a test is missing, solve both!

—> http://pragmatig.wordpress.com/2008/08/09/record-gettext-at-test-runtime/

Comments are closed