I’ve recently run into several challenges while localizing a corporate application in Infinity 24. In this post, I’d like to summarize the issues I’ve encountered and ask for general guidance on how to approach localization effectively
1. Based on Figure 1, is it required to import the Pega Language Pack for the target language as a prerequisite (step 0) before using Translate with GenAI?
2. How should we handle localization when multiple locales exist within the same language region?
For example, if we import the Spanish (es_ES) language pack, how should we support other Spanish locales used in the Americas such as es_MX (Mexico), es_US (U.S.), or es_XL (Latin America)?
3. Is the Localization wizard (Configure → User Interface → Application readiness → Localization) still useful for Constellation applications?
My understanding is that its main value now is creating a language pack for locales—such as es_XL—that are not included in the standard Traditional UI and Constellation Language Packs. Please correct me if I’m mistaken.
Figure 2 Application stack (1), New translation as seen in App Studio (2).
4. In Figure 2, when initiating a new translation, Pega often hangs if I select both “Re-translate all layers” and “Localize with GenAI” when running the process from the top-level application (AcmeClaimsDev).
Should we avoid re-translating all layers from the top and instead create translation packages individually at each layer?
5. In Figure 2, consider a component application below AcmeClaims—for example, AcmeCustomer—that defines an integration used to populate a drop-down list from a Data Page.
Should the localization for the Data Page’s field labels be handled within the AcmeCustomer component, or should it occur at the top application level?
Lastly, I’ve read recent articles about localization improvements in Infinity 25, which seem like a step forward and offer much clearer guidance. However, our application is currently on Infinity 24.2.3, so I’m hoping to apply best practices now that will also ease the transition when we eventually upgrade to Infinity 25.
Lot of questions in one post and truly everyone in the community also might have the same. Below are my responses as per my practical experience.
Any corrections or additional information/best practices/suggestions by community members on the below mentioned localization content is highly appreciated.
1. Is importing the Pega Language Pack mandatory before using Translate with GenAI?
Yes, in practice it should be treated as a prerequisite.
The Language Pack establishes the locale, base bundles, and fallback structure that GenAI translation builds on.
Primarily, pre-installed language pack would contain the general/standard labels for that specific language.
Without the language pack:
You may see incomplete translations
Missing UI tokens (OOTB labels, System messages)
Inconsistent fallback to en_US
GenAI is not a replacement for language packs in 24.x — it augments them.
Also, It has been noticed that GenAI sometimes does not generate all the translations for all fields. So manual translation entry is still expected in the excel.
Recommended guidance:
Import the appropriate Language Pack first.
Validate locale availability and fallback behaviour.
Then run Translate with GenAI for application-specific content.
2. Handling multiple locales within the same language (es_ES vs es_MX / es_US / es_XL)
From a Constellation perspective, localization behaves quite differently compared to the Traditional UI.
In Infinity 24.x, localization rules are generated based on context (such as views, cases, and UI components). As a result, even when working with the same language (for example, Spanish), Pega generates separate localization rules per locale. Any change to a specific locale therefore requires updating the corresponding localization rules, which are picked up at runtime based on the locale configured on the operator instance.
While it is technically possible to mark localization rules as editable and update them manually, this is not a recommended practice. These rules are JSON-based, and even a small formatting issue can corrupt the rule. The safer and supported approach is to always generate and update localized content using the Localization Wizard in App Studio.
Starting with Infinity 25, the localization model becomes much cleaner and easier to manage. Instead of multiple scattered rules, Pega introduces a single bundle-based approach:
Each language has one localization ruleset (for example, Converse_es)
Locale-specific bundles exist within that ruleset, such as:
Converse_es-ES
Converse_es-MX
Converse_es-US
To add or update locale-specific content:
Update the base bundle using localization configuration from your application.
Run the Localization Wizard in App Studio for the target locale.
Export and re-import the localization package.
The translated content is automatically placed into the correct locale-specific bundle.
From a runtime resolution standpoint, Pega always attempts to resolve localized content based on the exact locale set on the operator instance. For example, if the following bundles exist:
Converse_es-MX
Converse_es-ES
Converse_es-US
and the operator locale is set to just es, Pega will first look for an exact match. If no matching locale bundle is found, it falls back to the base language bundle(english).
Because of this behavior, it is important to configure the exact locale value on the operator when you want region-specific localization to take effect.
3. Is the Localization Wizard (Dev Studio) still useful for Constellation apps?
Localization in Pega is primarily applicable in 3 different areas
Portal content (Work portal, End User portal) – Views, Insights, etc
Localization wizard in Dev Studio focuses on generation of rules for 1 and #2, whereas,
Localization wizard in App studio focuses on 3 to generate of Constellation UI content (for Views, Dynamic Text, Data Pages, etc)
Localization wizard in Dev Studio can still be used for,
Creating new locales not shipped by Pega (e.g., es_XL) Generating initial translation rules and language metadata for backend rules (#2) and studio related content(1)
But for Constellation UI content, you have to depend on App Studio.
4. Hanging when using Re-translate all layers + Localize with GenAI at the top application
You’re not alone — this is a known operational pain point in 24.X and 25.x as well. Only GenAI option for some languages like Arabic will take at the least 10 min to generate the content for translation.
What’s happening
Re-translating all layers from the top app:
Triggers massive rule volume
Reprocesses rules that should not be retranslated
Overloads GenAI translation orchestration
The UI appears to hang or never completes
Best Practice : Do NOT re-translate all layers from the top application
Instead:
Translate each application layer independently
Framework
Component
Implementation
Only re-translate:
Changed rules
Rules owned by that layer
Treat translation as incremental, not monolithic
This approach:
Reduces latency issues/ unresponsive behaviour
Improves traceability
Matches Infinity’s layer-aware localization model
5. Localization ownership for Data Pages in component applications
This is an architectural ownership question, and the answer is very clear from a PSA standpoint.
Correct ownership model
Localize at the layer that owns the rule
In your example:
AcmeCustomer owns:
Integration
Data Page
Field labels / property references
Hence, Localization must happen in AcmeCustomer, not in AcmeClaims.
Why this matters
Keeps component applications:
Reusable
Portable
Consumer-agnostic
Prevents translation duplication
Avoids tight coupling between implementation and components
Implementation layer responsibility
Implementation apps may:
Override wording for business-specific context
Adjust labels for customer-facing nuance
But the base translation belongs in the component
This principle is explicitly reinforced in Infinity 25 documentation — so following it now will reduce refactoring later.
Important Links for Reference### Other important community post links on Localization in Constellation for your reference
Thanks for the feedback.
I have an additional question:
6. Is there a mismatch between the Spanish (Latin America) locale set in the browser and the locale configured in the Operator’s profile?
The Internationalization and Localization documentation mentions that the locale for Spanish (Latin America) is es‑XL. However, when you set your browser language to Spanish (Latin America), the resulting locale value appears to be different:
7. How can we configure localization fallback?
For example, suppose I upload a localization package for Spanish (Latin America), and a user in Mexico (whose locale is es‑MX) logs into our application. I want the system to still display the UI in Spanish, even if it’s not specifically tailored for Mexico.
Is it possible to define such a fallback behavior, or are we required to upload a separate localization package specifically for es‑MX?
On es-419 (vs) es-XL:
What you’re seeing is expected behavior. Browsers follow modern web standards and report Spanish (Latin America) as es-419, while Pega uses its own internal locale code and represents the same language as es-XL. They mean the same thing; the difference is just due to the standards being used on each side.
On fallback behavior:
Constellation doesn’t automatically fall back from a country-specific locale like es-MX to a regional one like es-XL. Localization works on exact locale matches. If there’s no match, it falls back to the application default or English.
If your goal is to show Spanish across Latin America, the usual approaches are:
Upload lightweight “alias” localization packages (for example es-MX) using the same translations as es-XL, or
Normalize the user’s locale to es-XL at login if regional formatting differences aren’t critical.
Creating new locales not shipped by Pega (e.g., 