from_name: Ray Saintonge

subject: [Wikipedia-l] Changes and suggestions (was Re: slight change to the announce-l list)

body:
Brion Vibber wrote:

>>So, since others protest and undelete the
>>redirections, some asked if it would be possible to
>>somehow catch mispellings, redirect the mispelled
>>title to the right-spelled page, *and* dynamically
>>display a message at the top of the article saying
>>"you asked for "fachisme", this word does not exist,
>>and is probably a mispelling of "fascisme".
>>
>
>It has in the past been suggested to have a special type of redirect for
>misspellings. These could have a "you're an illiterate idiot, from now
>on please type 'X'" message display when visited or searched, but be
>hidden from lists like the Allpages list or general search results.
>
I've never favoured automatic redirects for misspellings.  A lot of them
are really typos that can come from just hitting the key on the keyboard
that's beside the one that you want.  With common misspellings the sort
of thing that Brion (oops I just had to go back and correct this from
Brian) suggests has a lot of merit.  A simple redirect presumes what a
person wants, and the worst offenders will probably not even realize
that they have been redirected.

Ec


list: wikitech-l

source: pipermail-mbox

subject: [Wikitech-l] Bot approval request

body:
Erik Moeller wrote:

>Tim-
>
>>:In keeping with Wikipedia policy, the source code is secret,
>>:however, it will be made available via email to well-behaved
>>:users if required
>>
>
>Can you elaborate a bit on the destructive potential of the bot? I'm not
>fully sure if
>
>1) You do not want people to use the bot for things which you don't want
>to happen, but which nobody else cares to stop; or
>2) You do consider it, if modified, unstoppable.
>
>Please note that we can block whole IP ranges if necessary or switch the
>wiki to read-only, so I'm not sure what a dedicated bot attack could
>accomplish? If you are basically telling Fred "I don't like you, you have
>opinions I disagree with, you won't get to use my code", that is certainly
>your decision to make.
>
>But if that is your logic, I do not think your bot should be approved for
>running on Wikipedia at all.
>
I've had some serious concerns about this bot.  On the surface it has to
do with changing [[Brisbane, Queensland]] to simply [[Brisbane]] with
the possibility that it could also be used for other city names.  This
is a questionable use of a bot to impose a naming convention that may
not have unanimous support.  If it is used in the course of an edit war,
it makes for an unequal fight between those who use a bot and those who
don't.

I'm not too sure of the solution.  Perhaps such a bot should be
generally available to everybody so that someone who disagreed with the
naming convention change could just as easily revert it.  Perhaps we
need to have bot generated changes appear on "Recent changes" again so
that everybody can see what is happening.  Or perhaps we need to review
the bot approval process so that some vote would be needed for each
separate use of a bot.

Eclecticology


list: wikien-l

from_name: Erik Moeller

subject: [WikiEN-l] It is time to ban Michael

body:
> I have seen no improvement since Jimbo's warning and I think it is now to
> kick Michael off the island (in fact, his response to Jimbo's message was to
> blank his talk page). He does edit each day with a different IP but we have
> learned with 142.177 that simply reverting everything he posts soon after
> posting it (SoftSecurity) should do the job (an IP block would be nearly
> useless here since he edits in the 64.175.xxx.xxx range)

I could fix up the IP blocking code to include an expiry date fairly
quickly, would that help? You would have to block a few times but it would
probably scare him off.

Regards,

Erik


subject: [WikiEN-l] Iraq and chemical weapons

body:
> This would be a great place for wikimedia news reporting. There shouldn't be
> encyclopedia articles on current events. If there is a contraversy about
> what the facts are, then any product that comes out will have to be
> unencyclopedic.

The principles of NPOV are as applicable to current as to past events. The
real difference here is that articles about current events tend to get
neglected once the events in question have passed. This means much
attention has to be paid to proper refactoring, like on the Village Pump
page when it gets too full.

I do not support the idea of a separate Wikipedia for current events at
the present time.

Regards,

Erik


list: wikipedia-l

subject: [Wikipedia-l] Re: [Announce-l] slight change to the announce-l list

body:
>> [...] Of course, none of this matters unless poeple start using it.

> I?ll do so now.
> Could you annonce that the German Wikipedia has hit 13.000 articles tonight?

Is that a magic number or something? No offense, but please do not spam
the lists with useless announcements.

Thanks,

Erik


subject: [Wikitech-l] Bot approval request

body:
Tim-
> :In keeping with Wikipedia policy, the source code is secret,
> :however, it will be made available via email to well-behaved
> :users if required

Can you elaborate a bit on the destructive potential of the bot? I'm not
fully sure if

1) You do not want people to use the bot for things which you don't want
to happen, but which nobody else cares to stop; or
2) You do consider it, if modified, unstoppable.

Please note that we can block whole IP ranges if necessary or switch the
wiki to read-only, so I'm not sure what a dedicated bot attack could
accomplish? If you are basically telling Fred "I don't like you, you have
opinions I disagree with, you won't get to use my code", that is certainly
your decision to make.

But if that is your logic, I do not think your bot should be approved for
running on Wikipedia at all.

Thanks for your understanding,
Erik


from_name: koyaanis qatsi

subject: [Wikipedia-l] the 'pedia's down

body:
wikipedia has been down for a few hours.  I'm not
subscribed to wikipedia-L, so could someone pass this
on if the moderator doesn't see it and if the
powers-that-be don't know about the problem?

thanks,

kq

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


from_name: Brion Vibber

subject: [Wikipedia-l] links are not completely empty

body:
On Sun, 2003-03-30 at 04:27, Chuck Smith wrote:
> > The official vote results were to count pages in
> > article space that are:
> > * not completely empty (size greater than 0 bytes)
> > * contain at least one link (search for "[[" should
> > do)
>
> Is it me or isn't it true that all pages that contain
> at least one link would not be completely empty?
> Thus, saying both of the above statements is a bit
> redundant.  :)

This is to distinguish from other proposals that require a page to reach
X arbitrary number of bytes before getting any respect. (Sizeism,
probably illegal under the Universal Declaration of Webpage Rights. ;)

-- 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/20030330/cecfc2d4/attachment.pgp


from_name: Bryan Derksen

subject:
[Wikipedia-l] Changes and suggestions (was Re: slight change to
 the announce-l list)

body:
At 12:51 AM 3/30/03 -0800, Brion Vibber wrote:
>On Sat, 2003-03-29 at 23:52, Anthere wrote:
> > 3. Could it be possible that the "random page" be (per
> > option) chosen with a size threashold ? This would be
> > to avoid all these pages about dates and french little
> > villages that keep on appearing on random pages :-).
>
>Hehe... Traditionally people asked for that to keep out the city pages
>on the English wiki, which wouldn't help at all since those pages are at
>or _above_ the median article size...

While on the subject of the "random page" link, why is it that the page it
takes me to is apparently not very random? Sometimes when I've got nothing
specific to do I'll just start clicking random page repeatedly searching
for an interesting article to tinker with, and I find that I start visiting
the same small set of pages over and over again. Also, it seems that an
unusually large number of these random pages are ones which have been just
recently edited, though I haven't done a rigorous count of this. Is there
some sort of non-random algorithm being used?


subject: [Wikitech-l] What, no salt?

body:
On Sun, 2003-03-30 at 07:04, Tim Starling wrote:
> Gee, the interesting things you find when browsing the wikipedia codebase.
> Don't you people know what salt is?

Nothing like reinventing a wheel to reinvent old bugs, is there? :)

> Don't worry, I fixed it. What do I do with the rectified code (once I've
> read over it a couple more times)?

By all means, send it over.

Obviously we'd have to add a note explaining that everyone has to reset
their password. Not everyone has an e-mail address attached to their
account, so we'd need to add a web form for doing this. That obviously
would require first validating the person with their current password
with the current hashing code; so we'd probably need a marker to
indicate that each users' password field is upgraded.

Of course, all our passwords are sent in cleartext over the internet
anyway, so should never be assumed to be secure.

-- 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/20030330/354fcee3/attachment.pgp>


body:
Chuck Smith wrote:

>>The official vote results were to count pages in
>>article space that are:
>>* not completely empty (size greater than 0 bytes)
>>* contain at least one link (search for "[[" should
>>do)
>>
>
>Is it me or isn't it true that all pages that contain
>at least one link would not be completely empty?
>Thus, saying both of the above statements is a bit
>redundant.  :)
>
The problem with that POV is that it's too logical. :-)

Ec


body:
tarquin wrote:

> Brion Vibber wrote:
>
>>
>> It has in the past been suggested to have a special type of redirect for
>> misspellings. These could have a "you're an illiterate idiot, from now
>> on please type 'X'" message display when visited or searched, but be
>> hidden from lists like the Allpages list or general search results.
>>
>> Would that be a help?
>>
> yup :-)
> #MISSPELLING [[Napoleon]]
> for "Napolean", say
>
> I also suggested non-English wikipedias might find it easier to have a
> synonym of the keyword #REDIRECT in their own language -- so on fr:,
> #REDIRECT or ... #{whatever} would work

What about those situations where "napolean" is correct?  I would find
it quite acceptable as an adjective in some circumstances.  The glossary
on the website for the Farrier & Hoofcare Resource Center refers to a
"napolean shoe" as a "backwards shoe".

Eclecticology


from_name: Tim Starling

subject: [Wikitech-l] Bot approval request

body:
>
>"I'm open to suggestions as to the setting of $delay. If anyone wants to
>see
>the rest of the code, I'll send it by private email.
>
>-- Tim Starling."
>
>What's up with this guy?
>
>Fred

Sorry if I gave the wrong impression, but the reason I'm sending it by
private email is so that I control who gets it. As I said on User:Timbot:

:In keeping with Wikipedia policy, the source code is secret,
:however, it will be made available via email to well-behaved
:users if required

Fred, you've been here only since November, your first post to wikitech-l
was in February. With those 224 edits, you've only managed to piss me off
with a non-productive and persistent edit war over chiropractic medicine. In
that short time, you've managed to form an impression in my mind of
unilateralism and an aversion to real debate. You're not in a position to
contribute to the approval process, so why do you want the bot code? That
bot could be used very destructively if it fell into the hands of someone
interested in enforcing partisan article names. With a minor modification,
it could be made into an automated revert-bot.

Perhaps if The Cunctator or Lee have formed a better impression of you, you
can convince one of them to give you the code.

-- Tim Starling.

_________________________________________________________________
MSN Instant Messenger now available on Australian mobile phones.?Go to
http://ninemsn.com.au/mobilecentral/hotmail_messenger.asp


subject: [Wikipedia-l] the 'pedia's down

