# 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.

<!--
Guidance: How to use this template
- Write one brief per release or content set. Reuse the locale, style and
  terminology sections between briefs; change the scope, freeze and
  schedule each time.
- Fill sections 2 (locales), 3 (source freeze) and 4 (scope) first. A
  translator cannot quote or plan without them.
- Send the termbase and do-not-translate list with the brief, not after
  the first batch has been translated.
- The brief describes the work; it does not replace the contract or the
  data processing terms with the LSP.
-->

## Document control

<!-- Guidance: Identify the release, the requester and the vendor contact so queries reach the right person. -->

| Field | Value |
|---|---|
| Document ID | [L10N-BRIEF-001] |
| Version | [0.1] |
| Status | [Draft / Sent to vendor / Accepted / Closed] |
| Owner | [@l10n-coordinator] |
| Approvers / reviewers | [@product-manager], [@docs-lead], [@engineering-lead], [@vendor-project-manager] |
| Last updated | YYYY-MM-DD |
| Classification | [Confidential: contains unreleased product information] |
| Release or content set | [*Example:* Checkout 2026.11, UI plus developer docs] |
| Language service provider | [Vendor name or in-house team] |
| Source locale | [*Example:* en-US] |
| Target locales | [See section 2] |
| Related | Termbase (`docs/termbase`), Technical Writing Style Guide (`docs/style-guide-technical`), Docs Contribution Guide (`docs/docs-contribution-guide`) |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Localisation coordinator | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Product manager | [@name] | [Decision] | YYYY-MM-DD |
| Documentation lead | [@name] | [Decision] | YYYY-MM-DD |
| Vendor project manager | [@name] | [Accepted] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record changes to scope, locales and dates; vendors quote against a specific version. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* ar-SA added; schedule moved by one week |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Accepted by vendor |

## Contents

<!-- Guidance: Keep aligned with the headings. -->

