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 pyFieldLabels rule 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 :cross_mark:

You could technically:

  • Make the pyFieldLabels localization 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 :tada:

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 :+1:.

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

@JayachandraSiddipeta Thanks a lot for the explaination.

@JayachandraSiddipeta below article describes some known issues you may encounter when localizing constellation app in 25.1.1