How do you translate a Wagtail CMS website without losing page relationships, breaking language-specific navigation or publishing an attractive but inaccurate second-language site? This practical Wagtail multilingual localization guide explains locale configuration, translated page trees, Wagtail Localize, snippets, StreamField content, language switching, search visibility and publication quality assurance. It is written for international editors, translators and developers who need dependable multilingual content, not merely a translated headline.
Wagtail is built on Django and treats translations as separate content objects linked by translation identity. A French page can have its own publication state and URL, while a shared translation key connects it to the corresponding English page. Wagtail Localize adds editorial translation management and synchronization capabilities; it does not remove the need for human decisions about terminology, local facts, accessibility, links and user journeys. That distinction is the foundation of a reliable Wagtail translation workflow.
The fastest responsible path is to select a small complete reader journey, establish which locale owns each fact, configure translation relationships, translate structured content and test everything through the public site. The step-by-step lessons below address Wagtail internationalisation and Wagtail Localize together while distinguishing core features from optional packages. They also provide a concrete quality checklist for multilingual SEO, editorial handover and safe future updates.
Quick summary
- Wagtail’s locale-specific page trees need complete navigation and translated homepages.
- Core internationalisation, simple translation and Wagtail Localize are different layers.
- Translation identity, snippets and StreamField require structural checks as well as language checks.
- Review metadata, language switching, documents, forms and public URLs.
- Release each target-language journey only when its facts and actions have been verified.
Throughout the guide, imagine a fictional international museum with English and French exhibitions, guided-tour reservations, research notes and shared collection records. The example shows why a translation project must preserve meaning, user navigation and practical accuracy without pretending that every language edition has the same local services.
1. Choose the audience before choosing locale codes
Begin with the people who will use the translated website. A visitor searching for an exhibition in French may live in France, Belgium, Canada or Senegal; their language alone cannot determine the opening hours or ticket conditions that apply to them. Record the countries, accessibility requirements and actions the site must support.
Create a compact audience matrix with language, region, intended journey and responsible reviewer. Separate information that is genuinely shared from content requiring local confirmation, such as prices, transport, booking contacts and legal notices. This stops a translated page from making a service promise the original organisation cannot meet.
Do not create separate country editions merely because a language code exists. Each additional locale creates a maintenance obligation, and apparently identical pages can become contradictory when one price or policy changes. Prefer fewer verified versions to a catalogue of attractive but unreviewed copies.
Test the strategy using a reader who follows the homepage, finds the relevant exhibit, checks accessibility and buys a ticket. If any required step is missing in the target language, the translation project is not yet ready to claim a complete language journey.
2. Understand what Django translates and what Wagtail translates
Django internationalisation commonly handles interface messages such as form labels and validation strings. Wagtail internationalisation manages authored content objects and their relationships. These layers often appear together on one screen, but their source files, review procedures and publication states are not the same.
Inventory user-facing messages in templates, Python code, custom components, Wagtail pages, snippets, error pages, emails and third-party services. Give each item an owner rather than assuming that translating a page automatically changes every button displayed within it.
A translated ticket page can still show an English checkout warning if that warning belongs to a Django message catalogue or an external payment service. Conversely, a fully translated interface can display an untranslated article body. Treat those as different classes of failure.
Open the pilot site as an ordinary visitor, without administrator permissions, and trace each string to the layer that produces it. Record whether the fix belongs in a content editor, a message catalogue, a snippet or another integrated application.
3. Configure languages with a stable editorial policy
Wagtail’s internationalisation settings determine which content languages are available. Language identifiers should represent real editorial choices, and the project needs consistent use of identifiers in its Wagtail configuration, Django environment, domain setup and public URL plan.
Document the source locale, supported target locales, editorial owners, launch criteria and retirement policy. If a project needs both French for France and French for Canada, define the actual vocabulary and factual differences before creating both versions. A code by itself cannot supply localization decisions.
Changing codes after a translation archive has developed can complicate routing, content identification and human workflows. An informal convention such as ‘French means all Francophone visitors’ can also hide the fact that operational guidance applies only in one jurisdiction.
Verify configured locales in a staging installation and create one simple test page in each intended language. Confirm the locale recorded in the CMS and the language presented to the visitor before translating a full catalogue.
4. Learn the separate page-tree model
Wagtail represents translated pages in locale-specific page trees. It is not simply one record with many text columns. Different locale pages can be edited and published on different dates, and the tree structure influences navigation, permissions and the relationship between homepages.
Sketch the desired site hierarchy for each locale. Include the root page, key sections, contact information, policy documents and pages reachable through navigation. Translate the pilot tree in a way that preserves functional destinations without requiring every language to share identical editorial ordering.
A common mistake is to translate a leaf page without giving visitors a reliable language-specific route back to its parent. A second mistake is to assume that moving one page automatically creates the correct layout in every locale. These are structural decisions, not writing errors.
Inspect the page explorer and the public site side by side. Follow the translated homepage to a category, an article and a completion page, then inspect their actual parentage and routes. The journey should remain coherent without switching unexpectedly to a different language.
5. Understand locale and translation-key identity
Wagtail records a locale and a translation_key on translatable pages and eligible snippets. The shared key connects separate objects belonging to the same translation group. It is conceptually different from a URL slug or visible page title, which editors may change for readers.
Build a translation register around the original page identity and target locale, not around a spreadsheet of matching titles. Store review state, source revision, links to both versions and the intended publication date. This keeps the relationship intelligible when editorial naming changes.
If an editor duplicates a page outside the translation workflow, the copy may appear visually correct but lack the intended translation relationship. A language switcher may then fail to find the corresponding content even though both pages are publicly accessible.
Choose one article and inspect both language objects using the CMS’s available editor or developer tools. Confirm they represent the same translation group and have distinct locale assignments. Then test the language switcher from each direction.
6. Choose between simple translation and Wagtail Localize
Wagtail offers a simple-translation approach that creates content copies for editors to translate. Wagtail Localize is a separate, officially supported package that adds translation management, content synchronization and integrations. Both approaches can serve a project, but they create different maintenance expectations.
Decide how often source pages change and whether translators need structured workflows. A small static collection may be manageable with deliberate manual copying; an active multinational editorial team may need change tracking, translation segments, review queues and permissions.
Do not promise that the core system automatically tracks every translated phrase simply because Wagtail supports locales. Check which optional packages are actually installed, and read the documentation for the deployed versions rather than mixing screenshots from unrelated releases.
Run a controlled experiment: publish a source paragraph, create the translation, then edit the source. Observe how the chosen workflow alerts reviewers and where the new text appears. A maintainable system must expose revision work instead of silently hiding it.
7. Install and test Wagtail Localize deliberately
Wagtail Localize integrates with Wagtail administration and supports translating pages and snippets. Its package requirements change with major Wagtail and Django releases. Installation is therefore a compatibility decision, not just a command copied from a tutorial.
Confirm the official Wagtail Localize compatibility matrix for the deployed stack, enable Wagtail internationalisation and install the package in a staging environment. Apply the documented migrations, access settings and locale configuration before onboarding translators.
A production installation can already contain custom page models, StreamField blocks and unusual snippet definitions. A successful package installation does not prove that every model’s content is ready for translation or that old page relationships will remain usable.
Verify one ordinary page, one complex structured page and one eligible snippet. Inspect the translation editor and public output after both creation and source revision. Keep a rollback plan for configuration or package changes.
8. Decide what translation synchronization should mean
Synchronization describes how source changes reach the people responsible for target-language pages. It should not mean that a fluent editor’s reviewed language suddenly disappears when someone adjusts a source heading. Content structure and translated wording need clear rules.
Define whether new source text opens a translation task, whether existing translated segments can remain approved and how editors review moved or deleted blocks. Record who can accept synchronized updates and when the target page becomes eligible for republication.
Suppose a curator changes the exhibition date in English. The French text may require an immediate factual correction even if its carefully written explanation does not need rewriting. A workflow that treats both kinds of changes identically wastes effort and increases risk.
Make two source revisions in staging: one factual change and one stylistic clarification. Trace their effect through the localization workflow. Confirm that the review team sees a meaningful distinction and can verify the final published translation.
9. Preserve StreamField structure while translating
StreamField permits editors to assemble pages from structured blocks such as headings, paragraphs, images, cards and calls to action. The translation task is not merely a string replacement exercise because text sits within an ordered design that guides the reader.
Inventory each block type and decide which attributes are human language, which are identifiers and which are editorial structure. Translate visible text, captions and alt text appropriately while preserving required identifiers and allowed formatting. Review custom blocks separately.
A translator who changes a machine-readable key may break rendering, while a translator who preserves every word order mechanically may produce awkward target-language guidance. Translation quality therefore requires both technical restraint and linguistic judgment.
Test a page containing nested cards, a quotation, an image, a button and a related-content block. Review the editor view and the rendered mobile page. The content should remain intelligible, accessible and functionally connected after translation.
10. Translate snippets and reusable information correctly
Snippets often carry information reused on many pages: staff biographies, site notices, opening-hour summaries, footers and promotional cards. Wagtail can make relevant snippet models translatable, but the model must be designed for that behaviour.
Ask a developer to confirm that the snippet is configured as translatable using the relevant Wagtail model facilities. Choose whether a snippet’s facts are shared or region-specific, and test how a page in one locale resolves the intended snippet counterpart.
A translated page with an English opening-hours snippet may mislead readers, even when the main article is perfect. Duplicating the snippet informally can also produce contradictory versions of an important public notice during future updates.
Create a pilot snippet referenced by at least two pages. Translate it, change its source and check both target pages. The expected result should be consistent information with traceable editorial responsibility.
11. Translate rich-text links as destinations, not decorations
Rich-text content often contains internal links whose relationship to the destination matters more than the visible anchor words. A good translation workflow should preserve meaning while directing target-language readers toward the corresponding relevant page whenever it exists.
Map link destinations as content identities. When a translated page is available, inspect whether the editor or localization integration converts the link correctly. When it is not available, decide whether an honestly labeled source-language destination is acceptable.
Link text such as ‘Read the safety instructions’ is a promise about the next page. Sending a French-speaking visitor to a page in another language without notice may be merely inconvenient for a news article but unsafe for an essential instruction.
Click every main navigation, card, related-article and in-paragraph link on the pilot site. Record the URL, displayed language, page status and intended reader action. Fix destination mismatches, not only the words surrounding them.
12. Make language switching content-aware
A language switcher is a navigation tool, not a decorative list of flag icons. It should take a reader to the translation of the current page when that version exists, or to a clearly explained fallback when it does not.
Use Wagtail’s translation relationships to identify corresponding pages rather than guessing URLs from translated slugs. Display language names clearly, and avoid using a country’s flag to imply that one language belongs exclusively to one country.
A switcher that always returns to the second-language homepage discards a reader’s location and can cause frustration after a long search journey. A switcher that guesses a non-existent destination may produce a broken page.
Test switching languages from a deep article, a policy notice and a page available in only one language. Confirm the destination is honest and navigable. If the translated page is unavailable, the interface should not pretend otherwise.
13. Plan translated homepages and domains
Wagtail’s site-root and page-tree arrangements matter because multilingual homepages are separate content pages. A project may use language prefixes, subdomains or separate domains, but its public URL choice should reflect reader needs and long-term operational capacity.
Write down the intended homepage for each locale, how the application chooses it and how visitors reach it without being redirected away from an explicit URL. Include canonical domain ownership, TLS, redirects and alternate-language navigation in the plan.
An overly aggressive browser-language redirect can prevent testers and search engines from reaching a stable destination. A root page that looks translated but resolves to the wrong locale tree can also undermine navigation throughout a site.
Test direct entry to each homepage from a fresh browser, then follow a deep link and change language. Repeat with differing browser preferences. Stable public URLs should remain usable even when preferences and geography do not match.
14. Keep slugs, routes and redirects under editorial control
A translated title and a translated URL slug solve different problems. The title tells the reader what is on the page; the slug participates in persistent addressability, links, bookmarks and search discovery. Localized URLs need a policy that balances natural language with stability.
Choose descriptive slugs in the target language where supported and practical. Maintain an explicit redirect record when a published path changes. Do not assume that translating a title will automatically update old links or all external systems that reference it.
Consider a French event page whose original English slug includes an old year. Renaming only the visible title may leave a misleading address; changing the URL without a redirect may break partner links. The right decision needs both editorial and technical review.
Run a crawler or manual URL inventory before and after translation launch. Check redirect targets, trailing-slash behaviour, canonical tags, sitemap entries and the final destination reached by published internal links.
15. Translate metadata and search snippets truthfully
Page titles, descriptions, social previews and image labels may be managed through page fields, snippets or custom SEO integrations. They influence search and sharing, yet are easy to omit when editors focus on the visible article.
Translate every metadata field that makes a claim to the visitor. Keep descriptions useful and specific, and ensure that a localized snippet reflects the actual available content. Translate accessibility descriptions according to the image’s function, not just its original vocabulary.
A target-language search result promising online booking is inaccurate if the translated page contains no booking path. Search engines may also discover multiple routes to substantially similar content if canonical choices are inconsistent.
Inspect the rendered HTML and social preview for each pilot page. Confirm the page language, title, description, canonical URL and any alternate-language annotations with the development team, then compare these with what users see.
16. Design hreflang relationships around real equivalents
International search annotations should connect genuine alternate versions of the same content. An English exhibition page and its reviewed French counterpart form a natural relationship; an unrelated French homepage does not become an equivalent merely because both exist.
Agree on self-referential and reciprocal alternate-language URLs according to current search-engine guidance. Add only public, indexable and substantially corresponding destinations. Coordinate the implementation with whichever SEO package or template controls the head output.
Automatically generating a complete set of alternatives for every URL can create false equivalences when some translations are not ready. It is better to omit an unavailable alternate than to suggest an unrelated destination as its replacement.
Choose three pages: fully translated, partially translated and untranslated. Inspect canonical and hreflang links for each. Verify response codes, locale identifiers and whether the linked pages agree about their relationships.
17. Protect forms and transactional messages
A visitor’s most important interaction may occur after the article: search, booking, registration, donation or contact. Those systems can be rendered by custom Django views or external services, so content translation does not guarantee a complete localized workflow.
Inventory every visible label, validation error, consent notice, confirmation screen and transactional email. Decide who translates each layer, how placeholders and variable data are protected, and which legal claims need locale-specific approval.
A translated booking page can still send an English error message or a misleading email. The problem becomes more serious if a user misunderstands eligibility or the final payment conditions. Test the entire journey before public promises are made.
Submit a realistic test form in each locale, including a failed submission. Inspect the success message, email, accessible error labels and follow-up link. Keep genuine personal data out of testing wherever possible.
18. Manage images, captions and document downloads
Images may contain text, and documents linked from a translated page can contain essential details outside the CMS editor. A page should not be declared fully translated while its safety diagram, map legend or attached form remains unreadable to its intended audience.
Prepare an asset inventory with language needs and owners. For each asset, decide whether it can be shared, needs a translated caption or requires a new language-specific file. Keep alternative text faithful to the image and useful to assistive-technology users.
Do not duplicate photographs unnecessarily, and do not automatically translate proper names or technical labels that require exact identification. Conversely, a downloadable brochure’s English-only instructions may be a serious gap in an otherwise polished target page.
Open each downloadable document, play or inspect embedded media, and check image captions on mobile. The target-language page should tell visitors explicitly when a resource remains in another language.
19. Separate machine translation from publication approval
Machine translation can accelerate first drafts or terminology suggestions, but it does not verify an institution’s factual claims. A multilingual CMS can integrate translation services without transferring editorial responsibility to the service.
Classify content by consequence. Low-risk descriptions can use a light review, while safety notices, financial terms, medical guidance and legal statements require appropriately qualified human verification. Preserve named entities, dates, units, abbreviations and accessibility meaning.
A fluent-sounding mistranslation can be more dangerous than an obvious unfinished sentence because readers may rely on it with confidence. The source content can also be wrong, which means the reviewer sometimes has to challenge the original.
Build a sign-off process using a named editor, target-language reviewer and domain expert when needed. Save the revision or evidence used for approval, and require re-review after material source changes.
20. Establish terminology without flattening language
Consistent terminology helps users navigate a site and recognise concepts across multiple articles. It is especially useful for institutional names, collection titles, scientific terms and repeated application buttons, but consistency must not become mechanically unnatural writing.
Create a small glossary from actual high-impact content. Include the source concept, preferred target expression, context, prohibited ambiguity and an example sentence. Record what should remain untranslated, such as protected trademarks and exact identifiers.
A glossary containing only word pairs can give the wrong answer when a term has several senses. For example, ‘collection’ may refer to museum holdings, a fee, or the act of collecting data. Translation depends on the local sentence and reader task.
Ask two reviewers to translate a representative paragraph with the glossary, then compare their choices. Update definitions only when they improve comprehension and factual consistency; do not force every occurrence into the same phrase.
21. Configure editorial permissions and review ownership
International publishing often involves multiple teams with different authority. Wagtail can support locale-aware editorial workflows, but the actual permission configuration and custom business rules determine who may edit and publish each target version.
List which roles can draft, translate, review, publish and roll back. Assign accountability for emergency corrections and local factual verification. Avoid granting broad publication rights merely because a translator needs access to a page’s text.
A common failure occurs when the source page is updated under time pressure but no one knows who can approve the corresponding target page. Another occurs when an editor changes a shared snippet without realizing the change affects several locales.
Simulate a change request involving a source editor, translator and approver. Confirm that each person can see the necessary material without being able to publish unreviewed content outside their responsibility.
22. Design a source-change register
Translation is not a one-time conversion. Pages accumulate new facts, seasonal dates, policy changes and corrections, while translated versions develop their own style and sometimes local content. A change register makes these movements visible.
Record source page identity, modification date, change type, affected locales, urgency, reviewer, approval state and published target revision. Distinguish fact corrections from style improvements; they do not require identical turnaround expectations.
A change to the venue address must reach every audience immediately, while a small improvement to a historical introduction can wait for scheduled review. Treating both changes as equal creates noise, yet ignoring all small changes accumulates divergence.
Revisit an article after two revisions and ask the target-language editor to describe what changed and what remains to be checked. If that answer cannot be produced from the workflow, documentation needs improvement.
23. Test accessibility and multilingual reading order
Localization changes the physical shape of text. Some translations expand, some words wrap differently, and some scripts require different fonts or text direction. The CMS editor may look fine while the public page becomes difficult to use.
Test headings, lists, button widths, focus order, language declarations, alternative text and screen-reader names. Check right-to-left languages separately if supported, and make sure embedded user-interface components do not reverse important numeric or directional meaning.
A button that fits in English may truncate in German; a graphic with hard-coded English labels may be invisible to readers who cannot use the image. A page can be linguistically fluent yet inaccessible or technically misleading.
Use keyboard navigation and a screen reader for a pilot workflow. Inspect mobile and desktop layouts, zoom settings, long words, file downloads and error messages. Record defects against the exact locale and component.
24. Publish with a repeatable multilingual release gate
A release gate is a short set of observable standards, not a long ceremony. It should answer whether the target-language page is accurate, complete for its intended task, structurally connected, accessible and discoverable without misleading visitors.
Review source identity, target locale, current facts, page-tree position, internal links, form outcomes, metadata, alternate URLs, approval and rollback. Inspect the public URL after publishing, because a successful CMS save does not prove that caches and routing serve the correct page.
Do not hide incomplete work behind a translated title and an indexable URL. If a jurisdiction-specific warning remains unverified, delay that page or label the limitation honestly. An international edition should not promise more than the editorial team can maintain.
Choose a release owner and record the final checks with date and page identity. Re-run the core journey after deployment, and schedule rechecks when important source information, site templates or language configuration changes.
Worked example: launch the museum’s French exhibition journey
The source website has an English homepage, an exhibition overview, an accessibility notice, an event booking page and a confirmation email. The editorial team first records the source page identities and which facts are universal: the artist’s name, exhibition dates, accessibility features and collection descriptions. It then marks the admission rules and booking conditions for separate local verification. This simple inventory prevents the translators from assuming that every source claim can travel unchanged into a new public market.
In Wagtail, the team creates or confirms the French locale and translated homepage. It translates the exhibition pages through the chosen workflow, maintaining relationships to the English counterparts. A collection summary stored in a translatable snippet receives a reviewed French version; StreamField cards keep their structure while their visible descriptions, image labels and calls to action are translated. Internal links are checked against the French page tree rather than rewritten by changing an English slug by guesswork.
The booking page creates a useful test. Its main text is French, but an integrated reservation service may still send an English confirmation and apply venue rules that have not been approved. The team therefore tests a harmless booking submission, checks errors and email contents, and records exactly which system owns each string. It either fixes the missing localization before launch or describes the remaining language limitation plainly; it does not call a partial flow complete.
On release day, reviewers open the homepage and exhibition detail through direct French URLs. They follow navigation links, use the language switcher, inspect metadata, open the accessibility PDF and check that the public article matches the approved source revision. An unresolved broken download blocks launch. A cosmetic line-wrap issue may be corrected without changing the translation’s factual approval. The result is a controlled release with clear evidence, not simply a large set of published copies.
Common problems and how to diagnose them
French page appears but the language switcher jumps to the homepage
Verify the page is linked to the intended translation group, the locale-specific page exists and the switcher uses content identities rather than guessed paths. Begin with one reproducible public URL and a known source revision. Compare the editor’s stored values with the page rendered for a visitor, then trace the discrepancy to the content model, localization process or deployment layer. Retest the same journey after making the correction.
An English snippet appears inside a translated article
Inspect whether the snippet model supports translation, whether the target snippet exists and how the page or template resolves the snippet for the current locale. Begin with one reproducible public URL and a known source revision. Compare the editor’s stored values with the page rendered for a visitor, then trace the discrepancy to the content model, localization process or deployment layer. Retest the same journey after making the correction.
A translation is published but not found in search
Check indexability, response status, canonical URLs, sitemap inclusion, appropriate alternate links and whether the page contains sufficient unique reviewed content. Begin with one reproducible public URL and a known source revision. Compare the editor’s stored values with the page rendered for a visitor, then trace the discrepancy to the content model, localization process or deployment layer. Retest the same journey after making the correction.
Recent English edits do not appear in the French review queue
Confirm which translation workflow is installed, whether the changed fields are translatable and how synchronization or review tasks are configured. Begin with one reproducible public URL and a known source revision. Compare the editor’s stored values with the page rendered for a visitor, then trace the discrepancy to the content model, localization process or deployment layer. Retest the same journey after making the correction.
The image caption is translated but the download is not
Trace the document or media asset as a separate resource and either provide a verified target-language version or label the download’s actual language. Begin with one reproducible public URL and a known source revision. Compare the editor’s stored values with the page rendered for a visitor, then trace the discrepancy to the content model, localization process or deployment layer. Retest the same journey after making the correction.
Four-week implementation plan
Week one is discovery and editorial ownership. Inventory pages, snippets, StreamField blocks, templates, forms, outgoing documents and language-specific claims. Choose one full reader journey and record supported locales, business rules and accountable reviewers. The deliverable is a small content map with explicit translation scope, not a bulk export of strings.
Week two is configuration and controlled translation. Validate compatible Wagtail and Wagtail Localize versions where applicable, create the locale structure, translate the pilot pages and snippets, and test a deliberate source edit. Fix broken page relationships and ambiguous fallback behaviour before asking editors to translate dozens of additional pages.
Week three is reader-facing quality. Review target-language terminology, factual accuracy, dates, image labels, download language, UI messages and transactional emails. Test navigation, language switching, keyboard operation and mobile layout. Give reviewers realistic scenarios rather than asking only whether paragraphs read smoothly.
Week four is release and maintenance. Verify URLs, redirects, canonical and alternate-language signals, sitemaps, cache behaviour and public visibility. Publish the reviewed journey, log the approved source revision and assign responsibility for future updates. Use failures from the pilot to refine the workflow before expanding to more sections or languages.
Frequently asked questions
Does Wagtail translate article text when a locale is created?
No. Locale support provides the content architecture; it does not write accurate target-language articles. Editors or a configured translation process must create and review the wording.
Is Wagtail Localize part of core Wagtail?
Wagtail Localize is an officially supported separate package. Check compatibility with the deployed Wagtail and Django versions before installing it.
Can translated pages publish on different dates?
Yes. Wagtail’s locale-specific page objects can be managed independently, subject to the project’s workflow, permissions and publication configuration.
What connects an English page to its French translation?
The relevant translatable content objects share a translation identity while each has its own locale. A matching title or slug alone is not reliable proof of that relationship.
Are snippets automatically translated?
Not necessarily. The snippet model and translation workflow must support it, and the actual target-language content still needs verification.
Will Wagtail Localize fix every external checkout message?
No. External services and custom Django interfaces have their own translation and compliance work. Test them as part of the complete user journey.
How should missing translated pages be handled?
Use a clear, documented fallback or an honestly labeled unavailable state. Do not route readers silently to unrelated pages or imply that unreviewed content is complete.
What is the most useful final QA test?
Follow a realistic target-language reader journey from a public entry URL to a completed action, checking factual accuracy, links, forms, accessibility and search metadata.
Official documentation and connected learning
Check platform instructions against the exact deployed Wagtail, Django and Wagtail Localize releases. Product interfaces and compatibility change, but the core editorial requirement remains constant: each translation must be a truthful, navigable and maintainable version of the intended content.
Wagtail — Internationalisation documentation
Wagtail Localize — official documentation