Version Control for Video Scripts and Translations

When you dub a video, the script becomes the source of truth. Every language tracks back to it. Change the English script after publishing the German dub, and now you have a mismatch nobody noticed until a comment points it out.

Version control for multilingual scripts is not git with branches and pull requests. It is a naming system and a file structure that makes it impossible to edit one language's version while another is still processing, and makes it obvious what was changed and when.

Name scripts by date and state, never by language

The worst naming approach: script-spanish.doc, script-french.doc, script-final.doc. You will lose the plot in three videos.

Better: video-42-script-v2.1-2026-11-15.doc. This tells you:

• Which video it belongs to (42)
• What it is (script)
• What version (2.1, meaning version 2 revision 1)
• When it was written or last locked (2026-11-15)

The version number matters. v1 is the first locked script sent to translation. v1.1 is a typo fix after translation started but before publishing. v2 is a full re-edit after the video was published. Any tool reading the file name can instantly know how new it is and whether translators have already worked on it.

Do not embed the language in the script name. The script is in English. Translations are separate files. Call them video-42-translation-es-v2.1-2026-11-15.doc.

Store scripts in a single folder, not scattered

Put every script in one place:

/scripts
  /video-42
    video-42-script-v1-2026-11-09.doc
    video-42-script-v1.1-2026-11-10.doc (typo fix)
    video-42-script-v2-2026-11-15.doc (re-edit after publish)
    video-42-translation-es-v1-2026-11-11.doc
    video-42-translation-es-v2-2026-11-16.doc
    video-42-translation-de-v1-2026-11-11.doc
    video-42-translation-de-v1.1-2026-11-12.doc

Keep a spreadsheet or a README.txt at the top level showing which translation is used in which video. This is your deployment record:

Video 42 - Published State

English: video-42-script-v1
Spanish: video-42-translation-es-v1 (published 2026-11-12)
German:  video-42-translation-de-v1 (published 2026-11-12)

When you re-edit the English script, you update the spreadsheet and mark the Spanish and German lines as "needs revision". Do not allow uploading a new dub until you have confirmed the translators have seen v2 and validated that the timing still works.

Name translators and reviewers as owners

If a translator claims "I will fix the French version", know who you are counting on. Add initials to the file name:

video-42-translation-fr-v1-jd-2026-11-11.doc

jd are the reviewer's initials. When you ping them a week later with "is this done?", you are not asking a ghost. You know exactly who signed up.

Alternatively, add ownership to your version control spreadsheet:

The spreadsheet is the system of record. Names matter. Email addresses matter more than initials because Slack handles get cycled. Store emails.

Freeze scripts before translation starts

Announce: "Spanish translation starts today. English script is now frozen until further notice."

Do not change it. If you need to fix a typo mid-translation, create a documented exception. Note it clearly:

video-42-script-v1-frozen-until-2026-11-15.doc video-42-script-v1.1-hotfix-typo-2026-11-15.doc

Ping the translator: "We found a typo on line 12. Updated version is v1.1. Do you need to re-translate that part?"

Do not silently change the script and assume they saw it. Translators work from static files. They do not watch a folder for changes.

After re-editing, keep the old file

Never delete an old script version. Keep all of them. They are your audit trail.

When you re-edit a video after it has been published, create a new version:

• video-42-script-v1 (original, used for Spanish and German dubs)
• video-42-script-v2 (re-edited, used for re-dub)

If a native speaker later tells you "wait, the German version had a detail that you removed in v2", you can pull up the German version, pull up video-42-script-v1, and see what was there. Then decide whether to revert part of v2 or accept the mismatch.

This takes one extra minute per video. It saves hours when troubleshooting a retention drop that happens only in one language.

Use a shared drive or cloud folder with version history

Google Drive, OneDrive, or Dropbox all keep version history. Enable it. When someone asks "who changed this line and when?", you can pull the history.

Never email script files to translators. That creates copies. You end up with script-FINAL.doc, script-FINAL-FINAL.doc, script-FINAL-use-this-one.doc.

Instead, share a read-only link to the cloud folder. Let translators download the version they need. Upload their translations back to the same folder. One source.

A worked example: when things go wrong

Here is what happens without version control. You produce a travel video. The script is 4 minutes 20 seconds. You send it to translators for Spanish and Portuguese. Two days later, before the Spanish translator has finished, you notice the audio has background music that overlaps dialogue in the middle. You re-record that 15-second segment and update the English script to 4 minutes 5 seconds. You upload the new version to the same folder, overwriting the old one.

The Spanish translator finishes first. They translated from the 4 minute 20 second script. Their translation is 4 minutes 18 seconds (slight expansion in Spanish). You dub it and upload. You ping the Portuguese translator: "Ready whenever you are."

