Ux Translator Laravel Package

Technical Evaluation

What this release actually is: v3.6.0 of symfony/ux-translator — a Symfony UX bundle for extracting translations from Twig templates and wiring them into Symfony's Translator + AssetMapper. The changelog is entirely bug fixes and tooling chores; there are no new features, no deprecations, and no documented breaking changes.

Architecture fit: Poor for a Laravel-first estate. ux-translator assumes Symfony's FrameworkBundle, the Symfony DI container, Twig, symfony/translation, and optionally symfony/asset-mapper. Laravel ships Blade, its own __()/trans() helpers, lang/ file loading, and Vite — none of which the bundle understands. There is no Laravel service provider, no Blade extractor, and no Vite/asset integration. Leveraging it in Laravel would mean standing up a Symfony kernel inside the app solely for translation extraction, which is disproportionate to the value.

Integration feasibility: Low, bordering on not viable. Even the optional path (Twig-based templates inside Laravel, e.g. via rcrowe/twigbridge) requires the bundle's compiler passes and container extensions, which the bridge does not provide. The realistic adoption unit is a Symfony service or a Symfony/Silex legacy component, not a Laravel app.

Technical risk (if adopted in a Symfony context): Low-to-moderate. All five bug fixes are corrective, but two carry behavioral weight worth tracking:

• #4059 "Fully escape translation IDs" — output for IDs containing quotes/backslashes/HTML-sensitive characters will change. Any downstream snapshot tests or JS-side consumers of the generated catalogue should be re-baselined.
• #3919 "Conflict with symfony/asset-mapper 8.2 and later" — an explicit upper-bound conflict. This is the highest-signal line in the changelog: it means the bundle and AssetMapper 8.2+ are mutually incompatible today, so an AssetMapper upgrade elsewhere in the estate can block ux-translator upgrades (or vice versa). Treat as a version-lock coupling.
• #4073 / #4067 — dump-directory and empty-translation-output fixes. These are silent-failure classes: translations were being written empty or to the wrong path. Anyone currently on ≤3.5.0 with AssetMapper should assume their translation artefacts may have been quietly wrong and re-verify.

Key questions:

1. Do we actually operate any Symfony applications or bundles, or is this arriving via a transitive/scan signal? If Laravel-only, this is a no-op.
2. What is the estate's symfony/asset-mapper version? If anything is on 8.2+, this package is blocked regardless.
3. Are we consuming Twig-based translation extraction anywhere, or is this being evaluated as a "translation tooling" category fit against Laravel-native options (laravel-lang/*, barryvdh/laravel-translation-manager, knuckleswtf/scribe-style extractors)?
4. Who owns a Symfony runtime, if anyone, and is it in scope for this review?
5. Is translation artefact correctness a compliance/regulatory concern (i.e. do silent empty dumps have audit implications)?

Integration Approach

Stack fit: Mismatch. Recommended disposition is NO-GO for Laravel, CONDITIONAL for any Symfony surface. For Laravel, the functionally equivalent evaluation set is Laravel's native lang/ pipeline plus a community extraction tool; ux-translator does not compete on that axis and should not be shortlisted.

Migration path: None exists from Laravel. There is no adapter, no bridge contract, and no roadmap signal in this changelog toward non-Symfony frameworks. If a Symfony service is in scope, migration is a straightforward Composer bump from 3.5.x to 3.6.0 — non-breaking by inspection, but gate on the AssetMapper conflict resolution first.

Compatibility:

• Requires a Symfony runtime and Twig; not compatible with a pure Laravel container.
• Hard conflict with symfony/asset-mapper ≥8.2 (#3919). Pin and verify with composer why-not before any bump.
• The escaping fix (#4059) is output-affecting; run catalogue diffs in a lower environment before promoting.

Sequencing (if a Symfony surface is in scope):

1. Inventory symfony/asset-mapper versions across affected services; resolve the 8.2+ conflict or defer the bump.
2. Bump to 3.6.0 in a single non-production Symfony service; run ux:translator:warm-cache and diff generated catalogues against 3.5.x output.
3. Inspect specifically for IDs with quotes/backslashes/HTML entities to confirm the #4059 escaping change is intentional and consumed correctly downstream.
4. Confirm the dump directory is registered and that dumps are non-empty (#4073, #4067) — this is the regression to actively prove, not assume.
5. Only then roll forward to remaining Symfony services.

For the Laravel estate: no action; close the ticket with a note that this is a Symfony UX component and route translation-tooling demand to a Laravel-native evaluation.

Operational Impact

Maintenance: Low burden where legitimately adopted — this is a Symfony-maintained, actively released bundle with a steady bug-fix cadence (five fixes in one minor). The cost is not patching; it is the version-coupling to AssetMapper, which introduces a second upgrade clock. In a Laravel-only estate, maintenance cost is effectively the cost of a permanently unowned dependency.

Support: Upstream GitHub issues, Symfony core-team maintainers. No commercial SLA. For an org with no Symfony expertise, the support surface is "read the changelog and hope" — acceptable for a build-time codegen tool, not for anything on the request path.

Scaling: Fits well — this is build-time extraction and cache warming, not runtime serving. It scales with CI, not with traffic. No horizontal scaling concerns. The one scaling-adjacent risk is catalogue churn: large Twig codebases generate large diffs, and the #4059 escaping change will make the first post-upgrade diff noisier than usual.

Failure modes to watch:

• Silent empty translations (#4067) — the worst class: build succeeds, catalogue is empty, users see raw keys in production. Fixed here, but anyone on ≤3.5.0 should audit historical artefacts.
• Misplaced dump directory (#4073, #4081) — assets reference translation files that were written elsewhere; manifests resolve but content 404s.
• Version deadlock with AssetMapper ≥8.2 — manifests as an unresolvable Composer graph mid-upgrade, typically discovered at the worst time.
• Output drift from the escaping fix — downstream snapshot/JS catalogue consumers.

Ramp-up: For a Symfony-fluent engineer, near-zero — it is a conventional bundle with two console commands. For a Laravel-only team, effectively prohibitive: it requires learning Symfony DI, bundle registration, compiler passes, Twig, and AssetMapper to operate a translation extractor. That is not a justified learning investment relative to Laravel's native options.

TPM recommendation: Do not add symfony/ux-translator to the Laravel dependency surface. File it under "Symfony-only tooling," track it passively, and if translation-extraction capability is a real requirement, open a separate evaluation against Laravel-native tooling. Upgrade to v3.6.0 only for existing Symfony consumers, gated on the AssetMapper conflict check and a catalogue diff.