Topic on Talk:Universal Language Selector

As I said to Arun at the hackathon, the execution of the design is really nicely done and professional! It does raise quite a few questions/issues, the biggest group of which can be summed up as:

What happens if the user changes the language?

As the document notes, we're dealing with the different constructs of UI language, interlanguage links to different versions of an article, different language versions of a project, and different language versions of content inside the same multilingual project (Meta, Commons). Moreover, we have an existing user interface control, the interlanguage links, that uses the label "Language" in one specific fashion now anchored in the minds of millions of users.

Any changes we make here have the potential to be highly confusing and disorienting to the user. Let me give a simple example. Let's say you're on English Wikipedia on the article about carrots, and you pick this language widget to try to find the French article about carrots. But let's say the widget does the following instead:

→ Change the user interface language to French

Now you're operating in English Wikipedia but using a French UI. WTF?! Even if that's what you actually wanted to do, due to the way MediaWiki: messages are localized, the results can be highly unpredictable. For example, compare the AbuseFilter interface on English Wikipedia in English vs. the same interface in French.

Or let's say the widget does the following instead:

→ View the French Main Page

Eek! We were looking for the French article about carrots. Oh, should have clicked the interlanguage link in the sidebar instead. WTF #2. An example of that kind of WTF in action is the implementation of interlanguage links on Commons. Here, language links inside Commons are sometimes shown at the bottom (commons:Main Page), usually at the top (commons:Commons:Village pump), and never in the sidebar. Instead, the sidebar is confusingly used for Wikipedia language versions of the page you're on. WTF #3!

Another example of brokenness in action is the language selection hack that was implemented in Commons to switch content and UI language. While a worthwhile attempt to make Commons more understandable, it nevertheless has many confusing characteristics. For example, if I visit commons:Main Page anonymously and change the language selector to German, my expectation would be ... to see the German main page. Instead I see the English Main Page with a German UI. WTF #4!?

Here are some suggested design principles I think we should aim for:

1. If I'm in a multilingual wiki (like Meta or Commons), the system should behave as much as possible like one where multiple wiki instances are used. Having a completely different language selection system in those wikis violates the principle of least surprise and is a recipe for confusion.
   • One especially tricky bit is that if I'm hopping between English and German Wikipedia, the UI language changes. If I'm hopping between an English vs. German page on Commons, it doesn't. But note, for example, that on Meta, it actually appends the &uselang parameter when clicking on the language links in the Main Page, switching the UI language. Both behaviors have the potential to be confusing.
2. If I'm in a language-specific wiki instance like English Wikipedia, changing the UI language is an edge case with unpredictable consequences. We may still want to surface it through a simple UI for edge cases where it might be helpful (e.g. view the history of an article in Arabic Wikipedia without speaking Arabic), but any accidental activation should be avoided by being absolutely unambiguous about what this feature is. If we can't implement this as an intuitive feature, I'd prefer to not implement it at all outside the existing Special:Preferences because the risk of confusing users is too great.
3. The cases of "Read this article in language FOO" vs. "Visit this project in language BAR" need to be clearly distinguished from each other. While not as confusing as the UI language change, the difference between those also can be highly confusing.
4. We have existing consensus that (some) language links should be immediately visible (expanded). These fall into the "Read this article in language FOO" category, i.e. interlanguage links. We should preserve that characteristic, even if we change the layout/appearance of interlanguage links. On the other hand, I think it's appropriate for the "Visit this project in language BAR" option to be hidden behind a selector, except for the Main Page, because ...
5. The Main Pages are usually functioning as initial language selection portals they need to most likely be special cased here as well.

With all that said, I think we need to rethink the language selector with these assumptions in mind:

• It would be simplest to add a new language control and keep the interlanguage links as they are for now.
• If we're going to simply call it "Language" and render it in addition to the interlanguage links, it may be desirable to explicitly call out the two different options: "Read this article in language .." vs. "Visit (project name) in language .."
• For hopping between monolingual wikis, the UI language option, if it is implemented in the standard selector, needs to be very clearly separated and labeled apart from everything else and likely with a lot less visibility.
• For hopping between languages in multilingual wikis, we may want to consider an "[ ] Also change my user interface language" checkbox for the choices in the language selector to avoid accidental switches as users have to often work in multiple languages (e.g. their native one and English or another more widely spoken language than their own). But I think this area requires further research and user testing.

That's some initial feedback. I think the specific controls in the proposed selectors could also be further simplified:

• The top map is too small to select and seems confusing next to the list of top languages. I'd keep those two clearly distinct: 1) a list of top languages (perhaps combined with search), 2) a list of languages relevant to the user's current location.
• Given how much stuff we're likely to stash into this, it may make sense to collapse it into a few headings by default, e.g.: 1) Read (page) in .. 2) Visit (site name) in .. 3) Type in .. 4) Change user interface to .. 5) Change font to ...

Looking forward to future iterations as this is definitely an area with a lot of potential for UI/UX improvement.

This post was posted by Peachey88 (Flood), but signed as Eloquence.

Can I just say, I totally second Erik's point here. Of the three designs already given, none seems to have clarified the link (or distinction) between interwikis and the intended operation of the selector at all. (though they are visually appealing :) ) Jarry1250 (talk) 21:24, 21 May 2012 (UTC)

Thank you for having taken the time to read through the comments, Harry. Interlanguage links are being kept out of scope for now. The main reason for this is to not make this already considerable project a whale. After initial development, we will proceed by integrating content language and interlanguage in the language selector.

The selector was designed to be capable of replacing the current interlanguage links. This is can be achieved by providing content language selection by default. See the multi-language workflow (page 2) for an example.

In the meantime, different alternatives are currently being considered for integrating interlanguage links and the ULS in a way that their functions are not confusing for users.

This post was posted by Pginer-WMF, but signed as Pginer.