[Feature]: Minimal multi-locale i18n foundation, with zh-CN as the first locale #6789

I want to acknowledge that this issue may reasonably be considered a duplicate of #1463. I previously left a follow-up comment there to ask whether a small, community-led implementation would be welcome, but I did not receive a response. For that reason, I decided to open this more narrowly scoped issue in the hope of receiving clear guidance before investing time in the implementation.

I sincerely apologize if opening a separate issue is not the preferred approach. If the maintainers would rather continue the discussion in #1463, I completely understand and would be happy for this issue to be closed.

"Minimal i18n foundation" is the right framing, the foundation decides whether language two costs a weekend or a quarter.
I built i1n (i1n.ai), which might collapse a chunk of this: strings live in plain locale JSONs, i1n push --translate AI-translates missing keys (zh-CN included) with product context, typed key definitions so typos fail at compile time, and i1n check keeps community-contributed languages in parity in CI. Contributors then review translations instead of bootstrapping them. Free tier, npx i1n init. Is the plan to build the foundation in-house or are you evaluating existing tooling?

Adding a strong +1 from the Chinese developer & builder community.

Following Julius’s note in #16888 consolidating this discussion, I wanted to echo why this is so critical right now:

1. The Vibe Coding Wave: "Vibe coding" and agent-first development have exploded across China over the past several months. Creators, indie hackers, PMs, and junior engineers are all adopting agent workflows, and T3 Code is widely recognized as one of the best agent harnesses available.
2. Reducing Everyday Cognitive Friction: Non-native English speakers often hesitate when evaluating agent permissions, reading git conflict warnings, or configuring environments. Having native Simplified Chinese UI significantly lowers this barrier and makes agent interaction much safer and more natural.
3. Community-Carried Maintenance: We completely understand and respect that the core team has limited capacity and must focus on core engine velocity. The community is eager to carry 100% of the ongoing translation work (reviewing catalogs, adding missing keys, and keeping them in parity with upstream releases).

Really excited to see the progress in #16087 (shared i18n foundation) and #16673 (opt-in Chinese navigation & settings). Hoping to see these merged upstream so the whole community can rally behind the official mainline!

Hi all,

Adding a +1 from Switzerland. I set up T3 Code for small businesses here, and the people using it day to day work in German and often struggle with an English UI. They love T3 Code otherwise.

We've already translated the full web UI into German (about 4,700 strings, with a glossary) in a private fork, and we'd be glad to contribute and maintain German once there is an i18n foundation.

Would a minimal foundation be something you'd accept? If you tell us the shape you'd want, we're happy to follow your lead.

Thanks for building this,
Andreas

Small English / Spanish starting point, with a working macOS prototype

Adding a Spanish use case here, following the consolidation noted in #17522.

I'm a Spanish-speaking T3 Code user. With Codex, I built a local macOS version with an Español / English selector, a saved language preference, and English fallback. I verified switching both ways and restarting, with my existing accounts, projects and chat history preserved. Some technical and third-party text still appears in English.

The screenshot below is from this local prototype. For an upstream contribution, I would propose a much smaller initial scope:

• English as the source, default and fallback; Spanish as an explicit opt-in. Store the language choice per device and preserve it across restarts.
• A small message catalog and lookup API, following the team's preferred architecture. Validate keys and interpolation placeholders. Missing Spanish strings should display English.
• One complete, bounded UI slice: navigation, common actions and General settings in the shared web/desktop UI, plus the native menu labels needed for those actions.
• Preserve user content and technical identifiers: project/chat names, messages, code, commands, paths, model IDs and provider output remain untouched. Locale changes should not modify accounts or conversation data.
• Focused verification: language selection/persistence/fallback tests, placeholder checks, before/after screenshots, and a check of bundle/runtime impact.

Mobile coverage remains a later goal, as discussed above; the catalog design should allow reuse without requiring a full mobile or application-wide translation in the first contribution. Documentation and marketing translations can also wait.

I would like to contribute the initial Spanish catalog and adapt the prototype to an agreed scope. I understand that community translations still create review and maintenance work. This should fit the existing foundation work referenced here, rather than establish a competing localization system.

Would maintainers be open to this English/Spanish slice, and which existing approach or PR should it build on? I'll wait for direction and scope approval before opening an implementation PR.

Local prototype — Settings → General:

We need that, hope maintainer will accept related PR soon!

Hi maintainers, this thread started as a Simplified Chinese request, but it has since collected requests for German, Spanish, Turkish, and other languages. I'd like a direction decision on a multi-locale foundation before anyone opens a PR, following CONTRIBUTING.md#prior-approval.

Proposed scope (deliberately narrow):

