If you're in a region that google defaults to another language, &hl=en (or another language code) is very useful. Nowadays I mainly use it for the maps site, but I've used it elsewhere before when I couldn't struggle through a website in another language. It's very hard to get it into certain google products, like recaptcha. So I have to learn the words for what it wants clicked.

I don't know if parsing the Accept-Language header is too slow, or if google's trying to encourage people to log in to an account.

From what I've heard, Google purposely ignores the Accept-Language header because they believe browsers with a mis-configured language (eg. the browser is set to use english when the user doesn't want english) is more common than browsers with a correctly configured language that differs from their geoip location (eg. someone in France who wants to view a site in english).

That was my guess too. I haven't checked if they ignore it for all languages, or just English.

I remember being very confused when another site (wttr.in) would show up in Russian on a friend's computer for some reason. I later learned that clicking "never translate <language>" back then in chrome's prompt to translate would add that language to the Accept-Language header. The site then served this version, despite en-ie and en being higher priority.

Are these params documented, or just reverse engineered from the JS or something? TFA didn't cite its source, either

On a plain search, click on more, click on web, and then look at the URL you end up on, it's right there. (So, in the most limited sense of the word, "reverse engineered" but in a way that is less work than finding documentation would be if there were any :-)

But verbatim is not useful these days imo. Usually I rather accept that there doesn't exist such information than waste time in googling stuff.

It still works, sometimes. Usually in the afternoon.