I've found the reason behind the issues. The expression var browserLanguages = navigator.languages || [ navigator.language || navigator.userLanguage ]; assigns 'en-us' in iOS/Mac safari, but in Chrome, it assigns 'en'. en-us could not be found in the sourceLanguages hence it becomes undefined by the following filter:

browserLanguages = browserLanguages.filter(function (language) {
    return language in sourceLanguages;
});

I think there are few approaches to solve this.

• If the language code is not define, we should fall back to 'en'.
• we can add 'en-us' in the sourceLanguages of uls
• if the language code does not exist in our source languages, we could try to remove the coutry code along with the hyphen and run the filter again.

I think first approach is simple and should be done anyway to prevent completely breaking in case a language is not found.

Whaty say?

Here is a pull request using the first approach:

https://github.com/wikimedia-research/translation-recs-app/pull/62

@Sabya, for the en-US issue, there's a different task to fix this: T130044

There's no problem that I see with having nothing pre-selected in the dropdown, except for the fact that the i18n isn't loaded until selecting a language. I think using english would be appropriate for a default localization, but not as a default source.

@Sabya since we haven't heard back from you, we are going to remove this from your todo list. :) Please feel free to claim it back if you have time to work on it. Your contributions are always welcomed here.

It looks like the scrolling issue may be a browser bug: https://bugs.webkit.org/show_bug.cgi?id=153852

Looks like something similar was fixed here: https://gerrit.wikimedia.org/r/#/c/207705/