from_name: Mark Williamson

subject:
[Wikipedia-l] How to edit wikipedia when stupid mods block all
	Thai ip addresses

body:
Yes - Thai ISPs are blocked from nl.wp, not th.wp.

Mark

On 13/02/07, Michael Snow <wikipedia at earthlink.net> wrote:
> Walter van Kalken wrote:
>
> > Read Thai fora and websites over Thailand. It will not work. providers
> > do not care as there are just a few foreigners suffering from this.
> > Most Thais only visit Thai websites.
>
> The Thai Wikipedia has just over 19,000 articles, and according to
> Alexa, wikipedia.org is the 15th-most-popular website in Thailand. Even
> with the standard caveats about Alexa data, that can't all be Thai
> expatriates elsewhere and only foreigners in Thailand.
>
> --Michael Snow
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/wikipedia-l
>

--
Refije dirije lanm? yo paske nou posede pw?p bato.


list: commons-l

source: pipermail-mbox

from_name: Eugene Zelenko

subject: [Commons-l] Mayflower: Wikimedia Commons media search

body:
Hi!
> Hi, this is a follow-up to my posts regarding "The Ideal Wiki
> Software" on foundation-l, from late January.
>
> I've uploaded my Wikimedia Commons image/media search tool, dubbed
> "Mayflower",  to the toolserver; it's available at http://
> tools.wikimedia.de/~tangotango/mayflower/.
>
> Just to recap, this tool allows full-text searching of the Commons
> database, returning a gallery-based results page, much like Google
> Images and similar services. The main goal was to make a user-
> friendly interface, so that even non-Wikimedians can take advantage
> of it.
>
> As I said back in January, I'm still interested in Brianna Laugher's
> idea of making a gallery-based, full-text search feature available as
> a MediaWiki extension, so that it can take advantage of the existing
> MediaWiki search index and the stability of the main servers.
>
> Any comments and/or suggestions would be most welcome.
>
> (Sorry if this looks like an advertisement; I don't usually advertise
> new tools, but I thought the foundation-l and commons-l communities
> would be interested.)
>
> Cheers,
>
> Tangotango

Great tool! Thank you for your work!

I found minor problem. I tried to search for Rakaw/?????/????? and it
find images only for query Rakaw. Images contain descriptions with all
variants.

May be tool searches only withing references to page titles?

With best regards,
Eugene.


list: wikien-l

from_name: Flame Viper

subject: [WikiEN-l] Admin Elitism (part 2)

body:
Admin Elitism (part 2)
Actually, the previous submission wasn't all I had to say; I got cut off because I had to leave.
The last sentence, "Why shouldn't adminship be a trophy", was never answered be me.
The answer is, "because it isn't".

Its original purpose was because somebody would use the tools. But it seems that not only does someone need to require the tools, they *also* need to write new articles. Which has jack to do with adminship.
That may seem to have little to do with the topic at hand, but in fact it is closely related.

Writing good articles and doing general non-admin things should NOT be a reason for adminship. An article-writer would have little to no use for the admin tools. And a recent-canges patroller who is turned down because she "doesn't write articles" would be rightly confused.

I think the root of this "adminship is a reward for writing articles etc" attitude is that people think just that and forget the core principles of being an administrator.

My suggestion to root all the unecessary sysops is to create two eschelons of "elevated" users.

The "writers" and the "sysops".

A sysop would be just like an ordinary sysop; delete, protect, block, and reverse all those.

But a writer would be more of an honorific and would not have some of the capabilities. The only capabilities a writer would have would be to delete OR protect (haven't decided yet).

A sysop's only responsibility should be to understand Wikipedia policies and guidelines, and be willing to use the sysop tools. I would actually be a writer since I don't partol RC or go to AIV.

---------------------------------
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.


subject: [WikiEN-l] ?

body:
Message: 10
Date: Tue, 13 Feb 2007 12:39:15 +0100
From: "Christof Sperl" <christof.sperl at gmail.com>
Subject: Re: [WikiEN-l] Allowed use of list email addresses
To: "English Wikipedia" <wikien-l at lists.wikimedia.org>
Message-ID:
 <102f82b90702130339v1efcd841k4ebd2769c884a7c9 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I got that e-mail too, from the student in Thailand. Weird. <aybe it's just an etxperiment to see if all these e-mail addresses are "real". The thing that worries me is that this might just be a prelude to massive loads of SPAM SPAM SPAM.

I haven't got such an e-mail, but if that user really wants to use the
mail
addresses from this list in any not-so-nice ways I suppose there is
noone
able to stop him one he has the address really.

On 13/02/07, Gary Kirk <gary.kirk at gmail.com> wrote:
>
> I know that, and I don't have a problem with that, but would suggest
> the user not go about his enquiries in this way.
>
> On 2/13/07, NSLE (Wikipedia) <nsle.wikipedia at gmail.com> wrote:
> > I can confirm that I did. To be fair, the archive is available
publicly,
> so
> > by contributing to this you're letting everyone know your email
address.
> >
> > On 13/02/07, Gary Kirk <gary.kirk at gmail.com> wrote:
> > >
> > > Did anyone else receive an email recently with the subject
> > > ''Requesting to make comments for e-learning wiki''? I did, from
a
> > > student in Thailand, and I found it rather rude. Surely people
are not
> > > supposed to randomly grab addresses from mailing lists they
subscribe
> > > to?
> > > --
> > > Gary Kirk
> > >
> > > _______________________________________________
> > > WikiEN-l mailing list
> > > WikiEN-l at lists.wikimedia.org
> > > To unsubscribe from this mailing list, visit:
> > > http://lists.wikimedia.org/mailman/listinfo/wikien-l
> > >
> > _______________________________________________
> > WikiEN-l mailing list
> > WikiEN-l at lists.wikimedia.org
> > To unsubscribe from this mailing list, visit:
> > http://lists.wikimedia.org/mailman/listinfo/wikien-l
> >
>
>
> --
> Gary Kirk
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> http://lists.wikimedia.org/mailman/listinfo/wikien-l
>

---------------------------------
Looking for earth-friendly autos?
 Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.


subject: [WikiEN-l] WikiEN-l Digest, Vol 43, Issue 95

body:
Lamest digest ever

wikien-l-request at lists.wikimedia.org wrote: Send WikiEN-l mailing list submissions to
 wikien-l at lists.wikimedia.org

To subscribe or unsubscribe via the World Wide Web, visit
 http://lists.wikimedia.org/mailman/listinfo/wikien-l
or, via email, send a message with subject or body 'help' to
 wikien-l-request at lists.wikimedia.org

You can reach the person managing the list at
 wikien-l-owner at lists.wikimedia.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of WikiEN-l digest..."

Today's Topics:

   1. Re: Admin burnout (deputy admins) (Thomas Dalton)

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

Message: 1
Date: Wed, 14 Feb 2007 11:58:12 +0000
From: "Thomas Dalton"
Subject: Re: [WikiEN-l] Admin burnout (deputy admins)
To: "English Wikipedia"
Message-ID:

Content-Type: text/plain; charset=ISO-8859-1; format=flowed

> "Utopia (from Greek i.e. "no place" or "place that does not exist")"
> I think maybe it was a joke? A continuation of the original punning?
> I didn't see it as an attack, at the least.

Ok, so that part was a pun, the rest was an ad hominem attack. He
referred to me multiple times and never made any mention of my
arguments - it's an excellent example of an ad hominem attack.

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

_______________________________________________
WikiEN-l mailing list
WikiEN-l at lists.wikimedia.org
To unsubscribe from this mailing list, visit:
http://lists.wikimedia.org/mailman/listinfo/wikien-l

End of WikiEN-l Digest, Vol 43, Issue 95
****************************************

---------------------------------
Don't get soaked.  Take a quick peak at the forecast
 with theYahoo! Search weather shortcut.


list: wikitech-l

from_name: Jim Wilson

subject: [Wikitech-l]  Massive Hook Proposal

body:
Dear Wiki Devs,

I have a proposal for adding new hooks into the MW codebase, and I'm looking
for feedback (positive and negative).  The goal of the proposed changes is
to give Extension Devs the ability to cleanly hijack just about any class in
the system.  Here are the details:

Step 1: For each class in MW, create a static factory method for class
instantiation.  The factory method would take the same number of arguments
as the class constructor, and under normal circumstances would simply call
the constructor.  Here's an example for the UploadForm class (
SpecialUpload.php):

