- How do I install thettler/extended-localization in a Laravel application?
- Install it with Composer using composer require thettler/extended-localization. The service provider is auto-discovered, so no manual registration is required in a standard Laravel skeleton. Publish the package config, register your supported locales in the locale registry, and wrap the route groups that should be locale-prefixed. A working spike is typically possible in under half a day.
- Which Laravel and PHP versions does extended-localization support?
- The package does not publish a maintained compatibility matrix in its release notes, so verify the version pin directly in the package composer.json before adopting it. Check the laravel/framework and php constraints against your target versions rather than assuming support. Because it is a 0.0.x release, the constraints can change between patch versions, so re-check on every bump.
- How is Extended Localization different from Laravel's built-in localization?
- It complements Laravel's native lang file translation rather than replacing it. Laravel handles message and copy translation through lang files and the __() helper, while this package adds the routing and request-lifecycle layer: locale-prefixed URLs, localized route helpers, per-locale metadata, middleware-based locale switching, and model translation support with fallback handling. Use it when locales need to be URL-addressable, not when you only need a single URL space with translated copy.
- How do I store model translations in the database with this package?
- The package provides model translation support with fallback handling, letting translated attribute values live in the database instead of only in lang files. You define the translatable attributes on your Eloquent models and the package resolves the value for the active locale. When no translation exists for the current locale, the configured fallback locale is used. Verify the exact trait, migration, and fallback configuration against the source for your installed version.
- How does automatic locale detection work in extended-localization?
- Locale is resolved from the route, the session, or request headers, in the priority order configured for the package. The included middleware switches and persists the locale, so a user's choice survives subsequent requests. Detection order matters: if you prefer URL prefixes to override a stored session value, confirm that behavior in the config and cover it with a test.
- How do I switch the active locale and persist it across requests?
- Use the package's locale-switching middleware together with its locale-aware route helpers, which generate the correct URL for a given language. The middleware stores the selected locale in the session so later requests keep the same language. Make sure the switch route is registered outside any locale-prefixed group if you want a single entry point for switching.
- Does extended-localization work with Laravel route caching and route:cache?
- This must be proven in your own application rather than assumed. Localized route registration commonly collides with route:cache and with duplicate route names across locales, which is a frequent source of 404s and wrong-language URLs after deployment. Add a CI step that runs route:cache and then exercises URL generation for every locale before you rely on it in production.
- Is thettler/extended-localization stable enough for production use?
- Treat it as pre-stability: at 0.0.x there is no compatibility promise, and Composer treats 0.0.7 to 0.0.8 as a potentially breaking change. The release notes carry only an autogenerated changelog link, so you have to diff tags yourself to see whether public methods, config keys, or route macros changed. Pin an exact version, review commits before bumping, and account for a single-maintainer bus factor before putting locale-prefixed, indexed URLs behind it.
- How does it compare to mcamara/laravel-localization?
- Both operate at the routing layer and provide locale-prefixed URLs, but mcamara/laravel-localization is the mature incumbent with a long track record and a wider user base. Extended Localization adds a configurable locale registry, model translation support, and locale detection from headers and sessions. If you only need localized route groups, the incumbent is the lower-governance-risk choice; choose this package if you specifically want its registry and model translation features.
- How do I test localized routes and locale switching in my app?
- Write feature tests that hit each locale-prefixed URL and assert both the status code and the rendered language, using the package's route helpers to generate the links rather than hardcoding paths. Cover unknown or hostile locale prefixes, the fallback-locale path, and that the middleware persists the chosen locale in the session. Also test with route:cache enabled, since cached route registration is where localized route packages most often break.