- How do I install and configure Laravel Tongue for subdomain localization?
- Install the package with Composer as pmochine/laravel-tongue, then define your supported locales and default locale in the package configuration. Wrap the route groups you want translated in the dialect() helper so each locale gets its own translated URL set, and register the detects-tongue and speaks-tongue middleware so visitors are matched to a locale on the way in. Because the public surface is small, one helper, two middleware, and a redirect() method, most of the setup is route definition and middleware ordering rather than application code.
- Does Laravel Tongue work with route:cache and Laravel Octane?
- Yes, as of version 6.1.0. The dialect()->localizedRoutes() approach registers translated routes declaratively at boot time instead of at runtime, which makes the route table serializable and therefore compatible with route:cache and long-lived workers like Octane. Earlier versions were effectively disqualified for applications that deploy with cached routes, so pin ^6.1 if that is your production posture.
- How does Laravel Tongue detect and persist the visitor's locale?
- The detects-tongue middleware resolves the visitor's locale from the incoming request, typically from the subdomain or path prefix, against your configured dialects. The speaks-tongue middleware then keeps requests on the localized path, redirecting when the current URL does not match the detected locale. Because the locale is encoded in the URL, it persists naturally across link sharing, caching, and crawlers without depending on session state alone.
- What is the difference between the detects-tongue and speaks-tongue middleware in Laravel Tongue?
- detects-tongue is responsible for identifying which locale the current request belongs to, based on the subdomain or path prefix it arrives on. speaks-tongue acts on that detection by redirecting the visitor to the localized URL for that locale when the requested path does not match. In short, detects-tongue decides and speaks-tongue enforces, which is why the ordering between the two and SubstituteBindings matters.
- How do I register Laravel Tongue middleware in Laravel 11 or 12 bootstrap/app.php?
- Register detects-tongue and speaks-tongue through the withMiddleware() callback in bootstrap/app.php, the same way you register any other web or route middleware in Laravel 11 and 12. Place them ahead of SubstituteBindings so route model binding resolves translated slugs, since the 6.1 release changed that ordering and the change is behaviorally significant. If you still run the legacy HTTP Kernel, register them inside your web middleware group instead.
- Which Laravel and PHP versions does Laravel Tongue support?
- The 6.1 release line is what you should evaluate today, because it is the version that makes translated route registration boot-time and route-cache safe. Exact Laravel and PHP constraints are declared in the package's composer.json and release notes, so confirm those before upgrading a legacy application. The package is framework-idiomatic with no external service, queue, or persistence dependency, which keeps the version constraint the main compatibility question.
- How does dialect()->localizedRoutes() work and do route names need to be unique per locale?
- dialect()->localizedRoutes() lets you declare a set of translated routes once and have the package register a localized variant per dialect at boot time. Because every locale produces its own entry in the route table, route names must be unique per locale, and the usual convention is to prefix or suffix the base name with the locale code, for example welcome.fr. Route-name collisions are the most common failure when multiplying routes across many locales, so pick a naming convention before you scale to a dozen languages.
- How does Laravel Tongue affect route model binding with translated slugs?
- In 6.1 the detects-tongue and speaks-tongue middleware run ahead of SubstituteBindings, which means route model binding resolves against translated slugs rather than untranslated ones. That is the desired behavior for localized URLs, but it changes runtime behavior for applications with custom binding logic, custom route keys, or middleware that previously sat between detection and binding. Test your bindings explicitly after upgrading, especially for models whose route key is itself translated.
- Can Laravel Tongue get stuck in a redirect loop if a translation is missing?
- speaks-tongue redirects to the path of the current locale, so a loop is possible when detection and translation disagree, for example a missing translation for a locale, a locale whose route was never registered, or a misconfigured default locale. Loop protection is not described in the release notes, so verify it against your own route set before shipping and add a safeguard for fallback locales. Redirects also preserve HTTP method and body for non-GET verbs, so decide which route groups are allowed to redirect at all and use the redirect() status argument when you need 301 or 308 semantics instead.
- How does Laravel Tongue compare to other Laravel localization packages?
- Laravel Tongue is a lightweight option focused specifically on translated routes and language switching, with no persistence layer, queue integration, or external dependency. Compared to broader localization suites it does less, but the surface you integrate, a dialect() helper, two middleware, and redirect(), is small, framework-idiomatic, and cheap to reverse. The 6.1 release is what makes it viable behind route:cache and Octane, which is exactly where earlier versions lost ground to alternatives.