Dictate Code Reviews in Your Own Language

There is a quiet assumption baked into most developer tooling: the code is in English, so the developer must be too. Keywords are English. Library names are English. Error messages are English. And so, the reasoning goes, dictation for developers can be English-only and nobody will mind.

Code review breaks that assumption immediately. A review comment is not code. It is a sentence addressed to a person, and on a great many teams that person shares your first language. A Romanian team reviewing a Rust service writes Romanian comments about English identifiers. A Polish team does the same in Polish, a German team in German. The code stays English; the conversation about the code does not.

Dictation is unusually good for review comments, because review is a reading activity and typing interrupts reading. But it is only good if it works in the language the comment is actually in. This post is about making that work: which languages Keebye covers on-device, how the language pin behaves, and where the edges are. If you want the argument for why any of this matters, dictation for developers shouldn't be English-only makes it; this is the practical follow-up.

Why review comments are the ideal dictation target

A review comment has three properties that make it a better fit for voice than almost any other developer text.

It is short. Most comments are one to three sentences. That is one breath, one hotkey hold, one utterance.

It is prose. Unlike a commit message with a rigid format or a config file with exact syntax, a review comment is just how you would explain the problem out loud. "This retries forever if the socket never answers; cap it." Spoken and typed versions are nearly identical.

It happens while your eyes are busy. You are reading a diff. The moment you stop to type, you lose your place in it. Dictating lets you keep reading and speak the comment into the input box you have already clicked into.

Now add the language dimension. If your team reviews in Polish, an English-only dictation tool forces a choice: review in English (unnatural, and your colleagues may read it more slowly) or type (losing the benefit). Neither is what you wanted.

What Keebye actually supports

Two on-device engines matter here, and it is worth being exact about them.

The default engine is English-tuned. It is fast, it is the one most people use, and it is not the one you want for a Polish review comment. Pointed at non-English speech, it will produce phonetically plausible English that is not what you said.

The second engine, Canary, covers exactly 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, and Ukrainian. It is opt-in, it is downloaded once, and after that it runs offline like everything else in Keebye. Not a hundred languages; twenty-five, listed, and if yours is not on the list this post cannot help you yet.

There is also the option to use Apple's native speech recognition as the engine, which brings its own language coverage on your Mac. That is a separate path with different characteristics; the rest of this post is about Canary.

Pin the language; do not let it guess

The single most important setting for non-English review is the language pin.

Auto-detection sounds like the right default and is the wrong one for developers. Review comments are dense with English identifiers: function names, package names, the words "null" and "async" and "callback." A comment that is eighty percent Romanian and twenty percent English tokens gives a language detector exactly the mixed signal it handles worst. It will flip mid-sentence, or decide the whole thing was English, and you will get a transcript that is confidently wrong. Pin your dictation language walks through the failure in detail.

With Canary, Keebye lets you set the language explicitly. Pin Romanian and the model decodes Romanian; the English identifiers inside your sentence are handled as loanwords rather than as evidence that you switched languages. Recognition of an unusual identifier can still be imperfect, but the language itself stops being a coin flip.

One behavioural detail worth knowing: the pinned language is read for the next utterance. Change the pin and the dictation you are about to make uses it; the one you already released does not get retranscribed. In practice this means: switch, then speak. If you review in two languages across the day, the switch is cheap. The menu-bar tray exposes a shortlist of 11 languages for quick switching, and Settings exposes all 25.

A review session, dictated

Here is what a session looks like on a team that reviews in Romanian.

You open the pull request. The tray already shows Romanian pinned from yesterday, so nothing to do. You read the first file. Third hunk, a retry loop with no cap. Click into the comment box, hold Right Command, say the comment in Romanian, release. The text lands, with "um" and a false start removed by the rule-based cleanup, and the identifier reconnectSocket intact because you added it to the custom dictionary a week ago.

Next file. The comment you want to leave is a code suggestion, not prose. You type that one; dictating a diff is a bad experience in any language.

Later, a contributor from another team joins the thread and writes in English. You want to reply in English. Click the tray, pick English from the shortlist, and the next utterance is decoded as English. Reply, then switch back.

None of this needs a window. Keebye stays in the menu bar; the hotkey works in whichever app has focus, whether that is a browser tab with the review, a desktop Git client, or a terminal running a CLI review tool.

Honest limits

Twenty-five languages, not all of them. If you review in Turkish, Japanese, Arabic, or any language outside the Canary list, the second engine does not cover it. Apple's native engine may, depending on your system's language support, but that is a different engine with different behaviour.

The tray shortlist is eleven. English, Romanian, French, German, Spanish, Italian, Portuguese, Dutch, Polish, Russian, and Ukrainian are two clicks away. The other fourteen are in Settings. If your daily pair includes, say, Czech and Finnish, one side of it goes through Settings.

Identifiers are still identifiers. A speech model in any language struggles with snake_case_names. The dictionary helps with the recurring ones; the rest you fix by hand. Read the comment before you post it.

No live transcription. Canary transcribes on key release, as one batch. You will not see words as you say them. For a review comment, one to three sentences long, this is barely noticeable.

The polish is optional and literal by default. If you enable the on-device local-LLM polish, it tidies sentence structure and a fidelity guard falls back to the raw transcript when the output shows severe token loss, expansion, or repetition. That guard is a heuristic; it does not check that your meaning survived. For review comments, where a reversed negation changes the verdict, most people keep the polish off and let the rule-based cleanup do the work.

Where this fits

If the language pin is the feature you care about most, Keebye vs Wispr Flow compares the two on where speech runs and how language is handled, including where Wispr Flow fits better. For the broader case of dictation while your hands are on the diff, the developers guide covers the day-to-day, and the Mac guide covers setup.

The assumption that developers are English-only was never true. It was just convenient for the tools. Reviewing in your own language, by voice, with speech that never leaves your machine, is not a niche request. It is what a large fraction of the people writing software would do if the tooling let them.