[00:16:45] is there an alolita about? [00:17:33] There is [00:17:44] not at her computer, but she's not far away [00:17:47] reckon you could lassoo her for me? [03:49:09] whoa, did anybody see this french story? [03:49:11] http://yro.slashdot.org/story/11/07/05/1646220/Company-Fined-euro25000-For-Altering-Wikipedia [03:51:43] Wikipedia. Srs bizness. [03:52:49] 25,000 euro is pretty serious business. [03:53:10] Especially if random people can now be sued for removing links on Wikipedia. [11:03:46] does someone remember when wmf's lucene implementation was switched over to java? [16:47:36] has anybody seen Russ lately? [17:16:56] what number for call in? [17:17:13] 2003 [17:28:33] Anyone know how to actually run the parsertests locally? [17:28:57] php tests/parserTests.php [17:29:08] while in MW's root dir [17:29:20] cool [17:31:05] kaldari: add that to the parsertests dox? [17:31:07] Added it to the documentation: http://www.mediawiki.org/wiki/Parser_tests [17:31:27] sumanah: fast huh? [17:31:27] thanks kaldari! [17:31:29] :) [17:31:48] I am a fooooool [17:33:14] <^demon> kaldari: Also you can do --help to get a bunch of options. Since you're working with ImageGallery, I imagine --regex="Gallery" would save you time :) [17:33:34] thanks! [17:35:20] ^demon: How do I have more tests failing when I limit it to gallery tests? [17:36:01] lol, that sounds very wrong ;) [17:36:03] <^demon> Come again? [17:37:53] I ran php tests/parserTests.php and got 1 test failure. I ran php tests/parserTests.php --regex="Gallery" and got 2 test failures. [17:39:49] wrong dependancies on templates perhaps ? [17:50:40] <^demon> parser tests should be pretty reliable there. Pastebin your two different results? [17:58:41] ^demon: Here's the failure I get only when I run with regex="Gallery" [17:58:42] http://pastebin.com/fTjsXDMQ [17:58:50] And this one wasn't caused by me at all [17:59:36] <^demon> Weird. [18:01:28] ^demon: This looks like a significant difference in output [18:01:56] <^demon> Quite. [18:02:01] ^demon: Is it safe for me to just ignore that one for now? [18:02:40] I don't feel comfortable fixing that test since I don't know what broke it. It might be legitimately failing. [18:04:11] <^demon> I don't believe it should be failing. [18:10:02] The link in the image definitly shouldn't be going to commons. Perhaps InstantCommons settings are somehow being used by your parser tests where they shouldn't be [18:10:18] ^demon: I found the parser test I missed earlier and fixed it. It's all checked in at http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91573 [18:11:18] *bawolff also has instantcommons enabled though and doesn't have that test failing [18:11:45] hi [18:11:50] hi hashar [18:12:01] I am overwhelmed ... [18:12:41] sumanah: have you finished up / published the "mediawiki testing" essay? [18:12:54] bawolff: turned off InstantCommons and that fixed it. [18:12:56] hashar: yes! I emailed wikitech-l, did you not see? [18:13:28] still have to read thoses (62 unread messages) [18:13:34] kaldari: Which begs the question of why instant commons causes it to fail for you and not for me [18:13:47] hashar: and I welcome your thoughts on the talk page [18:14:12] bawolff: And why does it only fail when I run with --regex="Gallery" ? [18:14:49] bawolff: Are you running with -regex="Gallery" ? [18:15:00] hashar: http://www.mediawiki.org/wiki/Talk:Requests_for_comment/Unit_testing [18:15:04] I tried it both with and without [18:15:19] hashar: my sympathies on the overwhelmption [18:16:14] kaldari: oh, now it fails for me [18:16:16] well going to eat. I will have a look at the testing RFC. [18:16:30] before i was running it as a user who didn't have permission to touch my images directory [18:17:02] <^demon> kaldari: "CiteParserTests::testParserTest with data set #7: ' after (bug 6164)' [18:17:32] ^demon: ? [18:18:33] <^demon> After your commit. There were some cite parser tests that needed fixing. [18:20:25] kaldari: no that i run the tests with the right user, it fails with regex, and passes without regex [18:20:47] ^demon: I fixed the test it's complaining about. It needs to be rebuilt. [18:22:03] bawolff: weird huh? [18:22:04] <^demon> You fixed the test in Cite? I didn't see an r# [18:22:53] alolita: awjr kaldari : Pushed bugfixes to prototype for AFT: http://prototype.wikimedia.org/release-en/ArticleFeedbackTest [18:23:01] oh, maybe not. Are there other parser tests outside of tests/parser ? [18:23:28] krinkle: thanks! [18:23:41] <^demon> Yeah, extensions like Cite and Pfuncs carry their own tests. [18:23:52] great [18:23:54] howief: krinkle has pushed aft fixes to prototype - ready to test? [18:23:56] sigh [18:24:13] howief: http://prototype.wikimedia.org/release-en/ArticleFeedbackTest [18:24:16] <^demon> If you have Cite installed, it'll run the tests [18:24:25] <^demon> When you run parserTests.php [18:25:03] found it [18:25:19] <^demon> :) [18:27:16] ^demon: fixed that one in r91578. [18:27:28] <^demon> I saw, just kicked off a new run. [18:27:51] That's the last time I try to fix a gallery bug on my day off :P [18:29:57] At least I know more about the parser tests now :) [18:30:42] <^demon> "All Tests Passed" [18:30:45] <^demon> \o/ [18:30:48] howief: Is the AFT fix good ? [18:30:56] (prototype) [18:34:13] \o/ [19:13:00] howief: I reconnected for a bit, have you verified the bug fixes on prototype ? [19:37:48] hey Krinkle [19:37:51] sorry just got out of a meeting [19:37:55] i'll check out the fixed on prototype [20:11:05] howief: I know youre' in/out meeting, but have you confirmed the fix ? [20:12:36] pdhanda: You around ? [20:12:45] Krinkle: yeah [20:13:50] pdhanda: Just letting you know (not sure if you were scheduled or whether this is new) that we should sync /branches/wmf/1.17wmf1/extensions/ArticleFeedback with the trunk equiv in abit [20:13:53] http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki&path=%2Fbranches%2Fwmf%2F1.17wmf1%2Fextensions%2FArticleFeedback [20:14:07] usually Roan does that kind of thing [20:14:39] I don't have 1.17wmf access, so wondering if you could do that. [20:14:40] Krinkle: yeah, I can do that, let me know when [20:14:43] Alrighty [20:14:51] i can do it now if you are ready [20:15:24] Well, I have confirmed the state but howief reported the bug and we weren't quite sure the bug was properly defined so verifying a fix is not 100%, better to have him see it first. [20:16:15] How long does such a sync usually take ? Perhaps we can do a push to test.wikipedia.org in the mean time. [20:16:17] Krinkle: can you give me 15 minutes? [20:16:22] Sure [20:16:23] ok, let me know when you need it done. I'll be around [20:16:30] thanks [20:30:09] howief: need your ok for aft changes to deploy live [20:30:41] howief: pdhanda, krinkle are avail to push now :-) [20:32:32] aft changes, heave! [20:32:38] starboard changes, heave! [20:33:29] can someone test on IE and safari? [20:33:33] I'm in a meeting so i can't [20:33:40] if we're good on IE and safari, we're good to go [20:37:48] brb, going to call my brother very quickly. earthquake off the NZ coast. [20:42:12] howief: Safari is good. [20:42:24] Now all we need is IE. [20:44:20] can someone test IE? [20:44:31] back [20:44:47] howief: i don't have IE; does anyone have IE on a VM [20:46:09] alolita: install ie tester? [20:46:16] *Krinkle boots VM [20:46:32] howief: what do you need tested? [20:46:45] I have been tracking down IE6 problems [20:47:00] alolita: Krinkle can you answer that? [20:47:06] *Lcawte dislikes etherpad, the side scrollbar keeps showing up as the hide/show for the right sidebar [20:47:26] hexmode: hi [20:47:26] Lcawte: yeah, Etherpad 1.1 introduced some bugs, I liked the previous version better [20:47:39] alolita: hey [20:47:50] can you test http://prototype.wikimedia.org/release-en/ArticleFeedbackTest [20:47:53] http://bugzilla.wikimedia.org/20781 Move 'mainpagetext' message to installer's .i18n file once it exists | That sounds too easy :/ [20:47:53] on IE [20:48:03] Np, I'll check it out in the VM now. Almost booted (native is usually better than IE Tester which is somewhat unnatural) [20:48:12] krinkle: awesome [20:48:15] thanks [20:48:41] *hexmode lets Krinkle handle it so he can do meeting prep [20:48:45] thanks! [20:48:58] Lcawte: Well Easy bugs come in 3 varieties, things that are on the level of spelling mistakes, things that require re-writing most of mediawiki, and things that are wontfix [20:49:23] Almost nothing is ever marked easy that's more then one line fix, actually easy, and should actually be done [20:49:25] I'm going to attack the i18n related stuff I thinks? [20:50:38] ew. my VM crashed. [20:50:47] ha. ha. [20:50:49] (not due to AFT) [20:50:50] :P [20:51:11] What'd be the method for that, are we suposed to have commit if we want to attack these, or do we just link patches to the bugs? [20:51:22] patches work [20:52:07] my vm is up if someone tells me what to test [20:55:15] hello [20:56:57] Krinkle: would you mind telling pdhanda how to test? [20:57:17] pdhanda: Yes, go to http://prototype.wikimedia.org/release-en/ArticleFeedbackTest [20:57:31] then hover the stars and verify there are tooltips appearing below them [20:57:53] then go to "View page stats" and then back to the rating panel, there should be no tooltips visible [20:58:16] then hover again and they should be appearing on-star and gone off-star [20:58:21] that's about it [20:58:57] thanks Krinkle [20:59:03] Bug triage here in ~2min: http://etherpad.wikimedia.org/BugTriage-2011-07 [20:59:50] ok alolita also verified on my vm [20:59:55] she said it looks good [21:00:19] howief, krinkle: pdhanda and i tested it on ie on her vm [21:00:28] seems to work with wrapped text [21:00:32] great! [21:00:39] lets deploy then [21:00:40] so i would say - deploy :-) [21:00:45] so merge and deploy? [21:00:58] krinkle: merge and deploy? [21:01:10] Yep [21:01:10] can someone give me a quick summary of the change... for a log message when i deploy [21:01:23] Sync trunk/ext/AF to /branches/wmf/1.17/ext/AF then to test.wp [21:01:45] pdhanda: See http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki&path=%2Fbranches%2Fwmf%2F1.17wmf1%2Fextensions%2FArticleFeedback for previous summaries [21:01:55] Bug Triage time! [21:02:05] pdhanda: usually not specific as you see :D [21:02:10] Krinkle: k i'll let you know when it is on test.wp [21:02:15] cool [21:02:30] If you're in the triage, please get on the Etherpad: http://etherpad.wikimedia.org/BugTriage-2011-07 [21:02:38] 2min per bug [21:02:44] k, hexmode saved the notes bout the two i18n bugs [21:02:54] Lcawte: ty! [21:03:31] just so everyone knows, I'll repeat this: [21:03:46] These bugs are all tagged "easy" [21:03:59] this triage is to verify that they actually are easy [21:04:24] First off: http://bugzilla.wikimedia.org/8178 [low enhancement] Make table of contents for category pages: Subcategories, Pages, Media [21:04:24] [21:05:27] Sounds easy, better question, do we really want that? [21:05:32] krinkle says that one is: "Easy for those somewhat familiar with MediaWiki OutputPage. Howeverw the need / it being wanted is in discussion " [21:05:32] [21:05:50] Although we do do something similar on image pages I suppose [21:05:59] sounds like it is an iffy one, but maybe yes? [21:06:09] i have the same concerns [21:06:26] It might be a good idea for big categories, make it optional in preferences/localsettings maybe? [21:06:50] for it to be unobtrusive, it needs some good interface design, otherwise most people will just find it annoying i think. [21:07:20] so, could this be something a newb prototypes and then a UI person comes along and fixes up? [21:07:41] thedj: ?? [21:07:59] I think it'd be easy enough... if we do something similar already with the image pages... [21:08:09] yup [21:08:26] ok, so easy [21:08:31] next: http://bugzilla.wikimedia.org/12532 File links on image description page should be in alphanumeric (alphabetic) order [21:09:08] Could be easy, but requires one to make sure you don't do something stupid with the db query [21:09:13] Do we really need that one? How are tehy sorted at the moment? [21:09:31] basically only sort on the part that gets inlined, and you are good. [21:09:55] as a reminder: http://etherpad.wikimedia.org/BugTriage-2011-07 is the notes for this bug triage [21:10:16] Sorting alphabetically the first 200 odd entries if there happens to be 5 billion links seems confusing user interface [21:10:23] sort how? it should match the category collation order [21:10:32] bawolff: that's true. [21:10:57] since the user would assume that we're returning things alphabetically, and it'd be the first 200 random entries, not first 200 alphabetical [21:10:58] yeah, so sorting would work on cats that weren't too ginormous [21:11:15] config option? ;) [21:11:24] *hexmode wants to make ^demon scream [21:11:36] Is that section still needed on File-pages ? The global usage section was also at discussion to be deleted since it has it's own dedicated page. There is a "What links here" toolbox link. [21:11:40] I can scream everytime config option is mentioned :o [21:11:59] ok, next item? (2 min per bug) [21:12:06] <^demon> Moar config? [21:12:10] <^demon> Just what we need! [21:12:14] Sorting by category collation would require a schema change (unless we're just doing the first 200 on the php side) [21:12:44] I'd go for fixing it properly if at all [21:12:44] so, make notes on that one and lets move on [21:12:47] what if we only sort if count < inclusion limit [21:13:07] next: http://bugzilla.wikimedia.org/13862 Add a horizontal table of contents to Special:SpecialPages [21:13:17] thedj: could you put that on the etherpad? [21:13:26] so we don't lose that thought? [21:13:53] personally I think that the more standard ToC we use on articles would make more sense for that special page [21:14:10] <^demon> I tried a vertical TOC on that awhile back [21:14:18] (hi mcallan & alxndr) [21:14:24] <^demon> It looked kind of silly. [21:14:30] hello hello [21:14:34] Krinkle: r91466 and r91469 on trunk are still marked new. [21:14:41] <^demon> I liked the horizontal TOC, but Brion reverted because I reused #filetoc. [21:14:54] pdhanda: ok, checking now [21:15:00] !r r91466 [21:15:00] --elephant-- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/r91466 [21:15:01] !r r91469 [21:15:01] --elephant-- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/r91469 [21:15:09] oh brion !!! [21:15:09] their mine [21:15:14] they're* [21:15:21] i see no point in the special page toc [21:15:41] =1 [21:15:42] +1 [21:15:45] *AaronSchulz can't say he's sold either [21:15:46] i can't find stuff there anyways without some control-f'ing and trial-and-error [21:15:59] ^demon: so if you didn't reuse #filetoc it would've been ok? [21:16:08] <^demon> Probably :p [21:16:11] ok, [21:16:27] hexmode, oy [21:16:47] moving on ... let a newb implement it and show us how they're chops [21:16:54] Perhaps create a horizontaltoc class ? (like there is .toccolours) and replace CSS rules for #filetoc with .horizontal-toc [21:17:04] Which is re-usable without duplication [21:17:05] brion: did I use your name in vain? ;) [21:17:15] i dunno, you got a q for me? [21:17:19] oh, I shoudn't give the answer ofcourse :P [21:17:32] Krinkle: I think it's ok to put a *hint* in the bug comments [21:17:38] can someone ok those? [21:17:45] next: http://bugzilla.wikimedia.org/20781 Move 'mainpagetext' message to installer's .i18n file once it exists [21:17:50] Any CSS hamsters here ? [21:17:51] <^demon> brion: We were just commenting on one of your evil moments of reverting me ;-) [21:17:53] Krinkle: paulproteus says "I try to provide hints to the solution on the bug." [21:18:12] (keeping to ~2min) [21:18:28] I think Lcawte put a comment on 20701, right? [21:18:39] uhh, which one was that? [21:18:52] !bug 20701 [21:18:52] --elephant-- https://bugzilla.wikimedia.org/show_bug.cgi?id=20701 [21:18:53] I left etherpad comments that it was tagged etc [21:19:08] hexmode: easy. but needs someone who is a tad familiar with installer perhaps. [21:19:28] This bug looks easy when we decide what we want to do with the message... there are various ideas on that bug report [21:19:31] or who WANTS to be familiar? ^demon ? [21:19:41] *paulproteus waves [21:19:41] Krinkle: let me grab neilk [21:19:53] *hexmode waves [21:20:04] neilk_: even [21:20:15] !r r91466 [21:20:15] --elephant-- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/r91466 [21:20:30] and [21:20:32] !r r91469 [21:20:32] --elephant-- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/r91469 [21:20:39] are you signalling that you want to take on https://bugzilla.wikimedia.org/show_bug.cgi?id=20701, paulproteus? [21:20:40] <^demon> hexmode: Moving that message is totally unimportant. [21:20:41] neilk_: (see also comments below) [21:20:49] <^demon> I'll do it....eventually. [21:21:22] hexmode: No, just saying hello. I'm interested in the categorization of bitesize bugs and how projects do it; I contribute to openhatch.org, which aims to index them and help newcomers find projects to work on. [21:21:38] ^demon: is it easy enough that someone else could, though? in which case, use it as a training wheels thing? [21:21:39] Krinkle: that 12em one seems dubious, but you're aware of why, so I'll okay it [21:21:55] ^demon: yeah, so this *is* an "easy" triage. not so important to say if these things should happen *now* as saying someone could get it done as a good starting point [21:21:56] Krinkle: r91466 [21:22:03] <^demon> sumanah: It's a copy+paste job :) [21:22:08] ok, so, easy! next. [21:22:10] sounds easy [21:22:24] neilk_: it's the lesser evil until Brandon does a redesign that does take all these new features into account from the start. [21:22:28] ^demon: is today "I will not respond to any question with either a yes or a no" day? [21:22:33] next: http://bugzilla.wikimedia.org/23086 [extensions] AbuseFilter config diff date and time should use user preference instead of UTC [21:22:44] <^demon> sumanah: Yes ;-) [21:23:08] don't we have a date/time tracking bug [21:23:10] bug 23086 has screenshots [21:23:13] (yes) [21:23:26] b/c there are 50 diff ways MW displays time [21:23:28] hexmode: yes, but I removed it since it was more of a timezone thing rather than format, and it's in an extension. [21:23:32] wait, redesign of what? [21:23:36] Perhaps re-add it though [21:23:42] jorm: ArticleFeedback [21:23:45] oh. [21:23:46] yeah. [21:23:55] well, we'll need someone to say "spend time on this" [21:24:11] pdhanda: I marked them both OK [21:24:13] jorm: nothing major but just minor changes to take all these ideas into account, basically new elements have been thrown into your original design [21:24:16] changing time display in that extension, easy? [21:24:21] i'm fairly certain i could whip up a design v3 in a day. [21:24:28] thanks neilk_ [21:24:40] hexmode: I'd say very easy, many examples in the code base. [21:25:09] I love how people on Etherpad are arguing over twn :P [21:25:11] next: http://bugzilla.wikimedia.org/24159 Remove uses of the error suppression operator [21:25:25] Lcawte: etherpad is fun [21:25:45] <^demon> hexmode: 24159 is a case by case basis. [21:25:46] ooh that one looks easy, easy [21:25:58] just grep the code! [21:26:00] <^demon> Some of them are wrapping things in wfSuppressWarnings() and such [21:26:04] even sed it! [21:26:06] ;) [21:26:14] <^demon> Ha, @ is incredibly difficult to grep for. Use the token :) [21:26:32] <^demon> That's why our scripts detect it [21:26:55] <^demon> I'll update the list. [21:26:56] but that is more of a tracking bug, a good place to start looking for code hyjinx problems [21:27:40] next: http://bugzilla.wikimedia.org/25839 Add class for block ending time element [21:27:51] (another time bug?!?!) [21:28:26] Krinkle: updated on test but css and js changes need to be synced before one can see then on test.wp [21:28:36] Looks like that bug is requesting to implement a solution, rather than fixing a bug. [21:28:40] hmm, I thought we did that already. maybe that's only for {{#dateformat [21:28:52] hexmode: maybe poke spqrobin as it seems to be rtl-ltr issue? [21:28:53] this is for inlined dates. [21:28:58] gonna rename [21:29:17] Nikerabbit: yeah, SPQRobin is the rtl guru for now ;) [21:29:29] Krinkle: going to sync and then someone can verify [21:29:34] not sure if this is easy [21:29:44] bug rename: Block end timestamp should use the right direction in logs [21:29:48] and the span can contain both an exact date and a description of the date "1 day" vs. "UTC formatted time" [21:30:16] do we have datetranslation like Huji requests ? [21:30:35] don't think so, but... maybe [21:30:39] it is possible to implement it with some ugly hackery [21:30:43] see LanguageFi.php [21:30:45] brion might know [21:30:58] but that's not really a solution that scales [21:31:04] hiwiki used to have localized timestamps on talk pages [21:31:08] we should just limit the allowed values into something that can be translated easily [21:31:32] but that goes beyond that bug imho [21:31:40] or we should just output a utc date differently from a textual date. [21:31:48] seperate span [21:31:57] ok, but we're at half time, and have to move [21:32:05] easy or not? [21:32:14] the bug itself is easy to fix, just add a direction mark [21:32:16] ugly implementation is easy :D [21:32:25] next: http://bugzilla.wikimedia.org/25909 Add a drop-down list for the tags in RecentChanges and NewPages [21:32:36] SPQRobin: Oh nice, direction marks, forgot those. [21:32:42] hexmode: i think a good solution requires more thought than 'easy' will probably grant it. [21:32:47] what might i know about [21:32:53] (i'm in middle of tweaking js parsing stuff) [21:33:20] do we have date/time translation ? [21:33:27] to output a date in arabic for instance ? [21:33:35] thedj could you put that comment in the bug "good solution..." [21:33:36] I think so [21:33:43] Language->formatDate or something [21:34:09] yes, have to have something since we took away translation to dev. digits on hiwiki [21:34:32] +1 on the common suggestions idea [21:34:41] (for the drop-down) [21:34:42] anyway: http://bugzilla.wikimedia.org/25909 Add a drop-down list for the tags in RecentChanges and NewPages [21:34:54] ah, ty AaronSchulz ! [21:34:54] 25909: Mostly a usability problem. A free text input for a (generally limited) number of good values makes more sense in being autocompleted or a dropdown. Small chance users would know it right away [21:35:05] Krinkle: easy? not? [21:35:11] Krinkle: i synced but I'm not seeing the changes yet on en [21:35:12] thedj, in what context? you can run date/times through any language object you like [21:35:23] sumanah: dropdown: easy, autosuggest: easy ???if there is an api- [21:35:40] most dates in ui are formatted for the selected ui language [21:35:41] k, so separate bug for the api? [21:35:48] I doubt there is an api there [21:35:48] to clarify: it is either a dropdown or autosuggest, not both. [21:35:53] however those that get inserted into page text or comments will get hardcoded [21:36:01] API to get tags ? lemme check [21:36:09] usually those are stored formatted for the content language, using either UTC or the default timezone for th esite [21:36:14] brion: block time [21:36:24] in block logs [21:36:28] not a suggest one [21:36:29] Krinkle: or one or another depending on how many there are? [21:36:30] these should be few, mainly: 1) signatures and 2) block expiry times in logs [21:36:44] since they're stored as text, not as timestamps there [21:36:49] apiquerytags [21:36:50] there's a bugzilla entry recommending retooling that [21:36:57] 2) block expiry is PITA since it can be basically anything [21:37:24] yay [21:37:25] http://en.wikipedia.org/w/api.php?action=query&list=tags&tgprop=displayname [21:37:28] query list=tags [21:37:32] I'm gonna have fun trying to read these logs tomorrow ;) [21:37:52] I see they have hit_counts [21:37:54] AaronSchulz: Ah, beat me :) Missed your message. [21:38:03] so easy easy [21:38:12] maybe one could query the top hit ones, and then suggest on that list based [21:38:15] on that list [21:38:18] ok, sounds like we have enough information re * http://bugzilla.wikimedia.org/25909 Add a drop-down list for the tags in RecentChanges and NewPages ? [21:38:35] next: http://bugzilla.wikimedia.org/26470 Add toggle for checkered or transparent image background on file description pages [21:38:44] sumanah: I think so, yeah [21:39:10] For that, I like the idea of having a toggle on the image page to toggle the background [21:39:11] who has yellowish color? :o [21:39:19] hexmode: as controversial as ever. some like it, some dont'. [21:39:27] :) [21:39:35] trial by fire for the newbie? [21:39:37] hexmode: I am going to go through the Etherpad for the bugs we have already done and mark them as "easy" or "not easy" based on skimming what people say about it -- feel free to change & update if my conclusion is wrong [21:40:06] sumanah: tyvm!! [21:40:33] hexmode: personally i think it's not really needed, most people don't care that much about transparency, and commons en en.wp have it anyways. [21:40:44] thedj: why would it be controversial to have a toggle? [21:40:51] a toggle for it seems 'overdone' in my perspective [21:40:57] set to what it is now by default [21:41:07] :o [21:41:13] can it be done with a gadget? [21:41:19] of course, it's css [21:41:21] heh [21:41:22] Nikerabbit: Yes, a one or two liner [21:41:30] the lines are in the bug comments [21:41:41] oo! a newbie gadet! [21:41:42] so what we need instead is a awesome gadget distributor platform [21:41:57] ok, easy. next? [21:42:22] skipping next which is worksforme [21:42:29] on : http://bugzilla.wikimedia.org/27501 List categories from foreign file repositories on the File description page [21:43:01] Controversial: Readers don't have to care about transparency (technology) and dont want to see checkboxes in most cases, the image would look broken. But, if transparency must be indicated (needs usecase) a way to see it would be helpful. Given solutions in the bug: Either on hover (one liner CSS fix), or via a button (mini js gadget) [21:43:10] quoting Lcawte: "Hard. Need to rewrite the way the description page is fetched from the foreign repo. Can be done via the API." [21:43:16] consensus is not easy [21:43:24] moving on: http://bugzilla.wikimedia.org/27545 Extension:reCAPTCHA has badly worded message [21:43:42] Krinkle: hover is nice idea there actually. [21:44:08] badly worded message should be easy fix, right? [21:44:14] *sumanah marks as EASY [21:44:17] Lcawte: did you look at that one? [21:44:26] That patch is borked [21:44:37] can we just ask the reporter/patch-writer to resubmit? [21:44:43] yes [21:44:53] make a note of it please [21:44:54] ? [21:44:56] next: http://bugzilla.wikimedia.org/28162 Installer does not respect initial DBport declaration [21:45:05] done [21:45:06] krinkle, neilk, pdhanda: many thanks for getting aft fixes out! [21:45:16] to production [21:45:45] thedj: Thanks, I use :hover on most of my private wikis (only in though) [21:45:53] alxndr or any other new developers here interested in MediaWiki -- do any of you run postgres? [21:45:58] next one is related to above: http://bugzilla.wikimedia.org/28173 Postgres defaults to a unix socket - mention in install? [21:46:05] nope [21:46:32] heh [21:46:47] pg = "not easy" ?? [21:47:08] hexmode: i think that is safe to say :D [21:47:16]