Alright, that's exactly what I wanted to avoid... a long thread about how the core should deal with localization :(
I don't think the core team should adopt a .t method or another way of dealing with translation. That's really up to the plugin developers to decide. What I would like to see is simply a way of declaring your locale and when you call one of the usual method, instead of returning an English string you get something in your own language/culture. Nothing fancy, nothing specially designed to help l10n/i18n plugins but just to avoid patching the core methods. (extending is fine) -Matt On May 23, 10:52 am, "Kevin Clark" <[EMAIL PROTECTED]> wrote: > 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 Clarkhttp://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 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 -~----------~----~----~----~------~----~------~--~---
