Extjslocalization Bundle Laravel Package

Getting Started

Reality check before you install anything: this is a Symfony2 bundle, not a Laravel package. It targets the Symfony 2.x kernel/bundle system and the ExtJS 4/5 era Ext.Loader/override model. Dropping it into a Laravel composer.json will not give you a working service provider — there is none. Treat this repository as a reference architecture for how Symfony wired ExtJS localization, and port the pattern into Laravel (service + route + locale asset pipeline). If you are genuinely on a legacy Symfony2 app, install with composer require sergeil/extjslocalization-bundle, register Sli\ExtJsLocalizationBundle\SliExtJsLocalizationBundle in AppKernel, import the bundle routing, and you are running.

Where to look first, in order:

1. DependencyInjection/ — the extension class shows the config tree (locale directories, default/fallback locale, whether output is served or written to disk).
2. Resources/config/routing.* — the public endpoint(s) the bundle exposes for locale payloads. This is the seam you will re-implement in Laravel.
3. The controller / Resources/views that emits the JS — this is the actual payload ExtJS consumes.
4. Any extractor/loader classes — how translation keys are mapped to ExtJS class overrides.

Minimal Laravel equivalent (first use case): expose a route like GET /extjs/locale/{locale}.js that returns a JS file of Ext.define(...) overrides for ExtJS UI strings, sourced from lang/{locale}/extjs.php, cached with Cache::remember and served with a long Cache-Control. Point your ExtJS bootstrap at that URL per locale. That is the whole value proposition of the bundle, minus the Symfony plumbing.

Implementation Patterns

Serve-time vs build-time. The bundle historically leans on a controller route that renders locale JS on request. Day-to-day this is fine in dev but you want it out of the hot path: either precompile locale files during artisan/composer build steps into public/extjs/locale/{locale}.js, or wrap the route in Cache::rememberForever keyed by locale + a content hash. Precompiled static files win whenever you have more than a handful of locales or a CDN.

Per-locale override files. The ExtJS localization model is class overrides, not gettext. Structure your translations as lang/en/extjs.php returning an array keyed by ExtJS class or override name, then generate a JS file that emits Ext.define('MyApp.locale.en.overrides.SomeClass', { override: 'SomeClass', ... });. Keep the mapping data-only so both backend (emails, validation messages) and frontend read the same source.

Locale resolution order. Resolve locale explicitly from the request/route, then fall back to a configured default. Do not silently read app()->getLocale() in the controller — ExtJS bootstraps once per page load and the locale must be pinned at render time so the loader URL in your Blade layout matches the served payload. Emit the locale JS <script> tag immediately after the ExtJS core in your layout.

Integration with the ExtJS loader. Override classes must be listed in Ext.Loader config or required before instantiation. The reliable pattern is a generated manifest array (MyApp.locale.bundle = ['ClassA','ClassB',...]) shipped alongside the translations, so the frontend loops and Ext.requires each override after the core classes load. The bundle's extracted manifest is the piece worth preserving.

Symfony integration tips (legacy context). Declare the bundle's route under a prefix (/extjs), tag the translator or loader if you swap implementations, and use the DI config (sli_ext_js_localization:) for locale dirs rather than hardcoding paths. If you add locales, remember the container caches the config tree — clear cache after changing it.

Gotchas and Tips

• Abandoned and effectively unmaintained (single star, last release 2019, no dependents). Assume no security patches. Run composer audit on any transitive deps if you are actually installing it, and pin it.
• PHP/Symfony version ceiling. Symfony2 bundle code will not boot on Symfony 5+/Laravel. Don't expect a ServiceProvider; the port is manual.
• Silent translation misses. The ExtJS override model means a missing key usually renders the raw class name or the untranslated default, not an error. Add a dev-only check that diffs generated locale manifests against the default locale and logs missing keys.
• Load ordering is the #1 runtime bug. Overrides applied before the target class exists throw Ext.Loader "class not found" or silently no-op. Always require the base class, then require the override, then instantiate.
• Cache invalidation across three layers. Symfony/Laravel config cache, the HTTP/CDN cache on the locale endpoint, and the browser cache of locale/{locale}.js. Version the URL (?v={hash}) or use content-hashed filenames; otherwise stale UI strings after a deploy will waste your afternoon.
• Locale mismatch. The HTML lang attribute, the Laravel/Symfony locale, and the ExtJS locale file must all agree. A single source (request-derived locale passed into the layout) prevents the classic "date format is right but labels are English" bug.
• Path traversal risk. If the bundle's endpoint accepts a locale segment and reads a file by name, sanitize against an allowlist of configured locales — never interpolate the raw route parameter into a filesystem path.
• Extension points to reuse when porting: the locale-directory config, the manifest generator, and the JS emitter. Everything else (routing YAML, DI extension, AppKernel registration) is Symfony-specific boilerplate you should throw away rather than translate.
• Debugging tip: fetch the locale endpoint directly with curl and assert it returns valid JS (node --check) before blaming ExtJS. Most "localization is broken" reports are a 404, a redirect to login, or a PHP warning prepended to the JS payload.