Hi; to be brutally honest, as a maintainer I don't want any translator to commit directly to Git—unless it's done to a separate branch and/or through merge requests.
Translators do not build the projects they translate, and they don't (or cannot) know when they break things. The only way maintainers know that a broken translation happened is that suddenly the CI mails us, and then we have to hunt down what happened behind out backs. This is even worse when you realise something has broken a long time ago because the release process is now impossible. I'd rather have an automated, web UI tool that pushed changes to a branch and opened a merge request that ran the CI pipeline (and maybe the dist process), than allowing translators to commit to Git directly. I don't really care if some translator is an old hand that was around when GNOME used CVS and scripted their way to push to dozens of repositories at once; we started using a lot of tooling to ensure things don't break, and even developers have started pushing things to development branches instead of committing directly to master. I don't see why translators have to be the special snowflakes of the whole GNOME project, and break stuff for everyone else just because of their 20 years old workflow. Ciao, Emmanuele. On Mon, 22 Jun 2020 at 11:03, Daniel Mustieles García via gnome-i18n < gnome-i18n@gnome.org> wrote: > Some time ago I talked about this with +Carlos Soriano > <csori...@gnome.org> . I asked him about the possibility of creating a > user's group in Gitlab, formed by some team coordinators, which will have > commit rights to be able to commit a bunch of translations due to the heavy > clickwork must be done in DL. Still waiting... > > Me (and some other team coordinators) got Git access before migration to > Gitlab, and it was not a problem. Having such rights will help us a lot to > be more agile maintaining and commiting translations. Yes, I currently have > those rights and can use an automated script [1] to ease my life, but I > don't have commit rights in some new modules (app-icon-preview, > shortwave...). I'd like to formerly request this feature/rigths. If we > found any problem with a wrong commit or something like that is quick and > easy to revert that commit; if a user with rights uses them for other > things that translations is quick and easy to revoke those privileges. > Advantages for us to maintain and keep translations up-to-date are huge. > > Please consider this request and let's work together to make it possible > in the best way. > > Best regards. > > [1]https://github.com/dmustieles/gnome_scripts/blob/master/gttk.sh > > El dom., 21 jun. 2020 a las 20:43, Matej Urban via gnome-i18n (< > gnome-i18n@gnome.org>) escribió: > >> Hello, >> some time ago I complained about inability to commit damned-lies package >> due to wrong access rights. Ok, I can live with that, but lately I get this >> error on many, many packages, especially new ones, like: >> >> app-icon-preview, authenticator, fractal, fragments, gnome-keysign, >> obfuscate, shortwave ... list goes on >> >> Is there any special reason why not even coordinators are able to do that >> the usual way? Yes, I know, there is another way to do it, but it is >> cumbersome and takes a lot, lot, lot time to do it and what is more >> important, each project has some specifics. For this reasons I do not push >> these ... >> >> Please advise or better, please bend at least for coordinators these >> rules. >> >> Thank you, >> Matej >> >> >> _______________________________________________ >> gnome-i18n mailing list >> gnome-i18n@gnome.org >> https://mail.gnome.org/mailman/listinfo/gnome-i18n >> > _______________________________________________ > gnome-i18n mailing list > gnome-i18n@gnome.org > https://mail.gnome.org/mailman/listinfo/gnome-i18n > -- https://www.bassi.io [@] ebassi [@gmail.com]
_______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
