Transcript

X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Hello, everyone, and welcome to five things I wish I knew before attempting to localize my scope application. My name is Maria Gabriela Ochoa Perez Waechter. My pronouns are she, her, and I'm a 2022 and 2021 ServiceNow developer MVP. Hi, everyone. I'm Jesalyn. I'm a ServiceNow developer, and I'm looking forward to sharing what we've learned about localization. So before we go further into the presentation, we thought it would be helpful to go back to the basics real quick. We're going to be using some terms throughout the session, and we want to make sure everyone is familiar with them. So what is the difference between localization and translation? Localization is making an application adaptable to specific regions without impacting functionality. This means your application can show the target language, currency, date formats for that region. Translation refers to changing source text into another language. You may be thinking can't ServiceNow do this for us. The language pack plug-ins that ServiceNow provides only cover out-of-box strings. This means that anything custom that you add or you modify to the system needs to be localized by yourself, and in a scoped application, that's everything. There's a couple of different ways you can localize your app. You can do it by hand or by machine, such as Google Translate. We're going to be focusing on the manual approach because that's what we decided to do. Here's some tools to help us localize our application. We recommend using them since they made the entire process a lot easier. The out-of-the-box tools that are available are the Translation Prefix System Property. It places a prefix-like message before each string to tell you which table a string is on, and that helps with debugging and identifying translation gaps. And then there's the Translate and Learn System Property that will automatically create records in the applicable translation table for any strings that are missing translations. So what you basically end up doing is you click through your entire application, and it's going to pull things like table names, options for the fields and automatically create translation records for you in the corresponding tables. Another great tool that is available online is the FetchCode project on the ServiceNow share. We used it to help us identify hard-coded strings in our script includes, in our business rules widgets, and any other place that has a script field. We use this to search for word code that is, in our instance, in a large scoped application with lots of legacy code. It's likely that you don't know where code exists or what it's doing, and it made it really easy to search for everything. Next, we use the website called Crowdin in order to obtain our translations of our strains. We basically compiled everything into a spreadsheet, and we uploaded that into the Crowdin website, where we were able to get quotes from multiple different vendors and select who we wanted to work with from there. And finally, we're going to have all of these resources and many more links in our GitHub repo that's available at the end of this presentation. Now that we've covered the basics and some helpful tools, it's time to learn about the five things that I wish I knew before attempting to localize my scope application. We've broken up the process into five steps, and the first step happens before you do anything. You need to plan your localization strategy. This means figuring out details like what language you're going to support, how you're going to source your translations, and many others. In our case, we decided to focus on Spanish, French, and German since that's what our customers currently requested. There's a few options for sourcing translations, like Jesalyn said. You can use machine learning, such as Google Translate, or you can use experts and native speakers in order to translate by hand. Our team had native Spanish and French speakers available to us, so we only had to figure out plans for German translations, which is where we went with a Crowdin tool. Now that you're ready to start because you have everything strategized. You can go ahead and turn on the language plug-in. During this stage of the process, you really want to focus on finding those missing translations. This is where you want to use the Translate and Learn System Property that we mentioned earlier. This property will create initial translation records for you because ServiceNow will only show translated text if there's a translation record for that string on any of the five tables. This property will create the records for you, so what we recommend doing is turning the property on and then clicking through everything in your application. Going module by module, visiting every form, every list, every widget, every portal page, and so on. And through this method, we were able to generate over 100 records of translations that we need to source. Another thing to focus on is the Display Translation Prefix System Property. What this one will do is it will show you if you have hard coded strings in your instance. Because if there's no prefix, which is what shows you what table a string is from. If there's no prefix, then that means that the string is hard coded, and that is not ideal. And what you need to do for that is convert that into a translatable way. So then ServiceNow knows to translate it, and it won't stay hard coded. And for that, what we recommend doing in the next phase, stage three, is Establishing Design and Development standards. So in order to make sure that everything is scalable and translatable, you want to have standards. So this means not hard coding any strings, and you want to be using the appropriate gs.getMessage depending on if it's the server or the client or even in a portal widget. So the best way to do that is to have gs.getMessage is to structure it by using a system-like message. So the general example you've seen with gs.getMessage is gs.getMessage hello world. So, hello world is what's displayed to the screen or the user. Rather than using hello world, we recommend structuring your gs.getMessage in a system-like way. So the key for the input to gs.getMessage would be a system-like description such as widget header text. Widget header text would then be your key, and your value for the record on the messages table could be hello world. So then, you're still showing the same output of hello world, but you're just structuring it in a way that makes it easier to maintain and to code. Because now, if you have it structured like that, where you're showing widget header text, then when you are doing your search for missing translations with the display translation prefix system property. When you're searching around your instance, and you see the output of widget header text, then you know that you don't have the appropriate translation record. Because it's showing that system description rather than showing the hello world that you would expect to see. So to sum it all up, static strings are bad, and you want to make sure you're always wrapping everything in your gs.getMessage. With everything localized, it's time to test all the hard work that you've done so far. We don't have a well-defined testing plan yet, partly since we haven't reached the stage ourselves. However, what we have done is taken a look at everything in our application to see how it looks when things are translated. Different languages are going to have different sizing requirements compared to English. So what looks good in the English version of the UI might appear cramped or overflowing in the translated UI. So, for example, the word new is three letters long in English, but it's nine letters long in French. This is something to be mindful of and keep in your mind as you go through this process, especially when users are zoomed into their browsers, or they have a larger default font size. Another thing that we plan to do here is have our customers try to navigate our application in English and then in the target language like French, using our service portal as an example. Our goal is to verify that our customers can navigate and use the portal functionality in the same way in English and French. If our customers are unable to use the French version of the portal, for whatever reason, that gets us feedback on what needs to be reworked. And now, great job. It's the future now. The localization implementation has been deployed, and now you need to maintain it. So like testing, we don't have a well-defined maintenance plan just yet. But we are planning on scoping that out and figuring out exactly what's required. One of the things to keep in mind is that as new content and features get added to the app, localization needs to be considered. Code reviews should be checking that strings aren't hard coded and that you have correspondent translation strings in your system for any new updates that are getting added, for example. A good thing about making sure that you're not hard coding strings and wrapping everything in the appropriate gs.getMessage, in your scripts is that this makes maintenance of your strings a lot easier. Whenever you want to change the wording of a message, you no longer need to edit your script includes or business rules. You can instead update the value of the translation record for that key which is a beta change. And finally, we'd like to thank you for listening to our presentation on localization. I hope that this has helped you all get started. If you want to get more resources, you should check out our GitHub repo linked down below, which is going to have a lot more information and links. You should also check out our blog post on WomenNow.dev. We're going to go way more in-depth on what we covered today, and we're going to have code samples that you can reference. You should also come hang out with us at sndevs.com, which is our community Slack server, where we all like to hang out and talk about ServiceNow and ServiceNow related topics. Thank you very much, and have a good day. [MUSIC PLAYING]