body:
> There is some truth in your statement.  But: for editing purposes
> jumping line length don't hurt that much

Switching line lengths require more effort on the part of the human brain
and lead to semantic interpretations of the breaks (as emphasis, pause
etc.).

Compare:

Messages from Communities Around the Globe Palestinians and international
friends from the United States, the UK, and the Netherlands marched along
Sea Street, Sharia al Baha, one of the central streets in Rafah Camp. As
they approached the center of town they began to shout through bullhorns
in Arabic "Hurriyah la Falesteen! Hurriyah la al Iraq! Hurriyah la Rafah!
Hurriyah la Baghdad!" and in English "Freedom for Palestine! Freedom for
Iraq! Freedom for Rafah! Freedom for Baghdad!"

vs.

Messages from Communities Around the Globe Palestinians
and international
friends from the United States, the UK, and the Netherlands
marched along
Sea Street, Sharia al Baha, one of the central streets
in Rafah Camp.
As they approached the center of town they began to
shout through
bullhorns in Arabic "Hurriyah la Falesteen! Hurriyah la
al Iraq!
Hurriyah la Rafah! Hurriyah la Baghdad!" and in English
"Freedom for
Palestine! Freedom for Iraq! Freedom for Rafah! Freedom for
Baghdad!"

Since you have to read to edit, this is a very serious problem.

> (Emacs hat M-q to work around
> those problems...)

Yes, but people with different line lengths have to keep doing this to fix
each other's annoying breaks. Furthermore, most people do use the browser-
internal editor, like it or not, for convenience reasons alone. I do so
myself a lot because Mozilla has no external editor support and cannot
paste more than 4000 bytes from most other applications on Linux.

For these reasons, I will probably revert any edits I see which needlessly
insert linebreaks into text.

> and more important I simply depend on broken
> lines -- grep, sed and awk work best on those line.

I do not see the advantage here -- in fact, you will have to go to extra
trouble when doing a regex on a paragraph with linebreaks in it, since you
usually care about the paragraph, not about the line. Semantically,
however, the linebreaks are a bug that has a long history in the Unix
world.

BTW, if you used vim, you could just do ":set lbr" to turn on soft
wrapping...

Regards,

Erik


list: wikitech-l

source: pipermail-mbox

from_name: Tomasz Wegrzanowski

subject: [Wikitech-l] Re: <abbr>

body:
On Tue, Mar 18, 2003 at 07:29:52AM +1200, Richard Grevers wrote:
> Abbr has always been regarded as structural markup and thus has survived
> through unto
> XHTML 1.1 strict. Yet ironically, deprecated presentational stuff like <b>
> is supported.
> A Wiki equivalent of <abbr> is needed then (and <acronym>, presumably.

Why do we need it ?
First, they're silly and were never widely used.
Second, what's wrong with [[jezyk angielski|ang.]] ?


list: wikien-l

from_name: Richard Grevers

subject: [WikiEN-l] LOTR intro's

body:
I've just noticed* that back in December, Magnus Manske edited a bunch of
newly added articles about characters and geopgraphical features from
Tolkien's works by prefacing them with the explanatory note:

''The following information belongs to [[the Lord of the Rings]]
[[fantasy]] [[novel]]''

Which is of course much better than having no indication that the article
refers to a work of fiction. However, many of the articles are actually
about people and places from [[The Silmarillion]].
So I was wondering if there is a preferred format for introducing articles
about literary ephemera.

My first attempt is along the lines of In ''[[The Silmarillion]]'' by
[[J.R.R. Tolkien]] the '''foo''' is a...

--
Richard Grevers


subject: [Wikitech-l] Re: Re: <abbr>

body:
On Tue, Mar 18, 2003 at 08:02:27AM +1200, Richard Grevers wrote:
> Are there situations where you might need to expand an abbreviation
> without it being a wiki-link?

Very rarely I think. Usually abbreviation is either known to absolutely
everyone, like `kg' or `etc', or specific to some domain of knowledge, and
article about it should be written.


from_name: Jesse Alter

subject: [WikiEN-l] Disregard this message

body:
I am testing my mail filters. I hate replying to a single message when I
receive a digest, so I set up filters to organize mail from the list
into a separate folder. Sorry; please disregard.


subject: [WikiEN-l] Re: LOTR intro's

body:
I put a * in my previous post and then forgot the footnote.
My current Wikikarma technique is to hit random page until I see something
that needs fixing (usually a typo or a bad phrasing, occasionally a fact.)
--
Richard Grevers


from_name: tarquin

subject: [Wikitech-l] Re: Re: <abbr>

body:
Tomasz Wegrzanowski wrote:

>On Tue, Mar 18, 2003 at 08:02:27AM +1200, Richard Grevers wrote:
>
>
>>Are there situations where you might need to expand an abbreviation
>>without it being a wiki-link?
>>
>>
>
>Very rarely I think. Usually abbreviation is either known to absolutely
>everyone, like `kg' or `etc', or specific to some domain of knowledge, and
>article about it should be written.
>
"kg", "cm" etc should be linked, together with the number they follow,
to an [[orders of magnitude]] chain page.
[[%]] links correctly to an article :-)

>
>


from_name: Christopher Mahan

subject: [WikiEN-l] User:RachelCorrie

body:
Really?

What's wrong with that?

It's not like her userpage needs to be NPOV, you know.

Now, it may be in bad taste or blatantly political, or may ruffle
your feathers, but maybe she's gathering information on the subject
while it's hot.

Perhaps a better course of action would be to engage this contributor
into a dialog.

--- Jesse Alter <jesse at snacksoft.com> wrote:
> The user RachelCorrie is using their user page to show photos of
> Rachel
> Corrie and links about her death. She died while playing chicken
> with an
> Israeli bulldozer, in protest of the destruction of Palestinian
> settlement. The user has made no contributions other than turning
> their
> user page into a non-NPOV memorial to Rachel Corrie. I move that
> the
> user be banned. If their IP can be matched to another user, I think
> that
> the user should be warned against doing that in the future.
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikien-l

=====
Christopher Mahan
chris_mahan at yahoo.com
818.943.1850 cell
http://www.christophermahan.com/

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com


list: wikipedia-l

from_name: abhio at vsnl.net

subject: [Wikipedia-l] a suggestion

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


from_name: Stevertigo

subject: [WikiEN-l] User:RachelCorrie

body:
No, I disagree - in fact the user is already contributing to other pages as
well. You should welcome her, and her new contributions, and be incouraging,
and not a snot that is trying to advocate severe measures against a
legitimate user simply on the basis of your cynical and callous political
views. No apology is necessary, Jesse, just think before you type next
time. -SV

Jesse typed... > >The user RachelCorrie is using their user page to show
photos of  Rachel Corrie and links about her death. She died while playing
chicken  with an Israeli bulldozer, in protest of the destruction of
Palestinian  settlement. The user has made no contributions other than
turning their user page into a non-NPOV memorial to Rachel Corrie. I move
that the user be banned. If their IP can be matched to another user, I think
that
 the user should be warned against doing that in the future.


from_name: Ray Saintonge

subject: [WikiEN-l] User:RachelCorrie

body:
Jesse Alter wrote:

> The user RachelCorrie is using their user page to show photos of
> Rachel Corrie and links about her death. She died while playing
> chicken with an Israeli bulldozer, in protest of the destruction of
> Palestinian settlement. The user has made no contributions other than
> turning their user page into a non-NPOV memorial to Rachel Corrie. I
> move that the user be banned. If their IP can be matched to another
> user, I think that the user should be warned against doing that in the
> future.

User pages are not subject to the same NPOV requirements as articles.
 Some of this material could even be put on a biographical article about
Rachel Corrie.  Clearly she had the courage to back up her beliefs with
her life when she protested the criminal destruction of Palestinian homes.


subject: [WikiEN-l] the term 'USER'

body:
Doesnt it sound well... anti-collegial, ...

I suggest maybe "Comrade:name" or com: for short...

of editor: or ed: for short... or contributor... cont: for short...


subject: [Wikitech-l] <abbr>

body:
How come wikipedia doesn't support markup such as <abbr
title="Sergeant">Sgt.</abbr>
(It currently displays the raw HTML code)

--
Richard Grevers


from_name: Toby Bartels

subject: [WikiEN-l] Turks and Kurds

body:
Stevertigo wrote in part:

>[[Turks and Kurds]], eh? Wow, that's *clear... So, expanding on the tone of
>[[Turks and Kurds]], perhaps: [[Turk and Kurd relations:From cordial
>handshakes to ethnic cleansing]]... Lets say not. *Violence is better - at
>least it *says someting.. but its unfitting...

That's it!: [[Turk and Kurd relations]].
(Or [[Turko-Kurdish relations]], but I'm not sure of
the correct adjectives in this case.)

-- Toby


from_name: Brion Vibber

subject: [WikiEN-l] the term 'USER'

body:
On Mon, 2003-03-17 at 23:32, Stevertigo wrote:
> Doesnt it sound well... anti-collegial, ...
>
> I suggest maybe "Comrade:name" or com: for short...
>
> of editor: or ed: for short... or contributor... cont: for short...

Incidentally, the Polish, Esperanto, and Czech wikipedias use the local
equivalent of 'Wikipedian' for the user page namespace. (Respectively,
that's Wikipedysta:, Vikipediisto:, and Wikipediista:)

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030318/c00d631a/attachment.pgp


subject: [WikiEN-l] User:RachelCorrie

body:
The user RachelCorrie is using their user page to show photos of Rachel
Corrie and links about her death. She died while playing chicken with an
Israeli bulldozer, in protest of the destruction of Palestinian
settlement. The user has made no contributions other than turning their
user page into a non-NPOV memorial to Rachel Corrie. I move that the
user be banned. If their IP can be matched to another user, I think that
the user should be warned against doing that in the future.


from_name: Erik Moeller

subject: [WikiEN-l] Re: WikiEN-l digest, Vol 1 #212 - 14 msgs

body:
> If the search feature is slowing down the site, I think using Google
> would be a satisfactory permanent alternative. We've been using it
> for years at the PR Watch web site, with no complaints.

I'm very much against this. Having search results in realtime is of
crucial importance for serious article work to avoid duplicates. The
Google spider only comes ever so often and misses a lot. PR Watch is one
thing, Wikipedia is a couple orders of magnitude bigger, though. As a
very, very temporary hack, the Google search is fine. But we need to get
the realtime search (with wikisource no less!) back up and running ASAP.

If we have to disable critical features to keep the site running, we may
as well disable editing altogether until we have raised enough money to
buy a bigger server and/or hire developers.

As for optimization, there are still a few things we need to do, but we
also have to keep in mind that a single server is now running all language
Wikipedias + meta, and all of them are growing fast (faster now that
Google indexes us again). I hope we have the nonprofit setup soon, and if
we can't get it setup, we should start raising donations without an
organization. Kuro5hin raised 35000 dollars in a few days -- I'm not sure
if we can get that high, but we should certainly try.

Regards,

Erik


subject: [Wikipedia-l] Wikipedia unscheduled downtime over

body:
Wikipedia was down for almost two hours, from 8:36-10:22 UTC.

There was a kernel panic related to the filesystem driver; I'm not
entirely clear how this came about, but once that happens it stops
liking to talk to the disk, which is obviously somewhat problematic. ;)

