HubSpot will migrate content rendering from the legacy Java Runtime Environment (JRE) locale dataset to the Common Locale Data Repository (CLDR), the current industry standard for localization. Most content will remain unchanged, while some may see improved formatting accuracy.
What’s changing
All content rendered by HubSpot’s rendering services will transition from the legacy JRE locale dataset to CLDR. This impacts how locale-aware values including as dates, times, numbers, and currencies are formatted across:
- CMS pages
- Landing pages
- Blog posts
- Emails
This change enables more accurate and comprehensive localization aligned with modern internationalization standards.
Key formatting differences
CLDR introduces updated formatting rules that may result in subtle output differences:
- Non-breaking spaces (NBSP/NNBSP) may replace standard spaces in:
- Time formats (between the time value and AM/PM marker)
- Unit formats (between numeric values and unit labels)
- Cyrillic date formats (before the year marker “г”)
These characters often appear visually identical to regular spaces but behave differently in code.
For additional technical background, see the Java documentation on CLDR locale data
Potential impact to existing implementations
Most content will not be affected. However, issues may occur if your implementation relies on exact string matching or parsing of formatted values:
- Code that compares formatted strings expecting regular spaces may fail
- Parsing logic that assumes standard whitespace may break silently
The following HubL filters are most likely to be impacted due to locale-aware formatting:
- datetimeformat: most affected (AM/PM spacing and Cyrillic formats)
- Timeformat: AM/PM spacing changes
- Numberformat: unit spacing changes
Review your usage of these filters if your implementation depends on exact string output.
For more details, see the HubL filter reference.
What do I need to do?
All rendering services will undergo this migration automatically. Unless your setup relies on specific string formatting, no action is needed. If you utilize the filters mentioned earlier, we recommend verifying that your implementation aligns with the updated standard.
Additionally, this upgrade enables support for modern Java features and improves overall runtime performance and internationalization (I18n) capabilities.
When is it happening?
This change goes into effect on July 14, 2026.
Questions or comments? Join us in the developer forums.