[HttpFoundation] Similar locale selection

[Spomky]

Q	A
Branch?	7.1
Bug fix?	no
New feature?	yes
Deprecations?	no
Issues	none
License	MIT

Allow the nearest locale to be selected instead the default one.
Ping @welcoMattic

I noted a non-optimized locale selection. Let say I have the following controller and root route:

#[Route('/', name: 'app_root', methods: [Request::METHOD_GET])]
public function indexNoLocale(Request $request): Response
{
    $locale = $request->getPreferredLanguage($this->supportedLocales) ?? $this->defaultLocale;

    return $this->redirectToRoute('app_homepage', [
        '_locale' => $locale,
    ], Response::HTTP_SEE_OTHER);
}

And the following parameters:

• $this->supportedLocales = ['fr_FR', 'en_US']
• $this->defaultLocale = 'en_US'

When a user arrives on this page with the header accept-language: ja-JP,fr_CA;q=0.7,fr;q=0.5, the default locale en_US is returned.
In this situation, I would expect to use fr_FR as the browser indicates French is a possible choice (fr_CA and fr).

With this change, and if no exact match is found, a similar language is selected. In this example, fr_FR is acceptable and then returned.

[Nyholm]

Thank you. It looks cool.

Can you also test these:

ja-JP,fr;q=0.5
ja-JP,fr_CA;q=0.7

Both of them should go to fr_FR, right?

---

How about these?

ja-JP,fr_CA;q=0.7,fr;q=0.5,en_US;q=0.3
ja-JP,fr;q=0.5,en_US;q=0.3
ja-JP,fr_CA;q=0.7,en_US;q=0.3
ja-JP,fr_CA;q=0.7,en;q=0.5

[welcoMattic]

Maybe for another PR, but shouldn't we add support for q= parameter? https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language#directives

[Spomky]

Many thanks for your comments. Indeed there is something wrong with some cases such as this one where en is selected when en-us is preferred just because of the order of the array values.
I will add use cases and make sure q is understood.

[Spomky]

Hi,

I updated the PR and changed the comparison logic:

• If an exact match exists, it is returned
• Else if a similar locale exists, the corresponding language is returned
• If nothing is acceptable, the first supported locale is returned

Please note that the q parameter is already used. The test with a reversed order priority returns the expected language.

In addition, the returned locale value is always xx_XX to make it consistant with the value used internally.
Also, it accepts locales such as hi_Latn_IN to be compared.

[nicolas-grekas]

Here's some nitpicking. What's the state of this PR? Any votes from previous reviewers?

[Spomky]

Many thanks for the last suggestions.
The PR is now rebased, squashed and ready for other reviewers comments

[nicolas-grekas]

That's an improvement, for 7.1 ;)

[stof]

PHP already has a locale matching algorithm in ext-intl: https://www.php.net/manual/fr/locale.lookup.php (or maybe some of the other methods there)

Would this algorithm help for this PR ? If yes, the proper way to solve it might be to implement them in the polyfill in https://github.com/symfony/polyfill/blob/1.x/src/Intl/Icu/Locale.php (where it currently throw an exception saying it is not implemented) and to use it.

[nicolas-grekas]

LGTM thanks

PHP already has a locale matching algorithm in ext-intl [...] the proper way to solve it might be to implement them in the polyfill

Good idea! I suggest merging this PR, and switch to the polyfill once we have it. Nothing is public here so the switch should be easy.

[fabpot]

Thank you @Spomky.