Entity Translator Laravel Package

Technical Evaluation

Architecture fit. Poor as a drop-in, workable as a reference design. elcodi/entity-translator is a Symfony 2-era component extracted from the Elcodi monorepo (the 420 stars belong to the parent repo, not this split package — treat the social proof as near-zero). Its design assumes Symfony's DI container, service tags, event dispatcher, and — depending on the configured translation provider — Doctrine entities and repositories. A Laravel codebase runs on Eloquent, a different container, and a different event model. The portable core is small and conceptual: an entity-translator abstraction over a TranslationProviderInterface that resolves a field value for a given locale. That idea transplants cleanly; the shipping code does not.

Integration feasibility. Technically installable, practically hostile. The component's composer.json predates PHP 7 type declarations and pins Symfony 2.x/3.x ranges, so resolution against a modern Laravel app (Symfony 6/7 components, PHP 8.2+) will conflict on symfony/translation, symfony/options-resolver, psr/log, and Doctrine constraints. Forcing it in with --ignore-platform-reqs buys a runtime that emits deprecations at best and fatals at worst. Realistic paths are: fork and vendor into app/Support, or reimplement the contract in ~150–300 lines. Both are cheaper than dependency surgery.

Technical risk. High and one-directional. The package is EOL, archived, read-only by policy ("we'll not attend any Pull Request"), last released 2016-02-15, and has zero dependents — no production signal, no downstream patches, no CVE response. Whatever we adopt becomes permanently ours to maintain, including PHP-version treadmill work. The secondary risk is conceptual mismatch: if the team assumes "translation" means Laravel's __() string catalog, the entity-field-locale model will surprise them.

Key questions.

• What is the actual requirement — localized content fields on domain entities, or UI string translation? These are different problems and only the first is in scope here.
• Are we on Eloquent, or is there a Doctrine island in this codebase? Doctrine changes the calculus substantially.
• Is per-locale field storage mandated, or would a JSON column with fallback resolution suffice?
• What does a spatie/laravel-translatable or astrotomic/laravel-translatable spike cost versus porting this? Run that comparison before committing.
• Who owns this code after adoption, by name?

Recommendation: do not add as a runtime dependency. Mine the interface design, implement a Laravel-native equivalent behind our own contract.

Integration Approach

Stack fit. The usable artifact is the pattern: a translator service that takes an entity plus a field name plus a locale, delegates to a provider, and applies fallback. Everything framework-coupled — bundle registration, tagged provider collection, Doctrine-backed provider — is dead weight in Laravel and should be discarded rather than ported.

Options, cheapest first.

1. Adopt an existing package. spatie/laravel-translatable (JSON-backed) or astrotomic/laravel-translatable (side-table) cover the common cases with active maintenance. Default choice unless a requirement rules them out.
2. Port the concept. Define TranslationProviderInterface, a EntityTranslator service, and an Eloquent-backed provider. Small surface, full control, no abandoned code.
3. Fork and vendor. Only justified if the provider abstraction is genuinely load-bearing and we want the upstream shape preserved. Accept that we now own a fork with no upstream.

Compatibility. If any path involves the original code, audit composer.json first: PHP constraint, Symfony major ranges, Doctrine ORM version, and PSR interface versions. Any one of these can block resolution independently. Assume incompatibility until a composer why-not proves otherwise.

Sequencing.

1. Spike (2–3 days): one entity, one translated field, one alternate locale, both an off-the-shelf package and a hand-rolled port.
2. Decide build-vs-buy against measured effort; document the decision.
3. Define the internal contract (EntityTranslator interface) before any implementation lands, so call sites never bind to a vendor.
4. Implement behind the contract; wire one consumer end-to-end.
5. Migrate remaining call sites incrementally; keep the old path until parity tests pass.
6. Retire the spike artifacts.

The contract-first step is the one that matters. It converts an irreversible vendor choice into a reversible one, which is the whole point when the candidate is archived.

Operational Impact

Maintenance. Total ownership transfer. No upstream fixes, no security advisories, no PHP 8.x compatibility work coming. Every future PHP or framework upgrade becomes a manual patch task against code we didn't write and don't fully understand. Budget it as internal code from day one, not as a dependency.

Support. Effectively none. Gitter channel and Twitter handle referenced in the README belong to a defunct project; Stack Overflow coverage will be thin for a component with zero dependents. Internal escalation is the only path — meaning the adopting engineer becomes the sole subject-matter expert. That's a bus-factor of one on a subsystem we'd otherwise consider trivial.

Scaling. The translator itself is in-process and cheap. The risk is the provider: a naive implementation that queries per field per entity will produce N+1 patterns on list views and API responses — the classic failure mode for entity translation. Any implementation needs eager-loading or a request-scoped cache for resolved translations, and a documented cache-invalidation story when content changes. Throughput is not the concern; query amplification is.

Failure modes.

• Missing translation returns the raw key or a null, surfacing as blank content in production rather than an error.
• Fallback chains silently resolve to the wrong locale when a default is misconfigured.
• Dependency drift breaks the app on an unrelated composer update, with a stack trace pointing nowhere useful.
• PHP deprecations become hard failures on the next runtime upgrade.
• Locale-aware caching staleness after content edits.

Ramp-up. The code volume is small — days for a mid-level PHP developer to read and understand. The real ramp-up cost is conceptual overhead: the team must learn a Symfony-flavored abstraction that doesn't match Laravel idioms, and future hires will need the same explanation. That tax is permanent and disproportionate to the capability delivered. A Laravel-native package or a small in-house trait carries near-zero of it.

Net: low capability value, high tail risk, zero upstream. Score of 2.34 is consistent with what's on the page.