Admin Translatable Bundle Laravel Package

Product Decisions This Supports

• Localization roadmap sequencing. This bundle models the canonical answer to "how do editors enter content in 5 languages?" — a per-locale tab on the entity edit form. It lets you spec and size that requirement without writing code, and decide whether multi-locale authoring is v1 or v2.
• Build vs. buy (the real output: build the pattern, not the package). The code is a thin extension of a specific Symfony admin stack; the value is the UX contract, not the artifact. You'd port the pattern into your own admin (Filament/Nova tabs, a locale switcher, per-field translation widgets) rather than depend on it.
• Admin UX acceptance criteria. Gives you a concrete checklist to write tickets against: locale switcher placement, per-field translation inputs, fallback-locale behavior, unsaved-change handling when switching tabs, validation of required locales.
• Scope boundaries. Clarifies whether you need scalar-field translations only, or translated relations/collections and localized routing/SEO. The former is cheap; the latter is where projects blow up. This package does only the admin-side slice, which is a useful scope anchor.
• Stack standardization. It's evidence about the FSi/Symfony admin ecosystem (last release 2020). If someone proposes standardizing there, this is the counter-datapoint.
• Whitespace / open-source opportunity. High opportunity (4.15) against near-zero adoption (0 stars, 0 dependents) is a demand-vs-supply gap. Relevant if you're deciding whether to open-source an internal multi-locale admin component — the signal says the idea is wanted, the maintenance is absent.

When to Consider This Package

Frame it as: adopt only under a narrow conjunction of conditions; otherwise mine it for the pattern.

Consider adoption only if all hold:

• You are on Symfony, not Laravel. Despite being catalogued as a "Laravel/PHP package," this is a Symfony bundle with no Laravel integration and none forthcoming — treat the framework mismatch as disqualifying for a Laravel shop.
• You already run FSiAdminBundle + Doctrine ORM + Gedmo/KnpLabs translatable behaviors. Standalone, the bundle is close to valueless.
• You are pinned to the Symfony/PHP versions the March 2020 release supports (Symfony 3.4/4.x, PHP 7.x). It will not install cleanly on Symfony 6/7.
• You need only form-level locale tabs — no translation memory, machine translation, or workflow.

Look elsewhere when:

• Laravel — spatie/laravel-translatable (model layer) plus locale tabs in your admin is the equivalent, and it's maintained.
• Supply-chain hygiene matters — no releases since 2020-03-25, no security patching, 0 dependents means no community to catch regressions before you do.
• You need API responses, localized routing, or hreflang — this is admin-side only.
• You need translation operations (Crowdin, Lokalise, Phrase) — better ROI than an admin tab.
• Your admin is not FSi — the coupling makes a fork's maintenance cost exceed a clean reimplementation.

How to Pitch It (Stakeholders)

Executives. We should not adopt this as a dependency. It's a 2020-era Symfony add-on for one specific admin framework, with zero community adoption and no upgrade path. Its value is as a reference design: it shows exactly what multi-language content editing should look like, which lets us spec and estimate localization work in days instead of weeks. Recommendation: build the capability natively — roughly one to two weeks for scalar-field translations — instead of taking on an unsupported component with no maintainer.

Engineering. Use it as a design reference, not a dependency. The pattern to copy: a translations tab bound to a translatable entity, editing one locale at a time with fallback behavior and validation per locale. Do not vendor it — stale framework constraints, single-maintainer origins, zero dependents. On Laravel, the equivalent is spatie/laravel-translatable plus your admin's form tabs. Worth flagging: the high opportunity score reflects unmet demand for a maintained version of this idea, not the quality of this artifact — which is why a small native build is the higher-leverage move.

Decision in one line: No-adopt; mine for the UX pattern; revisit only if we standardize on the legacy FSi/Symfony admin stack.