from_name: Siebrand Mazeland

subject: [Commons-l] Sound files

body:
Hi guys,

I have no knowledge about this software, but Gerard indicated that 'praat'
is GPL licensed and its source is available. The code was written in C, I
assume, as C99 is required to compile it.

Wouldn't benifits be much greater is support for other file formats in praat
was arranged for somehow?

Cheers!

Siebrand

-----Oorspronkelijk bericht-----
Van: commons-l-bounces op lists.wikimedia.org
[mailto:commons-l-bounces op lists.wikimedia.org] Namens Gerard Meijssen
Verzonden: zondag 11 februari 2007 17:55
Aan: Gregory Maxwell
CC: Wikimedia Commons Discussion List; The Wiktionary
(http://www.wiktionary.org) mailing list
Onderwerp: Re: [Commons-l] Sound files

Hoi,
The problem is that existing academic software like "praat" use .wav files.
I do sympathise up to a point that storage is used. However, the price of a
terabyte of storage is such that this is not that relevant.
Both an .ogg and a .wav file would be saved. The first is to enable science
to do its thing, the second is for our punters.
Thanks,
    GerardM

http://www.fon.hum.uva.nl/praat/

Gregory Maxwell schreef:
> On 2/11/07, Gerard Meijssen <gerard.meijssen op gmail.com> wrote:
>> Hoi,
>> I read this in digest mode so let me answer things together.
>>
>> The reason why .ogg files are not great is because indeed it is a
>> lossy algorithm. There is some great software to analyse
>> pronunciation files; a program called "praat" is worth mentioning it
>> is even licensed under GPL. There is even functionality in there to do
with IPA transcription.
>>
>> Gregory's proposal to use Ogg/FLAC is not helpfull. This is not the
>> format that is used to analyse pronunciation files. The notion that a
>> specific quality was "the gold standard" at the time is indeed that.
>> It used to be, times have changed.
>>
>> The Shtooka program that we are talking about CAN create both a WAV
>> and an OGG file. It just needs asking. It would be helpful if we
>> learn sooner rather than later what the outcome is of this request.
>
> The Ogg/Flac is lossless, so it removes your concerns about lossyness.
> It can be uploaded today, so it removes the problems of not being
> uploadable. It is compressed (losslessly) so it's not quite so bad on
> our storage and bandwidth. Shtooka already outputs Flac, and could be
> trivially altered to output ogg/flac, if you'd like I will do this for
> you. Any number of Ogg/Flac files can be quickly converted to wav with
> a single command.
>
> I am very hesitant and concerned about the prospects of permitting
> uncompressed files: I think people will use them where they are
> completely inappropriate because they are a bit easier to playback.
> Flac or Ogg/Flac should be substantially smaller than wav and won't
> drive people to use uncompressed formats for bad reasons.
>

_______________________________________________
Commons-l mailing list
Commons-l op lists.wikimedia.org
http://lists.wikimedia.org/mailman/listinfo/commons-l


list: wikitech-l

source: pipermail-mbox

from_name: Rob Church

subject: [Wikitech-l] WYSIWYG (or WYSIWYM or WYSIWYM) status?

body:
On 11/02/07, Brion Vibber <brion at pobox.com> wrote:
> Last I heard they gave it up and are sponsoring another, apparently
> identical project. I don't expect it to fare any better.

Such beautiful cynicism, so poetic, so carefree.

Probably, if anybody ever wants this kind of functionality done, we
need to direct them to start helping us defining the parser behaviour.
I say this, but of course, defining the behaviour of the behemoth we
have now is a task rather akin to removing all the sand from the
Sahara.

Rob Church


list: commons-l

from_name: Stephen Bain

subject: [Commons-l] Fwd: Share-Alike with images

body:
On 2/11/07, geni <geniice at gmail.com> wrote:
>
> But CC-By-SA is claiming the film is a derivative of the sound
> recording despite film and sound being seperate under uk law. So even
> though I have made no changes to the music CC-By-SA is trying to claim
> it is under copyright again because is it is part of a film.

There are at least three copyrights potentially at play:

* Any copyright(s) subsisting in the music,
* Any copyright(s) subsisting in the moving image,
* The copyright in the film, created by synching the music and moving image.

If the music is under CC-BY-SA, then the copyright in the synching is
thus also under CC-BY-SA because the licence treats it as a derivative
work. They remain as separate copyrights.

Note that the text of the licence makes no express comments about
synching music that is not under CC-BY-SA, which is the premise of
your example.

--
Stephen Bain
stephen.bain at gmail.com


list: wikien-l

from_name: Glen S

subject: [WikiEN-l] Sanger and CZ

body:
Tell me, have any of you read this:
http://daveydweeb.com/2007/02/07/citizendium-isnt-interested-in-your-opinion/

I was shocked when I read it... that is, until I read Sanger's response
beneath it... then I was absolutely dumbfounded. With a guy with that
attitude at the helm, I'm expecting the CZ project to fizzle out VERY
quicky.

Glen
http://en.wikipedia.org/wiki/User_talk:Glen_S


from_name: Steve Bennett

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

body:
On 2/10/07, Erik Moeller <erik at wikimedia.org> wrote:
> I agree that the current process is broken; the criteria are
> increasingly unreasonable. One way to address this would be to
> whitelist the list of valid criteria, rather than allowing every user
> to come up with their own.

Agreed, but the regular voters at RFA are very insistent about their
right to set their own parameters for what makes a good admin. It
gives them a feeling of power, I guess.

Steve


subject: [WikiEN-l] Free online maths books

body:
On 2/10/07, Pedro Sanchez <pdsanchez at gmail.com> wrote:
> Some free, some not
> For instance
> "Reproduction for commercial purposes is prohibited. The cover page,
> which contains these terms and conditions, must be included in all
> distributed copies. It is not permitted to post this book for
> downloading in any other web location, though links to this page may
> be freely given."
> from "Logic for COmputer Science". A few ones GFDL, many without a
> copyright statement.

Well, considering that we're an encyclopaedia and not a textbook, I'm
proposing that we reproduce the material verbatim. But they could make
good sources, as they're publicly accessible on the internet. That
helps both writing and verifying.

Steve


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

body:
On 2/10/07, Matthew Brown <morven at gmail.com> wrote:
> Seasoned web users know this convention; newbies don't.

Ok, I stand corrected. What about my other suggestions?

Steve


from_name: Thomas Dalton

subject: [WikiEN-l] Admin burnout

body:
> Up to a point.  There are two issues: first, the /value/ of risk and
> the /value/ of reward are subjective; second, the perceived /balance/
> between them differs.
>
> To say that different individuals are more or less risk averse is only
> half the story - they may be identically risk averse but have formed
> different judgments of the value of risk in a given context.

You're absolutely right, I oversimplified things.


from_name: Guy Chapman aka JzG

subject: [WikiEN-l] Admin burnout

body:
On Sun, 11 Feb 2007 18:43:31 +0000, "Thomas Dalton"
<thomas.dalton at gmail.com> wrote:

>You're absolutely right, I oversimplified things.

That's my soapbox you're standing on there ;-)

Only a couple of days ago I received a copy of an out-of-print book,
an early work on risk by John Adams of UCL.  This is one of my
favourite topics.

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


subject: [WikiEN-l] Admin burnout

body:
> Remind me who was advocating taking risks that offer no reward?

No-one. I phrased that wrong, sorry. I meant a negative expectation,
ie. less reward than risk, which is how I assess the expectation of
this proposal, rather than no reward at all.

> Also, my question wasn't about whether one should balance risks and
> rewards, but what the right level of risk tolerance is for Wikipedia.
> I'm saying that I expect Wikipedia would be pretty hungry for
> well-managed risk. Unless people feel that the era of innovation at
> Wikipedia is more or less over, in which case the minimum-risk strategy
> you suggest seems more appropriate.

I agree, we have to take significant risks for Wikipedia to work.
Allowing everyone to edit is an enormous risk, and we frequently lose
time because of it (ie. we have to fix vandalism). However, the gain
in terms of good contributions is even more enormous, so we consider
it an acceptable risk. The risk of allowing large numbers of people
access to admin tools without the strict standards we employ at the
moment is extremely high, and the reward is very small, so (in my
opinion, according to the values I've placed on the risk and reward
and the balance between them that I've determined) it's not an
acceptable risk.


list: foundation-l

from_name: rfrangi at libero.it

subject: [Foundation-l]Ilustrating contemporary art articles without permission images

body:
> Teofilo Folengo wrote:
> Until now, the scarce contemporary art articles featuring illustrations at
> all on the French Wikipedia have been those using
> permissions-to-Wikipedia-only, for example :
> http://fr.wikipedia.org/wiki/Kim_Prisu
>
>
> Supposing that permission images will no longer be allowed on any Wikimedia
> project worldwide, how can we illustrate such articles, in the case of
> artists whose art is a way of earning a living and who are therefore
> unlikely to suscribe CC-BY-SA or GFDL licences ?
>
> A user who wrote an article on Contemporary African Art says he is in touch
> with African artists and able to take pictures. He asks what sort of
> agreement should be made with the artists before publishing on Wikipedia :
> http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Le_Bistro_multim%C3%A9dia/semaine_6_2007#images_d.27art
>
> What should I answer him ?

Tell him that if the licence is not GFDL compliant, some will claim fair use on the images, the others will simply have to remove them.

No, sorry, tell him to wait for the annoncement of WMF on allowed licenses on our project, that we all are eager to see.

Roberto (Snowdog)

------------------------------------------------------
Passa a Infostrada. ADSL e Telefono senza limiti e senza canone Telecom
http://click.libero.it/infostrada11feb07


list: wikimedia-l


from_name: Ray Saintonge

subject: [WikiEN-l] Admin burnout

body:
William Pietri wrote:

>ikiroid wrote:
>
>
>>Perhaps it's the fact that we only really promote to adminship the
>>workaholics or veterans who slipped through the cracks and we forgot to
>>nominate, so we end up with a backlog of everything. There is a lot of
>>pressure on admins and admin candidates to act perfectly, all of the time.
>>
>>
>I confess that when somebody offered to nominate me for adminship, I
>declined. It was partly that I didn't feel quite up to the
>have-you-done-everything-a-lot filter in RfA voting, and partly because
>it looked like a major time commitment, with a lot of hair-pulling involved.
>
Next week will be the 5th anniversary of my participation in Wikipedia.
I have declined adminship twice during that time.  I have been a
bureaucrat in Wiktionary and Wikisource, though I am not currently
active in those two projects.  Lately I have taken interest in a
specific Wikibook for which last week I though it would be useful to
seek adminship; so far I have two oppose votes and nothing else.

What I see in the RfA process is an attempt to draw people into tasks
and issues that don't interest them at all.  If I don't want to spend a
lot of time vandal fighting or on RC patrol or arguing the fine points
of policy why should I commit to that.  For those of us who come here to
develop information in an area of interest our work as admins will be an
extension of that.  As a consequence a good admin will deal with the
problem people when they begin to affect his areas of interest.  Who
would want to spend time debating deletion requests about subjects in
which he has neither interest nor knowledge.

If new admins are expected to spend their time grovelling about in the
muck it's no wonder that they burn out so quickly.

>I don't know if it's correct, but my impression was that ten hours a
>week was about a minimum to do it right. I felt like staying an editor
>let me keep the ability to put in time as schedule and stress level allow.
>
If you have only ten hours a week to contribute you may want to take a
more focussed approach to your efforts, both as an editor and as an admin.

>Now that I think about it, though, maybe I got that impression from
>watching the busy ones burn out.
>
Sounds like an excellent reason to avoid being an admin. :-)

