Email Notification in different languages

[gowthamanbalu]

Hi Team,

I thought of seeking help/advice from this group on one of the requirements I received.

Here it goes.

As We have diverse clients across geographical locations, ServiceNow email Notifications should be sent in the language selected in user profile (Only user prefers to receive notifications in their language).

1. Rather creating multiple notifications (i.e. Having same notifications in different languages), could we dynamically translate the notification content to the selected language? - ( I agree, it's a invalid ask)

2. If we have multiple notifications (i.e. Having same notifications in different languages), how could we handle and relate them to user profile?

3. Do we have any other alternate method to fulfill this requirement!! Thanks for looking into this!!

Regards, GB

[Mark244]

Hi Chuck, what about situations that require the email notification to go out to multiple recipients - for example, if an email was going to members of the Watch list or Work notes list?  Many notifications in ServiceNow get sent to multiple users at a time and we are trying to find a good solution that doesn't require a long multi-lingual email or iterating through the list of users and creating events for each user based on their language.

[Chuck Tomasi]

Hi Mark,

No, the event driven/multiple notification scenario will not address recipients of multiple languages, then again nor will anything else. To appreciate this, you have to realize that only one message is being sent. The To: field is identifying the recipients (which could very well be a group of people with different languages) and the Cc: field, which also has more recipients. If you were to try this in Outlook, you're only sending on message to several people.

In order to do this, you would have to rework the way mail is sent to ensure only one message is sent to each recipient, thus losing the Cc or multiple recipient capability and making it a bit inefficient.

[AndyLock]

We have the same 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 proposal by b-rad 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?

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.

[Rushikesh Mandh]

How come there no ServiceNow recommended approach to translate the notifications despite being a common requirement across all the customers? It's quite surprising that neither there's a mention of notification translations in documentation nor any convenient OOTB way even till London release.

[AndyLock]

Hi @Rushikesh,

I agree that this is a royal pain if you deal with very many languages, like many companies now have to. I worked out a fix for notifications that go to a specific caller, using translations in the sys_ui_messages table:

First I created a simple script include that emulates gs.getMessage, but it gets passed a parameter for the language, rather  that relying on what the system is set to:

function findMessage(messageKey, messageLanguage) {
var message = (messageKey + '.');
// the above  suffix '.' is useful for debug and for printing a template definition by using a caller with a dummy or non-defined language.

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;
 }
}

We then created a new version of the default mail Scripts to use findMessage instead of getMessage. Here's an example of the Mail Notification Script 'Incident Has been Closed', which has the original getMessage part commented out and the new version added beneath.

(function runMailScript(current, template, email, email_action, event) {
 template.print('<p><font size="5" color="#808080" face="helvetica"><strong>');

// template.print(gs.getMessage('Incident has been closed') + '.');
     template.print(findMessage('Incident has been closed',current.caller_id.preferred_language)  + '.');

 template.print('</strong></font></p>');
})(current, template, email, email_action, event);

If you are using Native text then it should all just work, as the translations will already be in the table. If you've created custom text then you 'll need to add the translations to the sys_ui_message table.

As I said, this only works where you have a specific caller identified in the notification. It won't work for groups (who may speak multiple languages), or where the recipient is a parameter. This is fine for us, as all ITIL users speak English, so we only need Incident notifications to go to the caller in their own language, and 'Caller' is specified by the system.

This solution emulates how many of our other international systems work. The benefits are:

• a single, common design for all our caller-facing emails, ensuring consistency for corporate branding and design; 
• The translations can be exported from sys_ui_messages to be worked on by as many native speakers as required. This is often one person per language, so distributing the work is important;
• Importing of new translations can be done in one hit by an admin, without the need to go into hundreds of templates and laboriously type out/paste the new text
• Undoing any work is a simple import of the original text - which of course you kept as a backup 😉
• If you go Native with the text, adding a new language should just work by installing the plugin.
• Having exported and imported a set of translations makes it easy to add a new custom text for a new language. You just add the data to the existing spreadsheet (which is a template for all the data you need) and import it.

Hope this helps.

Andy