body:
Your questions, with brief answers (as non-tech as I could manage;) are now
at
	http://www.wikipedia.com/wiki/Wikipedia:PHP_script_FAQ

Help expanding (even questions will help; I'll try to answer them).

Magnus

> -----Original Message-----
> From: wikipedia-l-admin at nupedia.com
> [mailto:wikipedia-l-admin at nupedia.com]On Behalf Of Julie Kemp
> Sent: Friday, February 08, 2002 10:47 PM
> To: wikipedia-l at nupedia.com
> Subject: [Wikipedia-l] Re: Documentation and user aids
>
>
> HI all --
>
> Magnus, it wasn't really aimed all at you, because
> frankly I'm not sure who does what!
>
> Although I truly appreciate the documentation =
> ironing thing, there needs to be something.  And
> unfortunately, your answer waas sooooo programmer!
> Most people aren't.  I'm lucky because I've actually
> had to translate geekspeak to sales/customer support
> in a couple of jobs, so I had an inkling, but frankly
> the discussion bored the hell out of me because it
> never got to the user level.
>
> Yes, you guys let interested parties know what was
> going on -- i.e., that changes were being made -- but
> not how those changes would affect the site and its
> use in user-speak.
>
> Here are some very fundamental issues that need
> addressing:
>
> 1)  What happened to sub-pages and why
>
> 2)  What the HELL is a namespace (and a ton of related
> questions -- like if there are no subpages, why is
> there a talk link?
>
> 3)What changes have been made to the use of certain
> punctuation marks in titles?
>
> 4)Where subpages once existed, how did the conversion
> affect them?
>
> 5) HOw do I redirect?  (If it's the same as before, it
> doesn't seem to work with articles entitled with
> people's names)
>
> Lots of questions!  NO answers.  I suggest a New
> Features special page that has FAQs and a kind of tour
> for newbies and those of us who have been around a
> while but just want to use the site -- and don't
> really care how it works, as long as it does!! ;-)
>
> I will help in any way I can, but I really think we
> need something!  [[JHK]]
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Send FREE Valentine eCards with Yahoo! Greetings!
> http://greetings.yahoo.com
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


list: wikitech-l

source: pipermail-mbox

from_name: Jimmy Wales

subject: [Wikitech-l] slow query log

body:
O.k., I've enabled this and glanced through it a bit.  It's pretty
interesting, even though I only have a small handful of values in it.

I think what I'll do is leave it on overnight, and then gzip it for
everyone to download tomorrow.  (Or perhaps I'll just gzip the output
of mysqldumpslow, which summarizes it a bit.  Or perhaps I'll slap together
a quick perl script to boil it down to the essentials for our context.)

SELECT * FROM cur WHERE (cur_title NOT LIKE "S") AND (cur_text LIKE "S" )
ORDER BY cur_title

seems to be a big offender.  That's the special_dosearch query, I think.

Also, here's a fun looking query:
  SELECT * FROM cur WHERE (cur_title NOT LIKE "S") AND ( (cur_title LIKE "S" OR
cur_title LIKE "S") AND (cur_title LIKE "S" OR cur_title LIKE "S") AND (cur_titl
e LIKE "S" OR cur_title LIKE "S") AND (cur_title LIKE "S" OR cur_title LIKE "S")
 AND (cur_title LIKE "S" OR cur_title LIKE "S") ) ORDER BY cur_title

I'm no database expert, but that doesn't look so sensible to me. :-)


from_name: Axel Boldt

subject: [Wikitech-l] Speedup suggestions

body:
Browsing around on http://www.mysql.com/documentation/ and comparing
with the wikipedia.sql in cvs, I have the following suggestions:

1) To speed up searches, we should use a FULLTEXT index on title and
   text, and then use the match operator. That should also yield more
   relevant results.
   (http://www.mysql.com/doc/F/u/Fulltext_Search.html)

2) In special_recentchanges.php, we select with "WHERE
   cur_timestamp>$mindate", but cur_timestamp is not indexed. This
   means that mysql linearly searches through the whole cur database,
   everytime somebody views RecentChanges.

3) Assuming that php runs as an apache module, we should use
   persistent database connections. That way, we won't repeatedly send
   over the username and password; one connection is reused by apache
   even after the php script dies.
   (http://www.phpbuilder.com/manual/features.persistent-connections.php
   and http://www.phpbuilder.com/manual/function.mysql-pconnect.php)

Axel


from_name: Hr. Daniel Mikkelsen

subject: [Wikitech-l] Speedup suggestions

body:
> 2) In special_recentchanges.php, we select with "WHERE
>    cur_timestamp>$mindate", but cur_timestamp is not indexed. This
>    means that mysql linearly searches through the whole cur database,
>    everytime somebody views RecentChanges.

Why not simply log change-events to a separate table, and display data
from that log depending on the user's filter? Changes older than, say, two
weeks could be discarded by a cronjob.

-- Daniel


list: wikipedia-l

from_name: Lars Aronsson

subject: [Wikipedia-l] Optimizing the Wiki parser

body:
Uri Yanover wrote:
> Well, while easiness of debugging is important, it
> is still possible to write a good parser that would

How do you know that the current parser is bad?  Do you have numbers
(measurements from the live website) that indicate that the regexp
parsing is the bottleneck in the performance of today's Wikipedia
website?  Or do you just want to write a parser?  (I know writing
parsers can be great fun, seriously, but I think this discussion
should focus on fixing the performance problems.)

Sometimes, a simple access to http://www.wikipedia.com/wiki/Biology
takes 11 seconds, sometimes it takes 2 seconds.  When it takes longer,
is it because too much CPU time is spent in regexp parsing?  How can
we know this?  From profiling the running server?  Or is my HTTP
request put on hold for some other reason (database locks, swapping,
I/O waits, network congestion, ..., or too much CPU time spent on some
other task)?  If regexp parsing really is the bottleneck, how much
more efficient can a new parser be?  Twice as fast?  Is it possible to
add more hardware (multiprocessor) instead?

--
  Lars Aronsson
  <lars at aronsson.se>
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/


from_name: Magnus Manske

subject: [Wikitech-l] Speedup suggestions

body:
Weird. I tried the mysql_pconnect thing a few days ago (on a suggestion from
Brion), and I didn't see any noticable effect at all, so I didn't commit it
to the repository.

Must be the multiple-user effect, or the configuration.

> -----Original Message-----
> From: wikitech-l-admin at nupedia.com
> [mailto:wikitech-l-admin at nupedia.com]On Behalf Of Jimmy Wales
> Sent: Friday, February 08, 2002 11:56 PM
> To: wikitech-l at nupedia.com
> Subject: Re: [Wikitech-l] Speedup suggestions
>
>
> Axel Boldt wrote:
> > 3) Assuming that php runs as an apache module, we should use
> >    persistent database connections. That way, we won't repeatedly send
> >    over the username and password; one connection is reused by apache
> >    even after the php script dies.
> >    (http://www.phpbuilder.com/manual/features.persistent-connections.php
> >    and http://www.phpbuilder.com/manual/function.mysql-pconnect.php)
>
> After reading these two pages, it seemed that all I needed to do
> was change
> mysql_connect in databaseFunctions.php to mysql_pconnect.
>
> It's a little early to get *too* excited, but so far the results
> seem astonishing!
>
> This is the first time I've seen the 5 minute load on the machine
> under 3 in days.
> And it's 0.46 now.
>
> Also, I'm getting 2.52 pages per second from my little
> benchmarking tool.  This is
> dramatically better than the 1/2 page per second pace we've been seeing.
>
> --Jimbo
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at ross.bomis.com
> http://ross.bomis.com/mailman/listinfo/wikitech-l


from_name: Jan Hidders

body:
> Is there an easy way in mysql to turn on some logging to see which
> queries are taking the longest?

See http://www.mysql.com/doc/L/o/Log_Files.html and esp.
http://www.mysql.com/doc/S/l/Slow_query_log.html

Let me know the results ASAP because I would really like some real data on
where the real problems are.

-- Jan Hidders


subject: [Wikitech-l] Old cache on Main Page

body:
I'm not sure if this will be fixed with the next bugfix, but I edited the
Main Page (twice) to remove the counter, but I still get the old cached page
("23.338 articles").


from_name: Brion L. VIBBER

subject: [Wikitech-l] Questions about installing

body:
I wrote:

> Ah, that reminds me. On the subject of namespaces: to what degree can
> we localize these? The names of the "special:" pages are hidden away
> behind localized titles, and a "wikipedia:" namespace sounds fine, but
> "user:", "talk", "user talk:" and "wikipedia talk:" are probably less
> than ideal, particularly where local words such as "discuter",
> "dyskusja", "priparolu", etc are well-established. Would there be any
> objection to localizing these namespaces? They're currently hard-coded
> in English.

Well, since no one's complained yet, I've started on that. :) Please use
the $wikiUser and $wikiText variables as defined in wikiText*.php rather
than hardcoding "user" and "talk" in the namespaces from now on.

-- brion vibber (brion @ pobox.com)


from_name: Uri Yanover

body:
> How do you know that the current parser is bad?  Do you have numbers
> (measurements from the live website) that indicate that the regexp
> parsing is the bottleneck in the performance of today's Wikipedia
> website?  Or do you just want to write a parser?  (I know writing
> parsers can be great fun, seriously, but I think this discussion
> should focus on fixing the performance problems.)

Well, I've got that impression from what Jan Hidders said.
Judging from the recent traffic on the list, the bigger problem
is with the database connection management, though, so
you've got a point here.

I still believe, however, that the current Wiki parser is far
from perfection, so that it will have to be re-written some
day. What I'd personally like to see as the first step is the
simplification and systematization of Wiki markup (e.g.
making all links use square brackets).

> Sometimes, a simple access to http://www.wikipedia.com/wiki/Biology
> takes 11 seconds, sometimes it takes 2 seconds.  When it takes longer,
> is it because too much CPU time is spent in regexp parsing?  How can
> we know this?  From profiling the running server?  Or is my HTTP
> request put on hold for some other reason (database locks, swapping,
> I/O waits, network congestion, ..., or too much CPU time spent on some
> other task)?  If regexp parsing really is the bottleneck, how much
> more efficient can a new parser be?  Twice as fast?  Is it possible to
> add more hardware (multiprocessor) instead?

Again, I set out from the position that the Wiki parser is
so inefficient that adding any additional markup (the
original subject of the discussion) would be devastating
to its performance. Even though the current slowdown
seems to originate in the database connectivity, I suspect
that parser speed will become the bottleneck some time
in the future.

Sincerely yours,
            Uri Yanover


subject: [Wikipedia-l] Hide minor edits

body:
I just noticed that some of you might *not* be aware of the "Hide minor
edits on Recent Changes" checkbox on your user preferences page. Someone
made a comment in his minor edit that implied everyone would be forced to
see it. Well, you're not!

Julie Kemp might want to include this factoid on the PHP Script FAQ page :)

I would also like to thank everybody who has been working on the software,
improving functionality, reliability, and performance over the last few
weeks. We're really getting somewhere here ;)

