Wikitech-l October 2008

wikitech-l@lists.wikimedia.org

98 participants
93 discussions

Local replication
by Bilal Abdul Kader 09 Oct '08

09 Oct '08

Hi, I am trying to replicate Wikipedia locally with the history and the editing tracking. The total DB might be extremely large. It is possible to do that on a single server with 8 CPUs (Xeon) and 32 GB or RAM and Linux CentOS? Thanks in advance for all your time and answers. bilal

2 1

Re: [Wikitech-l] nostalgia skin: gathering ideas for an improved version
by nsk 09 Oct '08

09 Oct '08

Le mercredi 08 octobre 2008 à 20:17 +0000, wikitech-l-request(a)lists.wikimedia.org a écrit : > From: Huji <huji.huji(a)gmail.com> > Subject: Re: [Wikitech-l] nostalgia skin: gathering ideas for a > improved version > > There are many other issues with Nostalgia skin too. I never played with it > until recently, when I fixed a bug in its printable version. yeah I remember your fix as I reported that bug, thanks for fixing it so quickly! I immediatelly grabbed your fix from svn for my wikis as I am adventurous enough to run on HEAD :) I also use Nostalgia on Wikipedia though, and I wonder when your fix will make it there, as I see the Wikimedia wikis are still in 41337. I can't properly print a Wikipedia page without switching skins as it is now :( > Nostalgia should be rewritten some day. that was my idea also. someday it ought to be rewritten to become more modernised from a coding perspective, and maybe also from a user interface perspective while keeping the same general oldish look. > From: Brion Vibber <brion(a)wikimedia.org> > Subject: Re: [Wikitech-l] nostalgia skin: gathering ideas for a > improved version > > Nostalgia roughly replicates the pre-MediaWiki interface of Wikipedia. > It's not really meant for usability. ;) Nostalgic Wikipedians want a usable skin, too! :) It is not necessary to replicate the old wiki look so much as to make Nostalgia unusable or put its users at a disadvantage compared to the other skins. I think we can replicate the old look without sacrificing much usability. I think it is important to provide the same functionality to Nostalgia users that users of other skins enjoy, such as user pages links (15868), a search box that can be used with Ajax easily (15902), an upload link that can be middleclicked in a new tab (15903), perhaps even a Discussion link at the top of the page as well (15905). As I use Nostalgia I may end up improving it a bit, and I will share any improvements as patches on bugzilla. > > PS: I have put a quick patch (15868) on bugzilla to include user pages > > in Nostalgia. > > Doesn't sound terribly disruptive. Note that preferences and watchlist > are already available through the special pages dropdown, though. I was thinking about this while I was getting the patch ready, and finally decided that the most important user-related pages that are available as links in other skins should also be available as links in Nostalgia as well. This helps users of Nostalgia enjoy the same user experience as users of other skins; for example, I can middleclick and open my watchlist in a new tab or new window with the other skins, but with Nostalgia I wouldn't be able to do this through the dropdown menu. In fact I now have the same problem with the upload link: in the other skins I was used to middleclicking the upload link so that I could upload using a new tab without replacing the page I was viewing. But with Nostalgia I only get the upload function in the dropdown menu. I will probably submit a small patch to add an upload link soon (15903). > Of course as the number of special pages has increased dramatically > since 2002, that drop-down has become rather unwieldy. I'm not sure > what's the best way to extend or replace this without dramatically > changing the layout. I am thinking along the same lines, but I am considering whether it is truly desirable to list all special pages in the drop down menu. Maybe just including a menu item leading to the list of all special pages, perhaps together with a small number of other frequently used special pages, would be enough. I would like to learn what other ideas or perceptions there are about Nostalgia as well. I would also be very interested to collect statistics regarding how many Wikipedia users use Nostalgia as their skin of choice, so I will submit a query request to see generally how much interest there would be for a better Nostalgia. -- Thanks, NSK Nikolaos S. Karastathis, http://karastathis.org/

1 0

OpenID
by Jan Kucera 09 Oct '08

09 Oct '08

Hi there, what about implementing OpenID accross some Wikimedia projects? I know this might be rather "political" than "technical" decision, but I think it would bring only positives. I tried to bring it up on Metapub and Village pump, but quite little interest was showed... Jan

14 21

nostalgia skin: gathering ideas for a improved version
by nsk 08 Oct '08

08 Oct '08

Nostalgia is a MediaWiki skin that has been introduced before 1.3, when MonoBook became the default. It is available for use in Wikipedia and other Wikimedia sites for registered users. It is the skin that I like best, but I think it is in need of some improvement. The skin appears to have some usability problems that other skins don't have: you cannot easily find your user pages when using Nostalgia, and there is no easy link for uploads apart from a drop down menu which is too unorganised. I would like to know whether there is any interest from other users/developers about Nostalgia (or whether I am the only one using it!), and if so what you would like to see in an improved more modern version of Nostalgia (with the same general looks, but not putting the user in a disadvamtaged position from a usability standpoint comprared to the other skins, particularly the default one). What would you think can be considered wrong with the current Nostalgia, and how would you like it to be? PS: I have put a quick patch (15868) on bugzilla to include user pages in Nostalgia. -- Thanks, NSK Nikolaos S. Karastathis, http://karastathis.org/

3 2

Wikipedia & YSlow
by howard chen 08 Oct '08

08 Oct '08

