Translatable Bundle Laravel Package

Product Decisions This Supports

Build vs. buy for the localisation layer. This package is relevant to one decision and one only: whether to buy a translatable-entity persistence layer or build the equivalent in-house. For a Symfony/Doctrine application, in-house means an entity listener, a translation table per translatable entity, locale resolution with fallback, and hydration handling in collections. That is two to four engineer-weeks plus permanent ownership. A maintained bundle at zero licence cost is usually the cheaper answer — which is why this evaluation matters.

Framework scope correction (decision-blocking). The brief frames this as a "Laravel/PHP package." It is not. softspring/translatable-bundle is a Symfony bundle built on Doctrine ORM. There is no Eloquent analogue. If the target product is a Laravel codebase, this is a scoping error and the decision is "close the ticket," not "evaluate further." Confirm the target stack before any roadmap assumption is committed. This single check should be the first item in the next product review.

Roadmap: internationalisation of content-bearing features. If the roadmap includes multi-market content (per-locale product copy, CMS pages, catalogue fields), the choice of translation storage is a now decision, not a later one. Retrofitting localisation onto columns designed single-locale is a schema migration with a dual-read window — materially more expensive than starting with a translation table. This package is one candidate implementation for that slot, alongside a first-party build and a SaaS translation platform.

Licence posture and dependency policy. AGPL-3.0 is a genuine product decision, not a footnote. AGPL's network-use clause means legal review is required before it enters anything that could be construed as a distributed or network-served product. Many organisations maintain an AGPL denylist for product code. If ours does, this decision is closed regardless of technical merit. Route to legal early; it is a one-hour question with a multi-week tail if deferred.

Dependency-risk policy. Zero stars, a single small vendor, no changelog discipline, and a persistence-layer footprint. That combination should trigger whatever threshold we use for "named owner required." The decision this supports is not "adopt or not" but "adopt with an assigned internal owner and a pinning policy, or do not adopt."

What it does not support. Any decision about translation workflow — vendor management, TMS integration, translator tooling, content-ops process. This is storage and retrieval for locale-specific field values. Scope creep into "we'll get translation management too" is a predictable and wrong inference from the name.

When to Consider This Package

Consider it when all of the following hold:

• The consuming application is Symfony with Doctrine ORM, not Laravel or another ORM. This is a hard gate, not a preference.
• We have no existing localisation strategy, or an ad-hoc one we have already decided to replace. Greenfield adoption is a schema-definition exercise; replacement is a data-migration project.
• The content model is CRUD-shaped: fields on entities, edited by admins, read by end users. Translation-table designs fit this well.
• The translatable surface is bounded. Ten to thirty translatable entities with modest field counts is comfortable. Hundreds of entities, or hot-path listing queries over translatable fields, is where join explosion and N+1 hydration become product-visible latency.
• AGPL-3.0 has cleared legal, or the deployment context is unambiguously internal-only.
• We are prepared to pin the version and review diffs per release. With no changelog, this is a recurring cost, not a one-time one.
• Fallback-locale semantics match the product requirement. Specifically: does a missing translation silently fall back to the default locale, or should it surface as missing content? These produce different user experiences and the bundle's opinion needs to match ours.

Look elsewhere when any of the following hold:

• Laravel, or any non-Doctrine data path. Use a first-party Eloquent solution (JSON columns with a locale accessor, or a dedicated translations table modelled directly). The ramp-up to Doctrine alone is measured in weeks for an Eloquent team — that cost dwarfs any saving from the package.
• Localisation spans a search index, document store, or read-model as the source of truth. Entity-listener translation only covers the ORM write path. Everything downstream needs its own locale strategy, and we would end up with two.
• AGPL is disallowed by policy. Stopping here is cheaper than any technical evaluation.
• We need translation workflow, not translation storage. This is a TMS or content-platform decision.
• Query performance on translatable fields is a core requirement. Listing pages that sort or filter by translated values need explicit index and hydration design that a general-purpose bundle will not hand us.
• The team cannot absorb a single-vendor, zero-community persistence dependency. One named engineer must own upgrades and schema review, indefinitely.

Confidence caveat to carry into any decision: the evidence base is thin. The v5.6.0 release note is an auto-generated diff link with no changelog body — no feature list, no deprecations, no migration notes. Version 5.5.10 → 5.6.0 implies a backward-compatible minor bump, but that is inference from a version string, not documentation. Treat any adoption recommendation as provisional until the diff is read and the composer.json constraint changes are confirmed.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: We are evaluating a free, open-source Symfony component that would let us store product content in multiple languages without building that capability ourselves. Two things need to be true before we proceed. First, the target system must actually be Symfony — our initial brief described it as Laravel-compatible and it is not, so we are confirming scope before spending further. Second, the licence is AGPL-3.0, a copyleft licence with obligations that trigger when software is served over a network; legal must clear it before we commit. If both clear, the commercial case is straightforward: it replaces an estimated two-to-four engineer-weeks of build plus ongoing ownership, at zero licence cost, with a manageable dependency risk that we mitigate by pinning the version and assigning an internal owner. The vendor is small with no support contract and an inconsistent changelog, which we should record on the risk register rather than assume away. If either check fails, we build in-house or defer, and we should say so early rather than after a migration.

For engineering — what we are actually asking:

• Gate one, stack fit. Confirm the target is Symfony + Doctrine. If it is Laravel/Eloquent, stop — this is not a candidate, and the cost of adopting Doctrine to use it is far larger than the bundle's value.
• Gate two, licence. AGPL-3.0 needs a legal read against how we deploy. Internal-only and network-served have different answers.
• Gate three, read the diff before recommending. The v5.6.0 note has no changelog. Compare v5.5.10...v5.6.0 directly and check the composer.json constraints. Specifically look for PHP/Symfony/Doctrine floor changes, any entity-listener or hydration changes, and any deprecations pointing at a 6.0 removal.
• Then the technical fit questions. Does the bundle's fallback-locale behaviour match the product requirement, or does it mask missing content? What does the generated schema look like — column types, the (translatable_id, locale) index? What does the schema diff report on a clean install, and is it empty? What do query counts look like on a listing page over translatable fields?
• If we proceed, pin current consumers to ~5.5.10, upgrade one non-production service, review the migration with whoever owns the database, run the localisation tests, then roll forward. Budget recurring time for per-release diff review — with this vendor's changelog discipline, that is a standing cost, and it needs a named owner or it will not happen.

The headline for the decision record: adopt only if Symfony/Doctrine is confirmed and AGPL clears; otherwise this is a scope mismatch or a licensing non-starter, and either conclusion closes the ticket faster than a technical bake-off would.