Magnus


subject: [Wikitech-l] License

body:
I think we should add the GPL license to the cvs tree and add a
copyright notice to the top of the scripts as soon as possible (just
take any GNU program as template). Right now, the number of
contributors is still small and we can still make this change. Later
it may get ugly.

Axel


subject: [Wikitech-l] Slow search queries

body:
> SELECT * FROM cur WHERE (cur_title NOT LIKE "S") AND (cur_text LIKE "S" )
> ORDER BY cur_title

>seems to be a big offender.  That's the special_dosearch query, I think.

Yes. That searches linearly through the whole database to search for a
string. That's a killer. It's like our old UseMod search before Jimbo wrote
an indexed one. A FULLTEXT index, together with MATCH instead
of LIKE, should give a major improvement.

Axel


subject: [Wikitech-l] License

in_reply_to: <200202091639.RAA04005@atm3.uni-paderborn.de>; from axel@uni-paderborn.de on Sat, Feb 09, 2002 at 05:39:10PM +0100

body:
I agree 1,000,000 percent!!  We're a small group and "we all know" that
the software is GPL, but we should formalize it.

We should put the "usual" COPYING files and whatever else normally
comes with GPL software into the CVS.  And from time to time, we
should generate a slightly more formal "release" with a version
number.

One feature that I think users of the software might want is an option

$ThisSiteIsReadOnlyMirror = 1;  # Well, maybe a better name could be chosen

A read only mirror site looks like a regular site, except all of the
edit links are gone, replaced by a link to visit the main site, or
something that seems like what most read-only licensees will want.

My view is that the software is _secondary_ to OUR project, the encyclopedia.
So I think we can focus our efforts on uses of the software that have to do
with the encyclopedia.  But of course, other people may want to use the software
for totally unrelated things.  That'll be cool, too.

--Jimbo

Axel Boldt wrote:

> I think we should add the GPL license to the cvs tree and add a
> copyright notice to the top of the scripts as soon as possible (just
> take any GNU program as template). Right now, the number of
> contributors is still small and we can still make this change. Later
> it may get ugly.
>
> Axel
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at ross.bomis.com
> http://ross.bomis.com/mailman/listinfo/wikitech-l


subject: [Wikitech-l] Proof of principle

in_reply_to: <ILENJBCFHGHELEBFPPBGAEFGCFAA.Magnus.Manske@epost.de>; from Magnus.Manske@epost.de on Sat, Feb 09, 2002 at 11:32:12PM +0100

body:
Magnus Manske wrote:
> Called from the shell (as I didn't connect it with the apache yet), it
> renders the Main Page in 0:00.04 (without caching ;)

Is there any way to compare that in a "fair way" to the performance of
the php script?  One thing to keep in mind is that if/when apc is working
properly, the overhead of interpreting the php goes away.

--Jimbo


subject: [Wikitech-l] Stress testing setup

in_reply_to: <200202092024.VAA05113@atm3.uni-paderborn.de>; from axel@uni-paderborn.de on Sat, Feb 09, 2002 at 09:24:07PM +0100

body:
Oh, this sounds sweet.  :-)

I think that even the simple 'ab' which comes with apache has always
helped me in the past.  It's not as sophisticated as a more realistic
simulator like siege, but hitting various scripts on test sites or live
sites is a pretty decent way to get preliminary information -- and that
often turns out to be enough.

Axel Boldt wrote:

> I think we should get a decent stress testing setup going, so that we
> don't have to try out all improvements on the live site.
>
> I assume we are all running Unix/apache/php/mysql. Siege at
> http://joedog.org/siege/ looks like a good choice of a free stress
> testing utility. It can simulate n users hammering your site
> simultaneously, even if you aren't connected to any network, and
> reports response times and other stats.
>
> We need a realistically sized database dump to start playing though.
>
> We could then come up with a nice little Siege script that loads
> RecentChanges, searches and downloads a couple of articles, edits a
> couple others (maybe modeled on real stats from Jimbo), share the
> script and use it as benchmark to try out patches to the PHP script
> and database scheme.
>
> Axel
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at ross.bomis.com
> http://ross.bomis.com/mailman/listinfo/wikitech-l


subject: [Wikitech-l] slow searches log


subject: [Wikitech-l] Stress testing setup

body:
I think we should get a decent stress testing setup going, so that we
don't have to try out all improvements on the live site.

I assume we are all running Unix/apache/php/mysql. Siege at
http://joedog.org/siege/ looks like a good choice of a free stress
testing utility. It can simulate n users hammering your site
simultaneously, even if you aren't connected to any network, and
reports response times and other stats.

We need a realistically sized database dump to start playing though.

We could then come up with a nice little Siege script that loads
RecentChanges, searches and downloads a couple of articles, edits a
couple others (maybe modeled on real stats from Jimbo), share the
script and use it as benchmark to try out patches to the PHP script
and database scheme.

Axel


subject: [Wikitech-l] Proof of principle

body:
For proof of principle (and just for fun, of course!) I took a few hours to
write a simple single-pass parser for wikipedia pages in C++, using sql++
(the "official" MySQL API).

It supports external and internal links (with "does topic exist" check),
special line beginnings (:, *, #, and leading space), wiki-style bold and
italics, ---- things etc.
No == headings == (beheadings neither;), no namespaces, but these are simple
to implement.

Called from the shell (as I didn't connect it with the apache yet), it
renders the Main Page in 0:00.04 (without caching ;)

Should I continue to work on this, and eventually add it to the CVS, or is
it just a waste of time?
I will, of course, continue to work on the PHP script, no doubt about that!

Magnus


subject: [Wikitech-l] Reported login problems

body:
There are some problems with the login routine that I wasn't able to fix yet
(obviously, otherwise I wouldn't waste your time;)

Symptoms are as follows:
1. User "Some One" can/has to log in as "Some_One"
2. Sometimes, directly after login, the first page shows the IP instead of
the user name, even though "Some One" is logged in. It will work on further
pages.
3. Sometimes, the user name changes to "Some_One1"
4. There seem to be some problems with user_rights associated with the
above.

Personally, I have experienced only #2 on my local copy. I though this would
happen when the loading of the page is faster than the cookies management.

I will make this my priority for today, and if you're not too busy fixing
parser bugs;) please have a look at it as well.

Magnus


subject: [Wikitech-l] update of Recent Changes page

body:
Dear fellow programmers,

I have just submitted my new implementation of the Recent Changes and
History pages. For these pages the number of database accesses is now
drastically reduced. I have also updated the Wikipedia.sql file with the new
database scheme. Fortunately it turned out that I didn't have to add any
columns, but I did add two new indexes. The code to add these on the running
database is in updSchema.sql. I suggest that any future changes on the
database schema are also added in the form of SQL statements that can be
executed by Jimbo.

Finally, I got some errors on the pages of old versions that occurred
because the timestamp field of the page object wasn't set. (It is used in
the footer.) I could only remedy this by adding an extra line in WikPage.php
that initializes it, but I still don't understand fully why this didn't lead
to errors before.

Anyway, I hope you guys have some time to test it, because I couldn't do
this as well as I wanted. But this is my first big patch, so please be
gentle. :-)

Kind regards,

-- Jan Hidders

PS. My next task will the improvement of the search pages, as Axel already
suggest.


from_name: Larry Sanger

subject: [Wikipedia-l] Some thoughts

body:
On Mon, 11 Feb 2002, Magnus Manske wrote:

> I noticed some things on wikipedia that IMHO should be avoided:

I have some advice in turn: this list of (good!) rules should go on
[[rules to consider]] (which itself should now live at [[wikipedia:rules
to consider]] if it doesn't already).

> * Creating half a dozen redirects to a single topic. A recent example
> of this might be the "ArXiv.org e-print archive", for which
> "Xxx.lanl.gov", "Www.arXiv.org", "ArXiv.org", and "ArXiv" redirects
> were created. There's no need to do this if the redirected titles
> aren't very common and mentioned in the article text anyway. The
> search function will find them without the redirect, and noone will go
> through the "All Pages" list if there's a search function.

Sounds OK, but really, what harm does it do if someone does this?

> * Links to the talk page of an article appended to the article. Having
> "Talk" links in the article text is obsolete, as at least one link to the
> talk page will show anyway (or two, if you use the sidebar). When editing
> articles, if you see these links, please delete them.

I'd agree fully with this given that people are completely aware of the
Talk namespace and how to get to it.

> * Ebooks and other long texts. With the coming software update, the
> sidebar will contain a link to "Long Pages" (like an inverse stub
> list). Please have a look at this once it is available, and remove yet
> another copy of "The Origin Of Species" (that's not what wikipedia is
> for, right?), and try to break apart long "real" articles into pieces
> that are more easy to swallow;)

I now agree with this.  If you had asked about nine months ago, I wouldn't
be so sure.

Larry


subject: [Wikipedia-l] Recent Changes page!  Grr!

body:
It takes such a long time to load!  And I can't instruct my preferences
page to make 500 (or more!) changes the default, which is what I want.
Please, please, dear, dear programmers, make the updates to this page's
code correct and functional.  :-)  Thank you.  :-)

Larry


subject: [Wikitech-l] garbled URL

body:
I was trying today to sort out the [[Swedish monarchs]], when I
stumbled on this page:
    http://www.wikipedia.com/wiki/Bgustav/bus+Adolphus+of+Sweden

It looks like this URL is the result of a bug during the conversion.
Perhaps this is interesting evidence for Magnus?  (BTW, we have a few
old kings of Sweden named Magnus...)

There is a king of Sweden who's name is sometimes spelled Gustavus
Adolphus, but sometimes Gustav Adolf.  It seems this URL is the result
of someone trying to link to [[<b>Gustav</b>us Adolphus of Sweden]],
but this is just my guess.

--
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik
  Teknikringen 1e, SE-583 30 Link?ping, Sweden
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/


body:
Looking forward to it!  :-)

larry

On Mon, 11 Feb 2002, Magnus Manske wrote:

> Jan's fast Recent Changes is "in the mail" (meaning in the CVS repository),
> waiting to be checked out ("checkout" is a CVS command, meaning "use it").
>
> That was fast work of him, wasn't it? :]
>
>
> > -----Original Message-----
> > From: wikipedia-l-admin at nupedia.com
> > [mailto:wikipedia-l-admin at nupedia.com]On Behalf Of Larry Sanger
> > Sent: Monday, February 11, 2002 3:30 PM
> > To: wikipedia-l at nupedia.com
> > Subject: [Wikipedia-l] Recent Changes page! Grr!
> >
> >
> > It takes such a long time to load!  And I can't instruct my preferences
> > page to make 500 (or more!) changes the default, which is what I want.
> > Please, please, dear, dear programmers, make the updates to this page's
> > code correct and functional.  :-)  Thank you.  :-)
> >
> > Larry
> >
> > [Wikipedia-l]
> > To manage your subscription to this list, please go here:
> > http://www.nupedia.com/mailman/listinfo/wikipedia-l
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>


subject: [Wikipedia-l] Page titles to be deleted

