Bilingual Subtitles: Two Languages in One Caption
Two subtitle files never share cue boundaries, so pairing by line number drifts. Match on time overlap, and expect stacked captions to fill the line budget.
Showing two languages at once is a common request: a local language for the audience and English for everyone else, stacked in the same caption. It sounds like a job for pasting one file under the other. It is not, and the reason is worth understanding before you try, because the failure is quiet.
The two files do not line up
Two subtitle files for the same video almost never share cue boundaries. A translator splits a sentence where the grammar of their language wants a break, which is rarely where the original broke. So cue three in one file is not cue three in the other, and pairing them by position drifts further apart with every mismatch until the languages are describing different moments.
Matching has to be done on time, not on order. Here two Roman Urdu cues fall inside the span of one English cue:
English 00:00:01,000 --> 00:00:04,000 We tried three cameras this week.
Urdu 00:00:01,000 --> 00:00:02,400 Hum ne teen camere test kiye.
00:00:02,400 --> 00:00:04,000 Is hafte.
merged 00:00:01,000 --> 00:00:04,000
We tried three cameras this week.
Hum ne teen camere test kiye. Is hafte.Each cue from the second file attaches to whichever cue of the first it overlaps most. Where two land on one, they are joined rather than one of them being dropped.
One file has to be the timing spine
Something has to decide when the merged cue starts and ends, and it should be a deliberate choice rather than whichever file you happened to load first. Use the language your audience primarily reads, since that is the track whose pacing should feel right. The second language then fits around it, occasionally joined, occasionally sitting slightly early or late against its own natural break. That compromise is unavoidable, and it is better than the alternative of two tracks quietly diverging.
Stacked captions use the whole line budget
This is where bilingual subtitles usually go wrong visually. A caption is conventionally at most two lines. A bilingual caption spends both of them immediately, one per language, and there is nothing left for wrapping. So any line that runs long does not wrap, it overflows into a third line and pushes the caption up the frame, or the player truncates it.
That makes the length limits stricter, not looser, and the merged example above is exactly the risk: two cues joined onto one line is the longest line in the file. Check the joined ones first. The limits themselves, and what a tool is really counting when it applies them, are in subtitle character limits. If both languages are romanised, expect the lines to run longer again than the same words in their native scripts.
Reading speed is the real constraint
A viewer reading a bilingual caption reads only their own language, so the characters-per-second figure that matters is for one language, not the pair. But the cue duration is now shared. If the timing spine was cut for a language that says the same thing in fewer syllables, the other language can end up genuinely unreadable in the time available. This is the thing to check on a real playback rather than in the file, and subtitle reading speed covers how to measure it.
Often you should not merge at all
Bilingual subtitles are the right answer when the caption has to be burned into the video, or when the platform shows only one track. When the platform supports multiple subtitle tracks, and YouTube does, shipping two separate tracks is better in every way that matters: each viewer reads one language at full size, neither is compromised by the other's timing, and you can fix one without touching the other. Merge because the destination forces it, not because two languages are wanted.
A short checklist
- Decide which language is the timing spine before merging.
- Match on time overlap, never on cue number.
- Find the cues where two were joined, and check those lines for length.
- Play it back and read the slower language, not the faster one.
- Ship two tracks instead if the destination supports them.
The subtitle merger does the overlap matching, keeps cues that pair with nothing rather than dropping them, and tells you which cues were joined so you know where to look. If you do not have the second language yet, the subtitle translator produces it from a reviewed track, and the caption generator produces the first one from the video.
Quick answers
Why can I not just paste one subtitle file under the other?
Because two files for the same video almost never share cue boundaries. A translator breaks a sentence where their grammar wants it, not where the original broke, so cue three in one file is not cue three in the other. Pairing by position drifts further apart with every mismatch.
How should two subtitle files be matched?
On time overlap. Each cue from the second file attaches to whichever cue of the first it overlaps most, and where two fall inside one they are joined rather than dropped. One file should be chosen deliberately as the timing spine, normally the language the audience primarily reads.
Should I use bilingual subtitles or two separate tracks?
Two tracks whenever the destination supports them, which YouTube does. Each viewer then reads one language at full size and neither is compromised by the other’s timing. Merge only when the caption is burned in or the platform shows a single track.