Since we’ve come up with I18n, that single “Ruby gem to rule them all”, we’ve always said we wanted new functionality to be tried out in plugin-land, giving it a good round of battle-testing and discussion. We also said we’d plan for another “round” of evaluating these things and considering to include them to I18n itself.

The I18n gem has probably been in production for long enough that we can be sure the API works well enough. Also, in release 0.2.0 internals were cleaned up quite a bit and the API has further consolidated.

So, my feeling is that we can start moving things to I18n that have proven useful in plugin-land – reviewing and reassessing their implementation and sticking to a modular design.

Here’s an overview of a few recent changes to the I18n gem library following these considerations.

For a lowlevel library like I18n small changes are big ones because so many users depend on it. That said two huge changes have made it into the codebase and thus we’re bumping the version to 0.2.0.

So, here are some details about this release.

Ripper is a s-expression based Ruby Parser shipped with Ruby 1.9. There’s no documentation out there so trying to figure out what’s going on can be quite hard so I thought the following notes might help you get started.

Ripper is a Ruby parser that ships with Ruby 1.9. Ripper2Ruby is a library that generates a representation of Ruby code which you can modify and/or compile back to Ruby.

When it comes to selecting a fullfledged Internationalization solutions for a Ruby on Rails application Globalize has always been amongst the first choices. Shipping with “batteries included”, solid support for Model translations and everything stored to the database it was an obvious pick in many project environments.

On the other hand Globalize had some problems like the fact that it actually limited the set of ActiveRecord features one could use for translated models, its original choice to use default strings as keys and the mere size of its shipped data – something that sparked the development of several other Rails I18n solutions announcing themselves as way more lightweight and down to the basics.

Now with the introduction of the new I18n API to Ruby on Rails (which will be released with Rails 2.2 pretty soon) this landscape has changed. Future solutions will comply with and build on this API and therefor can be made much more modular, exchangeable and lightweight.

We’re happy to announce Globalize2 as the first fullfledged I18n solution for Ruby on Rails compatible with the new I18n API.

This is a wrap-up of my talk about the new Internationalization API that’s included in Rails at the RailsConf Europe 2008 in Berlin.

You can also look the presentation as a Mac OS X Keynote file, HTML (click on the slides, give the images some time to load) and PDF (including notes) format here.

If you are looking for more resources about Rails I18n please refer to our project site and especially the wiki. If you liked my talk or find my work useful please recommend me on working with rails.

So far the ratings evaluations summary says that I’ve received 13 ratings with an average grade of 4.2 (scale is 1-5 stars) … which I guess I can be pretty happy with. If you’ve attended my talk and haven’t rated it, yet, please do so :-) You should find a link for doing that on the session’s details page here.

Also, unfortunately O’Reilly did not take any videos from the sessions apparently and I have missed to ask somebody to take photos myself. If you know of anybody who’s taken some photos please let me know!

There’s been so much going on in the Rails I18n space in the last couple of weeks that I haven’t got around to update any blogs about it. So, here are some notes.

Future versions of Rails will ship with a minimalistic, yet powerful I18n/L10n api baked in.

The following post is about technical api and implementation details. You can read more about the motivation and reasoning behind this work here.

So, it’s getting real. Our changes to Rails have been merged back into master and will be released with Rails 2.2.

We’ve started this project in September 07. A couple of I18n plugin developers gathered to implement a Rails core patch which should make our lifes easier. We agreed on the following goal:

“Our goal with this work is to eliminate the need for monkey patching Rails in order to internationalize an application. We want to achieve this by implementing a minimal, common I18n API that can be leveraged by all I18n/L10n solutions.”

For a spam protection feature in a project I’m currently working on I started out specifying the behaviour of a filter chain that I was planning to implement. Specifically, I wanted to specify that the filter chain would call the filters in the expected order.

Looking at the RSpec documentation for expecting method calls on mock objects I didn’t found this usecase mentioned at first. It turns out to be pretty easy with RSpec mocks though.

