A useful terminology sheet records a decision in context. It tells the reviewer where a term appears, how the source defines or uses it, which rendering is proposed and who can approve the choice. A two-column list of words may be too thin to resolve the questions that arise in a contract pack.
Start with terms whose treatment affects repeated passages: defined parties, recurring obligations, document titles and technical expressions. Do not attempt to settle every ordinary word before translation begins. Prioritise the decisions that would otherwise generate repeated or conflicting edits.
Give each entry enough context
| Field | What it should contain |
|---|---|
| Source term | Exact wording and capitalisation where relevant |
| Location | Clause, schedule, page or source reference |
| Source context | Definition or a short description of the use |
| Proposed rendering | Candidate term in the target language |
| Decision status | Proposed, queried, approved or superseded |
| Decision owner | Person authorised to resolve the question |
| Decision record | Answer, date and any limits on its application |
Keep the sheet connected to the controlling source version. A term approved for an earlier definition may need review when the definition changes.
Use a fictional ambiguity to test the sheet
Imagine an invented agreement that calls one party “Supplier” in the main text and “Vendor” in a schedule. A bare glossary might encourage the team to choose one target term for both. A contextual entry makes the unresolved issue visible: are these labels intended to refer to the same role?
Record both source locations and ask the document owner or legal reviewer for the relevant clarification. The translator can identify the language inconsistency and propose alternatives. The sheet should not turn a linguistic preference into an unsupported decision about the parties' legal roles.
When the answer arrives, record it and identify which occurrences it covers. If the distinction is deliberate, preserve it. If a correction to the source is required, route that through the source owner rather than hiding it in the translation.
Keep approvals narrow enough to be useful
A term can have different functions in different contexts. Record whether an approved rendering applies to a defined term, a technical phrase or an ordinary use. Avoid an instruction that triggers an indiscriminate global replacement.
If several reviewers disagree, consolidate the comments through the designated decision owner. Keep the final answer visible alongside the original question. This reduces the risk of a later reviewer reopening a settled issue without seeing why the choice was made.
Connect terminology to revision work
When an approved term changes, identify the affected files and occurrences. Review the surrounding sentences, headings and tables rather than replacing a string without reading it. Related abbreviations and references may need attention as well.
Mark the previous entry as superseded and retain the decision history under the agreed project arrangements. A reader should be able to distinguish the current instruction from an old suggestion.
Check the rendered output
The terminology sheet supports review, but it does not replace a final reading. Check that approved terms appear in the correct contexts and that formatting has preserved distinctions such as capitalised defined terms where relevant to the source and agreed style.
For a translation brief, provide any existing terminology resources with their status clearly labelled. Identify the in-house reviewer and the route for unresolved questions. A small, contextual, maintained sheet is more useful than a large inherited glossary whose authority nobody can explain.
Request a quotation with your document type, language pair and written requirements.