[10:20:18] Ugh, maybe we need to refresh our homepage again. Content-wise. [10:34:47] sjoerddebruin: do it! :P [10:35:07] Not so good in writing and thinking. :P [10:44:12] Adrian_WMDE: any idea https://phabricator.wikimedia.org/T96264#1783853 ? [10:45:01] jzerebecki: any idea what settings deployment-prep / beta has for the job queue? [10:45:08] or where to find them? :0 [10:45:23] addshore: its also in mediawiki-config [10:45:30] ahh, cool! [11:11:02] addshore: though some settings are in operations/puppet (same for beta/test/production) [11:22:20] the date parser works in such mysterious ways... I pasted "1901년 12월 26일" and it quite happily parsed it... then I pasted "1931년 7월 11일" but that's apparently malformed... but if I remove the korean characters, it can suddenly understand it, even though it didn't have a problem with the korean characters just a moment before... [11:24:35] I don't recall it ever working for east asian dates before though, so having it work for some of them was a nice surprise [11:41:46] nikki: hahaaaa, dates are just one big ball of fun ;) [11:43:05] yes parsing them without knowing their language is not always possible [11:44:27] * aude wants handling of farsi digits :) [11:45:09] sure, it's just weird that it has no problem with one thing and has no idea what to do with something that's pretty much the same [11:47:10] maybe because "1931 [11:47:31] 1931? 7? 11? could be interpreted as july 11 1931 or november 7 1931 [11:47:52] but 1901? 12? 26? can only be sanely be interpreted as december 26 [11:48:10] don't know about the korean characters though [11:49:59] could be... [11:54:41] it'd be nice if it offered multiple suggestions if there are multiple interpretations, instead of rejecting it as malformed or just picking one and ignoring the fact it's actually ambiguous [11:55:21] (although the korean one is not actually ambiguous, since the characters mean year, month and day) [12:03:48] I've never come across yyyy dd mm before though, so it's weird that it's picky about that, but then quite happily assumes that something like 2/3/yyyy must be mm/dd/yyyy when it's often dd/mm/yyyy... but like I said, it works in mysterious ways :P [12:04:24] jzerebecki: if we are deploying https://gerrit.wikimedia.org/r/#/c/251219/ then i would like https://gerrit.wikimedia.org/r/#/c/250999/ also [12:04:58] (hoo needs to look again but i don't think the -1 is really valid, or a follow up can be done if he has better wording) [12:07:02] aude: i'll take a look later [12:07:12] k [12:09:19] frimelle! [12:16:18] Ehw, that WIkidata spam on Twitter is terrible. [12:16:32] ? :O [12:16:51] https://twitter.com/search?f=tweets&vertical=default&q=%22the%20file%20numbers%22&src=typd&lang=nl [12:18:13] All of them also have a unique client to post the tweet with. [12:18:50] all of the spam [12:19:30] Yup, I've filtered a lot in my Twitter client to actually read the good stuff. [12:19:51] Worried about http://www.semrush.com/blog/seo-professionals-how-to-get-started-with-wikidata/ [12:20:00] "Create at least one backup account" [12:20:12] "Don’t say you’re an agency or an in-house." [12:20:44] "Since Wikipedia is the most trusted source" [12:22:08] lol [12:33:44] sjoerddebruin: hah [14:19:42] jzerebecki: aude: Lydia_WMDE: https://gerrit.wikimedia.org/r/251237 [14:19:49] Prepared that for early SWAT [14:20:03] thx! [14:20:03] probably wont be there, but will watch the deploy later today [14:20:21] Jan signed it up, so I suppose he volunteers to watch it [14:20:33] yes [14:20:58] hoo: aude asked for https://gerrit.wikimedia.org/r/#/c/250999/ also to be in that swat, can you take a look? [14:21:17] sounds ok to me [14:22:18] I reviewed that earlier, so easy +2 [14:23:23] brb [14:34:46] Battery time is being significantly reduced, when compiling, as it turns out :D [14:38:38] amended the build [14:53:47] I'll be back for the deploy o/ [15:40:02] * aude waves :) [15:50:21] Hey folks. I'm trying to figured out if WikiData has some facility for grouping together articles that have a sub-article relationship into a single item. [15:50:28] E.g. http://en.wikipedia.org/wiki/United_States and https://en.wikipedia.org/wiki/History_of_the_United_States [15:55:44] halfak: not that i know yet [15:56:00] Gotcha. Do you think this might be valuable? [15:56:01] suppose this could be a property, like subtopic / parent topic [15:56:48] personal opinion is that we need it and it woudl be nice if detailed more climate info (etc) could go into Climate of the United States etc. [15:57:08] like we split up wikipedia articles when they get too big [15:57:15] +1 [15:57:30] The United States item locks up my browser for a few seconds when I load it :S [15:57:36] * aude nods :( [15:58:01] Anyway, I'm wondering about how this would work with wikis that split an topic into multiple articles and wikis that do not. [15:58:09] we'd just need a nice way to be able to find these statements, if not on a main item, then are they on a subtopic [15:58:15] E.g. I'm sure theres a language that just has one article for United States. [15:58:17] i have no idea [15:58:42] maybe make a phabricator task about this, so people can give suggestions and ideas [15:58:51] It turns out that this is really important for algorithms that use Wikidata/wikipedia as a datasource. [15:58:56] yeah [15:59:13] Sure! Will do. Should I make the project "wikidata"? [15:59:15] i'm sure others have other opinion on how to do this [15:59:18] sure [15:59:21] Thanks :) [16:00:23] addshore: good we encrypted those two emails. Who knows what would have happened if the NSA read them! [16:00:39] (they probably did anyway but whatever) [16:01:47] halfak, aude: i think there is a property for that, like facet of or something. [16:02:16] Interesting. [16:02:28] If that already exists and works pretty well, that would make things easier :) [16:03:24] jzerebecki: sounds right, but then do we have the inverse? [16:03:53] * aude sees https://www.wikidata.org/wiki/Property:P1269 [16:05:25] jzerebecki: https://phabricator.wikimedia.org/F2918940 the search box looks slightly strange, btw [16:05:57] i am logged out but the "item by sitelink" gadget appears enabled [16:09:15] aude, task filed https://phabricator.wikimedia.org/T117875 [16:09:22] Thanks for your help. [16:10:35] halfak: thanks for asking [16:12:25] aude: oh noes, my search script =o [16:12:40] fixed it but is still cached. Why did they make the search form larger? [16:13:33] benestar: to display more of our descriptions ;) [16:13:50] haha, I see [16:16:55] benestar: no idea [16:21:00] Ah, I see. [16:43:07] Thiemo_WMDE: aude Why does EntityParserOutputDataUpdater have a finish method? Can this work not be done in processEntity? I don't see any batching or similar stuff that would explain this split [16:43:23] it does? [16:44:01] JeroenDeDauw: we need to do stuff when updating parser output [16:44:21] we collect info, statement by statement, (e.g. for geodata, for page images, ...) [16:44:30] then update the parser output at once [16:49:02] aude: are you saying it does do batching? Where should I look to see this? [16:49:57] EntityParserOutputGenerator? [16:54:01] aude: hmmm... still not seeing any batching. You avoid interleaving the calls to processSomething and updateParserOutput on the dataUpdaters... does that actually make any difference though? [16:55:25] it loops through statements once [16:55:39] (original idea was to operate on snak level, but that doesn't work for everythign) [16:56:05] aude: so no SWAT as wmf.5 on tin is unexpectedly dirty. either someone manages to tack it onto the train or we use the SWAT at 0100. I won't be online during the train. [16:56:16] jzerebecki: rage! [16:56:37] hoo said he would help keep an eye on things if there is a problem with wikidata stuff [16:56:47] but most likely it's all good [16:57:28] i think some of these things have been broken though, so waiting until monday is not terrible [16:57:30] aude: ok [16:58:15] JeroenDeDauw: would be good to do some/more benchmarking and improve it [16:58:34] and i'd like to split the item updates (site link parts) [17:12:49] Lydia_WMDE_: https://phabricator.wikimedia.org/T112550 [18:08:54] ALL the dependencies! http://img.ctrlv.in/img/15/11/05/563b9b20e4992.jpg [18:09:00] addshore: benestar|cloud ^ [18:50:44] hoo|busy, aude: *sigh* its taking much longer than I thought. seems I won't be online when the sync for the backport actually happens. [20:34:54] JeroenDeDauw: the bottom is cut :S [20:40:32] hey Ainali [20:40:42] hello multichill [20:41:01] Completely volunteer again? [20:41:22] no, still the ED until January :) [20:51:08] Do you already know what you're going to do after that? [21:00:18] multichill: I have some cool ideas, but nothing official yet [21:10:57] * benestar waves [22:04:10] hi [22:04:40] can anyone help me to use the wikipedia