In-Platform Language Support Guide

This post will act as a stickied one stop shop with as many useful links as possible on the topic and will be regularly updated. 

This post is currently being updated with some of the new features in Yokohama. Keep coming back often to see what's added.

What is Localization?

At a high-level there are a few key phrases to be aware of so that all of the following will make sense:

If you notice very carefully, you'll also see that each term has a short-hand which is based on the first letter of the word and the number of letters between the first and last letter of said word. E.g. with "internationalization" being shortened to "i18n" there are 18 letters between the "i" and "n" in English. As such, this helps anyone understand the topic of discussion when speaking in another language as these are industry standardised terms. 

As I'm sure you can imagine, all of this requires some careful planning:

So before thinking about Languages specifically, there needs to be some careful consideration of the region (or regions) to be covered which can (or likely will) determine what languages that need to be used. Coupled with also considering what content / material / UI's are to be "localized". This is a super important concept because it's not just about Languages as you will likely need to factor in and potentially cater for local culture and / or customs to really make the content the best it can be for your intended audience.

For example if we look at English we can see that there are variations between US English, GB English, Australian English etc:

• We'll go into more detail about regional variations related to this further down in this post.

So, consider the Geography, any local customs, styles, customs etc of your intended audience to help plan your next steps, which in-turn will help make adoption be the best it can be.

What is a Language Pack?
Before we delve into what Language packs we provide, lets explore what a "Language Pack" is. Essentially a "Language Pack" is a plugin / package of all of the OOtB UI translations in that given language. Typically these are everything in that given Family release (e.g. Quebec), which means all of the other plugins available in that Family release will also be included in a Language Pack. 

For example, whilst HR or CSM plugins are not enabled OOtB on an instance, the plugins are contained in the Family release so when a Language Pack is installed it will automatically install all of those translations as well rather than having to re-process after each feature plugin activation. 

It's important to note that there are some store apps included via this method, however due to the sheer size of the language packs (~4.5m source words per pack) we're currently trialling new methods of distribution to make it quicker to install a Language Pack.

The Language Packs themselves populate the 5 translation tables with records for their given language in the following way:

• sys_ui_message - scripted messages
• sys_choice - drop down choices
• sys_documentation - field labels
• sys_translated - translatable fields
• sys_translated_text - translated text / html 

More details of how the tables work can be found in my blog post here.

As a quick overview (from our training courses) here's a recap of what the Tables do:

Globalization Guide

For a list of all Plugins and Store Apps that are translated into what Languages (ootb), please check our "Globalization Guide" here on the CSC - (The guide is updated per release)

The Guide has also been translated into the following Languages (incase you need it);

• Dutch 🇳🇱
• French 🇫🇷
• German 🇩🇪
• Italian 🇮🇹
• Portuguese 🇵🇹
• Spanish 🇪🇸
• Japanese 🇯🇵
• Korean 🇰🇷

MessageAPI aspects

As the MessageAPI leverages the concept of calling "keys" rather than instantiations on specific tables like the other 4 translation tables do, there is therefore a concept to be mindful of called "externalization" and the idea of a "hard-coded string".

Simply put, a hard-coded string is when what you want to be displayed is not being sent to the API necessary to show it in another language and therefore not localizable. For clarity, this isn't a SN specific concept, this is a tech concept in general.

Here's an example using a simple alert() call:

alert('hello world');

In the above example, "hello world" is not externalized which means the platform doesn't understand that it should be shown in another language. If we want to do this correctly we would need to call the MessageAPI like this:

alert(getMessage('hello world'));

There are 3 main ways to call the MessageAPI, which all depend on the type of script it needs to be called from. I've provided the necessary links in the link table below to each of the script types to cover their nuances (Client Scripts, Server Scripts and Widgets).

So the API's to be mindful of (whilst not an exhaustive list) are as follows:

Whilst there are more (such as how portal widgets need to call the API via ${} calls), however as this post isn't about solution design, we'll save that for another post.

