Make broken translations a build error, not a support ticket.

None of this comes free with picking Rust. The hot path is written by hand: memchr scanning, NEON SIMD on Apple Silicon, borrowed parsing that never copies the source, and a merge that moves data instead of cloning it. Months of low-level work you inherit the moment you add the crate.

Parsing is mostly raw scanning, and a warm JIT is genuinely good at raw scanning, so the parse gap is the narrowest one on this page. The honest part is admitting that. Updating is the real release-time job: parse the existing catalog, parse the freshly extracted strings, merge by identity, and write it back. Once allocation and serialization dominate, the JIT’s edge fades and the zero-copy, move-not-clone hot path pulls further ahead—which is why the update lead is wider than the parse lead. The GNU msgmerge bar is not a launch-cost artifact either: the benchmark records an empty-run baseline, and its fixed process and I/O overhead is about 2% of the measured time on this corpus, so the gap is real work. The Node baseline, pofile-ts, is our own performance fork of the popular pofile—so the fastest JS parser here is one we built, and Rust still leads it ~3x; the unforked original sits about 220x back. The parse chart uses borrowed, zero-copy parsing; reading into a fully owned model still reaches 362 MiB/s. Serialization runs at about 1.16 GiB/s on the same corpus. Median of 10 runs on an Apple M1 Ultra, every tool reading the same files (pofile-ts 4.0.3, gettext-parser 9.0.2, polib 1.2.0, gettext/gettext 5.7.3, GNU gettext 1.0). Methodology and full report.