subject: [WikiEN-l] The vexed issue of sources

body:
> I think that this takes the original research ban a little too far.  We
> are talking here about a place and a directly observable fact about the
> place.  The original research here was done by the people who put the
> information own the wall.  Any Wikipedian who cares to (I'm sure we have
> plenty of Wikipedians in or near Philadelphia.) can go there and take a
> photo of the wall for verification.  It fits in fine with a policy of
> having people go out and take their own photos of whatever to replace
> fair use photos.  IOW when should original research be used as grounds
> for rejecting a photo?

I think it's best to stop talking in terms of original research and
talk about reliability of sources (which is the main reason the OR
rule exists, it's a special case of WP:RS).

The source being used in the article is not the writing on the wall.
The source is the few Wikipedians that have seen the writing. While
the writing is probably reliable, the few Wikipedians are not. If
someone took a picture, then we could use that picture as the source,
and that picture *is* reliable, so everything is ok.

I think a lot of the disagreements in this thread boil down to people
not understanding what the source in a particular situation is. If we
only know something because a Wikipedian found it out from somewhere,
then the source is the Wikipedian, not the somewhere they found it out
from. A piece a information is only as reliable as the least reliable
connection from the primary source to the article. If a source is
published in such a way that anyone can verify it then the last
connection (the author of the article) becomes reliable, as we can
repeat their work (as it's a completely reliably connection, we
usually ignore it and just reference the source directly).


list: wikien-l

source: pipermail-mbox

from_name: Luna

subject: [WikiEN-l] <Ref> tags s__k

body:
Yep! As I recall, the first use of a particular <ref> need not be the "real"
one, anymore. It may be beneficial to start just using <ref name="foo"/> in
the article text, and then shove the main refs to the bottom of the article,
above or around the <refereces/> tag. For the time being, I suppose that
would cause a few extra footnote links, but surely the problem is
surmountable.

Thoughts?

On 12/9/06, stvrtg <stvrtg at gmail.com> wrote:
>
> The apple
> <ref name=foo>
> {{cite web
> |url=http://www.timesonline.co.uk/article/389438794343.html
> |title=Foo panel disagress with bar
> |first=Foo
> |last=Bar
> |date=2006-10-17
> |publisher=The Sunday Times
> |accessdate=October 17
> |accessyear=2006}}
> </ref>
> is red.
>
> Anyone else bothered by how much these clutter up and interefere with
> editing text?
>
> -sv
> _______________________________________________
> 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: charles.r.matthews at ntlworld.com

subject: [WikiEN-l] The vexed issue of sources

body:
"Thomas Dalton" wrote
> I think it's best to stop talking in terms of original research and
> talk about reliability of sources (which is the main reason the OR
> rule exists, it's a special case of WP:RS).

Historically that's quite wrong. 'Original research' came into policyland as a Jimbo intervention against cranks on the science pages. 'Citing sources' was one of things that floats up from the frontline areas of highly contentious pages. 'Verifiability' was an attempt to amalgamate NOR and 'cite sources'; and RS is a needed guideline to support our notion of verifiability.

It is not exactly satisfactory that our policies have this kind of path-dependence (in some sense one has to understand why they got there). But the history does have a role to play in explaining things. Especially because consensus on policies is hardly perfect.

Charles

-----------------------------------------
Email sent from www.ntlworld.com
Virus-checked using McAfee(R) Software
Visit www.ntlworld.com/security for more information


subject: [WikiEN-l] <Ref> tags s__k

body:
Messedrocker has a pretty good suggestion, there, I think. Difficult to say,
but I *think* that setup might make more sense for newcomers? In addition to
fixing the problems originally brought up in this thread.

Given the number of lines of text these things might entail, it might be
easier for parsing and human readability if there's something just a little
more elaborate to delineate the start of each ref. I'm not sure what that
would be, though.

On 12/9/06, James Hare <messedrocker at gmail.com> wrote:
>
> I think it should be reformed -- that is, it should be done the other way
> around.
>
> <ref name="foobar"/>
>
> then, at the bottom,
>
> <references>
> foobar=When "Thingamajig" Isn't Enough: A History of Foo Bar. Jim Cadigan.
> 1997
> </references>
>
> or something like that
>
> On 12/9/06, Alphax (Wikipedia email) <alphasigmax at gmail.com> wrote:
> >
> > Thomas Dalton wrote:
> > >> Yep! As I recall, the first use of a particular <ref> need not be the
>
> > "real"
> > >> one, anymore. It may be beneficial to start just using <ref
> > name="foo"/> in
> > >> the article text, and then shove the main refs to the bottom of the
> > article,
> > >> above or around the <refereces/> tag. For the time being, I suppose
> > that
> > >> would cause a few extra footnote links, but surely the problem is
> > >> surmountable.
> > >
> > > If they can go at the bottom, then it should be ok. I was under the
> > > impression the first use had to be the full one, if that's not so,
> > > then great! A numberline at the bottom isn't too bad, although the
> > > extra letter on each reference linking to the bottom of the page would
> > > still be annoying... we need some kind of noinclude option for refs...
> > >
> >
> > See Bug 5997.
> >
> > --
> > 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
> >
> >
> >
> > _______________________________________________
> > 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: Thomas Dalton

subject: [WikiEN-l] The vexed issue of sources

body:
> Let's not be simplistic here.  I completely agree that information is
> only as reliable as the weakest link in the information chain, but that
> does not imply that the weakest link is necessarily the most recent
> one.  The fact that I read what I claim in the "Da Vinci Code" is
> immediately verifiable.

Of course, but the most recent is the only one we have any control
over. When determining the reliability of a source, we should
certainly consider the reliability of the sources that source used,
but we can't control what those sources were.


from_name: stvrtg

subject: [WikiEN-l] <Ref> tags s__k

body:
The apple
<ref name=foo>
{{cite web
|url=http://www.timesonline.co.uk/article/389438794343.html
|title=Foo panel disagress with bar
|first=Foo
|last=Bar
|date=2006-10-17
|publisher=The Sunday Times
|accessdate=October 17
|accessyear=2006}}
</ref>
is red.

Anyone else bothered by how much these clutter up and interefere with
editing text?

-sv


from_name: James Hare

subject: [WikiEN-l] <Ref> tags s__k

body:
I think it should be reformed -- that is, it should be done the other way
around.

<ref name="foobar"/>

then, at the bottom,

<references>
foobar=When "Thingamajig" Isn't Enough: A History of Foo Bar. Jim Cadigan.
1997
</references>

or something like that

On 12/9/06, Alphax (Wikipedia email) <alphasigmax at gmail.com> wrote:
>
> Thomas Dalton wrote:
> >> Yep! As I recall, the first use of a particular <ref> need not be the
> "real"
> >> one, anymore. It may be beneficial to start just using <ref
> name="foo"/> in
> >> the article text, and then shove the main refs to the bottom of the
> article,
> >> above or around the <refereces/> tag. For the time being, I suppose
> that
> >> would cause a few extra footnote links, but surely the problem is
> >> surmountable.
> >
> > If they can go at the bottom, then it should be ok. I was under the
> > impression the first use had to be the full one, if that's not so,
> > then great! A numberline at the bottom isn't too bad, although the
> > extra letter on each reference linking to the bottom of the page would
> > still be annoying... we need some kind of noinclude option for refs...
> >
>
> See Bug 5997.
>
> --
> 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
>
>
>
> _______________________________________________
> 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: MacGyverMagic/Mgm

subject: [WikiEN-l] The WikiChix debate gets noticed...

body:
I think I'll start filtering emails about Wikipedia Review.
Those loonies don't deserve the attention.

Mgm

On 12/9/06, Daniel R. Tobias <dan at tobias.name> wrote:
>
> The inhabitants of the looney bin called Wikipedia Review seem to
> have taken notice of the recent discussion in this list regarding a
> women-only mailing list, and that provoked some of them into wild
> theorizing regarding how such a list is bound to be dominated by
> transsexuals and "shemales"...
>
> http://wikipediareview.com/index.php?showtopic=5302
>
>
> --
> == 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/
>
>
> _______________________________________________
> 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: Matthew Brown

subject: [WikiEN-l] <Ref> tags s__k

body:
On 12/9/06, stvrtg <stvrtg at gmail.com> wrote:
> Anyone else bothered by how much these clutter up and interefere with
> editing text?

Me. The idea that one puts a reference near the referred-to text is
good in principle - in that it makes it harder to lose the reference -
but the interaction of that with the 'cite blah' templates is poor.
They're bulky, and that causes a problem.  The flow of the text is
lost, making editing less natural.

The problem with putting the actual reference text in the references
section and referring to it by name in the text is that the two are
then separated and easier to break.  However, I'd prefer that to the
ugly mess the current <ref> tags make of the running text.

-Matt


list: wikitech-l

from_name: Alex Powell

subject: [Wikitech-l] Multiple image namespaces in the same wiki

body:
Hi,

I was wondering if it were possible to create two image namespaces in a
single mediawiki install. I would like to have some files stored in one
location and others in another.

Docs:Worddoc.doc would put Worddoc.doc into a folder named Docs/<hashed
folder>/Worddoc.doc

Image:Picture.gif would put Picture.gif into a folder named images/<hashed
folder>/Picture.gif

I can create custom namespaces, but it appears that only the Image namespace
responds with a file upload, and I cannot see how to flag a namespace for
media.

Any help would be much appreciated,

Alex


from_name: Guy Chapman aka JzG

subject:
[WikiEN-l] Anne Milton (was Re: Attack blogs in WP:LIVING
	articles)

body:
On Fri, 8 Dec 2006 23:30:24 +0000, David Boothroyd
<david at election.demon.co.uk> wrote:

>>Indeed it does.  And yet you steadfastly refuse to believe those who
>>tell you that your *contributions* (including on Talk) are the
>>problem, choosing instead to blame some notional external factors.
>>Funny, that.

>When you brought this issue to the mailing list your very second
>sentence was "We know from other evidence that Fys is an active member
>of the Labour party; this may or may not be considered relevant."
>You clearly did consider it relevant otherwise you wouldn't have
>mentioned it at all.

I do consider it significant, when considered in conjunction with your
aggressive editing style on political biographies, as noted in your
ArbCom case and block log.  Put another way *It's not just me*.

>I have asked you again and again why you continue to insinuate that
>my preference for including the disputed material in Anne Milton is
>due to political bias, and for you to substantiate your view. You
>have not. The time is past due for you to apologise for that. There
>is no finding that I am a POV editor for the very good reason that
>I am not.

So you say.  You may not be the best judge of this.  What we do know
is that you have a strong personal interest in party politics, as a
party political activist, and a history of causing problems when
editing political biographies.

Your personal version of the "bold, revert, discuss" method sees to be
"bold, revert, revert, revert, revert, argue until everyone else loses
interest and you get your way".

>I have steadfastly refused to retaliate in kind by saying that your
>known opposition to my politics has influenced your judgment. Nor
>have I told you to "fuck off" as you have told me. I think you know
>me well enough to know that I will not give up on this. I think you
>also know you owe me an apology.

Yup. You were being an arse.  You still are.  I would hardly describe
my politics as *opposed* to yours, I voted Labour in several
elections.  If you were a Tory then it would be a different matter.

You have said several times that you think I owe you an apology, but
as it happens I disagree.  If i did not, I would have done so.

Fact is, you edit warred over a biography of a living individual, a
member of an opposing party, you reverted four times in quick
succession.  You claimed it was simple vandalism, two separate admins
disagreed, yet you continued to report it as simple vandalism and you
continued to revert, and you got blocked for it.  This is not the
first time you have been blocked for edit warring.  You have been
sanctioned by ArbCom for edit warring on a political biography.

So: do you propose to learn from the experience at some point, or do
we just keep blocking you?  No, I think I know the answer to that.
Your every action since persuades me that, as with most politicians,
you are so convinced that you are right, you will continue arguing
until I either accept your assertions (which is unlikely) or lose
interest.

I just lost interest.

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


body:
On Fri, 8 Dec 2006 23:59:58 +0000, David Boothroyd
<david at election.demon.co.uk> wrote:

>Unfortunately, our Mr Chapman does.

Or you do.  Actually looking at our respective block logs and ArbCom
records, I'd say it's you.

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


from_name: brion at pobox.com

subject: [Wikitech-l] MediaWiki automated test run failure 2006-12-10

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

Reading tests from "/home/brion/src/wiki/phase3/maintenance/parserTests.txt"...
Running test TODO: Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED!
Running test TODO: Link containing double-single-quotes '' (bug 4598)... FAILED!
Running test TODO: Template with thumb image (with link in description)... FAILED!
Running test TODO: message transform: <noinclude> in transcluded template (bug 4926)... FAILED!
Running test TODO: message transform: <onlyinclude> in transcluded template (bug 4926)... FAILED!
Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED!
Running test TODO: HTML bullet list, unclosed tags (bug 5497)... FAILED!
Running test TODO: HTML ordered list, unclosed tags (bug 5497)... FAILED!
Running test TODO: HTML nested bullet list, open tags (bug 5497)... FAILED!
Running test TODO: HTML nested ordered list, open tags (bug 5497)... FAILED!
Running test TODO: Parsing optional HTML elements (Bug 6171)... FAILED!
Running test TODO: Inline HTML vs wiki block nesting... FAILED!
Running test TODO: Mixing markup for italics and bold... FAILED!
Running test TODO: 5 quotes, code coverage +1 line... FAILED!
Running test TODO: dt/dd/dl test... FAILED!
Running test TODO: Images with the "|" character in the comment... FAILED!
Running test TODO: Parents of subpages, two levels up, without trailing slash or name.... FAILED!
Running test TODO: Parents of subpages, two levels up, with lots of extra trailing slashes.... FAILED!
Running test TODO: Don't fall for the self-closing div... FAILED!
Running test TODO: Always escape literal '>' in output, not just after '<'... FAILED!

Reading tests from "/home/brion/src/wiki/phase3/extensions/Cite/citeParserTests.txt"...

  10 previously failing test(s) now PASSING! :)
      * Simple <ref>, no <references/>
      * Simple <ref>, with <references/>
      * <ref> with a simple template
      * <ref> with a <nowiki>
      * <!--comment--> in a <ref> (bug 5384)
      * <references> after <gallery> (bug 6164)
      * {{REVISIONID}} on page with <ref> (bug 6299)
      * Blank ref followed by ref with content
      * Regression: non-blank ref "0" followed by ref with content
      * Regression sanity check: non-blank ref "1" followed by ref with content
Passed 451 of 471 tests (95.75%)... FAILED!


from_name: Alphax (Wikipedia email)

subject: [WikiEN-l] The vexed issue of sources

body:
Ray Saintonge wrote:
> The Cunctator wrote:
>
>> On 12/8/06, Daniel P. B. Smith <wikipedia2006 at dpbsmith.com> wrote:
>>
>>
>>> If the episode has _not_ been published on commercial videos, then
>>> IMHO it is not verifiable. Of course, published print sources that
>>> describe the episode are fine.
>>>
>>>
>> Of course it's verifiable. Verifiable means "able to be verified", not
>> "commercially available."
>>
> Absolutely.  The person citing the episode may have taped it when it was
> broadcast.  That's certainly legal when someone is time shifting.  If
> the episode has not yet been made commercially available, I'm sure that
> the producers still have the episode in their archives somewhere.
>

You haven't read the lede of [[Doctor Who missing episodes]] then.

--
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: 569 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20061210/a8b421f7/attachment.pgp


from_name: Ray Saintonge

subject: [WikiEN-l] <Ref> tags s__k

body:
stvrtg wrote:

>The apple
><ref name=foo>
>{{cite web
>|url=http://www.timesonline.co.uk/article/389438794343.html
>|title=Foo panel disagress with bar
>|first=Foo
>|last=Bar
>|date=2006-10-17
>|publisher=The Sunday Times
>|accessdate=October 17
>|accessyear=2006}}
></ref>
>is red.
>
>Anyone else bothered by how much these clutter up and interefere with
>editing text?
>
Looks like the geeks are running amok again.  What's the matter with
normal WYSIWYG text inside simple <ref> tags?  Promoting better
sourcing, and adding all that garbage formatting are mutually exclusive.

Ec


from_name: Brion Vibber

subject: [Wikitech-l] What does the "undo" link do?

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

Steve Bennett wrote:
> On 12/8/06, Rob Church <robchur at gmail.com> wrote:
>> As I've mentioned before in this thread, that isn't the whole case;
>> rollback *will* revert more than one edit where there's a sequence of
>> edits by the same contributor.
>>
>> In that respect, it's much more powerful.
>
> Ok, given that "undo" is not "rollback", and that "undo" is more
> user-friendly than "manual revert", can "undo" be enabled for all
> users for the most recent revision? And we'll keep calling it "undo"
> and insist that it's totally different from "rollback" and everyone
> will be happy, right?

I don't see a particular reason not to show it; it would just be the
same as clicking 'edit' on the previous revision. :)

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

