subject: [Wikipedia-l] Celebration

body:
I hereby decree, in my usual authoritarian and bossy manner, that today shall
forever be known as Magnus Manske day.  Wikipedians of the distant future will
marvel at the day when the new software era dawned upon us.

Tonight at dinner, every Wikipedian should say a toast to Magnus and his many
inventions.

--Jimbo


list: wikipedia-l

source: pipermail-mbox

from_name: Jimmy Wales

subject: [Wikipedia-l] tarball

in_reply_to: <1011997307.10822.0.camel@rdaneel.moisty.org>; from brion@pobox.com on Fri, Jan 25, 2002 at 02:21:46PM -0800

body:
Brion Vibber wrote:
> http://www.wikipedia.com/tarballs/
> Error 404 File Not Found

Darn, this is due to the upgrade.  I'll fix it now.

> http://www.wikipedia.com/
> Warning: MySQL Connection Failed: Too many connections in
> ./databaseFunctions.php on line 6
>
> Warning: Supplied argument is not a valid MySQL-Link resource in
> ./wikiPage.php on line 46
> ......

I'm working on changing the config file to allow more connections.

--Jimbo


from_name: Brion Vibber

subject: [Wikipedia-l] tarball

body:
On ven, 2002-01-25 at 10:24, Jimmy Wales wrote:
> > I do have a problem though, that you can help me with if you will.
> > It seems the tarball is not being updated regularly.
>
> In my opinion, the tarball is updated nightly, and has been for a few
> weeks.  I just looked, and it looks good!  Have you checked it lately?

http://www.wikipedia.com/tarballs/
Error 404 File Not Found

Hmm...

http://www.wikipedia.com/
Warning: MySQL Connection Failed: Too many connections in
./databaseFunctions.php on line 6

Warning: Supplied argument is not a valid MySQL-Link resource in
./wikiPage.php on line 46
......

:((

-- brion vibber (brion @ pobox.com)


from_name: Tim Chambers

subject: [Wikipedia-l] wikipedia.com cut over to PHP?

body:
What a surprise! I checked
http://www.nupedia.com/pipermail/wikipedia-l/2002-January/date.html to be
sure and see no announcement that the 'pedia was cutting over to Magnus'
package.
http://www.wikipedia.com/wiki/special:RecentChanges doesn't even list a page
that obviously mentions this historic event.

Oh, well. What's done is done. But I have noticed turmoil that I can't keep
up with. All the links seemed to be getting generated or interpreted
incorrectly (or both), pointing to create-a-page. But links of the form
http://www.wikipedia.com/wiki/something worked fine. Now as I write, all
seem to point to the home page. Sigh. Thrash, thrash, thrash.

I looked through the last 5,000 changes and see mostly [Automated
conversion] comments.

Would one of these users who have been active care to comment?

Damian Yerrick
Joao
Magnus Manske
Matthew Woodcraft
MichaelTinkler
Paul Drye
RjLesch
Tobias Hoevekamp
Trelvis
TwoOneTwo


subject: [Wikipedia-l] tarball

body:
On ven, 2002-01-25 at 14:20, Jimmy Wales wrote:
> Brion Vibber wrote:
> > http://www.wikipedia.com/tarballs/
> > Error 404 File Not Found
>
> Darn, this is due to the upgrade.  I'll fix it now.

Forbidden
You don't have permission to access /tarballs/ on this server.

Well, we're on the right track at least. :)

> > http://www.wikipedia.com/
> > Warning: MySQL Connection Failed: Too many connections in
> > ./databaseFunctions.php on line 6
> >
> > Warning: Supplied argument is not a valid MySQL-Link resource in
> > ./wikiPage.php on line 46
> > ......
>
> I'm working on changing the config file to allow more connections.

Seems better now, thanks.

Testing.... Uh-oh. Looks like the entities bug is still there. :(
This is a serious bug for pages containing HTML entities for
non-Latin1 characters (for instance the Japanese names in
http://wikipedia.com/wiki/Miyazaki_Hayao ). The &s are not escaped into
&s when the text is inserted into edit box, and the browser thus
interprets character entities as the actual characters. When the text is
submitted for save or preview, everything after the first non-Latin1
character gets cut off from the page (ie, MASSIVE DATA LOSS).

I thought this had been fixed... leastwise, it works perfectly in the
copy of the source I grabbed earlier this month to work on.
(basicFunctions.php from 9 Janurary attached for comparison, see lines
67 and 89)

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: basicFunctions.php
Type: application/x-php
Size: 6698 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020125/8f849f16/attachment.bin


subject: [Wikipedia-l] tarball

in_reply_to: <20020126005046.GE14762@lupercalia.net>; from david@lupercalia.net on Fri, Jan 25, 2002 at 07:50:46PM -0500

body:
I think /pages/ is the latest and greatest.  The 'keep' files are, uh, I'm not
sure what exactly.

I guess everything is changing pronto, though!  I'll make sure your tarball is
downloadable, but since we've changed software the old tarball will be increasingly
irrelevant.

We'll have to put together a new tarball of the mysql database.

David Merrill wrote:

> On Fri, Jan 25, 2002 at 10:24:49AM -0800, Jimmy Wales wrote:
> > David, that's great news!
> >
> > Actually, Wikipedia did 14,780,010 pageviews in December, and is on track
> > to break 17 million this month. :-)
> >
> > > I do have a problem though, that you can help me with if you will.
> > > It seems the tarball is not being updated regularly.
> >
> > In my opinion, the tarball is updated nightly, and has been for a few
> > weeks.  I just looked, and it looks good!  Have you checked it lately?
>
> Checked it last night. I thought it was outdated because there is no
> Andrew_S._Tanenbaum.kp file. Perhaps I misunderstand the file
> structure? Which subdir is the official, latest-and-greatest? Feel
> free to tell me to rtfm if you also give me the location of the fm.
>
> :-)
>
> --
> David C. Merrill                         http://www.lupercalia.net
> Linux Documentation Project                   david at lupercalia.net
> Collection Editor & Coordinator            http://www.linuxdoc.org
>
> Asked how small software companies could compete on products that Microsoft
> wants to fold into Windows, [Microsoft COO Bob] Herbold told Bloomberg News
> they could either fight a losing battle, sell out to Microsoft or a larger
> company or 'not go into business to begin with.'
> 	--Newsweek, March 1998
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


subject: [Wikipedia-l] Memory usage

body:
Memory usage seems to be the greatest problem.  I'm lowering the maximum number
of apache connections to get that under control.  This might cause some problems
for some people connecting.

The real solution is the buy more memory.  This machine has 512Mb, I will bump it
up to 2 gig as soon as I can.

--Jimbo


from_name: lcrocker at nupedia.com

subject: [Wikipedia-l] New software

body:
Seems to be working better now.  I need to go through all my pages
now and update them (with things like parenthesized titles and
no subpages andso on), but it just so happens that this is the
weekend of the big poker tournament at Casino San Pablo, so it'll
have to wait for next week :-)


from_name: Magnus Manske

subject: [Wikipedia-l] 'ing' words

body:
> I'll think about how to make this change, but I think I'll hold
> off until we have
> some experience with the php/mysql search engine.  I think it'll
> be sort of o.k.,
> but I think with some creativity, I can do something that will beat it.

I bet you can ;)
Currently, I am just putting jokers around the search request ("%foobar%")
and look for it in titles and fulltext. Pityful, yes.

I'd also suggest to have some Google-like mechanism that uses your "trick"
and suggests links with "Did you mean to search for *foobaring*?" or
similar. That wouldn't mess up the search results and still make it easy to
try variations.

Magnus


from_name: David Merrill

subject: [Wikipedia-l] tarball

body:
On Fri, Jan 25, 2002 at 10:24:49AM -0800, Jimmy Wales wrote:
> David, that's great news!
>
> Actually, Wikipedia did 14,780,010 pageviews in December, and is on track
> to break 17 million this month. :-)
>
> > I do have a problem though, that you can help me with if you will.
> > It seems the tarball is not being updated regularly.
>
> In my opinion, the tarball is updated nightly, and has been for a few
> weeks.  I just looked, and it looks good!  Have you checked it lately?

Checked it last night. I thought it was outdated because there is no
Andrew_S._Tanenbaum.kp file. Perhaps I misunderstand the file
structure? Which subdir is the official, latest-and-greatest? Feel
free to tell me to rtfm if you also give me the location of the fm.

:-)

--
David C. Merrill                         http://www.lupercalia.net
Linux Documentation Project                   david at lupercalia.net
Collection Editor & Coordinator            http://www.linuxdoc.org

Asked how small software companies could compete on products that Microsoft
wants to fold into Windows, [Microsoft COO Bob] Herbold told Bloomberg News
they could either fight a losing battle, sell out to Microsoft or a larger
company or 'not go into business to begin with.'
	--Newsweek, March 1998


from_name: General Wesc

subject: [Wikipedia-l] Apology

body:
As long as we're not confronted with a "Word Galaxy" for 15-20 minutes
every night, it's cool.

Magnus Manske wrote:
>
> I hereby apologize for the inconveniences my software currently causes. But,
> nothing like that ever showed up on the test sites, and it seems the current
> problems are "only" a matter of configuration to handle "real-life" load. As
> far as I can tell, it is *not* a problem with the script itself, and should
> therefore be fixed soon.
>
> I am confident the new functions will outweight the rough start.
>
> Magnus
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l

--General Wesc,
http://wescnet.cjb.net/
[Politeness is always in order]


subject: [Wikipedia-l] tarball

body:
On Fri, Jan 25, 2002 at 04:22:38PM -0800, Jimmy Wales wrote:
> I think /pages/ is the latest and greatest.  The 'keep' files are, uh, I'm not
> sure what exactly.
>
> I guess everything is changing pronto, though!  I'll make sure your tarball is
> downloadable, but since we've changed software the old tarball will be increasingly
> irrelevant.
>
> We'll have to put together a new tarball of the mysql database.

I assume the format will not be changing? If so, I'll wait until it's
settled down.

I will also look at the /pages/ directory. I don't remember why I
didn't think that was right. IIRC, it was because it contained lots
of:

>foo
<bar

type of stuff, which made me assume it was "changes". But I'll look at
it again. Is there a webpage which describes the file formats and
stuff, or do I need to go through the code?

Thanks a lot, Jimbo. I appreciate the help.

--
David C. Merrill                         http://www.lupercalia.net
Linux Documentation Project                   david at lupercalia.net
Collection Editor & Coordinator            http://www.linuxdoc.org

Like any dictatorship, when things start to get tough Microsoft is going to
discover that it has lots of allies, but very few friends.
	--Dan Gillmor, San Jose Mercury Columnist


subject: [Wikipedia-l] Apology

body:
I hereby apologize for the inconveniences my software currently causes. But,
nothing like that ever showed up on the test sites, and it seems the current
problems are "only" a matter of configuration to handle "real-life" load. As
far as I can tell, it is *not* a problem with the script itself, and should
therefore be fixed soon.

