v0.9.0 introduced a side effect about I18n.locale_available?

[juno]

I noticed that return value of I18n.locale_available? method changed after upgrade from v0.7.1 to v0.9.0.

Our Rails application defines :en and :ja locales in config/locales/*.yml.

with v0.7.1:

> I18n.locale_available?(:en)
=> true
> I18n.locale_available?(:ja)
=> true
> I18n.locale_available?(:de)
=> false

with v0.9.0:

> I18n.locale_available?(:en)
=> true
> I18n.locale_available?(:ja)
=> true
> I18n.locale_available?(:de)
=> true # CHANGED

I doubting this introduced by 585cddd.
Is this behaviour change intended?

[oriolgual]

I think this has been fixed by #71, could you confirm @juno?

[juno]

@oriolgual
Thank you for notifying.
I confirmed that the issue still exists with latest master branch 9df6740. 😢

This issue blocks a technique like an extracting locale from tld/params/etc which mentioned in Rails Guide:

# This line returns parsed_locale if it defined in data_validator's locale files
I18n.available_locales.map(&:to_s).include?(parsed_locale) ? parsed_locale : nil

# [1] pry(main)> I18n.available_locales
# => [:en, :ru, :ja, :af, :ca, :de, :es, :fr, :it, :nl, :pl, :"pt-BR", :tr]
# [2] pry(main)> I18n.locale_available?(:pl)
# => true

However, since we using 0.9.0 with a following workaround, there are no problems at this time.

available_locales = [:ja, :en]
available_locales.map(&:to_s).include?(parsed_locale) ? parsed_locale : nil

So, If it's OK with you, please close this issue. 👍

[oriolgual]

Maybe we could change https://github.com/codegram/date_validator/blob/585cddda057edcf5409d7ba2d29c12ee947a5d7c/lib/date_validator/engine.rb so it only loads locales that are already available in the parent Rails app.

Something like this after line 4:

available_locales = I18n.available_locales.map(&:to_s)
files = files.select do |file|
  locale_from_file = file.split("/").last.split(".").first
  available_locales.include?(locale_from_file)
end

Could you patch your local gem and see if this solves it?

[juno]

@oriolgual

Could you patch your local gem and see if this solves it?

Sure, I'll try it tomorrow.

[juno]

@oriolgual
Sorry for late reply.

I checked vanilla rails app with codegram/date_validator master branch & patch.
Unfortunately, patch doesn't seem to solve the problem.

---

How to reproduce

Create vanilla rails app with date_validator master (not yet patched):

$ rails -v
Rails 5.0.0.1
$ rails new TestApp --skip-bundle --skip-active-record
$ cd TestApp
$ echo "gem 'date_validator', github: 'codegram/date_validator'" >> Gemfile
$ bundle install --path vendor/bundle

I18n.available_locales returns locales within date_validator gem:

$ rails console
Loading development environment (Rails 5.0.0.1)
irb(main):001:0> I18n.available_locales
=> [:en, :af, :ca, :de, :es, :fr, :it, :ja, :nl, :pl, :"pt-BR", :ru, :tr]

Apply patch and debug prints:

$ bundle open date_validator

# lib/date_validator/engine.rb
module DateValidator
  class Engine < Rails::Engine
    initializer 'date_validator' do
      files = Dir[Pathname.new(File.dirname(__FILE__)).join('../../config', 'locales', '*.yml')]
      available_locales = I18n.available_locales.map(&:to_s)
      puts "*** available_locales: #{available_locales}"
      files = files.select do |file|
        locale_from_file = file.split("/").last.split(".").first
        available_locales.include?(locale_from_file)
      end
      config.i18n.load_path += files
      puts "*** config.i18n.load_path: #{config.i18n.load_path}"
    end
  end
end

I18n.available_locales returns same results:

$ rails console
*** available_locales: ["en"]
*** config.i18n.load_path: ["/Users/juno/src/TestApp/vendor/bundle/ruby/2.3.0/gems/web-console-3.4.0/lib/web_console/locales/en.yml", "/Users/juno/src/TestApp/vendor/bundle/ruby/2.3.0/bundler/gems/date_validator-9df67409c49b/config/locales/en.yml"]
Loading development environment (Rails 5.0.0.1)
irb(main):001:0> I18n.available_locales
=> [:en, :af, :ca, :de, :es, :fr, :it, :ja, :nl, :pl, :"pt-BR", :ru, :tr]