--------------------------------------------------------------
class UploadForm {

// ...

function instantiate( &$request ) {
    $uploadForm = new UploadForm($request);
    wfRunHooks('UploadFormInstantiate', array( &$uploadForm, &$request ));
    return $uploadForm;
}
--------------------------------------------------------------

Step 2: Replace all calls to the traditional "new Whatever($args)" with
"Whatever::instantiate($args)".

By doing this, extension developers gain the power to modify any class
before it's ever used, possibly even replacing it with a custom class
they've developed.

What do you think?  I'm genuinely interested in hearing what everyone has to
say.  Thanks!

(Please note that I haven't tested any code for this yet - so if my syntax
in the example is out of order, I apologize in advance).

-- Jim R. Wilson


from_name: Kasimir Gabert

subject: [Wikitech-l] Massive Hook Proposal

body:
On 2/14/07, Mark Clements <gmane at kennel17.co.uk> wrote:
> "Jim Wilson" <wilson.jim.r at gmail.com> wrote in
> message news:ac08e8d0702140532sdd74668u487a6aeab0eaa35e at mail.gmail.com...
> > Dear Wiki Devs,
> >
> > I have a proposal for adding new hooks into the MW codebase, and I'm
> looking
> > for feedback (positive and negative).  The goal of the proposed changes is
> > to give Extension Devs the ability to cleanly hijack just about any class
> in
> > the system.  Here are the details:
> >
> [SNIP]
> > --------------------------------------------------------------
> > class UploadForm {
> >
> > // ...
> >
> > function instantiate( &$request ) {
> >     $uploadForm = new UploadForm($request);
> >     wfRunHooks('UploadFormInstantiate', array( &$uploadForm, &$request ));
> >     return $uploadForm;
> > }
> > --------------------------------------------------------------
> [SNIP]
> > What do you think?  I'm genuinely interested in hearing what everyone has
> to
> > say.  Thanks!
>
> No real comment on the idea at the moment, except that it might be better to
> use "Instantiate_ClassName" as the hook, so that they can be easily grouped
> in documentation, or referred to as "Instantiate_*" hooks.  It also clearer
> what the hook does if you come across one you haven't seen before, I think.
>
> - Mark Clements (HappyDog)
>
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

Hello Jim,

I would definitely vote for this idea.  It could potentially be a
solution to many questions that people are posting, such as how to
turn a wiki into a content management system.  It would definitely
make upgrading easier with wikis that have heavily hacked core code.

--
Kasimir Gabert


list: foundation-l

from_name: teun spaans

subject: [Foundation-l] Mayflower: Wikimedia Commons media search

body:
Pls dont exclude the ogg files - instead, offer checkboxes by which the uer
can select media types he/she searches

On 2/14/07, Andrew Gray <shimgray at gmail.com> wrote:
>
> On 13/02/07, Tangotango <tangotango at wikignome.net> wrote:
>
> > Any comments and/or suggestions would be most welcome.
>
> Very funky.
>
> Would it be possible to have an option to restrict it only to image
> files? Some searches bring up quite a few .ogg files stored on
> Commons, which are not desperately useful for most people using the
> search...
>
> The thumbnailing is sometimes a bit unexpected. For example,
> http://commons.wikimedia.org/wiki/Image:Tromboon.jpg is displayed as
> just the top fraction of the image - a plain brass U-bend and nothing
> else. Is it possible to do a full-article thumbnail?
>
> --
> - Andrew Gray
>   andrew.gray at dunelm.org.uk
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/foundation-l
>


list: wikimedia-l


from_name: Pedro Sanchez

subject:
[Foundation-l] The Communist Vandal Trashed the Dine (Navajo)
	Wikipedia

body:
On 2/14/07, Jeffrey V. Merkey <jmerkey at wolfmountaingroup.com> wrote:
>
> The Communist Vandal trashed the entire Dine (Navajo) Wikipedia at
> nv.wikipedia.org sometime earlier today.
>
> I have reverted all of his edits -- it took a while.  He managed to
> vandalize every single article on this wiki in a matter of minutes.
>
> Jeff
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/foundation-l
>

why was his block length shortened to 19 days?


from_name: Jon Harald Søby

subject: [Foundation-l] MediaWiki Server

body:
Hi! You should mail mediawiki-l for that, this list is only for
Wikimedia Foundatino matters.

On 2/14/07, Frazer Kirkman <frazer at frazerk.net> wrote:
> Greetings.
>    My associates and I are looking to build a new Wiki using MediaWiki.
> We are looking to have lots of audio and video content.
> I was hoping you could suggest servers which are optimized for this purpose.
> I am particularly concerned with the expandability.
>
> Do the MediaWiki servers serve other projects, or can you suggest any
> servers are being used by other MediaWiki sites?
> If not, are there any considerations we need to be aware of for deciding
> on for supplying good performance for MediaWiki?
>
> Thank you
>
>     Frazer Kirkman
>
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/foundation-l
>

--
Best regards,
Jon Harald S?by

Website - http://www.alqualonde.com/
Wikipedia - http://no.wikipedia.org/wiki/Bruker:Jhs
MSN messenger - jhsoby at gmail.com
Skype - jon.harald.soby


subject: [Foundation-l] MediaWiki Server


from_name: NSLE (Wikipedia)

subject: [WikiEN-l] Admin Elitism

body:
[[WP:AN#User:Flameviper]]. End of story imo.

On 14/02/07, Gurch <matthew.britton at btinternet.com> wrote:
>
> Flame Viper wrote:
> > I recently was engaged in an encounter with a particularly troublesome
> admin. He blocked me and when I attempted to contact him through e-mail, he
> made ad hominem personal attacks and generally condescended to me. Now I can
> assure you this is the only time an admin has ever personally attacked me,
> but I have repeatedly encountered the seemingly glaring obviousness that is
> admin elitism.
> >
> > Wikipedia editors, or regular users, usually create and edit articles,
> sometimes reverting vandalism or dealing with formal Wikipedia business. And
> once an editor has performed a large enough amount of good deeds, they can
> be nominated for administrator. An RfA is a harsh process which yields few
> admins, and this would seem to make them an exclusive group (which they are
> indeed). Many people (or at least me) seem to regard adminship as a sort of
> trophy rather than advanced tools. And it would be intuitive to think that.
> On almost all websites, being made a moderator (or other "elevated user
> right status") is a gesture of great respect, trust, and exclusivity. This
> is because moderators are the "high lords" of the website, much like mayors
> or representatives.
> > So why shouldn't adminship be a trophy?
> >
>
> Forgive me if I've misread this, but you seem to be simultaneously
> complaining about admin elitism and saying there's nothing wrong with it.
>
> Adminship is a set of advanced tools. Some people use it like a trophy.
> There isn't an awful lot that can be done about that. And if it really
> results from "good deeds" then some people have a very odd definition of
> "good deeds".
>
> Don't read too much into the "standards" applied at RfA. All sorts of
> arbitrary metrics and irrelevant judgements are made there. More
> worryingly, the "standards" are being raised progressively higher, to
> the point that nobody who would make a good administrator can be one.
>
> I took a glance at the RfA page today to see what was what. It seems
> that two popular reasons to oppose at the moment are "doesn't need the
> tools" and "doesn't do enough work on articles".
>
> Just wait... before long people will start applying BOTH those criteria
> simultaneously. Then *nobody* will pass.
>
> -Gurch
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> http://lists.wikimedia.org/mailman/listinfo/wikien-l
>


from_name: Guy Chapman aka JzG

subject: [WikiEN-l] Admin burnout

body:
On Tue, 13 Feb 2007 17:24:24 -0800, Ray Saintonge
<saintonge at telus.net> wrote:

>"Plain bad luck" in our context means that there may be instances where
>we will be sued no matter what we do.

Sure.  But if we have done our best and show it, we'll be OK.

Guy (JzG)
--
http://www.chapmancentral.co.uk
http://en.wikipedia.org/wiki/User:JzG


from_name: Brion Vibber

subject: [Wikitech-l] Massive Hook Proposal

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

Jim Wilson wrote:
> Also, if implemented, what version(s) should be targeted?  I'm thinking
> 1.8.4, 1.9.3 and 1.10.0 - your thoughts?  Is there going to be a 1.6.10 that
> would benefit from this?  Thanks in advance.

Massive far-reaching changes like that would never ever go into
maintenance releases of old versions.

Is it a security fix? no.

Is it a vital bug fix necessary for the software to run? no.

- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF00FBwRnhpk1wk44RAt4SAJ9h7hXhpPDuiYAVcjYxgT9U2aVAcQCfVGIk
aEny2OzSpT90Kem/KWmm+pY=
=S60U
-----END PGP SIGNATURE-----


from_name: Earle Martin

subject: [WikiEN-l] - category clutter on biographical articles

body:
On 14/02/07, Bryan Derksen <bryan.derksen at shaw.ca> wrote:
> On a serious note, though, I happen to use the Classic skin as my
> default and I don't have any problem with this at all. If this sort of
> thing _was_ sufficiently annoying to me I could put "#catlinks
> {display:none}" in my custom CSS like what I did to get rid of the stub
> templates, or just switch to one of the other skins that puts the
> catlinks at the bottom. Wikipedia's display format is highly
> configurable so I don't consider this to be a paprticularly strong
> example of "harm".

It would be useful if there were preference switches for what one
wanted to see, i.e. "Don't show: [ ] article categories [ ] stub
messages ...",  and so on, a la the kind of display configuration you
get on Slashdot and similar sites, that would set user CSS
appropriately. While technical users such as ourselves may be
comfortable with editing CSS files, many other users are not.

--
Earle Martin
            http://downlode.org/
http://purl.org/net/earlemartin/


subject: [Wikitech-l] WMDumper

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

Axel Ngonga wrote:
> C:\Downloads>set
> class=mwdumper.jar;mysql-connector-java-3.0.11-stable-bin.jar
[snip]
> 1.000 pages (148,148/sec), 1.000 revs (148,148/sec)
> 2.000 pages (156,104/sec), 2.000 revs (156,104/sec)
> Exception in thread "main" java.lang.StringIndexOutOfBoundsException:
> String index out of range: -1
>         at java.lang.String.substring(Unknown Source)
>         at
> com.mysql.jdbc.EscapeProcessor.escapeSQL(EscapeProcessor.java:151)
>         at com.mysql.jdbc.Statement.execute(Statement.java:845)

I can't reproduce this problem with MySQL Connector/J 3.0.14 or 3.1.11
(java 1.5.0_06-113 on Mac OS X 10.4/Intel, tried current mwdumper build
and the snapshot on download.wikimedia.org); try grabbing 3.0.14 from
http://dev.mysql.com/.

- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF00T0wRnhpk1wk44RAhlMAJ42n0CDZOT2rzVeC7sJ54m6WOtLuwCg2MDJ
48Brgx8qdYFGHvfm9dO52SM=
=ryXB
-----END PGP SIGNATURE-----


from_name: Tim Starling

subject:
[Foundation-l] How to edit wikipedia when stupid mods block all
	Thai ip addresses

body:
Walter van Kalken wrote:
> I am getting extremely impatient with RonaldB he seems to have a fetish
> for blocking Thai IP addresses on the Dutch wikipedia and he doesn't
> answerd emails send to him. I cannot even edit when I am logged in, not
> from a friends computer which uses a different provider. Is it the
> wikimedia foundations goal to block me??
>
> The last two weeks I have found the IP adresses of my provider
> constantly blocked, pre-emptively by RonaldB without any sign of
> vandalism by those IP adresses. Wikipedia can be editted by anyone? Not
> by me!

The first time this happened, we fixed it by listing the True Internet
proxies in the trusted XFF list. True Internet have since expanded their
proxy list. A polite request to the devs to update the list would have
seen this problem fixed immediately. However, Waerth is apparently not
capable of polite requests, he only knows screaming and yelling, and I had
no desire whatsoever to put myself in the path of his tirade. But I think
this has gone on long enough. I'm going to list the extra proxies, polite
request or no.

True Internet appear to have secured their proxies properly now, denying
requests that come from outside their network. So adding them to the list
is no longer any kind of security risk for us. In time, they may even be
removed from the open proxy lists that sysops like RonaldB use as a source.

-- Tim Starling


subject: [Wikitech-l] Massive Hook Proposal

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

Jim Wilson wrote:
> function instantiate( &$request ) {
>     $uploadForm = new UploadForm($request);
>     wfRunHooks('UploadFormInstantiate', array( &$uploadForm, &$request ));
>     return $uploadForm;
> }

Well, the obvious limitation here is that you're instantiating the
object with a fixed class first. This method means you'd have to either
proxy the original object or throw it away and create a new one (hope
there's no side effects!)

Subclassing could be a nice way to do things in various circumstances,
where proxy objects are IMHO kind of ugly.

> Step 2: Replace all calls to the traditional "new Whatever($args)" with
> "Whatever::instantiate($args)".

Note that we use factory methods fairly extensively, usually with
multiple such methods.

- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF00YRwRnhpk1wk44RAvBSAJ99HbW0HJwJUJfNzcq+4VFSjsKnuQCgg0JM
CCiYNWsRi6pZIYQIB4AS28o=
=K57/
-----END PGP SIGNATURE-----


from_name: Jimmy Wales

subject: [WikiEN-l] The Age uses Wikipedia logo for Wikia

body:
Steve Bennett wrote:
> Not sure how long their front page will show this, but The Age
> newspaper (theage.com.au) is linking to a story about some
> magazine-style wikis at wikia.com with the Wikipedia logo. They do
> clarify the distinction between wikia and Wikipedia, but it's still a
> bit...odd. I wonder what it means...is the Wikipedia logo now
> associated with wikis in general?

I have my PR people at wikia complaining about this now to The Age.


subject: [Wikitech-l] Massive Hook Proposal

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

Jim Wilson wrote:
> Gotcha - so when's the submission deadline for patches to 1.10.0?

1.10 will branch from trunk in the first week of April per our quarterly
release cycle.

- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF00nwwRnhpk1wk44RAnZ6AJ0aMeWYHO0hJ/dbM+PTL1wzqnXgkgCgvBeZ
x2dU8UXm1IK2ZxDbsXvpX8M=
=KSM7
-----END PGP SIGNATURE-----


from_name: Ray Saintonge

subject:
[Foundation-l] precisions about the recent WMF "fair
	use"	decision

body:
geni wrote:

>On 2/12/07, David Strauss <david at fourkitchens.com> wrote:
>
>
>You want minimum restrictions with regard to copyright that is the
>correct course of action.
>
I agree with minimum restriction, but a move to Iran strikes me as
slightly unrealistic.

>>I'm arguing that we should weigh the advantages of accommodating foreign
>>restrictions
>>
>>
>Try again this time try not to think so americano centri
>
Some accomodation of "foreign" restrictions is necessary, but it seems
that the most retrogressive pressures are the ones that come from the
European Union.

>>U.S. centrism is borne of ignorance or willful exclusion. Neither is the
>>case here.
>>
>>
>Then try and think why when dealing with the option of moving the
>foundation to somewhere with the most liberal copyright laws on an
>international mailing list why using the term "foreign restrictions"
>isn't exactly ideal phrasing.
>
I can see where the word "foreign" leads to a number of anomalous
problems.  The location of the hardware in the United States does lead
to the natural tendency to have other laws considered foreign.  At the
same time it would be good to have a contingency plan for the location
of servers even if there is no immediately forseeable reason for
invoking that plan.  In any circumstances it would be helpful if we can
start developping more international terminology for our discussions.
Would the Berne Convention be a good starting point for this?.

Ec


subject:
[Foundation-l] precisions about the recent WMF
	"fair	use"	decision

body:
Yann Forget wrote:

>geni a ?crit :
>
>
>>So not copyright on items produced outside Iran doesn't appeal? Well
>>Ok then how about move commons to the UK? At least one type of item
>>enters the public domain there well before ti does in the US.
>>
>>
>Canada (or Australia, or South Africa) would be a better option: only 50
>years p.m.a. Next India might be interesting: 60 years p.m.a.
>
Australia went to 70 years not long ago.

Ec


from_name: Steve Bennett

subject: [WikiEN-l] Unneeded disambiguation

body:
On 2/14/07, Bogdan Giusca <liste at dapyx.com> wrote:
> Then why do we have them?

It's a good question. I used to think they were redundant, and indeed,
generally "non-ambiguous pages" like this don't have them. But now I'm
not so sure. Some reasons for having them:

- it may be useful or just interesting to know what the name is ambiguous with
- somewhat related, it helps the reader understand why there is a
slightly bizzarre name: Why "Jerry Seinfeld (character)"? Why not just
"Jerry Seinfeld"?
- it's much easier to maintain ambiguous sets when there are links
back to the disambig page
- sometimes people link to the wrong page. If there are two "Fred
Smith"s who are scientists, people may hastily link to "Fred Smith
(scientist)" and get it wrong.
- consistency

These may not be compelling reasons, but there is *some* benefit in
having the links.

Steve


subject: [WikiEN-l] Admin burnout

body:
Guy Chapman aka JzG wrote:

>One that particularly
>annoys me is the tendency to overdramatise supposed death threats and
>legal threats when the comments have no degree of credibility.  A
>credible threat of harm is bad, and reducing the currency of such by
>saying that generic "Meh!  I'll kill ya!" crap is a death threat
>(rather than just simple stupidity) does not help.
>
Whe  the expression, "I'll kill you," is used in a TV comedy nobody
seems to get upset or take it seriously.

Often some of our editors interpret much less explicit statements as
death threats or otherwise seriously offensive without recourse to any
kind of reality check.  Sometimes it seems that there are people who
thrive on being offended.

Ec


subject: [WikiEN-l] Fwd: [Foundation-l] About rumors...

body:
David Gerard wrote:

>Suggestions, anyone? en:wp is the largest project by far, hence both
>the most expensive to run and the greatest base for possible
>fundraising.
>
When a blogger makes a comment about the imminent fiscal collapse of
Wikipedia it might be good to reply with thanks for bringing public
attention to our fundraising site. ;-)

Ec


from_name: Guettarda

body:
On 2/14/07, NSLE (Wikipedia) <nsle.wikipedia at gmail.com> wrote:
>
> I'm starting to think Flameviper needs to be put on mod.

That was my thought this morning.  Too bad I wasted my one thought for the
day on something that someone else has thought of.

On 14/02/07, Flame Viper <flameviper12 at yahoo.com> wrote:
> >
> >
> > Lamest digest ever
> >
> > wikien-l-request at lists.wikimedia.org wrote: Send WikiEN-l mailing list
> > submissions to
> > wikien-l at lists.wikimedia.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > http://lists.wikimedia.org/mailman/listinfo/wikien-l
> > or, via email, send a message with subject or body 'help' to
> > wikien-l-request at lists.wikimedia.org
> >
> > You can reach the person managing the list at
> > wikien-l-owner at lists.wikimedia.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of WikiEN-l digest..."
> >
> >
> > Today's Topics:
> >
> >    1. Re: Admin burnout (deputy admins) (Thomas Dalton)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Wed, 14 Feb 2007 11:58:12 +0000
> > From: "Thomas Dalton"
> > Subject: Re: [WikiEN-l] Admin burnout (deputy admins)
> > To: "English Wikipedia"
> > Message-ID:
> >
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > > "Utopia (from Greek i.e. "no place" or "place that does not exist")"
> > > I think maybe it was a joke? A continuation of the original punning?
> > > I didn't see it as an attack, at the least.
> >
> > Ok, so that part was a pun, the rest was an ad hominem attack. He
> > referred to me multiple times and never made any mention of my
> > arguments - it's an excellent example of an ad hominem attack.
> >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > WikiEN-l mailing list
> > WikiEN-l at lists.wikimedia.org
> > To unsubscribe from this mailing list, visit:
> > http://lists.wikimedia.org/mailman/listinfo/wikien-l
> >
> >
> > End of WikiEN-l Digest, Vol 43, Issue 95
> > ****************************************
> >
> >
> >
> > ---------------------------------
> > Don't get soaked.  Take a quick peak at the forecast
> > with theYahoo! Search weather shortcut.
> > _______________________________________________
> > WikiEN-l mailing list
> > WikiEN-l at lists.wikimedia.org
> > To unsubscribe from this mailing list, visit:
> > http://lists.wikimedia.org/mailman/listinfo/wikien-l
> >
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> http://lists.wikimedia.org/mailman/listinfo/wikien-l
>


subject: [Wikitech-l] Massive Hook Proposal

body:
Thanks everyone.  My goal was to come up with a passive way to put hooks
"everywhere" - or as close to everwhere as possible.  Is there a better
solution?  I'm open to suggestions.

Also, if implemented, what version(s) should be targeted?  I'm thinking
1.8.4, 1.9.3 and 1.10.0 - your thoughts?  Is there going to be a 1.6.10 that
would benefit from this?  Thanks in advance.

-- Jim

On 2/14/07, Simetrical <Simetrical+wikilist at gmail.com> wrote:
>
> On 2/14/07, Jim Wilson <wilson.jim.r at gmail.com> wrote:
> > Dear Wiki Devs,
> >
> > I have a proposal for adding new hooks into the MW codebase, and I'm
> looking
> > for feedback (positive and negative).  The goal of the proposed changes
> is
> > to give Extension Devs the ability to cleanly hijack just about any
> class in
> > the system.  Here are the details: . . .
>
> It seems like a good idea.  It should be reverse-compatible as long as
> we don't change the public interface (well, or protected interface)
> for classes, which would generally break reverse-compatibility anyway.
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/wikitech-l
>


from_name: Jeff V. Merkey

subject:
[Foundation-l] The Communist Vandal Trashed the Dine (Navajo)
 Wikipedia

body:
Pedro Sanchez wrote:

>On 2/14/07, Jeffrey V. Merkey <jmerkey at wolfmountaingroup.com> wrote:
>
>
>>The Communist Vandal trashed the entire Dine (Navajo) Wikipedia at
>>nv.wikipedia.org sometime earlier today.
>>
>>I have reverted all of his edits -- it took a while.  He managed to
>>vandalize every single article on this wiki in a matter of minutes.
>>
>>Jeff
>>
>>_______________________________________________
>>foundation-l mailing list
>>foundation-l at lists.wikimedia.org
>>http://lists.wikimedia.org/mailman/listinfo/foundation-l
>>
>>
>>
>
>why was his block length shortened to 19 days?
>
>

This admin, Node ue, has been placing spamming links to their personal
email address. They changed it from an indefinite block due to ignorance.
I reinstated the indefinte block. Node ue placed spamming links into the
site notice as well. I reverted these as well.

Jeff

>_______________________________________________
>foundation-l mailing list
>foundation-l at lists.wikimedia.org
>http://lists.wikimedia.org/mailman/listinfo/foundation-l
>
>
>


subject: [WikiEN-l] Admin burnout

body:
Jeff Raymond wrote:

>>Guy Chapman aka JzG wrote:
>>
>>
>>>Ultimately the only way to fix this is probably to be more willing to
>>>
>>>chuck out people who resolutely refuse to follow policy.
>>>
>>>
>Do you know exactly how many admins that would encompass?
>
We have no way of knowing.  This sort of thing is often based on
inconsistent and changing policy, applied by inconsistent admins with
varying attitudes about how punitive they can or should be.

I have no problem with chucking out problem admins, including ones who
consistently block people for a month when policy calls for a 24-hour
block for the offense in question.

Ec


subject: [WikiEN-l] Unneeded disambiguation

body:
On 2/14/07, MacGyverMagic/Mgm <macgyvermagic at gmail.com> wrote:
> Ah, now I know what you mean, you are talking about the duplication in the
> notices.

Is he? I think he's saying that it makes sense that [[Barrel]] links
to [[Barrel (disambiguation)]], that [[Barrel (disambiguation)]] links
to [[Barrel (unit)]], but that there's no need to link from [[Barrel
(unit)]] back to [[Barrel (disambiguation)]].

I believe that the general pattern is for *those* links to not be
added, but I could be wrong.

Steve


from_name: Simetrical

subject: [Wikitech-l] Wikitech-l Digest, Vol 43, Issue 25

body:
On 2/14/07, Chuck Smith <chuckssmith at gmail.com> wrote:
> Another benefit of changing the double single quotes and triple single
> quotes to // and ** respectively is that it would be a small step to
> making MediaWiki markup more Creole-compatible (www.wikicreole.org).
> Also, it seems like a conversion script for just these two elements
> would not be that difficult to write.  What could be potential
> complications?

In terms of the pure syntax?

1) C++-style comments use //.
2) URLs use // (and probably not all will be linked).
3) Lists use **.
4) ** is often used for footnote-style things, once * has been used
(although this usage may not be common on WMF projects).
5) Probably there are some weird languages out there that use these somehow.

