- How does Laravel Localizer handle route naming differently than mcamara/laravel-localization?
- Laravel Localizer enforces explicit route naming with `->name()` inside `Route::translate()`, ensuring all localized routes are resolvable via `Route::localizedUrl()`. Unnamed routes in `Route::localize()` remain unnamed, avoiding auto-generated names like `with_locale.`. This change aligns with Laravel best practices and prevents runtime failures.
- Will my existing Laravel app break if I upgrade from mcamara/laravel-localization to this package?
- Most apps will work, but routes inside `Route::translate()` without explicit names will fail at boot. Routes in `Route::localize()` without names remain unchanged but won’t auto-generate names. Test route resolution (e.g., `route('with_locale.')`) and update any implicit naming dependencies. The migration guide covers these changes.
- Does Laravel Localizer support route caching with `php artisan route:cache`?
- Yes, the package is fully compatible with `route:cache`. However, cached routes must adhere to the new naming rules—all translated routes must have explicit names. After migrating, regenerate cached routes to ensure consistency. The package guarantees static, cache-ready routes.
- How does Laravel Localizer detect the user’s language? Can I customize the detection logic?
- By default, it reads the `Accept-Language` header and falls back to session/cookie-based detection. You can extend or replace the detector chain via the `LocalizerDetector` contract. The package also integrates with `RedirectLocale` middleware for seamless locale switching.
- What’s the recommended way to generate locale-aware URLs in JavaScript (e.g., for Inertia.js or Vue)?
- Use Ziggy for static route generation. The package no longer supports `spatie/laravel-typescript-transformer` due to generator limitations. Ziggy’s `route()` helper automatically resolves locale-aware URLs, and the package provides `Route::localizedUrl()` for server-side consistency.
- Can I hide the default locale (e.g., `/about` instead of `/en/about`) in the URL?
- Yes, set `hide_default_locale` to `true` in the config. This suppresses the locale prefix for the default language while still auto-detecting and redirecting users. For example, `/about` will resolve to the default locale, while `/de/about` remains unchanged.
- How do I handle routes that shouldn’t be localized (e.g., API endpoints or static assets)?
- Use `Route::localize()` for routes that *should* be localized, and define non-localized routes outside this block. The package ignores routes outside `Route::localize()` or `Route::translate()`, so they remain unchanged. For APIs, consider using `Route::prefix('api')->group()` separately.
- Are there performance implications for route caching or compilation with this package?
- No significant impact. The package generates static routes during boot and remains compatible with `route:cache`. The stricter naming rules may slightly increase compilation time during migration, but cached routes perform identically to vanilla Laravel. Test with `php artisan route:cache` after updates.
- What alternatives exist if I need dynamic route localization without strict naming rules?
- Consider `spatie/laravel-localization` (legacy) or custom middleware for dynamic locale handling. However, Laravel Localizer’s successor status and `route:cache` compatibility make it the most robust choice for static, production-ready localization. Alternatives lack enforced naming or caching optimizations.
- How do I test locale-aware routes in PHPUnit? Can I mock the language detector?
- Use Laravel’s `actingAs()` with a user having a locale in their session, or mock the `LocalizerDetector` via the container. Test redirects with `Http::fake()` and assertions like `Http::assertRedirect()`. The package provides helpers like `Localizer::setLocale()` for isolated testing.