Recently I’ve been working on a plugin for Ruby on Rails that help me out when creating new Rails applications in Danish. Previously, when we’ve created Danish prototypes for our customers all the default Rails error messages were still written in English.
I generalized it for use with any language, and currently (with the help from contributors) it’s now available for download on rubyforge.
Currently supported languages:
- Dutch (thanks Jeroen Houben)
- Spanish (thanks Luis Villa)
- Swedish (thanks Olle Jonsson)
- Swedish Chef
- Pirate Talk (thanks Tobias Michaelsen)
The main reason why I wanted to support Swedish chef and Pirate talk is that I want to remind myself to have fun while coding. And of course it’s a plus that International Talk like a Pirate day is coming up at Sept. 19, arrrh!
What it does
This plugin modifies the following most used helpers for Rails
- Localized errors and error headings
- Localized monthnames on date_select etc. (changing the order of Y-M-D, where Rails allows)
- Localized distance_of_time_in_words
- Localized to_currency (but not changing the order of unit/currency)
- Simple pluralization also available in the lang-file (but currently only used for pluralizing “error”=>”errors” in local language)
- Uses standard Rails methods. In this way, there is no tedious rewrite of localization functions in your view files
There are some FIXME’s in the code and any help on the plugin is appreciated.
As I’ve written in the Rails Core group, this plugin does some work that I hope will be worked into the Rails framework for easier future internationalization.
An example: distance_of_time_in_words() are hardcoded and translated into at least 4 different l10n plugins. If it changes in Rails Core, ALL the plugins must be fixed to ensure that the new code is copied to the plugins.
Seen from the perspective of a localized app, there should be as few dependencies as possible, so making hooks available for localization is preferred. In the example above, the texts should be available as a variable (like the error messages in ActiveRecord).
This would be an ideal solution to some of the most important i18n related issues, and I’d like to know the view of the community on this point.
From my post “i18n-friendly, plugable Rails core” in the Ruby on Rails Core list.
It’s my hope that the Rails Core team will acknowledge that it should be easier to localize your application. (Today, many text strings and date/time/currency formats are hard coded and difficult to overwrite).