Skip to content
Ferrocat
⌘K

Project Status

Current strengths, roadmap themes, compatibility policy, and long-term direction for Ferrocat.

Ferrocat is a stable, production-ready Rust project. Since the 1.0 release the public API follows semantic versioning, so breaking changes ship only in a new major version and applications can depend on it with confidence. The focus stays product-facing: make translation catalogs easier to update, validate, audit, compile, and ship.

Current strengths

  • translation catalogs that preserve source identity, translator context, comments, source origins, plural entries, and obsolete entries
  • deterministic parsing, serialization, merge, combine, and update workflows
  • AI translation metadata for machine-generated entries, with compact PO/FCL storage and stale-metadata cleanup after text edits
  • release-oriented catalog audit reports for completeness, stale entries, ICU issues, metadata conflicts, and obsolete entries
  • rich-message parsing and diagnostics for placeholders, formatters, plurals, selects, and tags
  • normalized catalog APIs plus runtime compilation and requested-locale artifact generation
  • conformance and benchmark infrastructure treated as product features

Compatibility policy

  • MSRV: 1.93.0
  • MSRV policy: align with OXC when practical, while avoiding churn from tracking only the newest stable toolchain
  • MSRV bumps: raising the MSRV is treated as a minor-version change and called out in the changelog; patch releases should not raise the MSRV.
  • Prebuilt CLI target: x86_64-unknown-linux-musl is validated in CI and published as a smoke-tested GitHub Release archive for ferrocat-cli.
  • Semver: the public API follows semantic versioning; breaking changes ship in a new major version and are documented in the changelog
  • Documentation: README examples, rustdoc, and repository docs aim to stay aligned
  • Host bindings: Ferrocat is currently a pure-Rust engine. JS/TS access belongs in Palamedes and its palamedes-node bridge; other hosts should use the Rust crates, the ferrocat-cli command-line interface, or their own binding layer.

Roadmap themes

  • more catalog workflow APIs inspired by practical translation-maintenance jobs, especially filtering, attribute transforms, and structured completeness checks
  • deeper runtime/catalog workflows on top of the compiled catalog layer
  • broader cross-ecosystem tooling on top of the ferrocat-cli foundation, especially host-specific bindings that stay outside the Ferrocat core crate boundary unless a future ADR deliberately changes that split
  • continued conformance growth and publication-grade benchmarking discipline

MessageFormat 2 is deliberately not a near-term roadmap item. Ferrocat tracks it as an important future standard, but the current implementation focus stays on ICU MessageFormat v1 parsing, authoring diagnostics, conformance, and runtime artifact validation because those solve the more immediate catalog problems without taking on a second transitional message syntax.

Why the project direction matters

Today Ferrocat is Rust-first. The longer-term goal is broader: a trustworthy translation core that can serve multiple ecosystems from one implementation, without forcing each host environment to re-implement catalog semantics, compiled key derivation, and locale resolution separately. That does not mean every host binding belongs in this repository. The core contract is the Rust API plus host-neutral formats and diagnostics; Palamedes, the ferrocat-cli, or host-specific adapter projects can expose those contracts to application environments.

Follow-up reading