[php-src] Issue #24074: Make Locale::acceptFromHttp accept a list of possible languages (or return all matches, at least)

Issue: https://github.com/php/php-src/issues/24074 Author: rugk ### Description ### problem [Extracting the HTTP_ACCEPT_LANGUAGE header](https://stackoverflow.com/a/3771447/5008962) is [a very common task](https://neidl.net/technik/php-doku/function.http-negotiate-language.html#86787) and [many implementations in PHP apps exist](https://www.jesseskinner.com/blog/use-accept-language-header/). Some of the quite crude (only take the first two characters into account e.g.) not adhering to [the spec](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Accept-Language) at all, especially [with these q values](https://developer.mozilla.org/en-US/docs/Glossary/Quality_values). There is/was(?) also a PECL HTTP extension which [has http_negotiate_language](https://neidl.net/technik/php-doku/function.http-negotiate-language.html) apparently, which is exactly what we want. So one would expect modern PHP to have a solution for it built-in though. And from a first look, one sees it and thinks it is great: [Locale::acceptFromHttp/locale_accept_from_http](https://www.php.net/manual/en/locale.acceptfromhttp.php) exists! **However**, that just returns *the top-most accepted language* aka it does not allow one to pass in the languages that your application actually supports/is localized in, which makes it effectively useless, because you still need to implement fallback logic. ### workaround This is no new observation. [This SO answer explains it](https://stackoverflow.com/a/9051957/5008962) and [this bug report has been open since 2016](https://bugs.php.net/bug.php?id=59430). That said, I see bugs.php.net is apparently not used anymore, so I wanted to raise it here. As per the old bug: > At least this yes. But in each application we will have a code that looks similar to this: > > ```php >$supportedLanguages = ['de_DE','en_US']; > >foreach (Loacle::acceptFromHttp as $locale) { # AFAIK not quite correct > if (in_array($locale, $supportedLocales)) { > return $locale; > } >} >return $defaultLocale; >``` > > Why a acceptFromHttp if it is useless? The best matching is not useful at all. A list of > matching locales is at least useful ### proposed solution Make it (optionally?) accept a second parameter with a sorted array of strings as supported languages (as by it's preference), which it cleverly parsed, properly-optimized and calculates the "best match" of: ```php public static function Locale::acceptFromHttp(string $header, array $languages): string|false ``` This is exactly what the old [PECL http_negotiate_language](https://neidl.net/technik/php-doku/function.http-negotiate-language.html) did, which I am not sure about whether it's maintained or even exists anymore. Technically [as per already linked SO answer](https://stackoverflow.com/a/9051957/5008962) it should be possible: > PHP wraps ICU's uloc_acceptLanguageFromHTTP without the > ability to pass your locale list. ### resources My own implementation attempts from practice/community https://github.com/PrivateBin/PrivateBin/pull/2043