i18n: move UI translations to versioned DB ledger and complete 8-locale coverage

[seonghobae]

Buyer-visible gap

LineageWeave currently declares only en, ko, zh, ja, and vi in frontend/src/i18n.ts, and translation resources are compiled into the SPA source. The product contract requires KO/EN/JA/ZH/VI/ES/DE/FR and a database-distributed, versioned translation ledger with screen-key caching; ontology labels remain a separate semantic concern.

This is a LineageWeave presentation/read-model boundary. Do not copy ontology truth, locale management, or other CWL owners into this repository. If a released shared i18n owner becomes available, consume it through a versioned contract/ACL instead of duplicating it.

Required repair

1. Add es, de, and fr as first-class supported locales without treating English fallback as translated coverage.
2. Replace the SPA-bundled translation dictionary as the production source of truth with a normalized PostgreSQL translation ledger. Keep the client payload scoped by product/screen/key/locale/version and cache by immutable/versioned ledger identity so locale switching does not require shipping the full translation corpus in the JS bundle.
3. Preserve English source keys as stable message identities for the migration only if an ADR demonstrates collision/versioning safety; otherwise introduce an explicit stable message key and migrate callers without breaking existing accessibility names.
4. Keep ontology labels out of the translation ledger. Translation records are presentation resources, not semantic ontology truth.
5. Fail closed on missing required production translations for the eight supported locales in release/build evidence; development fallback must be explicit and observable, not silently counted as coverage.
6. Verify KO/EN/JA/ZH/VI/ES/DE/FR text expansion, CJK rendering/font fallback, normal/loading/empty/error/permission states, responsive layouts, keyboard/focus semantics, and screen-reader names for material UI.
7. Add migration/rollback, seed/version provenance, cache invalidation semantics, tenant/scope rules if applicable, API/read-model contract, and operational evidence. No cross-service SQL.
8. Update PRD/TRD/ARCHITECTURE/ADR/UX/OPERABILITY/TEST_STRATEGY and docs/product-technical-gap-baseline.md code-current with the chosen transaction/cache/version boundary.

RED acceptance

• A contract test must demonstrate that SUPPORTED_LOCALES is missing es, de, and fr on current code.
• A packaging/build assertion must demonstrate that production translation payloads currently live in the frontend source/bundle rather than a versioned database resource.
• An i18n completeness test must distinguish a real translation from English fallback and fail when any required screen key is missing in one of the eight supported locales.

GREEN acceptance

• SUPPORTED_LOCALES contains exactly the supported product locales KO/EN/JA/ZH/VI/ES/DE/FR (canonical locale tags documented).
• Production translations are read through the versioned DB-ledger/API boundary and screen-key cache; the frontend bundle is not the canonical translation store.
• Full current-head i18n/accessibility tests cover all eight locales and all material states; no untranslated fallback is counted as translated coverage.
• Migration rollback and immutable/versioned resource provenance are demonstrated on current head.
• No ontology-label conflation, raw cross-service SQL, or mutable sibling dependency is introduced.

Open material-UI lanes covered by this gate

At the 2026-09-03 live sweep, this release gate applies to open material UI work including #667 (Ask history), #679 (public-claim verification), #770 (project-history timeline), #774 (Operations Dashboard status), #802 (leftover-map explained-share presentation), #903 (Event Lineage), #907 (Affiliate Tree), #909 (Customer Master), and the #918 → #920 → #921 leftover-map composition stack. These PRs retain their own domain/test findings, but none may count five-locale SPA-bundled predecessor evidence as completion of this eight-locale DB-ledger requirement. Keep conflicts and unique deltas repairable; do not close them merely because this shared presentation prerequisite is unfinished.

[seonghobae]

Starting the RED/GREEN repair this cycle on a main-targeting branch (feat/i18n-translation-ledger-eight-locales, ADR 0357 / v2.31.0). Stacked leftover-map origin ADRs 0272–0356 stay on #921 and descendants; this increment does not mix into that stack. Canonical locales: en ko ja zh vi es de fr. Production translations persist to a versioned PostgreSQL ledger with screen-key cache identity; English source keys remain message identities only when they equal the en translated string. English fallback is not translated coverage for the other seven locales. Ontology labels stay out of the ledger.

