+1 I don't want to get into details yet, but I agree that the main issue is agreeing on a standard for view translation that all plugins will have to support. In Globalize, this would be: 'Validation Error'.t, instead of simply 'Validation Error'. The idea would be for Rails core to overload String#t with a method that simply returns the original string, i.e. a no-op. The end user could then choose to use any i18n plugin he wants, and everything would be available for translation with no monkey-patching needed. This in itself would be a huge step, and I don't see a lot of downside. Localizing dates and countries could also be done much the same way.
If we agree that this is a good idea, we can start discussing standardization details. Josh Harvey Globalize Dev On May 22, 10:38 am, Matt Aimonetti <[EMAIL PROTECTED]> wrote: > ActionView and ActiveRecord have hardcoded English strings which make > using Rails in a different language a bit harder. > > ActiveRecord has hardcoded error messages, and ActionView has many > helpers rendering English strings, or localized content in English for > the US. > > Here are some examples: > > Date helper: > distance_of_time_in_words > number_to_currency > date_select > > FormOptionsHelper: > country_options_for_select > > Time and Date object > > While many plugins monkey patch rails to offer core localization, I > feel that we should find a simple localization solution for the core > methods with English localization only. > > I'm not talking about UI localization or Model localization but simply > offering an option to use Rails builtin methods in another context > than North America. I'm not trying to fight for a i18n/l10n solution > for Rails developers since I know we all have different needs and > that's why many people came up with different plugins. > > I do understand that this question raises at least 4 issues: > - how to deal with pluralization? > - how to deal with different grammar and dynamic variables? > - how to setup a locale, and what format to adopt? > - how to create/maintain core localization? > > Here is what I think about the above issues: > > Pluralization: > At the moment, the core team doesn't use pluralization in their hard > coded English strings, and I believe most people would prefer to see a > pluralization error instead of an error message in English. > > Grammar: > The syntax changes from one language to another and you can structure > sentences in the same order. I believe it can be easily done by > passing one or many variables to the translation. > > for instance (inspired by > Globalitehttp://svn.aimonetti.net/public/plugins/globalite/trunk/ > ): > :localization_key.translate({:who => 'Matt', :when => 'Time.now'}) > > The translator could use :when and :when in its translation in > whichever order and wherever he wants. (obviously the 'macro' would be > replaced by the passed variable) > > Locale: > Locale is a more touchy subject since if the core lets you define a > locale for an user or for the framework, it also mean that most i18n/ > l10n plugins will use that same value. However, looking at the actual > Rails plugins, none seem to agree on a standard. In Globalite I > decided to use the following format (used on a lot of other projects): > US English locale would be en-US. Locales are specified by RFC 3066 > and consist of two parts. The first is an ISO 639 language code and > uses lowercase letters. The second is an ISO 3166 country code in > uppercase letters. > In the case of Globalite I let the user set only the language and the > locale becomes en-* for generic English. This is a personal choice and > I'm not sure I would recommend to do the same in the core. I had a > discussion with Jeremy Voorhishttp://www.jvoorhis.com/from Globalize > during the last RailsConf and agreeing on a standard for a locale > might be the only real issue with localizing the core. > > Create/maintain core localization: > I personally think that localization should be included in the core > and maintained by the core team. Obviously they wouldn't be able to > translate the core themselves. > > My 2 cents worth, > > m|a --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
