rffontenelle / python-docs-tx-translations

Translating Python Docs in Transifex
https://explore.transifex.com/python-doc/
10 stars 1 forks source link

Implementing the propagation automation between python-doc org's Transifex projects #30

Closed rffontenelle closed 1 year ago

rffontenelle commented 1 year ago

We learned that Transifex stopped propagating translations between projects of a organization. To enable it, python-doc organization would have to sign up for a Premium plan ($$$$).

So right now, translations contributed to the main Python project (slug "python-newest") will not be automatically reused by the versioned projects in this same organization (slugs python-311, python-310, etc.).

How to solve this problem?

I'm discarding the option of duplicating, triplicating efforts of translating more than one project, because Python documentation has about 24K strings (yeah, twenty four thousands). Let's talk about scripting then.

A script has to be made to pull translations for the current translation version, and merge them in older versions. This would should be used by/in every team.

pomerge looks an awesome tool for the job, as it allows merge translated string into different branches.

git switch 3.12   # current translation branch
pomerge --from-files *.po **/*.po
git switch 3.11    #older translation branch
pomerge --to-files *.po **/*.po

pomerge also has a --no-overwrite flag to consider. When used, merging translations will not overwrite already translation strings.

Who should run the propagation automation?

Handling this task of propagation automation to the python-doc organization administrator (me) would centralize the effort hence making it easier for the translation teams, but by pushing the merged translations back to Transifex would add my username as translation in teams' translation files.

By leaving to the teams to automatize the propagation could result in different implementations and different bugs, which would multiply the effort of propagating translations. On the bright side, they could implement in their own way, and not have my username as translator.

For the second option, we could come up with a script that would make everyone happy and this be presented in an announce of some kind.

Ideas are welcome.

m-aciek commented 1 year ago

We learned that Transifex stopped propagating translations between projects of a organization.

Basing on the answer from Transifex representative and the coocurence with old CLI/API closure date I suppose that one of translations teams was running the propagation script basing on downloading and uploading TMX translation memory files from newset to older versions' projects for all languages. I would bet for one of Japanese or Traditional Chinese teams? (They had active maintainers and admins in TX.) I didn't find the script's source as a proof though.

Nevertheless it doesn't change much as we are blocked there.

I think the centralized script for the propagation is the best feasible solution in current sitation (or until we figure out/finish switching to Weblate which would have it solved). Having different static account as the memory propagator doesn't solve the issue of losing the original authorship. We should track now the translators only for the main project.

m-aciek commented 1 year ago

For what it's worth I've spent a while searching for the propagation script somewhere (didn't find it) and later on looking through Transifex configuration and docs, and I'm back supposing that it was Transifex's feature back then.