Translation Brief Template - Bubbles Translation Services

Download Translation Brief Template (PDF)

Why Briefs Matter

The quality of a translation project is shaped long before a translator starts work. It begins with the brief.

A good brief gives the translation team everything they need to make informed decisions — about terminology, tone, audience, and context. A poor brief leaves them guessing. And guessing, in translation, leads to inconsistencies, misaligned tone, and rework that costs time and money.

This isn’t about creating bureaucracy. It’s about giving your translation partner the information they need to get it right first time.

The difference between a strong brief and a weak one is often the difference between a project that runs smoothly and one that generates rounds of corrections.

The Template

Use this template when briefing any translation project. Not every field will be relevant to every project — but the more context you provide, the better the result.

Project Overview

Project name / reference:
[Your internal reference for this project]

Contact person:
[Name and email of the person the translation team should contact with questions]

Deadline:
[Required delivery date. If there are interim milestones — e.g., first language due before others — note them here]

Budget considerations:
[Any budget constraints. If you need a quote before proceeding, say so here rather than after translation has started]

Source Material

Document title(s):
[List all documents included in this project]

Source language:
[Usually English — but confirm, especially for projects involving multiple source languages]

Target language(s):
[List every target language required. Be specific: “Brazilian Portuguese” not just “Portuguese”; “Simplified Chinese” not just “Chinese”; “Latin American Spanish” not just “Spanish”]

Word count:
[Total word count of source material. If you can’t count it (e.g., PDFs or images with embedded text), note that and the translation agency will assess]

File format(s):
[List formats provided — Word, InDesign, FrameMaker, XML, HTML, Excel, PDF, etc. Editable source files are always preferable to locked PDFs]

Files with embedded text:
[Note any images, diagrams, screenshots, or illustrations that contain text requiring translation]

Context and Purpose

What is this document?
[Describe the document type: user manual, marketing brochure, safety data sheet, website content, contract, training material, etc.]

Who will read it?
[Describe the audience: engineers, end consumers, procurement teams, medical professionals, factory operatives, etc. Include their likely technical level]

What is the purpose?
[What should the reader do or understand after reading? Examples: operate machinery safely, make a purchasing decision, comply with a regulation, complete a training module]

Where will it be used?
[Website, printed brochure, product packaging, regulatory submission, training platform, internal intranet, etc.]

Tone and Style

Tone:
[Formal / semi-formal / informal / technical / conversational. If the document mixes tones — e.g., technical content with a conversational introduction — note that]

Brand voice guidelines:
[Attach or describe any brand guidelines the translation should follow. If there’s a style guide, include it]

Formality level by market:
[If you know that certain markets require different formality — e.g., formal “Sie” in German vs informal “du” — specify here. If you’re unsure, say so and ask the translation team to advise]

Terminology

Preferred terminology:
[List any specific terms that must be translated in a particular way. Product names, proprietary terms, technical vocabulary with preferred translations]

Terms NOT to translate:
[Product names, brand names, acronyms, or technical terms that should remain in English across all language versions]

Glossary or termbase available?
[If you have an existing glossary, terminology database, or translation memory from previous projects, provide it. This is one of the most valuable things you can supply]

Previous translations:
[Provide any previous translations of similar or related content. These help ensure consistency and can reduce cost through translation memory leverage]

Technical Requirements

DTP / layout required?
[Does the translation agency need to handle desktop publishing — flowing text into InDesign, FrameMaker, or similar? Or will you manage layout in-house?]

Output format:
[What format do you need the translations delivered in? Same as source? Different format? Print-ready PDF?]

Special formatting:
[Any specific formatting requirements — e.g., tracked changes, bilingual format, specific font requirements, character encoding]

Quality assurance process:
[Will the translations be reviewed by an in-market contact? If so, who, and what’s the process for handling their feedback?]

Regulatory or Compliance Context

Applicable regulations:
[Is this documentation subject to specific regulations? EU MDR, Machinery Regulation, REACH/CLP, CE marking, industry-specific standards, etc.]

Certification requirements:
[Does this translation require certification or sworn/certified status?]

Regulatory submission:
[Will this documentation be submitted to a regulatory authority or notified body? If so, are there specific format or language requirements?]

Additional Information