body:
On Sun, 2003-03-30 at 07:56, koyaanis qatsi wrote:
> wikipedia has been down for a few hours.  I'm not
> subscribed to wikipedia-L, so could someone pass this
> on if the moderator doesn't see it and if the
> powers-that-be don't know about the problem?

Back up since a couple of hours ago.

As a reminder, don't bother sending mail to the mailing list if the
server is down! It won't go anywhere. :)

Instead, send to wikidown at bomis.com, which will forward to several of
the server admins.

-- 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/20030330/97e74ef8/attachment.pgp


subject:
[Wikipedia-l] Changes and suggestions (was Re: slight change
	to the announce-l list)

body:
On Sun, 2003-03-30 at 11:54, Ray Saintonge wrote:
> tarquin wrote:
> > #MISSPELLING [[Napoleon]]
> > for "Napolean", say

> What about those situations where "napolean" is correct?  I would find
> it quite acceptable as an adjective in some circumstances.  The glossary
> on the website for the Farrier & Hoofcare Resource Center refers to a
> "napolean shoe" as a "backwards shoe".

Well that wouldn't be used as a redirect to [[Napoleon]], would it?

-- 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/20030330/d406817c/attachment.pgp


from_name: Anthere

body:
--- tarquin <tarquin at planetunreal.com> wrote:
>
>
> Brion Vibber wrote:
>
> >
> >
> >
> >It has in the past been suggested to have a special
> type of redirect for
> >misspellings. These could have a "you're an
> illiterate idiot, from now
> >on please type 'X'" message display when visited or
> searched, but be
> >hidden from lists like the Allpages list or general
> search results.
> >
> >Would that be a help?
> >
> yup :-)
> #MISSPELLING [[Napoleon]]
> for "Napolean", say
>
> I also suggested non-English wikipedias might find
> it easier to have a
> synonym of the keyword #REDIRECT in their own
> language -- so on fr:,
> #REDIRECT or ... #{whatever} would work

Good idea Tarquin

Also, just a personnal suggestion...could [[user:xxx]]
work on any pedia (as well as the local word) ?

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


subject: [Wikitech-l] What, no salt?

body:
--- Brion Vibber <brion at pobox.com> wrote:
> On Sun, 2003-03-30 at 07:04, Tim Starling wrote:
> > Gee, the interesting things you find when browsing
> the wikipedia codebase.
> > Don't you people know what salt is?
>
> Nothing like reinventing a wheel to reinvent old
> bugs, is there? :)
>
> > Don't worry, I fixed it. What do I do with the
> rectified code (once I've
> > read over it a couple more times)?
>
> By all means, send it over.
>
> Obviously we'd have to add a note explaining that
> everyone has to reset
> their password. Not everyone has an e-mail address
> attached to their
> account, so we'd need to add a web form for doing
> this. That obviously
> would require first validating the person with their
> current password
> with the current hashing code; so we'd probably need
> a marker to
> indicate that each users' password field is
> upgraded.
>
> Of course, all our passwords are sent in cleartext
> over the internet
> anyway, so should never be assumed to be secure.
>
> -- brion vibber (brion @ pobox.com)

Si.
And remember, on the first of january 2003, someone
took over three sysops accounts on the french wiki,
and indicated our passwords in clear to the three of
us.
So...well...security...hum

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


body:
--- Brion Vibber <brion at pobox.com> wrote:
> On Sat, 2003-03-29 at 23:52, Anthere wrote:
> > 1. Was the count system for pages changed ? If it
> was,
> > when was it ? When it is changed, could it be
> > announced on the "announced list" please ? It will
> > also need to be made obvious on the stats pages
>
> The official vote results were to count pages in
> article space that are:
> * not completely empty (size greater than 0 bytes)
> * contain at least one link (search for "[[" should
> do)
>
> Unless someone else snuck it in and forgot to tell
> me, the change has
> not yet been put in effect, as I'm a lazy, grumpy
> bastard and way way
> too busy of late. :)

You are nothing like a lazy grumpy bastard Brion !
Just don't forget to tell us just before (so the
interested ones will be able to see the difference
:-))

> > 2. When are we going to have the counts of hits
> per
> > page up again on the english wiki ? with the new
> > server ?
>
> Maybe. I'm not terribly interested in the counts, so
> it's a very low
> priority for me. If performance picks way up (or
> someone else
> contributes a more server-friendly count method),
> it'll go back in.

I'm interested. So, i'll come back back when
performance issues are solved

> >  when is that new server expected ? could we
> > have any time line here ?
>
> I know nothing... Jason? Jimbo? While I'm asking,
> Jimbo, how's that
> foundation coming along? :)
>
> > 3. Could it be possible that the "random page" be
> (per
> > option) chosen with a size threashold ? This would
> be
> > to avoid all these pages about dates and french
> little
> > villages that keep on appearing on random pages
> :-).
>
> Hehe... Traditionally people asked for that to keep
> out the city pages
> on the English wiki, which wouldn't help at all
> since those pages are at
> or _above_ the median article size...

Sigh. Yes. Well...most of these are under the median
article I guess. If above, they provide information at
least.
The best option would be to set categories, and to
shuffle through the categories we like of course
When I was a kid, I always picked up the same couple
of books from my parents 20 tomes encyclopedia...

But...well...would it be feasible...?

> > Editors would put the option without threashold
> for
> > article-to-improve, and readers would have a
> > threashold to remove stubs when just chasing
> > interesting articles to *read*
> > (this request reported from some french people)
>
> Hmm, maybe. Personally I may find short articles
> more fun to read than
> 20-page dense monstrosities on n-dimensional
> topology. My personal
> opinion is simply that if you don't like what the
> random selection turns
> up, you should keep pushing the button! It isn't
> clear to me that
> fudging the selection in one direction or another is
> a better default.

hum...quite true. Unless pushing the button takes 30
seconds each time :-(
But, here, you hold the position of an editor; not of
a reader.

> > 4. Could we slightly improve the search box, maybe
> by
> > having a drop down menu aside from it : search in
> > encyclopedia by default as right now, search in
> > personnal pages, search in meta pages...but have
> it at
> > first level, not on a second page, after a first
> > unfruitful search.
>
> Yes, that would be lovely.

yes, yes, yes !

Say...this could improve performance issues, no
?...so...could it be planned if nobody disagrees ?

Does someone disagree ?
Which categories would we define ?

> > So, since others protest and undelete the
> > redirections, some asked if it would be possible
> to
> > somehow catch mispellings, redirect the mispelled
> > title to the right-spelled page, *and* dynamically
> > display a message at the top of the article saying
> > "you asked for "fachisme", this word does not
> exist,
> > and is probably a mispelling of "fascisme".
>
> It has in the past been suggested to have a special
> type of redirect for
> misspellings. These could have a "you're an
> illiterate idiot, from now
> on please type 'X'" message display when visited or
> searched, but be
> hidden from lists like the Allpages list or general
> search results.
>
> Would that be a help?

That's what some people ask for...
I'll report...
Question : even if hidden, would it be known by google
?

given the number of times I mispell neartic instead of
nearctic (who had the weirdest idea to put a c here),
I could be convinced I am an illiterate idiot...:-(

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


from_name: Chuck Smith

body:
> The official vote results were to count pages in
> article space that are:
> * not completely empty (size greater than 0 bytes)
> * contain at least one link (search for "[[" should
> do)

Is it me or isn't it true that all pages that contain
at least one link would not be completely empty?
Thus, saying both of the above statements is a bit
redundant.  :)

Chuck

=====
Learn Esperanto! - http://www.lernu.net/
Enciklopedio: http://eo.wikipedia.org/

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran?ais !
Yahoo! Mail : http://fr.mail.yahoo.com


from_name: Daniel Mayer

subject: [Wikipedia-l] Syndicated article a day queue idea

body:
Below is the start of a thread on the possibility of having a syndicated
article a day queue (sorry, I didn't have much time to write a real proposal
for this but just wanted to float the idea by everyone):

Yo. could you bring up on wikipedia-L the idea of re-establishing something
like "article a day queue," but with an rss feed that allows syndication,
sending the first paragraph of 1 - 5 articles a day? maybe setting up
voting/submission system to work out which articles to send, and making it
multilingual? just some ideas. thanks, Koyaanis Qatsi

Seconded, that's a great idea. --Brion

be much easier for wiktionaries word of teh dya too. -fonzy

We already have an article a day - A new day page is automatically displayed
each day which in turn has many articles linked from it. I also add at least
three new historical anniversaries onto the Main Page daily (and then there
are the updates to the other parts of ==Selected Articles==). But the
syndication idea would be most useful at promoting Wikipedia. Perhaps we
could syndicate the whole ==Selected Articles== section? --mav

-- Daniel Mayer (aka mav)

WikiKarma
The usual at [[March 24]]


subject: [Wikitech-l] What, no salt?

body:
On Sun, 2003-03-30 at 15:24, Tim Starling wrote:
> No-one will have to reset their password. I'll just use md5(md5(password) +
> salt) for the new hash. The only thing users will notice is that their
> stored cookies will stop working and they'll have to log in again.

If that's a good enough hash, then yes that would work fine as an
automated upgrade path. Hurrah!

When you've got the code ready, send it over and I'll put it up on
test.wikipedia.org for a whirl.

On Sun, 2003-03-30 at 15:30, Tim Starling wrote:
> If we really want to be serious about security we'll have to use ssl for
> login, but I don't know how to do that.

I looked into this briefly a while ago; apparently there are
difficulties with using https on apache with name-based virtual servers,
as it cannot determine which virtual host configuration to go to until
it's already established the https connection, but to configure the
https connection it needs to know which virtual host configuration it's
using.

If anyone's got some experience with this or can think of a clean
workaround, please speak up. (Listening on a separate port for each wiki
is probably possible, but less than elegant.)

-- 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/20030330/ab7617d0/attachment.pgp>


from_name: tarquin

subject: [Wikitech-l] Bot approval request

body:
The Cunctator wrote:

>We'd be much better off if we add the needed functionality on the
>serverside, I believe.
>
>
probably.

>If you could describe exactly what the problem is that you wrote the
>code to solve, that would be very helpful.
>
>I really think we should err on the side of not worrying so much about
>"fixing" links, if the redirects go to the right place.
>
I'd like some sort of system (bot, server-side, don't mind) to rename
images. for example:

1) cryptic DOS-like names, like "UKmp-nwcstle" to "Map of UK showing
Newcastle"
2) ambiguous names, like "Washington" to "washington memorial"


subject:
[Wikipedia-l] Changes and suggestions (was Re: slight change
 to the announce-l list)

