[10:58:59] thedj: https://phabricator.wikimedia.org/T175877 hey DJ, would be great if you can provide feedback here! [11:14:11] nzr: hmm, that is not something that i'm very familiar with right now. unfortunately [11:14:26] i would say that worrying about windows mobile is a waste of time :) [11:14:49] hmmm no worries thedj just wanted to get feedback before we proceed. will post somewhere [11:14:56] yeah it affects ios and android as well [11:15:07] uses the system typefaces. sf sans for ios and roboto for android [11:15:50] yeah, it should work, i've just not done anything with fonts on mobile web for some time. [11:17:13] cool just wanted to check.. thanks though [13:36:47] mhurd: yes. afaik the only time the placeholders should change size are when the declared dimensions are incorrect or unspecified. https://drive.google.com/a/wikimedia.org/file/d/1JzKoyt5nrThNKh6V3OTGFQXXizAROlxh/view?usp=sharing [13:36:48] https://drive.google.com/a/wikimedia.org/file/d/1Mq8XQ1pBNQeNc3rbFc8sLwdtw9G8YHmB/view?usp=sharing [16:52:11] dbrant: Hey! Is there a way I can trick you into answering https://phabricator.wikimedia.org/T177879#3796376 , https://phabricator.wikimedia.org/T179334#3776290 , https://phabricator.wikimedia.org/T171521#3776285 ? TIA :) [16:52:29] andre__: ah, sorry! will do. [16:57:17] Thanks :) [17:42:25] mdholloway: re media endpoint: [17:42:30] https://www.mediawiki.org/wiki/Help:Extension:Media_Viewer#How_can_I_disable_Media_Viewer_for_unrelated_images? [17:42:52] tgr: thanks! [17:43:00] and https://www.mediawiki.org/wiki/Help:Images#Mode_parameter mode="slideshow" [17:43:29] (my wifi seems to be in a quantum superposition of working and not working, couldn't send links during the meeting) [17:43:50] tgr: also, one question i forgot to ask during the meeting: do File pages have pageprops? i added pageprops to a mw api query about File pages for the media endpoint but never seem to get any pageprops back [17:43:53] tgr: lol [17:44:40] tgr: all i'm really after is getting the displaytitles for the File pages, if that's something it's possible for them to have [17:45:11] every page can have them (e.g. you could mark a file page as a disambiguation page, technically), but I don't think there is any real use for file pages [17:46:09] geodata, maybe? [17:46:41] tgr: hmm, yeah, i assumed pageprops shouldn't be namespace-restricted. [17:46:43] https://commons.wikimedia.org/w/api.php?action=query&list=pagepropnames&ppnlimit=100 [17:46:45] geodata might be useful, yeah [17:47:05] some of that makes sense for file pages but isn't too interesting (e.g. defaultsort) [17:48:33] I don't see anything that would be relevant for the media endpoint [17:48:33] tgr: thanks again! [17:50:06] nvm, geodata is in the page HTML, not page props [17:50:30] you can get it from extmetadata or the dedicated API [17:56:12] bearND: https://www.mediawiki.org/wiki/Extension:Cite#Customization is what I meant, but it seems like no Wikmedia wiki does that [18:02:45] tgr: Great. Thanks. Yep, I see https://www.mediawiki.org/w/index.php?title=Special%3AAllMessages&prefix=cite_reference&filter=all&lang=en&limit=50 has only red links, so all defaults then, right? [18:04:36] bearND: yeah, you can go to terbium and run https://wikitech.wikimedia.org/wiki/Wikimedia_binaries#mwgrep [18:05:03] mwgrep --etitle 'Cite_*' '.*' [18:05:12] and that did not turn up anything [18:14:07] awesome, thanks! [18:14:09] (the other search would only look for mediawiki.org overrides) [18:14:40] It's good to see the message formats for the defaults on https://www.mediawiki.org/w/index.php?title=Special%3AAllMessages&prefix=Cite&filter=all&lang=en&limit=500 [18:15:13] oh, right. I would have to look on WP instead [18:15:54] hmm, there are some blue links on https://en.wikipedia.org/w/index.php?title=Special%3AAllMessages&prefix=Cite&filter=all&lang=en&limit=500 [18:20:37] that's weird [18:20:52] did I get the regex notation wrong? [18:22:16] the ones that are interesting to you are cite_reference_link, cite_reference_link_prefix, cite_references_link_many, cite_references_link_one, and cite_references_link_prefix [18:22:30] and maybe cite_references_no_link, no idea what that is [18:22:46] and none of those have changed class/id names [18:23:06] that's only enwiki though [18:32:05] tgr: Right. I just checked dewiki and all the string there are default (English). That's surprising. [18:32:11] ahh I remember, mwgrep only looks at .js pages in the MW namespace [18:32:12] https://de.wikipedia.org/w/index.php?title=Spezial:MediaWiki-Systemnachrichten&prefix=Cite&filter=all&lang=en&limit=500 [18:32:42] I had a patch to fix that but never uploaded it [18:33:09] I'll dig that up and make a proper list [18:33:52] lang=en makes it search in a language subspace [18:34:08] so cite_reference_link/en instead of cite_reference_link [18:34:19] those messages rarely exist [18:35:59] Ah, that explains. Fixed to https://en.wikipedia.org/w/index.php?title=Special%3AAllMessages&prefix=Cite&filter=all&lang=de&limit=500 [18:36:08] Good catch! [18:36:43] that still searches in a language subspace actually :) [18:36:56] it's a bit confusing [18:38:09] cite_reference_link/de and cite_reference_link are different pages, MediaWiki will first look up cite_reference_link then fall back to cite_reference_link/ [18:39:38] (the other way around, actually) [18:40:40] arguably that page is buggy, I doubt looking at the language subspace of the content language is useful at all [18:41:05] but you can drop the lang parameter completely and then you'll see the real messages [18:42:22] tgr: like https://de.wikipedia.org/w/index.php?title=Spezial:MediaWiki-Systemnachrichten&prefix=Cite ? That shows some interesting message diffs [18:44:23] For the earlier one I had two tags open, one with the English, the other with the German one. Then I updated the wrong one, duh. [18:50:12] yeah, sorry, I mixed up the wikis there [18:50:40] (the dangers of having set the interface to English everywhere...) [19:23:30] coreyfloyd: about the video derivatives, what do you think about removing the original from the derivatives list but keeping the 'original' property for videos? [19:23:53] coreyfloyd: my reasoning is that it would be unfortunate to make clients introduce special-case logic for videos [19:24:08] every media item should have the original file info under 'original' [19:24:19] (and probably most clients aren't going to care much about the derivatives anyway) [19:26:04] I think it’s impossible for clients not to deal with videos different from images [19:26:10] mdholloway: ^ [19:26:32] So I wasn’t worried about it being a special case. Same for audio... hose are inherently different [19:27:39] mdholloway: also if I am writing a parser and I encounter “original” now I have to have special logic to see if that is an image or a video. So that’s not very restful [19:28:49] coreyfloyd: i suppose it's true they'll be handled differently. all right, then! [19:29:01] mdholloway: and of course we use “originalimage” elsewhere. So it’s odd that we don’t follow that convention here. That’s basically my rationale so far. I can be talked out of it but so far it seems that this points to removing the video from original [19:29:14] mdholloway: Kk let it simmer [19:29:34] If you still feel that way after playing with it more let me know. You may come up with some other good reasons. [19:29:38] mdholloway: ^ [19:32:01] mdholloway: also feel free to rename that derivative property to something that encapsulates the original. Like sources or files or videos idk [19:32:22] coreyfloyd: yeah, i think i'll go with 'sources' [19:54:23] niedzielski: thanks for the video! it looks like the image widening transform isn't working though... those images are widened on ios and i see size changes when images lazily load... [19:56:42] mhurd: are you applying the widen and lazy load transforms at the same time? what order are you applying them? [19:57:08] niedzielski: oh i mean in the video you posted images are not being widened at all [19:57:48] mhurd: what's a good test article for me to try? [19:58:23] niedzielski: i test with the obama article and the pablo picasso one [20:04:54] https://usercontent.irccloud-cdn.com/file/9eSadsr7/o.mov.gif [20:04:57] niedzielski: ^ [20:07:01] that gif is w/o lazy load btw - just quick example of the obama image widening [20:08:25] but ya when i widening then applying lazy load i'm seeing resize/reflows. the image which is lazily fetched ends up being the right widened size, but the lazy placeholder is at the small pre-widened size [20:12:31] mhurd: sorry, old apk. here's the latest alpha which shows widening. https://drive.google.com/a/wikimedia.org/file/d/1Dr4A0sh2kxLbCVz7Q04cDDwSU9BZ3J5l/view?usp=sharing [20:12:31] https://drive.google.com/a/wikimedia.org/file/d/1eHZFceIy6TTuvlQR3ZUP5XHXNDe1NqAD/view?usp=sharing [20:13:59] mhurd: doesn't ios have some weird thing with the image width and height attributes being moved to data-attributes? [20:14:48] mhurd: the transform only knows about width, height, and style width and height (preference is made to the latter) [20:15:56] mhurd: does the lifecycle you're seeing look correct in terms of sizing? https://github.com/wikimedia/wikimedia-page-library/blob/master/src/transform/LazyLoadTransform.css#L3-L33 [20:15:59] niedzielski: ah thx! checking on the data attribs... [21:50:39] niedzielski: when you have time could you check one more thing (no rush) - if you set lazyLoadViewportDistanceMultiplier to 1 and throttle your connection speed, do still not see any resizing? still tracking down lifecycle deltas... (took lunch break) [22:03:01] mhurd: i've set it to .1 (network settings slower than lte appear to always timeout in the app). i've tried to crawl up on the images as slow as possible. you should be able to repro this same thing in the page library desktop demo too. https://drive.google.com/a/wikimedia.org/file/d/1y-_UkJ2D517F2Sq_taKQ0OXpfvQGVUoQ/view?usp=sharing [22:10:30] niedzielski: oh that's perfect thanks for checking! while watching you video i think i may have realized what's happening - or at least what to check next... suspecting its an artifact of how iOS is now handling sections... checking... [22:10:38] *your video [22:11:37] niedzielski: i hadn't realized lazyLoadViewportDistanceMultiplier could be < 1 but makes sense and makes testing even easier :)