from_name: Brion Vibber

subject: [Wikitech-l] ParserFunctions trial

body:
Gerard Meijssen wrote:
> The argument does not fall on its face; it only proves again that
> MediaWiki is hard, arguably impossible for many, to use for languages
> that are not left to right.

In other words: the argument *does* fall on its face, but we can make a totally
different argument: that it would be nice to support RTL better.

Yes, it would be nice to support RTL better.

However that has nothing to do with banning a construct that has THE EXACT SAME
ISSUES AS THE TEMPLATES IT WOULD REPLACE.

-- brion vibber (brion @ pobox.com)

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


list: foundation-l

source: pipermail-mbox

from_name: Dariusz Siedlecki

subject: [Foundation-l] WMFrance: new Board

body:
Congratulation to all new and re-elected members, and hope both of our
chapters will have the possibilities to co-operate in the future on
various projects :).

Best of luck, everyone!

On 4/12/06, Anthere <Anthere9 at yahoo.com> wrote:
> Hi
>
> David Monniaux being known as Submarine.
>
> Ant
>
> Jastrow wrote:
> > Hi all,
> >
> > Wikim?dia France just got its new Board.
> >
> > * Nicolas Weeger (Ryo), chairman,
> > * Marie-Lan Nguyen (Jastrow, that's me), secretary,
> > * Delphine M?nard (notafish), treasurer,
> > * Florence Devouard (Anthere),
> > * Mathieu Amo (Solensean),
> > * Fr?d?ric Thuillier (Fred-th),
> > * David Monniaux,
> > * Jean-Baptiste Soufron (Soufron),
> > * Emmanuel Engelhart (Kelson).
> >
> > Cheers,
> >

--
Pozdrawiam,
Dariusz Siedlecki


list: wikimedia-l

subject: [Foundation-l] WMFrance: new Board


list: wikipedia-l

from_name: Mark Williamson

subject: [Wikipedia-l] Europanto

body:
Exactly. And no rules means it's not a real language.

Mark

On 13/04/06, europanto <europanto at gmail.com> wrote:
>
>
> Don't you see that it is precisely one of the point that pleases
> europantists : no "rules" and good sounding sentences.
> I would say : "Tengo een amerikanische friend" or "An amigo am?ricain hebe
> Ich".
> Worse than unpure code-switching : sometimes, you even transform or invent
> words ( you qualified that "heavy". )
> I particularly like to use verb+"ando". For example : spielando ( playing ).
> And ... guess what "avioplano" stands for in one of Diego Marani's text ?
>
> Anyway, as I said before, I won't kill myself if there's no Europanto
> Wikipedia.
> I didn't ask for one and that will probably save me a lot of time.
>
> Well, that will be my last words here, I think.
>
> Bye
>
> Ms smh
>
> --
> View this message in context: http://www.nabble.com/Europanto-t1056989.html#a3902686
> Sent from the Wikipedia General forum at Nabble.com.
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>

--
"Take away their language, destroy their souls." -- Joseph Stalin


list: wikien-l

from_name: James D. Forrester

subject: [WikiEN-l] Application of the {{pd-art}} tag

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

Ray Saintonge wrote:

> My apologies for not being familiar with Ms. Emin.

Don't be upset. Be thankful. ;-)

> The way I would read "irrespective of artistic quality" it is to protect
> even bad artists. This allows the drawings of a 3-year old to be
> protected, and prevents the argument that something is not good enough
> to be protected.

That, certainly, is the way I wish it to be read. Wishes don't make
fact, though.

> An interesting case would be over copyrights on the paintings by the
> elephants in the San Diego Zoo. Would an elephant be capable of
> exercising artistic craftsmanship?

I'd imagine that the animals would be treated in much the same way as
minors would be (except that they would never "grow up" to take over
ownership), and the creations would be considered as the creations of
the responsible adults (keepers? owners?).

> The fact that the Bridgeman v. Corel situation has not been ironed out
> in Britain cannot be taken as support for either side of the argument.
> Subsection 4(c) at first strikes me as a redundancy unless it can be
> taken to apply prospectively to other formats that are not specified in
> (a) or (b).  I think that any photograph that we may be considering
> would pass the test in section 4, but it must still pass the originality
> test specified in paragraph 1(1)(a).

Possibly.

> BTW does this copy of the Act include amendments since 1988?  I see that
> it still shows copyright duration as being life + 50.  Why have I
> misunderstood that it would be life + 70?

The Patents Office has a "consolidated" 252-page PDF of the Act and all
of the subsequent modifications[0], which lists 37(!) Acts and Statutory
Instruments which have modified it, including the "Duration of Copyright
and Rights in Performances Regulations 1995, SI 1995/3297", which did
indeed modify the Act from 50 to 70 years after death for artistic works
(sound recordings are still at 50, though, which is why Elvis's back
catalogue is rapidly entering the public domain.

> In any event given the fuss that the museums of Britain have been making
> over this issue, it is amazing that there would be no British court
> decision on this.

Not really; it would be quite astoundingly bad press to be seen to be
"stealing" from a museum (remembering that essentially all museums are
charities, open to the public for free[1], and that the British press
love nothing better than to savage the party seen to be attacking the
"underdog", which any charity would surely be). Also, we British aren't
as litigious as our cousins, which "helps".

> It would, of course, be up to them to initiate any infringement
> proceedings. In the absence of such proceedings they have an infinite
> capacity to roar like paper tigers for as long as people are willing to
> take that roar seriously.

Agreed, up to a point.

> Unfortunately, as Wikipedia gets bigger it becomes less courageous in
> taking on these ruffians, because it has assets that it could lose.

Now that the Wikimedia Foundation exists, its Board has a legal duty to
avoid any action that might result in harm to its long term ability to
exist, of course.

> It would be helpful to have a litigation-proofed organization that
> operates at arms length to Wikipedia, and that could openly inspire the
> museums into taking legal action.

We've had the same concerns in starting Wikimedia UK; though we'd love
to see some case law in our favour, we really can't be the ones involved
in the case.

[0] - http://www.patent.gov.uk/copy/legislation/legislation.pdf
[1] - Free at the point of use; funded through both taxes and donations.

Yours,
- --
James D. Forrester
Wikimedia : [[W:en:User:Jdforrester|James F.]]
E-Mail    : james at jdforrester.org
IM (MSN)  : jamesdforrester at hotmail.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEPj0zd7WnstdBQBkRAlAvAJ927SQ51kY+guOm0Bs8gJtt2Y6X4ACeOrY2
6RqaSjXpjjYi2CNO6HL4hTw=
=A4yY
-----END PGP SIGNATURE-----


from_name: Matt Brown

subject: [WikiEN-l] Socialist POV

body:
On 4/13/06, Fred Bauder <fredbaud at ctelco.net> wrote:
> Dismissing him out of hand is inappropriate without looking at the
> edits. There is plenty of POV editing on the other side too. I'm
> going to answer him too, but after I look at some sample edits.

Granted, but Sam's positioning of himself as the crusader of
neutrality against the armies of bias is rather laughable.

-Matt


from_name: David Gerard

subject: [WikiEN-l] How Wikipedia deals with hoaxes: a practical example

body:
This is the story of a real case on en: Wikipedia, prompted by a
journalist query on the subject. I'm sending it to wikien-l and
wikimediauk-l as it's on topic, and Aphaia suggested wikipedia-l would
benefit from it as well.

Full credit to en:user:Average Earthman on this one - he did an excellent job.

This shows how Wikipedia deals with hoaxes: patiently and carefully
the first time around, less patiently the second, shoot-on-sight the
third.

The (Glasgow) Daily Record articles:
http://www.dailyrecord.co.uk/news/tm_objectid=16929538%26method=full%26siteid=66633%26headline=exclusive%2d%2dmeet%2dthe%2dreal%2dsir%2dwalter%2dmitty-name_page.html
http://www.dailyrecord.co.uk/news/tm_objectid=16929536%26method=full%26siteid=66633%26headline=mcilwraith%2ds%2dentry%2din%2dwikipedia-name_page.html

The eventual Times article barely mentions Wikipedia:
http://www.timesonline.co.uk/article/0,,2-2130227.html
- but I got a nice thank-you note back from Mr Lister and I think we
can say another journalist has successfully been informed.

I also blogged it: http://reddragdiva.livejournal.com/307381.html

- d.

Original query:

    My name is David Lister and I am a journalist for The Times. I am
doing a story today about a man called Alan McIlwraith, a call centre
worker in Glasgow, Scotland, who has been passing himself off as an
Iraq war hero. Mr McIlwraith, who claimed he was a sir and had
received the Military Cross, was exposed by a Glasgow tabloid
newspaper today; the British Army says that he has never even served
in its ranks. He also had an entry in wikipedia - which I am assuming
he wrote himself - in which he was described as someone who "can get
things done and is thought of as a hero?by the UK and NATO". His entry
has now been deleted: can you please tell me when it was removed? I am
assuming that he wrote this entry himself - what are the procedures
that one has to go through to submit an entry on your website?

My reply:

    Creating an article is easy - the only requirement is that you
create a WIkipedia user account, which is about thirty seconds'
effort. (This requirement was put into place in November last year,
which is actually after the Alan Mcilwraith article was first
created.) This means it's very easy to create something. The figures
as of November last year were about 4000 new articles a day, 2000 of
which were deleted within 24 hours. We've become ridiculously popular
since then, so I'm sure the numbers are much higher now.

    We get a lot of rubbish, but we operate on the principle of "keep
it open and clean up later" because it generally works well enough and
*most* jokes and hoaxes are easily spotted. Ever since the John
Seigenthaler hoax late last year, we've kept a *particularly* close
eye on the biographies of living people, which helps in areas such as
the current case.

    The article "Alan Mcilwraith" was created and deleted a few times.
I have administrator powers on English Wikipedia ("administrator" =
"janitor", rather than any sort of "senior editor" - an admin has
various cleanup powers, the ability to block vandals, delete and
undelete articles, etc.), so I am able to look up the history of the
article.

    It's actually a pretty typical example of how Wikipedia deals with
people putting rubbish or hoaxes in, so I'll detail exactly what
happened for you to give you an understanding of the process. We get
this sort of thing all the time, and we have reasonably effective
procedures for dealing with persistent hoaxers.

    The article was first created 18:28 GMT, 5 October 2005 by an
anonymous IP-address user. It was a badly-spelt and ungrammatical
article detailing Mcilwraith's improbable heroics, and reads like
something a high-school student would create as a prank - a lot of
deletable articles are of that description, and we're used to this
sort of thing. The creator kept working at the article, also creating
a username (User:MilitaryPro) to continue working on it - that
username doesn't appear to have written on any other subject.

    (MilitaryPro did add Alan Mcilwraith to "List of honorary British
Knights" on 21:18 GMT, 4 October 2005, but someone removed him two
hours later, at 23:19 GMT, with the comment "del Alan Mcilwraith -
Google has never heard of him - pretty good for someone supposedly
knighted this year". Lists of this sort tend to be on a lot of
editors' watchlists.)

    MilitaryPro uploaded a purported picture of Mcilwraith:
http://en.wikipedia.org/wiki/Image:Alan.No2.jpg , uploaded 22:36 GMT,
9 October 2005. Note that he marked it "may be reused for any
purpose", so if MilitaryPro is Mcilwraith and he owns the image, he
has in fact legally released it for free reuse if you need a pic :-)

    The article triggered the suspicions of Wikipedia editors in
fairly short order. One user, "Average Earthman", tagged it
"cleanup-verify" at 17:49 GMT, 10 October 2005, with the comment "This
smells like a hoax to me. What year was he made a CBE then?" The
"cleanup-verify" tag not only warns the reader, but adds tagged
articles to a category for dubious articles, so others can easily look
over what needs an unforgiving eye.

    Ten days later (19:48 GMT, 20 October 2005), with no verification
having been added to the article, another editor (user "RussBlau")
marked it for deletion. You can read the deletion debate at
http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Alan_Mcilwraith
- typical for an obvious hoax or joke article with no-one coming
forward with anything to verify otherwise. So it was deleted at 11:50
GMT, 26 October 2005.

    Interestingly, the same IP address that had created the article
had come back on 24 October and blanked the article, before its
deletion but after the first two comments on the deletion debate.

    MilitaryPro came back and created the article again at 18:39 GMT,
21 December 2005, working on it for a few days further, both as a
logged-in user and as an anonymous IP address. (The same IP address
also tried twice to delete the previous deletion discussion from the
list of old discussions, though these changes were quickly spotted and
reverted.)

    "Average Earthman" spotted the recreation at 12:44 GMT, 22
December 2005 - presumably he had the article on his watchlist - and
tagged it for deletion again, then re-tagged it 24 December for speedy
deletion as recreated deleted content, with the comments: "No, forget
the AfD, it's already failed in the past. Same lies again. It's a
hoax. And in case it isn't speedied, I still think it's a hoax. Uni at
14? Advisor to Generals at 22? No google hits? Really?" It was then
deleted the second time at 17:50 GMT, 24 December 2005.

    MilitaryPro came back to create the article a *third* time at
10:53 GMT, 17 February 2006. It was tagged two minutes later, at
10:55, for speedy deletion as "patent nonsense." MilitaryPro then
blanked the page at 11:00; "Average Earthman" tagged it for deletion
*again* at 11:09. (The more persistent the hoaxer, the easier they are
to deal with.) It was deleted for the third and final time at 16:19
GMT, 17 February 2006, and the page was locked with a "do not
recreate" notice (as you can see at
http://en.wikipedia.org/wiki/Alan_Mcilwraith ) a few seconds later.

    Interestingly, the hoax has been noted on the talk page of the
article (the "discussion" tab at the top):
http://en.wikipedia.org/wiki/Talk:Alan_Mcilwraith . Now that he's
making the papers, we have the question of whether his newfound fame
as a hoaxer makes him notable enough to have a Wikipedia article!


subject: [Wikipedia-l] How Wikipedia deals with hoaxes: a practical example


from_name: Sam Spade

subject: [WikiEN-l] Socialist POV

body:
The wikipedia may have a neutrality policy, but it hasn't many teeth,
and some POV's seem alot more equal than others. Two that I have run
up against time and time again are the Socialist POV (socialism has
never been implemented, most socialists define socialism like I do,
etc...) and the Pathological Skeptic POV (Humans are an ape, God is
just one diety among many, most scientists agree w me, etc...) Instead
of the collective editing process minimizing the insistance of these
editors to remove cited facts:

http://en.wikipedia.org/w/index.php?title=God&diff=46806965&oldid=46804989

and to make unsubstantiated claims:

http://en.wikipedia.org/wiki/Talk:Socialism#Unsubstantiated_claims

majoritocracy and oligarchic admins who shoot from the hip seem to
have the final say, trumping NPOV:

http://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Sam_Spade

The wikipedia needs to make some changes. Either rewrite NPOV to
reflect those biases welcomed by the project, or find a way to enforce
neutrality which works, i.e. not popularity contests.

SS


from_name: jkelly at fas.harvard.edu

subject: [WikiEN-l] Socialist POV

body:
Quoting Sam Spade <samspade.thomasjefferson at googlemail.com>:

>
> http://en.wikipedia.org/w/index.php?title=God&diff=46806965&oldid=46804989

  It is not immediately obvious to me why we shouldn't mention that most living
people believe in God as Creator in the first line of our article if that is,
in fact, the case.  Your reference, however, only shows that most Americans
believe in God as Creator, which is probably not something to include in the
first line of that article.  I also note that you wikilinked to the article on
Satanism from the mention of Dystheism.  I suggest that is crediting modern
Satanists with a much better grasp of theodicy than is the case.

> http://en.wikipedia.org/wiki/Talk:Socialism#Unsubstantiated_claims

  This link leads to you stating baldly that Socialism is in some way
essentially racist, and a handful of editors commenting that they don't think
that most socialists are racists.  I don't understand what you want us to take
away from that conversation.  It certainly doesn't suggest to me the existence
of some kind of pro-socialism cabal on Wikipedia as implied by your email.

  I do notice that the article is absurdly long, disjointed, full of uncited
weasel words, a patchwork of various hobby-horses, and something like half of
it renders in an underlined blue font.  That makes it pretty much in line with
the rest of our top-level politics articles.

> http://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Sam_Spade
>

  When some number of your peers are suggesting that you have a blind spot when
it comes to your own beliefs and that and that you seem to think your
edit-warring is more acceptable than it is, it might be worth your time to
consider that criticism seriously.

                          Jkelly


from_name: Alphax (Wikipedia email)

subject: [WikiEN-l] LS Studio and pro-pedophilia pov

body:
Stephen Bain wrote:
> On 4/12/06, Jimmy Wales <jwales at wikia.com> wrote:
>> I think we absolutely should delete it, if it is as unverifiable as
>> people are saying.
>>
>> This could be done in multiple steps, if that would help.
>>
>> First, remove all unverifiable statements from the article.  Insist
>> firmly on the talk page that nothing goes back into the article without
>> a solid site to a mainstream publication.
>>
>> Second, after a couple of weeks of demonstrating that there is therefore
>> nothing to be said, AfD would be appropriate and likely to succeed.
>
> That's basically what I did already: I cut all the unverifiable stuff
> and moved it to [[2004 Ukrainian child pornography raids]]. There have
> been no substantive changes in the five days since, after raging
> activity beforehand, clearly there is nothing of encyclopaedic value
> left.
>
> Nominating it for deletion is a good idea.
>

Had you {{prod}}ed it at the time, it would most likely have been
deleted by now. No need to drag it through AFD...

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

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


subject: [WikiEN-l] Georgia/Victoria

body:
Steve Bennett wrote:
> On 4/11/06, Pete Bartlett <pcb21 at yahoo.com> wrote:
>> To back up Mark's point with a concrete example,
>> [[Victoria]] has had no controversy, despite the
>> Australian state getting far less prominence on that
>> page than it deserves.
>
> That is truly the mother of all disambiguation pages! It would
> probably do well to highlight the most important cases (notably, the
> ex Queen, the Australian state, and the Canadian city) up the top, as
> recommended in whatever manual of style page. Then the more obscure
> articles, like defunct voting zones in Canadian provinces can be
> hidden down the bottom.
>

Without even looking, I'd suggest something like:

* [[Queen Victoria]]
* [[Victoria, Australia]]
** Stuff relating to Victoria, Australia
* [[Victoria, British Columbia]]
* Stuff relating to Victoria, British Columbia

etc.

Ok, now after looking at it, it's kinda messy, but I guess it works...

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

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


list: wikitech-l

from_name: Gregory Maxwell

subject: [Wikitech-l] What is required to "fix search"?

body:
On 4/13/06, Steve Bennett <stevage at gmail.com> wrote:
> That would be nice, but even the simple mechanism of exact matches
> would be a start. And then you can add fall backs, like all upper
> case, all lower case, upper case first letter of each word and so on.
> If performance is the issue here.

All upper/lower isn't really effective on Wikipedia because most of
our multiword titles are mixed case.

AFAIR, most string matches in mysql are case insensitive, which would
mean that we could have indexed case insensitive matches quickly...
but I'm guessing that our use of binary fields for titles (which is
required because no version of mysql has complete UTF-8 support) most
likely breaks that.

Alas, mysql doesn't have functional indexes
(http://bugs.mysql.com/bug.php?id=4990) or it would be fairly trivial
to offer a fast case-insensitive match.


from_name: Steve Bennett

subject: [WikiEN-l] Featured article deterioration

body:
On 13/04/06, Ben Greenberg <bengreenb at hotmail.com> wrote:
> It doesn't seem to me like Greasemonkey could solve the systemic problem--
> it'd just help deal with it better for a couple individual users who choose
> to use it.  How could we systemically work to prevent deterioration?  I've
> identified the following causes:
>
> 1.Multiple vandalisms, where only some are reverted

This can be better detected with tools that show multiple diffs at once.

> 2.Additions of poorly written stuff, but stuff not bad enough to warrant
> straight up reverting.

An almost untreatable problem.

> 3.Citations getting removed

Sucks, don't it.

> 4.Unecessary factoids and observations getting added.

That's Wikipedia - I don't think that's always a "problem" as such,
they just have to be distilled into something encyclopaedic. Sometimes
those factoids can lead somewhere...

Steve


from_name: Guettarda

subject: [WikiEN-l] Archives as sources proposal

body:
I have a certain sympathy for the idea - for example, it makes a certain
amount of sense, when a person's date of birth is in dispute, to get a copy
of their birth certificate.  However, this isn't foolproof - I remember
someone saying that their birth certificate said "February 30".  A good
researcher would have taken the primary source material, and put it in
context.  My grandfather's birth certificate said November 11, but he always
said that he was actually born November 1, but that there was a fine for
late registration, so his parents gave a later date.  If he was notable
enough to have a Wikipedia article (he isn't) I could have consulted the
original archival material, and said: born [[November 11]], [[1906]].  I
could not have used his story to say: born [[November 1]], despite what his
birth certificate says (as that's OR).  A real historian would have taken
the archival material and the anecdote and cross-checked against the story
of their being a fine for late registration, and maybe determined from other
sources whether such practised were commonplace at the time...and then used
that to decide the plausibility of the date of birth (and published it, of
course).

Unpublished primary sources can only be valid sources about the content they
contain ("his birth certificate says...").  In the hands of an amateur, they
really can't be taken to say anything more, we can't evaluate how good the
source is, we can't determine how much weight to give to one source as
opposed to another...


subject: [WikiEN-l] Request for second opinion templates

body:
Hi all,
  Are there any "request for second opinion" templates? There are many
times where I come across an article that smells fishy to me. However,
I'm not certain. All the processes like AfD, Prod etc presume that you
are personally sponsoring the destruction of the page. But at times
I'd simply like to add the page (with a minimum of effort) to some
list where smart people can be alerted to possible dodginess.

Ideally for me, such a template would simply add a template, with no
big ugly banner, again on the basis that I could be wrong.

The kinds of things that I might like to flag an article with:
- "smells like copyright violation"
- possible hoax
- contribution from user with history of bad edits
- unsourced change of a figure (eg, adjusting a city's population, a
number of awards won by someone, but not explaining the source for the
new figure)

I suppose what particularly concerns me is that some tags, like
cleanup, are really ugly and a bit of a slap in the face to
contributors to the article.

Any ideas?

Steve


from_name: Stephen Bain

body:
On 4/13/06, Alphax (Wikipedia email) <alphasigmax at gmail.com> wrote:
>
> Had you {{prod}}ed it at the time, it would most likely have been
> deleted by now. No need to drag it through AFD...

Unfortunately, until someone gets the toolserver to work with the new
separate en: cluster, PROD is down.

--
Stephen Bain
stephen.bain at gmail.com


subject: [Wikipedia-l] Help! Flood Attack at Chinese Wikipedia Now!

body:
Isn't there a  function to hide new account creation from recent changes?

Because other than screwing up RC, I can't see what problems it could
possibly cause.

Mark

On 13/04/06, mingli yuan <mingli.yuan at gmail.com> wrote:
> Help! Flood Attack at Chinese Wikipedia Now!
>
> Some evil guys attack Chinese Wikipedia by registing new users endlessly,
> please help us to disable new user register.
>
> Thanks.
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>

--
"Take away their language, destroy their souls." -- Joseph Stalin


subject: [Wikitech-l] ParserFunctions trial

body:
Reinhardt WIEWE @ torg.is wrote:
> The minimal compromise which would not harm template syntax nor conditional
> templates would be be the support / processing of the "trailer" in conditional
> templates. This is not banning as mentioned in your email:

You can already have line breaks here, can't you?

-- brion vibber (brion @ pobox.com)

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


from_name: Rob Church

subject: [Wikitech-l] ParserFunctions trial

body:
On 13/04/06, Erik Moeller <eloquence at gmail.com> wrote:
> As I understand it, we simply need someone to keep the LanguageAr.php
> file up to date to localize the relevant keywords. When MediaWiki
> provides the _functionality_ to localize something, but it is not
> localized because a volunteer hasn't done it, it isn't MediaWiki that
> is broken. We just need people to maintain the language files in each
> language; whether it's LTR or RTL is irrelevant. This process can of
> course be expedited by paying someone to do it.

I have maintained this position for a long time. Certain of the
developers do "adopt" languages and keep their localisations up to
date, and Rotem Liss seems to have placed himself in charge of keeping
the Hebrew localisation up-to-the-minute, but I think we could do
better than that.

> As for distinguishing between minor annoyances and things which are
> "horribly broken", I'd like to see some surveys among the actual users
> of the various non-English Wikipedias. As things are, I am entirely
> unconvinced that it is RTL issues which are the cause of the fact that
> ar.wikipedia.org has "only" 12000 articles. Limited access to or use
> of the WWW would be a much more important factor.

Concur.

Rob Church


from_name: Guy Chapman aka JzG

subject: [WikiEN-l] Now I wonder if this counts as a reliable source?

body:
Surely as a public service this important new research should be
incorporated into our growing series of articles on alien abduction
theories and other conspiracies, but is it a reliable source?

http://people.csail.mit.edu/rahimi/helmet/

It put me rather in mind of this ground-breaking study:
http://www.plokta.com/plokta/issue23/teapot.htm which gives us a
verifiable source to back the frequently-repeated assertion that
''foo'' is about as much use as a chocolate teapot.

Sorry, a slow afternoon in the office :-)
Guy (JzG)
--
http://www.chapmancentral.co.uk
http://en.wikipedia.org/wiki/User:JzG


from_name: Jay R. Ashworth

subject: [Wikitech-l] ParserFunctions trial

body:
On Thu, Apr 13, 2006 at 10:09:48PM +0200, Gerard Meijssen wrote:
> Brion Vibber wrote:
> > Gerard Meijssen wrote:
> >> The argument does not fall on its face; it only proves again that
> >> MediaWiki is hard, arguably impossible for many, to use for languages
> >> that are not left to right.
> >
> > In other words: the argument *does* fall on its face, but we can
> > make a totally different argument: that it would be nice to support
> > RTL better.
> >
> > Yes, it would be nice to support RTL better.
> >
> > However that has nothing to do with banning a construct that has THE
> > EXACT SAME ISSUES AS THE TEMPLATES IT WOULD REPLACE.
>
> The current functionality is not good enough. The argument that the
> new stuff does not make the situation worse is wrong. People argued
> that the new functionality will make it harder for many even in left
> to right languages. It becomes therefore even more problematic to use
> the constructs that are now considered in right to left languages.
>
> The current stuff is broken, the fact that the proposed new stuff is
> broken in the same way does not make it an excuse. Please remember
> what our objective is: information for all people in their language.

You know what's weird?

I agree with Gerard, kinda.

If there's a structural problem with the API to a template
implementation of functionality, then the time when you reimplement
that API into the core is the time to fix it, if you can, if only to
avoid institutionalizing an API with a structure which can't be
extended in the necessary fashion.

I don't know that this is that case, but if that particular aspect of
the thing hasn't been examined, perhaps it should be...?

Cheers,
-- jra
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

     A: Because it messes up the order in which people normally read text.
     Q: Why is top-posting such a bad thing?

     A: Top-posting.
     Q: What is the most annoying thing on Usenet and in e-mail?


from_name: Fred Bauder

subject: [WikiEN-l] Socialist POV

body:
Yes, and when I got to looking at it, some of it was still the old
National Socialism is socialism stuff.

Fred

On Apr 13, 2006, at 2:21 PM, Matt Brown wrote:

> On 4/13/06, Fred Bauder <fredbaud at ctelco.net> wrote:
>
>> Dismissing him out of hand is inappropriate without looking at the
>> edits. There is plenty of POV editing on the other side too. I'm
>> going to answer him too, but after I look at some sample edits.
>>
>
> Granted, but Sam's positioning of himself as the crusader of
> neutrality against the armies of bias is rather laughable.
>
> -Matt
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


subject: [Wikitech-l] DISPLAYTITLE

body:
On 13/04/06, Phil Boswell <phil.boswell at gmail.com> wrote:
> For example in the case of Aevar's <ref> extension it has been suggested
> that in cases where a section is being edited which contains <ref> tags but
> no <references/> tag, the extension might be able to produce a preview of
> what would appear without the user having to introduce a temporary
> <references/> (which would run the risk of their forgetting to remove it
> :-).

It would also be nice if the categories next to the rest of the page,
above the edit box. With however I set my prefs, I get this:

page text

edit box

categories

Steve


body:
Well, yes, but I meant, is it causing any attacks in the here-and-now
since people seem to be extremely concerned about this whole thing.

Mark

On 13/04/06, Andrew Gray <shimgray at gmail.com> wrote:
> On 13/04/06, Mark Williamson <node.ue at gmail.com> wrote:
> > Isn't there a  function to hide new account creation from recent changes?
> >
> > Because other than screwing up RC, I can't see what problems it could
> > possibly cause.
>
> Prelude to a mass page-move attack in a week's time?
>
> --
> - Andrew Gray
>   andrew.gray at dunelm.org.uk
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>

--
"Take away their language, destroy their souls." -- Joseph Stalin


from_name: Erik Moeller

subject: [Wikitech-l] ParserFunctions trial

body:
As I understand it, we simply need someone to keep the LanguageAr.php
file up to date to localize the relevant keywords. When MediaWiki
provides the _functionality_ to localize something, but it is not
localized because a volunteer hasn't done it, it isn't MediaWiki that
is broken. We just need people to maintain the language files in each
language; whether it's LTR or RTL is irrelevant. This process can of
course be expedited by paying someone to do it.

As for distinguishing between minor annoyances and things which are
"horribly broken", I'd like to see some surveys among the actual users
of the various non-English Wikipedias. As things are, I am entirely
unconvinced that it is RTL issues which are the cause of the fact that
ar.wikipedia.org has "only" 12000 articles. Limited access to or use
of the WWW would be a much more important factor.

Erik


from_name: Jakob Voss

body:
Steve Bennett wrote:

> Just wondering what the story with the search functionality is
> exactly. My biggest concern is that searches for the exact title of an
> existing (but "recently" created articles) fail.

Search engines don't update their search index live with every new item.
The problem with Wikipedia is its size and the quick changes. Normally
you would generate a new index every week or night - and to generate a
search index for millions of records takes hours! A powerful MediaWiki
search engine with a time lag of 1 to 2 days would also be fine for me -
you could also think of a smart search engine that works on an old dump
in the first run and checks on the live database in the second.

This is what I wrote about it last year: http://wm.sieheauch.de/?p=4
With this sketch of a special search engine for MediaWiki:
http://wm.sieheauch.de/files/MediaWikiSearchEngine.html

To get such a powerful search it's better to build it from the scratch
in an independent application instead of coding it into MediaWiki (but
I'm no MediaWiki developer so I may be wrong) so you can optimize for
searching only.

> I understand that searching is a difficult problem best left to
> Google, but is there a way where it could at least be hacked to check
> for articles whose name matches the search string verbatim?

How about about a title search?

SELECT page_id FROM page WHERE page_title RLIKE $regxp AND $conditions
LIMIT $limit

It would be useful to find articles named "FOO (BAR)", "List of FOO" etc.

Greetings,
Jakob


subject: [WikiEN-l] Georgia/Victoria

body:
Steve Bennett wrote:
> On 4/13/06, Alphax (Wikipedia email) <alphasigmax at gmail.com> wrote:
>
>> Without even looking, I'd suggest something like:
>>
>> * [[Queen Victoria]]
>> * [[Victoria, Australia]]
>> ** Stuff relating to Victoria, Australia
>> * [[Victoria, British Columbia]]
>> * Stuff relating to Victoria, British Columbia
>
> Have a look now.
>

Nice work. I've added {{disambig}} to the top as well, since (somewhere,
probably [[Wikipedia:Disambiguation]]) says that you can do so for
really long disambiguation pages.

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

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


from_name: Kirill Lokshin

subject:
[WikiEN-l] Wikipedia as a playground for other companies'
	disputes

body:
On 4/13/06, Mathias Schindler <neubau at presroi.de> wrote:
> http://www.flightglobal.com/Articles/2006/04/13/205967/Online+encyclop%c3%a6dia+Wikipedia+aircraft+group+allege+deliberate+misleading+Airbus+and+Boeing.html
>
> DATE:13/04/06
> SOURCE:Flight International
>
> Online encyclop?dia Wikipedia aircraft group allege deliberate
> misleading Airbus and Boeing entries
>
> Readers of the online open-access encyclop?dia Wikipedia have raised
> concerns that the entries of both Airbus and Boeing have been altered in
> possibly deliberately misleading ways.

Out of curiosity, is this the first time an individual WikiProject has
made the news?

Kirill Lokshin


from_name: Carl Fûrstenberg

subject: [Wikitech-l] ParserFunctions trial

body:
I have made two (one) example implementation on the english wikipedia that I
think might be useful, it's http://en.wikipedia.org/wiki/Template:Leap_yearand
http://en.wikipedia.org/wiki/Template:Tomorrow2 (tomorrow was already taken)


from_name: Justin Cormack

subject: [WikiEN-l] Archives as sources proposal

body:
On Thu, 2006-04-13 at 09:59 -0700, Matt Brown wrote:
> On 4/13/06, Fastfission <fastfission at gmail.com> wrote:
> > That doesn't even begin to capture its ridiculousness.
>
> As an Englishman, I carry a current understatement license.

Understatement license? Thats not an understatement license.
Its an irony license with the word 'irony' crossed out and
the word 'understatement' added.

Justinc


from_name: Michael Snow

body:
Kirill Lokshin wrote:

>On 4/13/06, Mathias Schindler <neubau at presroi.de> wrote:
>
>
>>http://www.flightglobal.com/Articles/2006/04/13/205967/Online+encyclop%c3%a6dia+Wikipedia+aircraft+group+allege+deliberate+misleading+Airbus+and+Boeing.html
>>
>>DATE:13/04/06
>>SOURCE:Flight International
>>
>>Online encyclop?dia Wikipedia aircraft group allege deliberate
>>misleading Airbus and Boeing entries
>>
>>Readers of the online open-access encyclop?dia Wikipedia have raised
>>concerns that the entries of both Airbus and Boeing have been altered in
>>possibly deliberately misleading ways.
>>
>>
>Out of curiosity, is this the first time an individual WikiProject has
>made the news?
>
>
No, assuming you're willing to include Andrew Orlowski's writings for
The Register under the heading of "the news". He mentioned "Project
Galatea" in passing once, and said he would discuss it in more detail
later, but I don't recall him following through and not much appears to
have come of the project.

--Michael Snow


from_name: GerardM

subject: [Wikitech-l] ParserFunctions trial

body:
Hoi,
Horribly broken is when it is not usable for an ordinary user. I was
not an ordinary user when I started editing in Farsi and, has been a
real education; it was horrible, it was broken. The only reason why I
finished the things I wanted done was because I used multiple browsers
for different tasks. Something that would take five minutes in Dutch
or English would take at least half an hour.

What is needed to have proper support for language is to have
developers who know these languages, know it as their mother language.
Who make sure that MediaWiki does not even have to suffer from "minor"
annoyances. Annoyances that would not be accepted for English.

It is rich that we feel this need to debate about what the main reason
is why we do poorly in left to right languages. All this talk is a
great excuse to do nothing. My answer is that the reason is a mix of
issues. When you change this mix by making it easier/possible to edit,
it will certainly change the potential for more contributions.

Thanks,
   Gerard

On 4/13/06, Erik Moeller <eloquence at gmail.com> wrote:
> As I understand it, we simply need someone to keep the LanguageAr.php
> file up to date to localize the relevant keywords. When MediaWiki
> provides the _functionality_ to localize something, but it is not
> localized because a volunteer hasn't done it, it isn't MediaWiki that
> is broken. We just need people to maintain the language files in each
> language; whether it's LTR or RTL is irrelevant. This process can of
> course be expedited by paying someone to do it.
>
> As for distinguishing between minor annoyances and things which are
> "horribly broken", I'd like to see some surveys among the actual users
> of the various non-English Wikipedias. As things are, I am entirely
> unconvinced that it is RTL issues which are the cause of the fact that
> ar.wikipedia.org has "only" 12000 articles. Limited access to or use
> of the WWW would be a much more important factor.
>
> Erik
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


from_name: Brion Vibber

subject: [Wikitech-l] templates and RTL issues

body:
William Allen Simpson wrote:
> We covered these issues in great detail in the IETF over a decade ago.
> There was a lot of acrimonious argument then, too, but Hank (and others)
> did a great job drafting a technical solution that solved the
> transmission and editing problems.
>
> (1) A canonical form for storage and transmission.  In SMTP, all storage
> and transmission is LTR.  I don't see why that couldn't apply here, too.
> Sure, it makes Hebrew appear backward in storage, but we usually don't
> look at the stored version.
>
> (2) Display and edit as RTL.  In practice, this turned out to be fairly
> simple by thinking about such things as opening and closing parentheses,
> rather than left and right.  They simply are reversed on display.
>
> (3) This allows all email to be parsed consistently, without change to
> the existing mail transmission programs, while specialized mail user
> agents (MUA) handle display of the text body.

Well, we work in a Unicode/XML/HTML context, and for better or for worse the W3C
world has explicitly embraced bidirectional text stored in logical order.

Parsing of markup happens on text in logical order. Since the markup is very
much embedded in the text and requires both exposure to human editors and
consistent parsing by the machine, I'm not sure that e-mail is a good
comparison. The 'markup' in e-mail is invisible to the user: headers, escape
codes, MIME content part separators.

Our output is to HTML, and editing is done in a web browser. This is a heavily
bidi-centric environment which I don't think we could really override if we
wanted to.

-- brion vibber (brion @ pobox.com)

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


from_name: Angela

subject: [Foundation-l] Placeopedia

body:
On 4/13/06, Benjamin Webb <bjwebb67 at googlemail.com> wrote:
> I've just discovered http://www.placeopedia.com/

> I wondered if anyone else had spotted these and whether placeopedia has
> permission to use the Wikipedia logo on its page.

The Board has known about it at least last November. The trademark
committee was supposedly working on a logo use contract then, but this
still hasn't materialised. Until then, no one officially has
permission to use the logo or to make derivatives of it, though many
sites (Placeopedia being one of them) have been told by various people
(though not through formal Board resolution) that there's no objection
to their use pending this policy. Such logos can be added to
http://meta.wikimedia.org/wiki/Uses_of_logo_derivatives so there's a
record of who needs to be contacted if and when such a contract ever
exists.

Angela.

--
Angela Beesley
Wikimedia.org || Wikia.com
Aim/MSN/Yahoo/Jabber: Wikiangela
Gmail/Skype: Beesley


subject: [Foundation-l] Placeopedia


from_name: Tels

subject: [Wikitech-l] DISPLAYTITLE

body:
Moin,

On Thursday 13 April 2006 15:01, Phil Boswell wrote:
> Brion Vibber wrote:
> > Tels wrote:
> >> I would like to generate different output depending on whether my
> >> extension code is triggered for a preview, or for a save.
> >
> > Please don't. Among other things, this defeats the purpose of a
> > preview.

I knew you would say this :(

With my preview I have a few problems that would be addressed by this:

* fontsize change. The user can specify a global percentage of making the
font bigger. Unfortunately, this affects #bodyContent (or however it is
actually named, I forgot the name). Works fine for the saved article, but
_also_ includes the preview/edit area (that arguable a bug, but fixing
that needs introducing another div into the output in the mediawiki
source code). So when you preview, suddenly all buttons etc, texts are
also bigger. This makes editing _very_ hard.

Of course, not seeing the real fontsize can be a bit problematic, too, but
then, you can't know in what final base fontsize the entire article will
be displayed, as every viewer is free to use CTRL+<+> and CTRL+<-> to
change it at will. So I'd rather have a workable preview mode, and see
the outcome in fontsize after saving.

* UI change. My extension makes certain user elements disappear in the
saved article for more viewing space (yeah, I can hear you already say
"dont do that". However, it is nec. and usefull. When you present text,
you dont want the menu. You dont print it, either, right? :-). However,
during preview one might actually want the menu box, and the toolbox
visible, only to have them disappear at save time.

It is of course possible to disable both the fontsize change as well as
the disappearing UI elements, as well as the preview-differes from save.

So, for users who *want* that functionality, it must be implemented in the
extension.

> I can certainly see where this might actually be a good thing to do.
>
> For example in the case of Aevar's <ref> extension it has been
> suggested that in cases where a section is being edited which contains
> <ref> tags but no <references/> tag, the extension might be able to
> produce a preview of what would appear without the user having to
> introduce a temporary <references/> (which would run the risk of their
> forgetting to remove it
>
> :-).

I am not sure I understand it, I just know that the feature can be
usefull. ;-]

Another idea is that for extension producing graphics or other inline
elements, a "preview" is (*Gasp! Shock! Horror!* :-) a preview, e.g. it
is maybe rendered with a reduced quality, but faster. Only when you save
the real final-quality image is produced.

Another problem is that when a preview is produced, my graph extension
(and any other extension producing files) leaks a file: Hash the contents
to render to filename, produce preview, user then edits the contents,
saves, a new file is generated. The file from the preview is, unlike
files from former editions of an article, no longer accessable.

With a dedicated preview action the file could be stored into a different
temp folder, which could be cleaned out at any time without any risk of
loosing files that are still referenced in real articles.

(In fact, this point is the strongest point for determining =preview,
because it would stop almost all leaks of files from my extension. The
only ones left are from deleting articles and are much harder to get rid
of.)

So, I'd still like to know how to ask the parser whether it renders for a
preview, or for the final save.

Best wishes,

Tels

--
 Signed on Thu Apr 13 19:14:38 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "We're looking at a future where only the very largest companies will be
 able to implement software, and it will technically be illegal for other
 people to do so." -- Bruce Perens, 2004-01-23

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20060413/405b5287/attachment.pgp>


subject: [Wikitech-l] DISPLAYTITLE

body:
Moin,

On Wednesday 12 April 2006 20:33, Brion Vibber wrote:
> Tels wrote:
> > How do you determine whether the parser currently runs for
> > action=view or action=preview etc?
>
> You don't. :)
>
> The parser does not (or should not!) know anything about the outside
> environment.

So please tell my how my extension can know about preview or not preview.
For reasons why this is actually desirable, see my other email. :)

If the Parser should not know, then something else must know and be able
to pass the knowledge on. If it can't, then extensions producing files
are forever leaking files and thus clobbering disks up :(

Best wishes,

Tels

--
 Signed on Thu Apr 13 19:29:07 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "You know the world is going crazy when the best rapper is a white guy,
 the best golfer is a black guy, the tallest guy in the NBA is Chinese,
 the Swiss hold the America's Cup, France is accusing the U.S. of
 arrogance, Germany doesn't want to go to war, and the three most
 powerful men in America are named 'Bush', 'Dick', and 'Colon'. Need I
 say more?" -Chris Rock

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20060413/a46385d1/attachment.pgp>


from_name: Mathias Schindler

subject: [WikiEN-l] Wikipedia as a playground for other companies' disputes

body:
http://www.flightglobal.com/Articles/2006/04/13/205967/Online+encyclop%c3%a6dia+Wikipedia+aircraft+group+allege+deliberate+misleading+Airbus+and+Boeing.html

DATE:13/04/06
SOURCE:Flight International

Online encyclop?dia Wikipedia aircraft group allege deliberate
misleading Airbus and Boeing entries

Readers of the online open-access encyclop?dia Wikipedia have raised
concerns that the entries of both Airbus and Boeing have been altered in
possibly deliberately misleading ways.


subject: [Wikitech-l] TOClimit

body:
Moin,

On Wednesday 12 April 2006 23:04, Conrad Dunkerson wrote:
> * Tels wrote:
> > Which is one of the serious problems of having usefull stuff in
> > templates: You need to replicate them to all wikis that might use
> > them.
> >
> > That's where build-ins for some very-often used or usefull things
> > have an advantage, like other wiki sites getting them, too.
>
> Backwards logic. The 'problem' you assign to the templates is actually
> the absence of the feature in MediaWiki. The template is not the
> problem, but rather a solution to it.

What I meant to express was that the template is the "short-term", but
"wrong" solution, in that it works "right now but is not practical in the
long run.

E.g. it only works on en, then fr needs to copy it, then ch re-invents it,
then it copies it, too, and then somehow all the rest of the wikis on the
world need to either re-invent it, or copy it.

Just thinking in needs of Wikipedia (or even one language aspect) neglets
all the other wikis out there :)

I know it is much easier to write a template than to produce a source code
patch, and the latter isn' the solution to anythign an all. Still, it
should be made easier, and in any event a solution for distributing (and
updating) usefull templates to other wikis needs to be found.

Best wishes,

Tels

--
 Signed on Thu Apr 13 19:42:45 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "In 1988, Jack Thompson ran against Janet Reno for DA of Dade County:
 Thompson's unique campaign message was that Reno was unfit for the job
 because, as a closeted lesbian with a drinking problem, she was great
 candidate for blackmail by the criminal element. Jack never explained
 why this remained a threat even after he exposed her 'secret'. Reno
 cruised at the polls."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20060413/a5d9ca38/attachment.pgp>


from_name: Steve Bennett

body:
On 13/04/06, Jakob Voss <jakob.voss at nichtich.de> wrote:
> Search engines don't update their search index live with every new item.
> The problem with Wikipedia is its size and the quick changes. Normally
> you would generate a new index every week or night - and to generate a
> search index for millions of records takes hours! A powerful MediaWiki
> search engine with a time lag of 1 to 2 days would also be fine for me -
> you could also think of a smart search engine that works on an old dump
> in the first run and checks on the live database in the second.

That would be more than fine. I gather the search db is currently
several months out of date? But that wasn't my major complaint.

> To get such a powerful search it's better to build it from the scratch
> in an independent application instead of coding it into MediaWiki (but
> I'm no MediaWiki developer so I may be wrong) so you can optimize for
> searching only.

Well, it should be as easily accessible as the search box is now.

> SELECT page_id FROM page WHERE page_title RLIKE $regxp AND $conditions
> LIMIT $limit

That would be nice, but even the simple mechanism of exact matches
would be a start. And then you can add fall backs, like all upper
case, all lower case, upper case first letter of each word and so on.
If performance is the issue here.

Steve


from_name: Reinhardt WIEWE @ torg.is

subject: [Wikitech-l] ParserFunctions trial

body:
On Thu, 13 Apr 2006 12:29:58 -0700
 Brion Vibber <brion at pobox.com> wrote:

> In other words: the argument *does* fall on its face, but we can make a
> totally
> different argument: that it would be nice to support RTL better.
>
> Yes, it would be nice to support RTL better.

Thanks Brion for this constructive approach.

There are many places to start, many issues have been reported and many test
have been made but I see no "road map".

One of the bidirectional issues all projects could benefit from is to implement
"fix location lists" for the special pages. Onece you did it one time it is
trivial.

See the three pages sharing identical source code:
http://epov.org/wd-gemet/index.php/Wikidata_M2:Special_pages/%21list#special:Specialpages
http://www.anubite.co.uk/mediawiki/head-rtl/index.php/Mw16:Special_pages/%21list#special:Specialpages
http://www.anubite.co.uk/wikis/test-fpr/index.php/Farsitest:Special_pages/%21list#special:Specialpages

In these lists the position of relevant fields are preserved *regardles* of the
directionality of the content. This is exactly what users would expect from
special pages.

There are two more open requirements which can RTL / BiDi live easier:

Facilitate bidirectional editing / readability via a trailing escape character
(as "\") at the end of line
http://bugzilla.wikimedia.org/show_bug.cgi?id=05121
It would be fair to allow multiline syntax in MediaWiki same as all the
MediaWiki software is written.

Magic words (pedefined templates) {{UTF-8DECODE:}} {{UTF-8ENCODE:}} (optional
{{UTF-8ENCODE8:}} {{UTF-8ENCODE16:}})
http://bugzilla.wikimedia.org/show_bug.cgi?id=5256
This is not a constructed request. The feature can save hours.

Regarding my objections against not supporting table code in the conditional
templates please respect that I tell / write what I think and that I write it
now.
The minimal compromise which would not harm template syntax nor conditional
templates would be be the support / processing of the "trailer" in conditional
templates. This is not banning as mentioned in your email:

> However that has nothing to do with banning a construct that has THE EXACT
> SAME
> ISSUES AS THE TEMPLATES IT WOULD REPLACE.
>
> -- brion vibber (brion @ pobox.com)

best regards reinhardt [[user:gangleri]]


from_name: David Boothroyd

subject: [WikiEN-l] Georgia/Victoria

body:
Alphax writes:
>Steve Bennett wrote:
>  > On 4/13/06, Alphax (Wikipedia email) < alphasigmax at gmail.com > wrote:
>  >
>  >> Without even looking, I'd suggest something like:
>  >>
>  >> * [[Queen Victoria]]
>  >> * [[Victoria, Australia]]
>  >> ** Stuff relating to Victoria, Australia
>  >> * [[Victoria, British Columbia]]
>  >> * Stuff relating to Victoria, British Columbia
>  >
>  >Have a look now.
>
>Nice work. I've added {{disambig}} to the top as well, since (somewhere,
>probably [[Wikipedia:Disambiguation]]) says that you can do so for
>really long disambiguation pages.

A few months ago, musing on the conjunction between Sven-Goran Eriksson
and Sven the scorer on "I'm Sorry, I Haven't a Clue", I noticed there
wasn't a page for [[Sven]]. Using Special:Allpages to identify the page
produced a very long disambiguation page which included all the people
called Sven on which there was an article. A brief introduction simply
stated that Sven was an old German first name.

Other editors subsequently sorted them by field, and then Uncle G
removed the 'disambiguation' notice on the grounds that the names were
not really ambiguous, which is (as usual for Uncle G) quite correct.
--
David Boothroyd - http://www.election.demon.co.uk
david at election.demon.co.uk (home)
dboothroyd at westminster.gov.uk (council)


subject: [Wikitech-l] ParserFunctions trial

body:
On Thu, 13 Apr 2006 23:16:27 +0300
 Ilmari Karonen <nospam at vyznev.net> wrote:
> Gerard Meijssen wrote:
> >
> > The current stuff is broken, the fact that the proposed new stuff is
> > broken in the same way does not make it an excuse. Please remember what
> > our objective is: information for all people in their language.
>
> At this point it might be appropriate for the people complaining about
> it being broken to propose a syntax the _would_ work for them.  Doesn't
> have to be perfect, just something to give us LTR-writing folks
> something more concrete to work on than "it doesn't work".
>
> --
> Ilmari Karonen

Dear Ilmari,
Would you prefere a wording "It is not practical"?

Please go at
http://yi.wiktionary.org/w/index.php?title=template:listspecial&action=edit
I copied the template from Rob's testwiki because you would need to login.

This is a typical "all in one line template" designed at a LTR wiki and pasted
here. No additional complications because of Hebrew characters.

To see that the template is functional take a look at
http://yi.wiktionary.org/wiki/project:Special_pages/%21list

I would not thouch that to spend my time.

Now go to
http://yi.wiktionary.org/w/index.php?title=%D7%B0%D7%90%D6%B7%D7%A1%D7%A2%D7%A8&action=edit

this is an old draft waiting for optimization trough conditional templates.

Nothing special. Beleive me that RTL / BiDi editing is complicated enougt and
there is no need for more workarounds / restictions.

reinhardt [[user:gangleri]]


from_name: William Allen Simpson

subject: [Wikitech-l] templates and RTL issues (was: ParserFunctions trial)

body:
I'm a recent addition to this list.  I joined after the Apr 9 outage,
thinking that as a longtime Internet engineer I'd be able to help on
operational issues.  Sadly, that doesn't seem to be a focus here.

Never-the-less, these parser functions have been requested for a long
time and been a source of considerable acrimony.  I'm very happy they
have been implemented, and as the trial proceeds, it's possible that
improvements will be made.

However, the RTL issue doesn't seem to have anything to do with these
functions in particular.  It may be an issue with parsing all templates.

We covered these issues in great detail in the IETF over a decade ago.
There was a lot of acrimonious argument then, too, but Hank (and others)
did a great job drafting a technical solution that solved the
transmission and editing problems.

(1) A canonical form for storage and transmission.  In SMTP, all storage
and transmission is LTR.  I don't see why that couldn't apply here, too.
Sure, it makes Hebrew appear backward in storage, but we usually don't
look at the stored version.

(2) Display and edit as RTL.  In practice, this turned out to be fairly
simple by thinking about such things as opening and closing parentheses,
rather than left and right.  They simply are reversed on display.

(3) This allows all email to be parsed consistently, without change to
the existing mail transmission programs, while specialized mail user
agents (MUA) handle display of the text body.

In this case, I don't see why the templates cannot be parsed in the
standard canonical order, but displayed RTL as an option.  Then, there's
no need for line continuation escaping and such ugliness, that would
just interfere with RTL editing.

Just reverse the template syntax on display, along with everything else;
   * without localization (BiDi):
                                                  {{else|then|test:if#}}
   * assuming localization of the words:
                                                  {{esle|neht|tset:fi#}}

That would seem to correlate with my memory of the recommendations of
W3C, too, but I'm no expert there.


from_name: David Gerard

subject: [Foundation-l] IRC: #wikimedia-uk on Freenode

body:
James has set up a general chat channel for UK Wikimedia-related matters:

    #wikimedia-uk on irc.freenode.net
    irc://irc.freenode.net/wikimedia-uk

All are welcome. He appears to be in there 24 hours, I'll be in there
when my laptop is on.

- d.


from_name: Gerard Meijssen

subject: [Wikitech-l] ParserFunctions trial

body:
Brion Vibber wrote:
> Gerard Meijssen wrote:
>
>> The argument does not fall on its face; it only proves again that
>> MediaWiki is hard, arguably impossible for many, to use for languages
>> that are not left to right.
>>
>
> In other words: the argument *does* fall on its face, but we can make a totally
> different argument: that it would be nice to support RTL better.
>
> Yes, it would be nice to support RTL better.
>
> However that has nothing to do with banning a construct that has THE EXACT SAME
> ISSUES AS THE TEMPLATES IT WOULD REPLACE.
>
> -- brion vibber (brion @ pobox.com)
Hoi,
The current functionality is not good enough. The argument that the new
stuff does not make the situation worse is wrong. People argued that the
new functionality will make it harder for many even in left to right
languages. It becomes therefore even more problematic to use the
constructs that are now considered in right to left languages.

The current stuff is broken, the fact that the proposed new stuff is
broken in the same way does not make it an excuse. Please remember what
our objective is: information for all people in their language.

Thanks,
    GerardM


subject: [Wikitech-l] ParserFunctions trial

body:
On Fri, 14 Apr 2006 00:27:15 +0300
 Ilmari Karonen <nospam at vyznev.net> wrote:
> Reinhardt WIEWE @ torg.is wrote:
> >
> > Now go to
> >
>
http://yi.wiktionary.org/w/index.php?title=%D7%B0%D7%90%D6%B7%D7%A1%D7%A2%D7%A8&action=edit
> >
> > this is an old draft waiting for optimization trough conditional templates.
> >
> > Nothing special. Beleive me that RTL / BiDi editing is complicated enougt
> and
> > there is no need for more workarounds / restictions.
>
> Yes, I can see that it's a mess.  But what would you propose instead?

Improuvements in small steps:

a) Bug 4011: Allow users to change text direction in all text input and
textarea boxes
== http://bugzilla.wikimedia.org/show_bug.cgi?id=4011

http://yi.wiktionary.org/wiki/user:Gangleri/tests/bugzilla#RTL_.26_Bidi_issues
lists all RTL and bidirectional projects (striked projects are not set up)

When you edit
http://ar.wikipedia.org/wiki/project/sandbox/do_not_save?action=edit
as an anonimuous user you will see that the cursor is at the right
if you log in you will see that the cursor is at the left
the same will happen at
http://he.wikipedia.org/w/index.php?title=Project/sandbox/do_not_save&action=edit
but at
http://fa.wikipedia.org/w/index.php?title=Project/sandbox/do_not_save&action=edit
http://ur.wikipedia.org/w/index.php?title=Project/sandbox/do_not_save&action=edit
http://ug.wikipedia.org/w/index.php?title=Project/sandbox/do_not_save&action=edit
the cursor will be always at the right

BTW: I discovered the difference at ar: and he: just now.

Facilitate bidirectional editing / readability via a trailing escape character
(as "\") at the end of line
== http://bugzilla.wikimedia.org/show_bug.cgi?id=05121
realy would be an improuvement

you may see that this is also a workaround for the bug demonstarted at
http://meta.wikimedia.org/wiki/Talk:ParserFunctions#note_on_usage_of_whitespace_in_templates

> Would it be easier to edit if it was _all_ in Hebrew, with no Latin
> letters at all?  As far as I know, this should be possible: all the
> MediaWiki keywords can be localized, and template names and parameters
> can of course be changed on each wiki.  The only major problem I see are
> HTML tags -- I don't think MediaWiki has any way to localize those.
>
> --
> Ilmari Karonen

The question if it "be easier to edit if it was _all_ in Hebrew, with no Latin
letters at all?" does not focus on the main problem.

Content, contributor names, variables, parameters would be more and more mixed.
Of course it would be more easier if a single script would be used. But it can
be made "less complicated" also.

http://epov.org/wd-gemet/index.php/Template_talk:dir_rtl
is a template to include RTL text in a LTR environment and
http://yi.wikipedia.org/wiki/template_talk:dir_ltr
is a template to include LTR text in a RTL environment.

There should be some copies around at various projects. They can be improuved
because padding is not necessary.

The templates are used / can be used inside articles, pages, project and hep
pages.

To answer your question: I neither untherstand Arabic, Dari, Farsi, Hebrew,
Kurdish, Pashto, Sindhi, Urdu etc. I have some minimal knowledge of Yiddish.

Keeping keywords in English would help me to provide some support. For the
native speakers a translation is more suitable.

But one can provide support also either useing 'project', '{{ns:project}}' or
'{{subst:ns:project}}'.

Thanks for your interest on this topic. If you spend months to find out all
what's possible and what is not you can not explain this in a few minutes.
However it should not take that long once the knowledge is available.

best regards reinhardt [[user:gangleri]]


from_name: Jay R. Ashworth

subject:
[Wikitech-l] templates and RTL issues (was: ParserFunctions
	trial)

body:
On Thu, Apr 13, 2006 at 09:11:28PM -0400, William Allen Simpson wrote:
> I'm a recent addition to this list.  I joined after the Apr 9 outage,
> thinking that as a longtime Internet engineer I'd be able to help on
> operational issues.  Sadly, that doesn't seem to be a focus here.

Note that there are many lists related to MediaWiki and Wikimedia
Foundation issues; it's possible that you're on the wrong one.

Cheers,
-- jra
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

     A: Because it messes up the order in which people normally read text.
     Q: Why is top-posting such a bad thing?

     A: Top-posting.
     Q: What is the most annoying thing on Usenet and in e-mail?


from_name: Guy Chapman aka JzG

subject: [WikiEN-l] Socialist POV

body:
On Thu, 13 Apr 2006 12:05:44 -0600, you wrote:

>Dismissing him out of hand is inappropriate without looking at the
>edits. There is plenty of POV editing on the other side too. I'm
>going to answer him too, but after I look at some sample edits.

Looking at the articles is fine.  Dismissing him out of hand is fine,
too, and not in any way incompatible with looking at the articles.
Sam's POV is way off neutral; far better to use your own judgment.
Which is likely rather better than Sam's, given his past history per
http://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Sam_Spade.

For the record, I followed the linked edits up and came to precisely
the same conclusion as JKelly, especially the point about the God
article.  America <> the world.  I wouldn't like to guess what
proportion of the world's population are monotheistic believers, but I
would find a figure over 50% very surprising given all the pantheists,
agnostics and atheists out there.

But then, I'm just a stupid ape descendent who doesn't know any
better...
Guy (JzG)
--
http://www.chapmancentral.co.uk
http://en.wikipedia.org/wiki/User:JzG


from_name: Ilmari Karonen

subject: [Wikitech-l] ParserFunctions trial

body:
Gerard Meijssen wrote:
>
> The current stuff is broken, the fact that the proposed new stuff is
> broken in the same way does not make it an excuse. Please remember what
> our objective is: information for all people in their language.

At this point it might be appropriate for the people complaining about
it being broken to propose a syntax the _would_ work for them.  Doesn't
have to be perfect, just something to give us LTR-writing folks
something more concrete to work on than "it doesn't work".

--
Ilmari Karonen


subject: [Wikitech-l] ParserFunctions trial

body:
On Thu, 13 Apr 2006 15:25:57 -0700
 Brion Vibber <brion at pobox.com> wrote:
> Reinhardt WIEWE @ torg.is wrote:
> > The minimal compromise which would not harm template syntax nor conditional
> > templates would be be the support / processing of the "trailer" in
> conditional
> > templates. This is not banning as mentioned in your email:
>
> You can already have line breaks here, can't you?
>
> -- brion vibber (brion @ pobox.com)

Unfortunatelly not everywhere:
http://meta.wikimedia.org/wiki/Talk:ParserFunctions#note_on_usage_of_whitespace_in_templates
shows a *general template* example with a parameter having a trailing new line
which will breake in a construct as [[user:{{{bar}}}|{{{bar}}}]].

the last two test regarding {{#if: ... }} render fine
http://meta.wikimedia.org/wiki/Talk:ParserFunctions#Notes_on_syntax

http://bugzilla.wikimedia.org/show_bug.cgi?id=05121
relates also to list items where a new line would break the syntax

best regards reinhardt [[user:gangleri]]


from_name: Lars Aronsson

body:
Jakob Voss wrote:

> Search engines don't update their search index live with every new item.
> The problem with Wikipedia is its size and the quick changes. Normally
> you would generate a new index every week or night - and to generate a
> search index for millions of records takes hours!

I'm not sure if you're talking about the big web search engines
(Google, Yahoo, MSN) or the search function in Mediawiki here.
There is little excuse for the latter to have any delay.  But even
for a big web search engine, it is easy to keep track of how often
each webpage has changed in history, and economize how often it
needs to be revisited.  Combined with the high PageRank of en.wp's
RecentChanges (9 of 10), it would be trivial for Googlebot to
revisit this page (or the front page of websites of major
newspapers) every minute or two and make it a high priority to
reindex all pages linked from there.  I suppose this is how Google
News works.  Why it still takes about a month for Google to update
its index on Wikipedia articles is a mystery to me.  Probably it
has to do with a lack of competition.  If MSN or Yahoo were
faster, it would force Google to improve.

--
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik - http://aronsson.se


from_name: Sam Spade

subject: [WikiEN-l] Socialist POV

body:
Laugh all you want, but after you research please.

Dismissing  me out of hand with a "Move along, folks, nothing to see
here." does help cull the more gullible viewers however, which I guess
I could thank you for...

SS

On 4/13/06, Matt Brown <morven at gmail.com> wrote:
> On 4/13/06, Fred Bauder <fredbaud at ctelco.net> wrote:
> > Dismissing him out of hand is inappropriate without looking at the
> > edits. There is plenty of POV editing on the other side too. I'm
> > going to answer him too, but after I look at some sample edits.
>
> Granted, but Sam's positioning of himself as the crusader of
> neutrality against the armies of bias is rather laughable.
>
> -Matt
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Molu Bosu Palit

subject: [WikiEN-l] Deletion reform

body:
Hi,

  I recently created [[Wikipedia:Ammendment to deletion policy]]
after seeing some of the rationales offered by the people at AfD. This
seeks to remoce state of content as a criterion of deletion, making topic
the sole deciding factor in deletion debates. No more "delete, badly
sourced" or "delete, pov". Please discuss this at the talk page. Thank
you.

  Molu

---------------------------------
New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.


from_name: brion at pobox.com

subject: [Wikitech-l] MediaWiki automated test run failure 2006-04-14

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

Running test Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED!
Running test Magic Word: {{NUMBEROFFILES}}... FAILED!
Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED!

Passed 300 of 303 tests (99.01%) FAILED!


subject: [Wikitech-l] ParserFunctions trial

body:
Reinhardt WIEWE @ torg.is wrote:
>
> Now go to
> http://yi.wiktionary.org/w/index.php?title=%D7%B0%D7%90%D6%B7%D7%A1%D7%A2%D7%A8&action=edit
>
> this is an old draft waiting for optimization trough conditional templates.
>
> Nothing special. Beleive me that RTL / BiDi editing is complicated enougt and
> there is no need for more workarounds / restictions.

Yes, I can see that it's a mess.  But what would you propose instead?

Would it be easier to edit if it was _all_ in Hebrew, with no Latin
letters at all?  As far as I know, this should be possible: all the
MediaWiki keywords can be localized, and template names and parameters
can of course be changed on each wiki.  The only major problem I see are
HTML tags -- I don't think MediaWiki has any way to localize those.

--
Ilmari Karonen


from_name: Justin Cormack

subject: [WikiEN-l] Socialist POV

body:
On 13 Apr 2006, at 23:25, Fred Bauder wrote:

> Yes, and when I got to looking at it, some of it was still the old
> National Socialism is socialism stuff.

Yes that seemed to be the main issue when I looked.

I looked over the Socialism article and it didnt seem too bad,
especially as it is an overview article that mainly is referencing
other articles, always a hard thing to write well. Trying to add
a view that National Socialism was, er, the only real socialism
ever implemented seemed rather foolish, and out of place there.

The article needs more references, but I can see it is hard to
do this in the overview (havent yet had time to read all the
subarticles).

Justinc


from_name: Andrew Gray

body:
On 13/04/06, Mark Williamson <node.ue at gmail.com> wrote:
> Isn't there a  function to hide new account creation from recent changes?
>
> Because other than screwing up RC, I can't see what problems it could
> possibly cause.

Prelude to a mass page-move attack in a week's time?

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


from_name: Kernigh

subject:
[Foundation-l] Stewards are ignoring requests for CheckUser
	information?

body:
Sometimes, several new user accounts will vandalise a wiki, after which the
local sysops will apply infinite blocks. In these cases it is very probable
that the accounts are sockpuppets of one user and form an "array of vandal
sockpuppets" (AOVS). A wiki with local CheckUser users can use CheckUser to
check if the vandalism is from an AOVS, and then block the IP address of the
AOVS. (see footnote [1]) One such situation occured today at en.wikibooks,
which has no local CheckUser users. Thus I decided to try to request some
CheckUser information from the stewards. So I went to:

http://meta.wikimedia.org/wiki/Request_for_CheckUser_information

However, I discovered that there are unhandled requests on that page. At 1
April 2006, there was a request concerning a previous AOVS on en.wikibooks. At
30 March 2006, there was a request concerning an AOVS ("array of vandal
sockpuppets") on simple.wikipedia. Neither request is marked has handled or
rejected. It is now 14 April 2006, and we are at risk of losing the opportunity
for CheckUser, because the databases sometimes forget IPs after one week. [2]

Why has no steward responded to these and many other requests for information
made in February, March, and April 2006?

-- [[Wikibooks:en:User:Kernigh]]
   http://en.wikibooks.org/wiki/User:Kernigh

Footnote [1]:
I have not found good documentation, but I will describe how I believe the
blocking to work; please correct me if I am wrong.
* A block against a user account blocks only when that user is logged in.
* A block against an IP address blocks all user accounts, but only when the
accounts edit from that IP.
* When a blocked user accesses the wiki, an autoblocker also blocks this IP
address. This block expires when the user block expires, or after 24 hours,
whichever is earlier.
* If a sysop acts quickly and blocks an AOVS user account while the vandal is
still active, the autoblocker will block the AOVS ("array of vandal
sockpuppets") IP address, but only for 24 hours.

Footnote [2]:
I have not yet made my request for CheckUser information. I want to know the
answer to this question:

Why has no steward responded to these and many other requests for information
made in February, March, and April 2006?


from_name: Essjay

body:
I agree with Mark, and raise the question of why we worry about these
mass account creation sprees? As long as we block them before they
"age", does it really cause a problem? Should we be worried about them,
or are we just giving the vandals undue attention?

Essjay

http://en.wikipedia.org/wiki/User:Essjay
Wikipedia:The Free Encyclopedia
http://www.wikipedia.org/

Mark Williamson wrote:
> Well, yes, but I meant, is it causing any attacks in the here-and-now
> since people seem to be extremely concerned about this whole thing.
>
> Mark
>
> On 13/04/06, Andrew Gray <shimgray at gmail.com> wrote:
>
>> On 13/04/06, Mark Williamson <node.ue at gmail.com> wrote:
>>
>>> Isn't there a  function to hide new account creation from recent changes?
>>>
>>> Because other than screwing up RC, I can't see what problems it could
>>> possibly cause.
>>>
>> Prelude to a mass page-move attack in a week's time?
>>
>> --
>> - Andrew Gray
>>   andrew.gray at dunelm.org.uk
>> _______________________________________________
>> Wikipedia-l mailing list
>> Wikipedia-l at Wikimedia.org
>> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>>
>>
>
>
> --
> "Take away their language, destroy their souls." -- Joseph Stalin
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>
>


from_name: Matt Brown

subject: [WikiEN-l] Georgia/Victoria

body:
On 4/14/06, Steve Bennett <stevage at gmail.com> wrote:

> (arguably a few of the cities named Victoria should be on the list, if
> "Victoria, Newport" is not a natural construction in the UK etc.

I disagree with removing everything that has a natural qualifier,
since people may not know or think of the correct one.  E.g. if
someone is searching for a city named Victoria, they may not know what
state, province, county or whatever it's in.

It makes sense to list the more likely cases first, though.

-Matt


from_name: Nathaniel Sheetz

subject:
[WikiEN-l] Alexa - rankings differenciated among users from
	different countries

body:
You have ES listed twice--is one of them supposed to be EN, perhaps?

Nathaniel

On 4/14/06, Mathias Schindler <neubau at presroi.de> wrote:
>
> Alexa has now a new feature, at least it took me until today to discover
> it. At http://www.alexa.com/site/ds/top_500, you will find a list of
> countries. Alexa is providing a list of web sites that Alexa believes
> them to be popular in that country. It is still not clear what the data
> basis for Alexas charts is. The most likely source is its toolbar which
> appears to have a feature that phones back to Alexa.
>
> I have compiled a list of wikipedia's rank in the different countries,
> both sorted by ISO country code and sorted by the rank. When a country
> did not have wikipedia.org among its TOP 100 (pretty rare these days,
> might even be an indication of being blocked in some cases), it is
> marked as XX.
>
> Data retrieved on April 14, 2006:
>
> Sorted by ISO country code (and by Alexa's standards what a country
> might be)
> AE  39
> AR  19
> AT  08
> AU  15
> BE  15
> BG  16
> BH  45
> BR  27
> CA  12
> CH  08
> CL  21
> CO  10
> CR  25
> CY  29
> CZ  17
> DE  07
> DK  28
> DO  27
> EG  57
> ES  14
> ES  32
> FI  16
> FR  13
> GB  12
> GR  22
> HK  97
> HR  18
> HU  24
> IE  13
> IL  13
> IN  21
> IR  27
> IS  17
> IT  13
> JO  42
> JP  30
> KR  XX
> KW  57
> LB  73
> LT  19
> MA  35
> MX  13
> MY  18
> NL  12
> NO  17
> NZ  08
> OM  19
> PE  15
> PH  21
> PK  10
> PL  09
> PR  12
> PS  55
> PT  11
> QA  73
> RO  12
> RU  25
> SA  XX
> SE  21
> SG  16
> SI  18
> SK  15
> SY  42
> TH  86
> TR  45
> TW  XX
> UA  21
> UK  12
> US  14
> VE  26
> VN  67
> YE  40
> ZA  13
> ZH  XX
>
>
> Same list, sorted by the rank itself:
>
> 07 DE
> 08 AT
> 08 CH
> 08 NZ
> 09 PL
> 10 CO
> 10 PK
> 11 PT
> 12 CA
> 12 GB
> 12 NL
> 12 PR
> 12 RO
> 12 UK
> 13 FR
> 13 IE
> 13 IL
> 13 IT
> 13 MX
> 13 ZA
> 14 ES
> 14 US
> 15 AU
> 15 BE
> 15 PE
> 15 SK
> 16 BG
> 16 FI
> 16 SG
> 17 CZ
> 17 IS
> 17 NO
> 18 HR
> 18 MY
> 18 SI
> 19 AR
> 19 LT
> 19 OM
> 21 CL
> 21 IN
> 21 PH
> 21 SE
> 21 UA
> 22 GR
> 24 HU
> 25 CR
> 25 RU
> 26 VE
> 27 BR
> 27 DO
> 27 IR
> 28 DK
> 29 CY
> 30 JP
> 32 ES
> 35 MA
> 39 AE
> 40 YE
> 42 JO
> 42 SY
> 45 BH
> 45 TR
> 55 PS
> 57 EG
> 57 KW
> 67 VN
> 73 LB
> 73 QA
> 86 TH
> 97 HK
> XX KR
> XX SA
> XX TW
> XX ZH
>
>
> A couple of months ago, Kate gave some similar data about the
> distribution of web site requests among countries in relation to its
> population (or something like that, I can't find the URL at the moment).
> At a first glimpse at the data, I find it plausible. I also feel
> satisfied to see three countries with a large share of German speaking
> population at a top of that list (I hope this is not just because the
> level of infestation with alexa sp^wphonehomeware is particulary high
> there :)).
>
> Mathias
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Rob

subject: [WikiEN-l] Archives as sources proposal

body:
On 4/14/06, Steve Bennett <stevage at gmail.com> wrote:
>
>
> Seriously, that's the basic problem isn't it - amateurs trying to do
> the work of experts.

Isn't that the definition of Wikipedia? ;)


from_name: Arwel Parry

subject: [WikiEN-l] Wikipedia compared..... again!

body:
The May issue of BBC Focus magazine ("The world's best science and
technology monthly"), (www.bbcfocusmagazine.com, but the contents are
not online) is interesting from a Wikipedia point of view. Firstly
there's a "quick chat" with Jimbo, together with a full page photo of
our benevolent god-king himself, and a three-page "Tried and Tested"
feature on online encyclopaedias - Encarta, Infoplease, Wikipedia, and
Our Favourite Other Encyclopaedia. They only compared three articles --
one for current news ("Bird flu"), one for history ("George
Stephenson"), and one for obscure facts ("Planetesimal"), and also
reviewed the usability of each site together with details of cost (if
any), number of entries, sources, and multimedia.

The usability comment for Wikipedia says "The design is a bit text-heavy
but useful "contents" tools help you navigate the articles. Links
abound, but the sheer number of them means you can soon find yourself
far adrift from your starting point. There are close to 500,000 media
files, but video and audio is restricted to the patent-free formats Ogg
Theora and Ogg Vorbis."

The Bird Flu test:
Reviewed by St Andrews University virologist Dr Richard Elliot, looking
to see whether the encyclopaedias can keep up with a fast-moving
subject.

Encarta: "Encarta has a short entry on avian flu with no details on the
scale of the ongoing H5N1 outbreak. The info is out of date and
cross-referencing is limited. The influenza entry contains a number of
errors (for example, the influenza B virus does not infect birds, as
stated here), and requires thorough revision."

EB: "Britannica online provides a short entry on bird flu that contains
the essential information but with no in-depth coverage. The material is
about six months out of date and does not mention the use of
neuraminidase inhibitors (e.g. Tamiflu) that are being stockpiled in
some countries and widely mentioned in the media."

Infoplease: "There's no specific entry for bird flu and the search
directs to a very brief entry on influenza. However we do get an FAQ
entry heavily based on World Health Organisation material from November
2005. This deals with aspects of the disease in a concise
question-answer format but the lack of cross-references limits any
in-depth analysis."

Wikipedia: "Wikipedia provides the most comprehensive and up-to-date
information with cross-references and links to original sources.
Generally the entries are accurate and suitable as an
undergraduate-level resource, but the terminology section of the H5N1
entry is both confused and contains errors, while some links did not
direct to the correct reference."

The George Stephenson test:
Broadcaster Dick Strawbridge was looking for an accurate and accessible
account of the great railway engineer.

Encarta: "If you need more than a couple of general lines you have to
subscribe to the premium content, but it's easy to read and there are
plenty of dates and facts. Reading Stephenson's obituary from The Times
of 1848 puts the man's life in historical context and some of the links
introduce facts not covered by the other online encyclopaedias."

EB: "Britannica tells a very easy-to-read story about George
Stephenson's life. It's not a comprehensive list of dates and events,
but you do get a rounded portrait of the man. Unfortunately, it reckons
Stephenson's Rocket went a lot faster than the commonly agreed 29 miles
per hour (47 kph) - which hurts when you're paying for the information."

Infoplease: "Even after following all the available links, you end up
with very little useful information here. Historical context was thin,
with no allusion to Stephenson's reputation as the "father of British
steam railways". The ads that flash on the pages would have been very
useful if I'd been looking for love. Sadly, I was after facts."

Wikipedia: "An entry that is clear, comprehensive, and full of facts.
The information is digestible, presented in chronological order, and the
most detailed of all the encyclopaedias on test. For example, it was the
only one to inform me that we can thank Mr Stephenson for the majority
of the world's railway tracks being 4' 8.5"."

The Planetesimal test:
Astronomer Dr Duncan Steel examined how an ambiguous term is handled.
"Planetesimal" is used to describe the blocks that collide to form
planets, but is also used for modern comets and asteroids.

Encarta: "The definition of 'planetesimal' is given in terms of a body
that exists early in a solar system's history. Elsewhere on the site it
says the Oort cloud, a huge sphere of comets about a lightyear from the
Sun, consists of planetesimals, and that asteroids are fragments of
planetesimals. That's fine by me, but contrary to the definition given
here."

EB: "The most authoritative entry on the subject begins with this
admirable definition: 'One of a class of hypothetical bodies that
eventually coalesced to form the planets after condensing from gaseous
matter early in the history of the solar system.' A bit technical for
the lay reader and the possible asteroid-or-comet meaning is not
covered."

Infoplease: "Planetesimals are mentioned in the context of the theory
for the origin of the Solar System. Elsewhere, things get confusing when
the term 'planetoid' is given as another synonym for 'asteroid'. Not
very useful since asteroid means 'star-like' - which fits their
appearance through a telescope, but not their physical nature."

Wikipedia: "Both possible meanings of planetesimal are given, among
various other confusing statements that contain factual errors and
punctuation outrages. But my main beef with Wikipedia is that it
contains an entry for Elbsteel, the asteroid I named for my youngest
son, but not for Arrius, the one named for my eldest. This causes
arguments at home!" [NB, actually we created an entry for "5263 Arrius"
on 12th April, so both sons should now be happy].

The Verdict:
Ratings: Infoplease 2/5; Encarta 3/5; Britannica 3/5; Wikipedia 4/5.

Wikipedia pros: Comprehensive articles with lots of detail, the most
up-to-date encyclopaedia on test, page labels help assess the quality of
the information; it's free.

Wikipedia cons: Some factual errors found; occasional slips in spelling
and grammar.

"All the encyclopaedias contained at least some errors and omissions,
reinforcing the point that they should be viewed as starting points for
your research rather than as all-encompassing fountains of knowledge.
Infoplease fared poorest in our test with very little to get your teeth
into. Encarta has a bright design and engaging multimedia options, but
was let down by a dismal performance in the 'current news' test.
Meanwhile Britannica's long history was showcased in authoritative pages
that are easy to get around. Our winner is Wikipedia which had the most
detailed articles and was best equipped to deal with the ever-changing
news about bird flu. While it was only marginally more accurate, it has
close to 10 times more articles than the next biggest, all freely
available. That means it's most likely to have what you need."

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


from_name: mingli yuan

body:
Help! Flood Attack at Chinese Wikipedia Now!

Some evil guys attack Chinese Wikipedia by registing new users endlessly,
please help us to disable new user register.

Thanks.


from_name: Robert Scott Horning

subject:
[Foundation-l] Stewards are ignoring requests
	for	CheckUser	information?

body:
Essjay wrote:

>Perhaps this would be an appropriate time to say "Maybe we could use a
>couple more stewards?"
>
>Essjay
>
>
Or perhaps the minimum requirement for the number of votes for users to
get checkuser status on smaller projects like en.wikibooks is
unreasonable?  We have had a couple of candidates for checkuser status
for almost two months now, and we simply can't get the number of votes
necessary because of the size of our active user base.  Yet we are the
target of repeated vandalism, and even sockpuppet voting from die-hard
sock puppets.  If the concern is that checkuser privileges are going to
be abused, it is a smaller user base that can be abused.

Should projects be allowed to set their own standards for people with
this status, or is it something that is imutable and only set by the
Foundation board?  So far, only Wikipedias are seemingly allowed to have
somebody with checkuser status at all.  And if stewards are overwhelmed
with this task of dealing with checkuser scans, perhaps the policy needs
to be reviewed.

--
Robert Scott Horning


from_name: Mathias Schindler

body:
Alexa has now a new feature, at least it took me until today to discover
it. At http://www.alexa.com/site/ds/top_500, you will find a list of
countries. Alexa is providing a list of web sites that Alexa believes
them to be popular in that country. It is still not clear what the data
basis for Alexas charts is. The most likely source is its toolbar which
appears to have a feature that phones back to Alexa.

I have compiled a list of wikipedia's rank in the different countries,
both sorted by ISO country code and sorted by the rank. When a country
did not have wikipedia.org among its TOP 100 (pretty rare these days,
might even be an indication of being blocked in some cases), it is
marked as XX.

Data retrieved on April 14, 2006:

Sorted by ISO country code (and by Alexa's standards what a country
might be)
AE  39
AR  19
AT  08
AU  15
BE  15
BG  16
BH  45
BR  27
CA  12
CH  08
CL  21
CO  10
CR  25
CY  29
CZ  17
DE  07
DK  28
DO  27
EG  57
ES  14
ES  32
FI  16
FR  13
GB  12
GR  22
HK  97
HR  18
HU  24
IE  13
IL  13
IN  21
IR  27
IS  17
IT  13
JO  42
JP  30
KR  XX
KW  57
LB  73
LT  19
MA  35
MX  13
MY  18
NL  12
NO  17
NZ  08
OM  19
PE  15
PH  21
PK  10
PL  09
PR  12
PS  55
PT  11
QA  73
RO  12
RU  25
SA  XX
SE  21
SG  16
SI  18
SK  15
SY  42
TH  86
TR  45
TW  XX
UA  21
UK  12
US  14
VE  26
VN  67
YE  40
ZA  13
ZH  XX

Same list, sorted by the rank itself:

07 DE
08 AT
08 CH
08 NZ
09 PL
10 CO
10 PK
11 PT
12 CA
12 GB
12 NL
12 PR
12 RO
12 UK
13 FR
13 IE
13 IL
13 IT
13 MX
13 ZA
14 ES
14 US
15 AU
15 BE
15 PE
15 SK
16 BG
16 FI
16 SG
17 CZ
17 IS
17 NO
18 HR
18 MY
18 SI
19 AR
19 LT
19 OM
21 CL
21 IN
21 PH
21 SE
21 UA
22 GR
24 HU
25 CR
25 RU
26 VE
27 BR
27 DO
27 IR
28 DK
29 CY
30 JP
32 ES
35 MA
39 AE
40 YE
42 JO
42 SY
45 BH
45 TR
55 PS
57 EG
57 KW
67 VN
73 LB
73 QA
86 TH
97 HK
XX KR
XX SA
XX TW
XX ZH

A couple of months ago, Kate gave some similar data about the
distribution of web site requests among countries in relation to its
population (or something like that, I can't find the URL at the moment).
At a first glimpse at the data, I find it plausible. I also feel
satisfied to see three countries with a large share of German speaking
population at a top of that list (I hope this is not just because the
level of infestation with alexa sp^wphonehomeware is particulary high
there :)).

Mathias


subject:
[Foundation-l] Stewards are ignoring requests for
	CheckUser	information?

body:
Perhaps this would be an appropriate time to say "Maybe we could use a
couple more stewards?"

Essjay

http://en.wikipedia.org/wiki/User:Essjay
Wikipedia:The Free Encyclopedia
http://www.wikipedia.org/

Dariusz Siedlecki wrote:
> On 4/14/06, Angela <beesley at gmail.com> wrote:
>
>>> Why has no steward responded to these and many other requests for
>>>
>> information
>>
>>> made in February, March, and April 2006?
>>>
>> Only three stewards (Anthere, Datrio, and Oscar) have CheckUser
>> access. I don't know if the backlog is because the policy is unclear
>> on when requests can be fulfilled, or whether there just aren't enough
>> people willing to carry out these requests.
>>
>
> Not really - we have CheckUser access on Meta, but every Steward can
> give him CheckUser access on any other wiki.
>
> Personally, I'm taking care of every request that'll get through _to
> me_. I'm not checking [[Request for CheckUser information]] all the
> time, I'll confess. I'll try to take care of these requests in a few
> minutes, I hope someone will be able to help me.
>
> --
> Pozdrawiam,
> Dariusz Siedlecki
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>
>


from_name: Guettarda

body: So what's with Alexa - the English-speaking Caribbean doesn't exist to them?


subject: [WikiEN-l] Archives as sources proposal

body:
On 4/14/06, Rob <gamaliel8 at gmail.com> wrote:
>
> On 4/14/06, Steve Bennett <stevage at gmail.com> wrote:
> >
> >
> > Seriously, that's the basic problem isn't it - amateurs trying to do
> > the work of experts.
>
>
>
> Isn't that the definition of Wikipedia? ;)
>

Hmmm...now that you have shot a huge hole in my generalisation...

I really hadn't thought of it that way.  We are amateurs trying to be
encyclopaedists to some extent.  But we are amateurs playing at being
editors (in some cases, professional editors playing at being amateur
editors...), not amateurs playing at being subject experts (though again,
some of us are subject experts).  Ok, so discard my summary line, and stick
with Steve's - I think he got my point across better than I did.

Ian