Translations update from Weblate

[weblate-fpf]

Translations update from Weblate for SecureDrop/SecureDrop Client.

Current translation status:

[cfm]

Per #1516 (comment), note that this diff still shows some flapping newlines, because this pull request doesn't contain any new commits from Weblate's .po exporter. I think the path of least resistance is to let the flapping resolve in subsequent commits, whether in this or a future pull request from Weblate.

[gonzalo-bulnes]

@cfm Should we squash those (or most of those that don't have multiple authors) commits, and sign the result after visual inspection? I think I'd be keen to doing so, what do you think?

[gonzalo-bulnes]

@cfm and I had an offline chat about

Context

1. Only the strings belonging to an enabled language are packaged with new releases
2. Weblate will create a PR and keep it updated:

• every time a string changes
• making one commit per language
• ensuring that if new changes come in, the commit always reflect them (on an hourly basis)

Decisions

• Because only the strings belonging to an enabled language are packaged with new releases (1):

  • Incorrect translations in non-enabled languages are therefore not concerning.
  • We're comfortable integrating non-enabled languages on a regular basis.

• Because enabled languages can be used by journalists after each release:

  • Enabled languages need to be reviewed for correctness before each release (more on that below)
  • 🍒 As long as that review is performed before release, we're comfortable integrating enabled languages on a regular basis as well.
  • 💡 If the level of support for any given language ever became insufficient to ensure correct translations are shipped for each release, we can disable support for that language.

Reviewing strings

Translated strings need to be reviewed for:

• Validity: to make sure they don't break the localization system. (Weblate is unlikely to produce invalid strings / PO files.)
• Correctness: to make sure they're accurate, with the following in mind:
  1. Inaccurate strings can be unsafe (e.g. HTML/JS injections, misleading instructions)
  2. Inaccurate strings can reduce accessibility (e.g. confusing grammar or terminology)
  • There can be overlap between both concerns (e.g. people can make dangerous mistakes if things are unintentionally unclear)

🍒 The safety aspect of the review happens in GitHub, either when Weblate opens a PR or at the very least before each release. The accessibility aspect of the review can happen in Weblate, in conversation with the localization team, but MUST be taken into account before each release to evaluate the level of support that each enabled language actually has.

---

Weblate/GitHub flow

• Review and merge Weblate PRs whenever convenient, Weblate will keep its PRs updated, so there is usually no rush.
• 🔥 Before each release, perform a thorough correctness review of all changes affecting supported languages.

---

Longer term vision

Localization is an integral part of building accessible user interfaces. We recognize that there is a collaboration opportunity between engineering/design/research (FPF) and the translation/localization team. This is a first step towards making it possible for translations to happen at any time during the release process, instead of only within a few days prior to each release.

We take this step as an incremental step towards a more collaborative integration with the translation/localization team, and aim at tightening those ties over time. 💚

Examples of what we'd like to achieve through closer collaboration:

• Making sure translators have the clear context they need to understand the intention behind each copy decision. (e.g. Was "Reply" a noun or a verb in this context?)
• Making sure the original copy (English) is refined to make as many translations as possible unambiguous / easier. (e.g. distinguishing different concepts that may originally be covered by the same word in English, if that makes the copy clearer and the translation less error-prone.)
• Improving our ability to identify design changes to improve how the user interface can be localized effectively: e.g. buttons behavior when rendered in a RTL/LTR/mixed context, awareness of connotations attached to different icons in different locales etc.

CC: @tina-ux 🙂

[gonzalo-bulnes]

With the above in mind, I'll take a fresh look at this PR and merge it.

(We also said it would be nice for all languages to use the commit message template that includes the language name, but that's not a blocker.)

[cfm]

Thanks for summarizing, @gonzalo-bulnes! I think everything you've outlined is consistent with the current overview, but feel free to make (or suggest) any changes there too.

[gonzalo-bulnes]

I'd outline an explicit responsibility for the release team to verify the quality of the translations as much as possible. (Because the strings come otherwise from an external group of people, and we're the last opportunity to check them before they make their way to the journalists' workstations.) Let's think of the phrasing together. (And thanks for adding the reference here @cfm, it's great context!)

[sssoleileraaa]

Since translations are all disabled by default and MANIFEST.in doesn't have any included languages yet, this seems fine to pull into this upcoming release

[gonzalo-bulnes]

Oops, I forgot documenting my approving review!
I'm merging now 🙂