Page MenuHomePhabricator

Easier language switching from Main page
Open, HighPublic

Assigned To
Authored By
alexhollender_WMF
Oct 15 2021, 1:59 PM
Referenced Files
F36325474: Screen Shot 2023-01-19 at 8.30.57 AM.png
Thu, Jan 19, 12:32 PM
F35060831: Screen Shot 2022-04-20 at 7.27.34 PM.png
Apr 21 2022, 2:27 AM
F35060815: Screen Shot 2022-04-20 at 7.05.38 PM.png
Apr 21 2022, 2:26 AM
F35060562: Screen Shot 2022-04-20 at 4.30.26 PM.png
Apr 20 2022, 8:35 PM
F35060565: Screen Shot 2022-04-20 at 4.31.17 PM.png
Apr 20 2022, 8:35 PM
F35058546: Screen Shot 2022-04-19 at 11.03.37 AM.png
Apr 19 2022, 6:05 PM
F34954695: Screen Shot 2022-02-17 at 7.39.10 PM.png
Feb 17 2022, 6:45 PM
Tokens
"Love" token, awarded by Jdlrobson.

Description

Description

Earlier in the desktop improvements project we moved the language switcher from the sidebar to the top of the page (next to the article title), so that it is more discoverable (T260738). This presented a problem for Main pages because they do not have a page title element, so there was no clear place to put the language switcher. In T276140 we put it at the bottom of the Main page so it would at least be somewhere, and we started to explore ideas for how to find a better location for it on the Main page. This task is for continuing that conversation, and finding a better solution to make it easier to switch languages from the Main page.

Ideas

Add title to Main page (which includes the language switcher)

One idea to try is adding a title to the Main page, which includes the language switcher beside it. The main benefit to this solution is that the language switcher will be consistent between the Main page and all article pages. Currently the Main page doesn't have a title, so it would take some time and discussion to figure out what an appropriate title for the page could be. And a good option for one project might not work for others.

Logged-outLogged-in
image.png (1×2 px, 1 MB)
image.png (1×2 px, 1 MB)
Create language switcher templates for main page

Another idea is to create some template (or templates) for the Main page that communities can choose to add as they like. Some communities already have language templates on their Main pages, so for them it could be about moving those templates closer to the top. For other projects they would have to add them entirely. Here are some examples:

image.png (480×1 px, 206 KB)
image.png (458×1 px, 177 KB)
image.png (527×1 px, 121 KB)

for reference, here are some of the existing language templates on Main pages:

Acceptance Criteria

  • Add a feature flag that allows us to put the language button at the top in the main page and that allows editors to change the page title message.
  • Default configuration for title:
  • Logged-out: "Welcome to [project name]"
  • Logged-in: "Welcome [user name]"
  • Ensure feature flag is visible via a query string parameter like our other feature flags
  • Create new task for follow-up (steps outlined below)

Follow-up for euwiki

  1. Restrict eu.wikipedia.org styles on the main page to pages without the feature flag.
  2. Test on https://eu.wikipedia.org/w/index.php?title=Azala&oldid=8746129&languageinmainpageheader=1
  3. Enable the config flag and apply the revision.

Developer Notes

  • @Jdlrobson wrote a POC patch for customizing the main page title. This data can be made available in core and output to the base mustache template for all skins to access.
  • For internationalization and logged in/out users, we'll need 2 message keys: mainpage-title-logged-in and mainpage-title-logged-out - both of which can be customized by editors at will.
  • The feature flag that renders the custom/default main page title AND places the language button at the top of the main page is presumably scoped to Vector and should be straightforward to add with a query parameter as well using the OverridableConfigRequirement class.
  • The relevant templates can check for the feature flag to display the main page title + language button accordingly.

QA Steps

Please perform the following steps for both logged in and anonymous users. Note, when testing on the beta cluster we are looking for the presence of this button:

Screen Shot 2022-01-05 at 1.35.49 PM.png (118×364 px, 7 KB)

Please ignore this button:

Screen Shot 2022-01-05 at 1.36.08 PM.png (140×930 px, 9 KB)

When at default

  1. Visit https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page
  2. Verify that the language list is absent in the sidebar and the new language button is at the TOP of the content.
  3. Verify the new language button is not at the bottom of the content.

When languageinheader is disabled and languageinmainpageheader is enabled

  1. Visit https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page?languageinheader=0&languageinmainpageheader=1
  2. Verify that the language list is present in the sidebar and the new language button is not at the bottom of the content and not at the top of the content

