from_name: Bence Damokos

body:
Well you could start by giving the one-click upload feature to admins on a
local wiki, and maybe storing the uploaders name in a database, so it can be
traced...

Bence

On 12/13/06, Artur Fija?kowski <wiki.warx at gmail.com> wrote:
>
> 2006/12/13, Brianna Laugher <brianna.laugher at gmail.com>:
> > On 13/12/06, Magnus Manske <magnusmanske at googlemail.com> wrote:
> > > On 12/12/06, Bence Damokos <bdamokos at gmail.com> wrote:
> > > >
> > > > > I do not think this is good enough to celebrate. I'd welcome a
> tool that
> > > > > would allow us to move properly licensed free images from
> wikipedias to
> > > > > commons. Now I'd celebrate then.
> > > >
> > > > >
> > > > >
> > > > > *ahem*
> > > > >
> > > > > http://tools.wikimedia.de/~magnus/pushforcommons.php
> > > >
> > > > Is there a way, to have the one-click upload feature in the
> ImportFreeImages
> > > > extension made available in the pushforcommons as well?
> > >
> > > PushForCommons uses CommonsHelper, which already has that option. But,
> > > it is currently hidden, as all one-click uploads are then attributed
> > > to a Commons upload bot. There was concern it might be abused. Now, if
> > > there were consensus to enable this publicly, and if the toolserver
> > > databases were back...
> >
> > I will continue to push very strongly that any toolserver-based tool,
> > which does not require any kind of Wikimiedia login, should never
> > allow essentially anonymous uploads to Commons, as this would. Many,
> > many many Wikimedia wikis have lax, nonexistent or not-inforced image
> > use policies. If we were to enable this all sorts of shit would be
> > transferred and we would have no way of even identifying who had
> > transferred it. All the cleanup and even no one specific to blame. ;)
> > Not cool.
> > So probably any tool like this should be part of MediaWiki. So we know
> > what that means, chaps: settle in for a good long wait, or else write
> > it yourself (and then settle back for that wait anyway...).
> >
> > cheers,
> > Brianna
> > user:pfctdayelise
>
> Sad but true - I would be same as with LonardoG, who was ''only''
> moving ''free'' images from his own wiki, but we blamed him for
> copyvios (I think we were 100% right).
>
> I someone gives to everyone such toy, he MUSTto know, that he takes
> responsibility for that (cause of that my IRC bot interface needs
> authorization and userrights  for uploading).
>
> AJF/WarX
> _______________________________________________
> Commons-l mailing list
> Commons-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/commons-l
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/commons-l/attachments/20061213/1796bdc1/attachment.htm


list: wikien-l

source: pipermail-mbox

from_name: Steve Bennett

subject: [WikiEN-l] Categories (was: Hello)

body:
On 12/13/06, Marc Riddell <michaeldavid86 at comcast.net> wrote:
> It is beginning to dawn on me (perhaps the sun rises later here) that there
> is/would be a great difference between categorizing biographical articles v.
> non-biographical ones. The biographical would require much less complex
> layers. Any thoughts on this?

I don't think there are any simple dichotomies in this. Different
kinds of stuff have different kinds of categorisational needs.

We have a current trend towards splitting big categories. We prefer a
single category "Dutch authors" rather than adding two massive
categories to an article: "Dutch people" and "Authors". However this
approach is pretty clearly a dead-end: how many times can we split?
What do we split on next, "Dead Dutch authors"? Good category
intersections would really help that one...

I guess you're right in that people are just made up of attributes:
where/when they're born/died, what field they were primarily in etc,
all of which could be much more complex trees.

Steve


from_name: Gregory Maxwell

subject: [WikiEN-l] Finding out what to take photos of

body:
On 12/13/06, Timwi <timwi at gmx.net> wrote:
[snip]
> Take me as an example. I live in [[Cambridge]]. I'm not particularly
> interested in sight-seeing or architecture, so I know little about the
> sights and buildings in this city. However, I would be happy to take
> (free-license) pictures of something in this city and upload them to
> Commons (indeed I have already done so for some of the Colleges). The
> problem (for Commons/Wikipedia) is that I don't know, and don't have
> much interest or motivation in researching, what sights or buildings
> exist in this city that don't already have a free picture on
> Commons/Wikipedia.

I suffer from this too.. We have lists, but they aren't really
effective.  I tried making a list of articles for things near me which
don't have pictures.. but our category system makes doing so
difficult.

Sometimes I visit some place and think "surely we have a picture of
X".. only to later find out that we don't .. or that it's "fair use"
.. or that it's just a very poor picture and that I could take one
which is much better.

Or the reverse happens.. I'll be out in the woods and think "surely we
don't have good pictures of trail markers" and spend an hour building
a exhaustive collection only to find that the subject is
[http://en.wikipedia.org/wiki/Trail_blazing well covered].

To an extent I think that we'll only be able to solve this by putting
up a good lightweight (wap perhaps) interface to our lists of needed
images so people can reasonably query them while in the field.

[snip]
> So, in summary: Commons or Wikipedia needs an organised index or
> catalogue of things that don't have a free picture. Ideally, there
> should be somewhere I can click to list the things in Cambridge that
> don't have a picture.

The prerequisite is correctly identifying things in Cambridge... which
is currently non-trivial because of semantic drift in our categories
and a lack of geocoding.


from_name: Thomas Dalton

subject: [WikiEN-l] new Google Earth tie-in (!!)

body:
> We (and they) are in a rock-and-a-hard-place situation.  It's
> good that they're working from their own stashed copy instead of
> hitting us live, because I doubt our servers could handle their
> users' load.  But of course on the other hand it's supremely
> annoying that they're working from their own stashed copy,
> because (as you note and I emphatically agree) our lovely
> instantaneous wiki-quick edit-save-test loop is broken.

Why can't we have the best of both worlds? They get the co-ordinates
from the database dumps, but when a user clicks on the globe icon they
get the live page. We should be able to handle the load if our servers
are only hit when a user actually tries to read the page.


from_name: Delirium

subject: [WikiEN-l] new Google Earth tie-in (!!)

body:
The Cunctator wrote:

>On 12/13/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>
>
>>On 12/13/06, The Cunctator <cunctator at gmail.com> wrote:
>>
>>
>>>Looking at the screenshot and reading GFDL 1.2 it looks like they should
>>>just a) have a link on each page to the authors/article history and b)
>>>release the code for their modified version of the pages. Not sure how
>>>appropriate it is for them to use the logo.
>>>
>>>
>>>From that page you are two clicks from the history.
>>
>>
>
>
>The history on our servers. Where's their copy?
>
>

Our own information on reuse suggests that a link back is sufficient
[1].  Whether that's how the GFDL would be interpreted in court or not I
can't say, but it hardly seems like something to fault Google for if
they're doing precisely what we ask of them.

-Mark

[1] http://en.wikipedia.org/wiki/Wikipedia:Copyrights#Example_notice


from_name: Luna

subject:
[WikiEN-l] Completely unreasonable block and behavior by admin
	friends of Itaqallah to win a content dispute

body:
And Itaqallah has asked me to forward this to the list:

== hello Luna ==

> i was reading the mailing list about the RunedChozo incident... i'm not
> sure how to reply to current discussions (i just signed up to it), so i was
> thinking i would request you to convey all i had to say on the matter (i had
> already explained this on AN/I).
>
> if that edit summary is looked at by itself, then no it doesn't match up
> with my revert. if, however, you consider RunedChozo's behaviour on that
> page then you may understand the reasoning for that summary. every revert by
> RunedChozo had been a revert to this version<http://en.wikipedia.org/w/index.php?title=Muhammad_as_a_diplomat&diff=92473890&oldid=92318517>(bar an extra sentence which i will cover in a moment), which was the
> insertion of subjective (and yes, unsourced) OR. now, RunedChozo had been
> persisting in re-inserting this sentence: it was only five reverts after his
> original insertion that he added an additional sentence starting with
> "Source:..". this is rather inconsequental: the sources do not substantiate
> the claim, so it remains OR; and he would not be in a position to verify it
> unless he is fluent in Arabic, which i do not believe he is. i didn't see
> his insertion of these sources: someone else had reverted it before i'd had
> a chance to look at it. when RunedChozo had come back from his three day
> block and resumed reverting to self again (11 Dec), i merely assumed that he
> was reinserting the same OR again (which he was), not knowing that he had
> added a pseudo-'source' to it. had i known that he was also misrepresenting
> sources i would not have described his OR insertion as 'unsourced'. i may
> have been wrong, yes, but i certainly was not lying. i hope that clarifies
> the issue. by the way, i do not know future perfect (i have addressed him on
> two separate occasions only)- i contacted him when i had found RunedChozo
> puppeteering (User:Wheelygood), because he had been involved in the 3RR
> discussion here<http://en.wikipedia.org/wiki/Wikipedia:Administrators%2527_noticeboard/3RRArchive32#User:RunedChozo_reported_by_User:mdf_.28Result:_3_days.29>
> .
>
> if you could put that up on the list Luna, i would be very grateful..
> thank you. [[User:Itaqallah| color="#029DDD">ITAQALLAH]] 23:31, 13 December 2006 (UTC)
>


from_name: Stan Shebs

subject: [WikiEN-l] Problem with {{contradicting}}

body:
Timwi wrote:
> I think the {{contradicting}} template is problematic because it doesn't
> require the user to specify what the supposed contradiction is. Some
> people seem to add it as if it was an intrinsic property of the subject,
> rather than a request to fix something. When I removed it with the
> comment "Please don't add the contradiction tag without giving your
> reasons on the Talk page, otherwise I won't know what to fix in the
> article", it was simply added back in with the edit summary "who keeps
> removing that template?".
>
Just add a parameter with an appropriately snarky default...

Stan


from_name: Steve Summit

subject:
[WikiEN-l] quick question: different policies for different
	namespaces?

body:
Can someone remind me where it's stated how our policies are
applied differently for different namespaces, and how many of
those differences there are?  I'm pretty sure the rules for talk
pages are different, but are there also significant differences
between "project" pages and the main namespace (i.e. ns:0)?

(I ask because I'm becoming embroiled in a delightful -- not! --
tempest-in-a-teapot over proposed sweeping new policies for the
Reference Desks, and one of the sticking points seems to be the
extent to which core policies such as WP:NOR and WP:V should be
applied there.  But I mention this only for information; I'm not
trying to extend the RD debate to this mailing list.)


list: wikitech-l

from_name: Dave Grogan

subject:
[Wikitech-l] can I add parameters to hooks used by two
 extensions(spellchecker and svn blame-like view)

body:
Mark Clements wrote:
> "David Grogan" <dgrogan at gmail.com> wrote in
> message news:cb6d7dc50612130850s74267de2s2f943af0c1c75224 at mail.gmail.com...
>> I've co-authored two extensions that need an additional hook and
>> additional parameters to two existing hooks.  I am requesting commit
>> access so that I may upload the extensions and amend the hooks.
>>
>
> What hook and what parameters?
>
>
> - Mark Clements (HappyDog)

To be addded:

The spellchecker needs a hook near the end of getEditToolbar that is
passed the toolbar variable.  The extension adds a spellcheck button to
the toolbar.