Hello all, As you might already know, YSlow is a tool to check website performance, I just run a test against: http://en.wikipedia.org/wiki/Main_Page Results is quite surprising, Grade F (47). Of course lower mark does not always means bad, but there are some room for improvement, e.g. 1. Minify JS (e.g. http://en.wikipedia.org/skins-1.5/common/ajax.js?179) 2. Enable GZip compression (e.g. http://en.wikipedia.org/skins-1.5/monobook/main.css?179) 3. Add expire header (e.g. http://upload.wikimedia.org/wikipedia/en/9/9d/Commons-logo-31px.png) 4. Don't put CSS out of the <head /> etc. By do this, it should save some money on bandwidth, as well as to provide a better user experience. Howard

17 34

Invisible malicious changes.
by Tei 07 Oct '08

07 Oct '08

Possibly off-topic. Heres is a script that replace normal whitespace with one of the whitespaces supported by UTF8 ( Others are             ). I have made a few vandalization test here: http://en.wikipedia.org/wiki/User:Tei/lalaland What do you guys think? could this be a problem? You can break links like [[Mr Thonson]] replacing it by [[Mr Thonson]] while(<DATA>){ @chars = split(//,$_); foreach $ch (@chars){ if ( $ch eq " "){ print pack("ccc",0xe2,0x80,0x80); }else { print $ch; } } } __DATA__ Text to be vandalized goes here

9 13

handling of interwiki links in dumpHTML
by Christensen, Courtney 07 Oct '08

07 Oct '08

I've googled, I've MediaWiki.org'd, I've searched the mailing list archives and I haven't found an answer to this so I'm taking it to the sources. I have a wiki family with interwiki links between each wiki. I often have to dump my wikis to make flat deliverables for people to run off a CD (or DVD). When I dump this wiki family I get <iw_prefix>:/f/i/l/0.html when it tries to parse an interwiki link. I would like to be able to rewrite those links during the dump to whatever destination directory I tell it to use. I thought this was being made in the getHashedFilename function of dumpHTML, but adding some print statements there I don't seem to see any of the interwiki links. My ultimate problem is that when the wiki is dumped the interwiki links are all dead and I don't know any way to hook them back up short of going through each page by hand. I was hoping, since I know the destination directory of the wiki family dumps, I could rewrite the links mid-dump. Any solutions, pointers, encouragement, or other comment that is not negative is very appreciated! Courtney Christensen

1 1

seeking advice in making extension more robust
by Burobjorn 07 Oct '08

07 Oct '08

Hi there, I've recently built my first extension for Mediawiki using the CustomUserCreateForm extension as a base and a bit of the ConfirmEdit extension. My goal was to have a checkbox on the register form for new user where they have to agree to the wiki's terms before they can become users. Using the previous mentioned extensions as a base I succeeded in this, yet I've the feeling the extension could/should use some (probably a lot actually) changes that would make it better. For instance I replace the php template for the registration of new users with my own, but I have hardcode the link to the terms. I would prefer this to be set by a user of this plugin using a variable instead of forcing them to change a template. Actually I would rather not replace the register php template at all, but just add a new form element to it. Anyway, I hope some of you have some time to review my work so far and point me in the right direction to do things the mediawiki way :) The plugin code can found as a zip file on my site: http://www.burobjorn.nl/customUserCreateForm.zip (approx 5Kb) Looking forward to your feedback and comments, -- met vriendelijke groet, Bjorn Wijers * b u r o b j o r n .nl * digitaal vakmanschap | digital craftsmanship Concordiastraat 68-126 3551 EM Utrecht The Netherlands http://www.burobjorn.nl

2 2

ODJAR (Re: [MediaWiki-CVS] SVN: [41264] trunk/phase3)
by Tim Starling 06 Oct '08

06 Oct '08

brion(a)svn.wikimedia.org wrote: > Revision: 41264 > Author: brion > Date: 2008-09-25 18:43:33 +0000 (Thu, 25 Sep 2008) > > Log Message: > ----------- > * Improved upload file type detection for OpenDocument formats > > Added a check for the magic value header in OpenDocument zip archives which specifies which subtype it is. Such files will get detected with the appropriate mime type and matching extension, so ODT etc uploads will work again where enabled. > > (Previously the general ZIP check and blacklist would disable them.) > I think you're missing the point. It's trivial to make a file which is both a valid OpenDocument file, and a valid JAR file subject to the same origin policy. http://noc.wikimedia.org/~tstarling/odjar/ > print $mm->guessMimeType('.../odjar.odt') application/vnd.oasis.opendocument.text Just done with zip/unzip, no hex editing involved. -- Tim Starling

3 3

Bugzilla Weekly Report
by reporter＠isidore.wikimedia.org 06 Oct '08

06 Oct '08

MediaWiki Bugzilla Report for September 29, 2008 - October 06, 2008 Status changes this week Bugs NEW : 134 Bugs ASSIGNED : 5 Bugs REOPENED : 11 Bugs RESOLVED : 80 Total bugs still open: 3052 Resolutions for the week: Bugs marked FIXED : 46 Bugs marked REMIND : 0 Bugs marked INVALID : 6 Bugs marked DUPLICATE : 12 Bugs marked WONTFIX : 11 Bugs marked WORKSFORME : 7 Bugs marked LATER : 1 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component Site requests 13 Special pages 7 General/Unknown 4 User interface 4 Database 4 New Bugs Per Product MediaWiki 37 Wikimedia 24 MediaWiki extensions 9 Top 5 Bug Resolvers JSchulz_4587 [AT] msn.com 17 markus [AT] semantic-mediawiki.org 8 jayvdb [AT] gmail.com 6 mattj [AT] emazestudios.com 5 roan.kattouw [AT] home.nl 5

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2026

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 October 2008