Here's a little cheat sheet for the different types of script examples (Client-side script vs Server-side script vs portal widgets):

Note in the image above, we've made some records in the [sys_ui_message] table for the first key example "Test message", we would also need to make another for "This is my text" and another for "Show more" because of what we're passing into the API as a parameter.

It is also possible to develop tools to check for these hard-coded strings, which should be considered a code infraction within your development standards.
If there's enough demand we might release some PoC tools via the innovation area of the Store in the future.

To learn more about "externalization" and to refresh yourself on how the tables work, check out our training course the "Localization Journey" on NowLearning here.

This also means, that when you're developing on the platform and needing to use the MessageAPI, you need to be mindful of what's called a "concatenation". Which is the idea of expanding a string / sentence with multiple aspects. For example, in English it might be nice and easy to append (or prefix) a string with a variable calculated from a query and then send that to the MessageAPI, however whilst nice and efficient from a code perspective it will actually cause increasing degrees of complication for the translator (MT or Human) performing the translation.

As a general rule of thumb think along like this:

The cleaner the string being sent, the easier it is to translate and also the easier it is to UX test in the target language. To learn more about this concept, check out our various training courses linked down below.

What about number formatting?

On top of currencies (the platform has two different monetary field types "price" and "fx_currency"), there are also different considerations to think about for number formats. This is because in different parts of the world, a decimal separator might be a comma vs a dot, or the thousand separator might be a dot rather than a comma (or even a space).

Think the difference between "1 000,00" in somewhere like France vs "1,000.00" in somewhere like the UK as an example. This little detail can be very important in some countries, as they may be only familiar with their specific formatting of such numbers.

To learn more about number formatting in your code check this link on the developer portal:
https://developer.servicenow.com/dev.do#!/reference/api/washingtondc/server/sn_i18n

To learn more about Date formatting (because some locations might use either a different combination to show a date or use a different layout), check this link in the developer portal:
https://developer.servicenow.com/dev.do#!/reference/api/washingtondc/server_legacy/c_GlideDateTimeAP...

In both scenarios, if you need to parse a format, be sure to include the user's specific preference in the return value to ensure what's shown in the UI for them is what they've set, otherwise any custom logic with a forced format will override the end-user's preference (which is not ideal and potentially problematic for the user).

Typically, the way the UI represents a number format is driven by the user's session language, where-as date and time formats are driven by fields on the user table:

^ note the two columns "Date Format" and "Time Format",

Side note - default user currency is driven by the "Country Code" field on the user's record.

There is also a user preference (which the user sets in the UI) called "glide.ui.short_date_format", this is either set to "true" or "false" based on the options in this list:

There is also a preference called "glide.ui.date_format" that will hold the permutation of what they've chosen.

What Language Packs are provided?

At time of writing, we provide 23 Language Packs:

To add some context, in the Paris release each Language Pack was around 3m source words where as in the Quebec release was closer to 4.5m source words.

Important notes -

Install times:
Pre-Tokyo - It would take approximately 2-4 hours to install each language pack which would need to be factored in to any timelines. 
Post Tokyo - After re-engineering how Language Packs install, we targeted less than an hour and in many scenarios it came in around 
30mins on a sub-prod instance. So you should see significant time based optimisations going forward.

UI Language Fallbacks:
Pre-Tokyo - If viewing a UI across the platform in another language, and you came across a missing translation, the default behaviour 
was to always show the English source value.

Post-Tokyo - Because Tokyo supports "locales", it is now also possible to define an alternative "fallback" language. For example, If you 
are translating an instance into "Mexican Spanish" you technically don't need to translate everything because a significant proportion of 
the language is similar to Castilian Spanish, meaning you can set the fallback of "Mexican Spanish" to the Spanish language pack. 
(This particular scenario could prove very useful for back-end UI consistency or Portals that have already been translated in the suitable 
fallback language, reducing the difference / coverage of what in the UI has been translated).

