Quick answer
A glossary fixes the one problem that gets worse the longer a document is: the same term coming out differently on page 4, page 40, and page 400.
When a glossary is worth building
- The document uses defined terms whose translation is not negotiable
- Several documents in a set must agree with each other
- Product names, module names, or internal jargon must never be translated
- Different teams have translated the same material before, inconsistently
- A regulator, customer, or standard dictates specific wording
Building a glossary by hand
- Open glossary management in the translation settings
- Create a glossary and add source-to-target term pairs
- Import existing terminology from an XLSX file rather than retyping it
- Select the glossary when submitting a translation so it applies to that job
- Include terms that must stay untranslated, not only terms that must be translated a particular way
Letting the system extract one for you
- The translation workflow analyses the document and proposes the terms that matter
- You review the proposed list before it is applied, so nothing is decided silently
- This suits unfamiliar material, where you do not yet know which terms are load-bearing
- The result is reusable for the next document in the same set
Which approach to use
- Manual, when you already know the terminology and it is non-negotiable
- Automatic extraction, when you are working with unfamiliar content
- In practice: extract first to find the candidates, then curate by hand and reuse it
Bottom line
Terminology drift is the failure people notice most in long translations, and a glossary is the cheapest fix for it. Build it once and reuse it across the document set.