They open the folder. The English script now says 4 minutes 5 seconds. They translate that version. Their dub is 3 minutes 58 seconds. You now have three versions: English 4:05, Spanish 4:18, Portuguese 3:58. Viewers watch the Spanish version and notice the audio does not fit. A week later someone comments asking which version is the real one. You have no record of why they diverge.

With version control, this scenario is impossible. The Spanish translator works from travel-video-script-v1-2026-08-10.doc. You create travel-video-script-v1.1-2026-08-12-musicfix.doc and email her: "We fixed a music overlap. Does your 4:18 translation still fit the new audio?" She either says yes or re-translates that 15 seconds. The Portuguese translator sees two English files. You have a deployment record showing which one each language used. Three months later, when analytics show the Spanish version outperforms the Portuguese one, you can trace it back and check whether it is a translation quality issue or a timing issue.

Failure modes and how to handle them

Translator claims they never saw the updated file

This happens when you send updates in Slack or email without updating the shared folder, or when you update the folder without announcing it. The translator was working from a cached local copy.

Prevention: Always announce folder changes in a channel where all translators see it. Always confirm receipt: "Are you ready to work from the v1.1 file, or do you need me to re-send it?"

Recovery: Pull the version the translator used from your cloud history, compare it to the current version, and decide whether to have them re-translate the changed parts or to create a hybrid version.

Two translators work on the same file

This usually happens when you have multiple people working on Spanish, or when someone is covering for a colleague and does not realize another translator is already assigned.

Prevention: Freeze the file in your version control spreadsheet before assignment. Mark it with an owner name and status (In Progress). Do not unfreeze until they confirm done.

Recovery: Check the cloud folder history to see which translator's version is more recent. Use that one. Give the other translator a clear signal: "v1 is yours, v2 belongs to JD."

A translator uploads their translation with no version number

They just call it spanish.doc or translation-es.doc. You now have no idea whether it corresponds to v1, v1.1, or v2 of the English script.

Prevention: Be explicit in your assignment message: "Please save this as video-42-translation-es-v1-2026-11-20-yourname.doc. Do not change the version number."

Recovery: Download the translator's file. Open it alongside your English script versions. Search for a unique phrase that changed between v1 and v1.1. This tells you which English version they translated from.

Common mistakes and how to avoid them

Mistake 1: Assuming translators will email you if they have a question about the script.

They will not. They will translate what is in front of them. If there is an ambiguous sentence, they will make a choice and keep going. You find out in the finished dub.

Fix: Review every script before sending to translation. Read it aloud. Mark any sentence that could be interpreted two ways and call it out: "Line 47 is deliberately vague in English. In Spanish, did you interpret it as X or Y?"

Mistake 2: Creating "just one exception" to the naming system.

You have a video that needs to be dubbed in five languages simultaneously. Naming them all would be tedious, so you call them video-redo-spanish.doc, video-redo-french.doc. You tell yourself it is just this one video.

Three videos later, you have five files with mixed naming, and you cannot remember which one corresponds to which. Your second round of translators picks the wrong file.

Fix: Use the same system every time. It takes thirty seconds to create the right filename. Consistency is free.

Mistake 3: Not documenting why a version exists.

You have script-v1.1 and script-v1.2. A translator emails: "Which one do I use?" You are not sure yourself because you have not documented the difference.

Fix: Add a comment to your deployment spreadsheet with a one-line reason for each minor version:

• v1.1: typo on line 12 (narrator says "their" not "there")
• v1.2: shortened intro by 10 seconds (removed greeting)

Mistake 4: Waiting to translate until the script is perfect.

You re-edit the script five times. You finally release it to translators on a Friday. You have waited three weeks because you kept finding small improvements. Now the translations are rushed.

Fix: Set a deadline. Tell translators: "v1 is locked on Wednesday. I will make no more changes after that." Then stick to it. If you want to change it later, that is v2. Create space to do the re-dub.

Deciding when to freeze and unfreeze

Use this decision framework when you are unsure whether a script is ready for translation:

1. Will any visual changes require script changes? If you plan to re-shoot or edit the video after translation starts, wait. Do not ask translators to work from a script that will be out of sync with a different edit.

2. Are there any open notes from internal reviewers? Do not send to external translators until your own team is aligned. A single unresolved comment often means a paragraph needs to be rewritten.

3. Could timing issues emerge in the dub? Read the script aloud at your intended pace. If it feels too fast, too slow, or if any section feels unclear when spoken, fix it before translation. Translators cannot fix pacing problems in the source material.

4. Have you shown this script to someone who has never seen the video? If the script makes no sense without watching the video, rewrite it. A translator has only the script and a few images. Make it standalone.

