Migrate localization to hosted Weblate

[All copy below by @cfm mostly from March 2024; transferred here from an internal repository.]

Affected components

• SecureDrop
• SecureDrop Client

People

• Infrastructure has been consulted in freedomofpress/infrastructure#4617 (internal repo).

Problem statement

We currently ask the Infrastructure team to do the care and feeding of our own Weblate instance at weblate.securedrop.org. However, most projects Localization Lab works with just use the hosted Weblate service at hosted.weblate.org, just as most (and we!) use either GitHub or GitLab for code. Neither @adaFPF nor I have been able to come up with a convincing security rationale for special-casing our localization platform in this way.

Solution impact

Any change to our localization platform will affect:

• translators;
• reviewers;
• Localization Lab staff; and
• SecureDrop maintainers, who interact with Weblate most while preparing releases.

Requirements and constraints

Any action we take here:

1. MUST achieve security properties equivalent to the status quo;
2. MAY define those security properties and explain why moving to hosted Weblate would in fact not preserve them; and
3. SHOULD ideally lessen or eliminate Infrastructure's burden in maintaining our own self-hosted Weblate instance.

Exploration

See freedomofpress/infrastructure#4617 for background (internal repo).

Initial proposal

Phase 1: Is this even worthwhile?

1. Contact the Weblate team to ask about pricing for our project: >20,000 source strings, 54 languages, but open-source.
2. Infrastructure, probably @soleilera: Decide whether this monetary cost would be a worthwhile tradeoff from the current time/capacity cost.
3. Optional: Sketch a security model for our use of (a) Weblate for translations versus (b) GitHub for source code.
   • hosted.weblate.org links to and summarizes their use and privacy policies from its registration page.

Phase 2: Will this work for us?

4. Set up a trial of the appropriate Weblate plan.
5. Import freedomofpress/securedrop and freedomofpress/securedrop-client directly from Git.
   • Does continuous localization set up correctly? (This may require testing against our sandbox repositories.)
   • Does translation memory and history import correctly?
   • Are translator attributions preserved, both for (a) those translators who are already registered at hosted.weblate.org and (b) those who aren't? (Via Git, no non-public PII is transferred this way.)
6. Compare (feel free to add to this list):
   • Cookies etc. used by hosted.weblate.org versus weblate.securedrop.org
   • What other projects that use hosted Weblate do in their own tools and processes.

Go/no-go decision between SecureDrop and Infrastructure

Phase 3: Migration

TK, but MUST involve:

• Plenty of lead time before the next release from freedomofpress/securedrop and freedomofpress/securedrop-client
• Coordinating with Localization Lab

Suggestions to consider:

• Lint that pull requests coming from Weblate only touch .po/.mo files
• Test Weblate's user-matching/melding behavior from Git history alone, without our user data

The good news is that the actual switchover should be risk-free, since we won't change anything in our repositories or disable anything at weblate.securedrop.org until we're happy with things at hosted.weblate.org.

Selected proposal

Additional notes

The major thing to call out about this proposal (since we first discussed this informally two weeks ago) is that hosted Weblate would very likely cost us some money. Even if we're comfortable with this proposal on the technical merits, I'll have to defer to the Infrastructure team on the tradeoff between capacity and budget.

Start by reviewing freedomofpress/infrastructure#4617 and the hosted Weblate pricing, security, and trial information. Test importing both repositories from Git, including continuous localization, translation history, and translator attribution. Done means the security and cost tradeoffs are documented, the trial works for both projects, and SecureDrop and Infrastructure have made a go/no-go decision.