Currently, the documentation (as well as plenty of other places on the Internet, such as Stack Overflow answers) mentions msgfmt.py and pygettext.py. See https://docs.python.org/3/library/gettext.html
(Python also includes pure-Python versions of these programs, called pygettext.py and msgfmt.py; some Python distributions will install them for you. pygettext.py is similar to xgettext, but only understands Python source code and cannot handle other programming languages such as C or C++. pygettext.py supports a command-line interface similar to xgettext; for details on its use, run pygettext.py --help. msgfmt.py is binary compatible with GNU msgfmt. With these two programs, you may not need the GNU gettext package to internationalize your Python applications.)
The problematic part is: "some Python distributions will install them for you" As a Python distributor, I may ask myself a question: Where do I install those? As a Python user, I may ask: Where did the distributors put them, and did they? So I suggest we make those modules instead and we document how to use them. It might be: $ python3 -m gettext And: $ python3 -m gettext.msgfmt And (provided as a shortcut): $ python3 -m msgfmt I feel that using -m is the general direction Python is going, considering this message: $ pyvenv ... WARNING: the pyenv script is deprecated in favour of `python3.7 -m venv` It also gives the user a choice for Python version on a system with multiple Python versions installed as the user could do: $ python3.6 -m gettext Or $ python3.7 -m gettext While with e.g. /usr/bin/pygettext.py this adds unnecessary burden on the distributor to package /usr/bin/pygettext-3.7.py etc... This idea originates at https://bugzilla.redhat.com/show_bug.cgi?id=1571474 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok