Hey @Prototyperspective, these sound like reasonable ideas for how to improve the user experience here, so I want to bring this to the attention of the Structured Data team (who are the official maintainers of this feature AFAIK). @AUgolnikova-WMF or @Sannita may be able to move this task to the appropriate place for triaging. I will say that I think the team's current focus is on improving UploadWizard, so this might not be an immediate priority.

Thanks for CCing. @egardner Yes of course. The Media search is much better. However, there are several problems with it due to which in practice one often has to resort to the Special search. The better solution would be to improve Media search further so that Special search is not needed anymore at all (that would be separate issues). Two main problems with it are that Cat-a-lot (which is very useful especially on WMC) does not work in Media search and that it doesn't have this dropdown for search operators.

Right now this limit is not even 4GB.

Hi @Prototyperspective – are you familiar with Special:MediaSearch on commons? Here's an example of it in action:

CC'ing more folks who were involved in this change to get another opinion in this ticket.

I already knew about this research and agree with the findings and what it means for Wikipedia. But it does not apply here much or at all because these are search results. Even if it applied, then the solution here would be to show two columns. I do not have understanding for declining this. The special search shouldn't be this broken if it's not abandoned. Please reopen.

the space should be used until a preview is shown there, just like with the modern not-broken wall-of-images-view Media search results (example) which use all available width until an item is clicked for preview

@Aklapper That only relates to what would be needed for this problem to be fixed – in specific that the default for WMC needs to be different than other Wikimedia sites, eg site-specific changes on top of the default page layout that makes it use a wider width.

The empty space is used for interwiki search results or previews in other cases. Page layout shouldn't differ across pages, thus empty space in this case when there are no interwiki search results or previews.

In T369808#9973188, @Prototyperspective wrote:

That is not true. It does work well here

@Aklapper I don't think this should be closed and it seems way to quick to close it – I don't understand your explanation. When I click on a file in these search results the page is opened instead of a preview showing on the right. Whether or not it's intentional doesn't make it any better, if anything it would be a bigger problem and indicate that it would be easier to fix. And remains the case that the Special search UI is broken. Could you please clarify what you mean in the sense of why you think this is not a valid issue?

@Aklapper That is not true. It does work well here for example (which has been very useful to find files missing in the cat) and this category contains thousands of files.

The operator works but AFAIK negation is currently not supported.

Assuming the total width on the screenshot is between 1440px and 720px, mw-search-results-container intentionally defines to use 7/12 for content, 1/12 space, and 4/12 for interwiki results and search previews (which doesn't apply in the screenshot above, thus the emptiness in this special case) since https://gerrit.wikimedia.org/r/c/mediawiki/core/+/902677 . Rating consistency across wikis higher than this special case, I'm declining this request.

Removing tag as this is unrelated to the Advanced-Search interface not shown in the screenshot.

This appears to have been an issue with a previous version of librsvg, I've purged the caches for each of the affected images in this case and they now render correctly. If you notice any other similarly incorrect images, purging the cache will hopefully address it.

Oh actually, it's correct in safe mode when I view the live page, but not the old revision page.

@Aklapper the page looks the same in safe mode. I also can't edit the page with the safe mode flag.

Hi @ChromeGames923, thanks for taking the time to report this! Is this specific to Commons, or does this also happen on other wikis?

Some examples of what the page looks like on mobile edit preview (fine) versus what it looks like once the edit is published (broken). Not sure what causes the edit preview to match or not match the end result, it does not always look "correct". For example, the first time I encountered the issue on the Illustration request page, the characters were broken in the edit preview (all four jumbled together), but I published anyways thinking it must be a bug with the preview and that it would be fine on the actual page, but that was not the page.

Uploads have been going much better today, thank you to whoever fixed this. :-)

In T369298#9954690, @Urbanecm_WMF wrote:

Done.

https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=h@bbef750&_a=h@2ee6f1d
https://grafana-rw.wikimedia.org/d/OPgmB1Eiz/swift?forceLogin=&from=1719294248878&orgId=1&to=1720203381602&var-site=All&viewPanel=37

Also getting errors while uploading: