Page MenuHomePhabricator

Category members should update after changing the localised name of a tracking category
Open, Stalled, LowestPublicFeature

Description

The parser has some tracking categories, which are defined in the MediaWiki namespace.
But when the message is changed, the categorylinks are not updated.
You have to nulledit (save without changes) each page in the category to get the change also reflected on the pages and in the categories.

Maybe it is possible to start jobs, that do the work, like it is done on a template change, (but for the categorylinks, not templatelinks)

The messages:

  • expensive-parserfunction-category
  • post-expand-template-argument-category
  • post-expand-template-inclusion-category
  • hidden-category-category
  • index-category
  • noindex-category
  • broken-file-category

Having this also for extensions is nice.
I have see the global $wgPagePropLinkInvalidations,
having a global for messages is nice and expandable.

Thanks.


Version: 1.20.x
Severity: enhancement

Details

Reference
bz28876

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:38 PM
bzimport set Reference to bz28876.
bzimport added a subscriber: Unknown Object (MLST).

There is also 'coll-exclusion category title' in the Collection extension

For categories now $wgTrackingCategories exists (see gerrit 112323),
which gives the list of possible effected categories.

Krinkle renamed this task from update categorylinks when tracking category is changed to Category members should update after changing the localised name of a tracking category.Apr 11 2020, 8:04 PM
Krinkle removed a subscriber: wikibugs-l-list.
Krinkle lowered the priority of this task from Medium to Lowest.Apr 11 2020, 8:08 PM
Krinkle subscribed.

The current system assumes categories are part of the wikitext and/or of templates they use and they must be deterministic and/or vary only by parameters that the wikitext or templates themselves make decisions about.

If this logic exists outside the content (for example in a configuration variable or localisation message) then updates are not tracked and there is not really existing mechanism we have for how such things could be tracked or updated.

The only answer for this right now is that site administrators must not do this without system administration involvement. who can then use scripts like maintenance/refreshLinks.php to re-parse all pages in the old category. That is actually a functional workaround so perhaps that's good enough given this happens very rarely. Automating this would pose a significant risk in terms of load.

The category is part of the wikitext, because the error is in the wikitext parsed by the parser.

The categories are not part of the wikitext (when there are added to the wikitext, that is an fault from the wiki user).

It just about starting a refresh job when a mediawiki message is changed, which is in the list of tracking categories. Changing mediawiki messages is limited to a user group, so the issue with the load seems not a big issue.

maintenance/refreshLinks.php is a workaround, when it allows to get a list of pages to parse from a category name

Krinkle changed the task status from Open to Stalled.Apr 12 2020, 4:45 PM
Krinkle added a project: Platform Engineering.

refreshLinks.php has an option --category for that purpose.

And even better, refreshLinks.php also has an option --tracking-category for the express purpose behind this task. It turns out that tracking categories are more complicated than just pages in a category because they can use variables like {{NAMESPACE}} inside the message, and this option expands the list to cover that.

Making edits to some of the MediaWiki namespace pages automatically queue a recursive job like this would require a new kind of job to be created for "tracking category" type, which does not yet exist. Adding that ability to the software is non-trivial and comes with maintenance cost and load risk. I will leave it to Core Platform to decide whether this is something they want to add to the "Save edit" pipeline in terms of complexity, or whether the occasional Wikimedia-maintenance-script-run task is an acceptable workaround.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:02 AM