[04:45:06] <Sven_Manguard>	 Hey all: do you think  that "award received" would be a good property to use to denote that someone has https://en.wikipedia.org/wiki/Righteous_Among_the_Nations recognition? 
[06:08:16] <rschen7754>	 https://meta.wikimedia.org/wiki/October_2013_private_data_security_issue
[06:42:43] <Sven_Manguard>	 g'night
[08:27:31] <hsarrazin>	 Hello everybody :)
[08:45:49] <GerardM>	 hoi hsarrazin 
[10:46:09] <Sid-G>	 Hi. Is the alias here-> https://www.wikidata.org/wiki/Q3511761 <- correct?
[10:48:52] <Stryn>	 Sid-G: no, I removed it
[10:49:05] <Sid-G>	 Stryn: thanks :)
[12:36:16] * Lydia_WMDE  waves

[13:55:16] <dMaggot>	 hola
[13:55:31] <dMaggot>	 I'm wondering if I can make any of these two types of queries:
[13:55:53] <dMaggot>	 give me all entities with claims involving P##
[13:56:27] <dMaggot>	 from the API POV that would look like ?action=wbgetclaims&property=P2
[13:56:36] <dMaggot>	 but that is an error right now in the API
[13:58:34] <Lydia_WMDE>	 dMaggot: hey! :)
[13:58:52] <Lydia_WMDE>	 dMaggot: not possible yet but magnus wrote an external tool for it
[13:59:05] <Lydia_WMDE>	 it is on [[Wikidata:Tools]] i think
[13:59:07] <AsimovBot>	 10[5] 10https://www.wikidata.org/wiki/Wikidata:Tools
[14:00:28] <dMaggot>	 Lydia_WMDE: hey there! I think I know you ;)
[14:00:35] <Lydia_WMDE>	 ;-)
[14:00:48] <dMaggot>	 another type of query is (this one I guess is more complicated)
[14:01:08] <dMaggot>	 give me all entities with claims involving a subtype of Q###
[14:01:37] <dMaggot>	 it more or less boils down to whether property transitivity is implemented or not
[14:03:28] <Lydia_WMDE>	 nope
[14:04:21] <dMaggot>	 :(
[14:40:19] <lazowik>	 hey
[14:40:27] <lazowik>	 Lydia_WMDE: ur here?
[14:40:37] <Lydia_WMDE>	 lazowik: hey
[14:41:13] <lazowik>	 Lydia_WMDE: what you'd go with http://tools.wikimedia.pl/~mlazowik/comments.php ?
[14:41:19] <lazowik>	 or something different?
[14:42:06] <Lydia_WMDE>	 lazowik: 3 and 3
[14:42:22] <lazowik>	 mhm
[14:42:48] <lazowik>	 aude the same, I'll go with that
[14:42:52] <Lydia_WMDE>	 :)
[14:43:06] <lazowik>	 addshore: ^ want to break out?
[15:18:05] <lazowik>	 hmm
[15:18:25] <lazowik>	 can I make (in wbsetsitelink) page title optional?
[15:21:58] <lazowik>	 so it would be linkSite( ( id XOR ( site, title ) ) OR baserevid, linksite, ( linktitle OR badges ), *summary )
[15:22:18] <lazowik>	 or maybe even linkSite( ( id XOR ( site, title ) ) OR baserevid, linksite, ( linktitle XOR badges ), *summary )
[15:22:32] <lazowik>	 then the autosummary wouldn't be a problem
[15:22:53] <lazowik>	 addshore: ^ ?
[17:23:08] <Base>	 https://www.wikidata.org/w/index.php?title=Wikidata:Requests_for_deletions&curid=454&diff=74289036&oldid=74288998
[17:23:09] <Base>	 i belive thats beacuse of this resetting of pass
[17:23:23] <Base>	 which was more harmful than helpful, sure
[17:23:45] <Base>	 *bacause
[17:23:50] <Base>	 *because
[17:24:24] <Base>	 but amyway botmaster should care
[17:24:29] <Base>	 whose bot it is?
[17:24:55] <Base>	 addshore, lazylegoktm
[17:25:59] <liangent>	 Base: maybe just softblock the whole labs ip range?
[17:26:17] <Base>	 hmm
[17:26:36] <liangent>	 (and toolserver
[17:26:44] <Reedy>	 BLOCK ALL THE IPS
[17:26:44] <Base>	 but botmasters anyway should change the pass and rerun bots
[17:26:58] <Base>	 Reedy: +1 :D
[17:27:06] <Reedy>	 They should also be checking for login errors
[17:27:19] <Reedy>	 and STOPPING IF THERE'S AN ERROR LIKE YOU MUST FUCKING CHANGE YOUR PASSWORD NAO BITCH
[17:27:29] <rschen7754|away>	 we'd rather not block benebot if we don't have to
[17:27:45] <Base>	 if bot logged in successfuly and then THEY logged it out it should not check
[17:27:47] <rschen7754|away>	 the operator is semi-active, and the bot keeps RFD running
[17:27:50] <Base>	 its not his fault
[17:27:50] <liangent>	 Reedy: I wonder what the bot sees in these cases
[17:27:50] <Reedy>	 aude: No 1.22wmf20 for wikibase?
[17:27:55] <liangent>	 from api / forced password change
[17:28:06] <Reedy>	 I had an example earlier
[17:28:47] <Base>	 i think nothing that he is learned to understand
[17:29:08] <liangent>	 Base: I guess failing to check a session failure is his fault
[17:29:21] <Reedy>	 https://gerrit.wikimedia.org/r/#/c/87285/
[17:29:30] <liangent>	 session failure doesn't only happen in this case (password leak)
[17:29:39] <Reedy>	 liangent: $errorMsg = 'password-recycled';
[17:29:50] <Base>	 if token became wrong then perhaps smth would be wrong
[17:29:52] <Reedy>	 It's new, but it's also an error so they shouldn't just carry on
[17:30:48] <Base>	 bots cant be learned to read all the stuff wmf can invent to make their live more difficult
[17:30:57] <liangent>	 Reedy: grep password-recycled * -R gives nothing in core
[17:31:03] <liangent>	 where does it come from?
[17:31:04] <Base>	 their task is to edit, not to read errors
[17:31:07] <Reedy>	 As I said, it is new
[17:31:13] <Reedy>	 https://gerrit.wikimedia.org/r/#/c/87285/11/wmf-config/Bug54847.php,unified
[17:31:19] <Reedy>	 Message should be in WikimediaMessages
[17:31:52] <liangent>	 Reedy: hmm I know it's new but I don't know it's not in core
[17:32:21] <liangent>	 Reedy: so generally what's reported when for logins with a temporary password
[17:32:30] <liangent>	 temporary password as in password reset
[17:32:59] <liangent>	 s/when//
[17:33:13] <Base>	 messages should be localizeble also if they are not
[17:33:44] <Base>	 these emails in english werent helpful for plenty of users
[17:33:50] <Base>	 that are <en-1
[17:35:08] <Reedy>	 Indeed
[17:35:47] <Reedy>	 Unfortunately it needed doing quickly, so waiting for localisation wasn't high o the priorities
[17:36:43] <Reedy>	 			case LoginForm::RESET_PASS: // bug 20223 - Treat a temporary password as wrong. Per SpecialUserLogin - "The e-mailed temporary password should not be used for actual logins;"
[17:36:44] <Reedy>	 			case LoginForm::WRONG_PASS:
[17:36:44] <Reedy>	 				$result['result'] = 'WrongPass';
[17:36:44] <Reedy>	 				break;
[17:36:49] <Reedy>	 that looks awful
[17:37:02] <Reedy>	 liangent: WrongPass
[17:43:20] <liangent>	 Reedy: hmm those stuff are more complex. I was thinking wmf just moved password into temporary passwords
[17:43:35] <liangent>	 btw 20223 seems unrelated
[18:15:42] <aude>	 Reedy: next week
[18:15:51] <aude>	 today is a holiday
[18:18:46] <Reedy>	 Silly Germans
[18:19:50] <aude>	 :)
[18:20:43] <JeroenDeDauw>	 indeed
[18:34:49] <Reedy>	 Though, the Americans are as bad
[18:34:54] <Reedy>	 Midweek holidays indeed
[18:37:36] <travis-ci>	 [travis-ci] wikimedia/mediawiki-extensions-Wikibase#931 (master - ba9fc0b : Translation updater bot): The build was fixed.
[18:37:36] <travis-ci>	 [travis-ci] Change view : https://github.com/wikimedia/mediawiki-extensions-Wikibase/compare/857f31ac0b6d...ba9fc0b0a519
[18:37:36] <travis-ci>	 [travis-ci] Build details : http://travis-ci.org/wikimedia/mediawiki-extensions-Wikibase/builds/12104463
[19:44:23] <legoktm>	 [10:25:12 AM] <liangent>	 Base: maybe just softblock the whole labs ip range? <-- bad idea because of XFF blocking
[19:44:32] <legoktm>	 and that's bene*'s bots
[19:45:31] <liangent>	 legoktm: toolserver ips are already softblocked on enwiki
[19:45:41] <legoktm>	 right, but toolserver ips are not internal ips
[19:45:58] <legoktm>	 lemme find the discussion on enwiki
[19:46:14] <legoktm>	 liangent: https://en.wikipedia.org/wiki/User_talk:Anomie/Archives/2013#10.111.0.0.2F16
[19:48:36] <liangent>	 legoktm: hm
[20:27:57] <Schisma_>	 hi
[20:28:14] <Schisma_>	 cant the date field handle hours minutes and seconds?
[20:42:43] <liangent>	 Schisma_: hmm it seems possible to add such a value via api, but it's then not consistently displayed
[20:43:09] <Schisma_>	 sounds like a bug
[20:48:52] <liangent>	 Schisma_: I submitted https://bugzilla.wikimedia.org/show_bug.cgi?id=54939
[20:49:26] <Schisma_>	 liangent: tanks ^^
[21:07:53] <grrrit-wm>	 (03CR) 10Aude: [C: 04-1] "(3 comments)" [extensions/Wikibase] - 10https://gerrit.wikimedia.org/r/84996 (owner: 10Daniel Kinzler)
[21:09:02] <aude>	 liangent: do you have an opinion about https://gerrit.wikimedia.org/r/#/c/84996/ ?
[21:09:30] <aude>	 if we should continue accepting time precision more specific than days? e.g. hours /minutes
[21:09:35] <aude>	 in the api
[21:09:48] <aude>	 while the UI and elsewhere handles it inconsistently
[21:13:42] <liangent>	 aude: people will start to ask for microseconds later
[21:13:56] <liangent>	 I don't have much knowledge about calendars
[21:14:20] <liangent>	 does our datetime representation always make sense in different calendar models?
[21:16:23] <aude>	 liangent: it's really not my expertise
[21:16:31] * aude  can speak better about coordinates

