pybabel extract gets strings from jinja templates automagically and assigns them to the line of the source file rendering the template. This confuses msgmerge into doing the following:
-#: journalist.py:449 -msgid "Two-factor token successfully verified!" -msgstr "Le jeton de validation en deux étapes a été vérifié avec succès !" +#: journalist.py:451 +#, fuzzy +#| msgid "Reset Two-Factor Authentication" +msgid "Token in two-factor authentication verified."
Not sure how to cope with that.
Posted a bug report at http://lists.gnu.org/archive/html/bug-gettext/2017-09/msg00004.html
Hi,
Given the messages.pot[1] and messages.po[2], when calling:
msgmerge --previous --update messages.po messages.pot
it produces the messages.po.updated[3] file. A diff between messages.po and messages.po.update shows:
-#: journalist.py:237 journalist.py:453
-msgid "Two-factor token failed to verify"
-msgstr "Échec de vérification du jeton de la validation en deux étapes"
+#: journalist.py:237 journalist.py:455
+#, fuzzy
+#| msgid "Reset Two-Factor Authentication"
+msgid "Could not verify token in two-factor authentication."
+msgstr "Réinitialiser la validation en deux étapes"
which incorrectly associates "Reset Two-Factor Authentication" as the previous version of the "Could not verify token in two-factor authentication." string and therefore swaps the translations. The messages.po file has the following entry, unmodified in messages.po.updated
#: journalist_templates/edit_account.html:53
msgid "Reset Two-Factor Authentication"
msgstr "Réinitialiser la validation en deux étapes"
The correct behavior would be to keep the original translation. It is always incorrect to assume two different phrases (in this case "Could not verify token in two-factor authentication." and "Reset Two-Factor Authentication") have exactly the same translation.
Cheers
Looks like it might be correct to do that if percentage-wise the translation represents less change.
So correlation for a given length, and it has some use.
It isn’t a huge issue if it doesn’t also happen for the source string.
That being said, i don’t see how it is solvable without having more differentiation of strings.
How to deal with fuzziness is probably configurable from the admin panel of Weblate.
Sometimes it is just a correction where the error is on the side of English only. Other times it is actively wrong, and needs clearing pending a new translation.
It turns out you are correct. Bruno Haible in the bug report thread explained in detail the rationale for the change and it is not a bug.
What confused me was that it was so obvious to me (as a developer) to fix this manually. I’ll update the documentation to suggest all obsolete strings must be verified carefully and possibly fixed manually to save work for the translators.