- How do I install and set up codezero/laravel-localized-routes?
- Install it with Composer (composer require codezero/laravel-localized-routes); the service provider is auto-discovered. Publish the config file, define your supported locales, and organize your routes into per-locale route files that the package wraps in locale-prefixed groups. Register the locale detection/redirect middleware if you want automatic locale resolution. Installation is quick, but retrofitting an existing app is the real work: audit every route(), url(), redirect(), hardcoded anchor, sitemap generator and email template that emits a URL.
- Which Laravel versions does this package support, and is it still maintained?
- Check the composer.json constraints on the repository before committing, because the latest release was March 2024 and the maintainer footprint is small with few listed dependents. Confirm it installs cleanly on your target Laravel 10 or 11 app and run your test suite against it. Treat the dependency as adopt-with-an-exit-plan: keep route definitions in your own files so you can fall back to a native locale prefix group if it lags behind a future Laravel major.
- Does it survive route:cache, route:list and Laravel Octane?
- Localized routes are registered as route groups per locale, so they should cache like normal routes, but you should prove it rather than assume it. Add route:cache, route:clear and route:list to your CI pipeline and run them against the localized route files. If you use Octane, verify that locale state is not leaking between requests in long-lived workers.
- How do I translate route segments and route names per locale?
- You define a translation for each route path segment per locale so /en/about renders as /nl/over-ons, while route names can stay stable or be translated as well. Segment translations are typically kept in lang files; dynamic content such as product or article slugs usually needs per-locale columns on the Eloquent model plus customized route model binding. The slug storage decision is a schema and content-ops choice, not a package setting, and it is where most schedule risk lives.
- Does the package handle locale detection and redirects automatically?
- Locale detection and redirect middleware are part of the package's core value: it consolidates locale-aware URL generation, translated segments and detection/redirect behaviour that teams otherwise hand-roll. If locale choice is persisted in a cookie or session, test how that behaves behind a CDN and make sure your Vary headers and cache keys are correct. Also decide on the fallback behaviour when a requested locale has no translation before you ship.
- Does route() automatically include the current locale?
- Yes. You keep using the same route helper API and the generated URL is prefixed with the active locale automatically, which removes the common bug where a hardcoded route() call silently drops the locale. To link to another language, switch the locale context (for example in a language switcher) and call route() again. Verify helper output in a feature test rather than only in the browser.
- Does route model binding resolve models by their localized slug?
- Out of the box, binding resolves by whatever key you register on the route. If URLs need localized slugs, store a slug per locale and override resolveRouteBinding on the model, or use an explicit binding, so /nl/over-ons resolves the Dutch record. Add tests for each locale to catch mismatches between generated URLs and binding logic before launch.
- What about URLs generated in queued jobs, notifications and emails?
- Locale context is request-scoped, so anything running outside an HTTP request needs explicit locale handling. Queued jobs, notifications, signed and temporary URLs, sitemap generators and auth scaffolding packages are the most likely breakage points because they emit URLs without going through your localized route context. Wrap those code paths so the intended locale is set before the URL is generated, and cover them with tests.
- How does it compare to mcamara/laravel-localization or a plain {locale} route group?
- mcamara/laravel-localization has much larger mindshare and a longer track record, so it is the natural benchmark. A native {locale} prefix group is simpler and dependency-free if you only need prefixes and have a handful of routes. Choose this package when you want translated segments and translated route names plus locale-aware helpers in one small dependency, and weigh that against its thinner maintenance signal.
- Is changing URLs with this package risky for SEO?
- Yes. Changing URL structure is effectively a one-way door for rankings, so plan 301 redirects from every old URL to its localized equivalent before launch. The package handles URL structure, but canonical tags, hreflang pairs and sitemap generation remain your responsibility. Roll out one low-traffic section with a single locale pair first, confirm crawl behaviour, then expand.