[seonghobae]

Cycle 2026-09-03T05:01Z: writes work this cycle (comment/create-branch). Independent of leftover-map origin stack #912–#921 (ADR 0272–0356).

Implementing ADR 0357 / v2.31.0 on feat/i18n-translation-ledger-eight-locales (from main@0f1d447):

• 8 locales en/ko/ja/zh/vi/es/de/fr
• 3NF ledger ui_product / ui_screen / ui_locale / ui_message_key / ui_ledger_edition / ui_translated_string (migration 0246)
• cache identity {product}:{screen}:{locale}:{edition}
• English source keys as message identities; English fallback is not coverage
• ontology labels stay out of the ledger
• synthetic fixture lineageweave/fixtures/ui_translated_strings.json (edition 1)
• GET /api/ui-translations read model

Never invent a leftover score or a theta. No self-approve. Draft PR onto main after tests + push. Independent exact-head APPROVE required before squash-merge.

[seonghobae]

#929 now carries the #922 persistence/read-model foundation on exact protected base b0e94aa2a6f7a943f96dc5c4f2fdecd0021978a1.

Implemented under Draft:

• normalized versioned ui_translation_resource / ui_translation_key / ui_translation_text schema;
• persisted member-locale admission expanded to ko/en/ja/zh/vi/es/de/fr;
• published-resource immutability and complete key×8-locale publication gate;
• PostgreSQL-authoritative read model with exact product/screen/version/locale Valkey cache identity and fail-closed missing copy;
• publication/child-write serialization after a review-found race (370f83a... RED → bb61753... fix);
• Proposed ADR 0362 with BCP 47 / RFC 5646 traceability and non-destructive recovery semantics;
• edge coverage through current feat: establish versioned UI translation ledger foundation #929 head ba7af630b390c5edf33bc112bc624d56f28d0b09.

#922 stays open. Buyer-visible completion still requires FastAPI locale-request admission and frontend/src/i18n.ts to stop using the old five-locale/bundled-copy contract, actual screen-resource seeding/versioning, and current-head 8-locale normal/loading/empty/error/permission/responsive/a11y evidence. Current #929 checks are non-terminal, so no Ready/merge claim is being made.

[seonghobae]

#929 advanced the DB-ledger/read-model foundation, but #922 remains open. Review of predecessor ba7af630b390c5edf33bc112bc624d56f28d0b09 found that an exact-identity Valkey payload could contain only a subset of a published screen's required keys and still bypass PostgreSQL. RED 3b68e4ed16731e97e8743748ab5775fa78240064 captures the partial-cache case; repair 249b6cfba21c37899cae10ee7519d4e77132269d now resolves the published required-key set from PostgreSQL before accepting an explicit-version cache hit and requires exact key-set equality; verification-contract alignment is f666a5b12b9ddd0bbef040c238ef541ec1fa1af1. ADR 0362 is code-current at 7df347874ae26b95947be14b0cb97d7789b8d07a and remains Proposed. Buyer-visible completion is still gated on released foundation + API/frontend cutover, actual versioned screen resources, and eight-locale UI/a11y evidence.

[seonghobae]

#929 foundation progressed beyond the earlier cache repair. Current exact head 00896929ab67427c53f7809b533857e65ab20ca7 now also rejects padded PostgreSQL product/screen identities (RED d75d0a96... → repair d4d03da3...) and makes immutable publication provenance database-owned. A new real-PostgreSQL test path (d982d265...) applies migrations 0001 + 0044 + 0246 in a throwaway DB and verifies canonical identity, publication immutability/provenance, and eight-locale completeness. That runtime test exposed PostgreSQL now() as transaction-start time; RED 74f0521b... → repair e2429b14... now uses statement_timestamp() so a long transaction cannot backdate the publication receipt. ADR 0362 remains Proposed. #922 stays open: API/frontend cutover, versioned production screen resources, eight-locale material-state/a11y evidence, and the wider code-current product/technical docs are still outstanding.