DefaultLocaleResolver does not support Accept-Language header with extended locales (de-DE)

[simonihmig]

We had some issue at least with Safari on Mac, which sends a Accept-Language header with a single value of "de-de" (see the screenshot), so without a fallback "de" which other browsers do send.

This "extended" locale is not recognized by the DefaultLocaleResolver, so it returns null and the default locale ("en" in this case) is used.

I changed the behaviour by replacing the locale resolver with a custom one like this:

class LocaleResolver extends DefaultLocaleResolver {

    /**
     * {@inheritDoc}
     */
    public function resolveLocale(Request $request, array $availableLocales)
    {
        $locale = parent::resolveLocale($request, $availableLocales);

        // JMS\I18nRoutingBundle\Router\DefaultLocaleResolver does not work as expected in case the browser sends only a
        // long version of a locale, e.g. de-DE. We add a fallback here, by using getPreferredLanguage()
        if (empty($locale)) {
            return $request->getPreferredLanguage($availableLocales);
        }

        return $locale;
    }

} 

This fixes the issue, as $request->getPreferredLanguage($availableLocales) has already support for those "extended" locales (don't know the correct technical term).

I wonder why this is not used by the DefaultLocaleResolver in the first place? If there are no objections, I could create a PR.

[flodaq]

Still needed in 2019, +1 for a PR