Personal Translations Widget Bundle Laravel Package

Product Decisions This Supports

• Localization roadmap scoping. This package is a useful reference pattern, not a dependency: it demonstrates the "translation widget embedded in an entity edit screen" UX (side-by-side locale tabs, inline save) that product teams typically ask for when moving from single-language to multi-language content. It informs the shape of the feature, not the implementation you ship.
• Build vs. buy for the admin translation UI. For a Laravel shop, the honest answer is build (or buy via an admin panel plugin). The widget itself is a thin UI layer over ladela/personal-translations; the expensive part of the feature is the data model and content workflow, not the form controls. This package confirms the UI layer is small enough to own in-house.
• Vendor/dependency risk policy calibration. 2 stars, 0 dependents, and a composite score of 0.07 make this a textbook example for your "unmaintained dependency" gate. Use it to justify (or sanity-check) a policy that requires a minimum maintenance signal before anything enters composer.json.
• Buyer's-remorse avoidance on stack mismatch. Despite the framing as a Laravel/PHP package, this is a Symfony bundle (...WidgetBundle, from the rodgermd/ladela Symfony ecosystem, sitting on top of a personal-translations Doctrine layer). Any decision to "try it in Laravel" is a dead end — that's a decision not to spend two sprints on, and it's worth recording explicitly.
• Interview/estimation input. When estimating "add translation management to the CMS," this codebase is a reasonable 1–2 day spike reference to validate that the admin surface is ~5–10 files of form + save logic, not a multi-week initiative.

When to Consider This Package

Consider it only under the conjunction of all of the following:

• You are on Symfony (not Laravel), with Doctrine ORM and an existing ladela/personal-translations integration already storing per-entity translations.
• The team needs a stopgap admin widget for internal editors and is comfortable forking and vendoring the code, since upstream activity is effectively nil.
• Your framework/PHP versions still fall within the bundle's supported range — verify this before anything else; unmaintained Symfony bundles rot quickly against new major versions.
• The blast radius is small: internal tooling, no customer-facing SLA, no security-sensitive data in the translation payload.

Look elsewhere — decisively — when any of these hold:

• Laravel stack. Use spatie/laravel-translatable or astrotomic/laravel-translatable for the model layer, plus a first-party admin surface (Filament's translatable plugin, Nova's built-in localized fields, or plain Blade). You get maintained code, active security patches, and docs.
• You need a maintained dependency. 2 stars / 0 dependents means no community debugging, no CVE response, and a bus factor of roughly one. That's disqualifying for production content infrastructure.
• Translation is a core product capability — multi-market rollout, translator/vendor workflows, TMS integration (Crowdin, Lokalise, Phrase), review-and-approve states, or per-locale publishing gates. A widget is not a translation workflow; you'll outgrow it in one quarter.
• Content volume or locale count is nontrivial. Doctrine per-entity translation tables need indexing and query strategy decisions this bundle won't make for you.
• You're in a security or compliance review that requires provenance, license clarity, and an active maintainer. Assume this fails and plan accordingly.

How to Pitch It (Stakeholders)

Bottom line: do not adopt. Borrow the pattern, not the dependency.

This is a small Symfony bundle that adds a translations editing widget on top of a per-entity translation layer. It has 2 GitHub stars, zero known dependents, and effectively no maintenance signal. Even if it were a perfect functional fit, the support and security posture make it unsuitable for anything we'd have to stand behind.

Two things make it genuinely useful to us anyway. First, it's a cheap calibration point for scope: it confirms that the "edit translations inline on the entity page" UI is a small, well-understood surface — days, not months — which lets us size the localization epic honestly. Second, it's a ready-made argument for our dependency-review gate: this is exactly the kind of package that looks convenient in week one and becomes a fork we own forever by week twelve.

Recommendation for engineering: implement the same UX natively on our stack. On Laravel that's a translatable model trait plus localized form fields in our existing admin panel — a maintained, first-party path with no vendor risk. On Symfony, if we ever go there, we'd fork the pattern rather than the package.

Ask: no headcount, no budget. Just a decision to not spike on this dependency and to route the localization UI work into our normal admin tooling backlog. If anyone raises this package in a design review, the answer is: pattern yes, dependency no.