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 …

Lately I ran into an interesting issue with MySQL’s string comparsion that I haven’t seen before.

I’ve been setting up a simple vocabulary and grammar learning program for my spouse who’s started learning ancient greek a while ago. After she’s entered some testdata containing several funny looking ancient greek characters we saw that MySQL 4.1 seems to treat the following characters as equal when compared as VARCHAR:

Char.	Unicode Codepos.	UTF-8	Name
	U+03B7	206 183	eta
	U+1F75	225 189 181	eta w/ oxia
	U+1FC4	225 191 135	eta w/ persispomeni and ypogegrammenti

These characters are stored and retrieved correctly (which was a nice thing to watch, by the way). But when it comes to compare them to each other they are wrongly regarded the same character.

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.

Yes. I finally managed to finish the (first version of the) first part of my series “Get on Rails with Globalize”.

My idea with this write-up is to provide a complete summary of everything about and around Globalize – which IMO is the most complete, most elegant and (notably) most Rail’ish I18n solution available.

I thus started weeding through the archives of the Rails I18n and the Globalize mailing list (well, sort of, I needed to use my local archive to weed the latter because it’s badly missing an online archive so far), the Globalize wiki and several other ressources Google came up with.

I started my work on this series by the end of August, having been timed-out by obligations and stuff again and again. It also actually took me a while to collect and sieve out the relevant bits of information, check their up-to-dateness (e.g. of bug reports), sort and split everything into chunks and topics. But hey, I think this will have been worth that while. So … finally … here we go :-)

This article is a bit outdated and has been replaced by an entire series in the meantime: “Get on Rails with Globalize: a comprehensive writeup in 6 parts”.

This is the second version of my writeup about Globalize. My first attemp was too much a literal protocol of my actual steps – which haven’t actually mixed that well with a newbie intro to Globalize. So simply let’s start over.

I initially really shyed away from translating a pretty simple application just because of my previous experiences with t10n/i18n libraries that were nothing else but a big pain and hassle …

Ever felt the same? Then here’s some good news for yor. If you’re going to add multi-language support to a Ruby on Rails application I suggest you give Globalize a serious try.

The docs are a bit spare so at first it seemed to me that things don’t work as announced (or: at all). But once I understood how Globalize works everything went like a charm and was incredibly simple to use (at least for the very basic stuff I’ve tried so far).

So, I’ll put together how things worked for me.

Update: If you’re interested in reading about my adventures … this article might be for you. But if you’re interested in getting started with Globalize then please refer to this follow-up version of this article.

I first shyed away from adding multi-language support to folksr (my experimental voting application) ... mostly because of my previous experiences with t10n/i18n libraries and tools which were basically nothing else but a big pain.

Ever felt the same? Then there’s some good news for you. If you’re going to add multi-language support to a Ruby on Rails application I suggest you give Globalize a serious try.

The docs are a bit spare so at first it seemed to me that things don’t work as announced (or: at all). But once I understood how to Globalize works it went like a charm and is incredibly simple to use (at least for the mostly very basic stuff I’ve tried so far).

I’ll put together how things worked for me.