from_name: Andries Krugers Dagneaux

body:
[[User:Pjacobi]] is on a hunt in the English and German Wikipedia to put
articles of VfD that he thinks are POV forks i.e. all Criticism articles
including [[Criticism of Wikipedia]] that has survived VfD a couple of
weeks ago. Other possible unjustified victims of the hunt are
[[Criticism of Prem Rawat]]. I agree that POV forks should be avoided
but a Criticism article does not have to be a POV fork.

[[User:Pjacobi]] overlooks the fact that there are legitimate criticism
articles. Legitimate criticism articles fulfill the following
conditions.
1. The main article is too big to contain all points the criticism. The
main article should contains a summary of the criticisms
2. The criticisms follow normal standards of NPOV, verifiability,
documentation elsewhere etc.
3. The points of criticism are followed by rebuttals that follow the
normal standards
4. The subject is relative to its size so controversial that it warrants
a separate criticism article. For example, the controversial status of
Scientology justifies an article [[Scientology_controversy]]

[[User:Pjacobi]] and I [[user:Andries]] agree that we need guidelines
about what Pjacobi calls "POV forks".

Andries K.D.


list: wikipedia-l

source: pipermail-mbox

from_name: Fred Bauder

subject: [Wikipedia-l] Duplicate article

body:
In this case one is British, one is American, but generally the policy is to
merge duplicate articles.

Fred

> From: Adam Hunt <kinema at gmail.com>
> Reply-To: wikipedia-l at Wikimedia.org
> Date: Sun, 27 Feb 2005 08:56:13 -0800
> To: wikipedia-l at wikipedia.org
> Subject: [Wikipedia-l] Duplicate article
>
> What is the policy on duplicate articles?  "U.S. customary units" and
> "Imperial unit" both cover the same topic.
>
> --adam
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l


from_name: Ævar Arnfjörð Bjarmason

subject: [Wikipedia-l] Duplicate article

body:
To merge them.

On Sun, 27 Feb 2005 08:56:13 -0800, Adam Hunt <kinema at gmail.com> wrote:
> What is the policy on duplicate articles?  "U.S. customary units" and
> "Imperial unit" both cover the same topic.
>
> --adam
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>


list: wikitech-l

subject: [Wikitech-l] Apache rewrite rule missing

body: I'd like it back too, not having to type an extra five characters was nice.


list: foundation-l

from_name: Daniel Mayer

subject: [Foundation-l] Fwd: [Wikimediafr-l] donations

body:
> Subject: [Wikimediafr-l] donations
> Date: Sunday 27 February 2005 06:49
> From: Dean Rivando <deanrivando (at) yahoo . ca>
> To: wikimediafr-l at wikimedia.org
>
> I would like to donate, but I will only do so if I receive a tax credit in
>  Canada. Can you please advise me whether you have charitable status with
> the Canada Customs and Revenue Agency and whether donations made in Canada
> are tax deductible.

While we are almost certainly are about to get tax exempt status in the United
States we have not yet explored that possibility for other nations. This may
require the formation of a Wikimedia chapter in Canada but we have not yet
looked into this.

Rest assured that once we have tax exempt status in the United States we will
explore ways to directly gain similar status in other nations where possible
and encourage the creation of national chapters where not.

-- Daniel Mayer

__________________________________
Do you Yahoo!?
Yahoo! Sports - Sign up for Fantasy Baseball.
http://baseball.fantasysports.yahoo.com/


list: wikimedia-l


list: wikien-l

subject: [WikiEN-l] article length: =<32Kb?

body:
It is the section editing that ended the technical need to limit an article
to 32K using Internet Explorer. Now unless it is the first section you need
to edit you don't need to edit the whole article or change browsers. I have
no idea why you can't edit the first section. Ability to do that should be
added.

Fred

> From: Viajero <viajero at quilombo.nl>
> Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
> Date: Sun, 27 Feb 2005 13:52:35 +0100
> To: English Wikipedia <wikien-l at Wikipedia.org>
> Subject: [WikiEN-l] article length: =<32Kb?
>
> Hi all,
>
> Perhaps I have been out of the loop on this development, but when I
> started contributing to WP, limiting article length to 32Kb was
> considered an important consideration. Lately, though, I've been
> encountering articles considerably longer. Yesterday, I wanted to
> refactor some material in one to tighten it up and another user
> objected, saying that [[George W. Bush]] was 72Kb in length. Has the
> 32Kb threshold effectively been abandoned?
>
> FWIW, I thought the 32Kb limit served as a useful stylistic constraint,
> as it encouraged a a measure concision in unwieldy topics. I am going to
> take a look at the Bush article in a moment to see what I think of such
> a long article.
>
>
> V.
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l


from_name: shantanu oak

subject: [Wikitech-l] Adding visited pages to watchlist automatically

body:
Is there any way to add all the pages I have visited, to my watchlist?

Shantanu Oak


subject: [WikiEN-l] article length: =<32Kb?

body:
--- Viajero <viajero at quilombo.nl> wrote:
> Perhaps I have been out of the loop on this development, but when I
> started contributing to WP, limiting article length to 32Kb was
> considered an important consideration. Lately, though, I've been
> encountering articles considerably longer. Yesterday, I wanted to
> refactor some material in one to tighten it up and another user
> objected, saying that [[George W. Bush]] was 72Kb in length. Has the
> 32Kb threshold effectively been abandoned?

Yes, this is still a very important consideration but at the same time it is no
longer a hard and fast rule due to the existence of separately-editable
sections and the extreme rarity of browsers that have issues editing articles
over 32KB.

However, some topics are so expansive that they do need 40 to even 50 KB of
text to be a comprehensive summary (such as a 'history of' article for a
country that has existed in one form or anther for a 1000 years) while the
great majority of topics can do the same job with less than 32KB of text. An
article about a single person, even such an important person as a president of
the United States, really needn't be longer than 32KB to be comprehensive
encyclopedia article about that person.

The example you give is way longer than is appropriate for the subject and
should be divided into a set of articles; at the top would be an article about
George W. Bush divided into sections. Any one section could be a summary of an
article that goes into more detail on that aspect of his life. Almost all of
the material about the Bush Administration and policies thereof could be
summarized at [[George W. Bush]] and spun into [[George W. Bush
Administration]] (now just a redirect).

The existing foreign and domestic policy articles along the first and second
term articles could be similarly organized from [[George W. Bush
Administration]] (the host of other articles are a disorganized mess that I
don't know what to do with; it might be best to have some of them be stand
alone articles; such as articles on single events or people).

[[Ronald Reagan]] was 65KB until I summarized the massive ==Presidency==
section there and moved the detail to [[Reagan Administration]]. Both articles
still triggered the 32KB warning, but both were at a much more manageable size
as a result (I see that [[Ronald Reagan]] is up to 55KB again ; time for
another refactor).

The point of this kind of organization (which I call summary style) is to not
overwhelm the reader with too much detail up front. This is done by summarizing
the most important aspects of a subject and going into further detail with
daughter articles (repeat this as many times as you like until all aspects of a
topic are very thoroughly covered).

The best way this works, however, is to let articles grow into the 40 to 50+ KB
range and *then* start to look for areas that could logically be summarized and
the detail moved to daughter articles. Splitting articles prematurely can
create a disorganized and illogical mess unless it is part of a well-organized
and well-thought-out WikiProject scheme (such as WikiProject Countries).

Encyclopedia articles need to stay closely on topic ; going into too much
detail on any aspect of the topic up front tends to lose this tight focus on
the subject (such as going on and on about the Bush Administration in an
article on the man - the two are really different yet linked subjects).

More info at http://en.wikipedia.org/wiki/Wikipedia:Summary_style

-- mav

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


from_name: Adam Hunt

subject: [Wikipedia-l] Duplicate article

body:
What is the policy on duplicate articles?  "U.S. customary units" and
"Imperial unit" both cover the same topic.

--adam


from_name: dpbsmith at verizon.net

subject: [WikiEN-l] POV forks, and "the 32K devil made me do it"

body:
I don't know whether PJacobi is "on a hunt," but I am not at all happy
about the current state of the "Prem Rawat" and "Criticism of Prem
Rawat" article. While trying not to extend that battle here, I want to
make two points:

a) HYPOTHETICALLY (i.e. I DO NOT want to argue about whether Prem Rawat
actually is an example of this situation): SUPPOSE that there is a
topic that is being contentiously edited by two factions, A and B, that
include most of the WIkipedians actively interested in working on the
topic. The two factions could cut a deal in which they produce two
articles, one presenting faction A's viewpoint and one presenting
faction B's viewpoint, and agree that they will each tolerate and stay
out of the other faction's article provided the other faction does the
same. In this case, you have two POV articles--and because of the
agreement by the two factions and the disinterest by other Wikipedians,
the situation is likely to be stable.

Surely we agree that that is a VERY unsatisfactory situation, and not
what is meant by NPOV?

If we have to have this sort of thing, we need to figure out out a way
to legitimize it, e.g. with a template saying "This article represents
one view of a disputed issue. For the other view, see..."

b) In any case, I really dislike seeing the 32K limit being brought up
as justification for doing things. 32K is a reasonable _guideline,_ and
that articles in, say, the range 32K to 96K should be refactored
_eventually_. But it should not be regarded as an urgent necessity.
Particularly in the case of a disputed topic, the article should be
left to stew and mellow. _When it has reached a stable state_, the need
to break it up should be discussed.

But breaking up an oversized article shouldn't be a high priority.
Breaking up a 32 to 96K article is just _cleanup,_ and it's a _lot_
less important than a lot of other cleanup. _As long as no single
section_ is over 32K, people with older browsers can participate
actively in almost every part of the editing process. About all that
they cannot do is load the entire article as a whole in order to make
major changes in the section organization.

I think the 32K limit is often used as a convenient excuse for unwise
breakouts--specifically, POV splits and subtrivia. ("I couldn't put the
vital, encyclopedic, verified fact that John Kerry flip-flopped in
August, 1960 at the Central Street McDonalds when he ordered a Quarter
Pounder _and tried to exchange it for a Quarter Pounder with
Cheese_--the main article is over 32K!)

The 32K limit gets an unjustified amount of attention because a warning
is displayed automatically. The wording of that warning ought to be
toned way down. This is just one of many issues involved in browser
compatibility, and not the most important one.

I notice that no warning is displayed about the use of Unicode
characters, even though these also present problems in older browsers
(and sometimes newer ones!) In gauging the seriousness of these issues,
note too that using characters outside, say, ISO Latin-1 actually
presents problems to people passively _viewing_ the article, whereas
articles over 32K are still viewable by everyone (and editable within
sections by everyone).

--
Daniel P. B. Smith, dpbsmith at verizon.net
"Elinor Goulding Smith's Great Big Messy Book" is now back in print!
Sample chapter at http://world.std.com/~dpbsmith/messy.html
Buy it at http://www.amazon.com/exec/obidos/ASIN/1403314063/


from_name: Thomas Gries

subject:
[Wikitech-l] Proposed: one new link (diff-to-LVR) for watched
	pages in RecentChanges, Watchlist and PageHistory screens

body:
Ben Brockert schrieb:

