subject:
[WikiEN-l] Re: Mintguy is an ad-hominem,	British Upper Class
	POV revert war monger

body:
Kenneth Alan wrote:

>Sorry about the long line of writing.  I thought the wrap-around features work at the mailing list.  I hope this one comes out right.
>
>
>>From: <coxcustomer3 at cox.net>
>>Date: 2004/08/13 Fri AM 05:37:51 EDT
>>To: <wikien-l at Wikipedia.org>
>>Subject: Mintguy is an ad-hominem, British Upper Class POV revert war monger
>>
>>I can't ever get a word in without him getting on my case.  Mintguy has this stuffy, toffee-nosed, Upper Class, British POV, Canonical Fascism about every article and doesn't allow for American contributions on British and British related topics by me, although it was beginning to spill into other articles including American that I contributed to in his quest to stamp me out and erase my efforts to Wikipedia.  He vandalised my User Talk Page and banned my IP address in the midst of a revert war in which he facilitated a prejudicial and ad hominem, mass revert spree towards my contributions without excuse by any discussion, despite my message to him on his talk page for a reason of his and a warning against such behaviours. - Kenneth Alan
>>
>>
>>
The flipside:
http://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Kenneth_Alan


list: wikien-l

source: pipermail-mbox

from_name: Charles Matthews

subject:
[WikiEN-l] Mintguy is an ad-hominem,
	British Upper Class POV revert war monger

body:
Kenneth Alan wrote

> I can't ever get a word in without him getting on my case.

Looks like both of you were out of order with the reverts on [[Yorkshire]].
However, the quality of your edits does seem suspect ('it's' for 'its',
spelling, punctuation and so on).  Without knowing what's behind the bad
feeling, I can't say much more.

Charles

PS Oh yes, I'm British too ...


from_name: Kenneth Alan

subject:
[WikiEN-l] RE: Mintguy is an ad-hominem,
	British Upper Class POV revert war monger

body:
There was no justification for such a fluke.  It is merely
my fault for announcing that I was who I was when I came
back.  People didn't notice otherwise, but proceeded to
blacklist me for announcing myself as a former user who had an imperfect start with my first account.  Just
goes to show you that Frankenstein mobs inhabit Wikipedia.
The village people have risen to slay the demon.  Nice take
you have of that Heph, when I didn't continue the things
that got me into trouble.  People began to justify every
negative against me based upon my long ago past.

What was that, Summer of 2003?  Such obsession is only disgracious to Wikipedia.  Wikipedia is no place for grudges, if you've got those type of soap opera disorders you ought to be watching As The World Turns or something on Lifetime.  Sorry, that's not what I came to Wikipedia for, but that's so common it's hard not to notice or become involved somehow.  Just ask user Jw, he used to stalk me and revert everything I posted.  Then Decumanus set up a hate page for burning me at the stake.

Mats Halldin flipped out in every circumstance of me being present for my editing, even if I just asked a question.  I blatently flamed Fedor with a insult and so I must take responsibility for that.  If he'd listen without demanding my banning, I would apologise.  I just stopped giving a shit when people weren't opening their minds and attacked me so I just got caught in the drama people brought to me and went right at them back.

I am glad that such people as Martijn Faassen, OlofE and Wiglaf have been so patient and polite, yet such an experience here at Wikipedia seems to be hard to come by.  It's not my fault that you want to inflict your hatred of my contributions by banning me.  That's an internal dispute that is being projected onto others.  I find it hard to blame others for my discomfort in their opinions except when they attack me personally by auto-reverting everything or calling me a troll, especially without a formulated, rational reason when requested politely for one.

>
> From: John Robinson <john at freeq.com>
> Date: 2004/08/13 Fri AM 10:46:10 EDT
> To: coxcustomer3 at cox.net,  English Wikipedia <wikien-l at Wikipedia.org>
> Subject: Re: [WikiEN-l] RE: Mintguy is an ad-hominem, 	British Upper Class
>  POV revert war monger
>
> >I don't appreciate falsifications that justify social institutions
> >which people like Mintguy adhere to.
>
> You have a lot of gall coming onto the list spouting about how
> "abused" you think you are. You should have been banned months ago.
>
> -Hephaestos
>


list: wikitech-l

from_name: Magnus Manske

subject: [Wikitech-l] Parser, lists and XHTML

body:
For the wiki source

* unordered
*#sub-ordered

our parser does

unordered

sub-ordered

Note the
 *within* the
 tag, which contradicts

http://www.devguru.com/Technologies/xhtml/quickref/xhtml_li.html

Which is correct XHTML? Do we care?

Magnus


from_name: Brion Vibber

subject: [Wikitech-l] An alternate parser

body:
Magnus Manske wrote:
> I therefore suggest a new structure:
> 1. Preprocessor
> 2. Wiki markup to XML
> 3. XML to (X)HTML

This doesn't actually solve any of the issues with the current parser,
since it merely has it produce a different output format.

The main problems are that we have a mess of regexps that stomp on each
other all the time.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040813/af895c13/attachment.pgp>


from_name: Claudio V

subject: [Wikitech-l] Updating cur and old database tables

body:
Hello,

I was wondering if it is possible to update a
localhost Wikipedia cur and old tables or every time a
new database dump is available you must completely
overwrite the cur and old tables with the most recent
ones.

Thanks,

Claudio

______________________________________________________________________
Post your free ad now! http://personals.yahoo.ca


from_name: xmlizer

subject: [Wikitech-l] Re: phase3/languages LanguageFr.php,1.72,1.73

references:
<E1BvD6B-0003k2-QH@sc8-pr-cvs1.sourceforge.net>	<cfg6c9$9qr$1@sea.gmane.org>
	<cfgslt$tqt$1@sea.gmane.org>

body:
Timwi a ?crit :

> xmlizer wrote:
>
>> Question du b?otiens qu'a surement rat? la discussion ad?quate :
>>   On parles souvent de "Pages" et dans certains textes, il est
>> question de "Sujet" (a priori sujet incluerai les cat?gories) ou
>> d'"Article" ? Y'a-t-il une nomenclature ? si oui, o? puis-je la trouver ?
>
>
> Tous les "articles" sont aussi des "pages", mais une "page" peut aussi
> ?tre une page de discussion, une page d'un utilisateur, une page
> Wikip?dia, une cat?gorie, un mod?le, une page de d?scription d'un image
> ou autre fichier, ou une page d'aide. Les "articles" sont les pages dans
> l'espace sans nom.
>
> Timwi
>
Et "Sujet" dans
 >   "tog-highlightbroken" => "Liens vers les sujets non existants en
rouge",
??
xmlizer


from_name: Robert

subject: [WikiEN-l] When can an article be considered public domain?

body:
I am writing an article on the [[Kabbalah Center]], the
for-profit religious group led by former insurance agent
Feivel Gruberger, who now claims to be "Rabbi Philip Berg".

There is a lengthy and carefully referenced article about
him and his work called ''The Truth about the Kabbalah
Centre'' which I got a photocopy of. It was published by
the ''Task Force on Cults and Missionaries'', Los Angeles,
CA in 1995. The references and facts stated therein match
the claims in other articles, from newspapers. (Berg and hs
group have been investiagted by journalists from the US and
Israel; he is accused of running a cult and brainwashing
some of his disciples, as well as scamming them out of
large amounst of money, and endangering their health.)

A few years ago I wrote an article for a local newspaper on
this issue, and tried to get permission to print the
article from the ''Task Force on Cults and Missionaries''.
Despite letters and phone calls, I was unable to track down
anyone who held copyright to it; the people who sent me the
article from LA told me that I was free to publish the
entire article, or parts therein, and that they could not
provide me with copyright information or the name of the
author. They allow others to post the entire article on
their website, notably Rick Ross, an anti-cult educator.

I suspect that the author or authors of this article want
to avoid being sued, and wish that this material be
distributed.

I notice that our article on [[Public domain]] states that
"A copyright holder can explicitly disclaim any proprietary
interest in the work, effectively granting it to the public
domain, by providing a licence to this effect. A suitable
licence will grant permission for all of the acts which are
restricted by copyright law."

What about cases when we can no longer track down the
copyright holder, or they wish not to be found, and
encourage distribution of their work? At what point can we
reasonably presume that such work enters the public domain?

Robert (RK)

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail


from_name: Christiaan Briggs

body:
> Not that I have a problem with British people, it's that I have a
> problem with POV spins in favour of merely the Upper Class propaganda.
>  Wikipedia is not for such things as Wikipedia is not a place for
> establishing social heirarchy as a reason for what edits to favour.

What's a "point of view spin"? Anyway I'm curious. Can you post some
evidence of Upper Class propaganda?

Christiaan


from_name: Eckhart Wörner

subject: [Wikitech-l] Parser, lists and XHTML

body:
Hallo Magnus,

Magnus Manske schrieb:
> * unordered
> *#sub-ordered
>
> our parser does
>
>

>
unordered
>

>
sub-ordered

>

>

>

>
> Note the
 *within* the
 tag, which contradicts
>
> http://www.devguru.com/Technologies/xhtml/quickref/xhtml_li.html

Why does this contradict the mentioned page?
At least, the W3C validator doesn't find any errors in it:

http://tinyurl.com/3vbrw

Eckhart


list: wikipedia-l

from_name: Ralesk Ne'vennoyx

subject: [Wikipedia-l] How about distributing fonts ??

