This post originated from an RSS feed registered with Ruby Buzz
by Robby Russell.
Original Post: Rails i18n Gets a Mailing List
Feed Title: Robby on Rails
Feed URL: http://feeds.feedburner.com/RobbyOnRails
Feed Description: Ruby on Rails development, consulting, and hosting from the trenches...
Last month, Jeremy gave a presentation up at Canada on Rails on Internationalization and Ruby on Rails, which showed the audience that you could use the Globalize plugin to provide i18n support to your Rails application. But wait, Rails doesn’t include native support for i18n. Why not? This is actually asked quite frequently on the Ruby on Rails mailing list and has been an anti-Rails argument point for quite some time.
So, why doesn’t the Rails framework have built-in i18n support? There is actually an easy answer to this.
One Size Does Not Fit All
I look at i18n much in the same way that I view authentication. Each application has it’s own set of special cases and requirements. The acts_as_authenticated plugin might work great but what do you mean it doesn’t authenticate against a LDAP server? Why doesn’t it have a complicated ACL schema? This is where you are left to keep searching for another available plugin or roll your own. Often times, it’s quicker to do things the way you need them to work than to search, review, implement, and test a plugin that someone else wrote. However, there is good reason to use plugins… especially when you become comfortable with them and begin extracted plugins from your application that you can reuse in other applications that you develop.
With internationalization you will find yourself reviewing numerous options that have been developed by the Rails community. People ask on the mailing list, “Will Rails core include i18n support?” No. Why not? Well, there isn’t one solution that solves all problems. They each have their pros and cons. At PLANET ARGON we are using the Globalize plugin for every project that requires i18n support, but we have talked to others who find it to be too much for what they need. It’s a matter of the context in which it is needed. For example, the applications that we have been developing that require i18n support went beyond just needing to have various labels, headers, and application text be available in multiple languages. The applications required that all content have different translations. For example, a biography of the Brasil soccer team has 18 translations that Globalize allows the applications administrators to manage. Other i18n solutions use the gettext/text file approach, which doesn’t solve the problem that we were faced with. Globalize works great with ActiveRecord and we’ve been using it with PostgreSQL with great success.
As the Rails core team isn’t aiming to solve this problem… much like I don’t expect them to solve the problem of interacting with Legacy systems… it pushes the responsibility on developers to make educated decisions on what will solve their problem. However, when there are a good number of i18n options available, how do you know which one to use?
Help is on the way, as Martin Bernd Schmeil has started a mailing list for those who wish to talk more about i18n and Ruby on Rails. If you’ve had experience working with i18n and would like to help those who are seeking the right solution for their specific needs, you might consider offering your assistance on the mailing list.
Previous Topic
