Doctrine Translatable Laravel Package

Technical Evaluation

Framing correction. Despite the request framing this as a "Laravel/PHP package," prezent/doctrine-translatable is a Doctrine ORM behavior extension, not a Laravel/Eloquent package. It has no service provider, no config publish tag, and no Eloquent trait. Any TPM assessment must start from that stack mismatch, because it determines whether this is a drop-in, a wrapper project, or a non-starter.

Architecture fit. Poor-to-moderate for a standard Laravel application. Laravel's default data layer is Eloquent (Active Record); Doctrine is a Data Mapper with a unit of work, DQL, and its own hydration model. Bolting Doctrine into Laravel is supported (e.g., laravel-doctrine/orm) but creates a split ORM estate, dual migration tooling, and two mental models for the team. If the target application is already Doctrine-based — a Symfony service, a Laravel app with an existing Doctrine layer, or a legacy PHP system — the fit improves to reasonable.

Integration feasibility. Medium. Expect: Composer install, entity-level mapping (annotation vs. attribute syntax matters for PHP 8), registration of the translation listener/event subscriber, a locale resolver wired to Laravel's App::getLocale(), and translation entity generation or hand-mapping. All of that is glue the TPM should budget as custom work, not package work.

Technical risk. High, on three independent axes:

• Adoption signal: 26 stars is near-zero community gravity. Bug discovery and fixes will be self-service.
• Provenance: the repository is listed as unknown — no verifiable commit history, issue tracker, release cadence, or maintainer identity. That is a supply-chain due-diligence blocker until resolved.
• Version drift: "Doctrine2" branding implies an era before Doctrine ORM 3.x, PHP 8 attributes, and DBAL 3/4. Compatibility with a modern Laravel (10/11/12) + PHP 8.2+ baseline is unverified and likely requires patching.

Key questions to answer before committing:

1. Is the application actually on Doctrine, or is this a mistaken package shortlist entry?
2. Which Doctrine ORM, DBAL, and PHP versions are in production, and does this package declare support for them?
3. Who maintains the fork, and is a paid or internal maintainer assigned?
4. What is the translation storage model — row-per-entity or row-per-field — and does it match our query patterns?
5. What is the fallback behavior when a locale is missing?
6. Is there a credible alternative (see below) that clears the due-diligence bar?

Verdict. Treat as do not adopt by default. The strongest reason to use it is "we are already on Doctrine and need a translatable behavior now." The strongest reason to reject it is "we are an Eloquent shop," which is the likely case. Mature alternatives — gedmo/doctrine-extensions (Translatable) or knplabs/doctrine-behaviors for Doctrine; spatie/laravel-translatable for Eloquent — carry orders of magnitude more adoption and should be the default comparison set.

Integration Approach

Stack fit.

Migration path. Do not migrate toward this package. If the application is Eloquent-first, the correct path is a Laravel-native translatable package; introducing Doctrine solely to use this behavior inverts the cost/benefit. If the application is Doctrine-first, the migration path is within Doctrine: evaluate gedmo/doctrine-extensions first, and use prezent/doctrine-translatable only if it demonstrably solves a gap Gedmo does not.

Compatibility gate. Pin and verify before any code: PHP version, Doctrine ORM 2.14+/3.x, DBAL 3/4, mapping driver (attributes vs. annotations), and the Laravel or Symfony major. If the package's composer.json does not declare these constraints, assume breakage and budget a fork.

Sequencing.

1. Week 0 — provenance check. Resolve "repository unknown"; confirm license file, last commit, open issues, and whether a maintained fork exists.
2. Week 1 — two-day spike. One entity, two locales, one list and one detail query. Measure query count and hydration cost. Kill the initiative here if the spike is ugly.
3. Week 2 — integration design. Locale resolution, fallback policy, admin editing surface, cache invalidation contract.
4. Sprint 2–3 — pilot entity behind a feature flag, with the ORM wrapper isolated behind an internal interface so the package can be swapped without touching domain code.
5. Sprint 4+ — pattern rollout, only after the pilot survives a load test and one framework upgrade rehearsal.

The internal-interface isolation step is the single most important sequencing decision: it converts an unmaintained dependency from an architectural lock-in into a replaceable detail.

Operational Impact

Maintenance. This is the dominant cost. A 26-star package with an unverifiable repository has no realistic expectation of upstream patches for PHP or Doctrine upgrades. Plan to vendor the source into the monorepo (with the MIT license preserved) and own it. Budget roughly 5–10% of one engineer's capacity per quarter for dependency upkeep, spiking around framework major upgrades.

Support. MIT, community-only, no SLA, no security advisory channel. Any production incident traces to our own on-call. This must be accepted explicitly by the engineering owner, not silently inherited.

Scaling. The translatable pattern typically multiplies rows per entity per locale. Watch for:

• Join fan-out on list endpoints when multiple translated fields and locales are joined into one query — cartesian growth and slow hydration.
• N+1 hydration if translations are lazy-loaded per entity in a collection.
• Fallback queries that issue a second round-trip per missing locale.

Mitigations: partial hydration / DQL NEW projections, per-locale caching keyed by entity + locale + version, and composite indexes on (locale, foreign_key).

Failure modes to design against.

• Silent fallback: missing translation serving the wrong locale or a blank string with no alert.
• Locale leakage: request-scoped locale stored statically and bleeding across queued jobs or long-running workers (Octane, Swoole).
• Schema drift: adding a locale requires no migration in row-per-entity models but does in row-per-field models — document which model is in use.
• Upgrade breakage: DBAL or ORM minor bumps silently breaking the listener registration.
• Cache staleness: translation edits not invalidating the read cache.

Ramp-up. Expect a real learning curve if the team is Eloquent-native: Doctrine's unit of work, DQL, entity lifecycle events, and mapping drivers are a distinct skill set. Realistic estimate: 2–3 sprints before a mid-level engineer is productive and one senior engineer as the named owner. Documentation for a package this size will be thin or absent — the ramp-up cost lands on reading the source, which is only feasible if the repository is actually reachable.

Bottom line for the roadmap. Green-light only for Doctrine-based systems, only after provenance is verified, only behind an internal abstraction, and only with a named maintainer. For a Laravel/Eloquent codebase, reject and route the i18n requirement to a mainstream Laravel translatable package.