[13:17:37] berlin folk [13:17:39] i'm bored [13:17:41] entertain me! [13:17:44] ^ joakino [13:36:27] phuedx: how ?? [13:36:30] phuedx: hello [13:36:44] it's so quiet [13:36:54] if you want to be entertained - wait for daily ;) [13:36:59] lol [13:37:01] again, 3 computers in small room [13:37:17] with joakino controlling the mic and drinking beer… [14:53:32] * hashar dances for entertainment [14:53:38] ^(oo)^ [14:53:42] v(oo)v [14:53:45] <(oo)v [14:53:49] >(oo)> [14:53:53] <(oo)< [14:53:56] ^(oo)^ [14:54:04] >(oo)> [14:54:08] v(oo)v [14:54:13] <(--)> [14:54:21] phuedx: ^^ [14:54:32] <3 <3 <3 [14:54:36] i am entertained [14:54:38] raynor: ^ [14:56:23] phuedx: https://www.youtube.com/watch?v=htobTBlCvUU ? [15:00:35] hi all, running 5 min late [15:00:49] <3 [15:01:12] we have quick planning, will join grroming in couple minutes [15:02:35] olliv: ok, there is only me in the meeting. phuedx, joakino, jhobs care to join? [15:02:54] jdlrobson: not sure if it's too early for you ^ [15:03:06] bmansurov: I'm connecting [15:03:08] bmansurov: i'm busing in so wont be joining :) [15:03:09] bmansurov: i'm about to head out for dinner with the fam [15:03:21] cool [15:03:32] raynor: great [15:06:11] bmansurov: we lost you [15:06:29] go ahead without me, i'll restart [15:18:12] hi, are there tags that are not displayed in mobile version? trere is a template in ptwiki that is not showed in mobile version [15:28:16] is there docs about mediawiki mobile? (please, put it in the topic) [16:06:07] bmansurov: jhobs nzr retro [16:06:38] phuedx|nom: retro [16:09:48] coreyfloyd: did you want to meet today? [16:14:04] bearND: yep - every time… [16:17:35] danilo: yes, the extension MobileFrontend does apply certain transformations, so to speak. probably best if you post on the mobile-l mailing list (subscribe at https://lists.wikimedia.org/mailman/listinfo/mobile-l) [16:20:56] ok, the template is a navbox, and I just found in enwiki:Template:Navbox a warn saying that navboxes dont work in mobile version [16:59:41] maxbinder: have a meeting conflict... can't come to standup. will email [16:59:52] nzr: ok [17:00:43] have another meeting - will email standup right after, sorry! [17:30:38] dr0ptp4kt: I am writing my proposal for WikiRadio project. I need some help to decide bounds of project [17:31:14] dr0ptp4kt: I will also ask to Nirzar when he is online [17:39:51] jdlrobson: when is a good time to talk about the infobox & lead section task? [17:40:07] bmansurov: i've got 20 mins now if that helps [17:40:22] ok, do you want to talk here or hangouts? [17:42:25] bmansurov: lets go to trracy [17:49:56] bmansurov: the test is here: https://github.com/wikimedia/mediawiki-services-mobileapps/blob/10f24f15b8cb00219e873c1582b01cd36bcdbc57/test/features/mobile-sections-lead/pagecontent.js#L141 [17:50:33] There's just one. I have no idea if it was picked because it was a more complicated example but it's a good starting point. We can probably get away with just copying the layout of the lead. [18:00:31] cool [18:19:18] bearND: is ti known that the feed endpoint is overwriting old news? https://en.wikipedia.org/api/rest_v1/feed/featured/2016/07/11 [18:19:30] bearND: the news section is for today [18:19:59] bearND: seems like we should never evict the cache for the news section after the day has passed [18:20:23] coreyfloyd: we only have news for today. We don't have historic news info yet. there's a task for that, though. (TM) [18:20:41] bearND: ok - gotcha… thanks [18:20:51] T139481 [18:20:52] T139481: [Feed 2.0] News endpoint should provide old content - https://phabricator.wikimedia.org/T139481 [18:26:31] coreyfloyd: In the Android app we show news and a few other things only for the first day. In our Java code look for "age == 0" [18:27:06] bearND: thanks [18:27:39] bearND: we are just adding in some logic to not ingest news from any day but today [18:27:45] but will still keep old news in the DB [18:28:02] bearND: so does this mess up the cache behavior? [18:29:18] bearND: as a quick fix could we return “nil” from the news endpoint for any day but today? [18:30:05] i mean until we implement persisting that data long term [18:30:29] coreyfloyd: hmm, sound interesting. I'm in a meeting right now. I'll have to think about that a bit more [18:42:33] bearND: np - just thinking of ways to get this work off of the client - thanks [18:43:39] coreyfloyd: I think this sounds reasonable. I just created T147952 [18:43:39] T147952: Omit news property for prior days in aggregated feed - https://phabricator.wikimedia.org/T147952 [18:50:45] bearND: 👍 [18:59:20] bearND: another question… what are you doing for the license info of the Picture of the day? [19:01:44] coreyfloyd: we show an icon representing the license in the full screen version of the Potd. If you tap on that you get a Snackback with some text explaining what it is [19:02:18] bearND: where do you get the license info - I don’t see it in the feed response [19:11:50] coreyfloyd: When we enter the full screen mode (we call it gallery view) we just use the "File:" name of the image and get the data from there. Our GalleryActivity has already implemented the parts to get the license info there. I guess it would be nice to include the license info also in the feed response, so that theoretically no extra request would be [19:11:50] necessary. The way we have it right now in the Android app let's us reuse a lot of code. [19:13:29] bearND: gotcha… yeah I’ll file a ticket for that. I can fetch the extra info to, but like you said would be nice if that was included in the image response [19:30:54] omw... [20:34:48] mdholloway: it fixes the issue for me.... How are you reproducing? [20:36:21] dbrant: just doing the same test niedzielski and i were doing yesterday: change app lang to simplified chinese, search 中国, hit the 'go' button, and observe the characters of the page title after it's loaded [20:37:12] i'm still getting the traditional second character even with the patch applied [20:39:12] mdholloway: I am, in fact, getting the correct character. :/ Local cache issue, perhaps? [20:39:24] dbrant: maybe, i'll clear the cache and retry [20:41:46] dbrant: yep, sorry about that, i just had the traditional version cached [20:55:23] bearND mdholloway: i tried the check group permissions patch on dev and alpha flavors with my personal and test accounts on obama and jefferson but it's not working for me. i always see locked pencils. do you want me to just merge these since it's working for you both? [20:58:25] niedzielski: hmm, it would be nice to know why it's failing for you. [21:00:54] niedzielski: just to rule stuff out, no non-default MW or RB dev settings, i presume? [21:01:21] mdholloway: right. that's why i tried a fresh install of the alpha app [21:24:53] hello? [21:26:10] jdlrobson: o/ [21:41:06] niedzielski: not sure if you saw all or any of this before you got booted, but if I hard-code "Niedzielski" as the user for requesting group memberships so that my edit rights on the edit buttons appear as yours, the patch works as expected [21:41:17] niedzielski: so i suspect there's an issue in your setup somewhere [21:42:34] niedzielski: so, just so I understand your scenario better: On your device you uninstalled the alpha app. In AS you selected the alpha flavor and did a clean build using my patch, logged in, and went to [[Thomas Jefferson]]. [21:43:25] Did I capture this correctly? [21:43:30] mdholloway bearND: i think i just figured it out. i login with a lowercase username but the api returns an uppercase. it's just a comparison error [21:44:10] niedzielski: hmm, interesting. I thought MW usernames are case-sensitive [21:44:19] mdholloway bearND: i'm not sure where the ideal spot for it is but if you make the comparison in getGroupsFor: userName.toLowerCase().equals(name.toLowerCase()) it works [21:45:19] bearND: they are, except that the API will auto-capitalize the first letter for you... it's kind of inconsistent. [21:45:35] i ran into this while working on the AuthManager compatibility stuff [21:45:37] mdholloway: niedzielski : ah, just found it as well "Wikipedia usernames are case sensitive, but the first letter is always automatically capitalized." [21:45:48] https://en.wikipedia.org/wiki/Wikipedia:Username_policy [21:45:49] niedzielski: good find! [21:46:01] mdholloway bearND: neat. maybe we should change the app input field to auto-capitalize the field unconditionally [21:46:13] (someday) [21:46:22] niedzielski: mdholloway ok, will make the change [21:46:45] bearND mdholloway: sounds good [21:50:27] niedzielski: you can use the users API to get the canonical name [21:50:58] titlecasing is not necessarily the only transformation, and it does not happen on all wikis (although it does on all wikipedias) [21:52:08] tgr: thanks! i was thinking it would be nice to show the user how they'll really be logged in and also keep an exact record on the app side (we keep the username in nonvolatile storage) [21:54:16] https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&format=json&list=users&ususers=niedzielski [21:54:27] this should work for non-existing users as well [21:54:58] even better, https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&format=json&list=users&usprop=cancreate&ususers=niedzielski which will warn if that username cannot be created [21:55:11] (title blacklist rule etc) [21:56:51] tgr: awesome! [21:57:12] tgr: niedzielski mdholloway : we also get the real user name back as part of the clientlogin response [21:57:34] I'll probably just make a patch for that and rebase my other one on that [21:57:41] tgr: i opened up a couple app feature requests recently to show better username failures. this should help! [21:58:26] bearND: since we fail when requesting groups fail, that seems reasonable [22:01:03] niedzielski: weird, I am actually seeing the first letter uppercase in the overflow menu, even after logging in with the first letter lower cased [22:01:16] do you see yours uppercase, too? [22:02:20] bearND: i do :| [22:03:02] bearND: and i don't see anywhere that casing is changed (although perhaps i'm just missing it) [22:06:54] niedzielski: in LoginClient.ClientLogin.toLoginResult() it already takes the username from the clientlogin response. So, that seems to be doing the right thing already. [22:08:00] bearND: can you repro the issue i had? maybe it was something else and it just happened to work for me? [22:08:03] niedzielski: ok, I think I found it [22:08:35] niedzielski: Yes, I was able to repro once I used the first letter lower cased. [22:09:03] bearND: ok cool [22:20:09] tgr: thanks. That got us on the right track. [22:22:51] niedzielski: mdholloway|afk https://gerrit.wikimedia.org/r/#/c/313031/19 has the changes [22:23:13] bearND: sweet! thanks [22:25:34] we were basically storing the right username in the shared preference but for the getGroupMemberships we still used the one entered by the user [22:30:02] bearND: i see. i was just about to leave a comment but i'm glad to see this fix rather than my kludge [22:32:55] niedzielski: was a bit uneasy about making transforms blindly, esp. after seeing T141723 [22:32:56] T141723: [Bug] Wikipedia article on the letter "ß" does not load properly. - https://phabricator.wikimedia.org/T141723 [22:34:34] 👍