The machine is rebooted and running smoothly again (big thanks to our
very own Jason Richey!)

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20030318/5089f916/attachment.pgp


from_name: Fred Bauder

subject: [WikiEN-l] the term 'USER'

body:
Editor

Fred

> From: "Stevertigo" <stevertigo at attbi.com>
> Reply-To: wikien-l at wikipedia.org
> Date: Mon, 17 Mar 2003 23:32:34 -0800
> To: <wikien-l at wikipedia.org>
> Subject: [WikiEN-l] the term 'USER'
>
> Doesnt it sound well... anti-collegial, ...
>
> I suggest maybe "Comrade:name" or com: for short...
>
> of editor: or ed: for short... or contributor... cont: for short...
>
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikien-l


from_name: Sheldon Rampton

subject: [WikiEN-l] Re: User:RachelCorrie

body:
Jesse Alter wrote:

>The user RachelCorrie is using their user page to show photos of Rachel
>Corrie and links about her death. She died while playing chicken with an
>Israeli bulldozer, in protest of the destruction of Palestinian
>settlement. The user has made no contributions other than turning their
>user page into a non-NPOV memorial to Rachel Corrie. I move that the
>user be banned. If their IP can be matched to another user, I think that
>the user should be warned against doing that in the future.

OK, then, while we're at it, I move that Jesse Alter be banned too.
He is using this listserv to make NPOV comments about the death of
Rachel Corrie ("died while playing chicken"). Granted, there's no
rule against POV on the listserv, but there's no rule against POV on
a user page either. If we're going to ban RachelCorrie over this, I
think it's only fair that we should ban Jesse too.

This is the same Jesse Alter who previously rose to the defense of
Vera Cruz/Lir, right? Hmm....
--
--------------------------------
|  Sheldon Rampton
|  Editor, PR Watch (www.prwatch.org)
|  Author of books including:
|     Friends In Deed: The Story of US-Nicaragua Sister Cities
|     Toxic Sludge Is Good For You
|     Mad Cow USA
|     Trust Us, We're Experts
--------------------------------


from_name: Jimmy Wales

subject: [WikiEN-l] Chris Mahan's inappropriate comments

body:
Christopher Mahan wrote:
> I apologize for the tone of my comment and I did not want to imply
> that you had modified other people's comments. It is just that from
> bitter experience I sometimes feel the need to pepper my writings.

Bravo to Christopher for this apology.

> Also, in the spirit of cooperation I need you to look at your own
> attitude about your contribution to the P. Please do not think this
> as an accusation of any sort, but rather as an exhortation to temper
> your approach to fit the collaborative nature of this medium.

I think this is a perfectly proper thing to ask.

--Jimbo


from_name: Anthere

subject: [Wikitech-l] Re: Real stats! (Re: what's going on with wikipedia ?)

body:
--- Brion Vibber <brion at pobox.com> wrote:
> On Sat, 2003-03-15 at 11:11, Giskart wrote:
> > Brion Vibber <vibber at aludra.usc.edu> wrote in
> > > Ok, NL stats are up to date. (Note: there are
> missing chunks from 21-24
> > > January and 17-20 February. Logs from those days
> appear to be lost...?)
> >
> > Thanks. Have you/can you/will you set it up so the
> stats are updateted
> > automaticly every x hours / x days ?
>
> Assuming I haven't screwed it up ;)  it should be
> rotating the logs and
> updating the stats every night from here out.
>
> -- brion vibber (brion @ pobox.com)

he, forgot to thank you Brion !

These are very interesting

Btw, in terms of statistics, it is very unfortunate
you had to disconnect the counter on the articles on
the en wiki. This is maybe one of the most important
one. It would nice on day, that for each article, we
have stats on the number of access per month or
week...might be interesting to "feel" which parts of
the encyclopedia are badly in need to be improved. No ?

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com


subject: [WikiEN-l] User:RachelCorrie

in_reply_to: <3E76B36B.4080505@snacksoft.com>; from jesse@snacksoft.com on Tue, Mar 18, 2003 at 12:49:31AM -0500

body:
User pages have never been subject to NPOV requirements.  The exact
parameters for what's appropriate on a userpage have never been set
with any firmness, though it's worth noting that I think that there
are some limits, since we aren't a free homepage provider.
(Pornography would be one example of something I think would be
inappropriate for a user page.)

This, though, doesn't even begin to approach those limits.

--Jimbo


subject: [WikiEN-l] Re: Search engine disabled

in_reply_to: <oprl69u5hdk4g8ki@news.gmane.org>; from dramatic@xtra.co.nz on Tue, Mar 18, 2003 at 10:24:31AM +1200

body:
Richard Grevers wrote:
> And if Google found out about this, how happy will they be?

Thrilled, I suspect.  We're sending people to google's pages where
they run advertisements, so they're making money.

They like money, I bet. :-)

--Jimbo


subject: [WikiEN-l] donations (was: Search engine disabled)

body:
Brion Vibber wrote:
> I assume this has been held off until there's an actual legal entity to
> receive the donations. Jimbo, any news on the non-profit front?

Soon.  Waiting for a response on some paperwork.

And yes, I think a donation mechanism is a good idea.

--Jimbo


subject: [Wikipedia-l] RE: Current events and Indymedia

body:
--- Yann Forget <yann at forget-me.net> wrote:
> Hi Anthere and others,

Hello Yann,

> So to resume, there are two objections against
> Indymedia :
> - biaised,
> - not GNU FDL.
> Is that right ?
>
> However, I would not agree to include a news project
> within Wikipedia. An
> encyclopedia needs some detachment, to stand back
> from current events, to be
> able to analyse the facts.

I am sure glad to hear you say that...:-)

> On nuclear issues, I would be the happiest if there
> would be NPOV articles (I
> mean scientific, on facts) on this subject. I think
> that people opinions in
> favor of nuclear power is mostly because of lack of
> knowledge about the
> subject. Well, that my opinion after 20 years of
> study of the question.
> And the articles on this in the English wikipedia
> are quite good for me.

thanks for improving a bit the field these past 2 days
:-)

> The article on Activiste was put on my page by
> Francis. I thought that it
> would be, with maybe some little changes, a good
> definition of French people

Sure. The difference in meaning is very important to
be mentionned. I agree.

But, the fact it was offered to you by Francis doesnot
make it look more like a non-biased encyclopedic
article. Don't you agree ?

I am reflecting on the activism article and the one on
La Hague, where you removed that big bunch of
information.
http://fr.wikipedia.org/wiki/Usine_de_retraitement_de_la_Hague

I am sure glad you appear to know on lot on the
nuclear matter. And I agree the text proposed is not
written in a neutral matter. But I think there is not
much wrong about the core of the infos given.

Similarly, I think there is not much wrong about the
core of the infos given on the activism article, but
the way it is written is not neutral and not
appropriate.

So, both situations need to be handled. It is not
because there are activists, but little pro-nuclear on
the french wiki, that one article should be censored
and not the other. So please, consider that, and do
not censor. Let's try to improve rather.

Thank you Yann

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com


from_name: Karl Eichwalder

subject: [Wikipedia-l] Re: New bug concerning lists

in_reply_to:
<8i0WrKxCpVB@erik_moeller> (erik_moeller@gmx.de's message of
 "17 Mar 2003 20:48:00 +0100")

body:
erik_moeller at gmx.de (Erik Moeller) writes:

> I do so
> myself a lot because Mozilla has no external editor support and cannot
> paste more than 4000 bytes from most other applications on Linux.

I just pasted
http://de.wikipedia.org/w/wiki.phtml?title=Ludwig_Tieck&action=edit
from Emacs (4066 chars) and adding 1000 chars were not a problem.

> BTW, if you used vim, you could just do ":set lbr" to turn on soft
> wrapping...

When time permits I'll check out longlines.el; for the moment I'll stay
away from web editing as much as possible ;)

--
ke at suse.de (work) / keichwa at gmx.net (home):              |
http://www.gnu.franken.de/ke/                            |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)


subject: [Wikipedia-l] Article count: Vote result

body:
Thomas Corell wrote:
> I hope we get an automatic voting next time, which don't show who's
> voting what. It will reduce possible influences. Nothing against
> publishing the result with names, but not during the voting process.

Oh, I think publishing the names as we go is a very good thing.  I
think possible influences are good.  If people I respect are voting
differently from me, it may give me pause.  If people I don't respect
are voting the same as me, it may give me pause.

Voting isn't supposed to be an alternative to open discussion and
consensus building, but a methodology to formalize it.

--Jimbo


in_reply_to: <8i4X5g6hpVB@erik_moeller>; from erik_moeller@gmx.de on Tue, Mar 18, 2003 at 03:19:00PM +0100

body:
I endorse this result.

--Jimbo


subject: [Wikitech-l] Re: <abbr>

body:
On 17 Mar 2003 04:26:44 -0800, Brion Vibber
<brion at pobox.com> wrote:

