Best Practice for Translating Emails?

[Nick Peters]

We support 5 languages in total in our instance. Translating Catalog Items, Item Variables, and Question Choices has been fairly easy for us since the fields that we need to translate are the Translated Text or Translated HTML type. We have created a "translator" role, assigned it to a group, and configured ACLs that grant write access to specific fields in these tables to users in that group via the role. We have them sign into our Dev environment and have them make their changes which are captured in auto-generated Update Sets (one for each language). At the end of each month, I review the Update Sets to ensure accuracy and move forward with testing and ultimately implementation of the Update Sets to our Prod environment.

What is the best practice for translating emails, since none of the fields are configured as translated fields? We would like to empower our select few users that we have given "translator" access in Dev to translate emails as well. Up to this point, we have been creating emails in English and sending the Subject and Body to these users to translate. When we receive the translated version, we create a copy of the English email in the respective language and apply any necessary language conditions/restrictions.

Just looking for some helpful advice on how to proceed. Thank you!

[Jan Cernocky]

As Paul says, mailscript is the way.

Same solution was implemented by our SNow partner for our 8 language mutations.

And thanks for the tip of a translator role, how did you autogenerate the update set?

[Deepak Negi]

Try this if there is 1 recipient, e.g Assigned to, Caller etc

Multilingual Notifications- NOW made easy! - Now Platform - Article - ServiceNow Community

Regards

Deepak