Add support for validating translations (syntax checks)

[sayamindu]

Version: 2.0.x

One of the main problems for developers is that often translators commit PO files with syntax errors (not all translation team does rigorous checking with the built in Pootle checks).

It may make sense to have some form of validation being done when an unit is updated, something in the lines of http://people.sugarlabs.org/sayamindu/pootle_gettext_check.png

[sayamindu]

Created attachment 616

Extremely hackish patch

Attached is an extremely hackish patch for anyone who needs this on an emergency basis. I have very little clue on the new Pootle codebase, and I have not checked this very carefully. This requires pygettextpo from https://launchpad.net/pygettextpo

[alaaosh]

interesting idea.

I'm afraid the cases where we can know for sure that it's an error are rare though (what else apart from unnamed printf style variables?).

[sayamindu]

(In reply to BZ-IMPORT::comment #2)

interesting idea.

I'm afraid the cases where we can know for sure that it's an error are rare though (what else apart from unnamed printf style variables?).

Anything that is caught by "msgfmt --check"

Printf formatting errors introduced in translations are the single-most common reason why the OLPC/Sugarlabs buildsystems break.

[friedelwolff]

Thanks for porting this to version 2, Sayamindu! I have some loose ideas which we can still think about:

• should we make this a quality check in itself?
• should we just show this as a file error similar to a parsing error? (icon next to the name)
• how widely is pygettextpo available/packaged? Shouldn't we just wrap the necessary things with ctypes similar to what we do in translate/storage/cpo.py? That way we don't introduce a new dependency.

I'm not sure what the ideal answers to these things are, but this is what came to mind.

[sayamindu]

(In reply to BZ-IMPORT::comment #4)

Thanks for porting this to version 2, Sayamindu! I have some loose ideas which we can still think about:

• should we make this a quality check in itself?

I would stick to the current behaviour (mandatory checking at the end of each submissions). The reason is that if someone neglects to do the translation, this may actually lead to crashes in the software (msgfmt in default mode does not do very strict checking, and many release processes often skip the make distcheck or equivalent part).

• should we just show this as a file error similar to a parsing error? (icon next to the name)

Yes, that can be useful.

• how widely is pygettextpo available/packaged? Shouldn't we just wrap the necessary things with ctypes similar to what we do in translate/storage/cpo.py? That way we don't introduce a new dependency.

pygettextpo is not widely available, and I used the latest code directly from bzr (I think it is only used internally by Launchpad). I will check if going via ctypes is feasible.

Thanks for the feedback, and a very happy new year :-).

[julen]

This is already implemented in master, not specific to gettext but critical failing checks are mandatory to be reviewed after submitting. We also prominently display the number of critical failing checks everywhere in the overview pages.