Well, each i18n plugin would override String#t to actually translate the validation message. Anybody who doesn't want i18n just uses Rails as usual. But anyone who does want to translate, just adds their localization plugin of choice, which now can automatically translate all of the Rails validation messages without having to alter any core Rails code.
Btw, when I say String#t, I don't mean that it has to be String#t -- it could be any agreed upon stand-in. Also, it could be a bit more sophisticated, to handle pluralization and string interpolation as Globalize currently does. Hope that helps, Josh On May 23, 2:24 am, "Michael Koziarski" <[EMAIL PROTECTED]> wrote: > > The end user could then choose to use any i18n > > plugin he wants, and everything would be available for translation > > with no monkey-patching needed. This in itself would be a huge step, > > and I don't see a lot of downside. Localizing dates and countries > > could also be done much the same way. > > I don't quite follow how adding a String#t no-op helps the > localization plugins? Could you explain that a bit more please? > > -- > Cheers > > Koz --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
