@thiemowmde I think this was originally your suggestion? It seems like the right thing to do, feel free to leave your remarks.

I don't mind much at this point. We said we want to be able to find all pages utilizing extends="…" just in case something goes wrong. But we don't have an actual plan to use this information. So what would be the benefit of making it a category?

I think we should keep it as it is for now, close this ticket, and wait if the community really needs an easier way to find pages with extends="…".

On WMF wikis, [[Special:Search/insource:extends]] would probably do to start.

Change 775906 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):

[mediawiki/extensions/Cite@master] Use a tracking category in addition to a page property to track 'extends'

https://gerrit.wikimedia.org/r/775906

@Lena_WMDE This still seems like a good idea, and cscott has kindly provided a patch to implement the suggestion. The impact is that a new category for pages using book referencing would appear on Special:TrackingCategories, in the same way that the Cite extension already tags error pages with cite-tracking-category-cite-error (listing).

We can remove the page property immediately if we choose this approach, since book referencing hasn't been deployed to production.

Change #775906 merged by jenkins-bot:

[mediawiki/extensions/Cite@master] Replace book-referencing page property with tracking category

https://gerrit.wikimedia.org/r/775906

This is odd.

• After automatic merge, I reloaded https://en.wikipedia.beta.wmflabs.org/wiki/CiteExtendsTests and the tracking category was present.
• I went to the category page and CiteExtendsTests was not listed.
• I edited the page again, using VE. Added some whitespace and saved. The tracking category disappeared.
• Then I edited in the wikitext editor and the tracking category reappeared, this time with the correct reverse link visible on the category page.

Maybe there's some kind of incompatibility with VE?

Unfortunately testing this is exceptionally hard for at least two reasons.

• For some reason clicking the red category link at the bottom doesn't go to the category page as it used to. It appears like somebody had the idea to redirect this directly to VisualEditor. Unfortunately this doesn't make much sense on category pages. A category doesn't need content to be useful. Directly switching to VisualEditor makes it impossible to see what's in the category. I would like to find out which team is responsible for this behavior and ask them to enable it only in specific namespaces.
• The Parsoid code path currently doesn't set a tracking category. I don't know what dictates the behavior of a category on the beta cluster. The old or the new parser? We might need to make the two behave the same to make this behave more consistent.

We will talk about the necessary next steps in demo time, I guess.

Follow-up: we should create the category page with __HIDDENCAT__, or alert the communities to needing this.