Translations lets Creators enable multilingual support for a module. Component labels, placeholders, error messages, and other text display in an end-user's language at runtime. Module translations apply to component text only; workflow node labels and settings are translated separately in the Workflow Builder.
Access Translations by selecting Translations from the Definition drop-down in the Module Builder header.
9.0 behavior change: Beginning in the 9.0.0 release, translations are stored dynamically in the Locale module, not embedded in the module definition. This reduces module size and improves performance. Existing modules transition to the new behavior automatically the next time their translation table is saved. Customers currently using translations are being onboarded individually. Contact a Customer Experience representative for details.
Enable Translations
The Enable Translations toggle activates multilingual support for the module. When enabled, the platform applies translation strings at runtime based on the end-user's locale.
Translation Editor
When translations are enabled and languages are configured in the environment's Locale module, a translation table displays. Each column represents a language, and each row represents a translatable string from the module, like a component label, placeholder, or error message.
The source language (typically English) displays the original text. Enter translated text in the corresponding column for each additional language. Rows with no translation entered display the source language text at runtime.
Action | Description |
|---|---|
Enable Translations | When set to ON, this setting activates translation support for the module. End-users see translated text in Express when a matching locale is active. |
Add Locale | Opens a selector to add a new language locale column to the translation table. |
Export | Downloads all current translations as a file. |
Import | Uploads a CSV file to populate the translation table. |
Save Translations | Saves the current translation values to the Locale module. Saving translations does not a module save. |
Discard Changes | Reverts any unsaved changes to the translation table. |
Language Configuration
The languages available in the translation table are determined by the Locale module, a built-in module available in every Unqork environment. Each submission in the Locale module represents one language, identified by its ISO 639-1 code (for example, en, fr, fr-ca).
To add a new language to the translation table, create a submission for that language in the Locale module.
How Translations Are Stored
Note: This section applies to modules newly enabled for translations after the 9.0 release. It also applies to existing translation modules re-saved in the Unqork platform after upgrading. Modules with existing translations not yet re-saved still use the previous behavior. Translation data remains embedded in the module definition and is promoted with the module. Re-saving the translation table migrates them to the new storage format automatically.
Translation strings are stored as submissions in the Locale module, not embedded in the module definition. Each language submission contains a translations field that maps the module's component strings to their translated equivalents. When a Creator saves changes in the translation editor, the platform writes the translation data to the matching Locale module submission.
This separation keeps module definitions lightweight and lets translation data be managed independently from module configuration.
Migrating existing modules: Modules saved before this behavior change still carry their translation data inside the module definition. They migrate automatically. On the next save of the translation table, the platform writes translations to the Locale module and removes the embedded data from the module definition.
Shared translation keys: Translations are decoupled from module definitions and fetched dynamically. Updating a shared translation key in one module reflects across all modules that share that key immediately, with no manual save required for each module.
Promoting Translations
Before Dynamic Translation Loading, translation strings were embedded in the module definition. Promoting a module to a higher environment automatically carried its translations along. No separate step was needed. Dynamic Translation Loading stores translations separately in the Locale module, so they are no longer part of the module definition and must be promoted independently.
Note: This section applies to modules whose translation table has been saved at least once after Dynamic Translation Loading was enabled. If a module's translation table has not been re-saved since the feature was enabled, its translations are still embedded in the module definition and will promote automatically with the module. No separate step is required. Once the translation table is re-saved, the behavior described below applies.
Required step: Promoting a module does not include its translations. Translations must be promoted separately using the Promote Translations action in Settings. Skipping this step means the target environment uses outdated or missing translations for all modules.
Because translation data is stored separately from the module definition, promoting a module across environments does not include its translations. Workspace administrators must promote translations independently using the Promote Translations button in Settings → Environment Administration.
For example, to deploy a translated module from Staging to QA, complete the following:
Promote the module from Staging to QA using the standard promotions workflow.
Navigate to Settings > Environment > Environment Administration.
Select Promote Translations in the page header.
In the dialog, select QA as the target environment.
Select Promote, then confirm when prompted.
If translations are not promoted, end-users in the target environment see source language text for all fields regardless of locale. The Promote Translations action is available to workspace administrators only.
Passing the Locale at Runtime
Unqork does not detect an end-user's language automatically based on browser settings or region. The locale must be passed explicitly by the application when loading a module.
Method | How |
|---|---|
Module API call | Append |
Workflow execution | Pass the locale as an |
The locale is not detected automatically. Applications must include logic to capture the end-user's language preference and pass the locale when loading the module. Common approaches include a language selector component, a stored user preference, or browser language detection through a Plug-In component.
If an exact locale match is not found (for example, fr-ca), the platform falls back to the base language code (fr).
Changelog
Date | Change |
|---|---|
2026-08-11 | Added pre-migration caveat to Promoting Translations section — modules not yet re-saved still promote translations automatically with the module (EN-7993). |
2026-08-06 | Added pre-migration edge case callout for users with existing translations not yet re-saved in the new IDE (EN-7993). |
2026-08-04 | Updated for 9.0.0 dynamic translation loading (EN-7993): added 9.0 behavior change callout, migration note, shared key propagation, and prominent promotion warning. |
— | Initial publication. |