daniel updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTIONBackground:
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.
Currently we use the whole entity to track changes
Need:
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 action="" like other wikidata usages are - though is is far less critical than the RC injection.
Problem:
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 once we make it less coarse we should make should weRC injection and CDN purge is still track the descriptionneeded.
This could be done in a few ways:Solutions:
* Provide extensions a hook to register additional usages which are applied to all pages (of a namespace)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 thake 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. These would be taken into account in `AffectedPagesFinder`To avoid this, but not not saved into `wbc_entity_usage`.
* Provide extensions a hook to register additionalwe'd need to be able to distinguish between proper in-content usage, and usages for specific only fro pages_props. TheseThis would be saved in the `wbc_entity_usage` table and handled like regular probably require a schema change to `wbc_entity_usages`.
* Provide some kind of API for this which registers usages as needed (similar to what is done in Lua).# 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 action_info and Special:EntityUsage. Maintaining //subscription// would however not be an issue, This might not be doable without rather nasty hacksas long as the virtual usage is of an asepct of the "connected" item of a page - the wiki will be subscribed to these anywayTASK DETAILhttps://phabricator.wikimedia.org/T173144EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: thiemowmde, matej_suchanek, hoo, PokestarFan, Halfak, Aklapper, RP88, eranroz, Doc_James, GoranSMilovanovic, QZanden, Winter, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