To be amended:

Track Changes needs ArticleSaveComplete to also pass $revisionId (id of
the newly-saved revision) and a flag that determines whether the content
of the article changed.

Track changes needs SkinTemplateTabs to pass in revid and oldid so that
it can display oldid if specified in the query string or revid if it was:

$oldid = $wgRequest->getVal( 'oldid' );
global $wgArticle;
$revid = $wgArticle ? $wgArticle->getLatest() : 0;

dgrogan at gmail.com


from_name: geni

subject: [WikiEN-l] new Google Earth tie-in (!!)

body:
On 12/13/06, The Cunctator <cunctator at gmail.com> wrote:
> Is it even legal for them to use the stashed copy? That seems to potentially
> violate the GFDL in any number of ways.
>

Do they give credit in any way shape or form?

--
geni


subject: [WikiEN-l] new Google Earth tie-in (!!)

body:
> Is it even legal for them to use the stashed copy? That seems to potentially
> violate the GFDL in any number of ways.

How? It's no different to any other mirror. As long as they give
appropriate credit and link back to the original (technically, they
just have to supply a copy of the original wikicode, I think, but
linking back is the standard way to do that) they're fine.


from_name: Ben Yates

subject: [WikiEN-l] new Google Earth tie-in (!!)

body:
I agree.  And in practical terms, what difference does it make where
the history is hosted?

On 12/13/06, Delirium <delirium at hackish.org> wrote:
> The Cunctator wrote:
>
> >On 12/13/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> >
> >
> >>On 12/13/06, The Cunctator <cunctator at gmail.com> wrote:
> >>
> >>
> >>>Looking at the screenshot and reading GFDL 1.2 it looks like they should
> >>>just a) have a link on each page to the authors/article history and b)
> >>>release the code for their modified version of the pages. Not sure how
> >>>appropriate it is for them to use the logo.
> >>>
> >>>
> >>>From that page you are two clicks from the history.
> >>
> >>
> >
> >
> >The history on our servers. Where's their copy?
> >
> >
>
> Our own information on reuse suggests that a link back is sufficient
> [1].  Whether that's how the GFDL would be interpreted in court or not I
> can't say, but it hardly seems like something to fault Google for if
> they're doing precisely what we ask of them.
>
> -Mark
>
> [1] http://en.wikipedia.org/wiki/Wikipedia:Copyrights#Example_notice
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

--
Ben Yates
Wikipedia blog - http://wikip.blogspot.com


body:
I've seen blocks happen over this sort of thing. I suggest kindly reminding
the user that adding such templates without a more complete explanation on
the talk page isn't helpful to fixing the problem. It's possible they didn't
see your edit summary, so their user talk will make that nice, orange box
for them. You can also jump-start the discussion, yourself -- a "please
explain" thread, I like to call them. Open-ended questions beg for answers.

Just my thoughts.

-Luna

On 12/13/06, Stan Shebs <stanshebs at earthlink.net> wrote:
>
> Timwi wrote:
> > I think the {{contradicting}} template is problematic because it doesn't
> > require the user to specify what the supposed contradiction is. Some
> > people seem to add it as if it was an intrinsic property of the subject,
> > rather than a request to fix something. When I removed it with the
> > comment "Please don't add the contradiction tag without giving your
> > reasons on the Talk page, otherwise I won't know what to fix in the
> > article", it was simply added back in with the edit summary "who keeps
> > removing that template?".
> >
> Just add a parameter with an appropriately snarky default...
>
> Stan
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Timwi

subject: [WikiEN-l] Hello

body:
Steve Bennett wrote:
> On 12/13/06, The Cunctator <cunctator at gmail.com> wrote:
>
>>It pretty much defeats the purpose of having subcategories.
>>
>>By putting an article into a subcategory, you are effectively putting it
>>into the parent category.
>>
>>Maybe we should figure out a way to make that more obvious.
>
> There is absolutely nothing at all in MediaWiki that makes a page in a
> subcategory behave like it's also in the parent category. Nothing.
> It's completely and utterly a construct in the mind of the user.

But it's by far the most logical construct to make, and there is very
little reason to keep the software free from any support of that
construct (even if it is to the detriment of other, more exotic constructs).


subject: [WikiEN-l] Hello

body:
charles.r.matthews at ntlworld.com wrote:
>
> That does not mean that I want [[Category:Mathematics]] to consist of
> 15000 pages. How would that help anyone?

This seems to be an extremely widespread and popular fallacy. "/I/ can't
think of any use for it, therefore we mustn't have it." Could you all
please think about this for 1 second and realise that it's a total fallacy?


from_name: jayjg

subject:
[WikiEN-l] Admins who pretend to quit (was Re: MONGO and the
	ArbComm)

body:
On 12/12/06, Parker Peters <onmywayoutster at gmail.com> wrote:
> On 12/12/06, M Roget <mroget at gmail.com> wrote:
> >
> > Can we have a rule that states that any admin who "quits" Wikipedia to
> > protest this or that is automatically desysopped? It's one thing to take a
> > wikibreak or to leave because of real life time commitments but any admin
> > who quits in order to make a point has abdicated their responsibilities.
> > There seems to be a trend of admins announcing their departure only to
> > come
> > back in a few days after dozens of people have posted supportive
> > statements
> > on their talk page. Call me cynical but this looks like manipulative
> > trolling to me and automatic desysopping would create a disincentive. If
> > someone really intends to leave they won't care about being desysopped -
> > they'll even request that it be done but if somone is just pretending to
> > leave an automatic desysopping will make them think twice.
> >
> > Michel
> >
>
> I see this as a very valid option. It'd certainly be a disincentive to a
> large amount of drama.
>
> And no, I don't see my circumstances as different. Unlike them, I haven't
> come back to wikipedia itself.

Trolling wiken-l is hardly leaving.

> And if this were to be adopted, I'd
> cheerfully smile as my account was desysopped.
>
> Parker

An empty offer, since it could only happen if you had a sysop account
to begin with.

Jay.


list: foundation-l

from_name: Brad Patrick

subject: [Foundation-l] Wikimedia Foundation's help to the projects

body:
Soufron is no longer the Chief Legal Officer.  He has no role at this time.

Legal is my responsibility (General Counsel) and will be receiving more
attention in the future.  My other current job is, shall we say, demanding.

-Brad

Michael Bimmler wrote:
> On 12/13/06, Yann Forget <yann at forget-me.net> wrote:
>
>
>> 1. Legal counselling.
>>
>> Some projects (mainly Commons and Wikisource) need more input about
>> copyright issues from knowledgeable persons. I have asked twice to
>> juriwiki-l specific issues for Wikisource without receiving an answer,
>> even an acknowledgement that my request was received. Another concrete
>> example: Commons and Wikisource would benefit most from a cross table
>> about copyright rules, which countries use "most favourable rule apply",
>> etc.
>>
>>
> I really wonder about the status of the following bodies or positions:
>
> http://meta.wikimedia.org/wiki/Legal_department Is / was this ever
> official? If yes, is it the appropriate point of contact?
>
> http://meta.wikimedia.org/wiki/Lead_Legal_Coordinator (Soufron) Is
> this still an active position? If yes, how is it related to the
> General Counsel? Who is the appropriate contact for project legal
> issues? Jean-Baptiste Soufron or Brad?
>
> http://meta.wikimedia.org/wiki/Juriwiki_mailing_list Is this
> mailinglist active (i.e. are there discussions going on at the
> moment)? Should it still be contacted?
>
>
>
>
>> 2. Helping small projects. It seems that some projects have a difficult
>> start. Indian languages projects are my first examples. I will go to
>> India in January, and I would like to use this opportunity to recruit
>> new contributors. The Foundation could help coordinate this kind of
>> recruitement.
>>
>>
> Isn't this in the domain of Special Projects Committee resp. its
> 'language' subcommitee?
> >From http://meta.wikimedia.org/wiki/Special_projects_subcommittees/New_languages
>
> The Wikipedia Foundation Special projects language subcommittee is in
> charge of (...) supporting and coordinating new projects to optimize
> their success.
>
> Michael
>
>> Best regards,
>>
>> Yann
>> --
>> http://www.non-violence.org/ | Site collaboratif sur la non-violence
>> http://www.forget-me.net/ | Alternatives sur le Net
>> http://fr.wikipedia.org/ | Encyclop?die libre
>> http://fr.wikisource.org/ | Biblioth?que libre
>> http://wikilivres.info | Documents libres
>> _______________________________________________
>> foundation-l mailing list
>> foundation-l at wikimedia.org
>> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>>
>>
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>
>


list: wikimedia-l


subject: [WikiEN-l] new Google Earth tie-in (!!)

body:
On 12/13/06, Thomas Dalton <thomas.dalton at gmail.com> wrote:
> > Is it even legal for them to use the stashed copy? That seems to potentially
> > violate the GFDL in any number of ways.
>
> How? It's no different to any other mirror. As long as they give
> appropriate credit and link back to the original (technically, they
> just have to supply a copy of the original wikicode, I think, but
> linking back is the standard way to do that) they're fine.

They have to credit the authors.

--
geni


from_name: Anthony

subject: [WikiEN-l] new Google Earth tie-in (!!)

body:
On 12/13/06, Steve Summit <scs at eskimo.com> wrote:
> Gregory Maxwell wrote:
> > The use of the logo was negotiated.
>
> Glad to hear it.  In answer to geni's earlier question whether
> they were giving credit in any way shape or form, it seemed to
> me that their use of the logo was a good way *to* give credit,
> not something for us to be jealous of.
>
> To anyone out there who's worried about this: I'm just one guy,
> but from where I sit, this is a *very* nice tie-in, and we stand
> to gain at *least* as much from it as Google does, and quite
> possibly much more.

It doesn't seem right to me giving special permission to a company
which makes proprietary software and distributes watermarked
proprietary maps, some of which are just public domain maps with a
watermark and a spurious claim of copyright on them.

Give the special permissions and assistance to the people who make
World Wind.  Down with Google Earth.

Anthony


from_name: Jay R. Ashworth

subject:
[Wikitech-l] can I add parameters to hooks used by two
	extensions (spellchecker and svn blame-like view)

body:
On Wed, Dec 13, 2006 at 02:12:46PM -0500, Dave Grogan wrote:
> Jay R. Ashworth wrote:
> > On Wed, Dec 13, 2006 at 11:50:30AM -0500, David Grogan wrote:
> >> The second is a "track changes" / "svn blame" view that shows who is
> >> responsible for what portions of an encyclopedia entry.
> >
> > Technical derail: I'm curious: what is your list of colors for
> > identifying contributors?  Specifically: *how deep is it*?  :-)
>
> I believe it is 64 deep.

That won't be enough.  :-)

> > I regularly see things identified by color codes which are
> > insufficiently distinguishable from one another.  Past 9 or 10, it can
> > get rough...
>
> Yeah, there are only about 8 good ones that are really distinctive, and
> then after about 20 you can get into some hairy situations.  It's not
> that bad though because usually an off-green is next to an off-red or
> something.  It's only bad when a color and two of its off-colors are all
> close.  I might have it wrap after 10 but add a hover feature that will
> pop up the contributor's name.

You've seen the IBM work on this sort of thing, right?

Should we ever expect it to show the rendered text with these markers,
instead of the raw?  Cause that'd be outta sight...

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


body:
On Wed, Dec 13, 2006 at 11:43:28AM -0800, Brion Vibber wrote:
> Dave Grogan wrote:
> > Jay R. Ashworth wrote:
> >> I regularly see things identified by color codes which are
> >> insufficiently distinguishable from one another.  Past 9 or 10, it can
> >> get rough...
> >
> > Yeah, there are only about 8 good ones that are really distinctive, and
> > then after about 20 you can get into some hairy situations.  It's not
> > that bad though because usually an off-green is next to an off-red or
> > something.  It's only bad when a color and two of its off-colors are all
> > close.
>
> Let's not forget the color-blind and the monochrome screen-users.

It's an enhancement; accessibility is *slightly* less important than it
is to mainline functionality.

For a while.

IMHO.

(That's not dissing the handicapped; it's a scheduling/priority opinion.)

> > I might have it wrap after 10 but add a hover feature that will
> > pop up the contributor's name.
>
> I would strongly suggest using such a hover feature. Pop-ups with links
> to details might be rather more useful, actually, enabling popping over
> to the specific diff that made the change.
>
> I do fear how this stuff is going to work on pages with tens of
> thousands of edits, but... ;)

Set fences on the earliest and latest versions it displays?  Showing
older material in just black on white?

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


from_name: The Cunctator

subject: [WikiEN-l] new Google Earth tie-in (!!)

body:
On 12/13/06, Anthony <wikilegal at inbox.org> wrote:
>
> On 12/13/06, Steve Summit <scs at eskimo.com> wrote:
> > Gregory Maxwell wrote:
> > > The use of the logo was negotiated.
> >
> > Glad to hear it.  In answer to geni's earlier question whether
> > they were giving credit in any way shape or form, it seemed to
> > me that their use of the logo was a good way *to* give credit,
> > not something for us to be jealous of.
> >
> > To anyone out there who's worried about this: I'm just one guy,
> > but from where I sit, this is a *very* nice tie-in, and we stand
> > to gain at *least* as much from it as Google does, and quite
> > possibly much more.
>
> It doesn't seem right to me giving special permission to a company
> which makes proprietary software and distributes watermarked
> proprietary maps, some of which are just public domain maps with a
> watermark and a spurious claim of copyright on them.

kind of have to agree there. but i guess if you pay off the foundation....

Give the special permissions and assistance to the people who make
> World Wind.  Down with Google Earth.
>
> Anthony
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


subject:
[Wikitech-l] can I add parameters to hooks used by two
 extensions (spellchecker and svn blame-like view)

body:
>> Yeah, there are only about 8 good ones that are really distinctive, and
>> then after about 20 you can get into some hairy situations.  It's not
>> that bad though because usually an off-green is next to an off-red or
>> something.  It's only bad when a color and two of its off-colors are all
>> close.  I might have it wrap after 10 but add a hover feature that will
>> pop up the contributor's name.
>
> You've seen the IBM work on this sort of thing, right?

No.  Please inform.

> Should we ever expect it to show the rendered text with these markers,
> instead of the raw?  Cause that'd be outta sight...

My comrades and I have discussed this and it is definitely on the table.
  It seems that the parser would have to (and maybe it already does some
of this) report when it was processing a token and also when it was
about to display some text.  When it was about to throw the text on the
page the extension could wrap it in the appropriate color span.  I have
never looked at the parser so I don't know if that would be feasible.


from_name: Sander Sepp

subject: [WikiEN-l] new Google Earth tie-in (!!)

body:
I like the way it is now. Google's servers load the articles faster
than wikipedia servers do, at least for me in Europe. Using the live
articles would cause longer load times.

(first post for me in this list, I hope I posted correctly)

On 12/13/06, Thomas Dalton <thomas.dalton at gmail.com> wrote:
> > We (and they) are in a rock-and-a-hard-place situation.  It's
> > good that they're working from their own stashed copy instead of
> > hitting us live, because I doubt our servers could handle their
> > users' load.  But of course on the other hand it's supremely
> > annoying that they're working from their own stashed copy,
> > because (as you note and I emphatically agree) our lovely
> > instantaneous wiki-quick edit-save-test loop is broken.
>
> Why can't we have the best of both worlds? They get the co-ordinates
> from the database dumps, but when a user clicks on the globe icon they
> get the live page. We should be able to handle the load if our servers
> are only hit when a user actually tries to read the page.
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


subject: [Wikitech-l] "One intermediate revision not shown."

body:
Hey!  When did that new placeholder message get added to an otherwise
empty (and therefore otherwise potentially misleading) diff listing?
Very nice touch!


body:
On 12/13/06, MacGyverMagic/Mgm <macgyvermagic at gmail.com> wrote:
> Surely you can have AutoWikiBrowser slug through a list of articles that
> link to Camebridge and also have a structure-stub tag or Buildings in
> Camebridge category to them? Then there's [[WP:RI]] too. Is there a
> Camebridge WikiProject?

Wikipedia is more of a mess than you expect.

You can reach lots of non-location things (like people, ideas, and
products) via almost any clearly location based category.  ... And
many of the things which would be suitable for photography do not have
anything that easily identifies them, for example [[Eden Center]] (why
the heck do we have articles on minor shopping centers when we're
still missing important US Supreme court cases.. blah! a rant for
another day).

Also, none of our location based categories easily translate to 'near
me' or even 'within a reasonable travel distance' .. if everything
were geocoded, things would be much easier.


from_name: Guy Chapman aka JzG

body:
On Wed, 13 Dec 2006 09:09:06 -0500, "Daniel R. Tobias"
<dan at tobias.name> wrote:

>The principles of Wikipedia are based upon Clue?  Well, then, I say
>it was Colonel Mustard in the ballroom with a candlestick.

Clue?  d'oh!

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


subject:
[Wikitech-l] can I add parameters to hooks used by
 twoextensions(spellchecker and svn blame-like view)

body:
Mark Clements wrote:
> "Rob Church" <robchur at gmail.com> wrote in
> message news:e92136380612131311x24e8cf0cpe0ad70aeaf678b87 at mail.gmail.com...
>> On 13/12/06, Dave Grogan <dgrogan at gmail.com>
> wrote:
>>> The spellchecker needs a hook near the end of getEditToolbar that is
>>> passed the toolbar variable.  The extension adds a spellcheck button to
>>> the toolbar.
>> You couldn't just use the existing JavaScript-based support functions
>> for adding custom edit buttons?
>
> Or look at how http://www.mediawiki.org/wiki/Extension:Add_Button does it.

Thank you for this link.

>>> Track Changes needs ArticleSaveComplete to also pass $revisionId (id of
>>> the newly-saved revision) and a flag that determines whether the content
>>> of the article changed.
>> That sounds sane enough to me.
>>
> I was under the impression that the article was never saved if the content
> hasn't changed, and therefore the hook wouldn't trigger in that situation
> anyway.

No new revision is saved but the hook is run.  See Article.php, lines
1285-90 and 1359-63 in v1.8.2.

> Also, $revisionID should be available through the article object that is
> already passed to the hook.  If not, then that is where it should be added,
> not as an extra hook parameter.

A revisionID is available through the article object, but it is the id
of the previously retrieved page, not the newly inserted one.  The id of
the newly-inserted page is not passed to the hook in any of the current
parameters, as far as I can tell (var_dumps and some ctrl-f-ing).

>>> Track changes needs SkinTemplateTabs to pass in revid and oldid so that
>>> it can display oldid if specified in the query string or revid if it
> was:
>>> $oldid = $wgRequest->getVal( 'oldid' );
>>> global $wgArticle;
>>> $revid = $wgArticle ? $wgArticle->getLatest() : 0;
>
> Not very clear about this point.  Can you elaborate?

The SkinTemplateTags hook calls an extension function that adds the
track changes tab shown in the screenshot.  The "track changes" tab
needs to pass a parameter to the TrackChanges page telling it what
revision to display.  The SkinTemplate class has access to wgArticle, so
it can pass the id of the article's latest revision.  However, if the
user is viewing an older revision of the document, as specified by the
oldid query parameter,
eg
http://www.mediawiki.org/w/index.php?title=Extension:Add_Button&oldid=52330
then the TrackChanges extension should display that older revision.  It
is not necessary that both of those be passed in (the logic for figuring
out which one to display could be moved from the tab-adding extension to
SkinTemplate) but SkinTemplate needs to communicate the requested
revision to the extension that adds the "track changes" tab somehow.


from_name: Marc Riddell

subject: [WikiEN-l] Categories (was: Hello)

body:
"For what do you hunger, Lord?" Moneo ventured.
??????? "For a humankind which can make truly long-term decisions.? Do you
know the key to that ability, Moneo?"
??????? "You have said it many times, Lord. ? It is the ability to change
your mind."
            Frank Herbert - "God Emperor of Dune" (p.55)

I have read everything that has been written here, as well as the links
detailing Wikipedia's history on the subject. A lot of thought - some
excellent ideas. But change can happen only if enough people believe it
needs to. I believe the Wiki Category system needs some serious study &
re-evaluation. Does anyone else believe it's worth a try?

Marc

> From: Marc Riddell <michaeldavid86 at comcast.net>
> Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
> Date: Wed, 13 Dec 2006 14:44:38 -0500
> To: English Wikipedia <wikien-l at Wikipedia.org>
> Subject: Re: [WikiEN-l] Categories (was: Hello)
>
> David,
>
> I read it. A crowd can never come to a decision about anything; they can
> only make enough noise to call attention to the fact that a decision needs
> to be made. At some point, very early in its history, there was no Wikipedia
> crowd. How, and by whom, were the decisions made that evolved into what
> Wikipedia is now?
>
> Marc
>
>> From: "David Gerard" <dgerard at gmail.com>
>> Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
>> Date: Wed, 13 Dec 2006 18:56:09 +0000
>> To: "English Wikipedia" <wikien-l at wikipedia.org>
>> Subject: Re: [WikiEN-l] Categories (was: Hello)
>>
>> On 13/12/06, Marc Riddell <michaeldavid86 at comcast.net> wrote:
>>
>>> I am not suggesting that a "small committee" (your term) fix the problems of
>>> Wikipedia - just one small part of it. And, if flexibility leads to chaos
>>> then it does more harm than good - and is ultimately destructive.
>>
>>
>> The trouble is that this trick never works. See [[WP:PRO]] for an
>> explanation.
>>
>>
>> - d.
>> _______________________________________________
>> WikiEN-l mailing list
>> WikiEN-l at Wikipedia.org
>> To unsubscribe from this mailing list, visit:
>> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l


from_name: Alphax (Wikipedia email)

subject:
[WikiEN-l] Completely unreasonable block and behavior by admin
 friends of Itaqallah to win a content dispute

body:
Parker Peters wrote:
> I like to think that, since I've continued to use this and stood by my words
> in this email account, it'd be clear by now that this is not a "throwaway"
> account.
>

