Q&A: Multilingual support improvements

[thibaudcolas]

👋 use this discussion thread for any and all questions relating to our project idea: Multilingual support improvements.

Check out our recommended (optional) tasks for contributors, including tasks geared towards getting up to speed for this project idea.

[Phinart98]

Hi @thibaudcolas, It's great to see you here. We met at DjangoCon Africa in Arusha!😅

I have been going through the discussions you linked above and then digging into the source code of wagtail and wagtail-localize directly for some time. The locale-after-creation problem stands out to me as the most critical piece. I got some insights when I read the code, but two questions remain that I would appreciate a response to:

1. On locale mutability: CreatePageAliasAction already accepts an update_locale parameter (create_alias.py), so the primitive for a locale-offset alias exists. What's missing is a user-facing workflow that wraps it, handling url_path recalculation, cascading locale updates to child translatable objects, and on the wagtail-localize side, migrating the TranslationSource record (which has unique_together = [("object", "locale")], meaning a locale change on the source page would orphan it). Is the GSoC scope expected to cover both the core Wagtail and wagtail-localize sides? Or is the intent to design a core-only solution that wagtail-localize then adapts to?

2. On content comparison: The current preview_translation() builds a read-only ephemeral instance via get_ephemeral_translated_instance(). No diff highlighting, no change tracking between versions. Is the GSoC project expected to build on top of this existing preview infrastructure, or would a proper comparison view require a different approach entirely?

Understanding and getting more insights on this would help me massively in scoping the proposal that I am putting together. Thank you for your time!

[thibaudcolas]

Is the GSoC scope expected to cover both the core Wagtail and wagtail-localize sides? Or is the intent to design a core-only solution that wagtail-localize then adapts to?

This is up to you to decide in the proposal. And would be confirmed with mentors once the project starts. This project idea is intentionally more open-ended so that people who have the domain expertise and time to do the research can shine. There are a lot of pros and cons to "core" vs. "package" for decisions like this, don’t get too worried about picking the "right" answer. What matters to us is demonstrable understanding of the trade-offs.

Is the GSoC project expected to build on top of this existing preview infrastructure, or would a proper comparison view require a different approach entirely?

Same as above, no preference at this stage. I think both approaches have merit.

[Phinart98]

Thank you for the response, @thibaudcolas! I believe I have what I need now. I've been going back and forth on the core-vs-package question, and this confirms I should present both options with a clear rationale rather than try to guess the "right" one. I will think more deeply about this.

I've published a blog post exploring these two gaps I was thinking about: https://philipnarteh.me/blog/whats-broken-in-multilingual-wagtail

I'm currently working on the full proposal. I'll aim to share the draft on the avenue given before submitting the final document on the portal. Thanks again for the guidance!

[sushanthaaa]

Hey @thibaudcolas ,

Following your recommendation on my participant file, I’m very excited about the Multilingual support improvements project.

My production Wagtail EIP at Pou Chen Group included full i18n with English + Traditional Chinese (URL prefixes, LocaleMiddleware, custom menu translation tags). I also documented everything with detailed SOPs and architecture guides.

