Translate form re-building should not rely on pagination

This seems to be a side effect of how the form API works. Drupal checks whether the submitted form is valid, and it regenerates the base form structure for that. So if the underlying data changes, the form structure will change., and your data will not be accepted. We could maybe look into testing how form caching interacts with this validation/submission process, so we maybe can eliminate the form regeneration.

Retitled to be more specific as we now understand the problem.

#806758: Items come back without suggestion was submitted as a duplicate and has some similar details.

So translate sprints with l.d.o. are a no-go until this is solved!
Can it be solved by using indivdual forms per item instead of a page form? The position of a item is then not relevant anymore. I also feel that the proccess then is more natural... I don't like the way it works now, I hate to save twice. One time when you leave the field and then the whole page.

You can still just use per-project filtering where there is much less chance of a form issue (but there is some).

Similar issues in other projects
#497206: Avoid search conflicts with other forms, use menu API instead of search_get_keys()
#614644: Forms attached to Apachesolr search results won't work
Ubercart.org #5089 Search result as teaser 'Add to cart' button doesnt work

i created http://drupal.org/node/1299954 and it may be duplicate, but I'm not sure, check the symptoms and repair this please :)

It may be that we have still this issue on the 7.x-1.x branch, any way, the 6.x version is discontinued

The main problem is that the form is relying on pager to get the strings, when a form is submitted, the query is executed again to retrieve the sids.

That can cause race condition when another person (or another page) is submitted and has a lower page number.

I've attached a patch that fetch the sids submitted from $form_state['input'] (that I'm not proud of), but solves the problem. Given we have a limit of 50 strings per page, I've overcome the potential DDOS (even if it is authenticated form) by only allowing a chunk of 50 sids to be input by user.

+++ b/l10n_community/translate.inc
@@ -309,32 +308,41 @@ function l10n_community_translate_page($langcode) {
+  if (!empty($form_state['input']['strings'])) {
+    $sids = array_keys($form_state['input']['strings']);
+    $strings = l10n_community_get_strings($langcode, $filters, $filters['limit'], $sids);
+  }

So while the limit param is validated, the string list may still be any length no? It would be great to chunk this with the limit or refuse the form if its over 50 (or over the limit that was validated) or something along those lines.

I am a bit wary to make this live honestly :/

Pushed a array_slice given the maximum limit we allow in the filter form.

The french team successfully tested this patch on staging.

Deployed to live. Thanks for the quick fix. :)