Standard glossary matching only catches the exact word or phrase a term was defined with. Augmented Term Lookup goes further: it recognizes when a segment uses a different grammatical form of a glossary term — a plural, a different verb tense, a different inflection — and still surfaces the glossary's translation for it, using AI to bridge the gap when no exact match exists.
​

💡 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, it changes how that glossary's terms are matched against a segment's source text in two ways:
​

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 has connected a custom OpenAI, Azure OpenAI, or Google Gemini provider through 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.
​

These are real glossary entries that matched a different grammatical form of the word in your source segment. Each item shows:

When no exact or inflection match exists, but a word in the segment still looks related to a glossary term, the AI may suggest a re-inflected form of that term's translation. These appear with:

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

For an Inferred variant, the exact suggested word replaces the matching text in your target draft. For an inflection-matched term, the term is inserted at your cursor position. Either way, 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, hover the variant and click Apply this term 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 to contain a word that's an inflected form of a glossary term — if the segment only contains exact matches, those show up in the regular GLOSSARY section instead, with nothing in GLOSSARY VARIANTS.

Inferred variants never show up, even though Inflection Matches do. 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 an Inflection Match but no Inferred variant, or neither. If the shimmer "Finding variants…" state seems to hang, it will resolve to an empty result automatically after a few seconds rather than block the segment.