Just a reminder about the Meets today:
On Fri, May 5, 2023 at 8:17 AM Adam Baso <abaso(a)wikimedia.org> wrote:
Hello Again World,
The Google Meets for live discussion about MCS decommissioning will be
held during the upcoming week for those needing assistance. There are two
sessions on Thursday, 11 May 2023, and we hope they will provide for decent
timezone coverage. Please see details below and add an entry to your
calendar if you would like to meet synchronously this way.
Additionally, as noted before, there will be Content Transform Team
members at the Wikimedia Hackathon 19-21 May 2023. Ask around if you are
there, and consider helping others who may be transitioning their
components off of MCS.
If it is better for you to discuss asynchronously, please as always feel
free to use https://www.mediawiki.org/wiki/Talk:Content_Transform_Team
We have reached out to a handful of additionally identified MCS re-users
where there were some clues in the User-Agent fields from the web request
logs. If you or someone you know has a bot, gadget, user script, Scribunto
Lua module, or extension* (or other component, for that matter!) using MCS,
we would appreciate your help in further spreading the word and helping
migrate active use.
== Google Meet Details ==
Thursday, 11-May-2023 - 1100-1200 UTC (0400 - 0500 San Francisco)
Telephone numbers in case of audio issues:
Thursday, 11-May-2023 - 1800-1900 UTC (1100 - 1200 San Francisco)
Telephone numbers in case of audio issues:
Please refer to https://support.google.com/meet/answer/7317473
requirements for using Google Meet.
Adam Baso, on behalf of the Content Transform Team
is not suggestive of unknown things.
is not suggestive of obvious on-site user generated content / code (a regex
search seems to possibly be too exhaustive as these searches are inherently
slow, but in theory would not turn up anything extra anyway as a simple
string search should be sufficient). It is certainly the case that there
are repos discovered via
, but it's a bit of
a stretch to determine reliably if things are even running and where. As
this message is going out, it dawns on oneself that
repos could be a target for searches, but
this may require enabling global search
<https://docs.gitlab.com/ee/user/search/> (will need to check with a
GitLab admin if that can be done outside of an EE installation easily) or
perhaps a scripted search across each individual repos...TBD.
On Wed, Mar 22, 2023 at 4:45 AM Adam Baso <abaso(a)wikimedia.org> wrote:
TL;DR: The legacy Mobile Content Service is going
away in July 2023.
Please switch to Parsoid or another API before then to ensure service
I'm writing about a service decommission we hope to complete mid-July
2023. The service to be decommissioned is the legacy Mobile Content Service
("MCS"), which is maintained by the Wikimedia Foundation's Content
Transform Team. We will be marking this service as deprecated soon.
We hope that with this notice, people will have ample time to update
their systems for use of other endpoints such as Parsoid  (n.b., MCS
uses Parsoid HTML).
The MCS endpoints are the ones with the relative URL path pattern
/page/mobile-sections* on the Wikipedias. For examples of the URLs see the
"Mobile" section on the online Swagger (OpenAPI) specification
documentation with matching URLs here:
== History ==
The Mobile Content Service ("MCS") is the historical aggregate service
that originally provided support for the article reading experience on the
Wikipedia for Android native app, as well as some other experiences. We
have noticed that there are other users of the service. We are not able to
determine all of the users, as it's hard to tell with confidence from the
The Wikimedia Foundation had already transitioned the Wikipedia for
Android and iOS apps to the newer Page Content Service ("PCS") several
years ago. PCS has some similarities with MCS in terms of its mobility
focus, but it also has different request-response signatures in practice.
PCS, as with MCS, is intended to primarily satisfy Wikimedia
Foundation-maintained user experiences only, and so this is classified with
the "unstable" moniker.
== Looking ahead ==
Generally, as noted in the lead, we recommend that folks who use MCS (or
PCS, for that matter) switch over to Parsoid for accessing Wikipedia
article content programmatically for the most predictable service.
The HTML produced by Parsoid has a versioned specification  and
because Parsoid is accessed regularly by a number of components across the
globe tends to have fairly well cached responses. However, please note that
Parsoid may be subject to stricter rate limits that can apply under certain
At this point, I do also want to note that in order to keep up with
contemporary HTML standards, particularly those favoring accessibility and
machine readability enhancements, Parsoid HTML will undergo change as we
further converge parsing stacks . Generally, you should expect iteration
on the Parsoid HTML spec, and of course as you may have come to appreciate
that the shape of HTML in practice can vary nontrivially wiki-by-wiki as
practices across wikis vary.
You may also want to consider Wikimedia Enterprise API options, which
range from no cost to higher volume access paid options.
== Forking okay, but not recommended ==
Because MCS acts as a service aggregate and makes multiple backend API
calls, caveats can apply for those subresources - possibility of API
changes, deprecation, and the like. We do not recommend a plain fork of MCS
code because of the subresource fetch behavior. This said, of course you
are welcome to fork in a way compatible with MCS's license.
== Help spread the word ==
Although we are aware of the top two remaining consumers of MCS, we also
are not sure who else is accessing MCS and anticipate that some downstream
tech may break when MCS is turned off. As we are cross-posting this
message, we hope most people who have come to rely upon MCS will see this
message. Please feel free to forward this message to contacts if you know
they are using MCS.
== Help ==
Although we intend to decommission MCS in July 2023, we would like to
share resources if you need some help. We plan to hold office hours in case
you would like to meet with us to discuss this or other Content Transform
Team matters. We will host these events on Google Meet. We will provide
notice of these office hours on the wikitech-l mailing list in the coming
weeks and months.
Additionally, if you would like to discuss your MCS transition plans,
please visit the Content Transform Team talk page:
Finally, some Content Transform Team members will also be at the
Wikimedia Hackathon  if you would like some in-person support.
Adam Baso (he/him/his/Adam), on behalf of the Content Transform Team
Director of Engineering