Maybe it's not, but without a username and contributions you will
continue to be dismissed as an outsider.

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

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


subject: [WikiEN-l] Categories (was: Hello)

body:
I would recommend someone building a yahoo/dmoz style interface for
Wikipedia, using the categories. If we have that interface, people will do
the work to make categories work better.

On 12/13/06, Marc Riddell <michaeldavid86 at comcast.net> wrote:
>
> "For what do you hunger, Lord?" Moneo ventured.
> "For a humankind which can make truly long-term decisions. Do you
> know the key to that ability, Moneo?"
> "You have said it many times, Lord. It is the ability to change
> your mind."
>             Frank Herbert - "God Emperor of Dune" (p.55)
>
> I have read everything that has been written here, as well as the links
> detailing Wikipedia's history on the subject. A lot of thought - some
> excellent ideas. But change can happen only if enough people believe it
> needs to. I believe the Wiki Category system needs some serious study &
> re-evaluation. Does anyone else believe it's worth a try?
>
> Marc
>
> > From: Marc Riddell <michaeldavid86 at comcast.net>
> > Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
> > Date: Wed, 13 Dec 2006 14:44:38 -0500
> > To: English Wikipedia <wikien-l at Wikipedia.org>
> > Subject: Re: [WikiEN-l] Categories (was: Hello)
> >
> > David,
> >
> > I read it. A crowd can never come to a decision about anything; they can
> > only make enough noise to call attention to the fact that a decision
> needs
> > to be made. At some point, very early in its history, there was no
> Wikipedia
> > crowd. How, and by whom, were the decisions made that evolved into what
> > Wikipedia is now?
> >
> > Marc
> >
> >> From: "David Gerard" <dgerard at gmail.com>
> >> Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
> >> Date: Wed, 13 Dec 2006 18:56:09 +0000
> >> To: "English Wikipedia" <wikien-l at wikipedia.org>
> >> Subject: Re: [WikiEN-l] Categories (was: Hello)
> >>
> >> On 13/12/06, Marc Riddell <michaeldavid86 at comcast.net> wrote:
> >>
> >>> I am not suggesting that a "small committee" (your term) fix the
> problems of
> >>> Wikipedia - just one small part of it. And, if flexibility leads to
> chaos
> >>> then it does more harm than good - and is ultimately destructive.
> >>
> >>
> >> The trouble is that this trick never works. See [[WP:PRO]] for an
> >> explanation.
> >>
> >>
> >> - d.
> >> _______________________________________________
> >> WikiEN-l mailing list
> >> WikiEN-l at Wikipedia.org
> >> To unsubscribe from this mailing list, visit:
> >> http://mail.wikipedia.org/mailman/listinfo/wikien-l
> >
> > _______________________________________________
> > WikiEN-l mailing list
> > WikiEN-l at Wikipedia.org
> > To unsubscribe from this mailing list, visit:
> > http://mail.wikipedia.org/mailman/listinfo/wikien-l
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


body:
>>> The spellchecker needs a hook near the end of getEditToolbar that is
>>> passed the toolbar variable.  The extension adds a spellcheck button to
>>> the toolbar.
>> You couldn't just use the existing JavaScript-based support functions
>> for adding custom edit buttons?
>
> Or look at how http://www.mediawiki.org/wiki/Extension:Add_Button does it.

It might be possible to use a similar method as this extension.
Add_Button stuffs its custom js into the page by way of the
ParserBeforeTidy hook.  Do you know of a more appropriate hook offhand?

>>> Track changes needs SkinTemplateTabs to pass in revid and oldid so that
>>> it can display oldid if specified in the query string or revid if it
> was:
>>> $oldid = $wgRequest->getVal( 'oldid' );
>>> global $wgArticle;
>>> $revid = $wgArticle ? $wgArticle->getLatest() : 0;
>
> Not very clear about this point.  Can you elaborate?

I'd like to retract the paragraph in my previous e-mail.  This code was
moved entirely into the extension:

global $wgArticle, $wgRequest;
$oldid = $wgRequest->getVal( 'oldid' );
$revid = $wgArticle ? $wgArticle->getLatest();

The extra parameters to the SkinTemplateTabs hook are no longer needed.

Thanks.


from_name: Michael Noda

subject: [WikiEN-l] Categories

body:
On 12/13/06, Marc Riddell <michaeldavid86 at comcast.net> wrote:
> Stan,
>
> You're absolutely right (on most counts ;). The one I have trouble getting
> my mind around is, "this ain't ever going to happen". Crowds, noise and,
> yes, the occasional violence have always been crucial in bringing attention
> to the need for change. But, what always has ultimately brought about that
> change is a small group of dedicated, focused people coming together to plan
> the substance of that change.

Yes, but our "small group of dedicated, focused people" is busy
implementing single signon.  ;-)

Although the above statement is meant to be tongue-in-cheek, the
kernel of truth in it is that making the category system sane will
require major technical changes, which will require nearly the full
attention of our core developers.  Since they're already backlogged on
at least two high-priority tech upgrades, there's little to be gained
by asking them to devote time to the Category Question just now.
Unlike other respondents, I think it can and will be fixed, but I
agree that *it will not be fixed soon.*

Until then, I would otherwise recommend the CatScan tool on the
Toolserver, but the Toolserver hasn't updated from en since June; a
situation which certainly hasn't escaped the notice of the community
of Toolserver users on en.  So until a functioning toolserver is
restored to our lives, I'm afraid there's no good way to solve this
problem.


from_name: Thomas Dalton

subject: [WikiEN-l] new Google Earth tie-in (!!)

body:
> The history on our servers. Where's their copy?

Why do they need a copy? It doesn't matter where the history is
hosted, as long as it is linked to.


subject: [WikiEN-l] new Google Earth tie-in (!!)

body:
> No, that's just what I doubt we could handle.  We're on the edge
> of our capacity a lot, these days, I think, and while I don't
> know how many Google Earth users there are out there and how
> often they're going to be clicking on these new Wikipedia
> placemarks, it could be a *lot*.

Maybe we can get Google to donate us an extra server, then.


subject: [WikiEN-l] Categories

body:
Patience is a virtue (or so I've been told) - and since it's the only one I
have left - I am willing to wait. In the meantime, I would love to know
there are some concrete proposals being worked on.

Marc

> From: "Michael Noda" <michael.noda at gmail.com>
> Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
> Date: Wed, 13 Dec 2006 18:19:47 -0500
> To: "English Wikipedia" <wikien-l at wikipedia.org>
> Subject: Re: [WikiEN-l] Categories
>
> On 12/13/06, Marc Riddell <michaeldavid86 at comcast.net> wrote:
>> Stan,
>>
>> You're absolutely right (on most counts ;). The one I have trouble getting
>> my mind around is, "this ain't ever going to happen". Crowds, noise and,
>> yes, the occasional violence have always been crucial in bringing attention
>> to the need for change. But, what always has ultimately brought about that
>> change is a small group of dedicated, focused people coming together to plan
>> the substance of that change.
>
> Yes, but our "small group of dedicated, focused people" is busy
> implementing single signon.  ;-)
>
> Although the above statement is meant to be tongue-in-cheek, the
> kernel of truth in it is that making the category system sane will
> require major technical changes, which will require nearly the full
> attention of our core developers.  Since they're already backlogged on
> at least two high-priority tech upgrades, there's little to be gained
> by asking them to devote time to the Category Question just now.
> Unlike other respondents, I think it can and will be fixed, but I
> agree that *it will not be fixed soon.*
>
> Until then, I would otherwise recommend the CatScan tool on the
> Toolserver, but the Toolserver hasn't updated from en since June; a
> situation which certainly hasn't escaped the notice of the community
> of Toolserver users on en.  So until a functioning toolserver is
> restored to our lives, I'm afraid there's no good way to solve this
> problem.
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l


from_name: Steve Sanbeg

subject:
[Wikitech-l] updated labeled section transclusion - request for
	feedback

body:
I've made some updates to the labeled section transclusion extension,
which is described at

http://www.mediawiki.org/wiki/Extension:Labeled_Section_Transclusion

I'm hoping to have this installed on wikisource, so I'd appreciate any
feedback on the implementation (i.e. code review) to help me towards that.

The main changes since it was last discussed on this list are:

1) #lst counts headings in the text that were skipped before the section, so
edit links can be offset appropriately (similar to desired behavior
desired in bug 6563)

2) By request, a new function, #lsth, allows translcuding sections by visual
headings. Since this isn't crucial for the wikisource projects, it's
implemented in a separate file, like an extension to the extension.  I'd be
interested to know whether this seems like something that would be useful
for wikimedia projects, or should just be an optional extension for smaller
wikis.

Thanks
  -Steve


from_name: Steve Summit

body:
Rob Church wrote:
> On 13/12/06, Steve Summit <scs at eskimo.com> wrote:
>> Hey!  When did that new placeholder message get added to an otherwise
>> empty (and therefore otherwise potentially misleading) diff listing?
>
> Why don't you look at the subversion log?

Because that would merely answer my question (which I don't
really care about the answer to), and do nothing to express my
appreciation to the various people who had, implemented, and
deployed that nice little touch!

(Also because I don't know off the top of my head where the
subversion log is, but that's beside the point.)


from_name: Andrew Gray

subject: [WikiEN-l] new Google Earth tie-in (!!)

body:
On 13/12/06, Thomas Dalton <thomas.dalton at gmail.com> wrote:
> > We (and they) are in a rock-and-a-hard-place situation.  It's
> > good that they're working from their own stashed copy instead of
> > hitting us live, because I doubt our servers could handle their
> > users' load.  But of course on the other hand it's supremely
> > annoying that they're working from their own stashed copy,
> > because (as you note and I emphatically agree) our lovely
> > instantaneous wiki-quick edit-save-test loop is broken.
>
> Why can't we have the best of both worlds? They get the co-ordinates
> from the database dumps, but when a user clicks on the globe icon they
> get the live page. We should be able to handle the load if our servers
> are only hit when a user actually tries to read the page.

You'd think that. We regularly block "live mirrors" and so forth,
because we're having enough trouble handling our own load much less
anyone else's. The exceptions are usually either low-traffic and vital
(there's a smallish email-webpages service operating in Africa which
we let grab stuff on demand, IIRC) or paid for (people like
answers.com)

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


from_name: David Gerard

subject: [WikiEN-l] Categories (was: Hello)

body:
On 13/12/06, Marc Riddell <michaeldavid86 at comcast.net> wrote:

> I am not suggesting that a "small committee" (your term) fix the problems of
> Wikipedia - just one small part of it. And, if flexibility leads to chaos
> then it does more harm than good - and is ultimately destructive.

The trouble is that this trick never works. See [[WP:PRO]] for an explanation.

- d.


subject: [WikiEN-l] new Google Earth tie-in (!!)

body:
On 12/13/06, The Cunctator <cunctator at gmail.com> wrote:
> On 12/13/06, Anthony <wikilegal at inbox.org> wrote:
> > It doesn't seem right to me giving special permission to a company
> > which makes proprietary software and distributes watermarked
> > proprietary maps, some of which are just public domain maps with a
> > watermark and a spurious claim of copyright on them.
>
>
> kind of have to agree there. but i guess if you pay off the foundation....
>
It's not like it's that much money, though.  Royalty income doesn't
even make its own category on the financials (presumably it's included
in the $56 thousand of other income), and with half a million dollars
sitting in a bank account earning little or no interest (some of it
not even FDIC insured), it's not like the money is desperately needed.
 I say get behind World Wind and/or some other free software.  Make it
a point to *not* support Google Earth.  That's worth more in my
opinion.

And if you're gonna sell out, at least make a decent amount doing so
:).  I think it's just that Google has a certain blind love from a
certain community which overlaps with the former members of Wikimedia.
 I can understand it, I respect Google and its founders, and I think a
