Doctrine Translatable Bundle Laravel Package

Product Decisions This Supports

• Localization roadmap sequencing. The package's core premise — storing a separate translation row per locale per entity — forces an explicit answer to "which locales do we launch with, and which are additive?" Adding a locale becomes a data/backfill operation rather than a schema migration. That makes market-by-market rollout decisions cheap to defer.
• Build vs. buy for the i18n layer. It is a credible "buy" (well, adopt) option for the storage/entity half of localization, which isolates the genuinely bespoke half — editorial workflow, review/approval, translation memory, MT — where a TMS (Phrase, Lokalise, Crowdin) is the real decision.
• Data model choice: translation tables vs. JSON columns vs. external CMS. Adopting this commits you to a normalized per-locale table model. That trade-off (clean querying and per-locale indexing vs. join cost and schema churn when fields change) is a product decision as much as an engineering one — it affects admin CMS performance and how fast you can add translatable fields.
• Scope of "translatable." Useful for forcing the distinction between content (products, pages, categories — this package's job) and UI strings (Symfony's Translator). Conflating them is a common and expensive roadmap mistake; picking this package is effectively a decision to keep them separate.
• Fallback and partial-translation policy. Per-locale rows make "what do we show when a locale is 60% translated?" an explicit product rule (fallback to default locale, hide the entity, show partial with a banner) rather than an accident of null handling.
• Admin/editorial UX investment. The package handles persistence, not authoring. Deciding to adopt it is implicitly a decision to build or buy a per-locale editing surface — a meaningful roadmap line item most localization estimates under-scope.

When to Consider This Package

Consider it when:

• The stack is Symfony with Doctrine ORM. Note the framing risk: this is a Symfony bundle, not a Laravel package — it does not apply to Eloquent-based applications at all. If the request is Laravel-shaped, the correct answer is a comparable Eloquent solution (dimsav/laravel-translatable / spatie/laravel-translatable), and this should be excluded on stack mismatch alone.
• You need entity-level multilingual content persisted in the database, queried and sorted per locale, with translation tables you control.
• You want a small, MIT-licensed, conventional implementation over a heavyweight CMS or a full TMS integration.
• You are comfortable treating it as a reference implementation you vendor and own rather than a long-term upstream dependency.

Look elsewhere when:

• Adoption signals are absent. 0 stars, 0 dependents, score 0, and a [READ-ONLY] split from a monorepo. There is no community, no issue traffic, no third-party validation. This is a maintenance liability, not a safe default.
• You need a support contract, security SLA, or evidence of active maintenance for procurement/compliance review.
• Translation workflow is the actual problem — review cycles, translator handoff, MT, translation memory. A TMS integration solves that; this does not.
• Your content model is field-light and document-shaped (a JSON blob per locale is simpler and avoids join sprawl).
• You need per-locale routing, hreflang, locale negotiation, or UI-string translation — Symfony's own routing/locale and Translator components cover those; this bundle does not.
• The team has no appetite for forking and owning a near-zero-traction dependency.

How to Pitch It (Stakeholders)

For executives: We need multilingual content to enter new markets. The expensive, differentiating parts of localization are editorial workflow, review, and translation supply — not database plumbing. This package is a small, MIT-licensed, conventional Symfony/Doctrine implementation of the plumbing: one row per locale, queried natively. Adopting it removes several weeks of bespoke schema work and keeps our options open, since it's permissive-licensed and trivially replaceable if we outgrow it. The honest caveat: it has effectively zero external adoption and is published as a read-only mirror of an internal monorepo. We should therefore vendor it into our codebase and own it — roughly one to two days of review by a senior engineer — rather than depend on it as a maintained third-party library. Low cost, low lock-in, no procurement or licensing exposure.

For engineering: Standard Doctrine entity-translation pattern — separate translation tables, locale-keyed, per-entity. It is Symfony-only; it is not usable from Laravel/Eloquent, so confirm the stack before anyone spends time on it. The repository is a read-only subtree split with no dependency graph and no community, so treat the upstream as a source of truth to copy, not a version to pin. Recommended path: fork/vendor, pin to a commit, add our own tests around the entity lifecycle and fallback behavior, and keep the translation surface behind a thin internal interface so we can swap the implementation without touching domain code. Budget for the authoring/admin UI separately — this bundle is persistence only.