Captions written via MDL always land as en_US — breaks projects whose only/default language isn't en_US

[TOFBuck]

Title

Captions written via MDL always land as en_US — breaks projects whose only/default language isn't en_US

Body

Summary

Every MDL write path that sets a caption/title/label hardcodes the translation under en_US (confirmed in docs/11-proposals/PROPOSAL_translations.md, "75 hardcoded en_US sites"). On a project whose configured language is something else (e.g. nl_NL only, no en_US enabled), the caption is written to a language Studio Pro isn't displaying — so the widget shows the empty-caption placeholder (<>) plus a "no translation for this language" warning, even though mxcli/mx check/mxbuild all report success.

Steps to Reproduce

1. A project with a single configured language, nl_NL (no en_US enabled).
2. Create or alter any widget with a caption via MDL, e.g.:

   create or modify page MyModule.MyPage (
     ...
     button button1 (Caption: 'Opslaan')
     ...
   )
   

3. Open the page in Studio Pro.

Expected

The button caption shows "Opslaan" in the nl_NL client, no warning.

Actual

The button shows the empty-caption placeholder (<>) and Studio Pro warns that there is no translation for the project's language. mx check / mxbuild show 0 errors — nothing catches it.

Root cause (per the project's own proposal doc)

docs/11-proposals/PROPOSAL_translations.md already documents this precisely: there is no MDL syntax to author a translation for a specific language, so every writer (Title:, Caption:, Content:, Label:, etc.) re-emits the given string under a hardcoded "en_US" LanguageCode, regardless of the project's actual DefaultLanguageCode or enabled languages. Related: #702 (the read-side version of this — describe picking the wrong language — was fixed there; this issue is the write-side counterpart, which the #702 fix explicitly did not cover).

Environment

• mxcli: v0.18.0
• Mendix Studio Pro: (project language: nl_NL only, no en_US enabled)

Ask

At minimum, mx check/mxcli check should warn when a write lands under a LanguageCode the project doesn't have enabled — right now this is silent. Full fix is presumably what PROPOSAL_translations.md scopes (MDL syntax to author a translation in a given language, e.g. writing under the project's DefaultLanguageCode instead of a hardcoded en_US).

[ako]

Reproduced end to end on Mendix 11.12.0, with a fresh project set to nl_NL only (en_US removed, DefaultLanguageCode = 'nl_NL'), exactly as described.

The core claim is correct

mxcli created a page with a Dutch title, caption and dynamic text. Decoding the unit on disk:

unit $Type: Forms$Page | Name: TestPage
Texts$Text total: 6 | per-language markers: {'en_US': 3}
non-empty: [{'en_US': 'Opslaan'}, {'en_US': 'Hallo wereld'}, {'en_US': 'Testpagina'}]

Zero nl_NL markers. For contrast, the stock Atlas units in the same project carry {en_US: 'Save', nl_NL: 'Opslaan'} — Studio Pro writes both; mxcli writes one, under a language the project has disabled.

