Language Pack installs Translated Choices Where No English Choice Exists

[Mathew Hillyard]

Hi all,

I have recently come up with some strange behaviour when installing language packs. This occurs in both Tokyo and Utah and applies to both German and Polish language packs.

In brief, the plugins use the Import Set/Transform functionality on platform to install various records supporting translations, one of which is in the Choice [sys_choice] table. I notice that when the packs have installed, there are many (as in tens of thousands) of choices for the translated languages set to inactive = true. When I look closer, it's because there are no Choice records in English, and the Transform Map will expressly set the Choice to inactive if no English equivalent can be found - makes sense, you cannot translate something when nothing exists as a starting point. However, on a vanilla Utah instance, installing the Polish language pack results in over 70,000 inactive Choice records!

Looking at some of these Choices, they do not appear to be "genuine" data. For example, in the Incident table the Polish choices contain many values that do not have an English equivalent where the Value is something that resembles demo or custom data, e.g. "Service is stable, ok to close ticket" is not a valid Resolution code in English and doesn't match the normal values you'd expect for this field. This was observed for both the German and Polish language packs.

I understand activating other plugins may result in new (English) choice values being installed, but nevertheless something seems awry. I further note that in Utah there is a new Related Link on the Language record - "Repair non-english sys_choice records", which suggests there may have previously been a defect with Choices being set to an inactive status in error.

Any thoughts/observations/suggestions are welcome.

[Alex Coope - SN]

@Mathew Hillyard,

So, what you're describing is because when you install a Language Pack, we also include all the translations for the plugins (including ones you've installed and not-installed at the point - meaning they are genuine). Hence, you are seeing every single possible choice for all the plugins in the platform, and indeed if you don't have the English record we mark the translation record in [sys_choice] as "inactive=true" until an appropriate time has been met.

As a side note, when it comes to Store Apps this is a little different, in that the translations for those are now mostly contained in the Apps. This was a change we implemented back in SanDiego / Tokyo timeframe to help with reducing the time it took to install the Language Packs,

By all means let me know if you have any further questions, but our thinking (from back when this was first created - which was many many years ago) is essentially to err on the side of caution and install all possible translations when you install a pack rather than just ad-hoc items, so you don't have to keep revisiting the Packs after every feature plugin is installed (Imagine that activity after every Plugin and each dependent Plugin, it would be a lot of work for an Admin). However, I can't talk too much about the future, but this will change one day in the near future,

Many thanks,
Kind regards

[Mathew Hillyard]

Hi @Alex Coope - SN 

Thanks, I reached the same conclusion as no other explanation for so many inactive records made sense. Thanks also for the advice around Store Apps. Both instances make perfect sense and explain why a language pack takes a little while to install - certainly easier than revisiting languages after every plugin install, as you said.

None of the translated sys_choice records contain either a sys_created_on or sys_updated_on value, which seems a little odd as I would not normally expect to find any records without these system-generated fields - possibly this is something special to the sys_choice table?

I also notice that a Utah version of the I18N Core plugin installs a related link on the Language record (when the language is activated) to fix the English choices ("Repair non-english sys_choice records"), which is not present on Tokyo. I presume this is related to a known issue. I don't suppose you have a PRB reference as it would be good to know whether customers need to take additional steps if still on Tokyo where this option is not available?

What appeared slightly surprising was when I looked at some of the translated choice Values - e.g. in German and Polish, for incident > close_code there are 10 additional choice options, including choices with values like  "AC" (Automatisch schließen in German, Automatyczne zamykanie in Polish) and "CBBC" (Rückruf vor Abschluss in German, Oddzwoń przed zamknięciem in Polish). At first glance these look incorrect, almost like demo data, but given the translations appear genuine ("Closed automatically, and "Call back before closure"), I assume these are for something above and beyond the OOTB Incident Management application?

Thanks again for your rapid and detailed response.

[Alex Coope - SN · Accepted solution]

@Mathew Hillyard,

No worries at all. 

So with the 5 translation tables, since Tokyo we've changed the way the translations load and now no-longer use the Transform Maps (hence they no longer include meta-data such as sys_created_on etc). The new method has helped us trim the install time from 3-4hrs down to 20-30mins. It's important to state that the metadata is only not included for translations and will not affect any of the English records in the 5 tables.

The "fix English choices" UI action you are referring to, is for when you are adding a language / locale we don't provide (e.g. es-MX aka Mexican Spanish) and you need the choice that is selectable by an end-user to be made or changed back so not a PRB but more of ensuring you have a choice made when necessary,

Many thanks,
Kind regards 

[Mathew Hillyard]

Excellent, thanks for the comprehensive explanation!