cc @alexhollender @ovasileva

[for clarity/simplicity sake I'm using the terms right and left and assuming a LTR language wiki here — the same points apply, just with right/left reversed, for RTL]

Starting with some context: this was anticipated and discussed in T263511#6579782.

This task seems to propose moving them up so that they are displayed next to the (new) language switcher. To clarify here are some mockups of what I understand @Srdjan's suggestion to be:

The indicators should be in line with the title, to the right of the new interlanguage selector.

One result of this approach would be that the language switcher is not presented in the same location on every page. Instead, the location would be variable depending on the presence of page indicators. I think it's quite important for the language switcher to be presented in the same location on all pages, so I unfortunately I don't think this approach is viable.

The next question might be: what about if we placed them on the left-side of the language switcher, so they were positioned in between the page title and the language switcher? This would result in the language switcher being in the same location on every page (✔). However due to the variable length of page titles, and the variable length of the language switcher (due to different language strings), this would get messy in many situations.

In short, the page indicators need a substantial amount of dedicated space, and shouldn't interfere or distract from more important elements such as the page title and the language switcher. That is, more or less, how I arrived at the conclusion that they should be below the heading underline:

From there we return to the awkwardness several people have pointed out. As discussed in T263511 the benefits of keeping article indicators right-aligned are:

• they appear in a consistent location regardless of the project language
• they remain at (relatively) the same visual prominence as they currently are

The obvious alternative would be to left-align them in cases where the project had no tagline. However we would then fail on the two pros listed above. For reference that would look (roughly) like this:

things get rather subjective here, but I believe that placing page indicators underneath the article title is a significant change in the visual prominence of those elements and should be discussed and/or researched before such a change is made. I also don't think that decision needs to be made as part of this work, as I don't see the awkward gap being a major issue. Another alternative would be for those wikis to add the tagline back, or some other similar element, in order to fill the space.

cc @RHo @Volker_E @Pginer-WMF

In T282027#7112359, @alexhollender wrote:

I also don't think that decision needs to be made as part of this work, as I don't see the awkward gap being a major issue.

Wikimedians are sensitive to whitespace. It will be a major issue.

In T282027#7112405, @Izno wrote:

In T282027#7112359, @alexhollender wrote:

I also don't think that decision needs to be made as part of this work, as I don't see the awkward gap being a major issue.

Wikimedians are sensitive to whitespace. It will be a major issue.

right, well hopefully it doesn't become a major issue :) I would suggest that we wait to see what kinds of complaints we hear over the upcoming months, and then focus energy accordingly. There is no simple solution here unfortunately. If it's helpful: we can explain this as a tradeoff for increased usage of language switching, which hopefully people will appreciate as a worthwhile tradeoff.

In T282027#7112359, @alexhollender wrote:

This task seems to propose moving them up so that they are displayed next to the (new) language switcher.

This place, opposite of page header text, is where indicators were so far and where they nicely suited, and where associated icons and alike also were before indicators were introduced. I'd rather wonder if new language button really needs to go into this already occupied space. I don't know what would be good place for language button, but have you considered tab bar? Something like this:

we can explain this as a tradeoff for increased usage of language switching, which hopefully people will appreciate as a worthwhile tradeoff.

As someone who translates from a variety of wikis (sometimes from languages not in the "Suggested languages" list), it takes more time to switch now compared to legacy Vector (two clicks vs a single click, and the tiny pop-up dialog with languages not listed alphabetically makes finding them more difficult if you're used to scrolling). Also given that I don't think the vast majority of readers are bi or multilingual anyway, I'm skeptical on whether it could be called a "worthwhile tradeoff". I'm not a fan of creating a regression and then "not seeing it as a major issue" or asking a wiki to re-add redundant elements like the tagline.

If the current implementation can't be changed, I think having the short description on wikis that don't use the tagline would be more useful; essentially integrating this gadget, which could look something like this:

In T282027#7114398, @Srdjan wrote:

we can explain this as a tradeoff for increased usage of language switching, which hopefully people will appreciate as a worthwhile tradeoff.

As someone who translates from a variety of wikis (sometimes from languages not in the "Suggested languages" list), it takes more time to switch now compared to legacy Vector (two clicks vs a single click, and the tiny pop-up dialog with languages not listed alphabetically makes finding them more difficult if you're used to scrolling).

When estimating the effort I think we need to estimate the action to scroll and find the list of languages. Also for classic vector there are two versions of the language list:

• The compact language list shows a short list of suggested languages which will be available as suggested languages directly after open the new selector.
• The old flat list shows al languages directly but that comes with the effort to finding the language in the middle of a potentially long list without aids for searching (unlike the language selector)

Finally, the original location at the end of a crowded sidebar requires an initial discovery effort too, which may result on not serving the needs of users that need to switch the language because they don't expect the functionality there.

If the current implementation can't be changed, I think having the short description on wikis that don't use the tagline would be more useful; essentially integrating this gadget, which could look something like this:

Integrating the short description seems an idea worth exploring. On mobile (web and apps) this is displayed around the title area, so it would be consistent. One consideration is that not al the topics have such info available, so a fallback may be needed (option to contributing it, leaving it blank, or something else...).

Just wanted to pitch in with some of the data we've collected so far on the button itself. The new language button has so far been tested qualitatively across a number of different tests - details are available at https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Features/Language_switching#User_testing. So far, the button has been received positively in our prototype testing with editors, as well as a separate user test with reader. We also tested the time required to find the new button versus the old option and saw that the new button was up to 4x quicker to find than the previous version that required scrolling down the page - results are available here. https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Repository/Language_Switching_User_Tests#Test_results.

That said, since this is a big change, there's a few more checks coming up from our side. Mainly, we will begin quantitative testing on a set of pilot wikis that will compare the usage of the old vs new version (details available in T269093: Deploy new language switching location to test wikis and begin A/B test pt 1). Also, for people that switch languages fairly frequently (for translations for example), we are considering adding direct links to their most used languages. These are still early ideas, but there are more details as well as a mockup available here: https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Features#Language_switching_2:_One-click_access_to_preferred_languages

One consideration is that not al the topics have such info available, so a fallback may be needed (option to contributing it, leaving it blank, or something else...).

Here's how that gadget handles it currently:

If it's empty:

If it exists:

That seems like a decent idea, though obviously the UI would need to be tweaked.

If Wikidata descriptions are to be integrated, it's quite important to be able to add and edit them directly on Wikipedia.

In T282027#7114398, @Srdjan wrote:
Also given that I don't think the vast majority of readers are bi or multilingual anyway, I'm skeptical on whether it could be called a "worthwhile tradeoff".

According to this 2013 academic study published in Trends of Cognitive Science more than half the world's population is bilingual.

It is generally believed that more than half of the world’s population is bilingual [1]. In each of the U.S. [2] and Canada [3], approximately 20% of the population speaks a language at home other than English. These figures are higher in urban areas, rising to about 60% in Los Angeles [4] and 50% in Toronto [3]. In Europe, bilingualism is even more prevalent: In a recent survey, 56% of the population across all European Union countries reported being functionally bilingual, with some countries recording particularly high rates, such as Luxembourg at 99% [5]. Bilinguals, therefore, make up a significant portion of the population. Importantly, accumulating research shows that the development, efficiency, and decline of crucial cognitive abilities are different for bilinguals than for monolinguals. What are these cognitive differences and how does bilingualism lead to these changes?

This 2019 article in the Washington Post suggests the same.

This 2019 report compiled by Eurostat shows similar numbers.

While we don't have data on how many Wikipedia readers are bi, or multi, lingual, we have made a general commitment towards knowledge equity and inclusion (link). I think it is important to keep this commitment in mind as we discuss the tradeoffs here. My interpretation of that commitment as it relates to this discussion is: I think it's important that we welcome any/all newcomers (and existing community members) with a clear and easy way for them to find the language they prefer.

We all are faced with difficult decisions and tradeoffs when updating the interface. Every element is important, but my belief is that some elements/functions are more important than others. If the data we collect in the future (as Olga alluded to here T282027#7118749) continues to show that people are able to discover language switching more easily, and switch languages faster, I firmly believe that added value is greater than the drawback of having some awkward whitespace below the article title. I recognize that this might come across as harsh, or somehow flippant, as you said:

I'm not a fan of creating a regression and then "not seeing it as a major issue" or asking a wiki to re-add redundant elements like the tagline.

I would ask you to assume good faith here, and either trust (or read our research to verify) that we are not taking these decisions lightly. We are similarly bothered by awkward whitespace, but again some elements/functions outweigh others in terms of value and importance to the people using the website.

In T282027#7118749, @ovasileva wrote:

We also tested the time required to find the new button versus the old option and saw that the new button was up to 4x quicker to find than the previous version that required scrolling down the page - results are available here.

This metric is essentially meaningless. Of course the previous version takes longer to find, you’ve basically outlined yourself why: it is further down the page, so it would take longer no matter what the other design would be. Any design making the list higher would win in such a comparison. It is not a fair test and it cannot be used to prove or conclude anything. (A fairer version would’ve been the one where old language list in sidebar was visible in the first screen in both tested versions.)

The line break and white space is even more evident where other items where added below the absent tagline. Look at http://eu.wikipedia.org/wiki/Lehen_Mundu_Gerra to get an example of how white space is a problem.

This can be solved with the solution given at de.wikivoyage. I don't know exactly how they have moved the indicators to the title section, but the best solution is that. If anyone knows how to do it, we could try to show coordinates and indicators correctly at the Basque Wikipedia.

Adding a float: right to the indicators section would work to remove that white space in an acceptable way? AFAIK that way it wouldn't generate that space and it would only move the infobox down instead of the whole content.

No, the problem is that the indicators where moved below the title line. This is the current mess with "float:right" added to mw.indicators.

Oh, yeah, now I see the problem. That happens because indicators are part of the header even if they look like they are part of the content instead. Clearly making them float at the end of the header wouldn't change anything.

To work the way I expected indicators must be located on top of #bodyContent instead of at the end of inside .mw-body-header, and the coordinates should be added as an indicator. Otherwise the result would have too much white space or overlapping coordinates.

Modifying the HTML the way I described above it would be something like this, which I think looks way better than the current state of the page:

But that is not the way to show it. They should go over the title line, just to the left of the language switcher, as it was previously. I have opened a ticket here: T292617

For a relevant picture, this is how we see now at English Wikipedia

And this is what happens without the legacy vector

The position of the indicators have been moved, but in the mock-up this wasn't intended.

@Theklan - The indicators were moved on purpose to make sure they're not overlapping with the language button. Having space around the language button is important to draw attention to the functionality. Also, in the future, we are planning on using that space to create buttons directly to people's most common languages, as a way of shortening the amount of time it takes to switch language. This however, introduced some inconsistencies with other wikis. The projects that had a tagline "From Wikipedia, the free encyclopedia" are okay, but the ones that do not have the white space that this task was created to discuss.

When we take a design decission we must think on what was in that spot before. If we move the language switcher to the place were the indicators where (and indicators are pretty common), even with the tagline enabled (I did it now in Basque wikipedia to show it) and even without the language quality asessment (that is something unique at two Wikipedias, but may be common in the future) the design is inconsistent:

There is too much space below the items, they are unbalanced and not in line.

When we add the coordinates, that happen to be a significant part of any given Wikipedia, the problem is more evident:

This design faults can be reverted site by site, but this will cause communities to have lots of hours spent dealing with a problem they had previously figured out and solved and now can't be easily undone. Furthermore, most of the Wikimedia communities don't have a css/js editor permission administrator, so the burden of changing that will fall to volunteers at Meta.

As we haven't seen what is the idea for the future, but this issue was open 5 months ago, let's take this as a bug that must be solved before we wait to that "future" that will or won't come some day.

In T282027#7406120, @Theklan wrote:

But that is not the way to show it. They should go over the title line, just to the left of the language switcher, as it was previously. I have opened a ticket here: T292617

I understand that they're not in the same position as they were previously, and I also understand that they won't go back to the title line because developers want to use that space for languages. I just suggested a different design to fix the problem (too much space between the title and the content of the article) without reverting the changes related to the new position of the language selector.