body:
Sounds good to me.  In "voting" for deletion, of course it's important to
be able explain why one believes the page should be deleted.

Larry

On Mon, 11 Feb 2002, Magnus Manske wrote:

> I thought about having an easy way of expressing "this page is obsolete and
> should be deleted". Currently, we have "page titles to be deleted", but it
> takes time and effort to go there and edit.
>
> The obvious solution:
> * For logged-in users (troll prevention!), have a link in the sidebar "Mark
> this page for deletion" (a shorter title might fit better, but I can't think
> of any; maybe a shredder logo?;)
> * This adds the current page to "log:Pages to be deleted" (or
> "wikipedia:Pages to be deleted")
> ** Alternatively, we mark the article in the database, so the page is "PTBD"
> page is generated on-the-fly, ensuring it doesn't list pages that already
> *have* been deleted
> * Additionally, these pages are sorted by votes (descending, the "most
> hated" on top;)
> * Optionally, list the users that voted for deletion of that page
>
> Then, a sysop (=Larry) comes along, checks out the list and cleans up behind
> us thoughtless page-creators by permanently deleting the pages he deems
> obsolete.
>
> Before I implement any of that, any ideas, comments, flames? ;)
>
> Magnus
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>


subject: [Wikitech-l] This week

body:
During the week this week, I hope to get a few things setup.
Advice would be much appreciated, of course!

1.  beta.wikipedia.com (or similar name) will be our testbed site.
Every week, a cron will dump the live database from www.wikipedia.com
and load it into the testbed site.  So any changes made to the testbed
site's data will be lost every week.

2.  beta.wikipedia.com will have the latest version of the code once
per day, loaded directly from the CVS via cron.  This means that if
someone checks in broken code, beta.wikipedia.com will be broken until I
manually fix it.

3.  The main site will be updated with the most recent working code,
let's say once per week, maybe on Monday morning.  I think I should
always do this one by hand, because of the importance of not breaking
anything on the live site, or at least the importance of immediately
backing down to the previous version if something is broken.

4.  Of course I can also always do an upgrade of the live site in case
we find a major bug in the running code.

Last week, I upgraded the site 5 times I think -- i.e. once per day
when I had the time.  It seems important to me that we start to have a
development site and a live site, and some partially automated system for
moving forward.  :-)


subject: [Wikitech-l] Slow search queries

body:
From: "Axel Boldt" <axel at uni-paderborn.de>
>
> I think in your recent updSchema.sql, you want the second cur_timestamp
> to be old_timestamp.

I've corrected it. Thanks for noticing.

-- Jan Hidders


subject: [Wikitech-l] Latest version installed

body:
And I managed to only have the site broken for 2-3 minutes.  :-(

:-)


subject: [Wikipedia-l] Some thoughts

body:
I noticed some things on wikipedia that IMHO should be avoided:

* Creating half a dozen redirects to a single topic. A recent example of
this might be the "ArXiv.org e-print archive", for which "Xxx.lanl.gov",
"Www.arXiv.org", "ArXiv.org", and "ArXiv" redirects were created. There's no
need to do this if the redirected titles aren't very common and mentioned in
the article text anyway. The search function will find them without the
redirect, and noone will go through the "All Pages" list if there's a search
function.

* Links to the talk page of an article appended to the article. Having
"Talk" links in the article text is obsolete, as at least one link to the
talk page will show anyway (or two, if you use the sidebar). When editing
articles, if you see these links, please delete them.

* Ebooks and other long texts. With the coming software update, the sidebar
will contain a link to "Long Pages" (like an inverse stub list). Please have
a look at this once it is available, and remove yet another copy of "The
Origin Of Species" (that's not what wikipedia is for, right?), and try to
break apart long "real" articles into pieces that are more easy to swallow;)

Magnus


subject: [Wikipedia-l] two indexes on the same column?

body:
Magnus,

Was there a specific reason why you created two indexes for each of the id
columns in table cur and table old?

-- Jan Hidders


body:
Jan's fast Recent Changes is "in the mail" (meaning in the CVS repository),
waiting to be checked out ("checkout" is a CVS command, meaning "use it").

That was fast work of him, wasn't it? :]

> -----Original Message-----
> From: wikipedia-l-admin at nupedia.com
> [mailto:wikipedia-l-admin at nupedia.com]On Behalf Of Larry Sanger
> Sent: Monday, February 11, 2002 3:30 PM
> To: wikipedia-l at nupedia.com
> Subject: [Wikipedia-l] Recent Changes page! Grr!
>
>
> It takes such a long time to load!  And I can't instruct my preferences
> page to make 500 (or more!) changes the default, which is what I want.
> Please, please, dear, dear programmers, make the updates to this page's
> code correct and functional.  :-)  Thank you.  :-)
>
> Larry
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


body:
Commiting the visible number of Recent Changes to be set in User Preferences
right now...

Magnus

> -----Original Message-----
> From: wikipedia-l-admin at nupedia.com
> [mailto:wikipedia-l-admin at nupedia.com]On Behalf Of Larry Sanger
> Sent: Monday, February 11, 2002 3:30 PM
> To: wikipedia-l at nupedia.com
> Subject: [Wikipedia-l] Recent Changes page! Grr!
>
>
> It takes such a long time to load!  And I can't instruct my preferences
> page to make 500 (or more!) changes the default, which is what I want.
> Please, please, dear, dear programmers, make the updates to this page's
> code correct and functional.  :-)  Thank you.  :-)
>
> Larry
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


from_name: Brion Vibber

subject: [Wikitech-l] Most Wanted

body:
On lun, 2002-02-11 at 14:35, Magnus Manske wrote:
> I just tried to refresh the page when I got this :
>
> (The page was last refreshed just -161981 minutes ago; please wait another
> 161986 minutes and try again.)
>
> That's about 4 month...

I was subtracting 10000000 seconds from the actual timestamp to keep
log:WantedPages out of the RecentChanges list while still retaining a
usuable modification time for comparison with the present. (Previously
the timestamp was being forced to 0 to keep it out of RecentChanges.)
Apparently this got slightly messed up in the conversion...?

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Page titles to be deleted

body:
I thought about having an easy way of expressing "this page is obsolete and
should be deleted". Currently, we have "page titles to be deleted", but it
takes time and effort to go there and edit.

The obvious solution:
* For logged-in users (troll prevention!), have a link in the sidebar "Mark
this page for deletion" (a shorter title might fit better, but I can't think
of any; maybe a shredder logo?;)
* This adds the current page to "log:Pages to be deleted" (or
"wikipedia:Pages to be deleted")
** Alternatively, we mark the article in the database, so the page is "PTBD"
page is generated on-the-fly, ensuring it doesn't list pages that already
*have* been deleted
* Additionally, these pages are sorted by votes (descending, the "most
hated" on top;)
* Optionally, list the users that voted for deletion of that page

Then, a sysop (=Larry) comes along, checks out the list and cleans up behind
us thoughtless page-creators by permanently deleting the pages he deems
obsolete.

Before I implement any of that, any ideas, comments, flames? ;)

Magnus


subject: [Wikitech-l] update of database schema

body:
I have just updated the schema definition again to remove some superfluous
indexes and add some dearly needed ones. The new schema is in wikipedia.sql
and the update commands are in updSchema.sql, but before you run it you need
to uncomment the commands that still need to be run for your schema.

-- Jan Hidders


subject: [Wikitech-l] SQL dump for testing

body:
I almost forgot that I have an older, >21.000 articles SQL dump at
	http://wikipedia.sourceforge.net/fpw/newiki.sql.gz
Warning : 23 MB!

Happy testing,
Magnus


subject: [Wikipedia-l] Some thoughts

body:
Magnus wrote:
> * Creating half a dozen redirects to a single topic. A recent
> example of this might be the "ArXiv.org e-print archive", for which
> "Xxx.lanl.gov", "Www.arXiv.org", "ArXiv.org", and "ArXiv" redirects
> were created. There's no need to do this if the redirected titles
> aren't very common and mentioned in

Links to redirect pages are evil, because they are not found by the
"Pages that link here" function of the new software (or are they?).
But the user has no easy way of knowing whether he links to a redirect
page or a real page.  When the user saves a page, the software already
checks if each link goes to an existing or non-existing page,
resulting in an underlined or ?-link, respectively, and it could just
as well check if the link goes to a redirect page, and display such
links in a third way, perhaps underlined in green color.

I sometimes take my favorite year-in-review and open the "Pages that
link here" in another window and edit the page in the main window.
This function is really useful.

--
  Lars Aronsson
  <lars at aronsson.se>
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/


subject: [Wikitech-l] garbled URL

body:
On dim, 2002-02-10 at 22:02, Lars Aronsson wrote:
> I was trying today to sort out the [[Swedish monarchs]], when I
> stumbled on this page:
>     http://www.wikipedia.com/wiki/Bgustav/bus+Adolphus+of+Sweden
>
> It looks like this URL is the result of a bug during the conversion.
> Perhaps this is interesting evidence for Magnus?  (BTW, we have a few
> old kings of Sweden named Magnus...)
>
> There is a king of Sweden who's name is sometimes spelled Gustavus
> Adolphus, but sometimes Gustav Adolf.  It seems this URL is the result
> of someone trying to link to [[<b>Gustav</b>us Adolphus of Sweden]],
> but this is just my guess.

We have traced this to a bug in the search page, where it puts bold tags
inside the links before they're converted to HTML. If someone clicks one
of those links, they end up creating a bad page title.

I've checked a patch into CVS to fix it.

-- brion vibber (brion @ pobox.com)


from_name: Steve Callaway

subject: [Wikipedia-l] Some thoughts

body:
Also, this is a vexed issue with a number of mythologies, particularly
Celtic and Norse where many different spellings refer to the same topic e.g.
Odin, Wotan, Woden, Odd, Od, Odinn, etc, etc, etc... Without multiple
redirects we would probably end up with a topic for each of them: not good,
not good at all...

----- Original Message -----
From: "Michel Clasquin" <clasqm at mweb.co.za>
To: <wikipedia-l at nupedia.com>; "Magnus Manske" <Magnus.Manske at epost.de>;
"Wikipedia-L at Nupedia. Com" <wikipedia-l at nupedia.com>
Sent: Monday, February 11, 2002 7:12 PM
Subject: Re: [Wikipedia-l] Some thoughts

> On Monday 11 February 2002 14:24, Magnus Manske wrote:
> > I noticed some things on wikipedia that IMHO should be avoided:
> >
> > * Creating half a dozen redirects to a single topic. A recent example of
> > this might be the "ArXiv.org e-print archive", for which "Xxx.lanl.gov",
> > "Www.arXiv.org", "ArXiv.org", and "ArXiv" redirects were created.
> > There's no need to do this if the redirected titles aren't very common
> > and mentioned in the article text anyway. The search function will find
> > them without the redirect, and noone will go through the "All Pages"
> > list if there's a search function.
>
> I agree in principle, though there may be individual exceptions.  Do you
> know how many ways "Dostoyevsky" has been (mis)spelled in English over the
> last century or so? <g>
>
> Lately I've made redirects just to give 0-byte stubs something to do. A
> deletion-mechanism as proposed in another post today should clear this up
>
> --
> Michel Clasquin, D Litt et Phil (Unisa)
> clasqm at mweb.co.za/unisa.ac.za   http://www.geocities.com/clasqm
> This message was posted from a Microsoft-free PC
>
> ...hey, at least a wild goose chase gives you some exercise-Neal
Stephenson
>
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>


