from_name: Steve Summit

subject: [WikiEN-l] giving medical advice

body:
Timwi wrote:
>>>>The last sentence of the lead,
>>
>> It actually can be spelt "lede".
>
> I couldn't find any dictionary that agrees with this other than
> Wiktionary.

How hard did you look?  The first three google hits are to

http://www.randomhouse.com/wotd/index.pperl?date=20001128

	lede... refers to the opening lines of a newspaper
	article, also called the "lead."

http://www.uark.edu/~kshurlds/FOJ/HW2.html

	Lede is often spelled lead. The odd spelling was adopted...

and Wikipedia's own http://en.wikipedia.org/wiki/News_style

	The most important structural element of a story is the
	lead -- namely contained in the story's first sentence
	(sometimes spelled lede to avoid confusion with...


list: wikien-l

source: pipermail-mbox

from_name: Alphax (Wikipedia email)

subject: [WikiEN-l] Colbert Report heads-up

body:
Oldak Quill wrote:
> On 01/08/06, mboverload <mboverload at gmail.com> wrote:
>> What?  He asked people to vandalise the page.
>
>
> No, I'm saying that Colbert has no sense of good faith. Why would he
> just ask people to vandalise a page? Seems senseless.

He's doing it "for the fun of it"; in reality, it's so that people will
watch him, and he'll get more money.

--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 569 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20060802/2324d300/attachment.pgp


from_name: geni

subject:
[WikiEN-l] Technical solution to bad fair use (was:Uploading
	images should be a privilige...)

body:
On 8/2/06, Steve Bennett <stevagewp at gmail.com> wrote:
>
> The image is still crucial to being able to identify the album in
> other contexts.
>
> Steve

I'm not sure that is much of an fair use defence and in any case where?

--
geni


list: foundation-l

subject:
[Foundation-l] The Atlantic & Colbert - two great tastes that
	taste great together

body:
On 8/2/06, Brad Patrick <bradp.wmf at gmail.com> wrote:
> and "Wikiality" on "The Word" on the Colbert Report.
>
> http://www.powerpage.org/archives/2006/08/stephen_colbert_v_wikipedia.html
>
> Did you know the number of elephants in Africa has tripled in the past 10
> years? 8-D
>

No but I do know we know have a number of vandle hunters who react
somewhat balisticaly to that phrase and that User:Stephencolbert has
been indef blocked.

--
geni


list: wikimedia-l


subject:
[WikiEN-l] OT photocruft (was Re: Technical solution to bad
 fair use)

body:
Steve Bennett wrote:
> On 8/1/06, Stan Shebs <shebs at apple.com> wrote:
>> Heh, my productivity machine is botanical gardens. Photo of label,
>> whole plant, closeups of leaves/flowers, three steps to the left,
>> repeat. :-) UC Berkeley botanical garden sez they have 12,000 taxa
>> for instance, I've only racked up about 300 of them so far...
>
> Bastard! I do European castles. I don't have a car. You have any idea how
> long it takes to take those "three steps to the left"?
>
> Actually the real problem is getting to the article after visiting the
> place, and discovering that someone has already taken a (better) photo of
> it.
>
> Amusing case in point:
> http://commons.wikimedia.org/wiki/Image:Rock_of_Cashel_inside_cathedral.jpg
> (my image)
> http://en.wikipedia.org/wiki/Image:Rock_of_Cashel-castle_interior.jpg
> (existing image)
>

Yours is bigger, which makes it better :)

--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 569 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20060802/ff65d369/attachment.pgp


from_name: Jeff V. Merkey

subject:
[Foundation-l] The Atlantic & Colbert - two great tastes that
 taste	great together

body:
Brad Patrick wrote:

>So not one but two must-read/sees in the same news cycle...
>
>http://www.theatlantic.com/doc/200609/wikipedia
>
>by Marshall Poe
>
>and "Wikiality" on "The Word" on the Colbert Report.
>
>http://www.powerpage.org/archives/2006/08/stephen_colbert_v_wikipedia.html
>
>Did you know the number of elephants in Africa has tripled in the past 10
>years? 8-D
>
>Enjoy!
>
>
>
>
The tide of public opinion is turning . It's only a matter of time Brad
-- wait til I announce
who was just hired as the CEO to head up the Wikipedia based appliance
company -- I think
a whole slew of viable and profitable businesses are about to srping up
around Wikipedia's
fertile soil.

All my Wikilove,

Jeff.


from_name: Mark Gallagher

body:
G'day Steve,

> Actually the real problem is getting to the article after visiting the
> place, and discovering that someone has already taken a (better) photo of
> it.
>
> Amusing case in point:
> http://commons.wikimedia.org/wiki/Image:Rock_of_Cashel_inside_cathedral.jpg
> (my image)
> http://en.wikipedia.org/wiki/Image:Rock_of_Cashel-castle_interior.jpg
> (existing image)

Ahh, yours is quite good.  Sadly, they're too similar to both use in an
article.

I took a photograph of Jon Stanhope the other day, and came home really
rather proud of myself.  But somebody got in first; that it's a better
photograph than mine hardly needs saying.

--
Mark Gallagher
"What?  I can't hear you, I've got a banana on my head!"
- Danger Mouse


from_name: Anthony

subject: [WikiEN-l] Colbert Report heads-up

body:
On 8/2/06, stevertigo <vertigosteve at yahoo.com> wrote:
> --- Anthony <wikilegal at inbox.org> wrote:
> > Now Colbert isn't a journalist, certainly not a traditional
> > one as his show is basically a farce, but I would hope he knows who
> > Jimmy Wales is and would be intelligent enough to contact him or
> > someone else at Wikimedia before doing a segment on it.
>
> Why? Wikimedia just pays the bills - it doesnt run the show.
> Wikipedians run the show, and any Wikipedian who saw that report
> probably got up off the couch and strolled over to their computer
> just to make sure it didnt get out of hand. Wikifaith - apparently
> Colbert has some sense of it. Wikifunniness too maybe.
>
I dunno.  I apparently was wrong that it's a standard practice anyway.
 It would have been nice if *someone* had gotten a heads up *before*
Colbert told the public to come vandalise the web site (even if it was
said tongue-in-cheek).

Anthony


from_name: Will

subject: [WikiEN-l] Colbert Report heads-up

body:
We've been getting elephant population requests ~5 times a day at WP:AFC as
well.

On 02/08/06, Anthony <wikilegal at inbox.org> wrote:
>
> On 8/1/06, Oldak Quill <oldakquill at gmail.com> wrote:
> > On 01/08/06, mboverload <mboverload at gmail.com> wrote:
> > > What?  He asked people to vandalise the page.
> >
> >
> > No, I'm saying that Colbert has no sense of good faith. Why would he
> > just ask people to vandalise a page? Seems senseless.
>
> Colbert's entire show is based on tongue-in-cheek parody.  In fact,
> you could say the whole thing is intelligent "trolling".  It's usually
> fairly funny, as the Wikipedia segment probably was.
>
> Anyway, I'm kind of surprised he didn't mention something to Wikimedia
> warning it before broadcasting that segment.
>
> Anthony
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Steve Bennett

body:
On 8/2/06, geni <geniice at gmail.com> wrote:
> I'm not sure that is much of an fair use defence and in any case where?

I don't think there is any doubt over the legitimacy of including a
low-res scan of an album cover in an article about the album.

Steve


subject: [WikiEN-l] Colbert Report heads-up

body:
On 8/2/06, Anthony <wikilegal at inbox.org> wrote:
> Anyway, I'm kind of surprised he didn't mention something to Wikimedia
> warning it before broadcasting that segment.

Don't forget the prevailing attitude is "Wikimedia is a website where
random people write random things" - there is no understanding of a
Wikipedia community, much less a Wikimedia that oversees things.

It would be like expecting someone to warn a noticeboard before
telling your friends to stick notices all over it.

Steve


from_name: Mark Wagner

subject: [WikiEN-l] A new winner for most irrelevant trivia?

body:
On 8/2/06, Andrew Gray <shimgray at gmail.com> wrote:
>
> "Will someone rid me of this troublesome priest?"

==In popular culture==
*Five minute and seventeen seconds into episode 18 of the fifth season
of TOCFH, Jason says "Will nobody rid me of this meddlesome fool?" in
an attempt to get Alex killed.

--
Mark
[[User:Carnildo]]


subject: [WikiEN-l] Newsgroups

body:
On 8/2/06, Steve Bennett <stevagewp at gmail.com> wrote:
> On 8/2/06, Timwi <timwi at gmx.net> wrote:
> > This mailing list is in the newsgroup
> > gmane.science.linguistics.wikipedia.english (the bizarre hierarchy is
> > probably historical).
>
> Interesting. Must have a look.
>
> Not that I've ever liked usenet - typically low S/N ratio, and not
> knowing when your message will propagate to certain readers.

[[Gmane]] isn't [[Usenet]].  It's a Usenet-like interface to a whole
bunch of mailing lists.

--
Mark
[[User:Carnildo]]


from_name: Timwi

subject: [WikiEN-l] Newsgroups

body:
John Lyden wrote:
>
>>Why, praytell, are you using digests???
>
> Some people just don't LIKE volumes of mail being dumped in their inbox.

Am I really the only person in the whole world that uses the
newsgroups?... I keep seeing this false dilemma fallacy, and nobody ever
responds to it to set it straight.

Digests are the absolutely dumbest and worst imaginable way to solve the
"volumes of mail" problem.

Timwi


subject: [WikiEN-l] giving medical advice

body:
Steve Bennett wrote:
> On 7/28/06, Fred Bauder <fredbaud at ctelco.net> wrote:
>
>>>The last sentence of the lead,
>
> It actually can be spelt "lede".

I couldn't find any dictionary that agrees with this other than
Wiktionary. I am therefore inclined to suspect that someone made it up.

Timwi


from_name: Sean Barrett

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Gray stated for the record:

> On 02/08/06, Steve Bennett <stevagewp at gmail.com> wrote:
>
>>On 8/2/06, Rob <gamaliel8 at gmail.com> wrote:
>>
>>>And it doesn't even identify or link to the particular episode.  How
>>>disappointing. ;)
>>
>>Yeah! If there's one thing worse than trivia, it's unverifiable trivia! :)
>>
>>Incidentally, the whole "References in pop culture" section of that
>>article is, um, worthwhile having a look at.
>
>
> "Will someone rid me of this troublesome priest?"
>
> 01:09, 2 August 2006 The Epopt (Talk | contribs | block) (?Machu
> Picchu in pop culture - removed unsourced, unverifiable, and
> irrelevant comments)

/me bows theatrically.

- --
 Sean Barrett     | Those who cannot remember the past are
 sean at epoptic.com | condemned to learn it from Oliver Stone movies.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE0SAtMAt1wyd9d+URAqPAAJ9wuucahv2n/yikgjUM/MCRGkkleACfb3T4
