anthropics / anthropics/claude-code

[BUG] Desktop dictation: live transcript is correct Latin script, but finalization rewrites the whole paragraph into Devanagari

Open
#95,510 2 comments 0 reactions 0 assignees View on GitHub
area:desktop bug platform:windows
Dominant language
TypeScript
Stars
146k
Forks
23.8k
PR merge metrics
PR metrics pending

Description

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

When I dictate Urdu using the microphone button in the Claude Code desktop app's chat input, the **live streaming transcript is correct** — it appears in Latin script (Roman Urdu), which is what I want.

The moment I stop dictation, the **finalization step rewrites the entire paragraph into Devanagari (Hindi script)**.

So the speech recognition itself is working. Something in the post-stop finalization/commit pass re-renders the already-correct transcript into a different script and discards what was streamed.

Context: I speak Urdu. Urdu is not among the 20 supported dictation languages; Hindi is. Urdu and Hindi are near-identical in speech and differ mainly in script, so the recognizer appears to detect Hindi and the finalization step renders it in Devanagari.

This looks related to #78682 (dictation ignoring the language setting) and #94755 (macOS dictation misrecognized as English), but the symptom here is narrower and points at a specific stage: the streamed text is right, only the committed text is wrong.

### What Should Happen?

Stopping dictation should commit the transcript that was already displayed during recording — in Latin script.

The finalized text should match what was streamed, not be re-rendered into a different writing system.

### Error Messages/Logs

```shell
No error is shown. A dictation event recorded in the desktop app's own Local Storage shows English being sent as the language, so the client side looks correct:

"area":"code", "input":"session", "language":"en-GB",
"activation":"tap", "connected":true, "backend":"pcm", "outcome":"committed"

The strings `hindi`, `hi` and `devanagari` do not appear anywhere in the app's storage.
```

### Steps to Reproduce

1. Open the Claude Code desktop app (Code tab) on Windows.
2. Click the microphone button in the chat input.
3. Speak several sentences in Urdu (or Hindustani).
4. **While still speaking, watch the input box** — the text streams in correctly, in Latin script.
5. Stop the dictation.
6. The entire paragraph is replaced with the same content written in Devanagari.

Step 4 is the important one: the bug is only visible if you compare the text during recording against the text after stopping. Reproduced in both tap mode and with the mic button; no special configuration is needed.

### Claude Model

None

### Is this a regression?

I don't know

### Last Working Version

_No response_

### Claude Code Version

Desktop app 2.2553.1 (the CLI is not installed on this machine, so `claude --version` is unavailable)

### Platform

Anthropic API

### Operating System

Windows

### Terminal/Shell

Other

### Additional Information

### What I ruled out before filing

- `~/.claude/settings.json` — no `language` key was set. Setting `"language": "en"` **does** take effect for Claude's reply language (replies switched to English immediately), but made no difference to the dictation result.
- `~/.claude.json` — no `language` or `voice` key.
- Project-level `.claude/` — does not exist for this project.
- The desktop app's own Code-tab settings — **no language or dictation key is exposed at all** (only archiving, notifications, branch prefix, keep-awake, output style).
- The app's Local Storage — holds `"language":"en-GB"`.
- Windows input languages — only `en-US` is installed.
- The microphone dropdown has **no language picker**, only microphone device selection.

So there is no misconfiguration on this machine to correct: the client reports English, and the finalized transcript still comes back in Devanagari.

### Impact

There is no setting that fixes this, and the settings reference exposes no option for transcript finalization, post-processing, translation, streaming-only mode or raw transcript access. The only workaround is to abandon Claude Code's dictation and use the operating system's own voice typing.

### Suggested area

The finalization / commit pass that runs after recording stops, rather than the streaming recognizer — since the streamed text is correct and only the committed text is wrong.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start at the desktop app microphone button's post-stop finalization/commit pass, comparing its output with the streamed transcript. The issue mentions the Local Storage dictation event and the `language` value `en-GB`; done means stopping dictation commits the already-streamed Latin-script text without rewriting it into Devanagari. No source files or tests are named.

Written by the indexing model from the issue text.

Assessment

Domain
desktop
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.