Universal Language Selector/Design/Interlanguage links

With the current list of inter-language links, users have to process a long list of languages looking for their languages of interest time after time. We can make the language list shorter by including only the languages which are relevant to the user.

How it works

As multilingual content grows, inter-language links become longer on Wikipedia articles. Articles such as "Barack Obama" or "Sun" have more than 200 links, and that becomes a problem for users that often switch among several languages. The Universal Language Selector can be used in this context to:

Show only a short list of the relevant languages for the user based on geo-IP, previous choices and browser settings of the current user. The language the users are looking for will be there most of the times.
- See FAQ "How does Universal Language Selector determine which languages I may understand?".
Include a "more" option to access the rest of the languages for which the content exists with an indicator of the number of languages.
Provide a list of the rest of the languages that users can easily scan (grouped by script and region so that alphabetical ordering is possible), and search (allowing users to search a language name in another language, using ISO codes or even making typos).

Leave feedback

You can try the feature by going to the "beta" section of your preferences (most wikis will show a "beta" link on the top-right area when you are logged-in), and enable the "Compact language links" feature. You'll need to do the same process for each wiki you want to try the feature on (e.g., English Wikipedia, Japanese Wikipedia, Italian Wiktionary, etc.). Then, navigate the site as usual and repot any issues related to cross-language navigation.

Please leave feedback at the talk page. Since inter-language links are a critical element, and it is hard to anticipate the effects on all kinds of articles and users, this has been implemented as a beta feature so that users can provide early feedback based on actual use on their context. Since this feature depends heavily on the current context to select the most relevant languages (language of the wiki, language of the browser, user general location, previous choices...), it is extremely helpful to provide as much context information as you can when reporting issues with the feature.

Known issues

Master tracker: phab:T66793

We have already found some issues on which to work. See list on Phabricator.

