The error was the same. The request was correctly updated from `\/` to `\/en` based on the default locale, but apparently Laravel insisted on returning 404 to the test. I would have understood if the status code were 301 or 302, since I’m using\u00a0the LaravelLocalizationRedirectFilter middleware and expect there to be a redirect. But why would the route simply disappear?<\/p>\n

To make a long debugging session short, it turns out that while LaravelLocalizationRedirectFilter middleware correctly leads any browser to make a second request for the new URL,\u00a0the testing framework tries to follow redirects within the routes available to the same initial request object<\/em>.<\/p>\n

Standard operation of Laravel-Localization is to set up a route group with a prefix value of `LaravelLocalization::setLocale()`. When the browser visits the homepage initially, this function returns null so `Route::get(‘\/’, …)` is matched, the middleware is invoked, and the browser is redirected to `\/en`.\u00a0The browser then invokes a second request, this time to `\/en` as directed,\u00a0which means `setLocale()` is called again, this time returning `’en’`<\/em>. So `Route::get(‘\/’, …)` is now prefixed by `’en’`, \u00a0the requested route is matched, and everything works correctly.<\/p>\n

In the test however, there is only ever a single request object, in which the prefix defined by `setLocale()` is simply `”`. This matches the first time, the server runs the middleware and sends a redirect, but instead of making a second request, the testing framework tries to follow the redirect by resolving the new route against the `RouteCollection` in the original `Request` object. Since it was created with a prefix of `”`, any route prefixed by `’en’` won’t exist.<\/p>\n