[10:28:54] just finishing up the code review for 219153 [10:29:13] both boys are fast asleep at the moment [14:30:20] dbrant: hey! i'm trying to remember what used to be shared as text (admittedly a feature i didn't play with all that often). Does something like the user-highlighted text followed by "
on Wikipedia. " seem reasonable? That's what I seem to remember. [14:33:35] mdholloway: so, technically, the way it used to work is: if you share the article with *no* text highlighted, then it would share the URL of the article. But since now we default to sharing the first paragraph of text in the case of nothing highlighted, we no longer share the URL. (that's where this issue is coming from)... [14:33:56] mdholloway: ...but I think what you're describing is perfectly reasonable. [14:34:30] dbrant: cool, i'll get rolling on that [14:37:07] phuedx: did you see my message about ICFP? [14:37:12] joakino: ^ [14:59:27] bgerstle: yeah, thanks for the ping [14:59:44] it's unlikely i'm going to be travelling much this year though [15:00:53] gtg -- boys have just arrived back with their grandma [15:04:38] dbrant: looks like there's already a string resource (snippet_share_text) that i can use. so it's about done. but before i push for review, any objection to my taking out the @ in front of "@Wikipedia" in the string resource? [15:04:58] dbrant: i know it's supposed to refer to the Twitter account, but there are lots of ways besides Twitter that people can be sharing facts [15:05:21] dbrant: not to mention that it's in plain text and won't link to the Twitter account [15:06:53] mdholloway: well... Twitter is the primary means by which we "want" users to share facts... [15:07:01] mdholloway: and where would the URL go in that string? [15:08:21] dbrant: here's an example of the current output (after the selected snippet): "Chelsea Bridge" on @Wikipedia: https://en.wikipedia.org/wiki/Chelsea_Bridge?wprov=sfia1 [15:09:25] mdholloway: so the highlighted text wouldn't be shared? [15:10:02] dbrant: no, it would. [15:10:27] just forwarded you an example i shared to my gmail [15:10:31] dbrant: of what i have now [15:12:14] mdholloway: ah i see; so you're doing [highlighted text] + \n\n + [snippet_share_text] [15:12:28] dbrant: yep [15:12:57] mdholloway: ...i see no problems with that. [15:13:49] dbrant: cool. I guess I can live with the @. [15:14:21] dbrant: plus, that avoids modifying the existing string resource. [15:14:34] mdholloway: excellent [15:14:35] mdholloway: wrt sharing the url on twitter, do we use a link shortener? [15:16:35] niedzielski: nope. [15:16:50] mdholloway: maybe a future enhancement [15:17:35] mdholloway: we start getting into special cases with the destination app and the stock intent picker just doesn't cut it anymore [15:17:41] so limited [15:19:05] niedzielski: what kinds of cases have you seen? [15:19:45] Also, it looks like the default snippet plus [title/url] is going to generally be too long for Twitter, the way I have it now. [15:19:47] Hmm. [15:22:00] mdholloway: the case i just described, you probably *don't* want to shorten the url for all services except twitter / identi.ca. on a previous app, we wanted to record which app was selected, if any, and also adjust the ordering. i think most of hte problems stemmed from lack of detail in the result returned [15:31:22] niedzielski: yeah, worth opening up a phab task about shortening urls for sharing to microblogging sites. i'd worry about the privacy/security issues of shortening urls, although i suppose in theory we could roll our own url shortener to mitigate that. [15:31:34] maybe in the future we could have a checkbox that let the user decide whether to shorten it [15:32:25] yeah, that's a good point. i was hoping there was some shortwiki or something i just hadn't heard about yet :) [15:32:52] niedzielski: ha, i wouldn't be totally surprised to hear someone has already done it! [15:35:48] niedzielski: In any case, right now for Twitter/identi.ca, should I just truncate the user selection to accommodate the 140-character limit including the full URL? dbrant, what do you think? [15:42:40] mdholloway: hmm, that's tricky. how about we don't do any automatic truncation for now, and let the user trim down the text if necessary, if they share it on Twitter. [15:42:52] mdholloway: a url shortener would indeed help a lot... [15:43:34] dbrant: Works for me. [15:43:46] mdholloway: After shortening the text to fit the URL + the wrapper text in, how much useful text from the article is left? [15:45:32] bearND: I haven't implemented it yet. Would depend on the URL length (i.e., the length of the article name), I suppose, but in practice you'd get at most a short sentence, I think. [15:46:10] How many people are actually sharing facts to Twitter as text? Do we have numbers [15:46:11] ? [15:48:56] I'd speculate that it's fairly uncommon. [15:50:11] In any case, the more I think about it, the more I like dbrant's suggested approach of letting the user decide how to cut it down to Twitter-size [15:50:18] mdholloway: our eventlogging can't tell us which app the user shared the text to... So, all we can do is search Twitter for something like "wprov=sfia1", and see the results. [15:50:58] (and it's mostly images) [15:51:45] dbrant: yeah, just looking. images definitely predominate, but people do share as text. [15:53:00] mdholloway: if we had more room, we could add a #WikipediaAndroid tag [15:58:11] niedzielski: maybe we could start a twitter account for the app, to announce releases and whatnot? might help with the apparently widespread problem of people not realizing a Wikipedia app exists [15:58:32] mdholloway: I would be interested to know whether most "share a text" events are after text was selected or not. In the latter case these people wanted to copy the URL to the clipboard, as the app did until last release. [16:00:17] mdholloway: my initial reaction would be to try to get announcements published on @wikimedia since that likely has a larger audience. i wouldn't be against a wikipedia for android twitter tho [16:02:23] niedzielski: hmm, looks like they did announce the latest iOS release. [16:06:21] mdholloway: niedzielski: rest assured i'll coordinate with Comms to publicize our next production release ;) [16:06:46] :) [17:01:25] rmoen kaldari standing? [17:14:57] bearND: mdholloway mhurd coreyfloyd dbrant bgerstle standup [17:30:11] niedzielski: sorry i didn't realize you updated the patch. can have a look in a bit [17:31:20] bgerstle: no worries, sorry for the noise. i probably won't be able to respond to feedback on that patch today or over the weekend anyway so not a huge rush [17:31:48] mdholloway: regarding this one: https://phabricator.wikimedia.org/T73136 does it mean you'll address vibha's comments in a separate task? [17:32:39] dbrant: I was hoping vibha would create a task with specific requirements -- I was actually just looking to see if by any chance she'd done so. [17:32:49] dbrant: yeah I already did that [17:32:55] one second, finding the ticket [17:33:22] vibha: oh, cool, i didn't find it. let's reference it in T73136 so they're linked for posterity [17:33:37] makes sense, I should have done that. [17:34:04] mdholloway: will that include the visual change to the "en" button? or is that still part of the current task? [17:34:23] dbrant: nope, the new task involves solely the language selection dialog [17:34:41] dbrant: changes to the button/toolbar are still withiin the current task [17:35:00] mdholloway: ok cool; i'll move it back to "doing" then [17:35:11] dbrant: ok! [17:37:19] found it!!! [17:37:20] https://phabricator.wikimedia.org/T105429 [17:37:30] its an accomplishment finding anything in phabrictaor [17:37:33] i'll link the tickets [17:51:14] vibha: thanks! [17:56:19] niedzielski: edit pencil stuff looks good! mhurd's having a look as well just to double check [17:56:33] just running the app on master to check for differences.. [17:57:01] minor nit-pick, is that the current method of special-casing styles for platforms results in iOS downloading styles that aren't used (.android) [17:57:27] i might be nice (if we have time to refine this in the future) to just import & override styles per platform (in separate files), but it's not crucial right now [17:57:55] niedzielski: seems the same on master, so mission accomplished AFAICT [17:58:03] bgerstle: bearND expressed a similar concern. i think there's a tradeoff between dev time and data usage. i believe that the single file improves code reuse [17:58:21] niedzielski: i agree that copy/pasting is not a good trade-off either [17:58:33] i think having one file that's explicity for cross-platform styles [17:58:39] and then separate files for special cases for each platform [17:58:42] is a good compromise though [17:58:56] this way the compiled CSS doesn't have styles that don't belong to the target platform [17:59:02] and we still have an easy way to reuse styles [17:59:28] so, edit-links.less < edit-links.android.less & edit-links.ios.less [17:59:29] bgerstle: ok that makes sense. ok if i make a phab for that? [17:59:37] where .ios & .android @import the shared one [17:59:50] niedzielski: absolutely, no pressing need to do it now [18:00:45] niedzielski: would you mind subscribing mhurd and myself when you make it? [18:00:56] bgerstle: sounds good. will do [18:01:35] niedzielski: also, i might amend your patch to just the Makefile changes and submit that for review [18:01:47] so we don't need to re-patch the Makefile to point at vagrant [18:03:20] niedzielski: bearND +1'd https://gerrit.wikimedia.org/r/#/c/219421/ [18:03:30] bgerstle: fine by me. actually, my personal preference was to submit that as a distinct patch but i mistakenly understood ios to want a single patch [18:03:54] niedzielski: yeah, nbd [18:03:58] easy enough to cherry-pick [18:22:16] vibha: i added an updated screenshot to the ticket [18:30:18] coreyfloyd: bgerstle mhurd estimation time [18:31:34] mbinder: we're in the hangout [18:32:09] mhurd: mind closing it and rejoining? I think some funky things happened when making calendar changes [18:33:27] mhurd: bgerstle coreyfloyd There are likely 2 rooms. If you close out and rejoin I think we'll all be in the same one. [18:34:20] any luck? [18:53:16] mdholloway|brb: taking a look [20:21:56] niedzielski: are you running java 1.7? [20:22:20] mdholloway: yeah, OpenJDK 1.7 [20:23:27] niedzielski: i think it's version issues that are causing my error when trying to build the project with your patches [20:24:27] mdholloway: thanks for trying! i'm wrapping up some design feedback and see what's up soon [20:24:30] can see* [20:26:05] niedzielski: cool, and i'll let you know if i find a fix [20:26:14] mdholloway: thanks! [20:30:20] niedzielski: i see google still recommends java 7 at https://developer.android.com/sdk/index.html. maybe i'll drop down to 7 and retry [20:31:42] mdholloway: although i haven't looked into the detail of your report, i suspect the java version is not likely the culprit. a former colleague of mine used to use os x with Sun JDK8 and lots of submodules [20:32:09] i'd hate to put you through the pain of changing jdk versions for no reason [20:32:21] kristenlans: Ping! [20:32:26] mdholloway: IT gave me a present to give you at Wikimania. :-) [20:32:37] Deskana: yes! [20:32:55] Deskana: looking forward to seeing you there! [20:46:37] niedzielski: mdholloway : look like 1.8 JDK is the culprit. I had it at 1.8 and ran into build issues with the git submodule patch. Then I switched back to 1.7 and it was fine. [20:46:42] looks [20:46:50] bearND mdholloway dbrant|brb: i recommend when removing language strings, we capture all languages. when the default is not present and nondefault are, release builds fail due to lint :( it's true that a translation update fixes it, but i see no reason why we should temporarily break release builds. the following command line does a pretty good job: find -name strings.xml|xargs -rd\\n sed -ri [20:46:51] '/"STRING_NAME_HERE"/d' [20:47:13] bearND mdholloway: i stand corrected :) [20:47:49] bearND mdholloway: if that's the case, maybe i just need to explicitly specificy a Java 7 compilation in the gradle file [20:48:13] niedzielski: yes, i think that should work [20:49:33] niedzielski: fair point on the string removal. maybe we should add that to the "hacking on the wikipedia app" wiki. [20:50:07] bearND: niedzielski: i'll give building with submodule another try now. [20:53:41] niedzielski: yes, i agree it's better to remove translated strings at the same time the English string is removed. [20:55:17] mdholloway: niedzielski : http://stackoverflow.com/questions/24662801/bad-class-file-magic-or-version is what i ran into, so yes switching the gradle options should do the trick. [20:56:34] bearND: niedzielski: same here. i just built it successfully with 1.7 [21:00:35] mdholloway bearND: thanks for debugging guys. i'll submit a fix when i get a chance [21:09:19] niedzielski: added a comment to the java-mwapi patch. It needs to be changed there. [21:10:36] bearND: thanks again! [21:46:17] kaldari: hey are you around? [21:46:32] yeah [21:47:05] kaldari: how do we restyle the main page for mobile? [21:47:41] kaldari: I see that we take out did you know, on this day, featured pic and so on [21:47:49] mdholloway: so the toc button has been in the app for a while. i really like it. feels very androidy and materialish. good stuff [21:48:14] niedzielski: awesome! i'm glad! yeah, big improvement over the toolbar-based button for sure [21:48:30] kaldari: are we pulling in featured article and in the news individually or are we just hiding some things? [21:48:31] i've been complaining about toolbar clutter for some time [21:48:49] mdholloway: yeah it was actually a minefield trying to get to it in the toolbar. too many buttons [21:49:34] kaity: https://www.mediawiki.org/wiki/Mobile_Gateway/Mobile_homepage_formatting [21:49:50] kaldari: perfect thanks [21:49:59] kaity: basically, it's based on class names assigned to various sections of the MainPage by the editors [21:50:52] niedzielski: and it really surfaces it nicely. before, even i forgot the TOC was there half the time, and I work on the app. [21:50:53] coreyfloyd: check it out ^ [21:51:00] coreyfloyd: https://www.mediawiki.org/wiki/Mobile_Gateway/Mobile_homepage_formatting [21:51:24] kaity: also, there's a shorter version at https://www.mediawiki.org/wiki/Extension:MobileFrontend#Configuring_the_main_page [21:55:00] kaity: cool - so do we need to look through that to see whats possible then? [21:55:08] do you want me to make a spike ticket to investigate?