Entity Translator Laravel Package

Product Decisions This Supports

• Informs the i18n/localization roadmap for catalog data. The component’s model — a translator service that maps a source entity into locale-specific variants — is a useful reference pattern when scoping multi-language product, category, and attribute content. Use it to frame the build-vs-buy conversation, not as an implementation dependency.
• Data-model decisions (translation side tables vs. JSON columns vs. per-locale rows). Reviewing the Elcodi approach gives the team a concrete prior-art example for the schema debate: separate translation entities per locale versus serialized fields. This directly affects query complexity, admin UX, and search/indexing strategy downstream.
• Build vs. buy vs. borrow. Verdict: borrow the idea, buy/build the implementation. The package scores 2.34 with zero dependents, an archived repo, and a last release in Feb 2016 — it is not a viable dependency. The decision it supports is "adopt an actively maintained translation layer" (e.g., Spatie/Astrotomic translatable in Laravel, or Sylius/Doctrine Translatable if the stack is Symfony).
• Stack-risk review. The package is Symfony-based (Elcodi e-commerce components), not Laravel-native despite being catalogued as a Laravel/PHP package. This is a flag for any PM inheriting a legacy PHP codebase: verify framework alignment before adding it to a dependency audit or migration plan.
• Legacy archaeology / migration scoping. If the codebase already uses Elcodi components, this assessment supports a "replace or isolate" decision: identify translation touchpoints, estimate migration effort to a maintained library, and prioritize by customer-facing locale coverage.

When to Consider This Package

Consider it only under narrow, defensive conditions:

• You are maintaining an existing Symfony application that already depends on Elcodi and you need to understand or patch behavior — and even then, vendor/fork it rather than pull from Packagist.
• You need a reference implementation to study before designing your own translation layer.
• You are doing due diligence on a legacy vendor and need to document why a component is frozen.

Look elsewhere — decisively — when:

• Any new build. The repo is archived, read-only, EOL, and accepts no PRs. That means no security patches, no PHP 8+ compatibility guarantees, and no framework upgrades.
• You need an actively supported library. Zero dependents and a 2016 last release are strong signals of abandonment; onboarding cost will exceed any savings.
• You are on Laravel. This is Symfony-oriented; use spatie/laravel-translatable or astrotomic/laravel-translatable instead.
• You need community support SLAs. Documentation, Gitter, and Twitter links from 2016 are effectively dead channels.
• You require licensing/compliance assurance beyond MIT. MIT is fine, but the absence of maintainers means no CVE response.

How to Pitch It (Stakeholders)

Bottom line: do not adopt. Use it as a design reference only.

For executives: This is an end-of-life, archived component from a defunct e-commerce suite (Elcodi), last released in 2016 with no dependents and no maintainers. Adopting it would introduce unpatched security and compatibility risk for zero benefit. The concept — structured entity translation for multi-language catalogs — is sound and worth funding, but we should implement it with a maintained library or a small in-house layer.

For engineering: Treat elcodi/entity-translator as prior art. It demonstrates a translator-service pattern for producing locale-specific entity variants, which maps cleanly onto translation-table or per-locale-row designs. We will not add it to composer.json. Recommended path: evaluate spatie/laravel-translatable (if Laravel) or Doctrine Translatable (if Symfony), and budget a spike to confirm it covers admin editing, fallback locales, and search indexing.

For product/roadmap: The decision this unlocks is how we model localized content, which gates every downstream localization feature — storefront language switching, per-market pricing copy, SEO hreflang, and translation workflows. Make that schema call early; retrofitting localization is materially more expensive than designing it in.

Risk note: Any team member proposing this package should be redirected to the maintained alternatives above; the archived status is a hard blocker, not a preference.