I wouldn't use the I18n gem. I don't think dm-validations even requires any internationalization. Internationalization should be a lazy process. By that I mean that dm-validations should emit it's errors in an abstract fashion. This is where rails' validations fail / made a mistake, hence all it's problems; this is being changed though for rails 3.
In my view the solution is: get rid of all the @@default_error_messages in dm_validations and only emit Error objects each which contain the field (not humanized!), the error symbol (like :absent, :blank, etc.) and the options hash used by the validator. Cheers Lawrence > I'm outside the main thrust of this discussion, but I'd like to pass a > comment. > > All the discussion so far seems to have equated I18N with text > translations. > > There's a *lot* more to I18N than translation; locale handling includes > currency formats, number formats, calendars, country/language codes. > There are ISO standards for country codes and language codes, and the > locale codes are a pairing of these two (sometimes with further > refinement). > > Please don't forget the big picture! > > Clifford Heath. > > On 05/07/2009, at 11:22 PM, Maxim Kulkin wrote: > > >> 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 -~----------~----~----~----~------~----~------~--~---