When languageinheader is enabled and languageinmainpageheader is at its default (enabled)

  1. Visit https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page?languageinheader=1
  2. Verify that the language list is absent in the sidebar and the new language button is at the top of the content.
  3. Verify the new language button is NOT at the bottom of the content

When languageinheader is enabled and languageinmainpageheader is enabled

  1. Visit https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page?languageinheader=1&languageinmainpageheader=1
  2. Verify that the language list is absent in the sidebar and the new language button is at the top of the content.
  3. Verify the new language button is not at the bottom of the content

When languageinheader is enabled and languageinmainpageheader is disabled and visiting content

  1. Visit https://en.wikipedia.beta.wmflabs.org/wiki/Dog?languageinheader=1&languageinmainpageheader=0
  2. Verify that the language list is absent in the sidebar and the new language button is at the top of the content.
  3. Verify the new language button is not at the bottom of the content

QA Results - Beta

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Jdlrobson updated the task description. (Show Details)
Jdlrobson removed the point value for this task.

@Edtadros I've amended the QA steps which was wrong.

AC2:

The URL used in the screenshot for the anon test is incorrect.

❌ AC2: When languageinheader is disabled and languageinmainpageheader is enabled
There is a change language button at the bottom, I am assuming that considered the "new language button"

I don’t think so, that button is user-generated content. On the below screenshot from https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page?languageinheader=1&languageinmainpageheader=0 I put a cross on the wrong button and circled the right one with green; I also gave a gray background to the user-generated content area:

Screenshot 2022-01-05 at 20-24-42 Wikipedia, the free encyclopedia.png (213×653 px, 11 KB)

I don’t think so, that button is user-generated content. On the below screenshot from https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page?languageinheader=1&languageinmainpageheader=0 I put a cross on the wrong button and circled the right one with green; I also gave a gray background to the user-generated content area:

Screenshot 2022-01-05 at 20-24-42 Wikipedia, the free encyclopedia.png (213×653 px, 11 KB)

I've clarified the description to avoid confusion. We are not testing the "change language" button.

❌ AC2: When languageinheader is disabled and languageinmainpageheader is enabled

  1. Visit https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page?languageinheader=0&languageinmainpageheader=1
  2. Verify that the language list is present in the sidebar and the new language button is not at the bottom of the content and not at the top of the content

There is a change language button at the bottom, I am assuming that considered the "new language button"

Logged InAnon
Screen Shot 2022-01-04 at 5.30.16 AM.png (2×1 px, 1 MB)
Screen Shot 2022-01-04 at 5.39.08 AM.png (1×972 px, 530 KB)

The URL in the address bar of the 2nd screenshot is wrong. It doesn't match the first.

As a heads up, there is discussion taking place at English Wikipedia on removing the portal links from the top of the Main Page, which would open up a convenient place to put the language switcher, perhaps like this:

Concept of Wikipedia Main Page with no portals and language link.png (480×1 px, 202 KB)

@Sdkb I think there's a big benefit to having the language switcher in the same place on the main page as it is on article pages. I'm curious what you think about adding a page title + language switcher to the main page, like first two images in the task description? In case you haven't already seen it, this is already implemented on Basque Wikipedia's main page.

While I am not @Sdkb, I do want to reiterate that this is complete non-starter from multiple different points. Among them:
a) most wikis hide the heading for a reason—because it does not fit into the existing designs, which you as a designer should understand;
b) therefore, this suggestion requires all wikis to work around Vector 2022 in their main page designs since other skins do not require this, which in many cases can and will be a lot of work (what is your suggestion for ru.wikipedia.org, for example? nevermind the fact that the design looks worse with enforced max-width);
c) there are projects where <h1> is now appropriately set on the page itself, which would need hacks around for new Vector if you enforce the page title on it;
d) there are some multilingual projects that use page structure like Main Page/de for their main page localisation and do not use Extension:Translate, and page title will be bad to show on those projects.

These are simply issues that I can come up with in 10 minutes. I suggest completely dropping the idea of enforcing the page title on any main page. While enWP can probably be fine with this since their design is old and ugly, and euWP can be fine with this because their design does not use a defined header, there are many more projects that this would not work for, and a generalised solution cannot be ‘show page title that you have hidden for the last 21 years’.

I suggest completely dropping the idea of enforcing the page title on any main page.

From a development POV, I'm advising projects not to do that. Wikis that currently do this are outputting 2 h1s to the page which is not great from an SEO or accessibility standpoint.

Instead, edit MediaWiki:Mainpage-title to generate the title you want and update your main page template to incorporate it into the design. Raise bugs for any difficulties you hit.

