Wikistats are now available for all Wikimedia projects.
Stats have been generated from the latest dumps, which are from March 9.
Wikipedias
http://en.wikipedia.org/wikistats/EN/Sitemap.htm
Wiktionaries (use refresh button when you see old stats)
http://en.wikipedia.org/wikistats/wiktionary/EN/Sitemap.htm
Wikiquotes
http://en.wikipedia.org/wikistats/wikiquote/EN/Sitemap.htm
Wikibooks
http://en.wikipedia.org/wikistats/wikibooks/EN/Sitemap.htm
Wikinews
http://en.wikipedia.org/wikistats/wikinews/EN/Sitemap.htm
Wikispecial: wikisource/meta/sep11/species/commons/foundation
http://en.wikipedia.org/wikistats/wikispecial/EN/Sitemap.htm
Sj wrote:
> If there were a machine dedicated to stats of various kinds,
> with its own mirror of the db, could this be done more efficiently
> as a running-total, updated whenever the db was updated?
A dedicated mirrored server for these and other background jobs (e.g. IBM
history flow charts and Special Pages) would certainly help. Switching away
from processing dumps towards direct SQL access has been suggested before.
Especially with the upcoming database scheme change, dumps become more
difficult to handle, though not impossible.
I had my doubts about switching, because very heavy 'Special:' SQL queries
have been often disabled or cancelled halfway to bring down server load, and
the stats queries will be very heavy indeed.
A separate server would make this less of an issue. Average CPU speed will
do fine, memory no less than 1Gb, preferably 2GB. Even though I took great
care to keep memory requirements at an acceptable level, some hash tables
need to be in memory and their sizes grow like everything else around here.
I hope you don't mean running-total literally, where all figures change
every second :)
At least it should be possible to generate new stats once or twice a week,
instead of once a month (the latter depending on how often dumps are
generated).
Erik Zachte
At ETech in San Francisco, I met with Ross Mayfield of Socialtext, and
we discussed the idea that there should be a central core set of
standard wiki syntax. Ross was quite keen on the concept.
Standard syntax is important for the entire wiki world so that as
people become more accustomed to using wikis for all kinds of things,
they can feel comfortable on a variety of platforms.
It seems natural to me that as the largest wiki project (and we are
probably the wiki engine with the most installations, although I have
no actual way of knowing that), we should take a leadership role in
this.
http://www.socialtext.net/mayfield/index.cgi?action=refcard&login=user4232
is a quick 'refcard' on the syntax of socialtext.
I propose that we set up a group of people either in a mailing list or
a wiki or both, and invite representatives from all the major wiki
software projects and companies to participate in a syntax standard.
I don't know anything about how formal standards are proposed and
decided, but just as with HTML, it seems that wiki syntax is a natural
for some standardization.
--Jimbo
--
"Pianosa is een Italie" - first words of 50,000th article on nl.wikipedia.org
The following changes have been made to the Python Wikipediabot
framework since the previous overview of February 6. As always, the
new files can be downloaded at
http://cvs.sourceforge.net/viewcvs.py/pywikipediabot/pywikipedia/, and
one can of course use a newer version as well. Furthermore, changes
have been done to the Wikimedia software early February, and to the
bot as well. Therefore:
* versions of wikipedia.py older than 1.391 (February 5) do not work any more
* If you use a version of anything from February 6 or later, you
should use a version of everything (more precisely, wikipedia.py,
config.py and the specific bot you are using) from that date or later.
But on to the newer changes. For the bugfixes I will describe which
bot(s) is or are affected, and what goes wrong with older versions.
"int." means that the bug has been introduced in some earlier version.
Bugs both introduced and solved in the current period have not been
mentioned. For all changes the files and versions that are needed are
mentioned.
Andre Engels
== Dependencies ==
In general, if error messages occur upon downloading a new version of
a bot, getting a new version of wikipedia.py as well would be the
first idea. Versions of wikipedia.py 1.405 and higher need family.py
1.21 (and vice versa)
== Bug fixes ==
* general * wikipedia.py 1.397 (int. 1.392 - does not count number
of bot processes correctly)
* general * wikipedia.py 1.397 (int. 1.392 - cannot edit redirect
pages and cannot create new pages)
* general * wikipedia.py 1.406 (is unable to edit after having been
dormant for some time)
* catall.py * catall.py 1.13 (int. 1.12 - gives an error message
before ending)
* category.py * category.py 1.62 (int. 1.61 - major disfunction)
* category.py (and others) * catlib.py 1.32 (finds at most 200
articles in a category)
* interwiki.py * family.py 1.20 (does not find pages on csb:)
* interwiki.py * family.py 1.21, wikipedia.py 1.406 (does not
recognize [[{xx:PAGENAME}]] interwiki links and a few redirects)
* interwiki.py * interwiki.py 1.135 (crashes when the -continue
option is used with an empty dumpfile)
* interwiki.py * interwiki.py 1.136 (chance of not being removed
from the list of bot processes if stopped *very* soon after being
started)
* interwiki.py * titletranslate.py 1.38 (crashes when a non-existing
language is given as a hint)
* pagefromfile.py * pagefromfile.py 1.7 (int. 1.6 - gives error
message at end and is not removed from the list)
* pagefromfile.py * pagefromfile.py 1.8 (the option "-end" is not recognized)
* redirect.py * redirect.py 1.19 (int 1.18 - major disfunction)
* replace.py * replace.py 1.35 (int. 1.6 - gives error message at
end and is not removed from the list)
== Major changes ==
* interwiki.py can now, when asking for hints, be asked for the text
of the page by typing "?" or adding the "-showpage option *
interwiki.py 1.136
* replace.py and solve_disambiguation.py now give their diffs colored
(Unix only) * replace.py 1.37, solve_disambiguation.py 1.128,
wikipedia.py 1.404
* Two new features of sqldump.py: findr finds regular expressions; the
function of baddisambiguation is not clear to me * sqldump.py 1.17
* interwiki.py uses nb: instead of no: in presence of an nn: link or
on the nn: wiki * interwiki.py 1.139
== Minor changes ==
* Swedish translations for interwiki.py: interwiki.py 1.137
* Change of Icelandic text for category.py: category.py 1.63
* Hawaiian and Chichewa added to known languages (wiktionary only
Hawaiian yet): wikipedia_family.py 1.89, wiktionary_family 1.21
== Cosmetic changes / invisible changes ==
* Multiple alternative redirect texts for one language are supported:
wikipedia.py 1.406
* Special care for zh-cn/zh-tw difference removed: interwiki.py 1.139,
wikipedia.py 1.408
Hi all!
May I ask someone with the proper access to update the interwiki table
at cs: Wikipedia? At least "os:" does not work as an interlanguage
link there. See e.g. the bottom of http://cs.wikipedia.org/wiki/2005
Thanks,
-- [[cs:User:Mormegil | Petr Kadlec]]
Forwarding this from wikipedia-l
============================================================
Again: the dead Abkhazian, Avar (and tens of others) are on the list,
while the 150-article Ossetian is not. Sometimes I feel that the
Ossetian VP is an independent something, standing _by_, not _in_, the
Wikipedia project... :(
Can someone fix the problem? The code "os" is not in the lists of
wikipedias: that causes, e. g., not working interwiki links from other
wikipedias to the Ossetian. See the bottom of this page:
http://ru.wikipedia.org/wiki/Владикавказ
If _you_ don't know how to fix, do resend this message to a person who CAN.
Grateful beforehand,
Sl. Ivanov
On Apr 2, 2005 5:37 AM, Erik Zachte <e.p.zachte(a)chello.nl> wrote:
> Wikistats are now available for all Wikimedia projects.
>
--
Esperu cxiam!
_______________________________________________
Wikipedia-l mailing list
Wikipedia-l(a)Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
Hi,
There is a need for a special syntax for texts in verse, as
: creates an indentation and <br/> is quite ugly.
Could it be possible to have a code <verse>
which would produce carriage return at the end of each line ?
Thanks,
Yann
--
http://www.non-violence.org/ | Site collaboratif sur la non-violence
http://www.forget-me.net/ | Alternatives sur le Net
http://fr.wikipedia.org/ | Encyclopédie libre
http://www.forget-me.net/pro/ | Formations et services Linux
I've added a rev_deleted field to the revision table in CVS HEAD. If
running a wiki on 1.5 CVS currently, run update.php or manually source
maintenance/archives/patch-rev_deleted.sql to update the table.
This will be part of changes to the deletion system, not yet fully
implemented:
* Deleted revisions will remain listed in the contributions history
(though greyed out and in strike-through), making it easier to track
serial offenders.
* Deleted revisions will be listed in the regular page history (again,
grayed out and in strike-through). In cases where individual revisions
have been struck from a page for eg copyright reasons this will make it
easier to see where portions were removed.
* The actual text won't have to be shuffled into an archive table;
simply updating a 1-byte field in the revision records ought to be
faster, and this will allow deletion again on pages which have been
block-compressed. (Block compression combines multiple revisions' text
into a single compressed record; since this interacts poorly with the
current deletion/undeletion system, deletion is currently disabled for
any page which has been block-compressed.) Deleted text could be pruned
at leisure by a batch or background process if necessary.
* For admins, the diff and view source tools will remain available on
deleted pages, which the current Special:Undelete viewer doesn't
provide. This can aid in analysis of a vandalism spree.
The deletion/undeletion system has not yet been updated to actually use
this field, nor has limitation of viewing of such revisions to admins
been implemented. (Remember the purpose of _deletion_ is to make
materials inaccessible to the public, especially if for legal reasons,
so non-admins will still not be able to look at the actual deleted
revision text.)
Once finished there will probably be a slight change to the page table
as well, to mark pages which have no non-deleted revisions.
-- brion vibber (brion @ pobox.com)