[18:58:18] Krinkle: you're right in reverting me, but I've never suggested that it was the script's fault :) [18:58:40] Nemo_bis: If you don't have the gadget enabled and click the native link twice you'll also get 2 entries. [18:58:57] Nemo_bis: okay, but my gadget page is not a documentation page about this feature, its a specific script [18:59:26] so I don't want some negative stuff about core bugs on my POV 2.0 gadget page :P [18:59:39] lol [18:59:55] especially since docs pages are in the habit of being outdated, so I there's a chance it will still mention that bug years after it is fixed. [18:59:58] it's just one more reason to disable the script, which is something you agree with IMHO [19:00:03] yep [19:00:08] Although not entirely [19:00:22] There are a few features the native script doesn't have, that I personally use a lot [19:00:26] that's true, but also the script will hopefully superseded by that time [19:00:26] patrolling from a bookmarklet [19:00:39] Right. [19:00:53] (because the patrol link can be on different parts of the page, sometimes a few pixels down/up if the edit summary is longer) - when opening 20 tabs it is nice to be able to just click through. [19:01:01] and my bookmarktet also closes the tab when ready [19:01:24] I also miss a lot Pathoschild's rollback and patrol AJAX buttons on RC and WL [19:01:41] what about them? [19:01:49] they've been broken for a while [19:01:53] ai.. [19:02:08] https://meta.wikimedia.org/wiki/User:Pathoschild/Scripts/Ajax_sysop [19:02:18] https://github.com/Pathoschild/Wikimedia-contrib/issues/8 [19:02:44] "The rewrite should be just about done; what's left is mostly refactoring and tying up loose ends" (4 months ago) [19:04:05] I didn't file bugs for that because it's maybe too much for core. [19:04:20] meh, ajaxing those should be fine [19:04:30] although for rollback it can get a little non-trivial [19:04:36] because of the diff [19:04:43] I mean adding more links on RC and WL [19:04:46] that's useful to catch errors (just in case) [19:04:56] Yes. [19:04:58] Oh, well, RC is a decade old pile of shit [19:05:11] the API has been refactored 3 times, but the special page is still the same [19:05:21] many features it is lacking that the backend offers already [19:05:32] Speaking of which, I daily pray for https://bugzilla.wikimedia.org/show_bug.cgi?id=35785 [19:05:36] Nemo_bis: (spam spam spam) Have you tried Krinkle's RTRC ? [19:05:46] Krinkle: lol, I think I did [19:05:55] But I'm not a big patroller, so... [19:05:57] that's like RC on steroids using just the API but a different frontend instead of SpecialRecentchanges [19:06:05] I advertised it to several users I think. [19:06:19] Ah, I'll give you a raise then [19:06:23] 3x 0 [19:06:25] :D [19:07:27] You could also volunteer for the position of volunteer PM for mood/attitude which sumana suggested me to open for myself after https://blog.wikimedia.org/2012/11/21/lead-development-process-product-adviser-manager/ [19:07:31] :p [19:07:41] we should come up with a few features related to countervandalism we need most and get the foundation to work on them. [19:08:01] that's supposedly https://www.mediawiki.org/wiki/Admin_tools_development :) [19:08:25] current investment in countervandalism is unacceptable imho, its a mess. without the Countervandalism Network and the Toolserver tools it and other people maintain it'll be a disaster [19:08:29] The mass of countervandalism tools is a real mess across wikis. [19:08:40] and all of it relying on an ancient unstable service that is unmaintained (irc.wikimedia.org) [19:08:59] There is progress though [19:09:00] https://github.com/Countervandalism [19:09:05] Well I hope the Toolserver won't be killed, but I don't want to discuss this [19:09:25] well, toolserver slowly going away isn't the problem. [19:09:36] We'll migrate them to labs, but that is just as much a probelm. [19:09:41] So you think that XMPP RC feeds should be one top priority? [19:09:52] Countervandalism and reviewing should be as high a priority (or higher) as editing. [19:10:01] I think XMPP RC feeds can rot in hell. [19:10:15] but its probably better than IRC. [19:10:20] What confuses me most is that we have Huggle and Twinkle on en.wiki and a few other wikis, than it.wiki uses LiveRC, Commons your RTRC, other wikis I don't even know... [19:10:40] * Nemo_bis runs to dinner [19:11:12] what part confuses you? that we don't have a standard? Well that's because all of them have issues, mainly the part that their not native. [19:11:25] So different wikis make different compromises and settle on an acceptable tool [19:12:17] Anyhow, I've got a few plans I intend to get on the foundation's agenda soon. But there's a few other things that have to happen first. One step at a time :) [19:12:36] (that is, as staff member of the countevandalism network, not as a developer) [19:14:00] IRC seems to be simple and good enough as RC feed [19:14:40] No, on the contrary [19:14:57] The reason it has worked for so long is because of a handful of people doing 2 things very well: [19:15:06] Writing horrible regexes that get it right most of the time [19:15:10] yes [19:15:21] 2) Making sure nothing ever changed in any way to that feed, or the sky will fall down. [19:15:28] yes [19:15:47] We can't add any data to that feed because the length is limited. [19:15:55] we can't fix any bugs [19:16:42] well we can depending on the level of screaming we want to hear [19:16:50] The way I'd like to propose is to use simple JSON packages, machine readable (not human readable). That means short and concise keys with machine-readable values. [19:17:03] That also means we can add features later on without breaking anything because we'd just add a property. [19:17:15] you can throw out all rcprops this way [19:17:22] Yep [19:17:28] and this will be served as the IRC-ready UDP stream? [19:17:32] basically api.php?action=recentchanges [19:17:36] No, not IRC [19:17:43] there is no point in broadcasting JSON over IRC [19:17:58] it would be a proper socket, without all the IRC cruft around it [19:18:01] (maybe websockets) [19:18:12] I thought that XMPP had some issues with keeping a long session [19:18:19] Then one possible application is to create an irc bot that creates what is now irc.wikimedia.org [19:18:20] IRC cruft is actually almost nothing [19:18:38] Since we'll want to keep irc.wikimedia.org until all tools are migrated. [19:18:44] irc.wikimedia.org would become a consumer of the feed [19:18:48] I think it's accidential that MW outputs IRC-ready UDP packet [19:18:57] Krinkle: :P [19:19:00] Not really, it uses irc color codes. [19:19:10] 3,0 [19:19:14] 3,0this [19:19:19] maybe [19:19:36] yes ^Cm,n convention [19:19:57] uaaaaa, my eyes are hurting [19:20:26] So MediaWiki would still emit lightwight UDP packages with JSON in it (we can't do sockets since that'll be too expensive probably), then a UDP listener will aggregate that internally from the different webservers and provide a public pub/sub feed. [19:20:42] And to allow no length issues, I wrote up a D-JSON protocol a while ago [19:21:09] that allows splitting it up in different parts. Nothing fancy really, there's probably a dozen other protocols like it, but its something we could use. [19:21:22] Anyhow, the implementation has a few points to be discussed, but no blockers. [19:21:35] It just needs a small team assigned to work on it [19:21:37] isn't this related to the eternal "let's have xmpp rc channels" bug/request? [19:21:52] It has an overlap, yes. [19:22:02] there kind of is one [19:22:04] just not productionized [19:22:09] because i haven't had the time [19:22:10] But this is from a different POV, namely the one of countervandalism tools and the foundation not investing in that area at all. [19:22:12] why don't we emit the xmpp stuff then? [19:22:13] well, enwiki does [19:22:17] (other than keeping irc.wikimedia.org running) [19:22:48] begins to sound complex :) [19:22:54] ori-l: maybe, but it is not stable, maintained, standardised and highly available, right? [19:23:08] you mean the one on labs? [19:23:09] details :) [19:23:25] ori-l: heh [19:23:26] that's been done several times before on toolserver, not hard to set up. [19:23:44] like I said, the implementation is trivial. It needs to be discussed and agreed on, but there are many options to choose from. [19:23:56] it just needs to happen and then maintained. [19:24:27] ofcourse that's only the tip of the iceberg. the feed is just an enabler, we still need actual integrated tools that use them. [19:24:51] ideally in the form of a work-flow extension (like WikiHow has). [19:25:03] k, back to the mail backlog. it's email day. [19:25:14] (half day anyway) [20:36:20] hey! just wanted to say hello, everyone. [20:37:45] hi analphabet [20:39:02] analphabet: Hey, what brings you 'round these parts? [20:39:11] hu!? [20:41:11] marktraceur: ah, I'm just going for a walk, need some rest from all those heated discussions in #etherpad-lite-dev [20:41:26] so I'm wandering about freenode ;) [20:41:32] Heated? /me reads backscroll [20:43:26] ... and they say IRC is dead :) [20:47:16] marktraceur: Actually, I was told to ask for some DJ in here who would be able to help me with svg rasterization problems [20:47:43] marktraceur: but that must have been a joke, obviously [20:47:52] Oh, but analphabet, you don't want just *some* DJ [20:47:56] You want _the_ DJ [20:48:02] thedj[work]: analphabet has come for you [20:48:21] * analphabet chuckles [20:51:59] heh [20:52:08] Ah, it's _the_ DJ then... Ah, but then I think we've already sorted this out at twn [20:52:10] what's the problem? out of curiosity [20:53:20] saper: i drew a very nice-looking logo, saved it as svg and uploaded on twn -- it would be fine at 200px size [20:54:32] is it using any fonts? [20:55:41] saper: but when it came to smaller sizes -- like 30px -- the different graphs would be ripped apart [20:55:41] I think I see [20:55:50] you do? [20:55:54] http://translatewiki.net/w/images/6/6f/Etherpad_lite.svg this looks very messy in my firefox [20:56:14] is it this one? [20:56:38] saper: it's sometimes messy and sometimes not :) [20:56:42] in my firefox [20:57:00] analphabet: I have some experience in fixing SVG by hand, let me have a look [20:57:06] I don't like the drop shadow though :) [20:57:42] saper: you don't like drop shadows at all, or just how i did it? [20:59:59] that one looks überflussig to me, the simple logo is pretty nice [21:00:15] but let's fix the bug instead of bikeshedding :) [21:01:09] analphabet: first thing, did you try "plain SVG" save instead of Inkscape SVG? [21:02:08] no [21:02:26] trying that now [21:04:25] oho! [21:04:33] seems to make a difference... [21:04:59] better? [21:06:22] https://translatewiki.net/wiki/File:Etherpad_lite.svg [21:06:39] now it is in my firefox like the thumb [21:10:01] saper: not really, the plain svg is display correctly now, but at smaller sizes the shadow's still ugly [21:10:38] the shadow is applied as an extra filter [21:10:46] it's a very shaky feature I would say [21:11:49] saper: extra *filter*? I did the shadow by copying the original graph and blurring it [21:12:06] yes [21:12:27] inkscape:collect="always" [21:12:27] stdDeviation="0.85337489" [21:12:28] id="feGaussianBlur3967" /> [21:12:31] nasty [21:12:53] I wouldn't expect it to work good [21:13:39] i would. [21:13:44] :/ [21:16:03] really; it's not nice :) [21:16:23] saper: should i remove it then? [21:16:33] Personally I don't like it [21:16:59] it does not match the simplicity of a drawing [21:17:07] plus it will look bad black+white [21:18:16] I have removed lots of unnecessary elements [21:19:26] saper: updated it https://translatewiki.net/wiki/File:Etherpad_lite.svg [21:19:28] which fixed my Firefox problem [21:19:44] nice! [21:22:01] I#m not too happy with it that way, but whatever... [21:22:56] checking... [21:24:25] uploaded new revision that renders ok with my firefox [21:26:21] thx [21:27:00] so now it's only two paths [21:27:55] one thing I don't like from the design point of the is the fourth line behind the picture, it is too close to the "front leg" [21:28:02] but maybe it's meant this way [21:28:40] saper: do you also want to help fix some Wikimedia logos? [21:28:54] we have 50 missing Wiktionary logos and 50 missing Wikipedia logos, more or less [21:29:20] Nemo_bis: what needs to be done? [21:29:21] (not counting those we don't have of the text translations for) [21:29:22] fooo [21:29:58] saper: more or less this: https://commons.wikimedia.org/wiki/User_talk:Odder#More_logos [21:30:20] odder is doing some but they're so many (he's doing Wiktionary for now, iirc) [21:30:48] maybe it should be scripted? [21:31:07] saper: can it? [21:31:22] have you looked at the page on Meta? https://meta.wikimedia.org/wiki/User:Cbrown1023/Logos [21:31:25] ah, I'll say good night then.. [21:31:25] I am readings this; not sure what needs to be done exactly [21:31:33] weird languages are weird [21:31:53] we have words and they need to be translated to SVG :) [21:32:10] bless you diligent wiki* devs [21:32:11] within the boundaries of what can be a reasonable logo [21:33:38] saper: if instead of hands-on fixing you prefer to give advice on best practice, you could comment the official instructions instead https://wikimediafoundation.org/wiki/Wikimedia_official_marks/Word_mark_creation [21:34:11] (they don't mention "plain SVG" save, for instance) [21:34:19] words are not a problem, could be possible scripted the question [21:34:39] saper: I've no idea :) [21:35:03] if you're able to, I guess it would be nice to create a bunch of logos and then fix those which have problems manually [21:36:24] yes, maybe [21:37:58] things like this logo which was a bit too tall https://commons.wikimedia.org/wiki/File:Wiktionary-logo-my.svg [21:39:33] also, as after this bulk of 100 there will still be about 70 more logos to create sometime, a script could help future generations :) [21:40:13] so it's wikt mostly? [21:40:19] saper: half and half [21:40:40] I think it's more urgent for Wiktionary because Wikipedias usually have a localised logo, just the old version [21:41:47] yep [21:42:02] maybe I could write a script in Postscript :) [21:43:18] I recently fixed SVG generator in ghostscript so it could be done there [21:43:29] saper: well, it would be great; let me know if I can help somehow [21:43:43] I need to understand the task first :) [21:44:00] you could look at the last logos created by odder to see what's the best standard format [21:44:09] what do you need to understand better? [21:44:11] is odder alive by the way? [21:44:24] just need to read the wikipages carefully, I just glanced over [21:44:43] in postscript I can get a width of a generated text easily so it could be scaled [21:44:50] if necessary [21:45:27] yes he is [21:45:39] ok