[00:48:46] dbrant: github too.. that's why we're changing ours on Wikipedia clearly ;-) [00:48:54] it's the new in thing for designers like nzr ;-) [00:49:15] hahaha we have an underground community [00:49:21] we discussed this is the next big thing [00:49:29] wikipedia stackoverflow github and facebook [00:53:54] hah [00:54:09] anyone here with +2 and understand browser tests? [00:55:27] nzr: need you to test something in a bit [00:55:57] nzr: the limbo header.. [00:57:23] lol the limbo header [00:57:29] sure [01:03:51] nzr should be live in about 10 mins on beta cluster [01:11:27] * jdlrobson still waiting [01:19:54] nzr: ok [01:19:57] limbo header is live [01:20:11] nzr: still there? [01:23:58] booo [18:10:19] niedzielski: hello, sir. excuse me if i'm disturbing you continuously. [18:10:53] kaartic: :] o/ [18:12:57] I actually missed a point yesterday which I wanted to clarify. you mentioned, when faces are detected, the photo is panned to center the face but is never panned beyond the edge; this means a face on the edge of a photo cannot be centered". so does that mean that photos with faces in edges cannot be centered in anyway (i.e.) can't the face be centered at the edge ? [18:16:34] kaartic: i wouldn't say they couldn't be but that we chose not to allow them since it doesn't look very good [18:19:08] ok. i guess all the cases in which i saw the faces not centered seem to fit into either the "face in edge" or "face not clear" category. [18:19:17] that seems to leaves the face detection implementation without any trouble for now. [18:22:23] but for one thing, the image i saw would have been better if it were centered even though the face was in the edge [18:23:50] anyways, have a great day sir. [18:24:28] kaartic: maybe we could make it work if we zoomed in but it seems to me that there are some cases where we'd still have to pan beyond the edge or zoom so far in that part of the face is clipped or very pixelated [18:24:39] kaartic: thanks, you too! [18:25:31] niedzielski: can't it be centered at the edge itself, sir [18:26:48] kaartic: how so? i think we either have to pan and / or zoom to center a face [18:28:32] niedzielski: i'm not sure about the possibility, just wanted to know if the face could be centered with respect to the vertical axis in which it is detected. so that it could atleast be visible [18:29:15] the image i mentioned before is the lead image of the "Elasticsearch" article. you see that to get an idea, sir. [18:29:48] (looking) [18:31:40] kaartic: i agree that the vertical offset should work since translation wouldn't require moving beyond the edge in this case [18:31:50] kaartic: this seems like a bug to me [18:32:00] Hi all! A few quick questions here... Regarding desktop vs. mobile links there is no way to get the full mobile URL for a page on one wiki from a request on another wiki? For example, from PHP in a request to enwiki, is there a way to get a mobile URL for a page on meta? [18:33:26] niedzielski: do you want me to file one, sir? (or) should I file one when i see some other cases like this one? [18:33:48] kaartic: if you wouldn't mind, i think this is a great example for a bug report [18:34:16] niedzielski: in that case, i'll file one soon, sir. [18:34:34] thanks kaartic and thank you for your diligence! :] [18:35:37] niedzielski: you're welcome, sir. have a great day. [18:35:52] you too! [18:36:47] jdlrobson phuedx bmansurov ^ ? [18:39:33] AndyRussG: I don't think so, see discussion at https://phabricator.wikimedia.org/T53753 [18:40:46] oops, I meant https://phabricator.wikimedia.org/T67047 AndyRussG [18:46:21] bmansurov: ah interesting, thx! I'm asking wrt CentralNotice's call to Special:BannerLoader on meta to fetch banners [18:47:11] We've been using MobileContext::getMobileUrl(), but just found out it isn't working on a few smaller wikis, because of different base URL patterns [18:48:06] T158030 [18:48:06] T158030: CentralNotice: banners not showing on mobile versions of mediawiki.org, Wikidata and Wikisource - https://phabricator.wikimedia.org/T158030 [18:48:54] AndyRussG: ok, I'll bring it to our team's attention, and see if we can help. [18:49:03] cool thx! [18:49:16] np [18:50:57] bmansurov: here's a follow-up question: if I'd like to set a global config variable to a different value for the mobile site, really I should create a new config variable and decide which one to actually use at runtime based on MobileContext::shouldDisplayMobileView(), make sense? [18:53:36] dbrant: niedzielski: our help link in the revert help dialog still points to https://www.wikidata.org/wiki/Help:Description#Guidelines_for_descriptions_in_English. should we change this? at least to remove the URL fragment? [18:53:39] AndyRussG: sorry, in a meeting, will reply shortly [18:54:11] dbrant: niedzielski: a table of language links appears at the top of the page and is the first thing a user would see with the fragment removed [18:54:22] pages exist for catalan and russian but not hebrew [18:54:45] mdholloway: for other languages, the translated string resource should contain the correct url. [18:55:05] dbrant: ah, excellent. i hadn't checked that [18:57:33] mdholloway: o/ i think it was just confusing because hebrew is iw on android [18:57:41] i do see a translation there [18:58:09] er, the language code is iw not he, that is [18:58:26] niedzielski: oh, i never even got that far :/ i just saw the english string resource and assumed it wouldn't differ in structure elsewhere [18:59:00] AndyRussG: I think that's reasonable. [18:59:09] mdholloway: ah that's cool :] i think we used to have those in strings_no_translate.xml so that might have been what you were thinking [19:01:27] bmansurov: cool thx! [19:19:32] niedzielski: i have created the task as per your yesterday's suggestion, sir. It could be found at https://phabricator.wikimedia.org/T158227 [19:20:15] hope it helps. Not sure if it's that good. Please suggest some possible improvements to it, if needed. [19:38:28] jdlrobson: is this function in mobile.php the place to put hacks for config vars that should be different on mobile? https://github.com/wikimedia/operations-mediawiki-config/blob/e07a94d9cd8a54294bc799853c68dda062fb3fc6/wmf-config/mobile.php#L38-L60 [19:39:02] I could just change put a special setting there... [19:50:40] Hmmm actually scratch that, it doesn't address a different, related issue [19:53:06] dbrant: https://gerrit.wikimedia.org/r/#/c/336862/ is another patch that's pretty small (8 LOC) and basically a bug fix that might be nice to have in the beta [19:53:28] just making sure an active action mode doesn't persist between the two pages of the reading list fragment [19:55:18] kaartic: thanks! i'll look it over [20:09:12] AndyRussG: hey. you can do that. [20:09:18] alternatively you can simply add them in mobile.php [20:09:28] oh wait that is mobile.php :) [20:09:42] so yes. that's where you add them. [20:11:33] jdlrobson: thx! yeah... I was just remembering, though, that for another task (purging banner loading URLs from varnish) I'd like to get the mobile URLs from any request (desktop or mobile) to meta (CN admin UI). So rather I'm taking the extra-config-var route.... [20:11:56] :/ [20:12:38] I guess it's not fantastic, but it's temporary if core can tell us mobile and non-mobile URLs one day [20:12:40] T154954 [20:12:41] T154954: Method to bypass/purge CentralNotice cache when forcing banner - https://phabricator.wikimedia.org/T154954 [20:12:56] https://gerrit.wikimedia.org/r/336237 [20:13:16] Pls feel free to lmk if u can think of any better approaches! ;p [20:15:01] (bmansurov in case you're also interested ^ ) [20:15:05] thank u both! :D [20:18:09] ok [20:39:48] mdholloway: the new alpha is great, thank you and the team [20:40:18] matanya: thanks, glad to hear it! [20:40:24] niedzielski-afk: dbrant: ^ [20:50:07] jdlrobson: bmansurov: $wgServer somehow gets set to the mobile value on mobile, right? [20:51:36] AndyRussG: I don't think so. A quick search didn't return any results. jdlrobson? [20:51:52] \o/ [20:55:07] bmansurov: K thx! [20:56:21] dbrant mdholloway: are we ready for final beta release? :] [20:59:36] niedzielski: yes, ready to go from my end. [21:06:05] mdholloway: any objections? :] [21:06:17] niedzielski: go for it! [21:07:15] 👍 [21:19:36] ABorbaWMF: would you like a browser stack account? [21:19:51] for testing IE11 on Windows 7.. or do you specifically want/need a real device? [21:20:26] contact Sarah Rolund if you want one (I think she's the right contact) [21:20:37] I'll look into that thanks [22:24:33] https://developer.android.com/topic/instant-apps/prepare.html Are we going to try for an instant app? [22:36:16] Reedy: we'd like to, but this is still in its early stages, and Google hasn't yet opened it up to general developers (we have no way to test it). [22:36:41] :) [22:36:55] * Reedy adds things to the mountain of backlog [22:37:39] Looks like there's a few prepatory things that can be done [22:37:48] (if not done already) [22:37:50] like Implement runtime permissions from Android 6.0 [22:38:05] yes, we have that. [22:40:13] the only thing I'm still not totally clear about is Digital Asset Links. https://developers.google.com/digital-asset-links/ [23:00:27] dbrant mdholloway: i'm waiting on the google test results to publish but i wanted to merge in some of these outstanding patches. any objections? [23:01:16] niedzielski: none [23:02:49] niedzielski: nope, none here [23:03:38] cool, thanks :] [23:39:53] dbrant: btw, there's a Digital Asset Links wizard in Android Studio since version 2.3 beta 1 (https://sites.google.com/a/android.com/tools/recent/androidstudio23beta1isnowavailable) [23:43:24] I think the bigger blocker is "Android instant apps need to be structured into URL-addressable modules that are under 4MB in size". [23:45:04] This SmartLock thing sounds neat: https://developers.google.com/identity/smartlock-passwords/android/