UI language localization support

It would be great to support something like localization plugins to allow the community to localize the interface without requiring the Claude team's effort for each new language

+1 from a Japanese user.

The language setting currently only controls Claude's response language (per schema: "Preferred language for Claude responses and voice dictation"). Interactive UI — slash command dialogs like /hooks, /plugin, /help, confirmation prompts, error messages — remains English-only.

Setting language: japanese makes Claude respond in Japanese, but all menu/dialog UIs are still English, creating an inconsistent surface between the conversation (Japanese) and the CLI (English).

Consider a separate uiLanguage setting so users can mix configurations (e.g., English UI + Japanese responses, or fully Japanese).

+1 — @scala-kubotay's separate uiLanguage proposal matches what I had in mind. Decoupling UI language from response language is the cleaner model: some users want English UI + native responses, others want full localization. And @antomy-gc's point about community localization plugins would make this scale without blocking on the Claude team for every language.

Feature Request: Czech (cs-CZ) language support for Claude UI

I'd like to request Czech (cs-CZ) as a supported UI language for Claude Desktop and Web.

Czech is spoken by ~10 million native speakers in the Czech Republic and Slovakia, and is an official EU language. Several neighboring languages (German, French, Italian, Spanish) are already supported — adding Czech would be a natural next step for European users.

What would need to be localized:

• Menu items and navigation
• Settings and preferences
• Dialog messages and notifications
• Tooltips and placeholder texts

I'm a Czech-speaking user and would be happy to assist with translations or review if the Anthropic team opens a localization contribution process.

Related: #31413

+1 for this. As a Russian-speaking developer using Claude Code daily on macOS, the English-only UI is the single biggest friction point. Specifically:

• Permission prompts ("Allow / Deny / Always allow") break flow when I'm in a Russian context — I have to mentally switch languages mid-task
• Slash command descriptions, error messages, status spinners, menu labels — all English
• The model itself responds perfectly in Russian, so the inconsistency between content and chrome is jarring

Suggested priority of strings to localize first:

1. Permission prompts (most frequent interaction)
2. /config, /help, /status output
3. Error and warning messages
4. Menu items / slash command descriptions

Happy to contribute Russian translations via PR once a string catalog / i18n infrastructure is in place. Would even propose i18next or Fluent for the runtime layer if helpful.

Other priority languages from the developer community: Chinese, Japanese, Spanish, German, Russian, French, Korean. Starting with even 2-3 of these would be a huge UX win.

中文用户常问 MCP / Agent / RAG 等词什么意思 — 维护了一个开源中英对照词典（101 条，CLI 可查）：

https://github.com/YqqLikeGit/ai-heihua-zh

含 GitHub Star/Fork/PR 扫盲 + 2026 AI 热词，MIT，欢迎补充翻译相关词条。

+1 from a Spanish-speaking developer (Paraguay). The model already replies
in Spanish via /config, but the CLI chrome — permission prompts, /config,
/help, status line, error messages — stays English-only, creating an
inconsistent surface.

Strongly support @scala-kubotay's separate uiLanguage setting (decouple UI
language from response language) and @antomy-gc's community localization
plugins so new languages don't block on the Claude team.

Priority strings to localize first: permission prompts, /config & /help,
error/warning messages. Happy to contribute/review Spanish translations.

我也非常需要这个功能，或允许插件。

+1 for this. As a German-speaking user of the desktop app, the English-only sidebar (category headings like "Recents"/"Today", menus, dialogs) makes the app noticeably harder to navigate. The language setting in settings.json only affects Claude's responses, not the UI itself. German localization would be greatly appreciated.

A complete Russian implementation candidate is now attached to #69078.

It includes 21,093 Russian strings, automated validation, an integration map, and proof-of-concept screenshots: https://github.com/plesnev-hash/claude-desktop-ru

I found several earlier Russian or general localization requests in this repository, but no other Russian request with a complete locale pack and integration evidence. The candidate is ready for official review in the existing localization discussion.

Request: Turkish (tr-TR) UI localization

Hi, I'd like to request Turkish (tr-TR) localization for the Claude desktop app interface (menus, settings, buttons). Claude can already respond in Turkish, but since the app UI is only available in English, accessibility remains limited for Turkish-speaking users. Adding tr-TR localization would significantly improve the experience for a large user base. Thank you for considering this.

+1 for this feature.

+1 for Japanese (日本語) UI localization.

The model's responses can already be kept in Japanese, but the CLI's own UI strings remain English-only — most recently the background-sessions list screen (e.g. "Your conversation moved to the background - enter opens it", "Needs input", "Completed", "Describe a task for a new session", "enter to expand - ctrl+e to delete all - ? for shortcuts"). As new surfaces like this ship, the amount of untranslatable UI text keeps growing.

