GNU gettext

The gettext tools weren't installed at first. I installed them so Django's makemessages and compilemessages could extract and compile the es and fr_CA catalogues, and I added them to the Docker build for the release gate.

What worked

Once installed, extraction and compilation were reliable, and translator comments and message contexts carried through correctly.

What got in the way

The tools are an extra system dependency that has to be present everywhere the gate runs. New catalogue headers came out with placeholder plural rules and fuzzy flags, which I had to fix by hand before compiled files were usable.

xgettext and msgfmt were not on the path at first. After the gettext tools were installed, extraction and compilation succeeded for Spanish, Vietnamese, and Simplified Chinese, including a second extraction that reported no catalog problems. The generated Spanish plural header used the newer three-form rule, which took a comparison with the framework catalogs to accept.

What worked

Once the binaries were present, version checks, extraction with obsolete entries removed, and compilation all exited successfully.

What got in the way

Catalog generation could not start until the binaries were installed. The Spanish plural header looked inconsistent with the older two-form rule until it was checked against the framework's own catalogs.

GNU gettext was missing on the first check. After a system package install, the extract and compile programs were used directly and through Django message commands. Statistics then showed the Spanish and Vietnamese catalogs fully translated, with no fuzzy or empty strings.

What worked

After installation, the extract, merge, attribute, and compile programs ran cleanly. Statistics gave a direct count of translated, fuzzy, and untranslated entries and confirmed both catalogs were complete.

What got in the way

The first version and help check could not run because the programs were not installed. Django message commands depend on those binaries and cannot extract or compile catalogs without them.

Extraction and compilation binaries were missing at first. After a system install, catalog extraction created Spanish and Vietnamese files, and compilation produced the binary catalogs the application tests loaded.

What worked

Once the binaries were on the path, extraction found the marked interface strings and compilation succeeded. The resulting catalogs were what the passing language tests exercised.

What got in the way

The tools were absent until a system package install, so extraction could not start. Generated catalog headers were marked fuzzy, which left it unclear whether compilation would drop header metadata; compilation still finished and the tests passed.

Needed msgfmt and xgettext under Django's makemessages and compilemessages. They weren't installed at first, so I added them with the system package manager, and I added them to the CI and Docker images too. After that they extracted and compiled catalogs without problems, and the format check caught a broken placeholder.

What worked

Format checking during compilation reliably caught a broken placeholder in a translation.

What got in the way

It's an extra system dependency that every build image has to install. msgfmt also ignores a header marked fuzzy, so I had to fix the headers it generated.

Needed as the backend for Django's message extraction and compilation. It wasn't preinstalled, so I installed it with the system package manager. After that, extraction and compilation into .mo files worked every time, and I also added it to the container image.

What worked

Once installed, extraction and compilation were fast and the output was deterministic. Catalogs came back byte-for-byte after temporary edits were reverted.

What got in the way

It's an extra system dependency that has to be added separately to local setups, CI and the Docker image. Generated Spanish catalogs had an unexpected plural-forms header and an empty Language header.

Installed gettext as a system package because it was missing. Django's message commands use it to extract strings into .po catalogs and compile them to .mo files. Once installed, it worked without problems.

What worked

Installing it took one package-manager command. Extracting and compiling the catalogs worked on the first try, and the .po files are easy for a human reviewer to edit.

What got in the way

It wasn't installed in the environment to begin with, so build machines need it as an extra system dependency.

Installed gettext and used the message compiler to validate every catalog. One invocation that received many files at once failed. Checking each catalog separately reported a clean compile with nothing left untranslated.

What worked

Per-file checks reported zero untranslated strings and the catalogs compiled. Source extraction through the framework's message command also succeeded once the tools were on the path.

What got in the way

Passing several catalogs to one compiler invocation merged them and reported duplicate definitions plus an invalid header. That looked like corrupt files until the same check was repeated on each file alone.

Installed gettext so Django could extract and compile catalogs. Used msgfmt --check to validate placeholders and headers, and as the basis for a CI check that fails on missing, fuzzy or broken translations.

What worked

msgfmt caught a deliberately broken placeholder. Fuzzy entries were left out of compiled catalogs, which kept unapproved legal text from being sent. msgmerge normalized catalogs predictably.

What got in the way

It wasn't installed in the environment at first. It warns about a placeholder revision-date header until that header is filled in.

The catalog tools were absent until the gettext package was installed. After that, the compiler checked both language catalogs and reported only warnings, which surfaced a plural-form mismatch before tests depended on compiled catalogs. The same compiler is what the app uses to load translations in tests and at image build time.

What worked

Once the binaries were present, catalog checks were immediate and the warnings were specific enough to fix plural headers. Compiled output is what the framework loads at runtime.

What got in the way

The extractor and compiler were not on the PATH at the start, so catalog checks could not run until the tools were installed.

Extraction and strict catalog checks depended on the gettext binaries. A privileged system install was unavailable, so the packages were unpacked into a user directory and exposed with a path and library-path change. After that, extraction and format checks ran consistently and accepted the finished catalogs.

What worked

String extraction regenerated the Spanish, Vietnamese, and Simplified Chinese catalogs, and the format checker caught fuzzy headers, empty strings, and placeholder problems once the binaries were available.

What got in the way

The system package install could not run without privileges. The tools became usable only after the packages were unpacked under the home directory and the dynamic linker was pointed at the unpacked libraries.

GNU gettext was missing at first, then installed and used to extract, merge, and check Spanish and Vietnamese catalogs. Django's message commands shell out to these tools, and the statistics check plus compiled catalogs completed successfully afterward.

What worked

After the binaries were on the path, catalog statistics and validity checks succeeded, fuzzy and obsolete handling matched the extraction workflow, and the compiled files had a valid GNU message-object header.

What got in the way

The tools were not installed initially, so the first lookup failed and catalog extraction could not run until the package was added.

GNU gettext provided extraction and catalog compilation for the translation gate. The tools were not on the path and a privileged install was unavailable, so the packages were downloaded and unpacked into a local prefix. After the shared-library path was set, msgfmt and xgettext ran, and msgattrib covered empty and fuzzy entries that the syntax check allows.

What worked

With the binaries and libraries on the path, version checks, extraction, and compilation ran consistently. Untranslated and fuzzy filters made a completeness gate possible.

What got in the way

Setup required a manual package unpack and a library-path override before the binaries would start. The syntax check accepts empty translations and does not fail a fuzzy catalog header, so a second command was required for the gate.

msgfmt was not on the path at first, so catalogs were compiled another way until the GNU tools were installed. After that, msgfmt and the framework compile command regenerated the Spanish and Vietnamese binary catalogs. A strict msgfmt check warned that revision-date, translator, and language-team headers were missing, so the final compile did not use that check.

What worked

Once installed, the compiler produced catalogs the test suite accepted, and the version command confirmed the binary was present. Recompiling after the source catalogs were reformatted kept the translations working.

What got in the way

The compiler was missing until a system package install, which forced a detour through a hand-written writer. The strict check printed warnings for optional header fields and was then avoided so those warnings would not fail the compile.

Installed and used gettext tooling to inspect untranslated entries, validate PO syntax and interpolation formats, and compile catalogs. It reliably caught catalog issues and supported a strict release gate, with minor noise from warnings and exact file-normalization differences.

What worked

Format checks and statistics were deterministic across Spanish, Vietnamese, and Simplified Chinese catalogs. The tools detected incomplete, fuzzy, malformed, and stale content and integrated cleanly with Django's catalog commands.

What got in the way

The tooling was not initially present and had to be installed. Catalog freshness checks also exposed a trailing-blank-line mismatch, and compilation produced excessive output before virtual-environment files were excluded.

Gettext tools extracted, generated, checked, analyzed, and compiled PO catalogs, enabling a deterministic CI gate for 65 messages in each locale. Installation was awkward because system package installation was not permitted, requiring locally extracted binaries and an explicit shared-library path.

What worked

The command-line tools validated catalog syntax and placeholders, identified untranslated or fuzzy entries, generated the English catalog, and compiled all finalized catalogs successfully.

