Ferrocat And Palamedes

Palamedes is the OSS i18n framework for JavaScript and TypeScript applications. Ferrocat is the Rust-native catalog engine underneath it: the place where translation catalogs are parsed, updated, audited, validated, and compiled into runtime-ready data.

In plain terms: Palamedes helps application developers write and extract messages. Ferrocat makes the resulting catalog trustworthy.

Most people arrive from one of two directions:

• Application teams start with Palamedes because they need macros, extraction, framework adapters, runtime loading, and a clear authoring model.
• Tooling and platform teams start with Ferrocat because they need fast catalog parsing, deterministic updates, catalog QA, conformance evidence, and host-neutral runtime artifacts.

They are meant to connect. Palamedes owns the application integration. Ferrocat owns the catalog behavior that should not be reimplemented separately in every framework adapter.

That boundary includes host bindings. Ferrocat does not ship first-party JavaScript, TypeScript, WebAssembly, or N-API bindings from this repository. JS/TS access is routed through Palamedes, including the palamedes-node N-API bridge in the Palamedes repository. Other host environments should treat Ferrocat as a Rust engine and integrate through the Rust crates, the Ferrocat CLI, or their own host-specific binding layer.

Division Of Responsibility

Layer	Palamedes	Ferrocat
Authoring	Macros, message collection, framework-facing developer experience	Stable message identity inputs and catalog semantics
Extraction	JavaScript/TypeScript transforms and host-aware source scanning	Adapter-ready catalog update inputs, placeholder hints, and semantic metadata validation
Host bindings	palamedes-node, JS/TS package surfaces, and host packaging	Pure Rust crates and host-neutral data contracts
Catalog storage	Uses catalogs as part of the app workflow	PO, ICU-native PO, and FCL catalog modes
Catalog maintenance	CLI workflows and project conventions	Parse, serialize, merge, combine, update, audit, and validate
Runtime delivery	Framework adapters, bundler integration, client/server loading	Host-neutral compiled catalog artifacts and fallback semantics
Future scaling	Chunk-aware sidecars and app-specific delivery policy	Stable compiled IDs and locale-resolved payload generation

Why The Split Matters

Keeping Ferrocat and Palamedes separate gives both projects cleaner boundaries.

Ferrocat can focus on catalog correctness, performance, conformance, and storage contracts without becoming a JavaScript framework plugin. Palamedes can focus on application ergonomics, framework integrations, transforms, runtime wiring, and bundler behavior without duplicating PO parsing or catalog semantics.

Semantic message metadata follows the same split. Palamedes can infer argument types, enum values, tags, component names, and source origins from JS/TS code; Ferrocat can normalize and validate those facts against msgid + msgctxt without owning the JS/TS parser.

Catalog audit reports follow that boundary too. Palamedes can run audit in CI, editors, or release commands and enrich it with project context; Ferrocat owns the generic checks for completeness, stale target messages, ICU syntax, ICU source/translation compatibility, semantic metadata conflicts, and obsolete entries.

That split also makes the ecosystem easier to evaluate. If you need a full app-facing i18n framework, start with Palamedes. If you need catalog infrastructure, start with Ferrocat. If you need both, Palamedes is the natural application layer on top of Ferrocat.

Where To Go Next

• Palamedes repository for the JS/TS framework, packages, examples, and quickstarts
• Ferrocat API Overview for catalog APIs and runtime compilation
• Gettext Task Landscape for the catalog QA and audit direction
• Catalog Modes for PO, ICU-native PO, and FCL storage choices
• Bundler-Aware Message Sidecars for the future delivery model where Palamedes uses Ferrocat artifacts at chunk boundaries