Ec


subject: [WikiEN-l] Deleting orphaned unfree images

body:
> I was thinking your motivation was to reduce some real-world harm. E.g.,
> images sitting for a week causes difficulty X to person Y. I gather
> you're saying it's a more abstract thing, an aesthetic preference?

The real world harm is that of copyright violations. IANAL, so I don't
know if it is actually illegal for us to have unfree images on the
site for a week without them being fair use, but it has to be quite
close to that fine line. Just because we can't technically be punished
unless we refuse to remove it upon request doesn't make it legal for
us to keep it there until that request is made (by my understanding of
the law - if I assault someone, I can't be punished unless they decide
to press charges, them not pressing charges doesn't make my act legal,
though).


from_name: Gregory Maxwell

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

body:
On 2/11/07, rfrangi at libero.it <rfrangi at libero.it> wrote:
> You see, when we decided to accept images "used with permission" and or with the NC clause, it was done for the very same reasons on en.wiki copyrighted material is used claiming fair use. This is our workaround for not being able to claim fair use, in fact, you will notice that there are cases in which the same image appears on en.wiki with the fair use template and on it.wiki with the "used with permission" or NC template.
>
> That's the reason why, when we are told we should remove those images, but on en.wiki fair use is just ok, people get pissed and obviously talks about U.S. centrism.
>
> In this thread someone said that renounce to fair use would be  an intollerable limitation to the freedom of speech. The way we use NC and "used with permission" images is by any respect equivalent to the way you use copyrighted material claiming fair use.
>
> So in the end having to phase out those images, for us, is an intollerable limitation to our freedom of speech.

This is not the case at all.. You can continue to accept "with
permissions" images, so long as they would also qualify as Fair Use.

If what you are saying is completely true, that you only use "with
permissions" because there is no fair use in your local law then no
images would need to be deleted at all.

However, this does not appear to be the case on itwiki:
http://it.wikipedia.org/wiki/Speciale:PuntanoQui/Template:Copyrighted

Where very many of these images could have be recreated as free works
by anyone.. many of them are even the works of wikipedians but they
are not released as free content.


from_name: geni

subject: [Foundation-l] Use of logos within Wikimedia sites

body:
On 2/11/07, Anthere <Anthere9 at yahoo.com> wrote:
> Plus another reason: avoiding other parties to misuse the logo (such as
> using it to promote a right wing encyclopedic website) and as such
> damaging our image.

How do you think they would do that without violating your trademark?

--
geni


list: textbook-l

from_name: Andrew Whitworth

subject: [Textbook-l] Offer to upload a book, subject to conditions

body:
>Okay, it seems that everyone is happy with the idea of posting it with
>a link back to a controlled copy on her website.  I've explained the
>terms of the GFDL to her and she's perfectly happy with them.  I'll
>probably end up putting the book up sometime reasonably soon.

What format is your book in, currently? If it's in HTML currently, or some
other kind of text-markup format, I have a bot available that can quickly
handle the formatting changes. If not, you have to do it all the hard way
(which I know from experiance can be a big pain).

>On 2/8/07, Andrew Whitworth <wknight8111 at hotmail.com> wrote:
> > This would be perfectly acceptable. As has been done in the past, if a
>book
> > is donated to wikibooks, prominent links will be displayed to the
>original
> > version of the book, and information will be posted about the original
> > author.
>
>Just for reference, what's an example of such a Wikibook?

When the UN APDIP donated their library of ebooks to our project, we
included links to all the original PDF versions on the UN website. You can
see all these books at [[Category:APDIP Books]]. All of those ebooks also
include information about the original authors, and other meta-information
to help direct interested readers back to the UN. An important point to make
here, however, is that the links to the UN website are not considered to be
links "for profit", and so we don't consider them spam or anything like
that.

-- Andrew Whitworth

_________________________________________________________________


from_name: jkelly at fas.harvard.edu

body:
Quoting Gregory Maxwell <gmaxwell at gmail.com>:

> However, this does not appear to be the case on itwiki:
> http://it.wikipedia.org/wiki/Speciale:PuntanoQui/Template:Copyrighted
>
> Where very many of these images could have be recreated as free works
> by anyone.. many of them are even the works of wikipedians but they
> are not released as free content.

That's disappointing to read.  I imagine, however, that this also happens on
projects disallowing "permission only for Wikipedia" but allowing fair use.

                Jkelly


subject:
[Textbook-l] Recent events surrounding the Social and
	CulturalFoundations of

body:
>...
>I would sincerely appreciate that.
>--Iamunknown

Both Johnny and myself sent the user a message about this issue. I agree
that it's not only frustrating, but also causes potential legal problems,
and needs to be dealt with.

--Andrew Whitworth

_________________________________________________________________
Get in the mood for Valentine's Day. View photos, recipes and more on your
Live.com page.
http://www.live.com/?addTemplate=ValentinesDay&ocid=T001MSN30A0701


from_name: Anthere

body:
geni wrote:
> On 2/9/07, Samuel Klein <meta.sj at gmail.com> wrote:
>
>>Since we also have the benefit of an official Foundation logo, perhaps
>>the project logos can themselves be open-use.  What are the problems we
>>are trying to avoid, and what things that we want are being held back
>>due to licensing issues?
>>
>
>
> the foundation wishes to be able to raise money by lisenceing the use
> of the logo to third parties

yes.
Plus another reason: avoiding other parties to misuse the logo (such as
using it to promote a right wing encyclopedic website) and as such
damaging our image.

These two reasons (image and possibility to raise money) explain why the
Foundation will not put the logos under a free licence.

>>For the latter point, there is a joy of creativity and
>>project-identification when a WikiProject develops its own visual
>>identity, whether that is in the form of style guidelines, unified
>>template or infobox format, or icons and logos.  And there is a wider
>>remix culture around a project that is encouraged by incorporating
>>community icons into images and other media in innovative ways.
>>
>
> Community icons yes. The logo no unless you ask permission.

There is now a community logo.

ant


from_name: Gary Kirk

subject: [Foundation-l] Featured Article

body:
This seems to have been a cross-post to foundation-l by a newbie - it
has been posted to mediawiki-l, where I will respond :)

On 2/11/07, David Strauss <david at fourkitchens.com> wrote:
> I'd answer, but I don't want to encourage posting MediaWiki questions to
> the Foundation listserv. Please use the MediaWiki listserv or other
> MediaWiki-specific resources, like #mediawiki.
>
> Wilson Abigaba wrote:
> > Hi,
> >
> > I installed mediawiki 1.6 and am trying to put featured article, popular
> > article, etc on the home page, just like wikipedia.
> > Any ideas on how I can do that?
> >
> > Thanks in advance,
> >
> > regards,
> > Wilson
> >
> >
> >
> > _______________________________________________
> > foundation-l mailing list
> > foundation-l at lists.wikimedia.org
> > http://lists.wikimedia.org/mailman/listinfo/foundation-l
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/foundation-l
>

--
Gary Kirk


subject: [Foundation-l] Featured Article


from_name: Fred Bauder

subject: [WikiEN-l] Sanger and CZ

body:
>-----Original Message-----
>From: Keitei [mailto:nihthraefn at gmail.com]
>Sent: Sunday, February 11, 2007 10:28 AM
>To: 'English Wikipedia'
>Subject: Re: [WikiEN-l] Sanger and CZ
>
>Being an expert
>doesn't mean one can use English as effectively as is required for an
>authoritative encyclopedia. Sure, experts can say, "this is factually
>accurate," but can they explain in an encyclopedic tone the basics of
>their field? [material on Biology article removed] Unless
>Citizendium has a hidden army of English majors. Which it might. But
>maybe they are only allowed to edit linguistics articles.

>--keitei

Looking at law, I guess what Larry would consider an expert would be an academic such as a professor of law. His language regarding qualifications for editor, "editors in more "professional" fields require the usual terminal professional degree in the field plus significant experience and publishing."
http://www.citizendium.org/cfa.html
Some practicing attorneys would qualify, the crew that puts together the continuing legal education, for example. I guess some attorneys do continue to contribute to law journals, especially those who worked on them in school.

Some of these people are wonderful communicators, especially the trial lawyers who are good at addressing juries. Take a look at John Edwards, the presidential candidate. He's good. The people are out there, but most are probably not even aware that the option exists. One thing that is going on is that we, and society, are very new at this. One of Larry's ideas is for every profession and academic discipline to have a collaborative venue for sharing and developing knowledge (I think he is probably just reinventing the university, but that is not such a bad idea). The professions and academic disciplines he is considering are very far from participating in such a system of wikis, but, given a time, a few decades, that may well be part of our common intellectual life. See
http://www.citizendium.org/collab_prof.html

Anyway, I think it is best we treat Larry as a colleague engaged in friendly competition. He's got some good ideas. But so do we.

Fred


from_name: Magnus Manske

body:
On 2/11/07, Brion Vibber <brion at pobox.com> wrote:
> Seriously, though, we should all get together and make a concerted effort.
>
> I would recommend making a start by looking at the XML structure used by
> Magnus' conversion tools; if we need to adapt that further to integrate
> properly or if we can just poke around with that?
>
> Having a clear data model is a definite must; making the parser for it
> clean and fast can follow. :)

I stopped working the XML thing because of time issues ;-) and one
particularly nasty problem. Currently, wiki2xml needs to replace
templates while parsing. What it *should* do is optionally offer a way
to just put in a template placeholder XML tag, consisting of template
name and passed values. However, as our wiki code basically allows
templates everywhere, this will easily break the other XML that is
generated.

However, it worked OK (last time I checked) with most of our wiki code
except conditional/calculation template functions.

Magnus


subject: [WikiEN-l] Sanger and CZ

