Globalization Best Practices

Globalization is a powerful yet complex feature. Following best practices as you plan and implement multiple languages will help ensure your success.

Consider Impact of Translations

If you intend to globalize your system at some point, always design your customizations with translation in mind. Some translations may require Form adjustments, for example. See Managing Controls on Translated Forms.

Add One Culture at a Time

For best results, enable one culture and translate strings for that culture before enabling additional cultures.

Use Lookup Tables for Field Validation

Values for Fields that validate from lists cannot be localized. Use Lookup Tables to ensure that validated values are available to users in all languages.

Benefits include:

You can apply foreign key support to the validated Fields. See Storing Foreign Keys for Validated and Auto-populated Fields.
You can backfill translated values in existing records.

Use the Content Optimization Tool to easily convert validation lists to Lookup Tables.

Manage Language Packs Within Blueprints

Create and apply Language Packs through Blueprints or mApp Solutions to manage translations for new or modified definitions. This enables you to maintain translations as your system changes and to manage smaller Language Packs than those created outside of Blueprints or mApp Solutions.

Use Small Scopes for Language Packs

While you can create a Language Pack that contains a large set of strings for multiple scopes, you may find it easier to manage multiple Language Packs that have a smaller scope for each target language.

Benefits include:

You can manage translations, particularly reviews, in small batches. This is especially useful if multiple people are performing these tasks.
You can apply small Language Packs more quickly than large Language Packs.
You can use Language Pack naming techniques to manage the various types of strings that need to be translated.

You can apply Language Packs separately as they are ready, or you can create a Language Pack with an empty scope, and then merge completed Language Packs into it. You can then apply the merged Language Pack at one time.

Create Language Packs that Contain Only Tokens or Rich Text

You may find it useful to translate certain items as a single Language Pack. For example, you may want to create a Language Pack for the Incident scope that contains only Tokens.

To do so:

Create a Language Pack.
Open the Language Pack in the Language Pack Editor.
Verify that the Hide items containing Expression Tokens and Rich Text Strings check box is selected.
Select all of the visible strings, and then delete them.
Change the filter to Show only items containing Rich Text strings.
Select all of the visible strings, and then delete them.

Your Language Pack now only contains Tokens. You can use the Show only items containing Token Expressions filter to view and modify these strings following the guidance in Translating Plain Text Associated with Tokens.

Best Practices For Locking Strings from Translation

You can prevent strings from being translated by locking them. You can then exclude the locked strings lists when you apply a Language Pack. This can be important during different stages of your localization strategy, including the first time you localize your system and also during system maintenance and upgrades.

First Time Localizing Your System: When first localizing your system, you might exclude certain strings from being translated. Users can create one or more lists that can be selected when applying a language pack as part of the LP wizard. For example, you can create individual lists for each language, category of strings, child company of an MSP (Managed Service Provider), etc. Locked strings lists can be modified and updated at any time.
System Maintenance or Upgrades: Once the system has been localized, translations for certain strings might need to be changed based on context or preference (personal or stylistic preference). Since Language Packs do not contain duplicate entries, only one possible translation is contained in the Language Pack. This can result in existing, customized, context-based strings being overwritten. To preserve these existing translations, locked strings lists can be used to prevent overwriting when a new Language Pack is applied for updating (localizing newly added content) or maintaining your system.

Best practices for strings to include in locked strings list:

Team Names: Team names (such as "Customer Service" and "Accounting") might be used in other contexts in the application (example: Service Category within an organization). Also, Expressions and Stored Searches can reference Team Names and can break if Team Names are translated.
Company and Product Names: You may want to lock Company and/or Product names so they are not inadvertently translated and applied to your system.
Polysemantic Words: Words with different meanings based on context/part of speech can be difficult to translate (examples: order, record, open, site, state). These words can be used as a noun or verb or assume completely different meanings based on context.

For general guidelines on creating and managing Locked String lists, see Managing Locked Strings

For specific categories of strings that could cause issues when being translated, see Globalization Good to Know.