[00:00:01] It runs now [00:01:12] VasilievVV: they use the stable version of the template or the one used in the page during the review, whichever is newer. If no version can be specified, in some odd cases, it uses the current. [00:01:48] 03demon * r39929 10/trunk/extensions/LiquidThreads/README: (bug 15295) Outdated docs lead to broken configurations that render wiki dead. [00:02:07] Thanks [00:02:11] 03(FIXED) Impossible to lauch Mediawiki with LiquidThreads - 10https://bugzilla.wikimedia.org/show_bug.cgi?id=15295 +comment (10innocentkiller) [00:02:57] <^demon> Grondin: Docs updated, bug fixed. :-) [00:04:03] thanks ^demon [00:04:09] <^demon|busy> No problem. [00:06:16] 03grondin * r39930 10/trunk/extensions/LiquidThreads/README: correcting some links [00:06:44] I've corrected a missing update [00:07:23] <^demon|busy> Didn't see that, thanks. Now I'm off to go be |busy [00:07:56] good nighty [00:11:40] <_mary_kate_> i wonder if our newpage notice couldn't have bigger text, and blink a little. [00:11:44] <_mary_kate_> maybe a [00:52:50] Hmm. http://www.mediawiki.org/wiki/Extension_namespace_registration [00:53:05] Using namespace numbers in the 1-100 range. Ewwww. [00:53:29] <_mary_kate_> hardcoding namespace numbers seems like a bad idea [00:53:33] <_mary_kate_> isn't there a better way to do that? [00:56:19] ^_^ An installer script that selects the first free ns id? [00:57:59] refactor all of MediaWiki to use textual ids rather than integers? heh [00:58:02] Maybe we should change page_namespace to an ENUM. domas would like that. [00:58:21] Especially since in MySQL you normally have to rebuild the entire table to add something to an ENUM. [00:58:23] T_T Aaaaaagh... the extensions, the extensions... [00:58:33] heh, ya [00:58:45] Well, integers are fine, really. [00:58:54] But using lower than 199 is plainly stupid. [00:58:56] It's not like the ENUM-to-int mapping is stored in the .frm file and totally independent of the table data or anything. [00:59:02] MZMcBride, well, yes, that's certainly true. [00:59:42] CREATE TABLE /*wgDBprefix*/namespaces ( ... ); ^_^ [01:00:06] Let extensions grab the first one they can find on installation? [01:00:20] ^_^ And at the same time make it possible to administer them from the user end, heh [01:00:53] So every website is different? Ewww. [01:01:52] Sites don't use the same page_id for 'Foobar', why does something like 'Forum' need to be constant? [01:02:38] And you can always have a preference to what id to use [01:02:59] But use a different one if it exists [02:19:03] TimStarling: It seems very strange that external links don't have precedence in the parser in certain cases (like inside a table). [02:20:29] E.g., http://test.wikipedia.org/w/index.php?oldid=62722 [02:24:43] AaronSchulz: yes, I broke LiquidThreads installs. You have to include LiquidThreads.php [02:25:02] I suppose I could hack around so including LqtPages.php works, but ultimately people should reconfigure it [02:25:06] *AaronSchulz already got that :| [02:26:07] 03(NEW) External links should have higher precedence in parser - 10https://bugzilla.wikimedia.org/show_bug.cgi?id=15296 15enhancement; normal; MediaWiki: Page rendering; (MZMcBride) [02:31:17] *Werdna giggles at http://www.mediawiki.org/wiki/Project_talk:Administrators#Stewards [02:32:21] slakr: ^^ , for reference. [02:38:05] joy [02:48:46] MZMcBride: what sort of strange? [02:49:15] strange as in unexpected? [02:49:33] Yes. Unexpected and broken. [02:49:38] It doesn't format the external link. [02:51:54] so... you're not familiar enough with the parser to expect it to be broken? [02:52:08] I would expect that that would be a parser bug. [02:52:37] Given the unexpectedness and the brokenness. [02:52:42] // Tables need to come after variable replacement for things to work [02:52:42] // properly; putting them before other transformations should keep [02:52:42] // exciting things like link expansions from showing up in surprising [02:52:42] // places. [02:52:42] $text = $this->doTableStuff( $text ); [02:52:57] so there's the rationale [02:54:00] Still seems pretty broken. Pipes are fully valid in external links. [02:54:21] hmm, can anyone think of why Special:Random would have brought up a project namespace page for someone on enwiki? [02:55:04] Typo in the namespace name? [02:55:08] Krimpet: because Articles for Deletion redirects to WP:AFD [02:55:11] I'm not saying it's not broken [02:55:16] I'm just saying that lots of things are broken [02:55:32] who reverted my latest parser changes? [02:55:39] I'm not sure I understand still. [02:56:14] If it sees http:// or irc:// or whatever, I'd assume that would take precedence over table syntax (at least it would logically). [02:56:48] MZMcBride: use {{!}} [02:56:55] That doesn't work. [02:57:02] :( [02:57:11] And it's not about a workaround. I have one of those. [02:57:16] Alexfusco5, but redirects aren't supposed to pop up in Special:Random. [02:57:16] It's about fixing the brokenness. [02:57:51] Krimpet: maybe it bypasses the redirect by default or its a bug [02:59:13] I checked the code, and it doesn't look like it would. it's weirdness :p [03:00:07] hmm, idk then [03:09:08] 03tstarling * r39931 10/trunk/phase3/includes/ (LogPage.php RecentChange.php): Minor log-related changes for documentation and to support a potential extension [03:09:27] Any french-speakers around? [03:09:53] MZMcBride: it's a perfectly valid, bracketed link, there's no ambiguity [03:10:52] but the author of doTableStuff() was worried that if links were done before tables, then the subsequent link expansion would have links in attributes [03:11:10] Krimpet: ask them to reproduce it :P [03:11:13] this is, as it turns out, an easy problem to address [03:12:18] but any change to parse order would have so many consequences to syntax that maintaining backwards compatibility becomes a significant challenge [03:15:57] MrZ-man, that's a bit hard when we've got several million articles that could come up. :) [03:16:15] it should only take him a few days [03:16:28] though he'll need to videotape it or something [03:23:58] 14(INVALID) External links should have higher precedence in parser - 10https://bugzilla.wikimedia.org/show_bug.cgi?id=15296 +comment (10dan_the_man) [03:24:46] *MZMcBride stabs Dantman|Food. [03:24:57] Oh, heh [03:25:08] [http://en.wikipedia.org/w/api.php?title=foo|bar external link] is perfectly valid. [03:25:12] :/ You could have just said something like "api urls with |" [03:25:21] It's any URL with pipes. [03:25:29] Mhmm, primarily api stuff [03:25:41] Pipes are only an issue with MediaWiki. ;-) [03:25:45] The rest of the web likes them. [03:26:23] ;) Most of us who deal with common users are used to users who accidentally try and use | to break the link and display text [03:26:31] http://en.wikipedia.org/w/api.php?action=query&titles=Foo%7CFlibblez ~~== http://en.wikipedia.org/w/api.php?action=query&titles=Foo|Flibblez [03:27:06] [http://en.wikipedia.org/w/api.php?titles={{urlencode:{{{1}}}}} link] [03:27:23] not a workaround, just common sense ^_^ [03:27:24] 04(REOPENED) External links should have higher precedence in parser - 10https://bugzilla.wikimedia.org/show_bug.cgi?id=15296 +comment (10dan_the_man) [03:27:48] Hmm... why doesn't it have that order anyways [03:28:01] I thought table syntax was just about the very last thing done? [03:28:10] *Splarka points up [03:29:35] ^_^ If you poke me... I could include external links in my link rewrite [03:29:52] If you do it right it should be possible to handle this stuff right [03:30:06] ;) Regexes are evil [03:38:37] noi [03:38:40] no no no [03:38:43] regex are not evil [03:38:49] it's only what hte users make of them :) [03:39:50] it's like saying a chainsaw is evil because it can slice zombies ^^ [03:42:01] I agree, however, that regexes are overused. [03:42:21] often used as a catch-all where more appropriat text-processing could be used. [03:42:29] regexes are nice, but not in parsers :) [03:51:41] heh [03:52:00] Ok... I mean regexes are evil for things like our bracket matching [03:52:17] Especially for anything recursive [03:53:11] urk, I always fix this, and then always forget and do it wrong again next time ... I'm making a note this time ... I have ye olde <specialfoo> problem (the special page name shows up as '<specialfoo>' rather than 'specialfoo') where should I look to fix the problem. [03:53:45] ^_^ That's because the message 'specialfoo' needs to be defined [03:53:53] Oh. Duh. [03:54:08] *kim__ will promptly forget again [03:54:09] But the title? eugh [03:54:10] but wait! [03:54:16] *kim__ makes a note [03:54:17] Special:SpecialFoo? [03:54:27] :-P [03:54:43] I tell you, I mix this stuff up every time [03:54:44] Special:Foo should use the message 'foo' [03:54:49] then I fix it, and start all over :-P [03:54:52] roger ;-) [03:55:01] ^_^ That's why you do two things [03:55:24] *kim__ made the same mistake umpteen times on omegawiki 1 :-P [03:55:36] 1) Use previous extensions as templates; Just reuse your special page, parser function, header comment, i18n files as bases for new ones [03:55:38] 'cause I don't write code for mw often enough, I think [03:56:10] well, I've been doing that for a while. I just wanna totally grok it for once :-P [03:56:14] 2) Whenever you see <...> or <...> remember that the first thing you should check, is if you have a system message with that name defined [03:56:30] rogerroger [03:56:33] *kim__ kersalutes [03:56:41] ^_^ Be careful of wfLoadExtensionMessages [04:04:13] 03werdna * r39932 10/trunk/extensions/GlobalBlocking/ (GlobalBlocking.i18n.php SpecialGlobalBlockList.php): Fix glaring error where searching for an IP in the global block list would search for YOUR IP. This is what happens when you steal code from other places :) [04:04:38] 03(NEW) Problem with reloading edited page after browser crash or "exit" - 10https://bugzilla.wikimedia.org/show_bug.cgi?id=15297 15enhancement; normal; MediaWiki: User interface; (millosh) [04:27:53] 03tstarling * r39933 10/trunk/phase3/includes/parser/Parser.php: Revert r39675, which made functions that don't depend on $this static, for performance. See wikitech-l for a full explanation. [04:32:43] 03(NEW) Cannot Use Parser Inside EditPage::showEditForm: initial Hook - 10https://bugzilla.wikimedia.org/show_bug.cgi?id=15298 normal; normal; MediaWiki: Page editing; (david.sledge) [04:36:18] TimStarling: I'm working on an extensible RightsManager interface (i.e. anything that wants to define users and groups can extend RightsManager and add its class-name to $wgRightsManagers, and it automatically gets its groups/rights listed on ListGroupRights, gets a free Special:GroupRights special page, and a free Special:UserGroups interface). However, I'm not sure how to present the option of which RightsManager to alter group rights / user ... [04:36:24] ... groups for. Should I give the option when a user loads Special:GroupRights/Special:UserGroups (which is redundant for 99% of users, who would want to edit local users/groups), somehow magically add a special page for each one, or is there some better way that I'm missing? [04:37:18] what is $wgRightsManagers for? [04:38:21] well, the idea is that it's pluggable. So we have our regular MediaWiki native rights manager (ConfigAndDBRightsManager), and then there'd be a global groups rights manager (GlobalRightsManager) defined in CentralAuth, and a rights manager defined wherever another system wanted to grant users rights by putting them into groups. [04:38:55] so there'd be about 5 functions you'd have to override, and the rest is done for you. [04:39:12] and you'd present an entirely separate UI for each one? [04:39:20] No, that's the idea. [04:39:52] It's the *same* UI (give or take a few extra things, like the wiki sets in CentralAuth). [04:40:06] hello brion. [04:40:09] oy [04:40:12] hi brion [04:40:25] g'day mates [04:40:38] brion: what did you mean by "NEEDS PARSER TESTS" in r39662? [04:40:41] good timing. Brion was the one who suggested I break rights-management out of the User object. I decided that I may as well go the whole way and make it pretty and OO. [04:41:06] TimStarling: probably that there should be some parser tests for the regression,w hich i think i then added (?) [04:41:22] ok [04:41:23] yup [04:42:52] Perhaps a parser test for: https://bugzilla.wikimedia.org/show_bug.cgi?id=15296 [04:43:46] isn't | already forbidden in URLs? [04:43:49] If you read up, brion, I've got to the stage of generalising the UI for editing group rights for a particular "rights manager" (e.g. the native MediaWiki rights manager, or the global groups rights manager). I'm trying to figure out how I should present it -either as a "Select a rights manager" box on the applicable management page (ugly, breaks the 99% use case of just wanting to edit local groups/rights), or by generating a new pair of special ... [04:43:51] brion turning australian? [04:43:56] ... pages for each rightsmanager (perhaps a better idea). [04:44:18] | works fine in urls [04:44:21] Splarka: Localizing for his audience, I think. [04:44:27] Otherwise we wouldn't be using it in the api [04:44:29] brion: usually when you write something in capital letters, it means you're hoping someone else will do something :) [04:44:45] Tim and I are both in Australia. [04:44:55] so I think MZMcBride was right there. [04:44:56] Fine. Localising. [04:45:24] :D [04:45:27] heh [04:45:37] fair 'nuff, when does the WMF office move 'ozward? [04:45:49] what do you mean "when"? [04:45:58] touche [04:46:01] http://test.wikipedia.org/w/index.php?title=Sandbox&oldid=62726 [04:46:02] it's already the branch office. Says Tomasz, anyway. [04:46:06] Werdna: well, there's a couple possibilities off the top of my head [04:46:29] one is to display a list of available backends, pick one, then pick a group and edit it [04:46:47] another is to do like SPecial:Userrights does; where you can put in a local group name or a global group name, etc, and it "just works" [04:46:52] 03(mod) External links should have higher precedence in parser - 10https://bugzilla.wikimedia.org/show_bug.cgi?id=15296 +comment (10dan_the_man) [04:46:59] got to go visit some wedding photographer in carlingford, bbiab [04:47:21] right. As I said, I think that selecting a backend adds unnecessary complexity to the typical use case. [04:47:31] brion: that's not how Special:Userrights works. [04:47:44] you go to Special:Userrights or Special:GlobalUserGroups. [04:48:04] Werdna: users and groups are different things, which is why those are separate [04:48:12] (??) [04:48:26] but local users and users on another wiki are handled in the same interface, which is Correct [04:48:37] no, not leaving yet [04:48:40] global users should be in the same place (but perhaps aren't yet) [04:48:45] *Dantman|FS remembers back when he created a semi-shared permissions hack [04:49:02] brion: well, there's the opportunity to make them in the same place now, as I write this :) [04:49:10] :DD [04:49:40] ^_^ shared and local db were used for permissions... and certain groups, ie 'staff', could be made to go into the global table instead of local [04:49:56] Currently, the idea is, to write a backend, you derive from RightsManager and add $wgRightsManagers[] = 'MyRightsManagerClass'; [04:49:59] and that's all :) [04:51:33] that would actually be pretty cool [04:51:53] neat [04:53:21] I suppose I could use the "select backend first" thing, EXCEPT if there's only one backend you can use, skip it. [04:53:50] bleh... no-one apreciates the SMW improvements... [04:53:58] less things to choose is usually best :) [04:54:11] Hmmm... ^_^ What would people think if I separated the Semantic and the Forms in "Semantic Forms" ;) [04:54:12] right [04:54:14] what's the workflow going to look like? [04:54:21] http://img393.imageshack.us/img393/576/hesaidsemanticga2.jpg [04:54:32] brion: for changing user rights? [04:54:37] maybe for global users i'd like to be able to click on both his local and his global groups on one screen [04:54:40] ;) Splarka, you might actually like this idea [04:54:46] and then jump from there into group management [04:54:57] Splarka: :D [04:54:57] Think, Form interface like Semantic Forms, but no Semantic... [04:55:09] so what, just "Forms" ? [04:55:22] ah, you're thinking of more linkage between special pages. [04:55:34] ie: Turning Semantic Forms into a Forms extension with a pluggable backend [04:55:52] And making a semantic module one of those possible backends [04:55:52] I just hate the word ^_^ [04:55:56] heh [04:56:04] (and the negative associations with it, due to it) [04:56:59] brion: well, the intention was to co-opt the Special:GlobalGroupPermissions from global groups, and modify that and Special:Userrights to support multiple backends. [04:57:15] Werdna: did that SiteConfiguration hook from 39824 get sorted out? it looks like you did a hack to check if Hooks.php was loaded, this looks pretty unstable and weird imho [04:57:15] brion: but if you like, I can add some better linkage between them so it looks more like a cohesive rights-management interface. [04:57:27] *brion likes cohesive linkage [04:57:51] Splarka: Think of being able to edit a parserfunction using a form.... and then... think of an infobox system built out of parserfunctions... ;) see the drift there? [04:58:01] brion: I didn't do anything about it, but I could probably just take it out and subclass instead :) [05:02:09] brion: so much refactoring, so little time :) [05:02:37] Dan: I see the drift, but... well.. never was much a fan of dumbing down the wikicode (wikitext either) [05:02:54] remember what FrontPage did to the web [05:03:10] Hmmm? [05:03:24] *Lady_Aleena shudders when she remember Front Page and hides. [05:03:47] those who forget the past are doomed to repeat it [05:04:14] The idea of the forms is not really genericly dumbing down things... it's turning certain types of input (ie: the fields inside of an infobox) into a data entry form, rather than a large blob of text [05:05:04] *Werdna stabs Splarka [05:05:09] We do want to "dumb down" wikitext. [05:05:09] I didn't say the word! ow [05:05:11] Honnestly, form based input is a lot more sane in implementation than all the attempts at WYSIWYG [05:05:22] WYSIWYG is pretty cool, though. [05:05:24] Werd: sure, but dumbing it down in the UI is bad.. [05:05:26] I have it running on my test wikis. [05:05:39] because then you just make it more complicated in the backend, the raw edit page [05:05:46] there is no incentive to simplify it at its core [05:05:56] Ya, but since you're trying to work with both HTML and WikiText you often get bugs [05:06:09] (per the Front Page reference above, ever tried to edit a created by Front Page?) [05:06:33] The sane part about forms, is it doesn't really go anywhere away from WikiText, it merely sections off the WikiText into a set of sections [05:06:56] well, point [05:07:12] but counterpoint: people might get used to it and not be able to edit on a wiki without it [05:07:34] (whereas currently most mediawiki installations, even with really freaky UI and parser extension tags, and custom edit buttons, is pretty much the same) [05:07:52] Splarka: ^_^ You need a good person to be able to maintan the form... you site won't even last if at least one person isn't above average [05:08:36] SF Lets you use a form to create the form... but modifying it? forget it [05:08:54] Gives you the baseline, makes you understand it to do anything more [05:09:14] Dantman|FS: then that should change. [05:09:19] You should be able to modify the form with SF. [05:09:34] arr, he said it again [05:09:45] *Splarka wanders off to buy a second shrubbery [05:09:47] A form is primarily wikitext, that's actually counterintuitive [05:10:01] *Lady_Aleena giggles. [05:10:13] The nice part about it, is you are free to create your own interface using all the css, tables, and whatnot you want [05:10:42] yeah, that's nice. [05:10:49] If you try to make it so you can edit the form with a form, you lose every bit of that ability and dumb it down to just that... a "stupid ui" [05:11:03] Dantman|FS, if editing a form to make a form is so much trouble, how about editing a form to make a form to make a form. it's a 3GF (3rd Generation Form). We can leverage the synergies to break into the emerging 3gf market! [05:11:17] *Werdna throws rocks at kim__ [05:11:35] do I make a good phb? [05:11:49] I need to go get a haircut soon, I could ask them to make pointy bits :-P [05:12:32] ^_^ one of these days, I need to make it so that an infobox edit form can be contained inside of the infobox itself [05:12:58] ;) ie: Click an edit button on the infobox... and the actual infobox's rows become inputs [05:13:11] http://www.lou-and-andy.com/transcripts/petshop/ pet shop shop [05:13:39] Dantman|FS, that would actually be good! [05:13:47] ^_^ Yup [05:14:07] I want to buy a pet shop shop shop! [05:14:23] Box styles + iBox + Forms + iBox Forms module [05:14:29] *kim__ ducks for the next round of rocks [05:14:48] mmm... box styles [05:14:50] Dantman|FS, actually that could be combinable ... I got me an xml database backend... [05:14:59] and at some point I'd like to make purdy views [05:15:08] would your forms be able to help? [05:15:19] Hmmm? [05:15:45] I have $semi-arbitrary-database... [05:15:53] class="box table colored bordered innerbordered style-basic" <- My equivilant of "wikitable" heh ^_^ [05:15:54] it returns data in xml format [05:16:03] ut oh! [05:16:07] ^^;; [05:16:31] table.table {} ? [05:16:35] well, how it returns data is not that relevant... but certain fields could be assigned wikivariable-names [05:17:40] hrm [05:18:46] Splarka: http://anime.wikia.com/index.php?title=Template:No_license&action=edit [05:19:19] 14(INVALID) External links should have higher precedence in parser - 10https://bugzilla.wikimedia.org/show_bug.cgi?id=15296 +comment (10roan.kattouw) [05:19:34] The type- is legacy though... I want to change all those type- into style- [05:19:46] I want to support a scheme- for colorschemes [05:20:22] table, message, nav, navtable, block, infobox, trinav, etc... [05:20:39] svn up time [05:20:58] defines a type of box... ie: what kind of margins and other positioning the box gets [05:21:08] ^_^ oh right... class="box titleicons" [05:21:26] ;) Though one of these days, I intend to turn titleicons into an extension [05:21:33] ... [05:21:43] Hmm... nowait, {{#titleicon:...}} [05:21:44] 14(INVALID) Cannot Use Parser Inside EditPage::showEditForm:initial Hook - 10https://bugzilla.wikimedia.org/show_bug.cgi?id=15298 +comment (10roan.kattouw) [05:26:39] 03brion * r39934 10/trunk/extensions/gis/Geo.alias.php: fix bad file [05:27:49] hi everybody [05:28:57] hi all. does MW keep a special index of all pages that it uses when 'search' is run? [05:29:16] i'm wondering if theres a way to force-update said record if it does exist [05:31:06] i have this kind of url's: http://localhost/drux/index.php/MediaWiki:Sidebar [05:31:20] how can i hide the index.php piece [05:31:20] ?? [05:31:58] BioVirus, http://www.mediawiki.org/wiki/Short_URL [05:33:19] thnks sasa [05:39:17] my second question is probably just as aquard, so i'll give it now too: i have a bunch of pages which dont show their content. the page title is there, but all the content is hidden until the page is editd+resaved. can anyone offer a suggestoin on how to fix this? [05:39:37] i suspect its to do with the way i upgraded the database(s), but i'm not sure [05:41:47] vk5foss: php maintenance/rebuildtextindex.php [05:41:57] That'll get the search index [05:42:05] 03catrope * r39935 10/trunk/phase3/ (RELEASE-NOTES includes/api/ApiQueryBase.php): [05:42:05] API: Go back to using the good old str_replace() hacks rather than Title methods [05:42:05] in ApiQueryBase::titleToKey() and keyToTitle(). Error handling was awkward and [05:42:06] the Title methods over-normalize the input, causing bug 15275 (apprefix ignores [05:42:06] spaces at the end) [05:42:16] 03(FIXED) apprefix parameter ignores spaces at the end - 10https://bugzilla.wikimedia.org/show_bug.cgi?id=15275 +comment (10roan.kattouw) [05:42:29] when I print the printable version of a MediaWiki page, the images (aligned with frame|center) are left-aligned instead of centered. how can I edit the CSS so that the printable versions of the pages will center the images? I've tried adding margin-left and margin-right: auto to div.thumbinner in monobook/main.css, but the images still left-align [05:43:00] as for the other issue... you could try attempting using php maintenance/purgeList.php and feeding it a list of all the pages on the site [05:46:03] Dantman|FS: i thought i was running that, i'll look again, thank you. [05:47:17] Agh... r39935 evil... [05:47:37] :/ I'd like to move away from all those str_replaces in the code [05:47:51] The more people use those, the harder it is to rewrite the title backend to work right [05:48:24] ...wait, not a multibyte function ? [05:48:58] It's only space<->underscore conversion [05:49:15] oh [05:50:50] :/ However that function itself looks screwy [05:51:35] creating $t using $title, then checking !$t, and after that if it fails, testing for $title == '' and returning '' if that's the case [05:51:46] did look* [05:51:58] 03catrope * r39936 10/trunk/phase3/includes/api/ApiQueryBase.php: [05:51:58] Follow-up for r39935: re-fix bug 14651 by making the first letter uppercase if [05:51:58] needed in keyToTitle(). Code stolen from Yuri in r17039, who removed the [05:51:58] functionality without explanation in r17096. So much for today's history lesson. [05:52:00] Sane implementation's first check would be if( $title == '' ) return ''; [05:52:26] then you don't even create that pointless title object you wouldn't make proper use of anyways [05:53:28] Agh catrope... not only are you making things ugly.. you're breaking functionality [05:53:43] $wgCaptialLinks isn't a boolean anymore, it's a per-namespace array [05:53:58] :/ Use the proper MWNamespace function to test [05:55:07] <_wooz> lo [05:56:02] Ack damit... that's misuse of a function [05:56:32] titleToKey and keyToTitle shouldn't be used for converting prefixes [05:56:49] of course they're going to break prefixes... they're meant to handle full titles [05:57:02] I forgot how to make a faux category box. Please remind me. [05:58:13] why would ya want to? [05:58:16] *Dantman|FS debates if he shoult revert [05:58:29] Just to make something look like it has categories. [05:58:52]

