Indeed, google never behaves for me, always hands me language localized to my ip, even though my Accept-Language contains "en-US,en;q=0.9" (the local language is my native one, but i find using services or software that are originally in English translated to my (non-PIE) language awful, even anger-inducing).
For search i have had &hl=en added to the search parameters since forever.
What works surprisingly often is setting language to en-UK instead. Apparently many sites consider en-US to be some default that they can safely ignore, but en-UK to be a deliberate choice. Nowadays I use that not just for the browser, but for my phone and computer too.
I can say that it doesn't work on Google Docs, which uses the IP address's language^, even though my language is set to en-UK. Unless you're logged in, but I often have to use incognito because of another misfeature which is that Google will dox you to other editors if you access a public Google doc while logged in. Googlers reading this comment: please fix this!
^ I wonder how this works in places like Switzerland and Belgium that have more than one language. The notion that IP addresses can be mapped to languages needs to die.
One drawback I remember was that sometimes experimental features in some app are available strictly for the US (i.e. "vanilla") version, presumably simply because lack of localisation blocks it for "other" versions.
(Sadly cannot recall concrete program, but I think it was some web browser.)
I had my language set to en-NZ when I lived in Indonesia; definitely had Google serve pages in Indonesian to me (and double frustratingly, with US-style dates).
Often with default parameters such as zmap setting ip id to 54321, having tcp initial window at 65535, having no SACK bit set and masscan with no SACK bit either, tcp initial window at 1024, tcp maximum segment size 1460 (which is strange to put below initial window size!), (older versions having fixed src port 61000 or 60000 from documentation examples and no MSS set), all of which are extremly uncommon in legitimate traffic and thus easily identified.
Even those so called "legitimate" scanners (emphasis on the "") seem to use these tools with little or no extra configuration.
With this setup the last time my high-port ssh (key-only) has got an attempt on it was 2023-07-26 (previous intruders get permanently firewalled).
38"? ASUS ROG PG38UQ, 144Hz ips 4k (bought one recently as i wanted a >35" 4k ips with atleast then 120Hz), and from what i can gather it is the only ips screen those specs so far. (I am afraid of oled burnin as i tend to use my monitors for decade+.)
I seem to recall that USRobotics Total Control (dialup servers, ISDN PRI E1 (E1 for me in EU) / T1) to ~30ish dialup lines/ISDN BRI used x86 in the form of 80386ex (386 without real mode).
Whether it was 386ex or just a 386 is a bit hazy as it has been 25+ years since i last opened one up.
I think each line card that supported analog modems up to 4x 56kbit per card had one, along with some DSPs.
Also old Lucent WaveLAN (802.11 era, possibly even the non-standard predecessor) access points had a x86 processor sbc in them.
Normally i would use my first name (a rare Finnish male first name), but someone already used it.
(Maybe it was me years and years ago, but forgot the password and i have no idea if any email account is associated with it.)
For search i have had &hl=en added to the search parameters since forever.