Sulu Translations Bundle Laravel Package

Product Decisions This Supports

• PHP 8.4 platform upgrade sequencing. Release 1.2.0 raises the minimum to PHP 8.4 and swaps azjezz/psl for php-standard-library. This converts the package from a "drop-in" to a runtime-version-gated dependency: it cannot ship until the platform/runtime upgrade lands. Use this as a concrete forcing function (or blocker) item on the infrastructure roadmap, and sequence it against other packages that still cap at 8.1–8.3.
• Build vs. buy for translation/localization management. The bundle is thin glue around Sulu's translation layer. If the product needs multi-locale content authoring, translation inheritance, or fallback chains, adopting an existing bundle is almost always cheaper than building — but only if the hosting CMS is already Sulu. Do not treat this as reusable Laravel i18n machinery.
• Dependency-surface risk budgeting. Replacing a widely-used utility library (azjezz/psl) with php-standard-library is a same-author/fork-lineage change. For a PM this is a supply-chain and behavior-parity question, not a feature: it warrants a regression pass over any code paths that touch string/collection helpers, plus a check that no other dependency pins the removed package.
• Feature vs. maintenance investment. 1.2.0 contains no new user-facing capability — it is pure modernization. It supports a "keep the lights on" decision (cheap, safe upgrade) but does not justify new budget, new integrations, or a marketing/launch beat.
• Use cases this actually serves: Sulu-based sites needing locale-aware content, translation fallback behavior, or admin-side translation workflows. It is not a general-purpose translation service, and it is not a Laravel package despite the broader PHP framing.

When to Consider This Package

Adopt when:

• The application is already on Sulu (Symfony-based CMS); this bundle is a natural fit and avoids bespoke translation plumbing.
• The runtime is already on PHP 8.4, or the 8.4 upgrade is funded and scheduled. Treat 8.4 as a hard prerequisite, not an aspiration — 1.2.0 will not install below it.
• The team wants translation behavior managed by the CMS rather than reimplemented in application code.
• Tolerance for a small-maintainer, single-vendor dependency is acceptable, and the codebase is small enough to audit or fork if needed.

Look elsewhere when:

• The stack is Laravel, not Sulu. There is no meaningful reuse here; use Laravel's native localization or a dedicated translation package.
• You are pinned to PHP 8.1–8.3 with no upgrade path this cycle — stay on 1.1.0 and track it as a known technical-debt item with an owner.
• You need an actively roadmapped library with frequent feature releases; 1.2.0 is maintenance-only and the project shows low release cadence.
• You require strong support/SLA guarantees or vendor indemnification — this is community-maintained.
• Your localization needs are runtime/API-driven (machine translation, TMS integration, CDN-delivered strings). This bundle governs CMS content translations, not application-string delivery.

Adoption checklist before merging the bump: confirm CI matrix and production images move to 8.4 together; grep for direct Psl\ usages in first-party code; verify composer lock no longer resolves azjezz/psl; run the translation/fallback test suite as a parity check.

How to Pitch It (Stakeholders)

For executives (one paragraph): A small, low-risk maintenance release of a Sulu CMS translation component. It adds no new features and no new cost, but it hard-requires PHP 8.4, so its real significance is as a checkpoint on our PHP upgrade timeline. The main consideration is dependency hygiene, not capability — we are replacing one utility library with its successor, which we should validate with a routine regression pass. Recommendation: adopt once the 8.4 runtime is live; no budget ask, no customer-facing change.

For engineering (the substance):

• Breaking: minimum PHP is now 8.4. Any environment below that will fail to resolve. This is a hard gate, not a soft preference.
• Dependency swap: azjezz/psl → php-standard-library. Functionally adjacent (same lineage), but verify no behavioral drift in string/collection helpers and that nothing else in the tree still pins the old package.
• Scope: zero new features, zero deprecations beyond the platform floor. The diff is modernization plus one new contributor — a mild positive signal on project health, offset by continued low bus factor.
• Action: update the composer constraint, run the full test suite including locale-fallback paths, and add a CI job pinned to 8.4 so this doesn't silently regress.

Risk framing: low technical risk, moderate scheduling risk (blocked on platform upgrade), low strategic importance. Do not escalate; do put an owner and date on the 8.4 prerequisite.