[00:29:13] A friend at my coworking space speaks very highly of the iPhone Wikipedia app. :) I pointed them to the beta signup. [14:44:47] dbrant: I guess you remember the app freezing issue due to partially downloaded zim files I noted before. [14:45:13] Currently the app's not freezing anymore when those files are present. [14:45:52] But.... It identifies them as valid zim files and shows them in the 'In my Library' list. [14:46:11] Is this ok or should I file a bug about this? [14:50:29] kaartic: it is ok. [14:50:46] The real issue is that the app shouldn't really "use" zim files that are partially downloaded. [14:50:58] But we're working on that. [15:08:05] Ok then :-) [15:14:38] BTW, Is there any reason as to why the overflow menu repeats actions available in the article toolbar? [15:21:07] Yes, to make certain actions as discoverable as possible. [15:21:43] I saw the comment you left on the associated task. We'll evaluate it, in priority order, upon our next design review. [15:25:57] ok. One last thing I wanted to ask about the 'Offline library' feature. [15:26:19] (last thing for today) [15:27:52] Is there any idea of making the app associate itself with 'zim' files? [15:28:57] i.e., trying to open a zim file will open the app and show a the detail screen if it's a valid zim file [15:30:40] Sure, why not. [15:31:00] I'm asking this because From an end user's perspective, the app gives a view that it partially recognises zim files by opening the app when tapping on the download progress [15:31:53] This might be useful, but in very, very specific circumstances. [15:32:26] I had a doubt because an use might then try to open zim files they get from the wild. [15:34:55] Right, I'm not disagreeing; just saying it's very low-priority. [15:38:05] (but feel free to create a task regardless) [15:40:27] I didn't say you were disagreeing either. I was just expressing the reason why I was doubtful the app would something like that. [18:10:04] dbrant: +1 from OTRS to disabling font size syncing! [18:11:42] +1 ! [18:12:58] mdholloway: same question, will the language preferences be changed after login? [18:14:04] cooltey: we don't have any current logic to do that. it might be an interesting feature, though... [18:15:34] OK, I see. Because I found something (maybe a bug) about the Chinese variant issues after login. [18:16:20] thank you Michael! [18:19:45] cooltey: ah, actually, let me think this through for a minute. i think the user's language variant preference should be taken into account somehow, we just don't handle it directly in the app. it may affect the language variant of the content the API provides. let me double-check, though... [18:25:29] yes, that might be the reason! thanks! [19:56:29] mdholloway: cooltey|brb : I beg to differ. The Android app does handle Chinese language variant selection in the app, see https://github.com/wikimedia/apps-android-wikipedia/blob/master/app/src/main/java/org/wikipedia/language/LanguageUtil.java#L44-L45. There's a separate entry in languages_list.xml, so the user can select the variant she wants. [20:00:07] bearND: cooltey|brb: yeah, i should probably have been more clear. we do have the handling of the variant as an app language. i was more focused on what could be interacting with the user being logged in [20:02:50] mdholloway: ah, i see. [20:03:14] Anyone around to merge https://gerrit.wikimedia.org/r/#/c/376137 for me? [20:09:06] Pchelolo: cc about the route name change ^. jdlrobson said he's fine with the name change in T168848. [20:09:07] T168848: Bootstrap an initial version of the Page Summary API in MCS - https://phabricator.wikimedia.org/T168848 [20:09:50] bearND: i can do.. but will that clash with the existing route? [20:11:31] jdlrobson: No, it wouldn't. MCS hasn't had a summary endpoint in a long time. If you are talking about the one exposed in RB that's a whole different story. That's a different service. [20:12:32] So far RB is only exposing the call the MW API (TextExtracts) for summary, and is not invoking MCS for that yet. [20:17:42] bearND: thanks for the headsup.. ping me when that gets deployed to beta [20:19:11] Pchelolo: If you can merge it then I can deploy it during this hour. [20:20:32] done bearND [20:21:17] Pchelolo: opps, sorry. Try again. I just updated the commit message to link it to T168848 since it had some discussion about it. [20:21:21] T168848: Bootstrap an initial version of the Page Summary API in MCS - https://phabricator.wikimedia.org/T168848 [20:21:48] done [20:23:04] Pchelolo: great. While you're at it, would you also take a peek at https://gerrit.wikimedia.org/r/#/c/376139/? I copied some of the spec from RB. [20:23:16] with some modifications [20:29:49] bearND mdholloway i see, thanks! [20:29:53] Pchelolo: in mobile-sections MCS also accepts revision and tid. Why should we not do the same for summary? [20:31:14] bearND: we can support that no problem, just the parameters should not be required [20:31:37] and in uri template the parameter that looks like {bla} is required. Optional looks like {/bla} [20:31:56] Pchelolo: ah, i see. Thanks! [20:32:34] Pchelolo: is this better? /{domain}/v1/page/summary/{title}{/revision}{/tid}: [20:32:59] 👍 [20:33:39] I don't really think exposing a tid is useful though, nobody cares about a particular render of a page [20:34:08] Also, I guess we will not expose event the revision portion from RESTBase as it's not really needed by any client [20:36:46] Pchelolo: I guess we could leave it off in RB at the beginning until there's a need for it [20:37:05] yup yup [20:37:48] Pchelolo: OK, I'm going to cut the release. I hope you don't need the spec filled out yet. [20:38:16] nope, no need for that, we will just make the tests on the RB PR pass