Benefits of compiling po files to mo

Question

What's the benefit and primary reason for compiling GNU gettext .po (Portable Object) files to .mo (Machine Object) ?

I saw many programs reading/parsing .po directly.

I'm not using wordpress but on their docs it says:

https://codex.wordpress.org/I18n_for_WordPress_Developers

PO files are compiled to binary MO files, which give faster access to the strings at run-time

Is faster access true? PO can be read only once and cached in some hash table, the same probably goes for MO

Hawking

Answer 1

There are several reasons:

1. You should always compile PO files with msgfmt --check which performs several important checks on the PO file, not only a syntax check. For example, if you you are using printf format strings, it will check that %-expansions in the translation match the original string. Failure to do so, may result in crashs at runtime. There are a lot more checks, depending on the (programming) language.
2. Reading a binary MO file is usually faster and simpler than parsing a textual PO file.
3. PO files often have translation entries that should not be used for production, for example fuzzy or obsolete entries.
4. Many PO parsers are buggy or incomplete.
5. It is part of the gettext API. Translations are expected to be located by default under /usr/share/locale/LOCALE/LC_MESSAGES/TEXTDOMAIN.mo and they are expected to be in MO format, not in PO format. That does, of course, not apply to the countless libraries that just implement a subset of the gettext API.

Jar

Many programs load translation only once on startup. I don't think performance is that important unless loading it every time. – Hawking

Compiling C sources on the fly before executing binaries would also just contribute to their startup time, and still it is a customary thing to do. – Jar

See also reason #5 that I have just added. – Jar

@Hawking I think you are only looking at desktop applications or long-running daemons/services. But for CLI programs, the startup performance is important because they are often invoked from shell scripts, maybe even in loops. – Jar

"Translations are expected to be located under /usr/share/locale/LOCALE/LC_MESSAGES/TEXTDOMAIN.mo" - this seems very odd - why would applications not just keep their translations inside their own folder structure? What else would want to read them? – Greeson

@RobGrant, on Unix systems, applications do no have their own directory structure. The executable images are in one directory (for example /usr/bin) configuration in /etc, application data in /usr/share and so on. Besides, you can change the path to the translation files with the bindtextdomain() library function. – Jar