Language Accessibility for PyCon US Website

PSF
1

Hello folks,

Since the PSF manages https://us.pycon.org/, I think this is the right place to raise this topic.

As a native Spanish speaker, I’ve been highly interested in the PyCon Charlas program ever since my first PyCon in 2024 (and in 2025 I even gave a charla myself). It’s inspiring to see such a strong Spanish-speaking community present at PyCon US, which is primarily an English-speaking event.

As much as I admire the Charlas program, support for Spanish-speaking participants sometimes feels limited to that single space — largely because of the strong presence and initiative of the community itself. In practice, it can feel as though inclusion is delegated to the Spanish-speaking community, rather than being integrated into PyCon US more broadly. I realize this may come across as a stronger critique, but it reflects the experience of many of us who don’t really get a peek behind the scenes of how these decisions are made.

That’s why I was surprised to see that the PyCon US website currently has no language accessibility tools. I’d like to help change this. Specifically:

  • I’d like to request guidance on how I could help enable support for Spanish (and potentially other languages) on the PyCon US website.
  • I understand the site may be closed-source, so I’d like to know the process for proposing or contributing modifications.
  • There’s also an existing group of Spanish-speaking editors who regularly translate the official Python docs (python-docs-es), started by @cmaureir ; who I’m sure would love to contribute

My hope is that this could be a first step toward deeper integration of language accessibility at PyCon US — not just within Charlas, but across the conference experience.

10 Likes
2

I’m always in favor of adding non-English translations to Python. Adding multilingual capabilities to a website is a huge effort, and I’m no web designer who can say the right way to do this. And I wouldn’t want to add even more work onto the small PSF team who manages the site.

Really, I think the best place to put efforts is in the Python documentation and the existing Spanish-speaking editors that you pointed out. Getting their feedback on where efforts should go is what I’d defer to. Browsers have built-in translation services for websites, and many of the pages aside from the front page and download page probably don’t see all that much traffic. (Though please do point out any pages as examples otherwise.)

2 Likes
3

Hi Al,
I want to clarify a couple of points:

And I wouldn’t want to add even more work onto the small PSF team who manages the site.

I completely understand not wanting to overburden the PSF team. To be clear, I’m volunteering to do the implementation work myself.

The main barrier is that the PyCon US website appears to be closed-source, so I can’t fork it, implement the changes, and submit a PR.

Browsers have built-in translation services for websites

relying solely on them for accessibility isn’t ideal. Automated translations often struggle with:

  • Technical terminology and Python-specific jargon
  • Cultural nuances and idioms
  • Maintaining appropriate tone for different audiences
  • Consistency across related content

I remember starting out with python, switching to the spanish tab and quickly switching back to English because the content contained many machine translations and it was confusing, that has since improved a lot with the spanish translation folks.

Multiple multi-language guides specifically recommend visible language selectors and human-reviewed translations for important content.

Really, I think the best place to put efforts is in the Python documentation and the existing Spanish-speaking editors

Suggesting we focus efforts elsewhere reinforces this pattern where inclusion becomes something the Spanish-speaking community needs to build for themselves, rather than something that’s built into the conference infrastructure. I know this isn’t the intent, but when language accessibility remains limited to community-initiated spaces like Charlas, it can feel like we’re guests in our own designated area rather than full participants in the broader conference.

In many LATAM cultures, when someone comes to your front door, you make them feel welcome - bring them a coffee and bread, and make all efforts to accommodate them. This is what I envision PyCon US and all other PyCons should embody, especially given the significant Spanish-speaking community that attends. The website is that front door.

For PyCon US specifically, key pages that would benefit from translation include:

  • Registration and ticketing information
  • Code of Conduct
  • Financial aid applications
  • Speaker/tutorial proposal guidelines [ though I think Cristian might have done on this already]
  • Venue and travel information
4 Likes
4

Some content of PyCon US website are written in a CMS platform called wagtail. I believe wagtail has internationalization features, so having multi-language PyCon US website is a possibility.

I think striving for language inclusivity and accessibility is a great goal, and those pages that you suggested are great start for being translated.

