Translation Bundle Laravel Package

Technical Evaluation

Architecture fit — and a framing correction. The brief lists this as a "Laravel/PHP package." It is not. enhavo/translation-bundle is a Symfony bundle — a subtree split of the Enhavo CMS monorepo — and its value is inseparable from Enhavo's DI container wiring, resource layer, entity/model conventions, and admin UI. There is no Laravel integration path here: no service provider, no config publish, no Eloquent trait, no Blade/Livewire surface. A TPM should flag this before any engineering time is spent, because it converts the question from "can we drop this into our Laravel app?" (no) to "is this a signal to shortlist Enhavo for our multilingual content?" (maybe, but only if we are a Symfony shop).

Integration feasibility. Low as a standalone dependency. The README is branding plus a redirect to the main repository — no install steps, no config tree, no API surface, no version matrix. The only supported consumption path is the full enhavo/enhavo distribution; the split exists as a browsable mirror. Pulling the split directly alongside the parent risks double-autoload and class collision. For a TPM the operative conclusion is: this is not a package to evaluate; it is a component to be inherited as part of a CMS decision.

Technical risk. Compounding, and mostly outside our control:

• Read-only mirror semantics. Patches, issues, and security fixes land upstream in enhavo/enhavo and propagate via automated subtree split. That is sync lag and split-integrity risk we cannot remediate.
• Zero adoption signal. 0 stars, 0 dependents, maturity "readme." Not proof of poor quality — proof of no independent user base. No third-party examples, no SO corpus, no reference deployments, thin hiring pool.
• Version drift. Split tags can silently desynchronize from the parent's tagged release; pinning the split independently is a reproducibility hazard.
• Hidden coupling. The real dependency graph lives in the parent composer.json and service definitions, which we have not read.

Key questions to resolve before any commitment.

1. Are we a Symfony shop, or is a Laravel constraint hard? If Laravel, this is closed — use spatie/laravel-translatable and stop.
2. What are the declared composer.json requirements, and do they pin to our PHP and Symfony LTS targets?
3. Does translation storage (schema, migrations) belong to this bundle or a sibling resource bundle? Schema ownership determines migration blast radius.
4. Do split tags match enhavo/enhavo releases, and at what cadence?
5. Who maintains the parent, what is the commit cadence, and what is the bus factor?
6. Does Enhavo architecturally permit partial adoption, or does it assume the full suite ships together?

Verdict. Treat as a component of a suite, not a package to score independently. A scorecard entry here would read near zero and tell us nothing we did not already know.

Integration Approach

Stack fit. Symfony + PHP only. If our app is Laravel, the fit is zero — the correct move is a five-minute substitution decision (spatie/laravel-translatable or astrotomic/laravel-translatable) and this item is closed. If we are on Symfony but not Enhavo, the fit is poor: the bundle's proposition is Enhavo's side-by-side admin translation workflow, which is inert without Enhavo's admin UI, resource layer, and entity model.

Migration path. Two paths, in preference order:

1. Adopt the parent distribution. composer require enhavo/enhavo (or the Enhavo skeleton), then enable translation via standard bundle registration. Only path with an upstream support surface and matched version tags.
2. Fork-and-vendor. If we want only the translation domain model, copy the relevant classes under our own namespace. Decouples us from split drift at the cost of upstream fixes.

Do not add enhavo/translation-bundle as a direct dependency alongside enhavo/enhavo. Enforce that with a Composer conflict rule or a CI check.

Compatibility to verify before scheduling. PHP and Symfony LTS range (Enhavo historically tracks recent Symfony majors; a stale constraint is the most common blocker); Doctrine ORM/DBAL compatibility, since translation entities almost certainly persist relationally; and front-end asset pipeline assumptions (Webpack Encore vs. AssetMapper) against our build.

Sequencing.

1. Week 0 — Discovery spike (2–3 days, timeboxed). Clone the parent, read composer.json, service config, and Doctrine mappings. Deliverable: one-page capability and dependency map.
2. Week 1 — Harness. Throwaway Symfony app with the full Enhavo distribution; create, edit, and retrieve content in two locales end-to-end.
3. Week 2 — Gap analysis. Actual behavior vs. requirements: locale matrix, fallback rules, translator workflow, admin UX, upgrade friction.
4. Week 3+ — Decide suite vs. build. If "build," this package contributes design reference only, not code.

Treat a negative spike result as cheap information and a positive result as conditional approval pending a named owner for upgrades and a contingency if upstream stalls.

Operational Impact

Maintenance. We inherit the upstream Enhavo project's maintenance posture, not a vendor-managed dependency. With 0 stars and 0 dependents there is no visible third-party maintenance community; budget realistically for being close to sole maintainers of any behavior we rely on, via forks or upstream PRs of our own.

Support. GitHub issues against the split are an unproductive channel — the README redirects upstream. SLA is unknown and should be measured, not assumed: open one real issue during the spike and track time-to-first-response. Record the number; it is the single most decision-relevant operational datum available.

Scaling. Technically bounded by the persistence layer (Doctrine + RDBMS) — fine to moderate volumes, potentially expensive at high locale × entity cardinality. The bigger scaling constraint is human: the admin workflow assumes Enhavo's UX, so translator onboarding and throughput matter far more than any technical ceiling.

Failure modes to plan for.

• Split desync. Fix lands upstream, mirror lags, we depend on stale code. Mitigation: depend on the parent suite; pin via parent tags only.
• Silent breaking change. A parent minor bump alters internal service IDs. Mitigation: integration tests against a pinned parent; deliberate upgrades.
• Class collision / double autoload. Both split and parent installed. Mitigation: Composer conflict rule plus CI check.
• Upstream abandonment. Mitigation: keep the translation domain model thin and behind our own interface so it is replaceable.
• Documentation vacuum. Every new engineer reverse-engineers. Mitigation: write the internal "how Enhavo translation works" doc during the spike — required deliverable, not optional.

Ramp-up. Two distinct curves. For an engineer already fluent in Symfony and Enhavo's bundle conventions, ramp is low-to-moderate. For everyone else — and for any team coming from Laravel — expect weeks, not days, and expect the absence of standalone docs to dominate the cost. Plan for exactly one or two engineers to become the internal Enhavo experts, and treat that concentration as a key-person risk in its own right.