Sounds good. Would love to not have to support this configuration flag.

Please note I would highly recommend you don't attempt to override this behaviour with CSS or JS as the code here is pretty complex and it will be difficult to do that without impacting performance or risking future bugs when this code changes. Please do reach out for input/support if you do consider such a gadget.

Note: when disabling this configuration flag an override to expand all by default becomes available in the mobile settings so anonymous and logged in users will be able to override this. Any gadget may likely want to exploit this setting.

In T376446#10203930, @Jdlrobson wrote:

Please note I would highly recommend you don't attempt to override this behaviour with CSS or JS as the code here is pretty complex and it will be difficult to do that without impacting performance or risking future bugs when this code changes. Please do reach out for input/support if you do consider such a gadget.

I have tested the following code manually (on other projects, since it cannot really be tested with $wgMFCollapseSectionsByDefault disabled) and it seems to work just fine.

// On mobile, expand the only L2 section if there is only one.
// Run only in content namespaces (Main and Reconstruction).
if ([0, 118].includes(mw.config.get("wgNamespaceNumber"))) {
	// Find all L2 sections
	var h2list = document.querySelectorAll("main#content .mw-heading2");
	if (h2list.length === 1 && h2list[0].classList.contains("collapsible-heading")) {
		// Only one h2 - expand it if it is not already open.
		var h2 = h2list[0];
		if (!h2.classList.contains("open-block")) {
			// h2 is not open. open it.
			h2.click();
			window.requestAnimationFrame(function () {
				// reopen the h2 again in case it is accidentally closed by another script
				if (!h2.classList.contains("open-block")) {
					h2.click();
				}
			});
		}
	}
}

Gotcha. If this is for logged out users this is fine, but please do not ever run this code as a default gadget or in MediaWiki:Common.js as we cannot officially support this in the code (and on the long term upstream changes such as Parsoid roll out, might lead to breaking display of the page completely). This code also causes what is known as a reflow so as written, as well as damaging user performance,
since mobile is the primary source that search engines crawl you would be seriously damaging your search indexing for those pages.

If you need a solution for pages with 1 section for anonymous users too it would be better to request this is supported officially by the software. We can alter the logic around collapsing which would likely benefit over projects too.

Well, it is going to have to be in Mobile.js (https://en.wiktionary.org/wiki/MediaWiki:Mobile.js) to run automatically on the mobile frontend in order to get the desired behavior.

The worst case scenario I can think of is that it just stops working (as in the single section no longer gets expanded automatically), and then we can easily update it. It's not the first nor the last time something in the global scripts has stopped working. People usually notice and then have issues fixed.

I don't think anyone really has most people have the expectation that MediaWiki developers would be responsible for supporting everything that is placed on these site-specific script pages.

The alternative is waiting for the proper solution in MobileFrontend directly, as you mention, but seeing as it has not been developed after ten years of waiting, the community would rather not have to wait for that any longer.

I agree that some hacky JS isn't ideal because users would see a flash of the collapsed headers until that code runs. If there's a reasonable ETA for @Jdlrobson's idea then we could wait for that. But as I wrote in the on-wiki discussion there's value to have a system managed by the community which can be customized as necessary (e.g. always expand English and Translingual, or go by section size, etc etc).

Change #1078397 had a related patch set uploaded (by Ammarpad; author: Ammarpad):

[operations/mediawiki-config@master] enwiktionary: Enable $wgMFCollapseSectionsByDefault

https://gerrit.wikimedia.org/r/1078397

In T376446#10204121, @Jdlrobson wrote:

Gotcha. If this is for logged out users this is fine, but please do not ever run this code as a default gadget or in MediaWiki:Common.js as we cannot officially support this in the code (and on the long term upstream changes such as Parsoid roll out, might lead to breaking display of the page completely). This code also causes what is known as a reflow so as written, as well as damaging user performance,
since mobile is the primary source that search engines crawl you would be seriously damaging your search indexing for those pages.

If you need a solution for pages with 1 section for anonymous users too it would be better to request this is supported officially by the software. We can alter the logic around collapsing which would likely benefit over projects too.

This comment confuses me – did you mean that it would be fine if it’s only for logged in users? Or am I missing something?

And just to clarify: is it okay to deploy the above config change, i.e. collapse all sections by default, without a MobileFrontend feature to expand sections if there’s only one section?

is it okay to deploy the above config change, i.e. collapse all sections by default, without a MobileFrontend feature to expand sections if there’s only one section?

From the point of view of the English Wiktionary community, yes, because we have the JavaScript code to do this (I posted it above). The long term solution should probably be to implement that properly and directly in MobileFrontend, though.

The web team can work on T374883 this month as it aligns with work we are doing relating to the Parsoid migration and will offer a solution for this in the software. It seems sensible that pages with only one section should not be collapsed and the software should handle that elegantly. MobileFrontend and Minerva are actively developed and maintained by members of the WMF. I assure you "not been developed after ten years of waiting" is far from the truth.

Well, it is going to have to be in Mobile.js to run automatically on the mobile frontend in order to get the desired behavior.

@Surjection to be direct, do not add that code for anonymous users via Mobile.js. To do this we would be knowingly damaging performance for all users on the site and we would be penalizing those pages in search engine results. Neither of those is good and causes damage to your project that is hard to recover from. It will also break when Parsoid migration happens. If you want to add this as an opt-in gadget that's fine. I hope we can agree that it doesn't seem unreasonable to have an interim state for a few weeks where sections appear collapsed on pages with 1 heading.

And just to clarify: is it okay to deploy the above config change, i.e. collapse all sections by default, without a MobileFrontend feature to expand sections if there's only one section?

It depends. It's okay to deploy the config change if we have agreement to not introduce the on-wiki code as a default gadget. If the on-wiki is going to be enabled immediately afterwards and we're not willing to wait for T374883, I personally would not be comfortable being complicit in this deploy. If it's important that we have a solution for pages with only one heading, I'd recommend waiting for T374883.

I assure you "not been developed after ten years of waiting" is far from the truth.

The original issue was ten years ago, and the solution implemented there has been a thorn on everyone's side since. I can grant you that it is highly unlikely that there has been sufficient communication over this fact.

@Surjection to be direct, do not add that code for anonymous users via Mobile.js.

I have removed it, but I struggle to understand the arguments for not having it. I have already addressed the maintenance point earlier.

To do this we would be knowingly damaging performance for all users on the site

The performance impact should be minimal, certainly less than it is right now when all sections are expanded by default.

This code also causes what is known as a reflow

While not definitive evidence, I can distinctly remember the current situation also causing this - large pages would start with all sections collapsed and they would expand only later. I cannot reproduce this now, so something may have changed.

As for a flash of content the users would see, it is a moot point. The user is either loading the page without an anchor, in which case they start at the top of the page, with an anchor above the sole L2 heading, or with an anchor at or within the sole L2 heading. It is physically impossible for the user to have focused a later L2, since there is only one of them.

we would be penalizing those pages in search engine results

Is there any reason to suspect the script would cause issues with SEO? Having all sections collapsed could easily be considered more damaging, since one would think it means only the section headings are ever vislble.

The web team can work on T374883 this month

As a software developer myself, I know perfectly well that schedules of any kind very rarely get fulfilled as planned. When you say "few weeks", I have to assume it means at least two or three months before the feature as described will be available to Wiktionary readers. That seems like too long of a time to wait. Are there better interim solutions?

And, as a side note, while I know that my opinion on this matter probably means diddly squat, I cannot with good conscience consider any solution in which the existing $wgMFCollapseSectionsByDefault approach is maintained and documented as "dictionary style" with all sections expanded to be satisfactory.

Change #1078397 abandoned by Ammarpad:

[operations/mediawiki-config@master] enwiktionary: Enable $wgMFCollapseSectionsByDefault

https://gerrit.wikimedia.org/r/1078397

I think @Surjection is being too pessimistic. Mobile has been problematic in various ways for a while so it's understandable that a slightly suboptimal setting has flown under the radar. However, it seems a little silly to be so worried about reflows when the site already has popups and banners that are *much* more disruptive than what's being proposed. Also, it doesn't matter how long T374883 takes because I *oppose* applying it on the basis that it precludes any Wiktionary specific logic that we could apply through JavaScript. For example, on an entry with a large English section and a couple small sections in other languages (e.g. https://en.m.wiktionary.org/wiki/coke) it seems like a no-brainer to have English expanded. But on an entry like https://en.m.wiktionary.org/wiki/bulan it seems more reasonable to have everything collapsed and to show the miniTOC instead. This can be hashed out on-wiki. My suggestion to the developers is: if reflow is a concern, allow us to control collapsing behavior on the server side — maybe a special keyword like _COLLAPSED_ in the wikitext. Then a template can be added with whatever custom logic is necessary.

Change #1081254 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/MobileFrontend@master] Drop support for collapsing sections by default

https://gerrit.wikimedia.org/r/1081254

The earlier case of 'expand when there is only one section' can be handled by JavaScript on the project. However, were the developers to ever implement a feature to automatically expand sections if there is only one, that could and should be considered for all Wiktionary projects.

For the record, I would argue this should be the case in all MediaWiki projects. There is no reason to collapse sections when only one <h2> is present. This is also an annoying bug on some disambiguation pages in Wikipedia, like https://ru.m.wikipedia.org/wiki/Забелин

I considered adding JS code to uncollapse the sections on disambiguation pages, too, because currently the readers are required to uncollapse the sections before they can read the majority of contents.

@stjn yep that's the plan. We will do T374883 to improve things for all projects and then remove the configuration flag.

Blocked on T374883: Section collapsing should not apply to certain pages so deploy will happen in next sprint.