Repository: freedomofpress/securedrop

Issue:
reconsider gettext's fuzzy matching
## Description

Both `securedrop` (via Babel) and `securedrop-client` (via Weblate) merge source strings equivalent to running `xgettext` *without* `--no-fuzzy-matching`.  These ["fuzzy" entries](https://www.gnu.org/software/gettext/manual/html_node/Fuzzy-Entries.html) can be confusing to translators, to translation reviewers, and (in `securedrop-client`) to reviewers of translation PRs.  We should:
1. [x] ask Localization Lab for their advice on keeping or disabling gettext's fuzzy matching; and
2. [ ] make tooling changes if so recommended.
    - [x] `securedrop`: freedomofpress/securedrop#6772
    - [x] `securedrop-client`: in Weblate

## User Research Evidence

Cross-project concern raised by @gonzalo-bulnes in freedomofpress/securedrop-client#1527.  (Filed here since the ~v2.5.0~ v2.6.0 localization cycle is our next natural point of coordination with Localization Lab, and we might as well be consistent about this between the two projects and their Weblate components.)

## User Stories

*Presumably:*

As a translation reviewer, I don't want to have to guess whether a translation came from a human translator or gettext's fuzzy matching.

As a translation-PR reviewer, I don't want to be confused by apparent errors in incoming translation diffs.



Discussion:
Thanks @cfm for opening this issue and writing the recap!
Bumping to v2.6.0, so that (after #6557) we're making only one change to our localization tooling in each release.
In today's Server hangout: confirmed for v2.6.0.
Localization Lab confirms:

> [F]uzzy translations usually require revision and can contribute to a false sense of productivity and completion with a translation project, so I'd lean toward disabling this support.
For future reference: I flagged specific examples of inadequate `fuzzy`-matched translations in https://github.com/freedomofpress/securedrop-client/pull/1548. If anyone is looking for concrete examples, these are some.

As the Localization Lab folks said, automated translations require review, and that's what we're seeing in those examples. What I'm pointing at is that the automated attempts at translating are not good, and IMHO don't provide much, if any, value to a translator.

Resolving patch:
diff --git a/securedrop/i18n_tool.py b/securedrop/i18n_tool.py
--- a/securedrop/i18n_tool.py
+++ b/securedrop/i18n_tool.py
@@ -102,11 +102,21 @@ def translate_messages(self, args: argparse.Namespace) -> None:
             ):
                 tglob = f"{args.translations_dir}/*/LC_MESSAGES/*.po"
                 for translation in glob.iglob(tglob):
+                    subprocess.check_call(
+                        [
+                            "msgattrib",
+                            "--no-fuzzy",
+                            "--output-file",
+                            translation,
+                            translation,
+                        ]
+                    )
                     subprocess.check_call(
                         [
                             "msgmerge",
                             "--previous",
                             "--update",
+                            "--no-fuzzy-matching",
                             "--no-wrap",
                             translation,
                             messages_file,


Test patch: