I understand that many people won't get use out of 't', but I think the extra work involved (we're talking about an extra charcter, and letting the people who care submit patches to clean up what's already there) is trivial in comparison to what is gained here. It means that i18n efforts can hook into rails core easily, without monkey patching large bits of code (which is inhearently error prone).
I think this fits into something that has minimal effect on the codebase at large, but has a very large gain for the plugin writing community. I think this effort, which isn't deciding on a specific way to do i18n, but only on a common helper method for it, is something core can do without picking sides. I also think this means that the arguments about localization of rails core are going to go away because people can solve their own problems easily. Wouldn't that be nice? No more threads about localization in rails core? Wouldn't it? ;) Kev On 5/23/07, Michael Koziarski <[EMAIL PROTECTED]> wrote: > > > 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. > > But String#t, or anything else, would be entirely redundant without > localisation code in rails right? Adding a bunch of method > invocations for no new functionality doesn't seem like a good trade :) > > > 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'. > > > > > 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 > > > > > > > > > > > > -- > Cheers > > Koz > > > > -- Kevin Clark http://glu.ttono.us --~--~---------~--~----~------------~-------~--~----~ 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
