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?CheersOn Tue, 4 Sep 2018 at 18:13, Piotr Drąg <piotrdrag gmail com> wrote:2018-09-04 9:45 GMT+02:00 Carlos Soriano <csoriano 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