>> Wish to receive your proposals for a changed screen layout ......
>>
>>        - how would *you* arrange the screens
>>        - proposal for the short text for such a link ? (diff-to-LVR)
>> is not neat enough
>
> I like the current setup on Meta (why is it different than the setup
> on en?); this link could be added in before the other two:
> * (chng) (diff) (hist) . . m [[page name]]; ti:me . . [[User:]]
> ([[User talk:]]) (edit summary)
>
> How will this affect server performance? My watchlist is refreshed
> half a dozen times on a day that I'm not working on Wikipedia, ten
> times as often on a day that I am. Even if you only store the read
> state for items in the watchlist, and not all visited pages, that's
> still over 500 articles (for me).

Thank you for your comments.

Some quick answers:

a) Only 1 update takes place: if your watched page X is changed by
somebody else, this notificationtimestamp (= after your last-visit time)
is kept in the table watchlist and [optionally, the ENotif is mailed to
you (with the link "diff-to-LVR") - this is why I gave the flag the name].
 There are no further updates necessary, i.e. there are no further
updates to the entry of your watched page X in the database.

b) When you actually revisit the page X,  a second update of the
watchlist table is necessary to reset the notificationtimestamp. The
page X is still kept on your pagelist, but no longer marked with
"updated since your last visit". Your visit to the page automatically
re-enables the ENotif, so that you will receive an ENotif again on a
further changes of somebody else but you, which very suppress - ENotif
sends only one mail on the first change.

T.


from_name: Sean Barrett

subject: [WikiEN-l] article length: =<32Kb?

body:
NSK stated for the record:

> On Sunday 27 February 2005 14:52, Viajero wrote:
>
>>started contributing to WP, limiting article length to 32Kb was
>
>
> I see no reason why somebody would want to limit an article to 32Kb.

...which, of course, has no bearing on whether or not such limits should
or do exist....

--
  Sean Barrett     | I think we've all learned a
  sean at epoptic.com | valuable safety tip here.


from_name: Stan Shebs

subject: [WikiEN-l] article length: =<32Kb?

body:
Viajero wrote:

> Hi all,
>
> Perhaps I have been out of the loop on this development, but when I
> started contributing to WP, limiting article length to 32Kb was
> considered an important consideration. Lately, though, I've been
> encountering articles considerably longer. Yesterday, I wanted to
> refactor some material in one to tighten it up and another user
> objected, saying that [[George W. Bush]] was 72Kb in length. Has the
> 32Kb threshold effectively been abandoned?
>
> FWIW, I thought the 32Kb limit served as a useful stylistic
> constraint, as it encouraged a a measure concision in unwieldy topics.
> I am going to take a look at the Bush article in a moment to see what
> I think of such a long article.

Yes, the 32K limit should still be encouraged. Not only is there
still the risk of old browsers mangling long articles, but this
is the encyclopedia, not wikibooks. People delighting in long
articles should consider that 99% of readers will drop off long
before they get to the end of a 5,000-word article, so it's as
if the material at the end doesn't even exist; better to make
several shorter articles interlinked so readers can steer to the
desired details more quickly.

Stan


from_name: Tels

subject:
[Wikitech-l] editpage.php "page" "text" "summary" (prepends or
	appends a text to a page)

body:
-----BEGIN PGP SIGNED MESSAGE-----

Moin,

On Sunday 27 February 2005 00:23, Thomas Gries wrote:
> Jakob has asked me to write a tiny script, which can be called from the
> commandline to add (or to prepend) an arbitrary text to a wiki page.
> The script is for mediawiki 1.3.11 (which uses wpEditToken instead of
> wpEdittime to detect edit collisions)
>
> Usage:
> php editpage.php "Pagename" "A new text, created by ~~~~" "edit
> summary, optional"

Oh, cool. That would be idial for automated programs to post "news" or
similiar things to internal wikis. Or building a "news"  form, where a
human can enter a short news text and it is automatically added in the
right place in the wiki.

> Code on request

Bitte, bitte, bitte! :)

Best wishes,

Tels

- --
 Signed on Sun Feb 27 11:09:14 2005 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Retsina?" - "Ja, Papa?" - "Angriff im Morgengrauen." - "Is gut, Papa."

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQEVAwUBQiGcpHcLPEOTuEwVAQH2jgf+Ovv19FeuMnB5Buzh2pXhwAQZUfHv+7wk
KOMHfB4fUr+IKx1u0y1Gbg+N+qPgRNxiUIn2nox/YfTNX+iIcN/vcqK20DIwa1za
hla1S/g2hfvVz+Fyl0Vpx9Z33HXkolMD5/vsRkUULHqYCZ95yXBQ/EGk7McMbiNV
wuHU5691bQ3stGgBfyJV0mnS4+Voba/wG+FUqod3qEx3liiBF2+5fJkBqg7Lecfu
TDUArM7rBgMkZjNXbJCPALY7/dIcbtoiwjmvjgERGm4FEihISmRSNv2iLDNgMibD
LTDrcJbBboVU7tTxHYmP6gHvVzQAAs+m8QOH/revrR4DjNty6G0LDg==
=9tQ6
-----END PGP SIGNATURE-----


from_name: Bryan Derksen

body:
At 09:59 AM 2/27/2005 -0500, dpbsmith at verizon.net wrote:
>The 32K limit gets an unjustified amount of attention because a warning is
>displayed automatically. The wording of that warning ought to be toned way
>down. This is just one of many issues involved in browser compatibility,
>and not the most important one.

My own personal bugaboo with regards to the "we _must_ split this article
because it's so long" is the articles that wind up with (part 1 of 4),
(part 2 of 4), (part 3 of 4), etc. in their titles. If an article's to be
split then IMO it should be split solely along content lines so that the
resulting articles can be named reflecting what's actually covered by them,
not given arbitrary names like this.

Anyone know if there's a naming convention about this?
http://en.wikipedia.org/wiki/Naming_conventions#Do_not_use_an_article_name_that_suggests_a_hierarchy_of_articles
looks like it could apply.

--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 266.5.0 - Release Date: 2/25/2005


from_name: Matt Brown

body:
Which browsers actually have a problem with text boxes over 32K?  As I
recall, it's old browsers with a vanishingly small percentage of users
these days.


from_name: Jim Higson

subject: [Wikitech-l] Re: Testing if a page exists

references:
<cvnmue$e78$1@sea.gmane.org> <421F86E0.1060909@pobox.com>
	<cvr6e0$gcc$1@sea.gmane.org> <cvr6tk$h6h$1@sea.gmane.org>
	<cvrb0s$o8q$1@sea.gmane.org>

body:
Kate Turner wrote:

> Jim Higson wrote in gmane.science.linguistics.wikipedia.technical:
>
>> This at least gives a consistant (at least until this oddness is fixed)
>> way to tell if a page exits, so I know to colour my links red or blue.
>
> are you going to make an http request for every link in the page?

At the moment, yes, while I'm trying to go as far as possible sitting on top
of the existing mediawiki. Ideally there'd be some way to post the server a
list of articles, and get back a list of which ones exist.

You can see this in action in the demo I posted earlier.

Jim


subject: [WikiEN-l] Re: POV forks, and "the 32K devil made me do it"

body:
--- Pete/Pcb21 <pete_pcb21_wpmail at pcbartlett.com> wrote:
> I have a vague recollection that there was some good reason why
> MediaWiki: pages got protected en masse when the Template: namespace was
> introduced. If there is, then I will be willing to serve as the
> community's servant and change it to whatever they see fit as spelt out
> on the talk page. If not, I will unprotect it and put it on my watchlist.

All MediaWiki messages are protected because they are system messages. AFAIK,
system messages have always been protected.

-- mav

__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo


from_name: JAY JG

subject: [WikiEN-l] article length: =<32Kb?

body:
>FWIW, I thought the 32Kb limit served as a useful stylistic constraint, as
>it encouraged a a measure concision in unwieldy topics. I am going to take
>a look at the Bush article in a moment to see what I think of such a long
>article.

While the limit is sometimes helpful stylistically, I think it was more
related to the editing limits of certain (now generally obsolete) web
browsers.

Jay.


subject: [Foundation-l] Day 9 Fund Drive Report

body:
On Day 9 (Saturday 26 February eastern US timezone since PayPal data are not
available in UTC) we made $5,869.19 (USD equivalent) through PayPal (completed
payments only; no updates available for other sources at this time).

This is an increase of 57.14% from Day 8 and represents 10.54% of total funds
collected so far ($61,574.83 ; only counting full days) and 7.83% of our goal
($75,000). At the end of Day 9 we had reached 82.10% of our goal.

Day  9			Day 8 comparison
Breakdown:
PayPal		USD equiv	USD equiv	%change
AUD	  191.00   $150.99	   $74.38	103.00%
CAD 	 268.97	   $217.95	  $179.43	 21.46%
EUR 	1149.90	 $1,503.15	  $953.63	 57.62%
GBP 	 475.11	   $901.66	  $234.04	285.27%
JPY	16245	   $153.99	   $35.83	329.76%
USD	2941.46	 $2,941.46	$2,257.79	 30.28%
PayPal total:	 $5,869.19	$3,735.10	 57.14%

MoneyBookers	 no data           $0.00	 0.00%
Mail/Post	 no data           $0.00	 0.00%

	TOTAL	$5,869.19	$3,735.10	57.14%

Grand totals so far (only counting complete days)

PayPal		   USD equiv	%GrandTotal
AUD	1618.80	   $1,279.66	 2.08%
CAD 	2957.00	   $2,396.06	 3.89%
EUR 	15412.07  $20,146.66	32.72%
GBP 	3350.06	   $6,357.74	10.33%
JPY	154158.00  $1,461.26	 2.37%
USD	29136.76  $29,136.76	47.32%
PayPal total:	  $60,778.14

Moneybookers:	    $426.69	  0.69%
Mail/Post	    $370.00	  0.60%

GRAND TOTAL	 $61,574.83	100.00%

% toward goal        82.10%

For the most recent grand total and other details visit
http://wikimediafoundation.org/wiki/Fund_drives/2005/Q1

Some selected comments from Day 9:
See http://wikimediafoundation.org/wiki/Fund_drives/2005/Q1/Day_9

"Very handy resource, keep up the great work." by Anonymous

"Gladly support the Great Wikipedia Project" by Grant Slater

"I teach history and geography and use Wikipedia weekly. Excellent, easy to
access source of information." by Tom Gleason

"Viva la information revolution!" by Anonymous

"Great public project. Everyone should contribute financially and with their
editing efforts" by Bernard Farrell

"Das ist echte Wissens-Allmende!" by Adolf J Winterer

"Wikipedia is an invaluable research tool." by Anonymous

"Nothing compares to Wikipedia. It's the greatest informer." by Niels Buus

"A shining example of what the net is really all about." by William Finley

"MY COLLEGE STUDENTS DEPEND ON WIKIPEDIA; I so appreciate its well researched
articles on musical genres, especially" by Anonymous

"Keep it free & non-biased high quality!" by Anonymous

"I sent $1200 during your last fundraising drive. Here's $50 more for good
measure. Enjoy, and keep up the good work! Thanks, -David" by Anonymous

"By the people for the people" by Andrew Black

Some of my favorites:

"because freedom isn't free" by Anonymous

"De omni re scibili et quibusdam aliis." by Berteun Damman

"Love the site, hope you reach your goal easily and then some" by Mark Bullard
Jr

"Keep it Going. the records of the passage of time and events are no less
important than food and drink." by Zia imaging

"Oh all the services out there on the internet, I think this is one of the most
deserving of support. Thanks, very much!" by Michael Bierschenk

"...Wikipedia has already supplanted the great Encyclopedia Galactica as the
standard repository of all knowledge and wisdom..." (with apologies to Douglas
Adams)" by Christopher Allen

"Ciao" by Anonymous

Daniel Mayer,
Wikimedia CFO

__________________________________
Do you Yahoo!?
Yahoo! Sports - Sign up for Fantasy Baseball.
http://baseball.fantasysports.yahoo.com/


subject: [Foundation-l] Day 9 Fund Drive Report


subject: [Wikipedia-l] Day 9 Fund Drive Report


from_name: Tomer Chachamu

subject: [Wikitech-l] Early preview of client-side wiki presentation

body:
> An Apache mod rewrite rule defers all request to the same html page. This page is just a stub that kicks off the Javascript that fetches, parses and presents the content. Wikiwyg can run on top of any existing mediawiki without changes.
> All content is fetched using XMLHTTP and a mix of action=raw and Special:Export. Links are coloured red or blue a few seconds after they are first displayed, because it takes a little time between parsing the link and getting back a HEAD request to check if the article exists.

Does this mean that we can use it to browse Wikipedia, with a few
modifications? That would decrease server load, right?

It may not have template inclusion support and it displays masses of
XML per page, but it's worth it. ;)

By the way, I see <link avaliable="unknown"> a lot in the XML. It
should be "available", not "avaliable". ;)


body:
On Sun, 27 Feb 2005 07:58:51 +0530, shantanu oak <shantanu.oak at gmail.com> wrote:
> Is there any way to add all the pages I have visited, to my watchlist?

No.


subject: [Wikitech-l] Re: Early preview of client-side wiki presentation

body:
Tomer Chachamu wrote:

>> An Apache mod rewrite rule defers all request to the same html page. This
>> page is just a stub that kicks off the Javascript that fetches, parses
>> and presents the content. Wikiwyg can run on top of any existing
>> mediawiki without changes. All content is fetched using XMLHTTP and a mix
>> of action=raw and Special:Export. Links are coloured red or blue a few
>> seconds after they are first displayed, because it takes a little time
>> between parsing the link and getting back a HEAD request to check if the
>> article exists.
>
> Does this mean that we can use it to browse Wikipedia, with a few
> modifications? That would decrease server load, right?

I've changed the main page from something silly to something that explains
this. Yes, it could be used on top of any mediawiki, alongside the existing
interface. Running two interfaces has issues though, we'd have to try to
replicate any bugs in the PHP parser to keep the thing consistent.

> It may not have template inclusion support and it displays masses of
> XML per page, but it's worth it. ;)

Actually, I'm working on templates now. Templates are actually quite easy,
just another http request. The XML dump is just so I can see that the
parser is working fine, it won't be there when I'm done.

Tables also aren't supported, nor editing, which is my next sub-project.

> By the way, I see <link avaliable="unknown"> a lot in the XML. It
> should be "available", not "avaliable". ;)

Feel free to correct any other spellings - never my strong point.


from_name: Ray Saintonge

subject: [Wikipedia-l] Duplicate article

body:
Of course when merging them it's important to remember such things as
the difference between the Imperial gallon and the US gallon.
Ec

Fred Bauder wrote:

>In this case one is British, one is American, but generally the policy is to
>merge duplicate articles.
>
>Fred
>
>
>
>>From: Adam Hunt <kinema at gmail.com>
>>Reply-To: wikipedia-l at Wikimedia.org
>>Date: Sun, 27 Feb 2005 08:56:13 -0800
>>To: wikipedia-l at wikipedia.org
>>Subject: [Wikipedia-l] Duplicate article
>>
>>What is the policy on duplicate articles?  "U.S. customary units" and
>>"Imperial unit" both cover the same topic.
>>
>>--adam
>>
>>


from_name: Viajero

subject: [WikiEN-l] article length: =<32Kb?

body:
Hi all,

Perhaps I have been out of the loop on this development, but when I
started contributing to WP, limiting article length to 32Kb was
considered an important consideration. Lately, though, I've been
encountering articles considerably longer. Yesterday, I wanted to
refactor some material in one to tighten it up and another user
objected, saying that [[George W. Bush]] was 72Kb in length. Has the
32Kb threshold effectively been abandoned?

FWIW, I thought the 32Kb limit served as a useful stylistic constraint,
as it encouraged a a measure concision in unwieldy topics. I am going to
take a look at the Bush article in a moment to see what I think of such
a long article.

V.


body:
Yann Forget wrote:

>Hi,
>
>Can someone answer him ?
>
>From: Dean Rivando <deanrivando (at) yahoo . ca>
>
>Hi there,
>
>I would like to donate, but I will only do so if I receive a tax credit in
> Canada. Can you please advise me whether you have charitable status with the
> Canada Customs and Revenue Agency and whether donations made in Canada are
> tax deductible.
>
This is not available, and it could be a long while before it is.
Canadian tax relief for foreign donations applies only in limited
circumstances.  One of those might be if you have US source income.  For
practical purposes getting tax relief in Canada depends on having an
organization that is registered as a charity in Canada.  Part of the
application process includes submitting  a recent financial statements,
and that can't be done until there's an organization.  Once the
organization is registered the donated funds must be used to support
Canadian operations.

There are circumstances where a Canadian structiore would be beneficial,
but an organization would be needed first, and I haven't seen much
interest expressed in that.

Ec


from_name: zero 0000

subject: [WikiEN-l] Edit link on first section

body:
Fred wrote:
> It is the section editing that ended the technical need to limit
> an article to 32K using Internet Explorer. Now unless it is the
> first section you need to edit you don't need to edit the whole
> article or change browsers. I have no idea why you can't edit
> the first section. Ability to do that should be added.

Yes, please oh please give us an Edit link on the first section.

Zero.

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


body:
David Gerard wrote:

> Matt Brown wrote:
>
>> Which browsers actually have a problem with text boxes over 32K?  As I
>> recall, it's old browsers with a vanishingly small percentage of users
>> these days.
>
> Old Netscape, some old Opera.
>
> Nevertheless, I'm a big fan of the 32K limit. People who say the limit is
> fine for *other* topics, but *their* topic requires EVERY LAST DETAIL IN
> THE MAIN ARTICLE because the editors can't sort something out, well ...

I too would like to put in a word for article length limits.  Whether
32K is still the optimal length would still be an open question; perhaps
it could be increased a little.

Section editing has only dealt with one of the problems that come from
these articles.   It's not just slow browsers that are a problem.  So
are slow internet connections.  High speed service is not universally
available.  Long articles that are heavily wikified are also bound to
put a strain on the system, which needs to determine which should be red
and which should be blue.

A further benefit of having length limits on articles is the effect on
writing styles.  A good exercise for anybody who has just written an
article is to rewrite it and say the same thing with 75% of the words.

Article size is a bigger problem with Wikisource where people often
upload whole books as a single file, and then walk away without any
further editing.  We currently have 752 files that exceed 100Kb in
length.  17 of them are more than 1Mb long, and the longest of these has
nearly 4.3Mb of text in Gothic Latin.  For us it would be a big step
forward if everybody observed a 100Kb limit. :-)

Ec


subject: [WikiEN-l] Re: article length: =<32Kb?

body:
Viajero wrote:
> Hi all,
>
> Perhaps I have been out of the loop on this development, but when I
> started contributing to WP, limiting article length to 32Kb was
> considered an important consideration. Lately, though, I've been
> encountering articles considerably longer. Yesterday, I wanted to
> refactor some material in one to tighten it up and another user
> objected, saying that [[George W. Bush]] was 72Kb in length. Has the
> 32Kb threshold effectively been abandoned?
>
> FWIW, I thought the 32Kb limit served as a useful stylistic constraint,
> as it encouraged a a measure concision in unwieldy topics. I am going to
> take a look at the Bush article in a moment to see what I think of such
> a long article.
>
>
> V.

In the recent village pump revisting of this very topic, all that was
established was that

1) the hard 32kb limit due to technical reasons has been abandoned since
the inception of section-editing.

2) Softer limits due to readability and editability should be left for
editors to work out on a case-by-case article-by-article basis - though
good practice such as summary style tends to spread quickly.

The GWB article is the hardest "case" I've seen -

i) We've already spun out sub-pages on many aspects
ii) Trying to be even-handed on contentious topics tends to create a lot
of words

GWB is one article where we have too much colloboration :),


from_name: Brion Vibber

subject: [Wikitech-l] JavaScript extension "CharInsert.php" -- help needed

body:
Thomas Gries wrote:
> I need help for getting the <charinsert> .... </charinsert> tags working
> in my local Mediawiki.Copryrightwarning
>
> What I did already
>
> 1. copied [1] to my local wiki page:Mediawiki:Copyrightwarning
> 2. copied [2] from CVS to /mywiki/extensions)
> 3. command inserted in LocalSettings.php: include
> ($IP."/extensions/CharInsert.php");
>
> but I still cannot click onto one of the special characters.

You need to be more detailed. Why can't you click them? Are they not
there? Are they not links? Can you in fact click on them, but nothing
happens? What happens instead? Is there a JavaScript error? Have you
examined the HTML output? Have you tried variations of the page? What's
the exact text you tried running? Did you purge or save the page after
installing the extension? Is this page on the internet where others
could look at it?

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


subject:
[Wikipedia-l] Why: W3C-checklink/4.1 [4.14] libwww-perl/5.803
	->	Error 403

body:
Gerrit Holl wrote:
> whenever a request is sent to Wikipedia with the following header, the
> result is Error 403:
>
> User-Agent: W3C-checklink/4.1 [4.14] libwww-perl/5.803
[snip]
> Why is Error 403 served at all?

libwww-perl is blocked, as we have had a lot of trouble in the past with
poorly behaved spiders.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20050227/7e45ea95/attachment.pgp


from_name: Yann Forget

body:
Hi,

Can someone answer him ?

Subject: [Wikimediafr-l] donations
Date: Sunday 27 February 2005 06:49
From: Dean Rivando <deanrivando (at) yahoo . ca>
To: wikimediafr-l at wikimedia.org

Hi there,

I would like to donate, but I will only do so if I receive a tax credit in
 Canada. Can you please advise me whether you have charitable status with the
 Canada Customs and Revenue Agency and whether donations made in Canada are
 tax deductible.

thanks,

Dean Rivando

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


list: wiktionary-l

subject: [Wiktionary-l] Interwiki bot on redirect

body:
Hi,

It seems that the interwiki bot add links in redirects, which break them (in
the French Wiktionary). The links are also inserted at the top of the article
instead of the bottom.

Regards,
Yann

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


from_name: Violet/Riga

subject: [WikiEN-l] article length: =<32Kb?

