-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Add default locale back to fallback locales #4548
Conversation
The linked PR specifies that the workaround is to explicitly list the default language in the fallbacks which is straightforward to do. Unless that doesn't work for some reason I would say that should be the path forward for users who want the fallbacks to default languages. |
The suggested solution in the references PR is not viable for mongoid. You either need to set fallbacks for all locales in the world as a hash to make it work with mongoid. In svenfucks/i18n#415 the suggestion is to set Another option would to create a custom fallback-class that takes care of the problems in mongoid. |
Rails seems to solve it with not using version 1.1.0 of i18n, rails/rails#33566 until they have a solution for i18n new behavior. They seem to be adding this behavior to rails, rails/rails#33574.
Maybe mongoid needs a to also handle arrays and booleans? |
My current understanding of the situation is as follows:
Mongoid does not directly depend on i18n. This dependency is obtained through activesupport, which currently depends on i18n < 2. Therefore, and taking point 2 above into account, pinning to i18n 1.0 is not something Mongoid should do. Mongoid should support users who pin i18n to 1.0 or 1.1 within their application. I created https://jira.mongodb.org/browse/MONGOID-4614 to test both configurations. In each configuration there should be tests for fallback to default locale and fallback to no translation/error. Based on my reading of the rails PRs mentioned I believe all possible permutations are achievable. |
There should not be an automatic fallback to the default locale; it should be required to be listed. I propose to reject this PR. |
The tests added in this PR can be valuable regardless to verify correct fallback behavior against both 1.0 and 1.1 of i18n. I agree that Mongoid should refrain from changing i18n's behavior, and instead should allow the user to select either i18n 1.0 or 1.1 via application gemfile version specification. |
https://jira.mongodb.org/browse/MONGOID-4662 for this PR. |
I am ok to merge the tests only for this. |
we had a problem that could have been solved if mongo took more action on this. fallbacks are totally broken with the latest i18n. |
Right now the only ticket in the backlog that is related to i18n is https://jira.mongodb.org/browse/MONGOID-4662 which is adding tests to validate that Mongoid works with both 1.0 and 1.1+ versions of i18n, maintaining each version's behavior with respect to fallbacks. If you have a different issue please create a new ticket. |
The tests and documentation for fallbacks with i18n 1.0 and 1.1+ are added in #4703.
@smgt Correct me if I'm wrong, but does this not apply to all libraries using i18n? https://github.com/ruby-i18n/i18n/wiki/Fallbacks shows the hash syntax for specifying fallbacks. If so, it is out of scope for Mongoid to provide a different API for i18n. |
In version 1.1.0 of I18n the behavior of I18n fallbacks changed ruby-i18n/i18n#415 from including the default locale to not including the default locale.
This PR restores the behavior of document field localization to pre 1.1.0 of i18n.
Dunno if this is a good default but at least it restores how it used to be. What do you think?