I am confident the new functions will outweight the rough start.

Magnus


subject: [Wikipedia-l] rate of change

in_reply_to: <200201261929.g0QJTNH28713@levi.aronsson.se>; from lars@aronsson.se on Sat, Jan 26, 2002 at 08:29:23PM +0100

body:
Lars Aronsson wrote:
> Would it be reasonable to update the search index each time a new
> version of a page is saved?  In that case, the search would still be
> indexed (and fast), but it would always be up-to-date.

This is true now, since the pages are in a true database with Magnus's new
software.  In the old version, all the data was just stored in text files
on disk.  I wrote a program to go through and analyze the keywords from all
the pages and titles, and construct a search index from that.

I always wanted to put it on a cron job to update nightly, but it was
so inefficient that I didn't feel comfortable letting it run without
supervision, and I didn't feel comfortable running it all that often.

Now that everything is in a real database, it should be true that with a
little playing around and tweaking, we can get decent results that are
fast and also always instantly updated.

The current version is a very simple SQL query.  It doesn't work so well in
terms of being intelligent about returning what you probably want.


subject: [Wikipedia-l] rate of change

in_reply_to: <ILENJBCFHGHELEBFPPBGMEPKCEAA.Magnus.Manske@epost.de>; from Magnus.Manske@epost.de on Sat, Jan 26, 2002 at 10:24:23PM +0100

body:
Cool, and I'm going through them now, making updates.  :-)

Magnus Manske wrote:

> Jimbo, I sent you a zillion mails today (your night;), with a better search
> engine among them.
>
> Magnus
>
> > -----Original Message-----
> > From: wikipedia-l-admin at nupedia.com
> > [mailto:wikipedia-l-admin at nupedia.com]On Behalf Of Jimmy Wales
> > Sent: Saturday, January 26, 2002 10:06 PM
> > To: wikipedia-l at nupedia.com
> > Subject: Re: [Wikipedia-l] rate of change
> >
> >
> > Lars Aronsson wrote:
> > > Would it be reasonable to update the search index each time a new
> > > version of a page is saved?  In that case, the search would still be
> > > indexed (and fast), but it would always be up-to-date.
> >
> > This is true now, since the pages are in a true database with Magnus's new
> > software.  In the old version, all the data was just stored in text files
> > on disk.  I wrote a program to go through and analyze the
> > keywords from all
> > the pages and titles, and construct a search index from that.
> >
> > I always wanted to put it on a cron job to update nightly, but it was
> > so inefficient that I didn't feel comfortable letting it run without
> > supervision, and I didn't feel comfortable running it all that often.
> >
> > Now that everything is in a real database, it should be true that with a
> > little playing around and tweaking, we can get decent results that are
> > fast and also always instantly updated.
> >
> > The current version is a very simple SQL query.  It doesn't work
> > so well in
> > terms of being intelligent about returning what you probably want.
> > [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] Slight formatting bug

in_reply_to: <ILENJBCFHGHELEBFPPBGOEPOCEAA.Magnus.Manske@epost.de>; from Magnus.Manske@epost.de on Sat, Jan 26, 2002 at 11:44:51PM +0100

body:
Magnus Manske wrote:
> I am happy to say that Jimbo fixed the "&foobar;" bug, so it should be safe
> now to edit and save articles with special characters again.

Actually, I think credit goes to Brion or you.  All I did was install
what you guys sent me. :-)

--Jimbo


subject: [Wikipedia-l] Major edit bug warning

body:
There is a major bug in the script that wasn't spotted on the test site. The
bugfix is in the mail, waiting for Jimbo to install it.

In the meantime, beware of editing and saving articles that contain special
unicode characters in "&something;" notation. You might trash the page. Try
preview first, if the whole page is visible, it should be OK.

Again, the bugfix is in the mail, and will probably online within minutes.

Sorry for the inconvenience,
Magnus


from_name: Lars Aronsson

subject: [Wikipedia-l] rate of change

body:
What is the percentage of Wikipedia pages that get edited each day (or
week, or month), and has that percentage changed over time?

Or what are the number of daily page views, page edits, and searches?

Of course, on the first day, 100 % of the pages were altered... so it
would be reasonable to think that the rate of change slowly decreases
as a wiki site grows.  Is this so?  Do wiki pages find their final
form, never to be edited again, or at least more and more seldom?
Could we get some numbers on this?

Would it be reasonable to update the search index each time a new
version of a page is saved?  In that case, the search would still be
indexed (and fast), but it would always be up-to-date.

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


subject: [Wikipedia-l] rate of change

body:
> Would it be reasonable to update the search index each time a new
> version of a page is saved?  In that case, the search would still be
> indexed (and fast), but it would always be up-to-date.

The search engine actually isn't updated anymore. It searches through the
MySQL database now, so it is always up-to-date.

Magnus


subject: [Wikipedia-l] rate of change

body:
Jimbo, I sent you a zillion mails today (your night;), with a better search
engine among them.

Magnus

> -----Original Message-----
> From: wikipedia-l-admin at nupedia.com
> [mailto:wikipedia-l-admin at nupedia.com]On Behalf Of Jimmy Wales
> Sent: Saturday, January 26, 2002 10:06 PM
> To: wikipedia-l at nupedia.com
> Subject: Re: [Wikipedia-l] rate of change
>
>
> Lars Aronsson wrote:
> > Would it be reasonable to update the search index each time a new
> > version of a page is saved?  In that case, the search would still be
> > indexed (and fast), but it would always be up-to-date.
>
> This is true now, since the pages are in a true database with Magnus's new
> software.  In the old version, all the data was just stored in text files
> on disk.  I wrote a program to go through and analyze the
> keywords from all
> the pages and titles, and construct a search index from that.
>
> I always wanted to put it on a cron job to update nightly, but it was
> so inefficient that I didn't feel comfortable letting it run without
> supervision, and I didn't feel comfortable running it all that often.
>
> Now that everything is in a real database, it should be true that with a
> little playing around and tweaking, we can get decent results that are
> fast and also always instantly updated.
>
> The current version is a very simple SQL query.  It doesn't work
> so well in
> terms of being intelligent about returning what you probably want.
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


from_name: Axel Boldt

subject: [Wikipedia-l] Slight formatting bug

body:
If you check out
  http://wikipedia.com/wiki/How_to_edit_a_page
you will see that many entries under "Character formatting" are
screwed up: the new parser apparently doesn't allow entities like
& in <pre> formatted entries. That was different with the old
parser.

Axel


subject: [Wikipedia-l] Slight formatting bug

body:
Yeah, the parser is a little different than the old one, in several
instances. I don't think the differences will affect many articles, though.

I am happy to say that Jimbo fixed the "&foobar;" bug, so it should be safe
now to edit and save articles with special characters again.

BTW, if you notice both a "User talk" and a "User Talk" link on your user
page, it's just a glitch in the matrix ;) and both seem to point to the same
page. I'll fix it, someday...

Magnus

> -----Original Message-----
> From: wikipedia-l-admin at nupedia.com
> [mailto:wikipedia-l-admin at nupedia.com]On Behalf Of Axel Boldt
> Sent: Saturday, January 26, 2002 11:33 PM
> To: wikipedia-l at nupedia.com
> Subject: [Wikipedia-l] Slight formatting bug
>
>
> If you check out
>   http://wikipedia.com/wiki/How_to_edit_a_page
> you will see that many entries under "Character formatting" are
> screwed up: the new parser apparently doesn't allow entities like
> & in <pre> formatted entries. That was different with the old
> parser.
>
> Axel
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


subject: [Wikipedia-l] congratulations

body:
Congratulations on the move to the new software. No, it wasn't
completely smooth, but things like this *never* are. All in all it
went pretty damned well.

And the new software is just plain schweeet.

--
David C. Merrill                         http://www.lupercalia.net
Linux Documentation Project                   david at lupercalia.net
Collection Editor & Coordinator            http://www.linuxdoc.org

Windows is an utter kludge, the ultimate tar baby, sucking you in, making
things harder and harder, until you are hopelessly snagged and stuck,
exhausted from fighting with it, resigned to despair. It is an inscrutable,
god-awful mess, a disaster waiting to happen, a bonehead botch-job jammed
with you-can't-get-there-from-here idiocy. They could train soldiers to
kill by forcing them to struggle with this.
	--Paul Somerson, PC Computing


from_name: wojtek pobratyn

subject: [Wikipedia-l] congratulations

body:
oh, yes. it's working nice and snappy now.
great job!

++wojpob

David Merrill <david at lupercalia.net> napisa?:

>Congratulations on the move to the new software. No, it wasn't
> completely smooth, but things like this *never* are. All in all it
> went pretty damned well.
>
> And the new software is just plain schweeet.
>
> --
> David C. Merrill                         http://www.lupercalia.net
> Linux Documentation Project                   david at lupercalia.net
> Collection Editor & Coordinator            http://www.linuxdoc.org
>
> Windows is an utter kludge, the ultimate tar baby, sucking you in, making
> things harder and harder, until you are hopelessly snagged and stuck,
> exhausted from fighting with it, resigned to despair. It is an inscrutable,
> god-awful mess, a disaster waiting to happen, a bonehead botch-job jammed
> with you-can't-get-there-from-here idiocy. They could train soldiers to
> kill by forcing them to struggle with this.
> --Paul Somerson, PC Computing
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>
>
>
>
>

--

