Sonata Translation Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for back-office translation editing. This package is a glue layer that surfaces the Lexik translation editor (database-backed translations) inside Sonata Admin. If your product decision is "content editors should own copy changes without a deploy," this is the cheapest possible path to that outcome — no new SaaS contract, no separate admin surface, no translation export/import workflow.
• Roadmap sequencing for localization. Deciding when to invest in editor-facing translation tooling vs. shipping features. If you are already on Sonata Admin and LexikTranslationBundle, this is a days-not-quarters enabler; it unlocks "add locale N" conversations without an engineering-heavy prerequisite.
• Who owns copy: engineering or content. Every translation workflow decision is really an ownership decision. Adding an in-admin editor shifts ongoing copy maintenance off the sprint backlog and onto the editorial team — a headcount utilization decision as much as a technical one.
• Internal-tooling investment threshold. With 1 star, 0 dependents, and a low composite score, this is a "vendor/bundle as a starting point, not a dependency" decision. The PM decision is less "adopt this" and more "is a 1–2 day spike + potential in-house fork cheaper than 6 months of XLIFF handoffs?"
• Multi-locale go-to-market. If roadmap includes launching in additional markets, editor self-service translation is a prerequisite. This package is a candidate enabler; it is not the whole answer (no TMS, no vendor review workflow, no translator marketplace).

When to Consider This Package

Adopt only when all of the following hold:

• You are already running Symfony + Sonata Admin, and already use (or have decided to use) LexikTranslationBundle with database-stored translations. The bundle is an integration shim; without both parents it delivers zero value.
• The admin is internal-facing (staff, editors, ops) — not a multi-tenant or customer-facing surface where an unmaintained dependency's security posture matters more.
• You have engineering capacity to vendor or fork it. Treat it as sample code you are adopting, not a supported library.
• You have cleared the license. The repository reports NOASSERTION, meaning no recognized SPDX license was detected. Legal must confirm terms in writing before it ships in anything commercial. This is a hard gate, not a nice-to-have.
• Your alternative is worse: manual XLIFF editing in git, or a spreadsheet-and-ticket workflow.

Look elsewhere when:

• You are not on Sonata Admin — use LexikTranslationBundle's own admin UI, or a standalone CRUD, rather than adopting a whole admin framework for one screen.
• You need a supported, SLA-backed, security-patched dependency. Zero dependents and a single star give you no community safety net; you are the maintainer in practice.
• You need translator workflows — review states, vendor handoff, translation memory, contextual screenshots, word-count billing. That is a TMS (Crowdin, Lokalise, Phrase, Weblate) decision, not a bundle decision.
• PHP/Symfony versions have moved past the bundle's supported range. With no visible maintenance signal, verify compatibility on your target stack before you commit roadmap dates to it.
• Sonata's own SonataTranslationBundle (or a maintained equivalent) covers the same ground — prefer the option with a live maintainer.

How to Pitch It (Stakeholders)

For executives: Small, low-cost internal tooling that lets content and marketing staff update translations directly in the back office instead of filing engineering tickets and waiting for a release. The upside is turnaround time and reduced engineering toil on copy changes — measurably fewer "fix this string" tickets per sprint and faster market launches when we add locales. The caveat is real: this is an unmaintained open-source integration with essentially no adoption, and its license is not machine-declared. Position it as a short spike to validate, with a small internal fork budgeted, rather than a strategic dependency. Do not present it as "free" — the true cost is a few engineer-days plus ongoing ownership.

For engineering: It is thin glue between Sonata Admin and LexikTranslationBundle. Expect to read the source rather than the docs, pin the exact commit, and own upgrades. Before committing: confirm the license text, run a compatibility check against our Symfony/PHP versions, and scope an exit path (the Lexik UI, or a minimal custom CRUD) so we are never trapped. If we adopt, we vendor it and add it to the dependency-review list.

Recommendation: Conditional go — timeboxed spike only, contingent on license clearance and stack compatibility; otherwise build a small in-house admin screen or buy a TMS.