Employee Center Portal Translation for HR Journeys

[Hardik10]

Hi @Alex Coope - SN ,

First, thank you for your post on enabling translation for the portal—it was incredibly helpful!

We’re currently facing a major localization challenge in the HRSD module, specifically with Journeys used for onboarding and employee lifecycle events. Here's the issue:

• We’ve enabled translation for Activity Sets and Activities using the dynamic translation and localization framework.
• However, when users access their Journey records in non-English languages via Employee Center Pro, everything still appears in English.
• The translations exist and are working in the backend, but they’re not reflected on the Employee Center UI.

Additionally, we’re struggling with translating HR Tasks within the Journey:

• These tasks originate from HR Core Task, and translating their short descriptions would mean duplicating translations.
• We’re unsure if it’s advisable to change the field type of description and short_description on the Task table to translated_text.

We also want to enable dynamic translation on-demand for fulfillers in modules like Incident and Request. This functionality is already enabled, but we’re unsure whether changing the field type to translated_text would impact dynamic translation. For these modules, we don’t want to store translated values in sys_translated_text, and we’re trying to understand the best approach.

We’ve opened a ServiceNow Case for this and attached a screenshot of the Journey detail page from Employee Center Pro for reference.

In summary:

• Localization framework works for Activity Sets and Activities, but translations are not visible on Employee Center.
• HR Task translation is unclear—especially regarding duplication and field type changes.
• Need guidance on dynamic translation for fulfillers without storing translations in sys_translated_text.

Any insights or suggestions would be greatly appreciated!
@barveaparna , @Madhu123 @swaghosh 

[Alex Coope - SN]

Hi @Hardik10,

So, the Journeys aspect is something we're looking at. We've started prototyping another artifact for - watch this space 🙂

- What's viewed in the Portal, are actually different records. What you've probably translated are the definitions of the activity sets, but not the journey's instance'd records associated to that journey to that user, if that makes sense?

In terms of your question about changing "short_description" from "string" to "translated_text" - don't do it. It's a field defined on the [task] table, it would have massive implications and potentially affect a lot of extended tables. DT also would no longer work on those fields, because it's only for "string" field types. You would need to store every task record's translations (for all your languages) in [sys_translated_text] which would be completely unnecessary. And the implication of not doing that would impact global search and indexing. Ergo, it's not recommended for "short_description" or "description" fields, as DT is the intended use-case here.

Enabling Dynamic Translation on the tables in question is the recommended option,

I hope this helps,

Also - for anything language related, it's best to raise it in our dedicated forum here - that way we see it faster,

Many thanks,
kind regards

[Hardik10]

Thank you @Alex Coope - SN , changing the field type was suggested by ServiceNow support on the opened case but as we were unsure, we asked here. Thank you for confirmation to not to change the field type. 🙂

Your comment on Journey's instance records make sense. 

[MaxMixali]

ServiceNow HRSD Localization & Dynamic Translation Guide

-------------------------------------------------
1. Overview
-------------------------------------------------
This document explains how to resolve localization issues in HRSD Journeys (Employee Center Pro), handle HR Task translations safely, and enable dynamic translation for fulfillers without storing data in sys_translated_text.

-------------------------------------------------
2. Translation Layers
-------------------------------------------------
Type | Mechanism | Storage | UI Behavior | Typical Use
-----|------------|----------|--------------|--------------
Static Localization | sys_translated_text | Database | Auto-displayed by user language | Field labels, static text
Dynamic Translation | API runtime (IBM/custom) | In-memory | Real-time translation | Comments, conversations
Dynamic Localization Framework | Runtime + caching | Optional | Dynamic localized content | HR Journeys, Campaigns

-------------------------------------------------
3. Why Journey Translations Fail in Employee Center
-------------------------------------------------
- Translations exist but UI does not show them.
- Employee Center Pro (Next Experience) components do not call localization APIs automatically.
- The HR Journeys API (hr_Lifecycle_Journey) returns base values without resolving translated_text fields.

