How do you translate a Mendix app into multiple languages while keeping the language chosen by the developer separate from the language seen by each end user? This Mendix multilingual app guide explains Studio Pro language settings, the default dictionary, Batch Translate, Batch Replace, missing-translation checks, user language settings and realistic deployment QA. It is written for teams building applications for readers and customers around the world.
Mendix’s current Studio Pro documentation describes a Language Settings area, translatable captions and interface messages, a default language, a language editor, batch operations and completeness checks. The application also uses its user-language model and device or browser preferences when appropriate. These are useful tools for translating an interface, but they do not mean that every row of business data, uploaded document or external notification is automatically rendered in a different language.
The most useful test is an entire task rather than an isolated translation key. Imagine a person opening a form in Spanish, making a selection, receiving a validation error, submitting a request and later signing in on another device. The words should help that person understand the same facts, permissions, status and next actions throughout. This chapter separates platform features from application choices, then explains how to review the result.
Quick answer
In Mendix Studio Pro, select a supported default language and add the target languages using Language Settings. Translate interface strings in the appropriate dictionaries and use Batch Translate or related operations where they improve consistency. Distinguish Studio Pro’s current editing language from each end user’s runtime language. Enable completeness checking, validate fallback behavior, and separately design multilingual business data, email templates and regional formatting.
Before you begin: a practical checklist
- Verify the exact Mendix and Studio Pro version in use.
- Identify the source language and all supported target locales.
- List translatable interface strings, including microflow messages and validation.
- Confirm the meaning of the default-language fallback.
- Separate the editing dictionary from the end user’s language association.
- Use batch operations carefully, with context and terminology review.
- Test missing translations and the configured completeness warnings.
- Verify business data, access rights, formats and external messages separately.
Why this platform needs its own translation plan
Mendix has an important distinction that beginners can miss: a developer’s selected working language determines which translation dictionary they edit, while a running user’s language is chosen by application preferences and runtime rules. A product can be beautifully translated in the editor yet remain confusing to an anonymous visitor or a signed-in user whose account language differs from their device. Translation needs to be verified as a complete application experience.
1. Understand where Mendix stores translatable text
Mendix documents interface captions, grid labels, menu items, text and microflow messages as translatable resources. They live in language dictionaries associated with the application rather than being translated by changing every visible component independently.
A practical example
A library reservation app contains a Reserve button, a calendar heading, grid-column labels and a warning sent by a microflow. All four communicate important meaning but may be entered in different places in the project.
The common mistake is this: A team translates a page title and calls the screen complete, forgetting action messages and rules that appear only after submission.
A reliable way to handle it: Create a resource inventory by user journey and determine whether each visible string is controlled by a Mendix dictionary, database record or outside service.
Evidence to inspect: Trigger each action to confirm the correct language is shown, not merely that the editor displays a translated caption.
A useful translation review follows the meaning of an action all the way into system state. The important question is not whether a label has a counterpart in another language. It is whether the person understands the same choices, conditions and consequences in both versions.
2. Choose a default app language before expanding
Mendix’s Language Settings documentation says each app must have a default language; it is used when a user language is unsupported or when a target-language string is missing. For a new blank app, the current guide commonly starts from English (United States).
A practical example
A city services portal supports English and Vietnamese. A visitor with a device set to Swedish needs an intelligible fallback without falsely implying that Swedish is supported.
The common mistake is this: Treating the default as an unimportant internal value can make entire forms unexpectedly appear in the wrong language.
A reliable way to handle it: Choose a deliberate fallback with the audience in mind and correct unclear source phrases before producing several versions.
Evidence to inspect: Test a language that is completely unsupported and one that is supported but has a deliberately missing low-risk string.
A screen can look finished while the journey remains unfinished. Check the step before and after the translated element, including the results of invalid input and a return visit. Language quality becomes visible when the application must explain what happened.
3. Add target languages in the correct settings
The modern Mendix documentation describes using Language > Language Settings in Studio Pro to select additional supported languages. It also notes that the list of available locales can depend on the Studio Pro version.
A practical example
A team plans a regional rollout across Brazil and Portugal and needs to know whether its chosen locale variants are supported, not just whether generic Portuguese appears in an online example.
The common mistake is this: Selecting the wrong locale may produce unsuitable wording, formatting or later confusion about the intended market.
A reliable way to handle it: Confirm target-language options in the actual project and record precise language-region choices before translators start.
Evidence to inspect: Inspect the configured language list, intended audience and default choice together, rather than checking only a translated screen.
Stable records and stable permissions are essential. The user’s language may change the explanation of an invoice, order or request, but it should not silently create a new invoice, modify the amount or alter access rights. Check the backend outcome, not only presentation.
4. Do not confuse current editing language with user language
Studio Pro lets the developer change the current language while working on translatable text. That setting chooses which dictionary is being edited, not necessarily the language every running user sees.
A practical example
A developer selects French at the bottom-right language selector to revise a button caption, then mistakenly expects all customers to receive French immediately.
The common mistake is this: This misunderstanding can lead to false launch claims and source-language changes accidentally written into the target dictionary.
A reliable way to handle it: Maintain a clear development convention for which dictionary to edit. Test runtime behavior with actual accounts and anonymous sessions.
Evidence to inspect: A reader in each supported locale sees the intended screen even when the last developer editing session used another language.
Avoid inferring production behavior from an editor preview or a translation percentage. A real release may include cached client state, messages from another module or an unexpected error path. Evidence must come from running the actual workflow and checking the server result.
5. Understand missing translation indicators
Mendix documentation describes untranslated target-language strings appearing in the editor with default text inside angle brackets. That visual clue is a request for attention, not a finished translation.
A practical example
A French form shows a default-language label such as an untranslated Name caption while the rest of the page has French labels.
The common mistake is this: A mixed-language screen may be acceptable as a transparent fallback in a low-risk case but misleading if it involves consent, payment or safety.
A reliable way to handle it: Use indicators to locate gaps, then resolve critical terms with review rather than blindly accepting the default copy.
Evidence to inspect: Run the page in the target locale and confirm high-impact actions and warnings have accurate target-language wording.
Translation is an ongoing maintenance duty. Every new widget, validation rule and business state introduces potential new language. Put language review into ordinary product change management so that one careful release does not decay into inconsistent experiences.
6. Use Batch Translate with context awareness
Mendix provides Batch Translate for working across multiple occurrences of translatable text. It can accelerate repeated interface labels such as Save, Cancel and Delete, but identical English words can carry different meanings.
A practical example
An account panel includes ‘Save settings’, while a report page uses ‘Save as file’. The words look similar in English but may require different constructions.
The common mistake is this: A careless batch update can spread one incorrect term across many different contexts, increasing the correction work.
A reliable way to handle it: Review occurrences and scope to the relevant modules where useful; record terminology decisions before applying changes across the app.
Evidence to inspect: Inspect different uses after the batch operation and verify they still communicate the proper action.
A reasonable fallback is honest, not invisible at any cost. An understandable default is better than an empty interface, but a high-risk statement must not be misrepresented as translated or approved when it is not. Record limitations where they affect decisions.
7. Use Batch Replace as an editorial operation
The documentation presents Batch Replace for changing matching strings in the selected language dictionary. It is a maintenance tool, not a substitute for understanding business meaning.
A practical example
The company changes its preferred terminology from ‘case’ to ‘request’ in customer-facing status screens, but the legal case-management module still needs the original term.
The common mistake is this: An indiscriminate replace changes conceptually distinct statements and undermines consistency across modules.
A reliable way to handle it: Scope the operation carefully, examine occurrence lists and approve high-risk wording with domain owners before applying it.
Evidence to inspect: Compare affected screens and confirm the new term is appropriate in each context, including error messages.
A useful translation review follows the meaning of an action all the way into system state. The important question is not whether a label has a counterpart in another language. It is whether the person understands the same choices, conditions and consequences in both versions.
8. Copy related language variants without treating them as identical
Mendix Language Operations can help copy translated text between related dictionaries. That is useful as a starting point for regional variations, not a promise that every expression is acceptable in both markets.
A practical example
An application has a complete Portuguese translation for Portugal and is preparing a Portuguese variant for Brazil.
The common mistake is this: Copied terms for invoices, addresses, legal requirements or everyday services may be misleading because the regions differ.
A reliable way to handle it: Copy only as a draft, then review market-specific vocabulary, formats, policies and data with readers in the target locale.
Evidence to inspect: A regional reviewer can complete the same tasks without encountering imported terms that imply the wrong service or requirement.
A screen can look finished while the journey remains unfinished. Check the step before and after the translated element, including the results of invalid input and a return visit. Language quality becomes visible when the application must explain what happened.
9. Enable completeness checks thoughtfully
Mendix’s current Language Settings reference explains that the Check completeness option can flag missing dictionary entries in the Errors pane; the default language’s completeness check is always required.
A practical example
A release manager wants to know which target-language strings are incomplete before inviting a pilot group.
The common mistake is this: Without a check, new widgets and warnings may slip into an otherwise translated app after an ordinary feature update.
A reliable way to handle it: Use completeness reports as a release gate and pair them with task-based review. Note that a filled entry can still be wrong.
Evidence to inspect: Run the selected language through build checks and manually inspect critical flows for semantic correctness.
Stable records and stable permissions are essential. The user’s language may change the explanation of an invoice, order or request, but it should not silently create a new invoice, modify the amount or alter access rights. Check the backend outcome, not only presentation.
10. Watch inherited and preinstalled language resources
Mendix documentation notes that some templates and libraries may include English and Dutch translations. Their presence does not necessarily mean they are the chosen business language variants.
A practical example
A project created from a template includes more dictionary entries than the team planned to publish, leading reviewers to assume support exists for an unused locale.
The common mistake is this: Unreviewed default phrases and sample messages can surface to users or confuse translation-maintenance work.
A reliable way to handle it: Audit actual supported languages and remove or revise unused resources only within the new app’s authorized scope, without destabilizing required defaults.
Evidence to inspect: Check the running app and resource lists to ensure every advertised language is intentionally supported.
Avoid inferring production behavior from an editor preview or a translation percentage. A real release may include cached client state, messages from another module or an unexpected error path. Evidence must come from running the actual workflow and checking the server result.
11. Distinguish the anonymous visitor’s language from account language
Mendix’s reference guide explains that the runtime language can come from a user association and, for users without an associated language, browser or operating-system preferences. Unsupported requests fall back to the default.
A practical example
A multilingual public portal displays a first-visit screen in the browser’s preferred language, then the visitor signs in under an account with another language preference.
The common mistake is this: A jarring unannounced language shift can make an account look unfamiliar and discourage a sensitive transaction.
A reliable way to handle it: Decide and explain the policy for anonymous and authenticated users. Test first visit, sign-in, profile changes, logout and return.
Evidence to inspect: The active language is predictable and a user can recover from an unexpected choice without losing their task.
Translation is an ongoing maintenance duty. Every new widget, validation rule and business state introduces potential new language. Put language review into ordinary product change management so that one careful release does not decay into inconsistent experiences.
12. Understand the User_Language association
Mendix’s user-language model associates a User with a Language, which can determine what that person sees after authentication. A developer’s current editing dictionary does not override that relationship.
A practical example
An employee changes their preferred language in a profile and expects project dashboards to follow them when they return on another computer.
The common mistake is this: A preference saved only in one local screen may not update the authenticated account behavior across sessions.
A reliable way to handle it: Use the application’s supported user-language mechanism and ensure permission checks guard any preference updates appropriately.
Evidence to inspect: Verify that the correct account retains its preferred language and that another account’s settings remain independent.
A reasonable fallback is honest, not invisible at any cost. An understandable default is better than an empty interface, but a high-risk statement must not be misrepresented as translated or approved when it is not. Record limitations where they affect decisions.
13. Translate validation and microflow messages
Microflows can deliver human-facing text, and validation errors often carry more operational meaning than ordinary labels. They should be covered by the translation inventory and tested with real invalid inputs.
A practical example
A supplier tries to submit an invoice without a required tax identifier; the field label is translated but the rejection explains the requirement only in English.
The common mistake is this: A user cannot correct a mistake if the error leaves out the actual problem or appears in an unfamiliar language.
A reliable way to handle it: Review important system messages in the appropriate dictionary and map structured error outcomes to clear recovery steps.
Evidence to inspect: Cause the same validation failure in both languages and check that the two messages demand the same correction.
A useful translation review follows the meaning of an action all the way into system state. The important question is not whether a label has a counterpart in another language. It is whether the person understands the same choices, conditions and consequences in both versions.
14. Keep dynamic business data separate from interface dictionaries
Translatable UI text and records stored in domain models are different problems. A product description or a user-entered note does not automatically change language just because a Mendix page label does.
A practical example
An inventory app shows a Spanish screen while a product’s description is still stored as a single English attribute.
The common mistake is this: Claiming the complete product is multilingual based on dictionary coverage misleads both customers and content editors.
A reliable way to handle it: Create a deliberate translated-data model or approved content service for records that need language variants; retain stable IDs and provenance.
Evidence to inspect: Compare one record across locales and verify the same stock, price and identity with accurate language-specific descriptions.
A screen can look finished while the journey remains unfinished. Check the step before and after the translated element, including the results of invalid input and a return visit. Language quality becomes visible when the application must explain what happened.
15. Do not change stored status codes when translating
A localized status label such as Pending or Approved should reflect a stable internal code or enumeration. Business logic should continue to operate on the structured value, not on words seen by the user.
A practical example
A workflow stores REQUEST_APPROVED and displays the equivalent phrase in Chinese to a customer.
The common mistake is this: If the translated phrase is saved back as the status, downstream filters and reporting may fail or create new unintended states.
A reliable way to handle it: Keep internal state stable, map it to reviewed labels and test the actual workflow transitions after changing user language.
Evidence to inspect: A record maintains the same status and authorized actions regardless of the display locale.
Stable records and stable permissions are essential. The user’s language may change the explanation of an invoice, order or request, but it should not silently create a new invoice, modify the amount or alter access rights. Check the backend outcome, not only presentation.
16. Choose formats deliberately, not by visual guess
Mendix Language Settings allows custom date and time formats for language variants. Formatting should serve local readers without changing the actual instant, amount or unit of measurement.
A practical example
A booking is for 5 April at 14:30, but a numeric date string appears in different orders for customers in two countries.
The common mistake is this: A fluent localized label next to an ambiguous date can still cause the person to arrive on the wrong day.
A reliable way to handle it: Configure appropriate formats and include explicit time-zone or currency information where necessary. Check example values in the actual app.
Evidence to inspect: People in both regions can identify the same appointment timestamp and any financial obligation.
Avoid inferring production behavior from an editor preview or a translation percentage. A real release may include cached client state, messages from another module or an unexpected error path. Evidence must come from running the actual workflow and checking the server result.
17. Treat personalization and privacy as independent
An application may translate a customer’s address labels, account settings and notification preferences, but their private data remains subject to the same authorization controls.
A practical example
A staff member changes interface language while viewing a confidential procurement record.
The common mistake is this: A flaw that ties a data filter to locale rather than account permissions can leak records or hide legitimate data.
A reliable way to handle it: Enforce access checks at the server and test different accounts and language preferences independently.
Evidence to inspect: Forbidden records stay forbidden, and visible records remain attached to the correct owner across locale changes.
Translation is an ongoing maintenance duty. Every new widget, validation rule and business state introduces potential new language. Put language review into ordinary product change management so that one careful release does not decay into inconsistent experiences.
18. Review long strings and responsive layouts
Translated captions can become substantially longer than the default-language version. Grid headings, menu items and button captions need room to expand and still work on small devices.
A practical example
A German submit button wraps into an unreadable column on a mobile screen, hiding the action behind another control.
The common mistake is this: A dictionary can be complete while the interface is inaccessible in practice.
A reliable way to handle it: Test representative longest strings and enlarged text on relevant devices. Review focus order and actual tap targets.
Evidence to inspect: Users can read and activate every essential control without clipping, confusion or accidental selection.
A reasonable fallback is honest, not invisible at any cost. An understandable default is better than an empty interface, but a high-risk statement must not be misrepresented as translated or approved when it is not. Record limitations where they affect decisions.
19. Do not ignore accessibility text
Screen-reader names, instructions and alternative text are also part of the user experience. The visible word may be translated while the accessible description remains in the default language.
A practical example
A screen-reader user hears an English action name on a page whose visible headings are in Arabic.
The common mistake is this: A visual-only review misses important barriers for readers with different accessibility needs.
A reliable way to handle it: Inventory accessible labels and test actual keyboard, screen-reader and focus behavior in each supported locale.
Evidence to inspect: A nonvisual user can complete the same task and recognize error recovery steps in the selected language.
A useful translation review follows the meaning of an action all the way into system state. The important question is not whether a label has a counterpart in another language. It is whether the person understands the same choices, conditions and consequences in both versions.
20. Review external and uploaded content separately
An uploaded PDF, an API response, a support email or a shared document may originate outside Mendix language dictionaries. These materials require their own translation and governance if the user journey relies on them.
A practical example
A portal’s form is translated, but the download supplied after submission explains eligibility only in English.
The common mistake is this: An apparently finished localized journey can fail at the most consequential information handoff.
A reliable way to handle it: Inventory linked documents and generated messages, assign owners and show clear language availability information to readers.
Evidence to inspect: The person receives consistent, accurate guidance across the app and the external artifact.
A screen can look finished while the journey remains unfinished. Check the step before and after the translated element, including the results of invalid input and a return visit. Language quality becomes visible when the application must explain what happened.
21. Audit the complete journey after each release
Adding a new module, changing a widget or altering business logic may introduce strings that were never included in earlier translation work. Completeness warnings help but cannot judge whether translated claims remain true.
A practical example
A new approval step adds an intermediate status between Requested and Approved. Old translations still say ‘finished’ after the first step.
The common mistake is this: The application can misreport its true state even though its translation dictionaries contain no blank cells.
A reliable way to handle it: Revisit state transitions, critical forms and the acceptance matrix whenever functionality changes. Include in-language user review, not just build success.
Evidence to inspect: The text accurately represents what the application currently does, including newly introduced states.
Stable records and stable permissions are essential. The user’s language may change the explanation of an invoice, order or request, but it should not silently create a new invoice, modify the amount or alter access rights. Check the backend outcome, not only presentation.
Hands-on acceptance tests for teams
1. The developer-language versus runtime-language test
Set Studio Pro’s current editing language to French, but log into the running application as a user whose preferred language is Spanish.
Inspect the distinction between authoring dictionaries and end-user language association. Compare the running page to the stored user preference.
The intended result is specific: The account sees Spanish where supported regardless of the developer’s current editing language.
Repeat this exercise on a clean account and a returning account. Use the same business record, one source language and one target language; keep a record of the locale, app version, action, actual result and where the observed behavior differs.
2. The unknown browser language
Open the public application without signing in from a browser using a preference the project does not support.
Review default-language configuration and important error states. Verify the app remains coherent and the supported-language choices are discoverable.
The intended result is specific: The anonymous visitor receives an understandable default, not raw dictionary placeholders.
Run the same test with incomplete or invalid input. Compare the language shown in an error, the state held by the app, and the authoritative server record. A fluent success notice is not evidence of success unless the server agrees.
3. A Batch Translate ambiguity
Find two uses of ‘Close’—one for closing a modal and one for closing a customer case.
Review the occurrences and translate each concept with its context. Ask reviewers to use both actions and predict the outcomes.
The intended result is specific: Both actions retain the correct meaning rather than sharing a misleading literal translation.
Repeat this exercise on a clean account and a returning account. Use the same business record, one source language and one target language; keep a record of the locale, app version, action, actual result and where the observed behavior differs.
4. Completeness warning and real meaning
Intentionally leave a low-risk caption untranslated in a test branch, enable completeness checks and inspect the Errors pane.
Correct the missing entry, then separately examine an existing but incorrect target-language label to demonstrate why completeness is not quality.
The intended result is specific: Missing resources are identified and incorrect meanings are caught through review.
Run the same test with incomplete or invalid input. Compare the language shown in an error, the state held by the app, and the authoritative server record. A fluent success notice is not evidence of success unless the server agrees.
5. Account language after sign-in
Visit the public site in one language, then authenticate as a user whose stored language differs.
Trace when and why the UI changes and ensure the account record does not change without an authorized user action.
The intended result is specific: The transition is understandable and the person’s other saved data is preserved.
Repeat this exercise on a clean account and a returning account. Use the same business record, one source language and one target language; keep a record of the locale, app version, action, actual result and where the observed behavior differs.
6. A translated status without state changes
Create a request with a stable internal Pending status and display it in two language variants.
Compare backend values, search filters and workflow actions before and after switching language. Try advancing the status while viewing the translated label.
The intended result is specific: The same business state is represented accurately and transitions obey identical rules.
Run the same test with incomplete or invalid input. Compare the language shown in an error, the state held by the app, and the authoritative server record. A fluent success notice is not evidence of success unless the server agrees.
7. A localized date format
Display one timestamp to two users with different language-region settings.
Configure the intended format and time-zone presentation, then ask each tester to restate the absolute date and time.
The intended result is specific: Both readers identify the same moment rather than an ambiguous numeric date.
Repeat this exercise on a clean account and a returning account. Use the same business record, one source language and one target language; keep a record of the locale, app version, action, actual result and where the observed behavior differs.
8. A mobile layout with long labels
Open a translated form on a narrow device and enlarge system text.
Check navigation, validation and button focus order while completing a real task. Look for truncated captions and hidden instructions.
The intended result is specific: The task remains operable for readers using longer text and accessibility settings.
Run the same test with incomplete or invalid input. Compare the language shown in an error, the state held by the app, and the authoritative server record. A fluent success notice is not evidence of success unless the server agrees.
9. A post-update regression
Add a new page, microflow message and menu item after the initial translations have been approved.
Run dictionary completeness checks and a complete target-language transaction path. Include the new intermediate state in the review.
The intended result is specific: The new release has no misleading or inaccessible language gaps on essential flows.
Repeat this exercise on a clean account and a returning account. Use the same business record, one source language and one target language; keep a record of the locale, app version, action, actual result and where the observed behavior differs.
A four-week rollout readers can follow
Week 1: Map the application
Identify the project’s version, authoritative default, supported locales, UI messages, dynamic records, external documents and intended user populations. Trace one complete request from arrival to result.
Confirm who controls dictionaries, who owns account language preferences and which data belongs to another service.
Week 2: Translate and configure
Set languages in Studio Pro, review source strings, populate target dictionaries and use Batch Translate for repeated, unambiguous resources. Configure completeness warnings and decide how account or browser preferences determine display.
Build a pilot journey with a form, invalid input, submission and confirmed status rather than a demo screen alone.
Week 3: Review hard cases
Test language-region formatting, user associations, missing entries, microflow messages, dynamic records, privacy and authorization. Ask readers in each supported language to describe what the action means before they perform it.
Inspect narrow screens and accessibility tools, particularly after any translated label or screen layout changes.
Week 4: Release and maintain
Recheck dictionary coverage and the application behavior after every meaningful feature change. Preserve a record of the verified locale, user, version, test action and backend state.
Keep ownership clear for new strings, newly uploaded documents and translated content that comes from outside the app.
Frequently asked questions
Where do I add languages in Mendix?
The current Studio Pro guide describes Language > Language Settings. Check your version’s available language list and select a deliberate default.
What is the default language for?
It supplies a fallback for unsupported user-language choices and for missing translated strings, as documented by Mendix.
Does changing the editor language change every user’s app?
No. The current editing language chooses the dictionary being edited. Runtime language depends on the application’s supported languages and user or device preferences.
What does Batch Translate do?
It helps translate many resource occurrences at once. Review contextual meaning before applying one wording to different actions.
What does a completeness check prove?
It can reveal missing entries. It does not prove that a filled entry preserves the right meaning, state or business promise.
Can I copy translations between related locales?
Mendix includes language operations that can help. Copying is a starting point for local review, not proof that two regional variants are equivalent.
Do ordinary database records translate automatically?
Not merely because a UI dictionary exists. Plan localized fields or data services if business records require language variants.
How is a signed-in user’s language chosen?
Mendix documents association between User and Language; inspect the specific app’s configuration and test account behavior.
Can translation change permissions?
It should not. Server-side access rules and record ownership must remain stable across languages.
What confirms a good launch?
An independent reader can complete real tasks in the target language and the visible outcomes match the authoritative system.
The standard worth aiming for
A well-localized Mendix app distinguishes three things clearly: the developer’s language dictionary, the user’s actual reading language and the backend’s authoritative state. When those are governed separately and tested together, the user can move through forms, decisions, errors and follow-up messages confidently without caring which internal component supplied the text.