Note on that page: "When using, note that many parameters, specifically those relating to visual appearance may not apply or work as expected to certain skins (notably the Minerva skin used by the mobile site)"
This is one if those cases.

Im not sure what code is responsible for doing this but Minerva or Mobilefrontend is not explicitly turning this off.

This is mediawiki.page.gallery.slideshow, which doesn't have target mobile.

@TheDJ let's try turning it on today and see what it looks like.

@Jdlrobson did it work?

@Biologically it's written in OOUI so it looks like turning it on is not a problem but the module itself causes a severe reflow/restructure of the page (is jumpy) which I'd prefer for us to fix before enabling on mobile.

It also seems to break the media viewer on mobile, so we'd need to adjust that as well.

@Jdlrobson , thank you. I shall eagerly wait for these changes in the next updates.

@Yuriy_kosygin has suggested at the English Wikivoyage that this should be the default gallery mode for most mobile/smartphone readers. It sounds like a reasonable approach (swipe through the images, rather than seeing tiny/illegible thumbs).

With a volunteer hat on: Does this also mean the end of the archaic image policy on Wikivoyage? https://en.wikivoyage.org/wiki/Wikivoyage:Image_policy#Minimal_use_of_images

@Whatamidoing-WMF Thank your add me, my thoughts are as you described!

@Jdlrobson That's right, but when reading on the mobile version, the image show is vertical (even if the picture is no more than 5), causing the reader need keep to scroll down to find what they want text. Taking the Scroll gallery is hopeful. Let the image scroll left and right.

Change 505286 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/core@master] Gallery slideshow: Enable on mobile

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

https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/505286/ enables this on mobile.
For an anonymous user JavaScript payload jumps from 155kb to 235kb. The module mediawiki.page.gallery.slideshow is loaded at the top of the page via a call to mw.loader.load(RLPAGEMODULES);. See T176211 and solution for Popups on why this is a problem. Aside from the performance consideration, this is a big jump for one feature. Enabling this as is sets a precedent and could easily result in mobile having a simple JavaScript payload to desktop. We can do better!

Firstly, It looks like enabling it is not enough - it also doesn't render due to the lazy loading images transform on mobile. Obviously that patch is not enough to make this work:

There is also flash of unstyled content on desktop, that should be taken care of. This kind of thing is a big problem on mobile, where connections tend to slow, and for readers who have begun reading before the page is fully loaded, they may be confused by such a repaint which would lose them their place in the article. Ideally the styles for this module should be loaded up front (or space reserved). My preference would be for the gallery code to be loaded once an arrow is clicked, however moving it off the critical JS path seems like a good first step.

In T194887#5137158, @Jdlrobson wrote:

https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/505286/ enables this on mobile.
For an anonymous user JavaScript payload jumps from 155kb to 235kb. The module mediawiki.page.gallery.slideshow is loaded at the top of the page via a call to mw.loader.load(RLPAGEMODULES);. See T176211 and solution for Popups on why this is a problem. Aside from the performance consideration, this is a big jump for one feature. Enabling this as is sets a precedent and could easily result in mobile having a simple JavaScript payload to desktop. We can do better!

I think loading that code later would be fine, would that be sufficient?

Firstly, It looks like enabling it is not enough - it also doesn't render due to the lazy loading images transform on mobile. Obviously that patch is not enough to make this work:

Ah, I didn't test with content below the fold.

There is also flash of unstyled content on desktop, that should be taken care of.

Yes, the current implementation falls back to the other gallery style for no-JS environments, but we could detect client JS environments and avoid the FOUC (or at least the height change).

I think loading that code later would be fine, would that be sufficient?

I think this is the easy part to solve, I think the main blocker here is removing that flash of unstyled content which also impacts desktop. Once that's resolved I'll happily help get this loading on mobile. I have created T242143 to make that clearer.

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

[mediawiki/core@master] Galleries on mobile

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

The above patch takes care of everything except the lazy loading image part which I'm looking at separately.

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

[mediawiki/extensions/MobileFrontend@master] Images in galleries should be loaded automatically

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

Change 868175 merged by jenkins-bot:

[mediawiki/core@master] Galleries on mobile

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

Change 868197 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Images in galleries should be loaded automatically

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

The code is loading but it's not compatible with lazy loading right now...
https://en.m.wikipedia.beta.wmflabs.org/wiki/A_gallery_page#Foo

Lazy loading is working for me. Perhaps beta cluster had some issue when you were testing.

However it isn't displaying very well:

The image is tiny:

The file name issue is the lazy loading problem. Am working on a solution.

Also working on the small image as part of T326270

Change 505286 abandoned by Jdlrobson:

[mediawiki/core@master] Gallery slideshow: Enable on mobile

Reason:

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

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

[mediawiki/core@master] Make gallery code more resilient to HTML transformations

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

Change 875453 merged by jenkins-bot:

[mediawiki/core@master] Galleries: Make gallery code more resilient to HTML transformations

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

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

[mediawiki/skins/MinervaNeue@master] Fixes issue with height in slideshow

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

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

[mediawiki/core@master] Galleries: Set anchor height as well as img height

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

Almost there. The Minerva style .content a > img, .content noscript > img for responsive images is interfering with the height declaration. The above two patches should take care of that and then I think this is good to go for the train next week.

Change 876242 merged by jenkins-bot:

[mediawiki/core@master] Galleries: Set anchor height as well as img height

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

Change 876241 merged by jenkins-bot:

[mediawiki/skins/MinervaNeue@master] Fixes issue with height in slideshow

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

Change 881025 had a related patch set uploaded (by Jdlrobson; author: Bartosz Dziewoński):

[mediawiki/core@master] [wip] Gallery: Improve gallery for mobile (take 2)

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

I noticed today that this has got worse (https://m.mediawiki.org/wiki/Help:Images#mode_parameter) so I suggest we load this code and add a guard against making the slideshow - https://gerrit.wikimedia.org/r/c/mediawiki/core/+/906135 - that will at least make the content accessible but will avoid the reflows/repaints and broken thumbnails flagged above that we are trying to avoid.

Change 881025 abandoned by Jdlrobson:

[mediawiki/core@master] Gallery: Rewrite

Reason:

Not working on this currently as have too much on my plate :-( cc @thedj who also said he was interested in rewriting this.

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