from_name: Jens Frank

subject: [Wikitech-l] Possible bug

body:
On Fri, Apr 09, 2004 at 09:26:10PM +0530, Arvind Narayanan wrote:
>
>
> Hi,
>
> See http://en.wikipedia.org/w/wiki.phtml?title=User:Arvindn/Chess&oldid=3122727
>
> The footer is displaced to the right (in Gecko; haven't checked anything else).
>
> At the same time the indents in the discussion to the right of
> the image at the bottom are not showing. I think the two might
> be related.
>

The small chessboard at the end opens two
s:

but only one is closed:

	[[Image:chess_rll40.png|20px|]]

This causes rendering errors. Using Wiki table markup instead of HTML,
this kind of errors can be avoided.

Regards,

JeLuF


list: wikitech-l

source: pipermail-mbox

from_name: Brion Vibber

subject: [Wikitech-l] IE 24-bit PNG transparency

body:
IE for Windows doesn't support 24-bit transparent PNGs normally, but
with some hacking you can use a roundabout method to display them on
IE5.5+:

http://support.microsoft.com/default.aspx?scid=kb;en-us;294714

I managed to get the logo in MonoBook displaying with transparency by
sticking this hack into the IEFixes.css:

#portlet-logo a,
#portlet-logo a:hover {
	background-image: none;
	cursor: hand;
	filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='/
~brion/rel1.3/stylesheets/monobook/wiki.png',sizingMethod='crop');
}

Unfortunately it seems to want a URL relative to the HTML page, not the
stylesheet, so we can't hard-code it in the file. It could perhapsbe
hacked in at runtime by JavaScript (yuck!), or by a


from_name: Arvind Narayanan

subject: [Wikitech-l] Possible bug

body:
Hi,

See http://en.wikipedia.org/w/wiki.phtml?title=User:Arvindn/Chess&oldid=3122727

The footer is displaced to the right (in Gecko; haven't checked anything else).

At the same time the indents in the discussion to the right of
the image at the bottom are not showing. I think the two might
be related.

Arvind
--
Its all GNU to me


subject: [Wikitech-l] Possible bug

body:
On Fri, Apr 09, 2004 at 07:07:11PM +0200, Jens Frank wrote:
> The small chessboard at the end opens two
s:
>
>

>

>
>
>
 		solid #8888aa; width:160px; height:160px; float:left;
> 		margin-right: 1em;">
>
>

>
> but only one is closed:
>
> 	[[Image:chess_rll40.png|20px|]]
>

>

>
>
Oh, sorry, thanks for pointing that out.
>
> This causes rendering errors. Using Wiki table markup instead of HTML,
> this kind of errors can be avoided.
Unfortunately wiki markup doesn't work for the chessboard in MSIE,
which displays gaps between the pieces.

Arvind
--
Q: Do you ever think about quantum computing?
Linus: I think that's a load of bull.
(From a Linux Lunacy cruise interview. After the presumptuous disparagement
of QC, Linus goes on to confuse it with DNA computing.)


list: wikipedia-l

from_name: Gabriel Beecham

subject: [Wikipedia-l] Renaming Wikisource and Wikibooks modules

body:
Taking 'being bold' to a new level for me, I've
started a new discussion at

http://meta.wikipedia.org/wiki/Renaming_Wikisource_and_Wikibooks_modules

about renaming articles at Wikisource and Wikibooks so
that different language versions don't conflict.
Please comment on the proposal at the above page.

----
- Gabriel Beecham
gabriel beecham {aT} yahoo {DoT} co {dOt} uk

____________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html


from_name: Evan Prodromou

subject: [Wikitech-l] Re: wpSection=new flood attack on zh

in_reply_to:
<c56og4$msr$1@sea.gmane.org> (timwi@gmx.net's message of "Fri,
	09 Apr 2004 19:02:44 +0100")

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

    T> I often send quite a number of POST requests in short sequence
    T> when there are a large number of articles to change in a very
    T> uniform way, for example.  I thought one of the principles of
    T> Wiki was that the freedom to do legitimate things should never
    T> be sacrificed, and instead sysops should be given the power to
    T> undo damage easily.

Wiki editorial integrity depends on having a community of
well-intentioned people who can keep up with and correct unwanted
edits. If the edits are made by software like a bot, their rate can
outpace even a large community.

Edit throttling just serves to keep the edit rate of bots down to a
level that human beings can keep up with. In other words, bots
shouldn't edit faster than the fastest human.

The page on meta has more on this:

    http://meta.wikipedia.org/wiki/Edit_throttling

The goal with throttling is that humans would never notice it, nor
policy-compliant bots.

~ESP

--
Evan Prodromou <evan at wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide


subject: [Wikitech-l] Postgres suport for MediaWiki

body:
On Apr 10, 2004, at 01:56, Bernhard Naegele wrote:
> The following message occurs, when I load the index.php file:
> ************Start error message ***********************
> Warning: mysql_error(): supplied argument is not a valid MySQL-Link
> resource
> in /raid00/httpd/htdocs/mediawiki/includes/Database.php on line 196

Looks like a failure to connect to the database. IIRC there was a bug
in the install script that failed to set up the user account at least
under some circumstances... Change lines 196-197 in Database.php to:

	function lastErrno() { return mysql_errno(); }
	function lastError() { return mysql_error(); }

(remove the "$this->mConn" from each line). It ought now to give out a
more useful error message.

-- brion vibber (brion @ pobox.com)


subject:
[Wikitech-l] Re: [MediaWiki-CVS] phase3/includes Parser.php, 1.74,
	1.75

body:
On Apr 10, 2004, at 03:46, Erik Moeller wrote:
> ! 			$state["strong"] = $state["em"] = $token["pos"];
> ! 			$state["strong"] = $state["em"] = isset($token["pos"]) ?
> $token["pos"] : true;

Maybe it's just because it's late, but those don't look like they do
the same thing to me. An unset variable evaluates to boolean false, not
true.

-- brion vibber (brion @ pobox.com)


body:
On Apr 10, 2004, at 04:24, Bernhard Naegele wrote:
>
> Sorry! The wiki is experiencing some technical difficulties, and cannot
> contact the database server.
>
> Have you any hint for me?

Check that the user permissions were granted. Can you manually connect
to the database using the assigned username and password? If not,
modify a copy of maintenance/users.sql and apply it as root.

-- brion vibber (brion @ pobox.com)


from_name: Erik Moeller

subject: [Wikitech-l] IMDB update

body:
Hi!

Because of IMDB's no-bot policy I inquired a couple of weeks ago what the
best way would be to submit links to Wikipedia articles about movies, so
they can add them to the "External reviews" section for each movie. Here's
the reply:

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

I apologize for the delay in getting back to you (I was out of the office
for the past 2 weeks). The easiest thing to automatically submit several
links is to send them to our mail server. You will need to send a
specially formatted email to adds at imdb.com with details of the title and
link.

Please note that our mail server doesn't normally accept incoming email
from unauthorized users so you will need to let us know the email address
of the sender so we can allow access to it.

This is the syntax you will need to use.

URLTITLE
title|type|URL|description|
END

or

URLNAME
name|type|URL|description|
END

where:

title = Title of film exactly as it appears on IMDb.com
type = a 3-letter code that identifies the type of link
URL = the link
description = description of the link

"type" can be one of the following:

COM  comments/reviews
IMG  image
SND  sound
MOV  movie
FAQ  Frequently Asked Questions list.
OFF  official sites
POS  movie posters
TRA  movie trailers
MSC  miscellaneous i.e. anything that doesn't fit into a type above.

a few examples:

URLTITLE
Alien (1979)|COM|http://crazy4cinema.com/Review/FilmsA/f_alien.html|Crazy for Cinema
Alien (1979)|COM|http://efilmcritic.com/hbs.cgi?movie=583|eFilmCritic
Alien (1979)|COM|http://www.igs.net/~mtr/haiku-reviews.html#Alien|Haiku Reviews
Cheaper by the Dozen (2003)|COM|http://www.suntimes.com/ebert/ebert_reviews/2003/12/122402.html|Roger Ebert, Chicago Sun-Times
Jaws (1975)|MSC|http://www.sharks.net/bigger_boats.html|Real shark attacks
END

or

URLNAME
Garbo, Greta|IMG|http://www.goldensilents.com/stars/gretagarbo.html|Golden Silents Portrait Photos|
Eastwood, Clint|MSC|http://www.sensesofcinema.com/contents/directors/03/eastwood.html|Senses of Cinema -  Great Directors Critical Database|
Hitchcock, Alfred (I)|MSC|http://hitchcock.tv/|Alfred Hitchcock - The Master Of
Suspense|
END

What I suggest is that you create a sample submission and send it to
me along with the email address that you would like to use as a
submitter, so I can check that everything looks ok and set things
up on our side.

GC

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

So what we need is a mailbot which takes a list of Wikipedia articles and
the corresponding IMDB titles, apparently of the syntax "Title (year)" and
generates and sends the respective mails. Preferably it would keep track
of its submissions (could be done easily in Perl using a tie'd hash) so we
can update the list. For extra points, it could try to auto-guess the
title in the IMDB, say, by filtering out "(movie)" from the Wikipedia
title and looking for the first [1-2][0,8,9][0-9][0-9] match in the
article.

Mike, are you still interested?

Regards,

Erik


list: wikien-l

from_name: Jimmy Wales

subject: [WikiEN-l] remove my name from this mailing list

body:
Geoff Burling wrote:
> > Done.
> >
> > Adam [name omitted for privacy reasons] wrote:
> >
> > > You removed Helga's name -- now remove mine.
> > >
> By doing this, has Adam/Lir's name been editted from the mail archive, or
> was she/he merely unsubscribed?

Oh, just unsubscribed.  I didn't take him to mean that.  Perhaps I was
mistaken.

> And yes, I know this horse is dead; I'll stop beating it.

Lir's behavior is often difficult for me to understand.  For most
users, I would think that sending a big "f**k you all" email to the
list would be sufficient grounds for people to start talking about
banning, but of course with Lir, there's been no general protest
because we're all more or less tired of the whole scene to the point
that we're really past caring.

If Lir wants to go away, that's fine with me.

If Lir wants his real name purged from the mailing list archives (and
I can understand why he might, given the whole history, and presumably
he's going to be applying to grad. school or jobs soon enough, so he
might not want all that stuff out there on the net about him under his
real name) then I will do it for him personally as a friendly gesture.
I see no harm in it, and especially if it helps him to find peace, I'm
all for it.

If Lir wants "Lir" purged from the mailing list, it would take some
convincing for me to want to do that.  It's actually a fair amount of
work to go through and do it.

--Jimbo


from_name: Bernhard Naegele

body:
Hello,
I tried to install Mediawiki together with MySQL (even if I want to port
Mediawiki to PostgreSQL).
I took the MySQL-4.0.18, apache-1.3.28 and  php-4.2.3 source.
For Mediawiki installation I took the index.php script in the wiki/config/
directory (web-based installation). This all went well until the first start
of the index.php script in the main directory. Here I have now some problems
with connecting to the database.
The following message occurs, when I load the index.php file:
************Start error message ***********************
Warning: mysql_error(): supplied argument is not a valid MySQL-Link resource
in /raid00/httpd/htdocs/mediawiki/includes/Database.php on line 196

 Warning: Cannot add header information - headers already sent by (output
started at /raid00/httpd/htdocs/mediawiki/includes/Database.php:196) in /
raid00/httpd/htdocs/mediawiki/includes/Database.php on line 415

 Warning: Cannot add header information - headers already sent by (output
started at /raid00/httpd/htdocs/mediawiki/includes/Database.php:196) in /
raid00/httpd/htdocs/mediawiki/includes/Database.php on line 450

 Warning: Cannot add header information - headers already sent by (output
started at /raid00/httpd/htdocs/mediawiki/includes/Database.php:196) in /
raid00/httpd/htdocs/mediawiki/includes/Database.php on line 451
 Sorry! The wiki is experiencing some technical difficulties, and cannot
contact the database server.
*************End Error Message****************

Has anyone an idea, what the problem for this Error-Messages could be? I
wouldn's spent to much time in finding problems with MySQL. My goal is to
come up with Postgres as fast as possible......
Best regards,
Bernhard

Am Samstag, 27. M?rz 2004 21:01 schrieb Ivan Krstic:
> Hi Bernhard,
>
> it's very arguable what exactly is meant by "more professional".
> Generally speaking, speed is MySQL's forte, and is also what MediaWiki
> has a great need for (particularly with Wikipedia). The magazine
> articles you've read were probably referring to some of the more
> "enterprise" features (MySQL for a long time did not support
> transactions, and replication was dubious at best) which MediaWiki
> doesn't really need. I don't personally think there is much benefit in
> letting the code use Postgres, but if you're willing to put in the
> effort - hey, great, send a patch.
>
> As for the MediaWiki table structure, while I'm sure we can help with
> problems you might encounter, it might be easier for you to install,
> temporarily, MySQL on one of your machines. MySQL binaries are available
> for a slew of operating systems and architectures, so it shouldn't take
> very long.
>
> Cheers,
> Ivan
>
> >>> Bernhard.Naegele at t-online.de 03/27/04 12:02 PM >>>
>
> [...]
> In every article about Open Databases I read, that Postgres is a more
> professional database than MySQL, so I wonder that there is no interrest
> in suporting also Postgresql, or is there also interrest?
>
>
>
> However, I have a running Postgres database and I want to run also a
> Wiki
> Wiki. The question for me is now if I should take PHPWiki which has
> Postgres
> support or if I should spend some time in enhancing MediaWiki.
> At the moment, it seams that MediaWiki has more interesting features
> than
> PHPWiki.......
> So my first question: Was there a demand for Postgres in the past?
> Second: Is there anyone who can suport me if I have some question about
> MySQL
> (table-structure of MediaWiki) support of MediaWiki? I don't want to
> install
> also MySQL on some of my computers......
> Best regards,
> Bernhard
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l


body:
Brion-
> On Apr 10, 2004, at 03:46, Erik Moeller wrote:
>> ! 			$state["strong"] = $state["em"] = $token["pos"];
>> ! 			$state["strong"] = $state["em"] = isset($token["pos"]) ?
>> $token["pos"] : true;

> Maybe it's just because it's late, but those don't look like they do
> the same thing to me. An unset variable evaluates to boolean false, not
> true.

This does not appear to be the case, maybe because it is an associative
array and $token["pos"] is somehow a non-zero value. If you set the value
to false, the parser breaks (no error, just screwed up formatting).

Regards,

Erik


body:
Hello Brion,
sorry, but the only message which is now comming out is:

Sorry! The wiki is experiencing some technical difficulties, and cannot
contact the database server.

Have you any hint for me?
Best regards,
Bernhard

Am Samstag, 10. April 2004 11:54 schrieb Brion Vibber:
> On Apr 10, 2004, at 01:56, Bernhard Naegele wrote:
> > The following message occurs, when I load the index.php file:
> > ************Start error message ***********************
> > Warning: mysql_error(): supplied argument is not a valid MySQL-Link
> > resource
> > in /raid00/httpd/htdocs/mediawiki/includes/Database.php on line 196
>
> Looks like a failure to connect to the database. IIRC there was a bug
> in the install script that failed to set up the user account at least
> under some circumstances... Change lines 196-197 in Database.php to:
>
> 	function lastErrno() { return mysql_errno(); }
> 	function lastError() { return mysql_error(); }
>
> (remove the "$this->mConn" from each line). It ought now to give out a
> more useful error message.
>
> -- brion vibber (brion @ pobox.com)
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l


subject: [Wikitech-l] Re: IE 24-bit PNG transparency

body:
On Apr 10, 2004, at 13:33, Gabriel Wicke wrote:
> Done, you can try it at http://test.wikipedia.org/wiki/Main_Page. You
> might have to refresh the page or log in to get the xhtml with the js
> include. The logo doesn't get transparent until the page has loaded
> (it's
> using the onLoad handler), a bit annoying but better than nothing.

Great! It's not included in standard skin, though, I'll fix that up.
(For that matter, since Standard isn't Standard anymore, I'm thinking
we should rename it Classic.)

While I'm there, though, I notice that IE6/Win is showing the dreaded
Blue Border Around Checkboxes and Radio Buttons problem that has
plagued most browsers I've tested MonoBook with.

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] "Powered by MediaWiki" (and copyright)

body:
On Feb 10, 2004, at 19:26, Dan Carlson wrote:
> I was doing a little bit of fiddling around with my site's layout this
> evening, and I had an idea that someone more involved in the MediaWiki
> development might be interested -- a couple of little "powered by"
> badges that people can add to their site layout to show their support
> for this excellent software.
>
> I've quickly tossed together some ideas based on a couple of images I
> "borrowed" from the MediaWiki SourceForge page -- they're just a rough
> idea, so if anyone wants to develop the idea further, they're welcome
> to it.  I can pass on the original Fireworks .png files, though it
> might be better to use the original source files, 'specially since I
> don't have the exact font used for the word "MediaWiki" and had to
> approximate to create the "Powered By" part.

Good things come to those that wait. ;) They look great, Dan, thanks!

I've finally got around to adding in the 88x31 icon, which will display
in the page footer. Now up at http://test.wikipedia.org/ (you may have
to force a reload to update the stylesheet).