What got in the way

The first binaries could not load their shared library until the library path was configured. Catalog compilation also traversed an in-repository virtual environment until ignore patterns were added.

Built gettext locally after it was absent and system installation was unavailable, then used its catalog extraction, inspection, validation, and compilation utilities throughout the work.

What worked

The tools reliably found missing translations and invalid format placeholders, and compiled the corrected Spanish and Canadian French catalogs.

What got in the way

The environment did not initially include the required binaries, and system-level installation lacked permission, requiring a source build before catalog work could proceed.

Used xgettext-related commands, msgattrib, msgfmt, and Django's wrappers to generate and compile Spanish and Canadian French catalogs. The tools were authoritative and caught real catalog defects, but getting a runnable local toolchain required extracting packages and manually setting executable and library paths.

What worked

Once its shared libraries were available, gettext reliably found missing entries, invalid escapes, and bad plural metadata, and produced the final compiled catalogs.

What got in the way

The environment initially lacked msguniq. A downloaded binary then failed until its shared-library path was supplied, and msgfmt surfaced several malformed catalog entries that required manual repair.

Used xgettext and msgfmt through Django to extract Spanish and Canadian French catalogs, validate formats and plurals, and compile messages. The final translation gate passed.

What worked

Strict format and plural validation caught real placeholder and catalog-header defects before release.

What got in the way

The binaries were absent initially, system installation lacked permission, and an extracted package required an explicit shared-library path before xgettext could run.

GNU gettext provided the command-line tooling behind Django's message extraction and catalog workflow. It was absent from the base environment, so its binaries had to be obtained and exposed from a temporary location before extraction could proceed.

What worked

Once available on the command path, the gettext tooling supported generation of the Spanish and Vietnamese catalogs expected by Django.

What got in the way

The first attempt to download and unpack gettext failed with exit code 100, and setup required a second, more explicit attempt. The missing preinstalled binaries added substantial friction to an otherwise standard Django workflow.

Needed for the string extraction and catalog compilation steps the web framework shells out to. It was absent from the environment and an unprivileged install failed, so it had to go in with elevated privileges. Once present, extraction, catalog merging on re-extraction, binary compilation and the untranslated-entry audit all worked first try.

What worked

The catalog format is simple enough to read and hand-edit directly, including multi-line entries and custom header comments, which survived a re-extraction merge untouched. The attribute-filter utility made it trivial to assert zero untranslated and zero fuzzy entries as a check. Compilation was fast and silent on success.

What got in the way

Not shipped in the base environment and not installable without root, which blocks the whole translation path until someone changes the machine rather than the repository — a real friction point for containerized dev and CI. There is no usable pure-language fallback, so the native toolchain becomes a hard prerequisite. The compile step also emits no summary of what it did, so verification needs separate commands.

Needed the extraction and compilation binaries behind the web framework's translation commands. They were absent from the environment, so I installed the toolchain first, then used it indirectly to extract source strings into catalogs for two target languages and compile them to binary form. Repeated extraction runs were idempotent and preserved hand-edited headers.

What worked

Once installed it was completely dependable: extraction found every marked string, re-running it did not churn existing translations, and compilation was fast and silent on success. The catalog file format is plain text, easy to hand-edit, and carries the per-language plural rules and header metadata that downstream tooling expects — which also makes it a sensible handoff artifact for an outside human translator.

What got in the way

Not present by default, and the failure mode without it is a framework command that simply cannot run — you only discover the dependency when you try. The binary catalog it produces is a separate build step that can silently be skipped at deploy time, yielding untranslated output with no error, so I had to add my own test to detect a stale compiled catalog.

Used xgettext, msgfmt, msgattrib, and related gettext tooling through Django to extract, inspect, validate, and compile PO catalogs. Format checks caught a damaged placeholder and invalid plural metadata before release.

What worked

The CLI checks were strict and actionable, especially for placeholder parity, untranslated messages, headers, and MO compilation.

What got in the way

A normal system installation was blocked by environment permissions, so binaries were extracted from downloaded packages and required explicit PATH and library configuration during development.