Doctrine Translatable Form Bundle Laravel Package

Technical Evaluation

Architecture fit — the first finding is a stack mismatch. Despite being catalogued here as a Laravel/PHP package, simettric/doctrine-translatable-form-bundle is a Symfony bundle, not a Laravel package. It ships a Bundle subclass, a DI extension, Symfony Form types, and Doctrine event wiring. Its dependency surface is Symfony 2.x/3.x Kernel + Form component + Doctrine ORM + a translatable-listener extension (Gedmo-style). None of that maps onto Laravel idioms: no service provider, no facade, no Blade/FormRequest integration, no Eloquent support.

Integration feasibility into a Laravel application: low, effectively "port, don't install."

• Symfony bundles cannot be registered by Laravel's container; bundle boot logic, tagged services, and Configuration trees have no equivalent without the Symfony FrameworkBundle present.
• Symfony's Form component can be installed standalone via Composer, but the bundle's form types rely on FrameworkBundle-coupled services (locale providers, translation listeners, event dispatchers).
• The translatable behavior itself lives in a third-party listener layer; you would be adopting that dependency chain, not just this package.

Technical risk: high.

• Frozen since 2017-09-18 (~8 years) — no commits, no patches, no compatibility work for PHP 8.x or Symfony 5/6.
• 0 dependents, 5 stars — zero ecosystem validation. No downstream project has proven it works in production.
• API drift: the Symfony 3 → 4/5 transition removed AbstractType::getName(), setDefaultOptions(), and bundle inheritance conventions this code almost certainly uses. On PHP 8+, 2017-era code typically emits deprecations that harden into fatals.
• The 0.91 health score is not a viability signal. For a 5-star, 0-dependent, 8-year-dormant repo it almost certainly reflects metadata completeness (LICENSE present, composer.json well-formed, README) rather than maintenance. The opportunity score of 21.77 is the more honest read: little adoption headroom, low demand.
• MIT license is the one clean item — fork-and-vendor is legally unencumbered.

Key questions to answer before any further spend:

1. Is the target stack genuinely Laravel, or is a legacy Symfony 2/3 service actually in scope? The answer changes everything below.
2. What is the underlying requirement — localized entity CRUD forms with per-locale field editing and fallback? Or just storing translations?
3. Does an existing Gedmo/Translatable listener already live in the codebase? If not, this package's value is marginal even on Symfony.
4. What PHP version is mandated? Anything ≥ 8.1 makes this a rewrite, not an integration.
5. Is there a hard deadline or sunk-cost reason to preserve this specific form UX, or is parity acceptable from a modern library?

Verdict: Do not adopt as a dependency. Retain only as a reference implementation — its form-type design (locale tabs, per-field translation widgets, fallback display) is a useful spec for a small in-house build.

Integration Approach

Stack fit. Treat this as a design reference, not a component. On Laravel the modern equivalents are spatie/laravel-translatable or astrotomic/laravel-translatable for storage (JSON or side-table), plus Blade/Livewire or Inertia form components for the locale-switching UI. The functional gap — "edit one entity across N locales with fallback" — is a UI concern, not a persistence one, and is roughly 100–250 LOC of form + validation + locale-switcher logic in Laravel.

If the stack really is legacy Symfony 2/3 + Gedmo: direct composer require simettric/doctrine-translatable-form-bundle is plausible. Pin PHP to a version the code tolerates, freeze Symfony minor versions, and vendor-fork immediately so you control patches. Budget a spike to confirm the bundle registers and renders one translatable form before committing.

Migration path (Laravel):

1. Spike (1–2 days): model the translation schema (JSON column vs. *_translations side table). Side table wins if you need per-locale querying, indexing, or partial-locale updates; JSON wins on simplicity and read-mostly content.
2. Build (1–2 weeks): translatable trait/model layer + a locale-aware form request with per-locale validation rules + a form UI with locale tabs and fallback indicators + admin screens.
3. Backfill: one-off importer mapping the legacy translation tables into the new shape; write idempotent, re-runnable.
4. Cutover: dual-write or read-shadow for one release, then decommission legacy tables.

Compatibility. No compatibility matrix exists between this bundle and any supported PHP/Symfony/Laravel version. Do not assume one; derive it from the spike, and treat any positive result as an accident of version pinning rather than a supported configuration.

Sequencing. Run the spike in parallel with the "is this really a Laravel project?" question. If the answer is "legacy Symfony," the sequencing is fork → pin → test → containerize. If "Laravel," skip straight to the in-house build; there is no meaningful migration from this bundle because there is no shared runtime.

Operational Impact

Maintenance. You inherit 100% of it. There is no upstream to patch, no CVE feed, no maintainer to ping. Forking into a vendored namespace is the only defensible posture, and that means your team owns PHP-version upgrades, Symfony API drift, and any security surface in the transitive dependency chain.

Support. None. Community support is nil at 5 stars / 0 dependents — expect zero Stack Overflow coverage and zero GitHub issue activity. Any incident is a first-principles debugging exercise against 2017 code.

Scaling. Effectively a non-concern: this is form-rendering and locale-switching glue, not a hot path. Cost scales with entity count × locale count in admin UI complexity (N×M form fields), which is a UX and validation-design problem, not a throughput problem. Watch payload size on entities with many translatable fields — a 20-field entity across 8 locales produces 160 inputs per screen.

Failure modes to expect:

• Listener conflicts between the translatable extension and other Doctrine subscribers (soft-delete, timestampable, versioning) — classic silent-data-loss territory: translations written to the wrong locale or dropped on flush.
• Locale fallback bugs — content appearing in the wrong language, or empty strings masking a missing translation.
• Orphaned translation rows on entity delete if cascade rules are wrong.
• PHP 8 deprecation → fatal escalation on a routine runtime upgrade, with no upstream fix.
• Composer resolution failure once other dependencies require modern Symfony/PHP — this becomes the package that blocks an unrelated upgrade.

Ramp-up. The codebase is small and readable; a mid-level engineer can understand it in under a day. The real ramp-up cost is domain knowledge: legacy Symfony form conventions, Doctrine event lifecycle, and the translatable listener model — skills that are increasingly rare and do not transfer to the team's Laravel work. That hidden cost usually exceeds the price of rebuilding.

Recommendation. Reject as a dependency; approve a 1–2 week in-house build (Laravel) or a fork-and-vendor decision (legacy Symfony only). Reassess the catalogue entry — classifying a Symfony bundle in a Laravel package feed is a screening defect worth fixing upstream, since a 0.91 score could route a less careful reviewer straight into an 8-year-dead dependency.