On 03.07.2009, at 8:43, Dan Kubb (dkubb) wrote:
> On Jul 2, 1:09 pm, Dirkjan Bussink <[email protected]> wrote: > >> Well, I strongly oppose a solution that doesn't allow the end user to >> choose the internationalisation library. Personally I don't want to >> be >> forced by dm-validations to use Rails i18n (I really don't like the >> API myself). > > Aside from my dislike of forcing a single i18n library on everyone, is > that if you ask any two developers what they need/want in one, you'll > get different and often conflicting answers. There's not really any > agreed upon approach to resolving this, which means to me there's > still room for innovation. Well, here is my point in support for I18n gem (which is bundled into Rails now): if we want DataMapper to abstract from particular internationalization API, we need to develop another API that will allow integrating with existing APIs. But I18n gem is actually such an API: it allows developing custom "backends" to do the translation. Even if you use Gettext in your Rails project, you could benefit from supplying Gettext-adaptor backend to I18n and have the ability to localize e.g. ActiveRecord error messages. My vote for I18n as a ready to use I18n engine abstraction API. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DataMapper" 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/datamapper?hl=en -~----------~----~----~----~------~----~------~--~---
