[00:59:34] ^demon: ping [01:02:02] <^demon> pong. [01:06:18] <^demon|away> preilly: Actually I'll be back in just a bit [01:54:21] ^demon: you back? [01:54:42] <^demon> Yes [01:54:57] ^demon: do you have a minute for a question? [01:55:18] <^demon> Sure [01:55:33] so, I did a call to getQueryValues then unset the keys that I didn't need then called wfArrayToCGI to make a new query string [01:55:47] but, how do I get the url and path to link to? [01:55:53] Does that make sense? [01:56:18] <^demon> If you do getFullUrl() or getLocalUrl(), you can provide an array and it will do everything automatically. [01:57:13] how come I don't see that on http://svn.wikimedia.org/doc/classWebRequest.html#a82826bbef083453c9a02e40805045285 [01:57:33] <^demon> No, you don't want getFullRequestUrl() [01:58:02] <^demon> You can get the full query string with getQueryValues(), the remove the items from the array that you don't want. [01:58:26] I did that [01:58:49] <^demon> Then use Title::get{Full,Local}Url() passing that array as the params. [02:01:38] that is blowing up [02:02:10] Undefined property: ExtMobileFrontend::$mInterwiki PHP Fatal error: Call to undefined method ExtMobileFrontend::getPrefixedDBkey() [02:03:45] <^demon> Then it sounds like you're not setting $mInterwiki to the correct object. [02:04:02] ? [02:04:50] I'm doing anything with $mInterwiki directly [02:06:10] I think this might be due to the fact that this is happening in an output buffer handler and everything is destroyed already [02:06:48] since PHP 5.1.x, all objects have their destructors called before the output buffer callback function executes [02:07:36] ^demon: any ideas for a workaround? [02:21:04] ^demon: ^^ [12:48:52] Good day. Triage in 12 minutes. [12:49:14] See http://lists.wikimedia.org/pipermail/wikitech-l/2011-September/055149.html for details. [12:55:27] siebrand: Hello, newbie developer here.. [12:56:01] srikanthlogic: so good to see you. Welcome! [12:56:26] hmm, this is an interesting time for a triage. Isn't it the middle of the night for many folks? [12:56:40] I guess people come from all sorts of timezones though :) [12:56:43] siebrand : Hi everyone. Not a developer, but a learner over here. :) [12:56:44] srikanthlogic: we're starting in 4 minutes. Would you mind giving a brief intro of yourself that you can prepare now? (2-3 sentences on what you're looking for) [12:57:03] blucal: good to see interested lurkers. You're in step 1 of the 12 step program me :) [12:57:37] siebrand : I'll get there soon enough. Where do I start? [12:58:19] siebrand: professionally working as developer in soft giant, play by hacker at night, so far done some bottom up hacks with js / python.. [12:58:26] blucal: http://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker should be a great start. [12:58:38] srikanthlogic: nice. [12:58:53] srikanthlogic: had a look at MediaWiki code already? [12:58:58] siebrand: looking to gets some feel of mw coding, have some extension ideas which might help tamil wikipedia.. [12:58:59] siebrand: Be right back after paying that a visit. :) [12:59:08] siebrand: not yet.. just installed.. [12:59:28] srikanthlogic: oh yeah. You're in step 3 of the 12 step program already. [13:00:12] Rights, let's kick off. Next to srikanthlogic and blucal , who else are here for the triage and want to make their presence known? [13:00:50] Our todo list is at http://lists.wikimedia.org/pipermail/wikitech-l/2011-September/055149.html. I'll go through the issues one by one. [13:01:27] Usually these triages are held by the Wikimedia Bugmeister Mark Hershberger (hexmode), but he's really busy kicking devs assess to get the MediaWiki 1.18 blockers fixed :) [13:01:56] I hope he's glancing at this channel now and then... [13:02:22] Well, quick introduction of myself. Siebrand Mazeland, Product Manager Localisation for MediaWiki. [13:02:40] siebrand : Welcome Mazeland. :) [13:02:59] siebrand: congrats on your recent appointment :) [13:03:08] I'm basically product manager for a Wikimedia FOundation team that is tasked with improving language support in MediaWiki. We will be focusing on improving support for Indic languages initially. [13:03:15] thank you. [13:03:54] I'm also deeply involved in the translatewiki.net project, where anyone can help in translating the user interface of MediaWiki and other products. [13:04:17] Nikerabbit, aharoni and GerardM- are also on the team. [13:04:43] well, officially aharoni is not. But he's volunteering heavily at the moment. [13:04:59] Is Santhosh here too? [13:05:25] siebrand: dont see him [13:05:27] Anyone else before we really start? [13:05:31] I don't see him in #mediawiki either [13:05:38] *aharoni waves at everyone [13:05:45] 1. https://bugzilla.wikimedia.org/show_bug.cgi?id=16026 -- [13:05:46] MediaWiki:Revision-info should accept wikimarkup [13:07:03] Basically an issue that will allow one to look at previous attempts to resolve this issue, and come up with a better solution. That probably lies in introducing a new message, removing the old one. [13:07:08] Any takers? [13:08:04] Don't be shy, people. [13:08:32] doesn't look very complicated. Me, if no-one else? [13:08:37] blucal : I'm not into coding in php. But if it is documentation, I can give it a shot. [13:08:47] it's coding. [13:09:01] Amir: going once, going twice. Sold! [13:09:01] srikanthlogic: me neither a php dev, if its about changing message text, then may be.. [13:09:15] https://bugzilla.wikimedia.org/show_bug.cgi?id=16111 -- [13:09:15] MediaWiki:Cascadeprotected and MediaWiki:Cascadedprotectedwarning should [13:09:16] take the same parameters [13:10:12] Any comments? [13:10:25] Pass. [13:11:08] Message contents are: [13:11:09] '''Warning:''' This page has been protected so that only users with administrator privileges can edit it, because it is included in the following cascade-protected {{PLURAL:$1|page|pages}}: [13:11:10] and [13:11:14] if i understand correctly, both of these are bugs in particular messages and not something general. [13:11:19] you can find where those are used easily with grep [13:11:20] This page has been protected from editing, because it is included in the following {{PLURAL:$1|page, which is|pages, which are}} protected with the "cascading" option turned on: [13:11:20] $2 [13:11:32] aharoni: yes [13:11:47] So the first should have the second parameter added, I guess. [13:12:30] looks like another acceptable exercise for me [13:12:38] This is a fairly easy issue, and will make you familiar with parameter processing in MediaWiki system messages. [13:12:45] cool [13:12:48] Other takers than Amir? [13:13:05] siebrand: me ! [13:13:10] aharoni: and wfMessage is probably something you should look at, with the first one [13:13:18] Sold! [13:13:36] Next up, and slightly harder, and possibly controversial: https://bugzilla.wikimedia.org/show_bug.cgi?id=16175 -- Clean up the rendering of messages displayed at the top of the edit window [13:14:16] Any thoughts? [13:15:38] This bug probably means having to mess with EditPage.php, a critical class in MediaWiki [13:15:55] And a very nasty one [13:15:58] If I remember correctly, not everyone likes this class a lot. [13:16:06] better: what RoanKattouw says :) [13:16:20] EditPage scares me late at night ;) [13:16:48] MediaWiki, and Wikipedias in particular, can contain extremely elaborate pieces of text containing warnings and what not. [13:17:21] to the extreme point that it scares people away, if they read it at all :/ [13:17:43] It's a bit messy, and medium hard code wise, possibly hard to get accepted, because when deprecating old messages, many Wikipedias may get the challenge to rewrite those warnings again. [13:17:57] Nikerabbit: yes. But that's an entirely different topic... [13:18:23] Any takers? aharoni : as exam? :) [13:18:39] (it's diving in at the deep end) [13:18:43] i can try looking at that [13:18:59] OK, will assign it to aharoni . Let us know if you need help. [13:19:04] Thanks. [13:19:23] There's more! Like: https://bugzilla.wikimedia.org/show_bug.cgi?id=17148 -- The warning about editing a semi-protected page can display an irrelevant edit summary [13:20:04] Is everything related to coding? Will I fit in anywhere? [13:20:26] blucal: Lemme find you 1 or 2 issues that relate to UI message documentation. [13:20:47] siebrand : Thank you. :) [13:20:58] blucal: you would have to read code for this, but not develop new code: https://bugzilla.wikimedia.org/show_bug.cgi?id=19895 [13:21:13] siebrand : Shall I get on it? [13:21:23] blucal: https://bugzilla.wikimedia.org/show_bug.cgi?id=28557 -- Message documentation for Extension:AddMediaWizard needed too [13:21:35] blucal: that also contains a lot of JavaScript code. [13:21:52] blucal: have a look at it and let us know. [13:22:04] siebrand : I know js a bit. Will get back to you. :) [13:22:08] OK, back on track: https://bugzilla.wikimedia.org/show_bug.cgi?id=17148 -- The warning about editing a semi-protected page can display an irrelevant edit summary [13:22:12] Comments? [13:23:04] that bug could really use an example url or screenshot [13:23:23] Umm, do moving protection result in a different log_action then normal protection [13:23:43] It could just filter based on that if it does [13:24:07] yes [13:24:09] 'protect/move_prot' => 'movedarticleprotection', [13:24:11] bawolff: something you'd volunteer to look in further? [13:24:21] sure [13:24:33] sharat : want to help me on this one? https://bugzilla.wikimedia.org/show_bug.cgi?id=19895 [13:24:47] bawolff: and while you're at it, you might also want to look into the new logging system (unless Nikerabbit has already converted these log entries?) [13:24:55] siebrand: nope [13:25:07] only move, deletion and part of suppress logs [13:25:10] bawolff: feel free to poke Nikerabbit if you need help on that. [13:25:40] ok. I havn't looked at any of the new logging code at all (except for reading what's on wikitech-l), but i'll start looking at that [13:26:04] Thanks bawolff [13:26:06] Next up: https://bugzilla.wikimedia.org/show_bug.cgi?id=17865 -- Mismatched input syntax for Cite error messages [13:26:13] blucal: sure [13:26:15] Sounds more exotic. [13:27:02] I'd say this would require someone with a little more experience. [13:27:10] and it sounds like a very good way to learn about the Cite extension [13:27:28] Oh yes. [13:27:40] You know Cite? The extension that can bring Wikipedia down? :) [13:27:44] "can"? [13:27:51] has brought [13:27:52] ;) [13:28:39] Don't worry. All code is reviewed before it is deployed. [13:28:44] You're allowed to make mistakes. [13:29:02] sounds scary. now i'm curious - is there a record of how that happened? [13:29:15] aharoni: off topic. [13:29:32] Dude, lots of things have brought Wikipedia down before [13:29:35] Even LocalisationUpdate [13:29:42] aharoni: probably google for it, as it was discussed on wikitech-l IIRC. [13:30:29] *siebrand grins evilly. [13:30:45] looks like city is too scary for us :7 [13:30:46] Anyway, anyone interested in giving this a go? [13:31:07] which bug are you on? [13:31:17] well, a good advice would probably be to see how these messages are customized at en.wp and a few other large wikipedias. [13:31:29] hexmode: https://bugzilla.wikimedia.org/show_bug.cgi?id=17865 -- Mismatched input syntax for Cite error messages [13:32:03] Going once, going twice???. [13:32:19] Not sold. Next! [13:32:20] https://bugzilla.wikimedia.org/show_bug.cgi?id=25608 -- MediaWiki:Fundraiserstats-tab-ytd should not contain (USD) [13:32:32] Nikerabbit commented: Fundraising is always done in a hurry. When is there time for proper i18n? [13:33:18] The localization team will be in San Francisco where the fundraiser team is also hard at work. [13:33:30] How about we try and educate them a bit while there? [13:33:50] siebrand: I can bring this one back up in our upcoming fundraising triage [13:34:09] There are more issues in their code (for example a list of country names we could use CLDR data for (that is not yet in the MediaWiki CLDR extension) [13:34:21] hexmode: that would be great. [13:34:26] Done. [13:34:54] https://bugzilla.wikimedia.org/show_bug.cgi?id=19895 -- Fold identical messages, or state that they should or could be different [13:35:13] this too is about message documentation [13:35:14] This one is about Improve message documentation and/or merge duplicate messages. [13:35:23] blucal is on that. [13:35:59] blucal: do you have an account at https://bugzilla.wikimedia.org so you can comment on issues and submit patches? [13:36:09] also fundraising related? Hrm... [13:36:12] I'm making an account. [13:36:17] hexmode: yes [13:36:20] Will be there shortly. [13:36:50] Trying to download the source and install it in parallel. [13:36:59] blucal: so, you should come to the fundraising triage in a couple of weeks, too :) [13:37:01] blucal: you can add yourself on CC on the issue to receive updates by email. [13:37:09] hi akshayagarwal [13:37:17] hi siebrand [13:37:18] Ok, next issue [13:37:20] https://bugzilla.wikimedia.org/show_bug.cgi?id=29357 -- CategoryTree should have built-in localizable support for pretty Categorytree-member-num [13:37:20] CategoryTree extension. A little harder. [13:37:42] aharoni originally reported this. [13:37:44] Really should be done though [13:38:16] The default message for it is next to useless. Almost no wiki that regurally uses the extension has them uncustomized [13:38:19] bawolff: commenting on 29357, right? [13:38:23] so i can take it, too. [13:38:23] yes [13:38:43] bawolff: would you volunteer to assist aharoni in case he needs help? [13:38:54] yes sure [13:39:23] Great, thanks. [13:39:27] *akshayagarwal is available for some medium to little complex bugs [13:39:48] akshayagarwal: sweet! Thank you. [13:39:51] https://bugzilla.wikimedia.org/show_bug.cgi?id=29927 -- CentralAuth using wrong Language on Special:MergeAccount [13:39:57] akshayagarwal: there's your first one? [13:40:05] I don't think the bug will be too difficult, more it will be conceptually difficult how to make that message translatable easily (I think, I'm saying that without looking at the code in category tree) [13:40:09] Nikerabbit commented: Looks like an easy string replace. To warm up [13:40:26] i ll take it [13:40:35] bawolff: if abbreviations are documented well, translations aren't that hard anymore) [13:40:58] akshayagarwal: you're a committer already, right? [13:41:09] siebrand: yes [13:41:35] ok. (I only speak english, so some of the mysteries of what is and is not easy to translate is mysterious to me ;) [13:41:35] akshayagarwal: can you please assign yourself in bugzilla? Your nickname here does not resolve in bugzilla. [13:41:48] bawolff: don't worry; Amir's a master. [13:42:26] Ok, the next one is a scavenger hunt. [13:42:27] https://bugzilla.wikimedia.org/show_bug.cgi?id=30729 -- Not all numbers are localised in AbuseFilter [13:42:27] Scavenger hunt! When numbers are used in the UI, they should go trough $wgLang->formatNum(). [13:42:31] siebrand, thank you :) [13:42:53] It's not hard, but it will force you to check all output of a not that small extension. [13:43:06] You'll learn *a lot* doing this. [13:43:34] Expect it to take a proportionate amount of time though [13:43:49] Agreed. [13:43:49] I wonder if that could be semi-automated somehow [13:44:16] depends. If parameters and message keys are on the same line, gripping will be easier. [13:44:16] siebrand: me ? [13:44:16] put weird stuff in the digit conversion table, and see what's left that's still a number [13:44:18] AbuseFilter is pretty big, although you should be able to just focus on the front end, assuming the front end and back end are cleanly separated (which I assume they are) [13:44:47] bawolff: That would work. Alternatively, speak a language with different numerals and set that language [13:45:06] srikanthlogic: if you're not familiar with MediaWiki (extension) code at all, it's not the easiest thing. If you take it, expect it to take at least 4 hours. [13:45:54] siebrand: hmm.. from the description, i thought its about changing all out statements where numbers appear to use the function.. [13:46:01] srikanthlogic / bawolff : wanna work together on this one? (mentor/mentee-like)? [13:46:20] srikanthlogic: something like that, but you have to find where they are used. [13:46:40] srikanthlogic: in the UI numbers can appear differently depending on user language. [13:46:48] I'm certainly willing to help if needed [13:46:50] siebrand: essentially grokking each line of code ? [13:46:50] srikanthlogic: believe me mentor/mentee works awesome in MW [13:47:14] srikanthlogic: you have to use the global object for user language ($wgLang) and run the number through formatNum() of that object [13:47:43] srikanthlogic: do you have a bugzilla account already? (and what's the username?) [13:47:54] srik.lak@gmail [13:48:07] siebrand: srik.lak .. i usually report and go away :D [13:48:20] be wary, I think dantman made a threat about torturing kittens if $wgLang use used over the requestContext stuff when it didn't need to be ;) [13:48:26] srikanthlogic: well, that's about to change! :) [13:48:57] srikanthlogic: good to see you lurking less :) [13:49:43] hexmode: thanks :) [13:49:46] bawolff: oops. Please correct me. I'm only a PM :) [13:50:13] lol [13:50:19] The next two come as a pair and may lead to discussion into the next part of this triage: [13:50:24] https://bugzilla.wikimedia.org/show_bug.cgi?id=29170 -- [[MediaWiki:Enotif body]] needs GENDER support [13:50:25] https://bugzilla.wikimedia.org/show_bug.cgi?id=22769 -- MediaWiki:Enotif body: Replace named Parameter [13:50:37] eww, enotif ;) [13:50:50] aww that one [13:51:19] When "speaking" to and about users, the gender of the user may influence conjugation and other grammatical aspects of spelling [13:51:33] The first request asks for making that possible. [13:52:04] Secondly, named parameters are used in this system message ($PARAMETERNAME) instead of the regular numbered parameters ($1, $2, ..) [13:52:35] the first one depends on the second one [13:52:57] also be wary that some of the enotif code is a tad scary... [13:53:08] siebrand: do we have a common consensus about using gender? i remember a lot of discussion regarding enabling this in the signup form [13:53:33] akshayagarwal: unresolved, as far as I know. [13:53:48] akshayagarwal: gender is already in the software [13:54:03] akshayagarwal: we did recently change the wording from default "unknown" to "undisclosed". [13:54:10] the discussion was about where we should ask users to define it [13:54:33] Nikerabbit: ah yes [13:54:49] MediaWiki is a lot "no nag", where other "social platforms" (thinking of Facebook and LinkedIn) continuously nag you for completing your profile. [13:55:03] This would typically be a thing you'd nag users about *after* registering. [13:55:10] *bawolff always thought asking the gender on the sign up form should be (content) language dependent and ask for it on langs where it signficantly matters [13:55:14] Because it should be as easy s possible to register. [13:55:41] siebrand: agreed [13:55:53] bawolff: well, in English it's relevant too, but we avoid it by using "their" instead of his/hers, etc. [13:56:02] there is also bug open about the *way* we should ask for that information [13:56:14] Its, relevant but not critical [13:56:17] and I think there was a nice proposal how to do that better [13:56:30] siebrand: can we star using "xe" instead of "their" [13:56:32] My understanding is in some languages (slavic ones?) its critical [13:56:38] hexmode: I will kill you :P [13:56:42] *hexmode becomes very active on TWN [13:56:43] bawolff: sure, but with that reasoning we could close all but a few issues in bugzilla :) [13:56:47] :) [13:57:16] OK, we're not going to resolve this, and I really want one more issue discussed. [13:57:22] We have about 3 minutes left. [13:57:52] And I asked RoanKattouw to participate, because we're proposing a schema change. Or at least want to discuss the feasibility of it. [13:58:09] https://bugzilla.wikimedia.org/show_bug.cgi?id=28428 [Page titles][RTL] This schema change would likely solve many issues. [13:58:09] https://bugzilla.wikimedia.org/show_bug.cgi?id=28411 [13:58:22] Allow saving pages with LRM and RLM in titles, showing a warning and requiring a user right [13:58:33] titles of articles with LTR titles in RTL wikis may be displayed incorrectly in categories and special pages [13:58:44] RoanKattouw: did you by any change have a look at these issues? [13:59:03] what's wrong with page_props ? (I guess if we need it constantly then it'd make more sense in page though) [13:59:10] the proposal is to add page_displaytitle column to page table [13:59:15] I'm only looking at it now [13:59:19] You don't need page_displaytitle [13:59:24] Nikerabbit / aharoni : need you on this. Not my thing. [13:59:24] It's in page_props already [13:59:50] RoanKattouw: but it's not free that way [13:59:58] RoanKattouw: we need that information, and in many places [14:00:06] (everywhere?) [14:00:21] Probably in a LOT of places, yeah [14:00:27] But that shouldn't be a problem, should it? [14:00:34] Joining page against page_props by page_id is cheap [14:00:40] We may need an extra index [14:00:58] Nope [14:01:00] PRIMARY KEY (`pp_page`,`pp_propname`) [14:01:16] RoanKattouw: how about joining category listings to page_props? [14:01:29] Nikerabbit: Do it in batches [14:01:39] Integrate with Linker and LinkBatch [14:02:06] As I was about to say, this is a bit of an ambitious project, and will need the displayname stuff to be integrated with Linker, LinkBatch and probably Title as well [14:02:25] I agree that having displaytitle as a page_ field makes more sense *conceptually* [14:03:06] But in practice, I prefer page_props because that avoids a schema change and is still cheap [14:03:11] right [14:03:44] aharoni: is it already possible to use displaytitle to set the correct title? [14:03:52] just to check, have we considered if there would be any circumstances where we wouldn't want {{DISPLAYTITLE:...}} to be used in other places [14:04:13] if there will be a displaytitle property, it would solve it. [14:04:28] bawolff: I can't think of any... which probably means we will find one once the code is about ready [14:04:36] lol [14:04:48] I can't think of any either off the top of my head [14:05:02] aharoni: displaytitle already exists, but it only modifies the title of the page you are currently viewing [14:05:12] it would probably also solve cases for which http://en.wikipedia.org/wiki/Template:Correct_title and http://en.wikipedia.org/wiki/Template:Lowercase_title are needed today [14:05:16] if that already works, we will only expand it to be used everywhere [14:05:36] aharoni: It already exists ;) [14:05:54] i must misunderstand something. is it a column in the page table? [14:06:09] aharoni: a page property. [14:06:18] different table. [14:06:27] oh [14:06:32] Conceptually it makes more sense to make it a column [14:06:48] But in practice, adding a column to a table with 20M+ rows is not painless [14:06:49] aharoni: for example, its used on http://en.wikipedia.org/wiki/IPod [14:06:58] aharoni: page_props table [14:07:02] http://www.mediawiki.org/wiki/Help:Magic_words#Technical_metadata [14:07:06] yeah, i see now. [14:07:35] What are the drawbacks of not changing the schema and using page_props? [14:07:50] it adds some complexity [14:08:01] on the other hand updateing the column in page table would add some complexity too [14:08:08] so yeah, using it in other places will solve this. [14:08:29] otoh, that'd be one time complexity. using page_props would add complexity that lasts forever. [14:08:34] I agree with Roan, currently we have no reason to introduce a schema change [14:08:46] so then we have correctly display, etc. Would category sorting, etc, work with the display title, too, then? [14:09:03] Is there a method by which we can compare the two complexities? [14:09:13] schema change > everything [14:09:26] siebrand: should it? [14:09:32] ;) [14:09:35] Nikerabbit: :) [14:09:36] bawolff: I think it should [14:09:55] otoh, the title should still be equivalent... [14:10:18] and we probably don't want to be sorting ‎ if that's what we're putting in them [14:10:22] bawolff: display title x for page a would look a little out of place under a [14:10:39] I assume we're keeping $wgRestrictDisplayTitle to on [14:10:45] anyway, ideas are already forming in my head how I would now go on to do this [14:11:03] although that is a valid point for third parties who might turn it off [14:11:13] bawolff: or thinkg about translate extension [14:11:21] Nikerabbit: if you're taking any of these issues, can you please assign them yourself? [14:11:23] translated pages are stored as pagename/code [14:11:44] siebrand: I could... but there is already queue for me :) [14:11:49] As it is 11 minutes past our window, I'd like to close the triage now. Please feel free to continue talking. [14:12:14] aharoni, Nikerabbit, hexmode, RoanKattouw, bawolff, srikanthlogic, akshayagarwal, blucal: Thank you very much for showing up and contributing. [14:12:19] The same goes for the lurkers. [14:12:27] Please feel free to join in any time. [14:12:30] and thanks to siebrand for leading us [14:12:39] siebrand: Its actually purely accidental I'm here, I didn't even realize this was happening ;) [14:12:42] siebrand: thanks! [14:12:49] siebrand, you're welcome. now i've got work to do :) [14:12:49] Next week I expect there will be another triage, organized by hexmode. Do attend! [14:12:58] aharoni: wee :) [14:13:06] siebrand: thanks! [14:13:24] aharoni: did you btw look at the bugs siebrand sent to your way? [14:13:39] to blucal and srikanthlogic : please feel free to ask us for help and suggestions here. [14:13:46] nikerabbit, yes. [14:13:47] Isn't the next triage the wikibooks one? [14:14:00] Nikerabbit: I'm not really familar with translate, but wouldn't you want pages to be sorted "pagename/language" in that case? [14:14:18] blucal, srikanthlogic : most of the localization / internationalization developers hang out in #mediawiki-i18n, too. [14:14:45] Triage out! Thanks again. [14:14:53] siebrand : Thanks! [14:14:54] bawolff: dunno about sorting, but display names would be totally different [14:15:07] aharoni: particularly the one about namespace aliases [14:15:22] yes, saw that one. interesting. [14:15:43] Nikerabbit: maybe more a usecase for using GetDefaultSortkey hook perhaps then displaytitle (maybe) [14:16:21] bawolff: compare the title of http://translatewiki.net/wiki/Technology/ast http://translatewiki.net/wiki/Technology :) [14:16:23] siebrand : I'm having trouble installing it. Trying to set up the database. I'm stuck at the following line "Now, you can go to the installer script: http://your_machine/wiki/config/ and provide the wikiuser and the password you have set in the GRANT MySQL command." [14:17:10] Nikerabbit: Hmm [14:17:11] aharoni: any ideas about how to best achieve the end result? [14:17:36] i have to learn the namespace aliases system first. [14:18:00] aharoni: I'd do it programmatically, if it is possible and makes sense [14:18:11] and because that helps everyone, just not those who think about it [14:18:21] you mean, some kind of an automatic transliteration? [14:18:23] blucal: you really don't need to run GRANT commands in mysql, the installer can generally create a user for you. Just drop the tarball into a web viewable folder, and follow on screen instructions :) [14:19:00] aharoni: stripping the ZWNJs and other problematic characters [14:19:15] yes, probably. [14:19:33] bawolff : But I used svn to get the files. I don't have a tarball. [14:19:59] blucal: oh that's even better. Just browse to it in your web browser [14:20:30] bawolff: Using the 'file' protocol? [14:20:49] blucal: oh, do you have apache installed? [14:20:56] you're going to need that [14:21:02] bawolff: Yes I have it installed. [14:21:27] in that case (if it's configured properly) you can go to http://localhost and it should be your own computer you're browsing to [14:21:31] is there an groking tool for the codebase ? [14:21:54] srikanthlogic: grep is good ;) Krinkle has a search tool on the toolserver somewhere [14:22:21] *srikanthlogic is lazy to grep :D [14:22:43] bawolff: It says "IT WORKS! This is the default web page for this server.[...]" [14:22:53] back in a few minutes [14:22:59] ok, that's the default thing that comes to apache [14:23:13] you migth have to go to localhost/wiki or something depending on where you installed it [14:23:24] Alright. Let me see. [14:23:43] blucal: Sorry, I have to go to class (but there's lots of friendly people here, I'm sure someone will help you figure out the rest) [14:25:00] hi AryehGregor [14:25:07] Can anyone please help to access my home folder using my browser? I have apache installed. [14:25:43] I'm trying to install wikiMedia but got stuck while preparing the database. [14:25:59] blucal: usually apache looks stuff under /var/www/ by default [14:26:30] Nikerabbit : I see. Let me check it out. [14:28:20] Nikerabbit: There is just an html file there which was displayed with the URL "http://localhost". So how can I access my home folder? I wanted to go to the directory where I have downloaded the wiki files using svn. [14:29:25] Nikerabbit : I'm sorry. I'm a total beginner. [14:29:38] blucal: a symbolic link may work [14:29:53] or you may need to edit apache's configuration to look for your home folder [14:30:22] Oh. Can you give me any resource on how I can do that? [14:30:33] which one? [14:30:50] Either a symbolic link or configuring apache. [14:31:39] you can make symbolic links with ln -s, man ls gives manual [14:31:52] blucal: do you see htdocs folder in apache? [14:32:42] Nikerabbit : I'll try that. [14:33:10] akshayagarwal: Where will be the htdocs folder located? [14:33:18] akshayagarwal: you do the signup api extension, right? [14:33:29] hexmode: yes, I did :) [14:33:45] hexmode: i was a GSOC student [14:33:54] akshayagarwal: where is it used now, do you know? [14:34:50] hexmode: no, i had put up a mail to the list for RFC but got no replies [14:35:21] Nikerabbit : Did you mean "man ln" or "man ls"? [14:35:24] blucal: you should find it in the apache folder itslef [14:35:32] it looks sweet. Maybe I'll get a chance to check it out soon [14:35:33]