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

WorkflowMessage - Allow more dynamic-localized data. Unify language field. #26618

Merged
merged 11 commits into from
Jun 23, 2023

Conversation

totten
Copy link
Member

@totten totten commented Jun 23, 2023

Overview

Make it possible for bespoke methods in WorkflowMessages to generate localized content.

Before

There is a schism in how MessageTemplate::renderTemplate() handles languages -- there are:

  • $params['tokenContext']['locale'] (re: token-rendering), and
  • $params['language'] (re: template-selection).

At the time that the WorkflowMessage is evaluated ($params=exportAll(importall($params))), the[tokenContext][locale] is available to the WorkflowMessage, but the final version of language) is not available (because the template hasn't been loaded yet).

After

The same locale variable is used more consistently. The two properties are aliases. The template-selection is done while WorkflowMessage is being evaluated.

Technical Details

There is a trade-off here - that alterMailParams will no longer influence the loading the template. But it should mean that WorkflowMessage classes get better to the effective locale. Eileen says she searched universe and didn't think anyone would be affected.

There were lots of other little bits needed along the way. I don't know if all of this is a good idea, but it's probably not terrible.

totten added 10 commits June 22, 2023 17:26
…essage-template content

While rejuggling the order of operations in `renderTemplateRaw()`, this
helped some tests (like `testRenderDefaultTemplate()`) pass.
There's no particular sense to this, except that it should help the next refactoring steps.
To r-run this, I used the following procedure:

* Take an arbitrary `Contribution` from example DB (eg id=100)
* Update in SQL (`SET is_test=1 WHERE id=100`)
* Send mailing with `cv api Contribution.sendconfirmation id=100`
* Check email log
@civibot
Copy link

civibot bot commented Jun 23, 2023

(Standard links)

@civibot civibot bot added the master label Jun 23, 2023
@totten totten changed the title (WIP) DGWDIWT WorkflowMessage - Unify handling of locale/language property Jun 23, 2023
@totten totten changed the title WorkflowMessage - Unify handling of locale/language property WorkflowMessage - Allow more dynamic-localized data. Unify language field. Jun 23, 2023
@eileenmcnaughton
Copy link
Contributor

In my testing this didn't work entirely as I expected - in that

  • I expected the render locale to be set as the global when rendering, as it is for tokens but
  • the actual is that I have to actively add it
    return \Civi::format()->money($this->totalAmount, $this->currency, $this->getLocale());

I'm not too sure what I think of that but it means it is at least possible to get the locale consistent, even if it does require some diligent remembering

I'm merging this as a clear improvement

@eileenmcnaughton eileenmcnaughton merged commit 9f04857 into civicrm:master Jun 23, 2023
@totten totten deleted the bb branch June 23, 2023 22:55
eileenmcnaughton added a commit to eileenmcnaughton/civicrm-core that referenced this pull request Jun 25, 2023
eileenmcnaughton added a commit to eileenmcnaughton/civicrm-core that referenced this pull request Jun 25, 2023
totten added a commit that referenced this pull request Jun 26, 2023
Follow up to #26618 - set locale consistently when exporting model
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.

2 participants