ユーザーのロケール(場所ではない)を検出したい。問題は、どの方法も信頼できないように見えることです。
Accept-Languageヘッダー
長所
- ブラウザがデフォルトで別のものに変更された場合に真のロケールを明らかにできる値のリストを取得することを目的としています。
- 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ジオロケーション
長所
- ブラウザやOSの言語設定とは独立して動作します。
短所
- ブラウザやOSの言語設定とは独立して動作します。
- パフォーマンス、価格設定、最新の状態に保つことなどについてはいつものことです。
結論
- これが実際に機能するかどうかは、ユーザーのロケールを検出しようとしている理由によって異なります。このメソッドは、i18nの意味でのロケールと同じではないユーザーのロケールを提供します。
HTML5ジオロケーション
長所
- 一般的に、サーバーのオーバーヘッドなしでIPジオロケーションと同じくらい正確です。
短所
- ユーザーに自分の場所へのアクセスを許可する必要があります。
- ブラウザのサポート(実際のサポートはかなり良さそうです)。
結論
- 許可を求めなければならないことは、一般的に取引のブレーカーです。また、IPジオロケーションと同じ結論。
概要
現在、ユーザーのロケールの検出はこれまでになく困難になっているようですが、物理的な場所の検出は容易になっています。大きな犯罪者はSafariであり、少なくともOSXのデフォルトではOS設定を反映しているはずですが、Chromeも例を設定していません。ローカル辞書をChromeにインストールしたとしても、リストの一番上にドラッグするのではないかと思います。
他のブラウザがダウンロードページに誤って報告したことでMozillaとOperaが引きずり込まれたことを非難することはできません。ただし、おそらくAccept-Languageを見る代わりに、ダウンロードページをジオロケーションを使用するように切り替えると、問題が軽減されます。
しかし、実際には、IEがもはや支配的ではなくなった今、ユーザーのロケールを検出するためにどのようなオプションが残されていますか?何か残っていますか?