> On Mon, 2003-03-17 at 03:41, Richard Grevers wrote:
>> How come wikipedia doesn't support markup such as <abbr
>> title="Sergeant">Sgt.</abbr>
>> (It currently displays the raw HTML code)
>
> That's HTML markup, Wikipedia is a wiki and uses wiki markup.
>
> A limited subset of HTML markup is allowed, largely inherited from what
> UseModWiki allowed, and mainly with the intent of providing visual
> effects that we don't have a wiki way for (eg, tables).
>
> What you're talking about is semantic markup, which is a trickier thing
> by far.
>
Abbr has always been regarded as structural markup and thus has survived
through unto
XHTML 1.1 strict. Yet ironically, deprecated presentational stuff like <b>
is supported.
A Wiki equivalent of <abbr> is needed then (and <acronym>, presumably.
--
Richard Grevers


in_reply_to: <8i4X7I6SpVB@erik_moeller>; from erik_moeller@gmx.de on Tue, Mar 18, 2003 at 05:00:00PM +0100

body:
Erik Moeller wrote:
>     Secrecy is necessary for real world votes, but here we can
> afford some openness. It's the wiki way.

One reason secrecy is important in real world political voting is the
possibility of backlash against those who vote on the losing side.
That's not really possible here.  The winners can't round up the
losers into concentration camps.

--Jimbo


subject: [WikiEN-l] the term 'USER'

in_reply_to: <BA9CA6FB.7905%cunctator@kband.com>; from cunctator@kband.com on Tue, Mar 18, 2003 at 10:35:39AM -0500

body:
The Cunctator wrote:
> Why is a suggestion of authority to newbies a bad idea?

It might discourage or intimidate them from participating.  People
normally understand that anyone can be a "user" of a site, but usually
"editor" means you have to be appointed or authorized.

I think the term "user" helps to emphasize something radical about
the wiki concept -- ordinary *users* can edit the site.

It doesn't sound very radical to say that on wikipedia, the editors
can edit the site.  But it is radical, and intruiging to newcomers, to
hear that users can edit the site.

It's only a tidbit of language, though, so if we were starting from
scratch, I'd be easy to persuade either way.  But we already have a
lot of "User:" links, so it seems best to keep things the way they
are.

--Jimbo


subject: [Wikitech-l] Re: Re: <abbr>

body:
On Mon, 17 Mar 2003 20:52:24 +0100, Tomasz Wegrzanowski
<taw at users.sourceforge.net> wrote:

> On Tue, Mar 18, 2003 at 07:29:52AM +1200, Richard Grevers wrote:
>> Abbr has always been regarded as structural markup and thus has survived
>> through unto
>> XHTML 1.1 strict. Yet ironically, deprecated presentational stuff like
>> <b> is supported.
>> A Wiki equivalent of <abbr> is needed then (and <acronym>, presumably.
>
> Why do we need it ?
> First, they're silly and were never widely used.
> Second, what's wrong with [[jezyk angielski|ang.]] ?
>
come to think of it that does pop a title, doesn't it. Are there situations
where you might need to expand an abbreviation without it being a wiki-
link?

--
Richard Grevers


from_name: Poor, Edmund W

subject: [WikiEN-l] Turks and Kurds

body:
Well, even surfing requires study. Ya gotta take lessons from the most excellent master ya can find, if ya wanta surf with the best, Little Dude.

Uncle Ed

-----Original Message-----
From: Stevertigo [mailto:fofisiks at attibi.com]
Sent: Monday, March 17, 2003 6:11 PM
To: wikien-l at wikipedia.org
Subject: Re: [WikiEN-l] Turks and Kurds

> Ya know, I feel I'm being pulled into the Twilight Zone here. What is the
actual problem we are trying to solve, Steve?

Dude! Its all just school in summertime to you isnt it? -;) -SV

_______________________________________________
WikiEN-l mailing list
WikiEN-l at wikipedia.org
http://www.wikipedia.org/mailman/listinfo/wikien-l


subject: [Wikitech-l] Re: Re: <abbr>

body:
Andre Engels wrote:

>I don't agree that there should be an article on each such abbreviation;
>however, if there is no article, one should just write out the abbrevation
>in almost all cases. I tend to write out abbreviations like "etc.", "i.e."
>and "a.o." whenever they occur in an article I am editing.
>
This is a sensible position.  I would tend to make such changes in most
cases, but I would hope that eventually each of them does have an
article on Wiktionary.  Of the given examples, I tend to leave "kg" and
"etc." alone, I have mixed feelings about "i.e." where most English
speakers would understand "id est" even less, and I don't know what
"a.o." means.  I have to guess that it means "change it".

Eclecticology


from_name: Axel Boldt

subject: [WikiEN-l] the term 'USER'

body:
I never thought about it before, but I have to agree that "user" is not
a good description of what we are; in some software circles it also has
a negative connotation as in "just a user, what does he know".

Somebody who runs Linux is a user, somebody who writes code for Linux
is a contributor. Somebody who comes to Wikipedia in order to get some
information is a user, somebody who writes and edits articles is a
contributor.

While we probably all qualify as users in the above sense, I think we
are better described as "contributors" and I would favor a change. For
a smooth transition, the web server could simply redirect /wiki/user:*
to /wiki/contributor:*

Axel

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com


subject: [WikiEN-l] the term 'USER'

body:
Stevertigo wrote:

>Doesnt it sound well... anti-collegial, ...
>
>I suggest maybe "Comrade:name" or com: for short...
>
>of editor: or ed: for short...
>
This latter suggestion may give too much credit to our Uncle/Mister Ed. ;-)

>


from_name: Graham Burnett

subject: [WikiEN-l] RachelCorrie Re: WikiEN-l digest, Vol 1 #213 - 15 msgs

body:
> > The user RachelCorrie is using their user page to show photos of
> > Rachel Corrie and links about her death. She died while playing
> > chicken with an Israeli bulldozer, in protest of the destruction of
> > Palestinian settlement. The user has made no contributions other than
> > turning their user page into a non-NPOV memorial to Rachel Corrie. I
> > move that the user be banned. If their IP can be matched to another
> > user, I think that the user should be warned against doing that in the
> > future.
>
> User pages are not subject to the same NPOV requirements as articles.
>  Some of this material could even be put on a biographical article about
> Rachel Corrie.  Clearly she had the courage to back up her beliefs with
> her life when she protested the criminal destruction of Palestinian homes.

I agree with Ray.

Graham (Quercus Robur)


subject: [WikiEN-l] Google search; donations/grants (was: WikiEN-l digest, Vol 1 #212 - 14 msgs)

body:
--- Erik Moeller <erik_moeller at gmx.de> wrote:

>  Sheldon Rampton wrote:
> > If the search feature is slowing down the site, I think using
> > Google would be a satisfactory permanent alternative. We've been
> > using it for years at the PR Watch web site, with no complaints.
>
> I'm very much against this.

Me too. Our search is more up to date, more precise and doesn't have
ads. I don't think Google is a good permanent alternative.

> I hope we have the nonprofit setup soon, and if
> we can't get it setup, we should start raising donations without an
> organization. Kuro5hin raised 35000 dollars in a few days -- I'm not
> sure if we can get that high, but we should certainly try.

I don't think asking for donations is the way to go once a non-profit
is in place. The US is full of foundations that are happy to throw
money at half-baked proposals vaguely related to education. Pretty much
every billionaire sets up a foundation like that. You just write a
grant proposal and wait for the money to come in. Lots of people in
academia make their living that way. And we are talking at least an
order of magnitude higher than your figure above.

Axel

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com


subject: [WikiEN-l] Google search; donations/grants

in_reply_to: <8i4XCjzxpVB@erik_moeller>; from erik_moeller@gmx.de on Tue, Mar 18, 2003 at 06:52:00PM +0100

body:
Erik Moeller wrote:
> Sure, and Jimbo hasn't even ruled out the possibility of taking
> government money, although he snapped when I mentioned the EU ;-).

I should point out that this was quite some time ago, and not in the
context of the current Iraq crisis.

--Jimbo


body:
Axel Boldt wrote:

>>I hope we have the nonprofit setup soon, and if
>>we can't get it setup, we should start raising donations without an
>>organization. Kuro5hin raised 35000 dollars in a few days -- I'm not
>>sure if we can get that high, but we should certainly try.
>>
>
>I don't think asking for donations is the way to go once a non-profit
>is in place. The US is full of foundations that are happy to throw
>money at half-baked proposals vaguely related to education. Pretty much
>every billionaire sets up a foundation like that. You just write a
>grant proposal and wait for the money to come in. Lots of people in
>academia make their living that way. And we are talking at least an
>order of magnitude higher than your figure above.
>
I don't think that the Foundation should generally reject donations
except when they come with strings attached.  Being able to make a
modest donation within one's means can give a sense of belonging.

Two cautions come to mind right away:
    1. We need to avoid any perception that a person's value to the
Wikipedia community depends on the amount of donation.  The amounts may
need to be kept secret.
    2. There needs to be a refund mechanism for banned people who
somehow believe that their donation gives them a protection against banning.

Eclecticology


body:
> erik_moeller at gmx.de (Erik Moeller) writes:

>> I do so
>> myself a lot because Mozilla has no external editor support and cannot
>> paste more than 4000 bytes from most other applications on Linux.

> I just pasted
> http://de.wikipedia.org/w/wiki.phtml?title=Ludwig_Tieck&action=edit
> from Emacs (4066 chars) and adding 1000 chars were not a problem.

Yes, it works with emacs and a few other apps which use different
clipboard handling code. However, even then there are problems with some
special chars. See
http://bugzilla.mozilla.org/show_bug.cgi?id=56219
for the sordid details.

Regards,

Erik


from_name: Richard Grevers

subject: [WikiEN-l] Re: Search engine disabled

body:
On Mon, 17 Mar 2003 16:57:44 -0500, Poor, Edmund W
<Edmund.W.Poor at abc.com> wrote:

> Brian,
>
> If you cut page time from 4 seconds to 2 seconds, then it sounds like you
> cut performance time by 60% merely by letting Google do our searching!
> Way to go!!
>
And if Google found out about this, how happy will they be?
If I found out that someone was using my resources to run their search
facility, I'd either want to send them a nice big bill for that or purge
them from my database
--
Richard Grevers


from_name: The Cunctator

subject: [WikiEN-l] the term 'USER'

body:
On 3/18/03 9:34 AM, "Erik Moeller" <erik_moeller at gmx.de> wrote:

> The term User: is perfectly fine and would be a pain to update
> (external+internal links, Google etc.). Besides, Editor: suggests
> authority to newbies which is a bad idea. Wikipedian: is too easy to
> confuse with Wikipedia:.

Why is a suggestion of authority to newbies a bad idea?


subject: [WikiEN-l] Re: Re: Search engine disabled

body:
On Mon, 17 Mar 2003 14:33:10 -0800 (PST), Brion Vibber
<vibber at aludra.usc.edu> wrote:

> On Tue, 18 Mar 2003, Richard Grevers wrote:
>> And if Google found out about this, how happy will they be?
>> If I found out that someone was using my resources to run their search
>> facility, I'd either want to send them a nice big bill for that or purge
>> them from my database
>
> Oh yes, I'm sure they *hate* having more eyeballs see the advertisements
> in their search results.
>
But google searches on a single domain don't seem to trigger any
advertisements - neither a serious search like "hundred years' war" or a
likely ad-keyword such as "golf".

--
Richard Grevers


from_name: Daniel Mayer

subject: [Wikipedia-l] DW Widow