Test also now shows an optional GNU FDL icon which I threw together.
(It's ugly, sorry; the XCF is right next to the live PNG, so anybody
who wants to improve, please do.) To configure the FDL icon and
copyright notice (and to include this info in the Creative Commons and
Dublin Core metadata links) do something like this:

	$wgRightsPage = "Wikipedia:Copyrights";
	$wgRightsUrl = "http://www.gnu.org/copyleft/fdl.html";
	$wgRightsText = "GNU Free Documentation License 1.2";
	$wgRightsIcon = "$wgUploadPath/gnu-fdl.png";

Or to configure for a Creative Commons license, one might do this:

	$wgRightsUrl = "http://creativecommons.org/licenses/by-sa/1.0/";
	$wgRightsText = "Creative Commons Attribution-ShareAlike License";
	$wgRightsIcon =
"http://creativecommons.org/images/public/somerights.gif";

The "copyright" message plus $wgRightsText replaces the old "gnunote"
message in page footers. There are still other hardcoded FDL references
remaining that need to be cleaned up, though.

-- brion vibber (brion @ pobox.com)


from_name: Gabriel Wicke

body:
On Fri, 09 Apr 2004 19:57:33 -0700, Brion Vibber wrote:

http://www.allinthehead.com/code/samples/bgsleight.js does the fix for bg
images, works fine with 6.0 and 5.5 (try it at http://wiki.aulinx.de/).
Also circumvents the path problem. The only problem is that the link
cursor isn't shown by default when hovering the link, that might be
solvable via css.

Both the background image and the plain image version can go into an
IEFixes.js file that's included from the conditional-comment part that's
already including the css filter. That way it's not downloaded by better
browsers.
--
Gabriel Wicke


body:
On Sat, 10 Apr 2004 22:04:20 +0200, Gabriel Wicke wrote:
> Both the background image and the plain image version can go into an
> IEFixes.js file that's included from the conditional-comment part that's
> already including the css filter. That way it's not downloaded by better
> browsers.

Done, you can try it at http://test.wikipedia.org/wiki/Main_Page. You
might have to refresh the page or log in to get the xhtml with the js
include. The logo doesn't get transparent until the page has loaded (it's
using the onLoad handler), a bit annoying but better than nothing.
--
Gabriel Wicke


from_name: Arwel Parry

subject: [Wikitech-l] Re: IMDB update

body:
In message <96bVyR6hpVB at erik_moeller>, Erik Moeller
<erik_moeller-Mmb7MZpHnFY at public.gmane.org> writes
>So what we need is a mailbot which takes a list of Wikipedia articles
>and the corresponding IMDB titles, apparently of the syntax "Title
>(year)" and generates and sends the respective mails. Preferably it
>would keep track of its submissions (could be done easily in Perl using
>a tie'd hash) so we can update the list. For extra points, it could try
>to auto-guess the title in the IMDB, say, by filtering out "(movie)"
>from the Wikipedia title and looking for the first
>[1-2][0,8,9][0-9][0-9] match in the article.

Not forgetting that leading definite articles go at the end of the
title,. so our "The_Lord_of_the_Rings:_The_Return_of_the_King_(movie)"
becomes "Lord of the Rings: The Return of the King, The (2003)".

--
Arwel Parry
http://www.cartref.demon.co.uk/


from_name: Anthere

subject: [Wikipedia-l] statistics

body:
I think I need to have the rough number of hits per
day on wikipedia (whole project) or number of pages
per day...but I am not sure how to read the statistics
pages; and I would prefer to avoid saying something
entirely stupid by ignorance.

Could someone help me here before I say that the
number of visits per day is 2 million or 20 million or
200 millions or whatever ?

please ?

thanks

__________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html


from_name: Kai Kumpf

subject: [Wikipedia-l] backlinks

body:
Dear all
it is now more than two years that I first started to get involved in
Wikipedia. I have followed the explosion of interlinked free information
with some incredulity and deep fascination (not to mention heavy active
contributing). Still there is something about the appearance which I'm
missing sadly: I find that most wikis support backlinks via a
hyperlinked heading title. Is Wikipedia trying to appear more
distinguished by hiding backlinks in a shyly hidden menu item variously
called "what links here", "Links auf diese Seite ", etc. that only the
few people familiar with collaborative workspaces will recognize as
being of any use at all? From my point of view backlink functionality
should be inherent in a conspicuous place in the page, most likely the
title. Think of the vastly increased usefulness when people are enabled
to comfortably navigate not only forwards but backwards as well. The
1:many relationship from an article to its referring articles is part of
the knowledge domain partly covered by the respective article and cannot
be underestimated or -rated in any way.
Please consider eventually heaving backlinks towards the top!

Hallo
nun bin ich schon seit mehr als zwei Jahren aktiver Teilnehmer an der
Wikipedia und habe die Explosion vernetzter, freier Information mit
einiger Ungl?ubigkeit, Faszination und schliesslich auch manchmal
ausschweifender Editiert?tigkeit verfolgt. Leider gilt es nach wie vor
ein - wie ich meine - gro?es Manko zu beseitigen. Die allermeisten Wikis
unterst?tzen R?ckverweise (backlinks) ?ber einen Hyperlink in der
Artikel?berschrift. Versucht Wikipedia sich vom mainstream abzusetzen,
indem sie backlinks in dem scheu verborgenen Men?punkt "links auf diese
Seite" versteckt? Auf diese Weise werden Leute, die keine Ahnung von
Wikis haben kaum je zur Erkenntnis gelangen, welchen Stellenwert die
R?ckverlinkung eigentlich besitzt. Meiner Meinung nach sollte der
Backlink offensichtlicher platziert werden, die Titelzeile bietet sich
dazu selbstverst?ndlich an. Backlinks steigern den Nutzen einer
hyperverlinkten Enzyklop?die, da ein Wissensgebiet immer durch beide
Fragerichtungen definiert wird: "Wo wird sich daf?r interessiert" und "
Was ist direkt daf?r von Interesse". Man kann die Bedeutung dieser
1:m-Beziehung nicht hoch genug einsch?tzen!
Folglich: Ebnet dem Backlink den Weg nach Oben!

8-)
kku/kakau <http://de.wikipedia.org/wiki/Benutzer:Kku>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20040411/8eb71429/attachment.htm


