The same also works on commons with the "normal" title change page.

The above PoC gives a good rough understanding for where changes to display the refined parts must happen. The parameter itself could easily be forwarded to the model and then used in the code printing the preview.

Some things were done here already to wrap up the technical aspects of the gendered categories feature. Keeping this task open for questions that might come in from @JStrodt_WMDE when working on the communication part of the topic.

What happens if a page with book references is opened with the VisualEditor

Using the current PHP only PoC patch[1], the VE cannot make sense out of the refines attribute in the ref tag and introduces new footnote entries for these tags in the WYSIWYG preview :-(

In T227780#5430535, @awight wrote:

@WMDE-Fisch please undelete this file when you have a moment: https://commons.wikimedia.beta.wmflabs.org/wiki/File:File_moving_to_Commons2.png
This is a zombie created by the importer, we should be able to learn things from the ruins.

And here's the line responsible in Scribunto:

So looking into the pages affected it seems, this was always happening on pages in the Module namespace, what makes sense since we do not have a preview button when editing modules there. - I'll add a patch that checks if the button exists before we try to disable it.

@Nirmos if you're fine with it, I would change the ticket description to reflect the bug I'm describing above. - I did not really find a ticket for that so far so it might be good to use this one.

The original issue described in this ticket describes a different problem. The example diff [1] above looks a bit confusing due to the new line that was removed, while also edits in the paragraphs were done. - When lines are removed or added the diff algorithm does not align these changes very well in some cases.

In T164795#5411230, @Nirmos wrote:

Things are still broken. For a minimal test case, see for example https://sv.wikipedia.org/w/index.php?diff=46200983
The .diff-deletedline is further down than .diff-addedline, despite the article only containing one line, and that's the line being changed. It didn't use to be like this, but it's been like this for quite some time now.

This was done already and is part of the newer Two-Column-Edit-Conflict-Merge UI.

This was done already and is part of the newer Two-Column-Edit-Conflict-Merge UI.

In T186616#5410708, @Aklapper wrote:

@WMDE: Isn't this the case already? Is this still "currently in sprint" after 18 months? :)

In T186615#5410705, @Aklapper wrote:

@Lea_WMDE: Hi, what is this task about? What is "previously"? Could you please provide a task description if this is still a valid task? Thanks!

@Aklapper MIght also be a duplicate of T44669: Diffs of trailing newlines addition and removal don't work properly ?

In T225656#5406798, @David_Biddulph wrote:

Still getting spurious edit conflict flagged even after beta feature switched off,

This just turned up in my inbox and I wanted to note, that the original problem described in the ticket does not exist anymore. At least I could not reproduce it. - I guess we fixed it while working on the reference previews.

In T226513#5364445, @Lea_WMDE wrote:

What is there left to do for the completion of this ticket?

In T227358#5357632, @Lea_WMDE wrote:

It looks to me as if the message now says "at" instead of "as"?

I just had a quick look at this to check if it's a wikidiff2 specific problem. Seems not to be the case.

POC snippet

public static function onSpecialSearchResultsPrepend( SpecialSearch $specialSearch, OutputPage $out, $term ) {
	global $onSpecialSearchResultsPrepend;
	if ( !$onSpecialSearchResultsPrepend ) {
		$onSpecialSearchResultsPrepend = true;

POC snippet

public static function onInitializeArticleMaybeRedirect( Title &$title, &$request, &$ignoreRedirect, &$target, Article &$article ) {
	if ( $title->getNamespace() !== NS_CATEGORY ) {
		return;
	}

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.