Hello and welcome, everybody. Today is February 16th, so this is our 30th
Platform Academy session. I am very proud to welcome
all of you to this session. I am glad
that so many are joining us. And with that,
I will get into today's session. We are joined by Alex Coope today and we will be talking
about localization, internationalization and all of
the long isation words. I am very, very impressed
that you are daunting to pronounce
all of the words repeatedly. Thank you so much
for joining me today. We will get into introductions
in just a second. I will just get this
wonderful safe harbor out of the way. You probably
all know this already. If we are going to address
any forward looking statements or product features, don't make
any purchasing decisions based on anything you hear today. As I said, I am very glad
you joined us. This is a live
on ServiceNow webinar. We have a whole series
of academies by now. I would love for you
to check them out. I have more links later
in this presentation. We have our sister teams
talk about next experience, about performance analytics
or platform analytics, virtual agent, mobile,
all kinds of platform topics. I want to encourage you
to join those if you're interested
in those topics. And then as a final thing
from my side, some housekeeping items. We do save time
for Q&A at the end, but please feel free
to use the Q&A button at any point, the Q&A panel. Send us your questions. We want this to be
a little more interactive. We love your feedback. We want to hear from you
how you're using these products. What are your difficulties? What are your challenges? How would you like us
to address these and how we can help you
and what you think about this presentation
and this content today. This presentation
will be recorded as always, and we will share this
sometime later next week. I will edit the session,
upload to YouTube and post
on the ServiceNow community. We'll also share the deck as a PDF so that you have access
to the resources. After the event
you will be prompted to fill out a short survey. I have another short survey link
in this presentation. I would love for your feedback. Please give us your feedback. As ways of introduction,
my name is Lisa Holenstein. I'm now product manager
for the Now platform, focusing mostly
on workflow automation topics. I've been with ServiceNow
just over four years now. I've been working
with the ServiceNow platform for almost seven. A little much from me. I am very happy
to introduce Alex to you. Hello, everybody. My name is Alex Coope
and I'm the Director of Globalization Deployment
here at ServiceNow. I've been in the company
for just over three years, and my first foray into ServiceNow was way back
in beginnings of 2012. I was a pre-Aspen person. My first upgrade project
was Winter 2011 to a domain separated
Aspen instance, believe it or not. That sounds like an adventure. It was a baptism of fire,
I'll say that. But over that time,
I kind of developed this notion I wanted
to do multinational projects. I wanted to get into the big stuff
because why not? It's fun, it's complicated. It's good to learn
the good things. Now in ServiceNow I head up our customer
and partner enablement aspect to do
with multilingual implementations or non-English implementations,
and I sit in what we call our internationalization team
and therefore, we own the UI capability
to represent non-English. If it needs to show French,
if it needs to show German, if it needs to show Japanese,
that sits with us across all of the UIs. And on top of that,
we also own the 22 language packs. The 22 UI
translation packs basically. That gets me into the next slide
because we need to get through some terms, the isations. We're going to go through
what they are and I'm going to give you
a nice little nugget of how to remember them. If we go to the next one. Everything we're going
to go through here is actually
in our training materials. We've got a whole course
on Now Learning. We've got a bunch of blogs
and whatnot. And I can see some famous names in the attendees' list. I'm not going to name any names,
but there is one that piqued my interest. If you know who you are. If we go to the next bit,
the first term that we need to learn
is internationalization. The idea here is to say,
I've built a map, I've built a piece of software,
I’ve built anything. It can work with other languages,
meaning that the text that we want it to show
is understood in the system to be externalized
and therefore translatable. But it has no specific nuances
or needs for a country or for a language,
meaning this app will work. That's not a ServiceNow concept. That is a software
industry concept. It would apply to an iOS app. It would apply to a computer game, all those different things. The trick here to remember this,
is the i18n, that's an industry standard. The 18 is actually
the number of letters that come after the first letter,
which is i up to the O, which is before the end,
and you’ll count it, that's 18 letters. If you Google i18n,
you'll get this. We’ll go to the next one. The next term we need to learn
is localization. That's the idea of having
the translations done, as well as
adding visual specificity, that’s a big word,
for what that translation is. That could be anything
from a date format, a time format, a currency, all those little aspects
that make it specific to that given region or locale,
as we say in the industry. The short-term code for this
is l10n, and again the 10
is the number of letters between the l and the n. If we go to the next one. Then we have translation. Pretty obvious what this is. It's the act
of translating a source text from a source language
into a target language. That could be English to French,
or it could be English to Japanese. It could be English to German
or English to Spanish. But there are two aspects here. It could be human in translation,
as in someone is actually writing it themselves,
or it could be machine translation where you're using technology. There's hybrids in there,
there's different types, but we'll get to that later. If we get to the last one. That's the idea of globalization,
which is a bit of an umbrella term. I don't mean
in the supply chain world, I mean in this world
is literally bringing all of these
different aspects together. It's like the strategic part,
if you will, and that short term is g11n. 11 being the number of letters
between the g and the n. We’re going to
the next one pattern. A stellar pattern. Now, when we think
about translation, we have to bear in mind
that it's not as simple as just adding the translations
on top. We've got a bit of theory
that we need to get through first. The theory is to say
that languages are not equal. We're going to go through
different examples and different scenarios
but think of it like this. Let's take British English
because I'm just outside London. That's why it's a bit dark for me. If you're in another part
of the world and it's bright and sunny,
that's why it's dark for me. If we take American English,
we're going to go through certain things. If we look at the next part,
we could have scenarios where we have the same meaning
from different words. Of course, everybody knows the sidewalk versus pavement
and the elevator and lift. Sure. But if we go to the next part,
we can also have scenarios where we have the same word,
have different meanings. If any of you saw
my previous webinars on this topic before,
I often joke about the idea of a chip. In the UK,
that's a thicker French fry. But in America,
that might mean something else. That could be a crisp
that we would call here, not a chip. Like a Dorito
or something like that. You've got a couple,
which could mean more than a few. Or it could be
just specifically two over here. It's not a hard and fast rule, but it's the concept of saying
you have different meanings from the same word versus
you might have a different meaning from different words
and vice versa. It can get quite complicated. If we go to the next one. I'm not going to get into this because it doesn't apply
to us here. The notion is also pronunciation. The American English
would be router, whereas the British English
would be router. Tomato, tomato. On and so forth. The idea here as well
is to consider we want to try and connect with the end users
wherever they are. Whether they're in
a specific country, or in a specific area. If we go to the next bit. We want to try
and make sure that the content and the experience
resonates with that audience, with that user base. It's not as simple as saying, I want these translations on top. There's different factors
we're going to think about. The next slide,
it's going to give us another overview
of some other things. We don't need to think too hard
about this right now, but we just need to be aware
of them. You could even have spellings,
so paycheck and paycheque, not to be confused
with Czech persons. We could have localize
and localize, the ize versus ise. We could have verbs
in different areas of the sentence. We could have completely different
sentence structures. If we start thinking this
with a technical lens for a moment, it could actually implicate
how we design the interface. Think of a UI action. If we use a certain word,
it can actually make that button smaller or larger. In Italian, for example,
the average word is about three times longer
than an English word, whereas, in Korean,
it could be half the length of an English word. Again, these are all
different things we have to think about. If we go further than that
and we wanted to translate content, we have to be mindful of images,
specifically photos. If I had a picture of,
say, a nice, cool-looking guy in America
with sleeve tattoos down his arm, that would be a bit of a no-no
in certain Asian countries because that could imply
he's maybe part of a criminal enterprise
or in my case, as you can see here,
the name is in red, a person's name specifically. That could mean in Korea
that I have died. I hope I don't, because I want to
be in this webinar. I didn't know that one. Yeah. It's not to say
that this is all there is. There's many more,
but it's to say we have to be very mindful of whatever we do
for one region, one country,
one audience basically, it might not necessarily work
in that same way for another. Now we’re going
to get to the fun bit. If we go to the next one. The thing here
that we want to think about is whenever we're presenting text
in the interface, let's take something
like a scripted message. This is an example
of a concatenated string. The first row that you see,
you have number items, items in your shopping cart. Technically, that will work. There's nothing wrong with that from a technical perspective
at all. The problem
when it comes to translate, it’s going to be difficult
because if we looked from our previous slide, sentence structures
are very different. In some languages,
that number wouldn't be there in a sentence. When the translation tool
or person sees that, they're going to see you have,
then they're going to see another string that says
items in your shopping cart, which is going to be difficult
to ensure that same meaning. What we're suggesting here,
this is technical best practice, regardless of us being ServiceNow, it could be
any software development that you want to do. Try and keep the sentence
as simple as possible and the sliding scale downwards
as you can see in that image is getting simpler
and simpler and simpler. In the second example,
you’ll see a brace zero. That's a parameter
in the getMessage API and you can see
the object being sent is numltems. We can say,
okay, in the translation, I can put that parameter
wherever I need to and put it wherever I want
for that language. It doesn't need to be the same. The key is
you have parameter items in your shopping cart,
but the actual message value in that record
can be wherever you want. If you want to get really simple,
you can just simplify the sentence with that bottom one,
and then you can have that number as an object completely separate
to the sentence structure entirely. If you go to the next one
for a second. W e produce 22 language packs
out of the box, and a language pack
is basically the out-of-the-box UI translations. If you install French,
if you install German, if you install Hungarian,
what you're actually doing is you’re including translations
of that out-of-the-box UI into five tables. We’ll go into the five tables
in a minute. But the idea here is to say
that we include every plugin. If you install that language pack,
you're going to install the translations
for all the plugins and about 450 store apps
now as well. This is where the safe harbor bit
comes into it. We're actually changing
a little bit of how we deliver the translations. If some of you noticed
or remember how long it used to take before Tokyo,
it was quite a long time to install a translation pack. That's because
they were really big. There was millions of words
that we were unpacking. Then for Tokyo,
we've managed to get it down to about 20 to 30 minutes
per language. In the future,
it's going to be even quicker but I'm not going
to go too much into that now. The idea here is
all we're really doing, if you know how to translate
already in the platform, we're populating it
in the same way. We follow the same rules,
the same principles. We're not cheating.
We're not doing anything else. When it comes
to the UI translations, it is just data that sits
in the five tables. We do it exactly the same way
as you, just more, think of it that way. Hey, Alex, we have one question concerning the language packs. Do the translation packs
cost additional? Nope. They are completely free. You can store all 22
right now free of charge. Awesome. Thank you. That's a good question. If we go to the next one for me. We have to think,
why do we want to do this? It's not a case
of just adding translations. There's always a reason,
whether it's a business reason, whether it’s end-user reason,
we have to think why. If we go to the next one. This is an example
from one of my demo instances, which we'll do a demo later
in a minute and you'll see how I did this. What we have here
is the ESC portal completely translated
into Japanese. You've got catalog items,
you've got knowledge articles, you've got VA,
you've got the topics, the taxonomy. There are clever ways
and quicker ways that this can be achieved. I'm going to hopefully show you
how I did that. If some of you read my blog,
you might already know this. But the idea here is to say
that as long as we know what we want to achieve,
it is absolutely doable. If we go to the next one. Before we do. One more question in the Q&A.
The default is US English in the platform,
and there's no option for UK English. Is there a reason? That is correct. We don't provide British English,
UK is actually Ukrainian. But yeah,
we don't provide British English out of the box. But if you wanted to,
you absolutely could. If you're on Tokyo or above,
you could create a new language record,
call it EN-GB and then you could create a locale and add English-specific
translations that way. That's absolutely doable. It's a good question. That also applies to French,
French-Canadian, different variants of Spanish,
different variants of German. At least when I've spoken about
variants of German in the past. Austrian-German, Swiss-German, all that. If we go to the next one. We need to think about what it is
that we want to translate. Because very often,
some people can get into the idea of saying,
I just need to translate some knowledge articles. Sure, I totally get that,
totally hear that. But at the same time,
how are the end-users going to find it
if the interface isn't translated? If we assume that they don't
or can't read English as well as we can,
they may struggle to interact with the interface to then find
where that translation is for that knowledge article. It's always best to think,
what are the user journeys we need to cover
and how are we going to do that? I'm highlighting we need to translate the UI,
whether it's the topics at the top, the menus, the widgets, the virtual agent,
and it doesn't have to all be done at once. I want to be super clear
about that. It could be done in stages,
but the objective would always be to try and reduce
a mixed language experience because that's not going to help
the end-user. Try and do as much as you can
and then keep it as an iterative process
because translations are never one and done. There's always more. You're always creating
new catalog items, you're always creating new content,
and all of that will need to be translated at some point
if that's what your strategy is. Whether it's one extra language,
whether it's 20 extra languages, that comes down to your scope,
and that's absolutely fine. We go to the next one. This isn't to say this is explicitly
how you should do it. This is just an example
of a process. It's basically to say
that you want to get into a cadence where whatever you're building,
you have a holistic team, a global platform ownership team
if you will. They know that they have
their coding standards that they need to follow, you can create
a repeatable process. If everything anywhere
in the platform is being built in the same way
and your coding standards are effectively being policed
in a holistic way. You can therefore triage
any requirements and say, okay have we built
this kind of functionality over here in the platform
and do we now need to use it over here in the platform? Then in theory that should mean,
there's less technical debt because we can reuse
what there already is, which might mean
that we could potentially reuse a business rule or a flow or another type of integration
of some kind. Then you can prioritize
what they are, because if more than one BU
is going to use that functionality, then that makes a lot of sense. You don't need to rebuild,
you can just repurpose and then obviously
your maintenance and your solution in building
will be a lot, lot simpler. If you're dealing at scale
when you're trying to build out into say 20 languages for IT, HR,
and other different parts of the business,
this will make a massive difference in the long run. Then obviously, because
all of those different areas of the business may need to have
their content translated. For example,
look at the ESC portal. It brings IT and HR to the portal
for those end-users. Then your translation processes
and your testing processes can be the same. Because it doesn't matter
if the content is an IT knowledge article
for the end-user like I need to order a laptop. It doesn't matter
if it's a HR policy as in how much time do I have off? It will still
need to be translated, so you can create
that repeatable process. Obviously,
when it comes to the testing, you need to test your UI
with native speakers to make sure that you have the right word. For example, in some languages, there aren't equivalent words
as there are in English. Some of you
may have already heard this in one of my other webinars. If not, it's fine. In Polish,
there's no HR word for case in that context. The closest you'll get
will be suitcase. If you can imagine it,
on day 1 on Go Live if the end-users
haven't validated it in context, then they'll say,
I want to raise a suitcase, that won't be
a very good experience for them. We had a similar occurrence
a couple of years back when I was a platform owner
on an English and German instance. The button on,
I think change management set screen for the screening stage. But in German,
it thought it was the screen, like the display
that is in front of you, so Bildschirm. It tried to translate the stage
with the physical device, technical device. That was interesting. Yeah. Before we go on,
I have two more questions in the panel. Let’s see how they work. The first one asks,
does ServiceNow provide all the translations or do we have
to translate things manually? For example HR services,
does it also translate it? As far as I know,
all our products are included in those languages, right? If it's an out-of-the-box thing,
it will be translated. If you've built it,
you would have to add the translations
and we'll go through how in a minute. Will we be touching
upon NLU later? I will postpone the next question.
We can cover it very high level. In fact,
I can probably say a bit right now. If you're building a structured
VA conversation, so one where you present options
to the end-user, standard topic. You can translate them
pretty easily. They just get message calls. If the end-user is going to follow the same conversation
exactly as it is in English, in French, in German, in Spanish, then you can just translate
that same one, and build it once. If you actually need to allow
free text responses, the utterances,
then you basically need to create that same conversation
in NLU per language. If you go into the NLU designer, there's actually
the functionality there where you can say,
I need to have this in another language. You train it on the utterances
in that language, because remember,
languages are not equal. There could be 10 utterances
in English, there could be 20 utterances
in German, there could be five utterances
in French. I'm just making it up
as an example. But the idea is
you would train it per language. We're going to show you
some pretty cool stuff with what we call
the localization framework, but you can do it
with that functionality. The question that we got is,
or I'm thinking the question is, does it work
with Brazilian Portuguese or does it still use
European Portuguese? We actually do both. If you go back
to Slide 11 real quick. We do Portuguese,
proper Portuguese and we do Brazilian Portuguese
as well. These are the language packs.
I might as well go through them. Obviously English
is the base system language. We do Czech, Dutch, Finnish,
both versions of French, German, Hebrew, Hungarian, Italian,
Japanese, Korean, Norwegian, Polish, Portuguese
and Brazilian Portuguese, Russian, both variants of Chinese,
Spanish, Swedish, Thai, and Turkish. It's not to say you can't add more,
you absolutely can. I spoke to a customer
just last week and they've done 100 languages. But the idea here is to say
this is the translations we provide for the out-of-the-box. 100 is so wild to maintain. It's quite an achievement. If we go to the next one. If you want to get to Nirvana,
it's always impossible to have Nirvana from day one. But if you want to get to Nirvana
and you want to have everything the best it could possibly be,
it doesn't really matter if you use a machine translation,
it doesn't really matter if you use a human translation team
or even a third party to do the translations. That bit's actually the easy bit. The hard bit is actually defining
the governance layer. The governance layer
of how things should be built for consistency on the platform,
ensuring that coding standards are followed and ensuring
that all the different areas of the platform
are being utilized correctly, according to whatever
the platform ownership determines. Some companies and some groups
might call that a steer co, some may just call that
a platform ownership or a shared BU, or a global team. It doesn't really matter,
the objective is still the same. You'd have
your technical workstream, you'd have
your technical developers of any description,
whether they’re in-house or third-party,
that bit doesn't matter. They're
your ServiceNow-certified people who can build ITSML,
or your portal architects, or whomever. That's okay. What we're saying here
is you need to do the same thing
for the language side of it. Because you need to define
the style guides and the glossaries. We don't want that Polish word
for case to come out as suitcase, we want it to be ticket,
for example. They would define that
in what's called a glossary. You might have other concepts. Like in Latin languages,
you might want to have a particular manner in which
that verbiage comes across. Does it come across softly? Does it come across pushy, pushy? It depends on the scenario. Do you want to have
feminine-ending words or masculine-ending words? Again, it depends
on the specific scenario, and that's all of their role
and their responsibility is to say, I'm going to police this language. Say, for example,
if you're going to do French, you should really have
a French language specialist sometimes called a lead,
and they would own that. You'd have a German
and then you would have a Spanish, and then
you'd have so on and so forth. Now you can obviously
use third-party partners for that, that's absolutely fine. But you want to have
a nice guide in there. Then that way if you do use
a machine translation tool, you can govern it against that. If you're getting translations
coming back, you can validate,
is this what we intended? Is this
how we want the quality to be? That becomes different layers
of maturity of process. It's a bit like
how you do knowledge management in that sense. You'd review the articles
after a period of time. Translations are no different. You would review them
in context before you go live. We've got
a whole methodology of that. We've got to a CSC page
with tons of material and I can absolutely
share that link if any of you are interested. But we didn't have enough time
to go through that today, so I just wanted to touch on it. If we go to the next one, please. We need to start thinking about
how we do the technical stuff now. Now we've got the theory
and we understand the implications and we understand, give or take, what we need to plan for. We need to start thinking
how it's going to work. If we get to the next one. The actual platform itself,
I'm going to talk about it in two different ways. We have the UI translations
and that sits in five tables, which we're going to go through
in a minute and then we have content. Content to me is knowledge articles
because you're generating new content. If we go to the next bit,
the first table that we need to think about
is the sys_ui message table. This is typically
for scripted messages. Think of alerts,
think of ad info messages, think of confirms,
think of portal widget titles. Every time that you need
to do an add-in for a message, add error message, etc. All those different things
you're putting text in script. This is where you should be
putting the actual entry. There's a whole method
that we call get message and there's a concept
called hardcoded strings. I'm not going to go
too much into it right now, but again,
it goes back to my point earlier of coding standards. We've got a whole blog post on it. We've got
a whole bunch of training on it. It would take me too long,
unfortunately, to go through hardcoded strings. But the idea here is if your code
is externalized correctly, then the data for the translations
would sit in this table. You'd have one entry for English,
you'd have one entry for French, you'd have one entry for Spanish,
and so on and so forth. If we go to the next one. The next table we think about
is a dropdown choice. It could be a variable
if it's a question choice type, or it could be a field
such as the state field. Those entries sit in sys_choice. Just where you put the English ones
is exactly where you put the translated ones. They just have a language field
on it. You duplicate them,
so you've got three for English, you do three for French
and you do three for German, etc. It's exactly the same. If we go to the next one. Then we have sys_documentation,
which is for field labels. Exactly where you define
the English field label is where you put
the translated field labels, and it has a nice little language
field on that table as well. If you've got one label
for that field in English, you duplicate it
and you put another label and you put the value
what that is in the other language, and so on and so forth. That's the one that shows
as a related list on the dictionary items, right? That's correct. If we go to the next one? We have sys_translated,
and this is governed by a field type
called a translated field. If you look at the type of field
and it says translated field, it will reside in here. It has a permutation
where it needs to know what table it's for, what element, which is the field that it's for,
and then you can put the English value
and then you can put the translated value. You would duplicate
those records per language. The nugget here
is this does not hold the English entry,
so bear that in mind. Then the one
that people always struggle with is sys_translated_text. This is governed
by a translated text field or a translated HTML field. It works with both of them. It works very similar
to how sys_translated works, but it has one extra
piece of information, which is the document column
which maps to the sys_id of the originating English. I've got a whole blog post
on how these tables work. They're very, very long,
but it's very detailed, and again I will share that
with you guys later. If you just show the last block,
the takeaway here is to say that from the UI’s perspective,
so we're not talking about NLU, we're not talking
about knowledge content or anything like that,
just the UI, the translations just sit
in these five tables. If we know how they work,
we can make it do what we want it to do. That's the takeaway. We have another good question
about translations, and I think I know the answer
for this one. It’s does localization
support notifications yet? Last I checked, years ago,
it didn't. That is a good question. But perhaps it was just
not with emails containing sections generated by mail scripts. Are these supported? As of Tokyo? As of Tokyo,
we can translate notifications, which makes my heart very happy
because that is also something that I did
when I was a platform owner. We have those mail scripts
and we actually called the script crew that would look up
the recipient language and then translate
the appropriate text. Now you can create
translated versions of the email and it will be sent
to the person’s language in their profile
or the default if they don't have. Correct. You can even go one step further. If you haven't translated that
notification into their language, if you have dynamic translation
with a cloud MT provider, then you can actually do it
on the fly. Yeah. Which is really cool. It is really cool. But it goes back
to the quality question. You'll just have to bear in mind. We put a prefix along the top of the dynamically generated emails
and it will say this email has been translated by whomever. It's always good to set
that expectation because if there's
a mistranslation, then that they're going to be more forgiving as an end-user,
just like you would if you went on Google Chrome and went
to an international website and you saw something
that wasn't quite right, you would be okay with that. I also think
that's an amazing feature and feedback in chat is nice. I agree. I agree. It's been on my radar
for a long time. At least 2015, 2016 in my case. That's good. If we get to the next one. I'm going to start talking about
some architectural principles now. I can certainly see at least
one good architect in the chat. The idea here
that we have to think about is if we're going to be building out
a solution, whatever it is,
we always need to bear in mind what building blocks,
now I always refer in the platform to everything as a building block. A field is a field. A form is a form.
A table is a table. A component is a component. A widget port,
a widget port is a widget portal, and so on and so forth. As long as we know how they work
and as long as we know how they're supposed to be used,
it doesn't really matter where in the platform
they are used. We just need to be mindful
of how we're connecting them together for the use case
that we want. Here is to say,
whatever the solution is, we just need to remember
and bear in mind how those different
building blocks work. This isn't an exhaustive list
by any stretch of the imagination. I couldn't fit all of them
on the slide, but the idea here is to say,
if I'm going to be doing a catalog item,
I know how that works. I should know
and understand what I need to do to translate it,
and so on and so forth. Let's take a scenario
where we've built a process. If we go to the next one,
in this particular process, we're going to make it
really simple just because it's an analogy. Bob wants something. It doesn't really matter
what he wants, maybe he wants access to something, maybe he just wants help.
Doesn't really matter. But that's the beginning
of a process. Every process,
no matter what it is, has a beginning, a middle,
and an end. It has to.
Otherwise, it doesn't work. The beginning
could be the catalog item or the record producer
in the portal, or it could be the beginnings
of a topic in VA chat. Sure, that's fine. Or it could even be he's calling up
over the phone. It doesn't really matter. That's the beginning. The middle could be a single step
that's automated, doesn't matter. Or it could be multiple steps
of approvals. It doesn't really matter. In this scenario,
we're saying something happens in the middle
and there's an output, and that output leads to either
a positive outcome or a negative outcome. It could have a hundred steps,
it doesn't really matter. The process is still
a given structured process. If we go to the next one. We don't need to think about
if we wanted to have that available for another user. Let's take Yuka in Japan,
for example. We don't really necessarily need
to build out another version of that process. If the steps are the same,
the flow will be the same. You might need to feed it
different parameters, maybe a different manager
for an approval, for example,
and we could add logic there. That doesn't mean
we need to create another whole flow,
whether it’s a workflow or a flow, doesn't really matter,
but we don't necessarily need to make another one. But what we do know is
that the touch points for Bob and Yuka need to be translated
into their respective languages, and potentially some emails
might need to be translated into their respective languages
and we might need to think about particular other steps
for maybe the fulfillers. Already,
there's at least three or four different things
that we might need to translate. Thinking like that
makes things quite a bit easier. Along the way,
we might also have to think about a knowledge base. If we go to the next one,
sometimes people think that we need to create tons and tons
of knowledge bases, or we might need to do things
in a way that is just unmanageable. That's not strictly true. It always comes down
to what your needs are. I always try and rationalize it
into three key questions, and then that will determine
how many knowledge bases are best for you. It's not for anyone else
but you guys to think what is best for your needs. I always try and rationalize it
as who's the audience and I'll explain why in a minute. Is that content going to be
globally relevant and does there need to be
any locale-specific versions of that content? Let's play out a scenario. If I've got a knowledge base
that has content that may need to be translated,
but it has content that is for everybody,
it’s basically the same content. Whatever that is,
it could be a hundred articles, it could be a thousand articles,
doesn't matter. It might need to be in one language
or 100 languages. If the content is exactly the same
and everyone should have access to it,
I’d build one knowledge base for that scenario. If I have a scenario where I've got
a bunch of content that everybody needs to see
and I've got a bunch of content that may be a particular group
of individuals, whether that's in a region
or whether that's in a country, it could even be
an industry-specific thing, like a union
or something like that. That's when I would start
challenging the idea of needing another knowledge base
and putting their specific content in that other knowledge base. The reason you could do that,
and again, I'm not saying you should,
I'm just saying you could do that, is because then the user criteria
at the knowledge-base level are going to be automatically
sorting out the permissions for any of the articles within it. That's going to have benefits
for things like search speed, that's going to have benefits
for your publication processes. Because if you only stick
with the one knowledge base idea, and say everything is
in this one knowledge base, it potentially at scale
could put a lot of pressure on your publication process
because you have to put the right criteria
on all of those articles. You just have to weigh out,
what's the best pros, what's the best cons? If we go to the next slide,
we'll have a quick look at what one knowledge base
will look like. Now KBs themselves
are actually quite simple. Translated articles,
they're just related parent-child relationships. You create your English one,
that would be the parent in this example, and maybe
I've created a Spanish one. There’s a parent field
in the top right corner of the form,
and that creates a relationship to the English article. As long as the language field
is populated correctly, the system will know
it's a translated article. You'll see that in the related list
underneath each one, it was a translated article. Also we could do an Italian one, which we related up to
the English one. You could use content blocks
if you want to, there's nothing wrong with that. Again, it comes
down to pros and cons. You need to weigh up
what's best for your needs, but this is how one knowledge base
would look like. If we go to the next one. If we look in this scenario,
the idea was to say that everybody in the company,
if they needed access to content that is relevant to them,
they would all have access to the global KB. If you click on the next button,
you should see a little animation. Then in this scenario,
it’s saying a person in the US can have access
to the entire global KB and they would also have access
to a fictitious regional one because maybe there's content
that's only needed in this regional one. Now we're not saying
copy any content here. You wouldn't do that,
that would be crazy. But the idea here would be
if it's regionally specific for North America,
they would have access to that and it could have
a lot less content in there compared to the global one. Then conversely,
if we had a Canadian user, so if you click again,
then the Canadian user in this scenario
would have access to all three. Because the North American person,
in the US is not part of Canada. They wouldn't need access to it. Now again, pros and cons. It's not to say you should
or you have to do this is, it’s just to say you could
if you wanted to. We don't try
and push you into any specific way, it's more to say the platform
is scalable enough that you can do whatever you need to do with it. I think it's probably
the best way to put it. Because at the end of the day,
the end-user, if we go to the next one,
they don't want to have to navigate your taxonomy. They just want to search
and they want that search to present the results. If we click again,
we should see one set of results from one knowledge base
and if we click we should see
another set of results from another knowledge base. Because they don't need to know
the taxonomy. They don't need to know
which subsection it's in or anything like that. The process owners do
because that's how they manage their process. But it's all about the search
for the user. The more simple
that we make it for them and the quicker
and more performant we make it for them,
the better it will be for them. The distribution into different KBs
will then also mostly be irrelevant really
for the KB writers, the authors, the managers,
the ones that approve. There may be different
approval workflows based on different KBs. If some need more steps
to approve the articles, then you would have it
in its own KB. Yeah, exactly that. We've now gone through
our language theory. We've now gone through
some of the considerations we need to think about for the UI. Let's think about how. What's the really cool stuff
that we can do? What capabilities do we have
in the platform? Now, this is one of my one pages that I've put together. It's a busy slide,
it's going to take us a minute or two to talk through it,
but we're going to do some demos as well. Just a slight bit.
Slide a bit. In the Quebec release,
we introduced a functionality called the Localization Framework
and I wouldn't be surprised if not many people here
know what it is, because we didn't scream about it,
which is fair. But the idea is to say,
I've got something, I want to translate it. If you think of it in that context,
it should be a repeatable process because it doesn't matter
what that thing is, you're going to have people
who are going to see the text, whether that's a project manager
and they say, I need to route it to this person
or this team or whatever. If you can use
a machine translation agency, or a tool or anything like that,
you're going to want to route it in a particular manner,
and that's fine. Since Quebec, we've added
more functionalities to it. It's this functionality that
lets you do those notifications in other languages. It’s all part of this. This slide is basically saying
on the interaction circle, the different areas
where you can use either dynamic translation
or the localization framework, and how. What we've got to also clarify is exactly
what is dynamic translation. Dynamic translation,
all it really is, it says from the ServiceNow side,
I need to send some source text to a third party
and that third party will do the translation. Imagine Google, imagine Microsoft,
imagine Watson. That's all it is. That's all it's going to do. Send, go for the spoke, come back. We use that
for things like Agent Chat, real-time Agent Chat. We might use that
for knowledge articles as a first-pass translation,
and we could also use it here for the localization framework. The same spoke that you would use
for Agent Chat you could use here as well
and I'll show you how that looks in a minute. This is where
you can do email notifications, either the templates
or the dynamic translations on the fly if you need to. You can do Virtual Agent
like I said earlier, you can even do service catalogs. You could do a mobile app
with a custom artifact. You can do a service portal,
which I'm going to show in a bit. You can do workspaces,
which I'm also hopefully going to show you in a bit as well,
and you can do KBs. You can also do surveys. In Tokyo, we added some more. But think of it like this. It's an engine
based on a script include, the artifacts,
we call these on the site. They're all called artifacts. If we haven't provided one
out of box for you guys, you can write your own. If you know how to write
a GlideRecord query. If you know how to do
any structured script in the platform,
you can write your own. I think it's time for a demo. Hopefully, you can see my screen. It looks good. You can turn this on
on any of your instances right now. If you want to use it
without an MT, such as Google, or Microsoft, or whatever,
it's free to use manually. I'll explain what that means
in a second. But if you do want to use it
with a Cloud MT provider, you'll need a subscription
with them. MT being machine translation,
correct? And thanks for clarifying that. You'd need
a subscription with them, which unfortunately
is outside of our control and you would need
integration help. You may potentially
need to have a pro SKU if you don't have that already. I just have to put that out there. This is a list on our demo instance
of what we call the artifacts. The artifact, as I said, is the proverbial thing
that you want to translate. You can see my team’s created
some proto ones. If you look up my blog
on our community, you'll see that I've posted
a bunch of them, but I'm going to show you one now. Let's take a catalog item
just for speed because it's only going to be
a few seconds to do. If I was to look up say,
developer laptop, Mac. I'm on the catalog item table,
and I want to translate it. You can imagine if this is one,
you could do ten, you could do a hundred. You can do it from the list
and select them. But already,
from that catalog item, I know that I'm going to need
to translate the name, I'm going to have to translate
the short description, the description,
and the variables, and maybe some choices
in those variables as well. Potentially, I could be
looking at three or four of the five translation tables. But I don't want to. Maybe I just want this
to be simple, and I just want this to be doable. See this UI action up here,
Request Translations, I'm going to click on this. We’ll come to the edit one
in a minute. I've added a bunch of languages
on my instance just to show that you can and I’ve prefixed it with this self-lock
to say self-localized. That's what it means. But if I was to take Japanese,
just because it's easier to see in these demos. What's going to happen now
is the artifact script will run. It will go
and find that these fields are translatable field types. Then when it's picked up
all of the translation sources, which I'll show you in a second,
a task is generated and you can automate
who that goes to. It's just config. There's no issues there
and you can also define what type of workflow
you want to do. We've pre-canned a bunch
in the app itself. But if I look at this name field,
you'll see it's translated text. Straight away
I know that that's going to go to sys_translated_text. People are already thinking,
oh, but I need that document field value. That's the sys_id of this record. But I don't want to do that
right now. Let's have a look at this task
that's been generated. While this loads,
we have another question about notifications. Are push notifications
also supported like normal notifications? Good question. I'm pretty sure they should be,
but we’ll double-check on that. But I'm pretty sure it should be. We've got this task, normal form, nothing special,
I can add approvals if I want to. That's fine.
I can converse in the work notes. That's also fine. If I hit translate
in the top right-hand corner, you'll see that on the right here
it's actually telling me that my translations for these
already exist. This is what we call
a comparison UI. You can do this
since the Quebec release. If you're not on Tokyo,
that's fine, you can do this on San Diego too. It's absolutely fine. You'll get exactly
the same functionality. The reason it's grayed out
is because it is trying to protect me
from making my own mistake and overwriting it. If I was to click this padlock,
and maybe I did know better, maybe I do write
and read Japanese, I don’t,
but imagine I do for a second. I could potentially type away
in here. If I wanted to publish
those translations, I could hit publish up here
and that's when the record will be populated in the tables. But maybe
I just want to retranslate it, just for you guys. I'm going to save a quick draft
and what I'm going to do now, is I'm going to send it
to Microsoft because I have an integration
with Azure on this instance. What's going to happen
when I click Machine Translate is it’s only going
to send this one. It's not going to send the others
because we already have values for them. There's no need
to waste a token for that. I’ve hit Machine Translate,
that’s going to go to Microsoft but if you've got another one,
that's absolutely fine. Then we're going to get
a translation comeback. Now already the keen eyed
amongst you if you saw it, this shouldn't be translated. This goes back
to my comment earlier about the quality of translations. That's because Microsoft
doesn't know my business terms It doesn't know my glossary. Really,
you don't want to translate a product name. You don't want to translate
company names because they may not be known
as that. That goes into that glossary
and style guide concept. Then also,
I can protect it if I want to, so then that won't be overwritten. Let's take this one step further. Let's say I wanted
to translate this portal. If I just do a quick refresh. I wanted to translate
all of those widgets along the top. I want to translate
the content aspects on the top, the widgets. Maybe I wanted to translate
these topics. Maybe I wanted to translate
all of these quick links and maybe the applications as well. If you've done it the old way,
that could be quite an endeavor. Let's say we could go
to the portal table. Let's say we could go
to the portal record. I have a blog post on all of this
so you're absolutely fine to use it. Now we know that we are
on our portal record in question, which is on
the SP portal table. Sure. With that piece of information,
we can write a query, it becomes our artifact. We know what all these pages are. We know we have a page route map. We know that we have widgets
and widget instances in each of those pages. That's fine.
We know we have catalogs. We know we have a taxonomy. Let's see what happens
if I request translations for it. Let's say I want it in Japanese. Now, this will take a moment because it's a very big query. But let's see what it does. Now I'm going to challenge chat. How many strings
do you think make up the demo ESC portal? That is a great question. There was one question
in the meantime about the Machine Translate button
and Karina asked you, was a little confused
where that sends the translations. You mentioned Azure. Does Azure translate it for you? If you configure it to do that. That's what we call a setting,
and I'll show you that in a second when this task is generated. That’s a good question. That can be Azure,
or Google, or IBM, or whatever service
you set up there. Yeah. If I quickly like this one
and if we go back to here while that's loading,
in the section of the localization framework,
you have to define a setting. The setting could either be
one that rules them all, it doesn't matter
what artifact you're using, you tell it to go over there. That's fine, you can do that, or you can create one per artifact,
or you could even create one per artifact, per language, if you want to be
that kind of granular. If I go to the catalog, item 1, which is the one we just run,
I've told it all these languages, I want it to go to Microsoft,
or I want to allow Microsoft to be usable
because that's what I've got configured on this instance. If I go to workflow preferences, these are those different
pre-canned workflows that we have. If you want to go 100% automated
and not worry too much about the quality,
you potentially could go fully auto-translate,
auto-publish. I wouldn't recommend that, but if you need to be quick,
it's there. That's the takeaway. If we go to the task
that we've just generated, we can see that our portal
is partially translated. Put your numbers in chat,
we want to know what you think, how many strings
need to be translated. I'll show you the UI
so you can guess. We're going to have to think
about all of these, all of these, all of these. This is not including
catalog items and not including
knowledge articles. It's just the UI. Be brave. I think people are afraid to guess. I say it's 20,000. It is a few thousand. 3,000 comes in. It’s more than three. Six and a bit thousand. 6,000. If I collapse it,
we're using the same process, we're using the same UI,
the comparison UI, and this artifact,
which is freely available, you guys can use it. It's on my blog post. I talk how you can do it
and how it works. It's broken everything up
into the portal, the theme, the footers,
all the different sections that you would care about. If you want to tweak it
and you want to modify it, absolutely fine. It's there for you guys. If you wanted to take
and strip out one of the functions and say,
I just want to do the taxonomy or I just want to do a certain page
on a certain widget, you can do that if you want to. The idea was just to show
the art of the possible. If I wanted to translate
all of this into Japanese and pick up those last strings,
I could send that to Microsoft Azure, because that's what
I've configured. Then when I go to the portal,
I could change my language. Notice we also have
a new language switcher widget. I could go into Japanese. Then when the page refreshes,
we will see the interface in Japanese. You've just seen
when this refreshes that you can technically
translate a portal quite quickly. That is amazing. I wish I had that six years ago. It would have been so great. That would have made my life
so much easier. I had colleagues from Poland
asking for translations and the colleagues
from the Netherlands, and from Sweden. I'm like, I am so sorry, people. I don't speak
either of those languages. I couldn't guarantee
for the localization to be good so I only offered German
and English. If I scroll down
you can see it's all there. That's amazing. All right. Do you think we should head back
to the presentation for the last 2 minutes
to give you a chance to wrap up? Yeah, sure. Awesome. Yeah. We have a bunch of links. If you go to the CSC,
the plan your localization page is very, very helpful. We've got a workbook. If this is a completely new
and alien concept to you guys of how would you stand up a team, how do you get into the idea
of development practices and whatnot,
check out the workbook, it will get you
really helpful on that. In terms of
if you're doing a project, where do you begin? If you're trying to maintain
an instance that is going to add a language
that you haven't done in the past, you can do that. We have training,
the Localization Expert Series in Now Learning
with loads of different modules. The first one goes through
that localization framework and the principles of how it works. It gets into more
about how to do a deep dive on a project
and to plan it out, scoping, and all those different things. What a process owner
needs to know, what a platform owner
needs to know, and then it goes
into some of the more advanced considerations. We've got
internationalization guidelines on the developer site,
which talks about like I said, the word ratios of Italian
being longer than maybe South Korean, for example. Obviously,
we've got documentation as well. But on the
plan your localization page, you should also see a title
that takes you directly to our forum on community as well. We've got
some very deep-dive topics on there,
especially that portal artifact and a configurable
workspace artifact as well. I will share those resources
and the links on the community post
that you follow to get here. I will quickly call out
the last question. The last question is about
very manual efforts in getting translations
into every field. It's very tedious. Would you recommend
we connect with something like Azure? Would it do this automatically
and not require the manual work? I would definitely suggest
looking at the localization framework, whether you use Azure or not,
it doesn't really matter. It would simplify the act,
but you may still need to review the translations. If you want to go through
in more detail, you're more than welcome
to reach out to me and we can do demos,
we can go free-solutioning. That's fine. My team itself is actually
customer-facing as well, so if you need
any further deep dives, that's absolutely fine. All right. My last couple of slides. As I said,
I would love for some feedback. Please take two minutes
to answer these questions. You'll get another email
from our marketing team after this session that ask
for your feedback specifically. Then the other Platform Academies
that I was talking about, we have academies
about Analytics, Mobile, Virtual Agent, AI,
and Next Experience. Please check those out. My colleagues
are doing amazing jobs in their academies,
have incredible topics as well. And that is all
that we have for today. I thank you so, so much, Alex. This was so enlightening. This was an amazing session. Thank you for having me. I learned a lot
preparing this session and doing this session. Thanks, everybody, for joining us. Thank you for your questions
and I hope to see you all again in two weeks. Our next session, we'll go through some different integration options
and which kinds of integrations you can use to connect
your ServiceNow instance to other systems. Have a wonderful day
or have a wonderful rest of your night. If you're in Europe,
a wonderful morning in APJ and see you next time. Goodbye.