[[Special:Categories|Categories]]: [[:Category:Foo|Foo]]

[06:00:12] Thanks! [06:02:57] *Lady_Aleena is grateful for Splarka showing her class="icon-click" since it saved her a lot of {{#ifexist}}ing on 2 pages. [06:03:20] silly LA [06:04:01] Splarka, the other thing still has the {{#ifexist}} problem since I can't use icon-click with {{Click}}. [06:05:43] Dantman|FS: thanks a lot, the search index is back :) [06:06:30] i'm about to look at purgeList.php to try and undestand what it does. [06:06:46] it has a scary name [06:10:00] 03aaron * r39937 10/trunk/extensions/FlaggedRevs/specialpages/RevisionReview_body.php: slight transaction tweak [06:10:18] purge list merely takes a list of titles, and does the same thing that using ?action=purge on them [06:10:34] It merely cleans out the cache for that page so that it's updated the next time you use it [06:11:43] hm. [06:26:26] TimStarling: http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/api/ApiQueryBase.php?r1=39936&r2=39645 Was done to fix bug 15275, however it's poor coding (Duplicating part of Title inside of the API), breaks capitalization, and honnestly, it's altering good functions to 'fix' something when really the issue is that the functions are being misused... [06:26:35] Think I should revert? [06:42:56] How many times can a person vote for a bug? [06:48:02] Lady_Aleena: once, on wikimedia [06:48:27] Werdna, I meant on bugzilla. [06:48:39] yes, on Wikimedia's setup of bugzilla. [06:49:59] Darn it, I was thinking of using my remaining 998 votes on 3 bugs. [06:50:17] 04(REOPENED) internal_api_error_DBQueryError when API action login - 10https://bugzilla.wikimedia.org/show_bug.cgi?id=15267 (10damien.flament) [06:50:44] 03dantman * r39938 10/trunk/phase3/includes/api/ApiQueryBase.php: (log message trimmed) [06:50:44] Revert 39936 and 39935; [06:50:44] This 'fix' is merely a bad workaround and creates more issues rather than simply fixing. [06:50:44] A) Part of the Title class is being /duplicated/ meaning more bugs are going to show up when someone improves stuff inside Title and doesn't know stuff is duplicated here. [06:50:44] B) This change breaks cases as $wgCaptialLinks is now a per-namespace array, not a boolean. [06:50:46] C) This is the wrong way to 'fix' the issue, titleToKey and keyToTitle are meant [06:50:48] to handle full titles, not prefixes, the issue is not that they break prefixes, [06:54:03] 03(NEW) diff messages i18n problem - 10https://bugzilla.wikimedia.org/show_bug.cgi?id=15299 minor; normal; MediaWiki: History/Diffs; (alexander.sigachov) [06:57:31] 03dantman * r39939 10/trunk/phase3/includes/api/ApiQueryBase.php: [06:57:31] ApiQueryBase::titleToKey and ApiQueryBase::keyToTitle; [06:57:31] Don't bother constructing a title object when the $title/$key is ''. (Why were [06:57:31] we doing this check after creating the title object, there's no point in even [06:57:31] creating a big object if we're just going to check the old string we already had [06:57:34] to see if it's empty) [06:57:36] And as a bonus, use trim() so that user input such as ' ' does not dish out an error (There really isn't much difference between "&title=" and "&title= " if one shouldn't output an error, why should the other?). [07:00:04] 04(REOPENED) apprefix parameter ignores spaces at the end - 10https://bugzilla.wikimedia.org/show_bug.cgi?id=15275 +comment (10dan_the_man) [07:01:34] *Dantman|FS puts on a vibber of the day cap and returns to his anime [07:11:18] hi, i'm having trouble linking to another wiki page ( http://www.mediawiki.org/wiki/Extension:EmbedVideo ) -- i try doing [[:mw:Extension:EmbedVideo|EmbedVideo extension]] but it's not linking to the other wiki at all; what am I doing wrong? [07:19:09] *MZMcBride stares at bug 15296. [07:20:09] MZMcBride was that refering to me? [07:20:16] Not at all. [07:21:07] hmmm.. [07:22:44] Yawg81: Is mw: inside of your interwiki table? [07:22:59] i'm just installing the SpecialInterwiki extension [07:23:01] to make sure it is [07:23:02] Also, try it without the : [07:23:09] i tried multiple variations [07:23:16] it always tries to create a new page on my wiki [07:23:17] 03(mod) External links should have higher precedence in parser - 10https://bugzilla.wikimedia.org/show_bug.cgi?id=15296 (10N/A) [07:23:31] Ok, ya, then it seams like the mw prefix isn't in the table [07:23:35] or at least not in the cache [07:23:36] but i'll check the table right now [07:23:41] it must be something like that [07:25:29] and indeed.. it's not there [07:25:41] it's pretty strange that the mediawiki installation doesn't include mw by default? [07:26:02] or there might be a proper reason for not including this in default install? [07:26:51] I think we try to not force too much on people. [07:29:39] thanks btw! [07:30:48] 03(NEW) Certain well-formed page names cannot be removed from a watchlist - 10https://bugzilla.wikimedia.org/show_bug.cgi?id=15300 minor; normal; MediaWiki: Special pages; (falcon) [07:34:00] 03(mod) Improve organization of "other projects" in SiteMatrix list - 10https://bugzilla.wikimedia.org/show_bug.cgi?id=14949 (10fantasy) [07:46:17] 03(NEW) there are problem in russian edition - 10http://bugzilla.wikimedia.org/show_bug.cgi?id=15301 15enhancement; normal; MediaWiki: Page editing; (midao) [07:53:14] Darn it, I am trying to set up a cloak, but I am at a loss of how to get the edit summery thing to show up on a null edit. [07:54:05] Is there any way to call [[MediaWiki:Pfunc time too long]] content when page do not exist but is translated? I mean when calling: {{Pfunc time too long}} output is "[[Template:Pfunc time too long]]" and {{int:Pfunc time too long}} output "" [07:55:10] But viewing [[MediaWiki:Pfunc time too long]] having content "Error: too many #time calls" [07:57:17] 03aaron * r39940 10/trunk/extensions/LiquidThreads/LqtFunctions.php: [07:57:17] Fix case: [07:57:17] Fatal error: Call to a member function getTitle() on a non-object in C:\Server\xampp\htdocs\MW\extensions\LiquidThreads\LqtFunctions.php on line 88 [08:10:23] is there an easy way to show all external links on a wiki page? [08:10:28] like a special page or something? [08:10:51] of one page only? [08:10:56] of the whole wiki [08:11:35] i need to alter my wiki, because i'm merging static php pages to my wiki system.. i'll remove the static pages, which implies I'm having lots of soon to be dead links to external sites [08:11:39] special:linksearch? [08:11:50] it would be nice to have a list of all external links on my wiki, for easy editing [08:12:32] LinkSearch could be a nice extension, indeed, checking it out right now [08:24:59] apparently when discussed #elsewhere this is not possible... should I file a enhancement bug for ParserFunctions (or do somebody knows if there is already related for this)? [08:34:02] anyone working on SMW? try #semantic-mediawiki [08:34:29] Agony: What would it do? [08:38:58] MinuteElectron: what would what? {{Pfunc time too long}} output [[Template:Pfunc time too long]] (not exists) so {{#mediawiki:Pfunc time too long}} should output "Error: too many #time calls" (ie. whatever system message containing). This do not work ATM because page (in database) do not exist (even it is implemented to translations) [08:40:53] Agony: [08:40:56] #elsewhere [08:42:25]