I recently had a client (a sizable multinational with employees speaking 9 different languages) that needed real-time translation inside of ServiceNow.
The translation of labels on a given form–and of UI Actions–is already built in. It’s not real-time, but the translation plugins for the various languages already have translations defined for the baseline labels.
Translating things like description, short description and resolution notes (especially in real-time) is a whole different ball game.
I created some custom tables, set up an outgoing REST message, and then did a whole bunch of coding. I can’t give away any of the secret sauce, but here is the outcome:
First we start with a standard incident with the short description and description populated with English. You’ll also notice that we’ve got two new buttons at the top of the form, ‘Translate’ and ‘Translate Notes’.
Next, you can see a screenshot showing the same incident, but with the user’s language switched to French. You’ll notice that the labels are translated (‘Caller’ is changed to ‘Appelant’), which is standard with the French Translation plugin.
The ‘Translate’ and ‘Translate Notes’ buttons have been translated, but the values in the description and short description fields are still in English.
Then, after clicking the ‘Traduire’ button, French translations are added below the short description and the description fields. (In the blue field decorator.)
Then, if another user (with their language set to Spanish) opens up the same incident, the labels and buttons are both translated, but since the ‘Translate’ button hasn’t ever been clicked by a user with Spanish set as their language, we don’t have a translation for the description or short description.
Once the ‘Traducir’ button is clicked, the Spanish translation is displayed.
Below is a screen shot of a new incident, once again in English. This time from the service portal.
Here is the same incident, this time as it would be viewed by the ITIL user with their language set to Spanish. The additional comments in English that were visible on the ESS view are visible here as well, untranslated.
Clicking the ‘Translate Notes’/’Traducir Notas’ button brings up a UI Page with the original value in English in the 4th column, and the Spanish translation in the 5th column.
Looking at this particular screenshot, I can see that I probably should have made the title “Work Notes & Additional Comments” and the work_notes/comments label in the second column dynamic. I should also probably duplicate the Spanish value from the 1st row, 4th column and push it into the 5th column. I’ll have to circle back around to the client and see if they want that change made.
Finally, here is the ESS view with an English translation for the Spanish additional comments response which was input by the ITIL User.
There were some other wrinkles with this particular engagement that I won’t go into here, but overall I’m very pleased with how everything came together.
It would have been very easy to set the description, short description, and resolution notes to translate automatically rather than requiring the user to click a button, but there was some concern about things being translated unnecessarily.
I did however set it up to re-translate anything that has been previously translated if the source value of the original field is changed. All of the translations are saved off so that the API doesn’t have to be called (and charges incurred) unless the value of a field changes, or a particular field hasn’t ever been translated.
There is an app on the ServiceNow store with a price tag of $9,500 per month that has a few extra bells and whistles, but this replicates a significant chunk of the functionality, and the only ongoing charge is a $20 per million characters.
I think this is a big win for everyone involved, and I’m happy to have been able to automate the translation process so that the ITIL users at that company can spend more time doing other, higher-value work instead of manually translating incidents.
Hello Dean,
I am happy to discover your site.
As your article was published in April, I suspect that you were working on Madrid (or a previous version).
Please, do you have any inputs on limit (or weakness) of translation plugins in New-York?
Thanks,
Sandrine
Sandrine,
Apologies that I didn’t see your comment sooner–most of my comments at this point are spam and my consulting work has kept me unusually busy for the last few months.
Yes, I was working on London when I did the translation work.
I haven’t used any of the translation plugins in New York. I saw a couple in the store at the time I was working on the translation project that I blogged about. I don’t remember much about one of them, but the other one struck me as being really, really expensive.
I know that ServiceNow is rolling out some functionality that ties into flow designer. I don’t know what the pricing on that looks like, but knowing that it’s ServiceNow, I expect that it’s pretty expensive as far the ServiceNow licensing goes, and then I would guess that it’s still built on Google’s translation API, so you’d still have that fee in addition to the ServiceNow stuff.
If you’re translation needs are relatively limited in scope, you may find that you’re better off just tying into Google’s translation API yourself.
I put ~170 hours total into the translation project I worked on, but I was super green and went down some dead ends along the way. If you’ve got access to a more experienced dev, they could probably do it on 80-120 hours.
There are probably a lot of organizations where that isn’t the right answer, but that approach would give you a one-time cost to get the translations up and running, and then after that you’re only paying API fees to Google.