Feature request: Multi-language UI with a language selector (i18n)

Feature Description

Problem

The entire product surface — website, docs, desktop app, and CLI — is English-only.
There is no language option anywhere in Settings (General / Appearance / Agent /
Taste / MCP / Account), and no way for users to switch the interface language.

For a tool positioned as a frontier coding agent, this is an adoption bottleneck
in non-English markets.

Suggested solution

Add a Language dropdown under Settings → General, letting each user
freely pick their interface language. Suggested launch set:

• English (default)
• 简体中文 (zh-CN)
• 日本語 (ja)
• Español (es)
• Português (pt-BR)
• Deutsch (de) / Français (fr) / 한국어 (ko) as follow-ups

Scope for v1: desktop app UI + the most-visited docs pages.

Implementation notes:

• Build the i18n layer on a standard framework so adding a language is a
  translation file, not a code change
• If in-house translation isn't planned, a community workflow (e.g., Crowdin)
  keeps marginal cost near zero — especially if the i18n layer is added early
  rather than retrofitted later

I'm filing this as a product suggestion; happy to help test new languages once
shipped.

Use Case

• Market size: The majority of the world's ~30M developers are non-native
  English speakers. China alone has ~7M professional developers (the largest
  single population globally), and strong dev communities exist across Japan,
  Brazil, Korea, and Spanish-speaking Latin America.

• Competitive parity: Cursor, Windsurf, and Trae already ship official
  multi-language / Simplified Chinese UIs. Trae's rapid growth is partly
  attributed to localization. English-only is becoming a visible gap.

• Brand consistency: Non-English content about Command Code today is almost
  entirely third-party reviews and machine-translated blog posts — mixed
  messaging, no quality control, no positioning leverage. Official localization
  would consolidate all of it.

• Low cost, compounding return: A language dropdown is a one-time i18n
  investment; each new language after that is just a translation file, often
  community-contributed.

Additional Context

No response

How important is this to you?

Important for my workflow

Start by mapping the desktop app's Settings → General entry point and the most-visited docs pages named in the issue. Determine how language preferences and translations should be represented, then define the supported launch languages and fallback behavior. Done means a selectable interface language works for the v1 desktop UI and scoped documentation pages.