from_name: Peter Jaros

subject: [Wikipedia-l] backlinks

body:
On Apr 11, 2004, at 5:03 AM, Kai Kumpf wrote:

> Dear all
> it is now more than two years that I first started to get involved in
> Wikipedia. I have followed the explosion of interlinked free
> information with some incredulity and deep fascination (not to mention
> heavy active contributing). Still there is something about the
> appearance which I'm missing sadly: I find that most wikis support
> backlinks via a hyperlinked heading title. Is Wikipedia trying to
> appear more distinguished by hiding backlinks in a shyly hidden menu
> item variously called "what links here", "Links auf diese Seite ",
> etc. that only the few people familiar with collaborative workspaces
> will recognize as being of any use at all? From my point of view
> backlink functionality should be inherent in a conspicuous place in
> the page, most likely the title. Think of the vastly increased
> usefulness when people are enabled to comfortably navigate not only
> forwards but backwards as well. The 1:many relationship from an
> article to its referring articles is part of the knowledge domain
> partly covered by the respective article and cannot be underestimated
> or -rated in any way.
> Please consider eventually heaving backlinks towards the top!

I realize that for people used to other wikis this functionality might
seems
misplaced, but to me it it much clearer.  When I first arrived here I
knew
exactly what "What links here" meant.  While I had seen other wikis
before,
Wikipedia was the first I really used.  When I tried to use other types
of wikis,
one of my fist thoughts was "Where are the backlinks?"  I saw that the
title was
a link, but I figured it was a link to the same page, after all, a link
that
reads "AssumeGoodFaith" ought to go to the page AssumeGoodFaith.

Many Wikipedians do not come from a wiki background.  So I don't think
it's about
appearing distinguished.  I think it's about being clear to the most
people.

Peter

                                  -- ---<>--- --
                        A house without walls cannot fall.
           Help build the world's largest encyclopedia at Wikipedia.org
                                  -- ---<>--- --


subject: [Wikitech-l] Moreri

body:
There's a batch compression of de's old revisions running on moreri.
This doesn't seem to enjoy coexisting with apache+wiki, sending the
machine into *huge* loads (~50) every few minutes, so I've shut down
apache on that machine to take it out of the rotation and avoid bogging
things down.

-- brion vibber (brion @ pobox.com)


from_name: Timwi

body:
Evan Prodromou wrote:

> Edit throttling just serves to keep the edit rate of bots down to a
> level that human beings can keep up with. In other words, bots
> shouldn't edit faster than the fastest human.

No matter what throttling you choose, I will hit the limit at some
point, I'm sure...


from_name: Mike Friedman

subject: [Wikitech-l] Re: IMDB update

references:
<96bVyR6hpVB@erik_moeller> <LraOrkJppGeAFwJF@cartref.demon.co.uk>
	<c5c7b7$rbh$1@sea.gmane.org>

body:
On Apr 11, 2004, at 3:46 PM, Timwi wrote:

> Not to mention that titles are in their original language, so our
> [[Run Lola Run]] becomes "Lola rennt (1998)", and our [[Life Is
> Beautiful]] becomes "Vita ? bella, La (1997)".
>

