-
-
Notifications
You must be signed in to change notification settings - Fork 824
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
Message Templates - Allow rendering & previewing of translated messages #24174
Conversation
(Standard links)
|
That is an odd conflict @totten - maybe we should just merge that unhide since we should be able to sort the rest before the next forking (we REALLY want to wrap it up this week or next) |
5253c13
to
2c601ee
Compare
I just rebased out the 'unhide msg_admin' commit as it is otherwise merged |
The error is an uncaught Exception
|
I pulled out a commit to get it merged & reduce the noise of this #24281 Not too sure about that exception though |
Rebased to hide some bits that we're merged. Added a fix for the |
nope - that didn't solve it
|
ac2a248
to
8169749
Compare
test this please |
That's better - twelve clear fails - I suspect this might account for more than one... CRM_Utils_TokenConsistencyTest::testDomainNow |
$languages[$field['language']][$index] = $field; | ||
} | ||
|
||
$bizLocale = $userLocale->renegotiate(array_keys($languages)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This really stumped me - I couldn't figure out what Biz Locale is - 'Business Locale' 'Bees Locale' 'Random Prefix Locale'?
I feel like maybe this is the ResolvedLocale?
Fails are getting more clearly related now & api_v3_MultilingualTest::testOptionLanguage with data set "APIv3" (3) |
I pulled out a couple of test tweaks to a separate PR. I don't hold up much hope of this unblocking us but it makes me feel a little less helpless :-) #24369 |
Thanks for pulling those out @eileenmcnaughton. I'm rebasing and squashing a couple of the "fixup" commits. I'm glad the test-results actually show the failures now... :) |
f0af670
to
c618487
Compare
b821944
to
f148983
Compare
still passing - we need the next chunk huh? |
Attempt to pick off language not working yet - #24430 |
The functionality is bigger than `MessageTemplate`, and the test is fairly long.
Move hook_civicrm_translateFields from message_admin to core Move hook_civicrm_translateFields from message_admin to core m
…der the translated version
…n get/render the translated version * Updates for APIv4 calls * Set `$language` and `#ranslationMode()` instead of `$preferredLanguage` * Read 'actual_language' instead of `getTranslationLanguage()` * Updates for tracking global locale properties * Use `$loacleObj->moneyFormat` instead of `$GLOBALS['moneyFormatLocale']` and `IGNORE_SEPARATOR_CONFIG` * Use `$tokenContext['locale']` instead of `$GLOBALS['moneyFormatLocale']` and `IGNORE_SEPARATOR_CONFIG` * Split `testRenderTranslatedTemplate()` in two (for different configurations)
f148983
to
0fa49e7
Compare
I rebased out the merged changes |
translationMode
Yay - the bug is fixed - talked with Tim & we are ok to merge |
translationMode
@eileenmcnaughton I did a pass on updating the description. |
unrelated fails |
yay - thanks for that update |
Overview
Allow
MessageTemplates
to be translated. This PR builds on prior work (ext/message_admin
) which allowed the administrator to create+edit translations, but this update is needed to render, preview, or deliver the translated templates in fully localized form. There are a few major sections in this branch.(1) APIv4 Translation Mode
Suppose you read a record (such as a
MessageTemplate
):This returns the canonical record. However, there may exist
Translation
records for thisMessageTemplate
. If you actually want to use those translations, then you must lookup theTranslation
s and synthesize an effective/de-facto template.The PR adds an option
$translationMode
which will automatically lookup the best available translation. It currently supports two modes, fuzzy (opt-in) or off (default/status-quo). For example:This first loads the canonical version of the
xxx
template, and then it attempts to translate (replacingmsg_subject
,msg_html
,msg_text
with localized variants). It will use the active language (fr_CA
) and look for the closest matching template. The choice of "closest" is based inCivi\Core\Locale::renegotiate()
:fr_CA
), use that.fr_FR
), use that.Note that the translation-mode is emphatically superficial. It modifies the output of a basic
get
request. It does not support other operations, such as writing-back translated data or filtering/grouping translated data. It is difficult to define an automatic/one-size-fits-all behavior for those operations. (You can use theTranslation
API instead.)However, for basic application-usage (fetch and display record X), it is much easier to read data this way.
Recap:
Translation
API.(2) Message Template Runtime
There are various APIs for using
MessageTemplate
s. These are slight permutations on the same basic mechanism:CRM_Core_BAO_MessageTemplate::sendTemplate()
CRM_Core_BAO_MessageTemplate::renderTemplate()
Civi\Api4\WorkflowMessage::render()
In each case, it is possible to either (a) pass in a specific template or (b) autoload a template by name. The PR changes the autoloading rule:
preferred_language
. Otherwise, continue with the canonical message-template.(3) Message Admin UI
The
message_admin
UI allows you to create and preview translated templates. However, it needed a fix to render the tokens in the intended locale:Comments
There is a long list of locales supported for communication purposes (ie
preferred_language
; ielanguages
) - it is longer than the list of locales supported by the CIviCRM application. This is not necessarily a problem - but it can be. (Some mail-tokens may require l10n resources. But tokens are discretionary, and there are often similar/close-enough resources available.) To get the best support for many languages, enable the "Partial/Mixed Locales" option from #24403.Development History
This PR builds on #24116 and #23844. Major differences relate to:
setPreferredLanguage()
in two:setLanguage()
is basically as before, but promotedsetTranslationMode()
is the new mechanism that autoloads translations, and it only applies to DAOget
$moneyFormatLocale
into an object (along with$tsLocale
and$dbLocale
).Locale
object and make fallbacks more generalThis PR was used as an exploratory branch for patches in inter-related areas, so the history is quite long. Several elements were subsequently re-split. This includes smaller cleanups (#24281, #24284, #24369, and #24400) and more visible functionality (#24269, #24430 and dev/tranlsation#78's #24403).