Opinion Language Links

On May 13, the Usability Initiative changed the left navigation on the English Wikipedia as part of the new interface rollout. The goal was to reduce clutter in the left navigation. Frequently accessed links were kept exposed while infrequently used links would be collapsed by default, and then exposable upon click. Once a user exposes a set of links, they will remain exposed until the links are collapsed.

Since launching this change, there has been feedback from the Wikipedia community regarding the hiding of the Language links. Most of the feedback centers around the following two issues:

Multi-lingualism/culturalism is an important aspect of Wikipedia. When users come view article, the exposed language links let the user know that the article is available in other languages. Hiding the links gives this important aspect of Wikipedia much less visibility.
For users that go back and forth between different language versions of the same article, collapsing the languages presents a usability issue as we require users an additional click to access the different languages.

Regarding issue #2, there was a bug by which the cookie expiration date which determines the expand/collapse state of the Language links was set too short. The result is that the Language section may collapse even after a user has expanded it. This issue has been resolved, so users should no longer see this issue. Because of browser-specific bugs, this feature was broken in older versions of Opera (before 9.8) and Konqueror (before 4.0) and has been disabled in those browsers.

Regarding issue #1, the Usability Team is working on the following compromise [updated 00:22, 5 June 2010 (UTC)]:

By default, show a list of languages based on the user's most likely languages. These language(s) will probably be based on the browser's language setting. We will also have a link to "see other languages." With this type of control, we show the most likely languages while avoiding the clutter of languages that would probably not interest the user.
Change the wording of the "Language" link to be more descriptive (e.g., "See article in other languages" or "View in other languages"). The word "Languages" is probably not adequately descriptive.

Please let us know what you think of this proposal.

Howief 00:23, 5 June 2010 (UTC)

The response must have been unanimous, because User:Romaine wrote (on a different page of this wiki) on 16 June: "As of the beginning of last week, the default for inter-language links in the sidebar is to show them". No one bothered to say so here, so I've copied the information in now. Andrew Dalby 13:59, 2 September 2010 (UTC)

Update

Here are mockups of the interwiki links in collapsed and expanded state (assuming auto-detection of other languages).

Are these two options mutually exclusive? While the renaming sounds good, I am quite skeptical about the first option (choosing the « most likely languages » on behalf of the user). Exactly how would you guess which languages the user is interested in? guillom 16:51, 4 June 2010 (UTC)

No, the options are not mutually exclusive. We're looking at both. Re: the default languages, we may consider short term and long term solutions. Short term, we could base the default languages based on browser language and/or geo-coordinates where available. There are also a number of interesting ideas that have been suggested (e.g., enabling users to select a preference, taking into account the nature of the article) which are slightly more involved, but definitely worth looking into more closely. Howief 18:55, 4 June 2010 (UTC)

Until a long-term solution is agreed upon, the appropriate short-term solution is to display the interwiki links by default. It's unfortunate that this fix was reverted, let alone in the name of "usability." —David Levy 19:27, 4 June 2010 (UTC)

I regard "Languages" as sufficiently descriptive. The suggested wordings are problematic for the following reasons:

1. They incorrectly imply that all of the articles on a particular topic are direct translations of the same material. The English Wikipedia has intentionally avoided similar wording specifically to counter this misconception.

2. They overcomplicate the label for someone with little understanding of English (likely arriving at the article via a web search), for whom "languages" is the only relevant word.

3. The simple English Wikipedia is not written in another language, so it's inaccurate to refer to it in this manner. —David Levy 17:28, 4 June 2010 (UTC)

While I don't think "Languages" is sufficiently descriptive, I do share your concern that other phrases listed above may be misleading. This may be a case where we have to choose the least-bad option. I do think whatever word we use should aid understanding of the links and right now I'm not sure if it does. Howief 18:55, 4 June 2010 (UTC)

I don't believe that any description can compensate for the clarity lost by hiding the interwiki links; the readers for whom they're most useful are among the least likely to comprehend English in general.

Mark Williamson wrote an excellent analogy on the Wikimedia Foundation mailing list. In the hypothetical scenario, a reader of English reaches an article at the Georgian Wikipedia. And instead of seeing a link labeled "English," he/she must comprehend that it's hidden under the label "ენები" (Georgian for "languages"). For someone who cannot read Georgian, expanding this to the Georgian translation of "View this topic in another language" or similar would not be the least bit helpful. —David Levy 19:27, 4 June 2010 (UTC)

