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.

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!

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!

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.

Routes are one of the harder-to-grasp areas of Rails. How should you set up your routes for Globalize? Do you need to change anything at all?

As often, the short answer is: it depends. It might well be that you can leave your routes setup completely untouched. Probably they’ll need some easy touches though.

This article tries to provide a (slightly) longer answer and shows some of the basic options you have. (There has been quite some request for a howto on this topic, so I’ve decided to change the original outline of this series).

So, you know how to pipe data from the webbrowser through various library layers to a database and all the way back again. You know how to configure every layer of all those sophisticated web applications, frameworks, libraries, programming languages, ...

But now here’s this dammned static file that seems to get totally screwed somewhere and you’re already starting to pull your hair out because there’s no apparent reason.

Relax and step back. Look again. Sometimes things are simple, that simple that one doesn’t see the wood for the trees.

If you haven’t joined the masses yet camping in the front of the doors of the Globalize developers team, eagerly awaiting the Globalize for-1.2 release to get out of the doors … finally, time has come now.

Globalize is now fully compatible with the much celebrated Ruby on Rails 1.2 release! So get your party heads on, use your noise makers and start dancing!

Ok, I’m going to collect some gotchas, pitfalls, mistakes and traps relating to Unicode, UTF-8, character encoding in general etc. Hopefully this prevents myself and others from being bitten (again) or at least might help to find the culprid more easily.

So if you have any additions here: please let me know! You read that? If you’ve encountered some kind of common problem with character encodings, please, let me know! There’s a comment form to use below and you also can always send me a mail. Thanks in advance :)

Let’s start with some basic stuff …