-
-
Notifications
You must be signed in to change notification settings - Fork 411
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
Fallbacks to exclude default locale #415
Conversation
I have a sneaking suspicion this might also fix #413. That would be nice :) |
But well... we always can stick to 1.0.1 (which we will do). |
Please provide steps to reproduce this issue so that I can investigate.
…On 9 Aug 2018, 03:38 +1000, Fernando Calatayud ***@***.***>, wrote:
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).
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@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 |
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
But (fortunately!) I also noticed that I had a different configuration in
That worked fine on Now I've removed my environment overrides and it works fine... thanks a lot! |
I've had exactly the same problem, and after I found the code change in |
As my application comes from Rails 1.2, I guess that this was the proper configuration many years ago... |
Haha, mine is from Rails 3 so maybe not that old ;) |
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.
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
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 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:
Back to 1.0.1! 🔒 |
@sshaw Could you please open a new issue so that we can track this separately from this merged PR? |
Actually I just found the option to DIY! One moment... |
@@ -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 |
There was a problem hiding this comment.
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. 😅
There was a problem hiding this comment.
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
ruby-i18n#415 changed the behaviour, but this comment was not updated to reflect the change.
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: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 theI18n.exception_handler#call