.po file should not be considered broken if last msgstr is empty

The msgctxt introduction patch (#334283: Add msgctxt-type context to t()) changed the last string save condition to require a non-empty msgstr value at the end. While none of the other msgstr parsing requires an actual msgstr value to present to call the save callback, this one does, so if the last msgstr translation item in the file is empty, the file is reported broken by Drupal (even though all previous strings were imported and the file is not broken at all).

Drupal 6 had this:

  // End of PO file, flush last entry
  if (($context == "MSGSTR") || ($context == "MSGSTR_ARR")) {
    _locale_import_one_string($op, $current, $mode, $lang, $file, $group);
  }
  elseif ($context != "COMMENT") {
    _locale_import_message('The translation file %filename ended unexpectedly at line %line.', $file, $lineno);
    return FALSE;
  }

Drupal 7 has this:

  // End of PO file, flush last entry
  if (!empty($current) && !empty($current['msgstr'])) {
    _locale_import_one_string($op, $current, $mode, $lang, $file, $group);
  }
  elseif ($context != "COMMENT") {
    _locale_import_message('The translation file %filename ended unexpectedly at line %line.', $file, $lineno);
    return FALSE;
  }

So what happens is that if the last string has an empty msgstr (the last source has no translation), it flows into the unexpected end of file condition, which does match, because we are not yet in the comment context (there can be multiple consecutive msgstr lines so an msgstr line still keeps us in this context).

The solution is to treat the last content like any previous one. Just pass it on to the save callback even if it was empty. Suggested:

  // End of PO file, flush last entry.
  if (!empty($current)) {
    _locale_import_one_string($op, $current, $mode, $lang, $file, $group);
  }
  elseif ($context != "COMMENT") {
    _locale_import_message('The translation file %filename ended unexpectedly at line %line.', $file, $lineno);
    return FALSE;
  }

Apart from fixing this bug, it also makes it consistent with other strings, where Drupal core stores the source string even for empty translations, so you can use .po files to fill up your translation database for strings which did not appear yet on the site, so you know your translation status better.

There were multiple issues submitted for this on localization server, which uses this same code in Drupal 6 so it is able to parse .po files with contexts. The master bug for it was #561296: Error message when importing .po file where the last string is untranslated with many others marked as duplicates of that.