I'm not 100% happy with the sidebar:
Main page
Recent changes
Watch list
Current events
--------------------
Edit this page
Watch this page
Move this page
Talk page | Subject page
History
What links here
Watch links
--------------------
Upload
Bug reports
Special pages
The links are perfectly OK, but I have problems with the words used and
sometimes with the positioning. I suggest the following sidebar:
Main Page
Recent changes
My watchlist
Random page
Current events
--------------------
Edit this page
Watch this page
Move this page
Discuss this page | View article
Older versions
What links here?
Link history
--------------------
Upload file
Special pages
Bug reports
Explanations:
- "Watch list" should be "My watchlist" to make clear that this is not a
page that is the same for all users, like the other links in this
section of the sidebar.
- "Talk page" should be "Discuss this page" to use the same imperative
style of the other links above it. Since users don't have to create
"/Talk" links anymore, it's not necessary that we use the actual word
"Talk" anywhere but in the URLs.
- "Subject page" should be "View article" or "Back to article". "Subject
page" is really ambiguous and hard to understand, I searched several
times for a way back to the article because I didn't find an obvious
link.
- "History" should be "Older versions" or "Page history" to be more
obvious. Most people are not familiar with the concept of article
histories.
- "What links here" needs a questionmark.
- "Watch links" should be "Link history", "Related changes" or something
else. "Watch links" suggests that this will add the links to my
watchlist, which it doesn't do.
- Upload should be "Upload file". True, a bit redundant, but more
familiar this way.
- Bug reports should be at the bottom as this is the least relevant.
Your thoughts? I'll be glad to patch this, although it should be easy
enough for someone with CVS access to do it on their own.
Regards,
Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de
Hi,
since the site stats are conveniently stored in the site_stats table, I
suggest subtracting the number of articles created by the Ram-Man bot
(US Census city information) from the total number of articles.
Why? The NOA is primarily interesting as a measure of our collaborative
progress. This is important for ourselves and for others. Personally,
I've had several discussions about Wikipedia where I was reluctant to
cite the NOA because of the high number of machine-generated articles,
others probably feel the same.
I therefore believe we should generally exclude autogenerated articles
(we can change the wording on Main_Page to reflect this). As it would be
a 5 minute task for anyone with access to the db, is there any reason
not to do it?
Regards,
Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de
I've been getting lag for about the past hour
that seems to be especially pronounced when saving articles.
Otherwise, it's slower than usual but still tolerable.
Saving, however, takes half a dozen minutes.
-- Toby
netscape?
by Wolfram.Steinacker＠t-online.de
02 Nov '02
02 Nov '02
Hallo, seit gestern sehe ich wikipedia nicht mehr unter netscape.
Es erscheint:
----
"Warning: Too many connections in
/usr/local/apache/htdocs-de/w/DatabaseFunctions.php on line 19
Konnte keine Verbindung zur Datenbank auf 127.0.0.1 herstellen
Too many connections
If this error persists after reloading and clearing your browser cache,
please notify the Wikipedia developers."
----
Wann ist das Betrachten unter netscape wieder möglich?
Grüße von
Wolfram
Hi,
as promised, I have looked a bit into the RC code for the purpose of
possibly implementing a filter. Since Ram-Man seems to be finished with
his script, this is no longer an urgent issue, so we might want to take
a step back and look at the design of SpecialRecentchanges.php etc.
before any further changes.
I have taken the liberty to import the Wikipedia database locally to
find out which operations are fast and which ones are slow even locally.
Long RC queries are quite slow on my machine, in spite of cur_timestamp
being indexed. Even with an index, searching a 350 MB+ table with fairly
random row order may be heavy. (Is there any way to determine if the
index is used, BTW? MySQL has some weird conditions under which it
ignores indexes.) It certainly is slow on my system.
Since this is one of the most commonly accessed functions, we should
really do some performance tuning here, especially as we will sooner or
later have to do stuff like the aforementioned bot-filtering, making
queries even more complex. I noticed that there is already a
recentchanges table that new rows are inserted into upon edits. Is a
move away from SELECTs on the CUR table already in the works? If so,
what is its current status and who's doing it?
Regards,
Erik Moeller
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de