body:
On Wed, 2003-05-28 at 14:56, Oliver Pereira wrote:
> However, Erik's constraint that articles shouldn't be such that they will
> always remain stubs would probably disqualify it, if we accept his wish
> for articles to be 20,000 to 30,000 characters in length. It is currently
> less than 2,000 characters long. It could be expanded using the news
> article and whatever is sufficiently trustworthy on the tribute site, and
> padded with some relevant background about the school and neighbourhood
> and so on, but it would probably still be under 10,000 characters.
>
> But isn't this length business just a matter of personal taste?
> Personally, I find long articles quite off-putting. [[Charles Darwin]],
> for example, only just barely qualifies as a decently sized article
> according to Erik, while I think it could do with being split into
> separate sections.
>
> Clearly I don't have Erik's attention span. :) But do we *really* want
> articles that are over 10,000 characters long? And if so, why? I'm sure
> I'm not the only one who finds it a daunting task to try to edit long
> articles, especially if there is major restructuring to be done. If we
> want Wikipedia to be open to everyone, and easy to edit, I think we should
> seriously consider aiming for shorter articles everywhere. A reader who
> wants to read 30K of information about a subject would still be able to;
> they'd have to read three articles instead of one, maybe, but it would
> only involve two clicks of the mouse...
>
I, for one, strongly disagree with the Long-Entrians. I am a Atomizer.
Short, interlinked entries are most appropriate for the medium, both in
reading and editing.


list: wikien-l

source: pipermail-mbox

from_name: Christopher Mahan

subject: [WikiEN-l] A request from H. Jonat

body:
--- james duffy <jtdirl at hotmail.com> wrote:
> Zoe wrote
> >I really think that the mailing list pages should be
> >blocked from search engines.
>
> I agree. People need to be able to discuss matters openly and
> frankly.

I disagree. Having a track record is important. People in 5 years
will need the records to see what we did and why we did it. It might
cut down the flame-wars.

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

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com


from_name: Richard Grevers

subject: [WikiEN-l] The principle of fair use

body:
On Mon, 26 May 2003 21:11:23 -0400, cprompt <cprompt at tmbg.org> gave
utterance to the following:

> Daniel Ehrenberg wrote:
>
>> Is anyone at Wikipedia a cartographer?
>>
>> In responce to the first post (which I accidentally
>> deleted), is a cleaned up picture (obviously with most
>> of the pixels different, but similar colors) still a
>> violation of copywright? I made one if it would help.
>> --LittleDan
>>
> Sorry, but I tend to think it would still be a violation of copyright,
> just as much as taking a popular song and adding a drum beat, or using an
> acoustic guitar instead of electric guitar. In this case, you are
> changing the original, rather than using the original to create your own
> work.
>
I disagree. The information (in this case borders established by a 9th
century treaty and the outline of Europe, plus some place names) is not
copyrightable, only the presentation of it is.
I quite often have to make maps showing the locality of some project. I
might have traced the location of the streets from some other source, but
it is impossible to tell from the finished work which if any of multiple
sources (including public records) it may have been based upon.

--
Richard Grevers
Women are like watches: The finer the movement the better the time


from_name: Dante Alighieri

subject: [WikiEN-l] A request from H. Jonat

body:
At 03:31 PM 5/28/2003, you wrote:

>--- james duffy <jtdirl at hotmail.com> wrote:
> > Zoe wrote
> > >I really think that the mailing list pages should be
> > >blocked from search engines.
> >
> > I agree. People need to be able to discuss matters openly and
> > frankly.
>
>I disagree. Having a track record is important. People in 5 years
>will need the records to see what we did and why we did it. It might
>cut down the flame-wars.

What about archiving the mailing list locally, but not having that
available to crawlers so that it's hidden from Google and Yahoo! and such?
That way there would be a record, but people would have to come to the
Wikipedia to see it.

-----

Dante Alighieri
dalighieri at digitalgrapefruit.com

"The darkest places in hell are reserved for those who maintain their
neutrality in times of great moral crisis."
    -Dante Alighieri, 1265-1321
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030528/2d2d078a/attachment.htm


list: wikipedia-l

from_name: Thomas Corell

subject: [Wikipedia-l] Disambiguation detector

body:
Erik Moeller wrote:

> Very cool feature, Magnus! This will save us a lot of manual "Alternate
> meaning" links. Now all we need is some kind of template/transclusion
> system so the disambiguation text does not need to be edited on 20342
> pages if it changes ..

Oh, therefore we need users, don't do all the work ;)

> BTW, we can probably all just speak German if the current trend continues
> :-)

Well, but I think it's not even as fair as writing french or whatever,
if you can try it in english (I try hard and fail;). It reduces the
participation of all the others. And that's in no way the target of
wikipedia. (Of course if someone only speaks/writes $language he/she/it
can write here and hope someone answers/translate).

Smurf
--
In the internet noboby knows you are a dog.
  --- Anthill Inside! ---


from_name: Lee Daniel Crocker

subject: [Wikipedia-l] Re: Limits to the non-paperiness of Wikipedia?

body:
> (Karl Eichwalder <ke at gnu.franken.de>):
>
> Also, "fragment links" are not supported, you know, these
> "http://example/page.html#fragment" pointers.

Actually they are; have been for a long time. But the ability to
make the link _target_ has been disabled until we can agree on a
better syntax for it.

My current favorite suggestion is that second-level headings (H2)
should automatically become link targets.

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


from_name: Julie Kemp

subject: [WikiEN-l] possible odd goings on?

body:
Hi all - I just got an e-mail from someone calling himself 168 . (e-mail
address shakerh4 at yahoo.com) saying he'd wanted to quote something from
my user page on a new page called wikipedia: Who, Why?  I wrote back
pointing out that I was still around - anyway, it seemed like a letter
meant to make me think he was "on my side"   If someone e-mails someone
else through the pedia, is there any virus protection thing?  I could
find no such page, and now wonder if it wasn't a ploy to get me to
reveal my address .and it's not the one on th emailing list! (I know,
dumb of me).  Any suggestions, or am I being paranoid about this being
not entirely kosher?

JHK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030528/ee1fd605/attachment.htm


subject: [WikiEN-l] possible odd goings on?

body:
At 04:00 PM 5/28/2003, you wrote:

>Hi all I just got an e-mail from someone calling himself 168 & (e-mail
>address <mailto:shakerh4 at yahoo.com>shakerh4 at yahoo.com) saying hed wanted
>to quote something from my user page on a new page called wikipedia: Who,
>Why?  I wrote back pointing out that I was still around anyway, it seemed
>like a letter meant to make me think he was on my side   If someone
>e-mails someone else through the pedia, is there any virus protection
>thing?  I could find no such page, and now wonder if it wasnt a ploy to
>get me to reveal my address &and its not the one on th emailing list! (I
>know, dumb of me).  Any suggestions, or am I being paranoid about this
>being not entirely kosher?
>
>JHK

My understanding is that 168... is an upstanding user. And I've seen the
Who, Why? page. Looks legit to me. Anyone else?

-----

Dante Alighieri
dalighieri at digitalgrapefruit.com

"The darkest places in hell are reserved for those who maintain their
neutrality in times of great moral crisis."
    -Dante Alighieri, 1265-1321
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030528/63d1bcd2/attachment.htm


from_name: cprompt

subject: [WikiEN-l] The principle of fair use

references:
<20030526192934.8907.qmail@web41807.mail.yahoo.com>
 <3ED2BB3B.9070502@tmbg.org> <oprpu5h6vhzs1r4a@localhost>

body:
Richard Grevers wrote:

> On Mon, 26 May 2003 21:11:23 -0400, cprompt <cprompt at tmbg.org> gave
> utterance to the following:
>
>> Daniel Ehrenberg wrote:
>>
>>> Is anyone at Wikipedia a cartographer?
>>>
>>> In responce to the first post (which I accidentally
>>> deleted), is a cleaned up picture (obviously with most
>>> of the pixels different, but similar colors) still a
>>> violation of copywright? I made one if it would help.
>>> --LittleDan
>>>
>> Sorry, but I tend to think it would still be a violation of
>> copyright, just as much as taking a popular song and adding a drum
>> beat, or using an acoustic guitar instead of electric guitar. In this
>> case, you are changing the original, rather than using the original
>> to create your own work.
>>
> I disagree. The information (in this case borders established by a 9th
> century treaty and the outline of Europe, plus some place names) is
> not copyrightable, only the presentation of it is.
> I quite often have to make maps showing the locality of some project.
> I might have traced the location of the streets from some other
> source, but it is impossible to tell from the finished work which if
> any of multiple sources (including public records) it may have been
> based upon.
>
But is a cleaned up picture with different colors really the same as
tracing a map? I see tracing a map as akin to paraphrasing a document
which should be okay. In any case, I'm not willing to fight on this
issue, and will go with whatever the consensus is. :-)

--

--cprompt


from_name: Ray Saintonge

subject: [WikiEN-l] Mention that Bomis hosts Wikipedia

body:
Daniel Ehrenberg wrote:

 >I agree in prinicple, but it would look somewhat
 >amateurish.
 >--LittleDan
 >
Whatever the merits or problems of mentioning Bomis, what's wrong with
amateurish?

Wikipedia is the pinnacle of amateurish, and that's one of its greatest
assets.

Amateurish is chaotic, uncertain and fecund

Professional is orderly, confident and sterile.

It's just an observation that I've made over the years across a number
of fields.

Eclecticology


list: wikitech-l

subject: [Wikitech-l] Title characters

body:
Brion Vibber wrote:

>On Tue, 27 May 2003, Lee Daniel Crocker wrote:
>
>>I confess ignorance here. Are there really languages for which the
>>simplest canonical representation in Unicode requires combining forms?
>>
>
>Off the top of my head, one Aleutian language (Unangam Tunuu) uses
>x-with-circumflex; Guarani apparently uses g-with-tilde. Tone marks for
>Chinese Zhuyin phoenetic script are combining characters; I think the
>Indian scripts are pretty dependant on this kind of thing as well.
>
Also nasalized vowels for IPA.

Ec


from_name: Jimmy Wales

