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).
Fri, Jan 22
@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!
Wed, Jan 20
Fri, Jan 15
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!
Tue, Jan 12
I've started work on this but will pause until we get the green light to resume work on concept chips.
Mon, Jan 11
Hi @Jcross, here's an outline of our timeline:
Sat, Jan 9
Fri, Jan 8
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?
Thu, Jan 7
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).
Wed, Jan 6
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.
Tue, Jan 5
Dec 22 2020
Thanks for your review, @Etonkovidova!
Dec 21 2020
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!)
Dec 16 2020
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?
Dec 10 2020
Dec 7 2020
Thanks for your response, @Mooeypoo.
Dec 4 2020
Dec 3 2020
Dec 2 2020
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!
Nov 30 2020
Nov 25 2020
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.
Nov 20 2020
Nov 18 2020
I'll fix this along with the grid work
Nov 17 2020
Nov 16 2020
I've updated the UI patch but will keep it labeled WIP until the license mapping config is in place.
Nov 9 2020
Nov 4 2020
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.