Yes! Tested and confirmed working.
Fri, Jun 18
Wed, Jun 16
The links in the description no longer worked because we had changed the query param from q to search. I've updated them to reflect the current reality.
Tue, Jun 15
Thu, May 27
Most of it is already in place at https://www.mediawiki.org/wiki/Extension:MediaSearch.
I'll move this to blocked until T265939 is complete, at which point we can update the release status to "stable" and wrap this up.
Wed, May 26
Tue, May 25
May 18 2021
May 14 2021
May 12 2021
Updated ticket to be about Extension:MediaSearch instead of WBMI.
The other WBMI todos are 1/ things that already have tickets (support for complex search types) or 2/ not related to MediaSearch, and have already been looked into & left behind for good enough reasons.
This is blocked on a change in Wikibase (T282654) that's pending review.
Once that lands, this should also be good to go.
Unless there's something problematic about this feature request, I already have a patch for this. We're hoping to be able to leverage this to improve Commons' media search for other languages.
May 11 2021
"Searching" special pages doesn't work: the search API doesn't support virtual namespaces.
It's also not a good target for search anyway: special pages don't have searchable content - they're usually just a UI, or a (temporary/changing) list of content (that actually lives elsewhere)
It looks like Special:Search also doesn't show special pages as a search result.
Doesn't seem to be collecting data (see https://en.wikipedia.org/wiki/Special:Tags). Will investigate.
May 10 2021
IIRC that file doesn’t require any other code, so a simple manual include should probably be a good enough fix, right?
May 7 2021
May 5 2021
May 4 2021
Apr 29 2021
Apr 28 2021
Apr 26 2021
Update: in T274252, we copied the relevant code from said wikibase repo into the mediasearch extension. Once the mediasearch extension gets into production (a few weeks from now), this should be resolved.
Apr 23 2021
We will soon start deploying Extension:MediaSearch without i18n messages, using the stopgap solution described above (T266345#6967371).
We expect it'll take ~3 weeks before everything is up & running and has overtaken the original extension (which will continue to be the place that the i18n messages live)
Once all of that has settled and the risk of having to revert anything has gone away, we'll continue the i18n messages migration as outlined by @Nikerabbit (T266345#6587909) & @Raymond (T266345#7001995)
Does that make sense?
Apr 22 2021
Apr 15 2021
Apr 14 2021
Apr 9 2021
Removing Wikidata tags since this ticket is no longer relevant for them, nor does it require any action on their part.
Apr 2 2021
Mar 31 2021
The query is failing with Lock wait timeout exceeded; try restarting transaction (10.64.48.124)
It looks like, since las Fri (26 March), a whole bunch of these (Lock wait timeout exceeded; try restarting transaction) started to happen.
Mar 30 2021
This search profile has been merged, but is not yet the default. It needs an explicit flag to be triggered, which will allow us to manually verify that nothing unexpected happens once it's in prod.
Moving back to "ready for dev" - all it needs is another patch that replaces the current default config with this one.
Mar 26 2021
Nothing else relies on 5a0bfa9d yet, so this should be a simple revert with no extra impact. LMK if you want me to do so!
Mar 25 2021
The patch that introduces this edit tag has been merged, but I still need to switch it on.
What projects will we be tracking these multimedia edits on? All WMF projects? All Wikipedias? English Wikipedia?
Mar 24 2021
Patches LGTM, but I didn't +2 the one in Wikibase repo (so that WMDE can look it over & approve)
If they prefer me to +2, LMK, would be happy to.
Mar 23 2021
I'm thinking something like this:
Mar 22 2021
This will be part of T265939