In T424090#12216978, @Gehel wrote:

@egardner : should I understand from your comment that if we decommission this Semantic Search cluster, you don't care too much?

The path to an eventual production service for Semantic search is a different discussion (we'll get there hopefully). @pfischer is probably to right person to talk to for an eventual prod service (but you're probably already in contact).

Hi there. I'm on the Future-Audiences team, where we are working on some ideas for consumer-facing AI tools that talk to Wikipedia (plugins, MCP servers, etc).

A lot has changed since 2021. At this point it is possible to ship Vue-based UIs via ResourceLoader, written in mostly-idiomatic Vue SFCs; Codex supports server-side "tree-shaking" (you can specify the exact component or icons you need in PHP); and we now have Codex CSS only components and Codex PHP for fully server-rendered, no JS UIs. We've dropped IE11 compatibility and we ship ES6 to the client natively, removing the most glaring needs for some sort of transpilation step.

This was by design (thus far we've assumed Thumbnail images to be purely decorative, and thus excluded from assistive technology).

I've posted a WIP patch that relies on MW Core's WikitextStructure class instead of TextExtracts: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaCustomizations/+/1312731

Ok, patch is posted and a new patchdemo has been set up to verify the fix.

Hi @Ponor — thanks for flagging this; it's a real bug, distinct from the one fixed above but with the same underlying reason.

I've updated the task description to reflect the current approach.

Some quick thoughts about this, since @SherryYang-WMF and I were just chatting about it.

Thanks for raising these questions, @Krinkle. Addressing them below.

In T430854#12103994, @stjn wrote:

In T430854#12101921, @Johannnes89 wrote:

Slightly off-topic, but does https://www.mediawiki.org/wiki/Readers/Reader_Growth/Image_Browsing have an effect of the image limit? (@egardner fyi).
I checked https://en.wikipedia.org/wiki/List_of_national_flags_by_design on my phone and it seems the carousel shows at least 100+ images (I stopped counting afterwards, the actual number is probably 200-300 images) which would heavily limit the number of images editors can show in the list itself if all of them are counted twice...

Seems like MediaViewer loads very slowly the first time you click on a file on those articles (both in the old and the new version) but then it shows 1/965. Ideally, this case should be optimised for in the new version, because I thought something was broken at first when I tried clicking on an image because the loading time was noticeably slow (both versions clearly try to do some sort of API requests or something that take too much time when the amount of images is that big).

The bug is specific to the legacy-parser mobile pipeline, which is why this was difficult to replicate.

There is a patch up for review. This patch changes the behavior of *both* desktop/legacy MMV as well as mobile/beta MMV. It attempts to detect a common pattern where an .infobox-caption element lives adjacent to an .infobox-image element, in the same table cell. It does not attempt to cover cases where multiple images (each with their own captions) exist in a single cell.

One thing worth noting here. The reason that we didn't replicate the exact behavior from our ImageBrowsing experiment is that we decided to rely on the existing (desktop) MMV data model. So the caption-fetching behavior we currently follow is the same as what desktop MMV has done for a long time, and the logic is shared (in the bootstrap code and the LightboxImage class, etc).

This patch seems to fix the problem and is good to merge IMO. I could see a regression test being useful to capture this, but addTooltip would need to be exported from render.js in that case and I'm not sure if that kind of design change is worthwhile (or if a quick fix is preferred here). @aude I'd say this is your call. Aside from that consideration (which I don't consider blocking), this LGTM.

I'm going to keep looking into this to see if I can improve further.

We will backport some changes tomorrow morning that should fix this – sorry for the inconvenience! You might have to temporarily log out or disable the beta feature until then. Seems to only surface on specific pages.

@JScherer-WMF the image 13 you are referring to here is a 200MB animated GIF file. This kind of file is always going to be a challenge here and we may need a solution specific to large animated GIFs eventually. But I think this is rare enough that it doesn't need to block the roll-out of this feature.