Okresl Swoje potrzeby - my znajdziemy oferte za Ciebie!
[ http://oferty.onet.pl ]


subject: [Wikipedia-l] wikipedia text format

body:
I have a couple of general wiki questions, and thought I would ask here
since several of you have pretty good wiki experience.

How standard is the wikipedia text format?

Is there a standard name for that type of format? I am calling it
WikiText, but I'd rather use the usual term, if there is one. My
conversion utility is called txt2db, but I realized that is a bad
name. It's not for any text file, but for a specific format. So I want
toknow how I should properly refer to it.

btw, I will have a demo of some Wikipedia articles on my LDP mirror
soon, and after that passes LDP staff inspection, it will go live on
the LDP site! Woo Hoo! That should get Wikipedia some good publicity,
and it will sure help the LDP as well. Thanks again to all of you for
your wonderful spirit of cooperation.

--
David C. Merrill                         http://www.lupercalia.net
Linux Documentation Project                   david at lupercalia.net
Collection Editor & Coordinator            http://www.linuxdoc.org

Microsoft does not like negative or even objective press coverage and they
have a tendency to be a bully about it. If something appears that they
don't like, they have the ability to punish the publication.
	--Knight-Ridder New Media President Bob Ingle


from_name: sgilbert at nbnet.nb.ca

subject: [Wikipedia-l] Re: wikipedia text format

body:
On Sun, 27 Jan 2002, David Merrill <david at lupercalia.net> wrote:
>
> I have a couple of general wiki questions, and thought I would ask here
> since several of you have pretty good wiki experience.

Actually, I would suggest asking asking at MeatBallWiki
(http://www.usemod.com/cgi-bin/mb.pl), perhaps on the
WikiSyntax page (http://www.usemod.com/cgi-
bin/mb.pl?WikiSyntax). There's tons of wiki *design* experience
over there. From the look of things, however, I don't think there is a
common text format for all wikis.
>
> btw, I will have a demo of some Wikipedia articles on my LDP mirror
> soon, and after that passes LDP staff inspection, it will go live on
> the LDP site! Woo Hoo! That should get Wikipedia some good publicity,
> and it will sure help the LDP as well. Thanks again to all of you for
> your wonderful spirit of cooperation.

No sir, thank you! As a rank-and-file Wikipedian, I'm absolutely
delighted at the cooperation between our two projects, and I'm
hoping that many other people use Wikipedia in various creative
ways. I'm looking forward to the day that our encyclopedia is a
standard inclusion for Linux distributions.

- Stephen Gilbert (STG)


subject: [Wikipedia-l] wikipedia text format

in_reply_to: <20020127204435.GA13865@lupercalia.net>; from david@lupercalia.net on Sun, Jan 27, 2002 at 03:44:35PM -0500

body:
David Merrill wrote:
> Is there a standard name for that type of format? I am calling it
> WikiText, but I'd rather use the usual term, if there is one.

CamelCase is what people call it when you smash words together.

I think that this format:

[[Wiki Text]] is our own invention (Larry?  Clifford Adams?  me? someone
else? doesn't matter I guess...), or at least I think so.

I know that in an earlier version of UseMod Wiki, CamelCase was all that worked,
but people thought it looked too silly for an encylopedia, so Clifford coded up the
[[]] system for us.

--Jimbo


subject: [Wikipedia-l] wikipedia text format

in_reply_to: <20020128052331.GA27433@lupercalia.net>; from david@lupercalia.net on Mon, Jan 28, 2002 at 12:23:31AM -0500

body:
You should ask Ward Cunningham and Clifford Adams.  I think Clifford was
trying (mostly) to make a perl clone of c2 wiki, and I think many or most
of those were originally on c2.

But I don't think there's a single standard or name for it.

At Wikipedia, if I go through an article and add wiki markup, we call it
'wikifying' as in: "I wikified a few words in this article."

But that's just our own slang, I guess.

David Merrill wrote:

> On Sun, Jan 27, 2002 at 08:14:40PM -0800, Jimmy Wales wrote:
> > David Merrill wrote:
> > > Is there a standard name for that type of format? I am calling it
> > > WikiText, but I'd rather use the usual term, if there is one.
> >
> > CamelCase is what people call it when you smash words together.
> >
> > I think that this format:
> >
> > [[Wiki Text]] is our own invention (Larry?  Clifford Adams?  me? someone
> > else? doesn't matter I guess...), or at least I think so.
> >
> > I know that in an earlier version of UseMod Wiki, CamelCase was all that worked,
> > but people thought it looked too silly for an encylopedia, so Clifford coded up the
> > [[]] system for us.
>
> I see. Well that isn't very helpful for me, but I think that's because
> there really isn't an answer.
>
> I'm talking about not just the way a link is done, but also the * for
> bullets, # for numbering, ---- for rules, = for sections, etc. All of
> those are what I'm using.
>
> Maybe if there isn't any regularly used term, I'll just make something
> up, play marketroid. :-)
>
> --
> David C. Merrill                         http://www.lupercalia.net
> Linux Documentation Project                   david at lupercalia.net
> Collection Editor & Coordinator            http://www.linuxdoc.org
>
> I have a nice perspective on what it means to be in charge of the most
> important project in the history of mankind.
> 	--Microsoft project manager Brian Valentine,
> 	  as quoted in BusinessWeek 02.22.99
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


subject: [Wikipedia-l] New features list

body:
As I noticed some people being confused about how to do what in the new
software (watchlist etc.), I ask everybody to visit

http://www.wikipedia.com/wiki.phtml?title=wikipedia:PHP+script+new+features

that gives an initial (though incomplete) overview of the new features.
Please help me completing this, as I don't remember all features I
implemented ;)

Magnus


subject: [Wikipedia-l] wikipedia text format

body:
On Sun, Jan 27, 2002 at 08:14:40PM -0800, Jimmy Wales wrote:
> David Merrill wrote:
> > Is there a standard name for that type of format? I am calling it
> > WikiText, but I'd rather use the usual term, if there is one.
>
> CamelCase is what people call it when you smash words together.
>
> I think that this format:
>
> [[Wiki Text]] is our own invention (Larry?  Clifford Adams?  me? someone
> else? doesn't matter I guess...), or at least I think so.
>
> I know that in an earlier version of UseMod Wiki, CamelCase was all that worked,
> but people thought it looked too silly for an encylopedia, so Clifford coded up the
> [[]] system for us.

I see. Well that isn't very helpful for me, but I think that's because
there really isn't an answer.

I'm talking about not just the way a link is done, but also the * for
bullets, # for numbering, ---- for rules, = for sections, etc. All of
those are what I'm using.

Maybe if there isn't any regularly used term, I'll just make something
up, play marketroid. :-)

--
David C. Merrill                         http://www.lupercalia.net
Linux Documentation Project                   david at lupercalia.net
Collection Editor & Coordinator            http://www.linuxdoc.org

I have a nice perspective on what it means to be in charge of the most
important project in the history of mankind.
	--Microsoft project manager Brian Valentine,
	  as quoted in BusinessWeek 02.22.99


subject: [Wikipedia-l] wikipedia text format

body:
> The old e-mail and Usenet news convention is to
> use _italics_ and *boldface*.

Dolphin WikiWeb uses those conventions:
http://www.object-arts.com/wiki/html/Dolphin/WikiTextFormattingRules.htm

I can't find the reference that explains his rationale, but I seem to
recall that Ward created ''italic'' and '''bold''' because those
markups were easily distinguishable and trivial to type. Both _ and *
require the use of the shift key, and that didn't meet with his
objective to make content creation as easy as possible. Of course,
that doesn't explain why he settled on CamelCase, but I think it's
safe to say that CamelCase betrays the influence of his
object-oriented coding background. (CamelCase is more popular than
underscores_in_variables among OO types.) I, for one, am extremely
grateful to Cliff Adams for inventing the [[free link]] convention.
Easy to distinguish from plain text, easy to type, and it's more
aesthetically pleasing and flexible.

__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com


subject: [Wikipedia-l] wikipedia text format

body:
Tim Chambers wrote:
> > The old e-mail and Usenet news convention is to
> > use _italics_ and *boldface*.

I personally don't use '' and ''' because I can never remember which is which.
I use <i> and <b>, which come from html, and strike me as more intuitive for the
newcomer.

But wikipedia supports both, of course.

> objective to make content creation as easy as possible. Of course,
> that doesn't explain why he settled on CamelCase,

Well, I think CamelCase is consistent with making content creation as easy as
possible.  It's "transparent" as it looks the same in editing and in the output.
It looks _silly_ in the output, which is why we are no longer using it at Wikipedia,
but it certainly makes it easy for newcomers to get started.

But [[]] are also super-easy, of course.

--Jimbo


subject: [Wikipedia-l] wikipedia text format

body:
Jimmy wrote:
> At Wikipedia, if I go through an article and add wiki markup, we call it
> 'wikifying' as in: "I wikified a few words in this article."

What is the history of using multiple single quotes for ''italics''
and '''boldface'''?  The old e-mail and Usenet news convention is to
use _italics_ and *boldface*.  Has that text format ever been named
and documented?

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


subject: [Wikipedia-l] Apology

in_reply_to: <r5ik7u28pro.fsf@gill.maths.keele.ac.uk>; from wiki@gwowen.freeserve.co.uk on Mon, Jan 28, 2002 at 03:21:47PM +0000

body:
Gareth Owen wrote:
> Or, indeed, beyond.  Which is why you don't (or at least *shouldn't*) roll out
> new code into production use without stress testing it.

Good idea!  Are you volunteering to do this for us next time around?

> Can we not have the old one back until the code/hardware can at least perform
> in an acceptable manner?

Since people successfully editing and working, and since the data is now in a
totally different format, rolling back is not really much of an option.

I agree that the site is slow.  It will improve over the next few days.

> PPS:  There is also an old saying that starts:
>         "If it ain't broke..."

There's also an old saying:  "Beggars can't be choosers."

--Jimbo


from_name: Uri Yanover

subject: [Wikipedia-l] No-subpage policy makes editing [[Middle Earth]] difficult

body:
Hello,

The recent conversion to the no-subpage policy has created a
problem with editing those pages that describe whole independent
universes. This first came to my mind in relation to
[[Middle Earth]], but it is also relevant to pages such as
[[Star Wars]], [[Star Trek]] and possibly other pages.

Since this involves a policy issue as well as a technical one,
I wanted to discuss it in Wikipedia-L before I (or someone else)
began to write lengthy patches.

The problem is in the following: it is extremely inconvenient
(as a policy) to write "[[Middle Earth/Elrond|Elrond]] was
the lord of [[Middle Earth/Rivendell|Rivendell]]" than it is
to write "[[Elrond]] was the lord of [[Rivendell]]"

I could think of several solutions to this problem:
* Remove the [[Middle Earth/]] part (e.g. [[Elrond]] instead
    of [[Middle Earth/Elrond]]. But this would not only
    add fictional content to the generally real-world
    encyclopedia but also confuse the readers (think about
    [[USS Enterprise]]!)
* Creating a new namespace (e.g. [[Middle Earth:Elrond]]).
    But that would not automatically solve the linking problem,
    and would generally contradict the way namespaces are
    used now (the division being functional and not
    content-oriented).
* Creating a new Middle Earth wiki. Although it would solve
    most of the problems above, that would require too much
    effort and make linking with the "main" Wikipedia more difficult.

The solution which I would personally prefer is to add another
addressing mode to the Wiki links.For example, we could add
a #base directive after which all links except escaped ones
would receive a certain prefix. For example:

#base [[Middle Earth/]]
[[!JRR Tolkien]] wrote that [[Elrond]] was the lord of Rivendell.

The link with the prefixing "!" would not be affected. However
after the #base directive, [[Elrond]] will automatically become
[[Middle Earth/Elrond]].

What do you think about it? Could this be implemented or there's
another (easier) solution?

Sincerely yours,
                Uri Yanover


from_name: Gareth Owen

subject: [Wikipedia-l] Apology

in_reply_to: "Derek Ross"'s message of "Sat, 25 Jan 2003 23:00:03 -0000"

body:
"Derek Ross" <derekross at fisheracre.freeserve.co.uk> writes:

> It would have been a surprise if everything had gone completely without a
> hitch.  There's nothing like production use for stressing a new app to
> breaking point.

Or, indeed, beyond.  Which is why you don't (or at least *shouldn't*) roll out
new code into production use without stress testing it.

I appreciate that there is an old joke that goes:
        "Fast, cheap, correct - Pick any two"
but this is taking the piss.
IM-not-so-HO, at the moment, the 'pedia  is quite useless.
(I've been searching for the UN convention on human rights for 10 minutes.
 I know its there, I added it in myself.
 Last weeks wiki would've found it in 5 seconds
 Brittanica.com just found it in 5 seconds).

Can we not have the old one back until the code/hardware can at least perform
in an acceptable manner?

PS: The search has returned now.  It says this
-----------------------------------------------------------------------------
Wikipedia articles
 Found 76 occurences of un convention on human rights. For each article, you
 can see its first paragraph and the first paragraph that contains ''un
 convention on human rights''
-----------------------------------------------------------------------------

The remainder of the page is blank.

PPS:  There is also an old saying that starts:
        "If it ain't broke..."
--
Gareth Owen


subject: [Wikipedia-l] Apology

body:
> Or, indeed, beyond.  Which is why you don't (or at least
> *shouldn't*) roll out
> new code into production use without stress testing it.

It was out for month on the sourceforge server, and for a few weeks on the
bomis server (as test.wikipedia.com).

> I appreciate that there is an old joke that goes:
>         "Fast, cheap, correct - Pick any two"
> but this is taking the piss.

Well, this was quite helpful.

> IM-not-so-HO, at the moment, the 'pedia  is quite useless.
> (I've been searching for the UN convention on human rights for 10 minutes.
>  I know its there, I added it in myself.
>  Last weeks wiki would've found it in 5 seconds
>  Brittanica.com just found it in 5 seconds).

The code itself performs quite well. On my own machine, it is faster than
the same function on the UseModWiki via DSL.
The performance problems come from some unidentified bug in the
apache-PHP-MySQL triangle. Currently, I'd bet on a buggy apache server
(there are some bad versions out there).
You probably noticed that sometimes, the software is quite fast and usable,
while two minutes later, it becomes awfully slow. That's the problem. It
should be solved within a few days max.

> PS: The search has returned now.  It says this
> ------------------------------------------------------------------
> -----------
> Wikipedia articles
>  Found 76 occurences of un convention on human rights. For each
> article, you
>  can see its first paragraph and the first paragraph that contains ''un
>  convention on human rights''
> ------------------------------------------------------------------
> -----------

Strange. Never did this to me. Actually, I ran your search right now. It
showed me the results (which were not very useful, but all contained the
query words). Took about 20 secs. Takes about 3 secs on my local machine.

When the software repository goes online (soon, hoepfully), be my (or
Jimbos) guest to "fix" the code...

Magnus


subject: [Wikipedia-l] tarball

body:
On ven, 2002-01-25 at 16:22, Jimmy Wales wrote:
> I think /pages/ is the latest and greatest.  The 'keep' files are, uh, I'm not
> sure what exactly.
>
> I guess everything is changing pronto, though!  I'll make sure your tarball is
> downloadable, but since we've changed software the old tarball will be increasingly
> irrelevant.
>
> We'll have to put together a new tarball of the mysql database.

The tarballs are still broken. http://www.wikpedia.com/tarballs/ gives a
403 Forbidden error; if you know the filenames you can still get a
particular tarball, but they don't seem to be getting updated. The
Esperanto wikipedia has added a lot of content since January 9; it would
be nice to be able to get a current tarball for backup and testing the
conversion to the new software.

-- brion vibber (brion @ pobox.com)


from_name: Michel Clasquin

subject: [Wikipedia-l] wikipedia text format

body:
On Monday 28 January 2002 19:56, Jimmy Wales wrote:

> Well, I think CamelCase is consistent with making content creation as
> easy as possible.  It's "transparent" as it looks the same in editing
> and in the output. It looks _silly_ in the output, which is why we are
> no longer using it at Wikipedia, but it certainly makes it easy for
> newcomers to get started.

Until you start writing about Scotland. You know, McTavish, MacDonald,
FitzGerald ... <g>

Good riddance, I say

--
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

All in all, you're just another brick in the wall- Pink Floyd


in_reply_to: <003501c1a886$6e7f11f0$ed00000a@typhoon>; from uriyan_subscribe@yahoo.com on Tue, Jan 29, 2002 at 07:33:02AM +0200

body:
As a first pass, I think this is a good solution.  Certainly, we should work to
solve your problem, which is a valid problem.

Uri Yanover wrote:
> I could think of several solutions to this problem:
> * Remove the [[Middle Earth/]] part (e.g. [[Elrond]] instead
>     of [[Middle Earth/Elrond]]. But this would not only
>     add fictional content to the generally real-world
>     encyclopedia but also confuse the readers (think about
>     [[USS Enterprise]]!)

Well, is the content _fictional_?  Or it is real-world content about a
_fictional universe_?  There's a subtle difference.  If the content was
fictional, it wouldn't belong in Wikipedia in the first place.  But if it
is highly detailed encyclopedic information about a fictional universe, then
it does belong.  I think it does belong.

> * Creating a new namespace (e.g. [[Middle Earth:Elrond]]).
>     But that would not automatically solve the linking problem,
>     and would generally contradict the way namespaces are
>     used now (the division being functional and not
>     content-oriented).

Right!  I'd be very much opposed to this.  The namespace divisions should
be functional, not content-oriented, unless we have an EXTREMELY compelling
reason.

The primary reaso for the namespace division was to avoid collision
between user nicknames and real articles.

> * Creating a new Middle Earth wiki. Although it would solve
>     most of the problems above, that would require too much
>     effort and make linking with the "main" Wikipedia more difficult.

I think a Middle Earth wiki would be neat, but I think this wouldn't
really solve the real problem here.  Because the same problem will
crop up in many other areas, I think.

I also think that a Middle Earth wiki could and probably should be
fairly different from Wikipedia content about Middle Earth.  For example,
a Middle Earth wiki would probably want to make room for fan fiction.

I'd be happy to host such a

> The solution which I would personally prefer is to add another
> addressing mode to the Wiki links.For example, we could add
> a #base directive after which all links except escaped ones
> would receive a certain prefix. For example:
>
> #base [[Middle Earth/]]
> [[!JRR Tolkien]] wrote that [[Elrond]] was the lord of Rivendell.
>
> The link with the prefixing "!" would not be affected. However
> after the #base directive, [[Elrond]] will automatically become
> [[Middle Earth/Elrond]].
>
> What do you think about it? Could this be implemented or there's
> another (easier) solution?

I think that after we brainstorm, there may be some modifications to your
proposal, but certainly something in this neighborhood might make sense.

--Jimbo


subject: [Wikipedia-l] History of pages, author issues.

body:
I'm going to have to insist that people stop making up accusations.

David Jones wrote:
> Sorry to go on about 2) so much, but it strikes me that the current
> attitude is a little immature.  The current attitude as I see it
> is one of "changing software is simple; maintaining a database is
> not our concern; user requirements are only superficially important".

This is all completely false, and is in fact the exact opposite of my
attitude and the attitude of everyone doing the coding.

Please, try to be helpful -- and that means *not* just making stuff up
out of thin air every time you have a problem with something.

--Jimbo


in_reply_to: <ILENJBCFHGHELEBFPPBGMEAHCFAA.Magnus.Manske@epost.de>; from Magnus.Manske@epost.de on Tue, Jan 29, 2002 at 06:44:22PM +0100

body:
Magnus Manske wrote:
> * As Wikipedia articles have no author, there's no authorship.

Well, there was a good bit of useful data there.  There is authorship in some
sense, and we do like to keep the history.

> * AFAIK, the UseModWiki only stored the changes of the last two weeks (or
> something like that).

It was previously two weeks, but I extended it, I forget how long, but our
intention is to keep the history more or less permanently, subject to disk
space constraints.  (But disk space is cheap.)

> * AFAIK, there will be "old.wikipedia.com", with a patched UseModWiki that
> doesn't allow to edit/save articles, only view them, with the contents from
> before the switch.

That's right.  But we should still see about getting the old history into the new
database if it isn't impossible.

> * The reason why I didn't convert the article history as well as the
> "current" versions is simply that I didn't figure out how to read the
> UseModWiki history format. I asked several times, even on the 'pedia, for
> help, but...

*nod*  I don't know the answer to this.  I've tried it myself and did not succeed.

Maybe Clifford Adams could help us?


from_name: wikipedia at epoptic.org

subject: [Wikipedia-l] Unable to edit an article

body:
What's up with Natural Family Planning
<http://www.wikipedia.com/wiki/wiki.phtml?title=Natural_family_planning>
?  I'm trying to edit it (capitalizing "Catholic Church," if you're
curious), but when I save, I get the old version again.  I've tried
several times, and each time, Recent Changes shows a new entry: "(diff)
Natural family planning 09:54 (6 changes) ... conversion script M
[Automated conversion]"

