consider formal string-review process

[cfm]

In discussion with @creviera this morning about #1317, we articulated that the current processes governing securedrop-client (like securedrop) conflate code review and string review. That is, pull requests merged into main actually merge two different kinds of changes:

1. Code changes—obviously!
2. Changes to text strings presented to users in the CLI and (English-language) GUI. With Add support for community localization #239, the GUI will be available to users in other languages whose translators may provide feedback on these strings, but these strings remain privileged in the .py source files. (The minimal CLI will not be translated.)

@creviera sees two problems with this status quo:

1. A pull request might be functionally approved but blocked for merge pending string changes, involving people other than the developers directly responsible for writing and reviewing its code.
2. A pull request might be merged with "good enough" strings that turn out to need heavy revision, either directly by another developer or prompted by a translator's feedback via Weblate.

It might be worth considering an intermediate-language workflow in which:

1. developers commit good-enough strings during development;
2. maintainers can approve pull requests without wordsmithing; and
3. editors wordsmith ("translate") final English strings in Weblate as part of the overall translation workflow.

NB. I call this "wordsmithing" neutrally! The point is not that the strings are less important than the code. On the contrary, the source strings, like their downstream translations, are self-sufficiently important enough that they may warrant their own process for review and revision, independent of that used for functional code changes. (One could make the same case for other literal and constant values, such as the colors. Unlike UI strings, however, these don't involve dedicated downstream review and revision, with their own workflows and tooling.)

[gonzalo-bulnes]

I'd like to weight in here to support the idea of de-coupling code changes from translatable string updates where possible.

Copy in my opinion is an essential aspect of the user experience (and of the user understanding of the tools, possibilities and risks associated with it). Enabling an autonomous review of the copy would be I believe a step forward towards ensuring that the workflows associated with it are reasonable. (e.g. Waiting for a dev to apply your changes, may not be reasonable if that means you can't organize your work in a sustainable way.)

@creviera Mentioned today (offline) that one option under consideration would be to make use of string identifiers, and treat the English strings as one more translation output. I've worked in the past with strings identified by IDs, in the context of UI components, and I think that is a idea very worth looking into 👍

[eloquence]

If I understand the proposal correctly, in this model we would sometimes merge changes into main that cannot yet be released because they haven't been finalized.

I'm generally in favor of keeping our main branch as close to release-able as possible, as that reduces the cost of shipping small feature increments to our end users. If we accumulate large changes that aren't yet in a release-able state, I worry that it will create a large debt of strings that are still awaiting finalization, which may then cause us to hold back a release.

Basically, if you're looking at a nightly built from main, I would expect it to always look pretty close to a shippable product, with the exception of bugs and regressions that still need to be ironed out.

For features that are still in flux or being prototyped and that use placeholder strings, why not use a longer-lived feature branch (which can also be PR'd into as opposed to just being pushed to)? That would also allow us to solicit early translator feedback before making the strings fully translatable via Weblate.