[04:10:02] Woohoo! [10:12:38] (03PS36) 10Brion VIBBER: ogv.js media player for desktop Safari/IE/Edge (2 of 2) [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/165478 (https://phabricator.wikimedia.org/T63823) [10:12:41] (03PS1) 10Brion VIBBER: Update ogv.js libraries to 0.9 release [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/223261 [10:28:14] (03PS2) 10Brion VIBBER: WIP: very basic TimedMediaHandler frontend for mobile [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/217485 [10:28:49] (03CR) 10jenkins-bot: [V: 04-1] WIP: very basic TimedMediaHandler frontend for mobile [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/217485 (owner: 10Brion VIBBER) [11:11:35] 6Multimedia, 10MediaWiki-extensions-TimedMediaHandler, 7Browser-Support-Internet-Explorer: Attempting to play Ogg audio files in Internet Explorer fails with a Java error - https://phabricator.wikimedia.org/T104801#1433594 (10brion) Ok, I've updated the ogv.js integration patches & demo site -- can you try t... [11:20:41] 6Multimedia, 10MediaWiki-extensions-TimedMediaHandler, 7Browser-Support-Internet-Explorer: Attempting to play Ogg audio files in Internet Explorer fails with a Java error - https://phabricator.wikimedia.org/T104801#1433615 (10TTO) Yes, the audio file on the Main Page (JS Bach Prelude on the harpsichord) play... [12:34:43] (03CR) 10TheDJ: ogv.js media player for desktop Safari/IE/Edge (2 of 2) (034 comments) [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/165478 (https://phabricator.wikimedia.org/T63823) (owner: 10Brion VIBBER) [12:47:21] marktraceur: Do you write your gadget scripts on-wiki? [12:47:37] marktraceur: Should I just make a mostly front-end extension for now? Lets me keep my code modular etc. [13:49:32] prtksxna: I have gadgets on my local wiki that are copied manually to phabricator pastes [13:49:46] You could write an extension if you wanted... [13:49:57] prtksxna: I guess what I'm wondering is what you're working on exactly [13:50:14] marktraceur: Right, but do you edit the JS onwiki, or is there an easy way to load from disk [13:50:28] I was working on a license widget for https://github.com/prtksxna/uw-prototype [13:51:08] marktraceur: There are things in the repo I can use directly, just add the API stuff from your gadget code and we'll have something useful [13:52:04] AOK, well [13:52:31] prtksxna: The gadgets are edited on-wiki, but I usually open the MW edit interface, immediately cut and paste into gedit, and edit there, then copy and paste back and save. [13:52:42] I'm not aware of any better way to do it :( [13:52:47] Extensions, I guess. [13:53:04] Yeah, I do something similar. [13:53:14] I thought I was doing it wrong :\ [13:53:42] Extension, yeah. [13:54:15] prtksxna: I'd suggest making it similar enough to a gadget that we can go either way [13:55:15] marktraceur: Yeah, the extension will just load a bunch of JS, and i18n strings, like Popups… [13:56:11] prtksxna: i18n strings are pretty exclusively not gadget-y, at least not without hacks [13:56:52] We could just replace those if we need to [13:58:35] OK then [13:58:51] prtksxna: I guess you can and should move more towards something that's MediaWiki-y [13:58:57] Instead of hacky-on-Commons-y [13:59:12] I can probably do the latter later. :) [13:59:17] marktraceur: We'll still have the license picker? [14:00:29] Of course. [14:00:44] prtksxna: The license picker is going to be necessary in the VE implementation of all of this [14:01:06] prtksxna: Right now what we need is a relatively generic OOUI widget that will fetch you an upload. [14:02:37] marktraceur: I don't think I understand the difference between MediaWiki-y and hacky-on-Commons-y. [14:06:04] prtksxna: As we get to the point where we have a stable API, I'm going to start writing a couple of quick gadgets for Commons and probably Wiktionary so people can upload more easily [14:06:28] And to show them that they can write cool upload gadgets now. :) [14:06:47] But first, I must address MatmaRex's nitpicks. :P [14:07:10] * MatmaRex waves [14:07:29] That's the guy, right there [14:18:23] MatmaRex: First patch amended, moving on... [14:20:46] MatmaRex: I swear, I have you and Krinkle on either shoulder, telling me to do opposite things [14:21:01] "Use else ifs" "No, just return from the negative if statements" [14:21:31] marktraceur: ugh, i think that's something he and I disagree about [14:21:56] so i guess you need to choose your favorite way :P [14:22:17] Well, I did [14:22:22] I mean, I like this method anyway [14:22:32] I just didn't do it this way at first because it seemed easier [14:26:37] (03CR) 10Brion VIBBER: "Thanks for the review! Notes inline" (033 comments) [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/165478 (https://phabricator.wikimedia.org/T63823) (owner: 10Brion VIBBER) [14:31:36] (03CR) 10Bartosz Dziewoński: [C: 032] Check campaign content model [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/222042 (https://phabricator.wikimedia.org/T104395) (owner: 10Gergő Tisza) [14:32:39] (03Merged) 10jenkins-bot: Check campaign content model [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/222042 (https://phabricator.wikimedia.org/T104395) (owner: 10Gergő Tisza) [14:33:32] 6Multimedia, 10MediaWiki-ContentHandler, 10MediaWiki-extensions-UploadWizard: Moving From NS_USER to NS_CAMPAIGN leaves the page with the wrong content model - https://phabricator.wikimedia.org/T104408#1434189 (10matmarex) Vaguely related: {T45049}. [14:45:43] 6Multimedia, 10MediaWiki-extensions-TimedMediaHandler, 6operations, 7HHVM: Convert tmh100[12] to HHVM and trusty - https://phabricator.wikimedia.org/T104747#1434255 (10Krenair) [14:46:33] Damn it cat, I cannot type if you are attacking my hand [14:47:28] Most cats are willing to press buttons on your keyboard on your behalf [14:47:33] or at least mine do that [14:49:28] Mine is mostly just obstructive or loud. [14:53:20] 6Multimedia, 6Commons, 10MediaWiki-File-management, 10MediaWiki-Tarball-Backports, and 7 others: InstantCommons broken by switch to HTTPS - https://phabricator.wikimedia.org/T102566#1434294 (10Tau) I downloaded 2 php.ini files via FileZilla from directories /etc/php5/apache2/ and /etc/php5/cli/. Changed... [15:11:24] * GEOFBOT|busy hides secret cat-telepathy device [17:44:10] Hullo. [17:44:26] Hi [18:59:40] James_F: Hi there! [19:01:56] prtksxna: What extension are you creating to test your new UI elements? [19:02:34] I'm thinking I should create something like Extension:CommonsUpload to hold the various Commons-specific libraries, and I'm wondering if your extension might be a better home for them [19:03:42] Or maybe I should dump them into CommonsMetadata [19:04:05] tgr: D'you think it's a good idea to throw frontend libraries for constructing {{information}} et al. into CMD? [19:05:01] depends on how permanent you intend them to be [19:05:15] if you need a quick and dirty solution, IMO it's fine [19:05:23] tgr: Do you not think CMD will be used when Wikibase is adopted? [19:05:59] I sure hope it won't :) [19:06:14] Not in the same form, but you could keep the API and the data structure that we're used to [19:06:16] Do you think Wikibase will be adopted before we die ;) [19:06:23] There's the real question. [19:06:28] James_F: Well? :) [19:06:32] but realistically, there will be a long transition period even in the best case [19:07:35] tgr: We'll still need the libraries for submitting Wikibase metadata anyway, so maybe that can be the only remaining part of CMD [19:07:49] the CMD the API is horrible, once we have Wikidata we should replace it with something that actually returns structured data and not |-separated lists and such [19:08:37] the CMD DOM parsing logic on the other hand is probably not something we can get rid of quickly [19:09:21] so I imagine there would be some new thing providing an API that abstracts away the source and can use the Wikibase API or the CMD hook internally [19:10:19] Agreed, but why not call that thing CMD as opposed to BrandShinyNewThingThatIsNotCommonsMetadata [19:10:37] It won't be the same system at all AFAICT [19:11:08] hopefully it won't be Commons-only, for one thing [19:11:17] although CMD is not either [19:11:25] Ah, OK, so we should rename it [19:11:40] But that comes down the line. ^d will be angry but he'll forgive us eventually. [19:12:14] For now, since it sort of *is* Commons-only, or at least it only contains Commons-style machine-readable data, that should be fine [19:13:46] CMD is Wikimedia-specific, and CommonsData might be something more reusable, in which case it might make sense to make the new API into a separate extension which optionally depends on CMD [19:14:12] CommonsData is too vague at this point to tell if that would make any sense [19:14:34] Eugh extension dependencies. [19:18:52] tgr: I think for now I'll stick my modules in CMD because it will be enabled on the places that matter [20:21:14] 6Multimedia, 10MediaWiki-extensions-CommonsMetadata: Create frontend API based on mw.Upload for Commons uploads - https://phabricator.wikimedia.org/T105071#1435797 (10MarkTraceur) 3NEW a:3MarkTraceur [21:50:23] marktraceur: Unless someone is in a habit of dying young, yes. [21:52:21] James_F: Heh, fair enough [21:52:36] marktraceur: No dying! [23:50:26] 6Multimedia, 10MediaWiki-Vagrant, 7Epic: All multimedia extensions/systems should have a MW-Vagrant role - https://phabricator.wikimedia.org/T88072#1436415 (10Tgr)