[02:01:56] Nikerabbit: are you still around? [02:02:22] I'm puttering around on bug 34508, and need a little help with the LogFormatter class [02:02:27] !b 34508 [02:02:27] --elephant-- https://bugzilla.wikimedia.org/show_bug.cgi?id=34508 [02:08:03] I'm trying to find the best way to get parameters. I'd like to use LogFormatter->getMessageParameters(), but it's protected [02:19:13] well...that's not what I wanted anyway [13:28:51] Nikerabbit: do you happen to know what is broken with IRC notifications ? [13:28:58] https://bugzilla.wikimedia.org/show_bug.cgi?id=34508 is not very clear :D [13:34:15] hashar: AFAIK the text output to IRC has changed in format or somethin [13:34:16] g [13:34:26] good morning :-D [13:34:44] hai [13:35:02] rob sent us a mail this morning [13:35:26] I am in #countervandalism [13:35:29] seems to be some users there [13:39:28] and timo is around :-D [13:39:38] Reedy: have a good breakfast ! [13:56:08] hashar: NO [13:56:20] and that's the reason I'm very frustated about it [13:56:38] well, more specifically I do not know what broke the bots, I do know what changed [13:56:39] I am in #countervandalism with krinkle [13:56:51] hashar: I left a note on the bug [13:57:14] looks like the logentry-* messages were changed which is not that much a big deal since the bot seems to fetch i18n messages [13:57:22] but the order of parameters did change [13:57:29] which might be confusing the bots [13:57:54] hashar: the message keys changed, the message content changed and the variables changed [13:58:05] the meaning of $1 and $2 was changed and the message-key was changed. [13:58:16] content too, but that's OK. [13:58:32] so everything changed [13:58:34] that's how the bots manage to support reporting non-English wiki log actions in English [13:58:40] and now, we need a back compatibility layer :D [13:58:55] I like Tim's idea, but it won't work for us. [13:59:08] so was my suggestion for workaround not okay? [13:59:18] Nikerabbit: Yours will work I think [13:59:31] what is wrong with Tim suggestion? [13:59:36] hashar: See bug [13:59:45] what did Tim suggest? [13:59:51] hashar: Tim's suggestion restores 1 of 3 changes and still changes the other 2 [13:59:56] the 2 that actually matter, ironically [13:59:57] see above [14:00:42] Nikerabbit: https://bugzilla.wikimedia.org/show_bug.cgi?id=34508#c20 [14:00:44] dont we [14:00:44] [14:00:50] don't we have message key aliases ? :D [14:00:56] no [14:01:03] *hashar logs a bug for nike [14:01:41] those 3 listed things must not change ideally [14:01:48] * Log action name (e.g "move") [14:01:49] * Log message edit-summary message-key (e.g. "1movedto2_redir") [14:01:49] * Which variable replacements represent what (e.g. movedTo = $2) [14:04:56] got it [14:05:02] then we have rob patches wich get me confused [14:10:21] https://bugzilla.wikimedia.org/attachment.cgi?id=10057&action=diff [14:10:27] that is the third one, my preferred one [14:10:40] deserves a hacking barnstar of some sort [14:11:42] hashar: still the same problem, see comment 21 [14:11:47] gotta go, brb in 20-30 minutes [14:15:50] hashar: I have no idea why he went that way, just overriding the text and keeping the message keys around should be enough [14:16:10] and the messages can be in that extension [14:18:52] what do you mean by overriding the text? [14:20:14] I will just triage some bugs while waiting for timo [14:22:40] hi au [14:23:12] hi sumanah [14:39:38] au: are you settling in OK? anything you need? [14:40:48] sumanah: gwicke informed me it'll take a while for contracts / odesk / etc to setup, so I'm not too worried about it [14:41:10] otherwise I'm just greening Parsoid tests whenever I got a cycle. everything's OK on that front [14:41:13] . [14:43:47] ok, au! have you already joined the parser mailing list? [14:45:14] that would be wikitext-l? [14:47:35] yes. [14:48:36] ok, subscribed now. thx for the reminder! [14:48:40] Sure! [14:48:42] Glad to help. [17:22:54] hi robla [17:23:06] Hi Nikerabbit [17:23:13] lemme finish my comment on 34508 [17:23:21] robla: I was going to ask about that [17:25:17] Nikerabbit: https://bugzilla.wikimedia.org/show_bug.cgi?id=34508#c22 [17:26:00] not sure I agree with you comments [17:26:20] Nikerabbit: which ones? :) [17:27:21] robla: having it in core, or renaming the message keys [17:27:45] I'm not dug in on the message keys [17:28:05] however, I feel stronger about having it in core right now [17:28:30] I think we can keep it reasonably well isolated [17:31:35] Nikerabbit: I'm inclined to let you have your way if you actually write it :-) [17:32:21] Reedy: you around? [17:32:43] yup [17:33:55] Reedy: have you been following bug 34508? [17:33:59] !b 34508 [17:33:59] --elephant-- https://bugzilla.wikimedia.org/show_bug.cgi?id=34508 [17:43:48] Reedy: ping [17:48:54] Sorry robla, distracted wither other stuff [17:49:12] I'm also AFK for dinner in about 10 minutes [17:49:22] I haven't been following it closely, but I've some idea of what's been going on [17:50:14] I'm worried we're not going to get this fixed by 3pm, at which point, we have to postpone the 1.19 deploy to commons, and possibly roll back on the currently deployed set [17:50:32] 5 hours [17:50:34] ish [17:50:47] which would suck, because that probably sets us back a couple of weeks on Git due to ^demon|away's vacation schedule [17:52:02] I'm thinking we just need to break this up so that everyone can take pieces [17:53:44] Nikerabbit: one of the benefits I was hoping for with using existing messages was that the messages would still be in the Messages*.php files, but they don't appear to be [17:54:24] do we need the translations? [17:55:28] I was assuming we did, but if not, then that would be another reason to create new message strings in MessagesEn.php and call it good [17:56:16] I've pretty thoroughly tested the two actions that I created such that, at least for English, they produce identical results to 1.18 [17:58:14] Reedy: ^ [18:01:29] I'll be back in 30-60 minutes or so... [18:01:43] If we decide how we actually want to proceed, I can get on with it then [18:04:22] Yeah... We output it localised, so we need localisation for wikis we deploy to.. [18:23:29] TrevorParscal_: are you working from home? [18:23:44] just until lunch [18:23:55] my wife is at the dentist being orally interrogated [18:24:01] nice [18:24:08] so....20% time [18:24:14] have you captured Roan yet? [18:24:17] you and brion today [18:24:24] brion's back? [18:24:28] sweet! [18:24:30] yup [18:24:41] Rob moen today too agaik [18:25:00] and I need to bully roan into changing his day to tuesday too (since he's on the VE team) [18:25:31] Oh, my 20% day needs to be Tuesday? [18:25:33] heh [18:25:39] I just told Rob it was gonna be Wednesday [18:25:41] But Tuesday it is then [18:25:43] robla: ---^^ [18:26:03] i can review r111710 [18:26:21] *TrevorParscal_ is an effective bully, clearly [18:26:35] RoanKattouw: robmoen and I both use tuesday [18:26:53] that way there's not a ripple effect through the week of days we can't collaborate together [18:26:59] if you do the same, that would be best [18:27:07] plus we can have front-end code review parties [18:28:06] Yeah [18:28:48] yo [18:29:47] *robla wraps up IRL conversation with brion [18:30:14] he's going to chime in quickly on bug 34508, and then code review stuff [18:31:05] in general, I think there's probably just wrangling last minute bug fixes [18:31:31] is there any undeployed blocker fix code yet? [18:32:45] chrismcmahon: could you do a test pass against the currently open Javascript blockers? [18:32:56] robla: sure [18:33:28] robla: double-checking, we're using this list? https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&resolution=---&target_milestone=1.19wmf%20deployment&known_name=1.19%20deploy%20blockers&query_based_on=1.19%20deploy%20blockers&list_id=92675 [18:34:23] chrismcmahon: yup [18:35:26] hexmode: any new blockers? [18:35:47] robla: haven't seen any [18:38:36] robla, so dumb question. has anyone suggested updating the bots to read the updated format? or are there serious issues with that? [18:39:48] Krinkle tells us that's really impractical on such short notice, since some are on compiled code that the source has been lost for [18:39:53] brion: ^ [18:40:01] ... [18:40:06] *brion stab stab stab [18:40:17] yeah, it sucks [18:40:29] *AaronSchulz likes how we are dependent on fragile outside crap [18:41:10] I proposed some time ago that we should provide libraries for parsing the irc logs on different languages [18:41:23] well, we should have xmpp recentchanges [18:41:23] or have a proper IRC API-like format [18:41:50] *AaronSchulz hugs accidental complexity [18:42:18] that's what is replied every time [18:42:26] robla, is patch #3 complete and standalone or does it need other bits? [18:42:29] I remember duesentrieb asking for xmpp a long long time ago [18:42:46] Platonides, yeah he did some experiments but it never got fully finished [18:42:50] I believe patch #3 is complete and standalone [18:43:06] (unless I missed a file) [18:43:31] i like patch 3, it's pretty direct [18:43:58] throw in an alternate function that's back-compat and force it to use the right BC messages [18:45:19] *Nikerabbit still prefers another extension [18:45:53] robla: just did a quick tour to verify no new blockers and didn't see any :) [18:46:03] Nikerabbit: would be nice eventually [18:46:20] AaronSchulz: eventually? [18:46:32] this is one-off thingie, nobody is going to change it afterwards [18:47:13] https://bugzilla.wikimedia.org/show_bug.cgi?id=34508#c23 ? [18:49:05] brion: the getIRCActionText() change looks suspect [18:49:34] might be safer to build a separate $rc var using a second RecentChange::newLogEntry call [18:49:43] one would have plaintext, the other irctext [18:50:26] AaronSchulz: is that text used for anything else? [18:50:37] according to the comment probably I added, it isn't [18:52:05] Nikerabbit: probably checkuser [18:52:39] not any other ext we care about though, but still [18:52:58] wassup [18:53:39] Nikerabbit: oh, wait, I changed that ;) [18:53:44] the change to getMessageKey is just not going to work btw, the key names must be indentical [18:53:54] to what they were in 1.18 [18:57:34] Nikerabbit: why is that? [18:57:37] hexmode: I'm unable to repro https://bugzilla.wikimedia.org/show_bug.cgi?id=34542 (see comments). is it legit to close that one? [18:57:49] robla: according to krinkle, that is what the bots rely on [18:58:08] otherwise we don't need the messages at all, we could just hardcode the texts [18:58:10] the key name? [18:58:17] yes [18:58:28] how can they possibly rely on the key name? [18:58:55] robla: they download the message from the key and use that to construct regular expressions [18:59:06] ask Krinkle for details [18:59:09] ohhhhhhhh [18:59:31] gross [19:00:08] brion: ^ even more to get stabby about [19:01:22] that's terrible [19:02:36] i'm not sure https://bugzilla.wikimedia.org/show_bug.cgi?id=34504 is really a new regression, but a general sort of issue with updates [19:04:43] Yeah that's a general issue, you're completely right [19:05:00] does the 'jump to' bit still need fixing? [19:05:07] that could be done by returning a bit to the css, i guess [19:05:17] or ignoring it this time [19:06:48] Yes, it still needs fixing [19:06:55] I suggested adding a b/c rule in the CSS [19:08:34] team meeting? [19:08:42] http://etherpad.wikimedia.org/FeaturesTeam2012-W08 [19:08:54] hello TrevorParscal [19:09:10] hi [19:09:42] played a bit with coffeescript on the weekend [19:09:56] Audrey likes it a lot [19:09:59] ah, yes??? the forbidden JavaScript fruit [19:10:01] Oh that [19:10:28] looks quite nice [19:10:47] I get that it's got advantages and coolness, but it's yet another language for people to learn which makes it a pita for an open source project seeking to attract contributors... [19:11:34] yeah, I am also not about to convert to coffescript [19:12:00] the generated javascript looks surprisingly readable though [19:12:01] coffeescript: javascript for people who like arrows [19:12:31] the arrow is a bit of a haskellish touch [19:12:36] as a computer guy rather than a math guy, i actually don't like their shortcut syntax for lambdas [19:12:39] surprisingly, it's the "not having to think about trailing commas" that won me over at first [19:12:47] heh [19:13:59] Nikerabbit: what was the bug with log performer and rev author being mixed up? [19:14:11] AaronSchulz: need the number? [19:14:26] If it has one, I cant remember [19:14:47] https://bugzilla.wikimedia.org/34495 [19:16:50] Trevor: hi [19:16:54] team meeting today? [19:17:14] looks like most folks are still out of sync [19:18:28] I had a conversation with Ian Hickson last night about multiple itemtypes in microdata- he does not seem to like the idea very much [19:18:58] *TrevorParscal reminds people of http://etherpad.wikimedia.org/FeaturesTeam2012-W08 [19:19:12] not that important right now, but RDFa might be something to keep in mind as an alternative [19:19:52] au, feel free to add a section for yourself if you like [19:20:01] ok [19:23:30] RoanKattouw: I found a HTTPS exception you didn't get into https everywhere :P [19:23:37] bug-attachment.wikimedia.org [19:23:57] so, let's do 3 line updates [19:24:04] gwicke: could you start? [19:24:10] ok [19:24:31] last week progress on the parser front was not that fast, but steady [19:24:34] Reedy: why is it on seperate non-Bugzilla domain? [19:24:44] vvv: security [19:24:56] some clean-up and investigation of potential bigger problems for template expansion and tokenization [19:25:02] When the allow_attachment_display parameter is on, it is possible for a malicious attachment to steal your cookies or perform an attack on Bugzilla using your credentials. [19:25:02] If you would like additional security on attachments to avoid this, set this parameter to an alternate URL for your Bugzilla that is not the same as urlbase or sslbase. That is, a different domain name that resolves to this exact same Bugzilla installation. [19:25:02] Note that if you have set the cookiedomain parameter, you should set attachment_base to use a domain that would not be matched by cookiedomain. [19:25:02] For added security, you can insert %bugid% into the URL, which will be replaced with the ID of the current bug that the attachment is on, when you access an attachment. This will limit attachments to accessing only other attachments on the same bug. Remember, though, that all those possible domain names (such as 1234.your.domain.com) must point to this same Bugzilla instance. [19:25:04] You can upload there whatever you want? [19:25:04] and helping Audrey to get started [19:25:06] Reedy: could you give me a call (see PM) [19:25:33] this week I hope to get images and some microdata done [19:25:40] and/or RDFa.. [19:25:48] *gwicke passes the mic [19:25:49] ok, me now... [19:26:14] I got floating stuff working in a creative way, which was sweet victory [19:26:42] We met with the CE team and shared stories of pain and misery - came up with some ideas, mostly for IME [19:26:44] robla: sure, give me a minute or 2 [19:26:53] RoanKattouw, https://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki/112034 [19:27:07] for the jump styles [19:27:14] and we got Roan here in SF to stay, so I've been readying data model changes [19:27:21] (legend: CE = contenteditable) [19:27:31] au? [19:27:53] hi. took some time to setup, many thanks to gwicke for orientation [19:28:25] the "git svn clone" workflow seems to work well, though it'll have to re-clone-again after svn=>git I guess... [19:28:51] I'm working only 4hr/wk for the medium term, so next week will still be mostly about picking up low-hanging fruits in parsertest greening. [19:29:01] I promise I won't eat all the low-hanging fruits at once! :) [19:29:02] . [19:29:49] au: don't worry- there are still plenty in the tokenizer etc.. [19:30:01] excellent :) [19:31:14] Hi everyone. [19:31:26] Last week, started over with ime implementation due to Firefox problems. [19:31:41] This week, I'll be working more on a new ime / general input prototype. [19:32:44] Currently I have a working base, though need to work through some strange bugs. Hopefully I'll have something solid by end of week [19:33:05] That's really all for me. *passes mic* [19:33:15] (mic falls to the ground) [19:33:19] katie? [19:33:23] Yes! [19:33:26] Hello. [19:33:58] *TrevorParscal admires katie's nick [19:33:59] There's not a whole lot for me to tell. A surprising amount of my time has been dumped into the hiring process for the fr-tech openings. [19:34:15] yes, those french people... [19:34:21] haha [19:34:59] ...seriously, though, interviewing people and reviewing code samples and looking at resumes and doing phone screenings... [19:35:15] I spent about a day last week *not* doing that. [19:35:24] That went to code review for Jeremy. [19:36:02] ...and speaking of Jeremy: He's on vacation this week, which is why he's not here. [19:36:53] and Roan is wandering around the office chatting people up [19:36:54] so... [19:37:04] any i18n people around? [19:37:27] or editor engagement people? [19:37:42] Where is everybody, anyway? [19:37:48] I can report for Roan... [19:37:50] TrevorParscal: the former were just in an office hour [19:38:16] I didn't do much, just moved to another continent and cause mass hysteria with $wgResourceLoaderExperimentalAsyncLoading [19:38:31] Thanks roan [19:38:37] *K4-713 giggles [19:38:59] ok, thanks for participating! [19:39:08] don't forget, IT CROWD LUNCH, TODAY! [19:39:15] 6th floor collab space [19:39:18] A reminder to Features folks [19:39:24] https://blog.wikimedia.org/2012/02/15/wikimedia-engineering-moving-from-subversion-to-git/ [19:39:32] read it - check out that March date [19:39:36] TrevorParscal: sounds like fun [19:39:45] "migrate to Git for our source code repositories, starting on March 3rd." [19:40:14] gwicke: you can follow along - SE01E02 today [19:40:25] also, there are 127 patches awaiting review against MediaWiki core, and 58 against extensions WMF deploys [19:40:38] in case you have a 20% day coming up [19:41:05] *gwicke throws a parse error on SE01E02 [19:42:46] *gwicke re-parsed after googling [19:42:55] http://en.wikipedia.org/wiki/List_of_The_IT_Crowd_episodes#ep2 [19:45:50] *S01E02 [20:07:48] https://bugzilla.wikimedia.org/show_bug.cgi?id=34542 -- Closing b/c you can't repro is fine -- though sometimes I've done that and it was a case of me not understanding what was supposed to show -- but I'm sure they'll reopen if they're still having a problem. [20:37:45] It seems almost any way we try and do it, it's going to end up being hacky [20:37:53] We could just hack it, and send 2 messages - one of the old format, and one of the new format [20:38:02] Bots won't recognise both versions, as such where the problem currently lies [20:38:15] Reedy: we can just as easily hack just sending one message, no? [20:38:29] true [20:38:29] AaronSchulz: ^ we're talking about bug 34508 here [20:38:42] apart from we've still got to get from format A to format B [20:38:56] oh....maybe that's where the disconnect is [20:39:03] which could be regex hell [20:39:12] I don't think we need to do a transform [20:39:16] reedy-trunk: 14[[07LogPage14]]4 N10 02http://192.168.0.190/w/index.php?oldid=472&rcid=523 5* 03Reedy 5* (+4) 10Test [20:39:16] reedy-trunk: 14[[07Special:Log/move14]]4 move10 02 5* 03Reedy 5* 10Reedy moved page [[02LogPage10]] to [[LogPage2]] [20:39:16] reedy-118: 14[[07LogPage14]]4 N10 02http://192.168.0.194/w/index.php?oldid=3&rcid=3 5* 03Reedy 5* (+4) 10Created page with "Test" [20:39:16] reedy-118: 14[[07Special:Log/move14]]4 move10 02 5* 03Reedy 5* 10moved [[02LogPage10]] to [[LogPage2]] [20:39:25] *Reedy rages at the numbers [20:40:05] Reedy: couldn't we just eat the first one from LogFormatter, and make another call from there? [20:40:29] Looking at those 2, the only difference is the addition of the prefix of who did the action (slightly superfluous, but whatever) [20:40:51] Nikerabbit: still around? [20:42:46] Do they all have the prefix of "Foo action X" now? [20:43:19] Some seem simpler, then we get like the blocked ones have a block of extra text at theend of the message, before the same ": Why" [20:47:02] '1movedto2' => 'moved [[$1]] to [[$2]]', [20:47:02] '1movedto2_redir' => 'moved [[$1]] to [[$2]] over redirect', [20:47:17] 'logentry-move-move' => '$1 moved page $3 to $4', [20:47:21] 'logentry-move-move_redir' => '$1 moved page $3 to $4 over redirect', [20:50:30] Though, it's all back to the "why the hell are people screen scraping!?" ;) (obviously in this case, there's nothing better) [20:55:19] Reedy: so are you thinking about using patches #1 and #3? [20:55:55] I don't know what I'm thinking [20:56:01] Why do we need an extension if we're going to fix core? [20:56:38] Reedy: oh, and doing it in the core [20:56:42] Reedy: basically, we think it can be mostly patch #3 [20:56:59] so not exactly the patches, but similar [20:57:09] ...but steal the "big ugly switch statement" model from patch #1 [20:57:30] you mean the if that's waiting to become a big ugly switch? ;) [20:58:22] filter on part 1, in there then filter on part 2, shouldn't be too nasty [20:58:38] Reedy: yeah, that one :) [20:59:17] robla: was? [20:59:21] We've actually got some that don't seem to have changed [20:59:29] But I don't know if irc shows them [20:59:38] 'rightslogentry' => 'changed group membership for $1 from $2 to $3', [20:59:38] 'rightslogentry-autopromote' => 'was automatically promoted from $2 to $3', [20:59:43] 'pagemerge-logentry' => 'merged [[$1]] into [[$2]] (revisions up to $3)', [20:59:48] 'revdelete-logentry' => 'changed revision visibility of "[[$1]]"', [20:59:48] 'logdelete-logentry' => 'changed event visibility of "[[$1]]"', [20:59:55] plus more [21:00:07] import, reblock... [21:00:35] there is only 10 log types [21:01:21] and numerous more non log type log types [21:01:34] might be [21:02:28] let's get the big ones in English sorted out....that'll remove this as a commons blocker [21:04:51] back around [21:05:33] I really really want someone to make the first commit on this in the next 15 minutes, so that we can split up the messages and get this done in the next two hours [21:05:49] Reedy: how close are you to committing something? [21:07:48] Reedy: ping [21:08:13] I haven't changed any code as of yet [21:08:26] sure...how close are you, though? [21:08:26] So to merge 1 and 3... [21:09:12] Basically we want to replace the getIRCActionText() with what is currently efLegacyLogsIrcFormat and tidy up parameters to match? [21:09:22] *Reedy closes patch 2 [21:09:32] Reedy: yup, that's basically it [21:09:58] patch 3 looked like the cleanest hack to me [21:10:11] also krinkle said it was only fixing part of the issue [21:10:16] yeah [21:10:26] so...there's the parameter ordering problme [21:10:34] rebuilding messages from scratch allows us to keep the format out without writing really scary regexes [21:10:43] one idea would be to have an array referencing which parameters to replace [21:10:59] actually....interesting [21:11:03] something like array( 'old' => 'new', 'old' => 'new' ) [21:11:16] I think I finally understand what AaronSchulz was suggesting in real life [21:11:18] so we can easily exchange $1, $2, $3 in a message [21:11:25] either that, or I had a flash of insight of my own :) [21:11:46] we basically can use patch #3, but reimport the old messages too [21:11:47] robla: btw, I have decreed you a hacking barnstar for patch #3 [21:11:53] cause it REALLY LOOK HACKY!! :-D [21:11:56] arrrgh, my working copy is messy [21:12:47] so....still use new messages, and build new alternates of them in other languages [21:12:59] but....for legacy bot support, also put the old messages in there [21:13:30] I have talked about that issue with some friends this evening [21:14:29] their main questions were: 1) can you change the bot regex? and 2) can you put back the old message [21:14:43] 1 can happen [21:14:51] with time and notification to the bot runners [21:15:51] will also mean that bots will be messing until every wiki migrated to 1.19 [21:16:14] *AaronSchulz looks at https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/languages/messages/MessagesEn.php?&pathrev=97044&r1=97043&r2=97044 [21:16:17] I'm going to go grab something to eat and brb [21:17:24] AaronSchulz: wanna start up an etherpad to build the compatibility array? [21:19:16] https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/languages/messages/MessagesEn.php?&pathrev=97495&r1=97494&r2=97495 [21:20:34] http://etherpad.wikimedia.org/IRCBot-Messages [21:24:05] hashar: only three log types where converted [21:24:17] ohh [21:24:23] see $wgLogActionsHandlers [21:24:47] well, I guess four, since part of the 'suppress' type was conveted [21:25:15] "part" as in all except suppress/block, the others are mirrors of delete/delete or delete/revision or delete/event [21:25:21] and numerous more non log type log types [21:26:06] can't you just hardcode the parameters [21:26:23] sounds prone to breakage if you add mappings [21:26:28] Indeed [21:26:36] I said that about rebuilding the messages from scratch [21:26:56] !r 112045 [21:26:56] --elephant-- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/112045 [21:27:22] w00t! [21:27:24] we can get the old translations from twn, but I don't want translators from transling these legacy messages [21:27:55] mark them all as optional? [21:28:03] Nikerabbit: do you say we should just use logentry-irc-* messages ? [21:28:06] some translate those too [21:28:18] hashar: I don't see why you need new messages at all [21:28:55] then we have like same messages like three times [21:29:13] Why 3 times? [21:29:41] new system logentry-, logentry-irc and the old key names [21:30:28] You can help out, it'd be appreciated :p [21:30:31] I don't think we need the old key names [21:30:40] the logentry-irc seems enough to m e [21:30:50] that will let us change the parameter order [21:30:52] do the bots need the old names? [21:30:55] YES [21:31:03]