#should_receive takes a block that (according to the documentation) is meant to be used to compute return values. This block is called within the specification’s scope so it can be used to track the method call order.

My initial spec looks like this (simplified for clarity):

it "runs the filters in the correct order" do
  log = []
  @default.should_receive(:run){ log << :default }
  @akismet.should_receive(:run){ log << :akismet }
  @defensio.should_receive(:run){ log << :defensio }
  @chain.run
  log.should == [:default, :akismet, :defensio]
end

Update

After some discussion on the RSpec users mailinglist Ashley Moran pointed out a more elegant solution to this which also uses the should_receive block:

it "runs the filters in the correct order" do
@default.should_receive(:run) do
  @akismet.should_receive(:run) do
    @defensio.should_receive(:run)
  end
end
@chain.run
end

Thanks :)

For a project I’ve been working on recently I needed a sortable javascript tree widget that allows to drag and drop tree nodes and serialize an ajax call on drop events.

I’ve googled for solutions but did not find anything that implemented the simple things I wanted in a lightweight manner. So I started to check out the Scriptaculous sortable tree option but no matter what I tried I could not get it behave.

A couple of frustrating hours of reading the code and comments on the somewhat sparse Scriptaculous documentation (no offense!) I gave up and decided to implement this myself.

Here’s the result.

… because it already has Engines for Rails 2.0.

You can file this in the category of “Doh!” and “Things: obvious, but missed” … at least that applies to me. Did you notice it?

I’ve just recognized that with todays Engines and Rails 2.0’s config.plugin_paths you can do exactly what John W. Long envisioned and called for one and a half year ago.

Just some quick notes about the safemode library I’ve been working on with the help of Peter Cooper recently. Rather than starting out with a Haml specific library Peter suggested turning this into a more widely usable tool and hacked his way to make it eat plain Ruby code as well as ERB.

Since I’ve cleaned up things a bit and started working on a Rails ActionView ERB handler so one could transparently use this library when rendering ERB templates with ActionView. Yesterday I’ve managed to render a blog index page (which I used as a sample app) through this handler for the first time.

So, Rails has added some great HTTP related features with HTTP authentication, ETagging and, of course, support for REST. These actually greatly help scaling our applications by moving to HTTP what really belongs there.

One similar feature that has been in Rails for ages is page caching which just saves the response to a file and lets the frontend server handle subsequent requests. For example Mephisto is known to be “fast as hell” just because it uses page caching for public, non-authenticated pages.

Unfortunately Rails page caching doesn’t work with authentication: if you have to authenticate your users you simply can’t use it.

For applications that target human users HTTP authentication might be of limited use anyways in many cases because it still opens up that ugly browser authentication dialog box that only die-hard HTTP geeks really like. On the other hand, when it comes to closing down an admin section for a blog, maybe that dialog is still a valid option for certain applications?

Also, these days it seems to be possible to get around that UI non-design with Ajax … so we might even be able to overcome this limitation. (Or maybe it it’s not, like Mislav told me at Euruko. I’d still have to actually try that stuff out. But anyways :)

But even if not, the ability to HTTP authenticate cached pages should be great news at least when it comes to web services that need some authentication but often times don’t need any “personalization” based on user preferences or whatever.

After some recent experiments I really think this kind of stuff is actually possible. And not only that, it’s even very simple to implement it in Mongrel and Rails as a proof of concept (which might not be sufficient for production, but see below).

For my intial speculations about the feasibility of a Haml safemode as an alternative for Liquid I got a bold 'No!'.sub(/o/){|c| c * 46} by Ryan Davis. Ouch! Also, Peter Cooper initially commented rather sceptically …

You guys were right that my first thoughts didn’t go far enough with just looking for certain syntax node types. But hey! There’s still hope. :)

In the meantime I’ve implemented an experimental attemp on a safemode plugin for Haml which takes a bit different approach and certainly does more to get its job done better.