I think this might be all? At least, I read through the list of Wikimedia extensions, looked at the gadgets for enwiki and dewiki, and spot-checked a few articles on dewiki to see if templates ever mess with categories.

@Lea_WMDE @JStrodt_WMDE @Jan_Dittrich
This is a question best answered by non-developers, I think.

Friends, I see that this task is in a few "external / watching" columns, so I want to clarify the status as I understand it. I've written a patch which should provide the needed functionality, and I believe it's both a safe migration and not going to damage performance. It might even help overall performance since I've disabled npm's default cache-refresh network calls.

The only extension to mess with OutputPageMakeCategoryLinks so far is CategoryTree, and it will only do so when $wgCategoryTreeHijackPageCategories is true, which is not configured on any Wikimedia sites.

OutputPageMakeCategoryLinks is the only remaining hook that might work for us, but still looking good. It has access to all categories, which in German includes the Frau / Herr category, satisfying our second criteria here.

Another nice hook,

Interesting hook, but definitely not what we need for this project:

• CategoryViewer::generateLink - Doesn't allow us to change the title of a category, only allows us to substitute our own link instead of the results of Linker::link.

For Javascript tools like HotCat, we should think about providing the real, unaliased category name in a data attribute. Migrating the many versions of each tool sounds like an exciting project.

I dumped a lot into the task description, so I want to highlight what I believe is the most promising property so far. Gendered labels can be added to a profession's wikidata item, and then that profession can be added as a constraint on subjects of a category. That can be used to produce a regex appropriate for converting the profession name to its gendered equivalent, whenever it appears in the category label. Exceptions can be encoded directly into the wikidata item for the category, but we should try to keep this to a minimum.

TODO:

• Query how many Wikimedia category items include "human" and an occupation for "category contains".
• Query how many occupation items include "female form of label" values, for German.

I'm concerned that we might not be recording failures, instead the control flow hits the outer exception handling block.

This leaves behind a broken file, with the original file's history, no file contents, and no hint in the logs that it was created by FileImporter:
https://commons.wikimedia.beta.wmflabs.org/wiki/File:File_moving_to_Commons2.png

Either that or T211880: Upgrade grafana-labs.wikimedia.org to Grafana 5.x would be nice to have.

Okay--last detail is that with two boxes, the text will have to be adjusted slightly. Perhaps the error box should say,

The template {{<template name>}} could not be added automatically. Please return to [[the original file]] and add this template manually.

Hi @Addshore, thanks for sharing your insights! Like you pointed out, the historical rollup function isn't applied to current metrics, where consolidateBy is the only way to get a correct graph in many cases. The Wikitech page was helpful, and links to an article that addressed the worst of my misgivings: http://dieter.plaetinck.be/post/25-graphite-grafana-statsd-gotchas/

@Lea_WMDE I'm currently expecting to drop this from the sprint, rather than do half the job... Let me know what you think.

Needs the grafana panel.

Needs the grafana board.

Duplicate of T226509: Inform users if the source wiki could not be updated

Gentle nudge—we're still blocked by these decisions (see T227064). It's still no particular rush, since I think the current behavior is good enough for MVP, but I wanted to flag this as a loose end to tie up.

When we get to the demo, here's a nice edge case which leads to a functional stack of four interwiki prefixes: https://fr.wikisource.org/wiki/Fichier:Alfred_Adler.png . For example, https://test.wikipedia.beta.wmflabs.org/wiki/Special:ImportFile?clientUrl=https://fr.wikisource.org/wiki/Fichier:Alfred_Adler.png .

I'd say we can just reopen it if this ever happens again, thanks!

In T226532#5304289, @JJMC89 wrote:

In T226532#5302655, @JJMC89 wrote:

Current

"fileimporter-delete-summary": "This file is now on Wikimedia Commons (moved with FileImporter).",

...

Having a link to the imported file is important to show where the file ended up since the name may change during the import and/or the file may get deleted.

...

The link isn't for the success message but for the deletion log on the source wiki. The importer will know where the file ended up, but others cannot easily find out if the file was imported under a different name or when it is deleted after being imported.
Say File:Generic name.jpg was being used in My cool article. An admin imports the file to File:Descriptive name.jpg and deletes the original. If the admin doesn't update the file name in My cool article, it would be good for others to be able to know the new name (to be able to fix the article without having to ask the importer or sift through the importer's imports on Commons to find the new file name). Even when the file name gets updated by the importer, someone reviewing edits to the article may want to check that the image is the same one that was originally there.

This is ready to demo on beta commons, but you'll need an account with rights to make the deletion on the beta source wiki.

Minor bug report: We should include a newline before the template, here's an example edit:
https://de.wikipedia.beta.wmflabs.org/w/index.php?title=Datei:Green_Test.png&diff=24510&oldid=22444

I'm thinking about the config syntax, here's a line from the current de.wikipedia.org configuration:

Information|@Description=Beschreibung|@Source=Quelle|Author=Urheber|Date=Datum|Permission=Genehmigung|other_versions=Andere Versionen

We can stay pretty close to the existing syntax, but instead of mapping template parameters to a new template parameter, we would be mapping a template parameter to an ad-hoc Name label, if a new character e.g. & is present. So for example, the task description's rule would become,

Information|@Description=Beschreibung|@Source=Quelle|Author=Urheber|Date=Datum|Permission=Genehmigung|other_versions=Andere Versionen|@&Remarks=Anmerkung

Multiple punctuation is unfortunate.

I've adjusted the patch to detect selenium tests based on the scripts in package.json, rather than testing for directory tests/selenium existence, so we'll be compatible with Wikibase and other unusual hierarchies.

Grabbing this task until July 10th.

In T226532#5302655, @JJMC89 wrote:

Current

"fileimporter-delete-summary": "This file is now on Wikimedia Commons (moved with FileImporter).",

(This should be eventually merged with T226509, but I'll wait until we finish the discussion.)

Assuming we should also track how often deletions fail, maybe in a separate graph.

Tangentially related, please take a look at this language suggestion from @Amire80, https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/FileImporter/+/520203/