Sulu Translations Bundle Laravel Package

Technical Evaluation

Architecture fit. First and most important finding: despite being queued as a "Laravel/PHP package," phpro/sulu-translations-bundle is a Symfony bundle that extends Sulu CMS's translation infrastructure. It is not a Laravel package and has no service provider, facade, or Eloquent integration. It cannot be dropped into a Laravel application; it can only be consumed by a Symfony application running Sulu. If our target stack is Laravel, this release is not adoptable at all, and the evaluation should be closed rather than carried forward. If we have a Sulu-based content platform (or are evaluating Sulu for a headless CMS use case), the assessment continues as below.

Integration feasibility. The 1.2.0 change set is narrow: a PHP platform requirement bump to 8.4 and a swap of azjezz/psl for php-standard-library (the same library, renamed upstream). There are no new features, no API additions, no configuration surface changes. Integration effort is therefore dominated by environment work, not by the package itself: upgrading our PHP runtime to 8.4 and reconciling Composer constraints across the wider dependency graph.

Technical risk.

• PHP 8.4 floor is effectively a breaking change. Raising the minimum PHP version in a minor release (1.1.0 → 1.2.0) means any consumer on PHP 8.1–8.3 is silently cut off on composer update. This is a SemVer-compatibility concern worth raising with the maintainer, and it means we must pin to 1.1.x until our runtime is upgraded.
• Transitive dependency collision. Any package elsewhere in our graph still requiring azjezz/psl will now conflict, since both provide the same namespace/classes. This is the highest-probability failure mode and needs a composer why azjezz/psl audit before adoption.
• Thin maintenance base. Version 1.2.0 is the first contribution from a new contributor, and the bundle appears to be a small, narrowly-scoped utility inside the larger Sulu ecosystem. Bus factor and release cadence are the real long-term risks, not the code change.
• Low functional risk. No behaviour changes are introduced, so regression exposure in translation handling is minimal.

Key questions.

1. Is Sulu actually in our stack, now or on the roadmap? If no, close this out.
2. Does the php-standard-library rename preserve the Psl\ namespace and public API, or does it require code changes on our side?
3. Can we pin 1.1.0 and defer, or does a security or bug fix force us forward?
4. Who owns the PHP 8.4 runtime upgrade, and what is the blast radius across other PHP services?
5. Does the maintainer intend to keep the PHP floor at 8.4, or was this an opportunistic bump that may be relaxed?

Integration Approach

Stack fit. Only viable in a Symfony/Sulu application. For a Laravel estate, this is a non-starter — the correct recommendation is to solve translation management with Laravel-native tooling (e.g. spatie/laravel-translation-loader, astrotomic/laravel-translatable) rather than attempting to bridge a Symfony bundle. Record this explicitly so the package isn't re-queued later.

Migration path. For a Sulu consumer on 1.1.0: (1) audit the lockfile for azjezz/psl; (2) upgrade the runtime to PHP 8.4 in a staging environment; (3) run a full composer update in a branch and inspect the diff for the dependency swap; (4) run the translation-related test suite and a manual pass over admin/translation editing flows; (5) roll forward.

Compatibility. Treat the PHP 8.4 requirement as a hard gate, not a soft one. Confirm any Sulu core version constraints are still satisfied alongside 1.2.0 — a bundle bump that pulls Sulu forward could cascade into a much larger CMS upgrade. Verify the php-standard-library package is available in our Composer repository/proxy before committing to the upgrade window.

Sequencing. Runtime upgrade first, dependency audit second, package bump third, regression pass last. Do not attempt the package bump and runtime upgrade in the same change; if something breaks, we want to know which of the two caused it. If we are not a Sulu shop, the sequence collapses to a single step: decline and document.

Operational Impact

Maintenance. Near-zero ongoing cost if adopted — the bundle is small and this release adds no configuration or behavioural surface. The maintenance burden sits with the PHP runtime and the dependency graph, not the bundle.

Support. No vendor support; community-only via GitHub issues. Given a new contributor and a small project, treat issue response times as best-effort and budget for the possibility of forking or patching in-house if a blocking bug appears.

Scaling. Translation bundles are read-mostly at runtime and typically resolved at build/cache-warm time. No scaling concerns attributable to this release.

Failure modes. The realistic ones are: (a) Composer resolution failure due to the azjezz/psl ↔ php-standard-library conflict — loud, caught at install time; (b) runtime fatal errors if any code path still references the old package namespace — caught by tests; (c) silent lock-out of environments below PHP 8.4, which manifests as a stale lockfile rather than an error, and is the one most likely to go unnoticed; (d) abandonment of the package upstream, leaving us pinned.

Ramp-up. Trivial for anyone already working in Sulu. For a Laravel-only team, ramp-up cost is effectively infinite — this package requires Symfony and Sulu domain knowledge and is not a transferable skill investment unless we are committing to that ecosystem more broadly.

Recommendation. Do not adopt on a Laravel stack. On a Sulu stack, upgrade is low-risk and worth taking, but sequence it behind the PHP 8.4 runtime upgrade and gate it on a clean dependency-conflict audit. Hold 1.1.x as the fallback pin.