In the commits between 0.5.0 and 0.5.2, the I18n::RESERVED_KEYS constant is no longer present:
>> require 'i18n'
NameError: uninitialized constant I18n::RESERVED_KEYS
from /home/vagrant/.rbenv/versions/1.9.3-p392/bin/irb:12:in `<main>'
This constant is still referenced on ActionView::Helpers::TranslationHelper L42
For now, I think I can use the initializer patch suggested in this CVE with version 0.5.0, but any suggestions as to how to get back on an unpatched version would be greatly appreciated, thanks!
I'm having this problem as well, but can't see where the constant was removed. Is there an alternate location for it?
A bit at a loss with this, the commits don't mention anything about RESERVED_KEYS.
If it helps, I do seem to recall that they were part of lib/backend/base.rb before being moved to lib/i18n.rb.
You can find them at I18n::Backend::Base::RESERVED_KEYS:
>> require 'i18n'
=> [:scope, :default, :separator, :resolve, :object, :fallback]
But I'm also confused by the diff between 0.5.0 and 0.5.2, since as @tigrish noted they don't appear there. Is it possible that the 0.5.0 on rubygems is not actually the same as the one tagged v0.5.0 here? There seem to be inconsistencies.
I need to get #232 to work so I've just patched I18n and added the I18n.interpolate method back, but I'd prefer to get some clarity on why it was removed (and why I18n::RESERVED_KEYS was moved) in the first place.
Ok, this seems to explain something: 0967fda
The version was bumped from 0.4.2 to 0.5.1, skipping 0.5.0 (8ff0038) altogether. So all the commits between 0.4.2 and 0.5.2 were left out, AFAICT.
@tigrish can you confirm this? I'm not very familiar with I18n, but this seems fairly important. I guess most people are using 0.6.x by now so maybe not terribly high-profile, but nonetheless...
If y'all go look at the network graph, you'll see that tags 0.5.x for x >= 1 aren't actually descendants of 0.5.0. There's a fork at 0ff902f that has two descendant branches:
So the reason you can't find where I18n::RESERVED_KEYS was removed up to 0.5.2 - even though it was in 0.5.0 - is that it was never in that branch.
Exactly why they decided to fork 0.5.0 (the branch, not the tag) where they did is entirely beyond me, though.
@nickgrim thanks for narrowing down that fork commit. so the commits that are missing from 0.5.2 and 0.5.3 are these ones.
Also relevant to note that, as far as I can tell from the record of commits, the 0.5.0 branch was only created 10 days ago. I think it was just forked from the wrong commit, but maybe @tigrish can clarify.
Hi guys, I have an old Rails 3.0.20 app and after upgrading i18n to 0.5.3 from 0.5.0 by one of the developers, we experience the error mentioned in this issue. What's the best solution for such an old app to fix it? Downgrade to 0.5.0, use later version, i.e. 0.6.x or will this issue be fixed and a new 0.5.x version released?
@montrose-software - I'm in the same position. 0.6.x will not work with rails 3.0 - so i locked i18n to 0.5.0. Hoping for a fix too.
lock i18n to 0.5.0 so it works with rails 3.0
I'm in the same situation as @montrose-software (falling under 0.5.3, max allowed) for a rails 3.0.20 app
Hey guys, thanks for doing all the hard work to detect the problems on the 0.5x branch. I'll work to get it fixed with all the missing commits to fix this issue. ❤️
I've cherry picked all the missing commits and added some fixes on top of them to get the test suite green and remove some warnings.
I'll be merging this to 0.5.0 soon, meanwhile if anyone wants to try it out on some app, that'd be super welcome.
Merge branch 'cherry-pick-missing-0.5-commits' into 0.5.0
Add missing commits to the 0.5.0 branch. Closes #233.