Has the conversion script decided to adopt this article as its very own?
Or is it just the wrong time of month to edit this article?

--
 the Epopt


from_name: David Jones

body:
Meta question: is there a place in the wikipedia for these issues?
(Yes,
http://www.wikipedia.com/wiki.phtml?title=wikipedia:PHP+script+bug+reports
ugh, what a horrible URL. )

Meta meta question: is a wiki appropriate for defect tracking?
(not answered)

The history of pages has been amputated when changing to the new
software, in other words, changes made before the new PHP software are
not accessible.  I see two problems with this:

1) Lost authorship.

2) Lost changes.

1) is the problem that the revision history used to contain the author
information for the documents.  I understand that it is a requirement of
the Gnu FDL that the author information be retained so that it can be
reproduced as needed under the terms of the license.

2) is more obvious, but perhaps less problematic.  In many cases you may
say "so what", but the fact is that there may have been useful content
in older revisions (I have browsed the older revisions in order to
understand the creation process of a document or gain insight into some
debate).  This content has now been thrown away.  What is the policy on
keeping older versions?  Is it "keep all of them" or "only keep
revisions when it is convenient, in particular if changing the software
destroys all older revisions then that's fine"?  Don't forget that the
software will change again and again over the lifetime of the wikipedia.
I would say it behoves wikipedia to maintain a storage format that is
largely independent of the software (even if that storage format is not
the one used by the software, it could be an export format for example).

Sorry to go on about 2) so much, but it strikes me that the current
attitude is a little immature.  The current attitude as I see it
is one of "changing software is simple; maintaining a database is
not our concern; user requirements are only superficially important".

I think 1) (the authorship problem) needs addressing.  What is intended?

Cheers,
 drj


subject: [Wikipedia-l] Apology

in_reply_to: Jimmy Wales's message of "Mon, 28 Jan 2002 10:47:29 -0800"

body:
Jimmy Wales <jwales at bomis.com> writes:

> > PPS:  There is also an old saying that starts:
> >         "If it ain't broke..."
>
> There's also an old saying:  "Beggars can't be choosers."

