Note that not only LINGUAS file is a pain to add new languages... Makefile file for documentation is even more difficult to parse as it's not always in the same way, and it's needed to add a new language for documentation.
This case should be also considered Cheers! 2018-09-06 10:00 GMT+02:00 Carlos Soriano <csori...@gnome.org>: > Of course, if there is any problem with a translation commit you can >> always ask this list and we will help you ;-) > > Right, the goal is to not break on pre-merge though. But since this seems > quite rare to happen... it's probably not a big deal. > To add more weigh into this, recently I also had another problem in > Nautilus, a translator committed using a quite old "merge commit" and the > commit was actually wrong, that really made reverting that commit very > complex. This kind of errors are prevented by GitLab MR + CI too. > > >> I thought the git hooks we had that run msgfmt -c on translations >> during push are still working in GitLab? >> > Yes they are, I think this happened before GitLab, like a year ago or so. > What kind of breakages does msgfmt catch? > > 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. > - 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? > > Cheers > > On Tue, 4 Sep 2018 at 18:13, Piotr Drąg <piotrd...@gmail.com> wrote: > >> 2018-09-04 9:45 GMT+02:00 Carlos Soriano <csori...@gnome.org>: >> > Yeah... on the other hand I think most of FOSS projects do it this way >> > nowadays, at least in things like GitHub, etc. Another thing to >> consider is >> > that translationa can break the code, maybe a good option is that >> > translations need to pass CI before being committed? In that case MR >> could >> > be the best way to do that. >> > Most probably this is a longer discussion to have though... >> > >> >> I thought the git hooks we had that run msgfmt -c on translations >> during push are still working in GitLab? >> >> Best regards, >> >> -- >> Piotr Drąg >> https://piotrdrag.fedorapeople.org >> >
_______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
