from_name: limholt at excite.com

body:
 --- On Tue 09/02, Magnus Manske < magnus.manske at web.de > wrote:

"Daniel Mayer wrote: No separate project needed (a sub-project of Wikibooks might be needed though)."
There's no such thing as a sub-project, at least not on the software level. Either it is one project, or two. Two projects could be accessing the same database, but I don't see a reason for that, as we'd have two interfaces to show and do exactly the same thing. Two projects could be *presented* as project and subproject, though. If we call the two projects wikibooks.org and wikisources.org, or rather textbooks.wikibooks.org and sources.wikibooks.org, doesn't make a difference, at least not to me.

_______________________________________________

I didn't read Daniel's the same way you did. I assumed his 'sub project' referred to a kind of effort like the countrty or biography template ''projects'' within Wikipedia. If you look at his comments that way they make a lot more sense. A common wiki, data store, and set of software techniques that support a variety of books with somewhat different natures.

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!


list: wikipedia-l

source: pipermail-mbox

from_name: Toby Bartels

subject: [Wikipedia-l] Re: Sysop ability to ban logged in users

body:
Tomasz Wegrzanowski wrote:

>That's idiotic. What for is a ban where one can "unban oneself" ?

For nothing, obviously.  So why are we worrying about it?

What would be, if not idiotic, then at any rate a waste of effort,
would be to alter the natural code for blocking user names
so that it checks that whether the user names are admins first.

You make a fair case that blocking admins for real is a bad idea;
but since that can't happen anyway, why bother altering the code?

-- Toby


from_name: Tomasz Wegrzanowski

subject:
[Wikipedia-l] Re: Sysop ability to ban logged in users;
	Undelete bug fixed

body:
On Mon, Sep 01, 2003 at 03:20:07PM -0700, Toby Bartels wrote:
> Steve Vertigum wrote:
>
> >Still maybe cung is right --in case this isnt already
> >on the plate -- A routinely upadted shortlist of sysop
> >ips for a check against a "ban username" function --
> >might be appropriate.  With each login, the each user
> >ip is updated. Only rarely might a conflict arise due
> >to a same-ip range for dynamic ip sysops and potential
> >problem user.
>
> We shouldn't have to worry about sysops at all.
> A banned admin can always unban themself.

We have already seen this on IRCNet.
Giving sysops power to ban sysops is going to lead
to a lot of problems.

So could you:
* forbid sysops block other sysops
* don't install it on any Wikipedia but (maybe) English


list: wikitech-l

from_name: Daniel Mayer

subject: [Wikitech-l] Michael evidence?

body:
Jimbo wrote:
>Through the work of a user who I won't name because
>I'm not sure if he wants to be anonymous on this,
>I now have a potential contact in the right
>department at AOL who may be sympathetic to our
>plight with respect to Michael.

A good place to start is
http://www.wikipedia.org/wiki/User:Michael which lists
all of Michael's pseudonyms and know IP
address/ranges. IPs for the user names will have to be
retrieved by somebody with developer access.

--mav

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


from_name: Richard Grevers

subject:
[Wikitech-l] Re: Sysop ability to ban logged in users;
	Undelete bug fixed

body:
On Tue, 02 Sep 2003 11:40:17 +1000, Tim Starling
<ts4294967296 at hotmail.com> gave utterance to the following:

> Allan Crossman wrote:
>>> May I suggest one more piece of logic?
>>> An IP block is automatically released if a non-banned user logs in on
>>> it.
>>> (which means that the IP has been reassigned away from the vandal)
>>
>>
>> Hrmm. I thought part of the joy of IP blocks was that vandal user
>> accounts can't come in from that IP either. I've used this at least
>> once to ban a logged-
>> in vandal.
>>
>> A vandal shouldn't be able to escape the block by creating new user
>> accounts (or falling back to user accounts that already exist)
>
>
> Yes, I don't think it would be a good idea to have them automatically
> released. It's far more likely that it's a banned user trying to
> circumvent the system than another person altogether.
>
Which is why I said non-banned. Presumably the system knows which
user-names are banned.
I guess  have in mind that there should be two levels of banning
usernames: permanent, and short term (maybe 24 or 48 hours cooling off
time, with a 3 strikes policy).

And at an even milder level, we could maybe have an "educate" function:
When reverting a change by a first-timer, the IP gets stored and the next
editing attempt by that IP gets redirected to an education page WITHOUT a
24-hour block.

--
Richard Grevers
Between two evils always pick the one you haven't tried


from_name: Anthere

subject: [Wikipedia-l] Re:logo pb

body:
Message: 4
Date: Tue, 02 Sep 2003 10:08:09 -0400
From: Vicki Rosenzweig <vr at redbird.org>
Subject: Re: [Wikipedia-l] Re:logo pb
To: wikipedia-l at Wikipedia.org
Message-ID:
<5.2.0.9.1.20030902100624.02f39c90 at smtp.panix.com>
Content-Type: text/plain; charset="us-ascii";
format=flowed

At 05:07 AM 9/2/03 -0700, Anthere wrote:
>I take the opportunity to report - as an ambassador -
>the displeasure of some author, who feel there is
>applied pressure to direct their creativity to
another
>direction than is their wish, and officially ask me
to
>help him as my english ability is better than his.
(<-
>this is a neutral report)
>
>In my opinion, any logo proposition and any logo
>versioning is a "free-of-choice" work, and
>"free-to-display" work (except for
>sex-race-color-political-religion related works
>perhaps, though this might be controversial), and any
>pressure on authors is out of bounds. Please. Thanks.
>(<- This is a personal opinion. Please and thanks
mean
>please and thanks, and this part of my message is not
>for you Tillwe dear :-))

My understanding is that artists are/were welcome to
submit
any logo they wanted, and then everyone--including
artists--are
encouraged to vote for logos we think are appropriate.

I'm not sure I understand the complaint.

--
Vicki Rosenzweig
vr at redbird.org
http://www.redbird.org

-------

http://meta.wikipedia.org/w/wiki.phtml?title=Image_talk:Paullusmagnus-logo_(small).png&diff=14265&oldid=14264

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


from_name: Till Westermayer

subject: AW: [Wikipedia-l] Re:logo pb

body:
Hi,

134 to 137 were put on the voting sheet after the deadline, too, I believe.
This not being a problem seemed like a good example of WikiLove, in my eyes.
See [http://meta.wikipedia.org/w/wiki.phtml?title=International_logos_(126-150)&oldid=12065]
for example of voting in place without them.

Bye, Till we *)

>-- Original Nachricht --
>Date: Tue, 2 Sep 2003 05:07:16 -0700 (PDT)
>From: Anthere <anthere6 at yahoo.com>
>To: wikipedia-l at Wikipedia.org
>Cc:
>Subject: [Wikipedia-l] Re:logo pb
>Reply-To: wikipedia-l at Wikipedia.org
>
>
>Till Westermayer till at tillwe.de
>Tue Sep 2 08:55:13 UTC 2003
>
>    * Previous message: [Wikipedia-l] Gaps in 1.0
>    * Messages sorted by: [ date ] [ thread ] [
>subject ] [ author ]
>
>. . . . . . . . . . . . . . . . . . . . . . . . . . .
>till we *) . . .
>
>Hi Anthere,
>
>there is no logo 138?!
>
>Till
>
>
>Hi Tillwe
>
>How observant of you :-) (<- this is meant to be a
>very friendly and cheerful irony)
>
>Logo 138 (or rather logoS 138) were added after the
>deadline, hence were removed by our foreman (err...the
>organizer in case this word hold meanings I am not
>aware of).
>
>One of the logo 138 had the same name than another,
>hence it replaced it. The previous saved state was
>restored.
>
>Logos 138 were kat-related logo. Very nice artwork,
>but I fear they would not have been fit as logos
>anyway, so  it is sad for the author, but won't impact
>the final choice.
>
>Cheers Tillwe
>
>
>I take the opportunity to report - as an ambassador -
>the displeasure of some author, who feel there is
>applied pressure to direct their creativity to another
>direction than is their wish, and officially ask me to
>help him as my english ability is better than his. (<-
>this is a neutral report)
>
>In my opinion, any logo proposition and any logo
>versioning is a "free-of-choice" work, and
>"free-to-display" work (except for
>sex-race-color-political-religion related works
>perhaps, though this might be controversial), and any
>pressure on authors is out of bounds. Please. Thanks.
>(<- This is a personal opinion. Please and thanks mean
>please and thanks, and this part of my message is not
>for you Tillwe dear :-))
>
>
>
>
>
>__________________________________
>Do you Yahoo!?
>Yahoo! SiteBuilder - Free, easy-to-use web site design software
>http://sitebuilder.yahoo.com
>_______________________________________________
>Wikipedia-l mailing list
>Wikipedia-l at Wikipedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikipedia-l

________________________________________
Mehr Power f?r Ihre eMail - mit den neuen Leistungspaketen bei http://www.epost.de


from_name: Alex R.

subject: [Wikitech-l] Update to gfdl copyright notice needed

body:
Jimmy Wales jwales at bomis.com
Tue Sep 2 10:27:28 UTC 2003 said:

Marco Krohn wrote:
> > On another front, it is often alleged that _true_ "fair use" of some
> > non-FDL material (both text and images) _is_ compatible with the FDL.
>
> I might missed that, but what does "true fair use" mean?

>Here's some excellent reading material:
>
http://fairuse.stanford.edu/Copyright_and_Fair_Use_Overview/chapter9/9-c.html
The whole site is excellent.

>As you read over the case summaries, you'll begin to get a sense of
>how puzzling this doctrine can be.

Yes, that is true, but is anyone really going to sue Wikipedia because
a samll snippet of text or a photo that is informational is found on the
web site?   And anyway, what are the damages; at most the statutory
damages; after reading all those cases Jimbo I am sure you can
convince a federal judge that Wikipedia should have a fair use defense.

>I think it's pretty clearly that there will be lots of cases where
>*we* are on solid ground, but where potential re-users of our content
>will not be.  I think that's problematic.

Two points, first:as regards to fair use of text that is not attributed;
it probably gets edited in subsequent revisions; so when does a
collaborative text that is being changed constantly become a new text?
That would make an interesting case; might even get Wikipedia's
name into all the copyright law treatises; it is sort of like saying you
cannot make photocopies of something when you are writing a paper;
as long as the final paper is not a copy any information that was in
the photocopies does go into your paper.

Second: Is it implied that Wikipedia gives no guarantee regarding
the material posted on Wikipedia?  It is true that for pictures there is an
affirmation (more reason that Wikipedia is not responsible as their are
reliance issues there).  Perhaps  Stallman and Lessig (and I have not
discussed that with them) see no problem with fair use stuff because
most users of the GNU FDL include warranty disclaimers as the FDL
provides for them in the last paragraph of Section 1.   If subsequent
users have a problem they only have to remove the text or image;
as far as downstream distribution is concerned, one only has to include
a disclaimer regarding possible infringement. It makes perfeect sense
to disclaim copyright warranties in a wiki environment. Except for
the deletion poliicy there is no guarantee that Wikipedia is copyright
infringement free; it is the contributors that must guarantee that
not, Wikipedia; the more I think about it the more I feel that this is
the the best way to deal with the copyright/privacy rights issues on a
wiki.

There has been a recent related discussion here:

http://www.wikipedia.org/wiki/Wikipedia_talk:Votes_for_deletion/copyvio

Maybe adding a disclaimer is a good idea; anyway trying to keep
Wikipedia copyright pure is not a bad idea either.  BTW why is there not a
little check box on the edit pages that is similar to the check box on
image upload pages giving an affirmation about the copyright of submitted
text?

Quaere: Is it possible to creat a function to delete parts of a page's
history
if the history  is found to have an infringement on it. That would be a
way to clean up the many infringements that are posted on previous page
versions (which are also listed as being released under the GFDL); though
if the fair use policy applies to the current versions; there is even a
stronger
argument for fair use applying to

alex756 (remember, even though IAAL this is NALO (not a legal opinion).


body:
On Tue, Sep 02, 2003 at 12:00:04PM -0400, The Cunctator wrote:
> > From: Tomasz Wegrzanowski
> >
> > We have already seen this on IRCNet.
> > Giving sysops power to ban sysops is going to lead
> > to a lot of problems.
> >
> > So could you:
> > * forbid sysops block other sysops
> > * don't install it on any Wikipedia but (maybe) English
>
> They're not analogous situations. Banning on IRC means no ability to
> participate--a sysop can't easily unban himself. Banning on Wikipedia
> means only blocking the ability to edit pages--a sysop can easily unban
> himself.
>
> That is, the ability to ban WP sysops is only cosmetic.

That's idiotic. What for is a ban where one can "unban oneself" ?


from_name: Brion Vibber

subject: [Wikitech-l] software for making maps

body:
On Tue, 2 Sep 2003, Tomasz Wegrzanowski wrote:
> Also, not having everything in one edit box is quite inconvenient. It
> already annoys me that Upload Image isn't linked from an edit page.

It should be right there in the sidebar. Potentially a more prominent link
could be added?

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Gaps in 1.0

body:
. . . . . . . . . . . . . . . . . . . . . . . . . . . till we *) . . .

Hi Fred,

>on 9/1/03 12:12 PM, Magnus Manske at magnus.manske at web.de wrote:

>> As we are slowly wading through the usual swamp that is
>> consensus ;-) towards Mordor, eh, wikipedia release 1.0, I was
>> wondering: Is there any (more or less) organized effort
>> * to find the gape wikipedia has, compared to *other*
>> encyclopediae, and * to fill them
>> Is there a (machine-readable?) list of all entries in
>> Britannica, Encarta, or any other major encyclopedia?
>>
>> I remember putting lots of possible encyclopedia topics on the
>> 'pedia, but wer'de probably past that stage anyway (had a little
>> more than 100.000 entries, IIRC).
>>
>> Magnus

>There are a number of indispensible but mundane topics which
>because they are not that interesting to research remain undone,
>or incompletely done.

For example, I'd guess that [[List of sociologists]], which is half red
at Wikipedia, would be much bluer in the older cousins ...

 __ .
 / / / /                            ... Till Westermayer - till we *)
. .
  . mailto:till at tillwe.de . www.westermayer.de/till/ . icq 320393072
  . Habsburgerstr. 82 . 79104 Freiburg . 0761 55697152 . 0160 96619179
  . . . . .


subject: [Wikitech-l] software for making maps

body:
On Tue, Sep 02, 2003 at 11:48:42AM -0700, Jason Richey wrote:
> I'm  impressed...
>
> IIRC, this is the second major content generation system you've put
> together.  It seems that there are many of these kinds of systems that
> may be implemented in the future.  SVG graphics, Lilypond music, maps,
> TeX, etc. are all things that people would like to see, and are all
> the type of thing whose content is based on text.
>
> It seems reasonable to me to say that we shouldn't add new tags for
> every one of these systems, but should make them all be defined as
> "text based media".  Then, they should be editable in their own page,
> which should give a radio button indicating which rendering modules
> are available (math, lilypond, SVG, map).
>
> I recognize that it is easier to have mathematical equations inline in
> most cases instead of giving each it's own page.  Perhaps this could
> be solved with a tag like <text_based_media:math>\nabla \partial
> dx</text_based_media> or the like.

Tags are cheap to add and very easy to use. I don't see how
your solution is going to improve anything. Also, not having everything
in one edit box is quite inconvenient. It already annoys me that
Upload Image isn't linked from an edit page.

I think we should not only add a tag for each new type of content,
but to localize their names ! <math> and <map> are "localized enough"
for most European languages, but maybe non-European people would
prefer to use some different names, possibly in Han characters.

Any speaker of non-English language here to express their opinion on this ?


subject: [Wikitech-l] software for making maps

body:
On Tue, Sep 02, 2003 at 08:09:18PM +0000, Brion Vibber wrote:
> On Tue, 2 Sep 2003, Tomasz Wegrzanowski wrote:
> > Also, not having everything in one edit box is quite inconvenient. It
> > already annoys me that Upload Image isn't linked from an edit page.
>
> It should be right there in the sidebar. Potentially a more prominent link
> could be added?

Not in CB.
It looks like:

Browse

Main Page
Recent changes
Random page
New pages
Image list
Statistics
Special pages
Bug reports
Current events

My options

My page
My talk
My watchlist
Preferences
Log out


from_name: daniwo59 at aol.com

subject: [Wikipedia-l] Comparison to other 'pedias

body:
In a message dated 9/2/2003 8:45:43 PM Eastern Standard Time, alih at hku.hk
writes:
Encarta has a numerical strength (in number of articles) in Artists,
Writers/Poets, Plants, Economics/Business, Medicine.
Guess that means that we should work on those areas.

Danny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20030902/37e0be67/attachment.htm


from_name: Thomas Corell

subject: [Wikitech-l] Problems with setting up a wikipedia

body:
Hello,

I started a Test-Wikipedia at home, and I added (in an empty
installation) some pages. Using the downloaded source from cvs.

I run into a small problem: the stats  (Special:Statistics) should use
link-count (for ''good'') articles, but it keeps showing 0 (zero). After
   about a week I don't looked after it, it shows a realy long (and big)
number. Not one of these two results ever have something to do with the
number of arcticles in the testwiki. All the other stats seemed to be right.

Some Script or SQL-Code to get a proper statistic page? Any idea whats
possibly wrong with the code? Or did I got a unlucky cvs checkout?

Greetings

Smurf

--
Smurf

smurf at adamant.mud.de
-------------------------  Anthill inside! ---------------------------


list: wikien-l

from_name: Geoff Burling

subject: [WikiEN-l] simplicity of markup and presentation

body:
On Wed, 3 Sep 2003, tarquin wrote:

> A while ago some bright spark thought to put a DIV around the statement
> of maths theorems, with a dashed purple border.
> Today it's boxes with coloured borders for disambiguation notes.
>
> Here's why these are bad ideas:
>
> Firstly, Wikipedia is a wiki. That means source text should be as light
> on markup as possible. Knowing HTML should not be a prerequisite. We
> currently have HTML for tables and floated images -- this is something
> to be dealt with, not taken as a springboard for more.

In technical terms, using HTML is a hack; in non-technical terms, HTML
is the equivalent of making something work with duct tape, chewing gum
or an unbent paperclip.

If that's a fair paraphrase, I agree. Actually, after a brief period of
ignorance, I've always held that HTML should focus more on presenting
the material, not in producing flashy tricks of presentation. (Or so I
say now, having abused the <br> tag on a few pages full of lists.)

But the problem isn't people like me, it's those folks who discover that
you pull off certain tricks by embedding HTML in a Wiki page, then go
wild doing just that. The problems of education just keep coming back
to haunt us.

Geoff


from_name: tarquin

subject: [Wikitech-l] software for making maps

body:
Tomasz Wegrzanowski wrote:

>On Tue, Sep 02, 2003 at 08:09:18PM +0000, Brion Vibber wrote:
>
>
>>On Tue, 2 Sep 2003, Tomasz Wegrzanowski wrote:
>>
>>
>>>Also, not having everything in one edit box is quite inconvenient. It
>>>already annoys me that Upload Image isn't linked from an edit page.
>>>
>>>
>>It should be right there in the sidebar. Potentially a more prominent link
>>could be added?
>>
>>
>
>Not in CB.
>
CologneBlue needs tweaking and fixing.


body:
A while ago some bright spark thought to put a DIV around the statement
of maths theorems, with a dashed purple border.
Today it's boxes with coloured borders for disambiguation notes.

Here's why these are bad ideas:

Firstly, Wikipedia is a wiki. That means source text should be as light
on markup as possible. Knowing HTML should not be a prerequisite. We
currently have HTML for tables and floated images -- this is something
to be dealt with, not taken as a springboard for more. Besides, tables
and floated images serve a purpose, which leads to:--
Secondly, wiki markup is structural. This is one of its great strengths:
in accomplishes in one fell swoop the whole HTML/CSS separation of
content and presentation.
Thirdly, there is the aesthetics of it. Wikipedia thrives on simplicity.
Anyone can write a plain text article. Granted, there are certain style
guidelines, but do we really want to add purple borders to the manual of
style? Is the instigator of these pretty tweaks really going to go round
every single page to bring them into line? Which bring me to:
Fourthly: common sense. Suppose we *do* want a purple border around a
theorem, or a pink background to a disambiguation notice. This is *not*
the way to do it. If we really wanted this, we'd set these colours in
the stylesheet (because that is where presentational information
belongs) and we'd somehow tag paragraphs in an XML-like manner:
<disamb>This is a disamb.... etc </disamb>.
Though even that, IMO, would be bringing too much markup into the wiki
source.


body:
On Tue, 2 Sep 2003, Alex R. wrote:
> Quaere: Is it possible to creat a function to delete parts of a page's
> history
> if the history  is found to have an infringement on it. That would be a
> way to clean up the many infringements that are posted on previous page
> versions (which are also listed as being released under the GFDL); though
> if the fair use policy applies to the current versions; there is even a
> stronger argument for fair use applying to

Individual revisions can be deleted manually, and if there's a need to do
it frequently, a function could be made for it. However there are broadly
three classes of things we'd want to remove:

* A newly created article that's cut-n-pasted from a non-FDL source
without permission. If no good material has been added it can simply be
deleted; if the cut-n-paste was _replaced_ bodily with good material, it's
simple to delete the 'bad' revisions off the beginning and let the 'good'
article's history stand on its own as if it were created separately.

* An existing article that has had cut-n-paste added to it, and
immediately reverted. Individual revision(s) can be blanked easily.

* A longstanding problem, where cut-n-pasted text has been intermingled
with original text over many revisions.

This third case is the tricky one. How best to handle it?

(Do we need a wikilegal-l list?)

-- brion vibber (brion @ pobox.com)


from_name: martin at myreddice.freeserve.co.uk

subject: [WikiEN-l] misc

body:
Tarquin> We should probably put the following somewhere on a reference page
somewhere.

