Workflow for supported languages


Now that SecureDrop is internationalized (yeah !) we can start merging translations on a regular basis (see the proposed workflow). In the near future we will also publish the first SecureDrop release including supported translations. Each supported language will require more work in QA because the strings modified during the release cycle will have to be verified. Fortunately the localizationlab is a big help and reviewers for French (Alain-Olivier) and Norwegian ( @kingu ) have been active for weeks, doing quality work.

Here is how it could work,

  • at the beginning of each release, the QA time frame (October 17th -> October 24th for the 0.4.4 etc.) is announced to the translators and reviewers in the translation category of the forum and a copy sent to reviewers who are not willing to subscribe to the forum. They get a chance to send a warning in case they are not available during that time. Or if they only have little time to spare for SecureDrop reviews.
  • depending on the reviewers availability, strings changes may or may not be merged in during the release cycle. If there is noone available for review during QA for at least one supported language, it means no string changes can be merged during the release cycle.
  • the release/0.x.y branch is created
  • for each supported language for which there is pending translation work, a friendly reminder is sent to the reviewers
  • during QA the proposed workflow happens daily and is applied to the release/0.x.y branch (which will be merged into develop eventually anyway so the end result is the same)
  • if translations are incomplete at the time of the release, one of the SecureDrop lead (@redshiftzero or @conorsch) decide if the missing translations require to postpone the release date or if they are not a blocker

With many supported languages and a policy requiring they are all perfectly translated, the risk of being blocked is high. That’s mainly what I don’t like about the above but … I don’t know how to resolve that.

What do you think ?

This sounds like a smart workflow - also see my comments on the proposed workflow in

We can see how the 1 week QA + translation review window goes, if there is difficulty to review all translations in that time period, we could further restrict UI changes to a few weeks at the beginning of the release cycle in order to give more time for translations to be completed and reviewed. We are usually pretty light on the UI changes front, so I don’t foresee a problem there. Let’s go with 1 week in line with QA for now and if issues arise we can re-evaluate.

On the topic of incomplete translations - it’s concerning and ideally this would not happen - but if this does happen we have the choice of seeing if we can get rush paid translations to fill in the missing translations, doing automated translations, or pushing the release a few days. As the number of supported languages increases, we can ask Localization Lab about this and determine a backup plan. For example, we could determine what the budget / process / turnaround period is for rush paid translations and consider pushing up the translation review window by the number of days it would take to procure paid translations (if short).

1 Like

Bad idea. I’d suggest to (also?) contact the pool of LocalizationLab, but please don’t even consider automated translations, they’re horrible and dangerous. You might want to differentiate between source and journalist interface; a string not translated for the admin backend is less likely to cause problems.

An initial (paid or other) second pair of eyes for each language would be most welcome imho.

There seems to be a consensus against that idea :slight_smile:

Fair - no automated translations :slight_smile: For what it’s worth, I did also ask this question to Localization Lab yesterday and they agreed that there automated translations should not be done, suggesting that releasing even partial translations is preferable.