a) most wikis hide the heading for a reason—because it does not fit into the existing designs, which you as a designer should understand;

English Wikipedia hides the headline but also introduces its own headline "Welcome to Wikipedia".

It doesn't take much imagination to think how these could be reconciled with some main page targetted CSS styles:

Screen Shot 2022-02-16 at 11.58.33 AM.png (1×2 px, 737 KB)

b) therefore, this suggestion requires all wikis to work around Vector 2022 in their main page designs since other skins do not require this, which in many cases can and will be a lot of work (what is your suggestion for ru.wikipedia.org, for example?

Russian Wikipedia has the heading "Добро пожаловать в Википедию,"
Same applies as for English Wikipedia.

Screen Shot 2022-02-16 at 12.01.54 PM.png (694×2 px, 305 KB)

Here's some CSS to get you started:

.main-top .mw-headline { display: none; }
main header .firstHeading { border: none; margin-bottom: 0; }
.mw-parser-output .main-top { border-top: 0; margin-top: 0;}
main header {
  background-image: url("https://upload.wikimedia.org/wikipedia/commons/e/e3/Wikipedia_logo_letters_banner.svg");
   border: 1px solid #c8ccd1;
margin-bottom: 0;
  background-color: #f8f9fa;
  border-bottom: 0;
  padding-left: 1.5rem;
}

Screen Shot 2022-02-16 at 12.15.52 PM.png (622×2 px, 286 KB)

From a development POV, I'm advising projects not to do that. Wikis that currently do this are outputting 2 h1s to the page which is not great from an SEO or accessibility standpoint.

Not sure about SEO, but headings that are completely hidden, like you have recently done a change for, do not get into accessibility tree unless referenced by other elements (such as aria-labelledby). So there is no accessibility problem here, only if there is no <h1> at all when hiding it. I am pretty sure I already described this in T300695 before.

It doesn't take much imagination to think how these could be reconciled with some main page targetted CSS styles:

I am not sure you can provide examples that do not completely alter first screen layout in some or even most wikis. And even then, wikis would have to make changes to account for language switcher button in new Vector because usually all main pages pretty heavily on multi-column layout. (Which is why, accidentally, they should not have their width constrained.)

Russian Wikipedia has the heading "Добро пожаловать в Википедию,"

So, let’s look at your images/CSS.

  1. CSS does not work on the existing layout unless you would provide some way to put first heading into a random place on the wiki page.
  2. Provided (1) is done, in the example you are showing the language switcher button does not work in that placement unless you heavily change the header layout to account for it. Currently it is a two-column flexbox layout that includes the heading, whereas you propose a heading outside it. Tagline under the heading (‘free encyclopedia that anyone can edit’) looks frankly bad in your mockup, and the header gets additional height from having the language switcher button in a random place.
  3. Language switcher also messes up the layout here in another way because the logical text (‘Currently Wikipedia has X articles’) has to be moved down by the language switcher button because it is located in imaginary #firstHeading.
  4. All of this already demonstrates a lot of inflexibility forced by the wrong decision to explore the language switcher button, and shows why I suggested dropping the idea of forcing the page title on the main page.

This is what I mean by ‘main page authors will be required to hack around new Vector because it requires page header and language switcher’. I must admit that your proposal is not the worst thing you could have shown, but it is still miles away from something workable, and is probably even more unworkable for projects that have a more prominent header (such as nlWP). And I am not sure something workable is even possible here without a lot of hacks and redesigns to support one skin.

In case you haven't already seen it, this is already implemented on Basque Wikipedia's main page.

As I commented before, there are some problems with this approach:
1- You can't convince 322 individual wikipedias and other 800+ projects one by one of the benefit of the proposal.
2- Without an optimal main page proposal, there's no approach.
3- This "solution" was implemented because we insisted and insisted and it was even said that we were pushing something that was out of scope. The proposal for the Basque Wikipedia is not a solution, but a patch.
4- currently, the most logical solution is the one proposed at Basque Wikipedia. But that is far away for being the best one. Trying to solve one by one all the projects will lead to the same discussion about the best solution again and again, but that's out of the scope of this patching process.

Verifying in production
QA:
When at default
Visit https://eu.wikipedia.org/wiki/Azala
Verify that the language list is absent in the sidebar and the new language button is at the TOP of the content.
Verify the new language button is not at the bottom of the content.

Screen Shot 2022-02-17 at 7.39.10 PM.png (835×1 px, 568 KB)

When languageinheader is disabled and languageinmainpageheader is enabled
Visit https://en.wikipedia.org/wiki/Main_Page?languageinheader=0&languageinmainpageheader=1
Verify that the language list is present in the sidebar and the new language button is not at the bottom of the content and not at the top of the content

Screen Shot 2022-02-17 at 7.40.36 PM.png (1×475 px, 177 KB)

As I commented before, there are some problems with this approach:

@stjn @Theklan thanks for the notes. In my view it's a question of whether we currently have a better approach/solution here. I do not think we do currently. The two other solutions seem to be:

  • redesign & rebuild the Main page on every wiki
  • create custom language switcher elements and find custom locations for them on every wiki's main page

There are of course downsides to any approach, and using the page title certainly has downsides. The massive upside, which nobody seems to be discussing, is the consistency between language switching on the Main page and language switching on Article pages. I believe this is the single most important criteria for a solution here.

Anyways, until someone comes up with a better approach I will keep advocating for this solution.

@alexhollender_WMF
As we are again in the same point, and we had some frictions in the past because of this, I will try to summarize again my point of view of the best practice here:

  • The WMF should propose an ideal front page, as an opt-in, that should be scalable, modular, modern-looking and oriented to our 2030 strategy
  • The main page is the most visited page in any given wiki, so the design should focus on our vision: "Wikimedia will become the essential infrastructure of the ecosystem of free knowledge"
  • English Wikipedia, and a limited of bunch of others, have their own developers, designers and tech-oriented people. All the other Wikipedias and all the other Wikimedia projects lack this people. So, proposing something easy should be a basic.
  • All the main pages have been done by the community but this is not something mandatory. We have done it in that way, we have used legacy items from elsewhere, but this is because there wasn't any proposal. An opt-in proposal will beat most of the front pages.
  • Finally, as the main page should be modular, there may be a module hosting the language switcher. This could be used by languages that are not willing to opt-in but want the interlanguage link in some specific place.

Thanks

@Theklan yes, I understand your position and your proposal. And I agree we should be careful and avoid additional tensions here since it's not helpful.

I agree with your proposal. We also need a solution here in the meantime, since we do not have the resources to re-do the main page right now.

since we do not have the resources to re-do the main page right now.

Well, I disagree. We have the resources. What we lack is ambition and management. But we have plenty of resources to do this.

Now let's point it in another way:

  • How much would it cost, in terms of hours of dedication, to convince each of the 800+ projects to adopt a <h1> title approach for their main pages?
  • How much would it cost, in terms of hours of dedication, to build a main page proposal?

Because we can certainly have a recource-management problem, but both approaches need time and resources.

  • How much would it cost, in terms of hours of dedication, to convince each of the 800+ projects to adopt a <h1> title approach for their main pages?
  • How much would it cost, in terms of hours of dedication, to build a main page proposal?

Right, both approaches need time and resources. I think a more fair comparison is:

  • Ask 800+ projects to adopt <h1> title approach for main page, help them implement if needed
  • Research main page use, design several new main page designs, prototype and test several main page designs, test whether having a different language switching experience on the main page vs. article pages leads to an increase or decrease in language switching, ask 800+ projects to adopt new main page design, help them implement if needed

To me the first option seems like less work...maybe I'm wrong about that though.

No, that's not the calculation. You don't need to convince 800+ projects to adopt the new main page design. You propose it and they can implement it if needed. Now the solution is not giving anything and pushing them, one by one, for a patch (not a solution or a best practice).

At the end of the day, we need a proposal for the main page. I know that there are no plans to do that. but the burden of convincing 800+ projects of adopting something that we know is not what we need will take much time for something that won't solve the problem.

So, let's calculate the time needed for the research, design, prototype and implementation. We have plenty of money, and I'm sure that there are developers who would be happy to work on this.

@Theklan I think it's awesome that you are so passionate about improving the main page for Wikipedia. I've created a new task for that here: T303551. Please feel free to start filling out the description, goals, and any other thoughts and ideas you have.

The scope of this task is to make language switching on the Main page easier, and more consistent with article pages. Your solution, redesign the Main page, is unfortunately out of scope for the Desktop Improvements (Vector 2022) project, as I've mentioned several times. I realize this is upsetting to you and again, I apologize. Thanks in advance for your understanding.

And again, even though you think using the <h1> on the Main page is a bad solution, I think it's really awesome that you have tried it out on your wiki 🙏. I hope we can collect some data to see the impact on language switching there.

@alexhollender_WMF Merged the proposal at T293405.

If it is out of scope, then there's nothing to discuss. No one is going to do it, volunteers can't do it, the foundation is not going to implement it.

By the way, I'm not talking about Wikipedia. I'm talking about Wikimedia projects.

Krinkle added a subscriber: Krinkle.

New feature does not appear to be a release blocker.

English Wikipedia has just approved placing the language switcher button near the upper right corner of the Main Page (at the right end of the top banner, as depicted in the prototype image) as part of a suite of changes to reduce the prominence of portals. Would you all be able to handle the technical end of development to make this possible?

Hi @Sdkb I can certainly help with the configuration change. I guess the question is how to coordinate?

There are two options

  1. I do the configuration ASAP and then the homepage is edited after

Screen Shot 2022-04-19 at 11.03.37 AM.png (1×2 px, 802 KB)

  1. You make the homepage edits first and we do the configuration change after. You can test what it will look like using https://en.wikipedia.org/wiki/Main_Page?languageinmainpageheader=1 but whenever your changes are complete, the language button would still be at the button, potentially leaving a small space where the language button should be
  1. We coordinate and do the changes at the same time. We'd have to find a deployment window that we can both make: wikitech.wikimedia.org/wiki/Deployments

What option would you prefer?

@Jdlrobson, per the prototype image that I referred you to, and that I'm attaching below for good measure, the approval is for the language switcher button within the Main Page top banner. There is no approval for placing it above the banner, as in your options above; that would require us to run a brand new RfC, which I predict would fail.

Concept_of_Wikipedia_Main_Page_with_no_portals_and_language_link.png (480×1 px, 202 KB)

My understanding was that the language button would be allocated to the new position like so:

body.skin-vector .mw-body {
  position: relative;
}

body.skin-vector #p-lang-btn {
    position: absolute;
  top: 50px;
  right: 8px;
}

