[FEATURE]: i18n support for TUI (terminal interface) #37216

Activity

1. github-actions

   assigned

   kommander

   on Jul 16, 2026
2. github-actions commented on Jul 16, 2026

   

   github-actionsBot

   on Jul 16, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • [FEATURE]:Feature request: i18n / multi-language support for TUI interface #27445: Nearly identical feature request — "i18n / multi-language support for TUI interface" (closed), which proposed the same locale config option and TUI string localization
   • [FEATURE]: add locale-aware CLI and TUI strings to packages/opencode #21084: "add locale-aware CLI and TUI strings to packages/opencode" (closed), covering the same scope of making TUI strings locale-aware
   • [FEATURE]: i18n / Locale support (Portuguese and other languages) #35831: "i18n / Locale support (Portuguese and other languages)" (open), which also discusses the existing i18n infrastructure in packages/app/src/i18n/

   Please review those issues and the discussion there before proceeding, as the maintainers may have already provided relevant context or decisions.
3. xingxiulaomo commented on Jul 27, 2026

   

   xingxiulaomo

   on Jul 27, 2026

   More actions

   中文用户群体很大，很多非英语母语的开发者更习惯中文界面来降低认知负担。目前 Desktop 端已有 i18n 基础设施，希望 TUI 端也能尽快支持中文（zh-CN / zh-TW）。我们愿意帮忙测试和校对翻译。
4. huahai0202 commented on Aug 27, 2026

   

   huahai0202

   on Aug 27, 2026

   More actions

   For context, a working V2 TUI i18n plugin already exists (opencode-i18n-v2, zh-Hans/zh-Hant palette translation shipped on npm). It is built entirely on shadow keymap commands, which requires perpetual polling of context.keymap.commands(), echo detection, and bind: false guards to avoid hijacking keys.

   A small sanctioned hook — e.g. a display-time command transform or a "command registered" event — would let community plugins own localization of any surface/locale. Concrete proposal + evidence: #45490.
5. neriousy

   marked [FEATURE]: Russian (ru) localization / i18n support for the TUI interface #43533 as a duplicate of this issue on Oct 20, 2026
6. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   Contributor

   More actions

   Thanks for the detailed request, @apuromafo!

   You're asking for the terminal UI (packages/tui) to be localizable like the app, desktop and console packages. That would mean moving the hard-coded English strings into an i18n key system, adding a locale option in opencode.json, and shipping translations for the common locales. Today the TUI has no localization layer; only dates and times follow your system locale.

   This can't be done as a plugin, because the TUI's strings are built in and there is no hook to replace them, so it would need changes in core. Maintainers will consider it.

   Related issues you mentioned (all closed, none covers the TUI itself):

   • fix(app): Spanish General settings shows English labels and descriptions #32095: Spanish settings showing English labels in the app
   • Failing i18n parity test in packages/app. #36292: i18n parity test failures in packages/app
   • System prompts force ASCII-only output, breaking support for non-English languages #12609: system prompts forcing ASCII-only output for non-English languages
7. krotname commented on Nov 5, 2026

   

   krotname

   on Nov 5, 2026

   More actions

   Following the review of #61366, I'd like to agree on a smaller TUI i18n design before submitting the implementation in stages. @kommander, would this first step fit the intended direction?

   • Keep the translation layer inside packages/tui, using the app's flat catalog pattern and @solid-primitives/i18n. English defines the typed keys and remains the default; later catalogs load on demand with English fallback. Use Intl for numbers, dates and plural selection.
   • Persist a language setting through the existing TUI config/update mechanism. The initial PR would contain only an English catalog, a language picker and one converted dialog to demonstrate the pattern. Preserve existing English output and command IDs, bindings and behavior.
   • Translate built-in display text only. Paths, tool inputs/output, model identifiers and user content stay unchanged. The plugin command-display hook proposed in [FEATURE]: Plugin hook for localizing built-in TUI text (command titles and UI strings) #45490 would need its own API discussion; this first step would not change the plugin or server protocol.
   • Cover fallback/loading, keys and interpolation, plural selection, persistence and keyboard/mouse selection. Keep existing English tests passing and check narrow terminal layouts.

   After that infrastructure PR: extract English strings in small batches (dialogs, prompt/session, sidebar/plugins), then Mini, then the Russian catalog and its coverage/plural tests. Each PR would have a limited scope and its own validation.

   Could you confirm the core-layer approach and whether language belongs in TUI config, or prefer the issue's locale option in opencode.json? I'll keep the existing implementation as a reference and wait for maintainer design approval before opening the first implementation PR.