← Blog · 24 September 2026 · Lire en français

French text to speech: reading code and technical snippets

getUserById, max_retries, config.json, npm install, v1.2.3: a technical blog is full of strings nobody pronounces the way they are spelled. What a synthetic voice does with them, what to spare it, and how to mark code so it reads right.

A serious article about software mixes two languages in the same paragraph: prose, made to be read aloud, and code, which is not. "Open config.json and set max_retries to 3" reads effortlessly for a human, because they know you do not say "config dot j s o n" as if it were a word. A synthetic voice has no such reflex: it meets a string of characters and tries something. Sometimes it spells, sometimes it invents a pronunciation, sometimes it swallows half of it. The result is audio that stumbles on every technical term, and that is exactly where an expert reader tunes out.

The table of forms that trip up the voice

| Written form | Reasonable reading | Common error |
|---|---|---|
| config.json | config dot jason | "config dot j s o n", "config jissonn" |
| getUserById | get user by id | "gett-you-zer-by-dee" read as one block |
| max_retries | max retries | "max underscore retries" |
| /usr/local/bin | slash u s r slash local slash bin | "user local bin" run together |
| MAX_SIZE | max size | "m a x underscore s i z e" |
| npm install | npm install | "n p m" spelled, then a mangled "install" |
| v1.2.3 | version one point two point three | "v one comma two comma three" |
| .env | dot env | "dot e n v" spelled out |
| a === b | a triple equals b | "a equals equals equals b" |
| () => {} | arrow function | character-by-character reading of the symbols |

The middle column is not an official standard: it is what a developer says spontaneously when reading their code aloud to a colleague. A voice that gets close stays listenable; a voice that spells everything turns a tutorial into a string of letters.

Why a machine loses its way

A neural voice predicts pronunciation from what it saw in training, and what it mostly saw is natural language. Faced with "getUserById", it has no model of camelCase: it sees an unknown word and tries a whole-word pronunciation, often with an approximate English accent. The underscore in "max_retries" does not exist in speech, so the voice either names it ("underscore") or glues the two words together. The dot in "config.json" is sometimes a full stop, sometimes an extension separator: nothing in the character settles it.

It is the same problem as with URLs and email addresses, and it follows the same idea, the one behind the French text to speech page: what matters happens before the sound, in recognising and rewriting the text for the voice. Code is the extreme case, because it carries almost no meaning when spoken: reading it character by character is faithful and useless at the same time.

What WeDispatch does about it, without over-promising

The stance is simple and it owns itself: an article audio player is made to read prose, not to recite a code repository. A whole code block is not meant to be read aloud, and forcing it would produce audio nobody finishes. So the right practice is to treat code as code, apart from the sentence that comments on it, exactly the way you treat the typographic noise that should not be read.

For the short technical terms that recur in your prose (a product name, a command, an extension you keep citing), the pronunciation lexicon lets you fix the expected reading once and for all: declare that ".env" is said "dot env" and not "dot e n v", and the setting holds across all your articles, with nothing to regenerate. That is the honest lever: it does not pretend to guess your code, it lets you decide for the cases that matter on your site.

The writing habit that fixes almost everything

Write for the ear inside the sentence, and keep the literal for blocks. Rather than "set max_retries to 3" in a sentence meant to be heard, prefer "raise the retry count, the max_retries setting, to three", giving the meaning before the token. The hurried listener hears the idea, the technical reader finds the exact term on screen. And when a passage is made to be copied, not heard (a full command, a configuration excerpt), it is better off living in a real code block: the eye spots it, and the audio does not try to say it. A listen-through before publishing will tell you in a minute which terms stumble on your site, and which ones deserve a lexicon entry.

Give your articles a voice with WeDispatch

This blog is itself voiced by WeDispatch. Curious how it sounds on your content?

Book a demo

Read next