Switch to using Weblate

[m-aciek]

Transifex:

• doesn't support translation memory download/upload between projects in the open-source plan since October 2022
• doesn't support machine translation as suggestions (Consider setting up machine translation #18),

One of options is to switch to Weblate (which supports both machine translations as suggestions and global translation memory propagation). Weblate has very good version control system integration – this switch would also solve #14 plus would remove the necessity of maintaining scripts to fetch the translations.

This issue is to track blockers for migrating the translation project to Weblate.

• updating translation source strings along with English original documentation changes
  • to be implemented by ourselves on repository side,
• Allow per-language Git repositories WeblateOrg/weblate#7271 – one target repository per language is not supported – validation for file mask in the target repository requires a placeholder with a language code,
• translation propagation between different Python versions
  as we would set up a project per Python stable version, we'd like to have working translation propagation between the projects
  • confirm Autotranslate add-on solves it
• Nested projects or project grouping WeblateOrg/weblate#263

[comradekingu]

Happy to help

[m-aciek]

I think the action point here for now is to create a feature request in Weblate for allowing the target repository to not have a language code in the filename pattern (second point from the list of blockers in the issue description). Point first and three should be possible to implement as GitHub Actions scripts.

[m-aciek]

I've added proof-of-concept repository and successfully pushed the first change: https://github.com/m-aciek/python-docs-pl-weblate-poc (https://hosted.weblate.org/projects/python-docs/). I've updated original issue with refined points that still require an effort. I think of scripts being fired with GitHub Actions for both updating source strings and translations propagation.

[m-aciek]

Translation propagation between components will be handled by Autotranslate add-on.

Discovery for adding or removing components will be handled by Discovery add-on.

[m-aciek]

According to this discussion setting up Autotranslate between projects (Python versions) is also possible.

[comradekingu]

@m-aciek
Population between components "spreading of translations" can be set up in https://hosted.weblate.org/settings/python-docs/bugs//#translation if that is the component the others are mirrored from. (Or individually per component where desirable.)

There is also the shared translation memory between other projects on Hosted Weblate, which can be turned on in
https://hosted.weblate.org/settings/python-docs/#workflow

---

Don't use CC0, it is not advisable. It is also not the license used for the documentation already.

This file is distributed under the same license as the Python package.

from https://github.com/python/python-docs-pl/blob/3.10/copyright.po

https://github.com/python/cpython/blob/main/LICENSE#L65

---

If you add "kingu" in https://hosted.weblate.org/access/remmina/#users I can see if I find other improvements to be made. :)

[m-aciek]

Population between components "spreading of translations" can be set up in https://hosted.weblate.org/settings/python-docs/bugs//#translation if that is the component the others are mirrored from. (Or individually per component where desirable.)

I already found and did that 👍 .

@comradekingu do you know if we add a separate project for Python 3.9 documentation translation, will we be able to set automatic propagation from Python 3.10 project? (Not only having a translation memory as a suggestions.) I wonder if this feature is visible when you have admin privileges to two projects (WeblateOrg/weblate#7200 seems to suggest that).

Don't use CC0, it is not advisable. It is also not the license used for the documentation already.

From what I understand the license of translations may be a bit different than the license of the original documentation. The PEP 545 suggests to use CC0. If needed we can/should discuss it further on Python documentation Discourse section.

I can see if I find other improvements to be made. :)

Sure, I've added you as an administrator.

[comradekingu]

The setup worked just fine, but the grace period timed out.
I meant to do this, but the date I had in my head was the expiry.
I suggest putting it up again and then requesting approval.

@m-aciek
Yes, it is possible to turn on sharing between components.
CC0 is a disaster. For collaborative works it does nothing to further move it towards the public domain in any usable sense, but it incurs every bit of legal trouble from doing it effectively part-way for different and incompatible jurisdictions.
Just use the license the software itself has.

[m-aciek]

I suggest putting it up again and then requesting approval.

According to this comment by nijel, our request would be put down, at least until WeblateOrg/weblate#7271 is done.

CC0 is a disaster. For collaborative works it does nothing to further move it towards the public domain in any usable sense, but it incurs every bit of legal trouble from doing it effectively part-way for different and incompatible jurisdictions.

Do you maybe have some external resource with the critique of CC0 in a context of similar works like this translation? I'd be keen to get to know more.

For what it's worth on main branch of this repository I started trying to put together a GitHub Action to update translations source strings.

[comradekingu]

@m-aciek

https://rd-alliance.org/sites/default/files/cc0-analysis-kreuzer.pdf
https://www.ivir.nl/publicaties/download/KnowRight08_Paper.pdf
https://halshs.archives-ouvertes.fr/halshs-00671622/document
https://wiki.osmfoundation.org/w/index.php?title=Licence/Licence_Compatibility&mobileaction=toggle_view_desktop#CC0

It always stops at the "what did you think you were doing" stage, and it is never popular, with nobody using it for collaborative works at scale, or with success at a smaller scale.

I couldn't find the one that hits the nail on the head, but basically moral rights can't be waived in some jurisdictions,
and the terms for actual public domain, which is both possible and not, differ.
You thereby get inalienable copyright, mixed in with a lot of non-endgame. The winning move is not to play, even though it somewhere down the road could make sense. It seeks no protections, and finds itself challenged by the protections it could have used. It is buying into the results of downfall of the commons as if it prevents it somehow.
My opinion is that copyright protection is better, even if it were possible.
TL;DR Collaborative works thereby get every bit of legal pain incurred in the differences, with no functional upside as a result.

https://www.gnu.org/licenses/license-recommendations.html is a particularly bad recommendation, and they also championing waiving copyright for translations.
In my opinion a better CLA system for maintainership is warranted, and it should be in the license.
Something along the line of it will be like this, but possibly have more protections/restrictions to that end.
That is another in-process discussion.

[m-aciek]

Another blocker (?) on Weblate side: WeblateOrg/weblate#263.

[rffontenelle]

How about presenting to all translation teams a migration to a single workflow using Weblate? If accepted by teams and by Python core devs, this would eliminate per-team customized scripts and would land translations directly in the main repository (or another suffixed with e.g. "-doc-translations" of their choice).

For PyPA (PyPI website/warehouse and the packaging guide) it is working fine.

One thing I know is that French teams gives great importance to FLOSS, so the Hosted Weblate linked with several machine translations might be a problem. So self-hosted weblate could be a solution. I wanted to present a proof-of-concept of a Weblate instance for python docs translations using Yunohost, but never went further.