Beggars?   *boggle*
Well, I guess I've been leeching off you for a year now.
I'm sorry to have used so many of your valuable resources.
--
Gareth Owen


subject: [Wikipedia-l] some other remarks

body:
Jan Hidders wrote:
> This also brings me to another issue. Shouldn't there be a definitive
> thourgh formal description of the syntax of the mark-up language (in for
> example BNF) and its semantics?

Yes, there "should" be!  If there's any support I can lend to a working group
that would seek to do such a thing, just let me know.

> Has this not been done because
> nobody has yet taken the trouble (or the responsibility), or is there
> another reason?

No, that's the reason.  :-)

> By the way, if I sound critical, I didn't mean to. I think the step to a
> database-based Wikipedia is a step of major importance and I am amazed at
> the amount of time and effort that you guys have spent on this. Thank you,
> thank you, thank you.

You're welcome, and the kind comments are most appreciated.

I've been grumpy with a few people over the past few days, because I
think some people prefer only to complain rather than to _do_.  One
person went so far as to suggest that my praise of Magnus was somehow
meant to be _ironic_!  :-) It wasn't.  Magnus lives on the other side
of the world, and I get bugfix patches from him at midnight or later,
his time.  That's astounding.

I like it when people contribute ideas, too!  So it is not good of me to
be grumpy when people suggest ideas.  But I *love* it when people get involved
with the code, for example Brion Vibber.

--Jimbo


from_name: Julie Kemp

subject: [Wikipedia-l] My general reaction to the new site and a couple of requests

body:
Hi all -- I generally like the new site, but find it
REALLY confusing. the way it's set up is very
appealing, and I love the new special pages.  The
'diff' sections are much easier to figure out, and I
love the red orphan links.  But -- Am I blind, or is
there somewhere on the new site where I can see a list
of "here are the major changes:  what used to be this,
is now replaced by that" kind of thing.  For example,
I remember vaguely reading about (vaguely placed where
it is for a reason) losing sub-pages, but can only
infer that where there were once pages we now have
name spaces.  I think.  And I'm fairly computer
literate.

Also, is there any way to add a line or two to the
script that pulls the 'most Wanted' list and have it
exclude years -- or at least 2 digit years?  Lots of
times they just don't need to link back and forth...

I still think the site is a huge improvement... just
wish that there was more user-friendly documentation.
I used to write that kind of thing, BTW (in HTML,
even).  Could I be of help?    [[JHK]]

__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com


body:
OK, let's try this without a flame war ;)

> The history of pages has been amputated when changing to the new
> software, in other words, changes made before the new PHP software are
> not accessible.  I see two problems with this:
>
> 1) Lost authorship.
> 2) Lost changes.

* As Wikipedia articles have no author, there's no authorship.
* AFAIK, the UseModWiki only stored the changes of the last two weeks (or
something like that).
* AFAIK, there will be "old.wikipedia.com", with a patched UseModWiki that
doesn't allow to edit/save articles, only view them, with the contents from
before the switch.
* The reason why I didn't convert the article history as well as the
"current" versions is simply that I didn't figure out how to read the
UseModWiki history format. I asked several times, even on the 'pedia, for
help, but...

I hope that claryfies things a little.

Magnus


body:
We had a rather lengthy discussion about the subpages, which ended in Larry
deciding to get rid of them. I don't suppose he would be happy with subpages
returning from the grave, even if they are marked with "#" instead of "/".
And if I'd implement such a thing, he would be quite annoyed with me (I
picture the horseman from "Sleepy Hollow";)

I guess we'll have to get used to the copy&paste keyboard shortcuts...

Magnus

> -----Original Message-----
> From: wikipedia-l-admin at nupedia.com
> [mailto:wikipedia-l-admin at nupedia.com]On Behalf Of Jimmy Wales
> Sent: Tuesday, January 29, 2002 5:10 PM
> To: wikipedia-l at nupedia.com
> Subject: Re: [Wikipedia-l] No-subpage policy makes editing [[Middle
> Earth]] difficult
>
>
> As a first pass, I think this is a good solution.  Certainly, we
> should work to
> solve your problem, which is a valid problem.
>
> Uri Yanover wrote:
> > I could think of several solutions to this problem:
> > * Remove the [[Middle Earth/]] part (e.g. [[Elrond]] instead
> >     of [[Middle Earth/Elrond]]. But this would not only
> >     add fictional content to the generally real-world
> >     encyclopedia but also confuse the readers (think about
> >     [[USS Enterprise]]!)
>
> Well, is the content _fictional_?  Or it is real-world content about a
> _fictional universe_?  There's a subtle difference.  If the content was
> fictional, it wouldn't belong in Wikipedia in the first place.  But if it
> is highly detailed encyclopedic information about a fictional
> universe, then
> it does belong.  I think it does belong.
>
> > * Creating a new namespace (e.g. [[Middle Earth:Elrond]]).
> >     But that would not automatically solve the linking problem,
> >     and would generally contradict the way namespaces are
> >     used now (the division being functional and not
> >     content-oriented).
>
> Right!  I'd be very much opposed to this.  The namespace divisions should
> be functional, not content-oriented, unless we have an EXTREMELY
> compelling
> reason.
>
> The primary reaso for the namespace division was to avoid collision
> between user nicknames and real articles.
>
> > * Creating a new Middle Earth wiki. Although it would solve
> >     most of the problems above, that would require too much
> >     effort and make linking with the "main" Wikipedia more difficult.
>
> I think a Middle Earth wiki would be neat, but I think this wouldn't
> really solve the real problem here.  Because the same problem will
> crop up in many other areas, I think.
>
> I also think that a Middle Earth wiki could and probably should be
> fairly different from Wikipedia content about Middle Earth.  For example,
> a Middle Earth wiki would probably want to make room for fan fiction.
>
> I'd be happy to host such a
>
> > The solution which I would personally prefer is to add another
> > addressing mode to the Wiki links.For example, we could add
> > a #base directive after which all links except escaped ones
> > would receive a certain prefix. For example:
> >
> > #base [[Middle Earth/]]
> > [[!JRR Tolkien]] wrote that [[Elrond]] was the lord of Rivendell.
> >
> > The link with the prefixing "!" would not be affected. However
> > after the #base directive, [[Elrond]] will automatically become
> > [[Middle Earth/Elrond]].
> >
> > What do you think about it? Could this be implemented or there's
> > another (easier) solution?
>
> I think that after we brainstorm, there may be some modifications to your
> proposal, but certainly something in this neighborhood might make sense.
>
> --Jimbo
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


from_name: Jan Hidders

body:
First let me apologize if this is not appropriate because I've only recently
subscribed again to this list and haven't thoroughly checked if  this was
discussed before.

I thought that the intention of namespaces was to disambiguate homonyms such
as Nirvana (Music and Mythology), function (Mathematics and Programming
Languages), ring (Mathematics and Common use) et cetera. But now it seems
that they are only used to distinguish between pages with different types of
functions.  I personally was planning to write some articles on database
normalization and there we have also a lot of terms (relation, key,
dependency, normal form) that have a very specific meaning there. If I now
see the problems that Uri Yanover mentions, then it seems to me that these
problems are very similar to those in Mathematics and Computer science (and
other fantasy worlds, :-)) and could also be solved by a general
user-definable hierarchical name space implementation. Let me make a
suggestion:

1. With every page a name space of the same name is associated. So with the
page "Middle_earth" there would be a name space "Middle_earth:" and with the
the page "Database_theory" there would be a name space "Database_theory:".

2. A page name would consist of (an optional) namespace, e.g.,
"relational_model:", and the basic page name, e.g., "first_normal_form". The
full page name would in this case be "relational_model:first_normal_form" or
for example "Middle_earth:Elrond". Since a name space corresponds with a
page name, a name space itself can also be qualified with another name
space, so you might have
"Computer_science:Database_theory:Relational_model:First_normal_form". (I
don't think the hierarchy will be that deep in practice, but you get the
point.)

3. The looking up/linking of page names that are not qualified with a
namespace is done by walking up to the root of the tree of name spaces. So a
link on the page for "first_normal_form" is first looked for in the name
space "First_normal_form:", then consecutively in "Relational_model:",
"Database_theory:", "Computer_science:" and finally the global name space
":"". For Uri's example this would mean that the look-up of "Elrond" would
start in the name space "Middle_earth:" if it appeared on the page
"Middle_earth".

4. If a page name is qualified then the look-up starts at the given name
space. So "Computer_science:relation" is looked up first in the name space
"Computer_science" even if it appears on a page with name space
"Database_theory".

5. If a page name belongs to a certain name space then it also belongs to
the name spaces higher up the name space hierarchy unless a conflict arises.

6. The looking up only happens when the page is submitted. After that the
unqalified page name is replaced with a fully qualified page name. That
prevents unneccesary processing and avoids problems with page names becoming
ambiguous because a new page with the same name is added in a sibling name
space.

7. If a page name is not found then a "creation link" is created and its
namespace is either the name space that was specified (if it exists) and if
no name space is specified then it is the local space name, i.e., the name
space of the page that the link is on. If the specified name space does not
exist already then an error is reported and no "creation link" is created.

8. Every page is presented with somewhere on the screen a link to the page
corresponding to its namespace.

That is about all. I know this looks very much like subpages on steroids
(Larry is probably foaming at the mouth right now :-)) and in some sense it
is, but I really think we need user-definable hierarchies of name spaces and
I don't see why we cannot trust the self-organization of Wikipedians on
this. I also realize that this is not easy to implement, to put it mildly,
but if you think it is a good idea then I would probably feel morally
obliged to help build it. I have a little PHP experience and have once
written patches for PhpWiki.

Btw. note how elegantly Talk-pages fit into this scheme; you just add a link
[[Talk]]. No further special arrangements necessary. On the down-side the
user now has the indicate explicitly that a page has to be put in the
highest name space by writing  for example [[:Wikipedia_talk]] where ":"
represents the root name space.

Kind regards,

-- Jan Hidders


subject: [Wikipedia-l] some other remarks

body:
Hello again,

I also wanted to make some other small remarks but thought it best to put
them in a separate mail.

About the lay out of the pages: I usually read Wikipedia with a small font
and in that case the header becomes a lot of white space because it stays
the same height because of the Wikipedia logo (which I like very much,
btw.). If the logo would be reduced to half the size then the header would
consume far less space.

About the mark-up language: I've seen some request for more mark-up features
and even full HTML and XML. Since I'm very fond of the WikiWiki-concept this
sends shivers down my spine. I would actually vote for the opposite, i.e.,
to abandon all HTML mark-up and even those that only looks like HTML. For a
good example look at what the mark-up languages are on MoinMoin or PhpWiki.
An alternative mark-up for tables, for example, would have prevented
problems such as there were with incorrect HTML on the page for Quaternions.

