Locale settings for each tenant after upgrading IDSP from version 3.4.6

Products

• Symantec Identity Security Platform - IDSP (formerly VIP Authentication Hub)

Issue/Introduction

When upgrading from IDSP version 3.4.6 to a 4.0.x release, administrators may have questions about how locale configurations are handled during the upgrade process. Because locale settings are defined at the **tenant level** rather than the system level — reflecting the fact that each tenant within the same environment can be independently configured for a different locale — it is important to understand which locale entries are automatically migrated, which require manual intervention, and which target version is recommended to ensure a complete and issue-free upgrade.

This article addresses the following:

- Which 4.0.x version is recommended as the upgrade target from 3.4.6.

- How locale configurations are handled for both out-of-the-box (OOTB) and custom (manually created) locales during the upgrade.

- Whether new locale entries are automatically included or require manual population after the upgrade.

Environment

Symantec Identity Security Platform - IDSP (formerly VIP Authentication Hub) 

Cause

The locale framework in IDSP operates at the tenant level. As a result, when new locale keys are introduced in a new product release (such as expiry warning message keys introduced in 4.0.x), those keys must be present in every tenant's locale configuration to render correctly in the UI consoles. A missing locale key can cause UI elements — such as password or session expiry warnings — to display incorrectly or fall back to a raw key string.

Additionally, a defect present in IDSP 4.0.1 causes the expiry warning locale key to not be correctly resolved, which was addressed in the subsequent patch release.

Resolution

IDSP 4.0.2 includes the fix for the expiry warning locale key issue that is present in 4.0.1. Upgrading to 4.0.1 and then applying a subsequent patch introduces unnecessary operational complexity and risk. To ensure a complete, stable, and issue-free upgrade, administrators should target **4.0.2** directly from 3.4.6.

 

Locale Configuration Handling During Upgrade

Locale handling during the upgrade depends on whether the locale was shipped as part of the product (OOTB) or was created manually by an administrator.

Out-of-the-Box (OOTB) Locales

All five OOTB locales supported by IDSP are **automatically seeded** with any new locale content introduced in the target release during the upgrade process. No manual action is required for OOTB locales.

The five OOTB supported locales are seeded automatically on upgrade. For the full list of supported OOTB locales, refer to the [OOTB Supported Locales](https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/identity-security-platform/4-0.html) section in the IDSP 4.0 documentation.

Manually Created (Custom) Locales

Locales that were **created manually** by an administrator are **not automatically updated** during the upgrade. Any new locale keys introduced in IDSP 4.0.2 must be **manually added** to each custom locale after the upgrade completes.

**Action Required for Custom Locales:**

After upgrading to 4.0.2, administrators must:

1. Identify all tenants that use a custom (non-OOTB) locale configuration.

2. Review the new locale keys introduced in IDSP 4.0.2 (including, but not limited to, the expiry warning locale key).

3. Add the new locale key-value pairs to each affected custom locale via the IDSP administration console or the appropriate locale management API.

Failure to populate the new keys in custom locales will result in those locale entries falling back to their default values or displaying as unresolved key strings in the UI.