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 --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
On 8/23/06, Jesper Rønn-Jensen <jesperrr@gmail.com> wrote:> > 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.Indeed, Jesper. Thanks for surveying - these modifications seem reasonable and will make localization overrides easier and more predictable. Perhaps some of our localization plugin gurus can join heads to patch, test, and document each of these. Volunteers? jeremy --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
On 23-aug-2006, at 14:04, Jesper Rønn-Jensen wrote:> 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.I wholeheartedly agree but I would love to have Multibyte integrated first, after characters are working (i18n) it might be time to think about l10n. -- Julian ''Julik'' Tarkhanov please send all personal mail to me at julik.nl --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
On 29-aug-2006, at 11:29, Jeremy Kemper wrote:> Perhaps some of our localization plugin gurus can join heads to > patch, test, and document each of these. Volunteers?The Globalize folks should know better. Personally I would love to just have a number of hooks that you could use to override Rails helpers. Something along the lines of ActionView::load_helper_overrides(RussianHelpers) There you would be able to supply a module to the method call and your custom helper routines will be used instead of the built-in ones. Otherwise Rails has to assimilate Globalize and carry a whoppin'' lot of locale data around. -- Julian ''Julik'' Tarkhanov please send all personal mail to me at julik.nl --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
On 2006-08-29, at 08:01 , Julian ''Julik'' Tarkhanov wrote:> Something along the lines of > > ActionView::load_helper_overrides(RussianHelpers)I like this. Somethings just don''t work with simple format strings. For some languages, the way activerecord''s error messages are generated make them sound weird. The time_ago_in_words helper may result in fairly distinct constructs in different languages. Having overrides fixes all that. --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
On 8/29/06, Julian ''Julik'' Tarkhanov <listbox@julik.nl> wrote:> > On 29-aug-2006, at 11:29, Jeremy Kemper wrote: > > > Perhaps some of our localization plugin gurus can join heads to > > patch, test, and document each of these. Volunteers? > > The Globalize folks should know better. Personally I would love to > just have a number of hooks that you could use to override Rails > helpers.I may be mistaken, but I believe this is what the original poster proposes. These are simply the low-hanging fruit. jeremy --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
On 8/29/06, Julian ''Julik'' Tarkhanov <listbox@julik.nl> wrote:> > On 23-aug-2006, at 14:04, Jesper Rønn-Jensen wrote: > > > 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. > > I wholeheartedly agree but I would love to have Multibyte integrated > first, after characters are working (i18n) it > might be time to think about l10n.There is no cause to introduce this artificial dependency. Jesper has proposed some simple steps forward -- please consider pursuing rather than undermining this path. jeremy --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
Jeremy Kemper wrote:> On 8/29/06, Julian ''Julik'' Tarkhanov <listbox@julik.nl> wrote: > > I wholeheartedly agree but I would love to have Multibyte integrated > > first, after characters are working (i18n) it > > might be time to think about l10n. > > > There is no cause to introduce this artificial dependency. Jesper has > proposed some simple steps forward -- please consider pursuing rather than > undermining this path. >Jeremy, Julian. Thanks for bringing this up again. I do want to clarify (as Jeremy mentions), that there really are a few changes that we could all benefit from. Julian, I agree that real multibyte character support would be nice to have, but are you sure that it is an important issue. I mean, I''m fine with the support in my plugin (basically sets $KCODE = ''u'' and that''s it.) I have seen no problems on that until now (and I have done a few "string juggling" tests). Moreover, do you know if the problems you describe, will be solved with better unicode support in Ruby 2? Because if that''s so, you should be pushing on the Ruby mailing list. My own opinion is still that we should be able to modify Rails so that it''s easier to "override" for these purposes: More like setting new hashes with localized strings, and less overriding of entire functions because english texts are hardcoded. I''m looking forward to hear your opinion here, and like Jeremy I''m delighted to know if any volunteers are listening and reacting.... PS. I''m trying to look into it myself, but some of the code is not as easy to modify as much of it is still beautiful (but in an incosistent way as I described in my first post :-) /Jesper Rønn-Jensen http://justaddwater.dk/ --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
Patches already exist for the error_messages_for and datetime_select issues. They may need to be updated (or extracted) and resubmitted. Bob Silva http://i.nfectio.us/ -----Original Message----- From: rubyonrails-core@googlegroups.com [mailto:rubyonrails-core@googlegroups.com] On Behalf Of Jesper Rønn-Jensen Sent: Tuesday, August 29, 2006 11:52 AM To: Ruby on Rails: Core Subject: [Rails-core] Re: i18n friendly, plugable Rails Core Jeremy Kemper wrote:> On 8/29/06, Julian ''Julik'' Tarkhanov <listbox@julik.nl> wrote: > > I wholeheartedly agree but I would love to have Multibyte integrated > > first, after characters are working (i18n) it > > might be time to think about l10n. > > > There is no cause to introduce this artificial dependency. Jesper has > proposed some simple steps forward -- please consider pursuing rather than > undermining this path. >Jeremy, Julian. Thanks for bringing this up again. I do want to clarify (as Jeremy mentions), that there really are a few changes that we could all benefit from. Julian, I agree that real multibyte character support would be nice to have, but are you sure that it is an important issue. I mean, I''m fine with the support in my plugin (basically sets $KCODE = ''u'' and that''s it.) I have seen no problems on that until now (and I have done a few "string juggling" tests). Moreover, do you know if the problems you describe, will be solved with better unicode support in Ruby 2? Because if that''s so, you should be pushing on the Ruby mailing list. My own opinion is still that we should be able to modify Rails so that it''s easier to "override" for these purposes: More like setting new hashes with localized strings, and less overriding of entire functions because english texts are hardcoded. I''m looking forward to hear your opinion here, and like Jeremy I''m delighted to know if any volunteers are listening and reacting.... PS. I''m trying to look into it myself, but some of the code is not as easy to modify as much of it is still beautiful (but in an incosistent way as I described in my first post :-) /Jesper Rønn-Jensen http://justaddwater.dk/ --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
Bob Silva wrote:> Patches already exist for the error_messages_for and datetime_select issues. > They may need to be updated (or extracted) and resubmitted.Thanks Bob. I''d like to compare those patches with what I''ve found in LocalizationSimplified. Any chance that you can send any details/descriptions/url''s of the patches? /Jesper www.justaddwater.dk --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
Off the top of my head, I know that ticket #3811 has the fixes for the date stuff. That patch won''t be applied as a whole, but some of the individual fixes could be extracted and applied. For the error_messages, I looked and I guess the patch I "remembered" was for my enhanced error messages for plugin I wrote quite awhile ago. Bob Silva http://i.nfectio.us/ -----Original Message----- From: rubyonrails-core@googlegroups.com [mailto:rubyonrails-core@googlegroups.com] On Behalf Of Jesper Rønn-Jensen Sent: Wednesday, August 30, 2006 2:10 PM To: Ruby on Rails: Core Subject: [Rails-core] Re: i18n friendly, plugable Rails Core Bob Silva wrote:> Patches already exist for the error_messages_for and datetime_selectissues.> They may need to be updated (or extracted) and resubmitted.Thanks Bob. I''d like to compare those patches with what I''ve found in LocalizationSimplified. Any chance that you can send any details/descriptions/url''s of the patches? /Jesper www.justaddwater.dk --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
On 29-aug-2006, at 20:05, Jeremy Kemper wrote:> please consider pursuing rather than undermining this path.I have other paths to pursue at the moment but I never wanted to undermine anything. Anyway, I stand corrected :-) -- Julian ''Julik'' Tarkhanov please send all personal mail to me at julik.nl --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---