Why not have RoR define a reference set of modules and class (call it i18n for now) whose API implements the most basic i18n methods with no real functionality? Then the plugins could flesh out the functionality. I know this is pretty simplistic, but we need to start somewhere. As RoR evolves, the hooks could be strengthened, but at this point even one or two basic hooks would be a great start. I would envision i18n's submodules being included in the standard RoR frameworks and handling string translation (a la .t), error message translation, model translation, locale initialization, time zone determination, template selection, currency/time/date/number formatting, etc.
Key points: 1. API hooks need to be in many, many places 2. API hooks need to be in places that are currently deep within RoR undocumented code 3. We can start small -just one or two hooks. 4. Rails Core need not define any new functionality behind the hooks -they can effectively be no-ops that aim to replicate the current functionality. 5. For testing, a special Rails Locale can be defined so that test assertions based on translatable output can be consistent on any platform. The Rails locale would be the only locale effectively supported by the default (no-op) i18n implementation. Other implementations should mimic it for test compatibility. On May 22, 3: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 rubyonrails-core@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
