How do you translate a Plone 6 website and its Volto frontend while preserving linked content translations, language folders, shared assets and accessible navigation? This Plone multilingual localization guide explains plone.app.multilingual, language configuration, Dexterity content types, translation groups, Volto language switching, site search and international SEO quality assurance. It is designed for international institutions, public-interest websites and professional editors who need reliable translated information that readers can actually use.
Plone distinguishes translated user-generated content from translated interface messages. Its multilingual add-on can organize language-specific content under language roots and link corresponding items; Volto provides frontend language-aware navigation according to its version and configuration. These tools create a structure for multilingual publishing, not a guarantee that an article is factually translated or that a download, form or external service is available in the visitor’s language.
The dependable way to localize Plone is to configure languages, audit content types, translate one complete reader journey, preserve translation links and inspect the live frontend in every supported locale. This guide walks through those decisions, explains where shared assets and language-independent fields belong, and provides editorial checks for accurate public-service communication, accessibility, metadata and ongoing maintenance.
Quick summary
- Enable Plone multilingual features and align Volto with the installed backend version.
- Maintain language-root folders and correctly linked content translations.
- Audit Dexterity custom types, shared fields and language-independent assets.
- Test Volto blocks, navigation, forms, search, documents and accessibility.
- Publish only reviewed, meaningful international editions with truthful URLs and SEO metadata.
The running example is a fictional international research library publishing collection descriptions, student workshops, accessible-visit information and registration forms in English, French and Spanish. Some resources and catalog identifiers must remain shared; other facts are region-specific or need new translated documents. The example shows how a language-aware content structure can support, but never replace, careful editorial verification.
1. Begin with the reader’s purpose
A public library, university or heritage institution may use Plone to reach people across several languages. Before configuring a new locale, identify what users need to understand, find or complete. A language list is not a substitute for a working service journey.
Choose a pilot route from the homepage through a topic page and into a real task, such as registering for a workshop or reading accessibility guidance. Record source-language ownership and which facts vary by country, organisation or service area.
Readers may reasonably assume that a translated page means the institution can support them in that language. Do not translate a booking promise or support telephone claim without checking whether the underlying service actually meets it.
Ask someone unfamiliar with the site to perform the task in the proposed target language. Their points of confusion will reveal missing links, incomplete documents and technical assumptions that a paragraph-only translation review would miss.
2. Distinguish content translations from interface translations
Plone’s multilingual content workflow concerns authored objects such as pages, news items and custom records. Interface translation concerns buttons, menu controls, errors and application messages. Both appear in one experience, but they have different technical owners and release cycles.
Create a string inventory spanning content bodies, Volto blocks, CMS labels, login forms, search states, emails, notifications and external integrations. Assign responsibility for each layer and determine whether source strings are stored in records, localization resources or another service.
A French article can sit beneath a menu whose search box remains English. Conversely, a translated interface may open an English-only PDF. Those failures require different corrections, and neither proves that the content writer did a poor job.
Check the public pilot page as a visitor and note the origin of every visible string. This produces an actionable repair map instead of an unspecific request to ‘translate the whole website’.
3. Understand plone.app.multilingual
Plone 6 documentation describes plone.app.multilingual as the core add-on for translating user-generated content. The add-on is installed with the platform, but multilingual use must be activated and configured for the site. It does not automatically supply translated prose.
Review the site’s enabled add-ons and Languages control panel. Enable only the languages the organisation can maintain, and document their codes, naming conventions, content ownership and expected public URL patterns before generating language roots.
Confusing availability with completion causes overpromising. A newly configured Spanish language folder may be almost empty while the interface offers Spanish as though it were a fully supported edition. Editorial readiness and technical enablement should be tracked separately.
After configuration, create one simple page and its linked translation. Inspect the backend’s language relationship and the frontend’s actual URL, language indicator and navigation behaviour.
4. Recognize language-root folders
Plone’s documented multilingual setup creates language-specific root folders. This gives visitors and editors a recognisable content hierarchy while separating versions that are authored for different languages. The hierarchy matters for navigation, breadcrumbs and local content discovery.
Draw the intended tree for each language. Include the home or landing page, high-traffic sections, policy information, forms and contact details. Keep the purpose of corresponding sections comparable, but allow real regional differences when editorial evidence supports them.
Translating an isolated article into a language root without its surrounding navigation can create a dead end. A visitor may read the article but struggle to find the next action or return to a meaningful section.
Open the root folder and follow a representative path in both source and target languages. Confirm the folder tree and public breadcrumbs describe the same coherent reader journey.
5. Use content-translation links rather than matching titles
Plone’s translation mechanism relates content objects as versions of one conceptual item. The relationship helps the language switcher reach the corresponding page. Identical titles or slugs do not substitute for a properly linked translation group.
Use the documented content translation interface to create or link target items. Record source identity, target object, reviewer and current revision. When linking two existing items, verify they truly represent the same subject and reader purpose.
A French article called ‘Visitor information’ might describe a different venue from an English article with the same title. Connecting them as translations would mislead users despite the superficially plausible match.
Switch languages from a deep article and confirm the destination is the actual equivalent item. Then switch back. Test this again after renaming one page, because a robust relationship should not depend only on displayed words.
6. Decide when to create a translation versus link an existing item
A new target item is appropriate when the translation does not yet exist. Linking is appropriate when an independently authored target-language object already represents the same information. The two choices have different editorial risks.
Before linking, compare intended audience, factual scope, source revision, dates and related resources. Document any local additions that are legitimate differences rather than inconsistencies. Avoid merging unrelated content merely to make the language selector look complete.
A previously published Spanish guide may include local regulations not found in the English source. It might still be a valid translation family, but only after the team agrees what information is common and what must remain region-specific.
Test the linked object’s language switcher, breadcrumbs, canonical metadata and links. A plausible relationship in the CMS must also produce an honest public destination.
7. Configure the correct languages in the backend
Plone’s Languages control panel is a central configuration point for supported languages and the default language. Volto’s behavior depends on its version and backend configuration, so frontend and backend decisions must be aligned.
Write a language register containing visible names, codes, default language, source editorial team, launch status and target content owner. Validate locale identifiers with the developers responsible for routing, translation messages and external integrations.
Do not add country-specific codes as a substitute for meaningful regional adaptation. Two nominally distinct locales containing duplicate content and no maintenance plan can confuse editors, visitors and search engines.
Request a public URL in each configured language, then inspect the page heading, language selector, breadcrumb and intended next step. Report any mismatch between the CMS language and the frontend’s displayed language.
8. Account for Volto 19 and later configuration differences
Official Plone documentation explains that Volto 19 and later take the supported languages and default language from the Plone site’s backend configuration. Older Volto releases used frontend configuration settings. Mixing those instructions can produce avoidable errors.
Identify the actual Volto version before applying an internet tutorial. Use the documented approach for that release, and verify what the frontend reads from Plone. Treat old configuration snippets as historical examples rather than universal advice.
A team may change a deprecated frontend setting and expect the language selector to update, while the current frontend continues to follow the backend. This is not evidence that translation data is corrupt; it may simply be a version mismatch.
Check the installed version and run a small configuration test. Confirm the list of available languages, default-language selection and redirect behavior through actual public requests.
9. Understand how the language switcher chooses destinations
Volto can switch between linked translations when it knows the relationship. A language switcher should preserve the reader’s topic where an equivalent page exists and make missing translations understandable rather than sending visitors to arbitrary pages.
Test switching from a homepage, a nested article, a news item and a page not yet translated. Agree whether missing destinations should lead to a language root, a clearly labeled source-language page or another transparent fallback.
A switcher that replaces only the URL prefix can be wrong when translated content has different structure or slugs. A switcher that always returns home may make users lose the context of the page they were reading.
Follow the switcher in both directions, observe the destination title and subject, and record the actual target URL. Fix translation-group relationships or routing instead of disguising the failure with misleading labels.
10. Make Dexterity content types translatable intentionally
Plone uses Dexterity content types for many structured records. Custom content does not become fully translatable merely because the site supports multiple languages. The content type must have the appropriate multilingual behavior or configuration.
Inventory custom types such as course records, staff profiles, public notices and events. Confirm which are marked as translatable through the available schema, control-panel or file-system mechanism. Test representative objects instead of assuming the default page behavior applies everywhere.
A custom workshop entry may be omitted from a target language even while regular pages work. Without a content-type audit, the translation team may try to copy its visible text into unrelated pages rather than fixing the model.
Create one test object of each high-impact custom type and attempt a proper translated counterpart. Verify relations, fields, language assignment and frontend rendering before expanding to hundreds of records.
11. Treat language-independent fields carefully
Some structured fields identify the same real-world object in every language: an internal event code, persistent identifier or media reference. Plone documentation describes language-independent fields for cases where a value should not be translated as separate prose.
Classify every custom field as translated text, shared identity, region-specific data or derived value. Record why the classification exists, and test that editors cannot accidentally change stable identifiers when composing a target-language description.
A registration system may depend on the event ID remaining constant even when public event titles differ. Translating the ID as though it were a sentence could break booking records; leaving the public description in English would be a different failure.
Inspect the source and target objects after a controlled edit. Verify which fields are shared and which vary, and confirm the downstream service still resolves the intended real-world item.
12. Use language-independent assets with editorial judgment
Plone can create language-independent folders for shared assets such as files or images. This can reduce unnecessary duplication when the exact resource genuinely serves all audiences, but an asset’s existence in a common folder does not guarantee that its contents are understandable.
Maintain an asset register with language, purpose, permissions and update owner. Share photographs and nonlinguistic diagrams where appropriate; provide translated alternatives for documents or graphics containing essential words.
A scientific image may have labels that require translation even if the photograph itself is universal. A safety PDF in the English asset folder should not be linked from a Spanish page as though it were Spanish documentation.
Open representative downloads from each target-language page and inspect the actual language of the file, its title, accessibility tags and important instructions. Label source-language resources honestly when no approved translation exists.
13. Translate Volto blocks as structured content
Volto editors can assemble pages from blocks with headings, body text, cards, links, images and other structured components. Each block may contain reader-facing language as well as data or configuration that should remain intact.
Create a field-level guide for custom blocks. Translate visible text and accessible descriptions, preserve identifiers and relationships, and verify that nested components remain supported after duplication or translation. Include image cards and calls to action in the pilot.
A copied card may point to the English event registration page even after its heading becomes French. Another block may store essential text in a field the translator did not see. Neither problem is solved by proofreading the headline.
Review the block editor and public rendering together. Check every link and action, then test mobile layout, keyboard focus and alternative text with the target-language wording.
14. Preserve internal linking and reference integrity
Plone content can link to related pages, images, documents and other objects. Translation requires preserving the intended destination, not merely converting the words around the link. A reader needs the right next step.
Map the source content’s important links and their target equivalents. When a translation exists, point to it through a dependable content relationship; when it does not, choose a transparent fallback and avoid inventing a nonexistent destination.
A target-language application page can accidentally lead back to a source-language consent notice. This may be unacceptable even when the surrounding explanatory text is well translated.
Click every pilot navigation item, linked card, policy citation and action button. Record the destination’s URL, language, subject and availability. Diagnose broken relationships in the content model rather than replacing URLs blindly.
15. Localize navigation, breadcrumbs and site structure
A visitor experiences the site as a journey through menus, breadcrumbs, search results and topic sections. These may come from language folders, content objects and frontend components with different translation owners.
Audit main menus, footers, related sections and mobile navigation per language. Use natural target-language labels that correspond to real destinations. Maintain clear rules for sections that exist only in one region.
A site can display a fully translated article yet have an English breadcrumb or an empty menu item because the corresponding language root is incomplete. Those defects make the information harder to find and trust.
Start from the public homepage and reach the pilot article without a direct URL. Return to its parent, then use the language switcher and repeat. If the route fails, fix the content hierarchy or menu configuration before launch.
16. Consider language detection without overriding choice
A multilingual website may detect browser preferences or use cookies to choose a starting language. This can be convenient, but a reader’s deliberate choice of a stable language URL should normally remain effective.
Document how initial language selection works and whether it uses cookies, paths or other preferences. Test ordinary browsers, private sessions and direct links. Avoid assuming that device language reveals a visitor’s citizenship or preferred service location.
An aggressive redirect can trap a bilingual visitor in a language they did not request or make deep URLs difficult for search engines and reviewers to inspect. Language preference and content identity should remain distinct.
Open a French deep link from a browser configured for English and verify that it remains accessible. Change language explicitly, reload and test navigation again. Record expected behavior for each common entry route.
17. Translate forms and confirmation flows end to end
Forms and transactional services often live partly outside a page’s rich text. They include field labels, error messages, consent statements, validation instructions, success screens and email notifications, all of which can affect reader comprehension.
Create a form-translation inventory and assign ownership to the responsible Plone, Volto or external service component. Ask legal or domain experts to review high-consequence terms and preserve variable placeholders where messages are generated dynamically.
A translation can appear complete until the reader submits an invalid phone number and receives an untranslated error. More serious problems occur when a multilingual registration flow presents conditions in a different language or sends inaccurate confirmation terms.
Submit test records in each target locale, including invalid cases. Inspect displayed messages, confirmation emails, relevant attached documents and accessibility labels. Use fictional data rather than real visitor details.
18. Ensure multilingual search works for actual users
An article may exist under the correct language folder but remain hard to discover through internal site search. Search indexing, result filtering and tokenization may depend on the Plone and Volto implementation and installed add-ons.
Prepare a small target-language search list including common terms, synonyms, compound words and proper names. Confirm that results are relevant, current and in the language the reader chose rather than relying solely on translated navigation.
Searching for a French term and receiving only English results can make a functioning translated archive effectively invisible. The defect may sit in indexing scope or query handling rather than in the translation itself.
Run searches from the target-language homepage and record expected pages. Inspect result titles, snippets, links and whether draft or restricted content leaks into public results.
19. Plan translated slugs and stable public URLs
Localized page titles and public paths serve different purposes. Titles help readers understand content; URLs preserve addressability for bookmarks, partner links and search crawlers. A translation project should decide whether slugs change between languages and how old paths are preserved.
Make a route table containing the source URL, target URL, language, content identity and redirect rules. Translate slugs only when the platform configuration and maintenance workflow support them reliably. Avoid broad rewrites of established addresses.
Renaming a page for editorial clarity may make an old link fail if the redirect policy is ignored. A naive prefix replacement may lead to the wrong content object when language folder structures differ.
Request source, target and older public URLs, checking response codes and final destinations. Inspect breadcrumbs, language switching and search metadata on the resolved page.
20. Use canonical and alternate-language metadata honestly
International search discovery depends on stable, indexable pages and truthful relationships. If a page has an equivalent reviewed translation, relevant alternate-language annotations may help search engines understand the connection. They should not be attached to unrelated pages as decoration.
Coordinate canonical and hreflang generation with the site’s SEO templates, Plone settings and deployment implementation. Test the rendered HTML and sitemap output rather than assuming a translated item automatically produces correct search metadata.
A Spanish landing page that only repeats an English headline should not be declared a full Spanish equivalent of a detailed service guide. Likewise, a fallback to an English homepage is not an equivalent of a specific French article.
Choose three states—complete, partial and absent translation—and inspect whether the metadata represents those states accurately. Check reciprocal URLs, indexability, language codes and public response status.
21. Review accessibility and inclusive language
Translation can change text length, screen-reader pronunciation, interface layout and the meaning of images. A public institution must consider accessible language use as part of translation quality, not as an afterthought.
Review headings, alternative text, labels, focus order, keyboard interaction, language attributes, contrast, text expansion and downloadable document accessibility. Include assistive-technology users in testing where practical and treat script directionality as a separate requirement when relevant.
A translated button can wrap over another control, while a public document can remain untagged or in the source language. A page that is linguistically clear but operationally inaccessible still fails the reader.
Test the pilot journey on desktop and mobile, with zoom and a screen reader. Record defects with the precise locale, URL and component, then correct the source of the problem.
22. Manage source revisions and translation status
Public information changes after it is published. An annual report receives corrections, an office changes its address and a policy gains a new deadline. Each source change can affect several translated items with different editorial review states.
Create a revision register containing source content identity, change summary, affected languages, urgency, reviewer and target publication status. Separate factual updates from stylistic adjustments so urgent changes are not hidden in routine editorial noise.
A correction to a safety instruction should reach all relevant locales promptly. A minor rephrasing of an introductory sentence can be reviewed later. Treating both as equally urgent can exhaust translators and make the whole workflow less dependable.
Change a pilot source item and ask the target-language editor to describe what needs review. If the team cannot identify the change and associated translations, improve tracking before scaling the project.
23. Establish permissions and release sign-off
Different teams may need different permissions to create, translate, review or publish items. A multilingual content model becomes difficult to maintain if anyone can publish sensitive target-language advice without the relevant language or subject expertise.
Write down roles for authoring, local review, technical verification, publication and emergency rollback. Make sure the responsible editors can access the translated content and documents but cannot accidentally change unrelated sitewide settings.
An editor who only needs to correct a French event description should not have to modify global routing. Conversely, a shared asset change can affect multiple languages and should not bypass cross-language review.
Simulate a normal translation request and an urgent factual correction. Check who can approve each action, what evidence is retained and how the target-language public page is checked after publication.
24. Release a complete reader journey rather than a page count
A successful multilingual Plone release is measured by comprehension and task completion. The number of translated objects is less important than whether the target-language visitor can find accurate information, follow relevant links and finish the intended action.
Before launch, inspect language folders, translation groups, Volto navigation, custom types, shared assets, forms, downloads, public search and SEO metadata. Record the approved source revision, reviewer and date for every essential target page.
Do not present a language switcher as proof that all material is available. If a crucial policy document or action remains untranslated, publish an honest availability note or hold the affected target journey until it is ready.
Recheck the complete public route after deployment and whenever an important source item changes. Keep the QA register small enough that editors can use it repeatedly instead of treating it as a one-time launch document.
Worked example: launch the library’s French visitor guide
The library begins with a narrow, complete English journey: home, visitor information, accessible entry, workshop registration and confirmation. The team identifies which objects are ordinary Plone pages, which are custom Dexterity event records and which images or PDFs live in shared asset folders. Its source inventory records the authoritative address and workshop dates. A separate editor verifies whether telephone support and physical access details are suitable for the French-language audience.
The Plone administrator enables the supported languages in the backend. The team checks that the language roots and Volto frontend agree, especially where the frontend version changes which configuration source is used. The English visitor page receives a French counterpart through the proper translation workflow. Instead of guessing the URL, editors verify that the items belong to the same translation group and that the language switcher reaches the real equivalent.
An accessible-visit diagram is shared between languages because it contains no embedded words. Its alternative description is reviewed in French. The registration PDF cannot be shared without qualification because it contains English-only instructions. The team either prepares a verified target-language form or labels the existing resource clearly. A French event card is linked to the correct target-language registration destination, and the custom event record’s shared ID remains intact.
In the final test, a French-speaking reviewer opens the public homepage, finds the visitor guide through navigation, changes language from a deep page, checks the linked resource and submits a harmless registration test. The team inspects error messages and the confirmation email. It also reviews canonical and alternate-language URLs to ensure public equivalences are real. The successful result is not simply a translated page but a journey the intended visitor can complete confidently.
Practical troubleshooting cases
Language selector shows a locale with little actual content
Separate technical availability from editorial launch readiness. Verify the language folder and translated page coverage before claiming a complete public edition. Start with a reproducible public URL, a known source revision and the relevant content object. Compare the backend record with what an ordinary visitor sees. Correct the owning layer, repeat the failing task and retain a brief note so the same defect can be detected in the next release.
The switcher sends readers to an unrelated page
Inspect translation-group links and the target item’s identity. Matching titles or guessed URL prefixes do not guarantee correct relationships. Start with a reproducible public URL, a known source revision and the relevant content object. Compare the backend record with what an ordinary visitor sees. Correct the owning layer, repeat the failing task and retain a brief note so the same defect can be detected in the next release.
A custom content type cannot be translated
Check whether its Dexterity schema has the appropriate multilingual behavior and whether its fields require translation, sharing or independent local values. Start with a reproducible public URL, a known source revision and the relevant content object. Compare the backend record with what an ordinary visitor sees. Correct the owning layer, repeat the failing task and retain a brief note so the same defect can be detected in the next release.
A translated page links to an English-only PDF
Review the asset independently of page content. Provide a genuine translated file where needed or explicitly identify the document’s actual language. Start with a reproducible public URL, a known source revision and the relevant content object. Compare the backend record with what an ordinary visitor sees. Correct the owning layer, repeat the failing task and retain a brief note so the same defect can be detected in the next release.
Volto language settings appear to be ignored
Check the installed Volto version and whether the frontend reads supported languages from Plone’s backend configuration rather than older frontend settings. Start with a reproducible public URL, a known source revision and the relevant content object. Compare the backend record with what an ordinary visitor sees. Correct the owning layer, repeat the failing task and retain a brief note so the same defect can be detected in the next release.
Four-week implementation plan
Week one: investigate audiences, source ownership, backend and Volto versions, language folders, custom types and public user journeys. Select a pilot with a page, shared asset, translated custom record and form. Record current URLs, information sources and the language policy before changing configuration.
Week two: configure supported languages, check backend/frontend alignment, and create properly linked translated content. Mark custom fields and shared assets according to documented ownership. Test content navigation and language switching, including cases where an equivalent translation does not exist.
Week three: translate and review user-facing prose, blocks, metadata, downloads, form text and confirmation messages. Ask fluent readers and subject specialists to verify content. Inspect accessibility, mobile layout, public search and internal links as complete tasks rather than isolated strings.
Week four: test public URLs, redirects, canonical and alternate-language links, sitemap output, permissions and release ownership. Publish the verified pilot, record approval and establish a procedure for urgent source changes. Expand only when the same workflow can support additional sections without inventing language coverage.
Frequently asked questions
Does Plone translate articles when I enable multilingual support?
No. The multilingual add-on creates a content framework and translation relationships. Real target-language text still needs to be authored and reviewed.
What is plone.app.multilingual?
It is Plone’s core add-on for organizing and linking multilingual user-generated content. Its setup and use are documented in Plone 6.
Why are there separate language folders?
They help organize content by language and support navigation and editorial structure. Each folder still needs complete, maintained content.
Do Volto 19 and later versions use the same language settings as older Volto?
No. The Plone 6 documentation describes backend-driven language configuration in newer Volto versions, while older versions used frontend settings.
Can two existing pages be linked as translations?
Yes, when they truly represent corresponding content and the supported workflow allows the link. Review their factual scope before connecting them.
Should every image be duplicated by language?
No. Genuine shared assets can remain common, but word-bearing graphics and essential documents may require translated alternatives.
Will a translated article automatically translate a linked form?
Not necessarily. Forms, error messages and confirmation emails may be managed by other components and require separate testing.
What is the best release test?
Ask a target-language reader to enter through the public homepage and complete an important action, verifying facts, navigation, resources and confirmation.
Official documentation and connected learning
Follow the documentation for the actual Plone and Volto versions deployed. In particular, do not mix old frontend language-setting examples with newer backend-driven configuration. A reliable release is the combined result of correct content relationships, truthful translation and tested public behaviour.
Plone 6 — Volto multilingual configuration