Anything else the translation team should know:
[Context that doesn’t fit elsewhere. Background on the project, changes from previous versions, sensitivity around certain content, political or cultural considerations, etc.]

Good Brief Example

Here’s what a strong brief looks like in practice:

Project name: Fortress FT-200 Series Service Manual — German, French, Spanish

Contact: Sarah Thompson, s.thompson@fortress-tech.com

Deadline: 15 March 2026 (all three languages)

Source: English, 12,400 words. InDesign source files attached plus PDF for reference.

Target languages: German (Germany), French (France), Spanish (Spain)

Document: Service and maintenance manual for the FT-200 Series metal detection system. Used by field service engineers to install, calibrate, maintain, and troubleshoot the equipment.

Audience: Qualified service engineers with technical background. Assume familiarity with metal detection technology and food processing environments.

Purpose: Enable service engineers to perform installation, routine maintenance, and fault diagnosis without reference to English documentation.

Tone: Technical, precise, instructional. Not conversational. Formal throughout.

Terminology: Glossary attached (FT-200 term list, v3.2). Key terms: “reject system” (not “rejection mechanism”), “product effect” (do not translate — industry standard term used in English across markets), “HACCP” (keep as acronym).

Previous translations: German and French v2.1 manuals attached. Spanish is new for this product.

DTP: Yes — please flow into InDesign. We’ll handle final print production but need print-ready PDFs for proofing.

Regulatory: CE marked product. Documentation forms part of the technical file. Must comply with Machinery Directive documentation requirements (transitioning to Machinery Regulation for next revision).

Notes: Sections 4.3–4.7 are new in this version (calibration procedures updated). Previous translation memory should be valid for remaining sections. Images on pages 12, 18, and 23 contain English text that needs translating — editable Illustrator files attached.

This brief tells the translation team everything they need. No guessing. No back-and-forth emails clarifying basics. Translation starts on day one, not after a week of questions.

Poor Brief Example

Here’s what happens without adequate context:

Email subject: Translation needed

Body: Hi, can you translate the attached into European languages? Need it ASAP. Thanks.

Attachment: FT-200-Manual-FINAL-v4-DRAFT(2).pdf

What’s missing — and what it costs:

“European languages” — Which ones? All 24? The big four? The translation team has to ask, which delays the quote and the start date.

“ASAP” — When, specifically? Tomorrow? Next week? Next month? Without a date, the project can’t be scheduled, and “ASAP” often means “after everyone else’s properly scheduled projects.”

“FINAL-v4-DRAFT(2)” — Is this final or draft? If it’s going to change, the translation team needs to know — translating a document that’s then revised creates unnecessary cost.

PDF only — No editable source files. The translation team either has to extract text from PDF (slower, less accurate word count, layout challenges) or ask for the source files — which delays the project.

No context — Who’s reading it? What’s the product? What tone? Any previous translations? Preferred terminology? The translator has to guess or research, which takes time and introduces risk.

No terminology guidance — Should “reject system” be translated literally, or is there an established industry term? Without guidance, the translator makes a choice — which may or may not match what your engineers expect.

This brief creates 3–5 emails of clarification before any translation begins. It delays the project by days. And it increases the risk of a result that doesn’t meet expectations.

Tips for Better Briefs

Provide source files, not just PDFs. Editable files (Word, InDesign, FrameMaker, XML) are faster and cheaper to translate than locked PDFs. They also produce better-formatted output.

Be specific about languages. “Portuguese” means different things in different contexts. Brazilian Portuguese and European Portuguese are distinct. Simplified Chinese and Traditional Chinese are different writing systems. Specify exactly what you need.

Share your glossary — even an informal one. A spreadsheet of key terms with preferred translations is enormously valuable. Even a list of terms that should NOT be translated (brand names, product names, industry acronyms) saves time and prevents errors.

Send previous translations. If you’ve had similar content translated before — even by a different provider — sharing those files helps build translation memory and ensures consistency. This also reduces cost, because segments that match previous translations don’t need translating from scratch.

Be honest about the timeline. If the deadline is genuinely tight, say so — the translation team can plan accordingly. If there’s flexibility, say that too. “We’d like it by Friday but Wednesday the following week is fine” is far more useful than “ASAP.”

Name one contact person. Multiple reviewers feeding back separately creates conflicting corrections. One person to channel questions and approve translations keeps the process clean.