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

store translations for unavailable locales if enforce_available_locales is false #408

Merged
merged 1 commit into from Feb 13, 2018

Conversation

@wjordan
Copy link
Contributor

@wjordan wjordan commented Feb 13, 2018

Fixes issue described in #404 where the enforce_available_locales setting is not respected by the optimization added in #391.

Adds I18n.enforce_available_locales && to the early-exit conditional in #store_translations, so that translations for locales not in the available_locales array will not be stored only if enforce_available_locales is set to true.

Updated tests to reflect changed behavior.

@radar
radar approved these changes Feb 13, 2018
@radar
Copy link
Collaborator

@radar radar commented Feb 13, 2018

I've investigated #404 and can confirm that there's still an issue in 0.9.4. Your wonderful steps to reproduce worked a treat. I checked out to this branch locally and it does indeed fix the issue. The code + tests are great too.

Just re-running build 529.10. It failed for what appeared to be a glitch-y reason. Once that passes, I'm happy to merge this and to release 0.9.5 with this fix.

Thanks for your work @wjordan! ❤️

@radar radar merged commit 29fe565 into ruby-i18n:master Feb 13, 2018
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@btrd
Copy link

@btrd btrd commented Feb 21, 2018

Is it possible to release this fix in a 0.9.6 version ?

Rails (in the last version 5.1.5) require ~> 0.7 so it is not possible to have this fix in a Rails project.

I think it would make sense to have a 0.9.6 versions.

@radar
Copy link
Collaborator

@radar radar commented Feb 21, 2018

@btrd I am not sure what you mean. The merge commit for this PR shows that the commit is in the v0.9.5 and the v1.0.0 branch.

I just installed a new Rails 5.1.5 app locally and it is using i18n v0.9.5 which contains this fix. Why would I need to do a v0.9.6 release, if v0.9.5 already includes this fix and is used by default in new Rails applications?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants