| 2009-06-30 07:39:29 |
Jeroen T. Vermeulen |
bug |
|
|
added bug |
| 2009-06-30 07:54:49 |
Jeroen T. Vermeulen |
description |
It looks to me as if we may be exporting the wrong diverged TranslationMessages as part of language packs.
The POExport view joins a TranslationMessage to all POTemplates that use its POTMsgSet. It keeps a separate "diverged" FK to TranslationMessage.potemplate. That's good design, but I don't see anything to filter out cases where diverged is neither null nor equal to potemplate. Then POFile._getMessages gives precedence to diverged messages—but doesn't check that they are diverged to the current POTemplate rather than to some other POTemplate that it shares with.
We could solve this in at least two ways:
1. In the view: "WHERE diverged IS NULL OR diverged = potemplate." May make the SQL slower but will also return fewer rows, which is good.
2. In POFile._getMessages:
if row.diverged == row.potemplate:
diverged_messages.append(msg_key)
elif row.diverged is None:
# This message is shared.
if msg_key in diverged_messages:
continue
else:
# This diverged message belongs to a different template.
continue
If it doesn't upset the applecart too much I'd prefer the SQL solution. |
It looks to me as if we may be exporting the wrong diverged TranslationMessages as part of language packs.
The POExport view joins a TranslationMessage to all POTemplates that use its POTMsgSet. It keeps a separate "diverged" FK to TranslationMessage.potemplate. That's good design, but I don't see anything to filter out cases where diverged is neither null nor equal to potemplate. Then POFile._getMessages gives precedence to diverged messages—but doesn't check that they are diverged to the current POTemplate rather than to some other POTemplate that it shares with.
We could solve this in at least three ways:
1. In the view: "WHERE diverged IS NULL OR diverged = potemplate." May make the SQL slower but will also return fewer rows, which is good.
2. In POFile._getMessages:
if row.diverged == row.potemplate:
diverged_messages.append(msg_key)
elif row.diverged is None:
# This message is shared.
if msg_key in diverged_messages:
continue
else:
# This diverged message belongs to a different template.
continue
3. In VPOExport: replace get_pofile_rows and get_pofile_changed_rows with versions that go straight to the relevant tables. Then we won't need the POExport view at all.
I'd prefer solution 3 in the end, but 1 or 2 are easier short-term fixes. |
|
| 2009-06-30 08:15:40 |
Jeroen T. Vermeulen |
description |
It looks to me as if we may be exporting the wrong diverged TranslationMessages as part of language packs.
The POExport view joins a TranslationMessage to all POTemplates that use its POTMsgSet. It keeps a separate "diverged" FK to TranslationMessage.potemplate. That's good design, but I don't see anything to filter out cases where diverged is neither null nor equal to potemplate. Then POFile._getMessages gives precedence to diverged messages—but doesn't check that they are diverged to the current POTemplate rather than to some other POTemplate that it shares with.
We could solve this in at least three ways:
1. In the view: "WHERE diverged IS NULL OR diverged = potemplate." May make the SQL slower but will also return fewer rows, which is good.
2. In POFile._getMessages:
if row.diverged == row.potemplate:
diverged_messages.append(msg_key)
elif row.diverged is None:
# This message is shared.
if msg_key in diverged_messages:
continue
else:
# This diverged message belongs to a different template.
continue
3. In VPOExport: replace get_pofile_rows and get_pofile_changed_rows with versions that go straight to the relevant tables. Then we won't need the POExport view at all.
I'd prefer solution 3 in the end, but 1 or 2 are easier short-term fixes. |
It looks to me as if we may be exporting the wrong diverged TranslationMessages as part of language packs.
The POExport view joins a TranslationMessage to all POTemplates that use its POTMsgSet. It keeps a separate "diverged" FK to TranslationMessage.potemplate. That's good design, but I don't see anything to filter out cases where diverged is neither null nor equal to potemplate. In other words, messages that are diverged but for a different template.
Next, POFile._getMessages (which processes the rows from POExport) properly gives precedence to diverged messages over shared ones—but doesn't check that they are diverged to the current POTemplate rather than to some other POTemplate that it shares with.
We could solve this in at least three ways:
1. In the view: "WHERE diverged IS NULL OR diverged = potemplate." May make the SQL slower but will also return fewer rows, which is good.
2. In POFile._getMessages:
if row.diverged == row.potemplate:
diverged_messages.append(msg_key)
elif row.diverged is None:
# This message is shared.
if msg_key in diverged_messages:
continue
else:
# This diverged message belongs to a different template.
continue
3. In VPOExport: replace get_pofile_rows and get_pofile_changed_rows with versions that go straight to the relevant tables. Then we won't need the POExport view at all.
I'd prefer solution 3 in the end, but 1 or 2 are easier short-term fixes. |
|
| 2009-06-30 08:23:11 |
Jeroen T. Vermeulen |
summary |
Language packs and diverged messages |
Exports and diverged messages |
|
| 2009-06-30 08:24:18 |
Jeroen T. Vermeulen |
description |
It looks to me as if we may be exporting the wrong diverged TranslationMessages as part of language packs.
The POExport view joins a TranslationMessage to all POTemplates that use its POTMsgSet. It keeps a separate "diverged" FK to TranslationMessage.potemplate. That's good design, but I don't see anything to filter out cases where diverged is neither null nor equal to potemplate. In other words, messages that are diverged but for a different template.
Next, POFile._getMessages (which processes the rows from POExport) properly gives precedence to diverged messages over shared ones—but doesn't check that they are diverged to the current POTemplate rather than to some other POTemplate that it shares with.
We could solve this in at least three ways:
1. In the view: "WHERE diverged IS NULL OR diverged = potemplate." May make the SQL slower but will also return fewer rows, which is good.
2. In POFile._getMessages:
if row.diverged == row.potemplate:
diverged_messages.append(msg_key)
elif row.diverged is None:
# This message is shared.
if msg_key in diverged_messages:
continue
else:
# This diverged message belongs to a different template.
continue
3. In VPOExport: replace get_pofile_rows and get_pofile_changed_rows with versions that go straight to the relevant tables. Then we won't need the POExport view at all.
I'd prefer solution 3 in the end, but 1 or 2 are easier short-term fixes. |
It looks to me as if we may be including diverged TranslationMessages in translation exports where they shouldn't be included.
The POExport view joins a TranslationMessage to all POTemplates that use its POTMsgSet. It keeps a separate "diverged" FK to TranslationMessage.potemplate. That's good design, but I don't see anything to filter out cases where diverged is neither null nor equal to potemplate. In other words, messages that are diverged but for a different template.
Next, POFile._getMessages (which processes the rows from POExport) properly gives precedence to diverged messages over shared ones—but doesn't check that they are diverged to the current POTemplate rather than to some other POTemplate that it shares with.
We could solve this in at least three ways:
1. In the view: "WHERE diverged IS NULL OR diverged = potemplate." May make the SQL slower but will also return fewer rows, which is good.
2. In POFile._getMessages:
if row.diverged == row.potemplate:
diverged_messages.append(msg_key)
elif row.diverged is None:
# This message is shared.
if msg_key in diverged_messages:
continue
else:
# This diverged message belongs to a different template.
continue
3. In VPOExport: replace get_pofile_rows and get_pofile_changed_rows with versions that go straight to the relevant tables. Then we won't need the POExport view at all.
I'd prefer solution 3 in the end, but 1 or 2 are easier short-term fixes. |
|
| 2009-06-30 12:57:59 |
Данило Шеган |
rosetta: importance |
Undecided |
High |
|
| 2009-06-30 12:57:59 |
Данило Шеган |
rosetta: status |
New |
Triaged |
|
| 2009-06-30 12:57:59 |
Данило Шеган |
rosetta: milestone |
|
2.2.7 |
|
| 2009-06-30 12:58:16 |
Данило Шеган |
tags |
|
message-sharing |
|
| 2009-07-02 06:07:01 |
Jeroen T. Vermeulen |
rosetta: status |
Triaged |
In Progress |
|
| 2009-07-02 06:08:06 |
Jeroen T. Vermeulen |
rosetta: assignee |
|
Jeroen T. Vermeulen (jtv) |
|
| 2009-07-03 13:48:27 |
Jeroen T. Vermeulen |
rosetta: status |
In Progress |
Fix Committed |
|
| 2009-07-23 06:04:13 |
Jeroen T. Vermeulen |
rosetta: status |
Fix Committed |
Fix Released |
|