mx check reports 0 errors and 0 best-practice recommendations — including with CheckCompleteness: true set on nl_NL. And describe page round-trips perfectly, because the read side (the #702 fix in mdl/executor/describe_language.go) falls back to en_US. So the MDL loop is self-consistent and hides the defect.

Scope, measured on main: ~42 write sites across 18 files, in both engines — sdk/mpr/writer_widgets*.go, sdk/mpr/writer_navigation.go, mdl/backend/modelsdk/{widget,menu,navigation}_write.go, mdl/backend/widgetobj/builder.go, mdl/backend/pagemutator/mutator.go, modelsdk/mpr/nav_patch.go, and the executor page/entity/enum/validation-rule builders. There is no central Text constructor to fix in one place.

One claim in the report does not hold, and it changes the severity

The string does reach the built app. After mxbuild --target=deploy, both translations.properties and translations_nl_NL.properties carry Opslaan, Testpagina and Hallo wereld.

I ran the discriminating A/B — same project, same page, only the stored LanguageCode changed:

Text carries	Project enables	Emitted to translations_nl_NL.properties
en_US only	nl_NL only	the string
de_DE only	nl_NL only	empty value (string absent from all of deployment/)

So mxbuild has a hardwired en_US fallback — not a general "fall back to any available language". mxcli's hardcoded en_US is, by accident, the one wrong language that still renders at runtime. The blank-caption symptom is real, but it requires a text with no en_US entry.

That points to the <> being Studio Pro's editor display for a text with no translation in the selected language, rather than a broken build. I can't run Studio Pro in this environment, so I've left that half as reported-but-unverified — it's consistent with the model state either way. If you can confirm whether the deployed app actually renders the caption (as opposed to the Studio Pro editor showing <>), that would settle it.

The confirmed damage — arguably worse than the render symptom

mxcli's own translations feature cannot see the captions mxcli wrote. On the repro project:

$ mxcli -c "describe translations in MyFirstModule for de_DE"
create or modify translations in MyFirstModule for de_DE (
    'Tekst' as '',
);
-- 1 source string(s), 0 translated, 1 to go.

One string, and it's a stock Mendix one. Testpagina, Opslaan and Hallo wereld are invisible: translations.Collect keys on the project's source language (DefaultLanguageCode) and mdl/translations/apply.go:55 skips any text with no source-language entry. So an MDL-driven non-en_US project is untranslatable by mxcli itself. Studio Pro's Excel export has the same view of it — Opslaan is registered as the English source string.

What a fix has to work with

• The resolution already exists on the read side. describeDefaultLanguage(ctx) → Backend.GetProjectSettings().Language.DefaultLanguageCode, cached per run. The write path has no equivalent.
• The "at minimum, warn" ask is nearly free. unenabledLanguageWarning / languageIsEnabled already exist in mdl/executor/language_enablement.go, complete with the measured rationale. They have exactly one caller — create translations (cmd_translations.go:152). Nothing wires them into the caption write path.
• Threading is the real cost. Several of the 42 sites sit below the executor (sdk/mpr writers, mdl/backend/modelsdk) where there is no ExecContext, so the language must be resolved once and passed down.
• Migration hazard worth designing for. canon.CarryTranslations carries stored translations onto a rebuild. Once the writer switches to nl_NL, re-running an existing script yields {nl_NL: 'Opslaan', en_US: 'Opslaan'} — not lossy, but it churns every unit carrying a caption once and leaves a stale en_US duplicate behind.

Caveats

Measured only on 11.12.0. The en_US build fallback is undocumented behaviour inferred from the A/B above, not something Mendix promises — a fix should not depend on it continuing to exist.

[ako]

Reproduced and fixed. The report is accurate; the root cause turned out to be narrower — and therefore more fixable — than the "75 hardcoded sites" figure suggests.

Reproduction

Built an nl_NL-only project (alter settings LANGUAGE ADD 'nl_NL' → set default → REMOVE 'en_US'), created a page, and read the stored BSON:

/FormCall/…/CaptionTemplate/Template   [('en_US', 'Opslaan')]
/FormCall/…/Content/Template           [('en_US', 'Welkom')]
/Title                                 [('en_US', 'Opslaanpagina')]

mx check on that project: The app contains: 0 errors. — the silence you describe is confirmed. Which also means the check cannot be the oracle for this class; the assertion has to be on the stored LanguageCode.

The control came free from your configuration

Administration's own Studio Pro-authored pages, in the same project, store the same Dutch word correctly:

page	author	Opslaan stored under
Account_New, Account_Edit, MyAccount	Studio Pro	nl_NL
the mxcli-authored page	mxcli	en_US

So the model was never the problem — only the writer's choice of language. Both engines (modelsdk and legacy) behaved identically, which places the defect above the storage layer.

Root cause, and why it is smaller than 75 sites

Mendix has no language-neutral text — every Texts$Translation carries a LanguageCode — so a writer must pick one.

The read side already resolves the project's DefaultLanguageCode; that was #702's fix. The write side was simply never wired to it. So on a non-en_US project describe read one language while create wrote another, and describe → exec quietly stopped round-tripping.

Of the ~42 write sites, only about half matter:

• ~23 creation sites in mdl/executor are the bug. Every one could already reach the project's language (pageBuilder and flowBuilder carry the context; the exec functions take it directly).
• ~21 sites in the writer layers are fresh-envelope fallbacks. Measured: ALTER PAGE … SET Caption updates the stored translation in place and keeps its existing LanguageCode — over an en_US caption it stays en_US, over an nl_NL one it stays nl_NL. They inherit the creation-path mistake rather than making their own.

Fix

All ~23 creation sites now resolve the language from the project's DefaultLanguageCode, falling back to en_US only when settings are unavailable. Verified end to end on the nl_NL project: all texts store nl_NL, and mx check still reports 0 errors.

Two notes on the "at minimum, warn" ask. A warning is now largely unnecessary for this path, because DefaultLanguageCode is by definition one of the enabled languages — a write can no longer land in a disabled one. The separate case of deliberately authoring for a not-yet-enabled language (create translations for <code>) already warns, with the build behaviour measured: the string reaches nothing in deployment/.

The en_US case is unchanged, asserted as a regression control rather than assumed.

Scope

This covers creation. The writer-layer fallbacks remain for the narrow case where ALTER PAGE sets a caption on a widget that has none yet — tracked as a follow-up rather than swept in, since each needs a language threaded through a layer that has none today.

Worth correcting one pointer in the issue: PROPOSAL_translations.md's Slice 1 (a rewrite dropping other languages) already passes — a real rewrite preserved [en_US, nl_NL] on both engines in testing — so this was a standalone defect, not blocked behind that proposal.

The fix is on the fork (ako#299) and will reach this repo through the usual sync PR.