- What is escalated-dev/locale and is it a normal Laravel package?
- escalated-dev/locale is not a conventional Laravel library; it is a language-catalog data package with a thin Composer wrapper. The real deliverable is the canonical locales/{locale}.json set that is also republished to npm, RubyGems, Maven, NuGet, Hex, PyPI, and Go. It is a strong fit only if your application already consumes Escalated plugins and needs a shared, versioned translation baseline. As a generic i18n dependency it adds little, because Laravel's native lang files and __() helper already cover that ground.
- How do I install escalated-dev/locale with Composer in a Laravel app?
- Install it with composer require escalated-dev/locale, then publish any config the package ships if a service provider is registered. After that, decide your merge order explicitly, with package defaults loaded first and app-local overrides layered on top. Adopt it in a single non-critical app first and diff the resulting keys against your existing lang files before touching production.
- Which PHP and Laravel versions does escalated-dev/locale support?
- The README excerpt does not publish a minimum PHP version or supported Laravel majors, so check the require constraints in composer.json on Packagist before installing. Because the package is pure data behind a thin wrapper, constraints are usually permissive, but permissive is not the same as CI-tested. Pin a version in composer.json and confirm the constraint against your framework major during your first install.
- How do I override a translation that ships in escalated-dev/locale?
- The documented pattern is to load the package locale data first and then layer framework-local or app-local overrides on top. Collision behaviour is not specified in detail, so assert the precedence yourself in a test rather than assuming it. Keeping emergency patches in your own lang/vendor files is the safest fallback if the merge semantics surprise you.
- What is the difference between escalated-dev/locale and Laravel's lang directory?
- Laravel's lang directory holds your application copy and is resolved by the __() helper, while escalated-dev/locale ships vendor baseline catalogs for the Escalated UI and plugin surface. In practice it sits alongside lang rather than replacing it. Its value is consistent translated strings across the Vue frontend and PHP backend from one versioned source.
- How do I add a new locale or translation to escalated-dev/locale?
- To add a locale, copy locales/en.json to locales/{locale}.json, translate the values, and run the sync script (bash scripts/sync.sh or pwsh ./scripts/sync.ps1). To change a string, update the source translation upstream or edit locales/en.json directly if the central package is now the canonical owner, then rebuild with scripts/build_locales.py. If you do not maintain the package, fork it or vendor the JSON instead of waiting on a pull request.
- Does escalated-dev/locale register a service provider or publish config?
- The documentation is thin on boot behaviour, and the package is essentially data, so treat any provider, config file, or Artisan publish command as something to verify after install. Run php artisan vendor:publish --provider if a provider exists, or skip it entirely. Bypassing the provider is viable: vendoring locales/*.json into lang/vendor/ removes the runtime dependency altogether.
- How should I test escalated-dev/locale translations in my Laravel app?
- Diff the keys from the package catalogs against your existing lang files to quantify overlap and collisions before shipping. Assert the fallback chain and merge precedence in a feature test, and check for duplicate keys and malformed {name} placeholder tokens. A schema validation pass over the JSON before deployment catches the most likely failure mode.
- Is escalated-dev/locale safe for production and what are the supply chain risks?
- The security surface is small because the package is pure data, but the trust decision is real: adding an unknown namespace to composer.json grants it autoload and boot participation. Signals are thin, with a few stars, no dependents, and a single publishing pipeline spanning eight registries, so one bad sync can break every ecosystem at once. Treat it as a vendored data dependency rather than a core platform component.
- Who maintains escalated-dev/locale and what are the alternatives?
- Maintenance appears to be a one-person effort with no stated support window or documented deprecation policy, though a recent release date suggests active upkeep. Alternatives include Laravel's built-in lang files, a community translation loader such as spatie/laravel-translation-loader, or simply forking the JSON catalogs and internalising them. If you only need a reference-quality set of locale catalogs, vendoring the JSON gives you most of the value with none of the runtime trust.