11.3 Localizing the SailPoint UI

Localizing the SailPoint UI

Objective 4.10 asks you to perform localization in the SailPoint UI for common customer use cases. The usual cases are changing product wording, translating labels for non-English users, showing application, role, and entitlement descriptions in several languages, and localizing custom forms, reports, and emails.

How IdentityIQ Chooses Text

IdentityIQ UI text comes from message catalogs: Java .properties files of key=value pairs. The user's browser language decides which language catalog is used. For multi-language descriptions, the description shown depends on the browser language, falling back to the configured default.

• Product catalogs ship inside WEB-INF/lib/identityiq.jar, in sailpoint/web/messages/iiqMessages.properties and language variants such as iiqMessages_it.properties.
• The customer override catalog is WEB-INF/classes/sailpoint/web/messages/iiqCustom.properties. It is empty by default. A key placed here overrides the product value, and you never edit the jar.

Common Use Case 1: Change or Translate a Label

1. Find the message key. Search the product catalogs extracted from identityiq.jar, or inspect the page.
2. Add the key with your text to iiqCustom.properties for the default language.
3. For another language, create a language-suffixed file such as iiqCustom_fr.properties or iiqCustom_de.properties, or a locale-specific one such as _fr_CA.
4. Deploy with the build and restart, then test in a browser set to that language.

# iiqCustom.properties  (this key is the alt text of the header logo)
ui_sailpoint_logo=ACME Access Portal
# iiqCustom_fr.properties
ui_sailpoint_logo=Portail d'accès ACME

Keep these files in the build (SSB web or config layout), because upgrades replace the installation directory.

Common Use Case 2: Multi-Language Object Descriptions

Business users see application, role, policy, and entitlement descriptions throughout LCM and certifications. To localize them:

1. On Global Settings > IdentityIQ Configuration > Miscellaneous, under Localized Object Attributes, enable multi-language descriptions for applications, roles, policies, and/or entitlements.
2. Under Multi-Languages Descriptions, choose the Default Language and list the Supported Languages.
3. Add every supported language to the <locale-configure> section of faces-config.xml. The documentation says the application will not recognize the languages otherwise.
4. Enter descriptions per language with the language selector on each object's page. Save each language before switching to the next.

Policy descriptions can be localized, but policy rule descriptions cannot.

Bulk-Loading Entitlement Descriptions

The console command importManagedAttributes loads a CSV. The first line is a comment naming the columns, which can include locale columns such as en_US or fr_FR holding the description for that language. Later comment lines can set defaults such as application=AD. Required values are type (default Entitlement), application, attribute, and value.

# value, displayName, en_US, fr_FR
# application=AD
# attribute=memberOf
CN=Finance,OU=Groups,DC=acme,DC=com, Finance, Finance department share, Partage du service Finance

Watch the HTML rules for descriptions. Certain escaped characters must be written correctly, such as < and ", or they will not display.

Common Use Case 3: Custom Forms, Reports, and Emails

• Forms: field labels (displayName) and help text (helpKey) can be message keys, so the same form renders in each user's language.
• Reports: report form labels and ReportColumnConfig headers are evaluated first as message keys (for example, rept_uncorrelated_ids_grid_username). If no key matches, the literal text is used. Render scripts can call Message.localize(key).
• Email templates: call $spTools.getMessage("key") for catalog text, and $spTools.formatDate(...) for locale-formatted dates.
• Server-side code: use the Message object's localize method with a catalog key.
• Security questions on the User Reset tab can be message keys from the properties file, which is how the questions are internationalized.

Common Use Case 4: Plugins

A plugin carries its own catalogs in its messages folder, one per language, for example TrainingPlugin_fr_ca.properties. Prefix plugin keys with the plugin name to avoid collisions with product keys or other plugins. Full-page plugins translate with the msgs function, and widgets use the spTranslate filter from the SailPoint Angular bundle.

Planning a Multilingual Rollout

Localization is easiest when planned before content is written:

• Decide the language list early, and configure it both in the Miscellaneous tab and in faces-config.xml.
• Use message keys in custom artifacts (forms, reports, and plugin pages) from the start, rather than hard-coded English, so later translation is a properties-file task.
• Translate the business data too. A French user who sees French buttons but English entitlement descriptions still cannot make a good certification decision. Load descriptions with importManagedAttributes or the per-object language selector.
• Remember email. Notification text comes from templates. Use spTools.getMessage keys or separate templates per audience where needed.

Checklist and Traps