Voice input: choose the dictation language (iPhone, and the same on desktop)

[nicolaeser]

Problem

The microphone button in the T3 Code composer on iPhone always transcribes in a language the app picks. There is no way to choose it. This is about the app's own voice input, not the iOS keyboard dictation.

The language you speak to a coding agent is often not your phone's system language. A German speaker with a German iPhone may dictate prompts in English because the code, issues, and commands are English, and switch back to German for other projects. The reverse happens too. Any automatic choice gets one of these cases wrong, and the result is not a slightly worse transcript. The speech is run through the wrong model and comes out as unrelated words (see #12743).

On main (5307c23), voiceTranscription.ios.ts binds the transcriber to Intl.DateTimeFormat().resolvedOptions().locale, and nothing in the mobile preferences overrides it.

#13312 fixes the default by following the device's preferred languages. That is the right default, but it still can't help when the dictation language differs from the device language.

Proposal

Add a Language option to the existing voice input / microphone settings in the iPhone app:

• Automatic (default): keeps whatever the default is (today's behavior, or the preferred-languages fallback once fix(mobile): transcribe voice input in the user's language #13312 lands).
• An explicit language: picked from the locales Apple's on-device transcriber supports on this device. The chosen locale is used when the recording's transcriber is prepared.

Recording, insertion at the caret, and "never auto-send" stay unchanged. Everything stays on-device, with no API keys and no cloud transcription.

Possible follow-up, not part of this ask: a quick switch from the mic control for people who regularly alternate between two languages.

Desktop

I'd also like this on desktop. Voice input is iPhone-only today, and desktop and web voice input are tracked separately in #10489 and #14814. I'm not asking to bundle desktop voice into this. My ask is that when voice input reaches desktop, it offers the same language choice. It would help if the iPhone setting were designed so desktop can reuse it rather than as an iOS-only special case.

Scope

This is a configuration option for an existing capability. It only chooses the transcription language for the on-device voice input that already ships. #17692 implemented roughly this and was closed with the suggestion to discuss the override in Ideas, so this is that discussion. #15422 bundled the same setting with a custom transcription service (BYOK). That was declined, and this request deliberately leaves BYOK out.

Related

• [Bug]: iPhone 1.2.0 voice input recognizes Korean speech as unrelated English words #12743: bug, non-English speech transcribed with the English model (accepted)
• fix(mobile): transcribe voice input in the user's language #13312 / iOS voice input transcribes non-English speech with the English model #13313: fixes the default via the device's preferred languages; iOS voice input transcribes non-English speech with the English model #13313 lists this setting as a follow-up
• feat(mobile): choose the language for iPhone voice input #17692: closed PR that added this setting
• Mobile voice input: language config + BYOK #15422: closed discussion (language setting + BYOK)
• [Feature]: Chinese (zh-CN) speech recognition and desktop composer voice #10489: desktop composer voice (+ zh-CN)
• Voice input in the web composer, using the browser's speech recognition #14814: web composer voice via browser speech recognition

Note

Written by Claude (claude-opus-5-5) running as an agent in T3 Code, on behalf of @nicolaeser. The agent checked the current code on main and searched existing issues and discussions before posting.

[MikaMcFlurry]

I built the iPhone part of this in a fork: mika/dictation-locale.

• Settings → Microphone gets a Dictation language picker: Automatic (device language, the default), plus explicit locales (de-DE, en-US, en-GB, es-ES, fr-FR, it-IT, pt-BR). It is stored in mobile preferences and every recording uses it.
• Transcript spacing in client-runtime/voice-input/controller.ts only applied to English locales. It now applies to every space-separated language (\p{L}\p{N}), excluding unspaced scripts (ja, zh, th, …).
• Tests cover the spacing cases and the preference decoding. Typecheck and check:changed pass. It has not run on a device yet.

The desktop half isn't covered. If a maintainer wants this, I can open a PR.

Written with Claude Opus 5.5 in Claude Code (running in T3 Code).

[MikaMcFlurry]

Update: #25808 now covers most of my earlier comment. Voice input follows the iPhone's preferred languages in order, and word spacing works for every language that uses spaces. I dropped my version of both.

What's left is the explicit choice this idea asks for. Many people keep their iPhone in English but dictate in German, or the reverse. mika/dictation-locale-on-25808 is one commit on top of #25808:

• Settings → Microphone → Dictation language: Automatic (the default; it uses fix(mobile): voice input keeps your edits, your first words, and your language #25808's preferred-language order), or one fixed locale.
• A fixed locale is used on its own, with no silent fallback, so an unsupported choice shows the existing "does not support this language" error.
• Stored in mobile preferences, with tests for decoding and the default.

I can't verify it on a physical iPhone from here. If you'd take it as a configuration option once #25808 lands, I'll open it with simulator screenshots of the setting.

[jokaperes]

#29689 implements the iPhone part of this: Settings → Microphone → Dictation language. Device language stays the default, and the other rows are the locales Apple's on-device transcriber supports.

It's #26725 by @gabrielsch rebased onto current main, plus the device evidence that PR was closed without. I tested it on an iPhone 17 (iOS 27). With English (US) selected, only English is transcribed. With Português (Brasil) selected, Brazilian Portuguese comes out correctly. The choice is still selected after force-quitting the app. It doesn't depend on #25808. That PR fixes the default, and this one lets you override it.