Lotus-added UI bypasses the app's i18next mechanism entirely — always renders in English regardless of user locale #53

New Issue

2026-09-12T01:51:15-04:00

jared commented

2026-09-12 01:51:15 -04:00

Severity: medium · Type: ux · Confidence: high

Location: representative sample — none of src/app/features/lotus/*, src/app/components/seasonal/*, src/app/components/avatar-decoration/*, src/app/components/presence/*, src/app/components/soundboard-pack-view/*, src/app/features/call/CallSoundboard.tsx, src/app/features/toast/LotusToastContainer.tsx, src/app/pages/client/sidebar/SettingsTab.tsx (PresencePicker), or src/app/features/shortcuts/KeyboardShortcutsDialog.tsx import useTranslation/react-i18next (0 of ~56 files checked); src/app/i18n.ts confirms the app uses i18next-browser-languagedetector to auto-select the UI language from the browser locale, and public/locales/{en,de}.json shows the mechanism is real (used in 11 files total, e.g. src/app/components/message/Reply.tsx, src/app/components/DeviceVerification.tsx).

Problem

Every Lotus-added feature hard-codes its user-facing strings ("Set Status", "Soundboard", "No Decoration", every shortcut description, every toast/label) as plain JSX text rather than t('key'). Because the app auto-detects and applies the browser's language (LanguageDetector), a user with a German (or any non-English) browser locale gets a genuinely mixed-language UI: the handful of upstream strings that still route through en.json/de.json translate, while all Lotus surfaces — which are a large fraction of the app's newer, most-visible chrome (presence, calls, soundboard, decorations, seasonal settings, keyboard shortcuts help) — stay in English unconditionally. This is a single systemic gap rather than N per-string findings.

How to trigger

Set the browser's language to de (or add another public/locales/<lng>.json), open the app — core translated strings switch language while every Lotus feature panel does not.

Suggested fix

Either explicitly scope Lotus Chat to English-only (drop i18next-browser-languagedetector/remove the now-misleading partial de.json coverage so the experience is consistently English), or route new Lotus strings through the same useTranslation()/public/locales pipeline used by the 11 already-localized files.

Filed from the September 2026 client audit (branch lotus @ 4bea4895).

**Severity:** medium · **Type:** ux · **Confidence:** high **Location:** representative sample — none of `src/app/features/lotus/*`, `src/app/components/seasonal/*`, `src/app/components/avatar-decoration/*`, `src/app/components/presence/*`, `src/app/components/soundboard-pack-view/*`, `src/app/features/call/CallSoundboard.tsx`, `src/app/features/toast/LotusToastContainer.tsx`, `src/app/pages/client/sidebar/SettingsTab.tsx` (PresencePicker), or `src/app/features/shortcuts/KeyboardShortcutsDialog.tsx` import `useTranslation`/`react-i18next` (0 of ~56 files checked); `src/app/i18n.ts` confirms the app uses `i18next-browser-languagedetector` to auto-select the UI language from the browser locale, and `public/locales/{en,de}.json` shows the mechanism is real (used in 11 files total, e.g. `src/app/components/message/Reply.tsx`, `src/app/components/DeviceVerification.tsx`). ### Problem Every Lotus-added feature hard-codes its user-facing strings ("Set Status", "Soundboard", "No Decoration", every shortcut description, every toast/label) as plain JSX text rather than `t('key')`. Because the app auto-detects and applies the browser's language (`LanguageDetector`), a user with a German (or any non-English) browser locale gets a genuinely mixed-language UI: the handful of upstream strings that still route through `en.json`/`de.json` translate, while all Lotus surfaces — which are a large fraction of the app's newer, most-visible chrome (presence, calls, soundboard, decorations, seasonal settings, keyboard shortcuts help) — stay in English unconditionally. This is a single systemic gap rather than N per-string findings. ### How to trigger Set the browser's language to `de` (or add another `public/locales/<lng>.json`), open the app — core translated strings switch language while every Lotus feature panel does not. ### Suggested fix Either explicitly scope Lotus Chat to English-only (drop `i18next-browser-languagedetector`/remove the now-misleading partial `de.json` coverage so the experience is consistently English), or route new Lotus strings through the same `useTranslation()`/`public/locales` pipeline used by the 11 already-localized files. --- _Filed from the September 2026 client audit (branch `lotus` @ 4bea4895)._

jared added this to the Audit 2026-09 · Medium & Low milestone 2026-09-12 01:51:15 -04:00

jared added the priority: medium ux area: settings labels 2026-09-12 01:51:15 -04:00

jared self-assigned this 2026-09-12 01:51:15 -04:00

jared referenced this issue

2026-09-12 01:52:08 -04:00

Client audit 2026-09 — tracking index #89

jared referenced this issue from a commit

2026-09-13 00:56:42 -04:00

fix(i18n): English-only until Lotus strings are localized

jared closed this issue

2026-09-13 00:56:42 -04:00

jared referenced this issue from a commit