body:
On 2/11/07, stvrtg <stvrtg at gmail.com> wrote:
>
> The whole point of CZ is greater reliability, but:
>
>    The article below may contain errors of fact, bias, grammar, etc. The
> Citizendium
>    Foundation and the participants in the Citizendium project make no
> representations
>    about the reliability of this article or, generally, its suitability for
> any purpose. We make
>    this disclaimer of all Citizendium article versions that have not been
> specifically approved."
>
> Sort of says it all.

Add it to this list:

http://en.wikipedia.org/wiki/Wikipedia:Non-Wikipedia_disclaimers

--
Stephen Bain
stephen.bain at gmail.com


from_name: Robert Scott Horning

body:
Andrew Whitworth wrote:

> When the UN APDIP donated their library of ebooks to our project, we
> included links to all the original PDF versions on the UN website. You
> can see all these books at [[Category:APDIP Books]]. All of those
> ebooks also include information about the original authors, and other
> meta-information to help direct interested readers back to the UN. An
> important point to make here, however, is that the links to the UN
> website are not considered to be links "for profit", and so we don't
> consider them spam or anything like that.
>
> -- Andrew Whitworth

I don't think that the issue of external links on Wikibooks or any other
Wikimedia project really has to do much with wheither the link is "for
profit" or not.  The main issue is if the link has any relevance to the
material that it is related to.  A Wikipedia article (or even a how-to
repair manual on Wikibooks) about the Ford Motor Company certainly can
have a link to the official corporate website... and be considered a
high quality link.

In the case of the UN APDIP books, a link to the original PDF files is
certainly relevant as it is the original source material, and you are
maintaining academic integrety by noting the original source of the
text.  In a similar vein, if this offer to have the book on Wikibooks
were to happen or even if it were just used as source material to create
a very different book, its use as a bilbliographic reference certainly
is very justified.

The problem with link spamming is that 300 links for Viagra on a page
about Quantum Mechanics is completely irrelvant to the topic under
discussion.  A sexual health Wikibook, on the other hand.....

--
Robert Scott Horning


from_name: Florian Straub

subject: [Commons-l] Making a home wiki field in user login

body:
"Brianna Laugher" <brianna.laugher at gmail.com>  Sunday, February 11, 2007
2:15 PM:

>I think it would make more sense to ask the user explicitly, "How
> would you like to be informed if your files are nominated for
> deletion?"
> x Never inform me
> x Inform me at my Commons talk page (default)
> x Inform my at my talk page at another wiki, which is User:_ at
> project _ (fill in the blanks)
> x Inform me via email; I have verified my email in my Commons account.

Sounds great.

> that would be pretty cool actually.

> Anyway, unfortunately I have to agree with Platonides et al that we
> should wait and see exactly what SUL brings. How the watchlist(s) will
> work has not been made terribly clear, at least in anything I've seen.

Why not inplementing a javascript and/or template solution before waiting
for another few years?

Regards,

Flo


from_name: Keith Old

subject: [WikiEN-l] Sanger and CZ

body:
On 2/11/07, Glen S <wikiglen at gmail.com> wrote:
>
> Tell me, have any of you read this:
>
> http://daveydweeb.com/2007/02/07/citizendium-isnt-interested-in-your-opinion/
>
> I was shocked when I read it... that is, until I read Sanger's response
> beneath it... then I was absolutely dumbfounded. With a guy with that
> attitude at the helm, I'm expecting the CZ project to fizzle out VERY
> quicky.
>
> Glen
> http://en.wikipedia.org/wiki/User_talk:Glen_S
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at lists.wikimedia.org
> To unsubscribe from this mailing list, visit:
> http://lists.wikimedia.org/mailman/listinfo/wikien-l
>
Glen,

Thanks for posting this.

It confirms my belief that Citizendium is having serious problems. In a
Citizendium post announcing that they would no longer be forking Wikipedia,
Larry Sanger claimed that they had 24 active contributors as I recall. That
isn't very many and it seems that a couple of those are no longer active.
Sanger's claims about micromanaging suggests that many of the senior people
aren't contributing much. Twenty odd people aren't terribly many people for
a project of Citizendium's claimed ambit.

He seems to have annoyed many of the experts that have signed up as shown by
the post by another contributor and the problems over Afro-American
literature discussed previously on the list.

Larry Sanger has been talking about how Citizendium will be much better than
Wikipedia. It hasn't gone live yet and I doubt that it will for some months.
If it does, I am predicting that I will fall well short of Wikipedia in both
quantity and quality.

Regards

Keith Old


from_name: David Still

subject: [WikiEN-l] Sanger and CZ

body:
Disclaimer: I'm the same David Still that wrote the blog post being
discussed. :)

> We are obviously only hearing one side of the story, but even so it's
> pretty crazy. Hearing from the former CZ editor in the comments
> backing him up helped, of course.

On this note, I strongly suggest that you read through as much of the
thread as is available. The relevant links, in chronological order, go
like this:

1. My original post at Ars Technica, under the username 'stigmata', in
which I make many of the same points. I was responded to by Mike
Johnson of the CZ Executive Committee ('johnsonmx').
http://episteme.arstechnica.com/eve/forums/a/tpc/f/174096756/m/691002192831?r=453008192831#453008192831

2. The (criticism-only) blog post that followed:
http://daveydweeb.com/2007/02/03/and-yet-still-so-far-to-go/

3. My suggestions for change, based on the previous two posts, and the
rejection email from Citizendium-L (be sure to read the forum thread I
linked to): http://daveydweeb.com/2007/02/03/and-now-the-suggestions/

4. My announcement that I'd put a proof-of-concept online,
demonstrating one idea for improving the Approval process:
http://daveydweeb.com/2007/02/06/making-approval-not-suck/

5. My bitter response to Larry's rejection of the above idea:
http://daveydweeb.com/2007/02/07/citizendium-isnt-interested-in-your-opinion/

Those five links provide as close to the full story as is publicly
available. I should note that a number of Citizendium contributors
have taken a very agreeable stance toward me, as you'd see at my
Citizendium talk page and the CZ forum thread linked above --
especially Mike Johnson, who's been very moderate and civil throughout
the debate.

I'll try not to argue my point too much, here. I just sensed a need to
point out a little more of the story.

Cheerio,
David


from_name: Eric Astor

body:
Nick Jenkins wrote:
>> As one of the many people who's done so, I agree. :)  The problem is
>> that ~80% of wikimarkup is pretty straightforward to parse using
>> standard methods, another 10-15% can be done without huge difficulty
>> using known-but-less-standard methods, and the remaining 5% doesn't fit
>> well at all into any of the normal models of lexing/parsing.
>>
>> [...snip...]
>>
>> -Mark
>
> Can I maybe suggest please giving some examples that you encountered of
> the 10-15% hard category, and the 5% very hard category?
>
> I ask so that if anyone feels tempted to start on defining the behaviour,
> we can gently suggest doing the harder stuff *first* (with examples),
> thus hopefully preventing the situation where we have multiple unfinished
> 80%-done definitions, and no 100%-complete formal definitions.
>
> All the best,
> Nick.

Just one example - probably of the 5% very hard category:

'''''hello''' hi''
vs.
'''''hi'' hello'''

Rendered in HTML, the first reads hello hi, and the second
reads hi hello. The problem is that the meaning of the
first 5 quotes changes based on the order in which the bold and italic
regions close - which is not determined while scanning left-to-right.

Another example:

'''hello ''hi''' there''

MediaWiki renders this as hello hi there, properly
handling overlapping formatting.

There are ways to deal with these... putting off the resolution until a
later pass is the only way I know of that deals with the first one, and
it's a bit touchy. Manageable, but touchy.

If I have time this summer, I'm going to look at formalizing a parser
again... see if I can make a start on hammering out a somewhat more
formal structure for handling some of the tougher cases, after I've
tackled OLPC's CrossMark.

- Eric Astor


body:
Eric Astor wrote:
> There are ways to deal with these... putting off the resolution until a
> later pass is the only way I know of that deals with the first one, and
> it's a bit touchy. Manageable, but touchy.

