Actually @Raymond, scratch that: I'm realizing that since we can't remove the messages from WBMI immediately and don't want to turn off synching to WBMI for a long time, we're going to need to do all of this in tandem with deploying the MediaSearch extension, which won't happen for a little while.

Hey @Raymond, I wanted to let you know that the Structured Data team has decided to go ahead and move forward with this plan to remove the Special:MediaSearch code from the WikibaseMediaInfo extension and move it to a new extension, MediaSearch.

Thanks for the feedback and suggestions, @matthiasmullie! I've pushed some updates to my patch (and will be rebasing and refactoring it soon, too).

@Jcross this is great news, thank you!

@srodlund sorry, I just realized this morning that we never got back to you on a lead image - the one you chose looks good!

Thanks again @srodlund! I'm happy for this to go out next week as you mentioned.

Hey @srodlund, I just granted you edit access. Thanks for your review!

I've started work on this but will pause until we get the green light to resume work on concept chips.

Hi @Jcross, here's an outline of our timeline:

Noting here that it feels weird to me to tell people to check their spelling when there are results...I'm sure that's useful in some circumstances, but it isn't in circumstances where there just aren't a lot of files for that search term. I could see it having a negative connotation to users. Maybe we can re-evaluate if and when we add more stuff to this message?

Hi @Jcross (and @sbassett—thanks for your helpful comments on this process earlier, and I'm sorry for my lack of response!), we have been deliberating how to move forward on this as a team. I'm working on getting you a more concrete timeline on when we plan to formally release this feature, but I can tell you that the extension itself will be ready for review within a few weeks. I'll get back to you with more info as soon as possible (hopefully tomorrow).

This'll take a little while to resolve; all I did was remove the markup from the English message and the CSS style. The markup will need to be removed from other language files as well.

Thanks for your review, @Etonkovidova!

I think I've gotten this to a point where it provides a benefit to the results set, but it's going to need a lot of review and some discussion with @matthiasmullie (in 2021!)

I think there's a case for the latter if we continue work on MediaSearch or if it would benefit others to have the MediaSearch front-end broken out and made more agnostic (if that's even feasible). Let's discuss at the first engineering office hours of the new year?

Thanks for your response, @Mooeypoo.

Changing this to medium because it involves either a nontrivial architectural change, or adding something to state to indicate whether QuickView is open... cc @egardner

This should be resolved by the patch for T266080, which just got merged yesterday!

I've tested the UI patch and confirmed it's working when pointing to production API endpoints. It's now ready for code review.

Also wondering if we've missed some...I'm testing my patch locally and an image with the license Creative Commons Attribution-Share Alike 3.0 it is popping up under "other" instead of share with attributtion/cc-by-sa.

@Etonkovidova Good call on the namespaces; I agree we should display them on this tab.

Thanks very much for the information, @Nikerabbit and @Raymond.

I'll fix this along with the grid work

I've updated the UI patch but will keep it labeled WIP until the license mapping config is in place.

Thanks for all the information @Catrope, and for the suggested change @Amire80. I'd suggest we simplify it even further by removing the span and CSS class altogether - it's only there so we can set the font weight of the number of files, which I would argue is not worth all this hassle. @mwilliams, what do you think?

@sbassett My apologies, I was speaking of risk more generally—that this code already exists on production, so moving it to a new extension doesn't alter the existing level of risk the code presents—not specific to the security review ranking framework.