Deduplication would only fix it for subsequent occurrences of references with <cite> elements. The first one would still have the <style> element coming shortly after the <cite> element.

What caused the 5x increase in requests?

Just saw https://github.com/wikimedia/restbase/pull/1074, and am wondering if that is enough to cover also this task or should we continue promisifying CPU intensive tasks?

Wow, in the example one Accept-Language value is capitalized, the other all lower-case. Which way do we go with?

As mentioned during apps standup I recommend the Android app at least to incorporate the PR for the page library. In the meantime I'll also look into moving the style tags inside reference lists towards the end of the document (since the reference lists tend to come near the end of a page and are collapsed by default anyways).

@ssastry: @Dbrant makes a good point in T206527#4659479. The parsoid output of a page with cite tags has unnecessarily duplicated content, while in the PHP parser version duplication works.
Compare running document.querySelectorAll('style[data-mw-deduplicate="TemplateStyles:r861714446"]').length on https://en.wikipedia.org/wiki/Cat#References vs. https://en.wikipedia.org/api/rest_v1/page/html/Cat#References. While the former has only one occurrence, the latter has 278.

As @Pchelolo, I also doubt that a cache would help us in production, considering our service architecture having many worker. Hitting the same page in your ab test is not indicative of production behavior.

Yes, local override should be taken into account (eventually). Possibly it's good enough for a prototype without it but eventually this needs to be taken into account. I think the MW API should be able to indicate if the description is central or local and if possibly filter on it, too.

According to the meeting we had last week it sounds like we would like to proceed with setting up I18N for the wikimedia-page-library.
Adding @siebrand to see what we have to do to get I18N and TWN sync set up for this JavaScript project.

merged

@JoeWalsh The apps already know the translated strings, which they pass in over the JS bridge. What I really want to accomplish here is to have these values already know on the server-side, so that we're getting the DOM rendered as much as possible on the server-side. The server already knows the main language from the wiki domain and any wanted language variants could be known on the server via the accept-language header.

Maybe related to T53003?

I think the main thing that's missing is this:

@Jhernandez Thanks for spotting this. I've fixed the formatting.

Blocked on T205550.

I agree with @Mholloway to add on-wiki POTD for the ones that have some other than what Commons provides, and fallback to the one from Commons where it doesn't.

https://github.com/wikimedia/wikimedia-page-library/pull/160

Shouldn't we be doing x-request-id (T201409) instead?

An example of where this came up is T195838.

It would be good to add some acceptance criteria to this so we can derive some test cases and know exactly what e.g. MCS needs to do.

@Mholloway screenshots or it didn't happen. ;)

https://github.com/wikimedia/webextension-readinglists/pull/12 and https://github.com/wikimedia/readinglists-extension-safari/pull/8 to limit handled projects to Wikipedia and Wikivoyage are merged. Still need to check the namespace.

My vote goes for removing all sites except WP and wikivoyage.

@Mholloway Any concerns about moving this to Specs/Announcements/0.2.0?

@Mholloway Thanks for checking this out.

When the Accept-Language header stuff is ready we could also add an x-ample which triggers the vary header of the response having Accept-Language also.

@Mhurd The date in your request is too new. The daily results have not been generated for today. Try yesterday's (https://wikimedia.org/api/rest_v1/metrics/pageviews/per-article/en.wikipedia.org/all-access/user/Dog/daily/20180905/20180905) instead.

@Mhurd I wasn't aware that the iOS app made direct requests to the PageViews API.
@jcrespo Are most of the 404 responses here from requests to /api/rest_v1/metrics/pageviews?

Another idea is to temporarily turn on debug to true in the config.prod.yaml, similarly to how it's done in the config.dev.yaml[1]. This would show also outgoing requests (to backend services, like MW API or other services in RB). Check it out locally first to see if there would be any useful info there.

The feed content includes a lot of things already stored in RESTBase (Parsoid content of pages, PagewView API, summaries of included pages, ...). Are the hosts getting updated properly depooled? Should MCS use a different hostname to refer to content in RB?

For this you need a wide enough device, e.g. an iPhone 6 Plus in landscape mode or an iPad,
then open the Cat page,
open the collapsed infobox table

The page library PR has been merged and version 6.1.3 with it published.

@Krinkle I added you and @Jdlrobson mainly to increase awareness of how MinervaNeue CSS is used downstream by the apps for future CSS changes, and possibly review my PR that tries to fix this issue if you'd like.
For the future it would be great to get a heads-up of major changes in CSS (esp. for tables) or get some ideas for better testing this wrt to the apps usage. This will be even more important in the future when the apps get the CSS from the server instead of bundling with the apps. (But even with some testing when the apps update their CSS bundles this fell through the cracks.)

I believe the issue started with this patch: https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/428868.