Rails Internationalization- 1.8 vs. 1.9

I had the chance to demo a rails app at Dev House Boston on Sunday, and one of the questions I got was about making ruby1.8 speak Japanese. I remember this being a big deal for me at one point. There is so much talk of the internationalization in ruby1.9 that when I started my project, I used 1.9 for some of the string processing that I was doing.

When it came time to hook that code into an application, the obvious answer seemed to be sticking with 1.9. However, things didn't look as rosy when I found myself in dependency hell trying to make ruby 1.9 friends with rails, mysql, etc. etc. After applying patches, editing gems (manually), fighting with how gems and debian both want to rule package management (and reading a really long argument between debian developers about the topic, with no resolution), I finally got everything working (sort of). It still had a few hiccups that I didn't know how to deal with (which looked like they could expand into bigger issues), and at this point I was pretty much through trying to fix anything else. So I decided to switch back to ruby 1.8.

It's actually a lot easier than I thought it would be.

The database needs two modifications:

CREATE_DATABASE my_web_two_zero_development DEFAULT CHARSET utf8;

and

development:
adapter: mysql
database: example_development
encoding: utf8
username: root
password:

The global $KCODE should be changed in environment.rb to either "UTF-8" or it's short version like so:

$KCODE = 'u'

Concerning the string manipulation itself, ActiveSupport::Multibyte::Handlers::UTF8Handler has provided a solution with (string).chars.methods_of_death_such_as_length_index_etc.

But because my goal wasn't full on i18n, but rather just Japanese support, I found that a simple require 'jcode' in my enviroment.rb file gave me what I was looking for, providing methods like (string).jlength. Either one gets the job done when it comes to Japanese. It might be prudent to do some benchmarking or code delving to see if one is better than the other, but for my purposes, I found either to work fine.

I guess there are two things that I took away from this. First, I'm not sure why i18n was so hyped up for 1.9. I guess it was something for people to talk about, but it did obscure the fact that there are multiple simple solutions that will already solve a good deal of the issues in 1.8, but just maybe not as elegantly. Second, adding Japanese support for an app backed with 1.8 seemed impossible, until I tried it. So if my solution ends up being a too messy, as was the case with 1.9, it's probably time to reevaluate what I think is impossible.