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.

The main difference between gettext and Rails i18n is the usage of translation keys. With gettext, you place full strings of the “master language” (usually English) into the views. With Rails i18n, you build up a hierarchical structure of translation symbols (like “sidebar.latest.title”) and associate them with real text in translation files. Currently there’s no tool to extract symbols used in views to assist you to keep translations complete (like rgettext does for gettext), but I guess helpers will appear soon.

For my translations, I used the i18n simple backend, which comes with Rails and stores translation strings in simply .yml files. However, the Rails i18n framework actually is much more than just translations in .yml-files. It allows translation backends to hook into the Rails core with a documented interface, which promises to be more stable and reliable than monkeypatching solutions (e.g. like ruby-gettext does). In theory, it should be possible to create an i18n backend that utilizes gettext — which certainly is still very interesting e.g. to upgrade existing applications or for large applications with many translators (since the gettext format is widely supported by a lot of tools and services).

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.

Video link

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:

1 conditions = {}
2 conditions[:orderno] = orderno unless orderno.blank?
3 conditions[:color] = color unless color.blank?
4 ...
5 Product.find(:all, :conditions => conditions)

However this only works for simple searches (where values are matched by equality). If you try to build a slightly more complex condition (like searching for a substring in the name of a product, or for products that are cheaper than a given price), a hash won’t work and you need to use an array for the condition. This usually leads to clumsy code that needs to assemble the query string and its parameters in the right order depending on the given criteria. However, by extending the Array class with a helper method, everything becomes easier and nicer:

A while ago I faced a problem with controllers for nested resources I wanted to reuse in different contexts (polymorphic resources). For example, I had a simple Todo model that is used to store tasks that have to be done. Having multiple users which are organized in teams, the goal was to have user-specific (personal) todos and team-specific todos. Obviously, both kind of todos could be handled exactly the same way (same controller, same views) – except that the context differs.

So here’s a way to use a single controller for a polymorphic resource.

During the development of some web applications in the past, I found myself using various techniques again and again on different projects. Here’s a collection of five things that I discovered over the time and that I found most useful.

• #1 – Pimp your rails console with colors, history and tab completion
• #2 – Using source annotations
• #3 – Using enum attributes with ActiveRecord
• #4 – Protect email addresses in views from being gathered by spammers
• #5 – Avoid sending messages to nil

If you put your email address on a public web page, you can usually be sure to get tons of spam from there on, because address harvesters will sooner or later visit your page and recognize the email address.

There are different solutions to prevent harvesters recognizing an email address. I personally don’t like the use of images to display email addresses or the use of feedback forms instead displaying addresses at all. These methods have a negative impact on the site usability, since a visitor wouldn’t be able to easily copy an email address to his email application anymore.

Another method is to scramble email addresses in a way that harvesters cannot recognize it. Using JavaScript, the address is unscrambled and displayed to a human visitor. Even though this is not a foolproof solution, it provides the best measure between safety and usability in my opinion – as long as you do it right.

So here’s an easy way to use scrambled email addresses in Rails views.

Yesterday, in my post about upcoming features in Rails 2.1, I wrote, that Git gets more and more attention in the Ruby on Rails scene recently – and this morning, I stumbled across a post from David, where he annonced, that Ruby on Rails itself is moving from Svn to Git.

That was a rather welcome news to me, since I personally use Git for quite some time now and have switched all my repositories to Git a while ago. However, some people seem to be concerned about Svn being dropped by Rails. But it’s not as bad as you may think, since this doesn’t mean that you have to move to Git as well…

Ruby on Rails 2.1 is almost here and there are several interesting features coming with it. Among many little details, performance optimizations and some bug fixes, my favorites are:

• ActiveRecord named scopes
• ActiveRecord dirty field checking and partial updates
• Built-in gem dependencies

After updating to the latest edge Rails via SVN today, my local development webserver suddenly started to respond with a 500 application error for every request. The mongrel console revealed:

NoMethodError (undefined method `file_exists?’ for #<ActionView::Base:0x2aaaac3eee10>):
/usr/lib64/ruby/gems/1.8/gems/gettext-1.90.0/lib/gettext/rails.rb:280:in `render_file’
/usr/lib64/ruby/gems/1.8/gems/gettext-1.90.0/lib/gettext/rails.rb:278:in `each’
/usr/lib64/ruby/gems/1.8/gems/gettext-1.90.0/lib/gettext/rails.rb:278:in `render_file’
/vendor/rails/actionpack/lib/action_controller/base.rb:1107:in `render_for_file’
/vendor/rails/actionpack/lib/action_controller/base.rb:841:in `render_with_no_layout’
:
:

Digging deeper, I found out that the method ActionView::Base#file_exists? has been moved to a different place in Rails’ Changeset 8683. Fortunately, fixing it is easy.