Since we’ve come up with I18n, that single “Ruby gem to rule them all”, we’ve always said we wanted new functionality to be tried out in plugin-land, giving it a good round of battle-testing and discussion. We also said we’d plan for another “round” of evaluating these things and considering to include them to I18n itself.

The I18n gem has probably been in production for long enough that we can be sure the API works well enough. Also, in release 0.2.0 internals were cleaned up quite a bit and the API has further consolidated.

So, my feeling is that we can start moving things to I18n that have proven useful in plugin-land – reviewing and reassessing their implementation and sticking to a modular design.

Here’s an overview of a few recent changes to the I18n gem library following these considerations.

For a lowlevel library like I18n small changes are big ones because so many users depend on it. That said two huge changes have made it into the codebase and thus we’re bumping the version to 0.2.0.

So, here are some details about this release.

When it comes to selecting a fullfledged Internationalization solutions for a Ruby on Rails application Globalize has always been amongst the first choices. Shipping with “batteries included”, solid support for Model translations and everything stored to the database it was an obvious pick in many project environments.

On the other hand Globalize had some problems like the fact that it actually limited the set of ActiveRecord features one could use for translated models, its original choice to use default strings as keys and the mere size of its shipped data – something that sparked the development of several other Rails I18n solutions announcing themselves as way more lightweight and down to the basics.

Now with the introduction of the new I18n API to Ruby on Rails (which will be released with Rails 2.2 pretty soon) this landscape has changed. Future solutions will comply with and build on this API and therefor can be made much more modular, exchangeable and lightweight.

We’re happy to announce Globalize2 as the first fullfledged I18n solution for Ruby on Rails compatible with the new I18n API.

This is a wrap-up of my talk about the new Internationalization API that’s included in Rails at the RailsConf Europe 2008 in Berlin.

You can also look the presentation as a Mac OS X Keynote file, HTML (click on the slides, give the images some time to load) and PDF (including notes) format here.

If you are looking for more resources about Rails I18n please refer to our project site and especially the wiki. If you liked my talk or find my work useful please recommend me on working with rails.

So far the ratings evaluations summary says that I’ve received 13 ratings with an average grade of 4.2 (scale is 1-5 stars) … which I guess I can be pretty happy with. If you’ve attended my talk and haven’t rated it, yet, please do so :-) You should find a link for doing that on the session’s details page here.

Also, unfortunately O’Reilly did not take any videos from the sessions apparently and I have missed to ask somebody to take photos myself. If you know of anybody who’s taken some photos please let me know!

There’s been so much going on in the Rails I18n space in the last couple of weeks that I haven’t got around to update any blogs about it. So, here are some notes.

Future versions of Rails will ship with a minimalistic, yet powerful I18n/L10n api baked in.

The following post is about technical api and implementation details. You can read more about the motivation and reasoning behind this work here.

So, it’s getting real. Our changes to Rails have been merged back into master and will be released with Rails 2.2.

We’ve started this project in September 07. A couple of I18n plugin developers gathered to implement a Rails core patch which should make our lifes easier. We agreed on the following goal:

“Our goal with this work is to eliminate the need for monkey patching Rails in order to internationalize an application. We want to achieve this by implementing a minimal, common I18n API that can be leveraged by all I18n/L10n solutions.”

Hey, just in case you missed this like I did: there’s a video of Saimon Moore’s conference session about Globalize at ”Ostrava on Rails” available online!

The video probably leaves something to be desired regarding the allover quality, but hey! At least you can now watch one of our star developers giving an introduction to Globalize on Rails and that’s pretty cool, isn’t it?

So, go and grab the video here: Saimon Moore’s conference session about Globalize.

Like Saimon mentions this in his conference roundup there are also videos of several other interesting sessions available like those of Jamis Buck (about, guess what, deployment with Capistrano) and Tobias Lütke (about how he got shopify to where it is today).

Sometimes you just want less noise in your log files, especially when your Globalize setup runs pretty fine and you don’t need it to tell you about every single move it makes: Globalize can be just too chatty then.

Joost Hietbrink thought this, too, and sent me the following code snippet. So you don’t need to suffer from Globalize’s chattiness any more :-)

This article is part of the series “Get on Rails with Globalize!” and like the two last installments it’s a catch-all list: this time we’re going to point out some unexpected behaviours, problems and other funny things. Nothing world-shattering, just some things that you’ll probably want to be informed about so you don’t run into any problems.

• I’m seeing lot’s of strange characters!
• Weird Currency parsing results
• Globalize WrongLanguageError on attribute read
• Globalizes screws my RJS (or: my IE6)!

I’ll edit and complete this list as needed. If you’ve found any other common gotchas concerning Globalize, please drop me a note!

This article is part of the series “Get on Rails with Globalize!” and like the last installment it’s a catch-all list: this time we’re going to get some really cool extensions, plugins and patches caught. Stuff that makes Globalize an even mightier tool by adding useful functionality or connecting it to other important tools:

• Multilingual URLs
• Get Globalize working with :include and no base language
• Translate your application while browsing it
• Localized, concise Rails URL helpers
• Get Liquid templates to play nice with Globalize
• Globalize time_ago_in_words method of Rails
• Multiple arguments to fetch

I’ll edit and complete this list as needed. If you know of a Globalize extension, a library, plugin or patch that you found useful and that would fit into this collection, please drop me a note!

This article is part of the series “Get on Rails with Globalize!” and it’s a bit of a catch all list of useful techniques, tips and tricks. Stuff that you probably don’t necessarily need in every project but that you should be aware of:

• Bridge Globalize and TZInfo
• Preload View Translations in Production
• Clear Globalize’s translations runtime cache
• Use nice predicated block helpers in your views
• Organize your translations through Globalize’s namespaces
• Alternative Storage Mechanism for Model Translations

I’ll edit and complete this list as needed. If you know of a tip or trick that you found handy and that would fit into this collection, please drop me a note!

Originally triggered by Jeremy Hubert I’ve posted some thoughts about more concise and transparently localized Rails url_helper methods last month.

Basically Jeremy nailed a problem that occurs as soon as you define a Rails route that includes the locale as the leftmost parameter: you now can’t use Rails’ url_helper methods in a reasonable DRY way any more! A reasonable solution was pending.

Plugins to the rescue. By the end of this article you’ll be able to choose between two different solutions to this problem.

Update: It’s worth noting that the following information has been updated in the follow-up article: Concise, localized Rails URL helpers? Solved (twice).

Recently Jeremy Hubert commented on my tutorial about routes setup for Globalize. In short he criticized that Globalize doesn’t provide a solution for transparently adding the locale to Rails url_helpers where needed. Instead of being able to say:

article_url(@article)   

You have to specify the locale for each and every call to an url_helper, like so:

article_url(@current_locale, @article)  

Needless to say that this does raise some eyebrows in the Rails community. So let’s see if we can come up with an acceptable solution here. This post describes some intermediary results.

In case that you’re interested in the Globalize plugin but you haven’t subscribed to the right blogs ;-) … let me link up some interesting articles for you.