In T293470#7715855, @alexhollender_WMF wrote:

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.

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

In T293470#7717402, @Theklan wrote:

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.

In T293470#7734802, @Theklan wrote:

• 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.

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

2. 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

3. 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.

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.

In T293470#7865957, @Jdlrobson wrote:

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)

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)

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?

In T293470#7868637, @Jdlrobson 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/)

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:

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.

In T293470#7870077, @Jdlrobson wrote:

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:

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.

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).

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?

In T293470#8523965, @alexhollender_WMF wrote:

@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.

In T293470#8524648, @Theklan wrote:

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.

In T293470#8524507, @Izno wrote:

In T293470#8523965, @alexhollender_WMF wrote:

@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

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

In T293470#8540778, @Sdkb wrote:

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:

In T293470#8540029, @alexhollender_WMF wrote:

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. :)

In T293470#8541699, @Sdkb wrote:

@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.

In T293470#8540814, @Jdlrobson wrote:

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

In T293470#8540029, @alexhollender_WMF wrote:

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. I’d personally much prefer allowing communities to place the switcher wherever they want on the page, through a parser function.

Related task for long text/two line text in the header: https://phabricator.wikimedia.org/T330567

Some wikis already have a header in the Main Page, without other elements at the right, so there are no limitations as described on the Language switching page. For this group of wikis with a header in the Main Page, the language switcher should be available at the top of the Main Page without a formal request by community.

Exemples for Italian language and dialects and related languages:

• Italian Wiktionary https://it.wiktionary.org/wiki/Pagina_principale?useskin=vector-2022&safemode=1
• Wikisource in Piedmontese https://pms.wikisource.org/wiki/Intrada?useskin=vector-2022&safemode=1
• https://co.wiktionary.org/wiki/Pagina_maestra?useskin=vector-2022&safemode=1
• https://scn.wiktionary.org/wiki/P%C3%A0ggina_principali?useskin=vector-2022&safemode=1
• https://it.wikiversity.org/wiki/Pagina_principale?useskin=vector-2022&safemode=1
• https://it.wikinews.org/wiki/Pagina_principale?useskin=vector-2022&safemode=1
• https://it.wikibooks.org/wiki/Pagina_principale?useskin=vector-2022&safemode=1
• https://it.wikiquote.org/wiki/Pagina_principale?useskin=vector-2022&safemode=1
• https://co.wikipedia.org/wiki/Pagina_maestra?useskin=vector-2022&safemode=1
• https://roa-tara.wikipedia.org/wiki/Pagene_Prengep%C3%A1le?useskin=vector-2022&safemode=1
• https://roa-rup.wikipedia.org/wiki/Prota_fr%C3%A3ndz%C3%A3?useskin=vector-2022&safemode=1
• https://fur.wikipedia.org/wiki/Pagjine_princip%C3%A2l?useskin=vector-2022&safemode=1
• https://lld.wikipedia.org/wiki/Plata_prinzipala?useskin=vector-2022&safemode=1
• https://pms.wikipedia.org/wiki/Intrada?useskin=vector-2022&safemode=1

In the specific case of https://lij.wikipedia.org/wiki/Pagina_prin%C3%A7ip%C3%A2 the top is already occupied by icons, we need to talk with community before.

Exemples for French language and dialects and French related languages:

• https://wa.wikipedia.org/wiki/Mwaisse_p%C3%A5dje?useskin=vector-2022&safemode=1
• https://en.wikiquote.org/wiki/Main_Page?useskin=vector-2022&safemode=1
• https://ln.wiktionary.org/wiki/Lok%C3%A1s%C3%A1_ya_libos%C3%B3?useskin=vector-2022&safemode=1
• https://oc.wiktionary.org/wiki/Wikiccionari:Pagina_d%27acu%C3%A8lh?useskin=vector-2022&safemode=1
• https://shy.wiktionary.org/wiki/Asebtar_amenzu?useskin=vector-2022&safemode=1
• https://ht.wikipedia.org/wiki/Paj_Prensipal?useskin=vector-2022&safemode=1
• https://oc.wikipedia.org/wiki/Acu%C3%A8lh?useskin=vector-2022&safemode=1
• https://kbp.wikipedia.org/wiki/Tal%C9%A9_%C9%96eu?useskin=vector-2022&safemode=1
• https://gcr.wikipedia.org/wiki/Paj_Prensipal?useskin=vector-2022&safemode=1
• https://nrm.wikipedia.org/wiki/Page_d%C3%A9_garde?useskin=vector-2022&safemode=1
• https://pcd.wikipedia.org/wiki/Accueul?useskin=vector-2022&safemode=1
• https://ff.wikipedia.org/wiki/Hello_ja%C9%93%C9%93orgo?useskin=vector-2022&safemode=1
• https://kbp.wikipedia.org/wiki/Tal%C9%A9_%C9%96eu?useskin=vector-2022&safemode=1
• https://ln.wikipedia.org/wiki/Lok%C3%A1s%C3%A1_ya_libos%C3%B3?useskin=vector-2022&safemode=1
• https://ln.wikipedia.org/wiki/Lok%C3%A1s%C3%A1_ya_libos%C3%B3?useskin=vector-2022&safemode=1
• https://sg.wikipedia.org/wiki/G%C3%A4_nz%C3%B6n%C3%AE?useskin=vector-2022&safemode=1
• https://bm.wikipedia.org/wiki/Ny%C9%9B_f%C9%94l%C9%94?useskin=vector-2022&safemode=1
• https://ty.wikipedia.org/wiki/Fa%E2%80%99ari%E2%80%99ira%E2%80%99a?useskin=vector-2022&safemode=1
• https://wa.wikipedia.org/wiki/Mwaisse_p%C3%A5dje?useskin=vector-2022&safemode=1

In this specific case, the Main page has a different language button, not linked to other Main Pages:

• https://wo.wiktionary.org/wiki/X%C3%ABtu_Nj%C3%ABlb%C3%A9en?useskin=vector-2022&safemode=1