Topic on Talk:Universal Language Selector/Compact Language Links/Archive 2

I guess I will continue complaining about this, as I did here (https://phabricator.wikimedia.org/T136677 – not sure if it was the right place) and repeat my comments.

This feature is annoyingly complicated. Please make the list more simple, and get rid of the pop-up window. A similar approach that has been taken for the mobile version would be good. I don't understand the need for this kind of complexity. For example, compare a situation of a typical article with 17 interwiki links in the English wiki and the Finnish one: which list is more complicated to navigate, the English one with 17 languages – or the Finnish one with a separate scrollable pop-up window, five different categories and two columns of text!?

Hiding the interwiki links like this actually causes me a lot of extra trouble instead of helping me. I am interested in a fairly wide array of languages, as well as seeing, which languages are available for a given topic. For example, on the Finnish Wikipedia page on Philippe Buonarroti (https://fi.wikipedia.org/wiki/Philippe_Buonarroti), nine interwiki links are shown and seven are hidden. I have to open a pop-up window to know which languages they are. Instead of showing me a list of those previously hidden languages, I have a long list of all the available languages grouped into eight (!) different categories, some geographical and some not, with some languages repeated (e.g. Russian is on the list three times, and English a full eight!). If I was searching for Hungarian, for instance, I would have no way of knowing whether it actually exists, and I would have to browse through a long and confusingly, unintuitively arranged list to actually know that yes, there is a Hungarian article available on the topic (if I ever made it that far). This feels outright discriminatory in some ways.

It seems to be a larger trend to only show users content that a service presumes that they would be interested in. I'm sure that this is often terribly useful, although sometimes problematic (as in the case of Google algorithms that leave out certain search results and bring up others, for example). Here, however, that is currently executed in a way that I find quite annoying. Using a simple, alphabetised list in which what you see is all there is can in many situations actually be easier, more equal, neutral and helpful. Browsing different languages and moving between them, which I like to do a lot, becomes much more difficult with this kind of an arrangement. Now, this does not preclude lifting up some languages to the top of the list, for example (like has been done with the mobile version), but the current version is IMHO a complete mess.

Thanks for your feedback @Epiq. I'll try to cover the different topics mentioned below:

Language grouping

You provided a good example that illustrates the need for some improvements in this area. The grouping by region has proven to be helpful when there are many languages available (e.g., articles such as Moon available in ~200 languages, or in tools such as Content Translation where it has been used to select among all existing languages to translate to/from).

However, for pages available in fewer languages, grouping by region may add some unnecessary complexity. It makes sense to avoid the grouping in those cases, and this is something we plan to work on. More details are available in this ticket.

Using a separate panel to access more languages

Regarding the use of a separate panel for language selection, we considered that it (a) allowed the user to focus on their languages of interest (the initially visible provides enough room to include the number of languages most of our uses speak), and (b) it allowed us to provide advanced searching capabilities to facilitate the selection. Searching was the most common method for users to find their language during our research, and providing flexible search (you can search for a language based on the name in another languages, making typos or using the ISO codes) made it easier to support the cases where the language you are looking for was not in the initial list.

Although the tool does not show initially all the interlanguage links, the access to them is provided through a "continuation" pattern where it is quite clear how to access to the rest of the languages. Our research confirmed that users were able to figure out how to find their language when it was not present in the initial list (something that they only need to do once at most). We are monitoring the volume of inter-language navigations to identify any potential issues.

Advanced usecases

Our main usecase we optimised the tool for is for multilingual users to quickly navigate across the languages they know (to read/edit the content). With the previous model, a user speaking several languages was forced to search their languages again and again on lists of very different length. Every single time. This is especially harming for small languages (in which few articles are available, but those available are also available in many others), since users often do this effort in vain which demotivates users to check if content is available in their language.

With the Compact Language links, once the user selected their languages once, they become extremely visible later, making it easy to navigate to them and inviting to do so. We think this significantly improves the experience of many multilingual readers and editors.

Having said that, we know there are many other usecases, and we'd like to explore how to better support them. In order to do so, we need a deep understanding of the activities those involve. You said you are interested in a wide array of languages, would you be able to describe the use you do of them in more detail? Are the listing of language links in Wikidata a reasonable mechanism to support those?

Keeping users in control

I don't think Compact language links could be described as part of the trend of "only show users content that a service presumes that they would be interested in".  Human intervention is given priority in the languages shown more prominently to the user:

• Individual users can decide their preferred languages by selecting them. Previous choices is the criteria with a highest priority (since it is based on actual decisions by the user), it will not be overridden by other guesses.
• Browser accept languages are also considered. The user can configure those through the browser settings.
• Communities can define their list of closely related languages that will be taken into account to surface those, when there are no previous selections.
• Finally, other criteria such as location-related guesses are based on CLDR, an information repository open for contribution.

More details about how are languages selected are available here.

Hi Pginer-WMF, thank you for your reply.

Language grouping

This might really be the biggest problem of the feature. I do understand the need to get a more usable interface for articles with dozens or hundreds of interwiki links, as an alphabetical list gets terribly long and hard to navigate. However, this subset of articles is relatively small for big wikis – the vast majority of articles must have from a few to a few dozen iw links. Instead of starting with the cases that are actually problematic and easy to improve, you adopted an unnecessarily complicated approach for situations that are working just fine. Apparently you have done research here (?), but as you see in the ticket you refecenced above, the result is just ridiculously complex. I do not understand why you could not have taken a safer approach from the start and just see first how this feature is actually working for the difficult cases (say over 50 links) before making many more people suffer using it.

Using a separate panel to access more languages

"[A]llowed the user to focus on their languages of interest (the initially visible provides enough room to include the number of languages most of our uses speak)" – so basically prioritizing large languages on the expense of smaller ones, because they are searched less?

"[I]t allowed us to provide advanced searching capabilities to facilitate the selection" – so does the mobile version, the design of which is much superior to this one. Why can't you just include a simple search box above the list of links? It works great in the mobile version!

Advanced usecases

"With the previous model, a user speaking several languages was forced to search their languages again and again on lists of very different length. Every single time." That is true, and the reason why the mobile version with a few links lifted above the list coupled with a search feature works well. Having to use a confusingly subcatecorized pop-up window does not in my opinion make the situation better overall. I am a user speaking several languages who has had to search for his languages on different length lists for years and years, and this is still hugely more annoying to use.

"With the Compact Language links, once the user selected their languages once, they become extremely visible later, making it easy to navigate to them and inviting to do so." I have not disputed this (and as I said I think it works great in the mobile version), I only have a problem with the execution of the feature. However, I must point out that this is actually not working for me at all when I'm not logged in (browser history/cookies are cleared, IP changes), which is most of the time when I check Wikipedia on the computer. I just see a random and/or geographical selection of languages which is even less useful for me since I live in a country where my native language is not spoken.

"You said you are interested in a wide array of languages, would you be able to describe the use you do of them in more detail? Are the listing of language links in Wikidata a reasonable mechanism to support those?" I'm not sure what you are referring to with the Wikidata list – it's just a regular alphabetical list? I meant that I don't check just, say, Spanish every single time; if I'm reading an article on something Czech, maybe I'll check the Czech article, if Danish, the Danish article, or even all or most of the interwikis if I'm writing on something, or translations of a term by just hovering over the link, etc. etc. I'm wondering if you actually use the iw links much in spite of making changes to them...?

Anyway, I now managed to hide this whole thing globally, so out of sight and out of mind, I guess...

"[A]llowed the user to focus on their languages of interest (the initially visible provides enough room to include the number of languages most of our uses speak)" – so basically prioritizing large languages on the expense of smaller ones, because they are searched less?

No. I was referring that we are showing up to 9 languages in the main list and most users consume content on less than 9 languages. so over time, as users access content in their languages of interest (bigger or smaller), those will be right at hand to easily switch to them back and forth with no additional searching effort.

"[I]t allowed us to provide advanced searching capabilities to facilitate the selection" – so does the mobile version, the design of which is much superior to this one. Why can't you just include a simple search box above the list of links? It works great in the mobile version!

I'm not sure I understand the comparison with the mobile version. On mobile the list of languages are in a separate view. On the article you just have a button (similar to the "X more" Compact Language links provide) that leads to a separate view for the language lists. I wonder what makes you consider this transition not to be a problem on mobile and a similar one that keeps more context on desktop (not navigating away) represents a problem.

@Epiq, have you been using the search feature? I don't try to read through the list of grouped languages. When I reach a page such as w:fi:Suur-Zimbabwe, I don't usually even look at the list. I click the "32 more" button and immediately start typing the name or language code that I want. I find my target language very quickly this way.