Before submitting
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:
- Keep English as the default and source locale.
- Extract only core user-facing UI strings into locale files.
- Add Simplified Chinese translations for those strings.
- Provide a language option in Settings, with the selected locale stored locally.
- Fall back to English whenever a translation is missing.
- 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
Before submitting
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:
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:
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:
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