Doctrine Translatable Laravel Package

Product Decisions This Supports

• Localization / i18n roadmap: Enables per-locale storage of translatable content (product names/descriptions, categories, CMS pages, marketing copy) without building a bespoke translation persistence layer. Directly supports a "ship multi-language content" roadmap item at lower engineering cost.
• Build vs. buy (adopt): For teams already invested in Doctrine, this is an adopt-not-build decision for the translation persistence layer — it standardizes how translated fields are stored across entities and avoids one-off language column designs per table.
• Feature scoping: Lets you commit to concrete i18n capabilities — edit content per locale, define a base/fallback language, expose translated attributes in admin — with a known implementation pattern rather than open-ended custom schema work.
• Use cases: Multi-market e-commerce catalogs, localized legal/policy pages, region-specific B2B portal content, admin-managed marketing pages with language variants.
• Forces an explicit fallback decision: Because translations live in a companion entity, product must decide fallback UX (e.g., display base language when a translation is missing) — a decision that otherwise surfaces late and disrupts launch.

When to Consider This Package

Consider adopting when:

• Your Laravel application uses Doctrine ORM (e.g., via Laravel Doctrine), not Eloquent — this package is Doctrine-specific and irrelevant to Eloquent models.
• You have multiple translatable entities and want a single consistent translation pattern rather than ad-hoc name_en / name_fr columns.
• You accept a small, low-traffic dependency (26 stars, repository status unclear) and are prepared to pin the version and vendor/fork if upstream goes quiet. The MIT license permits this.
• Your scope is content storage and admin editing — not machine translation, locale routing, URL strategy, or SEO.

Look elsewhere when:

• You are on Eloquent (the majority of Laravel apps) — use an Eloquent-native translatable package instead.
• You require active maintenance, security patching, or broad community support — the low star count and "unknown" repository provenance are risk signals; validate recent commit activity and ownership before committing.
• You need locale routing, middleware, URL localization, or hreflang/SEO — out of scope; pair with a dedicated i18n routing solution.
• You need complex fallback hierarchies, per-locale permissions, or translation workflow (draft/review/publish per language) — likely a custom build.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed building block that shortens the path to shipping multi-language content by removing custom schema work for storing translations. It reduces engineering effort and schedule risk on the localization roadmap at effectively zero license cost. The trade-off is maturity: it is a lightly-adopted library with unclear upstream upkeep. We should gate adoption on a brief technical due-diligence pass and keep a fork/vendor contingency — the permissive license means no vendor lock-in.

For engineering: It provides a Doctrine translatable behavior where translated fields live in a companion entity keyed to the base record, giving a reusable pattern instead of per-entity language columns. Fits only if we are committed to Doctrine. Before adopting: verify maintenance status and provenance, pin the dependency, and be ready to fork under our org. Note it does not cover locale routing, fallback resolution, or SEO — those remain separate design decisions we must own.