In a filtered view, Rosetta skips messages when saving

[Malcolm Parsons]

When translating with the "untranslated" filter on.
Messages 1-10 are displayed.
The user translates these, and presses "save & continue".
The URL then contains "start=10".
So Rosetta displays untranslated messages 11-20.
These are actually messages 21-30, as the first 10 messages are now translated.
Messages 11-20 have been skipped.
...
When you've translated the last message you get told
"There are no messages that match this filtering. Translation status: English (United Kingdom) 50%"

Maybe the start value in the URL should be decreased by the number of strings that were translated.

[Diogo Matsubara (matsubara)]

Indeed, this is confusing.

[Andre Noel (andrenoel)]

"Maybe the start value in the URL should be decreased by the number of strings that were translated."
It would be nice. Alternatively, if start > total strings it would go back to start=0.

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

Some discussion in bug #81490 as well.

[Mikel Pascual Aldabaldetreku (mpascual)]

yeah

this is very annoying, and makes much more long to translate huge packages (keeping the translator go forth and back)

this should be easy to fix (and would help a lot), either doing "new_start=old_start+batch-translated" as Malcom said.

[Curtis Hovey (sinzui)]

The branch to fix this is in review.

[Curtis Hovey (sinzui)]

Fixed in RF 5538.

[Curtis Hovey (sinzui)]

Fixed released in Launchpad 1.2.1.

[Gintautas Miliauskas (gintas)]

This bug has been fixed for the "untranslated messages" filter, but not for "changed messages". I just compared the behaviours for these two filters and it is indeed different. Other filters may also have the problem. Here's how to reproduce the problem:

1. Open a package with X (X>20) changed strings in Launchpad Translations
2. Revert all 10 strings on first page to packaged versions.
3. Press "Save & Continue"
4. The label at the top says "11 → 20 of X-10 results", whereas it should say "1 → 10 of X-10 results".

[Curtis Hovey (sinzui)]

This should be files as a new bug because the rules for identifying the changed messages will be different. This will be easier to fix since the new rules can be added to blocks that adjust the batch starting numbers.

[Gintautas Miliauskas (gintas)]

As requested, I filed the problem as a separate bug: https://bugs.launchpad.net/rosetta/+bug/206739