Admin Translatable Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, and the framing needs correcting first. This is a Symfony bundle, not a Laravel package. It is an extension for FSiAdminBundle (a Symfony admin generator) that adds a locale switcher and per-locale field editing to admin forms. It assumes Doctrine ORM entities implementing KnpLabs/DoctrineBehaviors Translatable (or Gedmo Translatable), and it hooks FSiAdminBundle's own form-event pipeline. None of those primitives exist in Laravel. Fit against a Laravel stack is effectively zero as a library; fit as a pattern reference is moderate.

Integration feasibility — low. It is Composer-installable in principle, but installing it means pulling FSiAdminBundle, its asset pipeline, and Symfony 3.4/4.x-era components into the dependency graph. Even inside a Symfony app, adopting this bundle is a much smaller decision than adopting the admin bundle it depends on — which is the actual commitment. There is no path to using it standalone.

Technical risk — high and concentrated in provenance. Last release 2020-03-25, zero stars, zero dependents, single-vendor origin. Zero dependents is the material signal: there is no production canary, no downstream bug reports, no field evidence the code works outside its author's applications. PHP constraints are almost certainly 7.x; expect deprecation noise and breakage on PHP 8.1+. The opportunity score (4.15) against a package score of 0.28 reads as: the problem (multi-locale admin editing) is real and underserved, but this artifact is not the vehicle.

Key questions. (1) Is the target stack actually Laravel, or is the Symfony assumption baked into the request? (2) Is this being evaluated as a dependency or as a reference implementation? (3) What is the intended translatable storage model — JSON columns or a side translation table? (4) Who owns the fork if adopted, and for how long? (5) Is the requirement "edit every locale in one form," or merely "switch the admin's active locale"? Only the former justifies studying this code at all.

Integration Approach

Stack fit — use as reference, not as a dependency. The transferable concepts are small and worth extracting by reading the source: a locale tab strip bound to form state, per-locale field proxying into a translation collection, fallback-locale display, and single-submit persistence of all locales. That is a design pattern, not a library.

Migration path. (1) Read the bundle (it is small) and write a two-page design note capturing the switcher UX and the form-to-translation data mapping. (2) Reimplement natively: a translations JSON column or entity_translations side table; a FormRequest validating translations.{locale}.{field}; a Blade/Livewire partial with locale tabs and fallback highlighting. (3) Only if the target is genuinely Symfony + FSiAdminBundle should you vendor and pin the bundle itself — and even then, pin to a commit, not a version range.

Compatibility. Symfony 3.4/4.x, PHP 7.x, Doctrine ORM 2.x, KnpLabs/DoctrineBehaviors 1.x. Laravel 10/11: incompatible by construction, not by configuration.

Sequencing. UX pattern first (cheap, zero dependency risk), storage model second, write path third, fallback read path last. Sequence nothing behind a Composer install of this package; any plan where step one is composer require is a plan that stalls.

Operational Impact

Maintenance. Adoption equals ownership. There has been no upstream activity since March 2020 and no maintainer response should be assumed. Budget a permanent in-house fork, or a scheduled replacement, on day one — not when the first PHP upgrade lands.

Support. No vendor, no community, no issue triage. Internal code review is the only safety net. If installed as a dependency, its transitive Symfony packages will accumulate advisories faster than a small team can track them.

Scaling. Runtime cost is negligible — this is form-layer code. The scaling risk is organizational: knowledge concentration in whichever engineer read the source, and a growing fork surface with no upstream to rebase against.

Failure modes. The dangerous ones are data-integrity, not availability: silent locale fallback masking untranslated fields; partial-locale submits dropping previously saved rows; orphaned translation records on entity delete; switcher state desync when the form reloads without persisting. These argue for reimplementing against a schema you control rather than inheriting someone else's persistence assumptions.

Ramp-up. High relative to delivered value. Reading the source requires FSiAdminBundle and DoctrineBehaviors context; a Laravel team will get further from a short internal design doc than from the code itself.

Net position. Do not take this as a dependency. Mine it for the locale-switcher pattern, then build natively — the opportunity score reflects a genuine gap in multi-locale admin tooling, and that gap is better served by 200 lines of owned code than by an unmaintained bundle with no downstream users.