Ux Translator Laravel Package

Product Decisions This Supports

• Client-side i18n without a second translation stack. Symfony UX Translator (the package behind these notes) lets a Symfony/PHP backend's existing Translator catalogs drive JavaScript translations via ICU MessageFormat. For a PM, that removes a recurring build-vs-buy question: "do we adopt i18next/FormatJS and a separate JS catalog, or reuse the catalogs we already maintain?" This package is the reuse answer.
• Roadmap scoping for localization. It is enabling infrastructure, not a user-facing feature. It supports a roadmap item like "make the app fully translatable, including JS-rendered UI," and it directly reduces the cost of plurals/gender/ICU formatting parity between Twig-rendered and JS-rendered copy.
• Reducing duplicated translation work. One catalog served to both server and client means fewer keys to keep in sync, fewer "the plural rule differs on the client" bugs, and less translator/vendor churn.
• Integration risk management. v3.6.0 is a patch release dominated by correctness fixes around translation dumping and cache warming, plus an explicit conflict with symfony/asset-mapper 8.2+. That is a dependency-pinning decision (Symfony/AssetMapper version alignment), not a product decision — worth tracking if we are on Symfony 8.2+ or plan to be.
• Not a Laravel-native choice. For a Laravel-first product, this is only relevant in a hybrid Symfony/Laravel or Symfony-component context; a standard Laravel app would normally use Laravel's own translator with lang/*.json plus laravel-vue-i18n/i18next. Treat this package as a Symfony-side option, not a default for Laravel roadmaps.

When to Consider This Package

Consider it when:

• The application is Symfony (or a Symfony-based service inside a PHP monorepo) using AssetMapper and the Symfony Translator, and there is JavaScript-rendered UI that needs the same strings as Twig.
• You need ICU MessageFormat in the browser (plurals, select/gender) and want it to match server-side output exactly rather than reimplementing rules.
• You want a lightweight, no-runtime-service approach: translations dumped at build/container time, served as static assets — good for caching, CSP, and offline/perf-sensitive pages.
• Your translation volume and workflow are modest (one catalog, a handful of locales, translation handled in-repo or via simple export). This is plumbing, not a TMS.
• You are willing to pin Symfony/AssetMapper versions. v3.6.0 includes a conflict guard with symfony/asset-mapper 8.2+, so check version alignment before upgrading.

Look elsewhere when:

• The product is Laravel-native with Inertia/Livewire/Vue and no Symfony translation layer — use Laravel's translator plus a JS i18n library; adopting this adds a bridge you don't need.
• You need a TMS-managed workflow (Crowdin/Lokalise/Phrase, in-context editing, translator roles, per-locale review gates) — this package is not that, and won't replace it.
• You are building a large SPA with heavy runtime locale switching, lazy-loaded namespaces, or per-component catalogs — react-i18next/vue-i18n with dynamic loading is a better fit.
• You are not using AssetMapper (e.g. Webpack Encore/Vite-only) — the dump/asset integration is the core value, and the recent fixes are all in that area.
• You need mature, versioned API stability guarantees across a long support window: this is Symfony UX, versioned in step with Symfony releases; budget for regular patch upgrades.

How to Pitch It (Stakeholders)

For executives: This is not a new feature — it is localization plumbing that lets the strings we already translate on the server also work in JavaScript. The benefit is cost avoidance: we don't maintain a second translation catalog or buy a separate JS i18n toolchain, and we reduce the class of bugs where a plural or date renders differently in the browser than on the server. Investment is small and contained; there is no user-visible change to announce.

For engineering: v3.6.0 is a patch release with no breaking changes and no new features — it hardens the translation-dump and cache-warm paths (ux:translator:warm-cache no longer writes empty translations; translations are dumped when the container is built without a dump directory; the configured dump directory is correctly registered with AssetMapper; translation IDs are fully escaped; tooling dependencies updated). The one thing to action is the symfony/asset-mapper 8.2+ conflict guard — verify our version constraints before upgrading, and re-run the dump/warm-cache steps in CI to confirm no empty or missing catalogs ship. Upgrade is low risk and can ride our normal patch cadence; no migration work, no deprecations to schedule.

Recommendation: Adopt/maintain, low strategic weight, no roadmap slot needed. Re-evaluate only if we move localization to a TMS or leave AssetMapper.