body:
I find it quite amusing that the sections with separate articles, such
as ==Foreign policy and security== and [[Foreign policy of the George
W. Bush administration]], are extended to over 1300 words.  Surely
they could be summarised futher?

~~~~ Violet/Riga


body:
If people agree that the warning is too prominent, remember it can be
edited at

[[MediaWiki:Longpagewarning]]

- the talk page has been unedited for over a year.

Pete

p.s.

One reason that the 32k was displayed more prominently than other
problems is that it has the capacity to affect other users - if you have
an inept browser and edit a long page you will cut off the tail of the
article and affect others. Unicode issues only affect the person with
the defective browser.

dpbsmith at verizon.net wrote:

> I don't know whether PJacobi is "on a hunt," but I am not at all happy
> about the current state of the "Prem Rawat" and "Criticism of Prem
> Rawat" article. While trying not to extend that battle here, I want to
> make two points:
>
> a) HYPOTHETICALLY (i.e. I DO NOT want to argue about whether Prem Rawat
> actually is an example of this situation): SUPPOSE that there is a topic
> that is being contentiously edited by two factions, A and B, that
> include most of the WIkipedians actively interested in working on the
> topic. The two factions could cut a deal in which they produce two
> articles, one presenting faction A's viewpoint and one presenting
> faction B's viewpoint, and agree that they will each tolerate and stay
> out of the other faction's article provided the other faction does the
> same. In this case, you have two POV articles--and because of the
> agreement by the two factions and the disinterest by other Wikipedians,
> the situation is likely to be stable.
>
> Surely we agree that that is a VERY unsatisfactory situation, and not
> what is meant by NPOV?
>
> If we have to have this sort of thing, we need to figure out out a way
> to legitimize it, e.g. with a template saying "This article represents
> one view of a disputed issue. For the other view, see..."
>
> b) In any case, I really dislike seeing the 32K limit being brought up
> as justification for doing things. 32K is a reasonable _guideline,_ and
> that articles in, say, the range 32K to 96K should be refactored
> _eventually_. But it should not be regarded as an urgent necessity.
> Particularly in the case of a disputed topic, the article should be left
> to stew and mellow. _When it has reached a stable state_, the need to
> break it up should be discussed.
>
> But breaking up an oversized article shouldn't be a high priority.
> Breaking up a 32 to 96K article is just _cleanup,_ and it's a _lot_ less
> important than a lot of other cleanup. _As long as no single section_ is
> over 32K, people with older browsers can participate actively in almost
> every part of the editing process. About all that they cannot do is load
> the entire article as a whole in order to make major changes in the
> section organization.
>
> I think the 32K limit is often used as a convenient excuse for unwise
> breakouts--specifically, POV splits and subtrivia. ("I couldn't put the
> vital, encyclopedic, verified fact that John Kerry flip-flopped in
> August, 1960 at the Central Street McDonalds when he ordered a Quarter
> Pounder _and tried to exchange it for a Quarter Pounder with
> Cheese_--the main article is over 32K!)
>
> The 32K limit gets an unjustified amount of attention because a warning
> is displayed automatically. The wording of that warning ought to be
> toned way down. This is just one of many issues involved in browser
> compatibility, and not the most important one.
>
> I notice that no warning is displayed about the use of Unicode
> characters, even though these also present problems in older browsers
> (and sometimes newer ones!) In gauging the seriousness of these issues,
> note too that using characters outside, say, ISO Latin-1 actually
> presents problems to people passively _viewing_ the article, whereas
> articles over 32K are still viewable by everyone (and editable within
> sections by everyone).
>
> --
> Daniel P. B. Smith, dpbsmith at verizon.net
> "Elinor Goulding Smith's Great Big Messy Book" is now back in print!
> Sample chapter at http://world.std.com/~dpbsmith/messy.html
> Buy it at http://www.amazon.com/exec/obidos/ASIN/1403314063/


from_name: Christiaan Briggs

references:
<20050227125020.0D7AF1AC17EE@mail.wikimedia.org>
	<cc43d9ebf1fc2d18471c86c97a970ac3@verizon.net>
	<cvso78$bi3$1@sea.gmane.org>

body:
Pete/Pcb21 wrote:

> If people agree that the warning is too prominent, remember it can be
> edited at
>
> [[MediaWiki:Longpagewarning]]

But it's protected.

Christiaan


body:
Thomas Gries wrote:
> The <charinsert> tags are not translated to javascriptlets on a  page X:
> The HTML of a page X action=edit shows _still_ the <charinsert> ...
> </charinsert> tags.
>
> But the HTML of and the rendered page Mediawiki:Copyrightwarning show
> the <a href="javascript:insertTag()"....>... </a> scriptlets
>
> mediawiki version 1.3.11
> Did I overlook something ?
> Why aren't they replaced by the javascript ?

In MediaWiki 1.3, the copyrightwarning message is raw HTML, so no
interpretation of wikitext (such as extensions) will occur. I wrote the
CharInsert extension to continue to provide the insert capability when
it was switched from raw HTML to wikitext in 1.4.

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


from_name: Gerrit Holl

subject:
[Wikipedia-l] Why: W3C-checklink/4.1 [4.14] libwww-perl/5.803 ->
	Error 403

body:
Hi,

whenever a request is sent to Wikipedia with the following header, the
result is Error 403:

User-Agent: W3C-checklink/4.1 [4.14] libwww-perl/5.803

The resulting document has a XHTML 1.0 Strict definition, but it is not
valid XHTML 1.0 Strict - see
http://topjaklont.student.utwente.nl/invalid.html and try to validate
it.

Why is Error 403 served at all? As for example www.sp.nl proves,
W3C-checklink can obey robots.txt. It also sleeps one second between
each request, so it does a fair job in throttling. What's the problem
then?

regards,
Gerrit Holl.

--
Weather in Twenthe, Netherlands 27/02 16:25:
	-3.0?C   wind 6.3 m/s NNE (57 m above NAP)
--
In the councils of government, we must guard against the acquisition of
unwarranted influence, whether sought or unsought, by the
military-industrial complex. The potential for the disastrous rise of
misplaced power exists and will persist.
    -Dwight David Eisenhower, January 17, 1961


body:
Christiaan Briggs wrote:

> Pete/Pcb21 wrote:
>
>> If people agree that the warning is too prominent, remember it can be
>> edited at
>>
>> [[MediaWiki:Longpagewarning]]
>
>
> But it's protected.
>
> Christiaan

I have a vague recollection that there was some good reason why
MediaWiki: pages got protected en masse when the Template: namespace was
introduced. If there is, then I will be willing to serve as the
community's servant and change it to whatever they see fit as spelt out
on the talk page. If not, I will unprotect it and put it on my watchlist.

Pete


from_name: David Gerard

body:
Matt Brown wrote:

> Which browsers actually have a problem with text boxes over 32K?  As I
> recall, it's old browsers with a vanishingly small percentage of users
> these days.

Old Netscape, some old Opera.

Nevertheless, I'm a big fan of the 32K limit. People who say the limit is
fine for *other* topics, but *their* topic requires EVERY LAST DETAIL IN
THE MAIN ARTICLE because the editors can't sort something out, well ...

- d.


from_name: dpbsmith at verizon.net

subject: [WikiEN-l] Re: "The 32K limit made me do it"

body:
1) I'm not necessary challenging the 32K limit itself. I was urging
that the message present 32K as a _soft_ limit, a guideline requiring
_deliberate_ action. The old message sounds like a call to jump in and
do something immediately.

I've Been Bold and rewritten the message. It now reads:

"Note: This page is 38 kilobytes long. Under current  article size
guidelines, articles that exceed 32KB are considered to be too long. It
may be appropriate to restructure this topic into a related series of
shorter articles, or split off a section of it as a separate article.
However, these are major structural changes which should not be made
hastily, and should be made by consensus agreement among editors of the
page. See the guidelines for details."

The new text links to [[Wikipedia:Article size]]. That article should
now be expanded to discuss not just the technical issue but some
obvious observations on size problems should be handled. Specifically,
it should say that if a _controversial_ section of the article has
grown large, it should _not_ be split off as a separate article
_unless_ all editors are certain that the title and content of the new
article exhibit a neutral point of view.

2) Christiaan Briggs <christiaan at last-straw.net> asks

> So what are the generally accepted criteria for length of articles in
> encyclopedias?
>
> Christiaan

People should be getting tired of my stock answer to this, which is
that the Eleventh Edition of the Encyclopaedia Britannica contains
articles which exceed one megabyte in size. I need to get to the
library and see what size the juicier articles in the Britannica 3
Macropaedia are.

3) An important consideration is _how well indexed_ the encyclopedia
is. It's a benefit if you can guess the location of your article
without having to consult the index. The Britannica 3 Micropaedia is
sort of interesting: it's essentially a TEN-volume combination of an
index and all the stub-sized articles. The Britannica 11th is notable
for having an absolutely superb index.

In case anyone doesn't know, indexing a traditional book is a specialty
in itself and involves huge amounts of judgement and creativity. People
tend to think that it's a mechanical task that can be done by a
computer. It can't. A computer has no idea _what terms need to be
indexed._ Computer-generated indices have a terrible tendency to
generate entries that have a list of fifty page references following
them, because the computer doesn't know which are the important ones,
and doesn't know how to replace a single entry term ("London, Jack" 20,
21, 22, 23, 25, 26, 27, 30, 31, 33, 34, 36...) with several narrower
terms ("London, Jack: paternity of, 20; infancy, 21; travels to Yukon,
23; breaks into print, 25; affair with Charmian, 30; ...)

I haven't tried to test this objectively, but my impression is that,
comparing Wikipedia/(current) Britannica 3/(classic) 1911 Britannica,

a) _if_ the subject you want _is_ treated in the encyclopedia,
b) _if_ you don't succeed in guessing the entry term correctly on your
first try, and
c) are forced to resort to search/Micropaedia/index,

you are _more_ likely to find what you're looking for in either
Britannica than in Wikipedia.

--
Daniel P. B. Smith, dpbsmith at verizon.net
"Elinor Goulding Smith's Great Big Messy Book" is now back in print!
Sample chapter at http://world.std.com/~dpbsmith/messy.html
Buy it at http://www.amazon.com/exec/obidos/ASIN/1403314063/


from_name: Thomas Gries

body:
I need help for getting the <charinsert> .... </charinsert> tags working
in my local Mediawiki.Copryrightwarning

What I did already

1. copied [1] to my local wiki page:Mediawiki:Copyrightwarning
2. copied [2] from CVS to /mywiki/extensions)
3. command inserted in LocalSettings.php: include
($IP."/extensions/CharInsert.php");

but I still cannot click onto one of the special characters.

Is there anyone who can assist me, please ?
T.

[1] http://en.wikipedia.org/wiki/Mediawiki:Copyrightwarning
[2]
http://cvs.sourceforge.net/viewcvs.py/wikipedia/extensions/CharInsert/CharInsert.php?rev=1.2&view=markup


subject: [Wikitech-l] Do we have server monitors for wikipedia machines?

