Manage protected terms

When auto-translation runs, some terms shouldn’t be translated at all (your brand name, product names, code identifiers) and others should be translated in a specific way that the AI translator won’t always pick up. Protected terms is where you tell the system both.

Open protected terms from Settings → Translation → Protected Terms.

When to use protected terms

• Brand and product names — “Atender”, “Sidekick”, “Email Studio”. Customers in any language should see the same name.
• Code identifiers — function names, API endpoints, configuration keys. Translating apiRequest() to apiAnfrage() is wrong.
• Local-language conventions — when “My account” should be “Mitt konto” in Norwegian (not the AI’s default of “Min konto”).
• Industry-specific terms — terms your AI translator might guess wrong because they’re niche or regulated.

Protected terms are managed per knowledge-base partition or brand. Use them to control terminology for the brand you’re working in without changing other brands’ glossaries.

Choose where protected terms apply

Protected terms have a master switch and per-module toggles.

1. Go to Settings → Translation → Protected Terms.
2. Use the Enable Protected Terms switch to turn protected terms on or off for the whole workspace.
3. Choose which modules should use protected terms:
   Knowledge Base — on by default.
   Conversations — on by default.
   Web Chat — off by default until you enable it.
   Form Builder — off by default until you enable it.
   CSAT — off by default until you enable it.
4. Each toggle saves as soon as you flip it.

Leave a module off if you want that area to translate normally without protected-term rules.

Add a never-translate term

1. Go to Settings → Translation → Protected Terms.
2. Click Add term.
3. Fill in:
   Term — the exact text to protect (e.g. Atender, Sidekick).
   Case-sensitive — toggle if atender and Atender should be treated differently. Most brand-name protections want this on.
   Language-specific translations — leave empty for “never translate”.
4. Click Add Term.

Now every enabled module skips this term during translation — the original text appears in every language unchanged.

Add a per-language override

Use this when a term should be translated, but to a specific phrase rather than whatever the AI picks.

1. Go to Settings → Translation → Protected Terms.
2. Click Add term (or edit an existing term).
3. Set the Term in your default language (“My account”).
4. In Language-specific translations, add an entry per language:
   no → Mitt konto
sv → Mitt konto
da → Min konto
5. Click Add Term (or Save Changes when you are editing an existing term).

Translations in those languages now use your override in every module where protected terms are enabled. Languages without an override translate normally.

Edit or remove a term

Go to Settings → Translation → Protected Terms, then hover the term in the list and click the pencil (edit) icon. Edit the form, then click Save Changes. Or click Delete to remove the protection — the term will start translating normally on the next translation job.

When changes apply

Protected term changes apply to existing translations, not just future jobs. Adding, editing, or deleting a term automatically queues a translation job that re-translates the content containing that term into every other active language. Content that doesn’t contain the term keeps its existing translations.

Protected-term language overrides are also used by KB search when the Knowledge Base module toggle is enabled. After the term is saved, a search for one form, such as “school mode”, can match articles using another protected form, such as “Schulmodus”.

Adding, editing, or deleting a protected term re-syncs translations for that partition only. Other brands’ glossaries and translations are unaffected.

For a bulk re-translation, use Force Retranslate All in the Translation Sync card under Settings → Knowledge → Markets & Languages.

What protected terms don’t do

• They don’t change the default language. For article text and translation jobs, protected terms only affect non-default languages. Your articles in the default language still say what they say.
• They don’t leave article slugs alone. Each translation gets its own slug, translated to a URL-friendly version in that language by the same pass that applies your protected terms, and the result is always lowercased and hyphenated.
• They don’t apply retroactively to manual edits. If you’ve edited a translation directly, that edit stays as-is even if a protected term would have changed it.
• They don’t apply to disabled modules. If Web Chat, Form Builder, or CSAT is off in the module toggles, protected terms won’t affect translations there until you enable that module.

Common patterns

• Lock down your brand and product names first. Add them all on day one, before customers see translated content.
• Add overrides as you spot mistranslations. When a customer or teammate flags an awkward translation, fix the protected term rather than the article — the fix propagates everywhere the module is enabled.
• Keep the list short and intentional. Hundreds of overrides slow translation jobs and make the term list hard to maintain. Prefer fixing translation prompts over piling up overrides.