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

[WIP] defaults take precedence over fallbacks causing a misleading situation #413

Closed

Conversation

coorasse
Copy link

Before proceeding with fixing the issues (even if I would need help with that) I opened a pull request with a failing test to explain it better.
The failing test is on line 28 (master...coorasse:add_fallback_issue_example#diff-514ab2ee25f5643b31473b6383cf04e7R28) and, as you can see, it shouldn't fail, since the test on the previous line works fine.
In other words: if I have a string translated, I don't expect it not to be translated because I add a default value.
That unfortunately happened in our Rails app and took me some time to dig into the issue.
Funny fact: when using a Chain backend I18n.backend = I18n::Backend::Chain.new(Backend.new, I18n::Backend::Simple.new) the same does not happen since the default options are passed only to the last backend of the chain.

test "fallback does not work with defaults when using en-CH locale" do
I18n.with_locale(:'en-CH') do
assert_equal 'i exist', I18n.t(:faa)
assert_equal 'i exist', I18n.t(:faa, :default => [:'foo.bar'])
Copy link
Author

Choose a reason for hiding this comment

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

that's the failing test. why should it fail, just because we added a default option?

Copy link
Collaborator

Choose a reason for hiding this comment

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

This is certainly weird. I wonder if it is failing not because of the option, but because of the value passed to the option? I will investigate.

Copy link
Collaborator

@radar radar Apr 18, 2018

Choose a reason for hiding this comment

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

Ok, I investigated this a little bit, but I don't have much more time to look into it today.

I suspect this is happening because https://github.com/svenfuchs/i18n/blob/274ed8accd53a573d839617de2dd16b1b01d864b/lib/i18n/backend/base.rb#L33 doesn't take into account the fallback_in_progress option. What happens is that this translate call will lookup first in the ch-CH translation and then because the entry returned is nil, it will use the default, without falling back to the en translation first.

I tried adding && !options[:fallback_in_progress] to this, but it doesn't quite solve it. I am only partially confident that this is the solution.

Could you please take a deeper look at it when you have time, @coorasse?

@radar
Copy link
Collaborator

radar commented Aug 7, 2018

Probably fixed by #415. Let us know if it isn't!

@radar radar closed this Aug 7, 2018
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.

2 participants