Send out emails in patron's preferred language

We did something like this years ago via a combination of editing the default template, the use of patron statistical categories for language preference, with a fallback to the language preference at the actor.org_unit level. Happy to share what we've done, but I don't think it's very generalizable for inclusion in core.

As a first stop-gap measure, I think it might be good enough to just have a user setting for "Preferred language" - assuming that value is available via templates, it wouldn't be too onerous to hard-code for the 2 or 3 languages in IF ... ELSE blocks

There is a template function helper.get_user_locale(user_id). It starts by checking the value of the 'global.locale' user setting and falls back to another function which looks up the default locale for the home org unit of the user. The problem is that "global.locale" does not actually exist yet as a config.usr_setting_type entry nor is there any UI for applying a value.

We'd need to insert "global.locale" into config.usr_setting_type and add a selector to the patron edit UI (as suggested). The rest is done.

Just to be clear, by "the rest is done", I meant in regards to the stop-gap measure of using IF blocks within the templates.

A possible future direction could be to break action/trigger templates out into their own table, give each a locale (and maybe some other stuff), and link them back to the their parent event_def. That's a considerably larger project, though.

If only it was possible to use the l() macro in the tt2 templates in the database, even if the locale had to be set manually in the template...

Linn-Benton Community College has signed a contract with Equinox to address this bug, as part of a grant provided by the Institute of Museum and Library Services through the Library Services and Technology Act, administered by the State Library of Oregon.

A patch to add this functionality is at https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=2542925ced2283f61fb9f8a2fc2e8a20e7eabaf6

follow up commit with commas fix: 3b60d2f80764a16b3d58241580b769c7f6d862b1

There is one particular point to this patch I would still like feedback on.
The implementation assumes that in an effort to not check every event that the
logic only applies to events with the SendSMS, SendEmail, or ProcessTemplate reactors.
However, any event could potentially create a patron message so we may want to expand
this to all possible events which would be simple to do if we want to go that route.

From the commit message:

This feature supplies the ability to create alternate templates for Action Triggers
that will generate locale-specific out for Action Triggers. If you send notices in
multiple languages, we recommend putting some words to that effect in your notice
templates. The template, message, and message title can all be localized. To use the
feature the following new UI elements have been added:

- When you double-click on an Event Definition under Notifications / Action Triggers
  to edit it there will be a tab option for Edit Alternate Template if the reactor is
  ProcessTemplate, SendEmail or SendSMS.
- In the Patron Registration and Patron Editor screens staff members may now select a
  locale for a patron and edit it in the Patron Preferred Language field.
- Patrons may set their own locale in the My Account interface off the OPAC by going to
  Preferences -> Personal Information and setting the Preferred Language field.

The templates used on the Edit Definition tab are the defaults that are used if there are
no alternate templates available that match the preferred language. If alternate templates
are available the system will use a locale that is an exact match and then if failing that
use one where the language code matches and then fall back to the default one.

For example, if a patron has a locale of fr-CA and there are templates for both fr-CA and
fr-FR it will use the fr-CA. If the fr-CA template was deleted it would fall back on using
the fr-FR for the patron since it at least shares the same base language.

Valid locales are the codes defined in the i18n_locale table in the config schema.

Thanks so much, Rogan. Such a long-awaited feature!

2 things:
* I saw that angular.json now includes an analytics id, which I think should be removed from this patch.
* I did some light testing of this feature when I was at Linn-Benton, and it works well! I'm not ready to sign off until doing some code review and Rogan gets an answer to the question he posed. But I am feeling good about this feature!

Hi Rogan, there are commas missing at the end of line 74 in 005.schema.actors.sql and line 277 in 400.schema.action_trigger.sql preventing new databases from being created. Can you add a commit to that branch to fix those files?

I took a look at this - added Patron Preferred Language = Spanish to a patron and enabled the 3 day courtesy email, with an alternate template with locale Spanish.

For the template I copied the original message and added a hunk of random Spanish.

I clicked Run Tests, using an item checked out to my test patron. Nothing happened - is it because this is a test server and not fully configured, run tests doesn't work, or did I do something wrong with the alternate template?

Also - I have, in our live 3.6 server, tried to add Spanish text to notices (in addition to the English text), but the accent marks did not render correctly in the resulting notices. I tried several hex codes, entity numbers, etc. Will that problem be addressed with this functionality? Lack of proper characters is a deal breaker for my libraries.

I'll check the outgoing mail on pattypan, that may not have been enabled.

Lindsay, you mentioned hex codes and entities, did you also try directly inserting correctly entered accented characters and it still caused problems? It's possible that the encoding gets messed up at some point in between the ui, database, and the SendEmail A/T reactor. I don't think there is any special type of escape that works though; HTML entities won't work because the backend isn's using that, and I don't think perl escapes would be supported (not that anyone should have to know those anyway) in the modules we're using either.

Update: sending emails from that machine now works as expected.

Re: accents -

I did try just entering the accents, and in the in-client test the characters render correctly:
"Dear Lindsay Testuser,

According to our records, the following Library materials are past their due dates and may be accruing fines. Please return the items at any WLS library. Thank you!

No sólo sobrevivió 500 años, sino que tambien ingresó como texto de relleno en documentos electrónicos, quedando esencialmente igual al original. Fue popularizado en los"

However, in my email (Gmail, in Chrome, same result no matter what language settings I applied to gmail) it was garbled:
"Dear Lindsay Testuser,

According to our records, the following Library materials are past their due dates and may be accruing fines. Please return the items at any WLS library. Thank you!

No sólo sobrevivió 500 años, sino que tambien ingresó como texto de relleno en documentos electrónicos, quedando esencialmente igual al original. Fue popularizado en los 60s con la creación de las hojas "Letraset", las cuales contenian pasajes de Lorem Ipsum, y más recientemente con software de autoedición, como por ejemplo"

If that was on your 3.6 system that may be an issue with the old Dojo A/T interface. (Another great reason to get rid of Dojo.) I've tried out the branch for this again after enabling email and everything looks like it comes through ok to me.

UPDATE: the below is wrong, but hey, I wrote it. :) The feature isn't in the user settings block where I was looking, it's a field directly on the actor.usr table so it's up above near the photo url and staff can edit it just fine.

Something to note for testing: Staff can't change this setting for patrons, so you'll want to sign in to the opac somewhere to change the preferred language setting to test it properly.

Noting that the field should be available in the patron editor and registration in the staff client. The field should be "Patron Preferred Language" right under "Photo URL"

I've added a follow up commit to fix the issue jboyer found at 3b60d2f80764a16b3d58241580b769c7f6d862b1 I've also edited the message above to have it and the original in the same place.

I've pushed a rebased branch of this to https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp1091588_localize_action_triggers that signs off the main commit and squashes Rogan's followup commit as well. Hopefully this will make merging simple ... *hint, hint*

Thanks, all!

Thank you so much, Rogan and Mike! This works well for me. Pushed to master, with a slight tweak to remove the analytics ID in angular.json.