search

Hubs-Foundation / hubs

Duck-themed multi-user virtual spaces in WebVR. Built with A-Frame.
https://hubsfoundation.org
Mozilla Public License 2.0
2.13k stars 1.41k forks source link

[Investigation] Hubs language is occasionally not what the user expects them to be #3133

Open misslivirose opened 4 years ago

misslivirose commented 4 years ago

Description We have had a few cases where Hubs attempts to use a language other than what the user is expecting. Today, a user in Vienna reported that they were getting the pt-BR translation. We have also had a user in Singapore report that their browser was displaying Hubs in Chinese on a mobile device. Potentially external issue (see repro steps below)

To Reproduce This doesn't completely reproduce this specific issue, but reporting steps that I've found that seem to indicate that, at the very least, Firefox and Edge/Chromium browsers are handling locales differently:

In Firefox

  1. Set the default language to an unsupported Hubs language (I used French)
  2. Set English as a second supported language
  3. Set Portuguese (Brazil) as a third supported language
  4. Restart the browser
  5. Go to a Hubs room and confirm that 'Default Browser' is selected in the preferences for language support in Hubs
  6. Observe that Hubs is displaying English. Open the browser console and use navigator.languages. Observe that pt-BR is not in the array.

In Edge

  1. Set the default language to an unsupported Hubs language (I used French)
  2. Set English as a second supported language
  3. Set Portuguese (Brazil) as a third supported language
  4. Restart the browser
  5. Go to a Hubs room and confirm that 'Default Browser' is selected in the preferences for language support in Hubs
  6. Observe that Hubs is displaying in Portuguese. Open the browser console and use navigator.languages. Observe that pt-BR is in the array as expected.

Expected behavior The client currently expects to default to en-US if the browser default language is not supported or if none of the languages that are set in the browser as supported languages are localized in Hubs.

Additional context At least part of this seems to be external, as it's not clear why Firefox is not displaying pt-BR in the navigator.languages call. However, it is not clear whether there are other things at play with additional languages.

For troubleshooting When this issue is reported, we should ask users to open the console and report the results of navigator.languages to see if there is another language pack that has been added to the browser. They should also check the languages preference in their browser to see if that matches what the console reports. We should also ask what their default language is for their browser, and whether they are using a VPN. While I don't believe that we intentionally try to fall back to a reported language, I've had times where (non-Hubs) websites default to other languages based on where the visit appears to be coming from, so it might be worth considering that.

┆Issue is synchronized with this Jira Task

johnshaughnessy commented 4 years ago

RE troubleshooting -- While navigator.languages is most commonly used, we also check for a couple of alternatives. We might want to ask for navigator.languages || navigator.language || navigator.userLanguage . (Source: https://github.com/mozilla/hubs/blob/816f37b9eedf1bdf170919ffb66e13817b07c6af/src/utils/i18n.js#L12-L22 )

johnshaughnessy commented 4 years ago

@misslivirose In the edge example above, what is the full array returned by navigator.languages ?

We do not have any fallback locale set for "en-XX", so if your languages were something like ["fr", "en-US", "pr-BR"], we would have:

misslivirose commented 4 years ago

@johnshaughnessy Edge shows this array: ["fr", "pt-BR", "en-US", "en"] . To be clear, I think Edge worked as expected here (though I didn't articulate that in my 'Expected Behavior' note, which I will update) and I started to mix up what may be separate issues here.

robinkwilson commented 4 years ago

This may be a separate issue.

I've been experiencing this as well in my Chrome browser on desktop. Not on mobile.

I set my language to simplified Chinese on my phone, switched it back to English. Now hubs shows up with Chinese language on my desktop computer. It's possible I tried the setting on desktop and switched it back, but it remembered the setting.

joshiamita1 commented 4 years ago

function findLocale() should works like navigator.languages ? navigator.languages[0] : (navigator.language || navigator.userLanguage)

for works for chromium browsers.

misslivirose commented 3 years ago

A note that a user in Thailand experienced this today - their Hubs client had swapped to Chinese without their intervention

joshiamita1 commented 3 years ago

Hey i commented on this post, after searching for a lot, is my solution excepted or it is helpful to you. ?

On Mon, 9 Nov, 2020, 8:31 pm Liv, notifications@github.com wrote:

A note that a user in Thailand experienced this today - their Hubs client had swapped to Chinese without their intervention

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mozilla/hubs/issues/3133#issuecomment-724067900, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIDMB4BDGBMJFNFE4LAKCNTSO775FANCNFSM4SHW6USQ .

johnshaughnessy commented 3 years ago

@joshiamita1 Your proposed solution

navigator.languages
? navigator.languages[0]
: (navigator.language || navigator.userLanguage)

does not account for the secondary languages the browser user might specify (navigator.languages[1]). So for example:

misslivirose commented 3 years ago

Another user in Discord reported this today - they are seeing Japanese localization unexpectedly

johnshaughnessy commented 3 years ago

This PR might help with this issue: https://github.com/mozilla/hubs/pull/3351

Previously, we relied on having an exact match in AVAILABLE_LOCALES or FALLBACK_LOCALES for one of the user's language tags. I was adding a bunch of possible matches to FALLBACK_LOCALES in https://github.com/mozilla/hubs/pull/3350 until I realized the first subtag is the only one that's relevant to us given our limited number of available translations.

I don't know whether this will fix the issue entirely. We should continue to ask users to tell us the output of the console command described above in https://github.com/mozilla/hubs/issues/3133#issuecomment-705109488 when they encounter unexpected languages and track whether it is still happening after the PR is deployed.