Add i18n/localization infrastructure (starting with Spanish support)

[CamiloNietoOficial]

Problem

Buzz currently ships with UI strings hardcoded in English across all three frontend clients (desktop/ — Tauri + React, web/, and mobile/ — Flutter). There is no i18n/localization infrastructure in any of them:

• No i18next, react-intl, formatjs, lingui, or next-intl in package.json (root or desktop/)
• No Flutter intl package wired up in mobile/
• No locales/ or i18n/ directories in any client
• Text appears to be embedded directly in JSX/TSX components (desktop/web) and widget code (mobile)

This makes the app inaccessible to non-English-speaking users/teams, even though Buzz is meant to be a shared workspace for humans and agents across teams. A community member requested help changing the interface to Spanish, which surfaced that there's currently no path to do this at all — not even a partial one.

Proposal

Before writing any translation strings, agree on an approach for adding i18n infrastructure, scoped to one client first:

1. Pick a starting client — desktop (Tauri + React) is the primary UI most users interact with day-to-day, so it seems like the natural first target. Web and mobile would follow the same pattern once the approach is validated.
2. Pick a library — for the React/Tauri desktop client, react-i18next (or formatjs/react-intl) are the common choices. Happy to write up a short comparison if useful.
3. Extract strings incrementally — sweep desktop/src/features/ and desktop/src/shared/ to move hardcoded strings into a translation-key system, defaulting to en with no behavior change.
4. Add a language selector in settings, defaulting to system locale with an override.
5. Add a first non-English locale (e.g. es) as the initial proof that the pipeline works end-to-end.

This is a fairly invasive change (touches most UI files) so I wanted to check in before starting any implementation, per CONTRIBUTING.md's guidance to open an issue first for substantial work.

Questions for maintainers

• Is i18n already on the roadmap / being tracked elsewhere?
• Any preference on library or scope (e.g. desktop-only first vs. all three clients in parallel)?
• Would maintainers want string extraction done as one large PR or incrementally per-feature?

Happy to pick this up (starting with a proposal/RFC-style PR for the desktop client) once there's agreement on direction.

[paulovitin]

Hi @CamiloNietoOficial!

Thanks for bringing this up! I'd love to help bring Portuguese support to the platform as well. Beyond translating the strings, I'm available to help with the necessary code implementation and testing across the clients once the maintainers align on the i18n architecture.

Looking forward to seeing this move forward!

[stimiorasta]

Buzz looks really great. I agree that i18n is needed so that employees in my organization (France) can use it.

Do you plan to add i18n support? I’d be happy to help with the translation.

Thank you so much for your work!

[Aladincz]

Hi,
I would like to help with Czech localization but I am not real coder so I can translate when I get data then test how it fit in interface if someone will do implementation part.
I would like to bring to my community so it can start playing with it.

[HyperfocuSam]

We hit the same wall this week (Hong Kong team, Traditional Chinese needed) and have a working desktop implementation on a fork, offered here as a starting point or reference:

Branch: https://github.com/HyperfocuSam/buzz/tree/feat/desktop-i18n-language-setting (single commit, based on current main)

What it contains:

• react-i18next wired into desktop/ with en as default + fallback, plus zh-Hant / zh-Hans locale scaffolds
• A Language selector in Settings, persisted via the existing desktop settings mechanism
• A bounded first slice of extraction — 153 keys across the four highest-traffic surfaces (Settings 38, sidebar 45, composer/message actions 54, agents sidebar 16); everything else stays hardcoded and falls back to English, so untranslated surfaces keep working
• locales/STRINGS-MANIFEST.md — every key with its English source and one-line UI context, as a handoff for human translators
• Verification: tsc --noEmit clean, desktop test suite 3872 passed / 0 failed (includes a fallback test), biome clean

Two design choices worth debating here:

1. Empty locale values fall back to English (returnEmptyString: false). We deliberately ship the zh files with all 153 keys and empty values — machine-translated UI strings read poorly to native speakers, so translation quality stays a human decision per locale rather than a build artifact. A Spanish es.json would slot in the same way.
2. Incremental extraction over big-bang. Extracting all ~1,100+ component files at once makes an unreviewable PR; surface-by-surface keeps each PR reviewable and the app shippable at every step.

Happy to adapt the branch to whatever direction maintainers pick (different framework, different file layout, mobile/web strategy) and split it into reviewable PRs — treat the branch as evidence the incremental path works rather than a fait accompli.

[yoruhenry]

Hi, Korean user here. I’m planning to use Buzz daily as my agent workspace, and the lack of Korean localization would be a real adoption barrier for me.

I’d be happy to contribute the initial Korean (ko) translation and help review future localization updates for terminology consistency.

Before writing any code, I read through this issue, @HyperfocuSam’s feat/desktop-i18n-language-setting branch, and PR #3285. I’d prefer to coordinate with the existing work rather than create another separate implementation.

Could the maintainers clarify a few points?

1. Is desktop localization something the project is ready to accept now, or would you prefer to defer it while the UI is changing quickly?
2. Should future work build on the existing react-i18next branch, coordinate with PR feat(desktop): Raft theme + zh/en i18n #3285, or take a different approach?
3. Is there a preferred catalog format or translation key convention?
4. Would a small en + ko vertical slice be a useful first PR? My thought is to add the localization runtime, translate one small settings component, and include tests and screenshots. Keeping it to roughly ten files would make the architecture easier to review while still testing fallback behavior, Korean text rendering, and font fallback end to end.

