Re: Git access for translators

[Claude Paroz <claude 2xlibre net>]

Le 06. 09. 18 à 10:00, Carlos Soriano a écrit :
...
> Also, another thing I'm taking into account here is that there is a 
> strong desire by some maintainers to prevent any commit to go directly 
> to master by using GitLab's protected branches feature (not because of 
> translators, but generally). This is currently on hold due to blocking 
> translators using scripts.
>
> So I have been thinking on this and this is what I think we could do, 
> kinda in order:
> - Push harder to make all projects have LINGUAS file for the main 
> projects, and if missing and want to commit something, implement LINGUAS 
> file first to overcome the issue (how hard is that?).
> - Only have one or two people from the i18n team have developer access 
> to overcome Dammed Lies missing features such as uploading images from 
> DL when needed.
> - Implementing mass commit in DL, so translators used to commit by 
> script can use it.
> - Use GitLab API from Dammed Lies to create MRs and set the "merge 
> automatically when CI pipeline passes". From my experience, this is a 
> matter of 20 lines of Python code and I could help here.

The main issue here is that some (many?) modules have no CI configured 
or the pipelines do fail for a long period of time. Then, we know that 
some maintainers do not care much for i18n, which mean that MRs may rot 
in those situations. This could be tested on some chosen modules, though.

> - Maintainers will start protecting the master branch, translators will 
> use only DL. Trranslators with developer access will use MRs for e.g. 
> uploading pictures or other rarely used needs.
>
> Now, this depends on how doable you think modifying DL to implement 
> those is. If that's not doable, we can give up entirely and create a 
> GitLab group called "translation team" and maintainers could give 
> developer permissions to those to their projects.
>
> What do you think?

This plan (more or less) makes sense to me. "doable" is not the real 
question, development time and resources is. I'm available to mentor 
potential contributors, but I'm afraid not being able to develop myself 
all these functionalities on my free time, at least not in the short term.

Claude
--
www.2xlibre.net