We used I18n for all our static contents, it’s a piece of cake. And all the client needs to do is to update that ymls files. For dynamic contents, we use Globalize2.

Here comes the fun part. Because you are most likely be working on an existing application, the bulk of the work is not making a nice back-end for multi-language objects, but it’s making sure the Rails application works correctly after we implement multi-language. It’s especially true when the application doesn’t have a complete test suite :)

Some things worth noting:

1. All occurrences of find_by_name will no longer work correctly. So grep that and modify accordingly
2. Basically all queries that use ‘name’ field, either on the select clause or condition clause, will also no longer work correctly
3. All routes that need locale path should also be added /locale/ to it
4. Javascript methods within a .js file that calls a Rails action and needs ‘locale’. Simply make a global Javascript variable for the locale and use that when necessary within the .js file
5. Javascript method that uses hard-coded words. Eg. “this.value = ‘Beware’”. Either we refactor it completely since it’s most likely we can do it another cleaner way, or we have to pull out that Javascript method from .js file to rhtml

If you need a partner in developing your next Multi-language Rails application, we may be able to offer a good help! Contact us at info[at]kiranatama[dot]com