[21:17:02] <liangent>	 btw, when you want to validate time values ( https://bugzilla.wikimedia.org/show_bug.cgi?id=48965 ), leap seconds will come into our eyes
[21:17:12] <aude>	 oh, true
[21:18:59] <liangent>	 aude: is it currently validated without leap support?
[21:20:22] <aude>	 i am not sure
[21:20:25] <aude>	 !^[-+]\d{1,16}-(0\d|1[012])-([012]\d|3[01])T([01]\d|2[0123]):[0-5]\d:([0-5]\d|6[012])Z$!
[21:20:26] <AsimovBot>	 El búfer 01 está vacío.
[21:20:35] <aude>	 is the regex used to validate 
[21:21:19] <aude>	 it is ISO8601
[21:21:39] * aude  wonders what AsimovBot is thinking :)

[21:22:54] <liangent>	 aude: yay it works with leap seconds :)
[21:23:02] <liangent>	 |6[012])
[21:23:15] <aude>	 good
[21:23:36] <aude>	 yeah
[21:24:34] <liangent>	 though it allows nonexistent leap seconds to be inserted
[21:25:03] <aude>	 always a trade off how much we want to validate and add complexity
[21:28:32] <liangent>	 aude: but anyway, isn't ISO8601 designed for Gregorian calendar
[21:30:23] <liangent>	 aude: well I can say it now, that ISO8601 doesn't work with the chinese calendar at all
[21:31:06] <aude>	 hmmm
[21:31:27] <aude>	 i am not sure how we handle julian
[21:31:34] <aude>	 and don't think we support other calendars yet
[22:55:22] <grrrit-wm>	 (03PS1) 10Jeroen De Dauw: Update readme [extensions/WikibaseQueryEngine] - 10https://gerrit.wikimedia.org/r/87471 
[22:55:31] <grrrit-wm>	 (03CR) 10Jeroen De Dauw: [C: 032 V: 032] Update readme [extensions/WikibaseQueryEngine] - 10https://gerrit.wikimedia.org/r/87471 (owner: 10Jeroen De Dauw)