subject: [Wikipedia-l] Some thoughts

body:
Yes, but then you get Swedes contributing, Icelanders, Norwegians, Finns,
Estonians, etc, etc, all creating new articles. Much better to basket them
all together, and get the redirects working for you.

In English we certainly recognise: Odin, Od (appears in a number of
mediaeval folk tales), Wotan, Woden, and probably a few more.

----- Original Message -----
From: "Magnus Manske" <Magnus.Manske at epost.de>
To: <wikipedia-l at nupedia.com>
Sent: Monday, February 11, 2002 7:25 PM
Subject: RE: [Wikipedia-l] Some thoughts

> Yes, but only one or two are actually used in ENglish (Wotan and Odin, I
> guess). The others could be mentioned within the text of the actual
article,
> so that the search function will find them. Redirects are only good if
they
> are used in other articles.
>
> > -----Original Message-----
> > From: wikipedia-l-admin at nupedia.com
> > [mailto:wikipedia-l-admin at nupedia.com]On Behalf Of Steve Callaway
> > Sent: Monday, February 11, 2002 8:18 PM
> > To: wikipedia-l at nupedia.com
> > Subject: Re: [Wikipedia-l] Some thoughts
> >
> >
> > Also, this is a vexed issue with a number of mythologies, particularly
> > Celtic and Norse where many different spellings refer to the same
> > topic e.g.
> > Odin, Wotan, Woden, Odd, Od, Odinn, etc, etc, etc... Without multiple
> > redirects we would probably end up with a topic for each of them:
> > not good,
> > not good at all...
> >
> >
> > ----- Original Message -----
> > From: "Michel Clasquin" <clasqm at mweb.co.za>
> > To: <wikipedia-l at nupedia.com>; "Magnus Manske" <Magnus.Manske at epost.de>;
> > "Wikipedia-L at Nupedia. Com" <wikipedia-l at nupedia.com>
> > Sent: Monday, February 11, 2002 7:12 PM
> > Subject: Re: [Wikipedia-l] Some thoughts
> >
> >
> > > On Monday 11 February 2002 14:24, Magnus Manske wrote:
> > > > I noticed some things on wikipedia that IMHO should be avoided:
> > > >
> > > > * Creating half a dozen redirects to a single topic. A recent
> > example of
> > > > this might be the "ArXiv.org e-print archive", for which
> > "Xxx.lanl.gov",
> > > > "Www.arXiv.org", "ArXiv.org", and "ArXiv" redirects were created.
> > > > There's no need to do this if the redirected titles aren't very
common
> > > > and mentioned in the article text anyway. The search function
> > will find
> > > > them without the redirect, and noone will go through the "All Pages"
> > > > list if there's a search function.
> > >
> > > I agree in principle, though there may be individual exceptions.  Do
you
> > > know how many ways "Dostoyevsky" has been (mis)spelled in
> > English over the
> > > last century or so? <g>
> > >
> > > Lately I've made redirects just to give 0-byte stubs something to do.
A
> > > deletion-mechanism as proposed in another post today should
> > clear this up
> > >
> > > --
> > > Michel Clasquin, D Litt et Phil (Unisa)
> > > clasqm at mweb.co.za/unisa.ac.za   http://www.geocities.com/clasqm
> > > This message was posted from a Microsoft-free PC
> > >
> > > ...hey, at least a wild goose chase gives you some exercise-Neal
> > Stephenson
> > >
> > >
> > > [Wikipedia-l]
> > > To manage your subscription to this list, please go here:
> > > http://www.nupedia.com/mailman/listinfo/wikipedia-l
> > >
> >
> > [Wikipedia-l]
> > To manage your subscription to this list, please go here:
> > http://www.nupedia.com/mailman/listinfo/wikipedia-l
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>


subject: [Wikipedia-l] Some thoughts

body:
Yes, but only one or two are actually used in ENglish (Wotan and Odin, I
guess). The others could be mentioned within the text of the actual article,
so that the search function will find them. Redirects are only good if they
are used in other articles.

> -----Original Message-----
> From: wikipedia-l-admin at nupedia.com
> [mailto:wikipedia-l-admin at nupedia.com]On Behalf Of Steve Callaway
> Sent: Monday, February 11, 2002 8:18 PM
> To: wikipedia-l at nupedia.com
> Subject: Re: [Wikipedia-l] Some thoughts
>
>
> Also, this is a vexed issue with a number of mythologies, particularly
> Celtic and Norse where many different spellings refer to the same
> topic e.g.
> Odin, Wotan, Woden, Odd, Od, Odinn, etc, etc, etc... Without multiple
> redirects we would probably end up with a topic for each of them:
> not good,
> not good at all...
>
>
> ----- Original Message -----
> From: "Michel Clasquin" <clasqm at mweb.co.za>
> To: <wikipedia-l at nupedia.com>; "Magnus Manske" <Magnus.Manske at epost.de>;
> "Wikipedia-L at Nupedia. Com" <wikipedia-l at nupedia.com>
> Sent: Monday, February 11, 2002 7:12 PM
> Subject: Re: [Wikipedia-l] Some thoughts
>
>
> > On Monday 11 February 2002 14:24, Magnus Manske wrote:
> > > I noticed some things on wikipedia that IMHO should be avoided:
> > >
> > > * Creating half a dozen redirects to a single topic. A recent
> example of
> > > this might be the "ArXiv.org e-print archive", for which
> "Xxx.lanl.gov",
> > > "Www.arXiv.org", "ArXiv.org", and "ArXiv" redirects were created.
> > > There's no need to do this if the redirected titles aren't very common
> > > and mentioned in the article text anyway. The search function
> will find
> > > them without the redirect, and noone will go through the "All Pages"
> > > list if there's a search function.
> >
> > I agree in principle, though there may be individual exceptions.  Do you
> > know how many ways "Dostoyevsky" has been (mis)spelled in
> English over the
> > last century or so? <g>
> >
> > Lately I've made redirects just to give 0-byte stubs something to do. A
> > deletion-mechanism as proposed in another post today should
> clear this up
> >
> > --
> > Michel Clasquin, D Litt et Phil (Unisa)
> > clasqm at mweb.co.za/unisa.ac.za   http://www.geocities.com/clasqm
> > This message was posted from a Microsoft-free PC
> >
> > ...hey, at least a wild goose chase gives you some exercise-Neal
> Stephenson
> >
> >
> > [Wikipedia-l]
> > To manage your subscription to this list, please go here:
> > http://www.nupedia.com/mailman/listinfo/wikipedia-l
> >
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


subject: [Wikitech-l] update of database schema

body:
From: "Lars Aronsson" <lars at aronsson.se>
>
> How do you tell which indexes are superfluous?

Right now with my eyes. The indexes I removed were defined twice for the
same column. :-)

>  What tools or commands
> do you use?

The EXPLAIN command tells how a query is executed, what indexes are used, et
cetera.

-- Jan Hidders


from_name: Michel Clasquin

subject: [Wikipedia-l] Page titles to be deleted

body:
On Monday 11 February 2002 17:57, Magnus Manske wrote:
> I thought about having an easy way of expressing "this page is obsolete
> and should be deleted". Currently, we have "page titles to be deleted",
> but it takes time and effort to go there and edit.

On a somewhat related issue: the collection of "stubs" feature a *lot* of
0- and 1-byte pages. Perhaps one of the wikigods could go and put the
whole lot out of their misery?

--
Michel Clasquin, D Litt et Phil (Unisa)
clasqm at mweb.co.za/unisa.ac.za   http://www.geocities.com/clasqm
This message was posted from a Microsoft-free PC

...hey, at least a wild goose chase gives you some exercise-Neal Stephenson


subject: [Wikipedia-l] Some thoughts

body:
On Monday 11 February 2002 14:24, Magnus Manske wrote:
> I noticed some things on wikipedia that IMHO should be avoided:
>
> * Creating half a dozen redirects to a single topic. A recent example of
> this might be the "ArXiv.org e-print archive", for which "Xxx.lanl.gov",
> "Www.arXiv.org", "ArXiv.org", and "ArXiv" redirects were created.
> There's no need to do this if the redirected titles aren't very common
> and mentioned in the article text anyway. The search function will find
> them without the redirect, and noone will go through the "All Pages"
> list if there's a search function.

I agree in principle, though there may be individual exceptions.  Do you
know how many ways "Dostoyevsky" has been (mis)spelled in English over the
last century or so? <g>

Lately I've made redirects just to give 0-byte stubs something to do. A
deletion-mechanism as proposed in another post today should clear this up

--
Michel Clasquin, D Litt et Phil (Unisa)
clasqm at mweb.co.za/unisa.ac.za   http://www.geocities.com/clasqm
This message was posted from a Microsoft-free PC

...hey, at least a wild goose chase gives you some exercise-Neal Stephenson


subject: [Wikitech-l] Latest version installed

body:
From: "Jimmy Wales" <jwales at bomis.com>

> And I managed to only have the site broken for 2-3 minutes.  :-(
>
> :-)

Wow, look at the Recent Changes page go.  :-)) But I 've seen the first bug
already. :-( It shows you max. 50 pages per day if your max is 50. I'm on it
right away.

-- Jan Hidders


subject: [Wikipedia-l] Some thoughts

body:
On Monday 11 February 2002 21:25, Magnus Manske wrote:
> Yes, but only one or two are actually used in ENglish (Wotan and Odin, I
> guess). The others could be mentioned within the text of the actual
> article, so that the search function will find them. Redirects are only
> good if they are used in other articles.

But that's the point: I don't know when somebody is going to start writing
an article on early Burgundian mythology, but I can make sure that if he
does, the particular name the Burgundians used will link to a central page
called [[Odin]]. Or if someone starts writing about Dostoyevski in an
article on [[Russian literature]], a little proactive redirecting avoids
the situation where you have parallel [[Dostoyevsky]] and [[Dostoyevski]]
pages that someone now needs to harmonise.

I do agree that it can be overdone.

--
Michel Clasquin, D Litt et Phil (Unisa)
clasqm at mweb.co.za/unisa.ac.za   http://www.geocities.com/clasqm
This message was posted from a Microsoft-free PC

...hey, at least a wild goose chase gives you some exercise-Neal Stephenson


subject: [Wikitech-l] Latest version installed

body:
From: "Magnus Manske" <Magnus.Manske at epost.de>

> I fixed it already. Look at the user preferences.

No, that's not it. It happens when your preference is "ignore minor edits".
There you might not get all the changes during a day if your maxCnt is not
very high. I know already what the problem is (I should not select the first
maxCnt there because I am sorting by title_name, not by timestamp.) I hadn't
noticed this because my testing database wasn't that big. I know I can solve
this, but it takes some thinking.

-- Jan Hidders


subject: [Wikitech-l] HTML munging code rewritten

body:
I've rewritten wikiPage::removeHTMLtags again. (Checked into CVS, diff:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/wikipedia/phpwiki/fpw/wikiPage.php.diff?r1=1.60&r2=1.61)
Exciting new features:

* Removes unwanted tag attributes, such as the scripting attributes
(onmouseclick, onmouseout, etc) which can be used to create fake links
or automatically redirect the browser to another web site (see the
previous version of the [[Goatse.cx]] article for an example)

* Makes a more serious attempt to fix mismatched open/close tag pairs.
Related, makes some attempts at normalization of tables. ie, <tr> not
allowed outside of <table> etc.

* Nested tables now work.

The function feels more weighty than it ought to be, but it works on
everything I've tried throwing at it so far, which is an improvement
over the previous versions.

I also threw in fixes for:
* Character entities in <pre> sections
* ISBN numbers with letters in them
* == Section headers == at the edges of HTML tags

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] Most Wanted