lot of the things Google does are great and revolutionary.  But I'm
also the kind of person who can respect a company but still believe I
have a duty to fight against certain things it's doing.

Anthony


from_name: Rob Church

subject: [Wikitech-l] Htdig, mailman & broken links

body:
On 13/12/06, Jay R. Ashworth <jra at baylink.com> wrote:
> And indeed, the URL with *pipermail* in it currently *is* returning 404.

For our next trick, ladies and gentlemen, we will be altering mailman
to zap spammers. Watch this space...

Rob Church


from_name: Gregory Maxwell

subject: [WikiEN-l] new Google Earth tie-in (!!)

body:
On 12/13/06, Anthony <wikilegal at inbox.org> wrote:
[snip]
>  I say get behind World Wind and/or some other free software.
[snip]

I'd love to see world wind with better Wikipedia integration, however
world wind has huge Microsoft dependencies and it seems there is no
remote hope of getting it to work on my Linux systems anytime soon..
so I can't even help out directly.

World Wind support is a worthy cause, and everyone would like to see
it.  Please don't mix up worthy causes with what is, frankly, trolling
and nonsense speculation about "selling out".


from_name: Michael Bimmler

body:
On 12/13/06, Jay R. Ashworth <jra at baylink.com> wrote:
> On Wed, Dec 13, 2006 at 02:41:57PM +0000, Timwi wrote:
> > Can you please make http://mail.wikipedia.org/mailman/htdig/wikien-l
> > return a 404 or some other error if it's not supposed to be correct?
>
> Well, perhaps there was a transient failure.  That URL returns the
> Archive index page to me now.
>
Sure it returns the same output as
http://mail.wikipedia.org/mailman/pipermail/wikien-l but with broken
links.
Michael
> Cheers,
> -- jra
> --
> Jay R. Ashworth                                                jra at baylink.com
> Designer                          Baylink                             RFC 2100
> Ashworth & Associates        The Things I Think                        '87 e24
> St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


from_name: Mark Clements

subject:
[Wikitech-l] can I add parameters to hooks used by two
	extensions(spellchecker and svn blame-like view)

body:
"David Grogan" <dgrogan at gmail.com> wrote in
message news:cb6d7dc50612130850s74267de2s2f943af0c1c75224 at mail.gmail.com...
> I've co-authored two extensions that need an additional hook and
> additional parameters to two existing hooks.  I am requesting commit
> access so that I may upload the extensions and amend the hooks.
>

What hook and what parameters?

- Mark Clements (HappyDog)


list: commons-l

from_name: Bryan Tong Minh

subject: [Commons-l] New tool - User dupes

body:
That's a pity, since it would have been very handy for auto comparing images.

Bryan

On 12/12/06, Magnus Manske <magnusmanske at googlemail.com> wrote:
> On 12/12/06, Bryan Tong Minh <bryan.tongminh at gmail.com> wrote:
> > On 12/4/06, Magnus Manske <magnusmanske at googlemail.com> wrote:
> > > There was a discussion somewhere (maybe on this list? I don't
> > > remember) to store MD5-hashes of image data in the table with the
> > > other image information (size etc.). Nothing came of it, I'm afraid.
> > > Too bad.
> > What was the reason for this? Was it the technical difficulties, or
> > just a lack of willingness?
>
> I'd say 10% the former (MD5ing all existing images on all wikipedias
> and commons would mean server stress), and 90% the latter.
>
> Magnus
> _______________________________________________
> Commons-l mailing list
> Commons-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/commons-l
>


from_name: NSLE (Wikipedia)

body:
Houston, TX, eh? Wasn't Enviroknot from Houston?

On 13/12/06, Tariq Ab- Jo- Tu- <tariqabjotu at gmail.com> wrote:
>
> And they're both Houston, Texas IP addresses... (see WP:ANI post under
>
> http://en.wikipedia.org/wiki/WP:ANI#RunedChozo_.28talk_.E2.80.A2_contribs.29_blocked
> ,
> earlier e-mail). The coincidences seem just too many.
>
> Luna wrote:
> > George Herbert wrote:
> >
> >
> >> As far as I can see, it's entirely over his editing of his talk page,
> >> removing unblock request refusals and re-unblock-requesting, plus
> >> arguing with people there.
> >>
> >> As a personal opinion - lengthening blocks due to ongoing argument
> >> ONLY on a blockee's talk page is among the worst abuses that a pack of
> >> administrators can commit, ganging up on someone.
> >>
> >> RunedChozo came into the argument with a bunch of abuses he'd
> >> committed counting against him, and certainly was being disruptive on
> >> several levels.  He did have one point that I see - Itaquallah did use
> >> inappropriate edit summaries and remove material with source info
> >> claiming it's unsourced.  There was a two-sided abusive edit war going
> >> on; Itaquallah was not an innocent party there, and should have been
> >> warned against that.
> >>
> >> It's hard to see this and not wonder if RunedChozo is too disruptive
> >> to be a Wikipedia participant, but a bunch of admins have gone and
> >> collectively beaten up on someone in a way which is not called for or
> >> appropriate.  If someone can't stop being a dick on their talk page
> >> while they're blocked, admins need to just walk away and let them cool
> >> down.
> >>
> >> Bad day.
> >>
> >
> >
> > All in all, I like that post. I don't think we'll all completely agree
> on
> > everything, but you're attempting to be fair and objective, and I like
> that.
> >
> >
> > Moving on to the checkuser results -- Essjay reports that it's
> "possible"
> > RunedChozo and 70.114.237.14 are the same person.
> >
> > "Possible" means just that. It's objectively possible that it's the same
> > person, but also objectively possible that it's not -- meaning that
> there
> > are other people active in this IP range, most likely. We're probably
> not
> > going to get a solid result, through checkuser; that evidence seems
> > circumstantial.
> >
> > George Herbert brings up an interesting point -- RunedChozo has a strong
> > tendency to edit at about 10:00-15:00 (my time), but 70.114.237.14 was
> > editing only between 20:00-23:00 (my time). I can only find two
> exceptions
> > to this, in RunedChozo's edit history:
> >
> >
> http://en.wikipedia.org/w/index.php?title=User_talk:RunedChozo&diff=prev&oldid=88763202
> >
> http://en.wikipedia.org/w/index.php?title=User_talk:RunedChozo&diff=prev&oldid=88763010
> >
> > Both were on 18 November, at about 22:40. This seems to hint away from
> > RunedChozo being 70.114.237.14, but given such a brief sampling, it's
> > difficult to be entirely certain. We know that he *can* stay up until
> > whatever time that is, locally, but also that he does so rarely.
> >
> > 70.114.237.14 has two main "periods" -- once, at 20:16-20:34 on 10
> December
> > (about half a day before RunedChozo's block @ 11:45, 11 December), where
> the
> > primary activity was apparently trolling at Striver. It's possible this
> was
> > another user, or also possible it was a registered user logging out to
> > attempt to avoid responsibility for attacks. The IP's second block of
> edits
> > comes at 21:32-22:34, 11 December (about 10 hours after RunedChozo's
> block),
> > and the first edit again attacks Striver. The IP then proceeds to the
> AN/I
> > thread RunedChozo started, and makes some more attacks before being
> blocked,
> > at which point it continues at its talk page.
> >
> > Given the IP started its second block by attacking Striver, I think we
> can
> > at least assume the 70.114.237.14 was the same user, both days.
> >
> > So, I decided to check if RunedChozo has had any previous interaction
> with
> > Striver. He has. On 14 November, he made two edits to Striver's talk
> page:
> >
> >
> http://en.wikipedia.org/w/index.php?title=User_talk:Striver&diff=prev&oldid=87786569
> >
> http://en.wikipedia.org/w/index.php?title=User_talk:Striver&diff=prev&oldid=87795801
> >
> > They appear to have been clashing over these:
> >
> http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Beit_Hanoun_November_2006_incident
> >
> http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Israeli_shelling_of_Beit_Hanoun
> >
> > This evidence doesn't seem to clearly pin RunedChozo as 70.114.237.14,
> but
> > it does establish that he had an antagonistic relationship with Striver,
> and
> > we do know that 70.114.237.14 attacked Striver's userpage.
> >
> > I can see a few other similarities between RunedChozo and 70.114.237.14.
> > Both consider Striver to be an anti-Israeli POV-pusher and/or
> anti-semite.
> > Both consider the Muslim Guild to be a group of meatpuppets or some
> other
> > form of conspiracy.
> >
> > They both refer to Future Perfect as a "tool"
> >
> http://en.wikipedia.org/w/index.php?title=Talk:Muhammad_as_a_diplomat&diff=prev&oldid=93636099
> >
> http://en.wikipedia.org/w/index.php?title=User_talk:Future_Perfect_at_Sunrise&diff=prev&oldid=93633482
> >
> http://en.wikipedia.org/w/index.php?title=Wikipedia:Administrators%27_noticeboard/Incidents&diff=prev&oldid=93753665
> >
> > Both call Tariqabjotu and Itaqallah "liars" frequently
> >
> http://en.wikipedia.org/w/index.php?title=User_talk:RunedChozo&diff=prev&oldid=93664423
> >
> http://en.wikipedia.org/w/index.php?title=User_talk:RunedChozo&diff=prev&oldid=93688036
> >
> http://en.wikipedia.org/w/index.php?title=Wikipedia:Administrators%27_noticeboard/Incidents&diff=prev&oldid=93760600
> >
> http://en.wikipedia.org/w/index.php?title=Wikipedia:Administrators%27_noticeboard/Incidents&diff=prev&oldid=93628825
> >
> http://en.wikipedia.org/w/index.php?title=Wikipedia:Administrators%27_noticeboard/Incidents&diff=prev&oldid=93761034
> >
> > And as is no doubt obvious to any interested party by this point, they
> both
> > seem to have a high interest in the exact same AN/I thread and the same
> > article (Beit Hanoun November 2006 incident).
> >
> > So, what do we think?
> >
> > -Luna
> > _______________________________________________
> > WikiEN-l mailing list
> > WikiEN-l at Wikipedia.org
> > To unsubscribe from this mailing list, visit:
> > http://mail.wikipedia.org/mailman/listinfo/wikien-l
> >
> >
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


body:
On 12/13/06, Jay R. Ashworth <jra at baylink.com> wrote:
> On Wed, Dec 13, 2006 at 07:54:30PM +0100, Michael Bimmler wrote:
> > On 12/13/06, Jay R. Ashworth <jra at baylink.com> wrote:
> > > On Wed, Dec 13, 2006 at 02:41:57PM +0000, Timwi wrote:
> > > > Can you please make http://mail.wikipedia.org/mailman/htdig/wikien-l
> > > > return a 404 or some other error if it's not supposed to be correct?
> > >
> > > Well, perhaps there was a transient failure.  That URL returns the
> > > Archive index page to me now.
>
> > Sure it returns the same output as
> > http://mail.wikipedia.org/mailman/pipermail/wikien-l but with broken
> > links.
>
> So it does, but "please make the URL return 404 *instead of a page witn
> inoperative links" is a different trouble report.
>
well. My original report was "please fix the links". Brion then said,
this page shouldn't be used. So Timwi said "please make it return
404".
> :-)
>
> And indeed, the URL with *pipermail* in it currently *is* returning 404.
>
Yes, you have to strike the 'mailman' bit out of it.
http://mail.wikipedia.org/pipermail/wikien-l/ works.
Michael
> Cheers,
> -- jra
> --
> Jay R. Ashworth                                                jra at baylink.com
> Designer                          Baylink                             RFC 2100
> Ashworth & Associates        The Things I Think                        '87 e24
> St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


