body:
I like this proposal because it is both useful and technically sound - a
rare combination these days ;)

As the software will then actually modify the articles automatically, I
guess this needs approval from The One Who Said He'd Be Back (not Arnold;)

Magnus

> -----Original Message-----
> From: wikipedia-l-admin at nupedia.com
> [mailto:wikipedia-l-admin at nupedia.com]On Behalf Of Tim Chambers
> Sent: Thursday, January 31, 2002 12:23 AM
> To: Wikipedia List
> Subject: [Wikipedia-l] yet another modest proposal to address
> subpage-like behavior
>
>
> 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.
>
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


list: wikipedia-l

source: pipermail-mbox

from_name: Gareth Owen

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

in_reply_to: "Magnus Manske"'s message of "Thu, 31 Jan 2002 18:45:28 +0100"

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

> That's it (as I understood it). The problem at [[Middle Earth]] does seem to
> be thy typing inconvenience.

As necessitated by disambiguation.  (is that a word?)

> The proposal should solve it nicely and simple,

It would certainly seem to.

> without subpages.

Well, maybe not.  But not without something isomorphic to subpages :)
--
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: Vicki Rosenzweig

subject: [Wikipedia-l] Middle Earth controversy

references:
<r5izo2un90p.fsf@gill.maths.keele.ac.uk>
 <20020130224339.79863.qmail@web12003.mail.yahoo.com>
 <E16W3Qq-0002lx-00@mono.mweb.co.za>
 <r5izo2un90p.fsf@gill.maths.keele.ac.uk>

body:
At 08:01 PM 1/31/02 +0200, Michel Clasquin wrote:
>On Thursday 31 January 2002 11:51, Gareth Owen wrote:
>
> >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?
>
>I don't got no problem with that. See [[Thor]]
>
>Besides, Batman's Alfred does actually have a surname, Merriweather, I
>think it was. So, between [[Alfred the Great]] and [[Alfred Merriweather]]
>the problem is solved.

The longer we discuss this, the more I wonder whether we actually want to
encourage Wikipedia to be a guide to fictional characters.

Good, solid entries on [[Middle Earth]] and [[Batman]], yes. Separate entries
on every character in either are starting to feel like overkill. And not
just because
there's already an online Encyclopedia of Arda.

I realize that these entries aren't really a "waste of resources," because
someone
who wants to write about Batman isn't necessarily going to say "Oh, well,
no room
for that, and we need an article about Tennesee/English line
dancing/Nero/peas...."
But I do wonder what impression people get when they come to Wikipedia, look at
the lists of recent changes or new pages, and find so much on secondary worlds.

I also have a feeling that, well, if someone doesn't know who Tolkien is,
we can be a
useful resource. If they're looking for details of the life of Elrond,
they're better off looking
at the works of Tolkien.

As such, is it worth going to extra trouble--setting up separate forms or even
namespaces--to make it easier to provide this information? Raise (poker) and
Java (island) and such make sense, but I think that's as far as we should go.
--
Vicki Rosenzweig
vr at redbird.org
http://www.redbird.org


from_name: Magnus Manske

body:
> It's not clear to me from Tim's description exactly what
> he's proposing, so let me paraphrase what I think he means:
>
> 1) No meta tags (#base, #context, #parent, #alias, or all
> the variants we've discussed over the months), no new name
> spaces or runtime-features of any kind.
>
> 2) As purely a typing convenience like ~~~, links typed
> as [[/baz]] on page "Foo (Bar)" are rewritten when saved
> as [[Baz (Bar)|baz]]; links in the form [[/baz]] on page
> "Foo" are rewritten as [[Baz (Foo)|baz]].  If the link
> already specifies a display form (the part after the
> vertical bar), that display form is used as is.
>
> 3) Links with non-initial slashes are not modified at all.

That's it (as I understood it). The problem at [[Middle Earth]] does seem to
be thy typing inconvenience. The proposal should solve it nicely and simple,
without subpages.

Magnus


from_name: Jan Hidders

body:
From: "Magnus Manske" <Magnus.Manske at epost.de>
>
> That's it (as I understood it). The problem at [[Middle Earth]] does seem
to
> be thy typing inconvenience. The proposal should solve it nicely and
simple,
> without subpages.

I think Tims proposal is an excellent one, but if I'm honest it looks very
much like subpages with a slightly different (better) notation.

-- Jan Hidders


body:
I just thought of a way to solve the problem without any subpage-like
notations:

* Have all topics, even fictional characters, as a plain title.

* On pages where the title has multiple meanings (e.g., Mars), use a
wikipedia-special heading tags. I suggest
<h0>Mars the god</h0>
.....
<h0>Mars the planet</h0>
.....

* On each page that has these special tags, the software generates a brief
directory with links inside the page

Mars the god

Mars the planet

Personally, I like Tims proposal better, but is has turned out that my taste
in these things is strangely uncorrelated with that of the rest of the
wikipedia community ;)

Magnus

> -----Original Message-----
> From: wikipedia-l-admin at nupedia.com
> [mailto:wikipedia-l-admin at nupedia.com]On Behalf Of Jan Hidders
> Sent: Thursday, January 31, 2002 6:59 PM
> To: wikipedia-l at nupedia.com
> Subject: Re: [Wikipedia-l] yet another modest proposal to address
> subpage-like behavior
>
>
> From: "Magnus Manske" <Magnus.Manske at epost.de>
> >
> > That's it (as I understood it). The problem at [[Middle Earth]]
> does seem
> to
> > be thy typing inconvenience. The proposal should solve it nicely and
> simple,
> > without subpages.
>
> I think Tims proposal is an excellent one, but if I'm honest it looks very
> much like subpages with a slightly different (better) notation.
>
> -- Jan Hidders
>
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


subject: [Wikipedia-l] wiki.phtml subpage phenomenon

body:
I noticed that the software (see how I avoid saying "my software" in this
context? ;) sometimes creates subpages that are named wiki.phtml.

Trying to figure out the cause of that, I'd like anyone who accidentially
created such a page tell me what *exactly* he/she was doing when this
happened. Were there any other strange side effects? Did you do a preview?
Create another new page? Got an edit conflict?

Anything might help.

Thanks,
Magnus


from_name: sgilbert at nbnet.nb.ca

subject: [Wikipedia-l] wiki.phtml bug

body:
> I noticed that the software (see how I avoid saying "my software" in this
> context? ;) sometimes creates subpages that are named wiki.phtml.
>
> Trying to figure out the cause of that, I'd like anyone who accidentially
> created such a page tell me what *exactly* he/she was doing when this
> happened. Were there any other strange side effects? Did you do a preview?
> Create another new page? Got an edit conflict?

I created one today by trying to edit
[[Stephen_Gilbert/Contributions]]. Several days ago I got into a
perpetual edit conflict with myself, so I left it. Today, I went back to
it, and came up at the edit page automatically. I was still in that
edit conflict, so I hit the Random Page link in the header. That's
when the software created [[Stephen_Gilbert/wiki.phtml]].

- Stephen


from_name: Chuck Smith

subject: [Wikipedia-l] International wikipedias statistics

body:
These statistics are for the two International
Wikipedias (English and Esperanto).  I took into
account duplicate listing for states, but not for
countries, so the country stats may be a bit off.  I
think you'll all find this interesting.  This took a
while so don't expect me to do it too often...

Enjoy!
Chuck Smith

--- English Wikipedia ---

Listed in US: 85
Actual in US: 79
43.9% in US
Listed Most Times: 4 - Jimbo Wales (Alabama,
California, Illinois, Indiana)
Listed non-US: 101
En - predominantly English speaking countries
(8 Australia, 11 Canada, 1 Singapore, 1 South Africa,
22 United Kingdom, 79 United States)
Actual in En: 122
67.8% in En

Breakdown by Country:
 1 Andorra
 8 Australia
 1 Bosnia and Herzegovina
11 Canada
 1 Chile
 2 Denmark
 4 Finland
 7 Germany
 1 Hungary
 2 Republic of Ireland
 4 Israel
 2 Italy
 4 The Netherlands
 1 Malta
 1 Mexico
 2 New Zealand
 2 Norway
 5 Poland
 2 Portugal
 1 Russia
 1 Singapore
 1 South Africa
 4 Spain
 9 Sweden
 1 Switzerland
 1 Turkey
22 United Kingdom

Breakdown by US State
 1 Alabama
 2 Alaska
 3 Arizona
 0 Arkansas
19 California
 1 Colorado
 2 Connecticut
 0 Delaware
 1 District of Columbia
 0 Florida
 1 Georgia
 0 Hawaii
 0 Idaho
 3 Illinois
 2 Indiana
 2 Iowa
 0 Kansas
 2 Kentucky
 1 Louisiana
 0 Maine
 2 Maryland
 4 Massachusetts
 3 Michigan
 2 Minnesota
 0 Mississippi
 1 Missouri
 0 Montana
 0 Nebraska
 2 Nevada
 0 New Hampshire
 1 New Jersey
 0 New Mexico
 8 New York
 3 North Carolina
 0 North Dakota
 2 Ohio (!)
 0 Oklahoma
 1 Oregon (!)
 1 Pennsylvania
 0 Puerto Rico
 0 Rhode Island
 0 South Carolina
 0 South Dakota
 1 Tennessee
 3 Texas
 0 Utah
 0 Vermont
 2 Virginia
 4 Washington
 0 West Virginia
 0 Wisconsin
 0 Wyoming
 5 Nomadic and shy (includes Larry Sanger, but we know
where you live...*evil laughter*)
85 Total

