5 Pain Points Wagtail Users Face with Multilingual Sites

Sushanth Purushothama — Sat, 28 Mar 2026 13:47:07 +0000

Wagtail CMS has solid building blocks for multilingual websites. It has a Locale model, TranslatableMixin, and i18n_patterns for URL routing. The wagtail-localize package adds translation workflows. It also supports machine translation.

When I read Discussion #13693, I noticed clear patterns. Maintainers and users shared their real-world experiences with i18n. Here are the five biggest pain points.

1. Links That Switch Your Language

When you call .localized on a page, it should return the translated version. But if no translation exists, it returns the source-language page instead of None. This causes menus and links to switch the user into a different language.

Many users reported this problem. One developer wrote custom _or_none methods to work around it. This should be built into Wagtail's core.

2. Sitemaps That Forget Other Languages

Wagtail's sitemap generator only lists pages in the default locale. It does not add xhtml:link alternate entries or x-default values. This hurts SEO. Search engines can't find the translated pages.

3. Search That Only Works in One Language

Wagtail's search backend does not support many locales. You cannot configure different NLP dictionaries for different languages. The only choice is to turn off language-specific processing. This leads to poor search results for everyone.

4. Page Tree Bugs in Wagtail-Localize

I experienced this myself. The "Include subtree" translation feature makes child pages. However, it does not update the parent's numchild metadata. This makes translated pages invisible in the admin. I reported it as issue #773 and fixed it with Page.fix_tree().

5. No Way to Tell Source from Translation

Wagtail's TranslatableMixin doesn't show if a page is a source or a translation. The has_translation attribute returns True even on translated pages, which is confusing. Developers need a clear way to check if a page is the original or a translated copy.

What This Means

These are not edge cases. They affect every multilingual Wagtail site. The good news is the community has clearly identified these problems. Several of them have simple solutions.

I am proposing to work on fixes for items 1, 2, and 4 as part of my Google Summer of Code project. You can see my demo site at sushanthaaa.pythonanywhere.com and the source code on GitHub.

Read my other post: How I Found a Hidden Bug in Wagtail-Localize

How I Found a Hidden Bug in Wagtail-Localize

Sushanth Purushothama — Sat, 28 Mar 2026 10:55:30 +0000

I am working on a GSoC proposal for Wagtail CMS. As part of my preparation, I set up a multilingual demo site using wagtail-localize. I learned a lot about how Wagtail handles translations and found a bug along the way.

What I Was Doing

I extended Wagtail's Bakery Demo with three languages: English, Spanish, and French. For Spanish, I translated pages one by one. For French, I used the "Include subtree" option to translate an entire section at once.

The Spanish pages worked fine, but the French pages had a strange problem.

What Went Wrong

After translating the French subtree, I could not see any child pages in the admin panel. The pages existed in the database. They had content. But the admin explorer showed nothing under the French homepage.

I got "Page not found" errors when I visited the child page URLs directly, even though the pages exist.

How I Diagnosed It

I wrote a small script to check the page tree data. Every Wagtail page stores a field called numchild. This tells the admin how many children a page has. If numchild is zero, the admin skips the database query to find children.

The French homepage had numchild = 0, even though it had several child pages. The "Include subtree" translation made the child pages but didn't update the parent's counter.

This happens because wagtail-localize uses django-treebeard to manage the page tree. When it makes many pages at once during subtree translation, it skips updating numchild.

How I Fixed It

The fix was simple. I ran one command in the Django shell:

from wagtail.models import Page
Page.fix_tree()

This rebuilt the tree metadata. All French child pages showed up in the admin and loaded fine on the frontend.

What I Learned

Translation tools can have subtle data bugs. The pages were created correctly, but the metadata was wrong. This kind of bug is hard to spot because everything looks fine until you check the admin explorer.
numchild is critical for Wagtail's page tree. It controls whether the admin even tries to find child pages. A wrong value makes pages invisible.
Bulk operations need extra care. When you create many pages at once, update all related metadata too. It's not enough to just update the pages.

I reported this as issue #773 in wagtail-localize. The bug is still open and needs a permanent fix in the package.

If you use wagtail-localize's subtree translation feature, watch out for this. Running Page.fix_tree() is a good workaround until the fix is merged.

Check out my multilingual demo: sushanthaaa.pythonanywhere.com | Source code

DEV Community: Sushanth Purushothama