Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fallbacks to exclude default locale #415

Merged
merged 1 commit into from
Apr 18, 2018

Conversation

tjoyal
Copy link
Contributor

@tjoyal tjoyal commented Apr 17, 2018

Fixes #338 ?

I believe using the default locale as a default fallback is not a sane default behaviour.

"Silently" displaying an default locale version of a string when a page is being rendered in another can have a negative impact (especially if this is not fixable like in the cases where emails are being sent).

For us to disable that behaviour, we had to pass in an explicit nil, but I believe it should be the default behaviour:

I18n::Locale::Fallbacks.new([nil])
or
Rails.application.config.i18n.fallbacks = [nil]

This only work because of a undocumented compact down in the internals of the class.

I am not saying that I would always prefer to have a "translation missing" error instead of displaying the default locale, but not having the default allows the rest of the i18n stack to handle exceptions as normal, send it to the exception handler where I can transform that missing translation to the specificities of my application.

Eg.: in my current case we have an exception handler that logs on missing translation, send a developer actionable item then manually fall back to I18n.t(key, options.merge(locale: :en), all within the I18n.exception_handler#call

@radar
Copy link
Collaborator

radar commented Apr 18, 2018

I have a sneaking suspicion this might also fix #413. That would be nice :)

@radar radar merged commit 697b42d into ruby-i18n:master Apr 18, 2018
@tjoyal tjoyal deleted the fallbacks-to-exclude-default-locale branch April 18, 2018 12:08
@Fernan2
Copy link

Fernan2 commented Aug 8, 2018

v1.1.0 has broken broken our application, due to this change. We built all relying on its default behavior, and changing it is a major compatibility issue that I see no reason to add, but if it should be added, at the very least it should be done properly: name the version 2.0 instead of 1.1, and release a previous version triggering warnings when the default behavior is being used...

But well... we always can stick to 1.0.1 (which we will do).

@radar
Copy link
Collaborator

radar commented Aug 8, 2018 via email

@jarthod
Copy link

jarthod commented Aug 8, 2018

@Fernan2 if you relied on this behavior all you have to do now is declare it explicitly if I'm right, something like:

# config/application.rb
module XXXXX
  class Application < Rails::Application
    ...
    config.i18n.fallbacks = [:en]
  end
end

@Fernan2
Copy link

Fernan2 commented Aug 9, 2018

Ok, it seems that I had a weird configuration that has been the cause of all... after @jarthod 's comment, I've gone to my application.rb and I've found that I had

    config.i18n.default_locale = :es
    config.i18n.fallbacks = [:es]

But (fortunately!) I also noticed that I had a different configuration in development.rb and production.rb:

config.i18n.fallbacks = true

That worked fine on 1.0.1, but not on 1.1.0... with the problem that I had overriden development and production but no test, so tests were all passing.

Now I've removed my environment overrides and it works fine... thanks a lot!

@jarthod
Copy link

jarthod commented Aug 9, 2018

I've had exactly the same problem, and after I found the code change in i18n I checked my application.rb and saw that this syntax can't work, I removed the fallback = true line all is back to normal. I'm not sure where this line came from but I guess it was in some tutorial or documentation.

@Fernan2
Copy link

Fernan2 commented Aug 9, 2018

As my application comes from Rails 1.2, I guess that this was the proper configuration many years ago...

@jarthod
Copy link

jarthod commented Aug 9, 2018

Haha, mine is from Rails 3 so maybe not that old ;)

cbothner added a commit to galahq/gala that referenced this pull request Dec 12, 2018
Before i18n v1.1.0, i18n.fallbacks would eventually hit your
default_locale. That was changed without warning and broke
everything ruby-i18n/i18n#415. This restores the
previous behavior by explicity falling back to English.
cheerfulstoic added a commit to cheerfulstoic/globalize that referenced this pull request Dec 19, 2018
I'm not 100% sure that this is right, but when I make this change it seems to fix the problem that I was having which many other people seem to be having in the globalize#682 discussion

