Universal Language Selector/Design/Interlanguage links

With the current list of interlanguage 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, interlanguage 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 wiipedia, 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 interlanguage 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
We already found some issues to be improved:
 * On right-to-left languages the language panel is 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.
 * Items in the language panel should be real links. Languages present in the language panel are styled like links but they should be real links ( elements in HTML) so that users can operate them as such (e.g., open in a new tab, etc.).
 * 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.
 * '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.
 * This beta feature is incompatible with gadget SidebarTranslate.

Being fixed (work in progress)

 * Previous choices are 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.
 * Conflict with other list additions (such as Wikidata list editing and main page). Currently the way the extension manipulated the list of languages makes that Wikidata's "Edit links" link position is not kept at the bottom of the list and is moved 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).
 * Quality indicators for articles are lost. For both the initial list and the extended one, the indicators of featured and good quality articles are 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.
 * Title property should be preserved on language links. Original interlanguage 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.

Fixed

 * Not working on Commons. Wikimedia Commons (and probably other wikis) does not rely on interlanguage links to switch between languages, but use them to link to Wikipedia pages. We should either (a) make those links compact when the extension is enabled, or (b) don't expose the extension to those sites where it adds little value (feedback from different wikis will be helpful in that regard).

Suggestions for improvement
Beta features are supposed to improve over time, here are our current ideas for improvement:
 * 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).
 * 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.
 * 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.
 * Make it work across devices. When we learn that a user prefers a language, this should be taken into account for all devices.
 * Make a clear distinction between a language not available and not found in search. The "No results found" message can distinguish better between not fond 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.
 * 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).
 * 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 practise 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 have tested, users clearly identify that there are more languages than tho 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.
 * GeoIP solution rely on good information.
 * 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 espected to improve over time and we encourage users to ask for improvements on it.

Is this really needed?
It seems there is a need for a better access to your usual languages. This need can be illustrated by the following examples:
 * There are user scripts (en, de) 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 interlanguage 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 interlanguage links as a beta feature/ (and /Compact interlanguage links as a beta feature/Project progress report/)