Object Translation Bundle Laravel Package

Product Decisions This Supports

• Localization architecture: build vs. buy. Choosing a generic object-translation layer rather than hand-rolling per-entity translation tables. This package lets a single Translation entity back translations for any domain object (products, CMS pages, categories) instead of one join table per translatable type — a decision that directly affects schema sprawl, migration overhead, and how fast new content types can be made translatable.
• Roadmap sequencing for i18n. If multi-language is on the roadmap for more than one content type, adopting a generic translation store now avoids a painful retrofit later. Conversely, if only one entity will ever be translated, this is over-engineering — a decision this assessment should force explicitly.
• Content model flexibility. Because translation is decoupled from the owning object, PMs can greenlight "make X translatable" as a low-cost, low-risk increment rather than a schema-migration project. That changes how you cost and slot localization work into sprints.
• Vendor coupling / exit cost. The v1.0.3 change is significant here: translation classes are no longer required to extend a package-provided AbstractTranslation. Your existing entities and base classes stay yours, so adopting (and later removing) the bundle is cheaper. This lowers the "lock-in" line item in build-vs-buy scoring.
• Integration surface with editorial workflows. Translation storage is the substrate for admin UIs, translation-status reporting, export/import to translators, and fallback-locale behaviour. The choice of storage layer constrains what you can promise in the CMS/admin roadmap.
• Migration and coexistence. Teams with existing translation data can evaluate whether this layer sits alongside current structures, which determines whether i18n is a phased rollout or a big-bang migration.

Note: this is a Symfony bundle, not a Laravel package. If the platform decision is Laravel-first, this is a poor architectural fit regardless of feature quality — confirm framework alignment before treating the above as actionable.

When to Consider This Package

Consider it when:

• You have multiple, heterogeneous translatable objects and want one translation mechanism instead of N bespoke tables — the generic-object model is the whole value proposition.
• You are on Symfony with Doctrine and want a maintained, small-surface bundle rather than a bespoke implementation.
• You have pre-existing translation entities or a base-class hierarchy you cannot change. This is exactly what v1.0.3 unlocks: the inheritance requirement is gone, so you can adopt without refactoring your model layer. Before this release, that constraint could be a hard blocker.
• You want a thin storage layer and intend to own the admin UX, workflow, and export tooling yourselves.
• You want low exit cost — the interface-over-base-class direction reduces how much of your domain model is shaped by the package.

Look elsewhere when:

• You are on Laravel. Use a Laravel-native package (e.g. spatie/laravel-translatable) or per-model JSON/column approaches. Do not port a Symfony bundle into a Laravel codebase.
• You need first-class editorial workflow out of the box — translation queues, review states, per-locale publishing. This is a storage primitive; the workflow is yours to build. Budget for it.
• Your translation model is field-level per entity with heavy query needs (e.g. filtering/sorting across many locales at scale). Generic translation tables can produce awkward joins; measure against realistic query patterns before committing.
• You have exactly one translatable entity today and no credible near-term path to a second.
• You need vendor SLA, formal support, or a large community — this is a small, single-maintainer package. Assess bus factor and pin versions.
• Your team has no Doctrine/Symfony depth; the "generic object" abstraction is simple but debugging relational translation joins requires fluency.

Due diligence before adoption: confirm the actual minimum PHP/Symfony/Doctrine versions, verify the release cadence and issue responsiveness, and write a throwaway spike that translates two different entity types end-to-end including a locale-fallback read path — that spike answers most of the questions this assessment raises.

How to Pitch It (Stakeholders)

For executives — one paragraph: We are evaluating a small open-source component that stores translations for any content object through a single, shared mechanism, rather than building a separate translation table every time we add a new content type. The latest release removes a constraint that previously forced our data classes to inherit from the library's base class, which meaningfully lowers both adoption cost and lock-in — our code stays ours, and backing the decision out later is cheaper. The relevant question is not "is this good software" but "will we translate more than one kind of content in the next 12–18 months." If yes, this is a credible, low-cost foundation that makes each subsequent content type cheap to localize. If no, we should not adopt it. Caveat for the room: it targets Symfony/Doctrine, so it only applies if that is our stack.

For engineering — the short version: It is a Symfony bundle providing a generic translation store keyed to arbitrary objects. v1.0.3 drops the requirement that your translation class extend AbstractTranslation; the contract is now interface-based, so existing entities and base classes come as-is. That is the change that makes adoption plausible for us. Trade-offs to weigh: it is a storage primitive only — admin UI, locale fallback policy, and translator export are ours to build; generic translation tables can complicate locale-filtered queries at scale; and it is a small, single-maintainer project, so pin the version and expect to read the source. Recommended next step is a two-entity spike, not a commitment.

What we are asking for: a timeboxed spike (roughly 2–3 days) proving two entity types, one fallback read path, and one admin list filtered by locale. Outcome is a go/no-go, not a rollout plan.