Why is my translation not appearing?

A customer visits your help center expecting Swedish, sees English instead. Or you previewed an article in German and the language switcher does nothing. Four checks, in order of likelihood.

1. Is the language Active?

Open Settings → Knowledge → Markets and Languages → Languages. Find the language in the Secondary Languages list and check the Active switch.

• Switch off → the language is Disabled. Customers fall back to the primary language even if the translation exists. Toggle the switch on to start serving translations again.
• Switch on → the language is live. Move to check 2.

2. Has the translation been generated yet?

Translations don’t run automatically when you create or edit an article. They run when someone clicks Sync Translations on the Languages subtab. Check the coverage panel for the language in question.

• Translated / total counter says 100 / 100 → translations are complete, the issue is elsewhere.
• Translated / total counter says 99 / 100 → exactly one article is missing. That’s likely the one you’re looking for.

If you just edited the article and haven’t synced yet, click Sync Translations. The job picks up changed content and translates only what’s new. Watch the job’s progress card; when it shows Completed, the translation is live.

3. Was there a failure?

Open the Translation Sync card. If the most recent job ended in Failed, the card shows a brief error message. Common causes:

• Rate limit hit during a large sync. Run Sync Translations again — it picks up where it left off.
• Source content had a structural issue (corrupted markdown, missing fields). Open the article in the primary language and republish to refresh the source.
• A protected term mapping referenced a language that’s been removed. Open Protected Terms, remove the orphaned mapping, and retry.

After a fix, re-run the sync.

4. Is the customer’s browser actually requesting this language?

Translation only appears for customers whose browser asks for it. Atender checks (in order):

1. The URL — if the customer is on /de/ or /sv/, that wins.
2. The Accept-Language header — what their browser asks for.
3. Their explicit cookie choice from the language selector on the public site.

To test:

• Open your help center in a private browsing window.
• Use the language selector on the public site to pick the target language.
• Reload the article.

If the article now renders in the right language, the original issue was the customer’s browser preference — not the KB. If it still doesn’t, you’re back to checks 1–3.

When fallback is doing its job

If a translation truly doesn’t exist for an article (sync wasn’t run, language was just enabled), the customer sees the default-language version with no error. This is the correct fallback — the article still loads, it just renders in the source language. After the next sync completes, the customer sees the translated version on their next visit.

If you specifically want a customer to not see fallback content for a partial translation, the cleanest answer is to disable the language until coverage is complete.

Edits and re-translation

Editing an already-translated article doesn’t automatically re-translate it. The next Sync Translations click will pick up the change. If a translation is showing the pre-edit version, run sync.

There’s no per-article re-translate button — sync runs at the language level for everything that needs work.

See also

• Translation completeness
• Enable a language
• Multi-language Knowledge Base
• Manage protected terms