Moving the language to the top of the page, might help with this, given it would change the HTML position.
Is this not the plan? If not, what else did you have in mind?

Which I am fairly certain would necessitate turning the main page title line on. Is that correct? That would be the no-go part of the discussion.

I believe Sdkb was expecting for the development that was discussed in the description of the task ("Create language switcher templates for main page") earlier in this task regarding an in-wikitext selector being available. Has WMF decided not to take that alternative?

Which I am fairly certain would necessitate turning the main page title line on. Is that correct? That would be the no-go part of the discussion.

It depends what you mean by turning the main page title line on. AS https://en.wikipedia.org/wiki/Main_Page?languageinmainpageheader=1 demonstrates, yes it would add the element header.mw-body-header but the title itself would be hidden because English Wikipedia is blanking the title. You would be free to style this HTML however you pleased.

I believe Sdkb was expecting for the development that was discussed in the description of the task ("Create language switcher templates for main page") earlier in this task regarding an in-wikitext selector being available. Has WMF decided not to take that alternative?

You can add the HTML <a class="mw-interlanguage-selector" href="#mp-lang">Read in another language</a> to your template and that will be automatically enhanced by the UniversalLanguageSelector. I presume that any of those templates in the description could be made using this technique, but I haven't explored it myself so I'd be interested to know if that's not the case. None of these templates exist at time of writing to my knowledge.

