Standard glossary matching only catches the exact word or phrase a term was defined with. Augmented Term Lookup goes further: when a glossary term is found in a segment, it uses AI to suggest how the term's translation should be re-inflected — a plural, a different gender, a different verb tense — to fit the form used in that segment.
​

💡 Who is this for? This guide is for Account Admins and any user with Editor access who need to enable Augmented Term Lookup on a glossary and use the AI-suggested term variants it surfaces while translating.

Augmented Term Lookup is turned on per glossary. Once enabled, whenever the Editor finds one of that glossary's terms in a segment, wxrks asks an AI model to suggest how the glossary's target-language translation should be re-inflected (for gender, number, or tense) to fit that segment. This never invents a new translation for the term — only a different grammatical form of the translation already stored in the glossary.

This runs on wxrks's own built-in AI by default — the same underlying AI infrastructure behind wxrks Augmented Actions, though it's a separate, purpose-built feature rather than one of the Augmented Actions you trigger manually from a segment. If your account uses any provider you connect in Model Management (see Configure Custom AI Providers with Model Management), Augmented Term Lookup uses that connection automatically — no separate setup is needed just for this feature.

Augmented Term Lookup is a per-glossary setting, available wherever a glossary is attached: at the Organizational Unit level, and independently at the Project level.
​

Each project's glossary association gets its own Augmented Term Lookup setting, separate from the org unit's. When a glossary is attached to a project — whether automatically, because it's the org unit's default glossary, or manually from the project's Context tab — that project's copy of the setting starts out matching whatever the org unit's setting was at that moment.
​

After that, the two are independent: changing the setting on the org unit's glossary does not retroactively change it for projects that already have that glossary attached, and changing it on one project doesn't affect the org unit or any other project. If you need a change to reach every project using a glossary, update each project's Context tab individually, or re-attach the glossary after changing the org unit's setting so new attachments pick up the new value.

When a segment's source text contains terms from a glossary that has Augmented Term Lookup enabled, the Editor's right sidebar shows two sections stacked together: GLOSSARY (amber header) for exact-match terms, and GLOSSARY VARIANTS (purple header, with a sparkle icon) below it for everything Augmented Term Lookup found.
​

For the glossary terms found in the segment, the AI may suggest a re-inflected form of the term's translation that fits the segment. These appear with:

When several suggested variants share the same source term, they're grouped under one header row showing that shared term.

The suggested word replaces the matching text in your target draft, and the applied text gets a dashed amber underline in the target segment so you can spot it again later.

Augmented Term Lookup runs automatically as soon as you open a segment with a matching glossary term — there's no button to click. While it's working, the GLOSSARY VARIANTS section shows a brief shimmer animation with "Finding variants…" text.

Augmented Term Lookup and Context Sensitive Translate are independent features that don't automatically feed into each other. The GLOSSARY VARIANTS panel above runs on its own as soon as you open a matching segment — it doesn't need Context Sensitive Translate to be turned on or to have run. And Context Sensitive Translate's own output — which may or may not touch a glossary term at all — is never changed by what Augmented Term Lookup suggests.
​

In practice, this means a segment can show two different forms of the same word at once: Context Sensitive Translate might produce a literal, unadapted glossary substitution, while GLOSSARY VARIANTS separately offers a better-inflected form as an Inferred suggestion. Neither happens automatically — if you want the inflected form instead of what Context Sensitive Translate produced, click Apply on the variant yourself, the same manual step you'd use for any other Glossary Variant.

The GLOSSARY VARIANTS section doesn't appear. Confirm Augmented Term Lookup is enabled for at least one glossary attached to the project (check both the project's own Context tab and, if it inherited the glossary from there, the org unit's). The current segment also needs at least one term in the regular GLOSSARY section — variants are only suggested for terms found there, and only when the AI finds a form that fits the segment.

Glossary terms show up, but no variants. Inferred variants depend on a live AI call, which only returns a suggestion when the model finds a plausible re-inflection for the target language — it's normal for some segments to have glossary matches but no Inferred variant. If the shimmer "Finding variants…" state seems to hang, it resolves to an empty result automatically after about 15 seconds rather than block the segment.