centralize list of supported languages

[cfm]

Description

The current state of play:

1. Users can only use SecureDrop in a language configured by the instance's administrator. (#2378, #2561)
2. Administrators can only configure languages present in their working copy's securedrop/translations directory. (#2516)

But:

3. [x] To keep translations in sync even if they fall (or have not yet reached) 100% translation coverage, we need to have them present in securedrop/translations. (#6156)

Therefore:

4. [x] i18n_tool.py and securedrop-admin sdconfig need to share a centralized list of supported languages.

This can be thought of as securedrop's companion to freedomofpress/securedrop-client#1438—and as another incremental step away from the securedrop repository itself as the Server's packaging.

User Research Evidence

In #6156, I tried to sync up a language not yet supported and needed a sequence diagram to do it. :-)

User Stories

As a translator, I want to be able to request (volunteer!) a new language to translate without placing a large operational or maintenance burden on the SecureDrop project until and unless the translation can be considered supported and ready to be deployed.

• Currently, a translator can add a new language directly in Weblate, whereupon it will receive the current string catalog but no future updates. This is what's happened with the languages reported in #6156.)

As a Localization Manager, I want to be able to add languages and facilitate their translation when they've not yet reached, or may have fallen below, the 100% coverage threshold to be considered supported.

• Formalize language-support lifecycle: 80% or 90% threshold for losing support?

As a SecureDrop administrator, I (still) want to be able to configure only supported languages, no matter what else may be present in my securedrop working copy.

[cfm]

Breadcrumbs for myself for resuming the work I started last month:

4. [x] i18n_tool.py and securedrop-admin sdconfig need to share a centralized list of supported languages.

This is done in 6387-supported-langauges as of the newly-rebased aa84b1d39c4d0114fe52d708938a727cc3885022.

3. [x] To keep translations in sync even if they fall (or have not yet reached) 100% translation coverage, we need to have them present in securedrop/translations. (#6156)

This is next. It's slightly more involved than it appears, because for each supported language I18NTool.update_from_weblate():

1. first manually git checkouts the latest .po from the securedrop/securedrop Weblate component (and git adds it if updated); and
2. then does the same for the latest .po from the securedrop/desktop component, as specified in the I18NTool.supported_langauges dictionary.

The lazy approach would be:

1. git checkout the glob of .pos from securedrop/securedrop; then,
2. for each .po, check for a corresponding supported_languages entry, in which case check out its .po from securedrop/desktop.

The non-lazy approach would involve enumerating translations for each component separately, either via Git against the i18n remote or via the Weblate API or wlc SDK. I don't think this is worth it, since in addition to being more work it would:

1. decouple the securedrop/securedrop and securedrop/desktop commits, which right now are nicely combined for each supported language;
2. deviate further from i18n_tool.py's current design and make it harder to reason about; and
3. possibly add a new dependency (wlc).

So the lazy approach is what's next!

[cfm]

3. [x] To keep translations in sync even if they fall (or have not yet reached) 100% translation coverage, we need to have them present in securedrop/translations. (#6156)

This lazy approach is done in 3de94cc0ef02417f500d7f23c3426fb8188f083b. For a reviewable pull request, we still need:

• [x] tests updated to pass, in particular the obsoleted case where: https://github.com/freedomofpress/securedrop/blob/2cfb0f90ab28f42c7b7e80eba9144c0509c27933/securedrop/tests/test_i18n_tool.py#L311-L312
• [x] (optional) new tests written for new and changed behavior, such as:
  • ValidateLocales set checks,
  • I18N_CONF checks,
  • I18NTool.commit_changes(), and
  • I18NTool.translated_locales(); and
• [x] a test plan.

@zenmonkeykstop, if you have bandwidth to pick this up over the next week, I'd be very much obliged. Otherwise I think I'll have to let it sit until next week.