UI Term Replacement lets a glossary automatically translate specific terms in your source content — typically interface labels, like a button or menu name — wherever they're wrapped in a matching tag, before a linguist ever opens the segment. This article covers what it does and how to turn it on for a glossary.
💡 Who is this for? This guide is for Account Admins and Project Managers who need to configure automatic translation of tagged UI terms using a glossary within the wxrks platform.
What is UI Term Replacement?
Product documentation and help content often reference your own application's interface by name — a button, a tab, a field — and source files commonly wrap those references in a tag, most often <uicontrol> or <userinput> in DITA-style content. UI Term Replacement checks every term wrapped in a tag you configure against a glossary, and translates it using the exact term the glossary already has for it — instead of leaving it to machine translation, AI, or a linguist to translate freely, which can produce a translation that doesn't actually match the label shown on screen.
This isn't something you trigger per segment. Once it's configured, wxrks checks tagged terms automatically as part of pre-translation and of Context Sensitive Translation — you only need to turn it on and tell it which tags to watch for.
Turning UI Term Replacement on for a glossary changes what that glossary is used for: it's then used only for UI term matching, and stops contributing its usual contextual suggestions elsewhere in the project. If you want a glossary to keep doing both jobs, use two separate glossaries — one for general terminology, and one dedicated to UI Term Replacement.
How to Configure UI Term Replacement
UI Term Replacement is configured per glossary, from that glossary's row in the Glossary table on the Context tab — available at both the Organizational Unit and Project levels. The glossary has to already be added there before you can configure this; see All about Glossaries if you haven't added one yet.
The same Glossary table has other, unrelated toggles side by side with Advanced Settings — Enable Learning Terms (see Learning Terms) and Augmented Term Lookup. This article only covers the gear-icon Advanced Settings button.
At the Organizational Unit level
Open the Organizational Unit and go to its Context tab.
In the Glossary table, find the glossary you want to configure.
Click the gear icon in that row's Advanced Settings column.
Turn on Enable UI Term Replacement.
In Tag names (comma-separated), enter every tag that should trigger replacement — for example
uicontrol, userinput. At least one tag name is required once the toggle is on.Click Save.
Only users with glossary-management permissions for the Organizational Unit can open and change these settings.
At the Project level
The same steps apply from the Project's own Context tab — see Project Overview for where that tab sits. Find the glossary in the Project's Glossary table, click its Advanced Settings gear icon, and configure the same Enable UI Term Replacement toggle and Tag names field there.
How Organizational Unit and Project Settings Relate
When you add a glossary to a Project, the Project's copy of these settings starts as whatever the Organizational Unit currently has configured for UI Term Replacement — but only as a one-time starting point. After that, the two are independent: changing the setting at the Organizational Unit level does not update Projects that already have the glossary bound, and changing it at the Project level doesn't affect the Organizational Unit or any other Project. If a Project needs different tags, or needs UI Term Replacement off after inheriting it on, change it directly from that Project's own Context tab.
What Happens in the Editor
Once configured, wxrks checks every tagged term during pre-translation and during Context Sensitive Translation. If a segment's translation instead comes from Translation Memory with a 100%/101% match — or a lower match that still meets your project's Minimum TM match threshold for prioritizing TM over Context Sensitive translation — UI Term Replacement is skipped for that segment entirely, and the existing translation is left as-is.
Otherwise, each tagged term is checked against the glossary (or glossaries) you've enabled it for, and one of four things happens:
Situation | What happens to the term | What you'll see in the Editor |
No match in the glossary | Stays in the source language; the rest of the segment translates normally | A Smell flagging that no glossary translation was found for the term |
Exactly one match | Automatically replaced with the glossary's target term | No warning — the substitution happens silently |
More than one different match | Stays in the source language, rather than guessing which one is right | A Smell listing the different candidate translations it found |
One match exists, but the current translation uses something else (common on segments carried over from Translation Memory) | Existing translation is left untouched | A Smell suggesting the term the glossary expects instead |
These all surface as Smells — the same AI-driven quality panel used for other translation issues; see QA Confidence Score and Smells for how to turn Smells on and work with the panel in general. Unlike most Smells, a UI Term Replacement warning has no Fix Smell button, because the fix is a change to the glossary, not a rewording of the translation — Ignore Smell is still available if you want to dismiss it.
[SCREENSHOT PLACEHOLDER]
Related Articles
Related article: All about Glossaries
Related article: Learning Terms
Related article: QA Confidence Score and Smells
Related article: Project's Translation Settings
Related article: Project Overview