The Obligation Nobody Budgets For
Producing a localized asset is a one-time cost. Keeping it accurate is a recurring one, and it does not appear in most localization plans.
The obligation is real: when the source content is corrected, every language version needs the same correction. When the source changes, every version needs updating. When the source is withdrawn, every version must be withdrawn simultaneously.
This scales with the number of languages. A program with a hundred assets in six languages has six hundred things to keep current, and the maintenance burden grows with every batch produced.
Programs that do not plan for this accumulate a library of increasingly wrong content. The staleness is discovered by customers rather than by the team, and by the time it surfaces the divergence between source and translations may be substantial across many assets.
The Cost of Staleness
Stale localized content is not neutral. It is frequently worse than no content.
A viewer who follows outdated instructions and fails does not conclude that the content was old. They conclude that the guidance was wrong, and they contact support — the outcome the content was meant to prevent.
In regulated contexts, a stale translated version of a procedure, policy, or safety instruction is a compliance exposure. The question of what a specific person was actually shown, in what language, and when, has an answer, and that answer needs to be defensible.
In product content, a video showing an interface that no longer exists undermines confidence in everything else the company publishes.
And staleness compounds reputationally. A market that receives visibly outdated content concludes, correctly, that it is not a priority.
The Records That Make Maintenance Possible
Maintenance is only tractable if you know what exists and what it reflects. Without records, determining what a correction affects requires inspecting everything.
Record per localized asset:
Source version. Which version of the source content this was derived from. This is the single most important field, because it is what makes scoping a change possible.
Production date and the pipeline configuration used.
Glossary version in effect at production. When a term changes, this identifies exactly which assets used the old rendering.
Voice and settings, so that a regenerated segment matches the rest of the asset.
Reviewers and approval, with dates. In regulated contexts this is part of the deliverable.
Segmented script and timing data. This is what enables segment-level correction rather than full regeneration, and archiving it during production costs nothing while reconstructing it later is laborious.
Product area or subject tags, so that a change in a domain can be cross-referenced against affected content.
Publication locations. Where the asset is published, which is what makes withdrawal complete rather than partial.
These should be recorded by the pipeline rather than maintained by hand. Hand-maintained records at volume are unreliable exactly when they matter.
Change Propagation
When source content changes, the response should be proportionate to the change.
Assess scope first. A change to one paragraph in a forty-minute course does not require full retranslation. Identify which segments are affected.
Update at segment level where possible. Retranslating and regenerating only the affected segments keeps update cost proportional to change size. This requires the archived segmented script and timing data.
Define a re-review threshold. Minor wording changes may not need in-market review; changes to definitions, procedures, legal language, safety instructions, or anything with regulatory significance always should. Writing this rule down prevents both over-reviewing trivial updates and under-reviewing significant ones.
Batch where practical. Applying several accumulated changes at once, at a release boundary, is more efficient than propagating each individually, provided the delay is acceptable for the content type.
Propagate to all languages together. A correction applied to some language versions and not others creates exactly the inconsistency that is hardest to detect later.
Update the records with the new source version, so the next change can be scoped correctly.
Detecting Drift
The hardest maintenance problem is not applying changes but noticing that they are needed.
Tag content by subject area and cross-reference release notes, policy updates, or regulatory changes against those tags. This is the mechanism that turns "someone should check" into a specific list.
Set review intervals appropriate to how quickly the underlying subject changes. Software content may need quarterly review; foundational educational content may need annual review.
Instrument the signals. Rising support contacts about a topic covered by localized content, negative feedback on specific assets, or completion rate decline can all indicate that content has drifted out of accuracy.
Watch the source. Where the source content has an owner, they should know that translated versions exist and that changes need flagging. Frequently they do not, which is a communication gap rather than a process one.
Audit periodically. A scheduled pass over the library, checking a sample against current reality, catches drift that no automated signal surfaces.
Retirement
Withdrawal is the maintenance activity most often done incompletely.
When source content is retired, every localized version must be retired at the same time. Orphaned translations outliving their source are a recurring failure and a serious one in regulated contexts.
This requires knowing every location where the asset was published, which is why publication locations belong in the records. Content distributed to multiple platforms, embedded in help centres, downloaded for offline use, or shared with partners is harder to withdraw completely than content published in one place.
Offline copies are the hardest case. Content downloaded to devices, distributed to sites, or included in physical media cannot be recalled centrally, and withdrawal requires a communication process rather than a technical one.
Retire proactively rather than waiting for a complaint. A scheduled review that identifies content covering removed features, superseded procedures, or discontinued products is cheaper than discovering the same thing through a customer.
Reducing the Maintenance Burden
Some of the burden is avoidable through content design.
Separate durable from volatile content. Content explaining concepts outlasts content describing specific interfaces or values. Splitting these means only the volatile part needs frequent updating.
Avoid embedding volatile specifics. A video that directs viewers to a page for current pricing, contact details, or specifications stays accurate far longer than one stating them directly, and the page is dramatically cheaper to update in every language.
Keep assets short and single-purpose. A long video covering many topics goes stale when any one of them changes; short single-topic videos go stale individually.
Avoid positional references. "Click the button in the top right" breaks when layouts change and breaks differently in each localized layout. "Open the sharing options" survives both.
Prefer sidecar subtitles over burned-in text where the platform allows, since correcting a sidecar file costs nothing and re-rendering burned-in text costs a full production cycle per language.
Localize selectively. Content with a short useful life often should not be localized at all, precisely because the maintenance obligation exceeds the value.
Budgeting for It
Maintenance should be a recurring line rather than an afterthought.
A reasonable planning assumption is that a meaningful proportion of a library needs updating each year, scaling with how fast the underlying subject changes and with the number of languages.
The proportion rises as the library grows. A program in its third year spends materially more on keeping existing content current than one in its first, and programs that budget only for new production find that maintenance either does not happen or crowds out new work unexpectedly.
Reserve capacity explicitly. Where a budget cycle funds a localization push, allocating a portion to maintenance rather than spending it all on new content is what prevents the library decaying while it grows.
Where maintenance capacity is genuinely limited, the right response is to localize less content and keep it current rather than to localize more and let it decay.
Getting Started
If a library already exists without maintenance records, start by establishing what is there: what assets exist, in what languages, published where, derived from what source version if determinable.
Audit a sample against current reality to estimate how much drift has already accumulated. This number is usually larger than expected and is what justifies the process.
Prioritize corrections by exposure and severity rather than chronologically. A stale high-traffic asset matters more than a stale one nobody watches.
Instrument the records going forward, so that the next change can be scoped rather than investigated.
Assign an owner. Maintenance without a named owner is work that falls between roles and does not happen.
Set review intervals and tag content by subject area, so that drift detection becomes a scheduled activity rather than a reaction.
A localized library is an asset that depreciates without upkeep. The programs that treat maintenance as part of the cost of localizing — rather than as a problem for later — are the ones whose libraries are still worth something in year three.
Who Owns It
Maintenance fails on ownership more often than on process, because it is work that sits between roles.
The content owner produced the source and moved on. The localization team produced the translations and moved on. The product or policy owner changed something without knowing translated versions existed. Nobody's job description includes noticing that a Portuguese version of a two-year-old training video now describes a procedure that changed.
Naming an owner is the intervention that matters. It does not need to be a full-time role at most scales — it needs to be someone whose responsibility it explicitly is, with time allocated and the authority to require changes to propagate.
The owner's practical job is: keeping the records current, running the scheduled reviews, cross-referencing changes against the tagged library, scoping corrections, and ensuring withdrawal is complete.
Where the localization program has an owner already, maintenance naturally belongs to them. Where localization was a project rather than a program, maintenance frequently has no owner at all, which is why project-shaped localization efforts decay so reliably.
Communication upstream matters as much as the process itself. Source content owners need to know that translated versions exist and that changes need flagging. Most do not, and telling them costs nothing.
A Maintenance Cadence
A workable rhythm for most programs:
Continuously: propagate corrections. When source content is corrected, the correction reaches every language version promptly rather than waiting for a cycle.
At each release or policy update: cross-reference the change against tagged content and scope what needs updating. Batch the resulting updates.
Quarterly: review high-volatility content — product, pricing, procedural — against current reality.
Annually: audit a sample of the whole library, review the glossary, and identify content for retirement.
On demand: respond to signals — support contacts, feedback, completion decline — that indicate drift.
The cadence should match the content. A library of foundational educational material needs far less frequent attention than one covering a product that ships weekly, and applying a uniform schedule either wastes effort or misses drift.
What Good Maintenance Looks Like
A library under control has a few observable properties.
Any localized asset can be traced to a source version, a glossary version, and an approval record, without investigation.
A change to source content produces a specific list of affected assets rather than a general concern.
Corrections reach every language version within a defined window rather than reaching some and not others.
Retired content is gone from every location it was published to, including offline distributions.
Nobody discovers stale content through a customer complaint, because the scheduled reviews found it first.
The maintenance workload is predictable enough to budget, rather than arriving as unplanned emergency work.
If none of these are true, the library is decaying, and the rate of decay is proportional to how fast the underlying subject matter changes.
The programmes that achieve this are not doing anything sophisticated. They recorded the source version at production time, tagged content by subject, named an owner, and set a review interval. That is the whole apparatus, and it is considerably cheaper than the alternative of rediscovering the library's state every time something changes.
Treat the first maintenance cycle as the one that establishes the process. Whatever is missing from the records will become obvious the first time a correction has to be scoped, and fixing it then is far cheaper than fixing it after three more batches have been produced without it.