body:
Peter Gervai wrote:
> On Fri, Aug 13, 2004 at 12:03:15AM +0200, Ralesk Ne'vennoyx wrote:
>
>
>>>http://www.nongnu.org/freefont/
>>>http://savannah.nongnu.org/projects/freefont/
>>
>>Files section seems empty, last news from 2002...
>
>
> See te CVS (browse on the web on
> http://savannah.nongnu.org/cgi-bin/viewcvs/freefont/freefont/ ).
>

Although that's nice that that at least exists and works, I don?t
believe that Average User, or even myself, should be forced to use CVS.


from_name: Peter Gervai

body:
On Fri, Aug 13, 2004 at 12:47:27PM +0200, Ralesk Ne'vennoyx wrote:
> Peter Gervai wrote:
> >On Fri, Aug 13, 2004 at 12:03:15AM +0200, Ralesk Ne'vennoyx wrote:

> >>>http://www.nongnu.org/freefont/
> >>>http://savannah.nongnu.org/projects/freefont/
> >>
> >>Files section seems empty, last news from 2002...
> >
> >
> >See te CVS (browse on the web on
> >http://savannah.nongnu.org/cgi-bin/viewcvs/freefont/freefont/ ).
> >
>
> Although that's nice that that at least exists and works, I don?t
> believe that Average User, or even myself, should be forced to use CVS.

No way forced. You're not even forced to breath.

But those who choose to use the fonts can. And I believe the thread was
about available and usable fonts and not "font sources for the mentally
handicapped".

Forget it. I do not need fonts, you do not need fonts, so there is no point
to argue. Those who do may decide to use the links provided or not.

Peter


from_name: Manuel VACELET

subject: [Wikitech-l] Embed mediawiki ?

body:
Hello,

I investigate to embed a wiki engine into another web application. As
wikipedia user I think mediawiki is one of the best engine and I would
integrate it. But I would have your developer point of view :
Do you think it is a good idea to embed mediawiki as wiki engine or
should I look for another tool ?

Thanks

Regards,
Manuel


body:
Peter Gervai wrote:

> On Fri, Aug 13, 2004 at 12:47:27PM +0200, Ralesk Ne'vennoyx wrote:
>
>>Peter Gervai wrote:
>>
>>>On Fri, Aug 13, 2004 at 12:03:15AM +0200, Ralesk Ne'vennoyx wrote:
>
>
>>>>>http://www.nongnu.org/freefont/
>>>>>http://savannah.nongnu.org/projects/freefont/
>>>>
>>>>Files section seems empty, last news from 2002...
>>>
>>>
>>>See te CVS (browse on the web on
>>>http://savannah.nongnu.org/cgi-bin/viewcvs/freefont/freefont/ ).
>>>
>>
>>Although that's nice that that at least exists and works, I don?t
>>believe that Average User, or even myself, should be forced to use CVS.
>
>
> No way forced. You're not even forced to breath.

I know I know, it wasn?t a particularly good wording.

But I mean, as opposed to having it available via ftp or http.  I mean,
updating the damn site once in a blue moon that oops, hey, we don?t want
to make release packs, don?t even try the files section, go use CVS. --
because this surely doesn?t take more than ten fricken minutes from the
life of whoever has write access to the site.

I mean, I have to go, dig around, find that font is available via CVS as
opposed to being a plain old download, and then fight my way through the
CVS to find the newest version (yes, I?m being utterly evil here, but I
don?t like having to nose around in CVS repositories).

Not to mention they only provide the sfd files and from there it?s DIY
which isn?t particularly easy without having a UNIX-like system
installed nearby.  Which I do, but I?m damn lazy to boot over.  And I?m
not the world, so...  Anyway, long live apt-get, I guess :P

And to go back to the original note that the last update of the site was
two years ago, the newest font is 8 months old.  Yes, I know it?s free.
  No, that doesn?t mean I shouldn?t complain.  It?s almost as lively as
The Hurd Project :P  And, from what I?ve seen in Linux, the Freefonts
definitely need some hinting job done on them (and/or freetype some
whacking, because I?ve seen perfectly good fonts rendered terribly, but
maybe that?s just my lazy eye that?s used to the readability of Windows
and OS X).

> But those who choose to use the fonts can. And I believe the thread was
> about available and usable fonts and not "font sources for the mentally
> handicapped".

There?s a whole lot of difference between ?I don?t know what that link
you gave me is? and ?I don?t like to have to poke around in CVS, and
whatever I listed above?.  Please leave your Linuxite arrogance at home.

> Forget it. I do not need fonts, you do not need fonts, so there is no point
> to argue. Those who do may decide to use the links provided or not.

Good point, but I hope you see the hurdles one has to jump over to get a
ttf out of this.
>
> Peter


from_name: Yann Forget

subject: [Wikitech-l] Images used in templates are shown as orphan

body:
Hi,

I posted this last Sunday, but no answer.
Is this bug already known?
It Bugzilla ready for use so I can add it?

Thanks,
Yann
==============
Images used in templates are shown as orphan on fr:
Is this bug already known?

cf.
1. http://fr.wikipedia.org/wiki/Image:Shiva.jpg
used in http://fr.wikipedia.org/wiki/Shiva
2. http://fr.wikipedia.org/wiki/Image:Narmada.jpg
used in http://fr.wikipedia.org/wiki/Narmad?

http://fr.wikipedia.org/w/wiki.phtml?title=Special:Unusedimages&limit=100&offset=1800
Image #1872

This is the case for all images included in templates that I can see.

Yann

--
http://www.non-violence.org/ | Site collaboratif sur la non-violence
http://www.forget-me.net/ | Alternatives sur le Net
http://fr.wikipedia.org/ | Encyclop?die libre
http://www.forget-me.net/pro/ | Formations et services Linux


from_name: mbecker

subject: [Wikitech-l] Distributing wikimedia hardware

body:
I've just now subscribed to this list, so please stop me if this has been already discussed... After hearing about the storm coming toward the wikimedia servers. I thought to myself, wouldn't it be a good idea to have backup servers elsewhere in the world? Especially since Florida is highly susceptible to this sort of weather this time of year... I'm not sure if our funding or budget would allow for distribution of our servers. However, my guess is, there are probably more than one wikipedia people who wouldn't mind setting up a server of theirs somewhere as a backup. Even if it's just a no edit cached back-up. Something is better than nothing...

--
Michael Becker


from_name: Krzysztof Kowalczyk

subject: [Wikitech-l] An alternate parser

body:
> >> I therefore suggest a new structure:
> >> 1. Preprocessor
> >> 2. Wiki markup to XML
> >> 3. XML to (X)HTML

Why XML for intermediate part? As I understand it, speed is important
for WikiPedia code given it needs to scale to a very high usage.
Servers are always overloaded.

Using XML for intermediate form would have a significant negative
impact on speed and memory usage (compared to more efficient
implementation strategy, which is always possible).

Given that there is no requirement to serialize to XML (at least not
during internal wiki->html conversion), serializing to XML and then
parsing this serialized form is pure overhead that can be avoided.

There are many ways to have benefits of XML (structured data) without
incurring the overhead of XML.

For example, you can ship objects around. If you know your XML schema
and it doesn't change, you can always create an equivalent object
hierarchy.

For example:
<wikiPage>
  <title>Title of the page</title>
  <body>This is body</body>
</wikiPage>

can be represented with object wikiPage() that has members title and
body. You can extrapolate this example to any XML with schema known
up-front. Then you can ship those objects around. It's as clean
approach (the abstraction provided is the same, it's just a different,
more efficient way of providing this abstraction to clients).

But as I write it, I see even less reason to use XML - it's just not a
good format to represent wiki markup structure. Can you give an
example of how this XML would look like for some simple wiki markup?
Further discussion about speed/space/code cleanness trade-offs is a
bit hard without knowing more details about proposed approach - it's
vague enough to have more than one interpretation.

Krzysztof Kowalczyk | http://blog.kowalczyk.info


body:
** flame warning! please wear asbestos sunglasses! **

On Fri, Aug 13, 2004 at 01:37:39PM +0200, Ralesk Ne'vennoyx wrote:
> Peter Gervai wrote:

> >>>See te CVS (browse on the web on
> >>>http://savannah.nongnu.org/cgi-bin/viewcvs/freefont/freefont/ ).
> >>>
> >>
> >>Although that's nice that that at least exists and works, I don?t
> >>believe that Average User, or even myself, should be forced to use CVS.

[...]

> >Forget it. I do not need fonts, you do not need fonts, so there is no point
> >to argue. Those who do may decide to use the links provided or not.
>
> Good point, but I hope you see the hurdles one has to jump over to get a
> ttf out of this.

One have to click on the filenames, retrieve. Click on the tools, retrieve.
Run them. Use the fonts.

You get what you have paid for. If you want to pay, I'll read the manuals
instead of you for a fee, get the files instead of you for another, run them
instead of you for more, and provide you the result for another reasonable
sum of money. THEN you get what you've paid for, too.

My "Linux arrogance" means that I despise people who whine that they do not
get the service they demand for free. I believe people either have to think
and do, or stop whining and be selective of the input: if you're lazy (or
stupid) then ignore the helpful links people give to you because they
require work and thinking, and not start whining that it does not suit your
high standards (for free, of course). Choose - silently - the ones you can
handle (click-n-go ones, suit for "nice windows people" [as opposite of
arrogant linux people {those who help I mean}]), and keep it secret that you
won't use the others.

This way you don't disappoint others who tried to help, don't angry others
who see that their help was not just rejected but complained upon.

And I reckon your reply did not serve any useful purposes as it did not
contain any solutions. It showed that I am an ignorant arrogant linux
bastard, who expects too much of the bright nice windows people, but that
did not help anyone.

Oh, and THIS email was completely useless too. I'd advice people to google
up the term "freefont", but then, it needs thinking and efforts, so I won't.
I do not want to get another reply telling me that I cause poor bright nice
fellas more work instead of the Right(tm)(r) solution.

But I know the REAL solution for you nice bright windows people: PAY. Buy
the fonts you need and get the serivce. You did once, it'll do it again. If
you need places where to buy, ask.

Peter

ps: sorry, I plan not to reply to replies of this stupid email of mine. if
anyone requires reply I'll send it in personal email. best to ignore it
altogether.


from_name: Jens Ropers

subject: [WikiEN-l] WP:(...)

body:
Can I suggest we implement a "cover all" redirect, whereby ALL
[[Wikipedia:Some stuff here]] kind of links can alternatively be
written [[WP:Some stuff here]]?

Not all "Wikipedia:(...)" pages have "own" their redirects (meaning
redirects such as WP:SB), but it still seems like a good idea to ALWAYS
allow the "Wikipedia:" bit to be abbreviated as "WP:" -- so that if I'm
writing e.g. [[WP:Dispute resolution]], this would automatically
redirect/be expanded to [[Wikipedia:Dispute resolution]]. Again, I'm
asking whether we can do the WP: to Wikipedia: redirecting/expanding
stuff on a GENERIC basis. (I know it /could/ be done on an individual
article basis, but that's not my point.

It would help, be really convenient and it would not get in the way of
anything. Pages can still have actual own redirects such as [[WP:SB]].

Thanks and regards,
Jens Ropers

There are two types of IT techs: The ones who watch soap operas and the
ones who watch progress bars.
http://www.ropersonline.com/elmo/#108681741955837683


from_name: tatet

subject: [Wikitech-l] Re: linkscan?

body:
Hello Timwi,

Thursday, August 12, 2004, 5:15:04 PM, you wrote:

T> tatet wrote:

>> Thursday, August 12, 2004, 12:21:39 PM, you wrote:
>>
>>> tatet wrote:
>>
>>>>???????????.
>>>>
>>>>???? ?????????? ???? ?? ??????, ??????? ???????? ????? ?????? ?
>>>>????????? ?? ? ??????? link. ??? ?????????? ?????? Whatlinkshere.
>>>>??? ?????? ??????.
>>
>>> ?? ????????????? ?? ?????? ???????? ??????? ??????????? ??? ????,
>>> ??????????? maintenance/refreshLinks.php.
>>
>> ? ???? ? ????, ???? ?????? ???????? ?? ???? ??????? ??????? ???? ?
>> ??????? cur ? ????????? ????? ?????? ? ??????? links.
>> ??? ?????? Whatlinkshere.
>>
>> ? ???????? maintenance/refreshlinks.php, ?? ?? ?? ?????? ???? ?????? ;-(

T> Translation: I meant a script that would go through all articles in the
T> 'cur' table and place their links in the 'links' table. For making
T> Whatlinkshere work. I ran maintenance/refreshlinks.php, but it didn't
T> create all the links. ;-(

T> _______________________________________________
T> Wikitech-l mailing list
T> Wikitech-l at wikimedia.org
T> http://mail.wikipedia.org/mailman/listinfo/wikitech-l

?? ???? ?? ????????? ??????. ? ???? ????????? ?????? ? ?????? "?????????"
??????-?? ?? ????????? ?? ?????? "??????", ???? ?????? ? ??????
"?????????" ??????? ?!
????????, ??? ???????????.

--
Best regards,
 tatet                            mailto:serhiy at tatet.com


subject: [Wikitech-l] An alternate parser

body:
Ivan Krstic wrote:
> 1. User begins to edit page
> 2. Software loads mediawiki-markup page from "write" database, displays it
> 3. User makes changes, submits changes
> 4. Mediawiki stores the page, verbatim, into the "write" database
> 5. Mediawiki also runs the page through Parser, takes the raw HTML, and
> feeds it to a separate, "read" database

Please take a look at the parser cache and see if it's missing any
needed functionality.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040813/6b07c839/attachment.pgp>


subject: [Wikitech-l] An alternate parser

body:
Ivan Krstic wrote:
> Brion Vibber wrote:
>> Please take a look at the parser cache and see if it's missing any
>> needed functionality.
>
> What are the current cache hit/miss rates like? I wrote the last post
> based on the premise that memcached only makes it possible to cache a
> fraction of the article space, still making the parser churn quite a
> bit, making people unhappy.

I don't know what our current hit rate looks like, but memcached can be
arbitrarily large since it is spread across many machines. (The
cluster's total memory capacity is something like 40 gb.)

The parser cache iirc does have to parse _differently_ for users with
different options, so I don't know how much duplication there is.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040813/99e12e9c/attachment.pgp>


subject: [WikiEN-l] Re: domain donation, cybersquatter, our copyright

body:
CB low

> Date: Thu, 12 Aug 2004 06:55:36 -0700
> From: "Jimmy (Jimbo) Wales" <jwales at wikia.com>
> Subject: Re: [WikiEN-l] Re: domain donation, cybersquatter, our
> copyright
> To: English Wikipedia <wikien-l at Wikipedia.org>
>
> The nice thing about "particularly bad serial cybersquatters" is that
> they tend to offer reasonable prices.  Once upon I time, I foolishly
> allowed bomis.net and bomis.org to expire and they were promptly
> squatted.  I was horrified at what it might cost to get them back, but
> it turned out to be quite reasonable, given the fact that it was
> completely tragic in the first place, of course.
>
> If this person is a professional, he's going to be smart and know that
> this isn't worth *that much* money to us.  He'll charge us a small
> nuisance amount, like double what he paid, and that'll be that.

Okay, that's possible. Couple of points:

(a) I made a strong case on
http://www.ropersonline.com/Area_51/wikipaedia.html (user: guest,
passwd: 1ns4nI+y) that we should own and control /all/ the major
wikipAEdia domains (in addition to the wikipEdia ones). Do you agree?
Is there consensus on that?

(b) Are we /willing/ to pay for the wikipaedia.com, .org and .de
domains, considering that we are pretty much guaranteed to get the .com
.org ones by the ICANN UDRP and also rather likely to get the .de
domain through the German legal system? POVs on this may include
considerations of principle vs. convenience -- as well as, in the .de
case, legal costs.

(c) Once we have a clear decision established on (a) and (b), can we
get down to business? I happen to know German and might be able to
help, if suitably "authorized and ordained" ;-)

(d) Speaking of getting down to business -- and keeping (a) in mind --
are people willing to accept my donation of the wikipaedia.net domain?
The domain name registrar I used is
http://www.ev1servers.net/english/index.asp and I could create a
profile of, say, jimmywales (or whoever holds the keys to the kingdom),
move the domain to that profile and email you (Jimmy) the password. No
cost would incur (until and unless you renewed the domain or moved it
to Register.com, who AFAICT are your registrar for wikipedia.org). I
would be happy to do that now if you're ready. I'd prefer though, if
you gave me a public key of yours (PGP or whatever). Safer is safer.

(e) Also, again assuming you're happy to accept wikipAEdia.net, I
suggested doing the applicable DNS changes in my last email, and to
point wikipaedia.net at the respective applicable DNS boxen, to
actually get it to work. Any word on that? Who actually looks after the
Wikipedia associated DNS servers? (Of course, once (d) is done, you no
longer need me for this and can DIY ;-)

Thanks, and looking forward to your replies :-)

- Jens [[User:Ropers|Ropers]]

> Angela_ wrote:
>
>> (moving thread from wikien-l to foundation-l. Please reply there)
>>
>> Jens Ropers wrote:
>>
>>> 1. I am seeking to donate the wikipaedia.net domain name (which I
>>> have
>>> registered) to the Wikipedia Foundation.
>>
>> Thank you for offering us this. My only concern is that confusion
>> could arise if we own wikipaedia.net but not the other wikipaedia
>> domains. If we don't own any of them, it's more obvious that
>> wikipaedia is nothing to do with us.
>>
>>> 2. A particularly bad serial cybersquatter is controlling
>>> wikipaedia.org, wikipaedia.com and wikipaedia.de. We really should
>>> get
>>> these domains off him (and would be able to do so).
>>
>> I asked in the German IRC channel about this. Maybe I'm assuming too
>> much good faith, but I think we ought to approach that site owner in a
>> friendly way at first before we get too heavy handed. Sansculotte is
>> going to take this to the VereinDE-l mailing list and discuss it
>> there. Hopefully someone who speaks German can contact the site about
>> this. We might well get no reply, but at least we can say we tried
>> before taking this any further. It is worth noting that Akl was
>> successful in getting the wikipedia.ch and wikipedia.at domains back,
>> so perhaps this can be successful too.
>>
>> Angela.
>> _______________________________________________
>> WikiEN-l mailing list
>> WikiEN-l at Wikipedia.org
>> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>>


from_name: Neil Harris

subject: [Wikitech-l] Error condition...

body:
I'm getting this set of error reports:

Warning: Wrong parameter count for define() in
/usr/local/apache/common-local/php-new/includes/SiteConfiguration.php on
line 10

Warning: Cannot modify header information - headers already sent by
(output started at
/usr/local/apache/common-local/php-new/includes/SiteConfiguration.php:10)
in /usr/local/apache/common-local/php-new/includes/User.php on line 545

Warning: Cannot modify header information - headers already sent by
(output started at
/usr/local/apache/common-local/php-new/includes/SiteConfiguration.php:10)
in /usr/local/apache/common-local/php-new/includes/User.php on line 546

Warning: Cannot modify header information - headers already sent by
(output started at
/usr/local/apache/common-local/php-new/includes/SiteConfiguration.php:10)
in /usr/local/apache/common-local/php-new/includes/OutputPage.php on
line 262

Warning: Cannot modify header information - headers already sent by
(output started at
/usr/local/apache/common-local/php-new/includes/SiteConfiguration.php:10)
in /usr/local/apache/common-local/php-new/includes/OutputPage.php on
line 290

Warning: Cannot modify header information - headers already sent by
(output started at
/usr/local/apache/common-local/php-new/includes/SiteConfiguration.php:10)
in /usr/local/apache/common-local/php-new/includes/OutputPage.php on
line 291

Warning: Cannot modify header information - headers already sent by
(output started at
/usr/local/apache/common-local/php-new/includes/SiteConfiguration.php:10)
in /usr/local/apache/common-local/php-new/includes/OutputPage.php on
line 351

Warning: Cannot modify header information - headers already sent by
(output started at
/usr/local/apache/common-local/php-new/includes/SiteConfiguration.php:10)
in /usr/local/apache/common-local/php-new/includes/OutputPage.php on
line 352

This does not look healthy.

-- Neil


subject: [Wikitech-l] Re: Error condition...

body:
Neil Harris wrote:

> I'm getting this set of error reports:
>
> Warning: Wrong parameter count for define() in
> /usr/local/apache/common-local/php-new/includes/SiteConfiguration.php
> on line 10
>
> Warning: Cannot modify header information - headers already sent by
> (output started at
> /usr/local/apache/common-local/php-new/includes/SiteConfiguration.php:10)
> in /usr/local/apache/common-local/php-new/includes/User.php on line 545
>
> Warning: Cannot modify header information - headers already sent by
> (output started at
> /usr/local/apache/common-local/php-new/includes/SiteConfiguration.php:10)
> in /usr/local/apache/common-local/php-new/includes/User.php on line 546
>
> Warning: Cannot modify header information - headers already sent by
> (output started at
> /usr/local/apache/common-local/php-new/includes/SiteConfiguration.php:10)
> in /usr/local/apache/common-local/php-new/includes/OutputPage.php on
> line 262
>
> Warning: Cannot modify header information - headers already sent by
> (output started at
> /usr/local/apache/common-local/php-new/includes/SiteConfiguration.php:10)
> in /usr/local/apache/common-local/php-new/includes/OutputPage.php on
> line 290
>
> Warning: Cannot modify header information - headers already sent by
> (output started at
> /usr/local/apache/common-local/php-new/includes/SiteConfiguration.php:10)
> in /usr/local/apache/common-local/php-new/includes/OutputPage.php on
> line 291
>
> Warning: Cannot modify header information - headers already sent by
> (output started at
> /usr/local/apache/common-local/php-new/includes/SiteConfiguration.php:10)
> in /usr/local/apache/common-local/php-new/includes/OutputPage.php on
> line 351
>
> Warning: Cannot modify header information - headers already sent by
> (output started at
> /usr/local/apache/common-local/php-new/includes/SiteConfiguration.php:10)
> in /usr/local/apache/common-local/php-new/includes/OutputPage.php on
> line 352
>
> This does not look healthy.
>
> -- Neil
>
>
And it's fixed itself, just as suddenly. Was someone updating the software?

-- Neil


from_name: Walter van Kalken

subject: [Wikitech-l] Problem with watchlist

body:
Hello my name is user:waerth from the Dutch wikipedia.
According to my preferences button my internal
identification number is: 1467.

Since yesterday it has not been possible to see the
changes for more than 12 hours ago on my watchlist.
This is very irritating as I haven't checked the
changes due to time limitations for the last 3 days! I
tried changing the skins and than pressed look at
changes in the last 3 days and I got the following
error message, (I hope it helps) With kind regards,
Walter van Kalken

Warning: Wrong parameter count for define() in
/usr/local/apache/common-local/php-new/includes/SiteConfiguration.php
on line 10

Warning: Cannot modify header information - headers
already sent by (output started at
/usr/local/apache/common-local/php-new/includes/SiteConfiguration.php:10)
in
/usr/local/apache/common-local/php-new/includes/OutputPage.php
on line 262

Warning: Cannot modify header information - headers
already sent by (output started at
/usr/local/apache/common-local/php-new/includes/SiteConfiguration.php:10)
in
/usr/local/apache/common-local/php-new/includes/OutputPage.php
on line 290

Warning: Cannot modify header information - headers
already sent by (output started at
/usr/local/apache/common-local/php-new/includes/SiteConfiguration.php:10)
in
/usr/local/apache/common-local/php-new/includes/OutputPage.php
on line 291

Warning: Cannot modify header information - headers
already sent by (output started at
/usr/local/apache/common-local/php-new/includes/SiteConfiguration.php:10)
in
/usr/local/apache/common-local/php-new/includes/OutputPage.php
on line 351

Warning: Cannot modify header information - headers
already sent by (output started at
/usr/local/apache/common-local/php-new/includes/SiteConfiguration.php:10)
in
/usr/local/apache/common-local/php-new/includes/OutputPage.php
on line 352

___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com


from_name: Charles Matthews

body:
Kenneth Alan wrote

> I don't appreciate falsifications that justify social institutions which
people like Mintguy adhere to.  The nature of his interests and the form of
his edits and attacks against me happen to reflect class basis.

I think you mean class bias.  Anyway, if you think his WP writing suffers
from POV, you should be able to prove that, by the usual type of debate.

Charles


subject:
[WikiEN-l] Image use (was "the document vs. everything vs. the
	text")

body:
CB low

> Date: Thu, 12 Aug 2004 07:08:12 -0700
> From: "Jimmy (Jimbo) Wales" <jwales at wikia.com>
>
> Jens Ropers wrote:
>> IMHO we would severely hamstring ourselves if we didn't allow this.
>
> I don't think so.  There might be some extreme cases in which we might
> desperately need something that is unavailable under a free license
> and also unavailable under a conservative interpretation of 'fair
> use/fair dealing', but it is very hard to think of examples.
>
> One very big issue is that if we permit ourselves to use content
> under a proprietary license, we do two very bad things:
>
> 1.  We dilute our standing as a shining example of what freedom can
> bring.  We lose the ability to speak publicly and say: "Look, the
> claim that proprietary copyright is necessary for the production of
> quality content is not true; we have proven it."  Instead, we have to
> point to our work and say "Well, some of it is free, but some of it is
> proprietary, and we really needed the proprietary stuff to make it
> work."
>
> 2.  We remove the incentive for free alternatives to develop.  Imagine
> if I went to a major stock photo house and obtained, as a charitable
> contribution, licenses for wikipedia-only use of photos of major
> landmarks around the world.  Then why should anyone bother to go out
> and take a photo of the Leaning Tower of Pisa with Wikipedia in mind?
>
>> There are some very important images out there that /should/ be
>> included in the Wikipedia -- and we may just (given our "limited"
>> legal
>> resources) be unable to ever get them under "free" licenses.
>
> I concede that there may well be *a few* rare cases where this is
> absolutely necessary for scholarly integrity.  We should make careful
> judgments about those exceptions, on a case-by-case basis.
>
> What we should *not* do is get lax about using non-free content as a
> crutch because it is easier or more convenient.
>
> --Jimbo

I can actually see where you're coming from and I would even largely
agree.
However, with respect to the [[Image:TrangBang.jpg]] I emailed AP about
-- are you ok/is there agreement that this would be one of the "few
rare cases"?
I would strongly plead that it is. My email was this:

> 	From: 	  ropers at ropersonline.com
> 	Subject: 	electronic reproduction permission request -- Nick Ut's
> "naked girl running from napalm attack" photograph of Kim Phuc Phan
> Thi
> 	Date: 	8 August 2004 16:25:15 GMT+02:00
> 	To: 	  apdigital at ap.org
(content omitted here)

I previously cc'd this mailing list on that email.

Thanks and regards,

- Jens [[User:Ropers|Ropers]]


from_name: Brion Vibber

subject: [Wikitech-l] An alternate parser

body:
Jan Hidders wrote:
[snip]
> That hard part is of course to come up with the contex-free grammar (it should
> probably be LALR(1) at that). Since I used to teach compiler theory I might
> be of some help there.

Yes, and that's the *only* part that will help. Having two or three or
five intermediate formats doesn't do anything to help the problem --
making the actual parser actually work token by token will.

IMHO putting a lot of emphasis on output formats is a mistake, since it
ignores the actual problem.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040813/a0950f0f/attachment.pgp>


subject: [Wikipedia-l] Distributing fonts

body:
I have been amazed at the passions that were stirred up when I proposed that we distribute free fonts.

There have been two types of reaction: Point to a source that has a partial solution, sometimes for money and bickering about the level of handholding that a user may need.

As there is not one golden solution, it is not simple to say spend $$ and you are ready.

It can also become part of the installation of software that goes with a DVD for of-line use. When having enough fonts is needed for the best wikipedia experience, why wouldn't we give a helping hand to our current users and help them in this way ??

Thanks,
   Gerard


from_name: Anthony DiPierro

subject: [WikiEN-l] Image:TrangBang.jpg

body:
Jens Ropers asked whether this is likely one of the "few rare cases" where
we desperately need an image which is unavailable under fair use.

Looking at the details, this image is used in [[Nudity]], [[Vietnam War]],
[[Strategic bombing]], [[Kim Phuc Phan Thi]], [[History of the United States
(1964-1980)]], and [[Huynh Cong Ut]].  I don't see any arguable "deperate
need" for the image in any of the articles other than [[Kim Phuc Phan Thi]]
and [[Huynh Cong Ut]], and the image is most likely fair use in those
articles.

I think we should remove the image from [[Nudity]], [[Vietnam War]],
[[Strategic bombing]], and [[History of the United States (1964-1980)]].
I'd suggest that we only link to it in the other articles (assuming it is
available somewhere online outside of Wikipedia), but I could see an
argument for keeping it, as it is essentially impossible to replace, the
cost to buy a free license would be prohibitive (at least at Wikipedia's
current stage of development), and it is most likely usable by at least the
noncommercial reusers.  I don't see a problem with asking for permission to
use the image in those two articles if we decided to keep it.

Just my opinion, though.  I'd like to here Jimbo's assessment.

Anthony


from_name: Michael Becker

subject: [WikiEN-l] Image:TrangBang.jpg

body:
As you might be aware of, I was the one who originally asked for the deletion of this image. After extensive discussion on this thread http://mail.wikipedia.org/pipermail/foundation-l/2004-August/000822.html I changed my mind about the need for deletion. I agree with your assessment of the situation. I too look forward to Jimmy's comments on the issue, however due to the Hurricane currently flooding his house with up to 5 feet of water, I somehow doubt he will be replying any time soon :(.

On Fri, 13 Aug 2004 16:46:33 -0400, Anthony DiPierro <anthonydipierro at hotmail.com> wrote:
> Jens Ropers asked whether this is likely one of the "few rare cases" where
> we desperately need an image which is unavailable under fair use.
>
> Looking at the details, this image is used in [[Nudity]], [[Vietnam War]],
> [[Strategic bombing]], [[Kim Phuc Phan Thi]], [[History of the United States
> (1964-1980)]], and [[Huynh Cong Ut]].  I don't see any arguable "deperate
> need" for the image in any of the articles other than [[Kim Phuc Phan Thi]]
> and [[Huynh Cong Ut]], and the image is most likely fair use in those
> articles.
>
> I think we should remove the image from [[Nudity]], [[Vietnam War]],
> [[Strategic bombing]], and [[History of the United States (1964-1980)]].
> I'd suggest that we only link to it in the other articles (assuming it is
> available somewhere online outside of Wikipedia), but I could see an
> argument for keeping it, as it is essentially impossible to replace, the
> cost to buy a free license would be prohibitive (at least at Wikipedia's
> current stage of development), and it is most likely usable by at least the
> noncommercial reusers.  I don't see a problem with asking for permission to
> use the image in those two articles if we decided to keep it.
>
> Just my opinion, though.  I'd like to here Jimbo's assessment.
>
> Anthony
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

--
Michael Becker


from_name: Pedro Fortuny Ayuso

subject: [Wikipedia-l] Text-to-speech

body:
Wow, the tests are IMPRESSIVE. I think they need not have any problem with
our linking to them.

Thanks for the link, anyway.

Pedro.

Text-to-speech

Magnus Manske schrieb:
> As Wikipedia has a good and innovative image, and since we wouldn't buy
> their product anyway, I guess AT&T would be interested in such a thing.
> Question is, would we?

Sure! I would love to see that.

The quality even of the German part is impressive, with much space to
improve :)

Mathias

_______________________________________________
Wikipedia-l mailing list
Wikipedia-l at Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/wikipedia-l

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004


subject:
[Wikipedia-l] Re: Nauruan and this ugly message
	under	each	en:article

body:
Roman Maurer wrote:

> Timwi pravi:
>
>> Having the URL on the screen doesn't do any harm.
>
>
> Sure it does.  It decreases the readability of the text.

It?s not in the middle of content, it?s at the very end.  How does that
decrease readability?


from_name: Roman Maurer

subject:
[Wikipedia-l] Re: Nauruan and this ugly message under
	each	en:article

body:
Timwi pravi:

> Having the URL on the screen doesn't do any harm.

Sure it does.  It decreases the readability of the text.
--
	Pozdrav,
	  Roman


subject: [Wikitech-l] Bugzilla bug report migration

body:
The bugzilla.wikimedia.org (with M) address still seems to be
problematic for some people, but bugzilla.wikipedia.org seems to be
pretty well working by now.

Timwi's started on migrating still-open bug reports from the sourceforge
tracker to Bugzilla, which will bring us these amazing benefits:

* Easier to create a login than it is on Sourceforge
* Easier to search for existing bugs
* Less cluttered interface!
* Bugmail notifications are less cluttered; it's easier to tell what's
changed
* URLs typed in comments are clickable
* Wikilinks typed in comments are clickable (to Wikipedia wikis at least)
* Easy links from Wikipedia pages to bug reports like this: [[bugzilla:13]]

At some point we need to look at the Feature Requests too; there are a
lot of duplicates and weird things in there...

Note -- if you take assignment of a bug, be sure to add wikibugs-l to
the CC list so notifications will still go to the mailing list and IRC
bot. We'll try to make that automatic in the future.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040813/a50c0d7d/attachment.pgp>


subject: [Wikitech-l] An alternate parser

body:
Ivan Krstic wrote:
> Brion Vibber wrote:
>> The parser cache iirc does have to parse _differently_ for users with
>> different options, so I don't know how much duplication there is.
>
> This is probably worth looking into. With duplication and constant
> growth working against you, 40GB isn't as much as it seems. I'm more
> interested in your opinion about whether the one parser hit on edit
> would solve the parser performance issues altogether, since it takes any
> guesswork out of the picture and scales very easily.

I'm sure it would help some, though I don't know how much as I don't
have the hit ratio numbers.

Making it have to parse on edit _only_ would require a number of
specific things though such as:

* Parsing has to be independent of user options and settings. Things
like math rendering options need to alter only a later stage of output
than what is cached.

* Variable substitutions like the current date and number of articles
must be kept for later. Note that people like to use the date variables
in links for 'X of the day' type features; this causes some niggling
trouble with link consistency.

* Template substitution must similarly be delayed. If the templates are
pre-parsed though it could be easy to just grab the template's parse
tree and stick it in to the appropriate place. Caveat: templates have
parameters, with the same kinds of problems as variable substitutions
(they are often used in links)

And of course, if we change the parsing rules we need to be able to
clear out the cache, either through automatic versioning or some other
scheme. I tend to favor versioning and checking the cache for
currentness at load time and saving it then if necessary; that's how we
deal with most such things.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040813/bc660b54/attachment.pgp>


list: wiktionary-l

subject: [Wiktionary-l] nl:Wiktionary on 2500 words

body:
Since the conversion to UTF-8 the nl:wiktionary (or WikiWoordenboek) had a big growth spurt. Fittingly the 2500th word is ????????? (UTF-8 was needed to create the word).

We have many words in many languages for many languages..

Thanks,
   GerardM


from_name: Ashar Voultoiz

subject: [Wikitech-l] Re: phase3/includes Parser.php,1.237,1.238

body:
Guillaume wrote:
> Update of /cvsroot/wikipedia/phase3/includes
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2173
>
> Modified Files:
> 	Parser.php
> Log Message:
> MAX_INCLUDE_REPEAT 5 => 20
> Fix non-breaking space before ';'

I don't think we should set the default settings so high.

--
Ashar Voultoiz


from_name: Magnus Manske

subject: [Wikitech-l] An alternate parser

body:
Warning: Yeat Another Crazy Idea of Mine ahead. If you're sick of these
(by bitter experience;-) delete this mail *now*.

Still here? Great!

OK, we all know that the current parser, while working, is not the final
word. It is kinda slow due to multi-pass, the source is confusing, and
there are some persistant bugs in it, like the template malfunctions.

I therefore suggest a new structure:
1. Preprocessor
2. Wiki markup to XML
3. XML to (X)HTML

Let me go through these. The preprocessor would basically do the
template and variable stuff; dumb text replacement, like a C/C++
preprocessor. It would generate the complete wiki-markup text, which is
then carefully chewed by the to-XML-coverter. The XML output is then
converted into HTML/XHTML for display.

Why have this XML step in there? Couple of reasons.

I think of XML which can be generated from the wiki text /without any
knowledge of the rest of the database/. The converter will not check,
"does this article exist" or "is this an internal link, an image, an
interwiki link, or what?". It should only convert "[[this|or that]]" to
"<wikilink page='this'>or that</wikilink>". Also, it should produce only
valid XML, no matter the input.

IMHO that would separate the actual *parsing* of the wiki markup from
its *meaning*. There are useful methods, functions, libraries
and-what-not for dealing with XML.

To have a few points working in favor of this idea:
* The wiki parser (#2) can be clean, brief and efficient without
worrying about the context of the page; it can focus on parsing wiki markup.
* The XML-HTML-converter (#3) can focus on the pure context of the page:
make a normal link, stub link, thumbnailed image, or a category or
interwiki link, etc.
* Both can be developed and maintained independently. To make thumbnail
display behave differently, I won't have to look at the dirty wiki
markup parsing at all ;-)
* We could have a decent XML output function at no cost.
* Other wikis, used to a different syntax, could easily switch to
MediaWiki by adapting the wiki-to-XML module.

For wiki-to-XML, we could even use an external parser. I am currently
toying around with one in C++ (yes, another one, and yes, one could
probably write it in two lines of Perl. So, go ahead!;-)

I *do* realize that this would mean a great change in our current
software. Therefore, I do not demand for this to be implemented in 1.3.1 :-)
But, in the long run, I strongly believe that this is the way to go. The
performace loss from doing two steps instead of one might even be
compensated for by increased performance of each specialized part. The
value of making the parser more modular, however, should IMHO not be
underestimated.

Magnus

P.S.: Hurricane "Charley" - Britannica's last hope... ;-)


subject: [Wikipedia-l] Distributing fonts

body:
Gerard.Meijssen wrote:

>I have been amazed at the passions that were stirred up when I proposed that we distribute free fonts.
>
>

I was amazed as well. I didn't bother to look through the Credits page,
but if the fonts are free as in GPL/GFDL, did anyone of the bickering
crowd actually consider building TTFs from the files, upload these at
wikipedia, and offering them for convenient download there, with proper
credits?

We could also upload a free OGG player or the like. [[Wikipedia:Software
resources]] or something.

Magnus


from_name: Zinnmann

subject: [Wikipedia-l] Distributing fonts

body:
MM> We could also upload a free OGG player or the like. [[Wikipedia:Software
MM> resources]] or something.

I don't think, we have to mirror every single GPL software. But maybe
a comprehensive catalogue of free software and data (like fonts) would
be a good idea.


from_name: Pablo Saratxaga

subject: [Wikipedia-l] Distributing fonts

body:
Kaixo!

On Fri, Aug 13, 2004 at 09:16:07PM +0200, Magnus Manske wrote:

> but if the fonts are free as in GPL/GFDL, did anyone of the bickering
> crowd actually consider building TTFs from the files, upload these at
> wikipedia, and offering them for convenient download there, with proper
> credits?

It's just that it isn't the goal of wikipedia to be a font distributor
(nor a software distributor, etc).
Having a page on meta namespace referencing places where to get fonts
for a given script is ok; but actually hosting the files on wikipedia
I don't see the point (and wikimedia software isn't designed to be an
optimal solution for file serving either)

> We could also upload a free OGG player or the like. [[Wikipedia:Software
> resources]] or something.

Distributing software is an even worst idea imho.

What next, upload CDROM/DVD images of free operating systems?

All that can be easily downloaded from the right place, from places
that aim to be repositories of free software/free fonts.
Using wikipedia servers for that will be a waste of bandwidth and server
resources, diverted from their goal of serving encyclopedic pages.

Having a list of links from where to get those files/programs may
be a good idea; but actually hosting them is not.

--
Ki ?a vos v?ye b?n,
Pablo Saratxaga

http://chanae.walon.org/pablo/		PGP Key available, key ID: 0xD9B85466
[you can write me in Walloon, Spanish, French, English, Catalan or Esperanto]
[min povas skribi en valona, esperanta, angla aux latinidaj lingvoj]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20040813/2ba9f789/attachment.pgp


subject: [Wikitech-l] Re: An alternate parser

body:
Brion Vibber wrote:
> Magnus Manske wrote:
>
>> I therefore suggest a new structure:
>> 1. Preprocessor
>> 2. Wiki markup to XML
>> 3. XML to (X)HTML
>
>
> This doesn't actually solve any of the issues with the current parser,
> since it merely has it produce a different output format.
>
> The main problems are that we have a mess of regexps that stomp on each
> other all the time.
>
> -- brion vibber (brion @ pobox.com)

Can't we switch back to the tokenizer parser and try to optimize it ?
The token approch Seems much easier to maintain.

--
Ashar Voultoiz


subject: [Wikitech-l] An alternate parser

body:
Brion Vibber wrote:

> Magnus Manske wrote:
>
>> I therefore suggest a new structure:
>> 1. Preprocessor
>> 2. Wiki markup to XML
>> 3. XML to (X)HTML
>
>
> This doesn't actually solve any of the issues with the current parser,
> since it merely has it produce a different output format.

Of course, it wouldn't solve any issues with the current parser; it
would be another parser altogether, with shiny new issues of its own ;-)

