Customise hash deep symbolize keys

[radar]

Due to new behaviour introduced in #422, numbers are now treated differently. There are people using this new behaviour in the wild (see ice-cube-ruby/ice_cube#462), and simultaneously people who want the old behaviour #443.

Both are sensible.

I have now reverted some of the changes in #422 and have made my own attempt at the problem here by changing how deep_symbolize_keys works. It checks the type of the key and from that determines if it is "symbolizable" or not, rather than blindly rescuing from any thrown exceptions. The only two types that are "symbolizable" are String and the parent class of all numbers: Numeric. I think this covers all use-cases.

Rather than releasing I18n 1.2.1 with this fix contained, I want to give @wjordan, and @adamniedzielski (and anyone else) until 8pm Thursday night Australian Eastern Time to test this change on their applications.

You can do so by adding this line to your Gemfile:

gem "i18n", github: "svenfuchs/i18n", branch: "radar/customise-hash-deep-symbolize-keys"

If there are no reported regressions by 8pm Thursday night Australian Eastern Time, I will be merging this patch to master and then immediately releasing 1.2.1.

Thanks for your patience while we try to resolve this regression.

[radar]

For this PR to be merged, i18n will need to drop support for Ruby 2.0.

Given that this Ruby version was EOL'd on 2016-02-24, I think that it will be acceptable to do that.

I do realise that this will mean that any i18n release after this point will not be compatible with any 4.x release running Ruby 2.0 -- the minimum Ruby version requirement there is 1.9.3.

I'm happy to make this sacrifice also.

[wjordan]

Let's look at some examples across i18n versions:

I18n.backend.store_translations(:en, x: {
  'str' => {'foo' => 'bar'},
  1 => {'foo' => 'bar'},
  true => {'foo' => 'bar'}
})
puts [I18n.t('x.str.foo'),
  I18n.t('x.1.foo'),
  I18n.t('x.true.foo')],
  I18n.t('x')

1.1.1

bar
translation missing: en.x.1.foo
translation missing: en.x.true.foo
{:str=>{:foo=>"bar"}, 1=>{:foo=>"bar"}, true=>{:foo=>"bar"}}

1.2.0

bar
bar
bar
{:str=>{:foo=>"bar"}, :"1"=>{:foo=>"bar"}, :true=>{:foo=>"bar"}}

radar/customise-hash-deep-symbolize-keys

bar
bar
translation missing: en.x.true.foo
{:str=>{:foo=>"bar"}, :"1"=>{:foo=>"bar"}, true=>{:foo=>"bar"}}

I don't think this PR will break my application's use-case specifically (I don't think we use true / false as translation keys anywhere, only integers), but I don't believe this will fix ice-cube-ruby/ice_cube#462.

[wjordan]

See #445 for an extra test case clarifying the API discussed here, as well as a PR proposal that would support all of the various use-cases in a slightly more backwards-compatible fashion.

[adamniedzielski]

@radar thanks for all your work on this! 🎉

I didn't dig into @wjordan response, but I tested the patch on my application as you requested. It solves my issue, the test is passing again with your patch.

[radar]

It is now 8pm (well, 8:05pm) Australian Eastern time. I am going to attend to #446 and #445 and then this PR. Once I have merged them all into master and Travis reports green I will then release 1.2.1.

[radar]

Given that this PR both fixes this regression and changes the minimum required Ruby version, I will be releasing it as 1.3.0.

[tom-lord]

@radar Having just encountered this regression in production, can I please ask for this to be merged asap?
Version 1.3.0 was released today, but this PR unfortunately isn't included.

[radar]

I merged this PR manually to master because I was time-limited last night and Travis was taking too long to even start the build.

Here is the commit: 949dc64.

If you’re still seeing an issue definitely on 1.3.0, please open a new issue with steps to reproduce.