I've been researching the best way to approach this recently, and it
seems to me it would work better if we went in the opposite direction,
and imported IMDB's core data (not including reviews and comments and
so forth) into Wikipedia with a standard template, similarly to what's
been done with US Census data. For movies with existing pages, we could
stick the data in [[Movie Title/IMDB]] with a standard note on the
existing page that the data needs to be merged. I think we would need
to request a license from IMDB (their copyright page is not
particularly clear on the matter: http://www.imdb.com/conditions) but
they seem to allow non-commercial use.

Mike Friedman


from_name: Thomas Luft

subject: [Wikitech-l] Deletion log is parsed and breaks layout

body:
Hi,

I don't know if this error was already reported, at least I found no bug
report at sourceforge. When viewing the deletion log
(http://de.wikipedia.org/wiki/Wikipedia:L%F6sch-Logbuch) of the German
Wikipedia there are several deleted entries which get parsed and break
the layout of the page. I just cheked en: and there it works normal?!

Any clues?

Regards

Thomas aka Urbanus


from_name: Erik Zachte

subject: [Wikipedia-l] statistics

body:
Anthere wrote:
"I think I need to have the rough number of hits per day on wikipedia (whole
project)"

Page requests:

Look at http://www.wikipedia.org/wikistats/EN/TablesUsagePageRequest.htm

Daily 4.4 million pages are requested for all Wikipedias, 1.8 million for
en:
This is slightly less than in March.

Visitors:

Look at http://www.wikipedia.org/wikistats/EN/TablesUsageVisits.htm

Daily 586,000 people visit any wikipedia. 215,000 visit en:
This is slightly less than in March.

Note that Webalizer may count several visits per day by one person as
several unique visitors if the time between those vists is several hours, so
a (very) small correction downwards is needed.

Figures may be influenced by current server setup (squids, etc), maybe
visitors are counted once per squid, or something like that, I don't know.

---

By the way: this allows me to say that the bottom line on both pages
contains nonsensical percentual forecasts, I already spotted this before, so
fix has been submitted.

Erik


from_name: Tim Starling

body:
"Timwi" <timwi at gmx.net> wrote in message
news:c56og4$msr$1 at sea.gmane.org...
> Tim Starling wrote:
>
> > * Limiting the rate at which any given IP address can send POST
requests,
> > i.e. throttling
>
> I often send quite a number of POST requests in short sequence when
> there are a large number of articles to change in a very uniform way,
> for example.  I thought one of the principles of Wiki was that the
> freedom to do legitimate things should never be sacrificed, and instead
> sysops should be given the power to undo damage easily.

Ward Cunningham doesn't have any problem with the idea of edit throttling.
He recently implemented such a throttle on the Portland Pattern Repository,
mainly for the purpose of slowing down trolls. Changes to a wiki must be
reviewed, this is how quality is ensured. If a single user makes changes
very quickly, this can damage quality. Also, bots allow users to circumvent
soft security techniques. The freeedom to allow bots to operate unfettered
is not among the principles of the Wiki Way. The idea of allowing users to
do damage which only sysops can revert is against wiki principles.

-- Tim Starling


subject: [Wikitech-l] Re: IMDB update

body:
Arwel Parry wrote:
> In message <96bVyR6hpVB at erik_moeller>, Erik
> Moeller
> <erik_moeller-Mmb7MZpHnFY at public.gmane.org> writes
>
>> So what we need is a mailbot which takes a list of Wikipedia articles
>> and the corresponding IMDB titles, apparently of the syntax "Title
>> (year)" and generates and sends the respective mails. Preferably it
>> would keep track of its submissions (could be done easily in Perl
>> using a tie'd hash) so we can update the list. For extra points, it
>> could try to auto-guess the title in the IMDB, say, by filtering out
>> "(movie)" from the Wikipedia title and looking for the first
>> [1-2][0,8,9][0-9][0-9] match in the article.
>
> Not forgetting that leading definite articles go at the end of the
> title,. so our "The_Lord_of_the_Rings:_The_Return_of_the_King_(movie)"
> becomes "Lord of the Rings: The Return of the King, The (2003)".

Not to mention that titles are in their original language, so our [[Run
Lola Run]] becomes "Lola rennt (1998)", and our [[Life Is Beautiful]]
becomes "Vita ? bella, La (1997)".

Quite obviously, this cannot be automated.

Timwi


subject: [WikiEN-l] Re: Human-assisted spelling bot?

body:
Jimmy Wales wrote:

> Also, your attitude is very very barnstar.

And your terminology is very very adjective! :-D

Thanks for that one :)
Timwi


subject: [Wikitech-l] Re: New db server

body:
A summary of current performance issues and discussions in IRC, combined with some purchase options discussions is available at:

http://meta.wikipedia.org/wiki/Upgrade_discussion_April_2004

Also linked from there are the new, excellent, Ganglia statistics Tim Starling set up a few days ago.

I'll integrate the discussion from the mailing list which isn't yet covered there shortly.


in_reply_to:
<c5bois$uqe$1@sea.gmane.org> (timwi@gmx.net's message of "Sun,
	11 Apr 2004 16:34:49 +0100")

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

    T> No matter what throttling you choose, I will hit the limit at
    T> some point, I'm sure...

Well, y'know, I'd question whether you could do a sustained 2 edits
per second, like the zh flooding bot. If so, you need to get some
other hobbies. B-)

~ESP

--
Evan Prodromou <evan at wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide


subject: [Wikitech-l] Re: Deletion log is parsed and breaks layout

body:
Thomas Luft wrote:

> I don't know if this error was already reported, at least I found no bug
> report at sourceforge. When viewing the deletion log
> (http://de.wikipedia.org/wiki/Wikipedia:L%F6sch-Logbuch) of the German
> Wikipedia there are several deleted entries which get parsed and break
> the layout of the page. I just cheked en: and there it works normal?!

Your assertion is false. The same happens on en:. It's just that when
you looked at [[en:Wikipedia:Deletion log]] it did not have any
{{msg:...}} stuff in it.

Timwi


subject: [Wikipedia-l] Deletions on meta

body:
Today, aplank deleted a collection of pages on meta.

See http://meta.wikipedia.org/wiki/Meta%3ADeletion_log

The deletion policy on meta states that pages should
stay between 15 to 30 days listed on vfd before being
deleted. The long delay time is due to the fact users
do not come to meta as often that they come to local
wikipedia, so are given more time to react.

Most of the pages perl deleted have been listed for
about a week. Others, I added yesterday. And some
pages have never been listed at all.

Granted, I think that most of these pages had to be
deleted, however, I do not think any of them qualified
to speedy deletion, given that most have been on meta
for a full year.

In any cases, I think there is a rule, not a very
drastic one, but a rule anyway. I think it should be
respected.

And the rule state "list article on vfd, and wait
between 15 to 30 days";

------

On meta, there is another rule which I think is
inappropriate. It states "any sysop on any wikipedia
shall be sysop automatically upon request on meta". I
propose a change of policy, so that a user making a
request is at least not opposed by its peers.

Please, give feedback on these two points

* What do we do when sysop do not respect rules on
meta ?
* Is that ok that any sysop on any wiki is made sysop
on meta, without any approval by anyone, or without
any chance to express disapproval

__________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html


subject: [Wikipedia-l] statistics

body:
Thanks Erik :-)

__________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html


list: foundation-l

from_name: Brion Vibber

subject: [Foundation-l] Help betatest MediaWiki 1.3

body:
On Apr 12, 2004, at 01:33, Nancy McGough wrote:
> On 9 Apr 2004 Erik Moeller (erik_moeller at gmx.de) wrote:
>> Please help us in testing the latest version of MediaWiki, ...
>
> I'm planning to convert my Infinite Ink site to a MediaWiki wiki but I
> currently have no experience setting up or administering MediaWiki (or
> MySql). I'd like to use MediaWiki 1.3 or later and I'm happy to help
> beta test it but I have some questions:
>
> * How stable is the 1.3 code right now? Does it make sense for someone
> like me to set it up and experiment with it?

A number of things are not yet working correctly; some features have
been temporarily broken while being rewritten, some other new features
just aren't quite finished yet (templates, new layout, page import).
The wiki->HTML parser is being tweaked for correct XHTML output and
fundamental parts of it get half-broken and half-fixed a couple of
times a day, so I would certainly not recommend setting up a site on
1.3 just now.

> * If I set up 1.2.3 instead, will it be easy to migrate to 1.3?

Yes, it should be pretty easy. We've so far made only minor changes to
the database, which an update script should take care of.

> * When do you think 1.3 will be released? I know that estimating
> release dates is not a very accurate business but any clues in this
> area will help me decide what to do.

A beta release or release candidate before the end of the month is
quite likely, but we don't have firm plans. An official 1.3.0 release
will come when it seems to be working and the installation and upgrade
process has been tested to general satisfaction.

-- brion vibber (brion @ pobox.com)


list: wikimedia-l


subject: [Wikipedia-l] Parasitic behaviour. We loose more than money by it.

body:
ErikZ-
> Could we not strike a deal with Google similar to the one with Yahoo by
> which Google favours the original content instead of outdated copies, should
> be in their interest too.

That seems like the most reasonable course of action. Note, however, that
Google is notoriously unresponsive to any queries regarding search result
ranking (and who could blame them). Taking this from the bottom up could
be difficult. Do we have anyone who has contacts to reasonably high level
Google personnel? Has anyone at Google ever said something about
Wikipedia?

There are other options aside from downranking Wikipedia mirrors. Google
does have a deal with reference.com, whereby when you enter a word like
"elephant", it provides a link to a dictionary [definition]. I'm not sure
if reference.com pays them for that, and if so, how much. I could imagine
a similar link [encyclopedia article] for searches which match Wikipedia
titles.

We do need to enforce the FDL requirements more systematically.
phatnav.com, for example, leeches our images, but does *not* provide a
backlink to Wikipedia articles and even calls itself "a Wikipedia". This
is a violation of the FDL and of our trademark.

While these mirrors do hurt our rank, they have the effect of getting
multiple Wikipedia articles into many search queries. I hope this will not
be perceived as search engine spamming.

Regards,

Erik


subject: [Wikipedia-l] Sysop

body:
I suggested a change of policy on meta, about the way
adminship was granted. Please comment.

http://meta.wikipedia.org/wiki/Talk%3AAdministrator

__________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html


from_name: Fred Bauder

subject: [Wikipedia-l] Deletions on meta

body:
It strikes me that the pages should be listed on VfD of en.Wikipedia so this
little backwater that is not closely watched no longer exists. I think
creating a separate sysop list for Meta that "controlled" it would be a way
of playing politics within Wikipedia.

Perhaps there should be more integration so that separate separate accounts
and logging in could be eliminated.

Fred

> From: Anthere <anthere9 at yahoo.com>
> Reply-To: wikipedia-l at Wikimedia.org
> Date: Mon, 12 Apr 2004 00:00:48 -0700 (PDT)
> To: wikipedia-l at wikimedia.org
> Subject: [Wikipedia-l] Deletions on meta
>
> Today, aplank deleted a collection of pages on meta.
>
> See http://meta.wikipedia.org/wiki/Meta%3ADeletion_log
>
> The deletion policy on meta states that pages should
> stay between 15 to 30 days listed on vfd before being
> deleted. The long delay time is due to the fact users
> do not come to meta as often that they come to local
> wikipedia, so are given more time to react.
>
> Most of the pages perl deleted have been listed for
> about a week. Others, I added yesterday. And some
> pages have never been listed at all.
>
> Granted, I think that most of these pages had to be
> deleted, however, I do not think any of them qualified
> to speedy deletion, given that most have been on meta
> for a full year.
>
> In any cases, I think there is a rule, not a very
> drastic one, but a rule anyway. I think it should be
> respected.
>
> And the rule state "list article on vfd, and wait
> between 15 to 30 days";
>
> ------
>
> On meta, there is another rule which I think is
> inappropriate. It states "any sysop on any wikipedia
> shall be sysop automatically upon request on meta". I
> propose a change of policy, so that a user making a
> request is at least not opposed by its peers.
>
> Please, give feedback on these two points
>
> * What do we do when sysop do not respect rules on
> meta ?
> * Is that ok that any sysop on any wiki is made sysop
> on meta, without any approval by anyone, or without
> any chance to express disapproval
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - File online by April 15th
> http://taxes.yahoo.com/filing.html
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l


body:
I know this is not new, but I'm rather pissed off to see Google returns
several commercial sites featuring all Wikipedia articles on a request
explicitly specifying "Wikipedia" as search term, and on top of the real
thing.

I figure more and more of these sites will pop up when people realize how
easy it is to make money this way, and probably loads of it.

E.g. "rembrandt wikipedia"
http://www.google.com/search?sourceid=navclient&ie=UTF-8&oe=UTF-8&q=wikipedi
a+rembrandt
shows Wikipedia only behind two other sites, one of which uses "Rembrandt -
Wikipedia" even in the <title>..</title> tags, which is shown prominently in
the Google response.

I know GDFL is very permissive, but is there nothing we can do about this?
Even if we don't want the money, which is also an old discussion, we might
at least attract more contributors if  parasitic sites (not all mirrors are
in this category) were less succesful.

Could we not strike a deal with Google similar to the one with Yahoo by
which Google favours the original content instead of outdated copies, should
be in their interest too.

Erik Zachte


body:
Correction: en:Wikipedia is shown first in Google on "rembrandt wikipedia"

Try "wikipedia rembrandt" instead.

Erik Zachte


subject: [Wikipedia-l] meta deletion

body:
>It strikes me that the pages should be listed on VfD
of >en.Wikipedia so this
>little backwater that is not closely watched no
longer >exists.

Hum ?!?
Are you suggesting that en.wikipedia is the place
which will decide of deletions of pages located on
meta ?

>I think
>creating a separate sysop list for Meta that
>"controlled" it would be a way
>of playing politics within Wikipedia.

Are you also suggesting that meta should be managed by
en:sysop ?

>Perhaps there should be more integration so that
>separate separate accounts
>and logging in could be eliminated.

Are you suggesting that a sysop on one wikipedia would
be sysop on all wikipedias ?

>Fred

__________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html


from_name: Robert

subject: [WikiEN-l] Mr Natural Health and Martin Harper again out of control

body:
I am aware that many of you are concerned with the non-stop
harassment from "Mr Natural Health". As many of you have
noted, he has made threats against me, and has made what
appear to be death threats to many others on Usenet
newsgroups. Also, a Wikipedia committee has repeatredly
found him to be a harasser, and has reccomended action
against him. Many Wikipedians have complained about his
personal attacks and harassment.

In recent days he has started going back to harass his
older self-imagined enemies, including me. MNH is again out
of control, and is engaged in edit wars, personal attacks
and vandalism of talk pages. He needs to be banned,
immediately, as many of you already suggested.

Also, Martin Harper (MyRedDice) is still censoring the
article on Palestinian Views of the Peace Process. While he
disingenuously claimed to be engage in mediation, in point
of fact, the "mediation committee" refused to take any
action at all, and effectively supported his non-stop
vandalism. I tried for over two weeks to "mediate", only to
find out that the process was a hoax.

In regards to the article, ""Palestinian views of the peace
process", Martin Harper is _still_ censoring vast amounts
of historical facts and verified quotes. Instead of
working with others to make improvements, he is hiding
facts that he finds inconvenient. This is totally
unacceptable.

We should heed the words of Jimbo Wales on this issue: On
Fri Jan 9 14:48:08 UTC 2004 Jimbo writes about this
situation:

"But in tems of actual content, I don't see the problem.
There is no question that a full understanding of the
Palestinian situation requires understanding what
Palestinian views of the peace process actually are. There
is no question that one point of contention is whether
Palestinian leaders, in particular, view the peace process
as "permanent and irrevocable" (or similar) or whether they
view it merely as a short-term negotiating tactic in a
longterm effort to destroy Israel. Simply omitting
information on that question is unacceptable. This is an
important part of one of the major questions of our time."

On Fri Jan 9 16:24:36 UTC 2004 Jim also wrote:

"I don't really see how it's original historical research
in any way shape or form. Palestinian attitudes are well
documented and discussed -- except on Wikipedia, where
people have chosen to delete rather than work for
neutrality."

My own comment Martin Harper is deliberately violating NPOV
by only mentioning viewpoints from a limited number of
people. Viewpoints that he disagrees with, even if they are
majority views, are censored. In contrast, the material
censored actually shows a wide range of views from a wide
range of Palestinian leaders, so that Wikipedia readers can
read the range of views and make up their own mind.  Should
we allow Wikipedia to maintain NPOV? Yes! range of views
presented within the article, Jimbo Wales writes:

Fri Jan 9 17:11:56 UTC 2004

"The text could be improved, of course. But it is very good
precisely becasue it presents "balanced and balancing
viewpoints with the proper historical context". The quotes
are dated and exact references are given. Alternative views
and background information is given.

Many in the West are uncomfortable with this kind of
information because it doesn't comport well with the
prevailing liberal view that the Palestinians are solely
victims. Rationally, of course we can say that Palestinians
are indeed victims while simultaneously holding and
expressing reprehensible views. What we must not do is
simply omit information about Palestinian attitudes because
it doesn't match up too our rosy view of noble rebels
fighting a racist apartheid state. What I'm primarily
arguing, though, is not the content of the material. I
think that the material is good, though not excellent, but
my real point is that it can in no way be characterized as
something that ought to be simply *deleted* outright. It
should be *improved*.

In the present case, we see why deletion is bad. We are
left with a horribly broken presentation in which readers
are unable to discover why it might be that, despite the
PLO officially no longer calling for the destruction of
Israel, and Arafat himself announcing a right to exist, the
majority of Palestinians polled support the destruction of
Israel.

We can only come to understand that better when we come to
understand Arafat's duplicity, and the anti-Israel
propaganda that is rampant in the Palestinian culture. But
because some supporters of Palestine are uncomfortable with
that material, it is censored from Wikipedia. No, I don't
think censorship is too strong a word."

-- end quote --

(Again, I would have been happy to engage in mediation. I
was saddened to see that in fact, it does not exist.)

Robert (RK)

__________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html


subject: [Wikipedia-l] meta deletion

body:
If they speak the language.

Fred

> From: Anthere <anthere9 at yahoo.com>
> Reply-To: wikipedia-l at Wikimedia.org
> Date: Mon, 12 Apr 2004 06:20:42 -0700 (PDT)
> To: wikipedia-l at wikimedia.org
> Subject: [Wikipedia-l] meta deletion
>
> Are you suggesting that a sysop on one wikipedia would
> be sysop on all wikipedias ?


from_name: Mathias Schindler

subject:
[Wikipedia-l] Parasitic behaviour. We loose more than money by
	it. <- I highly doubt that.

body:
Erik Zachte schrieb:
> I know this is not new, but I'm rather pissed off to see Google returns
> several commercial sites featuring all Wikipedia articles on a request
> explicitly specifying "Wikipedia" as search term, and on top of the real
> thing.

[...]

> I know GDFL is very permissive, but is there nothing we can do about this?

Last year, I played a lot with google's pagerank and the way new pages
find their way into the index.

One of the monst important factors in the PageRank formula is freshness.
If I copy a page from the source web site which is already in the google
index, I have a certain chance to get ahead of if - for some time.

After a while, the ratio of age will balance and other factors (the
global pagerank of a site, and it's update frequency) will catch up.

So the answer is time. Most pages won't stay ahead of wikipedia.org for
long time - If the other comply to the license, they have to link to us,
which is boosting wikipedia.org.

So in the long term (and that's what wikipedia is certainly good at:
deep breath) we gain from all the parasits (which appears to me as a POV
term)

By the way: Noone is searching for "wikipedia rembrand" if he doesn't
know wikipedia yet. I use to use google as a full text search engine for
wikipedia as long as we can't provide this yet by ourself.

Our aim is to get to position 1 for the search term "rembrand" and all
the other lemmata which is a project for ages. Under these condiditions
we can surely afford to let other sites to provide the wikipedia content
in a GFDL compliant way.

Mathias

--
nach uns der synflood.


subject: [WikiEN-l] Wikipedia:Requests for comment/RK

body:
Many Wikipedia users have had trouble with RK, often over long periods.
Please add your input at:

[[Wikipedia:Requests for comment/RK]]

Fred

> From: Robert <rkscience100 at yahoo.com>
> Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
> Date: Mon, 12 Apr 2004 07:46:09 -0700 (PDT)
> To: wikien-l at wikipedia.org
> Subject: [WikiEN-l] Mr Natural Health and Martin Harper again out of control
>
> I am aware that many of you are concerned with the non-stop
> harassment from "Mr Natural Health". As many of you have
> noted, he has made threats against me, and has made what
> appear to be death threats to many others on Usenet
> newsgroups. Also, a Wikipedia committee has repeatredly
> found him to be a harasser, and has reccomended action
> against him. Many Wikipedians have complained about his
> personal attacks and harassment.
>
> In recent days he has started going back to harass his
> older self-imagined enemies, including me. MNH is again out
> of control, and is engaged in edit wars, personal attacks
> and vandalism of talk pages. He needs to be banned,
> immediately, as many of you already suggested.
>
> Also, Martin Harper (MyRedDice) is still censoring the
> article on Palestinian Views of the Peace Process. While he
> disingenuously claimed to be engage in mediation, in point
> of fact, the "mediation committee" refused to take any
> action at all, and effectively supported his non-stop
> vandalism. I tried for over two weeks to "mediate", only to
> find out that the process was a hoax.
>
> In regards to the article, ""Palestinian views of the peace
> process", Martin Harper is _still_ censoring vast amounts
> of historical facts and verified quotes. Instead of
> working with others to make improvements, he is hiding
> facts that he finds inconvenient. This is totally
> unacceptable.
>
> We should heed the words of Jimbo Wales on this issue: On
> Fri Jan 9 14:48:08 UTC 2004 Jimbo writes about this
> situation:
>
> "But in tems of actual content, I don't see the problem.
> There is no question that a full understanding of the
> Palestinian situation requires understanding what
> Palestinian views of the peace process actually are. There
> is no question that one point of contention is whether
> Palestinian leaders, in particular, view the peace process
> as "permanent and irrevocable" (or similar) or whether they
> view it merely as a short-term negotiating tactic in a
> longterm effort to destroy Israel. Simply omitting
> information on that question is unacceptable. This is an
> important part of one of the major questions of our time."
>
> On Fri Jan 9 16:24:36 UTC 2004 Jim also wrote:
>
> "I don't really see how it's original historical research
> in any way shape or form. Palestinian attitudes are well
> documented and discussed -- except on Wikipedia, where
> people have chosen to delete rather than work for
> neutrality."
>
>
> My own comment Martin Harper is deliberately violating NPOV
> by only mentioning viewpoints from a limited number of
> people. Viewpoints that he disagrees with, even if they are
> majority views, are censored. In contrast, the material
> censored actually shows a wide range of views from a wide
> range of Palestinian leaders, so that Wikipedia readers can
> read the range of views and make up their own mind.  Should
> we allow Wikipedia to maintain NPOV? Yes! range of views
> presented within the article, Jimbo Wales writes:
>
> Fri Jan 9 17:11:56 UTC 2004
>
> "The text could be improved, of course. But it is very good
> precisely becasue it presents "balanced and balancing
> viewpoints with the proper historical context". The quotes
> are dated and exact references are given. Alternative views
> and background information is given.
>
> Many in the West are uncomfortable with this kind of
> information because it doesn't comport well with the
> prevailing liberal view that the Palestinians are solely
> victims. Rationally, of course we can say that Palestinians
> are indeed victims while simultaneously holding and
> expressing reprehensible views. What we must not do is
> simply omit information about Palestinian attitudes because
> it doesn't match up too our rosy view of noble rebels
> fighting a racist apartheid state. What I'm primarily
> arguing, though, is not the content of the material. I
> think that the material is good, though not excellent, but
> my real point is that it can in no way be characterized as
> something that ought to be simply *deleted* outright. It
> should be *improved*.
>
> In the present case, we see why deletion is bad. We are
> left with a horribly broken presentation in which readers
> are unable to discover why it might be that, despite the
> PLO officially no longer calling for the destruction of
> Israel, and Arafat himself announcing a right to exist, the
> majority of Palestinians polled support the destruction of
> Israel.
>
> We can only come to understand that better when we come to
> understand Arafat's duplicity, and the anti-Israel
> propaganda that is rampant in the Palestinian culture. But
> because some supporters of Palestine are uncomfortable with
> that material, it is censored from Wikipedia. No, I don't
> think censorship is too strong a word."
>
> -- end quote --
>
> (Again, I would have been happy to engage in mediation. I
> was saddened to see that in fact, it does not exist.)
>
> Robert (RK)
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - File online by April 15th
> http://taxes.yahoo.com/filing.html
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l


from_name: Nancy McGough

body:
On 9 Apr 2004 Erik Moeller (erik_moeller at gmx.de) wrote:
> Please help us in testing the latest version of MediaWiki, ...

I'm planning to convert my Infinite Ink site to a MediaWiki wiki
but I currently have no experience setting up or administering
MediaWiki (or MySql). I'd like to use MediaWiki 1.3 or later and
I'm happy to help beta test it but I have some questions:

* How stable is the 1.3 code right now? Does it make sense for
someone like me to set it up and experiment with it?

* If I set up 1.2.3 instead, will it be easy to migrate to 1.3?

* When do you think 1.3 will be released? I know that estimating
release dates is not a very accurate business but any clues in
this area will help me decide what to do.

I'm looking forward to using MediaWiki!
Thank you,
Nancy

--
Nancy McGough
Infinite Ink ~ <http://www.ii.com>
Deflexion & Reflexion ~ <http://deflexion.com>


from_name: Ray Saintonge

subject: [Wikipedia-l] meta deletion

body:
It's important that the sysops on a given project be people who are
active participants in that project.  They are the ones familiar with
the ways of doing things there, and the culture that has developed.

To have others coming into a small friendly project making decisions
based on a process that took place on en-wikipedia is insulting and
disrespectful of everything that the participants in the smaller project
have been trying to build.

Ec

Fred Bauder wrote:

>If they speak the language.
>
>Fred
>
>>From: Anthere <anthere9 at yahoo.com>
>>Subject: [Wikipedia-l] meta deletion
>>
>>Are you suggesting that a sysop on one wikipedia would
>>be sysop on all wikipedias ?
>>


body:
Thanks for the quick reply! OK, I'm going to set up 1.2.3 and
then migrate to 1.3 whenever it's released. If anyone has any
words of wisdom/advice to a newbie especially w.r.t. mathematical
symbols, please let me know. Hope to see you on the ii wiki!

Nancy

--
Nancy McGough
Infinite Ink ~ <http://www.ii.com>
Deflexion & Reflexion ~ <http://deflexion.com>


from_name: Till Westermayer

body:
. . . . . . . . . . . . . . . . . . . . . . . . . . . till we *) . . .

Hi,

>We do need to enforce the FDL requirements more systematically.
>phatnav.com, for example, leeches our images, but does *not*
>provide a backlink to Wikipedia articles and even calls itself "a
>Wikipedia". This is a violation of the FDL and of our trademark.

BTW: I wrote them a short notice that I don't like them using my user-
page without proper GFDL, and I only got back a one-sentence-mail
stating they will update their encyclopedia part in summer.

 __ .
 / / / /                            ... Till Westermayer - till we *)