subject: [Wikipedia-l] [lori@affero.com: Wikipedia to be featured in Affero's Newsletter]

body:
----- Forwarded message from Lori Winslow <lori at affero.com> -----

From: "Lori Winslow" <lori at affero.com>
Date: Wed, 28 May 2003 14:49:15 -0700
To: <jwales at bomis.com>
Subject: Wikipedia to be featured in Affero's Newsletter

Hello, My name is Lori Winslow and I am one of the founders of Affero (http://www.affero.net).  We publish a
monthly community newsletter called Random Hacks of Kindness - Each month we feature an innovative project or
cause that is open source.

In our last edition (April 2003 - see that here: http://www.affero.net/nl/apr03.html), we featured Xaraya
which is a Content Management Solution.

For our May edition, Wikipedia will be the featured project. I will provide a brief summary with a link to the
sourceforge page and use some "about" text from the Wikipedia website.   Once the newsletter is published -
target is by the end of the week - I will send you a copy.

If you want to promote this anywhere or have suggestions where we should do so, please let me know.  I would
love to get more recognition and awareness out about Wikipedia.  What a great project!

Let me know if you have any questions or comments. Thanks so much.

Lori Winslow
lori at affero.com

"There are two means of refuge from the miseries of life: music and
cats."  - Albert Schweitzer

==========
Give a voice to those who cannot speak for themselves:
http://rate.affero.net/loriwinslow

----- End forwarded message -----


subject: [WikiEN-l] A request from H. Jonat

in_reply_to: <BAY1-F201GYaBQYR7Wk0001af4a@hotmail.com>; from jtdirl@hotmail.com on Wed, May 28, 2003 at 11:15:20PM +0100

body:
james duffy wrote:
> I agree. People need to be able to discuss matters openly and frankly. It
> really is nobody else's business but the people on the mailing list what is
> said on that list.

Well, I don't agree at all.  Wikipedia is a transparent public
project, what we do is all out in the open for anyone to see.

Sunshine is the best disinfectant.

It is true that of course some things are best said privately -- but
then they are best said really privately, one on one, to trusted
confidants.

--Jimbo


subject: [WikiEN-l] possible odd goings on?

in_reply_to: <5.2.0.9.2.20030528162039.011597e8@digitalgrapefruit.com>; from dalighieri@digitalgrapefruit.com on Wed, May 28, 2003 at 04:21:17PM -0700

body:
Is there a link to this "Who? Why?" page?

Dante Alighieri wrote:

> At 04:00 PM 5/28/2003, you wrote:
>
> >Hi all I just got an e-mail from someone calling himself 168 & (e-mail
> >address <mailto:shakerh4 at yahoo.com>shakerh4 at yahoo.com) saying hed wanted
> >to quote something from my user page on a new page called wikipedia: Who,
> >Why?  I wrote back pointing out that I was still around anyway, it seemed
> >like a letter meant to make me think he was on my side   If someone
> >e-mails someone else through the pedia, is there any virus protection
> >thing?  I could find no such page, and now wonder if it wasnt a ploy to
> >get me to reveal my address &and its not the one on th emailing list! (I
> >know, dumb of me).  Any suggestions, or am I being paranoid about this
> >being not entirely kosher?
> >
> >JHK
>
> My understanding is that 168... is an upstanding user. And I've seen the
> Who, Why? page. Looks legit to me. Anyone else?
>
>
> -----
>
> Dante Alighieri
> dalighieri at digitalgrapefruit.com
>
> "The darkest places in hell are reserved for those who maintain their
> neutrality in times of great moral crisis."
>     -Dante Alighieri, 1265-1321


from_name: Axel Boldt

subject: [Wikipedia-l] Disambiguation detector

body:
--- Thomas Corell <T.Corell at t-online.de> wrote:

> PS: If you remember, Magnus wrote that each Language can turn it on
> or off. Or possibly each User. I think that will be a minor change
the
> developers can handle in a few minutes. No need that all have to use
> this feature. And than each wikipedia or even each user can choose.

If we adopt Magnus' feature (which I would support), then it should not
become a user option. The whole point of the feature is to do away with
hand-written disambiguation blocks, but that is only possible if
everyone uses it.

Axel

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com


from_name: Tim Starling

subject: [Wikitech-l] Bug fix

body:
My first ever CVS commit seems to have worked just fine. I fixed a bug I
submitted to the tracker myself, # 635281, URL:

http://sourceforge.net/tracker/index.php?func=detail&aid=635281&group_id=343
73&atid=411192

It was a tough one: four whole characters of source code had to be added to
Article.php in the obvious place. Plus another four for good measure. I
tested it on Lee's machine and it seems to work.

-- Tim Starling.


from_name: Vicki Rosenzweig

subject: [WikiEN-l] A request from H. Jonat

body:
At 03:31 PM 5/28/03 -0700, Christopher wrote:

>--- james duffy <jtdirl at hotmail.com> wrote:
> > Zoe wrote
> > >I really think that the mailing list pages should be
> > >blocked from search engines.
> >
> > I agree. People need to be able to discuss matters openly and
> > frankly.
>
>I disagree. Having a track record is important. People in 5 years
>will need the records to see what we did and why we did it. It might
>cut down the flame-wars.

It might.

More to the point, since the list is entirely open--to the point that
people banned from the Wikipedia can still read and contribute to the
mailing list--making it unsearchable wouldn't provide privacy, only
inconvenience.
--
Vicki Rosenzweig
vr at redbird.org
http://www.redbird.org


subject: [Wikipedia-l] Disambiguation detector

body:
> (Toby Bartels <toby+wikipedia at math.ucr.edu>):
>
> My idea is to link people directly to the disambiguation page,
> which will (if well written) contain exactly what readers need --
> human editing of the disambiguation page in the wiki way will see to that.
> Here's a brief algorithm:
>
> Given a page title [[X]] without parentheses or of the form [[X (Y)]]:
> * Search for a page [[X (disambiguation)]]
> ** If it exists, add "See also: [[X (disambiguation)]]"
>    (unless "Y" = "disambiguation", of course).
> ** If it doesn't exist, add "See also: [[X]]"
>    (unless we're on [[X]] itself, of course).
> We don't need to link to anything else;
> the disambiguation page (either [[X]] or [[X (disambiguation)]])
> will do so, and furthermore will have human-written text
> explaining the nuances, if necessary.
>
> As a bonus, we could add the complete list of parenthesised pages
> as a "See also" on the disambiguation page itself
> (as identified by the "unless"es in the previous paragraph).
> That's not really necessary, but it could be convenient;
> for example, it would highlight an incomplete disambiguation page.
>
> Furthermore, this could solve the problem of formatting disambiguation blocks.
> Larry, mav, and I have discussed this matter before
> on [[en:Wikipedia talk:Disambiguation]] (look for "= Jimmy Carter =").
> If, as mav suggested on the mailing list just now,
> we put this "See also" directly underneath the language links,
> then Larry, mav, and I, at least, should think that it looks good.
> Human-written disambiguation blocks would be unnecessary;
> but the human-written material would still be on [[X (disambiguation)]],
> so Lee (and I) should be happy about that.

That's a bit complex, but maybe it could be made to work. The analogy
to language links doesn't quite work for me because some human editor
has actually gone to the trouble of noting that the fr:chat article is
an appropriate French version of en:cat, whereas these will be fully
automatic. But I agree that it's a reasonably safe bet that X (Y) is
somehow related to X, X (Z), and X (disambiguation), because our
conventions here have created that association, so it's somewhat human-
created.

Another issue is performance. Perhaps we could help both of those
issues by making a single link to a list page rather than a set of
links. But what to call that list is tricky. Is isn't really "related
pages" because they're only related lexigographically, not semantically.
Perhaps it could be something like "Other 'Foo' pages".

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


from_name: Oliver Pereira

subject: [Wikipedia-l] Limits to the non-paperiness of Wikipedia?

body:
On Wed, 28 May 2003, Jimmy Wales wrote:

> That sounds about right to me.  For example, the current Mayor of
> Athens, Georgia, U.S.  I doubt if we have an article about that
> person, but I see no reason why we shouldn't.

Okay, there's a bit of a fight over [[Sarah Marple-Cantrell]].

She's a 12-year-old girl who killed herself, and has a Web presence of
little more than one local news article and one tribute site. So she's
rather more obscure than the Mayor of Athens, Georgia, I expect. However,
using Stan Shebs's "thousand-person rule", she could qualify. I'm sure
everyone with a family member at her school (say 300ish pupils * 4 family
members each) would have been affected by a suicide taking place in their
school, and possibly a fair proportion of local people in Addison, Texas
(pop. 14,166).

However, Erik's constraint that articles shouldn't be such that they will
always remain stubs would probably disqualify it, if we accept his wish
for articles to be 20,000 to 30,000 characters in length. It is currently
less than 2,000 characters long. It could be expanded using the news
article and whatever is sufficiently trustworthy on the tribute site, and
padded with some relevant background about the school and neighbourhood
and so on, but it would probably still be under 10,000 characters.

But isn't this length business just a matter of personal taste?
Personally, I find long articles quite off-putting. [[Charles Darwin]],
for example, only just barely qualifies as a decently sized article
according to Erik, while I think it could do with being split into
separate sections.

Clearly I don't have Erik's attention span. :) But do we *really* want
articles that are over 10,000 characters long? And if so, why? I'm sure
I'm not the only one who finds it a daunting task to try to edit long
articles, especially if there is major restructuring to be done. If we
want Wikipedia to be open to everyone, and easy to edit, I think we should
seriously consider aiming for shorter articles everywhere. A reader who
wants to read 30K of information about a subject would still be able to;
they'd have to read three articles instead of one, maybe, but it would
only involve two clicks of the mouse...

Oliver

+-------------------------------------------+
| Oliver Pereira                            |
| Dept. of Electronics and Computer Science |
| University of Southampton                 |
| omp199 at ecs.soton.ac.uk                    |
+-------------------------------------------+


subject: [WikiEN-l] Alternative to Blanking Pages

body:
Axel Boldt wrote:

>--- cprompt <cprompt at tmbg.org> wrote:
>
>
>
>>Instead of blanking articles why not replace the article text with a
>>redirect to a boilerplate text with something along the lines of
>>"The content of this article is being disputed. It has been blanked
>>for the time being, though older version are still accessible through
>>the Page History. It may have been blanked because of blatantly false
>>
>>
>
>
>
>>information, or non-encyclopedic garbage. This article may be
>>awaiting [[votes for deletion]], or awaiting a sysop to delete it.
>>Please use the Talk Page to discuss this dispute if necessary, and
>>check [[Votes for Deletion]]"
>>
>>
>
>I disagree with this in the case of removing work by banned users, for
>the following reasons:
>
>* it is factually incorrect: the work was not removed because it is
>"disputed", but because it was contributed by a person who is not
>allowed to contribute.
>
>* talking about "disputed" and "older version" implies that it may be a
>good idea to look at the old material and check whether it is worth
>restoring. But that is precisely what should *not* be done in the case
>of a soft ban. Treating the banned user's contributions on their merits
>just encourages him/her to contribute more.
>
>Axel
>
>
Brion linked to Ward's wiki boilerplate text (
http://c2.com/cgi-bin/wiki?DeleteTestAndWelcome) and Toby suggested we have several boilerplate texts to use in certain situations. You make a good point in that the text I suggested might legitimize the work of a banned user. Perhaps the boilerplate text in that particular situation could be "The text in this article was created by a user who is banned from using the Wikipedia. This page will eventually be removed by an administrator and may in the future be replaced by the work of a valid contributor."

If no one else would like to undertake the task of writing out the boilerplate texts, I'll add it to my todo list.

--cprompt


from_name: John R. Owens

subject: [WikiEN-l] possible odd goings on?

body:
On Wed, 28 May 2003, Jimmy Wales wrote:

> Date: Wed, 28 May 2003 17:46:30 -0700
> From: Jimmy Wales <jwales at bomis.com>
> Subject: Re: [WikiEN-l] possible odd goings on?
>
> Is there a link to this "Who? Why?" page?

http://www.wikipedia.org/wiki/Wikipedia%3AWho%2C_Why%3F

--
John R. Owens http://www.ghiapet.homeip.net/
"You getting back together with (name omitted) would be even stupider than
me taking you back!"
	No. 7 on the list of Top Ten Things NOT to say to an ex-girlfriend
		with whom you may have hopes of getting back together


subject: [Wikitech-l] Upload log error

body:
When I try to check the
http://www.wikipedia.org/wiki/Wikipedia%3AUpload_log Upload log page, I'm
getting timeouts and "connection close" messages. Is that one of the ones
that needs to be cleared out from time to time, or is that just the
Deletion log? If it is, it's probably time to clear some out. If not, then
why IS it behaving this way?

--
John R. Owens http://www.ghiapet.homeip.net/
I will confess that I look forward to the day when we have cleansed the
universe of the Centauri and carved their bones into little flutes for
Narn children.  'Tis a dream I have.
				--G'Kar


from_name: Magnus Manske

subject: [Wikipedia-l] Disambiguation detector

body:
Lee Daniel Crocker wrote:
> I'm not convinced. I generally dislike the idea of automatic
> content of any kind--the content of Wikipedia should be created
> by human editors, and even disambiguation pages should each be
> crafted uniquely to suit the needs of the subject, not just stamped
> out of a template.

Yes, I seem to remember :-)

But this is not written into the content - just a display of (possible)
related links, like "what links here". Granted, links on "what links
here" are human-made, but so are page titles. We're bound to step onto
some false positives with this, but IMHO the advantages outweight that.
Unless, of course, it badly affects performance, which I doubt, given
the rather minor query (it uses "%", though...)

Magnus


from_name: Sean Barrett

subject: [Wikipedia-l] Disambiguation detector

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

Axel Boldt wrote:
| If we adopt Magnus' feature (which I would support), then it should not
| become a user option. The whole point of the feature is to do away with
| hand-written disambiguation blocks, but that is only possible if
| everyone uses it.
|
| Axel

If everybody must use it and hand-written disambiguation blocks are to
be "done away with," then I oppose it.

Given a mandatory XOR choice between

	"See also USS Enterprise (1775), USS Enterprise (1799),
	USS Enterprise (1831), USS Enterprise (1874),
	USS Enterprise (CV-6), and USS Enterprise (CVN-65)."

and the 1500-character disambiguation block at USS Enterprise -- which
not only mentions the Star Trek ships and the Space Shuttle and the ten
HMS Enterprises but also describes a schooner and a motorboat that are
not worth separate articles AND gives a couple of points of distinction
between the each of the eight ships -- then I choose the hand-written,
informative page.

- --
~ Sean Barrett     | Lozhka diogtia portit bochku miodu.
~ sean at epoptic.com |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+1ZLiv/8xpnvE6M8RAtnRAJ9C9UIM8vncB3Pq3uOzq38zgP6BqwCgleGm
Jim0iGsEgvMUO61tOjK+p8c=
=FMJ0
-----END PGP SIGNATURE-----


from_name: Karl Eichwalder

body:
Oliver Pereira <omp199 at ecs.soton.ac.uk> writes:

> But do we *really* want articles that are over 10,000 characters long?

Sure.

> And if so, why?

As a reader I want info belonging together in oen article, I'm not that
much interested in clicking around.  I'm also not interested in
download and reading and scrolling away all this navigation stuff.

Many a lot fragmented pages are only useful if you want to offer banner
ads and stuff like that.

> I'm sure I'm not the only one who finds it a daunting task to try to
> edit long articles, especially if there is major restructuring to be
> done.

This is a problem.  My solution is to copy-and-paste centents into my
editor, do the editing business (check it into my local CVS), and paste
it back into the webbrowser for publishing.

Also, "fragment links" are not supported, you know, these
"http://example/page.html#fragment" pointers.

> If we want Wikipedia to be open to everyone, and easy to edit, I think
> we should seriously consider aiming for shorter articles everywhere. A
> reader who wants to read 30K of information about a subject would
> still be able to; they'd have to read three articles instead of one,
> maybe, but it would only involve two clicks of the mouse...

Don't worry too much, most articles start small...

--
                                                         |      ,__o
http://www.gnu.franken.de/ke/                            |    _-\_<,
ke at suse.de (work) / keichwa at gmx.net (home)               |   (*)/'(*)


from_name: Brion Vibber

subject: [WikiEN-l] American diplomatic listings

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

Je Merkredo 28 Majo 2003 20:53, james duffy skribis:
> I notice a lot of pages of countries which reply on information from
> the CIA factsbook include information US diplomatic representation to
> that country and that country's diplomatic representation to the US.

There was discussion on talk pages (I don't remember where) sometime
last year in which it was agreed to take those out. Presumably they
didn't all get done at the time; if you see more, please fix them up.

- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+1Ze4xVlOmwh1xjgRAlo2AJ9X8BM04hTqyrB6FcSWb9Q1w/viOACfRI7v
VzvWXkYKVZijqmwuS2ql58w=
=djEi
-----END PGP SIGNATURE-----


subject: [Wikipedia-l] Disambiguation detector

body:
> (Axel Boldt <axelboldt at yahoo.com>):
>
> If we adopt Magnus' feature (which I would support), then it should not
> become a user option. The whole point of the feature is to do away with
> hand-written disambiguation blocks, but that is only possible if
> everyone uses it.

No, that's not the point at all. Hand-written disambiguations with
clarifying comments are invaluable. This new feature, if we can figure
out a good way to do it, is to facilitate creating them and keeping
them up to date, not to eliminate them.

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


subject: [Wikitech-l] Upload log error

body:
> (John R. Owens <jowens.wiki at ghiapet.homeip.net>):
> When I try to check the
> http://www.wikipedia.org/wiki/Wikipedia%3AUpload_log Upload log page, I'm
> getting timeouts and "connection close" messages. Is that one of the ones
> that needs to be cleared out from time to time, or is that just the
> Deletion log? If it is, it's probably time to clear some out. If not, then
> why IS it behaving this way?

Yeah, it just grows too large. I really need to think about
reimplementing logs entirely.

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


from_name: james duffy

subject: [WikiEN-l] A request from H. Jonat

body:
Zoe wrote
>I really think that the mailing list pages should be
>blocked from search engines.

I agree. People need to be able to discuss matters openly and frankly. It
really is nobody else's business but the people on the mailing list what is
said on that list. Other email conversations aren't accessible generally.
Why should this mailing list be available? Many people don't realise that
what they say on the mailing list isn't private and if they did might simply
opt out of it.

JT

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail


subject: [Wikipedia-l] Disambiguation detector

body:
Toby Bartels wrote:
> Lee Daniel Crocker wrote:

>>I'm not convinced. I generally dislike the idea of automatic
>>content of any kind--the content of Wikipedia should be created
>>by human editors, and even disambiguation pages should each be
>>crafted uniquely to suit the needs of the subject, not just stamped
>>out of a template.
>
>
> I agree with Lee, but I think that the idea can still be made to work.
>
> To expand on Lee's point, if faced simply with a list of alternate articles
> -- [[X]], [[X (Y1)]], [[X (Y2)]], [[X (Y3)]], etc. --
> it may not be clear which article you really want,
> at least if the various Ys are closely related.
> A disambiguation page, if necessary, can offer explanations.
> We usually don't need explanation, and a disambiguation page
> is thus usually just a list -- but sometimes we do need explanation.

Well, I agree with Lee, too. And I don't see the problem of Magnus feature.
We have disambiguation pages, written manually as Lee it prefers, with
explanations and all. Magnus don't intended to change that.

And Magnus feature only supports a shortcut: If I got on a page X (Y1)
(randomly), and I see X (Y2) and think, oh, fine, Y2 was what I'm
interested in, let's go there, I can do that. No need to do that list of
links manually. If I need the explanations or I'm interested in them I will
  go to X, and read them. The user has the free choice, we only offer him
to have that choice.

Let's first decide if we agree to the feature as it is, and discuss further
features seperatly. Erik's proposal is a possiblility, but it should be not
mixed up with the current feature.

PS: If you remember, Magnus wrote that each Language can turn it on or off.
Or possibly each User. I think that will be a minor change the developers
can handle in a few minutes. No need that all have to use this feature. And
than each wikipedia or even each user can choose.

--
Smurf
German translation on request ;)
smurf at AdamAnt.mud.de
-------------------------  Anthill inside! ---------------------------


from_name: Toby Bartels

subject: [Wikipedia-l] Disambiguation detector

body:
Lee Daniel Crocker wrote in response to me:

>That's a bit complex, but maybe it could be made to work. The analogy
>to language links doesn't quite work for me because some human editor
>has actually gone to the trouble of noting that the fr:chat article is
>an appropriate French version of en:cat, whereas these will be fully
>automatic. But I agree that it's a reasonably safe bet that X (Y) is
>somehow related to X, X (Z), and X (disambiguation), because our
>conventions here have created that association, so it's somewhat human-
>created.

I don't think that one should stress much of an *analogy* to language links.
It should go no farther than that the place where language links now lie
would be a good place (one a separate line) to place these as well.

>Another issue is performance. Perhaps we could help both of those
>issues by making a single link to a list page rather than a set of
>links. But what to call that list is tricky. Is isn't really "related
>pages" because they're only related lexigographically, not semantically.
>Perhaps it could be something like "Other 'Foo' pages".

Or [[Foo (disambiguation)]]! ^_^

-- Toby


subject: [Wikipedia-l] Disambiguation detector

body:
Smurf wrote in part:

>Let's first decide if we agree to the feature as it is, and discuss further
>features seperatly. Erik's proposal is a possiblility, but it should be not
>mixed up with the current feature.

Yes, let's set Erik's ideas aside for now --
we can trust Erik to bring them up again! ^_^

-- Toby


subject: [Wikipedia-l] Disambiguation detector

body:
Axel Boldt wrote:

>If we adopt Magnus' feature (which I would support), then it should not
>become a user option. The whole point of the feature is to do away with
>hand-written disambiguation blocks, but that is only possible if
>everyone uses it.

I think that we can do this in such a way
as to eliminate human-written disambiguation *blocks*
but to retain of human-written disambiguation *pages*.
Indeed, we may have to write a few more of the latter,
since some disambiguation now is done *only* by blocks --
so we may get more human-written content in the end.

-- Toby


subject: [WikiEN-l] A request from H. Jonat

body:
>james duffy wrote:
> > I agree. People need to be able to discuss matters openly and frankly.
>It
> > really is nobody else's business but the people on the mailing list what
>is
> > said on that list.
>
>Well, I don't agree at all.  Wikipedia is a transparent public
>project, what we do is all out in the open for anyone to see.
>
>Sunshine is the best disinfectant.
>
This argument reflects an ongoing debate in political science over
tranparency versus confidentiality in public office decision taking. Keeping
of records and access to them is vital. To too much ''immediate'' access
tends to lead to (a) people not being able to be open in a discussion
without their words coming back to haunt them or being used outside
wikipedia against them (if they were called on the list a rascist, a bigot,
a homophobe, anti-semite, anti-catholic, any-woman, anti whatever) (b)
playing to the gallery, ie., phoney positions being taken up simply for the
impression they give if anyone does a google search on someone.

Most organisations provide a space where full records are kept of
discussions, debates, etc but where that information is not instantly
available, providing a degree of confidentiality that allows things to be
discussed fully and frankly without the worry that someone doing a google
search discovering that 'x' was accused of such and such. I know I wanted to
send a sensitive message to someone on wiki, but couldn't email them as they
have no email account listed.

I would hate to think, for example, that if Mav ever ran for public office,
an opponent could do a google search under Mav's name, find that someone on
the list in the heat of an argument once accused him of anti-semitism (and
that is a ficticious example!) and use such a suggestion against him. I
myself was accused of being like a holocaust denier here once. Luckily this
email account doesn't give my real name, but if it did, that wild accusation
could show up against me in a google search if for example in next year's
Irish local elections I agreed to run for office as I have been asked. Or if
ran in the next Irish general election in 2007. If there was the slightest
chance that that wild claim or others could be found if someone did a google
search under my real name, I would be gone from the list (and probably from
wikipedia) like a shot.

Communication on this list should only be available (a) through a carefully
restricted means (eg, through being a contributor to wikipedia), not simply
through a google search, and (b) perhaps with some time delay mechanism.
There is, for example, a US Democratic Party political consultant called
James Duffy, a soccer manager called James Duffy and a number of others.
What happens if someone does a google search, finds attacks made on me under
the name of this email account and presumes it was some other 'James Duffy',
one with a public profile. That is why organisations 'always' provide
restricted access to discussions such as those here, usually with a time
delay mechanism. They universally find that unrestricted access blocks free
discussion  and prevents, not encourages, free speech.

JT

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus


subject: [Wikipedia-l] Disambiguation detector

body:
Erik Moeller wrote:

>It may be useful to be able to transclude such text segments
>([[>Wikipedia:Disambiguation]] or something like this). However, I am also
>thinking about having these segments be inserted as part of a general
>category scheme, such as
>
>[[Category:Disambiguation page]]
>
>Where that page would list all pages in that category, with automatic
>paging and sorting, and allow editors to define a standard block of text
>that is added at the bottom of all pages of that category. So we could use
>the same principle for
>
>[[Category:Stub]]
>
>or
>
>[[Category:Deletion]]
>
>To have texts like
>
>''This aricle is a [[Wikipedia:stub article|stub]]. Please see
>[[:Category:Stub]] for a list of current stub articles.''
>
>or
>
>''This page has been marked for deletion. In order to debate its deletion,
>please use the discussion page.''
>
Much of this seems compatible to a suggestion that I made several months
ago:  To include a category box or boxes at the bottom of the edit page.
 At the time I also spoke in terms of a specific category scheme, which
some people felt would be just one more thing to learn before it could
be used effectively.  Although I would still favour that scheme there is
no reason why we can't (at least in the early stages of such an
initiative) have multiple overlapping schemes.   A which-is-better
debate about various possible schemes in the early stages could rapidly
lead to accomplishing absolutely nothing.  If multiple schemes are
allowed, usage and practice will over time determine what stays.
 Disused schemes will die by atrophy.

Whether there are many boxes at the end of an article, or one box with
comma delimited categories would make no difference to me.  Although I
would appreciate an option being available for case sensitive searches.

When I discussed this before I raised the possibility of an "XXX"
classification for possibly objectionable material.  Some responses at
the time felt that this was tantamount to applying censorship.  From my
perspective any censorship would only be applied at the home computer
level, and would give a parent the opportunity to block articles with
certain codes from being viewed by their children.  Providing this sort
of opportunity would at least give the public some confidence that we
are aware of the problems.

Erik's suggestion of categories to detect stubs or to mark an article
for deletion could fit in very well.  A simple search of category boxes
for the word stub could instantly creat a list of these.

As the project gets bigger indexing will become more problematical.
 Brute searches of the data base are not always the most satifactory.  A
biography of a famous person will most often not include the word
"biography" to be used as a search element.  Having an [[Index of ...]]
or [[List of ...]] article does not guarantee that everything that could
go on that list does go on it.

In Wiktionary we have seen a proliferation of index pages for multiple
languages.  I've had doubts from the beginning about whether this
approach would be viable in the long run.  It can be a lot of additional
work to insure that each article is properly indexed and linked, often
from places whose existence is completely unknown to the newcomer.  One
established contributor has taken to setting up a series of Wiktionary
articles withe the title format [[Polish word: foo]].  It would be a
whole lot simpler if the [[foo]] article could have a PL in it's index box.

Eclecticology


subject: [WikiEN-l] American diplomatic listings

body:
I notice a lot of pages of countries which reply on information from the CIA
factsbook include information US diplomatic representation to that country
and that country's diplomatic representation to the US. Two things strike
me:

1. That sort of information changes very quickly, much quicker than details
about who is in government, etc, because diplomatic postings are regularly
changed. So it is something that can very very easily be out of date even
when being put on wiki, or within a small time afterwards.

2. It hardly creates a fair and balanced article if its focuses exclusively
on issues to do with that country's diplomatic relationship with the US. Is
there a single article on wiki that mentions with the British ambassador is
to a country and what the UK embassy address is? What about the Italian
Ambassador? Brazilian ambassador? Irish ambassador? Rwandan ambassador, etc.
It all adds a regrettable and unnecessary degree of americo-centrism to
articles.

Given this fact, and that the information is likely to change rapidly, is it
not time that such unnecessary and americo-centrist information was left
out? The entire world doesn't need to know who the US ambassador to Germany
is, or who the Germany ambassador to the US is, do they?

If it is thought worth keeping, it should all be moved to a specific article
on [[United States Embassies and Ambassadors]] and [[International
Ambassadors to the United States]]. There it can be easily updated and
avoids making articles appear too americocentric.

JT

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


from_name: Erik Moeller

body:
Oliver-
> However, Erik's constraint that articles shouldn't be such that they will
> always remain stubs would probably disqualify it, if we accept his wish
> for articles to be 20,000 to 30,000 characters in length.

Let me rephrase my argument: A subject which cannot be covered in such
detail should not have its own article. It should not be merged into
another text if it can realistically grow to that size when relying on
verifiable information. I think you understood it this way, but I'm not
sure everyone else did.

The length itself is debatable, but I think most of us agree that we don't
want one-paragraph texts about every single fictional character out there.

Long articles have several advantages:
* A topic is kept in context, eliminating the need to write a separate
intro for each individual article
* It becomes easy to save, print and pass around an article covering all
relevant information
* We do not require the reader to click around unnecessarily, which can be
confusing to many people
* Should we decide on some major structural change or even a deletion, it
becomes easier to fix things
* The same goes for links: The less articles there are, the less double
redirects, the less links that need to be manually edited and so on
* A short average article length does not reflect well on our article
count, which is one of the key instruments used for size comparisons

The arguments against long articles:

Hard to edit:
One of the features on my personal wishlist is the ability to edit an
individual article section. If you have this preference enabled (should be
default for signed in users, off for anons) you get an "[edit]" link next
to each article section headline, and this individual section can be
loaded into the edit window. This makes it trivial to edit large articles.

No linkability to individual sections:
Supporting a [[foo#bar]] style syntax is not the problem. However, keeping
these links working is non-trivial. It might be desirable to only have
this label functionality for some sections, instead of automatically
turning every section title into a label.

Attention span:
This is a valid argument, but splitting up articles is not the solution:
instead of giving our reader easy access to the pertinent info, we now
hide it with the justification that it is "too much to read". The solution
is structure. Have a proper introduction with a decent summary, and put
every relevant piece of information into the right section. We could try
to develop guidelines for structuring articles in specific subject areas.

For some articles, splitting off specific points, e.g. long criticism
discussions, may be desirable to avoid detracting from the main substance
of the article. But this gets us into NPOV territory, and should be
discussed for each individual article.

Regards,

Erik


from_name: Richard Grevers

subject: [Wikitech-l] Unicode and polices

body:
On Tue, 27 May 2003 12:32:19 +0900, Guillaume Blanchard
<gblanchard at arcsy.co.jp> gave utterance to the following:

<older attribution for the >> was snipped by Guillaume>
>> So...perhaps I understood nothing, but do you think
>> Opera 5 is not accepting unicode because of missing
>> polices or does it just not tolerate it at all ?

>
> I think there are both problem. Even if your browser can handle unicode,
> you
> can't see caracters not defined in your font. I'm using MS Arial Unicode
> with IE6.0 and I still not be able to see 100% of unicode characters. In
> my
> case I think it's only a font problem. You can go to this page and look
> at
> what percentage of caracters you can see :
> http://www.columbia.edu/kermit/utf8.html (it's a UTF8 sample page).
>
Opera 5 has no unicode support - Opera 6 was the unicode rewrite.
Both Opera (6+) and Mozilla support unicode natively - the only thing you
have to do to get it working is to install an appropriate font.
However, even if you have the font, IE doesn't display some writing systems
until you "install support" by downloading a large patch to your operating
system. (A fully multilingual installation of IE6 weighs in at around 85MB)

--
Richard Grevers
I hate Victor Hugo said Les miserably


subject: [Wikipedia-l] Disambiguation detector

body:
Lee-
> I'm not convinced. I generally dislike the idea of automatic
> content of any kind--the content of Wikipedia should be created
> by human editors, and even disambiguation pages should each be
> crafted uniquely to suit the needs of the subject, not just stamped
> out of a template.

I agree regarding the disambiguation pages themselves. In general, we
should only use automatically generated/added content where it is at least
equivalent to text written by humans. Using this criterion:

1) The "Alternate meanings:" solution by Magnus is a good one, because
this is supposed to be a short line on individual articles that
complements the longer disambiguation page. There is no point in having
humans write and update this information, just as there is no point in
having humans write the "What links here" information.

2) Text blocks that do not change are currently written for each
inidividual page. On the main disambiguation pages, for en:, the following
text block is currently used:

''This is a [[wikipedia:disambiguation|disambiguation]] page; that is, one
that just points to other pages that might otherwise have the same name.
If you followed a link here, you might want to go back and fix that link
to point to the appropriate specific page.''

It may be useful to be able to transclude such text segments
([[>Wikipedia:Disambiguation]] or something like this). However, I am also
thinking about having these segments be inserted as part of a general
category scheme, such as

[[Category:Disambiguation page]]

Where that page would list all pages in that category, with automatic
paging and sorting, and allow editors to define a standard block of text
that is added at the bottom of all pages of that category. So we could use
the same principle for

[[Category:Stub]]

or

[[Category:Deletion]]

To have texts like

''This aricle is a [[Wikipedia:stub article|stub]]. Please see
[[:Category:Stub]] for a list of current stub articles.''

or

''This page has been marked for deletion. In order to debate its deletion,
please use the discussion page.''

Regards,

Erik


list: sifter-l

source: wayback-mbox

from_name: Efrain Lopez

subject: [Sifter-l] HOLLIE Loves You  efztfe l


subject: [Wikipedia-l] Disambiguation detector

body:
Kurt Jansson wrote:

> Ray Saintonge schrieb:
>
>> Erik Moeller wrote:
>
> >> However, I am
>
>>> also  thinking about having these segments be inserted as part of a
>>> general  category scheme, such as
>>>
>>> [[Category:Disambiguation page]]
>>
>> Much of this seems compatible to a suggestion that I made several
>> months ago:  To include a category box or boxes at the bottom of the
>> edit page.
>
>
> Magnus Manske schrieb:
>
> > For the disambiguation pages, I would imagine something as simple as a
> > "{{DISAMBIGUATION}}" variable
>
> Okay, this discussion is coming up again and again. I've said that I'm
> against putting more of this meta-information into the article text,
> but some people feel a pressing need for it. So how about adding an
> extra meta:-namespace were this information could be put in? So we
> could also get rid of the annoying interlanguage links on top of each
> article.
>
> This namespace could have some extra functionality like
> drop-down-boxes,  and some magic to *suggest* missing interlanguage
> links. And while I don't like the idea to have article ratings inside
> Wikipedia, but seem to be quite alone with this opinion, this could
> also be handled there.

To be perfectly clear, I am not saying that the category material should
be in the body of an article but in a completely separate box.  If that
fits in with your idea of a "meta-namespace" that's just fine.  The
interlanguage links have never bothered me, and I've always thought of
them more as a benefit than a problem.  However, in saying that I also
have to admit that I rarely use them.  Using drop down boxes for
interlanguage links would likely be just as effective.

I would also make a distinction between Interlanguage (IL) boxes, and
Index (IX) boxes.  IL boxes would involve links between pedias, so they
would need to be applied consistently in all the projects.  IX boxes
would address the requirements of a particular pedia, and its contents
could be fashioned to suit the needs of that community.  Wiktionary has
already developed many unique characteristics, so I am sure that it
would use IX boxes quite differently from the other projects.  It could
use the IL boxes to link to substantive articles arising from a word.

I suppose that some people mught interpret my proposal for XXX codings
as "ratings", but I also need to be clear that I think that dumbing down
an article in order to appeal to the most prudish elements in a society
does not have my support.  It will still be an individual human's choice
to put an XXX coding in an IX box, and I anticipate that there will be
edit wars over this kind of thing.

Eclecticology


from_name: Alfio Puglisi

subject: [Wikitech-l] Static html

body:
After some delays and bug-hunting my script for the HTML static versions
is in acceptable shape.

Here you can see an example, built from a SQL file of some weeks ago:
(Don't try the Search box!!! I explain below)

http://www.arcetri.astro.it/~puglisi/wiki/dump/ma/main_page.html

Please don't DOS the connection, it's not a very fast line.
Interested parties can find the script here:

http://www.arcetri.astro.it/~puglisi/wiki/wiki2static.txt

(renamed to .txt due to some server misconfig)
use a wide terminal for this one. Everything (html code included) is in
one single file. The whitespace may appear weird because I use 4-space
tabs.  There's no need to tell me you don't like the coding style, I
alread know :-)))