--- Esperanto Wikipedia ---

Actual in US: 7
0% living in predominantly Esperanto speaking country
:)
Actual non-US: 10
41.2% in US
41.2% in En

1 Brazil
1 Catalonia
1 China
1 France
1 Japan
1 Polland
2 Russia
1 Spain
7 United States

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

_________________________________________________________
Do You Yahoo!?
Informaci?n de Estados Unidos y Am?rica Latina, en Yahoo! Noticias.
Vis?tanos en http://noticias.espanol.yahoo.com


from_name: Michel Clasquin

subject: [Wikipedia-l] Middle Earth controversy

body:
On Thursday 31 January 2002 11:51, Gareth Owen wrote:

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

I don't got no problem with that. See [[Thor]]

Besides, Batman's Alfred does actually have a surname, Merriweather, I
think it was. So, between [[Alfred the Great]] and [[Alfred Merriweather]]
the problem is solved.

--
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] yet another modest proposal to address subpage-like behavior

body:
From: "Tim Chambers" <tbchambers at yahoo.com>
>
> [...] 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.

Excellent idea; clear, simple and elegant. But I also see a small problem:
except for a small difference in notation this is almost exactly the same as
having subpages. However, I think the big difference here is that we know
what the name "X (Y)" means; X is a term that has a specific meaning in
knowledge area Y, e.g., "Function (Set theory)" or "Mapping (Topology)", or
X is the name of a thing of a certain type, e.g., "Java (Island)", "Java
(Coffee)", and "Java (Programming language)" . (I would expect that many
namespaces correspond with Wikipedia categories.) I believe that his makes
namespaces less arbitrary than subpages, which was IMHO Larry's most
important argument against subpages. But I have to admit that it also could
have been "Java (Computer science)" or even something else, some
arbitrariness is still left.

Another small problem is: what do I do if I want a links on "Middle Earth
(Tolkien)" to have the name space "Middle Earth"? That is something that you
would probably want for many links there. So I would suggest the following
notation:
- [[:name]] for a sibling page, i.e., a page in the same name space as the
page the link is on
- [[/name]] for a child page, i.e., a page in the name space corresponding
with the page the link is on

Another argument that Larry used was "why only two levels?". As you can
probably guess from my previous mail, I agree with that. So allow me to take
your idea and make it horribly complex and unimplementable. :-) No
seriously, I'll try to keep it simple this time. Here goes.

1. If there is a page with a name of the form "X (Y)" then X is a sub-name
space of Y. Pages without a name space in their name are presumed to belong
to the highest global name space. (only terminology)
2. links [[/X]] and [[/X (Y)]] are replaced as in your proposal
3. link [[:X]] on page [[Y (Z)]] is replaced with [[X (Z)|X]]   (only
slightly different notation)
4. link [[X]] on page [[Y (Z)]] is replaced with [[X (Y)|X]] if "X (Y)"
exists and Y is the first name-space from below that is a super-name space
of Z. This makes that sub-name spaces inherit page names from super-name
spaces as you would expect.

This avoids having lists of #base pragma's which you may have to retype (you
could even have "multiple inheritance" of name spaces) and if you like you
can also have automatic links to the super-name spaces without the need of a
double edit.

-- Jan Hidders


from_name: Axel Boldt

subject: [Wikipedia-l] File upload Copyright notice

body:
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.

Axel


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

body:
Hello,

if one (hypothetically :-) wanted to help in finding bugs, should one
start with the version of the software on sourceforge, in CVS, or is
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?

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.

Axel


body:
From: <lcrocker at nupedia.com>
>
> > I think Tims proposal is an excellent one, but if I'm honest it
> > looks very much like subpages with a slightly different (better)
> > notation.
>
> But there are critical differences: most importantly, the article
> namespace remains semantically flat; "Foo (Bar)" is still a top-
> level article just like "Bar", and they have no pre-defined
> relationship of any kind, and no runtime features that link them
> in any way.  People won't be tempted to use them to "categorize"
> pages into hierachies.

That's true. With subpages the new user saw a link called "/blah" and in the
edit page it also said [[/blah]], which makes it very easy and tempting.

-- Jan Hidders


from_name: Uri Yanover

body:
I must agree with that. We shouldn't add non-intuitive
features to Wikipedia mark-up. In particular, I don't
see any substancial difference between
[[Elrond (Middle Earth)]] and [[Middle Earth/Elrond]]
(The former looks more aesthetical to me, though), and
if Wikipedia software itself does not recognize subpages,
we shouldn't add subpage-like features.

Unlike most others encyclopedias, Wikipedia is about
ease of editing too, and editing is made harder by the
abiguity in the convert-links-once solution. What I like
in the idea of aliases is the total control of the author
over what he links to. This won't be possible if Wiki
software is the thing that decides about the conversion.

            Uri Yanover

----- Original Message -----
From: <lcrocker at nupedia.com>
To: <wikipedia-l at nupedia.com>
Sent: Thursday, January 31, 2002 9:39 PM
Subject: Re: [Wikipedia-l] yet another modest proposal
to address subpage-like behavior

>
> Sorry, Magnus, but your counter-proposal changes the
> runtime behavior of the system and is /far/ too complicated.
> Let's not shoot the golden goose here: Wikipedia works
> because it is SIMPLE.  Article title space should be
> flat (whether or not we add typing conveniences).
>
> Also, disambiguation isn't the problem we're trying to
> solve here.  That can be done easily enough manually.
> 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.
>
> The issue really is just one of typing convenience.  When
> I write about Texas Hold'em strategy, I might say something
> like "A raise from late position on the flop will often
> cause an opponent to check to you on the turn, giving you
> the chance to check behind him and take a free card."  In that
> sentence, I might want to link words like "raise", "position",
> "flop", "free card" and such, and typing "[[Raise (Poker}|raise]]"
> for every one of them is a pain.  But I /want/ to do the right
> thing semantically and make sure that the link actually does go
> to the "Raise (Poker)" page, and not just to a disambiguating
> "Raise" page that will interrupt and confuse the reader.
>
> Of course, when I /want/ links to be ambiguous to encourage
> "accidental" discovery, I can still do that too.  In my
> "See also" lines, for example, I'll probably just link to
> simple titles, hoping that accidental links do interesting
> things.  So there /will/ be an "Elves" page with pointers to
> other contexts, as well as "Elves (Tolkein)", or whatever.
> The author should have the choice, and the power.  The software
> should support what theauthor wants to do, not enforce its
> ideas or structure upon the author.
> 0


subject: [Wikipedia-l] Re:  yet another modest proposal to address

body:
I must agree with that. We shouldn't add non-intuitive
features to Wikipedia mark-up. In particular, I don't
see any substancial difference between
[[Elrond (Middle Earth)]] and [[Middle Earth/Elrond]]
(The former looks more aesthetical to me, though), and
if Wikipedia software itself does not recognize subpages,
we shouldn't add subpage-like features.

Unlike most others encyclopedias, Wikipedia is about
ease of editing too, and editing is made harder by the
abiguity in the convert-links-once solution. What I like
in the idea of aliases is the total control of the author
over what he links to. This won't be possible if Wiki
software is the thing that decides about the conversion.

            Uri Yanover

P.S. My appologies if this message reaches the list
twice, my mailer drives me crazy :-(

----- Original Message -----
From: <lcrocker at nupedia.com>
To: <wikipedia-l at nupedia.com>
Sent: Thursday, January 31, 2002 9:39 PM
Subject: Re: [Wikipedia-l] yet another modest proposal
to address subpage-like behavior

>
> Sorry, Magnus, but your counter-proposal changes the
> runtime behavior of the system and is /far/ too complicated.
> Let's not shoot the golden goose here: Wikipedia works
> because it is SIMPLE.  Article title space should be
> flat (whether or not we add typing conveniences).
>
> Also, disambiguation isn't the problem we're trying to
> solve here.  That can be done easily enough manually.
> 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.
>
> The issue really is just one of typing convenience.  When
> I write about Texas Hold'em strategy, I might say something
> like "A raise from late position on the flop will often
> cause an opponent to check to you on the turn, giving you
> the chance to check behind him and take a free card."  In that
> sentence, I might want to link words like "raise", "position",
> "flop", "free card" and such, and typing "[[Raise (Poker}|raise]]"
> for every one of them is a pain.  But I /want/ to do the right
> thing semantically and make sure that the link actually does go
> to the "Raise (Poker)" page, and not just to a disambiguating
> "Raise" page that will interrupt and confuse the reader.
>
> Of course, when I /want/ links to be ambiguous to encourage
> "accidental" discovery, I can still do that too.  In my
> "See also" lines, for example, I'll probably just link to
> simple titles, hoping that accidental links do interesting
> things.  So there /will/ be an "Elves" page with pointers to
> other contexts, as well as "Elves (Tolkein)", or whatever.
> The author should have the choice, and the power.  The software
> should support what theauthor wants to do, not enforce its
> ideas or structure upon the author.
> 0


from_name: Jimmy Wales

in_reply_to: <ILENJBCFHGHELEBFPPBGAEBJCFAA.Magnus.Manske@epost.de>; from Magnus.Manske@epost.de on Fri, Feb 01, 2002 at 11:23:18PM +0100

body:
Magnus Manske wrote:
> I just uploaded the very, very latest version to SourceForge CVS. This is
> even more up-to date than the version I sent Jimbo yesterday, and certainly
> more up-to-date than the one that is currently running, which is about 4
> days old :(

This should be fixed by the end of today.

In other news, we upgraded the kernel on the machine and fiddled with some
settings so that the machine now recognizes all 1 gig of memory.

I'll be upgrading the PHP and Apache today, if all goes well, and also installing
Magnus's latest code.


subject: [Wikipedia-l] Wow

body:
Uh, the new software update broke everything.  This is probably something
I did.  I'm going to try rolling it back now.


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

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

I've downloaded the script file from CVS but it looks very old and the
parser looks very rudimentary and very different from what is now running.
Or is there also a script in the big zip file? I'd really like to chase some
formatting bugs this weekend. So what I would like to get from somewhere is
the latest script and some additional script that creates the necessary
tables with enough contents to start running, without having to download the
big zip file from sourceforge. Couldn't that be placed on Wikipedia
somewhere?

Pretty please? :-)

-- Jan Hidders


subject: [Wikipedia-l] Upgrades finished

body:
We are now running:

Linux 2.4.17
Apache 1.3.23
Php 4.1.1
mod_fastcgi 2.2.12

And the latest version of wikipedia that Magnus sent me earlier today.

Also, the machine has been upgraded from 512 megabytes of memory to 1
gigabyte of memory.

It is hoped that this will improve our performance, perhaps
substantially.

I'm in the process of rolling upgrades to all my servers, bumping them all
up to 2 gig, and in some cases beyond.  Wikipedia will eventually benefit
from that.

In the meantime, everyone please keep the bug reports flowing, or even better,
check out the CVS on sourceforge and send in patches.  :-)