body:
Rowan Collins wrote:
> As for being able to access some wikis and not others, I don't think
> the servers are divided like that, so I'd say it must have been either
> a) coincidence, b) some odd side-effect of different load on the
> actual databases or c) some transitory problem with the settings that
> meant some addresses were pointing to the wrong place or somesuch.

What that generally means is that one of the squids is offline. At the
moment this is happening with annoying frequency as we've had some
problems getting log rotation to work properly on the new machines.

Squid is brain-dead and will *crash* if its log file reaches 2 gigabytes
(which happens fairly frequently when you get our level of traffic).

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


from_name: NSK

subject: [WikiEN-l] article length: =<32Kb?

body:
On Sunday 27 February 2005 14:52, Viajero wrote:
> started contributing to WP, limiting article length to 32Kb was

I see no reason why somebody would want to limit an article to 32Kb.

--
NSK
http://portal.wikinerds.org


subject: [WikiEN-l] article length: =<32Kb?

body:
On Sunday 27 February 2005 18:33, Daniel Mayer wrote:
> issues editing articles over 32KB.

Why the whole article gets into a single field? You can use one field per
paragraph.

--
NSK
http://portal.wikinerds.org


from_name: Daniel Mayer

subject: [WikiEN-l] Edit link on first section

body:
--- zero 0000 <nought_0000 at yahoo.com> wrote:
> Yes, please oh please give us an Edit link on the first section.

The lead section is section 0, not section 1. Section 1 already has edit links.

-- mav

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


subject: [Foundation-l] Re: Day 1 Fund Drive Report

body:
--- Anthere <anthere9 at yahoo.com> wrote:
> It would be nice if a compendium is made at the end of the fund drive,
> with collection of many languages.
>
> We could host that on foundation wiki.

Yes - that would be neat. I'd also like to conduct a survey to see why people
donated, why they didn't, and what can be improved for the next fund drive.

-- mav

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


body:
dpbsmith at verizon.net wrote:

> 1) I'm not necessary challenging the 32K limit itself. I was urging
> that the message present 32K as a _soft_ limit, a guideline requiring
> _deliberate_ action. The old message sounds like a call to jump in and
> do something immediately.
>
> I've Been Bold and rewritten the message. It now reads:
>
> "Note: This page is 38 kilobytes long. Under current  article size
> guidelines, articles that exceed 32KB are considered to be too long.
> It may be appropriate to restructure this topic into a related series
> of shorter articles, or split off a section of it as a separate
> article. However, these are major structural changes which should not
> be made hastily, and should be made by consensus agreement among
> editors of the page. See the guidelines for details."

I just compared this with the existing message.  This one has 77 words
compared to 29 on the existing one.  Considering also that the first
seven words remain unchange this represents a revision that is more than
three times the old size.  If we are to encourage succinctness, brevity
here would serve as an excellent example. :-)

Ec


from_name: Rowan Collins

body:
On Sun, 27 Feb 2005 02:08:34 +0000, Jim Higson <jh at 333.org> wrote:
> Since I'm done hacking for today, thought I'd demo what I've been working
> on. I'll leave this up for a while:
>
> http://81.5.150.113/wysi/
>
> A lot of things are disabled for now, and the speed to first load can
> probably be improved by at least 80%, but it is presenting a dynamic
> interface without any server-side page generation. The parser is a more
> complete than the presenter, so I've dumped the parse trees to the bottom
> of the pages.
>
> Anyway, I should have edits and real-time previews working soon. For now
> this is mostly just an experiment to see what is possible. It's Mozilla
> only too, but there's no reason it couldn't be made to work in any browser
> that supports XMLHTTP. Especially interesting is viewing these pages
> generates virtually no server-side CPU load.
>
> (the normal interface is at http://81.5.150.113/wiki)
>
> Comments welcome :)

1) That rocks!

2) Perhaps you should add it to the list I just created at
http://meta.wikimedia.org/wiki/Alternative_parsers
I know yours is a lot more than just an alternative parser (so, in
fact, is the Eclipse plugin; maybe I named the page too specifically),
but once releasable it'll sure be interesting to people working on
their own hacks!

3) I've answered your questions about images (well, the first one
anyway) on the wiki page. :)

4) Happy hacking. ;)

--
Rowan Collins BSc
[IMSoP]


subject: [Wikitech-l] Testing if a page exists

body:
Brion Vibber wrote:
> Jim Higson wrote:
>> I've tried doing a HEAD request to the page url with &action=raw, but
>> that returns 200 regardless if the page exists (bug or feature?).
>
> You get a 200 because the wiki script exists, and hasn't yet been
> special cased to return a 404 response for pages which don't exist.

Just hacked this into HEAD branch:
http://mail.wikipedia.org/pipermail/mediawiki-cvs/2005-February/006720.html

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


body:
On Sat, 26 Feb 2005 13:32:43 -0600, Kiss All <kissall at gmail.com> wrote:
> Do we have server monitors for those machines? If not, I suggest to
> use some third party service to monitor the server's uptime and
> performance, like  http://www.siteuptime.com or
> http://www.elkmonitor.com/. I guess there are some free service
> provider available.

You might want to look at
http://meta.wikimedia.org/wiki/Wikimedia_servers and links therefrom;
there's also a load of stuff at
http://meta.wikimedia.org/wiki/Statistics In short, yes, there's all
sorts of monitoring going on to see which machines are doing what and
how well.

As for being able to access some wikis and not others, I don't think
the servers are divided like that, so I'd say it must have been either
a) coincidence, b) some odd side-effect of different load on the
actual databases or c) some transitory problem with the settings that
meant some addresses were pointing to the wrong place or somesuch.

--
Rowan Collins BSc
[IMSoP]


from_name: Jim Higson

subject: [Wikitech-l] Re: Re: Early preview of client-side wiki presentation

body:
Tels wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
>
> Moin,
>
> On Sunday 27 February 2005 14:00, Jim Higson wrote:
>> Tomer Chachamu wrote:
>> >> An Apache mod rewrite rule defers all request to the same html page.
>> >> This page is just a stub that kicks off the Javascript that fetches,
>> >> parses and presents the content. Wikiwyg can run on top of any
>> >> existing mediawiki without changes. All content is fetched using
>> >> XMLHTTP and a mix of action=raw and Special:Export. Links are
>> >> coloured red or blue a few seconds after they are first displayed,
>> >> because it takes a little time between parsing the link and getting
>> >> back a HEAD request to check if the article exists.
>> >
>> > Does this mean that we can use it to browse Wikipedia, with a few
>> > modifications? That would decrease server load, right?
>>
>> I've changed the main page from something silly to something that
>> explains this. Yes, it could be used on top of any mediawiki, alongside
>> the existing interface. Running two interfaces has issues though, we'd
>> have to try to replicate any bugs in the PHP parser to keep the thing
>> consistent.
>>
>> > It may not have template inclusion support and it displays masses of
>> > XML per page, but it's worth it. ;)
>>
>> Actually, I'm working on templates now. Templates are actually quite
>> easy, just another http request. The XML dump is just so I can see that
>> the parser is working fine, it won't be there when I'm done.
>
> All I see is an empty main page, with for differently-blue-colored
> rectangles with 3-pixel-wide borders. No matter what link I click, I get
> an JS alert "hello world" message box. The rectangles cannot be clicked.
>
> That is Forefoxc 1.0 on Linux, with a Privoxy as proxy in between. Any
> idea what I need to enable/disable to see it work? :)

I can't say for sure, but on my girlfriends's computer on our LAN Privoxy
didn't like XMLHTTP. Try adding my IP to your cache's exceptions list (I
won't spam you, honest :)

Also, I updated the site about 5 minutes ago, so you might have just hit it
while I was updating. A few things won't work, especially images for the
moment.

It still says hello world for some of the links, but clicking edit does
something now (not much but a start, I'm still working on parsing
fragments)

--
Jim


from_name: Walter Vermeir

subject: [Wikitech-l] Re: Apache rewrite rule missing

body:
Brion Vibber schreef:

>
> I've taken it out for the moment as a) like adding random domain names,
> it's a really bad idea to encourage a dependency on inherently unstable
> URLs, and b) there was an infinite looping problem.
>
> -- brion vibber (brion @ pobox.com)

In the 	printed and spread English and Dutch leaflets about Wikipedia
the url "http://wikimediafoundation.org/Fundraising" and
"http://wikimediafoundation.org/giften" is used.

I would be usefull if the work again.
--
[[w:nl:gebruiker:walter]]


from_name: Neil Harris

subject: [Wikipedia-l] Duplicate article

body:
Adam Hunt wrote:

> What is the policy on duplicate articles?  "U.S. customary units" and
> "Imperial unit" both cover the same topic.
>
> --adam
>
>
Note that there are some subtleties here, with different definitions of
some customary units on different sides of the Atlantic. And, in some
cases, multiple similarly named units on the same side of the Atlantic:
consider "international mile" and "survey mile". I wouldn't be too hasty
to merge the articles without doing detailed research on these
differences, and very careful reading of the existing articles.

-- Neil


body:
Ray Saintonge wrote:

> I too would like to put in a word for article length limits.  Whether
> 32K is still the optimal length would still be an open question;
> perhaps it could be increased a little.

Yes it would seem a coincidence that an optimal length for articles
happened to be the same as a technical restriction.

So what are the generally excepted criteria for length of articles in
encyclopedias?

Christiaan


from_name: JAY JG

subject: [WikiEN-l] Article on Wikipedia in the Saturday National Post

body:
There was a pretty complimentary article published about Wikipedia in the
Saturday National Post (a national Canadian newspaper).  Unfortunately, you
need a subscription to see the whole article online:

http://www.canada.com/search/story.html?id=df1fbe7e-c310-47c8-98af-ddd72928bc85

Jay.


subject: [WikiEN-l] POV forks, and "the 32K devil made me do it"

body:
Christiaan Briggs wrote:

> Ray Saintonge wrote:
>
>> I too would like to put in a word for article length limits.  Whether
>> 32K is still the optimal length would still be an open question;
>> perhaps it could be increased a little.
>
> Yes it would seem a coincidence that an optimal length for articles
> happened to be the same as a technical restriction.
>
> So what are the generally excepted criteria for length of articles in
> encyclopedias?

accepted that is. ;)


from_name: Tels

references:
<cvr9r0$m7m$1@sea.gmane.org>
	<9a878c440502270447692e2292@mail.gmail.com>
	<cvsg0q$pnp$1@sea.gmane.org>

body:
-----BEGIN PGP SIGNED MESSAGE-----

Moin,

On Sunday 27 February 2005 14:00, Jim Higson wrote:
> Tomer Chachamu wrote:
> >> An Apache mod rewrite rule defers all request to the same html page.
> >> This page is just a stub that kicks off the Javascript that fetches,
> >> parses and presents the content. Wikiwyg can run on top of any
> >> existing mediawiki without changes. All content is fetched using
> >> XMLHTTP and a mix of action=raw and Special:Export. Links are
> >> coloured red or blue a few seconds after they are first displayed,
> >> because it takes a little time between parsing the link and getting
> >> back a HEAD request to check if the article exists.
> >
> > Does this mean that we can use it to browse Wikipedia, with a few
> > modifications? That would decrease server load, right?
>
> I've changed the main page from something silly to something that
> explains this. Yes, it could be used on top of any mediawiki, alongside
> the existing interface. Running two interfaces has issues though, we'd
> have to try to replicate any bugs in the PHP parser to keep the thing
> consistent.
>
> > It may not have template inclusion support and it displays masses of
> > XML per page, but it's worth it. ;)
>
> Actually, I'm working on templates now. Templates are actually quite
> easy, just another http request. The XML dump is just so I can see that
> the parser is working fine, it won't be there when I'm done.

