On Wed, 2009-08-26 at 23:02 +0100, Bruce Cowan wrote: > I've noticed that one of the main purposes of the en_GB team is to fix > the grammar and spelling of the original strings. However, most of the > work of the team seems to be done after string freeze, when the strings > can't be changed (easily). Of course, I could have started earlier, but > I didn't for some reason. > > Anyway, I thought that a sort of "string strike force" may be a good > idea. Essentially it would audit strings while they can still be fixed. > > The en_GB team could take this on itself, but it's probably a bit > understaffed. Hi all, Sorry for the late reply, but I've been busy with various things (including reviewing strings!). I agree with Shaun in that the best way to do this is probably by using a PO file. My suggestion would be to translate strings to review them, and discuss them (or explain any fixes) in the comment field for each string. For example: # pwithnall: OK #: file.c:666 msgid "This is a good string." msgstr "This is a good string." # pwithnall: "innit" is an unnecessary colloquialism #: file.c:123 msgid "This is a bad string, innit." msgstr "This is a fixed string." People would still have to learn a syntax (for use in the comment field), which could be read by Pulse and any other tools. However, this format would have the advantage of allowing any corrections to be shown. We could say that if a string's translated and it doesn't have a comment, or if it has an "OK" comment, it has passed a review. I think the main obstacle to people reviewing strings is the time it takes to effectively duplicate the work you've just done in editing a PO file when adding a bug to Bugzilla. I know that has put me off filing bugs about string issues before. How about a post-commit git hook which checks for strings marked as needing changes in our special PO file, and automatically files a bug in the appropriate product about them? If the reviewer has filled out the comment field suitably well, all the information needed for a good bug report should be there. The hook could be clever and append the bug number to the comment once it's filed, and refrain from filing duplicate bugs if those strings fail another review before the bug is resolved. If people like the idea, and it turns out to be as feasible as I think it is, I'd be OK with writing the hook. I'm also very much in favour of automated checks. The post-commit hook could perform some of those, automatically add a comment to the PO file and include the errant strings in the automatic bug report. The automated checks would have to have no false positives, though. Regards, Philip
Attachment:
signature.asc
Description: This is a digitally signed message part