Docs translation platform

Documentation
1

A number of language teams translating Python docs have been using Transifex as the translations platform (7 out of 21 counting roughly). [1]

In October 2022 the changes in Transifex (and their policy) made it impossible to use shared translation memory along with translation memory fillup that used to propagate the translation memory between projects for different versions of Python (there is a project for documentation of every supported Python version, while the main focus is the latest stable). We would need to opt-in to Premium plan to make it work. We are discussing a workaround while keeping the basic open-source plan, but it loses the authorship info in PO files metadata.

Weblate project supports memory propagation between projects through shared translation memory and Automatic translation add-on. Moreover Weblate supports automatic suggestions from machine learning translation services which greatly improve translations experience (Transifex lacks this feature). Also Weblate is licensed with GNU GPL and open-sourced.

The Python docs project is too big to use Hosted Weblate’s standard open-source plan (libre plan allows 10,000 source strings and Python 3.12 docs have 57,643 of them). Although they offer discounts for open-source.

There is also an option to self-host the Weblate instance. That would require a maintenance burden though on ours/PSF side.

My personal preference would be to go into the Weblate direction (I’m pl contributor and coordinator). Also @rffontenelle (pt-br contributor and Transifex projects admin) and @josix (zh-cn contributor) expressed interested so far in this switch (we didn’t discuss it in a place as such so far). I don’t have a personal preference between self-hosted or Hosted Weblate, both would be OK for me.

Nevertheless current situation with propagation issue is not optimal, and I think we should act in any way (minimal step being discussion about Transifex Premium plan).

I’d love to hear what the community thinks about it. Also I am open to discuss more alternatives or elaborate in more detail on any aspect of the topic if needed.

Thank you!

  1. Other language teams work with Git-based flow and local PO files editors or are just starting the translation projects. ↩︎

3 Likes
2

GNU Mailman was one of the first internationalized Python projects that I’m aware of. As part of that work, I wrote the gettext library, flufl.i18n, and Tools/i18n [1]. GNU Mailman uses Weblate to manage its translations.

  1. with help from many others along the way ↩︎

2 Likes
3

OpenStack also used Transifex once upon a time, but following some
(much earlier) unfavorable changes in its terms of service we
migrated to an instance of the then-Red-Hat-maintained Zanata
software which we ran ourselves on donated virtual machines. Some
years later RH abandoned development on Zanata, so we’ve been
limping along with some ugly workarounds to mitigate security
vulnerabilities in it.

More recently, we’ve begun work on migrating to a hosted instance of
Weblate, and our string count is similarly too high to qualify for
the free tier, but as we’re also a community-developed open source
project they were willing to negotiate a generous discount on the
normal hosting costs. Time will tell how we get on with the
platform, but our friends in the Fedora community moved from Zanata
to Weblate some time ago and seem quite pleased with it.

2 Likes
4

Here for the french translation we don’t use web hosted tools (besides gitea/github), so we implemented a command line tool to “copy” translations from one branch to another: pomerge.

Typical usage:

pomerge --from-files *.po */*.po
git switch another_branch
pomerge --to-files *.po */*.po

So I bet you could stick to transifex and use pomerge as a memory?

(Don’t misread me, I’m against using closed-source software like transifex (or github) to do open-source software).

1 Like
5

Yes, we have an open issue and a plan to implement and use it this way (through the scripts and CI in python-docs-tx-translations repository).

Although: we have translators lists at the top of every PO file. An example looks like this:

Without shared memory download and upload features in Transifex (it’s now limited for open-source projects) we are not able to keep this behavior. Merging the PO files locally (or in CI) and uploading them back to Transifex attributes the translations to the uploader. This makes the proposed approach a not ideal workaround.

By the way, behavior of maintaining the list of translators this way is also supported in Weblate through the contributors in comment add-on.

6

Posting a status update about the Python docs / Weblate integration. Currently I’m working on support of multiple versions of Python through newly-added Weblate categories.

3 Likes