Assuming this is CI doing this, hence moving to tracking. Feel free to move to our backlog if that is incorrect.

Oh, you're right. Never mind.

@Tgr Do you know why in Special:ApiSandbox one can only select zh-yue instead of yue in the dropdown for language? I had to change the URL to get it to take yue to try it out.

@cooltey I think you don't need to set uselang. uselang is only for message translations, like user visible strings. Error messages and such AFAIU. You could set it to user or content, according to the help text in https://www.wikidata.org/wiki/Special:ApiSandbox.

Yes, noimages can be removed now.

Not sure what's going on there. +1 to @Pchelolo statement about /page/random/title using MW API. It's using the random generator to request 12 random pages and finds the most interesting page title of the dozen results. We did not deploy any new code around this timeframe. During the last week or two we deployed code which should actually reduce pressure on the event loop, and still continuing to do so. this week.

Shouldn't @Jdforrester-WMF be added, too?

Checked both https://pt.wikipedia.org/api/rest_v1/page/mobile-html/Hipotiroidismo/50805952 and https://pt.wikipedia.org/api/rest_v1/page/mobile-sections/Hipotiroidismo/50805952.

@schoenbaechler We can deploy this change today.

action=mobileview is still used by the apps, and by MCS (for the main pages).

@Pcheclolo I was thinking the new PCS endpoint would call the corresponding Parsoid endpoint (internally).

@Pchelolo Yeah, that's why I think this new endpoint would probably be similar to /transform/wikitext/to/html{/title}{/revision}.

I wonder if we should do something similar to https://en.wikipedia.org/api/rest_v1/#!/Transforms/post_transform_wikitext_to_html_title_revision and use the same as the backend service, just run the transformations on top of it.

I hope the project page on mediawiki.org with relevant information also includes:

• an architecture overview showing the major components. I know there's a queue involved. What are the other parts, etc.?
• links to repo(s)
• anything useful for debugging
• how to solve/investigate typical issues

FWIW, looks broken even when RESTBase usage is turned off. In https://en.wikipedia.org/api/rest_v1/page/mobile-html/Fraction_(mathematics) this text looks better, though. So, I think it's probably something on the app side.

App devs/QA, please test the announcements. You'll have to ignore the date and may have to override the country. (There are dev settings for the Android app to do so. I don't know if the iOS app has a similar setting.)

@Mholloway Ok, that makes sense. It's a bit annoying to have to open the section with the actual text, too. So, it's not a clear cut improvement over the desktop URL. I'm fine leaving it as is then.

Now checking the URLs, I think we should consider using the mobile (.m) version of the donation policy link.

Yes, my bad. Had tested PS6 instead of PS8. Now it looks much better:

There are some issues with the image being large and cropped:

@Nirzar I'm not sure what the best way to handle this is. This will affect web a little bit, too, at least by bloating up the CSS. So, I thought it's best to ask for advice first.

Thanks, @schoenbaechler. I haven't diffed the various versions of the body texts but it looks to me that the only difference between the countries are the country names, coffee price, and average donations, like we had last year. Is this correct? Last year we used some server side templating to insert those variables. Also we'll change the text to be HTML (turn the formatting into HTML tags).

Looks like this rule only exists for Vector. Our base CSS endpoint requests Minerva, though: https://en.wikipedia.org/w/load.php?debug=false&lang=en&skin=minerva&target=mobile&only=styles&modules=ext.cite.style%7Cext.math.styles%7Cext.pygments%7Cext.timeline.styles%7Cmediawiki.page.gallery.styles%7Cmediawiki.skinning.content.parsoid%7Cmobile.app%7Cmobile.app.parsoid%7Cskins.minerva.base.reset%7Cskins.minerva.content.styles

The Parsoid HTML actually doesn't have this attribute to begin with. Instead it wraps the <a><img> into a <figure-inline class="mw-image-border">.

In this article the references template comes at the end of the lead section:

{{referências|col=2}}

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

Getting the day of the week from the announcement text is problematic since we don't know what time zone the client is in, e.g. Australia vs UK. I think the day of the week should come from the client based on the local time zone.

Nice. Not that it makes a big difference but instead of caching at the parsoid-access._getRestPageContent() level you could also do it at api-util.restApiGet().

We've been able to create flame graphs with:

npm install -g autocannon clinic
clinic flame --on-port='autocannon -c1 http://localhost:6927/en.wikipedia.org/v1/page/mobile-sections/Cat' -- node server.js

@Mholloway Have you produced any flame graphs? Anything worth sharing in regards to that?

I think there is a benefit of doing I18N in the PCS layer instead of the wikimedia-page-library since then the page library wouldn't have to bundle the translatable strings. I'm going to change the task title and description accordingly. (OTOH we could also split up the wikimedia-page-library into a client bundle and a server bundle.)

I'm glad you found a solution for this. But CC'ing Reading Infrastructure for more visibility.

@Charlotte No updates yet. Is this something that's blocking you? In any case I've moved this to Upcoming so it hopefully gets picked up earlier.

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.
Having said that, I've tried three browsers but cannot reproduce this issue.

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.