Types of Localization
FormEngine supports two main types of localization:- Component Properties Localization - Localization of component properties such as labels, placeholders, tooltips, and other text properties.
- Validation Error Localization - Localization of validation error messages for form validation rules.
Localization in JSON Forms
Localization data is stored directly within the form JSON, making forms self-contained and easily distributable across different language environments.Basic Structure
A localized form includes three key properties:The localization Property
The localization property contains translations organized by language code and component. Each language code (likeen-US, de-DE) maps to an object containing translations for specific components:
Variables in Localized Strings
Localized strings can include variables that are replaced at runtime with actual values. Variables are enclosed in curly braces with a dollar sign prefix:{$variableName}.
Example:
{$userName} and {$messageCount} will be replaced with actual values provided to the component. This allows for dynamic
content within localized strings.
Variable names are case-sensitive and should match the property names available in the component’s data context.
The languages Property
The languages array defines which languages are available for the form. Each language includes:code: Language code (e.g., “en”)dialect: Regional dialect (e.g., “US”)name: Language name in its native scriptdescription: Language descriptionbidi: Text direction (“ltr” for left-to-right, “rtl” for right-to-left)
The defaultLanguage Property
The defaultLanguage property specifies which language should be used by default when the form loads. Must match one of the language codes in thelocalization object.
Localizing Component Properties
Component properties can be localized by setting computeType tolocalization in the property
definition. This tells FormEngine to look up the actual value from the localization data.
When a property has computeType set to localization, FormEngine will look up the actual value from the localization object based on
the component key and
current language:
label and helperText will be retrieved from:
localization["en-US"]["emailInput"]["component"]["label"](for English)localization["de-DE"]["emailInput"]["component"]["label"](for German)- etc.
Example: Basic Component Localization
Live example
live
Example: Multiple Components with Localization
Live example
live
Localizing Validation Errors
Validation error messages can also be localized. Each validator can have its error message specified in the localization data.Example: Validation Error Localization
The validator type in the localization object uses the format
validator-{validatorKey} (e.g., validator-email, validator-required).Live example
live
Validation error messages are not automatically translated when the language is changed, but they change after calling the validate
action.Localizing Tooltips and Modal Windows
FormEngine also supports localization of tooltips and modal windows, allowing you to provide translated help text and modal content for different languages.Tooltip Localization
Tooltips can be localized using thetooltip type in the localization object. Component tooltip properties are typically defined in the
tooltipProps section of a component.
Example: Tooltip Localization
The tooltip type in the localization object uses the format
tooltip (e.g., tooltip.title).Live example
live
Modal Window Localization
Modal windows can be localized using the modal type in the localization object. Modal content typically comes from templates defined in the form, and these templates can contain localized content.Example: Modal Window Localization
Below is an example of a simple dialog box for which localization will be applied:MyDialog.tsx
Live example
live
Setting Form Language
The form language can be controlled using thelanguage property on the FormViewer component. This property accepts a language code in
the format {code}-{dialect} (e.g., en-US, de-DE).
Example: React Component with Language Selection
showLineNumbers
Live example
live
Fallback Localization Mechanism
FormEngine provides a robust fallback mechanism to ensure users always see meaningful text even when translations are incomplete or missing.How Fallback Works
When a user requests a specific language (e.g.,fr-CA - Canadian French), FormEngine follows this fallback chain:
- Requested language exact match - Looks for exact translation in the requested language full code (e.g.,
fr-CA) - Requested language base match - Falls back to the base language code if the specific dialect is not found (e.g.,
frforfr-CA) - Form default language - Uses the form’s
defaultLanguagespecified in the JSON - Global default language - Falls back to the global default (
en-US) if form default is not available - [NOT LOCALIZED] helperText - Shows
[NOT LOCALIZED]for missing translations (not component key or property name)
This fallback mechanism applies to all localization types: component properties, validation errors, tooltips, and modal content.
Example: Fallback Chain in Action
Consider a form with these language definitions:fr-CA (Canadian French):
- FormEngine looks for
fr-CAtranslations - Not found - Falls back to
fr(French) - Finds"label": "Adresse Email"buthelperTextis missing - Falls back to form default
en-US- Uses"helperText": "Enter your email"for the missing translation - Result:
labelin French,helperTextin English
Live example
live
Best Practices for Fallback
- Always provide complete translations for your default language - This ensures a complete user experience even when other languages are incomplete
- Use base language translations for regional dialects - Provide
frtranslations that work for all French dialects (fr-FR,fr-CA,fr-BE, etc.) - Test with incomplete translations - Verify your form works correctly when some translations are missing
- Define all languages in the
languagesarray - Ensure every language used inlocalizationhas a corresponding entry in thelanguagesarray - Use consistent language codes - If you define
fr-FRinlanguages, usefr-FR(notfr) in thelocalizationobject keys
External Localization with localize Function
For more advanced scenarios where you need to load translations from external sources or integrate with existing translation systems, you can use the localize property on FormViewerProps.The ComponentLocalizer Type
Thelocalize property accepts a ComponentLocalizer function
with the following signature:
componentStore: Contains information about the component being localizedlanguage: The current language selected for the form- Returns: An object with localized property values for the component
Example: External Translation Service Integration
Live example
live
Best Practices
- Always provide a default language - Ensure your form has a sensible default language for users who don’t have a language preference set.
- Use descriptive component keys - Component keys like
emailFieldorsubmitButtonmake localization easier to manage than generic keys likeinput1orbutton2. - Keep localization data organized - Group related translations together and consider maintaining separate translation files for large forms.
- Test bidirectional text support - For RTL languages like Arabic or Hebrew, ensure your form layout handles text direction correctly.
- Consider text expansion - Some languages require more space for the same meaning. Design your forms with flexible layouts to accommodate longer text.
- Fallback strategy - Implement a fallback strategy for missing translations, either to a default language or to the component key itself.
Summary
FormEngine Core provides a robust localization system that supports:- Inline JSON localization for self-contained forms
- Component property localization for labels, placeholders, tooltips, and more
- Validation error localization for user-friendly error messages in multiple languages
- Language switching via the
languageproperty - External localization integration through the
localizefunction
For more information: