How to Build a Translation Glossary That Translators and AI Can Actually Use

To create a translation glossary, choose the concepts that need controlled wording, define what each means in your document, approve a target term for each language and context, and assign an owner to maintain those decisions. Then test the entries in real passages before handing them to translators or a translation tool.

The most useful distinction is between the master glossary that records your decisions and the smaller export a tool can consume. A two-column import file may be necessary, but it cannot replace the context, evidence, and approval history that made those two columns trustworthy.

Start with the blank glossary template and the worked glossary example. Both are UTF-8 CSV files. The example uses a fictional product and illustrative English-to-French decisions; it is not a certified terminology list, customer project, or ready-made import preset for BookTranslator.

Keep the glossary smaller than the dictionary

Include a term when an inconsistent or ambiguous choice would change meaning, confuse navigation, weaken an important distinction, or cause avoidable review work. Do not collect every noun simply because software extracted it.

A useful selection pass asks:

• Does this concept recur across sections, files, or contributors?
• Does the source word have more than one relevant meaning?
• Does the organization, author, or subject area require a specific target form?
• Would a different choice make a warning, instruction, interface, or argument harder to follow?
• Is the term new, disputed, or known to have caused a correction in this project?

A rare but consequential term can deserve an entry before a frequent ordinary word. A standard term with no realistic ambiguity may not need one at all.

The COTSOES Terminology Management for Translation starter guide recommends terminology relevant to the organization and explicit validation responsibilities. It also cautions that entry count alone does not establish quality. Those principles matter more here than the age of its software examples.

Candidate extraction is only the inbox. An extracted phrase becomes useful terminology when you know what it means, when it applies, and who approved the target wording.

Build one record around one meaning

Do not give the source string sole ownership of the record. The English word “charge” can describe an electrical property or an amount billed. One row mapping every occurrence to one French word would encode an error, not consistency.

Give each concept a stable identifier, then add the language-specific decision. In a simple spreadsheet, use one row per concept and source/target locale pair. Two rows can share a source spelling without representing the same concept.

The template contains these fields:

A context reference should let a reviewer find the passage again: a file version and section, an authoritative term record, or another durable source. “From the internet” is not enough. For an original author-defined concept, the manuscript's own definition may be the relevant evidence.

Keep the definition separate from the source context. The definition says what the concept is; the context shows how it is used. A sentence such as “Select the workspace” illustrates usage but does not explain what a workspace contains or how it differs from a project.

Repair five common glossary entries

The following repairs belong to the downloadable fictional example. They illustrate editorial decisions, not universal French terminology rules. The sample passages provide the surrounding text.

1. A polysemous word with one forced target

Weak entry: charge → charge

Repair: create separate concepts:

• Electrical property: source charge; target charge électrique; domain “introductory electronics”; context “The capacitor stores electric charge.”
• Amount billed: source charge; target frais; domain “billing”; context “The delivery charge is shown before payment.”

This does not mean either mapping should override every occurrence of “charge.” The entry's domain and context are part of the decision. If the chosen tool cannot distinguish them, use separate project exports, a longer unambiguous phrase, or human review instead of a global substitution.

2. A term without its part of speech

Weak entry: seal → sceller

Repair: distinguish the verb from the component:

• “Seal the envelope”: a verb, with illustrative target sceller in this project.
• “Replace the rubber seal”: a noun referring to a component, with target joint.

The spreadsheet now describes two concepts rather than suggesting that a rubber component is an action. For a real technical document, have the domain reviewer validate the component's meaning and preferred term.

3. Two acceptable translations with no project preference

Weak entry: workspace → espace de travail / zone de travail

Repair: approve espace de travail for the fictional application's named container. Record zone de travail as a rejected variant for this interface concept, not as bad French in general. Add a usage note that normal grammatical inflection is allowed.

A rejected variant needs a reason and a scope. Otherwise a reviewer may “correct” a perfectly valid phrase in a different context.

4. A product name protected only by implication

Weak entry: LeafDeck → LeafDeck

Repair: set do_not_translate=true, identify it as the fictional product name, preserve case, and cite the demo project's naming decision. State that the rule does not apply to unrelated words in an ordinary description.

Matching source and target text alone does not explain whether retention is intentional or simply unfinished work. Use the do-not-translate decision guide for the wider exclusion list.

5. A draft decision presented as approved

Weak entry: sync → synchroniser / mettre à jour, with no owner or state.

Repair: define the action first. For the fictional command that synchronizes the device library, approve synchroniser as a verb and record the alternative as unsuitable for this particular command. Assign an owner and a dated decision source.

Keep a separate proposed noun label in draft until its reviewer resolves it. The worked CSV deliberately includes that draft row. A clean-looking spreadsheet is not evidence that every row is approved.

Use an entry-quality gate, not a decorative score

Before approving an entry, ask six yes-or-no questions:

1. Meaning: can another person distinguish this concept from nearby ones?
2. Evidence: can they find the supporting source or author decision?
3. Language: does the target form work for the specified locale, grammar, and domain?
4. Scope: do they know where the rule applies and where it does not?
5. Accountability: is an owner responsible for resolving changes?
6. Use: has the entry been checked in a representative sentence?

An unresolved answer means the entry stays in draft. This is an editorial acceptance rubric, not a validated numerical measure of translation quality.

Divide the work by expertise. The author or subject specialist confirms the concept; the target-language reviewer confirms usage; the terminology owner records the decision and distributes the approved version. One person can fill several roles on a small project, but the questions still need answers.

If a reviewer disputes an entry, log the competing choices and the passage that exposes the conflict. Follow the translator-query workflow rather than allowing private messages to become undocumented exceptions.

Export for the receiving tool only after approval

Your master glossary and an engine's dictionary have different purposes. The master explains decisions to people. An import file must follow a particular tool's schema and matching behavior.

For a tool that supports glossary imports:

1. Select the required source/target language pair and project domain.
2. Exclude draft and deprecated entries.
3. Resolve duplicate source strings that the receiving tool cannot disambiguate.
4. Map only supported fields into the tool's current import format.
5. Confirm how it treats case, inflections, multiword terms, and protected text.
6. Test a small representative input and inspect the returned translation.

For example, Google Cloud Translation's documented unidirectional CSV format uses source/target pairs without a header, while its equivalent-term-set CSV uses language headers. Its glossary matching is case-sensitive by default, and some stopword entries are ignored. Those are Google Cloud rules, not general CSV rules or BookTranslator capabilities. Check the current Google Cloud glossary documentation before preparing an export for that service.

Do not upload the richly annotated CSV from this article to a random import dialog. It is a working master. Conversely, do not discard its definitions and approval history just because a tool accepts only two columns.

When using an AI system with a supported instruction field, provide a relevant, approved subset plus the context needed to distinguish meanings. An instruction can request terminology; it does not establish that the output followed it. Inspect the result. If the system offers no supported glossary input, keep the master as a reviewer reference rather than inventing a way to import it.

Add languages without erasing local decisions

Reuse the concept ID when adding another target locale, but give that locale its own target, status, owner, and evidence. Approval in French does not approve a German equivalent. A blank target means “not resolved,” not “use the source automatically.”

The same discipline applies within a language. Split locale-specific decisions when they materially differ. Do not create duplicate rows merely to add regional labels that change nothing.

Keep these states simple:

• Draft: a candidate or disputed decision; not part of an approved export.
• Approved: accepted for the stated scope and version.
• Deprecated: retained for history and detection, but not recommended for new work.

For a substantive change, record the old form, new form, reason, effective version, owner, and affected source locations. Rebuild the relevant export and tell translators which passages require reconsideration. Do not silently replace a term mid-project and expect already translated chapters to update themselves.

Review entries when the product, source manuscript, standard, or accepted usage changes. A calendar reminder can help, but a changed definition is the stronger trigger.

Validate the glossary in passages before scaling

A glossary can be internally tidy and still fail in a sentence. Use a small set of passages that deliberately includes:

• an ambiguous source word in two meanings;
• a term as a heading and within prose;
• a singular, plural, or other grammatical variation;
• a protected name next to ordinary language; and
• a term in a table, caption, instruction, or other important document structure.

The downloadable example pairs “delivery charge” with “electric charge” and includes “seal” as both noun and verb. These cases expose why unscoped replacement is the wrong acceptance test.

For each passage, record the source, glossary version, target output, reviewer decision, and correction if required. If you actually test a translation service, add the service/model, date, settings, and raw output. The examples in this article do not claim that such a service test was run.

After the complete document is translated, move to terminology-consistency review. Glossary construction establishes the policy; output review determines whether the delivered text follows it without becoming unnatural.

Hand off a decision record, not just a word list

The final handoff should contain the source version, approved master glossary, receiving-tool export if applicable, unresolved query log, and representative examples. The person doing the translation should know which file is authoritative and whom to ask about conflicts.

For a supported whole book or long document, BookTranslator's file translation workflow can provide a draft for subsequent review. Keep your approved glossary alongside that draft. The worksheet here is an external editorial reference, not a claim that BookTranslator imports user-managed CSV glossaries or enforces every entry.

Start with a few consequential concepts, make the decisions inspectable, and expand from genuine ambiguity or review findings. The goal is fewer unresolved decisions in the next document—not the largest glossary.