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.

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

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!

Saimon Moore, one of the Globalize committers, pointed me to some terrific new Globalize functionality that most likely will make it into the next (for-1.2 that is) release of Globalize (which is expected to arrive pretty soon).

Saimon has described said feature himself in a blog article: Alternative implementation of Globalize Model Translations. But there’s a lot of code to read over there so I thought I’d sum things up a bit for you.

In Part 2 of this series you’ve seen:

• how to setup your application to use Unicode
• how to select and keep the current user’s locale
• how to translate entire templates (instead of individual strings)
• how to translate Rails ActiveRecord messages

In this article we’ll talk about some of the more advanced features Globalize comes with like:

• Abstracting ViewTranslations (sprintf-like usage)
• Singular and (multiple) plural ViewTranslations
• Globalize’s Currency class
• Piggybacking translations of associated models

In Part 1 of this series you’ve seen how easy it is to get up and running with Globalize. And you’ve seen what the most basic concepts of this multilanguage plugin for Ruby on Rails are, namely:

• .t for ViewTranslations (arbitrary, static text)
• the translates directive for ModelTranslations and
• .loc to localize your date, time and number formats.

In this article we’ll talk about some common questions on getting started like:

• How to setup your application to use Unicode
• How to select and keep the current user’s locale
• How to translate entire templates (instead of individual strings)
• How to translate Rails ActiveRecord messages

(Update 06/12/06.: mention ActiveRecord::Multibyte and explain MySQL/Unicode character-set)

So you’ve just found out that Globalize is the Rails plugin to bring multilanguage support to your applications? And you’re now looking for an instant overview of what Globalize can do for you?

Then here’s some good news for you. By the end of this article you’ll know:

1. how to install and configure Globalize and
2. how to use it to translate your Rails applications.

I don’t know where you’re coming from. But my former experiences using I18n solutions have never been so much fun.

I’ve been absolutely thrilled about Globalize. Imagine to just plug-in some extension and instantly being able to use simple, intuitive mechanisms to translate your (now multi-language) application. Wouldn’t that be wonderful exactly the way you’d expect a Rails solution for your most common programming problems to work?

Well, Globalize is just that. Globalize is a powerful, yet elegant and usable Rails plugin that’s here to help you with the translation and localization of:

1. arbitrary text like in templates (“hello world!”), mails, messages, etc.
2. model data like text that goes in the database as part of your ActiveRecord classes
3. stuff like dates, time, numbers, currency etc.

This series is here to help you get started and get the most out of Globalize.