Object Translation Bundle Laravel Package

Technical Evaluation

Framework mismatch — first-order finding. Despite being scored in a Laravel/PHP package set, this is a Symfony bundle, not a Laravel package. It ships as a bundle (*Bundle class, DI Extension, YAML/XML service config, compiler passes) and almost certainly integrates via Doctrine ORM event subscribers rather than Eloquent. Nothing in it is expected to be installable via composer require into a Laravel app and "just work." Any evaluation of it as a Laravel dependency should start from the assumption that the integration cost is a port, not an install.

Architecture fit. The likely design is a Doctrine postLoad/onFlush listener or a translator decorator that swaps object properties based on the current locale, backed by a translation storage table keyed by (object class, object id, field, locale). That concept is sound and well-trodden — it is essentially what Doctrine Translatable and spatie/laravel-translatable do. The value here is therefore conceptual, not code-level: read it for the data model, then implement against a maintained library.

Integration feasibility. Feasibility into a Laravel codebase is low as-is, moderate as a reference implementation. Concretely:

• Symfony DI extension + service definitions → must be rewritten as a Laravel service provider / singleton binding.
• Doctrine listeners → must be rewritten as Eloquent accessors/mutators, a HasTranslations trait, or a query scope.
• Bundle config tree (Configuration.php) → must be rewritten as config/object-translation.php.
• The actual resolution logic (pick locale, fall back to default, hydrate) is typically 100–300 lines and is the only part worth lifting.

Technical risk — high.

• Abandoned: last release 2018-06-20, ~7 years stale. PHP 7.x-era code; likely breaks on PHP 8.2+ (dynamic properties, ContainerAware, deprecations) and on Symfony 5/6/7.
• Zero ecosystem validation: 0 dependents, 2 stars. No downstream users means no battle-testing, no issue history describing real failure modes, and no compatibility fixes.
• Bus factor 1, single author, no evidence of ongoing maintenance.
• Unknown test coverage — 2-star personal repos frequently ship without CI.
• Mitigating: MIT license means forking and vendoring is legally clean; small surface area means the code is auditable in an afternoon.
• Opportunity score 0.38 is consistent with the above: the problem space is real, but this artifact is not the vehicle.

Key questions to resolve before committing engineering time.

1. Does it persist translations in a side table (queryable, indexable) or a serialized/JSON column (cheap, but poor for search and per-locale partial updates)? This determines whether the data model is worth copying.
2. Is resolution read-time (listener/accessor) or explicit (service call)? Read-time is ergonomic but is the classic source of N+1 hydration queries.
3. Does it depend on Doctrine specifically, or is the core framework-agnostic?
4. What does composer.json declare — PHP constraint, Symfony constraint, test/CI setup?
5. How does it differ from doctrine/doctrine-extensions Translatable or KnpLabs bundles? If the delta is small, this package has no reason to exist.
6. Is our actual need Laravel, or do we have a legacy Symfony app being migrated? The answer changes everything below.

Integration Approach

Stack fit: poor. For Laravel, the maintained alternatives — spatie/laravel-translatable (JSON-column translations, ~2k stars, active) or astrotomic/laravel-translatable (side-table model) — dominate this package on every axis: docs, tests, PHP 8/Laravel 11 support, community. Recommending a direct port is only defensible if the existing data model already matches this package's schema.

Recommended path: reference-implement, don't fork. Use the repository as a design document for one spike, then build on a maintained library.

Migration / port path (if we do lift code):

1. Spike (1–2 days): clone, read the listener and storage layer, run phpstan/rector in dry-run to quantify PHP 8 upgrade cost, write one failing test against a real schema.
2. Extract: isolate the translation-resolution function into a framework-agnostic class with no Doctrine or Symfony imports. If it cannot be isolated cleanly in under a day, stop — that answers the build-vs-fork question.
3. Reimplement in Laravel: HasTranslations trait → accessor/mutator (getAttribute override or Attribute casts) → migration for the storage table (unique index on (translatable_type, translatable_id, field, locale)) → service provider binding a Translator resolver.
4. If the underlying data already exists in a Symfony system: write the schema-to-schema migration first, before any application code, and validate row counts and locale coverage.

Compatibility. Assume Symfony 3/4-era and PHP 7.1–7.3. Do not attempt to install it alongside a modern Symfony; do not expect it to install at all on PHP 8.3. Pin whatever environment you spike in.

Sequencing.

1. Confirm the framework question (Laravel vs. Symfony target) — this gates everything.
2. Evaluate maintained alternatives against the same requirements; default to them.
3. Only if requirements are genuinely unmet, spike + extract.
4. Vendor as an internal package (acme/object-translation) with an explicit owner, not as a public dependency.

Operational Impact

Maintenance: we own it outright. Upstream is dormant; no security patches, no PHP-version bumps, no Symfony/Laravel compatibility work. Forking means accepting a permanent line item — realistically a few days per year of dependency-drift maintenance, plus more if PHP major versions land. Budget it in the platform team's roadmap or don't take the dependency.

Support. No documentation beyond a README, no community, no Stack Overflow corpus, no issue history to mine for failure modes. Onboarding a new engineer means "read the source." The codebase is small enough that this is hours rather than weeks — that is the package's single genuine operational strength.

Scaling. Unknown and unproven. Watch specifically for:

• N+1 hydration: post-load listeners that fetch translations per object are the canonical failure mode. At a few thousand rows this is invisible; at page sizes in the hundreds with joins it becomes the dominant query cost. Verify whether batched/eager loading exists before trusting it in a hot path.
• Write amplification: every localized field save becomes a second write plus cache invalidation.
• Search: if translations live in a JSON/serialized column, per-locale full-text or WHERE filtering degrades badly — a strong argument for the side-table model or a maintained alternative.

Failure modes to instrument.

• Silent fallback to the default locale (users see English and no one notices until a support ticket).
• Missing translation returning null vs. the key vs. empty string — inconsistent contracts here are a recurring source of template bugs.
• Locale leakage in long-running processes: setting a global locale per request breaks under queue workers and Octane-style workers if not reset. This is the most dangerous failure mode for a translation layer and is rarely handled in 2018-era code.
• Stale translation caches after writes (no observable invalidation hook).

Ramp-up. Low for reading, moderate for owning. Any engineer can understand the concept in an afternoon; owning the port safely requires someone who has debugged ORM hydration and locale scoping before. Net: do not adopt as a dependency; treat as a design reference and a source of ~200 lines of logic under MIT. If the question is "should this be in our Laravel stack," the answer is no — the correct move is spatie/laravel-translatable, with this repo read once for schema ideas and then archived.