Text freeze and voice recording: the real cost of changing one line

Three weeks after the English recording session, the writer asks to change one line. It is a better line — sharper, and it fixes a small inconsistency with a scene two chapters later. The producer says yes in about four seconds, because on a text document a line is a line.

The question the production manager has to answer that same day is what that line touches. Nine languages of translated text, one recorded English take, two dubbed languages already in the can, a lip-synced animation cut to the old timing, subtitle files, and an LQA pass per language. The honest answer is not an hour of work. It is a week and a studio booking.

Text freeze exists to make that arithmetic visible before the yes, not after. It is not a rule against improving the script. It is a mechanism for moving improvements into a window where they cost roughly what they appear to cost, and for making sure that when a change is genuinely worth an expensive week, everyone agreeing to it knows that is what they are agreeing to.

What is actually downstream of one changed line

Before designing a freeze, it helps to write the chain out once for your own project, because most teams underestimate it by two or three steps. A single source line, once localization and recording are underway, feeds:

• Translation into every shipped language — each an assignment, a delivery, and a review, with a minimum charge that makes one-line jobs disproportionately expensive
• Recording in the source language — a booking, an actor's availability, a studio slot, a director's time
• Recording in every dubbed language — the same again, per language, with its own scheduling constraints
• Audio post — editing, processing, naming, and integration of the new take into the build
• Anything cut to the old audio — lip sync, cinematic timing, subtitle cues, animation events triggered on the line
• LQA in every language, because the changed line has to be verified in context again everywhere it appears

There is also a subtler shift that happens the moment recording starts. Before recording, the text document is the source of truth. After recording, the audio is, at least for every voiced line — and the text is now a description of something that already physically exists. Any mismatch between what a player hears and what they read is a bug they will notice immediately and report, particularly the large group of players who deliberately run source-language audio with subtitles in their own language.

This is why the freeze for voiced content cannot sit at the same date as the freeze for everything else. It is not stricter out of ceremony; it is earlier because the thing it protects takes longer and costs more to redo.

Freeze in stages, not all at once

A single freeze date for all text is the most common design and the one most likely to be broken. It is either so early that UI strings are frozen months before the UI is finished, which guarantees exceptions, or so late that it does not protect recording at all. Once a freeze is routinely broken, it stops functioning as information — people learn that the date is a suggestion, and the cost warnings attached to it stop being read.

Stage the freeze by content type, according to what each type feeds downstream:

• Voiced narrative text — freezes first, because it feeds recording in every language
• Unvoiced narrative and item or lore text — freezes next, gated by translation lead time rather than recording
• UI and system strings — later, but still before the translation handoff that covers them; these change late by nature, so plan for a final UI-only pass rather than pretending they will not
• Platform-mandated and legal strings — their own date, driven by submission deadlines, not by your internal schedule
• Store page and marketing copy — a separate track entirely; it does not belong in the build freeze and should not be allowed to hold it up

Each stage needs a named date and a named person who can approve an exception. If nobody owns the date, the freeze is enforced by whoever happens to be in the meeting, which in practice means it is enforced against junior people and not against senior ones.

Communicate each date with what it protects, not just when it lands. A date announced as text freeze is March 2 gets treated as bureaucracy. A date announced as after March 2, changing a voiced line costs two recording sessions and four language updates gets treated as a fact about the world, and people plan around facts.

The exception procedure is what makes a freeze survivable

An absolute freeze will be circumvented — through a side channel, a favor, or a quiet edit to a shared sheet — and circumvented changes are far more dangerous than approved ones, because they propagate to some languages and not others. Design the exception path deliberately so that using it is easier than going around it.

The procedure needs four things: who may request a change, what the request must contain, who approves it, and a standing statement of cost that is attached automatically rather than argued each time. The request should name the exact string keys rather than describe the scene, because a description sends someone hunting through the script and the hunt is where the wrong line gets edited.

Classification is what keeps the volume manageable, and three classes are enough:

• Class A — factual, legal, platform-compliance, or comprehension-blocking errors. Always accepted, cost absorbed, no debate.
• Class B — the line is understandable but genuinely misleads players about a mechanic or a story fact. Accepted after the cost is calculated and someone with budget authority sees it.
• Class C — the line could be better. Batched into a post-launch text update, or into the next scheduled pickup window if one exists.

The classification should be made by someone who did not write the line. Authors are systematically bad at rating their own improvements as Class C, not out of ego but because the improvement is vivid to them and the downstream cost is abstract. Handing that judgment to production, with the writer arguing their case, produces better decisions in both directions — it also means the genuinely important Class A changes are not lost in a pile of polish requests.

