freedomofpress
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 can be confusing to translators, to translation reviewers, and (in securedrop-client) to reviewers of translation PRs. We should ask Localization Lab for their advice on keeping or disabling gettext's fuzzy matching.
User Research Evidence
Cross-project concern raised by @gonzalo-bulnes in freedomofpress/securedrop-client#1527. (Filed here since the v2.5.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
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.
Bumping to v2.6.0, so that (after #6557) we're making only one change to our localization tooling in each release.
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.
This is done for securedrop-client in Weblate and prepared for securedrop in #6772, which I'll update to close this ticket upon merge.
#6772 will remove existing fuzzy entries in securedrop's translation catalogs. Weblate won't do the same for securedrop-client's, which I think is fine during the pilot. We can review remaining fuzzy ("needs editing") entries down the road—or, for that matter, for freedomofpress/securedrop-client#1548.
https://github.com/freedomofpress/securedrop/issues/6483#issuecomment-1470941394:
We can review remaining fuzzy ("needs editing") entries down the road—or, for that matter, for freedomofpress/securedrop-client#1548.
I happened to be in the neighborhood, so these are now gone from freedomofpress/securedrop-client#1548.