Change Details

Currently, article pages contain the JSON-LD linked data schema at the bottom of the article page. Calling this method calculates the description of an article's wikibase item on every page read, taking ~2.5% of the total page load time. Cacheing this value will reduce server load by reducing frequency of this expensive function. **Notes on implementation** - Cacheing is probably best to add in the extension data of the Parser Cache Output - Cache invalidation should only occur when the linked item's description changes **//in the user's language//** - Cache invalidation is probably best handled by adding usage tracking to the article, which automatically subscribes the page to changes for the description aspect of the linked wb item - A side effect of usage tracking is that it also notifies the user in their watchlist when the description changes - This could be frustrating to users since they cannot easily see where the description is used in their page (ld schema is hidden in the html bottom scripts) - Therefore we should add a feature flag (default true) in case we need to rapidly roll back this change - **Update 13/01/25** Pages are already subscribed to the description usage tracking. On the positive side, users are unlikely to see a difference in their watchlists! **Acceptance Criteria** [] The wb item description in ld schema is correct on the first page load [] The description is cached, and therefore not called on every page load [] Invalidation: the description in the schema remains up to date with wikibase changes [] Invalidation: the article's parser cache is //only// invalidated when the linked item's description changes **//in the user's language//** [] The whole implementation should be wrapped in a feature flag, which is default true for initial rollout

Currently, article pages contain the JSON-LD linked data schema at the bottom of the article page. Calling this method calculates the description of an article's wikibase item on every page read, taking ~2.5% of the total page load time. Cacheing this value will reduce server load by reducing frequency of this expensive function. **Notes on implementation** - Cacheing is probably best to add in the extension data of the Parser Cache Output - Cache invalidation should only occur when the linked item's description changes **//in the user's language//** - Cache invalidation is probably best handled by adding usage tracking to the article, which automatically subscribes the page to changes for the description aspect of the linked wb item - A side effect of usage tracking is that it also notifies the user in their watchlist when the description changes - This could be frustrating to users since they cannot easily see where the description is used in their page (ld schema is hidden in the html bottom scripts) - Therefore we should add a feature flag (default true) in case we need to rapidly roll back this change - **Update 13/01/25** Pages are already subscribed to the description usage tracking. On the positive side, users are unlikely to see a difference in their watchlists! **Acceptance Criteria** [] The wb item description in ld schema is correct on the first page load [] The description is cached, and therefore not called on every page load [x] Invalidation: the description in the schema remains up to date with wikibase changes //- this is covered by existing behaviour, including the ImplicitDescriptionUsageLookup// [x] Invalidation: the article's parser cache is //only// invalidated when the linked item's description changes **//in the user's language//** //- here we are not adding any additional impact for the users notification so no action needed// [x] The whole implementation should be wrapped in a feature flag, which is default true for initial rollout //- this is no longer necessary as there is no expected user impact for notifications//

Currently, article pages contain the JSON-LD linked data schema at the bottom of the article page. Calling this method calculates the description of an article's wikibase item on every page read, taking ~2.5% of the total page load time. Cacheing this value will reduce server load by reducing frequency of this expensive function. **Notes on implementation** - Cacheing is probably best to add in the extension data of the Parser Cache Output - Cache invalidation should only occur when the linked item's description changes **//in the user's language//** - Cache invalidation is probably best handled by adding usage tracking to the article, which automatically subscribes the page to changes for the description aspect of the linked wb item - A side effect of usage tracking is that it also notifies the user in their watchlist when the description changes - This could be frustrating to users since they cannot easily see where the description is used in their page (ld schema is hidden in the html bottom scripts) - Therefore we should add a feature flag (default true) in case we need to rapidly roll back this change - **Update 13/01/25** Pages are already subscribed to the description usage tracking. On the positive side, users are unlikely to see a difference in their watchlists! **Acceptance Criteria** [] The wb item description in ld schema is correct on the first page load [] The description is cached, and therefore not called on every page load [x] Invalidation: the description in the schema remains up to date with wikibase changes //- this is covered by existing behaviour, including the ImplicitDescriptionUsageLookup// [x] Invalidation: the article's parser cache is //only// invalidated when the linked item's description changes **//in the user's language//** //- here we are not adding any additional impact for the users notification so no action needed// [x] The whole implementation should be wrapped in a feature flag, which is default true for initial rollout //- this is no longer necessary as there is no expected user impact for notifications//