w1CblUGTY6UyaA3AJvGqFQg=
=Q1m5
-----END PGP SIGNATURE-----


from_name: adam

subject: [WikiEN-l] giving medical advice

body:
Timwi wrote:
> Steve Bennett wrote:
>> On 7/28/06, Fred Bauder <fredbaud at ctelco.net> wrote:
>>
>>>> The last sentence of the lead,
>> It actually can be spelt "lede".
>
> I couldn't find any dictionary that agrees with this other than
> Wiktionary. I am therefore inclined to suspect that someone made it up.
>
> Timwi

It's in the OED as a variant used in the 14th-16th centuries.

adam


subject: [WikiEN-l] "Submit review"

body:
Erik Moeller wrote:
> How would people feel about a "Submit review" tab that is only shown
> to unregistered users, and that would result in a page showing
> [...]
>
> The reviews would be sent to a to-be-created mailing list  [...]

If we will ever have proper discussion threads to replace the archaic
and dysfunctional talk pages, these reviews would be a perfect candidate
for starting such a discussion thread.

Timwi


subject:
[WikiEN-l] OT photocruft (was Re: Technical solution to bad
	fair use)

body:
Mark Gallagher wrote:
>
>>Amusing case in point:
>>http://commons.wikimedia.org/wiki/Image:Rock_of_Cashel_inside_cathedral.jpg
>>(my image)
>>http://en.wikipedia.org/wiki/Image:Rock_of_Cashel-castle_interior.jpg
>>(existing image)
>
> Ahh, yours is quite good.  Sadly, they're too similar to both use in an
> article.

Funny you should say that. I took a photo of [[Trinity Great Court]]
some time ago (although at the time I added it to [[Trinity College,
Cambridge]] because the former article didn't exist). Then someone added
a much better photo of the same thing from the same angle. So I went
ahead and removed mine, but someone reverted me. For a long time, the
article had two similar-looking photographs right underneath each other...

Timwi


subject: [Foundation-l] Wikipedia Suggest

body:
Julien Lemoine wrote:

> Hello,
>
> I have wrote a "google suggest" like service for wikipedia under GPL
> licence [1].
> By the way, I am not sure if this project will interest you, I am open
> to all comments from your community.
>
> I wrote a simple web site for english/french on
> http://suggest.speedblue.org, all software are available in the
> download section.
>
> Best Regards.
> Julien Lemoine
>
> [1] If you want me to change the licence to something other than GPL,
> please let me know.
>
>------------------------------------------------------------------------
>
>_______________________________________________
>foundation-l mailing list
>foundation-l at wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/foundation-l
>
>
It's a start -- we also need a specialized file system for a google
replacement.

Jeff


subject: [Foundation-l] Wikipedia Suggest


body:
On 8/2/06, Steve Bennett <stevagewp at gmail.com> wrote:
> On 8/2/06, geni <geniice at gmail.com> wrote:
> > I'm not sure that is much of an fair use defence and in any case where?
>
> I don't think there is any doubt over the legitimacy of including a
> low-res scan of an album cover in an article about the album.
>
> Steve

On what basis?

--
geni


list: wikitech-l

from_name: Uwe Brauer

subject: [Wikitech-l] how to sync wikipedia on different PC

references:
<87slkgr880.fsf@riemann.quim.ucm.es> <eanotb$5do$1@sea.gmane.org>
	<loom.20060801T165544-187@post.gmane.org>
	<eanu3o$ogu$1@sea.gmane.org>

body:
>>>>> "Timwi" == Timwi  <timwi at gmx.net> writes:

   Timwi> Well, what Platonides meant is that you should use mysqldump
   Timwi> to create a dump of the database (type mysqldump --help),
   Timwi> and then on the target machine use "mysql -D wikidb <
   Timwi> dump.sql" to import it.

That worked, may thanks!!!
   Timwi> However, I don't really know why the method you chose
   Timwi> shouldn't work.

No idea.

Uwe


from_name: Stephen Bain

body:
On 8/1/06, jkelly at fas.harvard.edu <jkelly at fas.harvard.edu> wrote:
>
>   Another technical solution might be to impose terrible resolution on unfree
> images, which itself could be switched off (perhaps by bureaucrats) when there
> is a real need to (as, for instance, with the Jyllands-Posten Muhammad
> cartoons).  If the default was for unfree content to be less aesthetically
> appealing than freely-licensed content, we wouldn't have editors constantly
> replacing freely-licensed images with unfreely-licensed ones.

We can always resize fair use images to make them smaller. Most images
are displayed in articles as thmbnails no larger than 300px in width
(although images with landscape orientation are sometimes larger than
this), and I think that it would be reasonable to downsize most images
to this resolution or smaller.

Certainly anything which is in the same proportions as a standard
photo print or a computer display would not need to be any larger than
300px.

I doubt there would be any copyright implications with adjusting
images like this, if all we do is make them smaller - we're simply
using less of the copyrighted work. It would be as if we scanned or
copied the source at a lower resolution in the first place. Similarly
cropping images would be a modification with no copyright
implications. It would be important not to make any other
modifications though.

--
Stephen Bain
stephen.bain at gmail.com


subject: [WikiEN-l] Newsgroups

body:
On 8/2/06, Timwi <timwi at gmx.net> wrote:
> Am I really the only person in the whole world that uses the
> newsgroups?... I keep seeing this false dilemma fallacy, and nobody ever
> responds to it to set it straight.

Out of my sample space of you and me, yes, you are definitely the only
person not using the normal mail option to communicate with this list.

I didn't even know there was a newsgroup bridge :)

Steve


body:
On 8/2/06, Timwi <timwi at gmx.net> wrote:
> Funny you should say that. I took a photo of [[Trinity Great Court]]
> some time ago (although at the time I added it to [[Trinity College,
> Cambridge]] because the former article didn't exist). Then someone added
> a much better photo of the same thing from the same angle. So I went
> ahead and removed mine, but someone reverted me. For a long time, the
> article had two similar-looking photographs right underneath each other...

It's hard to know how similar is too similar. I tend to think that the
more images, the better, and if there are even a few more details in
one than the other, it may be worth it. Particularly in the case of an
article with very little text, you can get a surprising amount of
information just by including several photos. I don't know about "a
thousand words", but often several hundred or so.

An example fresh in my mind:
http://fr.wikipedia.org/wiki/Barrage_de_Grangent

Can you imagine this without the images? Nowhere in the text does it
describe the surrounding scenery, or help you picture the shape of it
at all. By contrast:

http://fr.wikipedia.org/wiki/Lac_de_Grangent is about the artificial
lake - no image (yet), no way of understanding anything about this
lake except in purely abstract terms.

Steve


body:
On 8/2/06, geni <geniice at gmail.com> wrote:
> On what basis?

Amongst others the fact that noone's artistic income is in jeopardy.
But this is a pretty silly conversation.

Steve


from_name: uninvited at nerstrand.net

subject: [WikiEN-l] Privacy of article subjects

body:
[[Wikipedia:Privacy_of_article_subjects]]

We get OTRS requests related to such problems and there is a lack of
consensus in the project for how to deal with them.


subject: [WikiEN-l] giving medical advice

body:
Steve Summit wrote:
> Timwi wrote:
>
>>>>>The last sentence of the lead,
>>>
>>>It actually can be spelt "lede".
>>
>>I couldn't find any dictionary that agrees with this other than
>>Wiktionary.
>
> How hard did you look?  The first three google hits are

anything but dictionaries.

Also see adam's reply :)


subject: [WikiEN-l] Newsgroups

body:
Steve Bennett wrote:
> On 8/2/06, Timwi <timwi at gmx.net> wrote:
>
>>Am I really the only person in the whole world that uses the
>>newsgroups?... I keep seeing this false dilemma fallacy, and nobody ever
>>responds to it to set it straight.
>
> Out of my sample space of you and me, yes, you are definitely the only
> person not using the normal mail option to communicate with this list.

Out of my sample space of you and me, you are definitely the only person
who doesn't use the newsgroups, and to boot, you didn't even know one
existed. :-)

If you're interested:  http://gmane.org/

This mailing list is in the newsgroup
gmane.science.linguistics.wikipedia.english (the bizarre hierarchy is
probably historical).

Timwi


subject: [WikiEN-l] Photocruft, or not

references:
<b8ceeef70608011419n27df7d65w28dcb75de12c0b83@mail.gmail.com>	<44D0013B.50801@student.canberra.edu.au>
	<eaqc12$vsg$1@sea.gmane.org>
	<b8ceeef70608020742k3f7c0665r7c3a12a00de808ca@mail.gmail.com>

body:
Steve Bennett wrote:
>
> It's hard to know how similar is too similar. I tend to think that the
> more images, the better, and if there are even a few more details in
> one than the other, it may be worth it. Particularly in the case of an
> article with very little text, you can get a surprising amount of
> information just by including several photos. I don't know about "a
> thousand words", but often several hundred or so.

I quite agree with this. Accordingly, I would endorse a movement whereby
short articles are allowed to accrue a gallery of images at the bottom
(optionally with the "show/hide" links to keep frenetic clickers happy).
Nevertheless, those images should eventually be incorporated into the
article as it grows. Remember that people primarily come to Wikipedia
for encyclopedic articles. If someone were to specifically look for
pictures, well, that's what the links to Commons are there for.

Timwi


list: wikipedia-l

subject: [Wikipedia-l] Artikel ohne Koordinate

body:
Stefan K?hn wrote:
> Hallo zusammen!
>
> Zahlreiche Artikel in der Wikipedia haben einen Raumbezug aber noch
> keine Koordinate. Andererseits kennen sich viele Benutzer in bestimmten
> Landstrichen besonders gut aus und wissen aber nicht, dass dort ein
> Artikel existiert oder die Koordinate fehlt.
>
> Deshalb hab ich mal eine Liste f?r jedes Land erstellt, die alle derzeit
> noch nicht georeferenzierten Artikel (z.B. Berge, Museen, Orte) enth?lt.
>
> http://de.wikipedia.org/wiki/Wikipedia:WikiProjekt_Georeferenzierung/Artikel_ohne_Koordinate

Ich glaube nicht, dass sich damit so leicht Freiwillige finden. Ihr habt
ja einfach nur alle Artikel nach Land aufgelistet. Ich m?sste also
hunderte von Artikel, die unter "England" aufgelistet sind, ?ffnen, um
zu gucken, welche davon in Cambridge sind. Ich glaube nicht, dass viele
Leute dazu Lust h?tten. Hinzu kommt dann noch, dass man erstmal
umst?ndlich rumsuchen muss, um rauszufinden, wie die Koordinaten in die
Artikel eingetragen werden sollen, und selbst wenn man das mal gefunden
hat, ist die Erkl?rung viel zu kompliziert und viel zu umst?ndlich.

Timwi


from_name: Simetrical

subject: [Wikitech-l] Wikipedia Suggest

body:
On 8/2/06, Steve Bennett <stevage at gmail.com> wrote:
> I would be interested to hear from the server admins on the
> feasibility of integrating this tool in Wikipedia - particularly that
> compilation time.

I strongly suspect that the number of runtime cycles this could take
is a much greater concern.  Half an hour to compile the list isn't far
from the length some special-page indices take to build, IIRC.


from_name: James Hare

body:
The latest fad in the media seems to be making fun of a non-profit
attempt at information. The people tend to have a tendency of
believing the news sources that are more popular, so it might be a
subtle attempt to put us down.

What a conspiratorial accusation.

On 8/2/06, Brad Patrick <bradp.wmf at gmail.com> wrote:
> So not one but two must-read/sees in the same news cycle...
>
> http://www.theatlantic.com/doc/200609/wikipedia
>
> by Marshall Poe
>
> and "Wikiality" on "The Word" on the Colbert Report.
>
> http://www.powerpage.org/archives/2006/08/stephen_colbert_v_wikipedia.html
>
> Did you know the number of elephants in Africa has tripled in the past 10
> years? 8-D
>
> Enjoy!
>
>
> --
> Brad Patrick
> General Counsel & Interim Executive Director
> Wikimedia Foundation, Inc.
> bradp.wmf at gmail.com
> 727-231-0101
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>


subject: [Foundation-l] Wikipedia Suggest

body:
Very nice.

James endorses.

On 8/2/06, Julien Lemoine <speedblue at happycoders.org> wrote:
> Hello,
>
> I have wrote a "google suggest" like service for wikipedia under GPL
> licence [1].
> By the way, I am not sure if this project will interest you, I am open
> to all comments from your community.
>
> I wrote a simple web site for english/french on
> http://suggest.speedblue.org, all software are available in the download
> section.
>
> Best Regards.
> Julien Lemoine
>
> [1] If you want me to change the licence to something other than GPL,
> please let me know.
>
>


subject: [Foundation-l] Wikipedia Suggest


from_name: Andrew Gray

body:
On 02/08/06, Steve Bennett <stevagewp at gmail.com> wrote:
> On 8/2/06, Rob <gamaliel8 at gmail.com> wrote:
> > And it doesn't even identify or link to the particular episode.  How
> > disappointing. ;)
>
> Yeah! If there's one thing worse than trivia, it's unverifiable trivia! :)
>
> Incidentally, the whole "References in pop culture" section of that
> article is, um, worthwhile having a look at.