For undeletion, see [[wikipedia:votes for undeletion]], as pointed out by Anthere,
which already documents Allan Crossman's method (except it uses "%s", not
"PAGENAME"). Also, trying imagining an infuriated gnome hitting you over the head
with a big book while screaming "R T F M, DAMMIT!".

That said, if someone could add something on undoing moves to [[wikipedia:move]],
that'd be great. I'd copy Delirium's post, but for some godforsaken reason WikiEn-l
isn't GFDL'd.

Tim Starling> "it's currently not really clear what a banned user is meant to do to get
unbanned"

All sysops who perform IP blocks should include clear contact details on their user
page, allowing a blocked user to discuss the matter, and request unblocking. This is
particularly important when blocking dynamic IPs. Also, blocking sysops should know
how to unblock IPs as well.

Screw that, let's make contact details compulsorary for being a sysop. It'll spread out
liability when we all get sued for aiding and abetting Jimbo's world takeover.

Anthere> Perhaps it would be better that anyone practicing
deletion, knew how to practice undeletion as well

A splendid idea. I'll add something to [[wikipedia:deletion policy]]. I'd say "unless
there are any objections", but I haven't been flamed for being unilateral for a little
while, and I kinda miss it. :-)

Also, since Brion is posting helpful meatball links:
http://www.usemod.com/cgi-bin/mb.pl?CriticismIsFeedback

Which would be an excellent approach to reading [[user:Kat]], now she's left.

wikikarma: [[irreducible complexity]] (well, I like it)
-Martin "MyRedDice" Harper


body:
Alex R. wrote:
> ----- Original Message -----
> From: "Brion Vibber" <brion at pobox.com>
>>* An existing article that has had cut-n-paste added to it, and
>>immediately reverted. Individual revision(s) can be blanked easily.
>
>
> Can we do that right now as administrators (I was wondering what the
> delete this page function means when it show up on prior versions, is
> this what it is for or does it delete the whole page, not just the current
> revision on screen?) or is that only something that developers can do?

No, "delete this page" always means "delete this page". To blank
individual revisions requires mucking in the database directly at present.

It is a _technically_ simple matter, but policy is the question.

Deletion of page history must not be done lightly. Wikipedia has become
incredibly delete-happy over the last year; something we (or at least I)
really don't want to see is 'sanitization' of page histories by quietly
dropping revisions that somebody doesn't approve of, lost in a general
background of "deleted junk edit from newbie".

(Further, Wikipedia _is_ a grand experiment. There may be people doing
their theses on the edit histories of particular Wikipedia articles a
hundred years from now, and they'll be _sorely_ disappointed if we
remove all the "vandalism" from the archives. Let's remove only what we
_can't_ distribute -- the copyright problems -- and leave notice of
their passing.)

> Is there any possibility of putting a notice on the history pages to show
> they are there for _archival purposes only_?

I'm not sure I understand how that would be in any way different from
their present purpose. Archival or not, we're distributing those
revisions to the public.

-- brion vibber (brion @ pobox.com)


from_name: Gutza

body:
tarquin wrote:

> A while ago some bright spark thought to put a DIV around the
> statement of maths theorems, with a dashed purple border.
> Today it's boxes with coloured borders for disambiguation notes.
>
> Here's why these are bad ideas:
> [snip list]

I've started replying to this three times and closed the "Compose"
window just as many times. Why? Because I actually have nothing to add,
my message could just as well be void, because I have very little more
to add. Why I sent it after all? Because I feel exactly the same way, in
a strong way, and wanted to get my "vote" counted in. :)

Apart from your considerations though, I wanted to clarify the reason
why we're asking for this: I hate clogging content and formatting into
one ugly mess. I know that also what you're basically advocating
against, just wanted to clarify the general concept and the benefits,
apart from ease of editing.

The source should only contain information (plain text) and
meta-information ("this is text regarding disambiguation", "this is text
regarding maths", "this is a caption for an image") in some technical
way or another, but not formatting per se ("there is a purple box around
this text", "this is large text", "this is green underlined text on pink
background"--imagine that!). In that regard, XML, proper HTML or at
least custom CSS styles could be used for tables as well. Tables are a
cross-breed between meta-information and presentation, it's hard to
separate the two in this case. What you can do though is properly mark
the table header as header and the body as table body, as opposed to
marking the first row render in bold on a gray background, and rendering
the rest of the table in default style. The former solution is elegant,
uniform, allows custom formatting based on purpose (web, personal
printing, PDF output, high volume printing, 3rd party importing) whereas
the latter is ugly, messy, non-uniform and set in stone formatting-wise.

2c+2c=5c :)

[[User:Gutza]]


body:
----- Original Message -----
From: "Brion Vibber" <brion at pobox.com>
>
> Individual revisions can be deleted manually, and if there's a need to do
> it frequently, a function could be made for it. However there are broadly
> three classes of things we'd want to remove:

> * A newly created article that's cut-n-pasted from a non-FDL source
> without permission. If no good material has been added it can simply be
> deleted; if the cut-n-paste was _replaced_ bodily with good material, it's
> simple to delete the 'bad' revisions off the beginning and let the 'good'
> article's history stand on its own as if it were created separately.

Yes, there are lots of pages that are/have been "blanked" because of
"copyright violations" and then they converted into a stub. Getting
rid of the original page with the violation info would be a useful thing
to do routinely. A page that has a "impure" page history could be
listed somewhere when someone finds it, and then the original page
could be blanked but the rest of the page history remains without the
violation (but possibly the mention that it happened). There must be
_thousands_ of pages like this already as one look at the VfD/copyvio
page shows that people are replacing violations with stubs all the time.
It may be a job finding all of them.

> * An existing article that has had cut-n-paste added to it, and
> immediately reverted. Individual revision(s) can be blanked easily.

Can we do that right now as administrators (I was wondering what the
delete this page function means when it show up on prior versions, is
this what it is for or does it delete the whole page, not just the current
revision on screen?) or is that only something that developers can do?
I know that the folks on the Japanese Wikipedia are concerned
about that too, see Tomo's comment at the bottom of this page:
http://www.wikipedia.org/wiki/Wikipedia:Copyright_violations_on_history_pages

> * A longstanding problem, where cut-n-pasted text has been intermingled
> with original text over many revisions.
>
> This third case is the tricky one. How best to handle it?

That is the one where the copyright problem may be removed. If Wikipedia
is about facts then if the text is edited so that it can't be
differentiated, then
it may not be an infringement.  Probably best to keep editing it and leave
the "paper trail" to prove it has been edited beyond recognition. Probably
pages that have had only some but significant editing should be listed
somewhere to encourage more editing. It would be a shame to remove
text that has been edited over many generations. The diff function can
certain help one rewrite the article so that the content remains but the
form and structure has changed.

Is there any possibility of putting a notice on the history pages to show
they are there for _archival purposes only_?  Do we really want to
encourage people to use older versions of articles anyway? If they link
to the article (as they should) then the link will bring one to the newest
version, not an infringing history version of it. This might be a much
simpler solution than creating a delete function (though it is encouraging
people to look into the histories for the infringing material) and the
delete
function will certain clean up these old infringements.

> (Do we need a wikilegal-l list?)

I hope not! But maybe it is not a bad idea.

alex756


body:
Alex756 (the lawyer) wrote:

>Brion Vibber wrote:

>>* A newly created article that's cut-n-pasted from a non-FDL source
>>without permission. If no good material has been added it can simply be
>>deleted; if the cut-n-paste was _replaced_ bodily with good material, it's
>>simple to delete the 'bad' revisions off the beginning and let the 'good'
>>article's history stand on its own as if it were created separately.

>Yes, there are lots of pages that are/have been "blanked" because of
>"copyright violations" and then they converted into a stub. Getting
>rid of the original page with the violation info would be a useful thing
>to do routinely. A page that has a "impure" page history could be
>listed somewhere when someone finds it, and then the original page
>could be blanked but the rest of the page history remains without the
>violation (but possibly the mention that it happened). There must be
>_thousands_ of pages like this already as one look at the VfD/copyvio
>page shows that people are replacing violations with stubs all the time.
>It may be a job finding all of them.

It may be a job indeed, and luckily a probably unnecessary one.
The "good" part of the DMCA is that we're not liable for these copyvios
unless our designated agent (which is Jimbo) receives an official notice.
Until he starts getting a lot of these, then he can just tell the developers
to remove each individual problematic version from the online database
(although it should be stored in a backup in case of errors).
If and when these start pouring in, then we can speed things up.
So far, I believe that he hasn't received a single one of these complaints.

>>* A longstanding problem, where cut-n-pasted text has been intermingled
>>with original text over many revisions.
>>This third case is the tricky one. How best to handle it?

>That is the one where the copyright problem may be removed. If Wikipedia
>is about facts then if the text is edited so that it can't be
>differentiated, then
>it may not be an infringement.  Probably best to keep editing it and leave
>the "paper trail" to prove it has been edited beyond recognition. Probably
>pages that have had only some but significant editing should be listed
>somewhere to encourage more editing. It would be a shame to remove
>text that has been edited over many generations. The diff function can
>certain help one rewrite the article so that the content remains but the
>form and structure has changed.

I think that this is the tricky case, because the history may still infringe.
As long as we get no complaints, then that's just fine and they all stay up.
But if we do get complaints, then there may be a quite contentious issue
as to which versions are infringements that must be removed and which aren't;
complicating this is how to give credit to the authors of the good text.
The best way to prevent this (besides avoiding infringement at first)
is to /completely/ rewrite any violation as soon as it is detected,
rather than letting it be slowly changed over the course of several edits.

>Is there any possibility of putting a notice on the history pages to show
>they are there for _archival purposes only_?  Do we really want to
>encourage people to use older versions of articles anyway? If they link
>to the article (as they should) then the link will bring one to the newest
>version, not an infringing history version of it. This might be a much
>simpler solution than creating a delete function (though it is encouraging
>people to look into the histories for the infringing material) and the
>delete function will certain clean up these old infringements.

They are IMO for archival purposes only, except for reverting things.
So a notice that reiterates this fact might be a very good idea.
It may not be necessary either, but at least it's easy to do.

>>(Do we need a wikilegal-l list?)

>I hope not! But maybe it is not a bad idea.

We'll doubtless need it someday.

-- Toby


subject: [Wikipedia-l] [JOKE] Re: Sysop ability to ban logged in users

body:
Tim Starling wrote:

>Only developers can effectively block sysops, by first removing the
>user's sysop status and then banning the user.

Or going in the reverse order, if they're quick about it. -_^

-- Toby


subject: [WikiEN-l] [JOKE -- or is it?] Re: Michael again *sigh*

body:
Jimmy Wales wrote:

>Sure, but the great irony is that if someone did attack us in some
>more sophisticated way, the net result would not be to shut us down,
>but to force us to abandon one of our ideals of anonymous edits and
>instant-signup-edits.

Yes, but then the terrorists would have won.

-- Toby


body:
Gutza wrote in part:

>Tarquin wrote:

>>A while ago some bright spark thought to put a DIV around the
>>statement of maths theorems, with a dashed purple border.
>>Today it's boxes with coloured borders for disambiguation notes.
>>Here's why these are bad ideas:

>I've started replying to this three times and closed the "Compose"
>window just as many times. Why? Because I actually have nothing to add,
>my message could just as well be void, because I have very little more
>to add. Why I sent it after all? Because I feel exactly the same way, in
>a strong way, and wanted to get my "vote" counted in. :)

