- How do I install and configure laravel-localizer in a Laravel app?
- Install it with composer require niels-numbers/laravel-localizer, publish the config file, and wrap the route groups you want localized in Route::localize(). Then register the SetLocale and RedirectLocale middleware, making sure SetLocale runs after StartSession and before SubstituteBindings. The documented middleware removal and re-append steps are mandatory rather than optional, because Laravel's default web group puts SubstituteBindings in the wrong place for translated route bindings.
- Which Laravel and PHP versions does laravel-localizer support?
- The package supports Laravel 9 through 13 on PHP 8.2, 8.3, and 8.4, and its CI matrix covers that range. Apps on older Laravel versions or PHP 8.1 are excluded outright. Laravel 14 support is not committed yet, so confirm it with the maintainer before planning an upgrade path.
- Is laravel-localizer compatible with route:cache?
- Yes. Every localized route is registered twice as a static route, once without a prefix and once with a locale constraint, so route:cache works and the localization layer does not degrade Laravel's production route-caching path. This is the main architectural difference from packages that resolve locale prefixes dynamically at dispatch time. The secondary Route::translate mode for translated slugs has different case-sensitivity and 404 behaviour, so do not mix the two modes casually.
- Why do my translated route model bindings return 404 with laravel-localizer?
- Middleware order is load-bearing: SetLocale must run after StartSession and before SubstituteBindings, otherwise bindings such as {post:slug} resolve against the fallback locale and 404. Laravel's default web group puts SubstituteBindings where you do not want it, so the documented remove and append dance is required. Verify the final order with php artisan route:list and a request against a translated slug before debugging anything else.
- Why does $route->getName() return without_locale.about or Route::has() fail?
- The package prefixes route names internally with without_locale. and with_locale., so strict checks like getName() === 'about' and Route::has('about') silently break. Use the shipped helpers baseName(), currentBaseName(), and hasLocalized() instead. Audit middlewares, gates, breadcrumbs, and analytics call sites, since each one is a place a developer can get this wrong.
- How do I build a language switcher with laravel-localizer?
- Link to the localized URL for the target locale, resolved with route() while that locale is active, rather than linking to the plain /about path. A link to /about carries no locale signal, so RedirectLocale sends the visitor back to their session locale instead of switching languages. The package documentation has a dedicated Language Switcher page covering the recommended pattern.
- Does laravel-localizer work with Ziggy, Inertia, or Wayfinder?
- No adapters ship with the package. Frontend integration with Ziggy v1 or v2, Wayfinder, or spatie/laravel-typescript-transformer requires app-side shim code that you write and maintain yourself. The Ziggy adapter shims extend vendor classes and are excluded from static analysis, so Ziggy internals churn lands directly on you. Budget that work on every project instead of assuming it is plug and play.
- How does laravel-localizer compare with mcamara/laravel-localization?
- laravel-localizer is the declared successor, and the key difference is route registration: static routes registered twice instead of locale prefixes resolved at dispatch time, which makes it route:cache-native. It keeps a narrow footprint with a small middleware pair and deliberately does not own translations, formatting, or content negotiation. A migration guide exists, but whether a mid-migration app can run both packages side by side per route group is a question to confirm with the maintainer.
- Is laravel-localizer production-ready and actively maintained?
- It is a small, readable MIT-licensed codebase with Larastan level 6 and no baseline, Pint-gated CI, and a test matrix spanning PHP 8.2 to 8.4 and Laravel 9 to 13. The dominant risk is supply chain: one maintainer, a modest star count, zero dependents, and documentation hosted off-repository on a personal domain, so there is no public production track record. Treat minor releases as potentially breaking, since 1.3.0 changed the Localizer constructor signature, pin your versions, and note that fork-and-own cost is plausibly days rather than months.
- Do the locale redirects in laravel-localizer affect SEO and CDN caching?
- Yes. Because detection is redirect-centric, the default URL depends on user state from Accept-Language, session, or cookie, which has SEO, CDN, and analytics consequences rather than purely functional ones. With hide_default_locale disabled, expect redirects such as /about to /en/about, so decide deliberately whether those should be cacheable at the edge. Confirm what Vary header, if any, the package sets and test the behaviour on your CDN before launch.