[jayhemnani9910]

pybabel update --previous writes the old msgid of a fuzzy message as #| msgid ..., but read_po doesn't parse #| lines and stores them as user comments. The next update --previous writes them back as translator comments:

# first run                      # every later run
#, fuzzy                         # | msgid "Save the file"
#| msgid "Save the file"         #: app.py:2
msgid "Save this file"           #, fuzzy
msgstr "Datei speichern"         msgid "Save this file"
                                 msgstr "Datei speichern"

The # | msgid line then stays in the catalog as a translator comment even after the string is fixed. The same happens to #| lines written by GNU msgmerge --previous.

Two changes:

• read_po parses #| msgid / #| msgid_plural (and their continuation lines) into Message.previous_id. Message has no field for a previous msgctxt, so a #| msgctxt line is dropped instead of becoming a comment.
• Catalog.update keeps previous_id for a message that matches exactly but is still fuzzy, so a second run keeps the #| line, like msgmerge.
• write_po wrapped a long previous msgid with the comment wrapper, which splits it in the middle of the quoted strings (#| msgid "" "Save the file ... window so / #| " "nothing is lost"). It now writes one #| line per line of the normalized string, the way msgmerge does, so it reads back unchanged.

With both, three pybabel update --previous runs on the example above keep #| msgid "Save the file".

test_previous_msgid_roundtrip, test_long_previous_msgid_roundtrip and test_catalog_update_keeps_previous_id_of_fuzzy_message fail without the change. pytest tests/messages: the only failure is test_4_num_plurals_checkers, which fails the same way on master here (my locale data comes from the installed Babel 2.17.0, as the checkout has none).

[codspeed]

Merging this PR will not alter performance

✅ 88 untouched benchmarks

---

_{Comparing jayhemnani9910:fix/read-previous-msgid (09cd25b) with master (3072a70)¹}

Footnotes

1. No successful run was found on master (19d490d) during the generation of this report, so 3072a70 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