I don't think the way forward as suggested at the head of this page is actually a sensible option for several reasons -

I have never understood the attitude that regards the toolbox, languages, list, etc as "clutter". They do not take up any screenspace that is used for anything more useful - indeed now the search box has been marginalised to the top right, there is even less pressure on this area of the screen. Having them expanded by default but collapsible allows those who disagree with me the ability to see all the (imho wasted) blank space the vector designers seem to adore.
I don't understand why the very complicated first option is even being considered - show all languages that are available by default (which seems to be what everyone not involved in the decision to hide them in the first place wants), or show none of the languages that are available by default. Speaking personally, the languages links that I find most useful vary based on many factors, including the topic of the article concerned. For example the Dutch article on a municipality in the Netherlands is more likely to be useful to me than the Russian article, but the exact opposite is true for e.g. Russian politicians. Other important factors are not at all predictable without reading my mind.
I echo everything David Levy says above about the label "Languages". The only thing that could accurately replace it is "(This topic in) other Wikipedia editions", which is far too long and far too complicated.
It isn't just Opera for which the collapsed menus are not available - comments suggest Konqueror, PlayStation 3 and possibly others. 88.107.46.47 17:48, 4 June 2010 (UTC)

Interesting that this discussion is in English, neatly hidden away from many of the people for whom it matters most: monolingual non English speakers...

Rationale

Slightly rewording stuff on the top of this page:

Clutter on a page makes it more difficult to find useful things on the page, especially useful things you might not know about. If a person sees a giant mess of words or symbols, they'll tend to ignore or skim over most of it. We want people to know what the links are on the sidebar and actually read them, so we need to keep it relatively small.

At the same time, the fact that there are multiple language versions of articles is awesome, and it'd be a great thing to make people aware of, but if we make people aware of it by just expanding it out, you get clutter again. As it stands, it's not completely clear to an average user that expanding the "Language" bar will get them different language versions of the page. One way to give users a "hint" to this functionality is to try and "guess" a language they'd find interesting and expand out on that language and give them a 'more languages' option. Another option is to make the label more clear, and in some concise way say "if you click on this, you'll find multiple language versions of this page" as opposed to "if you click on this, we'll switch your UI to another language" or something. Nimish Gautam 18:56, 4 June 2010 (UTC)

Again, the links do not lead to "different language versions of the page." This is a common misconception that we've tried very hard to avoid reinforcing. —David Levy 19:27, 4 June 2010 (UTC)

First, there are not so much interwikis to make it intrusive in most pages (Main Page seems to be an exception, but there full interwikis are usually moved to a different page). Second, the interwiki links have a big disadvantage over other interface items which are easily customizable, since interwikis are used when fall on a foreign wiki, and use them to "go home", so you don't have any cookie set. You also need them expanded in case you are fixing interwikis or translating an article from several languages. Then you will need to expand it on every wiki. Not a big deal, but needing more clicks hurts usability. I also wonder about the change of perception of an article experienced users have depending on how many interwikis [normal, good, featured...] they see.

Some ideas I find worth from the foundation-l thread, which you should really follow: It shows the multilingual nature of wiki*edia, it raises awareness of other wikipedias, just by being shown. You can't correctly guess the right languages, which will lead to frustration, and a worse perception since it depends on too many factors, which will not be easily understood. They are useful as a translation (even if not clicked). The data may skewed due to (a) personal usability tests done with English, (b) the way the clicks were measured in the live site (clicks vs sessions, differences between languages...).

As a conclusion, we would like having more data about all of this.

Platonides 22:03, 4 June 2010 (UTC)

Without knowing exactly what data you are wanting, here is the ordered list (most to least frequent) of how often I click the various links in the sidebar on Wikipedia (other wikis differ, e.g. I almost never upload files to Wikipedia, but that is the most frequently used link on Commons):

Permanent link
Main page
Recent changes
What links here
Interwiki links
Related changes
Random article
Featured content
Cite this page

The other links I don't use often at all. However I like them there so I know what is available for when I do want to use them. Almost (but not all) design changes in the name of usability with vector have actually made it less user friendly which seems to have been sacrificed to some people's opinion of what looks prettier (I disagree but realise this is subjective). I've also lost count of the number of places where I've left feedback, almost all of which has been completely ignored, and that which hasn't has been rejected with basically "you're wrong", even when large numbers of people have the same opnion as me. 88.107.46.47 01:55, 5 June 2010 (UTC)

