Localization and Multilingual Content

Translation Context Packet

Package source references, screenshots, user flow, product behavior, variables, constraints, terminology, evidence, and ambiguity decisions for translators.

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

Download Markdown

Accessible HTML preview

Blank template

The downloaded file contains the same fields in editable Markdown.

Packet overview

Project and packet ID: [Stable identifier]
Packet version and date: [Version and YYYY-MM-DD]
Source locale and version: [Locale, commit, build, or file]
Target locales: [List]
User audience and situation: [Who, when, and why]
Content type and risk: [Product, help, campaign, policy, or another]
Localization owner: [Name and contact]
Source content owner: [Name and contact]
Implementation contact: [Name and contact]
Question deadline and release: [Dates]
Access and privacy limits: [Safe preview and prohibited data]

Asset and flow manifest

Asset or screen ID: [Stable reference]
Source file or URL: [Location]
Annotated screenshot or preview: [Safe reference]
Prior user step: [What just happened]
Current state and behavior: [What the product shows or does]
Available next actions: [Controls and destinations]
Related strings or media: [IDs]
Hidden or alternate states: [Error, loading, empty, success, permission, or other]
Layout and accessibility context: [Order, label association, caption, alt purpose]
Source evidence: [For claims, numbers, or instructions]

String context record

String ID and exact source: [Enter]
Content role: [Heading, label, button, status, message, metadata, or other]
Audience relationship and formality: [Enter]
Meaning and intended outcome: [Plain explanation]
Approved terminology: [Termbase links]
Variables and sample render: [Token, type, meaning, and example]
Plural, gender, or agreement behavior: [Rules]
Protected syntax: [Code, command, product name, filename, or URL]
Character or timing constraint: [Reason and tested boundary]
Permitted adaptation: [Examples, order, unit, idiom, or none]
Known ambiguity: [Question and owner]

Handoff and change control

Question log: [ID, question, answer, owner, date, affected strings]
Source changes after handoff: [Before, after, reason, affected IDs]
Translator acknowledgment: [Name and date]
Final packet approver: [Name, version, and date]
Archive location: [Enter]

Screenshots and source files describe the same version.
No live personal, confidential, credential, or secret data is exposed.
Fragmented strings and token-order risks were reviewed with implementation.
Claims, terminology, links, and related assets have usable references.
Questions have owners, shared answers, and release consequences.

How to use this template

Lock the source version and map every asset or string ID to its user flow, state, placement, and owner.
Add safe annotated visuals, source references, product behavior, audience, terminology, and material claim evidence.
Explain variables, plurals, protected syntax, layout behavior, media, links, and localized dependencies.
Record ambiguities in a shared question log and resolve source defects before translation where possible.
Version the packet, notify translators of changes, and archive the approved context with review and release evidence.

Reconstruct the experience around each string

Show where the content appears, what happened immediately before it, what the user can do next, and what changes after the action. Provide annotated screenshots or a safe preview with stable IDs that match the source file. Include hidden states such as errors, empty results, permission denials, confirmations, and time-sensitive messages. Identify whether text is a heading, label, instruction, button, status, notification, metadata field, spoken line, or alternative description. Short strings are especially ambiguous: “Open” might be an adjective, status, or command, and each requires a different grammatical decision.

Explain technical tokens and content dependencies

Document placeholders with meaning, data type, sample rendered values, order flexibility, plural behavior, gender implications, escaping, and any syntax that must remain unchanged. Mark product names, code, commands, filenames, URLs, and values that should not be translated. Record character limits as real interface constraints, not arbitrary requests for shorter language. Link terminology, style, claims evidence, related help, and previous approved translations. If a string is assembled from fragments, ask the implementation owner whether it can become a complete message; concatenation often prevents natural word order and agreement.

Keep the packet versioned and answerable

Name the source owner, engineering or implementation contact, localization owner, and deadline for questions. Use a question log so decisions reach every affected translator instead of remaining in private messages. When the source, screenshot, behavior, or token schema changes, increment the packet version and identify invalidated translations. Protect access to prototypes and user data. Archive the approved packet with the translation release so future reviewers can reconstruct why a choice was made. Context is part of the source, and stale context can produce fluent but functionally incorrect work.

See the fields in context

Fictional example: scheduled export status

Cedar Index is an invented records tool, and the interface behavior below is illustrative.

String: “Ready in {minutes}” appears beside an export that has been requested but is not yet downloadable.
Context: The screenshot shows a clock icon, a cancel action, and a separate notification setting; “ready” describes future timing rather than current status.
Token note: `{minutes}` is an integer with locale-aware plural forms and sample values of 1, 2, and 25.
Question: The source owner confirms that the estimate can increase, so the target must not imply a guaranteed deadline.
Change control: An updated product state adds “paused”; the packet receives a new version and affected translations reopen.

Frequently asked questions

How is this different from a localization brief?

A brief defines project purpose, boundaries, audience, and review. A context packet supplies operational evidence for the exact source: screens, states, IDs, behavior, tokens, dependencies, and answers.

Do translators need access to the live product?

Not always. Provide the safest context that supports correct work, such as sanitized screenshots, recordings, prototypes, or documented flows. Never expose production data unnecessarily.

What should we do with a character limit?

Explain the actual rendered boundary and test target-language text in context. Do not demand unnatural abbreviation when the interface can reasonably expand or wrap.

How should unanswered questions be handled?

Assign an owner and deadline. If the ambiguity could change meaning or function, hold the affected content rather than asking the translator to guess.