Feature request: Add voiceLanguage setting for /voice mode

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/30868
2. https://github.com/anthropics/claude-code/issues/30890

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

+1 for this feature! French speaker here — voice mode is currently unusable for us. The proposed voiceLanguage setting with ISO 639-1 codes would be perfect.

Since the underlying STT likely already supports multiple languages, exposing a simple config option would unlock voice mode for a large portion of non-English developers.

@gangpro Great binary analysis! This confirms exactly what I experienced — the hardcoded "en" makes /voice completely unusable for non-English speakers.

I strongly support using "multi" as the default value instead of "en". This would make voice mode work out-of-the-box for everyone without requiring manual configuration. Deepgram's multi-language detection handles this well and would be the most inclusive default.

For users who want to force a specific language (better accuracy), the voiceLanguage setting in settings.json is a clean solution.

+1 for this. Auto-detection doesn't work for Turkish at all it either fails to detect speech or transcribes it as English gibberish.

+1 from a German speaker. Voice mode consistently tries to recognize English instead of German, even when speaking
clearly in German. Short phrases are especially bad — Whisper defaults to English and produces garbled output.

Windows built-in speech-to-text (Win+H) recognizes German perfectly, so the mic/audio setup is fine. A voiceLanguage
setting in settings.json would solve this immediately.

+1 for this\! I'm a Brazilian Portuguese speaker and the current voice mode transcribes my Portuguese words as phonetically similar English words, making it unusable. Would love to see a voiceLanguage setting supporting pt-BR. 🇧🇷

Update: As of v2.1.76 (March 14, 2026), this is now resolved. The /voice command uses the language setting from /config. Setting it to your language code (e.g. fr) correctly configures the STT dictation language.

On enable, /voice now displays:

Voice mode enabled. Hold Space to record. Dictation language: fr (/config to change).

Confirmed working with French. 🎉

+1 on this. I'm a bilingual (Spanish/English) user and this is a real blocker for productivity.

My use case: I need Spanish as my primary dictation language with English as secondary. I frequently switch between both languages when communicating with Claude Code via voice. Without auto-detection or multi-language support, I'm forced to either:

1. Set language: "es" and lose accurate English transcription
2. Keep the default English and get garbled results when speaking Spanish
3. Manually change settings every time I switch languages

The proposed "voiceLanguage": ["es", "en"] with "auto" detection would solve this completely. Many of us work in multilingual environments and voice input is essential for transferring context efficiently — especially for longer explanations where typing is impractical.

Would love to see this prioritized. The underlying STT likely already supports multi-language detection; it just needs to be exposed.

Confirmed working for Spanish (es) on v2.1.108 — setting language in /config correctly propagates to /voice dictation. Thanks!

That said, multi-language support (as originally proposed with voiceLanguage: ["en", "es"]) would still be valuable for bilingual workflows where we switch between languages mid-session without having to toggle /config each time. Would it make sense to reopen or track that separately?

+1 from a multilingual user (Swedish, English, Polish, German, French). I switch between sv/en mid-sentence daily, and also work in pl/de/fr. The voiceLanguage array proposal would solve it. Closing my duplicate (#58062) in favor of this thread.

+1 from a Norwegian (Bokmål) perspective. Same issue: STT defaults to English, transcription of Norwegian voice input fails or produces incorrect English output. The proposed voiceLanguage array form would cover this cleanly. Whisper supports nb (Norwegian Bokmål) and nn (Nynorsk) natively, so this is configuration exposure, not new STT capability.

Quick follow-up to my previous comment: Norwegian dictation actually works on v2.1.139 — but the language code is no, not nb.

Setting language: nb in /config is rejected with "'nb' is not a supported dictation language; using English." Setting language: no works perfectly. Just tested with the phrase "Få med deg hva jeg sier nå når jeg snakker norsk." — transcribed cleanly with correct diacritics and punctuation.

The mismatch is upstream: Whisper's tokenizer uses no for Norwegian (covering both Bokmål and Nynorsk under the general code), while ISO 639-1 distinguishes nb and nn. Users reaching for the ISO codes (which is the natural choice for anyone familiar with locale standards) hit a wall.

Suggested improvement: alias common ISO 639-1 variants to their Whisper equivalents in the validation layer — nb → no, nn → no, possibly others where similar mismatches exist. Failing that, list supported codes explicitly in the error message.

Posting this in case it helps other Norwegian users find the working configuration.

Adding another data point for this: same root cause, different manifestation.

Setup: "language": "pt" in settings.json (Portuguese), using /voice in "hold" mode.

When dictating in Portuguese and mixing in English technical terms mid-sentence (very common for non-English-speaking developers — e.g. saying "regex", "commit", "pull request" while speaking Portuguese), the transcription engine visibly writes the English word, then retracts/erases it moments later — presumably because the partial-transcription reconciliation step is biased toward the single forced language and revises tokens that don't match it.

This is the same underlying gap as #33170, #69936, and the now-locked #36908/#58062 (Portuguese+English, Swedish+English, Ukrainian, German — five independent reports). A language: ["pt","en"] or auto-detect option for transcription specifically (separate from response language) would fix all of these at once.

Strong +1 to @EscuteDentro's report — same setup, same failure, and it is a daily blocker for me. Brazilian Portuguese (language: pt), /voice in hold mode.

To be clear about what is and isn't broken: Portuguese recognition itself is fine. What is broken is code-switching, and for a Brazilian developer that is not an edge case — it is every single sentence. Our whole technical vocabulary is English: commit, merge, rebase, pull request, deploy, build, cache, endpoint, payload, hook, container, regex, log, backup, timeout, worktree. There is no Portuguese sentence about code that does not contain English words.

The tell is exactly the one described above: the English term appears correctly in the live partial transcription, and then a moment later it is retracted and rewritten as a phonetically similar Portuguese word — or as something that is simply not a word. So the STT model clearly heard it right; something downstream rejects the token because it isn't Brazilian Portuguese and "corrects" it into garbage. The result is that every technical term in the sentence comes out mangled and I have to go back and fix by hand precisely the words that carry the meaning. At that point dictation costs more than typing.

Worth flagging that the v2.1.76 change (/voice honoring the language setting) fixed the monolingual half of this issue and, for the multilingual half, made the failure structural: forcing a single language is exactly the mechanism that destroys mixed-language input. The issue is still open for good reason — see #33170, #69936, the locked #36908/#58062, and the +1s here from French, Turkish, German, Spanish, Swedish, Norwegian and Portuguese speakers. That is not a long tail; that is most of the non-English world.

Concretely, any of these would solve it:

1. language: ["pt", "en"] — an array, as originally proposed;
2. a separate transcription-only setting (voiceLanguage), so dictation language is decoupled from response language — they are genuinely different things: I want answers in Portuguese and my English technical terms transcribed verbatim;
3. at minimum, an auto option for transcription, or simply not post-processing/revising tokens that the model already emitted with high confidence.

Option 3 alone would probably fix the majority of these reports, since the raw transcription is already correct before the reconciliation step ruins it.

Please prioritize this. As it stands, /voice is unusable for the one thing a developer would use it for: dictating about code.