# Termbase: [Product, domain or organisation name]

> Terminology register for a product, documentation set or organisation.
> Each entry describes one concept, gives its definition, its terms with
> usage status (preferred, admitted, deprecated), context, source, related
> concepts and equivalents in each target locale. Definition and term
> rules follow the principles of ISO 704:2022 (*Terminology work:
> Principles and methods*, 4th edition), written here in original wording,
> and the register columns map to data categories used by TermBase
> eXchange (TBX, ISO 30042:2019) so the table can be exported to
> translation and authoring tools. Replace every `[bracketed]` value and
> every row marked *Example*. Worked examples use Corvid Commerce, a
> fictional SaaS retailer, and the terms of its checkout and data platform.

<!--
Guidance: How to use this template
- A termbase is for the people who write, translate and review content. A
  glossary is for readers. Keep both: publish a Glossary (`docs/glossary`)
  generated from the entries marked "publish".
- One entry is one concept, not one word. Two meanings of "order" are two
  entries; three spellings of "e-mail" are three terms in one entry.
- Fill the field definitions (section 4) and status rules (section 6)
  before adding entries; changing the model later means touching every row.
- Keep the register as a table in this file for small sets (under about
  300 concepts). Move to a terminology tool that imports TBX when the set
  grows, and keep this file as the rulebook.
-->

## Document control

<!-- Guidance: Identify the terminologist who approves entries and the subject fields covered. -->

| Field | Value |
|---|---|
| Document ID | [TERMBASE-001] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@terminologist] |
| Approvers / reviewers | [@docs-lead], [@product-owner], [@l10n-coordinator], [locale reviewers] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Public] |
| Subject fields | [*Example:* checkout and payments; orders; data platform] |
| Source language | [*Example:* en-US] |
| Target locales | [*Example:* de-DE, fr-FR, ja-JP, pt-BR, ar-SA] |
| Export formats | [*Example:* TBX-Basic, CSV, Vale vocabulary lists] |
| Next review | YYYY-MM-DD (and before each localisation batch) |
| Related | Glossary (`docs/glossary`), Localization Brief (`docs/localization-brief`), Technical Writing Style Guide (`docs/style-guide-technical`) |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Terminologist | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Documentation lead | [@name] | [Decision] | YYYY-MM-DD |
| Product owner | [@name] | [Decision] | YYYY-MM-DD |
| Localisation coordinator | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record changes to the model and rules here; entry-level changes go to the change log in section 11. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft with core checkout concepts |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* ja-JP and de-DE equivalents added after vendor review |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved; first TBX export sent to vendor |

## Contents

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

