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)

The will_paginate plugin for Rails is one of the best pagination plugins I know of and I like the ease of using it. Instead of using Model.find, simply use Model.paginate(:page => x) and you’ll get back a collection that behaves like an array and can be displayed in views like any other collection. Additionally the returned collection has some new methods (like page_count and total_pages), which are useful to display pagination links. Installing the will_paginate plugin adds the pagination class method to all models; it even works with automatic finders: e.g. you can use Model.paginate_by_attr, which will paginate queries for Model.find_by_attr.

However, pagination can become tricky if you want to paginate collections returned by special queries…

Trying to paginate special queries gave me a headache for quite some time. As summarized in one of my previous blog posts “Paginating special queries”, custom finder methods do not work without problems if you use the will_paginate plugin.

There are several plugins that make life easier when you need custom finder methods to do special queries in your models. Widely known are scope_out and scoped_proxy. Both of them are great plugins with different features, but unfortunately neither of them work out of the box with pagination.

Some days ago, Nick of Pivotal Blabs brought back to my mind, that there’s another plugin called HasFinder. HasFinder basically works like scope_out and scoped_proxy and combines advantages of both plugins. Besides the basic idea to define different scopes for an ActiveRecord model, you can also access methods (finder) in nested scopes that exactly behave like ActiveRecord associations do. Additionally, HasFinder works out of the box with will_paginate.

Head over to Nick’s HasFinder article to find out more about it. HasFinder is available as a gem or can be installed as a plugin from SVN. Great plugin, Nick.

Update 2008-04-02: HasFinder functionality will be included in Rails 2.1, called named_scope