www.wikipedia.com gives me
Warning: Too many connections in /home/wiki-newest/work-http/databaseFunctions.php
on line 11
Could not connect to MySQL server:
Why that? Did this ever happen before?
________________________________________
Online Fotoalben - jetzt kostenlos bei http://www.ePost.de
I've re-ordered the Cologne blue sidebar to try and make it a bit more
ergonomic, with no real rationale, just a feel for what I do, and a
guess at the expectations of new users. The general principles are:
* rule of 3s
* most used categories at the top
* most frequent choices in those categories at the top
* don't repeat any options
...and I've moved some things into different categories: Recent Changes
into EDIT, for example, as it is mostly used when editing...
I'm not saying this is the best that can be done: I just want to kick
off a discussion of the options.
FIND
[search box] OK
BROWSE
Main Page
Random page
Current events
EDIT
Edit this page
Recent changes
Editing help
THIS PAGE
Talk page
Printable version
Watch this page
CONTEXT
What links here
Watch links
MY PAGES
My page
My watch list
My Preferences
Log out
SPECIAL PAGES
New pages
Image list
Statistics
Bug reports
more...
<http://beta.wikipedia.com/w/wiki.phtml?title=Kermit_the_Frog&action=history>
*** Sorry, that went to the wrong group. ***
Nice idea! Anyone remember the "auto-wikification" feature? This could be
one of its functions.
But, Lee is very cautious when it comes to software changing articles, and
he *does* have a point.
But, things like this could be on some kind of button, IMHO.
Magnus
> -----Original Message-----
> From: wikitech-l-admin(a)nupedia.com
> [mailto:wikitech-l-admin@nupedia.com]On Behalf Of Lars Aronsson
> Sent: Tuesday, July 16, 2002 10:59 PM
> To: wikitech-l(a)nupedia.com
> Subject: [Wikitech-l] Auto-harvesting of dates
>
>
> It is very easy to write a regexp that will recognize and parse dates in
> running text using formats like "July 14, 1789". That kind of automatic
> harvesting can be applied when a Wiki article is saved, and the dates
> found can be indexed and easily searchable.
>
> Was this alternative ever considered before the introduction of the
> current Wikipedia custom of writing [[July 14]], [[1789]]? Many people
> have spent their time adding [[]] markup to any years and dates in
> Wikipedia articles, and maintain the pages for dates and years. This time
> could have been saved if automatic harvesting and indexing had been used
> instead. (I am one of those persons.)
>
> The current Wikipedia custom is an entrenched position, that would take
> more energy to get out of than I dare think about. However, it is just as
> easy to write that regexp to recognize dates in formats like "[[July 14]],
> [[1789]]" instead.
>
> If you would like to test a function like this, visit
> http://susning.nu/Carl_Wilhelm_Scheele
> and click on this Swedish chemist's birth date "9 december 1742".
>
> My regexps recognize "99 monthname 9999", "monthname 9999", "year 9999",
> "born 9999", "died 9999", "9999-talet" (centuries and decades), which are
> the most common ways to specify dates in Swedish text. Clicking on a date
> leads to a search of adjacent dates found in other pages, chronologically
> sorted. Monthnames without day number are sorted before the 1st of that
> month. Years without months sort before January 1 of that year. Decades
> and centuries sort before the first year of the specified interval.
>
>
> --
> Lars Aronsson (lars(a)aronsson.se)
> tel +46-70-7891609
> http://aronsson.se/http://elektrosmog.nu/http://susning.nu/
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)ross.bomis.com
> http://ross.bomis.com/mailman/listinfo/wikitech-l
It is very easy to write a regexp that will recognize and parse dates in
running text using formats like "July 14, 1789". That kind of automatic
harvesting can be applied when a Wiki article is saved, and the dates
found can be indexed and easily searchable.
Was this alternative ever considered before the introduction of the
current Wikipedia custom of writing [[July 14]], [[1789]]? Many people
have spent their time adding [[]] markup to any years and dates in
Wikipedia articles, and maintain the pages for dates and years. This time
could have been saved if automatic harvesting and indexing had been used
instead. (I am one of those persons.)
The current Wikipedia custom is an entrenched position, that would take
more energy to get out of than I dare think about. However, it is just as
easy to write that regexp to recognize dates in formats like "[[July 14]],
[[1789]]" instead.
If you would like to test a function like this, visit
http://susning.nu/Carl_Wilhelm_Scheele
and click on this Swedish chemist's birth date "9 december 1742".
My regexps recognize "99 monthname 9999", "monthname 9999", "year 9999",
"born 9999", "died 9999", "9999-talet" (centuries and decades), which are
the most common ways to specify dates in Swedish text. Clicking on a date
leads to a search of adjacent dates found in other pages, chronologically
sorted. Monthnames without day number are sorted before the 1st of that
month. Years without months sort before January 1 of that year. Decades
and centuries sort before the first year of the specified interval.
--
Lars Aronsson (lars(a)aronsson.se)
tel +46-70-7891609
http://aronsson.se/http://elektrosmog.nu/http://susning.nu/
If this doesn't happen to Windows/IE and Netscape customers, it is probably not
particularly important.
http://beta.wikipedia.com/wiki/Special%3ARecentchanges
In mozilla, this page renders with the logo on top of the menu dropdown box and
the "Go" button. (Also, above that, the "Main Page" and "Recent Changes" links
have the logo on top of them.)
The features "under" the logo are all functional, it just looks ugly.
lcrocker(a)nupedia.com wrote:
>
> > http://beta.wikipedia.com/wiki/Special%3ARecentchanges
> >
> > In mozilla, this page renders with the logo on top of the menu
> > dropdown box and the "Go" button. (Also, above that, the "Main
> > Page" and "Recent Changes" links have the logo on top of them.)
>
> I'm not sure what you mean here; I'll need to know at least
> which Skin you're using and what your quickbar setting is. A
> screenshot would be nice.
I'm not logged in, so it's the default.
> I'd really like to see a screenshot.
Can you recommend a screenshot program?
--Jimbo
As for the links to large queries like the "5000" recent changes, it
occurs to me that the user can get any number he wants by composing
the URL himself, and anyone who actually wants a list of 5000 things
will probably know how to do that, so I removed all the big-number
links entirely, logged in and otherwise.
Also, Magnus showed me a SQL trick I'd never seen before ("order by
rand()"...wouldn't have thought of that) that enabled a much faster
implementation of RandomPage, and I thought that was worth changing
before the announcement and isolated enough that it's unlikely to
affect anything else in the code.
Those changes are installed and test well under the bots, so I'm going
to go ahead and announce the transition on the main list and the front
page to try to get some realistic user testing.
0
Many thanks to Neil Harris for the bots; They've been pounding on the
site for while now, and here's what we've learned:
- The size of the database isn't an issue. If Wikipedia doubles, or
more, performance won't be affected at all. This is what I would have
expected.
- Concurrent access does slow things down, but not pathologically.
I've got 16 bots running over two high-speed connectiions right now,
and the server isn't swapping. However, some pages do take longer to
serve than when load is light.
- Some special pages are still moderately slow (particularly "wanted"
and "random page"), but the real time hogs now are very long pages
with lots of links. Some particular hogs are "Current events",
"Chinese sovereign", "List of rare diseases" and long history pages
with lots of changes like main page and bug reports. The sample
scrabble game is the longest page, but it has very few links so it's
not as much of a hog, though it's still a problem.
"Current events" strikes me as a particularly big, yet solvable,
problem. We should come up with a way of breaking it into manageable
pieces. Chinese sovereign can clearly be broken up as well, and we
can do things like replace the Scrabble diagrams with images.
0
On Mon, 24 Jun 2002, Tomasz Wegrzanowski wrote:
> Count of all contributors would be over 30, but number of current
> active is certainly lower. How much lower depends on how you define
> "current active".
I guess the definition could be discussed, but here is my suggestion.
At the end of each month, I run statistics on the rclog file as produced
by the old UseModWiki software used in my Wiki site. This file contains
one line for every time anybody pressed "Save" (minor or major changes).
>From the file, I extract the user name for logged in users or "anonymous"
(counting all anonymous contributions as one user). Then I present a list
of all users who singlehandedly made more than 1% (actually .51% rounded
up) of all contributions.
There is no "typical" month yet, but for June 2002, there were 2990 lines
in my file, coming from 62 users (61 logged in and "anonymous"). The 23
most active users were listed, ranging from 512 contributions (17%) to 15
(1%). The "anonymous" user is normally the runner up, with myself in the
lead.
--
Lars Aronsson (lars(a)aronsson.se)
tel +46-70-7891609
http://aronsson.se/http://elektrosmog.nu/http://susning.nu/