> > > It seems the best bet is to leave the concern entirely outside rails > itself, until the current disparate efforts can be folded into a > single 'best practise'. Failing that, perhaps it's something where > there isn't a solution which suits 'most of the people most of the > time'. > >
There will never be a best practice because there is more than one problem to solve. But does this mean that Rails Core feels that it's OK for a growing number of plugins to override large chunks of Rails code? For this problem 'most people' means 'most il8n plugin developers' and 'people who need localization' of which there are many of both now. One could look at the 'prepend_view_path' option as a feature that was added specifically to ease the development of plugins. Why would a similar solution for changing error messages and other hard-coded strings in Rails be different, except for the valid point of having extra (though hardly complex or detrimental) method invocations? It's understandable to shy away from il8n because of its 'can of worms' nature. But what we're really talking about here is providing a simple mechanism by which plugins can access and change Rails error messages and hard-coded strings. Lumping that in with the rest of the il8n/il0n problems is a red herring. Perhaps it's time to lift the stigma associated with il8n and look at a specific proposal for how to solve this. Many other frameworks provide simple solutions to this without adding complexity beyond variable interpolation. Joshua Sierles --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
