As you seem to have discovered, a lone "Solo" was an English alias.
You have since removed it, but it is still in the synonyms cache (for 1 day, so this should no longer be an issue tomorrow)
After the cache clears (and assuming aliases on Wikidata remain what they are now), "solo city" (as exact phrase match) is going to be the synonym that'll be used.

I have a working solution using Elastic's scroll (https://gerrit.wikimedia.org/r/810282) that does seem to be able to get us past 10k results.

FYI there's a lot of discussion about restoring JS state after coming back in T284021 where that was implemented in search. There are even more tickets to be found on Phab when searching for tasks with mediasearch history.

In T306883#7885661, @Seddon wrote:

Will require a brief spike to work out how we will define image thumbnail dimensions.

Potential solutions we've discussed:

Deployed on ptwiki, ruwiki & idwiki

Good catch; likely caused by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MediaSearch/+/799256

Moving to blocked until the code has been deployed.

Moving to blocked until the code has been deployed, at which point I'll do a few more tests.

Moving to blocked until the code has been deployed, at which point I'll do a few more tests.

These methods should not be removed or things will break.

Initial code has been merged.
Reviews have been deemed unnecessary.
Deployment-related config patches are up & awaiting review.

Stupid question, I'm sure, but would a thumb on the right work?
Something along these lines:

New Vector does #3, a simple centered fill, indeed.
#4 would also be easy to do - we still can't predict what'll fall off, but cropped faces would become a less likely occurrence (though other important stuff might be in the lower parts)

Tech questions have been answered. Moving to "Needs Design" for design questions.

Luckily, figuring out what would be a good thumbnail for a page is a "solved problem" in the form of Extension:PageImages.
It's enabled on most wikis, with the exception of wikibooks, wikisource, wikitech & lockeddown (loginwiki, votewiki). Is also (usually) only works with the main namespace.

Again pinging @Sneha in case any of below is relevant.

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/785247 may be related?

I am hopeful that https://gerrit.wikimedia.org/r/c/mediawiki/core/+/785247 (cc @LucasWerkmeister) will soon resolve this.
That, in combination with presumptuous object caching in RenderedRevision would lead to html-less content being stored in cache.
Here's a quick breakdown of how this would happen:

In T299872#7902062, @Stang wrote:

'wgMediaSearchExternalSearchUri' => [
	'default' => 'https://commons.wikimedia.org/w/api.php',
],

I also just ran into it today with an edit from the default SDC interface.
We're "suddenly" seeing this so frequently and from so many sources now, that this must be a recent-ish regression somewhere.

Question: the "SDC edits" tab mentions "only look[ing] at non-bot edits to files".
MediaInfo submits all edits with a bot: 1 flag via the API (code for statements, code for captions) (the reason is simply "because that's how Wikidata does it")
Does that mean that those edits (via the regular SDC UI) are not included in this data, or does that param have no impact on how a "bot edit" is determined?

We will likely already use search API to grab and iterate over a list of <unillustrated articles that have suggestions> in the other maintenance script to generate notifications (T292147)
I think we can use the same method of gathering the pages, except that we'd also use deepcat (limited to 5 levels deep and 256 categories in total) to find pages within certain categories.
@dcausse would using deepcat for a manually run script (probably only a few times) to fully iterate over all pages within a certain category be problematic for Search?

In T296507#7855083, @Ladsgroup wrote:

Well, sadly this is an issue in all scripts T298485: MW scripts should reload the database config. A maint script doesn't update the list of replicas (to remove the depooled one) as long as it's running.

AFAICT, nothing too much out of the ordinary is happening in this script, so I'm not sure exactly why this is happening, when it's not happening for other scripts.
I did notice this script is not waiting for replication though; maybe that's where some relevant DB connection cleanup happens?

I'm closing this. The only unresolved thing is a Vagrant role, but it probably doesn't even make sense to make that happen (most of the work is in the data pipelines and they end up serving production data, not suitable for consumption on local environments)

In T305615#7845977, @Krinkle wrote:

• There is currently no need for frontend asset bundles (besides icons provided to Echo that Echo displays and ships using its standard and already-used-in-prod mechanisms).

Correct

I added phabricator project information to https://www.mediawiki.org/wiki/Extension:ImageSuggestions

Sorry for the late response - I totally missed all updated on this ticket!
The default branch has been switched to master.

AIUI, this has thus far been observed to occur via:

• HotCat (API wikitext edits)
• GeographBot & DPLA bot (wbeditentity)

• is quicksurveys already installed on both wikis?
• we'll need translations for these things ahead of time
• how do we want to sample this - every visitor, or only a certain percentage?
• where exactly do we want to put this - the home page has a very specific layout and quicksurveys is not something that we can style much; both wikis also vary quite a bit, including text direction, so I guess we need 2 separate "designs"
• do we already have someone with permissions to edit both pages (they're usually restricted) in case we need to edit it to get it where we want it to be (we can also request permissions, just need a headspu ahead of time)
• can we do this? (do we need to consult with community and/or do we have approval)

Code has all been removed & I've just completed cleaning up all previously applied tags to all wikis.

In T300706#7741524, @Isaac wrote:

Thanks for this analysis @cchen and linking to the notebook! Just wanted to point out a small piece of context for others that those median statistics are for just users who added at least one piece of media to an article that month. If you include all the folks who didn't add any media, I assume the median values are 0 (because most users never edit media in their editing work)

• Repo: https://gerrit.wikimedia.org/g/mediawiki/extensions/ImageSuggestions
• Granted Lindsay & Simone access to repo (others should have inherited access)
• Set up CI, with dependency on Echo
• Extension page: https://www.mediawiki.org/wiki/Extension:WikibaseMediaInfo
• Phab project: https://phabricator.wikimedia.org/project/profile/5098/
• Listed as maintainers: https://www.mediawiki.org/wiki/Developers/Maintainers#MediaWiki_extensions_deployed_at_Wikimedia_Foundation
• Vagrant role available: https://gerrit.wikimedia.org/r/c/mediawiki/vagrant/+/766619
• Active on translatewiki.net: https://phabricator.wikimedia.org/T302415

Metrics have not moved. This remains deployed.

1. The relevant part in this summary (that we want removed) comes from Wikibase\Repo\ChangeOp\ChangeOpRemoveStatement::getSummaryArgs; that one must be prevented from returning the summary args (or its direct caller, Wikibase\Repo\ChangeOp\ChangeOpRemoveStatement::apply prevented from using it; further relevant code lacks information about this data that would make this possible without becoming an unstable hack)

Unfortunately, the path down there is rather long:

• WikibaseRepo.ServiceWiring.php constructs Wikibase\Repo\ChangeOp\ChangeOpFactoryProvider (in "WikibaseRepo.ChangeOpFactoryProvider")
• ChangeOpFactoryProvider ends up creating and returning a new instance of Wikibase\Repo\ChangeOp\StatementChangeOpFactory (in getStatementChangeOpFactory), but uses a myriad of private properties in order to do so
• StatementChangeOpFactory creates & returns a new Wikibase\Repo\ChangeOp\ChangeOpRemoveStatement instance (in newRemoveStatementOp)
• Said ChangeOpRemoveStatement is the one where we could adjust the kind of data that it returns, but actually getting there would require extending from, and in some parts largely duplicating, 3 classes in between. It's also not inherently isolated to MediaInfo entities so would need additional checks to ensure things continue to work when both extensions run side by side.

In short: while not entirely impossible to override that way, this would be a hacky job, and a significant maintenance burden for both projects.