We had an informal conversation about the task discussing the various implementation proposals and details.

This is how the content is stored validted and served in the wiki, it is not mobile-html service's responsibility to clean this.

• What is the behavior when the response has no pages?
• Is there a problem with title normalization?
• Does /page/related support user pages?

Are the old jquery versions dev dependencies of some tool or actual production dependencies deployed to users? Seems important to clarify the origin of those.

@daniel, given the involvement of the job queue and the async job, could we then use the existing summary service, or is that still considered a loop?

I was checking and there is a few requirements of the information a stateless version of the summary endpoint would need:

It seems clear then that 2) is not a feasible implementation no?

The summary as I understand it for the two proposals:

Thanks for your comment! Very much appreciated.

Ping @sbassett who did work on the security review of the service and has context. Thoughts?

To further explain, /page/mobile-html is like a google map embed, or a youtube video embed, but with wikipedia content in a mobile-friendly way, so it would be super interesting to enable safe embedding on the web if it is possible.

Related: {T227114}

Made open sub-tasks orphan, they can be found under the Product-Infrastructure-Team-Backlog with the PCS filter

ping @WDoranWMF

Hey @MSantos, this seems fixed AFAIK, resolve the task if it is. Thanks!

Thanks for checking Johan.

Let me rephrase

@cooltey I think we have all of them grouped under T227827: Language variant support for page content service and restbase services, let me know if I've missed one or add it yourself as a task. We'll bundle these and try to tackle them all at once when we get to it.

Moving to needs analysis to discuss

We can't control or strip things from editor's styles. The best way to fix this would be to discuss with the editors and try to make the template behave better on mobile viewports.

When done with the fixing the tests if there is more actionable stuff to do move it back to the backlog @Mholloway

Moved to analysis to answer the open questions before going to implementation.

Hey @JoeWalsh @cooltey, can this wait a bit or is it urgent for your current work?

This can be considered done for the current use cases. If there are other things to lazy load we can figure it out separately from the epic.

This has generally been accomplished. Other related tasks that don't block the epic's completion have been orphaned and kept in the backlog with the appropriate priority.