From 99522540a53f6287e0025c2943057b0c95d687e7 Mon Sep 17 00:00:00 2001 From: Julien Gautier Date: Tue, 12 May 2026 00:30:27 +0200 Subject: [PATCH] =?UTF-8?q?feat(portal-shell):=20ci=20gate=20=E2=80=94=20f?= =?UTF-8?q?ail=20prod=20build=20on=20missing=20translations=20(#98)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ## Summary Set `"i18nMissingTranslation": "error"` on the production build configuration in [`apps/portal-shell/project.json`](apps/portal-shell/project.json). The Angular CLI checks every `` extracted from `i18n` markers and `$localize` calls against the loaded translation file (`messages.fr.xlf`); with the flag on `error`, the build now **fails** when a target is missing instead of silently falling back to the source text in the FR bundle. Closes the loop on ADR-0019 §"Confirmation" — the final piece of the i18n track that does not depend on the BFF route + cookie work (deferred to the auth-flow chantier). ## Gate mechanics - `pnpm ci:check` runs `nx affected -t ... build`, which uses the production configuration by default. A PR that adds an `i18n` marker without updating `messages.fr.xlf` fails its build job → merge blocked. - The default build configuration is unchanged (`production`), so no other CI plumbing is needed. ## Verification Locally, temporarily inserting an unmarked-in-fr string: ```html A string with no FR translation ``` then running `pnpm exec nx build portal-shell --configuration=production` produces: ``` ERROR: No translation found for "sanity.test.missingTranslation" ("A string with no FR translation"). Application bundle generation failed. NX Running target build for project portal-shell failed ``` …with a non-zero exit code. The patch was reverted before commit. ## Test plan - [x] `pnpm exec nx run-many -t lint test build --projects=portal-shell` — green (40 / 40 specs, build still passes on the current state). - [x] Sanity-check that the gate actually fires when a translation is missing (above). - [ ] CI: the next PR that adds an `i18n` marker without updating `messages.fr.xlf` should fail at the `build` step with the explicit error. ## What this PR explicitly does NOT do - Catch **unmarked** source strings (e.g. a developer who forgets to add `i18n="@@..."` to a new template line). That would need a custom ESLint rule against the Angular template AST — a separate, smaller scope mentioned in ADR-0019 as a future refinement. - Localise editorial / CMS content. Editorial copy comes from the BFF already localised; this gate covers only the developer-owned UI strings baked at build time. - Add a similar gate to the i18n extraction (we could fail the build if `nx extract-i18n` produces diffs against the committed `messages.xlf`, but we don't commit `messages.xlf` today). --------- Co-authored-by: Julien Gautier Reviewed-on: https://git.unespace.com/julien/apf_portal/pulls/98 --- apps/portal-shell/project.json | 1 + 1 file changed, 1 insertion(+) diff --git a/apps/portal-shell/project.json b/apps/portal-shell/project.json index 9868da0..70eab48 100644 --- a/apps/portal-shell/project.json +++ b/apps/portal-shell/project.json @@ -38,6 +38,7 @@ "configurations": { "production": { "localize": ["en", "fr"], + "i18nMissingTranslation": "error", "budgets": [ { "type": "initial",