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

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:

 1 #!/usr/bin/env ruby
 2 if ARGV.empty?
 3   STDERR.puts "usage: #{File.basename($0)} <cmd> ..."
 4   STDERR.puts "  Runs git <cmd> in every repository found in subdirs"
 5   exit
 6 end
 7 dirs = Dir.glob('**/.git').map { |d| d.chomp('/.git') }
 8 dirs.each do |dir|
 9   puts "-> #{dir}"
10   Dir.chdir(dir) do
11     system 'git', *ARGV
12   end
13 end

I’m using rgit pull or rgit fetch every morning to retrieve the latest code changes and rgit push every evening to make sure all my changes get pushed to the server. rgit repack -a -d is useful to cleanup all local repositories.

Todo: git submodules should be filtered out. Currently, they are processed like normal repositories, which probably is not what you want.

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.

Video link

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

In a Rails application, an incoming request is routed to a controller instance, i.e. Rails creates a new object of a controller class for every request. To determine the language a page should be shown in, gettext needs information of the current request: the language is selected by looking at the Accept-Language HTTP header, the lang cookie, the lang GET/POST parameter, or whatever else you made it to use (e.g. a user setting or the TLD of a request).

In all cases, the selected language is determined by information from the request – information, which simply isn’t available outside an instance of a controller.

If you use the gettext helper method _ at class level, it evaluates once when the application loads and results in a fixed (usually untranslated) string being used for all requests. You need to use the gettext methods at instance level to make it work.

But… why does it work sometimes? Actually it sometimes works in development environment, because the Rails application is entirely reloaded on each request and therefore the gettext statement is effectively evaluated on each request.

So, a common pitfall of using gettext with Rails is, that everything seems to translate fine during development, but strange things happen on the production server. In my opinion, it’d be a good idea to let gettext helpers raise an error if used at class level in a Rails application. Maybe I should file a gettext feature request for this ;). (note that this only applies to Rails applications; in other Ruby applications, it’s usually perfectly fine to use gettext at class level since the language can be selected when the application starts)

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.