All I see is an empty main page, with for differently-blue-colored
rectangles with 3-pixel-wide borders. No matter what link I click, I get
an JS alert "hello world" message box. The rectangles cannot be clicked.

That is Forefoxc 1.0 on Linux, with a Privoxy as proxy in between. Any
idea what I need to enable/disable to see it work? :)

Best wishes,

Tels

- --
 Signed on Sun Feb 27 23:14:21 2005 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "It is true that some lawyers are dishonest, arrogant, greedy, venal,
 amoral, ruthless buckets of slime. On the other hand, it is unfair to
 judge the entire profession by a few hundred-thousand bad apples." --
 The Washington Post

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQEVAwUBQiJGj3cLPEOTuEwVAQG9oQf+Natbwplu5lRsLSmXFKjikVi5G2+oLCq+
xznY6nDVmPqv65bLRgXMwIIpHTjezximMOEhrvgwj4Y3hmIE4WYYZayJzpQnyPMa
AZJkzbWcWjhYERO8cPHeHbv6ckNz2CE6EyfkLEzwBgDYOu4Pyuc5OuRYNtZrKj+k
0YsjJaFZhmBH98oN9GxmZcdmVbYL/SaF6l5hSOntBa0ceaxiRcejmeDBOpb7JEcK
OK54ldM3gNpx+tSFbF7LgivAQ3wfOZHHK4HKhrz46ceq7cLWUjOHIeaYwoOyjyCq
BKv7hwBsze7os9tuTrwBM6xoNAo/uPm5K0W0xJKGE/Z/MptjMBuFxA==
=xlc9
-----END PGP SIGNATURE-----


from_name: Magnus Manske

subject: [Wikitech-l] Error 400 for de

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

I keep getting "Error 400" for the German wikipedia. One of about five
attempts goes through, though. Example at

http://de.wikipedia.org/wiki/Isenburg

which doesn't seem to work at all.

What's going on?

Magnus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCIkbICZKBJbEFcz0RAp9SAJ9nn4v0Quk8rvg0Cur9ZAY2tpGHvQCfWH2d
civ8fZX0Md4SRAGHweLvnUU=
=lbZa
-----END PGP SIGNATURE-----


from_name: Evan Prodromou

subject: [Wikipedia-l] Duplicate article

body:
On Sun, 2005-27-02 at 08:56 -0800, Adam Hunt wrote:

> What is the policy on duplicate articles?  "U.S. customary units" and
> "Imperial unit" both cover the same topic.

Official policy is that you should look at the history of the article
with the title you least prefer to find the person  who did the smallest
possible change (I like "it's" to "its" changes, myself). Then, you
write an ALL-CAPS HATE LETTER to them on their User talk: page, cursing
them vehemently for "vandalizing" Wikipedia and violating the NPOV rule.
If you can, threaten to have their ISP account deactivated and/or
physical violence. Mention of Nazis or Hitler is a finesse touch but not
required. Finally, look at their user contributions to find other
articles the user's worked on, and blank them.

An alternate approach is to merge the two articles and make one a
redirect to the other. But what fun is that?

~Evan

--
Evan Prodromou <evan at wikitravel.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20050227/b5fb8b86/attachment.pgp


from_name: Fred Bauder

subject: [WikiEN-l] Edit link on first section

body:
So give us a link on Section 0, let's catch up with Wikinfo.

Fred

> From: Daniel Mayer <maveric149 at yahoo.com>
> Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
> Date: Sun, 27 Feb 2005 20:23:03 -0800 (PST)
> To: English Wikipedia <wikien-l at Wikipedia.org>
> Subject: Re: [WikiEN-l] Edit link on first section
>
> --- zero 0000 <nought_0000 at yahoo.com> wrote:
>> Yes, please oh please give us an Edit link on the first section.
>
> The lead section is section 0, not section 1. Section 1 already has edit
> links.
>
>
> -- mav
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l


from_name: Anthere

subject:
[Wikitech-l] Re: User controlled suppression of potentially
	offensive content

body:
See also on the topic : http://meta.wikimedia.org/wiki/Offensive_content

Ant

Christiaan Briggs a ?crit:
> Hi everyone, recently, in various forums throughout Wikimedia, there has
> been much discussion about the appropriateness of certain content on
> Wikipedia, particularly sexually and medically explicit photos.
>
> There has been some agreement that, rather than participate in
> self-censorship, this problem could be dealt with at a technical level
> by allowing downstream users of Wikimedia projects to control for
> themselves if such content is removed, hidden (linked) or shown by default.
>
> Your technical expertise on how this might be implemented is more than
> welcome:
> http://meta.wikimedia.org/wiki/Talk:End-user_content_suppression
>
> Cheers,
> Christiaan


body:
Ray Saintonge wrote:

> I too would like to put in a word for article length limits.  Whether
> 32K is still the optimal length would still be an open question; perhaps
> it could be increased a little.

I don't see a need. Here are two Featured Articles I've worked heavily on
that are at almost 32KB:

     http://en.wikipedia.org/wiki/Xenu
     http://en.wikipedia.org/wiki/X_Window_System