Interesting comment. I also feel that some of my feedback has been lost in the noise (say, on the Main Page talk here). It would be nice to develop a description of the user model that is being supported by Vector -- no skin will make everyone's life equally easy -- and to consider variants that make the use that you describe easier. (and I note that you've been devoiced again - by the lack of SUL on this wiki? - please come back and resign!) Sj 00:09, 6 June 2010 (UTC)

Foundation-l mailing list post

[reproduced below]

The Usability team discussed this issue at length this afternoon. We listened closely to the feedback and have come up with solution which we hope will work for everyone. It's not a perfect solution, but we think it's a reasonable compromise.

First, some background on the problem we're addressing and the design principle that we used. Every situation is unique, but in the case of the interwikilinks, we believe the sheer number of language links, especially within the context of an information-heavy page, makes users "numb" to the list. When people see large collections of things, they tend to group them all together as one object and not identify the individual parts that make the whole. As the number of items in the list decreases the likelihood of a person identifying the individual items increases. This is similar to how viewing a traffic jam appears as a long line of generic vehicles, while seeing just a few cars driving down the road might be comprehended in more granular detail (a motorcycle, a truck and a sports car). While we did not explicitly test for this during our usability studies (e.g., it wasn't included as a major design question), we did exercise judgement in identifying this as a problem, based partly on the applying the above design principle to the site, partly on the data.

Regarding the data behind the decision. First, let me apologize for the tardiness. The engineer who implemented the clicktracking of the left nav recently returned from vacation, so you can probably imagine how things might be a little difficult to find after being away for a while. Please see Left Nav Click Data for more details, but a quick summary is that we measured the click behavior for two groups of English Wikipedia users, Monobook and Vector (Vector users are primarily those who participated in the beta). Of Monobook and Vector users, 0.95% and 0.28% clicked on the language links (out of 126,180 and 180,873 total clicks), respectively. We felt that fewer than 1% of Monobook clicks was a reasonable threshold for hiding the Language links, especially when taken in the context of the above design principle and the implementation (state persists after expanding).

We do, however, recognize the concern that was voiced by a number of our community members. When the language links are in a collapsed state however, there is not enough information to explain what the list will be if you were to expand it. In all likelihood, we won't be able to get the verbiage to the point where it's sufficiently descriptive of the inter-language links. A list of languages is probably more effective as it *shows* the user that there are other languages available (rather than *telling* the user via a "Language", "In other languages" etc. link). However, exposing all of the languages can potentially be just as ineffectual as showing none of them.

A more effective approach would be to balance the two, by showing just enough links to clearly illustrate the meaning of the list. So our proposal is to show a list of, say, 5 languages with a "more" link. We think that a list of 5 languages should be sufficient to communicate to the user that there are other language versions available. If the language they want is not on the list, they may click "more" to see the full list.

There are numerous ways we can populate the list of 5. The simplest way is to populate based on the current order, but we can also do it based on size of the wiki, browser language, geo IP, etc. Our proposal is to go with something simple for now, and then continue to explore options for greater customization.

We hope this compromise addresses the most pressing concerns that have been raised. I will update the page on the usability wiki with the above information. Please direct discussion/feedback to that page.

Thank you for your input.

Howie, on behalf of the User Experience Team at WMF

First, some background on the problem we're addressing and the design principle that we used. Every situation is unique, but in the case of the interwikilinks, we believe the sheer number of language links, especially within the context of an information-heavy page, makes users "numb" to the list.

I regard this as an unreasonable assumption.

In my experience/observation, readers saw the links and recognized them as a list of articles in various languages. Most didn't wish to view such articles, so they paid no further attention to the list until such time as they did. (No harm done.) Meanwhile, users wishing to view articles in other languages (a small percentage, but a large number in absolute terms) knew exactly where to look.

