Whee, lots of new users this week. Please welcome
* archinform
* chrislb
* escaladix
* mdd4696
* orgullo
I invite the new users to edit their ~/.about.me files and create
project information files in their home directories.
Rob Church
Hi all,
I've created a page similar to the account listing page for projects.
http://tools.wikimedia.de/~leon/toolserver/projects.php
It works like the account listing:
Create a writable directory called '.projects' in your home and put a
file for each project there.
It's unimportant how that's called.
The incredible tim has written a script to automate that, you can call
it with "make_project_page" -- it asks for the information and does
everything else on its own.
Filename is something you like. Unimportant which one. Required.
Project name is what you call this project. Required.
Project description describes your project. You may use http:// links.
Required.
Project location is where users can find the tool. If there's no URL,
leave it empty.
Programming language is the language that tool is written in. Optional.
It would be great if this could become an overview with hopefully all
tools hosted on zedler.
I'll add filtering i. e. for users when I find the the time for that.
Leon
Hello all,
the replag de: (and all others languages expect asia and en:) rise at
the moment, because zwinger (a important server in the
wikimedia-clusetr) dies tonight and our ssh-tunnels to the databases had
gone over it.
Sincerly,
DaB.
--
Blog: http://www.wp-blog.de | PGP: 2D3EE2D42B255885
It looks like the page_id is corrupted somehow, from data on July 9 and July 10. Does this come
from the replication tool, or the replay tool?
http://tools.wikimedia.de/~interiot/cgi-bin/queries/tmp/en_munged_pageid
In the cases I've seen so far, rev_id and user_id seems to be correct, but page_id sometimes is not.
-Dave
There's a new view, "user", available for all databases, comprising of
the following fields:
* user_id
* user_name
* user_registration
Note that user_registration will be NULL for accounts created before
it was introduced. In these cases, what your code would have to do is
look up either
* the appropriate newuserlog row
* estimate based on the first edit
Cheers,
Rob Church
enwiki_p.templatelinks doesn't seem to currently exist. It seems to be still used by mediawiki
(TimStarling says so, and dewiki_p.templatelinks exists), so it seems like it should exist. Could
someone with more permissions see whether it's a view problem, or whether it's something that had
gotten dropped or wasn't replicated?
Thanks,
-Interiot
As some of you may know, Wikimedia Commons has a huge problem with a
backlog of files to be deleted. Problematic images and outright
copyright violations are piling up by the thousands. Part of the problem
is that, once you delete an image on the commons, it is really gone -
there is no undelete function for images. So, admins hesitate to delete
images, which is understandable.
Until the problem is solved within MediaWiki (likely a complicated
issue), I have written a script which can store images that are to be
deleted from commons on the toolserver. The images are given random
names, and the admin who invokes the script is given the mapping of
original and new name, so he can recover it in case the deletion was
unjustified. The random file names make it very unlikely for anyone to
"stumble" on a copyright violation, so there should be no harm in
storing them that way.
Currently, I am using a subdirectory of my toolserver account to store
the images. But, given the sheer volume of (bad) images on commons, I'll
soon run out of disk space.
Does anyone have an idea where to store these images on a more ...
permanent basis? I can always run a bot to delete images when disk space
gets low, but I'd prefer to keep these backup images around for a few
month at least. Increasing my disk limit is of course the easiest way to
do that, but maybe there's a better solution?
Magnus