Polyglot Bundle Laravel Package

Product Decisions This Supports

• Localization roadmap sequencing. The bundle is a concrete implementation of the "polyglot persistence" pattern for Doctrine entities: translated fields live in a companion translation entity keyed by locale, and TranslatedProperty / Locale attributes mark which properties are localized. That makes it a build-vs-buy input for any decision of the form "do we build per-locale columns, a JSON blob, or a translation table?" — the package is the buy option for the translation-table variant.
• Content model / schema decisions. Because it drives entity mapping, adopting it is effectively a one-way-ish data-model decision. It belongs in the same decision record as your i18n strategy, not as a late-stage implementation detail.
• Inheritance-heavy domain models. Release 4.5.4 makes class-level TranslatedProperty and Locale attributes resolve from parent classes, not just the concrete entity. This directly unblocks content models that use mapped superclasses or inheritance hierarchies (e.g. a shared AbstractContent base with translated title/slug, subclassed per content type). If your roadmap includes consolidating duplicated translated fields across entity types, this patch is the enabling change — previously you'd have had to redeclare attributes on every subclass.
• Platform/stack fit and portability risk. Worth stating plainly for planning: this is a Symfony/Doctrine bundle, not a Laravel/Eloquent package. If the product is Laravel-first, this is not the build-vs-buy candidate — the comparable decisions there are astrotomic/laravel-translatable or spatie/laravel-translatable. Treat this assessment as guidance for any Symfony service (admin back office, content API, legacy app) that sits alongside a Laravel product.
• Upgrade/maintenance budgeting. 4.5.4 is a patch release with no breaking changes and no deprecations, so it does not create roadmap work — it can be absorbed in a routine dependency bump.

When to Consider This Package

Adopt when all of the following hold:

• The service is Symfony with Doctrine ORM (not Laravel/Eloquent, not raw PDO).
• You need to store many translated scalar fields across several entities, and the translation-table shape (one row per entity per locale) is acceptable to your query and reporting patterns.
• You want localization handled at the persistence/mapping layer so application code reads $entity->getTitle() in the current locale without hand-rolled joins.
• Your content model uses, or is about to use, class inheritance — 4.5.4's parent-class attribute resolution is specifically valuable here.
• You're comfortable owning a smaller-community bundle: evaluate bus factor, test coverage, and the maintainers' release cadence against your support expectations.

Look elsewhere when:

• The stack is Laravel/Eloquent — this bundle is not usable there; use a translatable package built for Eloquent.
• You need fallback-locale resolution, translation workflow/UI, or machine translation — this is a persistence mechanism, not a translation management system; pair it with a TMS or build the workflow separately.
• Your read patterns are analytics/reporting-heavy across locales — the translation-table join shape can get expensive; a denormalized or search-index-backed approach may serve better.
• You need per-locale versioning, drafts, or editorial state — that's application-level modelling this package deliberately doesn't own.
• You're on an unsupported Symfony/Doctrine version, or on PHP versions outside the bundle's support matrix.

How to Pitch It (Stakeholders)

To executives: This is a maintenance-level update to a library we'd use only if the relevant service is Symfony-based. It fixes localization metadata so it's inherited from parent classes, which lets us model shared translated fields (titles, slugs) once instead of duplicating them across every content type — less code, fewer places for locale bugs. There are no breaking changes and no deprecations, so the risk and cost of taking it are near zero; it's a routine patch bump, not a project.

To engineering: 4.5.4 (PR #93) extends attribute parsing so class-level TranslatedProperty and Locale are read from parent classes as well as the concrete entity. Backward compatible — no migration, no config change, no API change. Action: bump the constraint if you're pinned to 4.5.x, and if you maintain inheritance-based content entities, add a regression test asserting translated fields resolve correctly on a subclass. If the product in question is Laravel/Eloquent, this package is out of scope — flag it and route the i18n decision to an Eloquent-appropriate translatable library instead.

Bottom line for the roadmap: not a strategic dependency, not a risk item, and not a reason to change plans. Log the patch, note the inheritance capability as a mild accelerator for any content-model consolidation work, and revisit the build-vs-buy call only if the localization surface area grows beyond per-field translation.