In T97780#1252841, @JKatzWMF wrote:

@Amire80 This feature is slotted for next sprint for both iOS and Android.

• do we already have a service for identifying top likely languages for user/article?

Nothing very convenient. Extension:UniversalLanguageSelector (ULS) does it for Common Languages in general and for the Compact Language Links beta feature in particular. For a while I wanted to convert this functionality into a more portable service or library, but it hasn't happened yet. If the mobile web team's fine engineers can get around to making it more reusable, we shall be eternally grateful. Actually, the ULS extension has some groundwork for mobile support, although AFAIK it was never truly used anywhere.

In particular, check the following files:

• https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FUniversalLanguageSelector/d04ade35741aded3515bb2eb1057f3e6e3ef5499/resources%2Fjs%2Fext.uls.init.js
• https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FUniversalLanguageSelector/d04ade35741aded3515bb2eb1057f3e6e3ef5499/resources%2Fjs%2Fext.uls.compactlinks.js

If these pointers are too brief or cryptic, please do ask me for more details :)

I don't know exactly what info is available to mobile browsers, but I imagine that the useful info would be:

• Previously browsed editions of Wikipedia
• Previously selected languages
• The device's UI language
• Geolocation
• On cellular connections, the carrier's country (I'm not sure at all that it's available)
• The browser's UI language
• The request's Accept-Language

Also, please do play with the Compact Language Links beta feature on the desktop.

Another thing you may find useful (and yes, I know I'm pitching it everywhere): https://www.mediawiki.org/wiki/Interlanguage_links/Implementation_comparison

One last thing: I am sure that making interlanguage links more discoverable on all platforms is important and useful, but we love to measure impact precisely, so see T78351.

Maybe @Pginer-WMF or @santhosh will have more to add.

Does "Access from current menu" mean from the More menu?

Yes - It means More menu in the top right hand of the page.

I updated the acceptance criteria.

That's called the overflow menu.

I hope you mean the overflow menu from the search fragment, though, since it should be available directly from the search interface.

Please also take a look at the previous tasks related to this, which have been closed prematurely: T87154 and T73136. (I think one person closed one task as duplicate of the other one, then another did the same but in the opposite way.) They already contain a good explanation what pain point we're supposed to solve, and some great ideas on how to fast switch languages.
When I look at the description of this task it seems to try to address finding the language in the language picker dialog. While that is a nice to have thing it's not as important as being able to quickly open the language picker. We already sort the languages by most recently used and most popular language. We also already have a filter EditText field to quickly search by language name.

After looking at the prototype and reading the updates to the description I've got a few more questions:

Add language icon to toolbar

• Is this just for "Read [this article] in other languages"? Do you just want us to rename this menu entry? How is the new title better? BTW, there is no icon needed. Just text.
• What about search language (which we currently have in the More menu)? This is the most important part.

If there are more than 20 languages, organize the list by region. Include "Common languages" and "Worldwide" before regions

• What's the difference between "Common languages" and "Worldwide" languages? Does world wide mean the rest? But then there's also regions. That seems confusing. Why do we need to put the languages into buckets?

The initial languages are decided based on the previous user selections (stored on a cookie), browser language info, and geo-ip information

• We don't store that in cookies but in a SharedPreference.
• I'd prefer to avoid requesting the user's current location. Since that costs battery, and we currently tell users that we only request location data for the nearby feature. I'd be ok with using the most recently requested location from the Nearby functionality.

"Region titles are shown in the current language"

It would be easier to just show it in the device language.

@bearND @Pginer-WMF
What about search language (which we currently have in the More menu)? This is the most important part.

I believe search is in the more section to really simplify the first page, so that if one of the first selections is what the user is looking for, they can very quickly select that, and not be distracted by anything else. In user tests it looks like some users preferred to search, and some preferred to browse.
Also note, the wikiwand app and desktop has a very similar experience.

What's the difference between "Common languages" and "Worldwide" languages? Does world wide mean the rest? But then there's also regions. That seems confusing. Why do we need to put the languages into buckets?

@Pginer-WMF can answer more of this. I think the reason to put languages into buckets is to help break up a very long list into something more easy to browse.

Interesting info from @KHammerstein via IRC:
Here's the link to the initial project https://www.mediawiki.org/wiki/Universal_Language_Selector/Design/Interlanguage_links
This is the compact language links built by the language engineering team (probably @santhosh).
Its a beta feature on desktop.

@santhosh: Where can I find the desktop code that puts the languages into various buckets? Is there an API for that?

@Dbrant is tentatively calling this 5 story points, pending more design input.

@Dbrant will sync up with @KHammerstein on remaining design questions

@Dbrant What remaining design questions are there?

@KHammerstein Sorry, I was a little confused by what this task is actually about. Our highest priority is to improve the way the user selects languages when searching. Since we don't yet have full inter-wiki search functionality, the user has to change the Wiki language through the "More" menu every time they want to search in a different language. So, it would be great if we could give the user a tiny drop-down selection inline with the Search bar for quickly switching languages for searching.

As for reading the current article in a different language, I think our current UX is pretty sufficient (in fact, we already show the most-recently selected languages at the top). The acceptance criteria as stated in this task would take a significant amount of work, with only a marginal improvement in UX...

@KHammerstein see https://phabricator.wikimedia.org/T73136 for a description of language switching when searching

Since we don't yet have full inter-wiki search functionality

That's just a matter of interface though. CirrusSearch provides such a feature in the backend, see T46420.

@Dbrant, this seems user facing. Can it be moved to product backlog?