2018-09-04 9:45 GMT+02:00 Carlos Soriano <csori...@gnome.org>: > Thanks for the answers! > > > LINGUAS is often a variable inside a Mafefile or a configure.ac file > Indeed. One option for that is to have one or two people from i18n have > access to some projects to fix that. > > > Note that there are more and more modules also using LINGUAS files for > docs, so this issue should be less important in the future > That's good to hear! > > > but some translators (me, for example) might use an automated script (1) > to push a bunch of translations instead of doing it one by one in Damned > Lies, which implies so much click-work to upload and commit a PO file into > a single module. > Is it possible for the script to interact directly with Dammed Lies > instead of directly git? >
No AFAIK... another possible solution would be implement the mass-commit feature in Damned Lies, but dont know hoy difficult would it be > > > About merge requests I don't know exactly how it works, but I don't > consider it be necessary for translations. It could also generate a > high-traffic for maintainers and delay translators daily work. > 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... > Damned Lies ald my script does such tests, but the case we have had with GIMP headers has not been detected... maybe test tools don't consider it a wrong line, when they should > > Another option is to create a translation team and giving that team > developer access to some modules. Ideally this translation team would be > only the people that really needs git access and others would use Dammed > Lies. > > On Tue, 4 Sep 2018 at 09:30, Daniel Mustieles García < > daniel.mustie...@gmail.com> wrote: > >> Hi Carlos, >> >> Yes, translators are encouraged to use Damned Lies instead of accesing >> Git directly, but some translators (me, for example) might use an automated >> script (1) to push a bunch of translations instead of doing it one by one >> in Damned Lies, which implies so much click-work to upload and commit a PO >> file into a single module. >> >> Of course this is a very isolated case, since not all translators use >> this kind od tools nor need access to git. In my personal case I've also >> fixed wrong strings in documentation or commited patches into several >> modules, so I needed Git access. >> >> About merge requests I don't know exactly how it works, but I don't >> consider it be neccesary for translations. It could also generate a >> high-traffic for maintainers and delay translators daily work. >> >> Best regards >> >> (1) - https://github.com/dmustieles/gnome_scripts/blob/master/gttk.sh >> >> 2018-09-04 9:18 GMT+02:00 Carlos Soriano <csori...@gnome.org>: >> >>> Also, it would be good to know if merge requests would be appropriate >>> for this, instead of pure git access. >>> >>> On Tue, 4 Sep 2018 at 09:16, Carlos Soriano <csori...@gnome.org> wrote: >>> >>>> Hello all, >>>> >>>> Recently we had a bit of scramble with the release notes and some >>>> translators not having git access to it. >>>> >>>> If I remember correctly translators are encouraged to not push directly >>>> and use Dammed Lies instead, if I remember correctly doing otherwise is >>>> unsupported. >>>> >>>> However, some translators mentioned they usually do it this way and >>>> they usually get access. >>>> >>>> I would need some clarification on this so we know what project/group >>>> permission set up is fit for translators. Can someone explain the current >>>> situation? >>>> >>>> Thanks! >>>> Carlos Soriano >>>> >>> >>> _______________________________________________ >>> gnome-i18n mailing list >>> gnome-i...@gnome.org >>> https://mail.gnome.org/mailman/listinfo/gnome-i18n >>> >>> >>
_______________________________________________ engagement-list mailing list engagement-list@gnome.org https://mail.gnome.org/mailman/listinfo/engagement-list
