Please take a look at http://en.wikipedia.org/stats/
December and January data are from an earlier year.
Dec 2002 and Jan 2003 instead of Dec 2003 and Jan 2004
The files that were supposed to be linked here do not exist
E.g. http://en.wikipedia.org/stats/usage_200401.html
I will soon add detailed wikistats based on these files,
so a two month gap in en: data would be a pity.
However, please do not delete the 'obsolete' files shown from disk.
They should not be linked from en.wikipedia.org/stats
but I'd like to parse any access history that is available for wikistats.
Erik Zachte
It has just been brought to my attention (well, rather: I found out)
that on the German Wikipedia, if someone submits a text that constitutes
a copyright violation, the sysops there immediately delete the complete
page history and reinstate the most recent version before the copyvio.
This is a pretty serious issue; I'm pretty sure that this is not
GFDL-legal (while, obviously, keeping the copyvio in the page history
isn't either); it removes legitimate contributions from legitimate
users; and less seriously, it messes up statistics.
I am therefore strongly suggesting that someone add a feature whereby a
sysop can delete a single previous revision, rather than the entire
history of a page.
It would probably suffice to delete just from the 'old' table; if you
want to delete the most current revision, you should probably revert to
an older version first anyway, thereby moving the one you want to delete
to the 'old' table.
Timwi
There've been some glitches in transferring wikipedia.com to the new
DNS regime, which hopefully should be resolved (har har) soon.
Valuable lesson about life: beware register.com
-- brion vibber (brion @ pobox.com)
The web page for making a user into a sysop or bureaucrat has two
glitches.
1. If you make a user a sysop who is already a sysop, you get a
perplexing error message like "can't make him a sysop". It should either
report success, like "he's a sysop"; or report the redundant action,
like "he already was a sysop".
2. When you make a sysop into a bureaucrat, it should NOT say "User
'Optim' is now a sysop" because he already WAS one. It should say that
he's now a BUREAUCRAT.
Ed Poor
Developer, Bureaucrat, Sysop
Wikien-l Admin
...and all around nice guy :-)
Word on the street is that load's going to be extra high today thanks
to some print exposure in Germany. I've taken the occasion to
stress-test Coronelli running its cache server under 2.6... Browne
(which was carrying all wikis but English) was starting to have its
periodic freezes, and at least one squid crash. I switched the .235
address over to Coronelli, so it's now handling _all_ incoming traffic.
So far it seems to be handling it smoothly; I'm not seeing the freezes
that browne had. We can switch one or both addresses back to browne if
needed.
[brion@coronelli brion]$ uptime
09:57:36 up 2 days, 7:25, 8 users, load average: 1.66, 1.78, 1.23
Some vmstat fragments:
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
2 1 9996 8128 151056 884652 21 0 107 591 1358 294 13
42 35 10
1 0 9996 9216 150652 884684 11 0 153 49 1552 408 12
44 39 5
2 1 9996 8796 150748 885064 0 0 91 615 1016 214 7
42 39 12
1 1 9996 8672 150784 885164 0 0 80 236 981 217 6
37 52 5
1 6 9996 8416 150856 885364 0 0 69 784 835 249 5
34 12 49
9 2 9996 8856 150916 885508 0 0 45 824 773 251 6
27 25 43
0 0 9996 8368 150968 885796 0 0 87 303 871 235 8
31 32 29
1 0 9996 7664 151048 886464 0 0 99 368 1121 293 13
40 40 7
6 1 9996 9012 150896 885256 0 0 61 701 1358 303 14
43 36 7
1 0 9996 8356 150980 886056 0 0 128 1 1590 458 15
41 38 5
-- brion vibber (brion @ pobox.com)
Based on the unstable branch, the article "MediaWiki:All_messages", used
for maintaining msg values is an interesting idea, but I believe this
would be better built as a dynamically built page, i.e. as
"special:all_messages", rather than as a static page in the database.
This would get around the use of external links to edit the variables
instead of internal links. Is this done to avoid the slow operation of
resolving [[...]] at run time? The problem is that this makes the database
non-portable between wiki sites.
This causes a problem at our site because we update the database on a
development server and then move it to our working server. It means I have
to manually edit this page to change all the external links marked up on
that page.
It may also cause problems because WikiMedia distributes the wikipedia
database. That database also will not be portable.
I notice that on the wikipedia site, the similarly sized article
"Wikipedia:MediaWiki custom messages" does use internal links and seems to
resolve in about the same amount of time.
We plan to actually change the variable '$wgServer' at run time. We want
to present the server address differently if the user links to our site
via our VPN intranet versus coming in through an external URL via the
Internet. So, we rather not have the server domain defined in the
database, but always dynamically determined.
By making All_messages a special page, you can hide it to all but sysops,
developers and/or bureaucrats, who are probably the ones who should see
and maintain these variables. It also will mean that, that as a developer,
if you add variables to "$wgAllMessagesEn" this page will be up to date
without having to run an install procedure.
I also notice this page is built from the variable '$wgAllMessagesEn'. If
this were built as a 'special' page, it could build using the language the
site actually represents.
Nick Pisarro
There've been lots of complaints about the MediaWiki installation
script over time, and with good reason! We don't actually use it for
Wikipedia since it doesn't fit our needs (centralized repository of
scripts for over a hundred wikis with near-identical config), nor does
it fit the needs of a lot of people trying to set up their own wikis,
who often don't have shell access to their web servers or root access
to the database.
I've checked in the beginnings of a new install script that doesn't
require shell access, root database access, or a separate place to put
the source files and the installation. You can just unzip the archive,
copy the directory tree to your web space, and run the configuration
script through the web like with any civilized PHP app with relatively
minimal fiddling.
At the moment it can create a configuration file that works with an
existing database, but doesn't yet do the database setup. I'll try to
get that merged in from the old command-line install script tonight or
tomorrow and release 1.2.0rc2 with it included.
(Tech note: we need to be sure that the maintenance scripts aren't
dangerous to have sitting around.)
-- brion vibber (brion @ pobox.com)
On the identification page on the french wikipedia, I have a <loginend>
that is added at the end of the page, just below the "send me a new email".
it is not the case on en:
Is it a software issue, or a bug from our translation ?
Thanks
ant
MediaWiki 1.2.0rc1 is now available for download at:
https://sourceforge.net/project/showfiles.php?group_id=34373
This is a release candidate, and may contain a few rough edges still.
Those feeling adventurous, please try it out -- on a safe server after
backing up all your data -- and please report any exciting new
problems. If we don't hear about your problems, they'll never get
fixed!
A few notes:
* Things should again work out of the box with MySQL 3.x (though 4.x is
preferred).
* We are now compatible with short_open_tag = Off
* wiki.phtml and redirect.phtml have now become index.php and
redirect.php to improve compatibility. The old names are still
available for compatibility, so you don't have to change your
configuration for existing installs. If you're mixing other stuff in
with the wiki's install directory, please be sure this doesn't conflict
with other existing files!
* Installation now prompts you to ask if you want to create a sysop or
developer account and lets you pick the name and password instead of
using the AdminSettings.php defaults.
* A new page, Special:Version lists the MediaWiki, PHP, and MySQL
version numbers. Please don't forget to note these when reporting bugs!
We tend to track current production releases of PHP and MySQL, and
sometimes things break on older or experimental versions of these that
we don't always see.
Database messages are now on by default, you can turn this off if the
performance hit is too great. We hope to improve the speed of this
soon.
A couple things we don't have in yet:
* We don't yet have an installer that's friendly to those without shell
access, sorry. Hopefully we'll have something for 1.2.0 final.
* We still require register_globals = On.
* No PHP5 compatibility. I know there are a few keyword conflicts which
should be easy to fix, but we haven't tested this yet.
See the file RELEASE-NOTES for a bit on the new features and bug fixes.
You can report problems at SourceForge at:
http://sourceforge.net/tracker/?group_id=34373&atid=411192
-- brion vibber (brion @ pobox.com)
Hi,
a new parser for internal links [[...]] and ''quotes''
has been committed to cvs HEAD.
Using the new parser, image thumbnail captions can
have links via [[Image:bla.jpg|thumb|A big [[bla]] I've photographed]].
The code has broken prefixed links that are used by ar: (Al[[razi]]
kind of links). I'll have to fix this tomorow.
A test page is available at
http://jeluf.mormo.org/testwiki/wiki.phtml?title=London
Regards,
JeLuF