> The main problems are that we have a mess of regexps that stomp on
> each other all the time.

Yes, but we could put what I call #2 into its own class, which could use
regexps or not, or into an external program. The wiki2xml C++ parser I
am working on doesn't use regexps at all. Or we could use one of these
weird compiler-generating languages, or parser-generating ones, if there
is such a thing. The point is, it will be spearate (read: independent)
from the rest of the software, which will simplify things enormously, IMHO.

I think a huge part of the problem is that we generate HTML for some
wiki markup, then get in conflict with outselves on another part.
Another part is the interweaving of parsing and database operations. By
parsing, checking numerous context conditions, querying the database,
and generating HTML, all in a single function, we get lost, along with
the parser.

In my proposal, we concentrate on pure markup-to-markup conversion
(wiki-to-XML) in one module, and on pure tag *interpretation* in the
next. IIRC, PHP already has built-in XML functions. When we enter #3 of
my proposal, we can rely on having perfectly vaild XML, so weird regexp
effects are likely to be a thing of the past there as well.

Back when I started Phase II, I didn't know exactly where I was headed,
so I added feature upon feature, up to a point where the code was a
mess. Lee Daniel Crocker (are you still out there? There are still some
bugs in the sourceforge bugtracker with your name on them;-) had mercy
and restructured the code to what became Phase III. Because of that
cleanup, that restructuring of things, we were able to get some speed
back into the code.

