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.
A while ago, I wrote about different methods in JavaScript to prevent spam harvesters from recognizing an email address. These methods work by placing a scrambled version of the email address into the page source so that a spam harvester cannot recognize it as an email address. Using JavaScript, the scrambled text is unscrambled and displayed as usual to human visitors. Usually, the "scrambling" is based on replacing characters of the email address with its hex-entities (Rails' mail_to helper does so if using :encode => :hex or :encode => :javascript). My theory was/is, that using hex-entities is not sufficient anymore nowadays, since they can be easily reversed with simple search-and-replace operations.
So I came up with the idea to use a scrambling method that cannot be easily reversed. I assumed that spam harvesters probably can decode hex-entities, but still aren't able to execute JavaScript. However since this was just an assumption, I started a simple test over the last 6 months to find out how good or bad the different scrambling methods perform.
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.
Just a quick note that this blog is now running Rails 2.2 and makes use of the new i18n framework. Although this site is completely in English, the same application is also serving another blog in German. Moving the blog application from ruby-gettext translations to Rails i18n was quite a bit of work since the i18n simple backend works differently and after all, I had to recreate all translation files.
In the end, it works very well and reliable. While working with i18n views, I had some small ideas for improving translation handling in views -- maybe I can come up with some minor improvements after thinking about it some more.
Here's a little helper that runs a git command on every repository found in subdirs. Put the following ruby code into a file called rgit, make it executable and save it to a bin directory, like /usr/local/bin:
Among my friends, it's not a secret that I personally don't like Java. During my time at the university, I had to deal with it for some courses, but somehow nobody could convince me to really like the language. With Ruby, it was the exact opposite -- I saw a few code examples, read some articles about it and I immediately started to like the language and its charming way of doing OO like I always wanted it to be.
When I discovered JRuby, I therefore didn't take it serious and overlooked its potential. Today, I'm starting to like JRuby. Why? Because JRuby is actually pretty cool. It runs code of my favorite language (Ruby) on a wide-spread and highly optimized platform (the Java Virtual Machine, aka JVM). You can use JRuby to run Ruby code without even knowing a single bit about Java -- but it runs on the JVM (which has several advantages as stated below).
The next version of Rails (which most probably will be version 2.2) will come with an integrated internationalization (i18n) API. Here's an overview of how this affects an application if you've used the gettext gem so far.
First of all, the new Rails i18n API isn't meant to completely replace existing localization plugins like gettext. More precisely, it's an API built into the Rails core to provide easier access for i18n plugins. The API, for example, makes it much easier to customize number, currency, date and time formats as well as error messages (e.g. in validations) and output of helpers like distance_of_time_in_words.
Google recently published an interesting tech talk about scalability of Ruby on Rails applications. Jason Hoffman from Joyent talks about DTrace and how they fixed latency issues observed in Twitter. In between, he's also telling some interesting thoughts on the Rails framework architecture in general.
In short: DON'T!
The long story:
Lately, I talked to a few people about using gettext in Rails applications and one of the most frequently asked questions was, why gettext behaves strange on strings at class level. My advice: don't use gettext at class level -- it logically makes no sense (at least not in Rails).
Building an ActiveRecord condition parameter can result in a lot of unattractive code if it needs to depend on various things. E.g. if you need to find records that match multiple criteria given by the user, you might end up writing a lot of code to do so.
Using a hash as a condition might work in some cases: