[06:28:21] (03CR) 10Aude: [C: 032] Do not use deprecated method for equality check [extensions/Wikibase] - 10https://gerrit.wikimedia.org/r/139608 (owner: 10Jeroen De Dauw) [06:28:39] (03Merged) 10jenkins-bot: Do not use deprecated method for equality check [extensions/Wikibase] - 10https://gerrit.wikimedia.org/r/139608 (owner: 10Jeroen De Dauw) [06:39:37] [travis-ci] wikimedia/mediawiki-extensions-Wikibase/master/c95b357 : jenkins-bot The build is still failing. http://travis-ci.org/wikimedia/mediawiki-extensions-Wikibase/builds/27601217 [08:52:10] (03CR) 10Thiemo Mättig (WMDE): [C: 04-1] "As Daniel said, please make this an option and not a "magic" behavior." [extensions/Wikibase] - 10https://gerrit.wikimedia.org/r/139367 (owner: 10Hoo man) [08:56:46] (03CR) 10Thiemo Mättig (WMDE): "Oh, and the shards in PS6 will never be valid JSON. Not before and not after concatenation. When we discussed this in IRC my impression wa" [extensions/Wikibase] - 10https://gerrit.wikimedia.org/r/139367 (owner: 10Hoo man) [08:59:51] [13ValueView] 15thiemowmde comment on pull request #68 14a484682: Still no declaration for these two? Not really needed. Just wondering because `_$customItem` does have a declaration but the others don't. 02http://git.io/LYBP6g [09:01:18] [13ValueView] 15thiemowmde closed pull request #68: Address review in #58 (06master...06addressReview) 02http://git.io/xnbMiQ [09:33:33] (03PS8) 10Thiemo Mättig (WMDE): [WIP] Cleanup in EntityRevision related code [extensions/Wikibase] - 10https://gerrit.wikimedia.org/r/139173 [09:33:51] (03CR) 10jenkins-bot: [V: 04-1] [WIP] Cleanup in EntityRevision related code [extensions/Wikibase] - 10https://gerrit.wikimedia.org/r/139173 (owner: 10Thiemo Mättig (WMDE)) [09:40:59] [13WikibaseDataModel] 15thiemowmde comment on pull request #118 14da3c58a: Comment doesn't fit any more. 02http://git.io/H9EY-w [09:41:19] (03CR) 10WikidataJenkins: [V: 032] "Build Successful" [extensions/Wikibase] - 10https://gerrit.wikimedia.org/r/139173 (owner: 10Thiemo Mättig (WMDE)) [09:42:36] [13WikibaseDataModel] 15thiemowmde comment on pull request #118 14da3c58a: What was wrong with using the constant? I saw you doing this several times now. What's the benefit of decoupling this? This makes maintenance much harder. 02http://git.io/OXbbcA [09:43:54] [13WikibaseDataModel] 15thiemowmde comment on pull request #118 14da3c58a: Where will this be used? 02http://git.io/ru4Yvg [09:46:36] [13WikibaseDataModel] 15thiemowmde comment on pull request #118 14da3c58a: More of this. Why? Nobody will ever be able to maintain these. Use the constants please. 02http://git.io/Mm5Mpg [09:46:51] [13WikibaseDataModel] 15thiemowmde comment on pull request #118 14da3c58a: More of this. Why? Nobody will ever be able to maintain these. Use the constants please. 02http://git.io/I17SMw [09:52:32] [13WikibaseDataModel] 15thiemowmde comment on pull request #118 14da3c58a: Description missing. 02http://git.io/vtb33A [10:00:31] (03PS1) 10WikidataBuilder: New Wikidata Build - 15/06/2014 10:00 [extensions/Wikidata] - 10https://gerrit.wikimedia.org/r/139671 [10:11:27] (03CR) 10WikidataJenkins: [V: 032] "Build Successful" [extensions/Wikidata] - 10https://gerrit.wikimedia.org/r/139671 (owner: 10WikidataBuilder) [10:34:05] [13WikibaseDataModel] 15thiemowmde created 06description (+1 new commit): 02http://git.io/bgQdKw [10:34:05] 13WikibaseDataModel/06description 1429469b3 15Thiemo Mättig: Back to 0.7.3 description [10:35:18] [travis-ci] wmde/WikibaseDataModel/description/29469b3 : Thiemo Mättig The build passed. http://travis-ci.org/wmde/WikibaseDataModel/builds/27608346 [10:40:22] [13WikibaseDataModel] 15thiemowmde opened pull request #119: Back to 0.7.3 description (06master...06description) 02http://git.io/ujEO3w [10:46:24] [13WikibaseDataModel] 15thiemowmde 04force-pushed 06unchain from 147c6462a to 14e96b3bf: 02http://git.io/AzZbyA [10:46:24] 13WikibaseDataModel/06unchain 14e96b3bf 15Thiemo Mättig: Unchain SiteLinkList adder [11:07:21] [13Geo] 15thiemowmde created 06globe-null (+1 new commit): 02http://git.io/W-c7-Q [11:07:21] 13Geo/06globe-null 140dff6aa 15Thiemo Mättig: Globe default value [11:11:57] [13Geo] 15thiemowmde opened pull request #13: Globe default value (06master...06globe-null) 02http://git.io/9dstkw [12:45:10] hi [12:45:31] hi [12:47:20] https://www.wikidata.org/w/index.php?title=Q12013&diff=137972401&oldid=137113664 <-- second pair of eyes please [12:49:22] Lydia_WMDE; Dealt with. [12:49:29] thx :) [13:00:43] [13WikibaseDataModel] 15JeroenDeDauw comment on pull request #118 14da3c58a: Look at this PR for several examples 02http://git.io/c-_7Cg [13:01:58] [13WikibaseDataModel] 15JeroenDeDauw comment on pull request #118 14da3c58a: What maintenance are you talking about exactly? Are you saying this should not be done because then we cannot easily rename the type? I agree it makes that harder yes. Though it is already impossible, so what difference does that make? 02http://git.io/qcypAQ [13:02:28] [13WikibaseDataModel] 15JeroenDeDauw comment on pull request #118 14da3c58a: Note how we are using strings at various places for over a year and those never caused any problem, nor do I see any reason why they would. 02http://git.io/DJVzJw [13:10:38] [13WikibaseDataModel] 15JeroenDeDauw 04deleted 06unchain at 14e96b3bf: 02http://git.io/noKFeg [13:11:08] [13WikibaseDataModel] 15JeroenDeDauw closed pull request #119: Back to 0.7.3 description (06master...06description) 02http://git.io/ujEO3w [13:32:59] [13WikibaseInternalSerialization] 15JeroenDeDauw created 06UnDeserializableValue (+1 new commit): 02http://git.io/uNEbHw [13:32:59] 13WikibaseInternalSerialization/06UnDeserializableValue 1488e2ed5 15jeroendedauw: Add UnDeserializableValue support to LegacySnakDeserializer [13:46:00] [13WikibaseInternalSerialization] 15JeroenDeDauw 04force-pushed 06UnDeserializableValue from 1488e2ed5 to 14802085e: 02http://git.io/rHaAsg [13:46:00] 13WikibaseInternalSerialization/06UnDeserializableValue 14802085e 15jeroendedauw: Add UnDeserializableValue support to LegacySnakDeserializer [13:46:26] [13WikibaseInternalSerialization] 15JeroenDeDauw 04force-pushed 06UnDeserializableValue from 14802085e to 14d736b95: 02http://git.io/rHaAsg [13:46:26] 13WikibaseInternalSerialization/06UnDeserializableValue 14d736b95 15jeroendedauw: Add UnDeserializableValue support to LegacySnakDeserializer [13:46:45] [travis-ci] wmde/WikibaseInternalSerialization/UnDeserializableValue/802085e : jeroendedauw The build has errored. http://travis-ci.org/wmde/WikibaseInternalSerialization/builds/27615291 [13:55:12] [13WikibaseDataModelSerialization] 15JeroenDeDauw created 06UnDeserializableValue (+1 new commit): 02http://git.io/Q49l3A [13:55:12] 13WikibaseDataModelSerialization/06UnDeserializableValue 14c3a1a35 15jeroendedauw: Add UnDeserializableValue support to SnakDeserializer [13:55:27] [13WikibaseDataModelSerialization] 15JeroenDeDauw opened pull request #66: Add UnDeserializableValue support to SnakDeserializer (06master...06UnDeserializableValue) 02http://git.io/FLFHTw [13:56:37] [travis-ci] wmde/WikibaseDataModelSerialization/UnDeserializableValue/c3a1a35 : jeroendedauw The build passed. http://travis-ci.org/wmde/WikibaseDataModelSerialization/builds/27615762 [14:01:07] aude: ^ [14:01:29] aude: once those 2 are reviewed I can make new tags [14:56:54] hi, i've prepared a spreadsheet comparing a snippet of the current wireless computer keyboard market offerings [14:57:41] I believe this may be useful as a basis to build upon with futher information [14:58:04] and so think it would be appropriate to release to a wiki project, for community maintenance [14:58:27] I expected, since it's tabular data, that wikidata would be the most suitable destination [14:58:41] but it doesn't seem that wikidata serves this purpose [14:59:02] please would someone suggest where or how it is best to store this information? [15:02:00] also, how would it be best to store localised information, such as price? [16:19:53] hoo: problem is still existing [16:20:39] Romaine: I know, will probably fix that tomorrow [16:20:45] ok [16:33:49] (03PS8) 10Tpt: Provides a default to otherProjectsLinks configuration parameter [extensions/Wikibase] - 10https://gerrit.wikimedia.org/r/132613 [16:34:07] (03CR) 10jenkins-bot: [V: 04-1] Provides a default to otherProjectsLinks configuration parameter [extensions/Wikibase] - 10https://gerrit.wikimedia.org/r/132613 (owner: 10Tpt) [16:35:41] (03CR) 10Tpt: "PS 8: apply improvements requested" (032 comments) [extensions/Wikibase] - 10https://gerrit.wikimedia.org/r/132613 (owner: 10Tpt) [16:36:05] (03PS9) 10Tpt: Adds a beta feature for "Other project" sidebar [extensions/Wikibase] - 10https://gerrit.wikimedia.org/r/132606 [16:39:30] (03PS9) 10Tpt: Provides a default to otherProjectsLinks configuration parameter [extensions/Wikibase] - 10https://gerrit.wikimedia.org/r/132613 [16:39:54] (03CR) 10Tpt: "PS 9: rebase" [extensions/Wikibase] - 10https://gerrit.wikimedia.org/r/132613 (owner: 10Tpt) [16:45:56] (03CR) 10WikidataJenkins: [V: 032] "Build Successful" [extensions/Wikibase] - 10https://gerrit.wikimedia.org/r/132613 (owner: 10Tpt) [16:52:38] (03CR) 10WikidataJenkins: [V: 032] "Build Successful" [extensions/Wikibase] - 10https://gerrit.wikimedia.org/r/132606 (owner: 10Tpt) [16:57:02] (03CR) 10WikidataJenkins: [V: 032] "Build Successful" [extensions/Wikibase] - 10https://gerrit.wikimedia.org/r/132613 (owner: 10Tpt) [17:06:20] hi Amir1 [17:08:46] multichill: hi [17:08:51] what's up? [17:09:13] Importing monuments into Wikidata :-) [17:09:35] cool :) [17:09:48] I'm working on P18 form Dutch WP [17:09:52] https://www.wikidata.org/wiki/Special:Contributions/BotMultichill <- seems to be going well [17:10:10] P18? I already cleaned that out a while ago [17:10:23] Only manual work left [17:11:05] There were 2K of them in Dutch (and 3K in German and 1K in French) [17:11:20] no there are about 300 overall left [17:11:25] *now [17:11:57] Ah, you might have imported some mistakes from nlwp [17:11:58] there are about 21K monuments of Iran (with their data existed in fa.wp) I think I had harvested them [17:12:18] I added a lots of checks [17:12:26] I'm pretty sure I don't have them in the monument database [17:13:02] https://commons.wikimedia.org/wiki/Commons:Monuments_database/Statistics <- no, nothing there Amir1 [17:13:50] Can you add them to your database? [17:15:36] Depends, please read the manual at https://commons.wikimedia.org/wiki/Commons:Monuments_database [17:16:32] https://fa.wikipedia.org/wiki/%D8%A7%D9%84%DA%AF%D9%88:%D8%AC%D8%B9%D8%A8%D9%87_%D8%A7%D8%B7%D9%84%D8%A7%D8%B9%D8%A7%D8%AA_%D8%AC%D8%A7%DB%8C%E2%80%8C%D9%87%D8%A7%DB%8C_%D8%AA%D8%A7%D8%B1%DB%8C%D8%AE%DB%8C_%D8%A7%DB%8C%D8%B1%D8%A7%D9%86 [17:16:47] cool [17:16:58] multichill: why do you think my bot may imported errors? [17:17:40] Because last time I checked it was only questionable images left :-( [17:17:53] We'll just see :P [17:18:05] yeah :) [17:19:23] Do you revertbot.py can be a very useful code but it's very limited now (it just reverts all edits of yours) [17:19:31] *Do you know [17:20:07] multichill: I added user option and now I'm adding rollback option in order to make it compatible with wikidata (or flow) [17:20:41] In core or are you still messing around with the old version? [17:21:38] multichill: I gave up compat about two months ago (or more) [17:21:42] :) [17:22:07] Still a lot of work in core, but having everyone split out over two branches sucks out too much energy [17:23:08] multichill: see this for example: https://bugzilla.wikimedia.org/show_bug.cgi?id=55073 [17:23:26] I agree with you :) [17:23:51] oh I forgot: congrats on exploding Spain :))) [17:24:35] hehe [17:24:40] The Netherlands football team is really good [17:26:59] Before Friday everyone here thought they would suck :P [17:28:41] :))) [17:30:15] Romaine: Around? [17:30:22] yes [17:30:51] Romaine: If you add a new sitelink and the past the name, the bug occurs, right? [17:30:56] * paste [17:31:25] it didn't matter if I pasted it or typed it [17:31:57] Ok, does it work if you wait for the suggester to pop up? [17:33:16] the past days I do not get suggestions [17:33:36] uh [17:34:30] multichill: I think people added images to the articles, I read the manual but I can't understand how I can make a Structured list, we have an infobox for them in fa.wp [17:34:53] let's just skip that part and have everything on Wikidata! [17:35:00] Romaine: Can you open an item with ?debug=true attached and look whether the suggester opens then? [17:36:52] I tried a random Q... and a random language and there I do get suggestions [17:36:58] (woithout ?debug=true ) [17:37:19] Romaine: Try it with debug true, please [17:37:42] multichill: okay :) [17:37:52] let me see what I can do [17:38:15] with debug=true I do also get suggestions (now) [17:38:39] Romaine: \o/ Great [17:38:48] Does setting sitelinks work for you that way? [17:39:29] I don't understand the question [17:40:13] Romaine: Is the bug still present if you open an item with debug=true? [17:41:21] I can't tell now, as I was writing articles and added them to Wikidata, haven't written one now [17:41:36] Ok [17:44:47] Amir1: In case you're intrested: https://www.wikidata.org/wiki/Wikidata:Cultural_heritage_task_force [17:45:29] sounds good [17:45:42] Romaine: If I may interrupt you one last time: If you go to a random item (without debug=true) now, do sitelink suggestions work for you? [17:45:49] Nice, api leaks wikitext: pywikibot.data.api.APIError: modification-failed: Must be no more than {{PLURAL:250|one character|250 characters}} long :@ [17:46:23] yes hoo [17:46:34] Ok, that's good [17:46:37] Thanks [17:46:50] I started an article now, will soon add it to Wikidata and will see what happens then [17:47:49] multichill: it's strange, I knew it returns string but wikitext! https://gerrit.wikimedia.org/r/#/c/139695/1/scripts/revertbot.py [17:48:00] :) [17:48:05] if e == "badtoken: Invalid token": [17:48:12] looks weird to me [17:48:58] it would be better if we could implement something that returns subclass instead of string [17:49:06] I keep getting badtoken errors, it's very anoying. The api is quite unstable righ tnow [17:49:36] Agree, classes would be nicer [17:49:58] Anyway, bbl [17:50:05] okay [17:52:53] hoo: article finished, wanted to add it to Wikidata, but bug is still there [17:53:34] the page stucks at Busy with saving... [17:53:39] Ok [17:54:05] Does that also happen if you select the item from the suggester or wait for the suggester to pop up before saving? [17:54:31] this time I haven't seen a suggestion [17:55:06] ok [17:55:34] when I referesh the page, and try it a second time with pasting it didn't gave a suggestion but this time it did save it [17:56:00] that is what I have all day, first attempt: not saved, second attempt: saved [18:25:21] multichill: I did this to start harvesting the data: https://www.wikidata.org/wiki/Wikidata:Property_proposal/Place#Iranian_National_Heritage_registration_number [18:52:20] aude / hoo: Is https://bugzilla.wikimedia.org/show_bug.cgi?id=66405 still an issue? (poking per the patches) [18:53:38] JohnLewis: Nope, it's fixed [18:53:40] closing the bug [18:55:41] hoo: kk [18:56:25] hoo: and https://bugzilla.wikimedia.org/show_bug.cgi?id=66346? :p [18:57:01] probably [18:57:03] aude: ? [19:03:47] hoo: this time I added a new article, saved it well, but I had no suggestion even while I waited 6 seconds [19:07:24] Romaine: No suggestions at all, or only the current article wasn't suggested? [19:07:39] no suggestions at all [19:07:45] even not the just created article [19:08:08] but when I tried to Save, the article was added [19:09:08] That the newly created article doesn't show up is normal, it takes some time till it appears [19:09:15] ok [19:09:15] but no suggestions at all is weird [19:09:42] hoo: probably a side-effect of henning's refactoring [19:10:22] Yeah, probably [19:10:49] I'm debugging side effects between the new suggester and our SitePageInterface for ages now [19:18:06] :/ [19:18:24] hoo: we'll have a post mortem about that in the next days [19:18:59] don't want that to happen again [19:20:31] Yeah, stuff like this is horrible [19:21:27] I finally found the solution for my timing bug \o/ [19:21:36] Let's just pray it doesn't introduce new bugs [19:21:38] * hoo goes to test [19:22:56] ... and it breaks the whole thing -.- [19:25:04] hoo: will not save now, [21:23:58.655] POST https://www.wikidata.org/w/api.php [HTTP/1.1 200 OK 788ms] [19:28:09] yeah :( [19:48:31] Amir1: Ah, strong identifiers are very useful indeed [19:49:27] once it got created I will start harvesting lots of data for Iranian national heritage [19:53:52] Amir1: I wrote a pywikibot based bot to do the import. It contains some logic to prevent duplicates etc. [19:54:22] It's pretty hacked up at the moment like a proof of concept. Based on the experience it could probably evolve into something more general [19:55:05] It uses WikidataQuery to get all the existing items to prevent dupes [20:00:40] multichill: cool, I will work on it (I saw that) [20:01:40] (03CR) 10WikidataJenkins: "Build Successful" [extensions/Wikibase] - 10https://gerrit.wikimedia.org/r/139751 (owner: 10L10n-bot) [20:02:04] Thiemo_WMDE: Around? [20:02:10] * hoo needs someone for JS code review [20:02:12] yes. [20:02:23] [travis-ci] wikimedia/mediawiki-extensions-Wikibase/master/c9bcb8b : Translation updater bot The build is still failing. http://travis-ci.org/wikimedia/mediawiki-extensions-Wikibase/builds/27633860 [20:02:35] Thiemo_WMDE: Ah great :) [20:02:41] Amir1: https://tools.wmflabs.org/paste/view/2b14bf90 [20:03:53] That's the logic to cache the items already tagged as a monument and to also cache some iso codes (which I happen to have in a database) [20:04:15] The data I use is http://tools.wmflabs.org/heritage/api/api.php?action=search&srcountry=nl&srlang=nl&srmunicipality=%Haarlem%&format=json&limit=5 [20:04:49] So the "nl" will give the item for the Netherlands and "nl-nh" the province Noord-Holland [20:05:07] And filling these caches is actually quite fast [20:05:46] hoo: nothing new on gerrit. [20:05:55] Thiemo_WMDE: About to push to github [20:05:57] one second [20:07:06] Lydia_WMDE: can we please make the post-mortem a rollback? it really, really feels like this would be much less painfull. [20:08:24] [13ValueView] 15mariushoch created 06suggesterNoReset (+1 new commit): 02http://git.io/T19z3A [20:08:24] 13ValueView/06suggesterNoReset 14e773676 15Marius Hoch: Don't reset the input value on suggester blur... [20:08:41] Thiemo_WMDE: ^ [20:09:03] it's really good [20:09:43] Amir1: ? [20:09:44] Thiemo_WMDE: Couldn't find anything that depends on that code block, but it's seriously screwing things up [20:09:55] your script [20:10:12] looks like a fix thats in the wrong place and should be inside of that oomenu thingy. [20:10:30] Thiemo_WMDE: ? [20:10:34] I'm just removing stuffs [20:10:45] multichill: your script is really cool [20:11:08] Actually I was thinking about improving P18 code you wrote [20:11:20] wait. thats not green, thats red. woups. [20:11:36] Amir1: This is the part that still looks good ;-) [20:11:56] stupid github. [20:12:41] Amir1: The whole thing is at https://tools.wmflabs.org/paste/view/4ea3a70f . It's a bit of a mess. I just wanted to get something working [20:14:05] I'm talking about illustrate_wikidata.py [20:14:08] multichill: [20:14:29] What do you want to change with that? [20:14:43] hoo: i'm trying to understand why this code is there. like cursor down and then tab, which blurs the list. is this when this line is executed? [20:15:34] Thiemo_WMDE: It will probably execute that line, but the value is already being set on curser down [20:15:38] * cursor, even [20:16:01] multichill: see this: http://www.wikidata.org/wiki/Property_talk:P18#Notes_for_botmasters [20:16:23] for example local images can pass the checks (AFAIK) [20:17:16] hoo: hover a list item with the mouse and then press tab. [20:17:45] Amir1: Weird, the bot checks if the image exists on Commons. So illustrate_wikidata.py should never add images that don't exist on Commons [20:17:45] it still works in my test and i wonder why? [20:17:58] still works for me [20:18:30] Thiemo_WMDE: There's an extra tab press handler [20:18:31] hoo: bug still there, adding an sitelink isn't saved, got this error: [22:17:23.837] TypeError: response[this.API_VALUE_KEY] is undefined [20:18:34] Do you have an example where that happens? Same for image placeholders, those should be filtered out too already [20:18:35] in _attachInputEventHandlers [20:18:50] The image property thing is true, we should check for that [20:19:04] Romaine: Yes, and I think I'm pretty close to a fix now. Hopefully we can get this fixed tomorrow :) [20:19:09] instance of human and svg is too much of an edge case [20:19:14] ok [20:20:38] multichill: it's possible to have the image in commons but different image with local (even an unrelated image) e.g. File:AB.jpg in English WP but the AB.jpg in commons is something different [20:21:09] I know Amir, look at the code: "imagelink = pywikibot.Link(imagename, source=commonssite, defaultNamespace=6)" [20:21:25] That looks on Commons, not on some local site [20:21:49] And checks for redirect and if it exists [20:22:50] Thiemo_WMDE: Can you see anything that needs that code block? I can't [20:23:16] trying to fix my local setup. i get a gazillion js errors at the moment. screw composer. [20:26:41] [13ValueView] 15mariushoch opened pull request #71: Don't reset the input value on suggester blur (06master...06suggesterNoReset) 02http://git.io/1cpUqw [20:27:09] WTF? The requested URL /repowiki/extensions/Wikibase/vendor/data-values/javascript/lib/util/util.inherit.js line 55 > eval was not found on this server. [20:27:24] multichill: the page.properties()['page_image'] returns you a name [20:27:28] like AB.jpg [20:27:50] if the image that has been used in English WP is a local image [20:28:07] but another image with the same name exists in commons [20:28:27] the bot works incorrectly and adds incorrect image to wikidata [20:28:56] Sure, but that's not what Ivan is saying. How often would we see that in the wild? [20:29:29] multichill: I think it worths fixing because once the mistake is made it's realy hard to catch [20:29:32] *really [20:29:41] because the image exists in commons [20:30:01] I want to work on what Ivan said too [20:30:08] but this came into my mind [20:30:23] and because of the scale of Wikidata anything is possible [20:30:25] Nah, too much of an edge case. Focus on his third point. That's an anoying bug [20:30:26] ;) [20:30:40] And easy to fix [20:31:17] multichill: yes I think so [20:31:52] the fastest and craziest fix would be "if image.title() in str(data.get()): pass" [20:31:57] :))) [20:34:42] goddamn. i didn't wanted to spend my sunday with more whatthefucks. :( [20:35:03] Thiemo_WMDE: Know that feeling :/ [20:35:09] Thiemo_WMDE: wtf :p [20:35:20] Would like to deploy the fix (or some fix) tomorrow though [20:35:35] Amir1: huh? [20:36:48] if the image name (e.g. AB.jpg) is mentioned in data page somehow (used in a claim) pass the page [20:36:54] why does everything just explode? what happened? [20:38:01] Thiemo_WMDE: The suggester is going crazy... and everything depends on it. [20:38:39] I'm close to just deleting my mediawiki setup. [20:38:56] Is composer f*cking with you? [20:39:00] Have no fear, NyanCat is near! [20:39:09] Worst case: rm -rf vendor extensions [20:39:30] hoo: delete ALL the things [20:39:48] Thiemo_WMDE does not get along well with Composer? :) [20:40:05] damn composer. its useless. [20:40:33] Thiemo_WMDE: ok, so I'm not going to take you serious for the next few days :D [20:40:40] how to reset the stuff in my vendor directory so that composer updates it again? without deleting everything. [20:40:53] Thiemo_WMDE: I kinda know the feeling. Updated a farm to MW 1.23 now nothing works :( [20:41:46] JohnLewis: thats mainly because we are at something like version 4.16.82 now but nobody updated the version number for a year. [20:42:10] :/ [20:42:14] * JohnLewis blames JeroenDeDauw [20:42:21] 4.16.82?? [20:42:41] JohnLewis: yes, gimme all of the credit! [20:42:53] At least if there are prizes involved that is [20:43:53] JeroenDeDauw: how to make composer update the libraries again? it just does nothing. [20:44:07] is there a force parameter or something? [20:44:37] Not that I'm aware of [20:44:41] faced that problem before [20:44:47] Thiemo_WMDE: I am not sure how you can make it not update stuff when it is supposed to [20:45:06] JeroenDeDauw: Eg. if you checked out master in one of the sub components [20:45:31] just start working on a sub-lib, do "git checkout master" and so on. then composer stops doing anything to that sub-lib. [20:45:52] Perhaps it is still at the correct version as far as composer is concerned? [20:45:58] no. [20:45:59] It looks at what is in composer.lock [20:46:07] If that is fine, it will not update [20:46:14] Even if you changed the git branch [20:46:18] Because composer does not know you did [20:46:33] but it does somehow. [20:47:06] if you checkout master, then composer will not automatically put it back on the other branch, unless it needed to do an update anyway [20:49:09] i have not even a clue whats wrong now. all the JS that crashes seems to be in lib. how is it possible this is outdated? [20:49:26] Thiemo_WMDE: No idea [20:49:40] I needed to use Firefox in private mode for stuff to work properly [20:49:44] no idea why [20:49:59] tried that a minute ago. same gazillion of JS errors. [20:50:06] Did you try turning it off and on again? [20:50:15] ReferenceError: evilsSeed is not defined [20:50:22] Oh, I had that one as well [20:50:28] TypeError: wb.utilities.ui.StatableObject is undefined [20:50:31] Went away in private mode [20:50:38] TypeError: wb.ui.PropertyEditTool is undefined [20:50:47] Yeah, those are follow-up errors [20:51:10] for me it worked to remove my vendor and extensions dir, then composer install and then private mode [20:51:17] straight forward... hahaha... not [20:51:39] i looked at the "evil" code. it's impossible this error can happen. [20:51:47] I know [20:51:52] but I had it as well [20:53:31] AAAAAAAAAAAAAAAAAA!!!!!!!!!!!!! [20:53:54] i added an if(!evilsSeed)return and the same error still happens! what is this? [20:54:07] Thiemo_WMDE: Cache ;) [20:54:20] eval() does have a caching layer? [20:54:31] No, firefox has one and it seems pretty f*cked [20:54:39] or maybe it's MWs local storage stuff [20:54:46] I don't know... private mode fixed it for me [20:55:41] kdsazfhakjlfakd!Tf5e87153o8!!ZU"%!!!!!!!!!!!!!!!!!!!!!!!!!! [20:59:09] good, firefox is so fucked up. you have to restart the private mode to get rid of that crap. [20:59:16] Yeah [20:59:38] so back to the patch. :( [20:59:46] I had similar issues with WebKit browsers before, just to make sure you really loose faith in browsers [21:00:03] after losing an hour for crappy firefox again. i want my beloved opera back. *cry* [21:00:59] hoo: reproducing the issue - success. [21:01:08] this is laughable. [21:03:44] yeah :/ [21:07:18] [13ValueView] 15thiemowmde closed pull request #71: Don't reset the input value on suggester blur (06master...06suggesterNoReset) 02http://git.io/1cpUqw [21:07:36] Thiemo_WMDE: You're today's hero :) [21:07:52] i also feel like that. [21:08:03] punching walls and such. [21:08:19] i think i need to watch an other Breaking Bad episode now. [21:08:34] * hoo still hasn't seen the last season [21:09:09] i'm not in a hurry. currently in the middle of 3 i think. [21:11:23] hoo: ValueView needs a release. i added your patch to the coming 0.6.2. ok? [21:11:46] Thiemo_WMDE: mh, I don't think we yet want the other patches, do we? [21:11:53] I want that to be minimal impact [21:12:07] I guess I'd make a .2 with only that commit and postpone the rest to .3 [21:12:11] do we backport this? again? [21:12:25] if we do, then yes, make it so. [21:12:49] still not happy with the z-index thing. [21:13:18] Yeah, that sucks... why does the dialog even have such an insane high zIndex [21:13:35] because it's a dialog. thats jquery. [21:14:28] the black background is at ~1001 and the dialog at ~1002 (in monobook). these numbers are calculated by jquery ... [21:14:44] jQuery can *calculate* that [21:14:52] ... based on something in monobook with a high z-index. [21:15:15] jquery increases the index of each element it knows. [21:16:02] thats why my ugly 2000 index does not belong to the valueview component. [21:16:28] but client should not even know about that class [21:16:37] because this 2000 depends on the dynamic z-index of a completely different component that depends on the z-index of an other completely different component. [21:16:43] it's just a hack. [21:17:14] client uses the component. it KNOWS the component. [21:17:17] I think having it in ValueView is the least evil: It's ok for it to have an arbitrary high z-index, but client shouldn't know about the class ever [21:17:29] no, it doesn't know the components externals [21:17:35] it only know the public methods [21:17:48] what? [21:18:12] Client shouldn't know about that class, and it also shouldn't dare to touch it [21:18:15] i understand what you mean but it doesnt make sense. [21:18:34] there is no such thing as a "private" css class name. they are part of the interface. [21:19:14] Of course they're not private, but one component shouldn't alter the CSS of another. Eg. if we at one point change the suggester's internal DOM that might break [21:19:43] why not? who said that? [21:19:48] who made that rule? [21:20:24] css is not dom. a z-index is a special thing, it's not changing a color or something. [21:20:27] It's not a rule, just a convention, and I'm not sure it's written down somewhere [21:20:50] assuming 2000 is more wrong than what you say. [21:22:53] its not true that a component can't alter the properties of sub-components. this is nothing special. this is how components work together. [21:23:19] the sub-component can't know the z-index of the environment it is used in. simple as that. [21:23:40] assuming 2000 is wrong. assuming any number is wrong. [21:24:48] I still don't think that client should do that: Unconditionally overwrite the CSS of another component [21:25:01] its not unconditional. [21:26:08] it is [21:26:24] the selector is not limited by anything wikibase specific [21:26:24] no. why do you say that? [21:27:26] Eg. if something else would use the suggester it would also need to set a z-index: That might conflict [21:27:45] there are no conflicts in css. [21:27:58] one overwrites the other [21:28:08] yes. thats not a conflict. [21:28:37] it can have weird side effects, coming from conflicting values/ assumptions on values [21:29:01] i'm not saying my current patch at gerrit is perfect. it is not. but having this z-index in the component is worse. [21:29:55] having it in valueview causes a million times more of the conflicts you are talking about. [21:31:07] Coming back to that jQuery thing: Can we make jQuery find the highest z-index? If so, why not do taht [21:31:22] i already suggested that. [21:31:46] Well, ok... if you make a pull, I'll merge it [21:32:00] i made one. you gave it a -2. [21:32:40] I only -2ed the one where you had a hard coded z-Index [21:33:10] which doesnt make sense because you merged exactly that in the component. [21:33:27] Because I think it fits into the component [21:33:35] at least more than into client [21:33:53] because I'm not allowed to access public properties of a sub-component????? [21:35:34] It's not a property which was supposed for public usage, it's an internal structure that IMO can be changed in the component at any time without having to risk b/c problems [21:35:47] let me repeat: why should the sub-component know that all environments it is used in are below z-index 2000? [21:36:20]