But when I look at Parser.php now, I see a similar mess as at the end of
Phase II. Yes, it is all OOP (or what PHP thinks OOP is:-) now, but the
functions are one nightmare of if-clauses after another. When I tried to
join the bughunt, I became increasingly afraid to touch the stuff.
Changes in one function had effects on others where there was no obvious
reason for that. Granted, I didn't keep up-to-date with the development
as I should have, but I doubt that's the reason for the (rather
emotional than rational) effect I experienced.

Things have already developed into the direction I proposed. Look at the
internal link parsing. It is parsing the link, thereby making a list of
parameters (for images), *then* analysing the parsed link and its
parameters. But that function alone has 160 lines! My C++ function (with
C++ less well suited for string manipulation) to convert wiki markup
into XML has 70 lines, and it already parses nested links; no need to
call it two times, as we currently do (yuck!).

The need to *then* render (X)HTML won't go away magically; but it can be
done based on valid XML, which should be *much* cleaner than what we do now.

Magnus


subject: [Wikipedia-l] Distributing fonts

body:
Zinnmann wrote:

>MM> We could also upload a free OGG player or the like. [[Wikipedia:Software
>MM> resources]] or something.
>
>I don't think, we have to mirror every single GPL software. But maybe
>a comprehensive catalogue of free software and data (like fonts) would
>be a good idea.
>
>
It fits into the emotional state of this discussion that suddenly "a
free OGG player" has become "every single GPL software"...