Some issues:

- the topbar links do not work (known bug :-). The Edit link goes to the
online wikipedia site.
- interlanguage links are ignored
- some wiki markup is not recognized yet.
- no images are present (of course!)
- filenames should be OK for most filesystems not "8.3" limited
  (max 63 chars, only a-z, 0-9 and underscore)

- despite the two-letter subdirectories, some of them have over 4,000
files in them!

- Time: the script takes more than 2 hours on my 1.3 Ghz Athlon...

- Size: this dump is about 800MB. (tar.gz is just 110MB). I think
that I can bring it down to 600-650MB with a bit of trimming and
eliminating unnecessary redirects.  BUT, without some form of compression,
the English wikipedia will soon overflow a single CD. Maybe we should
target DVDs? :-)

- Images: no images are present here. AFAIK, each of them has a SQL record
(that my script skips), but the actual image data is not included. How
many megabytes of images we have? I think it will be impossible to store
the full images on a CD. Certainly it's possible on a DVD. Maybe a low-res
version could be included in a CD.

- Search: I tried a javascript search that worked well for small sized
databases: it's basically a big array of strings (article titles and
filenames) with some lines code that do a regexp match against them.
For full-sized databases like this one, the search page becomes an 8
megabytes monster that takes forever to process (IE grabs 100 MB of memory
and stops there, Opera is even worse). I'll see if I can find a different
solution.

