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? > 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... 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
