It has been quite a while that I created these two Rails plugins, but they still serve their purpose without problems even in newer applications. Since Rails plugins as a gem are much easier to maintain, I took some time to move these two plugins to gems. This makes them even more easy to use and especially more maintainable.

I’m talking about rails-i18n-updater, a plugin that merges and manages Rails core translations in your application — a helper that I don’t want to miss in any i18n-enabled application anymore. And css_naked, a simple plugin that disables all stylesheets during the CSS naked day event once a year.

Both plugins are ready for Rails 3 and work well with Ruby 1.9, btw.

Rails I18n updater

The rails-i18n-updater plugin does two things to an application. First, it adds a rake task called i18n:update to your applications. This task can be called to download the most current translation files for the Rails core. Second, it prepends these translation files to the I18n load path at runtime.

This means, that you don’t have to fiddle with Rails core translations anymore in your application. Things like date formats, weekday names, month names, time distances in words and ActiveRecord validation error messages are translated for you — and moreover updating them is as easy as calling rake i18n:update. Because the downloaded translations are prepended to your load path, you’re still free to override them in your own locale files.

This seems simple, but becomes really useful if you don’t want to do every core translation yourself and don’t want to manually merge core translation updates. To use the rails-i18n-updater plugin as a gem, just add gem 'rails-i18n-updater' to your application’s Gemfile (environments.rb for Rails 2).

rails-i18n-updater plugin: RubyGems Github

CSS naked

css_naked is a very simple plugin that just disables the stylesheet_include_tag helper during the CSS Naked Day event each year. Installing and using it is now as easy as adding gem 'css_naked' to an application’s Gemfile (environments.rb for Rails 2).

css_naked plugin: RubyGems Github

If you’re writing an i18n-enabled Rails application, you have to deal with the translation of your own application as well as with the translation of several Rails core strings (like validation error messages, date formats, and so on). You usually don’t need to translate the Rails core strings yourself, since there’s a big repository of user-contributed core translations you can pull into your application. However keeping this translations up to date in your application can quickly become cumbersome.

For this reason, I refactored the rails-i18n(*) repository a while ago and made it a Rails plugin. You could install the plugin to your application and it provided Rails core translations for you. Unfortunately it became annoying to keep the fork up to date with the latest translation changes since every rebase or merge was a pain because of the moved file locations.

So my latest solution is another small plugin called rails-i18n-updater, which does not contain the translations itself but downloads them from the above mentioned repository of core translations.

Rails I18N gives you a way to translate your views and easily switch between different languages. However, you still need to set the locale for each request, i.e. you have to choose a method to select the right locale for a request. This can be done in various ways, depending on how you perfer it to behave. Here are some examples.

1. by browser-setting
2. by toplevel domain
3. by subdomain
4. by manual selection

Since Rails 2.2 has been released last week, lots of people are beginning to translate their applications — or, at least, many people seem to prepare their applications for later translation by replacing strings in views with t() calls.

If you’re modifying your application to be i18n-ready, or if you’re creating a new multilingual application, here’s a useful guideline to remember: translate meanings, not words.

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).

The next version of Rails (which most probably will be version 2.2) will come with an integrated internationalization (i18n) API. Here’s an overview of how this affects an application if you’ve used the gettext gem so far.

First of all, the new Rails i18n API isn’t meant to completely replace existing localization plugins like gettext. More precisely, it’s an API built into the Rails core to provide easier access for i18n plugins. The API, for example, makes it much easier to customize number, currency, date and time formats as well as error messages (e.g. in validations) and output of helpers like distance_of_time_in_words.