Project
Why loclizr
The argument this project is built on, and where the claim stops.
i18next, next-intl, Paraglide, Lingui, FormatJS and Intlayer are good libraries; the comparison says when to choose each. loclizr wants two things none of them is built for, in this order:
- Catalog checks, on by default, inside the build that generates the messages.
- A per-message context record that is a deterministic build output.
The runtime is solved
Section titled “The runtime is solved”Lingui removed the runtime parser, next-intl made request-scoped locale work in the App Router, and Paraglide turned messages into typed ESM exports the bundler can shake. Typed message functions are table stakes, so loclizr claims them as parity, never as the headline.
What none of them owns is the contract between code and translations: are the catalogs correct before the build ships them, and does whoever translates a string know what it is for?
Checks exist, as sidecars
Section titled “Checks exist, as sidecars”| Tool | Check |
|---|---|
i18next-cli |
exits non-zero on missing keys |
| Intlayer | gates pull requests on missing content |
@lingual/i18n-check |
validates ICU across locales, with a GitHub Action |
| TMS vendors | placeholder and terminology QA, for a decade |
Each is a step somebody wires into CI, and it gets skipped, even by the tools’ authors: one extractor has returned 0 on failure since 2023, the issue still open.
The claim here is narrow: checking is the default. No configuration of loclizr generates your messages and leaves your catalogs unchecked, because both are one pass over one representation.
Context exists, as discipline
Section titled “Context exists, as discipline”| Tool | Context field |
|---|---|
| gettext | msgctxt |
| FormatJS | description |
| Lingui PO catalogs | file:line and placeholder names |
All optional, so in practice unused, since making them mandatory worsens the quickstart. Since mid 2026 a TMS can also point an agent at your repository to write a sentence or two of context per string, per run.
The difference is shape, and the record is the smaller claim:
| Shape | loclizr’s record | Generated context |
|---|---|---|
| Produced by | a pure function of the tree: same inputs, same bytes | re-derived each run |
| Cost | nothing per run | billed per run |
| Lands | in the pull request, beside the changed string | in a database, after review is over |
The record travels to a human, a model or a vendor without anyone holding an account.
This site quotes no number for how much richer context improves machine translation. The only published figure is one vendor’s, about its own product, and nobody has reproduced it.
Why the gate leads
Section titled “Why the gate leads”Translators and translation-tool builders complain about context loss; developers rarely do. They
run npm install and react to type safety, tree-shaking and framework breakage. The payoff lands downstream of whoever picks the library, which is why no library
owned it, and why a pitch leading with context would lose the room.
So the build gate leads, felt on the first red run, and the record ships underneath in the same pass.
Why now: a human translator reading forty lines of metadata per string gets slower, which is why those fields stayed optional. A model reading them does not, and that consumer is new.
What this is not
Section titled “What this is not”- Not “i18n is broken”. It is not.
- Not an i18next replacement. The one real displacement in this category came when a framework seat opened and its incumbent stalled; there is no such seat here.
- Not per-locale delivery, which needs to own the metaframework’s build.
- Not stable: it is
0.x, and a minor may break.
Honest limits gives the reasoning for each, and Continuity covers the maintainer situation.