And no, Pablo, I wasn't saying anything about "DVDs of free operating
systems" either. I was talking about a single, 1MB+ ttf file. Yeah, that
would surely crush our bandwidth and disk capacity, as you more or less
predicted.

If we have a free TTF file to download from the web somewhere, link's
fine. If not, I see no reason *not* to upload and offer one. Sure
haven't heard one in the previous postings.

Come on, where's the problem? We're offering 4-5 *GB* with pictures to
download for en already. And you say we're not equipped to serve a
single TTF file?

Let's all calm down a little,
Magnus


from_name: Michael Snow

subject: [WikiEN-l] Re: When can an article be considered public domain?

body:
Robert wrote:

>A few years ago I wrote an article for a local newspaper on
>this issue, and tried to get permission to print the
>article from the ''Task Force on Cults and Missionaries''.
>Despite letters and phone calls, I was unable to track down
>anyone who held copyright to it; the people who sent me the
>article from LA told me that I was free to publish the
>entire article, or parts therein, and that they could not
>provide me with copyright information or the name of the
>author. They allow others to post the entire article on
>their website, notably Rick Ross, an anti-cult educator.
>
>I suspect that the author or authors of this article want
>to avoid being sued, and wish that this material be
>distributed.
>
>I notice that our article on [[Public domain]] states that
>"A copyright holder can explicitly disclaim any proprietary
>interest in the work, effectively granting it to the public
>domain, by providing a licence to this effect. A suitable
>licence will grant permission for all of the acts which are
>restricted by copyright law."
>
>What about cases when we can no longer track down the
>copyright holder, or they wish not to be found, and
>encourage distribution of their work? At what point can we
>reasonably presume that such work enters the public domain?
>
Copyright holders have no obligation to disclose contact information or
anything else that allows you to track them down. If a copyright holder
is untraceable, usually all you can do is wait for the copyright to
expire. This may not be easy to determine, since you probably will not
know in this situation when the author has died. Under current law,
among other things, the author needs to have been dead for 70 years. So
you can't reasonably presume that the work is in the public domain
unless you're pretty sure that the author died more than 70 years ago.

The possibility that the copyright holder encouraged distribution of the
work might be construed as some sort of license. But unlike the old
days, where failure to include a copyright notice might make a work
public domain, today there is no conduct that puts something into the
public domain by default. Simply encouraging the distribution of the
whole work or excerpts is not the kind of explicit statement I would
read as releasing the work into the public domain.

Furthermore, in the situation you describe, the providers of the content
act as if they know the author allows redistribution, yet they are
peculiarly unable to even name the author (which they should be able to
do even if they have since lost contact). This does not instill any
great confidence in me that these people can reliably restate the wishes
of the copyright holder.

In any case, I fail to see the need for us to reprint this work. If it
provides any useful information that is appropriate for our articles,
those facts can be written in a suitable NPOV fashion and the source of
the information cited.

--Michael Snow


subject: [Wikitech-l] An alternate parser

body:
Krzysztof Kowalczyk wrote:

>>>>I therefore suggest a new structure:
>>>>1. Preprocessor
>>>>2. Wiki markup to XML
>>>>3. XML to (X)HTML
>>>>
>>>>
>
>Why XML for intermediate part? As I understand it, speed is important
>for WikiPedia code given it needs to scale to a very high usage.
>Servers are always overloaded.
>
>
My reasons for XML:
* Standardized (for other applications, proven parsers available, easier
for new developers to deal with)
* IMHO best way to pass data between a #2 external parser and MediaWiki
* Basing #3 on guaranteed valid XML will ease generation of valid XHTML
a lot

>For example:
><wikiPage>
>  <title>Title of the page</title>
>  <body>This is body</body>
></wikiPage>
>
>can be represented with object wikiPage() that has members title and
>body. You can extrapolate this example to any XML with schema known
>up-front. Then you can ship those objects around. It's as clean
>approach (the abstraction provided is the same, it's just a different,
>more efficient way of providing this abstraction to clients).
>
>
Yes, that could be done, but it would require to stay in PHP. Also, I
(personally) like to stay in text-to-text conversion for #2, but that's
just my taste.

>But as I write it, I see even less reason to use XML - it's just not a
>good format to represent wiki markup structure. Can you give an
>example of how this XML would look like for some simple wiki markup?
>Further discussion about speed/space/code cleanness trade-offs is a
>bit hard without knowing more details about proposed approach - it's
>vague enough to have more than one interpretation.
>
>
Well, something like

[[image:bla.jpg|thumb=bla_small.jpg|150px|Text and [[a link]]]]trail

would become

<wikilink page='image:bla.jpg' thumb='bla_small.jpg' width='150px'>Text
and <wikilink page='a link'>a link</wikilink>trail</wikilink>

That's actual output of my parser. I will put the source on the net
somewhere once it has all major functions. Missing at this point are:
* Handling of <nowiki> (and <pre>, respectively)
* XML validating (that's going to be the hardest part;-)
* table markup
* external links and "brute force" markup like ISBNs

Otherwise, it is functional already. It even does the ''italics
'''italics bold''''' thingy right ;-)
Haven't tested it on "real" wikipedia pages yet, though.

Magnus


from_name: Timwi

references:
<E1BvD6B-0003k2-QH@sc8-pr-cvs1.sourceforge.net>	<cfg6c9$9qr$1@sea.gmane.org>	<cfgslt$tqt$1@sea.gmane.org>
	<cfi3u1$86a$1@sea.gmane.org>

body:
xmlizer wrote:

> Timwi a ?crit :
>
>> Tous les "articles" sont aussi des "pages", mais une "page" peut aussi
>> ?tre une page de discussion, une page d'un utilisateur, une page
>> Wikip?dia, une cat?gorie, un mod?le, une page de d?scription d'un
>> image ou autre fichier, ou une page d'aide. Les "articles" sont les
>> pages dans l'espace sans nom.
>
> Et "Sujet" dans
>  >   "tog-highlightbroken" => "Liens vers les sujets non existants en
> rouge",
> ??

Cela doit probablement dire "pages".

Timwi


from_name: Ivan Krstic

subject: [Wikitech-l] An alternate parser

body:
I just glanced at the codebase to take a look exactly what gets cached.
If my understanding is correct (and it's possible that it's not, since I
only looked for about 5 minutes), the article is reparsed by the parser
on every page view[1].

Since disk space is cheap, and disks are relatively fast, why not do the
following (it's assumed that a dedicated box is designated the "read"
database box):

1. User begins to edit page
2. Software loads mediawiki-markup page from "write" database, displays it
3. User makes changes, submits changes
4. Mediawiki stores the page, verbatim, into the "write" database
5. Mediawiki also runs the page through Parser, takes the raw HTML, and
feeds it to a separate, "read" database

Subsequently, any and all article views are routed to the "read"
database, reducing the time for all non-edit pageviews to a mere
database fetch, which is further performance-optimized by virtue of
memcached and the MySQL query cache, and can be cheaply made faster
through RAID striping and similar measures.

Of course, this depends on no user-configurable settings changing the
HTML once it's produced. That's in direct conflict with at least one
feature that I'm aware of, which is the different style of showing
non-existent links, but there are two solutions to this: one, scrap the
feature for a massive performance boost, and two, have a special
miniparser that only parses the raw HTML from the "read" database for
those per-user settings which modify the HTML output.

Either way, the performance penalty of the parser is reduced to a
one-time hit when the article is being committed, and the "our parser is
slow" discussion becomes moot.

Thoughts? If this is what we need, I might be nudged into providing a patch.

Cheers,
Ivan.

[1] For simplicity, I'm leaving the squids out of the equation here.


subject: [Wikipedia-l] Distributing fonts

body:
Kaixo!

On Fri, Aug 13, 2004 at 10:30:51PM +0200, Magnus Manske wrote:

> If we have a free TTF file to download from the web somewhere, link's
> fine. If not, I see no reason *not* to upload and offer one. Sure
> haven't heard one in the previous postings.

Ah, that is quite a different thing.

However, it would still be better to put it somewhere else (along other
fonts for example; that would reach more people)

> Come on, where's the problem? We're offering 4-5 *GB* with pictures to
> download for en already. And you say we're not equipped to serve a
> single TTF file?

I had read it as if the idea was to frentically upload all kind of fonts
available.
Indeed one font is not very much; but the real point is that it is not
the right place.
The images are big, but they illustrate the articles; they are part of
the information in the articles.

A font, I don't see how it could be a part of the article (a font file
cannot be directly usable from the web pages; it has to be downloaded
and installed first; that is different to images, sound and video that
can be directly seen/heard).

A font file could be a part of the article of an article about
typography or computer typography; but as it won't be directly usable
from the web browser, probably it would be useless anyway.

Another thing would be a font like a tool to create the infrastructure
(eg, to standardize on the typography of the logos etc); such
font-as-a-tool could indeed have its place in meta:

--
Ki ?a vos v?ye b?n,
Pablo Saratxaga

http://chanae.walon.org/pablo/		PGP Key available, key ID: 0xD9B85466
[you can write me in Walloon, Spanish, French, English, Catalan or Esperanto]
[min povas skribi en valona, esperanta, angla aux latinidaj lingvoj]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20040813/f609efc9/attachment.pgp


from_name: Fred Bauder

subject: [Wikipedia-l] personal threats again

body:
Blocking is just that, a possibly ineffective remedy should he use a wide
range of dynamic addresses. Following dispute resolution you can certainly
see him banned and blocked as much as possible, indeed under our personal
attacks policy he can be blocked immediately. I gather you don't want to do
it yourself, but a new administrator will be elected and all that can be
done on that front will probably be done.

Blocking does not address the underlying issue that he can in the policially
and religiously charged athmoshere in Iran potentially make good on his
threats. This is an issue that needs to be handled through institutions such
as the Persian Academy (if indeed you belong to such an organization).
Absurd denunciations need to be recognized as such, not taken seriously by
those in authority. This attitude takes a while to develop and requires
exposure of this sort of thing in public forums.

If indeed you have made edits and expressed opinions which are vulnerable to
successful attack by political and religious authorities themselves
outsiders such as ourselves can do some good by publicizing the matter and
exposing it. This can be small comfort in practical terms.

Fred

> From: Roozbeh Pournader <roozbeh at gmail.com>
> Reply-To: wikipedia-l at Wikimedia.org
> Date: Sat, 14 Aug 2004 06:45:01 +0430
> To: wikipedia-l at wikimedia.org
> Subject: [Wikipedia-l] personal threats again
>
> Recently, an anonymous user only writing on talk pages has started
> attacking me heavily on the Persian Wikipedia (and also a little on
> the English one). He has also threatened me on the Persian Wikipedia
> with "I will start a war, both here and on the English Wikipedia. I
> will also get you kicked out of the Persian Academy" and things like
> that, and has ridiculed us by saying that blocking his IP address
> won't stop him, as he is using dynamic addresses.  This is some of his
> more polite wording (in English), where he is calling me a "wild dog":
>
> http://en.wikipedia.org/w/wiki.phtml?title=User_talk:Roozbeh&diff=5194299&oldi
> d=5194027
>
> Unfortunately, there is only one other admin on the Persian Wikipedia
> besides me, I will not have access to the Internet for some time
> starting this Wednesday, and the process for electing a few new admin
> won't end until at least two weeks (and there are not so many eligible
> candidates either).
>
> Any recommendations?
>
> roozbeh
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l


subject: [Wikitech-l] Re: Parser, lists and XHTML

body:
Magnus Manske wrote:

> For the wiki source
>
> * unordered
> *#sub-ordered
>
> our parser does
>
>

>
unordered
>

>
sub-ordered

>

>

>

This is correct XHTML.

> http://www.devguru.com/Technologies/xhtml/quickref/xhtml_li.html

If you run their example through an XHTML validator, you get loads of
errors (the first error being "document type does not allow element "ul"
here; assuming missing "li" start-tag").  Maybe you shouldn't trust
every site you see :-)

Timwi


subject: [Wikitech-l] Re: Embed mediawiki ?

body:
Manuel VACELET wrote:

> I investigate to embed a wiki engine into another web application. As
> wikipedia user I think mediawiki is one of the best engine and I would
> integrate it. But I would have your developer point of view :
> Do you think it is a good idea to embed mediawiki as wiki engine or
> should I look for another tool ?

I am unsure what exactly you mean by "embed".  It is always possible to
install MediaWiki in a subdirectory of your server root, and have other
Web applications in different directories.


subject: [Wikitech-l] Re: Problem with watchlist

body:
Walter van Kalken wrote:

> Since yesterday it has not been possible to see the
> changes for more than 12 hours ago on my watchlist.

https://sourceforge.net/tracker/index.php?func=detail&aid=1007803&group_id=34373&atid=411192


from_name: Ralesk Ne'vennoyx

subject: [Wikipedia-l] Distributing fonts

body:
Pablo Saratxaga wrote:

>>Come on, where's the problem? We're offering 4-5 *GB* with pictures to
>>download for en already. And you say we're not equipped to serve a
>>single TTF file?
>
>
> I had read it as if the idea was to frentically upload all kind of fonts
> available.

No, nonono.  That?s the exact case with the ogg player reaction, of
course he didn?t mean to upload ALL possible GPL or PD players, only one
simple one or perhaps two, that would work on most computers (Windows,
OS 9, OS X, UNIX likes).  I would welcome people to program teeny-tiny,
simplistic, free and open source Ogg/Vorbis players -- nothing fancy,
just something that does the job (this one job only).

> Indeed one font is not very much; but the real point is that it is not
> the right place.
> The images are big, but they illustrate the articles; they are part of
> the information in the articles.

The letters that are missing ? those would be the information.

> A font, I don't see how it could be a part of the article (a font file
> cannot be directly usable from the web pages; it has to be downloaded
> and installed first; that is different to images, sound and video that
> can be directly seen/heard).

?If you cannot see some characters on this page, or see boxes or
question marks instead, download and install the free fonts available
[[TehFontPage|here]], or use [http://www.google.com/ Google] to look for
more.?

> A font file could be a part of the article of an article about
> typography or computer typography; but as it won't be directly usable
> from the web browser, probably it would be useless anyway.

Same goes for the aural content, you have to download it and listen
separately.  Are they too, useless?

Just some food for thought.


subject: [Wikitech-l] An alternate parser

body:
Brion Vibber wrote:
> Please take a look at the parser cache and see if it's missing any
> needed functionality.

What are the current cache hit/miss rates like? I wrote the last post
based on the premise that memcached only makes it possible to cache a
fraction of the article space, still making the parser churn quite a
bit, making people unhappy. If this is not the case, what are people
complaining about?

With another database as opposed to memcached, it's possible to
literally reduce things to one parser hit per edit, for all languages.
The parser would then need to be *really* slow for anyone to notice a
performance penalty, no?

Cheers,
Ivan.


subject: [Wikitech-l] Re: An alternate parser

body:
Magnus Manske wrote:

> OK, we all know that the current parser, while working, is not the final
> word. It is kinda slow due to multi-pass, the source is confusing, and
> there are some persistant bugs in it, like the template malfunctions.
>
> I therefore suggest a new structure:
> 1. Preprocessor
> 2. Wiki markup to XML
> 3. XML to (X)HTML
>
> Let me go through these. The preprocessor would basically do the
> template and variable stuff; dumb text replacement, like a C/C++
> preprocessor.

Well, isn't this going to create exactly the same problems as the ones
we have now?  We don't want "dumb text replacement" because "dumb text
replacement" is "dumb".

> I think of XML which can be generated from the wiki text /without any
> knowledge of the rest of the database/. The converter will not check,
> "does this article exist" or "is this an internal link, an image, an
> interwiki link, or what?". It should only convert "[[this|or that]]" to
> "<wikilink page='this'>or that</wikilink>". Also, it should produce only
> valid XML, no matter the input.

By choosing XML in preference over a native PHP structure, you are
essentially introducing unnecessary problems, such as having to ensure
XML validity.

> IMHO that would separate the actual *parsing* of the wiki markup from
> its *meaning*. There are useful methods, functions, libraries
> and-what-not for dealing with XML.

Yes, there are useful functions; however, they don't really do anything
that is particularly useful to specifically parsing text, or anything as
specific as this.  It is better to have PHP classes which can have
methods that we can define, extend, and modify.

Of course, is of my opinion, etc.

Timwi


from_name: Jan Hidders

subject: [Wikitech-l] An alternate parser

body:
On Friday 13 August 2004 20:59, Brion Vibber wrote:
> Magnus Manske wrote:
> > I therefore suggest a new structure:
> > 1. Preprocessor
> > 2. Wiki markup to XML
> > 3. XML to (X)HTML
>
> This doesn't actually solve any of the issues with the current parser,
> since it merely has it produce a different output format.
>
> The main problems are that we have a mess of regexps that stomp on each
> other all the time.

Are you kidding? That is exactly what it would solve! If you would let the
preprocessor be generated with a lex/yacc type of tool then you would for the
first time have a decent formal documentation of the wiki-syntax in the form
of a context-free grammar. That not only would give you a better idea of what
the wiki-syntax exactly is and tell you exactly whether any new mark-up
interferes with old mark-up, but you could also more easily add
context-sensitive rules (like replacing 2 dashes with — but only in
normal text). Moreover it would give you the power to make small changes to
the mark-up language because you could easily generate a parser that
translates all old texts to the new mark-up. Finally, having an explicit
grammar also makes it more easy to make sure that you actually generate
well-formed and valid XHTML, or anything else that you would like to generate
from it and that needs somehow to satisfy a certain syntax.

It's simply a briliant idea, and frankly I think it is in the long run as
unavoidable as the step to a database-backend. If there is performance
problem you could even consider storing the XML in the database so you only
need do the raw parse at write time and the xml parse at read time.

That hard part is of course to come up with the contex-free grammar (it should
probably be LALR(1) at that). Since I used to teach compiler theory I might
be of some help there.

-- Jan Hidders

PS. You could even get rid of the OCaml code since the Latex parsing could be
integrated in the general parser.


subject: [Wikitech-l] Re: An alternate parser

body:
Magnus Manske wrote:

> Or we could use one of these
> weird compiler-generating languages, or parser-generating ones, if there
> is such a thing. The point is, it will be spearate (read: independent)
> from the rest of the software, which will simplify things enormously, IMHO.

Personally, I am very much in favour of using such a parser generator.
Some time ago, someone here on this mailing list already proposed this,
but I can't find it now.  One major advantage of this would be that we
can extend the grammar and have the parser be generated from it.  We
would no longer have to actually tweak the parser.  Other advantages
included efficiency, and simply the assurance that this is the "correct
way", because all other professional applications do it this way.

The process is usually broken down into four phases:

(1) lexing -- turn raw text into series of tokens
(2) parsing -- turn series of tokens into parse tree
(3) processing
(4) compiling -- turn processed parse tree into requested output format

This is extremely general; this whole procedure can apply to programming
language compilers (e.g. gcc), markup processors (e.g. browsers, LaTeX)
and pretty much anything else that turns a text file in one format into
some other format (not necessarily text: in the case of a compiler, it
would be executable code). Because of this generality, many tools to
perform these tasks already exist.  In the case of step 1, this is what
"lex" does.  Step 2 is the field of expertise of parser generators such
as "yacc" or its free-software equivalent "bison".  These are C-centric
in the sense that they output C code; I'm sure PHP ones exist, but maybe
we want to use C for efficiency anyway.  Steps 3 and 4 are
application-dependent, so they are programmed manually, but given a
parse tree, they are easy.

The "process" step is particularly application-dependent; in the case of
a programming language compiler, for example, it might perform
optimisations.  In our case, it means:

(a) find template inclusions, recursively call this entire process with
     the template's wiki text and replace the template inclusion with the
     resulting parse tree;
(b) find links and determine if the page they point to is non-existent,
     a stub, etc., and "annotate" the parse tree accordingly;
(c) probably other little things I haven't thought of.

I would be more than willing to help with this, especially steps 3 and 4
:-), but since I have absolutely no experience with lex or bison, I
would need some help with those.

Have I mentioned yet that this is the only correct way to do this?  :-)

Timwi


subject: [WikiEN-l] Re: Another, unresolved security problem

body:
Jimmy O'Regan wrote:

> I remember having a conversation with Menchi on IRC about this; user
> customisations (http://meta.wikimedia.org/wiki/User_styles) can
> potentially be abused:

How can they?  The only CSS and JavaScript you can edit is the one that
is displayed only for you, and nobody else.  Of course, sysops can edit
other people's CSS and JavaScript, but if they do, and they insert such
malicious code, they pretty much deserve to be desysopped immediately.

Timwi


subject: [Wikitech-l] An alternate parser

body:
Brion Vibber wrote:
> The parser cache iirc does have to parse _differently_ for users with
> different options, so I don't know how much duplication there is.

This is probably worth looking into. With duplication and constant
growth working against you, 40GB isn't as much as it seems. I'm more
interested in your opinion about whether the one parser hit on edit
would solve the parser performance issues altogether, since it takes any
guesswork out of the picture and scales very easily.

Ivan.


subject:
[Wikipedia-l] Re: Nauruan and this ugly message under each
	en:article

body:
Roman Maurer wrote:

> Timwi pravi:
>
>> Having the URL on the screen doesn't do any harm.
>
> Sure it does.  It decreases the readability of the text.

Yes, maybe you are right -- and while we are at it, we might as well
remove those annoying tabs at the top.  And the distracting row of links
at the left.  And the article title, the TOC, and most importantly, the
article text.  They decrease readability like hell.

Timwi


subject: [Wikitech-l] An alternate parser

body:
On Friday 13 August 2004 22:46, Krzysztof Kowalczyk wrote:
> > >> I therefore suggest a new structure:
> > >> 1. Preprocessor
> > >> 2. Wiki markup to XML
> > >> 3. XML to (X)HTML
>
> Why XML for intermediate part? As I understand it, speed is important
> for WikiPedia code given it needs to scale to a very high usage.
> Servers are always overloaded.

A parser generated with yacc is extremely fast and needs very little memory.
The same holds for the XML parser in PHP. Since you don't want to write the
parser in PHP you have an interface problem anyway (you cannot simply
exchange a PHP data structure) and this would actually be a very efficient
solution.

-- Jan Hidders


subject: [Wikipedia-l] Re: Text-to-speech

body:
Magnus Manske wrote:

> I just found an AT&T demo site for text-to-speech synthesis:
>
> http://www.research.att.com/projects/tts/demo.html
>
> which appears to generate *way* better speech than I got from other
> (local installation) demos.

Well, personally, I find it rather disappointing, and I have heard
better ones even several years ago.  However, it would certainly be
pretty cool to have Wikipedia articles as sound files.

This might even combine well with the validation feature.  We could ask
them to synthesise an article whenever it reaches a certain level of
validation.  That way, even though Wikipedia can be edited by anyone,
people would not be able to abuse the system to use the software for
their own purposes.

Timwi


subject: [Wikitech-l] An alternate parser

body:
On Saturday 14 August 2004 00:49, Brion Vibber wrote:
> Jan Hidders wrote:
> [snip]
>
> > That hard part is of course to come up with the contex-free grammar (it
> > should probably be LALR(1) at that). Since I used to teach compiler
> > theory I might be of some help there.
>
> Yes, and that's the *only* part that will help. Having two or three or
> five intermediate formats doesn't do anything to help the problem --
> making the actual parser actually work token by token will.
>
> IMHO putting a lot of emphasis on output formats is a mistake, since it
> ignores the actual problem.

FWIW I completely agree with that. Having a real parser in C/C++ generated by
a parser-generator is IMHO the core of the idea, and if you need to interface
that somehow with the rest of the PHP code then XML is a good solution. I had
the impression that this is what Magnus meant anyway, but I may have been
wishful reading there.

-- Jan Hidders


from_name: Abe Sokolov

subject:
[WikiEN-l] Mintguy is an ad-hominem,
	British Upper Class POV revert war monger

body:
coxcustomer3 at cox.net wrote:

"Mintguy has this stuffy, toffee-nosed, Upper Class, British POV, Canonical
Fascism about every article and doesn't allow for American contributions on
British and British related topics by me."

I'm an American, I've never been accused of an 'aristocratic' bias, and I
use American English spellings. As the main author of a number of UK-related
articles (e.g., British Empire), I've only gotten to know Mintugy as a
helpful, diligent, and competent user.

If he is reverting American contributors, I bet that it's because their
edits are unconstructive, not because they're Americans.

-User:172

_________________________________________________________________
Check out Election 2004 for up-to-date election news, plus voter tools and
more! http://special.msn.com/msn/election2004.armx


from_name: Jim Cecropia

body:
First IANAL, but have worked for years with issues involving intellectual property.

The first question is: When was the material you want to use created? Since it was created during the '90s, it is in copyright, where or not a copyright notice appears.

Second. Who is the copyright owner? This is almost always the author, unless the work was done for hire AND the author contractually transferred his/her rights to another, or has otherwise assigned these rights. So assume it is the author, unless someone else can prove otherwise.

Third. Can you use the material because the copyright owner can't/doesn't want to be found? -- No.

Fourth. Can you use the material because you think the copyright owner wants it to be freely distributed? -- You'll need some kind of explicit proof of that, such as a statement by the copyright owner saying you can do it, or a dedication to the public domain.

Fifth. So you are essentially left with "fair use." Fair use is not a bright line. Generally, you may quote reasonable portions of a work in order to honestly critique it, especially if this is part of an intellectual or educational effort. You cannot quote so much as to spoil the copyright owners ability to market and profit from his own work. It is not your decision whether or not the work is commercially viable, etc. To go to an extreme, you obviously cannot quote an entire article and then make some comments and call it fair use.

Again, IANAL, but I hope this helps.

JC
----- Original Message -----
From: Robert <rkscience100 at yahoo.com>
Date: Fri, 13 Aug 2004 12:19:10 -0700 (PDT)
To: wikien-l at wikipedia.org
Subject: [WikiEN-l] When can an article be considered public domain?

> I am writing an article on the [[Kabbalah Center]], the
> for-profit religious group led by former insurance agent
> Feivel Gruberger, who now claims to be "Rabbi Philip Berg".
>
>
> There is a lengthy and carefully referenced article about
> him and his work called ''The Truth about the Kabbalah
> Centre'' which I got a photocopy of. It was published by
> the ''Task Force on Cults and Missionaries'', Los Angeles,
> CA in 1995. The references and facts stated therein match
> the claims in other articles, from newspapers. (Berg and hs
> group have been investiagted by journalists from the US and
> Israel; he is accused of running a cult and brainwashing
> some of his disciples, as well as scamming them out of
> large amounst of money, and endangering their health.)
>
>
> etc. etc.

--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm


from_name: Steven Melenchuk

subject: [Wikipedia-l] personal threats again

body:
This doesn't seem to be the first time this anon has come up in a
dispute - see some of the text at [[Talk:Azerbaijan]], [[Talk:South
Azerbaijan]], etc. for details. I'm currently in the process of talking
with this user about his apparent dispute and asking him to provide
evidence for his claims. In the meantime I suggest you attempt not to,
shall we say, "fuel his argument". Hopefully this will not escalate any
further than it already has...

~Grunt

Roozbeh Pournader wrote:

>Recently, an anonymous user only writing on talk pages has started
>attacking me heavily on the Persian Wikipedia (and also a little on
>the English one). He has also threatened me on the Persian Wikipedia
>with "I will start a war, both here and on the English Wikipedia. I
>will also get you kicked out of the Persian Academy" and things like
>that, and has ridiculed us by saying that blocking his IP address
>won't stop him, as he is using dynamic addresses.  This is some of his
>more polite wording (in English), where he is calling me a "wild dog":
>
>http://en.wikipedia.org/w/wiki.phtml?title=User_talk:Roozbeh&diff=5194299&oldid=5194027
>
>Unfortunately, there is only one other admin on the Persian Wikipedia
>besides me, I will not have access to the Internet for some time
>starting this Wednesday, and the process for electing a few new admin
>won't end until at least two weeks (and there are not so many eligible
>candidates either).
>
>Any recommendations?
>
>roozbeh
>_______________________________________________
>Wikipedia-l mailing list
>Wikipedia-l at Wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>
>
>


from_name: Roozbeh Pournader

subject: [Wikipedia-l] personal threats again

body:
Recently, an anonymous user only writing on talk pages has started
attacking me heavily on the Persian Wikipedia (and also a little on
the English one). He has also threatened me on the Persian Wikipedia
with "I will start a war, both here and on the English Wikipedia. I
will also get you kicked out of the Persian Academy" and things like
that, and has ridiculed us by saying that blocking his IP address
won't stop him, as he is using dynamic addresses.  This is some of his
more polite wording (in English), where he is calling me a "wild dog":

http://en.wikipedia.org/w/wiki.phtml?title=User_talk:Roozbeh&diff=5194299&oldid=5194027

Unfortunately, there is only one other admin on the Persian Wikipedia
besides me, I will not have access to the Internet for some time
starting this Wednesday, and the process for electing a few new admin
won't end until at least two weeks (and there are not so many eligible
candidates either).

Any recommendations?

roozbeh


from_name: Anthere

subject: [Wikipedia-l] Re: personal threats again

body:
Roozbeh Pournader a ?crit:
> Recently, an anonymous user only writing on talk pages has started
> attacking me heavily on the Persian Wikipedia (and also a little on
> the English one). He has also threatened me on the Persian Wikipedia
> with "I will start a war, both here and on the English Wikipedia. I
> will also get you kicked out of the Persian Academy" and things like
> that, and has ridiculed us by saying that blocking his IP address
> won't stop him, as he is using dynamic addresses.  This is some of his
> more polite wording (in English), where he is calling me a "wild dog":
>
> http://en.wikipedia.org/w/wiki.phtml?title=User_talk:Roozbeh&diff=5194299&oldid=5194027
>
> Unfortunately, there is only one other admin on the Persian Wikipedia
> besides me, I will not have access to the Internet for some time
> starting this Wednesday, and the process for electing a few new admin
> won't end until at least two weeks (and there are not so many eligible
> candidates either).
>
> Any recommendations?
>
> roozbeh

I am distressed to know that this user has started again. I think it is
very important that we take such matters very seriously, and I suggest
that you mail us again about that, so that we see what we can do that
would be acceptable to you from a personal point of view. I am not sure
what is the best way to do this toward the Academy for example.

As for the persian wikipedia itself, I recommand that you take it easy
with the election process if there is an emergency. We can very well
grant temporary sysophood to any person you think is okay (elections can
proceed in parallel in the coming weeks). To have anyone named sysop, if
you have no bureaucrat, ask any steward for emergency sysophood. I would
recommand firm blocking and immediate deletions of threats. Even if the
the ip is changing, perhaps a range block could do the deal.

However, I think your personal safety is more important than threats on
the wiki itself.

ant


subject: [Wikipedia-l] Re: Small fund-rising improvements.

body:
Krzysztof Kowalczyk a ?crit:
> I was just looking on Foundation's fund-rising page and have two comments.
>
> 1. I think that "Merchandise" and "Donations" should be separated,
> similar to what http://www.mozilla.org/ does. I believe more people
> would visit "Merchandise" or "WikiPedia merchandise" resulting in more
> sales => more funding. I believe that because in people's minds
> "donating" and "buying cool stuff" (even if it ultimately leads to
> funding a good cause) is strongly separated.

I absolutely agree with you !

I invite you to put your thoughts here
http://meta.wikimedia.org/wiki/Wikimedia_website

I invite you to help us here as well :-)
http://wikimedia.org/wiki/About_Wikimedia

> In more specific terms, things that could be done:
> * a link to "Merchandise" on main wikipedia.org page, in the nav
> section, next to "Donations" link
> * this link goes to a separate page on foundation's website which only
> deals with merchandise (and not all donations options)

I think it is best that only one link is kept, but that on the donation
page, a proeminent link will lead to "Merchandise".

> In general I think that foundation should study what Mozilla project
> does for fundraising as they are not larger/more visible project but
> according to http://forums.mozillazine.org/viewtopic.php?t=110721 they
> do much better at getting funding via. t-shirt sales ($15,000.00 for
> mozilla vs. $460.90 for wikipedia).
>
> Things that I think mozilla.org does better:
> * much nicer web design. No offense, but
> http://wikimediafoundation.org/fundraising is bad, both functionally
> (it's hard to read, the copy isn't that great) and visually (compare
> to http://www.mozillastore.com/products/clothing)
> * selling t-shirts on open-source conventions (linuxcon/oscon/devday)
> which is what http://forums.mozillazine.org/viewtopic.php?t=110721
> implies that mozilla foundation is doing (I don't really know, I
> haven't been there)

What about helping us set a page for the [[buying cool stuff]] ? I agree
with you this is much needed. On this page, we should not only list tee
shirts and related items, but also list items such as wikireaders, CD
distributions etc...

> 2. More t-shirt designs.
>
> I think that a design that gives emphasis on personal involvement in
> the project would be more attractive to people than a generic design
> with a logo. E.g. designs with teksts such as "I contribute to
> WikiPedia.org" or "I wrote for Encyclopedia \n wikipedia.org", "I
> write Encyclopedia articles \n wikipedia.org". I'm not claiming that
> exactly this wording should be used - I just want to give an example
> of what I mean (emphasis on contributing/writing for
> WikiPedia/Encyclopedia).

What about a small contest page ?

> Also, I think that Mozilla's "$50 donation t-shirt"
> (http://www.mozillastore.com/products/donations/50shirt) is a good
> idea. It could even had a text that says that e.g. "I donated to
> WikiPedia", "I make Free Encyclopedia possible", "I fund Free
> Encyclopedia" - something along those lines.
>
> Krzysztof Kowalczyk | http://blog.kowalczyk.info

Agreed, but only if some of the profit goes to the foundation or to the
project in general (through the local associations).

ant