Proposal: Add translation support – we'd like to help build it, starting with German

[OmegaProjct]

Why

We'd love to use T3 Code in our own language, and we'd like to help make that possible for everyone. Right now all UI text is hardcoded English inside components (web, desktop, mobile), so there's no way to add a translation without changing every screen. We'd like to build the foundation for translations and contribute the first one (German).

Proposal

Move user-facing strings into per-language message catalogs, with English as the source of truth.

• Typed keys, English as the base catalog. A missing key fails typecheck instead of shipping a blank label. Missing translations fall back to English, so a partially translated language is always safe.
• Shared between web and mobile. Catalogs live next to packages/client-runtime, so both clients use the same keys and translations.
• Small runtime. Plurals, dates, and numbers through the built-in Intl APIs. No heavy dependency, and only the active language is loaded. We'd measure bundle size and render cost before and after, since performance matters here.
• Language choice. Defaults to the OS/browser language, with an override in Settings.

Keeping it maintained without extra work for you

The obvious cost is that every new string has to land in the catalog. Two pieces would handle that:

1. An AGENTS.md rule. Since most changes are written by agents, one short rule ("put new user-facing text in the catalog, add the key to every language, translate it") means agents keep catalogs current as a side effect of normal work.
2. A CI check. A lint rule in oxlint-plugin-t3code that flags raw text in JSX, plus a check that every language has every key. The agent rule makes it cheap; the check makes it reliable.

The model also lets community translators own a language by editing one catalog file, without touching components. Languages nobody maintains simply fall back to English.

What we'd contribute

We would do the implementation ourselves, in reviewable steps:

1. The foundation plus one area (e.g. Settings) as a proof of concept, with before/after screenshots and bundle numbers.
2. Remaining web/desktop areas in follow-up PRs.
3. Mobile.
4. A complete German translation as the first non-English language.

Questions

• Is localization something you'd accept in principle?
• If yes: any preference on the approach (no library vs. a small one), catalog location, or how you'd want PRs split?

Happy to adjust scope to whatever fits how you want to work.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Thanks for the detailed proposal and the offer to build it. The core ask here, a minimal i18n foundation with English as the source and fallback plus community-maintained language catalogs, is already being discussed in #6789, where another German offer has also been made, so I'm closing this as a duplicate to keep the conversation in one place. Please add your German plan and the questions on approach there.

Related threads you may want to follow: #6901 (i18n foundation with Brazilian Portuguese), #15179 (opt-in language catalogs), and open PR #16087 (shared i18n foundation). As CONTRIBUTING.md notes, please wait for maintainer approval before opening implementation PRs.