Any translation workflow we adopt must implement the following stages:
- extraction of source strings from Python code (
securedrop_client/**/*.py) to the catalog template (securedrop/locale/messages.pot); - merging of the source strings from the template into each locale's translation catalog (
securedrop/locale/*/LC_MESSAGES/messages.po); and - compilation of each locale's translation catalog from portable-object format (
.po) to the machine-object format (.mo) loaded at runtime.
The following table summarizes the approaches we've considered to date:
| Step/Workflow | reference | current | securedrop-client option A |
securedrop-client option B |
|---|---|---|---|---|
| Implemented in | securedrop |
securedrop-client#1282 | securedrop-client#1347 | securedrop-client#1348 |
(1) extract .py → .pot |
manual via i18n_tool.py during release |
CI against main |
pre-commit hook (enforced by CI) | pre-commit hook (enforced by CI) |
(2) merge .pot → .po |
manual via i18n_tool.py during release |
CI against main |
pre-commit hook (enforced by CI) | Weblate add-on |
(3) compile .po → .mo |
builder playbook via i18n_tool.py during release |
setup.py sdist (or run.sh) |
setup.py sdist (or run.sh) |
Weblate add-on |
We should adopt option A if:
- We want developers to be able to test locally changes that might affect steps (2) and (3) as well as step (1), without requiring these changes to go through Weblate.
We should adopt option B if:
- We want developers' string changes to appear in their commits only in the catalog template, not also in each locale's translation catalog.
- We want Weblate to run as much of our Weblate workflow as possible, rather than using custom code and tooling.
- We want to remove localization-related dependencies from
securedrop-debian-packaging(securedrop-debian-packaging#270).