DataMapper needs a I18n support and this discussion is intended to
come up with the approach to use in DataMapper.
Main question: what I18n API to use ? Should it be existing API or
custom API to abstract it and provide adapters for third-party APIs
(like GetText or Rails' I18n gem).
Also, where DataMapper needs I18n support ? The most obvious answer -
validation messages. But what else ?
I started the development of a I18n extension a few months ago, I believe it's the way to go, even talked with Dan Kubb about it but I was taken away by a new job, so I didn't have the time to finish it. I hope to have time to do that soon, but I'm not sure when :( I really wanted to finish it, and it had a lot of features already. I was unable to follow the recent developments, so I'm not sure it will be compatible anymore. I'd like to participate, just need to squeeze some time.
> I started the development of a I18n extension a few months ago, I > believe it's the way to go, even talked with Dan Kubb about it but I > was taken away by a new job, so I didn't have the time to finish it. > I hope to have time to do that soon, but I'm not sure when :( I > really wanted to finish it, and it had a lot of features already. I > was unable to follow the recent developments, so I'm not sure it > will be compatible anymore. I'd like to participate, just need to > squeeze some time.
Well, I think I18n support should be included in dm-core. It should be an API to be used inside DataMapper to translate internal messages (like validation errors) and should allow writing adapters for I18n APIs used in project. The good start would be adapters for Rails' I18n and GetText APIs.
The basic stuff is already done, I was starting to change it to support pure Ruby object translations, but stopped. I'll dig my code up, dust it off and try to make it run with the latest build, and then I'll post the link here. It's on Github but it's pretty out of date.
On Jul 1, 1:02 pm, Maxim Kulkin <maxim.kul...@gmail.com> wrote:
> On 01.07.2009, at 22:55, Rafael Rosa wrote:
> > I started the development of a I18n extension a few months ago, I
> > believe it's the way to go, even talked with Dan Kubb about it but I
> > was taken away by a new job, so I didn't have the time to finish it.
> > I hope to have time to do that soon, but I'm not sure when :( I
> > really wanted to finish it, and it had a lot of features already. I
> > was unable to follow the recent developments, so I'm not sure it
> > will be compatible anymore. I'd like to participate, just need to
> > squeeze some time.
> Well, I think I18n support should be included in dm-core. It should be
> an API to be used inside DataMapper to translate internal messages
> (like validation errors) and should allow writing adapters for I18n
All the validation code is in the dm-validations plugin. dm-core does
nothing to prevent I18n, but I do not believe that it is a feature
that belongs in dm-core itself. It could easily be a plugin/wrapper
for the dm-validations plugin.
> The basic stuff is already done, I was starting to change it to > support pure Ruby object translations, but stopped. I'll dig my code > up, dust it off and try to make it run with the latest build, and > then I'll post the link here. It's on Github but it's pretty out of > date.
I just have noticed that datamapper/dm-more has "errors_messages_i18n" branch, that has I18n support added by Rafael (although it adds localization support only for several validators). It relies on Rails' I18n API.
It relies on I18n, but it's not a Rails exclusive library since it can be added as a gem, but I do believe it's the de facto internationalization library, specially with Rails 3 coming. Besides that, it's quite a well thought base to build upon. When I spoke to Dan Kubb he advised me to keep it under dm-validation, and I do believe it's a good call, since most internationalization stuff happens there, or at least keep it as a separate gem, so we won't clutter dm-core.
> It relies on I18n, but it's not a Rails exclusive library since it > can be added as a gem, but I do believe it's the de facto > internationalization library, specially with Rails 3 coming. Besides > that, it's quite a well thought base to build upon. When I spoke to > Dan Kubb he advised me to keep it under dm-validation, and I do > believe it's a good call, since most internationalization stuff > happens there, or at least keep it as a separate gem, so we won't > clutter dm-core.
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).
Imho we should give people a choice on what backend they use, whether it's Rails i18n, Gettext or some other solution. Agree on the fact that we shouldn't clutter dm-core with this stuff.
On Jul 2, 1:09 pm, Dirkjan Bussink <d.buss...@gmail.com> 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.
> Agree on the fact that we shouldn't clutter dm-core with this stuff.
I agree on this too. I don't want i18n part of dm-core. For one,
there's no need, there's nothing in dm-core that needs to be
internationalized. Secondly the only library that needs i18n support
that I can think of is dm-validations. We should be focusing on that
library, and how we can alter it's API and provide hooks so it works
with i18n libs without tightly coupling itself to any of them. I know
that's easier said than done, but I think that's where we should focus
our efforts.
> On Jul 2, 1:09 pm, Dirkjan Bussink <d.buss...@gmail.com> 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.
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).
>> On Jul 2, 1:09 pm, Dirkjan Bussink <d.buss...@gmail.com> 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.
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.
> 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 <d.buss...@gmail.com> 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.
|
