Translation Bundle Laravel Package

Product Decisions This Supports

• CMS platform shortlist for multilingual content. This bundle is the translation layer of the Enhavo CMS (Symfony full-stack, MIT). Its existence tells you Enhavo treats translated content — pages, blocks, structured entities — as a first-class modelling concern with a side-by-side editing UI, rather than an afterthought bolted on with message-catalogue string files. That is a legitimate input if the roadmap includes localised marketing sites, multi-region catalogues, or editorial workflows in more than one language.
• Build vs. buy for translated content. The realistic alternative is hand-rolling per-locale entity persistence on Doctrine plus an admin editing surface. This bundle is "adopt open source" rather than "buy" — but only inside Enhavo. It is not a reusable translation library you can drop into an arbitrary application.
• Architecture and supply-chain decision (engineering-led, PM-visible). The package is an explicit subtree split of a monorepo. Adopting it means adopting the release cadence and version constraints of enhavo/enhavo. That is an upgrade-path and dependency-ownership decision the PM should be aware of, because it determines who is on the hook when something breaks.
• Vendor and key-person risk modelling. Zero stars, zero dependents, README-only maturity, and a description that points at another repository. The ecosystem signal is essentially zero — not proof of poor quality, but proof of no independent adoption to lean on.
• What this should not drive. It is not a market signal, not a differentiator you can build a business case on, and not something to place on a dependency scorecard next to mature i18n solutions. It is an implementation detail of one CMS.

When to Consider This Package

Consider it only when:

• You have already selected — or are seriously prototyping — Enhavo as your CMS and need the translation capability present and version-matched to the rest of the Enhavo stack. In practice you will pull enhavo/enhavo or the Enhavo application skeleton, not this repository directly.
• You need a cheap, concrete read on how Enhavo models multilingual content as part of technical due diligence. Reading this split is faster than navigating the monorepo.
• Your constraint is Symfony-native, self-hosted, no SaaS CMS, and you are comparing Enhavo against Pimcore, Sulu, Ibexa, TYPO3, or Sylius rather than against Contentful or Strapi.

Look elsewhere when:

• You are on Laravel — despite the framing in the brief, this is a Symfony bundle with no Laravel integration whatsoever. Use spatie/laravel-translatable or astrotomic/laravel-translatable and move on.
• You want a standalone, framework-agnostic translation component. Use symfony/translation for message catalogues and something like a2lix/translation-form-bundle plus Doctrine behaviours for translated entities outside a full CMS.
• You need semantic versioning guarantees, an independent changelog, community support, or an SLA. A read-only split with no dependents and no standalone documentation gives you none of these; issues are triaged upstream and versions track the monorepo.
• You need proof of production adoption. Zero stars and zero dependents is not a failure verdict, but it means you cannot point to a reference base, and hiring for Enhavo on the open market is thin.

How to Pitch It (Stakeholders)

To executives — one line: this is not a product we adopt; it is a component inside the Enhavo CMS, so the real question is "are we choosing Enhavo?", not "should we use this bundle?"

What to say: Enhavo is an MIT-licensed, Symfony-based CMS with a clean editorial UI and built-in support for complex, structured content across multiple languages. Because translation is native, a multilingual content requirement can be met without licensing a SaaS CMS — a real cost and data-residency win if we are already a PHP/Symfony shop. The trade-off is ecosystem maturity: the project has a small footprint, and this component is a read-only split of the main repository with no independent community, no independent versioning promise, and effectively no third-party adoption signal. We are buying capability at near-zero licence cost while taking on supportability and key-person risk.

To engineering: the bundle is only usable in lockstep with enhavo/enhavo. Expect to track monorepo releases, read the main repository for issues and documentation, and never add the split as an independent Composer dependency in a non-Enhavo application. Budget for writing our own internal "how Enhavo translation works" note during the spike — treat that as a required deliverable, not a nice-to-have.

Recommendation: fund a two-to-three day timeboxed spike — stand up the Enhavo skeleton, model one content type in two locales, run a translator through the admin workflow, and measure upgrade friction. A negative result is cheap. A positive result is conditional approval pending a support plan: who owns upgrades, and what we do if upstream goes quiet. Do not score this package against mature i18n libraries; it will rate near zero and tell you nothing you did not already know.