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!

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

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

Ok, this is really a looong lasting itch of mine I wanted to scratch ever since I’ve learned Liquid templates for Mephisto.

Liquid still is (as far as I know) the only usable “safe” Ruby templating engine that one could use for themes/templates in an application like Mephisto. In this context “safe” means that you can allow your users to download and install themes from arbitrary sources.

Liquid is safe …

So, with Liquid you can still sleep at night without any worries that some bastard might have included a bit of code into a theme that sends your password files to the russian mafia, runs rm -rf / or whatever nightmare you like worse.

Liquid does a very solid job here and as such it earns respect. But … let’s face it: Liquid sucks, syntaxwise.

As a Ruby programmer you want a templating system that makes your templates easier to type and more intuitive to grasp than ERB, not worse! Maybe it’s really just me, but for me Liquid fails miserably in this regard.

Haml is sexy …

On the other side of the Ruby template engines universe lives Haml. A templating system that is that awesome that you can’t possibly toy around with it for more than 3 minutes without getting totally addicted to it. But Haml is an evaluating templating system like ERB and as such you can’t use it for themes from arbitrary sources.

So how cool would it be to combine the best of both? Obviously it’d totally rock. It would be as cool as Yahoo sunglasses in 1994 and as sexy as the Audi R8 in 2008 combined.

Just a short heads up that I’ve updated the will_paginate_liquidized plugin to work with the latest (Chrismas 07) edition of will_paginate.

Like its name says will_paginate_liquidized enables will_paginate to be used within Liquid templates. You can find more about it here: will_paginate_liquidized plugin project page.

I’ve just released a first version of the Google Analytics plugin for Ruby on Rails that I’ve done in the course of the offer to build custom plugins for Mephisto users.

You can grab the plugin and read more about it here: Ruby on Rails Plugin: Google Analytics (blue egg edition)

Eran Ben Sabat was the first to contact me about this offer and suggested that I could write a Google Analytics plugin which he was interested in.

By now there’s another interesting request by Thilo Thamm who asked for a plugin for allowing users to add blog posts. This sounds like another great idea for a useful plugin and I plan to tackle this one next.

I was totally thrilled how much fun it was to work with both Liz and Eran Ben Sabat on their plugins. So my offer still stands. If you have an idea for a nice plugin, don’t hesitate to drop me a note.

So, James Adam has published a preview release version of Engines for Rails 2.0 that I’ve helped to put together. Let me quote James from his announcement on the Rails engines mailinglists:

Just a quick note to let you know, should it be relevant, that we’ve readied a new release of the Engines plugin, revamped and ready for Rails 2.0, and would absolutely love for you to start using it and sending feedback about what’s broken, what’s missing and what could be improved.

image credits

When I recently started to help porting Rails Engines to Rails 2.0 I haven’t found a complete big-picture walkthrough for the Rails startup process.

There are some really useful resources about this (see the end of this article) but they are for Rails 1.2 (some things have changed quite a bit in Rails 2.0) and each of them only covers certain parts of the process.

Thus, I’ve taken some notes while reading to the Rails code and compiled the following guide from them.

This article intends to walk you through the startup process in a whirlwind-speedy way, yet sticking closely to the actual code. I’ve added links to the code browser on dev.rubyonrails.org so you can look at the code lines while reading this article.

Of course, any feedback, corrections or additions are highly appreciated.

Just a short note for those of you who are using my Mephisto Inverse Captcha plugin:

I’ve recieved some feedback that the way the plugin was implemented apperently caused problems in fcgi environments. I’ve simplified the plugin loading quite a bit and now it seems to work fine.

I’ve got it running here on my own blog, too, with Rails 2.0PR and Mephisto rev2983 and it continues to work like a charm :) Actually, I have no spam comments thanks to it.

If you further encounter any problems please let me know :)

I talked about why we need a better Mephisto tag cloud plugin recently and that it probably should use the Boldr plugin as a basis. Sadly nobody really seems to care about this at Boldr.net. Well, there’re more important things than building another tagcloud for Mephisto, right?

Thus I started to revamp a brand new tag cloud plugin for Mephisto which is now available in the Subversion Repository … and of course I really believe that it is the most sophisticated, customizable, standard-conform and overall awesome implementation of a tag cloud for Mephisto ;). Why, yes, obviously I’m a little biased, so judge for yourself!