# I18n friendly, plugable Rails Core **URL:** \ **Category:** Rails I18n\ **Created:** [August 23, 2006, 2:11pm UTC](https://www.ruby-forum.com/t/i18n-friendly-plugable-rails-core/66122 "2006-08-23T14:11:14Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Jesper\_RSSSSnn-Jens](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/96bed5/32.png) [@Jesper\_RSSSSnn-Jens](https://www.ruby-forum.com/u/Jesper_RSSSSnn-Jens)\ **Post date:** [August 23, 2006, 2:11pm UTC](https://www.ruby-forum.com/t/i18n-friendly-plugable-rails-core/66122/1 "2006-08-23T14:11:14Z")
Below is a copy of a discussion I just posted on Rails Core mailing list. The reason not to take the discussion here is that I think that we all agree on that Rails sometimes can be extremely difficult to deal with on i18n issues. Copy below. Please share your thoughts on Ruby on Rails Core list: [http://groups.google.com/group/rubyonrails-core/browse\_thread/thread/346cda3cd39e6fa9/c45615100e0f909a#c45615100e0f909a](http://groups.google.com/group/rubyonrails-core/browse_thread/thread/346cda3cd39e6fa9/c45615100e0f909a#c45615100e0f909a) ## /Jesper In my work with a simple localization plugin, i’m running into a lot of places in the Rails core, where text and other localization specific information is hardcoded. I’ve included some examples in the bottom of this post. It’s hard for an outsider to know, if the hardcoded values are a result of inconsistency in code, or “by design”. I hope that we can have a discussion here and see it in the light that most of the localization/internationalization actually have to re-code many Rails core methods. An example: distance\_of\_time\_in\_words() are hardcoded and translated into at least 4 different l10n plugins. If it changes in Rails Core, ALL the plugins must be fixed to ensure that the new code is copied to the plugins. Seen from the perspective of a localized app, there should be as few dependencies as possible, so making hooks available for localization is preferred. In the example above, the texts should be available as a variable (like the error messages in ActiveRecord). This would be an ideal solution to some of the most important i18n related issues, and I’d like to know the view of the community on this point. I mean, the modifications can be made relatively easily, but there is also (as always) a cost involved in changes: Of course, it will require a few lines of extra code that could in some cases cost cpu-cycles. I’m not the right person to judge how much overhead. The other cost I see is that some of the existing plugins (that override core Rails methods) will likely break. This cost I see as a healthy one, because it changes to something simpler. There is one point here not worth discussing here in this thread: UTF-8 support in Rails (because that’s closely related to Ruby and should be discussed separately). I’d like the discussion here to focus on the relatively small changes that can actually make internationalization much easier. Here are the examples I’ve found until now. I’d love to hear your comments and let me know if there are other examples here worth mentioning. ActiveRecord::Errors holds an easily configurable Hash of error messages. Very nice. But the actual header for showing the error messages is hardcoded in ActionView::Helpers::ActiveRecordHelper#error\_messages\_for This is inconsistent and could be fixed very easily, for instance by adding :header and :subheader to the @@error\_messages Hash. ActionView::Helpers::DateHelper#datetime\_select doesn’t support the :order option, which is inconsisten with the ordinary date\_select that does support it. This is like saying “we support localized dates but not localized datetimes”. ActionView::Helpers::NumberHelpers#to\_currency supports localization of :unit, etc. But does not support localization of ordering. An :order option should be added to make it consistent with date\_select etc. These are the most obvious examples I encountered while working on my LocalizationSimplified plugin. There are other places as well, but for now lets focus on the low-hanging fruit where we can easily make Rails core more i18n friendly. Jesper Rønn-Jensen [http://justaddwater.dk/](http://justaddwater.dk/) LocalizationSimplified info: [http://www.agilewebdevelopment.com/plugins/localization\_simplified](http://www.agilewebdevelopment.com/plugins/localization_simplified) ---
**Author:** ![Jesper\_RSSSSnn-Jens](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/96bed5/32.png) [@Jesper\_RSSSSnn-Jens](https://www.ruby-forum.com/u/Jesper_RSSSSnn-Jens)\ **Post date:** [August 29, 2006, 8:14am UTC](https://www.ruby-forum.com/t/i18n-friendly-plugable-rails-core/66122/2 "2006-08-29T08:14:27Z")
Jesper, I totally agree. I’d like to take it one step further. Hardcoded strings are a pain, even if you’re _only_ targeting english speaking people. It means you cannot change the defaults even if you want those to be English. How hard would it be to create a patch where all the hardcoded strings have been replaced by vars (with the same content)? Is there no way to do that and still maintain BC with other i18n plugins? Jeroen Jesper Rønn-Jensen wrote: > Below is a copy of a discussion I just posted on Rails Core mailing > list. > The reason not to take the discussion here is that I think that we all > agree > on that Rails sometimes can be extremely difficult to deal with on i18n > issues. Copy below. Please share your thoughts on Ruby on Rails Core > list: > [http://groups.google.com/group/rubyonrails-core/browse\_thread/thread/346cda3cd39e6fa9/c45615100e0f909a#c45615100e0f909a](http://groups.google.com/group/rubyonrails-core/browse_thread/thread/346cda3cd39e6fa9/c45615100e0f909a#c45615100e0f909a)