Conversation
Novitates
IN
Last activity: 8 Jan 2026 19:28 EST
From Fragmented Rules to Bundles: Localization Evolution in Pega 25
Introduction
While working with Pega Constellation Localization, I ran into an interesting issue in v24.2.1 that can easily confuse even experienced teams—especially during multi-language rollouts. This article captures what happens, why it happens, and how the problem is elegantly resolved in Pega Infinity 25.
What works as expected in 24.2.1
In v24.2.1, when you design views in Constellation and define:
- Field labels
- Helper texts
- Placeholder texts
- Field warning messages
Pega correctly generates view-context localization rules. When you run the Localization Wizard, language-specific localization rules are also generated without any errors.
So far, everything looks perfect.
The problem: Certain Localized content not visible on the UI
Despite the localization rules being generated correctly, the localized helper text, placeholder text, and warning messages do not appear on the UI.
This is where the underlying issue lies.
Root cause: Split localization storage
In v24.2.1, Pega creates the field label entry in the @baseclass.pyFieldLabels localization rule.
However, Pega expects all field-related content—including:
- Label
- Helper text
- Placeholder
- Warning messages
to exist within the same localization object.
The problem is:
- Field labels live in
pyFieldLabels(for e.g. @BASECLASS!LABEL!PYFIELDLABELS) - Helper/placeholder/warning texts live in view-specific localization rules (for e.g NT-PLAYGROUND-WORK-REQUEST!VIEW!REVIEW)
Because of this split, Constellation fails to resolve and render the localized content correctly at runtime.
Workaround (not ideal, but works)
If you’re already past development and need a fix in 24.2.1, there is a workaround:
- Before uploading the localization Excel file back into Pega:
- Update the Rule Key.
- Replace the view-specific localization rule key with the
pyFieldLabelsrule key for your missing entries.
- Zip and Upload the modified localization package to pega
This forces all related localization entries into the pyFieldLabels rule, allowing the UI to render localized content correctly.
What not to do ❌
You could technically:
- Make the
pyFieldLabelslocalization rule editable - Manually modify the JSON content
However, this is strongly discouraged:
- A small JSON syntax error can corrupt the rule
- Recovery is painful and risky
Avoid this approach in all cases.
The good news: Fixed cleanly in Pega Infinity 25 🎉
In v25, Pega resolves this problem at the root.
- All localized content (labels, helper text, placeholders, warnings) is stored in a single Localization Bundle rule.
- There’s no dependency on view-specific vs field-level localization.
- The UI resolves localization consistently and correctly.
Even better, if you need to update localization without rerunning the wizard, Pega 25 introduces Localization Configurations directly in the Application rule.
You can read more about it here: Exploring Localization Configurations in Application rule
Final takeaway
- Constellation 24.2.1 has a localization design gap that impacts helper, placeholder, and warning texts.
- A workaround exists but should be used carefully.
- Pega Infinity 25 fixes this holistically with Localization Bundles and Configurations.
If you’re planning a Constellation upgrade—or already on 25—this is one less thing to worry about 👍.
Also if you notice issues around Localization in constellation feel free to share your experiences in Expert circle.
Note: Shubham Garg bought up this issue to my notice in LinkedIn and hence we have this article floated around to everyone.
Happy Exploration!!!
Regards
JC