--Jimbo


from_name: Ian

body:
Well, we are apparently huge in Andorra. One user page out of a population
of 67,627! If we had that relative user base in China, there would be
18,825 user pages from China and 4,112 user pages if such a pecentage of
users existed in the USA.

Wikipedia is currently spitting out binary garrble )-:

Ian Monroe
http://mlug.missouri.edu/~eean/

On Thu, 31 Jan 2002, Chuck Smith msochuck at yahoo.com XXXXXXXXXXXXXXXXXXXXX wrote:

> These statistics are for the two International
> Wikipedias (English and Esperanto).  I took into
> account duplicate listing for states, but not for
> countries, so the country stats may be a bit off.  I
> think you'll all find this interesting.  This took a
> while so don't expect me to do it too often...
>
> Enjoy!
> Chuck Smith
>
> --- English Wikipedia ---
>
> Listed in US: 85
> Actual in US: 79
> 43.9% in US
> Listed Most Times: 4 - Jimbo Wales (Alabama,
> California, Illinois, Indiana)
> Listed non-US: 101
> En - predominantly English speaking countries
> (8 Australia, 11 Canada, 1 Singapore, 1 South Africa,
> 22 United Kingdom, 79 United States)
> Actual in En: 122
> 67.8% in En
>
> Breakdown by Country:
>  1 Andorra
>  8 Australia
>  1 Bosnia and Herzegovina
> 11 Canada
>  1 Chile
>  2 Denmark
>  4 Finland
>  7 Germany
>  1 Hungary
>  2 Republic of Ireland
>  4 Israel
>  2 Italy
>  4 The Netherlands
>  1 Malta
>  1 Mexico
>  2 New Zealand
>  2 Norway
>  5 Poland
>  2 Portugal
>  1 Russia
>  1 Singapore
>  1 South Africa
>  4 Spain
>  9 Sweden
>  1 Switzerland
>  1 Turkey
> 22 United Kingdom
>
> Breakdown by US State
>  1 Alabama
>  2 Alaska
>  3 Arizona
>  0 Arkansas
> 19 California
>  1 Colorado
>  2 Connecticut
>  0 Delaware
>  1 District of Columbia
>  0 Florida
>  1 Georgia
>  0 Hawaii
>  0 Idaho
>  3 Illinois
>  2 Indiana
>  2 Iowa
>  0 Kansas
>  2 Kentucky
>  1 Louisiana
>  0 Maine
>  2 Maryland
>  4 Massachusetts
>  3 Michigan
>  2 Minnesota
>  0 Mississippi
>  1 Missouri
>  0 Montana
>  0 Nebraska
>  2 Nevada
>  0 New Hampshire
>  1 New Jersey
>  0 New Mexico
>  8 New York
>  3 North Carolina
>  0 North Dakota
>  2 Ohio (!)
>  0 Oklahoma
>  1 Oregon (!)
>  1 Pennsylvania
>  0 Puerto Rico
>  0 Rhode Island
>  0 South Carolina
>  0 South Dakota
>  1 Tennessee
>  3 Texas
>  0 Utah
>  0 Vermont
>  2 Virginia
>  4 Washington
>  0 West Virginia
>  0 Wisconsin
>  0 Wyoming
>  5 Nomadic and shy (includes Larry Sanger, but we know
> where you live...*evil laughter*)
> 85 Total
>
> --- Esperanto Wikipedia ---
>
> Actual in US: 7
> 0% living in predominantly Esperanto speaking country
> :)
> Actual non-US: 10
> 41.2% in US
> 41.2% in En
>
> 1 Brazil
> 1 Catalonia
> 1 China
> 1 France
> 1 Japan
> 1 Polland
> 2 Russia
> 1 Spain
> 7 United States
>
> =====
> 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
>
> _________________________________________________________
> Do You Yahoo!?
> Informaci?n de Estados Unidos y Am?rica Latina, en Yahoo! Noticias.
> Vis?tanos en http://noticias.espanol.yahoo.com
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>


subject: [Wikipedia-l] Middle Earth controversy

body:
On Friday 01 February 2002 01:25, Vicki Rosenzweig wrote:

> The longer we discuss this, the more I wonder whether we actually want
> to encourage Wikipedia to be a guide to fictional characters.
> Good, solid entries on [[Middle Earth]] and [[Batman]], yes. Separate
> entries on every character in either are starting to feel like overkill.

A good question, Vicki.

> I realize that these entries aren't really a "waste of resources,"
> because someone
> who wants to write about Batman isn't necessarily going to say "Oh,
> well, no room
> for that, and we need an article about Tennesee/English line
> dancing/Nero/peas...."

I'm not too sure about that. "Most wanted" got weeded out steadily until
it was swamped with dates, and I hope to see "Orphans" return

> But I do wonder what impression people get when they come to Wikipedia,
> look at the lists of recent changes or new pages, and find so much on
> secondary worlds.

Well, maybe they think "hey, this place is hip and happening" ...

Fictional characters are not exactly the staple fare of traditional
ecyclopedias. But wkp is something different - it can contain the
traditional stuff but it need not be limited by it.  If people feel
compelled to write articles on Middle Earth then at some level it must be
real and important to them.  Someone looking for info on accounting
practices in upper Sulawesi need never come across it.

> As such, is it worth going to extra trouble--setting up separate forms
> or even namespaces--to make it easier to provide this information? Raise
> (poker) and Java (island) and such make sense, but I think that's as far
> as we should go.

As someone said yesterday, KEEP IT SIMPLE!  Once you start creating
namespaces for content, it becomes too difficult for the newbie to add new
snippets and create new pages, or we may see people starting [[Utopians]]
blissfully unaware that [[Utopia:characters]] already exists.

Next, we can see a flood of new namespace requests. How about one for
[[Flashman:]],  or maybe [[Davy Crockett:]]? This way lies madness.

clasqm
Proud originator of the [[Asterix]] and [[Batman]] 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] wiki.phtml/SQL errors

body:
The last two pages I tried to look at were full of gibberish, followed by
boldface and underlined gibberish, and then MySQL error messages.
See http://www.wikipedia.com/wiki.phtml?title=Sojourner_Truth
The other page I tried to look at was Physical anthropology. Both
links from "Recent changes."

We have a problem here.
--
Vicki Rosenzweig
vr at redbird.org
http://www.redbird.org


from_name: Carey Evans

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

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

[...]

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

Or when any previously nonexistant page it links to is created.  It's
my understanding that these links are saved in the database, so
noticing this shouldn't be very hard.

--
	 Carey Evans  http://home.clear.net.nz/pages/c.evans/

			     Cavem canus.


from_name: Brion Vibber

subject: [Wikipedia-l] HTML entities in article titles?

body:
In the 'Wikipedia:Bug reports' page, it came up that someone's trying to
make an article titled "β-cyclodextrine", ie using the HTML
character entity for the greek letter beta (β).

Currently the code makes a mess of attempts to do this; it can be sorted
out, but the question is how *should* it behave?

Possibility one: Ampersands in general and HTML entities in specific
should not work in article titles; links to such pages will be
considered invalid. (I believe this is how it worked on the old
software.) The user should probably instead title that page
"Beta-cyclodextrine".

Possibility two: Ampersands will be escaped; HTML entities will not work
as such in article titles, but the name typed as "β-cyclodextrine"
would appear as typed, with an ampersand, the word "beta" and a
semicolon. The user should probably instead title that page
"Beta-cyclodextrine", but might well call a page "HTML entity β".

Possibility three: HTML entities should work in article titles. Thus the
name typed as "β-cyclodextrine" will appear in body text and the
page title with a beta character. For "HTML entity β" to display as
intended the wikipedian must type "HTML entity &beta;".

Possibility four...?

-- brion vibber (brion @ pobox.com)


body:
> I've downloaded the script file from CVS but it looks very old and the
> parser looks very rudimentary and very different from what is now running.
> Or is there also a script in the big zip file? I'd really like to
> chase some
> formatting bugs this weekend. So what I would like to get from
> somewhere is
> the latest script and some additional script that creates the necessary
> tables with enough contents to start running, without having to
> download the
> big zip file from sourceforge. Couldn't that be placed on Wikipedia
> somewhere?

