Make "多言語対応選択メニュー" more visible

liyishuai commented 4 years ago

Non-Japanese users need to identify the language menu by globe icon and "Lang" (which is English). Please consider changing the drop-down menu into an unfolded list of buttons, so that all supported languages are explicitly visible.
Mobile users cannot see language options unless expanding the side bar via top-left menu button. Please consider moving the language buttons out of the folded menu bar.

PichuChen commented 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)

liyishuai commented 4 years ago

My browser's language preferences are zh and en, but https://stopcovid19.metro.tokyo.lg.jp/ shows me the Japanese version.

mcdmaster commented 4 years ago

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

mcdmaster commented 4 years ago

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

mcdmaster commented 4 years ago

Supposed that an unexpected fallback of locale might be taking place...anyway, I will check and get back to you shortly

MaySoMusician commented 4 years ago

Try also https://dev-covid19-tokyo.netlify.com/ Some bugs may be fixed in that newer development version

mcdmaster commented 4 years ago

@86423355844265459587182778, would you try as @MaySoMusician recommends to us? Thanks in advance

mcdmaster commented 4 years ago

Thank you very much for quick turnaround! Got it. Please give me some time

MaySoMusician commented 4 years ago

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文字に完全一致しなければならない）、中国語に関しては自動的に切り替えができない模様です。英語で上手く動かない理由はまだよくわかっていません

mcdmaster commented 4 years ago

実は、私も先ほどそれに気づいたところです。奇遇ですね(笑) ただ、detectBrowserLanguage が先頭２バイトだけを見ていると言っても、そこに到達する途中のどこかのタイミングまでは zh-CN や en-US といったフルストリングを見ているようにも思われます。ですので、サフィックスを落とすロジックを手で加えてあげるアプローチが必要そうです。

特に中文に関しては、CN でも HK でも MO でも TW でもない zh オンリーのときは zh-CN と見なすといった、既定対応すなわち「決めの問題」を解決するほかないでしょうね。 en-US も、似たような話だと思います。en-US で投げてこられると、en として判別できないといった問題ではないでしょうか。

いずれにせよ、もう少し見てみますね

MaySoMusician commented 4 years ago

上記の問題がそのまま 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

MaySoMusician commented 4 years ago

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.

mcdmaster commented 4 years ago

accept-language は、本来はまず配列のサイズを見た上で、インデックス順に locale identifier を覗いてアプリ側で持っているそれと一致した場合はループを抜けて次に行く、最後まで見つからなかったときは先頭の identifier から類推する、というのが「正しい」実装方法だとは思います。

とはいえ、可処分リソース（？）の制約条件の下で先頭の accept-language だけ見るというアプローチも、致し方ないかなあという気はします。私が企業の IT 監査をフィーをちゃんと頂戴してやっているのなら許しませんけどね(笑)

ですので、as long as you can というノリで、やり得る範囲で対応してくれれば超ハッピー！くらいのコメントは差し上げてもよろしいのではないでしょうか

mcdmaster commented 4 years ago

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 commented 4 years ago

リンク先が、他の言語ではなところを改善できないか。

mcdmaster commented 4 years ago

@hanyo さん

たとえば、左メニュー下のクリエイティブ・コモンズ BD ライセンスの URL を言語ごとに切り替えるように、それぞれの言語のページの表示時にそれぞれの言語の外部リンクを指すようにする、という理解でよろしいですね？間違っていたら、ご指摘をお願いいたします。

で、おそらくそのご用件は、本件とは別にイシューを起票した方が良いようにも思われます。たとえもしも今後プルリクエストが同一になるかもしれないとしてもです。個々のイシュー・タスクのゴールを明確化する目的があります。

お手数でなければ、個別イシュー起票をお願いできますでしょうか。ご面倒なときは、ご遠慮なくおっしゃってください

hanyo commented 4 years ago

分かりました。有難うございます。

mcdmaster commented 4 years ago

@hanyo さん、ご協力多謝です。

@MaySoMusician さん、皆さんついでのようで恐縮ですけれども、本題のお話、すなわちブラウザロケール設定に沿った言語のページが表示されず、常に日本語ページが出てきてしまう件についてです。

