-
-
Notifications
You must be signed in to change notification settings - Fork 827
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#4409 Use translation for default language, if exists #26232
Conversation
(Standard links)
|
8fdac5b
to
f77d934
Compare
test this please |
f77d934
to
52f8265
Compare
Includes civicrm/civicrm-core#26232 This also includes removing the renderQA magic. While I kinda like this it was superceded by the MessageAdmin UI and actually I suspect no users really ever used it. Keeping the code keeps the data-translate path alive & increases our complexity Bug: T325698 Change-Id: I36eecec156ca3f80bc68a2df8b96ecb70ce41b83
There is an assumption in the code that for the default language a translation is not used. However, the features around draft versions are all set up around translations, so it becomes necessary to create translations even for the default language. This change ensures they are used if they exist. Although we have a lot of complexity in the translation framework on the rendering side I think assuming that where stuff is configured people configured it to be used is a good underlying principle.
49489f5
to
2ec434c
Compare
@eileenmcnaughton - OK, so the general idea of defining a localized template for the default locale seems OK to me. There's an edge-case to clarify, but I'm OK with it as-is. For r-run, I defined templates for these locales (each with a different subject): Then I chose a contact and repeatedly registered for an event (but with different values for the recipient's
Drilling down on a few scenarios:
I think this is mergable because the modified scenarios (
|
Hmm - yeah I thought 6 was winding up back on the site-language because of the changes I had to make to the test - oh - but that is a partials vs no partials. I wonder why that isn't winding up on en_US in sceanrio 6 |
This addresses scenario 6 here civicrm#26232 (comment)
This addresses scenario 6 here civicrm#26232 (comment)
Overview
There is an assumption in the code that for the default language a translation is not used.
However, the features around draft versions are all set up around translations, so it becomes necessary to create translations even for the default language. This change ensures they are used if they exist.
Before
It is possible to create a translation for the site default language, and the presence of the draft / approval flow makes this a good thing to do. However, the
render
function will ignore itAfter
If it has been created it will be used. Note that the check for 'any' of the given language is primarily about performance, not functionality - everything falls back to the message template if there is no translation.
Technical Details
Although we have a lot of complexity in the translation framework on the rendering side I think assuming that where stuff is configured people configured it to be used is a good underlying principle.
Comments
https://lab.civicrm.org/dev/core/-/issues/4409