I guess we should keep on the discussion here instead of on Track. My points were:
- I'm ok with a translation hook that could be used by all translation/ l10n plugins. - String#t isn't clear enough and should be named String#translate or something more obvious (you can always use alias in your plugin if you want to) - the translation method should be 100% transparent for Rails and not change the existing pluralization system. - the translation method should be added to Symbol, Date, DateTime, Time - namespacing should NOT be forced by the API by reserving the Symbol class for that effect - this API should wait until after 2.0 Koz, the only way we have to localize Rails at the moment is to overwrite all places where content is localized in English only. For instance, I had to overwrite a lot of helpers to display a date, currency, ActiveRecord error properly in a different locale. Having a String#translate method for instance would create a simple hook we could use by extending this method. By default the #translate method would just return what was passed to it. However a plugin developer could decide to use localization files to translate the passed string. Each localization plugin deals differently with translation, interpolation, pluralization, namespacing, conventions, locales... I don't think there is one 'proper' way of doing this kind of things since it really depends on what you are trying to do. How many languages are you gonna support, one, 10, 50? Do you want to store the translation in the database or in files? Do you have a 'master' language or do you use translation keys? Do you want to organize your translation by namespaces? ..etc... Because of all these challenges, the guys from Globalize came up with this patch allowing a 'cleaner' hook into the core of Rails. My only worry is that this patch is too biased to their view of localization. The whole reason behind me writing the GlobaLite plugin is that Globalize was way to complicated for what I needed to do (at least in 90% of my projects requiring localization). (GlobaLite automatically "translates" rails core in the user language without worrying about database migration etc... However GlobaliZe handles database content translation.) To sum up mu thoughts, I'm 200% for a localization API/hook so we wouldn't have to monkey patch the core every time you guys change something. But honestly, having a diversity of localization solutions is awesome and I would hate to see this new API/hook forcing people to do things a certain and limit other developers. -Matt On Sep 30, 11:02 pm, "Michael Koziarski" <[EMAIL PROTECTED]> wrote: > > I just added a ticket (http://dev.rubyonrails.org/ticket/9726) with a > > very rough proposal of how a i18n plugin-agnostic api for rails may > > look like. I've added details in the ticket so all those interested > > please read that and provide as much feedback as possible. > > There are a few comments in the trac ticket which could do with > addressing. But I'm a little confused by the functionality of > String#t, that doesn't look like the no-op it should be? > > -- > 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 -~----------~----~----~----~------~----~------~--~---
