packaging should include compiled gettext MOs

[cfm]

#1348 supersedes the changes described below from #1282. Under #1348, all that remains to do here is:

1. Test end to end that a securedrop-client package includes a messages.mo machine object for each locale and that the client loads these correctly via:
   • Development: LANG=es ./run.sh
   • Production: /opt/venvs/securedrop-client/bin/sd-client from securedrop-client.X.Y.Z+buster_all.deb installed in disposable VM from template with export LANG=es_ES.utf-8; dpkg-reconfigure locales

Target	0.5.1	main	#1294	*.mo in...
PKG_GITREF=		main	1283-package-translations
	✗	✓	✓	python setup.py sdist
	✗	✓	✓	python setup.py bdist_wheel
	✗	✓	✓	securedrop-client_X.Y.Z+buster_all.deb

• Any of the languages available in securedrop_client/locale/* can be loaded with LANG=foo

2. Revert the substantive changes of adds Babel to build requirements securedrop-builder#270: babel is no longer required (after provides tooling for interactive localization updates #1348), but the bootstrap will need to be re-signed. → remove Babel from bootstrap securedrop-builder#283

---

#1282 provides a Make target compile-translation-catalogs to compile the per-locale POs committed by Weblate into the MOs actually loaded by gettext at runtime. While it's acceptable for this compilation step to happen at runtime in the development environment, loadable MOs should be included in production packages, whether compiled as part of securedrop-client CI or during the securedrop-debian-packaging workflow.

1. Python
   1. MANIFEST.in includes *.{po,mo}:

      securedrop-client/MANIFEST.in

      Line 15 in 16b3799

      recursive-include securedrop_client *

   2. python setup.py sdist includes *.po → *.mo
   3. python setup.py bdist_wheel includes *.mo
2. Debian
   • Check: inclusion of *.mo will not break determinism/reproducibility
3. pybabel available in securedrop-debian-packaging context

[cfm]

Updated based on this morning's demo and discussion: securedrop-client will ship with precompiled .mos, meaning that these will be compiled from Weblate's .pos as part of the packaging workflow rather than as part of nightly CI.

[cfm]

As of aa37aab (WIP):

1. python setup.py sdist includes *.po → *.mo

   (.env) cfm@ozymandias{1058}$ python setup.py sdist | grep "\.mo"
   [...]
   copying securedrop_client/locale/es/LC_MESSAGES/messages.mo -> securedrop-client-0.5.0/securedrop_client/locale/es/LC_MESSAGES

2. python setup.py bdist_wheel includes *.mo

   (.env) cfm@ozymandias{1064:1}$ python setup.py bdist_wheel | grep "\.mo"
   [...]
   copying build/lib/securedrop_client/locale/es/LC_MESSAGES/messages.mo -> build/bdist.macosx-10.15-x86_64/wheel/securedrop_client/locale/es/LC_MESSAGES
   adding 'securedrop_client/locale/es/LC_MESSAGES/messages.mo'

[eloquence]

@cfm Could you clarify what's left to do to resolve this issue?

[cfm]

Thanks for flagging, @eloquence. I've updated the description with a new checklist after #1348 based on what I'd left (unhelpfully :-) in #239 (comment).

[cfm]

I've done end-to-end testing to confirm that a securedrop-client package includes a messages.mo machine object for each locale and that the client loads these correctly via:

1. Development: LANG=es ./run.sh
2. Production: /opt/venvs/securedrop-client/bin/sd-client from securedrop-client.X.Y.Z+buster_all.deb installed in disposable VM from template with export LANG=es_ES.utf-8; dpkg-reconfigure locales

#1294 is no longer required, and I've closed it accordingly.

[cfm]

The remaining non-blocking housekeeping chore here has been opened as freedomofpress/securedrop-builder#283, to be included in the next sprint.