Product Decisions This Supports
- One catalog, many runtimes. The core capability — dumping server-side translation catalogs into a JS-consumable form — decides whether your product keeps a single source of truth for UI copy or maintains parallel PHP and JS string files that drift with every release. That drift is a recurring defect class (mixed-language screens, untranslated CTAs, locale-specific layout breaks) and a recurring QA cost.
- Where localization work lives in the roadmap. If translated strings can be shipped to the browser cheaply, i18n becomes a per-locale content task; if not, every new locale is an engineering project. This shapes whether "add Spanish/Portuguese/German" is a two-day config change or a quarter-sized epic.
- Build-time vs. runtime delivery. Two viable architectures: (a) compile locale JSON at deploy and serve static assets, or (b) expose a runtime endpoint that returns the catalog for the active locale. This is a real product decision — (a) is cache-friendly and CDN-deployable but requires a redeploy for copy fixes; (b) lets marketing fix a typo without a release, at the cost of an authenticated endpoint and cache-invalidation logic.
- Buy vs. build verdict: build (small). The functionality is a thin serializer plus a route/asset hook. It is roughly 100–200 lines of code in any modern framework, and it is not a differentiator. Note the framing correction: this is a Symfony bundle, not a Laravel package — for a Laravel codebase it is not adoptable at all short of porting, which is precisely the "build" path.
- A "no" decision with a documented reason. Recording that this specific fork (1 star, 0 dependents, forked from an abandoned upstream) was evaluated and rejected saves the next engineer a week of rediscovery and prevents it entering via a stray
composer require.
When to Consider This Package
Consider it only under a narrow set of conditions, all of which must hold:
- You are maintaining a legacy Symfony 2.x/3.x application that already depends on
willdurand/expose-translation-bundle (BazingaExposeTranslationBundle) and cannot yet migrate.
- The upstream is unavailable or unpatched for a blocker you hit (PHP version, deprecation noise), and a fork is the cheapest unblock.
- You are prepared to vendor-patch or fork-and-own it: pin the commit, add it to your internal patch queue, and accept that you are the maintainer now.
- The blast radius is contained to read-only translation delivery — no auth, no user data, no write path.
Look elsewhere — decisively — if any of the following is true:
- You are on Laravel. This is a Symfony bundle with Symfony DI, routing, and event-dispatcher assumptions. There is no path to adoption. Build a small JSON endpoint or use
laravel/lang/vue-i18n style export tooling.
- You are on modern Symfony (5/6/7). Use
symfony/translation's built-in catalog dumpers to emit JSON at build time, or the maintained successor, willdurand/js-translation-bundle. Reach for the framework's own primitives rather than a two-generations-old fork.
- You have a JS-first frontend (React/Vue/Next). Client-side i18n libraries — i18next, FormatJS/react-intl, vue-i18n — want ICU MessageFormat catalogs, plural rules, and interpolation handled client-side. A Symfony-era dumper produces a flat key→string map that will fight your frontend stack within a sprint.
- You need pluralization, gender, or interpolation. Verify message-format compatibility before committing; a flat dumper will not carry ICU semantics and you will end up re-architecting.
- Governance matters. Zero dependents and one star means zero external eyes on the code. In a regulated or security-reviewed environment, adding an unmaintained dependency requires a documented exception — usually not worth it for a commodity capability.
How to Pitch It (Stakeholders)
To executives: We evaluated a community package for getting translated UI text from the server to the browser. Recommendation is do not adopt. It is an unmaintained fork of a retired Symfony bundle with effectively no user base (1 star, 0 downstream dependents), and it does not fit our stack. The capability is worth having — it removes a whole class of "the app is half-translated" bugs and makes each new locale a content task rather than an engineering project. We recommend a small in-house implementation (estimated 2–3 days of engineering, no new dependency, no maintenance risk) scoped alongside the next localization milestone. Net effect: same product outcome, no supply-chain exposure, and no recurring upgrade tax.
To engineering: The problem is real — keeping PHP and JS string catalogs in sync is manual today and will not scale past two or three locales. Do not pull in hardchor/expose-translation-bundle: it is a Symfony bundle (wrong framework), a fork of an abandoned upstream, and last-generation. Instead, spike a ~2-day solution: dump symfony/translation-equivalent catalogs (or our Laravel lang files) to hashed JSON at build time, serve them from the CDN keyed by locale, and load the active locale in the frontend's i18n provider. Keep a runtime endpoint as a documented fallback if we later need copy fixes without a deploy. If we ever want a library rather than our own code, the maintained option is willdurand/js-translation-bundle — but only if we still have Symfony in the estate. Define acceptance criteria up front: one source of truth, no redeploy to change a string in the fallback path, ICU-safe plurals, and a CI check that fails on a missing key per locale.