On Thu, Sep 13, 2012 at 8:09 AM, Daniel Mustieles García <daniel.mustie...@gmail.com> wrote: > Yes, I've considered it several times, but the main script I've developed > (GTTK) has several bugs, and i'd like to fix them before sharing it with a > big README file ;-) > > I hope I'll have some time these days to work on it and, when I fix it, sure > I'll share it on github. > > BTW, as soon as I have time to create a repo and upload the scripts, I'll > share them in this mail list. > > Many thanks for your interest!
Dear Daniel, Thank you for this effort. Creation of workflows like this for global (or even individual) quality control is a wonderful contribution. I would not be too concerned about sharing them prior to final polishing as I think you have a very welcoming audience of beta testers on this list. I would encourage you to look at the Translate Toolkit for inspiration (or bits of code to borrow) as there are lots of widgets that perform similar work in a PO-file aware manner. The widgets there are readily wrapped in a little bash script for bulk operations. http://translate.sourceforge.net/wiki/toolkit/index For instance, I think a similar check is performed by the pofilter tool under the xmltags flag. translate.sourceforge.net/wiki/toolkit/pofilter_tests Just as a potential target for another such global analysis workflow, in my experience with Sugar Labs, I find that printf errors and mismatched terminal newlines are the most common causes of PO files causing build failures. One of the interesting things about xmltags, printf errors and terminal newlines mismatches is that very often, one does not need to be able to read the language in question to be able to provide a suitable correction. Simple understanding of the syntax of the original string is often sufficient to identify the error and correct it. I would also like to point out that one of the current Gnome Goals https://live.gnome.org/GnomeGoals/RemoveMarkupInMessages is, in fact, to find and remove markup from UI messages. I imagine your tool could be adapted to search for the presence of such tags in UI strings. I have filed a few i18n enhancement tickets on packages pointing out the Gnome Goal above where there was a lot of markup and referencing specific lines (from the PO location comment). At some point I may take a look at going back over them and trying to provide patches where the original developers have not taken action on their own. Warmest Regards, cjl _______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n