body:
Brion Vibber wrote:

>
>
>
>It has in the past been suggested to have a special type of redirect for
>misspellings. These could have a "you're an illiterate idiot, from now
>on please type 'X'" message display when visited or searched, but be
>hidden from lists like the Allpages list or general search results.
>
>Would that be a help?
>
yup :-)
#MISSPELLING [[Napoleon]]
for "Napolean", say

I also suggested non-English wikipedias might find it easier to have a
synonym of the keyword #REDIRECT in their own language -- so on fr:,
#REDIRECT or ... #{whatever} would work


from_name: Daniel Ehrenberg

subject: [WikiEN-l] weekeepeedee-uh Libel

body:
It would probably need to say stuff like Wikimedia Foundation is not liable for any libelous content.  The NPOV statement has nothing about liability.
 Brion Vibber <brion at pobox.com> wrote:On Sat, 2003-03-29 at 20:41, Stevertigo wrote:
> The thing I'm curious about is, with regard to the setting up of a Wikimedia
> foundation... and the necessary formalizing of some sort of policy.. vis a
> vis libel issues...

What would such a policy need to say that the Neutral Point of View
policy does not?

-- brion vibber (brion @ pobox.com)
> ATTACHMENT part 2 application/pgp-signature name=signature.asc

---------------------------------
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/20030330/dd6fa33d/attachment.htm


subject: [Wikitech-l] What, no salt?

body:
On Sun, 2003-03-30 at 17:02, Nick Reinking wrote:
> You can only have one virtual host per IP/port with ssl.  Sorry, SSL
> limitation, can't be helped.  All you have to do (provided all of the
> wikis are on the same machine) is redirect everybody to
> www.wikipedia.org for the login, and then back to their original
> language for everything else.  So, it can be done, but it is annoying.

Hmm, that reminds me.

Way back when, I suggested* using paths instead of hostnames for the
languages:

  http://wikipedia.org/en/Jimmy_Carter
  http://wikipedia.org/eo/Jimmy_CARTER
  http://wikipedia.org/ko/%ec%a7%80%eb%af%b8_%ec%b9%b4%ed%84%b0

Aside from being (IMHO) more aesthetically pleasing than the current
system, this would neatly solve the https problem by only using one
hostname for all languages. (Old names would always be allowed on http
for backwards compatibility, but not on https since we can't support
that, and have no backwards compatibility URls to worry about anyway.)

* http://meta.wikipedia.org/wiki/Thoughts_on_language_integration

If this were to be done without first setting up the single sign-in
system, we'd have to limit the cookie paths to the language-specific
subdirectories. (Caveat: what to do about directly calling the script
for diffs, edit, etc etc. This stuff needs access to the session cookie,
but we want it all in a distinct place so they can be cordoned off in
robots.txt, for which appending a query string after the title is
insufficient.) It may also be possible to rename the cookies. Sigh... I
still think the cookie/login system needs to be seriously reworked to
avoid setting any cookies until actual login time to avoid scaring the
paranoid.

-- 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/20030330/ca831699/attachment.pgp>


from_name: Nick Reinking

subject: [Wikitech-l] What, no salt?

body:
On Sun, Mar 30, 2003 at 04:23:03PM -0800, Brion Vibber wrote:
> On Sun, 2003-03-30 at 15:24, Tim Starling wrote:
> > No-one will have to reset their password. I'll just use md5(md5(password) +
> > salt) for the new hash. The only thing users will notice is that their
> > stored cookies will stop working and they'll have to log in again.
>
> If that's a good enough hash, then yes that would work fine as an
> automated upgrade path. Hurrah!
>
> When you've got the code ready, send it over and I'll put it up on
> test.wikipedia.org for a whirl.
>
> On Sun, 2003-03-30 at 15:30, Tim Starling wrote:
> > If we really want to be serious about security we'll have to use ssl for
> > login, but I don't know how to do that.
>
> I looked into this briefly a while ago; apparently there are
> difficulties with using https on apache with name-based virtual servers,
> as it cannot determine which virtual host configuration to go to until
> it's already established the https connection, but to configure the
> https connection it needs to know which virtual host configuration it's
> using.
>
> If anyone's got some experience with this or can think of a clean
> workaround, please speak up. (Listening on a separate port for each wiki
> is probably possible, but less than elegant.)
>
> -- brion vibber (brion @ pobox.com)

You can only have one virtual host per IP/port with ssl.  Sorry, SSL
limitation, can't be helped.  All you have to do (provided all of the
wikis are on the same machine) is redirect everybody to
www.wikipedia.org for the login, and then back to their original
language for everything else.  So, it can be done, but it is annoying.

--
Nick Reinking -- eschewing obfuscation since 1981 -- Minneapolis, MN


from_name: daniwo59 at aol.com

body:
I'd like to see a random stub of the day so that some of the stubs get filled
in.

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


from_name: Toby Bartels

subject: [WikiEN-l] Slander against scientists

body:
Ec wrote in part:

>But dismissing chiropractors as utter charlatans does not
>lead to the conclusion that the standard medical doctor will perfect.

Certainly not.

>They too have often been sold a bill of goods by drug company sales
>representatives with fat commissions to protect..

And one also needs to considere the sceptical POV of this as well.

>Toby Bartels wrote:

>>As a mathematician, I'm contractually obligated
>>to refute misapplications of G?del's theorems.
>>Of course, you only said "In the spirit of" ....

>It would be a shame if G?del had no practical application!

Well, these theorems have application to logic and philosophy.
They're related to matters with application to computer science.

>>Of course, we're not exactly comparing the same things here,
>>scientific verification vs mathematical proof.

>You really should try to get people in the other sciences to accept
>mathematical standards of proof. :-)

I trust that the smiley is an ?I'm just kidding, I'm not serious.? smiley.
^_^

-- Toby


subject: [WikiEN-l] City names argument resurrected

body:
Tim Starling wrote:

>Are there any objections to my setting a new standard for Australian city
>and town names, favouring simple names such as [[Canberra]]?

I thought that just this was already agreed upon in unambiguous cases --
no special naming conventions except in the USA and Canada.
The disagreement still festering on the talk page (and its archives)
is over commas vs parentheses, yes?

And mav has come over the light side of the force ^_^ on that matter,
I'm happy to see, so perhaps we could take it up again at
[[Wikipedia talk:Naming conventions (city names)]]?

-- Toby


subject: [Wikitech-l] Using TeX

body:
Michel Mouly wrote:

>However, when I looked to the details, I found (to my taste) too many
>limitations with the followed approach. Then I wrote an extension to
>outputpage.php to replace the call to texvc by calls to pdflatex then
>imagemagick convert. This has reached the stage of minimal functionality
>(translation and caching). This allows me to have full maths, without
>having to remember what is supported or not, or modified, compared to
>LaTeX. In addition, we intend to use it for small music scores (using Mu-
>sixTeX or possibly PMX), and I have in mind some other uses of LaTeX.

Is your version safe against DoS attacks with long scripts?
Is it safe against running TeX commands that access files?
OTOH, does it allow inclusion of additional TeX packages (like Xypic)
with a simple modification to the code opening up the package?
If so, then some of us (me and AxelBoldt, I guess)
might well prefer your code to the current texvc --
at least when producing PNG output instead of HTML.

>Please understand that I'm not trying to (re)open a debate. I've read the
>"math markup" page on meta.wikipedia (and music markup as well), and I'm
>aware of (some of) the drawbacks of the approach I followed. I mentionned
>what I did just in conformance with GPL: if there is any interest in this
>small piece of code (which I doubt, it's rather trivial!), just say it.

I'd like to see the diff to see just what you took away from texvc.

-- Toby


subject: [WikiEN-l] weekeepeedee-uh Libel

body:
Stevertigo wrote:

>Sean wrote:

>>Dan wrote:

>>>According to the constitution of the united states,
>>>libel should be solved out of the courts simply by
>>>notifying everyone of the incorrect information.

>>Oh, really?  Which article would that be?

>The idea I think Dan is getting at is 'good faith' - If a good faith effort
>isnt made to deal with the issue.. vis a vis.. a retraction, etc... then a
>judge is likely to view the issue as beneath the court.

IANAL, but this sounds correct to me.
However, such court practices would derive from case law;
I'm sure that the US Constitution says nothing directly about it.
(That said, the 1st Amendment may be seen as lending support for it,
and a court might cite the spirit of that amendment in a decision.)

So the idea is probably right,
it's just not clear-cut in the consitution's text.

-- Toby


subject: [Wikitech-l] What, no salt?

body:
On Sun, Mar 30, 2003 at 06:35:50PM -0800, Brion Vibber wrote:
> On Sun, 2003-03-30 at 17:02, Nick Reinking wrote:
> > You can only have one virtual host per IP/port with ssl.  Sorry, SSL
> > limitation, can't be helped.  All you have to do (provided all of the
> > wikis are on the same machine) is redirect everybody to
> > www.wikipedia.org for the login, and then back to their original
> > language for everything else.  So, it can be done, but it is annoying.
>
> Hmm, that reminds me.
>
> Way back when, I suggested* using paths instead of hostnames for the
> languages:
>
>   http://wikipedia.org/en/Jimmy_Carter
>   http://wikipedia.org/eo/Jimmy_CARTER
>   http://wikipedia.org/ko/%ec%a7%80%eb%af%b8_%ec%b9%b4%ed%84%b0
>
> Aside from being (IMHO) more aesthetically pleasing than the current
> system, this would neatly solve the https problem by only using one
> hostname for all languages. (Old names would always be allowed on http
> for backwards compatibility, but not on https since we can't support
> that, and have no backwards compatibility URls to worry about anyway.)

Not to mention squishing the wait for register.com's shitty DNS servers.
Getting old links to work would still be quite easy with an Apache
redirect rule.

> * http://meta.wikipedia.org/wiki/Thoughts_on_language_integration
>
> If this were to be done without first setting up the single sign-in
> system, we'd have to limit the cookie paths to the language-specific
> subdirectories. (Caveat: what to do about directly calling the script
> for diffs, edit, etc etc. This stuff needs access to the session cookie,
> but we want it all in a distinct place so they can be cordoned off in
> robots.txt, for which appending a query string after the title is
> insufficient.) It may also be possible to rename the cookies. Sigh... I
> still think the cookie/login system needs to be seriously reworked to
> avoid setting any cookies until actual login time to avoid scaring the
> paranoid.

Technically, they aren't really paranoid, since we are out to get them.
They just have an over-abundence of common sense.  :P  I can't say much
about the other parts; cookie setups vary widely.  Any docs on how that
all works?

