[09:44:15] <Jonas_WMDE>	 Lydia_WMDE ddddaily?
[09:45:00] <Lydia_WMDE>	 Jonas_WMDE: not in the office
[09:45:06] <Lydia_WMDE>	 Thiemo_WMDE: can you call jonas in?
[09:45:12] <Lydia_WMDE>	 or tell glorian to do it?
[09:45:57] <Thiemo_WMDE>	 IRC daily instead?
[09:46:05] <Thiemo_WMDE>	 Jonas_WMDE: Are you there?
[09:46:38] <Jonas_WMDE>	 Thiemo_WMDE here
[09:47:50] <DanielK_WMDE>	 IRC daily sounds good to me
[09:47:51] <Thiemo_WMDE>	 Jonas_WMDE: I have no microphone right now. :-(((
[09:48:18] <Jonas_WMDE>	 ok no problem
[09:48:59] <DanielK_WMDE>	 ok, who'll start?
[09:49:24] <Jonas_WMDE>	 lets chat after the daily how push the sprint forward
[09:51:31] <DanielK_WMDE>	 Glorian can
[09:51:38] <Thiemo_WMDE>	 My status: I need an other coffee. At the moment I'm working on a minor wikidata.git cleanup I had in my Git stashes. Then I want to clean my inbox (luckily no mess there today). I will talk with Daniel about "create MediaInfo entities in statement editing API".
[09:51:45] <DanielK_WMDE>	 Glorian can't join us because this channel is still +r
[09:52:00] <DanielK_WMDE>	 why is that still on? that's extremely restrictive :(
[09:53:34] <DanielK_WMDE>	 anyway. my status: Stas movwed structured search forward, we should be able to start using it soon. Also, there weas in interesting paper published on WDQS performance. we should get in touch with the researchers.
[09:54:36] <DanielK_WMDE>	 Today I'll work on auto-creation of MediaInfo (and talk to Thiemo about it). I'll also follow up on the Multi-Content_Revisions stuff (talk to Tim Starling about the BlobStore interface, and to Jaime about the representation of revision content in the DB)
[09:54:50] <DanielK_WMDE>	 If I feel brave, I'll install Neon on my laptop. 
[09:55:18] <DanielK_WMDE>	 Jonas_WMDE: ?
[09:55:42] <DanielK_WMDE>	 sjoerddebruin: thank you
[09:56:02] <sjoerddebruin>	 No problem. :)
[09:56:07] <DanielK_WMDE>	 hey Glorian_WMDE!
[09:56:12] <Glorian_WMDE>	 hey
[10:00:22] <Jonas_WMDE>	 I rebased some stuff and addressed gerrit comments and then I like to push the current sprint. I will talk to you about the individual tickets then.
[10:01:13] <Jonas_WMDE>	 DanielK_WMDE will you do a task breakdown with Thiemo_WMDE ?
[10:01:46] <DanielK_WMDE>	 Jonas_WMDE: probably. i have to look at the code again to see where we are at
[10:01:51] <Thiemo_WMDE>	 Jonas_WMDE: I think this is what we will do. Do a bit of code experiment and then break the task down.
[10:02:06] <DanielK_WMDE>	 we also need to decide how much refactoring we'll do, and with how much cruft we are willing to live
[10:02:45] <Jonas_WMDE>	 What is the status of T115269
[10:03:32] <Jonas_WMDE>	 is this blocked on announcement of  Lydia_WMDE 
[10:04:40] <DanielK_WMDE>	 Jonas_WMDE: yes. and then on waiting for people to fix their software.
[10:05:20] <DanielK_WMDE>	 we also want to prepare a bot run. Maybe we can talk to addshore about it when he's at the office
[10:05:41] <DanielK_WMDE>	 Lydia_WMDE: what do you think should the timeline be for announcing and implementing the change to Quantity serialization?
[10:05:54] <addshore>	 *waves*
[10:06:36] <Jonas_WMDE>	 DanielK_WMDE I already saw a swagger change here and there ;)
[10:07:29] <addshore>	 DanielK_WMDE: a bot run for what? :D
[10:08:53] <DanielK_WMDE>	 addshore: change bounds on quantities, for specific proeprties. Something like "for P1234, remove all +/-0 bounds" or "for P5678, change +/-1 to +/-0.5".
[10:09:20] <addshore>	 ooooh, okay, sounds easy enough :)
[10:09:24] <DanielK_WMDE>	 Jonas_WMDE: hm?
[10:12:14] <DanielK_WMDE>	 addshore: yea, but needs a bit of discussion :P
[10:14:52] <Thiemo_WMDE>	 DanielK_WMDE: Do you want to have a look at https://gerrit.wikimedia.org/r/197873 ? Otherwise I will just merge it.
[10:16:26] <Thiemo_WMDE>	 Jonas_WMDE: Do you want to have a look at https://gerrit.wikimedia.org/r/302408 ? Otherwise I will merge it.
[10:18:27] <Jonas_WMDE>	 Thiemo_WMDE ok with me
[10:18:44] <Thiemo_WMDE>	 Ok, thanks.
[10:19:20] <DanielK_WMDE>	 Thiemo_WMDE: uh... i'll have to look and figure out what this does, and why
[10:20:10] <Thiemo_WMDE>	 DanielK_WMDE: You did this before. :-) You could just check the reason for your -1 and if I fixed it and +2 the patch then. ;-)
[10:37:49] <DanielK_WMDE>	 Thiemo_WMDE: my vote was +1, no -1. i still don't see the point, but i'm fine with it
[10:42:31] <DanielK_WMDE>	 Thiemo_WMDE, everyone @WMDE: lunch at little saigon?
[10:53:35] <Amir1>	 for when you're back from the lunch: Please review https://gerrit.wikimedia.org/r/#/c/299284/
[13:06:16] <hoo>	 aude: Do you know who updated the sites table after tcy wiki was created?
[13:06:21] <hoo>	 There's nothing in SAL :(
[14:16:19] <DanielK_WMDE>	 Thiemo_WMDE: https://gerrit.wikimedia.org/r/#/c/295218/  https://gerrit.wikimedia.org/r/#/c/294521/  https://gerrit.wikimedia.org/r/#/c/294040/
[14:19:53] <hoo>	 I almost forgot how much fun it is to dick around the parser's internals
[14:20:02] <hoo>	 * digg
[14:20:04] <hoo>	 * dig
[14:21:08] <DanielK_WMDE>	 well... you can also do that...
[14:21:40] <sjoerddebruin>	 :P
[14:22:06] <hoo>	 and I also noticed that the parser profiling is totally screwed as of recently
[14:22:21] <hoo>	 but not sure how related that is to my thing
[14:23:37] <hoo>	 Oh wow https://de.wikipedia.org/wiki/Modul:Wikidata2Lemma
[14:23:41] <hoo>	 this is... just wow
[14:24:36] <sjoerddebruin>	 efficient
[14:33:15] <aude>	 hoo: sorry, forgot to log it 
[14:33:16] <aude>	 (
[14:33:18] <aude>	 :(
[14:39:42] <hoo>	 Ah, that's fine :)
[14:39:49] <hoo>	 Just wanted to make sure it has been done correctly
[14:41:05] <aude>	 no problems, except that addWiki.php doesn't tak ecare of this properly
[14:41:12] <aude>	 maybe it's best manually though
[14:41:26] <aude>	 and we need to add tcy to the interwiki sorting order
[15:20:40] <hoo>	 https://gerrit.wikimedia.org/r/303556 wow
[15:20:52] <hoo>	 Didn't realize we were a) still doing that and b) it was so slow
[15:21:06] <sjoerddebruin>	 \o/
[15:27:00] <aude>	 what are we doing?
[15:27:07] <aude>	 o_O
[15:27:43] <hoo>	 I love how I could just live hack it on mw1017 and then benchmark api calls :)
[15:28:57] * aude can do code reviews later, once i'm not tethering
[15:43:19] <hoo>	 The number of interface and classes we have around retrieving terms (in some way) is gigantic
[15:43:52] <hoo>	 I thought about splitting the TermIndex interface
[15:44:03] <hoo>	 but before doing that, I should probably find out what we have so far
[15:50:05] <hoo>	 aude: Do you have any ongoing refactors in the above area?
[15:50:15] <hoo>	 don't want to interfere with tha
[15:50:15] <hoo>	 t
[15:50:32] <hoo>	 or maybe it even eases my pain (quite likely)
[16:01:32] <hoo>	 DanielK_WMDE: here?
[16:07:55] <sjoerddebruin>	 Is it just me or does the "in other languages" doesn't show the so far process anymore during saving?
[16:10:15] <DanielK_WMDE>	 hoo: yea
[16:10:19] <DanielK_WMDE>	 sjoerddebruin: sorry, what?
[16:11:07] <hoo>	 DanielK_WMDE: https://gerrit.wikimedia.org/r/303556
[16:11:27] <DanielK_WMDE>	 hoo: i lloked at it. i'd merge, but jenkins sais no.
[16:11:42] <hoo>	 In order to mock WikibaseClient::getTermLookup, would you rather have a setter WikibaseClient::setTermLookup
[16:11:59] <hoo>	 or should I mock it via our MockClientStore (the underlying TermIndex)
[16:12:18] <sjoerddebruin>	 Earlier, you could see what edits were processed already (the underline would go away then). I don't see any indication anymore during the process.
[16:12:20] <hoo>	 getting mocktermindex that is in sync with the other mock data is not as easy as it sounds
[16:13:09] <DanielK_WMDE>	 sjoerddebruin: ah. no idea, sorry..
[16:13:32] <DanielK_WMDE>	 hoo: when exactly does it need to be mocked, and to do what?
[16:14:07] <sjoerddebruin>	 Will make a ticket then
[16:14:11] <hoo>	 DanielK_WMDE: The user is in Scribunto_LuaWikibaseLibrary
[16:14:17] <hoo>	 but we don't have control over that at all
[16:14:23] <hoo>	 this is an integration test
[16:14:30] <hoo>	 Scribunto_LuaWikibaseLibrary is instantiated via Scribunto
[16:14:34] <hoo>	 outside of our reach
[16:14:47] <DanielK_WMDE>	 hoo: so how did the mock data get in there in the past? 
[16:14:50] <hoo>	 so we need to mock WikibaseClient or its store (which is already mocked)
[16:15:13] <DanielK_WMDE>	 we put a mock store into the global WikibaseCLient instance?... ugh...
[16:15:16] <hoo>	 We used an EntityRetrievingTermLookup with the MockRepository EntityLookup
[16:15:21] <hoo>	 Yes, that's needed
[16:15:29] <hoo>	 and well enclosed to only act for that test
[16:15:29] <DanielK_WMDE>	 );
[16:15:58] <DanielK_WMDE>	 hoo: for which test, exactly?
[16:16:13] <DanielK_WMDE>	 anyway...
[16:16:14] <hoo>	 DanielK_WMDE: The lua integration tests
[16:16:28] <hoo>	 tests derived from Scribunto_LuaWikibaseLibraryTestCase
[16:16:32] <hoo>	 (various classes)
[16:16:46] <hoo>	 these are the tests that are actually written in Lua
[16:18:14] <DanielK_WMDE>	 hoo: I see... no chance to get a hold of the WikibaseLuaBindings and call setters on it?
[16:18:55] <hoo>	 No
[16:19:06] <hoo>	 We could make itself register to a global variable
[16:19:14] <hoo>	 but that sounds even worse
[16:21:08] <DanielK_WMDE>	 hoo: we could make it WikibaseClient manage the WikibaseLuaBindings instance. Would be cleaner anyway. 
[16:23:40] <DanielK_WMDE>	 hoo: dunno, make a patch, so i can complain ;)
[16:23:52] <DanielK_WMDE>	 it's all kind of ugly :(
[16:24:11] <hoo>	 DanielK_WMDE: But then WikibaseLuaBindings would need to "register" with WikibaseClient
[16:24:20] <hoo>	 because we have no control over what Scribunto does
[16:25:34] <DanielK_WMDE>	 why can't we have a singleton in WikibaseClient? oh, the UsageAccummulator, I gues... 
[16:27:12] <DanielK_WMDE>	 hoo: so if we were using MediaWikiServices, you could just call MediaWikiTestCass::setService and be done
[16:27:24] <DanielK_WMDE>	 *sigh*
[16:28:15] <hoo>	 hm… but how is that different from setting it in WikibaseClient?
[16:28:16] <DanielK_WMDE>	 just make a setter in WikibaseClient, and complain if it's called outside a test.
[16:28:53] <DanielK_WMDE>	 hoo: it's not different, it's the same thing, but with a mechanism to automatically clean up afterwards, and to ensure consistency between services (to different digrees)
[16:29:13] <hoo>	 yeah, that sounds good… I hacked that together myself more or less
[16:29:32] <hoo>	 Would be nice if we could change our top level service factories to MWServices
[16:29:33] <DanielK_WMDE>	 hoo: changing global state in test fixtures is ugly, but *leaking* global state is a *problem*...
[16:30:07] <DanielK_WMDE>	 hoo: yes. put them into MWServices directly, or at least make them derive from ServiceContainer
[16:30:44] <hoo>	 Do we have a ticket for that?
[16:30:55] <DanielK_WMDE>	 don't think so, no
[16:32:52] <hoo>	 I also think we should make a list of Term related services and then try to consolidate/ split them as needed
[16:32:57] <hoo>	 that's a bit of a mess now
[16:34:20] <DanielK_WMDE>	 yea, so much to do, so little time.
[16:36:19] <hoo>	 True :/
[16:48:45] <gehel>	 SMalyshev: Hello! I need to restart WDQS for JVM upgrade. I'll do that after pulling the latest code. Any issue with that?
[17:37:58] <Base>	 it looks that nobody answered me or I've missed it in the logs
[17:38:04] <Base>	 any Lua gurus here now?
[17:38:23] <hoo>	 Base: What do you need?
[17:39:12] <Base>	 hoo I need to know if I can getEntity by knowing wiki and sitelink title in it
[17:39:40] <Base>	 I do not see how to get entity ID with this info
[17:39:48] <Base>	 it would be overtrivial via API
[17:40:12] <Base>	 but https://www.mediawiki.org/wiki/Extension:Wikibase_Client/Lua looks like missing needed functionality or I am missing it, thus asking
[17:42:17] <hoo>	 That's not implemented: https://phabricator.wikimedia.org/T74815 which is unresolved because of https://phabricator.wikimedia.org/T142093
[17:42:26] <hoo>	 The access functionality is easy to do
[17:42:30] <hoo>	 but there's a long tail to it
[17:46:45] <Base>	 so basicly as of now if you implement it and I use it in module it wouldn't update cache for entities once they are changed? considering that I need it to track whether there is no new sitelink created that is too bad :(
[17:47:08] <Base>	 any idea how long it will take to figure out that second task?
[17:47:26] <Base>	 i see that the first one is there for 2 years already
[17:48:06] <hoo>	 Base: Exactly… the first one lay around for ages
[17:49:16] <hoo>	 I only opened the RfC ticket recently… not sure how fast we can pick this up
[17:49:41] <hoo>	 I would like to get it resolved soon-ish, as it's been a feature that people have asked for since forever
[17:51:49] <Base>	 it looks that I would need to add a parameter where people will manually put entity id, though too bad this wouldn't make all 11k of transclusions of the template I am going to enhance have new feature, usage wouldn't be straightforward too. (Just for the record, https://uk.wikipedia.org/wiki/Шаблон:Не_перекладено this template, though it is irrelevant as the problem is rather general)
[17:53:21] <Base>	 hoo, yeah would be really cool if it would be implemented soon. It is really hard to believe that it really isn't there yet
[17:54:09] <hoo>	 I can't promise anything, but I'll try to push it mor
[17:54:09] <hoo>	 e
[17:57:48] <Base>	 I think it would be useful for that structured commons thing which I believe is what is now work goes on too, so hopefully it gets good priority. Ok thanks you for info, I'll go figuring out what best temporary means I can use
[18:01:10] <hoo>	 aude: Do you know whether we still need property-suggester.wikidata-dev.eqiad.wmflabs
[18:01:25] <hoo>	 it's one of those instances that are not accessible (need a reboot)
[18:01:30] <hoo>	 but I'm not sure we need it at all
[18:01:48] <hoo>	 wikidata-suggester.wikidata-dev.eqiad.wmflabs for building the suggester data
[18:01:51] <hoo>	 no idea about that box
[18:04:57] <sjoerddebruin>	 hoo: talking about the suggester, has the ratio for identifiers changed too?
[18:05:20] <sjoerddebruin>	 Or did we adjust it completely some time ago
[18:05:33] <hoo>	 What do you mean by ratio?
[18:05:57] <sjoerddebruin>	 Ehm, that one number. :P
[18:06:04] <hoo>	 I delete all property relations where the first property is an ext-id
[18:06:21] <hoo>	 So something can relate to an ext-id
[18:06:29] <hoo>	 but ext-id don't relate to anything
[18:07:10] <hoo>	 but that's just a very ugly workaround
[18:07:20] <hoo>	 For https://phabricator.wikimedia.org/T132839
[18:07:21] <sjoerddebruin>	 Well earlier when I mirrored the VIAF for a item, more suggestions showed up.
[18:07:28] <hoo>	 but I guess we don't have the resources to pick that one up
[18:09:18] <sjoerddebruin>	 Well, can we at least update the data again after today's dump?
[18:09:24] <hoo>	 huh… that's weird VIAF is an external id
[18:09:35] <hoo>	 sjoerddebruin: Yes… the process is already running ;)
[19:20:40] <sjoerddebruin>	 hoo|away: script ready ret?
[20:54:31] <hoo|away>	 sjoerddebruin: Nope… but it's in the last phase
[20:54:50] <hoo>	 I guess another 10-20 minutes before I can apply it
[20:55:34] <sjoerddebruin>	 Okay :)
[21:11:37] <DanielK_WMDE>	 Alphos: if nobody responds here, just post to the talk page
[21:12:09] <DanielK_WMDE>	 Alphos: or ping Jonas_WMDE, best during a time europeans are at work....
[21:12:44] <Alphos>	 DanielK_WMDE duly noted
[21:12:46] <DanielK_WMDE>	 oh wait, i just replied to something you posted last night ;)
[21:15:48] <Alphos>	 yes you did :D
[21:16:11] <Jonas_WMDE>	 DanielK_WMDE I am here on duty ;)
[21:28:41] <DanielK_WMDE>	 Jonas_WMDE: oh hey!
[21:29:00] <DanielK_WMDE>	 did you see what Alphos posted last night? I didn't look into it, but I thought you might be interested
[21:29:11] <Jonas_WMDE>	 no when?
[21:29:14] <DanielK_WMDE>	 <Alphos> by the way, in quite a few examples, there are BIND clauses that are plain unnecessary. instead of http://tinyurl.com/hnb226m (12170 ms), why not replace the bound values where needed ? http://tinyurl.com/zgvywop (same results, 1656 ms)
[21:29:18] <DanielK_WMDE>	 that
[21:31:29] <DanielK_WMDE>	 I guess BIND disables the use of indexes even in trivial cases.
[21:31:37] <DanielK_WMDE>	 maybe the blazegraph people would be interested
[21:31:55] <DanielK_WMDE>	 SMalyshev: what do you think --^^
[21:33:10] <SMalyshev>	 hmm interesting, let me look
[21:34:01] <DanielK_WMDE>	 that should act as a simple asias in this context... 
[21:34:41] <SMalyshev>	 it should... but it may be it interprets it differently... let me see the explains
[21:34:49] <DanielK_WMDE>	 Alphos: it's always goo to know who to ping :)
[21:35:07] <DanielK_WMDE>	 SMalyshev: i didn't confirm, maybe it was a fluke
[21:37:31] <DanielK_WMDE>	 naw, looks legit. i got faster results, but also something like an 8x speedup without the bind on the first try. may be caching though. now both versions are super fast.
[21:37:42] <DanielK_WMDE>	 are queries run via the web interface cached?
[21:37:45] <SMalyshev>	 that's probably caching
[21:37:50] <SMalyshev>	 yes, all is cached
[21:38:07] <DanielK_WMDE>	 SMalyshev: is there a way to bapass it? with ?foo=amsjdf or something?
[21:38:24] <hoo>	 SMalyshev: DanielK_WMDE: https://jira.blazegraph.com/browse/BLZG-1141
[21:38:29] <SMalyshev>	 DanielK_WMDE: yes, it caches by url, so change the query (even ws) or add dummy param
[21:38:34] <hoo>	 DanielK_WMDE: Just put garbage into a comment
[21:39:48] <SMalyshev>	 The computation of definiteVars for bind expressions could be improved: currently, variables bound in BIND expressions are never considered definite (as BIND in general may fail), but trivial cases such as BIND (?x as <http://constant/uri>) might be considered "safe".
[21:39:54] <DanielK_WMDE>	 hoo: that looks hairy
[21:39:58] <SMalyshev>	 that's probably the reason it's slow
[21:40:13] <hoo>	 Indeed… scary bug
[21:40:14] <SMalyshev>	 it doesn't think bind is constant
[21:40:30] <SMalyshev>	 I'll ping them about it anyway
[21:41:07] <Alphos>	 then again, why bother binding a var instead of using its value directly ? ;)
[21:41:20] <DanielK_WMDE>	 hoo, Alphos: good find! to we need a phab ticket for this?
[21:41:23] <DanielK_WMDE>	 *de we
[21:41:26] <DanielK_WMDE>	 **do we
[21:41:33] * DanielK_WMDE is already on his way to bed
[21:41:43] * Alphos is already IN bed
[21:41:49] <Alphos>	 laptop <3
[21:41:50] <DanielK_WMDE>	 hahaha
[21:42:18] <SMalyshev>	 DanielK_WMDE: wouldn't hurt to have phab ticket
[21:42:32] <DanielK_WMDE>	 Alphos: in this query, i agree, there is no pint. other than perhaps to meake clear what each ID means.
[21:42:39] <SMalyshev>	 makes easier for me to track when such issues are fixed and re-check them when new BG release happens
[21:42:42] <hoo>	 Alphos: Sometimes it makes a query more expressive or shows of the flexibility better IMO
[21:43:05] <Alphos>	 hoo of course, but in this case, i don't think that's true
[21:43:27] <Alphos>	 it just makes the query more complex, which is prolly why it's taking 8x more
[21:44:03] <hoo>	 Yeah, in that case I don't see much value in it either
[21:44:27] <Alphos>	 also, i apologize in advance, i might go really dumb in a short span but for quite some time, in the next few minutes :x
[21:44:54] <Alphos>	 (cluster headache incoming. if you hear me screaming all the way from berlin, that's it)
[21:48:37] <patricksevat>	 Hi, can someone tell me what's wrong with my group concat in this query? 
[21:48:40] <patricksevat>	 SELECT ?item ?itemLabel (GROUP_CONCAT(?memberOf) As ?memberOf) WHERE {      ?item wdt:P31 wd:Q185441 .   ?item wdt:P463 ?memberOf } 
[21:49:10] <DanielK_WMDE>	 Alphos, SMalyshev, hoo: https://phabricator.wikimedia.org/T142437
[21:49:42] <DanielK_WMDE>	 Alphos: oh :(
[21:49:45] <hoo>	 patricksevat: You need to group by ?item
[21:49:54] <hoo>	 thanks, DanielK_WMDE 
[21:50:10] <hoo>	 also you will need to do that in a subquery and only select the labels after
[21:51:30] <hoo>	 patricksevat: SELECT ?item ?itemLabel ?memberOf WHERE { SERVICE wikibase:label { bd:serviceParam wikibase:language "en" .} { SELECT ?item (GROUP_CONCAT(?memberOf) As ?memberOf) WHERE {      ?item wdt:P31 wd:Q185441 .   ?item wdt:P463 ?memberOf } GROUP BY ?item } }
[21:51:37] <hoo>	 Sorry, formatting sucks
[21:51:53] <patricksevat>	 @hoo, thx!
[21:52:18] <patricksevat>	 I've been breaking my head on this for an hour :x
[21:53:40] <hoo>	 Yeah, especially grouping with labels is a little counter intuitive
[21:57:14] <hoo>	 I would really love for us to at some point tackle the problems described in https://phabricator.wikimedia.org/T132839#2270026
[21:57:26] <hoo>	 The suggester often is annoyingly dumb
[21:57:38] <hoo>	 and our workarounds are not really helping either
[21:57:56] <sjoerddebruin>	 yeah
[21:58:09] <sjoerddebruin>	 and I ranted about the lack of suggestions for references earlier
[21:59:57] <hoo>	 Think that might be caused partly by my workaround
[22:00:02] <hoo>	 but not sure about that
[22:00:06] <hoo>	 I only touch ext-id related stuff
[22:00:14] <sjoerddebruin>	 we just need more references ;)
[22:00:44] <sjoerddebruin>	 btw, since last weeks deploy I have double suggestions at some moments: https://www.dropbox.com/s/d1u6i7ala59u6qz/Schermafdruk%202016-08-09%2000.00.42.png?dl=0
[22:04:09] <sjoerddebruin>	 This is also still a huge problem. https://phabricator.wikimedia.org/T102324
[22:06:36] <sjoerddebruin>	 Would this be hard to add btw? We do the same when there are no statements. https://phabricator.wikimedia.org/T77972
[22:07:10] <sjoerddebruin>	 Showing it at least when no suggestions are available is already a huge improvement.
[22:07:27] <hoo>	 sjoerddebruin: Well, it's easy probably
[22:07:45] <sjoerddebruin>	 dec 2014, damn
[22:07:46] <sjoerddebruin>	 time flies
[22:07:54] <hoo>	 but might end up being hard if we want to do it right (keeping application logic and settings like these separate)
[22:09:40] <hoo>	 not really hard, but quite some work
[22:10:14] <sjoerddebruin>	 But a huge improvement for adding sources. :)