schmittjoh / JMSI18nRoutingBundle

Allows you to internationalize your routing
http://jmsyst.com/bundles/JMSI18nRoutingBundle
358 stars 159 forks source link

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

Open simonihmig opened 8 years ago

simonihmig commented 8 years ago

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.

image

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 commented 5 years ago

Still needed in 2019, +1 for a PR