Enough for now. While I carry on development, any input is welcome.

Ciao,
Alfio


subject: [Wikipedia-l] Disambiguation detector

body:
Lee Daniel Crocker wrote:
> Another issue is performance. Perhaps we could help both of those
> issues by making a single link to a list page rather than a set of
> links. But what to call that list is tricky. Is isn't really "related
> pages" because they're only related lexigographically, not semantically.
> Perhaps it could be something like "Other 'Foo' pages".

But this link should only appear if there really are other "foo" pages,
right? So, we'd have to run a SQL query anyway.

One special case I could think of is that there are a lot of matching
pages (like the mentioned "USS *" pages). The "Other 'foo' pages" link
cuold go into effect if there are more than, say, seven other 'foo'
pages. I'm not sure if the trouble of setting up Yet Another Special
Page (tm) will pay off considering the expected short number of such
pages (I think at the test wiki, with all the 'A' articles, "Atlas" and
variants hit the top, with five pages or so, one of them a REDIRECT).

The feature was *not* intended to replace the disambiguation pages. It
started off when someone mentioned he'd like to see for a page "foo
(bar)" if there's a page "foo" (which is often enough not the case, at
least on the German wikipedia).

For the disambiguation pages, I would imagine something as simple as a
"{{DISAMBIGUATION}}" variable, which would
* add all the "foo (bar)" pages on a "foo" or "foo (disambiguation)" page
* add the disambiguation disclaimer

