lambda support

[Clemens Kofler]

Hi folks,

today I've stumbled across an issue that I already raised (and
partially fixed with a plugin) last summer, namely the lack of lambda
support in i18n.

See this topic for more in-depth information:
http://groups.google.com/group/rails-i18n/browse_thread/thread/7b042fffe6b40e3d

As I said, I've partially fixed the issues with my localized dates
plugin (see http://github.com/clemens/localized_dates) where I've
added support for lambdas at least for localizing dates. Apart from
the fact that I still feel that this belongs into i18n itself
including a proper Rails patch (also see the still pending patch I
proposed at Lighthouse:
https://rails.lighthouseapp.com/projects/8994/tickets/748-date-and-time-classes-i18n-l10n-implementation),
today I saw that this would also be of use for translations (not only
localizations).

Here's a use case: Assume you're creating an application with some CRM-
like functionalities such as emails, letters etc. to customers which,
of course, needs proper i18n so you can address your customers
accordingly. The primary issue here is the salutation (assume we have
Dr Gregory Brown, his wife Sandra and their (unmarried) daughter
Catherine):

- (Formal) English: Dear Dr Brown, Dear Mrs Brown, Dear Ms Brown
- (Informal) English: Dear Gregory, Dear Sandra, Dear Catherine
- German: Sehr geehrter Herr Dr. Brown, Sehr geehrte Frau Brown, Sehr
geehrte Frau Brown
- (Older Austrian) German: Sehr geehrte Frau Dr. Brown (we used to
address women with their spouse's academic title)

The problem here is two-fold:

- Some languages (e.g. English, French) distinguish between married
and unmarried women and address them differently (Mrs/Ms).
- Some languages include prefixes in the salutation, some don't. Even
if they include prefixes, there are differences: In German, we still
use "Herr/Frau" (Mr/Mrs/Ms) together with the actual prefix (e.g.
academic titles) whereas in other languages (e.g. English) you drop
the "gender prefix" and only use the actual prefix.

Now, of course you could handle all this logic in the model/view code:

if person.has_prefix?
I18n.t(:'salutation.with_prefix')
else
I18n.t(:'salutation.without_prefix')
end

However, if you have rules with increasing complexity, this can easily
get out of hand. Plus, at least in my opinion, translations are
separate entities and models/views/controllers shouldn't have to deal
with the additional logic.

Here's a short implementation of a translation with logic, using a
lambda: http://gist.github.com/90757. As you can see, this gives us
the opportunity to extract all translation-related logic into the
translation itself instead of bothering the model with it. The
translation can call other translations internally which could also
save you from doing weird double translations like <%= t
(:signup_text, :signup_link => link_to(t(:signup_link_text),
signup_path)) %> because there might be potential to internalize it.

I'm not sure how attributes should be passed. For this example, I've
assumed that a hash is passed, so if you have t(:something, :x =>
x, :y => y, :z => z) you get attributes[:x] etc. in Ruby translations
and the usual interpolations (e.g. {{x}}) in YAML translations. This
might not be a suitable solution as it might clash with localize where
you'd have to pass the object to be localized to the lambda (e.g.
lambda { |date| ... }) - but of course, you could always pass both
(lambda { |date, attributes| ... }).

I'm curious as to what you guys think about this use case and whether
or not it justifies to (finally) implement lambda support in i18n.
- Clemens

[Yaroslav Markin]

On Mon, Apr 6, 2009 at 5:39 PM, Clemens Kofler <cle...@railway.at> wrote:

I'm curious as to what you guys think about this use case and whether
or not it justifies to (finally) implement lambda support in i18n.

I have to say I'm +10 on implementing lambda support for i18n (not Rails/AS). If by any chance you can publish your fork of i18n with lambda support you're working on, that would be great.

--
Yaroslav Markin

[Sven Fuchs]

Hi Clemens,

thanks for laying out this usecase. I agree we should finally get
lambda support into the I18n gem.

One thing I'm concerned about is consistency across key and default
translations.

So, with :foo resolving to a lambda these should behave the same:

I18n.t(:foo)
I18n.t(:does_not_exist, :default => :foo)

[Hans]

Hi Clemens
Here is another use case that shows the need for this kind of support
or maybe a simpler version of it.

I have to translate from swedish to english and there are some words
in english that have two possible swedish words depending on e.g.
gender, as grandparents, spouse etc.
I would like to do that by e.g. writing t(spouse, :gender => gender)or
something similar
Could you code snippet at githubeb used for that ?
What would then be the code in the view and in the json localization
file ?

On 6 Apr, 15:39, Clemens Kofler <clem...@railway.at> wrote:
> Hi folks,
>
> today I've stumbled across an issue that I already raised (and
> partially fixed with a plugin) last summer, namely the lack of lambda
> support in i18n.
>

> See this topic for more in-depth information:http://groups.google.com/group/rails-i18n/browse_thread/thread/7b042f...

>
> As I said, I've partially fixed the issues with my localized dates

> plugin (seehttp://github.com/clemens/localized_dates) where I've

> added support for lambdas at least for localizing dates. Apart from
> the fact that I still feel that this belongs into i18n itself
> including a proper Rails patch (also see the still pending patch I

> proposed at Lighthouse:https://rails.lighthouseapp.com/projects/8994/tickets/748-date-and-ti...),

[Clemens Kofler]

Yaroslav:
I just committed my stuff and pushed it to my fork:
http://github.com/clemens/i18n/tree/master.

Basically, the this implementation checks for Procs after the lookup
but before pluralization and interpolation. This means, that a Proc
can also return a Hash with pluralization data or a String with
interpolations. The Proc gets called with the Hash you pass in just
like interpolations, so just like interpolations the Proc can decide
which key/value pairs it actually needs.

Feel free to comment!

On Apr 6, 5:29 pm, Yaroslav Markin <yaroslav.mar...@gmail.com> wrote:

[Clemens Kofler]

Thoughts anyone?

[Sven Fuchs]

I've worked with Clemens yesterday to integrate and polish his lambda
support for the API and Simple backend yesterday.

http://github.com/svenfuchs/i18n/commits/lambda

Basically when a translated key resolves to a Proc that Proc is called
with the key and options (that were passed to #translate) or the
object and options (that were passed to #localize) respectively.

I.e. you can add lambdas to your translation data:

foo = lambda { |key, options| key.to_s.upcase }
I18n.backend.store_translations :en, { :foo => foo }
I18n.t(:foo) # => FOO

You can also pass lambdas as default values at any point of the
defaults chain:

foo = lambda { |key, options| key.to_s.upcase }
I18n.t(:not_here, :default => [:not_here2, foo]) # => FOO


I've pushed this work to a new branch "lambda". Can please everybody
interested in this feature review the branch and maybe pull it to some
working application to give it some fire?

I think after some battletesting we should then push this to an
"official" release soon.

[Yaroslav Markin]

Just pushed lambda localize support and lambda pluralization to my fork (github.com/yaroslav/i18n).

Feedback appreciated.

On Fri, May 1, 2009 at 2:58 PM, Sven Fuchs <sven...@artweb-design.de> wrote:

I've worked with Clemens yesterday to integrate and polish his lambda
support for the API and Simple backend yesterday.

http://github.com/svenfuchs/i18n/commits/lambda

Basically when a translated key resolves to a Proc that Proc is called
with the key and options (that were passed to #translate) or the
object and options (that were passed to #localize) respectively.

I.e. you can add lambdas to your translation data:

  foo = lambda { |key, options| key.to_s.upcase }
  I18n.backend.store_translations :en, { :foo => foo }
  I18n.t(:foo) # => FOO

You can also pass lambdas as default values at any point of the
defaults chain:

  foo = lambda { |key, options| key.to_s.upcase }
  I18n.t(:not_here, :default => [:not_here2, foo]) # => FOO


I've pushed this work to a new branch "lambda". Can please everybody
interested in this feature review the branch and maybe pull it to some
working application to give it some fire?

I think after some battletesting we should then push this to an
"official" release soon.

--
Yaroslav Markin

[Yaroslav Markin]

Whoops, make that http://github.com/yaroslav/i18n/tree/lambda

On Sat, May 2, 2009 at 3:48 PM, Yaroslav Markin <yarosla...@gmail.com> wrote:

Just pushed lambda localize support and lambda pluralization to my fork (github.com/yaroslav/i18n).

Feedback appreciated.

 

--
Yaroslav Markin

[Sven Fuchs]

Awesome, thanks Yaroslav.

I've cherry-picked the localization related commits:

http://github.com/svenfuchs/i18n/commits/lambda

[Yaroslav Markin]

Guys, if anyone does think that a simple lambda per locale is not good enough for their language — *please* speak loud.


--
Yaroslav Markin