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
Just wondering if anybody has a copy of the extension on this page:
http://meta.wikimedia.org/wiki/WikiPodcast
The original host doesn't seem to have the file anymore.
Thanks!
Chris
Recently, I have uploaded som eplant images to the commons. A few of
these might have been incorrectly labeled. The current procedure for
"renaming" them is
#1 someone downloads the image
#2 reuploads it under a new name, with the original description
#3 fixes links on other wikimedia projects via chackusage
#4 adds a "duplicate" template to the original image
#5 the original image gets, eventually, deleted (unless it's an admin
doing reuploading, who can skip #4)
For a site managing >1.5 million files, IMHO this is a rather
cumbersome process. Also, it leaves a (perfectly OK) image deleted on
the server, thus duplicating that data.
Maybe Tims recent file managing upgrade already has a solution for
this, but if not, here's my 2 pennies (I'm in the UK now, after all:-)
* Make image pages movable (with the appropriate changes to the image table).
* Replace the "404 error: File not found" error message for
non-existant images with a script that checks if there's a REDIRECT
page under that name in the database.
* Return the new image if this is the case, and return 404 if not.
This would be an improvement to the manual steps described above:
* MUCH easier and faster to do
* Preserves original upload/edit history
* Direct links to the image keep working
* No space waste due to deleted image
* Cost : an additional redirect page, and an SQL query for requests of
non-existing images
To turn off this behaviour for an image, simply delete the REDIRECT page.
(Seems so easy, I'm afraid I missed someting obvious at this point:-)
Magnus
Hi,
I've got a question:
Why is the special page template as described in [1] not compatible with
Media Wiki VERsion 1.6.9 ?
Using this Template under 1.6.9 the Specialpage can be listed under
Special:Version, but it is not visible at "Special pages" and if called
directly, the created Specialpage doesn't exist.
[1] http://meta.wikimedia.org/wiki/Writing_a_new_special_page
Thank you very much.
Chris
Recently, r22642 has added the list of deletion log entries below
noarticletext.
It was bug 7691, and while i understand the reasons for adding it, it
injects ugliness into the wiki's 404.
Deletion logs are not politically correct, there are lots of "content
was: <offensive text>", which are perfectly valid deletion reasons. But
not appropiate for showing to the casual browser.
When someone searchs about Foo, we may be giving
<s>insults</s>misleading information about it, as (while saying it was
deleted) we put "vandal #325 opinion about Foo"
It wouldn't surprise me that some blogger/journalist discovers that
"Wikipedia says X" on a log entry. We already had problems with
viewdeleted history.
If the user doesn't specify an ''editor interest'', page browsing
shouldn't give information about wiki document managing.
The log below newarticle text should be enough (though will show when
arriving via red links... :s)
If we still want to alert the user of deleted pages, i'd either make it
a new message: "Warning: A page with this name was deleted [N times]"
with the corresponding link to Special:log, or add it as a parameter to
noarticletext for parserfunctioning it.
Opinions?
On 09/06/07, amidaniel(a)svn.wikimedia.org <amidaniel(a)svn.wikimedia.org> wrote:
> Revision: 22859
> Author: amidaniel
> Date: 2007-06-09 04:16:28 +0000 (Sat, 09 Jun 2007)
>
> Log Message:
> -----------
> Remove dismiss from deletion log. This simply doesn't make sense to me, nor does it to those I've discussed it with. If you don't want the recreate warning displayed, it's in a div wrapper and can be hidden through css. We don't need a dismiss link on every system message to hide the message permanently; it only makes sense on things like Sitenotice, where users want to hide the current message, having read it, but not necessarily the next.
I disagree that it doesn't make sense, but fair enough.
Rob Church
In attempting to fix
http://bugzilla.wikimedia.org/show_bug.cgi?id=7651, I discovered that
returning the flag "noargs" => true from the callback function seems
to fix the problem, but I haven't the foggiest clue why this is.
Can anyone actually explain this to me?
Rob Church
On 07/06/07, amidaniel(a)svn.wikimedia.org <amidaniel(a)svn.wikimedia.org> wrote:
> Revision: 22816
> Author: amidaniel
> Date: 2007-06-07 17:31:08 +0000 (Thu, 07 Jun 2007)
>
> Log Message:
> -----------
> (bug 7997) Added ability to Special:Blockip to block users from using Special:Emailuser.
$wgSysopEmailBans
Wouldn't it make more sense to introduce a new permission for that,
which could sit on top of the standard "block" permission, rather than
introduce another global?
Rob Church
My motivation is to automate page creation and semantic annotation by using html-forms. One use case would be to automatically annotate creation relationships between pages. To do so I implemented a tag hook which creates the forms.
My problem: I want to use this extension tag inside templates and also use template parameters.
Contents inside an extension tag are not parsed but treated separately.
<tag>...contents...</tag>
Therefore template variables inside a tag like the following are not replaced.
<tag>...{{parameter}}...</tag>
I already figured out that extension tag hooks are treated within the function split() in Parser.php.
But how can I get the parser to parse the contents of the tag before calling the according extension callback function?
Function recursiveTagParse() seems to be an option but I can't get it to work.
Or is it necessary to work with an extension function hook instead of a tag hook?
Any suggestions? Or indications where I could find help?
Thanks in advance.
_______________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I pulled some stats together for Jimmy the other day, figured I may as
well post them too. :)
http://leuksman.com/log/2007/06/07/wikimedia-page-views/
Should be possible to automate these and other kinds of stats breakdowns.
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGaEcKwRnhpk1wk44RAp8CAJoCIVpEyNKevkLXVFyscVERgddiXACdGFEa
rbHs2ErUim4HfITbTmWOsUI=
=IWfC
-----END PGP SIGNATURE-----