This also brings me to another issue. Shouldn't there be a definitive
thourgh formal description of the syntax of the mark-up language (in for
example BNF) and its semantics? They are trying to do something like that at
PhpWiki at the moment.
(http://phpwiki.sourceforge.net/phpwiki/FormalWikiGrammar) If such a thing
had existed, would that not have helped Magnus? I also feel it is a point of
principle because it would make the content of Wikipedia more open and
usable for other people who would also like to write software that operates
on its contents, or for us if we want to convert old content with old
mark-up to a newer mark-up. I'm willing to invest some time in such a
description if some people agree with me.

On reporting bugs: I'm confused by the three pages for reporting bugs. I
understand the separate page for the "minor" issues but why are the other
two (the usual Wikipedia bugs pags and the PHP script bug reports page) not
merged? The bugs for the usemod script should of course be checked if they
still apply, and if not then filtered out. Has this not been done because
nobody has yet taken the trouble (or the responsibility), or is there
another reason?

By the way, if I sound critical, I didn't mean to. I think the step to a
database-based Wikipedia is a step of major importance and I am amazed at
the amount of time and effort that you guys have spent on this. Thank you,
thank you, thank you.

Kind regards,

-- Jan Hidders


body:
Sorry, two remarks I forgot to make.

From: "Jan Hidders" <hidders at uia.ua.ac.be>
>
> That is about all. I know this looks very much like subpages on steroids
> (Larry is probably foaming at the mouth right now :-)) and in some sense
it
> is, but I really think we need user-definable hierarchies of name spaces
and
> I don't see why we cannot trust the self-organization of Wikipedians on
> this.

Note that an important difference with sub-pages is that a name-space
inherits all the page names from it sub-name-spaces that are unambiguous.

> Btw. note how elegantly Talk-pages fit into this scheme; you just add a
link
> [[Talk]]. No further special arrangements necessary. On the down-side the
> user now has the indicate explicitly that a page has to be put in the
> highest name space by writing  for example [[:Wikipedia_talk]] where ":"
> represents the root name space.

For backwards compatability you can also reverse this of course, i.e.,
[[:blah]] becomes local and [[blah]] global. Hmmm, sounds familiar. ... :-)

-- Jan Hidders


body:
> We had a rather lengthy discussion about the subpages, which ended in
Larry
> deciding to get rid of them.
Note however, that Larry himself had stated that self-contained universes
are
the only subject where subpaging _does_ make sense to him. See
http://www.wikipedia.com/wiki.phtml?title=Faramir

> I don't suppose he would be happy with subpages eturning from the grave,
> even if they are marked with "#" instead of "/".
I don't propose # instead of "/", I'm proposing a limited add-prefix
function
(which could repair some of the disadvantages of the lack of subpages).

> And if I'd implement such a thing, he would be quite annoyed with me (I
> picture the horseman from "Sleepy Hollow";)
Well, don't lose your head over the subject :-)

> I guess we'll have to get used to the copy&paste keyboard shortcuts...
That isn't the solution I'd like to see. Personally I'd favor some sort of
an additional addressing mode. Anyway, Wikipedia as a means of
communications should somehow express the concept that Middle
Earth is an enclosed universe of its own (and make editing easier as
an added value).

Sincerely yours,
                    Uri Yanover


subject:
[Wikipedia-l] No-subpage policy makes editing [[Middle
    Earth]] difficult

body:
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020130/89345806/attachment.diff


subject: [Wikipedia-l] some other remarks

body:
From: "Jimmy Wales" <jwales at bomis.com>
> Jan Hidders wrote:
> > This also brings me to another issue. Shouldn't there be a definitive
> > thourgh formal description of the syntax of the mark-up language (in for
> > example BNF) and its semantics?
>
> Yes, there "should" be!  If there's any support I can lend to a working
group
> that would seek to do such a thing, just let me know.

Ok. I'll try to come up with a first proposal by next weekend.

-- Jan Hidders


from_name: Jimmy Wales

subject: [Wikipedia-l] Re: keep file stored format.

body:
David Jones wrote:
> Does the following help?  Sorry it is so scrappy, but I have other
> things to do and beggars can't be choosers.

:-)

--Jimbo


subject: keep file stored format.

body:
In message <20020129094250.M23243 at joey.bomis.com>, Jimmy Wales writes:
> Magnus Manske wrote:
> > * The reason why I didn't convert the article history as well as the
> > "current" versions is simply that I didn't figure out how to read the
> > UseModWiki history format. I asked several times, even on the 'pedia, for
> > help, but...
>
> *nod*  I don't know the answer to this.  I've tried it myself and did not suc
>>ceed.
>
> Maybe Clifford Adams could help us?

Maybe.

Does the following help?  Sorry it is so scrappy, but I have other
things to do and beggars can't be choosers.

2002-01-30
drj at pobox.com

The UseModWiki stored format

Introduction

This document is my attempt to describe the store file formats used
by UseModWiki.  UseModWiki is a cgi perl script that implements a
wiki.

Directory Structure

wiki/usemod/zwisdb/...
  diff_log
  keep
  page
  rclog
  temp
  user

keep stores the older versions (possibly all kept versions).

keep/A/...
    /B/...

A file in a subdirectory of keep is called Spong.kp where Spong is the FreeToNormal conversion of the page title.  The FreeToNormal conversion works by converting spaces to "_", upper casing the first letter, eliding runs of "___" into a single "_" and removing "_" from around "/" (when subpages are used).

File Format

Formal syntax for keep files (.kp ending) (supposedly in RFC2234 ABNF syntax):

keep-file =  *revision

revision  =  FS1 kv2-list

kv2-list  =  kv2		; also called Section in the code.
          =/ kv2-list FS2 kv2

kv2       =  key FS2 value

value     =  simple-value
          =/ kv3-list

kv3-list  =  kv3
          =/ kv3-list FS3 kv3

kv3       =  key FS3 simple-value

simple-value ; any sequence of characters not including "\xb3"

The strings FS1, FS2, FS3 are: (in C syntax, not RFC2234 syntax)
  FS1 = "\xb31" (the character with decimal code 179
      (hex b3) followed by ASCII 1)
  FS2 = "\xb32"
  FS3 = "\xb33"

The following kv2-list keys appear to be used:
username - the wiki username of the user to create this revision.
name 	- used by OpenKeptRevisions to select only certain revisions.  However,
	only "text_default" is used in the code, and I haven't seen any others
	in the file.
version - version number of the data format.
ts      - time of edit.  Seconds since UNIX epoch.
ip	- ip address
data    - mostly the text and some (more) meta information
tscreate- time of creation (ie revision 1).  Seconds since UNIX epoch.
keepts  - obviously something to do with keeping and expiring but I don't
 	know exactly what yet.
id	- user id of user making this revision.
host	- hostname of machine that user is connecting from.
revision - the user visible wiki revision of the document.

Only the data key has a kv3-list value (aka Text hash in the code), the
other keys have simple values.
Data sub-keys:
newauthor 	- 0 or 1, I _think_ this is 1 when the user making this revision
	is different from the one that made the previous revision.
minor		- 0 or 1
text		- The complete text for this revision
summary		- the summary typed in by the user.

Numbers appear as printed decimals, strings appear as themselves.

The following awk script prints the version numbers held in a file:
awk -F $(printf '\263.') '{for(i=1;i<NF;++i)if($i=="revision")print $(i+1)}' FILE
WARNING: This will be slow if you use it multiple times (mostly because of evaluating printf '\263.' every invocation).
Note: octal 263 == decimal 179 == hexadecimal b3

My random notes about the code and other things:

in "sub OpenKeptList"
@KeptList = split(/$FS1/, $data, -1)
so there is a list of things separated by FS1.
OpenKeptRevisions iterates over each FS1 sep thing
separating it with FS2:
  %tempSection = split(/$FS2/, $_, -1)
(into a hash table note)
ie, a series of key value pairs, each separated from the other by FS2


in_reply_to:
Your message of "Tue, 29 Jan 2002 18:44:22 +0100."
             <ILENJBCFHGHELEBFPPBGMEAHCFAA.Magnus.Manske@epost.de>

body:
In message <ILENJBCFHGHELEBFPPBGMEAHCFAA.Magnus.Manske at epost.de>, "Magnus Mansk
e" writes:
> OK, let's try this without a flame war ;)
>
> > The history of pages has been amputated when changing to the new
> > software, in other words, changes made before the new PHP software are
> > not accessible.  I see two problems with this:
> >
> > 1) Lost authorship.
> > 2) Lost changes.
>
> * As Wikipedia articles have no author, there's no authorship.

There is an author (as I think Jimbo has pointed out); when I write text
in an article I am the author of that text and the owner of the
copyright.  When I hit submit I, as the copyright holder, license it to
be used under the terms of the Gnu FDL.

The fact that the community doesn't really recognise authors doesn't
affect the law.

> * The reason why I didn't convert the article history as well as the
> "current" versions is simply that I didn't figure out how to read the
> UseModWiki history format. I asked several times, even on the 'pedia, for
> help, but...

Hmm.  I have submitted what I have learnt from an hour or two of
eyeballing the code in another message.  You should probably badger
me if I can me of any more help.

Cheers,
 drj


subject: [Wikipedia-l] Middle Earth controversy

body:
Chuck Smith wrote:
> IMHO, I don't see why we can't have an article called
> Elrond or Bilbo Baggins, and have in the first line,
> "Bilbo Baggins was a character in [[Middle Earth]]..."
> and I think it's fine to have a fictional character as
> an encyclopedia entry.  After all, Wikipedia is not
> paper... I think it will turn out much differently
> than traditional encyclopedias and we'll have to
> accept some non-traditional ideas to do it.

I agree totally with this.

There's still a problem of namespace collisions, though.
A good example is [[USS Enterprise]], which is the name of many
real and fictional vessels.


from_name: Tim Chambers

subject: [Wikipedia-l] yet another modest proposal to address subpage-like behavior

body:
Two points before I make my proposal:

1. I prefer the Frodo (Middle Earth) naming convention. It's more
encyclopedia-like.

2. I stand against subpages. Having said that, I stand in support of a
software solution that will translate links so people don't have to type so
much.

So here's yet another proposal. (Although I haven't done anything yet, I am
a registered SourceForce developer. So I'm willing to code up what I
propose.)

It's a blend of ideas already presented by Uri, Magnus, and Mark.

Mine is different because I think the system should merely translate what an
author has typed into what the author is presumed to have meant. This
completely simplifies the wiki syntax to what we have now, but it makes it
easier to create content. An acceptable balance, IMHO. Magnus has set a
precedent for this with the ~~~ signature feature (however, it would be much
more useful if it would expand in the preview screen). So I'm assuming that
the section of the system that translates ~~~ would do these new
translations.

So the elements of the changes are:

1. If the title has a parenthetical phrase, then that phrase is presumed to
be the parent article. So on the Frodo (Middle Earth) page, a link typed
[[/elves]] will be expanded to [[elves (Middle Earth)|elves]] when the page
is saved.