body:
>Dear Sir,
>
>I am the wife of David W. Thornton. I logged in to
>Wikipedia.org as "Lucie" on our computer under the
>User name, Black Widow . On my User Page, I clearly
>posted an official notice that I was the wife of
>User:DW.
>
>Today, after posting much hard work, I received the
>following message when I tried to log in:
>
>Your user name or IP address has been blocked by
>Maveric149. The reason given is this: Alias of DW
>
>You may contact Maveric149 or one of the other
>administrators to discuss the block.
>
>Sir, I would like to point out that this person
>calling him or her self Maverick149 has no proof
>or the statement he made as to any alleged alias.

This block was made a day after DW was banned - I had
no idea you even existed at that point.

>I searched your website and could find no official
>legal notice stating that you ban people from
>participating on your website on speculation or
>that you discriminate against wives / partners /
>friends / acquaintances etc. who may use our
computer.

/You/ were not blocked, DW was. Just look at the time
and date of the block - your user account didn't even
exist back then.

>Please advise why you authorized this discrimination.

>Sincerely yours. Christine Thornton, B.A., LL.B.

Now before you throw words like "discrimination"
around perhaps you can actually do a bit of homework
first?

In the future use the "Email this user" feature that
is located on an Admin's user page to ask for a block
removal. If you had visited my user page you would
have seen an easy to use and find shortcut to this
link. If you had visited the Admin page you also would
have seen /another/ such link right next to my user
name in the Admin list. If you had looked on the "IM a
Wikipedian" page you would have seen my AIM nickname.
The reason I'm pointing this out is that I check my
email 5-10 times a day and am usually on AIM while at
my home computer but I get Wikipedia-l in 10-20 email
digests which can take up to 2 days to arrive in my
mailbox (the IP block would probably have been lifted
within an hour if you had emailed me - instead it
looks like it lasted about a day). Another important
piece of information would be your IP address - but I
see you are editing again so everything is OK for now.

Daniel Mayer (aka mav)

WikiKarma
http://www.wikipedia.org/wiki/Richard_Ramirez (new)

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com


body:
--- Yann Forget <yann at forget-me.net> wrote:
> Hi,
>
> Did you read what I wrote on the Talk page of this
> article ?
> Didier made a NPOV summary of the long POV text of
> Athyvement, then Athyvement
> reverted Didier's text into his own text. So I just
> put Didier's text back.
>
> So, I didn't remove any information. And I think
> that, if some controversial
> information are given, the source has to be
> provided.
>
> Yann

Good evening Yann,

Problem is : where do the controversies really lie  ?
:-(((

When you remove a whole paragraph, because you say it
is controversial, could you at least state which point
(or points) exactly "is" controversial, so others
could help finding facts supporting or refuting the
claim ?

Do you reject the fact the crab was fished ? Or the
location it was taken ? Or the fact the crab was
picked up for analysis by ecologists ? Or the fact
Criirad did the analysis ? Or the contamination level
of 600 Bq found in the crab ? Or the amount of
radioactivity in some drinking water sources in France
? Or the official maximum level of radioactivity
allowed in food by french law ? Or the fact there is
no place on Earth without at least a bit of natural
radioactivity ? Or ....what ?

I agree it is not written the right way, but if you
just remove the text without saying which fact appears
false to you, how are we supposed to know where to
look for answers ?
I left you a list some hours ago. Please, comment Yann
:-) ant

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com


from_name: John Robinson

subject: [WikiEN-l] Re: Search engine disabled

body:
I just wanted to throw in my two cents regarding the search engine.

Using Google might be a good temporary solution, but I think using it
permanently, or even semi-permanently, would be a bad idea.  From an
editing standpoint, as Erik Moeller rightly pointed out, it can lead to
duplicate articles that aren't found for weeks or even months, if ever.

 From a user standpoint, it's even worse.  An example is [[Mexican Cave
Fish]]; created over a year ago, it doesn't show up in Google at all,
either under that name or under its current title [[Astyanax
mexicanus]].  (As an aside, that page probably needs to be moved by a
sysop.)  There is no way of easily telling how many pages are in a
similar situation.

A search function is essential; this thing doesn't have a conventional
index.  I strongly feel that Google is not up to the task.  I
completely understand the problems with server load, and hope we can
get that fixed in a more conventional manner soon (if another machine
in the rack is what's needed, I'd certainly contribute toward that, as
I'm sure would others).  However, I'm wondering if a more efficient
short-term remedy might be to find some other function, one less
integral to the use of the Wikipedia, to disable instead of the search
function.

Hephaestos


subject:
[Wikitech-l] Serious security issue with default Wikipedia
	installation

body:
On Tue, 2003-03-18 at 08:20, Juho Heikkurinen wrote:
> As I checked where it put the test file I noticed the the png I had
> uploaded had permissions set to -rwxr-xr-x

Hmm, that would be a PHP issue I suppose. We don't touch the permissions
as far as I know.

> 1. Upload whack_the_database.php
>
> 2. Point your browser to uploadpath/whack_the_database.php assuming it
> has access to LocalSettigs.php

This should probably be in the documentation:

*** FOR THE LOVE OF WIKI, CONFIGURE YOUR WEB SERVER TO DISABLE EXECUTION
OF PHP SCRIPTS AND OTHER SUCH THINGS IN THE UPLOAD DIRECTORY! ***

The simplest way to do this of course is to only _enable_ php for the
directories where your scripts are stored. What we use is a global
option to turn it off:
<IfModule mod_php4.c>
 php_admin_flag engine off
</IfModule>

then each wiki's business directory is explicitly turned on:
<Directory "/usr/local/apache/htdocs/w">
 <IfModule mod_php4.c>
  php_admin_flag engine on
 </IfModule>
 # other options...
</Directory>

This is in no way related to the executable bit, since php is usually
run as an apache module.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20030318/4fa6a585/attachment.pgp>


body:
On Tue, 2003-03-18 at 08:19, Thomas Corell wrote:
> For example: one important thing (IMHO) for Wikipedia is the speed of a
> database request. In the voting and in the discussion about the Article
> count nobody calculated the complexity of some of the options. I think
> some of the admins will refuse methods for this count which will need a
> lot of performance. And I would respect such a decision.

The live article count is maintained on an action-by-action basis. That
is, there's a stats table in the database that keeps track of a couple
of numbers, including the article count. When an article is created,
deleted, or modified, the software compares the previous text (if any)
with the new text (if any) and either increments or decrements the
counter if appropriate. Displaying the counter is simply a matter of
fetching one number from a table.

So there's really not much database impact; some of the ideas about
number of revisions or number of people editing would require a check of
the database for the article's history, but only individually as part of
the process of changing an article (and it'd be a drop in the bucket
between updating link tables and whatnot!)

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20030318/3779a9e6/attachment.pgp


subject: [Wikipedia-l] RE: Article count: Vote result

body:
>I endorse this result.
>
>--Jimbo

Even though every one of my top choices lost I endorse
this vote to. It was fair and I accept the results.

--mav

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com


from_name: Stevertigo

subject: [WikiEN-l] User:RachelCorrie

body:
>Jim:User pages have never been subject to NPOV requirements.  The exact
parameters for what's appropriate on a userpage have never been set with any
firmness..

I recall on the defunct Lir pages that one of the criticisms made, and
perhaps weighed.... was that "she used her user page to antagonize"... ??
The straw that BTCB, in otherwords?

> Ed's 2 cents: If I were in charge, I would remove the user:RachelCorrie
account...

I understand this.. but Ed...! For someone so keen to point out the
potential of people, and particularly new people... you fail to realize that
this is someone who potentially will make great contributions! Judging by
the notes, he/she either knew Rachel... or at the very least is (was) an
associate... We should feel honored here that someone close to someone who
made our top news is here, and feels welcome enough to display

I find it utterly stupid that it was previously suggested that she be
banned... after not even breaking a single rule! How *George Orwell...

All that said... Ed may have a point about the username... but lets wait
until the normal grieving process is over, and that person becomes involved
in other issues. Be well! --SV


subject: [WikiEN-l] User:RachelCorrie

body:
>Jesse wrote: You say no apology is necessary, but I'll apologize anyway.

This is a very honorable statement. I missed this message until after I
penned a response to Ed.... Please take this as an apology for the stupid
comment. -SV


body:
On 3/18/03 11:00 AM, "Erik Moeller" <erik_moeller at gmx.de> wrote:
>   Secrecy is necessary for real world votes, but here we can afford some
> openness. It's the wiki way.
>
Yeah, but voting *isn't* the wiki way.


body:
> I endorse this result.

This sounds kinda like the CIA putting its stamp of approval on a third
world election... ;)


body:
> >   Secrecy is necessary for real world votes, but here we can afford some
> > openness. It's the wiki way.
> >
> Yeah, but voting *isn't* the wiki way.

I agree that the openness is doable... just disagree with the method...
anyone could have set up a form and a server script to compile the results,
and published those results daily so that we could see the innards... I find
arguments against increasing efficiency, without corrupting collegiality, as
counterproductive... and certainly will bite WP in the ass if this
philosophy carries over into streamlining heavy bandwidth/editing issues, if
this project ever *really takes off... ;) -SV


subject: [WikiEN-l] Re: Search engine disabled

references:
<E506B3FF6BC1254C9AC1B948C380BC280CF5ED@sm-nyny-xm05.nena.wdpr.disney.com>
	 <oprl69u5hdk4g8ki@news.gmane.org> <20030318040712.C24751@joey.bomis.com>
	 <200303181934.h2IJYZuD021604@TheWorld.com>

body:
On Tue, 2003-03-18 at 11:34, Tom Parmenter wrote:
> |From: Jimmy Wales <jwales at bomis.com>
> |Richard Grevers wrote:
> |> And if Google found out about this, how happy will they be?
> |
> |Thrilled, I suspect.  We're sending people to google's pages where
> |they run advertisements, so they're making money.
> |
> Well, yes, but don't they sell search-engine support to individual
> sites?

They do, and for that you get other goodies that we moochers don't get.
http://www.google.com/services/

And for any doubters, this is NOT NOT NOT intended to be permanent or
semi-permanent. It should be gotten rid of as soon as possible.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030318/dc373f02/attachment.pgp


from_name: Lee Daniel Crocker

body:
> (Erik Moeller <erik_moeller at gmx.de>):
> > On 3/18/03 11:00 AM, "Erik Moeller" <erik_moeller at gmx.de> wrote:
> >>   Secrecy is necessary for real world votes, but here we can afford some
> >> openness. It's the wiki way.
> >>
> > Yeah, but voting *isn't* the wiki way.
>
> Obviously we have different definitions.

I'm with Cunc on that one: the Wiki way is jump first, ask
questions later.  I'm pretty down on voting as a way to
accomplish anything useful, but the openly-signed voting
process is at least better.  It's more like a record of
discussion than a vote.  The Wiki way would then be for the
person actually writing the code to look at the discussion
and let it influence him--but not 100%.  If he thought the
second most popular option was the one he wanted to implement,
he should do that.

