Why Dictation for Developers Shouldn't Be English-Only

There's a lazy assumption baked into most developer tooling: because code is written in English keywords, the developer must be working in English. Anyone who has actually worked on a team in Bucharest, São Paulo, Warsaw, or Kyiv knows how wrong that is.

Yes, the function is called getUserSession and the commit message is probably in English. But look at everything around the code: the Slack thread where the bug got reported, the message to the client explaining the delay, the internal doc describing the migration plan, the code review comment that needs diplomacy, the standup notes. On enormous numbers of teams, that entire layer happens in the team's own language — and it's most of the natural-language output of a developer's day.

Dictation tools, meanwhile, have mostly treated non-English speech as an afterthought: technically supported somewhere in a settings menu, rarely designed for, almost never the headline. If dictation is going to be a real input channel for builders — not a demo — it has to work in the language you actually think in.

The bilingual workday is the normal workday

Here's the texture of it, familiar to most developers outside the anglosphere: you think in your native language, code in English, and context-switch between the two hundreds of times a day. A Romanian developer writes retryWithBackoff, then turns to Slack and explains in Romanian why the retry logic needed a backoff at all. A German engineer reviews a PR in English syntax and annotates it in German prose.

Typing handles this bilingualism fine, because keyboards don't care what language you type. But the moment you add voice, the tool suddenly does care. If your dictation only works well in English, you can dictate the code-adjacent English fragments, but none of the messages, docs, and explanations that make up the bulk of what you'd actually want to dictate. The tool serves the smaller half of your output.

This gets sharper in the parallel-agent workflow we've written about in driving Claude Code with your voice. If your voice is the control channel for several lanes — prompting an agent in one window, answering a colleague in another — then a dictation tool that stumbles outside English breaks exactly half of your lanes. The agent prompt works; the reply to your teammate doesn't.

What Keebye actually does about it

Claims about language support are where dictation marketing gets fuzzy, so here is precisely what Keebye implements today — no more, no less.

The default engine is English-tuned. We're not going to bury that. The out-of-the-box model is optimized for fast, accurate English dictation, because it's the smallest good default and many users need nothing else.

The multilingual engine is a first-class option, and it's local. Switch to the Canary engine in settings and you get on-device speech-to-text in 25 languages: Bulgarian, Croatian, Czech, Danish, Dutch, English, Estonian, Finnish, French, German, Greek, Hungarian, Italian, Latvian, Lithuanian, Maltese, Polish, Portuguese, Romanian, Russian, Slovak, Slovenian, Spanish, Swedish, Ukrainian — with a language picker to pin the one you work in. Like everything in Keebye, it runs on your Mac: the audio of you talking to your team in your own language never leaves the machine, and it keeps working offline once the model is downloaded.

Apple's native engine is there too. If you'd rather use the speech recognition already built into macOS — which works in your system language — Keebye can use that instead, with no model download at all.

Your jargon comes along. The custom dictionary applies regardless of engine, which matters more in multilingual work, not less — every team develops its own creole of product names, English loanwords, and local grammar wrapped around them.

And the honest boundary: 25 languages is 25 languages, not "every language." If yours isn't on that list, Keebye's multilingual engine doesn't cover you today, and we'd rather say so than round up to a marketing number.

Why this is rare, and why that's an opportunity

Local-first multilingual dictation is genuinely uncommon. Cloud dictation products tend to have the widest language lists — sending audio to big server-side models is the easy way to add languages — but that routes your speech through someone else's infrastructure, which is exactly what some teams can't accept. We laid out that trade-off honestly in Keebye vs Wispr Flow. Local-first tools, on the other hand, have historically led with English and treated other languages as a checkbox. (Superwhisper users weighing the same question can read our comparison.)

The result is a strange gap: the developer who wants to dictate in Polish and keep audio on their own machine has had almost nowhere to stand. That gap covers most of the world's developers and most of their daily output.

It's also personal. Keebye's founder story — two kids, three startups, one voice — happens to be the story of a Romanian-speaking builder working with international startups: the exact bilingual split this post describes, lived daily. The multilingual engine isn't a feature we added for a market. It's a feature the founder needed by lunchtime.

Where this goes

Our bet is simple: voice input for builders will be judged the way keyboards are — it either works in your language or it's broken. "English plus an asterisk" won't survive contact with real teams.

If you work in one of those 25 languages, Keebye's early-access builds are on GitHub releases. Switch the engine to Canary, pick your language, and dictate the next Slack reply the way you'd actually say it — then tell us what broke, in whichever language you prefer.