A workflow tells you the steps. A playbook tells you which step to run when, who owns it, and what triggers it. The difference matters because real localization programs do not run as a clean linear pipeline; they run as a set of plays that fire in response to events: a new content type, a new market, a quality incident, a deadline crunch. Without a playbook, every one of those events gets handled by improvisation, and improvisation under pressure is where quality dies.
This article organizes the operation of automated translation as a set of named plays. Each play has a trigger that tells you when to run it, an owner who is accountable for it, and a sequence of moves. The plays are designed to compose: the routine ones run continuously, and the situational ones fire when their trigger appears. Together they form an operating model that a program can actually run against rather than a list of ideals.
The underlying mechanics of producing a single translation are not the focus here. That ground is covered in Building a Repeatable Workflow for Ai Translation and Localization Tools. This is the layer above: how to run the program.
One discipline holds the whole playbook together: every play names an owner before it names a move. A play without an owner is a wish, not a process, because under pressure unowned work simply does not happen. As you read each play, notice that the owner comes first. That ordering is deliberate, and it is the single habit that most reliably separates programs that run smoothly from those that lurch from crisis to crisis.
The Intake Play
Every piece of content enters the system the same way, and that entry point is where most quality decisions are actually made.
Trigger and owner
The intake play fires whenever new content is queued for translation. Its owner is the content operations lead. Its job is classification: what is this content, how high are the stakes, what language is it going to, and therefore what level of review does it require.
The moves
Classify the content by risk tier, attach the right terminology and do-not-translate context, and route it to the correct review path. Getting classification right at intake is what makes everything downstream work; misclassification here propagates errors through the whole pipeline.
Why intake deserves the most attention
It is tempting to treat intake as a formality and rush to the interesting work of translating. Resist that. A piece of content misclassified as low-risk skips the review it needed and ships an error; a piece over-classified as high-risk wastes scarce reviewer attention. Both failures originate at intake and are nearly impossible to correct later, because once content is routed, no downstream stage questions the routing. The owner of this play should be the most experienced person in the program, not the least.
The Terminology Enforcement Play
This play runs continuously in the background and prevents the slow erosion that ruins brand consistency.
Trigger and owner
It fires on every translation and is owned by whoever maintains the central glossary. The trigger is automatic; the maintenance is periodic.
The moves
Enforce approved terms at generation time, validate that they survived in the output, and flag any segment where an approved term was paraphrased. The play also includes a periodic review of the glossary itself, because terminology evolves. The reason a passive glossary fails is detailed in Where Fluent Machine Translation Quietly Breaks for Experts.
The Tiered Review Play
This is the play that decides where human attention goes, and getting it right is the difference between scalable quality and either overspending or shipping errors.
Trigger and owner
It fires after generation, owned by the review lead. The trigger is the risk tier assigned at intake.
The moves
Low-risk content gets automated checks and spot review. Medium-risk content gets human review by sampling. High-risk content, legal, medical, safety, gets full bilingual review with no bypass. The tiers exist because uniform review wastes attention; the rationale appears in Claims About Machine Translation That Do Not Survive Scrutiny.
The Integrity Check Play
This play catches the technical failures that linguistic review misses entirely.
Trigger and owner
It fires automatically on every translated string and is owned by the engineering side of the localization team. It does not depend on human attention.
The moves
Validate placeholders, variables, and markup survived intact; validate rendering in the actual target context; treat any corruption as a build-breaking failure. These checks run as automated gates, not manual steps, because the failures they catch pass human review undetected.
The Incident Response Play
When a translation error reaches production, this play turns the failure into a permanent improvement.
Trigger and owner
It fires when an error is found in shipped content, owned by the content operations lead. The trigger is a reported defect.
The moves
Contain the error, trace it to its cause, fix the immediate instance, and then close the loop by adding a control that prevents the class of error from recurring. An incident that does not produce a new control is a wasted incident. Many incidents trace back to the hidden risks catalogued in The Quiet Liabilities Lurking Inside Automated Translation.
The Scale-Out Play
When the program expands to new teams or markets, this play keeps quality from fragmenting.
Trigger and owner
It fires when a new team or market joins, owned by the program lead. The trigger is an expansion decision.
The moves
Provision the central standards, run enablement focused on judgment, and establish the ownership and measurement that keep the new group aligned. The full change-management detail lives in Getting Automated Localization to Stick Across a Whole Org.
The Deadline-Crunch Play
This is the situational play that decides whether quality survives pressure, and it is the one most programs lack.
Trigger and owner
It fires when volume or urgency exceeds normal capacity, owned by the program lead. The trigger is a release crunch or an unexpected surge in content.
The moves
Under pressure the wrong instinct is to skip review wholesale. The right move is to re-rank by risk: protect the high-stakes content's full review absolutely, relax review only on genuinely low-risk content, and explicitly defer the medium tier rather than silently dropping it. The crunch play makes the trade-off deliberate and visible rather than an accident that erodes quality. The temptation to quietly bypass review under deadline is exactly the failure mode flagged in The Quiet Liabilities Lurking Inside Automated Translation, and naming a play for it is what keeps the bypass honest.
Sequencing the Plays Together
The routine plays, intake, terminology, review, and integrity, run on every piece of content in sequence. The situational plays, incident response and scale-out, fire on their triggers. The owner map keeps accountability clear: content operations owns intake and incidents, the review lead owns the review tiers, engineering owns integrity, and the program lead owns scale-out. When every play has a named owner and a clear trigger, the program runs on rails instead of on heroics.
Frequently Asked Questions
What is the difference between a playbook and a workflow?
A workflow is the linear steps to produce a translation. A playbook adds triggers, owners, and situational plays, so the program responds correctly to events like incidents and expansions, not just steady-state production.
What is the most important play to get right?
The intake play, because classification there determines the review level and context for everything downstream. Misclassification at intake propagates errors through the whole pipeline.
Why separate the integrity check play from review?
Because the failures it catches, broken placeholders and rendering corruption, pass human review undetected. They need automated gates, not human attention.
Who should own quality across the plays?
Distribute ownership by play: content operations owns intake and incidents, the review lead owns review tiers, engineering owns integrity, and the program lead owns scale-out. Every play needs a named owner.
How does the incident response play prevent repeat failures?
By requiring that every incident produces a new control that prevents the whole class of error from recurring, not just a fix for the single instance.
Do all plays run on every piece of content?
The routine plays do: intake, terminology, review, and integrity. The situational plays, incident response and scale-out, fire only when their triggers appear.
Key Takeaways
- A playbook adds triggers, owners, and situational plays on top of a linear workflow, so the program survives real-world events.
- The intake play drives everything downstream; correct risk classification there is the highest-leverage move.
- Terminology enforcement and integrity checks run as automatic background plays, not manual steps.
- Tiered review sends human attention where stakes are highest instead of spreading it uniformly.
- Incident response must produce a new control each time, and scale-out must provision standards and ownership to keep quality from fragmenting.