Comparison
Narrower than the alternatives. On purpose.
Palamedes is for teams that like compile-time authoring and want the stack under it to feel smaller, steadier, and easier to trust. Here is how that compares — including when you should pick something else.
01 — Lingui
Palamedes vs Lingui
Lingui is the closest neighbor — same authoring instinct, same source-string-first heart. Palamedes is the stricter end state of that idea: one runtime model instead of several entry points, one native engine for catalogs instead of plugin layers, and adapters that stay thin.
| Criteria | Palamedes | Lingui |
|---|---|---|
| Authoring | Macro-style, JSX-first | Macro-style, JSX-first |
| Message identity | message + context, stable across refactors | Configurable ID strategies |
| Runtime access | One model: getI18n() everywhere | Multiple entry points (i18n, hooks, macros) |
| Catalog engine | Native (Rust/ferrocat), semantic merge & audits | JS-based tooling with plugin ecosystem |
| Extract + update (small corpus) | 174 ms (checked report¹) | 2254 ms (same harness¹) |
| Framework coverage | 5 families browser-verified in CI | Broad, community-verified |
| Maturity & ecosystem | New — honest about it; 16 ADRs document the tradeoffs | Mature, large community, years of production use |
¹ Median of 7 runs on the realistic corpus (1,500 files, 6,000 messages, ~400k lines — half the files not even i18n), same semantic validation — methodology and raw reports in the repo.
Honest note
Pick Lingui if you need its ecosystem breadth or plugins Palamedes doesn't have yet. Migrating anyway? Existing source-string-first .po catalogs are often reusable after an extraction pass; explicit-ID-heavy projects need cleanup — the playbook covers both paths.
02 — next-intl
Palamedes vs next-intl
Different mental model, both valid. next-intl centers on message files with keys and is deeply Next.js-native. Palamedes centers on source strings in your components and stays framework-portable.
Pick next-intl when…
You are all-in on Next.js, prefer key-based message files as the source of truth, and want the most Next-idiomatic API.
Pick Palamedes when…
You write messages in code, want .po catalogs translators already know, or expect to outlive your current framework choice.
03 — General Translation
Palamedes vs General Translation
A category difference, not a feature race. GT is a translation platform — hosted workflows, AI translation, delivery. Palamedes is local-first tooling: your repo owns the catalogs, the QA, and the history. The two concerns can even stack: Palamedes as the local foundation, a service layer on top.
04 — The honest bit
Every tool on this page is good software. The question is which tradeoffs match your team — ours are written down in 16 ADRs, so you can check before you commit.