The problem it solves
A subtitle file rarely stays unchanged. A writer drafts it, a reviewer corrects it, a client asks for different wording, and the video itself may be re-edited. Within days there can be several copies with similar names, and nobody is sure which is current. The usual consequences are modest but irritating: a corrected spelling reappears, a late fix is lost, or an outdated file is published.
Version control means keeping an orderly history so you can tell what changed, who changed it, which version was approved and how to go back if needed.
Start with naming
The cheapest and most effective habit is a consistent file name. Include:
- the project or video identifier
- the language
- a version number, increasing each time the file changes in a meaningful way
- a status word such as draft, review or approved
A hypothetical example is webinar-intro_de_v3_review.srt. Avoid names such as final, final2 and really-final, which stop meaning anything quickly. Do not edit a file and keep the same name, since you lose the ability to tell the copies apart.
Separate working files from approved ones
Use folders to show state. A common arrangement has a working folder for drafts, a review folder for files awaiting checking, an approved folder for signed-off versions and a delivered folder for what was actually sent or published. Moving a file between folders makes the status visible without opening it.
Keep earlier versions instead of deleting them, perhaps in an archive folder. Storage is cheap, and an old version is sometimes exactly what is needed to restore a lost line.
Record what changed
A short change note is worth the effort. It might be a line in a log or a note stored with the file: the version number, date, who made the change and a summary, such as “retimed cues 40 to 85 after new intro” or “corrected name spellings from glossary”. When something goes wrong later, the log shows where to look.
For larger changes, it can help to compare two versions directly. Many text editors and comparison tools can display differences between two files. Because subtitle formats are plain text, such comparisons work well on them, showing changed wording and changed timecodes line by line.
Know which master each file belongs to
Subtitle files depend on the video. A file timed to one cut will be wrong for another. Record which version of the video each subtitle version matches. This matters most after a re-edit, when the cues may need adjusting, and in multilingual work, where each language should state which version of the source it was built from.
Decide who may change what
Confusion often comes from two people editing at once. Simple rules help:
- Only one person edits a given file at a time, or each person works on a separate copy that is merged later.
- A reviewer returns comments or a new numbered version, not an edit over the original.
- Only a named person approves, and approval is recorded.
- After approval, the file is treated as read-only. Further changes make a new version.
Where a shared drive or collaboration tool supports locking or check-out, use it. Some tools keep their own history automatically, which is useful but should not replace your own record of which version was approved.
Using proper version control software
Software built for tracking changes to text files can be used for subtitle files, and it suits teams with technical comfort and many contributors. It records every change with a message, supports branches for experiments and can show who changed which line. The cost is a learning curve, and some team members may not want to use it.
For many teams a well-organized shared folder with disciplined naming is enough. A reasonable approach is to start simple and move to dedicated software only when the simple method starts to fail, for example because many people edit many languages at once.
Handling several languages
Each language file is a separate document with its own history, so apply the same rules to every one. A tracking sheet listing the current version, status and matching source version for each language prevents mistakes, as described in managing many languages in one project. When the master changes, every language gets a new version, even if only to confirm that nothing in it needed changing.
Be careful with formats and encoding
Saving a file in a different format or with different settings can change it in ways that are not obvious. Opening and re-saving in a program may alter line endings, styling data or character encoding, and accented or non-Latin characters can be corrupted. Keep the original working format as your master, and export other formats from it rather than editing the exports. Check each export before delivery.
A minimal routine
- Name every file with project, language, version and status.
- Never overwrite an approved file; save a new version.
- Keep working, review, approved and delivered files apart.
- Write a one-line note with every change.
- Record which video version each subtitle version matches.
- Store the delivered files, so you know exactly what viewers saw.
Done consistently, these habits make errors rarer and easier to undo.