How to write a translation brief that gets you the right output every time
Learn how to create a translation brief template that reduces revisions and sets every translator up for success. Covers audience, tone, glossary, and more.
A translation brief template is something most agencies intend to build and few actually do. In our experience working with translation teams across agencies, freelancers, and corporate localization departments, the projects that end in revision spirals and client complaints almost always started without one. The file arrived, someone translated it, and the gap between what was expected and what was delivered only surfaced at review. Revision cycles followed. Almost all of it was preventable.
What a translation brief actually does (and why most fail)
A translation brief is a set of written instructions telling the translator everything they need before work begins: the document's purpose, who's reading it, what register to use, which terms have approved translations, and what constraints exist on formatting and structure.
When the brief is missing, translators default to their own judgment. That works fine if you have a specialist with years of context on a specific client. It stops working at scale — multiple translators splitting a document, someone new on their first project, or AI pre-translation feeding into a post-editing step where the editor doesn't have time to research terminology calls from scratch.
The failure patterns we see are consistent. First, the brief confuses document type with purpose. "Technical manual" tells a translator almost nothing. "Technical manual for industrial machinery operators with no assumed engineering background, used in safety-critical conditions" tells them quite a lot. Second, briefs use style descriptors that mean nothing without context. "Formal" in French legal translation is a different register entirely from "formal" in a German software UI. Third, and most commonly, the glossary section gets left blank. The translator makes terminology calls the client later disputes, and the fix is expensive.
One agency we work with started tracking this systematically. Projects that came in with structured briefs had measurably fewer terminology and register corrections in post-delivery QA. The difference wasn't marginal, and once they saw the numbers, investing time in brief preparation became straightforward to justify.
The six elements every translation brief needs
Not every brief has to be a long document. For a recurring client with an established style guide and a maintained termbase, a brief might be three sentences and a glossary link. For a new client, domain, or content type, these elements need to appear somewhere before translation starts.
The first is source document and context: what the document is and what it's for. A pharmaceutical legal disclaimer carries specific liability implications that affect every word choice. That context belongs in the brief, not in a post-delivery revision note.
The second is target audience. Who reads this translation? Their background, familiarity with the subject, and reading context all shape vocabulary and register decisions. There's more on how to write this field properly in the next section, because it's where most project managers default to the broadest possible terms.
The third is register and tone. What should the text sound like? A positive description, a negative description, and at least one reference example in the target language carries more practical weight than a paragraph of adjectives.
The fourth is terminology and glossary. Which terms must translate a specific way? Which stay untranslated? This is where you attach the project glossary or termbase and note any brand names or regulated terms that follow specific conventions.
The fifth is formatting instructions: placeholders that can't be touched, character limits for UI strings, whether headings should be translated. These details matter especially in DOCX-based workflows where structural elements carry meaning.
The sixth is references and do-not-translate list: examples of previously approved translations, the style guide if one exists, and any boilerplate that must appear verbatim in the output — certified document numbers, legal disclaimers, registered trademarks.
How to write target audience instructions translators can actually use
"Target audience: retail investors." That was the complete audience section of the brief for a financial services onboarding document. The translator wrote accurate, formal prose with proper investment terminology throughout. The client came back and requested a full revision. The product targeted first-time investors with no financial background, acquired through social media ads. "Retail investor" was technically accurate and completely useless as a brief element.
The revision cost two working days.
What helps is thinking about three dimensions. Background knowledge: what does the reader already know about the subject? Reading context: when and how will they encounter this text — in a browser on a phone, in a printed manual at a workstation, in a rushed moment before a client call? Action intent: what should they do, understand, or feel after reading?
Two or three sentences covering these three dimensions does more work than a full demographic profile. "First-time users with no technical background, reading on mobile, who need to complete account setup in under five minutes" gives a translator a picture they can work with. "General consumers" does not.
This matters more in multilingual projects. A brief that works for German, where direct address in formal contexts is standard and expected, may need adjustment for Korean, where the same register can read as cold or dismissive. If you have language-pair-specific notes from past projects or from translators working in those markets, they belong in the brief. When none exist, build in a confirmation step before delivery rather than discovering mismatches at review.
For projects with significant cultural adaptation involved, it's also worth noting market-specific conventions that adjectives like "formal" or "professional" simply don't capture. German readers generally expect direct, factual statements about features and limitations. Japanese copy more often uses softer framing that leaves room for the reader's own judgment. These are audience expectations that shape how the same content lands, and they belong in the brief for those language pairs.
Tone and style instructions that go beyond "formal" or "informal"
"Formal" is not a style instruction. It's a starting point two translators will interpret in meaningfully different ways.
What works is a combination of positive description, negative description, and one reference example in the target language. Something like: "Warm but professional, like a knowledgeable colleague who takes your problem seriously. Not cold or bureaucratic like a government notice." Then attach a sentence or paragraph from a past translation the client approved, or a passage from a competitor's website in the target market that the client pointed to as an example of the right tone.
This approach is especially useful when you're building a translation style guide for a new client relationship. The tone section of the brief feeds directly into the style guide, and both eventually feed into the translation prompt if you're using AI pre-translation.
When AI is involved, tone is typically the first issue that surfaces in post-editing. The output is accurate and fluent, but the register is slightly off: too stiff, or too casual. The cause is almost always that the translation prompt didn't carry enough style context from the brief. Brief quality and AI output quality are directly linked. Improve the brief, and the post-editing step gets faster.
For projects spanning multiple language pairs, calibrate the tone description per market rather than writing one description and assuming it translates. Build short language-specific notes into your brief template for the markets you work in regularly. A sentence or two per language pair, updated as you accumulate feedback from clients and translators, becomes one of the more useful assets your team maintains over time.
The glossary section most agencies leave blank
If there's one field with a direct, measurable effect on output quality, it's the glossary. Terminology inconsistencies appear in the most common error categories across professional QA reports. Getting terms right before translation starts removes an entire class of problems from the project.
The types of errors that come from a missing glossary are predictable. Proper nouns get translated when they shouldn't. Brand terms get adapted when an approved equivalent exists. Technical terms with a precise meaning in one context get rendered with a synonym that carries different connotations. These aren't errors of competence — they're errors of missing information. A glossary doesn't make the translator smarter; it gives them what they need to apply what they already know.
The issue is that most agencies build glossaries after projects rather than before them. A translation goes out. A client finds a terminology error. The agency logs the correction. Over months, the log becomes a termbase. But the error already reached the client.
A better approach: build a starter glossary as part of brief preparation. Five to ten core terms per domain prevents the most consequential errors. For a legal project, that means contract-specific defined terms. For a medical project, the product name, the anatomical terms relevant to the device, and any regulated vocabulary. For a marketing project, brand-voice terms that should never be literally translated.
When clients don't have a glossary and can't provide one, we build from their existing approved materials before the first project starts: website copy, past translations they've signed off on, product documentation. All of this yields working terminology. It takes time upfront. It reduces revision cycles on every project that follows. There's more on keeping this material consistent across a client's ongoing work in our guide on maintaining a client glossary across multiple projects and translators.
One thing that doesn't apply here: if you're working with a client who has a detailed, well-maintained termbase already, the brief simply points to it. The gap this section addresses is different — clients who say "we don't have a glossary" but do have consistent terminology in their approved materials if you look.
A translation brief template you can fill in before your next project
The structure below covers the core fields for most translation projects. For a recurring client with established context, it takes around five minutes to complete. For a new client or domain, closer to fifteen or twenty.
Translation project brief
Document details: type, word count, source format.
Purpose: what the document is for; what readers should do or understand after reading it.
Target audience: background, reading context, action intent. Three to four sentences, not a demographic label.
Target language and locale: be specific about the regional variant. European Portuguese and Brazilian Portuguese are different briefs.
Register: positive description of the tone, what to avoid, and one reference example in the target language.
Terminology: glossary attached; must-not-translate terms; brand-name and product name conventions.
References: style guide if one exists; examples of approved translations; competitor copy for tone reference.
Formatting notes: placeholders to preserve, character limits for UI strings, heading translation conventions.
Deadline and delivery format: date, file format, and any delivery logistics.
This isn't a mandatory document for every job. Long-standing client relationships with a maintained termbase and a solid QA history can run on considerably less formality. New clients, new domains, and new content types need all of it. The point is to give whoever is translating what they need to make good decisions without stopping to ask.
What to do when the client gives you nothing
A file arrives with a deadline and no additional context. This happens often, especially with small and medium-sized clients who don't have an internal localization function and don't know what information is useful to provide. The concept of a "translation brief" may not mean anything to them.
Asking "do you have a style guide?" almost always gets a "no," even when the client has approved translation examples they've never thought of in those terms.
Better questions: Can you send me the most recent translation your team approved? Can I have the URL of your website in the source language? Do you have any marketing materials that have already been adapted for the target market? What three words would you use to describe how you want to sound to readers in that language?
Most clients can answer these in under ten minutes. Website copy gives you tone and register. Approved past translations give you confirmed terminology. Market-specific examples give you regional conventions. The three adjectives give you something to reference if the client disputes a tone call later — now there's a record of the brief and what they said they wanted, rather than a conversation that happened over email and was never written down.
This approach works for clients without an internal localization function. It doesn't apply when a client has an established style guide they simply forgot to attach. In that case, ask for that specific document by name.
The broader point: a brief is not something only a client can write. Part of the project manager's role is to pull out the information that makes a good brief possible, even when the client doesn't know to volunteer it. The alternative is absorbing the cost of revisions that could have been avoided. That happens — but it shouldn't be treated as inevitable.
Start with the materials you have access to, fill in the fields you can answer without the client, and ask targeted questions for the rest. A brief built that way is imperfect but functional. A missing brief is neither.