Disclaimer - the above works only when viewing the gendered category page. When the page is directly edited or the history page is directly accessed this does not work.

There's the InitializeArticleMaybeRedirect hook in the "root" MediaWiki class that could be used to completely redirect incoming request that match e.g. a certain mapping. This would make it possible to look for page access on gendered category pages and redirect them to the wanted generic form.

Sounds good and definitely ways to hack ourselves into the system "faking" that certain categories exist.

So manipulating search terms in the backend would be possible. On the front-end side we could obviously use JS to do fancy stuff on category searches, but that might then interfere with different UIs and gadgets.

For the first number:
https://de.wikipedia.org/wiki/Kategorie:Frau =>115.072
https://de.wikipedia.org/w/index.php?search=incategory%3AFrau =>114.522

For the autosuggestion in the search form MediaWiki mainly uses ApiOpenSearch in the background. This eventually calls completionSearchWithVariants and completionSearchBackend on the according instance of SearchEngine.

So the general search in core is triggered by using searchText/searchTitle on an instance of SearchEngine. The type of instance is set in the corresponding SearchEngineFactory and depends on configuration. ( by default it's some type of SearchDatabase with CirrusSearch installed it's CirrusSearch.

For instance, are there some aspects that should be tackled first?

Just from quickly looking over it:

Can be tested with https://commons.wikimedia.beta.wmflabs.org/w/index.php?title=Special:ImportFile&clientUrl=https%3A%2F%2Fde.wiktionary.beta.wmflabs.org%2Fwiki%2FDatei%3ABlue_Test.png

In T225693#5311131, @Pikne wrote:

I wonder if would be possible to still show this warning if all present categories are hidden categories? It seems that this warning message is mostly unused now since all files need to include some good template (a license) that usually has a hidden tracking category on Commons.

In T225617#5311114, @Pikne wrote:

Tiny note from translator: comma seems to be misplaced in message "Editing, the source wiki automatically was not possible please follow the instructions above."

Another file to test this with
https://commons.wikimedia.beta.wmflabs.org/wiki/Special:ImportFile?clientUrl=https%3A%2F%2Fde.wikipedia.beta.wmflabs.org%2Fwiki%2FDatei%3ACoole_Ziege.jpeg&importSource=FileExporter

This can be tested on beta now

In T223391#5299264, @Joe wrote:

In T223391#5299032, @jijiki wrote:

@awight @jkroll should we rollout to all hosts?

I think we should, I didn't get to it yesterday. So we should deploy everywhere and then do a rolling restart of php-fpm.

So last message I'm missing:

In T225617#5292129, @JStrodt_WMDE wrote:

@WMDE-Fisch As I understand it, that's included in T226075. @Lea_WMDE Correct?

Just to update this task with the things discussed in the daily today. - The new version of Wikidiff2 will only be deployed to PHP7 servers since HVVM servers will be EOL in the upcoming weeks. The impacts of the new version could therefore not be validate when PHP7 was not explicitly requested.

@JStrodt_WMDE @Lea_WMDE
What text should be presented to the user on a successful import with a successful source wiki template-addition?

Just wanted to mention here, that this also does not work when AdvancedSearch is "disabled" by deactivating JS. So this is probably not a problem, that is specific to the AdvancedSearch UI and probably lies further down.