Talk:Content Transform Team

Mobile Content Service Decommission
Thank you for the early announcement that the Mobile Content Service (MCS) is going away in July 2023. Currently I am using this API on an educational mobile app that allows users to learn and research history events linking to more detailed Wikipedia articles. To better understand what the alternatives to continue this service are, I would need your help and I will start with a couple of questions.

- Is the Page Content Service (PCS) be supported on the longer run? The current (MCS) returns the page divided into sections, in a json format, and I was wondering if such a feature exists or could be added to the PCS.

- The Parsoid API page (Parsoid/API) has a notice that the data can only be accessed through the RESTBase's REST API. Is this the PCS data-parsoid endpoint?

- I tried to access the data-parsoid data to see the format but I only get a 404 "Not found." error. Is there a way to get some help on this topic?

Thank you and looking forward to any update on the subject! Alexandru Ene (talk) 10:15, 24 March 2023 (UTC)


 * Thank you @Alexandru Ene for the questions and exploration. And thank you for helping people learn and research history events linking to more detailed Wikipedia articles!
 * We do anticipate continued support of PCS; it may be subject to fairly rapid changes, though, and it presumes its clients are native Wikipedia for Android and Wikipedia for iOS. Although we try to compose the software in a way that decouples presentation from logic, the level of coupling in practice for the user experience can result in glitchiness if, for example, there are assumptions about client-side operations on the content (e.g., native webview-mediated JavaScript execution on the content that is material to the fundamental presentation and interaction with the content).
 * We're not presently planning to replicate the JSON-based section content approach into PCS. However, there are  tags in the PCS   route's output (as well as Parsoid upon which PCS depends, cf.   route).
 * It is possible, although not in the immediate plans, that we may desire to consolidate the approach on base HTML for the apps that's closer to the web platform on mobile web or desktop web - for example, via Parsoid HTML directly, as there has been some technical exploration of this. What this would mean is that we would move some pieces from PCS to Parsoid and other pieces strictly to the native app clients. But as I say, it's only a possibility, and not in the immediate plans, as it entails a number of complicated changes to do such a thing with a bunch of tradeoffs for software delivery across teams. We would communicate any such plan of a migration similarly to how we're communicating the plan with MCS if we were going to go with such an approach.
 * I believe the  thing you're looking for is something like this if you were using  . This is part of the mainline Parsoid implementation, not PCS, and it's considered purely internal (so prone to breakage) - so, if it's just section data you were looking for the   tags may be simpler and not require an extra request, just a DOM query selector.

Notice how the URL contains a revision ID and a timestamping ID separated by a slash. As an example of getting this info (I'm using a HEAD request via the  flag here, not a GET with an ommitted , just for illustrative purposes) - see this:
 * ABaso (WMF) (talk) 11:17, 24 March 2023 (UTC)