Interpolation-feature suggestion:

grimen · February 1, 2010, 6:40pm

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/2c50bd209f3fc24fe9dfa694c81be64340f09b7d.
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: “[email protected]”
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?

grimen · February 3, 2010, 5:00pm

knock, knock

grimen

grimen · February 3, 2010, 5:34pm

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.

grimen · February 3, 2010, 5:39pm

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 …

grimen · February 3, 2010, 8:20pm

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

grimen · February 3, 2010, 8:26pm

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

grimen · February 26, 2010, 6:17am

Sven, got a chance to review this?

grimen

grimen · February 13, 2010, 7:40am

OK, now I had some time to realize it:

github.com/grimen/i18n

Initial support for optional "key interpolations": Extended behavior to support for interpolating explicit I18n keys (reference sub-translations within same document) for DRYer translations.

committed 06:30AM - 13 Feb 10 UTC

grimen

+129 -0

Without "key interpolations": interpolate "file {{file}} opened by \\{{user}}…", :file => 'test.txt', :user => 'Mr. X' # => "file test.txt opened by {{user}}" With "key interpolations": translate :"file.name" # => "manifesto.txt" interpolate "file {{:file.name}} opened by \\{{user}}", :user => 'Mr. X' # => "file manifesto.txt opened by {{user}}"

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:

github.com

grimen/i18n/blob/ff1169dc10d7db8ceca51997a72d040246706a78/lib/i18n/backend/key_interpolation.rb#L52-53


      
                elsif ::I18n::Backend::Base::RESERVED_KEYS.include?(key)
                  raise ReservedInterpolationKey.new(key, string)
                else
                  begin
                    value = self.translate(locale, key)
                  rescue
                    # DISCUSS: A leaner approach would be: self.translate(locale, key, :default => "{{:#{key}}}")
                    raise KeyError
                  end
                  # NOTE: Didn't want to mess with I18n String::INTERPOLATION_PATTERN; so using "_" instead of ":".
                  key = key.to_s.tr('.', '_').to_sym
                  values.merge!(:"_#{key}" => value)
                  "{{_#{key}}}"
                end
              end
          
          
    self.interpolate_without_key_interpolation(locale, s, values)
            end
          
          
rescue KeyError => e
            raise MissingInterpolationArgument.new(values, string)

…because of:

github.com

grimen/i18n/blob/ff1169dc10d7db8ceca51997a72d040246706a78/lib/i18n/core_ext/string/interpolate.rb#L34


      
          #
          # String#% method which accept "named argument". The translator can know
          # the meaning of the msgids using "named argument" instead of %s/%d style.
          
          
class String
            # For older ruby versions, such as ruby-1.8.5
            alias :bytesize :size unless instance_methods.find {|m| m.to_s == 'bytesize'}
            alias :interpolate_without_ruby_19_syntax :% # :nodoc:
          
          
  INTERPOLATION_PATTERN = Regexp.union(
              /%\{(\w+)\}/,                               # matches placeholders like "%{foo}"
              /%<(\w+)>(.*?\d*\.?\d*[bBdiouxXeEfgGcps])/  # matches placeholders like "%<foo>.d"
            )
          
          
  INTERPOLATION_PATTERN_WITH_ESCAPE = Regexp.union(
              /%%/,
              INTERPOLATION_PATTERN
            )
          
          
  # % uses self (i.e. the String) as a format specification and returns the
            # result of applying it to the given arguments. In other words it interpolates

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

grimen · March 3, 2010, 12:05am

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

grimen · March 7, 2010, 10:25am

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

grimen · March 3, 2010, 12:09am

On Wed, Mar 3, 2010 at 00:04, Sven F. [email protected]
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/activesupport/lib/active_support/core_ext/string/interpolation.rb