Fri, Mar 23
Thu, Mar 22
Wed, Mar 21
It was German.
OK, declining the task as invalid now but feel free to change status if you see fit.
Tue, Mar 20
Whoops, @Jdlrobson still has a related patch open.
@Pchelolo The content-type patch version was bumped in the patch. A content-type enforcing filter would be good if possible, but can wait until later if necessary as long as the top 5 wikis are updated.
@mobrovac @Pchelolo I recently deployed an MCS change (https://gerrit.wikimedia.org/r/#/c/419443/) that stops directly applying a display: none style to certain portions of IPA spans for the mobile-sections endpoints. Would it be possible to do a regeneration of mobile-sections and mobile-sections-lead sometime soon (this week, if possible) so that the IPA display change can be rolled out soon (and gracefully) on the app side?
Out of curiosity, could we in theory start a MediaWiki:MobileApp.css on any wiki that needed some special styling for apps but not mobile web, expose it as mobile.app.site via MobileAppResourceLoaderModule.php, and have it just work? Or would that take some additional configuration (or coding)? I can't find the notion of site-wide CSS beyond Common.css and Mobile.css addressed in the docs.
Mon, Mar 19
The current behavior won't change until https://gerrit.wikimedia.org/r/#/c/419430/ is merged in the app repo and the app is released with it. So long as we have a dump run by then we should be in good shape. It would be nice to have that happen soonish, though, so it's not blocking other work. We can get the dumps started as soon as https://gerrit.wikimedia.org/r/#/c/419443/ is merged and deployed and Services is willing.
Ah, okay. We're about at the limits of my current knowledge about ResourceLoader. If that's so, then plain mobile.site is probably the way to go (and we could probably take the code redundantly exposing mobile.app.site out of the MobileApp extension).
My concern with mobile.site from MobileFrontend is that according to https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/extension.json it declares a dependency on mobile.startup, which looks like a lot of web-specific stuff that the apps don't need or want.
Based on some testing it looks like the issue is most readily apparent by far on English Wikipedia. Would you agree? Limiting regeneration to pages on a single wiki (albeit the largest one) would probably help our case here.
Yeah, it's actually pretty bad IMO. Eyjafjallajökull manages to escape unscathed but that seems like a fluke.
There's one complication I want to flag here, without having a great idea how to handle it just yet. MCS currently adds a style of "display: none" to the first part of the IPA span (before the semicolon) such that when the CSS to hide the entire span is removed from the app style bundle, the result still looks like this:
One more question for the app teams. The MobileApp extension files issues.less and disambig.less both appear not to be needed any longer since issues and disambiguation messages have both been split off into native components. Can you confirm that these styles can be dropped?
Sat, Mar 17
I'm haven't found any smoking guns yet. We didn't deploy any code on 03-03; though we did deploy a fair amount of code on 03-01, 48h seems like a rather long time for any performance impact caused by the code to suddenly show up.
Fri, Mar 16
@bearND I've tried a few different ideas:
- simplifying the MW API query
- simplifying the querySelectorAll selectors
- using getElementsByTagName rather than querySelectorAll to find media items on the page
- restructuring the processing to fetch imageinfo from the API with generator=images while processing the HTML document rather than waiting to get the images list from the HTML (note: this one has some other challenges)
Thu, Mar 15
Per email discussion, added a cross-platform CSS snippet to hide the (listen) parenthetical in IPA spans. Results:
parsoidSectionsUsingDivs is no more.
Wed, Mar 14
Created a separate task, T189715, for discussion of showing IPAs in Android app article views, since there are some open questions around it. Since we know we can work toward that as a goal, I'm closing out this task. Thanks for the reviews, @Dbrant!
Tue, Mar 13
@Dbrant reminds me that the app doesn't load all page summaries from RESTBase (because of the ongoing lack of language variant support in the Parsoid/RESTBase stack). So, the patch above only fixes the issue for summaries loaded from RESTBase. The bug in the task description will continue to manifest for summaries loaded from the MediaWiki API, which continue to use the app's client-side extract text parsing.
It's a quick fix, I think that should do it. :)
First CSS style commit for Android: https://github.com/wikimedia/apps-android-wikipedia/commit/98c3a4db9e3d87d51cfc66d7776b3d9380c16897
No discussion of CSS style architecture for the apps appears to be documented anywhere. The MobileApp extension was created and styles moved there in January 2014.
Mon, Mar 12
@Fjalapeno Ah, the page metadata endpoint doesn't currently return any user info but I see that last editor info is something that was being considered. Yeah, I think it could be useful. If we do want to do that, the easiest way to get gender for now would be just to do a follow-up list=users query. I wouldn't really want to do it that way in one of the hotter endpoints like /page/summary, but in /page/metadata we could probably get away with it.
Here's a silly question for anyone who was around when early architecture choices about the apps were being made. Why do the apps bundle CSS at all? Links to the stylesheet(s) needed for a page could have instead been exposed through action=mobileview, for example. Was the idea to save on network requests? Or that many of the modules ResourceLoader identified as relevant to a page wouldn't actually be needed in the apps? Maybe both?
Ah, right, I'd forgotten about the Android app's client-side extract re-creation. That can probably go away now.
Looks resolved to me at this point. @mobrovac?
I'd expect this is long since resolved. Any cases showing otherwise spotted recently?