Localization Brief Template (ISO 17100, XLIFF)

Localization Brief: [Product, release or content set]

Brief that a product or documentation team hands to translators, a language service provider (LSP) or an in-house localisation team for one release or content set. It fixes the locales, the source freeze, what is in and out of scope (UI strings, documentation, screenshots, media), terminology and do-not-translate rules, style per locale, the machine translation and post-editing policy, process steps, linguistic quality assurance (LQA), pseudo-localisation, internationalisation (i18n) readiness, schedule and handoff formats. Process step names follow ISO 17100:2015 (translation services, with Amendment 1:2017) and the post-editing policy uses the terms of ISO 18587:2017 (post-editing of machine translation output); file formats include XLIFF 2.1 (OASIS Standard, February 2018) and XLIFF 2.2 (OASIS Committee Specification, March 2025). Replace every [bracketed] value and every row marked Example. Worked examples use Corvid Commerce, a fictional SaaS retailer, localising its checkout UI and developer docs.

Document control

Approvals

Revision history

Contents

1. Purpose and context
2. Target locales
3. Source content and freeze
4. Scope by content type
5. Terminology and do-not-translate list
6. Style per locale
7. Machine translation and post-editing policy
8. Process steps and roles
9. Internationalisation readiness
10. Pseudo-localisation
11. Handoff formats and file rules
12. Linguistic quality assurance
13. Schedule and milestones
14. Queries, risks and acceptance
15. Glossary and references

1. Purpose and context

This brief requests translation and localisation of [content set] for [Product name] release [version]. It gives the linguists the context they need to make good decisions without asking: who reads the text, what the product does, which words are fixed and how quality will be judged.

Linguists receive access to the reference environment and must not use real customer data. Anything that looks like personal data in the source is a defect: report it as a query instead of translating it.

2. Target locales

Locales are written as BCP 47 language tags (RFC 5646 and RFC 4647), for example pt-BR for Brazilian Portuguese and zh-Hans-CN for Simplified Chinese as used in mainland China.

For each locale, state whether a single variant serves several markets (for example es-419 for Latin American Spanish) and who decides when a market needs its own variant. Locales marked priority 2 may ship one release later if the schedule in section 13 slips; priority 1 locales ship with the source.

3. Source content and freeze

Before the freeze, the source owners confirm that:

1. Strings have been reviewed for clarity and consistency with the termbase (Termbase (docs/termbase)).
2. Every string has a stable key and a developer comment where meaning is not obvious (button label versus heading, noun versus verb).
3. Placeholders are named, not positional ({orderId}, not %s).
4. Docs pages pass the checks in the Docs Contribution Guide (docs/docs-contribution-guide) and carry translate: true in their front matter.
5. Text that must not be translated is marked (section 5).

4. Scope by content type

4.1 Screenshots and media

Screenshots are recaptured from the localised staging environment after UI translation is signed off, never edited by hand. The capture script uses the same demo data in every locale so images stay comparable. Text inside diagrams is avoided; where it exists, the editable source is sent with the batch.

5. Terminology and do-not-translate list

The termbase is the single source for approved terms and their equivalents in each locale. Linguists use preferred terms, may use admitted terms where the preferred one does not fit, and never use deprecated terms. New terms found during translation are proposed to the terminologist through the query log, not invented per file.

Do-not-translate list (keep exactly as written in every locale):

6. Style per locale

Each locale follows its own style sheet. Where no style sheet exists, the vendor proposes one in the first week and the locale reviewer approves it.

General rules for every locale:

1. Translate meaning, not words; keep UI labels short enough to fit (section 9 gives the expansion allowance).
2. Use the locale's own conventions for dates, numbers, currencies and units. The product formats them at runtime; do not hard-code formats in translated strings.
3. Keep the source's level of certainty: "may" stays optional, "must" stays mandatory.
4. Do not add, remove or reorder steps in procedures.

7. Machine translation and post-editing policy

Machine translation (MT) is allowed only where this table says so. When MT is used, a qualified human post-editor edits every segment; raw MT output is never published.

