Add support for community localization

[eloquence]

Given that the current SecureDrop web UI can be fully localized, having the UI of the client in English only represents a regression, which may slow down medium term adoption of the client.

We should ensure that all messages in the client can be localized via Weblate, and document the specifics of the translation process.

This is not strictly required for the beta (which will likely be only with English language newsrooms), though it would be good to lay the foundation for community translations early.

---

1. configure Weblate component #1264
2. review codebase for UI strings to be translated #1265
3. script continuous-localization workflow between GitHub repository and Weblate component #1266
4. SecureDrop Client localization workflow follow-up #1302
5. rework localization Make targets for PR-level use #1317
6. packaging should include compiled gettext MOs #1283
7. draft plans for coordination, documentation, and communications #1304
8. add test suite for running in a translated locale #1398
9. Add list of supported languages; disable unsupported languages #1438

On hold:

• replicate i18n_tool.py list-translators in continuous-localization workflow #1280

[cfm]

Initial findings after familiarizing myself with the status of i18n/l10n in both securedrop and securedrop-client:

1. UI strings here are already (on spot-checking, not exhaustive inventory) wrapped in gettext() calls.

   • Qt has its own translation system, in which the wrapper is QObject.tr(). However, the Qt ecosystem appears to be somewhere between (a) agnostic between its native system and gettext and (b) "just use gettext".
   • UX parity between prototypes and coded client #270 (especially) implies that reusing securedrop's gettext-based workflow and toolchain, and the SecureDrop team's familiarity with them, is an implementation assumption of securedrop-client.

2. I have separately drafted a diagram of securedrop's i18n workflow, which I'll review with @rmol with an eye to:

   1. comprehension on my part :-);
   2. any desired changes to this workflow for securedrop-client, such as experimenting with PR-based and continuous translation; and
   3. whether/how to adapt securedrop's i18n_tool.py for securedrop-client.

[cfm]

In discussion with @rmol: Let's use securedrop-client to test out PR-based and continuous translation (as a prototype for switching securedrop to this workflow as well). This approach will largely obviate the need for a i18n_tool.py or equivalent in securedrop-client except for the functions of:

1. extracting source strings into .pot;
2. listing supported (100% translated) locales; and
   • This designation, and the process for granting/revoking it, might be worth formally reconsidering—though the stakes are lower on the Journalist Interface (and client) than on the Source Interface.
3. giving credit to contributing translators.

These operations might still have to be scripted (either separately or as Makefile targets) for manual invocation, but we should look into automating them fully in CI jobs.

[cfm]

Confirmed this approach with @creviera.

[cfm]

With #1317 done, I've updated the description with the current status of this epic. #1304 is my focus this sprint. We can return to #1283 (which should just require retesting and a securedrop-debian-packaging update) next sprint.

Cc: @eloquence, @creviera

[sssoleileraaa]

@cfm QA for the next release happens on the 31st of May, so I think we'll want to notify folks that we're ready for translation as soon as possible.

[cfm]

Current status, including tasks remaining to hit a May 31 formal start of QA and translation review:

1. Translatability: The securedrop_client/locale/ directory is being updated automatically as a prerequisite to merge into main.
2. Translation: Our wonderful volunteer translators are already keeping up with translation of strings present in main! Draft PR Translations update from Weblate #1315 has the changes that have accumulated since this workflow was first enabled.
3. Testing: Localization is tested both automatically and during manual preflight testing (since tests localization and documents preflight check #1401).
4. Documentation: SecureDrop's "Translations" page covers the Client as well as the Server workflow. The "Internationalization" wiki page gives a technical overview.
   • For internal reference: https://docs.google.com/document/d/1dqukHmTo45weMsPSFonagV6a6d0haXS49nF38WTTaeA/edit
5. Limiting users to supported languages: I've suggested a trivial approach in Add list of supported languages; disable unsupported languages #1438 (comment), which I could implement in the next sprint.
6. Announcements: Drafted, pending team approval.

Any questions or concerns about proceeding as I've outlined here? Anything missing?

[sssoleileraaa]

Thanks for the status update. Could you describe a little more about the process of setting which languages would have their catalogs packaged (based on manually looking at translation percentage)? Like, will there be a last call for translations before a QA period so that we can figure out if we need to update the list before releasing the first rc?

[cfm]

Per #1438 (comment), it would be a change in setup.py, basically one line +/‒ per language enabled/disabled. Since translation is already possible and happening continuously, the pre-release timeline is up to us and Localization Lab. Either:

1. for more testing time: we review and merge translations (e.g.) at the feature freeze and test them during the two-week QA window; or
2. for more translation time: as for the Server, we use the QA period as the official or priority translation window, merge the final translations before building the production packages, and test them during preflight testing.

Since this workflow is continuous, its tooling is stage-agnostic. So we can choose the timeline that will suit us better, both in general and for this first time through. What do you (and @eloquence?) think?

[cfm]

(As requested during yesterday's sprint-planning meeting, I've put finalizing this timeline on the agenda for Monday's Workstation hangout.)

[cfm]

#239 (comment):

1. for more testing time: we review and merge translations (e.g.) at the feature freeze and test them during the two-week QA window; or

2. for more translation time: as for the Server, we use the QA period as the official or priority translation window, merge the final translations before building the production packages, and test them during preflight testing.

Today we decided to go with option (1), so that the release manager can determine which languages to include as supported as part of preparing an RC according to the release checklist.

[cfm]

With today's announcement, translation is officially open in Weblate. All that remains here is #1497, which is ready for review apart from a test that's unexpectedly failing.

[cfm]

Since #1280 is on hold, the planned work in this epic is done. However, I'll leave this epic open until we successfully release one or more translations, which we prepared in #1531 but weren't able to include in v0.8.0.

[cfm]

#239 (comment):

I'll leave this epic open until we successfully release one or more translations, which we prepared in #1531 but weren't able to include in v0.8.0.

However, since then, we have released v0.8.1, which was deliberately branched from v0.8.0, still without translations, rather than from main, where pt_PT (b0dc0d2) and zh_Hans (42aaf10) have been enabled since July 12. I'm going to go ahead and close this epic, since:

1. no more work is planned here, which serves as the basis for adopt continuous localization securedrop#6232;
2. we have preflight QA documented since tests localization and documents preflight check #1401; and
3. we can always reopen this epic, or just file follow-up tickets, for any further work or regressions discovered for v0.9.0.