> Thus, I think we should - at least for the next couple of months, > maybe for a really long time - collect this data, custom backends etc. > in a central place, make it easy to find and install, but not ship it > with Rails itself. > > That said, this is just my personal opinion ... we explicitely did not > want to decide on this matter without asking Rails core about this. So > we're really interested in what the community thinks about this.
I agree with this sentiment, but for slightly different reasons. We're not qualified to make the judgement calls, and it shouldn't be tied to our release timetable. If you add up all the languages people on the core team speak, it's more than 1, but probably less than 5. we're in no position to judge between two competing translation patches for pashtun or gulf arabic. Or to apply a patch which purports to correct a spelling error in the simplified chinese translations. It also ties the releases of fixes and updates to translations to the rails release schedule, if we have to push out a point release do we wait for translators? If the translations have a bunch of bugs but we're waiting for a new branch to land, do we hold off the releases of the translation fixes? I think for now the easiest option is just to keep them seperate, but perhaps provide a rake task or a standard way for plugins to contain translations. -- 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 [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 -~----------~----~----~----~------~----~------~--~---