--
Nick Reinking -- eschewing obfuscation since 1981 -- Minneapolis, MN


subject: [Wikitech-l] Bot approval request

body:
Brion said:

> > >We'd be much better off if we add the needed functionality on the
> > >serverside, I believe.
> >
> > Perhaps, but I believe in the motto "if you want something done, do it
> > yourself." Who's going to write this server-side code -- you're
>obviously
> > not interested.
>
>Meanwhile, you obviously _are_ interested in making this ability
>available. If you'd like to try your hand, I'd be delighted.

Alright, but in an attempt to prevent Wikipedia from completely taking over
my life, I'm going to stop making edits. I'm not sure if I can go cold
turkey, so if anyone sees me doing anything, please block me.

Now on to Eric Moeller's post:

>If you are basically telling Fred "I don't like you, you have
>opinions I disagree with, you won't get to use my code", that is certainly
>your decision to make.

Yeah, that's pretty much it. And from Eclecticology:

>I've had some serious concerns about this bot.  On the surface it has to do
>with changing [[Brisbane, Queensland]] to simply [[Brisbane]] with the
>possibility that it could also be used for other city names.  This is a
>questionable use of a bot to impose a naming convention that may not have
>unanimous support.  If it is used in the course of an edit war, it makes
>for an unequal fight between those who use a bot and those who don't.

That's a very good point. Okay, forget the bot. Like I said above, I'll
write it on the server side. I'll start a new thread on how it should be
implemented.

>what does that mean "you are not in a position to
>contribute to the approval process" ???

I was suggesting that it's not Fred who makes the decisions, it's people
like Brion and Lee. It doesn't make much sense to me either, now that I've
calmed down. Please forget I said it.

-- Tim Starling.

_________________________________________________________________
MSN Instant Messenger now available on Australian mobile phones.?Go to
http://ninemsn.com.au/mobilecentral/hotmail_messenger.asp


subject: [Wikitech-l] Server-side backlink redirects

body:
What we want to be able to do is:

1) Change a set of links pointing to a redirect, so that they're pointing to
the real article
2) Change a set of links pointing to an incorrectly named image, to a new,
correctly named image.

The second one was suggested by Tarquin on [[User talk:Timbot]]. Now the
problem with this feature is that it has the potential to create excessive
server load, especially if an edit war breaks out utilising it. My scheme
below is intended to do the following things:

* Make it appear weighty and time-consuming, so that users won't do it
frivolously.
* Make the smallest impact on the server possible while not wasting people's
time.
* Make edit wars utilising the feature take up a minimum of server load, and
to favour a conservative (changeless) outcome.

As a tentative short name, I suggest the "backlink redirect". It's a
mouthful, it doesn't make much sense, but it's better than anything else
I've come up with.

Here's my current vision for how it will operate:

On Special:Movepage, you now get an OPTION group looking like this:

(*) Move page only
( ) Make the page a redirect, and update all links so that they point to the
new article
( ) Move page and update links

Any logged in user has access to these options. If the user selects the
second or third option, a new thread is created on the server, set to low
priority -- low enough that it might take an hour or more during peak times
to fix a large set of articles. This new thread does the following:

* Updates Wikipedia:BacklinkRedirects (or related DB table) to indicate that
a backlink redirect has started. This appears on RC.
* Starts updating the links, one at a time. Changes do not appear on RC.
* After it finishes updating each article, it checks to see if someone has
clicked on the "cancel" link in Wikipedia:BacklinkRedirects. If so, it
reverts its changes and stops, indicating this on RC and
Wikipedia:BacklinkRedirects.
* Once it has finished, it updates the table related to
Wikipedia:BacklinkRedirects to indicate that the job is now over. This does
not appear on RC.

The job stays there on the lower half of the page for all time, with some
method of accessing multiple pages of them. Anyone can revert such completed
jobs. Reversions of complete jobs are handled at the usual thread priority
(arguable, I could be wrong). Articles which have changed since the initial
update are, of course, not reverted.

As you can see, with this scheme, even an edit war over a huge set of links
will create little server load in peak times, as long as both sides of the
fray watch Wikipedia:BacklinkRedirects vigilantly.

-- Tim Starling.

_________________________________________________________________
MSN Instant Messenger now available on Australian mobile phones.?Go to
http://ninemsn.com.au/mobilecentral/hotmail_messenger.asp


subject: [Wikitech-l] Bot approval request

body:
>>what does that mean "you are not in a position to
>>contribute to the approval process" ???
>
>I was suggesting that it's not Fred who makes the decisions, it's people
>like Brion and Lee. It doesn't make much sense to me either, now that I've
>calmed down. Please forget I said it.

Sorry, that quote (>>what...) was from Anthere. I didn't properly attribute
it.

_________________________________________________________________
Hotmail now available on Australian mobile phones. Go to
http://ninemsn.com.au/mobilecentral/hotmail_mobile.asp


from_name: The Cunctator

subject: [Wikitech-l] Software Assisted Context Resolution

body:
On Mon, 2003-03-31 at 00:08, Gary Curtis wrote:
> Hi people.
> This is my first post to wikitech-l, and its a biggun. I've
> been mulling over this idea for a while now and have finally
> gotten the electrons moving...
>
> I propose a number of changes to the Wikipedia software to
> enable "software assisted context resolution", or if you
> prefer "software assisted disambiguation". The primary purpose
> of these changes is to allow users to more easily resolve
> ambiguous links at the time they are created, or if necessary,
> at some later stage. I stress that this is not "automatic"
> link resolution, although the process will be invoked
> automatically in many cases.

This should be discussed on wikipedia-l, not wikitech-l. Wikitech-l
should just be for code implementation issues, not policy decisions that
everyone can and should weigh in on.


from_name: Stevertigo

subject: [WikiEN-l] weekeepeedee-uh Libel

body:
>>Brion:What would such a policy need to say that the Neutral Point of View
policy does not?

Well, Daniel once again has got the feel for the issue...  that is that NPOV
and being sued for libel are two different things... I can understand what
youre getting at Brion.. that they are related, with regard to an editors
point of view, But still, we here are involved in making policy and crafting
some general ways of dealing with related (even outside in the legal world)
issues so that later, when these things might come up, they've been thought
through somewhat beforehand.

NPOV is a good general policy.. but when Libel really means someone trying
to edit Wikipedia through a legal interface, rather than the normal one.
Here, of course, as I've said on the T:W:Libel page, theres a burden of
responsibility automatically placed on someone to make a change themselves,
if something is incorrect... Im sure this has been said before, in similar
words.. So, I dont think WP has much to worry about at all... If its true,
and the tribe sticks to it... and yet they want to sue... fine... That would
be one of the easier cases to argue... lawyer or not...

So, yes its an issue.. and having a foundation would inevitably mean a
policy with regard to being sued. And whatever policy that is.. simply by
nature of being solidified into some guide, would have some minimal bearing
on the freedoms Wikipedians enjoy in editing articles.

Funny enough, a major Libel case - Richard Perle is going to sue Seymour
Hirsch (and The New Yorker) for his column... not here in the US, but in
England... go figure... the laws there are apparently more favorable to him,
despite the fact that neither lives there, and the circulation there is a
sliver of what it is here. -Steve


subject: [Wikitech-l] What, no salt?

body:
Gee, the interesting things you find when browsing the wikipedia codebase.
Don't you people know what salt is? I'll give you a clue. Here's how an
attacker with access to Wikipedia's hashed passwords would currently
inverse-MD5 the passwords:

sort user table by hashed password;
foreach (possible password) {
    x = md5(password_guess);
    binary search table for match;
}

And here's how it would work with salt:

for (userNum=0; userNum < numUsers; userNum++) {
    foreach(possible password) {
        x = md5("wikipedia" + userNum + password_guess);
        check for match
    }
}

Some numbers: my password is 9 essentially random lower case letters. By
brute force, it would take a hacker about a week to inverse MD5 it, with one
computer. With the current scheme, if all 10000 users of Wikipedia used the
same kind of password, the hacker would successfully inverse MD5 one roughly
once every 10 minutes. He could then check those username/password
combinations against other sites -- say, Internet banking, unix accounts on
various servers, email, etc.

Don't worry, I fixed it. What do I do with the rectified code (once I've
read over it a couple more times)?

-- Tim Starling.

_________________________________________________________________
MSN Instant Messenger now available on Australian mobile phones.?Go to
http://ninemsn.com.au/mobilecentral/hotmail_messenger.asp


from_name: Jimmy Wales

subject: [WikiEN-l] It is time to ban Michael

in_reply_to: <8ipZpjrhpVB@erik_moeller>; from erik_moeller@gmx.de on Sun, Mar 30, 2003 at 05:37:00AM +0100

body:
Erik Moeller wrote:
> I could fix up the IP blocking code to include an expiry date fairly
> quickly, would that help? You would have to block a few times but it
> would probably scare him off.

I think having an expiry date on IP blocking code would be a good idea
generally, because it helps to alleviate the possibility that some
dynamic ips are broken for long periods of time.