"Will someone rid me of this troublesome priest?"

01:09, 2 August 2006 The Epopt (Talk | contribs | block) (?Machu
Picchu in pop culture - removed unsourced, unverifiable, and
irrelevant comments)

--
- Andrew Gray
  andrew.gray at dunelm.org.uk


body:
On 01/08/06, Steve Bennett <stevagewp at gmail.com> wrote:
> On 8/1/06, Stan Shebs <shebs at apple.com> wrote:
> > Heh, my productivity machine is botanical gardens. Photo of label,
> > whole plant, closeups of leaves/flowers, three steps to the left,
> > repeat. :-) UC Berkeley botanical garden sez they have 12,000 taxa
> > for instance, I've only racked up about 300 of them so far...
>
> Bastard! I do European castles. I don't have a car. You have any idea how
> long it takes to take those "three steps to the left"?
>
> Actually the real problem is getting to the article after visiting the
> place, and discovering that someone has already taken a (better) photo of
> it.
>
> Amusing case in point:
> http://commons.wikimedia.org/wiki/Image:Rock_of_Cashel_inside_cathedral.jpg
> (my image)
> http://en.wikipedia.org/wiki/Image:Rock_of_Cashel-castle_interior.jpg
> (existing image)

They're actually quite interesting in comparison. Most of the foliage
in your version is more grown - look at the top of the main arch - but
there are some patches where yours is denuded and the earlier one has
growth. What, if anything, that indicates I don't know, but it's
something.

There's rarely anything to be *lost* by the duplicate, though I agree
it's annoying to find you've been pre-empted. (I should go round the
Ashmolean one of these days, do all the obscure portraits of minor
nobility, little chance of duplicating effort there...)

--
- Andrew Gray
  andrew.gray at dunelm.org.uk


subject: [WikiEN-l] Photocruft, or not

references:
<b8ceeef70608011419n27df7d65w28dcb75de12c0b83@mail.gmail.com>
	<44D0013B.50801@student.canberra.edu.au> <eaqc12$vsg$1@sea.gmane.org>
	<b8ceeef70608020742k3f7c0665r7c3a12a00de808ca@mail.gmail.com>
	<eaqlp1$56h$1@sea.gmane.org>

body:
On 8/2/06, Timwi <timwi at gmx.net> wrote:
> I quite agree with this. Accordingly, I would endorse a movement whereby
> short articles are allowed to accrue a gallery of images at the bottom
> (optionally with the "show/hide" links to keep frenetic clickers happy).
> Nevertheless, those images should eventually be incorporated into the
> article as it grows. Remember that people primarily come to Wikipedia
> for encyclopedic articles. If someone were to specifically look for
> pictures, well, that's what the links to Commons are there for.

Yep. There seems to be disagreement about what happens when a long
article has too many images though (too many meaning, if they were all
laid top to bottom without overlapping, they would be longer than the
text). Some responses I've seen:
* Try and cram them in anyway :)
* Stick the "surplus" in a "gallery" section down the bottom
* Move the surplus to a separate article called "Images of X" (not a
fan of this)
* Just leave out the excess and possibly point to a category or Commons.

Steve


from_name: Julien Lemoine

subject: [Foundation-l] Wikipedia Suggest

body:
Hello,

I have wrote a "google suggest" like service for wikipedia under GPL
licence [1].
By the way, I am not sure if this project will interest you, I am open
to all comments from your community.

I wrote a simple web site for english/french on
http://suggest.speedblue.org, all software are available in the download
section.

Best Regards.
Julien Lemoine

[1] If you want me to change the licence to something other than GPL,
please let me know.


subject: [Foundation-l] Wikipedia Suggest


subject: [Wikitech-l] Wikipedia Suggest


subject: [Wikitech-l] Wikipedia Suggest

body:
On 8/2/06, Julien Lemoine <speedblue at happycoders.org> wrote:
> Hello,
>
> I have wrote a "google suggest" like service for wikipedia under GPL
> licence [1].
> By the way, I am not sure if this project will interest you, I am open
> to all comments from your community.

This is absolutely fantastic, and would greatly benefit Wikipedia if
cleaned up a little and integrated. What data is it running on?

Also, what is the number on the right side, the number of incoming
links to the page?

Again, brilliant - would make the search feature far, far more useful.

Steve


subject: [Wikitech-l] Wikipedia Suggest

body:
Hello,

Steve Bennett wrote:
> This is absolutely fantastic, and would greatly benefit Wikipedia if
> cleaned up a little and integrated. What data is it running on?
>
First of all, I grabbed the whole content of english/french wikipedia in
june 2006. Then, everything is compiled is a final state machine (about
200Mb for english wikipedia).
> Also, what is the number on the right side, the number of incoming
> links to the page?
>
>
Yes, you guessed right :)
> Again, brilliant - would make the search feature far, far more useful.
>
Thanks you.
Best Regards.
Julien Lemoine


subject: [Wikitech-l] Wikipedia Suggest

body:
On 8/2/06, Julien Lemoine <speedblue at happycoders.org> wrote:
> First of all, I grabbed the whole content of english/french wikipedia in
> june 2006. Then, everything is compiled is a final state machine (about
> 200Mb for english wikipedia).

How long does the compiling take? How close to a real-time update
could it be? This seems to be a recurring problem with search etc at
Wikipedia - the fact that it's always at best a few days out of date,
and sometimes months. Then with the problems with toolserver...

Steve


subject: [WikiEN-l] Colbert Report heads-up

body:
On 8/2/06, Anthony <wikilegal at inbox.org> wrote:
> I dunno.  I apparently was wrong that it's a standard practice anyway.
>  It would have been nice if *someone* had gotten a heads up *before*
> Colbert told the public to come vandalise the web site (even if it was
> said tongue-in-cheek).

If you look at the talk page history, we were onto it basically as
soon as it went to air, and semi-protection kicked within minutes or
so. How much warning do you need that a bunch of kids are going to
come past and moon your office window?

Steve


subject: [Wikitech-l] Wikipedia Suggest

body:
Hello Steve,

Steve Bennett wrote:
> On 8/2/06, Julien Lemoine <speedblue at happycoders.org> wrote:
>
>> First of all, I grabbed the whole content of english/french wikipedia in
>> june 2006. Then, everything is compiled is a final state machine (about
>> 200Mb for english wikipedia).
>>
>
> How long does the compiling take? How close to a real-time update
> could it be? This seems to be a recurring problem with search etc at
> Wikipedia - the fact that it's always at best a few days out of date,
> and sometimes months. Then with the problems with toolserver...
>
>
On my computer (Pentium D930, SATA HD, 1G RAM), it took about half an
hour for the 1.2M of english articles (I will give you the exact
processing time if you want). This time includes the reading of all
files on disk.

Best Regards.
Julien Lemoine


subject: [WikiEN-l] Newsgroups

body:
On 8/2/06, Timwi <timwi at gmx.net> wrote:
> This mailing list is in the newsgroup
> gmane.science.linguistics.wikipedia.english (the bizarre hierarchy is
> probably historical).

Interesting. Must have a look.

Not that I've ever liked usenet - typically low S/N ratio, and not
knowing when your message will propagate to certain readers.

Steve


subject: [Wikitech-l] Wikipedia Suggest

body:
Julien Lemoine wrote:
> Hello,
>
> Steve Bennett wrote:
>
>>This is absolutely fantastic, and would greatly benefit Wikipedia if
>>cleaned up a little and integrated. What data is it running on?
>
> First of all, I grabbed the whole content of english/french wikipedia in
> june 2006. Then, everything is compiled is a final state machine (about
> 200Mb for english wikipedia).

Can you explain in greater detail what your finite-state machine looks
like? Is it like a directed graph?

Timwi


subject: [WikiEN-l] Newsgroups

body:
Brian Salter-Duke wrote:
> On Wed, Aug 02, 2006 at 02:38:58PM +0100, Timwi wrote:
>
>>John Lyden wrote:
>>
>>>>Why, praytell, are you using digests???
>>>
>>>Some people just don't LIKE volumes of mail being dumped in their inbox.
>>
>>Am I really the only person in the whole world that uses the
>>newsgroups?... I keep seeing this false dilemma fallacy, and nobody ever
>>responds to it to set it straight.
>>
>>Digests are the absolutely dumbest and worst imaginable way to solve the
>>"volumes of mail" problem.
>
> I do not agree, but you have to use the digest sensibly. I download them
> using fetchmail with pop3. I read mail with mutt. When I see a digest, I
> hit control S and the digest message is piped through a script called
> metamutt that opens a separate mutt temporay folder with all the
> messages split out from the digest.

