@Jdlrobson I found this in Triaged but future, do you think the description is an estimate-able state? I wanted to nominate it for upcoming sprint as the design debt card

@Nirzar @ovasileva after some thinking, provided we default this to false (ie. don't enable this anywhere just yet - just do the implementation) I think we can do this whenever - this mitigates the risk of a release. I've updated description to capture this.

default this to false?

@mobrovac @GWicke is there any possibility we can source the content for og:description from RESTBase within MediaWiki? The new summary endpoint will produce better data than TextExtracts so it would be much more preferable to use that. We'd need to do this for every page view (but only once for a cold cache). I'm not sure if there are any other extensions doing this sort of thing.

@Jdlrobson, in general MW can (and does) certainly fetch data from the REST API. However, there are some potential issues if we wanted to fetch the summary on each parse or skin render:

• Availability and performance: We should make sure that an outage of the summary service would not cause an outage or serious performance degradation of MW content. We could set an aggressive timeout, and return an empty description in case of failures. Ideally, we would fetch the summary in parallel with other work, but this would require the use of async HHVM extensions / Hack. The current HTML client in MediaWiki only supports making several HTTP requests in parallel, but does not allow overlapping HTTP requests with other code execution.
• Consistency / race conditions: Most parses happen right after an edit, and often before a summary has been regenerated (there is a race). If MW pulled & cached a stale summary, vandalism affecting the summary could be persisted longer than we would like.

None of these issues would apply if the description was linked from the response, instead of embedded. However, I do not see href support for og:description in http://ogp.me/.

Per https://phabricator.wikimedia.org/T142090#3562366 probably needs a little more analysis.

I'm going to do research on this in the near term to figure out what the path forward is

@Fjalapeno I thought the path forward was to do this change? it's been de-prioritised many times but we should make this happen

@Nirzar the issues are technical. The remaining problem is where does the summary come from? We use a RESTBase service for but Minerva's HTML is generated by MediaWiki.

@Fjalapeno any updated on T142090#4082216 ?
I'd love to see the summary HTML response being embedded as a meta tag in the HTML. This would improve sharing for all our users.
Would this be @Jhernandez domain now?
Is this just as simple as adding an HTTP request in a hook in mediawiki?

@Jdlrobson actually @Jhernandez were just hypothetically discussing using MCR to hold a summary data that is editable by editors. So it is possible to have the summary actually be in the page, but we need product buy in on adding this user facing feature first.

This isn't HTML, but of course HTML can be generated from the structured data, which is probably a good strategy anyways.

I've just noticed the VirtualRESTServiceClient exists so I guess that could be used to inject those descriptions

@Tgr will be looking into it and making a proposal for implementation.

Relying on the external service on the parser pipeline has a bunch of complications so it is not straight forward. We've been talking about it lately and the pros/cons of the different approaches.

RfC published: T213505: RfC: OpenGraph descriptions in wiki pages