I18n support discussion
Maxim Kulkin
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 ?
Any feedback will be valuable.
Rafael Rosa
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.
Cheers,
Rafael Rosa
www.rafaelrosafu.com
www.rubyinside.com.br
Maxim Kulkin
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
APIs used in project. The good start would be adapters for Rails' I18n
and GetText APIs.
Rafael Rosa
Paul
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
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.
Maxim Kulkin
On 01.07.2009, at 23:10, Rafael Rosa wrote:
> 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.
Rafael Rosa
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.
Dirkjan Bussink
On 2 Jul 2009, at 16:40, Rafael Rosa wrote:
> 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.
--
Regards,
Dirkjan Bussink
Dan Kubb (dkubb)
> 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).
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.
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.
--
Dan
(dkubb)
Maxim Kulkin
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.
Clifford Heath
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.
Lawrence Pit
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