I don't see how that is any different from simply filtering the messages
into a folder directly. It is strictly equivalent except that it doesn't
incur the delay that the digest does, therefore it's strictly better :)

Timwi


from_name: Oldak Quill

subject: [WikiEN-l] Colbert Report heads-up

body:
On 02/08/06, Steve Bennett <stevagewp at gmail.com> wrote:
> If you look at the talk page history, we were onto it basically as
> soon as it went to air, and semi-protection kicked within minutes or
> so. How much warning do you need that a bunch of kids are going to
> come past and moon your office window?

They probably knew we'd pick up on it straight away anyway.

On 8/2/06, stevertigo <vertigosteve at yahoo.com> wrote:
> Why? Wikimedia just pays the bills - it doesnt run the show.
> Wikipedians run the show, and any Wikipedian who saw that report
> probably got up off the couch and strolled over to their computer
> just to make sure it didnt get out of hand. Wikifaith - apparently
> Colbert has some sense of it. Wikifunniness too maybe.

Perhaps the best place to have mentioned it before the episode aired
would have been the Village Pump or somesuch. I agree that notifying
Wikimedia would have been unnecessary.
--
Oldak Quill (oldakquill at gmail.com)


subject: [Wikitech-l] Wikipedia Suggest

body:
On 8/2/06, Julien Lemoine <speedblue at happycoders.org> wrote:
> On my computer (Pentium D930, SATA HD, 1G RAM), it took about half an
> hour for the 1.2M of english articles (I will give you the exact
> processing time if you want). This time includes the reading of all
> files on disk.

I would be interested to hear from the server admins on the
feasibility of integrating this tool in Wikipedia - particularly that
compilation time.

Steve


subject: [WikiEN-l] Newsgroups

body:
On 02/08/06, Brian Salter-Duke <b_duke at bigpond.net.au> wrote:
> I do not agree, but you have to use the digest sensibly. I download them
> using fetchmail with pop3. I read mail with mutt. When I see a digest, I
> hit control S and the digest message is piped through a script called
> metamutt that opens a separate mutt temporay folder with all the
> messages split out from the digest. I can then skip through these, exit
> back the main folder and delete the digest. If I want to keep a message
> I just save it from the temp folder to a main folder. Download is
> easier and reading them is clearer. I almost always subscribe to lists
> via the digest mode. The only negatives is the delay in getting messages
> and a bug that means I have to save a message to a main folder before
> replying.
>
> Brian

I find that the Gmail interface, and the way it works, is great for
mailing lists. Conversations are sensibly stacked making things very
easy to read. Labels are easily added to conversations and archiving
gets everything out of the way.

Plus, you can search the whole collection.
--
Oldak Quill (oldakquill at gmail.com)


from_name: brion at pobox.com

subject: [Wikitech-l] MediaWiki automated test run failure 2006-08-03

body:
An automated run of parserTests.php showed the following failures:

Running test Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED!
Running test Link containing double-single-quotes '' (bug 4598)... FAILED!
Running test Magic Word: {{CURRENTMONTHNAMEGEN}}... FAILED!
Running test Template with thumb image (wiht link in description)... FAILED!
Running test message transform: <noinclude> in transcluded template (bug 4926)... FAILED!
Running test message transform: <onlyinclude> in transcluded template (bug 4926)... FAILED!
Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED!
Running test HTML bullet list, unclosed tags (bug 5497)... FAILED!
Running test HTML ordered list, unclosed tags (bug 5497)... FAILED!
Running test HTML nested bullet list, open tags (bug 5497)... FAILED!
Running test HTML nested ordered list, open tags (bug 5497)... FAILED!
Running test Parsing optional HTML elements (Bug 6171)... FAILED!
Running test Inline HTML vs wiki block nesting... FAILED!
Running test Mixing markup for italics and bold... FAILED!
Running test 5 quotes, code coverage +1 line... FAILED!
Running test HTML Hex character encoding.... FAILED!
Running test dt/dd/dl test... FAILED!

Passed 412 of 429 tests (96.04%) FAILED!


from_name: Oskar Sigvardsson

subject: [WikiEN-l] Colbert Report heads-up

body:
On 8/2/06, Anthony <wikilegal at inbox.org> wrote:
> On 8/1/06, Oldak Quill <oldakquill at gmail.com> wrote:
> > On 01/08/06, mboverload <mboverload at gmail.com> wrote:
> > > What?  He asked people to vandalise the page.
> >
> >
> > No, I'm saying that Colbert has no sense of good faith. Why would he
> > just ask people to vandalise a page? Seems senseless.
>
> Colbert's entire show is based on tongue-in-cheek parody.  In fact,
> you could say the whole thing is intelligent "trolling".  It's usually
> fairly funny, as the Wikipedia segment probably was.

That's the first time I ever heard intelligent satire referred to as
intelligent trolling. Jonathan Swift is turning over in his grave
somewhere :P


from_name: Matt Brown

subject: [WikiEN-l] Technical solution to bad fair use

body:
On 8/3/06, geni <geniice at gmail.com> wrote:
> I showed that in most cases the album cover art is not mentioned in
> the text.

The album cover art is part of the whole package, IMO; it's thus valid
to show it as a visual depiction even if it's not explicitly mentioned
by itself.

> It is quite posible to buy an album without knowing what it
> looks like.

It is indeed, but it's not easier.

Besides, there's a long history (pre Wikipedia, heck pre internet) of
album cover art being usable as fair use when writing about albums.

-Matt


from_name: 田中 万太郎

subject: [Wikitech-l] LIVE MIRRORS: still more

body:
Hello,

I found these two live mirrors:

http://en.32of100e.info/Special:Recentchanges
http://en.45of100b.info/arbor-gates/Special:Recentchanges

Please block, thankyou!

TANAKA

--------------------------------------
Let's start Yahoo! Auction  -  Free Campaign Now!
http://pr.mail.yahoo.co.jp/auction/


subject: [Wikitech-l] Wikipedia Suggest

body:
Hello,

Simetrical wrote:
> On 8/2/06, Steve Bennett <stevage at gmail.com> wrote:
>
>> I would be interested to hear from the server admins on the
>> feasibility of integrating this tool in Wikipedia - particularly that
>> compilation time.
>>
>
> I strongly suspect that the number of runtime cycles this could take
> is a much greater concern.  Half an hour to compile the list isn't far
> from the length some special-page indices take to build, IIRC.
>
Here is the time output of compiler for the analysis of wikipedia
english articles :
622,65s user 53,69s system 70% cpu 15:58,91 total
95% of this time (16mins) was to read the files from disk (with a fresh
reboot so nothing was in the cache).

The algorithm uses very few cpu power. Imagine for example that all the
data needed are in memory, the compiled automaton could be obtained in 1
minutes.

Best Regards.
Julien Lemoine


subject: [Wikitech-l] Wikipedia Suggest

body:
Hello,

Timwi wrote:
> Can you explain in greater detail what your finite-state machine looks
> like? Is it like a directed graph?
>
>
Yes this is a directed graph, each transition from one node to another
is labeled by one UTF-8 character.
This graph is deterministic, you can not have two identic transitions at
the output of a node.
For each article I added the name of the article in this automaton, with
the final node containing a pointer to articles details (url, name, nb
of links).
After article names were added in automaton, I computed the table of
best content for each node containing pointer to articles with the
higher number of links.

I talked about pointers, these pointers are index to a vector storing
all details about articles.

You can have a small example (figure) in my FAQ :
http://suggest.speedblue.org/FAQ.php

I can give you more details about number of nodes/transitions in the
automaton if you want.
I hope this give you a more precise idea of how it works.

Please, don't hesitate to ask me more details.
Best Regards.
Julien Lemoine


from_name: Brian Salter-Duke

subject: [WikiEN-l] Newsgroups

body:
On Wed, Aug 02, 2006 at 02:38:58PM +0100, Timwi wrote:
> John Lyden wrote:
> >
> >>Why, praytell, are you using digests???
> >
> >Some people just don't LIKE volumes of mail being dumped in their inbox.
>
> Am I really the only person in the whole world that uses the
> newsgroups?... I keep seeing this false dilemma fallacy, and nobody ever
> responds to it to set it straight.
>
> Digests are the absolutely dumbest and worst imaginable way to solve the
> "volumes of mail" problem.

I do not agree, but you have to use the digest sensibly. I download them
using fetchmail with pop3. I read mail with mutt. When I see a digest, I
hit control S and the digest message is piped through a script called
metamutt that opens a separate mutt temporay folder with all the
messages split out from the digest. I can then skip through these, exit
back the main folder and delete the digest. If I want to keep a message
I just save it from the temp folder to a main folder. Download is
easier and reading them is clearer. I almost always subscribe to lists
via the digest mode. The only negatives is the delay in getting messages
and a bug that means I have to save a message to a main folder before
replying.

Brian

> Timwi
>
--
          Brian Salter-Duke            b_duke at bigpond.net.au
               [[User:Bduke]]  mainly on en:Wikipedia.
 Also on fr: Wikipedia, Meta-Wiki, WikiNews, WikiBooks and Commons


subject: [Wikitech-l] Wikipedia Suggest

body:
Hi Nick,

* Nick Jenkins <nickpj at gmail.com> [2006-08-03 16:16:23 +1000]:

> == UI stuff ==
>
> The only two constructive suggestions for the User-Interface that I
> would make are:
>
> 1) That if the user presses 'Enter' in the search textbox whilst
> typing out a query, that it automatically choose/open/redirect to the
> first item in the list. That way I can type out what I want, and press
> enter to open the first link when I've typed enough to specify it well
> enough to get it to the top of the list, all without using the mouse.
>
> 2) Allow the user to press the down/up arrows to select/highlight a
> specified entry on the list (including but not limited to the first
> item), and press enter to open it. That way again the user can be lazy
> and can select a link without using the mouse, and without typing out
> the full title.

You idea are goods, I added them on my TODO list :)

> == More Technical stuff ==
>
> 1) How do you handle pages with the same title, but different
> capitalization? They're rare, but they do occur. My suspicion from
> scanning Analyzer.cpp is that you just take the most popular. However,
> if it's for search, it would be best to include everything (I think).

Yeah you are right, the most popular is keept. I wanted to have a case
insensitive search and for the moment I have only one article by final
node. But it will be better, I also added it to my TODO list.

> 2) Doesn't seem to get include redirects. For example, when I search
> for "Formula weight", it's not listed, but on the EN Wikipedia
> "Formula weight" is a redirect to "Atomic mass". It would definitely
> be better to include redirects (in my personal opinion).

I will generates a new index with redirects, I will give you the size
before/after this evening.

