Yes! Tested and confirmed working.

In T282654#7145306, @Lucas_Werkmeister_WMDE wrote:

Worth noting that a language parameter was suggested, but rejected, when the API module was first introduced: see https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/611282/4#message-542a6727bc575318493568cade5bd18638daee82 and reply.

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.

PR here: https://github.com/cormacparle/media-search-signal-test/pull/12

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.

Done: https://www.mediawiki.org/wiki/Extension:WikibaseMediaInfo/MediaSearch

In T266067#7086455, @Urbanecm wrote:

I reverted the enabling patch, as it caused T282822: Certain tags are no longer activated by default. Also uploaded a patch that hopefully will enable this feature properly, but that should be ideally CR'ed first.

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.

In T266067#7077972, @matthiasmullie wrote:

Doesn't seem to be collecting data (see https://en.wikipedia.org/wiki/Special:Tags). Will investigate.

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.

"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.

IIRC that file doesn’t require any other code, so a simple manual include should probably be a good enough fix, right?

In T266067#6821153, @nettrom_WMF wrote:

I think I'd like to draw up some different scenarios (using images as the example media) and go through what edit tags end up getting applied, just to make sure I've got this right.

Changes in media	Edit tag
User adds one or more images	mw-add-media
User deletes one or more images	mw-remove-media
User adds two images, deletes one image	mw-change-media
User updates 1 image to a different one	mw-change-media

The last row ends up getting the mw-change-media tag because to the system it looks like a delete and an add. I don't think there's a way to get around that. We do have some ability to measure these if it's done using VE, because if the edit session gets sampled the logged events will reflect that the image was changed rather than added.

From my reading of the parent task, we're primarily interested in understanding how images get added, and the add/change media tags will let us track that. As far as I can tell, this is good to go.

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.

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?

Removing Wikidata tags since this ticket is no longer relevant for them, nor does it require any action on their part.

Moving a copy of this into MediaSearch extension. This way, we are no longer blocked by the wikibase/javascript-api's release schedule (which hasn't had a release in almost a year), and can lose that dependency.

In T266345#6587909, @Nikerabbit wrote:

7. Remove unused messages from WBMI (if not done earlier) and restore syncing
8. ...
9. You can deploy now

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.

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.

In T278429#6949069, @Urbanecm wrote:

Revert uploaded. If you or @matthiasmullie could merge it, it would be best, and we can backport it to wmf.36 soon.

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!

In T266067#6945125, @CBogen wrote:

In T266067#6944514, @matthiasmullie wrote:

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?

All WMF projects, thanks! (unless there’s a reason not to?)

In T258055#6748148, @TJones wrote:

Do we have enough sample queries to build a map of "hotspots" in the ontology?

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?

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.

I'm thinking something like this:

This will be part of T265939