[00:25:44] <James_F>	 SMalyshev: Sure. Mostly, it "just about" works. :-)
[00:49:59] <SMalyshev>	 James_F: well, but I need some details... I've send a long email to sdc/wikitech lists, but the summary is that I'm not sure how wikidata IDs are used on Commons
[00:50:20] <SMalyshev>	 should they have prefixes or not? If not, how do we know they are not native entities but foreign ones?
[00:50:56] <James_F>	 SMalyshev: I don't know. I know that they used to, but also that that area of the code was changed a lot when we found it didn't work, and now I don't know.
[00:51:30] <James_F>	 Leszek and A.ddshore are the experts, and I defer to them. The internals of Wikibase are very hairy.
[00:51:38] <SMalyshev>	 James_F: do you know who might know that?
[00:51:51] <SMalyshev>	 ah well, addshoreVacation you mean :)
[00:52:06] <James_F>	 That's why I didn't ping him. :-)
[00:52:21] <SMalyshev>	 hopefully Leszek is around and sees the mail
[00:52:37] * James_F nods.
[02:32:19] <addshoreVacation>	 Hii
[02:32:49] <addshoreVacation>	 SMalyshev: James_F they should probably not have prefixes anywhere
[02:33:15] <addshoreVacation>	 Properties are the same properties, this no differentiation / prefoxes
[02:33:27] <addshoreVacation>	 Same for items, they only exist on wikidata for now
[02:33:35] <addshoreVacation>	 And mediainfo, only on commons
[02:33:45] <addshoreVacation>	 The concept of prefixes has for now been totally removed from wikibase
[02:33:59] <addshoreVacation>	 (unless anything has changed in the last 2 or 3 weeks)
[02:34:27] <addshoreVacation>	 https://usercontent.irccloud-cdn.com/file/UUZG8AvQ/irccloudcapture1998484800343366910.jpg
[02:34:36] <addshoreVacation>	 Hi from San Juan!
[03:08:07] <James_F>	 :-)
[16:37:13] <duesen>	 anomie: hey. can you point me to the code or ticket related to the "remote" user prefix stuff?
[16:37:48] <anomie>	 duesen: Not offhand. Remind me to look it up in an hour or so
[16:38:21] <duesen>	 if you can tell me some good search terms, i'll go hunt for it myself
[16:38:29] <duesen>	 if i don't find it, i'll poke you again :)
[17:07:11] <tgr>	 duesen: that would be T20209 I think?
[17:07:11] <stashbot>	 T20209: Provide consistent native way to attribute offsite users in revision history - https://phabricator.wikimedia.org/T20209
[17:14:49] <anomie>	 duesen: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/386625 is the patch, it has three tasks linked. The real motivation for doing it was because it was decided that we didn't want to deal with updating the actor table to add a user ID that might reattribute imported edits to a wrong person after the fact.
[17:15:07] <duesen>	 tgr: no, i don't think that'S what I'm looking for...
[17:16:07] <duesen>	 anomie: right, thanks. I'm running into related trouble with UserIdentities created from revision rows read from another wiki's databasem, see T222380
[17:16:07] <stashbot>	 T222380: Decide how to represent the identity of users from another wiki. - https://phabricator.wikimedia.org/T222380
[17:16:23] <duesen>	 I'll cross-reference the old issue there
[19:26:35] <xSavitar>	 tgr: Hi, I'm sorry about this: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/507806. If it wasn't worth it, I wouldn't have made it. I've learnt from several of patches that creating multiple objects of the same thing which one can be created and used is not so good.
[19:26:47] <xSavitar>	 That is why I made the patch while I was reading the code.
[19:27:04] <xSavitar>	 If it's not an improvement, sorry to bother reviewer time. I'll abandon it. Sorry!
[19:28:37] <tgr>	 xSavitar: there's nothing to apologize for, it's up to you how you spend your time
[19:29:15] <tgr>	 IMO these kinds of tiny changes are not worth it, but it's up to you
[19:29:28] <tgr>	 I won't review it so I'm not bothered :)
[19:30:15] <xSavitar>	 Okay, thanks! :)
[19:30:16] <tgr>	 it doesn't help that the installer is a scary part of the codebase, in most areas such a patch could be merged without thinking
[19:30:29] <Reedy>	 xSavitar: The other thing, is some code has internal caching...
[19:30:30] <Reedy>	 	public static function getMain() {
[19:30:30] <Reedy>	 		if ( self::$instance === null ) {
[19:30:30] <Reedy>	 			self::$instance = new self;
[19:30:30] <Reedy>	 		}
[19:30:30] <Reedy>	 		return self::$instance;
[19:30:32] <Reedy>	 	}
[19:30:49] <tgr>	 in the installer I wouldn't exclude the possibility that something somewhere resets the globals and you end up with a different object
[19:31:07] <xSavitar>	 Okay Reedy
[19:31:31] <Reedy>	 So basically, it possibly comes to being micro optimisation
[19:31:56] <xSavitar>	 tgr: Okay, I get your point, thanks.
[19:32:28] <Reedy>	 Though, you would hope if the context was changing between the calls, it might be documented as such :)
[19:33:30] <xSavitar>	 Reedy, tgr, I didn't know that in the case of that code, the global could have been resetted, I didn't see it.
[19:33:39] <xSavitar>	 but yeah, it makes sense
[19:34:22] <tgr>	 you wouldn't, unless the walk through the entire call tree between the two points of using the getter
[19:34:32] <tgr>	 which is exactly what I don't want to do :)
[19:34:53] <xSavitar>	 Okay, makes sense, so in that case, we just leave it as-is for now.
[20:00:03] <SMalyshev>	 James_F: that WikibaseMediaInfo fail is weird, not sure if it's related but I'll take a look
[20:02:21] <James_F>	 SMalyshev: If it's related then I'm worried that it passed in master.
[20:02:49] <SMalyshev>	 yes indeed... it passed merge tests so I wonder what's different....
[20:03:10] <SMalyshev>	 maybe some unmerged bugfix for mediainfo?
[20:04:32] <James_F>	 I looked, I don't see anything obvious.
[20:04:35] <SMalyshev>	 no recent fixes to that test
[20:10:42] <SMalyshev>	 ApiUpload::performStash Stashing temporary file failed: UploadStashFileException Could not store file &#34;/tmp/MW_PHPUnit_Wikibase\MediaInfo\Tests\Integration\MultiLingualCapV9xIR7
[20:10:46] <SMalyshev>	 that worries me