iD8DBQFFe8Z1wRnhpk1wk44RAvLZAJ9OEpzHzXpOUASGsTF0Om+iov6LSACg2+z1
3b71Pakc3wlgH5z32fOYcoA=
=kuXq
-----END PGP SIGNATURE-----


subject: [WikiEN-l] <Ref> tags s__k

body:
> Anyone else bothered by how much these clutter up and interefere with
> editing text?

Do you have a solution? The only thing I can think of is putting all
the references at the beginning and then just putting <ref
name="foo"/> in the main text, but that would mean a big block of code
at the top of every page (or at least every page that is properly
sourced) and I'm not sure if it's possible to stop the top of each
page looking like a numberline.


subject: [WikiEN-l] <Ref> tags s__k

body:
> Yep! As I recall, the first use of a particular <ref> need not be the "real"
> one, anymore. It may be beneficial to start just using <ref name="foo"/> in
> the article text, and then shove the main refs to the bottom of the article,
> above or around the <refereces/> tag. For the time being, I suppose that
> would cause a few extra footnote links, but surely the problem is
> surmountable.

If they can go at the bottom, then it should be ok. I was under the
impression the first use had to be the full one, if that's not so,
then great! A numberline at the bottom isn't too bad, although the
extra letter on each reference linking to the bottom of the page would
still be annoying... we need some kind of noinclude option for refs...


from_name: Simetrical

subject: [Wikitech-l] Redirect to section

body:
On 12/10/06, Steve Bennett <stevagewp at gmail.com> wrote:
> Thanks very much for implementing this, I had been wanting it too. How
> come it needed javascript?

Because this isn't an HTTP redirect, so you can't redirect to a URL
that actually has an anchor in it.  You have to have the browser jump
to the appropriate location on the page some other way, i.e.,
JavaScript.


from_name: Tim Starling

subject: [Wikitech-l] MediaWiki automated test run failure 2006-12-09

body:
brion at pobox.com wrote:
> Reading tests from "/home/brion/src/wiki/phase3/extensions/Cite/citeParserTests.txt"...
> Running test Simple <ref>, no <references/>... FAILED!
> Running test Simple <ref>, with <references/>... FAILED!
> Running test <ref> with a simple template... FAILED!
> Running test <ref> with a <nowiki>... FAILED!

<ref> regression is my fault, apologies. I did a live hack to fix it
temporarily while I pondered how to fix it properly.

The main issue is one of syntax: should [[Page # section]] work, i.e. with
whitespace? It didn't before, but I thought that it should. The poor
implementation broke Cite's [[#_note1]], but I'm still torn as to whether
I should respect a difference between underscores and spaces, ignoring the
latter, or whether I should restore the previous behaviour.

Since it's taking so long, I'll commit the live hack for it now.

-- Tim Starling


from_name: Bryan Derksen

subject: [WikiEN-l] <Ref> tags s__k

body:
Thomas Dalton wrote:
>> Anyone else bothered by how much these clutter up and interefere with
>> editing text?
>
> Do you have a solution? The only thing I can think of is putting all
> the references at the beginning and then just putting <ref
> name="foo"/> in the main text, but that would mean a big block of code
> at the top of every page (or at least every page that is properly
> sourced) and I'm not sure if it's possible to stop the top of each
> page looking like a numberline.

I had the notion once of a reference: namespace, used just like the
template: namespace but solely for references. That way instead of
having every last detail duplicated in every article that used that ref
you could have

<ref name="foo">{{reference:foo}}</ref>

or perhaps for larger references like books,

<ref name="foo">{{reference:foo}}, p. 21-22</ref>

If we wanted to be daring we could have the <ref> tags be automatically
generated for transclusions like this, perhaps using a bar to tack
additions on like a parameter. {{reference:foo|, p. 21-22}} for example.

This would have the benefit of:

*preventing duplication of effort between articles that use the same
reference
*maintaining a more uniform format for reference text
*allowing easier tracking of which articles use which references

It would have the downside of:

*making it harder to find the text of the reference if you want to edit
it, much like with regular templates
*requiring some sort of naming convention that is consistent, unique,
but not so elaborate as to make it pointless to put the reference in a
separate page
*cross-article references could be more vulnerable to subtle vandalism
or honest mistakes. If one article used a source to cite one fact and
another article used the same source to cite another fact, and then
someone who only knows about its use at the first article fiddles with
it, it might invalidate its use in the second article.

This is just an idea I kicked around once, there's probably all sorts of
other problems I haven't thought of yet.

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


subject: [WikiEN-l] <Ref> tags s__k

body:
James Hare wrote:
> I think it should be reformed -- that is, it should be done the other way
> around.
>
> <ref name="foobar"/>
>
> then, at the bottom,
>
> <references>
> foobar=When "Thingamajig" Isn't Enough: A History of Foo Bar. Jim Cadigan.
> 1997
> </references>
>
> or something like that

The old {{ref}}/{{note}} template system was like that and I've
developed a strong distaste for it. I've done a lot of cleanup since
cite.php was introduced and there were a lot of articles with dangling
{{ref}}s that pointed nowhere or orphan {{note}}s that were no longer
referenced. Cite.php isn't perfect but I like that those errors either
can't happen at all (orphan footnotes don't exist) or produce obvious
visual effects that allow them to be easily noticed and fixed (refs with
no content appear as empty footnotes).

I suppose it's possible that by having it built into the wiki code
explicitly rather than tacked on with a template hack will allow some of
these issues to be made less of a problem, but my gut reaction is still
negative at the thought of going back to a system similar to the old one.

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


from_name: The Cunctator

subject: [WikiEN-l] The vexed issue of sources

body:
On 12/9/06, Daniel P. B. Smith <wikipedia2006 at dpbsmith.com> wrote:
> > From: "The Cunctator" <cunctator at gmail.com>
> >
> > On 12/8/06, Daniel P. B. Smith <wikipedia2006 at dpbsmith.com> wrote:
> >>> From: "The Cunctator" <cunctator at gmail.com>
> >>>
> >>
> >>> If someone says that in Episode X of Show Y this happened, I can't
> >>> imagine
> >>> why I wouldn't believe it.
> >>>
> >>> And I can imagine any number of ways by which if I *had* to I could
> >>> verify
> >>> such claim, including going to the production company or the
> >>> Museum of
> >>> Television and Radio or asking on craigslist to view such episode.
> >>
> >> If someone (e.g. 68.80.254.34) says:
> >>
> >> "Third floor of College Hall at Penn has an Episcopalian Chapel. On
> >> the wall states that Penn was founded by the Anglican Church of
> >> England. Go there and read it," would you say that "I can't imagine
> >> why I wouldn't believe it?"
> >>
> >> Anyone _could_ travel to Philadelphia and visit College Hall. Does
> >> that make the fact verifiable?
> >
> > Yes.
>
> It seems to me, then, that
>
> --you have a different definition of "verifiable" than Wikipedia
> currently has;

How so?

> --you do not accept the current verifiability policy;

Probably not. But then I'm a pretty disagreeable fellow.

> --you believe that information based solely on the personal testimony
> of an individual Wikipedian is acceptable content.

Huh?


from_name: Rob Church

subject: [Wikitech-l] Redirect to section

body:
On 10/12/06, Steve Bennett <stevagewp at gmail.com> wrote:
> Thanks very much for implementing this, I had been wanting it too. How
> come it needed javascript?

Read the bug report; it explains most of the issues.

Rob Church


from_name: geni

subject: [WikiEN-l] <Ref> tags s__k

body:
On 12/10/06, Ray Saintonge <saintonge at telus.net> wrote:
> Looks like the geeks are running amok again.  What's the matter with
> normal WYSIWYG text inside simple <ref> tags?

You are free to do that. Certianly it is what I do

>  Promoting better
> sourcing, and adding all that garbage formatting are mutually exclusive.

It isn't garbage formatting. It is a template designed to make
reference more standard and less work and it manages both for those
who learn how to use it. For the rest of us there is long hand.

--
geni


from_name: Travis Derouin

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

body:
Hi,

I've added the ability to control how the credits are displayed through a
template:

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

(See $wgTemplateName). I'm not sure if this was the functionality you were
referring to but it probably makes things a little easier.

Travis

On 12/10/06, Brianna Laugher <brianna.laugher at gmail.com> wrote:
>
> On 10/12/06, Eugene Zelenko <eugene.zelenko at gmail.com> wrote:
> >
> > It's great news! Should we bug developers to install extension on
> > Commons as soon as possible?
>
> I don't see why not -- as long as we can control how the info is
> imported (eg, to use Template:Information, and I guess some
> flickrreview thing). I just tried it out and it is frankly far easier
> than searching flickr!
>
> Undoubtedly people will not realise it is installed and continue to
> manually upload Flickr images, but for people who are aware of this,
> it will be a huge boon. :)
>
> cheers,
> Brianna
> user:pfctdayelise
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


