Is it possible to auto-extract strings like Heckle? Doing so it would be very easy to lookup for translatable strings and no change to core would be needed.
Marcello On May 23, 12:36 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > +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/fromGlobalize > > 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 -~----------~----~----~----~------~----~------~--~---
