I also don't know why this is the case. I would think that the Accept-Language HTTP header sent by the browser would be a good enough approximation for guessing the user's current country, at least as a convenience feature for pre-populating forms. It doesn't have to be spot-on.
The header contains one or more language codes (e.g. fr) and / or locale identifiers (e.g. en-US) in order of preference. So the first one should match closest the user's current country, if it's a full locale tag.
Since web development shifted heavily towards doing all sorts of magic right in the browser (such as form-processing and personalizing content based on user session) I can only imagine there are some problems with retrieving that locale tag from within JavaScript. The following StackOverflow discussion is hinting at that: stackoverflow.com/questions/104333...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I also don't know why this is the case. I would think that the
Accept-Language
HTTP header sent by the browser would be a good enough approximation for guessing the user's current country, at least as a convenience feature for pre-populating forms. It doesn't have to be spot-on.The header contains one or more language codes (e.g.
fr
) and / or locale identifiers (e.g.en-US
) in order of preference. So the first one should match closest the user's current country, if it's a full locale tag.There's also an article about that header over at w3.org.
Since web development shifted heavily towards doing all sorts of magic right in the browser (such as form-processing and personalizing content based on user session) I can only imagine there are some problems with retrieving that locale tag from within JavaScript. The following StackOverflow discussion is hinting at that: stackoverflow.com/questions/104333...