> However the downside of including these two things is that the amount
> of data that you need to store goes up. I've actually had a go at a
> very similar problem (storing a memory index of all article names, but
> meeting the two conditions specified above, plus for redirects I would
> also store the name of the article it redirected to [something which
> could potentially maybe also be useful for your suggest service if you
> wanted to show this information too]). However this was in PHP, and it
> a complete memory hog (think > 1 Gb for the memory index). My solution
> (since it was only for me) was to just "buy more RAM", however I like
> your approach of getting more efficient. By the way, the reason I was
> doing this was for suggesting links that could be made in wiki text -
> just so you know I'm not in competition with you, but that the
> problems we face are similar in some ways, and could maybe benefit
> from a common solution.
> How big would be a memory index be that had these properties (i.e.
> including all NS:0 articles/redirects, and maybe including the targets
> for redirects)?

The current automaton (index) of all wikipedia articles (without
redirects) needs 127Mb, I don't think adding redirects will increass a lot his
size. I will give you the exact size with redirect this evening :)
(Paris time).

Best Regards.
Julien Lemoine


from_name: Steve Bennett

subject: [Wikitech-l] Wikipedia Suggest

body:
On 8/3/06, Julien Lemoine <speedblue at happycoders.org> wrote:
> > 1) How do you handle pages with the same title, but different
> > capitalization? They're rare, but they do occur. My suspicion from
> > scanning Analyzer.cpp is that you just take the most popular. However,
> > if it's for search, it would be best to include everything (I think).
>
> Yeah you are right, the most popular is keept. I wanted to have a case
> insensitive search and for the moment I have only one article by final
> node. But it will be better, I also added it to my TODO list.

I didn't notice this - yes, a case-sensitive search is critical.
Problems with casing are one of the most likely reasons a user will
fail to find a given page. MediaWiki automatically finds the three
most common casing options - all lower, ALL CAPS, Title Caps - but
misses the likely "Caps of Important Words".

> I will generates a new index with redirects, I will give you the size
> before/after this evening.

Redirects should be indicated with what they redirect to, like:

...
Top-rope climbing -> top roping
Top roping
...

Or something - but maybe with the proviso that it doesn't show a
redirect if the actual target is currently being displayed.

Steve


from_name: Cheney Shill

subject: [WikiEN-l] Colbert Report heads-up

body:
Oldak Quill <oldakquill at gmail.com> wrote: On 03/08/06, geni  wrote:
> Depends on the joke. We have no problem with humor per se see the last line of:
>
> http://en.wikipedia.org/wiki/2038_problem

Haha, very good. No, I don't think we have a problem with humour
either - the suggestion about blocking Wikimedia until the storm is
over seemed to lack a sense of humour. If most people find a joke
funny and our reaction to it makes us seem self-righteous and
indignant then we have lost a sense of humour.

I was temporarily blocked for trying to add wikiality on wiktionary.  It already shows 189,000 results on Google and 5 news results, including:
http://en.wikipedia.org/wiki/The_Colbert_Report

Pro-Lick on Wikipedia
Halliburton Shill on Wiktionary

---------------------------------
Groups are talking. We´re listening. Check out the handy changes to Yahoo! Groups.


subject: [Wikitech-l] Wikipedia Suggest

body:
Just a thought - if you want to *really* impress everyone, incorporate
special handling for disambiguation pages. This could be tricky, but
one of these two methods might work, for given search string
"Friends":

First, check if "Friends (disambiguation)" exists

1) If it does, simply display it in a panel to the right and let users
click on links in it

2) If it does, load it and attempt to parse it, showing the links in
the list, differentiated somehow.

On second thoughts, 1) is probably better, as you really need the line
of disambiguating text to know whether you want the 1971 film or the
2001 film, or even "Friend (film)". What to do about entries like the
last two (no real link, just synonyms) is tricky...

Steve


from_name: Fastfission

body:
On 8/1/06, Steve Bennett <stevagewp at gmail.com> wrote:
> How much value does a photo being "free" really add to any given
> encyclopaedic article? Is this policy about promoting "free" images
> not at odds with other policies which are all about producing a high
> quality encyclopaedia? What happens when the goal to produce a "high
> quality" encyclopaedia is at odds with the goal to produce a "free"
> encyclopaedia?

The value is project-wide, not necessarily on an article-by-article
basis. And I think Jimbo would say that a high quality encyclopedia is
never at odds with producing a free one. Wikipedia could still be high
quality even if it lacked fair use images. Most encyclopedias do *not*
have an image for every article and do not feel the need to, much less
images of lesser known celebrities and video games.

Also, I think the more free and good looking images Wikipedia has, the
more impressive and useful it is. Wikipedia is currently the only site
I know of on the 'net where you can get high-quality vector images
illustrating a wide-variety of things (parts of cars, household items,
hydrogen bombs).

Ugly free images can also inspire better free images. I have many
times replaced well-intentioned but amateurish free images with
re-done, more professional looking free versions. If everything is a
slick un-free image, though, the obviousness of what should be
replaced goes down a bit.

FF


body:
On 8/1/06, Stan Shebs <shebs at apple.com> wrote:
> >Unfortunately this is common on some articles, especially the pop
> >culture stuff.  In some articles the lead pic is different every week
> >with fans switching it out for their new favorite, in others I've seen
> >clear public domain pics replaced with fuzzy screenshots.
> >
> I suppose if I were a more dutiful Wikipedian, I'd go take pictures
> of all the celebrities passing through Vegas, but truthfully,
> vegetables still seem more interesting! :-)

There are enough celebrity photographers in Los Angeles to last a
lifetime of free images if we could set up a rapport with them to
release some of their less-likely-to-be-commercially-viable images
under free licenses. Free exposure and circulation for them, free
images for us. I don't see how they'd have anything to lose (and it is
not as if the places they would sell their photos to regularly are
going to suddenly want to re-license their whole magazine as CC-BY-SA
either, so the odds of it even competing with their regular business
is pretty low).

It'd be great if we could do some sort of photo drive. I have a
feeling there are lots of photographers out there who wouldn't mind
releasing a few of their pics to WP under a CC-BY-SA license if we
could just put the question to them directly.

FF


from_name: Gregory Szorc

subject: [Wikitech-l] Extension Installer