. .
  . mailto:till at tillwe.de . www.westermayer.de/till/ . icq 320393072
  . Habsburgerstr. 82 . 79104 Freiburg . 0761 55697152 . 0160 96619179
  . . . . .


subject: [Wikipedia-l] backlinks

body:
. . . . . . . . . . . . . . . . . . . . . . . . . . . till we *) . . .

>On Apr 11, 2004, at 5:03 AM, Kai Kumpf wrote:

>> Please consider eventually heaving backlinks towards the top!

>I realize that for people used to other wikis this functionality
>might seems misplaced, but to me it it much clearer.  When I first
>arrived here I knew exactly what "What links here" meant.

Exactly the same with me. Maybe other wikis should consider putting
backlinks into a more visible place, i.e. a menu bar? ;-)
 __ .
 / / / /                            ... Till Westermayer - till we *)
. .
  . mailto:till at tillwe.de . www.westermayer.de/till/ . icq 320393072
  . Habsburgerstr. 82 . 79104 Freiburg . 0761 55697152 . 0160 96619179
  . . . . .


subject:
[WikiEN-l] Mr Natural Health and Martin Harper again out of
	control

body:
Robert wrote:

>In the present case, we see why deletion is bad. We are
>left with a horribly broken presentation in which readers
>are unable to discover why it might be that, despite the
>PLO officially no longer calling for the destruction of
>Israel, and Arafat himself announcing a right to exist, the
>majority of Palestinians polled support the destruction of
>Israel.
>
>We can only come to understand that better when we come to
>understand Arafat's duplicity, and the anti-Israel
>propaganda that is rampant in the Palestinian culture. But
>because some supporters of Palestine are uncomfortable with
>that material, it is censored from Wikipedia. No, I don't
>think censorship is too strong a word."
>
This seems like a blatant attempt to manipulate a text, or a series of
assumedly accurate facts in support of propaganda for the Israeli POV.
 The phrase "when we come to understand Arafat's duplicity" (without so
much as a hint of the more conditional "if and when...") suggests an
uncompromising closed-minded, view of Arafat's duplicity that is not
prepared to accept any evidence to the contrary.  I say this without
prejudice to whether or not that evidence exists.