body:
I just tried to refresh the page when I got this :

(The page was last refreshed just -161981 minutes ago; please wait another
161986 minutes and try again.)

That's about 4 month...


subject: [Wikitech-l] Latest version installed

body:
From: "Jan Hidders" <hidders at uia.ua.ac.be>
>
> No, that's not it. It happens when your preference is "ignore minor
edits".
> There you might not get all the changes during a day if your maxCnt is not
> very high. I know already what the problem is (I should not select the
first
> maxCnt there because I am sorting by title_name, not by timestamp.) I
hadn't
> noticed this because my testing database wasn't that big. I know I can
solve
> this, but it takes some thinking.

Indeed it did, but the solution is in cvs now. You only need to replace the
file special_recentchanges.php.

Apologies for the inconvenience. :-/

-- Jan Hidders


body:
On mar, 2002-02-12 at 01:57, Jan Hidders wrote:
> From: "Brion Vibber" <brion at pobox.com>
> >
> > * Nested tables now work.
> >
> > * == Section headers == at the edges of HTML tags
>
> Do we want this to work? I'd prefer it if we took a conservative stance
> towards the mark-up: we don't allow it unless it is needed. This is becuase
> once you allow something it will be used, and then it will be hard to
> unallow. This might one day become important when we try to optimize the
> parser. So I feel we should discuss extensions of mark-up publicly before
> implementing them.

The section headers bit was a bugfix to replicate the previous behavior
of of usemodwiki. Not strictly necessary though, I suppose. I'll take it
back out.

Tables are certainly in very active use as it is, and I see no reason to
break nested tables, which at least someone seems sufficiently
interested in to write a bug report about them not working. Nonetheless,
making them work was simply a side effect of my changes to remove the
dangerous scripting attributes, which previous too-simple versions let
pass through.

Now, we *know* we don't want scripting. What *do* we want? Good
question. Here's what was allowed under usemodwiki:

  Font effects: b i u font big small sub sup cite code em s strike
strong tt var
  Paragraph formatting: br p hr pre center blockquote div
  Headings: h1 h2 h3 h4 h5 h6
  Lists: ol ul dl li dt dd
  Tables: table caption td th tr

all with any attribute you cared to stuff in, including evil JavaScript
tricks. The first version of the PHP script that went online allowed
*everything* except a, script, title, html, body, and header (including
malicious scripting attributes). The next version replicated the
usemodwiki behavior exactly, broken tables and scripting attributes and
all.

Too much? Not enough? For the time being I've trimmed the allowed tags
back to the usemodwiki list (I'd slipped in some additional table tags
and some semantic markup tags that could theoretically be used to help
eg voice-based browsers for the blind render things more clearly), but
I'm sure as heck keeping those scripts out, and I can't imagine why we'd
want to break perfectly well-formed tables.

> As always we should strive for correctness and simplicity. The two go hand
> in hand.
>
> Sorry if I sound too critical, but I have strong feelings about this.

Agreed, which is why I'm not entirely happy with my current
implementation of the function, which is too complicated in places. But
the previous one, while relatively simple, was definitely not correct.

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] Cache problems?

body:
I'm not sure if the live site uses caching already (or an intermediate
proxy), but I have repeatedly noticed that the served version of a
page does not always completely agree with the current wiki version.

Right now, it is happening at the main page: all previous versions and
diffs show "Winter Olymplics" under Current Events, but the served
version of the page omits it. I'm pretty sure that nobody deleted that
text.

Axel


subject: [Wikitech-l] [neil.harris@tonal.clara.co.uk: Walone2.ico - a re-send of the missing favicon.ico file]

body:
----- Forwarded message from Neil Harris <neil.harris at tonal.clara.co.uk> -----

From: Neil Harris <neil.harris at tonal.clara.co.uk>
Date: Tue, 12 Feb 2002 09:38:03 +0000
To: jwales at bomis.com
Subject: Walone2.ico - a re-send of the missing favicon.ico file

Dear Jimbo,

This is the favicon file which got lost during the software upgrade.

It should be the most recent 16x16 version, and should be installed at
http://www.wikipedia.com/favicon.ico

In an ideal standards-compliant world, generated pages would have
  <link rel="shortcut icon" href="http://www.wikipedia.com/favicon.ico">
added to their HEAD sections.

* M$ browsers are hard-wired to find the favicon at the location given
_unless_ the 'link rel' stuff is in the page, in which case they will
use that

* pure W3C standards-compliant browsers won't find the icon unless the
link rel stuff is in the page

* Mozilla changes its policy from release to release...

I hope this is useful.

-- Neil

----- End forwarded message -----


body:
The notion of "section headers" sounds like one that should be discussed
on wikipedia-l before considering implementing it in software, I think.

The programmers, as much as we love 'em, should not be solely in charge of
specifying the system requirements...

Larry

On Tue, 12 Feb 2002, Lars Aronsson wrote:

> > The section headers bit was a bugfix to replicate the previous behavior
> > of of usemodwiki. Not strictly necessary though, I suppose. I'll take it
> > back out.
>
> Just an idea: Section headers can be quite useful.  During the first
> pass through the text (sub WikiToHTML in UseModWiki) you would store
> the resulting text in a string variable and all found section headers
> in a separate array.  In the output HTML you would first present a
> table of contents, i.e. a list of <a href="#header" > linked section
> headers pointing down to the right section header.  This would allow
> really long articles as a substitute for subpages, e.g. the subpages
> Denmark/History Denmark/Government Denmark/Geography would instead be
> subheaders in the same long page.  You would want to support
> [[Denmark#Geography]] type of links from other pages.
>
> Look at the user interface of encarta.msn.com.
>
>
>


body:
From: "Brion Vibber" <brion at pobox.com>
>
> * Nested tables now work.
>
> * == Section headers == at the edges of HTML tags

Do we want this to work? I'd prefer it if we took a conservative stance
towards the mark-up: we don't allow it unless it is needed. This is becuase
once you allow something it will be used, and then it will be hard to
unallow. This might one day become important when we try to optimize the
parser. So I feel we should discuss extensions of mark-up publicly before
implementing them.

As always we should strive for correctness and simplicity. The two go hand
in hand.

Sorry if I sound too critical, but I have strong feelings about this.

-- Jan Hidders


subject:
[Wikitech-l] [neil.harris@tonal.clara.co.uk: Walone2.ico - a
	re-send of the missing favicon.ico file]

body:
On mar, 2002-02-12 at 08:07, Jimmy Wales wrote:
> ----- Forwarded message from Neil Harris <neil.harris at tonal.clara.co.uk> -----
> In an ideal standards-compliant world, generated pages would have
>   <link rel="shortcut icon" href="http://www.wikipedia.com/favicon.ico">
> added to their HEAD sections.

Checked in. Perhaps we should use a PNG version to be nicer to non-MS
browsers, though?

-- brion vibber (brion @ pobox.com)


body:
From: "Brion Vibber" <brion at pobox.com>
> On mar, 2002-02-12 at 01:57, Jan Hidders wrote:
>
> The section headers bit was a bugfix to replicate the previous behavior
> of of usemodwiki. Not strictly necessary though, I suppose. I'll take it
> back out.

Thank you.

> Tables are certainly in very active use as it is, and I see no reason to
> break nested tables, which at least someone seems sufficiently
> interested in to write a bug report about them not working.

Ah, sorry, I didn't know they had worked before. In that case they should
now also work.

> Now, we *know* we don't want scripting. What *do* we want?

In some sense that is not really up to us, but should be decided by
Wikipedia management and the rest of the gang in Wikipedia-l. However, what
is clear IMO is that the tags and attributes that worked under usemod and
have been used in useful ways should now also work. I would suggest that
when we are in doubt this then we disallow it and wait until people start to
complain, and then we ask around for opinions.

If we want to change or restrict the markup more drastically then this
probably needs to be discussed first publicly. (I have a rather extreme
opinion about this, but that is not relevant here.) By the way I really like
the fact that you have a list of allowed tags/attributes and don't allow
anything else. Maybe we should even have separate lists of allowed
attributes per tag, but that maybe overkill.

> > Sorry if I sound too critical, but I have strong feelings about this.
>
> Agreed, which is why I'm not entirely happy with my current
> implementation of the function, which is too complicated in places. But
> the previous one, while relatively simple, was definitely not correct.

Agreed, and I do believe that what you are doing at the moment will turn out
to be very important in the long run. For example, when we are going to
optimize the parser, export to XML or adapt the mark-up, then it will be
very important, if not crucial, that the contents of Wikipedia satisfy a
certain strict syntax. So the more the script safeguards this syntax, the
better it is.

-- Jan Hidders


subject: [Wikipedia-l] Subsections

body:
Larry Sanger wrote:
> I'd like to see one example of an article, or a class of articles, that
> would be clearly improved by being put in article-with-subsections form,
> rather than simply broken into a series of shorter articles.

It might not be that the _articles_ are improved, but the _search
engine_ and _navigation in general_.  Maybe.  :-)

The example I have in mind: Iwo Jima.  It's a place.  Most people who search
for Iwo Jima are not looking for general information about the place, though.
Mostly people are interested in Iwo Jima because of the important WWII battle
fought there.

A search for Iwo Jima could look like either of these:

WITHOUT SUBSECTIONS
[[Iwo Jima]]
[[Iwo Jima In World War II]]
[[Major Battles of the Pacific Theater in WWII]]

WITH SUBSECTIONS
[[Iwo Jima]]
[[World War II]] -- subsection on "Iwo Jima as a turning point"
[[Major Battles of the Pacific Theater in WWII]] -- subsection on "Iwo Jima"

----

The second and third examples are different.  In one case, I am imaginging that
the article would actually be written differently.  Instead of having a short
[[World War II]] article and lots of independent articles, we have a longer
article with subsections.  There are pros and cons to this.

But in the third case, I'm imagining that the article is written the
exact same way in both cases -- but we now have a means to call
special attention to the fact that the article does contain a
subsection on Iwo Jima, rather than merely _mentioning_ Iwo Jima.
This seems a net improvement.

----

One of the mistakes of Nupedia was that we tried to design the perfect system
a priori, including grandiose visions of XML-marked-up text to permit all kinds
of fancy searching.  :-(

At Wikipedia, we take things simpler.  But if something is harmless (and ONLY
if it is harmless), we might add it.

--Jimbo


subject: [Wikipedia-l] Subsections

body:
I'd like to see one example of an article, or a class of articles, that
would be clearly improved by being put in article-with-subsections form,
rather than simply broken into a series of shorter articles.

Larry

On Tue, 12 Feb 2002, Jan Hidders wrote:

> From: "Larry Sanger" <lsanger at nupedia.com>
> >
> > The notion of "section headers" sounds like one that should be discussed
> > on wikipedia-l before considering implementing it in software, I think.
>
> It certainly is. It's a feature that is also seen at some other Wiki's,
> e.g., MoinMoin, and usually in the form of of a macro such as
> {{{table_of_contents}}} such that it adapts itself automatically when new
> headers are inserted. I agree with Lars that it could help in promoting
> bigger articles with subsections that replace subpages.
>
> -- Jan Hidders
>
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>


subject: [Wikipedia-l] Simple XML ideas

body:
It would be very cute and maybe harmless to be able to mark up some articles
as being about people or events or whatever.  I'm not sure how this would best
be implemented, and maybe it shouldn't be implemented, but hear me out.  (I think
maybe namespaces aren't right for this idea, but then again, maybe so.)

Look at this text -- I'm not suggesting this as actual markup we should adopt, but
this is just something to get ideas flowing:

<person>George Washington</person> was the first <concept>President</concept> of
the <place>United States of America</place> after the adoption of the <concept>United
States Constitution</concept>.

The magic we could do if lots and lots of articles were marked up with this kind
of metadata would be really neat.

If we used namespaces, this would be:

[[George Washington]]

[[person:George Washington]]

But I think we should think really hard about the dangers of
proliferating namespaces too quickly.  One of the things we have to
think really hard about is making sure that any transition to more
comprensive semantic markup doesn't frighten and confuse people.

--Jimbo


subject: [Wikipedia-l] Hello

body:
On mar, 2002-02-12 at 12:26, 421621 at ingta.unizar.es wrote:
> Suggestion #1:
>
> Upload a complete substitution gfx icons for greek symbols. And builtin a easy
> to use feature...
>
> <Grek>OMEGA</grek>  <Grek>A</grek>
>
> to
>
>
>
> May this help oneline math expresions writing?

Articles that use Greek letters in math expressions currently use the
standard HTML character entities: α β ... ω. These
should be displayed properly as Greek letters in all current,
standards-compliant browsers. There's only a problem for:

  * Text-mode browsers which have no Greek/math font available
  * Older browsers, such as Netscape 4, which don't recognize these
    entities and thus show the descriptive names α β etc.

Images won't help for text-mode browsers, obviously, so this kind of
conversion would only be an improvement for Netscape 4 and other
old/marginal browsers. Unfortunately there are still a lot of Netscape 4
users out there, especially on Unix.

If we were to have such a feature, I would recommend using the existing
character entities, not some new tag, and making the replacement
optional. Perhaps the default might be to use the images if a particular
browser/version is reported, and otherwise to leave things alone.

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Simple XML ideas

body:
On Tue, 12 Feb 2002, Magnus Manske wrote:

> > <person>George Washington</person> was the first
> > <concept>President</concept> of
> > the <place>United States of America</place> after the adoption of
> > the <concept>United
> > States Constitution</concept>.
>
> That might work, as long as it stays optional.

How *could* it stay optional?  If Magnus or some XML guru marks up an
article about XYZ, and I haven't a clue about markup let alone XML let
alone our DTD, I'm going to really be put off by the markup.

Unless we think of something really clever, I'm dead-set against this for
the working version of a Wikipedia.

Larry


subject: [Wikipedia-l] Simple XML ideas

body:
On Wed, 13 Feb 2002, Jan Hidders wrote:

> Why not [[George Washington (person)]]. I thought that was the whole
> point of having namespaces.

No, the SOLE point of having namespaces was to find a neat solution to
separating articles about Wikipedia, about Wikipedia contributors, and
other non-Wikipedia-articles, from the Wikipedia articles.  Nothing more
fancy than that.

> Oh dear. Just talking about "comprehensive semantic markup" already
> frightens and confuses me. :-) Sounds too much like the semantic web
> for me. That will never work.

I totally agree here.  Remember, Wikipedia is supposed to be simple and
easy to use.  Not just in theory, either, but *actually* simple and easy
to use.  :-)  This means that we cannot expect users to learn any more
tricks than they already have to learn.  This is a problem we have to work
with--it's a constraint.