body:
On 8/3/06, Daniel Kinzler <daniel at brightbyte.de> wrote:
>
> > Brion Vibber wrote
> > Daniel Kinzler wrote:
> >
> >> Basically, it fetches the files, places them in the extension dir, and
> >> optionally patches LocalSettings.php (if the user chooses that option
> >> and the extension provides an install.settings patch file). The
> >> CategoryTree extension has such a file, if you want to try the patching
> >> feature.
> >
> > I really, really don't like that. An improved extension system should
> simply
> > have autodiscovery of dropped-in directories and a simpler way to enable
> things.
>
> I agree in principle, but don't see a way to do this without changing
> all existing extensions and/or causing some inconvenience when upgrading
> an existing install to the new system. Here some points that should be
> considered:
>
> * we'd need a way to know which file in the extension's dir should be
> included on every page request. This could be done by a naming
> convention, as with skins - but that would mean changing many extensions.
>
> * there would have to be a separate directory for "auto-load"
> extensions, or a file listing the extensions to load. The ability to add
> something there would be just as dangerous as patching LocalSettings.
>
> * Extensions may use configuration variables. Would they go into
> LocalSettings, or into separate files? The former would require patching
> again (or worse, manually inserting them), the latter seems hard to
> maintain.
>
> * Some extensions may need to "patch" the database on install. That
> would be hard to do with a "drop in" scheme. While this issue isn't
> addressed by my installer either, it could easily be added there.
>
> > An installer should not be necessary, IMHO, as it would be useless for
> the
> > primary target audience of simplified extension installation -- people
> with
> > limited hosting accounts.
>
> Right now, it's pretty hard for people to even *get* an extension, since
> they are only available from SVN (correct me if I'm wrong there). Even
> if we had bundles somewhere, I think it's much easer to say "php
> installExtension.php Foo" than to manually download, extract, and hook
> up an extension.
>
> Internally, the installer provides a set of classes for dealing with
> repositories and resources, and for hooking up the extension. This could
> easily be used by a web based installation process (maybe as part of the
> original installation) - which would be what people without shell access
> would probably want. This would of course require a lot of precautions
> to avoid opening a huge attack vector. This is the case for any web
> based installation process, no matter if it patches LocalSettings or not.
>
> So:
> * if we don't want an installer, how can the installation of more
> complex extension (e.g. requiring db patches) be made simple for the user?
> * how would we migrate existing installations and extensions to a "drop
> in" scheme?
> * if there's going to be a web based installer, how can it be made secure?
>
> My current implementation is meant as a proof of concept, especially of
> a system to list available extensions and fetch them from a repository.
> I hope this can be reused regardless of how extensions are hooked up in
> the future. As it is, it makes life easier for people with shell access,
> and work with the extensions we have now.
>
> -- Daniel

Look at how Drupal manages modules.  You simply drop modules into the
modules directory, go to the admin interface to activate, and you are done.
The latest version of Drupal even supports modules automatically creating
database tables.  One of the many benefits to having an abstract extension
class.

abstract class MediaWikiExtension {
  public function installTables(&$dbConnection) { }
  public function installHooks(&$wgHooks) { }
  public function providesParserHook() { return false; }
  ...
}

I also made an extension auto-loader as part of Farmer (
http://www.mediawiki.org/wiki/User:IndyGreg/Farmer).  It is more-or-less
just a hack.  However, that is the best we can do until the extensions
system is more formalized.

Greg


body:
On 8/3/06, geni <geniice at gmail.com> wrote:
> I showed that in most cases the album cover art is not mentioned in
> the text. It is quite posible to buy an album without knowing what it
> looks like.

That's true, and I agree that most of them are really NOT strictly
necessary from an informational point of view. However I think things
like album covers are one of our safest categories from a legal point
of view, both for us and for re-users, since they are not competing
with any market and are most likely to be considered transformative.

All of the "media covers" we have are pretty safe in my mind; I wish
people would spend more time on the more ambiguous categories of fair
use, the ones with real potential for difficulties (i.e. the thousands
of unattributed celebrity photographs and things labeled as "publicity
photos", half of which are scans from magazines and the like).

FF


from_name: geni

body:
On 8/3/06, Alphax (Wikipedia email) <alphasigmax at gmail.com> wrote:
> geni wrote:
> > On 8/2/06, Steve Bennett <stevagewp at gmail.com> wrote:
> >> On 8/2/06, geni <geniice at gmail.com> wrote:
> >>> I'm not sure that is much of an fair use defence and in any case where?
> >> I don't think there is any doubt over the legitimacy of including a
> >> low-res scan of an album cover in an article about the album.
> >>
> >> Steve
> >
> > On what basis?
> >
>
> For educational, criticism and critiquing purposes; we're educating
> readers about what the album looks like if they want to go to their
> local music store and buy it :)
>

I showed that in most cases the album cover art is not mentioned in
the text. It is quite posible to buy an album without knowing what it
looks like.

--
geni


subject: [WikiEN-l] Fair use status of animated screencaps

body:
On 7/29/06, Oldak Quill <oldakquill at gmail.com> wrote:
> I think this depends upon whether moving images (videos clips) are
> available under fair use. Does anyone know the specifics?

They should only be used where the animation is absolutely required
for the purposes of the article. If every frame of the animation (or a
high number of them) is necessary for the article, then it probably
makes sense to just have the animation rather than have 7 fair use
screen shots.

I don't think we have a special category for animated fair use; it is
probably best that we don't, since they really should be rare
exceptions.

The one place where this is often violated is in little animated GIFs
of video game characters. I'm not sure that's a big issue, though.

FF


from_name: Philip Welch

subject: [WikiEN-l] Colbert Report heads-up

body:
On Aug 3, 2006, at 6:14 AM, Steve Bennett wrote:

>> People who follow such a call are often not very patient. We could
>> have
>> proected the whole site until the idiot-storm is over. With a big
>> banner
>> saying so.
>
> That kind of reaction seems like going the wrong way. At the end of
> the day, Wikipedia wants to be open, and it wants to grow and develop.
> We should look at these "idiot storms" as opportunities to attract new
> contributors. It would be cool if we could replace the {{test}}
> template with something like "Hey, thanks for the test - we've undone
> it now, use the sandbox if you need to test anything else. You
> wouldn't happen to know anything about <insert item from requests for
> expansion> or <another item> would you? We're short on information on
> them!"

Great. Invite more vandalism.

--
Philip L. Welch
http://en.wikipedia.org/wiki/User:Philwelch


from_name: Daniel Kinzler

subject: [Wikitech-l] Extension Installer

body:
> Brion Vibber wrote
> Daniel Kinzler wrote:
>
>> Basically, it fetches the files, places them in the extension dir, and
>> optionally patches LocalSettings.php (if the user chooses that option
>> and the extension provides an install.settings patch file). The
>> CategoryTree extension has such a file, if you want to try the patching
>> feature.
>
> I really, really don't like that. An improved extension system should simply
> have autodiscovery of dropped-in directories and a simpler way to enable things.

I agree in principle, but don't see a way to do this without changing
all existing extensions and/or causing some inconvenience when upgrading
an existing install to the new system. Here some points that should be
considered:

* we'd need a way to know which file in the extension's dir should be
included on every page request. This could be done by a naming
convention, as with skins - but that would mean changing many extensions.

* there would have to be a separate directory for "auto-load"
extensions, or a file listing the extensions to load. The ability to add
something there would be just as dangerous as patching LocalSettings.

* Extensions may use configuration variables. Would they go into
LocalSettings, or into separate files? The former would require patching
again (or worse, manually inserting them), the latter seems hard to
maintain.

* Some extensions may need to "patch" the database on install. That
would be hard to do with a "drop in" scheme. While this issue isn't
addressed by my installer either, it could easily be added there.

> An installer should not be necessary, IMHO, as it would be useless for the
> primary target audience of simplified extension installation -- people with
> limited hosting accounts.

Right now, it's pretty hard for people to even *get* an extension, since
they are only available from SVN (correct me if I'm wrong there). Even
if we had bundles somewhere, I think it's much easer to say "php
installExtension.php Foo" than to manually download, extract, and hook
up an extension.

Internally, the installer provides a set of classes for dealing with
repositories and resources, and for hooking up the extension. This could
easily be used by a web based installation process (maybe as part of the
original installation) - which would be what people without shell access
would probably want. This would of course require a lot of precautions
to avoid opening a huge attack vector. This is the case for any web
based installation process, no matter if it patches LocalSettings or not.

So:
* if we don't want an installer, how can the installation of more
complex extension (e.g. requiring db patches) be made simple for the user?
* how would we migrate existing installations and extensions to a "drop
in" scheme?
* if there's going to be a web based installer, how can it be made secure?

My current implementation is meant as a proof of concept, especially of
a system to list available extensions and fetch them from a repository.
I hope this can be reused regardless of how extensions are hooked up in
the future. As it is, it makes life easier for people with shell access,
and work with the extensions we have now.

-- Daniel


subject: [WikiEN-l] Colbert Report heads-up

body:
Anthony <wikilegal at inbox.org> wrote:The only real difference between satire and trolling is whether or not
you get the joke!  Of course the word "trolling" has basically become
meaningless at this point.  People use the term for basically anything
and everything.

Anthony
_______________________________________________

No, trolling is to illicit a response, preferably an extended, irate one.  Satire, as you may be aware, has a long history in non-interactive media, such as books.

If wikiality hasn't disrupted it, I'm sure wikipedia's entry for each can help you better understand both and their distinctions.

---------------------------------
Yahoo! Music Unlimited - Access over 1 million songs.Try it free.


from_name: Johannes Ernst

subject: [Wikitech-l] Daily Usage Stats?

body:
The Daily Usage statistics are empty in
     http://stats.wikimedia.org/EN/TablesWikipediaZZ.htm
(first table, last column on page)

Where should I look to find them?

What I'm really looking for is insights on the relationship between
load and servers, e.g. how many concurrent sessions per server, page
views per time and server etc.

Thanks,

Johannes.


subject: [WikiEN-l] Colbert Report heads-up

body:
On 02/08/06, Will <sceptre at tintower.co.uk> wrote:
> We've been getting elephant population requests ~5 times a day at WP:AFC as
> well.

Well, that's five fewer to delete in one way or another...

--
- Andrew Gray
  andrew.gray at dunelm.org.uk


from_name: Anthony

subject: [WikiEN-l] Colbert Report heads-up

body:
On 8/2/06, Oskar Sigvardsson <oskarsigvardsson at gmail.com> wrote:
> On 8/2/06, Anthony <wikilegal at inbox.org> wrote:
> > Colbert's entire show is based on tongue-in-cheek parody.  In fact,
> > you could say the whole thing is intelligent "trolling".  It's usually
> > fairly funny, as the Wikipedia segment probably was.
>
> That's the first time I ever heard intelligent satire referred to as
> intelligent trolling. Jonathan Swift is turning over in his grave
> somewhere :P

The only real difference between satire and trolling is whether or not
you get the joke!  Of course the word "trolling" has basically become
meaningless at this point.  People use the term for basically anything
and everything.

Anthony


from_name: Jeff V. Merkey

subject: [Foundation-l] Wikipedia Suggest

body:
Frederic wrote:

>Guten Tag Jeff V. Merkey,
>
>am Mittwoch, 2. August 2006 um 23:28 schrieben Sie:
>
>JVM> Julien Lemoine wrote:
>
>
>
>>>Hello,
>>>
>>>I have wrote a "google suggest" like service for wikipedia under GPL
>>>licence [1].
>>>By the way, I am not sure if this project will interest you, I am open
>>>to all comments from your community.
>>>
>>>I wrote a simple web site for english/french on
>>>http://suggest.speedblue.org, all software are available in the
>>>download section.
>>>
>>>Best Regards.
>>>Julien Lemoine
>>>
>>>[1] If you want me to change the licence to something other than GPL,
>>>please let me know.
>>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>foundation-l mailing list
>>>foundation-l at wikimedia.org
>>>http://mail.wikipedia.org/mailman/listinfo/foundation-l
>>>
>>>
>>>
>>>
>JVM> It's a start -- we also need a specialized file system for a google
>JVM> replacement.
>
>JVM> Jeff
>JVM> _______________________________________________
>JVM> foundation-l mailing list
>JVM> foundation-l at wikimedia.org
>JVM> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>
>I don't understand what the discussion is all about. Plse Explain.
>
>
>
Was hast du gemacht!   :-)

The search engine wiki is a great idea.  I am willing to develop an
enhnaced replica of Googles File System archtiecture to run beneath it
for this project.
We will need developers on the php side to define a set of interaction
rules to speed searches.

I would like to work out some set of agreements on the underlying
technology to ensure it is controlled by the community.  Open Sourcing
it is not
out of the question, but I would like to get some sort of consensus on
how we develop it and keep it under the control of the Foundation and
Wikipedia Community initially.  I would propose we develop it as a
project jointly owned by the Foundation and the contributors to the
project on
a concensus basis on who gets to use it and how as part of the licensing
terms.  No such public license has ever been created, but we should
attempt to do so.  This will ensure we have control over who uses it and
for what purpose based on community concessus.  i.e.  the work should be
jointly owned by the
creators as a "shared copyright".  Using it should be free -- owning it
should be a community based position.

We need the following:

Clustered file system for massive search engine capabilities
distributed content crawlers to harvest the internet by scraping (we can
start by scraping google and yahoo -- Wales already figured a lot
of this out with DMOZ.  He would be a big help here.
Distributed Search capability.

I'm in for the file system and underlying hardware platforms and
hardware support, including SAN based and distributed models.  We should
not open source the code, but develop a community licensing scheme for
the technology.  This way we can build a revenue model around hardware
and platform sales and certain classes of subscription services (not for
the content itself but for services like "I want to link our educational
organizations cluster of services to your central hub for automated
image and content updates, translation services, and service and support
and would like to compensate the foundation for these added services
which are above and beyond simply public access to the information
itself,  which is free).   I can see us creating all
sort of jobs for folks helping with content management, translation,
publishing textbooks and selling hard copy books for education, etc.)  Stuff
that keeps the information free, but lets the Foundation have a viable
revenue model to pay for everyones expenses and help give folks a stake
to build something that will endure 100 years from now.  Sort of like
combining the power of Google and Amazon together.

That's what I'm thinking.

Jus!

Jeff


subject: [Foundation-l] Wikipedia Suggest


subject: [WikiEN-l] Colbert Report heads-up

body:
--- Guy Chapman aka JzG <guy.chapman at spamcop.net> wrote:

> On Thu, 3 Aug 2006 11:35:03 -0700 (PDT), Cheney Shill
> <halliburton_shill at yahoo.com> wrote:
>
> >trolling is to illicit a response
>
> I think you mean elicit.
>
> Oh, wait, you were trolling, weren't you?

Technically, I was writing an effective lede to inseminate
the sede that trolling is illegal in the public
consciousness.  I recall rede'n that somewhere in
Wikipedia.

http://shilllicker.blogspot.com
http://en.wiktionary.org/wiki/User:Halliburton_Shill

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


from_name: Brion Vibber

subject: [Wikitech-l] Extension Installer

body:
Daniel Kinzler wrote:
>> Brion Vibber wrote
>> I really, really don't like that. An improved extension system should simply
>> have autodiscovery of dropped-in directories and a simpler way to enable things.
>
> I agree in principle, but don't see a way to do this without changing
> all existing extensions and/or causing some inconvenience when upgrading
> an existing install to the new system. Here some points that should be
> considered:

I don't understand what you mean by this. Existing extensions if not changed
will continue to work the same way. Extensions which add the metadata file for
automatic detection will be automatically detected.

> * we'd need a way to know which file in the extension's dir should be
> included on every page request. This could be done by a naming
> convention, as with skins - but that would mean changing many extensions.

Well, so what? You'd need to change every extension to support your installer,
too! If you have to do it anyway, what's different?

> * there would have to be a separate directory for "auto-load"
> extensions,

No there wouldn't.

> or a file listing the extensions to load.

Naturally. Oddly enough, your installer requires the same.

> The ability to add
> something there would be just as dangerous as patching LocalSettings.

Why is that so? The site operator still would have to enable any extension. How
is automatically pulling a list dangerous in this way?

> * Extensions may use configuration variables. Would they go into
> LocalSettings, or into separate files? The former would require patching
> again (or worse, manually inserting them), the latter seems hard to
> maintain.

What patching? When you *choose to set* configuration values, then you edit.
That hasn't changed.

> * Some extensions may need to "patch" the database on install. That
> would be hard to do with a "drop in" scheme. While this issue isn't
> addressed by my installer either, it could easily be added there.

Why so? The updater scripts should have a simple hook for this. If it's not
already there, add it. (I've recommended that Evan add this for his OpenID
extension.)

> Right now, it's pretty hard for people to even *get* an extension, since
> they are only available from SVN (correct me if I'm wrong there).

They're available from whereever they're available from. Some are available in
our SVN. Some are available from the web sites of the authors. Some are
custom-written and kept locally.

An extension can come from *anywhere*.

> Even
> if we had bundles somewhere, I think it's much easer to say "php
> installExtension.php Foo" than to manually download, extract, and hook
> up an extension.

I disagree completely. That is literally *IMPOSSIBLE* for those with no
command-line access, whereas dropping in a directory by FTP is insanely easy.

Literally zero setup. What's easier? Nothing.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20060803/0e0786a4/attachment.pgp>


body:
On 8/2/06, Andrew Gray <shimgray at gmail.com> wrote:
> They're actually quite interesting in comparison. Most of the foliage
> in your version is more grown - look at the top of the main arch - but
> there are some patches where yours is denuded and the earlier one has
> growth. What, if anything, that indicates I don't know, but it's
> something.

Yeah I was looking at that, trying to decide "what it all means". Was
the foliage in the previous version artificially pruned? Are we seeing
the same foliage, or is this an annual growth? etc.

So, there's some benefit in multiple photos of the same thing over
differet years :)

Haven't yet made up my mind if I like captioning photos "July 2006" or
whatever in the article itself.

Steve


subject: [WikiEN-l] Newsgroups

body:
On 8/3/06, Oldak Quill <oldakquill at gmail.com> wrote:
> I find that the Gmail interface, and the way it works, is great for
> mailing lists. Conversations are sensibly stacked making things very
> easy to read. Labels are easily added to conversations and archiving
> gets everything out of the way.
>
> Plus, you can search the whole collection.

The worst thing is you can only see 20 messages at a time when
searching. Trying to perform some operation on every message
satisfying some criteria is a pain in the arse.

I use the Gmail interface exclusively, and general, yeah it works well
(particularly like its way of detecting "quoted text"), but I find
that once messages have scrolled out of the active view they're very
difficult to find again. Unlike a normal mail program, where scrolling
down is trivial.

YMMV.

Steve


subject: [WikiEN-l] Colbert Report heads-up

body:
On 8/2/06, Will <sceptre at tintower.co.uk> wrote:
> We've been getting elephant population requests ~5 times a day at WP:AFC as
> well.

I repeat: I am *so* glad he made his vandalism request specific. Can
you imagine if people just started turning up making outlandish but
mildly plausible claims? There's no way we'd zap *all* fo them.

Steve


from_name: Oldak Quill

subject: [WikiEN-l] Colbert Report heads-up

body:
On 03/08/06, Steve Bennett <stevagewp at gmail.com> wrote:
> On 8/3/06, Magnus Manske <magnus.manske at web.de> wrote:
> > People who follow such a call are often not very patient. We could have
> > proected the whole site until the idiot-storm is over. With a big banner
> > saying so.
>
> That kind of reaction seems like going the wrong way. At the end of
> the day, Wikipedia wants to be open, and it wants to grow and develop.

Not to mention that it would show a po-faced lack of sense of humour.
I always feel that an organisation has become too large when they
react terribly to jokes.

> We should look at these "idiot storms" as opportunities to attract new
> contributors. It would be cool if we could replace the {{test}}
> template with something like "Hey, thanks for the test - we've undone
> it now, use the sandbox if you need to test anything else. You
> wouldn't happen to know anything about <insert item from requests for
> expansion> or <another item> would you? We're short on information on
> them!"
>
> You know, obsequiously assuming good faith even when presented with
> evidence to the contrary can have an amazing effect on basically
> good-hearted people.

I agree, although we don't have to wait for concensus to change
{{test}}. A better solution would be to just make an alternate
template (perhaps in the userspace). Hopefully this template will
become popular through its use and effects.
--
Oldak Quill (oldakquill at gmail.com)


from_name: Marco Chiesa

subject: [Wikipedia-l] Wikimedia Italia AGM

body:
The AGM of Wikimedia Italia, the Italian chapter of the WMF, is called
for Saturday 2nd September in Valentano (VT), Italy.

The agenda will likely be:
1. approval of the Meeting's Rules
2. Ratification of the decisions of the Directors' Board
3. Renewal of committee positions
4. Approval of 2005-2006 Financial Statement
5. Approval of 2006-2007 Provisional Statement
6. Planning of events and commitments of the Association
7. Wikimania 2007
8. Any other businesses

A few remainders:
* only members can vote, but everyone can take part at the AGM
* Frieda will soon email all the members explaining how to candidate for
next year's Board
* The Financial statement for 2005-2006 will be soon available on the
website http://www.wikimedia.it/ (any related question may be put to
treasurer, M/)
* The meeting goes on on Sunday 3rd as well

For any information please refer to (in order)
* The Meetup page on it.wikipedia:
http://it.wikipedia.org/w/index.php?title=Wikipedia:Raduni/Viterbo_2006
* the Organiser: http://it.wikipedia.org/wiki/Discussioni_utente:M7
* the President of WMI:
http://it.wikipedia.org/wiki/Discussioni_utente:Frieda

Ciao
Cruccone (on behalf of Frieda)


subject: [WikiEN-l] Colbert Report trunks-up

body:
--- Andrew Gray <shimgray at gmail.com> wrote:

> On 02/08/06, Will <sceptre at tintower.co.uk> wrote:
> > We've been getting elephant population requests ~5
> times a day at WP:AFC as
> > well.
>
> Well, that's five fewer to delete in one way or
> another...

The population is already given and search brings you to
the elephant page, so maybe this should be taken as an
indication that the page may benefit from a mild
reorganizing, such as a dedicated section on elephant
populations.  There's already a section on rogue elephants,
but no population statistic for them.

Pro-Lick
http://shilllicker.blogspot.com
http://en.wiktionary.org/wiki/User:Halliburton_Shill

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


subject: [WikiEN-l] Colbert Report heads-up

body:
On 8/3/06, Oldak Quill <oldakquill at gmail.com> wrote:
> Not to mention that it would show a po-faced lack of sense of humour.
> I always feel that an organisation has become too large when they
> react terribly to jokes.
>

Depends on the joke. We have no problem with humor per se see the last line of:

http://en.wikipedia.org/wiki/2038_problem

--
geni


from_name: Magnus Manske

subject: [WikiEN-l] Colbert Report heads-up

body:
Steve Bennett schrieb:
> On 8/2/06, Will <sceptre at tintower.co.uk> wrote:
>
>> We've been getting elephant population requests ~5 times a day at WP:AFC as
>> well.
>>
>
> I repeat: I am *so* glad he made his vandalism request specific. Can
> you imagine if people just started turning up making outlandish but
> mildly plausible claims? There's no way we'd zap *all* fo them.
>
People who follow such a call are often not very patient. We could have
proected the whole site until the idiot-storm is over. With a big banner
saying so.

Magnus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20060803/fee71b11/attachment.pgp


body:
On 03/08/06, Fastfission <fastfission at gmail.com> wrote:
> The value is project-wide, not necessarily on an article-by-article
> basis. And I think Jimbo would say that a high quality encyclopedia is
> never at odds with producing a free one. Wikipedia could still be high
> quality even if it lacked fair use images. Most encyclopedias do *not*
> have an image for every article and do not feel the need to, much less
> images of lesser known celebrities and video games.

I would consider these two, and other similar types of articles (such
as on films and television programs), to be the only articles which
truly warrant Fair Use images. I think there is use in providing an
image with close to every article - it displays information in a
different form and can be highly enlightening to a user. Anything
which is accessible to the public should have free images (objects,
places and people).

The [[David Bowie]] article gets around the lack of free use
photographs by using a free use drawing. It looks like it could be a
drawing of a photograph and is certainly recognisable as David Bowie.
When does a drawing start violating copyright? Drawings are quite
subjective, is there much value in them?
--
Oldak Quill (oldakquill at gmail.com)


subject: [Wikitech-l] Extension Installer

body:
Steve Bennett wrote:
> On 8/3/06, Brion Vibber <brion at pobox.com> wrote:
>> I disagree completely. That is literally *IMPOSSIBLE* for those with no
>> command-line access, whereas dropping in a directory by FTP is insanely easy.
>>
>> Literally zero setup. What's easier? Nothing.
>
> Clicking "Extensions" from inside MediaWiki, being presented with a
> list, and clicking one to install and enable it. And having no idea
> how idea it actually works.

That's not easier, that's exactly what I'm talking about, therefore precisely as
easy.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20060803/5b8f7451/attachment.pgp>


subject: [WikiEN-l] Colbert Report heads-up

body:
On 8/3/06, Magnus Manske <magnus.manske at web.de> wrote:
> People who follow such a call are often not very patient. We could have
> proected the whole site until the idiot-storm is over. With a big banner
> saying so.

That kind of reaction seems like going the wrong way. At the end of
the day, Wikipedia wants to be open, and it wants to grow and develop.
We should look at these "idiot storms" as opportunities to attract new
contributors. It would be cool if we could replace the {{test}}
template with something like "Hey, thanks for the test - we've undone
it now, use the sandbox if you need to test anything else. You
wouldn't happen to know anything about <insert item from requests for
expansion> or <another item> would you? We're short on information on
them!"

You know, obsequiously assuming good faith even when presented with
evidence to the contrary can have an amazing effect on basically
good-hearted people.

Steve


subject: [WikiEN-l] Colbert Report heads-up

body:
On 03/08/06, geni <geniice at gmail.com> wrote:
> Depends on the joke. We have no problem with humor per se see the last line of:
>
> http://en.wikipedia.org/wiki/2038_problem

Haha, very good. No, I don't think we have a problem with humour
either - the suggestion about blocking Wikimedia until the storm is
over seemed to lack a sense of humour. If most people find a joke
funny and our reaction to it makes us seem self-righteous and
indignant then we have lost a sense of humour.
--
Oldak Quill (oldakquill at gmail.com)


from_name: Birger

subject: [Wikitech-l] Parserfunction "ifeq" not recognizing Magic Words?

body:
Hello there,

I am trying to show different images, dependent on some conditions:

Scenario 1: if the pagename is the same as a given pagename,
image_1.gif is shown.
Scenario 2: if the pagename is not the same as the given pagename, the
existence of the given pagename is checked:
        Scenario 2a: if the given pagename exists, image_2a.gif is shown.
        Scenario 2b: if the given pagename does not exist,
image_2b.gif is shown.

So i wrote:
 {{if:
      {{ifeq:
{{NAMESPACE}}:{{PAGENAME}} | {{NAMESPACE}}:{{BASEPAGENAME}}/subpage | true
      }}
 | [[Image = image_1.gif]]
 | {{ifexist:{{NAMESPACE}}:{{BASEPAGENAME}}/subpage
               | [[Image = image_2a.gif]]
               | [[Image = image_2b.gif]]
     }}
 }}

The problem is that image_1.gif does not appear, even if
{{NAMESPACE}}:{{PAGENAME}} has the same value as
{{NAMESPACE}}:{{BASEPAGENAME}}/subpage (e.g. image_2a.gif appears then
instead because the page exists). Does the parserfunction "ifeq"
compares the values litterally without interpreting the magicwords?

I don't think there is any mistake in the above wiki-code because when
i substitute "{{NAMESPACE}}:{{PAGENAME}}" by "a" end
"{{NAMESPACE}}:{{BASEPAGENAME}}/subpage" by "a", so that the
comparison is "a=a" (which is true) the image_1.gif is correctly
displayed.

Does anyone know whether the magicwords in the parserfunction "ifeq"
are recognized and what the cause of the problem is? If this
parserfunction does not interpret magic words, is there another
solution to display image_1.gif in case the pagename is the same as a
given pagename?

Thanks in advance!

B.


subject: [WikiEN-l] Colbert Report heads-up

body:
On 8/3/06, Oldak Quill <oldakquill at gmail.com> wrote:
> Not to mention that it would show a po-faced lack of sense of humour.
> I always feel that an organisation has become too large when they
> react terribly to jokes.

...

> I agree, although we don't have to wait for concensus to change
> {{test}}. A better solution would be to just make an alternate
> template (perhaps in the userspace). Hopefully this template will
> become popular through its use and effects.

I kind of think a group has become too large when the effort of making
a change that affects everyone is too great, and *everything* becomes
a fork...

Steve


from_name: Stan Shebs

body:
Fastfission wrote:

>
>But even without a centralized credit facility we could make it easy
>for photographers to quickly set up Flickr-like user pages for
>themselves where they would have their contact information, a link to
>their web page, and a list of all free photos they've uploaded to
>Wikipedia and what articles they are used in. If we set up easy-to-use
>templates for this it might make it look even more attractive. We
>could remind them how high a pagerank Wikipedia has, and that their
>photograph would be used in an article which showed up on the first
>Google search page in most cases.
>
>
This fits perfectly into commons' architecture, and indeed several
professionals already have their own dedicated galleries and/or
categories there.

What would be a good attention-getting conduit? Used to be, you
could get the attention of lots of nerds by just spa^H^H^Hposting
to Usenet. What do photographers look at?

I wonder if a classified-type ad in a print magazine would be noticed...

Stan


from_name: Evan Martin

subject: [Wikitech-l] Wikipedia Suggest

body:
On 8/3/06, Timwi <timwi at gmx.net> wrote:
> Julien Lemoine wrote:
> > First of all, I grabbed the whole content of english/french wikipedia in
> > june 2006. Then, everything is compiled is a final state machine (about
> > 200Mb for english wikipedia).
>
> Can you explain in greater detail what your finite-state machine looks
> like? Is it like a directed graph?

The right data structure for this sort of thing is called a "trie",
and Googling it will turn up lots of information.
Though I'm not sure if the original poster knows this term.


subject: [Wikitech-l] Wikipedia Suggest

body:
On 8/3/06, Evan Martin <evanm at google.com> wrote:
> On 8/3/06, Timwi <timwi at gmx.net> wrote:
> > Julien Lemoine wrote:
> > > First of all, I grabbed the whole content of english/french wikipedia in
> > > june 2006. Then, everything is compiled is a final state machine (about
> > > 200Mb for english wikipedia).
> >
> > Can you explain in greater detail what your finite-state machine looks
> > like? Is it like a directed graph?
>
> The right data structure for this sort of thing is called a "trie",
> and Googling it will turn up lots of information.
> Though I'm not sure if the original poster knows this term.

*grumble reply-to*

Sorry, was meant to be an off-list reply.


from_name: Nick Jenkins

subject: [Wikitech-l] Wikipedia Suggest

body:
Hi Julien,

> I have wrote a "google suggest" like service for wikipedia under GPL
> licence [1].
> By the way, I am not sure if this project will interest you, I am open
> to all comments from your community.

Yes!! Good stuff!

== UI stuff ==

The only two constructive suggestions for the User-Interface that I
would make are:

1) That if the user presses 'Enter' in the search textbox whilst
typing out a query, that it automatically choose/open/redirect to the
first item in the list. That way I can type out what I want, and press
enter to open the first link when I've typed enough to specify it well
enough to get it to the top of the list, all without using the mouse.