2. If the Title doesn't have a parenthetical phrase, e.g. Middle Earth, then
links of the form [[/elves]] are translated to [[elves (Middle
Earth)|elves]] when the article is saved.

3. To make it easier to use random parethesized article names, the system
could translate any link of the form

[[/name (parenthetical)]]

to

[[name (parenthetical)|name]]

It doesn't save much typing, it has a nice symmetry to the previous two
translation patterns.

4. If we want to get fancy, then we can borrow from the way Perl programmers
change namespaces. I'm simplifying, but basically, in Perl, typing

package "FantasyFiction";

will cause subsequent symbol lookups to happen in the FantasyFiction::
namespace.

So we could use Uri's idea of the #base pragma to cause something like this:

#base [[Fantasy Fiction]]

[[/elves]]

to be translated into this:

See also: [[Fantasy Fiction]].

[[elves (Fantasy Fiction)|elves]]

The system could remove the #base line completely instead of translating it,
but I think it's useful to reflect by default that there's a relationship
between the content of a give page and some other related page. After all,
if the author doesn't like that behavior, he or she can simply type the
links manually instead of using #base. Or the author can edit twice: the
first is a major edit, and the second is a minor edit to remove the See
also: line.


from_name: Mark Christensen

subject:
[Wikipedia-l] An alternative idea to resolve the [[Middle Ear
	th]] issue

body:
I think getting rid of the / is an important goal for Larry and others.  So
I'd change you system to use the new approved style:

Elves (Middle Earth)

The other question is what happens if we try to use this for something where
there's likely to be a "real" article on the wikipedia which we might want
to link to as well?  Certainly there were "elves" in folklore before Middle
Earth.  My suggestion is that we could use some escape symbol to tell the
system not to use the alias...

That said, this seems like the simplest suggestion so far for context
sensitive linking.  And conceivably the most flexible, because we could
configure this to use nested alias namespaces.  This means that we could
put:

#alias [[Middle Earth]]
#alias [[Fantasy Novel]]
#alias [[Fantasy Movie]]
#alias [[20th Century Novel]]

at the top of the page on The Fellowship of the Rings. And links on that
page would look for a link to [[Elves]] first in the Middle Earth alias
namespace (which might contain an alias for [[Elves of Middle Earth]], and
then to the Fantasy Novel namespace which might also contain an alias for a
general article on the history of the use of elfish characters in fantasy
novels.  And so on.  At any point using the escape character before a link
will skip out of all namespaces, and just point directly to the [[elves]]
article.

Though nested namespaces is helpful in the case of self contained worlds, I
expect that it would be almost necessary on pages like [[mitochondrial DNA]]
where different sequences of DNA are used to mark off an amino acid when
compared to those used in non-mitochondrial DNA.  In other words one gene
triplet (for example[[CTA]]) could mean something entirely different in the
context of Mitochondrial DNA than it would outside that context.  (Though I
don't remember at all which triplets are actually different, I'm sure
someone with a biology background would know this.) My point is that there
are cases like this where nature is uses context sensitive namespaces, and
it would be very helpful to be able to do the same in the wikipedia
software.

And of course things like the [[poker]] pages would benefit by something
like this as [[stud]] means something entirely different in poker,
construction, and animal breeding contexts.

Any Object Oriented programmer knows that nested namespaces are a very
useful tool for keeping large projects with many programmers working
smoothly.  As long as data is properly encapsulated, there's no need to know
what variable names are being used elsewhere.   And I think the same thing
will be true in the wikipedia.   Someone writing an article on construction
shouldn't have to know that there's and article named [[stud (poker)]],
another article named [[stud (construction)]] as well as one named [[stud
(horses)]], and yet a fourth named [[stud (breeding]], they should just be
able to write [[stud]] and have their article point to the correct page.

Just a few thoughts...

Yours
Mark

-----Original Message-----
From: Uri Yanover [mailto:uriyan_subscribe at yahoo.com]
Sent: Wednesday, January 30, 2002 2:34 PM
To: wikipedia-l at nupedia.com
Subject: [Wikipedia-l] An alternative idea to resolve the [[Middle Earth]]
issue

Hi everyone again,

Having thought some more about how it is possible to make editing
[[Middle Earth]] easier once again, I've invented another solution
to the problem: aliases.

Here's how it should work: we create a new Alias namespace.
Inside it we'd have entries like [[Alias:Middle Earth]]. This page
would look like the following:
----------------
Bilbo                        Middle Earth/Bilbo
Faramir                    Middle Earth/Faramir
Frodo                        Middle Earth/Frodo
Gandalf                    Middle Earth/Gandalf
----------------
In general, the idea would be to match the ad-hoc "short" versions
of the page titles to the "long" version. Each page that that would
want to use the alias, will have to include a directive, explicitly
telling it to, e.g. #alias [[Middle Earth]].

This way we could both keep the longer (and the more informative)
names like [[Middle Earth/Elrond]] and still make short linking
(like [[Elrond]]) possible from the pages that require this.

What do you think about it?

            Uri Yanover

[Wikipedia-l]
To manage your subscription to this list, please go here:
http://www.nupedia.com/mailman/listinfo/wikipedia-l


body:
Subpages or not, it would be useful to be able have the slash (/) as
part of the article name, e.g. "TCP/IP", "IBM System/360", and "OS/2",
where the slash is part of the proper noun.

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


subject: [Wikipedia-l] Bug Report : Search Engine

body:
Using Netscapes 3 and 4, with junkbuster as a proxy, the search engine
studiously refuses to tell me about the things its found.
--
Gareth Owen
"Wikipedia does rock.  By the count on the "brilliant prose" page, there
 are 14 not-bad articles so far" -- Larry Sanger (12 Jan 2001)


from_name: Larry Sanger

subject: [Wikipedia-l] I'm back, more or less!

body:
Hi all,

I'm back, sort of--at least, I have a place to live and a computer
connection, but things are still kind of crazy, so I won't be able to work
full time for several days still.  I notice this interesting controversy
about the use of subpages for Middle Earth.  I'm sure you can guess what
my view about it will be.  :-)

Larry


body:
On Wednesday 30 January 2002 02:25, Julie Kemp wrote:

> Also, is there any way to add a line or two to the
> script that pulls the 'most Wanted' list and have it
> exclude years -- or at least 2 digit years?  Lots of
> times they just don't need to link back and forth...

Those years' pages actually exist - that bug has already been reported on
at least 2 of the 3 bug report pages.

--
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

All in all, you're just another brick in the wall- Pink Floyd


subject: [Wikipedia-l] An alternative idea to resolve the [[Middle Earth]] issue

body:
Hi everyone again,

Having thought some more about how it is possible to make editing
[[Middle Earth]] easier once again, I've invented another solution
to the problem: aliases.

Here's how it should work: we create a new Alias namespace.
Inside it we'd have entries like [[Alias:Middle Earth]]. This page
would look like the following:
----------------
Bilbo                        Middle Earth/Bilbo
Faramir                    Middle Earth/Faramir
Frodo                        Middle Earth/Frodo
Gandalf                    Middle Earth/Gandalf
----------------
In general, the idea would be to match the ad-hoc "short" versions
of the page titles to the "long" version. Each page that that would
want to use the alias, will have to include a directive, explicitly
telling it to, e.g. #alias [[Middle Earth]].

This way we could both keep the longer (and the more informative)
names like [[Middle Earth/Elrond]] and still make short linking
(like [[Elrond]]) possible from the pages that require this.

What do you think about it?

            Uri Yanover


from_name: Magnus Manske

subject: [Wikipedia-l] Subpages or namespaces

body:
Despite all more-or-less-complicated suggestions regarding this topic, I'd
like to repeat an idea I mentioned once as a compromise on subpages. It was
rejected by Larry at that time, but it might be worth thinking about it
again in the light of the [[Middle Earth]] issue.

The idea: On saving an edit, all links that start with "[[/" (like
[[/Frodo]] on the [[Middle Earth]] page) would be extended by the "root"
topic (like [[Middle Earth/Frodo]]).

That would give us back just a little subspace functionality, but would keep
the system "clean" (no automatic backlinks, no weird stuff on "GNU/Linux"
etc.). It just saves some typing. Personally, I doubt that would encourage
massive wild-growth of subpages, but of course, I'll accept the decision of
the powers-that-be ;)

Magnus


body:
Subject: [Wikipedia-l] No-subpage policy makes editing [[Middle Earth]]
difficult

I apologize for accidentially sending this message twice

            Uri


body:
The alias namespace is a good idea, and I see the advantages.

However, a mechanism like that would have major consequences for some
functions, especially the new ones, like "Most Wanted", "Orphans" etc.
In the database, all articles carry a list of their outgoing links, which is
updated upon saving the article. Now, if I look at the [[Elves]] link in
[[Middle Earth]], I could either save the link [[Elves]], which would
require cross-referncing articles while scanning through the links, which
would render "Most Wanted" virtually unusable because of search times that
are measured in hours...
Or, I could save the link as [[Elves (Middle Earth)]], which would be plain
wrong in case anyone edits the alias namespace article.

You see, this can get rather ugly. If you (or anyone!) have an idea of how
to do this, or how to fix other bugs that come up along the way, there's a
standing invitation to participate in development.

Any help would be appreciated, as my work schedule is rather tight at the
moment.

Magnus