In other words, "me too".  Well, me too too!

>In that regard, XML, proper HTML or at
>least custom CSS styles could be used for tables as well. Tables are a
>cross-breed between meta-information and presentation, it's hard to
>separate the two in this case. What you can do though is properly mark
>the table header as header and the body as table body, as opposed to
>marking the first row render in bold on a gray background, and rendering
>the rest of the table in default style.

Everybody interested in this should see [[meta:Wiki markup tables]].
This hasn't been worked on for a while, and fresh ideas would be good.

-- Toby


subject: [WikiEN-l] Fwd: My Wikipedia Rant

body:
Vicki Rosenzweig wrote:

>Jimbo Wales wrote:

>>The ironic beauty of this is that John calls it a 'socialist nirvana'
>>and laments the 'dead ends' he got when he tried to research the
>>founder of the site (I can only assume he meant me).

>From my viewpoint, it is a fine piece of an anarcho-socialist nirvana:
>everyone contributes what they want and are able to, and everyone shares
>the resulting benefits.

Yes, I don't see anything particularly right-wing about Wikimedia.
To be sure, it fits in with right-Libertarian philosophy just fine;
since Jimbo, as owner of the infrastructure, chooses to let us use it,
and Wikimedia, although a collective institution, is entirely voluntary.
That's the great thing about /libertarianism/ of any stripe,
as opposed to the authoritarianism of (say) the GWBush administration;
alternative models can fit into the framework if people want them.

-- Toby


subject: [Wikitech-l] Re: Problems with setting up a wikipedia

body:
Tim Starling wrote:
> I've seen this too. I'm not sure why the counter is not incrementing
> properly, but the big number occurs when an article is removed and the
> counter is decremented, and you get 0-1 = 2^64-1 or something like that.

Well, I think you are right about this. I din't thought about removing
articles. I will take a look at decrementing. Thank you so far.

--
Smurf

smurf at adamant.mud.de
-------------------------  Anthill inside! ---------------------------


from_name: Ray Saintonge

subject: [WikiEN-l] Make the press

body:
Gareth Owen wrote:

>In todays Guardian -- a major British broadsheet newspaper -- Notes and
>Queries column (the version published on dead trees, rather than the website)
>a correspondent cites www.wikipedia.org as an authority on various Dukes Of
>Edinburgh.  Might draw a little traffic.
>
What's interesting about this is what it tells us about the kinds of
article that draw traffic.  I have no doubt that the information
mentioned there about the Dukes of Edinburgh is available on other
sites, but we have it organized in one spot in a comprehensive way.
 Certain of our "List of" articles may seem trite and unimaginative, but
I believe that they have an attraction for people who want this kind of
summary information in one place, rather than going on an internet
wild-goose chase.  These chases are frustrating enough for experienced
searchers, and impossible for others.

Ec


from_name: Andrew Lih

body:
There was talk about comparison to other 'pedias, so you might be
interested in my initial breakdown of Encarta Plus, just to show the
categories and article counts in Microsoft's product.

http://www.wikipedia.org/wiki/User:Fuzheado/Research

The "educated guesses" posed by folks here tend to be correct.  Some
other insights:

- Encarta has a numerical strength (in number of articles) in Artists,
Writers/Poets, Plants, Economics/Business, Medicine.
- Wikipedia probably holds its own in the US towns and cities section,
thanks to the automated bot articles.
- Wikipedia has a much better "Military" section as Encarta,
inexplicably, only has *two* official entries.
- Wikipedia has strengths in the areas of pop culture, current events,
technology, and non-Western culture.

-Andrew

Andrew Lih, Assistant Professor
Journalism and Media Studies Centre
University of Hong Kong
Email: alih at hku.hk | Web: http://jmsc.hku.hk/


from_name: Tim Starling

body:
Thomas Corell wrote:
> Hello,
>
> I started a Test-Wikipedia at home, and I added (in an empty
> installation) some pages. Using the downloaded source from cvs.
>
> I run into a small problem: the stats  (Special:Statistics) should use
> link-count (for ''good'') articles, but it keeps showing 0 (zero). After
>   about a week I don't looked after it, it shows a realy long (and big)
> number. Not one of these two results ever have something to do with the
> number of arcticles in the testwiki. All the other stats seemed to be
> right.
>
> Some Script or SQL-Code to get a proper statistic page? Any idea whats
> possibly wrong with the code? Or did I got a unlucky cvs checkout?

I've seen this too. I'm not sure why the counter is not incrementing
properly, but the big number occurs when an article is removed and the
counter is decremented, and you get 0-1 = 2^64-1 or something like that.

-- Tim Starling.


subject: [WikiEN-l] Re: simplicity of markup and presentation

body:
Bj wrote:

> I agree that unnecessary markup is... unnecessary. But there are two
> sides of the coin, on one hand we don't want people to have to install
> MS Frontpage (or whatever it is called) and have three years web
> design experience. But on the other hand, most Wikipedia pages are
> rather ugly and boring. They are like just text! I mean who wants to
> read four pages of NPOV encyclopedic text where the most interesting
> things are the paragraph breaks? :-)

The choice is between information and pretty packaging.  If Wikipedia is
going to have any long term reputation it will depend on the
information, not the packaging.  Boring is OK.  Fixing the boring should
not come at the expense of the primary purpose of the encyclopedia.  For
people with slow connections pictures can be a problem.  Others who pay
by the on-line second, both to their ISP and the telephone company, may
not appreciate paying to download uninformative pretty pictures.
 Furthermore, if we want to appeal to impoverished parts of the world,
we need to take into account the fact that their services are rudimentary.

> We're modern people with attention spans measured in seconds.

This sounds like an argument in favour of dumbing down.

> For example, take the Rambot* city pages, how much better wouldn't
> those pages be if their information was presented in a more attractive
> way? I have already complained about the lack of pictures, but as that
> problem seems to be unsolvable unless someone spends a million dollars
> on lawyers researching copyright laws, we have to find other ways to
> make the information pretty.

This has nothing to do with lawyers.  Perhaps on your next vacation you
can choose an area (one county might be a convenient size), go there
with your digital camera, take pictures of all the little towns in that
area, and submit them to Wikipedia to illustrate those articles.
 Problem solved.  -- and without a lawyer.

> Currently the easiest and only way to make pretty articles is to use
> html. It has the disadvantages that it makes it harder for most
> editors to edit articles and someday it might cause severe browser
> incompatibilities and problems for disabled users. But isn't that a
> problem with all new features?

Huh?

> I'll bet someone already has asked themselve how to edit the table of
> contents..

That's easy.  Just edit the headings.

> . So instead of letting the not so smart people be a hinderance for
> the way of the future lets make them smarter by providing good
> documentation and make everything as easy as possible so that everyone
> can be happy.

That's an outrageously elitist attitude.  The project is not about
making people "smarter", it's about providing information.  How are
these "not so smart people" a hinderance anyway?  If you think that
better documentation will solve the problems you're welcome to write it.
 That should not be difficult unless you are one of the "not so smart
people". ;-)

Ec

>


body:
Toby Bartels wrote:
> Tomasz Wegrzanowski wrote:
>
>
>>That's idiotic. What for is a ban where one can "unban oneself" ?

Finally he cottons on. I did say it twice, on wikitech-l:

:Tsk tsk, don't you people read? ;) I said:
:
::As usual, these automatically generated entries, and the original
::username entries, can be unblocked by any sysop (even blocked sysops).

>
> For nothing, obviously.  So why are we worrying about it?
>
> What would be, if not idiotic, then at any rate a waste of effort,
> would be to alter the natural code for blocking user names
> so that it checks that whether the user names are admins first.
>
> You make a fair case that blocking admins for real is a bad idea;
> but since that can't happen anyway, why bother altering the code?

Only developers can effectively block sysops, by first removing the
user's sysop status and then banning the user.

-- Tim Starling <tstarlingphysicsunimelbeduau>


list: textbook-l

from_name: Magnus Manske

subject: [Textbook-l] Annotations of wikisource: A working proposal

body:
See my up-and-running early attempt at

   http://magnusmanske.de/stuff/test.php

This reads and writes directly from/to the single source file that can
be found under

   http://magnusmanske.de/stuff/source.txt

The acript does some automatic markup, but that's just a demo and can be
changed or turned off.

I propose that, for wikisource, we replace the display component with
something similar to my above proposal, at least for certan pages, e.g,
all articles with a '()' in it, like "A midsummer night's dream (Act 1)"

We could still edit the source (to fix OCR bugs etc.) just by clicking
"Edit this page"...

Comments? Suggestions? Penalties for yet again
implementing-before-discussing? ;-)

Magnus


from_name: Gareth Owen

subject: [WikiEN-l] Make the press

body:
In todays Guardian -- a major British broadsheet newspaper -- Notes and
Queries column (the version published on dead trees, rather than the website)
a correspondent cites www.wikipedia.org as an authority on various Dukes Of
Edinburgh.  Might draw a little traffic.

Kudos to
http://www.wikipedia.org/wiki/Duke_of_Edinburgh
--
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)


subject: [Textbook-l] Re: [Intlwiki-l] original sources on Wikipedia

body:
limholt at excite.com wrote:

>
>  --- On Tue 09/02, Magnus Manske < magnus.manske at web.de > wrote:
>
> "Daniel Mayer wrote: No separate project needed (a sub-project of Wikibooks might be needed though)."
> There's no such thing as a sub-project, at least not on the software level. Either it is one project, or two. Two projects could be accessing the same database, but I don't see a reason for that, as we'd have two interfaces to show and do exactly the same thing. Two projects could be *presented* as project and subproject, though. If we call the two projects wikibooks.org and wikisources.org, or rather textbooks.wikibooks.org and sources.wikibooks.org, doesn't make a difference, at least not to me.
>
> _______________________________________________
>
> I didn't read Daniel's the same way you did. I assumed his 'sub project' referred to a kind of effort like the countrty or biography template ''projects'' within Wikipedia. If you look at his comments that way they make a lot more sense. A common wiki, data store, and set of software techniques that support a variety of books with somewhat different natures.

Oh. Yes. I see. Now.

In that case, my earlier objections still apply, but as I said, I won't
block any emerging consensus on that :-)

Magnus


subject: [Wikitech-l] stats are down

body:
Walter Vermeir wrote:
> The stats of the Wikipedias are not updated anymore.
>
> http://nl.wikipedia.org/stats/
> http://fr.wikipedia.org/stats/

The new directory layout broke the stats update script, but that's okay
since they're now being regenerated with a better configuration. Now:

* Localized pages (for some at least, see note below)
* Fixed broken-URL problem (at least for some; the localized versions
I've compiled don't have the problem)
* More top URLs listed
* More referrers listed
* (most?) useles referrers from within wikipedia to wikipedia should now
be filtered out

Those wikis so far without stats should have stats pages generated
starting tonight.

