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:
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:

support: “[email protected]
hello: “Please say hello to us at {{}}”
goodbye: “Please say goodbye to us at

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

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

knock, knock


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
(i18n/lib/i18n/backend/base.rb at master · ruby-i18n/i18n · GitHub)
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(:“”))

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. :wink:

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!


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. =)


Sven, got a chance to review this?


OK, now I had some time to realize it:

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:

…because of:

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.



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


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?


On Wed, Mar 3, 2010 at 00:04, Sven F. [email protected]

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 :