Certainly there is anti-Israeli propaganda coming from Palestinians, but
then so too is there as much anti-Palestinian propaganda from Israelis.

As the adage goes, Robert's complaints are a case of "the pot calling
the kettle black".

Ec


from_name: Magnus Manske

body:
How about throttling with a manually generated whitelist for heavy
(human) editors?

Magnus

Evan Prodromou wrote:
>>>>>>"T" == Timwi  <timwi at gmx.net> writes:
>
>
>     T> No matter what throttling you choose, I will hit the limit at
>     T> some point, I'm sure...
>
> Well, y'know, I'd question whether you could do a sustained 2 edits
> per second, like the zh flooding bot. If so, you need to get some
> other hobbies. B-)
>
> ~ESP
>


subject: [Wikitech-l] Database Split & Revisions

body:
On Apr 12, 2004, at 07:49, RameezDon wrote:
> Hello Guys,
> i have downloaded the English Wikipedia Dump (en.wikipedia) present in
> three sub-parts namely (xaa, xab, xac) which amounts to around 6GB of
> data in compressed format.
> ?
> Now the issue is that only the 1st part xaa shows a .bz2 extension
> while the other two (xab & xac) are simply data files.
> ?
> If they are Splitted by the use of some utility , How do i merge them
> into 1 single (.bz2 ) file
> amounting to around 6gb

cat xa? > bigdamnfile.bz2

There are 5 parts (to xae), get all of them.

> ?How periodically is the Database Dump Revised or Updated....( week or
> fortnight ????)

Roughly weekly.

-- brion vibber (brion @ pobox.com)


from_name: Ricky Beam

subject: [Wikitech-l] Re: New db server

body:
On Sun, 11 Apr 2004, user_Jamesday wrote:
>http://meta.wikipedia.org/wiki/Upgrade_discussion_April_2004
"RAID 5 does not offer more read seeks than write seeks because each stripe
 is on all disks and all must seek together to get the data"

This is simply incorrect.  RAID 5 has distributed parity, so a write will
require reads from at least part of the stripe.  Gez, you'd think Wiki
people would read their own entry on RAID:
http://en.wikipedia.org/wiki/RAID#RAID_5:_Independent_Data_disks_with_distributed_parity_blocks_(Block_Interleaved_Distributed_Parity)

I quote:
"Characteristics and Advantages
 Highest read data transaction rate. Medium to poor write data transaction
 rate, especially when the host CPU performs software parity checking. Low
 ratio of ECC (Parity) disks to data disks means high efficiency. Good
 aggregate transfer rate."

Note: this discounts the ability of modern processors in performing parity
      calculations.  A 3GHz P4 Xeon can easily handle parity for hundreds
      of drives.

Parallel reads (of blocks not on the same drive) are faster with RAID 5 vs.
RAID 1 as there are usually many more drives.

And a stripe does not have to be across all the drives in the array, but
does have to be at least two drives.

--Ricky

PS: Software RAID 5 speeds for various filesystems using a 7 drive array
(7x ST118202FC 18.2G FC drives, Qla2100, dual 2.8G P4 Xeon, 3G RAM)

On Sun, 11 Apr 2004, user_Jamesday wrote:
>http://meta.wikipedia.org/wiki/Upgrade_discussion_April_2004
"RAID 5 does not offer more read seeks than write seeks because each stripe
 is on all disks and all must seek together to get the data"

This is simply incorrect.  RAID 5 has distributed parity, so a write will
require reads from at least part of the stripe.  Gez, you'd think Wiki
people would read their own entry on RAID:
http://en.wikipedia.org/wiki/RAID#RAID_5:_Independent_Data_disks_with_distributed_parity_blocks_(Block_Interleaved_Distributed_Parity)

I quote:
"Characteristics and Advantages
 Highest read data transaction rate. Medium to poor write data transaction
 rate, especially when the host CPU performs software parity checking. Low
 ratio of ECC (Parity) disks to data disks means high efficiency. Good
 aggregate transfer rate."

Note: this discounts the ability of modern processors in performing parity
      calculations.  A 3GHz P4 Xeon can easily handle parity for hundreds
      of drives.

Parallel reads (of blocks not on the same drive) are faster with RAID 5 vs.
RAID 1 as there are usually many more drives.

And a stripe does not have to be across all the drives in the array, but
does have to be at least two drives.

--Ricky

PS: Software RAID 5 speeds for various filesystems using a 7 drive array
(7x ST118202FC 18.2G FC drives, Qla2100, dual 2.8G P4 Xeon, 3G RAM)

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine   Size:chnk K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
xfs       6072M:64k           65897  30 18549   6           63092  14 335.0   8
ext2      6072M:64k           65777  27 18437   6           58003  14 288.4   6
ext3      6072M:64k           61752  38 22538   9           50738  12 212.0   5
reiserfs  6072M:64k           62821  26 23505   9           53290  14 269.4   6
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
xfs            1024   239  15  3591  84   280   5   254  16  1531  32   135   2
ext2           1024    43  99 48962  32 40645  30    43  99    84  27    82  85
ext3           1024    34  97 38788  27 24712  44    34  97    80  31    56  67
reiserfs       1024   488   2  9431   6   663   3   426   2  6299   6   285   2

I've not run these tests on "modern" 73G and 146G drives. (they're in use.)
These drives will be reattched this eveningif anyone wants any different
numbers (RAID 0, 1, 0+1, 1+0, 6, whatever)


from_name: Arvind Narayanan

in_reply_to:
<NMENLBGDKAFGBDHEPOBNAELICHAA.e.p.zachte@chello.nl>;
	from e.p.zachte@chello.nl on Mon, Apr 12, 2004 at 03:49:37AM +0200

body:
I have a suggestion:

While our main page has a high pagerank, individual articles probably
don't (depending on how well they're linked to). So, it would help to
link to Special:Allpages from the main page (the static cached version
is fine). That way, it would take at most 3 links from the main page
to any article. Further, the second level pages should also be made
static and updated once in a while, because crawlers don't request
dynamic pages (I think).

Arvind

On Mon, Apr 12, 2004 at 03:49:37AM +0200, Erik Zachte wrote:
> I know this is not new, but I'm rather pissed off to see Google returns
> several commercial sites featuring all Wikipedia articles on a request
> explicitly specifying "Wikipedia" as search term, and on top of the real
> thing.
>
> I figure more and more of these sites will pop up when people realize how
> easy it is to make money this way, and probably loads of it.
>
> E.g. "rembrandt wikipedia"
> http://www.google.com/search?sourceid=navclient&ie=UTF-8&oe=UTF-8&q=wikipedi
> a+rembrandt
> shows Wikipedia only behind two other sites, one of which uses "Rembrandt -
> Wikipedia" even in the <title>..</title> tags, which is shown prominently in
> the Google response.
>
> I know GDFL is very permissive, but is there nothing we can do about this?
> Even if we don't want the money, which is also an old discussion, we might
> at least attract more contributors if  parasitic sites (not all mirrors are
> in this category) were less succesful.
>
> Could we not strike a deal with Google similar to the one with Yahoo by
> which Google favours the original content instead of outdated copies, should
> be in their interest too.
>
> Erik Zachte
>
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l

--
Its all GNU to me


subject: [Wikitech-l] Re: Re: Re: New db server

body:
I agree on the quote from my writing. I've changed that from:

"RAID 1 mirroring offers about twice the number of read seeks as write seeks (each drive seeks independently). RAID 5 does not offer more read seeks than write seeks because each stripe is on all disks and all must seek together to get the data"

to:

"RAID 1 mirroring or RAID 10 offers about twice the number of read seeks as write seeks (each drive or stripe seeks independently). RAID 5 does not offer more read seeks than a single drive, RAID 1 or RAID 10 can deliver because each stripe is on all disks and all must seek together to get the data. In addition, in RAID 5 writes are slowed because at least one read is required to get the parity data unless it has been cached."

so it doesn't ignore the write rate reduction in RAID 5. That might be significant if it turns out that we become write rate limited and it might be one part of the reasons why LiveJournal, which is almost exclusively write-limited, is switching from RAID 5 to RAID 10. Doesn't affect what I was intending to write about, though, which was read rates of the various RAID systems.

Experience at the Wikipedia is that Suda with a 3 disk RAID 5 setup is far slower than Geoffrin with a 4 disk RAID 10 setup. I'm interested in reading your views on why that is the case. Either way, though, I'm inclined to go with what we've seen of performance in the Wikipedia environment until we can make Suda with RAID 5 faster than it has been. If you can come up with some proposals which might do that, it's worth considering trying them, since the greater space efficiency of RAID 5 will be useful eventually.

