Search function resets language preference

[michael-lavaveshkul]

From manual page: https://php.net/function.array-walk

---

First time submitting a bug to this project. I'm not sure which project this should go under, but I just clicked the "Report a bug" link from the docs.

1. Go to a page in the documentation where you can change the language.
2. Set browser language to something other than your browser's default language.
   1. For example, my browser is set to Japanese, but I chose to use the documentation in English.
3. Go to the search bar and type in a valid top level function name and hit enter. E.g. "count". (Do not click something from the dropdown.)
   Expected: The resulting page is in the language I set (English).
   Actual: The resulting page is in Japanese.
   After that, clicking links will also stay in Japanese until I set my language again.

Similar scenario but with a help page as an intermediary.

1. Go to a page in the documentation where you can change the language.
2. Set browser language to something other than your browser's default language.
   1. For example, my browser is set to Japanese, but I chose to use the documentation in English.
3. Go to the search bar and type in an invalid top level function name and hit enter. E.g. "impld". (Do not click something from the dropdown.)
4. In the resulting help page, it will say "impld doesn't exist. Closest matches:" in English (regardless of your chosen language preference or browser's default language I think).
5. Click on one of the listed matches.
   Expected: The resulting page is in the language I set (English).
   Actual: The resulting page is in Japanese.
   After that, clicking links will also stay in Japanese until I set my language again.

Clicking results from the dropdown doesn't have this issue.

[cmb69]

Thanks for reporting this issue! It should be filed for https://github.com/php/web-php, though, but issues aren't enabled there yet. Should we do that @nikic? There is already https://bugs.php.net/bug.php?id=48726 which reports the same issue.

[nikic]

Thanks for reporting this issue! It should be filed for https://github.com/php/web-php, though, but issues aren't enabled there yet. Should we do that @nikic?

That would make sense to me. A concern I have is that there may not be a lot of people looking at that repo. But I guess there are not a lot of people looking at web-php bugs on bugs.php.net either...

There is already https://bugs.php.net/bug.php?id=48726 which reports the same issue.

This looks like a different case. That report is about the 3rd party full text search, while this one seems to be about our own function name search.

[michael-lavaveshkul]

Thanks for looking at this!

There is already https://bugs.php.net/bug.php?id=48726 which reports the same issue.

This looks like a different case. That report is about the 3rd party full text search, while this one seems to be about our own function name search.

I think so, too. The one linked seems to reference a Yahoo (and now Google?) powered search. I'm referring to the search in the upper right of the screen in a "desktop" view. For my second scenario, the results page I land on goes to https://www.php.net/manual-lookup.php?pattern=impld&scope=quickref rather than www.php.net/results.php as mentioned in the other bug.

I didn't realize I should've checked bugs.php.net. It looks like this one matches my description https://bugs.php.net/bug.php?id=68880.

[cmb69]

But I guess there are not a lot of people looking at web-php bugs on bugs.php.net either...

I guess your're right.

And yes, this would be a duplicate of https://bugs.php.net/bug.php?id=68880 or the other way round. The problem is that we're ignoring LAST_LANG when redirecting.

@michael-lavaveshkul, you can somewhat work around this issue, when you go to https://www.php.net/my.php and set your prefered language to English.

[cmb69]

Not sure what to do here. If we prefer GH issues for Website related bugs, then https://bugs.php.net/bug.php?id=68880 should be closed as duplicate.

[salathe]

Not sure what to do here. If we prefer GH issues for Website related bugs …

Has switching away from bugsweb to GitHub issues been discussed, and received general mumblings of approval, on the webmaster list? I was surprised to see today that GitHub issues has been enabled for this repo, but maybe I missed the discussion.

[cmb69]

[…], but maybe I missed the discussion.

No, you have not. I've written to the ML a few hours ago, but can't link, since news.php.net is down, and marc.info apparently doesn't have the webmaster's list.

[saundefined]

@michael-lavaveshkul

Hi, after updating the search and navbar, I guess the issue is no longer relevant, and we can close it

[michael-lavaveshkul]

Hi @saundefined,

I think I found something related to my second scenario from my original post. The language selected isn't respected in the search results.

1. I set my browser's default language to Japanese first, English second.
2. I navigated to the documentation page
3. Then opened the Spanish docs
4. I Went to the search bar and searched for text curl_close and hit enter, directing me to https://www.php.net/search.php?lang=es&q=curl_close.

Expected: The google results would be in Spanish. Especially since lang=es is part of the query string.

Actual: It seems to give me results in all the languages in All Results, defaulting to Japanese and English first (based on my browser?).

I'm fine to close this one if it's out of scope.

[sy-records]

@michael-lavaveshkul Hi, Google results are beyond our control. By default, it displays results in all languages. When you search for curl_close, you will see multiple identical results, but in different languages. If you need to search for a specific language, you can add "lang", for example: curl_close "es"