On localization: webalizer needs to be recompiled to change the language
the pages are displayed in. I've done the Latin-1 ones that are up and
Hungarian as a test. The page contents seem to work after converting the
language file to UTF-8 to match with the URLs to be listed, but the
labels in the graphs aren't treated rightby the graphing library, and
I'm not quite sure how to fix that yet. (cf
http://hu.wikipedia.org/stats/daily_usage_200308.png )

-- brion vibber (brion @ pobox.com)


from_name: Fred Bauder

body:
on 9/3/03 11:09 AM, Ray Saintonge at saintonge at telus.net wrote:

> Bj wrote:
>
>> I agree that unnecessary markup is... unnecessary. But there are two
>> sides of the coin, on one hand we don't want people to have to install
>> MS Frontpage (or whatever it is called) and have three years web
>> design experience. But on the other hand, most Wikipedia pages are
>> rather ugly and boring. They are like just text! I mean who wants to
>> read four pages of NPOV encyclopedic text where the most interesting
>> things are the paragraph breaks? :-)
>
> The choice is between information and pretty packaging.  If Wikipedia is
> going to have any long term reputation it will depend on the
> information, not the packaging.

But see: http://credibility.stanford.edu/guidelines/index.html

  Boring is OK.  Fixing the boring should
> not come at the expense of the primary purpose of the encyclopedia.  For
> people with slow connections pictures can be a problem.  Others who pay
> by the on-line second, both to their ISP and the telephone company, may
> not appreciate paying to download uninformative pretty pictures.
> Furthermore, if we want to appeal to impoverished parts of the world,
> we need to take into account the fact that their services are rudimentary.

I hear you, I started on the internet with a 2400 connection, I absolutely
hated commplicated websites with intensive graphics.

>
>> . So instead of letting the not so smart people be a hinderance for
>> the way of the future lets make them smarter by providing good
>> documentation and make everything as easy as possible so that everyone
>> can be happy.
>
> That's an outrageously elitist attitude.  The project is not about
> making people "smarter", it's about providing information.  How are
> these "not so smart people" a hinderance anyway?  If you think that
> better documentation will solve the problems you're welcome to write it.
> That should not be difficult unless you are one of the "not so smart
> people". ;-)
>
> Ec

Like a lot of programming issues, it is not about being smart. It is about
having a life. If you don't fiddle around with markup a lot you are lost and
ignorant no matter how smart you are.

Fred Bauder

http://www.internet-encyclopedia.org


from_name: Dante Alighieri

body:
At 05:13 AM 9/3/2003, you wrote:
>Jimmy Wales wrote:
>
> >Sure, but the great irony is that if someone did attack us in some
> >more sophisticated way, the net result would not be to shut us down,
> >but to force us to abandon one of our ideals of anonymous edits and
> >instant-signup-edits.
>
>Yes, but then the terrorists would have won.
>
>
>-- Toby

I can envision a protection against vandalbots that would not endanger our
ability to accept instant anonymous edits. We could require that anyone
trying to make an edit from an IP (not logged-in) have to pass a little
test on every 5th edit or so. I'm sure you've all seen those images with
distorted words where you are asked to read and type in the word so that
bots can't sign up for various mailing lists, etc. We could use something
like that. Every 5th edit wouldn't be TERRIBLY inconvenient for the user,
but would sure stop a vandalbot. Plus, the minor inconvenience might even
nudge people towards generating and using a login... which is A Good Thing.
I suppose this could be problematic for anonymous contributors who are
vision impaired, but we could have an audio version as well.

In any event, even if the above example isn't terribly feasible, I doubt we
would truly have to give up in defeat (by disallowing anonymous edits) if
we were subject to a concerted attack. We're resourceful, we'll come up
with something when the time comes.

-----
Dante Alighieri
dalighieri at digitalgrapefruit.com

"The darkest places in hell are reserved for those who maintain their
neutrality in times of great moral crisis."
    -Dante Alighieri, 1265-1321


from_name: Richard Grevers

subject: [Wikitech-l] TOC feature request

body:
[[List of dramatists]] and, I imagine, quite a few other lists, are
organised alphabetically.

The page has a TOC which, while being useful, is butt-ugly due to excesive
length. What would be great for this sort of TOC is an alternative
presentation such as A | B | C | D or even just A B C D. Since we have a
code to suppress the TOC, could we create one that would flag generation
of a compact, horizontal layout?

I can also see potential for a skin where the ToC is rendered as
position:fixed (Supported now by most modern browsers other than IE for
Windows).

I would offer to help with implementation but my expertise in server-side
scripting is in a language other than php :-(

--
[ Note new address/phone from July 12th!         ]
[ dramatic design ---  for web | print | theatre ]
[ 146 lemon st | new plymouth 6401 | new zealand ]
[ tel +64-6-757-8090 | cell +64-27-221-5053      ]
[ fax +64-6-757-8090 | e richard at dramatic.co.nz  ]
[ web http://www.dramatic.co.nz/                 ]


from_name: Andre Engels

body:
On Wed, 3 Sep 2003, Toby Bartels wrote:

> I think that this is the tricky case, because the history may still infringe.
> As long as we get no complaints, then that's just fine and they all stay up.
> But if we do get complaints, then there may be a quite contentious issue
> as to which versions are infringements that must be removed and which aren't;
> complicating this is how to give credit to the authors of the good text.

We only have to credit the authors, and give a history of the changes to the
text, there is nothing in the GNU/FDL that tells us to provide the older
versions (IIRC). So just giving the names/nicks of the authors and the dates
of major revisions should be enough for the GNU/FDL. Just changing the old
version with 'removed for copyright reasons' should be enough.

> The best way to prevent this (besides avoiding infringement at first)
> is to /completely/ rewrite any violation as soon as it is detected,
> rather than letting it be slowly changed over the course of several edits.

Yes, but what if it has been slowly changed over the course of several edits
already before it is detected?

Andre Engels


subject: [Wikitech-l] TOC feature request

body:
On Wed, 03 Sep 2003 13:44:27 +1200, Richard Grevers
<richard at dramatic.co.nz> gave utterance to the following:

> [[List of dramatists]] and, I imagine, quite a few other lists, are
> organised alphabetically.
>
> The page has a TOC which, while being useful, is butt-ugly due to
> excesive length. What would be great for this sort of TOC is an
> alternative presentation such as A | B | C | D or even just A B C D.
> Since we have a code to suppress the TOC, could we create one that would
> flag generation of a compact, horizontal layout?
>
> I can also see potential for a skin where the ToC is rendered as
> position:fixed (Supported now by most modern browsers other than IE for
> Windows).
>
> I would offer to help with implementation but my expertise in
> server-side scripting is in a language other than php :-(
>
okay, so I won't re-post from the correct address! (Kicks mail software
for allowing wrong from address).

--
Richard Grevers
Between two evils always pick the one you haven't tried


from_name: DEEN

subject: [Textbook-l] l need some free textbooks

body:
sir/madam,l'm a regular viewer of you website and l will like to have some free textbooks on the use of C++ as a programming language with CDs support if possible. l shall like them to be sent to the address below: GAFAR DEEN,C/O MR R.O OSHINEYE,P.O.BOX 1223 APAPA,LAGOS,LAGOS STATE,NIGERIA.101010.  pls mail me back if my request shall be granted  thanks,GAFAR DEEN.

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/textbook-l/attachments/20030903/b0167a44/attachment.htm


from_name: Alex R.

body:
From: "Brion Vibber" <brion at pobox.com>

> > Is there any possibility of putting a notice on the history pages to
show
> > they are there for _archival purposes only_?
>
> I'm not sure I understand how that would be in any way different from
> their present purpose. Archival or not, we're distributing those
> revisions to the public.

Right now the assumption is that everything on Wikipedia is GFDL, there
is nothing stated that the history pages are not GFDL released, stating that
they are not to be linked to directly or copied is discouraging those pages
from being used for any purpose, except fair use which is always allowed,
(even if what fair use might be it is very confusing).  Anyone who accuses
Wikipedia of infringement in those cases would be told that those pages
are not generally available to search engines and that they are only for
research and private study; it is important to point out that even if there
is infringement there has to be damages and sometimes those damages are
nominal, the jury only awards one dollar as the copyright owner has not
suffered any real damage from the infringement even if the fair use defense
is unsuccessful. I am doubtful that any judge would award a plaintiff
statutory damages when it was not Wikipedia that posted the infringing
material and volunteers tried their best to remove all traces of the
infringement from the publicly released version.

Fair use would certainly cover graduate students writing theses, others
who are looking into page histories including anyone doing
a due dillegence search on the copyright origins of any page.

I am all for keeping the paper trail intact (except perhaps for deleting the
earliest page of those pages that were created with infringing material
and then  blanked and filled with a stub, or keeping the original entry
but just blanking the infringing material).

You are right a strong policy needs to be created so that such a function,
even if available only to a few developers or the sysops keeps the database
otherwise intact. The integrity of the database has an important function in
relation to the GFDL. Also, we do not want to be accused of destroying
or hiding evidence (though I guess there are historical back ups that can
always be retrieved if there is a subpeona issued).

Alex756


from_name: Toby Bartels

body:
Fred Bauder wrote in part:

>Eclecticology wrote:

>>The choice is between information and pretty packaging.  If Wikipedia is
>>going to have any long term reputation it will depend on the
>>information, not the packaging.

>But see: http://credibility.stanford.edu/guidelines/index.html

Which says in part "The visual design should match the site's purpose.".
Ours does.

-- Toby


from_name: Walter Vermeir

subject: [Wikitech-l] stats are down

body:
The stats of the Wikipedias are not updated anymore.

http://nl.wikipedia.org/stats/
http://fr.wikipedia.org/stats/

--
Contact: walter AT wikipedia.be
Ook een artikeltje schrijven? WikipediaNL, de vrije GNU/FDL encyclopedie
http://www.wikipedia.be


from_name: Björn Lindqvist

body:
I agree that unnecessary markup is... unnecessary. But there are two
sides of the coin, on one hand we don't want people to have to install
MS Frontpage (or whatever it is called) and have three years web design
experience. But on the other hand, most Wikipedia pages are rather ugly
and boring. They are like just text! I mean who wants to read four pages
of NPOV encyclopedic text where the most interesting things are the
paragraph breaks? :-) We're modern people with attention spans measured
in seconds.

For example, take the Rambot* city pages, how much better wouldn't those
pages be if their information was presented in a more attractive way? I
have already complained about the lack of pictures, but as that problem
seems to be unsolvable unless someone spends a million dollars on
lawyers researching copyright laws, we have to find other ways to make
the information pretty.

Currently the easiest and only way to make pretty articles is to use
html. It has the disadvantages that it makes it harder for most editors
to edit articles and someday it might cause severe browser
incompatibilities and problems for disabled users. But isn't that a
problem with all new features? I'll bet someone already has asked
themselve how to edit the table of contents...

So instead of letting the not so smart people be a hinderance for the
way of the future lets make them smarter by providing good documentation
and make everything as easy as possible so that everyone can be happy.

BL

* - Everyone seems to complain about Rambot so I figured it would be
safe for me to take a potshot too, but it was just an example many other
articles suffer from the same problem.


from_name: Brion Vibber

subject: [Wikitech-l] PHP Wiki

body:
Guillaume Blanchard wrote:
> I installed an old version of Wikipedia (a personal backup of an early Phase
> III version) on my server. But I have many (small) problems with it. I don't
> need all Wikipedia stuffs (basic Usemod Wiki is enough), but as I want to
> customize it, I'm looking for a PHP/MySQL version. My questions are:
>
> Does some one know where I can found a PHP version of Usemod Wiki?

No such thing exists; UseModWiki is written in Perl.

There are many wiki programs written in PHP; PhpWiki is fairly popular,
and I believe our diff function is borrowed from it, but otherwise it
bears no relation to our code. I don't know how similar it is in
formatting etc.

See: http://phpwiki.sourceforge.net/

> Do you restart the PHP version of Wikipedia from scratch?

The current (phase 3) code was largely written anew by Lee Daniel
Crocker, but partially based on the phase 2 code. The phase 2 code was
written from scratch by Magnus Manske. A few parsing functions might
have been based directly on UseModWiki code (?) but the overall code
structure is totally different.

-- brion vibber (brion @ pobox.com)


from_name: Lars Aronsson

subject:
[Textbook-l] Re: [Intlwiki-l] Annotations of wikisource: A working
	proposal

body:
Magnus Manske wrote:
> See my up-and-running early attempt at
>    http://magnusmanske.de/stuff/test.php

Perhaps I'm just having one of my pessimistic days, but I doubt that
this project will ever take off.  Is anybody really interested in
annontating literature on a big scale?  I know that annotated books
exist on paper, but I haven't seen many websites that do this, with or
without wiki technology.

I first embraced wiki technology because it allowed me to build a
website faster and in a more structured fashion than other methods I
had used to build websites.  But I was already building websites.

Hundreds of Wikipedia volunteers have a history of running their own
small websites where they have been compiling small dictionaries or
knowledge databases, and they are attracted to Wikipedia because
it allows them to cooperate and do the same thing on a bigger scale.
But who is doing "annotated literature on the web" today, that could
be attracted by the wikisource/wikibooks project allowing them to do
"the same thing" but faster and bigger?  Really?  Who?

I don't want to be pessimistic, so I hope you can convince me that
my first impression is wrong.  I also think that asking "who", i.e.
finding out who the target audience / volunteer force is going to be,
is a useful first step towards learning "how" it should be
implemented.

--
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik - http://aronsson.se/


from_name: james duffy

subject: [WikiEN-l] Make the press

body:
>
>Gareth Owen wrote:
>
>>In todays Guardian -- a major British broadsheet newspaper -- Notes and
>>Queries column (the version published on dead trees, rather than the
>>website)
>>a correspondent cites www.wikipedia.org as an authority on various Dukes
>>Of
>>Edinburgh.  Might draw a little traffic.
>>
>What's interesting about this is what it tells us about the kinds of
>article that draw traffic.  I have no doubt that the information mentioned
>there about the Dukes of Edinburgh is available on other sites, but we have
>it organized in one spot in a comprehensive way. Certain of our "List of"
>articles may seem trite and unimaginative, but I believe that they have an
>attraction for people who want this kind of summary information in one
>place, rather than going on an internet wild-goose chase.  These chases are
>frustrating enough for experienced searchers, and impossible for others.
>
>Ec

Wiki is weak in some areas but when it is good, (and the Duke of Edinburgh
page is a classic example) it is very very good indeed. There are so many
pages on wiki that are far far better than any other encyclop?dia I have
ever seen. And we can be so proud of what we have built and what we are
building. When a heavily academic article is praised in a paper as credible
as The Guardian, you know you are doing a damn good job.

JT

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail


from_name: martin at myreddice.freeserve.co.uk

body:
> I'm sure you've all seen those images with distorted words

http://www.wikipedia.org/wiki/captcha

One of our better articles.

WikiKarma: fixed edit war


from_name: Tomos at Wikipedia

subject: [Wikipedia-l] World Summit (on Information Society) Awards

body:
I think Wikipedia (or Wikimedia) would be a very strong candidate for the
World Summit Awards.

The award is given as a part of the World Summit on Information Society, a
series of events from 2003-2005 organized by UN (ITU, to be exact).

Oh, but it's not a financial award. It seems there will be some
demonstrations of good practices/ products in major regions of the world.

There are 8 categories, like e-government, e-science, e-culture,
e-inclusion, etc. I think Wikipedia would be good for e-learning category.

What I would suggest is that someone with some credentials would recommend
Wikipedia to Benton Foundation. (see the third link below) (deadline is
September 15)

Also, Jimbo could make an entry at the "Register" section of the Award site
(the second link below).
Deadline seems to be Sep. 27.

URLs:

1) The official website for the summit
http://www.itu.int/wsis/