(The second of those has a long section that's actually been split to a
separate article (one which needs a lot of work but will probably end up
longer than 32KB itself with several subarticles).

I really can't imagine either being longer and being of that much use as
a general article. Really. By the end of several thousand words of dense
text, your eyes are going to be falling out.

There are exceptions (172 successfully argued that [[History of Russia]]
was difficult to meaningfully summarise without going well over it), but
32KB is a fortuitous technical limit that makes a very good editorial
limit in my experience.

- d.


from_name: Mark Williamson

subject: [Wikipedia-l] Duplicate article

body:
You can't forget to accuse them of plagiarism of your most recent
best-selling novel, and threaten to sue.

It also helps to send them a Wikipedia e-mail (or a few, or several
hundred) reminding them what's wrong with them, exactly how stupid
they are (be sure to use similes and comparisons, they make for more
captivating e-mails; also don't forget the mandatory "if I had a
dollar for every brain you didn't have, I'd have one dollar"), how you
have engaged in sexual relations with their mother/sister/girlfriend
(be sure to describe these encounters in great detail - it will keep
the reader focused on the topic at hand), how many different ways you
are going to cause bodily harm to them and/or their loved ones (be
very graphic - it helps to drive your point home), remind them how
small their manhood is (again, use similes and comparisons... and when
they tell you they're a woman, say "my point exactly!"), rinse, and
repeat.

Mark

On Sun, 27 Feb 2005 23:59:28 -0500, Evan Prodromou <evan at wikitravel.org> wrote:
> On Sun, 2005-27-02 at 08:56 -0800, Adam Hunt wrote:
>
> > What is the policy on duplicate articles?  "U.S. customary units" and
> > "Imperial unit" both cover the same topic.
>
> Official policy is that you should look at the history of the article
> with the title you least prefer to find the person  who did the smallest
> possible change (I like "it's" to "its" changes, myself). Then, you
> write an ALL-CAPS HATE LETTER to them on their User talk: page, cursing
> them vehemently for "vandalizing" Wikipedia and violating the NPOV rule.
> If you can, threaten to have their ISP account deactivated and/or
> physical violence. Mention of Nazis or Hitler is a finesse touch but not
> required. Finally, look at their user contributions to find other
> articles the user's worked on, and blank them.
>
> An alternate approach is to merge the two articles and make one a
> redirect to the other. But what fun is that?
>
> ~Evan
>
> --
> Evan Prodromou <evan at wikitravel.org>
>
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>
>
>
>


subject: [Wikitech-l] Re: Spam

body:
Yann, an email was opened on otrs to deal with emails of requests from
non editors.

If I remember well, this address is info-fr at wikimedia.org

This is possibly the email address which should be better advertised on
the french speaking projects.

I recommand that any big projects with high spam amount and requests
from non registered people begin to think of using otrs and a special
information list as well.

Anthere

Yann Forget a ?crit:
> Hi,
>
> Le Tuesday 22 February 2005 16:01, David Gerard a ?crit :
>
>>Brion Vibber (brion at pobox.com) [050223 01:01]:
>>
>>>The lists are restricted to registered users only, but we hold other
>>>mails in the moderation queue rather than discarding them outright.
>>>This means a lot of spam gets in the moderation queue, which nobody ever
>>>sees except the list admins. I keep hearing a rumor that we've set up
>>>SpamAssassin but I guess it hasn't really gotten done.
>>
>
> No, it was never done, inspite of several propositions to do so.
> I offered several times to help setting this, and I do it again today.
>
>
>>There's a LOT of spam in the moderation queue, but it does no harm sitting
>>there (unless the mail server is about to fall over with the weight of it).
>
>
> The amount of spams has become so much that managing a list is now a burden.
> So yes, it does harm, because it wastes my time as list administrator.
> I am sure I am not alone in this case.
>
>
>>The main reason to check the queues at all is just in case there's a
>>message from a human to allow through.
>
>
> Every day, there are valuable mails from people who are not subscribers,
> so the cleaning of spams has to be done daily.
>
> For a basic spam filter, we don't even need to install Spamassassin.
> Just filtering out non existing domains and virus will remove a lot of
> unwanted traffic.
>
>
>>- d.
>
>
> Regards,
> Yann


body:
Brion Vibber schrieb:

> TG wrote:
>
>> I need help for getting the <charinsert> .... </charinsert> tags working
>>
>> What I did
>> 1. copied [1] to my local wiki page:Mediawiki:Copyrightwarning
>> 2. copied [2] from CVS to /mywiki/extensions)
>> 3. command inserted into last code line of LocalSettings.php: include
>> ($IP."/extensions/CharInsert.php");
>

>> but I still cannot click onto one of the special characters.
>
> Are they not there?

The <charinsert> tags are not translated to javascriptlets on a  page X:
The HTML of a page X action=edit shows _still_ the <charinsert> ...
</charinsert> tags.

But the HTML of and the rendered page Mediawiki:Copyrightwarning show
the <a href="javascript:insertTag()"....>... </a> scriptlets

mediawiki version 1.3.11
Did I overlook something ?
Why aren't they replaced by the javascript ?

Brion: please take note, that I only included the CharInsert.php as
Magnus told me - see step 3 above. I am puzzled, why there isn't a call
to it, is this the problem ?


from_name: Stephen Forrest

body:
On Mon, 28 Feb 2005 12:39:56 +0600, Arno M <redgum46 at lycos.com> wrote:
> I don't know if it is the same as this one, but you can read this without
> a subscription:
>
> http://www.thetyee.ca/MediaCheck/current/JourFutureWikipedia.htm

Er, that's not the same: that one's four months old, and it's not from
Canwest Global.

I must say I'm somewhat surprised at the relative lack of coverage
Wikipedia has gotten in Canadian media.  However, it's cited regularly
as source material by CBC (Canada's national news service) online
edition, and seems to have gotten some isolated mention in
Radio-Canada (CBC's French-language equivalent).  I would guess that
the other major papers will feel compelled to say something now that
the Post has featured it fairly prominently.

Steve


from_name: Michael Snow

subject: [WikiEN-l] Abbreviated Signpost issue, new shortcut

body:
Due to the power outage and the fact that I was traveling for most of
the weekend, I haven't been able to write as many articles, so this
week's edition of The Wikipedia Signpost is a little bit smaller than usual.

Also, a new feature has been added in the form of a handy shortcut. You
can now get to The Signpost quickly via [[WP:SIGN]].

--Michael Snow


from_name: Adam Bishop

body:
Whoops, I seem to have sent this to Stephen rather than to the list -
anyway, the other day I posted some stuff to [[Wikipedia:Press coverage]],
the Sun Media papers have made relatively frequent mention of Wikipedia in
2004 and already a few times this year.

Adam Bishop

>From: Stephen Forrest <stephen.forrest at gmail.com>
>Reply-To: Stephen Forrest <stephen.forrest at gmail.com>,English
Wikipedia <wikien-l at Wikipedia.org>
>To: English Wikipedia <wikien-l at wikipedia.org>
>Subject: Re: [WikiEN-l] Article on Wikipedia in the Saturday National
Post
>Date: Mon, 28 Feb 2005 01:59:38 -0500
>
>On Mon, 28 Feb 2005 12:39:56 +0600, Arno M <redgum46 at lycos.com>
wrote:
> > I don't know if it is the same as this one, but you can read this
without
> > a subscription:
> >
> > http://www.thetyee.ca/MediaCheck/current/JourFutureWikipedia.htm
>
>Er, that's not the same: that one's four months old, and it's not from
>Canwest Global.
>
>I must say I'm somewhat surprised at the relative lack of coverage
>Wikipedia has gotten in Canadian media.  However, it's cited regularly
>as source material by CBC (Canada's national news service) online
>edition, and seems to have gotten some isolated mention in
>Radio-Canada (CBC's French-language equivalent).  I would guess that
>the other major papers will feel compelled to say something now that
>the Post has featured it fairly prominently.
>
>Steve
>_______________________________________________
>WikiEN-l mailing list
>WikiEN-l at Wikipedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikien-l


subject: [Wikitech-l] Re: Paying wikimedia sysops (not developers)

body:
George Stepanek a ?crit:
> Given the recent recovery of the database, and the work to fix the performance
> problems experienced earlier this year, it may be time to think again about the
> issue of rewarding WikiMedia developers for their oustanding efforts on our
> behalf. Their achievements are considerable. I don't believe that anyone has
> ever before run such a popular website on so small a budget. They have been able
> to scale a rough-and-ready technology to accommodate phenomenal growth.
>
> I have read the ongoing discussions about the subject. The idea of bounties for
> specific projects has been mooted, but has not taken off. Part of the problem is
> that there appears to be considerable confusion as to what it is the developers
> actually do. Their most critical work is not actually development at all; it is
> keeping the system running smoothly.
>
> Software development is quite a creative and rewarding activity. The MediaWiki
> codebase is reasonably well documented, and it is actually quite accessible. It
> would not be hard to find new people to fix bugs and develop new features. But
> given the maturity of the software, there is not much that really needs to be
> improved.
>
> System operations, on the other hand, is an exhausting, frustrating and largely
> thankless activity. It relies on a few key individuals who have deep familiarity
> and expertise with the current setup. When things go wrong, the pressure on
> these people becomes enormous.
>
> I propose paying a bonus to those developers who make substantial contributions
> towards the running the of system. Someone who works 40 or more hours over the
> course of a week would receive $400 (US) for their efforts. Someone who works at
> least 20 hours would receive $200.
>
> Is this a fair recompense? No. It is way below market rate. But it might help
> out a student who would otherwise have to wait tables to make ends meet. And it
> would be a nice "thank you" to anyone else: it could pay for a mini-break, or a
> night on the town.
>
> What do you think?
>
> George Stepanek

Hi, your title is a bit confusing, as in Wikipedia, sysops are usually
not system operator...

But well, I understand what you mean.

I am not sure you have been informed that since january, the foundation
has decided to pay a bit two people.

One person (Chad) is paid since early january, one day a week, to help
with the servers themselves.
Brion should now been part time (though paper work has not been done
yet...) to help on various issues.

I think what you propose makes sense, but it may be also controversial.
As with many topics, the best thing is to move slowly, to insure
decisions taken will not upset editors nor tip a balance.
There is also the question of who to pay, how long, how much, how to
measure quality of work provided...

Also, it is important to note that our ressources are quite fragile, and
that paying people will increase our financial needs a lot.

And finally, there is an important point to consider.

It is why so many people here work for free.

They do because it is fun. They do because they are with others, they do
not have a boss telling them what they should do; they can do whatever
they feel like, and when they feel like. They can be away for 2 months
if there is need. And they can oppose what they do not like.

This freedom is very important. So, while I know very well some people
need money and while it would be nice that some people have only one job
rather than 2 at the same time, it is important to be slow in any
decision to pay people.

I'd say, essentially, we should right now listen to people reaction,
thoughts and proposals. Not straight take the decision to give 400
dollars to anyone working 40 hours a week on wikimedia servers :-)

ant


from_name: Pedro Fayolle

subject:
[Wikitech-l] Re: Re: Early preview of client-side wiki
	presentation

references:
<cvr9r0$m7m$1@sea.gmane.org>
	<9a878c440502270447692e2292@mail.gmail.com>
	<cvsg0q$pnp$1@sea.gmane.org> <200502272315.44831@bloodgate.com>
	<cvth05$jkb$1@sea.gmane.org>

body:
Very very impressive! Once again, this is just like what I had planned
to do, only better :) Congratulations on your hard work!

Just a question. I don't see what the benefit is from using a
parser+presentator model when you could just convert wiki markup
directly into HTML. On a more generic project it would likely fit, but
since you're running your code on a browser which uses HTML anyway,
what's the gain? Isn't it just slowing it down?

Can't wait to see what's next. It all looks awesome so far.

Best wishes,

Pedro

On Sun, 27 Feb 2005 22:23:10 +0000, Jim Higson <jh at 333.org> wrote:
> Tels wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> >
> > Moin,
> >
> > On Sunday 27 February 2005 14:00, Jim Higson wrote:
> >> Tomer Chachamu wrote:
> >> >> An Apache mod rewrite rule defers all request to the same html page.
> >> >> This page is just a stub that kicks off the Javascript that fetches,
> >> >> parses and presents the content. Wikiwyg can run on top of any
> >> >> existing mediawiki without changes. All content is fetched using
> >> >> XMLHTTP and a mix of action=raw and Special:Export. Links are
> >> >> coloured red or blue a few seconds after they are first displayed,
> >> >> because it takes a little time between parsing the link and getting
> >> >> back a HEAD request to check if the article exists.
> >> >
> >> > Does this mean that we can use it to browse Wikipedia, with a few
> >> > modifications? That would decrease server load, right?
> >>
> >> I've changed the main page from something silly to something that
> >> explains this. Yes, it could be used on top of any mediawiki, alongside
> >> the existing interface. Running two interfaces has issues though, we'd
> >> have to try to replicate any bugs in the PHP parser to keep the thing
> >> consistent.
> >>
> >> > It may not have template inclusion support and it displays masses of
> >> > XML per page, but it's worth it. ;)
> >>
> >> Actually, I'm working on templates now. Templates are actually quite
> >> easy, just another http request. The XML dump is just so I can see that
> >> the parser is working fine, it won't be there when I'm done.
> >
> > All I see is an empty main page, with for differently-blue-colored
> > rectangles with 3-pixel-wide borders. No matter what link I click, I get
> > an JS alert "hello world" message box. The rectangles cannot be clicked.
> >
> > That is Forefoxc 1.0 on Linux, with a Privoxy as proxy in between. Any
> > idea what I need to enable/disable to see it work? :)
>
> I can't say for sure, but on my girlfriends's computer on our LAN Privoxy
> didn't like XMLHTTP. Try adding my IP to your cache's exceptions list (I
> won't spam you, honest :)
>
> Also, I updated the site about 5 minutes ago, so you might have just hit it
> while I was updating. A few things won't work, especially images for the
> moment.
>
> It still says hello world for some of the links, but clicking edit does
> something now (not much but a start, I'm still working on parsing
> fragments)
>
> --
> Jim
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


subject: [WikiEN-l] Re: Desysoping

body:
HI sorry to answer so late, but I was away for the week, and I think I
needed to add a very important point to your answer Karl.

Karl A. Krueger a ?crit:
> On Sat, Feb 19, 2005 at 12:51:46PM +0100, Anthere wrote:

>>There is an easy way to do this : have it a requirement that listing the
>>person on the admin/deadmin list be made  by a sysop himself.
>
>
> There is a model wherein privileges are conferred upon persons in
> recognition of innate virtues, and it is presumed that whatever these
> persons care to do with those privileges, they will do so in ways
> conformant to those innate virtues.  The commoners are not deemed
> competent to judge the privileged:  only a peer can judge a peer.  This
> is called aristocracy.

This is not why I proposed it.
The real (unfortunate truth) is that if anyone is allowed to begin a
request for desysoping a person, there will be a real mess as in
particular trolls will rush start such pages.
So, when I suggest that only sysops be allowed to do this, I rather rely
on the fact that if a complaint seems reasonable, there will always be a
sysop to support it and open a page for comment.

Maybe I am being too optimistic on this... :-)
But generally, when someone shows me a sysop did something weird, I am
the first one to potentially support the complainer.

But well, something similar could be obtained I supposed by accepting a
request as potentially valid as soon as at least 3 people approved it.
Now, I fear that 3 trolls could unite...

So, the only thing that really happen is that in spite of abuse
sometimes, desysoping is rarely done at all.

> There is another model where responsibilities and the powers to carry
> them out are conferred upon persons deemed likely to do so correctly,
> but wherein those persons' actions are always subject to review.  The
> people are (collectively) deemed competent to judge those thus
> empowered, and to remove them from office by due process of recall or
> simply by not re-electing them.  This is called republicanism.
>

This is called the arbitration committee :-)

Ant

PS : by the way, about a year ago, I proposed a process on meta about
sysops. First, an inactive sysop is removed from sysop list. Second, any
sysop must be confirmed every year.
This process was accepted and is currently working.


from_name: Brion Vibber

subject: [Wikitech-l] PNG thumbnail image sizes

body:
Jim Higson wrote:
> The thumbnail has only about 6% the pixels of the original, but is still 88%
> as large. It'd be faster to just have the original.

See:
http://bugzilla.wikipedia.org/show_bug.cgi?id=1218

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


from_name: Thomas Gries

body:
Brion Vibber schrieb:

> In MediaWiki 1.3, the copyrightwarning message is raw HTML, so no
> interpretation of wikitext (such as extensions) will occur. I wrote the
> CharInsert extension to continue to provide the insert capability when
> it was switched from raw HTML to wikitext in 1.4.

Brion, I could quickly check it with CVS HEAD 1.5: it works very well
with 1.5, too. Thanks for your help.
Tom


subject: [WikiEN-l] Re: Censorship, really?

body:
Hmmmm, so do I.

Ant

Arno M a ?crit:
> I'll risk choking up your e-mail accounts to say that I agree with Oneguy here.
>
>
> ----- Original Message -----
> From: OneGuy <oneguyks at gmail.com>
> To: "English Wikipedia" <wikien-l at wikipedia.org>
> Subject: [WikiEN-l] Censorship, really?
> Date: Sat, 19 Feb 2005 00:12:52 -0600
>
>
>>Someone wrote:
>>
>><something about censorship>
>>
>>Every newspaper/encyclopedia/media has some kind of editorial policy.
>>This is not the same thing as "censorship."  A newspaper puts all the
>>sports stories in one section, all the local news in another, and
>>keeps the classified ads separately from the news and editorials.
>>Censorship means trying to disallow expression of certain views in all
>>media, but we are not trying to remove the picture from everywhere on
>>the internet. You are free to post that picture on your web site if
>>you want. We won't campaign to get it deleted from your web site.
>>Having an editorial policy on graphic pictures is not "censorship."
>>That has to be the most absurd claim posted yet. Should we have no
>>editorial policy and no limits? Should we allow trolls to upload child
>>porn as an excuse to "illustrates" the child porn article? How about
>>allowing trolls to upload bestiality, anal sex, coprophilia,
>>urolagnia, necrophilia, and rape porn to illustrate those articles?
>>That's clearly absurd. There should be clear editorial policy on
>>graphic pictures. If not, and if every troll is allowed to upload all
>>kinds of graphic pictures as an excuse to "illustrate" articles,
>>Wikipedia would get blocked by all child protection software, some
>>ISPs, and all countries where porn is illegal. That's clearly harmful
>>to Wikipedia, and it opens the door to trolls to disrupt Wikipedia by
>>uploading even more extreme and graphic porn,  and then cry
>>"censorship" when it is removed.
>>
>>OneGuy
>>(Sorry, couldn't resist responding when I read some preposterous claim
>>about "censorship" on the archive).
>>_______________________________________________
>>WikiEN-l mailing list
>>WikiEN-l at Wikipedia.org
>>http://mail.wikipedia.org/mailman/listinfo/wikien-l
>
>


subject: [Wikitech-l] Length of searchwords

body:
Philipp wrote:
> Even after researching I couldn't find settings for varying systemside search
> criteria (lists of stopwords or the mentioned length problem). Where do I have
> to look?

http://dev.mysql.com/doc/mysql/en/fulltext-fine-tuning.html

If you are using MySQL 3.x, you may also have to tweak $wgDBminWordLen
and the copy of the stopword list in FulltextStoplist.php.

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


body:
It would be nice if a compendium is made at the end of the fund drive,
with collection of many languages.

We could host that on foundation wiki.

Could editors from various languages isolate the best quotes ?

Anthere

notafish a ?crit:
> Little international addition to the interesting quotes ;-)
>
> No des pescado: ense?a a pescar. by Alberto Gaona
> "Don't give fish, teach how to fish."
>
> Bravo ? cette formidable initiative pour d?mocratiser la connaissance
> ! by Guillaume Lasnier
> "Bravo to this wonderful initiative destined to democratize knowledge!"
>
> Wissen ist die Waffe der Gewaltlosigkeit. by Arnim Faryn
> "Knowledge is the weapon of non-violence."
>
> and my favorite ones ;-)
>
> Bon j'irais pas au restau aujourd'hui ;o). by Fabrice Terrasson
> "Ok, I won't go to the restaurant today ;o)"
>
>
> Is there really a 200 character max? really? really? really? really?
> really? really? really? really? really? really? really? really?
> really? really? really? really? really? really? really? really? ok by
> anonymous.
>
>
> On Sat, 19 Feb 2005 01:43:46 -0800 (PST), Daniel Mayer
> <maveric149 at yahoo.com> wrote:
>
>>On Day 1 (Friday eastern US timezone since PayPal data are not available in
>>UTC) we made $9,939.47 (USD equivalent) through a combination of PayPal and
>>MoneyBookers.
>>
>>PayPal breakdown:
>>AUD   314.03 (247.27 USD)
>>CAD   334.40 (271.58 USD)
>>EUR  3413.75 (4464.75 USD)
>>GBP   475.17 (899.77 USD)
>>JPY  28340   (269 USD)
>>USD   3424.63
>>Total 9576.78 (USD equivalent)
>>
>>Moneybookers:
>>$362.69 (USD equivalent)
>>
>>For the most recent grand total and other details visit
>>http://wikimediafoundation.org/wiki/Fund_drives/2005/Q1
>>
>>Some selected comments from Day 1:
>>See http://wikimediafoundation.org/wiki/Fund_drives/2005/Q1/Day_1
>>
>>"Knowledge isn't a possession - it cannot be monopolized." by Robert K Bell
>>
>>"You guys rock!!" by Anonymous
>>
>>"Fantastic system - best of luck from a Random Page addict" " by Steve Agland
>>
>>"Wikipedia is Hope" by Anonymous
>>
>>"Ignorance breeds fear, use information to gain knowledge and empower yourself
>>with Peace" by Anonymous
>>
>>"Wikipedia is a splendid way of sharing information. Lets do this!" by
>>Anonymous
>>
>>"You guys do a fantastic job!!!" by Guoming Sun
>>
>>"You have helped me in college and in life. I don't have much money, and I've
>>never given a donation. But if any cause is worthy, it is your own. Thank you"
>>by Ryan Lewis
>>
>>"Wikipedia, is there anything it can't do?" by Anonymous
>>
>>"If you read this note, donate!" by Anonymous
>>
>>"It's Not Much But Every Individual's Contribution Counts! What The Wiki Is All
>>About!" by Anonymous
>>
>>And my personal favorites:
>>
>>"For not deleting at least some articles" by Vladimir Mozhenkov
>>
>>"Wikipedia: Destroyer of productivity; love of my life." by Anonymous
>>
>>"bonk" by Anonymous
>>
>


