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
/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/
LocalizationSimplified info:
http://www.agilewebdevelopment.com/plugins/localization_simplified