1. [Purpose and context](#1-purpose-and-context)
2. [Target locales](#2-target-locales)
3. [Source content and freeze](#3-source-content-and-freeze)
4. [Scope by content type](#4-scope-by-content-type)
5. [Terminology and do-not-translate list](#5-terminology-and-do-not-translate-list)
6. [Style per locale](#6-style-per-locale)
7. [Machine translation and post-editing policy](#7-machine-translation-and-post-editing-policy)
8. [Process steps and roles](#8-process-steps-and-roles)
9. [Internationalisation readiness](#9-internationalisation-readiness)
10. [Pseudo-localisation](#10-pseudo-localisation)
11. [Handoff formats and file rules](#11-handoff-formats-and-file-rules)
12. [Linguistic quality assurance](#12-linguistic-quality-assurance)
13. [Schedule and milestones](#13-schedule-and-milestones)
14. [Queries, risks and acceptance](#14-queries-risks-and-acceptance)
15. [Glossary and references](#15-glossary-and-references)

## 1. Purpose and context

<!-- Guidance: Tell the linguist who the readers are and what the product does, in plain words. Pitfall: a brief that assumes the translator has used the product. -->

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.

| Item | Value |
|---|---|
| Product summary | [*Example:* Corvid Commerce Checkout lets online shops take card and wallet payments and issue refunds] |
| Audience | [*Example:* shop owners (UI) and developers integrating the Orders API (docs)] |
| Purpose of this release | [*Example:* new partial refund flow and a refund webhook] |
| Reference environment | [*Example:* staging tenant `corvid-l10n-demo` with read-only test accounts] |
| Previous translations | [*Example:* translation memory from release 2026.08, all locales] |
| Contacts | Requester [@name], technical queries [@name], vendor PM [@name] |

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

<!-- Guidance: Use BCP 47 language tags, and say which locale variant and script you want. Pitfall: "Spanish" or "Chinese" without region or script, which produces the wrong variant. -->

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.

| Locale tag | Language and market | Direction | Content in scope | Linguist pool | Priority |
|---|---|---|---|---|---|
| de-DE *(Example)* | German, Germany | LTR | UI, docs, screenshots | Vendor | 1 |
| fr-FR *(Example)* | French, France | LTR | UI, docs | Vendor | 1 |
| ja-JP *(Example)* | Japanese, Japan | LTR | UI, docs, screenshots | Vendor | 1 |
| pt-BR *(Example)* | Portuguese, Brazil | LTR | UI only | Vendor | 2 |
| ar-SA *(Example)* | Arabic, Saudi Arabia | RTL | UI only | Vendor, RTL specialist | 2 |

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

<!-- Guidance: Give a date after which the source does not change, and the rule for late changes. Pitfall: no freeze, so the vendor translates moving text and bills twice. -->

| Item | Value |
|---|---|
| Source freeze (UI strings) | YYYY-MM-DD, [time and time zone] |
| Source freeze (docs) | YYYY-MM-DD |
| Source repository and commit | [*Example:* `corvid/checkout@<commit>`, `corvid/developer-docs@<commit>`] |
| Word count (new / fuzzy / repetitions) | [From the vendor's analysis against the translation memory] |
| Late change rule | [*Example:* changes after freeze go into a follow-up batch unless they fix a legal or safety issue] |

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

<!-- Guidance: List every content type, in or out, with its format and volume. Pitfall: screenshots, alt text and error messages forgotten until the end. -->

| ID | Content type | In scope? | Format | Volume | Notes |
|---|---|---|---|---|---|
| L10N-SC-01 *(Example)* | UI strings (web app) | Yes | XLIFF 2.1 | [*Example:* 1,240 strings] | Includes error messages and empty states |
| L10N-SC-02 *(Example)* | Transactional emails | Yes | XLIFF 2.1 | [*Example:* 18 templates] | Keep merge fields unchanged |
| L10N-SC-03 *(Example)* | Developer docs pages | Yes | Markdown | [*Example:* 42 pages] | Code blocks not translated; comments in code translated |
| L10N-SC-04 *(Example)* | Image alt text and captions | Yes | Within Markdown | Included above | Must be translated, never left in English |
| L10N-SC-05 *(Example)* | Screenshots | Yes, priority 1 locales | Recaptured from localised staging | [*Example:* 35 images] | See section 4.1 |
| L10N-SC-06 *(Example)* | Video subtitles | No | Not applicable | Not applicable | Planned for next release |
| L10N-SC-07 *(Example)* | API reference (generated) | No | Not applicable | Not applicable | Stays in English; descriptions only on request |
| L10N-SC-08 *(Example)* | Legal terms | No | Not applicable | Not applicable | Handled by legal counsel and certified translators |

### 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

<!-- Guidance: Send the termbase export and a short do-not-translate list; say who approves new terms. Pitfall: product names translated in one locale and kept in another. -->

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.

| Item | Value |
|---|---|
| Termbase export | [*Example:* `corvid-termbase-2026-10.tbx` (TBX-Basic) and a CSV copy] |
| Terminology owner | [@terminologist] |
| New term approval time | [*Example:* 2 working days per locale] |

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

| ID | Text | Type | Rule |
|---|---|---|---|
| DNT-001 *(Example)* | Corvid Commerce | Company name | Never translate or transliterate in Latin-script locales; ja-JP uses the approved katakana in the termbase |
| DNT-002 *(Example)* | Orders API | Product name | Keep in English |
| DNT-003 *(Example)* | `refund.created` | Event name | Code; keep including punctuation |
| DNT-004 *(Example)* | `{orderId}`, `{amount}` | Placeholders | Keep; move within the sentence as grammar requires |
| DNT-005 *(Example)* | HTTP, JSON, SKU | Technical abbreviations | Keep; expand only where the locale style guide asks |

## 6. Style per locale

<!-- Guidance: Give each locale its formality, conventions and reference style guide. Pitfall: mixing formal and informal address across screens. -->

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.

| Locale | Address form | Tone | Number and date format | Notes |
|---|---|---|---|---|
| de-DE *(Example)* | Formal "Sie" | Direct, neutral | `1.234,56 EUR`, `24.10.2026` | Compound nouns per termbase; avoid anglicisms where a common German term exists |
| fr-FR *(Example)* | "Vous" | Courteous, concise | `1 234,56 EUR`, `24/10/2026` | Non-breaking space before `:` `;` `!` `?` |
| ja-JP *(Example)* | Polite form (desu/masu) | Neutral | `1,234.56`, `2026/10/24` | Full-width punctuation in prose; half-width in code and UI keys |
| ar-SA *(Example)* | Formal | Neutral | Locale default from CLDR | Mirrored layout; Western or Eastern Arabic digits per approved style sheet |

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

<!-- Guidance: State per content type whether MT is allowed, which engine, what level of post-editing, and the data protection rule. Pitfall: unapproved public MT engines receiving confidential source text. -->

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.

| Content type | MT allowed? | Engine | Post-editing level | Reason |
|---|---|---|---|---|
| UI strings *(Example)* | No | Not applicable | Not applicable | Short, context-dependent strings; MT saves little and risks errors |
| Developer docs *(Example)* | Yes | [Approved engine under contract] | Full post-editing | Large volume, consistent technical style |
| Knowledge base updates *(Example)* | Yes | [Approved engine] | Full post-editing | Frequent small updates |
| Legal or safety text *(Example)* | No | Not applicable | Not applicable | Requires human translation and specialist review |

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

<!-- Guidance: Name each step, who does it and what it produces. Revision by a second linguist is the step most often skipped under time pressure. -->

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.

```mermaid
flowchart LR
    A[Preparation and analysis] --> B[Translation]
    B --> C[Check by translator]
    C --> D[Revision by second linguist]
    D --> E[Review by domain reviewer]
    E --> F[In-context check and LQA]
    F --> G[Final verification and release]
    D -. queries .-> Q[Query log]
    B -. queries .-> Q
```

| Step | Performed by | Output |
|---|---|---|
| Preparation and analysis | Vendor PM | Word count, quote, pretranslation from translation memory, file check |
| Translation | Translator (competences and qualifications agreed in the contract, domain experience) | Translated files, queries logged |
| Check | Same translator | Self-check for meaning, omissions, terms and placeholders |
| Revision | Second linguist (reviser) with equal or higher competence | Bilingual comparison of source and target, corrections tracked |
| Review | Domain reviewer, usually in-country product staff | Monolingual review for domain fit and readability |
| Proofreading | Vendor (for typeset or image content only) | Corrections on rendered output |
| Final verification and release | Vendor PM, then localisation coordinator | Delivery note, files returned, sign-off recorded |

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

<!-- Guidance: Confirm the product can carry translations before money is spent on them. Pitfall: concatenated strings and hard-coded formats discovered after translation. -->

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

| ID | Requirement | Status |
|---|---|---|
| I18N-01 | All user-visible text is externalised; no strings built by concatenation | [Met / Not met] |
| I18N-02 | Plurals and gender use a message format with plural categories (for example ICU MessageFormat), not `if count == 1` | [Status] |
| I18N-03 | Dates, numbers, currencies and lists are formatted at runtime with locale-aware APIs (for example `Intl` in browsers) using CLDR data | [Status] |
| I18N-04 | Layout tolerates text expansion of [*Example:* up to 100% for labels under 10 characters, 50% for short phrases, 30% for sentences] for target languages that expand against an English source (German, Finnish, Russian) without truncation; CJK targets usually contract in width but need more line height | [Status] |
| I18N-05 | Text input handles input method editors (IME): key handlers ignore events while composition is active (for example `event.isComposing` in browsers, and also ignore `keydown` events with `keyCode` 229, which some browsers send for the key that ends a composition) | [Status] |
| I18N-06 | RTL locales use logical CSS properties (`margin-inline-start`), the `dir` attribute and mirrored icons where direction has meaning | [Status] |
| I18N-07 | User-supplied or code text inside RTL sentences is isolated (for example `<bdi>` or Unicode isolate characters) | [Status] |
| I18N-08 | Fonts cover every target script, including CJK and Arabic, and are served locally | [Status] |
| I18N-09 | Sorting and search use locale-aware collation | [Status] |
| I18N-10 | Strings carry developer comments and screenshots or context links for linguists | [Status] |

### 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

<!-- Guidance: Run pseudo-localisation before the freeze to find i18n bugs cheaply. Pitfall: running it once at project start and never again. -->

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.

| Setting | Value *(Example)* |
|---|---|
| Character mapping | Latin letters replaced with accented forms (`Refund` becomes `Ŕéƒüñð`) |
| Expansion | Pad short strings (under 10 characters) by up to 100% and longer strings by 30% |
| Delimiters | Wrap each string in `[` and `]` so cut-off text is visible |
| RTL pseudo-locale | Mirror layout with a test RTL locale to check direction handling |
| Where | Every pull request preview for the UI; nightly build for docs |

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

<!-- Guidance: Name the exact formats and versions, and the rules for placeholders, markup and encoding. Pitfall: vendors converting files in a way that breaks keys or markup. -->

| Content | Format sent | Format returned | Rules |
|---|---|---|---|
| UI strings | XLIFF 2.1 (`.xlf`) | XLIFF 2.1 | Keep unit `id` values; keep inline codes; do not add or remove units |
| Docs pages | Markdown with front matter | Markdown | Translate `title`, `description` and body; keep keys, code blocks, URLs and anchors |
| Terminology | TBX (TBX-Basic dialect) and CSV | Term proposals in the query log | Proposals reviewed by the terminologist |
| Translation memory | TMX export of the previous release | Updated TMX | Vendor returns the memory with the delivery |
| Screenshots | PNG captured by script | Not returned | Captured by the product team after sign-off |

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

<!-- Guidance: Define error categories, severities, sample size and the pass rule before work starts. Pitfall: "quality" judged by personal preference after delivery. -->

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.

| Category | Examples |
|---|---|
| Accuracy | Mistranslation, omission, addition, untranslated text |
| Terminology | Term not matching the termbase, inconsistent terms |
| Language | Grammar, spelling, punctuation for the locale |
| Style | Wrong address form, tone or register against the locale style sheet |
| Locale conventions | Wrong date, number, currency or address format |
| Markup and functionality | Broken placeholder, tag, link or truncation in the UI |

| Severity | Definition | Weight *(Example)* |
|---|---|---|
| Critical | Could cause legal, safety or financial harm, or blocks a task | 10 |
| Major | Changes meaning or confuses the reader, but the task can be completed | 5 |
| Minor | Noticeable but does not change meaning | 1 |

| Rule | Value *(Example)* |
|---|---|
| Sample | 10% of new words per locale, at least 1,000 words, plus all UI strings on the checkout path |
| Score | Sum of weighted errors per 1,000 words |
| Pass | Score at or below 15 and no critical error |
| Fail | Vendor corrects the full batch, not only the sample, and LQA repeats |

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

<!-- Guidance: Work backwards from the release date and leave a buffer for screenshots and LQA. Pitfall: translation scheduled to end on release day. -->

```mermaid
gantt
    title Example schedule (Corvid Checkout 2026.11)
    dateFormat YYYY-MM-DD
    section Source
    i18n and pseudo-localisation fixes :a1, 2026-10-26, 5d
    Source freeze                     :milestone, m1, 2026-11-02, 0d
    section Translation
    Translation and check             :b1, 2026-11-02, 6d
    Revision                          :b2, after b1, 3d
    Domain review                     :b3, after b2, 3d
    section Integration
    Build localised staging           :c1, after b3, 1d
    Screenshots and LQA               :c2, after c1, 3d
    Fixes and final verification      :c3, after c2, 2d
    Release                           :milestone, m2, after c3, 0d
```

| Milestone | Date | Owner |
|---|---|---|
| Brief accepted and quote approved | YYYY-MM-DD | Localisation coordinator |
| Source freeze | YYYY-MM-DD | Product and docs owners |
| Translated files delivered | YYYY-MM-DD | Vendor PM |
| Domain review complete | YYYY-MM-DD | In-country reviewers |
| LQA pass for priority 1 locales | YYYY-MM-DD | LQA reviewer |
| Release | YYYY-MM-DD | Release manager |

## 14. Queries, risks and acceptance

<!-- Guidance: Keep one query log for all locales, record risks and define how the batch is accepted. -->

### 14.1 Query log

| ID | Locale | String key or page | Question | Answer | Status |
|---|---|---|---|---|---|
| Q-001 *(Example)* | All | `refund.partial.cta` | Is "Refund" a verb (button) or a noun (heading) here? | Verb, button label | Closed |
| Q-002 *(Example)* | ja-JP | `docs/how-to/retry-refund-webhooks.md` | Translate "webhook" or keep in English? | Use termbase entry TERM-0007 | Closed |

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

| ID | Risk | Impact | Mitigation | Owner |
|---|---|---|---|---|
| L10N-R-01 *(Example)* | Late UI changes after freeze | Rework cost, delay | Follow-up batch rule in section 3 | Product manager |
| L10N-R-02 *(Example)* | RTL layout bugs found during LQA | ar-SA slips one release | Pseudo-RTL testing in section 10 | Engineering lead |
| L10N-R-03 *(Example)* | No in-country reviewer for pt-BR | Review step missing | Vendor provides an independent reviewer | Localisation coordinator |

### 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

<!-- Guidance: Define terms the vendor and product team must read the same way, and list standards with editions. -->

| Term | Meaning in this brief |
|---|---|
| Localisation (l10n) | Adapting a product or content to a locale, including translation, formats and visuals |
| Internationalisation (i18n) | Designing software so it can be localised without code changes |
| Locale | A language plus regional conventions, identified by a BCP 47 tag |
| Translation memory (TM) | Database of previously translated segments reused for consistency |
| Termbase | Concept-oriented database of approved terms and their equivalents |
| Post-editing | Editing machine translation output to reach an agreed quality |
| Revision | Bilingual examination of a translation by a person other than the translator |
| LQA | Linguistic quality assurance: scoring a sample against defined error categories |
| Pseudo-localisation | Automatic text transformation used to find i18n defects before translation |

| Reference | Use |
|---|---|
| ISO 17100:2015, *Translation services: Requirements for translation services*, with Amendment 1:2017 (a new edition is in preparation) | Names of process steps and roles (section 8) |
| ISO 18587:2017, *Translation services: Post-editing of machine translation output: Requirements* (a revision, ISO/DIS 18587, was at public enquiry in autumn 2026 and may change the scope and terms; check iso.org) | Full and light post-editing terms (section 7) |
| ISO 30042:2019, *Management of terminology resources: TermBase eXchange (TBX)* | Termbase exchange format (sections 5, 11) |
| OASIS XLIFF Version 2.1, OASIS Standard, 13 February 2018; XLIFF Version 2.2, Committee Specification 01, 13 March 2025 (docs.oasis-open.org/xliff) | File format (section 11) |
| BCP 47 (RFC 5646, *Tags for Identifying Languages*, with RFC 4647) | Locale tags (section 2) |
| Unicode CLDR (cldr.unicode.org) | Locale formatting data (sections 6, 9) |
| Termbase (`docs/termbase`) | Terminology source |
| Glossary (`docs/glossary`) | Reader-facing term list |
| Docs Contribution Guide (`docs/docs-contribution-guide`) | Source preparation for docs |
| Technical Writing Style Guide (`docs/style-guide-technical`) | Source style |

## 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.