Looks good! 👍🏼

I tested further on other devices I have and it seems it depends on iOS version. If you're on v. 14 it works! Older iOS versions (11, 12, and some variants of 13) do not work.

This hit production before it went all the way through QA. It woks beautifully on Windows desktop, but fails on mobile (tested on iPhone Safari and Chrome). 😦

I verified this code is on production (via a search for Atlas van Dirk van der Hagen, with a result that could only be found via that text because it has a corresponding P2643 statement). However, we're still not getting the desired results for "The Kiss". Thoughts, @matthiasmullie ? 🤔

Resurrection time!

It's beautiful. I have no notes. Thank you! 😺

@Ottomata we don't need IP/geocoded data. thanks!

"All namespaces except for NS_FILE" is fine for now. We might have to have a later conversation about how we rank all that (categories first, I would guess), but for now this should work.

@Jarekt is this working for you now?

See T257938

@Lydia_Pintscher and @Samantha_Alipio_WMDE - given that WMDE is drafting new stuff for the REST API, I'd defer to you on ideas for how this kind of change should apply in more general use cases. On our side, we're fine with a param on wbeditentity

Is there a plan to bring MediaSearch to other wikis in the future, or will it be a Commons-specific media search interface? If it becomes the way to search media on wikis, will search results be a combination of wiki-specific and Commons results? I'm asking because it affects what we think of as a "search result", and whether we need to be prepared to store wiki & page ID or not.

We can't reproduce this anymore so something got fixed (or the bug is intermittent). Will reopen if it pops up again.

Based on discussion today, @Cparle will reach out to @Addshore to discuss technical implications of changing things here.

Don't forget tracking our upcoming Copy buttons (to copy the filename or wikitext), which I assume will nest under "Quickview interactions" 🙂

@Multichill are you only seeing this issue on Commons, or is it on Wikidata as well? Also, if you could point us to your bot code and the exact part where this conflict happens that will help us and WMDE diagnose the problem.

This was due to the first of many purposeful changes to the way search on Commons works. Overall, it has been received well, and the upcoming MediaSearch will change things even further.

@Addshore any thoughts on this? Something change in Wikibase recently?

"if its file page has no categories" I'd suggest caution here, @Cparle - files often get the "Media needing categories as of ____" categories automatically added to them and those aren't hidden categories so that could potentially throw things off. I suggest either attempting to exempt those categories or just change the condition check to prioritize images with less than 2 categories.

@Cparle could be your apprentice 😃

$someone seems to still be null 😄 Do you have time for this @ArielGlenn ?

Creating a user operated bot to reflect Wikidata redirects on Commons, similar to the way it's handled on Wikidata per the comment below, may be possible now with the WCQS. I wonder if @LucasWerkmeister has suggestions here?

This is maybe something to keep in mind for T260251

Bumping this one to later (cleanup/polish for RC) since Beta phase is pretty packed right now.

I spot checked this on Beta and it looks like the left margin is gone but the right one is not. Could use another set of eyes on it 👀

Hi! Based on our OKR planning, we have two questions to ask (but we don't need to ask them both at once).

1. Is this search experience an improvement over the default Commons search experience?
2. Do you think this search will lead you to start your image searches here on Commons, or will you use a major search engine (Google, Bing, etc.) as your image search starting point?

Confirmed in the InitialiseSettings.php file on production.

I definitely support closing it ✔

This was finished as part of other work.

This was finished as part of other work.

Confirming that there's no need to process this data. The SD team will replace the code with Event Platform at a later date. Will there be any detrimental effects if that code stays up for a while until we can get to it?

have fun!

All the QuickView icons appear on production.

The Concept URI link (which includes the page's M ID) now appears in the left nav for all files even if they don't have structured data.

In T260706#6399933, @CBogen wrote:

I agree with Matthias - the detailed analysis would be very welcome but is not urgent. I suspect with the work on search that we are focused on, especially as we consider moving to the Wikipedias, that this will become even more welcome next quarter (in October or so).

The "quick & simple analysis of preference from interleaved A/B tests" is urgent, however. I'm hoping that @nettrom_WMF and/or @mpopov can help us run this after the A/B test ends on Aug 31.

The only one other concern I have (which might be minor) is this - in our current advanced search UI we combine the extension variants into just one (for the mimetype). So for TIFF we just look for tiff, not tiff and tif. Behind the scenes it's doing a filemime:xxx search, and that is looking for specific strings (filemime:jpeg works, filemime:jpg doesn't).

In T260721#6394311, @AnneT wrote:

@CBogen / @Ramsey-WMF, could I get a second pair of eyes on the file types per tab in the acceptance criteria here? Do those look right to you? I checked the allowed file types on Special:Upload and had to look a few of them up so I wanted to make sure I didn't miss anything.

@Ottomata I discussed this with @MarkTraceur and we think you can go ahead and deactivate the MediaViewer EventLogging. We'll tackle implementing Event Platform for that code at a later date. Thanks!

@EBernhardson as part of Computer Aided Tagging's machine vision platform we currently use Google's SafeSearch classifier system to prevent "surprising" images appearing in the popular images feed. This means that we have hundreds of thousands of images in a DB already that have some NSFW flags, but it's in a CAT DB that nothing else uses.

Doesn't seem to be working ☹

should be testable on production now

This looks like T245396, which @Ladsgroup @Addshore and @hoo worked on just a few months ago. I think they have more expertise here than we do 🙂

None of this applies for the new search

All done!

Old Issue that doesn't apply to the current system.

Constraints work now and the three main icons are properly displayed (without weird spacing issues) as of last week.

The new search methodology is very different and doesn't require these hacks.

This did indeed magically go away after numerous UI changes.

Works on production.

The debate isn't quite resolved yet, but hopefully we are entering conditions where it will be. As we work on MediaSearch and do real-world testing on the effects of depicts on search results, we hope to have solid evidence that will settle it one way or the other.

@Milimetric picking this up again. We want to measure "Save As..." ideally, but in previous discussions (it's been over a year, fuzzy) we were told it was hard to differentiate because of how Commons handles links (ex: the "Download" button doesn't trigger a download, just displays a URL to the file that the user has to copy-paste). Perhaps we can measure how many times someone clicks that link per file to signal intent...although it's not very reliable.

Yup. Experiment phase complete ✔