Move shared translations into Shared WebApp

[tjementum]

Centralize shared-webapp/ui translations into a single Lingui catalog

Summary & Motivation

Each self-contained system (account, main, back-office) used to extract translatable strings from both its own source AND application/shared-webapp/ui/**/*.{ts,tsx} into its own .po files. Every shared <Trans> ended up duplicated across three catalogs — a Danish translation for a shared <Trans>Save</Trans> had to be maintained in three places, and re-extractions across systems would drift out of sync.

This change gives shared-webapp/ui its own Lingui catalog and merges catalogs at runtime so each shared string is translated once.

• Add application/shared-webapp/ui/lingui.config.ts rooted at shared-webapp/ui/translations/locale/{locale} and scanning only shared-webapp/ui/**/*.{ts,tsx}.
• Add update-translations script to application/shared-webapp/ui/package.json.
• Strip the shared-webapp/ui glob from createLinguiConfig() so each system extracts only its own strings.
• Update createFederatedTranslation to dynamic-import the shared catalog alongside the host's own and merge messages with precedence shared < own < federated remote.
• Migrate 35 of 37 existing Danish translations from the old account/da-DK.po into the new shared da-DK.po. The remaining 2 strings (Loading, Open calendar) had no prior Danish translation.
• Re-extract each system's catalogs to drop now-orphaned shared entries.

Build pipeline fix

A long-standing turbo cache issue caused the frontend build to hit the cache and skip lingui extract, leaving .po files stale until manually invalidated. Wire update-translations as an uncached turbo task that build depends on, and remove update-translations from each WebApp's npm build script chain so turbo invokes it via the dep.

Federation context fix in PreviewAvatarMenu

The Language submenu under the avatar on the /components page rendered with zero items because use(translationContext) returned the default value (locales: []). Each federated module bundles its own copy of @repo/ui (where translationContext is defined via createContext), so the host's context provider does not propagate across the federation boundary. Read locales directly from i18n.config.json instead, matching the workaround already used in usePreferences.tsx. Locale changes still route correctly via the document-level locale-change-request event.

Documentation

Update .claude/rules/frontend/translations.md — items 6 and 7 reflect the split catalog architecture and the uncached update-translations task. All other items and examples are preserved verbatim.

Checklist

• I have added tests, or done manual regression tests
• I have updated the documentation, if necessary

[linear]

PP-1134 Centralize shared-webapp/ui translations into a single Lingui catalog

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud