fix(l10n): 27 Dutch strings that never reached the browser

[rubenvdlinde]

versioniq shipped l10n/nl.json and no l10n/nl.js. Nextcloud reads the .json server-side for PHP $l->t(); the browser only ever sees the OC.L10N.register() call in the .js. So all 27 Dutch translations were inert in the frontend.

Fourth and last instance of the same gap, measured across all 21 fleet apps on development: zaakafhandelapp (637 keys, #554), nextcloud-app-template (38 catalogues, #186), thematiq (209 keys, #493) and this one. Every other app already ships both halves.

One difference worth noting

The generator is petstore's build-l10n-js adopted unchanged except for its extension. This package.json declares "type": "module", so a CommonJS .js is loaded as ESM and dies on its first require():

ReferenceError: require is not defined in ES module scope

So the file is .cjs here. The other three apps do not set a type and keep .js. Worth knowing before this travels to any other repo.

Verification

• nl.js written with 27 keys; the register call names versioniq, read from appinfo/info.xml.
• The file parses under node --check and is 3,710 bytes rather than empty — an empty file passes node --check, so size was checked separately.
• check:l10n-js exits 0.

🤖 Generated with Claude Code

[rubenvdlinde]

Refining one line in the description, because the mechanism is worth stating precisely.

I wrote that the .js is "the only thing the browser ever sees". That is the generator script's wording and it is slightly too strong. What the code in these repos actually says:

• Apps do call loadTranslations('<app>', …), which fetches l10n/<locale>.json at runtime.
• But on many installs, including this fleet's standard dev container, Apache only lets the JS/CSS allowlist through and rewrites everything else to index.php. There is no route for /custom_apps/<app>/l10n/<locale>.json, so the fetch fails and loadTranslations rejects. src/main.js documents this and deliberately mounts anyway: "Strings just fall back to their English source on miss."
• l10n/<locale>.js is an OC.L10N.register() call loaded as a <script>, so it rides the allowlist and works where the JSON does not.

So the accurate claim is: the JSON path is real but unreliable, the .js path is the one that survives, and shipping only .json is what produces a Dutch account reading English. The fix in this PR is unchanged.

[github-actions]

Quality Report — ConductionNL/versioniq @ 6369e51

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
composer			✅	✅ 29/29
npm			✅	✅ 310/310
app:check-code	⏭️
info.xml	✅
REUSE	❌
PHPUnit					✅
Newman					⏭️
Playwright					🚨 NO VERDICT — enabled but never ran
Hydra gates					✅

---

Quality workflow — 2026-08-30 17:28 UTC

Download the full PDF report from the workflow artifacts.