Larry


body:
On mar, 2002-02-12 at 15:49, Jan Hidders wrote:
> Brian,
>
> I just uploaded from CVS and now the <B> and <I> tags don't seem to work
> anymore. Frankly, I'm quite happy with that situation, but I suspect some
> other people won't be. :)

Hmm, news to me, they work on my test server... Let me grab a fresh copy
of everything and try again...

Yeah, still works for me. Could you send an example of wikitext that
triggers the bug?

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Subsections

body:
On Wed, 13 Feb 2002, Lars Aronsson wrote:

> Larry wrote:
> > I'd like to see one example of an article, or a class of articles, that
> > would be clearly improved by being put in article-with-subsections form,
> > rather than simply broken into a series of shorter articles.
>
> I understand that you want an example, and I don't intend to make one.

I understand that you think subsections are a nifty idea, and I don't
intend to support the idea.  :-)  Without an example to work with,
discussion seems pretty pointless.

> That was why I just mentioned potential power of section headings as
> loose idea on the tech list.  Many encyclopedias have really long
> articles that are subdivided in this way.  Making separate articles
> (without using subpages) requires that they can stand alone with just
> a brief introduction at the top.  This is fine with [[Swedish
> monarchs]] or [[History of Poland]], which don't need to be part of
> [[Sweden]] or [[Poland]].  But "The Middle Ages" is a section heading
> in [[History of Poland]].  If broken out into a separate article, what
> title should that page have?  Maybe [[Medieval history of Poland]]?

And yet you give an example anyway.  :-)

Yes, something like [[medieval history of Poland]] or [[Poland in the
Middle Ages]] or even [[medieval Poland]] (by golly!).

There are many features that are "powerful," and yet it would be an
extremely bad idea for us to have them.  Why?  Because they complicate the
EDITING system.  I'm generally opposed to further complications to the
system that would require users to learn much more about how to use the
system.  If there's one thing we've learned from Nupedia (and it was sure
an expensive mistake) it's that not many people aren't going to use a
system if it's incredibly complicated.  Meanwhile, Wikipedia was very easy
to use from the beginning and very quickly became more active than
Nupedia.

Again, simplicity is a constraint we have to work with.  At some point, it
has to care weight with us in designing the system any further.  For me,
the system is probably *more* complicated than it needs to be.

There's only one really significant change that I would stand behind, that
I can think of offhand, which would constitute an addition to the system:
*some* sort of categorization system, as we were discussing (probably a
multiple-select list of categories next to the "save" button),

This isn't to say that we can't have some very powerful, complicated stuff
going on at the metainformation and text processing levels, of course.

It also isn't to say that we can't have some "master version" living
somewhere that is beautifully marked up.

Larry


in_reply_to:
<1013510828.19756.0.camel@rdaneel.moisty.org> (message from Brion
	Vibber on 12 Feb 2002 02:47:07 -0800)

body:
> The section headers bit was a bugfix to replicate the previous behavior
> of of usemodwiki. Not strictly necessary though, I suppose. I'll take it
> back out.

