Late import of c-format flag causes inconsistent data

[Данило Шеган]

For translatable messages that represent (for example) C format strings, the formatting conversions in the translation must be compatible with those of the original message. As long as the c-format flag is set to indicate that the message is a C format string, you can't translate msgid "Blah" with msgstr "Foo %d". Neither gettext nor Launchpad will accept it.

But if the c-format flag is omitted when the mistake is first made, and then a later template update sets the c-format flag without changing the msgid, we end up with inconsistent data. The message is now in that state in which neither gettext nor Launchpad would accept it.

A good way to deal with this would be to demote the translation to a suggestion with validation_status == UNKNOWN_ERROR.

We need to watch for interactions with super-fast-imports.

Bug 312130 might be mildly related (at least in the practical sense, not much code-wise).

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

Jeroen has been working on cleaning up the data, fixing the bug properly will require a lot more attention (like how not to avoid slowing down entire LP).

[Jeroen T. Vermeulen (jtv)]

Separated out the cleanup of existing data into bug 319153. Working on that one.

So now this bug can be entirely about stopping the problem from happening.

[David Planella (dpm)]

Additional note: it seems that 'msgfmt --check-format' does not catch errors in correctly flagged python-format strings. Try the attachment with incorrect plurals missing the %d variable. I reported someting similar in bug 456210, which I then marked as duplicate of this one.

I've seen this happening in #kde-format strings as well (bug 363414, bug 425254, bug 425226), so I should probably check out if gettext catches errors there.

This also makes it difficult to catch things like bug 409785 and bug 363990 early.