Journal / Work & operations

A client terminology glossary template with context and approval history

Build a bilingual client glossary that preserves context, preferred terms, approval provenance, exceptions, and superseded decisions.

A client terminology glossary should explain more than which word to use. The next translator or interpreter needs to know what the term means in this client’s context, where the preferred wording came from, and whether the choice is proposed, reviewed, or approved. Without that context, a tidy bilingual list can preserve the wrong decision very efficiently.

This client terminology glossary template is a decision register for professional handoffs and repeated assignments. It covers source wording, preferred wording, context, provenance, exceptions, approval history, and sharing. The examples use invented terminology and fictional client decisions rather than offering authoritative translations.

Start with a client and project boundary

Keep client terminology scoped to the client or project where it applies. Two clients can prefer different wording for similar concepts. A single global list with one preferred term can erase that difference and make a perfectly valid choice look universal.

Record the language direction and relevant locale information. Source language, target language, and audience should be clear to the person retrieving the term. A label such as “English” may need more context when a client’s materials distinguish regional usage.

Separate a client’s standing terminology from a project-specific exception. A campaign may use a temporary label that should not replace the client’s established product name everywhere else. The relationship between the general preference and the local exception belongs in the record.

Define the intended use of the glossary: preparation, drafting, review, or handoff. Different users may need different fields, but they should be able to identify the same underlying decision and its current status.

Copy this terminology entry template

Use a stable identifier for each concept or decision entry. The source phrase and translation may change over time, so an identifier gives you something consistent to reference in questions and history.

  • Scope: client, project, language direction, locale, and intended audience.
  • Source: source term or phrase, source context, and a document reference.
  • Preferred wording: the proposed or approved target wording, including relevant spelling and capitalization.
  • Meaning: the concept intended in this context and any useful limitation.
  • Provenance: where the wording or instruction came from, with date and reference.
  • Status: candidate, reviewed, approved, or superseded, using your defined workflow.
  • Approval record: recorded approver, date, evidence reference, and what was actually confirmed.
  • Exceptions: contexts where another wording applies, with the reason and scope.
  • Sharing: whether the entry is cleared for the intended recipient and what notes must remain private.

Do not require invented certainty to fill every field. “Preferred wording proposed; client confirmation pending” is a useful entry. A blank status is less useful because another person may assume the term has already passed review.

Capture context that distinguishes the concept

Include enough source context to identify meaning. A short phrase may have several senses, and a product label may behave differently from ordinary prose. A relevant sentence, heading, or document location can be more useful than a long copied passage.

Record the kind of use: interface label, marketing headline, internal process name, spoken presentation, or another defined context. This helps the next user understand why the preferred wording may be concise, formal, or constrained in length.

Keep concept notes separate from translation instructions. “This label names the client’s onboarding stage” explains meaning. “Use sentence case in the interface” is an instruction. They belong together but answer different questions.

Capture only the source material needed for the terminology decision and permitted by the assignment. A glossary entry should not become an unnecessary copy of a confidential document when a reference and short contextual note would suffice.

A fictional worked example: a named service stage

Imagine a fictional client, Harbor Studio, uses the invented label “Launch Desk” for a service stage. A translator creates entry HS-017 within the relevant project. The source reference points to the client brief, and the meaning note explains that the label refers to a named stage rather than a physical desk.

The translator records a proposed target phrase as a candidate. A reviewer checks the context and adds a question about whether the label should be translated or retained. That question remains open; review alone does not turn the candidate into an approved term.

The client’s designated contact later confirms that the brand label should remain unchanged in the specified customer materials. The entry records that instruction, the message reference, the date, and the person whose approval was recorded. It does not imply that anyone independently verified the contact’s authority.

A separate internal training document uses an explanatory phrase on first mention. The glossary stores that as a contextual exception with its own scope. The exception does not replace the customer-facing preference or silently broaden it to every future project.

Distinguish provenance from approval

Provenance explains where information came from. Approval records a particular review outcome. An older brochure may establish that wording was used previously without showing that it is the current preferred choice. A supplier’s document may offer terminology without representing the client’s decision.

Record the source type clearly: client instruction, prior approved material, reviewer recommendation, reference document, or your own proposal. This lets the reader judge how to use the entry and which questions still need clarification.

For approval, identify the wording and context actually confirmed. A client approving one sentence does not necessarily approve a glossary term for every context. Likewise, a general acknowledgment of receiving the glossary is different from approving its contents.

Keep the supporting reference available to the people authorized to see it. If the reference cannot be shared in a handoff, include an appropriate summary and disclose that limitation. Do not invent a public source to make a private decision look independently documented.

Preserve old decisions while corrections are pending

When a term needs correction, create a proposed successor or an explicit pending change. Keep the currently approved wording retrievable until the replacement reaches the required state. Otherwise, someone may unknowingly use an unapproved correction in live work.

