Blog

Compare two subtitle drafts for a code review

Compare two subtitle drafts in your browser, spot changed wording and timestamps, and check that every edit preserves meaning before approving a code review.

Rachel BennettTools and utilities 4 min read

You have two versions of subtitles for a code review, but the changes are hard to track by eye. A small wording edit can alter a technical explanation, while an accidental timestamp or cue change can make subtitles appear too early or too late.

Use a text comparison to locate the differences first. Then review changed lines in context, especially code terms, filenames, and timing information, before accepting the new draft.

Compare the subtitle drafts

  1. Open Text Compare. Keep the original draft separate from the revised draft so you can check each change against the version it came from.
  2. Paste the earlier subtitle text into one side and the newer version into the other. If you are working with files, open each file and copy its text without changing its format first.
  3. Review the highlighted or listed differences from the beginning. Check changed words, punctuation, cue boundaries, and timestamps rather than judging the draft by its overall appearance.
  4. For each difference, decide whether it is an intended correction, a formatting-only change, or an accidental edit. Make a note of unresolved lines for the code review instead of silently choosing one version.

Compare the full subtitle files when the review includes timing, cue order, or formatting. If you only want to review the spoken wording, you can also compare text with timestamps removed, but keep the original files unchanged for a separate timing check.

What the differences mean

Only a few words or punctuation marks changed

This is usually an editorial revision. Confirm that the new wording matches what the speaker says and does not change the technical meaning. In a code review, pay close attention to identifiers, file extensions, command names, and phrases such as “does not” or “only if.” A single character can make a code term or instruction wrong.

A whole cue appears different

The lines may have been split, joined, or moved, even if most of the words are the same. Check the surrounding cues and listen to the matching part of the recording if you have it. A comparison tool may show a moved line as a removal in one place and an addition elsewhere, rather than recognizing it as a move.

Timestamps or cue numbers changed

These edits affect subtitle structure, not just wording. Confirm the cue still appears during the speech it describes and that the sequence remains in order. A changed timestamp may be intentional to improve synchronization, but a broad set of timestamp changes can also indicate that unrelated formatting or timing was modified.

Many lines show changes even though the text looks the same

The files may use different line endings, blank lines, spacing, or encoding. Those differences can create noise in a text comparison. Do not assume the wording is unchanged until you check the affected lines and the file format.

No differences appear

The drafts may be identical, or the same version may have been placed on both sides. Check the first and last lines of each input and confirm that you selected the intended files. If you removed timestamps or formatting to focus on wording, remember that this comparison cannot confirm those parts match.

How to resolve confusing changes

  1. Check that you compared the right versions. Look at the opening and closing cues in both drafts and verify the filenames or version notes. Comparing a draft against itself can look like a clean result even when you meant to review another file.
  2. Ignore formatting only when it is truly irrelevant. Blank lines and line-ending changes may not affect what viewers read, but cue breaks and timestamps do. Keep the full-file comparison available so you can distinguish harmless formatting differences from subtitle changes.
  3. Check each changed cue against the audio or video. Read the line while listening to the matching moment. Restore words that were omitted, and confirm that added text is actually spoken or is an approved on-screen description.
  4. Verify technical names character by character. Compare variable names, filenames, commands, and punctuation against the code or the review notes. Do not rely on spellcheck for code terms, since it may replace a valid name with an ordinary word.
  5. Review the subtitle structure after editing. Check cue order, blank lines, and timestamp syntax in the file. For example, an SRT timestamp commonly uses a comma before milliseconds, while WebVTT uses a period. Do not convert one format to another as part of a wording review unless that conversion is required.

Keep wording review separate from timing review

Subtitle formats store more than the words viewers see. An SRT file can contain numbered cues followed by start and end times, while a WebVTT file begins with a WEBVTT header and uses its own timestamp conventions. A plain text comparison sees these as characters and lines. It does not know whether a cue is synchronized correctly or whether a line is easy to read on screen.

For a cleaner review, use one comparison for the complete files and a separate wording-only comparison if timestamps distract from copy changes. When you make corrections, apply them to the working subtitle file, then compare the revised file again with the original to make sure only the intended changes remain.

If the subtitles contain unreleased code, customer information, or private review comments, remove those details before pasting text into any tool that is not approved for that material.