> -----Original Message-----
> From: wikipedia-l-admin at nupedia.com
> [mailto:wikipedia-l-admin at nupedia.com]On Behalf Of Mark Christensen
> Sent: Wednesday, January 30, 2002 10:41 PM
> To: 'wikipedia-l at nupedia.com'
> Subject: RE: [Wikipedia-l] An alternative idea to resolve the
> [[Middle Earth]] issue
>
>
> I think getting rid of the / is an important goal for Larry and
> others.  So
> I'd change you system to use the new approved style:
>
> Elves (Middle Earth)
>
> The other question is what happens if we try to use this for
> something where
> there's likely to be a "real" article on the wikipedia which we might want
> to link to as well?  Certainly there were "elves" in folklore
> before Middle
> Earth.  My suggestion is that we could use some escape symbol to tell the
> system not to use the alias...
>
> That said, this seems like the simplest suggestion so far for context
> sensitive linking.  And conceivably the most flexible, because we could
> configure this to use nested alias namespaces.  This means that we could
> put:
>
> #alias [[Middle Earth]]
> #alias [[Fantasy Novel]]
> #alias [[Fantasy Movie]]
> #alias [[20th Century Novel]]
>
> at the top of the page on The Fellowship of the Rings. And links on that
> page would look for a link to [[Elves]] first in the Middle Earth alias
> namespace (which might contain an alias for [[Elves of Middle Earth]], and
> then to the Fantasy Novel namespace which might also contain an
> alias for a
> general article on the history of the use of elfish characters in fantasy
> novels.  And so on.  At any point using the escape character before a link
> will skip out of all namespaces, and just point directly to the [[elves]]
> article.
>
> Though nested namespaces is helpful in the case of self contained
> worlds, I
> expect that it would be almost necessary on pages like
> [[mitochondrial DNA]]
> where different sequences of DNA are used to mark off an amino acid when
> compared to those used in non-mitochondrial DNA.  In other words one gene
> triplet (for example[[CTA]]) could mean something entirely
> different in the
> context of Mitochondrial DNA than it would outside that context.
> (Though I
> don't remember at all which triplets are actually different, I'm sure
> someone with a biology background would know this.) My point is that there
> are cases like this where nature is uses context sensitive namespaces, and
> it would be very helpful to be able to do the same in the wikipedia
> software.
>
> And of course things like the [[poker]] pages would benefit by something
> like this as [[stud]] means something entirely different in poker,
> construction, and animal breeding contexts.
>
> Any Object Oriented programmer knows that nested namespaces are a very
> useful tool for keeping large projects with many programmers working
> smoothly.  As long as data is properly encapsulated, there's no
> need to know
> what variable names are being used elsewhere.   And I think the same thing
> will be true in the wikipedia.   Someone writing an article on
> construction
> shouldn't have to know that there's and article named [[stud (poker)]],
> another article named [[stud (construction)]] as well as one named [[stud
> (horses)]], and yet a fourth named [[stud (breeding]], they should just be
> able to write [[stud]] and have their article point to the correct page.
>
> Just a few thoughts...
>
> Yours
> Mark
>
>
> -----Original Message-----
> From: Uri Yanover [mailto:uriyan_subscribe at yahoo.com]
> Sent: Wednesday, January 30, 2002 2:34 PM
> To: wikipedia-l at nupedia.com
> Subject: [Wikipedia-l] An alternative idea to resolve the [[Middle Earth]]
> issue
>
>
> Hi everyone again,
>
> Having thought some more about how it is possible to make editing
> [[Middle Earth]] easier once again, I've invented another solution
> to the problem: aliases.
>
> Here's how it should work: we create a new Alias namespace.
> Inside it we'd have entries like [[Alias:Middle Earth]]. This page
> would look like the following:
> ----------------
> Bilbo                        Middle Earth/Bilbo
> Faramir                    Middle Earth/Faramir
> Frodo                        Middle Earth/Frodo
> Gandalf                    Middle Earth/Gandalf
> ----------------
> In general, the idea would be to match the ad-hoc "short" versions
> of the page titles to the "long" version. Each page that that would
> want to use the alias, will have to include a directive, explicitly
> telling it to, e.g. #alias [[Middle Earth]].
>
> This way we could both keep the longer (and the more informative)
> names like [[Middle Earth/Elrond]] and still make short linking
> (like [[Elrond]]) possible from the pages that require this.
>
> What do you think about it?
>
>             Uri Yanover
>
> [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


from_name: Chuck Smith

subject: [Wikipedia-l] Middle Earth controversy

body:
IMHO, I don't see why we can't have an article called
Elrond or Bilbo Baggins, and have in the first line,
"Bilbo Baggins was a character in [[Middle Earth]]..."
and I think it's fine to have a fictional character as
an encyclopedia entry.  After all, Wikipedia is not
paper... I think it will turn out much differently
than traditional encyclopedias and we'll have to
accept some non-traditional ideas to do it.

Chuck Smith

=====
Venu al la senpaga, libera enciklopedio
esperanta reta! http://eo.wikipedia.com/
====
Junuloj!  Filadelfio, Usono 15an-17an de Februaro
http://unumondo.com/cgi-bin/wiki.pl?Filadelfia_JES

__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Ihre E-Mail noch individueller? - http://domains.yahoo.de


from_name: Kurt Jansson

subject: [Wikipedia-l] Middle Earth controversy

body:
Hi Chuck!

> IMHO, I don't see why we can't have an article called
> Elrond or Bilbo Baggins, and have in the first line,
> "Bilbo Baggins was a character in [[Middle Earth]]..."
> and I think it's fine to have a fictional character as
> an encyclopedia entry.  After all, Wikipedia is not
> paper... I think it will turn out much differently
> than traditional encyclopedias and we'll have to
> accept some non-traditional ideas to do it.

That's also my opinion about this theme. I think the only problem that
exist is when a word or a name descibes fictional and non-fictional
thing/persons. But that's the same problem that we have had before, for
example with Mars, which is a god, a planet and something to eat (I
don't know the English expression). When I write an article and want to
link to Mars I search if there is [[Mars (planet)]], or - if I'm lazy
(most of the time) - I link to [[Mars]]. There's a link on [[Mars]] to
[[Mars (planet)]] (in the German wikipedia at least), so I can't see the
problem here. People know from which page they are coming from and if
they are searching for a planet or if the are hungry.

(BTW, I like it when I stumble over those pages and get to know meanings
of a word I didn't know.)

Bye,
Kurt


subject: [Wikipedia-l] Middle Earth controversy

body:
On Thursday 31 January 2002 00:43, Chuck Smith wrote:
> IMHO, I don't see why we can't have an article called
> Elrond or Bilbo Baggins, and have in the first line,
> "Bilbo Baggins was a character in [[Middle Earth]]..."

You mean, just like [[Batman]]? The people working on Tolkien seem to be
the only ones in a huff and a hurry about this.

--
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

All in all, you're just another brick in the wall- Pink Floyd


from_name: lcrocker at nupedia.com

subject:
[Wikipedia-l] yet another modest proposal to address
    subpage-like behavior

body:
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020131/acffaa1f/attachment.diff


subject: [Wikipedia-l] Middle Earth controversy

in_reply_to: Michel Clasquin's message of "Thu, 31 Jan 2002 00:53:14 +0200"

body:
Michel Clasquin <clasqm at mweb.co.za> writes:

> You mean, just like [[Batman]]? The people working on Tolkien seem to be
> the only ones in a huff and a hurry about this.

Well, thats different.

Primarily, because Batman is a *the* main character in the franchise, and the
name of that franchise.  If I use the proper noun "Batman", people know what
I'm talking about.  There is no ambiguity.  The question is not where do you
put [[Batman]], but where do you put [[Robin]].  Or [[Alfred]] (do you really
want the [[Alfred]] page to be an article about an English king with poor
culinary skills and and an article about Bruce Wayne's butler?

A link to both? What would you call the latter?

Similarly, whilst [[Bilbo Baggins]] is unproblematic, [[The Ring]] should
probably be an article about Wagner's operatic cycle.
Whereas [[Middle Earth/The Ring]] can tell us about its forging in Mount Doom,
its loss in Gladden Fields yadda, yadda, yadda.

The fact remains, that (modulo the auto-wikifying of GNU/Linux, which was a
bug not a feature), and when used for *disambiguation* rather than in any
hierarchical sense, SUBPAGES WORKED.

It continues to baffle me that some people seem to think
[[Alfred (Batman)]] is in somehow sense different from [[Batman/Alfred]]
(rather than just more difficult to type).
--
Gareth Owen
"Wikipedia does rock.  By the count on the "brilliant prose" page, there
 are 14 not-bad articles so far" -- Larry Sanger (12 Jan 2001)


body:
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020131/14b11753/attachment.diff


in_reply_to: <200201311939.g0VJdeq12322@ross.bomis.com>; from lcrocker@nupedia.com on Thu, Jan 31, 2002 at 11:39:40AM -0800

body:
I think I agree 100% with Lee Crocker.  The "problem" is not
disambiguation, which is a problem requiring human cognition, but
"typing inconvenience".

lcrocker at nupedia.com wrote:
> There are already great disambiguating pages like "Java",
> and we should allow the software to do those automatically
> because we want human judgment and creativity to apply to
> making them.

I am almost certain that Lee meant to write:
"...we should NOT allow the software to do those automatically"

--Jimbo


body:
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020131/2bcc74ca/attachment.diff


body:
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020131/1774b4f7/attachment.diff


body:
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020131/08de2f79/attachment.diff


subject: [Wikipedia-l] Location of PHP software, contributions

in_reply_to: <200201312020.VAA19902@linde.uni-paderborn.de>; from axel@uni-paderborn.de on Thu, Jan 31, 2002 at 09:20:04PM +0100

body:
I think the latest version is on sourceforge.  We may soon move the
"canonical test version" to CVS here.  I'm a little shaky on the
details of how to do that, but Jason can help me, and presumably other
people, too.

> there a newer version? Also, if one (hypothetically) would fix a
> bug, should one just submit it to CVS or send it directly to
> Magnus/Jimbo?

For now, the best thing is to send patches to Magnus.  He sends me patches
every couple of days, and I install them when I can.

> On another note: somebody wrote a suggestion on the website that the
> slow response might be caused by one of the special features that have
> been added. Maybe that could be tested, by running the site for a
> while without watchlists, orphans, most wanted, page counters etc.
> When we had response problems with the old perl script, I remember it
> was due to too many RecentChanges accesses.

Today, if I get time, or else tomorrow, I'm going to install the
latest versions of PHP, Apache, and probably upgrade the kernel on the
machine, too.  Also, I bought memory, and I'll be boosting the memory
in the machine today for sure.

I'm also looking into 'apc', which is a php caching thingy, which (it
is alleged by the creators) gives a 50%-400% performance boost in
real-world applications.  We'll see about that.

I'm also thinking that we might want to think about caching the html
output, rather than generating every page on the fly from the database
all the time.  Basically, when a page is simply read, it can be stored
and also shown to the next person who reads it.  Only when a file is
edited does it need to be regenerated from scratch.

--Jimbo


from_name: Brion Vibber

subject: [Wikipedia-l] File upload Copyright notice

body:
On ?a?, 2002-01-31 at 12:09, Axel Boldt wrote:
> The current file upload utility requires the user to "donate" the
> copyright to "Wikipedia". Wikipedia is no legal entity, so this
> doesn't make sense. It is also not in line with the way we have
> handled copyrights up to know for text submissions: the user retains
> copyright, but licenses the work under GFDL. I suggest that this be
> changed.

Hmm, I read it as the *file* being donated, not the copyright. Poorly
worded in either case...

-- brion vibber (brion @ pobox.com)


body:
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020131/a46aad97/attachment.diff


from_name: Lars Aronsson

body:
Uri wrote:
> I could think of several solutions to this problem:
> * Remove the [[Middle Earth/]] part (e.g. [[Elrond]] instead
>     of [[Middle Earth/Elrond]]. But this would not only
>     add fictional content to the generally real-world
>     encyclopedia but also confuse the readers (think about
>     [[USS Enterprise]]!)

How bad would this be?  Is it really a problem to have fictional
contents in main entries?  Aren't there already entries on [[Moses]],
[[Zeus]], [[Big Bang]], and [[Phlogiston theory]]?  Is any harm done?
The article text would provide the context for the word: "In the books
by [[JRR Tolkien]], the fictional character Elrond is described as..."

Is there anything else in the universe named Elrond?  Do we have an
ambiguity conflict here (like Java - island, coffee, or programming
language)?

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