@matthiasmullie, you mentioned there's a hack to avoid this - seems like we should go that route. What are the down sides?

Below is an attempt at explaining what kind of data is used, how & why, without getting too technical.
If anything is too detailed or not detailed enough, or plain unclear, LMK and I'm happy to try to accommodate.
Feel free to edit in any way, and post wherever it may be relevant.

And one last thing to remember: we chose this heuristics implementation because it was the only viable one in a short amount of time.
It is flawed to some extent both in results (Wikidata ontology can be weird and inconsistent) and performance (we should be careful with these SPARQL queries)
This implementation is fine for limited usage on Special:MediaSearch and will allow us to evaluate the feature, but if we ever want to scale it up (to the point of it being served by default for most casual searches), we will have to consider alternative implementations.
In other words: let's instrument this, and if it's found to be used extensively, we should start working on more sustainable alternatives.

We're using the search API, which already exposes suggestions (&srinfo=suggestion.) E.g. https://commons.wikimedia.org/w/api.php?action=query&list=search&srsearch=einstn&srnamespace=6&srinfo=suggestion&mediasearch=1
Sadly, it's not exposing any such data when used as generator (which we do), and changing things to add that kind of data likely isn't happening (see https://gerrit.wikimedia.org/r/c/mediawiki/core/+/394120/1#message-1e5569733143789c304edc5d8bc1c7fc17362e15)

Most heuristics in spreadsheet have been implemented (strikethroughed)

The relevant tickets are already in the ticket description; I can't think of any others not already listed.

In T259896#6474685, @CBogen wrote:

@matthiasmullie will this affect file namespace searches on the wikipedias?

QuickSurveys only allows 1 question, so we either run separate surveys, or so an external survey. (Since @Ramsey-WMF said we don't have to ask both at once, I assumed we'd do 2 separate?)

Yes for VE.

Another thing to consider would be T258055: [L] [SPIKE] Investigate traversing entities tree to include more entities with more detail & feedback is very much welcome (scroll to last post for findings)

Short summary:

@CBogen @Ramsey-WMF Does T258419#6447736 (screenshot and caveats) look acceptable for us? (If not, we're likely in for a sizeable refactor of QuickSurveys, or consider alternative solution)

This was actually blocked by T258063. Both of the above links now have (almost) the exact set of results, so this is fixed.

In T258063#6462579, @Nikerabbit wrote:

Please inform translatewiki.net when adding or removing translation files. This way we can do changes beforehand before they show up in our error logs. You can tag translatewiki.net or ping @Raymond directly in Phabricator or Gerrit when it is about MediaWiki core or extensions.

AFAICT, VisualEditor already performs the perfect API call that will receive mediasearch results once the new profile is activated by default (so: blocked on T262271)
Work for this ticket will likely be a simple verification.

Quick status update: we have 3 patches that will help the situation.

Do you have a specific example where this occurred?
I'll close this because I'm fairly certain that the fix for T263126 will also fix this, but please re-open if you do find examples where that patch didn't resolve this.

In T263047#6469550, @Gilles wrote:

Once the lock is removed by whoever can (I don't have the right linux permissions, it seems), please deploy the backport:

Note: not number of words, as non-latin languages behave differently & certain words (stopwords) are omitted. We need the tokens from elastic.

Yeah, I guess we don't need this any longer then.

Media search is essentially 2 separate parts:

1. there as a new, media-focused, UI which uses the search API
2. there is a multimedia-specific search profile to alter the actual elastic query

After of next week's deployment train hits Commons (Wed 16 Sept, if things go well), both will be wired together & can be tested at https://commons.wikimedia.org/wiki/Special:MediaSearch?quickview=1

I've only looked at some of the profiles briefly, but it looks like:

@AnneT I'd suggest to use the popular_inclinks profile for now.
popular_inclinks_pv seems to add only a minor score, but popular_inclinks does have a massive impact.
That one's only based on incoming links, though, not incoming links + pageviews; but a good enough proxy for 'popularity' none the less.
We can then use T262511 to further investigate the impact of these rescore profiles.

This is probably blocked on (or at least influenced by) T262522

IMO it's quite likely that these are simply (very late) resubmissions from Special:Upload after the original upload failed (in which case the file got stashed), but the resubmission took long enough that the stashed file got cleaned up in the meantime.
See T38587#6267136 (duplicate) for more details.

1 thing is missing from your links: to be able to use the media search profile right now, you'll need to add ?mediasearch=1 to the url (and API sandbox keep stripping it, apparently)

Does this look ok?

This is no longer blocked now that T258063 has a working patch.

This has taken too long to land & we no longer need this intermediate step because the Vue work has already been merged.
I've worked around the blocker for T258063, which makes this ticket obsolete.

This was blocked because the media search profile is not active unless explicitly requested (via mediasearch query param). This will not change until A/B test results confirm that we're not turning the search results into a total mess.
This ticket blocks a few others, though (e.g. ability to sort), so let's get this moving...

And who do we want to survey (what are the criteria the audience)? Any random commons visitor? Anons? Or experienced with over X contributions? Only visitors of Special:MediaSearch? Or visitors of one of SDC's talk pages?

What is/are the question(s) we'd like to ask?

The existing Wikibase datamodel objects continue to be supported upstream and there are no plans of removing them.
We are no longer actively working on this much, so there is no reason to pursue this any further & we'll stick with what we've got.

The existing Wikibase datamodel objects continue to be supported upstream and there are no plans of removing them.
We are no longer actively working on this much, so there is no reason to pursue this any further & we'll stick with what we've got.

Not worth pursuing ATM. Let’s figure this out and reconsider options if/when this becomes an actual issue in the future.

We can simply grab the contents of the input field (which also contains the existing search term) instead of grabbing it from the url. That also covers the case of users starting new input before JS has had a chance to load.
The main reason that people will be able to start inputting text is the latency of having to transfer the JS bundle, which is now covered.

Based on the simplistic example query pasted earlier, it looks like it takes somewhere in the 300-600ms range to find nested statements (capped at 3 levels deep, limited at 750)
This will vary slightly based on the exact query (and we're going to need to keep it as simply as possible), but this is the ballpark.
We should probably cache that result (entity tree) for a short time so that we won't have to do it again as users continue to load additional pages of results for the same search term.

The initial render (from PHP) & the JS takeover are getting way out of sync.
There's a significant FOUC (there already was, but it's getting worse now that the UI is drifting apart), changes in functionality that we need to think about (can we skip the filters in no-JS), tabs are about to change, and the actual initial results (that are passed along from backend to frontend) are already based on different calls (filetype=bitmap vs filetype=bitmap|drawing)
We probably need to prioritize this - we should keep the initial render in sync (to some extent) when we make changes in JS, but it is no longer in a state where that is feasible.

Closing per rationale in above comment.

After some quick tests, elastic seems to respond just as fast with (up to) 50 (current situation) or 750 statements. But there's an upper limit of 1024 clauses ATM (too_many_clauses: maxClauseCount is set to 1024)

"most recent" and "most viewed" imply things about the implementation.
We can rescore results, but that's no guarantee that they'd be in that exact order, because we don't necessarily want a super popular image that is a poor match for the search term to outrank a near perfect match that is a little less popular.
I propose we rephrase the options to "relevance", "recency" and "popularity" to be less suggestive about the exact implementation.
PS: if we're going with popular: there is a rescore profile that uses both pageviews and incoming links to rank things by - that would probably be an even better one to use.

Note: the "quick & simple analysis of preference from interleaved A/B tests" as described at the end of this issue's description should be good enough for the test that we'd like to run next week.
Knowing the preferential set of results is good enough to drive our immediate work.

We are working on improving search results on Commons by including structured data (captions, statements) etc.
It would be extremely useful (essential, actually) to be able to tell the impact of changes, to confirm that we're moving in a good direction.

Oh, I somehow misread the order of actual & expected results, my apologies! I'll look into this!

I'm not sure I completely understand this issue.
If - as described - a campaign has a start date in the past and end date in the future, it's currently active (has already started, but not yet ended), right?
In such case, I would expect the whileActive message to be displayed, and afterActive shouldn't be displayed until the end date has reached.
Can anyone explain why it has to be the other way around, or where my understanding is wrong?

Note: I believe (some of) this already exists via Cirrus boosting usage of certain templates/categories, in which case we might simply be able to use that.

T257295 has to go first - that one replaces the existing MediaSearch API logic to make it use the default search API (with MediaSearch profile). That way we can start to use the new backend without having to make & synchronize changes to the frontend.

Captions, wikitext & filenames will indeed all be included when searching.
However, "paris" should not be matched when searching for "iris" or "irises". Do you have an example of where that was the case?
Most of the not too obvious matches I could find for "iris" were because the wikitext contained the photographer's name, "iris".

Quick brain dump before the weekend.

In T245861#5917800, @Multichill wrote:

I don't think many oppose, only a few loud mouths.

Sadly, it’s not (consistently) in structured data (yet?)
It lives in wikitext & Extension:CommonsMetadata extracts it on-demand (but it’s not stored anywhere)
I suspect there’ll be hooks in both of those methods, where CommonsMetadata could then add those fields to?

The latest is actually intentional in this case, because it's only used in tests and we want to ensure that those run against the latest code (that matches what is automatically going to be on production later on)
That said, if it's causing issues elsewhere, we can pin it to a specific version. That patch LGTM - do you want it merged?