Clarification: The cases I mentioned can't be handled by a context-free
parser - but both of them are parseable if ''' is parsed as a
TOGGLE-BOLD item, and '' is handled similarly as a TOGGLE-ITALICS. That
lets you escape the context-sensitivity, and handle the rendering
properly on the output end while scanning left-to-right.

- Eric


from_name: Simetrical

body:
On 2/11/07, Eric Astor <eastor1 at swarthmore.edu> wrote:
> Just one example - probably of the 5% very hard category:
>
> '''''hello''' hi''
> vs.
> '''''hi'' hello'''
>
> Rendered in HTML, the first reads hello hi, and the second
> reads hi hello. The problem is that the meaning of the
> first 5 quotes changes based on the order in which the bold and italic
> regions close - which is not determined while scanning left-to-right.

This is where we could redefine the behavior slightly.  Have '''''
always be .  Then, if ''' occurs first, output .  On
the other hand, from what you say next, I'm not sure that will help.

> Another example:
>
> '''hello ''hi''' there''
>
> MediaWiki renders this as hello hi there, properly
> handling overlapping formatting.
>
> There are ways to deal with these... putting off the resolution until a
> later pass is the only way I know of that deals with the first one, and
> it's a bit touchy. Manageable, but touchy.

Well, we could just output invalid XML for both these cases and then
fix it in the Sanitizer/Tidy pass, I guess.  In some clearly defined
manner, of course, perhaps stated informally in the grammar, or
formally as a separate non-parsing algorithm.


from_name: Thomas Dalton

subject: [WikiEN-l] Admin burnout

body:
> You do realize that for much of Wikipedia's history, the route to being
> an admin was much less strict than we have now. Despite this, and
> despite the fact that there are relatively very few cases of people
> being "de-adminned", cases of rogue admins doing huge damage are either
> non-existent or very rare, depending on what you consider "huge damage".
>
> Why is it that those admins, let in under much less strict processes,
> have not resulted in all the nastiness that are predicted if we somehow
> relax the process again?

The main difference between Wikipedia then and Wikipedia now is that
we now have people reading who don't contribute. Contributors know
what to expect, they don't mind a little vandalism because they know
how to fix it. Readers need what's visible at the moment to be right,
not just something hidden away in the history. When Wikipedia first
started, the only people that read it were those that contributed too,
that is no longer the case. Originally, Wikipedia was made by geeks,
for geeks. Now it is made by geeks for the world (for a suitable
definition of geek - there are so many definitions out there, I'm sure
one fits). We have a responsibility to our readers.


list: wikipedia-l

from_name: Gerard Meijssen

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

body:
Delirium schreef:
> Andrew Gray wrote:
>
>> On 10/02/07, David Monniaux <David.Monniaux at free.fr> wrote:
>>
>>
>>> Andrew Gray a ?crit :
>>>
>>>
>>>> Bear in mind that copyright is not related to your right not to have
>>>> your image used in a defamatory or misleading manner - whatever rights
>>>> the law gives you in this regard you retain whether you hold the
>>>> copyright or not.
>>>>
>>>>
>>> Actually, it is.
>>>
>>> Proof: the Wikimedia Foundation *copyrights* its logos under *unfree
>>> licenses* exactly for that reason: for being able to control their use
>>> more effectively than through trademark law solely.
>>>
>>>
>> Sorry, by "your image" here I meant "the photograph of you" (ie, the
>> image in question). Images which aren't a photographic representation
>> of a person don't tend to be covered by these protections, hence the
>> workarounds...
>>
>>
>
> Though even there it's not clear that the workarounds are necessary or
> beneficial.  Sun recently freely licensed the copyright on their Java
> mascot ("Duke"), and is controlling use exclusively through the
> trademark that they retain on it.  Mozilla, meanwhile, has been famously
> tightfisted with their Firefox logo, and it has led to a great deal of
> rancor within the open-source/free-software community, arguably
> outweighing any benefit they've gained from that control.
>
> -Mark
Hoi,
There are two sides to the coin. You assume that Mozilla lost out. Maybe
so, but Debian lost most of its credibility in the eyes of many others.
The sheer stupidity of it all is one of the impediments that works
against the uptake of Linux on the desktop. Including my desktop.

Thanks,
    GerardM


from_name: Bryan Tong Minh

body:
Implementing watchlists in Javascript? I have implemented a watchlist
in javascript [1], but the problem is that javascript does not allow
cross website scripting. So there is no way I can fetch the data from
an other hostname.

Bryan
[1] http://commons.wikimedia.org/wiki/Commons:ExtendedWatchlist

On 2/11/07, Florian Straub <flominator at gmx.net> wrote:
> "Brianna Laugher" <brianna.laugher at gmail.com>  Sunday, February 11, 2007
> 2:15 PM:
>
>
> >I think it would make more sense to ask the user explicitly, "How
> > would you like to be informed if your files are nominated for
> > deletion?"
> > x Never inform me
> > x Inform me at my Commons talk page (default)
> > x Inform my at my talk page at another wiki, which is User:_ at
> > project _ (fill in the blanks)
> > x Inform me via email; I have verified my email in my Commons account.
>
> Sounds great.
>
> > that would be pretty cool actually.
>
> > Anyway, unfortunately I have to agree with Platonides et al that we
> > should wait and see exactly what SUL brings. How the watchlist(s) will
> > work has not been made terribly clear, at least in anything I've seen.
>
> Why not inplementing a javascript and/or template solution before waiting
> for another few years?
>
> Regards,
>
> Flo
>
>
>
> _______________________________________________
> Commons-l mailing list
> Commons-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/commons-l
>


from_name: Ray Saintonge

subject: [WikiEN-l] Admin burnout

body:
George Herbert wrote:

>On 2/8/07, SonOfYoungwood at aol.com <SonOfYoungwood at aol.com> wrote:
>
>
>>To keep burned out admins from leaving, we need to give them praise and
>>encouragement. They need to be seen as some of our most valued contributors. We
>>might also want to set up incentives.
>>
>>
>I agree with this, but we also have the problem that a common (but not
>universal) near-the-end trait is blocks or other user admin stuff
>which turn out to be very controversial.  How do you say "we really
>like what you've done for the project and we want you to stay" and
>"...but can you stop beating up newbies this badly?" at the same time?
>
What you describe seems like a sign of frustration and siege mentality.
The task becomes so huge that the admin becomes overwhelmed.  For some
it appears even bigger than it really is.  Combine this with an
atmosphere of serious mistrust where he believes the other guy is either
trying to delete everything or keep everything, and you can soon become
non-functional.

Every admin should severely limit the amount of time he spends on admin
duties.  Spending a greater proportion of time on what really matters
helps maintain a vision of what this is all about.

Ec


subject: [WikiEN-l] Admin burnout

body:
Jeff Raymond wrote:

>George Herbert wrote:
>
>
>>We apparently just lost Alkivar (hopefully just on a stress relief
>>break, but he says he's out of here indefinitely).
>>
>>We're doing terribly at keeping identified, overstressed admins from
>>ending up going over the edge.  What are we doing wrong, or what do we
>>need to learn to do right?
>>
>>
>On the other side, his message isn't really just about admins, but
>editors in general.  People who edit articles simply are not valued on
>this project anymore.  Tha'ts a big problem, since it's people who edit
>articles that got us to this point.
>
Absolutely!  Newbies get jumped on for breach of incomprehensible
rules.  Articles are cluttered with transclusion templates that only the
experts know how to edit properly.  Articles get threatened with
deletion because they don't have the right kind of references.  Some
editors become so obsessed with trying to be authoritative that they
take all the fun out of editing.  We all want an accurate reference
work, but there are certain intangibles that we should not accept as
part of the cost.

Ec


from_name: Wilson Abigaba

subject: [Foundation-l] Featured Article

body:
Hi,

I installed mediawiki 1.6 and am trying to put featured article, popular
article, etc on the home page, just like wikipedia.
Any ideas on how I can do that?

Thanks in advance,

regards,
Wilson


subject: [Foundation-l] Featured Article


from_name: geni

body:
On 2/11/07, David Strauss <david at fourkitchens.com> wrote:
> Not only do I agree, but I believe a similar issue surrounds fair use.
> Accusations of U.S. centrism are indefensible when they're based on
> restrictive laws in non-U.S. countries.
>
> Now, that doesn't mean there aren't practical advantages to
> accommodating other countries' needs, but the lack of doing so is hardly
> "U.S. centrism."
>

The problem with that is the logical end point of that position is the
move the foundation and servers to Iran. There are a number of items
that are public domain in their home country but not in the US that we
as a result we do not accept. US laws are liberal in one area but in
others not so much.  Assuming shortest possible term sound recordings
in the US are protected for 20 years longer than they are in the UK.

--
geni


subject: [WikiEN-l] Admin burnout

body:
Guy Chapman aka JzG wrote:

> Ultimately the only way to fix this is probably to be more willing to
>
>chuck out people who resolutely refuse to follow policy.  Look at the
>crap Carnildo got simply because he was bot-tagging images which
>violate our copyright policies.  A lot of Alkivar's problem is that
>there are quite a few editors who flatly refuse to accept that an
>image scraped off the net somewhere is not an inherently legitimate
>illustration for any vaguely related article.  That's probably the
>biggest cause of friction.
>
>The second major cause of admin burnout in my opinion is trying to
>keep insidious POV pushers and off-wiki warriors apart.  As soon as
>you step in and prevent one action, you are immediately seen as
>"involved" and are no longer trusted by the other side - the best that
>can happen is when both sides decide you are biased against them.
>Wikipedia is the number 1 destination for people seeking to fix
>problems without he outside world, and the editors who come here to
>pursue these agendas have endless time to pursue them.  Caring even
>slightly about the neutrality of the project means that you *will* get
>stress.
>
>The third biggest cause of friction is groups who believe they
>"deserve" a Wikipedia article because they are so great, even though
>there are no reliable secondary sources.  I am getting crap at the
>moment about the General Mayhem forum, which is of surpassing
>significance to its members and (as far as I can tell) nobody else.
>
The problem I find with this analysis is that it's too one sideed.  You
outline three broad problems that do indeed happen, and take up a lot of
admin time.  Still another huge problem is the tendency of some admins
to zealotry, or assuming that a small error by a newbie is a precursor
to vandalism.  The most desirable skill in an admin is patience, and we
don't see much of that.

Ec


from_name: bawolff

subject: [Commons-l] Ogg/flac

body:
In response to:
Message: 1
Date: Sun, 11 Feb 2007 08:10:42 +0100
From: Gerard Meijssen <gerard.meijssen at gmail.com>
Subject: Re: [Commons-l] Sound files
To: commons-l at lists.wikimedia.org,      "The Wiktionary
       (http://www.wiktionary.org) mailing list"
       <wiktionary-l at lists.wikimedia.org>
Message-ID: <45CEC172.4070608 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hoi,
I read this in digest mode so let me answer things together.

The reason why .ogg files are not great is because indeed it is a lossy
algorithm. There is some great software to analyse pronunciation files;
a program called "praat" is worth mentioning it is even licensed under
GPL. There is even functionality in there to do with IPA transcription.

Gregory's proposal to use Ogg/FLAC is not helpfull. This is not the
format that is used to analyse pronunciation files. The notion that a
specific quality was "the gold standard" at the time is indeed that. It
used to be, times have changed.

The Shtooka program that we are talking about CAN create both a WAV and
an OGG file. It just needs asking. It would be helpful if we learn
sooner rather than later what the outcome is of this request.

Thanks,
   GerardM

Umm, so what's stoping you from converting it back to wav? ogg/FLAC is
completely lossless, so no information will be lost.

bawolff


subject: [Commons-l] ogg/flac

body:
sorry, I get this in digest mode. I didn't realize someone already said that

-bawolff
>In response to:
>Message: 1
>Date: Sun, 11 Feb 2007 08:10:42 +0100
>From: Gerard Meijssen <gerard.meijssen at gmail.com>
>Subject: Re: [Commons-l] Sound files
>To: commons-l at lists.wikimedia.org,      "The Wiktionary
>      (http://www.wiktionary.org) mailing list"
>      <wiktionary-l at lists.wikimedia.org>
>Message-ID: <45CEC172.4070608 at gmail.com>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>>Hoi,
>>I read this in digest mode so let me answer things together.
>>
>>The reason why .ogg files are not great is because indeed it is a lossy
>>algorithm. There is some great software to analyse pronunciation files;
>>a program called "praat" is worth mentioning it is even licensed under
>>GPL. There is even functionality in there to do with IPA transcription.

>>Gregory's proposal to use Ogg/FLAC is not helpfull. This is not the
>>format that is used to analyse pronunciation files. The notion that a
>>specific quality was "the gold standard" at the time is indeed that. It
>>used to be, times have changed.

>>The Shtooka program that we are talking about CAN create both a WAV and
>>an OGG file. It just needs asking. It would be helpful if we learn
>>sooner rather than later what the outcome is of this request.

>>Thanks,
>>  GerardM

>Umm, so what's stoping you from converting it back to wav? ogg/FLAC is
>completely lossless, so no information will be lost.

>bawolff


from_name: Gregory Szorc

subject:
[Wikitech-l] [MediaWiki-CVS] SVN: [19878]
	trunk/extensions/HTTPRedirect/HTTPRedirect.php

body:
Sorry for this.  My editor somehow lost its encoding settings for the
MediaWiki project.

Gregory Szorc
gregory.szorc at gmail.com

On 2/11/07, nikerabbit at svn.wikimedia.org <nikerabbit at svn.wikimedia.org>
wrote:
>
> Revision: 19878
> Author:   nikerabbit
> Date:     2007-02-11 02:42:08 -0800 (Sun, 11 Feb 2007)
>
> Log Message:
> -----------
> * There was nothing wrong with encoding, please note that we use UTF-8
> everywhere
>
> Modified Paths:
> --------------
>     trunk/extensions/HTTPRedirect/HTTPRedirect.php
> Modified: trunk/extensions/HTTPRedirect/HTTPRedirect.php
> ===================================================================
> --- trunk/extensions/HTTPRedirect/HTTPRedirect.php      2007-02-11
> 06:31:06 UTC (rev 19877)
> +++ trunk/extensions/HTTPRedirect/HTTPRedirect.php      2007-02-11
> 10:42:08 UTC (rev 19878)
> @@ -2,15 +2,15 @@
> /**
>   * An extension to make the wiki issue HTTP redirects rather than wiki
> redirects
>   *
> - * @author \xC6var Arnfj\xF6r\xF0 Bjarmason <avarab at gmail.com>
> - * @copyright Copyright \xA9 2005, \xC6var Arnfj\xF6r\xF0 Bjarmason
> Bjarmason
> + * @author ?var Arnfj?r? Bjarmason <avarab at gmail.com>
> + * @copyright Copyright (c) 2005, ?var Arnfj?r? Bjarmason
>   * @license http://www.gnu.org/copyleft/gpl.html GNU General Public
> License 2.0 or later
>   */
>
> $wgExtensionCredits['other'][] = array(
>         'name' => 'HTTP redirect',
>         'description' => 'A hook to make the wiki issue HTTP redirects
> rather than wiki redirects',
> -       'author' => '\xC6var Arnfj\xF6r\xF0 Bjarmason',
> +       'author' => '?var Arnfj?r? Bjarmason',
> );
>
> $wgExtensionFunctions[] = 'wfHTTPRedirect';
> @@ -23,7 +23,7 @@
>                 public function __construct() {
>                         global $wgHooks;
>
> -                       $wgHooks['ArticleViewRedirect'][] = array(&$this,
> 'redirectHook' );
> +                       $wgHooks['ArticleViewRedirect'][] = array( &$this,
> 'redirectHook' );
>                 }
>
>
>
>
>
>
> _______________________________________________
> MediaWiki-CVS mailing list
> MediaWiki-CVS at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/mediawiki-cvs
>


references:
<NABBJGECPILFNLFEAPIKCEEMKAAA.nickpj@gmail.com>
	<45CFD8C9.2010300@swarthmore.edu>
	<b8ceeef70702112024j4349bf54w767cb499eefee421@mail.gmail.com>

body:
On 2/11/07, Steve Bennett <stevagewp at gmail.com> wrote:
> How much of this task is possible without looking at the code base?
> How much can be done merely by inspection? Would it be possible for
> someone (Brion, yourself?) to structure this apparently very large
> task in such a way that non-developers like me would be able to
> contribute bite-size pieces of work? Such a task might look something
> like "Define the grammar for the [[Category:...]] statement". Do we
> have anything like that?

Well, the ideal is to get as much of the grammar as possible
formalized, not merely informally summarized.  Formalization should be
possible with some inspection and testing, but of course you have to
have a good understanding of formal grammars (I don't, for one, at
least not yet).  There are a number of wiki pages scattered around
Meta and MediaWiki.org containing attempts at formalizations, which of
course anyone can contribute to.

On 2/11/07, Steve Bennett <stevagewp at gmail.com> wrote:
> Just to check: Is changing MediaWiki sytnax absolutely out of the
> question?

Major changes are probably out of the question for the foreseeable
future, just because of the annoyance of transition, with months and
months of people using the wrong syntax and screwing up articles.
Tweaks to the behavior in corner cases are, of course, fine.


from_name: Matthew Brown

subject: [WikiEN-l] Admin burnout

body:
On 2/11/07, Ray Saintonge <saintonge at telus.net> wrote:
> The most desirable skill in an admin is patience, and we
> don't see much of that.

I suspect the patient admins don't make waves, or headlines.

-Matt


subject: [WikiEN-l] Admin burnout

body:
Keitei wrote:

>In order to become an admin, one must have an impeccable track record
>and have been aiming for adminship for quite some time. Then one must
>jump through all sorts of flaming hoops while all the people one gets
>along with the least gather to heckle. Then having become an admin,
>one gets treated like shit by newcomers pissed that one has deleted
>their page, trolls pissed that one has blocked them, POV pushers
>pissed that one has protected their page, users insistent that one is
>just the same as them and does not have any greater level of trust
>and should never be given any level of slack, users convinced that
>one is abusing one's powers, and "valued contributors" insistent that
>one does not matter and should go to hell because they do so much
>more and are so much more important to the encyclopedia.
>
Gee!  You make it sound so much like the real world. :-)

>And from my experience as an admin at other wikis, it's not the
>newbies or the vandals that get you down. It's the bitter resentment
>from invested users targeted at you over and over and over again. As
>if because the admins have such unspeakable power, they have to be
>abused to keep them down, so they won't take over in power-mad fits.
>It just gets to the point where one is like, "Fine! If you don't want
>me around so much, I'll leave. Have fun."
>
Absolutely.  Sometimes the best way to get your point across is to let
it go.  One of the big failings of democratic and quasi-democratic
systems is that they cannot reconcile the right of everyone to
participate in the decisions with the expenditure of time needed to be
fully and fairly involved in those decisions.  Participatory democracy
sounds good in theory, but it requires that those who participate have a
higher goal than winning debating points through persistence.

Ec


from_name: brion at pobox.com

subject: [Wikitech-l] MediaWiki automated test run failure 2007-02-12

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

This is MediaWiki version 1.10alpha (r19889).

Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...

  18 still FAILING test(s) :(
      * URL-encoding in URL functions (single parameter)  [Has never passed]
      * URL-encoding in URL functions (multiple parameters)  [Has never passed]
      * TODO: Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)  [Has never passed]
      * TODO: Link containing double-single-quotes '' (bug 4598)  [Has never passed]
      * TODO: message transform: <noinclude> in transcluded template (bug 4926)  [Has never passed]
      * TODO: message transform: <onlyinclude> in transcluded template (bug 4926)  [Has never passed]
      * BUG 1887, part 2: A <math> with a thumbnail- math enabled  [Has never passed]
      * TODO: HTML bullet list, unclosed tags (bug 5497)  [Has never passed]
      * TODO: HTML ordered list, unclosed tags (bug 5497)  [Has never passed]
      * TODO: HTML nested bullet list, open tags (bug 5497)  [Has never passed]
      * TODO: HTML nested ordered list, open tags (bug 5497)  [Has never passed]
      * TODO: Inline HTML vs wiki block nesting  [Has never passed]
      * TODO: Mixing markup for italics and bold  [Has never passed]
      * TODO: 5 quotes, code coverage +1 line  [Has never passed]
      * TODO: dt/dd/dl test  [Has never passed]
      * TODO: Images with the "|" character in the comment  [Has never passed]
      * TODO: Parents of subpages, two levels up, without trailing slash or name.  [Has never passed]
      * TODO: Parents of subpages, two levels up, with lots of extra trailing slashes.  [Has never passed]

Passed 493 of 511 tests (96.48%)... 18 tests failed!


from_name: Brianna Laugher

body:
I think it would make more sense to ask the user explicitly, "How
would you like to be informed if your files are nominated for
deletion?"
x Never inform me
x Inform me at my Commons talk page (default)
x Inform my at my talk page at another wiki, which is User:_ at
project _ (fill in the blanks)
x Inform me via email; I have verified my email in my Commons account.

that would be pretty cool actually.
since 'home wikis' can change as people's interests change. and I
think it is generally better to ask what you *mean* rather than what
you think will extract the answer you desire (unintended side effects
creep in...)

Anyway, unfortunately I have to agree with Platonides et al that we
should wait and see exactly what SUL brings. How the watchlist(s) will
work has not been made terribly clear, at least in anything I've seen.

cheers
Brianna

On 11/02/07, Florian Straub <flominator at gmx.net> wrote:
>  "Platonides" <Platonides at gmail.com> wrote on Saturday, February 10, 2007
> 4:31 PM:
>
> > bawolff wrote:
> >> Flo said:
> >>> My additional wish would be a way to contact one time contributers.
> >>> There
> >>> are several ways to achieve this:
> >>> * Creating a field "home wiki" on the resistration form.
> >> ...
> >>
> >> How hard could that be? Create a field in the log in page saying ''I
> >> ussually contribute to project x'', preferably this could be done
> >> semi-automatically via referrer headers or wikipedia linking with a
> >> url like
> >> http://common.wikimedia.org/wiki/special:userlogin?from=en.wikipedia
> >> . The thing gets automatically filled out, and the user can change it
> >> if he wants. Then when he creates an account, his user page has a
> >> template on it automatically that says, "so and so is usually at foo,
> >> leave a message both here and there". Then if orphanbot [or whatever
> >> you call your bots that send messages] comes a long, sees it, and
> >> leaves a message at both commons and the local wiki.
> >>
> > Easy, but it'd involve a change in db fields.
>
> Not necessary. We could create a link to a userpage that includes a
> template, the username and project the way we do it at the deletion requests
> ...
>
> Regards,
>
> Flo
>
>
> _______________________________________________
> Commons-l mailing list
> Commons-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/commons-l
>


subject: [WikiEN-l] Admin burnout

body:
geni wrote:

>On 2/9/07, James Forrester wrote:
>
>
>>Fully agreed. It seemed to work with many, including me (well, I'll
>>leave that judgement to the reader ;-)); the current system seems to
>>be negatively selecting against people who will "be bold" or "ignore
>>all rules", too, which suggests a slow corruption of our community's
>>spirit (note that I do not suggest that this is in any way
>>deliberate).
>>
>>
>Do you blame them? People have seen the amount of damage admins can do
>before being stopped. They know that if the admin is smart enough and
>not unlucky it is highly unlikely they will be stopped.
>
This approach requires one to assume bad faith

>So what is the rational response to this situation. To elect safe
>admins who you have a fairly good idea how they will act. That means
>electing admins who respect policy and don't like getting into fights.
>
The present situation, notably with its inquisitorial approach and
stress on certain kind of tasks, tends to favour admins who respect the
letter of policy, and who DO like to get into fights.  The kind of
people who do what they are told and join armies.

Ec


from_name: Stephen Bain

subject: [WikiEN-l] Sanger and CZ

body:
On 2/11/07, Tim Starling <tstarling at wikimedia.org> wrote:
>
> Put Citizendium in that list alongside a whole lot of sources that people
> have actually heard of? A list of "places which are often regarded as
> reliable"? I think that's giving them a bit more credit than they deserve.
>
> I'm inclined to think that even mentioning them on this list is giving
> them more credit than they deserve, but I'll be tolerant for now.

Well, some of them - or at least, Britannica - are groups that get
press for bragging about how much more reliable they are than
Wikipedia, while at the same time disclaiming their reliability to the
maximum extent permitted by law in similar language to our own
disclaimers.

Citizendium is not on the same scale, but its hubris is.

--
Stephen Bain
stephen.bain at gmail.com


body:
On 2/12/07, Brianna Laugher <brianna.laugher at gmail.com> wrote:
>
> Anyway, unfortunately I have to agree with Platonides et al that we
> should wait and see exactly what SUL brings. How the watchlist(s) will
> work has not been made terribly clear, at least in anything I've seen.

I don't know about watchlists, but I seem to remember reading that one
of the main features of SUL would be a unified "new messages" banner
to announce new messages on any project.

--
Stephen Bain
stephen.bain at gmail.com


from_name: rfrangi at libero.it

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

body:
< David Strauss wrote:

> Not only do I agree, but I believe a similar issue surrounds fair use.
> Accusations of U.S. centrism are indefensible when they're based on
> restrictive laws in non-U.S. countries.
>
> Now, that doesn't mean there aren't practical advantages to
> accommodating other countries' needs, but the lack of doing so is hardly
> "U.S. centrism."

You see, when we decided to accept images "used with permission" and or with the NC clause, it was done for the very same reasons on en.wiki copyrighted material is used claiming fair use. This is our workaround for not being able to claim fair use, in fact, you will notice that there are cases in which the same image appears on en.wiki with the fair use template and on it.wiki with the "used with permission" or NC template.

That's the reason why, when we are told we should remove those images, but on en.wiki fair use is just ok, people get pissed and obviously talks about U.S. centrism.

In this thread someone said that renounce to fair use would be  an intollerable limitation to the freedom of speech. The way we use NC and "used with permission" images is by any respect equivalent to the way you use copyrighted material claiming fair use.

So in the end having to phase out those images, for us, is an intollerable limitation to our freedom of speech.

Roberto (Snowdog)

------------------------------------------------------
Passa a Infostrada. ADSL e Telefono senza limiti e senza canone Telecom
http://click.libero.it/infostrada12feb07


from_name: Minh Nguyen

references:
<NABBJGECPILFNLFEAPIKCEEMKAAA.nickpj@gmail.com>	<45CFD8C9.2010300@swarthmore.edu>
	<45D02473.3010000@gmail.com>

body:
Gerard Meijssen wrote:
> Hoi,
> With the realisisation that this is also a problem that prevents
> Neapolitan from being written as it is standard practiced, the
> Neapolitan language uses '' in its language. The result of the MediaWiki
> practice of using the ' in bold and italic breaks functionality in the
> first place. Given that it is also a problem in the parser itself, maybe
> a good reason to ditch this abomination.
> Thanks,
>     GerardM

I was wondering... would it be possible for nap: users to enter
"smart-quotes", namely ’’ or ??? The advantage of this
character over ' is that you can represent it in plain text (no
HTML code), even in Category tags and page titles. It also looks nicer
if you have a good font. You could, of course, add ? to a <charinsert>
tag in [[MediaWiki:Edittools]] to make this character easier to insert.

--
Minh Nguyen <mxn at zoomtown.com>
[[en:User:Mxn]] [[vi:User:Mxn]] [[m:User:Mxn]]
AIM: trycom2000; Jabber: mxn at myjabber.net; Blog: http://mxn.f2o.org/


from_name: Piero

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

body:
Gregory Maxwell ha scritto:
> However, this does not appear to be the case on itwiki:
> http://it.wikipedia.org/wiki/Speciale:PuntanoQui/Template:Copyrighted
>
> Where very many of these images could have be recreated as free works
> by anyone.. many of them are even the works of wikipedians but they
> are not released as free content.
>
>

Ok, I think that we need to substitute all the "images with permission"
with "free content" images whenever it is possible, and I think we all
agree with it.
I believe that the problems are only for useful images that aren't
available with a free license (or that we can't create by ourselves,
there's a ton of that kinds of images even on it.wiki).

My doubt is: do we risk anything by uploading images with permission
that someone else on Wikipedia will tag as fair-use? I fear it won't be
legally acceptable (or at least who has given the permission will retire
it immediately) - I don't have an idea, since I'm not a lawyer.

piero tasso


from_name: David Strauss

body:
geni wrote:
> On 2/11/07, David Strauss <david at fourkitchens.com> wrote:
>> Not only do I agree, but I believe a similar issue surrounds fair use.
>> Accusations of U.S. centrism are indefensible when they're based on
>> restrictive laws in non-U.S. countries.
>>
>> Now, that doesn't mean there aren't practical advantages to
>> accommodating other countries' needs, but the lack of doing so is hardly
>> "U.S. centrism."
>
> The problem with that is the logical end point of that position is the
> move the foundation and servers to Iran.

That's absurd. How does one go from "not changing to accommodate
restrictive laws from other countries is not U.S. centrism" to "we must
move our servers to Iran"?

I'm arguing that we should weigh the advantages of accommodating foreign
restrictions (further reach) with the disadvantages of changing the
content (esp. censorship). If we happen to decide that accommodating a
restriction isn't worth the changes to content, then we're still not
guilty of U.S. centrism. Accommodating Iran's requirements is clearly
out of the question.

U.S. centrism is borne of ignorance or willful exclusion. Neither is the
case here.


from_name: Jeff Raymond

subject: [WikiEN-l] Admin burnout

body:
Ray Saintonge wrote:
> Guy Chapman aka JzG wrote:
>
>> Ultimately the only way to fix this is probably to be more willing to
>>
>> chuck out people who resolutely refuse to follow policy.

Do you know exactly how many admins that would encompass?

-Jeff

--
Name: Jeff Raymond
E-mail: jeff.raymond at internationalhouseofbacon.com
WWW: http://www.internationalhouseofbacon.com
IM: badlydrawnjeff
Quote: "As the hobbits are going up Mount Doom, the
	Eye of Mordor is being drawn somewhere else."
	- Sen. Rick Santorum on the war in Iraq.


from_name: Rich Holton

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

body:
geni wrote:
> On 2/12/07, Marc Riddell <michaeldavid86 at comcast.net> wrote:
>> on 2/12/07 6:19 AM, Cool Cat at wikipedia.kawaii.neko at gmail.com wrote:
>>
>>> Perhaps a wikiproject regulating categories might not be a bad idea.
>> Sounds like a great idea. I'd be one of the first in line to sign on.
>>
>> Marc Riddell
>>
>
> When trying to sort out our images and their copyright status I would
> rather not have to submit every category I find myself needed to a
> bunch of self appointed busy bodies who are unlikely to know much more
> about copyright than the average wikipedian.
>
> The stubs wikiproject works because the vast majority of people who
> are interested in new stubs and stub sorting are part of the project.
> That would not be the case with a categories wikiproject.
>
>

Do you know, Geni, that sometimes you project a fairly abrasive attitude?

-Rich


from_name: Marc Riddell

subject: [WikiEN-l] Admin burnout

body:
on 2/12/07 8:03 AM, charles.r.matthews at ntlworld.com at
charles.r.matthews at ntlworld.com wrote:

> It's kind of fascinating how these discussions go, off into blue sky
> meandering and frank ranting. An admin leaves (which is regrettable, but I
> hope Alkivar will come back some day). And you get a whole washing line full
> of people's pet beefs attached to the notion. Anecdotal evidence proves little
> enough, in the first place.

Yes, it is fascinating (and telling) how quickly the conversation moves from
the human to the technical.

Marc Riddell


from_name: Erik Moeller

subject: [Foundation-l] Fwd: Share-Alike with images

body:
On 2/11/07, Delirium <delirium at hackish.org> wrote:
> This would be problematic for our own uses unless the CC-BY-SA / GFDL
> compatibility issues are resolved.  The wording of the cc-by-sa requires
> any derivative works to be distributed "only under a license identical
> to this one"

The license could make a distinction between works which are direct
derivatives, and separate works which are used in a way where one
semantically depends on the other. In the second case, it could allow
them to be under separate licenses, as long as all component licenses
are free content licenses.
--
Peace & Love,
Erik

DISCLAIMER: This message does not represent an official position of
the Wikimedia Foundation or its Board of Trustees.


body:
geni wrote:
> On 2/12/07, David Strauss <david at fourkitchens.com> wrote:
>> That's absurd. How does one go from "not changing to accommodate
>> restrictive laws from other countries is not U.S. centrism" to "we must
>> move our servers to Iran"?
>>
>
> You want minimum restrictions with regard to copyright that is the
> correct course of action.
>
>> I'm arguing that we should weigh the advantages of accommodating foreign
>> restrictions
>
> Try again this time try not to think so americano centric
>
>> (further reach) with the disadvantages of changing the
>> content (esp. censorship). If we happen to decide that accommodating a
>> restriction isn't worth the changes to content, then we're still not
>> guilty of U.S. centrism. Accommodating Iran's requirements is clearly
>> out of the question.
>>
>
> So not copyright on items produced outside Iran doesn't appeal? Well
> Ok then how about move commons to the UK? At least one type of item
> enters the public domain there well before ti does in the US. Sure it
> might be a good idea to win a Bridgeman Art Library v. Corel Corp case
> first but that should be doable.
>
>
>> U.S. centrism is borne of ignorance or willful exclusion. Neither is the
>> case here.
>
> Then try and think why when dealing with the option of moving the
> foundation to somewhere with the most liberal copyright laws on an
> international mailing list why using the term "foreign restrictions"
> isn't exactly ideal phrasing.

There's simply no way I can discuss this issue with you unless you're
willing to adopt a more holistic consideration of Wikipedia's needs.
Your arguments are trapped in the consideration of the *one* idea you
seem to support, which is restricting Wikipedia content to what may be
republished in *your* country.

Nowhere in my post did I mention copyright, yet you framed my argument
as if copyright were its only consideration. You straw-manned my
argument by ignoring aspects of the balance I proposed -- most notably
ignoring censorship -- that didn't fit nearly within your pet issue.

Finally, you invoked a false slippery slope by stating my argument leads
to hosting Wikipedia in Iran. Only your imaginary, straw-manned version
of my argument has that flaw.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/foundation-l/attachments/20070212/1381f833/attachment.pgp


body:
geni wrote:
> On 2/12/07, David Strauss <david at fourkitchens.com> wrote:
>> That's absurd. How does one go from "not changing to accommodate
>> restrictive laws from other countries is not U.S. centrism" to "we must
>> move our servers to Iran"?
>>
>
> You want minimum restrictions with regard to copyright that is the
> correct course of action.
>
>> I'm arguing that we should weigh the advantages of accommodating foreign
>> restrictions
>
> Try again this time try not to think so americano centric
>
>> (further reach) with the disadvantages of changing the
>> content (esp. censorship). If we happen to decide that accommodating a
>> restriction isn't worth the changes to content, then we're still not
>> guilty of U.S. centrism. Accommodating Iran's requirements is clearly
>> out of the question.
>>
>
> So not copyright on items produced outside Iran doesn't appeal? Well
> Ok then how about move commons to the UK? At least one type of item
> enters the public domain there well before ti does in the US. Sure it
> might be a good idea to win a Bridgeman Art Library v. Corel Corp case
> first but that should be doable.
>
>
>> U.S. centrism is borne of ignorance or willful exclusion. Neither is the
>> case here.
>
> Then try and think why when dealing with the option of moving the
> foundation to somewhere with the most liberal copyright laws on an
> international mailing list why using the term "foreign restrictions"
> isn't exactly ideal phrasing.

There's simply no way I can discuss this issue with you unless you're
willing to adopt a more holistic consideration of Wikipedia's needs.
Your arguments are trapped in the consideration of the *one* idea you
seem to support, which is restricting Wikipedia content to what may be
republished in *your* country.

Nowhere in my post did I mention copyright, yet you framed my argument
as if copyright were its only consideration. You straw-manned my
argument by ignoring aspects of the balance I proposed -- most notably
ignoring censorship -- that didn't fit nearly within your pet issue.

Finally, you invoked a false slippery slope by stating my argument leads
to hosting Wikipedia in Iran. Only your imaginary, straw-manned version
of my argument has that flaw.

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


body:
geni wrote:
> On 2/12/07, David Strauss <david at fourkitchens.com> wrote:
>> That's absurd. How does one go from "not changing to accommodate
>> restrictive laws from other countries is not U.S. centrism" to "we must
>> move our servers to Iran"?
>>
>
> You want minimum restrictions with regard to copyright that is the
> correct course of action.
>
>> I'm arguing that we should weigh the advantages of accommodating foreign
>> restrictions
>
> Try again this time try not to think so americano centric
>
>> (further reach) with the disadvantages of changing the
>> content (esp. censorship). If we happen to decide that accommodating a
>> restriction isn't worth the changes to content, then we're still not
>> guilty of U.S. centrism. Accommodating Iran's requirements is clearly
>> out of the question.
>>
>
> So not copyright on items produced outside Iran doesn't appeal? Well
> Ok then how about move commons to the UK? At least one type of item
> enters the public domain there well before ti does in the US. Sure it
> might be a good idea to win a Bridgeman Art Library v. Corel Corp case
> first but that should be doable.
>
>
>> U.S. centrism is borne of ignorance or willful exclusion. Neither is the
>> case here.
>
> Then try and think why when dealing with the option of moving the
> foundation to somewhere with the most liberal copyright laws on an
> international mailing list why using the term "foreign restrictions"
> isn't exactly ideal phrasing.

There's simply no way I can discuss this issue with you unless you're
willing to adopt a more holistic consideration of Wikipedia's needs.
Your arguments are trapped in the consideration of the *one* idea you
seem to support, which is restricting Wikipedia content to what may be
republished in *your* country.

Nowhere in my post did I mention copyright, yet you framed my argument
as if copyright were its only consideration. You straw-manned my
argument by ignoring aspects of the balance I proposed -- most notably
ignoring censorship -- that didn't fit nearly within your pet issue.

Finally, you invoked a false slippery slope by stating my argument leads
to hosting Wikipedia in Iran. Only your imaginary, straw-manned version
of my argument has that flaw.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikimedia-l/attachments/20070212/1381f833/attachment-0001.pgp>


from_name: Eric Astor

subject: [Wikitech-l] WYSIWYG (or WYSIWYM or WYSIWYM) status?

body:
Jared Williams wrote:
>> Just one example - probably of the 5% very hard category:
>>
>> '''''hello''' hi''
>> vs.
>> '''''hi'' hello'''
>>
>> Rendered in HTML, the first reads hello hi, and
>> the second
>> reads hi hello. The problem is that the meaning of the
>> first 5 quotes changes based on the order in which the bold
>> and italic
>> regions close - which is not determined while scanning left-to-right.
>>
>> Another example:
>>
>> '''hello ''hi''' there''
>>
>> MediaWiki renders this as hello hi
>> there, properly
>> handling overlapping formatting.
>>
>> There are ways to deal with these... putting off the
>> resolution until a
>> later pass is the only way I know of that deals with the
>> first one, and
>> it's a bit touchy. Manageable, but touchy.
>
> Think the easiest method (and nearer to be able to keep as it a single pass)
> is to use DOM. Guarentees valid XML output always, which I believe the
> MediaWiki parser doesn't always do.
>
> Also can easly going back and fixing up the DOM tree, if the parser has made
> an initial wrong choice. Like
>
> '''italics''
>
> It might start out as italics, but seeing '' its can be corrected to
> 'italics.
>
> Jared

