Internationalization

Yes, rails sorely lacks this. I can't think of any other thing if this importance that rails is missing.

A good way to do (part of this) would be to add a .to_i18n method to all Strings. It would be used in views instead of .to_s . By default, it would just delegate to .to_s, but it could be overrideen to either do a lookup based on current locale.

The i18n lookup table could either be generic, or use reflection to treat different models and fields differently.

Another option is an i() method, similar to the current h() method.

Last, there needs to be a way to i18n the text in the templates, without needing to put it inside eruby tags. The designs which work the best for this normally surround the text with <i18n> tags - this doesn't seem to be in harmony with the rest of erb, though.

Also - we can't just bolt on i18n - there are also default messages for failed validations from AR, etc.

I'm using ri18n right now and I think it's the best solution. I'll try to propose something more complete when I get some free time (maybe weekend)

I've created http://wiki.rubyonrails.com/rails/pages/RailsLocalization to start drafting

Give a look to this : http://mir.aculo.us/articles/2005/10/30/localization-plugin

It would also be nice to have different storage formats/methods to choose from. The PHP pear module at: http://pear.php.net/package/Translation2 has some really nice things, like multiple storage methods. Maybe we could use that as an inspiration?

I don't think its a good idea to go and develop a whole new way of storing the translatable string (like in a .rb file, like most implementations of i18n in rails i've seen), when there is already the .PO format. And to be honest, i think even simply keeping each string in a row in the database, would be better than loading them from .rb files. Because keeping them in ruby-files makes it hard to parse and change them, unlike simple database storage or PO files.

Closing because there is no proposed patch.