We recorded every product demo in English for about two years. Not out of strategy, just out of habit — English was the language the team worked in, so English was the language the camera heard.
Then I pulled the signup data by country and found a pile of sessions from markets we had never recorded anything for. People were watching a demo they could not follow, getting three quarters of the way through, and leaving.
The expensive fix is re-recording with a native speaker per market. I did not have that budget. What I built instead was a subtitle pipeline, and most of what I learned had nothing to do with translation.
Localization is a distribution decision, not a post-production step
If you treat translation as the last thing that happens to a finished video, you find the real problems too late to fix them cheaply.
Three things I only noticed after the first attempt:
The demo says things the UI does not. "Click the blue button in the top right" is useless if the viewer's interface is in their own language and the words on screen are different.
Idioms do not survive. A throwaway joke in the intro reads as confusing, or worse, as rude.
On-screen text stays in the source language. Subtitles cover spoken words. They do not translate the form labels, the terminal output, or the error message you hovered over for three seconds.
Once you know those, you start writing the narration differently: shorter sentences, no idioms, and named things named the same way every time. That is a scriptwriting change, not a translation change.
Step 1: Fix the audio before you translate anything
Transcription quality is downstream of audio quality, and translation quality is downstream of transcription quality. A noisy track produces a wrong transcript, and a wrong transcript produces a translation you will spend an hour repairing line by line.
Practical things that mattered more than any tool choice:
Get the mic close. Room echo hurts far more than a slightly imperfect microphone.
Normalize levels and cut the dead air at the head and tail.
If there is music under the narration, drop it or duck it hard. Background music is the single biggest source of garbage segments in my experience.
Say the product name clearly and once. Do not rely on the model inferring it from context.
Step 2: Proofread the transcript, not the translation
This is the step that matters most, and it is the one everyone skips.
The instinct is to open the translated output and fix the strange lines there. That is backwards. Fix the source transcript first — correct the product names, the command names, the acronyms, the segments that got split in a weird place — and then translate.
Every target language inherits every mistake in the source. Ten minutes correcting English saves ten minutes per language, and it compounds if you add languages later.
If your tool gives you timestamped segments, read them against the video once before you do anything else.
Step 3: Protect the words that must not be translated
Keep a do-not-translate list next to you. Mine is short and it has saved me repeatedly:
the product name, and the company name
CLI commands, flags, and package names
environment variable names and API endpoints
file extensions and error codes
Machine translation is confident and wrong about these. I have watched a product name come back as a generic noun, and a command flag come back as a full sentence describing what the flag does. Both times the translation was grammatically fine, which is exactly why it slipped through the first read.
After the translation finishes, check every item on that list. Not skim — check.
Step 4: Respect reading speed
This is the part that breaks every language except English, and it is pure mechanics.
Working rules of thumb for subtitle cues:
Maximum two lines on screen at once.
Roughly 32–42 characters per line.
Reading speed around 15–20 characters per second.
Here is a cue that looks completely fine in English:
1
00:00:04,120 --> 00:00:07,480
Now we'll add the webhook endpoint to the config file.
That is 52 characters over 3.36 seconds, about 15.5 characters per second. Fine.
Now translate that into German or Finnish and the same sentence expands by a third. Same timing, more text, and suddenly the viewer has to read at 24 characters per second to keep up. They will not. They will miss a line, lose the thread, and close the tab.
Two fixes, and you will use both:
text
1
00:00:04,120 --> 00:00:06,200
Now we'll add the webhook endpoint
2
00:00:06,200 --> 00:00:08,900
to the config file.
Splitting the cue costs nothing and reads comfortably. Shortening the sentence costs a little precision and reads comfortably. Leaving it long costs you the viewer.
If you can, have someone read a couple of cues aloud in the target language and time them. That is the whole test.
Step 5: Ship the subtitle file and the translated audio separately
These are two artifacts for two different situations, and you want both:
A subtitle file for people watching muted on a phone in public.
A video with translated audio for people who would rather listen than read.
Do not burn the subtitles into the only copy you have. Keep a soft-subtitled version, because you will want to re-export after someone finds a typo.
Two commands I use constantly:
bash
burn subtitles into a separate copy (hard subs)
ffmpeg -i demo.mp4 -vf subtitles=demo.srt demo-hardsubs.mp4
keep subtitles as a switchable track instead
ffmpeg -i demo.mp4 -i demo.srt -c copy -c:s mov_text demo-with-track.mp4
And on the web, ship them as tracks rather than baking them in:
html
Users can switch languages, and you can fix one file without re-encoding video.
The things that actually broke
Every one of these cost me an export:
UTF-8 with a BOM. Some players show garbage, some show nothing. Save as UTF-8 without BOM.
SRT and WebVTT timestamps are not interchangeable. SRT uses a comma before the milliseconds — 00:00:01,000. WebVTT uses a dot — 00:00:01.000. Mixing them produces cues that silently fail to render.
Auto-detect language misfires. Accents, music, or a video that switches languages partway through will confuse it. Name the source language explicitly every time.
Comments arrive in a language you do not read. Decide before you publish whether you will reply with help, reply in English, or not reply. Silence is a legitimate choice; pretending you understood is not.
The first comment is usually about something you got wrong. That is the most valuable feedback channel you just opened. Watch it.
Where an AI video translator fits
This is the part people ask about, so let me be specific about what it does and does not do for me.
I run the first pass through an AI Video Translator. It handles the timed transcription and the subtitle translation, and the reason I keep using it is not the translation — it is that I can review and correct every segment side by side against the original before I export anything. That review step is where the quality actually comes from.
The other thing I care about: it exports the subtitle file as well as the finished video. So the SRT goes into the repo next to the code, gets reviewed in a pull request like any other file, and can be fixed without touching the video. There is no account needed for a quick pass, which matters when I am only trying to decide whether a market is worth a real localization effort at all.
What it does not do: it does not make the demo better. A confusing demo in five languages is a confusing demo. It makes the demo visible to people who would not have watched it — and visibility was the problem I actually had. Those are different problems, and it is worth knowing which one you are solving.
If you take two things from it, take the CPS check and the transcript-first rule. The commands and the character-per-second figures are worth verifying against your own files before you rely on them — subtitle tooling disagrees at the margins, and your audience is the only one who can tell you whether a cue was readable.
The demos were never the bottleneck. The assumption that English was the default was.
Top comments (0)