Keeping an abstract tree as an intermediate representation helps, but
does not fix, this problem. Dealing with things like '''italics'' is
non-trivial in any case, as if we're going to retain this behavior, no
context-free grammar (at least with fixed lookahead) can possibly suffice.

Whatever happens to handle this, it will have to be at a separate stage
from the original parsing. What remains is a question of how many extra
stages we will need.

- Eric


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

body:
To any & all,

I am doing some thinking about how the WP Community could help Admins who
are struggling with the work. My goal is to come up with a formal mechanism
that these Admins can turn to for help and support before they choose to
simply give up and leave the Community. It could serve as a form of
intervention before a burnout occurs.

What are your thoughts about this?

Marc Riddell


body:
Lars Aronsson wrote:
> Steve Bennett wrote:
>
>> Just to check: Is changing MediaWiki sytnax absolutely out of the
>> question? Using // and ** for italic and bold respectively would solve
>> that problem, be more consistent and more intuitive, and probably not
>> be excessively difficult to phase in, right?
>
> Many would say that any such discussion is a dead end.  However, I
> think that is a bit narrow-minded.  A syntax change on Wikipedia
> might not be very likely, but you can of course change MediaWiki
> for use on your own wiki website.
>
> Changing to // and ** doesn't necessarily make the wiki syntax any
> more BNF parsable than today, does it?  You can still write *****
> and what's that supposed to mean?  If clarity is wanted, the best
> would probably be <i> and <b>.

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

Oh - and ***** would most likely be disambiguated to <b>*</b>. Easy to
handle in a CFG with lookahead, and almost certainly what the user meant.

> The current wiki syntax cannot be described in simple BNF, but it
> is not impossible to parse.  The MediaWiki engine successfully
> converts it to HTML and, in the reverse direction, users who
> intend to accomplish a result in bold and italics are able to
> convert this intension into wiki syntax.

Slight disagreement on terms: The current syntax is convertible to HTML
- it is not parseable. At the least, it is not currently parsed... No
internal representation is generated, and the system just makes
something on the close order of 50 regex passes per page to convert it
into HTML.

> Thus, it is also possible to write a program that converts the
> current Wikipedia dump into using <i> and <b> rather than
> apostrophes, and then back again to traditional wiki syntax.
> Since <i> and <b> are already supported, you could make it a
> policy on your own wiki whether apostrophes should be deprecated.
> To enforce such a policy, every stored article can be converted.
> Such a policy is not very likely on Wikipedia, though.

Possible - though difficult. I'd actually welcome someone creating a
program to convert MediaWiki's syntax from apostrophes to <i> and <b>,
as that could technically provide a more formal specification of how the
MediaWiki parser handles apostrophes. However, at the moment, the only
such program we have is MediaWiki itself.

- Eric


from_name: Phil Boswell

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

body:
David Goodman wrote:
>
> This discussion has forgotten about one of the traditional media that
> work very well with computer based systems: drawing. A public figure
> can try to prevent himself from being photographed except under terms
> he dictates, but he can not (at least in the US) prevent  an artist
> from drawing or painting him based on whatever images are available,
> in any way the artist may please, fair or unfair, characteristic or
> satyrical, and publishing it as desired--as long as it is not an
> actual reproduction of the original.
>
This worked a treat on our article for the author Jim Butcher. I posted a
request for an image on his fan forum and the favourite image turned out to
be this:
http://en.wikipedia.org/wiki/Image:JimButcher_sepia.jpg

Surely any author with even a modest fan-base can manage this ;-)

HTH HAND
--
Phil
--
View this message in context: http://www.nabble.com/-Wikipedia-l--precisions-about-the-recent-WMF-%22fair-use%22-decision-tf3196431.html#a8927818
Sent from the Wikipedia General mailing list archive at Nabble.com.


body:
on 2/12/07 6:19 AM, Cool Cat at wikipedia.kawaii.neko at gmail.com wrote:

> Perhaps a wikiproject regulating categories might not be a bad idea.

Sounds like a great idea. I'd be one of the first in line to sign on.

Marc Riddell

--
If you're restricted to what is - you are cut off from - - what could be.


from_name: Andrew Whitworth

body:
>I don't think that the issue of external links on Wikibooks or any other
>Wikimedia project really has to do much with wheither the link is "for
>profit" or not.  The main issue is if the link has any relevance to the
>material that it is related to.  A Wikipedia article (or even a how-to
>repair manual on Wikibooks) about the Ford Motor Company certainly can
>have a link to the official corporate website... and be considered a
>high quality link.
>
>In the case of the UN APDIP books, a link to the original PDF files is
>certainly relevant as it is the original source material, and you are
>maintaining academic integrety by noting the original source of the
>text.  In a similar vein, if this offer to have the book on Wikibooks
>were to happen or even if it were just used as source material to create
>a very different book, its use as a bilbliographic reference certainly
>is very justified.
>
>The problem with link spamming is that 300 links for Viagra on a page
>about Quantum Mechanics is completely irrelvant to the topic under
>discussion.  A sexual health Wikibook, on the other hand.....

I've said for a long time that many links are necessary as bibliographic,
reference, and further reading information in a textbook. There is a camp of
people who believe that there should be no external links in books
whatsoever, as books are supposed to be "self-contained" resources
themselves. I think that the "self-contained" metric is simply an alternate
way of stating that a textbook is not supposed to link frequently to
wikipedia, but instead should maintain it's own narrative. This is, however,
neither here nor there.

Because external links are often required in textbooks (or, barring
requirement, that they are helpful), it has traditionally be left up to the
judgement of the page patroller as to whether or not a link is considered
"bibliographical/legitimate reference" or "spam". A potential metric to be
used in making such a determination is to ask whether the link in question
represents advocacy (and therefore violates NPOV), and also whether or not
the link provides financial gain to the target at the expense of Wikibooks.
My point above is that proper bibliographic and academic links rarely fail
these tests, and won't be deleted as spam.

--Andrew Whitworth

_________________________________________________________________
Turn searches into helpful donations. Make your search count.
http://click4thecause.live.com/search/charity/default.aspx?source=hmemtagline_donation&FORM=WLMTAG


from_name: Alex Powell

subject: [Wikitech-l] Page protection

body:
Hi,

I noticed the SVN tables.sql now has a permissions table. Dare I dream that
per page permissioning is on the way? Is the ethos of the wikipedia
changing, or has some money been thrown into the development? Is it likely
to be in 1.10, or a few versions away?

Best regards,

Alex


from_name: Magnus Manske

body:
> Nick Jenkins wrote:
> > Can I maybe suggest please giving some examples that you encountered of
> > the 10-15% hard category, and the 5% very hard category?

To really give you the creeps,

12''34''5

is rendered as

12345

which is just wrong, and IMHO /should/ be rendered as

12345

But don't worry, my wiki2xml tool doesn't do it correctly either,
though it does generate valid XML without tidyhtml...

Magnus


from_name: Gerard Meijssen

body:
Hoi,
With the realisisation that this is also a problem that prevents
Neapolitan from being written as it is standard practiced, the
Neapolitan language uses '' in its language. The result of the MediaWiki
practice of using the ' in bold and italic breaks functionality in the
first place. Given that it is also a problem in the parser itself, maybe
a good reason to ditch this abomination.
Thanks,
    GerardM

Eric Astor schreef:
> Nick Jenkins wrote:
>
>>> As one of the many people who's done so, I agree. :)  The problem is
>>> that ~80% of wikimarkup is pretty straightforward to parse using
>>> standard methods, another 10-15% can be done without huge difficulty
>>> using known-but-less-standard methods, and the remaining 5% doesn't fit
>>> well at all into any of the normal models of lexing/parsing.
>>>
>>> [...snip...]
>>>
>>> -Mark
>>>
>> Can I maybe suggest please giving some examples that you encountered of
>> the 10-15% hard category, and the 5% very hard category?
>>
>> I ask so that if anyone feels tempted to start on defining the behaviour,
>> we can gently suggest doing the harder stuff *first* (with examples),
>> thus hopefully preventing the situation where we have multiple unfinished
>> 80%-done definitions, and no 100%-complete formal definitions.
>>
>> All the best,
>> Nick.
>>
>
> Just one example - probably of the 5% very hard category:
>
> '''''hello''' hi''
> vs.
> '''''hi'' hello'''
>
> Rendered in HTML, the first reads hello hi, and the second
> reads hi hello. The problem is that the meaning of the
> first 5 quotes changes based on the order in which the bold and italic
> regions close - which is not determined while scanning left-to-right.
>
> Another example:
>
> '''hello ''hi''' there''
>
> MediaWiki renders this as hello hi there, properly
> handling overlapping formatting.
>
> There are ways to deal with these... putting off the resolution until a
> later pass is the only way I know of that deals with the first one, and
> it's a bit touchy. Manageable, but touchy.
>
> If I have time this summer, I'm going to look at formalizing a parser
> again... see if I can make a start on hammering out a somewhat more
> formal structure for handling some of the tougher cases, after I've
> tackled OLPC's CrossMark.
>
> - Eric Astor
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>


from_name: Rob Church

subject: [Wikitech-l] Page protection

body:
On 12/02/07, Alex Powell <alexp at exscien.com> wrote:
> I noticed the SVN tables.sql now has a permissions table. Dare I dream that
> per page permissioning is on the way? Is the ethos of the wikipedia
> changing, or has some money been thrown into the development? Is it likely
> to be in 1.10, or a few versions away?

No, we've just split off page editing permissions (for protection)
into a new table, and introduced a few columns in advance, to
facilitate future features such as expiring protection. This was done
at the same time as cascading protection was introduced.

I am not aware of plans to introduce per-page access permissions to
the software beyond anything we already have, at this time. MediaWiki
is a wiki engine, not a content management system.

Rob Church


from_name: Michael Lite

subject: [Wikitech-l] php / mediawiki developer position

body:
PHP Web Developer

To apply please visit Requisition # 13341 at www.battelle.org/careers

Battelle is a world leader in science and technology research. The
Information Technology Solutions (ITS) Product Line specializes in
developing advanced IT solutions for our government and commercial clients.
ITS is seeking a PHP Web Developer to develop web applications for our IC
client. Compensation will be based on qualifications and experience. A full
benefits package will be provided. The selected candidate will work out of
Battelle's office in Charlottesville, Virginia.

Position Responsibilities:
- Work independently and as a member of a multi-functional team to develop
and/or modify MediaWiki source, develop custom MediaWiki extensions, and
manage custom MediaWiki deployments
- Interact daily with non-technical analysts to resolve requests for
customizations, re-scoped requirements, and/or bugfixes
- Prepare and conduct regular progress briefings extemporaneously and in
formal settings to internal and external clients
- Troubleshoot periodic production baseline issues during regular business
hours
- Interact with open-source wiki community to stay abreast of latest wiki
technology

Required Qualifications:
- US Citizen with eligibility for Department of Defense Security Clearance
- B.S. degree in Computer Science, Engineering, Mathematics or related
field.
- 2+ years experience in developing dynamically generated web applications
- Programming experience with XML, XSLT, JavaScript, PHP, and SQL
- Understanding of source code control and software development
methodologies
- Programming experience in both Windows and UNIX environments
- Strong verbal and written communication skills

Preferred Qualifications:
- Familiarity with the MediaWiki Wiki implementation
- Familiarity with the Windows IIS web server
- Understanding of web security and web project management practices
- Previous experience supporting a production environment

Affirmative Action/ Equal Opportunity Employer M/F/D/V

To apply please visit Requisition # 13341 at www.battelle.org/careers


from_name: Brion Vibber

subject: [Wikitech-l] Page protection

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

Alex Powell wrote:
> I noticed the SVN tables.sql now has a permissions table. Dare I dream that
> per page permissioning is on the way? Is the ethos of the wikipedia
> changing, or has some money been thrown into the development? Is it likely
> to be in 1.10, or a few versions away?

We have always had per-page permissions; they have simply been branched
to another table to allow for more flexible manipulations and interactions.

Keep in mind that there is no support for per-page *read* permissions,
though, and none is planned.

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

iD8DBQFF0KobwRnhpk1wk44RAvoUAJ4os3NkSEKuBkJ1DUG3w3BOOYzoEwCeLTYB
cLBlINv/9oz3rRiPck+s2mE=
=pX8D
-----END PGP SIGNATURE-----


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

body:
Alphax (Wikipedia email) schreef:
> geni wrote:
>
>> On 2/11/07, David Strauss <david at fourkitchens.com> wrote:
>>
>>> Not only do I agree, but I believe a similar issue surrounds fair use.
>>> Accusations of U.S. centrism are indefensible when they're based on
>>> restrictive laws in non-U.S. countries.
>>>
>>> Now, that doesn't mean there aren't practical advantages to
>>> accommodating other countries' needs, but the lack of doing so is hardly
>>> "U.S. centrism."
>>>
>>>
>> The problem with that is the logical end point of that position is the
>> move the foundation and servers to Iran.
>>
>>
>
> We'd have to remove all the images of people.
Hoi,
To me, this sounds like a complete absurd assertion.. what do you base
THAT on ?
Thanks,
    GerardM


from_name: Bryan Derksen

subject: [WikiEN-l] Admin burnout

references:
<38a7bf7c0702081829u62f0261ai77cd02368817e402@mail.gmail.com>
	<btaos2tg8da5r1u714qe6vdd763pp3jmfu@4ax.com>
	<45D013B9.9040309@telus.net>
	<45D05A37.6060901@internationalhouseofbacon.com>
	<0hn0t29lg4hi35jev809q7hoqdaro8v3cb@4ax.com>

body:
Guy Chapman aka JzG wrote:
> Others who should have been promoted but were not for ridiculous
> reasons include Stephen B Streater and Georgewilliamherbert.

I should add Serpent's Choice to that list. I don't know why his RfA
failed, I missed it entirely, but he's been going wonderful work
rescuing the most unlikely articles from deletion by making such massive
improvements to them that delete votes get retracted in droves. I'm sure
he'd rescue even more that way if he could see deleted article histories.


from_name: Lars Aronsson

body:
Steve Bennett wrote:

> Just to check: Is changing MediaWiki sytnax absolutely out of the
> question? Using // and ** for italic and bold respectively would solve
> that problem, be more consistent and more intuitive, and probably not
> be excessively difficult to phase in, right?

Many would say that any such discussion is a dead end.  However, I
think that is a bit narrow-minded.  A syntax change on Wikipedia
might not be very likely, but you can of course change MediaWiki
for use on your own wiki website.

Changing to // and ** doesn't necessarily make the wiki syntax any
more BNF parsable than today, does it?  You can still write *****
and what's that supposed to mean?  If clarity is wanted, the best
would probably be <i> and <b>.

The current wiki syntax cannot be described in simple BNF, but it
is not impossible to parse.  The MediaWiki engine successfully
converts it to HTML and, in the reverse direction, users who
intend to accomplish a result in bold and italics are able to
convert this intension into wiki syntax.

Thus, it is also possible to write a program that converts the
current Wikipedia dump into using <i> and <b> rather than
apostrophes, and then back again to traditional wiki syntax.
Since <i> and <b> are already supported, you could make it a
policy on your own wiki whether apostrophes should be deprecated.
To enforce such a policy, every stored article can be converted.
Such a policy is not very likely on Wikipedia, though.

What you can do is to run some experiments on the existing dump.
How many cases are there where ''''' is hard to resolve?  Did
anybody count?

It is of course possible to write articles with unbalanced
apostrophes.  If I write '''hey'' it will render as '<i>hey</i>,
and that's also how a conversion program should leave it. How many
such user mistakes are there in the current dump? Perhaps somebody
is already running a robot to find and fix such errors?

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