I've made no decision about Michael yet, although a ban does seem to
be in order.  I hadn't heard anything about him since I gave him a
warning, and I hadn't been paying attention.  So I'll need to review
his contributions and possibly try to talk to him again. :-(

--Jimbo


from_name: Gary Curtis

body:
Hi people.
This is my first post to wikitech-l, and its a biggun. I've
been mulling over this idea for a while now and have finally
gotten the electrons moving...

I propose a number of changes to the Wikipedia software to
enable "software assisted context resolution", or if you
prefer "software assisted disambiguation". The primary purpose
of these changes is to allow users to more easily resolve
ambiguous links at the time they are created, or if necessary,
at some later stage. I stress that this is not "automatic"
link resolution, although the process will be invoked
automatically in many cases.

The process, detailed below, is invoked in two ways. The
first would be manually and explicitly by the user. The
secound would be automatic when an article with new or
modified links it saved.

To enable this process to be invoked manually I propose that
a new meta-link be added to the footer of every page that
contains at least one link (most pages). IMHO, an appropriate
position would be between "Edit this page" and "Discuss this
page". It would read "Resolve links", and invoke a page titled
"Resolving links from (real title)". This new page would look
identical to the original except that the destination of each
link is changed to a "context selection" page as detailed below.
Note that it is entirely possible (and probable) that many links
will point to UNambiguous pages. "Context selection" pages will
still be generated for these links as the user may have found
the first instance of ambiguity and will need to deal with it.

The "context resolution" process would also be invoked when an
article is saved, and the article contains new or modified
links. In this case the "context resolution" page would not be
a mimic of the real page. Rather, a short list of new or modified
links would be generated in the form of an alphabetized list.

The "context selection" pages are generated from the articles
currently known as "disambiguation pages".  The bulleted list
found in these articles is transformed into a set of radio
buttons. In addition, a radio button is generated that basically
means "unresolved". At the bottom of this list is a small form
to allow new links and associated context descriptions to be
added. Whichever option is selected from this page, the link in
the calling page is adjusted to point to the selected destination
article, with the original text preserved by using the pipe trick.

A by-product of these changes will be that the "context selection"
pages will, in the main, be updated by the wiki software (as
opposed to hand editted). This should make it possible to more
tightly control the layout of these pages, perhaps with the
addition of subheadings like "People", "Places", "Things".
Further, when the "Edit this page" link is clicked on a "context
selection" page, the normal edit page is replaced by a purpose-
built form for editing such pages.

I understand that there are probably a millions reasons why some
aspect(s) of the above will be difficult or impracticable. I hope
that the general concept is possible and feasible.

Gary Curtis
[[User:Gaz]] on Wiki
<wikiman.at.freemail.dot.com.dot.au> for all Wiki email

--------------------------------------------------------

Looking for a free email account?
Get one now at http://www.freemail.com.au/

--------------------------------------------------------


subject: [Wikipedia-l] Software Assisted Context Resolution

body:
Hi people.
This is my first post to wikipedia-l, and its a biggun. I've
been mulling over this idea for a while now and have finally
gotten the electrons moving...

I propose a number of changes to the Wikipedia software to
enable "software assisted context resolution", or if you
prefer "software assisted disambiguation". The primary purpose
of these changes is to allow users to more easily resolve
ambiguous links at the time they are created, or if necessary,
at some later stage. I stress that this is not "automatic"
link resolution, although the process will be invoked
automatically in many cases.

The process, detailed below, is invoked in two ways. The
first would be manually and explicitly by the user. The
secound would be automatic when an article with new or
modified links it saved.

To enable this process to be invoked manually I propose that
a new meta-link be added to the footer of every page that
contains at least one link (most pages). IMHO, an appropriate
position would be between "Edit this page" and "Discuss this
page". It would read "Resolve links", and invoke a page titled
"Resolving links from (real title)". This new page would look
identical to the original except that the destination of each
link is changed to a "context selection" page as detailed below.
Note that it is entirely possible (and probable) that many links
will point to UNambiguous pages. "Context selection" pages will
still be generated for these links as the user may have found
the first instance of ambiguity and will need to deal with it.

The "context resolution" process would also be invoked when an
article is saved, and the article contains new or modified
links. In this case the "context resolution" page would not be
a mimic of the real page. Rather, a short list of new or modified
links would be generated in the form of an alphabetized list.

The "context selection" pages are generated from the articles
currently known as "disambiguation pages".  The bulleted list
found in these articles is transformed into a set of radio
buttons. In addition, a radio button is generated that basically
means "unresolved". At the bottom of this list is a small form
to allow new links and associated context descriptions to be
added. Whichever option is selected from this page, the link in
the calling page is adjusted to point to the selected destination
article, with the original text preserved by using the pipe trick.

A by-product of these changes will be that the "context selection"
pages will, in the main, be updated by the wiki software (as
opposed to hand editted). This should make it possible to more
tightly control the layout of these pages, perhaps with the
addition of subheadings like "People", "Places", "Things".
Further, when the "Edit this page" link is clicked on a "context
selection" page, the normal edit page is replaced by a purpose-
built form for editing such pages.

I understand that there are probably a millions reasons why some
aspect(s) of the above will be difficult or impracticable. I hope
that the general concept is possible and feasible.

Gary Curtis
[[User:Gaz]] on Wiki
<wikiman.at.freemail.dot.com.dot.au> for all Wiki email

--------------------------------------------------------

Looking for a free email account?
Get one now at http://www.freemail.com.au/

--------------------------------------------------------

--------------------------------------------------------

Looking for a free email account?
Get one now at http://www.freemail.com.au/

--------------------------------------------------------


from_name: Performing Art

subject: [Wikitech-l] Matthew Barney

body:
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20030331/55109461/attachment.html>


subject: [WikiEN-l] Re: weekeepeedee-uh Libel

body:
Sheldon Rampton wrote:
> His point at the time was that my Disinfopedia is inherently more
> controversial and confrontational than Wikipedia. Being controversial
> arguably creates more INCENTIVE for someone to sue.

That's a good point, and really is what I had in mind.  Disinfopedia
is intended to be provocative in a way that wikipedia is not.


subject: [Wikitech-l] Re: What, no salt?

references:
<F16rdjjT5cLI6Q4ZLsl000075d4@hotmail.com>
	 <1049070182.16552.14.camel@frank.vibber.org>
	 <20030331010207.GA764@twoevils.org>
	 <1049078148.17003.12.camel@frank.vibber.org>
	 <oprmwejnxgk4g8ki@news.gmane.org>

body:
On Mon, 2003-03-31 at 04:05, Richard Grevers wrote:
> On 30 Mar 2003 18:35:50 -0800, Brion Vibber
> > Way back when, I suggested* using paths instead of hostnames for the
> > languages:
> >
> > http://wikipedia.org/en/Jimmy_Carter
> > http://wikipedia.org/eo/Jimmy_CARTER
> > http://wikipedia.org/ko/%ec%a7%80%eb%af%b8_%ec%b9%b4%ed%84%b0
> >
> Those would result in illegal cookies (the two-dot rule for domains).

No it wouldn't. They'd be set with ".wikipedia.org".

-- 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/20030331/8ce77de3/attachment.pgp>


from_name: koyaanis qatsi

subject: [WikiEN-l] 10. war in Iraq (Poor, Edmund W)

body:
I can't stress enough how much I would like for a
discussion of the war in Iraq to take place somewhere
other than the mailing list.  Why don't the interested
parties decide where to hold the discussion, announce
which page that is, and then continue the discussion
there?

thanks

kq

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


from_name: Brion Vibber

subject: [Wikipedia-l] Random pages (was Re: Changes and suggestions)

body:
On Mon, 2003-03-31 at 02:07, Andre Engels wrote:
> If I remember correctly, there are 1000 pages being selected once a day or
> so, which are then cycled through. So once you get a significant portion of
> this 1000 pages, you would indeed often be getting the same pages again.

No, that's not correct. Random selection is made from the set of all
articles. Each page is assigned a random number. The set of pages is
sorted by the random number, and a random index into this set is
selected. The selected page's random number is then reassigned to a new
random number so it should not be reselected even if the same random
index came up on a subsequent random load.

If that's not random enough, it may be due to an allegedly defective
RAND() function in MySQL 3.x.

At one time, random selection was made by picking 1000 articles at
random, then picking random indexes from that queue for the next X
number of random selections (a 1 in 800 chance of resetting the queue on
each random load). This was abandoned because the queue system was
problematic (high probability of duplicates; too-slow queue refill
operation; would sometimes bring up deleted pages; on smaller wikis it
didn't update, etc).

-- 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/20030331/3b2b2363/attachment.pgp


from_name: Sheldon Rampton

subject: [WikiEN-l] Re: weekeepeedee-uh Libel

body:
Awhile back, Jimbo wrote:

>>From our perspective, NPOV is a great mechanism for avoiding libel,
>because it's pretty hard to libel someone without taking any position.

His point at the time was that my Disinfopedia is inherently more
controversial and confrontational than Wikipedia. Being controversial
arguably creates more INCENTIVE for someone to sue. Regarding the
question of actual LIABILITY, however, I don't think NPOV offers the
protection that Jimbo thinks.

The Wikipedia editorial policy is "neutral point of view." My
Disinfopedia policy is "fair and accurate." Either of those policies,
if practiced consistently and completely, should offer protection
against a successful libel action. (Actually, I think "fair and
accurate" offers slightly better protection, because it may be easier
to define "accurate" than "neutral.") In practice, however, 100%
compliance doesn't exist. The real question is what happens if
someone wants to sue over an article that they think fails to meet
one of these standards.

To put this in concrete terms, let's consider how someone might write
an article about Jeffrey Dahmer. It is certainly fair and accurate to
say that Dahmer was a serial killer and human cannibal. I haven't
looked at the Wikipedia article on Dahmer, but I imagine that's what
it says about him, and I can't imagine anyone seriously claiming that
these statements violate the NPOV rule. Moreover, Dahmer's relatives
would have no basis for a lawsuit, because this characterization is
true. It's been proven in court, and Dahmer admitted it.

Now let's imagine a hypothetical situation in which a false urban
legend has been circulating that MERV GRIFFIN is a serial killer and
human cannibal. This claim gets added to the Wikipedia by someone who
believes it. Griffin responds by suing for libel.

You can't really argue that a NPOV rule prevents Wikipedians from
calling ANYONE a serial killer and human cannibal. Therefore, the
question of whether it's OK to say this about Merv Griffin ultimately
devolves to whether it is a "fair and accurate" statement.

 From a strict NPOV perspective, in fact, you would have to refrain
from taking a position either way about Merv's eating habits. Once
someone has inserted that claim in an article, subsequent editors
must either (1) delete the claim entirely, because it's ridiculous,
thereby asserting a point of view; or (2) offer a tortured
construction such as, "Some people allege that Merv Griffin kills
people and eats them; most people, however, contend that this is
ridiculous." If you adopt #2 (the strict NPOV construction), Merv
might still have grounds for libel action.

I'm certainly not trying to suggest that the Disinfopedia editorial
policy is better than the Wikipedia policy. The two policies simply
serve different purposes. However, I'm questioning whether
Wikipedia's policy offers as much protection against libel action as
some people seem to think.
--
--------------------------------
|  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: Poor, Edmund W

subject: [WikiEN-l] Writing about Saddam (was: Be on the lookout, 172 is back)

body:
Hey, Daniel, I hate to throw it back in your face, but...

Around here, the usual policy is:
1. If you see a problem, fix it.
2. If you can't fix it by yourself, ask for help.

I think you are capable of:

* attributing controversial statements to their adherents
* mentioning that So-and-so has called Saddam's policies "oppressive"
* mentioning that Whosis believes that Saddam has "terrorized" his own people
* reporting on the extent to which speaking out against him has gotten people killed
* writing (or linking to) an article about Saddam's use of chemical weapons against the Iranians and Kurds
* writing (or linking to) an article about uprisings following the first Gulf War, and the outcome of those uprisings, e.g., Joe StraightArrow said "Saddam brutally crushed the uprising in al-Giraffe, killing N thousand unarmed civilians" or whatever.

This might seem like a lot of work to you, but remember that you asked to become a sysop. People expect more!

Ed Poor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030331/17ffde26/attachment.htm


subject: [WikiEN-l] 172

body:
> This is a violation of sysop guidelines. You are
> not allowed to protect a page where an edit war
> occurs in which you yourself are involved. Please
> do not do this. I have unprotected the page.
> Sysops are NOT editors.

It's not as strict as that. I see nothing wrong with:

1. Telling the list you protected the article (and why).
2. Making ONE LAST EFFORT toward neutral POV.
3. Then butting out until a consensus emerges.

I would only worry, Erik, if someone made a practice of getting the last word by repeatedly doing the above.

In this case, another sysop selected another version to revert it to, so no harm was done.

Ed Poor
----
"Don't cry till you're hurt". --Robert Heinlein, ''The Man Who Traveled in Elephants''


subject: [WikiEN-l] 172

in_reply_to: <20030331182714.A625@chiark.greenend.org.uk>; from mattheww+wikipedia@chiark.greenend.org.uk on Mon, Mar 31, 2003 at 06:27:14PM +0100

body:
I would say that absent some kind of serious emergency, sysops should
never protect pages that they've edited recently.

> > 1. Telling the list you protected the article (and why).
> > 2. Making ONE LAST EFFORT toward neutral POV.
> > 3. Then butting out until a consensus emerges.

The problem I see with this is that once an article is protected, it's
hard for a consensus to emerge.

--Jimbo


subject: [WikiEN-l] Sorry about the inappropriate lecture

body:
Oops!

I just noticed that the "Daniel" whom I was lecturing was Daniel Mayer, aka Maveric -- not Daniel Ehrenberg (LittleDan).

Thus the condescending tone of my message seems doubly out of place.

Apologies all around :-(

Contritely,

Ed Poor

	 -----Original Message-----
	From: 	Poor, Edmund W.
	Sent:	Monday, March 31, 2003 8:58 AM
	To:	'wikien-l at wikipedia.org'
	Subject:	Writing about Saddam (was: Be on the lookout, 172 is back)

	Hey, Daniel, I hate to throw it back in your face, but...

	Around here, the usual policy is:
	1. If you see a problem, fix it.
	2. If you can't fix it by yourself, ask for help.

	I think you are capable of:

	* attributing controversial statements to their adherents
	* mentioning that So-and-so has called Saddam's policies "oppressive"
	* mentioning that Whosis believes that Saddam has "terrorized" his own people
	* reporting on the extent to which speaking out against him has gotten people killed
	* writing (or linking to) an article about Saddam's use of chemical weapons against the Iranians and Kurds
	* writing (or linking to) an article about uprisings following the first Gulf War, and the outcome of those uprisings, e.g., Joe StraightArrow said "Saddam brutally crushed the uprising in al-Giraffe, killing N thousand unarmed civilians" or whatever.

	This might seem like a lot of work to you, but remember that you asked to become a sysop. People expect more!

	Ed Poor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030331/9f4248f1/attachment.htm


from_name: Tim Starling

subject: [Wikitech-l] What, no salt?

body:
>Obviously we'd have to add a note explaining that everyone has to reset
>their password. Not everyone has an e-mail address attached to their
>account, so we'd need to add a web form for doing this. That obviously
>would require first validating the person with their current password
>with the current hashing code; so we'd probably need a marker to
>indicate that each users' password field is upgraded.

No-one will have to reset their password. I'll just use md5(md5(password) +
salt) for the new hash. The only thing users will notice is that their
stored cookies will stop working and they'll have to log in again.

-- Tim Starling.

_________________________________________________________________


subject: [Wikitech-l] What, no salt?

body:
>Si.
>And remember, on the first of january 2003, someone
>took over three sysops accounts on the french wiki,
>and indicated our passwords in clear to the three of
>us.
>So...well...security...hum

If we really want to be serious about security we'll have to use ssl for
login, but I don't know how to do that.

-- Tim Starling

_________________________________________________________________
MSN Instant Messenger now available on Australian mobile phones.?Go to
http://ninemsn.com.au/mobilecentral/hotmail_messenger.asp


from_name: Anthere

body:
> I just noticed that the "Daniel" whom I was
> lecturing was Daniel Mayer, aka Maveric -- not
> Daniel Ehrenberg (LittleDan).

>  This might seem like a lot of work to you, but
> remember that you asked to become a sysop. People
> expect more!

LOL ! Thanks for the laugh Ed !

Eh, could you remind me of the sysop roles as editors
?

Anthere

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


subject: [WikiEN-l] Not to worry (was: weekeepeedee-uh Libel)

body:
Sheldon, I think you worry too much -- at least, as far
as Jimbo and the Wikipedia project are concerned.

Wikipedia is a work in progress. I don't think anyone
would bother to launch a libel action against it, if for
no other reason than it's hard to hit a moving target.

Think about newspapers. Suppose the New York Times
prints a letter to the editor from Joe Blow, saying that
Merv Griffin is a cannibal. Is that actionable?

Suppose it's a signed column on the op-ed page. Joe
Crow, columnist, says Griffin eats people.

Suppose it's an editorial: the NYT calls Griffin a
cannibal.

Or it's a front-page article, with a headline screaming
"Griffin eats human flesh!"

But then his lawyers contact the paper and say, "Dude!
Whassup with that? That's grody to the max!"

The response of the newspaper to the lawyer's letter is
key.

If they say, "We stand by our story" then they may have
to battle it out in court.

But if they say, "Oops, you're right! We'll print a
retraction" -- then what basis is their for a libel
action?

Wikipedia is way different from your project: we
constantly strive for neutrality on all issues; you take
a definite stand on many issues. We'll never have to
fight, because we're not *asserting* anything. But
you're going around accusing this person and that group
of deceptive PR campaigns to cover up misdoings
(especially environmental wrongs), and on top of that
you're planning to *assert* that you're doing so
"fairly and accurately".

We march to different drummers, dude!

Ed Poor


subject: [WikiEN-l] Re: Not to worry

body:
Ed Poor wrote:

>Sheldon, I think you worry too much -- at least, as far
>as Jimbo and the Wikipedia project are concerned.
>
>Wikipedia is a work in progress. I don't think anyone
>would bother to launch a libel action against it, if for
>no other reason than it's hard to hit a moving target.

I certainly hope you're right, but people file libel actions for all
sorts of reasons, some of which are unfair and unreasonable. People
sue in hopes of getting a quick cash settlement; they sue because
they're jerks or because they're paranoid; sometimes they sue because
they're in the right.

Given the nature of my own project, I certainly want to make sure
that I understand how libel law could affect the Disinfopedia.
However, I don't think you can just *assume* that no one would bother
to sue Wikipedia. Currently you're a much larger target than
Disinfopedia, reaching a larger potential audience and therefore a
larger pool of potential litigants. Even if we assume that the
average Wikipedian is less likely to sue than the average
Disinfopedian, you still may be at higher risk.
--
--------------------------------
|  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
--------------------------------


subject: [WikiEN-l] war in Iraq

body:
We need to come up with a neutral, timeless name for the war
in Iraq. Forgive me for the length of this post, but I
believe it's important enough to warrant your attention.

I object to the incessant labeling of the war in Iraq as
the "invasion of Iraq". There is a lot more to the war than
the fact that 2 or 3 countries have invaded it.

Regardless of our personal feelings about how right or wrong
the conduct of any nation in the war has been, the
*articles* should:
* have neutral content
* have neutral titles

Let me lay my cards on the table, so you don't
misunderstand. My church opposes the US campaign: Bush was
wrong to attack. I agree with that POV. Many others do,
also, although perhaps not for precisely the same religious
reasons as Rev. Moon.

However, even though I'm "right" about my POV and most
Wikipedians happen to agree with me...

WE ALL AGREED TO ADHERE TO JIMBO'S NEUTRAL-POINT-OF-VIEW
POLICY

Excuse me for shouting, but several of us have been
confounding neutral-point-of-view with other things. I'm not
naming names and not engaging in prolepsis or other Roman
rhetorical tricks. I just want to fix the problem, so let's
all pitch in, please.

The war started in 2003, and it's taking place in Iraq
(which is near the Persian Gulf), so we might call it:

* the [[2003 war in Iraq]] or [[2003 Iraq War]]
* the [[2003 Gulf War]]

There are various military campaigns. I know of 4 countries
fighting against Iraq (the "allies" or "coalition"). We
should write about the war from the standpoint that there
are two sides in the war:

* Iraq
* US, UK, Australia & Poland

(I might be wrong about Australia or Poland; if so, that's
an important detail and please correct me.)

(There might be other countries which are parties to the
conflict. Maybe Iraq has a military or other ally which I
don't know about; if so, we should write about that ally!
There are up to 4 dozen countries in various degrees of
opposition to Iraq, and we've begun an article or two on
them.)

Also, I think "coalition of the willing" is a purely
political phrase: propaganda, i.e., a slogan. I don't think
it makes a good title for either of the following topics:

* the countries which oppose Iraq in the 2003 war, or
* every country which has made a statement or taken action
FOR OR AGAINST IRAQ

The latter topic, especially, would be just plain stupid to
call [[coalition of the willing]] because by design it
includes opponents.

I started dividing the [[coalition of the willing]] article
into:

* a short article about the slogan "coalition of the
willing"
* a longer article, tentatively called [[US-led coalition
against Iraq]]

But the "...coalition" article lists every nation in the
world which has ever made a statement or taken action on the
war. Roughly, there are around 2 or 3 dozen nations ranged
against Iraq (in word or deed) and maybe 5 dozen speaking up
for them or providing aid.

Shouldn't we have an article which lists the positions of
each nation of the world on this war? If so, what should we
call it? How about [[national positions on the 2003 war in
Iraq]]? Can we think of a shorter or more accurate title?

I hate to keep taking discussion off the talk pages, but
this is the only central place I know of, and talk gets
fragmented and overlooked too easily when discussing
multiple articles.

Ed Poor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030331/89ab6411/attachment.htm


body:
--- koyaanis qatsi <obchodnakorze at yahoo.com> wrote:
> I can't stress enough how much I would like for a
> discussion of the war in Iraq to take place
> somewhere
> other than the mailing list.  Why don't the
> interested
> parties decide where to hold the discussion,
> announce
> which page that is, and then continue the discussion
> there?
>
> thanks
>
> kq

You are quite right kq.

The problem is it seems there is no central place to
discuss anything about it. The pages keep changing
everyday, with large portions being excised, moved
here and there, new pages been created. Unless you
spend a lot of time on them (when the server is
working), there is little chance to have any impact on
them.

I feel totally lost between all of them. I will just
thank those who try to maintain some neutrality and
those who made the effort to remove inappropriate
comments that have little to do here, even in talk
pages where some claim we can express pov.

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


subject: [Wikipedia-l] Re: Software Assisted Context Resolution (from\r wikitech-l)

body:
At Mon, 31 Mar 2003 12:28:59 +0200 (CEST),
Andre Engels (engels at uni-koblenz.de) wrote:
> On Mon, 31 Mar 2003, Tim Starling wrote:
>
> > This is also on wikitech-l, forwarded on to wikipedia-l at
> Cunctator's
> > request.
> >
> > I've already briefly discussed this with Gary on his user talk
> page. A few
> > observations:
> >
> > In his proposal below, Gary does not explicitly deal with what
> happens when
> > a previously unambiguous name is given a second meaning. Here's
> what I
> > suggest:
> >
> > * The original page is moved to a disambiguated name. This name
> is selected
> > by the user who creates the second page.
> > * All existing links are updated via the pipe trick to point to
> the
> > newly-disambiguated primary article.
>
> Sounds like a bad idea - any pages that previously referred to the
> old
> page _wrongly_ would now be even more wrong. There will be rare
> cases where
> one disambiguation subject would be the only one that had links,
> but more
> commonly there are a few links that go to other disambiguation
> subjects. So
> I would very much prefer to have disambiguation done by hand, or
> at least
> under human control.
>
> Andre Engels

My original idea is for the human to control the disambiguation
process. The software just facilitates the process.

Gary Curtis

--------------------------------------------------------

Looking for a free email account?
Get one now at http://www.freemail.com.au/

--------------------------------------------------------


from_name: Yann Forget

subject: [Wikipedia-l] Changes and suggestions

body:
Le Dimanche 30 Mars 2003 23:21, Anthere a ?crit :

> > > 4. Could we slightly improve the search box, maybe
> >
> > > by having a drop down menu aside from it : search in
> > > encyclopedia by default as right now, search in
> > > personnal pages, search in meta pages...but have
> >
> > > it at first level, not on a second page, after a first
> > > unfruitful search.

> Say...this could improve performance issues, no
> ?...so...could it be planned if nobody disagrees ?
>
> Does someone disagree ?
> Which categories would we define ?

I think this is a high priority.
The categories now proposed for a second search are fine (Talk, User, User
Talk, Wikipedia, Wikipedia Talk, Image, Image Talk, Redirect).
And a selection Search title / Search content, with "Search title" as default.
I think this last would most reduce charge on the server.

Yann

--
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: [Wikitech-l] What, no salt?

body:
Lee Daniel Crocker wrote:
> Frankly, I don't see much need
> for high security of Wikipedia logins.

Agreed.  Remember that in the old wikipedia software, anyone could log
in as anyone else, password or no password.

--Jimbo


from_name: Andre Engels

body:
On 30 Mar 2003, Brion Vibber wrote:

> On Sat, 2003-03-29 at 23:52, Anthere wrote:
> > 1. Was the count system for pages changed ? If it was,
> > when was it ? When it is changed, could it be
> > announced on the "announced list" please ? It will
> > also need to be made obvious on the stats pages
>
> The official vote results were to count pages in article space that are:
> * not completely empty (size greater than 0 bytes)
> * contain at least one link (search for "[[" should do)
>
> Unless someone else snuck it in and forgot to tell me, the change has
> not yet been put in effect, as I'm a lazy, grumpy bastard and way way
> too busy of late. :)

Well, I did notice that the article count for Japanese has skyrocketed
(from 251 to 3337 in two weeks); I thought this was because of the new
counting method. If not, the Japanese are to be congratulated on their
productivity.

> > 4. Could we slightly improve the search box, maybe by
> > having a drop down menu aside from it : search in
> > encyclopedia by default as right now, search in
> > personnal pages, search in meta pages...but have it at
> > first level, not on a second page, after a first
> > unfruitful search.
>
> Yes, that would be lovely.

I agree.

> > So, since others protest and undelete the
> > redirections, some asked if it would be possible to
> > somehow catch mispellings, redirect the mispelled
> > title to the right-spelled page, *and* dynamically
> > display a message at the top of the article saying
> > "you asked for "fachisme", this word does not exist,
> > and is probably a mispelling of "fascisme".
>
> It has in the past been suggested to have a special type of redirect for
> misspellings. These could have a "you're an illiterate idiot, from now
> on please type 'X'" message display when visited or searched, but be
> hidden from lists like the Allpages list or general search results.
>
> Would that be a help?

Please do not use this kind of message - in most cases the person ending up
on a misspelled page is NOT the one who MADE the misspelling, just the one
who READ it.

Andre Engels


body:
On Sun, 30 Mar 2003, Bryan Derksen wrote:

> At 12:51 AM 3/30/03 -0800, Brion Vibber wrote:
> >On Sat, 2003-03-29 at 23:52, Anthere wrote:
> > > 3. Could it be possible that the "random page" be (per
> > > option) chosen with a size threashold ? This would be
> > > to avoid all these pages about dates and french little
> > > villages that keep on appearing on random pages :-).
> >
> >Hehe... Traditionally people asked for that to keep out the city pages
> >on the English wiki, which wouldn't help at all since those pages are at
> >or _above_ the median article size...
>
> While on the subject of the "random page" link, why is it that the page it
> takes me to is apparently not very random? Sometimes when I've got nothing
> specific to do I'll just start clicking random page repeatedly searching
> for an interesting article to tinker with, and I find that I start visiting
> the same small set of pages over and over again. Also, it seems that an
> unusually large number of these random pages are ones which have been just
> recently edited, though I haven't done a rigorous count of this. Is there
> some sort of non-random algorithm being used?