I can also see some concerns in implementing language translations for the PyCon US website:

  • Needing to configure wagtail to support the internationalization/ language translations
  • Needing to manage/give write access to the translators so that they can write up content.
  • Needing to review/approve translated content for every single pages.
  • Needing to coordinate/notify translators about upcoming content. Eg, is it ok if the english page showed up first, and the other language translations to come say one week later? Or should all the different languages show up at the same time as the english content?

If we’re ok with not having the translations to show up at the same time, it could make it a bit easier, but still takes effort. The PyCon US team could continue writing the content in english and publish them. Whenever you’re ready, (and only if the PyCon US team agree to this), you could then offer to write up the translated content in some document, send the translations to them, wait for them to review your translations, after that they could upload your translations to the website.

Also I believe some pages like the actual registration and ticketing form and the financial aid application are not in wagtail, so that would require a different mechanism for supporting translations. Perhaps starting with just translating content on wagtail would be a good first step.

This is just one suggestion on how we can begin supporting translated content. If the PyCon staff don’t have the bandwidth to do anything this time around, I would understand and respect that decision.

5 Likes
5

Hi! PSF staff member here, just popping in to say the staff person who leads the PyCon US website is OOO this week, and we want to have her input before making a longer response. So heads up we have seen your post, appreciate your thoughtful feedback, and will reply! Hopefully next week.

9 Likes
6

Hi! PyCon US committee member here :waving_hand:

Kevin, thank you for sharing this perspective — the “front door” analogy is such a clear way to describe why language accessibility matters. I also want to note that this is a proposal we’ve been working on with the Infra team, so your input is very much aligned with ongoing discussions.
As Co-chair of PyCon Charlas with Cristián, I’d also like to share that our call for volunteers for the PyCon Charlas Committee will be opening soon. If you’d like to get involved, your experience and passion for accessibility would be a real asset — and of course, you already know how to reach us directly if you’d like to connect.

I really appreciate you raising this. Conversations like this help us keep moving toward a more inclusive PyCon. :purple_heart:

7 Likes
7

Hey Kevin,

Thanks for raising this important topic.

I cannot add much besides what was mentioned already, but helping with the translations in the past editions, the platform we use (wagtail) require you to set permissions per-user to access the edit options of certain pages. I got access to a few pages a couple of years ago, and was able to translate a few things, but in the recent editions, we provide the translation as a document, that is later put on the website.

This doesn’t scale, but I also understand that because is the infrastructure that has been working for many years, the motivation to changing it creating more work around it might be too much, for getting better i18n (just assumptions).

If you want my opinion, it would be great if the PyCon US site could live in a repository, so people could grab the text and provide a translation of all the areas, but as I said, that is changing what have been done in the past.

Something else to consider, which for sure it’s not a big deal breaker, is that currently the people working in the website, just need to log-in and click on the edit button, lowering the barrier for them, compared to work with Git, but again that’s also a little assumption.

For PyCon US 2026, I’d say the way of doing this is:

  • The PSF Staff working on the website provides documents with the content in English, and people can jump into it and provide a translation.
  • A person (or people) check the final version, which can later be put in the website.

As Denny and Loren mentioned, we could reach the PyCon US Coordinator in the next meeting, and we could enable this content to be put somewhere “public” to do the proper translation of all the pages.

Little clarification: I didn’t start the translation of the Python documentation to Spanish, I just joined in 2019-2020 and starting helping with it :slight_smile: it was started before by people from the Argentinian and Spanish community (Raúl and Marian)

2 Likes
8

Full +1 on this. Automatic translation is a major annoyance on websites that impose it on users.

3 Likes
9

Thanks for letting me know loren!

10

If you’d like to get involved

absolutely, I’ll reach out to you in the upcoming days.

1 Like
11

Hey Cristián,

Your breakdown of the wagtail limitations makes total sense.
going from a simple edit button to Git would add friction for staff, but honestly I think the impact on accessibility would make it worth it.

The workflow you laid seems solid, though realistically, PSF staff might not want to take on the extra work, which I get.

I think we could start small, Like a pilot with just the critical pages I mentioned earlier, see how it goes, work out any issues before expanding.

and again, I’m happy to put in the work to get this done.