I’ve already started contributing to bakerydemo (PR #653 for block-based menus) and am now setting up wagtail-localize locally to analyze and begin small PRs here too.

I am fully available for the entire GSoC period and my internship is flexible and ends this June. (35–40h/week confirmed).

Would you have any early guidance on which pain points from #13693 to prioritise for a strong proposal, or should I start with a small improvement in wagtail-localize first?

Thank you!

[thibaudcolas]

@sushanthaaa as far as the proposal, no preference. As far as possible contributions to try out as part of this proposal phase, see what I added in our contributor guide:

Locally test, review, and provide feedback on one of the pull requests to wagtail-localize
Attempt to fix one Wagtail core issue tagged 'i18n'

You should note there is really no desire for more small PRs on wagtail-localize, where we’re already at capacity. What would help is (good) review and feedback on existing PRs.

[sushanthaaa]

Update on my progress:

I've set up a working wagtail-localize demo by extending the bakerydemo:

Live demo: https://sushanthaaa.pythonanywhere.com/en/ (Spanish: /es/, French: /fr/)
Branch: https://github.com/sushanthaaa/bakerydemo/tree/feature/wagtail-localize-demo
To understand different translation workflows, I set up Spanish by translating pages individually and French using the "Include subtree" option. This helped me experience the two approaches and compare how they work in practice.

During this process, I ran into #773 when translating with "Include subtree", the translated parent page's numchild stays at 0, causing child pages to not appear in the admin explorer. The pages exist and are correctly parented but are invisible due to the stale tree metadata. I worked around it with Page.fix_tree(), and I can see the root cause is in the subtree translation logic where treebeard's numchild isn't recalculated after bulk child page creation.

Following your suggestion, I'll now focus on reviewing and providing thorough feedback on the existing wagtail-localize PRs. Is there a specific PR you'd like me to prioritize, or should I start working through the open list, or should i work on issue #773 and try to fix it or mention about it in my proposal?

[shreyasbhaskar2001]

Hi @thibaudcolas, Shreyas here. I’m excited about the “Multilingual support improvements” idea for GSoC 2026 and have been
digging into how Wagtail currently handles localisation, especially with Wagtail Localize and the core i18n tooling. The
combination of locale-specific page trees, translation keys, and machine-translation integrations looks powerful, but I
can see why maintainers want to streamline the editorial workflow this summer.

(https://wagtail.org/blog/our-projects-for-gsoc-2026/?utm_source=openai))

A few questions to help me focus:

1. Which multilingual bottlenecks are top priority right now—structural sync across locales, editorial UX, machine-
   translation pipelines, or something else?
2. Are there existing community sites or issue threads you’d like me to study so I can anchor the proposal in real use
   cases?
3. How important is headless/REST parity for this idea (e.g. ensuring translated content stays consistent via the API as
   well as the traditional templates)?
4. Would you prefer incremental UX wins on top of Wagtail Localize, deeper platform changes in core Wagtail, or a blend
   of both?

Thanks & regards,
Shreyas

[thibaudcolas]

Which multilingual bottlenecks are top priority right now—structural sync across locales, editorial UX, machine-
translation pipelines, or something else?
Are there existing community sites or issue threads you’d like me to study so I can anchor the proposal in real use
cases?

I think you’ve already found the one thread which answers this :)

How important is headless/REST parity for this idea (e.g. ensuring translated content stays consistent via the API as
well as the traditional templates)?

It’s not as important as more fundamental improvements. But still important. Would appreciate improvements in this area definitely.

Would you prefer incremental UX wins on top of Wagtail Localize, deeper platform changes in core Wagtail, or a blend
of both?

All those options are valid, we want to leave this open, see what people propose.

[lourduradjou]

Hello @thibaudcolas , I have some questions regarding this project

1. wagtail-localize-docs this docs explains how to integrate DeepL for translation but I can't see any other way to support other vendors like AWS or Azure or open sourced translation models, this may make people to lock in to one vendor. So my question is the gsoc project expected to support multi-vendor system for machine translation ?

2. gsoc-contribute as stated here is it a must? to showcase my idea changes in this site or can I use my own portfolio site? (this would save some time for me.)

3. I can see from the discussions forum on improving this project, lot of people are saying to improve the UX of the existing wagtail-localize plugin (after integration), so It is fine is we make the proposal oriented towards both core support + UX support to handle the existing requirements. How much the weightage the mentors are expecting on this?

4. finally how much support can I expect from the mentors, I mean , are we going to discuss/design/etc as weekly meet or through slack discussions? (just curious to know this) I am thinking to have a two flow approach to keep technical approaches with us and showing the Ux/Ui ideas to the community to let them share their feedback.

Thank you for your time, please others can also discuss about this with me!!

[thibaudcolas]

So my question is the gsoc project expected to support multi-vendor system for machine translation ?

Our expectation is "better support for automation". Being more agnostic to providers would contribute to that. It’s not expected but it’s a good idea.

Demonstration of those changes on our multilingual user guide website.

This is required for completion of the project, once it starts. As part of your proposal, feel free to ignore that site. It’s just one site that uses wagtail-localize like any other.

so It is fine is we make the proposal oriented towards both core support + UX support to handle the existing requirements. How much the weightage the mentors are expecting on this?

What we’ll give weight to is a clear list of key goals/issues the project will address, and good rationale for how to address them, including which ones to try and tackle in Wagtail core vs. wagtail-localize. You don’t need to get it "right" as we might weigh those decisions differently, but we want a clear rationale given.

finally how much support can I expect from the mentors, I mean , are we going to discuss/design/etc as weekly meet or through slack discussions?

This is TBC per project but at this stage you should state what you think would work for you in your proposal. Or usual setup is one weekly meeting, Slack in-between, but other options are possible. For projects with multiple mentors we might have one weekly meet with everyone, and 1-on-1 with each mentor at other times.

[thibaudcolas]

@EvoChronyX please keep this thread to questions about this project

[zanzo2003]

Hi everyone, thanks again for all the insights in this thread! I’ve pulled together a shortlist of multilingual workflow
fixes that I’d love to tackle for GSoC and would really appreciate your thoughts on priorities (or any overlaps with
work already in progress):

• Translation diff view & memory hints – wagtail-localize#502. Editors lose the previous translation when source text c
  hanges; I’d like to add a diff sidebar so translators can update incrementally. I don’t see any open PRs linked to th
  is issue as of 19 Mar 2026. (github.com (Showing text diff and old translation (tagged as needs revision) for changes made in synchronized translation wagtail-localize#502))
• Reliable draft-to-draft sync – wagtail-localize#823. The top customer complaint in this discussion is that sync stops
  working once both source and translated pages have drafts, so I’d like to harden the sync pipeline around multi-draft
  workflows. No active PRs yet. (github.com (Wagtail-localize only syncs to the translated pages, sometimes.  wagtail-localize#823))
• Bulk publish + sync tooling – wagtail-localize#789. Bulk actions would cut a ton of repetitive clicking and reduce the
  “sync didn’t run” failures called out above; also no PRs open today. (github.com
  (feature request: bulk sync + publish and sync action wagtail-localize#789))
• Segmented rich-text improvements – planning to open a fresh issue based on feedback that the current StringSegment sp
  litter mangles inline markup and produces awkward machine translations; goal is DOM-aware grouping plus better previe
  ws. (github.com (Improving support for multilingual websites wagtail#13693))
• Translation status analytics + optional auto-creation – another new issue proposal to make it easy to list “pages/sni
  ppets with manual translations” (without raw SQL) and to auto-create translation objects for headless use cases, alig
  ning with the reporting pain points folks shared. (github.com (Improving support for multilingual websites wagtail#13693))

Could you let me know which of these would deliver the most value for the upcoming release cycle, and whether there’s
existing work or design discussions I should plug into? I’ll start by reproducing #502/#823 locally unless you’d prefer
a different order, and I’m happy to help write up the two new issue drafts once we agree on scope. Thanks!

[zanzo2003]

Hi team,
I’ve submitted a PR(#912)that resolves Wagtail Localize Issue #502. It introduces support for surfacing and reusing previous translations when source content changes, along with a regression test for the scenario.
I’ve verified the changes both via tests and manually in the translation editor. Would appreciate your review and feedback when you get a chance. Thanks!

[shreyasbhaskar2001]

Hi @zanzo2003, I got a chance to review your PR !!! amazing work...i check when time permits.

[thibaudcolas]

@zanzo2003 I think you’re asking too much here TBH. It’s for you to make the case which of those improvements you think are worthwhile, in your proposal

[Marvinrose]

Hi @thibaudcolas
I have a question about segmentation in wagtail-localize that touches several goals in my proposal.

The current fine-grained segment approach is what makes translation memory effective, since small changes in source content can still reuse previous translations. At the same time, this same approach seems to be behind two of the biggest pain points in #13693: machine translation losing sentence-level context (word order, agreement), and translators seeing inline elements break apart or move around in the editor.

The improvements I’m exploring, like grouping segments by paragraph and using richer editor components, are mostly about giving translators more context. But that starts to look a lot like coarser segmentation, which could reduce how reusable translation memory is.

I’d love to understand the project’s direction here: is the expectation to keep segment-level storage and improve only how segments are presented, or is there openness to revisiting the segmentation strategy itself?

That distinction affects how I scope both the translator experience work and the translation memory UI.

[thibaudcolas]

I don’t think I can definitively say at this stage really. My approach to this would be to look at how other better-established software does this, see if they might be faring better.

[Marvinrose]

Thanks! That's a great direction. I'll look at how tools like Phrase, Poedit etc.. handle this..

[sushanthaaa]

Hi!

I reviewed PR #882 in wagtail-localize, which adds translatable_blocks support for StructBlock addressing the long-standing issue #307.

The PR (by @Andreew4x4) builds on @freddiemixell's original PR #752, cherry-picking the core implementation and adding comprehensive tests and documentation. The feature allows developers to control which sub-fields of a StructBlock are extracted for translation which will be useful for blocks like CodeBlock or YouTubeBlock where translation doesn't make sense.

A few things I noticed during the review:

1. Silent failure on typos — if a developer misspells a field name in translatable_blocks, the field is silently excluded with no warning. A logged warning could save debugging time.
2. Interaction with get_translatable_segments() — if a StructBlock defines both translatable_blocks and get_translatable_segments(), the latter takes priority. This isn't documented.
3. Nested StructBlock test gap — the tests don't cover a StructBlock-inside-StructBlock where both levels have different translatable_blocks settings.

My full review is here: wagtail/wagtail-localize#882 (review)

This was a great way to get deeper into the wagtail-localize codebase ahead of my GSoC proposal for the Multilingual Support Improvements project.

[thibaudcolas]

Thank you everyone for taking part in this thread! We’ve received 24 proposals for this project. We’re going to hold off from responding to further questions, just so we can focus on reviewing the proposals.