2) Allow the user to press the down/up arrows to select/highlight a
specified entry on the list (including but not limited to the first
item), and press enter to open it. That way again the user can be lazy
and can select a link without using the mouse, and without typing out
the full title.

== More Technical stuff ==

1) How do you handle pages with the same title, but different
capitalization? They're rare, but they do occur. My suspicion from
scanning Analyzer.cpp is that you just take the most popular. However,
if it's for search, it would be best to include everything (I think).

2) Doesn't seem to get include redirects. For example, when I search
for "Formula weight", it's not listed, but on the EN Wikipedia
"Formula weight" is a redirect to "Atomic mass". It would definitely
be better to include redirects (in my personal opinion).

However the downside of including these two things is that the amount
of data that you need to store goes up. I've actually had a go at a
very similar problem (storing a memory index of all article names, but
meeting the two conditions specified above, plus for redirects I would
also store the name of the article it redirected to [something which
could potentially maybe also be useful for your suggest service if you
wanted to show this information too]). However this was in PHP, and it
a complete memory hog (think > 1 Gb for the memory index). My solution
(since it was only for me) was to just "buy more RAM", however I like
your approach of getting more efficient. By the way, the reason I was
doing this was for suggesting links that could be made in wiki text -
just so you know I'm not in competition with you, but that the
problems we face are similar in some ways, and could maybe benefit
from a common solution.