--
Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lee/>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC


subject: [WikiEN-l] Re: Search engine disabled

body:
For all of you people in GoogleLove:

http://www.google-watch.org/jobad.html


subject: [Wikitech-l] Re: Re: <abbr>

body:
> (Ray Saintonge <saintonge at telus.net>):
> Andre Engels wrote:
>
> >I don't agree that there should be an article on each such abbreviation;
> >however, if there is no article, one should just write out the abbrevation
> >in almost all cases. I tend to write out abbreviations like "etc.", "i.e."
> >and "a.o." whenever they occur in an article I am editing.
> >
> This is a sensible position.  I would tend to make such changes in most
> cases, but I would hope that eventually each of them does have an
> article on Wiktionary.  Of the given examples, I tend to leave "kg" and
> "etc." alone, I have mixed feelings about "i.e." where most English
> speakers would understand "id est" even less, and I don't know what
> "a.o." means.  I have to guess that it means "change it".

I never use abbreviations when they can be avoided. I also write out
"that is" and "for example" and even "and so on"; we are not constrained
by the size limits of paper here.  I suppose measurement units are hard
to avoid though, but even there I'd write "kilogram" if it was just an
isolated use in an otherwise non-technical article.

--
Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lee/>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC


subject: [Wikitech-l] Serious security issue with default Wikipedia installation

body:
> (Juho Heikkurinen <juho at consumerium.org>):
> Hi.
>
> As I checked where it put the test file I noticed the the png I had
> uploaded had permissions set to -rwxr-xr-x
> which is not a good thing.

This isn't a security problem on Wikipedia because Apache is
configured not to execute anything outside the wiki directories.
But I can see it might be a problem for other installations, so
I added a "chmod(..., 0644)" to the code after the move.

--
Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lee/>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC


subject: [Wikitech-l] Attempt to set up a local wiki from scratch

body:
On Tue, 2003-03-18 at 12:10, Lee Daniel Crocker wrote:
> > (Michel Mouly <mmouly at wanadoo.fr>):
> >
> > wikipedia : the last versions of the files found on source forge,
> > loaded one by one (how to dump the CVS??)
>
> Get an account on Sourceforge. Install CVS (I have no idea how to
> do this for Windows). Then use:

Supposedly there's a program 'WinCVS' which has a windows interface that
some people use. As a unix-head, I just run Cygwin and use the
unix-style tool. :)

> > I tried to run rebuildindex.php, but it aborts, seemingly some
> > timer in the server (message is an overload indication). Is there
> > any way to do that without invoking the server? For instance, a
> > MySQL script would be handy!

PHP generally has an execution time limit (default is 30 seconds I
think). This makes sense for web stuff which should generally never take
that long, but is obviously not something you want for your admin
scripts which might take an hour or two for really big things.

I run these scripts from the command line:
  php rebuildIndex.php

This avoids the timeouts, gives me regular job control (well, under
Unix), and most importantly does not require the maintenance scripts to
be web-accessible!

Make sure your PATH is set appropriately, or use the full path to the
php executable, ie:
  c:\webserver\php\bin\php rebuildIndex.php

(or something like that? I've never run these things on Windows, I
always use Linux for my servers.)

> Hmm. Yes, if you load pages through SQL, you have to rebuild the
> indexes again. Maybe the French SQL dump was in an old format?
> Brion?

It should be current... As a reminder, the SQL dumps only include the
'cur' and 'old' tables. The link, recentchanges, and search index tables
are recreated by the rebuild scripts:
  rebuildLinks.php does links, recentchanges
  rebuildIndex.php does search index.

These, I think, rely on the tables already existing, so you should run
the createdb.php before importing the data. (Michel I think is already
doing this part right.)

Hmm, it occurs to me that we don't have a clean backup/rebuild system
for the uploads. Probably someone should look into that.

> > d) When I edit a page, the submit yields a blank page after a long
> > time. Likely to be a pb in the php scripts, but this seems beyond
> > my competence.

No idea...

> > e) After a submit on a new page, I can see the modification only
> > after deleting the IE cache and recalling wiki.phtml. I set the
> > browser to checking most recent version at each page download, but
> > the behaviour is the same.
>
> Got me there. I'm afraid I can't be much help for Windows.

IE has the crappiest reload button ever, in that it doesn't reload
unless you hold down control. Help with workarounds for this is
welcome...

> In all honesty, though, I don't think the Wikipedia software is
> really good for personal use.

I do agree. There hasn't been a public, packaged, numbered software
release for a reason: it's idiosyncratic, built for a single site, has a
lot of assumptions (like all those hard-wired strings talking about
Wikipedia and GNU FDL license for text!), and way overkill for most
purposes.

I'm not going to say, "don't use it!" But keep the same caveats that you
would have for an early pre-alpha release of any large application with
a lot of weird features. It's fragile, and if you're trying to get real
work done it might not be for you unless you're willing to put a lot of
effort into it.

>  There are a lot of smaller, simpler
> Wikis that do a great job--I use UseMod for my personal site,
> for example. I really wrote this one for one and only one goal:
> to run Wikipedia. If it's useful for other things,I certainly don't
> mind, but that's not a goal I ever had.

UseMod is also fairly easy to set up -- one perl script. :D

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20030318/59f45c09/attachment.pgp>


from_name: Andre Engels

subject: [Wikitech-l] Re: Re: <abbr>

body:
On Mon, 17 Mar 2003, Tomasz Wegrzanowski wrote:

> On Tue, Mar 18, 2003 at 08:02:27AM +1200, Richard Grevers wrote:
> > Are there situations where you might need to expand an abbreviation
> > without it being a wiki-link?
>
> Very rarely I think. Usually abbreviation is either known to absolutely
> everyone, like `kg' or `etc', or specific to some domain of knowledge, and
> article about it should be written.

I don't agree that there should be an article on each such abbreviation;
however, if there is no article, one should just write out the abbrevation
in almost all cases. I tend to write out abbreviations like "etc.", "i.e."
and "a.o." whenever they occur in an article I am editing.

Andre Engels


subject: [Wikitech-l] Re: Re: <abbr>

body:
> > and I don't know what
> > "a.o." means.  I have to guess that it means "change it".
>
> "amongst others" or "and others"

The traditional abbreviation for that is "et al.", another one
I always write out.

--
Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lee/>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC


from_name: Jesse Alter

subject: [WikiEN-l] User:RachelCorrie

body:
There were no contributions when I wrote to the list. It seemed to me at
the time that this was a person who already had another account and
created this one to get information on the site that would otherwise be
edited mercilessly. If this is an active user, and not just a user page,
then of course, by all means welcome them to Wikipedia (although their
contributions seem to be to her own user page, RK's user page, and a
talk page of an article). It seems the part of my brain responsible for
tact was switched off when I posted. With a clear mind, I suppose there
isn't a problem with this user, besides just "ruffling my feathers". As
Christopher suggested, a better course of action would be to engage them
into a dialog, which I plan to do if a problem comes up with this user.

However, please do not presume to know my political views. I don't
believe I've made them public, and they do not factor into this issue.
My quarrel had to do with a page being NPOV, not against my beliefs.

You say no apology is necessary, but I'll apologize anyway. I'm sorry
for jumping to conclusions and suggesting something as severe as a ban
when clearly my first step should have been to leave a note on the
user's talk page.

Stevertigo wrote:

>No, I disagree - in fact the user is already contributing to other pages as
>well. You should welcome her, and her new contributions, and be incouraging,
>and not a snot that is trying to advocate severe measures against a
>legitimate user simply on the basis of your cynical and callous political
>views. No apology is necessary, Jesse, just think before you type next
>time. -SV
>
>
>Jesse typed... > >The user RachelCorrie is using their user page to show
>photos of  Rachel Corrie and links about her death. She died while playing
>chicken  with an Israeli bulldozer, in protest of the destruction of
>Palestinian  settlement. The user has made no contributions other than
>turning their user page into a non-NPOV memorial to Rachel Corrie. I move
>that the user be banned. If their IP can be matched to another user, I think
>that
> the user should be warned against doing that in the future.
>
>


subject: [WikiEN-l] Re: User:RachelCorrie

body:
Sheldon Rampton wrote:

> Jesse Alter wrote:
>
>> The user RachelCorrie is using their user page to show photos of Rachel
>> Corrie and links about her death. She died while playing chicken with an
>> Israeli bulldozer, in protest of the destruction of Palestinian
>> settlement. The user has made no contributions other than turning their
>> user page into a non-NPOV memorial to Rachel Corrie. I move that the
>> user be banned. If their IP can be matched to another user, I think that
>> the user should be warned against doing that in the future.
>
>
> OK, then, while we're at it, I move that Jesse Alter be banned too. He
> is using this listserv to make NPOV comments about the death of Rachel
> Corrie ("died while playing chicken"). Granted, there's no rule
> against POV on the listserv, but there's no rule against POV on a user
> page either. If we're going to ban RachelCorrie over this, I think
> it's only fair that we should ban Jesse too.
>
Ouch! You got me!

> This is the same Jesse Alter who previously rose to the defense of
> Vera Cruz/Lir, right? Hmm....

Well, actually, I'd like to (posthumously) withdraw my objection to
Lir's banning. I've found through conversation with Lir that they ARE
posting as Susan Mason, and they are making personal attacks on people
and they're lacking a uhh...cooperative spirit.


subject: [Wikitech-l] MySQL 4.0

body:
In case you hadn't heard, MySQL 4.0.12 was officially declared
"production quality" by MtSQL AB.  This will be the first thing I
test with the test suite.

--
Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lee/>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC


subject: [WikiEN-l] User:RachelCorrie

body:
If I were in charge, I would remove the user:RachelCorrie account.

1. user page only hold propaganda photos & links
2. teasing RK
3. name sounds too much like the dead girl [[Rachel Corrie]]
4. no other contributions but creating the user page (and 2 talk comments)

Whoever it is, should just put their resources on Metawikipedia (no hold barred there).

My 2 cents.

Uncle Ed


body:
> (Michel Mouly <mmouly at wanadoo.fr>):
>
> wikipedia : the last versions of the files found on source forge,
> loaded one by one (how to dump the CVS??)

Get an account on Sourceforge. Install CVS (I have no idea how to
do this for Windows). Then use:

cvs -d <name>@cvs.wikipedia.sourceforge.net:/cvsroot/wikipedia checkout phpwiki

to get the sources all at once. Then just "cvs update" to get new
ones whenever they change.

