[09:50:46] gahhhh the sparql interface changed again [09:57:21] I should figure out how to clear the page and insert my own damn interface where everything is always in the same place so I never have to be annoyed by things moving around ever again [10:32:57] ugh and why does the query box and run button vanish if I move down even slightly? [10:33:32] messes up the scrolling too [10:34:25] https://grafana.wikimedia.org/dashboard/db/wikidata-dispatch?refresh=1m&orgId=1&from=now-24h&to=now :) [10:35:07] no language fallback either [11:28:12] dispatch rising again over the past 40 minutes (both lag and pending)… [11:32:31] and some spikes in edits... https://grafana.wikimedia.org/dashboard/db/wikidata-edits?refresh=1m&panelId=1&fullscreen&orgId=1&from=now-6h&to=now [11:33:05] hooray [11:33:54] that shouldn't be problematic though... [11:34:41] Yesterday only 237,493 edits. http://wikidata.wikiscan.org/date/20170724/stats [11:49:06] Ugh, the entity suggester is most terrible on creative work items. [13:03:10] DanielK_WMDE: Lydia_WMDE: there is a mediawiki config change proposed to "Add P279 to $wgPropertySuggesterClassifyingPropertyIds" https://gerrit.wikimedia.org/r/#/c/366866/ [13:03:30] has been added to SWAT by Amir1 and really I have no clue what that is supposed to do :-} [13:08:31] hashar: should be ok [13:09:57] though i see it needs an announcement... [13:13:18] apparently yeah [13:13:34] Daniel said to reach out to Lydia :} [13:15:14] holding the deployment for now [13:15:30] I will be out in roughly 45 minutes, but zeljkof should be able to catchup [13:15:35] ok [13:35:07] And then things broke... [13:40:19] hashar: hey :) i am currently at a conference and can only sync with Auregann_WMDE next monday about the announcement. ok to hold it until then? or rather not? [13:40:22] sorry! [13:40:30] Lydia_WMDE: no worry :) [13:41:00] Lydia_WMDE: I am dropping the patch from current window and will comment on the Gerrit change that it should be rescheduled this monday. Danke Schon! [13:41:09] perfect [13:41:10] thanks [13:47:36] hashar, aude: the config change is good to go I think. We just have to know when it happened, so we can announce it [13:47:56] Lydia_WMDE: ah, sorry, i was scrolled up [13:48:10] ;-) [13:48:14] Lydia_WMDE: I can do the announcement [13:48:48] up to you but I will not be able to deploy it right now. I am about to leave and there is some outage going on [13:48:54] but zeljko should be able to help [13:52:43] it's not really urgent... but it's really a misconfiguration leading to bad search completions, and i'd really like to see it fixed! [13:52:54] Lydia_WMDE: I can do the announcement too [13:53:22] Let's do it next week. But it'd be hlepful to get Léa the necessary info if you can [13:53:32] it's best if it comes from léa [13:56:09] k :-} [13:56:16] I am off. Poke Zeljko if you need a deployment [14:37:36] Question regarding Wiktionary sitelinks: will they never be visible from a Wikidata item or is it planned to show them in the future? [14:38:04] How do you mean? Note that they shouldn't be used for main namespace pages. [14:39:33] Yeah, that is sort of my question. Is it in the plans to make it possible to connect a wikidata item with a concept on Wiktionary? [14:39:50] I think they are working on that, yeah. [14:40:40] https://www.mediawiki.org/wiki/Extension:WikibaseLexeme/Data_Model [14:40:58] Nice, and I guess it will be done in a more specific way than to just link to a page (since they can hold several concepts) [14:41:43] sjoerddebruin: Thanks for the link! [14:51:32] yeah, lexemes will be closer to the individual sections of a page [14:53:18] there's also https://www.wikidata.org/wiki/Wikidata:Wiktionary [14:54:33] I had a suggestion on https://www.wikidata.org/wiki/Wikidata_talk:Wiktionary#L-items for how we could do interwiki links, I dunno if the developers will decide to do it, but I think it would be useful if they did [14:56:34] because there isn't really an easy way to create links between lexemes and wiktionary, whereas my suggestion would have automatic links that work a lot like wiktionary sitelinks already work [14:57:19] nikki: Also a good link, thanks! [15:31:43] nikki: at least some more improvement for Dutch :) https://www.dropbox.com/s/ikh6pjm651fboit/Schermafdruk%202017-07-25%2017.31.31.png?dl=0 [15:32:05] :o [15:32:14] but... :( https://www.dropbox.com/s/sobn6m6nnw9li86/Schermafdruk%202017-07-25%2017.32.09.png?dl=0 [15:32:41] centiliter is nowhere to find https://www.dropbox.com/s/9gpfn3tnon1ucou/Schermafdruk%202017-07-25%2017.32.30.png?dl=0 [15:33:02] units are a bit of a nightmare... the unit search should clearly prefer things which have been used as units before [15:33:40] until then, at least we shouldn't drop them even lower :P [15:33:43] like I have never wanted to use comoros as a unit [15:33:51] (km) [15:34:14] and if it *has* been used as a unit, that's probably only because the results are silly [15:34:49] minute is also third instead of second now [15:35:03] err... when you use "m" [15:35:14] and "h" gives hour 7th instead of 4th [15:35:37] do we have somewhere to report good/bad results yet? [15:35:47] Not yet, I think they want to make one... [15:35:52] But we can start in my namespace. :P [15:38:01] This is my personal list so far. https://www.wikidata.org/wiki/User:Sjoerddebruin/Cirrus [15:38:06] Will add the units now. [15:40:52] sculptor also improved a lot [15:42:34] "Trump" also seems more logical. [15:42:40] Same for "Obama" [15:43:49] In Dutch, excuse me. :P [15:44:03] Seems like fallback aliases got a boost. [15:52:18] https://www.dropbox.com/s/1qpk5qurg7ly879/Schermafdruk%202017-07-25%2017.52.14.png?dl=0 ;) [15:53:53] oh no, sjoerddebruin has discovered our nefarious motivation for this change ;) [16:14:14] Lucas_WMDE: do you have a local setup with entity suggestions? :) [16:14:41] my local setup seems to have entity suggestions, but I never took care to set it up explicitly [16:14:47] so I don’t know anything about how it works [16:15:05] Just wondering if you could test https://gerrit.wikimedia.org/r/#/c/356071/ [16:15:40] (and damn I wish the suggestions worked for the property namespace, those constraint properties are hard to remember) [16:17:49] oh, wait [16:18:06] no, I don’t have a PropertySuggester setup, sorry [16:18:18] I just get search results as soon as I start typing [16:18:23] I was confused [16:18:35] Yeah, it can be confusing. [16:18:41] Wish we had more people with the setup. [16:28:20] * Lucas_WMDE is testing his new PropertySuggester setup :) [16:30:41] Hm, odly specific. https://www.wikidata.org/wiki/Q22122765 [16:32:01] lol [16:36:24] sjoerddebruin: PropertySuggester setup was pretty straightforward and the patch seems to work. I’ll probably merge it tomorrow :) [16:36:32] :) [16:52:50] nikki: Any clue what the whole bunch of new Ja entries at https://www.wikidata.org/wiki/Wikidata:WikiProject_sum_of_all_paintings/Possible_paintings are? Take for example https://ja.wikipedia.org/wiki/%E8%A5%BF%E5%B0%BE%E6%85%B6%E6%B2%BB [16:53:59] That one looks like a human [16:56:07] heh yeah, another person [16:56:20] Meanwhile, Dispatch stalest lag went under 1 hour. \o/ [16:57:42] A whole bunch of them. Something from with their category tree? [16:58:00] One of them is Category:People of Kaga Province... [17:03:49] nikki: have you noticed that https://www.wikidata.org/wiki/Q5296 shows up in some results, like "star"? [17:04:44] and sometimes a xkcd comic moves to the first place... [17:04:50] haven't noticed that, no [17:06:02] I haven't figured out the category tree, but it doesn't seem unreasonable to have "people who do something" as a subcategory of "something" [17:08:06] It's in the category tree of Ukiyo-e [17:08:18] https://ja.wikipedia.org/wiki/Category:浮世絵 [17:08:23] And that one is in... https://ja.wikipedia.org/wiki/Category:日本の絵画 [17:08:28] aka Japanese paintings ;) [17:10:39] pff [17:32:26] multichill: I've done some of them, so far all the ones without an item that I checked have been people. if you remind me again another day, I'll do some more then [17:32:34] I think all the ones with items are ones I don't know enough about [17:41:14] SMalyshev: how much is possible with those search profiles, weights and ranking? Is it actually easy to lower disambiguation pages? [17:41:50] sjoerddebruin: hmm that may not be easy. The index doesn't know what "disambiguation page" is [17:42:10] But most do have a description, can't we do something with that? [17:43:06] sjoerddebruin: well, it might be possible to de-boost pages that have word "disambiguation" in english description, but I'm not sure whether this is a good idea to go that specific [17:43:31] sjoerddebruin: I'll make an announcement on the list soon, and that would be a good thing to raise in the discussion [17:43:40] Well, it's a common complaint... [17:44:11] I even made a ticket ages ago :P https://phabricator.wikimedia.org/T148411 [17:44:15] I _think_ it's possible to give certain words negative weights [17:45:48] also, we do not index descriptions yet (only store them). Eventually, we will, but right now we do not [17:46:16] we might be able to index P31 and do boosts on that (there's a separate request for that anyway) [17:46:20] is it possible to give more weight to items which have lots of backlinks yet? [17:46:31] yes, that should be not hard [17:46:43] we already have links in the index iirc [17:47:32] https://www.wikidata.org/wiki/Q42?action=cirrusDump <- you can check out what we have in the index [17:47:40] only mainspace incoming links would be great then [17:49:20] would it matter that much? i.e. if there are tons of external links, won't it still be important item? [17:49:27] I think that would help, the examples I've collected so far (https://www.wikidata.org/wiki/User:Nikki/Item_search) have all been cases where the item with the most backlinks is the most appropriate [17:49:41] some of those are better with the cirrus search, some are still the same [17:49:49] (or different but not in a way that improves it) [17:50:01] Think of given names for example [17:50:43] ok so what about given names? [17:50:57] They are not always listed where you expect them. [17:51:43] given names should be pretty high on incoming link counts, so they should rank pretty high. Don't they now? [17:52:40] There is some improvement already, but that also depends on what language you use now. [17:53:59] The right gender item for male is still listed second in cirrus ;) [17:54:06] (for German) [17:54:14] (ordered food, will be sharper soon) [17:54:37] And still third for Dutch. [17:54:43] well, we didn't even tune the params yet so hearing there's already improvement is very encouraging for me :) [17:55:10] what's the difference between uselang and matchlang btw? [17:55:21] but we will definitely need to record all these somewhere so we can tune it. there's a real lot of tuneable params on this one... [17:55:33] I've started https://www.wikidata.org/wiki/User:Sjoerddebruin/Cirrus [17:55:41] nikki: matchlang is the language in which match is made. uselang is one which is displayed [17:55:43] The jazz one is actually interesting. [17:55:50] usually they are the same but don't have to be [17:57:04] ah, so I can leave uselang in english when I want to test other languages? [17:57:40] Is it possible to boost aliases when you search for very short words? [17:57:51] Take for example "KLM", Dutch airline. [17:58:06] yes. uselang defaults to user's preferred ui language so you rarely see it explicitly used, but since it's not on wiki, you need to specify it. but you can leave it "en" :) [17:58:28] ok :) [17:58:50] sjoerddebruin: hmm I don't know if there's a way to do that, but I can check [17:59:32] Or anything else, I've noticed that results are clearly less better when searching for abbreviations. [18:01:15] hmm... just tried "män" in german, by that point the existing search has männlich first and männliches geschlecht third but cirrus has männlich fourth and doesn't show männliches geschlecht at all [18:01:42] presumably because it can ignore accents now, but the things it has near the top don't seem that relevant [18:02:00] Something is also going on with "Lentis", the exact match is listed last. [18:03:30] I see you added type for testing property ordering. My annoyances seem fixed already! :P [18:03:44] hehe but if I write "female" while it's set to german, existing has weiblich fifth whereas cirrus has it first [18:03:59] (commonscat is listed as first results in Dutch now for "common" instead of 6th) [18:05:12] This is also more logical.... https://www.dropbox.com/s/ut6pfxkw5x45aux/Schermafdruk%202017-07-25%2020.05.06.png?dl=0 [18:12:39] Fun detail: Elastic, the company is nowhere to find in the new results. :P [18:14:59] in properties: “date of b” is no longer “date of baptism in early childhood” and “image” is no longer “image of function”, so that’s nice :) [18:16:00] this also seems more logical :P https://www.dropbox.com/s/nd6fvc9n8ok43px/Schermafdruk%202017-07-25%2020.15.54.png?dl=0 [18:16:14] oh, and “imp” is “imported from” (in the old system, even “import” still prefers “total imports”), that’s going to make entering references much more convenient [18:16:37] *cough* not that I would ever use such weak references as “imported from enwp” *cough* [18:16:50] sjoerddebruin: hehe [18:17:18] Yeah, properties seem fine. :D [19:35:44] Look. https://grafana.wikimedia.org/dashboard/db/wikidata-dispatch?refresh=1m&orgId=1&from=now-1h&to=now [19:38:04] we are back, aren't we? [19:39:25] congratulations to all the servers involved! [19:40:32] And users and bots that paused or slowed down their tasks. [19:41:15] more importantly, indeed ^^ [19:42:21] stalest lag used to be around 30 s, so there is still some time to spend. [19:44:38] it used to be but we've got millions of new items, didn't have Wiktionaries... [19:50:03] median lag is still at 1.7 minutes, so theoretically bots shouldn't be allowed to edit at all, right? [19:50:28] How do you guys find this P31 construction? https://www.wikidata.org/wiki/Q33219598 [19:51:04] didn't we have a status property proposal or something? [19:53:40] * matej_suchanek was looking for a search in proposal but apparently it's missing [19:54:16] ah, https://www.wikidata.org/wiki/Wikidata:Property_proposal/Archive [19:57:40] Right... [19:58:32] in my opinion, there should always be only one P31 [19:59:13] Well, this is a solution that is preventing queries to show it as already existing and also pleasing constraints at the same time... [20:00:03] also, "deprecated rank" is for things that are wrong and will be wrong forever... [20:00:40] someone also argued that reason for deprecation should be part of a reference, not a qualifier [20:00:52] Hmmm [20:00:59] I don't think so [20:02:07] reference tells who said that [20:02:37] you can read about it here: https://lists.wikimedia.org/pipermail/wikidata/2016-August/009361.html [20:02:51] I'm not sure that deprecated has to be wrong forever, things do change. the statement that it's a tram stop is wrong, was wrong and will continue being wrong until the world changes [20:03:13] I think we need a "expected" property, so I can use that for the proposed statement... [20:03:21] in this case it probably will change, but we can't guarantee it [20:04:01] Something so we can construct queries to say "hey, is this finished yet" [20:06:53] Or should I just say "end date"? [20:07:23] yeah, dissolved entities are also problem [20:07:44] I wouldn't complain if we added more ranks for old/future values. I see so many misuses of deprecated when people just want to say that a value is old and definitely not preferred and then we could mark future values like this as "not correct... yet" [20:08:06] I'm going to post the currrent solution in the project chat, let's see. [20:08:20] I hope we will find a way how to express continuity of an entity without instance of intention etc. [20:25:02] sjoerddebruin: https://www.wikidata.org/wiki/Wikidata:Database_reports/without_claims_by_site/nlwiki is now starting before I really started editing ;-) [20:25:15] Yeah, I've noticed. [20:25:40] Trying to work the backlog down again... [20:25:59] I started editing Wikidata start 2009 :P [20:26:24] What? [20:26:55] https://www.wikidata.org/w/index.php?title=Special:Contributions/Multichill&dir=prev&limit=20&target=Multichill <- it's on the wiki, so it must be true! [20:27:11] Ha! [20:27:37] And looks like I was a sysop too back then, because I protected a template [20:37:26] oh, sjoerddebruin, multichill: could you have a look at https://www.wikidata.org/wiki/Q8582846 and see if the dutch sitelink is right or if it should be moved to https://www.wikidata.org/wiki/Q8853278? [20:37:42] It's right. [20:37:51] Oh wait [20:38:01] That's confusing, lol. [20:38:49] yeah, that's why I'm asking :) [20:39:04] Yeah, I moved it. [20:39:08] I'm getting sleepy lol [20:39:11] thanks [21:45:09] Amir1: If you want https://github.com/wmde/wikiba.se to redirect to https://github.com/wikimedia/wikibase-wikiba.se, please transfer the wmde repo to @Krinkle and I'll perform the rename/delete dance to end up with such redirect. [21:45:40] Also, I can rename the GitHub mirror to just wikimedia/wikiba.se if you want. [21:45:45] (Won't affect replication) [21:46:37] Or.. you can close the original as your Pull request does. With a note to the new one, works :) [22:01:52] :/ https://grafana.wikimedia.org/dashboard/db/wikidata-dispatch?refresh=1m&orgId=1&from=now-3h&to=now [22:02:27] http://wikidata.wikiscan.org/?menu=live&date=6&list=users&sort=weight&filter=all [22:02:58] Again enwiki. [22:03:14] sjoerddebruin: I don’t understand what that list is sorted by… it’s not speed, but I have no idea what the number in the leftmost column means [22:03:34] or why you can sort by every column *except* speed, which would seem like the most useful column [22:03:52] Number of edits. [22:04:03] ah, thanks [22:04:17] total number in 6 h? [22:04:53] Yep. [22:05:11] hm, but 19996/6hr ≠ 74/min [22:05:17] so then the speed column must mean something different [22:05:56] 19996 / 270 [22:06:10] Steenthbot is active for 4 hours and 30 minutes [22:06:22] ah, ok [22:06:23] (see the time column) [22:06:35] so that’s the edit rate within their active period [22:06:43] Yep. [22:09:29] oh great, as if hiding the query box and run button when I dare scroll down even slightly wasn't annoying enough, I can't scroll down at all for some queries [22:57:07] Interesting how one single property with 1k uses can fuck up the whole suggestions: https://www.wikidata.org/wiki/Q33093633 [22:57:55] now gone with adding more properties...