[16:53:47] question about MediaWiki + hiphop: At Wikimania, Tim mentioned that to develop for hiphop you need to have only one class per file. Since then, however, I've been told that isn't the case. Did I misunderstand what Tim was saying? [16:54:23] Maybe it was the case in older versions [16:54:37] Though, one class per file isn't a bad practise to be in.. [16:57:31] Well, I changed some of my code to be one class per file, but I still have a few files that include multiple exception classes. Is it OK to leave these how they are? [16:58:23] Pass [16:58:27] ^demon might know a bit more [16:58:55] <^demon> *as far as I know* [16:58:59] <^demon> That isn't a requirement. [16:59:18] <^demon> I would find it odd for it to be one, I feel like MediaWiki wouldn't have worked last time I compiled it. [17:00:58] I'll leave it until I hear otherwise then :) [17:01:10] <^demon> It certainly can't hurt to have them in their own file [17:01:16] *^demon needs to get hiphop running again [17:02:35] *jorm wanna get latest moodbar version deployed. [17:11:54] I still need to get the rtl fixes for WikiLove deployed [17:12:14] have they been reviewed? [17:12:26] nope [17:13:10] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93955 [17:14:16] right. i can't review them, or i would. [17:14:49] I wonder who's good for rtl-issue reviews [17:15:30] TrevorParscal perhaps :) [17:20:18] yes. possibly krinkle? [17:23:20] rtl issues? [17:23:28] sqrobin has been doing css stuff [17:23:57] i think [17:24:33] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/author/robin [17:27:15] kaldari, are you doing some @noflip stuff? [17:27:51] rtl is automatic with resourceloader [17:32:06] there's issues with button edges. [17:32:12] check out wikilove on arabic wikipedia. [17:51:23] jorm, yeah, easily solved [17:51:47] just add noflip comments in a couple places [17:51:59] kaldari, you know about noflip comments? [17:52:10] I did [17:52:36] the main thing I actually had to change was removing the words "left" and "right" from the css class names [17:52:56] since that was causing the endcaps of the buttons to get flipped [17:54:00] TrevorParscal: it's fixed now in http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93955, just need to get it reviewed [17:56:16] I think changing class names is wrong you should be using noflip on those rules instead [17:56:21] be explicit [17:57:46] cssjanus flips things unless you tell it not to, you should tell it not to in the code in an obvious way [17:59:53] we should probably have more cssjanus documentation on mwo [18:01:10] hexmode: is the bug triage meeting still happening at 4pm PDT/7pm EDT? [18:09:02] robla: I was planning on it, yes [18:10:26] hexmode: who all have you asked to be there? [18:10:55] no one yet... [18:10:57] robla: rev report was taking forever, but looks like it just started magically working [18:11:33] We could just run it on the cluster [18:11:36] if TS is being crappy [18:14:01] robla: I pulled your changes but don't get the new numbers [18:14:12] *hexmode double checks [18:16:48] hexmode: check that you're using this version: https://gitorious.org/mwcrstats/mwcrstats/blobs/03026a8f01383127707ea004574abb5171591a81/bin/tagreport.py [18:22:05] *hexmode greps for "Total revisions marked fixme" [18:22:07] yep [18:22:14] but now I'm re-running [18:22:24] and its back to taking forever :P [18:26:34] <^demon> hexmode: Total revisions fixme'd is easy and you can do it via the UI [18:26:50] <^demon> http://www.mediawiki.org/wiki/Special:Code/MediaWiki/status/fixme [18:26:53] <^demon> 117. [18:27:14] yeah, I'm thinking of re-writing robla's revision report to use the API [18:28:19] <^demon> We should add it to the built-in repo stats. [18:28:26] <^demon> Rather than doing TS stuff over the API [18:30:54] ^demon: (and others) how do you generally do CodeReview dev work? Do you pull down a db dump and populate your dev instance that way, do you replicate the db via our svn, or do you only deal with small local svn test repos? [18:31:22] <^demon> You can give the http url for our SVN, and it will do the import. [18:31:44] ^ [18:31:58] <^demon> Takes a little bit to do the full import, but that's why we have a CLI tool for that :) [18:32:22] <^demon> It's hashar! [18:32:38] hey :-) [18:34:11] Reedy: can you make triage in 4.5 hr? if not... I need to ask you about a couple of 1.18 blockers [18:34:18] Anyone seen Alolita ? [18:34:23] Errm [18:34:25] Midnight [18:34:31] I'll likely be about [18:34:33] nickserv says last seen 40+ weeks ago??? ? [18:34:37] haha [18:34:42] heh [18:34:44] :) [18:34:47] she probably never logs in ? [18:34:48] I just got an e-mail from Alolita [18:34:50] So she's working [18:34:56] Yeah [18:35:07] She is on IRC somewhat regularly but I guess you're right that she never identifies [18:49:10] she logs as alolitas, iirc. [18:51:36] RoanKattouw: This is probably too late for you (1am?) but look over this before you go to bed, please? http://etherpad.wikimedia.org/BugTriage-2011-08 [18:51:37] that's not registered though [18:51:49] hexmode: It's 9pm [18:51:56] I am not in India, you know ;) [18:52:05] Krinkle: could you look over that etherpad, too [18:52:13] I'll add more in a bit [18:52:14] I'll look at it in a minute [18:52:29] He was meaning it'll be 1am when it occurs [18:52:39] Ooh [18:52:43] Yeah that sounsd likely [18:52:50] RoanKattouw: yes, but what Reedy says ;) [18:52:50] Yup, 1am [18:53:12] But it's the Australia edition, so that's expected [18:53:42] hexmode: Alright, I'll take a look as soon as I get home. [18:54:15] Krinkle: :) [19:00:40] brion is out today? [19:00:50] I believe he's still in Israel [19:00:56] I have the list somewhere, let me check [19:02:39] Hm.. I would expect Roan to know that from memory ;-) [19:02:43] Well [19:02:45] My memory was right [19:03:00] ...almost [19:03:07] I thought Brion would fly out on the 12th [19:03:12] It's the 11th [19:03:40] But you didn't say that, you said he was still in Israel. [19:03:47] Which is true! [19:03:52] Yeah [19:04:03] hexmode: So based on his arrival time, I don't expect him to be back until Monday [19:04:30] ah, I was just looking at the shared calendar [19:04:37] nothing on it. :P [19:04:49] But he's allowed to take at least one in lieu / recovery day [19:05:45] Yeah Brion isn't on it, but RobH is [19:05:51] And they're traveling together [19:06:10] They're even on the same flights from Israel to the East Coast [19:09:34] time travel. [19:09:41] it's the 12th in israel, i believe. [19:10:00] or, will be in about an hour and a half. [19:10:31] Yes [19:10:33] Err, what? [19:10:38] Ehm [19:10:40] No [19:10:42] It's still the 10th [19:10:45] It'll be the 11th in two hours [19:10:49] Right. [19:11:04] I guess the reason Ryan said 12th is because that's the day he gets back [19:11:06] wow. i somehow forgot what day it was. [19:11:13] yes; it's a 24+ hour travel cycle. [19:11:15] And their flight is only very barely on the 11th anyway, it leaves close to midnight [19:11:25] 12+ to philly; 5+ to sfo. [19:11:39] but the layovers and cab times increase it. [19:11:49] my flight left at 11:55 pm. [19:11:54] Yeah they're on that one too [19:11:56] TLV-PHL [19:12:07] yeah. so it's a 27 hour travel time. [19:12:14] assuming nothing goes wrong. [19:12:17] You should have had 17h airport to airport on your way in [19:12:25] doesn't work that way. [19:12:31] 2 hour layover in philly, for one. [19:12:48] Or wait [19:12:52] plus it's 5 hours from departure to tel aviv. 3 hours wait, plus 2 hour drive, or thereabouts. [19:12:53] I had 17h, you'll have had more [19:12:56] Suer [19:13:07] It's just that those are constant factors, they're the same for everyone [19:13:18] i just know that we landed 27 hours after we departed. [19:13:21] err, from the hotel. [19:13:27] So instead of estimating them, you can also drop them and compare how long it takes between take-off from TLV and landing at SFO [19:13:37] though, they are coming from jerusalem, which is shorter than haifa. [19:13:58] Let's see, 11:55pm - 10:55am, that's 11 hours on the clock, 21 hours real time [19:14:09] Damn that's pretty bad [19:14:10] that sounds right. [19:14:15] yeah, it was brutal. [19:14:21] i don't remember it being that bad on the way out, though. [19:14:26] About the same as my trip back from Buenos Aires [19:14:49] 13h flight to MAD (which was an hour late, so 14h on the plane), 5h layover (became 4 due to the delay), 2.5h to AMS [19:15:18] 20.5h sounds about right, I recall arriving around the same time that I departed, and there's a 4h time difference [19:15:34] sorry about your luggage, btw. [19:15:37] There was discussion on foundation-l about a "like" feature for Commons, similar to Flickr's. [19:15:39] It's OK, it's back now [19:15:46] i think that's a bad idea. [19:15:50] It took them about 24h to find it [19:15:53] Really? [19:16:00] I thought you, of all people, would like it. [19:16:07] yeah, it's a bad idea. [19:16:11] You're worried everyone will like Nazi pictures or what? [19:16:15] better to use article feedback tool. [19:16:18] Then they put it on the late flight from IST to AMS, so it arrived at like 10pm and they couldn't call me or deliver it until about 4pm the next day [19:16:21] For images? [19:16:23] and change the rating types. [19:16:28] So all in all, it took them 47h to reunite me with my suitcase [19:16:31] absolutely. it's pretty much custom built for that. [19:16:33] Hmm, maybe. [19:16:53] change teh values to things like "composition", "subject matter", "aesthetic value", etc. [19:16:58] Yeah. [19:17:15] Speaking of AFT, is there some option to kill it per-user? [19:17:15] now, i'm up for a "like" type feature to be applied to *revisions*. but not "like". more like "Productive" [19:17:22] you can hide it per user. [19:17:29] I should go find that. [19:18:47] It's in your preferences [19:18:58] Prefs --> Appearance [19:19:04] I guessed Editing first. [19:19:35] I always forget which pref is where [19:19:40] Even if I've implemented them [19:19:47] Yeah, they're a bit goofy. [19:20:08] Does AFT specifically exclude the main page? [19:20:24] how about tfinc? Anyone seen him? preilly? [19:21:21] Myra: There's a blacklist category [19:21:33] I forget its name, Erik made me add it while I was doing three other things [19:21:34] Ah, interesting. [19:21:49] But it'll be in the config somewhere, and of course the Main Page will be in it [19:22:02] [[Category:Article Feedback Blacklist| ]] [19:22:14] Category:Article Feedback Blacklist [19:22:36] Sounds about right [19:22:51] 205,000 articles in it? [19:22:53] wtf [19:22:58] does anybody know if it is possible to use $wgRequest->response()->setcookie()??? and have it set the cookie in the base domain? e.g., set it to wikipedia.org vs. en.wikipedia.org [19:23:03] RoanKattouw: ^^^ [19:23:19] I have no idea [19:23:23] I suggest reading the source [19:23:25] Ah, disambiguation pages got excluded. [19:23:36] Or asking ^demon , who implemented the cookie jar IIRC [19:23:46] Presumably CentralAuth has to do it, somewhat. [19:23:49] <^demon> I had nothing to do with cookie jar. [19:23:51] <^demon> That was hexmode [19:24:32] hmm, was category suggestion for uploadwizard rewritten in trunk ? [19:24:36] Good point, CA must be setting *.foo.org cookies [19:24:45] ^demon: um, not for response, I don't think [19:24:56] deployed seems to be useing allpages, and trunk seems to use allcategories... [19:24:59] I'm not sure if CA sets a cookie or there's some webserver domain image magic that does it. [19:25:08] But that's where I'd look first. [19:25:21] <^demon> preilly: To answer your question, no it's not. [19:25:27] <^demon> I was looking at changing that last night [19:28:19] hmm, so CA uses the following: setcookie( $wgCentralAuthCookiePrefix.'Token', $this->getAuthToken(), $exp, '/', $wgCentralAuthCookieDomain, $wgCookieSecure ); [19:28:55] <^demon> I've got a patch. [19:29:42] ^demon: a patch to the setcookie method? [19:29:46] <^demon> http://p.defau.lt/?BfjOhuXfInRQHukJNmFIAA [19:29:53] <^demon> Allows setting prefix and domain. [19:30:43] "var title = page.title.split( ':', 2 )[1];" [19:30:47] head desk... [19:30:50] preilly: have you found anywhere that sells Purple Drank yet? [19:30:51] <^demon> The CA example would become something like ->response()->setCookie( 'Token', $this->getAuthToken(), $exp, '', $wgCentralAuthCookieDomain ) [19:31:04] jorm: NO [19:31:23] *preilly dies a little inside each passing day without my purple drank [19:31:23] WELL GET ON IT HOSS [19:32:06] thedj: Where do you see that? [19:32:14] mw.Title is in trunk now, so it should just use that instead [19:32:18] preilly: here is the quick patch : http://noc.wikimedia.org/~hashar/patches/cookie_domain_override.patch [19:32:30] uploadwizard deployed code. category suggestions. [19:32:53] https://bugzilla.wikimedia.org/show_bug.cgi?id=30300 [19:33:11] and now i'm really gonna get food. 21:30 already... [19:34:30] preilly: is tfinc in the office? [19:34:45] hexmode: yes, he is [19:36:06] hexmode: I just told him that you are looking for him [19:36:14] ty [19:36:21] preilly: I have send my patch on a bug https://bugzilla.wikimedia.org/show_bug.cgi?id=30313 [19:36:33] preilly: feel free to enhance it and test it :b [19:36:39] hashar: okay [19:36:44] hashar: thanks, again. [19:36:55] preilly: I am not sure it works. You will have to test it out [19:37:22] hashar: okay, I'll do that if I end up using it. Thanks, again. [19:37:31] you are welcome :b [19:53:10] RoanKattouw: ^demon: I'm done updating http://etherpad.wikimedia.org/BugTriage-2011-08 -- please have a look when you get a chance [19:53:21] ^demon: will you be here at 7? [19:54:03] <^demon> I don't see much relating to me, but I can be sure. [19:54:36] ^demon: ty, you always have a good perspective :) [19:57:49] *hexmode has to step out for a bit [20:22:06] RoanKattouw: what is the status of the translate extension review? [20:22:27] *hexmode just saw your note about the babel review [20:29:38] On my list for this month [20:41:52] hexmode: I've commented on the Etherpad. It'd be nice if you could change your color to something that isn't so close to Chad's [21:11:45] AUGH JETLAG [21:11:48] killing me here [22:13:08] jorm: really? [22:42:24] This bug triage managed on McD's wifi :) [22:43:19] <^demon> Today's triage is brought to you by McDonalds. [22:43:36] <^demon> Enjoy a refreshing iced coffee today. [22:43:40] What letter? And What number? [22:43:54] <^demon> The letter R. [22:44:03] <^demon> And the number 0.01 [22:51:28] For some reason, whenever I go into town (Lancaster), my stupid phone thinks it is in Lancaster, CA so it switches to a timezone 3 hours away [22:51:30] lame [22:58:54] 2 min!!!! [23:00:26] TIME! [23:00:47] Hammer? [23:01:01] heh [23:01:05] yah [23:01:15] Reedy: ^demon: robla: starting [23:01:32] RoanKattouw: if you're still awake! [23:01:42] I really shouldn't be [23:02:12] yo [23:02:15] (brb) [23:02:15] shhh! I won't tell anyone [23:02:42] 29232 -- I shouldn't be doing it.. someone else want it? [23:02:49] etherpad link? [23:02:53] http://hexm.de/5l [23:03:27] http://etherpad.wikimedia.org/BugTriage-2011-08 # for read/write version [23:03:50] I [23:04:02] <^demon> I'm not sure I think it's that urgent. [23:04:06] <^demon> It's not a regression. [23:04:32] I've already un-assigned myself. [23:04:57] ^demon: good point. And just working around a problem in an older version [23:05:09] so lower priority [23:05:30] http://bugzilla.wikimedia.org/28613 [23:05:31] <^demon> Although it would be nice to fix. [23:05:36] <^demon> Afaict, it breaks interwiki importing. [23:05:43] <^demon> Due to the way we redirect IW urls. [23:05:50] ! [23:06:20] Is that due to the current implementation? [23:06:29] bugginess in the current impl? [23:07:22] moving on... unless someone wants to say something else [23:07:38] 28613 is close to being fixed if not fixed [23:07:49] we have multicast listeners [23:07:54] and found some problems [23:08:37] unless there are new reports, I don't think it should really bog us down... [23:08:53] yeah, seems like that one is moving along [23:09:48] ooo! [23:09:58] ^demon: here's one for you: http://bugzilla.wikimedia.org/30192 \ [23:10:04] file repo problem [23:10:22] we never delete old thumbnails [23:11:13] *^demon goes to see how much FileRepo's been butchered since the last time he banged on it [23:12:36] Reedy: while he looks at that, what can you tell us about http://bugzilla.wikimedia.org/29246 (API error 231) [23:14:01] Reedy: yt? [23:17:49] ok, so what about http://bugzilla.wikimedia.org/30086 ??? [23:18:05] I'm gathering a ton of upload stats [23:19:16] <^demon> hexmode: Your patch on 30192 is overkill methinks. [23:19:16] *hexmode thinks -commons are more active than -dev [23:19:29] <^demon> I think you'd be fine with just doing it in purgeHistory() [23:19:57] ^demon: k, could you commit an appropriate fix? [23:21:41] Reedy: Reedy: Reedy [23:21:51] ? [23:22:13] Reedy: while he looks at that, what can you tell us about [23:22:14] http://bugzilla.wikimedia.org/29246 (API error 231) [23:22:14] [23:23:41] Not quite sure it's a blocker [23:23:59] ok... since it is going on now, sure [23:24:01] but [23:24:12] do you have any insight? [23:24:22] Not really [23:24:49] :( Do you think priority is wrong? [23:25:14] I wonder how "occasionally" is occasionally [23:25:30] It's presumably been like that for pretty much ever [23:26:19] ah [23:26:22] noted [23:26:51] next: http://bugzilla.wikimedia.org/30086 -- Upload problems : Slow / timeouts [23:27:11] I still think 29246 is high priority [23:27:14] anyone have ideas on what I can do for that? Is that just an ops issue? [23:27:31] robla: could you explain why? [23:27:45] esp. if it has been that way forever [23:28:16] basically, what that's saying is that that part of the API is flaky, and Roan spells out why it's flaky [23:28:36] it's not a 1.18 blocker, since it's not a regression, but [23:29:02] higher priority [23:29:10] so I can pester people [23:29:20] *hexmode has a gnat for a mascot [23:30:09] <^demon> 30192 fixed. [23:30:10] there's just no good reason for leaving it like that. it's certainly higher priority than removing deprecated functions :-P [23:30:22] heg [23:30:50] hexmode, for 30086, "we" need to find out what's causing the slowness [23:31:09] "we" as in dev? [23:31:13] or WMF? [23:31:28] It'll probably need both ops and dev [23:31:33] Reedy: woosters was telling me that he'd asked you to document a bunch of tests that you did [23:31:51] Most of them should be on that bug already, but yeah [23:32:06] I'm currently trying to pin down *when* it became slow, probably need to get more specific info from Ops [23:32:17] he said he'd ask Mark B to look at it once that was done [23:32:49] robla: you mean tests on 30086? [23:32:51] tested a few hunches and came up blank [23:32:57] hexmode: yeah [23:33:26] k... I'm *hoping* that something will show up in the overall rate to commons [23:33:28] is there any profiling code we could add that would help debug? [23:33:32] looking at history [23:33:43] <^demon> The profiling code should already be there. [23:33:44] We could do some logging before/after writes etc [23:33:51] ^demon and RoanKattouw were working on that [23:33:53] <^demon> Roan said he was going to do a profiling group for commonswiki. [23:34:14] <^demon> But then we found out report.py doesn't support new groups automagically anyway. [23:34:50] Hmm [23:35:04] Does going to test, go directly to srv193? Or does it still do the squid bouncing? [23:35:31] what are you hoping to find with profiling? hotspots in the u/l code? [23:35:32] same reslove, so presumably it does [23:35:42] *hexmode doesn't follow [23:35:45] We've no idea where the actual issue is [23:36:37] <^demon> Right. [23:36:41] hexmode: hotspots in the system. might not be code, but it might be a particular file operation that implicates a particular system [23:36:47] <^demon> Profiling would help us eliminate a couple of places it might be. [23:37:00] exactly [23:37:16] We might need to poke some people (ie Bryan) who are more familiar with the code too [23:37:19] k, but profiling assumes it is in our system somewhere and helps find it, right? [23:37:23] <^demon> Or, we might get lucky and profiling shows us some crazy bottleneck that's blindingly obvious. [23:37:40] Bryan doesn't have much time right now [23:37:46] hexmode, and if it's not the code, we can then look at apache, squid etc outwards [23:37:53] <^demon> We don't need Bryan for FileRepo. [23:37:54] anyone else? [23:38:16] we have ^demon :) [23:38:23] <^demon> I wrote a good part of it. Russ has some newer experience since he's been doing that Swift project. Tim wrote the thing to begin with, so he's always an option. [23:38:58] Does the upload code write it to the apache temporarily, then copy it? or directly to nfs? [23:39:13] Due to the way uploading works in PHP, it'll go to /tmp first [23:39:18] <^demon> Yeah. [23:39:26] <^demon> But PHP will very quickly move it to NFS [23:39:34] <^demon> (quickly being as quick as nfs will allow) [23:39:39] indeed [23:39:44] But based on the upload speed [23:39:50] It's not NFS at fault [23:39:50] who should I follow up w/ tmw? RoanKattouw and ^demon ? [23:39:53] as it's not getting that far [23:40:04] I can put in the profiling tomorrow, I guess [23:40:10] Or maybe someone else could do it tonight [23:40:16] <^demon> Until that goes in, I won't have any new answers. [23:40:18] But.... crap it's almost 2am already, I really need to go to sleep [23:40:27] night! [23:40:29] <^demon> RoanKattouw: StartProfiler I can do, but report.py is owned by root:root :( [23:41:00] boo [23:41:03] *robla looks for binasher on other channels [23:41:11] :) [23:41:16] he's invisible [23:41:26] I'm sure that's not the canonical copy and that the canonical copy is editable [23:41:37] oh, that's right....he's out for a bit, but he'll be back in 30 min or so, I think [23:42:02] k, I'll bug you guys about this tmw [23:42:07] in the meantime: http://bugzilla.wikimedia.org/30211 -- detect conflict on move [23:42:16] looks like a race condition? [23:42:19] <^demon> That behavior's probably been like that forever. [23:42:25] <^demon> Have we ever detected move conflicts? [23:42:50] *hexmode doesn't know [23:43:13] but you shouldn't be able to move it if someone already has 30s before, right? [23:43:22] <^demon> Why not? [23:43:40] <^demon> If I move A -> B, but really wanted it to go -> C, why should I wait? [23:43:55] robla: binasher is away [23:43:56] maybe I'm not understanding [23:44:00] Plus, some anti-vandal could be very fast [23:44:08] if I move A->B [23:44:09] what are the consequences of the move conflict right now? [23:44:20] someone else shouldn't be able to move A->C [23:44:22] robla: he will be back on in a bit [23:44:46] because A is now B! [23:45:10] at least, that's how it seems to me. what am I missing? [23:45:18] *hexmode goes to look at the report again [23:45:20] ^demon: I can't even *find* report.py, where is it? [23:45:34] cgi-bin somewhere [23:45:41] <^demon> /usr/lib/cgi-bin/ ? [23:45:42] <^demon> I think [23:45:47] The cgi-bin alias in noc.conf points to /usr/local/apache2/cgi-bin which doesn't exist [23:45:51] /usr/lib/cgi-bin/report.py in () [23:46:29] <^demon> The only report.py I have is in /usr/lib/cgi-bin and then in the 'ng' subdir. [23:46:53] hrm... looks like A->B and then 2s later A->B [23:47:01] which still seems wrong [23:47:29] <^demon> Basically I opened my browser to move A->B, waited a bit too long, and you came along and moved A->B before I pressed submit. [23:47:32] <^demon> Then I pressed submit [23:47:40] so, not as bad as 30s [23:48:08] <^demon> It's very straightforward. I'm pretty sure we've just never put any race condition checks there. [23:48:10] Just check to see if someone has moved the page since you opened the form, but not very important [23:48:35] I'm just trying to figure out what sort of catastrophe we're trying to avoid [23:49:01] sounds like the only problem we have right now is that the page history is messy [23:49:12] robla: I don't think it's a catastrophe but more of a confusion preventer [23:49:29] <^demon> Yeah, nothing explodes afaict. [23:49:37] to me, it seems obvious that A->B and A->C would be bad but I guess it would only be B or C [23:49:43] not both B and C [23:49:50] *hexmode calms down [23:50:14] seems like something we should probably look at at some point, but normal-ish priority, unless I'm missing something [23:50:19] <^demon> I'm pretty sure it's a rare occurrence, if we've never had the bug reported before. I'd say just throw it in the general pile. [23:50:25] k [23:51:30] this one is ugly: http://bugzilla.wikimedia.org/30287 - [23:51:43] (skipping a few) [23:51:57] looks like two different ways of sorting the same charset [23:51:59] <^demon> I know zilch about any non-latin alphabets, unicode and all that fun stuff. [23:52:05] *^demon sits this one out [23:52:17] unicode is just as much fun as XML [23:52:20] ;) [23:53:15] sorting snafu: http://dbaspot.com/sqlserver-faq/228381-how-sort-farsi-persian-letters.html [23:53:37] who should look at this, though? [23:53:58] brion has some collation... anyone else? [23:54:29] Mark: can you drum up volunteers on list for this? [23:54:46] I guess you mean hexmode ;) [23:54:48] yes [23:54:53] will do.... [23:55:14] and with that... My battery is dying [23:55:23] I agree it's high priority, and we'll have to suck it up if no one steps forward, but let's see if we can get someone who actually understands Farsi [23:55:31] so I need to go [23:55:33] :) [23:55:38] k [23:55:43] *^demon needs to go to the drug store [23:55:45] I have been wanting an Iranian dev [23:55:49] <^demon> Nose has been sniffly all day :( [23:55:50] jorm: purple drank, purple drank [23:56:08] btw, I have to believe that if Farsi is busted, then other non-Latin langs are too, but maybe not [23:56:36] robla: lots of google hits for sorting in farsi, though [23:56:46] but yes, merits a look [23:57:06] it may just be a matter of adding a new collation via the mechanism Aryeh added [23:58:07] That'll work for categories [23:58:11] Not for everything else [23:58:45] Non-Latin languages aren't necessarily broken if the characters have a sane order in Unicode [23:59:02] Languages like German with a mix of basic Latin and extended Latin characters are broken, but they have been since 2001 [23:59:56] getting categories working might be the 80% solution, though