[12:33:53] nick phuedx|afk [13:34:07] 3f3n [15:18:50] niedzielski: mdholloway: morning! Can hz CR on this today? https://gerrit.wikimedia.org/r/232386 [15:19:59] dbrant: yep! that's next on my list after the highlight colors patch, which I'm about to try out. [15:21:18] dbrant: yeah, i can hit that. i need to buckle down on mdholloway's db patch first if that's ok? [15:21:31] sure! [17:10:07] dbrant: i like the latest link preview design *way* better. looking sharp! [17:11:16] https://phabricator.wikimedia.org/dashboard/manage/125/ [17:11:17] mdholloway: thx! in large part thanks to Design feedback. [17:11:21] kristenlans: ^ [17:17:27] i now idle in tracy island by the way [17:17:33] just incase y'all are lonely [17:17:37] (read: i'm lonely) [17:17:40] oh yeah [17:35:08] brb more coffee [17:45:28] bearND mdholloway|afk dbrant: i'm trying to tie up loose ends on our device focus thread, especially gb. it sounds like this is going to be The link preview release. are we intending to freeze this version (deviate from GB starting next version with a 10-20 version number boost)? if so, what's our timeline? i know the focus discussion was larger than just GB, were there any other action items wanted? [18:08:06] dr0ptp4kt, hey adam, hangout? [18:19:39] bmansurov, thanks for waiting a couple minutes. good talking with you. [19:09:50] anyone willing to answer a MobileFrontent support question? https://www.facebook.com/groups/2205099323/permalink/10153543465134324/ [19:20:42] niedzielski: Emulator - Nearby should be displayed without problems? [19:22:10] etonkovidova: currently it hangs forever. as a future enhancement, it should gracefully timeout with a message. there are ways to simulate to GPS but they're involved so i recommend testing that only on physical devices [19:23:46] niedzielski: understood - I thought so too. Nearby hangs on Android 4.0.4 on a tablet but ok on 5.1. Nexus [19:24:24] niedzielski: hmm... [19:27:13] joakino: jdlrobson ^^^^^ tgr noted a question on facebook. you guys got this covered? [19:27:39] niedzielski: I cannot decide if failing Nearby on a tablet with 4.0.4 is worth reporting... Nearby for 5x seems to be ok [19:28:06] MediaWiki:Mobile.css / MediaWiki:Mobile.js tgr is the answer [19:28:07] etonkovidova: do you have locations services enabled? [19:28:17] (for the time being) [19:28:39] niedzielski: yeah, just checked them [19:29:25] etonkovidova: hrm, i wonder if we're assuming gps is available and not using other services. just a moment [19:30:37] etonkovidova: it looks like we try both GPS and network provider. is the tablet on wifi or cell network at least? if so, it should get some kind of location [19:30:44] niedzielski: on a tablet -when Nearby is clicked - a blank page and a compass-like icon is blinking at the bottom of system menu [19:30:52] niedzielski: will look more [19:33:21] etonkovidova: if it's still not working, it's probably bug worthy but not necessarily a high priority [19:36:25] niedzielski: right [19:38:44] niedzielski: mdholloway: >_< i'm locked out of my link preview updates because i was working on my desktop, and now i've lost power :( i hope i can access them later today. [19:39:16] dbrant: that's a bummer. [19:39:22] dbrant: just bring your desktop to the coffee shop. they'll love it! [19:39:52] dbrant: yeah, sorry dude! we can try for tomorrow morning [19:40:49] niedzielski: i had pretty much all the comments addressed, too! [19:41:25] dbrant: i'm looking at it now. one thing while we're talking: i agree that the MobileWikiAppMediaGallery schema lends itself to extending the source field -- does actually updating the schema with the new value fall within this ticket? [19:42:00] niedzielski: lol, i would love it if someone did that, that is for sure! [19:42:47] mdholloway: how do you mean? (which ticket?) [19:44:01] dbrant: "task," i mean, not "ticket." you mentioned in your commit msg that the schema https://meta.wikimedia.org/wiki/Schema:MobileWikiAppMediaGallery supports the generalization of the source field to include link previews [19:44:13] (but it doesn't actually include them yet) [19:46:53] mdholloway: if we update the comment in the schema for the "source" parameter, then it would bump the revision id of the schema... and I think I'd rather keep it the same. [19:47:09] dbrant (/cc mdholloway bearND): hey did you guys see my questions on GB support earlier? [19:47:57] dbrant: does it have other implications besides our needing to change it in the relevant funnel code? (i seem to remember something about that.) [19:49:39] niedzielski: oops, yeah, forgot about that. to be honest i was allowing dbrant or bearND first dibs ;) [19:50:01] niedzielski: yeah, about the device discussion: When we freeze the app version for Gingerbread my recommendation would be to also do the same for Honeycomb, and at least the first ICS release (API 14). So, minSdkVersion would be 15 or 16. Maybe do 15 first, then a while later 16. The "when" part is probably more dbrant's turf. [19:50:25] niedzielski: my understanding was that we'd freeze at least GB ... and I see bearND's just replied :D [19:51:22] mdholloway bearND dbrant: sorry, i was lumping everything under the GB umbrella. i was also thinking API 15. i haven't looked too closely at the 16 numbers yet [19:51:23] niedzielski: we could probably stand to be a little more conservative than @minSdkVersion... though not necessarily that much. [19:52:15] niedzielski: (also, re @minSdkVersion, I like that it's anonymous... or is it semi-known who's behind it?) [19:52:27] niedzielski: right! About that, I think I'd be happy to freeze the app for GB after the link preview release (and after we're convinced that the feature is well-received!). Ideally, we would split off the app for GB, then spend 1/2-sprint or so tidying up any visual loose ends on GB, then freeze it. [19:52:53] mdholloway: not sure on who the owner is [19:53:34] niedzielski: timing-wise, I would imagine this would be towards mid- / late September. [19:54:46] dbrant: when you say GB, were you thinking API 15, 11, or something else? [19:54:57] niedzielski: I haven't seen any reason why @minSdkVersion bumped it to 16. Have you? Would be curious to know. Maybe they go by what's under the 5% threshold in the Android Dashboard? [19:55:32] niedzielski: err.. yes, API 15. [19:55:42] mdholloway: i don't think there are other implications for the funnel code. The schema revision id is staying the same, which is the most important part. [19:56:48] dbrant: the idea of deviating from the documentation just causes me some mild discomfort. [19:58:53] bearND: no, i'm not sure on that. looking at the Play numbers, i don't think we want to jump 16 from 15 right now. the tech gains are a lot smaller and there's still a lot of users on that api alone [20:00:25] niedzielski: I tend to agree on that one. So, let just say explicitly that minSdkVersion would be bumped from 10 to 15 when we do the freeze. [20:00:38] bearND: +1 from me [20:00:39] +1 [20:00:57] +1 [20:01:03] \o/ [20:01:44] bearND dbrant mdholloway: now we just need to communicate it. i'll send out an etherpad so we can draft it up. thanks!! [20:02:06] sounds good to me, thanks [20:02:13] niedzielski: cool, thanks! [20:02:29] mdholloway: well, technically we can make the edit to the schema comments, but still have the app send events to the previous schema id. I would just like the data to go into the same table as before, for easy comparison. [20:02:58] dbrant: ah, i see. that makes sense. [20:12:09] dbrant: one last thing: it looks like there's not yet a card on the content service workboard for processing link preview sentences. Should I write it up? [20:12:33] mdholloway: go for it [20:17:56] mdholloway: what processing of link preview sentences do you have in mind? [20:18:17] mdholloway: There is a Phab task for using text extracts [20:19:04] bearND: what task is that? [20:19:37] mdholloway: https://phabricator.wikimedia.org/T108347 [20:19:43] bearND: i was thinking along the lines of dbrant's discussion on PS4 here: https://gerrit.wikimedia.org/r/#/c/232386/ [20:20:38] bearND: basically, to the effect that our processing produces a superior result to TextExtracts [20:21:10] bearND: that said, I know too little about TextExtracts to have a strong opinion about this [20:21:18] bearND: at this point, anyway. [20:21:23] mdholloway: ok, that information should be added to the Phab task I mentioned [20:21:40] bearND: OK [20:56:19] kaldari: yay gsoc! :) https://en.m.wikivoyage.org/wiki/London [20:56:59] awesome! [20:58:46] jdlrobson: Can I start using that on WikiVoyage or is it still experimental? [20:59:45] currently Wikidata banners are not enabled and they haven't switched over the template [20:59:53] but i think you are free to experiment and find bugs :) [21:00:04] https://en.m.wikivoyage.org/wiki/Caye_Caulker :) [21:00:23] the first non-standard 7:1 banner - not sure if it will be reverted but we'll see :) [21:00:52] kaldari: there was a comment from a community member about enabling on commons [21:01:22] https://en.wikivoyage.org/wiki/Wikivoyage:Travellers%27_pub#Banners_extension_deployment [21:01:33] also why is the + collapsing/opening table of contents on wikivoyage broken? [21:03:19] jdlrobson: Nice. [21:57:46] ah ok. i somehow thought it was about clickthroughs to the store in the first place, but that makes sense of course [21:59:39] HaeB: you bring up a good point about social media campaigns. For future tweets about the app, I'll make sure to show Comms how to include the referrer parameter. It would be great to know the impact of those campaigns. [22:00:12] i'll send a PS on that thread so they remember it too [22:00:17] cool! [22:04:27] thanks for the explanation! having looked at the examples at https://phabricator.wikimedia.org/T103896#1540114 i wonder why we include the precise page name in the referrer URL - is someone planning to use that data? if not, we may want to remove it for privacy reasons [22:30:48] jdlrobson: I've been working on it, but I think I just figured out that https://phabricator.wikimedia.org/T109538 can't be done without varnish :/ [22:31:18] The way we do it in prod, varnish rewrites the Host header for the request [22:31:35] I can't figure out a way to do that with only Apache [22:32:30] All the ways that I can think that I might be able to make it work are pretty horrible and invasive hacks [22:34:25] the problem is that MWMultiVersion doesn't know anything about *.m.* variants. WMF prod taeks care of this with Varnish rewrites to remove the (.m.) bit before forwarding the request to MW [22:35:29] I can't find a way to rewrite the Host header inside Apache alone in any meaningful way [22:37:02] If MobileContext::updateMobileUrlPath() was actually all hooked up it would be easy to use a ^/m/ path and some internal rewrites [22:40:22] bd808, a hack in PHP could do it too [22:40:33] would be ugly as hell, obviously [22:41:53] MaxSem: yeah I could try and do something nasty in my getMediaWiki() entry point but I'd really rather not. [22:42:33] I think this is yet another example of MF being a bit purpose built and not very flexible [22:42:55] which I totally understand [22:52:54] well bd808, for general-purpose users there's autodetection. now you just need to impleent WMF's fucked up setup [22:53:38] the role has autodetection turned on but now jdlrobson wants this other wacky behavior [22:55:43] bd808, $wgServer = str_replace('.m', $wgServer); in LocalSettings.php ;) [22:56:50] I'm not sure that will actually work in MediaWiki-Vagrant due to it's Multversion system [22:57:15] I think it would still always end up talking to the "default" wiki (devwiki) [23:02:45] bd808: hhmmm. thanks for taking a look. i'm happy to completely revisit/rewrite this stuff if we can get it in core... just as an fyi. [23:14:00] dbrant mdholloway|afk: i feel like i'm nit picking in the code reviews today. sorry about that! i feel like the "and" guy from portlandia https://youtu.be/7e-GKmiM6U8?t=23s