But that's another story :-)

Magnus


from_name: cprompt

subject: [WikiEN-l] A request from H. Jonat

body:
james duffy wrote:

>> james duffy wrote:
>> > I agree. People need to be able to discuss matters openly and
>> frankly. It
>> > really is nobody else's business but the people on the mailing list
>> what is
>> > said on that list.
>>
>> Well, I don't agree at all.  Wikipedia is a transparent public
>> project, what we do is all out in the open for anyone to see.
>>
>> Sunshine is the best disinfectant.
>
> Communication on this list should only be available (a) through a
> carefully restricted means (eg, through being a contributor to
> wikipedia), not simply through a google search, and (b) perhaps with
> some time delay mechanism. There is, for example, a US Democratic
> Party political consultant called James Duffy, a soccer manager called
> James Duffy and a number of others. What happens if someone does a
> google search, finds attacks made on me under the name of this email
> account and presumes it was some other 'James Duffy', one with a
> public profile. That is why organisations 'always' provide restricted
> access to discussions such as those here, usually with a time delay
> mechanism. They universally find that unrestricted access blocks free
> discussion  and prevents, not encourages, free speech.

Many organizations also restrict what parts of their website can be
edited, if any. They restrict access to their services to those without
an account, and they verify accounts. Personally though, I think some
protection should be offered against "ego surfing" where information on
a person from the list is indexed in Google. This can still be an open
and transparent public project with a fully searchable mailing list
archive. I think that anyone should be able to search the archive only
after clicking an appropriate link on Wikipedia.org.


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