from_name: Steve Block

subject: [WikiEN-l] Hello

body:
On 12/12/06, Marc Riddell <michaeldavid86 at comcast.net> wrote:
> I have been in constant conflict with some who state that it is not
> only redundant to enter a single Article into both Categories; it
> is actually against Wikipedia policy. At present, if I enter John
> Doe into the ?Suicides by firearm? Category only, he does not
> appear in the ?Deaths by firearm? Category list. Consequently, if I
> want to call up all persons in the encyclopedia who have died by
> firearm, I must call up all the subcategory lists and collate them
> myself.

This has been knocked about a few times, and the latest proposal put
forward that I recall was
http://en.wikipedia.org/wiki/Wikipedia:Category_intersection which the
tech opinion felt might strain the servers, looking at the talk page it
appears the tables might take at least several seconds to display. Or
something.  I don't pretend to understand it, to be honest.  I only know
it would be a useful feature but it is difficult to practically implement.

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.15.18/584 - Release Date: 12/12/06


from_name: Rory Stolzenberg

body:
On 12/13/06, Timwi <timwi at gmx.net> wrote:
>
> Bogdan Giusca wrote:
> > I think the first fair use criterium should be more clearly written:
> > it seems that many people think that the part about a replacement
> > which could be "reasonably be found or created" excludes the variant
> > of getting out of the house and taking a picture. :-)
>
> The following isn't entirely related to the above, but I'm quoting it
> anyway because it reminded me that I was going to mention this at some
> point.
>
> So suppose an article has no picture, and a contributor wishes to add a
> picture to that one specific thing. What are the odds that this specific
> contributor gets a realistic chance of taking a photograph of the topic
> of that specific article, be it a celebrity, a sight or a building?
>
> Take me as an example. I live in [[Cambridge]]. I'm not particularly
> interested in sight-seeing or architecture, so I know little about the
> sights and buildings in this city. However, I would be happy to take
> (free-license) pictures of something in this city and upload them to
> Commons (indeed I have already done so for some of the Colleges). The
> problem (for Commons/Wikipedia) is that I don't know, and don't have
> much interest or motivation in researching, what sights or buildings
> exist in this city that don't already have a free picture on
> Commons/Wikipedia.
>
> Similarly for people. Imagine (hypothetically) that I'm planning to
> visit an event where I will likely see some celebrities. If there was a
> way for me to find out which OF THOSE celebrities don't already have a
> free picture on Commons/Wikipedia, it would be easier to know in advance
> which celebrities to focus on. The way it's now, however, I will likely
> just not care and only take images of things that /I/ want, not the
> things that Commons or Wikipedia needs.
>
> So, in summary: Commons or Wikipedia needs an organised index or
> catalogue of things that don't have a free picture. Ideally, there
> should be somewhere I can click to list the things in Cambridge that
> don't have a picture.
>
> Timwi
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

You could start by looking at
http://en.wikipedia.org/wiki/Category:Wikipedia_requested_photographs_in_Cambridgeshireand
its parent categories.


subject: [WikiEN-l] new Google Earth tie-in (!!)

body:
On 12/12/06, Eugene van der Pijll <eugene at vanderpijll.nl> wrote:
> Steve Summit schreef:
> > Google aside, this stuff needs cleaning up.  For example, it's
> > not at all uncommon to have a {{coor title d}} saying one thing
> > at the top of the page, and another {{coor dms}} in-line in the
> > article text, with slightly (or significantly) different
> > coordinates.
>
> Note that it is not always a bug to have more than one set of
> coordinates in an article. See for example [[Carnac stones]] or [[List
> of cities, towns and villages in Utrecht]].
>
> Perhaps there should be a "noindex" parameter, which would enable Google
> and others to exclude these from their databases?

Or, indeed, a "multiplecoords" parameter - it would make sense to give
multiple points for individual occurences of a same thing not dealt
with in individual articles.

Thing is, we've two kinds of multiple links - ones which are basically
navigational in a list, and ones which are "one thing many places". We
probably need to figure out a way of telling Google Earth, and the
things like it, that [[Carnac Stones]] is a sensible linkback for any
given incidence of a coord taken from that article, but [[Villages in
Utrecht]] isn't...

> By the way, if you are impressed with the new Google Earth layer, you
> may also want to take a look at Stefan Kuehn's GE data files at
> http://www.webkuehn.de/hobbys/wikipedia/geokoordinaten/index.htm

Thanks for the pointer.

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


from_name: James Hare

body:
The Mother Category:

http://en.wikipedia.org/wiki/Category:Wikipedia_requested_photographs

Bam.

Wheeeeeeeeee

On 12/13/06, Rory Stolzenberg <rory096 at gmail.com> wrote:
>
> On 12/13/06, Timwi <timwi at gmx.net> wrote:
> >
> > Bogdan Giusca wrote:
> > > I think the first fair use criterium should be more clearly written:
> > > it seems that many people think that the part about a replacement
> > > which could be "reasonably be found or created" excludes the variant
> > > of getting out of the house and taking a picture. :-)
> >
> > The following isn't entirely related to the above, but I'm quoting it
> > anyway because it reminded me that I was going to mention this at some
> > point.
> >
> > So suppose an article has no picture, and a contributor wishes to add a
> > picture to that one specific thing. What are the odds that this specific
> > contributor gets a realistic chance of taking a photograph of the topic
> > of that specific article, be it a celebrity, a sight or a building?
> >
> > Take me as an example. I live in [[Cambridge]]. I'm not particularly
> > interested in sight-seeing or architecture, so I know little about the
> > sights and buildings in this city. However, I would be happy to take
> > (free-license) pictures of something in this city and upload them to
> > Commons (indeed I have already done so for some of the Colleges). The
> > problem (for Commons/Wikipedia) is that I don't know, and don't have
> > much interest or motivation in researching, what sights or buildings
> > exist in this city that don't already have a free picture on
> > Commons/Wikipedia.
> >
> > Similarly for people. Imagine (hypothetically) that I'm planning to
> > visit an event where I will likely see some celebrities. If there was a
> > way for me to find out which OF THOSE celebrities don't already have a
> > free picture on Commons/Wikipedia, it would be easier to know in advance
> > which celebrities to focus on. The way it's now, however, I will likely
> > just not care and only take images of things that /I/ want, not the
> > things that Commons or Wikipedia needs.
> >
> > So, in summary: Commons or Wikipedia needs an organised index or
> > catalogue of things that don't have a free picture. Ideally, there
> > should be somewhere I can click to list the things in Cambridge that
> > don't have a picture.
> >
> > Timwi
> >
> > _______________________________________________
> > WikiEN-l mailing list
> > WikiEN-l at Wikipedia.org
> > To unsubscribe from this mailing list, visit:
> > http://mail.wikipedia.org/mailman/listinfo/wikien-l
> >
>
> You could start by looking at
>
> http://en.wikipedia.org/wiki/Category:Wikipedia_requested_photographs_in_Cambridgeshireand
> its parent categories.
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Ray Saintonge

subject: [WikiEN-l] Hello

body:
Timwi wrote:

>charles.r.matthews at ntlworld.com wrote:
>
>
>>That does not mean that I want [[Category:Mathematics]] to consist of
>>15000 pages. How would that help anyone?
>>
>>
>This seems to be an extremely widespread and popular fallacy. "/I/ can't
>think of any use for it, therefore we mustn't have it." Could you all
>please think about this for 1 second and realise that it's a total fallacy?
>
"No use for it" and "no help to anyone" are still different questions.
We need to distinguish between the content itself and how we organise
it.  Huge categories are subject to the law of diminishing returns.  If
a Google search gives you 1,000,000 hits it doesn't help anyone to go
through them all, so you develop strategies to seriously trim the results.

Being able to collapse or expand categories would be a great feature.

Ec


from_name: Timwi

body:
Bogdan Giusca wrote:
> I think the first fair use criterium should be more clearly written:
> it seems that many people think that the part about a replacement
> which could be "reasonably be found or created" excludes the variant
> of getting out of the house and taking a picture. :-)

The following isn't entirely related to the above, but I'm quoting it
anyway because it reminded me that I was going to mention this at some
point.

So suppose an article has no picture, and a contributor wishes to add a
picture to that one specific thing. What are the odds that this specific
contributor gets a realistic chance of taking a photograph of the topic
of that specific article, be it a celebrity, a sight or a building?

Take me as an example. I live in [[Cambridge]]. I'm not particularly
interested in sight-seeing or architecture, so I know little about the
sights and buildings in this city. However, I would be happy to take
(free-license) pictures of something in this city and upload them to
Commons (indeed I have already done so for some of the Colleges). The
problem (for Commons/Wikipedia) is that I don't know, and don't have
much interest or motivation in researching, what sights or buildings
exist in this city that don't already have a free picture on
Commons/Wikipedia.

Similarly for people. Imagine (hypothetically) that I'm planning to
visit an event where I will likely see some celebrities. If there was a
way for me to find out which OF THOSE celebrities don't already have a
free picture on Commons/Wikipedia, it would be easier to know in advance
which celebrities to focus on. The way it's now, however, I will likely
just not care and only take images of things that /I/ want, not the
things that Commons or Wikipedia needs.

So, in summary: Commons or Wikipedia needs an organised index or
catalogue of things that don't have a free picture. Ideally, there
should be somewhere I can click to list the things in Cambridge that
don't have a picture.

Timwi


from_name: Anthony

subject: [WikiEN-l] new Google Earth tie-in (!!)

body:
On 12/13/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> World Wind support is a worthy cause, and everyone would like to see
> it.  Please don't mix up worthy causes with what is, frankly, trolling
> and nonsense speculation about "selling out".

I think the term "selling out" is quite appropriate when an
organization dedicated to helping out the free content movement
"negotiates" to put its name on software like Google Earth
(proprietary software used to distribute proprietary content).

That's probably the difference of opinion I have which you hostilly
call "trolling", but if not feel free to point to which part it is.

Anthony

