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 Globalite http://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 Voorhis http://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 -~----------~----~----~----~------~----~------~--~---
