# Multi-language product demo videos from one recording

July 18, 2026 · Demos as Code · 8 min read · https://aidemo.top/blog/multi-language-product-demo-videos/

> Localizing a demo doesn't mean re-shooting it five times. Keep one recorded take, swap the words, and do the honest math on where each locale really costs you.

**Key takeaways**

- One recording, N narration tracks, N caption sets: re-voicing turns five locales into one take plus four translation-and-voice passes, not five recordings that each rot alone.
- Speech rate ranges from ~4.3 to 9.1 syllables/sec but information rate converges near 39 bits/s (Coupé et al., 2019), so demo totals hold while individual scenes drift and need fitting.
- Coverage is not quality: OpenAI speech reaches 99 languages (voices tuned for English), ElevenLabs 29-32 (Jul 2026). Audition the specific voice per locale, not the language count.
- The screen stays English unless the app is localized: fine for dev tools, a visible seam for a consumer buyer expecting their own language.
- Translated captions expand (W3C: +30% long strings, up to 200-300% short) yet must still read at 17-20 CPS (Netflix), so QA checks meaning and reading budget together.

## The recording is language-neutral; the narration is where the locale lives

A product demo is two artifacts sharing one MP4. There is the recorded browser flow — the pixels, the cursor, the clicks, the scroll down a settings page — and there is the track laid over it: narration and captions, the same words in two forms. Only the second artifact has a language. Footage of someone filtering a table and opening a record is identical whether you explain it in English, German, or Japanese.

That split is the entire economics of localization. Treat the demo as one indivisible performance and five languages means five performances. Treat it as a recording plus a script and five languages means one recording and five scripts. The recorded flow is the costly part to produce, and the part that [goes out of date on its own the moment the UI moves](/blog/why-product-demos-go-stale). The script is cheap to translate and cheaper still to re-voice. Localizing well is mostly a discipline of never paying for the recording twice.

Say it as a matrix: one recorded take, N narration tracks, N caption sets. The recording count stays at one while the language-bearing parts multiply. Everything below is that arithmetic, plus the four places it gets complicated in real life.

## Re-record per locale, or re-voice one take

Put numbers on it. Take a 90-second, six-scene demo carrying about 225 words of narration — roughly 1,350 characters — and cost five locales two ways. "Re-record" means a person sets up, performs, and retakes the browser flow in each language before narrating it. "Re-voice" means the flow is recorded once and every locale reuses that footage, swapping only the [narration text a TTS model reads](/blog/ai-voiceover-for-demo-videos) and the caption set aligned to it. The rates below are illustrative, not a quote: a two-hour record-and-retake loop, thirty-five dollars for a reviewed translation of 225 words, two cents of synthetic speech per language.

| Per demo | 1 locale (baseline) | 5 locales, re-record each | 5 locales, re-voice one take |
|---|---|---|---|
| Browser recordings produced | 1 | 5 | 1 |
| Human record + retake time (~2 h each) | ~2 h | ~10 h | ~2 h |
| Script translations (~$35 each) | 0 | 4 | 4 |
| TTS narration passes (~$0.02 each) | 1 | 5 | 5 |
| Caption sets, auto-aligned | 1 | 5 | 5 |
| Recompose passes (compute, minutes) | 1 | 5 | 5 |
| Artifacts that rot independently | 1 | 5 | 1 |

The dollar rows barely move. Synthetic narration is cents per language and machine translation is nearly free before a human touches it. The row that moves is time, and it is human time. Re-recording pays the setup-and-retake loop once per language and leaves you holding five separate recordings, each drifting out of date on its own. Re-voicing pays for the recording once; the parts that multiply across locales are the cheap, scriptable ones, while the expensive human step stays flat. That is the practical case for treating [the demo as a committed spec](/blog/demos-as-code) instead of a captured take.

Two caveats keep this from being free money, and they are the honest core of the subject: each locale's narration runs for a different length of time, and the screen beneath it is still in whatever language your app rendered during capture.

