How do you translate Jahia 8.2 content for an international audience without confusing language settings, editorial approval and what visitors actually see? This guide explains Jahia multilingual sites, internationalized content properties, language activation and publication workflows, starting with the practical route from a source claim to a reviewed target-language page. The central problem is not the difficulty of replacing words. It is ensuring that the right meaning, source revision and destination survive every system that carries the information.
If you need a Jahia 8.2 multilingual website or localization workflow, begin with the quick checklist below. Then follow the examples, the technical decisions and the validation exercises to understand the difference between a configured language, a translated field, a reviewed item and a published visitor journey. These differences matter for worldwide readers, including people who depend on accurate dates, rules, accessibility labels and instructions before they can make a decision.
This practical Jahia 8.2 translation tutorial is intended for Jahia site administrators, content model developers and translation reviewers. It covers Jahia multilingual sites, internationalized content properties, language activation and publication workflows with a worked example, release tests, common failures and links to official product documentation. It is a platform-specific implementation chapter, not a substitute for the larger subject of translation theory. Start with one real reader task and expand only after you can prove the result in an anonymous public browser.
Quick answer: a practical ten-step localization checklist
- Confirm the software version, hosting arrangement and public frontend technology.
- Identify the source language, target locales and responsible content owners.
- Map which values are shared facts, translatable fields or regional policies.
- Create a small test item and establish stable identity across languages.
- Configure language or locale behavior using the documented workflow.
- Translate complete reader journeys, including links, captions and forms.
- Review claims, numbers, conditions and context against source evidence.
- Compare editorial preview with published API or page delivery.
- Test search, accessibility, route switching, caching and language metadata.
- Release only approved language variants and preserve revision evidence.
A worked example: a public cultural foundation that must provide English, French and Arabic exhibit information while each language has its own editorial reviewers and launch date
Imagine a public cultural foundation that must provide English, French and Arabic exhibit information while each language has its own editorial reviewers and launch date. The team already has good information in its original language. New audiences need material that is natural to read and trustworthy enough to use. A software configuration can make a language available, but it cannot by itself decide which factual claims may be shared, which examples require localization or when an unfinished translation may go live.
The first useful artefact is a content map. Give every article or record an identifiable source and owner. Separate its stable data from descriptions that need a different language. Put dates, contact details and public actions in the map, even when they seem incidental. People often discover that a multilingual error is not a wrong dictionary choice: it is a page using an outdated source, the wrong market or the wrong linked destination.
On a staging site, enable a second language for editing but leave it unavailable live. Create one page with an internationalized title, body and image reference, then submit its translation for the required approval workflow. Verify the source language remains available and the target route is withheld until activation. Next test a deliberately missing field with the documented mixing policy and decide whether that behavior is appropriate for a public audience.
When the experiment works, resist turning its success into an unlimited claim. One translated item proves only that the tested content, locale, workflow and route behaved as expected. A public launch needs a repeatable standard for missing values, later revisions, fallback, search, assistive technology and who is allowed to publish. Use the chapters below to make those standards explicit and understandable to the people responsible for the site.
What counts as a complete translation?
A translated page is complete when the visitor can identify the subject, understand the same supported claim, see local adaptations clearly, follow each necessary link and act without being surprised by a different language. This includes visible headings, hidden accessibility text, captions, errors, menus and data supplied by external services. The test is not the number of translated words: it is whether the information remains useful and correct across the whole encounter.
A coverage matrix makes the answer concrete. Across the top place the intended languages and public routes. Down the side list the article body, title, media explanation, search result, navigation, form and important outbound references. In each cell record absent, draft, linguistically reviewed, factually reviewed or publicly verified. Distinguish deliberate reuse of universal facts from unintended English fallback.
Jahia 8.2 localization in depth: 39 decisions and checks
1. Configure site languages before editing
Jahia 8.2 administers website languages under Administration, Sites, Languages. Available, default, mandatory and active settings have distinct consequences. Think about the ownership of the data before thinking about vocabulary. A shared fact should have one identifiable source; a local adaptation should have a named reason. Those are different editorial obligations.
A cultural foundation adds French and German to a long-running English site, without wanting to expose incomplete translations immediately. An editor should identify the exact source record and intended audience before changing a language value. Make sure that the surrounding page does not change the scope of the statement.
Adding a language does not by itself prove translated content is present or available to public visitors. This is why editorial review and technical testing must be independent: a valid configuration does not guarantee a valid statement.
Practical verification: Record each language’s settings, editor permissions and intended public launch stage before content creation. Save the expected outcome next to the observed outcome; if they differ, identify the owning team before changing configuration.
2. Distinguish generic and regional locales
The Jahia language guide describes locale choices such as French and regional forms such as fr_CA or fr_FR. These are different content policies, not merely spelling preferences. Readers do not see the content-management boundaries. They experience a continuous page, so the review must follow the visible journey rather than stopping at the field editor.
A museum publishes French globally but needs Quebec-specific operating hours and ticket policy on one market site. A developer should check the real rendered result as well as the administrative settings. Matching text in a test form is not enough when a route or integration can select a different record.
Choosing a regional code unnecessarily can multiply translation maintenance; using generic French for local legal notices can be misleading. If a reader acts on the content, the cost of that mistake is measured in understanding and decisions, not merely visual inconsistency.
Practical verification: Write down the exact purpose of each locale and test an example in more than one market. Repeat the experiment after a small source edit to prove that your update policy continues to work when content evolves.
3. Understand the default language’s role
Jahia uses a configured default language when no supported visitor preference can be resolved. Its documentation also gives the default language particular system-name responsibilities. Treat the source statement as a claim that can be checked, not a string that merely needs different spelling. Dates, conditions and scope must survive the move between languages.
A public information portal retains English as the source and introduces French and Arabic for readers worldwide. An editor should identify the exact source record and intended audience before changing a language value. Make sure that the surrounding page does not change the scope of the statement.
Editors who treat default as a cosmetic label may break URL expectations or publish unreviewed fallback prose. An error can survive an attractive layout and a successful HTTP response, making it especially important to test the underlying meaning.
Practical verification: Verify the default site language and trace how one unsupported-language request is handled. Use a test item containing a number, an exception and a link, because these expose errors hidden by a friendly one-sentence greeting.
4. Respect the shared site structure
Jahia documentation says the site structure is the same across languages, while internationalized fields carry language-specific values. Removing content may affect all language versions. Make the test observable: record the requested locale, the actual returned value, the source revision and the public URL. A green status badge without that evidence can mislead.
A research organisation translates one article node into several languages and wants its references to remain identifiable. A developer should check the real rendered result as well as the administrative settings. Matching text in a test form is not enough when a route or integration can select a different record.
Deleting a supposedly French-only node may remove the shared structure or content across languages. This is why editorial review and technical testing must be independent: a valid configuration does not guarantee a valid statement.
Practical verification: Test changes in a non-production tree and compare the node identity and language-specific fields before deleting anything. Check the same state on desktop and mobile, then verify that a keyboard user can complete the central task.
5. Mark fields internationalized in content types
Jahia developers can mark fields with internationalized or i18n in content type definitions. Only the fields designed to vary by language should carry separate text or media values. Separate configured capability from completed work. The existence of a locale option or a valid response says little about whether the reader has received a reviewed explanation.
A heritage exhibit has different body text and captioned images per language but one canonical accession number. An editor should identify the exact source record and intended audience before changing a language value. Make sure that the surrounding page does not change the scope of the statement.
If an essential title is not internationalized, editing it in one language may unexpectedly affect other readers. If a reader acts on the content, the cost of that mistake is measured in understanding and decisions, not merely visual inconsistency.
Practical verification: Inspect the actual content type definition and review which properties need language-specific values. Ask a reviewer to explain the target-language claim in their own words before treating the translation as accepted.
6. Treat media references as possible translated fields
The official Jahia developer example shows that even an image reference can be marked internationalized, not only a string. This enables culturally and linguistically suitable assets. When the sample fails, isolate whether the cause is data modelling, editorial approval, route selection or delivery. Each cause requires a different repair and different owner.
An education foundation supplies distinct English and Arabic diagrams with embedded text and local explanations. A developer should check the real rendered result as well as the administrative settings. Matching text in a test form is not enough when a route or integration can select a different record.
Reusing an English-labelled image behind Arabic prose leaves the core evidence inaccessible to the intended audience. An error can survive an attractive layout and a successful HTTP response, making it especially important to test the underlying meaning.
Practical verification: Open the same content item in two languages and verify the correct image and alt description render. Confirm what happens to deep links, back navigation and search results rather than testing only the landing page.
7. Use mandatory languages with care
Jahia can require values in mandatory languages for certain mandatory properties; documentation warns these requirements affect whether nodes are considered valid and publishable. The best model is the simplest one that still expresses genuine regional differences and preserves stable identity. Extra duplication expands the number of revisions a team must reconcile.
A multilingual service wants emergency contact pages complete in English and French before any public release. An editor should identify the exact source record and intended audience before changing a language value. Make sure that the surrounding page does not change the scope of the statement.
Marking all new markets mandatory too early can block legitimate staged publication, while too few requirements expose incomplete essential pages. This is why editorial review and technical testing must be independent: a valid configuration does not guarantee a valid statement.
Practical verification: Configure the smallest justified mandatory set and rehearse a missing-value case in staging. Keep a source snapshot so that the team can detect obsolete target wording after an upstream correction.
8. Understand publication timing across mandatory languages
Jahia’s guide notes that a page with mandatory-language requirements may not become live until mandatory properties and publication workflows are satisfied in each required language. Assess the consequence to the person using the page. A wrong headline is inconvenient; a wrong deadline, payment rule or medical condition can change a real-world decision.
An English editor approves a new notice Monday, but a mandatory French version is not approved until Tuesday. A developer should check the real rendered result as well as the administrative settings. Matching text in a test form is not enough when a route or integration can select a different record.
The content team may misdiagnose an unpublished page as a technical error when the real blocker is a language-specific workflow. If a reader acts on the content, the cost of that mistake is measured in understanding and decisions, not merely visual inconsistency.
Practical verification: Record completion state and required property validation for each mandatory language before escalating a missing page. Use a lower-privilege account for the workflow test and a signed-out browser for the public delivery test.
9. Separate Active Edit from Active Live
Jahia has independent controls to let editors work in a language and to make that language accessible on the live site. Adding a language starts with live access disabled. Build one reversible experiment before implementing the policy across thousands of records. A small controlled example provides stronger evidence than assumptions based on an admin screen.
A non-profit translates German material privately for several weeks before announcing its German site. An editor should identify the exact source record and intended audience before changing a language value. Make sure that the surrounding page does not change the scope of the statement.
Turning on the live language too early can expose pages that are incomplete; confusing edit availability with live availability delays launch. An error can survive an attractive layout and a successful HTTP response, making it especially important to test the underlying meaning.
Practical verification: Test a draft German page with an editor and an anonymous browser before enabling Active Live. Test a complete locale, a partial locale and an unsupported locale as distinct input states.
10. Use language-specific publication workflows
Jahia’s documentation states that publishing changes can involve a separate publication request for each language. Approval of one locale is not blanket approval of all others. Record both what is intentionally shared and what is intentionally translated. The distinction helps a future editor understand whether the same visible value is correct or simply unfinished.
A public law guide needs its Spanish version legally checked while its English content already has final sign-off. A developer should check the real rendered result as well as the administrative settings. Matching text in a test form is not enough when a route or integration can select a different record.
Publishing in English cannot be treated as evidence that the Spanish claim was reviewed against the same source. This is why editorial review and technical testing must be independent: a valid configuration does not guarantee a valid statement.
Practical verification: Open the publication dashboard and verify target locale, reviewer and approval before release. Do not equate a successful API response with a publishable page until the real rendered output has been inspected.
11. Understand the Publish in all languages option
The Jahia publication documentation describes a choice that adds workflows for all languages. It does not magically translate each field or substitute for editorial validation. Compare the page under an authenticated editorial session and a private anonymous session. Preview access, workflow state and caches frequently produce different visible outcomes.
A multi-language university homepage has simultaneous layout changes and separate translation review teams. An editor should identify the exact source record and intended audience before changing a language value. Make sure that the surrounding page does not change the scope of the statement.
Bulk publication can accidentally submit incomplete variants if the language owners have not confirmed readiness. If a reader acts on the content, the cost of that mistake is measured in understanding and decisions, not merely visual inconsistency.
Practical verification: Prepare a per-language review matrix and compare it against the requests created by the bulk option. Reproduce the result with caches warmed in the opposite language to expose mis-keyed multilingual delivery.
12. Know what language mixing actually does
Jahia offers replacement of untranslated content with the site’s default language in some configurations. Its documentation advises caution for public sites because mixed-language pages can confuse readers. Keep accessibility and search discoverability within scope. A translation is not complete if assistive technology or a direct incoming link presents a different language from the one promised.
An internal intranet tolerates English snippets within a partly French screen as a temporary, visible fallback. A developer should check the real rendered result as well as the administrative settings. Matching text in a test form is not enough when a route or integration can select a different record.
A public health site silently replacing French instructions with English can create serious misunderstanding and accessibility problems. An error can survive an attractive layout and a successful HTTP response, making it especially important to test the underlying meaning.
Practical verification: Test a deliberately missing French field and label fallback clearly if the public experience will allow it. Include a negative test: deliberately remove one translated field and inspect the visible fallback or error.
13. Understand user-language detection priorities
Jahia documents language choice from explicit URL and user or browser preferences. The team must test explicit links rather than assuming browser settings alone determine delivery. Think about the ownership of the data before thinking about vocabulary. A shared fact should have one identifiable source; a local adaptation should have a named reason. Those are different editorial obligations.
A bilingual subscriber opens a French deep link while their browser is configured for English. An editor should identify the exact source record and intended audience before changing a language value. Make sure that the surrounding page does not change the scope of the statement.
Unexpected redirects can make published citations point to the wrong language or cause users to distrust the site. This is why editorial review and technical testing must be independent: a valid configuration does not guarantee a valid statement.
Practical verification: Test explicit language URLs, logged-in preferences, anonymous preferences and direct deep links independently. Save the expected outcome next to the observed outcome; if they differ, identify the owning team before changing configuration.
14. Plan for unsupported requested languages
By default Jahia may return a 404 for unlisted language routes. An option to permit unlisted languages is documented for specific fallback configurations. Readers do not see the content-management boundaries. They experience a continuous page, so the review must follow the visible journey rather than stopping at the field editor.
A researcher follows an old URL that includes a locale code no longer offered by the site. A developer should check the real rendered result as well as the administrative settings. Matching text in a test form is not enough when a route or integration can select a different record.
Silently interpreting an unknown locale as a valid published translation can hide broken links or misleading metadata. If a reader acts on the content, the cost of that mistake is measured in understanding and decisions, not merely visual inconsistency.
Practical verification: Request a supported, a disabled and an unknown locale and record the actual response and banner. Repeat the experiment after a small source edit to prove that your update policy continues to work when content evolves.
15. Avoid careless language removal
The administration guide says removing an available language is non-destructive in certain conditions but restricts removal when it is default, actively editable or has content. Treat the source statement as a claim that can be checked, not a string that merely needs different spelling. Dates, conditions and scope must survive the move between languages.
A public archive retires a regional language route while preserving historical translations for internal use. An editor should identify the exact source record and intended audience before changing a language value. Make sure that the surrounding page does not change the scope of the statement.
Deleting or disabling language availability without planning redirects may break old citations and bookmarks. An error can survive an attractive layout and a successful HTTP response, making it especially important to test the underlying meaning.
Practical verification: Record live URLs, content ownership and reactivation options before retiring a locale. Use a test item containing a number, an exception and a link, because these expose errors hidden by a friendly one-sentence greeting.
16. Separate internationalized and invariant properties
Language-dependent claims belong in internationalized fields; stable IDs, content provenance and structured measurements should usually remain invariant. Make the test observable: record the requested locale, the actual returned value, the source revision and the public URL. A green status badge without that evidence can mislead.
A heritage site stores an artifact’s inventory number once but translates its exhibition title and context. A developer should check the real rendered result as well as the administrative settings. Matching text in a test form is not enough when a route or integration can select a different record.
Copying the source identifier into each locale creates a risk of divergence after a correction. This is why editorial review and technical testing must be independent: a valid configuration does not guarantee a valid statement.
Practical verification: Change a test invariant value and inspect all language variants to confirm the intended shared behavior. Check the same state on desktop and mobile, then verify that a keyboard user can complete the central task.
17. Translate admin labels separately from public claims
Jahia provides language-specific editing interfaces and content types, but translated editor labels do not mean public page content has been reviewed. Separate configured capability from completed work. The existence of a locale option or a valid response says little about whether the reader has received a reviewed explanation.
An international library has French editor controls while the article body remains in English. An editor should identify the exact source record and intended audience before changing a language value. Make sure that the surrounding page does not change the scope of the statement.
Assuming a French CMS screen proves content localization can allow a misleading launch announcement. If a reader acts on the content, the cost of that mistake is measured in understanding and decisions, not merely visual inconsistency.
Practical verification: Inspect published body text, navigation and form strings on the anonymous URL. Ask a reviewer to explain the target-language claim in their own words before treating the translation as accepted.
18. Build translation context into assignments
A translator should receive source text, intended audience, date, underlying evidence and any legal or cultural limitations. When the sample fails, isolate whether the cause is data modelling, editorial approval, route selection or delivery. Each cause requires a different repair and different owner.
A Spanish translation of an evacuation notice requires a clear distinction between an advisory and a mandatory instruction. A developer should check the real rendered result as well as the administrative settings. Matching text in a test form is not enough when a route or integration can select a different record.
Without context a fluent translation may strengthen or weaken the original obligation. An error can survive an attractive layout and a successful HTTP response, making it especially important to test the underlying meaning.
Practical verification: Attach the source revision and one real use case to each translation request, then ask a reviewer to verify the implication. Confirm what happens to deep links, back navigation and search results rather than testing only the landing page.
19. Preserve the meaning of qualifiers
Words such as may, generally, unless and only are part of the claim, not optional decoration. Translation must preserve uncertainty and conditions. The best model is the simplest one that still expresses genuine regional differences and preserves stable identity. Extra duplication expands the number of revisions a team must reconcile.
A medical history page says a treatment may benefit a subgroup, not that it is universally effective. An editor should identify the exact source record and intended audience before changing a language value. Make sure that the surrounding page does not change the scope of the statement.
Omitting a qualifier changes the evidence and could cause a reader to make a harmful decision. This is why editorial review and technical testing must be independent: a valid configuration does not guarantee a valid statement.
Practical verification: Compare the source and target conditions in a small claim table before approval. Keep a source snapshot so that the team can detect obsolete target wording after an upstream correction.
20. Review right-to-left reading order
Jahia supports multilingual content including right-to-left languages, but page templates, navigation and external widgets still need real-world testing. Assess the consequence to the person using the page. A wrong headline is inconvenient; a wrong deadline, payment rule or medical condition can change a real-world decision.
An Arabic learning portal includes Latin scientific terms, dates and English publisher citations. A developer should check the real rendered result as well as the administrative settings. Matching text in a test form is not enough when a route or integration can select a different record.
A correctly localized rich-text body can be undermined by incorrectly ordered menu labels or mirrored icons. If a reader acts on the content, the cost of that mistake is measured in understanding and decisions, not merely visual inconsistency.
Practical verification: Test keyboard movement, visual order and copy-paste results on mobile and desktop. Use a lower-privilege account for the workflow test and a signed-out browser for the public delivery test.
21. Test a page with mixed content types
A Jahia page may render paragraphs, image components, menus and embedded content from different templates or modules. Each surface needs an owner. Build one reversible experiment before implementing the policy across thousands of records. A small controlled example provides stronger evidence than assumptions based on an admin screen.
A museum page displays one localized rich-text item, a related-events widget and a global footer. An editor should identify the exact source record and intended audience before changing a language value. Make sure that the surrounding page does not change the scope of the statement.
The body may be French while events or consent messages revert to English, producing a fragmented reading experience. An error can survive an attractive layout and a successful HTTP response, making it especially important to test the underlying meaning.
Practical verification: Inventory every visible component and verify its language source on a full page. Test a complete locale, a partial locale and an unsupported locale as distinct input states.
22. Use separate content review and site release
Language reviewers validate wording; subject experts validate facts; site operators validate routes and workflow state. These duties should meet before publication. Record both what is intentionally shared and what is intentionally translated. The distinction helps a future editor understand whether the same visible value is correct or simply unfinished.
A charity’s French donation page needs financial meaning, accessibility and secure form delivery checked by different people. A developer should check the real rendered result as well as the administrative settings. Matching text in a test form is not enough when a route or integration can select a different record.
One reviewer may miss a technical link failure, while an engineer may not notice a changed legal assertion. This is why editorial review and technical testing must be independent: a valid configuration does not guarantee a valid statement.
Practical verification: Require evidence from all three perspectives and keep the decisions attached to the release. Do not equate a successful API response with a publishable page until the real rendered output has been inspected.
23. Understand unpublished versus unavailable language
A language can exist in the repository, be editable and even have published items, yet remain hidden from visitors if Active Live is disabled. Compare the page under an authenticated editorial session and a private anonymous session. Preview access, workflow state and caches frequently produce different visible outcomes.
A German translation team finishes its articles but operations has not activated the live language. An editor should identify the exact source record and intended audience before changing a language value. Make sure that the surrounding page does not change the scope of the statement.
Checking only the content editor may lead to false reports that public URLs are live. If a reader acts on the content, the cost of that mistake is measured in understanding and decisions, not merely visual inconsistency.
Practical verification: Open the route without login and inspect the site language activation status. Reproduce the result with caches warmed in the opposite language to expose mis-keyed multilingual delivery.
24. Keep canonical identity for translated pages
One shared content identity may have several language views. Build switcher and SEO links from actual equivalents, not guessed URLs. Keep accessibility and search discoverability within scope. A translation is not complete if assistive technology or a direct incoming link presents a different language from the one promised.
A German version of an educational article is approved later than its English original. A developer should check the real rendered result as well as the administrative settings. Matching text in a test form is not enough when a route or integration can select a different record.
A generated German alternate link can lead to missing content before the language is live. An error can survive an attractive layout and a successful HTTP response, making it especially important to test the underlying meaning.
Practical verification: Crawl only published equivalents and verify reciprocal links and visible language. Include a negative test: deliberately remove one translated field and inspect the visible fallback or error.
25. Distinguish translation fallback from search indexing
A public page composed partly of default-language content is not necessarily a complete version in the advertised target language. Think about the ownership of the data before thinking about vocabulary. A shared fact should have one identifiable source; a local adaptation should have a named reason. Those are different editorial obligations.
An Arabic route contains an Arabic heading but most supporting text is English fallback. An editor should identify the exact source record and intended audience before changing a language value. Make sure that the surrounding page does not change the scope of the statement.
Search indexing of such pages can overstate coverage and give readers unexpected results. This is why editorial review and technical testing must be independent: a valid configuration does not guarantee a valid statement.
Practical verification: Check the actual rendered text and decide whether incomplete variants should be held back. Save the expected outcome next to the observed outcome; if they differ, identify the owning team before changing configuration.
26. Preserve document and media attribution
Translations of source evidence must retain quotation boundaries, author names, publication dates and licensing notes. Readers do not see the content-management boundaries. They experience a continuous page, so the review must follow the visible journey rather than stopping at the field editor.
A German museum page translates commentary on a historical letter but must preserve the letter’s citation and archival identifier. A developer should check the real rendered result as well as the administrative settings. Matching text in a test form is not enough when a route or integration can select a different record.
Changing a citation in translation makes verification harder even if the surrounding prose reads naturally. If a reader acts on the content, the cost of that mistake is measured in understanding and decisions, not merely visual inconsistency.
Practical verification: Cross-check every reference and original-language quotation with the source record. Repeat the experiment after a small source edit to prove that your update policy continues to work when content evolves.
27. Use test accounts with realistic permissions
An administrator may not encounter the review and language access restrictions faced by an ordinary translator or publisher. Treat the source statement as a claim that can be checked, not a string that merely needs different spelling. Dates, conditions and scope must survive the move between languages.
A French proofreader can edit but not publish; an Arabic editor can see only assigned language material. An editor should identify the exact source record and intended audience before changing a language value. Make sure that the surrounding page does not change the scope of the statement.
Successful admin preview does not prove the real contributor can complete the intended workflow. An error can survive an attractive layout and a successful HTTP response, making it especially important to test the underlying meaning.
Practical verification: Log in as each role in staging and attempt draft, review, publish and rollback actions. Use a test item containing a number, an exception and a link, because these expose errors hidden by a friendly one-sentence greeting.
28. Check published content after source correction
When the source article changes, translated fields do not automatically inherit the newly correct meaning. Re-review is a human responsibility. Make the test observable: record the requested locale, the actual returned value, the source revision and the public URL. A green status badge without that evidence can mislead.
A clinical study summary retracts an overstated claim and its English prose is corrected first. A developer should check the real rendered result as well as the administrative settings. Matching text in a test form is not enough when a route or integration can select a different record.
A still-published Spanish translation can contradict the current source and remain technically valid. This is why editorial review and technical testing must be independent: a valid configuration does not guarantee a valid statement.
Practical verification: Mark affected locales for review and compare revised claims before approving updated publication. Check the same state on desktop and mobile, then verify that a keyboard user can complete the central task.
29. Protect forms and validation messages
Transactional pages mix CMS content with form components and service integrations. Validation messages, privacy text and confirmation actions must match the chosen language. Separate configured capability from completed work. The existence of a locale option or a valid response says little about whether the reader has received a reviewed explanation.
A multilingual public-registration form asks for consent and reports missing required fields. An editor should identify the exact source record and intended audience before changing a language value. Make sure that the surrounding page does not change the scope of the statement.
An English-only error message can prevent a visitor completing a form even when the instructions are translated. If a reader acts on the content, the cost of that mistake is measured in understanding and decisions, not merely visual inconsistency.
Practical verification: Submit incomplete and complete forms in each live locale and inspect every response. Ask a reviewer to explain the target-language claim in their own words before treating the translation as accepted.
30. Verify routing with browser language changes
An explicit language route should remain stable on refresh, sharing, navigation and return from a redirect unless site policy says otherwise. When the sample fails, isolate whether the cause is data modelling, editorial approval, route selection or delivery. Each cause requires a different repair and different owner.
A French user opens a shared Jahia URL in a browser whose first preference is English. A developer should check the real rendered result as well as the administrative settings. Matching text in a test form is not enough when a route or integration can select a different record.
Unplanned fallback and redirects can send the visitor to an unexpected language or an old page. An error can survive an attractive layout and a successful HTTP response, making it especially important to test the underlying meaning.
Practical verification: Test direct routes with altered browser preferences, cookies and signed-out sessions. Confirm what happens to deep links, back navigation and search results rather than testing only the landing page.
31. Set up multilingual navigation labels
Navigation items should present meaningful target-language names and point to real available destinations. Translated text alone is insufficient if links are wrong. The best model is the simplest one that still expresses genuine regional differences and preserves stable identity. Extra duplication expands the number of revisions a team must reconcile.
An Arabic museum menu lists exhibitions, events and visitor services in natural Arabic. An editor should identify the exact source record and intended audience before changing a language value. Make sure that the surrounding page does not change the scope of the statement.
A link to the default-language landing page interrupts the task despite correct menu vocabulary. This is why editorial review and technical testing must be independent: a valid configuration does not guarantee a valid statement.
Practical verification: Click every top-level and child navigation item and confirm the target language and page identity. Keep a source snapshot so that the team can detect obsolete target wording after an upstream correction.
32. Test source and target release timing
Large translations are rarely published at exactly the same instant. The system must represent what is approved and what is still waiting. Assess the consequence to the person using the page. A wrong headline is inconvenient; a wrong deadline, payment rule or medical condition can change a real-world decision.
A French notice goes live Wednesday while Arabic edits await factual review until Friday. A developer should check the real rendered result as well as the administrative settings. Matching text in a test form is not enough when a route or integration can select a different record.
Assuming simultaneous updates can make the language switcher promise an equivalent page that is not ready. If a reader acts on the content, the cost of that mistake is measured in understanding and decisions, not merely visual inconsistency.
Practical verification: Record release dates by locale and present only approved cross-language alternatives. Use a lower-privilege account for the workflow test and a signed-out browser for the public delivery test.
33. Use quality checks beyond grammatical accuracy
A readable translation may still contain wrong dates, quantities, conditions or destinations. The test is whether the reader can make the same justified decision. Build one reversible experiment before implementing the policy across thousands of records. A small controlled example provides stronger evidence than assumptions based on an admin screen.
A multilingual events page includes a booking deadline expressed in local time. An editor should identify the exact source record and intended audience before changing a language value. Make sure that the surrounding page does not change the scope of the statement.
A translator accurately rewrites the words but changes the date format ambiguously, creating missed attendance. An error can survive an attractive layout and a successful HTTP response, making it especially important to test the underlying meaning.
Practical verification: Have a reviewer trace numbers, time zones, action verbs and destination links. Test a complete locale, a partial locale and an unsupported locale as distinct input states.
34. Run an authenticated and anonymous comparison
Editors often see draft content in their preferred locale while anonymous visitors see older published material or a fallback language. Record both what is intentionally shared and what is intentionally translated. The distinction helps a future editor understand whether the same visible value is correct or simply unfinished.
An administrator’s German preview looks correct but the public URL still returns English content. A developer should check the real rendered result as well as the administrative settings. Matching text in a test form is not enough when a route or integration can select a different record.
Only checking logged-in views can conceal site availability, workflow and cache differences. This is why editorial review and technical testing must be independent: a valid configuration does not guarantee a valid statement.
Practical verification: Use a clean browser to compare actual public text with the accepted preview. Do not equate a successful API response with a publishable page until the real rendered output has been inspected.
35. Handle caching by actual language context
A CDN or application cache must not reuse an English representation for a request to a French URL or vice versa. Compare the page under an authenticated editorial session and a private anonymous session. Preview access, workflow state and caches frequently produce different visible outcomes.
A Jahia public-site cache is warmed in English before the first French visitors arrive. An editor should identify the exact source record and intended audience before changing a language value. Make sure that the surrounding page does not change the scope of the statement.
Wrong cache variation can make language failures intermittent and difficult to reproduce. If a reader acts on the content, the cost of that mistake is measured in understanding and decisions, not merely visual inconsistency.
Practical verification: Alternate requests by language and compare response body, URL, cookies and cache headers. Reproduce the result with caches warmed in the opposite language to expose mis-keyed multilingual delivery.
36. Keep a change log for language policy
Language availability, mandatory requirements and fallback settings affect publishing behavior and should be treated like release configuration. Keep accessibility and search discoverability within scope. A translation is not complete if assistive technology or a direct incoming link presents a different language from the one promised.
A university changes German from optional to mandatory before a major admissions announcement. A developer should check the real rendered result as well as the administrative settings. Matching text in a test form is not enough when a route or integration can select a different record.
Without recorded policy changes editors may suddenly be unable to publish otherwise valid content. An error can survive an attractive layout and a successful HTTP response, making it especially important to test the underlying meaning.
Practical verification: Log the reason, date, affected content types and rollback plan for every language-policy change. Include a negative test: deliberately remove one translated field and inspect the visible fallback or error.
37. Re-test after a template or module update
A Jahia CMS upgrade or template change may alter navigation, label rendering or language selection without changing the underlying article text. Think about the ownership of the data before thinking about vocabulary. A shared fact should have one identifiable source; a local adaptation should have a named reason. Those are different editorial obligations.
A charity releases a new footer component that unintentionally forces English donation labels onto French pages. An editor should identify the exact source record and intended audience before changing a language value. Make sure that the surrounding page does not change the scope of the statement.
Text-level translation checks remain green while the complete page becomes partly unusable. This is why editorial review and technical testing must be independent: a valid configuration does not guarantee a valid statement.
Practical verification: Include cross-language template, mobile and accessibility checks in every material site release. Save the expected outcome next to the observed outcome; if they differ, identify the owning team before changing configuration.
38. Develop a target-language reader acceptance test
Ask a representative reader to complete a task, not merely to identify whether a page appears translated. Readers do not see the content-management boundaries. They experience a continuous page, so the review must follow the visible journey rather than stopping at the field editor.
A Spanish-speaking visitor must find eligibility information, understand the exception and reach the correct registration form. A developer should check the real rendered result as well as the administrative settings. Matching text in a test form is not enough when a route or integration can select a different record.
A flawless title and attractive layout cannot compensate for an ambiguous condition or broken action link. If a reader acts on the content, the cost of that mistake is measured in understanding and decisions, not merely visual inconsistency.
Practical verification: Observe the task, document confusion and revise the responsible wording or route. Repeat the experiment after a small source edit to prove that your update policy continues to work when content evolves.
39. Maintain evidence for long-term revisions
A translation launch creates continuing obligations whenever the source, law, linked content or site structure changes. Treat the source statement as a claim that can be checked, not a string that merely needs different spelling. Dates, conditions and scope must survive the move between languages.
An English environmental guide updates its evidence months after the German version was last reviewed. An editor should identify the exact source record and intended audience before changing a language value. Make sure that the surrounding page does not change the scope of the statement.
Without a source-to-locale trail, the organisation cannot know which public assertions need rechecking. An error can survive an attractive layout and a successful HTTP response, making it especially important to test the underlying meaning.
Practical verification: Keep an inventory of source revisions, reviewed target locales, release URLs and accountable owners. Use a test item containing a number, an exception and a link, because these expose errors hidden by a friendly one-sentence greeting.
A two-language release exercise you can reproduce
First select an ordinary content record whose source meaning can be verified. Give it a date, a numerical fact, a conditional sentence, an image with an explanation and one important internal link. The items are deliberately varied: a simple greeting is not a useful stress test. Assign a source revision, a target locale and a reviewer before anyone starts typing.
Next create one complete translated version and one deliberately incomplete variant in a test environment. Retrieve the result through the path the public website actually uses. Compare missing values and fallback behavior, then record whether the system returns nothing, a default-language value, a draft or an explicitly labelled alternative. Decide in advance which of these outcomes readers may safely receive.
Now change the source condition in a harmless way—for example, change “registration closes on Friday” to “registration closes on Thursday” in a test article. The important observation is not whether the translated page still renders. It is whether the team can identify every language version that may now state an old deadline and prevent that statement from being presented as current.
Finally complete a reader journey: arrive from an external link, switch language, search for another item, inspect an image, open a form, trigger an error and return by browser history. Test with the relevant locale configuration and without an editor login. Record any place where the page silently changes language, loses its identity, shows an older claim or fails accessibility. Only then is the translated experience meaningfully tested.
Troubleshooting: symptoms and likely causes
- The page exists but the visitor sees the source language: Inspect the public locale route, the actual content API request, the selected field or entry language and the approved release state.
- The title is translated but the body is not: Check field-level or item-level coverage rather than assuming a language indicator refers to a complete page.
- A link sends users to the wrong country: Separate market-specific destination policy from translation and review the target site’s authority and applicability.
- An editor sees new copy but the public still sees old copy: Compare preview and public queries, publication workflow, deployed frontend data and cache invalidation.
- One language appears after another was requested: Inspect the language selector, browser preferences, cache variation and explicit URL routing priorities.
- A page has translated prose but English controls: Inventory application dictionaries, templates, plugins, form validation and external widgets separately from CMS text.
- A translated page disappears from search: Verify public release, indexable status, canonical target, locale path, sitemap and the actual indexed language.
- Translators keep correcting the same phrase: Add source context and approved terminology, and record whether the old wording is being reintroduced from a stale source version.
- Numbers or dates disagree across languages: Compare underlying data, formatting, time zones and source corrections before blaming linguistic wording.
- Mobile users cannot select a language: Test focus order, accessible labels, responsive layout and non-pointer controls on the final frontend.
- A translation is approved but its image still reads in English: Review embedded text in the image, alt text, captions and any locale-specific media references.
- The team cannot tell which version is current: Preserve source revision, translator review, factual approval, locale status and public URL as separate fields of evidence.
Frequently asked questions
Does adding a locale mean the website is translated?
No. A locale setting may create a place for a value or enable a route. It does not create reviewed content, translate every widget or establish that readers can complete a task.
Should missing translations fall back to the source language?
That depends on audience and risk. A transparent fallback can be useful in an internal reference tool, but a public instruction, law or safety notice may need to be withheld until approved.
Can machine translation be used in the first draft?
It can assist a defined workflow, but the output still needs review for terms, conditions, numerical facts, cultural context, links and the intended reader’s actions.
How should we measure completion?
Count meaningful reader-facing surfaces and approved actions, not just words or records. Include media, metadata, search, forms, language routing and direct public delivery.
What happens after the source is revised?
Identify every target affected by the changed assertion, compare old and new meanings, re-review the necessary translations and verify the updated public result.
Does a successful preview prove that the page is live?
No. Preview often has different permissions, content states or caching. Test the production route while signed out and confirm the exact language and source revision.
Can we use one language version for several countries?
Often yes for universal information, provided market-specific rules, units, addresses and services are separately modelled and presented accurately.
What is the most important acceptance test?
Ask someone in the target audience to follow a real task from entry link to final action, then compare their understanding with the source’s intended meaning.
Official documentation and version notes
The following product documentation is the primary starting point. Features, supported versions and administrative controls change. Check the release that your organization actually uses before copying configuration or API examples into production.
- Jahia 8.2 official documentation 1
- Jahia 8.2 official documentation 2
- Jahia 8.2 official documentation 3
Continue through eduKate’s translation library
The broader Master Art of Translation explains why preserving claims, evidence and intended action matters across languages. The Translate Like a Pro series index links implementation guides across tools and systems. This chapter’s own focus is Jahia multilingual sites, internationalized content properties, language activation and publication workflows, so it complements rather than replaces those general guides.
The strongest multilingual implementation is not the one with the most enabled languages. It is the one that can explain exactly what a reader is seeing, where the information came from, who checked it and what happens after it changes. Start with one reliable journey, verify it from the outside, then extend that quality to every page and language you choose to publish.