[00:17:15] 06Multimedia, 06Commons, 10MediaWiki-Categories, 07Browser-Support-Google-Chrome: Filenames are truncated on category pages - https://phabricator.wikimedia.org/T143281#2563081 (10Jdforrester-WMF) 05Open>03Invalid Yeah; could you file something at https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget... [06:25:21] 06Multimedia, 06Commons, 10MediaWiki-Uploading, 10Possible-Tech-Projects, 07Community-Wishlist-Survey: Add support for KML/KMZ filetype - https://phabricator.wikimedia.org/T28059#2563400 (10Rschen7754) @putnik Any updates? [14:00:56] Wow, that bug that quiddity helped shepherd last night is already closed. [14:01:14] Back to looking for stuff to do, I guess [14:01:17] prtksxna: How's tricks? [14:25:47] marktraceur: Tricks? [14:26:46] prtksxna: Never mind; I was just typing in the standup notes that I wanted to talk to you about FA design stuff, would you rather do that before or after the standup? [14:27:23] marktraceur: Before would be better. Now? [14:27:29] Sure, one sec [14:27:55] marktraceur: Lets just use the standup hangout [14:28:10] Agreed [14:36:47] marktraceur: rejoining [14:37:08] bd [14:45:38] marktraceur: o/ [14:46:02] prtksxna: Literally understood nothing of your last length of speech [14:46:12] The standup should be extra fun today [14:47:05] So I think what we're talking about is whether, in displaying an annotation that is just [[Category:Barack Obama]] or whatever, should we only show images or show biographical data from his WD item? [14:47:08] marktraceur: I was wondering if the add annotation interface should have a unified search for wikidata and wikipedia [14:47:29] On that, I think we should hold off, I'm more asking about display right now if that's okay [14:47:43] We were, yes, and that lead me to talk about how that annotation was added in the first place [14:47:54] marktraceur: ok [14:48:08] marktraceur: So if its a commons category we should pull in stuff from wikidata [14:48:09] prtksxna: Let's assume for now that it was added free-form, with no other option, and we can alter our thinking on that as we build different editing tools [14:48:19] OK, cool [14:48:34] marktraceur: The editing interface will have a way to quickly turn links to wikidata items where they exist [14:48:46] Sounds good [14:48:54] marktraceur: But lets not change the way its displayed till an editor makes the change [14:48:57] Yeah [14:49:27] prtksxna: OK, so next is a Wikipedia article, which I assume is much the same - display a hovercards-like summary of the article, plus the article image, and infer a WD item if possible [14:49:54] marktraceur: Yep [14:50:16] marktraceur: But infer that only for the editing interface, not to change the display, right? [14:50:28] Oh, I see what you mean [14:50:36] prtksxna: OK, yeah, that could make sense [14:51:05] (y) [14:51:07] prtksxna: Sorry, somewhere between the hangout static and my own theories I lost what we were talking about [14:51:37] marktraceur: I am not sure if the map annotation is a real usecase [14:51:37] Hm, map templates...is that something we can drop in relatively easily? Did you talk to yurik et al. about that? [14:51:42] Yeah [14:51:57] marktraceur: I haven't yet [14:52:01] I think there's a {{subject location}} and {{camera location}} template system on Commons but I'm not sure it's worthwhile [14:52:04] * yurik reads back [14:52:22] yurik: We're talking about annotations in files [14:52:29] yurik: See https://www.mediawiki.org/wiki/Extension:FileAnnotations/Design and https://www.mediawiki.org/wiki/File:Map_annotation.png [14:52:39] We have a potential use case where an annotation is only a set of coordinates. [14:52:52] I think it may be good to put a pin in that, though [14:53:21] I haven't done much research, but I doubt they'd be a lot of annotations that are map only, and can't be expressed as wikidata/pedia items [14:53:55] prtksxna: What is the "explore" for the WD item display? WikiVoyage? :) [14:54:07] marktraceur: I agree (because, pin, in maps, right? right???) [14:54:24] * marktraceur groans [14:54:55] marktraceur: Hmm, I didn't think wikivoyage, though that sounds like a good idea. [14:55:03] I mean, what did you think? [14:55:16] marktraceur: I was thinking it'll just open a map interface, like leaflet or something [14:55:17] We could actually put links to every project, but we'd need some kind of context perhaps [14:55:35] Separately, not in the annotation itself [14:55:39] marktraceur: Right [14:55:59] OK, so maybe mapping WD properties and links to projects to contexts will be part of this, which sounds fun [14:56:09] marktraceur: That is what this sort of is. [14:56:15] marktraceur: Is it possible to do? [14:56:44] prtksxna: Absolutely! [14:56:52] Just have to map it and make sure there are messages for each one [14:56:52] \o/ [14:57:10] That's the whole point of structured data, so we're definitely pushing the limits here, which is what we came to do- [14:57:41] :) [14:58:23] OK, I'll get started on this stuff today and see what I come up with [14:58:35] prtksxna: Sorry about the hangout problems, hopefully we can breeze through the standup [14:58:48] marktraceur: I'll copy your etherpad notes to the talk page? [14:58:53] prtksxna: Sure! [15:00:03] prtksxna, marktraceur, commons has tried to do this already, e.g. https://commons.wikimedia.org/wiki/File:Passeport_italien_-_1818_-_Recto.jpg [15:00:26] there is a map on that page. Plus they tried to improve the location template to support it as well [15:01:11] but yes, i agree that we could build a better annotation system [15:01:25] yurik: Iiiinterestink. [15:01:38] yurik: We are building it, it is at least 40% built now [15:02:10] also, now that kartographer has been rewamped, it is much easier to show a map in mediawiki programattically [15:02:11] We just need it to be a little prettier, because it turns out I have the design instincts of a sloth [15:02:12] 45 [15:02:22] James_F: So generous [15:03:55] marktraceur, weren't you the one who was trying to improve commons uploader? [15:06:34] yurik: Several times, yes [15:06:46] i mean - by adding a map? [15:07:07] we deployed jgirault 's code last week [15:07:11] Oh, no, that was inchuikitty or someone, a GSoC student, under...I think jdlrobson, but I can't quite recall [15:07:12] so now its in prod, you can use it directly [15:07:27] We looked at reviving the patch but haven't gotten past the planning stage [15:07:41] MatmaRex (who is conspicuously absent) is the one currently working most heavily on UW [15:10:17] ah yes, it was matmarex [15:13:52] James_F: Wait, how are we planning to integrate talk pages into MCSR, and how is it any different from our use-case? [15:14:06] Are you maybe thinking that we're still storing annotations on the file page? [15:14:47] I don't think we have any plans to integrate talk pages in MCSR. [15:14:59] Oh. Well that removes a huge benefit IMO [15:15:02] I thought you were going to store them on a different namespace? [15:15:07] Yeah, that's the evil plan [15:15:10] Wait, you're thinking of storing them on talk pages?! [15:15:13] Oh, good. [15:15:23] I guess I have to read the RfC after all [15:15:30] No no, I can simplify. [15:15:32] So, AIUI, our options are: [15:15:50] A) Roll out pre-MCSR to namespaces. When MCSR comes around, do nothing. [15:16:24] Which potentially means out-of-date annotations, even out-of-bounds annotations, if an image changes [15:16:45] A) Roll out pre-MCSR to namespaces. When MCSR comes around, switch how it works to use MCSR (so integrated histories, atomicity, etc.), and have a migration script convert current revisions to new ones. [15:16:48] Err. [15:17:03] B) Roll out pre-MCSR to namespaces. When MCSR comes around, switch how it works to use MCSR (so integrated histories, atomicity, etc.), and have a migration script convert current revisions to new ones. [15:17:28] C) Roll out pre-MCSR to namespaces. When MCSR comes around, switch how it works to use MCSR (so integrated histories, atomicity, etc.), and have a migration script convert all revisions retrospectively to MCSR ones. [15:17:35] A) has the disadvantages you mentioned. [15:17:39] C) is deeply scary. [15:18:00] B) means having back-compat code in FileAnnotations for the rest of time (and never being able to get rid of the namespace). [15:18:13] Hence I was thinking of (D) Don't roll out until MCSR. [15:18:13] James_F: I don't see a problem with B that is obvious, except that old revisions would have the problems A would present [15:18:41] D would be a perfect (knock on wood) solution, but we are already crippled enough with blockers that I'm frustrated we can't push anything out [15:18:45] marktraceur: It's committing up-front to tech debt and user awkwardness. [15:18:54] Yeah, I don't think D is a good option either. [15:19:39] James_F: OK, AIUI B would entail moving the File annotations namespace into a content slot in every past revision, and instead of changing multiple slots in past history, every revision only changes one slot. Like a collation of the histories. [15:19:48] That seems imperfect but not prohibitively so? [15:20:10] Isn't that (C)? [15:20:25] Oh, sure, C. So I guess now I'm asking about C and wondering why it's so scary [15:20:44] Apart from the huge amount of data we'd need to crunch [15:20:48] You go from edits Xn in File and Ym in File_annotations to Z{n,m} in File*. [15:20:54] Well, not that huge. [15:21:18] Those edits already existed, so it's not like we're adding anything [15:21:20] We'd only need to re-write the edits for any Files with an associated File_annotation page. [15:21:24] Yeah. [15:21:45] I dunno, I just worry about retrospective rewrites. If you're not too worried, I won't be. [15:21:54] It might confuse the history slightly, but maybe the MCSR implementation could include "filter edits to ones that changed slot X" [15:22:02] * James_F nods. [15:22:03] Maybe I should talk to Danny [15:22:10] Which Danny? [15:22:26] Er, Daniel [15:22:35] The MCSR-y Daniel [15:22:37] Ah, OK. Yeah, maybe. [15:29:55] Ugh, now I feel silly seeing there was an office hour on MCR yesterday [15:30:05] Or at least part of the RfC office hour [15:33:47] There was. [15:33:53] It went long, in fact. [15:34:14] Good discussion. This kind of stuff didn't come up though. It was almost entirely about DB tables. [15:36:07] Yeah, I figured. Maybe better that we have this conversation with him separately [15:50:14] James_F: See -dev, he seems unconvinced [15:52:56] I'm going to run numbers on how many files have annotations, hopefully it shouldn't be an issue [16:43:48] Hey MatmaRex, how's it going? [16:44:22] sup marktraceur [16:44:38] Just starting a flurry of file annotation things today. [16:51:16] 06Multimedia, 10UploadWizard, 05WMF-deploy-2016-08-23_(1.28.0-wmf.16): Unknown error: "badparams" - https://phabricator.wikimedia.org/T143134#2564953 (10matmarex) 05Open>03Resolved [17:03:03] OK, MobileFrontend is not loading FileAnnotations, which is a problem for another time, but I'm going to leave the "flash" code in there for now... [17:13:15] (03PS3) 10Bartosz Dziewoński: mw.FormDataTransport: Unbreak error handling for async uploads [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/305272 (https://phabricator.wikimedia.org/T143213) [17:14:05] 06Multimedia, 10UploadWizard, 13Patch-For-Review: Uncaught TypeError: Cannot read property 'warnings' of undefined - https://phabricator.wikimedia.org/T143213#2565054 (10matmarex) p:05Triage>03High [17:19:46] (03CR) 10jenkins-bot: [V: 04-1] mw.FormDataTransport: Unbreak error handling for async uploads [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/305272 (https://phabricator.wikimedia.org/T143213) (owner: 10Bartosz Dziewoński) [17:22:31] woot [17:22:35] is master broken? [17:22:49] Might could be... [17:23:41] arrrghghgrhgr [17:23:47] we depend on messages defined in WikimediaMessages [17:24:15] we probably can define a dependency somewhere in CI config… but i have no idea where. [17:24:19] James_F: ^ do you know? [17:28:25] Oh, huh. Not sure. [17:28:33] Do it as a conditional registration? [17:29:16] ew [17:29:16] no [17:29:44] it doesn't break anything if WikimediaMessages is not available, other than krinkle's new structure test [17:30:06] and i would have to conditionally register everything, and move it back out of extension.json [17:56:05] 06Multimedia, 06Commons, 10MediaWiki-Categories, 07Browser-Support-Google-Chrome: Filenames are truncated on category pages - https://phabricator.wikimedia.org/T143281#2565229 (10matmarex) The Chromium bug for this is . [17:58:08] 06Multimedia, 06Commons, 10MediaWiki-Categories, 07Browser-Support-Google-Chrome: Filenames are truncated on category pages - https://phabricator.wikimedia.org/T143281#2565237 (10matmarex) Looks like https://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-Long-Image-Names-in-Categories.css&diff=20... [19:37:58] there's no hangout this evening? [20:36:26] MatmaRex: No, James_F and I both can't make it so we cancelled