If I remember correctly, there are 1000 pages being selected once a day or
so, which are then cycled through. So once you get a significant portion of
this 1000 pages, you would indeed often be getting the same pages again.

The second thing is similar - if you see something on random page, it is like
others have seen it in the same way as well. Pages that are on random page
are thus more visited, and therefore more edited, in the last day.

Andre Engels


subject: [Wikipedia-l] Re: [Wikitech-l] Software Assisted Context Resolution

body:
At Mon, 31 Mar 2003 12:40:12 +0100,
tarquin (tarquin at planetunreal.com) wrote:
>
>
> Gary Curtis wrote:
>
> >I propose a number of changes to the Wikipedia software to
> >enable "software assisted context resolution", or if you
> >prefer "software assisted disambiguation". The primary purpose
> >of these changes is to allow users to more easily resolve
> >ambiguous links at the time they are created, or if necessary,
> >at some later stage. I stress that this is not "automatic"
> >link resolution, although the process will be invoked
> >automatically in many cases.
> >
>
> Well we sort of already have this...
> Maintenance page -> disambiguation pages with links
>
> :-)
>
> The other mechanism we have for this is Plain Old Brainpower -- if
> you
> write in a certain area of the Wikipedia for some time, you come
> to know
> which pages are disambiguation and which aren't.

