Allow overriding of entry resolving entry resolving separate from defaults #622
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What are you trying to accomplish?
Fixes #617. Alternative to #620.
#591 was incorrect, since I didn't check/realize that
resolve
is called in three different cases:Symbol
(Code)Symbol
s using the original fallback locale #591. In this case, you need/want to restart your search from the original fallback locale.defaults
are resolved. (Code)defaults
before falling back throughfallbacks
locales, keeping the behaviour as it has always been.Proc
(Code)1.
, where you are resolving a entry, but I mention it separately since it is being called from a different place in the code.Prior to #591, there was no distinction between the cases. #591 should have introduced that distinction.
What approach did you choose and why?
I added a
resolve_entry
method which can be overridden to handle the case of resolving an entry separately from resolvingdefaults
. By defaultresolve_entry
is an alias ofresolve
.I then changed the calls to
resolve
to useresolve_entry
in cases where they are resolving entries.What should reviewers focus on?
🤷
The impact of these changes
Fixes #617.
Testing
I added the regression test from #620 to show that it works with the existing Rails calls.