We need to update the usage tracking table based on the information which user languages a pages has been rendered (and cached) in. Find out how we can get notified when an entity page gets rendered in a "new" language, but avoid updating the database every time a pages is rendered.
Description
Description
| Status | Subtype | Assigned | Task | |
|---|---|---|---|---|
| · · · | ||||
| Resolved | Lydia_Pintscher | T89002 multi-lingual label usage [Tracking] | ||
| Resolved | daniel | T93057 add eu_page_touched field to wbc_entity_usage_tracking | ||
| Resolved | daniel | T93066 Investigate tracking update mechanism for "non-standard language" views. | ||
| · · · |
Event Timeline
Comment Actions
WikiPage::triggerOpportunisticLinksUpdate is indeed called whenever a page is re-rendered for display with a specific set of parser options. It's a good candidate for adding a hook point that would allow us to track user-language specific output of the page.
Comment Actions
Hooking into WikiPage::triggerOpportunisticLinksUpdate may not be sufficient when links updates are triggered via the job queue. Investigate more.
Comment Actions
A simple scheme would be:
- purge all tracking when the page is edited
- add tracking on LinksUpdate, for the current language (these would add up for all languages)
Disadvantage: untracked (and possibly unsubscribed) limbo state, "flickering" subscriptions. Possible fix: A (delayed?) job could be used to unsubscribe.
Comment Actions
The result of this investigation is essentially the scheme described on T96373: Usage tracking update / purging on edit and re-parse (tracking) and, more specifically, T99512: UsageTracking: Use new ParserCacheSaveComplete hook to track usage info.