Skip to content

Internationalization

Cory Francis Myers edited this page Dec 9, 2021 · 11 revisions

Internationalization (i18n)

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:

  1. Developers must use make extract-strings to keep the catalog template up to date with changes they've made to UI strings in the Python source code. Developers are encouraged to commit make extract-strings changes along with the source-code changes that caused them, for a cleaner Git history to review and (if necessary) blame and revert.

    • CI will enforce this requirement via make check-strings on branches pushed to this repository. Like the other linters, this check must pass for a pull request to be approved for merge into main.

    • Developers can run make check-strings locally or have it run automatically on every commit by running make hooks. (make hooks is included in make venv and make venv-mac as of #1348.)

  2. 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 main and thereby into Weblate.

  3. 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.

  4. 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 .po catalogs and loadable .mo machine objects up to date.

Clone this wiki locally