How the glossary works in practice
- Create a namespace. A namespace is a named glossary for one client, matter or practice area, such as “Project Falcon SPA” or “Employment – Singapore”. Only the namespace you select is applied to a job, so one client’s terms do not leak into another’s.
- Add terms as pairs. Each entry is an original term, its approved translation and the language pair it applies to. There is no cap on entries, so a full defined-terms schedule can go in.
- Select the glossary when you translate. Under Advanced options, choose Custom Glossary and the namespace. The glossary applies as a constraint on the engine, not a suggestion, so the approved rendering is used every time the term appears.
- Review meaning, not terminology. A defined term cannot drift between clause 1 and schedule 4, or between the agreement and its side letters. Each defined term is one fewer thing to check on every page, so review time goes to substance.
Glossary content, like your documents, is never used to train models (Bluente security statement, read 21 September 2026). Glossary entries can be set for any supported language pair.
Worked example: “force majeure”
A supply agreement goes to local counsel in six jurisdictions. Left to itself, an engine may render “force majeure” one way in the definitions clause and another in the termination clause. One glossary entry per language pair fixes the rendering your firm has chosen:
| Target language | Pinned rendering |
|---|
| Chinese (Simplified) | 不可抗力 |
| Japanese | 不可抗力 |
| Korean | 불가항력 |
| Indonesian | keadaan kahar |
| Vietnamese | sự kiện bất khả kháng |
| German | höhere Gewalt |
Where two renderings are both accepted, as with Indonesian “keadaan kahar” and the Civil Code’s “keadaan memaksa”, your glossary decides once and the engine follows it on every page, in every document in the matter.