Frankly, this proposed mod is not for users of the skill level
of tarquin (or say mav or zoe). They don't need "software
assistance", but would probably use it ;-).

It is for Jack or Jill Average, who adds a link to [[mercury]]
with little thought that there are so many mercury's. I want
the software to "protect" the database from this user's well-
intentioned edit. Not that the user is going to do any real
damage here, but if the user resolves the link then someone
doesn't have to do it later.

Gaz

--------------------------------------------------------

Looking for a free email account?
Get one now at http://www.freemail.com.au/

--------------------------------------------------------


subject: [WikiEN-l] war in Iraq

body:
On Mon, 2003-03-31 at 10:43, Poor, Edmund W wrote:

> I hate to keep taking discussion off the talk pages, but
> this is the only central place I know of, and talk gets
> fragmented and overlooked too easily when discussing
> multiple articles.

Ah, the poor, forgotten, benighted meta.wikipedia. Perfectly designed
just for this.


subject: [Wikipedia-l] Changes and suggestions

body:
Tarquin wrote:

>Brion VIBBER wrote:

>>It has in the past been suggested to have a special type of redirect for
>>misspellings. These could have a "you're an illiterate idiot, from now
>>on please type 'X'" message display when visited or searched, but be
>>hidden from lists like the Allpages list or general search results.
>>Would that be a help?

>yup :-)
>#MISSPELLING [[Napoleon]]
>for "Napolean", say

It's been suggested at least twice before.
I said #DEPRECATED (because it could be for more than misspellings --
old CamelCase, for example, or anything else that unneede for searches).
Somebody else said something else a while earlier than that.

>I also suggested non-English wikipedias might find it easier to have a
>synonym of the keyword #REDIRECT in their own language -- so on fr:,
>#REDIRECT or ... #{whatever} would work

This is a good idea too.

-- Toby


from_name: Michel Mouly

subject: [Wikitech-l] Using TeX

body:
The mail is quite long, I 'included' some php code, and a small 'article'
at the end. I did it like that rather than to include files...

> -----Message d'origine-----
> De:	Toby Bartels [SMTP:toby+wikipedia at math.ucr.edu]
> Date:	lundi 31 mars 2003 07:02
> ?:	wikitech-l at wikipedia.org
> Objet:	Re: [Wikitech-l] Using TeX
>
> Michel Mouly wrote:
>
> >However, when I looked to the details, I found (to my taste) too many
> >limitations with the followed approach. Then I wrote an extension to
> >outputpage.php to replace the call to texvc by calls to pdflatex then
> >imagemagick convert. This has reached the stage of minimal functionality
> >(translation and caching). This allows me to have full maths, without
> >having to remember what is supported or not, or modified, compared to
> >LaTeX. In addition, we intend to use it for small music scores (using
Mu-
> >sixTeX or possibly PMX), and I have in mind some other uses of LaTeX.
>
> Is your version safe against DoS attacks with long scripts?

I confess my ignorance on the topic. But I'm ready to learn. Maybe it is
relevant to mention that, contrarily to texvc, the
text to compile is not in the DOS calls: the script writes files and DOS
lines are pretty standard.

> Is it safe against running TeX commands that access files?

Safety is a real problem, I agree. I did not look in any details to the
question with LaTeX. The
small application I'm trying to set up with some friends is (or will be,
I've still this problem with a blank page
return after submit), I hope, sufficiently safe for reasons independent
from the php scripts. Maybe naive...

> OTOH, does it allow inclusion of additional TeX packages (like Xypic)
> with a simple modification to the code opening up the package?

Well, this can be done already just modifying the 'header.tex' file
(included). That is what I will do for music. My idea (see the article) is
that different markups to choose between header files.

BTW, using drawing packages like Xypic is also on my agenda, see article.

