Re: gnome-devel-docs on developer.gnome.org
On Fri, 2014-05-09 at 21:08 +0200, Ask Hjorth Larsen wrote: Hello everyone First of all I am very willing to implement a mode in gtxml specifically for this. Fixing the translator-credits issue is obviously very easy. I can make it so that gtxml will only complain about syntax errors, i.e. strings that are not accepted by the xml parser. This requires that all msgids and msgstrs - except the header and translator-credits - can be assumed to be XML. The files also contain media links to images/videos with their md5 hashes. Perhaps a special check should be made for those, since they are probably not required to be legal XML. Are there other classes of strings to be aware of? Is all this acceptable? Also, who could actually approve this and make it run on the server? For any special strings that don't correspond directly to some content, itstool always uses msgctxt _. So at least for itstool-generated PO files, you could ignore any messages with msgctxt _. Right now gtxml can to various extents be smarter and detect more errors - e.g. whether unexpected XML tags are used. But some translators tend to insert their own little xml things when they want, which is fine by itself, but can lead to false positives when attempting to be too smart. What happens with placeholder tags (such as _:ulink-1, _:ulink-2 and so on), how bad is it if those are messed up? For any placeholder tags, itstool always uses the namespace prefix _. (It does an internal mapping of this to a namespace URI, which nobody should bother caring about (and yes, a known limitation of itstool is that it will do bad things if you use _ as a namespace prefix in your source documents.)) Messages with placeholders should always be well-formed. It would be nice to check that the placeholder elements in the source message line up with those in the translated message. Other XML-PO tools could do things completely differently. xml2po does not use a special msgctxt or namespace prefix for anything. But people should stop using xml2po anyway. I think KDE has their own tool. They should probably just use itstool too. I'm not sure what Okapi does, but it's targeted at XLIFF anyway, and its PO exporter is a bonus feature that I'm not sure many people use. There are probably other tools I don't know about. I saw a svg2po once somewhere. They should really just use itstool too. Extra bonus side note: I've asked the gettext maintainers before about adding a flag to identify XML content, like: #, xml-fragment It's been a while since I bugged them about that. Then tools like gtxml could just look for messages with that flag. -- Shaun ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gnome-devel-docs on developer.gnome.org
Hi Ask. Now it's me who is answering too late... sorry. I guess we could integrate gtxml checks in git as pre-commit hook (like it's actually done with msgfmt to check integrity), but to do this we need to ensure it will not report false positives. If you can modify gtxml to ignore the translator-credits string and we can ensure it won't report false positives, I would vote for doing it. Altough it couldn't detect all the possible errors, will be better than nothing. What the other i18n members think about? As always, many thanks for your great work with this tool :) El 26/05/2014 21:22, Ask Hjorth Larsen asklar...@gmail.com escribió: Hello Daniel: Sorry for the late reply. gtxml presently assumes that strings by default should be valid xml, which was not the case in previous revisions. This probably explains the difference. Back in the days I don't think there were translator_credits strings in the docs, so this change could be made without getting into trouble - something which clearly isn't the case anymore. It's a simple matter to recognize the translator credits strings though. So in general: gtxml is not only meant for the GNOME docs, it's supposed to be a bit more generalist. An option or mode could be written (without much trouble at all) specifically for GNOME docs to weed out known false positives. If a powerful being confirms that a gtxml check is desired for the GNOME docs (and by powerful I mean someone who has the rights/expertise/etc. to get things to run on the server) then I will be glad to write a special mode. Regarding the placeholders: I don't know how to completely generally recognize a placeholder tag. I.e. whether, upon seeing a tag, it has to exist in the translation as well or not. For a placeholder the answer is yes. For another tag the answer is typically no. Best regards Ask 2014-05-13 11:33 GMT+02:00 Daniel Mustieles García daniel.mustie...@gmail.com: As I've commented to Christian Kirbach in private mail, when I generated the reports before a new stable release, I didn't get this kind of errors, so I'm really confused about what is happening. The only difference I see is that I used to generate them under Ubuntu 12, and now I'm using Debian... maybe it's due to Python versions? I'm installing a virtual machine to investigate it... Anyway... simply ignoring the translator-credits line would be enough to have good reports. Media links are not used at all in the PO files, so it doesn't matter how you translate them; about placeholders, they should placed in the right place, as they often indicate the kind of license or the name of the program, so they should be, at least, the same in the translated and in the original string (but not in the same order). Thanks to all of you for your comments (and special thanks to Ask for taking care of this :) ) Cheers! 2014-05-09 19:44 GMT+02:00 Rūdolfs Mazurs rudolfs.maz...@gmail.com: Pk, 2014.05.09. 16:51 +, Rafael Ferreira rakstīja: If someone that knows python3 could patch pyg3t to fix this, I think it would be a great tool for this XML validation... Someone? specifically in translator-credits strings, the e-mail is often put in angle brackets, which is not a valid XML. If the translator-credits string is parsed with XML, that IS a bug. Otherwise just skip the translator-credits string in the xml check. -- Rūdolfs Mazurs rudolfs.maz...@gmail.com ___ 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: gnome-devel-docs on developer.gnome.org
Hello Daniel: Sorry for the late reply. gtxml presently assumes that strings by default should be valid xml, which was not the case in previous revisions. This probably explains the difference. Back in the days I don't think there were translator_credits strings in the docs, so this change could be made without getting into trouble - something which clearly isn't the case anymore. It's a simple matter to recognize the translator credits strings though. So in general: gtxml is not only meant for the GNOME docs, it's supposed to be a bit more generalist. An option or mode could be written (without much trouble at all) specifically for GNOME docs to weed out known false positives. If a powerful being confirms that a gtxml check is desired for the GNOME docs (and by powerful I mean someone who has the rights/expertise/etc. to get things to run on the server) then I will be glad to write a special mode. Regarding the placeholders: I don't know how to completely generally recognize a placeholder tag. I.e. whether, upon seeing a tag, it has to exist in the translation as well or not. For a placeholder the answer is yes. For another tag the answer is typically no. Best regards Ask 2014-05-13 11:33 GMT+02:00 Daniel Mustieles García daniel.mustie...@gmail.com: As I've commented to Christian Kirbach in private mail, when I generated the reports before a new stable release, I didn't get this kind of errors, so I'm really confused about what is happening. The only difference I see is that I used to generate them under Ubuntu 12, and now I'm using Debian... maybe it's due to Python versions? I'm installing a virtual machine to investigate it... Anyway... simply ignoring the translator-credits line would be enough to have good reports. Media links are not used at all in the PO files, so it doesn't matter how you translate them; about placeholders, they should placed in the right place, as they often indicate the kind of license or the name of the program, so they should be, at least, the same in the translated and in the original string (but not in the same order). Thanks to all of you for your comments (and special thanks to Ask for taking care of this :) ) Cheers! 2014-05-09 19:44 GMT+02:00 Rūdolfs Mazurs rudolfs.maz...@gmail.com: Pk, 2014.05.09. 16:51 +, Rafael Ferreira rakstīja: If someone that knows python3 could patch pyg3t to fix this, I think it would be a great tool for this XML validation... Someone? specifically in translator-credits strings, the e-mail is often put in angle brackets, which is not a valid XML. If the translator-credits string is parsed with XML, that IS a bug. Otherwise just skip the translator-credits string in the xml check. -- Rūdolfs Mazurs rudolfs.maz...@gmail.com ___ 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: gnome-devel-docs on developer.gnome.org
As I've commented to Christian Kirbach in private mail, when I generated the reports before a new stable release, I didn't get this kind of errors, so I'm really confused about what is happening. The only difference I see is that I used to generate them under Ubuntu 12, and now I'm using Debian... maybe it's due to Python versions? I'm installing a virtual machine to investigate it... Anyway... simply ignoring the translator-credits line would be enough to have good reports. Media links are not used at all in the PO files, so it doesn't matter how you translate them; about placeholders, they should placed in the right place, as they often indicate the kind of license or the name of the program, so they should be, at least, the same in the translated and in the original string (but not in the same order). Thanks to all of you for your comments (and special thanks to Ask for taking care of this :) ) Cheers! 2014-05-09 19:44 GMT+02:00 Rūdolfs Mazurs rudolfs.maz...@gmail.com: Pk, 2014.05.09. 16:51 +, Rafael Ferreira rakstīja: If someone that knows python3 could patch pyg3t to fix this, I think it would be a great tool for this XML validation... Someone? specifically in translator-credits strings, the e-mail is often put in angle brackets, which is not a valid XML. If the translator-credits string is parsed with XML, that IS a bug. Otherwise just skip the translator-credits string in the xml check. -- Rūdolfs Mazurs rudolfs.maz...@gmail.com ___ 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-devel-docs on developer.gnome.org
Hi all, the gnome-devel-docs module is now shown in developer.gnome.org live from git, not from release tarballs. This means that if the XML validation is broken in any of the files or a translation, a few hours after the commit, it will be broken on the website. I would appreciate it if anyone working on translations could verify that their commit does not break validation. In docs, we just run make after making the changes/applying the patch, but I'm not sure how that would fit into the translation workflow. If anyone has better suggestions, please speak up. Having said that, there is a lot of work being done on gnome-user-docs right now, so you may want to not translate it for a few more months. Happy translating, Kat ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gnome-devel-docs on developer.gnome.org
Ekaterina, Rather than rely on the carefulness of the translators (which will possibly fail at some point and a few times), isn't it possible to implement some kind of verification before pushing from the module to the website? My idea would be something like: schedule the pushes to website and before doing so, run the XML validation, and if it fails, do not push to website - and notify (the maintainer?). -- i'm not a developer, just throwing ideas. Cheers, Rafael Ferreira 2014-05-09 10:05 GMT-03:00 Ekaterina Gerasimova kittykat3...@gmail.com: Hi all, the gnome-devel-docs module is now shown in developer.gnome.org live from git, not from release tarballs. This means that if the XML validation is broken in any of the files or a translation, a few hours after the commit, it will be broken on the website. I would appreciate it if anyone working on translations could verify that their commit does not break validation. In docs, we just run make after making the changes/applying the patch, but I'm not sure how that would fit into the translation workflow. If anyone has better suggestions, please speak up. Having said that, there is a lot of work being done on gnome-user-docs right now, so you may want to not translate it for a few more months. Happy translating, Kat ___ 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: gnome-devel-docs on developer.gnome.org
Hi, Could we implement a pre-commit hook to check XML syntax with gtxml [1]? This is the tool I use to periodically check XML syntax from PO files, to detecttypos in tags or not properly closed tags in PO files, so running it before pushing changes into Git could help us to avoid this kind of problems. My 2 cents :-) [1] https://launchpad.net/pyg3t 2014-05-09 17:02 GMT+02:00 Rafael Ferreira rafael.f...@gmail.com: Ekaterina, Rather than rely on the carefulness of the translators (which will possibly fail at some point and a few times), isn't it possible to implement some kind of verification before pushing from the module to the website? My idea would be something like: schedule the pushes to website and before doing so, run the XML validation, and if it fails, do not push to website - and notify (the maintainer?). -- i'm not a developer, just throwing ideas. Cheers, Rafael Ferreira 2014-05-09 10:05 GMT-03:00 Ekaterina Gerasimova kittykat3...@gmail.com: Hi all, the gnome-devel-docs module is now shown in developer.gnome.org live from git, not from release tarballs. This means that if the XML validation is broken in any of the files or a translation, a few hours after the commit, it will be broken on the website. I would appreciate it if anyone working on translations could verify that their commit does not break validation. In docs, we just run make after making the changes/applying the patch, but I'm not sure how that would fit into the translation workflow. If anyone has better suggestions, please speak up. Having said that, there is a lot of work being done on gnome-user-docs right now, so you may want to not translate it for a few more months. Happy translating, Kat ___ 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: gnome-devel-docs on developer.gnome.org
On Fri, May 9, 2014 at 5:14 PM, Daniel Mustieles García daniel.mustie...@gmail.com wrote: Hi, Hi, Could we implement a pre-commit hook to check XML syntax with gtxml [1]? Are there any false positives? -- Alexandre Franke ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gnome-devel-docs on developer.gnome.org
No AFAIK, but I'm not 100% about it. Cc'ing Ask, maintainer of pyg3t, to hear his oppinion about this question. El 09/05/2014 17:37, Alexandre Franke alexandre.fra...@gmail.com escribió: On Fri, May 9, 2014 at 5:14 PM, Daniel Mustieles García daniel.mustie...@gmail.com wrote: Hi, Hi, Could we implement a pre-commit hook to check XML syntax with gtxml [1]? Are there any false positives? -- Alexandre Franke ___ 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: gnome-devel-docs on developer.gnome.org
The only false positive I know of gtxml is the 'translator-credits' string, returning exit code 1. For instance: $ gtxml platform-demos.master.pt_BR.po At line 23: not well-formed (invalid token) --- #. Put one translator per line, in the form NAME EMAIL, YEAR1, YEAR2 msgctxt _ msgid translator-credits msgstr Rafael Ferreira rafael.f...@gmail.com, 2013 2014-05-09 15:49 GMT+00:00 Daniel Mustieles García daniel.mustie...@gmail.com: No AFAIK, but I'm not 100% about it. Cc'ing Ask, maintainer of pyg3t, to hear his oppinion about this question. El 09/05/2014 17:37, Alexandre Franke alexandre.fra...@gmail.com escribió: On Fri, May 9, 2014 at 5:14 PM, Daniel Mustieles García daniel.mustie...@gmail.com wrote: Hi, Hi, Could we implement a pre-commit hook to check XML syntax with gtxml [1]? Are there any false positives? -- Alexandre Franke ___ 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: gnome-devel-docs on developer.gnome.org
Maybe it is because of the newline character? Translator credits should be in one line per credit El 09/05/2014 18:01, Rafael Ferreira rafael.f...@gmail.com escribió: The only false positive I know of gtxml is the 'translator-credits' string, returning exit code 1. For instance: $ gtxml platform-demos.master.pt_BR.po At line 23: not well-formed (invalid token) --- #. Put one translator per line, in the form NAME EMAIL, YEAR1, YEAR2 msgctxt _ msgid translator-credits msgstr Rafael Ferreira rafael.f...@gmail.com, 2013 2014-05-09 15:49 GMT+00:00 Daniel Mustieles García daniel.mustie...@gmail.com: No AFAIK, but I'm not 100% about it. Cc'ing Ask, maintainer of pyg3t, to hear his oppinion about this question. El 09/05/2014 17:37, Alexandre Franke alexandre.fra...@gmail.com escribió: On Fri, May 9, 2014 at 5:14 PM, Daniel Mustieles García daniel.mustie...@gmail.com wrote: Hi, Hi, Could we implement a pre-commit hook to check XML syntax with gtxml [1]? Are there any false positives? -- Alexandre Franke ___ 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: gnome-devel-docs on developer.gnome.org
No, it is a false positive. My example had only one translator. But here is another example, now with two translators in translator-credits: $ gtxml ~/Downloads//optimization-guide.master.pt_BR.po At line 24: not well-formed (invalid token) --- #. Put one translator per line, in the form NAME EMAIL, YEAR1, YEAR2 msgctxt _ msgid translator-credits msgstr Enrico Nicoletto live...@gmail.com, 2012\n Rafael Ferreira rafael.f...@gmail.com, 2013 If someone that knows python3 could patch pyg3t to fix this, I think it would be a great tool for this XML validation... Someone? 2014-05-09 16:40 GMT+00:00 Daniel Mustieles García daniel.mustie...@gmail.com: Maybe it is because of the newline character? Translator credits should be in one line per credit El 09/05/2014 18:01, Rafael Ferreira rafael.f...@gmail.com escribió: The only false positive I know of gtxml is the 'translator-credits' string, returning exit code 1. For instance: $ gtxml platform-demos.master.pt_BR.po At line 23: not well-formed (invalid token) --- #. Put one translator per line, in the form NAME EMAIL, YEAR1, YEAR2 msgctxt _ msgid translator-credits msgstr Rafael Ferreira rafael.f...@gmail.com, 2013 2014-05-09 15:49 GMT+00:00 Daniel Mustieles García daniel.mustie...@gmail.com: No AFAIK, but I'm not 100% about it. Cc'ing Ask, maintainer of pyg3t, to hear his oppinion about this question. El 09/05/2014 17:37, Alexandre Franke alexandre.fra...@gmail.com escribió: On Fri, May 9, 2014 at 5:14 PM, Daniel Mustieles García daniel.mustie...@gmail.com wrote: Hi, Hi, Could we implement a pre-commit hook to check XML syntax with gtxml [1]? Are there any false positives? -- Alexandre Franke ___ 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: gnome-devel-docs on developer.gnome.org
Pyg3t's maintainer is in Cc (Ask) so maybe he is the best option to fix it ;-) El 09/05/2014 18:51, Rafael Ferreira rafael.f...@gmail.com escribió: No, it is a false positive. My example had only one translator. But here is another example, now with two translators in translator-credits: $ gtxml ~/Downloads//optimization-guide.master.pt_BR.po At line 24: not well-formed (invalid token) --- #. Put one translator per line, in the form NAME EMAIL, YEAR1, YEAR2 msgctxt _ msgid translator-credits msgstr Enrico Nicoletto live...@gmail.com, 2012\n Rafael Ferreira rafael.f...@gmail.com, 2013 If someone that knows python3 could patch pyg3t to fix this, I think it would be a great tool for this XML validation... Someone? 2014-05-09 16:40 GMT+00:00 Daniel Mustieles García daniel.mustie...@gmail.com: Maybe it is because of the newline character? Translator credits should be in one line per credit El 09/05/2014 18:01, Rafael Ferreira rafael.f...@gmail.com escribió: The only false positive I know of gtxml is the 'translator-credits' string, returning exit code 1. For instance: $ gtxml platform-demos.master.pt_BR.po At line 23: not well-formed (invalid token) --- #. Put one translator per line, in the form NAME EMAIL, YEAR1, YEAR2 msgctxt _ msgid translator-credits msgstr Rafael Ferreira rafael.f...@gmail.com, 2013 2014-05-09 15:49 GMT+00:00 Daniel Mustieles García daniel.mustie...@gmail.com: No AFAIK, but I'm not 100% about it. Cc'ing Ask, maintainer of pyg3t, to hear his oppinion about this question. El 09/05/2014 17:37, Alexandre Franke alexandre.fra...@gmail.com escribió: On Fri, May 9, 2014 at 5:14 PM, Daniel Mustieles García daniel.mustie...@gmail.com wrote: Hi, Hi, Could we implement a pre-commit hook to check XML syntax with gtxml [1]? Are there any false positives? -- Alexandre Franke ___ 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: gnome-devel-docs on developer.gnome.org
Pk, 2014.05.09. 16:51 +, Rafael Ferreira rakstīja: If someone that knows python3 could patch pyg3t to fix this, I think it would be a great tool for this XML validation... Someone? specifically in translator-credits strings, the e-mail is often put in angle brackets, which is not a valid XML. If the translator-credits string is parsed with XML, that IS a bug. Otherwise just skip the translator-credits string in the xml check. -- Rūdolfs Mazurs rudolfs.maz...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gnome-devel-docs on developer.gnome.org
Hello everyone First of all I am very willing to implement a mode in gtxml specifically for this. Fixing the translator-credits issue is obviously very easy. I can make it so that gtxml will only complain about syntax errors, i.e. strings that are not accepted by the xml parser. This requires that all msgids and msgstrs - except the header and translator-credits - can be assumed to be XML. The files also contain media links to images/videos with their md5 hashes. Perhaps a special check should be made for those, since they are probably not required to be legal XML. Are there other classes of strings to be aware of? Is all this acceptable? Also, who could actually approve this and make it run on the server? Right now gtxml can to various extents be smarter and detect more errors - e.g. whether unexpected XML tags are used. But some translators tend to insert their own little xml things when they want, which is fine by itself, but can lead to false positives when attempting to be too smart. What happens with placeholder tags (such as _:ulink-1, _:ulink-2 and so on), how bad is it if those are messed up? Of course the ultimate authority on whether the translations are valid or not is the software that compiles the documentation. So another possible filter would be to actually compile the darn thing as soon as it gets checked in and use that as a test. Best regards Ask 2014-05-09 19:40 GMT+02:00 Daniel Mustieles García daniel.mustie...@gmail.com: Pyg3t's maintainer is in Cc (Ask) so maybe he is the best option to fix it ;-) El 09/05/2014 18:51, Rafael Ferreira rafael.f...@gmail.com escribió: No, it is a false positive. My example had only one translator. But here is another example, now with two translators in translator-credits: $ gtxml ~/Downloads//optimization-guide.master.pt_BR.po At line 24: not well-formed (invalid token) --- #. Put one translator per line, in the form NAME EMAIL, YEAR1, YEAR2 msgctxt _ msgid translator-credits msgstr Enrico Nicoletto live...@gmail.com, 2012\n Rafael Ferreira rafael.f...@gmail.com, 2013 If someone that knows python3 could patch pyg3t to fix this, I think it would be a great tool for this XML validation... Someone? 2014-05-09 16:40 GMT+00:00 Daniel Mustieles García daniel.mustie...@gmail.com: Maybe it is because of the newline character? Translator credits should be in one line per credit El 09/05/2014 18:01, Rafael Ferreira rafael.f...@gmail.com escribió: The only false positive I know of gtxml is the 'translator-credits' string, returning exit code 1. For instance: $ gtxml platform-demos.master.pt_BR.po At line 23: not well-formed (invalid token) --- #. Put one translator per line, in the form NAME EMAIL, YEAR1, YEAR2 msgctxt _ msgid translator-credits msgstr Rafael Ferreira rafael.f...@gmail.com, 2013 2014-05-09 15:49 GMT+00:00 Daniel Mustieles García daniel.mustie...@gmail.com: No AFAIK, but I'm not 100% about it. Cc'ing Ask, maintainer of pyg3t, to hear his oppinion about this question. El 09/05/2014 17:37, Alexandre Franke alexandre.fra...@gmail.com escribió: On Fri, May 9, 2014 at 5:14 PM, Daniel Mustieles García daniel.mustie...@gmail.com wrote: Hi, Hi, Could we implement a pre-commit hook to check XML syntax with gtxml [1]? Are there any false positives? -- Alexandre Franke ___ 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
