Re: Git access for translators



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 mustieles 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

2018-09-04 9:18 GMT+02:00 Carlos Soriano <csoriano 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 <csoriano 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-i18n gnome org
https://mail.gnome.org/mailman/listinfo/gnome-i18n




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]