As the mobile version of search shows the description of item + the page title, we should always track the description of page. Even if the page doesn't explicitly access the description with Lua, the mobile version does. The issue was raised by @Doc_James as there were cases of vandalism in description - and it is hard to track them.
Show changes to wikidata descriptions associated with pages in recentchanges (RC injection), like we do for other changes on wikidata that affect the page. We would also like this kind of "usage" to be visible on ActionInfo, like other wikidata usages are - though is is far less critical than the RC injection.
The current concept of "usage" is: has (potential) impact on the ParserOutput for the page. This is not true for the "usage" of descriptions by the mobile page, as currently implemented.
Similarly, we presently assume that when some information that is "used" on a page changes, that page needs to be re-rendered, in addition to mentioning the change in recentchanges, and purging the respective page from CDN. With information that is pulled in by skin layer code, not during parsing, re-rendering is not necessary, but RC injection and CDN purge is still needed.
There is two ways to tackle this:
- using a materialized usage in in the wbc_entity_usage table, and put the description (or other derived information) into the page_props table. This would be done via some hook that was triggered while (or after) parsing page content. MobileFrontend would then take the description from page_props. We already do something similar with displaytitle and page_image. This would trigger a re-rendering of the page even when only the page properties need to be updated. To avoid this, we'd need to be able to distinguish between proper in-content usage, and usage only fro page_props. This would probably require a schema change to wbc_entity_usage.
- using the notion of "virtual" usage, with a hook in AffectedPagesFinder that extensions can use to indicate that they consider the description of a given item "affecting" some page, even though that relationship is not in the database. Allowing extensions to specify whether they want to trigger (or avoid) a re-parse would still require some refactoring, but no schema change. However, virtual usages would not work seamlessly, additional hooks would be needed for the appropriate integration with ActionInfo and Special:EntityUsage. Maintaining subscription would however not be an issue, as long as the virtual usage is of an aspect of the "connected" item of a page - the wiki will be subscribed to these anyway.
This is potentially relevant for the following extensions:
- WikidataPageBanner (statement)
- In Other Projects Sidebar (sitelinks)
- MobileFrontend (descriptions)
- PageImages (statement)
- GeoData (statement)