I would like to propose three modifications to PEP 545. Their implementations have been split in to separate PRs and should be reviewed separately (so that one rejected suggestion doesn’t block the rest):
While maintaining translation quality is primarily up to the coordinator,
the translation should aim for a similar level of quality as that of the English
documentation. Machine translations that have not been reviewed by a human are
not allowed.
I believe this is important so that the standards of the Python docs do not degrade, especially with the current developments of AI which may seem temping to use. (It’s getting better at translating, but it’s still not great, it needs supervision)
Translations are overseen by the :pep:Editorial Board <732#scope>.
but it is intended that each language team remains as autonomous as possible.
Inactive Coordinators
If a coordinator is inactive for a year and does not respond within a two weeks to a
check-in issue on their translations issue tracker the coordinator will be marked
as inactive.
They will be moved to an “Inactive Coordinators” section on the devguide translations
page and the translation will be free to claim by anyone willing to coordinate by
opening a PR in the devguide repository adding themselves as coordinator.
The translation may also be temporarily managed by a user willing to maintain it
ideally with previous coordination experience.
(propagating translations, managing CI workflows, accepting PRs, etc.)
Mar 7, 21:23: changed notification period from one week to two weeks
This addition mainly focuses on what to do when a translation is abandoned and it will be helpful for future additions if other issues arise.
The devguide lists several contributors who have been inactive for well over a year and some who have not made any start to the translation whatsoever! This means the translation is out of date, when it could easily be pushed to newer branches, people are unable to contribute, for who is going to merge prs!, new contributors won’t join if there is no promotion and other problems.
For example:
The Bengali Translation, was claimed several years ago and not a commit in sight! It prevents people who wish to become coordinator and translate from doing so.
Hungarian Translation, not updated for 7 years, branch well out of date.
Indonesian translation, a contributor is yet again blocked.
Russian and others similar thing, you can see the dashboard for inactive translations
Finding new translators is difficult. For this reason the devguide’s *help-documenting* page <https://devguide.python.org/documentation/help-documenting/>_
will have a section on Translating. On https://docs.python.org when on a translation
(/lang) the footer will include the link: “Help Translating” that will link to
the translations contributing guide.
I work on the PL translation and it is difficult to get new translators, it is also not easy for people who would like to help to find out how to do so!
There is no direct link to the translation repo in docs and the link that leads you to a page about contributing in the devguide also does not mention it! (And navigating the devguide is not the easiest)
I also have another pr with a few minor suggestions (update links http → https, and update b.p.o. → github issue tracker).
I suggest 2 weeks instead of 1. If it is inactive, one more week won’t make much difference.
Also, how about marking the language team as “needing coordinator” and remove the name of the coordinator instead of marking the coordinator as inactive? Both mean the same thing, but I believe my suggestion has a more positive point of view.
Hi! Thank you for looking into this, and identifying areas where the translation process can be improved.
I think this has been submitted to the SC (python/steering-council#284) a little early: this thread has only been open a week, with only one comment, and the draft PRs haven’t been updated with the suggestions – it’s not clear which versions you are asking the SC to decide upon.
I do think we need some process around inactive translations and how to assign a new co-ordinator, this is something not currently in the PEP.
The Bengali and Indonesian issues have been open for less than two weeks. I think we have to mindful that most open source is done by volunteers, and real life happens. Plus translating is a lot of work, especially if done by a single person. Rather than removing people, can we find a way for people to work together?
I agree one week is too short.
They will be moved to an “Inactive Coordinators” section on the devguide translations page and the translation will be free to claim by anyone willing to coordinate by opening a PR in the devguide repository adding themselves as coordinator.
What’s the purpose of listing inactive coordinators?
The translation may also be temporarily managed by a user willing to maintain it
ideally with previous coordination experience.
(propagating translations, managing CI workflows, accepting PRs, etc.)
What defines a temporary manager from a regular coordinator? Are there any time limits?
I’m not sure we need to update the PEP to prescribe making updates to the devguide and docs, I think we could address these directly through PRs/issues?
Your first point I will answer with two of your own quotes
Rather than removing people, can we find a way for people to work together?
What’s the purpose of listing inactive coordinators?
real life happens
Yes it does, so maybe with an easier process of replacement it may be less of a burden. If they are busy why should it block someone who is not?
I agree one week is too short.
I updated it in my submission to the SC and in the preview here.
What defines a temporary manager from a regular coordinator? Are there any time limits?
Its just somewho who wishes to help out but cannot be a real coordinator (e.g. they don’t speak the langauge) the time limit is till a proper coordinator is found or they get tired
I’m not sure we need to update the PEP to prescribe making updates to the devguide and docs, I think we could address these directly through PRs/issues?
Historically that has gone poorly…
I thought that with SC approval it may be a bit easier.
