VA & Dynamic Translation and languages which are not supported by ServiceNow platform

[John Moon]

Hello,

I'd like to check if VA topics can be translated into languages which are not supported by ServiceNow platform when I use dynamic translation.

If not, is it possible to translate a non-supported language sentence that is typed in VA into English and vise versa with dynamic translation?

Thanks,

John

[Alex Coope - SN]

@Max Nowak,

In the scenario of needing a language that we don't provide a Language Pack for, you actually only need an entry in the [sys_language] table (as detailed in our training course here) which a user can then set their preference to. This is needed, so that DT understands the intended target language to request translations to,

• If you don't add UI translations for that language, then that starts opening up the conversation around "what is a good UX" which I've posted about on my blog quite a bit about available here.

When text is parsed either through DT or to a CloudMT provider, we always analyse it's language as the source language (even if English is not entered and the text is in another language) but we just need to know the intended target language for the user,

Many thanks,
kind regards

[Max Nowak]

Hey Alex,

Thanks for your reply. Does this really work for you? Maybe there's something wrong with my instance, but I read a few of your posts yesterday, and you mentioned this somewhere else, but it doesn't work for me.

See the following example:

I have set my user's language to French, which is actually a language pack we have installed. My platform language is still english, it's just that I selected French in the "preferred_language" field on my user record.

I'm pretty sure that at least some places use gs.getSession().getLanguage() to determine the current language, and this still returns the platform language, not the language specified in preferred_language:

gs.info('User language: ' + gs.getSession().getLanguage());

*** Script: User language: en

When trying to translate something that's written in english, according to your explanation, I would expect it to be translated to french, since this is what I selected as my preferred language, but:

I'd be really, really glad for further help, because I have spent upwards of two days trying to understand how dynamic translation (especially in the context of agent chat) works, and if there was some place where I could specify a language that's used as target language, but is not the user's platform language. It's a little frustrating.

I also understand you concern UX wise, but my issue mostly concerns agent chat. We might have a technician from Malaysia chatting with an agent in Germany for help, and while it's easy to say "all chats have to be in english", we have noticed that people are usually just better in expressing problems in their own language. Since Malay is not a language where ServiceNow provides a language pack, and we currently don't have the capacity to implement our own translations for basically any country / language you could think of that doesn't already have a language pack, having the possibility of using a translation provider to at least translate the communication between agent and technician would be a huge benefit for us.

[Alex Coope - SN]

@Max Nowak,

Yes it works for me. In the below example, my instance's system default language is English, yet my user in this example has their preferred language set to French. When I go to an incident and want to translate the Short Description value (written in English) I can translate it to French (this is also the logic for Agent Chat per participant of the conversation):

At a guess, I would suspect your user might not have their language set correctly. In that, there's also an entry written in the [sys_user_preference] table called "user.language" (per user) when you change your language. I'm willing to wager that the entry for your user has a contradictory "en" value, if it does then change it to "fr" log out and log back in and see if that solves it,

Many thanks,
Kind regards

[Max Nowak]

@Alex Coope 

You're correct, I only changed the preferred_language field on the user table. My requirement is, essentially, to allow translations to any language, regardless of what the user has currently selected as instance language, or what ServiceNow supports via language packs - that's why I hoped that changing the preferred_language field would be enough.

I can see now that I could achieve this by adding any language we need to the sys_language table, regardless of if there are translations available or not, because the instance language will still be english if there are no translations available. I added Malay to sys_language and then selected the language via the settings menu, after which the instance was painfully slow and it took a few minutes to actually load anything, but maybe that's normal when using a language that hasn't been used before.

After while, it actually worked though, and I could translate to Malay! My only gripe is the language translation labels ([ms]) on all labels, but I guess I can remove those entries from the sys_translated table.

Thanks for pointing me in the right direction, I have wasted a lot of time trying to find the entrypoint to the translation subflow to override the target language, but I think this works as well.

[Alex Coope - SN]

@Max Nowak 

Ok so there's a few things to unpack there,

• Language Packs are just data of translations of the OOtB UI (by installing a Language Pack you are populating the [sys_language] table with a language entry and the 5 UI translation tables with the translations of the OOtB UI in that given Language.
• A User can only select a Language preference (either via the "preferred_language" field on their user record or via preference) if that language in the [sys_language] table is active (which is either via a Language Pack install or a new record for a self-localized language).

What you're describing about the performance and the addition of "[ms]" on labels (which would be in the [sys_documentation] table because that's where field labels reside, is because you almost certainly have the "translate and learn" property enabled. This property is designed to create "stub" records in the 5 tables when-ever a translation in that target language doesn't exist, so you can easily export them and update those records for UI translation. If you'd like to learn more about the 5 translation tables, check out my blog post here,

So, feel free to turn that property off if you don't need it (because it's not supposed to be left on all the time). It's also important to add, that Dynamic Translation is not for translating the UI (I've blogged about this topic, as well as what use-cases it is for),

Ultimately, for Dynamic Translation to tell a CloudMT provider what language it wants translations for, it will need a data-point. In this example it is nearly always that of the user in question (driven by values in the [sys_language] table being active and associated either by the sys_user.preferred_language field or the sys_user_preference for that user called "user.language"). These two values should always be matched and therefore the same but I am aware that there was a bug which should be fixed either in SanDiego Patch 5 or Tokyo,

If you'd like to learn more on the topic as a whole, check out our CSC page here, and our dedicated forum (which is where my blog is located),

Many thanks,
Kind regards