Five-commit i18n cleanup: ~90 new keys, namespace fixes, locale cookie fallback
After a next-intl v4 scaffold landed ~112 keys per language, five follow-up commits over roughly 36 hours worked through the bugs it left behind. The most reusable fix addresses a real quirk in `localePrefix: 'never'` mode that anyone using next-intl v4 with that setting will hit.
The first two commits (1f2a7f6, b4c96d3) are coverage work: ~80 keys in the first pass across placeholders, aria-labels, button text, alerts, and status labels, then ~11 more in a second pass for inline text nodes a regex sweep missed (AssistantMessage, TRChatPanel, breadcrumbs, empty states). Straightforward but product-specific.
Commit c33fac9 is the one worth keeping. With localePrefix: 'never', getRequestConfig in next-intl v4 doesn't reliably receive the locale from requestLocale. The fix reads the NEXT_LOCALE cookie directly as a fallback in frontend/i18n.ts - ten lines, and also unfreezes the <html lang> attribute, which had been hardcoded to "de".
Commits 198ab24 and 0d6cd6a show what happens when regex-driven translation rewrites go wrong. The sweep changed useTranslations('common') to useTranslations() across 35 components, dropping the common. prefix from key references. That broke keys that actually live in the common namespace. The follow-up commit restores the prefix for those keys - but introduces a new bug: user?.email?.split("common.@")[0] (the regex replaced the literal string "@" inside a split call). Worth studying as a cautionary example of why regex-driven i18n sweeps need thorough review.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?