RAID 5 compared to RAID 10 is interesting when it comes to sequential read rates because the RAID 5 system can read the data from more drives, so it can get a higher sequential transfer rate. The catch is that this is a database system and database systems are generally considered to be limited primarily by their seek rate, not their sequential transfer rate. There are some potential gotchas in that though - cases with large chunk/cluster sizes in the database and some access patterns might change it. "Transaction rate" rather than seek rate or sequential transfer rate has lots of significant details not spelled out, which is one reason why I stuck to the comparatively unambiguous seek and sustained transfer rate measures (though those have a fair amount of varying potential as well).

Yes, I agree that it's possible to have RAID 5 systems set up not to have striping across all drives in the RAID 5 system box. However, that's not how people normally think of RAID 5 - they are normally thinking in terms of one set of drives. The RAID 5 option offers less independent seeks than RAID 1, unless you start to do things like splitting the array stripes as you described. Not really sure what I'd call that but RAID 5 probably isn't it. Maybe a pair of RAID 5s. In any case, I expect that to offer less seeks than RAID 1 because that two drive minimum per stripe has to seek together and RAID 1 drives can seek independently.

I do not agree that RAID 5 offers the highest read transaction rate, in general. Please support that claim compared to RAID 1 and RAID 10 over in the article talk page. It'll be interesting to see your data and any you can point to which compares the systems. Since we're considering Wikipedia use, data with Wikipedia access patterns, including transfer sizes, is what really interests me. I don't know the typical transfer size per seek for Wikipedia, though.

In a past life I was disk then overall manager for CompuServe's benchmarks and standards community, so I'm always happy to discuss disk system performance - it's a fun subject for me.:) But probably best not done on this list.:)


subject: [Wikitech-l] Re: Re: Re: New db server

body:
On Mon, 12 Apr 2004, user_Jamesday wrote:
...

My problem is with the word "get"... RAID arrays process "chunks".  The
chunk can be the size of a stripe or not.  If you want to read a 4k block
within a 32k chunk/stripe, the array will read the entire chunk.  This is
an optimization to deal with potential drive failures (it needs the entire
stripe to recover data), and prepare for subsequent writes.

I don't know enough about the hardware setup for LJ, so I'll reserve my
comments.  They are much higher write traffic, 'tho I doubt they have
that high a write rate to make that much difference between 5 vs. 1.

>Experience at the Wikipedia is that Suda with a 3 disk RAID 5 setup is far
>slower than Geoffrin with a 4 disk RAID 10 setup.

What's the exact hardware and software setup?  It could come down to the
exact drives.  For example, I have several dozen NEW Seagate 200GB IDE
drives.  Some can read at nearly 50MB/s, yet the next drive (in the same
system, on the same cable, etc.) reads at 23MB/s.  I've never seen SCSI
drives with that much variation -- even those with large grown defect
lists.

>RAID 5 compared to RAID 10 is interesting when it comes to sequential read
>rates because the RAID 5 system can read the data from more drives, so it
>can get a higher sequential transfer rate. The catch is that this is a
>database system and database systems are generally considered to be limited
>primarily by their seek rate, not their sequential transfer rate. There are
>some potential gotchas in that though - cases with large chunk/cluster
>sizes in the database and some access patterns might change it.
>"Transaction rate" rather than seek rate or sequential transfer rate has
>lots of significant details not spelled out, which is one reason why I
>stuck to the comparatively unambiguous seek and sustained transfer rate
>measures (though those have a fair amount of varying potential as well).

There are a lot of tiny details that add up fast.  The system has to be
tuned to it use -- both the OS, hardware, and database.  It's a bit of
Voodoo.

>Yes, I agree that it's possible to have RAID 5 systems set up not to have
>striping across all drives in the RAID 5 system box. However, that's not
>how people normally think of RAID 5 - they are normally thinking in terms
>of one set of drives. The RAID 5 option offers less independent seeks than
>RAID 1, unless you start to do things like splitting the array stripes as
>you described. Not really sure what I'd call that but RAID 5 probably isn't
>it. Maybe a pair of RAID 5s. In any case, I expect that to offer less seeks
>than RAID 1 because that two drive minimum per stripe has to seek together
>and RAID 1 drives can seek independently.

This depends on the actual RAID implementation.  I've not seen anything
that's really RAID 5 pushing a stripe across the entire array.  Netapp
did this years ago, but it was, by definition, RAID 4 not 5 (single
parity drive.)  As I understand the linux software RAID, the stripe
size is how much data is placed on a single drive before moving to the
next drive.  This also appears to be the method used in Mylex and DPT
hardware RAID controllers.  This appears to be true based on visual
inspection of the drive LEDs during a sequential read.

>I do not agree that RAID 5 offers the highest read transaction rate, in
>general.

RAID 1 can support a parallel read for each drive in the array.  This is
usually *2*.  RAID 5 can support a parallel read for each data drive in
the array.  Thare are usually more than 2 data drives in a RAID 5 array.
The IDE vs. SCSI war also applies heavily here.

> Please support that claim compared to RAID 1 and RAID 10 over in
>the article talk page. It'll be interesting to see your data and any you
>can point to which compares the systems. Since we're considering Wikipedia
>use, data with Wikipedia access patterns, including transfer sizes, is what
>really interests me. I don't know the typical transfer size per seek for
>Wikipedia, though.

I'll be glad to provide my findings once I reassemble my toys (moved to an
enclosed rack... too much heat and noise.)  Keep in mind, each configuration
will take about a day to test without skewing the results by removing most
of the system RAM. (bonnie++ processes files 2*RAM in size to avoid cache
effects.)

I'd need the wikipedia database and a way to reproduce "typical" traffic
loads to provide a meaning comparison.  There are ways to do this, but they
are more work than would be of value. (A replay of the web server log will
do for reads, but writes are a problem...  can someone capture a weeks worth
of updates?  It'd be an interesting bit of work if I had the time to do it.)

--Ricky


from_name: RameezDon

subject: [Wikitech-l] Database Split & Revisions

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


subject: [Wikitech-l] Worldwide Lexicon and Wikipedia

body:
On Apr 12, 2004, at 14:50, Brian McConnell wrote:
> We would like to ask the Wikipedia community to consider supporting
> WWL. This
> is very easy to do. All that is required is to modify the existing
> search
> script to recognize standard parameters used in WWL queries, and to
> generate an
> XML response in place of HTML.

That should be possible. A few quick questions... I've taken a quick
glance at this page:
http://picto.weblogger.com/stories/storyReader$27

and there are some things I'm not sure about. "sl" is specified for
source language in results, but "<language>" appears in the example.
Further it's unclear to me just what is an acceptable code; must a
three-letter ISO 639-2 code be used, or is a two-letter code
acceptable? (We try to stick with RFC 3066, which prefers 2-letter to
3-letter codes where they exist, so it's easier for us to publish RFC
3066 codes since we already use them to identify the language of our
HTML output and in most cases the domain name of each project.) What
about further details, for instance would something like "gem-alsace"
be acceptable in output from the Alsatian Wikipedia
(als.wikipedia.org)? Also "def" appears in the list of expected
results, but "<sdef>" appears in the example. Which is correct?
"roottext", "vdef" and "cyc" are not listed as optional, but don't
appear in the example. "cyc", which looks like what we'd want to
provide, can be "text, html or xhtml", but how do we specify which?

Is there a reference implementation we can compare against?

-- brion vibber (brion @ pobox.com)


body:
Mathias wrote:
"One of the most important factors in the PageRank formula is freshness.
If I copy a page from the source web site which is already in the google
index, I have a certain chance to get ahead of if - for some time.
After a while, the ratio of age will balance and other factors (the
global pagerank of a site, and it's update frequency) will catch up."

Comparison of PhatNav's Rembrandt page with our edit history reveals they
used a dump from between 19 Jun 2003 and 14 Sep 2003.

The Wikipedia article has been edited 30 times since then.

Erik Zachte


from_name: Brian McConnell

body:
Brian,

Thanks for the note. I've posted remarks below.

One thing to keep in mind is that the spec is being re-written to clarify a
few things. The client/server interface itself won't change, but we'll be
preparing better documentation, especially with respect to special cases
that are not explicitly documented. In the meantime, you can call on me
anytime with questions.

One point I would also emphasize is that Wikipedia will be the first
encyclopedia in the network, and among the first dictionaries. We will have
about 14 languages covered by machine translation servers in a few weeks. As
such we are certainly open to refinements in the spec, especially the XML
response. I would appreciate this actually. We've done a good job with the
basic system design, but now is an opportune time to fine tune things a bit
before we attract a larger user community.

My email is brian at mcconnell.net, phone is 415 695 2887.

Brian

-----Original Message-----
From: Brion Vibber [mailto:brion at pobox.com]
Sent: Monday, April 12, 2004 3:57 PM
To: Wikimedia developers
Cc: Brian McConnell
Subject: Re: [Wikitech-l] Worldwide Lexicon and Wikipedia

On Apr 12, 2004, at 14:50, Brian McConnell wrote:
> We would like to ask the Wikipedia community to consider supporting
> WWL. This
> is very easy to do. All that is required is to modify the existing
> search
> script to recognize standard parameters used in WWL queries, and to
> generate an
> XML response in place of HTML.

That should be possible. A few quick questions... I've taken a quick
glance at this page:
http://picto.weblogger.com/stories/storyReader$27

and there are some things I'm not sure about. "sl" is specified for
source language in results, but "<language>" appears in the example.

>>> <language> appears in the response because each entry may be in a
different language. For example, you could search for every instance of the
word "playa" regardless of language (if you omit sl=nnn in the incoming
query, the server will generally search all languages).  This will be a
useful tool for someone who wants to research the origins and evolution of a
word. We use a different label to avoid confusing the incoming parameter
with the outgoing response.

Further it's unclear to me just what is an acceptable code; must a
three-letter ISO 639-2 code be used, or is a two-letter code
acceptable? (We try to stick with RFC 3066, which prefers 2-letter to
3-letter codes where they exist, so it's easier for us to publish RFC
3066 codes since we already use them to identify the language of our
HTML output and in most cases the domain name of each project.)

>>> Regarding language codes, we ask that all service providers recognize
three-letter codes. This does not preclude you from recognizing two letter
codes, but nearly all client queries will use the three letter codes. You
can deal with this in your script with a simple mapping function that
recognizes both.

What
about further details, for instance would something like "gem-alsace"
be acceptable in output from the Alsatian Wikipedia
(als.wikipedia.org)?

>>> This not stated clearly in the spec, but subdomains of languages are
permitted in xxx.yyyyy notation (e.g. eng.medical), and can be used to
narrow the scope of a search. One thing we plan to do once we have a larger
developer community is to define some standard subdomains (i.e. xxx.medical,
xxx.engineering, etc). We're holding off on doing this because of the
possibility for feature creep, flame wars over nomenclature, etc.

Also "def" appears in the list of expected
results, but "<sdef>" appears in the example. Which is correct?
"roottext", "vdef" and "cyc" are not listed as optional, but don't
appear in the example. "cyc", which looks like what we'd want to
provide, can be "text, html or xhtml", but how do we specify which?

>>> Following are remarks about the usage of the elements you mentioned.

text = unformatted text/title (i.e. "playa")
sdef = short definition ("a dried up lake bed")
vdef = verbose definition (...longer description of playa geology, etc)

We assume the text returned in all three of these parameters is unformatted
plain text.

>>> If you want to return a HTML or XHTML response, the best way to do this
is to specify a target URL using the <url>...</url> field. This could either
point to the static page for the entry, or to a script that displays the
text minus nav menus, etc (so the rich text can be displayed in a child
window, minus extraneous sidebars, etc). I'll think about ways to return
this information in the response itself, however, there are some gotchas
involved in embedding HTML within an XML dataset. Everything has to be
escape encoded, which is a problem. I built an RSS feed generator a couple
of years ago. It took me forever to get embedded hyperlinks, etc to work
properly.

The <cyc> element was originally intended to specify the format of the
response, but was eliminated in favor of using the <url> field to point
elsewhere. So you can ignore that part of the response.

The other advantage of using the <url> field to point to a URL on your
server is that this will minimize bandwidth usage. If a client only wants
plain text, it gets it in the XML response. If it wants to load HTML, the
client does this on its own and renders it as needed. I can certainly see
where HTML would be useful since your pages are so extensively hyperlinked.
I think it will make sense to add a <htm>true/false</htm> field to the
response, so a WWL server can indicate if rich text is available, although
if the <url> field is present, the client can probably assume that it will
be getting html in response when it fetches this URL. I'll think about this.

Is there a reference implementation we can compare against?

>>> Not for an encyclopedia, as you're the first one (and our first choice
for a pilot project due to the collaborative nature of your system). This is
actually good, as we can fine tune the XML response to address issues
specific to this type of system.

-- brion vibber (brion @ pobox.com)


from_name: Rick

subject: [WikiEN-l] Wikipedia in the news

body:
http://www.computerworld.com/hardwaretopics/hardware/story/0,10801,92096,00.html

RickK

---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20040412/1471b486/attachment.htm


from_name: Marcos Cramer

subject: [Wikipedia-l] LanguageSw.php

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


body:
I've thrown together a quick demo of what a single search result might
look like (see attached file). The WWL spec is a little fuzzy so who
knows. :) I've also tossed in the Creative Commons copyright info
metadata as it would be output from our existing metadata module.

