IIRC, it is possible to have an i18n route "my_route" (so its names are technically my_route.en, my_route.hr, etc.) and an unrelated route with the name "my_route".

Passing the default locale to the UrlGenerator would be a BC break because it would generate another route than currently with the default value.

I think we need to deprecate having a route with the same name than an i18n route so we can actually do something about this in Symfony 5.0.

Kind of related to : #30010

Not sure it would be a BC break since the problem is that there's inconsistent behavior between the web and cli contexts. The route exists when generated in a web request cause it gets the locale from the request context ($this->context->getParameter('_locale')):

class LocaleController extends AbstractController
{
    /**
     * @Route({
     *    "en": "/locale",
     *    "hr": "/lokalno"
     * }, name="locale")
     */
    public function index()
    {
        // This works
        return new Response($this->generateUrl('locale'));
    }
}

Currently the same route generation call behaves differently depending on the context it's being run in (WEB or CLI). In a WEB context the above route would be generated just fine, while in CLI it'd throw an exception. The system does not behave consistently and I don't see how this can be treated as anything but a bug.

Another solution which would avoid this "breaking change" and allow us to make the behavior consistent no matter the context is adding another parameter (let's call it router.request_context.defaut_locale for example) which would work the same as all other similar parameters as described in https://symfony.com/doc/current/console/request_context.html

Since that parameter doesn't exist yet it would always default to null unless explicitly set so the current behavior remains the same while it allows developers to override/customize it.

Adding this new parameter looks good to me.

@stof Hm, but would we then have two different parameters/configuration options for the same thing, framework.default_locale & router.request_context.defaut_locale?

We don't have framework.default_locale. We have framework.translator.default_locale, which will not exist at all if you don't enable the translator. So we cannot make it a hard dependency.

@stof Not sure what you mean, I was referring to the FrameworkBundle configuration, which is set as kernel.default_locale.

The default locale is used if no _locale routing parameter has been set.

hmm indeed. I confused things. Using the kernel.default_locale would indeed make sense then.