All of those are, however, fairly easily surmountable with a
well-designed initial pass to clean them up (nowikiing where needed,
adding spaces after line-initial ** outside of nowiki/pre, flagging
URL-y things to be looked at), at least in theory.  The basic problem
is, as Christopher says, getting users who are used to '''? to start
using (**|//).  It would be frustrating, and we'd get invalid markup
being put into articles regularly for months.  And what would the
benefit be?  Putting a Band-Aid on a missing limb of parseability?
Compatibility with wikisyntax that we definitely don't need and that
none of our import sources use?  Not worth it, not by a long shot.


subject: [WikiEN-l] Help with Admin Burnout - 2

body:
Marc Riddell wrote:

>To any & all,
>
>I am doing some thinking about how the WP Community could help Admins who
>are struggling with the work. My goal is to come up with a formal mechanism
>that these Admins can turn to for help and support before they choose to
>simply give up and leave the Community. It could serve as a form of
>intervention before a burnout occurs.
>
>What are your thoughts about this?
>
What this probably needs is a "Father Confessor" type of person that
stressed out admins can go to privately when they have a problem.  Such
persons need to appreciate confidentiality and be non-judgemental.

Ec


body:
Rich Holton wrote:

>geni wrote:
>
>
>>On 2/12/07, Marc Riddell wrote:
>>
>>
>>>on 2/12/07 6:19 AM, Cool Cat wrote:
>>>
>>>
>>>>Perhaps a wikiproject regulating categories might not be a bad idea.
>>>>
>>>>
>>>Sounds like a great idea. I'd be one of the first in line to sign on.
>>>
>>>
>>When trying to sort out our images and their copyright status I would
>>rather not have to submit every category I find myself needed to a
>>bunch of self appointed busy bodies who are unlikely to know much more
>>about copyright than the average wikipedian.
>>
>>The stubs wikiproject works because the vast majority of people who
>>are interested in new stubs and stub sorting are part of the project.
>>That would not be the case with a categories wikiproject.
>>
>>
>Do you know, Geni, that sometimes you project a fairly abrasive attitude?
>
He does, but less so than when he first appeared.  Maybe being on this
mailing list has had a therapeutic effect. ;-)

Ec


from_name: Chuck Smith

body:
> Actually, // and ** are at least as clear, and are most definitely
> parsable by a fixed-lookahead context-free grammar - even an unaugmented
> LL(k) grammar could probably handle it. <i> and <b> are unambiguous, but
> ugly and language-dependent. MediaWiki's current behavior "fixes" many
> of the issues with its ambiguous bold/italics representation with little
> ad-hoc DWIM-type behavior. It works, but cannot be represented by a CFG
> and is difficult to extend.

Another benefit of changing the double single quotes and triple single
quotes to // and ** respectively is that it would be a small step to
making MediaWiki markup more Creole-compatible (www.wikicreole.org).
Also, it seems like a conversion script for just these two elements
would not be that difficult to write.  What could be potential
complications?

Chuck


subject: [WikiEN-l] Admin burnout

body:
Stephen Bain wrote:

>On 2/12/07, Guy Chapman aka JzG <guy.chapman at spamcop.net> wrote:
>
>
>>So what if he's the most inclusionist inclusionist on the
>>project?  If we allow republicans to be sysops we should allow
>>inclusionists :-)
>>
>>
>The "community" only wants admins who will delete whatever they decide
>to put into [[CAT:CSD]].
>
>
>>Others who should have been promoted but were not for ridiculous
>>reasons include Stephen B Streater and Georgewilliamherbert.
>>
>>
>This sounded like a good idea to me before, but I wouldn't be
>surprised if I'm hounded down as a cabalist: how about if any X number
>of admins think someone should have the mop, then that person gets the
>mop on a trial basis for Y amount of time, perhaps with a regular RFA
>at the end of the trial period. Adjust X and Y to taste.
>
I have no problem with bureaucrats who use common sense to override a
negative RfA result.

Ec


subject: [WikiEN-l] Unneeded disambiguation

body:
On 2/14/07, Thomas Dalton <thomas.dalton at gmail.com> wrote:
> I think an "Other uses of X" link is a good thing, but it should
> probably come under See Also, rather than at the top.

Nice compromise. I like it.

Steve


from_name: Gregory Maxwell

body:
On 2/14/07, Husky <huskyr at gmail.com> wrote:

> I'm not a brilliant programmer, but isn't it simply a case of
> 1) having an array with all possible (or at least, the most popular)
> licenses and their template tags

This is hard because you have to first make the list.. And you have to
deal with examples like the {{PD-CAGov that}} I listed, and
{{GFDL-joeblow}} (personal license templates).  The list of license
templates are growing every day.

> 2) parsing all {{template}} tags

Thats not enough because people often use licenses through wrapper templates..

{{self|GFDL|cc-by-sa-2.0}}
{{self2|GFDL|cc-by-sa-2.0}}
{{template2|..

There are a whole bunch, they change too.. and you have to track them down.

> 3) matching the template tags with the licenses array and using that to
> display the license in the Mayflower results screen?

Because there are so many different minor permutations, even if you
could extract all the licenses, figuring out the mapping to something
small enough to put in the interface is a challenge alone.


subject: [Wikitech-l] Massive Hook Proposal

body:
On 2/14/07, Jim Wilson <wilson.jim.r at gmail.com> wrote:
> Dear Wiki Devs,
>
> I have a proposal for adding new hooks into the MW codebase, and I'm looking
> for feedback (positive and negative).  The goal of the proposed changes is
> to give Extension Devs the ability to cleanly hijack just about any class in
> the system.  Here are the details: . . .

It seems like a good idea.  It should be reverse-compatible as long as
we don't change the public interface (well, or protected interface)
for classes, which would generally break reverse-compatibility anyway.


list: wikipedia-l

from_name: Lars Aronsson

subject:
[Wikipedia-l] [Foundation-l] How to edit wikipedia when stupid
 mods block all Thai ip addresses

body:
Walter van Kalken wrote:

> This is about the 4th or 5th time in a year that this is
> happening so may I be tat pissed of. and in all those times I
> can only remember you as the least co-operative of all and the
> most aggressive.

Walter, we all have our problems every now and then, but it's
always you that are pissed off and express yourself in a rude
manner.  Does it help you?  It doesn't really help me.

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


from_name: Deathphoenix

subject: [WikiEN-l] An idea for deletions

body:
On 2/14/07, Thomas Dalton <thomas.dalton at gmail.com> wrote:
>
> > It would be a hell of a lot easier if there was just a
> > "Suggest this article for deletion" button on every article, that
> > would walk the user through a deletion wizard like you describe.
>
> I have a worrying feeling that would be spammed by nonsense requests
> too often to be useful...
>

The "deletion preview team" would be able to weed out those ones.


from_name: Husky

body:
On 2/14/07, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>
> PD! Sure lets just use the template links table to find all the images
> that transclude a template that starts with PD- ... Such as...
> {{PD-CAGov}} (http://commons.wikimedia.org/wiki/Template:PD-CAGov)
>
> Hard problem. :(
>
> Even our most machine readable metadata isn't very machine readable. :(

I'm not a brilliant programmer, but isn't it simply a case of
1) having an array with all possible (or at least, the most popular)
licenses and their template tags
2) parsing all {{template}} tags
3) matching the template tags with the licenses array and using that to
display the license in the Mayflower results screen?

-- Hay Kranen / [[User:Husky]]


from_name: George Herbert

body:
On 2/14/07, Tuvic <tuvic.tuvic at gmail.com> wrote:
> As did he, now placing it back in the sitenotice.
>
> 2007/2/14, Jeff V. Merkey <jmerkey at wolfmountaingroup.com>:
> > Pedro Sanchez wrote:
> >
> > >On 2/14/07, Jeffrey V. Merkey <jmerkey at wolfmountaingroup.com> wrote:
> > >
> > >
> > >>The Communist Vandal trashed the entire Dine (Navajo) Wikipedia at
> > >>nv.wikipedia.org sometime earlier today.
> > >>
> > >>I have reverted all of his edits -- it took a while.  He managed to
> > >>vandalize every single article on this wiki in a matter of minutes.
> > >>
> > >>Jeff
> > >>
> > >>_______________________________________________
> > >>foundation-l mailing list
> > >>foundation-l at lists.wikimedia.org
> > >>http://lists.wikimedia.org/mailman/listinfo/foundation-l
> > >>
> > >>
> > >>
> > >
> > >why was his block length shortened to 19 days?
> > >
> > >
> >
> > This admin, Node ue, has been placing spamming links to their personal
> > email address. They changed it from an indefinite block due to ignorance.
> > I reinstated the indefinte block. Node ue placed spamming links into the
> > site notice as well. I reverted these as well.
> >
> > Jeff

Jeff and Node ue are the only two sysops on that wiki; can a Steward
apply attention?  This is very worrysome to me...

--
-george william herbert
george.herbert at gmail.com


subject: [WikiEN-l] Your comments on wikien-l regarding adminship

body:
Thomas Dalton wrote:

>>Choosing a first random batch of 100, and reporting after 3 months about
>>what happened to this group would support the radical concept of basing
>>later choices on facts.  Thus:
>>    1. How many refused the nomination outright? (This group could be
>>immediately replaced by new nominations.)
>>    2. How many went nuts?
>>    3. How many stopped editing within 1 month and within 2 months?
>>    4. How many continued editing without using admin powers?
>>    5. Which admin powers did they use?
>>    6. other questions?
>>
>>
>6. How many people that didn't get chosen complained loudly about/left
>completely because of/started vandalising in revenge of the unfair way
>admins were chosen?
>
I get the impression that you completely misconceive the idea of
statistical sampling.

Ec


from_name: Jim Wilson

subject: [Wikitech-l] Massive Hook Proposal

body:
Gotcha - so when's the submission deadline for patches to 1.10.0?

On 2/14/07, Brion Vibber <brion at pobox.com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jim Wilson wrote:
> > Also, if implemented, what version(s) should be targeted?  I'm thinking
> > 1.8.4, 1.9.3 and 1.10.0 - your thoughts?  Is there going to be a 1.6.10that
> > would benefit from this?  Thanks in advance.
>
> Massive far-reaching changes like that would never ever go into
> maintenance releases of old versions.
>
> Is it a security fix? no.
>
> Is it a vital bug fix necessary for the software to run? no.
>
> - -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFF00FBwRnhpk1wk44RAt4SAJ9h7hXhpPDuiYAVcjYxgT9U2aVAcQCfVGIk
> aEny2OzSpT90Kem/KWmm+pY=
> =S60U
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/wikitech-l
>


from_name: christoph.huesler at css.ch

subject: [Wikitech-l] Antwort: Re:  Wikitech-l Digest, Vol 43, Issue 25

body:
wikitech-l-bounces at lists.wikimedia.org schrieb am 14.02.2007 10:42:47:

> > Actually, // and ** are at least as clear, and are most definitely
> > parsable by a fixed-lookahead context-free grammar - even an
unaugmented
> > LL(k) grammar could probably handle it. <i> and <b> are unambiguous,
but
> > ugly and language-dependent. MediaWiki's current behavior "fixes" many
> > of the issues with its ambiguous bold/italics representation with
little
> > ad-hoc DWIM-type behavior. It works, but cannot be represented by a
CFG
> > and is difficult to extend.
>
> Another benefit of changing the double single quotes and triple single
> quotes to // and ** respectively is that it would be a small step to
> making MediaWiki markup more Creole-compatible (www.wikicreole.org).
> Also, it seems like a conversion script for just these two elements
> would not be that difficult to write.  What could be potential
> complications?

The users.


from_name: Brion Vibber

subject:
[Wikitech-l] [MediaWiki-CVS] SVN: [19930]
	tags/REL1_9_2/phase3/includes

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

Rob Church wrote:
>>     tags/REL1_8_3/phase3/includes/DatabasePostgres.php
>>     tags/REL1_9_2/phase3/includes/DatabasePostgres.php
>
> WTF?
>
> *No one* except the release manager is supposed to alter *tags*, ever.
> If code *has* to be backported, then it gets backported to a branch.

Have reverted them.

For reference, Subversion doesn't have "tags" in the sense that CVS
does; to create an easily-referenced "tag" for a particular state of the
code you clone a directory in the same was as you create a branch.

The good thing is this gives warm fuzzy feelings for being a clever
implementation.

The bad thing is that the tagged version can still be changed, which
makes things potentially a bit confusing. They need to be left intact so
that we can continue to pull past revisions out of the repository for
reference, reproduction of bugs, etc.

Apply fixes for release branches only in the *branch* directories, eg
branches/REL1_8 and branches/REL1_9. New tag snapshots will be copied
off of the branch directories at the next release.

- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF02ebwRnhpk1wk44RAqQhAJ9ZbpB0g1TpKci+vcNm4jIWPTxNcgCgzPGf
pnu9LMBud5Ev0iIPBhKsjME=
=jebl
-----END PGP SIGNATURE-----


subject: [Wikitech-l] Massive Hook Proposal

body:
Thanks Brion,

> Well, the obvious limitation here is that you're instantiating the
> object with a fixed class first. This method means you'd have to either
> proxy the original object or throw it away and create a new one (hope
> there's no side effects!)

How do you feel about this alternative? (continuing the UploadForm example):

function instantiate( &$request ) {
    $uploadForm = NULL;
    wfRunHooks('BeforeInstantiate_UploadForm', array( &$uploadForm,
&$request ));
    if ($uploadForm != NULL) {
        return $uploadForm;
    }
    $uploadForm = new UploadForm($request);
    wfRunHooks('AfterInstantiate_UploadForm', array( &$uploadForm, &$request
));
    return $uploadForm;
}

> Subclassing could be a nice way to do things in various circumstances,
> where proxy objects are IMHO kind of ugly.

I also like the idea of Subclassing.  Could you expand on what you mean by
proxy objects in this context?  Perhaps with an example?

> Note that we use factory methods fairly extensively, usually with
> multiple such methods.

Right right - such as "Title::newFromDBkey()", which in turn calls "new
Title()" internally.  By replacing this internal call with another factory
method such as "Title::instantiate()", we still give extension devs a chance
to hijack it.

Thanks again for the feedback - I really appreciate your comments.

At the current time there is a class of problems that can only be solved by
hacking the source - as used to be the case for Semantic MW.  Of course,
increasing the volume of wfRunHooks calls will help to reduce the problem
space (as was the case for Semantic).

As people want to do more with MW as a development platform, the number of
use-cases increases, and I hope we can find a way to blow the API wide open
to make nearly any modification possible, without resorting to hacking the
core code.

Thanks again,

Jim

On 2/14/07, Brion Vibber <brion at pobox.com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jim Wilson wrote:
> > Gotcha - so when's the submission deadline for patches to 1.10.0?
>
> 1.10 will branch from trunk in the first week of April per our quarterly
> release cycle.
>
> - -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFF00nwwRnhpk1wk44RAnZ6AJ0aMeWYHO0hJ/dbM+PTL1wzqnXgkgCgvBeZ
> x2dU8UXm1IK2ZxDbsXvpX8M=
> =KSM7
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/wikitech-l
>


from_name: Steve Sanbeg

subject: [Wikitech-l] Exporting sections of pages

body:
In the labeled section transclusion extension (written for wikisource, but
not installed yet) sections are transcluded by name, either using the
heading, or a special <section> marker; transclusion by heading is
optional, since it could be more more prone to breakage (i.e. renaming a
header), and it's less obvious exactly what needs to be included.

Wictionary could probably leverage this type of mechanism, similarly to
the way the DPL extension does, by calling LST functions to get the
sections.

 On Wed, 14 Feb 2007 12:09:29 +0100, Bryan Tong Minh wrote:
> If we want sections to be transcludable, we need to address them by name
> and not by number, because adding a header might cause an other section
> to be included.
>
> Bryan
>
> On 2/14/07, Andrew Dunbar
> <hippytrail at gmail.com> wrote:
>> Wiktionary's case is a bit easier because we don't need to transclude
>> sections but merely make them accessible to MediaWiki extensions
>> written in PHP.
>>
>> For instance most users don't care about translations so that section
>> would not be displayed by default unless enabled in preferences.
>>
>> A good incremental design path might be 1: wrap sections/subsections in
>> DIVs 2: provide section/subsection APIs for extensions. 3: make
>> sections transcludable.
>>
>> Andrew Dunbar (hippietrail)
>>
>>
>> On 2/14/07, Steve Bennett
>> <stevagewp at gmail.com> wrote:
>> > On 2/14/07, Jay R. Ashworth
>> > <jra at baylink.com> wrote:
>> > > Well, my snap reaction is 'microformats'.
>> >
>> > Say what?
>> >
>> > > I think that there should be some way (and perhaps this is as easy
>> > > as puting an "<a href="thisisatag"> link in after the section
>> > > header.
>> > >
>> > > Isn't there some pipe-y syntax that already does something akin to
>> > > this and tracks the section header?
>> >
>> > Yeah, I was wondering that. Something like this might work: ==List of
>> > highways|List==
>> >
>> > Where "List" is a code. Alternatively, and imho more readably: ==List
>> > of highways==
>> > {{SECTION|List}}
>> >
>> > Steve
>> >
>> > _______________________________________________ Wikitech-l mailing
>> > list
>> > Wikitech-l at lists.wikimedia.org
>> > http://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> >
>> >
>> >
>> --
>> http://linguaphile.sf.net
>>
>> _______________________________________________ Wikitech-l mailing list
>> Wikitech-l at lists.wikimedia.org
>> http://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>


from_name: Thomas Dalton

subject: [WikiEN-l] Admin burnout (deputy admins)

body:
> "Utopia (from Greek i.e. "no place" or "place that does not exist")"
> I think maybe it was a joke? A continuation of the original punning?
> I didn't see it as an attack, at the least.

Ok, so that part was a pun, the rest was an ad hominem attack. He
referred to me multiple times and never made any mention of my
arguments - it's an excellent example of an ad hominem attack.


from_name: Luna

body:
On 2/14/07, Timwi <timwi at gmx.net> wrote:
>
> There is no reason to
> believe that Wikipedia has now reached a perfect state and requires no
> further changes to the way it works.

True, but that doesn't even come close to implying that this particular
crazy idea should be implemented. I concur completely with the need for
*some* users with a higher access level. I can revert, warn, block, and
clean up after a dozen vandals in an hour, but suppose just one of them
suddenly has admin capabilities and blocks me? What's the line of defense,
then? What's the line of defense when somebody lines up 20-30 admin socks,
blocking and desysopping everyone in sight, resysopping each other and
retaliating when anyone tries to stop them? You would need -- literally
*need* -- somebody with a higher access level. Whether that implies adding
more bcrats, a level between admin and bcrat, I don't know, but unless and
until you add that provision, this sounds mostly like a suicide pact.

Which isn't to say that I don't appreciate the discussion. Ideas are
valuable, especially the original ones.

-Luna


from_name: Andrew Gray

body:
On 14/02/07, Gerard Meijssen <gerard.meijssen at gmail.com> wrote:
> Hoi,
> There are quite a few sound files and there will be many more given that
> some great functionality is developed in the "Shtooka" software. The
> notion that these files are not desperately useful for some.. is also
> true the other way around. For some the images are not desperately
> useful and it is the sound files that are of interest.

Hey, I didn't say "stop displaying them", I said "make it disableable" ;-)

[Most people doing a commons search are likely looking for images
only; I suspect a large fraction of the rest are looking for
non-images only. I wonder how many are intentionally looking for a
mixture...]

Making this more fine-grained would be interesting, too - restrict by
"image", and then provide the option to restrict by filetype. Hmmm.

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


from_name: Bryan Tong Minh

body:
If we want sections to be transcludable, we need to address them by
name and not by number, because adding a header might cause an other
section to be included.

Bryan

On 2/14/07, Andrew Dunbar <hippytrail at gmail.com> wrote:
> Wiktionary's case is a bit easier because we don't need to transclude sections
> but merely make them accessible to MediaWiki extensions written in PHP.
>
> For instance most users don't care about translations so that section
> would not be displayed by default unless enabled in preferences.
>
> A good incremental design path might be 1: wrap sections/subsections
> in DIVs 2: provide section/subsection APIs for extensions. 3: make
> sections transcludable.
>
> Andrew Dunbar (hippietrail)
>
>
> On 2/14/07, Steve Bennett <stevagewp at gmail.com> wrote:
> > On 2/14/07, Jay R. Ashworth <jra at baylink.com> wrote:
> > > Well, my snap reaction is 'microformats'.
> >
> > Say what?
> >
> > > I think that there should be some way (and perhaps this is as easy as
> > > puting an "<a href="thisisatag"> link in after the section header.
> > >
> > > Isn't there some pipe-y syntax that already does something akin to this
> > > and tracks the section header?
> >
> > Yeah, I was wondering that. Something like this might work:
> > ==List of highways|List==
> >
> > Where "List" is a code. Alternatively, and imho more readably:
> > ==List of highways==
> > {{SECTION|List}}
> >
> > Steve
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l at lists.wikimedia.org
> > http://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
>
> --
> http://linguaphile.sf.net
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/wikitech-l
>


subject: [WikiEN-l] An idea for deletions

body:
On 2/14/07, Thomas Dalton <thomas.dalton at gmail.com> wrote:

> I have a worrying feeling that would be spammed by nonsense requests
> too often to be useful...

That would be a problem; I'm not sure how big of one. Unblock-en-l gets
plenty of spam, but posts by non-subscribed emails require approval before
getting sent out, so even despite the 10:1 noise-to-signal ratio, the list
still functions. From what I hear, the other WMF mailing lists are a bit
similar in that regard.

Unless you were thinking more of "Please delete [[Martin Luther King, Jr.]]
because it sux lol," (or slightly less obvious nonsense), which might still
be a problem. CSD is hard to keep on top of. Prod seems to get around
100-200 pages daily, AfD is similar. Merging all that onto a mailing list
would be very, very busy. Unless, of course, this mailing list is only for
the people who *don't* know our deletion process, which would reduce the
load on the list a bit. At that point, it might be worth exploring.

Or perhaps we could have a more obvious "report a problem with this
article," link. I suppose that would have to go to OTRS, given the wide
variety and occassional sensitive nature of the emails such a link would
surely generate.

Just rambling,
-Luna


subject: [WikiEN-l] An idea for deletions

body:
> It would be a hell of a lot easier if there was just a
> "Suggest this article for deletion" button on every article, that
> would walk the user through a deletion wizard like you describe.

I have a worrying feeling that would be spammed by nonsense requests
too often to be useful...


from_name: Steve Bennett

body:
Not sure how long their front page will show this, but The Age
newspaper (theage.com.au) is linking to a story about some
magazine-style wikis at wikia.com with the Wikipedia logo. They do
clarify the distinction between wikia and Wikipedia, but it's still a
bit...odd. I wonder what it means...is the Wikipedia logo now
associated with wikis in general?

Steve


body:
On 2/14/07, charles.r.matthews at ntlworld.com
<charles.r.matthews at ntlworld.com> wrote:
> Well, categories should be verifiable. If not verifiable, the category itself is at fault, I think. [[Category:Guitarists influenced by Jimi Hendrix]] we can do without.

Influences can be verifiable. See
http://en.wikipedia.org/wiki/Queen_%28band%29#Influence_on_other_musicians

Steve


from_name: Jeff V. Merkey

body:
Tuvic wrote:

>As did he, now placing it back in the sitenotice.
>
>

Fixed. I pointed it to the community portal, where it belongs.

Jeff

>2007/2/14, Jeff V. Merkey <jmerkey at wolfmountaingroup.com>:
>
>
>>Pedro Sanchez wrote:
>>
>>
>>
>>>On 2/14/07, Jeffrey V. Merkey <jmerkey at wolfmountaingroup.com> wrote:
>>>
>>>
>>>
>>>
>>>>The Communist Vandal trashed the entire Dine (Navajo) Wikipedia at
>>>>nv.wikipedia.org sometime earlier today.
>>>>
>>>>I have reverted all of his edits -- it took a while.  He managed to
>>>>vandalize every single article on this wiki in a matter of minutes.
>>>>
>>>>Jeff
>>>>
>>>>_______________________________________________
>>>>foundation-l mailing list
>>>>foundation-l at lists.wikimedia.org
>>>>http://lists.wikimedia.org/mailman/listinfo/foundation-l
>>>>
>>>>
>>>>
>>>>
>>>>
>>>why was his block length shortened to 19 days?
>>>
>>>
>>>
>>>
>>This admin, Node ue, has been placing spamming links to their personal
>>email address. They changed it from an indefinite block due to ignorance.
>>I reinstated the indefinte block. Node ue placed spamming links into the
>>site notice as well. I reverted these as well.
>>
>>Jeff
>>
>>
>>
>>>_______________________________________________
>>>foundation-l mailing list
>>>foundation-l at lists.wikimedia.org
>>>http://lists.wikimedia.org/mailman/listinfo/foundation-l
>>>
>>>
>>>
>>>
>>>
>>_______________________________________________
>>foundation-l mailing list
>>foundation-l at lists.wikimedia.org
>>http://lists.wikimedia.org/mailman/listinfo/foundation-l
>>
>>
>>
>
>_______________________________________________
>foundation-l mailing list
>foundation-l at lists.wikimedia.org
>http://lists.wikimedia.org/mailman/listinfo/foundation-l
>
>
>


from_name: Ray Saintonge

subject: [WikiEN-l] Allowed use of list email addresses

body:
Gary Kirk wrote:

>Did anyone else receive an email recently with the subject
>''Requesting to make comments for e-learning wiki''? I did, from a
>student in Thailand, and I found it rather rude. Surely people are not
>supposed to randomly grab addresses from mailing lists they subscribe
>to?
>
>
I received it, but didn't find him to be particularly rude in his request.

Ec


from_name: Frazer Kirkman

subject: [Foundation-l] MediaWiki Server

body:
Greetings.
   My associates and I are looking to build a new Wiki using MediaWiki.
We are looking to have lots of audio and video content.
I was hoping you could suggest servers which are optimized for this purpose.
I am particularly concerned with the expandability.

Do the MediaWiki servers serve other projects, or can you suggest any
servers are being used by other MediaWiki sites?
If not, are there any considerations we need to be aware of for deciding
on for supplying good performance for MediaWiki?

Thank you

    Frazer Kirkman


subject: [Foundation-l] MediaWiki Server


subject: [WikiEN-l] An idea for deletions

body:
On 2/14/07, Ron Ritzman <ritzman at gmail.com> wrote:
> Just an idea I have been bouncing around for deletion nominations.
>
> If a user, any user either with an account or anonymous wants to
> nominate an article for deletion. Instead of posting directly to AFD,
> he instead enters the name of the article and the reason he thinks it
> needs to be deleted into a web form. The nomination then goes to a
> "deletion preview" team who can take one of several actions...

This looks like a step in the right direction. Wikipedia (or really,
MediaWiki) has very few "procedural" links in its interface. It takes
a lot of knowledge to know that you should type "WP:AFD" in the search
box, then follow further, fairly intricate and error-prone
instructions. It would be a hell of a lot easier if there was just a
"Suggest this article for deletion" button on every article, that
would walk the user through a deletion wizard like you describe.

A whole menu of buttons at the top or bottom of each article would be useful:
- Suggest this article for deletion
- Report a problem with this article (discussed several months ago)
- Edit this article (for consistency)
- Recategorise this article (another new front end to categories,
possibly with commonsenes?)
- Suggest a new article (a front-end to WP:AFC)
- Make a donation (why not :))

General theme: "What do you want to do" links in addition to the
current "What do you want to know" links.

Steve


subject: [WikiEN-l] "About Wikipedia" in navigation sidebar

body:
On 2/11/07, William Pietri <william at scissor.com> wrote:
> I think they're all plausible suggestions, and I like most of them,
> especially renaming the community portal and making the printable
> version a tab or something else up at the top. I personally would keep
> "Recent changes", as it demonstrates to newbies that people can make
> things happen.
>
> At least in my professional life, I'd user-test all of the suggestions
> to see how they play in Peoria. Then the ones that passed that I'd to
> A/B testing with a modest percent of the traffic to see which ones were
> clearly better by the numbers.

I'd be wary of applying the results of testing on smaller wikis
directly to Wikipedia. In this case, "Recent changes" probably
performs much better on smaller wikis.

> Historically, are either of those things done with Wikipedia?

Usability testing on Wikipedia? Not that I know of.

Steve


body:
On 2/14/07, Bryan Derksen <bryan.derksen at shaw.ca> wrote:
> On a serious note, though, I happen to use the Classic skin as my
> default and I don't have any problem with this at all. If this sort of
> thing _was_ sufficiently annoying to me I could put "#catlinks
> {display:none}" in my custom CSS like what I did to get rid of the stub
> templates, or just switch to one of the other skins that puts the
> catlinks at the bottom. Wikipedia's display format is highly
> configurable so I don't consider this to be a paprticularly strong
> example of "harm".

Yeah, there are certainly GUI issues, but the semantic markup is itself useful.

Perhaps we could make use of another way of tagging articles: with
templates. Or use some ingenuity to solve the problem by other means.

Steve


body:
Walter van Kalken wrote:

>Mark Williamson wrote:
>
>
>>Hi,
>>
>>[[WP:NPA]] -- you're not going to get anyone's sympathy nor their
>>attention if you call people stupid.
>>[[WP:OWN]] -- you don't own any of the articles you wrote. You gave up
>>all rights to the text when you submitted them to Wikipedia. They will
>>not be deleted.
>>
>>
>I would like to see how that would stand up in a court if wikipedia is
>denying me access without a valid reason (not a vandal etc).
>
I'm sure you know what you can do to test your hypothesis.

Ec


references:
<mailman.34414.1149630568.4497.wikitech-l@wikimedia.org>
	<20070213211417.9519.qmail@web26611.mail.ukl.yahoo.com>
	<eqtd9t$qqt$1@sea.gmane.org>

body:
Perhaps the "section=" parameter could work for viewing as well as editing:
http://en.wikipedia.org/w/index.php?title=Bundesautobahn_1&action=view&section=3

With section preview on you effectively can view just one section, but
you get the edit box as well.

Steve

On 2/14/07, Platonides <Platonides at gmail.com> wrote:
> Claudi Meneghin wrote:
> > Hi all,
> > is there a way to export section of articles by the 'special:export' feature, please?
> Special:Export doesn't allow section-exporting. Plus, MediaWiki doesn't
> choose sections by name, but for number.
>
> You can browse to teh article, click the section edit and copy&paste. Or
> you could make a script to strip everything from the article but the
> Exit list section.
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/wikitech-l
>


from_name: charles.r.matthews at ntlworld.com

body:
Michael Snow wrote

> Steve Bennett wrote:
>
> > On 2/14/07, charles.r.matthews at ntlworld.com
> > <charles.r.matthews at ntlworld.com> wrote:
> >
> >> Well, categories should be verifiable. If not verifiable, the
> >> category itself is at fault, I think. [[Category:Guitarists
> >> influenced by Jimi Hendrix]] we can do without.
> >
> > Influences can be verifiable. See
> > http://en.wikipedia.org/wiki/Queen_%28band%29#Influence_on_other_musicians
> >
>
> Perhaps he meant the problem was that you'd arguably have to include
> every rock guitarist since 1969 in the category.

We can say in an article that, for example, Prince is influenced by Hendrix, if there is a decent quote from Prince saying exactly that. Otherwise it is a silly category to have there; and in fact pretty much redundant since you'd have to discuss it explicitly anyway. People sneaking in their own opinions as categorisations is a no-no.

Charles

-----------------------------------------
Email sent from www.virginmedia.com/email
Virus-checked using McAfee(R) Software and scanned for spam


from_name: Mark Clements

subject: [Wikitech-l] Massive Hook Proposal

body:
"Jim Wilson" <wilson.jim.r at gmail.com> wrote in
message news:ac08e8d0702140532sdd74668u487a6aeab0eaa35e at mail.gmail.com...
> Dear Wiki Devs,
>
> I have a proposal for adding new hooks into the MW codebase, and I'm
looking
> for feedback (positive and negative).  The goal of the proposed changes is
> to give Extension Devs the ability to cleanly hijack just about any class
in
> the system.  Here are the details:
>
[SNIP]
> --------------------------------------------------------------
> class UploadForm {
>
> // ...
>
> function instantiate( &$request ) {
>     $uploadForm = new UploadForm($request);
>     wfRunHooks('UploadFormInstantiate', array( &$uploadForm, &$request ));
>     return $uploadForm;
> }
> --------------------------------------------------------------
[SNIP]
> What do you think?  I'm genuinely interested in hearing what everyone has
to
> say.  Thanks!

No real comment on the idea at the moment, except that it might be better to
use "Instantiate_ClassName" as the hook, so that they can be easily grouped
in documentation, or referred to as "Instantiate_*" hooks.  It also clearer
what the hook does if you come across one you haven't seen before, I think.

- Mark Clements (HappyDog)


subject: [WikiEN-l] Category:Jews -> Category:Jewsih people

body:
On 2/14/07, Cool Cat <wikipedia.kawaii.neko at gmail.com> wrote:
> Was there ever a discussion on why we should categorize African Americans
> and Danish Americans differently? What role does ones ethnicity play in
> fields of science for example?

Um, Africa isn't a country.

Steve


from_name: Brianna Laugher

subject: [Foundation-l] Mayflower: Wikimedia Commons media search

references:
<280A126F-DB3B-4709-BF83-5CB7EACE3FC2@wikignome.net>
	<eqtcn0$nlr$1@sea.gmane.org>
	<e692861c0702131412o51e4ecal1a99e2d4e3ce5f4f@mail.gmail.com>
	<85f46e6f0702131531x53c9c3e0na6d4caa6ff9f31f7@mail.gmail.com>

body:
On 14/02/07, Husky <huskyr at gmail.com> wrote:
> Wow, this is really good! I can finally find something on Commons without
> having to click trough a list of images or browsing categories :)
>
> Just some small recommendations:
> * I would give the 'x results found' a colourful background (maybe purple)
> to separate the search box from the thumbnail view. You could also move the
> search box to the right of the logo and use the dotted grey bar as a
> separator.
> * Having the license beneath the image would be very handy. Even more handy
> would be an option to do an 'advanced search' for a specific license (e.g.
> only PD images)
> * Maybe the colours should be a little more Wikimedia-like (green, blue,
> red) and the imagery could be more related to Wikimedia Commons to refer to
> the connection between the two. I attached an example logo (just an idea).
>
> Anyway, great job! With some more work Mayflower could be a great
> replacement for the current Commons search.

I suspect it would already be vastly more useful to our average user
than our default search :P

Yeah, I would put a by-line that says something like 'Search a
database of over one million <b>freely licensed</b> media files'. This
can be a great way to introduce non-Wikimedia people to Commons.

As a couple of people have commented, distinguishing between
images/sound/documents would be useful too.

Anyway -- fantastic work, Tangotango! It looks fabulous and we will
push it hard at Commons. And when you want some help developing that
MediaWiki extension, well, you know where to find me :)

cheers,
Brianna


body:
On 2/14/07, Simetrical <Simetrical+wikilist at gmail.com> wrote:
> Interesting idea.  We could have an option to make the TOC be real
> links, too, not just anchors.

Yeah, and as an option, a [view] link next to the [edit] link.

Steve


body:
On 2/14/07, Steve Bennett <stevagewp at gmail.com> wrote:
> Yeah, and as an option, a [view] link next to the [edit] link.

Or perhaps [print], since that would probably be the use for it.

Steve


body:
"Steve Bennett" wrote

>They do
> clarify the distinction between wikia and Wikipedia, but it's still a
> bit...odd. I wonder what it means...is the Wikipedia logo now
> associated with wikis in general?

I think it means that newpapers sometimes lack professionalism. I can't think how many times I've been annoyed to see a factual story illustrated by a still from a vaguely related Hollywood film, on tenuous thematic grounds.

Charles

-----------------------------------------
Email sent from www.virginmedia.com/email
Virus-checked using McAfee(R) Software and scanned for spam


from_name: Andrew Dunbar

body:
This timely discussion fits in with my explorations last night
for adding more structure awareness to mediawiki.
Wiktionaries in particular have standardized formats where
headings and subheadings with standard names provide
structure for the data.

In the short term we need to wrap each section and
subsection in a div with a class name which reflects
the heading. In the long term we need to provide accessor
functions that can manipulate sections in a way similar
to the DOM. See bug 6104.

Andrew Dunbar (hippietrail)

On 2/14/07, Steve Bennett <stevagewp at gmail.com> wrote:
> On 2/14/07, Steve Bennett <stevagewp at gmail.com> wrote:
> > Yeah, and as an option, a [view] link next to the [edit] link.
>
> Or perhaps [print], since that would probably be the use for it.
>
> Steve
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

--
http://linguaphile.sf.net


from_name: Cary Bass

body:
Bryan wrote:

> -----Original Message-----
> From: commons-l-bounces at lists.wikimedia.org [mailto:commons-l-
> bounces at lists.wikimedia.org] On Behalf Of Bryan Tong Minh
> Sent: Wednesday, February 14, 2007 2:41 PM
> To: Wikimedia Foundation Mailing List; Wikimedia Commons Discussion List
> Subject: Re: [Commons-l] Commons Picture of the Year 2006
>
> Dear Wikimedians,
>
> Phase 1 of the POTY 2006 election is coming to its end.
>
> If you didn't participate yet or want to change your vote, you can
> still do it until 2400 Feb, 14 (today) at:
> http://commons.wikimedia.org/wiki/Commons:Picture_of_the_Year/2006.
>
> Phase 2, to elect the winner and 2 runners-up, will start February 17
> at:
> http://commons.wikimedia.org/wiki/Commons:Picture_of_the_Year/2006/final.
>
> Note: the final date has been postponed 2 days as has been stated in
> the first mail. We are trying our best to have the preparations for
> the final on time
>
> Joaquim [[commons:User:Alvesgaspar]]
> Bryan [[commons:User:Bryan]]
>
> _______________________________________________
> Commons-l mailing list
> Commons-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/commons-l
>

While this is my opinion, I believe a number of other Commoners share it.
I'd certainly like to see the Picture of the Year be one that was originally
photographed or Illustrated by a Commons participant, rather than one that
was found on a U.S. Government site or Flickr and uploaded.

Cary Bass
Bastique


from_name: Scott Orgera

subject: [WikiEN-l] Looking for MediaWiki developer(s) for small project

body:
Hello.

I am looking to hire a developer to create 4-5 custom extensions.

Here are some details regarding a few of these extensions....

-Integration of a custom Comment System

We are going to use the ipbwiki extension:
http://www.ipbwiki.com/Ipb_Wiki:Inte...th_ MediaWiki

In addition to this, what we would like is for every article created there
is also a thread created in a specific forum. Users can go to the article
then comment on the article at the bottom, and the reply would be same
mechanism to reply to the ipbb thread. We would need to have an option via
the article to show/hide comments. (ie. <no_comments)

-Ratings System implementation

We would like to update the Ratings extention here:
http://www.leerwiki.nl/How_to_port_U...p;action=purge

To work with mw1.9 with some added functionality. We would like the logic to
work so that non-logged in people can vote once, saved by IP, (as it works
now), or if you're logged in you can vote once, regardless of your IP. Then
again, we would like to have the ability to turn this off on a per-article
basis. (ie a tag in the article such as <no_rating>).

... More details will be provided to interested parties.

Please respond to this if this is something you may be interested in or if
you have any questions. Also, please provide price quotes on a 'per
extension' basis.

Thanks!

Scott

_________________________________________________________________


subject: [Foundation-l] Support WMF via GoodSearch

body:
On 14/02/07, Erik Moeller <erik at wikimedia.org> wrote:
> These folks allow you to use a version of Yahoo! search where 50% of
> ad revenue goes to a charity of your choice:
>
> http://www.goodsearch.com/
>
> On your first visit, you can choose the charity (Wikimedia is among
> those supported). You can also review how much money has been raised
> so far (apparently $3 in January). Pretty cool, IMHO. I've set it as
> my default search and will see if it makes a difference. I _do_ search
> a lot. :-)

Me too. I put it as my default search on Firefox. But I am not really
clear on how to confirm that they know I want my charity to be WMF.
Does anyone know how I can check?

cheers,
Brianna
user:pfctdayelise


body:
On 2/14/07, Andrew Dunbar <hippytrail at gmail.com> wrote:
> In the short term we need to wrap each section and
> subsection in a div with a class name which reflects
> the heading. In the long term we need to provide accessor
> functions that can manipulate sections in a way similar
> to the DOM. See bug 6104.

Yeah, I understand that we can now transclude sections of other pages.
But if it's controlled by section heading or section number, that's a
method very prone to breaking. Also, it would be good to be able to
demarcate sections of a page *other* than through headings, if
possible.

Do you have any proposed syntax or other solution?

Steve


body:
Also, would it be technically possible to have an input box on a wiki
page, like 'Search via Mayflower', that takes the user to a Mayflower
search for the provided keywords?

cheers,
Brianna


subject: [WikiEN-l] An idea for deletions

body:
On 2/14/07, Guettarda <guettarda at gmail.com> wrote:
> I really don't see how this reduces the load on AFD.  As it stands now any
> admin can speedy delete an article on AFD, and a speedy keep is usually
> pretty obvious.  What makes me uncomfortable about this proposal is that it
> removes these powers from the community at large and puts it in the hands of
> a special team.

He said "deletion preview team". He didn't say "elite, hand-picked
group of Jimbo's best friends". Just like AFC, it would be who ever
volunteers and can be bothered doing it.

> It certainly makes deletion a lot more difficult.  As I understand it, too
> much crap is more of a problem than too much unsupervised deletion.  AFD is
> tends to get overwhelmed - making everything go through a few hands before
> getting to AFD will only make this problem worse.

I also don't think he was proposing scrapping the existing direct AFD
method, for those that know how to do it. He's just proposing an
easier method in addition. I think.

And it should help the problem you describe by keeping some articles
out of AFD that don't need to be there.

Steve


body:
On 2/14/07, Jay R. Ashworth <jra at baylink.com> wrote:
> Well, my snap reaction is 'microformats'.

Say what?

> I think that there should be some way (and perhaps this is as easy as
> puting an "<a href="thisisatag"> link in after the section header.
>
> Isn't there some pipe-y syntax that already does something akin to this
> and tracks the section header?

Yeah, I was wondering that. Something like this might work:
==List of highways|List==

Where "List" is a code. Alternatively, and imho more readably:
==List of highways==
{{SECTION|List}}

Steve


from_name: Keitei

subject: [WikiEN-l] An idea for deletions

body:
On Feb 14, 2007, at 15:13, Luna wrote:
> On 2/14/07, Thomas Dalton <thomas.dalton at gmail.com> wrote:
>> I have a worrying feeling that would be spammed by nonsense requests
>> too often to be useful...
> [...snip...] Merging all that onto a mailing list
> would be very, very busy. [snip...]

I was under the impression that this would be neither a mailing list
nor anything else we've got set up, but rather a new facet of the
MediaWiki software which would be written so that it works like we
want it to. Unlike the copious piles of workarounds and quick hacks
we've got....

And for that, all we need is a bored developer who can make decent
special pages or some such, and maybe a bugzilla request. Unless it
was intended to be a mailing list, in which case I think it's a
horrible idea and mailing lists for issues intended to be acted upon
should all be shot.

--keitei


from_name: Jonathan Buck

subject: [WikiEN-l] Extended Toolbar

body:
In the tables page of the meta.wikimedia site, the example shows a toolbar
with many more buttons.  Is this custom work, or a flag somewhere?


from_name: Aphaia

body:
On 2/14/07, Brianna Laugher <brianna.laugher at gmail.com> wrote:

> Me too. I put it as my default search on Firefox. But I am not really
> clear on how to confirm that they know I want my charity to be WMF.
> Does anyone know how I can check?

I type Wikimedia Foundation into their "Who do You GoodSearch for? " box.
(You can later flash it, so you may contribute both to your alma mater and WMF)

Interestingly this service was offered in the last month already
http://www.goodsearch.com/Estimate.aspx

--
KIZU Naoko
  Wikiquote: http://wikiquote.org
  * habent enim emolumentum in labore suo *


from_name: Thomas Dalton

subject: [WikiEN-l] Admin Elitism (part 2)

body:
> My suggestion to root all the unecessary sysops is to create two eschelons of "elevated" users.
>
> The "writers" and the "sysops".
>
> A sysop would be just like an ordinary sysop; delete, protect, block, and reverse all those.
>
> But a writer would be more of an honorific and would not have some of the capabilities. The only capabilities a writer would have would be to delete OR protect (haven't decided yet).

What benefit would that have? If someone wants to concentrate on
writing articles, they don't need any extra tools. Your idea creates
an elevated level for the sake of it, rather than to fulfil a purpose.
Wikipedia doesn't exist to satisfy people's egos.


from_name: Boris Eetgerink

subject: [Wikitech-l] Massive Hook Proposal

body:
Jim Wilson wrote:
> Dear Wiki Devs,
>
> I have a proposal for adding new hooks into the MW codebase, and I'm looking
> for feedback (positive and negative).  The goal of the proposed changes is
> to give Extension Devs the ability to cleanly hijack just about any class in
> the system.
[...]

I support this idea. It makes MediaWiki very easy to modify, without the
need to dig into the core code.
It would be possible to replace the instantiated class with a subclass,
allowing you to add functions to it. All modifications would be neatly
placed in the extensions folder and in LocalSettings.php. I like it!

Boris


from_name: Jim Wilson

subject: [Wikitech-l] Massive Hook Proposal

body:
Thanks Mark,

So what's my best path to move forward with this?  A giant diff patch that
implements Mark's version for every class?  A series of small, independently
verifiable diffs?  What special concerns should I take into account when
undertaking such a sweeping change (above and beyond what's on
MediaWiki.orgthat is)?

Are there reasons why this patch wouldn't be accepted that I should consider
before undertaking the work to implement it?

Thanks in advance for any advice - I know how to do the code, it's the
process of getting it into the code base where I need guidance.  Thanks
again.

-- Jim

On 2/14/07, Mark Clements <gmane at kennel17.co.uk> wrote:
>
> "Jim Wilson" <wilson.jim.r at gmail.com> wrote in
> message news:ac08e8d0702140949u83cc418hd6f54fca61b1ec64 at mail.gmail.com...
> >
> > How do you feel about this alternative? (continuing the UploadForm
> example):
> >
> > function instantiate( &$request ) {
> >     $uploadForm = NULL;
> >     wfRunHooks('BeforeInstantiate_UploadForm', array( &$uploadForm,
> > &$request ));
> >     if ($uploadForm != NULL) {
> >         return $uploadForm;
> >     }
> >     $uploadForm = new UploadForm($request);
> >     wfRunHooks('AfterInstantiate_UploadForm', array( &$uploadForm,
> &$request
> > ));
> >     return $uploadForm;
> > }
> >
>
>
> AfterInstantiate_X should be run regardless of where the object came from.
> The above should probably be (in some kind of pseudo-code form):
>
> function instantiate( &$args) {
>     $objResult = NULL;
>     wfRunHooks('BeforeInstantiate_X', array( &$objResult, &$args));
>
>     if ($objResult === NULL)
>         $objResult = new Object($args);
>
>     wfRunHooks('AfterInstantiate_X', array( &$ojResult, &$args));
>     return $objResult;
> }
>
>
> - Mark Clements (HappyDog)
>
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/wikitech-l
>


from_name: Claudi Meneghin

subject: [Wikitech-l] Exporting subsections of pages - 2

body:
Hi all,
  the use I have in mind about this feature was in fact translation, rather than printing.
  Using a generative-grammar approach allows large scale economy while translating many articles dislpaying similar strucures.
  However -as I realised this night- extracting subsections can be easily dealt with be the use of Find/Replace and wildcards, plus some appropriate macroes applied to the XML code exported.
  Another idea, which came to me while thinking about how to solve this problem, is that it would be very useful the templates included within a page to be automatically exported together with that page. Of course, nesting should be suitable limited.
  Many thanks for your kind and interesting comments,
  Claudi

---------------------------------
 D?couvrez une nouvelle fa?on d'obtenir des r?ponses ? toutes vos questions ! Profitez des connaissances, des opinions et des exp?riences des internautes sur Yahoo! Questions/R?ponses.


from_name: Steve Bennett

subject: [WikiEN-l] The Age uses Wikipedia logo for Wikia

body:
On 2/14/07, Nick Wilkins <nlwilkins at gmail.com> wrote:
> The article does begin with "The people behind Wikipedia bring their
> user-driven publishing model..." and does make numerous comparisons (ads,
> public confidence, etc.) with Wikipedia.

Actually, I originally interpreted "The people behind Wikipedia" as
"The Wikimedia Foundation". Just one of those ambiguous phrases I
guess.

Steve


subject: [WikiEN-l] - category clutter on biographical articles

body:
On 2/14/07, Michael Snow <wikipedia at earthlink.net> wrote:
> Perhaps he meant the problem was that you'd arguably have to include
> every rock guitarist since 1969 in the category.

And this is harmful how?

Steve


from_name: Platonides

body:
Claudi Meneghin wrote:
> Hi all,
>   the use I have in mind about this feature was in fact translation, rather than printing.
>   Using a generative-grammar approach allows large scale economy while translating many articles dislpaying similar strucures.
>   However -as I realised this night- extracting subsections can be easily dealt with be the use of Find/Replace and wildcards, plus some appropriate macroes applied to the XML code exported.
>   Another idea, which came to me while thinking about how to solve this problem, is that it would be very useful the templates included within a page to be automatically exported together with that page. Of course, nesting should be suitable limited.
>   Many thanks for your kind and interesting comments,
>   Claudi

The purpose of Special:ExpandTemplates is precisely this: expand
templates, magic words and parser functions into wikicode.
Thus you would need two server calls: One to Special:Export and a second
one to Special:ExpandTemplates with the section content.


from_name: Flame Viper

subject: [WikiEN-l] Deletion propsals

body:
I think that a "nom for delete" tab would be an excellent idea.
Obviously, it would be abused, but so can the entire Wikipedia concept of editable pages. That hasn't stopped us yet.
But in order to make it somewhat reliable as a source of legitimate information, we would probably have to make it available only to logged-in users. The same thing is already in use for page moves, so there is no danger of breaking precedent.
And if even that isn't enough, we might even have to bury the option somewhere in User Preferences.
The technology is already avaliable to nom an article for CSD (see http://en.wikipedia.org/wiki/User:Flameviper/monobook.js), we only have to modify it to work for AFD and prod.

SO THAR.

---------------------------------
Have a burning question? Go to Yahoo! Answers and get answers from real people who know.


from_name: Axel Ngonga

subject: [Wikitech-l] WMDumper

body:
I tried using WMDumper to load the content of wikipedia in a Mysql 5
Database. I used tables.sql to generate the table. I then tried writing
the data in the mySql using WMDumper and get the following results.

C:\Downloads>set
class=mwdumper.jar;mysql-connector-java-3.0.11-stable-bin.jar

C:\Downloads>set data="C:\Downloads\enwiki-20070206-pages-articles.xml.bz2"

C:\Downloads>java -client -classpath
mwdumper.jar;mysql-connector-java-3.0.11-stable-bin.jar
org.mediawiki.dumper.Dumper
"--output=mysql://127.0.0.1/enwiki?user=xxxx&password=xxxxxxx"
"--format=sql:1.5" "C:\Downloads\enwiki-20070206-pages-a
rticles.xml.bz2"
1.000 pages (148,148/sec), 1.000 revs (148,148/sec)
2.000 pages (156,104/sec), 2.000 revs (156,104/sec)
Exception in thread "main" java.lang.StringIndexOutOfBoundsException:
String index out of range: -1
        at java.lang.String.substring(Unknown Source)
        at
com.mysql.jdbc.EscapeProcessor.escapeSQL(EscapeProcessor.java:151)
        at com.mysql.jdbc.Statement.execute(Statement.java:845)
        at org.mediawiki.importer.SqlServerStream.writeStatement(Unknown
Source)
        at org.mediawiki.importer.SqlWriter.flushInsertBuffer(Unknown
Source)
        at org.mediawiki.importer.SqlWriter.bufferInsertRow(Unknown Source)
        at org.mediawiki.importer.SqlWriter15.writeRevision(Unknown Source)
        at org.mediawiki.importer.MultiWriter.writeRevision(Unknown Source)
        at org.mediawiki.importer.PageFilter.writeRevision(Unknown Source)
        at org.mediawiki.dumper.ProgressFilter.writeRevision(Unknown Source)
        at org.mediawiki.importer.XmlDumpReader.closeRevision(Unknown
Source)
        at org.mediawiki.importer.XmlDumpReader.endElement(Unknown Source)
        at
org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
        at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown
Source)
        at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
        at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
        at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
Source)
        at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
Source)
        at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
        at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
        at
org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
        at javax.xml.parsers.SAXParser.parse(Unknown Source)
        at javax.xml.parsers.SAXParser.parse(Unknown Source)
        at org.mediawiki.importer.XmlDumpReader.readDump(Unknown Source)
        at org.mediawiki.dumper.Dumper.main(Unknown Source)

--
________________________________________________________________________

Axel Ngonga              University of Leipzig, Dpt. Computer Sciences
M.Sc.                               Business Information Systems Group
                                  http://bis.informatik.uni-leipzig.de
Johannisgasse 26, Room 5-22
D-04103 Leipzig
fon: +49-341-9732341 * fax: +49-341-9732239 * mobile: +49-176-23517631
________________________________________________________________________


from_name: Ron Ritzman

subject: [WikiEN-l] An idea for deletions

body:
On 2/13/07, Steve Bennett <stevagewp at gmail.com> wrote:

> He said "deletion preview team". He didn't say "elite, hand-picked
> group of Jimbo's best friends". Just like AFC, it would be who ever
> volunteers and can be bothered doing it.

Except that under the model I "dreamed up" :) The volunteers would
have to have admin privs in order to delete the no-brainers. Anything
else could be done by any volunteer, admin or not.

> I also don't think he was proposing scrapping the existing direct AFD
> method, for those that know how to do it. He's just proposing an
> easier method in addition. I think.

[snip]

> And it should help the problem you describe by keeping some articles
> out of AFD that don't need to be there.

For this to work, the direct nomination method would have to be
scrapped or else a troll/vandal could get a bullshit nom past the
team. However, using such a system and keeping direct nominations
would still have a benefit in allowing anons and those unfamiliar with
deletion procedure to make a nom and even have it "proofread" for them
:)


subject: [Wikitech-l] WMDumper

body:
Axel Ngonga wrote:
> I tried using WMDumper to load the content of wikipedia in a Mysql 5
> Database. I used tables.sql to generate the table. I then tried writing
> the data in the mySql using WMDumper and get the following results.

You'll probably get the answer that the MediaWiki developers don't
support third-party extensions, so you'd better give it a try with the
maintenance/importDump.php script first (run it from the command-line).

Good luck,

Boris


subject: [WikiEN-l] An idea for deletions

body:
On 2/14/07, Thomas Dalton <thomas.dalton at gmail.com> wrote:

> I have a worrying feeling that would be spammed by nonsense requests
> too often to be useful...

That's why I don't know if I like the idea of having a "delete" button
on the article itself. The act of having to "go somewhere else and
jump through some hoops" makes some people think about their noms
under the present setup. I just want to eliminate the "hoops". Someone
who wants to nominate an article for deletion would still have to "go
somewhere else", the web form.


from_name: Rob Church

subject: [Wikitech-l] WMDumper

references:
<45D335DE.2070608@informatik.uni-leipzig.de>
	<45D33908.1080401@planet.nl> <eqvg7b$d44$1@sea.gmane.org>

body:
On 14/02/07, Platonides <Platonides at gmail.com> wrote:
> MWDumper is supported by MediaWiki. I don't know the author, but it's
> certainly not a "third party extension", but the recommended tool.
> importDump.php is too slow for using it with a full wiki dump (it
> renders each page).

Brion Vibber, I thought?

Rob Church


subject: [WikiEN-l] Limited Sysop

body:
My earlier comment on a possible "writer" status was kind of stupid. And it wasn't refined...

I propose that for the "editor" status (my proposal for a user right between user and sysop), one would have the capabilities to edit protected articles, view deleted revisions, and generally view admin-olny things (but not actually perform sysop actions per se). And they might have a toolbar that would allow them to nominate these things...

---------------------------------
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.