-------------------------------------------------
4. Fixes for Journey Localization
-------------------------------------------------
Option A – UI Builder Widget Fix
- Use $sp.getMessage() or GlideLocalization.getMessage() in widget server scripts.
- Call /api/now/hr/localization endpoint from UI script for localized text.

Option B – Extend HR Journeys API (Preferred)
- Clone sn_hr_core.JourneyAPI.
- Override getJourneyData() to fetch translated fields using sn_hr_core.LocalizationUtil():
var loc = new sn_hr_core.LocalizationUtil();
var translated = loc.getLocalizedText('sn_hr_journey_activity_set', journey.activity_set.sys_id, 'title');
- Return localized values in API response.

Option C – Dynamic Client-Side Translation
- Use Dynamic Translator API client-side to translate visible DOM text (temporary fix).

-------------------------------------------------
5. HR Task Translation Best Practices
-------------------------------------------------
❌ Do not change field types (short_description, description) to translated_text.
- These fields are shared globally and dynamic translation won’t work on translated_text.
✅ Correct Approach:
1. Keep them as string fields.
2. Use GlideDynamicTranslation.getTranslation() or Flow Designer actions for runtime translation.
3. If static HR translations are required, use shadow fields (u_short_description_fr, etc.).
4. Avoid manual duplication; use translation memory or API automation.

-------------------------------------------------
6. Dynamic Translation for Fulfillers (Incident/Request)
-------------------------------------------------
Goal: Translate on demand, no persistence.
✅ Configuration:
- Keep fields as string.
- Enable plugin com.glide.dynamic_translation.
- Implement or extend your translation provider (IBM/custom).
- Use contextual menu or UI Action for “Translate to my language”.
- Translations remain transient and are not stored in sys_translated_text.

-------------------------------------------------
7. Architecture Summary
-------------------------------------------------
Layer | Data Source | Appears Where | Fix/Approach
------|--------------|---------------|--------------
Activity Sets & Activities | DLF Translations | Backend OK, UI fails | Patch Journey API/UI
HR Tasks | HR Task Table | Shared Modules | Keep string; dynamic translation
Fulfillers | Dynamic Translation | Runtime | Keep string fields

-------------------------------------------------
8. Recommended Long-Term Architecture
-------------------------------------------------
1. Keep translated_text fields for static content only.
2. Use dynamic translation for operational records.
3. Extend HR Journeys API to return localized content.
4. Use translation registry tables to avoid duplicates.
5. Never alter core schema; use translation wrappers.

-------------------------------------------------
9. Hybrid Translation Model
-------------------------------------------------
Object | Translation Type | Delivery Layer
--------|------------------|----------------
HR Activity/Set/Playbook | Static (translated_text) | Employee Center / Journeys
HR Task Short Description | Dynamic via API | HR Portal / Fulfillment
Knowledge Articles | Static (versioned) | Employee Center / Search
Agent Chat / Work Notes | Dynamic | Dynamic Translation plugin

-------------------------------------------------
10. Key Actions Summary
-------------------------------------------------
1. Do NOT change field types.
2. Extend Journey APIs to fetch localized text.
3. Use Dynamic Translation for fulfillers (no sys_translated_text storage).
4. Separate static vs dynamic translation paths.

-------------------------------------------------
11. Implementation Suggestion
-------------------------------------------------
Deliverables:
- API extension for localized Journeys
- Dynamic Translation fallback logic
- HR localization flow templates

-------------------------------------------------
12. TL;DR
-------------------------------------------------
- Backend localization works; UI requires explicit localization calls.
- HR Task fields remain string types.
- Dynamic Translation should stay runtime-only.
- Static + Dynamic translation layers should coexist separately.

[SwarnarghyaG]

Thanks for your response. You mentioned about a document. It would be helpful if you provide us the document which shows step by step guidance on how to set this up.