Record why the change is proposed. The reason may be a new client instruction, changed product naming, clarified meaning, or an earlier transcription error. A short change note makes the history useful to someone joining later.

When the successor is approved, mark the earlier decision superseded and link the two. Preserve the date and scope of the transition. Some existing materials may still refer to the earlier wording, and the record should explain the difference rather than erasing it.

Do not treat every spelling fix as a new conceptual decision, but avoid silent changes that alter meaning or approval context. Define a proportionate revision practice and use it consistently across the client workspace.

Write exceptions as rules with a boundary

An exception should say where it applies and why. “Use alternative phrase in the internal training introduction” is more useful than “sometimes use alternative.” Identify the document, audience, or grammatical context that triggers the exception.

Keep the preferred term visible alongside the exception. A reader should understand the default and the specific case that differs. If the exception becomes the new general preference, review it as a change rather than letting repeated use silently redefine the entry.

For prohibited or deprecated wording, explain the scope. A client may reject a term in customer-facing material while it remains necessary in a quotation, historical title, or source reference. The glossary should support accurate handling rather than blind replacement.

If two exceptions conflict, raise a decision question with examples. Do not resolve the conflict by creating another vague note. The purpose of the register is to make the next choice easier, not accumulate unresolved commentary.

Make lookup work in both language directions

Search by source wording and preferred wording during review. A handoff recipient may remember the target phrase while the original translator remembers the source. Both routes should lead to the same concept and status rather than separate duplicate entries.

Use aliases carefully. An alternate spelling or abbreviation can help retrieval, but it should not appear to be an approved alternative if it is only a search aid. Label deprecated wording so finding it does not encourage using it.

When you find likely duplicates, compare their client, project, meaning, status, and sources before merging. Similar text can describe different concepts. Different text can refer to the same concept. The decision should follow context rather than a simple string match.

Test a small set of realistic lookup questions before expanding the glossary. Can you find the approved wording, identify the exception, and tell whether a correction is pending? A growing list is not automatically a more usable terminology system.

Prepare a handoff glossary for its actual recipient

Choose the entries needed for the assignment, then check their status and sharing clearance. A working archive can contain candidates, private notes, superseded terms, and confidential evidence. A recipient-facing glossary should not expose all of that merely because it is convenient to export everything.

Include readable labels, language direction, client or project scope, current preferred wording, and necessary context. Add provenance and approval information that the recipient is authorized to receive. Keep private deliberation separate from the agreed terminology.

State the export date and the scope of the set. An exported file is a snapshot, so a later correction in the working register will not automatically update a copy already sent. Define where the recipient should ask about changes or discrepancies.

Open the export outside the original workspace. Check characters, field labels, and status wording. A bilingual record that loses accents or combines fields incorrectly can become difficult to interpret even when the source workspace is accurate.

Keep preparation notes and records recoverable

Pronunciation notes and preparation recordings can help the individual working on an assignment, but they are not automatically part of a client handoff. Decide what needs to remain private and what can be shared for the task.

Check the difference between a handoff export and a full backup. The handoff may deliberately omit private notes. A backup may include a broader written archive but omit local media. Test what your chosen tool preserves before assuming every part of preparation can be recovered elsewhere.

Record the location and date of backups according to your confidentiality obligations. Keep device access and deliberate sharing under control. A terminology register becomes dependable when the records are both retrievable and scoped to the people entitled to use them.

Prepare a focused set for a time-sensitive assignment

Before an assignment, select the relevant client’s current approved terms and the exceptions likely to arise. Check when the set was prepared and whether any high-impact correction is pending. A small, current collection can be easier to use under time pressure than an unfiltered archive of every candidate term.

Make the collection’s scope visible to yourself and anyone receiving it. A snapshot prepared for one meeting should not look like a complete or permanently current client terminology policy. Keep a route back to the working register for questions the snapshot cannot answer.

After the assignment, capture new terminology questions as candidates with their context. Do not promote a word to approved status merely because it was used once during a fast exchange. Review the evidence and obtain the appropriate confirmation through your usual process.

Use Lexivow as a terminology decision register

Lexivow supports client and project terminology, bilingual lookup, contextual exceptions, and candidate-to-superseded history. Its official listing describes share-cleared glossary exports and private written backups, with voice recordings remaining on the original device. It records your approval attestation rather than contacting or independently verifying the client.

View Lexivow on the App Store for current features, privacy details, and access. Use our requirements handoff checklist when terminology forms part of a larger project transfer. Keep the term’s wording, reason, scope, and recorded decision connected.

Sources and example scope

Product features were checked against the official Lexivow listing and product page. Harbor Studio, Launch Desk, the entry identifier, and the approval sequence are fictional. The guide presents an original recordkeeping method, not authoritative terminology, certified translations, or independently verified client approvals.