[BUG] 1.8.6 breaks fallback logic

[JasonBarnabe]

After upgrading to i18n 1.8.6, my fallbacks stopped working. I want missing translations to fallback to English, but now they are doing they are doing the <span class="translation_missing"> behaviour.

My app: https://github.com/JasonBarnabe/greasyfork
Ruby 2.7.2
Rails 6.1.0
rail-i18n 6.0.0

Using this in an initializer:

Rails.application.config.i18n.fallbacks = [:en]

Reverting to 1.8.5 fixes the issue.

[radar]

Possibly a bug caused by #542?

[radar]

Do you have a smaller repro case than an app? Ideally a failing test case on i18n would be good. That’s typically what I’m using to prevent future regressions like this.

[radar]

I am unable to reproduce this with either this test script:

require 'bundler/inline'

gemfile do
  source 'https://rubygems.org'

  gem 'i18n', '1.8.6'
  gem 'pry'

end

require 'i18n'
require 'pry'

I18n::Backend::Simple.send :include, I18n::Backend::Fallbacks
I18n.enforce_available_locales = false
I18n.fallbacks = [:en]

I18n.locale = :jp

I18n.backend.store_translations(:en, { discussions: { posted_by_html: "%{user} %{date}" } })


p I18n.t('discussions.posted_by_html', user: 'Ryan', date: 'Today')

Or within a fresh Rails application.

I have not yet tried greasyfork -- I do not have time this morning to start it up.

I would be interested to hear back from you, @JasonBarnabe, if you're able to come up with a smaller repro case.

Or this will wait until later this week when I have time to build greasyfork locally.

[travisbell]

Hey @radar, upgrading my app to 1.8.6 also broke the fallbacks. Reverting to 1.8.5 fixed it.

I'll see if I can find some time to create a working example, but I just thought I'd mention it. You might wanna yank the gem until it can be resolved.

[JasonBarnabe]

I haven't been able to reproduce in a small test case, so I'm trying debugging in my app.

I've found that in 1.8.6, when I18n::Locale::Fallbacks#compute is called with the locale that's missing translations, #defaults is [], whereas in 1.8.5, it's [:en] (my configured default).

[JasonBarnabe]

In 1.8.5, I18n::Locale::Fallbacks#defaults= is called at startup with the proper value.

In 1.8.6, I18n::Locale::Fallbacks#defaults= is called at startup with the proper value, but also on every request with an empty array (from I18n.fallbacks).

[radar]

Thank you for the information. That will be tremendously helpful when figuring this issue out. Thank you also for your patience.

I was able to reproduce this issue today in a new Rails application with:

1. The above initializer setting: Rails.application.config.i18n.fallbacks = [:en]
2. A view with:

<h1><%= I18n::VERSION %></h1>
<h1><%= t('discussions.posted_by_html', user: 'Ryan', date: 'Today') %></h1>

3. en.yml with the right key
4. jp.yml with a missing key

On 1.8.6, I see:

On 1.8.5 I see:

So I now have an easy test case local.

Let's see about fixing this up.

Sorry for the regression!

[radar]

Interestingly, I cannot reproduce this in a rails runner:

 rails runner "puts I18n::VERSION; puts ApplicationController.helpers.t('discussions.posted_by_html', user: 'Ryan', date: 'Today')"
1.8.6
Ryan Today

[radar]

bisect points to this commit: d024044

d0240440bf6616240523a215cd228a1d17740adb is the first bad commit
commit d0240440bf6616240523a215cd228a1d17740adb
Author: Jonian Guveli <[email protected]>
Date:   Sun Nov 8 16:26:46 2020 +0200

    store fallbacks in Thread.current

 lib/i18n/backend/fallbacks.rb | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)