(dev/core#1546) Fix translation of seed data #16357
Merged
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.
Overview
This fixes a regression in which seed data is not translated.
(This is a backport of #16356.)
Before
The
civicrm_data.*.mysql
files are not translated.After
The
civicrm_data.*.mysql
files are translated.There's a unit-test to check this.
Comments
This regression stems from #15411, which aimed to allow extensions to define
custom variants of
ts()
. The crux of the issue is "What happens if youtry to translate a string before the system is bootstrapped - before the
extension is loaded? What's your fallback behavior?"
In #15411, it used a fallback behavior of "do no translation". In theory,
you shouldn't really get into this scenario since UIs are pretty much always
generated post-boot.
However, it turns out that there is a situation where you have an un-booted
system and need to translate strings -- i.e. when generating the localized
civicrm_data.*.mysql
data. Hence the bug.This patch preserves most of the changes from #15411, but it changes the
fallback behavior from "do no translation" to "use the built-in/default
translator".