Terms used in this policy follow ISO 18587:2017. Full post-editing aims at output that is indistinguishable in quality from human translation; light post-editing aims only at comprehensible output. The standard sets requirements for full post-editing and treats light post-editing as informative material only. This brief does not permit light post-editing for any published content.

Data protection rules for MT:

1. Use only engines approved in the vendor contract, with no retention or training on submitted text.
2. Never send unreleased product names, credentials, personal data or customer content to a public MT service.
3. The vendor states in the delivery note which segments were machine translated, so LQA can sample them separately.

Generative AI tools used for translation or terminology suggestions are treated as MT engines under this policy.

8. Process steps and roles

Translation, check, revision, review, proofreading and final verification and release follow ISO 17100:2015; revision is mandatory, while review and proofreading apply when the client specifies them. Preparation and LQA are project steps added by this brief. A different person from the translator performs the revision.

Roles and competence expectations are set in the vendor contract. The in-house domain reviewer has [Example: 3] working days per batch; silence after that time counts as acceptance only when the contract says so.

9. Internationalisation readiness

Engineering confirms each item before the source freeze. Items not met are listed as risks in section 14.

9.1 IME and RTL notes for linguists and testers

For Japanese, Chinese and Korean, test typing in search boxes, forms and the editor with a real IME: pressing Enter to confirm a conversion must not submit the form. For Arabic and other RTL scripts, test mixed-direction strings that contain order numbers, email addresses and English product names, and check that punctuation lands on the correct side.

10. Pseudo-localisation

Pseudo-localisation replaces source text with an altered version that stays readable but exposes problems: accented characters reveal encoding and font issues, padding reveals truncation, and brackets reveal concatenated or hard-coded strings.

Issues found are filed with the label i18n and must be fixed before the source freeze. A string that shows without brackets in the pseudo-locale is hard-coded and blocks the freeze.

11. Handoff formats and file rules

XLIFF 2.1 is the current OASIS Standard version. XLIFF 2.2, approved as an OASIS Committee Specification on 13 March 2025, is designed to stay compatible with 2.0 and 2.1; agree with the vendor before switching, and check the current status at docs.oasis-open.org/xliff.

File rules:

1. Encoding is UTF-8 for every file; no byte-order mark in Markdown.
2. File names keep the source name and add the locale folder: docs/de-DE/how-to/retry-refund-webhooks.md.
3. Placeholders, inline tags and Markdown syntax pass through unchanged; the vendor's QA tool checks tag and placeholder parity before delivery.
4. Files travel through [the agreed secure transfer method]; never by personal email or public file-sharing links.

12. Linguistic quality assurance

LQA samples delivered content in context (running UI or rendered docs) and scores errors by category and severity. Preferential changes are recorded but do not count as errors.

LQA results are logged per locale and batch with the ID pattern LQA-<locale>-NNN (for example LQA-de-DE-001 (Example)).

13. Schedule and milestones

14. Queries, risks and acceptance

14.1 Query log

Answers that affect more than one locale are broadcast to all linguists and, when they concern a term, added to the termbase.

14.2 Risks

14.3 Acceptance

A locale is accepted when final verification is recorded, LQA passes, all queries are closed and the localised build passes the product's functional tests. Acceptance is recorded in the Approvals table of a copy of this brief or in the localisation tracker.

15. Glossary and references

Standard and licence note

Structure aligned with ISO 17100:2015 (with Amendment 1:2017) and ISO 18587:2017, which are copyrighted by ISO: only process step names and the names of post-editing levels are cited, and every explanation is original. TBX is cited by its standard number and name (ISO 30042:2019). File format details are based on the OASIS XLIFF Version 2.1 Standard and XLIFF Version 2.2 Committee Specification, cited by name and status only. Locale tags follow BCP 47 (IETF). Revisions of ISO 17100, ISO 18587 and ISO 30042 are in development: check the current official versions at iso.org and docs.oasis-open.org before relying on this brief. The error categories, severities, weights and thresholds in section 12 are examples, not requirements of any standard. Corvid Commerce is fictional. Original text written for this collection. Template licence: MIT.