Skip to content

fix(l10n): translate the 36 untranslated manifest strings - #471

Merged
rubenvdlinde merged 2 commits into
developmentfrom
fix/manifest-l10n-coverage
Aug 27, 2026
Merged

fix(l10n): translate the 36 untranslated manifest strings#471
rubenvdlinde merged 2 commits into
developmentfrom
fix/manifest-l10n-coverage

Conversation

@rubenvdlinde

Copy link
Copy Markdown
Contributor

The manifest is data the renderer walks, not source the l10n extractor scans, so CnAppNav's menu[].label, the setup wizard and CnWalkthrough's step copy looked up keys that were never in the catalogue. A missing key falls back to the English source and nothing reports it, so a Dutch user reads English.

36 strings: the setup wizard, the whole pet-store tour, and the nav.

Product names stay untranslated, on purpose

"Pet Store" is the app the user is told to create BY NAME, and "Pet" is the schema they type. Translating either would make the instruction stop matching what they must actually enter.

So the prose around them is Dutch while the names are not:

"Noem die Pet Store" · "Voeg een schema toe met de naam Pet"

Same reasoning keeps Apps, App, Manifest, Exports and Agents, while translating the ones that genuinely have Dutch: Winkel, Manifestlagen, Geschiedenis, Rondleidingontwerper.

nl.json only

Adding the same keys to en.json is the obvious move and it is wrong in this fleet. check-l10n-parity.js is a ratchet over every required locale — the official language of every European country, plus Russian and Turkish — so one new English source key demands a real translation in ~30 languages. ConductionNL/keepiq#449 shows the failure mode.

Verification

manifest strings missing Dutch 0 (was 36)
test:l10n PASS

Two checks fail, both pre-existing and both failing identically on development:

  • check-l10n-parity+831 more missing across the required locales. This app's en.json holds 1,423 keys against nl.json's 1,009, and the other ~30 locales are further behind. Real debt, its own piece of work; this PR does not add to it, since it touches only nl.json.
  • check:manifest — the script crashes locally on the borrowed node_modules; it fails the same way on development.

The manifest is data the renderer walks, not source the l10n extractor scans,
so CnAppNav's `menu[].label`, the setup wizard and CnWalkthrough's step copy
looked up keys that were never in the catalogue. A missing key falls back to
the English source and nothing reports it, so a Dutch user reads English.

Thirty-six strings: the setup wizard, the whole pet-store tour, and the nav.

Product names stay untranslated on purpose. "Pet Store" is the app the user is
told to create BY NAME, and "Pet" is the schema they type, so translating
either would make the instruction not match what they must enter. The prose
around them is Dutch: "Noem die Pet Store", "Voeg een schema toe met de naam
Pet". Same reasoning keeps Apps, App, Manifest, Exports and Agents as they are,
and translates the ones that genuinely have Dutch: Winkel, Manifestlagen,
Geschiedenis, Rondleidingontwerper.

nl.json ONLY. Adding the same keys to en.json is the obvious move and it is
wrong in this fleet: check-l10n-parity.js is a ratchet over every required
locale (the official language of every European country, plus Russian and
Turkish), so one new English source key demands a real translation in about
thirty languages. keepiq#449 shows the failure mode — eleven new en.json keys
produced "+568 more missing" across the other locales.

Verified: 0 manifest strings missing Dutch.
Same omission as keepiq#449 on the same day: thirty-six keys added to
l10n/nl.json, l10n/nl.js never regenerated. nl.js was 1,009 keys against
nl.json's 1,045, which is exactly the additions sitting only in source.

The .json is source; the .js is what the runtime loads via OC.L10N.register. A
catalogue correct in JSON and stale in JS is a translation nobody receives, and
every check that reads the JSON calls it done. That is why `check:l10n-js`
exists, and it is what caught the keepiq case in CI.

Checked this by comparing key counts across all three of my open l10n branches
rather than waiting for CI to tell me twice.

Ran `l10n:build`; did not hand-edit the generated file.

Verified: l10n:build PASS, check:l10n-js PASS.
@github-actions

Copy link
Copy Markdown
Contributor

Quality Report — ConductionNL/buildiq @ d994ef9

Check PHP Vue Security License Tests
lint
phpcs
phpmd
psalm
phpstan
phpmetrics
eslint
stylelint
build
check-manifest
test-l10n
check-gitignore
check-nc-floor
format
check-l10n-js
check-schema-l10n
composer ✅ 106/106
npm ✅ 642/642
app:check-code ⏭️
info.xml
REUSE
PHPUnit
Newman
Playwright
Hydra gates

Quality workflow — 2026-08-26 22:25 UTC

Download the full PDF report from the workflow artifacts.

@github-actions

Copy link
Copy Markdown
Contributor

Quality Report — ConductionNL/buildiq @ d9370a1

Check PHP Vue Security License Tests
lint
phpcs
phpmd
psalm
phpstan
phpmetrics
eslint
stylelint
build
check-manifest
test-l10n
check-gitignore
check-nc-floor
format
check-l10n-js
check-schema-l10n
composer ✅ 106/106
npm ✅ 642/642
app:check-code ⏭️
info.xml
REUSE
PHPUnit
Newman
Playwright
Hydra gates

Quality workflow — 2026-08-27 00:17 UTC

Download the full PDF report from the workflow artifacts.

@rubenvdlinde
rubenvdlinde merged commit 1af2c46 into development Aug 27, 2026
87 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant