Re: Git access for translators
Le 06. 09. 18 à 10:00, Carlos Soriano a écrit : ... 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. The main issue here is that some (many?) modules have no CI configured or the pipelines do fail for a long period of time. Then, we know that some maintainers do not care much for i18n, which mean that MRs may rot in those situations. This could be tested on some chosen modules, though. - 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? This plan (more or less) makes sense to me. "doable" is not the real question, development time and resources is. I'm available to mentor potential contributors, but I'm afraid not being able to develop myself all these functionalities on my free time, at least not in the short term. Claude -- www.2xlibre.net ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Git access for translators
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 : > 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 wrote: > >> 2018-09-04 9:45 GMT+02:00 Carlos Soriano : >> > 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
Re: Git access for translators
> > 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 wrote: > 2018-09-04 9:45 GMT+02:00 Carlos Soriano : > > 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
Re: Git access for translators
Þann þri 4.sep 2018 19:15, skrifaði Daniel Mustieles García via gnome-i18n: Ok so just to clear things and not to start a flame-war, I just want to use my script to commit a bunch of translations, only that. If i have to commit 20 PO files with just one string modified throught DL I will simply ignore them because all the click-work needed to do it it's not worth for me. +1 Upload of multiple files at once is crucial for language coordinators; regularly we have to introduce new/better terms/wordings *all over* the project. Not to mention cases like when someone replaces project-wide all triple points [...] with real ellipsis […], leaving hundreds of otherwise correct strings fuzzy - this has happened in other projects I've been working on. I only aim to work in translations and make my work as efficient as possible. Dont mind I have Git access or web access, but if I have to spend more time doing the commits manually than translating maybe we are doing something wrong. I agree we have always tried to reduce git access, but I think this case is more than justified to have it. And if you try the script to commit translations you will problably want to have git access to use it and not waste your time. Can you provide this features in DL today? API seems not be able to do that, so sorry for disagreeing again with you but currently DL is not usable for us to cover our needs. Best would be to add this feature through DL; Transifex has it via the tx-client, Pootle allows uploading of multiple ZIP-ed files (beware of keeping the file structure intact), KDE has synchronization via SVN. Most of the web-translation interfaces (Transifex, Crowdin, Weblate, etc.) also have a more/less functional search/replace for whole projects, which may in some cases might be substitute for multiple-file commits. Best regards, Sveinn í Felli Regards 2018-09-04 20:42 GMT+02:00 Alexandre Franke : On Tue, Sep 4, 2018 at 8:10 PM Daniel Mustieles García < daniel.mustie...@gmail.com> wrote: El mar., 4 sept. 2018 17:50, Alexandre Franke escribió: On Tue, Sep 4, 2018 at 9:30 AM Daniel Mustieles García via gnome-i18n < gnome-i18n@gnome.org> wrote: Damned lies has an API and your script could use it. If the API is not enough, we can extend it. Where is it documented? https://wiki.gnome.org/DamnedLies#XML_interfaces It doesn’t have any workflow actions exposed yet (so no commit), but that can probably be added. Is it compatible with bash scripts? It is a Web API. From bash you can use e.g. curl to make the calls. I've been using this script for several years without any problem, also mi Git access, and never received any disclaim about it, but thanks if I fixed a wrong string in docs... if game rules have changed due to gitlab migration maybe someone should explain them clearly... Don’t act as if we never said anything about trying to reduce direct repository access. We have always been trying to avoid giving access unless really necessary, and done everything we could to reduce cases where it was necessary. Rules have not changed, we just now have betters tools to enforce them. and then I could explain why this script is very useful for translators :-) I’m not claiming it is useless, but it is not the right way to do it. -- Alexandre Franke GNOME Hacker ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Git access for translators
Ok so just to clear things and not to start a flame-war, I just want to use my script to commit a bunch of translations, only that. If i have to commit 20 PO files with just one string modified throught DL I will simply ignore them because all the click-work needed to do it it's not worth for me. I only aim to work in translations and make my work as efficient as possible. Dont mind I have Git access or web access, but if I have to spend more time doing the commits manually than translating maybe we are doing something wrong. I agree we have always tried to reduce git access, but I think this case is more than justified to have it. And if you try the script to commit translations you will problably want to have git access to use it and not waste your time. Can you provide this features in DL today? API seems not be able to do that, so sorry for disagreeing again with you but currently DL is not usable for us to cover our needs. Regards 2018-09-04 20:42 GMT+02:00 Alexandre Franke : > On Tue, Sep 4, 2018 at 8:10 PM Daniel Mustieles García < > daniel.mustie...@gmail.com> wrote: > >> El mar., 4 sept. 2018 17:50, Alexandre Franke >> escribió: >> >>> On Tue, Sep 4, 2018 at 9:30 AM Daniel Mustieles García via gnome-i18n < >>> gnome-i18n@gnome.org> wrote: >>> Damned lies has an API and your script could use it. If the API is not >>> enough, we can extend it. >>> >> >> Where is it documented? >> > > https://wiki.gnome.org/DamnedLies#XML_interfaces > > It doesn’t have any workflow actions exposed yet (so no commit), but that > can probably be added. > > >> Is it compatible with bash scripts? >> > > It is a Web API. From bash you can use e.g. curl to make the calls. > > >> I've been using this script for several years without any problem, also >> mi Git access, and never received any disclaim about it, but thanks if I >> fixed a wrong string in docs... if game rules have changed due to gitlab >> migration maybe someone should explain them clearly... >> > > Don’t act as if we never said anything about trying to reduce direct > repository access. We have always been trying to avoid giving access unless > really necessary, and done everything we could to reduce cases where it was > necessary. > > Rules have not changed, we just now have betters tools to enforce them. > > >> and then I could explain why this script is very useful for translators >> :-) >> > > I’m not claiming it is useless, but it is not the right way to do it. > > -- > Alexandre Franke > GNOME Hacker > > ___ > gnome-i18n mailing list > gnome-i18n@gnome.org > https://mail.gnome.org/mailman/listinfo/gnome-i18n > > ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Git access for translators
Just some notes from Serbian translation team. It is nice to have a tool such as Damned Lies and we would love if it can grow to a point that all the translation can be done through a web interface (like transifex for example). On the other hand, DL functionality is very limited, especially when documentation comes into play. I guess you should focus on adding all the features we need before forcing translators to use half-made product. I. e. forcing a translator to use DL API for scripting that does not commint translations to GIT? Are you sereious? :) ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Git access for translators
On Tue, Sep 4, 2018 at 8:10 PM Daniel Mustieles García < daniel.mustie...@gmail.com> wrote: > El mar., 4 sept. 2018 17:50, Alexandre Franke > escribió: > >> On Tue, Sep 4, 2018 at 9:30 AM Daniel Mustieles García via gnome-i18n < >> gnome-i18n@gnome.org> wrote: >> Damned lies has an API and your script could use it. If the API is not >> enough, we can extend it. >> > > Where is it documented? > https://wiki.gnome.org/DamnedLies#XML_interfaces It doesn’t have any workflow actions exposed yet (so no commit), but that can probably be added. > Is it compatible with bash scripts? > It is a Web API. From bash you can use e.g. curl to make the calls. > I've been using this script for several years without any problem, also mi > Git access, and never received any disclaim about it, but thanks if I fixed > a wrong string in docs... if game rules have changed due to gitlab > migration maybe someone should explain them clearly... > Don’t act as if we never said anything about trying to reduce direct repository access. We have always been trying to avoid giving access unless really necessary, and done everything we could to reduce cases where it was necessary. Rules have not changed, we just now have betters tools to enforce them. > and then I could explain why this script is very useful for translators :-) > I’m not claiming it is useless, but it is not the right way to do it. -- Alexandre Franke GNOME Hacker ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Git access for translators
El mar., 4 sept. 2018 17:50, Alexandre Franke escribió: > On Tue, Sep 4, 2018 at 9:30 AM Daniel Mustieles García via gnome-i18n < > gnome-i18n@gnome.org> wrote: > >> 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. >> > > Damned lies has an API and your script could use it. If the API is not > enough, we can extend it. > Where is it documented? Is it compatible with bash scripts? I've been using this script for several years without any problem, also mi Git access, and never received any disclaim about it, but thanks if I fixed a wrong string in docs... if game rules have changed due to gitlab migration maybe someone should explain them clearly... and then I could explain why this script is very useful for translators :-) > > In my personal case I've also fixed wrong strings in documentation or >> commited patches into several modules, so I needed Git access. >> > > No, you don’t. For those you can do a Merge request just like anyone else > would. > > -- > Alexandre Franke > GNOME Hacker > ___ > gnome-i18n mailing list > gnome-i18n@gnome.org > https://mail.gnome.org/mailman/listinfo/gnome-i18n > ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Git access for translators
2018-09-04 9:45 GMT+02:00 Carlos Soriano : > 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
Re: Git access for translators
On Tue, Sep 4, 2018 at 9:30 AM Daniel Mustieles García via gnome-i18n < gnome-i18n@gnome.org> wrote: > 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. > Damned lies has an API and your script could use it. If the API is not enough, we can extend it. In my personal case I've also fixed wrong strings in documentation or > commited patches into several modules, so I needed Git access. > No, you don’t. For those you can do a Merge request just like anyone else would. -- Alexandre Franke GNOME Hacker ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Git access for translators
On Tue, Sep 4, 2018 at 9:30 AM Claude Paroz wrote: > However, there are some cases where Damned Lies is not yet able to push > *new* translations. > Another case that you forgot about and which I also forgot about so far when replying to this topic is figures. We don’t have a way to upload images from DL, but that would be awesome to have! Bonus points if one can have the corresponding string translated in the process. > Note that there are more and more modules also using LINGUAS files for > docs, so this issue should be less important in the future. If the > release-notes build could be changed to use a LINGUAS file, it would be > great too. > Could Damned lies detect when that is the case and display a warning for those where it can not add the new translation? I thought all documentation were affected but if that’s not the case then I’ll start committing from DL for docs too when possible. > > > Also, it would be good to know if merge requests would be appropriate for > > this, instead of pure git access. > > It's a bit heavier than direct pushes, but IMHO it can be acceptable. > Agreed although I’d lean more on the “meh” side. -- Alexandre Franke GNOME Hacker ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Git access for translators
Claude, Em ter, 4 de set de 2018 às 04:30, Claude Paroz escreveu: > > Note that there are more and more modules also using LINGUAS files for > docs, so this issue should be less important in the future. If the > release-notes build could be changed to use a LINGUAS file, it would be > great too. > I proposed a merge request adding Meson support to Release Notes, using a LINGUAS file. Can you please verify if it is for Damned Lies? https://gitlab.gnome.org/Community/Engagement/release-notes/merge_requests/7 Best regards, Rafael Fontenelle ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Git access for translators
I use gtxml and msgfmt for checking PO files, but I disabled the gtxml check temporary because it returned false positives in the "translator-credits" line, but it detects wrong tags in documentation that might cause a crash when compiling the module. Of course, if there is any problem with a translation commit you can always ask this list and we will help you ;-) 2018-09-04 10:02 GMT+02:00 Carlos Soriano : > 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 >> > Interesting... what kind of tests are passed? We had an issue with > Nautilus one year ago or so with a translation commit. > > On Tue, 4 Sep 2018 at 09:57, Daniel Mustieles García < > daniel.mustie...@gmail.com> wrote: > >> >> >> 2018-09-04 9:45 GMT+02:00 Carlos Soriano : >> >>> 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 : >>>> >>>>> 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 >>>>> wrote: >
Re: Git access for translators
> > 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 > Interesting... what kind of tests are passed? We had an issue with Nautilus one year ago or so with a translation commit. On Tue, 4 Sep 2018 at 09:57, Daniel Mustieles García < daniel.mustie...@gmail.com> wrote: > > > 2018-09-04 9:45 GMT+02:00 Carlos Soriano : > >> 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 : >>> >>>> 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 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 >>>> >>>> >>> > ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Git access for translators
2018-09-04 9:45 GMT+02:00 Carlos Soriano : > 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 : >> >>> 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 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 >>> >>> >> ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
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.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 : > >> 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 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 >> >> > ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Git access for translators
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 : > 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 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 > > ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Git access for translators
Le 04. 09. 18 à 09:16, Carlos Soriano a écrit : 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? Hey Carlos, You are right in that *most* commits should be done through the Damned Lies interface. However, there are some cases where Damned Lies is not yet able to push *new* translations. Adding a new translation implies editing the LINGUAS file or variable to add the language code. For LINGUAS files, this is quite trivial and D-L is able to do it automatically. Unfortunately, and especially for help translations, LINGUAS is often a variable inside a Mafefile or a configure.ac file. In that case, automatic editing of the variable is tricky and I refrained programming that until now to avoid risking breaks in build processes. In those cases, "manually" committing is still the rule. Note that there are more and more modules also using LINGUAS files for docs, so this issue should be less important in the future. If the release-notes build could be changed to use a LINGUAS file, it would be great too. Also, it would be good to know if merge requests would be appropriate for this, instead of pure git access. It's a bit heavier than direct pushes, but IMHO it can be acceptable. Claude -- www.2xlibre.net ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Git access for translators
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 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
Git access for translators
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