2) The official website for the award
http://www.wsis-award.org/

3) The the U.S. representative for the summit soliciting input
http://www.benton.org/contact/summitawards.html

Tomos

_________________________________________________________________
Get 10MB of e-mail storage! Sign up for Hotmail Extra Storage.
http://join.msn.com/?PAGE=features/es


from_name: Ray Saintonge

subject: [Wikipedia-l] Gray's Anatomy

body:
Magnus Manske wrote:

> As we are short on medical topics, I went to [[Requested articles]]
> and created a stub on [[Ethmoid bone]]. Then I realized that there's
> [[Gray's Anatomy]] from 1908, in the public domain, according to the
> article.
>
> So I copied the text and the images from www.bartleby.com, who claim
> to have the original thing. I didn't copy HTML but only the text, so
> no bartleby markup here.
>
> Questions:
> * Can we use these? AFAIK, scanning&OCR is not a copyrightable thing.
> * Should we use these? Wikified, of course, as I did. They'd cover
> plenty of topics in the medical area, but may be a little old and
> heavy. OTOH, this is wikipedia; if you don't like the style, edit!

I have no problem with your doing this.  Unlike most of science, the
basics of human anatomy have not significantly changed since Gray's book
was produced.  The illustration style is somewhat dated in the way that
it uses shading, but I guess that will do until someone with the
appropriate skills can improve them.

As a whole Gray's Anatomy could be a useful candidate for inclusion on
Wikisource.  It is an objective topic where NPOV issues are not going to
be as big a factor as they might be elsewhere.  As an English original,
it does not lead to immediate translation problems, though if others
want to translate it they should feel free to do so.   It certainly
provides a lot of work to do for those who want to wikify the text.  It
is a text which could easily fit potential annotation models and how
they might be developed; that is to say it contains many individual
sub-headings where people could find something to say or improve or
compare or ...whatever?  As a whole a good candidate for the
experimental development of the relationship of wikisource with other
members of the Wikimedia Kingdom.

Ec


from_name: Jimmy Wales

subject: [Wikipedia-l] Gray's Anatomy

body:
Regarding the 1908 Gray's anatomy, Magnus wrote:
> Questions:
> * Can we use these? AFAIK, scanning&OCR is not a copyrightable thing.

Yes, we should be fine with that.

> * Should we use these? Wikified, of course, as I did. They'd cover
> plenty of topics in the medical area, but may be a little old and heavy.
> OTOH, this is wikipedia; if you don't like the style, edit!

It's sort of a mixed blessing like the 1911 Britannica stuff, isn't
it?

Perhaps it would be best to add them slowly, perhaps in an automated
fashion, but maybe a few per day, so that we have time to absorb them.
It should be pretty easy for people to go through and update them to a
certain extent.  And some of that information, perhaps the bulk of it,
is going to be pretty valid even today.

--Jimbo


from_name: tarquin

body:
Toby Bartels wrote:

>Fred Bauder wrote in part:
>
>
>
>>Eclecticology wrote:
>>
>>
>>>The choice is between information and pretty packaging.  If Wikipedia is
>>>going to have any long term reputation it will depend on the
>>>information, not the packaging.
>>>
Yup!

>>But see: http://credibility.stanford.edu/guidelines/index.html
>>
>>
>
>Which says in part "The visual design should match the site's purpose.".
>Ours does.
>
>
I still intend to work on the overall packaging of the site -- the skins
and the stylesheet.
But I'm aiming for simplicity & clarity.


subject: [Textbook-l] l need some free textbooks

in_reply_to:
<20030903190609.969F93DDA@xmxpita.excite.com>;
	from g_deen@excite.com on Wed, Sep 03, 2003 at 03:06:09PM -0400

body:
DEEN wrote:
> sir/madam,l'm a regular viewer of you website and l will like to
>have some free textbooks on the use of C++ as a programming language
>with CDs support if possible. l shall like them to be sent to the
>address below: GAFAR DEEN,C/O MR R.O OSHINEYE,P.O.BOX 1223
>APAPA,LAGOS,LAGOS STATE,NIGERIA.101010.  pls mail me back if my
>request shall be granted thanks,GAFAR DEEN.

The day will come when we can answer this question by directing this
gentleman to the nearest Red Cross/Red Crescent office to pick up a
book pack.

--Jimbo


from_name: Jason Richey

subject: [Wikitech-l] Path for fonts in Colonge skin

in_reply_to:
<3F5756E7.4080102@planetunreal.com>;
	from tarquin@planetunreal.com on Thu, Sep 04, 2003 at 04:14:47PM
	+0100

body:
I'll do it, just tell me what usernames I am adding...

Jason

tarquin wrote:

> Not to harp on, but it's been weeks since Jimbo said me & a few others
> could have server access to update from CVS -- what has to happen for
> this to happen?

--
"Jason C. Richey" <jasonr at bomis.com>


from_name: Guillaume Blanchard

subject: [Wikitech-l] PHP Wiki

body:
Hello all.

I installed an old version of Wikipedia (a personal backup of an early Phase
III version) on my server. But I have many (small) problems with it. I don't
need all Wikipedia stuffs (basic Usemod Wiki is enough), but as I want to
customize it, I'm looking for a PHP/MySQL version. My questions are:

Does some one know where I can found a PHP version of Usemod Wiki?

Do you restart the PHP version of Wikipedia from scratch?

Aoineko


from_name: Anthere

subject: [Wikipedia-l] Logo issue

body:
Olie just reported someone replaced yesterday logo 124
per logo 12.

This is a problem perhaps as it resulted from too many
votes for 12, and perhaps loss of votes for 124

--------

Three users have voted for logo 12 listed at 124

I suggest they confirm their vote for the logo 12.
They have been removed from logo 124 (the original was
replaced)

[[User:H?mant|H?mant]],
[[User:Jeanmichel|JeanMichel]],
[[User:Pit|pit]]

Moreover, the following users have not seen logo 124,
and should be told to reconsider their vote perhaps

Adam Bishop
Jtvisona
ELF
Gandalf
Sebastianwallroth
Snooweatinganima
vitred
Sebastianwallroth
Wanjos
Dgrant
Webkid
Geoffrey
Eclecticology
Arnt Richard Johansen
Ryan Cable
Canrocks
Kupope
Terberlo
Davidkoree
Sansculotte
Eslios
MyNameIsClare
Skood
Chbs
Alvaro
Lorax
SanderSpek
Tux2000
Ramesh
Stygian
Gaz
Tex
Ryo
Nataraja
Teresag
RAF

Following options.

Either 124 have enough vote to be in the top 10, and
we forget about it

Or not

* We have 12 hours to find all these people above and
make them come back

* we tell User:Abi that never mind his logo

* We admit it per default, making 11 top 11

So ?

(ah; voting security :-))

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


from_name: Stan Shebs

subject: [Wikipedia-l] Gray's Anatomy

body:
Magnus Manske wrote:

> As we are short on medical topics, I went to [[Requested articles]]
> and created a stub on [[Ethmoid bone]]. Then I realized that there's
> [[Gray's Anatomy]] from 1908, in the public domain, according to the
> article.

No different from a 1911EB lift I would say.  The "eternal verities" are
still good,
such as the shape of a bone, but beware of conclusions about structures'
purposes
and functioning, often new research data about those.

Stan


subject: [Wikipedia-l] logo issue

body:
Forgot to say that logo 12 is 19th and logo 124 is 9th

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


from_name: Magnus Manske

subject: [Wikipedia-l] Gray's Anatomy

body:
As we are short on medical topics, I went to [[Requested articles]] and
created a stub on [[Ethmoid bone]]. Then I realized that there's
[[Gray's Anatomy]] from 1908, in the public domain, according to the
article.

So I copied the text and the images from www.bartleby.com, who claim to
have the original thing. I didn't copy HTML but only the text, so no
bartleby markup here.

Questions:
* Can we use these? AFAIK, scanning&OCR is not a copyrightable thing.
* Should we use these? Wikified, of course, as I did. They'd cover
plenty of topics in the medical area, but may be a little old and heavy.
OTOH, this is wikipedia; if you don't like the style, edit!

Magnus


from_name: Chris Seaton

body:
Hello,

I have some extra time on my hands so I'm looking to do some development
on Wikipedia, as people always seem to be complaining about a lack of
developers.

I'm just getting the hang of things, browsing the source. I'm a good PHP
developer, but databases aren't my strong point (I can use them, but
can't really administer them).

This is just a little patch to modify the fonts of the stats section of
the colonge skin. This section is currently in serif, but the rest of
the page is in a sans font, so it looks out of

I was just planning to go through bugs and feature requests looking for
things that I can manage, is there something more pressing that you
would like to direct me to?

Also, how frequently is the English wikipedia updated to use the CVS
code?
--
Chris Seaton

chris at chrisseaton.com
http://www.chrisseaton.com/
-------------- next part --------------
--- phase3/stylesheets/cologneblue.css	2003-09-04 13:16:25.000000000 +0100
+++ phase3/stylesheets/old_cologneblue.css	2003-08-13 13:44:37.000000000 +0100
@@ -46,7 +46,7 @@
  padding: 0;
 }
 #pagestats {
- font-family: Verdana, Arial, sans-serif;
+ font-family: Times, serif;
  color: black;
  font-size: 9pt;
 }


from_name: Karl Wick

subject: [Textbook-l] annotated texts

body:
Magnus,

It must be thrilling to wield such power in your fingers
... I for one love the "quick" coded example you did for
annotated texts.

Someone said that with a script we can inport all of
Shakespeare's works into Wikified format relatively easily.
Does anyone have code that does that already or do we have
to write new scripts ?

Man this project just keeps getting better.

Karl

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


from_name: Jake Nelson

subject: [Wikipedia-l] Gray's Anatomy

body:
Magnus Manske said:
> * Can we use these? AFAIK, scanning&OCR is not a copyrightable thing.
The content of the book isn't, which typically means text is free game...
but actual scanned images can be copyrighted. (or so I recall the gist of it
from
Project Gutenberg and Distributed Proofreaders discussion- IANAL)

> * Should we use these? Wikified, of course, as I did. They'd cover
> plenty of topics in the medical area, but may be a little old and heavy.
> OTOH, this is wikipedia; if you don't like the style, edit!
The medical topics in Wikipedia are woefully under-filled (probably because
people are wary about that whole thing of being considered a source of
medical advice, and it's very heavy stuff)... I think this would be a
tremendous boost. And yes, we can always clean it up as we go. It's easier
to restyle and reformat something than to supply it in the first place.

So I'd suggest putting in as much text as possible, but I'm unsure about
images
from there. Alternatively, there might be a PD scan out there
somewhere... and if not, it might be something relatively easy to find. I've
got some used book contacts, I can look around and see if I can snag a copy
cheap. If so, I can scan in any images needed.

-- Jake


from_name: Daniel Mayer

subject: [Wikipedia-l] Gray's Anatomy

body:
Magnus wrote:
>As this is not my field of expertise, maybe a disclaimer
>at the top should help, like
>
>''This article is based on [[Gray's Anatomy]]. Some
>information might be outdated.''

A reference at the bottom would be better and is the same thing we do with
EB1911 text. Why is this on Wikipedia-l instead of WikiEn-l?

--mav


from_name: Geoffrey Thomas

subject: [Wikitech-l] Installing MediaWiki on Windows

body:
I installed PHP and it works, and MySQL and it seems to work. However,
when I run install.php, it gives an error when trying to create the
database wiki-db, and aborts. Using the mysql.exe client, I haven't
been able to create databases with hyphens in their names, though
normally-named databases work fine. Is this something I need to
reconfigure on Windows's MySQL?

-[[User:Geoffrey]] Thomas

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


from_name: Geoffrey McRae

subject: [Wikitech-l] Re: PHP Wiki

body:
Hi, I am currently developing a PHP wiki engine called svsWiki, it will do
everything that you are looking for, the only problem is that I have hit a
road block, I need a function that will do the conversion from wiki to html,
I am looking at the NEWS markup system that has been brainstormed here:
http://www.cheeky.house.cx/cgi-bin/nemowiki.pl?NEWS.

If anyone is interested in writing me a clean function or class that would
do this it would be much appreciated, most of the core is complete and
general concept and design is done on the MySQL end, the idea of this wiki
is to make it as user friendly as possible with a good user management
system and a decent themeing system.

go here for more info on my wiki engine:
http://www.spacevs.com/cgi-bin/wiki.pl?SvsWiki

Regards
Geoff

PS: I found PhpWiki to be very very poor performance wise.

----- Original Message -----
From: "Brion Vibber" <brion=e+AXbWqSrlAAvxtiuMwx3w at public.gmane.org>
Newsgroups: gmane.science.linguistics.wikipedia.technical
Sent: Thursday, September 04, 2003 12:38 PM
Subject: Re: PHP Wiki

> Guillaume Blanchard wrote:
> > I installed an old version of Wikipedia (a personal backup of an early
Phase
> > III version) on my server. But I have many (small) problems with it. I
don't
> > need all Wikipedia stuffs (basic Usemod Wiki is enough), but as I want
to
> > customize it, I'm looking for a PHP/MySQL version. My questions are:
> >
> > Does some one know where I can found a PHP version of Usemod Wiki?
>
> No such thing exists; UseModWiki is written in Perl.
>
> There are many wiki programs written in PHP; PhpWiki is fairly popular,
> and I believe our diff function is borrowed from it, but otherwise it
> bears no relation to our code. I don't know how similar it is in
> formatting etc.
>
> See: http://phpwiki.sourceforge.net/
>
> > Do you restart the PHP version of Wikipedia from scratch?
>
> The current (phase 3) code was largely written anew by Lee Daniel
> Crocker, but partially based on the phase 2 code. The phase 2 code was
> written from scratch by Magnus Manske. A few parsing functions might
> have been based directly on UseModWiki code (?) but the overall code
> structure is totally different.
>
> -- brion vibber (brion @ pobox.com)


from_name: Adam Bishop

subject: [Wikipedia-l] Re: Logo issue

body:
I didn't vote for either 12 or 124, so that's one less person on your list
:)

Adam

>From: "Olie ze kat" <duprezolivier at nordnet.fr>
>Reply-To: Olie ze kat <kat at olid.fr.st>, wikipedia-l at Wikipedia.org
>To: wikipedia-l at Wikipedia.org
>Subject: [Wikipedia-l] Re: Logo issue
>Date: Thu, 4 Sep 2003 21:43:54 +0200
>
>Anthere <anthere6 at yahoo.com>, l'ami(e) des kats,
>avait papatt? dans sa niouze :
>
>| Olie just reported someone replaced yesterday logo 124
>| per logo 12.
>|
>| This is a problem perhaps as it resulted from too many
>| votes for 12, and perhaps loss of votes for 124
>|
>| --------
>|
>| Three users have voted for logo 12 listed at 124
>|
>| I suggest they confirm their vote for the logo 12.
>| They have been removed from logo 124 (the original was
>| replaced)
>|
>| [[User:H?mant|H?mant]],
>| [[User:Jeanmichel|JeanMichel]],
>| [[User:Pit|pit]]
>|
>| Moreover, the following users have not seen logo 124,
>| and should be told to reconsider their vote perhaps
>|
>| Adam Bishop
>| Jtvisona
>| ELF
>| Gandalf
>| Etc...
>
>I think it will be too hard to contact all...because we dont know for all
>their
>basic Wikipedia Where we will be sure to contact.
>
>|
>| Following options.
>|
>| Either 124 have enough vote to be in the top 10, and
>| we forget about it
>|
>| Or not
>|
>| * We have 12 hours to find all these people above and
>| make them come back
>
>Too few to repair what the logo 124 lost !
>
>|
>| * we tell User:Abi that never mind his logo
>|
>| * We admit it per default, making 11 top 11
>
>Yes... logo 124 was always in top 10 ... If tomorrow it will not in top 10,
>I
>suggest that we add it on final voting.
>
>|
>| So ?
>|
>| (ah; voting security :-))
>|
>
>I'm too surprised that it could be a vandalism... We must survey more if
>its not
>a deceit :o(
>
>
>NB: H?mant has confirmed that he wanted to vote for logo 12...Somebody
>(deutsch)
>can explain to Pit on his personal page
>http://de.wikipedia.org/wiki/Benutzer:Pit that he must confirm his vote for
>logo
>12 (simply move his name with another votes of logo 12)...Thank :op
>--
>Olie ze kat ---------  http://www.olid.fr.st
>
>
>_______________________________________________
>Wikipedia-l mailing list
>Wikipedia-l at Wikipedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikipedia-l

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail


body:
Sorry, I used diff wrong. Attached is the proper patch.

On Thu, 2003-09-04 at 13:25, Chris Seaton wrote:
> Hello,
>
> I have some extra time on my hands so I'm looking to do some development
> on Wikipedia, as people always seem to be complaining about a lack of
> developers.
>
> I'm just getting the hang of things, browsing the source. I'm a good PHP
> developer, but databases aren't my strong point (I can use them, but
> can't really administer them).
>
> This is just a little patch to modify the fonts of the stats section of
> the colonge skin. This section is currently in serif, but the rest of
> the page is in a sans font, so it looks out of
>
> I was just planning to go through bugs and feature requests looking for
> things that I can manage, is there something more pressing that you
> would like to direct me to?
>
> Also, how frequently is the English wikipedia updated to use the CVS
> code?
-------------- next part --------------
--- phase3/stylesheets/old_cologneblue.css	2003-08-13 13:44:37.000000000 +0100
+++ phase3/stylesheets/cologneblue.css	2003-09-04 13:16:25.000000000 +0100
@@ -46,7 +46,7 @@
  padding: 0;
 }
 #pagestats {
- font-family: Times, serif;
+ font-family: Verdana, Arial, sans-serif;
  color: black;
  font-size: 9pt;
 }


body:
Chris Seaton wrote:

>Hello,
>
>I have some extra time on my hands so I'm looking to do some development
>on Wikipedia, as people always seem to be complaining about a lack of
>developers.
>
>I'm just getting the hang of things, browsing the source. I'm a good PHP
>developer, but databases aren't my strong point (I can use them, but
>can't really administer them).
>
>
if you're not keen on databses, would you be interested in working on
implementing smarty? ( http://meta.wikipedia.org/wiki/Skins )

>Also, how frequently is the English wikipedia updated to use the CVS
>code?
>
>
whenever someone who has access takes care of it.
Not to harp on, but it's been weeks since Jimbo said me & a few others
could have server access to update from CVS -- what has to happen for
this to happen?


subject: [Wikipedia-l] Re: Re: Logo issue

body:
I know, sorry, I didn't explain myself very well....I was just there to see
the non-vandalized version.

>From: "Olie ze kat" <duprezolivier at nordnet.fr>
>Reply-To: Olie ze kat <kat at olid.fr.st>, wikipedia-l at Wikipedia.org
>To: wikipedia-l at Wikipedia.org
>Subject: [Wikipedia-l] Re: Re: Logo issue
>Date: Thu, 4 Sep 2003 22:17:55 +0200
>
>Adam Bishop <grenfell_ at hotmail.com>, l'ami(e) des
>kats, avait papatt? dans sa niouze :
>
>| I didn't vote for either 12 or 124, so that's one less person on your
>| list
>| :)
>|
>| Adam
>|
>
>You didn't understood... Anthere said that you didn't see the logo 124
>while you
>gone to vote because vandalism hidden it...
>
>Please, come back to see it, perhaps you will want to vote for him ;o)
>
>
>
>--
>Olie ze kat ---------  http://www.olid.fr.st
>
>
>_______________________________________________
>Wikipedia-l mailing list
>Wikipedia-l at Wikipedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikipedia-l

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail


from_name: Steve Vertigum

subject: [WikiEN-l] Pronunciations and IPA/SAMPA

body:
This is probably the most well thought out addressing
of this issue ever done on wp. I must say this is
impressive and inline with the consensus of

No unicode IPA on IE?? Hmm. Well, considering the
expensive workarounds you listed -- as necessary to
accomodate IE users -- for a fix that entirely in
Microsoft's domain, I would lean toward calling the
IPA Unicode as "standard" anyway, and let the ?? or
Xboxes be the problem of the IE end user. This is
already the case for any character sets that arent
loaded up anyway -- (I have yet to load a Hindi
character set for example. ;)  Soon afterward someone
will write a hack to accomodate IE no doubt, but
theres no reason not to push the Unicode IPA as the
standard right now.

But that still doesnt deal with the problem of easy
input via a Roman character set.  A little conversion
hack from the pseudovalues (/s/) to their IPA
equvalents should be a first priority , and I would do
it myself if I had the time, or could program a little
better (late bloomer ok..)

As always with apologies to the hackers,
-S-

--- David Friedland <david at nohat.net> wrote:
> There was some talk a while back about deciding on a
> standard method of
> indicating pronunciations on Wikipedia. Of course
> some people said
> pronunciations belong on Wiktionary, but that's
> beside the point: there
> are many articles where a discussion of the
> pronunciation of certain
> words is necessary, and there ought to be a standard
> way of notating that.
>
> In fact, there is. The International Phonetic
> Alphabet is ideally suited
> to marking pronunciations of words, and is flexible
> enough to describe
> broad transcriptions that represent how a word is
> pronounced in multiple
> dialects to minute phonetic details. This wisdom, of
> course, has been
> lost on the makers of most American dictionaries,
> who each insist upon
> using their own ad-hoc pronunciation scheme (one of
> my personal pet
> peeves). The _Cambridge Dictionary of American
> English_ is a notable, if
> perhaps not well-known, exception. The foremost
> dictionary of (mostly)
> British English, the _Oxford English Dictionary_
> uses IPA, as does the
> major Australian English dictionary,  _The Macquarie
> Dictionary_.
>
> But I digress. There are several pages on the
> Wikipedia that deal
> specifically with pronunciations, for example [[List
> of words of
> disputed pronunciation]]. And the way that the
> pronunciations are listed
> on that page is the worst possible mix of ad-hoc
> pronunciation schemes.
> In fact, some of the ad-hac pronunciations given I
> couldn't even figure
> what they meant. (does AHSK rhyme with American
> _task_ or _mosque_?).
> Clearly some kind of standard scheme is needed.
>
> I spent several hours today revamping that page,
> using IPA
> transcriptions and doing some serious research about
> which
> pronunciations are listed in what dictionaries. I
> put that page on
> [[List of words of disputed pronunciation/IPA]].
> However, I later
> discovered to my tremendous dismay that the IPA
> letters simply do not
> display in IE. The scheme for encoding IPA in ASCII,
> called SAMPA, is
> capable of encoding anything in IPA, but it is not
> particularly readable
> (although some might argue the same about IPA). It
> was designed to be
> machine-readable, and it doesn't really seem like an
> adequate solution.
> It uses lots of non-alphabetic characters to
> represent sounds (the 'a'
> in _cat_ is '{' in SAMPA), and as a result
> SAMPA-ized pronunciations are
> frankly ugly.
>
> Anyhow, it seems that just using the HTML entities
> for the Unicode IPA
> extensions is not an acceptable solution because it
> leaves IE users with
> lovely but useless rectangles where there ought to
> be IPA characters.
> There is a LaTeX extension called TIPA that allows
> the complete set of
> IPA characters and diacritics. If this were
> installed into the TeX math
> extensions, then a similar syntax could be used to
> generate images of
> the IPA from LaTeX input.
> I see the following possible solutions (in the order
> that I think is good):
>
> 1.) Auto-detect the browser and send IPA Unicode to
> browsers that
> support it and TIPA LaTeX images to those that
> don't. (Pros: attractive
> display of IPA for all users. Cons: lots of
> programming)
>
> 2.) Just send TIPA LaTeX images (Pros: attractive
> display of IPA. Cons:
> Uses images in text when for some users embedded IPA
> Unicode would look
> better)
>
> 3.) Store the IPA in a special format or in a
> special tag, auto-detect
> the browser and send IPA Unicode to browsers that
> support it and SAMPA
> to the rest. (Pros: doesn't require inserting images
> or using TeX. Cons:
> SAMPA is ugly and hard to read)
>
> 4.) Render IPA into GIFs or PNGs and just insert
> them as images. (Pros:
> compatible with everything. Cons: time-consuming,
> and difficult to change)
>
> 5.) Devise a Wikipedia-specific pronunciation scheme
> and just use that
> (blech!) (Pros: no coding required. Cons: YAAHPS
> (Yet Another Ad Hoc
> Pronunciation Scheme))
>
> 6.) Do nothing and continue to allow people to use
> ad-hoc pronunciation
> schemes (BLECH!!) (Pros: no action required. Cons:
> maintains status quo
> harms as described above)
>
> Of course, no. 1 requires doing some coding and
> testing for what may end
> up being a feature used on just a few pages. On the
> other hand, such
> code could possibly be extremely useful for the
> Wiktionary. In the
> meantime, I'm going to leave [[List of words of
> disputed
> pronunciation/IPA]] as it is, and wait for
> suggestions.
>
> Now of course there will be opponents of the IPA,
> because it's too
> technical or whatever reason. To those people I say
> the IPA for the
> purposes of representing English is really no more
> complicated than the
> pronunciation schemes used in American dictionaries,
> like the
> _Merriam-Webster Dictionary_, and the _Cambridge
> Dictionary of American
> English_, which is designed for learners of English,
> seems to do just
> fine with it.
>
> - David [[User:Nohat]]
>
>
> *
>
<http://www.wikipedia.org/wiki/List_of_words_of_disputed_pronunciation/IPA>*
>
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


