Intro
The ServiceNow platform supports multiple languages through the activation of I18N plugin and language packs. The system stores the data used for the translations of any standard applications installed and allows administrators to accommodate users from a variety of different countries.
Developers can update existing base line translations working on the records available in five tables.
Translated Name / Field [sys_translated]
Message [sys_ui_message]
Field label [sys_documentation]
Choice [sys_choice]
Translated Text [sys_translated_text]
In general this is an easy task.
However, things can be more complex for Field label records in case you have scoped applications installed (e.g. Human Resources: Core) and can have an impact on requirements concerning translation.
The Issue
[sys_documentation] table is the only one including the Application [sys_scope] field and the records are always linked with a scope. For this reason, a developer working on label translations must always double check if the right scope has been selected.
ServiceNow language packs are no exception. New translation records are deployed in the table for all the possible applications installed in the instance but unfortunately the plug-in creates all of them as part of the 'Global' scope.
The next image illustrates the issue.
In this example, we have an instance where the 'Human Resources: Core' application and a language pack are available.
Clearly the scopes are different.
- The first record is the original 'English' label included with the scoped application.
- The second the 'Italian' translation included with the language pack.
A common requirement during project involving translations is to update some of the translations obtained through the language packs.
Unfortunately, the system does not allow to update the labels because of the conflicting scopes.
If you select the 'Human Resources: Core' application and try to update 'Label' or 'Plural' for the second record, the system is preventing it.
This is expected because the record belongs to the 'Global' scope.
If you select the 'Global' scope, the system releases the record, but it is not possible to complete the update because of a cross scope issue.
The list of COE tables is not available from the 'Global' scope.
Solutions
There are few solutions available for the issue described.
Simple Workarounds.
Option 1
- Export the original translation record as xml and retain for future reference.
- Create a new translation record under the right scope.
- Update the copy.
PROS.
- Simple
- Manual work
- Solve the cross scope issue
CONS.
- Remove the original record
Option 2
- Export the original translation record as xml
- Open the xml in an editor.
- Update the content of the tags used by hint/label/plural
- Import the xml back in the system to override the original version
PROS.
- Simple
- Manual work
- Re-use the original record
CONS.
- Override the original record.
- Does not solve the cross-scope issue
Advanced
This last section suggests possible approaches to solve the cross-scope issue and avoid repetitive works introduced by the previous section.
Massive Replacement.
- Execute a query and collect all the records available for a specific app included in sys_documents.
- Export all of them as XML for reference
- Create a script with the following logic
1 - Query sys_documents and collect all the records created for the app
2 - For each record, create a duplicate in the right scope
3 - Delete the original record.
Few considerations about Cross Scope Control.
The side effect primarily is caused by the missing access to the scope.
Someone on the community suggests relaxing the baseline cross scopes set up and give access to the list of tables from Global scope. The solution, in my opinion, can be possible.
On the other hand, any modification executed on that side of the platform
- requires an exhaustive analysis of the actual security settings
- can have a disruptive impact on the overall security of the scope architecture
- too complex for the type of requirements
For the reasons stated above should be avoid.
Stay tuned for more
R0b0