Brian, let me know if this seems like a reasonable direction to you.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: WWL search example.xml
Type: application/octet-stream
Size: 4411 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040412/aadfb974/attachment.obj>


from_name: Michael Snow

subject: [Wikipedia-l] Re: meta deletion

body:
Anthere wrote:

>>It strikes me that the pages should be listed on VfD
>>
>>
>of >en.Wikipedia so this
>
>
>>little backwater that is not closely watched no
>>
>>
>longer >exists.
>
>Hum ?!?
>Are you suggesting that en.wikipedia is the place
>which will decide of deletions of pages located on
>meta ?
>
It strikes that this is part of the problem; Perl is applying the en:
procedures for deletion to meta. This is what we want to avoid.

>>Perhaps there should be more integration so that
>>separate separate accounts
>>and logging in could be eliminated.
>>
>>
>Are you suggesting that a sysop on one wikipedia would
>be sysop on all wikipedias ?
>
This need not be the case. A unified login system is sorely needed -
having to log in separately to each different site is a big hindrance to
working on multiple projects. I believe that is a big part of what makes
meta so poorly used. But integrating logins can be done without creating
universal sysops, other than perhaps the new "stewards". The system
should be able to provide different user abilities depending on which
project you are working on.

--Michael Snow
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20040412/db515df4/attachment.htm


from_name: Peter Jaros

body:
On Apr 11, 2004, at 11:04 PM, Erik Moeller wrote:

> There are other options aside from downranking Wikipedia mirrors.
> Google
> does have a deal with reference.com, whereby when you enter a word like
> "elephant", it provides a link to a dictionary [definition]. I'm not
> sure
> if reference.com pays them for that, and if so, how much. I could
> imagine
> a similar link [encyclopedia article] for searches which match
> Wikipedia
> titles.

I've thought about this possibility for a while.  Personally, I think
Reference.com is becoming a much poorer resource as it tries to become
a richer
company.  First it was advertising, which was a pain, but not too bad.
Now it
seems to often favor its "premium" definitions over the standard ones,
meaning
if you don't subscribe you can't find definitions for certain words.
I'd like
to see Wiktionary one day take over this function in Google.
Obviously, if
Reference.com pays for the placement, which they probably do, this is
pretty
far-fetched, at least for a while.

Adding an encyclopedia link might be feasible/plausible, since we're
not trying
to replace the dictionary link.

Peter

                                  -- ---<>--- --
                        A house without walls cannot fall.
           Help build the world's largest encyclopedia at Wikipedia.org
                                  -- ---<>--- --


from_name: Anthere

subject: [Wikipedia-l] Meta deletions

body:
Hi all :-)

I proposed a new deletion policy on meta.
http://meta.wikipedia.org/wiki/Meta_talk%3ARequests_for_deletion
There is no big deal, it is basically what we have
been doing for a long time now. It is very similar to
the english policy, with a couple of slight
differences however.

I think there was no real need to write precisely the
policy before, because we were just a little group of
people taking care of that and trusting one another
(though we definitly sometimes disagreed :-)).

Well, the place is growing and new members make it
necessary to better define the rules and strengthen
the process. I regret this.

Given yesterday occurences, I fear this is urgent.

__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/


list: wiktionary-l

from_name: Paulo Ricardo Colacino

subject: [Wiktionary-l] Wikitionary in Portuguese

body:
Dear Admins

I have had many problems with users from Portugal in pt.wikipedia.com about the differences of portuguese at Brazil and Portugal.

My suggestion was create the Wikitionary entries that community accepted.

We could setup de Wikitionary in portuguese language?

Tnks

Paulo Colacino
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wiktionary-l/attachments/20040412/72269b15/attachment.html


body:
Hello.

I am writing to introduce a project that complements Wikipedia. Jimmy suggested
I post here, so here goes...

The goal of the Worldwide Lexicon Project (www.worldwidelexicon.org) is to
create a standard procedure for discovering and querying a wide range of
language resources, including: machine translation servers, dictionaries,
encyclopedia (i.e. Wikipedia), and even human translators. Sounds ambitious,
but all WWL does is to create a machine-readable directory of language
services, and to define a standard set of CGI parm/value pairs and XML response
as a poor man's web services interface. Read about the REST method of building
web services, we borrowed heavily from this model.

We would like to ask the Wikipedia community to consider supporting WWL. This
is very easy to do. All that is required is to modify the existing search
script to recognize standard parameters used in WWL queries, and to generate an
XML response in place of HTML. How simple is this, here's an example.

A WWL client wants to search a Spanish Wikipedia for "Antoni Gaudi". This is a
two-step process. First the client, perhaps an embedded browser plug-in,
queries a WWL directory server as follows:

http://www.trekmail.com/wwl/sn.asp?action=findservices&sl=esp&servicetype=cyc

Note: if the client does not already know the location of a directory server,
it simply loads http://root.worldwidelexicon.org to get a list of directory
servers.

The directory server replies with an XML dataset containing a list of Spanish
encyclopediae including, presumably, a Spanish wiki. Each record contains a
baseurl for each server, which informs the client which script to invoke. The
record for the spanish Wikipedia might point to:
http://esp.wikipedia.org/search.php

The client then queries this script as follows:

http://esp.wikipedia.org/search.php?
qt=wwl&action=searchtext&searchscope=title&sl=esp&stext=antonio+gaudi

The wiki server replies with an XML dataset containing matching records, full
text, and pointers to HTML URLs for each record. All it does is respond with
XML versus HTML when it sees the qt=wwl parm/value pair. The client application
parses the XML and displays it as desired. (Note that I am using querystring
notation, the queries could also be submitted via the POST method).

If client side developers prefer, they can also access WWL services via
JavaBean or ActiveX objects. These are basically a collection of wrapper
functions that further simplify this process and also handle common errors.
These will be available later this month when we begin testing a multilingual
instant messaging client. These tools are not necessary, so developers can
build applications in any development environment that allows you to open a URL
and parse XML.

To support a basic WWL implementation requires trivial changes to the existing
search script. In the future, you may also consider implementing an extended
feature set that describes parent and child categories related to an entry. I
believe this will also be easy to implement, but the basic implementation
described above is a quick and easy job.

Why do this? What WWL does is create a peer-to-peer equivalent of the Google
API. So application developers will be able to build tools that can talk to
many types of WWL enabled resources. The range of possible applications is
quite broad. One application (among many) that is well suited to Wikipedia is a
translation memory. Commercial translation memory tools are expensive and often
not well maintained. By combining WWL and Wikipedia, it will be possible to do
the same thing with a lightweight client app.

If anyone is interested in creating a WWL front-end to Wikipedia, you can
contact me at brian AT mcconnell.net I will be glad to explain the system in
detail and answer questions regarding implementation.

Thank you for your time.

Brian McConnell, Project Leader
Worldwide Lexicon

PS - we will also be releasing a Java based Jabber client that talks to machine
translation servers, and that also matches users with bilingual users who are
willing to translate for other IM users.


subject: [Wikipedia-l] admin on meta

body:
http://meta.wikipedia.org/wiki/Talk%3AAdministrator

The new proposed policy for granting admin status on
meta is here. It will go live on the 17th of april if
no one complains.

Mind you, this is a major change of policy, since it
imposes limits while before there were none.

Again, this was not necessary before, but I fear we
outgrew the current policy relying on trust.

Next one will be the de-adminiship policy :-)

__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/


from_name: Brion Vibber

body:
On Apr 12, 2004, at 19:53, Brion Vibber wrote:
> I've thrown together a quick demo of what a single search result might
> look like (see attached file). The WWL spec is a little fuzzy so who
> knows. :) I've also tossed in the Creative Commons copyright info
> metadata as it would be output from our existing metadata module.

A slightly corrected version is now linked from:
http://meta.wikipedia.org/wiki/Worldwide_Lexicon

<language> changed to <sl> on Brian's suggestion, and a mistyped close
tag was fixed; the file passes the XML parsers of Mozilla 1.6, Internet
Explorer 6.0, and Safari 1.2. Please add any further suggestions to
that wiki page so we can keep them organized.

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] Re: Worldwide Lexicon and Wikipedia

body:
FYI. The content management system we use for our webserver mangles long URLs,
and converts ampersand characters into escape encoded strings. This just began
to occur recently.

The system will be ready for end-to-end testing by the end of the week. So by
Friday we will have a development environment for people to experiment with. We
expect to have a Apache/PHP implementation of the directory server running on a
dedicated box in early May. By then, the multilingual IM client should be ready
for testing as well.

Thanks for taking a look at our project.

Brian McConnell