ruby-i18n/i18n#415
@sshaw
Copy link
Contributor

sshaw commented Jun 25, 2020

I had:

I18n::Backend::Simple.send(:include, I18n::Backend::Fallbacks)
I18n.enforce_available_locales = false

And things like:

I18n.l product.updated_at, :format => :long, :locale => "un-supported"

Worked great! Used default locale's :long.

Then I upgraded to said version, and I cannot get this behavior back.

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

Gives:

Traceback (most recent call last):
       14: from ./bin/rails:4:in `<main>'
       13: from ./bin/rails:4:in `require'
       12: from /Users/sshaw/.rvm/gems/ruby-2.5.2/gems/railties-5.0.7.2/lib/rails/commands.rb:18:in `<top (required)>'
       11: from /Users/sshaw/.rvm/gems/ruby-2.5.2/gems/railties-5.0.7.2/lib/rails/commands/commands_tasks.rb:49:in `run_command!'
       10: from /Users/sshaw/.rvm/gems/ruby-2.5.2/gems/railties-5.0.7.2/lib/rails/commands/commands_tasks.rb:78:in `console'
        9: from /Users/sshaw/.rvm/gems/ruby-2.5.2/gems/railties-5.0.7.2/lib/rails/commands/console_helper.rb:9:in `start'
        8: from /Users/sshaw/.rvm/gems/ruby-2.5.2/gems/railties-5.0.7.2/lib/rails/commands/console.rb:65:in `start'
        7: from (irb):1
        6: from /Users/sshaw/.rvm/gems/ruby-2.5.2/gems/i18n-1.1.0/lib/i18n.rb:274:in `localize'
        5: from /Users/sshaw/.rvm/gems/ruby-2.5.2/gems/i18n-1.1.0/lib/i18n/backend/base.rb:83:in `localize'
        4: from /Users/sshaw/.rvm/gems/ruby-2.5.2/gems/i18n-1.1.0/lib/i18n.rb:181:in `translate'
        3: from /Users/sshaw/.rvm/gems/ruby-2.5.2/gems/i18n-1.1.0/lib/i18n.rb:181:in `catch'
        2: from /Users/sshaw/.rvm/gems/ruby-2.5.2/gems/i18n-1.1.0/lib/i18n.rb:185:in `block in translate'
        1: from /Users/sshaw/.rvm/gems/ruby-2.5.2/gems/i18n-1.1.0/lib/i18n/backend/fallbacks.rb:45:in `translate'
TypeError (no implicit conversion of String into Integer)
I18n.enforce_available_locales = false
I18n.fallbacks = [I18n.default_locale]

Along with other seemingly correct config permutations give:

I18n::MissingTranslationData (translation missing: XX.time.formats.long)

Back to 1.0.1! 🔒

@radar
Copy link
Collaborator

radar commented Jul 14, 2020

@sshaw Could you please open a new issue so that we can track this separately from this merged PR?

@radar
Copy link
Collaborator

radar commented Jul 14, 2020

Actually I just found the option to DIY! One moment...

j15e added a commit to didacte/hstore_translate that referenced this pull request May 28, 2021
@@ -56,7 +56,7 @@ class Fallbacks < Hash
def initialize(*mappings)
@map = {}
map(mappings.pop) if mappings.last.is_a?(Hash)
self.defaults = mappings.empty? ? [I18n.default_locale.to_sym] : mappings
self.defaults = mappings.empty? ? [] : mappings
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tjoyal This PR did not update the documentation comment above, which still references default_locale.

Took me far too long to realize that default_locale was no longer getting used. 😅

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've opened a PR to update the comment: #576

movermeyer added a commit to movermeyer/i18n that referenced this pull request Mar 16, 2022
ruby-i18n#415 changed the behaviour, but this comment was not updated to reflect the change.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Don't include default_locale in list of fallbacks
6 participants