Translation completeness
When you enable a language, the question that matters is “is this language ready for customers?” Atender answers it with two surfaces on the Languages subtab: a Translation Sync control card and a per-language coverage panel.
The Translation Sync card
Below the Secondary Languages list, the Translation Sync card carries two actions:
- Sync Translations — Queues translation jobs only for content in the currently selected KB partition/brand that doesn’t have an up-to-date translation in each active language. The normal everyday button.
- Re-translate all — Re-translates everything in the currently selected KB partition/brand, including content already translated. Useful after a wholesale prompt or terminology change. Expensive — uses AI inference for every article in every language for that partition.
The card also shows a Last run line for the latest successful sync in the currently selected KB partition/brand. This freshness line includes syncs started by other admins, and automatic syncs show no started by name. Failed jobs do not update the Last run timestamp.
When you click either button, a translation job kicks off for the currently selected KB partition/brand and the card shows live progress until it finishes. In multi-partition tenants, switch partitions and run sync separately for each brand you want refreshed.
Job statuses
A translation job moves through five states:
- Pending — Job is queued but hasn’t started running.
- Scanning — Atender is walking your KB to figure out what needs translating in each language.
- Translating — The actual translation work is running. The progress counts tick up as articles complete.
- Completed — All queued work finished. The job is done.
- Failed — The job hit an error and stopped. The card shows the failure reason.
The card polls every five seconds while a job is running, so you can watch the numbers move in real time.
What the job carries
For each running job you can see:
- Articles — completed / total across all secondary languages
- Categories — completed / total
- Subcategories — completed / total
- Skipped counts for each — content that was already translated and didn’t need work this time
- Target language count — how many languages this job is translating into
- Started at / completed at — timestamps for the job’s run window
The split between Total and Skipped is the difference between “all the content that exists” and “the content this run actually touched”. After a fresh enable, those two numbers are close. After steady-state operation, most runs skip most content and only translate the bits that changed.
The per-language coverage panel
Each secondary language has its own coverage card pulled from translation stats. It shows four counters (the fourth is sections):
- Articles translated / total — How many published articles have a translation in this language.
- Categories translated / total — How many categories have a name and description in this language.
- Subcategories translated / total — How many subcategories are translated.
When all four counters match (translated == total), the language is fully covered. Until then, customers in this language fall back to the default language on the untranslated items.
What gets translated
The translation pipeline operates at four levels:
- Article title — Yes
- Article summary — Yes
- Article body — Yes
- Article keywords — No
- Category name and description — Yes
- Subcategory name and description — Yes
- Section name and description — Yes
- Public UI strings (search box label, “How can we help?”, etc.) — Yes — translated by the same sync
- Tag names — No — tag slugs and display names stay in the default language
For brand names and product names you don’t want translated, use protected terms.
How completeness ties to retrieval
Search and AI retrieval honor the customer’s language when one exists. Rendering fallback and retrieval are separate:
- Public Help Centre search searches the customer’s selected language when it is known. If an article has not been translated into that language, its default-language version is not retrieved through that language-scoped search unless the language-scoped search finds no results at all, in which case it falls back to the default language.
- An already-opened article without a translation can still load and render in the default language. This fallback affects article rendering, not whether the article appears in language-scoped search results.
- AI retrieval, including Sidekick, web chat, and voice, follows the same customer-language retrieval behavior. When the customer’s language is known, untranslated default-language chunks are used as fallback retrieval results only when the language-scoped search returns no knowledge-base results at all.
So an article at 80% translation coverage in Swedish can still leave gaps in Swedish search and AI retrieval until the next sync completes the remaining translations.
Triggering re-translation
Translations are queued by an automatic sync that runs every 15 minutes, not on save. If you edit an article in the primary language, the automatic sync translates what changed within 15 minutes.
There’s no per-article translation button in the editor — sync runs at the language level for the currently selected KB partition/brand and works through whatever needs translating across that KB. The automatic sync covers every partition that has an active secondary language.