Save previous message for fuzzy matches

[maennchen]

Should this be the default behavior or hidden behind a flag?

[whatyouhide]

How does it affect what gets written to the PO files?

[maennchen]

@whatyouhide When we fuzzy match on a message, the new message is in the msgid and the old one will be stored as a previous message.

It will look something like this:
https://github.com/elixir-gettext/expo/blob/d3b6377edf24884f290efcaae1f5e346c39e3555/test/expo/po_test.exs#L500

[maennchen]

@whatyouhide It would probably make sense to handle this the same as #315

[maennchen]

@whatyouhide Do you have an update so that I can finish the PR?

[whatyouhide]

@maennchen sorry for the long wait. I agree, having this behind an option (like :on_obsolete) sounds great. By the way, #| is the "official" GNU Gettext comment for old fuzzy matches, right?

[maennchen]

@whatyouhide I‘ll do that 👍

No, the official way fur fuzzy is the fuzzy flag.

The pipe comment signals the previous mesage.

If I extrat the string Hello World and change it to Hello Worlds, we identify it as fuzzy. We no longer have the initial extracted string though.

With bigger translations, it can be helpful for the translator to know how the message changed so that he can apply the same change to the current translation.

[whatyouhide]

Yeah I’m down for that 👍 My question was: do "previous translations" have an official comment in GNU Gettext?

[maennchen]

@whatyouhide Yes, the #| syntax is official.

See: https://www.gnu.org/software/gettext/manual/html_node/PO-Files.html

white-space
#  translator-comments
#. extracted-comments
#: reference…
#, flag…
#| msgid previous-untranslated-string
msgid untranslated-string
msgstr translated-string

[...]

The previous-untranslated-string is optionally inserted by the msgmerge program, at the same time when it marks a message fuzzy. It helps the translator to see which changes were done by the developers on the untranslated-string.

[whatyouhide]

Ah that's fantastic. Let's go for the option then, and we'll be good to go here.

[maennchen]

@whatyouhide I'll add that in next week 👍

[maennchen]

@whatyouhide I'm not happy with the naming of this option. Do you have a better idea than this?

[whatyouhide]

@maennchen since the behaviours here are not complementary, but rather one a subset of the other, I think we can have store_previous_message_on_fuzzy_match: boolean(). The option name is quite long, but I like that it really conveys what it's doing. Regardless of whether the option is true or false, we'll still override the message and mark it as fuzzy, so the option only controls whether we store the old message too. Thoughts?

[maennchen]

@whatyouhide I agree that a longer more descriptive name is the way to go. I'll adapt accordingly.

[maennchen]

@whatyouhide Done, better?

[coveralls]

Pull Request Test Coverage Report for Build f9f5149cf47d6c99001d57308041fe7f890040c6-PR-316

• 4 of 4 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.07%) to 89.61%

---

Totals
Change from base Build b720495c9700bfcf87fd149e1e796502ba75f858:	0.07%
Covered Lines:	552
Relevant Lines:	616

---

💛 - Coveralls

[whatyouhide]

Awesome work, thanks @maennchen! 💟