There is currently no settings.json option, environment variable, or /config entry to switch the interface language. A locale setting covering these built-in strings (ja included) would be greatly appreciated.

+1 for this request — specifically for the built-in slash-command list/menu (e.g. /clear, /code-review and their one-line descriptions shown when typing /), which stays in English even when the response language is set to Japanese via /config. For non-English-speaking users this is one of the most visible remaining English-only surfaces in daily use, alongside permission-dialog labels reported in other issues (#82377, #77976, #73076). Would be great if slash-command menu strings could be covered by the localization effort described here.

日本人ユーザーからの賛成意見です。 このlanguage設定では現在、Claudeの応答言語のみが制御されます（スキーマ「Claudeの応答と音声入力の優先言語」による）。対話型UI（スラッシュコマンドダイアログ、確認プロンプト、エラーメッセージなど/hooks）/pluginは/help英語のみとなります。 この設定language: japaneseではクロードは日本語で応答するが、メニューやダイアログのUIはすべて英語のままなので、会話（日本語）とCLI（英語）の間で一貫性のないインターフェースが生じる。 uiLanguageユーザーが設定を組み合わせられるように、別の設定項目を設けることを検討してください（例：英語のUIと日本語の応答、または完全に日本語）。

+1 for this request.

My specific pain point: the tool-permission prompts (Allow/Deny dialogs)
are hardcoded in English, even when I'm working entirely in Japanese with
Claude Code. Right now, every time an approval dialog appears, I have to
either take a screenshot or copy-paste the text into a separate translator
just to understand exactly what I'm approving.

A settings.json locale option (or an env var like CLAUDE_LANG) that
localizes just the permission-dialog text would remove this friction
entirely and let me review approvals more carefully and quickly,
I wouldn't need to context-switch out of the terminal.

Happy to help test a Japanese translation if that's
useful.

この要望に+1です。
私の具体的な困りごと：Claude Codeを日本語
権限確認ダイアログ（Allow/Deny）は英語固定で表示されます。そのため
スクリーンショットを撮るか、テキストをコピーして別の翻訳ツールに貼
ないと、何を承認しているのか正確に理解できません。
settings.jsonにロケール設定（またはCLAUDE_LANGのような環境変数
追加し、権限ダイアログの文言だけでもローカライズできるようになれば
手間がなくなり、承認内容をより丁寧かつ迅速に確認できるようになりま

日本語訳のテスト協力など喜んでお手伝いします。

+1 for this feature.

I'd like to add Traditional Chinese (zh-TW) to the list of requested locales, with one important note: please treat Traditional Chinese (zh-TW) and Simplified Chinese (zh-CN) as separate locales, not a single "Chinese". They differ in both script and terminology (e.g. "settings" is 設定 in zh-TW but 设置 in zh-CN), so a single zh locale would feel wrong to half of its users.

Current state for Chinese-speaking users: the language setting works well for Claude's responses, but permission prompts (Allow once / Allow always / Deny), the /config menu, trust dialogs, and status messages are all hardcoded in English, which makes the overall experience mixed-language.

A locale key in settings.json (e.g. "locale": "zh-TW") with English fallback for untranslated strings would be ideal.

+1 from another Japanese user.

I use Claude Code entirely in Japanese every day, and the model itself responds fluently in Japanese. But the surrounding UI — the skill/plugin picker, model-selection menus, permission prompts, /help output — stays hardcoded in English regardless of locale. It's a strange mismatch: the conversation is completely natural in my language, but the moment I need to pick a skill or plugin from a list, I have to know English words like transcript-cleanup or portfolio-update to find the right one.

A locale setting in ~/.claude/settings.json (auto-detected from the OS locale by default, like others have suggested above for zh-TW/zh-CN) that lets skills/plugins declare localized display names, with English as the fallback when no translation exists, would fix this for Japanese as well as the other languages already requested here.

+1 from a Russian-speaking user of the Claude desktop app (macOS). I run a genealogy platform (tegim.kz) entirely in Russian and Kazakh and use the Code tab daily. Claude's replies and my CLAUDE.md are in Russian, but the app chrome stays English: the activity summary ("Ran 14 commands, read 15 files"), permission dialogs, settings labels, "What's new". For a non-English-speaking owner reading the action feed this is the main friction point — every status line has to be mentally translated. Even a minimal first step would help: localizing the activity feed and permission prompts, with the language taken from the existing language setting.

+1 for Turkish (tr-TR) from a Turkish-speaking developer.

Claude already responds in Turkish via the language setting, but permission prompts, /config, /help, the slash-command list and error messages stay in English, so every decision point requires switching languages.

I support the separate uiLanguage setting proposed above, and community-maintained locale files if official translations are not feasible. I am a native speaker and happy to help translate or review Turkish strings. (My earlier request, #69348, was auto-closed for inactivity.)