I just uploaded the very, very latest version to SourceForge CVS. This is
even more up-to date than the version I sent Jimbo yesterday, and certainly
more up-to-date than the one that is currently running, which is about 4
days old :(

It has many bugfixes and some very minor "feature requests".

The CVSROOT is cvs.wikipedia.sourceforge.net:/cvsroot/wikipedia
The package is phpwiki.
THe code you want is in the fpw subdirectory.

Maybe someone should put this up on the wiki somewhere...

NOTE: This is *not* the code that currently runs on the sourceforge test
site! It is the current bomis version!

I agree it would be best to have the CVS at bomis as well, like it was done
for Nupedia.

Magnus


body:
> > But there are critical differences: most importantly, the article
> > namespace remains semantically flat; "Foo (Bar)" is still a top-
> > level article just like "Bar", and they have no pre-defined
> > relationship of any kind, and no runtime features that link them
> > in any way.  People won't be tempted to use them to "categorize"
> > pages into hierachies.
>
> That's true. With subpages the new user saw a link called "/blah"
> and in the
> edit page it also said [[/blah]], which makes it very easy and tempting.

But an automatic replacement of [[/bar]] to [[foo/bar]] on Save wouldn't be
any different, except the () soultion might be more "natural" looking than
the / thing...

Magnus


subject: [Wikipedia-l] Up again

body:
The site is up again. Good work, Jimbo! I should know better than to
recommend a software upgrade (never change...;)

And you installed the new software. Apart from some goodies, I just found a
bug. When trying to edit a "subpage" (any page with a "/" in the title), it
says "URL not found". It is the same here, so it is not the rewrite rules
that cause it, but the software.

Until the bugfix, if you encounter that page, manually replace the "%2F" in
the URL box with a normal "/", the reload. You'll get the edit page then.

Sorry for that. WOrking on the fix right now.

Magnus


subject: [Wikipedia-l] New to the Wikipedia with a few questions

body:
On sab, 2002-02-02 at 01:11, David Black wrote:
> I'm new to Wikipedia and would like to contribute to some of the pages. I
> would initially like to add a list of recommended books to some of the
> pages with a review paragraph. Is it permissible ( is it accepted
> practice ) to link the book into something like Amazon so that if the
> reader wanted to buy a copy they can ?
[..]
> PS I'm not proposing this to sell book it's just that it's the sort of
> feature I would like to see.

It's already a feature. Just insert the ISBN number and the wiki
automatically links to pricescan.com, which will provide links to a wide
range of online retailers which carry the given book. ie,
  ISBN 0844237639
results in a link to
  http://www.pricescan.com/books/bookDetail.asp?isbn=0844237639

Fun, huh?

-- brion vibber (brion @ pobox.com)


in_reply_to: <1012643922.18519.0.camel@rdaneel.moisty.org>; from brion@pobox.com on Sat, Feb 02, 2002 at 01:58:41AM -0800

body:
I'd just like to add that for now, the auto-generated links from ISBNs are not
"affiliate coded".  So we don't make any money from those links.

However, with the ongoing hard times in the Internet economy, we do
anticipate adding some forms of advertising to the site in the near
future.  One thing that we will do is make sure that ISBN links are
affiliate coded.

I would of course view it as inappropriate for people to insert their own
affiliate coded links into the Wikipedia.

-----

Some abstract thoughts on these matters:

1.  Advertising must not interfere with the content of the
encyclopedia.  There must be a "Chinese wall" between the two.  This
is ensured by the fact that the content portions of the pages are
always editable by anyone.  Advertisements should be separate from
content and must be clearly advertisements.

2.  Although links to booksellers are a natural fit, a natural feature
that people like _anyway_, some may feel that they blur the line to
some extent between advertising and content.  The important thing here
is that even as advertising, automatic book links should be vendor
neutral, and I would also support including some kind of library link
there, too.

3.  Amazon.com is the easiest (to my knowledge) affiliate program to
work with.  But, Amazon.com is controversial in the free software
community for their patent activities, most notably their monumentally
stupid and offensive "one click" patent, which they used to restrict
competition from Barnes&Noble.  I'm sensitive to those concerns.

4.  My current thinking on advertising is that people who are logged-in
should have ads turned *off* by default, although if they want to help
fund Wikipedia, they can turn them back on and make an effort to click
through and buy stuff.

5.  I know the introduction of advertising will be controversial with
some people, no matter how carefully and sensitively we do it.  Those
people are invited to step forward and pay for Wikipedia out of their
own pockets if they like.  :-)

--Jimbo


from_name: David Black

body:
Hi,

I'm new to Wikipedia and would like to contribute to some of the pages. I would initially like to add a list of recommended books to some of the pages with a review paragraph. Is it permissible ( is it accepted practice ) to link the book into something like Amazon so that if the reader wanted to buy a copy they can ?

Kind regards,

David

PS I'm not proposing this to sell book it's just that it's the sort of feature I would like to see.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020202/45594a7f/attachment.htm


body:
Hr. Daniel Mikkelsen wrote:
> What are the expenses involved? What is the bandwidth consumed? The
> storage space required? The load on servers?

1.  The physical expenses are minimal and easily absorbed.  So none of
the things you mention are worth worrying about -- I can continue to
pay for those things indefinitely.  (If Wikipedia were to be 100 times
more popular, though, these things would start to add up!)

2.  The programming expenses are drastically lower for Wikipedia than
they ever were for Nupedia.  Volunteers are to thank for this.
Nupedia was very expensive to build, because I paid programmers
(chiefly Toan) to do it.  Currently, Jason and I spent a few hours
per week on Wikipedia.

3.  The major remaining expense is Larry's editorial leadership, which
I believe has been a major factor in the success of the project to
date.  Fans of random anarchy may disagree, of course.  And if they
do, I'm happy to provide them (so long as the license is free!) with
web space to have a totally unmanaged project.  I think they'll get
crap, though.

--Jimbo


body:
From: "Uri Yanover" <uriyan_subscribe at yahoo.com>
>
> Unlike most others encyclopedias, Wikipedia is about
> ease of editing too, and editing is made harder by the
> abiguity in the convert-links-once solution. What I like
> in the idea of aliases is the total control of the author
> over what he links to. This won't be possible if Wiki
> software is the thing that decides about the conversion.

I would say that it is exactly the other way around. Tim's proposal is not
ambiguous and does not require any searching for terms in name spaces.
Your's, however, does.

-- Jan Hidders


from_name: wikipedia at epoptic.org

subject: [Wikipedia-l] trouble including a picture

body:
Can someone take a look at http://www.wikipedia.com/wiki/RQ-1_Predator
and tell me why the picture at the bottom isn't showing up?  If you
click on the link, the picture will be displayed by itself, but it'd be
nice to see it in the page itself.

I've upload numerous other pictures with no problems....

--[[the Epopt]]


body:
Thanks for the reply and information.

David

----- Original Message -----
From: "Brion Vibber" <brion at pobox.com>
To: <wikipedia-l at nupedia.com>
Sent: Saturday, February 02, 2002 9:58 AM
Subject: Re: [Wikipedia-l] New to the Wikipedia with a few questions

> On sab, 2002-02-02 at 01:11, David Black wrote:
> > I'm new to Wikipedia and would like to contribute to some of the pages.
I
> > would initially like to add a list of recommended books to some of the
> > pages with a review paragraph. Is it permissible ( is it accepted
> > practice ) to link the book into something like Amazon so that if the
> > reader wanted to buy a copy they can ?
> [..]
> > PS I'm not proposing this to sell book it's just that it's the sort of
> > feature I would like to see.
>
> It's already a feature. Just insert the ISBN number and the wiki
> automatically links to pricescan.com, which will provide links to a wide
> range of online retailers which carry the given book. ie,
>   ISBN 0844237639
> results in a link to
>   http://www.pricescan.com/books/bookDetail.asp?isbn=0844237639
>
> Fun, huh?
>
> -- brion vibber (brion @ pobox.com)
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


from_name: Hr. Daniel Mikkelsen

body:
On Sat, 2 Feb 2002, Jimmy Wales wrote:

> 5.  I know the introduction of advertising will be controversial with
> some people, no matter how carefully and sensitively we do it.  Those
> people are invited to step forward and pay for Wikipedia out of their
> own pockets if they like.  :-)

What are the expenses involved? What is the bandwidth consumed? The
storage space required? The load on servers?

-- Daniel Mikkelsen,
   Copyleft Software AS


body:
On Sat, 2 Feb 2002, Jimmy Wales wrote:

> Hr. Daniel Mikkelsen wrote:
> > What are the expenses involved? What is the bandwidth consumed? The
> > storage space required? The load on servers?

> 1.  The physical expenses are minimal and easily absorbed.  So none of
> the things you mention are worth worrying about -- I can continue to
> pay for those things indefinitely.  (If Wikipedia were to be 100 times
> more popular, though, these things would start to add up!)

Yes. Given the wonderfully light format (and nature!) of the project, I'd
expect a normal small company could run it today.

I feel certain the project will become very large. When that happens, I'm
thinking it shouldn't be too difficult getting a university (or at least
some non-commercial entity) to host it, since it is makes very good use of
bandwidth (compared to, say, radio streaming) and is Free. Also, although
there would some consistency problems, making Wikipedia distributed
(something like freenet/newsgroups) should be possible.

As for hardware, it's really cheap these days. I haven't scrutinized the
PHP Script, but it occurs to me some creative cacheing (and at the other
end, offloading history data to a less optimized method of access) could
extend hardware life substantially.