> a) The script createdb.php fails if there is already a db. This is
> due to lack of deletion of table user_newtalk in buildTables.inc

Thanks; fixed.

> b) The database as obtained starting with an empty directory and
> running the script createdb.php is such that the search function
> always answers that it found nothing.
> Running rebuildindex.php corrects that. May be this is the normal
> policy, and rebuildindex.php must be run regularly??

It has to be run once; it became a separate script because those
tables and that functionality were added recently. I'll update the
docs.

> c) I loaded the current state of the french articles (smaller than
> the english, and I'm french btw). There again, basic functions
> runs correctly except for the search.
>
> I tried to run rebuildindex.php, but it aborts, seemingly some
> timer in the server (message is an overload indication). Is there
> any way to do that without invoking the server? For instance, a
> MySQL script would be handy!

Hmm. Yes, if you load pages through SQL, you have to rebuild the
indexes again. Maybe the French SQL dump was in an old format?
Brion?

> d) When I edit a page, the submit yields a blank page after a long
> time. Likely to be a pb in the php scripts, but this seems beyond
> my competence.
>
> e) After a submit on a new page, I can see the modification only
> after deleting the IE cache and recalling wiki.phtml. I set the
> browser to checking most recent version at each page download, but
> the behaviour is the same.

Got me there. I'm afraid I can't be much help for Windows.

> This being said, congratulations to all of you (and also Xitami,
> php and MySQL). It is quite impressive that the code and docs
> allowed me with my limited experience to go so far in so little
> time!

Well I had never used PHP or MySQL before I wrote it; no doubt
our shared ignorance helps us communicate.

In all honesty, though, I don't think the Wikipedia software is
really good for personal use. There are a lot of smaller, simpler
Wikis that do a great job--I use UseMod for my personal site,
for example. I really wrote this one for one and only one goal:
to run Wikipedia. If it's useful for other things,I certainly don't
mind, but that's not a goal I ever had.

--
Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lee/>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC


body:
> (Stevertigo <stevertigo at attbi.com>):
> > I endorse this result.
>
> This sounds kinda like the CIA putting its stamp of approval on a third
> world election... ;)

...except that Jimbo probably didn't engineer the result he's
endorsing.

--
Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lee/>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC


from_name: Brion Vibber

subject: [Wikipedia-l] Can't log in to Meta

body:
On Wed, 19 Mar 2003, Richard Grevers wrote:
> The Meta-wikipedia says I don't exist, yet my login name is working fine on
> most pages.

Before we go further: you are aware that each wiki has a separate user
database, and that you have to create the username separately on each
wiki, right? Have you ever logged in on meta.wikipedia.org before? Did you
create an account there?

-- brion vibber (brion @ pobox.com)


from_name: Tom Parmenter

subject: [WikiEN-l] Re: Search engine disabled

body:
|From: Jimmy Wales <jwales at bomis.com>
|Content-Disposition: inline
|Sender: wikien-l-admin at wikipedia.org
|Reply-To: wikien-l at wikipedia.org
|Date: Tue, 18 Mar 2003 04:07:12 -0800
|
|Richard Grevers wrote:
|> And if Google found out about this, how happy will they be?
|
|Thrilled, I suspect.  We're sending people to google's pages where
|they run advertisements, so they're making money.
|
|They like money, I bet. :-)
|
|--Jimbo

Well, yes, but don't they sell search-engine support to individual
sites?

Tom P.
O88


subject: [Wikipedia-l] Re: Can't log in to Meta

body:
On Wed, 19 Mar 2003, Richard Grevers wrote:
> On Tue, 18 Mar 2003 14:17:45 -0800 (PST), Brion Vibber
> > Before we go further: you are aware that each wiki has a separate user
> > database, and that you have to create the username separately on each
> > wiki, right? Have you ever logged in on meta.wikipedia.org before? Did
> > you create an account there?
> >
> I wasn't aware of that, because I'm not aware of it being stated clearly
> anywhere (the login page would be a good place!).

I'll add a note.

> Is that why there are no
> links from the english wiki to meta.wikipedia.org?

I'm not quite sure what you mean -- there are numerous links to meta from
the main page, recentchanges, and various other places.

> This raises another question: What provision is there to prevent someone
> else grabbing my wikipedia.en username on the meta wiki and appearing to be
> me? Or to prevent me registering as, say, Susan Mason on meta?

The same thing that prevents someone else from grabbing your wikipedia.en
username on slashdot.org or yahoo.com: politeness and/or lack of interest
in doing so.

-- brion vibber (brion @ pobox.com)


subject: [WikiEN-l] Re: the term 'USER'

body:
>>Richard Grevers:*what she said*

If there was a defense to be made for it, she put it quite
eloquently...:) -SV


from_name: Yann Forget

body:
Hi,

Did you read what I wrote on the Talk page of this article ?
Didier made a NPOV summary of the long POV text of Athyvement, then Athyvement
reverted Didier's text into his own text. So I just put Didier's text back.

So, I didn't remove any information. And I think that, if some controversial
information are given, the source has to be provided.

Yann

Le Mardi 18 Mars 2003 13:09, Anthere a ?crit :

> La Hague, where you removed that big bunch of
> information.
> http://fr.wikipedia.org/wiki/Usine_de_retraitement_de_la_Hague

--
http://www.forget-me.net
Alternatives sur le Net
http://keys.indymedia.org/showkey.py?key=0A34CBDA
gpg --keyserver keys.indymedia.org --recv-key 0A34CBDA


subject: [WikiEN-l] new macot idea

body:
http://meta.wikipedia.org/upload/8/8e/Nimmascot.png

:)


from_name: Erik Moeller

body:
Hi,

we have a winner. Because we did everything manually, vote counting has been
a bit of work, but now it's done and even with minor errors, the results are
fairly clear. The new article count system is going to be based on two
factors:

1) An article is counted if, trimmed of all trailing whitespace (blanks,
newlines etc.), it is longer than zero bytes (non-empty) AND
2) it contains at least one link.

Redirects, talk pages, user pages and Wikipedia: pages are not counted.

The vote consisted of two parts, the main vote on article size and a vote on
further restrictions.

The results for the main vote were, ranked lowest (better) first:

1) zero bytes:
   39 votes, averaging 3.1795
2) 100 bytes:
   37 votes, averaging 3.4595
3) 20 bytes:
   38 votes, averaging 3.8158
4) 250 bytes:
   37 votes, averaging 4.027
5) 5 bytes:
   36 votes, averaging 4.4167
6) language-dependent:
   33 votes, averaging 4.5758
7) 500 bytes:
   37 votes, averaging 4.7027
8) dynamic (e.g. depending on stub size):
   35 votes, averaging 5.1142

The votes for further restrictions, of which only one is to be picked, were:

1) at least one link:
   36 votes, averaging 3.1667
2) independent system for each wikipedia:
   31 votes, averaging 4.4516
3) stub flag (stubs excluded from count):
   34 votes, averaging 4.5882
4) minimum number of contributors:
   35 votes, averaging 4.6857
5) language-dependent punctuation (comma etc):
   36 votes, averaging 4.7778
6) two paragraphs minimum:
   33 votes, averaging 5
7) <article> tag
   33 votes, averaging 5.1515
8) no further restriction
   32 votes, averaging 5.1875
   minimum number of edits
   32 votes, averaging 5.1875
9) divide database size by byte size:
   30 votes, averaging 5.4333
10) existing comma requirement
   38 votes, averaging 5.5789

I have done my best to avoid errors, and for the first stage have compared
with Tomos' count, but I cannot be certain. While an error is unlikely to
affect the result, pedants may want to doublecheck just in case. Please note
that votes added after yesterday's deadline should not be counted. I also
did not count the anonymous vote (6 against dynamic).

Analysis of results
===================

The opinion regarding the main size restriction can be divided into two camps:
One group thought simply counting non-blank articles would be enough, the
other felt that excluding very short articles would also be necessary.
Consensus between these two groups was unlikely. The non-blank camp won by a
relatively narrow margin, but those who wanted more restrictions got an
important victory in the second stage of the vote: Only articles including
at least one link are counted, which excludes most newbie experiments.

This, in my opinion, is an almost perfect result that everyone should be
able to live with. It demonstrates well that voting systems can arrive at
compromises not just as well, but even better than simple discussions. How
long would we have needed to talk to agree on this solution and to determine
agreement? My guess is that we would not have arrived at it, ever.

But it is a good solution. There can simply be no valid article in the
Wikipedia system without links -- the whole wiki concept depends on high
interconnectedness. Material copied from somewhere else is not "wikified",
however -- nor are newbie experiments. Such "articles" are now
excluded from the count, as they should be. At the same time, we do not
choose an arbitrary byte size limit that would always remain arguable.
And I do not foresee users adding <!--[[]]--> HTML comments to an
article just to have it counted, as has happened with the comma.

Yet, even with this solution, there are people who feel strongly
that it is a bad one: 8 people have voted that counting only
articles with at least one link is a "very bad" idea (11 people thought
it is a very good idea). Once again, it is unlikely that there would
have been consensus between these groups, further disproving the
consensus model. With groups of 30 and more people, there is simply
never going to be "near unanimous consensus" about anything but the
most obvious questions.

But some results came as no surprise: Keeping the comma count was almost
universally rejected, and it is debatable whether we should have included
that option in the first place. Second place in the restrictions stage, with
considerable distance, was the option to let each Wikipedia decide on its
own. While this option clearly lost, its rank highlights that many
Wikipedians want "their" Wikipedia to have room for independent decisions. A
similar option should thus be included in future polls.

Finally, I would like to point out that the process has led to a remarkable
number of ideas -- some of them awful, sure, but some of them, like the link
idea, have never been mentioned on the mailing list. This, too, demonstrates
the advantages of a formalized brainstorming process.

Analysis of methodology
=======================

What have we learned from the process we used here?

1) The participation rate was very high. Concerns that an option might win
because of neglect were unjustified. HOWEVER, options which were added too
late tended to gather significantly fewer votes. Options which were
apparently written off as unlikely to win also tended to gather fewer votes.

2) Votes tended toward the extremes, i.e. 6 or 1. For most options, however,
the entire spectrum was used.

3) The system used therefore allowed us to gather a very large amount of
information about the opinions held. It would be difficult, if not
impossible, to gather as much information through a non-formalized process.

4) Deadlines and limits on options must be even more strictly enforced. The
deadline for proposing options should be longer, but options should be
discussed more carefully.

5) The combination of options and the possible requirement to split up voting
into stages need to be discussed to avoid ambiguity (e.g. "can more than one
option win?").

6) The voting system used takes some effort to handle manually, but would be
relatively easy to implement in code. Until we have such a software-based
solution, using this system would probably be overkill for small decisions.
In any case, we should try consensus finding first.

