-
Notifications
You must be signed in to change notification settings - Fork 45
Internationalization
This page is a work in progress. For more information, see https://github.com/freedomofpress/securedrop-client/issues/1304 and https://docs.securedrop.org/en/stable/development/i18n.html.
The SecureDrop Client is piloting a continuous translation workflow that differs from that of the SecureDrop Server:
| Step | SecureDrop | SecureDrop Client |
|---|---|---|
1. Extract strings from .py source code → .pot catalog template
|
manual via i18n_tool.py during release |
make extract-strings (enforced by pre-commit hook and CI) |
2. Merge .pot catalog template → .po catalogs
|
manual via i18n_tool.py during release |
Weblate add-on |
3. Compile .po catalogs → .mo machine objects
|
builder playbook via i18n_tool.py during release |
Weblate add-on |
In this workflow, each party's localization responsibilities are simplified:
-
Developers must use
make extract-stringsto keep the catalog template up to date with changes they've made to UI strings in the Python source code. Developers are encouraged to commitmake extract-stringschanges along with the source-code changes that caused them, for a cleaner Git history to review and (if necessary)blameandrevert.-
CI will enforce this requirement via
make check-stringson branches pushed to this repository. Like the other linters, this check must pass for a pull request to be approved for merge intomain. -
Developers can run
make check-stringslocally or have it run automatically on every commit by runningmake hooks. (make hooksis included inmake venvandmake venv-macas of #1348.)
-
-
Maintainers should keep in mind that pull requests they review will include changes to the catalog template for any strings changed in the source code. They should consider the impact and timing of these changes on translators---just as they consider the impact and timing of code changes on other developers---as part of their review of a pull request prior to approving it for merge into
mainand thereby into Weblate. -
Translators can always see the latest strings available to translate in Weblate. They can translate new and changed strings continuously, as development progresses, and they can give feedback on strings well in advance of the release period.
-
Release and localization managers do not need to do anything special! As summarized above, developers are responsible for keeping strings up to date; Weblate is responsible for keeping the per-language editable
.pocatalogs and loadable.momachine objects up to date.