現在は、以下の状況が確認できています。特にいちばん最後の項目につき、皆さんのご意見をうかがいたいです。

nuxt-i18n.config.ts 内で、detectBrouserLanguage: {alwaysRedirect: true} をセットすれば、ブラウザロケールに沿った言語ページへのリダイレクトが行われることが確認できた
ただしクッキーのライフサイクルが長いのか、ブラウザウインドウをいったん閉じても以前の言語のページが出てきてしまう。すなわち、いちど出した言語で固定されてしまう
クッキー i18n_redirected は、そもそもそういう目的、つまり「次」のブラウザ起動時のリダイレクトに時間を割かないようにすることで、ページ表示の高速化を図る目的がある
でも、クッキーに保存するほどのミッションクリティカルなレスポンスを求められないなら、クッキーを使わずとも立ち上げる度に各言語のページにリダイレクトさせるので構わないのではないか？

MaySoMusician commented 4 years ago

i18n_redirected がセットされるのは

クッキーがまだない場合はブラウザのロケール設定を見る → 今まで議論された通り、中国語は上手く認識できず、何もセットされない
言語メニューで言語を変更したとき

の2パターンになります。そして、例えば i18n_redirected=enの場合にen以外のページのURLにアクセスすると

alwaysRedirect: false の場合（現在の設定）は指定したURLをそのまま表示する
alwaysRedirect: true の場合、en版のページにリダイレクトする

という挙動になります。 alwaysRedirect: true の挙動は、自分とは異なる人が共有してるURLにアクセスした場合、自分の言語で自動的に表示されるというメリットがある反面、特定の言語版のURLを共有するということが難しくなります。こちらについて少し検討する必要があると思います。（ lang_redirect=no のようなクエリ文字列を実装する、などもあり？）

また最初に書いた通り alwaysRedirect の設定に関わらずそもそも初回アクセス時の言語自動判定は中国語では上手くいかないので、やはり別途対処する必要があるかなと思います。

mcdmaster commented 4 years ago

alwaysRedirect: true が指定されているときの挙動につき、補足します。ちなみに、参照環境は Firefox Win64 Nightly です。

クッキーがまだない場合はブラウザのロケール設定を見る → 今まで議論された通り、中国語は上手く認識できず、何もセットされない
- alwaysRedirect: true が指定されていれば、簡体字（zh-CN）繁体字（zh-TW）のいずれのブラウザ設定も簡体字（zh-CN）で認識されリダイレクトされることが確認できました。たしか、以前は zh-* はおしなべて認識されなかったはずです
言語メニューで言語を変更したとき
- これは、残念ながら take effect しないですね。切り替えても反映されません

サイト・オーディエンス層に想定されるエスニック・ミックスへの配慮と本件への対応工数との間のバランスの取り方についても議論の余地があると思いますけれども、少なくともそれをここでテキストの形で述べるのは、適切さを欠くおそれがあります。もう少し考えを整理してから、技術的アプローチに最適化した案を提示します

MaySoMusician commented 4 years ago

ありがとうございます。こちらの検証環境は Windows 10 + Firefox 74.0 ですが、上記2点（ alwaysRedirect: true なら中国語がリダイレクトされる・言語メニューでの設定変更時のクッキー変更がされない）について再度検証してみても確認できませんでした。

shgtkshruch commented 4 years ago

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)
}

mcdmaster commented 4 years ago

@shgtkshruch さん

的外れだなんてとんでもないです。とても助かります。ありがとうございます。こと緊急性が求められるプロジェクトの性格上、ワークアラウンドは大切だと思います。恒久対応は、nuxt-i18n にリスク移転をしましょう

mcdmaster commented 4 years ago

どうやら、nuxt-i18n の方で対応してくれているようですね。 nuxt-community/nuxt-i18n#651 遠からず、上記 PR がマージされるものと思われます

mcdmaster commented 4 years ago

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

liyishuai commented 4 years ago

開発版は良いです。ありがとうございましだ！

Tokyo-Metro-Gov / covid19

Make "多言語対応選択メニュー" more visible #2535