Why does the Python gettext module require a compilation step (.po -> .mo) ?

Question

I don't see that the compilation step is adding any value.

Answer 1

I think that the compilation is .po -> .mo

The letters PO in .po files means Portable Object, to distinguish it from .mo files, where MO stands for Machine Object.

MO files are meant to be read by programs, and are binary in nature. A few systems already offer tools for creating and handling MO files as part of the Native Language Support coming with the system, but the format of these MO files is often different from system to system, and non-portable.

GNU `gettext' utilities - 1.4 Files Conveying Translations

Answer 2

Reading just quickly about .mo files, it is clear that:

• It is a machine-readable representation
• It is a hash table

Given gettext's function, to lookup strings by keys at runtime, it is reasonable for this lookup to be implemented efficiently.

Also, it is needed for gettext's performance impact to be negligible; else interest to play nice with the international community would be even lower for english-speaking hackers (from all countries, we all speak english, programming languages are in english).

Making the .mo file an already processed representation is good since

• The format is well suited for quick lookup (hash table)
• The format needs little processing at application launch (custom-representation binary)

Answer 3

Because gettext module in Python follows GNU gettext standards which required to use PO files for do translations by people, and MO files for using by application in runtime. When you're using gettext module you're actually using GNUTranslations class, which name suggests it's implementation of GNU gettext.

But you can provide your own Translations class and load translations from PO files, there is nothing special about it. There is even some implementation of PO files reader in standard Python distribution, see script msgfmt.py in Tools directory.