subject: [Wikipedia-l] Logo issue

body:
Just curious, are any developers checking for
redundant ip's on the voting?

-S-

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


from_name: Erik Moeller

subject: [Wikipedia-l] Gray's Anatomy

body:
Jimmy-
> Perhaps it would be best to add them slowly, perhaps in an automated
> fashion,

Tricky, as we already have articles on most subjects. In these cases,
there should always be an individual decision by a human on whether

- the existing text should be kept and no further action should be taken
- the public domain text should be put somewhere (preferably on the talk
page)
- the stub should be replaced with the public domain text
- the public domain text should be integrated into the existing article.

Regards,
Erik


from_name: Tomos at Wikipedia

body:
Regarding Brion's point that there should be a good policy or monitoring
system of deletion/undeletion - I think that's right. But I am not sure if
all wikipedias became tolerant of unilateral deletion by admins. Have en.,
fr. and eo. all gone through that kind of change?

For one, admins on Japanese wikipedia don't delete pages uniliterally.
Stubs, testing (like "Hi there!"), pure junks (like falkjdslkjas) are turned
to blank, but people don't list them on Votes for Deletion unless the page
titles are really meaningless. There was once a discussion that we might
start deleting these stuff, but the idea was to create an expedite process
for those limited types of pages to be deleted, not uniliteral deletion.

