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 background translation caught up?
When you create or edit an article, Atender queues the translation automatically. 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 created or edited the article, allow the background translation to finish. The job picks up changed content and translates only what’s new. When coverage reaches 100%, the translation is live.
3. Was there a failure or delay?
If coverage stays incomplete longer than expected, check the latest background translation status for that language. A failed job may show a brief error message. Common causes:
- Rate limit hit during a large translation run. The background job should continue once capacity is available.
- 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 and remove the orphaned mapping.
After a fix, Atender will pick up the article again in the background. If coverage still doesn’t improve, contact support with the language, article URL, and any error shown in the translation status.
4. Is the customer’s browser actually requesting this language?
Translation only appears for customers whose browser asks for it. Atender checks (in order):
- The URL — if the address has
?lang=deor?lang=sv, that wins. - Their explicit choice from the language selector on the public site, remembered in their browser.
- Their browser’s language preference — what their browser asks for, only when the language selector is shown.
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 yet (the language was just enabled, or the background translation hasn’t finished), 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 background translation 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 automatically queues it for re-translation. If a translation is showing the pre-edit version, allow the background translation to catch up and then reload the article.
There’s no per-article re-translate button — translation runs at the language level for everything that needs work.