subject: [Wikitech-l] ImportFreeImages Extension

body:
Hey,

Thanks for the info. Was the the image you were trying to import?

http://www.flickr.com/photos/26155200 at N00/4787954

I've made some changes and it seems to work now:

http://wikidiy.com/mediawiki-1.8.2/index.php/Image:On_Vaci_Utca%2C_Budapest.jpg

I like the idea of importing the description as well, I'll look into that.

Travis

On 12/8/06, Bence Damokos <bdamokos at gmail.com> wrote:
>
> Hi
> Great extension.
>
> Unfortunately it has problems with improper file names (on a search for
> Budapest , I get this message:"The filename "On+Vaci+Utca%2C+Budapest.jpg"
> contains characters that are not allowed in page titles. Please rename the
> file and try uploading it again.", maybe an option to rename the file
> would
> be nice).
>
> And maybe  the link to the original image, should be changed to the
> description page of the image?
>
> And I don't know, if its possible, but maybe such a one click import would
> be useful to implement on commons, so that local wiki images can be
> imported
> in this way (maybe with an intermediate step with the option to change the
> description, possibly using suggestions from the Commonshelper).
>
> Again, I must say you have done a wonderful job, and I have to say I was
> amased by the speed of it (just one click and the image is uploaded!).
>
> Keep up the good work
>
> Regards, Bence
>
> On 12/8/06, Travis Derouin <travis at wikihow.com> wrote:
> >
> > I've converted some code we've been using into an extension for
> importing
> > properly licensed photos from flickr into a Mediawiki installation:
> >
> > http://www.mediawiki.org/wiki/Extension:ImportFreeImages
> >
> > It makes use of the phpFlickr package for the API calls.
> >
> > Feel free to play around with it here:
> >
> > http://wikidiy.com/mediawiki-1.8.2/index.php/Special:ImportFreeImages
> >
> > Travis
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l at wikimedia.org
> > http://mail.wikipedia.org/mailman/listinfo/wikitech-l
> >
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


subject: [Wikitech-l] ImportFreeImages Extension

body:
Unfortunately it looks like the API doesn't return the description of the
image:

http://www.flickr.com/services/api/flickr.photos.search.html

Travis

On 12/10/06, Travis Derouin <travis at wikihow.com> wrote:
>
> Hey,
>
> Thanks for the info. Was the the image you were trying to import?
>
> http://www.flickr.com/photos/26155200 at N00/4787954
>
> I've made some changes and it seems to work now:
>
> http://wikidiy.com/mediawiki-1.8.2/index.php/Image:On_Vaci_Utca%2C_Budapest.jpg
>
>
> I like the idea of importing the description as well, I'll look into that.
>
>
> Travis
>
> On 12/8/06, Bence Damokos < bdamokos at gmail.com> wrote:
> >
> > Hi
> > Great extension.
> >
> > Unfortunately it has problems with improper file names (on a search for
> > Budapest , I get this message:"The filename
> > "On+Vaci+Utca%2C+Budapest.jpg"
> > contains characters that are not allowed in page titles. Please rename
> > the
> > file and try uploading it again.", maybe an option to rename the file
> > would
> > be nice).
> >
> > And maybe  the link to the original image, should be changed to the
> > description page of the image?
> >
> > And I don't know, if its possible, but maybe such a one click import
> > would
> > be useful to implement on commons, so that local wiki images can be
> > imported
> > in this way (maybe with an intermediate step with the option to change
> > the
> > description, possibly using suggestions from the Commonshelper).
> >
> > Again, I must say you have done a wonderful job, and I have to say I was
> >
> > amased by the speed of it (just one click and the image is uploaded!).
> >
> > Keep up the good work
> >
> > Regards, Bence
> >
> > On 12/8/06, Travis Derouin <travis at wikihow.com > wrote:
> > >
> > > I've converted some code we've been using into an extension for
> > importing
> > > properly licensed photos from flickr into a Mediawiki installation:
> > >
> > > http://www.mediawiki.org/wiki/Extension:ImportFreeImages
> > >
> > > It makes use of the phpFlickr package for the API calls.
> > >
> > > Feel free to play around with it here:
> > >
> > > http://wikidiy.com/mediawiki-1.8.2/index.php/Special:ImportFreeImages
> > >
> > > Travis
> > > _______________________________________________
> > > Wikitech-l mailing list
> > > Wikitech-l at wikimedia.org
> > > http://mail.wikipedia.org/mailman/listinfo/wikitech-l
> > >
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l at wikimedia.org
> > http://mail.wikipedia.org/mailman/listinfo/wikitech-l
> >
>
>


from_name: SPUI

subject: [WikiEN-l] <Ref> tags s__k

body:
Thomas Dalton wrote:
>>Anyone else bothered by how much these clutter up and interefere with
>>editing text?
>
>
> Do you have a solution? The only thing I can think of is putting all
> the references at the beginning and then just putting <ref
> name="foo"/> in the main text, but that would mean a big block of code
> at the top of every page (or at least every page that is properly
> sourced) and I'm not sure if it's possible to stop the top of each
> page looking like a numberline.

