Can we use gs.getmessage() to enable email translations

AndyLock
Mega Guru

We have an issue where we will have ELEVEN languages for end users (not ITIL users, who will use English), and possibly more languages in the future.

The workable proposals by b-rad and Chuck to create a language version of each end-user email, a matching rule to trigger the email to be sent in each language, then managing the portal translations in different place is one that's repeated everywhere I look. It's a solution that is probably OK with just two or three languages but, for our scenario, eleven or more languages appears un-scalable and inelegant.

I would prefer to leverage gs.getMessage() for end-user emails (where it goes to only the caller) so that both Portal and Email translations are held in just one place. This way translations can easily be managed by native speakers on a spreadsheet, then imported/updated by admins to the sys_ui_message table. No need for admins to go into each email template to change the wording for the 'Take me to the incident' button, or to create new triggers and templates for a new language - we can do it in one place from a single import from work done by others, and simply make sure the new language appears in the language picker.

I realise that gs.getmessage() is designed to work on the system language by default, so my question: is there a way that we can force a certain email to reference the user language instead of the system language?

EDIT - If there is a way to use the sys_iu_message table based on the recipients language, can you please provide details on how.

Note: emails going to multiple recipients would be in English. The decision to use system language or user language should be configurable per email, ideally by a common script that can be added to an event or a template.

thx,

Andy.

5 REPLIES 5

AndyLock
Mega Guru

Many thanks for your help, guys. I wrote my first script and it seems to work 🙂

Note that the prefix NB_ is used because it's the initials of the company I work for.

I solved the problem like this -

First I created a Script Include called findMessage()
This script is passed the Key and Language then returns the match from the sys_ui_message table (or returns the original key if no match is found).

function findMessage(messageKey, messageLanguage) {
var message = (messageKey);
var msg = new GlideRecord('sys_ui_message');
msg.addQuery('language',messageLanguage);
msg.addQuery('key',messageKey);
msg.query();
if(msg.next())
 {
   return msg.message;
 }
else
 {
  return message;
 }
}

Next step was to find all the incident notifications that went to the caller by using this filter:
collection=incident^recipient_fields=caller_id

By looking at the 'What it will contain' tab for all these notifications I could make a note of all the scripts that might need alternative versions that use findMessage()

I then replaced getMessage() with findMessage() in my own version of all the email scripts.

For example, email script 'incident_has_been_opened'  was inserted as a new version 'NB_lang_incident_has_been_opened' with these modified script details:

(function runMailScript(current, template, email, email_action, event) {
 template.print('<p><font size="5" color="#808080" face="helvetica"><strong>');
// template.print(gs.getMessage('An incident has been opened on your behalf.'));
 template.print(findMessage('An incident has been opened on your behalf.',current.caller_id.preferred_language));
 template.print('</strong></font></p>');
})(current, template, email, email_action, event);

You can see where I commented out the original getMessage() section and replaced it with findMessage() plus the parameter current.caller_id.preferred_language

Then I inserted new versions of the notifications that used the new versions of the above mail script(s), for example, the Message HTML for "NB Incident opened for me" included three new versions of each line:

${mail_script:NB_lang_incident_body_header}
${mail_script:NB_lang_incident_has_been_opened}
${mail_script:NB_lang_incident_take_me_to_the_incident}

Finally I disabled (Active=false) the original "Incident opened for me" so that only new version was used.

 

I suppose I could have altered the script to dynamically change the Subject (you can't include a mail script in the Subject field), but to simplify things I changed the subject to: ${number} - ${short_description}