Just an idea: Section headers can be quite useful.  During the first
pass through the text (sub WikiToHTML in UseModWiki) you would store
the resulting text in a string variable and all found section headers
in a separate array.  In the output HTML you would first present a
table of contents, i.e. a list of <a href="#header" > linked section
headers pointing down to the right section header.  This would allow
really long articles as a substitute for subpages, e.g. the subpages
Denmark/History Denmark/Government Denmark/Geography would instead be
subheaders in the same long page.  You would want to support
[[Denmark#Geography]] type of links from other pages.

Look at the user interface of encarta.msn.com.

--
  Lars Aronsson
  <lars at aronsson.se>
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/


subject: [Wikipedia-l] Subsections

body:
On Tue, 12 Feb 2002, Jimmy Wales wrote:

> Larry Sanger wrote:
> > I'd like to see one example of an article, or a class of articles, that
> > would be clearly improved by being put in article-with-subsections form,
> > rather than simply broken into a series of shorter articles.
>
> It might not be that the _articles_ are improved, but the _search
> engine_ and _navigation in general_.  Maybe.  :-)

One thing that makes navigation easy right now is that the organization of
articles is simple, after all.

> The example I have in mind: Iwo Jima.  It's a place.  Most people who
> search for Iwo Jima are not looking for general information about the
> place, though. Mostly people are interested in Iwo Jima because of the
> important WWII battle fought there.
>
> A search for Iwo Jima could look like either of these:
>
> WITHOUT SUBSECTIONS
> [[Iwo Jima]]
> [[Iwo Jima In World War II]]
> [[Major Battles of the Pacific Theater in WWII]]
>
> WITH SUBSECTIONS
> [[Iwo Jima]]
> [[World War II]] -- subsection on "Iwo Jima as a turning point"
> [[Major Battles of the Pacific Theater in WWII]] -- subsection on "Iwo Jima"

I see that advantage, yes.

> The second and third examples are different.  In one case, I am
> imaginging that the article would actually be written differently.
> Instead of having a short [[World War II]] article and lots of
> independent articles, we have a longer article with subsections.
> There are pros and cons to this.

There sure are a lot of cons.  This is pretty much a different approach to
the old subpages idea, and the same objections apply (e.g., why not have
subsubsections?--that's only one of them).

> But in the third case, I'm imagining that the article is written the
> exact same way in both cases -- but we now have a means to call
> special attention to the fact that the article does contain a
> subsection on Iwo Jima, rather than merely _mentioning_ Iwo Jima.
> This seems a net improvement.

Actually, I think the way we've been proceeding in many (not all) cases
has been the correct way: the general articles have general information
(not just links to more specialized articles), omitting many details.  The
general articles link to more specialized articles.

I've got an article on metaphysics, for example, that links several other
many more specialized topics in metaphysics.  But if someone wants to know
what metaphysics is, and what sorts of concepts and problems are
"metaphysical," hopefully he could go to the metaphysics article and find
out.  What would be really a bad thing is if he had to go to a series of
more specialized articles to learn about metaphysics--which would be the
case if "metaphysics" were nothing more than a bunch of links to
specialized topics within metaphysics.

Generally, with subsections, the tendency, I imagine, would be to write
more very long articles, rather than break down such long articles into
series of shorter articles on specific subjects, and make the
formerly-long article into a moderate-sized article that discusses the
topic *at a length-appropriate level of generality* and serves as a
pointer to more specialized articles.

It is really, really important that we think in detail about how
contemplated features like this would actually be used over the long haul,
and whether in a long-term context they make any sense.  Subsections, like
subpages, make very little sense to me, and for similar reasons.

> One of the mistakes of Nupedia was that we tried to design the perfect
> system a priori, including grandiose visions of XML-marked-up text to
> permit all kinds of fancy searching.  :-(
>
> At Wikipedia, we take things simpler.  But if something is harmless
> (and ONLY if it is harmless), we might add it.

Hear, hear.

Larry


subject: [Wikipedia-l] Subsections

body:
I just formulated an interesting hypothesis, which might explain why some
people are attracted to ideas like subpages and subsections, despite the
many clear disadvantages of them.  Sorry, this is going to be a bit of a
ramble.

There is an inherent discomfort we all experience when we see that
information is not properly contextualized.  We don't like to start in the
middle of things.  General expository works, such as technical books, very
often start with very general chapters that present level at a level of
generality and simplicity that implies that the rest of the book is going
to be a lot simpler than it is; it turns out that, for anyone who can
understand the rest of the book, the introduction was old hat and pretty
much unnecessary.

In the context of Wikipedia, we'd hate (in varying degrees) to come across
an article on the Battle of Iwo Jima that goes into detail about troop
movements, generals, casualties, and so forth, and yet doesn't put the
thing into the context of the Pacific Theater, which has to be put into a
larger context to be properly understood, and so forth.  But the
contextualizing has to stop somewhere.  At some point, we have to let the
other articles do the work.

Not quite realizing this, some people come up with this dandy idea of
hardwiring the connection between certain subtopics and certain parent
topics.  This way, nobody can mistake that Mr. Burns is a character in The
Simpsons, that Frodo Baggins lives in Middle Earth, and so forth--totally
essential, of course, to understanding who Mr. Burns and Frodo are
supposed to be.  But there are other essential relationships between
topics that are equally deserving of being hardwired.

This tendency to want to supply context is *totally* well-meaning and
well-intentioned.  The problem is that it doesn't neatly solve the problem
it is mainly intended to solve, because it reflects a poor understanding
of the problem.

The problem subpaging and subsectioning proposals are trying to solve is
simply that everything requires context in order to be properly
understood.  That IS a problem; but subpages and subsections just will not
solve that problem by themselves; they have a host of problems themselves,
besides.

In hypertext encyclopedia, the contextualization problem is *naturally*
and *elegantly* solved with two tools: hyperlinks, and equally
importantly, text that is written at a proper level of generality, that
*provides* the really *essential* background for a specific topic on the
spot.  One simply has to distinguish the essential from the nonessential.

An article titled "World War II" simply cannot and should not aspire to be
any more than the most superficial introduction to a conflict that
requires many volumes just for bare exposition and slenderest theorizing.
It should act as a contextualizer of the next level down of subtopics,
which might repeat some of the information in "World War II," but which
give more detail.  And so on, and so on.

Another example is generally given by a number of different articles I've
adapted from my introductory philosophy lectures.  I *could* have pumped
for subsections in order to create, say, eight parts to one long article
about ethics.  Instead, I used the introductory material, from the front
of that section, to try to characterize ethics in general; I then briefly
introduced several branches of ethics, such as theory of value and theory
of conduct, and created articles for each of the branches.  Then, I have
not yet but I will further prise out of the articles on the branches
(which are themselves very long) more articles about particular ethical
theories and concepts, like eudaimonism and eudaimonia.

This requires that we repeat what we say in articles quite a bit.  In some
of my articles, I have actually cut and pasted bits of text from one
article to another.  Actually, I think this is a *good* thing.  The
purpose of encyclopedia articles is to convey human knowledge *on
particular subjects* in a way that can be absorbed as easily as the
subject allows.  So, if I write about ethics and mention what the theory
of value is, and then repeat the same thing (in more detail) in the theory
of value article, I have done a good job in fulfilling the purpose of
encyclopedia articles.  If someone wants to know about what ethics (as a
Western philosophical discipline)  is, it is pretty important that he or
she understand at least *what* the theory of value is.  One shouldn't have
to go to a separate article to find out what the theory of value is, in an
article on ethics, because part of what it is to understand what ethics is
*just is* to understand what the theory of value is.  But an understanding
of ethics doesn't require an understanding of all the topics necessary to
give a basic introduction to the theory of value.  To pick a very
specialized topic, you might wonder where to go to find out about Mackie's
moral irrealism; that's the sort of detail we might find in an article on
irrealist meta-ethics, or an article on Mackie's moral irrealism.  Not in
an article on ethics, for good reason.

The next part is important: the above implies that there is a distinction
between the essential and the nonessential with regard to any topic, and
that we focus on the essential when we're writing on the topic, saving the
nonessential for more specialized or for tangentially related articles.
And *this* is difficult, sometimes.  It requires a kind of thinking that
mere amassers-of-fact are sometimes not familiar with.  I think that just
goes to show you that encyclopedias need more than amassers-of-fact.  They
also need people who really understand the facts and can organize them in
articles appropriate to their level of generality--rather than just
shoving them willy-nilly into one catch-all article patched together like
a Frankenstein monster, with no rhyme or reason.  That's sort of what I
think of when I think of subsections and subpages.  It implies a certain
degree of sloppy, disorganized thinking.

But how can we, in practice, distinguish the essential from the
nonessential?  Like this: we realize that topics in Wikipedia are
individuated by their names.  One name (or cluster of near synonyms), one
topic.  Then we ask ourselves: "*Given that* we will also have articles
introducing related topics X, Y, and Z, that our readers will be able to
consult, and so on down to the most detailed of topics--so that we don't
*need* to repeat here all the details of X, Y, and Z--what is really left
that's necessary to say in order to understand the meaning or significance
of the person, concept, event, etc., right now at hand, and provide the
context necessary to understand the articles on the 'subtopics'?"

In writing that article about ethics, for example, I know that we're going
to have articles on the theory of value, meta-ethics, applied ethics, and
so forth, and it certainly isn't necessary that I repeat the details that
I know will be in those articles (or that I repeat the details that will
be in even more specialized articles linked to from *those* articles).
So I'm off the hook as far as giving a complete, erudite exposition of
ethics is concerned.  What, then, do I need to say about ethics in order
to convey a basic understanding of ethics, *and* provide the basic context
necessary to understand the articles on the next level of generality down?

An article on theory of value shouldn't have to repeat, at least in much
detail, what ethics is supposed to be (what sort of definitions have been
offered, say).  So the article on ethics should at least give a
definition.  Moreover, the theory of value article can probably "rely" on
the ethics article to explain some of the basic interrelations between the
different branches of ethics.

Larry


from_name: 421621 at ingta.unizar.es

subject: [Wikipedia-l] Hello

body:
Hello I am Tei,
  and i have join Wikipedia project recently.

I am a active web and desktop developper for 3D Engines, GFX, Perl things, etc..
I can make amazing suggestions that can turn people crazy as never have you
see.. that mi expecial ability :D

Suggestion #1:

Upload a complete substitution gfx icons for greek symbols. And builtin a easy
to use feature...

<Grek>OMEGA</grek>  <Grek>A</grek>

to

May this help oneline math expresions writing?

1 saludo
Tei

==POD RULEZ!!

---------------------------------------------
This message was sent using Endymion MailMan.
http://www.endymion.com/products/mailman/


subject: [Wikipedia-l] Re: [Wikitech-l] HTML munging code rewritten

body:
From: "Larry Sanger" <lsanger at nupedia.com>
>
> The notion of "section headers" sounds like one that should be discussed
> on wikipedia-l before considering implementing it in software, I think.

It certainly is. It's a feature that is also seen at some other Wiki's,
e.g., MoinMoin, and usually in the form of of a macro such as
{{{table_of_contents}}} such that it adapts itself automatically when new
headers are inserted. I agree with Lars that it could help in promoting
bigger articles with subsections that replace subpages.

-- Jan Hidders


from_name: Vicki Rosenzweig

subject: [Wikipedia-l] Suggestion #2

body:
At 12:50 AM 2/13/02 +0000, Tei wrote:
>Hello,
>
>  Suggestion #2:
>
>  WikiWord:
>   page with buttons labeled "BLOCKQUOTE" "LIST" "CARRIER RETURN"...
>
>  you press "LIST"
>  you get *
>
>  you press "LINK"
>  you get [[insert here you link]]
>
>  stupid?
>  not because you NOT need to remind all UserMod trick, you only need
> press the
>button laveled what you need.
>
>note:
>at least this will help me, because I dont remember the minimal sintax needed
>por wikipedia :P

This complicates things at the coding end, though.

It would be simpler to write yourself a cheat sheet, and keep it open on
screen,
or print it out.
--
Vicki Rosenzweig
vr at redbird.org
http://www.redbird.org


subject: [Wikipedia-l] Simple XML ideas

body:
> <person>George Washington</person> was the first
> <concept>President</concept> of
> the <place>United States of America</place> after the adoption of
> the <concept>United
> States Constitution</concept>.

That might work, as long as it stays optional.

> If we used namespaces, this would be:
>
> [[George Washington]]
>
> [[person:George Washington]]

I have a bad feeling about this. Not really sure why.

A third possibility would be to revive my "category" feature (it's still in
the code, but deactivated). It would be more easy to mark the *article*
"George Washington* as {{PERSON}} once, instead of making that in every
occurrence manually (which would inevitable result in some articles marked
up like that, some not).


subject: [Wikipedia-l] Simple XML ideas

body:
From: "Jimmy Wales" <jwales at bomis.com>
> If we used namespaces, this would be:
>
> [[George Washington]]
>
> [[person:George Washington]]

Why not [[George Washington (person)]]. I thought that was the whole point
of having namespaces. That reminds of something else I wanted to ask. Why do
we now have two namespace concepts? (We have "X:Y" and we have "Y (X)".) I
would vote for one namespace concept with one notation: X (Y).

> But I think we should think really hard about the dangers of
> proliferating namespaces too quickly.  One of the things we have to
> think really hard about is making sure that any transition to more
> comprensive semantic markup doesn't frighten and confuse people.

Oh dear. Just talking about "comprehensive semantic markup" already
frightens and confuses me. :-) Sounds too much like the semantic web for me.
That will never work.

-- Jan Hidders


body:
Brian,

I just uploaded from CVS and now the <B> and <I> tags don't seem to work
anymore. Frankly, I'm quite happy with that situation, but I suspect some
other people won't be. :)

-- Jan Hidders


subject: [Wikipedia-l] Suggestion #2

body:
Hello,

 Suggestion #2:

 WikiWord:
  page with buttons labeled "BLOCKQUOTE" "LIST" "CARRIER RETURN"...

 you press "LIST"
 you get *

 you press "LINK"
 you get [[insert here you link]]

 stupid?
 not because you NOT need to remind all UserMod trick, you only need press the
button laveled what you need.

 This can bee improved to a small icons, not buttons.

 notes:
 1) optional
 2) improve with small eyecandy lovable icons :D

