1 string is missing from export

This patch is works fine.

Sorry that it took some time to review this patch, but it does need some thought. In short: neither the current code, nor your patch is right.

The current logic works this way:

- DO get row from database
  - IF the row represents a new string (new sid)
    - IF the *previous* string was already assembled in $export_string with all location information
      - DO generate data for the *previous* string and add to $output and eventually $string_files
    - DO start the metadata array with the *new* string
  - ELSE append additional location information to *existing* string

What this does is that it keeps building up $export_string with all the location information for a string from multiple database result rows, until the next string comes around, when it saves $export_string, and starts processing of the next string. It does skip saving the last string, it is clear to me. You are right in that.

However, your code does the following (I did not actually try it, was just doing code review):

- DO get row from database
  - ALWAYS start over $export_string as if we are dealing with a new string in all cases
  - IF the row represents an existing string (same sid as previous)
    - DO add the *same* location information again to $export_string 
      (it does not remember any of the old values, since it is always overwritten)
  - DO generate data for the current string and add to $output and eventually $string_files

What this logic disrespects is that data for the same sid comes in a sequence of multiple rows from the database, and those should be aggregated in $export_string before handled. Your code seems to export multiple copies of the same string with bogus (duplicated) location information from the second copy onwards, when the same string appears multiple times in the exported "domain" (eg. Drupal core, module, theme).

What makes this code tricky is that even for the last database row, we don't know in advance whether that will be a new string or just additional location information for the existing one we are already handling. And we don't know when that last row comes, so handling the last row should be deferred until information is available that there are no more rows and we should close up the last string and save into $output / $string_files. So saving the last string is something we can only decide on after we are out of the while() loop.

Maybe we should refactor most of the inside of the while() loop to a function which would take most variables by reference, so we can call it once on each step inside the while() loop and once outside the while loop at the end to save the last string. Any good ideas are appreciated.

Edited the above flow of your code to say:

- DO get row from database
  - ALWAYS start over $export_string as if we are dealing with a new string in all cases
  - IF the row represents an existing string (same sid as previous)
    - DO add the *same* location information again to $export_string 
      (it does not remember any of the old values, since it is always overwritten)
  - DO generate data for the current string and add to $output and eventually $string_files

Instead of the original:

- DO get row from database
  - ALWAYS start over $export_string as if we are dealing with a new string in all cases
  - IF the row represents an existing string (same sid as previous)
    - DO add the *same* location information again to $export_string 
      (it does not remember any of the old values, since it is always overwritten)
    - DO generate data for the current string and add to $output and eventually $string_files

Which was a mistake in indentation. You always save the string for each new database row, regardless of conditionals, so the last DO should be on the same level as ALWAYS and IF.

This patch is works fine.

Looks great, thanks for the persistence and for the solution. Committed!