As a multilingual user of Wikipedia mobile web I frequently check articles in other languages. When i use the button "read in other language" I want a better experience of choosing a language. I am highly intended user to switch the language. It would be nice If software can help me pick a language quickly and without much mental overhead.
There are two parts to this problem. The language switcher and the experience after the intent of switching a language has been established. Before we fix the first problem, we need to fix the second problem.
The classic funnel example of better experience then more people vs more people then better experience.
For e.g. I would invite my friends over for a house-warming party once I have the necessary things in the house for them to have a good experience.
There are two parts to the solution too :) we need to change a small part of functionality and improve the visual design to reduce the "thinking" that a user has to do before tapping on anything.
PART I: The functionality change
While selecting languages, the UI should show 2 buckets of languages.
- Preferred languages
- All other available languages
Preferred languages is a list of languages preferred by the user.
To populate this list there are two ways
- If a user has switched language of an article once
- If user has specified any languages to the OS, browser or anything else that we have access to 
From the above, we already do the first one viz. if someone selects a language it goes to the top. now it will go to this bucket.
Second one just uses similar technique as desktop to learn more about the user.
The goal is to predict what languages the user speaks and put them above everything else under a bucket called "preferred"
 e.g., window.navigator object or potentially in the API response based upon the user's Accept-Language header, although the latter necessarily cannot be cached easily by api.php and the former is much simpler
PART II : The display
The second part of the task is to change how we show list of languages.
Current representation of languages
- This is a flat list of languages
- Without hierarchy, it's difficult to scan
- Missing names of the language in current language
The hierarchical language variants for some languages.
- The first list item shows the primary name and primary domain of the language
- The indented list shows the extension of the primary domain. ZH-HANT, ZH-HANS. as we show ZH on top we just need to show the extension (hans, hant) in the children items
- Two buckets: preferred and all. better visual separation gives purpose of the buckets
- Better hierarchy of words
- Language codes (we need these later when we make language switching better in article)
- The text below the language is the name of the title (not a wikidata description!)
- It must be possible to compare the "old" modal engagement with the "new" modal engagement. One early signal will include data. One signal will be observation of data arriving from the change implemented in T123932: Instrument mobile web language switching user workflow, which will be rolling out on the train week 1 of sprint 65. The other should be an A/B test in mobile web stable; the A/B test in mobile web stable should be conducted in isolation from any different UX placement of the actual "Read in another language" button, so that it is simple to disentangle cause and effect.
- languageOverlayVersion value when languageListLoaded value sent is structured-overlay.