Not that Japanese wikipedians cannot wait until others become ready, nor am
I suggesting that other wikipedias should do that (my impression is there
are really too many testing and junks at en. to be kept as blank pages), but
at least some Wikipedia is/are more or less free from that problem, I
imagine.

(Or maybe there is a tendency that wikipedia becomes tolerant of uniliteral
deletion over time, and japanese wikipedia will go down the path?)

Regarding Toby's point that DMCA protects the project - I am not very sure
about the implication of that to admins living elsewhere. There is a
japanese law defining legal responsibilities of BBS admins, etc. The law
seems to hold admins responsible if they know that illegal contents
(defamation, obscenity, copyright violation, etc.) are there, and they do
not delete illegal contents in a timely manner. And the fact that admins are
just volunteers do not seem to free from liability - there are cases where
volunteer BBS admins are found to be guilty in the court (that was a
defamation case).

The location of server is also said to be irrelevant at least in certain
cases that I looked at, when the contents are there mainly for japanese
users.

Now, my knowledge about these laws and issues of international jurisdiction
are so limited that I need more advice than stating my opinion here, but if
I have to choose now, I would not bet on the possibility that DMCA protects
all admins at Japanese wikipedia regarding copyright violations.

Regards,

Tomos

_________________________________________________________________
Send and receive larger attachments with Hotmail Extra Storage.
http://join.msn.com/?PAGE=features/es