Multi-language Knowledge Base

If your customers span multiple languages, the worst answer is “we have a help center, but only in English.” Atender’s Knowledge Base is built so you write articles once in your default language and translate them — on demand — into every active language. Translations cover categories, subcategories, articles, sections, and the surrounding UI strings on the public site.

Translation runs when you ask for it. Each language has a Translation Sync card showing coverage and a tenant-wide Last synced timestamp, so any admin can see when the current KB partition was last refreshed and whether it was run by an admin or automatically. Clicking Sync Translations queues jobs for whatever’s missing or out of date. This is deliberate: translation uses AI inference and costs money, so Atender doesn’t auto-translate on every save.

A typical cadence is to run Sync Translations after a batch of content edits (weekly, monthly, or after a major content push) rather than after every save.

What gets translated

• Article title — Yes — Per-language.
• Article summary — Yes — Per-language.
• Article body — Yes — Per-language. Markdown structure preserved.
• Category name and description — Yes — Per-language.
• Subcategory name — Yes — Per-language.
• Section names and descriptions — Yes — Per-language.
• Keywords — Yes — Per-language. Each language has its own keyword list.
• UI strings on the public site — Yes — The labels around your articles (“Search”, “Categories”, “Was this helpful?”) translate too.
• Tags — No — Tag slugs stay in the default language. The display name can be translated manually if needed.
• Protected terms — No (by design) — Brand names, product names, and any term you mark as protected stay untranslated. See Manage protected terms.

Languages, status, and the default

Each language has one of two statuses:

• Active — Live. Customers in this language see translated content.
• Disabled — Off. Customers in this language see the default language instead. Useful when you want to pause a language without losing translations.

New secondary languages are created Disabled. You run Sync Translations, review coverage, then toggle Active when you’re satisfied. There’s no “pending” middle state — the toggle is the readiness gate.

Exactly one language is the default. The default is the source of truth — translation jobs translate from it. Articles are authored in the default. You can change the default later, but it’s a heavier change — translations need to re-run from the new source via Force Retranslate All.

How translations stay current

Atender does not auto-translate on save. After publishing an article (new or edited), translations stay on whatever version they were on until you trigger a new run:

• Sync Translations — Translates everything missing or out of date. Cheap and incremental.
• Force Retranslate All — Re-runs every article through translation, ignoring existing translations. Costs significantly more — use after major content overhauls or after changing protected-term lists.

The Translation Sync card on each language shows current coverage so you can spot drift at a glance. See Translation completeness for the exact metrics.

How customers see the right language

The public help center detects the customer’s language from:

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

If the customer’s preferred language has no published translation for the article they’re reading, they fall back to the default language version. The article still loads — it just renders in the default language.

Markets vs. languages

Markets are a separate concept. A market is a region — country or country group — and is independent of language. See Markets vs Languages for the full distinction. Most teams start with languages only; markets matter primarily for regional content variants and search filtering.

When automatic translation isn’t enough

Auto-translation is fast and consistent, but it’s not perfect. Reach for the manual override when:

• A specific phrase needs the local-language convention. (“My account” might be “Min konto” by translation but “Mitt konto” is what customers actually expect.) Use a protected term with a per-language override.
• A product feature has a different name in a market. Same fix — protected term with per-language override.
• An entire article needs a different framing for one language. Edit the translation directly in the editor for that language. Manual edits stick — the next Sync Translations won’t overwrite them.

Where to go next

• Add a language: Enable a language
• See coverage in detail: Translation completeness reference
• Lock down brand terms: Manage protected terms
• Understand search across languages: KB search and AI retrieval