Are translated sys_documentation records overwritten when upgrading SNOW version

[AlainT1]

We work in Canadian French (fq) and we installed the French Canadian language pack.  During our onboarding onto the ServiceNow platform, we are correcting numerous labels in the sys_document table.

We need to confirm that our efforts are not futile and that they will not be systematically overwritten when we upgrade our ServiceNow version.  We would be very fine with  "skipped upgrade" records during the upgrade scan.

Can anyone confirm this please.

[Maik Skoddow]

Hi

the table is named sys_documentation and as that table is real configuration the changed records should be marked as skipped in the next upgrade. But to be sure that your work is not futile I recommend capturing all changes in an update set or exporting all changed rows to an XML file. That way you have an backup.

Maik 

[Mark Roethof]

Hi there,

While what Maik is mentioning is the correct in theory... that's not what I have experienced on multiple customer instances in the past when it comes to translations. Some of the translations are being corrected and overwritten with Patches/Upgrades!

If my answer helped you in any way, please then mark it as helpful.

Kind regards,
Mark
2020-2022 ServiceNow Community MVP
2020-2022 ServiceNow Developer MVP

---

LinkedIn
Community article, blog, video list

[Alex Coope - SN · Accepted solution]

@AlainT,

There's a couple of things to unpack there,

If there's any Quebecois terms that you are correcting, if they completely incorrect / wrong etc, please could you raise a case for them (you can raise it as a single case), please include the URL path as to where that string is so our Localization team can review the context as well as the reasons you feel they aren't accurate / correct.

Secondly, the logic for the language packs during an upgrade (it's actually immediately after the upgrade has finished) is a little different to standard plugins. In that, for each of the 5 translation tables we have to do very specific checks (per translation). With regards to the entries in the [sys_documentation] table we are looking to see if that table's field label exists in the [sys_update_xml] table which would imply it is a customization. This then lets us know if we should ignore it.

Therefore the best way to migrate translations of this type between a sub-PROD instance and a PROD instance is indeed via update-sets, because if you run a manual import per instance it wouldn't necessarily add an entry in the [sys_update_xml] table. Ultimately the intention is always to ignore any changes you've made to what we provide ootb as you may have very valid reasons to change terms. We also would have no reason to touch / modify any net-new translations you've made due to the previously mentioned logic,

If you have any more questions on this specific topic, please feel free to reach out to me and we can organise a call if necessary,

Many thanks,
kind regards

[AlainT1]

Thanks Alex,

That is excellent news.  So basicaly, ServiceNow will consistently ignore our translation, as long as they are present in update sets - got you. 

As for opening a case, I am currently discussing with @Yobany Amaya the make sure that we communicate those in a way that will work for ServiceNow and for us.

Alain