You can add the HTML <a class="mw-interlanguage-selector" href="#mp-lang">Read in another language</a> to your template and that will be automatically enhanced by the UniversalLanguageSelector. I presume that any of those templates in the description could be made using this technique, but I haven't explored it myself so I'd be interested to know if that's not the case. None of these templates exist at time of writing to my knowledge.

It’s not the case: wikitext doesn’t allow setting arbitrary attributes on <a> elements. It’s possible to create for example <a href="#mp-lang">Read in another language</a> (without the class) or <a href="#mp-lang"><span class="mw-interlanguage-selector">Read in another language</span></a> (the class being on a child <span>), but not the exact markup you wrote.

@Tacsipacsi yeh that would work too. The class just needs to be present, doesn't matter if it's on the link or not. Check out https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Template:LanguageButton for example (shown on bottom of https://en.wikipedia.beta.wmflabs.org/)

in case this clarification is helpful, there are two different proposals:

Proposal 1
turning on the heading on the main page and including the language switcher to the side of it (this is preferred because it matches the location on article pages)

Screen Shot 2022-04-20 at 4.30.26 PM.png (256×1 px, 92 KB)

Proposal 2
adding the language switcher to the top-right within the content area of the main page (which is still good because it's pretty close to the location on article pages)

Screen Shot 2022-04-20 at 4.31.17 PM.png (272×1 px, 67 KB)

my understanding is that proposal 1 is more complex because it would involve additional community discussion. therefore we are deciding to move ahead with proposal 2 right now.

for whatever it's worth, I do hope that we can eventually consider proposal 1. as I've mentioned in the past I think it would further benefit people using the site if they can find the language switcher always in the same place, regardless of if they are on the main page or an article page.

Where is there a functioning example of version 2, and how does it serve users without JavaScript enabled?

@Tacsipacsi yeh that would work too. The class just needs to be present, doesn't matter if it's on the link or not. Check out https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Template:LanguageButton for example (shown on bottom of https://en.wikipedia.beta.wmflabs.org/)

It doesn’t work for me—there’s no event handler attached, so nothing happens when I click it. (Except that if I click the <a> within the <div>, the default browser behavior of jumping to the anchor does happen.) I see nothing suspicious on the browser console (Firefox 91.8.0esr on Debian 10, although this shouldn’t matter).

Where is there a functioning example of version 2, and how does it serve users without JavaScript enabled?
doesn’t work for me—there’s no event handler attached, so nothing happens when I click it.

Presumably you have this preference disabled:

Screen Shot 2022-04-20 at 7.05.38 PM.png (268×1 px, 39 KB)

If so, then yes this is how the fallback would work. The fallback is jumping to the hash fragment if the URL is not set. We could easily add support for :active state to expand the dropdown if this is a blocker. The amount of users this impacts is pretty low from what I've previous seen, but we could re-run the numbers to be sure.

The problem we have here is the language button is part of the skin not the content area. If you want to use the native language button we display, then you will need to move the language button to the top of the page and incorporate the header into the design by styling which is what I was imagining you would be doing.

Here's a simulation of how that would happen demonstrated via JavaScript with inline comments of how you would do that in a non-hacky way:

$('#firstHeading').show().text('Welcome to Wikipedia'); // edit https://en.wikipedia.org/wiki/MediaWiki:Mainpage-title-loggedin and https://en.wikipedia.org/wiki/MediaWiki:Mainpage-title

// These styles would be shipped by template styles not JavaScript. The body class is needed to get around scoping challenges.
mw.util.addCSS(`
body.page-Main_Page .mw-body-header {
     box-sizing: border-box;
    border-color: #ddd;
    background-color: #f9f9f9;
    text-align: center;
    padding: 0.1em;
   border-width: 1px;
  border-style: solid;
   background-color: #f9f9f9;
   border-bottom: 0;
} 

body.page-Main_Page .mw-body-header h1 {
    border-bottom: none;
}

#mp-topbanner {
    border-top: none;
}

#mp-welcome { display: none; } /* or remove from template */
`)

That's not a complete solution but it gets you most of the way there and will work across all skins.

Edit: As pointed out currently TemplateStyles does not permit styling of elements outside the content on main page. For now in the short term these would need to be done in Common.css or a gadget and on long term we'd add support to TemplateStyles to allow more control of main page styling.

Screen Shot 2022-04-20 at 7.27.34 PM.png (720×2 px, 556 KB)

Where is there a functioning example of version 2, and how does it serve users without JavaScript enabled?
doesn’t work for me—there’s no event handler attached, so nothing happens when I click it.

Presumably you have this preference disabled:

Screen Shot 2022-04-20 at 7.05.38 PM.png (268×1 px, 39 KB)

I was sure I mentioned it, but I seem to have removed this information when I rephrased my comment for the n’th time: I was logged out. I have an account on beta cluster, but I’m just too lazy to try to remember its password… This means that all preferences should be at their defaults. I assumed compact language links are on by default everywhere on Wikimedia wikis, including beta cluster, but now I clicked on the language selector provided by the skin, and I got the non-ULS list indeed. Do you know why is this preference off on beta English Wikipedia, and whether it still needs to be off?

If so, then yes this is how the fallback would work. The fallback is jumping to the hash fragment if the URL is not set.

But this works only on new Vector, not e.g. on legacy Vector (there’s no such ID on legacy Vector). Since the main page should work on all skins, with as little skin-specific code as possible, could we make so that at least the fallback works across skins? Also, the default behavior is not properly prevented by ULS, so sometimes when one cliks on the button, the browser jumps to the skin-provided button in addition to toggling the ULS popup. Even worse, your example template uses an absolute link, so if the URL is not canonical (e.g. testing another skin, or viewing the template itself, not the main page), this not prevented default behavior results in actual navigation, causing the ULS popup to be lost together with the unloaded page.

// These styles would be shipped by template styles not JavaScript. The body class is needed to get around scoping challenges.
mw.util.addCSS(`
body.page-Main_Page .mw-body-header {

This won’t work with TemplateStyles: TemplateStyles’ output for this input is body.page-Main_Page .mw-parser-output .mw-body-header, and .mw-body-header is not ancestor of any .mw-parser-output. This is an intentional limitation, which aims to prevent non-privileged TemplateStyles styles to break out of the page content. Currently styles for the header can be added only by JS or site styles like MediaWiki:Common.css or gadgets. Maybe there could be a MediaWiki:Mainpage.css that would load only on the main page like TemplateStyles, but would be privileged (i.e. editable only by interface admins) and unrestricted (no scope rewriting, probably no restriction on what CSS properties can be used) like Common.css, in order to prevent unnecessary styles to be loaded in articles while maintaining the security of not allowing anyone to touch things outside the content area. But that’s another story and probably out of scope here.

ovasileva raised the priority of this task from Medium to High.Apr 25 2022, 9:19 AM

his won’t work with TemplateStyles: TemplateStyles’ output for this input is body.page-Main_Page .mw-parser-output .mw-body-header, and .mw-body-header is not ancestor of any .mw-parser-output. This is an intentional limitation, which aims to prevent non-privileged TemplateStyles styles to break out of the page content.

For now, you could use MediaWiki:Vector-2022.css. I think TemplateStyles should have special rules on the Main page to support this and I'd be happy to get that work prioritized (I've been pushing for that previously).

Jdlrobson added a subscriber: sgrabarczuk.

@Sdkb @Izno @sgrabarczuk @ovasileva is it clear what's being suggested on wiki (T293470#)7870077? If not, what would be a useful next step for updating the English Wikipedia main page as envisioned?

Olga, per the discussion with @Tacsipacsi if we're happy with my suggested approach here we should create a task to expand the use of TemplateStyles outside the main content on the main page.

When you added the subtasks, I looked into them, and realized that special-casing the main page is actually not that great idea. Instead I prefer making Gadgets capable of loading an (in this case, CSS-only) gadget only on certain pages (I prefer T241524, but that’s not the only way to solve the problem). First, it’s a more general solution, solving much more problems and thus creating less technical debt; second, a page title hardcoded in software code means that those rules apply only on that one page, and not for example in yesterday’s main page, tomorrow’s main page, sandbox main page etc. There’s no staging environment, if one makes a mistake, it’s the main page which is broken.

Hi, French wikipedians requested several times the language switching at the top of the Main page of fr.wp on Vector 2022 (exemple). After discussion (1, 2) Wikipedia French community asks to add a title on the Main page, actually the preferred solution is a title with the Welcome message in French as shown above (''Bienvenue sur Wikipédia'' for logged-out and ''Bienvenue _user_name_'' for logged-in or similar). As suggested in the FAQ, the French community is waiting for the team to make the change. Tell me if I have to open a new task, thank you.

@Patafisik we can do that but it will need to be next year given we are limiting deploys in December! Could you make a new phabricator ticket tagged Wikimedia-Site-requests (following the guidelines in https://wikitech.wikimedia.org/wiki/Wikimedia_site_requests#Lifecycle_of_a_request) to make this happen?

@TheDJ @Izno any chance either of you would be able to help us add an h1 with the language switcher to the main page on English before the launch? Or could you suggest other community developers who might be able to help?

@TheDJ @Izno any chance either of you would be able to help us add an h1 with the language switcher to the main page on English before the launch? Or could you suggest other community developers who might be able to help?

See my opinions in T293470#7432150 and T293470#7432242. That is a request that requires community consensus and I don't think you will get it (I obviously do not speak for them but I'd put the odds of acceptance somewhere between "not a snowball's chance in hell, thank you for asking" and "over our dead body" :).

Having something like Create language switcher templates for main page would go a way to starting a conversation about potentially raising the profile of these links, but I provide no guarantees and would probably rate effort spent on that, without discussion with affected communities, as being wasted.

Having something like Create language switcher templates for main page would go a way to starting a conversation about potentially raising the profile of these links, but I provide no guarantees and would probably rate effort spent on that, without discussion with affected communities, as being wasted.

And that's why trying to convince 800+ projects is a dead-end idea, and the first approach should be T293405.

Having something like Create language switcher templates for main page would go a way to starting a conversation about potentially raising the profile of these links, but I provide no guarantees and would probably rate effort spent on that, without discussion with affected communities, as being wasted.

And that's why trying to convince 800+ projects is a dead-end idea, and the first approach should be T293405.

Which does not solve the problem in this task, at all. It is entirely irrelevant, because nothing within the power that task can solve can touch the interface/"chrome" of a page.

The problem statement for this task is:

  • Vector 22 adds a language switcher in the space in/around the normal h1.
  • Wikis, like English Wikipedia and many others, remove the h1, either in global CSS (as it had been for a long time) or with the message added in T255682 (English Wikipedia now hides it with the latter).
  • Now WMF doesn't know what to do about the language switcher they added for the main page, which is known to be a special case.

As I said before, a fallback is required or a magic word switcher is necessary. The fallback could reasonably key off the empty message from T255682 if it is believed a magic word switcher is too much work or if some discussions with the affected communities indicate it would be a waste of time entirely. The fallback I was envisioning would go in the sidebar where it has always lived, but there is currently a fallback today at the bottom of the page, which is not terribly unreasonable even if, again, the WMF would prefer it elsewhere.

@TheDJ @Izno any chance either of you would be able to help us add an h1 with the language switcher to the main page on English before the launch? Or could you suggest other community developers who might be able to help?

See my opinions in T293470#7432150 and T293470#7432242. That is a request that requires community consensus and I don't think you will get it (I obviously do not speak for them but I'd put the odds of acceptance somewhere between "not a snowball's chance in hell, thank you for asking" and "over our dead body" :).

Having something like Create language switcher templates for main page would go a way to starting a conversation about potentially raising the profile of these links, but I provide no guarantees and would probably rate effort spent on that, without discussion with affected communities, as being wasted.

@Izno I apologies for not taking the time to regain context here, and thus be reminded that you had already responded to this question.

One option that French Wikipedia is discussing is adding the language switcher to the top of the page without the page title. Personally I think if you're going to add the language switcher you might as well add the page title (it doesn't require much extra space, and the language switcher is just kind of floating without it) but I guess it's better than nothing. To see how that looks you can use ?vectorlanguageinmainpageheader=1

Screen Shot 2023-01-19 at 8.30.57 AM.png (2×3 px, 2 MB)

Personally, that does not look at all good to me. It creates a blank space, pushing the actual content of the main page down.

@Sdkb what if we moved Welcome to Wikipedia box into that space? That should be supported using MediaWiki:Mainpage-title

Personally, that does not look at all good to me. It creates a blank space, pushing the actual content of the main page down.

To me it seems like a reasonable tradeoff. (Though I have to note that the fact that ULS opens an extremely small box there is ironic.)

@Jdlrobson I'm not quite sure what you mean. Is it this? I continue to think that this is the best design option we have with the current en-WP homepage:

Concept of Wikipedia Main Page with no portals and language link.png (480×1 px, 202 KB)

Personally I think if you're going to add the language switcher you might as well add the page title ...

Yes, I agree with that conclusion. :)

@Jdlrobson I'm not quite sure what you mean. Is it this?

No, Jdlrobson is suggesting to move the text "Welcome to Wikipedia" into the headline of the page by readding that h1.

@Sdkb what if we moved Welcome to Wikipedia box into that space? That should be supported using MediaWiki:Mainpage-title

One option that French Wikipedia is discussing is adding the language switcher to the top of the page without the page title.

Any change to the above-the-fold on English Wikipedia will need consensus (and really, anything above and including "featured picture" and "featured list", which are not often above the fold). English Wikipedia had gone over a decade since any significant change was made above the fold until last year. The removal of some navigation links in May 2010, and tweaking some colors, and then last year the removal of the portals in April 2022, which was the result of a surprisingly short RFC that came about more because the community has finally turned away from portals and less because they thought the main page should change. The next major change before those fairly minor changes in 2010 was this revamp in March 2006. (We apparently change the main page on roughly the same schedule as Wikimedia changes the desktop skin. :)

I don't have any strong opinions about the main page, so I'm not the target audience (besides that I like that all the sections exist and hate that they still have colored boxes around them - hey everyone's got an opinion about the main page :). I don't know if I would like to have a title line personally, haven't thought about it too much, but if you should move the welcome line then the question you're asking is "where does the other stuff in what's currently the title box go?". And then we're definitely in "redesign the main page" mode and that never goes as well as one might want it to. I think also framing any request to the community - that isn't one of the other options I've already stated I think you can sell - on the motivation of "we introduced the button in this place on testing that didn't test the space for anything but the presence or absence of that button, now we want you to 'fix' your main page" is not going to go over well, even ignoring that right now your (WMF and/or the DI team in particular) social capital is probably not very much due to the rollout of Vector22.

Adding the title seems awkward to me.