Motivation
Buzz Desktop currently ships with English-only UI strings. Non-English speakers (e.g. Chinese-speaking teams running Buzz as an internal hive-mind platform) hit a language wall on day one: onboarding ("Create a new identity key"), Settings panels, channel/thread controls, notifications, and agent-status surfaces are all hardcoded English.
I hit this deploying Buzz 0.5.23 on Linux for a Chinese-speaking user: the app works great (WebGL rendering, STT models, relay connectivity all fine), but every UI string is English. This limits adoption in mixed-language teams and for non-technical colleagues who would otherwise be able to use Buzz as their daily communication hub.
Searching the codebase, desktop UI strings appear hardcoded in components (e.g. settingsSections labels in desktop/src/features/settings/ui/SettingsPanels.tsx), with no i18n framework present.
Proposed solution
Introduce an i18n layer in the desktop (React) app:
- Adopt a standard i18n framework — e.g.
react-i18next / i18next or lingui — and extract hardcoded UI strings into message catalogs (en as source of truth).
- Language selector in Settings → Appearance — persisted per user (localStorage is already used for app state), defaulting to the OS locale.
- Ship zh-CN as the first community translation — Chinese is likely the largest non-English audience; a
zh-CN.json catalog would get the app usable for a large group immediately.
- Keep strings in one place per feature module so catalog updates stay low-churn as the UI iterates (0.5.x ships fast).
Alternatives considered
- Hardcoded per-language forks — unmaintainable; desktop resources are bundled into the binary, so every release needs a rebuild.
- Browser-level / system-level translation (e.g. translate shell overlays) — not viable inside WebKitGTK, and machine translation of a trust-sensitive comms tool is poor UX.
- Upstreaming later, starting with a community patch — possible, but without an i18n framework in place there's nothing to hang translations on.
Additional context
- Verified in v0.5.23 deb build on Linux: no
Language section in Settings, no i18n framework (i18next / lingui / react-intl) referenced in the desktop bundle.
- Prior art: Tauri + React apps commonly use
react-i18next; Electron/Tauri comms apps (e.g. Element) ship full i18n with community catalogs via Weblate/Transifex.
- Duplicate check: none found (searched open/closed issues for i18n / translation / language).
Motivation
Buzz Desktop currently ships with English-only UI strings. Non-English speakers (e.g. Chinese-speaking teams running Buzz as an internal hive-mind platform) hit a language wall on day one: onboarding ("Create a new identity key"), Settings panels, channel/thread controls, notifications, and agent-status surfaces are all hardcoded English.
I hit this deploying Buzz 0.5.23 on Linux for a Chinese-speaking user: the app works great (WebGL rendering, STT models, relay connectivity all fine), but every UI string is English. This limits adoption in mixed-language teams and for non-technical colleagues who would otherwise be able to use Buzz as their daily communication hub.
Searching the codebase, desktop UI strings appear hardcoded in components (e.g.
settingsSectionslabels indesktop/src/features/settings/ui/SettingsPanels.tsx), with no i18n framework present.Proposed solution
Introduce an i18n layer in the desktop (React) app:
react-i18next/i18nextorlingui— and extract hardcoded UI strings into message catalogs (en as source of truth).zh-CN.jsoncatalog would get the app usable for a large group immediately.Alternatives considered
Additional context
Languagesection in Settings, no i18n framework (i18next / lingui / react-intl) referenced in the desktop bundle.react-i18next; Electron/Tauri comms apps (e.g. Element) ship full i18n with community catalogs via Weblate/Transifex.