subject: [Wikitech-l] Automatic timezone selection

body:
http://bugzilla.wikipedia.org/show_bug.cgi?id=505
See also http://meta.wikimedia.org/wiki/Automatic_timezone_selection -
for comments

In four weeks, most of the US states and also European countries will
change to daylight saving time ("Sommerzeit") --> timezone offset of
many users need to be adapted individually.

What I proposed within this enhancement report was, to switch timezones
automatically according to the affected countries (for users who have
opted-in such a new method).
T.


from_name: dpbsmith at verizon.net

subject: [WikiEN-l] Article size considerations

body:
All of this needs to be taken to Wikipedia_talk:Article_size and Wikipedia:Article_size and MediaWiki_talk:Longpagewarning, where I and some others are Being Bold (and the warning message is consequently in a state of flux...) To summarize what I believe to be true:

The _only_ reason for a _firm_ bright-line limit of 32KB was a technical limitation in some now-seldom-used browsers. Because of the advent of section editing, even users of these browsers can do _almost_ anything needed, and updated versions of these browsers are available. Thus, there is consensus that article size is now limited _only_ by considerations of page-loading speed, ease of navigation, issues of style and organization and preference, etc. There is no longer any urgent need to take action just because an article is 36KB.

The actual wording of the warning is still being wordsmithed. There's general agreement that it should be softened--no more "Danger! Danger! 32769 bytes! Aaaah-ooo-gah! Aaaah-ooo-gah! Split! Split!" People are struggling to find something concise that says everything people think needs to be said.

I've invented some hopefully-non-controversial uh, policy at Wikipedia:Article_size. Rather than repeat it here, I invite people to read it there and discuss in Talk.


from_name: Jim Higson

subject:
[Wikitech-l] Re: Re: Re: Early preview of client-side wiki
	presentation

body:
Pedro Fayolle wrote:

> Very very impressive! Once again, this is just like what I had planned
> to do, only better :) Congratulations on your hard work!
>
> Just a question. I don't see what the benefit is from using a
> parser+presentator model when you could just convert wiki markup
> directly into HTML. On a more generic project it would likely fit, but
> since you're running your code on a browser which uses HTML anyway,
> what's the gain? Isn't it just slowing it down?

Just generally easier to write and debug because the HTML representation is
lossy. The presentation layer takes only about a tenth the time of the
parser anyway. The article never actually exists as text XML, just an
in-memory DOM tree, it is faster than you'd think. It might even be faster
this way because I can throw bits of the parse tree about witout worrying
about presentation.

Programs are mostly easier to write with seperation of roles, there's a good
article on this here:

http://www.faqs.org/docs/artu/ch01s06.html#id2877537

> Can't wait to see what's next. It all looks awesome so far.
>
> Best wishes,
>
> Pedro


subject: [Wikitech-l] PNG thumbnail image sizes

body:
I've just noticed that this thumbnail:

http://81.5.150.113/wiki/images/thumb/180px-Diagram2copy.png

and original:

http://81.5.150.113/wiki/images/Diagram2copy.png

The thumbnail has only about 6% the pixels of the original, but is still 88%
as large. It'd be faster to just have the original.

Mediawiki seems to have a problem with PNG thumbnails - it generates 24bpp
ones even the original image was indexed.

Jim


from_name: Ben Brockert

body:
On Sunday, February 27, 2005, at 10:01  PM, Brion Vibber wrote:
> Squid is brain-dead and will *crash* if its log file reaches 2
> gigabytes
> (which happens fairly frequently when you get our level of traffic).

Are the logs mission critical?

Ben


from_name: Yann Forget

subject: [Wikitech-l] Re: Spam

body:
Hi Anthere,

Le Monday 28 February 2005 01:34, Anthere a ?crit :
> Yann, an email was opened on otrs to deal with emails of requests from
> non editors.
>
> If I remember well, this address is info-fr at wikimedia.org
>
> This is possibly the email address which should be better advertised on
> the french speaking projects.

1.?This has nothing to do with the current subject.
Or better, we CAN'T?start to advertise such an address before setting up a
spamfilter.
2.?I still don't know how OTRS?works, and was not able to find any help.
Anybody knows ?
So once a spamfilter is set up and there are sufficient people registered to
OTRS and knowing how to use it, we can advertise such an address.

> I recommand that any big projects with high spam amount and requests
> from non registered people begin to think of using otrs and a special
> information list as well.
>
> Anthere

Yann

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


from_name: Philipp

subject: [Wikitech-l] Length of searchwords

body:
Hello,

it appears to me that in the default settings searchwords with a length of up to
three letters are disregarded. This is obviously useful to rule out a lot of
everyday words one doesn't want to search for anyway (me, it, he, she, and,
you, not, ...).

On the other hand this also rules out all TLAs (three letter abbreviations)
which turns out as a major drawback in a development field (WAP, ANT, ...) and
users continue complaining about not finding relevant articles. (Mediawiki here
is used as an IT development intranet.)

Even after researching I couldn't find settings for varying systemside search
criteria (lists of stopwords or the mentioned length problem). Where do I have
to look?

Thanks
Philipp