## Different languages run on different clocks

Languages are not spoken at the same speed, and they do not pack the same meaning into a syllable. Across a corpus of 17 languages from 9 families, speech rate averaged 6.63 syllables per second but varied widely by speaker, from roughly 4.3 to 9.1, while information density ran from 4.8 bits per syllable for Basque up to 8.0 for Vietnamese ([Coupé et al., Science Advances, 2019](https://pmc.ncbi.nlm.nih.gov/articles/PMC6984970/)). The study's headline is reassuring for localizers: those two properties trade off, so information rate converges near 39 bits per second across every language measured. The same meaning takes broadly the same time to say, whatever the language.

The trouble is that a demo does not sync at the level of the whole meaning. It syncs at the moment — the click lands at 0:08, the dropdown opens at 0:11 — and translation is not length-preserving scene by scene. Translated text expands, and short strings expand most: IBM's and the W3C's localization guidance puts growth around 30% for long passages but 200–300% for strings under ten characters ([W3C, text size in translation](https://www.w3.org/International/articles/article-text-size.en.html)). A TTS voice then speaks that expanded text at its own cadence, so scene four's German narration can overrun the English it was timed against even when the demo's total runtime holds steady.

There are two honest fixes, and subtitle localizers have used the first for decades. Condense the translated line to fit the scene's fixed window, trading a little literalness for sync. Or let the window move: because the flow is a deterministic replay rather than a hand-cut clip, each scene's duration can be recomputed per locale — hold a frame a beat longer where the German runs long, trim idle time where the Japanese runs short — without retouching the recording. The polish stays a recompose, never a re-shoot.

## The screen is still in English

Re-voicing localizes the explanation, not the product. The recorded pixels show whatever language your app rendered at capture time, which is usually English, so a German viewer hears German over an English UI. Whether that seam matters depends entirely on who is watching.

It is fine more often than nervous marketers assume. Developer tools, infrastructure products, and anything whose own interface ships English-only lose nothing: the narration localizes the teaching while the UI shows the product as it actually is. Internal enablement and technical evaluators who work in English all day rarely register it. It breaks trust exactly where the product's own localization is part of the pitch — a consumer checkout, a regional compliance workflow, a claim that the app speaks the buyer's language. A prospect being sold "works in your language" while watching an English screen sees the gap at once.

When the UI has to match, there is a middle path that is not a full re-shoot. If your app supports locale switching, run the same deterministic flow again with the app set to each language. Because it is spec-driven replay, the second capture is a re-render, not a person redoing the take, so you get a genuinely localized UI at close to matrix cost. The hard limit is worth stating plainly: if the app itself is not localized, no rendering trick paints the screen in another language.

## Which languages your TTS actually speaks

The matrix assumes a voice exists for each locale, and coverage varies more than the marketing implies. OpenAI's speech models accept text in 99 languages but note that the voices are optimized for English ([OpenAI, July 2026](https://developers.openai.com/api/docs/guides/text-to-speech)). ElevenLabs voices 29 languages on its higher-quality Multilingual v2 model and 32 on the low-latency Flash v2.5 ([ElevenLabs, July 2026](https://elevenlabs.io/docs/overview/models)).

| TTS option | Languages (Jul 2026) | The catch |
|---|---|---|
| OpenAI speech models | 99 | voices are optimized for English |
| ElevenLabs Multilingual v2 | 29 | the higher-quality tier |
| ElevenLabs Flash v2.5 | 32 | low latency; adds Hungarian, Norwegian, Vietnamese |
| Self-hosted open-weight (e.g. Kokoro) | varies by voice pack | confirm the pack before you promise a locale |

Read the table for the trap: a language count is not a quality guarantee. A locale can be "supported" and still land a flat, foreign-accented read that undercuts the very trust you localized to build, so audition the specific voice you intend to ship, not the language it belongs to. When a language you need has no voice worth shipping, that one locale drops back to a human recording, which breaks the flat-human-cost property for that locale alone and is a perfectly reasonable place to spend money.

## Translating captions without blowing the reading budget

Captions inherit the same translation and one constraint the narration does not: they have to be read, in the time the scene allows, at a human reading speed. Subtitle practice has a published number for that. Netflix's English timed-text guide caps reading speed at 20 characters per second for adult programs and 17 for children's, on lines of at most 42 characters ([Netflix, English Timed Text Style Guide](https://partnerhelp.netflixstudios.com/hc/en-us/articles/217350977-English-USA-Timed-Text-Style-Guide)). A caption that fit its scene comfortably in English can breach that budget once expansion inflates it, so the translated line sometimes has to be condensed even where the audio does not.

That makes caption localization a two-part job. Machine translation drafts every locale in seconds; a native reviewer then checks two things at once — that the meaning survived, and that each cue still fits its window under the reading-speed cap. The timing itself is mechanical: captions are generated from the translated narration and [re-aligned to the audio automatically per locale](/blog/demo-video-captions), so the human spends attention on language and fit, not on stopwatch work. Skip the review and machine translation will confidently caption your product's name as a common noun in six languages at once.

## Rendering the matrix: one take, many locales

Assemble the pieces and localization becomes a render, not a reshoot. One recorded take, a reviewed translation per locale, and the pipeline emits N videos, each footage recomposition muxed to its own narration track and burned with its own caption set. Adding Portuguese is adding a row, not booking a studio.

This is where our own engine, aidemo, earns its mention: a single flag renders one recorded take into a chosen set of locales, each with translated narration and realigned captions. The disclosure owed here is the shape of the limits — aidemo runs in the browser only, the storyboard behind it is written by an agent instead of assembled by hand on a timeline, and it ships no visual editor, so a locale is tuned by editing text and re-running the render. The same [render-matrix pattern that fans one take into many languages](/blog/personalized-demo-videos-at-scale) also fans it into many prospects, which is the more valuable version of the trick.

None of this localizes what it cannot reach. The matrix makes every step downstream of the recording cheap to repeat; it does not translate an English UI, and it does not retire the native reviewer. What it removes is the thing that actually cost you — performing the same take, five times over, by hand.

## Sources

- [Coupé, Oh, Dediu & Pellegrino — Different languages, similar encoding efficiency (Science Advances, 2019)](https://pmc.ncbi.nlm.nih.gov/articles/PMC6984970/)
- [OpenAI — Text to speech guide (supported languages)](https://developers.openai.com/api/docs/guides/text-to-speech)
- [ElevenLabs — Models and language support](https://elevenlabs.io/docs/overview/models)
- [W3C Internationalization — Text size in translation](https://www.w3.org/International/articles/article-text-size.en.html)
- [Netflix — English (USA) Timed Text Style Guide](https://partnerhelp.netflixstudios.com/hc/en-us/articles/217350977-English-USA-Timed-Text-Style-Guide)

## FAQ

### Do I have to re-record my demo for every language?

No. The recorded browser flow has no language of its own, so one take can back every locale: you translate the script, generate a new voice track and caption set per language, and recompose the same footage to fit each. You only re-record when the app's on-screen UI has to appear in the local language and your product supports that, and even then a deterministic replay re-renders the flow rather than making a person perform it again.

### Will the app's on-screen text be translated too?

Only if the app itself is localized. Re-voicing swaps the narration and captions, but the pixels still show whatever language the interface rendered when you captured it, usually English. That is acceptable for developer tools and English-first products, and a problem for consumer flows where the buyer expects to see their own language. If the app supports locale switching, re-running the same recorded flow with the UI set to each language gets you a localized screen without a manual reshoot.

### How many languages can AI voiceover handle for a demo?

As of July 2026, OpenAI's speech models take text in 99 languages though the voices are tuned for English, and ElevenLabs voices 29 languages on Multilingual v2 or 32 on Flash v2.5. Breadth is not quality, so audition the specific voice for each locale before committing. For a language no model voices convincingly, that single locale is worth recording with a human.