Closed liyishuai closed 4 years ago
I think that nuxt-i18n will detect user's Language setting (by User-Agent header), so if your browser is in English, it will display English version by default.
And if you choose any language, it will be save in cookie, and read it out next time you visit (although this function is not work now)
My browser's language preferences are zh
and en
, but https://stopcovid19.metro.tokyo.lg.jp/ shows me the Japanese version.
Hi @liyishuai,
Can you please let me know if your browser throws locale preference(s) in zh
w/o country or region code?
If so, we need to revisit our zh-*
locale settings to determine what the locale w/ country or region code should be indeed when the only zh
is thrown from the user agent. Thanks for cooperation in advance
Guys,
Well noted. Please give some time to me so that I can also check on my end what the locale identifier actually is at each symptom that you showed to me
Supposed that an unexpected fallback of locale might be taking place...anyway, I will check and get back to you shortly
Try also https://dev-covid19-tokyo.netlify.com/ Some bugs may be fixed in that newer development version
@86423355844265459587182778, would you try as @MaySoMusician recommends to us? Thanks in advance
Thank you very much for quick turnaround! Got it. Please give me some time
nuxt-i18n
はブラウザの navigator.language
(Firefoxでは intl.accept_languages
と同じ)でも accept-language
ヘッダーでも、最初の2文字しか見てないようです。その2文字が nuxt-i18n.config.ts
内の locales[n].code
に一致する必要がある。
となると、中国語に関しては zh-cn
・ zh-tw
と、どちらも一致しないため(2文字を含むではなく、2文字に完全一致しなければならない)、中国語に関しては自動的に切り替えができない模様です。
英語で上手く動かない理由はまだよくわかっていません
実は、私も先ほどそれに気づいたところです。奇遇ですね(笑)
ただ、detectBrowserLanguage
が先頭2バイトだけを見ていると言っても、そこに到達する途中のどこかのタイミングまでは zh-CN
や en-US
といったフルストリングを見ているようにも思われます。ですので、サフィックスを落とすロジックを手で加えてあげるアプローチが必要そうです。
特に中文に関しては、CN
でも HK
でも MO
でも TW
でもない zh
オンリーのときは zh-CN
と見なすといった、既定対応すなわち「決めの問題」を解決するほかないでしょうね。
en-US
も、似たような話だと思います。en-US
で投げてこられると、en
として判別できないといった問題ではないでしょうか。
いずれにせよ、もう少し見てみますね
上記の問題がそのまま nuxt-community/nuxt-i18n#570 でwontfixになってました ~主な理由としては「今まで2文字言語コードのみで設定していたウェブサイトで誤作動を引き起こす破壊的変更になり得るから」だそうです~ (ちょっと読み違えていました。下のコメントにて訂正) こちらで独自に実装するしかなさそうですね。
en-US
については仕様としては先頭2文字( en
)に切り落とされるはずなので、本プロジェクトの英語言語設定と合致するはずです(こちらでは en-US
ではなく en
で登録しているので)
おそらくブラウザ以外でGETを投げると上手くいかないようです
nuxt-i18n
の該当する処理はこれですが、先に navigator.language
を評価してるせいなのかも...?
accept-language
の1個目しか評価してないところとかを見ると、そもそも実装が雑にも見えますね。 accept-language
の2個目以降は無視しても良いかどうかは自分もよく知らないのですが...。
Edited: 向こうでコメントしたらwontfixも消えました https://github.com/nuxt-community/nuxt-i18n/pull/570#issuecomment-605656602
nuxt-i18n
のPRの方で返信ありました
It's a bug and should be fixed but the fix needs to be done in a different way.
バグとして認識はしているようで、ただどう修正するかは異なってくるみたいです。
というかもともとのコメントを少し読み間違えてたようで、PR提出者に対し「このコードだと破壊的変更になってしまうから、configの方と国指定が合わなかったら2文字コード版にfallbackしてほしい。そうすれば破壊的変更にはならずにすむ」というコメントだったようです。(なおその後PR提出者からの応答は無し)
- This is a breaking change since it can break detection for people who currently use two-letter codes in their configuration
- It can and should be done but this is not the way to do it. It needs to be more complex logic that tries to match full code but fallbacks to two-letter code if not found. Then it could be introduced as non-breaking change.
accept-language
は、本来はまず配列のサイズを見た上で、インデックス順に locale identifier を覗いてアプリ側で持っているそれと一致した場合はループを抜けて次に行く、最後まで見つからなかったときは先頭の identifier から類推する、というのが「正しい」実装方法だとは思います。
とはいえ、可処分リソース(?)の制約条件の下で先頭の accept-language
だけ見るというアプローチも、致し方ないかなあという気はします。私が企業の IT 監査をフィーをちゃんと頂戴してやっているのなら許しませんけどね(笑)
ですので、as long as you can というノリで、やり得る範囲で対応してくれれば超ハッピー!くらいのコメントは差し上げてもよろしいのではないでしょうか
Hi @86423355844265459587182778,
Although I think that your idea would work well in the end, I am unsure how feasible it would be. It is obvious that there would be additional party i.e. infra SME(s) involved so that DNS settings can be configured accordingly.
In this fast-paced circumstance, that kind of activities including some approval workflows with potential paperwork required often incurs unexpected burden in the project. Thanks anyway
リンク先が、他の言語ではなところを改善できないか。
@hanyo さん
たとえば、左メニュー下のクリエイティブ・コモンズ BD ライセンスの URL を言語ごとに切り替えるように、それぞれの言語のページの表示時にそれぞれの言語の外部リンクを指すようにする、という理解でよろしいですね? 間違っていたら、ご指摘をお願いいたします。
で、おそらくそのご用件は、本件とは別にイシューを起票した方が良いようにも思われます。たとえもしも今後プルリクエストが同一になるかもしれないとしてもです。 個々のイシュー・タスクのゴールを明確化する目的があります。
お手数でなければ、個別イシュー起票をお願いできますでしょうか。 ご面倒なときは、ご遠慮なくおっしゃってください
分かりました。 有難うございます。
@hanyo さん、ご協力多謝です。
@MaySoMusician さん、皆さん ついでのようで恐縮ですけれども、本題のお話、すなわちブラウザロケール設定に沿った言語のページが表示されず、常に日本語ページが出てきてしまう件についてです。
現在は、以下の状況が確認できています。特にいちばん最後の項目につき、皆さんのご意見をうかがいたいです。
nuxt-i18n.config.ts
内で、detectBrouserLanguage: {alwaysRedirect: true}
をセットすれば、ブラウザロケールに沿った言語ページへのリダイレクトが行われることが確認できたi18n_redirected
は、そもそもそういう目的、つまり「次」のブラウザ起動時のリダイレクトに時間を割かないようにすることで、ページ表示の高速化を図る目的があるi18n_redirected
がセットされるのは
の2パターンになります。そして、例えば i18n_redirected=en
の場合にen以外のページのURLにアクセスすると
alwaysRedirect: false
の場合(現在の設定)は指定したURLをそのまま表示するalwaysRedirect: true
の場合、en版のページにリダイレクトするという挙動になります。
alwaysRedirect: true
の挙動は、自分とは異なる人が共有してるURLにアクセスした場合、自分の言語で自動的に表示されるというメリットがある反面、特定の言語版のURLを共有するということが難しくなります。こちらについて少し検討する必要があると思います。( lang_redirect=no
のようなクエリ文字列を実装する、などもあり?)
また最初に書いた通り alwaysRedirect
の設定に関わらずそもそも初回アクセス時の言語自動判定は中国語では上手くいかないので、やはり別途対処する必要があるかなと思います。
alwaysRedirect: true
が指定されているときの挙動につき、補足します。ちなみに、参照環境は Firefox Win64 Nightly です。
クッキーがまだない場合はブラウザのロケール設定を見る → 今まで議論された通り、中国語は上手く認識できず、何もセットされない
alwaysRedirect: true
が指定されていれば、簡体字(zh-CN
)繁体字(zh-TW
)のいずれのブラウザ設定も簡体字(zh-CN
)で認識されリダイレクトされることが確認できました。たしか、以前は zh-*
はおしなべて認識されなかったはずです言語メニューで言語を変更したとき
サイト・オーディエンス層に想定されるエスニック・ミックスへの配慮と本件への対応工数との間のバランスの取り方についても議論の余地があると思いますけれども、少なくともそれをここでテキストの形で述べるのは、適切さを欠くおそれがあります。 もう少し考えを整理してから、技術的アプローチに最適化した案を提示します
ありがとうございます。こちらの検証環境は Windows 10 + Firefox 74.0 ですが、上記2点( alwaysRedirect: true
なら中国語がリダイレクトされる・言語メニューでの設定変更時のクッキー変更がされない)について再度検証してみても確認できませんでした。
To Be の状態としては、ユーザーのブラウザの言語設定が zh-cn
なら /zh-cn
、zn-tw
なら /zn-tw
のページが表示されるということでよろしいいでしょうか?
こちらのコメント https://github.com/tokyo-metropolitan-gov/covid19/issues/2535#issuecomment-605670094 にある issue で Nuxt-i18n 本体が修正されるのがいいと思うのですが 、すぐに対応・リリースされるのは難しい印象を持ちました。
workaround になりますが、例えば LanguageSelector.vue
に以下のような実装を追加すると、ユーザーの言語設定に応じたページを表示できるかなと思いました。
(的外れだったらすみません)
created() {
// 1. クライアントサイドのみで実行
// 2. 日本語トップページのときのみ実行
// 3. すでにcookieに言語設定があればそれを利用する
if (!process.browser || this.$router.currentRoute.path !== '/' || this.$i18n!.getLocaleCookie()) return
// ユーザーの言語設定と同様のlocalesがあればそちらに変更
const userLang = navigator.language.toLowerCase()
const locales: string[] = this.$i18n!.locales!.map((l: any) => l.code)
if (locales.includes(userLang)) this.$root.$i18n.setLocale(userLang)
}
@shgtkshruch さん
的外れだなんてとんでもないです。とても助かります。ありがとうございます。
こと緊急性が求められるプロジェクトの性格上、ワークアラウンドは大切だと思います。
恒久対応は、nuxt-i18n
にリスク移転をしましょう
どうやら、nuxt-i18n の方で対応してくれているようですね。 nuxt-community/nuxt-i18n#651 遠からず、上記 PR がマージされるものと思われます
Hi @liyishuai,
Hope you are doing well. Since the nuxt-i18n
module is fixed, I would like you to check the behavior of the Language Switch via the "development" site.
If you feel it as fixed good, can you please close this issue? Thanks in advance
開発版は良いです。ありがとうございましだ!