Automated quality checking of translations

It should be possible to extend coder to do this. However what are the reviews you would want to add? What checks would need to be done? Can you provide a link to the Drupal standards on .po files?

You might want to look at the "Interface Text Translation" review that ships with the potx module (with #309875: Fix (and improve) hook_reviews).

You might also look at the new "Internationalization" review in the 6.x-1.x-dev version.

ztyz: it's already possible to do different checks based on file-suffixes. We already have different tests for js (not complete), patch and tests. We just need to know which checks should be done on .po files.

The new "Internationalization" review is in the 6.x-1.x-dev version. It will be in the 6.x-1.2 version when we release it (but it's not released yet). But based on your most recent comments, I don't think that this review checks what you're asking for. The "Internationalization" review is still checking the php code for proper Drupal programming.

This would make a very valuable and powerful battery of tests. It would allow us to assess to a degree not only the completeness but the quality of a translation. We could present summary statistics for each module, showing the number of problem-free, problematic, and missing translations.

Clearly this issue presents challenges because it's quite distinct from the usual coder needs in that it needs to compare specific data between sets of text files. Probably this would need to be done in a separate module, maybe one that depends on potx, since potx is already set up to deal with .pot files.

Doug, Stella, what do you think?

Attached is a patch that does some restructuring of coder to make it simpler to add file extension based rules. And then it takes the first stab at a callback that implements many of the requests above. I'm likely to commit part (or all of this patch) before it is really done, just to get the restructuring in place.

But we should continue to work on improving these rules, and possibly even move them to the potx review.

Opps, here's the patch...

Please, don't forget to test:

1. Sentences must end with periods. (http://drupal.org/node/312523#comment-1030590)
2. Also check if people are using l() inside the placeholder array. If they do - make it an context sensitive "error". Code example can be found at http://drupal.org/node/310852#comment-1029681.
3. Validate if people are using @ placeholder if url() is used. $output .= '<p>'. t('Go to the <a href="@contact-page">contact page</a>.', array('@contact-page' => url('contact'))) .'</p>';

This patch attempts to catch translation issues. Aren't these latest three requests more about the potx review, and not about the translation itself.

Sorry, aren't you working here on the internationalisation tests? It's not POTX only... It extends the list of checks in #7 above.

@hass: actually it shouldn't be filed with the potx project. I don't think those are appropriate cases for that module. Instead create a new issue against the coder module for those requests. They should be added to the coder built-in internationalization review. Thanks.

From hass's new suggestions:

1. I've added a check that if the original text ends in a period, that the translation should also end in a period.
2. Please create a separate coder issue for this.
3. Please create a separate coder issue for this.

I then committed this patch. I'm leaving the issue open, so that we can add additional checks.

Don't think the following review is working:

"The translation text should end in a period when the same original text also ends in a period."

It's giving me errors in po files for lines where both the original source text and the translated text both end in a period.

Secondly how do you compare upper and lower case of the first letter of a sentence when the source text is in English and the translated text is in a different character set, e.g. Japanese, Arabic, etc. Similarly not sure if the punctuation checks will work here either.

Cheers,
Stella

Well, not every string needs a period... but descriptions should have one - mostly/everytime(!?)... titles - mostly not... but maybe sometimes. Not sure how we should test this 100% correctly.

hass: I'm actually referring to the review of the .po files themselves, i.e. where the comparison of the translated text and the source text. For example, if the English source text ends in a period, then a check is done to ensure that the French translation does too. So your comment is more in relation to the parsing of the strings passed to t() in the source code, which is a separate issue. This issue is just for the comparison the translated strings with the original source text.

Ahhh, well that would be cool... haven't yet thought about comparing English with the translation. Very good idea. :-)

The upper/lower case comparison is using ctype_upper.

The period and punctuation tests aren't working because the '.' in other languages doesn't match the '.' in English. Any ideas how to solve this?

And lastly, as hass mentions above, not every sentence should end with a period. But as stella also mentions, this check is that if the original text ends in a period, that the translated text should as well.

Could we separate the review of ".po" files out from the "internationalization" review? Or at least have a flag to stop .po files from being reviewed by default as part of that review? It's just that as a developer reviewing my module's code, I don't want to see errors in relation to translation. I just want to see my coding errors.

The period matching appears to have been included in the latest beta, although it still doesn't work.

This is not really relevant anymore, since the new standard is now translations managed on localize.drupal.org and exported separately from d.o projects. There are to be no .po files in projects to check with coder module. However, quality checking of translations (on input and possibly on request for existing translations) would be a good feature request for localization server, so moving this issue there.

I started a similar issues a year ago #587666: Add simple automated translation formatting checks.

I & my FD started to do similar stuff to save our time to do error checking, this is a test page: http://bit.ly/gOqUOI
(black is origin texts, green is following our standard, red is errors)

for my experience, we only catch very few error (non-standard) strings. specifically, English and other Latin lang translation have SPACE to split the word and lots punctuations is SAME. There would be very very less errors. (IMO, I think it do not worth if it need spent a lots time to code a script to do formatting check for English (eg. punctuations checking, have SPACE or no SPACE ..capitalization or not). but always happing to see that :)

at the point, placeholders / HTML Markup checking is more important.

Yes, in fact, we can continue on the existing issue.