[00:24:51] o// [09:19:24] hullo [10:31:18] hi phuedx [10:31:22] hi bman [10:31:27] hey joakino [10:31:30] how're you? [10:31:35] * joakino failed hitting tab [10:32:21] phuedx: preparing travel stuff, hotel, insurance, all that crap [10:32:24] and you? [10:32:34] yeah [10:32:38] code reviewin' [10:32:44] got a bunch of emails to write [10:34:21] about? [10:34:26] phuedx: ^ [10:36:20] extracting mobileview, watchlist continuations stuff [10:36:25] stuff i should've written about a while ago [11:20:17] out for lunch [15:56:23] greg-g: is the finland banner popping up in the states? [15:58:46] joakino: I'm bowing out of the discussion, see ori's thread on wikitech [15:58:55] oh k [15:59:22] short answer: don't know, but I'd still like to see something public about the experiment [16:00:27] greg-g: seems it's only showing in Finland (as per CN conf), but yeah, agreed. Anne is on holidays, not sure who's covering for her [16:00:34] i'll try to find out [16:01:17] joakino: mbinder dr0ptp4kt are you guys in the hangout? [16:02:36] there's this https://phabricator.wikimedia.org/T103896 [16:02:42] not yet bgerstle [16:02:51] bgerstle: yes, can you join? [16:02:56] bgerstle: want link? [16:02:58] yes plz [16:04:24] bgerstle: sent invite [16:04:34] mbinder: got a link from joakino i'm in [16:29:12] I am not able to use message API using message in javascript . I have included message key in includes/resources.php , message in init.js .What else should I do? [16:34:25] adisha: can you upload the code you have so far? :) [16:34:52] FlorianSW : ya I am doing that only.. :) [16:35:18] adisha: ok, you've added the message keys to the mobile.search array as "messages", yes? [16:35:33] If so, you can use "mw.msg( 'msgkey' );" to get the message in JavaScript :) [16:40:18] FlorianSW I have uploaded it please have a look. [16:40:36] * FlorianSW looks @ adisha's change [16:57:57] FlorianSW : I have applied both the comments. But It javascript is not working properly.. [16:58:00] :( [17:00:16] adisha: what does not work? (btw.: Instead of mw.message().text() you can use mw.msg(), iirc) [17:09:03] FlorianSW jshint test is also failing my patch..:( [17:10:05] adisha: if you click on "jshint", you can see, why the change failed in the tests :) In your case it's a bit of code style 17:02:59 resources/mobile.search/init.js: line 53, col 45, Missing semicolon. 17:02:59 resources/mobile.search/init.js: line 50, col 5, 'searchPlaceholderMsg' is not defined. 17:02:59 resources/mobile.search/init.js: line 52, col 9, 'searchPlaceholderMsg' is not defined. 17:02:59 resources/mobile.searc [17:11:16] rmoen: https://gerrit.wikimedia.org/r/235267 [17:31:31] FlorianSW Finally it is done.. I was facing stupid syntax error.. :( [17:31:32] you can checkit [17:31:52] adisha: wohoo! :) Give some minutes to finish my current work, ok? :) [17:32:40] yeah... [17:32:51] take your time I am in no hurry.. [17:33:07] and bye gtg exams tommorow..:) [20:41:40] bearND mdholloway: hello. i'm trying to port some of dbrant's link preview functionality. part of the algorithm is dependent on localized sentence boundaries detection. do you have any recommendations for getting BreakIterator-like functionality in javascript? [20:44:04] niedzielski: hey! nothing off the top of my head unfortunately. [20:44:23] mdholloway: wb! [20:44:30] niedzielski: thanks! [20:47:16] niedzielski: maybe this one: https://www.npmjs.com/package/sentence-tokenizer. I haven't tried it myself. I just found it through a search. [20:49:37] If there is no suitable npm module then you could theoretically also try regex [20:51:55] niedzielski: but keep in mind that a regex doesn't take locale into account: http://stackoverflow.com/questions/4482469/splitting-text-to-sentences-and-sentence-to-words-breakiterator-vs-regular-expr. Looks like neither does the above npm package from what I could glance. [20:52:38] bearND: yeah, looking at the source this doesn't appear locale aware [20:53:02] bearND: i'll see what i can find. i didn't know if we had a nice solution already in place that i was missing [20:57:04] niedzielski: frankly, I'm not sure why we even modify the text extract string. I thought the point of text extracts was that it's already stripped out unnecessary text. [20:59:56] niedzielski: do you remember why we can't use exsentences=2 anymore? [21:00:29] bearND: i do not, but i saw that it was commented out [21:05:54] I will let you know when I see dbrant around here [21:05:54] @notify dbrant [21:09:05] Deskana: i'm looking at https://office.wikimedia.org/wiki/Communications but don't see their main contact address is it communications@ ? [21:12:35] tfinc: I normally email Juliet directly. [21:13:02] k [21:40:01] bearND: for the "error handling in service" thread you started, is there a phab for that? [21:41:55] niedzielski: no, because Marko said that we don't have to do anything. There is one related task I'm going to add, though, which is to avoid the exception when an API error occurs. [21:42:35] bearND: does this cover examining MW response bodies for errors, even for status code 200? [21:46:46] niedzielski: no, it doesn't. Actually, in the retrofit patch, I've already started looking for an error object. If that is present then the app wouldn't proceed with the rest. [21:48:26] bearND: er, sorry i'm talking about the restbase service. if i make a request for a page that doesn't exist, i want that to error out at the lowest level the same way a 404 would, for example [21:50:41] niedzielski: yeah, currently you get a 500 since the code throws an exception trying to access the sections[] when there is none. If we make it not throw the exception but have section be null then theoretically RB should return 404 [21:55:57] RB will pass through your status [21:56:18] bearND: yeah, i think it should throw that exception in mwapi.js in some like response preprocessing that gets done before passing it out to the client callback. this way, all that nasty weirdness is handled in the same way for all requests and the clients just get a well formed response or nothing (exception) [21:56:37] gwicke: ^ [21:57:34] it's useful to return a meaningful error though, not just 'nothing' [21:57:45] niedzielski: https://phabricator.wikimedia.org/T111114 [21:57:55] gwicke: yeah, but can't we handle that at the lowest layer for all responses in the same way? [21:58:19] gwicke: rather than make each route handle parsing MW API responses in its own way [21:59:40] in RB, we handle MW API responses generically, and raise an HTTPError that wraps the response if the response doesn't check out [21:59:54] that way, we get automatic error propagation [22:00:37] preq also raises errors for response codes >= 400, but the MW API often returns 200 & indicates errors only in the body [22:02:14] for the responses, we generally use http://tools.ietf.org/html/draft-nottingham-http-problem-07 [22:05:45] gwicke: so for mobile-html-sections-lead, if i request a nonexistent page, i get a 500 in pageContentPromise() of mobile-html-sections.js where we assume the response is good [22:06:40] it would probably be cleaner to check the response as early as possible & raise a semantically more useful error [22:06:59] something indicating that the sections response is not kosher, for example [22:07:52] gwicke: so right now we're not raising any error AFAIK. we happen to be assuming that a response contains something that it doesn't which causes a server error. the phab i'm talking about would fix that at the lowest layer [22:08:46] niedzielski: yeah, that sounds good to me [22:09:19] if missing sections indicate that the page doesn't exist, then a 404 makes more sense [22:09:35] it's trickier when a backend service is temporarily down [22:10:11] gwicke: well, right now the api is actually returning a body with a code of "missingtitle". surely we can do this kind of check at the lower layer and raise an HTTPError like you say [22:11:03] you could consider 502 (bad gateway) or 504 (gateway timeout) as well [22:11:28] agreed re checking [22:12:16] gwicke: i think bearND's T111114 will cover this if i understand it right [22:19:09] bearND: i think the reason exsentences wasn't used is because it's not super reliable. for San Francisco, exsentences=2 returns 2 sentences. for "Who Let The Dogs Out?", it returns 3. i think is because of date formatting in the extract. for example, see the berlin wall article [22:22:47] bearND: i do kind of wonder if it would still end up doing a better job then us since the worse case scenario so far has been too many sentences [22:23:06] niedzielski: yeah, i think it would be better to fix this upstream then (not saying that's easier) [22:23:24] bearND: this seems to be the appropriate line? https://phabricator.wikimedia.org/diffusion/ETEX/browse/master/includes/ExtractFormatter.php;1619d0ed9316983a1cb8bfd2ee3bf26066126cdc$82 [22:24:06] bearND: i think [^\d]\.\s supports my date theory [22:30:59] niedzielski: Looks like it. I don't think this one is meant for dates. I think it's to not include ordinals in some other languages. ("4th " in German would be "4. ") [22:31:49] bearND: seems like this phab is pretty closely related: https://phabricator.wikimedia.org/T59669. i guess it doesn't work for articles like H. P. Lovecraft either [22:37:56] bearND: so in the case that we're using parsoid, we'd still have to handle this on our side because we'd just be getting raw html back, right? [22:38:36] niedzielski: are you talking about text extracts + Parsoid? [22:38:43] bearND: sorry, yes [22:39:17] niedzielski: I doubt Parsoid does text extracts (cc:gwicke) [22:40:18] bearND: it doesn't yet, but seeing how popular text extracts are & how parsoid's semantic HTML can help the use case I'd be very interested in changing that [22:40:49] gwicke: niedzielski: that would be awesome [22:43:08] looking at the extension code, it doesn't even look that hard [22:46:33] we have an official goal of tackling some of the high-traffic API end points next quarter, and textextracts and pageimages are the first ones we have set our sights on [22:46:34] gwicke: do you think regex will be "good enough"? it seems like you'd have to have pretty good context to understand what was a true sentence termination in a given locale [22:47:20] the content translation folks might actually have better sentence segmentation code [22:48:08] https://github.com/wikimedia/mediawiki-services-cxserver/tree/42366db2008c25b80089a56a34639ebe018f2486/tests/segmentation [22:48:23] https://github.com/wikimedia/mediawiki-services-cxserver/blob/0d21a808f7ab6b82086171af927467c1b9460626/segmentation/languages/index.js#L3 [22:55:36] gwicke bearND: yeah, looks nicer! [22:56:40] nice :)