Duplicate translations for POTMsgSet cause OOPSes on PO import

[Henning Eggers]

Gettext format errors in import files cause the poimport script to oops. This happens because they are being logged as WARN when they should be logged as INFO nowadays

Some examples:

OOPS-1770POI16, OOPS-1770POI18, OOPS-1770POI19, OOPS-1770POI31, OOPS-1770POI17

[Данило Шеган (danilo)]

Actually, none of these are problems with gettext checks. The OOPSes are incorrectly logged. One should look at the "Request variables" to get at the real reason behind it:"Translation for POTMsgSet 8089344 into 'te' matches 2 existing translations."

select translationmessage.id, submitter, reviewer, msgstr0, msgstr1, potemplate from translationmessage join language on language.id=language where potmsgset=8089344 and language.code='te';
    id | submitter | reviewer | msgstr0 | msgstr1 | potemplate
-----------+-----------+----------+----------+---------+------------
 173718363 | 1751163 | | 19573073 | |
 152868260 | 1751163 | | 16985879 | |
 107670655 | 1751163 | | 16985879 | | 18812

We've got identical translations where one is diverged and other isn't. Existing updateTranslation can't cope with this. Our latest code doesn't use updateTranslation anymore in db-stable. We should QA that this is the case.

This is message "%s%s%s%s has made %s his or her buddy%s%s" in Telugu Pidgin translation. Divergence is there in Hardy, and we can probably QA this by doing a similar upload on qastaging (using updateTranslation) where it should fail in the same way and then doing an upload on staging (which is not using updateTranslation) to make sure new code can deal with the problem.