Product Decisions This Supports
- Localization scope for legacy admin surfaces. If we still ship an ExtJS-based admin console on Symfony 2.x, this bundle is a candidate for a cheap, server-driven i18n layer: Symfony's translator becomes the single string source, and ExtJS classes read translations generated from the PHP side. That supports a decision to localize an existing tool for a new market without rewriting the UI.
- Build vs. buy (really: adopt vs. vendor). The package is small and does one job — bridging Symfony translation catalogs into ExtJS-accessible JS. The realistic decision is not "buy" but "vendor ~a few hundred lines" versus "adopt an unmaintained dependency." Treat it as a reference implementation, not a vendor.
- Roadmap sequencing: patch now vs. platform migration. Adopting this is an explicit bet that the ExtJS/Symfony 2 stack survives the next 12–24 months. It should be paired with a roadmap item to migrate off ExtJS (and off Symfony 2, which is EOL) rather than treated as a long-term foundation.
- Prioritization of i18n investment. Where the user base is non-English and the admin tool is customer- or ops-facing, this lowers the marginal cost of the first additional locale. It does not support advanced i18n requirements (pluralization rules, RTL, per-user locale negotiation, runtime locale switching) without additional work.
- Licensing/vendor risk review. Because it depends on ExtJS, any adoption decision must be coupled to the Sencha license renewal decision — the bundle's lifespan is bounded by that contract.
When to Consider This Package
Consider it only when all of the following hold:
- We are maintaining, not greenfielding, a Symfony 2.x/3.x application whose UI is ExtJS classes.
- Translation strings already live in Symfony translation catalogs (YAML/XLIBC) and we want to avoid duplicating them in ExtJS locale files.
- The scope is a small, known set of UI strings; we can tolerate a fork-and-vendor model with no upstream support (1 star, 0 dependents, last release December 2019).
- We have verified PHP and Symfony version compatibility ourselves and pinned the code in-tree.
- The locale requirement is simple (one or two target languages, no pluralization edge cases).
Look elsewhere when:
- The application is on Symfony 4/5/6+. The bundle targets Symfony 2 idioms and is effectively unmaintained; you will spend more time on compatibility than on the feature.
- We need a maintainable, supported dependency or a security-response path. There is none here.
- The frontend can use ExtJS's native locale override files or a modern JS i18n library (i18next, FormatJS) fed by a small API endpoint — usually a cleaner, framework-agnostic solution.
- Requirements include RTL, ICU message format, plural/gender rules, or dynamic locale switching; this package does not solve those.
- The greenfield path is open: choose a modern Symfony + JS stack and avoid inheriting an EOL framework combination.
How to Pitch It (Stakeholders)
To executives: This is a narrow, low-cost bridge that lets an existing ExtJS admin tool reuse our Symfony translation files so we can ship a localized version for a new market without a UI rewrite. It is not a strategic platform investment — the package is unmaintained (last release 2019, essentially no community) and depends on the ExtJS license we already pay for. Recommendation: fund it as a time-boxed tactical patch, code reviewed and vendored in-repo, with an explicit expiry tied to the next Sencha renewal and to the Symfony 2 end-of-life migration.
To engineering: Treat it as a reference implementation, not a dependency. The useful logic is small: it maps Symfony translation catalogues into a form ExtJS can consume at runtime. Fork it, pin it, add tests for the locales we actually ship, and gate it behind a feature flag. Confirm PHP/Symfony compatibility before committing — the upstream release predates current PHP versions. Do not extend it for pluralization, RTL, or dynamic locale switching; if those appear on the roadmap, that is the signal to move i18n to a modern JS toolchain rather than grow this bundle.
Risk summary: unmaintained upstream, no dependents, EOL framework pairing. Acceptable only as a contained, reversible maintenance cost — never as a dependency in a new product.