[00:01:02] *Duesentrieb eyes Skizzerz [00:01:14] *TimLaqua grins [00:01:32] Skizzerz: it doesn't matter what type of quotes are used in that case. [00:02:07] Skizzerz: also... wiki markup? huh? [00:02:22] wfmsg wont' process wikitext [00:02:30] single is generally the right thing. but it doesn't matter in this case anyway. [00:02:34] hmm... maube you could get clever about it... [00:02:58] Skizzerz: and you want to be able to enter it into the system message as wiki text? and need html to putput it? [00:03:01] I suppose if you ran the text through the parser after you got it from wfmsg on the php side. [00:03:20] Skizzerz: use wfMsgWikiHtml [00:03:47] of, i guess, you can also use wfMsgExt - it has a gazillion modes. [00:04:02] *Duesentrieb pokes Sasoriza [00:04:46] *Sasoriza sits up [00:05:31] read back [00:06:27] Sasoriza: that'S the most powerful variant, but tricky to use. use wfMsgWikiHtml [00:06:35] "take wikitext, give me html" [00:06:52] read up on the everal variants of wfMsgXXX in GlobalFunctions [00:07:03] o_O [00:07:13] err... [00:07:46] you are using the message in ImagePage.php, right? so, it has to be turned into html at some point, so it can be sent to the browser... [00:08:24] now, depending on how things are handeled in the code, this might be done later on, so you would want to keep wiki text. but i doub it - especially since you said that wikitext didn't work when you used wfMsg [00:11:38] read up on all the options of that thing, then. [00:15:22] Sasoriza: what's that? [00:15:23] Sasoriza: huh? implement what? [00:16:31] and... what's that? [00:21:43] where is he!!!! [00:23:16] no [00:23:18] roan [00:23:32] the api dude [00:27:50] Sasoriza: extension dev is crazy [00:28:35] ;-) I mean the process/control [00:28:52] I think MW does an excellent job of making it easy to develop extensions [00:31:27] *siebrand nods. [00:35:17] Sasoriza: lol - http://rafb.net/p/uGTSVA67.html [00:35:33] *Skizzerz tries to fix it when it breaks... unless it's MultipleUpload... I'm totally lost there [00:35:57] extensions don't break... [00:36:01] silly goose. [00:36:19] *siebrand agrees with Skizzerz on the MultipleUpload thingie. [00:36:27] what's it do? [00:36:33] er... is there a bug report? [00:36:59] indeed [00:38:43] no, they become incompatible [00:38:46] ;-) [00:39:12] Sasoriza: look at bizzwiki. ;-) [00:40:06] yo [00:40:52] i'm pretty sure bizzwiki has a class called ExtensionManager [00:41:07] some unassembled, some on order, some still on a truck from florida :) [00:42:25] I'm really not a fan of the bizzwiki framework - I don't like dependencies. [00:43:10] *Skizzerz doesn't either [00:43:30] but then I feel bad rewriting his extensions to yank out the dependencies [00:43:38] w/e. [00:44:14] Skizzerz: you could easily make a LoadExtensions hook [00:45:52] Skizzerz: well, there's nothing we can do about those [00:46:42] mm.... dinner... [00:46:55] alnokta: not working? it was until recently :) [00:47:05] but not from the web. intentionally. [00:47:46] Sasoriza: because that would be dangerous [00:48:02] Sasoriza: as has been noted before, changing php scripts in any way from the web is a nono [00:48:18] alnokta: o_O... very odd. [00:48:27] *Sasoriza wants functionality! [00:48:34] !sidebar | ponyofdeath [00:48:34] --mwbot-- ponyofdeath: To edit the navigation menu on the left, edit [[MediaWiki:Sidebar]] using its special syntax. For more details, see . [00:49:27] Sasoriza: it's impossibel to do this safely from the web. per definition, installing an extension means getting the system to execute php code you provide. which is dangerous. so it's a nono. [00:50:26] alnokta: file a bug report, maybe i'll remember to look into it :) [00:50:56] anyway, i need to go to bed. [00:50:59] n8 ppl [01:04:27] NobodHere: can you try setting $wgDebugRedirects = true; in LocalSettings.php, then try editing a page? [01:04:43] this may show you error messages on edit that are being hidden by the redirect back to the title page [01:11:43] NobodHere: normally yes [01:12:02] alnokta: looks like something isn't quoted right [01:12:04] i'll take a peek [01:13:15] ay ay [01:13:17] yes no quoting [01:15:46] anyone familliar w/ CommentPress? [01:16:47] *alnokta svn ups [01:18:01] hm [01:18:16] NobodHere: is your site publicly accessible? [01:18:31] can you give a url to it so i can poke it? [01:19:00] ok NobodHere your problem is probably that mysql's fulltext search engine defaults to ignoring words shorter than 4 characters [01:19:06] so "ISV" won't turn up in searches [01:19:40] looks like a small wiki, safe to drop down to 2 character indexing. [01:19:45] if you control the host, you can tweak the setting and rebuild the index... there should be a link to the mysql docs from the faq [01:20:18] if it's a shared host and you can't change the mysql server configs, then my workaround recommendation would be to make redirect pages for key terms like that [01:20:30] those'd still come up as exact-title matches in most searches [01:26:56] AaronSchulz: if you think it's ready, then yes. :) [01:27:07] right now i'm still catching up on svn changes, i'll try and be through those tonight [01:27:50] ok; whenever you guys are ready [01:30:28] :) enjoy [01:38:26] maybe one thing at at ime for now ;) [01:46:56] alnokta: i've seen worse :) [01:47:10] io_error: i think we recently killed wfQuery() [01:47:20] a couple versions back [01:47:36] get a database object (with wfGetDB()) and call functions on it [01:47:48] if you build raw sql queries (not recommended), then the query method would be appropriate [01:48:01] but it's nicer to use the query-builder functions [01:48:06] yes since ages and ages [02:13:51] io_error: you find what you're looking for? [02:14:12] k [02:16:10] ;-) I find things are pretty consistent lately. [02:16:49] or maybe an irc room full of extension writers [02:17:08] that'd be this one. [02:17:21] *io_error plants tongue firmly in cheek [02:18:28] speaking of queries, has anyone used the query builder f/ subqueries? [02:18:39] i'm just not familliar w/ the syntax for it [02:20:24] you're getting newlines in *after* tidy? [02:20:55] so you're like appending to the $text var that is passed? [02:21:33] ya, brion changed it to dramatically fail instead of "dying quietly" iirc [02:21:35] ;-) [02:22:07] I like your style. [02:22:22] darkcode: offhand it looks like not all the section names are filled out [02:22:43] and yet... http://en.wikibooks.org/wiki/MediaWiki:Gadget-section-admin-gadgets is sitting right there [02:22:44] curious :D [02:23:16] hmmmm [02:23:20] seems happier now after a reload [02:23:23] mysteeeeeerious [02:23:23] and then you asked it to tell you and it said your extension wasn't playing nice? [02:23:56] io_error: when an extension doesn't return anything, it halts further hook execution [02:28:19] io_error: you can override the per-db key part in current versions i think (default is table prefix and db name) [02:28:22] some config var [02:28:45] the rest of that isn't sensitive info, but is all available (user prefs, page id) [02:28:56] *io_error is one paranoid mofo. [02:29:27] io_error: you could just pop in to ParserCache.php and make it go away. ;-) [02:29:49] :D [02:31:28] thx. brion, should that be an option? [02:31:54] TimLaqua: $wgInformationDisclosure = false? :) [02:32:01] exactly! [02:32:07] hehe [02:32:07] darkcode: about once a day when i'm up to date on code review, which i'm not right now [02:32:16] *brion is at december 11 :P [02:33:34] mmmmaybe :) [02:42:19] AaronSchulz: hmm yes, it probabyl should :) [02:50:40] dinnertime [03:18:57] *AaronSchulz does like the idea of transcluding pages out of MW: namespace [03:55:29] darkcode: almost [03:55:57] the syntax was actually {{msg:name}}, the short form {{name}} came in with the template namespace [03:56:17] and the mediawiki namespace was editable at that time, we just had the installer protect all system messages [03:57:36] AaronSchulz: ok [03:57:45] what does it need? [03:58:44] I didn't make titleparts [04:00:32] ALTER TABLE /*$wgDBprefix*/page [04:00:39] hmm [04:01:12] I guess it'll only take seconds on testwiki [04:01:49] less than a second [04:02:48] there's a whole lot of changes in BASE:HEAD [04:06:08] I was pondering it in this channel just a few days ago [04:06:21] just at the pipedream stage though [04:08:49] AaronSchulz: anything is viable in a pipedream [04:09:08] *AaronSchulz things of the Many Pipedreams [04:09:34] TimStarling: oh, just use your consciousness to cause pipe-dream collapse ;) [04:11:44] AaronSchulz: is it ok in your opinion to run FlaggedRevs HEAD with r28384 of the core? [04:12:01] *AaronSchulz checks [04:12:54] 28258 was the last important thing methinks [04:12:57] so that should work [04:15:16] $this->notes = (FlaggedRevs::allowComments() && $wgUser->isAllowed('validate')) ? [04:15:16] $wgRequest->getText('wpNotes') : ''; [04:15:30] you don't need to use a wp prefix on form variables anymore [04:15:44] that was a hack from when MediaWiki required register_globals [04:16:06] i.e. before it was even called MediaWiki [04:16:40] *darkcode loves running php with register_globals disabled [04:16:46] yeah, but I like how 'wp' looks :) [04:17:18] 'This feature is DEPRECATED and REMOVED as of PHP 6.0.0. Relying on this feature is highly discouraged.' [04:17:30] $this->upprovedTags [04:17:34] is that meant to be a word? [04:18:05] lol, "unapproved" [04:19:16] are you telling me you misspelt unapproved 12 times, each time in exactly the same way? [04:20:33] I do cp a lot, so it wouldn't be a surprise [04:21:38] darkcode: actually, if I make a mistake, in that same time period, it will probably be made again [04:33:02] is it random spam? [04:33:22] ConfirmEdit or ConfirmAccount might help [04:33:33] if( !defined( 'FLAGGED_CSS' ) ) [04:33:33] define('FLAGGED_CSS', $wgScriptPath.'/extensions/FlaggedRevs/flaggedrevs.css' ); [04:33:37] that's a really bad idea [04:33:54] what if the user changes $wgScriptPath after they include the extension file? [04:34:13] http://www.mediawiki.org/wiki/Extension:ConfirmEdit [04:34:24] there a fuzzy catpchas too [04:35:30] the indenting in FlaggedRevs.php is all over the place [04:37:08] do you have vim, Aaron? [04:37:19] I don't think so [04:37:27] I used to use a crappy editor though [04:37:46] go to special:version [04:38:35] TimStarling: I use Programmer's Notepad 2 now [04:38:46] stiv2k: thats fine for the extension [04:39:14] AaronSchulz: you might want to start with a global search and replace, four spaces for a tab [04:39:46] that will stop the arrows lining up properly though, so you'd have to go back and fix them [04:39:47] yuck...the old programs "auto-tab" did stuff like that [04:40:34] 351 occurances replaced [04:40:37] ;) [04:42:09] some lines were starting with 8 spaces for two indent levels [04:42:16] some with two tabs, some with 4 spaces and a tab [04:42:45] it was a bit random [04:43:08] and kind of obvious when you look at the file in an environment where a tab is 8 spaces [04:43:39] if( !$article || !$article->getId() ) [04:43:39] return NULL; [04:43:42] $key = 'sv-' . $parserCache->getKey( $article, $wgUser ); [04:43:42] # Get the cached HTML [04:44:40] maybe he was writing a http://en.wikipedia.org/wiki/Whitespace_(programming_language) program instead of php [04:45:37] Splarka: no it was dev-PHP "smart" auto-tab thing [04:47:16] TimStarling: not sure what the !$article is doing [04:47:54] it's harmless, I was just complaining about the spaces [04:50:58] hi brion [04:51:48] wtf [04:51:54] if( $user->getID() ) { [04:51:54] $oldgroups = $user->getGroups(); [04:51:59] two tabs per indenting level? [04:52:00] 'special:userrights' shows as available to all users now [04:53:26] yo [04:53:42] AaronSchulz: in HEAD? [04:53:54] yeah [04:53:55] ? [04:54:03] doesn't seem to be available on wikipedia [04:54:10] "The action you have requested is limited to users in the group Stewards." [04:54:42] brion: I'm enabling FlaggedRevs on testwiki [04:55:03] werdna re-did userrights [04:55:06] just doing a quick review to work out what the deployment issue is [04:55:23] whee [04:55:34] http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/SpecialUserrights.php?r1=27735&r2=28650 [04:56:13] brion: ok, but there are not options [04:56:25] but it feels weird using userrights as an IP :) [04:56:35] o_O [04:56:45] that shouldn't be possible :) [04:56:52] for one thing it would break the log :D [04:57:09] "member of" and "available" are empty [04:57:37] which wiki? [04:57:51] so Special:Makevalidate grants and revokes both editor and reviewer, right? [04:58:17] yes [04:58:32] MZMcBride: my testwiki [04:58:34] don't you think it's a little bit oddly named? [04:58:40] I mean, it's not exactly making validates is it? [04:58:46] ah, ok [04:58:49] perhaps it's making validators [04:59:04] better still, we could draw on the english language for our inspiration [04:59:14] and call it "Special:MakeReviewer" [05:01:53] I see you have used nouns for the group names [05:03:46] ugh, time to rename all those lang files and search and replace :( [05:05:48] $specialPageAliases['aaronese']['MakeReviewer'] = 'Makevalidate'; [05:06:08] $specialPageAliases['en']['MakeReviewer'] = 'Make_reviewer'; [05:07:18] the language files should be merged [05:07:22] they all have to be loaded anyway [05:08:34] *AaronSchulz goes crazy [05:08:54] so the CategoryTree language method is no better? [05:09:23] than loading one big file [05:09:26] thing is, any of those languages can be requested at any time [05:10:03] I don't know, I guess we could just break that feature [05:10:11] for certain extensions at least [05:10:42] obviously it's already broken for CategoryTree [05:13:07] the split language file is only going to be at best a stopgap measure [05:13:55] because ultimately I'd like to migrate everything over to something resembling $wgExtensionMessagesFiles, and make it fast [05:16:03] am I just talking to myself? [05:19:25] I guess so [05:21:07] hehe 169 people in the room; someone's always reading... [05:21:09] man I wasted a lot of time separating those lang files out [05:21:26] TimStarling: it just sucks to then put them back in one...argh [05:21:36] well I was just saying that you don't have to [05:22:08] but you can hardly claim it's more efficient when you're loading the special page messages unconditionally in an extension setup function [05:22:18] couldn't you defer that? [05:24:32] exception 'DBQueryError' with message 'A database error has occurred [05:24:32] Query: SELECT fr_rev_id,fr_user,fr_timestamp,fr_comment,fr_quality,fr_tags FROM `page`,`flaggedrevs` WHERE page_namespace = '3' AND page_title = 'Tim_Starling' AND (page_ext_stable = fr_rev_id) LIMIT 1 [05:24:32] Function: FlaggedRevs::getStablePageRev [05:24:32] Error: 1054 Unknown column 'fr_tags' in 'field list' (10.0.0.234) [05:25:21] that's a bit more serious than message files [05:25:46] whee [05:26:43] don't tell me, you just added the field in the last hour [05:26:53] shortly after I added the table on testwiki, right? [05:27:39] fr_tags is the newest field, but it is not *that* new [05:28:14] *AaronSchulz wonders wtf $wgmakevalidatePrivileged is for [05:29:22] alright, so I'm dropping flaggedrevtags, and adding fr_tags, right? [05:30:21] done [05:30:36] yep [05:35:44] wtf? [05:35:51] Saved in stable version parser cache with key sv-testwiki:pcache:idhash:12620-0!1!0!default!!test!2 [05:36:18] that's the parser cache for the wiki with ID "sv-testwiki" [05:36:33] you want testwiki:sv-pcache:... [05:41:01] *AaronSchulz wonders when a message was changed to reference {{MediaWiki:Makevalidate-page}} [05:42:21] that's ok, you ignore me, and I'll fix it [05:44:29] ok, I'll some search and replace on that key to get that right [05:46:15] why did it reference the promotion page? [05:46:29] whatever...I fixed it for en...all I give a shit about for now [05:46:34] that and this parser key [05:47:54] TimStarling: can wikis have IDs with colons? [05:48:50] I said I'd do it [05:50:02] oh, I though you were being sarcastic ;) [05:51:26] Hmm, earlier on test.wp rc I clicked "snow new changes starting from"... and so was on Special:Recentchanges&from=20071220053418 -> 'Below are the changes since 21:34, 19 December 2007' ... [05:51:51] oh, nm am blind [05:58:04] mmm, not quite right [05:59:05] http://test.wikipedia.org/w/index.php?title=Sandbox&diff=29616&oldid=29516 [05:59:15] thats some sub-par vandalism ;) [06:00:12] is it meant to show the current draft on action=purge? [06:03:02] I honestly never cared, and forgot about it, but it probably should not just be showing the current one no matter what [06:03:11] *AaronSchulz looks [06:05:49] I've granted makereviewer and makevalidator to all users on testwiki [06:09:45] eww, global $action [06:10:07] does that officially exist now, or is it still an accident? [06:10:44] probably for b/c, but it is used everywhere [06:11:15] it was originally a holdover from register_globals [06:11:28] and it only continued to exist because it happened to be used on the file level [06:12:12] $action = $wgRequest->getVal( 'action', 'view' ); [06:12:15] $wgTitle = $mediaWiki->checkInitialQueries( $title,$action,$wgOut, $wgRequest, $wgContLang ); [06:12:46] it's not a convention I would have chosen to reproduce [06:12:56] $wgRequest->getVal('action') works just as well [06:13:47] less likely to break for odd entry points [06:19:52] are you going to announce it now? [06:21:59] announce? [06:22:11] hmm [06:24:02] TimStarling: I'm still amused at being able to access Special:Userrights as an IP, though I can't actually do anything from there [06:24:17] complain to Werdna [06:24:30] complain? why? It's funny :) [06:24:45] presumably that's why you want FlaggedRevs on test.wikipedia, to promote it [06:25:11] sooner or later it'll have to be enabled on the large wikipedias [06:25:17] well, I'd like to get people to be playing around [06:25:24] playing myself is not as much fun [06:25:26] and that'll need a lot of promotion [06:25:29] *with [06:25:38] it would help to have some old dumps though [06:26:43] *Werdna reads backscroll [06:32:40] having the 'current groups' be empty is not really expected behavior though [06:33:46] hmm, that would be better, but better still, if you can't do jack at the page, it feels odd for it to be available at all [07:01:28] see includes/zhtable [07:01:35] I'll find you a URL... [07:02:45] http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/zhtable/ [07:03:32] particularly this: http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/zhtable/README?view=markup [07:05:14] vader897: apply this patch: http://bugzilla.wikimedia.org/show_bug.cgi?id=12122 [07:05:25] then run maintenance/dumpHTML.php [07:06:52] well, you could write a script to do that [07:10:36] no, it stores it as typed [07:10:47] then converts to whatever variant the user requests [07:11:13] so the source text is, as I understand it, typically a hybrid [07:11:48] amerinese: I mean as the user entered it [07:11:58] so it depends on the policies of the wiki [07:12:15] and I'm told that the chinese wikipedia is very permissive about how people write things [07:12:40] that may have changed lately, but that's how it was a while ago anyway [07:12:53] that's why we have the converter [07:14:03] is that so? [07:14:25] maybe you should go to zh.wikipedia.org and try it out [07:15:14] set your preferences to simplified, then try editing an article [07:16:15] darkcode: ping [07:19:18] JohnMichael: what's your wiki's URL? [07:20:29] vader897: you won't be able to do it on a shared web host, if that's what you've got [07:23:08] JohnMichael: what's your wiki's URL? [07:24:46] please do [07:27:32] mmm, that manual is a path to query rewrite rule, plus signs will be broken [07:29:18] you're not following the manual correctly [07:29:32] it says that your index.php should be in a directory called "w" [07:29:41] yours is in a directory called "wiki" [07:29:51] you should move your whole wiki from "wiki" to "w" [07:29:57] and leave "wiki" just for articles [07:38:10] maybe IRC wasn't the best choice of forum for a guy whose internet connection drops out every 2 minutes [07:39:10] *AaronSchulz giggles [07:46:57] *AaronSchulz wonders what Raymond_afk is up to [07:47:14] it's more of a module than a script [07:47:21] the relevant code is in languages/LanguageConverter.php [07:47:26] mostly [07:47:47] it also does serbian latin/cyrillic conversion [07:48:02] with different tables obviously [07:51:07] AaronSchulz: announcing on de.wp: http://de.wikipedia.org/wiki/Wikipedia:Projektneuheiten#20._Dezember [07:51:17] TimStarling: http://test.wikipedia.org/w/index.php?title=Meow&stable=1 [07:51:26] the ogg doesn't want to play :( [07:51:34] only for the stable one [07:52:26] how are you writing out the ParserOutput? [07:54:11] ewww [07:54:17] $wgOut->mCategoryLinks = array(); [07:54:17] $wgOut->addCategoryLinks( $parserOut->getCategories() ); [07:54:17] $wgOut->mLanguageLinks = array(); [07:54:17] $wgOut->addLanguageLinks( $parserOut->getLanguageLinks() ); [07:54:18] wrongly [07:54:32] use $wgOut->addParserOutput() [08:04:30] I have things to do [09:39:49] http://comics.go-girly.com/filler/girly_timeforlove.gif "never trust wikipedia" *snicker* [11:37:12] enwp uses JS at http://en.wikipedia.org/wiki/MediaWiki:Common.js (and some CSS and templates) [11:37:41] http://en.wikipedia.org/wiki/Wikipedia:NavFrame for overview [11:37:47] hey Splarka :) [11:37:52] rar [15:43:06] ;-) [15:43:08] classy. [16:10:55] wfSpecialUserlogin() [16:26:15] Nikerabbit, my original plan was just to change wfMsgHTML and wfMsgExt(...'escape'...), but Brion pointed out there are corner cases where that breaks. Like outputting raw JavaScript: you don't want document.write( '' ); to . . . hmm . . . actually wait, we do. [16:26:18] *Simetrical scratches head [16:26:33] Uh, yeah, I dunno. [16:26:55] Maybe we should just make it, I only did it differently because I was vaguely afraid of incurring Brion's wrath. :) [16:27:09] *just make it the same [16:27:22] *brion rumbles [16:27:29] who dares invoke my wrath? [16:27:41] hehe [16:27:55] *Simetrical hides [16:28:12] *Simetrical goes off to study for his Chemistry test that he has to leave for in . . . about one hour. [16:28:17] 'escape' is only used for html output (is it? if not, maybe fix those cases) [16:29:51] something in UserMailer [16:37:45] how do I make svn ignore everything changed in a file? [16:37:56] in git, there's git ignore for that [16:37:56] ignore or revert? [16:37:59] ignore [16:38:12] it's a data file of unilinky (the seendb...) [16:38:21] tell me too when you know [16:38:29] as you can imagine, it gets B.I.G. (current >20MB) [16:39:18] HardDisk_WP: there's the svn:ignore property. see svn help propset [16:39:22] you mean deleting its content? [16:39:25] note that it's per directory (non-recursive) [16:39:46] :) [16:39:47] you can also set properties from a file - i find it handy to maintain my svnignore list in a file [17:19:02] ieuan: sure, just set $wgEnableUploads = true; in LocalSettings.php [17:35:00] ieuan: by default, the 'images' subdirectory in your wiki [17:57:21] just committing work done before I go to bed [17:57:51] and I think I'll have to do some christmas shopping tomorrow, so that commit might be it for a while [17:57:58] nighty night [17:59:07] what do you think about the idea of moving dumpHTML to an extension? [17:59:15] I guess the job control stuff could go there too [17:59:34] it's possible now because I did a 3 line patch to Skin.php to make it possible to define skins in extensions [17:59:58] we can backport that to 1.11.1 in order to fix 12122 [18:05:04] good night [18:05:27] ludc: particular pages or everything? [18:06:08] ooooo-kay? [18:06:29] good luck to you too ludc [18:26:40] brion: can you SVN up flaggedrevs on testwiki? [18:27:24] moment, in the midst of something [18:28:27] !r 28713 [18:28:27] --mwbot-- http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=28713 [18:29:25] AaronSchulz: just the extension? [18:29:31] yeah, but wait... [18:29:34] ok [18:29:52] review submission is acting odd [18:30:37] ( [18:30:39] :( [18:32:26] brion: well, please sync anyway [18:32:44] ok [18:33:13] working fine on my testwiki, but there it is taking me to the formal review page; adding an extra step [18:33:44] ok, up'd the dir [18:33:57] for test wiki i shouldn't have to run a sync... [18:38:31] Guest1: brion is our dump guru ) [18:38:44] Guest1: and just ask your question there :p [18:52:29] brion: ok, that should help [18:52:42] *brion svn up'd [18:55:37] !uploads | artagnon [18:55:37] --mwbot-- artagnon: File uploads are an often-used feature of MediaWiki, but are disabled by default in all current release versions. To enable them, first make the upload directory (default images) writable by PHP, then set $wgEnableUploads to true in LocalSettings.php (i.e. "$wgEnableUploads = true;"). See for more info. [18:57:26] darkcode: putting it into wgPageName would probably break some scripts - putting it into a special variable seems reasonable. wgSpecialParam maybe? [18:57:39] or wgSpecialPageParam [19:01:50] finally i'm sitting at a *desk* :D [19:01:53] i have furniture! [19:09:44] *brion renames the channel to #browserwars :) [19:17:51] brion: and say "switch to linux too" [19:18:05] who added comma-separator? [19:18:21] trailing whitespace = not good [19:20:37] hmhm [19:20:42] what should be done to it? [19:24:15] to mediawiki! [19:24:46] please read [19:25:55] I'm too tried to play games, please [19:26:44] perhaps because I'm not expecting any answer from you [19:28:03] unlikely [19:30:23] 1) we could keep it as is (would not be editable in wiki then) 2) remove the space (not good either) 3) figure some work-around [19:35:32] hmhmm [19:35:40] sounds like my doings [19:35:49] that was on mw.org until I edited the message [19:36:08] well, better to add it in the code, not? [20:08:55] which version is our bugzilla? [20:52:56] Nikerabbit: says v. 3.0 on the bugzilla front page [20:53:53] oh, it has a front page :o [20:54:05] hehe [20:54:11] http://bugzilla.wikimedia.org :) [20:57:40] Nikerabbit, hmm, no trailing whitespace in messages . . . that's bad. [20:58:03] Simetrical: indeed [20:58:12] alnokta, it might become horribly inconsistent or otherwise broken? [20:58:26] Nikerabbit, some languages don't *have* spaces. It's no good to hardcode the space . . . [20:58:35] But you're right, this doesn't work either. [20:58:38] *Simetrical frowns [20:58:52] leaves solution 3) [20:59:01] Possible ways around it: 1) Allow some magical way for messages to have trailing whitespace. [20:59:06] 2) Screw all those foreigners. [20:59:07] 3) ? [20:59:21] Simetrical: there's the magic word __END__ [20:59:30] alnokta, probably 100-ish. It's just first-semester chemistry. [20:59:33] Duesentrieb, does that work? [20:59:34] it has to be used on every edit, though [20:59:39] it used to :) [20:59:39] Hmm. [20:59:50] 3) add special character that is removed... 4) use some weird escaping for the space [20:59:54] We could have some magic to preload it if there's trailing whitespace in a message file? [21:00:03] Or a message, rather? [21:00:11] That sounds sane, more or less, and it builds on what we have. [21:00:15] Fairly self-explanatory, too. [21:00:20] wot? [21:00:31] I dropped from the train [21:02:29] ah [21:03:12] __END__ or # ... needs some hack in any case [21:03:50] <^demon> What could possibly cause iconv() "Detected an incomplete multibyte character?" I'm using the Zend Framework's lucene api, and invoking it largely without error. Some of my entries come back with this error, and I'm unsure why. [21:03:55] how about ? [21:04:38] <^demon> Duesentrieb: Was that to me? [21:04:56] no, that was to Nikerabbit and Simetrical [21:05:00] <^demon> Oh ok. [21:05:31] Duesentrieb: mm would work pretty well with escapenoentities -> escape change, but not so nice for plain-text output [21:05:33] ^demon: the error is caused (surprise) by an incomplete multibyte character. I.e. broken utf-8 [21:05:53] ^demon: find out what sequence of bytes breaks it, and where that sequence comes from [21:06:04] <^demon> Would running my string through utf8_encode() potentially fix it? [21:06:37] ^demon: if they mostly are utf8 already, then no. [21:06:48] <^demon> They should *all* be utf8. [21:07:12] indeed. [21:07:33] and utf8_encode( expects latin1 input (hardcoded - wtf? what are the php guys smoking anyway?) [21:07:47] <^demon> But obviously some aren't. What would be the easiest way to scan a database for broken utf8? I can at least give it id's to go by, so it doesn't have to scan everything, but what way would check to find the broken parts? [21:07:58] ^demon: if you have inconsistently encoded text for some reason, there's no clean way to fix it, afaik. [21:08:08] find it, fix it by hand, find the reason. [21:09:06] ^demon: to dind the broken parts... well, i would hack into lucene, rather, because that's where the error happens, so you have all the info, and also because it's java, and java has strong unicode support. [21:09:31] <^demon> Ouch, not quite what I was wanting to hear, but thanks. [21:11:15] Nikerabbit, Duesentrieb: so how about when you view wikitext for *any* page that ends with whitespace, it automatically appends __END__ to the output? [21:11:30] ^demon: you could also tell mysql to copy all text to a dummy table, and convert on the fly from utf8 to... whatever encoding. it should also complain about broken utf-8, possibly telling you where & why. [21:11:52] Ideally, anytime wikitext is returned by the interface, submitting the same wikitext back should result in no change. [21:12:33] Simetrical: sounds ugly [21:12:40] Simetrical: yes... no... how about not automatically removing it? simply keep it where it is, and tell the parser to reduce it to nil? No idea why it didn't always work like that... maybe it was supposed to, and broke, and no one cared. [21:12:42] What about it is ugly? [21:12:46] the MAGIC-whatever should be there always [21:12:50] Duesentrieb, hmm, even better. [21:13:04] __END__ should just be a magic word that does nothing, then? [21:13:10] yes. [21:13:13] I can anticipate people finding more uses for that. [21:13:22] >_< [21:13:25] So maybe the name is bad . . . but for this context it's better to have a reasonable name. [21:13:25] note that most messages are _not_ going trough parser [21:13:47] especially not those where it would matter [21:13:48] Nikerabbit, right, we'd have to duplicate the logic for all message-handling. [21:13:53] Nikerabbit: for those, you'd need a special hack in the wgMsgXXX methods [21:14:19] at least it would be nice & consistent on the user side of things [21:14:35] Yes, that sounds reasonable. [21:14:37] I don't find it consistent to use same thing for two things [21:14:46] Nikerabbit, what are the two things, in this case? [21:14:49] I doubt we want to localise it (slow) [21:15:18] but the other __END__ can be localised [21:15:37] Hmm. [21:15:39] That's a point. [21:15:41] *Simetrical frowns [21:16:15] So what else?  isn't any good for plaintext output, should that be used anywhere . . . [21:16:33] Of course if we had the caller and not the message decide on output format, that wouldn't be a problem. [21:16:57] You would just do wfMsgPlainText or something, the message would realize it's plaintext with entities, and it would un-escape any entities. [21:17:27] I smell gentoo user [21:17:29] But brion seemingly doesn't want that, or else he misunderstood my proposal. [21:17:59] (Possibly my initial proposal was confusing.) [21:18:10] I would like the idea too, but there might be some problems... [21:18:19] Not that I see anyone willing to recode all of the wfMsg() functions either way. [21:18:35] Although you'd think they could be a lot faster than 100us or whatever they are, for a locally cached call. [21:18:41] A *lot* faster. [21:18:48] adding yet-another tag to wfMsgExt for this one is also one solution, easy one [21:19:11] Nikerabbit, yes, that would work, if we actually consistently use it whenever we do plaintext . . . [21:19:19] Which isn't that frequently anyway, honestly. [21:19:32] yep [21:19:36] And it won't kill anyone to have some entities show up in their plaintext for a while if we miss a spot. [21:19:38] Sasoriza: MediaWiki:Common.js [21:19:51] So maybe we should just do . [21:19:57] Sound good? [21:20:17] for the time being yes.. [21:20:30] Duesentrieb, you agree too? [21:20:44] Sasoriza: that JS doesn't need to be in a file, just edit the MediaWiki:Common.js article in your wiki [21:20:45] depends on little wether parsenoentities is renamed :o [21:21:06] well, for plain text messages, it's a hack either way (some magic value that isn't treated as "plain"). [21:21:17] i don't really like it, but don't see a batter solution [21:21:38] mmm...batter [21:22:18] Betty Botter had some butter... [21:22:23] so 1) use entity for space 2) introduce 'plaintext' to wfMsgExt later if needed 3) (related) make escape identical to escapenoentities [21:22:54] Sasoriza: ;-) I despise hacking files. [21:22:58] 4) can we fix easily semicolon-separator too? [21:23:21] or 3) always decode entities [21:23:32] The problem with all the wfMsg functions, and wfMsgExt switches, is they specify both the input format and output format. They should only specify the output format, the caller should not have to care about the storage format for the message. [21:24:23] Simetrical: i agreee [21:24:26] hmhm? how do they specify input format? [21:24:42] Simetrical: in theory. but no idea how to do it in mediawiki [21:24:53] (actually, i wrote a small skin framework around this idea) [21:24:57] Nikerabbit, some array somewhere would store it centrally. [21:25:11] Duesentrieb, I opened a bug on it but Brion WONTFIXed, I think he misunderstood. [21:25:21] Nikerabbit, rather than every call making the assumption separately. [21:25:31] guh [21:25:40] ? [21:25:46] here he is [21:25:53] Simetrical: well, it might not be feasable. and "some array somewhere" isn't really an improvement imho. it would be cool if i could actually specify it when editing the message on-wiki. [21:26:48] Sasoriza: Do you see how that chunk of code works? [21:28:31] !r 28735 [21:28:31] --mwbot-- http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=28735 [21:28:43] oo, fancy new feature in mwbot :D [21:28:53] Duesentrieb, then all the enwiki admins would set messages called 150 times per page to wikitext, and domas would kill you. :) [21:28:56] I think it always did it. we just didn't know how to use it [21:28:57] Or whoever did that. [21:29:01] semicolon-separator could use the same fix.. I think [21:29:14] Nikerabbit, its usage needs to be changed, yes. [21:29:22] I didn't bother changing usage. [21:29:37] hmmm [21:29:45] Simetrical: true. but conceptually, it should be stored with the message. not in yet another magic place. [21:29:58] Simetrical: when referencing an irc discussion in a commit message, it might be wise to summarize the discussion [21:30:02] Duesentrieb, yes, but not changeable per-language. [21:30:17] Duesentrieb, whereas messages are, so it needs to be in a separate place. [21:30:20] Simetrical: however, it would be nice to be able to put a message on the edit page for the message saying "this will be rendered as raw HTML", etc. [21:30:20] brion, okay, noted. [21:31:14] Duesentrieb: or we could just render it properly [21:31:53] Duesentrieb, see, that would be fine, if there were no distinction between input and output format. Which might be the simplest way to do it, but . . . [21:32:14] Sasoriza: that "test" string - you can put whatever HTML you want in there. [21:32:19] no i don't think that would be good [21:32:22] Necrogami, #redirect doesn't normally work cross-wiki. There might be some way to enable interwiki redirect, if the two wikis are in each other's interwiki maps. [21:32:49] no, that thing Skizzers was working with you on was totally different [21:32:50] Duesentrieb, so do we ever really use a message in two different contexts? Like output as HTML, and elsewhere output the same message as plaintext? [21:32:54] !configuration | Necrogami [21:32:54] --mwbot-- Necrogami : *All* configuration is done in LocalSettings.php (near the end of the file). Editing other files means modifying the software. Default settings are not in LocalSettings.php, you can *look* in DefaultSettings.php. See , , [21:32:57] Sasoriza: this is a hack free implementation [21:33:45] Sasoriza: if you put that code in your MediaWiki:Common.js article, and view an image page, you should see the "test" text right under the image description [21:34:02] Simetrical: we should allow it if possible [21:34:04] Duesentrieb, the caller would only usually want to output as either 1) HTML, 2) plaintext (very rarely), 3) raw content of the message escaped for HTML (one or two instances), 4) raw content of the message with no escaping (one or two instances). [21:34:34] Whereas the message itself might be stored as plaintext, plaintext with entities, wikitext, or raw HTML (deprecated). [21:34:49] *Simetrical ponders [21:34:59] and then there is variables with replace before/after [21:35:12] Sasoriza: eh, your call. only if you're comfortable with a 100% JS implementation [21:35:26] Nikerabbit, yes, true. That would be on the input side, I think. [21:35:27] Sasoriza: the php hack has the benefit of always being rendered - JS or no JS. [21:35:33] Because it affects the semantics of the stored text. [21:35:49] Sasoriza: but understand that your PHP hack gets lost when you upgrade your MediaWiki installation [21:35:52] Simetrical: but yes, that's about it (I would merge plaintext and plaintext with entities) [21:35:58] Sasoriza: which is why we try not to do file hacks [21:36:07] Sasoriza: and write extensions and such. [21:36:07] Nikerabbit, then use what for CSS and JS messages? [21:36:20] Nikerabbit, those shouldn't have entities, CSS and JS have their own ways of escaping. [21:36:33] hmm, ok you beat me [21:36:48] Sasoriza: so make sure you understand the JS script and make sure it does what you want, then you can remove the php hack. and upgrade w/ confidend in the future. ;-) [21:36:50] they abuse mw-namespace :) [21:37:16] Nikerabbit, yes, we have no other real way to configure the site. [21:37:21] It's kind of silly. [21:37:33] Simetrical: we can live with it [21:37:47] Necrogami, *everything* is configured in LocalSettings.php. [21:37:54] (Except where it's configured in the messages. \o/) [21:38:36] Sasoriza: not the JS implementation. That's actually an article in the database. [21:38:38] Simetrical: that could be nice to implement if brion approvies it [21:38:41] Necrogami, I don't know how to set up interwiki, never done it. I think it involves manually altering the database. (Yes, this contradicts what I said about all config being in LocalSettings.php.) [21:39:35] Nikerabbit, http://bugzilla.wikimedia.org/show_bug.cgi?id=10507 [21:39:37] Sasoriza: all that parentNode.parentNode.whatever.whatever.nextSibling stuff is how it's finding the element that we're trying to insert our new node before [21:40:09] Ooh, I even opened it twice. http://bugzilla.wikimedia.org/show_bug.cgi?id=8893 [21:41:13] Simetrical: heh [21:41:38] *Sasoriza doesn't want to have to think that far back today [21:41:49] Sasoriza: ImagePage.php I believe [21:41:58] would proper spesification help? [21:42:27] like writing down nicely what we have talked here [21:43:33] Nikerabbit, maybe, ask him. [21:43:37] Nikerabbit, someone has to write it, though. [21:45:26] Necrogami, no. I'm not sure if there's any option for interwiki redirects; if there is, you must specifically enable it. They don't work as nicely as intrawiki redirects. Generally on Wikimedia projects, you just use a template that links to the other project. [21:47:18] Necrogami, that's what's generally done. Interwiki redirects have various problems . . . there's no "redirected from" notice, so maintaining them is hard, it's difficult to edit the redirect page. [21:47:41] Necrogami, it can also be confusing, if you're logged in on one site but not the other, assuming no shared login. [21:48:06] Necrogami, the previous point probably is, though. [21:48:23] hmhm [21:48:48] Simetrical: what happens if someone tries to output wikitext as plaintext? :o [21:49:14] !access | Necrogami [21:49:14] --mwbot-- Necrogami: For information on customizing user access, see . For common examples of restricting access using both rights and extensions, see . [21:49:41] Necrogami: actually, preventing people from editing some pages is very simple, even without any config changes... just protect the pages. [21:49:46] Nikerabbit, 1) Throw an error. 2) Make a good-faith effort to make it plaintext, maybe by using whatever routine headings use to generate TOC entries (for instance). [21:49:55] for more stuff, read the page mwbot linked you to [21:50:03] 2) would have to be modified for subscripts/superscripts, though, at least, which are special-cased for TOC's. [21:50:24] Necrogami, you could also set up namespace-based editing restrictions. [21:50:51] brion, could you comment on http://bugzilla.wikimedia.org/show_bug.cgi?id=11555 at some point? [21:51:24] Necrogami, that's harder. MediaWiki isn't designed for that, using separate wikis is the best way to fix it. [22:02:44] Necrogami: preventing people from reading specific namespaces is what i wrote Lockdown for. it's not guaranteed to be air tight, but it works pretty well. [22:03:26] Necrogami: for moving 400 pages, use export/import, btw [22:03:38] yes. use interwiki redirects [22:03:43] it sucks, but it works [22:03:52] if you prefer, you can also do it on the apache level. [22:03:57] harder to maintain though [22:04:58] hm? what? [22:07:23] intoducing some redirects in a .htaccess file should not be a problem. but using on-wiki interwiki-redirects is probably nicer. [22:07:30] you'll want interwiki-links set up anyway [22:08:53] yes. [22:09:11] well, somehow it has to know when to rediret, right? [22:09:19] so you'll have to list the 400 in some way, at some point [22:09:36] you could do it in an .htaccess file to tell apache to redirect [22:09:46] or you can make an xml dump with the 400 redirects, and import it. [22:09:53] it's up to you. [22:09:59] hm... oh... http://www.mediawiki.org/wiki/Manual%3A%24wgRedirectSources [22:10:06] i didn't know that existed. nice :) [22:12:35] Necrogami, use a template! [22:12:50] Necrogami, otherwise, yeah, that's what (for instance) meta.wikimedia.org does, for pages moved to www.mediawiki.org. [22:14:10] !magicwords | Necrogami [22:14:10] --mwbot-- Necrogami : For more information about creating magic words and their inner workings, see . For a list of magic words, please see . [22:14:15] Necrogami, you want {{CURRENTPAGE}}. [22:16:38] yes it will [22:17:16] though in an external link, you'll need to {{#urlencode:{{CURRENTPAGE}}}} [22:18:34] Duesentrieb, no, {{CURRENTPAGEE}}. urlencode will be wrong for things like spaces. [22:18:43] Er, right. [22:18:54] And {{PAGENAMEE}} is what I meant, for inclusion in a URL. [22:19:01] But yes, the way you use it is correct. [22:27:03] Necrogami, you want {{FULLPAGENAMEE}} there, to account for pages with spaces in the name, etc. [22:32:59] Simetrical: the EE stuff will work, but why should urlencode not work? ok, it would trigger an additional redirect - but in the end, it should work, no? [22:33:49] Necrogami: if you don't want to put the template on 400 pages by hand, write a script that generates a dump. should be trivial [22:33:50] Duesentrieb, http://en.wikipedia.org/wiki/Electrical+engineering does not redirect. That's what you would get from urlencode, no? [22:34:09] Simetrical: ah, right, because [22:34:25] ...because "+" is only "sometimes" decoded by the webserver [22:34:42] which is a bit odd - handling of url-encoded chars in the path is a bit... err... magical [22:34:47] seems to be underspecified [22:39:22] *Sasoriza hears crickets [22:57:15] Sasoriza, 1in is an inch, or 72pt. Use of such units is typically frowned upon, in CSS. [23:05:14] Simetrical: except for specifying font size [23:05:28] Duesentrieb, usually also frowned upon for that. [23:05:41] Simetrical: ...what would you use for that, then? [23:05:52] btw, even px is useful for some things. like border width. [23:06:00] Duesentrieb, xx-small, x-small, small, medium, large, x-large, xx-large [23:06:05] Or whatever they are. [23:06:30] yea, well... the problem is that those vary too much among browsers, iirc. [23:06:33] px is a weird measurement. [23:06:51] In CSS, that is. [23:06:55] Because it's not really a pixel. [23:06:59] But it's implemented as one. [23:07:08] Usually. [23:07:19] *usually* you also have pt=px [23:07:23] Except when you use a really big resolution and a px becomes two pixels and everything is gigantic. [23:07:28] That depends on platform, IIRC. [23:07:37] although you increasingly see the actual monitor's dpi used [23:08:19] Can't be done except very approximately, if you're rounding to the nearest pixel. [23:08:34] So you have enormous jumps when you hit a certain resolution threshold. [23:08:58] yes [23:12:01] replikant, I believe it just takes the final value of the font-size property from CSS, converts to pixels, and then scales up by a constant factor. [23:12:11] *Simetrical tries to remember the CSS jargon for "final value" [23:18:00] replikant, it's supposed to be a point or an inch, measured on the display device. [23:18:32] Which means if you display your 14pt font on a projector . . . according to the standard, it should remain exactly 14pt high. [23:18:51] One wonders why they bothered having such measurements in the standard to begin with, other than *Imaybe* for print. [23:21:13] FF3 has everything scale with full-page zoom, apparently. [23:21:16] Which is nice. [23:21:28] *Simetrical wanders off to see if there's bagels and lox around [23:24:16] Smoked salmon. [23:59:29] uh... 1.6 had a "error creating thunmbnail" message? i thought that was added much later... [23:59:43] anyway - check file permissions, check safemode, check path to imagemagic [23:59:57] !thumb [23:59:57] --mwbot-- For information on configuring thumbnailing on MediaWiki, please refer to .