> 2.  The programming expenses are drastically lower for Wikipedia than
> they ever were for Nupedia.  Volunteers are to thank for this.
> Nupedia was very expensive to build, because I paid programmers
> (chiefly Toan) to do it.  Currently, Jason and I spent a few hours
> per week on Wikipedia.

Yes, Free Software has basically solved this problem. If the rest of the
world's aspects could just learn from this model. :)

> 3.  The major remaining expense is Larry's editorial leadership, which
> I believe has been a major factor in the success of the project to
> date.  Fans of random anarchy may disagree, of course.  And if they
> do, I'm happy to provide them (so long as the license is free!) with
> web space to have a totally unmanaged project.  I think they'll get
> crap, though.

I agree that one should have a set of dedicated and involved editors, but
do these really have to be hired? The project is way past critical mass,
and I see a lot of very active contributors. A rotating voluntary post, or
a comittee perhaps? Once enough people participate in something (read:
once someone spends the effort and money to get something rolling, like
you did), people find all kinds reasons to chip in. Status, the feeling of
contributing to something worth wile, desire to influence - didn't ESR
make a list of these?

Anyway, my 10c is that both volunteer editorship, and if that fails,
random anarchy should be _tried_ before we (I hesitate to say "we" here,
as I'm new to the project) try advertisments.

That said, I think you could make back a lot of your investment in effort
and money by identifying Wikipedia more closely with Bomis and Nupedia. A
lot of people visit these pages.

-- Daniel Mikkelsen,
   Copyleft Software AS


subject: [Wikipedia-l] Updates

in_reply_to: <ILENJBCFHGHELEBFPPBGOECCCFAA.Magnus.Manske@epost.de>; from Magnus.Manske@epost.de on Sun, Feb 03, 2002 at 08:17:20PM +0100

body:
Magnus Manske wrote:
> The default number of changes on "Recent changes" was increased to 250,
> which can result in longer loading time. If it takes too long, add
> "&maxcnt=100" to the URL manually, for now. Use "List only new changes" for
> even faster loading.

Actually, I reduced the default just now to 50, because this seemed to be
causing extreme slowness.

I'm working on the "incorrect ip" bug.  The obvious fix didn't work.  I won't
bore everyone with the details, just Magnus and Brion.  :-)

I think perhaps it's getting to be time to set up a wikipedia-dev mailing list.
thoughts?


body:
What I meant is that the _author_ is the one who controls
the way links are transformed, not wiki software. That
way noone is going to come up saying "Wikipedia made
a link for me that I didn't intend to". With aliases,
the author could either use the aliased link or
make an escape of his own, and it's all under his control.

True, this requires a bit of thinking on behalf of the
author, but it also makes up for the defficiency in
ordering that was created by the elimination of
subpages.

Note finally, that if we don't do subpages, we go
all the way, link transformations included.

        Uri Yanover

----- Original Message -----
From: "Jan Hidders" <hidders at uia.ua.ac.be>
To: <wikipedia-l at nupedia.com>
Sent: Saturday, February 02, 2002 11:29 AM
Subject: Re: [Wikipedia-l] Re: yet another modest proposal to address

> From: "Uri Yanover" <uriyan_subscribe at yahoo.com>
> >
> > Unlike most others encyclopedias, Wikipedia is about
> > ease of editing too, and editing is made harder by the
> > abiguity in the convert-links-once solution. What I like
> > in the idea of aliases is the total control of the author
> > over what he links to. This won't be possible if Wiki
> > software is the thing that decides about the conversion.
>
> I would say that it is exactly the other way around. Tim's proposal is not
> ambiguous and does not require any searching for terms in name spaces.
> Your's, however, does.
>
> -- Jan Hidders
>
>
>
>
>
>


body:
From: "Uri Yanover" <uriyan_subscribe at yahoo.com>
>

> What I meant is that the _author_ is the one who controls
> the way links are transformed, not wiki software.

So did I. :-)

> That
> way noone is going to come up saying "Wikipedia made
> a link for me that I didn't intend to". With aliases,
> the author could either use the aliased link or
> make an escape of his own, and it's all under his control.

In some sense, but if you provide a list of #base pragma's  you have to know
which subject resides in which namespace if you want to determine in advance
how it is going to be expanded. In Tim's proposal this is not necessary.

> True, this requires a bit of thinking on behalf of the
> author, but it also makes up for the defficiency in
> ordering that was created by the elimination of
> subpages.

That deficiency is a feature, not a bug. What we want to avoid is that
writers qualify all terms of a certain knowledge space (fictional universe,
scientific field, ...)  as belonging to the corrsponding name space. Not all
terms in mathematics should be in the name space Mathematics, but only those
that have to be because the term has also a different meaning in other
fields. The same holds for article subjects from Middle Earth.

Kind regards,

-- Jan Hidders


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

> I just thought of a way to solve the problem without any subpage-like
> notations: [...]

I agree with Lee's arguments about this, but maybe it would still be a nice
idea that if somebody started editing a page for Frodo that did not exist
beforen then instead of the standard edit box text you get already a list of
links to pages with titles of the form "Frodo (Some Namespace)".

> Personally, I like Tims proposal better, but is has turned out that my
taste
> in these things is strangely uncorrelated with that of the rest of the
> wikipedia community ;)

FWIW, I still think Tim's proposal is the best one until now.

-- Jan Hidders


body:
On sab, 2002-02-02 at 16:58, wikipedia at epoptic.org wrote:
> Can someone take a look at http://www.wikipedia.com/wiki/RQ-1_Predator
> and tell me why the picture at the bottom isn't showing up?  If you
> click on the link, the picture will be displayed by itself, but it'd be
> nice to see it in the page itself.
>
> I've upload numerous other pictures with no problems....

There's a minor buglet in the image URL matching code that causes it to
reject URLs with dashes in them. I've put a fix in the CVS version; next
time Jimbo updates the running code it should work again.

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Updates

body:
Jimbo just uploaded the latest software version.

It contains some bugfixes, and a cached "Most Wanted" page (that doesn't
list articles starting with numbers). You'll have to refresh it manually
when too many articles are covered. But, that will take stress off the
system, making this page (and others) load a little faster.

The default number of changes on "Recent changes" was increased to 250,
which can result in longer loading time. If it takes too long, add
"&maxcnt=100" to the URL manually, for now. Use "List only new changes" for
even faster loading.

Thanks to Brion Vibber, there's now an option on your preferences page where
you can deactivate minor changes for the "Recent Changes" page. We hope it
works ;)

That's it for today, mostly. Brion has joined me at the "programmer's
staff", for which I am very grateful, as there's now someone else to blame
when the script dies ;)
Also, Jan Hidders has sent me a patch, and wants to continue working on the
code. (If you have a SourceFOrge account, I can give you CVS write access).

Magnus


from_name: Larry Sanger

subject: [Wikipedia-l] Login bug

body:
I'm sure someone has already reported this, but I just want to say that
it's really annoying that I can't login.  I can login for one screen, but
then when I move from the login screen to any other page, 130.94.122.xxx
comes up as my IP address, which (I'm guessing) it isn't.  I guess it
isn't, because if you'll take a look, 130.94.122.xxx has been editing a
whole bunch of pages.  I think those are actually different people.

Again, this must be old news (I'm going to start quickly replying to my
big e-mail backlog) but it's got to get fixed ASAP!

Larry
(Learning Perl, hopefully to learn PHP and make a big nuisance of myself)


from_name: David Jones

subject: [Wikipedia-l] Updates

body:
In message <20020203111108.K17681 at joey.bomis.com>, Jimmy Wales writes:
> I think perhaps it's getting to be time to set up a wikipedia-dev mailing lis
>>t.
> thoughts?

I think wikipedia-dev would be a good idea.  Sign me up please if you
create the list.


subject: [Wikipedia-l] "Trolls" on the Catalan Wikipedia

body:
On Tue, 8 Jan 2002, Tuxisuau wrote:

> By the way, i truly need help with the catalan wikipedia... see
> meta.wikipedia.com. Now i have trolls too writing stupid jokes instead
> of articles :(.

For this, I think we need to designate a *small* number of trusted
individuals to ban the IP numbers of the vandals, and we need to draw up
some broad *practical* guidelines about what a "bannable offense" is that
people on the non-English Wikipedias can use.  (*Please* let's not get
into a debate about the latter right now.  I and others who are more
interested in doing *work* for Wikipedia have more important things to do
with our time than get into such a debate--you know, things like getting
the website running.  At some point, we will have that debate, though.)

--Larry


subject: [Wikipedia-l] Re: wiki source cvs

body:
On 14 Jan 2002, Robert Bihlmeyer wrote:

> Larry Sanger <lsanger at nupedia.com> writes:
>
> > This, by the way, would be a great feature for Wikipedia to be able to
> > use; we'd certainly like Wikipedia articles to be convertable to DocBook
> > XML format.  That's what we decided we wanted to use as an XML DTD for
> > Nupedia, and surely we'd want to use it for Wikipedia too.
>
> I'm not convinced that DocBook is the best DTD for this kind of
> content. I like it very much for (computer-oriented) technical
> documentation, but for a more general topic?

The proposal was to use an augmented version of it; we'd add lots of new
elements of our own.  Please see the tools-l mailing list archives for
more information.  There's no point in going over this all again.

--Larry


subject: [Wikipedia-l] An idea...

body:
On Thu, 17 Jan 2002, Jimmy Wales wrote:

> Gareth Owen wrote:
> > At some point, some of the vandals are going to spot the "minor edit" button,
> > and realise it makes their vandalism harder to police.  Would it be too unwiki
> > to limit the option of "minor edit" to those logged in (most non-vandal new
> > users don't seem use it anyway).
>
> I think that's pretty reasonable.

I agree!  Have we done this?

> I personally have my preferences set to "show minor edits" and "show
> all changes".  This means that I see _everything_ on my Recent_Changes
> page.

Ditto--personally, I hardly pay attention to the difference at all.

Larry


subject: [Wikipedia-l] tarball

body:
On Thu, 24 Jan 2002, David Merrill wrote:

> I'm adding wikipedia stuff to the LDP site. I will definitely pass the
> result past you before any publication, to make sure you're happy with
> how I've implemented it - since the official "policy" has never been
> finally established.
>
> I hope you know by now I will do everything I reasonably can to make
> sure what I do benefits the Wikipedia and doesn't "fork" it in any
> meaningful way. I'll be driving traffic to you, for one thing, and
> won't do any actual "editing" on my site. Clicking the "Edit this
> page" link will do just what it says -- but will take you to the
> Wikipedia to do your edits. I think the LDP probably gets a lot more
> traffic right now than the Wikipedia does (6 million page views a
> month), so that should be a good thing for you.

Yes, and yes.  Sounds great!

> I do have a problem though, that you can help me with if you will.
> It seems the tarball is not being updated regularly.

...and, we need to check on this *again*, now that the new software is
uploaded.  I thought the tarball was being updated either daily, or
weekly.  It turns out that http://www.wikipedia.com/tarballs is currently
inaccessible (probably due to the software change, eh, or the server
switchover?).  Anyway, there should be a notice on wikipedia.com/tarballs
stating (accurately!) how often it's updated.  This is very important for
our credibility as an open content/free project.

> I want to
> download and process it regularly, probably weekly. An rsync feed
> would be really ideal, because it would minimize the bandwidth
> requirements. It's not a problem on my end, but it could be on yours.
>
> But if an rsync feed is not in the cards, at least update the tarball.
> Can you get the tarballs updated on a more regular basis? It should
> just take a few minutes to write a script and put it in
> /etc/cron.daily.

We *were* doing it regularly.  :-(

Larry


body:
> In some sense, but if you provide a list of #base pragma's  you have to
know
> which subject resides in which namespace if you want to determine in
advance
> how it is going to be expanded. In Tim's proposal this is not necessary.
...
> That deficiency is a feature, not a bug. What we want to avoid is that
> writers qualify all terms of a certain knowledge space (fictional
universe,
> scientific field, ...)  as belonging to the corrsponding name space. Not
all
> terms in mathematics should be in the name space Mathematics, but only
those
> that have to be because the term has also a different meaning in other
> fields. The same holds for article subjects from Middle Earth.

I don't think you understood my idea then. I didn't mean to use
aliaes mainly to categorize, but rather to _disambiguate_ (e.g.
[[root (botanics)]] vs. [[root (mathematics)]]). Because in most
fields there are very few internal disagreement in terms,
we should need very few alias pages.

[[Middle Earth]] is one of the few exceptions, where an alias
could be used to categorize (and therefore would point at all the
articles). The "normal" wiki articles won't need and won't use
aliases for anything but disambiguation.

            Uri


subject: [Wikipedia-l] Webby Awards

body:
Suggestion: nominate Wikipedia for the Webby Awards!

http://www.webbyawards.com/main/submit/index.html

--Larry


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

body:
I just edited the article now.  So is this problem solved?  By the way, I
linked [[calendar method]]--which redirects to [[natural family
planning]], but I can't edit the redirection!  (I think there should be an
article called "calendar method.")

--Larry

On Tue, 29 Jan 2002 wikipedia at epoptic.org wrote:

> 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
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>


body:
On Thu, 31 Jan 2002, 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.

What makes it true that "we have handled copyrights up to now for text
submissions" in this way (i.e., with this interpretation)?  As far as I
can tell, Axel, you were the first to insist, several months ago, that
this was the case.  If I recall correctly, Jimbo and I admitted that this
might be a valid interpretation.  For my part, I thought it was obvious
from the beginning that writers are donating text to the project, in order
for it to be distributed freely to the public at large.  While I can
certainly freely admit that there are other interpretations, what I can't
understand is why you would think another interpretation is so clearly the
correct one.  I don't think we've settled the issue.

By the way, Wikipedia might soon join Nupedia as part of a Nupedia
Foundation; that then would be the obvious holders of Wikipedia article
copyrights.

Larry


body:
On Thu, 31 Jan 2002, Axel Boldt wrote:

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

I think this is a really good idea, on first glance.

Larry


body:
Thanks, Chuck--interesting.

Larry

On Thu, 31 Jan 2002, Chuck Smith wrote:

> These statistics are for the two International
> Wikipedias (English and Esperanto).  I took into
> account duplicate listing for states, but not for
> countries, so the country stats may be a bit off.  I
> think you'll all find this interesting.  This took a
> while so don't expect me to do it too often...
>
> Enjoy!
> Chuck Smith
>
> --- English Wikipedia ---
>
> Listed in US: 85
> Actual in US: 79
> 43.9% in US
> Listed Most Times: 4 - Jimbo Wales (Alabama,
> California, Illinois, Indiana)
> Listed non-US: 101
> En - predominantly English speaking countries
> (8 Australia, 11 Canada, 1 Singapore, 1 South Africa,
> 22 United Kingdom, 79 United States)
> Actual in En: 122
> 67.8% in En
>
> Breakdown by Country:
>  1 Andorra
>  8 Australia
>  1 Bosnia and Herzegovina
> 11 Canada
>  1 Chile
>  2 Denmark
>  4 Finland
>  7 Germany
>  1 Hungary
>  2 Republic of Ireland
>  4 Israel
>  2 Italy
>  4 The Netherlands
>  1 Malta
>  1 Mexico
>  2 New Zealand
>  2 Norway
>  5 Poland
>  2 Portugal
>  1 Russia
>  1 Singapore
>  1 South Africa
>  4 Spain
>  9 Sweden
>  1 Switzerland
>  1 Turkey
> 22 United Kingdom
>
> Breakdown by US State
>  1 Alabama
>  2 Alaska
>  3 Arizona
>  0 Arkansas
> 19 California
>  1 Colorado
>  2 Connecticut
>  0 Delaware
>  1 District of Columbia
>  0 Florida
>  1 Georgia
>  0 Hawaii
>  0 Idaho
>  3 Illinois
>  2 Indiana
>  2 Iowa
>  0 Kansas
>  2 Kentucky
>  1 Louisiana
>  0 Maine
>  2 Maryland
>  4 Massachusetts
>  3 Michigan
>  2 Minnesota
>  0 Mississippi
>  1 Missouri
>  0 Montana
>  0 Nebraska
>  2 Nevada
>  0 New Hampshire
>  1 New Jersey
>  0 New Mexico
>  8 New York
>  3 North Carolina
>  0 North Dakota
>  2 Ohio (!)
>  0 Oklahoma
>  1 Oregon (!)
>  1 Pennsylvania
>  0 Puerto Rico
>  0 Rhode Island
>  0 South Carolina
>  0 South Dakota
>  1 Tennessee
>  3 Texas
>  0 Utah
>  0 Vermont
>  2 Virginia
>  4 Washington
>  0 West Virginia
>  0 Wisconsin
>  0 Wyoming
>  5 Nomadic and shy (includes Larry Sanger, but we know
> where you live...*evil laughter*)
> 85 Total
>
> --- Esperanto Wikipedia ---
>
> Actual in US: 7
> 0% living in predominantly Esperanto speaking country
> :)
> Actual non-US: 10
> 41.2% in US
> 41.2% in En
>
> 1 Brazil
> 1 Catalonia
> 1 China
> 1 France
> 1 Japan
> 1 Polland
> 2 Russia
> 1 Spain
> 7 United States
>
> =====
> 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
>
> _________________________________________________________
> Do You Yahoo!?
> Informaci?n de Estados Unidos y Am?rica Latina, en Yahoo! Noticias.
> Vis?tanos en http://noticias.espanol.yahoo.com
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>


body:
I'm inclined to think #1 is best.

On 1 Feb 2002, Brion Vibber wrote:

> In the 'Wikipedia:Bug reports' page, it came up that someone's trying to
> make an article titled "β-cyclodextrine", ie using the HTML
> character entity for the greek letter beta (β).
>
> Currently the code makes a mess of attempts to do this; it can be sorted
> out, but the question is how *should* it behave?
>
> Possibility one: Ampersands in general and HTML entities in specific
> should not work in article titles; links to such pages will be
> considered invalid. (I believe this is how it worked on the old
> software.) The user should probably instead title that page
> "Beta-cyclodextrine".
>
> Possibility two: Ampersands will be escaped; HTML entities will not work
> as such in article titles, but the name typed as "β-cyclodextrine"
> would appear as typed, with an ampersand, the word "beta" and a
> semicolon. The user should probably instead title that page
> "Beta-cyclodextrine", but might well call a page "HTML entity β".
>
> Possibility three: HTML entities should work in article titles. Thus the
> name typed as "β-cyclodextrine" will appear in body text and the
> page title with a beta character. For "HTML entity β" to display as
> intended the wikipedian must type "HTML entity &beta;".
>
> Possibility four...?
>
> -- brion vibber (brion @ pobox.com)
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>


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

body:
(re: edit conflicts with [[Natural family planning]])
On lun, 2002-02-04 at 14:39, Larry Sanger wrote:
> I just edited the article now.  So is this problem solved?  By the way, I
> linked [[calendar method]]--which redirects to [[natural family
> planning]], but I can't edit the redirection!  (I think there should be an
> article called "calendar method.")

You can edit a redirect by clicking on the "(redirected from [[X]])"
link at the top of the page you've been redirected to. Well, you can
when the script is working properly... at the moment it's a broken link,
but this should be fixed later today when Jimbo applies the latest
fixes.

As a temporary solution, you can manually construct a working link:
http://www.wikipedia.com/wiki.phtml?action=edit&title=Calendar_method

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Modest proposals

body:
I've just finished going over the enormous set of interesting e-mails
about the problem re the "Middle Earth" subpages.  I just have a few
notes.  I am sure I haven't caught all the issues here but hopefully I've
said something useful on some of the important ones.

(1) There were *several really good* reasons not to have subpages.  Not
just one or two.  While I did concede that fictional worlds were prime
candidates (*if* any were) for subpage treatment, I did *not* concede that
the fact that they're useful for that purpose means that we should have
them.  In fact, the mere fact that subpage functionality existed meant
that subpages were used in all sorts of different ways.

(2) Those who have said that there's no difference between [[Foo/Bar]] and
[[Bar (Foo)]] have obviously not used subpages very much.  There's a huge
difference, and this has been discussed in depth before.

(3) I agree with Lee, Jimbo, Vicki, and I think a few others who
emphasized that it is very important to preserve the ease of editing
Wikipedia articles.  Tim's solution has the distinct advantage of making
it no more difficult to edit articles, while preserving keystrokes.

(4) When we think about policy options, it often helps to consider
carefully what problem we're trying to solve, and to make sure that our
solution is the most elegant solution to that problem.  It is not entirely
clear to me what the problem is, in this case.  Originally, Uri Yanover
said:

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

This suggests that the problem is *just* one involved in typing long page
titles in order to create a link, but the solution offered by Uri solves a
lot more than that, so I'm not sure this is exactly the problem he wants
to solve.

(5) *If* the problem is just that, then I'd agree with those who say that
Tim's solution is very neat and elegant, and we should move forward with
it.  We should probably also write a script that would allow sysops or
trusted users to rename large numbers of pages (and links) formatted
[[Foo/Bar]] as [[Bar (Foo)]].

(6) I see no particularly good reason why the name of an article about
Elrond needs to be named anything other than [[Elrond]] or [[Elrond
Peredhil]].  The whole point of so-called disambiguating parentheses (I
wrote a little column about these last year) is to disambiguate, not to
categorize.

(7) "Hear, hear" to Lee, or whoever it was, who said that article
structure *should* be flat.  This is a good thing!

Larry


body:
From: "Uri Yanover" <uriyan_subscribe at yahoo.com>
> ...
> > That deficiency is a feature, not a bug. What we want to avoid is that
> > writers qualify all terms of a certain knowledge space (fictional
> > universe,
> > scientific field, ...)  as belonging to the corrsponding name space. Not
> > all
> > terms in mathematics should be in the name space Mathematics, but only
> > those
> > that have to be because the term has also a different meaning in other
> > fields. The same holds for article subjects from Middle Earth.
>
> I don't think you understood my idea then. I didn't mean to use
> aliaes mainly to categorize, but rather to _disambiguate_ (e.g.
> [[root (botanics)]] vs. [[root (mathematics)]]).

Oh, I am quite convinced that this is what *you* mean to use them for. But
the important question is what the consequences are if many other people are
going to use it as well. That depends on some details that you haven't
explained yet. You could reduce the risc as follows:
- introduce special notation for links that have to be looked up in the name
space (so [[blah]] behaves normalla and [[~blah]] is looked up in the name
spaces
- if  a link [[~blah]] is not found in the name spaces then it is treated as
the link [[blah]].

Kind regards,

-- Jan Hidders


subject: [Wikipedia-l] Modest proposals

body:
Please forgive my copyediting...I can plead that I've been ill for the
last several days.  :-)

Larry (who is happily connected via cable modem once again!)


from_name: Kurt Jansson

body:
Hello!

>On Sat, 2 Feb 2002, Jimmy Wales wrote:
>> 3.  The major remaining expense is Larry's editorial leadership,
which
>> I believe has been a major factor in the success of the project to
>> date.  Fans of random anarchy may disagree, of course.  And if they
>> do, I'm happy to provide them (so long as the license is free!) with
>> web space to have a totally unmanaged project.  I think they'll get
>> crap, though.

This sounds a bit strange if you read it with the national wikipedias in
mind. At least the German Wikipedia doesn't have an editorial leadership
and is IMHO quite good described by "random anarchy". But it's far away
from crap.

> Anyway, my 10c is that both volunteer editorship, and if that fails,
> random anarchy should be _tried_ before we (I hesitate to say "we"
here,
> as I'm new to the project) try advertisments.

I don't like advertisments, too. They don't annoy me, because I have a
filter program running, but I think they'll lower the reputation (or
does "prestige" fit better?) of the project, especially to newcomers.
But I don't want Larry to loose his job! :-) So affiliate links to
bookstores would be okay for me.

Bye,
Kurt


body:
> Oh, I am quite convinced that this is what *you* mean to use them for. But
> the important question is what the consequences are if many other people
are
> going to use it as well. That depends on some details that you haven't
> explained yet. You could reduce the risc as follows:
> - introduce special notation for links that have to be looked up in the
name
> space (so [[blah]] behaves normalla and [[~blah]] is looked up in the name
> spaces
> - if  a link [[~blah]] is not found in the name spaces then it is treated
as
> the link [[blah]].
>
> Kind regards,
>
> -- Jan Hidders

Well, while aliases could be abused (as nearly everything on this planet),
I don't really see a reason why people would bother to create new topics
with names like [[Mathematics/Analysis/Zeta function]] and then making
the aliases for them when they could just do [[Zeta function]]. We could,
of course, do explicit alias escaping (~) but frankly I don't think it's
necessary. This is particularly so because more than 20,000 topics
have been created so far without any categorization and transfering
them all would be next to impossible.

Sincerely yours,
            Uri Yanover


body:
In message <Pine.LNX.4.30.0202041503460.28975-100000 at ross.bomis.com>, Larry San
ger writes:
> On Thu, 31 Jan 2002, 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.
>
> What makes it true that "we have handled copyrights up to now for text
> submissions" in this way (i.e., with this interpretation)?  As far as I
> can tell, Axel, you were the first to insist, several months ago, that
> this was the case.  If I recall correctly, Jimbo and I admitted that this
> might be a valid interpretation.  For my part, I thought it was obvious
> from the beginning that writers are donating text to the project, in order
> for it to be distributed freely to the public at large.  While I can
> certainly freely admit that there are other interpretations, what I can't
> understand is why you would think another interpretation is so clearly the
> correct one.  I don't think we've settled the issue.

The interpretation of "I, as author, hold the copyright and grant a
license for wikipedia to use it under Gnu FDL" has always been my
interpretation of the intellectual property transfer.  I never thought I
was donating text to the project when I wrote it.

One reason I might think this is that in UK copyright law (See
Copyright Designs and Patent Act 1988, [CDP]), "an assignment of copyright
is not effective unless it is in writing signed by or on behalf of
the assignor" (section 90 CDP).  I haven't done that, so in my mind, I
still own the copyright; and in law too I think.

I think the view that wikipedia holds the copyright is extremely
worrying.  If that were the case then there is nothing to stop wikipedia
making future versions closed.  The Gnu FDL only restricts licensees
that don't own the copyright, the copyright owner can do what they like.

I would stop writing for wikipedia if it turned that they owned
copyright in the articles.  I know wikipedia has a database copyright,
that doesn't worry and seems only fair.

Cheers,
 drj


from_name: Mark Christensen

body:
Axil's interpretation strikes me as the standard interpretation for those
writing free software.  I retain the copyright the code I write, and license
it under the GPL or some other license, but also maintain the right to
relicense it under a revised version of the GPL, a BSD style license, or any
other agreement I choose.

In many cases this standard practice is amended to include the assignment of
copyright to the Free Software Foundation, or some other organization which
I trust with the ability to relicense my code under whatever license they
choose.  As long as an entity retains copyright, they will be able to
release the copyrighted material under whatever license they choose.  Not
assigning copyright is therefore a protection against undesirable license
changes, but at the very least it is common practice to view the assignment
of copyright as a separate transaction from submitting code under a
particular license.

Legally, if you want us to assign copyright to you, I think you need to
change the wording of the submission text, and add some verbiage to the top
of your license page.

I am not a lawyer, but this is my understanding of the current situation,
and can easily be confirmed by consulting a lawyer with some experience with
free software, or by looking up  stories on the subject at www.lwn.org, or
looking into the faq on why you should assign copyright to the FSF at
www.gnu.org.

Yours
Mark

-----Original Message-----
From: Larry Sanger [mailto:lsanger at nupedia.com]
Sent: Monday, February 04, 2002 6:10 PM
To: wikipedia-l at nupedia.com
Subject: Re: [Wikipedia-l] File upload Copyright notice

On Thu, 31 Jan 2002, 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.

What makes it true that "we have handled copyrights up to now for text
submissions" in this way (i.e., with this interpretation)?  As far as I
can tell, Axel, you were the first to insist, several months ago, that
this was the case.  If I recall correctly, Jimbo and I admitted that this
might be a valid interpretation.  For my part, I thought it was obvious
from the beginning that writers are donating text to the project, in order
for it to be distributed freely to the public at large.  While I can
certainly freely admit that there are other interpretations, what I can't
understand is why you would think another interpretation is so clearly the
correct one.  I don't think we've settled the issue.

By the way, Wikipedia might soon join Nupedia as part of a Nupedia
Foundation; that then would be the obvious holders of Wikipedia article
copyrights.

Larry

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


from_name: lcrocker at nupedia.com

subject: [Wikipedia-l] Proposed policy on foreign characters

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


body:
Thanks a lot for this, Lee!

Larry

On Tue, 5 Feb 2002 lcrocker at nupedia.com wrote:

> Over the last year, we have had many discussions about the various
> ways foreign characters are used, and I think we reached consensus
> on many of the issues, but those discussions are a bit scattered.
> I think a simple, organized, documented policy on these issues is
> important to help all the newcomers, and also to serve as a spec
> for fixing the new software to properly support and enforce those
> choices.  I was going to do some of that code myself, but I thought
> I should make sure I had a correct understanding of what should
> happen first.
>
> Please read the proposal at
> http://meta.wikipedia.com/wiki.phtml?
> title=Proposed_Wikipedia_policy_on_foreign_characters
> and comment.
>
>
> 0


subject: [Wikipedia-l] Copyrights

body:
It is my understanding that copyright to everything in Wikipedia
belongs to the contributors, who are releasing it under the GNU FDL.
Wikipedia has a copyright on the _compilation_, which means something
very specific under copyright law, and we release the _compilation_
under the GNU FDL.

The downside of this arrangement is that if someone takes portions of
wikipedia and does something counter to the GNU FDL, we are not in a
position to defend it.  That's not a good thing.  I suppose that if
that were to happen, and if I were to be in the mood to defend it, we
could ask contributors to those specific sections to _at that time_
sell us their copyright for a dollar, so that we could pursue the
infringers in court.

The upside of this arrangment, if there is one, is that even Wikipedia
can't make the content proprietary.

Another potential downside to this arrangement, and I'm not sure how
important this one is, is that many overly cautious potential
licensees of the content will hesitate to license it absent a single
unified ownership.  For example, Yahoo might not want to use Wikipedia
content as the basic for Encyclopedia Yahoo, if they were to create such
a thing, out of concern about there not being a single licensing authority.

--Jimbo


from_name: Tim Chambers

subject: [Wikipedia-l] Modest proposals

body:
I haven't seen a need to write again since making my proposal, but today Uri
Yanover <uriyan_subscribe at yahoo.com> wrote:

>What I don't like about Tim's idea is the fact that it converts
>the link automatically basing on parsing of the article title.

My proposal is archived at
http://www.nupedia.com/pipermail/wikipedia-l/2002-January/001230.html

There it can be seen that in addition to the simple solution that does
convert links based on the article title, I did include Uri's idea. To
summarize:

#base [[Fantasy Fiction]]

[[/elves]]

could 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 given 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.

Uri's original #base idea is archived at
http://www.nupedia.com/pipermail/wikipedia-l/2002-January/001220.html. He
also proposed an Alias: namespace
(http://www.nupedia.com/pipermail/wikipedia-l/2002-January/001218.html), but
the features are very similar.

The key differences between my proposal and his are:

1. I propose a solution that converts text during save, while Uri proposed
adding to the wikipedia's source syntax.
2. I propose the disambiguating syntax -- [[title (context)]] -- while Uri
proposed subpage syntax -- [[context/title]].

However, Uri also said yesterday in
http://www.nupedia.com/pipermail/wikipedia-l/2002-February/001288.html that
he "didn't mean to use aliaes mainly to categorize, but rather to
_disambiguate_ (e.g. [[root (botanics)]] vs. [[root (mathematics)]])." So I
assume he's flexible on #2.

I take it that there's consensus on the part that deals with link
conversion.

So what about the #base idea?

<>< Tim


subject: [Wikipedia-l] Copyrights

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

> It is my understanding that copyright to everything in Wikipedia
> belongs to the contributors, who are releasing it under the GNU FDL.

I thought *Bomis* released *the contents of Wikipedia* under the GNU FDL,
in any case; so then each individual contributor first must release their
contributions to Bomis under the same license?  This seems to be what
several of you have been getting at.

I am not convinced.  I'll have to write more later, when I have time.

Larry


from_name: Jan Hidders

subject: [Wikipedia-l] Updates

body:
From: "David Jones" <djones at zoonami.com>
>
> I think wikipedia-dev would be a good idea.  Sign me up please if you
> create the list.

Me too. :-) It would be a good way to avoid that The script tech talk page
becomes too cluttered with duscussions.

-- Jan Hidders


subject: [Wikipedia-l] Modest proposals

body:
> (4) When we think about policy options, it often helps to consider
> carefully what problem we're trying to solve, and to make sure that our
> solution is the most elegant solution to that problem.  It is not entirely
> clear to me what the problem is, in this case.  Originally, Uri Yanover
> said:
>
> >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]]"
>
> This suggests that the problem is *just* one involved in typing long page
> titles in order to create a link, but the solution offered by Uri solves a
> lot more than that, so I'm not sure this is exactly the problem he wants
> to solve.

