Interlanguage links/Implementation comparison

On Wikimedia sites and apps there are a lot of different ways to switch to reading an article in another language. Here are some observations and comparisons.

Vector and Monobook: compact
See Universal Language Selector/Compact Language Links

This is the default view in Wikipedia in all the languages and in most other Wikipedia projects, and available as a beta feature in all others. It can be disabled using a preference so that all the languages are shown.

Location
In the end of the sidebar (left-hand in LTR, right-hand in RTL). In a small number of Wikimedia project it is not at the bottom of the sidebar.

Label
"In other languages". Customized in some projects as "Languages", "This page in other languages", and so on.

Appearance
Up to nine autonyms are shown initially. They are chosen by the user's previously selected languages, Babel boxes, browser language, Accept-Language, geolocation, and featured articles. If this still doesn't fill up the whole list, common world languages are added to avoid random languages with autonyms from the beginning of the alphabet appearing in the list. (The code for selecting the language for the compact list can be found at the  function in the ext.uls.compactlinks.js file, and the order is also documented in human language on the Compact Language Links page.)

A button with the label "X more" is shown at the bottom of the list, where "X" is the number of the other languages. All the available autonyms are shown in a ULS panel that opens when the user clicks the "More" button. Languages are searchable using the ULS search box. The gear icon is shown near the label - it opens ULS, which doesn't change the content language, but controls other language settings.

Are the foreign article names shown?
Target article name and the name of the target language in the user's language is shown as a tooltip on each autonym link.

Are featured article indicated?
Yes.

Pros

 * We have data that shows that people are more likely to click these links than in the non-compact list.
 * No clicking needed to see the language names.
 * The big list of languages shows Wikipedia's massive multilingualism.
 * The initial list is short and manageable.
 * The most likely languages are shown first.
 * The user's previous languages are remembered.
 * The languages are easy to search thanks to ULS's support for searching any language name in any language, especially in a very long list and for people who cannot easily type in the language that they need.
 * Geolocation doesn't add issues with privacy and performance. It's already done on every request anyway, and it's not stored.
 * We use the standard CLDR language-territory data, and we contribute to it.

Cons

 * The location of the list is low on the page and hard to find for people who are not familiar with the existence of the language list. On many screens, even with modern currently-sold desktop and laptop computers, the list is only visible if the user scrolls down. A user who doesn't know the language may leave the page without becoming aware of the existence of an article in their language without scrolling.
 * The language name is only shown as autonym. The name in the user's language may be useful, and currently it's only available as a tooltip.
 * Languages that don't appear in the initial list are hidden behind a click:
 * This makes them unsearchable with browsers' "Find in page" feature, although a surprisingly small number of people on the web actually use this browser feature.
 * This may be inconvenient for editors who want to examine or compare articles in many languages at once.
 * More conditions may be added to select the initial languages: long articles, articles in languages that are related to the article's subject, and so on.
 * The process to update CLDR language-territory data, while easy enough, is not entirely under our control. Reasonable requests sometimes take a long time to process (for example adding more languages of Russia).
 * See some more known issues on the ULS-CompactLinks Phabricator workboard.

Location
Same as with Compact Language Links.

Label
Same as with Compact Language Links.

Appearance
All the languages' autonyms are shown. They are sorted according to the wgInterwikiSortingSort value specified in the InitialiseSettings.php file in the WMF server configuration. The default is to sort alphabetically by the language code, but this is customized for many projects. The actual customizations are detailed in the InterwikiSortOrders.php file. As with Compact Language Links, the gear icon is shown near the label.

Are the foreign article names shown?
Article names and names of the languages in the language of the wiki are shown as a tooltip.

Are featured article indicated?
Featured articles are marked using an icon near the autonym. The icon itself is different in different projects.

Pros

 * No clicking needed to see the language names.
 * The big list of languages shows Wikipedia's massive multilingualism.

Cons

 * It's hard to find the needed language in the long list. Fewer people click links in such a list than in the compact list.
 * The language name is only shown as autonym. The name in the user's language may be useful, and currently it's only available as a tooltip.
 * As with the compact list, the location of the list is low on the page and hard to find.
 * It appears after all the other sidebar links, and scrolling may be needed.
 * The list can be very long. It sometimes happens that short articles have long lists.

Timeless
This experimental skin is available on all projects as a preference, but it is not default anywhere. It was developed in 2017 based on some ideas from the Winter design experiment from 2014.

It can work with both compact and classic (full) language list.

The main difference is the location of the list. This skin has two sidebars, on the left and on the right. The language list is shown as the second box on the right-hand sidebar in LTR wikis, and left-hand sidebar in RTL wikis. This makes it rather more prominent than it is with the Vector or Monobook skins.

(At the time of this writing, it shows an unnecessary scrollbar, although this is probably an easily fixable bug.)

Location
Two places: Not available at all on the main page.
 * 1) A "文A" button on the bottom sticky toolbar.
 * 2) A link in the end of the article (requires scrolling).

The language of the wiki can also be changed in the user settings.

Label

 * 1) "文A" icon on the bottom toolbar.
 * 2) "Available in X other languages" in the end of the article.

Appearance
Tapping the element replaces the view with a list of languages.

The target autonym is shown in larger black type. The name of the language in the user's language is shown below it in smaller gray type. After it, the target article name is shown.

The list is not shown immediately, but loaded after tapping.

"Your languages" are shown at the top. They appear to be chosen according to the keyboards that are enabled in the device settings (but this is TBD precisely).

