What to expect on installation of I18n translations plugin for existing translations

Mostafa El-Baro
Tera Expert

Dears,

 

Kindly could you provide your insights regarding what to expect on installation of a translations plugin (Arabic Language) when the instance already contains thousands of translation records across all localization tables (translated text, ui messages, documentation, choices, etc.) ?

 

Does the plugin installation overwrite pre-existing records, or does it preserve the current versions and skip conflicting entries from the package

 

Thanks in advance.

1 ACCEPTED SOLUTION

Hello Mark,

 

It's simple actually, you can create a language record and create a choice for language selection.

So we applied this in our instance because the Arabic translations package hadn't been released yet back then.

https://www.servicenow.com/docs/bundle/yokohama-platform-administration/page/administer/localization...

https://www.servicenow.com/docs/bundle/yokohama-platform-administration/page/administer/localization...

Anyway, I reproduced the exact same case on a developer instance and found that i18n language plugins installation (for an existing language record) skips all conflicts keeping the old translations as they are.

View solution in original post

5 REPLIES 5

Mark Manders
Mega Patron

The plugin will only introduce the Arabic Language. It will only create the Arabic translations for the OOB fields/messages/documentation that are available. It doesn't override other language packs.


Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark

Hello Mark,

Thank you for your reply. But I think I did not make my case clear.

Actually, I meant existing translations of the same language.

For example we translated the message "Hello" to "أهلاً بك".
And the Arabic language pack, contains a UI message record that translates the same key "Hello" to "مرحباً".
Regardless of the translations, but I wanted to clarify that there will be conflicts for the same keys and records for the same language between pre-defined custom translations and translations from the plugin.
My question is, how will the plugin/application manager handle these conflicts during the installation?

 

Thanks.

How are you switching languages at the moment? Installing a language pack enables a new language on the instance and includes all of the OOB translations. How are you currently showing your Arabic translations to your users if you don't yet have the Arabic language installed? 

Installation will install new records on your system. That could mean that you get duplicate keys or existing ones get overwritten. It just doesn't really make sense that you already have translations, but not yet have the language pack installed.


Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark

Hello Mark,

 

It's simple actually, you can create a language record and create a choice for language selection.

So we applied this in our instance because the Arabic translations package hadn't been released yet back then.

https://www.servicenow.com/docs/bundle/yokohama-platform-administration/page/administer/localization...

https://www.servicenow.com/docs/bundle/yokohama-platform-administration/page/administer/localization...

Anyway, I reproduced the exact same case on a developer instance and found that i18n language plugins installation (for an existing language record) skips all conflicts keeping the old translations as they are.