If you need to translate Kontent.ai content for a multilingual website, start by understanding language variants, language codenames, fallback chains and how the Delivery API chooses which content to return. Kontent.ai can keep one content item identity while managing individual language variants, but a language existing in the project does not mean its translated page is ready for the public. This guide explains how editors, translators and developers can work together without confusing drafts, published content or fallback text.
A dependable Kontent.ai localization workflow answers four questions for every language: what was translated, which source facts are still current, what a reader actually receives, and how the team proves that result. The difficult cases often involve linked content, non-localizable fields, missing variants and publication states. A perfectly fluent headline is not enough when one connected safety note is absent or a localized route retrieves the wrong language.
If you are searching for Kontent.ai multilingual SEO, language fallbacks or Delivery API language parameters, use the quick start first and then work through the field-level lessons, worked example, failure tests and release checklist. The advice applies to publishers in any country, with special care for factual, scientific, financial and public-information material where translation cannot become an invented promise.
Quick answer: the eight steps that matter first
- Choose and document the real source language and each stable target-language codename.
- Separate shared identifiers from text requiring translation and regional adaptation.
- Create one representative item with linked content, captions, a URL slug and an approval record.
- Translate and review each variant independently; do not count empty drafts as coverage.
- Test configured fallback chains, including missing parent and missing linked items.
- Check the Delivery API request’s language parameter and compare preview to public delivery.
- Verify navigation, metadata, accessible names, URLs, mobile views and anonymous caching.
- Publish only approved languages and retain evidence of what the public actually received.
A worked multilingual publishing project
A practical project makes the abstract details easier to see. Imagine a nonprofit education publisher maintaining a worldwide collection of plain-language guides about weather preparedness, public services and scientific literacy. Its main editorial team writes English, while local contributors prepare French, Spanish and Japanese reading experiences. Some information is general; other material references local numbers, regulations or emergency services that cannot safely be copied from another region.
The publisher uses one content item identity for each guide, separate language variants for the prose, linked cards for practical examples, and a frontend application to render the appropriate route. The first editorial question is not whether every locale flag exists. It is whether each visitor receives the correct approved explanation, including the links and secondary components they need to act responsibly.
Consider a single instruction: “Check the current local evacuation guidance before travelling.” It can be translated faithfully in every language while the linked municipal contact card cannot necessarily be reused. The principle is simple: translate general meaning, verify locality-dependent claims, preserve source identifiers and distinguish content approval from delivery configuration. This separation prevents a reassuring translated page from turning into inaccurate advice.
Before the first translation: four operating decisions
For each language, begin with a manifest rather than a vague promise. The manifest records the source item codename, language codename, editorial owner, source revision, target workflow step, linked items, public URL and known exceptions. Such a sheet can be small. Its advantage is that a translator can distinguish “text missing” from “text deliberately unavailable” and “text present through fallback.” Do not bury those differences inside a dashboard percentage.
Before large-scale production, build a test item whose fields expose common trouble: a heading, two paragraphs, an image with text, a date, a non-localizable reference ID, a linked item and a call to action. Choose a target language that has a complete translation and one that deliberately lacks a linked component. This makes it possible to prove what your present project actually does rather than trusting a generic setup diagram.
Agree on approval standards before translation begins. A native-language reviewer should check natural readability and tone; a subject expert should check consequential claims; a publisher should verify URLs, metadata and public behavior. In small teams one person can hold multiple roles, but the final decision still needs a recorded basis. Automation and machine translation can help generate a first pass; they cannot verify local permissions or make regional claims true.
When stakeholders ask how long localization will take, count the work units that actually need handling. Translating a short abstract is different from checking every linked card and variant of a diagram. Budget for source revision, accessible text, route testing, browser behavior, responsive layout, fallback exceptions and reader feedback. These are part of publishing, not optional polish once the translation is “done.”
Kontent.ai localization in depth: 25 decisions that prevent wrong-language publication
1. Content item identity is not a translated page
In Kontent.ai, a content item supplies shared identity while its language variants hold the audience-facing content. The name and codename are shared, but a variant has its own text and workflow. This means a single item can represent one policy across markets without asserting that every market has an approved translation.
Imagine a public learning project with one item called ‘Preparing for a Flood’. English and Spanish readers need different prose while editors still recognize the same underlying topic. Keep the stable codename in the inventory and inspect each language variant independently.
A dashboard showing one content item can create the false impression that every language is finished. A contributor may also mistake an empty language variant for an intentionally blank page.
What to test: Open the item in each intended language and record its workflow status, title, body fields and last approval separately. Test the public result, not just the content list.
Decide this point by reference to the reader’s task, not only the CMS configuration. In ordinary descriptive copy a minor fallback may be acceptable with a clear notice. In an eligibility rule, safety instruction, price, deadline or contractual statement, an unapproved fallback may be materially misleading. Classify the example and document which outcome is permitted before exposing the page.
2. Define the true default language
Every Kontent.ai project has a default language that has no fallback and cannot be deactivated. The correct default is the language in which canonical content is actually maintained, not an assumed global audience preference. Changing which language people see at the website is a separate presentation decision.
For an international museum whose editorial team writes in British English, the source language must be documented explicitly even if its largest readership lives elsewhere. Record whose wording controls terminology and updates.
Teams sometimes choose a default for marketing convenience and then treat fallback text as an approved source. This obscures what was translated from what.
What to test: Inspect localization settings, content models and the source editorial calendar. Confirm that an untranslated request leads to the behavior the product promises.
The useful unit of testing is the page as received by a visitor. An editor interface can show correct values while a frontend fetch, linked item or cache serves something else. Check the primary sentence, its dependent component, the action it invites, and the language signalled by the page. These elements must tell one consistent story.
3. Use stable language codenames
Kontent.ai lets a project label languages for editors and give each language a machine-readable codename. Its documentation recommends standardized short codenames such as fr-CH. These codenames are used by applications requesting localized content; a friendly display name alone is not a safe API key.
A charity may display ‘French for Switzerland’ to editors while its frontend requests fr-CH. Document both values. Check punctuation, case and regional suffixes with the development team before launch.
A spelling correction to the human label should not silently create a new routing scheme. Confusing fr-CH with fr-FR can change word choice, contact instructions and fallback behavior.
What to test: Ask a developer to show the language value in a real Delivery API request and compare it with the configured codename. Confirm the returned variant and page language.
A good translation is not word substitution alone. Ask whether a reader could describe what action the text authorizes, what it does not authorize, and where uncertainty remains. Regional language sounds natural when the message respects audience context without altering evidence. Keep original numbers, identifiers and conditions traceable to a source.
4. Separate non-localizable from localizable elements
Kontent.ai content elements are localizable by default, but a model can mark selected elements non-localizable. Those fields are edited in the default language and shared across language variants. Use this feature for truly invariant identifiers and shared facts, not merely to save translation time.
An equipment guide may share an internal product identifier and revision code while translating warnings, headings and contact instructions. Decide field by field; a global phone number can be common while an emergency contact may be regional.
Putting visitor-visible prose into a non-localizable element prevents translators from adapting it. Conversely, copying a unique identifier into each language creates opportunities for mismatched codes.
What to test: Inspect the content type field settings and sample API output in two languages. Confirm that shared fields stay equal and localized fields can differ without corrupting identity.
Localization choices have operational costs. If a field is shared, the team saves duplicate editing but may lose necessary adaptation; if a variant is independent, editing becomes flexible but requires synchronization. Select the tradeoff deliberately. The right model is the smallest one that preserves meaning, permissions and useful public delivery.
5. Plan localized field boundaries
A content model should separate title, summary, body, button text, image description, URL slug and legal notice when those parts have different approval requirements. A single giant rich-text body is convenient for drafting, but it hides components whose localization and publication status must be tested independently.
For a multilingual course page, the learning outcome might change only through approved source revisions; the booking button may link to a region-specific service. Represent these as deliberate fields and linked content rather than editable fragments of HTML.
When everything is one blob, a translator may overlook accessible labels or overwrite a tracking token. Text embedded in a screenshot can also escape normal extraction.
What to test: Inventory all visible text, source asset, destination field and reviewer. Preview narrow-screen and assistive technology views, not only the desktop article body.
Decide this point by reference to the reader’s task, not only the CMS configuration. In ordinary descriptive copy a minor fallback may be acceptable with a clear notice. In an eligibility rule, safety instruction, price, deadline or contractual statement, an unapproved fallback may be materially misleading. Classify the example and document which outcome is permitted before exposing the page.
6. Understand language fallback chains
Kontent.ai language settings can define ordered fallback languages. An unavailable fr-CH variant might fall back to fr-FR and then to the default language. This provides continuity, but it is not a guarantee that the returned text is appropriate or legally safe for a Swiss audience.
A global transport guide might tolerate fallback for a neutral history paragraph but not for border-control instructions or a locally approved emergency number. Classify fields and pages by risk before deciding where fallback is acceptable.
A reader can see apparently complete content while the underlying variant is absent. Fallback can make a localization coverage dashboard look better than the actual human translation record.
What to test: Request a missing translation deliberately, trace the language used in the response, and record which fallback level delivered it. Show an editorial alert for consequential content.
The useful unit of testing is the page as received by a visitor. An editor interface can show correct values while a frontend fetch, linked item or cache serves something else. Check the primary sentence, its dependent component, the action it invites, and the language signalled by the page. These elements must tell one consistent story.
7. Do not assume fallback cycles are fatal
Kontent.ai documents that even cyclic fallback configurations are handled by its Delivery API, which can eventually return default-language content when no requested variants are available. That behavior should not be interpreted as a recommendation to design a confusing cycle.
For a team managing French dialects, draw arrows from each regional codename to its intended parent language. A simple chain is easier for editors to understand and audit than relationships that return to themselves.
If the team confuses configured language order with a translation priority list, a page may surface text from an unexpected market without anyone noticing.
What to test: Create a small matrix of available and missing variants, then run requests for each language. Compare results to the written fallback policy and revise the policy if they diverge.
A good translation is not word substitution alone. Ask whether a reader could describe what action the text authorizes, what it does not authorize, and where uncertainty remains. Regional language sounds natural when the message respects audience context without altering evidence. Keep original numbers, identifiers and conditions traceable to a source.
8. Default linked-content handling needs attention
Kontent.ai documents a distinction between a parent variant and linked items. Under default linked-content behavior, a localized parent may omit linked content that lacks the matching language. It does not simply guarantee a complete translated graph of all related components.
In a Spanish learning article, one linked example card may still exist only in English. The main article can load correctly while the card disappears, leaving the explanation without its worked example.
This can look like a frontend rendering defect when the actual cause is an unlocalized linked item. Translators working solely on the parent may never notice the missing card.
What to test: Test linked-item relationships in a real API response. Track not only parent coverage but the localization status of every mandatory component.
Localization choices have operational costs. If a field is shared, the team saves duplicate editing but may lose necessary adaptation; if a variant is independent, editing becomes flexible but requires synchronization. Select the tradeoff deliberately. The right model is the smallest one that preserves meaning, permissions and useful public delivery.
9. Optional linked-item fallbacks change the result
Kontent.ai also documents an opt-in linked-content fallback behavior that evaluates linked items’ fallback chains independently. Availability must be confirmed for the project; do not assume it is enabled everywhere. It can preserve components but can also mix audience languages in a single page.
A Portuguese article could display an English linked safety note under one configuration and omit the note under another. Neither outcome is automatically acceptable; the publisher decides whether the mixed-language experience is truthful and usable.
A global ‘fallback on’ switch is not a substitute for reviewing sensitive linked content. A translated parent with fallback links can mislead readers about what has received local approval.
What to test: Verify the project’s setting, the link type, the response’s actual item language and the user-facing result. Record an exception when a linked component stays untranslated.
Decide this point by reference to the reader’s task, not only the CMS configuration. In ordinary descriptive copy a minor fallback may be acceptable with a clear notice. In an eligibility rule, safety instruction, price, deadline or contractual statement, an unapproved fallback may be materially misleading. Classify the example and document which outcome is permitted before exposing the page.
10. An empty variant is still an editorial state
When a contributor opens an untranslated item in another language, Kontent.ai can create an empty draft variant. The change from ‘Not translated’ to a draft does not mean an approved sentence exists. Content operations need to distinguish no translation, started translation, review and publication.
A training coordinator may open dozens of Japanese variants while planning the next quarter. If a report counts every draft as coverage, the project will celebrate progress that learners cannot yet use.
Blank drafts are easy to confuse with deliberate short forms or archived versions. An automated exporter may pick the wrong object if it ignores variant status.
What to test: Build coverage reports from actual filled required fields and approved workflow steps. Spot-check the draft against the public Delivery API before declaring it complete.
The useful unit of testing is the page as received by a visitor. An editor interface can show correct values while a frontend fetch, linked item or cache serves something else. Check the primary sentence, its dependent component, the action it invites, and the language signalled by the page. These elements must tell one consistent story.
11. Treat workflow as language-specific
Kontent.ai stores workflow details such as step, contributors, due dates and versions for individual language variants. A source item can therefore be live in one language and awaiting legal review in another. This is normal and should be visible to the delivery team.
A French patient information note might have passed clinical and language review while the German version is awaiting a regional regulator’s wording. One shared item identity does not authorize simultaneous release.
Release calendars that use only the source language’s published status risk exposing an unfinished version or blocking a completed one unnecessarily.
What to test: Read the workflow state for each locale and document the named decision-maker. Test both preview and public delivery, because the presence of an item in the editor is not proof of live visibility.
A good translation is not word substitution alone. Ask whether a reader could describe what action the text authorizes, what it does not authorize, and where uncertainty remains. Regional language sounds natural when the message respects audience context without altering evidence. Keep original numbers, identifiers and conditions traceable to a source.
12. Design ownership rather than a translation queue alone
Good localization work has at least a source owner, a translator or adapter, a subject reviewer and a publisher responsible for public behavior. These roles can be combined in a small team, but the decisions should remain explicit and auditable.
For a global science resource, one editor owns factual changes, language specialists own readability, and a developer owns whether page requests select the approved variant. A reviewer should be able to reject a misleading translation without losing the source.
If ‘translation complete’ means only that text was entered, terminology drift, wrong links and unsupported claims travel directly to users.
What to test: Use a release sheet listing source revision, target codename, reviewer, issues, resolution and sign-off. A local reviewer must see the page in context.
Localization choices have operational costs. If a field is shared, the team saves duplicate editing but may lose necessary adaptation; if a variant is independent, editing becomes flexible but requires synchronization. Select the tradeoff deliberately. The right model is the smallest one that preserves meaning, permissions and useful public delivery.
13. Write a term bank before mass translation
Kontent.ai does not remove the need for editorial terminology. Create a small controlled glossary for high-impact names, interface actions, units, programme descriptions and prohibited shortcuts. Preserve official brand names and identifiers; translate explanatory text for comprehension.
A multilingual financial education team might distinguish ‘estimate’, ‘guarantee’, ‘fee’, ‘refund’, and ‘reversal’. These concepts must stay separate even when a machine-generated first draft sounds fluent.
A single ambiguous word may reverse an obligation or make a tentative estimate sound promised. Repetition across linked items can spread that error widely.
What to test: Review terms across a representative page set in each locale. Ask a native-speaking reviewer to explain the meaning, not merely to back-translate individual words.
Decide this point by reference to the reader’s task, not only the CMS configuration. In ordinary descriptive copy a minor fallback may be acceptable with a clear notice. In an eligibility rule, safety instruction, price, deadline or contractual statement, an unapproved fallback may be materially misleading. Classify the example and document which outcome is permitted before exposing the page.
14. Use source revision IDs
A translated variant is attached to a shared item identity, but translations can become stale when the source is edited. Keep a source revision marker, update reason and affected field list outside the body text or in an appropriately governed workflow record.
An admissions article may change one eligibility condition and leave the rest unchanged. The translation team must know exactly which variants need reassessment instead of automatically rewriting all paragraphs.
Without revision tracking, an older target-language page may remain polished and convincing while quietly presenting superseded policy.
What to test: Record the source change, compare translated fields, resolve impact on linked items and re-run the target-language acceptance tests. Do not assume unchanged copy means unchanged meaning.
The useful unit of testing is the page as received by a visitor. An editor interface can show correct values while a frontend fetch, linked item or cache serves something else. Check the primary sentence, its dependent component, the action it invites, and the language signalled by the page. These elements must tell one consistent story.
15. Use the Delivery API language parameter deliberately
Kontent.ai Delivery API documents a language query parameter for content requests. Without it the API returns the default language. When the requested variant is unavailable, configured fallbacks apply. This is application behavior that should be verified from actual responses, not inferred from the browser language.
A content API may retrieve /items/course_overview?language=fr-CH for a French Swiss route. The application must use its configured language codename and consistently pass it for page content and reused components.
If the frontend omits language for one secondary request, navigation may be French while an important explanatory card is English. Browser location alone will not correct an API call.
What to test: Inspect request URLs or network logs for the language parameter, then compare the returned fields. Repeat for missing variants, linked content and default-language requests.
A good translation is not word substitution alone. Ask whether a reader could describe what action the text authorizes, what it does not authorize, and where uncertainty remains. Regional language sounds natural when the message respects audience context without altering evidence. Keep original numbers, identifiers and conditions traceable to a source.
16. Preview is not the same as delivery
Kontent.ai exposes preview delivery as distinct from public delivery. Editorial preview should show an approved candidate to reviewers; public delivery must honor actual publication state. QA that tests only editor previews does not prove that visitors receive the same words.
A Spanish article may look correct through a preview token while the public API still serves the last published wording. A release checklist should open a clean browser and fetch public content without editor credentials.
A reviewer can mistakenly approve a preview URL and assume the public product has updated. Caching can create further delays in what anonymous readers see.
What to test: Check both environments with the same locale and item identity, and record timestamp, response source and visible text. Investigate differences before signing off.
Localization choices have operational costs. If a field is shared, the team saves duplicate editing but may lose necessary adaptation; if a variant is independent, editing becomes flexible but requires synchronization. Select the tradeoff deliberately. The right model is the smallest one that preserves meaning, permissions and useful public delivery.
17. Handle not-found and fallback as different outcomes
An intentionally absent translation can produce a fallback, an empty component or a route-level not-found decision depending on application design. These represent different user experiences. Choose a clear policy for pages where partial translation would confuse readers.
A museum might allow English fallback for an exhibition history article but withhold a translated ticket-eligibility page until it is approved. The website can give an understandable language notice rather than silently presenting the wrong offer.
A route that returns HTTP success and a default-language page can look indexed and healthy while failing the visitor’s language expectations.
What to test: Document route policy, fallback precedence and visitor notice. Run both missing-item and missing-linked-item cases and verify that the observed response follows the stated policy.
Decide this point by reference to the reader’s task, not only the CMS configuration. In ordinary descriptive copy a minor fallback may be acceptable with a clear notice. In an eligibility rule, safety instruction, price, deadline or contractual statement, an unapproved fallback may be materially misleading. Classify the example and document which outcome is permitted before exposing the page.
18. Build localized slugs and links upstream
The CMS language variant is only one layer of international navigation. Frontend routes, translated slugs, canonical URLs and internal linking must agree on the intended version. A translated title does not automatically ensure a localized URL structure that search engines can interpret.
For a global curriculum project, map every published variant to its actual canonical page URL. When translated slugs change, consider redirects and update language-switch destinations.
A visitor can switch from a translated page to a default-language homepage if the site does not maintain equivalent-page relationships. Old slugs may continue to receive external traffic.
What to test: Test direct URL loading, navigation links, redirects and language-switch behavior across all intended variants. Verify only real published routes appear in indexable metadata.
The useful unit of testing is the page as received by a visitor. An editor interface can show correct values while a frontend fetch, linked item or cache serves something else. Check the primary sentence, its dependent component, the action it invites, and the language signalled by the page. These elements must tell one consistent story.
19. Give SEO fields their own review
Search snippets and headings can create promises independent of the article body. Localize titles and descriptions according to actual audience questions, but never invent outcomes, availability or credentials to make a result attractive.
An educational page translated to Japanese may use a naturally phrased search term rather than a literal English heading. The snippet should still describe exactly what the page explains and who it helps.
If a default-language description remains attached to a translated URL, search visitors may mistrust the page or misunderstand the subject before entering it.
What to test: Examine page source for title, description, canonical and any hreflang elements; ensure they point to the actual language URL, not the API record ID.
A good translation is not word substitution alone. Ask whether a reader could describe what action the text authorizes, what it does not authorize, and where uncertainty remains. Regional language sounds natural when the message respects audience context without altering evidence. Keep original numbers, identifiers and conditions traceable to a source.
20. Audit media and alt text
Images can contain language-dependent meaning through captions, diagrams, subtitles or text embedded inside the image. Model and translation workflows should account for these assets, while preserving identifiers, licences and attribution details when legally required.
A laboratory teaching page may reuse one labelled illustration in several markets. If labels are visible inside the picture, a translated body paragraph cannot make the illustration accessible on its own.
Missing alt text, mismatched transcript language or screenshot-only instructions can exclude users who need assistive technology or read on mobile.
What to test: Inspect visible image text, captions and alternative descriptions in every live variant. Ask whether a learner who cannot see the image receives the same essential explanation.
Localization choices have operational costs. If a field is shared, the team saves duplicate editing but may lose necessary adaptation; if a variant is independent, editing becomes flexible but requires synchronization. Select the tradeoff deliberately. The right model is the smallest one that preserves meaning, permissions and useful public delivery.
21. Keep dates, units and numbers trustworthy
Regional adaptation is not free permission to change facts. Display formats can differ; underlying amounts, thresholds and scientific units should remain tied to source evidence. A changed currency is a new calculation or local offer, not a translation of the same value.
An environmental guidance card might use a temperature value in Celsius and an approved conversion for Fahrenheit readers. The team must document rounding and never alter an exposure threshold because a translator guessed.
Ambiguous dates such as 04/05 can create practical errors when a deadline or event is involved. Numbers in rich text are easily missed by language-only QA.
What to test: Compare numeric invariants against a source register; use explicit month names where clarity matters, and test rendering with representative locale conventions.
Decide this point by reference to the reader’s task, not only the CMS configuration. In ordinary descriptive copy a minor fallback may be acceptable with a clear notice. In an eligibility rule, safety instruction, price, deadline or contractual statement, an unapproved fallback may be materially misleading. Classify the example and document which outcome is permitted before exposing the page.
22. Protect cache keys and build releases
When API responses vary by language, caches and static builds must distinguish locales. Otherwise a valid French response could be reused on an English route, or a newly published version could be hidden behind stale content.
A multilingual learning portal using a CDN may cache an article by path but forget to include locale in the cache key if the language comes from an API parameter. The content model may be correct while public delivery is wrong.
A successful editorial publish event is not enough to establish that every visitor receives the new translation. Browser and edge caches may outlive the update.
What to test: Compare anonymous requests in two locales, repeat after a source change and inspect response headers or build output. Purge only the appropriate entry and retest.
The useful unit of testing is the page as received by a visitor. An editor interface can show correct values while a frontend fetch, linked item or cache serves something else. Check the primary sentence, its dependent component, the action it invites, and the language signalled by the page. These elements must tell one consistent story.
23. Test the language selector as a navigation feature
A language selector is an application feature, not a translation control inside Kontent.ai. It should take the reader to an equivalent approved version when available and explain unavailable language options. Avoid presenting flags as an unambiguous substitute for language names.
A visitor reading a course FAQ in German should not unexpectedly land on the English homepage after switching to French. Preserve article identity where the target equivalent exists; otherwise say why it is unavailable.
Broken equivalence can erase the reader’s place or silently switch markets. Some languages are used across multiple countries, making national flags misleading.
What to test: Start from deep links and switch in both directions, then test keyboard navigation, screen-reader labels and direct URL loading. Confirm the chosen API language matches the selected route.
A good translation is not word substitution alone. Ask whether a reader could describe what action the text authorizes, what it does not authorize, and where uncertainty remains. Regional language sounds natural when the message respects audience context without altering evidence. Keep original numbers, identifiers and conditions traceable to a source.
24. Measure coverage without exaggeration
A strong localization report distinguishes item count, required field completion, editorial approval, linked-content coverage and public URL availability. No single percentage captures all these states. Publish the meaning of the metric alongside any dashboard.
A project with 90 percent translated titles but 35 percent approved body content is not almost complete. A local programme could prioritize its ten critical pages before hundreds of low-risk archived items.
Treating machine-draft existence as completed translation makes planning look reassuring while users still encounter unreviewed material.
What to test: Use a small stratified sample across page templates, language pairs and risk levels. Compare dashboard claims with actual public pages before reporting success.
Localization choices have operational costs. If a field is shared, the team saves duplicate editing but may lose necessary adaptation; if a variant is independent, editing becomes flexible but requires synchronization. Select the tradeoff deliberately. The right model is the smallest one that preserves meaning, permissions and useful public delivery.
25. End with release evidence instead of confidence
A safe launch has a reproducible set of checks: correct language codename, intended variant, complete linked graph, approved workflow state, accurate facts, correct routes, working accessible navigation and public delivery proof. Put a named person behind each unresolved risk.
For the course page, the publisher should be able to answer what changed, which locale was approved, where the live page appears and which reviewer checked it. This is possible without making the process bureaucratic.
‘It looks fine on my laptop’ is not an acceptance test. Missing components, fallback surprises and mobile truncation often appear after the editor considers work finished.
What to test: Store a dated URL, screenshot or content diff, API result, issue register and reviewer decision. If a high-risk assertion remains unchecked, withhold that variant rather than guessing.
Decide this point by reference to the reader’s task, not only the CMS configuration. In ordinary descriptive copy a minor fallback may be acceptable with a clear notice. In an eligibility rule, safety instruction, price, deadline or contractual statement, an unapproved fallback may be materially misleading. Classify the example and document which outcome is permitted before exposing the page.
A complete acceptance test you can perform in one afternoon
Create three variants of the same article: one source page, one completely approved translation, and one intentionally incomplete translation. Include two linked components, only one of which is available in the target language. Keep notes of the actual language codenames rather than guessed names. Build a checklist before changing settings so you can compare the observed behavior with your intended policy.
First inspect the published source and translated article in the editorial interface. Then open the preview environment and record visible field values. Finally request the same item through the public Delivery API using the target language parameter, and load the corresponding website URL in a private browser session. If the language, linked content or publication state differs, record the smallest reproducible example. A discrepancy is valuable evidence, not something to conceal with a screenshot of a different page.
Second, remove the target-language text from one harmless test component and repeat the exercise. Distinguish a missing localized parent from a missing linked child. If the response uses a fallback, write down which language supplied the field and whether the user was informed. Test the reverse direction: starting on a deep target-language URL, switch language, navigate back and verify the reader returns to the equivalent content rather than an unrelated homepage.
Third, change one non-localizable field and one localized field in the test environment. Confirm that the shared value behaves as the model promises and that the language-specific value does not leak into another variant. Publish only the reviewed target and recheck anonymous delivery after your normal cache or build process. This creates evidence that the CMS, API, website and editorial workflow agree. Never perform destructive experiments on real public documents.
Frequently asked questions
Does adding a Kontent.ai language automatically translate content?
No. Languages establish places for language variants. Editors still need to produce, review and publish meaningful text. Opening an untranslated variant can make an empty draft, which should not be counted as an approved translation. A robust dashboard tracks filled required fields and publication separately.
What happens if a requested variant is unavailable?
The Delivery API can use the configured fallback language chain. Its result may be intelligible but not necessarily appropriate for that region. Check whether fallback is acceptable for the page’s claims; test the actual response instead of assuming an absent variant will always cause a 404.
How do I request another language in the Delivery API?
Use the documented language query parameter with the configured machine-readable codename. Keep the same language choice for primary content and linked components. An omitted parameter normally retrieves the default language, which can create a partly translated page without an obvious error.
Will an untranslated linked item always fall back?
No. Kontent.ai distinguishes default linked-content behavior from an optional setting that evaluates the fallback chain for each linked item. Projects can differ. Inspect your project configuration and actual API response, including linked items inside rich text, before writing application assumptions.
Do all variants publish together?
Do not assume that they do. A language variant has its own workflow information and may be in a different review or publication stage. A source change should trigger a translation impact review rather than treating every old translation as automatically current.
Which fields should be non-localizable?
Only fields with genuinely shared meaning, such as stable internal codes or truly universal reference values. Visitor-facing prose, legal conditions and locally different contacts often require localizable treatment. Field settings should represent the meaning of the data, not merely the convenience of editors.
How do I avoid SEO duplication across languages?
Give each published page a real stable URL and appropriate page-language metadata, canonical information and equivalent-language links. Do not point hreflang to a translation that has not been published. Use search-intent wording in headings while remaining accurate about the page’s actual guidance.
Can machine translation replace a reviewer?
It can accelerate a first draft in some settings, but it cannot check jurisdiction-specific permission, regulated terms, original factual evidence or visual context on its own. Combine linguistic review with subject review and a public-page delivery test for consequential content.
How do I show that a translation is complete?
Use a clear acceptance definition: required fields present, terminology reviewed, linked components accounted for, target-language workflow approved, metadata and accessible text correct, and anonymous public delivery verified. Store exceptions openly instead of converting them into a misleading percentage.
What should I do when source English changes?
Identify the changed fact, affected target variants and linked records. Ask whether the change is substantive, then re-review only the necessary components with the original evidence. A source update does not automatically fix previously published translations; a reviewed release closes that gap.
Official documentation and further reading
- Kontent.ai: configure languages, codenames and fallback rules
- Kontent.ai: understand and manage language variants
- Kontent.ai: Delivery API content items and language query
- Kontent.ai: language management API objects
Check the version and settings of your own environment before treating an API example or optional behavior as universal. Product interfaces and entitlements may change; the official documentation is the reference for current implementation details.
Continue through the eduKate translation library
This chapter is a practical Kontent.ai guide within the broader Master Art of Translation. For platform-specific lessons in the same learning pathway, use the Translate Like a Pro series index. The master explains translation principles; this chapter answers what to configure and test in Kontent.ai without replacing the broader architecture.
The final professional habit is to verify what a real reader receives. A project can be elegantly modeled, translated and reviewed, yet still deliver the wrong language through a missing API parameter or a linked item. Publication becomes dependable when the factual source, editorial variant, request, navigation and public page all agree.