[Feature]: Community-led Simplified Chinese localization with a minimal i18n foundation

[LyaQanYi]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web

Problem or use case

T3 Code currently displays its interface in English only. As a native Chinese speaker, I can use the application, but understanding settings, actions, error messages, and less familiar terminology requires additional effort.

This also creates a barrier for Chinese-speaking developers who are interested in using or contributing to the project but are not comfortable working with an English-only interface.

A previous request for Chinese localization was raised in #1463 and closed because the maintainers did not have the capacity to work on i18n at the time. I understand that concern. This proposal is specifically asking whether a small, community-led implementation would be acceptable, with me taking responsibility for the initial Simplified Chinese translation and implementation work.

Proposed solution

Introduce a minimal localization foundation for the web application and add Simplified Chinese (zh-CN) as the first additional locale.

The initial implementation could:

1. Keep English as the default and source locale.
2. Extract only core user-facing UI strings into locale files.
3. Add Simplified Chinese translations for those strings.
4. Provide a language option in Settings, with the selected locale stored locally.
5. Fall back to English whenever a translation is missing.
6. Include focused tests and documentation for adding or updating translations.

I would follow the maintainers’ preferred architecture and keep the implementation small. I am willing to prepare the translations and submit the PR myself if the project is open to accepting and maintaining this foundation.

Why this matters

Chinese-speaking developers represent a large part of the global developer community. A localized core interface would make T3 Code easier to understand and adopt, particularly for users who are comfortable with programming but not with an English-only product interface.

Adding a small localization foundation would also make future community-contributed translations possible without requiring the maintainers to translate the application themselves.

Smallest useful scope

The first version only needs to cover the core application shell and the most frequently used interface text, including:

• navigation;
• common buttons and actions;
• settings labels;
• dialogs and menus;
• common status and error messages.

English would remain the default language. Documentation, marketing pages, uncommon screens, and additional locales can remain out of scope for the initial PR.

Alternatives considered

Browser translation: This can produce inconsistent translations and may not work well for dialogs, dynamic content, technical terminology, or desktop usage.

Maintaining a separate Chinese fork: This would quickly fall behind the upstream project and duplicate maintenance work.

Translating documentation only: Helpful for onboarding, but it would not address difficulty using the application itself.

Hardcoding Chinese text directly in components: This would not scale and would make future maintenance more difficult.

Risks or tradeoffs

Introducing i18n creates ongoing maintenance work because new or changed UI strings need corresponding translations.

There is also a risk of missing or outdated translations. This can be reduced by:

• using English as a reliable fallback;
• keeping locale files structurally consistent;
• adding checks for missing translation keys;
• documenting the translation workflow;
• starting with only a small set of core UI strings.

The implementation may also add some architectural and bundle-size complexity, so the initial solution should remain lightweight.

Examples or references

Previous request: #1463

Maintainer response regarding current capacity: #1463 (comment)

Contribution

• I would be open to helping implement this.

[LyaQanYi]

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.

[Pakvothe]

"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?

[juliusmarminge]

#6900 is being consolidated here with the other Simplified Chinese requests. It also asks for eventual mobile coverage; please retain that cross-client goal alongside the initial web/desktop localization work.