Doctrine Translatable Form Bundle Laravel Package

Product Decisions This Supports

• Localized admin editing scope — this bundle exists to reduce the work of building per-locale edit forms for Doctrine entities using the Translatable extension (KnpLabs/DoctrineExtensions). It directly informs the question "how many languages can we support in the admin UI before form tooling becomes a project in itself?"
• Build vs. buy for CMS/admin tooling — if the roadmap includes a multilingual content admin, this package is a candidate "buy" (adopt) option against building custom form mappers around TranslatableListener. Its low activity level is itself an input to that decision.
• Roadmap sequencing for i18n — the existence of a drop-in form layer suggests localization can be sequenced as data model → admin forms → front-end locale routing, rather than as one monolithic i18n epic.
• Platform fit check (important): despite the framing, this is a Symfony bundle, not a Laravel package — it integrates via Symfony's DI container and form component. A Laravel-based product should treat this as a pattern reference, not a dependency.
• Not supported: no evidence of active users, no dependents, and the last release predates Symfony 4. It should not be used to justify an adoption decision on its own merits — only as prior art.

When to Consider This Package

Consider it only if all of the following hold:

• The stack is Symfony, not Laravel, and is pinned to the PHP 5.x/7.x + Symfony 2/3 era (or you are willing to fork and port).
• You already use Doctrine + KnpLabs Translatable (or simettric/doctrine-translatable), and the pain point is specifically authoring translated content in forms, not rendering it.
• You need per-locale form generation as a short-term time-saver on a legacy application with an internal team able to own a vendored fork.
• You are evaluating prior art for a bespoke solution — reading its form-type design is legitimate value even if you never install it.

Look elsewhere if:

• You are on Laravel — there is no integration path; the Symfony form component has no Laravel analogue here.
• You are on Symfony 4+ / PHP 8 — this will not install cleanly, and the 2017 release date means no maintenance, no security response, and no compatibility guarantees.
• You need long-term support — 5 stars, 0 dependents, and a single 2017 release is a strong signal of an unmaintained project. Budget for full ownership or avoid.
• Your translation model is content-level, not entity-level — dedicated translation/translation-management tools, or a CMS, is the better buy.
• You need front-end locale routing, SEO hreflang, or fallback chains — this bundle does none of that; it is form plumbing only.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed Symfony utility that automates one narrow but tedious task — generating the localized form fields editors use to translate content. It is free and readable, but it is effectively unmaintained (last release 2017, negligible adoption). Recommendation: do not adopt as a dependency; treat it as a low-cost reference design if multilingual authoring enters the roadmap. The strategic value is the pattern, not the code.

To engineering: It solves form-side ergonomics for Doctrine Translatable entities — building the per-locale field sets and wiring submission back to the translatable collection. Two caveats before anyone installs it: it is Symfony, not Laravel, and it targets a PHP 5/7 + Symfony 2/3 baseline that will fail on modern stacks. If the team wants the behavior, plan to reimplement the form type against current Symfony Form and TranslatableListener — roughly a few days of work — rather than vendor a nine-year-old bundle with no dependents to catch regressions.

Positioning: Low opportunity, low risk because adoption risk is easily avoided. It is a design input, not a procurement decision.