To equate this unusual type of list with large blocks of text in general (without any data to demonstrate the principle's applicability) is to completely ignore context.

I agree with this. NB: Erik posted a nice short suggestion to the mailing list recently. --Sj
+1 --Amir E. Aharoni 08:04, 6 June 2010 (UTC)

When people see large collections of things, they tend to group them all together as one object and not identify the individual parts that make the whole. As the number of items in the list decreases the likelihood of a person identifying the individual items increases. This is similar to how viewing a traffic jam appears as a long line of generic vehicles, while seeing just a few cars driving down the road might be comprehended in more granular detail (a motorcycle, a truck and a sports car).

This analogy fails to consider a very important distinction.

Unlike the motor vehicles, one (or a small number) of the links on the list are meaningfully different from the user's perspective. To a reader of Japanese, the 日本語 link stands out in much the same way that an ice cream van would stand out in the aforementioned traffic jam. The other links, being foreign to this particular user, do not compete for attention (and therefore are less of a distraction than the random cars surrounding the ice cream van are).

+1 --Amir E. Aharoni 08:04, 6 June 2010 (UTC)

While we did not explicitly test for this during our usability studies (e.g., it wasn't included as a major design question), we did exercise judgement in identifying this as a problem, based partly on the applying the above design principle to the site, partly on the data.

Said data indicated only that the interwiki links were used relatively infrequently. Apparently, there is absolutely no data suggesting that the full list's display posed a problem. Rather, this is a hunch based upon the application of a general design principle whose relevance has not been established.

Right. And even a frequent browser of multiple projects who relies heavily on interlanguage links is likely to use other links on a page much more often. I am pleasantly surprised that 1% of all clicks were to interlanguage links -- that suggests that they are more useful to the general read than I had expected. Sj

A more effective approach would be to balance the two, by showing just enough links to clearly illustrate the meaning of the list. So our proposal is to show a list of, say, 5 languages with a "more" link. We think that a list of 5 languages should be sufficient to communicate to the user that there are other language versions available. If the language they want is not on the list, they may click "more" to see the full list.

If the language that the user seeks is not visible, why do you assume that he/she will recognize the list's nature?

Imagine seeing the following on a page full of similarly unintelligible text:

Would you recognize the first five items as languages and the last as "Show 6 more"?

Compare the above to this:

And keep in mind that the above allows for the use of Ctrl-F to find "English" on the page.

+1. Using browser's Accept-Language and Geolocation may be good for some sites, but for Wikipedia it is way, way too simplistic. Wikipedia supports many languages which common browsers don't, for example Sakha (code sah). Furthermore, a lot of people don't bother to configure their browser to support their language. In Israel, for example, many people use English Windows, even though they don't necessarily know English well. Finally, for multilingual countries such as Russia, Indonesia, Israel, China, Belgium, Spain and many others, Geolocation is a potentially offensive joke. --Amir E. Aharoni 08:04, 6 June 2010 (UTC)

If you go with an option like this, please consider using article size or the language of the article topic as factors in addition to the notoriously unreliable and incorrect geolocation. There are many of us who have enough grasp of a large number of languages to be able to interpret at least hard facts from articles in many languages (e.g. most Germanic or Latin ones). Interwiki links to the largest and likely most recently updated article on a topic without several clicks would be far more useful than links to stubs in languages that geolocation might suggest I understand./Coffeeshivers 17:43, 9 June 2010 (UTC)

There are numerous ways we can populate the list of 5. The simplest way is to populate based on the current order, but we can also do it based on size of the wiki, browser language, geo IP, etc.

Browser language and location detection are the best of the above options, but they're far from flawless. It's been explained on the mailing list that there are reasons for speakers of some languages to set their browsers to other languages. Location detection is not entirely reliable and only enables an educated guess as to the language that someone speaks.

To me, all of this comes across as a manufactured problem in search of a solution (while the initial change was a solution in search of a problem).

My thoughts exactly. --Amir E. Aharoni 08:04, 6 June 2010 (UTC)

Our proposal is to go with something simple for now, and then continue to explore options for greater customization.

Or you could simply restore the one-line code modification that provided the default behavior requested by the community (pending evidence that an alternative setup is beneficial).

—David Levy 05:30, 5 June 2010 (UTC)

Yes. Do it, please, now. It is really not my intention to offend anyone, but i really fail to understand why a questionable decision of a small group of developers is more important than the opinion of the community. Please restore the old functionality until the community agrees to change it. --08:04, 6 June 2010 (UTC)

I also find it extremely troubling that the team has interpreted interwiki link usage data from the English Wikipedia as applicable to all Wikimedia wikis (given the intention to deploy this setup across the board). I would be shocked to learn that the interwiki links don't receive substantially more use within other Wikipedias (particularly the smaller ones, whose articles often contain less information). —David Levy 19:10, 5 June 2010 (UTC)

I find it troubling that the developers felt this was a problem that needed to be fixed from the top down. As pointed out above, the vast majority of pages have only a handful of -- if any -- interwiki links. The pages with a distracting number of such links could be handled with a template which would put all of them in a box that would hide them, which could be added by users. That would be the optimal solution: the pages which users felt had too many interwiki links could be fixed by the users, & the rest would be left alone. (And if this template is applied to too many pages, then the current change would be justified.) This is a bottom-up approach, which has served all of the Wikimedia projects quite well in the past. -- 216.20.149.168 17:14, 9 June 2010 (UTC) (llywrch on en.wikipedia)

Thoughts on the usage data

"Of Monobook and Vector users, 0.95% and 0.28% clicked on the language links (out of 126,180 and 180,873 total clicks), respectively."

~~A 66% reduction in the use of one of the more unique and irreplacable elements of Wikipedia sounds like a powerful reason to return to the previous interface.~~ As David notes above, use on smaller wikis will naturally be more significant. It would be nice to see more multilingual and targeted research before making a change to the default behavior (of that earlier interface). Sj 00:01, 6 June 2010 (UTC)

To clarify, no current statistics have been released. The "0.28%" figure refers to use of Vector before the official roll-out (when the interwiki links became collapsed by default, if I'm not mistaken). The disparity is attributable to the fact that most Vector users were participants in an opt-in, English-language beta test. —David Levy 01:21, 6 June 2010 (UTC)

Thanks for the clarification. So there is no before/after data, then? It would be interesting to gather some on a small sample, whatever happens to the default for most readers. Sj 08:18, 6 June 2010 (UTC)

Does click tracking data works here at all?

They give undue weight to the people who speak only English (which are significant part of overall Wikipedia traffic). If Wikipedia is smaller (and hence is more outweighted by enwiki audience), more people use language links to get the information they want.
Many people don't actually click those links, they just look at where do they point.

Finally, does it really help? Is there any actual proof that they distract users? I believe there should be a better way of improving our sidebar than hiding things. VasilievVV 20:25, 6 June 2010 (UTC)

If I understand right, part of the reason to collapse the interlanguage links was they weren't used often in monobook. Well, I remember distinctly the time when monobook came out (2004). Before monobook, we had the interlanguage links horizontally at the very top of the page. Then monobook moved them down left, hidden unless you had a big screen or scrolled down. One of the very first things I did was devise some JS/CSS hacks for me to put the interlanguage links back to the top (meta:File:Wp-lupo-vp-screenshot.png). That's where they still are for me: the multi-linguality of the WMF projects is for me a key feature, and I never understood why the interlanguage links were moved down-left in monobook.

Now, I don't want to suggest the interlanguage links be moved back to the top again. That placement is just my personal, perhaps highly unusual, preference. However, when it comes to click counting, I very much would like to suggest that the low counts in monobook are a result of the decision made in the monobook rollout to move them to a place where they are less prominent. Hiding them even more in vector would just be a continuation of that (in my personal view, wrong) decision made back in 2004 with monobook to de-emphasize the multi-lingual nature of WMF projects.

Lupo 09:54, 7 June 2010 (UTC)

Out of all left-hand navigation links (excluding search), the interwiki-links are the ones I use most often. Generally at least looking what's available in other languages for each article. My usage of other left-navigation approaches zero. --88.130.177.138 21:09, 8 June 2010 (UTC)

I don't see any comparison with how many people click on other links at the top, left and bottom of the page. If the change was made based on a statistical ceiling, as is claimed above -- to summarize, "over 1% we would have been interested, below 1% we weren't" -- then other links must have been evaluated in the same way. Where are the statistics? Andrew Dalby 11:52, 6 July 2010 (UTC)

Since there was never any reply to this, and the version of the Vector skin that I now see on en:wiki and la:wiki does display the language links, should I take it that the idea of hiding these links has been dropped? Andrew Dalby 13:33, 2 September 2010 (UTC)

Answering myself: yes, it seems it was dropped. See my note near the top of the page. Andrew Dalby 13:59, 2 September 2010 (UTC)