Forum: Rails I18n interpolation-feature suggestion:

Messaged to Sven directly, but maybe makes more sense to share:

After using i18n for quite some time and extending i with own
extensions/powers I found one features that is lacking that really
should be useful feature in the core. It has to do with
interpolations; a feature related to José Valim's patch seen here:
http://github.com/svenfuchs/i18n/commit/2c50bd209f....
I'm quite experienced in Ruby, but I found it "not time efficient
enough" to understand all the core code since I scanned it for 15
minutes - there's no documentation on the methods at all, so it's not
very easy for me right now to patch this. What I want to do is to
support re-using translations within the document, like so:

en:
  settings:
    emails:
      support: "hello@example.se"
  some_strings:
    hello: "Please say hello to us at {{:settings.emails.support}}"
    goodbye: "Please say goodbye to us at
{{:settings.emails.support}}"

Hope the sample says it all: In other words when interpolation is
symbol - i.e. leading ":"-sign - it should be parsed as a lookup key
instead of using a passed hash parameter/variable. It would be ideal,
becuase many times translation editors are not the actual programmers
so would be good if the YAML file is all there is for the translator
guy/girl.

So I guess you see why it's very convenient. But consider I want to
patch this...could you give me a fast pointer on where this belongs? I
ended up in "interpolations_compiler.rb", but as mentioned the code is
not documented so It's a maze. Would appreciate any help.

Oh, and: Do you agree that this would be awesome addition to I18n
core?

*knock*, *knock*


grimen

Hi Grimen,

sorry for the late response.

Yes, I think your idea would make a great addition to I18n. But ... I'm 
a bit hesitant of altering the API right away especially when it comes 
to interpolation. Also, we'd need to make sure that it works with the 
InterpolationCompiler if that's included.

What would you think of implementing this as an optional module that 
overwrites Backend::Base#interpolate 
(http://github.com/svenfuchs/i18n/blob/master/lib/i...) 
so we can play with it and keep it optional for a while? I'd pull and 
include it to the I18n gem so it gets some attention.

Ummm, btw just in case your not aware of this.

You can always avoid the repetition of that email address by injecting 
that value yourself:

t(:"some_strings.hello", :emai => t(:"settings.email"))

That obviously leaves control to the programmer though while your idea 
would translators allow to do it themselves ...

No problem, just knocking the list to be sure. ;)

Yes, understandable. Adding an experimental module would be an ideal
start - I very much will be able to test it out in my current project
too (which got loads of repeated interpolations for more variant
communication to the end user). I think I'll look at it asap then!

grimen

Yes, I use that quite a lot but it's starting to get messy after a
while - and it's static stuff so it feels wrong to recursively call it
like so, makes sense to dynamic content such as :count =>
@collection.size, etc. =)

grimen

OK, now I had some time to realize it:

http://github.com/grimen/i18n/commit/ff1169dc10d7d...

Initial version, so up for review that is. As mentioned in a comment I
avoided to mess with the core-ext for now that actually should be a
better idea: String#% regex only looking for non-symbols:

http://github.com/grimen/i18n/blob/ff1169dc10d7db8...
...because of:
http://github.com/grimen/i18n/blob/ff1169dc10d7db8...

I guess that is identical to Ruby 1.9 implementation of it, so maybe
my little way around it is okay as it's all happen under the hood.

Reflections?

grimen

Sven, got a chance to review this?

grimen

Hey Grimen,

yes, I had a look. Sorry for not getting back to you earlier.

One thing that held me back is that I've been pondering to entirely pull 
our String core class patch out of the I18n library for a bunch of 
reasons. Maybe the most important one is that we've managed to break 
completely unrelated things (like rcov) by patching Ruby core classes. 
Obviously this is a risk every Ruby dev should know by now but somehow 
this sneaked into this now pretty widely used library.

At the point when we added that Ruby 1.9 String interpolation backport I 
think it was a great step forward for us. Today I believe that this 
rather should go into ActiveSupport (and maybe be optional anyway). As 
your usecase shows in I18n we will want to be in a position to go beyond 
that interpolation api.

Roughly, my thinking is to

- rip off the current String core extension and put it somewhere where 
people can pick it if they want it
- in I18n have a more streamlined implementation that is more open to 
usecases like yours

So, yes, I think we should support that case but maybe rethink the 
implementation.

Wdyt

On Wed, Mar 3, 2010 at 00:04, Sven Fuchs <svenfuchs@artweb-design.de> 
wrote:
> At the point when we added that Ruby 1.9 String interpolation backport I think it was a great step forward for us. Today I believe that this rather should go into ActiveSupport (and maybe be optional anyway)

It's there already, but I suppose you knew that :

http://github.com/rails/rails/blob/master/activesu...

OK, so how can I go further with this from here? Sounds like it will
be on the shelf for a while, so maybe I could make and effort to get
there faster somehow?

grimen