I used to think so when I'd written that post, but I no longer do.
Having considered the subject for long enough, I reached the
concept of aliases (more details in the mailing list). The general
usefullness of aliases is for disambiguating (that is, making [[root]]
point at [[root (mathematics)]] on pages concerning with algebra
and at [[root (botanics)]] at pages concerning with plants).

However, the other useful thing that could be done with aliases
is facilitating the editing of pages like [[Middle Earth]], so that
ineed [[Elrond]] on an a page that uses aliases becomes
[[Elrond (Middle Earth)]]. But this use is secondary, and
confined only to pages that describe a specific universe.
The fact that the vast majority of the other articles does not
use subpaging indicates that probably there won't be too much
abuse of aliasing in this way.

What I don't like about Tim's idea is the fact that it converts
the link automatically basing on parsing of the article title.
But not only that would be inconvenient (making it more
difficult to edit the article afterwards and sometimes creating
links that the author doesn't want), it would also be out
of policy, as it would essentially be a substitute for subpages.

Sincerely yours,
            Uri Yanover


subject: [Wikipedia-l] Copyrights

body:
>> It is my understanding that copyright to everything in Wikipedia
>> belongs to the contributors, who are releasing it under the GNU FDL.

> I thought *Bomis* released *the contents of Wikipedia* under the GNU FDL,
> in any case; so then each individual contributor first must release their
> contributions to Bomis under the same license?  This seems to be what
> several of you have been getting at.

I think the safest thing would be to clarify so that it says the various
authors own copyright. The rights granted by the FDL are supposed to be
enough for everyone who wants to use the encyclopedia, so why not Bomis et
al...

If copyright "had" (I suspect somebody would fork to a degree) to be
handed over, it should be to a non profit organization.

I think this is very important.

-- Daniel Mikkelsen,
   Copyleft Software AS, Norway


subject: [Wikipedia-l] Re: Modest proposals

body:
> #base [[Fantasy Fiction]]
>
> [[/elves]]
>
> could be translated into this:
>
> See also: [[Fantasy Fiction]].
>
> [[elves (Fantasy Fiction)|elves]]

My apologies for not understanding you perfectly, but it still
would act as I've said if you don't give it a #base.

> The key differences between my proposal and his are:
>
> 1. I propose a solution that converts text during save, while Uri proposed
> adding to the wikipedia's source syntax.
> 2. I propose the disambiguating syntax -- [[title (context)]] -- while Uri
> proposed subpage syntax -- [[context/title]].

As for #2, I no longer support subpage syntax (as I've said, the
parentheses seem to me more aesthetic and helpful for an
encoclopedia).