Guest Users:
Pre-Tokyo - Any non-authenticated user essentially inherited the system default language defined in the property "glide.sys.language". 
This wasn't an ideal option for international CSM use-cases, where it's very possible to have unauthenticated users view the portals. 
Changing the language of the "guest" user it-self actually impacted all non-authenticated users.

Post-Tokyo - It's now possible to define "Regions", where a Language can be associated to a Region and in-turn becomes available for 
a non-authenticated user to select. This then gets stored in the guest users's cookie of their session so that the next time they browse to 
the Portal it is remembered, whether they login or not.

Vancouver+
In the Vancouver release, it is now possible for Service Portals to support RtL languages.This can be enabled by following the instructions 
here - see below for more details.

WashingtonDC+
We introduced the Arabic Language Pack.

The Language selector in the back-end is now on it's own "Language and Region" tab, which also moves the "Date and Time Format" 
and "Tiimezone" preferences into the same place.

In the WashingtonDC release, we've also made some significant improvements with some terms that previously weren't translated. 
Here's an example in our Japanese language pack:

If you are a Japanese reader and want to learn more, check out the awesome post by our Japanese Language Lead here.

RtL (Right-to-Left) Language Portal Support
New for Vancouver+, it is now possible to enable RtL UI support in portals. This is enabled by going into the Portal record and ticking the field "Support right-to-left languages".

Below is an example of the /esc portal translated as a demo via our Localization Framework prototype Portal artifact via MS Azure with Dynamic Translation:

^ I have purposefully not translated the KB articles in this screenshot to show the impact of an RtL language.

Beyond the Language Packs, what options are there?
This is actually a really good question because it comes down to use-cases and what the objective is. So whilst the Language Packs covers OOtB UI facets and whilst you can manually add your own we do have a bunch of tools to do more than that.

UI
So, within the UI there are many different components that make it up, e.g. Forms, Portals, Widgets, UI pages, Announcements, Surveys, Workspaces etc.

In Quebec, we introduced the "Localization Framework" to act as an engine to simplify the process of translating what we call "artefacts". And in Quebec we included artefacts for "Catalog Items" and structured "VA Topics".
In Rome we added a few more which I detail in this post here where I explain how you can make your own if necessary.

As of Utah
It is now possible to save translations in dedicated update sets from a sub-prod instance.

Create a dedicated update set for each localization task with the localization task number as the name. When the localization task is 
published, the related translation XML files are saved to the created update set instead of a system update set. You can then easily 
move the translation records across various environments.

More info can be found here.

To learn more about how to set up the Localization Framework, check out this super handy post by one of my colleagues Nilima here. 

The Localization Framework can leverage Dynamic Translation and its spokes to Cloud based MT providers if you have a suitable subscription, otherwise it can be used by translators manually in platform (more detail is down below in a single-pager slide).

Knowledge Articles
Whilst it's been possible for a very long time to manually make translated articles in a KB when the i18n plugin and kB_v2/v3 plugins are installed, in Madrid we also introduced "Translation Management" to make it a bit easier to create them. This can be rule based or applied manually at the KB level, where you can generate the child related articles via the UI rather than needing complex set-ups.

Translation Management can leverage Dynamic Translation and its spokes to Cloud based MT providers, if you have a suitable subscription, otherwise it can be used by translators manually in platform.

In the Tokyo release, we introduced Knowledge article translations into the Localization Framework, replacing Translation Management. 

Knowledge Tips

If you need to search for an article in a language other than your session language, then there is a property called "glide.knowman.enable_multi_language_search", which if set to "true" will return results in what-ever language a search makes a match in.

If you are using the /kb portal or the "kb_search" page in your portal (in-conjunction with the property mentioned above), which looks like this:

This sets a "user preference" for that user called "knowledge.portal_search.language".

Note - this functionality is for when you are not using AI Search in your portal.

AI Search for Knowledge - by Country

If you are using AI search and you want to break out per country search results, then you can now do this by leveraging records in the [sys_language] table with a "locale" code (detailed in the Language section of this post). 

