Wikitech-l February 2010

wikitech-l@lists.wikimedia.org

92 participants
75 discussions

Re: [Wikitech-l] [mwdumper] new maintainer?
by emmanuel＠engelhart.org 12 Feb '10

12 Feb '10

Le ven 12/02/10 14:24, "Christensen, Courtney" ChristensenC(a)battelle.org a écrit: > We use the DumpHTML extension (http://www.mediawiki.org/wiki/Extension:DumpHTML) to > make static copies of our wikis. It used to be a maintenance script. > Maybe that would work for you? The DumpHTML extension is something else... this is tool a to get a static HTML version of Mediawiki articles. If you speak from http://static.wikipedia.org/... this is also an other topic because these pages are not our content, but only a not customizable view of our content (I can't do nothing with it). Our content is the wiki code and the files (images, etc.) ... and this is what seems not to be fully reusable currently. Emmanuel PS: DumpHTML seems also not to be maintened currently... have a look to the bug reports.

2 1

Re: [Wikitech-l] [mwdumper] new maintainer?
by emmanuel＠engelhart.org 12 Feb '10

12 Feb '10

Le ven 12/02/10 01:52, "Tim Starling" tstarling(a)wikimedia.org a écrit: > emmanu > el(a)engelhart.org wrote: > mwdumper is an almost mandatory tool to spread our > content and for this reason i wanted to > speak about that on the ML. > > You might have to be more specific than that. It doesn't seem like a > mandatory tool to me. XML dumps+mwdumper are the only one solution I know to make quality static dumps? Do you know an other one? Emmanuel

2 1

OTRS for commit access requests
by Tim Starling 12 Feb '10

12 Feb '10

So that I can respond to commit access requests in a more prompt and standardised manner, I've set up an OTRS queue: commit-access-requests(a)wikimedia.org. I will get an email notification when new tickets are opened in it. It has the same permissions as the noc queue, but I imagine I'll be the only one looking at it for a while. Moving to OTRS will make dialog with requesters easier and more reliable. I will shortly migrate the outstanding requests to the queue, and update the mediawiki.org page to indicate that new requests should be sent to it. I have modified the approval response template to encourage new users to create a user page on mediawiki.org. This means that there will still be a chance for new users to interact with mediawiki.org regulars and to talk about their projects. -- Tim Starling

2 1

New committers
by Tim Starling 11 Feb '10

11 Feb '10

Gabriel Wicke (gwicke): yes, *the* Gabriel Wicke, the man who wrote the MonoBook skin and introduced us to Squid. We are in his debt and he can work on whatever he wants. Nathanael Thompson (than4213): has some grand plans for rewriting the parser. We will see how it turns out in a branch. Gurch: API HappyDog: CodeReview extension, various other extensions currently hosted offsite. -- Tim Starling

1 0

Re: [Wikitech-l] confirm dfe03c58a0a....
by Marco Schuster 11 Feb '10

11 Feb '10

Hi all, I just got this email from bugzilla. Apparently Google Apps has screwed up something again so the message itself doesnt annoy me, but why are the users' passwords still sent in CLEARTEXT in these days?? Can someone (tm) of the mailman admins or tech guys please fix this up? Thanks, Marco On Wed, Feb 10, 2010 at 2:47 PM, <wikitech-l-request(a)lists.wikimedia.org>wrote: > Your membership in the mailing list Wikitech-l has been disabled due > to excessive bounces The last bounce received from you was dated > 10-Feb-2010. You will not get any more messages from this list until > you re-enable your membership. You will receive 3 more reminders like > this before your membership in the list is deleted. > > To re-enable your membership, you can simply respond to this message > (leaving the Subject: line intact), or visit the confirmation page at > > > https://lists.wikimedia.org/mailman/confirm/wikitech-l/dfe03c58a0a1fe2.....<https://lists.wikimedia.org/mailman/confirm/wikitech-l/dfe03c58a0a1fe2700f7…> > > > You can also visit your membership page at > > > https://lists.wikimedia.org/mailman/options/wikitech-l/marco%40harddisk.is-… > > > On your membership page, you can change various delivery options such > as your email address and whether you get digests or not. As a > reminder, your membership password is > > <blanked> > > If you have any questions or problems, you can contact the list owner > at > > wikitech-l-owner(a)lists.wikimedia.org >

5 6

Skin system rewrite
by Jack Phoenix 10 Feb '10

10 Feb '10

Hi all, MediaWiki's skin system has been quite a mess for some while. I decided to try rewriting it and you can see the end result on [1]. It's quite a big patch, which is why I want to encourage all developers to test it and report (or maybe even fix? :) any and all issues they stumble across. There is also an example extension on [1] which I've been wanting to do for a long time but which hasn't been possible with the old skin system. To be exact, it was partially possible, as I noted on the MediaWiki.org page, but the implementation was too buggy to be put live on any site IMHO. What does this patch change exactly? When writing a new skin, you no longer need to override SkinTemplate and write a class that utilises QuickTemplate, you can just extend Skin class directly. Old SkinTemplate-based skins will however continue functioning. I wrote a couple things about writing a new skin with this new system on MediaWiki.org[2], feel free to check it out. There are some changes which may cause problems, though. For example, SkinTemplateToolboxEnd and MonoBookTemplateToolboxEnd hooks both take two arguments instead of one and the hooks are in Skin.php instead of SkinTemplate.php. I was also thinking that this could be a great opportunity to add some new hooks to Skin.php, besides the SkinAfterSidebar hook. See [3] for my thoughts about what could be improved. I haven't ported Vector skin to use this new system because it's currently under development. Because this change is quite a big one, I thought that I'll commit it to SVN once MediaWiki 1.16 has been released so that it'll make into the 1.17 release. What are your thoughts and suggestions for this new skinning system? [1] http://www.mediawiki.org/wiki/User:Jack_Phoenix/SkinSystemRewrite [2] http://www.mediawiki.org/wiki/User:Jack_Phoenix/SkinSystemRewrite/Documenta… [3] http://www.mediawiki.org/wiki/User:Jack_Phoenix/SkinSystemRewrite/Notes_and… Thanks and regards, -- Jack Phoenix MediaWiki developer

10 21

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [62223] trunk/extensions/OggHandler
by Gregory Maxwell 10 Feb '10

10 Feb '10

On Wed, Feb 10, 2010 at 12:51 AM, <tstarling(a)svn.wikimedia.org> wrote: > http://www.mediawiki.org/wiki/Special:Code/MediaWiki/62223 > > Revision: 62223 > Author: tstarling > Date: 2010-02-10 05:51:56 +0000 (Wed, 10 Feb 2010) > > Log Message: > ----------- > * In preparation for deployment, revert the bulk of Michael's unreviewed work. Time for review has run out. The code has many obvious problems with it. Comparing against r38714 will give you an idea of which changes I am accepting. Fixes bug 22388. > * Removed magic word hook, doesn't do anything useful. > * OggPlayer.js still needs some work. Looks like this change removed both the Oggthumb support as well as the code that handles the cases where ffmpeg fails. Ffmpeg will fail to generate a thumb if there is no keyframe in the file after the point in time that you requested a thumb. This was causing a failure to generate thumbs for many files because they are short and only have a single keyframe at the beginning.

2 6

Release the content on Wikimedia Technical Blog under a free content license
by Liangent 10 Feb '10

10 Feb '10

http://techblog.wikimedia.org/ : Is it ok to do it just like our main wikis and WMF official blog?

4 3

Flattening a wikimedia category
by Rayson Ho 09 Feb '10

09 Feb '10

Seems like it is no easy way to display all the media files under a wikimedia category -- for example if someone wants a picture of a library, he or she will need to go into each sub-category under "Libraries": http://commons.wikimedia.org/wiki/Category:Libraries While Wikimedia is not yet the most popular stock photo source, IMO having this flattening functionality would be useful to those who are looking for stock photos. Rayson

15 37

empty .sql.gz dump files
by Mike.lifeguard 08 Feb '10

08 Feb '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, While trying to get externallinks.sql.gz for enwiki, I found that the file was empty. Looking at the hashes, I guess several of these metadata dumps have failed (but marked as successful, of course): http://download.wikimedia.org/enwiki/20100130/enwiki-20100130-md5sums.txt e32d799e86f8d2be5ebb3eed048238c7 is the md5 for these 20-byte files. Older stuff seems ok (enwiki-20100116-externallinks.sql.gz) - as does data for other wikis (enwikibooks-20100206-externallinks.sql.gz). - -Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktwMl8ACgkQst0AR/DaKHtZswCghbS4I+mKb1lDRvBbKREC+dww NtoAn30rKLPMpQ0ZAl0JTkifeG8RE9YC =HFYk -----END PGP SIGNATURE-----

2 1

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 February 2010