| 2009-01-18 06:25:22 |
Jeroen T. Vermeulen |
description |
When we initially import a message without c-format flag, and later add a c-format flag to it via template without changing it in any other way, we may keep inconsistent data in the database.
This can commonly happen if a POFile is imported without the c-format flag, and later a POTemplate is imported which contains it. Initial checks on POFile would not catch cases like msgid "Blah", msgstr "Foo %d", but when c-format is introduced, this should have resulted in the message being punted 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). |
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). |
|
