Hello there,

Been chatting with Sven Fuchs at #rubyonrails. My native tongue isn't english, so I've always needed localization. I created a localization plugin that translates column names and validation strings, Array#to_sentence, month and day names in Time/Date/DateTime#strftime and inflectors. Now that Rails core gets localization, my plugin is rather pointless. This is why I'm interested in contributing to the Globalize project, and here are my thoughts:

• AFAIK, Rails will not have localizations bundled with it. The only change is that every english phrase that's hardcoded in Rails is now easily translateable. I'm thinking that the globalize project can be (amongst other things) a repository for translations. italian.yml, german.yml etc.
• Globalize should be highly modular. This makes it easy to use globalize for the same purpose as my mentioned localized frontend plugin - single language apps thar aren't english. DB content translation and run-time language selection is not needed in these cases.
• The API needs to be very sensible. I haven't used globalize myself, I've never done a multi lingual app. I've seen some globalize-enabled apps, though, and the way methods are called on symbols makes me shiver. I haven't encountered that in any other ruby lib, let's just use methods like everyone else ; )
• Javascript! A rake task could generate a .js file that contains an object (or a hash, depending on how evangelic you are =P) that contains the localized strings. Perhaps also set a variable that returns the current language. The details needs to be figured out, but you should nevertheless have access to localizations from JS. Probably not localized content from the database, just static strings. Error messages when AJAX calls fails, for instance.

This pastie outlines some ideas I have on how the API could look.

Allright, that's all. sudo discuss!

--
August Lilleaas / leethal
Tlf: (+47) 915 28 701