[Feature]: Add a minimal i18n foundation with Brazilian Portuguese support

[SirMaciel]

Before submitting

• I searched existing issues and did not find an existing Brazilian Portuguese localization request.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web, apps/desktop, apps/mobile, and shared client runtime where appropriate

Problem or use case

T3 Code currently exposes its user interface in English only across the hosted and locally served web clients, the desktop application, and the iOS and Android applications.

Brazilian Portuguese users must interpret settings, permissions, dialogs, error states, navigation, and agent-specific terminology in a second language. Browser translation is not a reliable workaround for Electron or React Native surfaces and can produce inconsistent translations for dynamic or technical UI text.

There are existing discussions about a minimal i18n foundation for Simplified Chinese in #4082 and #5601, plus the earlier capacity concern in #1463. This request is specifically for Brazilian Portuguese (pt-BR) and acknowledges that the main cost is not the initial translation but maintaining the localization foundation over time.

Proposed solution

Introduce a lightweight localization foundation shared across T3 Code's client surfaces and add Brazilian Portuguese (pt-BR) as the first requested locale for this contribution.

The desired behavior is:

1. Keep English as the source, default, and reliable fallback locale.
2. Add a language selector in Settings and persist the user's explicit choice.
3. Optionally use the browser or operating-system locale only when the user has not selected a language.
4. Cover the hosted and local web clients, the desktop application on Windows, macOS, and Linux, and the mobile application on iOS and Android.
5. Keep translation keys and locale behavior consistent across surfaces, while allowing platform-specific strings where necessary.
6. Fall back to English for missing keys rather than displaying broken or blank UI.
7. Add focused validation for missing or structurally inconsistent keys and brief contributor documentation for maintaining translations.

The implementation should follow the repository's preference for the smallest simple system and avoid adding unnecessary runtime, bundle-size, rendering, or WebSocket overhead.

Why this matters

Brazilian Portuguese is the primary language for a large developer community. Native pt-BR support would make T3 Code easier to adopt and operate, especially for settings, permission prompts, error recovery, and mobile workflows.

A minimal foundation would also provide a maintainable path for future community-contributed locales without requiring separate forks or hardcoded translations in individual components.

Smallest useful scope

A first accepted version can remain deliberately narrow:

• English and Brazilian Portuguese only.
• Core application shell and high-frequency user-facing strings only: navigation, common actions, Settings, dialogs, menus, connection states, and common errors.
• A persisted language setting with English fallback.
• Consistent behavior on web, desktop, and mobile.
• Focused tests for locale selection, persistence, and fallback.
• A short guide for adding or updating translation keys.

Marketing pages, full documentation translation, provider-generated content, terminal output, uncommon screens, and additional locales can remain out of scope. The implementation can be split into small, reviewable PRs if maintainers prefer.

Alternatives considered

• Browser or operating-system translation: inconsistent for dynamic technical text and unavailable as a complete solution in desktop and mobile clients.
• Maintaining a separate Portuguese fork: it would drift from upstream and duplicate ongoing maintenance.
• Translating only documentation: useful for onboarding but does not solve day-to-day product usage.
• Hardcoding Portuguese strings in components: simple initially but not maintainable and would make future locales more expensive.
• Implementing each client independently: risks inconsistent terminology, locale persistence, and fallback behavior.

Risks or tradeoffs

• Every new or changed user-facing string creates translation maintenance work.
• Missing or stale translations can lead to mixed-language screens.
• A third-party i18n runtime may affect bundle size or rendering performance.
• Web, Electron, and React Native do not share every UI component, so full consistency requires explicit cross-surface coverage.
• System-locale detection must not override a user's explicit selection.
• Technical terms need a reviewed glossary so translations remain consistent.

These risks can be reduced through English fallback, focused structural checks, a small initial catalog, lazy or static loading where appropriate, and clear ownership of translation updates.

Examples or references

• Related minimal i18n proposal: [Feature]: Community-led Simplified Chinese localization with a minimal i18n foundation #4082
• Related multi-surface localization proposal: [Feature]: Simplified Chinese (zh-CN) localization for web, desktop and mobile apps #5601
• Earlier maintainer capacity response: [Feature]: Add Chinese (zh-CN) localization / i18n support #1463

Contribution

• I would be open to helping implement this after maintainer guidance on scope and architecture.

[ygormteus]

Hi! I’d like to offer my help implementing Brazilian Portuguese (pt-BR) support while preserving English as the default language and fallback.

Before starting implementation, I’d like to confirm whether maintainers are interested in this contribution and agree on a manageable initial scope.

My proposed first step would include:

• A lightweight localization foundation, following the project’s preferred architecture.
• An English / Português (Brasil) selector in Settings, with the user’s choice persisted.
• English fallback for missing translations.
• An initial translation of core navigation, common actions, Settings, dialogs, and connection states.

I suggest starting with the shared web/desktop interface, with mobile coverage guided by maintainers’ priorities. I can split the work into small, focused PRs to make review easier.

I’d also provide focused tests for language selection, persistence, fallback, and translation-key consistency, plus before/after screenshots and a short contribution guide.

Would this direction be welcome? If so, what initial scope and localization approach would you prefer? I’m happy to adapt the proposal before implementation.