Re: Help needed for user manual translation
Hi, On Thu, 2018-09-06 at 22:00 +0530, Snehalata Shirude wrote: > I downloaded gimp repository from git... > Followed steps I found like > Modified configure.ac file by adding mr I assume you did not download the "gimp" repository but "gimp-help". > Put po files in po folder > Then run autogen.sh > Then trying to use make html-mr command to see the translation on > local machine Are you following https://gitlab.gnome.org/GNOME/gimp-help/blob/master/TRANSLATING ? If so, you want to mention that for clarity. > But its giving error make: *** No rule to make target ' > Can anybody will help to solve this? Please provide the lines before that error, for example by posting the complete output to paste.gnome.org and providing a link here. andre -- Andre Klapper | ak...@gmx.net https://blogs.gnome.org/aklapper/ ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Help needed for user manual translation
Hi I downloaded gimp repository from git... Followed steps I found like Modified configure.ac file by adding mr Put po files in po folder Then run autogen.sh Then trying to use make html-mr command to see the translation on local machine But its giving error make: *** No rule to make target ' Can anybody will help to solve this? Snehalata ___ 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