The sort order for the rest of the languages is (probably) the same as on desktop: by the language code. (TBD: Need to read the code to understand: How are the languages sorted?)

The sort order is probably by the article count of the Wikipedias.

A search box at the top allows to filter the list by the autonym or by the name in the language of the wiki (but not in any other language, as in the ULS search box).

Are the foreign article names shown?
Yes.

Are featured article indicated?
No.

Pros

 * The design of the list matches iOS design visual patterns (citation needed!!!)
 * The location matches iOS design visual patterns (citation needed!!!)
 * The entry points are consistent with the Android app.
 * Using the keyboards installed on the device is a good indication of a user's interest in the language, although it's probably only possible on iOS.
 * Showing the language name in the user's language is useful for people who want to take a look at the article despite not knowing the language (in discussions about Compact Language Links many editors indicated that they are interested in this).
 * Nice search box (but see cons).

Cons

 * Not all people know that the "文A" button gives other languages. It is a common design on many websites, but it's possible that this is just a convention among web designers and that is not clear to all people. This should be tested by comparison to other approaches to letting users know that the article is available in other languages.
 * There's no way to switch to other languages from the main page.
 * The element at the end of the article may be redundant, given the presence of the element on the bottom toolbar. However, measuring its actual usage may be useful.
 * Searching can only be done in two languages. The ULS search box allows searching in any language.

Location
Two places: Not available at all on the main page.
 * 1) A "文A" button on the bottom sticky toolbar.
 * 2) A link in the end of the article (requires scrolling).

The language of the wiki can also be changed in the user settings.

Label

 * "文A" icon on the bottom toolbar.
 * "Available in X other languages" in the end of the article.

Appearance
Tapping the menu item replaces the view with a list of languages. The autonym of the language is shown in large black type. The article name is shown under it in smaller gray type.

The sort order for the rest of the languages is (probably) the same as on desktop: by the language code. (TBD: Need to read the code to understand: How are the languages sorted?)

A search box at the top allows to filter the list by the autonym or by the name in the language of the wiki (but not in any other language, as in the ULS search box).

Are the foreign article names shown?
Yes.

Are featured article indicated?
No.

Pros

 * The entry points are consistent with the iOS app.
 * Nice search box (but see cons).

Cons

 * Not all people know that the "文A" button gives other languages. It is a common design on many websites, but it's possible that this is just a convention among web designers and that is not clear to all people. This should be tested by comparison to other approaches to letting users know that the article is available in other languages.
 * The language name is only shown as autonym. The name in the user's language may be useful.
 * There's no way to switch to other languages from the main page.
 * The element at the end of the article may be redundant, given the presence of the element on the bottom toolbar. However, measuring its actual usage may be useful.
 * Searching can only be done in two languages. The ULS search box allows searching in any language.

Location
On the main page: a "Read in another language" button at the bottom of the article. Requires scrolling.

On all other pages: an element with a "文A" icon below the title at the top of the article. Not sticky, goes out of view when scrolled.

Label
"Read in another language" on the main page.

A "文A" icon elsewhere.

Appearance
Tapping the menu item replaces the whole view with a list of languages. The autonym is shown, followed by a pipe character (|) and the article name. The list is not shown immediately, but loaded after tapping.

A section of "Suggested languages" is shown at the top followed by all the other languages. (TBD: Need to read the code to understand: How are "Suggested languages" determined?)

The sort order is (probably) the same as on desktop: by the language code. (TBD: Need to read the code to understand: How are the languages sorted?)

A search box at the top allows to filter the list by the autonym or by the name in the language of the wiki (but not in any other language, as in the ULS search box).

Are the foreign article names shown?
Yes.

Are featured article indicated?
No.

Pros

 * Nice searching (but see cons).
 * The article title is a useful addition to the language name (this assumption must be tested thoroughly with real users, however).

Cons

 * Not all people know that the "文A" button gives other languages. It is a common design on many websites, but it's possible that this is just a convention among web designers and that is not clear to all people. This should be tested by comparison to other approaches to letting users know that the article is available in other languages.
 * Searching can only be done in two languages. The ULS search box allows searching in any language.
 * On the main page scrolling is needed.
 * On the main page, if the user doesn't know the language of the main page, the button is useless.
 * The "文A" button is not sticky. Scrolling hides it. (It is sticky on the apps.)
 * Easily fixable: The way in which the suggested languages are selected is unclear (although it can be found in the code).

Location
A clickable element near the middle of a persistent top bar.

Label
The current language code in serif capital Latin letters. If the code has more than two letters, it is shortened to two.

Appearance
Clicking the element shows a menu. Each item shows a language code, the English language name and the article name in smaller type. Clicking it shows the full list of languages as a sidebar on the left-hand side, with a search box at the top. This sidebar only shows the autonym and the English language name (always English; it doesn't matter in which language am I reading the article).

If two languages' codes begin with the same two letters, they are shown identically in the list, for example AS and AST are both shown as AS.

The languages appear to be sorted according to the name in English, so Albanian (SQ) is close to the beginning.

"Search languages" box works strangely. It doesn't appear to search for language names. Sometimes it finds article names, and sometimes if finds nothing at all. This may be a bug.

Are the foreign article names shown?
Only in the initial menu.

Are featured article indicated?
No.

Pros

 * Nice searching.
 * The discoverability at the top may be good (but see cons)

Cons

 * Inconsistency: Article names are only shown in the first list, but not in the full list.
 * I happen to know that EN and HE are language codes, but not all users know it.
 * Language code shortening is weird. Perhaps they are not necessary to most end users at all.