Probably can be closed now.

Deployed a few minutes ago deploy/2019-03-13/5f8e4e61.

Deployed a few minutes ago deploy/2019-03-13/5f8e4e61.

Deployed a few minutes ago deploy/2019-03-13/5f8e4e61.

@Jhernandez Should we make T177433 an Epic?

The place to change this in MCS would be the processing script [[ https://phabricator.wikimedia.org/diffusion/GMOA/browse/master/processing/definition.yaml$15-16 | definition.yaml ]].

@JoeWalsh app:// looks good to me.

My current understanding based on the discussion we had today is that the output of this endpoint should include:

• all linked CSS
• all linked JS
• all URLs of <img> tags (media endpoint only has a subset of images because that one is meant for gallery)
• possibly links to video and audio files, too?

Great. That's much easier. (Yes, I was thinking about the DOM transformations you'd do when changing the URLs for reading and writing external links for offline use. Not sure if you do for both or just one way.)

Reading through old comments and adding my 2 cents:

Bummer. That going to be tough. I don't think Android needs something like that since they use the same networking library (and interceptors) when they save for offline. Would it be possible to instantiate a hidden WebView somewhere to still get to run JavaScript DOM transformations?

@JoeWalsh I think this should work. Thank you!

Bumping that one upstream to Parsoid.
It works on https://bm.wikipedia.org/wiki/Seshel but the Parsoid output (https://bm.wikipedia.org/api/rest_v1/page/html/Seshel) uses a different file name for the svg image.

We should fix this after we've come up with a strategy for decoupling app/mobile-html CSS from MinervaNeue CSS.

I've been thinking we could add a JS function in the page library which would get all the resources needing to be saved for offline.
It could even do the DOM transformation before writing the file to disk if the replacement is predictable. For reading while offline we could also do the same for the opposite way, which would get invoked after reading the stored page from disk.

Mholloway deployed about an hour ago. I purged https://meta.wikimedia.org/api/rest_v1/data/css/mobile/base and many languages https://<lang>.wikipedia.org/api/rest_v1/data/css/mobile/base, for older versions of the Android app which still use the base CSS from WP.

Yes, we should bump the version number when we switch to Node 10. Do you propose to add something else Unicode specific there as well?

@Jdlrobson Making the apps' CSS dependent on what parser was used to generate the HTML makes sense to me. So, I guess for the iOS app they are better off using what they have right now until they switch to mobile-html. For the Android app since it's using HTML generated by Parsoid (mobile-sections, later mobile-html) we probably should make sure that the https://en.wikipedia.org/api/rest_v1/data/css/mobile/base CSS output works well at least with Parsoid generated HTML. Having said that, unfortunately we can't drop the legacy parser based CSS since the Android app still uses legacy parser output for some fallback cases (e.g. Chinese language variants).

Plan to move to PCS anyways.

Is there a convention for naming the HTML attribute to mark the pronunciation source?

Template:HeatTable has a fixed height attribute of 200px. I think this is what causes this issue. Not sure why this only affects when collapse table is turned on, though.

I purged the URLs in the form of https://[lang].wikipedia.org/api/rest_v1/data/css/mobile/base for all Wikipedias on this list: https://phabricator.wikimedia.org/diffusion/GMOA/browse/master/private/languages_list.json.
As mentioned on IRC consider using meta.wikimedia.org instead of the language specific Wikipedia in the app for the base CSS.

@Jdlrobson The revert would be done at the PCS (base CSS) level, not MinervaNeue. Reverting T214714 would result into changes in the H1/H2 headings. Any help with that would be appreciated.

@Dbrant. Yes, we could do that. Let me know when you are done trying to find a fix. I'm going to look a bit, too.

Hmm, I can repro in the Android app but not with https://en.wikipedia.org/api/rest_v1/page/mobile-html/Cat, which is surprising. (I manually added class="pagelib_platform_android content-ltr pagelib_theme_dark pagelib_dim_images" to trigger dark mode using Chrome inspector.)

Looks like this enwiki change triggered the issue.

PCS has a good amount of unit tests for this. Might be worth porting those as well. There is a also a growing list of page titles that are good candidates for testing summaries.

Yes, that is done in the page library.
The page library could detect if the content language is Asian and then chose a smaller minimum, let's say 20 or even lower (any suggestions?).

Maybe we could use randomInCategory, get a bunch of descriptions for the list of articles, and pick 3 most similar ones that are not exactly the same?

@Jdlrobson Yes, that's what I want. I had already included the module name mediawiki.skinning.content.parsoid in my previous request. Then I was now wondering why the .mw-image-border rules didn't get included in my version of the request.
After trying changing various query parameters to get them closer to your request I suspect that it was the useskin=minerva that triggers it. I had only skin=minerva before. Going that route changes other parts of the CSS that leads to undesired side-effects:

• The font is now a serif font instead of sans-serif.
• Infobox content is not centered anymore and has white background instead of gray.

@Tgr The search probably failed because the string had line breaks in the source.

https://github.com/wikimedia/restbase/pull/1092

@MSantos. No, it's https://github.com/wikimedia/mediawiki-services-mobileapps/blob/master/lib/transformations/pcs/head.js#L89.

The Swagger UI is taken from RB. The one for 1.3.0 and later is summary_new.yaml. The summary.yaml file in RB is for 1.2.0.

Deployed 30 minutes ago.

Not sure what column to put this one but it's not really actionable from our side at this time, so I'm going to put it in tracking.

@Niedzielski The possible values for the type field are listed in https://www.mediawiki.org/wiki/Specs/Summary/1.3.0:
"standard", "disambiguation", "no-extract", "mainpage"
https://www.mediawiki.org/wiki/Page_Previews/API_Specification doesn't mention "generic" either. Not sure where that was coming from.

@Jdlrobson I think we're going to want the content.parsoid.less styles included in Minerva as well for this to properly work? Thoughts?

content.parsoid.less styles are already requested but not included in the response of 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.

Setting priority to low since the backend work for this seems quite complicated and the workaround of using MW API seems sufficient currently.

ActionCounters, since it's for the edit action feed?

If this is for all pages then that could turn out quite expensive on the server side, at least if we pre-generated the API responses. Maybe a specific API is in order?

The links in the task description point to empty pages. Anyone know some good examples of links to glossary pages?
What API is needed here?