At the same time I agree with John Smith. For all practical purposes, HTTP content negotiation AKA request.accept_language is essential anyways, so it could as well be covered here. Would make a great piece of work even greater ;-)

You have a nil object when you didn’t expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.inject

# app/controllers/application.rb
config.i18n.default_locale = :en

Should be

# config/environment.rb
config.i18n.default_locale = :en

That is put it into the environment.rb not the application.rb

The list of ‘railties’ available for translation can be found here:

http://rails-i18n.org/wiki/pages/translations-available-in-rails

From there, just make a file with an I18n.store_translations call and all the messages you need to translate, and require it (either with a before_filter or in an initializer). This seems a little convoluted right now, I think the ideal would be to make a plugin that grabs a YAML translation file and makes the store_translations call based on that.

While the possibilites of the new I18n as far as multilingual applications go are very impressive, I think the first thing we need to do is develop a simple framework for people who just want to localize rails to one non-english language, using the new API. That would allow us to get all of the “translating rails messages” bit out of the way and allow people to focus on whatever specific translation their app requires.

http://groups.google.com/group/rails-i18n

I’m designing a web application that needs to be translated in English and Finnish. I am using the approach presented in this post to do the localization. However, when I try to display form error messages with I get a “can’t convert Array to String” error if I use any other language than English (default en-US).

I’ve tried to also create fi.rb -files in active_record, active_support and action_view -folders but this seems to not be enough. What should I do?

Then you can just set the locale in the controller filter: http://github.com/karmi/rails_i18n_demo_app/tree/master/app/controllers/application.rb#L13 (and even perform some check like `available_locales.include? user_submitted_locale`

Thanks Trevor for this great write-up!

Karel

A possible way to get around the require/params problem: Store the possible language options in an array or hash at startup. Match the user params against the array, if it exists in the array, require. Otherwise, decline.

I was thinking of using validates_inclusion_of to check that the language chosen was valid, and storing that as an value in the users table (as you would with a time zone).

Allowing a user selected language would mean you’d need to do something like this for each request, though, I believe. I’m also not sure if the languages should just be put into a single file and loaded all at once. I’m thinking that people won’t change the language much, though, so having separate files probably makes sense.

Anyway, we’re making progress at least :)