If the answer to any of these is yes, do not freeze. Keep editing. Once all answers are no, create v1, freeze it, and move forward.

When one language needs updating, do others?

Here is a practical dilemma: your English video is live with Spanish, German, and French dubs. A viewer in France comments pointing out a factual error in the French version. Or, a month later, you want to make a small improvement to the opening. Do you update all three language versions, or just the one that needs it?

The answer depends on what changed and how many viewers are affected. Track this decision in your deployment spreadsheet so you do not make inconsistent choices later.

Case 1: A factual error in one language only. The Spanish translator misunderstood a source concept or made a mistake. The English and other languages are correct. Update only Spanish. Create video-42-translation-es-v1.1-2026-12-15-correction.doc, update the spreadsheet, and notify viewers in Spanish of the corrected version. Do not touch German or French.

Case 2: A factual error in the English script that affects all languages. You realize you misstated a date or name. Fix the English version. Create video-42-script-v1.1-2026-12-16-factcheck.doc. Notify all three translators: "English has a correction. This affects one sentence. Please check your dub and let me know if this changes anything in Spanish/German/French."

Some translators will re-dub, some will say their version already works. Document which ones updated and which did not. Viewers in France might hear the old fact if the French translator chose not to re-dub. That is okay, and it is documented. You have a record of the choice.

Case 3: A stylistic improvement. You want to tighten the opening by removing a filler phrase. This does not affect meaning, only brevity. The Spanish dub runs one second longer than you want. Do you ask the Spanish translator to re-dub and then have the German translator do the same to match? Probably not. Update English, document it, and move on. Accept that Spanish and German will remain as they were. Consistency in all languages is less important than shipping quickly.

Document the choice in the spreadsheet: mark the Spanish and German lines with a note like "Not re-dubbed for v1.1 (stylistic only)". This prevents someone from asking a month later "why is the Spanish version longer?"

Scaling the system to larger teams

If you work alone or with one translator, the system above is overkill. If you are managing three to five languages with multiple people involved, it becomes essential. If you are scaling to ten languages with overlapping work, add these layers:

Layer 1: Language assignments. Create a separate tab in your spreadsheet for each language showing who can translate, who can review, and who has uploaded. When a new translator joins, add them as a potential owner. Do not let two people work on the same language without explicit assignment.

Layer 2: Timing gates. Create columns in the deployment spreadsheet for "Assigned Date", "Due Date", and "Uploaded Date". Calculate the time between assignment and upload. If Portuguese always takes three weeks and Spanish always takes one week, you can predict bottlenecks and adjust your publishing schedule.

Layer 3: Escalation. If a translator goes silent after the due date, you need a backup plan. Add a column for "Backup Owner" with a name and email. Two days after the due date, email the backup: "Can you take over Portuguese? Original translator is not responding."

Layer 4: Spot checks. For every major dub, listen to at least thirty seconds of two languages that are not your native language. You are listening for timing problems and egregious errors. Note issues in the spreadsheet. Do not assume professionalism. Create accountability.

Building your own system

The key principle is that every decision and every version must be discoverable without asking someone. The spreadsheet is the source of truth. The file names encode metadata. The folder structure makes it impossible to lose a file. Cloud version history provides an audit trail.

Start small. Implement it for your next two-language video, then three. By the time you are dubbing in five languages, it will feel like muscle memory. You will save more time troubleshooting than you spent setting up the system.

What to do next

Build this system into your workflow now, before you dub multiple languages of anything:

1. Choose a cloud folder (Google Drive, OneDrive, or Dropbox). Create the /scripts folder structure. Test that you can restore a file from version history.

2. Create a single spreadsheet or README that lives in the /scripts folder. Add columns for Video ID, Language, Filename, Owner, Status, and Date Locked. This is your source of truth.

3. Write a template filename: video-[ID]-[TYPE]-[LANG-CODE]-v[X].[Y]-[DATE]-[OWNER].doc. Paste it somewhere you see it. Use it every time.

4. For your next multilingual dub, name every file according to the template before you send anything to translators. Freeze the English script. Update the spreadsheet. Ask each translator to confirm the filename they downloaded.

5. After publishing, do not delete anything. Leave all versions in place. You will reference them later.

One small system now prevents a disaster later. Three months in, when a market is underperforming and you are chasing down whether it is a translation issue or something else, knowing exactly what version of what script drove that dub is the difference between a quick diagnosis and a week of guessing.

---

🚀 Start Dubbing Your Videos Today

DubLab uses AI to translate your videos into 92+ languages in minutes.

📱 Download for iOS

🌐 Try Free at dublab.app