1. [Purpose, scope and users](#1-purpose-scope-and-users)
2. [Roles and entry lifecycle](#2-roles-and-entry-lifecycle)
3. [Entry model](#3-entry-model)
4. [Field definitions and TBX mapping](#4-field-definitions-and-tbx-mapping)
5. [Definition rules](#5-definition-rules)
6. [Term selection and usage status](#6-term-selection-and-usage-status)
7. [Terminology register](#7-terminology-register)
8. [Equivalents per locale](#8-equivalents-per-locale)
9. [Do-not-translate terms](#9-do-not-translate-terms)
10. [Concept relations](#10-concept-relations)
11. [Requests and change log](#11-requests-and-change-log)
12. [Quality checks](#12-quality-checks)
13. [Export and exchange](#13-export-and-exchange)
14. [Glossary and references](#14-glossary-and-references)

## 1. Purpose, scope and users

<!-- Guidance: Say which subject fields are in, who uses the termbase and for what decisions. Pitfall: collecting every word in the product instead of the terms that cause confusion or translation cost. -->

This termbase records the concepts that [Product name] content depends on
and the words used to name them, so that the UI, documentation, support
articles, training and translations use the same term for the same thing.

Include a concept when at least one of these is true:

1. It is specific to the product or domain and readers may not know it.
2. Teams use more than one word for it, or one word for more than one
   concept.
3. Translators have asked about it, or translations of it have differed.
4. A wrong term would cause a legal, financial or safety misunderstanding.
5. It is a product, feature or event name that must stay fixed.

Exclude general vocabulary that any dictionary covers with the meaning you
intend, and internal code names that never reach users.

| User | Uses the termbase to |
|---|---|
| Technical writers and UX writers | Choose the preferred term and check definitions |
| Engineers | Name UI labels, events and API fields consistently |
| Translators and reviewers | Find approved equivalents and do-not-translate terms |
| Support and training staff | Explain concepts in the same words as the product |
| Docs platform | Generate the reader glossary and linter vocabularies |

## 2. Roles and entry lifecycle

<!-- Guidance: Name who may propose, who decides and how quickly. Show the states an entry passes through. Pitfall: everyone can edit, so preferred terms change without notice. -->

| Role | Responsibility |
|---|---|
| Proposer | Anyone; submits a request with term, context and source (section 11) |
| Terminologist | Researches the concept, drafts the definition, decides status, keeps the model |
| Subject matter expert (SME) | Confirms the concept and definition are technically right |
| Locale reviewer | Approves equivalents for one locale |
| Product owner | Decides when a term choice affects UI labels or product names |

```mermaid
stateDiagram-v2
    [*] --> Proposed
    Proposed --> UnderReview: terminologist accepts request
    Proposed --> Rejected: out of scope or duplicate
    UnderReview --> Approved: SME confirms definition
    Approved --> Approved: equivalents added per locale
    Approved --> Retired: concept no longer used
    Retired --> [*]
    Rejected --> [*]
```

Entry status (above) is about the whole concept entry. Usage status
(preferred, admitted, deprecated) is about each term inside an entry and
is set in section 6. An approved entry can hold deprecated terms; that is
how the termbase tells writers which old words to stop using.

## 3. Entry model

<!-- Guidance: Explain the three levels so contributors put each field at the right level. Pitfall: definitions written per language, so the concept splits silently. -->

The termbase is concept-oriented: the entry is the concept, and terms hang
below it. Each entry has three levels, which match the TBX structure of a
concept entry, language sections and term sections.

```mermaid
flowchart TD
    C["Concept entry (ID, subject field, definition, related concepts)"]
    C --> L1["Language section: en-US"]
    C --> L2["Language section: de-DE"]
    C --> L3["Language section: ja-JP"]
    L1 --> T1["Term: partial refund (preferred)"]
    L1 --> T2["Term: part refund (deprecated)"]
    L2 --> T3["Term: Teilerstattung (preferred)"]
    L3 --> T4["Term: 一部返金 (preferred)"]
```

| Level | Holds | Rule |
|---|---|---|
| Concept | ID, subject field, definition (in the source language), related concepts, image, entry status | One concept per entry; the definition belongs here |
| Language | Locale tag, optional definition in that language, notes on regional use | One section per locale |
| Term | Term text, part of speech, usage status, term type, context, source, grammatical information | One row per spelling or variant |

A definition written in a target language is a translation of the
concept definition; it must not narrow or widen the concept. If a locale
genuinely needs a different concept (for example a legal term that only
exists in one jurisdiction), create a separate entry and link the two.

## 4. Field definitions and TBX mapping

<!-- Guidance: Define every column once and map it to a TBX data category name so exports are lossless. Check the data category list for your TBX dialect at tbxinfo.net before exporting. Pitfall: free-text status values that tools cannot import. -->

| Column | Level | Meaning | TBX data category | Required |
|---|---|---|---|---|
| ID | Concept | Stable identifier `TERM-NNNN`, never reused | Concept entry `id` attribute | Yes |
| Subject field | Concept | Domain the concept belongs to, from a controlled list | `subjectField` | Yes |
| Definition | Concept (source language) | Statement that identifies the concept (section 5) | `definition` | Yes for approved entries |
| Related concepts | Concept | IDs of broader, narrower or associated concepts | `crossReference` | No |
| Image | Concept | Link to a diagram or screenshot that shows the concept | `xGraphic` (check your dialect) | No |
| Entry status | Concept | Proposed, under review, approved, rejected, retired | Local field (map to a `note` or a custom category) | Yes |
| Locale | Language | BCP 47 tag | Language section `xml:lang` | Yes |
| Term | Term | The designation exactly as written | `term` | Yes |
| Part of speech | Term | Noun, verb, adjective, adverb, proper noun, other | `partOfSpeech` | Yes |
| Usage status | Term | Preferred, admitted, deprecated (section 6) | `usageStatus` | Yes |
| Term type | Term | Full form, abbreviation, acronym, short form, variant, phrase | `termType` | No |
| Grammatical gender | Term | Masculine, feminine, neuter, other (for gendered languages) | `grammaticalGender` | For de-DE, fr-FR and similar |
| Context | Term | A real sentence that uses the term as intended | `context` | Yes for preferred terms |
| Source | Term or concept | Where the term, definition or context comes from | `source` | Yes |
| Note | Any | Usage advice, history, warnings | `note` | No |
| Product or customer subset | Term | Product line or audience the term is limited to | `customerSubset` | No |
| Publish | Concept | Whether the entry appears in the reader glossary | Local field | No |

Use the controlled values exactly as listed. The mapping above follows
TBX-Basic Version 4 (TerminOrgs, 2025, compliant with ISO 30042:2019),
where usage status is `<termNote type="usageStatus">` with the values
`preferred`, `admitted` and `deprecated`, and term type takes `fullForm`,
`acronym`, `abbreviation`, `shortForm`, `variant` or `phrase`. Older
TBX-Basic versions and some other dialects encode usage status as
`administrativeStatus` with values such as `preferredTerm-admn-sts`,
`admittedTerm-admn-sts` and `deprecatedTerm-admn-sts`. Confirm the
picklists for the dialect you export before the first handoff.

## 5. Definition rules

<!-- Guidance: These rules follow the principles of ISO 704:2022 in original wording. Apply them to every definition and use them as the review checklist. Pitfall: definitions that describe how to use a feature rather than what the concept is. -->

A definition states what a concept is, so that a reader can tell it apart
from related concepts. Write each definition to these rules:

1. **One concept, one definition.** If the definition needs "or" to cover
   two different things, there are two concepts.
2. **Start from the nearest broader concept, then add what makes this one
   different.** "Partial refund: refund of less than the full amount
   captured for an order" names the broader concept (refund) and the
   distinguishing characteristic (less than the full amount).
3. **Make it substitutable.** The definition should be able to replace the
   term in a sentence without changing the meaning. That is why it starts
   with a noun phrase for a noun, not with "A term that" or "When you".
4. **Do not repeat the term or use it in disguise.** "Refund: the act of
   refunding" defines nothing. Also avoid two definitions that point at
   each other.
5. **Say what it is, not only what it is not.** Use a negative only when
   the absence of a characteristic is what defines the concept.
6. **Keep usage, procedures and examples out of the definition.** Put
   them in the context or note fields.
7. **Use terms that are defined in the termbase or generally known.** Link
   other entries in related concepts instead of explaining them inline.
8. **Write one phrase, not a paragraph.** No initial article, no full stop
   in the definition column, and no more detail than needed to separate
   the concept from its neighbours.
9. **Match the scope of the product.** Define the concept as the product
   uses it; if the industry meaning differs, say so in the note.

| Quality *(Example)* | Definition of "checkout session" |
|---|---|
| Weak | "When the customer checks out" (not a noun phrase, not substitutable) |
| Weak | "A session used for checkout" (repeats the term) |
| Good | "Time-limited server-side record that holds a shopper's cart, address and payment choice until an order is placed or the record expires" |

## 6. Term selection and usage status

<!-- Guidance: Give criteria for choosing the preferred term and rules for each status. Pitfall: marking a term deprecated without saying what to use instead. -->

When a concept has more than one candidate term, choose the preferred term
with these criteria, in this order:

1. It is already used correctly in the shipped UI, and changing it would
   confuse users more than it helps.
2. Its meaning can be inferred from its parts by the intended audience.
3. It fits the existing pattern of related terms (for example, all
   payment events use the same noun and verb pattern).
4. It is short enough for UI labels without becoming an unclear
   abbreviation.
5. It translates cleanly; terms built on idioms or wordplay are avoided.
6. It is inclusive and neutral (no terms such as "whitelist" or
   "master/slave").

| Usage status | Meaning | Writers | Translators | Linters |
|---|---|---|---|---|
| Preferred | The term to use for this concept | Use it | Use the preferred equivalent | Accepted |
| Admitted | Acceptable alternative, for example a standard abbreviation or a form needed for space | Use only where the preferred term does not fit; note why | Use only if the locale entry allows it | Accepted |
| Deprecated | Must not be used in new or updated content | Replace it when editing a page | Never use | Rejected (error) |

Each entry has exactly one preferred term per locale it covers. A deprecated term
always sits in an entry that also has a preferred term, so writers know
what to use instead. Some older TBX dialects add a superseded value for terms
replaced over time; this termbase records that history in the note field
rather than as a fourth status, and TBX-Basic Version 4 has no such value.

## 7. Terminology register

<!-- Guidance: One row per term, grouped by concept ID. Copy the definition only on the first row of each concept. Pitfall: duplicates created because nobody searched before adding. -->

| ID | Term | POS | Usage status | Definition | Context | Source | Related | Subject field |
|---|---|---|---|---|---|---|---|---|
| TERM-0001 *(Example)* | order | noun | Preferred | Confirmed request by a shopper to buy one or more items, with agreed prices, delivery details and payment | "The order moves to Paid once the payment is captured." | Orders API reference, 2026-06 | TERM-0002, TERM-0003 | Orders |
| TERM-0001 *(Example)* | purchase | noun | Deprecated | (see first row) | Used in older UI; replace with "order" | UI audit 2026-09 | | Orders |
| TERM-0002 *(Example)* | checkout session | noun | Preferred | Time-limited server-side record that holds a shopper's cart, address and payment choice until an order is placed or the record expires | "Create a checkout session before redirecting the shopper." | Checkout API reference | TERM-0001 | Checkout and payments |
| TERM-0002 *(Example)* | check-out session | noun | Deprecated | (see first row) | Hyphenated form; do not use | Style guide decision 2026-08 | | Checkout and payments |
| TERM-0003 *(Example)* | partial refund | noun | Preferred | Refund of less than the full amount captured for an order | "You can issue several partial refunds until the captured amount is used up." | Product spec PRD-REF-12 | TERM-0004 | Checkout and payments |
| TERM-0004 *(Example)* | refund | noun | Preferred | Return of captured money to the shopper's original payment method | "Refunds take up to five business days to appear." | Payments policy | TERM-0003, TERM-0009 | Checkout and payments |
| TERM-0009 *(Example)* | refund | verb | Preferred | To return captured money to the shopper's original payment method | "Refund the order from the Orders page." | Payments policy | | Checkout and payments |
| TERM-0005 *(Example)* | stock keeping unit | noun | Admitted | Identifier a merchant assigns to one sellable variant of a product | Spelled out on first use in docs | Catalog guide | TERM-0001 | Orders |
| TERM-0005 *(Example)* | SKU | noun | Preferred | (see first row) | "Each size and colour has its own SKU." | Catalog guide | | Orders |
| TERM-0006 *(Example)* | data product | noun | Preferred | Dataset published by a domain team with a named owner, a documented contract and service levels, for use by other teams | "The Orders data product is refreshed every hour." | Data platform charter | TERM-0008 | Data platform |
| TERM-0007 *(Example)* | webhook | noun | Preferred | HTTP request that the platform sends to a merchant-configured URL when a subscribed event occurs | "Configure a webhook for the refund.created event." | Webhooks reference | TERM-0004 | Checkout and payments |
| TERM-0007 *(Example)* | callback URL | noun | Deprecated | (see first row) | Older docs; means the endpoint, not the request | Docs audit 2026-07 | | Checkout and payments |
| TERM-0008 *(Example)* | data contract | noun | Preferred | Agreed, versioned description of a dataset's schema, semantics, quality rules and service levels between its producer and consumers | "Breaking changes require a new major version of the data contract." | Data platform charter | TERM-0006 | Data platform |

Note on TERM-0004 and TERM-0009: the action (to refund) and its result
(a refund, money returned) are different concepts, so they are two entries
linked as associative. Use one entry with several term rows only for
designations of the same concept, such as a full form and its acronym.

## 8. Equivalents per locale

<!-- Guidance: One row per concept and locale, keyed by the concept ID from section 7. A locale reviewer approves each row; translators use only approved rows. Pitfall: translating the source term instead of the concept, so the equivalent fits a different meaning. -->

Equivalents name the same concept in a target locale. The definition stays
the one agreed in the source language; add a definition in the target
language only when reviewers need it, and keep its meaning identical.
Each row carries its own usage status, because a preferred source term can
have an admitted or deprecated form in a locale.

| Concept ID | Locale | Equivalent | POS | Usage status | Note | Reviewer | Approved |
|---|---|---|---|---|---|---|---|
| TERM-0001 *(Example)* | de-DE | Bestellung | noun | Preferred | Feminine; plural Bestellungen | [@de-reviewer] | YYYY-MM-DD |
| TERM-0001 *(Example)* | ja-JP | 注文 | noun | Preferred | UI labels may use 注文 alone; avoid オーダー | [@ja-reviewer] | YYYY-MM-DD |
| TERM-0002 *(Example)* | fr-FR | session de paiement | noun | Preferred | "Checkout" is not used as a loanword in French UI | [@fr-reviewer] | YYYY-MM-DD |
| TERM-0004 *(Example)* | de-DE | Rückerstattung | noun | Preferred | Result of the action; for the verb see TERM-0009 | [@de-reviewer] | YYYY-MM-DD |
| TERM-0009 *(Example)* | de-DE | erstatten | verb | Preferred | Imperative in UI: "Betrag erstatten" | [@de-reviewer] | YYYY-MM-DD |
| TERM-0005 *(Example)* | pt-BR | SKU | noun | Preferred | Kept as acronym; spell out "unidade de manutenção de estoque" on first use only in docs | [@pt-reviewer] | YYYY-MM-DD |
| TERM-0007 *(Example)* | ar-SA | خطاف الويب | noun | Admitted | "Webhook" in Latin script is preferred in developer docs; check the locale style guide | [@ar-reviewer] | YYYY-MM-DD |

Rules for equivalents:

1. Translate the concept, using the definition and context in section 7,
   not the English word.
2. Record one preferred equivalent per concept and locale; list other forms
   as admitted or deprecated rows with a note.
3. Check every equivalent against the do-not-translate list in section 9 so
   the two never disagree.
4. Note grammatical information translators need, such as gender, plural or
   counters, in the Note column.
5. Re-review equivalents when the source definition changes; mark them
   "To review" until the locale reviewer approves again.

## 9. Do-not-translate terms

<!-- Guidance: List names and strings that stay identical in every locale. Pitfall: a do-not-translate list that contradicts the equivalents table. -->

These terms keep the same form in every locale. They are exported with
part of speech `properNoun` (for names) or with a note, and the Localization Brief
(`docs/localization-brief`) refers to this section.

| ID | Term | Reason | Exceptions |
|---|---|---|---|
| TERM-0100 *(Example)* | Corvid Commerce | Company name | ja-JP uses the approved katakana form in marketing copy only |
| TERM-0101 *(Example)* | Orders API | Product name | None |
| TERM-0102 *(Example)* | `refund.created` | Event name in code | None |
| TERM-0103 *(Example)* | Checkout | Product name when capitalised | Lowercase "checkout" (the process) is translated |

## 10. Concept relations

<!-- Guidance: Show how concepts relate so writers choose the right level of generality. Pitfall: listing related terms without saying how they relate. -->

Concept relations help writers choose between a general and a specific
term and help translators see whether two terms are siblings or
synonyms. Record three relation types:

| Relation | Meaning | Example |
|---|---|---|
| Generic (broader, narrower) | One concept is a kind of the other | Partial refund is a kind of refund |
| Partitive (whole, part) | One concept is part of the other | A checkout session is part of the order process |
| Associative | Concepts are linked by use, cause or sequence | A refund triggers a webhook |

```mermaid
flowchart LR
    R[TERM-0004 refund] -->|narrower| PR[TERM-0003 partial refund]
    O[TERM-0001 order] -->|preceded by| CS[TERM-0002 checkout session]
    R -->|applies to| O
    R -. triggers .-> W[TERM-0007 webhook]
    DP[TERM-0006 data product] -->|described by| DC[TERM-0008 data contract]
```

## 11. Requests and change log

<!-- Guidance: Make proposing a term easy and record every decision with a reason. Pitfall: decisions made in chat and lost. -->

Anyone can request a new term, a new equivalent or a status change. A
request includes the proposed term, the concept it names, a real context
sentence, a source and the locales affected.

| Request ID | Date | Requested by | Request | Decision | Reason | Entry |
|---|---|---|---|---|---|---|
| TRQ-001 *(Example)* | YYYY-MM-DD | Vendor (ja-JP) | Translate "webhook" or keep it? | Keep in Latin script | Developers search with the English term; consistent with API field names | TERM-0007 |
| TRQ-002 *(Example)* | YYYY-MM-DD | Docs team | Deprecate "callback URL" | Approved | Ambiguous between the endpoint and the request | TERM-0007 |
| TRQ-003 *(Example)* | YYYY-MM-DD | Support | Add "chargeback" | Under review | SME confirmation pending | Not yet assigned |

Decisions that change a preferred or deprecated term are announced to
writers, engineers and the localisation vendor, because they change the
linter vocabularies and translation memories.

## 12. Quality checks

<!-- Guidance: Run these checks before every export and at each review. Pitfall: exporting duplicates and orphans that tools then import as truth. -->

| Check | Rule | How |
|---|---|---|
| Duplicate concepts | No two approved entries with equivalent definitions | Sort by definition keywords; SME review |
| Duplicate terms | A preferred term appears in only one entry per subject field | Script over the register |
| Missing preferred term | Each approved entry has one preferred term per locale it covers | Script |
| Orphan deprecated terms | Each deprecated term sits beside a preferred term | Script |
| Definition rules | Each definition passes section 5 | Terminologist review |
| Context present | Each preferred term has a real context sentence | Script |
| Source present | Each definition and term has a source | Script |
| Broken relations | Every related concept ID exists | Script |
| Consistency with content | Deprecated terms do not appear in published content | Vale reject list (section 13) |

## 13. Export and exchange

<!-- Guidance: Name each consumer of the termbase and the format it receives. Validate TBX files against the dialect schema published at tbxinfo.net. Pitfall: hand-maintained copies in each tool that drift from this register. -->

Generate every downstream copy from this register; never edit an export by
hand.

| Consumer | Format | Content | Frequency |
|---|---|---|---|
| Translation vendor and CAT tools | TBX (TBX-Basic Version 4) | Approved entries, all locales, without internal notes | Before each localisation batch |
| Spreadsheets and reviewers | CSV (UTF-8) | One row per term with all columns | On request |
| Prose linter (Vale) | `accept.txt` and `reject.txt` | Preferred and admitted terms; deprecated terms | On every change |
| Reader glossary | Markdown page | Entries marked "publish", source language and each published locale | On every release |
| UI string review | CSV or JSON | Preferred UI terms and do-not-translate terms | Before source freeze |

Example TBX-Basic Version 4 fragment for TERM-0003 (a valid file wraps it
in `<tbx type="TBX-Basic" style="dca" xml:lang="en">` with a `<tbxHeader>`;
validate against the schema of the dialect you export):

```xml
<conceptEntry id="TERM-0003">
  <descrip type="subjectField">Checkout and payments</descrip>
  <langSec xml:lang="en-US">
    <descrip type="definition">Refund of less than the full amount captured for an order</descrip>
    <termSec>
      <term>partial refund</term>
      <termNote type="partOfSpeech">noun</termNote>
      <termNote type="usageStatus">preferred</termNote>
      <descrip type="context">You can issue several partial refunds until the captured amount is used up.</descrip>
    </termSec>
  </langSec>
  <langSec xml:lang="de-DE">
    <termSec>
      <term>Teilerstattung</term>
      <termNote type="partOfSpeech">noun</termNote>
      <termNote type="grammaticalGender">feminine</termNote>
      <termNote type="usageStatus">preferred</termNote>
    </termSec>
  </langSec>
</conceptEntry>
```

CSV export columns, in order: `id, subject_field, definition, locale,
term, part_of_speech, usage_status, term_type, grammatical_gender,
context, source, related, note, publish`. Quote every field, keep line
breaks out of cells, and save as UTF-8 so CJK and Arabic terms survive.

For the Vale vocabulary, the export writes preferred and admitted
source-language terms to `accept.txt` and deprecated terms to
`reject.txt`, as described in the Docs Contribution Guide
(`docs/docs-contribution-guide`). Terms that need case-insensitive matching
are exported with the `(?i)` prefix.

## 14. Glossary and references

<!-- Guidance: Define the terminology terms used in this document, and list the standards with editions. -->

| Term | Meaning in this document |
|---|---|
| Concept | A unit of thought that a term names; the subject of one entry |
| Term | A word or phrase that names a concept in a given language |
| Definition | Statement that identifies a concept and separates it from related concepts |
| Concept-oriented | Organised by concept, with all terms and languages for that concept in one entry |
| Usage status | Whether a term is preferred, admitted or deprecated |
| Equivalent | A term in another language that names the same concept |
| TBX | TermBase eXchange, the XML format for exchanging terminology (ISO 30042) |
| Data category | A named type of information in a terminology entry, such as definition or part of speech |

| Reference | Use |
|---|---|
| ISO 704:2022, *Terminology work: Principles and methods*, 4th edition, July 2022 | Principles behind the definition and term selection rules (sections 5, 6), in original wording |
| ISO 30042:2019, *Management of terminology resources: TermBase eXchange (TBX)* (a revision is in development) | Entry structure and data category names (sections 3, 4, 13) |
| TBX information site, tbxinfo.net | Dialect schemas (TBX-Core, TBX-Basic, TBX-Min) and data category lists |
| TBX-Basic Version 4 (TerminOrgs, 2025), terminorgs.net | Usage status, term type and part of speech values (sections 4, 9, 13) |
| BCP 47 (RFC 5646, *Tags for Identifying Languages*, with RFC 4647) | Locale tags |
| Glossary (`docs/glossary`) | Reader-facing list generated from this termbase |
| Localization Brief (`docs/localization-brief`) | How the termbase is sent to translators |
| Docs Contribution Guide (`docs/docs-contribution-guide`) | Vale vocabulary use |
| Technical Writing Style Guide (`docs/style-guide-technical`) | Word list and style rules beyond terminology |
| Documentation Plan (`docs/documentation-plan`) | Where terminology work fits in the documentation schedule |

## Standard and licence note

Structure aligned with ISO 704:2022 (principles and methods of terminology
work) and ISO 30042:2019 (TermBase eXchange), which are copyrighted by ISO.
The definition and term selection rules are original wording written for
this template after the general principles of ISO 704; no text, table or
definition from the standard is reproduced. TBX element and data category
names are cited only so that the register can be exported; check the
data category list and schema for your dialect at tbxinfo.net, and the
current editions at iso.org, because a revision of ISO 30042 is in
development. Corvid Commerce and every example entry are fictional.
Original text written for this collection. Template licence: MIT.