> If so, then some of us (me and AxelBoldt, I guess)
> might well prefer your code to the current texvc --
> at least when producing PNG output instead of HTML.

>
> >Please understand that I'm not trying to (re)open a debate. I've read
the
> >"math markup" page on meta.wikipedia (and music markup as well), and I'm
> >aware of (some of) the drawbacks of the approach I followed. I
mentionned
> >what I did just in conformance with GPL: if there is any interest in
this
> >small piece of code (which I doubt, it's rather trivial!), just say it.
>
> I'd like to see the diff to see just what you took away from texvc.
>

I include the relevant part of outputpage.php. It is
basically scratch code, to check if the idea is viable. At least error
handling requires further work. As you will see, I just 'mimicked' texvc
(same input format, same output format) and kept the rest of the code.

I include header.tex (the very basic and trivial one), for completion.

I also include a text I prepared with in mind the possibility to put it
somewhere in wikipedia or meta wikipedia; I'm too new in the business to
decide whether this is valuable, or where exactly to put it. Consider it
backgroupd information. It deals with 'source' for images or sounds: one of
my problems in my small project is music, and allowing others to modify
scores is important. LaTeX provides those tools as well.

An important point, hinted at in the text, is that compiling the 'source'
on the wikipedia site is not really necessary (though definitely useful).
Then security aspects should be less a problem, as well as computing load
(going through pdflatex is quite long on my machine).

>
> -- Toby
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikitech-l

This the beginning of outputpage.php; the rest is exactly as in the normal
script. The modifications are

1) first step, encapsulating the call to texvc;

2) second step, function 'fulltex', same input format, same output format
as the function encapsulting texvc. The functionality is very slightly
different: the '$' are included in the call to fulltex, so that it can be
used for text in non math mode.

First comes the  4-line 'header.tex'.

\documentclass[12 pt]{article}
\pagestyle{empty}
\begin{document}
\LARGE

# See design.doc

function linkToMathImage ( $tex, $outputhash )
{
    global $wgMathPath;
    return "";
}

function texvc($tex)
{
    global $wgMathDirectory, $wgTmpDirectory, $wgInputEncoding;
    $cmd = "./math/texvc ".escapeshellarg($wgTmpDirectory)." ".
              escapeshellarg($wgMathDirectory)." ".escapeshellarg($tex)."
".escapeshellarg($wgInputEncoding);
    return(`$cmd`);
}

function fullTeX($tex)
      #same output syntax as texvc, generation done via pdfLatex and
Imagemagick convert
{
global $wgMathDirectory, $wgTmpDirectory, $wgInputEncoding;
global $wgPdflatex, $wgconvert;

#wgInputEncoding not taken into account, assumed to be compatible with
pdfLatex

#if (!isset($wgPdflatex)) $wgPdflatex = "pdflatex -quiet -halt-on-error
-interaction batchmode -output-directory $wgTmpDirectory";
  # chdir() ok, while -output_directory leads to pb (pdflatex can't find
its own .aux!!)
if (!isset($wgPdflatex)) $wgPdflatex = "pdflatex -quiet -halt-on-error
-interaction batchmode";
if (!isset($Convert)) $wgConvert =
'C:\Programs\ImageMagick-5.5.6-Q16\convert';
$headerfilename = "$wgMathDirectory/header.tex";
#$headerfilename = 'header.tex';
$header = fopen($headerfilename, 'r');

$md5 = md5($tex);
$filename = "$wgTmpDirectory/$md5";

$fp = fopen($filename.".tex", 'w+');

fwrite($fp, fread($header, filesize ($headerfilename)));

fwrite($fp, "$tex\r");
fwrite($fp, "\\end{document}");
fclose($fp);

$backupcwd = getcwd();
chdir($wgTmpDirectory);
$cmd = "$wgPdflatex $filename.tex";
$res = `$cmd`;

#todo: test if error; OK if empty (thanks to option -quiet)

#$cmd = "$wgConvert $filename.pdf -trim -bordercolor white -border 5 x 5
$wgMathDirectory/$md5.png";
$cmd = "$wgConvert $filename.pdf -trim $wgMathDirectory/$md5.png";
$res = `$cmd`;

#todo: test if error; OK if empty

#todo : delete temporary files (should be kept for debug and error)
chdir($backupcwd);  # don't know if needed, certainly cleaner
return ("+$md5");
}

function renderMath( $tex )
{
    global $wgUser, $wgMathDirectory, $wgTmpDirectory, $wgInputEncoding;
    $mf   = wfMsg( "math_failure" );
    $munk = wfMsg( "math_unknown_error" );

    $fname = "renderMath";

    $math = $wgUser->getOption("math");
    if ($math == 3)
    return ('$ '.wfEscapeHTML($tex).' $');

    $md5 = md5($tex);
    $md5_sql = mysql_escape_string(pack("H32", $md5));
    if ($math == 0)
    $sql = "SELECT math_outputhash FROM math WHERE math_inputhash =
'".$md5_sql."'";
    else
    $sql = "SELECT math_outputhash,math_html_conservativeness,math_html
FROM math WHERE math_inputhash = '".$md5_sql."'";

    $res = wfQuery( $sql, $fname );
    if ( wfNumRows( $res ) == 0 )
    {
#    $cmd = "./math/texvc ".escapeshellarg($wgTmpDirectory)." ".
#              escapeshellarg($wgMathDirectory)." ".escapeshellarg($tex)."
".escapeshellarg($wgInputEncoding);
#    $contents = `$cmd`;

###    $contents = texvc($tex);
    $contents = fullTeX("\$$tex\$");

    if (strlen($contents) == 0)
        return "".$mf." (".$munk."): ".wfEscapeHTML($tex)."";
    $retval = substr ($contents, 0, 1);
    if (($retval == "C") || ($retval == "M") || ($retval == "L")) {
        if ($retval == "C")

<\code>

This discusses how to handle non text elements in wikipedia pages,
such as images, sounds, or math formulae. More precisely, this
advocates the possibility to have the 'source code' of such
elements, so that they can be modified as easily (almost!) as the
text can be modified.

Akin ideas have been discussed in the past (math markup, SVG
support, chess talk page, ...). I did not looked everywhere (by
far!), so the ideas propounded herein are likely not original! If
they are, the key aspect is that the proposed scheme is general,
not specific to one domain, whether it be math formula,
chessboards or vectorised images.

The present state

Documents can already include different types of material, namely
text, images and sounds.

For texts a 'source file', according to a special syntax, is
uploaded, and is 'compiled' (i.e., translated in HTML) by the
wikipedia site.

Images and sounds are simply uploaded. They are either included in
the text (images) or available for links (images and sounds).

There is an intermediate case, that of mathematical formula. They
are included in the visible page as images, but the 'source' is
uploaded and compiled by the site. Another peculiarity is that the
'source' is embedded in the text 'source'. And still another one
is that a special syntax is to be used (derived from TeX, but not
TeX).

That the images and sounds are uploaded 'as is' is, IMHO, in
contradiction with the general goal of wikipedia, in particular
easiness to modify.

In many cases, sounds and images have been, or could, be generated
from a 'source'. Making this 'source' available would have many
advantages:

* it would allow for free modifications, in conformance with the general
spirit;
* it would allow more or less automatic eventual change to another
format (e.g., extensions of HTML);
* it provides ready-to-use examples to other images/sounds/maths.

Let us take an example. Chess positions. This is done at present
with png images. They are quite nice, I agree, but how to modify
them? How to add new ones in the same style as the existing ones?
Simply because the images are difficult to reproduce, a set of
pages become difficult to extend upon. Either a different style of
drawing is used, and the result is not professional, or somebody
becomes an unavoidable intermediate! The talk page of the chess
article shows such concerns.

Imagine now a simple source code to draw chess positions (this
exists in LaTeX). To recipe for creating new drawings is obvious
and  style is consistent. No blocking.

(To complete the example, source code for a chess position with
LaTeX could be (taken from LaTeX graphics companion):

    \usepackage{chess}
    \board{B* * * KR}
          {*r* * *R*}
          {* b p p}
          { *P*k*P*}
          {*p* P *p}
          { P *P* P}
          {* *N*N* }

 Ok, this looks a bit esoteric, but this is a simple matrix, with
 uppercase for white and lowercase for black, p for pawn, k for
 king, n for knight, and so on. The result is a very nice and
professionally
 looking drawing. Don't tell me the source is more esoteric
 or difficult to use than, say, HTML.)

How to upload the source?

The case of math formula provides one approach: to embed the
source in the page text, with a special markup.

This raises then the issue of the generation of the 'compiled'
version. In the case of math, this is done by the site. This
offers the advantage to the users that they don't have to install
anything. On the other hand, this requires that the generation
software is installed on the site, thus limiting freedom, and
consumes some site resources (who does consider that the response
time is short enough??), in particular in the case of successive
corrections, e.g., to correct syntax errors.

The other possibility is to ask the user to upload both the source
and the result. This is more complex for the user, mainly because
this requires the software, but this allows for checking prior
upload (less load on the side, and possibly, all taken into
account, less operations for the user).

In practice (for the user), this consists in extending the upload
page to include:

* the result;
* (optional) the source;
* when not obvious, a description of the 'compiling' method (e.g.,
texvc, pdflatex with such or such header then imagemagick convert,
povray 3.5).

Conversely, clicking on a drawing (for instance) opens a page more
or less as the present one, extended with the source and the
compiling indications, plus the possibility to edit the source
code (exactly as for a text page).

Embedding in the page text can still be a possibility (better for
math than for images for instance), but either has to be limited
to what the site can compile, or has to be coupled with the upload
of the result.

Which formats are acceptable?

Ideally, the source format should be such that:

* it is in plain text;
* it is public, free of copyrights or other constraints;
* it is already in use;
* at least one free version of a 'compiler' is easily available,
easy to install, and easy to use for as many
platforms as possible;
* it must be as secure as possible (to prevent carrying nasty
code).

IMHO, texvc does not respect all the conditions.

Examples (in my limited knowledge) that do respect them include :

* music (scores): lilypond, musixtex;
* music (sound) : midi;
* math : LaTeX;
* images : povray (security??), drawing packages in LaTeX;

Browsing through LaTeX drawing packages, one can see the potential
richness of such a scheme. Could be mentioned, in any order, board
games, card games, graphs, Feynman diagrams, chemical diagrams,
electrical diagrams, ...

Should the list of formats be explicitly prescribed?

IMO, no. Wikipedia is assumed to be self-regulating. If a format
is considered wrong, somebody can transcribe it in something more
appropriate.

<\article>