Is it really necessary to create the English equivalent of the translations?

[Rain Vaine]

Hello expert,
Just a question. When creating a translation record especially for sys_ui_messages, is it really necessary to also create the englih record counter part? Because in my case I only created the Japanese record for my report widget in my dashboard and it seems to be working fine. Is there any significance on creating it English language counterpart?

Regards,
Vaine

[Community Alums]

Hi @Rain Vaine ,

 It's not always you have to create the English counterpart but it's required, i have noted down a few use cases to help you :

Translation methods and use cases

What needs translation	Approach to take	Resources
Field labels in a table for a customer-created application	First create English versions for all fields in the table. Then open the Field Labels translation table. Locate the records for the table in the application. Export the records, translate the appropriate fields, set the language field, and reimport through an import set.	Export and edit translation records. Alternatively, follow the procedure for translating individual labels in Translate a field label.
HTML in a UI page in a customer-created application	Create the English version. When creating the HTML in the UI Page form, wrap any translatable text in gs.getMessage calls. Create a Message [sys_ui_message] record for each English message with a corresponding key/value pair. Create additional Message records for each message for each other language.	Translate a client script message
Service Catalog items	Navigate to All > System Properties > System Localization and set Display translation prefix on translatable strings to Yes. Create the item in English. Change the preferred language to a different language. Translate all the translatable items, now identified by translation prefix. Save the record.	To activate translation prefixes, see Debug translations. For translatable text fields, which are common in Service Catalog items, see Translating text fields.
Service Portal widget	Create the English version. Externalize any translatable text by surrounding the text with ${} wrappers. Create a Message [sys_ui_message] record for each English translatable text with a corresponding key/value pair. Create additional Message records for each piece of translatable text for each other language.	Translate a client script message Internationalize a widget in Service Portal documentation For unofficial advice, see Building multi-lingual service portals
Edit a translation provided in a plugin	Export the records from the translation table. Edit them outside the translation table and reimport them. Do not edit the records directly, because your changes could be overwritten when you upgrade or zBoot your instance.	Export and edit translation records
Translate an instance to an unsupported language	Create a Choice [sys_choice] record for that language. Add other translation records through the Export and import set approach.	Translate to an unsupported language
Support Chat texts	Support Chat is mostly translated through the I18N language plugins. If you customize any Support Chat texts, follow the procedure for Service Portal widgets.
Notifications and Surveys	System Localization does not cover platform notifications or surveys. The usual approach is to create a separate version of each survey or notification in each language and use business rules to send the right language version to the right end user.

[Community Alums]

Hi @Rain Vaine ,

[Alex Coope - SN]

@Community Alums,

Just a heads up, some of the information in your table is now out of date 🙂

Surveys have always been translatable and Notifications have been supported since the Tokyo release for example,

A lot of what's listed is possible via the Localization Framework,

Many thanks,
Kind regards
 

[Alex Coope - SN · Accepted solution]

@Rain Vaine,

So, technically speaking no you don't need to create the English entry in [sys_ui_message] because the system will display either the message of a matching key if a record in that language exists and if not it will present the string passed into getMessage.

However, with that being said, it is our best-practice to create the English as it will be easier to find and modify should you want to in the future,

If in doubt, we have a mega thread for our various In-Platform Language support features with multiple spin off links to other docs, materials as and where necessary, 

Many thanks,
Kind regards