1. A shared, data-only locale catalog: plain key-to-string maps per locale, with typed keys and no new runtime dependency. Adding a locale means adding a catalog file, not editing conditionals in components.
2. English stays the default. Other locales are opt-in through an interfaceLanguage client setting, so existing users see no change.
3. Initial locales: English, Simplified Chinese (zh-CN), and one additional locale to show the mechanism is not specific to Chinese. Candidates raised in this thread include German, Spanish, Turkish, and Brazilian Portuguese. I'd suggest picking the one that already has a complete translation ready to review.
4. First surface is Web and the Electron shell. Mobile follows in a separate PR, keeping the cross-client goal raised earlier in this thread.
5. Values that are not UI copy stay untouched: provider and model names, paths, commands, user content, and official labels such as "Reasoning", "Low", and "High".

Design constraints:

• Parameterized messages use full sentences with named placeholders, not concatenated fragments, because word order differs across languages.
• Lookup is keyed by locale, not a conditional per language.

What I took from the closed PRs (#10900, #14215, #11748, #12563, #8073, #6010): they were closed mainly for missing direction approval and for scope. Changing the default language, or bundling the framework with deployment, identity, or docs changes, made them hard to review. I'd keep each step to one reviewable PR.

Questions:

• Is a data-only catalog with English as default and an opt-in setting an acceptable first step?
• Which second locale, beyond English and zh-CN, should the first PR include?
• Is Web and Electron first, with mobile later, an acceptable order?
• Should this be decided here, or under the V2 language-catalog proposal in Proposal: opt-in English / Simplified Chinese language catalogs on V2 #15179?

If there is a yes on direction, I'll follow up with a small first PR: the catalog foundation, the setting, and the locales agreed here, without translating other surfaces yet. Happy to narrow the scope further first.

Adding Czech (cs) to the list.

I am a Czech front-end developer using T3 Code daily and I would be glad to contribute and maintain the Czech catalog once a shared locale foundation is approved. I agree with the narrow scope proposed above: English stays the source, default and fallback, other locales are opt-in through a setting, and a locale is a data-only catalog file with no changes in components.

I will not open a PR before maintainers approve the direction here, per CONTRIBUTING.md#prior-approval. Happy to help test or review the foundation PR as well.

I've updated the title to reflect the scope this thread has grown into. It started as a Simplified Chinese request, but it now also covers requests for German, Spanish, Czech, Turkish, and other languages, and #6900 / #16888 / #17522 have been consolidated here.

The proposal is unchanged in substance: English stays the source, default, and fallback; other locales are opt-in through a setting; each locale is a data-only catalog file; and the initial work covers only the core web UI. I'm also keeping the cross-client goal @juliusmarminge asked for, so mobile coverage is part of the longer-term plan.

I'm not opening a PR until there is a direction decision on the foundation, per CONTRIBUTING.md#prior-approval. Happy to adjust the scope if maintainers prefer a different split.

I'd like to contribute Turkish (tr-TR) translations and review as part of the shared localization effort here.

I checked current main and read CONTRIBUTING.md#prior-approval. There is no application locale catalog to extend yet, so I would like to follow the agreed foundation rather than create another implementation.

Would maintainers be open to a Turkish catalog once the foundation's direction and scope are approved? I can start with one agreed screen, such as General settings, and keep English as the default and fallback. Provider/model names, commands, paths and user content would remain unchanged, with translation keys and interpolation placeholders checked.

Please point me to the approach you want contributors to build on. I'll wait for explicit direction and scope approval before implementing or opening a PR.

I'd like to coordinate a possible German contribution here, following the routing of the German offer in #17522 and the existing German translation interest in this thread.

We have a private English/German reference implementation spanning web, desktop, and the native iOS/Android app. It includes a substantial amount of private-edition branding and installation isolation, so I would not propose merging that fork. Those private names, identifiers, data paths, update restrictions, signing choices and unrelated fixes would remain outside an upstream contribution.

A possible first contribution would be an opt-in English/German foundation with one complete settings-to-chat-entry path across all three app surfaces, including the corresponding desktop/native mobile labels needed for that path. Existing users would remain on English, missing translations would fall back to English, and each client would own its locale. User content, commands, file paths, provider output and raw diagnostics would remain unchanged. Broader catalog coverage and additional native surfaces would be follow-up scope, with mobile retained in the overall goal.

The reference uses bundled catalogs with i18next/react-i18next and typed keys. I also see the dependency-free foundation proposal in this thread; I am not assuming either approach has been approved. The reference is based on an older upstream commit and would need selective adaptation to current main, followed by focused tests and fresh before/after evidence. It is not an upstream-ready tested patch today.

Would the maintainers be interested in this direction, and if so, what initial cross-client scope and catalog/runtime approach would you explicitly approve before an implementation PR? If the preferred route is to build on another contributor's foundation, I can first assess how the German catalog and client integration can fit that direction.

No PR is being opened as a substitute for scope approval, and this proposal does not depend on setting up external push delivery. I am offering a bounded technical proposal and reference material, not committing to a maintenance schedule.

Prepared using OpenAI Codex, GPT-6 family (exact runtime model identifier not exposed in this session).

I don't think i18n is fundamentally a technical challenge at this point. It's more about whether the project is willing to commit to it.

The community has already shown interest, proposed solutions, and even contributed working implementations. The technical groundwork is largely there.

T3 Code is growing beyond English-speaking users, and i18n shouldn't be treated as a low-priority feature indefinitely.

We don't need perfect translations for every language on day one. A simple, maintainable i18n framework that allows community contributions would be a great start.

The real question isn't whether we can implement i18n, but whether we want to make it happen.

I'd like to contribute an opt-in Russian (ru) localization covering the application-owned web/Electron interface, including the native desktop menus. The goal is a complete English / Русский choice, rather than a few translated settings screens.

The working reference is available here: English/Russian implementation, based on upstream ce9e01640636. It includes 5,894 catalog entries (including parameterized messages and whitespace/context variants).

The implementation keeps English as the default and per-message fallback. The existing client-settings pipeline persists each device's language. Switching updates mounted components without reloading or remounting the app; presentation metadata is cached separately per translator. Native menu labels follow the same preference, with menu-specific wording where needed. User messages, project names, code, commands, file paths and model IDs stay outside translation. There is no external translation service or new runtime dependency.

This branch contains only localization. Our separate OMP adapter, deployment setup, credentials, private memory, branding and signing changes are excluded. Mobile and marketing translations are outside this reference's current scope.

Local validation: check:changed passed format, lint, both knip passes, typechecks of all 39 affected packages, 2,006 tests in 234 files, and React Compiler checks for 564 changed files. The production web build also passed. Tests cover English fallback, interpolation placeholders, saved language, live language updates with an unsent draft retained, and both native menu languages. Native-menu tests use the Electron service stubs; they are not a claim of a live macOS UI verification. The integrated T3 Browser-panel pass and full-app before/after captures are still outstanding in this environment.

I see the foundation work in #27965 and the direction discussion here. I am not asking to merge a competing localization foundation or treating a reference implementation as scope approval. The complete Russian catalog and UI integration can be adapted to the maintainers' chosen foundation.

Would maintainers approve this English/Russian web-and-desktop coverage as a contribution, and which foundation should it build on? Per CONTRIBUTING.md, I will wait for explicit direction/scope approval before opening the implementation PR. I'm not committing to a translation maintenance schedule without first agreeing on the approach.

Prepared with OpenAI Codex (GPT-6 family).

French on top of #27965, plus three small follow-ups

#27965 looks like the shared foundation this thread asked for: English stays the source, default and fallback, and each locale is a catalog keyed by the English keys. Once it lands, I'd like to build on it, and I'm asking for explicit approval of the direction and scope first, per CONTRIBUTING.md#prior-approval.

Locale. French, which I can translate and maintain as a native speaker. It is opt-in through the existing language setting and adds catalog data only.

Follow-ups to the layer, one PR each, needed by French and by any other language beyond zh-Hans:

1. resolveUiLocale maps any supported base language (fr-CA to fr), not only Chinese.
2. Plural messages selected by CLDR category with Intl.PluralRules. Chinese has no plural forms, so the layer doesn't handle them yet, and the app has about 200 hand-written count === 1 ? ... : ... choices that need them in French.
3. Non-English catalogs loaded on demand, so the initial bundle stays English-only as languages are added. A full extraction is roughly 6,600 strings.

Not included: any change to the default language (that stays with your product review on #27965), desktop native menus, and mobile, which I'd propose separately.

For every PR: no new dependencies, one problem per PR, before/after captures, and the model and harness named in the description. No PR before an explicit OK.

Could a maintainer confirm whether (a) a French catalog and (b) the three follow-ups are welcome once #27965 merges, and (c) whether you want contributors to extract further screens domain by domain, or prefer to drive that yourselves?

I'd like to contribute Ukrainian (uk) localization, following the shared direction in this discussion and #27965 rather than proposing a competing foundation.

A local prototype based on stable v0.1.6 covers approximately 6,100 web messages and 85 Electron-shell messages, including settings, navigation, composer, dialogs, accessibility labels and native menus. It has a persisted System / English / Українська preference, English fallback, named interpolation and Ukrainian plural categories through Intl.PluralRules. Provider/model IDs, protocol values, code and user/agent content remain unchanged. Mobile is outside this prototype's scope.

Validation: format, lint, both knip passes, typechecks of all 39 affected packages, 576 React Compiler cases and production desktop packaging passed. Focused localization/persistence/menu/model-label/packaging/search tests passed (94 tests); the follow-up settings/chat tests passed (50 tests). The broad changed-code run was not green: 1,902/1,910 tests passed. Seven browser failures passed when their files ran separately; the remaining guest-scroll failure reproduces identically on untouched v0.1.6 (LegendList convergence abort, 2,074-pixel bottom gap). No tests were skipped or relaxed to conceal these results. The packaged macOS app's Ukrainian settings and composer were also inspected in the native client.

The local build uses separate app identity/state and no upstream update feed so official updates cannot erase the translation. Those distribution-specific changes would stay separate from an upstream contribution.

Would maintainers welcome a Ukrainian catalog and focused web/Electron integration adapted to the chosen foundation? In particular, should Ukrainian plural support and native menus be separate follow-ups to #27965? I will wait for explicit direction/scope approval before opening an implementation PR; this comment is a proposal, not a claim of approval or a maintenance commitment.

Prepared with Codex (GPT-6.1 Sol); Claude Opus 5.5 reviewed the packaged-client startup failure and identified the macOS Unicode helper-path mismatch.

+1 for a multi-locale foundation, and please consider German (de) as one of the next locales.

I use T3 Code every day for my work as a craftsman in Germany, and my whole working environment is German. The menus are the only part that stays English. A language setting with English as the default and fallback would be enough. I would be glad to help test a German catalog.

@LyaQanYi 我这边发布了一份基于官方 2.2.0（735）的 T3 Code Android 简体中文社区版，源码和签名 APK 都已公开。欢迎来看看，也可以下载安装试试。

源码仓库 · APK 发布页

Offering to help with Simplified Chinese (zh) on top of #31313

Hi! I'm a native Simplified Chinese speaker. I'd like to help with the official zh translation, following the direction maintainers have set in #31313 (gt-react, English as the source and fallback) rather than proposing anything competing.

What I can bring

• I maintain deepfry666/t3code-cn, a zh-CN fork that tracks official releases. It has about 9,800 web/desktop strings, also keyed by the English source text, so they map onto GT's catalog for strings that get wrapped.
• A written glossary, plus automated checks that fail when:
  • the same English gets two different Chinese renderings;
  • a recurring term (thread, agent, worktree, provider…) drifts;
  • a placeholder is lost.
• A list of text that deliberately stays English (agent prompts, diagnostics, brand names), with the reason for each.
• The translations were made with AI assistance, then reviewed entry by entry. That review fixed about 600 issues: state confusion (on/off, in progress vs done), awkward phrasing and inconsistent terms.

How I'd like to help, if it's welcome

1. Review the zh strings in each slice as it lands. I left notes on feat(web): switch the UI language from Settings, with Spanish and Chinese #31313's first slice.
2. When a slice wraps more UI, open one small PR per slice that fills zh.json from the fork's reviewed translations, so zh isn't left to machine regeneration.
3. Keep the glossary consistent across slices.

Before doing any of that, I'd appreciate a maintainer's go-ahead on the direction (per CONTRIBUTING), and on two terms that shape every later string: thread as 会话 or 线程, and agent as 智能体 or 代理. The reasoning is in my comment on #31313.

Thanks for opening T3 Code up to more languages!

I’d like to request multilingual UI support in T3 Code.

Please consider adding a language selector in Settings so users can choose their preferred interface language. The language preference should be saved, and English can remain the default and fallback when a translation is not yet available.

A useful first step would be to support a few commonly requested languages, including Simplified Chinese, and cover the main interface areas such as navigation, settings, model options, permission prompts, and error messages. The localization system should also make it straightforward for the community to contribute more languages over time.

As a Chinese-speaking designer using T3 Code on macOS, I can already communicate with the coding agents in Chinese, but I still struggle with the English interface when choosing settings or understanding permissions and errors. A multilingual interface would make T3 Code easier to use for people around the world.

I built an experimental Simplified Chinese desktop branch against T3 Code 0.1.9: https://github.com/Link557/t3code/tree/zh-cn-desktop-prototype

It adds English / 简体中文 switching, translated UI text and localized macOS menus, building on work by ZhiweiXiao98. The desktop language and menu switch were observed; translation coverage and restart persistence still need verification. The branch also contains settings for an isolated local build.

Would maintainers be interested in an i18n contribution? If so, what scope would you prefer for a PR?

The separate Antigravity SOCKS proxy issue is already tracked in #16911 and google-antigravity/antigravity-cli#1489.