For example, if I wanted to have results for Spain (regardless of language), I can create a locale record in the [sys_language] table where the "id" is es-ES, setting the "fallback" value to the ootb "Spanish" (as this will save me from having to translate everything again - read more about the Language Packs further up). Then, when I have my suitable locale created I can follow the steps here on how to set up a "Country to Language" search.

VA Topics
With the launch of the Localization Framework in Quebec, structured VA topics (ones that aren't expecting a free text response) can be translated via the "VA Topic" artifact. In the Rome release this was expanded out to also create the NLU models in other languages so that the utterances can also be easily localised for the topic being built.

At time of writing this post, the non-English language capabilities within NLU are as follows:

So, with the various features across languages, you can have VA (Virtual Agent) in a scenario like this where some languages are directly translated and store and others are dynamic on the fly as needed;

Agent Chats
This is one of the main use-cases for Dynamic Translation, as well as in ticket / case details such as the Short Description and potentially work notes etc.

Check the videos and table below for all useful links ranging from product Documentation, to Guidelines etc.

Dynamic Translation
Think of Dynamic Translation like a gear box / transmission, and the spokes to a Cloud MT provider as the gears. Following this line of thought, you can think of Localization Framework as the engine to the car, in that Localization Framework can leverage Dynamic Translation but it doesn't have to.

Here's some useful videos about Dynamic Translation, however be mindful of the use-cases mentioned:

As you'll see down below in the Machine Translation section, on top of understanding the intended use-cases for Dynamic Translation it's also important to understand an MT's strengths and Weaknesses.

One of the main use-cases for Dynamic Translation has been for End-users to Agents when they are working on a task-type like a Case. The ability for string fields like the Short Description and Description fields has been around for many releases (as far back as Orlando), like this:

However, in Utah it is now possible to leverage this in Workspaces and it's activity stream and fields:

^ it should work in exactly the same way as in UI16 (Core UI).

The Language (or Languages) we need aren't in the list above, what can we do?

This concept is called "Self-Localization" whereby you perform the act of creating the translations. It's important to note that this would also need to be done for languages we provide packs for but for your own customisations (such as Catalog Items, forms etc).

Another important aspect to be aware of is that (prior to San Diego) we followed the iso 639-1 2 digit standard for language identification, more info can be found here. Where as post San Diego we now support the BCP 47 standard, which is a 5 digit standard factoring in locales (e.g. en-GB for English in the UK vs en-US which would be English in the US vs en-CA which would be English in Canada).

So in the scenario that you would want to provide multiple variants of Spanish or German, then you could add those "locales" to the [sys_language] table, and also set a default language fallback to save on the effort of what to translate. This means you would only need to add specific translations that are relevant to that given locale rather than having to add everything - (see the section about "fallbacks").

For example, you might want to add:

• Mexican Spanish - es-mX (fallback of "es")
• Peruvian Spanish - es-PE (fallback of "es")
• Austrian German - de-AT (fallback of "de")
• Swiss German - de-CHE (fallback of "de")
• etc

Locales can also be used for Knowledge articles as well (but not fallbacks as that functionality is just for UI strings).

NOTE - you may need to add a Language Mapping for your MT in the "Language Mapping" table if they don't understand the locale you are using, this is because most CloudMT providers support Languages.

Pre-Tokyo - Therefore, in the SanDiego release due to various preparations for future features, the process for adding a new Language 
had changed slightly where you'd need to follow the following process:

"After upgrading, you can request ServiceNow personnel to configure your instance to support languages other than the 22 for which 
ServiceNow offers language plugins. The two-character language code supports the BCP 47 standard." no longer required

Post Tokyo - In the Tokyo release you can make new Language records manually again.

In preparation for this, you may have noticed some changes to the [sys_ui_message] table's form.

If you'd like to learn more about this topic and the linguistical considerations for self-localization be sure to check out our course on "Add a Self-Localized Language" on NowLearning.
* The first module now only applies to pre SanDiego and will be updated in the near future.

Language Selectors in Portals

In the Tokyo release, we introduced a portal language selector widget for portal headers that works both for authenticated users and non-authenticated users:

To learn more about it, check this post here.

Force the language via the URL to Service Portals

In the Tokyo release, we introduced a new feature that allows the Language to be defined in the URL path for either a user who does not yet have a Language preference or un-authenticated users.

For example, you could do something like this in the CSM portal:

^ note the "lang=fr" as an appended value to the URL. Or you could do a different language that you have the UI translated in, like this:


Note that if the Language Picker is exposed, the language shown will be updated. However, if the language is parsed in the URL it might contradict a change made via the picker - so be mindful of this.

To learn more about this new capability please check the docs article here.

Multi-lingual notifications

In the Tokyo release, we've introduced a bunch of new email notification features:

Dynamically translated notifications and Statically translated notifications.

The main idea behind the options are:

If you translate the notification template via the Localization Framework (blog post coming soon about this) then it will be available for any 
user (it factors in individuals or group members as it is processed per user) to be consumed by them. 

If the Dynamic Translation tickbox is enabled on the notification in question, then if a translated template doesn't yet exist at the time an 
email needs to be sent to them, it will leverage your Dynamic Translation spoke to translate the email and it's contents on the fly based 
on the user's Language preference (this will only work for authenticated users with a Language Preference).

The following screenshots are taken from a pre-release version of Tokyo and may differ at time of GA.

For example, a translated email notification performed via the Localization Framework would look like this to the end user:

As part of the translation process, the translator, or persona actioning the translation of the email can review the outputs and quality before it is made available for use:

Where as, if the notification was translated on-the-fly via the Dynamic Translation capability, you'll see that there's a banner added to the top of the email. This is to warn the recipient that it has been "Machine Translated". This is to set appropriate expectations to the recipient in regards to the quality of the translation potentially not being perfect:

These features are applied to each notification as necessary - no more per language notifications required.

NowAssist in other Languages

In the WashingtonDC (expanded in the Xanadu) release, we provided an in-built Microsoft (SN Supplied) integrated Dynamic Translation capability for NowAssist use-cases. What does that mean? At a very high level, ServiceNow is providing (free of charge) on-the-fly translations when interacting with NowAssist features (aka our LLM's). 

At time of writing (Xanadu release) the Languages supported are the same 23 languages we have UI packs for (see list further above in this post). This means that this offering does not currently support the full plethora of MS MT languages (~140).

In the November 2024 store release, some languages have been introduced as native in the models. 
You can find more information here on this new feature.

The newly launched native model languages are (on top of the baseline English):

• French
• Spanish
• Japanese
• German
• Italian
• Brazilian Portuguese
• Dutch
• Quebcois (French Canadian)

Any other language (from our 23 UI languages) would currently be supported by our Dynamic Translation offering until these remainder languages are launched at some point in 2025.

A new property has also been introduced "sn_generative_ai.append_lang_in_prompt" that when enabled will allow you to summarised across languages as detailed below.

Here are some examples of use-cases this is for:
Task Summarization (task record in another Language to English, or Vicer versa). E.g. Japanese Case summarised into English:

Q&A search results:
In this example a French question was asked, AIS (AI Search) found a French KB article, which was in-turn sent for summarisation with a French output:

^ Screenshot taken from pre-release version of Xanadu.

Or in this example, the same question was asked via VA:

^ Screenshot taken from pre-release version of Xanadu.

To set this up:

• you will need to ensure AI Search is completely set up via the "AI Search Admin" console for the "Now Assist Q&A" results - details here,
• you will need to enable NowAssist in VA - details here,
• you will need to enable Dynamic Translation for NowAssist (enabling each appropriate language) - details here
  • This uses a new spoke called the "Microsoft Translator OEM Spoke" and does not use or consume your MS subscription when interacting with NowAssist use-cases.
  • In the VA use-case if the conversation follows through to a live Agent then at that point it will start to use your MS MT subscription as it's no longer interacting with NowAssist.

In the "Now Assist Admin" settings area, you should see how the configurations work a bit like this:

The intention is, if the KB article found by AIS hasn't been translated into the intended target Language, the purpose of this feature is to also to be able enable NowAssist to consume it for summary into the end-user's language but you will get better results if it's already a translated article.

For example, if the user was a French speaker and there was no French article result (only an English one) then this will translate the summary into French from the source English article.

There are of course more, hopefully this gives an insight into the concepts and how it works.

Back-end Language selector changes

When we launched the new UI (Next experience), it allowed us a new simpler way to allow users to change some of their preferences and various settings. With regards to user Language and a few other preferences, this has changed into a more streamlined and dedicated experience with the WashingtonDC release for end-users in the back-end UI.

Pre-WashingtonDC:
In the preferences Modal a user would have to go to "Display":

Then their Language (and a few other preferences) would be presented:

WashingtonDC+:
Now there is a dedicated "Language & Region" pane:

Which contains the following preferences (rather than having them in "Display":

Over the next few releases, the intention is to bring in more preferences and future settings in to this dedicated section. 

So watch this space in upcoming releases.

Yokohama+:
The layout of the user preference's modal has changed significantly:

Then "Language & Region" is on the lefthand side:

List sorting by user session language.

In the Yokohama release, we've introduced a new property called "i18n_session_language_sortable" which when set to true will enforce the display sorting of that column (in a list view) to be in-line with that alphabet of that user's session language.

By default this property is set to false. 

In the image above, looking at the "example string field" column, we can see that it is sorted alphabetically. In this example, the additional 
vowel letters (å, Å, Ä, ö, Ö) are at the end of the list (normal Z) instead of being within their respective vowel letters, which would happen 
when the property is set to true.

More information about this feature can be found here.

If you need to add your own character "collation" matches, there is also a new table you can leverage called:
[sys_db_collation_info].

More information about this capability can be found here.

Are there any useful links to consume?

Yes there are (many infact):

As you can see above, we have content available on the Docs, Developer, the CSC and NowLearning sites, with more to come in the future. When looking at the material on Docs, be sure to explore as there are many expanded topics in the various sections.

Due to the complex nature of localizing an instance, the training is broken up into multiple aspects ranging from a beginner course through to some more advanced intermediate courses - with more to come in the future.

• Localization Fundamentals - this course is for learning the basics with a real-world scenario of non English native Customers. For example, a Japanese Customer in Japan who would change all of the system defaults from English to Japanese.
• Localization Journey - this course is much more advanced as it's tailored towards multi-lingual customers looking to support multiple languages. Starting by covering the business objectives through to the technical how does it all work with some solution design, then going through some lessons learned and best practices.
• How to localize a Service Portal - expanding on the Localization Journey this course covers the specifics of a Service Portal, for Customers who only desire adding additional languages for the end-user perspectives rather than all UI's.
• Add a self-localized language - expanding on all of the previous modules and courses, this course covers the linguistical aspects for adding a net new language. Detailing what is a "style guide" and a "glossary" and why they are important.

Please let us know if you have any suggestions for more courses.

You'll also find a link above called "Internationalization Guidelines" on the Developer site. Did you know that different languages can also have a UI impact due to the length of words and sentences? For example:

In the example above, Korean is approximately 0.8x the length (in ratio terms) to the English equivalent, where-as Italian can be as much as 3x the length of the English equivalent. All of this is to say, terms and phrases need to be carefully considered and tested as part of the design rather than just the solution, which will ensure it all fits and acts as harmoniously as its desired to be.

Is Machine Translation the answer?

When it comes to Translation, context is everything. Which means the shorter the sentence (or string) the more complex it is for Machine Translation (MT) to perform. The levels of complexity increase when it comes to business specific terms / phrases because the MT lacks the context of what that means. When dealing with a training MT, you would normally have Language experts help define key "glossaries" and "style guides" of how you want the target language to be conveyed as based from the source. This is because no two languages are equal, there's potentially different styles, different genders, different tones, different needs per language pair. Which is to say, what might sound perfectly normal and grammatically correct in English might sound very odd in another language.

Here's a little example:
If we have the sentence in English - Hi, when will my case be updated?

it would look like this in Japanese - こんにちは、私の場合はいつになったら更新されますか？

yet in English, that would literally mean - "Hi, by when it'll be updated in my case?"

However, before we go into what some common MT's would give us back, let's recap why there might be a problem:

If we reverse translate the Japanese back into English, what did Google give us?

If we reverse translate the Japanese back into English, what did MS Azure give us:

Of course there are many other MT engines and providers out there, this is just a very small and exaggerated example.

All of this is not to say that all or even any Machine Translation in general is not good enough, it's to say that you shouldn't expect it to be perfect straight away and thus you should have processes in place to mitigate this. Generally speaking, someone (a Language SME / Language Lead) should review the outputs before use and compare against an established "Style Guide" and / or "Glossary" for that language.

• You can find out more on this topic in our Self-localization course available here.

In our training course here we go into the differences between functional UAT and UX (User Experience) testing as well as what this kind of process might look like in a project to ensure that the translations are fit for purpose and can therefore empower the intended end-user to be able to do what they need to do.

You can also review our planning workbook here to guide you through everything.

How does everything come together?

Accurate as of Vancouver:

For those who don't know, in the translation world there are some rather advanced tools out there called "TMS's" or "Translation Management Systems". Without going into too much detail, these are for when a Company (and for what-ever their needs are) they have their own in-house managed / maintained MT's which have been built up and trained to their own "TM's" (Trained Memories). This is nearly always because the CloudMT's aren't able to provide the types of quality desired for their use-case and as such the "TMS" acts like a middle man between the to-be translated string and the check against the model's "TM" of a given translation. They are also super helpful for comparing to-be translations against a given Glossary prior to a fresh translation taking place. To be fair, this is a very advanced concept and way up there on the maturity curve. Yet, it is important to note that it's not a replacement for an MT, it's just a more advanced method of translating when quality and scale is just as important as speed.

Language Detection spoke

Via the Dynamic Translation plugin there is actually a "native to the platform" capability for language detection. It's typically used for VA, but it can also be used if your CloudMT of choice does not have a language detection offering.

As of the Tokyo release, the support languages are:

If it's configured, it is also possible to use this capability for custom purposes. Check the API information on the developer portal here.

AI Search

AI Search has many capabilities and functionalities (too much for me to detail here):

And it's journey of improvements has been huge:

But our AI Search Expert @Heather Phipps has an amazing blog post here about everything it can do - well worth a read.

Localization Framework Updates

Here's a little summary (per release) of what's been added to the Localization Framework:

• Tokyo - The First one being that Knowledge Articles are no-longer separated via "Translation Management". As of Tokyo you can translate articles via the Localization Framework, meaning you can leverage the same advanced TMS integration functionalities and XLIFF export capabilities to translate your content in a consistent manner as other aspects across the platform. Check the "useful link" table above to read more about this on Docs.
• Tokyo - you will notice that it is now possible to translate Email Notification templates (or emails on-the-fly should you need to) via the Localization Framework. I'll go through this in a more detailed blog post in the future, suffice to say, it is now possible to define a notification once then translate the template and the system will send the correct translation to the end-user (even in multi-lingual groups) based on their language preference. Meaning less admin overhead (no more multi-lingual templates) and less config / dev work to maintain. Check the "useful link" table above to read more about this on Docs.
• Tokyo - you will also see that we've added a new Artifact specifically for Surveys ootb.
• Utah - we introduced the ability to have LFtasks create an update-set (per task) to contain it's translations, to make it easier to migrate translations between instances when the Localization Framework was set-up on a sub-prod (e.g. Dev) instance.
• Utah - within Catalog Builder it is possible to leverage the Localization Framework.
• Vancouver - within Decision Builder the Localization Framework is now also built in.
• Vancouver - within Virtual Agent Designer the Localization Framework is now also built in.
• Vancouver - RPA Hub supports international languages.
• WashingtonDC - Hub and Spoke model

With regards to the platform and therefore to learn more about how to utilise the right "building block" for the right purpose, check out my blog post on the In-platform translation capabilities here.

Fun Facts

• In NewYork Patch 2 we re-introduced Korean and added Norwegian and Swedish Language Packs
• Our .com website is also available in other languages, check some of them out here
  In no particular order:
  • 🇬🇧 UK - www.servicenow.co.uk
  • 🇫🇷 France - www.servicenow.fr
  • 🇩🇪 Germany - www.servicenow.de
  • 🇪🇸 Spain - www.servicenow.es
  • 🇳🇱 The Netherlands (Holland) - www.servicenow.nl
  • 🇮🇹 Italy - www.servicenow.co.it
  • 🇧🇷 Brazil - www.servicenow.com.br
  • 🇯🇵 Japan - www.servicenow.co.jp
  • 🇰🇷 Korea - www.servicenow.kr
• In the WashingtonDC release we introduced the Arabic Language Pack.

Did you know Docs is translated?

DOCS is also now available in the following languages:

• English - https://docs.servicenow.com
• German - https://docs.servicenow.com/de-DE/
• French - https://docs.servicenow.com/fr-FR/
• Japanese - https://docs.servicenow.com/ja-JP/
• Korean - https://docs.servicenow.com/ko-KR/
• Brazilian Portuguese - https://docs.servicenow.com/pt-BR/

* Translations are constantly being added so if a page isn't translated at the time of viewing, be sure to check back often.

Alternatively you can check out the globe icon in the top right of the page you are on (such as a product page like ITSM or CSM) to change language:

If you need a more comprehensive coverage of content, check out the "PDF Archive Library" in the following languages;

Snapshot posts from my blog

• Is your catalog not searching in other languages? - check this
• Non-English inbound emails not being identified as a Reply / Forward? - check this
• Need to find where a translation comes from? - check this
• Emails in other languages (easy to complex) - updated
• (LF Artifact) - Extending the Localization Framework to Portal Announcements
• (LF Artifact) - Translating Surveys and Assessments
• Global Go-Live Considerations
• Hardcoded strings are bad
• Solution Design is just as important
• Everything you ever wanted to know about the 5 translation tables
• (LF Artifact) - Need to translate a portal - check this
• Need to add a Language Selector to your portal? - check this
• (LF Artifact) - Need to translate a configurable workspace? - check this
• (LF Artifact) - Need to translate a Guided Tour? - check this
• Want to find a hardcoded string? - check this (Instance Scan Definitions)
• (LF Artifact) - Need to translate a PA Dashboard? - check this
• (LF Artifact) - Need to translate you Office / Building / Indoor maps? - check this

• Ever wondered what it takes to translate other types of content (such as video)? - check this

• (LF Artifact) - Need to translate a PAR Dashboard? - check this

• Need Dynamic Translation on Variables in forms? - check this

• Need to auto publish translated articles? - check this

Crash Course
If you'd like to see a 1hr crash course on all of this, check out the session I co-hosted with the HRSDAcademy:

If you'd like to learn about how these principles can be applied to the new /esc portal please check out the session I co-hosted with the Employee Center Academy:

There's also a session on the Platform Academy series:

The Platform Academy session has been fully dubbed and subtitled into the following languages for your needs. Please check it out if it's more useful for you, rather than English. In no particular order:

• 🇫🇷 French
• 🇨🇦 French Canadian (Quebecois)
• 🇩🇪 German
• 🇮🇹 Italian
• 🇯🇵 Japanese
• 🇧🇷 Brazilian Portuguese
• 🇪🇸 Spanish

We have now also published a special full-day session we held in Canada back in June 2024. We've trimmed it down to just over 5hrs, so to say it's pretty extensive is an understatement (and it's still not everything - this was before NowAssist was released, but everything else still very much applies):

If you found this useful please like, share and subscribe if you want to learn more, as it always helps.