As for #1, what I dislike in conversion during save is the fact
that _editing afterwards_ is still difficult (and I truly see no
gain in making this sort of pre-processing - it could be done
in runtime just as well). The renaming rules seem quite
complicated and implicit to me. And finally, I have doubts
if it is wise to build a link-resolving AI using regular
expressions if we can have the authors make the same
decisions explicitly.

Sincerely yours,
                    Uri Yanover


subject: [Wikipedia-l] MySQL dump available

body:
Can someone tell me what I need to do here?

I think Magnus already told me, but I can't find it now.  :-(

Jan Hidders wrote:

> Is there a dump of the Wikipedia tables available somewhere? I would like to
> do some testing on a database with a realistic size.
>
> -- Jan Hidders
>
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


subject: [Wikipedia-l] Re: Modest proposals

body:
From: "Uri Yanover" <uriyan_subscribe at yahoo.com>
>
> As for #1, what I dislike in conversion during save is the fact
> that _editing afterwards_ is still difficult (and I truly see no
> gain in making this sort of pre-processing - it could be done
> in runtime just as well).

The gain is that the author has at edit time full control over where the
link points to. With runtime lookup a link might change because a certain
term was added to a certain namespace.

-- Jan Hidders


subject: [Wikipedia-l] Modest proposals

body:
From: "Tim Chambers" <tbchambers at yahoo.com>
>
> So what about the #base idea?

To be honest, it's the part I like the least. I believe that the other part
of your proposal probably already covers 90% of the cases where you would
like a shortcut for a namspace, and it is easy to implement it in an
efficient way. The #base idea is a bit harder to implement and would add
some complexity to the parser which is at the moment already far too slow,
big and complicated, and also still has a lot of bugs. After we have gotten
the parser into shape, maybe then we can start thinking about adding such
features, but even then I would try to keep the code as efficient and simple
as possible.

-- Jan Hidders