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

(dev/core#1546) Fix translation of seed data #16357

Merged
merged 1 commit into from
Jan 23, 2020

Conversation

totten
Copy link
Member

@totten totten commented Jan 23, 2020

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 you
try 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".

Overview
--------

This fixes a regression in which seed data is not translated.

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 civicrm#15411, which aimed to allow extensions to define
custom variants of `ts()`.  The crux of the issue is "What happens if you
try to translate a string before the system is bootstrapped - before the
extension is loaded?  What's your fallback behavior?"

In civicrm#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 civicrm#15411, but it changes the
fallback behavior from "do no translation" to "use the built-in/default
translator".
@civibot civibot bot added the 5.21 label Jan 23, 2020
@civibot
Copy link

civibot bot commented Jan 23, 2020

(Standard links)

@eileenmcnaughton
Copy link
Contributor

@jusfreeman I believe you were describing this bug just now

@agileware-justin
Copy link
Contributor

Thanks @eileenmcnaughton

Please note new nic :)

@agileware-justin
Copy link
Contributor

Actually, I don't think this PR fixes the bug I was describing today, which is basically this:
When you select a language during the first CiviCRM installation screen, that choice is not then applied to all the relevant localisation settings.

I will do a Gitlab for that one l8r.

@eileenmcnaughton eileenmcnaughton merged commit bc35797 into civicrm:5.21 Jan 23, 2020
@totten totten deleted the 5.21-gencode-ts branch January 23, 2020 23:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants