Tue, Mar 19
Fri, Mar 15
Probably can be closed now.
Wed, Mar 13
Tue, Mar 12
The place to change this in MCS would be the processing script definition.yaml.
@JoeWalsh app:// looks good to me.
Thu, Mar 7
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)
Tue, Mar 5
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:
@JoeWalsh I think this should work. Thank you!
Mon, Mar 4
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.
Fri, Mar 1
We should fix this after we've come up with a strategy for decoupling app/mobile-html CSS from MinervaNeue CSS.
Thu, Feb 28
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.
Mon, Feb 25
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.
Thu, Feb 21
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?
Feb 19 2019
@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).
Feb 13 2019
Plan to move to PCS anyways.
Feb 7 2019
Is there a convention for naming the HTML attribute to mark the pronunciation source?
Feb 6 2019
Feb 5 2019
Feb 4 2019
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.
Jan 26 2019
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.
Jan 25 2019
@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.)
Jan 23 2019
Looks like this enwiki change triggered the issue.
Jan 22 2019
Jan 19 2019
Jan 18 2019
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?).
Jan 17 2019
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.
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.
Jan 16 2019
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?
Jan 15 2019
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.
Jan 11 2019
Setting priority to low since the backend work for this seems quite complicated and the workaround of using MW API seems sufficient currently.