Who Owns, Approves and Retires Content in Every Language

Why translated content needs its own governance

Governance for single-language content is usually informal: the author publishes, an editor checks, and people notice when something is wrong. That stops working when the same content exists in five languages. The core team cannot read most of the versions, errors are reported late or never, and an update to the source does not automatically reach any translation.

The typical failures look like this:

• A pricing change is made in the source and two of four translations, leaving old prices live elsewhere.
• A legal disclaimer is reworded for one market and later copied into others where it does not apply.
• A dubbed video still describes a discontinued feature, because nobody knew it existed in that language.
• Two teams translate the same help article independently and publish conflicting versions.

Each of these is a governance gap, not a translation error. The translation may be perfect; the problem is that nobody owned the version or knew it needed attention.

Assign an owner to every language version

Every translated asset needs a named owner, and the owner of the source is not automatically the owner of the translations. A workable split:

Source owner

Decides what the content says, approves changes to the source and flags which changes must reach every language

Language owner

Accountable for all content in one language: accuracy, currency, and raising problems back to the source owner

Approver

Signs off specific content types, such as legal, brand or product, before publication in any language

Operations owner

Keeps the records, triggers update work and runs periodic audits

In a small team one person may hold several roles; what matters is that each role has a name. The language owner is the role most often missing. Without one, a translation has an author but no one who will notice when it becomes wrong. How those roles map onto a team structure is a separate question; governance only requires that they exist.

Define approval paths by risk

Not every piece needs the same approval. Grading content by risk keeps review effort where it matters:

1. Low risk (social posts, blog posts, general explainers): language owner or one fluent reviewer approves.
2. Medium risk (product pages, help articles, onboarding videos): language owner plus a product check on feature names, numbers and steps.
3. High risk (pricing, contracts, safety instructions, health or financial claims, regulated disclosures): qualified translator, language owner and the relevant legal or compliance approver.

Write down which content types fall into each level, and who the approvers are per language. The mechanics of reviewing a translated video (who watches, what they check, how they log fixes) are covered in the team review workflow for video translation. Governance decides who must sign off; the review workflow decides how they do it.

Legal requirements for translated content vary by country, sector and content type, and they change. Check with your legal team or a qualified adviser for each market rather than assuming that the approval path for one country works in another.

Keep a single source of truth

For each piece of content, one version is the source, and every translation is derived from a specific revision of it. That sounds obvious, but problems start when a translation is edited locally and then becomes the de facto source for a third language.

Rules that keep the source clear:

• Translate from the approved source, never from another translation, unless you deliberately use a pivot language and record it.
• If a market needs different wording, decide whether it is a local adaptation (recorded as such) or a correction (fed back into the source).
• Store glossaries, style guides and translation memories centrally, not in each translator's files. A translation memory is only useful if everyone writes to the same one.
• Keep the source script, a timestamped transcript or a subtitle file for every video, because a finished video file is hard to compare against anything.

Brand and legal review across languages

Brand review checks that a translation sounds like the organization; legal review checks that it says nothing the organization cannot stand behind in that market. Both are hard when reviewers do not read the language.

Practical approaches:

• Give brand reviewers a back-translation or a translated transcript of key passages, rather than asking them to approve text they cannot read.
• Mark sentences that carry legal weight (guarantees, prices, eligibility, safety warnings) in the source, so translators and reviewers know which lines need exact treatment.
• Keep an approved-phrases list per language for recurring legal wording, so it is not retranslated each time.
• Record who approved what and when. If a claim is challenged later, you need to know which version was live and who signed it off.

Version records that actually get used

A version record answers three questions for any translated asset: which source revision it came from, when it was last checked, and who checked it. A spreadsheet works for hundreds of assets; a content management system with locale fields works for thousands.

Asset ID

A stable identifier shared by the source and all translations

Source revision

Date or version number of the source the translation was made from

Language

One row per language version

Status

Current, needs update, under review, withdrawn

Last verified

Date the language owner last confirmed it matches the source

Approver

Who signed off, for medium- and high-risk content

The key habit is updating the record when the source changes. Whenever a source revision is published, every row with an older source revision becomes "needs update" until someone decides otherwise. For video specifically, the decision between re-running, patching or withdrawing an outdated version is its own topic; the record just has to make the outdated versions visible.

Retiring outdated translations

Retirement is the part of governance teams forget. Not every translation deserves to be updated forever. Set criteria for withdrawal, such as:

• The source has been retired or replaced.
• The translation is outdated and the cost of updating exceeds its value, judged by traffic or business use.
• The language has moved to a lower coverage level in your content strategy.
• The content carries legal or safety risk and cannot be verified quickly.

When withdrawing, redirect to the nearest current equivalent (the same content in the source language, or an updated page in the same language) instead of leaving a broken link. Keep the withdrawn file and its record for your archive, so you can show what was published if it is ever questioned.

Risks and limits of heavy governance

• Approval paths that are too strict for low-risk content slow publishing until teams bypass them.
• Language owners without time allocated in their role will not keep up, and the record becomes fiction.
• Version records maintained by hand drift unless updating them is part of the publishing step, not an afterthought.
• Central control can make translations sound uniformly foreign; leave room for local adaptation and record it.
• Governance cannot fix poor source content. If the source is unclear, every language inherits the problem.

Aim for the lightest process that prevents your most likely failure. For most teams that is outdated prices, features and legal wording, not stylistic inconsistency.

How mydubly outputs fit a governed workflow

mydubly is a processing step, not a governance system. It does not store your content, keep version history or route approvals. Uploaded audio chunks and results are deleted within 30 minutes of a job finishing, so your own records, not mydubly, must hold the files you want to keep.

What it produces can support governance. For a video, a translated transcript job gives the transcript in both the spoken and target languages, which a brand or legal reviewer can read side by side. A dubbed job gives target-language subtitles that follow the dubbed lines, plus transcripts in both languages, so the reviewer can check exactly what the translated voice says. Save those files alongside the video and record the source revision they came from. If the source video changes, re-run the job from the new file; the video localization page explains the options, and the private video translation page describes what leaves the device during processing.

Next step: start the record

Pick your highest-risk content type, usually pricing or legal pages, and build the version record for it across every language you publish. Name a language owner for each language and an approver for that content type. Once that works, extend the record to help content and video. For guidance on who should review translated material in each language, see finding a reviewer for AI translation.