我想检测用户的语言环境（而不是他们的位置）。问题是这些方法似乎都不可靠。
接受语言标题
优点
- 如果浏览器已更改为默认设置，您将获得一个可以显示真实语言环境的值列表。
- 默认情况下在 IE 中似乎准确？
- 默认情况下在 IE 中准确意味着默认情况下在 Windows 上的 FF 中准确？（即您从 mozilla.org 下载正确的版本）
- 与 Windows 上的 Opera 的 #3 相同吗？
缺点
- 服务器端开销和对缓存的干扰（或额外的 XHR）。
- 在所有英语系统上的 Chrome 中默认为“en-us”，除非您安装本地词典并将其拖到顶部。
- 不是 Safari 发送的？
- 在 Safari 和 Chrome 中默认不正确意味着http://mozilla.org和http://opera.com将用户定向到错误的下载，并且还会安装它们自己的“en-us”版本。
结论
- 在 OSX 上完全不可靠，因为默认情况下每个浏览器都会出错。但是在 Windows 上的 IE 和 FF 中应该是准确的。
window.navigator.language/userLanguage
优点
- 最好的部分是它是一个很好的轻量级客户端解决方案。
- 默认情况下在 IE 中似乎准确？
- 默认情况下，在 Windows 上的 FF 中似乎准确？
缺点
- 默认情况下，在所有系统上的 Safari 中始终“en-us”。
- 在所有英语系统上的 Chrome 中默认为“en-us”，除非您安装本地词典并将其拖到顶部。
- 在 Opera 中总是只有“en”。
结论
- 甚至比 Accept-Language 更不可靠。
IP地理定位
优点
- 独立于浏览器和操作系统语言设置工作。
缺点
- 独立于浏览器和操作系统语言设置工作。
- 关于性能、定价、保持最新等的所有常见问题。
结论
- 这是否真的有效取决于您为什么要尝试检测用户的语言环境。此方法为您提供用户的位置，这与 i18n 意义上的区域设置不同。
HTML5 地理位置
优点
- 通常与 IP 地理定位一样准确，无需服务器开销。
缺点
- 要求用户允许您访问他们的位置。
- 浏览器支持（实际上支持看起来很不错）。
结论
- 不得不征求许可通常会破坏交易。也与 IP 地理定位相同的结论。
概括
现在似乎检测用户的区域设置比以往任何时候都更难，而检测他们的物理位置变得更容易了。最大的罪魁祸首是 Safari，它至少应该在 OSX 上默认反映操作系统设置，但 Chrome 也没有设置任何示例。即使人们将他们的本地词典安装到 Chrome，我真的怀疑他们也会将其拖到列表的顶部。
我不能责怪 Mozilla 和 Opera 被其他浏览器误报到他们的下载页面所拖累。但是，如果他们将下载页面切换为使用地理定位而不是可能查看 Accept-Language，这将缓解问题。
但实际上，既然 IE 不再占主导地位，还剩下哪些选项可以检测用户的语言环境？还剩下什么吗？