Why free subtitle translators quietly lose half your dialogue

The first version of this translator lost the second line of every multi-line cue. Not occasionally — every single one. In a typical episode that was about 44% of all cues, and the output still looked plausible enough to ship.

How it happens

Cues were sent to the model as tab-separated rows: an id, a tab, the text. That is a perfectly ordinary way to move data around, and it works until the text itself contains a newline. Subtitle text contains newlines constantly, because a line break is how a subtitle separates two speakers or splits a sound label from dialogue.

So a two-line cue became two rows. The first row parsed as the cue. The second row had no tab in it, so it was discarded. No error, no warning — the line was simply gone.

Why nobody notices

This is the part worth dwelling on. A file missing half its second lines still has the right number of cues, correct timings and valid formatting. It opens in any player. Every cue that remains is a real translation of a real line. If you cannot read the target language you have no way to know, and if you can, it reads as though the show is oddly clipped.

The fix, and the check that keeps it fixed

Cues now travel as a JSON object of id to text. Newlines are legal inside a JSON string, so there is nothing to lose. That is the entire fix — it is not clever.

The part that matters is the test. There is now a case that translates a multi-line cue and asserts both lines come back. It fails if anyone ever reaches for a line-delimited format again, which is exactly the kind of change that looks harmless in review.

This is why the validation gate exists at all. Not because a model writes bad prose, but because the pipeline around it can lose text without anything appearing wrong.