1 saludo
Tei

note:
at least this will help me, because I dont remember the minimal sintax needed
por wikipedia :P

---------------------------------------------
This message was sent using Endymion MailMan.
http://www.endymion.com/products/mailman/


subject: [Wikitech-l] Most Wanted

body:
> On lun, 2002-02-11 at 14:35, Magnus Manske wrote:
> > I just tried to refresh the page when I got this :
> >
> > (The page was last refreshed just -161981 minutes ago; please wait another
> > 161986 minutes and try again.)
> >
> > That's about 4 month...

I've checked in a fix to special_wantedpages.php that will allow a
refresh when the timestamp is insanely wrong. Jimbo, I highly recommend
installing it, as people are clamoring for WantedPages to work again.

I'd also recommend a cronjob to do an automatic refresh at some
interval; daily would probably be sufficient.

Alternatively, a "maximum refresh interval" could be written into the
page code, so if somebody brings up the page after X amount of time, it
automatically gets refreshed (but the unlucky user has to wait for it to
finish).

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Subsections

body:
Larry wrote:
> I'd like to see one example of an article, or a class of articles, that
> would be clearly improved by being put in article-with-subsections form,
> rather than simply broken into a series of shorter articles.

I understand that you want an example, and I don't intend to make one.
That was why I just mentioned potential power of section headings as
loose idea on the tech list.  Many encyclopedias have really long
articles that are subdivided in this way.  Making separate articles
(without using subpages) requires that they can stand alone with just
a brief introduction at the top.  This is fine with [[Swedish
monarchs]] or [[History of Poland]], which don't need to be part of
[[Sweden]] or [[Poland]].  But "The Middle Ages" is a section heading
in [[History of Poland]].  If broken out into a separate article, what
title should that page have?  Maybe [[Medieval history of Poland]]?

--
  Lars Aronsson
  <lars at aronsson.se>
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/


subject: [Wikitech-l] Cache vs. other-language links

body:
I noticed that the other-language links (links in the form [[fr:Japon]]
[[en:Japan]] [[eo:Japanio]] etc which are hidden in the article body but
listed by language name in the header bar, pointing to the article on
the current subject in the other-language wikis) are vanishing on cached
pages, because they're scanned and listed during the wiki->html link
parsing which of course doesn't occur when loading a cached page.

I've a hackish fix for that which explicitly seeks out the other-
language links for cached pages, but I don't like it very much. It's
inelegant, and two sets of code have to be maintained to do the same
thing in different contexts.

What I'd like to do is add a column to the cur table, something like
cur_links_languages which would be analogous to cur_links_linked and
cur_links_unliked. The list of inter-language links for a page would be
stored when the page is saved, then easily loaded up again along with
the cache. This would also make it easy to provide statistics on the
degree of linkage between language wikis. (No change in current
user-visible behavior except in fixing the obvious bug of vanishing
links, and potentially providing more information in special:Statistics
etc.)

Alternatively, we might have a separate database which contains nothing
but lists of connected articles. This could facilitate keeping the
other-language links consistent; if somebody adds an article "Jap?n" to
the Spanish wikipedia, it shouldn't be necessary to separately add
[[es:Jap%f3n]] to the English, French, Esperanto, etc. articles. Keeping
a central repository would mean that it only needs to be linked in with
the others once, and all linked articles will immediately benefit by
being able to list it without manual editing. Upside: added simplicity
for article writers, who don't have to maintain as many links. Downside:
added complexity for site maintainers, who have to run a second database
or not get all the other-language links. Also might be more difficult to
remove incorrectly linked articles.

An alternative to the separate link database might be a robot/automatic
process that occasionally looks through all the wikipedias checking for
consistency in the other-language links and automatically adding (or
alerting a human that one ought to add) new other-language links where
needed.

So what do people think? Should we try one of these, or should I just
check in my hackish fix for the meantime?

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Re: Simple XML ideas

body:
Jan Hidders wrote:

>Why not [[George Washington (person)]]. I thought that was the whole
>point of having namespaces. That reminds of something else I wanted to
>ask. Why do we now have two namespace concepts? (We have "X:Y" and we
>have "Y (X)".) I would vote for one namespace concept with one
>notation: X (Y).

I think the two are different: the software enforced name spaces are
there to separate the encyclopedia proper from all the cruft
surrounding it. Your parenthesis notation serves mainly to distinguish
several concepts with the same name: [[Cardinal (bird)]], [[Cardinal
(person)]]. I don't think people want to or should be required to
universally slap on "(person)" to every title that describes a person.

Jimbo's "tagging" idea is different still. I agree with Magnus: if
such a tagging is to take place, it would have to happen on the
article level, maybe easiest as a little choice list when you edit and
submit an article (Place, Idea, Person, etc.) That wouldn't complicate
matters for contributors (they could always ignore the choice list and
leave it at the default). I don't immediately see the payoff though.

Axel


subject: [Wikipedia-l] Subsections

body:
On Wed, 13 Feb 2002, Jan Hidders wrote:

> From: "Larry Sanger" <lsanger at nupedia.com>
> >
> > I just formulated an interesting hypothesis, which might explain why some
> > people are attracted to ideas like subpages and subsections, despite the
> > many clear disadvantages of them.  Sorry, this is going to be a bit of a
> > ramble. [...]
>
> Hm, I believe you have actually convinced me. Can I summarize you as
> follows: we don't want people to build their own little hierarchies in
> this encyclopedia and have some links between them, but we want an
> interlinked web of relatively self-contained small articles that give
> a sketch of the context necessary to understand them and link to other
> articles that describe the context in a general way or parts of the
> context in more detail.
>
> Correct?

Right!  To be clear, it sounds to me like you've summarized what I think
people *should* want, and what perhaps many people already do want--but
which (I was saying) advocates of subpages and subsections (maybe) don't
want.  *My* view (to elaborate what you said a bit) is that they should
not build their own little hierarchies in this encyclopedia and have
*hard-wired* (special, hard-to-remove) links between the elements of them.
Instead, as you say, we should have an interlinked web of, indeed,
relatively self-contained small (or relatively small) articles that give a
sketch of the context necessary to understand them, and link to other
articles that describe that context in a more general way or, instead,
that describe details of the context in more detail.

Of course, "more general" and "more detailed" are not always neatly
distinct or exhaustive categories: for articles that link to each other,
there are other important conceptual relationships between their topics.

Larry


subject: [Wikipedia-l] Re: Simple XML ideas

body:
On Wed, 13 Feb 2002, Mark Christensen wrote:

>
> > Why? This would keep the software and the interface simple and more
> > consistent. Look at the links to namespaces at the bottom of pages.
> > Sometimes there is none, sometimes one, sometimes two. Why is that?
> > And why on earth is the link to a discussion page called
> > a namespace? And why is there no Talk page for SpecialPages?
>
> I think constancy is not the solution, it's the problem.

I agree with this--different pages (or classes of pages) have different
functions and we need those functions really clearly indicated.

Larry


subject: [Wikipedia-l] Suggestion #2

body:
On Tue, 12 Feb 2002, Vicki Rosenzweig wrote:

> At 12:50 AM 2/13/02 +0000, Tei wrote:

> >  WikiWord:
> >   page with buttons labeled "BLOCKQUOTE" "LIST" "CARRIER RETURN"...
> >  you press "LIST"
> >  you get *

> It would be simpler to write yourself a cheat sheet, and keep it open
> on screen, or print it out.

There's room below the edit field when you edit an article and haven't
previewed it yet. I think it would be a good idea to list out the basics
there.

-- Daniel


subject: [Wikipedia-l] Re: Simple XML ideas

body:
On Wed, 13 Feb 2002, Magnus Manske wrote:

> > I would actually suggest that we try somehow to change the "look and feel"
> > of the special namespaces, so that people will just SEE the distinction as
> > they browse through our site.
>
> I think that's what is bugging me about the "()", in a way. Talk pages
> are not just a variant of encyclopedia articles, they're something
> else entirely, even though they use the same interface and syntax. The
> hardwired ":" character makes a clear distinction between the pages
> types, while "()" does not. There are already some articles with "()"
> in the name, and I'm afraid the talk, wikipedia and user pages would
> blend into each other again if we stop using the ":".

Yes!  So Mark is right, here: the other namespaces need some different
sort of look and feel.  Different background colors, anyway, something
like that.

> I agree that the special namespaces should be distingushed more from
> the encyclopedia pages. Again, this is more a layout problem than
> anything else. How about marking the namespace part of the title in
> red, of italics?

The namespace part of the URL doesn't have to appear in the title at all
(as it doesn't for special: pages--odd); in fact, probably shouldn't since
it's so ugly.  But maybe there should be some indication on the page of
how to link to the page, perhaps just below the title.  Maybe something
like this:

[=+[=+Talk section+=]+=]  <-- This is a distinctive talk section header
Philosophy  <-- page name
(link to this page with <aColor>[[talk:Philosophy]]</aColor>) <--notice

> The namespace display should also be updated. The link to the Talk namespace
> should probably get a special position, or an icon or something.

Yes, clearly some special treatment.  One shouldn't need to know that, in
order to talk about an article, one should click on the "Talk" link (the
reader might well say: "Gee, is that a link or cryptic green colored
text?") that follows "Other namespaces" ("What the hell is a namespace?
Nothing I'd be interested in, because I don't even know what 'namespace'
means.")

> I think Larry agrees with me that hardwireing is a *good* thing to sepetate
> the actual articles from the "surrounding" pages. That was *one* of the
> reasons we made meta.wikipedia.com, right?

Right!  As I said when it was being made, I wouldn't be entirely averse to
there being a meta: namespace--as long as the meta: namespace had a
separate Recent Changes page.

Larry


subject: [Wikipedia-l] Re: Simple XML ideas

body:
On Wed, 13 Feb 2002, Jan Hidders wrote:

> How about user friendliness? Is that not a good reason? But the names
> was only one point. What matters is that it should be either obvious
> or easy to explain why these links are there an what they mean. I
> believe we can do better than this.

I think your solution is actually less user-friendly.  We simply need to
retain namespaces (they work fine, for the most part) and provide unique,
user-friendly templates (I guess) for pages in different namespaces.
E.g., talk pages could have one frame color and set of links--even font.
Wikipedia pages could have a different frame color, and of course
different links.  User pages and special pages, ditto.  The user should
have the experience of being in different *parts* of the website, even
though the thing is run from the same database.  That's what's going to
constitute a real improvement in useability.  Making the page names all
the same format doesn't constitute a significant improvement in user
friendliness at all, that I can see.  It's a decided disimprovement
insofar as we use ":" to indicate namespaces and thus website page
function, and we use "(...)" to disambiguate similarly-named topics.

Larry


subject: [Wikipedia-l] Re: Simple XML ideas

body:
An example of the sort of thing Mark is talking about is given on the
Nupedia website.  Compare these three pages:

http://www.nupedia.com/
http://www.nupedia.com/newsystem/member.phtml
http://www.nupedia.com/article/short/The+Quasispecies+model/