>> * The conversion of article titles didn't work. So many
>> articles are now in
>> http://de-beta.wikipedia.org/wiki/Spezial%3ALonelypages
>> (e.g. [[Brian De Palma]] should have been converted to
>> [[Brian de Palma]]).
> Whoever did the conversion (Lee? Magnus?), what exactly did
> you run? For Usemode-to-phase II conversion there is a
> *separate* script (recaseLinks.php) that does the renaming/case
> correction, which is to be run after importing the data into MySQL.
Ah, thanks. I just ran the wiki-to-SQL script. Is there anything
else I need to know about converting up to the Phase II stage?
>> * /Talk-pages should have been converted into the
>> Diskussion:-namespace (like the /Diskussion-pages). It didn't
>> work, but a "See also: " (should be: "Siehe auch:") has been
>> inserted.
I'll look into that.
On Sat, Aug 24, 2002 at 02:42:37PM +0200, Jaap van Ganswijk wrote:
>
> Please also consider that font problems may seem to be solved for now, but
> how local is that solution?
Fonts? I assume you mean character encodings. At the moment the script is
ISO-8859-1 (Latin-1) oriented. It's widely supported by most browsers and
certainly not MS-based. When it becomes necessary this will be extended to
UTF-8 which at the moment is already quite well supported.
>UPDATE user SET user_rights="is_sysop";
>should do it.
Um, yes, but it will also make every user in the database
a sysop. Probably not what he had in mind...
Hello there!
I'm loving the Wikipedia PHP Script, and solving my all my install
problems except one. I'm not quite sure how to edit the tinyblog
user_rights field so that I can become a sysop of my own site! Does
anyone have a php script or an SQL query to do it?
Also, this might not be the place, but I've noticed how cool the
wikipedia.com's mod_rewrite is, but I don't know how to use it? Is there
a simple setup text file on how to use mod_rewrite with Wikipedia?
Thanks in advance!
Seer
--
Seer Snively -- Network Administrator -- NetHelpNow.com
seer(a)nethelpnow.com "The medium is the message." -- Marshall McLuhan
> I'm loving the Wikipedia PHP Script, and solving my all my
> install problems except one. I'm not quite sure how to edit
> the tinyblog user_rights field so that I can become a sysop
> of my own site! Does anyone have a php script or an SQL query
> to do it?
If you're using the Phase III software (the stuff in the
"newcodebase" directory, then just use this SQL query:
UPDATE user SET user_rights='sysop,developer' WHERE user_id=X;
(where X is your user id, which you can determine with s SELECT
query). In the Phase II software, replace "sysop" and "developer"
with "is_sysop" and "is_developer". If you only want one or the
other, omit the comma.
> Also, this might not be the place, but I've noticed how cool the
> wikipedia.com's mod_rewrite is, but I don't know how to use it?
> Is there a simple setup text file on how to use mod_rewrite with
> Wikipedia?
In general, using "mod_rewrite" and "simple" in the same sentence
is a non-sequitur. The full documentation is on Apache's site.
The incantation used at wikipedia.org is this:
RewriteEngine On
RewriteRule ^/wiki/(.*)$ /w/wiki.phtml?title=$1 [NE]
RewriteRule ^/w/wiki.phtml(.*) /w/wiki.phtml$1
RewriteRule ^/wiki$ /w/wiki.phtml
RewriteRule ^/$ /w/wiki.phtml
RewriteRule ^/wiki.phtml/(.*)$ /w/wiki.phtml/$1 [NE]
RewriteRule ^/wiki.phtml$ /w/wiki.phtml
This is with the software installed in the "/w" directory
(I don't like installing stuff in the document root--it's too
inflexible for later changes. But those last two lines make
it look as if it's installed at root). If you install the
scripts in a different directory, or want different URLs,
modify the above appropriately.
Today Friday, the front page of the English Wikipedia has been fast
all day.
Another page (I monitor http://www.wikipedia.com/wiki/Sweden) was slow
for one period of 30 minutes (09:30-10:00 am GMT) and another period
of two hours (11:40-13:50 GMT). Some other URLs on the international
Wikipedias were also affected at the same time. This might be due to
maintenance or work being done on the scripts.
Subtract 7 hours from GMT to get the server's local time zone
(PDT = GMT -0700).
Apart from these two limited intervals, every URL that I monitor have
been fast all day, including the recent changes pages.
I'm very happy with this, and hope Brion and Jimmy (and who else?)
will soon get the talk namespace links back without hurting
performance. (But hey, never make big fixes five minutes before you
leave for the weekend! Better just leave it as is if you have to go.)
And now for some more relaxed Friday reading, actually related to
performance problems. (The following analysis might be politically
slanted. Don't take it too seriously.) The Swedish parliament
elections are coming up in September, so the political parties are
starting up their campaigns. The problem is there are no big issues
to fight about. The four non-socialist parties have unusually boring
candidates (Dukakis style), and everybody expects the current
social-democratic government to win. The single issue that seems to
be coming up is the national sick leave insurance, which is paid by
tax money, and far over budget. This is linked to the fact that
"burn-out" is now an accepted medical diagnosis for which you are
allowed to take a long sick leave on the tax payers' expense. You
would expect such welfare excesses to be on the social democrat
agenda, and that non-socialists would urge for tax cuts and a balanced
budget. However, the current s-d govt has been doing a great job
balancing the budget, and they will now have to deal with cutting back
this overgenerous sick leave compensation without hurting their
voters' feelings. Tough job. The Christian-democratic party's
candidate has already hurt a lot of feelings by claiming that "some"
of those receiving compensation are "cheating the system". That might
be true, but accusing "some" (who? me?) is obviously not the way to
attract voters. This issue now has media attention and some
interesting example cases are reported.
Like this one: Attorneys in Swedish district courts have been
right-sized in the past years, as part of balancing the budget. This
means that as soon as one gets sick, the rest get too much to do,
leading to stress and burn-out, which leads to more sick leaves.
Think of the court cases as HTTP requests arriving to Wikipedia.
There are some processes/attorneys there to handle the cases, but for
some reason one process gets blocked and cannot work. This leaves
more work for the remaining workers, but they are probably waiting for
the first process to get finished and unlock the resources (database
records?) that it is using. If processes are allowed to go to sleep
waiting for each other, the work will pile up. It will never end.
So, what is the solution? Throwing more attorneys at the problem?
Maybe, but more likely the work processes should be redesigned and
simplified. That allows the available attorneys to finish up a case
and take on the next one. Some of their tasks are more important than
others, but the performance or throughput of the system depends on
cutting away or redesigning the most time-consuming tasks. The high
degree of sick-leave is an indicator of system design flaws (albeit an
one), and thus not altogether bad.
In the same way, a high "load average" (as reported by the "uptime" or
"top" commands) is one indicator that the Wikipedia system is flawed.
The load average in a UNIX system is the number of processes that are
ready to run, waiting for the CPU to become available. Unfortunately,
most of them are just waiting to see if their wanted resource has
become available. If this is not the case (e.g. database record still
locked), they will go back to the end of the line, waiting again. Do
you remember those bread shop waiting lines in Soviet Russia?
Training new attorneys is in itself a time-consuming task, which
should be avoided if possible. Instead of paying sick leave (for how
long?) to the already trained attorneys, a "cure" for "burn-out"
should be found that can bring them back to work, thus relieving the
overload from their colleagues and saving tax payers' money at the
same time.
I have no idea how a "cure" for burn-out can be found, but I think it
is a necessary political trick, and thus will happen. It will not
hurt voters' feelings, and it is my guess that the people who can
achieve this will work for the winners of the election.
This might be the weakest analogy in history, but I think we should
treat the Wikipedia processes with the same dignity and respect that
the Swedish voters would expect. After all, they're supposed to work
for us. The processes feel self-fulfillment when they can finish
their job on time, and get distressed when they get locked up. Any
uncalled for delay will only result in more work piling up. That is a
flaw in the system design that has to be fixed, and we cannot go
around claiming that "some" of the workers are trying to cheat the
system. That will only lead to us losing their confidence.
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik
Teknikringen 1e, SE-583 30 Linuxköping, Sweden
tel +46-70-7891609
http://aronsson.se/http://elektrosmog.nu/http://susning.nu/
>For those wikipedias that /should/ be using the same codebase, it
>seems reasonable to me that they should have all of the scripts
>symlinked to the scripts of the main wikipedia. Then, any
>configurable variables could be exported by Apache as ENV variables.
>By doing this, you avoid running a script to update things, a person
>doesn't have to update them manually, and all of the apropriate
>wikipedias will be running the same software...
That will work wonderfully up to the first time we make a software
update that requires a database change. In that case, we want to
make sure that the upgrade process incudes the database update, and
each one has to be done individually.
> Woulnd't it be better to have a set-up where all updates to
> the codebase of the English Wikipedia are (semi-)automatically
> propagated to all Wikipedias that use the same codebase? If not
> I fear that the non-English Wikipedias will keep on lagging behind
> on the bug fixes or new features such the enhanced recent changes
> page or subtle (or not so subtle) changes in the markup language,
> or whatever changes are yet to come. Making the updates automatic
> would also ensure that all future changes in the Wikipedia are
> internationalization aware, because if they're not the bug reports
> will start coming in from the non-English Wikpedias.
I'm inclined to think that if a particular community isn't large
enough to come up with a developer to take care of its own needs,
then it /should/ be left behind. UseMod wiki is a fine piece of
software for a small level of activity, and if a group never
outgrows it, I don't see any reason for me to waste time and
effort on them. The German, Spanish, and Polish guys are on the
ball and won't be a problem. But I don't plan to make much effort
on behalf of the others unless they can come up with someone
from among their own ranks with the energy and skills necessary
to take care of themselves.
>> [...] The code is also organized so that if, say, I add a
>> special page and update the code of the foreign version, that
>> special page will appear in the foreign version, but with
>> English text; they can add the translation for that page at
>> any time, no coordination needed.
> If *you* update the code of the foreign version? Does that mean
> that you would also take care of installing the updated code for
> the foreign versions? That would take all my worries away, but I
> was under the impression you wanted to leave that to the local
> developers.
Well, read that as "if the code gets updated from CVS", by
whoever. When I update the main code with something like a bug
fix, it will be a pretty trivial thing for me to update the
forgeign ones at the same time, so I'll probably do that. But
I also might forget. Also, someone like Magnus might fix a bug
and update only the German installation, leaving me to update
the English one later.
Jimbo moved us to the new server in part so he could give
accounts out more freely (currently I, Axel, Brion, Magnus, and
Neil have accounts there), so he would no longer be a bottleneck
or a single point of failure. It makes no sense to just make me
the bottleneck instead (although I'm sure Jimbo sees that as an
improvement :-)
> Perhaps I'm only stating the obvious here, but I would suggest
> the following guidelines:
> - Local developers can make always updates in local parts
> of the code, for updates in the common part of the code they
> should ask Lee's permisson.
> - When a new version of the code is installed for the English
> Wikipedia then this should be announced (on Wikitech-l) and
> then installed on local Wikipedias by the local developers as
> soon as possible.
> - Local developers are responsible for putting local bug-reports
> on something in the common code in the Sourceforge bugtracker.
It should be simpler than that. There is only one codebase, and
it contains only one language-specific file: "LanguageDe.php",
"LanguageEs.php", and so on, all of which are kept in the single
codebase. There'a also a "LocalSettings.php" for each install,
but that doesn't change once installed.
Those files can be changed at will by anyone without affecting
the English wiki, and should be. The code is also organized so
that if, say, I add a special page and update the code of the
foreign version, that special page will appear in the foreign
version, but with English text; they can add the translation for
that page at any time, no coordination needed.
I also don't have any problem with Brion, Magnus, you, and other
developers doing direct checkins. I'd prefer that such new checkins
be tested on my server before installing them on the wiki server,
but even there I can see small bug fixes not wanting to bother.
In short, I don't think we need to worry about coordination unless
one of the groups decides to "fork" the code for some reason, and
in that case I'd try to talk them out of it, but if they really
wanted to do it, they're free to, and then they'd definitely be on
their own.