Well, at least the two parsers are in agreement here.
https://en.wikipedia.org/api/rest_v1/page/html/User_talk%3ABrion_VIBBER/895522398 vs. https://en.wikipedia.org/wiki/User_talk%3ABrion_VIBBER?oldid=895522398.
Both display [[Wikipedia:Missing Wikipedians|This user is too busy working for Wikipedia to edit Wikipedia]]

It works now. :) Now we can use this for development as well.

Latency has come back down.

Is there a separate task for the mobile-html-offline-resources issue or are we combining that?

This patch should be linked as the actual fix: https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/626178/, reverting changes from https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/626102.

Possibly related to T255876.

In T260684#6441315, @schoenbaechler wrote:

02) Please remove the yellow active state on the CTA, see video below:

I found another difference between the REST API and the Action API. This time in the description field. The REST API seems to prefer the central description, while I think it should prefer the local description instead.

Thank you, @Mholloway, for deploying it today.

These cases don't happen very often because in most pages the first image is wrapped inside a collapsed table (infobox). (At least on the Android app I think the default is to collapse them.)

@cooltey We don't have a fixed schedule for this AFAIK. Someone (maybe @Mholloway?) might try to do this tomorrow morning. I'd say if that fails on Thursday we'd probably aim for Tuesday (Monday is holiday).

@cmadeo There's no ripple effect for this at this time. IIUC the original plan had some ripple effect but it turned out that it wasn't that easy to implement and not visible for long enough since the page gets replaced too quickly.
There are no specific effects for hover (only underlined link) and press (only changing color in addition to the cursor style). (These are the same as for most other links on the page.)

@eprodromou It doesn't seem to work yet. Running the following in the dev console from any website other than https://en.wikipedia.org triggers the CORS error because the Access-Control-Allow-Origin header is not present in the response:

fetch('https://en.wikipedia.org/w/rest.php/v1/search/title?q=cat').then(response => response.json()).then(data => console.log(data));

Is this also for iOS or only for Android? If it's for Android only we need to have a default implementation that @cmadeo is happy with to be used on iOS as well.

Works for me. @apaskulin once that change is deployed you may want to add to the docs that this property may include HTML tags.

I agree that the display title should be included in the response. This would especially help the cases where the first letter of the title is not capitalized, like iOS, eBay, ...
It's a change in the search user experience but I think that would be a very good one IMO.
Whether it's in a new field or changing title doesn't matter to me very much.

This is now displayed in mobile-html, and that is what the Android app uses now for page content. (The older mobile-sections doesn't show it.)

@JoeWalsh, I've updated the task description with the report. Let me know if you have any questions about it.

Filed T259545: What's the reason for the `excerpt` property in the search/title endpoint? and T259547: Include display titles in MW REST API responses.

Similarly, I'm not sure why null is returned for some fields that could be also omitted. This seems to also add to extra values that need to be transferred to the client and parsed on the client side.

Examples from printing as PDF of https://fr.wikiquote.org/wiki/Michel_Henry:

Not sure if we need the excerpt field but the search/title endpoint seems to always return the title in the excerpt property:

Maybe @Pchelolo can shed some light on this?

Updated the description with the report. Shout-out to the web team for their work in this area. //CC: @Jdrewniak @Jdlrobson.

@Aklapper. No, I think this is not about DarkMode but the Page Content Service endpoint mobile-html since our team was tagged.

I believe these character (《》) are not parentheses. They are double angled quotation marks. Background: For the summary extract the code does strip some content inside parentheses. But this is not the case here. The problem is that the Parsoid output already strips the content inside these double angled quotation marks, at least when the first unnamed parameter is used, see my sandbox page and the resulting Parsoid output.

Adding CPT since redirect handling is handled by RESTBase itself.

While debugging this I noticed another issue in the code using action=mobileview (T257632). I've got a fix for that but don't know why action=mobileview returns internal_api_error_InvalidArgumentException. This page seems to be working fine on mobile web: https://zh.m.wikipedia.org/wiki/MediaWiki%3AConversiontable%2Fzh-hans.

Below is a screenshot of a test I ran using http://localhost:8888/en.wikipedia.org/v1/page/mobile-html/Cat, added the class pcs-platform-android to the root <html> tag, and in the dev console ran

pcs.c1.Footer.add({
  menu: {
    items: [pcs.c1.Footer.MenuItemType.lastEdited, pcs.c1.Footer.MenuItemType.pageIssues, pcs.c1.Footer.MenuItemType.disambiguation, pcs.c1.Footer.MenuItemType.talkPage],
    fragment: "pcs-menu",
    editedDaysAgo: 3
  },
  readMore: {
    itemCount: 33,
    baseURL: 'https://en.wikipedia.org/api/rest_v1',
    fragment: "pcs-read-more"
  }
})

In T254490#6272054, @Mholloway wrote:

Just to throw another idea out there before we close out this ticket: any reason not to allow clients to cache this response locally for a while as well? Maybe up to a day (max-age=86400)?

@cooltey @Dbrant @JoeWalsh What do you think about my proposal (see patch above) to remove the title parameter from Footer.add()? Is there a real need for the client to specify the title at all? Just checking to make sure this approach makes sense.

This should be fixed client-side by the Android app.