Seam request: ScopedTranslocoLoader needs a 'shared' scope path #59

New issue

Closed

opened 2026-09-11 11:04:17 +00:00 by patrick · 0 comments

patrick commented

2026-09-11 11:04:17 +00:00

Owner

Found while working #13 (PH1.5 — web shared UI)

frontend/src/app/core/i18n/transloco-loader.ts (ScopedTranslocoLoader, owned by PH0.5/feature/web-skeleton, not by PH1.5's owned paths) resolves a Transloco scope to an asset path like this:

const assetPath =
  !scope || scope === 'shell'
    ? `core/i18n/${lang}.json`
    : `features/${scope}/i18n/${lang}.json`;

docs/12-implementation-plan.md's "Frontend decoupling rules" says: "shared/ has one scope for common strings". PH1.5 created that scope's files at frontend/src/app/shared/i18n/{en,nl}.json (angular.json's asset glob **/i18n/*.json under src/app already copies them to the build output at /shared/i18n/<lang>.json). But the loader above only special-cases shell; any other scope name — including shared — is assumed to live under features/<scope>/i18n/.... So provideTranslocoScope('shared') would 404 at /features/shared/i18n/en.json instead of resolving to /shared/i18n/en.json.

This doesn't block #13 itself (nothing wires shared/ui/shared/admin-crud components into an actual routed page yet — no feature has adopted them), but it will block the first feature ticket that mounts a shared/ui/shared/admin-crud component and needs its shared.* strings (e.g. shared.actions.save, shared.adminCrud.addNew) to actually translate at runtime.

Suggested fix

const assetPath =
  !scope || scope === 'shell'
    ? `core/i18n/${lang}.json`
    : scope === 'shared'
      ? `shared/i18n/${lang}.json`
      : `features/${scope}/i18n/${lang}.json`;

One line, in a file PH1.5 isn't allowed to touch (core/i18n/**). Whichever feature ticket first depends on shared/i18n strings resolving at runtime should either make this fix as part of its own PR or should be blocked on a small dedicated PR that does.

Owns

frontend/src/app/core/i18n/transloco-loader.ts only (plus its existing spec, if one needs updating).

## Found while working #13 (PH1.5 — web shared UI) `frontend/src/app/core/i18n/transloco-loader.ts` (`ScopedTranslocoLoader`, owned by PH0.5/`feature/web-skeleton`, not by PH1.5's owned paths) resolves a Transloco scope to an asset path like this: ```ts const assetPath = !scope || scope === 'shell' ? `core/i18n/${lang}.json` : `features/${scope}/i18n/${lang}.json`; ``` docs/12-implementation-plan.md's "Frontend decoupling rules" says: *"shared/ has one scope for common strings"*. PH1.5 created that scope's files at `frontend/src/app/shared/i18n/{en,nl}.json` (angular.json's asset glob `**/i18n/*.json` under `src/app` already copies them to the build output at `/shared/i18n/<lang>.json`). But the loader above only special-cases `shell`; any other scope name — including `shared` — is assumed to live under `features/<scope>/i18n/...`. So `provideTranslocoScope('shared')` would 404 at `/features/shared/i18n/en.json` instead of resolving to `/shared/i18n/en.json`. This doesn't block #13 itself (nothing wires `shared/ui`/`shared/admin-crud` components into an actual routed page yet — no feature has adopted them), but it will block the *first* feature ticket that mounts a `shared/ui`/`shared/admin-crud` component and needs its `shared.*` strings (e.g. `shared.actions.save`, `shared.adminCrud.addNew`) to actually translate at runtime. ## Suggested fix ```ts const assetPath = !scope || scope === 'shell' ? `core/i18n/${lang}.json` : scope === 'shared' ? `shared/i18n/${lang}.json` : `features/${scope}/i18n/${lang}.json`; ``` One line, in a file PH1.5 isn't allowed to touch (`core/i18n/**`). Whichever feature ticket first depends on `shared/i18n` strings resolving at runtime should either make this fix as part of its own PR or should be blocked on a small dedicated PR that does. ## Owns `frontend/src/app/core/i18n/transloco-loader.ts` only (plus its existing spec, if one needs updating).

patrick referenced this issue from a commit

2026-09-11 11:04:58 +00:00

feat(web): shared UI wrappers, pipes, stores and store-slice pattern

patrick referenced this issue

2026-09-11 11:05:18 +00:00

feat(web): shared UI wrappers, pipes, stores and store-slice pattern #60