(*) If Gregory Maxwell is correct that the use of the logo was
"negotiated", which hasn't yet been confirmed.


subject: [WikiEN-l] Hello

body:
The Cunctator wrote:

>For Wikipedia's purposes, it would be much better to work on computation to
>"translate" the text.
>
>One of the fundamental tenets of wikis is that they remain as close to
>natural language and markup as possible -- the wiki format should remain
>readable.
>
>This:
>
>Paris is a [[type:=city]] in
>[[located in::France]], with a population of
>[[population:=1,000,000,000]].
>
>is not.
>
I don't know about the "translation", but some of us are old enough to
remember when articles were written in natural language.  Some
task-oriented people become so focused on what they believe would be
easy that they often forget that there's a real world out there where
people don't speak markup.

Ec


subject: [Commons-l] Fwd: [Wikitech-l] ImportFreeImages Extension

body:
Is there no way you can upload using your own commons login name?

Bryan

On 12/13/06, Bence Damokos <bdamokos at gmail.com> wrote:
> Well you could start by giving the one-click upload feature to admins on a
> local wiki, and maybe storing the uploaders name in a database, so it can be
> traced...
>
> Bence
>
>
> On 12/13/06, Artur Fija?kowski <wiki.warx at gmail.com> wrote:
> > 2006/12/13, Brianna Laugher <brianna.laugher at gmail.com>:
> > > On 13/12/06, Magnus Manske <magnusmanske at googlemail.com > wrote:
> > > > On 12/12/06, Bence Damokos <bdamokos at gmail.com> wrote:
> > > > >
> > > > > > I do not think this is good enough to celebrate. I'd welcome a
> tool that
> > > > > > would allow us to move properly licensed free images from
> wikipedias to
> > > > > > commons. Now I'd celebrate then.
> > > > >
> > > > > >
> > > > > >
> > > > > > *ahem*
> > > > > >
> > > > > >
> http://tools.wikimedia.de/~magnus/pushforcommons.php
> > > > >
> > > > > Is there a way, to have the one-click upload feature in the
> ImportFreeImages
> > > > > extension made available in the pushforcommons as well?
> > > >
> > > > PushForCommons uses CommonsHelper, which already has that option. But,
> > > > it is currently hidden, as all one-click uploads are then attributed
> > > > to a Commons upload bot. There was concern it might be abused. Now, if
> > > > there were consensus to enable this publicly, and if the toolserver
> > > > databases were back...
> > >
> > > I will continue to push very strongly that any toolserver-based tool,
> > > which does not require any kind of Wikimiedia login, should never
> > > allow essentially anonymous uploads to Commons, as this would. Many,
> > > many many Wikimedia wikis have lax, nonexistent or not-inforced image
> > > use policies. If we were to enable this all sorts of shit would be
> > > transferred and we would have no way of even identifying who had
> > > transferred it. All the cleanup and even no one specific to blame. ;)
> > > Not cool.
> > > So probably any tool like this should be part of MediaWiki. So we know
> > > what that means, chaps: settle in for a good long wait, or else write
> > > it yourself (and then settle back for that wait anyway...).
> > >
> > > cheers,
> > > Brianna
> > > user:pfctdayelise
> >
> > Sad but true - I would be same as with LonardoG, who was ''only''
> > moving ''free'' images from his own wiki, but we blamed him for
> > copyvios (I think we were 100% right).
> >
> > I someone gives to everyone such toy, he MUSTto know, that he takes
> > responsibility for that (cause of that my IRC bot interface needs
> > authorization and userrights  for uploading).
> >
> > AJF/WarX
> > _______________________________________________
> > Commons-l mailing list
> > Commons-l at wikimedia.org
> > http://mail.wikipedia.org/mailman/listinfo/commons-l
> >
>
>
> _______________________________________________
> Commons-l mailing list
> Commons-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/commons-l
>
>
>


from_name: Daniel R. Tobias

subject: [WikiEN-l] MONGO and the ArbCom

body:
Hey, let's try and set a new list record for most consecutive
repetitions of the list footer trailing at the bottom of an
insufficiently-trimmed top-posted reply!

On 12 Dec 2006 at 17:06, "Jim Schuler" <jim62sch at gmail.com> wrote:

> > > >>> _______________________________________________
> > > >>> WikiEN-l mailing list
> > > >>> WikiEN-l at Wikipedia.org
> > > >>> To unsubscribe from this mailing list, visit:
> > > >>> http://mail.wikipedia.org/mailman/listinfo/wikien-l
> > > >>>
> > > >>>
> > > >> _______________________________________________
> > > >> WikiEN-l mailing list
> > > >> WikiEN-l at Wikipedia.org
> > > >> To unsubscribe from this mailing list, visit:
> > > >> http://mail.wikipedia.org/mailman/listinfo/wikien-l
> > > >>
> > > >>
> > > > _______________________________________________
> > > > WikiEN-l mailing list
> > > > WikiEN-l at Wikipedia.org
> > > > To unsubscribe from this mailing list, visit:
> > > > http://mail.wikipedia.org/mailman/listinfo/wikien-l
> > > >
> > > >
> > > _______________________________________________
> > > WikiEN-l mailing list
> > > WikiEN-l at Wikipedia.org
> > > To unsubscribe from this mailing list, visit:
> > > http://mail.wikipedia.org/mailman/listinfo/wikien-l
> > >
> > _______________________________________________
> > WikiEN-l mailing list
> > WikiEN-l at Wikipedia.org
> > To unsubscribe from this mailing list, visit:
> > http://mail.wikipedia.org/mailman/listinfo/wikien-l
> >
>
>
>
> --
> Jim
> http://iacobomus.blogspot.com/

--
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/


from_name: Steve Bennett

subject: [WikiEN-l] Hello

body:
On 12/13/06, The Cunctator <cunctator at gmail.com> wrote:
> It pretty much defeats the purpose of having subcategories.
>
> By putting an article into a subcategory, you are effectively putting it
> into the parent category.
>
> Maybe we should figure out a way to make that more obvious.

There is absolutely nothing at all in MediaWiki that makes a page in a
subcategory behave like it's also in the parent category. Nothing.
It's completely and utterly a construct in the mind of the user.

Steve


subject: [WikiEN-l] Hello

body:
On 12/13/06, charles.r.matthews at ntlworld.com <charles.r.matthews at ntlworld.com>

> That does not mean that I want [[Category:Mathematics]] to consist of 15000 pages. How would that help anyone? I have actually done work, on [[Category:Set theory]] (where I was thanked) and [[Category:Fluid dynamics]] (perhaps unnoticed) on getting useful subcategories; which then can sit inside two or more higher-level categories. This all adds to the convenience of the user. It is quite a good idea, in many cases, to consider splitting categories which have gone 'over the page'.

Purely and simply, categories are useful for many things they weren't
designed for or intended to do. Remember, they were a cute hack
invented by Magnus a couple of years ago in the face of some pretty
serious skepticism.

I don't think it would take much to make them much more powerful, but
as long as most people think they're primarily a navigational tool,
using them to record all kinds of attributes about the subjects of
articles is going to run into a lot of criticism. As it already does.

Steve


subject: [WikiEN-l] Categories (was: Hello)

references:
<b8ceeef70612121917ra23c54cx2b5d31a436bf0ced@mail.gmail.com>
	<C1A4DF2E.4AF%michaeldavid86@comcast.net>
	<b8ceeef70612122019v13dd51f4yf37dc034c38dcb3a@mail.gmail.com>
	<aa08c93c0612122233v39275a03paa469605fa1838fc@mail.gmail.com>

body:
On 12/13/06, cohesion <cohesion at sleepyhead.org> wrote:
> On 12/12/06, Steve Bennett <stevagewp at gmail.com> wrote:
>
> > We have a current trend towards splitting big categories. We prefer a
> > single category "Dutch authors" rather than adding two massive
> > categories to an article: "Dutch people" and "Authors". However this
> > approach is pretty clearly a dead-end: how many times can we split?
> > What do we split on next, "Dead Dutch authors"? Good category
> > intersections would really help that one...
>
> I just wanted to point out semantic mediawiki extension, as it solves
> these problems fairly well. It may be a little difficult for many
> users, but I don't think it's that bad.
>
> http://meta.wikimedia.org/wiki/Semantic_MediaWiki

Yeah, I know about it. The widespread assumption is that Semantic
MediaWiki will never happen at Wikipedia. Which is a pity, and
possibly a self-fulfilling prophesy.

Is there some small part of the semantic stuff that we could adopt,
without taking the whole thing?

Steve


references:
<cb6d7dc50612130850s74267de2s2f943af0c1c75224@mail.gmail.com>
	<elpm19$qfj$1@sea.gmane.org> <elppn8$8hn$1@sea.gmane.org>

body:
On 13/12/06, Dave Grogan <dgrogan at gmail.com> wrote:
> The spellchecker needs a hook near the end of getEditToolbar that is
> passed the toolbar variable.  The extension adds a spellcheck button to
> the toolbar.

You couldn't just use the existing JavaScript-based support functions
for adding custom edit buttons?

> Track Changes needs ArticleSaveComplete to also pass $revisionId (id of
> the newly-saved revision) and a flag that determines whether the content
> of the article changed.

That sounds sane enough to me.

Rob Church


subject: [WikiEN-l] MONGO and the ArbCom

body:
George Herbert wrote:

>On 12/13/06, Ray Saintonge <saintonge at telus.net> wrote:
>
>
>>George Herbert wrote:
>>
>>
>>>On 12/12/06, Guy Chapman aka JzG <guy.chapman at spamcop.net> wrote:
>>>
>>>
>>>>On Wed, 13 Dec 2006 11:29:18 +1030, "Alphax wrote:
>>>>
>>>>
>>>>>NPOV says otherwise.
>>>>>
>>>>>
>>>>Not so.  We can document it, in terms which make it abundantly clear
>>>>that *this is simply not true* even though some people are determined
>>>>to believe it.  NPOV would not, of course, allow the mad theory to
>>>>creep into the main article.
>>>>
>>>>
>>>Guy, I hope it's obvious that I respect you quite a lot, but as much
>>>as I agree with you that the ideas the conspiracists put forth are
>>>intellectual garbage, I really very badly think that this attitude
>>>ultimately encourages them and (much worse) public perceptions of
>>>them.
>>>
>>>We can't make the lunacy go away; if we really want to minimize the
>>>encouragement we give them, let the light of neutral open review of
>>>their ideas expose them as garbage.  People are much less likely to
>>>believe conspiracy theories when the whole situation is laid
>>>dispassionately out for them to see what kooks the kooks are.
>>>Anything else ends up encouraging them.
>>>
>>>
>>When you start by calling the conspiricists kooks, and their theories
>>garbage you have indeed succeeded in encouraging them.
>>
>>
>Please note that the terms I used here on this list are NOT appropriate for
>in-wiki discussions or inclusion in pages.  I know that and differentiate
>how I approach the conversations.  Those are biased and loaded terms, and
>shut down any ability to rationally discuss the situation.
>
Acknowledged.

Ec


from_name: geni

subject: [WikiEN-l] new Google Earth tie-in (!!)

