3 steps to consider when translating a ServiceNow instance in another language
Who doesn’t know the situation: You want to translate the ServiceNow instance in another language. There are the OOTB translations after you activate a language plugin, but typically they are never enough because you have done at least one customization (like a new field or a new field choice, etc.) which you will have to translate by yourself. In this post we put the emphasis on the tips when translating an instance not manually, but using template files that will be translated in different languages and then will be imported and transformed. It should go without saying, but it is always a good idea to validate the translations through native speakers.
To smoothen your translation project keep the three following steps in mind:
1. Before starting with the preparation of templates
- Search in all your scripts for hard coded text (e.g. UI actions, business rules, etc.) to convert them into messages in the UI messages table, and then modify the script to read the corresponding message:
e.g. gs.addInfoMessage(“This incident is linked to an existing problem”) should be modified to gs.addInfoMessage (gs.getMessage(“This incident is linked to an existing problem”)). It is also a good idea to use keys for short messages, as the same word in English can translate in multiple ways in other languages. E.g: if you do “gs.getMessage(‘Order’)”, should the German translation be “Reihenfolge” or “Bestellen”?
- If any script exists that is checking for a field label and not a field value, they also have to be modified to check for the value of the field, as after the translation different labels for the same value will exist.
- For translating the labels of custom related lists (e.g. custom many-to-many tables) on a form, first a label has to be created by right clicking on the list header -> Configure List Control -> and entering a label in the ‘Label’ field. This will create an entry in the sys_ui_list_control table that can be later translated.
There are out-of-the-box Import Set Tables and their corresponding Transform Maps that do assist in translating all the necessary system objects, so what you have to do is just prepare the excel spreadsheets and then import them using the right import staging table.
The most important part is identifying which table or field should be translated. For this the table below summarizes a mapping information: the first column shows the objects to be translated, in the second column you can seethe out-of-the-box import set table used when importing the translation files, and in the third one is the target translation table.
For the CMS – what needs to be translated are mainly the menus, record producers (variables plus the help text under each variable), static pages.
Translating the Service Catalog can result in being quite heavy in case you have many catalog items, because all the variables, the variables’ choices and their hints need to be translated.
2. How to export the records and prepare the excel spreadsheets
Preparing the excel files to be handed over to people for translation needs some attention, i.e. to put them into the right template. For each of the tables mentioned under the “Objects to be translated” column in the above table, go to the list of all records and filter out the ones created by any system user because this means a translation should already exist in the system for every language (unless you deliberately want to assess and validate the existing translations from native speakers).
The picture below shows a quick filter of the out-of-the-box related list labels created by some system users. Note that this list is not exhaustive as you will have to do judge yourself what users are not system users.
The instructions for filtering out the out-of-the-box records should be applied to all of the following points when preparing the excel spreadsheets.
-> For translated names and fields under System Localisation > Translated Name / Fields
The data from all the tables mentioned in the third row of the mapping table should be copied into the respective template sheet for Translated Name / Fields, like in the picture below, which is a snapshot from a template file with Turkish translations.
-> For Messages, Field Labels and Choices – you can export the required records directly from the modules with the same name under System Localisation application and leave the template as it is.
-> For the translated text under System Localisation > Translated Text
It is a better idea to translate the knowledge base articles using the UI by giving people access to the instance, because of the HTML nature of the Text field of the article which makes it cumbersome to translate it in an excel file, and because you will need the sys_id of the original knowledge base article. But if you still want to go this way, then the template should look like in the following picture where the first two records are for translating the KB article with sys_id in the Document Sys ID field, and the other records are examples of other translated text fields for which a Document Sys ID is not required.
-> Email notifications have to be imported on the email notification table like a normal import, they do not need any import set table. Note that after exporting the email notifications in an excel file, the encoded condition should be modified with the language code of the language being translated. In case your email notifications were not setup with English language in mind, but English is the only language in your instance, then the conditions of all email notifications should be first modified by adding the language (typically the requestor’s language) in the Condition field and then exported for the translations.
Put the above-mentioned excel sheets in one single file, prepare one copy for each language, and then you are ready to send it to the native speakers of the respective language to perform the translations.
3. Importing the translated files
When the translations are ready, follow the following steps:
1. System import sets > Load data
2. Select the “Existing table” option
3. “Import set table” – select the system table based on the information from the mapping table
4. Select and run the only transformation map that is available
And that’s it. By undertaking these steps, it should become easier to execute your instance translation project and make its outcome a success.