I’m happy to follow whichever direction the maintainers prefer. If the existing react-i18next branch becomes the base, I’d be glad to test it in Korean and contribute the initial ko catalog.

[kk-ben]

Thanks for scoping this out, @CamiloNietoOficial — and thanks to
@HyperfocuSam for the concrete react-i18next branch, that's a strong
signal the approach works end-to-end (tsc clean, full test suite green,
biome clean).

To help unblock a maintainer decision, I did an independent measurement of
the current hardcoded-string scope across three high-traffic desktop
surfaces (settings/, sidebar/, messages/ under desktop/src/features/):
93 / 45 / 47 unique JSX text nodes + label/placeholder/title/aria-label
strings respectively (185 total across 89 files, ~17% of desktop's 520
.tsx files — .tsx only; roughly 1,180 files including .ts). That's
in the same order of magnitude as the 153 keys
@HyperfocuSam extracted from the equivalent four surfaces, which gives some
independent confirmation the incremental, surface-by-surface extraction
plan is the right shape (a single big-bang PR across all ~520 files would
not be reviewable).

A few things that would help move this forward:

1. +1 to @yoruhenry's still-open question about which base to build on —
   from our reading, @HyperfocuSam's react-i18next branch looks like the
   strongest candidate base. (PR feat(desktop): Raft theme + zh/en i18n #3285 also touches i18n but bundles it
   with an unrelated theme change, which per CONTRIBUTING.md's "drive-by
   changes" guidance would need to be split before it could be reviewed as
   an i18n PR anyway.)
2. If desktop-only-first is confirmed, is there a preference for which
   surface goes first — settings (largest string count, self-contained) vs.
   sidebar (highest visual exposure)?
3. We're independently interested in contributing a ja (Japanese) locale
   once the runtime/extraction pattern is settled, alongside the es
   originally proposed — happy to help validate CJK text rendering and
   font fallback as part of that, similar to what @yoruhenry offered for
   Korean.

Happy to help with the surface-by-surface extraction work once there's a
maintainer nod on which base branch/PR to build from — want to avoid
adding a fourth parallel implementation to the pile.

[VScommonBot]

+1 for this. We are piloting Buzz as a human+agent workspace for a Korean team (VentureSquare, Seoul), and the lack of localization is the first thing non-technical teammates notice — agent conversations work fine in Korean, but all app chrome (menus, empty states, onboarding, membership prompts) is English-only.

Once the i18n infrastructure lands, we would love to see Korean (ko) among the early locales, and we would be happy to contribute or review the Korean translation strings for the desktop client.

One note from our onboarding experience: the strings that matter most for non-English users are the first-run surfaces (relay/community switch dialog, "Not a member yet" invitation screen, and key backup prompts), since those are exactly the screens people hit before they can ask an agent for help.

[kk-ben]

Following up on point 3 in our comment above — the ja locale we mentioned is now ready. Built on top of @HyperfocuSam's feat/desktop-i18n-language-setting branch, we've added a complete ja.json (153 keys, matching the extracted key set 1:1) plus the corresponding APP_LANGUAGES registration in i18n.ts, following the exact same pattern used for the existing zh-Hant/zh-Hans entries. Key parity and i18next placeholder preservation ({{...}}) against en.json have been verified programmatically — no missing/extra keys, no placeholder mismatches. The branch is up at https://github.com/kk-ben/buzz/tree/feat/desktop-i18n-ja-locale (commit 394168d), DCO-signed, touching only those two files to keep it minimal and easy to review. We're holding off on opening a PR against block/buzz until a maintainer confirms the base branch/approach per the open questions above, but it's ready to go the moment that's settled.

[ianzencom]

Interested in contributing Spanish (es) once the i18n string-key system lands. Happy to own the es locale catalog and follow whatever library/base the maintainers choose.

[HyperfocuSam]

Heads-up for anyone who has built against my branch — the key set moved, so a re-sync is needed.

I've rebased onto current main (it was 145 commits behind) and opened the implementation as a PR: #5087. Branch: feat/desktop-i18n-language-setting-rebased. The original feat/desktop-i18n-language-setting is untouched, so nothing you already wrote is lost.

What changed in the key set, 153 → 140:

• composer.toolbar.attachImage → composer.toolbar.attachFile, value now "Attach file" (upstream renamed it in fix(desktop): rename generic attachment action from 'Attach image' to 'Attach file' (#2381) #4304)
• settings.nav.sections.channelTemplates value "Templates" → "Channel templates"
• agents.restartRequired removed — upstream deleted that badge
• 12 keys removed from sidebar.sections.* and composer.placeholder.*: AppSidebar.tsx and MessageComposer.tsx are at the repo's 1000-line file-size ratchet, so extraction can't add lines to them yet. Those strings fall back to English until those files are split.

@kk-ben — your ja.json needs those three renames and the 12 removals to keep 1:1 parity. Sorry for the churn.

Also worth reading: @setar has filed #5038 with a wider extraction (~560 keys, incl. onboarding) plus a Russian locale. I've suggested there that we land one runtime and stack the surface extractions and locale catalogues on top as separate small PRs, rather than have maintainers pick between two designs.