Entity Translations Bundle Laravel Package

Product Decisions This Supports

• Localization roadmap scoping. Whether the platform's user-facing content (product catalogs, CMS pages, category trees, any domain object) needs per-locale text storage, and how many entities are in scope for translation.
• Build vs buy for the translation layer. This package is a candidate "buy" (MIT, drop-in persistence) against "build" (own translation table + traits/behaviors). The decision hinges on maintenance risk, not features.
• Fallback and locale-handling policy. Any adoption forces a decision on default-locale fallback, missing-translation behavior, and whether translations live in the same table as the entity or a side table.
• Tech-debt and dependency-policy decisions. With 9 stars, 0 dependents, and a last release of Jan 2021, adopting it is effectively a commitment to vendor and maintain the fork yourself — that is a resourcing decision, not just a library choice.
• Prototype vs production gating. Reasonable as a reference implementation to validate a translation schema quickly; not a defensible production dependency without an owner.

When to Consider This Package

Consider it only if:

• You are on a Symfony-style bundle ecosystem, not Laravel. The name and structure (*Bundle, "POPOs") point to Symfony; framing it as a Laravel package is a mismatch worth resolving before evaluation.
• You need a small, self-contained polymorphic translation store for a handful of entities and want to avoid hand-rolling one.
• You are comfortable vendoring/forking — auditing the code, taking ownership, and patching it yourself. MIT license makes that legally clean.
• It is being used as a spike or reference design, with a scheduled replacement path.
• Your app's PHP and framework versions are pinned to what it supported in early 2021 and cannot move.

Look elsewhere if:

• You are building on Laravel — evaluate spatie/laravel-translatable or astrotomic/laravel-translatable instead; they are framework-native, actively maintained, and widely adopted.
• You are on Symfony/Doctrine — KnpLabs/DoctrineBehaviors or the Doctrine Translatable extension offer the same capability with maintenance and community behind them.
• You have security, compliance, or long-term-support requirements. A four-year-old package with no dependents means no upstream CVE response and no ecosystem pressure to keep it compatible.
• You need PHP 8.x/current-framework compatibility without doing the upgrade work yourself.
• Translation is core to the product (e-commerce, multi-market SaaS). Core infrastructure should not sit on a 9-star, single-maintainer dependency.
• You need query performance guarantees on locale-filtered joins at scale — evaluate the schema and indexing yourself rather than inheriting it.

How to Pitch It (Stakeholders)

To executives: There is an open-source option that solves entity translation quickly and is free to license. However, it has negligible adoption (9 stars, zero dependent projects), its last release was January 2021, and it appears built for Symfony rather than our Laravel stack. I do not recommend it as a production dependency. The realistic paths are (a) build a small in-house translation layer — roughly a one-to-two sprint effort for a typical entity set — or (b) adopt a maintained, framework-native library. I recommend (b) for speed, with (a) as the fallback if we need unusual fallback rules.

To engineering: The capability we want — per-locale text fields on domain objects, stored in a side table, resolved by locale — is well-trodden. This package is a compact reference for that schema, and its MIT license means we can lift the design freely. It is not a dependency to inherit: stale, unmaintained, framework mismatch, and no downstream users to surface breakage. Let's spend an hour reading it, then implement against a maintained library or our own thin layer with tests. Please confirm our actual framework target before we scope.