Keep a visible log of every exception granted, with its cost. Two things come out of that log. Teams request fewer Class C changes when the running total is on a wall, and the log becomes the evidence for next project's schedule, when someone asks why the freeze should be two weeks earlier than it was this time.

Text changes and voice changes are two different bills

It is worth separating these explicitly in how you talk about changes, because treating them as one category makes every change feel equally expensive and pushes teams toward blanket refusal.

A text-only change — an unvoiced line, or a language that ships subtitles only — costs translation, review, integration, and an LQA check. It is real work in every language, but it is bounded and it does not depend on anyone else's calendar.

A voiced-line change costs all of that plus a session, and sessions have a floor. Bringing an actor and a director back for one line costs close to what bringing them back for twenty lines costs, because the expensive part is the scheduling, the setup, and the minimum booking, not the reading. That single fact should shape the whole process: never record pickups one change at a time.

Instead, keep a running pickup list from the freeze date onward, and put pickup windows on the calendar in advance — booked, with the actors' availability confirmed — rather than trying to find a slot reactively when a change arrives. A change that lands the day after a pickup window is a change that waits for the next one, and knowing the date of the next one turns that wait from a crisis into a scheduling fact.

Decide one policy in advance, before it comes up under pressure: when the recorded audio and the improved text disagree, which one wins in the subtitle? For most teams the answer is that the subtitle matches the audio, because a visible mismatch is a bug players report and a slightly less elegant line is not. Whatever you choose, choose it once and write it down, because deciding it per line produces a build where some subtitles match the audio and some do not, which is worse than either consistent option.

Translation and recording run in parallel, which multiplies the ripple

On a schedule tight enough to need a freeze, languages are never all at the same stage. When the source changes, language 4 may be mid-translation, language 6 may have delivered and been reviewed, and language 2 may already have recorded a dub of the old line. The same source edit therefore has a different cost and a different remedy per language, and the failure mode is applying it in the languages that are easy to reach and forgetting the ones that are not.

Three practices contain this. First, version the source with change identifiers rather than editing in place, so that every downstream party can ask what changed since the version they worked from. Second, publish a change log that vendors and the recording coordinator subscribe to, on a fixed cadence, including a line that says no changes this week when that is true — silence is ambiguous, and an explicit nothing changed is worth sending. Third, carry the recording status on the string record itself, so that anyone looking at the line can see what a change would cost before proposing it.

# a string record that makes the cost of a change visible

key:            ch03.mira.betrayal.012
source:         You knew. The whole time, you knew.
source_status:  FROZEN (2026-03-02)

voiced:         en  recorded 2026-03-18  (studio A, actor confirmed)
                ja  recorded 2026-04-02
                de  scheduled 2026-05-11
                fr, es, pt-BR, ko, zh-Hans, ru  subtitle only

translation:    ja delivered | de delivered | fr in review
                es in progress | pt-BR, ko, zh-Hans, ru not started

cut_to_audio:   cinematic CS-0311 (lip sync), subtitle cue 03-14

change_cost:    2 recorded sessions to redo + 1 booking to amend
                9 language updates + 9 LQA checks + 1 cinematic re-cut

The single most damaging habit in this whole area is communicating a source change by editing a shared spreadsheet and saying nothing. It feels efficient and it is how a line ships correctly in eight languages and stale in the ninth — the one whose vendor had already exported their working file that morning. A source change is an event that has to be announced, not a state that quietly differs from what people downstream are holding.

What to settle before the freeze date arrives

Almost everything above is cheap to arrange in advance and expensive to invent mid-crisis. Before the first freeze date on your schedule, these should exist in writing and be known to the writers, not only to production:

• The staged freeze dates, each with what it protects and who owns exceptions
• The exception request form, the three classes, and who classifies (not the author)
• Pickup windows already on the calendar, with actor availability confirmed, through to submission
• The subtitle-versus-audio policy for mismatches
• The change-log cadence and its distribution list, including every vendor and the recording coordinator
• A per-language definition of delivered, so nobody assumes a language is done when it is only translated and not yet reviewed in context

None of this is aimed at reaching zero changes. A project that reaches its freeze date and never changes another line has usually stopped listening to its own playtests. The aim is zero surprise changes: every change that happens is one somebody chose while looking at what it costs, applied everywhere it needs to go, in every language, and verified afterwards. That is a schedule you can hold, and it is the difference between a freeze that protects the release and a freeze that everyone quietly ignores.