Easy solution:
<ref>[http://www.timesonline.co.uk/article/389438794343.html Foo panel
disagress with bar], The Sunday Times, [[October 17]], [[2006]</ref>


body:
On 10/12/06, Andrew Garrett <andrew at epstone.net> wrote:
> Precisely why it's unnecessary.

It's not exactly unnecessary if it's something helpful we can add. Or
do you despise convenient user interfaces?

Rob Church


from_name: Bence Damokos

body:
I concur, having an undo link on the last revision would be more intuitive
then clicking on edit (at least for new users). Also if they see the undo
link at the last revision, they might learn how to use it on older revisions
as well.

On 12/10/06, Rob Church <robchur at gmail.com> wrote:
>
> On 10/12/06, Andrew Garrett <andrew at epstone.net> wrote:
> > Precisely why it's unnecessary.
>
> It's not exactly unnecessary if it's something helpful we can add. Or
> do you despise convenient user interfaces?
>
>
> Rob Church
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


from_name: Sam Korn

subject: [WikiEN-l] <Ref> tags s__k

body:
On 12/10/06, geni <geniice at gmail.com> wrote:
> On 12/10/06, Ray Saintonge <saintonge at telus.net> wrote:
> > Looks like the geeks are running amok again.  What's the matter with
> > normal WYSIWYG text inside simple <ref> tags?
>
> You are free to do that. Certianly it is what I do

Ditto.  And woe betide anyone who goes after me "clearing up"!

> >  Promoting better
> > sourcing, and adding all that garbage formatting are mutually exclusive.
>
> It isn't garbage formatting. It is a template designed to make
> reference more standard and less work and it manages both for those
> who learn how to use it.

True.  Solution: {{subst:cite web|...

--
Sam


from_name: Luiz Augusto

subject: [Wikitech-l] ImportFreeImages Extension

body:
On 12/10/06, Travis Derouin <travis at wikihow.com> wrote:
>
> Unfortunately it looks like the API doesn't return the description of the
> image:
>
> http://www.flickr.com/services/api/flickr.photos.search.html
>
> Travis

And don't get the original size of a picture :(

http://wikidiy.com/mediawiki-1.8.2/index.php/Image:The_Guggenheim_%28Subtitle-_Kissssfrazado_II%29.jpg

http://www.flickr.com/photo_zoom.gne?id=308895239&size=o

On 12/10/06, Travis Derouin <travis at wikihow.com> wrote:
> >
> > Hey,
> >
> > Thanks for the info. Was the the image you were trying to import?
> >
> > http://www.flickr.com/photos/26155200 at N00/4787954
> >
> > I've made some changes and it seems to work now:
> >
> >
> http://wikidiy.com/mediawiki-1.8.2/index.php/Image:On_Vaci_Utca%2C_Budapest.jpg
> >
> >
> > I like the idea of importing the description as well, I'll look into
> that.
> >
> >
> > Travis
> >
> > On 12/8/06, Bence Damokos < bdamokos at gmail.com> wrote:
> > >
> > > Hi
> > > Great extension.
> > >
> > > Unfortunately it has problems with improper file names (on a search
> for
> > > Budapest , I get this message:"The filename
> > > "On+Vaci+Utca%2C+Budapest.jpg"
> > > contains characters that are not allowed in page titles. Please rename
> > > the
> > > file and try uploading it again.", maybe an option to rename the file
> > > would
> > > be nice).
> > >
> > > And maybe  the link to the original image, should be changed to the
> > > description page of the image?
> > >
> > > And I don't know, if its possible, but maybe such a one click import
> > > would
> > > be useful to implement on commons, so that local wiki images can be
> > > imported
> > > in this way (maybe with an intermediate step with the option to change
> > > the
> > > description, possibly using suggestions from the Commonshelper).
> > >
> > > Again, I must say you have done a wonderful job, and I have to say I
> was
> > >
> > > amased by the speed of it (just one click and the image is uploaded!).
> > >
> > > Keep up the good work
> > >
> > > Regards, Bence
> > >
> > > On 12/8/06, Travis Derouin <travis at wikihow.com > wrote:
> > > >
> > > > I've converted some code we've been using into an extension for
> > > importing
> > > > properly licensed photos from flickr into a Mediawiki installation:
> > > >
> > > > http://www.mediawiki.org/wiki/Extension:ImportFreeImages
> > > >
> > > > It makes use of the phpFlickr package for the API calls.
> > > >
> > > > Feel free to play around with it here:
> > > >
> > > >
> http://wikidiy.com/mediawiki-1.8.2/index.php/Special:ImportFreeImages
> > > >
> > > > Travis
>


subject: [WikiEN-l] <Ref> tags s__k

body:
Thomas Dalton wrote:
>> Yep! As I recall, the first use of a particular <ref> need not be the "real"
>> one, anymore. It may be beneficial to start just using <ref name="foo"/> in
>> the article text, and then shove the main refs to the bottom of the article,
>> above or around the <refereces/> tag. For the time being, I suppose that
>> would cause a few extra footnote links, but surely the problem is
>> surmountable.
>
> If they can go at the bottom, then it should be ok. I was under the
> impression the first use had to be the full one, if that's not so,
> then great! A numberline at the bottom isn't too bad, although the
> extra letter on each reference linking to the bottom of the page would
> still be annoying... we need some kind of noinclude option for refs...
>

See Bug 5997.

--
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: 569 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20061210/e949cf24/attachment.pgp


subject: [WikiEN-l] <Ref> tags s__k

body:
On 12/10/06, Ligulem <ligulem at pobox.com> wrote:
> Sam Korn wrote:
> >
> > True.  Solution: {{subst:cite web|...
> >
>
> Oh really? :-)
>
> {{subst:cite web
> |url=http://www.timesonline.co.uk/article/389438794343.html
> |title=Foo panel disagress with bar
> |first=Foo
> |last=Bar
> |date=2006-10-17
> |publisher=The Sunday Times
> |accessdate=October 17
> |accessyear=2006}}
>
> inserts the following verbatim into the wiki source of the article:
>
> {
> #if: {{#if: http://www.timesonline.co.uk/article/389438794343.html |
> {{#if: Foo panel disagress with bar |1}}}}
[snip]

Yuck yuck yuck.

I retract my previous comment.  This is what comes of absurdly
complicated template syntax.

--
Sam


from_name: Thomas Dalton

subject: [WikiEN-l] <Ref> tags s__k

body:
> I retract my previous comment.  This is what comes of absurdly
> complicated template syntax.

Or the lack of a recursive subst option. There should be a way to get
MediaWiki to include just the code that is actually displayed, so
automatically substing any subtemplates, resolving any if statements
when you make the edit, rather than each time it's displayed, etc.
something like {{totalsubst:template}}.


subject: [WikiEN-l] <Ref> tags s__k

body:
> In the mean time, you can copy/paste the call into
> http://en.wikipedia.org/wiki/Special:ExpandTemplates and paste the
> result into the article.

How did I not know that page existed? Is it not linked to from anywhere?


subject: [WikiEN-l] <Ref> tags s__k

body:
On 12/10/06, Ligulem <ligulem at pobox.com> wrote:
> Sam Korn wrote:
> > Yuck yuck yuck.
> >
> > I retract my previous comment.  This is what comes of absurdly
> > complicated template syntax.
> >
>
> No. Just non-intuitive behaviour of subst. :-)

... allied with an absurdly complicated template syntax. :-)

> You might want to "vote" for
> http://bugzilla.wikimedia.org/show_bug.cgi?id=2777

Have done so. Thanks.

--
Sam


from_name: Ligulem

subject: [WikiEN-l] <Ref> tags s__k

body:
Sam Korn wrote:
>
> True.  Solution: {{subst:cite web|...
>

Oh really? :-)

{{subst:cite web
|url=http://www.timesonline.co.uk/article/389438794343.html
|title=Foo panel disagress with bar
|first=Foo
|last=Bar
|date=2006-10-17
|publisher=The Sunday Times
|accessdate=October 17
|accessyear=2006}}

inserts the following verbatim into the wiki source of the article:

{
#if: {{#if: http://www.timesonline.co.uk/article/389438794343.html |
{{#if: Foo panel disagress with bar |1}}}}
   ||Error on call to [[Template:cite web]]: Parameters '''url''' and
'''title''' must be specified
}}{{
#if: {{{archiveurl|}}}{{{archivedate|}}}
   | {{#if: {{#if: {{{archiveurl|}}}| {{#if: {{{archivedate|}}} |1}}}}
     ||Error on call to [[template:cite web]]: Parameters
'''archiveurl''' and '''archivedate''' must be both specified or both
omitted
}}
}}{{#if: {{{author|}}}Bar
   | {{#if: {{{authorlink|}}}
     | [[{{{authorlink}}}|{{#if: Bar
       | Bar{{#if: Foo | , Foo }}
       | {{{author}}}
     }}]]
     | {{#if: Bar
       | Bar{{#if: Foo | , Foo }}
       | {{{author}}}
     }}
   }}
}}{{#if: {{{author|}}}Bar
   | {{#if: {{{coauthors|}}}| <nowiki>;</nowiki> {{{coauthors}}} }}
}}{{#if: {{{author|}}}Bar|
     {{#if: 2006-10-17
     |  (2006-10-17)
     | {{#if: {{{year|}}}
       | {{#if: {{{month|}}}
         |  ({{{month}}} {{{year}}})
         |  ({{{year}}})
       }}
     }}
   |}}
}}{{#if: Bar{{{author|}}}
   | . }}{{#if: {{{archiveurl|}}}
     | {{#if: {{{archiveurl|}}} | {{#if: Foo panel disagress with bar |
[{{{archiveurl}}} Foo panel disagress with bar] }}}}
     | {{#if: http://www.timesonline.co.uk/article/389438794343.html |
{{#if: Foo panel disagress with bar |
[http://www.timesonline.co.uk/article/389438794343.html Foo panel
disagress with bar] }}}}
}}{{#if: {{{language|}}} |  ({{{language}}})
}}{{#if: {{{format|}}}
   |  ({{{format|}}})
}}{{#if: {{{work|}}}
   | . ''{{{work}}}''
}}{{#if: {{{pages|}}}
   |  {{{pages}}}
}}{{#if: The Sunday Times
   | . The Sunday Times{{#if: {{{author|}}}Bar
     |
     | {{#if: 2006-10-17{{{year|}}}{{{month|}}} || }}
   }}
}}{{#if: {{{author|}}}Bar
   ||{{#if: 2006-10-17
     |  (2006-10-17)
     | {{#if: {{{year|}}}
       | {{#if: {{{month|}}}
         |  ({{{month}}} {{{year}}})
         |  ({{{year}}})
       }}
     }}
   }}
}}.{{#if: {{{archivedate|}}}
   |  Archived from
[http://www.timesonline.co.uk/article/389438794343.html the original] on
[[{{{archivedate}}}]].
}}{{#if: October 17
   |  Retrieved on [[October 17]]{{#if: 2006 | , [[2006]] }}.
}}{{#if: {{{accessmonthday|}}}
   |  Retrieved on {{{accessmonthday}}}, 2006.
}}{{#if: {{{quote|}}}
   |  ?{{{quote}}}?
}}


from_name: Mak

subject: [WikiEN-l] <Ref> tags s__k

body:
Perhaps this is cheating, and it seems to upset some people, but I basically
use Harvard Referencing within the <ref> templates, and give the full
citation in the ==References== section. So, within the wikitext, you have:
"Blah blah blah.<ref>Kilmer, pg. 7</ref> Blah blah." and at the bottom of
the page you have the full information for Kilmer. This also makes it easier
to put in page numbers for books sources. The downside is that you can
sometimes get long lists of different page numbers for the same book, which
takes up space and looks somewhat messy, but I figure it's at the bottom of
the article anyway.
Makemi

On 12/10/06, SPUI <drspui at gmail.com> wrote:
>
> Thomas Dalton wrote:
> >>Anyone else bothered by how much these clutter up and interefere with
> >>editing text?
> >
> >
> > Do you have a solution? The only thing I can think of is putting all
> > the references at the beginning and then just putting <ref
> > name="foo"/> in the main text, but that would mean a big block of code
> > at the top of every page (or at least every page that is properly
> > sourced) and I'm not sure if it's possible to stop the top of each
> > page looking like a numberline.
>
> Easy solution:
> <ref>[http://www.timesonline.co.uk/article/389438794343.html Foo panel
> disagress with bar], The Sunday Times, [[October 17]], [[2006]</ref>
> _______________________________________________
> 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: James Hare

subject: [WikiEN-l] <Ref> tags s__k

body:
Yeah, I do that too. I know it's standard for citing things like books, but
can it be applied to things like websites?

On 12/10/06, Mak <makwik at gmail.com> wrote:
>
> Perhaps this is cheating, and it seems to upset some people, but I
> basically
> use Harvard Referencing within the <ref> templates, and give the full
> citation in the ==References== section. So, within the wikitext, you have:
> "Blah blah blah.<ref>Kilmer, pg. 7</ref> Blah blah." and at the bottom of
> the page you have the full information for Kilmer. This also makes it
> easier
> to put in page numbers for books sources. The downside is that you can
> sometimes get long lists of different page numbers for the same book,
> which
> takes up space and looks somewhat messy, but I figure it's at the bottom
> of
> the article anyway.
> Makemi
>
> On 12/10/06, SPUI <drspui at gmail.com> wrote:
> >
> > Thomas Dalton wrote:
> > >>Anyone else bothered by how much these clutter up and interefere with
> > >>editing text?
> > >
> > >
> > > Do you have a solution? The only thing I can think of is putting all
> > > the references at the beginning and then just putting <ref
> > > name="foo"/> in the main text, but that would mean a big block of code
> > > at the top of every page (or at least every page that is properly
> > > sourced) and I'm not sure if it's possible to stop the top of each
> > > page looking like a numberline.
> >
> > Easy solution:
> > <ref>[http://www.timesonline.co.uk/article/389438794343.html Foo panel
> > disagress with bar], The Sunday Times, [[October 17]], [[2006]</ref>
> > _______________________________________________
> > 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
>


subject: [WikiEN-l] <Ref> tags s__k

body:
Sam Korn wrote:
> Yuck yuck yuck.
>
> I retract my previous comment.  This is what comes of absurdly
> complicated template syntax.
>

No. Just non-intuitive behaviour of subst. :-)

You might want to "vote" for
http://bugzilla.wikimedia.org/show_bug.cgi?id=2777

In the mean time, you can copy/paste the call into
http://en.wikipedia.org/wiki/Special:ExpandTemplates and paste the
result into the article.

If that's what you prefer (or the consensus may be)...

The Germans use a list of red tape for the formatting at
http://de.wikipedia.org/wiki/Wikipedia:Literatur#Format.

And they never change that. For obvious reasons :-)


from_name: Manuel Schneider

subject:
[Wikitech-l] [Bug 8148] Apache randomly dies using up all CPU
	cycles after upgrade from 1.8.2 to trunk

body:
Hi,

> http://bugzilla.wikimedia.org/show_bug.cgi?id=8148
I finally found the reason for this problem, but unfortunately no solution.

The problem was introduced by this commit of Brion:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/OutputPage.php?r1=17300&r2=17452

Maybe someone of you has a solution. The problem is really bugging me as I
have it on serveral servers and I can no longer use the wikis I have once
upgraded to trunk (unless I use my dirty hack).

--
Regards
Manuel Schneider

Wikimedia CH - Verein zur F?rderung Freien Wissens
Wikimedia CH - Association for the advancement of free knowledge
www.wikimedia.ch


subject: [WikiEN-l] <Ref> tags s__k

body:
Ligulem wrote:
> The Germans use a list of red tape for the formatting at
> http://de.wikipedia.org/wiki/Wikipedia:Literatur#Format.
>
> And they never change that. For obvious reasons :-)

Addendum: just found out that the "full" German red tape is even longer:
http://de.wikipedia.org/wiki/Wikipedia:Literatur/Formatierungsregeln

Quote from that page:

"Die bisher verwandten Regeln unter Literatur sind unvollst?ndig und
werden uneinheitlich angewandt, weshalb detailliertere Regeln notwendig
sind."

("The current rules are incomplete and not applied uniformly. Rules
which go into more detail are needed")


subject: [WikiEN-l] <Ref> tags s__k

body:
Thomas Dalton wrote:
>> In the mean time, you can copy/paste the call into
>> http://en.wikipedia.org/wiki/Special:ExpandTemplates and paste the
>> result into the article.
>
> How did I not know that page existed? Is it not linked to from anywhere?

It's a "special page".

These are all listed at http://en.wikipedia.org/wiki/Special:Specialpages.

Click on "Special pages" in the toolbox on the left (assuming you use
the default Monobook skin).


subject: [Wikitech-l] ImportFreeImages Extension

body:
On 12/8/06, Travis Derouin <travis at wikihow.com> wrote:
> I've converted some code we've been using into an extension for importing
> properly licensed photos from flickr into a Mediawiki installation:
>
> http://www.mediawiki.org/wiki/Extension:ImportFreeImages
>
> It makes use of the phpFlickr package for the API calls.
>
> Feel free to play around with it here:
>
> http://wikidiy.com/mediawiki-1.8.2/index.php/Special:ImportFreeImages

Glancing over the code, I didn't notice any permission controls.
Maybe it would be best to set up a user permission.  It could default
to everybody but be configurable, so that only
sysops/autoconfirmed/etc. could upload them.  IIRC, on Commons there's
a huge queue of images from Flickr that need to be reviewed by sysops
to ensure that their license as labeled is actually correct, so they
might want to restrict this easy-upload to sysops only.


list: foundation-l

from_name: Dedalus

subject: [Foundation-l] Audited financial statements released!

body:
Brad:

You wrote:

I want to specially thank the members of the audit team, Michael Davis
and Danny Wool,

Congrats first for having audited financial statements. That is great.
Another great thing is that you published the Management Letter - which is
rather uncommon to do.
The auditors recommend the creation of an audit committee, on page 11. The
audit team Michael Davis and Danny Wool what was their role and capacity?
Did they serve as a de facto audit committee? If looking for new members,
I've a degree in economics/business administration and am a Certified
Internal Auditor and member of the Institute of Internal Auditors (IIA,
Inc.).

Having published the Management Letter, I would like to call attention of
members of the community, espescially staff and committee members to another
recommendations on page 11 of the Management Letter "Like many small
non-profit organizations, Wikimedia Foundation, Inc., functions with a small
staff and requires the board involvement in various management functions to
provide needed oversight and independent review. As the organization grows
and resources become available, we recommend systems be developed to reduce
the need for board involvement in certain of these duties and allow the
board to focus on overall governing, setting strategy and policy objectives,
approving staff and committees, plans to achieve objectives and monitoring
progress toward meeting the objectives. Also, we recommend actively seeking
additional independent board membership."

The first might involve assigning real responsibilities and authority to
some committee - committees that already have been esthablished.
The second point about "independent board membership" might need some
clarification. In auditor-speak independent is someone without an executive
positive, or a non-executive. Indepedent board members only "provide needed
oversight and independent review", they are not directly involved in day to
day operations or executive decision making.

Lastly I wish Brad a lot of succes in establishing a manual of policies and
procedures, as required by the external auditors including all the specific
policies and procedures as mentioned by the auditors.

Good luck for all,

Dedalus


list: wikimedia-l


from_name: Ray Saintonge

subject: [WikiEN-l] <Ref> tags s__k

body:
Sam Korn wrote:

>On 12/10/06, geni <geniice at gmail.com> wrote:
>
>
>>On 12/10/06, Ray Saintonge <saintonge at telus.net> wrote:
>>
>>
>>>Looks like the geeks are running amok again.  What's the matter with
>>>normal WYSIWYG text inside simple <ref> tags?
>>>
>>>
>>You are free to do that. Certianly it is what I do
>>
>>
>Ditto.  And woe betide anyone who goes after me "clearing up"!
>
Escellent!  I'm glad to see that some forces of sanity are still alive.

Ec


from_name: Aerik Sylvan

subject: [Wikitech-l] Category Intersections again

body:
Here's something that looks promising:  Using MySQL's fulltext search
against categories only.  What I did was create a table having pagenumbers
and category text that looks like this:

<http://athlonx2/phpmyadmin/sql.php?db=categorylinks&table=pages&token=71a69e555a82e3d94a8450b4ace4496a&sql_query=SELECT+%2A+FROM+%60pages%60&session_max_rows=30&pos=0&disp_direction=horizontal&repeat_cells=100&goto=tbl_properties_structure.php&dontlimitchars=1>
ID<http://athlonx2/phpmyadmin/sql.php?db=categorylinks&table=pages&token=71a69e555a82e3d94a8450b4ace4496a&pos=0&session_max_rows=30&disp_direction=horizontal&repeat_cells=100&dontlimitchars=0&sql_query=SELECT+%2AFROM+%60pages%60++ORDER+BY+%60ID%60+ASC>
pagenum<http://athlonx2/phpmyadmin/sql.php?db=categorylinks&table=pages&token=71a69e555a82e3d94a8450b4ace4496a&pos=0&session_max_rows=30&disp_direction=horizontal&repeat_cells=100&dontlimitchars=0&sql_query=SELECT+%2AFROM+%60pages%60++ORDER+BY+%60pagenum%60+ASC>
pagename<http://athlonx2/phpmyadmin/sql.php?db=categorylinks&table=pages&token=71a69e555a82e3d94a8450b4ace4496a&pos=0&session_max_rows=30&disp_direction=horizontal&repeat_cells=100&dontlimitchars=0&sql_query=SELECT+%2AFROM+%60pages%60++ORDER+BY+%60pagename%60+ASC>
catcount<http://athlonx2/phpmyadmin/sql.php?db=categorylinks&table=pages&token=71a69e555a82e3d94a8450b4ace4496a&pos=0&session_max_rows=30&disp_direction=horizontal&repeat_cells=100&dontlimitchars=0&sql_query=SELECT+%2AFROM+%60pages%60++ORDER+BY+%60catcount%60+ASC>
catlist<http://athlonx2/phpmyadmin/sql.php?db=categorylinks&table=pages&token=71a69e555a82e3d94a8450b4ace4496a&pos=0&session_max_rows=30&disp_direction=horizontal&repeat_cells=100&dontlimitchars=0&sql_query=SELECT+%2AFROM+%60pages%60++ORDER+BY+%60catlist%60+ASC>

7343 0 Kurt000 14 Chinese_Wikipedians Leo_Wikipedians User_cello Us...

7344 1 AaA 3 Redirects_from_CamelCase Redirects_from_other_cap...

7345 5 AlgeriA 2 Redirects_from_CamelCase Unprintworthy_redirects

7346 6 AmericanSamoa 2 Redirects_from_CamelCase Unprintworthy_redirects
So the categories have underscores instead of spaces, thus forcing mysql to
index the whole category phrase as one word.  In a table with about 114,000
rows with categories (it takes a long time to recombine the categories into
one row - I'm sure the way I'm doing it is clunky), I get very reasonable
query result times.  Take our worst case "Living_People" category for
example:

Showing rows 0 - 29 (4,105 total, Query took 0.0042 sec)
SQL query: SELECT *
FROM `pages`
WHERE MATCH (
catlist
)
AGAINST (
'Living_People'
)
LIMIT 0 , 30

This also give us an immediate solution to category math (Boolean searches):

Showing rows 0 - 29 (61 total, Query took 0.0058 sec)
SQL query: SELECT *
FROM `pages`
WHERE MATCH (
catlist
)
AGAINST (
'+Living_People +1969_births'
IN BOOLEAN
MODE
)
LIMIT 0 , 30

So, I know 114,000 records is much smaller than one million +, but this
looks quite promising.

I'm using PHP to cycle through records in the categorylinks table to
recreate this index.  If one of you smart guys will tell me a better way,
I'll try this on a larger data set.

Best Regards,
Aerik


body:
Whoops - sorry about the mangled formatting in my previous post, guess I
shoulda been more careful pasting tables into my email.

Aerik


subject: [Wikitech-l] ImportFreeImages Extension

body:
Hi!

Thanks for the info. Was the the image you were trying to import?
>
> http://www.flickr.com/photos/26155200 at N00/4787954
>
> I've made some changes and it seems to work now:
>
>
> http://wikidiy.com/mediawiki-1.8.2/index.php/Image:On_Vaci_Utca%2C_Budapest.jpg
>
> I like the idea of importing the description as well, I'll look into that.
>

It was what I wanted: change the +es in teh filename to spaces, and include
a link to the original description page. And you did just that!
Good work,
Bence

On 12/10/06, Luiz Augusto <lugusto at gmail.com> wrote:
>
> On 12/10/06, Travis Derouin <travis at wikihow.com> wrote:
> >
> > Unfortunately it looks like the API doesn't return the description of
> the
> > image:
> >
> > http://www.flickr.com/services/api/flickr.photos.search.html
> >
> > Travis
>
>
> And don't get the original size of a picture :(
>
>
> http://wikidiy.com/mediawiki-1.8.2/index.php/Image:The_Guggenheim_%28Subtitle-_Kissssfrazado_II%29.jpg
>
> http://www.flickr.com/photo_zoom.gne?id=308895239&size=o
>
>
> On 12/10/06, Travis Derouin <travis at wikihow.com> wrote:
> > >
> > > Hey,
> > >
> > > Thanks for the info. Was the the image you were trying to import?
> > >
> > > http://www.flickr.com/photos/26155200 at N00/4787954
> > >
> > > I've made some changes and it seems to work now:
> > >
> > >
> >
> http://wikidiy.com/mediawiki-1.8.2/index.php/Image:On_Vaci_Utca%2C_Budapest.jpg
> > >
> > >
> > > I like the idea of importing the description as well, I'll look into
> > that.
> > >
> > >
> > > Travis
> > >
> > > On 12/8/06, Bence Damokos < bdamokos at gmail.com> wrote:
> > > >
> > > > Hi
> > > > Great extension.
> > > >
> > > > Unfortunately it has problems with improper file names (on a search
> > for
> > > > Budapest , I get this message:"The filename
> > > > "On+Vaci+Utca%2C+Budapest.jpg"
> > > > contains characters that are not allowed in page titles. Please
> rename
> > > > the
> > > > file and try uploading it again.", maybe an option to rename the
> file
> > > > would
> > > > be nice).
> > > >
> > > > And maybe  the link to the original image, should be changed to the
> > > > description page of the image?
> > > >
> > > > And I don't know, if its possible, but maybe such a one click import
> > > > would
> > > > be useful to implement on commons, so that local wiki images can be
> > > > imported
> > > > in this way (maybe with an intermediate step with the option to
> change
> > > > the
> > > > description, possibly using suggestions from the Commonshelper).
> > > >
> > > > Again, I must say you have done a wonderful job, and I have to say I
> > was
> > > >
> > > > amased by the speed of it (just one click and the image is
> uploaded!).
> > > >
> > > > Keep up the good work
> > > >
> > > > Regards, Bence
> > > >
> > > > On 12/8/06, Travis Derouin <travis at wikihow.com > wrote:
> > > > >
> > > > > I've converted some code we've been using into an extension for
> > > > importing
> > > > > properly licensed photos from flickr into a Mediawiki
> installation:
> > > > >
> > > > > http://www.mediawiki.org/wiki/Extension:ImportFreeImages
> > > > >
> > > > > It makes use of the phpFlickr package for the API calls.
> > > > >
> > > > > Feel free to play around with it here:
> > > > >
> > > > >
> > http://wikidiy.com/mediawiki-1.8.2/index.php/Special:ImportFreeImages
> > > > >
> > > > > Travis
> >
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


list: wikipedia-l

from_name: Andrew Gray

subject: [Wikipedia-l] Hungarian Wikipedia queries

body:
[This didn't get through the first time, so I'm resending it]

Hi all.

I've an open query on OTRS from someone asking about a recent spate of
deletions on the Hungarian wikipedia. Apparently, they have a number
of articles on personal names, which give such features as people with
that name, name-days, etymology and history of the name, closely
related names, and diminutives/petnames ("becenev").

These "becenev" have apparently been deleted from most such articles,
and they're wondering why. Is anyone here active on huwiki and knowing
anything about this? I've not been successful in collaring someone
from there to ask about it...

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


from_name: Steve Bennett

body:
On 12/8/06, Rob Church <robchur at gmail.com> wrote:
> As I've mentioned before in this thread, that isn't the whole case;
> rollback *will* revert more than one edit where there's a sequence of
> edits by the same contributor.
>
> In that respect, it's much more powerful.

Ok, given that "undo" is not "rollback", and that "undo" is more
user-friendly than "manual revert", can "undo" be enabled for all
users for the most recent revision? And we'll keep calling it "undo"
and insist that it's totally different from "rollback" and everyone
will be happy, right?

Steve


subject: [Wikitech-l] ImportFreeImages Extension

body:
Hi
I also found, that if you search for something and click on next, then you
get an empty page, because the next link doesn't pass on the query (ie. it
links to
http://wikidiy.com/mediawiki-1.8.2/index.php?title=Special:ImportFreeImages&p=2instead
of
http://wikidiy.com/mediawiki-1.8.2/index.php?title=Special:ImportFreeImages&p=2&q=tate)
Also if you use the search box after clicking next it passes on the query to
index.php instead of index.php/Special:ImportFreeImages (eg. I get
http://wikidiy.com/mediawiki-1.8.2/index.php?q=tate+gallery when searching
after clicking next). Could this be because after clicking next the url
changes to index.php?title=<title> form from index.php/<title> ?

Regards, Bence

On 12/10/06, Bence Damokos <bdamokos at gmail.com> wrote:
>
> Hi!
>
> Thanks for the info. Was the the image you were trying to import?
> >
> > http://www.flickr.com/photos/26155200 at N00/4787954
> >
> > I've made some changes and it seems to work now:
> >
> > http://wikidiy.com/mediawiki-1.8.2/index.php/Image:On_Vaci_Utca%2C_Budapest.jpg
> >
> >
> > I like the idea of importing the description as well, I'll look into
> > that.
> >
>
> It was what I wanted: change the +es in teh filename to spaces, and
> include a link to the original description page. And you did just that!
> Good work,
> Bence
>
>
> On 12/10/06, Luiz Augusto <lugusto at gmail.com> wrote:
> >
> > On 12/10/06, Travis Derouin <travis at wikihow.com> wrote:
> > >
> > > Unfortunately it looks like the API doesn't return the description of
> > the
> > > image:
> > >
> > > http://www.flickr.com/services/api/flickr.photos.search.html
> > >
> > > Travis
> >
> >
> > And don't get the original size of a picture :(
> >
> >
> > http://wikidiy.com/mediawiki-1.8.2/index.php/Image:The_Guggenheim_%28Subtitle-_Kissssfrazado_II%29.jpg
> >
> > http://www.flickr.com/photo_zoom.gne?id=308895239&size=o
> >
> >
> > On 12/10/06, Travis Derouin < travis at wikihow.com> wrote:
> > > >
> > > > Hey,
> > > >
> > > > Thanks for the info. Was the the image you were trying to import?
> > > >
> > > > http://www.flickr.com/photos/26155200 at N00/4787954
> > > >
> > > > I've made some changes and it seems to work now:
> > > >
> > > >
> > >
> > http://wikidiy.com/mediawiki-1.8.2/index.php/Image:On_Vaci_Utca%2C_Budapest.jpg
> > > >
> > > >
> > > > I like the idea of importing the description as well, I'll look into
> > > that.
> > > >
> > > >
> > > > Travis
> > > >
> > > > On 12/8/06, Bence Damokos < bdamokos at gmail.com> wrote:
> > > > >
> > > > > Hi
> > > > > Great extension.
> > > > >
> > > > > Unfortunately it has problems with improper file names (on a
> > search
> > > for
> > > > > Budapest , I get this message:"The filename
> > > > > "On+Vaci+Utca%2C+Budapest.jpg"
> > > > > contains characters that are not allowed in page titles. Please
> > rename
> > > > > the
> > > > > file and try uploading it again.", maybe an option to rename the
> > file
> > > > > would
> > > > > be nice).
> > > > >
> > > > > And maybe  the link to the original image, should be changed to
> > the
> > > > > description page of the image?
> > > > >
> > > > > And I don't know, if its possible, but maybe such a one click
> > import
> > > > > would
> > > > > be useful to implement on commons, so that local wiki images can
> > be
> > > > > imported
> > > > > in this way (maybe with an intermediate step with the option to
> > change
> > > > > the
> > > > > description, possibly using suggestions from the Commonshelper).
> > > > >
> > > > > Again, I must say you have done a wonderful job, and I have to say
> > I
> > > was
> > > > >
> > > > > amased by the speed of it (just one click and the image is
> > uploaded!).
> > > > >
> > > > > Keep up the good work
> > > > >
> > > > > Regards, Bence
> > > > >
> > > > > On 12/8/06, Travis Derouin <travis at wikihow.com > wrote:
> > > > > >
> > > > > > I've converted some code we've been using into an extension for
> > > > > importing
> > > > > > properly licensed photos from flickr into a Mediawiki
> > installation:
> > > > > >
> > > > > > http://www.mediawiki.org/wiki/Extension:ImportFreeImages
> > > > > >
> > > > > > It makes use of the phpFlickr package for the API calls.
> > > > > >
> > > > > > Feel free to play around with it here:
> > > > > >
> > > > > >
> > > http://wikidiy.com/mediawiki-1.8.2/index.php/Special:ImportFreeImages
> > > > > >
> > > > > > Travis
> > >
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l at wikimedia.org
> > http://mail.wikipedia.org/mailman/listinfo/wikitech-l
> >
>
>


subject: [Wikitech-l] Redirect to section

body:
On 12/9/06, Tim Starling <tstarling at wikimedia.org> wrote:
> Use it wisely -- remember that a link from one page to the middle of
> another will typically be unexpected and surprising behaviour for the
> reader, especially when the source link has no # in it. This feature is

Yes. We should have some guidelines or policies on how to deal with
the large numbers of terms that frequently redirect to one page. It's
ok when the redirected term appears in bold, or is the name of a
subheading. However, I'm particularly troubled by redirects where the
redirected term never appears at all, but is a vague synonym for the
article title.

> regularly requested, and so I implemented it on that basis. I'm sure there
> are good applications, but some amount of common sense at the editorial
> level is required.

Thanks very much for implementing this, I had been wanting it too. How
come it needed javascript?

Steve


subject: [Wikitech-l] Block message

body:
On 12/7/06, Titoxd at Wikimedia <titoxd.wikimedia at gmail.com> wrote:
> No, they (or rather, we, as I do it too) do it because 31 is a prime number,
> while 24 is not. See [[User:Drini/31 hours]].

I don't really get the prime number thing - even with reference to the
above page. Is this just being cute? Um...is this a good thing to be
cute about?

I'm also not sure I really agree with the rationale for strange block
times in general. If a vandal reappears every 24 hours, then by
blocking for any number between 24 and 48 hours, he just vandalises
every 2 days, right? It wouldn't really matter if you chose 25, 48 or
anywhere in between.

Are there not more sophisticated solutions to these problems? Like
blocking for 1 hour, but placing them on a redlist where their edits
are subjected to computer approval, and any possibly-good edits are
then subjected to human approval, before being allowed through. The
huge number of quite lengthy blocks being made each day is bound to be
catching out some good contributions.

Steve


from_name: Brion Vibber

subject:
[Wikitech-l] [Bug 8148] Apache randomly dies using up all CPU
 cycles after upgrade from 1.8.2 to trunk

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

Manuel Schneider wrote:
>> http://bugzilla.wikimedia.org/show_bug.cgi?id=8148
> I finally found the reason for this problem, but unfortunately no solution.
>
> The problem was introduced by this commit of Brion:
> http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/OutputPage.php?r1=17300&r2=17452
>
> Maybe someone of you has a solution. The problem is really bugging me as I
> have it on serveral servers and I can no longer use the wikis I have once
> upgraded to trunk (unless I use my dirty hack).

Update to r18253.

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

iD8DBQFFfLn+wRnhpk1wk44RAtHDAKCYHUrS/5A+cEERKlqYxiKqOqxEvwCgmp1Y
vLwDEwUcxYoaRs1kKw8c86Q=
=Q2qp
-----END PGP SIGNATURE-----


from_name: theProject

subject: [WikiEN-l] How to clear a backlog

body:
I've spent the last week or two observing and trying to help out with the
backlog on [[Category:Articles to be merged]]. Unfortunately, it looks like
the backlog is rapidly spinning out of control -- I haven't actually kept
track, but I have a sneaking suspicion that there are many more merge
requests added than are serviced every day. Right now the backlog is a
little under 10,000 articles, and I would like to see if we can't brainstorm
a new way to deal with backlogs, because our current methods aren't dealing
with our worst backlogs. (Our worst backlogs, ironically but expectedly, are
the ones users are least likely to start tackling.)

I was just thinking about the math, however: if 100 Wikipedians volunteered
to service one merge request per day, or 50 Wikipedians volunteered to
service an average of two per day, etc., we might make significant headway
into the backlog in three month's time. Of course, there would be new
articles to be merged, but ...

... anyway, it might not even involve actually performing the merge. A lot
of old merge requests are merges that have not gained consensus and should
just be removed. Also, since a merge request typically entails two merge
templates, it's likely we have "only" somewhere on the order of 6000~7000
actual requests. So if 100 Wikipedians, every day for a few months:

1) evaluate one merge request
2) check if the merge has consensus (or use their own discretions)
3) perform the merge

Maybe we'll make some progress clearing the backlog. (In fact, item #3 might
be as simple as copy and pasting and slapping {{cleanup}} on it to have it
checked over for redundancy and style, but of course, we'd have an even
bigger cleanup backlog then. :-) ) Any thoughts?

--
theProject


from_name: Claudi Meneghin

subject: [Wikitech-l] robot for uploading multiple pages

body:
Hi all,
  please, do you know if there's a robot for uploading multiple pages?
  That is to say, a user at LMO.WP has made up a text file (not .csv) with the appropriate wiki-code for each page, and a marker for the beginning of each page: can they by uploaded with a single operation?
  Many thanks.
  Bests,
  Claudi

---------------------------------
 Yahoo! Mail r?invente le mail ! D?couvrez le nouveau Yahoo! Mail et son interface r?volutionnaire.


body:
Hi all,
  please, do you know if there's a robot for uploading multiple pages?
  That is to say, a user at LMO.WP has made up a text file (not .csv) with the appropriate wiki-code for each page, and a marker for the beginning of each page: can they by uploaded by a single operation?
  Many thanks.
  Bests,
  Claudi

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


from_name: Finne Boonen

body:
On 12/10/06, Claudi Meneghin <clamengh at yahoo.fr> wrote:
> Hi all,
>   please, do you know if there's a robot for uploading multiple pages?
>   That is to say, a user at LMO.WP has made up a text file (not .csv) with the appropriate wiki-code for each page, and a marker for the beginning of each page: can they by uploaded by a single operation?

take a look at the pywikipedia framework, I think there's an uploadbot in there.

henna

--
"Maybe you knew early on that your track went from point A to B, but
unlike you I wasn't given a map at birth!" Alyssa, "Chasing Amy"


subject: [Wikitech-l] Redirect to section

body:
Ok, ta.

For others: it's http://bugs.wikimedia.org/show_bug.cgi?id=218

Steve

On 12/10/06, Rob Church <robchur at gmail.com> wrote:
> On 10/12/06, Steve Bennett <stevagewp at gmail.com> wrote:
> > Thanks very much for implementing this, I had been wanting it too. How
> > come it needed javascript?
>
> Read the bug report; it explains most of the issues.
>
>
> Rob Church
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


from_name: Stan Shebs

subject: [WikiEN-l] First fair use criterium

body:
Steve Bennett wrote:
> On 12/8/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>
>> It is an explicit goal of the project to produce an encyclopedia of
>> free content. Fair use images are not free. Thus it is harmful because
>> the explicit goals of the project define unfree content as a
>> non-solution.  The fact that other factors may make the harm
>> preferable to other harms does not change the fact that unfree content
>> is a harm.
>>
>
> Let's paraphrase into parable language:
>
> "The explicit goal of the project is to acquire a collection of
> apples. Therefore, every time someone gives us an orange, this is
> harmful to our project."
>
Except that we have people who argue that the project is really to
acquire a collection of fruit, and see no reason to acquire apples
because "we already have the oranges, and they taste better anyway".

A number of people on the fair use policy pages have explicitly declared
that they consider the free content goal to be secondary at most. I
suppose it's fortunate that they haven't started lifting text from other
websites en masse...

Stan


from_name: Anthere

body:
Dedalus wrote:
> Brad:
>
> You wrote:
>
> I want to specially thank the members of the audit team, Michael Davis
> and Danny Wool,
>
> Congrats first for having audited financial statements. That is great.
> Another great thing is that you published the Management Letter - which is
> rather uncommon to do.

I was actually surprised Brad chose to publish that letter, as I
remember the auditors saying it was a set of recommandations given for
internal consideration.
However, I am actually happy it is published, because it shows the
reality of what a board member needs to do. Not deciding on english
arbcom elections, not only fancy tv interviews or conferences, not
really receiving complaints in case of edit wars. But rather making sure
we build up a good and solid basis for the organisation.

> The auditors recommend the creation of an audit committee, on page 11. The
> audit team Michael Davis and Danny Wool what was their role and capacity?

Yes, there was an offical audit committee. The official audit team was
Michael David, Brad Patrick, Tim Shell and Jimmy Wales,
http://wikimediafoundation.org/wiki/Resolution_Audit_Committee.
Practically, the people who worked on the audit were not necessarily
those listed in the committee :-)

The current audit team suggested an audit committee charter, to be
submitted to board approval. This will be another step toward clearer
procedures and guidelines. I do not consider it an urgent item right
now, so I presume adoption of the charter and approval of the new audit
committee could be delayed at least january, if not february. So, it is
currently pending.

> Did they serve as a de facto audit committee? If looking for new members,
> I've a degree in economics/business administration and am a Certified
> Internal Auditor and member of the Institute of Internal Auditors (IIA,
> Inc.).

Interesting !
Noted.

> Having published the Management Letter, I would like to call attention of
> members of the community, espescially staff and committee members to another
> recommendations on page 11 of the Management Letter "Like many small
> non-profit organizations, Wikimedia Foundation, Inc., functions with a small
> staff and requires the board involvement in various management functions to
> provide needed oversight and independent review. As the organization grows
> and resources become available, we recommend systems be developed to reduce
> the need for board involvement in certain of these duties and allow the
> board to focus on overall governing, setting strategy and policy objectives,
> approving staff and committees, plans to achieve objectives and monitoring
> progress toward meeting the objectives. Also, we recommend actively seeking
> additional independent board membership."
>
> The first might involve assigning real responsibilities and authority to
> some committee - committees that already have been esthablished.

Agreed. However, we face some scaling problems with the committees, so a
re-work is planned on this very issue.

> The second point about "independent board membership" might need some
> clarification. In auditor-speak independent is someone without an executive
> positive, or a non-executive. Indepedent board members only "provide needed
> oversight and independent review", they are not directly involved in day to
> day operations or executive decision making.

Nod.
Which directly clashes with the noisy request of having mostly community
members on the board (those ones are likely to precisely get involved in
executive decision making and daily operations). And which even more
noisily clashes with the requirement for a so-called democratic electing
process to get on the board.

This is definitly the way to go. Now, the unfortunate reality of things
is that when board members do not help on a daily basis, community
members scream that Foundation jobs are not done and money does not get in.

All this is in good part as well the reason why we need significantly
more money than before. Not only to buy servers and pay bandwidth, but
also to have the necessary staff.

> Lastly I wish Brad a lot of succes in establishing a manual of policies and
> procedures, as required by the external auditors including all the specific
> policies and procedures as mentioned by the auditors.

Agreed...

> Good luck for all,
>
> Dedalus


from_name: Andrew Garrett

body:
> -----Original Message-----
> From: wikitech-l-bounces at wikimedia.org [mailto:wikitech-l-
> bounces at wikimedia.org] On Behalf Of Brion Vibber
> Sent: Sunday, December 10, 2006 7:34 PM
> To: Wikimedia developers
> Subject: Re: [Wikitech-l] What does the "undo" link do?
>
Brion Vibber wrote:
> Steve Bennett wrote:
> > On 12/8/06, Rob Church <robchur at gmail.com> wrote:
> >> As I've mentioned before in this thread, that isn't the whole case;
> >> rollback *will* revert more than one edit where there's a sequence of
> >> edits by the same contributor.
> >>
> >> In that respect, it's much more powerful.
> >
> > Ok, given that "undo" is not "rollback", and that "undo" is more
> > user-friendly than "manual revert", can "undo" be enabled for all
> > users for the most recent revision? And we'll keep calling it "undo"
> > and insist that it's totally different from "rollback" and everyone
> > will be happy, right?
>
> I don't see a particular reason not to show it; it would just be the
> same as clicking 'edit' on the previous revision. :)

Precisely why it's unnecessary.

Andrew Garrett
"Werdna"


from_name: Gregory Maxwell

body:
On 12/10/06, Aerik Sylvan <aerik at thesylvans.com> wrote:
> Here's something that looks promising:  Using MySQL's fulltext search
> against categories only.  What I did was create a table having pagenumbers
> and category text that looks like this:

Last I checked mysql FTI requires the underlying table not be innodb.
Thus no crash recovery.

In general any approach which performs well for FTI will perform well
for category intersections. The postgresql examples I posted a while
back using gist and inverted index are both normally used for FTI.


from_name: Simetrical

subject: [Wikitech-l] ImportFreeImages Extension

body:
On 12/10/06, Brianna Laugher <brianna.laugher at gmail.com> wrote:
> But these are essentially already reviewed! That's why it appears so
> useful to me. The only case this would miss is where the Flickr
> uploader has lied and the work is not actually their own (eg they
> uploaded all the promo images for their favourite band, and just
> happened to set the license as CC-BY for all their files).

They're already reviewed by someone who, quite likely, is not very
familiar with copyright law (like, it must be admitted, most people
who can upload to the Commons).  However, this is a decision for
Commonsers to make, and I won't venture an opinion.  I was just
suggesting that permissions functionality might be welcomed by some
who'd like to use the extension.  Heck, there are some wikis that are
totally locked down, and those certainly wouldn't want anons uploading
random images to them.


subject: [WikiEN-l] How to clear a backlog

references:
<28a1bd6e0612101755j5e654eabh4bca5eeaea02ae91@mail.gmail.com>
	<99c742680612101945n225b74det5bf6535d92e8b491@mail.gmail.com>
	<elimvo$ssu$1@sea.gmane.org>

body:
On 12/10/06, Tim Starling <tstarling at wikimedia.org> wrote:
>
> Utkarshraj Atmaram wrote:
> > On 12/11/06, theProject <wp.theproject at gmail.com> wrote:
> >> I've spent the last week or two observing and trying to help out with
> the
> >> backlog on [[Category:Articles to be merged]]. Unfortunately, it looks
> like
> >> the backlog is rapidly spinning out of control -- I haven't actually
> kept
> >> track, but I have a sneaking suspicion that there are many more merge
> >> requests added than are serviced every day. Right now the backlog is a
> >> little under 10,000 articles, and I would like to see if we can't
> brainstorm
> >> a new way to deal with backlogs, because our current methods aren't
> dealing
> >> with our worst backlogs. (Our worst backlogs, ironically but
> expectedly, are
> >> the ones users are least likely to start tackling.)
> >>
> >
> > Unlike wikification and other such tasks, in most cases, a merge is best
> done by
> > somebody who has little knowledge about the subject. I do hunt out the
> articles
> > to be merged that I know something about.
> >
> > Right now, many people who put the [[Template:Merge]] or
> [[Template:Mergeto]]
> > don't use [[Template:Mergefrom]]. This is one of the main reasons behind
> the
> > backlog.
> >
> > The article to be merged is usually an orphaned or little known about
> > article. On
> > the other hand, the article that is to receive the merged material is
> usually on
> > many watchlists. If [[Template:Mergefrom]] is used, many editors will
> notice
> > it and help with the merge.
>
> You want to ugly up major articles with "merge from" templates for obscure
> orphans? Why? You won't get things done even by having todo templates fly
> across every article on the site in flashing red reindeer-shaped boxes.
> Merging does not need to be centralised, it's a simple task which can be
> done by any interested editor. Like every other editorial task, it can be
> organised from the wikiprojects, perhaps with a rotation of requests on a
> wiki-wide forum like the community portal.
>
> -- Tim Starling
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

That's what I'm suggesting, I suppose -- I'm just wondering if the idea
would work. Err, did I suggest it in the wrong place?

--
theProject


subject: [WikiEN-l] First fair use criterium

body:
On 12/10/06, Steve Bennett <stevagewp at gmail.com> wrote:
> apples. Therefore, every time someone gives us an orange, this is

Unfree content is superficially indistinguishable from free content.
It is constructed similarly, and it appears to have similar
applications.

So take your example and search and replace "orange" to "poison apple"
and we have the beginnings of a parable which parallels the position
of many of the folks who disagree with you.


from_name: phoebe ayers

subject: [WikiEN-l] How to clear a backlog

body:
On 12/10/06, Tim Starling <tstarling at wikimedia.org> wrote:

>
> You want to ugly up major articles with "merge from" templates for obscure
> orphans? Why? You won't get things done even by having todo templates fly
> across every article on the site in flashing red reindeer-shaped boxes.
> Merging does not need to be centralised, it's a simple task which can be
> done by any interested editor. Like every other editorial task, it can be
> organised from the wikiprojects, perhaps with a rotation of requests on a
> wiki-wide forum like the community portal.
>
> -- Tim Starling

The merge category has kept track of how many articles have been in it over
time, though the numbers aren't up to date. The last time there was a
(recorded) maintenance collaboration of the week for merges, a year ago, the
number of articles to be merged only fell by 160 or so.
http://en.wikipedia.org/wiki/Category_talk:Articles_to_be_merged
Hey, at that rate, it'll only take 62 weeks to clean up the category,
assuming nothing else gets added to it of course.

As Utkarshraj said, subject knowledge is helpful for merging (which
shouldn't be a simple redirect, if there's anything of substance to the
article), which makes this task slightly more difficult for an editor
without that subject knowledge (this has less to do with the text itself,
I've found, and more to do with questions of whether thing A is really the
same as thing B, and does thing A deserve its own article. Merge tags often
get placed on an article without any accompanying helpful commentary). Placing
complimentary 'mergeto' tags on the major article in question simply means
that more people who work in that subject are likely to see it & do
something about it, which doesn't seem too problematic to me.

Of course, merging is small potatoes compared to the backlogs in some other
major cleanup categories, like factchecking and cleanup itself (not least
because particularly poor articles tend to get placed in multiple
categories).

-- phoebe


from_name: Edward Z. Yang

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

Marco Schuster wrote:
> the commons guys have a tool "commonist". it supports batch uploading,
> but i am not sure if it supports other wikis than commons.

Oy, people, he's looking for a tool that will upload pages (not
uploading but importing). Reformat into MediaWiki's XML format and then
use [[Special:Import]].
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFfMWGqTO+fYacSNoRAuYtAJ9NlIr3bXf5LiVB1IUGKPYrhClAYgCfYny+
z7xxdu1xDmkcVJFDYbbNiII=
=oOmc
-----END PGP SIGNATURE-----


from_name: Marco Schuster

body:
Finne Boonen schrieb:
> On 12/10/06, Claudi Meneghin <clamengh at yahoo.fr> wrote:
>
>> Hi all,
>>   please, do you know if there's a robot for uploading multiple pages?
>>   That is to say, a user at LMO.WP has made up a text file (not .csv) with the appropriate wiki-code for each page, and a marker for the beginning of each page: can they by uploaded by a single operation?
>>
>
> take a look at the pywikipedia framework, I think there's an uploadbot in there.
the commons guys have a tool "commonist". it supports batch uploading,
but i am not sure if it supports other wikis than commons.

regards
marco


subject: [Wikitech-l] Wikitech-l Digest, Vol 41, Issue 23

body:
Jens Frank wrote:

> Even worse than the crash recovery issue is the locking of MyISAM
> databases, which is not very granular. With our change rate, MyISAM is
> not an option.
>

Well... we've already established that this would have to live in a separate
table, since it would have to be MyISAM.  The table doesn't need to be
written to for each edit, only when a category is added/changed/deleted from
a page, which must be a pretty small subset of edits (wild guess: 10%?), so
maybe it's not that big a problem...?

To dig up a little history, the queries I/we have tried on the existing
categorylinks table take too long, so we either 1) can't run queries against
really big categories or 2) need a separate table/data structure.

Aerik


from_name: Rob Church

subject: [Wikitech-l] ImportFreeImages Extension

body:
On 10/12/06, Simetrical <Simetrical+wikitech at gmail.com> wrote:
> Glancing over the code, I didn't notice any permission controls.
> Maybe it would be best to set up a user permission.  It could default
> to everybody but be configurable, so that only
> sysops/autoconfirmed/etc. could upload them.  IIRC, on Commons there's
> a huge queue of images from Flickr that need to be reviewed by sysops
> to ensure that their license as labeled is actually correct, so they
> might want to restrict this easy-upload to sysops only.

You probably also want to review your naming of global configuration
variables, and make sure that there won't be any possible ambiguity
later. Also consider where the MediaWiki namespace can be used
effectively to make things more customisable for the administrators.

Rob Church


from_name: brion at pobox.com

subject: [Wikitech-l] MediaWiki automated test run failure 2006-12-11

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

Reading tests from "/home/brion/src/wiki/phase3/maintenance/parserTests.txt"...
Running test TODO: Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED!
Running test TODO: Link containing double-single-quotes '' (bug 4598)... FAILED!
Running test TODO: Template with thumb image (with link in description)... FAILED!
Running test TODO: message transform: <noinclude> in transcluded template (bug 4926)... FAILED!
Running test TODO: message transform: <onlyinclude> in transcluded template (bug 4926)... FAILED!
Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED!
Running test TODO: HTML bullet list, unclosed tags (bug 5497)... FAILED!
Running test TODO: HTML ordered list, unclosed tags (bug 5497)... FAILED!
Running test TODO: HTML nested bullet list, open tags (bug 5497)... FAILED!
Running test TODO: HTML nested ordered list, open tags (bug 5497)... FAILED!
Running test TODO: Parsing optional HTML elements (Bug 6171)... FAILED!
Running test TODO: Inline HTML vs wiki block nesting... FAILED!
Running test TODO: Mixing markup for italics and bold... FAILED!
Running test TODO: 5 quotes, code coverage +1 line... FAILED!
Running test TODO: dt/dd/dl test... FAILED!
Running test TODO: Images with the "|" character in the comment... FAILED!
Running test TODO: Parents of subpages, two levels up, without trailing slash or name.... FAILED!
Running test TODO: Parents of subpages, two levels up, with lots of extra trailing slashes.... FAILED!
Running test TODO: Don't fall for the self-closing div... FAILED!
Running test TODO: Always escape literal '>' in output, not just after '<'... FAILED!

Reading tests from "/home/brion/src/wiki/phase3/extensions/Cite/citeParserTests.txt"...

Passed 451 of 471 tests (95.75%)... FAILED!


subject:
[Wikitech-l] [MediaWiki-CVS] SVN: [18252]
	trunk/extensions/ImportFreeImages/ImportFreeImages.php

body:
On 10/12/06, travis at svn.wikimedia.org <travis at svn.wikimedia.org> wrote:
> -                       $caption = "{{" . $wgTemplateName . "|{$_POST['id']}|" . urldecode($_POST['owner']) . "|{$_POST['name']}" . "}}";

Just a quick note; in general, we use the global $wgRequest instance
of the WebRequest class to access $_GET, $_POST and $_REQUEST; the
functions perform various useful preprocessing tasks (dealing with
magic quotes, for instance) and useful type conversions and so forth.

Rob Church


list: commons-l

from_name: Brianna Laugher

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

body:
On 10/12/06, Eugene Zelenko <eugene.zelenko at gmail.com> wrote:
>
> It's great news! Should we bug developers to install extension on
> Commons as soon as possible?

I don't see why not -- as long as we can control how the info is
imported (eg, to use Template:Information, and I guess some
flickrreview thing). I just tried it out and it is frankly far easier
than searching flickr!

Undoubtedly people will not realise it is installed and continue to
manually upload Flickr images, but for people who are aware of this,
it will be a huge boon. :)

cheers,
Brianna
user:pfctdayelise


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


from_name: Aerik

body:
Gregory Maxwell <gmaxwell at ...> writes:
>
> Last I checked mysql FTI requires the underlying table not be innodb.
> Thus no crash recovery.

Well... I guess you gotta pay something for performance - the risk is that in
the even of a crash, the table would have to be rebuilt...


body:
On 11/12/06, Edward Z. Yang <edwardzyang at thewritingpot.com> wrote:
> Oy, people, he's looking for a tool that will upload pages (not
> uploading but importing). Reformat into MediaWiki's XML format and then
> use [[Special:Import]].

He's also looking for a solution that will work on Wikimedia wikis,
and Special:Import isn't enabled for that on those.

If we're talking about a huge number of pages, I see two real options.

1. Use a modified version of one of the various bots around to perform
the edits.
2. Have someone write a (safe and working) script that can read the
file we've got and perform page insertions to MediaWiki direct, then
ask a user with shell access to assist in performing the import
operation.

Given the current claimed workload of our shell users, option one
might be quicker.

Rob Church


body:
On 11/12/06, Aerik Sylvan <aerik at thesylvans.com> wrote:
> Well... we've already established that this would have to live in a separate
> table, since it would have to be MyISAM.  The table doesn't need to be
> written to for each edit, only when a category is added/changed/deleted from
> a page, which must be a pretty small subset of edits (wild guess: 10%?), so
> maybe it's not that big a problem...?

Probably higher than that, to be honest, especially with all those
Wikipedians running around, dealing with Special:Uncategorisedpages,
and correcting stub templates and so forth.

Rob Church


from_name: Jens Frank

body:
On Mon, Dec 11, 2006 at 01:31:54AM +0000, Aerik wrote:
> Gregory Maxwell <gmaxwell at ...> writes:
> >
> > Last I checked mysql FTI requires the underlying table not be innodb.
> > Thus no crash recovery.
>
> Well... I guess you gotta pay something for performance - the risk is that in
> the even of a crash, the table would have to be rebuilt...

Even worse than the crash recovery issue is the locking of MyISAM
databases, which is not very granular. With our change rate, MyISAM is
not an option.

Regards,

	jens


from_name: Swen Wacker

body:
Hi,
Claudi Meneghin schrieb:
> Hi all,
>   please, do you know if there's a robot for uploading multiple pages?
>
http://meta.wikimedia.org/wiki/Pagefromfile.py might be a solution.

Swen