These are my thoughts for now -- please add yours.

Regards,

Erik


subject: [WikiEN-l] the term 'USER'

body:
The term User: is perfectly fine and would be a pain to update
(external+internal links, Google etc.). Besides, Editor: suggests
authority to newbies which is a bad idea. Wikipedian: is too easy to
confuse with Wikipedia:.

Regards,

Erik


subject: [WikiEN-l] index

body:
> Maybe we should make an alphabetical index to replace the seach engine. It
> would take much less computing power.  The index would be searchable to
find
> the right section (but not the right article) and look sort of like the
list
> of all articles page, but all redirect pages and stubs would show up, but
> not the talk pages.  Would that work?

No. The way databasing works.. makes basic functions like alphabetizing and
sorting so easy as to make it obsolete... the information can be sorted in
any number of ways, provided its there... The index can always be reindexed
for efficiency, but this is largely the domain of the database software...

http://computer.howstuffworks.com/question599.htm

note: Viewing the HSW site requires having a good pop-up stopper ;)


subject: [Wikitech-l] Re: Re: Re: <abbr>

body:
> (Richard Grevers <dramatic at xtra.co.nz>):
>
> Well, in the page that prompted this: [[Marine Corps Memorial Statue]] I
> was wanting to expand the abbreviations Sgt. Cpl. and Pfc. The latter
> occured in front of four names, and I don't think we'd want to see
> "Private, First class" written in full four times. I don't think we'll have
> an article on it any-time soon, either. Also, does anyone know what PhM.
> expands to as a U.S. Naval rank?

If they're used a lot, then it's probably OK to abbreviate and link
the first one of each to an article about military ranks in general
(which hopefully someone will notice is empty and fill in).

"PhM" isn't so much a rank as a job title: Pharmacist's Mate.  That's
someone who works in the sickbay of a ship.

--
Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lee/>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC


subject: [WikiEN-l] index

body:
On Tue, 18 Mar 2003, Daniel Ehrenberg wrote:
> Maybe we should make an alphabetical index to replace the seach engine. It
> would take much less computing power.  The index would be searchable to find
> the right section (but not the right article) and look sort of like the list
> of all articles page, but all redirect pages and stubs would show up, but
> not the talk pages.  Would that work?

http://www.wikipedia.org/pipermail/wikien-l/2003-February/001299.html

-- brion vibber (brion @ pobox.com)


from_name: Zoe

subject: [WikiEN-l] User:RachelCorrie

body:
Although I have had problems with the encyclopedia article, I see no problem with allowing the User space to be used for this purpose.
Zoe
 Christopher Mahan <chris_mahan at yahoo.com> wrote:Really?

What's wrong with that?

It's not like her userpage needs to be NPOV, you know.

Now, it may be in bad taste or blatantly political, or may ruffle
your feathers, but maybe she's gathering information on the subject
while it's hot.

Perhaps a better course of action would be to engage this contributor
into a dialog.

--- Jesse Alter wrote:
> The user RachelCorrie is using their user page to show photos of
> Rachel
> Corrie and links about her death. She died while playing chicken
> with an
> Israeli bulldozer, in protest of the destruction of Palestinian
> settlement. The user has made no contributions other than turning
> their
> user page into a non-NPOV memorial to Rachel Corrie. I move that
> the
> user be banned. If their IP can be matched to another user, I think
> that
> the user should be warned against doing that in the future.
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikien-l

=====
Christopher Mahan
chris_mahan at yahoo.com
818.943.1850 cell
http://www.christophermahan.com/

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
_______________________________________________
WikiEN-l mailing list
WikiEN-l at wikipedia.org
http://www.wikipedia.org/mailman/listinfo/wikien-l

---------------------------------
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030318/0fe981b1/attachment.htm


from_name: Thomas Corell

body:
Erik Moeller wrote:
> Finally, I would like to point out that the process has led to a remarkable
> number of ideas -- some of them awful, sure, but some of them, like the link
> idea, have never been mentioned on the mailing list. This, too, demonstrate
> the advantages of a formalized brainstorming process.

And some mentioned on the mailling list never get in the voting process.
   But we got a result, thats the important point.

I hope we get an automatic voting next time, which don't show who's
voting what. It will reduce possible influences. Nothing against
publishing the result with names, but not during the voting process.

Smurf
--
  --- Anthill Inside! ---


subject: [Wikipedia-l] Re: Re: Can't log in to Meta

body:
(cc'ing to wikitech-l)

On Wed, 19 Mar 2003, Richard Grevers wrote:
> But I would never expect the latter with other sites. However, the
> separation between wikis is not at all evident to the newcomer. Indeed, my
> first assumption was of a single user database across all wikipedia
> entities.

This is planned, but (surprise!) not yet implemented. It requires either
that all wikis are in one database (which would require more code to deal
with languages and sections separately) or talk to two databases, one
local and one common.

The latter approach is already being started with some experimental code
Magnus has done for the interlanguage links, so in the short term we'll
probably go that way. (Once someone has time to work on it...)

> While we are discussing log-ins, what is the expiry time for keeping logged
> in status? It seems to be rather short - only an hour or so. While I don't
> necessarily want to use cross-session cookies, it would be nice to stay
> logged in for an entire browser session. Sometimes I find that I have
> edited an article anonymously because my login has expired in the meantime.
> One option could be to default to session-long logins but to have a
> checkbox "this is a public computer" which would introduce a 30 or 60
> minute limit.

*Side usability note: it's easy to misinterpret from the layout that the
'remember my password' checkbox applies only to creation of new accounts.
This should probably be changed.*

Our whole login/cookie system is crying out for improvement. I've never
messed with it much because I'm not 100% sure how it works. ;)

We partially use PHP's session management, and we also set some other
cookies. I don't know what the default timeouts are. PHP session cookies
are IMHO problematic, because it asks to set a cookie *the first time you
touch the site*. I'm sure I'm not the only one who blocks all cookies by
default unless I'm deliberately logging in to a site; and we do not
gracefully handle the case where someone tries to log in with cookies
disabled.

(We print a blithe "success!" message, but the next page they visit is
logged back out, because the session cookie isn't passed on. PHP session
stuff has some funky link munging, but a) we prevent them from being put
in on most pages by using absolute URLs, and b) with our current url
rewriting configuration the information would be lost in most cases.  And
c) putting session information into URLs is *serious* bad mojo, with great
possibilities for session hijacking.)

Better would be to only set cookies at login time, and to pull a redirect
in the login process so we can reload and check that the cookie stuck. (Or
we could check for the cookie in javascript, but I hate relying on
javascript. Someone with both cookies and javascript disabled/not
available should also be able to be told that they can't log in.)

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] Re: [Wikipedia-l] Re: Re: Can't log in to Meta


from_name: Vicki Rosenzweig

subject: [WikiEN-l] the term 'USER'

body:
The advantage of the term "USER" is precisely that it's inclusive: it
doesn't draw a sharp line between the people who spend too much of
our time writing for the Wikipedia, those who do a few articles on things
they care about, and those who come here looking for information on
something specific.

It also emphasizes that *the purpose of Wikipedia is to be a usable
encyclopedia.* That I enjoy editing it is good, because it supports that
goal: but the purpose is for Wikipedia to be *used* as a source of
information.
--
Vicki Rosenzweig
vr at redbird.org
http://www.redbird.org


subject: [Wikitech-l] Page caching

body:
On Tue, 18 Mar 2003, Lee Daniel Crocker wrote:
> The "?" links are another matter: I can't think of a clean
> way to offer both options; i.e., links on the whole word
> with some style, or links only around the "?".

We had this working on phase 2. Something like:

[
Page title
]?

So for question-mark links the class "newlinkedge" was defined as visible
and "newlink" defined to inherit surrounding color/style instead of
looking linking; while for red links the class "newlinkedge" was defined
as invisible and "newlink" as red underlined.

The only change is in the stylesheet, which is generated or selected
depending on user options (with the behavior change that the titles of
question-mark links can be clicked; a behavior whose loss was bemoaned by
some when we switched to phase 3.)

There are of course other options that affect content, particularly the
TeX-related selections.

-- brion vibber (brion @ pobox.com)


body:
> Thomas Corell wrote:
>> I hope we get an automatic voting next time, which don't show who's
>> voting what. It will reduce possible influences. Nothing against
>> publishing the result with names, but not during the voting process.

> Oh, I think publishing the names as we go is a very good thing.  I
> think possible influences are good.  If people I respect are voting
> differently from me, it may give me pause.  If people I don't respect
> are voting the same as me, it may give me pause.

> Voting isn't supposed to be an alternative to open discussion and
> consensus building, but a methodology to formalize it.

I agree with Jimbo here, for the reasons I have already explained on
Talk:Article count reform. Here's a copy:

     Transparency works both ways -- it may encourage groupthink, but it
also lets you use strong votes to express dissent with options you dislike
that seem to be winning, esp. in a preferential system. In my experience,
hiding votes sounds like a good idea at first, but works badly in practice
because what is often snobbishly called groupthink is really valuable
information that you don't want to do without once you lose it. Should I
bother reading this option if all people I trust have rejected it? Should
I maybe give this a closer look if people I don't trust have buried it in
negative votes? I also find it funny that the argument "groupthink" should
be used against open voting, whereas we try to strive for consensus
without voting whenever possible, a process which is much more likely to
encourage groupthink ("Gee, I don't want to stop the consensus!").

    Secrecy is necessary for real world votes, but here we can afford some
openness. It's the wiki way.

Regards,

Erik


subject: [Wikitech-l] Watchlist query needs optimizing

body:
The watchlist is just damn slow. Would anyone care to take a look at it
and find a way to make it more efficient?

Currently:

SELECT DISTINCT
  cur_id,cur_namespace,cur_title,cur_comment,
  cur_user,cur_user_text,cur_timestamp,cur_minor_edit,cur_is_new
  FROM cur,watchlist
  WHERE wl_user={$uid} AND wl_title=cur_title
        AND (cur_namespace=wl_namespace OR cur_namespace=wl_namespace+1)
  ORDER BY inverse_timestamp {$dolimit}

This ends up EXPLAINED as:

+-----------+------+----------------------------------------------+-----------+---------+--------------------+------+----------------------------------------------------------+
| table     | type | possible_keys                                | key       | key_len | ref                | rows | Extra                                                    |
+-----------+------+----------------------------------------------+-----------+---------+--------------------+------+----------------------------------------------------------+
| watchlist | ref  | wl_user                                      | wl_user   |       4 | const              |    1 | where used; Using index; Using temporary; Using filesort |
| cur       | ref  | cur_namespace,cur_title,name_title_timestamp | cur_title |     255 | watchlist.wl_title |    1 | where used                                               |
+-----------+------+----------------------------------------------+-----------+---------+--------------------+------+----------------------------------------------------------+