Neil Harris wrote:
| Lee Daniel Crocker wrote:
|>
|> My current favorite suggestion is that second-level headings (H2)
|> should automatically become link targets.
|>
| I agree; this is the "obvious right thing" to do, in my opinion. We can
| now argue about whether we should support references for these anchors
| as [[article#fragment-text]], which also seems to be the "obvious thing" ?
|
| What I can't decide is how I think these links should render into the
| page -- perhaps as  "article; fragment-text"?

Another question immediately arises: how should a broken link be
rendered? What HTML is generated by [[article#subhead]], if "article"
exists but does not contain "subhead"?

- --
~ Sean Barrett     | Some of you may not return...
~ sean at epoptic.com | the rest of you definitely won't.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+1lm4v/8xpnvE6M8RAuTiAJ9J48LhzobIlX02xMKsP78djGL10gCgtwVs
MfRNWOdyCPDRWGJVyygOGVI=
=za64
-----END PGP SIGNATURE-----


subject: [WikiEN-l] American diplomatic listings

body:
On Wed, 28 May 2003, Brion Vibber wrote:

> Je Merkredo 28 Majo 2003 20:53, james duffy skribis:
> > I notice a lot of pages of countries which reply on information from
> > the CIA factsbook include information US diplomatic representation to
> > that country and that country's diplomatic representation to the US.
>
> There was discussion on talk pages (I don't remember where) sometime
> last year in which it was agreed to take those out. Presumably they
> didn't all get done at the time; if you see more, please fix them up.

No way! There is no reason why information on diplomatic representation
should be taken out of the Wikipedia. Of course we shouldn't have just
that relating to the US, but we should have it for all countries. Clearly
this can't all go in main country articles, because it would become
unwieldy, but it should be moved to pages specifically about diplomatic
representation.

[[Ambassadors from the United States]] and [[Ambassadors to the United
States]] are quite likely the pages you want. The latter doesn't exist
yet, and both may need renaming, but there is no reason why they could not
hold the information in question. There is no reason to remove such
information altogether.

Oliver

+-------------------------------------------+
| Oliver Pereira                            |
| Dept. of Electronics and Computer Science |
| University of Southampton                 |
| omp199 at ecs.soton.ac.uk                    |
+-------------------------------------------+


subject: [WikiEN-l] Re: Alternative to Blanking Pages

body:
a.crossman at blueyonder.co.uk wrote:

>>If no one else would like to undertake the task of
>>writing out the boilerplate texts, I'll add it to my todo list.
>>
>>--cprompt
>>
>>
>
>Hmm, I've still not seen an answer to the problem I raised - links to
>blanked pages will no longer be coloured as stubs. This isn't a small
>problem, I feel...
>
>It might be OK if in all cases the page was going to be either
>deleted or turned into an actual stub - but can you guarantee this?
>
>Evercat
>
>
Do you mean that the links won't appear as though there was no article
created for them? If so, well, that's one of the problems with pages
that have just been blanked; they link just like regular articles, and
are indexed just like regular articles. I think it should be considered
the responsibility of the person who blanks a page (or redirects to
boilerplate) to ensure that it doesn't remain in that state. If they are
not a sysop, they should list the page on votes for deletion, or they
should try to make their own stub or article (or find someone who can).

--

--cprompt


from_name: Dante Alighieri

subject: [WikiEN-l] Michael and hard ban

body:
This is an open request, but it is specifically aimed at Jimbo. Can we have
a clear and definitive answer on Michael and his pseudonyms and his/their
ban status? Also, can this be posted on the Wikipedia so that it can be
easily linked to? The current situation requires that we direct people to
Michael's ban talk page and that they then link to the No-Fx page and the
Weezer pages. I am, as are others, spending too much time defending our
actions when we delete Michael's garbage. Thanks.

-----

Dante Alighieri
dalighieri at digitalgrapefruit.com

"The darkest places in hell are reserved for those who maintain their
neutrality in times of great moral crisis."
    -Dante Alighieri, 1265-1321
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030529/d2081878/attachment.htm


from_name: a.crossman at blueyonder.co.uk

body:
> If no one else would like to undertake the task of
> writing out the boilerplate texts, I'll add it to my todo list.
>
> --cprompt

Hmm, I've still not seen an answer to the problem I raised - links to
blanked pages will no longer be coloured as stubs. This isn't a small
problem, I feel...

It might be OK if in all cases the page was going to be either
deleted or turned into an actual stub - but can you guarantee this?

Evercat
--
Allan Crossman
a.crossman at blueyonder.co.uk
http://dogma.pwp.blueyonder.co.uk


from_name: Anthere

subject: [WikiEN-l] A request from H. Jonat

body:
--- james duffy <jtdirl at hotmail.com> wrote:
> Zoe wrote
> >I really think that the mailing list pages should
> be
> >blocked from search engines.
>
> I agree. People need to be able to discuss matters
> openly and frankly. It
> really is nobody else's business but the people on
> the mailing list what is
> said on that list. Other email conversations aren't
> accessible generally.
> Why should this mailing list be available? Many
> people don't realise that
> what they say on the mailing list isn't private and
> if they did might simply
> opt out of it.
>
> JT

Well...in case they did not know, now they do.
Nothing said here is private.
Nothing said on talk page is private either :-)

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com


from_name: Kurt Jansson

subject: [Wikipedia-l] Disambiguation detector

body:
Ray Saintonge schrieb:
> Erik Moeller wrote:
 >> However, I am
>> also  thinking about having these segments be inserted as part of a
>> general  category scheme, such as
>>
>> [[Category:Disambiguation page]]

> Much of this seems compatible to a suggestion that I made several months
> ago:  To include a category box or boxes at the bottom of the edit page.

Magnus Manske schrieb:

 > For the disambiguation pages, I would imagine something as simple as a
 > "{{DISAMBIGUATION}}" variable

Okay, this discussion is coming up again and again. I've said that I'm
against putting more of this meta-information into the article text, but
some people feel a pressing need for it. So how about adding an extra
meta:-namespace were this information could be put in? So we could also
get rid of the annoying interlanguage links on top of each article.

This namespace could have some extra functionality like drop-down-boxes,
  and some magic to *suggest* missing interlanguage links. And while I
don't like the idea to have article ratings inside Wikipedia, but seem
to be quite alone with this opinion, this could also be handled there.

Kurt


from_name: Lee Daniel Crocker

body:
>| What I can't decide is how I think these links should render into the
>| page -- perhaps as  "article; fragment-text"?
>
> Another question immediately arises: how should a broken link be
> rendered? What HTML is generated by [[article#subhead]], if "article"
> exists but does not contain "subhead"?

The latter question is really a no-brainer: the link is generated
containing the fragment identifier, and is marked as broken or not
solely based on whether or not the page exists. Browsers routinely
accept links to non-existent fragments and just silently drop the
fragment, going to the page.

The question of whether or not to include the fragment id in the
default text is really one of style; I'm inclined to just drop it.

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


subject: [WikiEN-l] A request from H. Jonat

body:
--- james duffy <jtdirl at hotmail.com> wrote:
 I
> myself was accused of being like a holocaust denier
> here once. Luckily this
> email account doesn't give my real name, but if it
> did, that wild accusation
> could show up against me in a google search if for
> example in next year's
> Irish local elections I agreed to run for office as
> I have been asked. Or if
> ran in the next Irish general election in 2007. If
> there was the slightest
> chance that that wild claim or others could be found
> if someone did a google
> search under my real name, I would be gone from the
> list (and probably from
> wikipedia) like a shot.

Err...I think that any person running for any election
should be ready to face these types of accusations
anyway. That often ends up in front of tribunal.

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com


subject: [Wikipedia-l] Disambiguation detector

body:
Magnus Manske wrote:

>Lee Daniel Crocker wrote:

>>Another issue is performance. Perhaps we could help both of those
>>issues by making a single link to a list page rather than a set of
>>links. But what to call that list is tricky. Is isn't really "related
>>pages" because they're only related lexigographically, not semantically.
>>Perhaps it could be something like "Other 'Foo' pages".

>One special case I could think of is that there are a lot of matching
>pages (like the mentioned "USS *" pages). The "Other 'foo' pages" link
>cuold go into effect if there are more than, say, seven other 'foo'
>pages. I'm not sure if the trouble of setting up Yet Another Special
>Page (tm) will pay off considering the expected short number of such
>pages (I think at the test wiki, with all the 'A' articles, "Atlas" and
>variants hit the top, with five pages or so, one of them a REDIRECT).

But Yet Another Special Page would be precisely wrong.
It would function like a disambiguation page,
but one not written by a human and featuring only a list.
If we direct people to a special page through "Other 'Foo' pages",
then that really should link to [[Foo (disambiguation)]].
As you say:

>The feature was *not* intended to replace the disambiguation pages.

-- Toby


from_name: Fred Bauder

subject: [WikiEN-l] A request from H. Jonat

body:
> From: "james duffy" <jtdirl at hotmail.com>
> Reply-To: wikien-l at wikipedia.org
> Date: Thu, 29 May 2003 22:02:32 +0100
> To: wikien-l at wikipedia.org
> Subject: Re: [WikiEN-l] A request from H. Jonat

> I have clashed with Fred Bauder, but Fred does not deserve to have the
> following on google, which comes via a different dispute he was involved in:
>
> [WikiEN-l] [FB] and academic dishonesty
> [WikiEN-l] [FB] and academic dishonesty wikien-l at wikipedia.org
> Thu, 20 Mar 2003 18:08:18 -0700: Previous message ...
>
> (I have removed Fred's name from the above so as not to create another link
> to that claim!)
>
> These are just from a couple of quick google searches I did at random.
>
> In view of this, I would suggest:
>
> 1. That the list NOT be available to check on google or any search engine.
> 2. That users be discouraged from using their own name. If they don't have a
> nickname, initials or an unusual spelling of their name should be used.
> 3. We should not use a person's in the title of any messages on the list.
>
> JT

I agree with Jimbo that an open, generally available to the public is a part
of what Wikipedia is about. Perhaps folks need to know when they jump in
that the messages are googled, that could be in a mailing list FAQ. Using
folks name in the title of any message, well like RK, when we do that we are
usually pretty excited. That might be the better rule. Never post when you
are all worked up.

People, like myself, who use their full name in the open on the internet
have usually thought about it first and accept the consequences. I've been
doing it for years and no harm yet. I get 400 hits on exact name, granted
the cited one is #2 but that will pass. I live in a gossipy little small
town anyway.

Fred


from_name: limholt at excite.com

body:
Lee Daniel Crocker < lee at piclab.com > wrote:

The use of...

> fragment id in the default text is really one of style; I'm inclined to > just drop it.

My choice would be to display Article: fragment, but always use the existing convention that if the Wikipedian write a display to use that. So the display makes sense if written as [[Article:fragment|Displayed link]].

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


from_name: rose.parks at att.net

subject: [Wikitech-l] Unicode and polices...Have you tried this?

body:
Hi,

     I just got a new computer with Windows XP. I, also, was wondering where
the old "Input Methods" for foreign languages were.
     If you run IE6 and right click on any web page, you will get a drop down
menu with "encoding" as an entry. Follow the arrow to a long list of encodings.
In my case, I chose Japanese and it was installed on demand, in under a
minute. Then I left "Encoding" set to "Autoselect."
     If you are aware of this already, apologies...

                 As Ever,

                      Ruth Ifcher

--

> On Tue, 27 May 2003 12:32:19 +0900, Guillaume Blanchard
> <gblanchard at arcsy.co.jp> gave utterance to the following:
>
> <older attribution for the >> was snipped by Guillaume>
> >> So...perhaps I understood nothing, but do you think
> >> Opera 5 is not accepting unicode because of missing
> >> polices or does it just not tolerate it at all ?
>
> >
> > I think there are both problem. Even if your browser can handle unicode,
> > you
> > can't see caracters not defined in your font. I'm using MS Arial Unicode
> > with IE6.0 and I still not be able to see 100% of unicode characters. In
> > my
> > case I think it's only a font problem. You can go to this page and look
> > at
> > what percentage of caracters you can see :
> > http://www.columbia.edu/kermit/utf8.html (it's a UTF8 sample page).
> >
> Opera 5 has no unicode support - Opera 6 was the unicode rewrite.
> Both Opera (6+) and Mozilla support unicode natively - the only thing you
> have to do to get it working is to install an appropriate font.

> However, even if you have the font, IE doesn't display some writing systems
> until you "install support" by downloading a large patch to your operating
> system. (A fully multilingual installation of IE6 weighs in at around 85MB)
>
> --
> Richard Grevers
> I hate Victor Hugo said Les miserably
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikitech-l


body:
Erik Moeller wrote in part:

>Long articles have several advantages:
>* The same goes for links: The less articles there are, the less double
>redirects, the less links that need to be manually edited and so on

Actually, I think that long articles will cause more redirects.
Consider [[en:Neighbourhood (topology)]].
Since the only material on this topic is a short definition,
it has no proper article but is listed on [[Topology glossary]].
So [[Neighbourhood (topology)]] redirects to [[Topology glossary]].

But what about [[Neighorhood (topology)]] (with the US spelling)?
If I hadn't created this redirect as well,
then somebody else might have come along (following a red link),
redirected the alternate spelling to [[Neighbourhood (topology)]],
seen (from the resulting blue link) that this page did indeed exist,
but didn't look at it to discover that it was just a redirect.

Also, when [[Topology Glossary]] was moved to [[Topology glossary]],
a whole bunch of double redirects were created -- two examples above.

Despite all of this, I *don't* think that [[Neighbourhood (topology)]]
should be separated out.  Not because a long article couldn't be written
(it could, and I intend to write one when I get around to it,
as I intend to write articles on every term in that glossary),
but because the article would be only a single sentence *now*.
I think that your 20KB suggestion is too long for a minimum size,
like others here, but I do basically agree with your main point.
I write this to emphasise that everybody -- in this situation and others --
should take time out to think about redirects
and how the actions that we take may impact them or require them.

-- Toby


from_name: Zoe

subject: [WikiEN-l] American diplomatic listings

body:
--- james duffy <jtdirl at hotmail.com> wrote:
>>Is
> there a single article on wiki that mentions with
> the British ambassador is
> to a country and what the UK embassy address is?
> What about the Italian
> Ambassador? Brazilian ambassador? Irish ambassador?
> Rwandan ambassador, etc.
> It all adds a regrettable and unnecessary degree of
> americo-centrism to
> articles.

We keep having this discussion and I keep asking why
we would rather delete something that discusses
America instead of adding something that discusses
other countries, but I already know the answer to
that, so there's no point in my even bringing it up
again.

There is an article whose name escapes me which has a
list of all of the ambassadors from other countries to
Canada.

Zoe

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com


subject: [WikiEN-l] American diplomatic listings

body:
Gee, how difficult was that? :)  The article I was
talking about is [[List of Ambassadors to Canada]]

Zoe

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com


from_name: Neil Harris

body:
Lee Daniel Crocker wrote:

>>(Karl Eichwalder <ke at gnu.franken.de>):
>>
>>Also, "fragment links" are not supported, you know, these
>>"http://example/page.html#fragment" pointers.
>>
>>
>
>Actually they are; have been for a long time. But the ability to
>make the link _target_ has been disabled until we can agree on a
>better syntax for it.
>
>My current favorite suggestion is that second-level headings (H2)
>should automatically become link targets.
>
>
>
I agree; this is the "obvious right thing" to do, in my opinion. We can
now argue about whether we should support references for these anchors
as [[article#fragment-text]], which also seems to be the "obvious thing" ?

What I can't decide is how I think these links should render into the
page -- perhaps as  "article; fragment-text"?

-- Neil


body:
a.crossman at blueyonder.co.uk wrote:

>cprompt writes:
>
>
>
>>Do you mean that the links won't appear as though there was no
>>article created for them?
>>
>>
>
>No, that's not what I mean. If you go to your preferences, you'll see
>a field called "threshold for stub display". Enter a value into it.
>All links to articles (not counting redirects) that have less than
>that many characters will be rendered in a different colour. This is
>very useful, and plans to create boilerplate text to put in blanked
>pages will undermine its usefulness somewhat.
>
Hmm...I see what you mean. Well, I'm not really sure what to do about
that one...

--

--cprompt


from_name: daniwo59 at aol.com

subject: [WikiEN-l] American diplomatic listings

body:
In a message dated 5/29/2003 7:36:34 PM Eastern Standard Time,
zoecomnena at yahoo.com writes:

> There is an article whose name escapes me which has a
> list of all of the ambassadors from other countries to
> Canada.
>

A long while ago, there was an article listing something like British
ambassadors to Kazakhstan.

Danny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030529/8533c39a/attachment.htm


body:
cprompt writes:

>Do you mean that the links won't appear as though there was no
>article created for them?

No, that's not what I mean. If you go to your preferences, you'll see
a field called "threshold for stub display". Enter a value into it.
All links to articles (not counting redirects) that have less than
that many characters will be rendered in a different colour. This is
very useful, and plans to create boilerplate text to put in blanked
pages will undermine its usefulness somewhat.

--
Allan Crossman
a.crossman at blueyonder.co.uk
http://dogma.pwp.blueyonder.co.uk


from_name: Brion Vibber

subject: [Wikitech-l] Static html

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

Je ?a?do 29 Majo 2003 02:15, Alfio Puglisi skribis:
> - Images: no images are present here. AFAIK, each of them has a SQL
> record (that my script skips), but the actual image data is not
> included.

Many images uploaded to Wikipedia are third-parties' copyrighted IP
being used under the vague claim of "fair use". The project has not yet
received legal advice about whether such materials can be redistributed
under the terms of the GFDL; until that's resolved I at least have no
intention of putting them all in one easy download, for which a
significant use would be reuse and redistribution by people like
yourself trying to reuse Wikipedia material.

IIRC the last word from Jimbo on the subject was:
http://mail.wikipedia.org/pipermail/wikipedia-l/2002-November/007880.html

I know several prominent Wikipedians don't seem to care about this, but
I think staying true to our all-reusable-all-redistributable license is
a very important aspect of maintaining Wikipedia's credibility and
fulfilling the project's goals. It may not always be _expedient_, but
then copying every article straight out of EB or World Book or Encarta
would have been a very expedient way to build an encyclopedia, and
cracking Windows XP activation codes and binary search-and-replacing
'(c) Microsoft' to 'Copyleft GPL' would be a very expedient way to put
out a free operating system. :P

> How many megabytes of images we have?

On the English wikipedia, the upload tree contains about 437 megs at
present not counting older replaced revisions of files. I'm not sure
what portion are actually used or needed; and some portion of that is
non-image material (sound clips, etc).

- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+1uJ+xVlOmwh1xjgRAtdRAJsFoTquEj2JX1snahmX62vLP/oIOgCdH4v+
+KFGEdqBjKAO2PmHrpjdYa0=
=EyF4
-----END PGP SIGNATURE-----


from_name: Erik Zachte

subject: [Wikitech-l] RE: Unicode and polices...Have you tried this?

body:
>> If you run IE6 and right click on any web page, you will get a drop
down menu with "encoding" as an entry. Follow the arrow to a long list
of encodings. In my case, I chose Japanese and it was installed on
demand, in under a minute. Then I left "Encoding" set to "Autoselect."
<<

I tried this but it did not work for me. I remember that when I
installed XP and then ran the 'Windows Update' wizard I clicked 'Remove'
for all foreign language packages (a little short sighted, looking
back). Maybe this explains why. Could not find how to undo this.

There is also a "Enable Install On Demand (Explorer)" checkbox in
Explorer -> Options -> Advanced. (unchecked by default, or because of my
actions above). Enabling this did not help me either.

Finally I found a link in the Wikipedia to "Alan Wood's Unicode
Resources": "http://www.alanwood.net/unicode/ Lots of info and useful
links there.

He tells that Microsoft has some very complete TrueType fonts. They are
only shipped with MS Office. I copied the Arial unicode font
(Arialuni.ttf, 24 Mb) from another machine running Office and all was
well.

Erik Zachte


subject: [WikiEN-l] American diplomatic listings

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

Je ?a?do 29 Majo 2003 17:34, Zoe skribis:
> We keep having this discussion and I keep asking why
> we would rather delete something that discusses
> America instead of adding something that discusses
> other countries, but I already know the answer to
> that, so there's no point in my even bringing it up
> again.

Because it's not very informative, changes with little notice (therefore
will likely not be maintained well), and would probably be better
served by linking to the embassies' home pages which will have more
information?

- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+1uO0xVlOmwh1xjgRAlKGAJ9cVa3fl/rObWUU9JCpKrXv2fSeXwCfUKJO
W8Lp7wTncVTuR0yILAXMGhw=
=rFMz
-----END PGP SIGNATURE-----


from_name: james duffy

subject: [WikiEN-l] A request from H. Jonat

body:
>cprompt wrote

>Many organizations also restrict what parts of their website can be edited,
>if any. They restrict access to their services to those without an account,
>and they verify accounts. Personally though, I think some protection should
>be offered against "ego surfing" where information on a person from the
>list is indexed in Google. This can still be an open and transparent public
>project with a fully searchable mailing list archive. I think that anyone
>should be able to search the archive only after clicking an appropriate
>link on Wikipedia.org.
>
Here's a practical example. We have all being condemning Lir. That could
rebound on Adam (I won't use his full name here so as not to provide another
link to his name!) But how many of his 'names' on wiki are also the names of
real people. For example, if there is someone called Vera Cruz, they might
not be happy to find the following on google:

[WikiEN-l] vera cruz is a troll
... WikiEN-l] vera cruz is a troll; ...  |From: Oliver Pereira
<omp199 at ecs.soton.ac.uk> |X-ECS-MailScanner:
Found to be clean |Sender: wikien-l-admin at wikipedia.org |Reply ...

I have clashed with Fred Bauder, but Fred does not deserve to have the
following on google, which comes via a different dispute he was involved in:

[WikiEN-l] [FB] and academic dishonesty
[WikiEN-l] [FB] and academic dishonesty. Fred Bauder wikien-l at wikipedia.org
Thu, 20 Mar 2003 18:08:18 -0700: Previous message ...

(I have removed Fred's name from the above so as not to create another link
to that claim!)

These are just from a couple of quick google searches I did at random.

In view of this, I would suggest:

1. That the list NOT be available to check on google or any search engine.
2. That users be discouraged from using their own name. If they don't have a
nickname, initials or an unusual spelling of their name should be used.
3. We should not use a person's in the title of any messages on the list.

JT

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail


from_name: rednblack at alum.mit.edu

subject: [WikiEN-l] Advertising for website by anonymous user 24.132.158.131

body:
An anonymous user has inserted the following text into basically every article
relating to gay film:

"[http://www.aboutgaymovies.info/ About Gay Movies] for information about gay
themed movies and TV series."

Or, sometimes:

"[http://www.aboutgaymovies.info/ About Gay Movies]: Information about gay
themed movies & tv-series. Also gay movie history, wallpapers, glbt
filmfestivals, sweepstakes and more."

This is essentially an effort to advertise for a (mediocre) website. I think
this is a bad idea, and we should discourage it, and maybe make some formal
proviso against it.

The user has contributed what appears at first glance to be some good content
([[Chubby culture]]), but at second glance it's just the [[Bear community]]
article s///d into an article on chubbies. Dunno what to think of that, but
anyway..

Saurabh

http://www.wikipedia.org/w/wiki.phtml?title=Special:Contributions&target=24.132.158.131

------
The great lesson of history is that knowledge develops through the conflict of
viewpoints... a consensus view... severely stultifies; it fails to see the
problems of that consensus and it depends on the existence of critics to break
up that iceberg and permit knowledge to develop. -- Walter Gilbert


subject: [Wikitech-l] Static html

body:
> (Brion Vibber <brion at pobox.com>):
>
> Many images uploaded to Wikipedia are third-parties' copyrighted IP
> being used under the vague claim of "fair use". The project has not yet
> received legal advice about whether such materials can be redistributed
> under the terms of the GFDL; until that's resolved I at least have no
> intention of putting them all in one easy download, for which a
> significant use would be reuse and redistribution by people like
> yourself trying to reuse Wikipedia material.

I don't think there's anything unresolved; clearly we CAN'T redistribute
copyrighted photos under GFDL. But the issue of whether or not we can use
them in Wikipedia is more complicated.  The supply of good public domain
photos is negligible, and the usefulness of photos to an encyclopedia is
critical enough to justify some hassle. So if copyrighted images, used with
permission or under fair use, are attached to Wikipedia articles, and it is
likely that most if not all redistributions of the Wikipedia would also
qualify for the same fair use, I think that's a reasonable second choice,
so long as (1) every image so used _is clearly identified_ as such, and
has clear documentation of its source.

Images from unknown sources should certainly be removed, and any images
that can be replaced with real GFDL images should be. Likewise, if we do
any static mirror of Wikipedia, I think it's important that it retain
(or point to) the image description pages that identify the source of
each image and its status.

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


from_name: Erik Moeller

subject: [Wikitech-l] 3 new InterWiki prefixes

body:
I have added

*PageHistory
*UserContributions
*BackLinks

InterWiki prefixes, because we currently do not support parameters in the
[[Special:]] namespace, and this was the lazy way to provide a much needed
quickfix. Among other things, this allows us to put

#REDIRECT [[UserContributions:Username]]

on the user page of a known vandal, making it easier to fix his edits from
RC.

As you might expect, these InterWiki links point to en:. I pondered
picking a name like EnHistory, EnContris etc., but I wanted something
intuitive. If other languages want the same functionality, prefixes like
"SeitenHistorie","BenutzerBeitraege" and "LinksAuf" can be easily added
(i.e. local equivalents).

Note that if we change the functionality of [[Special:]], things like
[[Special:MovePage->nul|Click here]] also become possible unless we
specifically forbid them.

Regards,

Erik


subject: [Wikitech-l] RE: Static html

body:
Hi Alfio,

I looked at your code. Nice job.

Superficially it may seem we did almost the same job.
But overlap is minimal. My perl script addresses a lot of issues that
only are relevant in a Palm/Pocket PC/TomeRaider environment.

Your version has quite some code which is specific for a static html
version.

Still there are some areas where we can be of help to each other.
You mentioned unicode support as an open issue. Conincidentally I was
looking into this issue the past few days, while preparing a TomeRaider
version of the Esperanto Wikipedia, which would be unreadable without
it.

You will also find the UTF-8 coding scheme on which this is based below.

Here is some Perl code to translate unicode multicharacter byte
sequences into html tags of type &#nnn;

# unicode -> html character codes &#nnnn;
$entry =~ s/([\x80-\xFF]+)/&UnicodeToHtml($1)/ge ;

sub UnicodeToHtml
{
  my $text  = shift ;
  my $html = "" ;
  my $c, $byte, $ord, $unicode, $bytes, $html ;
  for ($c = 0 ; $c < length ($text) ; $c++)
  {
    $byte = substr ($text,$c,1) ; # optimize with regexp ?
    $ord = ord ($byte) ;
    if ($ord < 128)      # plain ascii character
    { $html .= $byte ; } # (will not occur in this script)
    else
    {
      if ($ord < 224)
      { $bytes = 2 ; }
      elsif ($ord < 240)
      { $bytes = 3 ; }
      elsif ($ord < 248)
      { $bytes = 4 ; }
      elsif ($ord < 252)
      { $bytes = 5 ; }
      else
      { $bytes = 6 ; }
      $unicode = substr ($text,$c,$bytes) ;
      $html .= &UnicodeToHtmlTag ($unicode) ;
      $c += $bytes - 1 ;
    }
  }
  return ($html) ;
}

sub UnicodeToHtmlTag
{
  my $unicode = shift ;
  my $char = substr ($unicode,0,1) ;
  my $ord = ord ($char) ;
  my $c, $ord, $value ;

  if ($ord < 128)         # plain ascii character
  { return ($unicode) ; } # (will not occur in this script)
  else
  {
    if ($ord >= 252)
    { $value = $ord - 252 ; }
    elsif ($ord >= 248)
    { $value = $ord - 248 ; }
    elsif ($ord >= 240)
    { $value = $ord - 240 ; }
    elsif ($ord >= 224)
    { $value = $ord - 222 ; }
    else
    { $value = $ord - 192 ; }
    for ($c = 1 ; $c < length ($unicode) ; $c++)
    { $value = $value * 64 + ord (substr ($unicode, $c,1)) - 128 ; }
    return ("\&\#" . $value . ";") ;
  }
}

Found this somewhere on the web:

#UTF-8 works as follows:
#ENCODING
#       The following byte sequences are used to represent a char-
#       acter. The sequence to be used depends  on  the  UCS  code
#       number of the character:
#       0x00000000 - 0x0000007F:
#           0xxxxxxx
#
#       0x00000080 - 0x000007FF:
#           110xxxxx 10xxxxxx
#
#       0x00000800 - 0x0000FFFF:
#           1110xxxx 10xxxxxx 10xxxxxx
#
#       0x00010000 - 0x001FFFFF:
#           11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
#
#       0x00200000 - 0x03FFFFFF:
#           111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
#
#       0x04000000 - 0x7FFFFFFF:
#           1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
#
#       The  xxx  bit  positions  are  filled with the bits of the
#       character code number in binary representation.  Only  the
#       shortest  possible  multibyte sequence which can represent
#       the code number of the character can be used.

By the way I enjoyed your contribution about Ant Power.

If you have any questions or suggestions you can reach me at
xxx at chello.nl
!spam: read xxx as epzachte

Cheers, Erik Zachte


subject: [WikiEN-l] American diplomatic listings

body:
>Zoe wrote

>We keep having this discussion and I keep asking why
>we would rather delete something that discusses
>America instead of adding something that discusses
>other countries, but I already know the answer to
>that, so there's no point in my even bringing it up
>again.

I never said to delete them. I said to move them. It is utterly impractical
to keep them there because

1. Many states have over 100 ambassadors accredited to them. There is no way
we could get all that information, place all that information and not simply
end up with pages that have 5% of the space given over to the country about
which the page is concerned and 95% devoted to a list of ambassadors to and
from that country.

2. That information changes regularly. It would be almost impossible to keep
all the pages up to date.

3. Why should the rest of the world have to chase around tracking down
detailed information to try to balance out the americocentism of an article
when that americocentrism shouldn't be there in the first place?

A far better solution should be to remove this information from those pages,
where it should not be in the first place - making them americocentrist is
hardly NPOV!). Brion already has said that wiki policy is that that
information should not be there. It should either be moved to a special page
devoted to US diplomatic representation, or cut out entirely. But as it is
against wiki policy to have that stuff there and it breaks NPOV rules, these
entries have to be removed. Where they are removed to is simply the issue.

JT

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


from_name: Daniel Ehrenberg

subject: [WikiEN-l] American diplomatic listings

body:
Brion Vibber <brion at pobox.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Je ??a?do 29 Majo 2003 17:34, Zoe skribis:
> We keep having this discussion and I keep asking why
> we would rather delete something that discusses
> America instead of adding something that discusses
> other countries, but I already know the answer to
> that, so there's no point in my even bringing it up
> again.

Because it's not very informative, changes with little notice (therefore
will likely not be maintained well), and would probably be better
served by linking to the embassies' home pages which will have more
information?

I still think it's bad to delete npov content, even if it's incomplete.

--littleDan

---------------------------------
Do you Yahoo!?
Free online calendar with sync to Outlook(TM).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030530/11011794/attachment.htm