#translate modifies the passed argument hash

[edzhelyov]

The #translate method will modify the passed hash options, this results in very bad cases where a hash with interpolation values is passed to multiple #translate calls.
Not only valuable arguments can be lost, like :locale, but in case with fallback enabled, the :fallback => true key, will be introduces in the hash.
That will be later passed to the next call to #translate that will incorrectly return a missing translation.

Here is an example with fallback configured to :en and missing :us translations:

options = { :title => 'Some title' }
I18n.locale = :us
# This will be translated correctly, but options will now include :fallback => true
I18n.t 'key', options 
# Because options will now include :fallback => true this will result in no translation
I18n.t 'another.key', options 

Modifying the passed option hash is not expected behavior and a copy of it should be used instead.

[tigrish]

I don't get how adding options means the lookup fails, maybe I'm not understanding the issue correctly?

[edzhelyov]

The options hash will be modified. This by itself will cause any subsequent calls to behave unexpectedly.

In the particular case, if you look at the fallback code in fallback.rb you will see that if there is a :fallback => true key, no additional fallback will be done.

So after the first call options will now include :fallback => true and the presence of that will not trigger the fallback mechanism on the second call. So I18n.t 'another.key', options will wrongly return missing translation.

[svenfuchs]

@tigrish the user has an options hash that they want to re-use for subsequent calls. because the first call modifies the options hash these are unexpected (and possibly problematic) side-effects.

i agree that's an issue. can't we just duplicate the hash as soon it goes into I18n.t? or do we internally rely on the hash being modified? then that might be something we'd need to fix first. @edzhelyov i guess a pull request would be welcome :)

[tigrish]

OK thanks for the clarification.

Referencing bug #124 even though they're different issues, I suspect there's some cross over.

[apeiros]

I18n.localize has the same issue.