Previous choices not remembered cross-wiki. The preferred languages for the user are only remembered in the current wiki.
This beta feature is incompatible with the SidebarTranslate gadget. (Won't be fixed ULS-side.)

Fixed

Tracked in Phabricator
Task T131233
No quality indicators are shown for languages which are collapsed.
Integrate more-languages label and ULS trigger: The '...' should be replaced by the number of more languages.
Tracked in Phabricator
Task T70075
Keyboard use should be supported. Accessing the "..." button using keyboard (tabs for moving the focus there and enter to open it) should be possible. In addition, other accessibility info may be needed to communicate that the button provide access to more languages.
Not working on Commons. Wikimedia Commons (and probably other wikis) does not rely on inter-language links to switch between languages, but use them to link to Wikipedia pages.
Tracked in Phabricator
Task T64692
Previous choices not remembered. When a language from the "more" list of languages is selected, it should become more prominent the next time by appearing on the initial list of languages. While we cannot always anticipate user languages from the beginning we should aim to at most fail once and make it easier the selection for the user next attempt.
Tracked in Phabricator
Task T64981
On right-to-left languages the language panel was misplaced. On languages such as Hebrew or Arabic, where the sidebar appears on the right, the language panel is currently displayed further on the right (becoming most of it out of the screen). The way in which the panel is positioned should be improved to take this into account. Fixed in Gerrit change 124061.
Title property should be preserved on language links. Original inter-language links had a title property which allow users to hover and get the article title information in that language. This information is currently missing on both the initial list and the "more" list of languages. Please note that this does not work on the extended language list which is in the ULS menu.
Tracked in Phabricator
Task T64376
Quality indicators for articles lost. For both the initial list and the extended one, the indicators of featured and good quality articles were not shown. Although the quality of the article is not going to make you read it in a language you don't understand, those indicators are useful to (a) find that a good article is available in one of your languages, and (b) have an overview of how well a topic is covered in other languages. Please note that the quality indicators are yet not displayed for the collapsed languages.
Conflict with other list additions (such as Wikidata list editing and main page). "Edit links" link position not stay at the bottom of the list and move to the top instead. Something similar happens at the main page, where the "complete list" link is also moved on top (in this case though, there is a functionality duplication that could be resolved by removing such link and support the functionality of exploring all languages). "Edit links" now appears below the languages.
Tracked in Phabricator
Task T70078
The "..." button should be kept pressed while the panel is open. Considering the lack of an explicit close action, that will help to communicate that you can close the panel by clicking there again (in addition to click outside the list of languages) and avoid users to spend some seconds wondering how to close it.
Items in the language panel should be real links and preserve all their attributes. Languages present in the language panel are styled like links but they should be real links (<a> elements in HTML) so that users can operate them as such (e.g., open in a new tab, etc.).
Tracked in Phabricator
Task T70076
Integrate "..." and language count label. Using a single entry point for both communicating that there are more languages and provide access to them could help to simplify the UI (example design).
Allow us to specify the languages we think are more relevant to list by default, not pre-chosen by what Wikipedia thinks is most relevant to me.
- The main criteria for language selection are previous choices. This means that by navigating to your preferred languages you are already configuring your preferences on which languages to show next time (acting as a de facto configuration process). The number of previous choices considered was increased to 9.
  Tracked in Phabricator
  Task T135487
  .

Suggestions for improvement

Beta features are supposed to improve over time, here are our current ideas for improvement:

Track success metrics. Log the number of times users switch languages (accessing the short vs. extended lists) and possible measuring time to do so. that will give a better understanding on the percentage of success in anticipating the needed languages, and may allow to compare with the default experience.
Tracked in Phabricator
Task T70071
Take into account the article size/quality. A featured/good article should be more biased to appear on the sidebar and/or the top of the list.
Make more prominent languages related to current ones. Not all articles are available in all languages. A reader that speaks a small language or which articles are not usually available may overlook those that are available if this language is not made prominent. The list of languages shown by default should probably be more "generous" than with the ULS standard to include:
- All the (main) languages of the same *family* should be shown in it.
  - We don't know what language source to use.
- Include minor languages from the user region (GeoIP), and minor languages associated to another major language related to the user (e.g., include Breton if we know French has been previously selected or is in the Browser configuration).
  - Note that even if we make wider the search for related languages, we don't want to show more language in the initial list, but we are able to show some more languages in the "Common languages" section of the language list.
Tracked in Phabricator
Task T135374
Make it work across devices. When we learn that a user prefers a language, this should be taken into account for all devices.
- It's not clear where we could store such an information.
Make a clear distinction between a language not available and not found in search. The "No results found" message can distinguish better between not found and not available. It is not clear whether the system is unable to understand which language I'm looking for (e.g., if I type "Englissssh", or the content is not available in such language). When the user searches for a valid language (e.g., "Spanish") but the content is not available in that language, we should probably indicate that "Content is not available in Spanish", and use "Language not found" to indicate that the language the user is typing does not exist.
DONE (and there will be further adjustments) Adapt the list of languages to accommodate a reduced number of languages. The design for the list of languages was made to support 300+ languages. For articles that are in the 15-30 range, a better use of space can be done by adjusting the layout (e.g., use 2 columns instead of 4 for displaying languages when the "more" list contains less than 30 languages).
- Another adjustment can be to remove the "Common languages" section when there are very few languages in addition to the ones of the initial list to avoid the number of times elements may be repeated (initial list, common languages, and the corresponding region).
DONE
Tracked in Phabricator
Task T70077
Surface languages used in content. Articles contain content in different languages (e.g., an article about a Russian city will have the name in Russian, even on the English Wikipedia). Those languages indicate a special connection between the topic and the language. This may not be a language the user understands (so this criteria should not be a priority) but it may be a good option if there are remaining slots in the initial list of languages.

Concerns from the community

When the idea was presented, some concerns were raised. Now that it is available to test in practice, it is interesting to pay attention if those occur in practice and how to fix them:

Advertising the many languages of Wikipedia is a strongly-held value of many Wikimedians. It was suggested that reordering would be more beneficial to communicate how multilingual our sites are.
- The project tries to communicate the availability of content in other languages without listing them. As far as we know -- (and we have done some testing) – users clearly do realize that there are more languages than the ones shown. the current design indicates the number of languages which makes it easier to know in how many languages a given page is available compared to counting them (would users recognise the difference in language support between a 100-language and a 200-language article just by the whole language list?).
The use of Geo-IP may be interpreted as trying to enforce certain languages in certain geographic areas, which would be contrary to the mission of the Wikimedia Foundation.
- Clutter can be an effective way to hide or obstruct the access to information. If suggestions include minor languages, this can bring more visibility to them than the usual list.
A GeoIP solution depends on information being good.
- GeoIP is not perfect, but that is not used as the main information source just as a fallback for more reliable sources such as previous selections or browser language. in any case our data relies on CLDR so it is expected to improve over time and we encourage users to ask for improvements on it.
Geo IP is useless for some people who use proxies or VPNs that go through another country e.g. for passing censorship. In some countries this is very common.
- As mentioned above, Geo-IP is only a fallback mechanism used to guess the user's language. Previous selection and browser info are more reliable.

More information

Is this really needed?

It seems there is a need for a better access to your usual languages. It is common to find Wikipedia articles with hundreds of languages that require users to scan the list to check if the languages they know are in the list for each article. This need can be illustrated by the following examples:

It was asked in r67281 (2010) as solution to a complex dilemma which caused a lot of drama.
There are user scripts (en since 2010, de since 2008) that do simple user-defined versions of this.
There is also an Opera extension.
Each wiki site has different ordering requirements – like Hebrew and Hungarian wikis want English as the first link, or 'nn' uses 'no', 'sv', 'da' before all others.
Kazakh wiki shows inter-language links for English and Russian in bold (example).

Initial prototype, usability testing, and community feedback

Prototype showing the idea.
Usability testing recordings. To see how users will switch languages.
The idea was shared on the design mailing list.

Technical information

Universal Language Selector. Extension that provides already most of the needed pieces (language selection list, cross-language search, and identification of likely languages).
Compact inter-language links as a beta feature (and Compact inter-language links as a beta feature/Project progress report)