Temporary table and filesort are not friendly.

-- brion vibber (brion @ pobox.com)


body:
On Tue, 18 Mar 2003, Jimmy Wales wrote:

> Erik Moeller wrote:
> >     Secrecy is necessary for real world votes, but here we can
> > afford some openness. It's the wiki way.
>
> One reason secrecy is important in real world political voting is the
> possibility of backlash against those who vote on the losing side.
> That's not really possible here.  The winners can't round up the
> losers into concentration camps.

It depends... What about the next vote being to ban the losers from all
Wikipedias except the Russian one?

Andre Engels


body:
Jimmy Wales wrote:
> Oh, I think publishing the names as we go is a very good thing.  I
> think possible influences are good.  If people I respect are voting
> differently from me, it may give me pause.  If people I don't respect
> are voting the same as me, it may give me pause.
The programmer inside me cries "deadlock";) You wait until some/all of
the respected and some/all of the others made their vote, to know what
you will vote? If this will be done by everyone, voting won't work.

I think time for influences is in the discussion before the voting and
not during voting. But this topic isn't realy important in case of
wikipedia desissions.

For example: one important thing (IMHO) for Wikipedia is the speed of a
database request. In the voting and in the discussion about the Article
count nobody calculated the complexity of some of the options. I think
some of the admins will refuse methods for this count which will need a
lot of performance. And I would respect such a decision.

Smurf
--
  --- Anthill Inside! ---


from_name: Toby Bartels

body:
Erik Moeller wrote:

>1) An article is counted if, trimmed of all trailing whitespace (blanks,
>newlines etc.), it is longer than zero bytes (non-empty) AND
>2) it contains at least one link.

This is almost exactly the result that I wanted.
The only thing that I'd prefer is to let each wiki decide for itself,
but that takes a lot more coding.

>I have done my best to avoid errors, and for the first stage have compared
>with Tomos' count, but I cannot be certain. While an error is unlikely to
>affect the result, pedants may want to doublecheck just in case. Please note
>that votes added after yesterday's deadline should not be counted. I also
>did not count the anonymous vote (6 against dynamic).

And since Jimbo endorsed the result, you didn't count my vote, right?
(See my comment on the talk page.)

>Finally, I would like to point out that the process has led to a remarkable
>number of ideas -- some of them awful, sure, but some of them, like the link
>idea, have never been mentioned on the mailing list. This, too, demonstrates
>the advantages of a formalized brainstorming process.

A formalized brainstorming process?  Certainly a good idea.
Since the first of your voting pages that I saw,
I've thought that they were a good way to get people
to come out and talk.  It's insisting that the results be valid
that is problematic.

>3) The system used therefore allowed us to gather a very large amount of
>information about the opinions held. It would be difficult, if not
>impossible, to gather as much information through a non-formalized process.

Same comment as above.

>5) The combination of options and the possible requirement to split up voting
>into stages need to be discussed to avoid ambiguity (e.g. "can more than one
>option win?").

In this case, a maximum of 1 restriction other than size was allowed.
Indeed, several things like this were decided by the voting administrator,
not the voters.

>These are my thoughts for now -- please add yours.

Oh, and I like approval voting better than this method. ^_^

-- Toby


body:
Karl Eichwalder wrote in part:

>Toby Bartels wrote:

>>(When we go to XHTML, where the initial <p> will be required,
>>then presumably we'll have to rely on the CSS for everything.)

>This would be a good thing -- without CSS all things are non-fancy and
>thus usable ofr simple browsers and audio devices and for fancy things
>the reader can choose from some CSS stylesheets.

>If you don't agree with me, that's also okay :)

I think that every developer agrees that XHTML would be best.
But none of them (I'm not one) has started to do the work.
It's a matter of budgeting time and priorities;
even the fact that I'm not one of the developers is such a matter
(since I do have some interest in how the code works).

-- Toby


body:
Erik Moeller wrote in part:

>Switching line lengths require more effort on the part of the human brain
>and lead to semantic interpretations of the breaks (as emphasis, pause
>etc.).

>Compare:

> Messages from Communities Around the Globe Palestinians and international
> friends from the United States, the UK, and the Netherlands marched along
> Sea Street, Sharia al Baha, one of the central streets in Rafah Camp. As
> they approached the center of town they began to shout through bullhorns
> in Arabic "Hurriyah la Falesteen! Hurriyah la al Iraq! Hurriyah la Rafah!
> Hurriyah la Baghdad!" and in English "Freedom for Palestine! Freedom for
> Iraq! Freedom for Rafah! Freedom for Baghdad!"

>vs.

> Messages from Communities Around the Globe Palestinians
> and international
> friends from the United States, the UK, and the Netherlands
> marched along
> Sea Street, Sharia al Baha, one of the central streets
> in Rafah Camp.
> As they approached the center of town they began to
> shout through
> bullhorns in Arabic "Hurriyah la Falesteen! Hurriyah la
> al Iraq!
> Hurriyah la Rafah! Hurriyah la Baghdad!" and in English
> "Freedom for
> Palestine! Freedom for Iraq! Freedom for Rafah! Freedom for
> Baghdad!"

And I would write:

 Messages from Communities Around the Globe
 Palestinians and international friends
 from the United States, the UK, and the Netherlands
 marched along Sea Street, Sharia al Baha,
 one of the central streets in Rafah Camp.
 As they approached the center of town
 they began to shout through bullhorns
 in Arabic "Hurriyah la Falesteen! Hurriyah la al Iraq!
 Hurriyah la Rafah! Hurriyah la Baghdad!"
 and in English "Freedom for Palestine! Freedom for Iraq!
 Freedom for Rafah! Freedom for Baghdad!"

because I encourage semantic interpretations of the breaks.

^_^

-- Toby


subject: [Wikitech-l] Page caching

body:
On Tue, 18 Mar 2003, Lee Daniel Crocker wrote:
> > (Brion Vibber <vibber at aludra.usc.edu>):
> > [
> > Page title
> > ]?
>
> Ick.  I wouldn't want to add that much overhead on each link; it seems
> OK to do it for numbered headings, but not for links.  I'm really quite
> tempted to just eliminate the "?" links, and I'm really curious if they
> are liked enough to justify them.

The Dutch folks explicitly requested that question links be retained as
the default there. There may be some resistance.

> > There are of course other options that affect content, particularly the
> > TeX-related selections.
>
> Yeah, that's a tough one too, but it's only on a small number of
> pages, so even if it makes those pages uncacheable, we'll probably
> still benefit from the cache.  And I'm not sure we can't work around
> or eliminate some of those options as well.

Pages with TeX are a small minority, and it would not be a significant
problem to simply mark any page with TeX as uncacheable. It might be nicer
to allow them to be cached, but only for users using the default
TeX options... Inclusive special cases can be worried about later, though;
it's just the exclusive cases we should start with -- things to not cache
because they're trouble.

Another odd option is "show hoverbox over wiki links". IIRC, unchecking
this will remove the 'title' attributes from the s. I don't know
if that's something that can be done by CSS... I also don't know if anyone
uses or wants the option.

There's also the stub detector. Difficult to CSSize that, as the threshold
is user-selected. Simplest to disable caching for the rare users who use
it.

-- brion vibber (brion @ pobox.com)


from_name: Daniel Ehrenberg

subject: [WikiEN-l] Google search; donations/grants (was: WikiEN-l digest, Vol 1 #212

body:
Well, we should still have something in place.  We dont NEED to ask
foundations to give us money, but if we do, the money will be going to good
use.  If you don't want to ask an education-related-fund, I think this would
much more relevant to something like the FSF. Do they give grants?

>I don't think asking for donations is the way to go once a non-profit
>is in place. The US is full of foundations that are happy to throw
>money at half-baked proposals vaguely related to education. Pretty much
>every billionaire sets up a foundation like that. You just write a
>grant proposal and wait for the money to come in. Lots of people in
>academia make their living that way. And we are talking at least an
>order of magnitude higher than your figure above.
>
>Axel

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
http://join.msn.com/?page=features/virus


subject: [WikiEN-l] index

body:
Maybe we should make an alphabetical index to replace the seach engine. It
would take much less computing power.  The index would be searchable to find
the right section (but not the right article) and look sort of like the list
of all articles page, but all redirect pages and stubs would show up, but
not the talk pages.  Would that work?

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
http://join.msn.com/?page=features/virus


subject: [Wikitech-l] Re: <abbr>

body:
Richard Grevers wrote:

>Yet ironically, deprecated presentational stuff like <b> is supported.

<b> is not deprecated in HTML 4, nor in XHTML 1.0.
(I haven't checked XHTML 1.1, but that's not very relevant.)
<b> is quite different from <strong>, as I'm sure you know.

-- Toby


subject: [WikiEN-l] the term 'USER'

body:
Jimmy Wales wrote in part:

>I think the term "user" helps to emphasize something radical about
>the wiki concept -- ordinary *users* can edit the site.

I agree with this.

In practice, there are (at least) two classes of Wikipedia users:
the ordinary users that come to look stuff up after a Google match,
and the regular editors that come here to work on articles.
But this distinction doesn't exist in theory,
and it's good to encourage the idea that users
(hey, that's me, I'm a user 'cause I just looked something up here!)
are the people that edit the site (so that's me too!).

-- Toby


body:
> On 3/18/03 11:00 AM, "Erik Moeller" <erik_moeller at gmx.de> wrote:
>>   Secrecy is necessary for real world votes, but here we can afford some
>> openness. It's the wiki way.
>>
> Yeah, but voting *isn't* the wiki way.

Obviously we have different definitions.

Regards,

Erik


from_name: Juho Heikkurinen

body:
Hi.

I'm working on getting wikipedia wiki fully installed for
http://www.consumerium.org/wiki/
and I just got the uploading setting to work so that uploading works,
but...

As I checked where it put the test file I noticed the the png I had
uploaded had permissions set to -rwxr-xr-x
which is not a good thing.

Imagine:
1. Upload whack_the_database.php
2. Point your browser to uploadpath/whack_the_database.php assuming it
has access to LocalSettigs.php

I heard from taw at #wikipedia that the upload code should make the
files _not executable_ which is not what it did.

He tracked it down to the bug being in move_uploaded_file(
$wpUploadTempName, $wgSavedFile ) or near it.

Could someone take a look at this?

My CVS-dump is dated 22.2.2003

regards, Juho Heikkurinen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 881 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20030318/391d6f32/attachment.bin>