body:
On 12/13/06, Ben Yates <bluephonic at gmail.com> wrote:
> I agree.  And in practical terms, what difference does it make where
> the history is hosted?
>

technicaly creates problems since you can't rely on the history always
being there.

--
geni


from_name: Oskar Sigvardsson

body:
On 12/12/06, M Roget <mroget at gmail.com> wrote:
> Can we have a rule that states that any admin who "quits" Wikipedia to
> protest this or that is automatically desysopped? It's one thing to take a
> wikibreak or to leave because of real life time commitments but any admin
> who quits in order to make a point has abdicated their responsibilities.
> There seems to be a trend of admins announcing their departure only to come
> back in a few days after dozens of people have posted supportive statements
> on their talk page. Call me cynical but this looks like manipulative
> trolling to me and automatic desysopping would create a disincentive. If
> someone really intends to leave they won't care about being desysopped -
> they'll even request that it be done but if somone is just pretending to
> leave an automatic desysopping will make them think twice.
>
> Michel

I think your point of view is a fundamental misunderstanding about
what an admin is. Admins don't hold special standing in our community,
they are just users who have proven their ability to not go insane
with the tools. If he comes back, why not let him have the tools?
Admins keep the encyclopedia running and unless someone has proven to
be unreliable with the tools, desysopping is a bad thing.

If you wish to prevent this kind of drama in general, make a rule that
isn't admin specific, make it so for all users. What has leaving and
coming back to do with adminship?

--Oskar


subject: [WikiEN-l] new Google Earth tie-in (!!)

body:
I honestly thought the words "selling out" were invoked in a
deliberate attempt to be inflammatory, as that's the only reason I'd
use them.  I guess I misunderstood, sorry.

I don't understand how we could be commited to free content yet
opposed to certain groups from making free use of the free content or
identifying and promoting its free source. I guess I don't understand
your position at all.

It seems I often can't figure you out and I feel bad about that.
Perhaps we could meet in person sometime? Your choice of food or drink on me.

On 12/13/06, Anthony <wikilegal at inbox.org> wrote:
> On 12/13/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> > World Wind support is a worthy cause, and everyone would like to see
> > it.  Please don't mix up worthy causes with what is, frankly, trolling
> > and nonsense speculation about "selling out".
>
> I think the term "selling out" is quite appropriate when an
> organization dedicated to helping out the free content movement
> "negotiates" to put its name on software like Google Earth
> (proprietary software used to distribute proprietary content).
>
> That's probably the difference of opinion I have which you hostilly
> call "trolling", but if not feel free to point to which part it is.
>
> Anthony
>
> (*) If Gregory Maxwell is correct that the use of the logo was
> "negotiated", which hasn't yet been confirmed.
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


subject: [WikiEN-l] MONGO and the ArbCom

body:
Guy Chapman aka JzG wrote:

>Ray Saintonge wrote:
>
>
>>We can then have a section where the theorists have a
>>relatively free hand to develop their ideas without non-believers trying
>>to tell them what they believe.  A further section would give the
>>critics an equally free reign.  The article would not really reach
>>conclusions, but it would be subject to referencing.
>>
>>
>Sorry, but this is a recipe for he-said-she-said and original
>research.  Sometimes it works, more often you get articles like
>Aetherometry where we are in the vanguard of debunking something that
>nobody else takes seriously enough to give time to.
>
Being subject to referencing deals with the original research rule.
Both sides of the argument have to do it.  There is certainly a strong
element of he-said-she-said, but I wouldn't worry about that.  That can
be constrained by keeping both sides from carrying on endlessly.

It is not the function of Wikipedia to be either promoting or debunking
theories.  Doing either of these would be jumping on one side's POV
bandwagon.  I tried to look up aetherometry just to see what it is but
we currently do not have an article about it.

Ec


body:
On 12/13/06, Brion Vibber <brion at pobox.com> wrote:
<snip wise (no irony here!) explanations about the importance of final '/'>
right.  Same is also true, if you strip the month part ('2003-November')as well.
> Possible solution options:
> * tell people not to go to the wrong links ;)
Well, I don't think the page in question is anywhere linked. I myself
only discovered it because I was
1. looking at a message found by htdig
2. wanting to go to the list archive
3. thinking I could do so by just removing the month and msg-id bit,
as this works in the pipermail-environment.
Let's say, this one is the zero-budget and zero-time solution ;)

> * hack the mailman htdig interface to forward correctly
> * hack the mailman htdig interface to just send to the regular pipermail
> urls (why doesn't it by default?)
Hm, if anybody considers hacking the interface (no idea how difficult
this is), I'd prefer this option. Can't give a really good reason,
though, I just think it looks nicer if there is only one archive page
(/pipermail/...) and not a nominally separate archive (/htdig/...)
> * rip out the whole archive system with something that actually works
> the way we'd like it in the first place ;)
Okay, this is probably the opposite of the first one... Might be bit
of an utopia though.
Michael


body:
Gregory Maxwell wrote:

>On 12/13/06, MacGyverMagic/Mgm <macgyvermagic at gmail.com> wrote:
>
>
>>Surely you can have AutoWikiBrowser slug through a list of articles that
>>link to Camebridge and also have a structure-stub tag or Buildings in
>>Camebridge category to them? Then there's [[WP:RI]] too. Is there a
>>Camebridge WikiProject?
>>
>>
>Wikipedia is more of a mess than you expect.
>
That helps to insure that there is plenty of work for people to do.

>why
>the heck do we have articles on minor shopping centers when we're
>still missing important US Supreme court cases.
>
I guess there are just more people interested in shopping centers than
Supreme Court cases.  The shopping center people are looking after their
own interests, perhaps those interested in law should be as diligent.

Ec


from_name: Yann Forget

body:
Hi,

I think that there are several areas where the projects would benefit
from a more proactive help from the Foundation. I will speak about two here:

1. Legal counselling.

Some projects (mainly Commons and Wikisource) need more input about
copyright issues from knowledgeable persons. I have asked twice to
juriwiki-l specific issues for Wikisource without receiving an answer,
even an acknowledgement that my request was received. Another concrete
example: Commons and Wikisource would benefit most from a cross table
about copyright rules, which countries use "most favourable rule apply",
etc.

2. Helping small projects. It seems that some projects have a difficult
start. Indian languages projects are my first examples. I will go to
India in January, and I would like to use this opportunity to recruit
new contributors. The Foundation could help coordinate this kind of
recruitement.

Best regards,

Yann
--
http://www.non-violence.org/ | Site collaboratif sur la non-violence
http://www.forget-me.net/ | Alternatives sur le Net
http://fr.wikipedia.org/ | Encyclop?die libre
http://fr.wikisource.org/ | Biblioth?que libre
http://wikilivres.info | Documents libres


subject:
[Wikitech-l] can I add parameters to hooks used by
	twoextensions(spellchecker and svn blame-like view)

body:
"Rob Church" <robchur at gmail.com> wrote in
message news:e92136380612131311x24e8cf0cpe0ad70aeaf678b87 at mail.gmail.com...
> On 13/12/06, Dave Grogan <dgrogan at gmail.com>
wrote:
> > The spellchecker needs a hook near the end of getEditToolbar that is
> > passed the toolbar variable.  The extension adds a spellcheck button to
> > the toolbar.
>
> You couldn't just use the existing JavaScript-based support functions
> for adding custom edit buttons?

Or look at how http://www.mediawiki.org/wiki/Extension:Add_Button does it.

> > Track Changes needs ArticleSaveComplete to also pass $revisionId (id of
> > the newly-saved revision) and a flag that determines whether the content
> > of the article changed.
>
> That sounds sane enough to me.
>

I was under the impression that the article was never saved if the content
hasn't changed, and therefore the hook wouldn't trigger in that situation
anyway.

Also, $revisionID should be available through the article object that is
already passed to the hook.  If not, then that is where it should be added,
not as an extra hook parameter.

> > Track changes needs SkinTemplateTabs to pass in revid and oldid so that
> > it can display oldid if specified in the query string or revid if it
was:
> >
> > $oldid = $wgRequest->getVal( 'oldid' );
> > global $wgArticle;
> > $revid = $wgArticle ? $wgArticle->getLatest() : 0;

Not very clear about this point.  Can you elaborate?

- Mark Clements (HappyDog)


body:
On 12/13/06, Yann Forget <yann at forget-me.net> wrote:

> 1. Legal counselling.
>
> Some projects (mainly Commons and Wikisource) need more input about
> copyright issues from knowledgeable persons. I have asked twice to
> juriwiki-l specific issues for Wikisource without receiving an answer,
> even an acknowledgement that my request was received. Another concrete
> example: Commons and Wikisource would benefit most from a cross table
> about copyright rules, which countries use "most favourable rule apply",
> etc.
>
I really wonder about the status of the following bodies or positions:

http://meta.wikimedia.org/wiki/Legal_department Is / was this ever
official? If yes, is it the appropriate point of contact?

http://meta.wikimedia.org/wiki/Lead_Legal_Coordinator (Soufron) Is
this still an active position? If yes, how is it related to the
General Counsel? Who is the appropriate contact for project legal
issues? Jean-Baptiste Soufron or Brad?

http://meta.wikimedia.org/wiki/Juriwiki_mailing_list Is this
mailinglist active (i.e. are there discussions going on at the
moment)? Should it still be contacted?

> 2. Helping small projects. It seems that some projects have a difficult
> start. Indian languages projects are my first examples. I will go to
> India in January, and I would like to use this opportunity to recruit
> new contributors. The Foundation could help coordinate this kind of
> recruitement.
>
Isn't this in the domain of Special Projects Committee resp. its
'language' subcommitee?
>From http://meta.wikimedia.org/wiki/Special_projects_subcommittees/New_languages

The Wikipedia Foundation Special projects language subcommittee is in
charge of (...) supporting and coordinating new projects to optimize
their success.

Michael
> Best regards,
>
> Yann
> --
> http://www.non-violence.org/ | Site collaboratif sur la non-violence
> http://www.forget-me.net/ | Alternatives sur le Net
> http://fr.wikipedia.org/ | Encyclop?die libre
> http://fr.wikisource.org/ | Biblioth?que libre
> http://wikilivres.info | Documents libres
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>


subject: [WikiEN-l] Westboro_Baptist_Church

body:
Hi,

Tragic Romance wrote:
> Hi,
>
> I don't know who to write to about this, but user "Wahkeenah" makes a death threat against the members of "Westboro Baptist Church" at the bottom of this page:
>
> http://en.wikipedia.org/w/index.php?title=Talk:Westboro_Baptist_Church&oldid=94081545
>
> I'm just an editor; I have no association with that user or that church.

Thanks for removing this. I am forwarding to the appropriate list.

> Thanks,
> Tim

Best Regards,

Yann
--
http://www.non-violence.org/ | Site collaboratif sur la non-violence
http://www.forget-me.net/ | Alternatives sur le Net
http://fr.wikipedia.org/ | Encyclop?die libre
http://fr.wikisource.org/ | Biblioth?que libre
http://wikilivres.info | Documents libres


subject: [Commons-l] Wikimedia Foundation's help to the projects