translations

Translations

Every user-visible string of a Mendix app — page titles, widget captions, button labels, validation messages, enum captions, menu items — is a Texts$Text with one translation per language. MDL treats them in bulk: one file per language.

The loop

# 1. export: an untranslated string comes back with an EMPTY target
mxcli -p app.mpr -c "describe translations for de_DE" > de_DE.mdl

# 2. fill in the right-hand sides (by hand, or hand the file to an LLM)

# 3. write them back
mxcli exec de_DE.mdl -p app.mpr

That is the whole design: DESCRIBE emits the CREATE form, so the export format and the import format are the same file, and the empty targets are the prompt.

Statements

describe translations [in <Module>] for <lang>;

create translations            [in <Module>] for <lang> ( 'src' as 'target', ... );
create or modify translations  [in <Module>] for <lang> ( 'src' as 'target', ... );
create or replace translations [in <Module>] for <lang> ( 'src' as 'target', ... );

Entries use as, not a colon: a translation maps a user-provided name to another name.

verb	meaning
create	the "add a language" form — refuses if that language already has translations anywhere in scope
create or modify	merge; a source string the file does not name keeps whatever it has
create or replace	the file is authoritative — a translation whose source the file does not name is removed, and the run names what it deleted

IN <Module> scopes both directions, and under OR REPLACE it bounds the deletion — without it, a set of per-module files would wipe each other on every run.

The trap: a language that is not enabled

A translation for a language the project has not enabled is stored, passes mx check, and is discarded at build time. Measured with mxbuild --target=deploy: the string reaches nothing under deployment/ — no translations_<code>.properties is produced at all — while the model and Studio Pro both keep it happily.