Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Search function resets language preference #435

Open
michael-lavaveshkul opened this issue Jun 8, 2021 · 7 comments
Open

Search function resets language preference #435

michael-lavaveshkul opened this issue Jun 8, 2021 · 7 comments

Comments

@michael-lavaveshkul
Copy link

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
Copy link
Member

cmb69 commented Jun 8, 2021

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
Copy link
Member

nikic commented Jun 8, 2021

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
Copy link
Author

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
Copy link
Member

cmb69 commented Jun 8, 2021

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.

@nikic nikic transferred this issue from php/doc-en Aug 18, 2021
@cmb69
Copy link
Member

cmb69 commented Aug 18, 2021

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
Copy link
Contributor

salathe commented Aug 18, 2021

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
Copy link
Member

cmb69 commented Aug 18, 2021

[…], 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants