Just out of curiosity, I took two of my recent Rails applications today and tried them with Ruby 1.9. It was surprisingly easy to make all tests pass without any warnings or errors. Rails 2.3 already has quite good support for Ruby 1.9. The main gotcha however was about file encodings. If you have source files which contain non-ASCII characters, Ruby 1.9 now needs to know which encoding the file was saved with. If you don’t specify the encoding for a file with non-ASCII characters, you’ll get an invalid multibyte char (US-ASCII) error message.

Rails I18N gives you a way to translate your views and easily switch between different languages. However, you still need to set the locale for each request, i.e. you have to choose a method to select the right locale for a request. This can be done in various ways, depending on how you perfer it to behave. Here are some examples.

1. by browser-setting
2. by toplevel domain
3. by subdomain
4. by manual selection

Since Rails 2.2 has been released last week, lots of people are beginning to translate their applications — or, at least, many people seem to prepare their applications for later translation by replacing strings in views with t() calls.

If you’re modifying your application to be i18n-ready, or if you’re creating a new multilingual application, here’s a useful guideline to remember: translate meanings, not words.