Localization and Multilingual Content

Localization Content Brief

Give localization teams the audience, purpose, terminology, interface context, source evidence, adaptation boundaries, variables, and review path they need.

Free editable Markdown · Localization managers, translators, and content designers · Updated July 30, 2026

Download Markdown

Accessible HTML preview

Blank template

The downloaded file contains the same fields in editable Markdown.

Project and audience

Project and asset ID: [Enter]
Source URL/file and version: [Enter]
Source locale: [Enter language and locale]
Target locale: [Enter language, region, and script where relevant]
Reader situation and prior step: [Describe]
Required reader outcome: [Describe]
Channel and content type: [Web / Email / Product UI / Help / Other]
Release date and dependency: [Enter]
Localization owner: [Name/team]

Context packet

Safe preview or screenshots: [Enter reference]
Character or layout constraints: [List]
Connected controls and destinations: [Describe]
Source evidence for material claims: [List]
Related assets: [Terms, privacy, help, campaign, other]
Known source ambiguities: [List with resolution owner]
Tone, relationship, and formality: [Describe]
Accessibility context: [Reading order, alt text, captions, labels]

Terminology and protected elements

Product and feature names: [Approved handling]
Termbase entries: [Source term / Definition / Approved target / Avoid / Example]
Variables and placeholders: [Syntax, meaning, sample rendered value]
Commands, code, and filenames: [Translate / Preserve / Explain]
Names and addresses: [Handling]
Dates, times, numbers, currencies, and units: [Locale rules]
Quoted or regulated text: [Owner and required handling]
URLs: [Localized destination / Source destination / Do not link]

Adaptation boundaries

Meaning that must not change: [List claims, conditions, limitations]
Examples that may localize: [Scope and approval]
Idioms or cultural references: [Replace / Explain / Preserve]
Call-to-action flexibility: [Describe]
Search language research: [Approved query language, if relevant]
Prohibited additions or omissions: [List]
Questions for the source owner: [List]

Review and release

Translation and review owners: [Names/dates]
Defects and resolution: [List or None]
Final approver and version: [Name/version/date]
Source-change monitoring owner: [Name/team]

Source version was locked and ambiguities were resolved.
Translation is complete with no unapproved fallback text.
A qualified linguistic reviewer checked fluency and terminology.
A subject or product owner verified claims and instructions.
Variables, links, layout, reading order, and interaction were tested.
Dates, numbers, units, names, and locale conventions were checked.

How to use this template

Define the source asset, target locale, reader situation, task, channel, and release.
Package the locked source, screenshots, evidence, terminology, variables, and known ambiguities.
Mark invariant meaning and clearly authorize only the adaptations appropriate to the locale.
Assign translation, linguistic review, subject review, functional QA, and final approval.
Track source changes, resolve defects by locale, and publish only reviewed equivalents.

Explain the reader, task, and product situation

A translator needs to know who encounters the content, what happened immediately before it, and what the reader must understand or do next. Record the target locale rather than only a language, because date formats, formality, terminology, regulation, units, and interface expectations can differ. Provide screenshots or a safe preview that shows text beside controls, errors, images, and space constraints. Identify whether the asset is marketing, help, research, transactional, or policy-related and whether the reader is new, returning, stressed, or blocked. Without context, a short label can have several equally grammatical but functionally different translations.

Separate fixed meaning from adaptable expression

Mark product names, verified claims, legal text, variables, commands, URLs, and controlled terminology that must follow approved rules. Then describe what may adapt: examples, idioms, measurement units, calls to action, sentence order, or cultural references. Adaptation is not permission to invent a product benefit or delete a limitation. Include source evidence for material claims and note ambiguity rather than asking translators to guess. A termbase entry should include definition, grammatical context, approved translation, prohibited alternatives, and an example. If source copy is confusing, resolve it before locking the version; localization should not multiply an unresolved source defect.

Build linguistic and functional review into release

Define who translates, who reviews language, who verifies product or subject meaning, and who tests the rendered experience. QA should cover omissions, additions, terminology, numbers, dates, links, variables, truncation, line breaks, reading order, and localized destinations. Avoid publishing machine-generated translations as reviewed simply because they are fluent. When a qualified reviewer is unavailable, keep the locale in draft rather than serving English fallback at a localized URL. Record source changes after handoff and reopen affected strings. A last-updated date, version, and owner help each locale remain accurate after the original page changes.

See the fields in context

Fictional example: storage warning for French in Canada

MapleNote is an invented product. The warning, feature, and localization decision below are not real instructions.

Reader context: A fictional French-Canadian user is about to delete a local notebook before cloud synchronization finishes.
Fixed meaning: Deletion cannot be reversed after the imaginary 30-day recovery period; the number and limitation require product verification.
Adaptation: The reviewer changes sentence order to put the consequence before the action and applies approved Canadian French terminology.
Functional QA: A long localized button is tested at narrow width, and its help link points to a reviewed French destination.
Release: The locale remains draft until linguistic and product reviewers approve the same source version.

Frequently asked questions

What is the difference between translation and localization?

Translation transfers language. Localization also adapts permitted formats, examples, terminology, layout, destinations, and context for a specific locale while preserving required meaning.

Can one brief cover every language?

A shared core can describe the asset, but each target locale needs its own audience, terminology, adaptation decisions, reviewers, destinations, and release status.

What should happen when the source changes mid-project?

Log the exact source change, identify affected strings and claims, pause release where necessary, and reopen translation, review, and QA for those parts.

Is machine translation acceptable as a draft?

That depends on policy, sensitivity, and content type. A draft generated by a tool still requires qualified review and must not be labeled reviewed until it passes the defined checks.