How big would be a memory index be that had these properties (i.e.
including all NS:0 articles/redirects, and maybe including the targets
for redirects)?

All the best,
Nick.


from_name: Simetrical

subject: [Wikitech-l] Wikipedia Suggest

body:
On 8/3/06, Julien Lemoine <speedblue at happycoders.org> wrote:
> The algorithm uses very few cpu power. Imagine for example that all the
> data needed are in memory, the compiled automaton could be obtained in 1
> minutes.

Okay, that's good.  But what I meant was, how much CPU power (and
other resources) will the suggestion feature eat on a day-to-day
basis?  I start typing "Metasyntactic variable" into the search box,
it helpfully provides some suggestions based on its index ? how much
resources did that just use?  When thousands of people are doing it
every minute, how much will that slow down the servers compared to the
normal load of page views and edits and so on?


from_name: Steve Bennett

subject: [Wikitech-l] Toolserver

body:
At the risk of getting a whack on the head, could we have a status
update on the toolserver, particularly with respect to English
Wikipedia? I haven't heard much since it was announced that the data
was being reloaded but there was some corruption.

http://meta.wikimedia.org/wiki/Toolserver isn't very helpful.

Sorry to be a nuisance!

Steve


from_name: Alphax (Wikipedia email)

subject: [Foundation-l] Wikipedia Suggest

body:
Julien Lemoine wrote:
> Hello,
>
> I have wrote a "google suggest" like service for wikipedia under GPL
> licence [1].
> By the way, I am not sure if this project will interest you, I am open
> to all comments from your community.
>
> I wrote a simple web site for english/french on
> http://suggest.speedblue.org, all software are available in the download
> section.
>

Very nice! How often is the database updated?

--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 569 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/foundation-l/attachments/20060803/8709c03c/attachment.pgp


subject: [Foundation-l] Wikipedia Suggest

body:
Julien Lemoine wrote:
> Hello,
>
> I have wrote a "google suggest" like service for wikipedia under GPL
> licence [1].
> By the way, I am not sure if this project will interest you, I am open
> to all comments from your community.
>
> I wrote a simple web site for english/french on
> http://suggest.speedblue.org, all software are available in the download
> section.
>

Very nice! How often is the database updated?

--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 569 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/foundation-l/attachments/20060803/8709c03c/attachment-0001.pgp


subject: [Foundation-l] Wikipedia Suggest

body:
Julien Lemoine wrote:
> Hello,
>
> I have wrote a "google suggest" like service for wikipedia under GPL
> licence [1].
> By the way, I am not sure if this project will interest you, I am open
> to all comments from your community.
>
> I wrote a simple web site for english/french on
> http://suggest.speedblue.org, all software are available in the download
> section.
>

Very nice! How often is the database updated?

--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 569 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikimedia-l/attachments/20060803/8709c03c/attachment.pgp>


subject: [Foundation-l] Wikipedia Suggest

body:
Julien Lemoine wrote:
> Hello,
>
> I have wrote a "google suggest" like service for wikipedia under GPL
> licence [1].
> By the way, I am not sure if this project will interest you, I am open
> to all comments from your community.
>
> I wrote a simple web site for english/french on
> http://suggest.speedblue.org, all software are available in the download
> section.
>

Very nice! How often is the database updated?

--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 569 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikimedia-l/attachments/20060803/8709c03c/attachment-0001.pgp>


body:
geni wrote:
> On 8/2/06, Steve Bennett <stevagewp at gmail.com> wrote:
>> On 8/2/06, geni <geniice at gmail.com> wrote:
>>> I'm not sure that is much of an fair use defence and in any case where?
>> I don't think there is any doubt over the legitimacy of including a
>> low-res scan of an album cover in an article about the album.
>>
>> Steve
>
> On what basis?
>

For educational, criticism and critiquing purposes; we're educating
readers about what the album looks like if they want to go to their
local music store and buy it :)

--
Alphax - http://en.wikipedia.org/wiki/User:Alphax
Contributor to Wikipedia, the Free Encyclopedia
"We make the internet not suck" - Jimbo Wales
Public key: http://en.wikipedia.org/wiki/User:Alphax/OpenPGP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 569 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20060803/7e0b4ae4/attachment.pgp