[07:16:47] PROBLEM - Response time of WDQS on wdqs1002 is CRITICAL: CRITICAL: 14.29% of data above the critical threshold [300000.0] [07:33:53] RECOVERY - Response time of WDQS on wdqs1002 is OK: OK: Less than 5.00% above the threshold [120000.0] [07:36:14] PROBLEM - Response time of WDQS on wdqs1001 is CRITICAL: CRITICAL: 11.11% of data above the critical threshold [300000.0] [07:38:20] * gehel is looking at WDQS... [07:38:24] RECOVERY - Response time of WDQS on wdqs1001 is OK: OK: Less than 5.00% above the threshold [120000.0] [07:41:39] Okay, thanks. [07:44:00] seems that we just got a big batch of updates from wikidata, high write load probably created some response time issue. Seems back under control, but I'll keep an eye on it for a while [07:46:01] ‎GZWDer (flood) is mass-creating items, could that be it? https://www.wikidata.org/wiki/Special:Contributions/GZWDer_(flood) [07:46:25] Seems above the bot etiquette, gonna write him. [07:53:56] sjoerddebruin: Thanks! Yep, that might be related... [07:54:29] See https://www.wikidata.org/wiki/User_talk:GZWDer#GZWDer_.28flood.29, if things are going bad again I can block his flood account. [07:55:36] We had this before on a much worse scale, also someone parallel editing. [07:55:53] note this *should* not affect WDQS, we should be able to throttle writes on WDQS to something reasonable and accept some lag instead. (we don't do that at the moment) [07:56:31] "Paused a process and leaving another (and the third is completed)." on my talkpage. [07:59:33] Seems to have effect. https://grafana.wikimedia.org/dashboard/db/wikidata-query-service [08:05:22] sjoerddebruin: at least he is reactive! Good! [08:05:42] That's why we are such a lovely project. :) [08:09:49] At least there is some limiter in the tools now, otherwise it would be much worse. [08:17:15] Just created T139445 for tracking this [08:17:16] T139445: WDQS - Throttle updates to WDQS - https://phabricator.wikimedia.org/T139445 [08:17:47] gehel: Yeah I saw, https://phabricator.wikimedia.org/T135471 for the previous issue. [08:27:13] Adrian_WMDE: https://phabricator.wikimedia.org/T127435#2432506 Your comment leaves me a bit puzzled. Did I something wrong? Is there something I should do now? [08:27:50] Good morning btw. ;-) [08:28:01] Hi [08:28:31] Lydia_WMDE: sjoerddebruin: ‎GZWDer (flood) is mass-creating items, could that be it? https://www.wikidata.org/wiki/Special:Contributions/GZWDer_(flood) [08:29:05] Adrian_WMDE: Yup, that's the main reason. User already slowed somewhat down. [08:29:12] it's a Thiemo_WMDE :) [08:29:15] See our discussion somewhat above. [08:29:31] sjoerddebruin: that's actually a copy & paste of what you wrote [08:29:41] sjoerddebruin: Didn't mark it as quote, sorry [08:29:54] Ah, okay. :') [08:30:09] I wanted to know what was going on :D [08:30:10] Thiemo_WMDE: Well, I don't know if it's wrong, it's just that we did it differently until now. [08:31:19] Lydia_WMDE: ah, because you always miss half of the discussion due to the shitty internet. [08:31:26] indeed -.- [08:32:57] Adrian_WMDE: I don't see steps I can follow in that other ticket. If it describes a process, I dont understand it. [08:33:20] gehel, Lydia_WMDE, Adrian_WMDE: hmmm https://www.wikidata.org/w/index.php?title=User_talk:Sjoerddebruin&oldid=prev&diff=354713630 [08:33:24] Thiemo_WMDE: It says »Currently, they are added in ExtraLanguageNames: [08:33:26] https://phabricator.wikimedia.org/diffusion/OMWC/browse/master/wmf-config/InitialiseSettings.php$15823« [08:33:39] But they arent. [08:34:37] ? [08:34:58] What is "wmgExtraLanguageNames"? This does not appear a single time in my whole code base. [08:35:35] https://phabricator.wikimedia.org/diffusion/OMWC/browse/master/wmf-config/InitialiseSettings.php$15960 [08:35:47] That is part of the cluster's configuration [08:36:02] I can't find any code that uses this setting. [08:36:56] ExtraLanguageNames? [08:37:07] Zero search results. [08:37:29] Well, check languages/Language.php [08:38:41] Found a spot that uses $wgExtraLanguageNames [08:38:45] Thiemo_WMDE: https://github.com/wikimedia/operations-mediawiki-config/blob/36a623ffb8801025fb0c124da6097075e783aa48/wmf-config/CommonSettings.php#L3254 [08:39:13] Ah, thanks aude! [08:39:33] Yeah, thank you :) [08:40:26] Last bit that confuses me: https://phabricator.wikimedia.org/T127935 says "kea" is "currently added in ExtraLanguageNames", which seems to be reverted or never happened. Is that what we still want to do? [08:41:29] No, in general extra term languages are added there. kea is not added yet [09:58:39] DanielK_WMDE_: Can you give me a phab number (with that multi content discussions) for the scrum of scrums. [10:05:26] Tobi_WMDE_SW: Can you stream the sites discussion (sound only)? [10:06:04] Thiemo_WMDE: it will happen tomorrow [10:06:11] ok, thanks. [10:06:14] since Adrian_WMDE needs to leave now [10:07:05] Can I get a USB mic sponsored by WMDE? My sound was so bad that I missed that. [10:10:55] Thiemo_WMDE: https://phabricator.wikimedia.org/T107595 is what i'm working on. we need to fix https://phabricator.wikimedia.org/T137537 . I'll be pushing on https://phabricator.wikimedia.org/T114640 soon. [10:12:48] Lydia_WMDE: any idea when we get actual useful property suggestions for qualifiers before saving? [10:14:12] Thiemo_WMDE: sure. can you just find one that would fit you and then send the link to sandra? [10:15:29] Lydia_WMDE: the task is here btw https://phabricator.wikimedia.org/T102324 [10:17:13] sjoerddebruin: i had pushed that down on the priority list because i assumed it isn't happening too often that people add a new statement and then immediately add qualifiers. but that assumption mightbe wrong [10:17:51] I'm playing the date game right now and hitting a lot of circa dates, so those need qualifiers. [10:18:31] Thiemo_WMDE: i kind of like asus the wireless usb headset. you can use it while charging, and it's not bluetooth - just a usb dongle and a headset. pretty decent [10:19:20] I also think it's a nice service for new users, who are pretty confused now. [10:19:49] sjoerddebruin: *nod* [10:20:18] But I'm okay with it though, good for my edit count. :3 [10:22:03] Thiemo_WMDE: hm, can't find it on amazon off-hand.... [10:22:13] i can look up the product id when i'm at home [10:22:20] sjoerddebruin: lol [10:23:21] Thiemo_WMDE: ah, this one: https://www.amazon.de/Asus-Travelite-HS-1000W-Kabelloses-Headset/dp/B001W1VDHU [10:23:28] sadly, out of stock... [10:23:41] Lydia_WMDE: I also notice that the qualifier suggestions are sorted differently? [10:23:59] sjoerddebruin: how do you mean? [10:25:03] P31 isn't the first result when I want to use it for category mappings, despite a exact match. It's the first result when I search for it during adding statements, but second when I want to use it in the property datatype. [10:25:03] P31 Fork of P29 (An Untitled Masterwork) - https://phabricator.wikimedia.org/P31 [10:25:46] sjoerddebruin: ah ok. will have a look [10:26:43] Hm, now it's working correct. Weird. [10:27:20] The squeaking door example.. [10:27:28] uhuh [10:28:07] Let me try it on the normal workflow. [10:30:27] Okay, it happens on categories when I want to add https://www.wikidata.org/wiki/Property:P971, together with the qualifier https://www.wikidata.org/wiki/Property:P1659 [10:30:27] P971 (An Untitled Masterwork) - https://phabricator.wikimedia.org/P971 [10:30:27] P1659 Masterwork From Distant Lands - https://phabricator.wikimedia.org/P1659 [10:31:13] http://i.imgur.com/56lIGj0.png [10:31:49] Mostly the exact match is always displayed first, I thought the sorting of search results weren't influenced by current statements? [10:38:08] yeah it is exact match first and then ranked by statements and sitelinks [10:38:48] But that isn't applied to the property datatype then. [10:39:43] Only on categories it seems. [10:44:02] Lydia_WMDE: https://phabricator.wikimedia.org/T88804 [10:46:23] Lydia_WMDE: it really depends on the properties you use. if you mostly add ones which don't often need qualifiers, it won't happen much to you. if you mostly add ones which require qualifiers (like all the ones listed on https://www.wikidata.org/w/index.php?title=Special%3AWhatLinksHere&target=Property%3AP1646&namespace=120) it happens all the time, like I was doing a bit of work on cleaning up badly imported "visitors per year" statements the other [10:46:23] day and was trying to add statements for other years and it was maddening (partly because the interface keeps moving around when I try to click thanks to all the popups but partly because I had to keep saving and re-editing to get the suggestions to work) [10:48:02] I never did finish >_< [10:49:14] The entity suggester is just half-baked at some points. [10:50:57] At least the suggestions are somewhat improved now on non-human items, right? [10:52:02] yeah, it's not completely obsessed with suggesting human properties at the moment [11:28:31] hm... I have a long list of item ids and want to know which ones are redirects, does anyone know a good way to figure it out? [11:30:19] Manual list on PetScan, and there is a option for redirects under page properties. [11:30:43] Otherwise you can just put them between [[ and use CSS. [11:35:42] oh, good point, I already have some css that changes the colour of redirects in the history, maybe it works on normal pages too [11:37:05] I use it while progressing the same sitelink name between project lists [14:40:51] https://www.wikidata.org/wiki/Q303425?uselang=en other user speaking Korean said he wants to set the year value to exact 2000 but what he get is 2000s. any solutions? [18:58:29] revi: huh. if I use ?uselang=ko, add a new date, type "2000", it changes the precision to "decade", but if I do it using ?uselang=en it uses "year". I assume the solution right now is to tick "set manually" and change the precision to year... and create a bug ticket since that's just odd inconsistent behaviour [18:59:35] that's for locale [18:59:49] hmm [18:59:50] wait [19:00:01] I tried using ?uselang=en I think [19:01:51] hmm I set the precision manually to 'year' explicitly when I was saving it (and I'm ?setlang=ko) [19:02:06] nikki: That's a fascinating edge case. Can you create a Phabricator ticket for this please? I would love to fix this. [19:02:14] that's my case lol [19:02:17] wring ping [19:02:22] I notice that ?uselang=ko shows "2000" for the existing value whereas ?uselang=en shows "2000s". wonder if that's related, maybe because "2000" matches both the decade display and the year display [19:02:26] well [19:02:32] Korean doesn't have plural [19:02:38] so 2000s and 2000 is just same [19:02:51] it should have an equivalent of decade, I imagine, like japanese and chinese [19:02:59] You know what, your description just helped me understanding the error. :-) [19:03:04] :) [19:03:35] how's decade shown in Japanese and Chinese? [19:03:41] I don't know those two langs [19:04:08] (and please understand my blahblahs, it's 4am and I was just about to sleep) [19:04:14] This: https://translatewiki.net/wiki/MediaWiki:Wikibase-time-precision-10annum/ko [19:04:45] Probably correct. The error is in our parser code. I will fix this. [19:04:52] in chinese 2000s is shown as "2000年代", japanese shows "2000s" which is wrong, iirc it's the same characters as chinese (if not, it's something similar) [19:05:16] got it [19:05:47] I didn't get the definition, there's such concept, yeah [19:05:55] (4am is not a good time to think, isn't it?) [19:06:00] is it?* [19:06:05] yeah blahblahs [19:06:08] it depends when you got up :) [19:06:22] my records says 8am [19:06:29] then yes, that sounds like a bad time [19:06:55] I'll fix the translation to reflect the wording properly [19:07:12] but that decade should be done somehow and it doesn't seem to be my work [19:07:30] https://phabricator.wikimedia.org/T139509 [19:08:00] y no me [19:08:02] lol [19:08:14] Plus add something to https://translatewiki.net/wiki/MediaWiki:Wikibase-time-precision-10annum/ko if you can. [19:08:50] I'm thinking of something but hard to find good word [19:10:04] Could be "2000 (decade)". [19:10:10] In that language, obviously. [19:10:27] saved, Japanese translation was good hint [19:10:42] and also commented on the bug, well tell local user it's a bug [19:11:05] Please poke me when you find such date/time related things, or create phabricator tasks. I love to work on this. [19:11:23] will do :) [19:11:28] by the way [19:11:38] the user said he put 2001 and as year [19:11:41] just fyi [19:12:18] https://www.wikidata.org/wiki/Wikidata:사랑방#.EB.B2.84.EA.B7.B8.EB.95.8C.EB.AC.B8.EC.97.90_.EC.97.B0.EB.8F.84.EB.A5.BC_.EC.A0.9C.EB.8C.80.EB.A1.9C_.EB.AA.BB.EB.84.A3.EA.B2.A0.EC.96.B4.EC.9A.94. [19:12:19] here [19:12:20] Yea, that's kind of correct. Decade stuff is offset by 1. [19:12:29] Same bug, same solutions. [19:12:50] so translation should be live tomorrow or today (iirc) [19:12:58] Cool, thanks. [19:13:04] and there's nothing more I can do (I think) so goodnight [19:13:11] Same here. goodnight [19:51:19] * aude waves [19:54:08] * Harmonia_Amanda waves back at aude [21:57:51] DanielK_WMDE: have a minute? [22:18:08] SMalyshev: sure. but i'm not fully awake any more [22:18:18] heh [22:18:57] so maybe we can discuss https://gerrit.wikimedia.org/r/#/c/296793/ at least? [22:19:12] and schedule review of the search patches for later? [22:20:01] I'll look at the search stuff tomorrow [22:20:48] can you tell me again what problem the fix-script solves? I have the impression there is a deeper issue here... [22:21:43] well, so when we create a wiki, we create main page [22:21:56] which is in wikitext, and it's the default content model [22:22:06] so revision table gets null as content model [22:22:31] now we install Wikibase, and default content model for main space is not wikitext anymore, it's now wikibase-item [22:22:46] but doesn't the page table have the correct model? [22:22:50] if the actual content model is *somewhere* in the db, the page content should not be misinterpreted. only in with $wgContentHandlerUseDB = false should this be possible. [22:22:53] but the revision table for main page still has null. only now the code thinks null is wikibase-item! [22:23:18] DanielK_WMDE: page does. But the code does not look into page table anywhere, it relies only on revision table [22:23:22] if the revision model is null, we should use the page model, not the default [22:23:25] and per-namespace default [22:23:50] yea. but if it's in the page table, why don't we use that?... [22:23:51] DanielK_WMDE: not sure... looks like page model is supposed to be just a copy of latest revision [22:24:23] so normally page table and revision table would have the same data, unless the model is default for namespace, in which case revision has null to save space [22:24:29] yes. but if that's null, the page table still records the default model at the time, right? [22:24:45] rght. but nobody looks there. because code assumes it's the same value [22:24:52] but since defaults changed, it's not anymore [22:24:58] yea. we should fix that assumption then., [22:25:17] not exactly sure where that is though. will need to debug. poke me tomorrow [22:25:21] well, that'd require some serious rewrite of Revision I'm afraid because right now it has no idea about page table [22:25:33] it has a Title object [22:25:59] right but it's not using its content model and I'm not sure whether using it is correct or not... [22:26:13] or whether even Title has correct model then... [22:26:54] anyway, what the patch does is it finds pages where page's data != revisions's data != default (which means default changed but revision table wasn't updated) and updates page->revision [22:27:17] I'd like to understand the issue before we mess with how things are stored on an ad-hoc basis wqith a maintenaince script [22:27:26] so maybe you want to do the same in the code, dunno. I can ping you tomorrow about it, I'll be online ~9:30am PDT [22:27:59] the fix script only makes sense if null in the revision table is a bug. then we should fix the bug before fixing the data. [22:28:23] if otoh the issue is in interpreting what's in the db, then we should fix that interpretation. [22:28:38] null definitely looks like a bug, since it violates two assumptions: null means default, and page data is the same as lat rev data [22:28:58] "default" could here mean "what'S in the page table". [22:29:08] though if we remove one of the assumptions then it's fine [22:29:35] well, I'm not sure that works with the rest of the code... maybe yes, I just don't know the history of it enough [22:29:35] yea, i want to look into that. hoefully, i'll have time tomorrow. calendar look good so far [22:29:59] ok, so I'll be online around 9:30am and we can talks. Also about search things [22:30:14] 9:30 what time zone? [22:30:31] and I've started looking into units as you've seen. Not sure so far if it's the final version but will try to get something together [22:30:36] DanielK_WMDE: 9:30 PDT [22:30:59] i commented on the unit conversion thing [22:31:07] so 18:30 for me. cool. [22:31:24] I may be online 9:30 CET too but I'm not sure if you'd be :) [22:32:17] not really before noon ;) [22:32:17] yeah I saw about transform. I didn't know it existed, makes a lot of sense to use it for me [22:32:24] DanielK_WMDE: that's what I guessed :) [22:32:40] also use DecimalMath [22:33:54] SMalyshev: btw, we'll need a factor, an offset, and an exponent. maybe even log. fun. [22:34:14] and i'm still not sure how to handle relative temperature [22:35:28] DanielK_WMDE: I'm ignoring non-multiplicative units for now [22:35:41] maybe get to them later [22:35:47] yea, fine for now. but something to keep in mind. [22:35:59] surely