Aman-Mittal opened a new issue, #624:
URL: https://github.com/apache/fineract-backoffice-ui/issues/624
## Summary
A translation key that does not resolve renders as its own name —
`SAVINGS.CONFIRM_UNDO` where a sentence belongs — with nothing in the console
and nothing in CI. `scripts/check-translations.mjs` is meant to prevent this,
but it only sees a subset of how keys are actually referenced, and it cannot
see several ways a key goes wrong.
Three concrete defects, found while measuring the gap:
### 1. Three top-level sidebar groups are permanently English
`src/app/core/services/navigation-config.service.ts` has:
```ts
labelKey: 'Campaigns', // line 476
labelKey: 'Interop', // line 503
labelKey: 'Admin', // line 544
```
Every other entry holds a real key (`nav.spm`, `BATCH_OPERATIONS.TITLE`).
These three hold the English word. They render correctly in English and stay
English in Hindi and Korean, which is why no review or screenshot caught them.
`i18n:check` cannot catch them either: it verifies that keys *exist*, and a
bare word is not shaped like a key it would look up.
### 2. `i18n:check` is blind to the two most common reference forms
The `| translate` pattern in the script does not match `| appTranslate` —
the pipe ADR 0003 mandates — and there is no pattern for
`i18n.translate('KEY')`, the adapter method most application code calls.
Measured on `main`:
| Form | Uses | Checked before |
| ---- | ---- | -------------- |
| `'KEY' \| appTranslate` | 634 | no |
| `i18n.translate('KEY')` | 127 | no |
| `labelKey: 'KEY'` | 41 | no |
The script reported "1621 referenced keys" while ~800 references went
unexamined.
### 3. A stale key outlived its English counterpart
`hi.json` and `ko.json` both define `nav.clientSearchV2`, which `en.json`
does not. Nothing checks the non-English catalogues against the English one, so
a rename on the English side orphans its translations silently. (Related: `hi`
and `ko` each cover 469 of 2505 keys — that is expected and not a defect, but
nothing stops it going backwards.)
## What no static check can catch
Keys assembled at runtime, which exist in several places today:
```ts
this.i18n.translate(`SAVINGS.CONFIRM_${key}`)
this.i18n.translate(`GROUPS.CMD_${command.toUpperCase()}`)
```
A branch of one of these that has no key prints the key. Only the browser
knows.
## Proposal
Three static checks and one runtime one:
1. Teach `check-translations.mjs` the missing reference forms, and fail on a
key-shaped literal interpolated with no translate pipe.
2. Add a catalogue check: a non-English catalogue may not define a key
`en.json` dropped, and coverage may not regress (ratchet file, same idiom as
`scripts/nav-ids.json`).
3. Extend `check:nav-ids` to reject a `labelKey` that is not a translation
key.
4. Add a `MissingTranslationHandler` that logs unresolved keys in dev
builds, and an e2e fixture that fails any Playwright test producing one — the
only way to catch the runtime-assembled keys above.
Checks 1–3 cost no extra CI time (they run inside jobs that already exist).
Check 4 rides on the existing mocked suite.
None of these should be red on arrival: the three nav labels get real keys
and the stale catalogue key is removed as part of the change.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
