from_name: Anthony

subject: [Foundation-l] Celebrity pictures

body:
On 8/29/06, Ray Saintonge <saintonge at telus.net> wrote:
> Anthony wrote:
> >On 8/28/06, Ray Saintonge <saintonge at telus.net> wrote:
> >>Perhaps more significant than whether anyone has lost is whether any
> >>such case has ever been filed.  Given that they are distributed for the
> >>specific purpose of publicity there could be an implicit permission.
> >>
> >>
> >If you're using the image for the purposes of promoting the person.
> >If, on the other hand, you're using the image to sell an encyclopedia
> >article which portrays the person in a way which they don't want to be
> >portrayed, then there probably isn't implicit permission.
> >
> I don't know if it's to "sell" an encyclopedia.  Lindsay Lohan would
> need to think she's pretty special if she believes a picture of her will
> make all the difference in encyclopedia sales.  Is she as self-absorbed
> as Paris Hilton?  Our use is transformative, and it in no way adversely
> affects the company's sales..  It would even be interesting to hear the
> companies comment on the function of publicity shots.
>
I was talking about reuse.  Specifically, someone who was selling
print encyclopedias with the current Lindsay Lohan article in it.  I
didn't mean to imply that the selling point was the picture, but
merely that the encyclopedia was being sold.

> >Maybe I'm overly paranoid, but even here in the US where we have some
> >very strong fair use and first amendment rights, I still wouldn't feel
> >comfortable selling an encyclopedia with the current [[Lindsay Lohan]]
> >article in it, without first receiving permission from the copyright
> >holders of the images.
> >(http://en.wikipedia.org/w/index.php?title=Lindsay_Lohan&oldid=72480012
> >in case it changes before this is read)
> >
> This may be a problem for the print version, and specific permissions
> should probably be sought when we get that far.  For the on-line
> verrsion however I have no problem with an active campaign to replace
> the fair use images with "free" ones.  It's clear that I'm more risk
> tolerant than you, but that doesn't mean there's such a wide gap between
> our views.
>
I don't think it makes sense to have such significant differences
between the print version and the online version.  Other than that, I
agree with you though.  I wouldn't have a problem distributing the
current article online.  In fact, I have a website where I'm doing it.

Jimbo has stated, long in the past, that he doesn't want the print
version to be a fork of the online version.  Maybe he's changed his
mind, but if not I think you have to consider the print and online
versions to be the same thing.

> >Frankly I think that case could be probably be won by the museum on
> >appeal, if they spent enough money fighting it.
> >
> Yeah, Dillinger has been dead since 1934.
>
In Indiana the right to publicity persists after death, though.

> >Besides, there are
> >always going to be crazy jurisdictions (like Indiana, apparently) with
> >laws so out of touch with reasonableness that we just can't follow
> >them.
> >
> Developing policies to account for such extremes is playing to the
> lleast common denominator.
>
Absolutely.  I agree.  But at the same time, US fair use is an extreme
too, just on the other end of the spectrum.

> >As for relying on the copyright holder of the image finding the
> >Wikipedia article "respectful", well, I just think that's a horrible
> >thing for us to even have to consider.  Would Linsay Lohan (*) object
> >to our portrayal of her in "Media spotlight"?  I don't know, and I
> >don't care.
> >
> There's also the question of who owns the copyright.  I suspect it's the
> studio who sends out fan pics to admirers.
>
I would think, with a publicity photo, that it'd be the publicist.

Anthony


list: wikimedia-l

source: pipermail-mbox

subject: [Foundation-l] Celebrity pictures


list: wikien-l

from_name: Gordon Joly

subject: [WikiEN-l] on new article creation

body:
At 20:14 -0400 28/8/06, Anthony wrote:
>On 8/28/06, Steve Bennett <stevagewp at gmail.com> wrote:
>>  On 8/28/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>>  > Wikipedia won't be finished in a day...and some times we need to just
>>  > try things out if we are to find good solutions.
>>
>>  Yep. My heart is not bleeding that anons couldn't make their usual
>>  truckload of crappy articles.
>>
>So are a truckload of crappy articles no longer being made, or do you
>think you can identify the people who are making them?
>
>Anthony

I have found two articles that needed attention within the past few
days. I probably came to Wikipedia via a Google.com search. In other
words, I did not start in Wikipedia.

// pauses to reflect

In one case, an obituary from "The Times" had been posted verbatim
when the person in question had died in March 2006. By August 2006,
the full copyright text was still there, so I removed it and created
a biographical entry. I then bought the book that this person had
written, and started to add references (the book and its ISBN etc)
and other information, and linked to the Times article as an external
link.

In the second case, the person is still living I believe. He was born
in 1941, and is household name in the East End of London (UK). I
added a couple of redirects and will probably "wikify" the article
next time around. It has these: {{tone}}, {{references}} and
{{wikify-date|August 2006}}...

I have often stopped from creating an article for a living person,
and I note that there is now clear policy on this, which I welcome.

http://en.wikipedia.org/wiki/Wikipedia:Biographies_of_living_persons

http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Biography

When I started being editing, and I am a late comer (January 2004),
there was no clear policy (or I was unaware of it).

Gordo

--
"Think Feynman"/////////
http://pobox.com/~gordo/
gordon.joly at pobox.com///


from_name: David Gerard

subject: [WikiEN-l] Well darn, Pokemon is important after all.

body:
Or popular with the readers, at least.

http://tools.wikimedia.de/~leon/stats/wikicharts/index.php?ns=articles&limit=100&month=08%2F2006&wiki=enwiki

Interesting to-do list task: see what subjects or subject areas are in
demand from that list, and make a list of related subjects in the area
that aren't covered or could do with serious work.

- d.


list: wikitech-l

from_name: Ligulem

subject: [Wikitech-l] Cite.php footnote problems on en.wikipedia.org

body:
Error reports about <ref> footnotes on en are piling at
http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29

Example bad page:
http://en.wikipedia.org/wiki/List_of_misnamed_theorems

Anybody knows something? Is somebody twiddling with Cite.php?


from_name: Death Phoenix

subject: [WikiEN-l] OT gmail spam increase?

body:
On 8/28/06, Matt Brown <morven at gmail.com> wrote:
>
> On 8/28/06, David Gerard <dgerard at gmail.com> wrote:
> > A lot of that is masses of text to clog spam filters that work on word
> > frequency, with the actual content in an image at the end.
>
> The good thing, though, is that the more spammers try to mask what
> they're pushing,
>
> a) The spam becomes easier to distinguish by human eye, and
> b) The spam becomes less effective, since it's a much poorer
> advertisement.
>

Very true. It's very easy to ignore an email with a horribly-misspelled
subject title with one of several thousand ways of describing Viagara or
erection.

(I wonder if this email will pass the spam filters?)


list: wikipedia-l

from_name: [LiM] Manop

subject: [Wikipedia-l] Cannot access Thai Wikipedia from Thailand

body:
Hello,

I'm wondering if anyone have the same problem. Several of my friends in
Thailand cannot access to Thai Wikipedia (http://th.wikipedia.org) today
since 4-5 hours ago. But I access from the USA, it works fine for me.

Best regards,
Manop - Thai Wikipedia


from_name: Andrew Gray

body:
On 29/08/06, Sigvat Stensholt <sigvats at mi.uib.no> wrote:
> David Gerard wrote:
>
> >>Or popular with the readers, at least.
>
> >>http://tools.wikimedia.de/~leon/stats/wikicharts/index.php?ns=articles&limit=100&month=08%2F2006&wiki=enwiki
>
> >>Interesting to-do list task: see what subjects or subject areas are in
> >>demand from that list, and make a list of related subjects in the area
> >>that aren't covered or could do with serious work.
>
>
> >>- d.
>
> Interesting. I am surprised that "Irukandji jellyfish" came so high up on the
> list... is there some anomoly here?

Jellyfish wasn't on the list at all last night; the statistics are
sampling (I think) one in five thousand pageviews, so it's quite
likely a glitch. They've only been running for a couple of days, and
I'd strongly advise against treating them as reliable until at least a
fortnight in.

That said... JonBenet Ramsay is interesting - it surged last night and
with no link from the front page. Interesting to see how quickly our
use (apparently) reacts to news stories. The sex-related ones - lists
of porn stars etc - were consistently high and are now dropping; I
wonder where they'll stabilise at.

(It could just be they're more popular at weekends...)

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


list: foundation-l

from_name: Daniel Bregman

subject: [Foundation-l] WMF Approval of New Languages/Projects

body:
Over at Incubator we've been deciding our policy with regard to
starting new language (of an existing project) tests, and new project
tests.
We've come up with this:

   - New languages can create a test on Incubator quite easily, needing
   only to get a few people who will help. (
   http://incubator.wikimedia.org/wiki/I:NTR)
   - New
   languages can create a full wiki using an approval process on
Incubator, and it will be made (or not) after consensus
   has been reached. (http://incubator.wikimedia.org/wiki/I:NLR)
   - New projects will need approval from the foundation to have a test
   made, and then need further approval to make a full wiki.

Is this acceptable? We are also not sure about what exactly the Foundation
needs to approve. Views we got previously seemed to be slightly
contradictory on this matter.

Thank you for your replies,

Dbmag9 (http://incubator.wikimedia.org/wiki/User:Dbmag9)

   -


from_name: Mark Ryan

subject: [WikiEN-l] OT gmail spam increase?

body:
I get precisely 45 spam messages a day, but Gmail catches almost all of them.

~Mark Ryan


from_name: Guettarda

body:
On 8/29/06, geni <geniice at gmail.com> wrote:
>
> On 8/29/06, Steve Bennett <stevagewp at gmail.com> wrote:
> > However, I can't see why Irukandji jelly fish would be so high. It's
> > not linked from anything, it's not in the news, and it's not even
> > jellyfish season in Queensland. It could just be a statistical
> > anomaly, or perhaps someone is deliberately messing with the stats?
>
> Might be on various school national caricular.

I'm sure it's place is cemented now that everyone who reads the mailing list
has clicked on it ;)


body:
At 10:03 +0100 29/8/06, David Gerard wrote:
>Or popular with the readers, at least.
>
>http://tools.wikimedia.de/~leon/stats/wikicharts/index.php?ns=articles&limit=100&month=08%2F2006&wiki=enwiki
>
>Interesting to-do list task: see what subjects or subject areas are in
>demand from that list, and make a list of related subjects in the area
>that aren't covered or could do with serious work.
>
>- d.

1563666 ? 18%  3.9924% 	1. Main Page
64666 ? 91%	0.1651%	2. JonBen?t Ramsey
63666 ? 92%	0.1626%	3. United States
50333 ? 103%	0.1285%	4. Wikipedia
47000 ? 107%	0.1200%	5. Pluto
43333 ? 111%	0.1106%	6. Irukandji jellyfish
35333 ? 123%	0.0902%	7. Wii
34333 ? 125%	0.0877%	8. Jeff Hardy
33000 ? 127%	0.0843%	9. Pok?mon
32666 ? 128%	0.0834%	10. Wiki

Nice margin of error.

Further down:

18333 ? 171%  0.0468% 	47. Brooke Hogan
18333 ? 171%	 0.0468%	48. Jessica Dee
18333 ? 171%	 0.0468%	49. F-15 Eagle
18333 ? 171%	 0.0468%	50. Providence, Rhode Island
18333 ? 171%	 0.0468%	51. Marilyn Manson (band)
18333 ? 171%  0.0468%	52. Jeff George

All the same values?

Gordo

--
"Think Feynman"/////////
http://pobox.com/~gordo/
gordon.joly at pobox.com///


from_name: Ivan Krstić

subject: [Wikitech-l] WikiCreole - a common wiki markup

body:
Hi Chuck,

Chuck Smith wrote:
> We have set up the WikiCreole wiki (www.wikicreole.org) to continue
> the discussion and work.  We would be interested to know what you
> think and to hear from you if you would also like to add Creole
> support to your wiki.

over the last few weeks, I designed a markup format to be used on the
laptops of the One Laptop per Child project (http://laptop.org), and
have arrived at one that's reasonably similar to Creole. The markup I've
worked on is a cross between John Gruber's Markdown and Lee Daniel
Crocker's proposed replacement for MW's wikitext syntax.

You can find the RFC (still a work in progress!), including rationale, here:
http://dev.laptop.org/git.do?p=users/krstic/docformat;a=blob;hb=HEAD;f=document-format.txt

The markup I need for OLPC is a superset of Creole, but it would
certainly be beneficial to see if we could converge on identical syntax
for the bits we do share.

Cheers,

--
Ivan Krsti? <krstic at solarsail.hcs.harvard.edu> | GPG: 0x147C722D


from_name: Sigvat Stensholt

body:
David Gerard wrote:

>>Or popular with the readers, at least.

>>http://tools.wikimedia.de/~leon/stats/wikicharts/index.php?ns=articles&limit=100&month=08%2F2006&wiki=enwiki

>>Interesting to-do list task: see what subjects or subject areas are in
>>demand from that list, and make a list of related subjects in the area
>>that aren't covered or could do with serious work.

>>- d.

Interesting. I am surprised that "Irukandji jellyfish" came so high up on the
list... is there some anomoly here?

Not all that surprised about how high Pokemon came up, it is a large fictional
universe and I would guess that that universe's main article would get a high
result.

Aww... my userpage and user-talk page aren't even on the top lists in their
respective categories. :-/

Sjakkalle


from_name: Jay R. Ashworth

subject: [Wikitech-l] References - ugh

body:
On Mon, Aug 28, 2006 at 10:52:42PM -0400, Simetrical wrote:
> On 8/28/06, Jay R. Ashworth <jra at baylink.com> wrote:
> > Because in wikitext, everything is in-band; in XML, the structure is
> > out-of-band, on purpose.  This requires an entirely different, and I
> > suspect, much more complicated diff algorithm.
>
> I don't know what "in-band" and "out-of-band" mean ([[Out of band]]
> doesn't help either),

The current diff engine, with which I'm not familiar intimately (read
that as I haven't looked at the code at all, but I'm assuming it's
somewhat familiar with the Unix diff internals) is working on one big
object of stream text.  The structural markup is *part* of that stream
of text, hence, in-band.

>                         but if the diff engine parses the XML, it can
> look for a) changes in structure/markup and b) changes in content.

Yep, and those will interact in ways different from the ways that they
do now: the current diff engine need not "trip over" the edges of
objects in the way that an XML parser will have to.

> Either one should be very easy and fast to diff, given XML-parsing
> library functions (for the C++ module used on WMF sites, that is).
> Faster than present, I don't know, but the present differ is hardly a
> bottleneck.

Certainly.  I wasn't suggesting that it was; rather, the opposite.

Anyone got any implementation experience with diffing XML trees?

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

	The Internet: We paved paradise, and put up a snarking lot.


from_name: Andre Engels

subject: [Wikitech-l] Categories problem

body:
2006/8/28, Jay R. Ashworth <jra at baylink.com>:

> > I think the behaviour where the saved text is not what you actually
> > typed ought to be kept to a minimum. At current I know of that
> > happening in two instances: ~~~~ (and variants) and [[Foo (blah)|]],
> > which is replaced by [[Foo (blah)|Foo]]. It's kind of surprising to
> > the user...
>
> I concur, but both examples are miswarts: on inspection, it's pretty
> clear why those choices were made...

I agree where the ~~~~ is concerned, but how about [[Foo (blah)|]]? I
have always considered the way that has been programmed to be some
kind of error. I think it would have been better to keep [[Foo
(blah)|]] in the text, and change it at parsing. Apart from the
'surprise' factor, I see two more advantages:
* It diminishes the human readability of the wiki text less (just
disregard the special symbols and anything between brackets and you
get the 'flat text')
* It makes it much easier for newbies to learn this 'trick'. Now you
have to hear or read it somewhere, but if it were not changed on save,
one could find it in existing wiki text and learn that way.

--
Andre Engels, andreengels at gmail.com
ICQ: 6260644  --  Skype: a_engels


subject: [Wikitech-l] References - ugh

body:
On Tue, Aug 29, 2006 at 09:32:48AM +0200, Steve Bennett wrote:
> On 8/29/06, Simetrical <Simetrical+wikitech at gmail.com> wrote:
> > I don't know what "in-band" and "out-of-band" mean ([[Out of band]]
> > doesn't help either), but if the diff engine parses the XML, it can
> > look for a) changes in structure/markup and b) changes in content.
>
> I think what's meant is that with XML, it's basically trivial to
> separate text from markup - depending on how you receive the XML, that
> may already have been done for you. The structure and formatting thus
> occupies a completely separate "band" to the text being formatted.
>
> Whereas Wikitext is a nightmare to parse :)

My point was that it's a bastard to parse, but it seems intuitively
that it would be *easier* to diff.

And as to "it's never going to happen"...

Never's a *long* time; if we wish to engage in gedankenexperiments
about how to do an implementation that's "never going to happen"...

who cares?

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

	The Internet: We paved paradise, and put up a snarking lot.


subject: [Wikitech-l] Smoother treatment of actions like "unwatch"

body:
On Tue, Aug 29, 2006 at 01:32:04PM +1000, Tim Starling wrote:
> Tels wrote:
> > Please ad "login". I hate it when I want to edit, then have to click in that
> > order:
> >
> >   * while loged out, click "edit"
> >   * see msg about need to log int, click "login"
> >   * (firefox fills in pwd/user) press button "login"
> >   * click "go back to page"
> >   * click "edit"
> >
> > That could be reduced by at least one click :)
>
> More than one, we could just put a username and password box on the edit form.

*Puhleeze*?  (and you might want to put the obligatory companion "Log
me in?" "Remember me?" and "Don't ever remember anyone, this is a
public computer" check boxes, though perhaps that's too much...)

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

	The Internet: We paved paradise, and put up a snarking lot.


subject: [Wikitech-l] Categories problem

body:
On Tue, Aug 29, 2006 at 11:49:44AM +0200, Andre Engels wrote:
> 2006/8/28, Jay R. Ashworth <jra at baylink.com>:
> > > I think the behaviour where the saved text is not what you actually
> > > typed ought to be kept to a minimum. At current I know of that
> > > happening in two instances: ~~~~ (and variants) and [[Foo (blah)|]],
> > > which is replaced by [[Foo (blah)|Foo]]. It's kind of surprising to
> > > the user...
> >
> > I concur, but both examples are miswarts: on inspection, it's pretty
> > clear why those choices were made...
>
> I agree where the ~~~~ is concerned, but how about [[Foo (blah)|]]? I
> have always considered the way that has been programmed to be some
> kind of error. I think it would have been better to keep [[Foo
> (blah)|]] in the text, and change it at parsing.

I'm of two minds on that.  I think I might like invisible magic in the
parser even less than I like visible magic in the subst:

>                                                  Apart from the
> 'surprise' factor, I see two more advantages:
> * It diminishes the human readability of the wiki text less (just
> disregard the special symbols and anything between brackets and you
> get the 'flat text')
> * It makes it much easier for newbies to learn this 'trick'. Now you
> have to hear or read it somewhere, but if it were not changed on save,
> one could find it in existing wiki text and learn that way.

Well, if you learned it.

I really *would* like to know what percentage of our editors are the
sort who would learn something like that; I'm *certain* it's
declining... and we'd do well to remember that.

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

	The Internet: We paved paradise, and put up a snarking lot.


subject: [Wikitech-l] Categories problem

body:
On Tue, Aug 29, 2006 at 01:44:54PM +0200, Steve Bennett wrote:
> On the other hand, it raises questions about the true syntax of
> MediaWiki: is [[foo (blah)|]] well-formed Wikitext or not?
> Technically, it's not. Practically, it is.

I don't see why it's not well-formed.  They've just made it magic,
because it looks prettier on output to hide the parenthetical.

Again: miswart -- looks broken, but not, because it was done for a good
reason.

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

	The Internet: We paved paradise, and put up a snarking lot.


from_name: Dion Rowney

subject: [Wikitech-l] Disabling users

body:
Hi,

We have setup Mediawiki within our University and have a fair understanding
of it.  Hoever, we failed to test the block feature and we discovered this
after setting it up and starting to use it :(

Block seems to clock the username from posting but it does not block the
user from logging in.  Has there been any work to either block logins for
blocked accounts or add an enabled flag in the user table?

Although wikis should be open communities, we use it for internal
documentation and when an employee leaves (or student drop a course etc), we
would like to be able to delete the or block the account from gaining read
access.  I am willing to work on this code if no one has done so already but
want the efforts to be put into the main source so I dont have to do it over
and over each time there is an upgrade.

Has anyone done this/started this/talked about this?

Dion Rowney
U of S


subject: [Wikitech-l] References - ugh

body:
Jay R. Ashworth wrote:
> Anyone got any implementation experience with diffing XML trees?

I haven't done it personally, but the paper I linked to earlier looked
at a bunch of implementations.

--
Ivan Krsti? <krstic at solarsail.hcs.harvard.edu> | GPG: 0x147C722D


from_name: Amgine

subject:
[Foundation-l] [Election] Big season of translation,
	we have now close to 20 candidates!

body:
On 29-Aug-06, at 6:11 AM, geni wrote:

> On 8/29/06, Aphaia <aphaia at gmail.com> wrote:
>> Hello all,
>> thank you for your help and interest as usual, now we close candidate
>> accepting. I hope we can release soon the complete list of
>> candidates.
>> This election gets a wide attention, and we have now close to 20
>> candidates.
>
>
> So less than a third of the total who ran in en.wikipedia's arbcom
> elections. Are people now going to accept that
> [[MediaWiki:Watchdetails]] provides enough profile for this kind of
> notice?
>
> --
> geni

No.

Amgine

-------------- next part --------------


from_name: Jeff V. Merkey

subject:
[Foundation-l] Swahili Machine Translation First Run Completed
 for	enwiki-20060817

body:
Martin,

Thanks for the phone call today and let's get going on taking this off list
and getting the parser and grammar rules put together for the
translator. I think we
could get this machine assisted translation of over 90% after
application of a
set of grammar rules. I wanted to demonstrate how rapidly this could be done
and embrace the full wikipedia. As I said in the earlier post, I have not
applied any grammar, tensing, word pairing, or other rules, just a
simple word
by word and phrase translation. I am sending the materials we discussed
and I anticiapte we can get to 95% accuracy by the end of autum. This
would provide
an excellent basis for your African Languages Programs.

P.S. I agree that the public swahili dictionary is junk, BTW.

Jeff

Martin Benjamin wrote:

>Jeff,
>
>I applaud you for your initiative - your effort is impressive, albeit
>unreadable.  I'll give my feedback in this post, and then suggest we
>take the discussion of the specifics of Swahili translation off-list
>(and welcome others who want to keep track of this thread to email us to
>stay in the cc loop).  The last 2 or 3 paragraphs of this post do speak
>to the wider discussion list, so other readers might wish to SKIP TOWARD
>THE BOTTOM.
>
>
>


from_name: Simetrical

subject: [Wikitech-l] References - ugh

body:
On 8/29/06, Steve Bennett <stevage at gmail.com> wrote:
> No, but I'm wondering what happens if you simply flatten it down to
> text then diff. What's the worst that could happen?

The worst that could happen is it's all on one line and your diff
engine says "line 1 was changed, here are the lines side-by-side".
No, that wouldn't work too well: instead, how about you

1) Compress all whitespace in each document per XML specs,
2) Replace all /(<.*?>)/ with /\n$1\n/ in each document,
3) Run a normal line-based diff, such as the one we use now.

Each tag will then be on one line, and so will the contents of each
tag.  Perfect?  Ideal?  No, but definitely usable.


from_name: Steve Bennett

subject: [WikiEN-l] Colbert on the loose

body:
Hi all,
  Just removed another tripling elephant population reference at
[[Queenie (elephant)]], which had apparently been there for 2 weeks. I
wonder how many more of these there are.

Even more alarmingly,
http://www.google.com/search?hl=fr&ie=UTF-8&oe=UTF-8&q=elephant%20population%20triple%20site%3Aen.wikipedia.org
shows quite a few of these joke references have made their way into
Google's cache.

Ok, the current example is trivial, but maybe we need some sort of
organised response to these kind of attacks, which will presumably
become more common. What if an organised group starting planting
"George Bush is dead" all over the place or something...

Steve


body:
Martin Benjamin wrote:

>
>  It looks like someone started with a smallish Swahili-English
>wordlist, plugged that into an English thesaurus, and extrapolated
>dozens of additional English equivalents per word, yielding an
>intriguing but lexicographically suspect set of equivalencies.
>
>

Actually, I used yours from the Kamusi project. All of this needs review
and correction.
I went through the Cherokee versions and corrected them by hand. Took
weeks of tedious work,
and we are still working on more.

But for four hours of work, pretty good progress .... :-)

:-)

Jeff


from_name: Gerard Meijssen

body:
Daniel Bregman wrote:
> Over at Incubator we've been deciding our policy with regard to
> starting new language (of an existing project) tests, and new project
> tests.
> We've come up with this:
>
>    - New languages can create a test on Incubator quite easily, needing
>    only to get a few people who will help. (
>    http://incubator.wikimedia.org/wiki/I:NTR)
>    - New
>    languages can create a full wiki using an approval process on
> Incubator, and it will be made (or not) after consensus
>    has been reached. (http://incubator.wikimedia.org/wiki/I:NLR)
>    - New projects will need approval from the foundation to have a test
>    made, and then need further approval to make a full wiki.
>
> Is this acceptable? We are also not sure about what exactly the Foundation
> needs to approve. Views we got previously seemed to be slightly
> contradictory on this matter.
>
> Thank you for your replies,
>
> Dbmag9 (http://incubator.wikimedia.org/wiki/User:Dbmag9)
Hoi,
In the past we have accepted codes to be used as "language" codes which
were non-existent and have had as a result that we are not in compliance
with the rules of accepted use for the ISO-639 codes. When codes for new
languages are used that are not consistent with the existing ISO-639
codes (all two and three character codes) a language should not be
accepted at all.

Anthere has indicated a few weeks ago that in the end it is the board
that accepts languages and that this process happens at Meta not at the
incubator.

Thanks,
    GerardM


from_name: Tim Starling

body:
Tels wrote:
> Please ad "login". I hate it when I want to edit, then have to click in that
> order:
>
>   * while loged out, click "edit"
>   * see msg about need to log int, click "login"
>   * (firefox fills in pwd/user) press button "login"
>   * click "go back to page"
>   * click "edit"
>
> That could be reduced by at least one click :)

More than one, we could just put a username and password box on the edit form.

-- Tim Starling


from_name: MacGyverMagic/Mgm

subject: [WikiEN-l] Colbert on the loose

body:
Surely we can have a bot spider pages or dumps for triplet elephant
references?

On 8/29/06, Steve Bennett <stevagewp at gmail.com> wrote:
>
> Hi all,
> Just removed another tripling elephant population reference at
> [[Queenie (elephant)]], which had apparently been there for 2 weeks. I
> wonder how many more of these there are.
>
> Even more alarmingly,
>
> http://www.google.com/search?hl=fr&ie=UTF-8&oe=UTF-8&q=elephant%20population%20triple%20site%3Aen.wikipedia.org
> shows quite a few of these joke references have made their way into
> Google's cache.
>
> Ok, the current example is trivial, but maybe we need some sort of
> organised response to these kind of attacks, which will presumably
> become more common. What if an organised group starting planting
> "George Bush is dead" all over the place or something...
>
> Steve
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> To unsubscribe from this mailing list, visit:
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


body:
On 8/29/06, Andrew Gray <shimgray at gmail.com> wrote:
> Jellyfish wasn't on the list at all last night; the statistics are
> sampling (I think) one in five thousand pageviews, so it's quite
> likely a glitch. They've only been running for a couple of days, and
> I'd strongly advise against treating them as reliable until at least a
> fortnight in.

The sampling period is, from my observation, constantly being
decreased. It was 5000, then 1000, then 500, now 333. Well, I'm
guessing just looking at what numbers have turned up at different
times. I don't know exactly how the "+-111%" is calculated, but I
would say that we're getting to the stage where the values are
somewhat meaningful. With the exception of Jeff Hardy, all the other
top 10 entries seem very plausible and topical.

However, I can't see why Irukandji jelly fish would be so high. It's
not linked from anything, it's not in the news, and it's not even
jellyfish season in Queensland. It could just be a statistical
anomaly, or perhaps someone is deliberately messing with the stats?

> That said... JonBenet Ramsay is interesting - it surged last night and
> with no link from the front page. Interesting to see how quickly our
> use (apparently) reacts to news stories. The sex-related ones - lists
> of porn stars etc - were consistently high and are now dropping; I
> wonder where they'll stabilise at.

Yes, that trend is interesting - why did they all show up so high then
disappear. Was it a time of day thing? More stats required!! :)

I really hope we will end up with "last 24 hours" and "last 7 days" stats.

Steve


subject: [WikiEN-l] on new article creation

body:
On 8/29/06, Gordon Joly <gordon.joly at pobox.com> wrote:
> I have found two articles that needed attention within the past few
> days. I probably came to Wikipedia via a Google.com search. In other
> words, I did not start in Wikipedia.

I'm not quite sure what you're getting at, but the discussion was
primarily about creating *new* articles - it looks like you have
*rewritten* two articles (a very welcome move indeed!)

> When I started being editing, and I am a late comer (January 2004),
> there was no clear policy (or I was unaware of it).

The living persons policy is quite new (late 2005 or early 2006).

Steve


subject: [Wikitech-l] Categories problem

body:
On 8/29/06, Andre Engels <andreengels at gmail.com> wrote:
> I agree where the ~~~~ is concerned, but how about [[Foo (blah)|]]? I
> have always considered the way that has been programmed to be some
> kind of error. I think it would have been better to keep [[Foo
> (blah)|]] in the text, and change it at parsing. Apart from the
> 'surprise' factor, I see two more advantages:
> * It diminishes the human readability of the wiki text less (just
> disregard the special symbols and anything between brackets and you
> get the 'flat text')
> * It makes it much easier for newbies to learn this 'trick'. Now you
> have to hear or read it somewhere, but if it were not changed on save,
> one could find it in existing wiki text and learn that way.

Agree with all that - I would be curious to hear what the rationale
was. Most likely it simplifies parsing to do it this way, as the
parser doesn't need to be touched.

On the other hand, it raises questions about the true syntax of
MediaWiki: is [[foo (blah)|]] well-formed Wikitext or not?
Technically, it's not. Practically, it is.

Steve


from_name: Matt Brown

subject: [WikiEN-l] WP:LIVING and "sensitivity" again

body:
On 8/29/06, David Gerard <dgerard at gmail.com> wrote:
> Our pop culture articles are rubbish, and they definitely need no more
> encouragement toward a hagiographic point of view.

Very much agreed.  I am very against any suggestion that strongly
sourced, accurate negative information that is relevant to the
person's notability/notoriety should be removed from articles for
'sensitivity'.

I am in favor of being very tough about the 'well sourced' part,
though, and about the notability of life details.  Not everything
about their private lives that has been e.g. dragged out in divorce
court is really notable.

-Matt


subject: [Wikitech-l] References - ugh

body:
On Tue, Aug 29, 2006 at 12:06:42PM -0400, Ivan Krsti?? wrote:
> Jay R. Ashworth wrote:
> > Anyone got any implementation experience with diffing XML trees?
>
> I haven't done it personally, but the paper I linked to earlier looked
> at a bunch of implementations.

I'll check it out and see if it agrees with my prejudices.
--
--
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	The Internet: We paved paradise, and put up a snarking lot.


subject: [Wikitech-l] References - ugh

body:
On Tue, Aug 29, 2006 at 06:42:38PM +0200, Steve Bennett wrote:
> On 8/29/06, Jay R. Ashworth <jra at baylink.com> wrote:
> > Anyone got any implementation experience with diffing XML trees?
>
> No, but I'm wondering what happens if you simply flatten it down to
> text then diff. What's the worst that could happen?

Well, that would likely make the job back into what we have now, yes.

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

	The Internet: We paved paradise, and put up a snarking lot.


body:
On Tue, Aug 29, 2006 at 05:12:19PM +0100, Rob Church wrote:
> On 29/08/06, Jay R. Ashworth <jra at baylink.com> wrote:
> > *Puhleeze*?  (and you might want to put the obligatory companion "Log
> > me in?" "Remember me?" and "Don't ever remember anyone, this is a
> > public computer" check boxes, though perhaps that's too much...)
>
> "Puhleeze"? You can't submit a patch? ;)

:-)

Even if I wasn't hanging paper on three houses with only one hand, I
probably couldn't, no.  Dammit, Rob, I'm an analyst, not a programmer.

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

	The Internet: We paved paradise, and put up a snarking lot.


from_name: Martin Benjamin

subject:
[Foundation-l] Swahili Machine Translation First Run Completed for
	enwiki-20060817

body:
Jeff,

I applaud you for your initiative - your effort is impressive, albeit
unreadable.  I'll give my feedback in this post, and then suggest we
take the discussion of the specifics of Swahili translation off-list
(and welcome others who want to keep track of this thread to email us to
stay in the cc loop).  The last 2 or 3 paragraphs of this post do speak
to the wider discussion list, so other readers might wish to SKIP TOWARD
THE BOTTOM.

The first problem derives from your sources.  The first source, "public
swahili lexicon," is a useless set of about 1000 nouns, adjectives, and
conjunctions, essentially a tourist vocabulary without any verbs.  I
would be surprised if that list gave any pairings that weren't also in
the other lists.  The third source, "rogets thesaurus in swahili," is
one I would like to know more about, but is not useful for machine
translation purposes in the configuration you've set up - for example,
scroll down to line 51382, and look at the following 100-odd pairs for
"idhini" in no particular order, with no way to distinguish among parts
of speech, shades of meaning, relative frequency, etc.  However, I was
heartened to see line 45405 and following; I'm sure that if any
wikipedia entries need to be translated that include "assify,"
"torpedinous," or "macht nichts," this thesaurus will prove quite handy.
  It looks like someone started with a smallish Swahili-English
wordlist, plugged that into an English thesaurus, and extrapolated
dozens of additional English equivalents per word, yielding an
intriguing but lexicographically suspect set of equivalencies.

Which leads us to the Kamusi Project as a source.  I will be the first
to say that the Kamusi is a pretty good Swahili dictionary that will one
day be a great Swahili dictionary, but at the moment contains
significant weaknesses that prevent it from being a reliable source for
machine translation.  The first issue is the quality of the data.  The
initial data were manually input from an existing print dictionary to
which we were granted copyright permission.  Unfortunately, the students
entering the data, before we programmed the Edit Engine, introduced a
lot of errors.  I am currently in the process of going through the
database entry by entry, fixing those errors and adding in new heaps of
data, including information for many data fields that we hadn't
introduced during the initial data entry phase.  This is an incredibly
time consuming, research-intensive task, and I don't foresee having a
Swahili->English dictionary that I am really happy with for another
couple of years (at best - the thesaurus above, and my wife, would
describe our current funding situation as "pauperized").

The Kamusi lexicon is much better as a Swa->Eng source than as an
English->Swahili dictionary, because that is the direction in which
we've input most of the initial data.  The magic of databases makes it
possible to have our data available bi-directionally, but the E->S
version of the Kamusi needs its own careful review.  That review can
only come after the S->E data are thoroughly updated.  Most especially,
precious few E->S entries have been arranged with the Grouping Tool (
http://research.yale.edu/swahili/serve_pages/groupingtool_en.php ), so
most entries appear in an arbitrary order that does not account for
homographs, differing senses, frequency, etc.  So, it would be premature
to use the E->S Kamusi lexicon as a platform for machine translation,
even though we do intend to get there.

When the data are ready for machine use, the program would also need to
check the four "alternate spellings" fields, to pick up all the color v.
colour issues that occur in both English and Swahili.  Also, I would
think that you would want to keep part of speech info associated with
each line, which would make it much easier to employ grammar rules.  A
grammar hint: in Swahili, the adjective always comes *after* the noun
that it modifies, except for the words "kila," "nusu," and "robo", and a
few other cases, including the numbers preceding "elfu" for thousands
between 11,000 and 99,000.

Another hint: Swahili does not use articles, so you need to get rid of
most attempts at translations of a/ an/ the.  When an article is
absolutely necessary (which a computer would have a difficult time
predicting), Swahili uses variations of "one" for a/ an, and "that" for
the.  Just getting rid of the articles in your articles would be a 100%
improvement (bringing them up to 2% readable).

Ok, now assume we have good data, with a good way of predicting which
words were appropriate in which circumstances (something that will
eventually be aided by the work now being done toward building a central
OmegaT database), and a good set of grammar rules.  You would still need
to deal with the agglutinative Swahili verb in all its glory.  The
Kamusi Project has a good parser embedded in our Swahili->English
search, which disentangles the front end of any conjugated Swahili verb
according to an analysis of every grammatical rule in the language.  (We
have a similar analysis completed and written in pseudo-code for the
back end, the verbal extensions, but ran out of money and had to lay off
our programmer before we could code it into the search engine.)  Even
taking advantage of our parser, your translating software would need to
go the other way, building Swahili verbs from conjugated English verbs.
  You would need to account for the noun classes of each noun that is
referred to in the verb (as many as three different nouns, each of which
is either one of four different conversational participants or belongs
to one of 16 different noun classes), which involves trivial calls to
our database once you've identified the appropriate elements in the
English sentence and chosen the relevant nouns - the "class" field is
the key here.  The real problem comes from conjugated English verbs.
You need some way of knowing that "catches/ caught" relate to "catch,"
which would involve a database of English verbs and their irregular
forms, and then you would need to map the various movable elements of
the English sentence to the appropriate fixed points of the Swahili
verb.  Not an impossible task to achieve to 90% over time, but not
nearly as straightforward as you are hoping.

Of course, this is all for Swahili, for which we have a pretty good
initial lexicon en route to becoming excellent, a complete description
of grammatical rules, and an accepted, unicoded orthography.  Most other
African languages, even those spoken by millions of people, are missing
some or all of those elements in digital form.  So, even if you could
get pretty good machine translation of Wikipedia for Swahili, you would
still be a long, long way away from rolling with other languages.

And we still haven't dealt with content.  What's to say that content
that is appropriate for the English Wikipedia is appropriate for the
Swahili Wikipedia?  For example, the entry for Agriculture.  It begins
by discussing the derivation of the word "agriculture," which is of
course irrelevant for Swahili.  Then it carries an unacknowledged POV
about modern agriculture (as though the vast numbers of Africans who
earn their livings with hand hoes are pre-modern museum relics, and
let's not even click on the link to "subsistence farming" that talks
about "life outside of modern society"), and essentially ignores all of
the issues of raising crops on small farms that would be of immediate
interest to an African farmer logging in from an internet kiosk.
(Comment to those who fear paternalism in this endeavor: the people I
live and work among in Tanzania express a huge interest in having access
to this sort of information, although they are not in a position to
contribute to the development of the resource.)  So, an African farmer
trying to combat an insect infestation on her farm would find a
translation of an English "agriculture" article that focuses on
technology-intensive farming to be much less useful than an article
started almost from scratch that addressed farming in the context of
speakers of that language.  It just happens that "agriculture" was the
second article I clicked to by following links from the initial article
on the pseudo-Swahili test site - what similar issues would arise on the
fourth article, or the tenth, or the 997,032nd?

There's also the issue that a great many of the current English
Wikipedia articles are works in progress, of varying quality.  Would you
do a one time machine translation of the current Wikipedia, and ignore
all future edits?  Translate only "stable versions?  Re-translate
articles every time there is a change?  Re-translate every time the
Kamusi Project data is updated (hundreds of times a week)?  Have the
machine overwrite manual edits that someone did to machine translations,
when the English version changes?  Do this for dozens of African
languages, and hundreds of languages around the world?

I don't want to dismiss the entire endeavor, although I've been working
on these issues for long enough to be sure that the undertaking is much
more complicated than you're estimating.  Here's where I think your
translation project might prove useful: if a speaker of, for example,
Swahili went searching for an entry that didn't already exist in the
Swahili Wikipedia, an application could build a version of that page
on-the-fly from the English version that is current at that moment.  The
Wikipedia user could then either (a) glean whatever information she
could from the article and move on, (b) laugh uproariously, or (c) go
into edit mode, work to turn the machine translation into something
readable in Swahili, and save that version - which would then become the
baseline page for that entry in that language, from which future edits
could take off.  In this way, you would get the best of both worlds -
good articles written in the actual language whenever possible, and
fingertip access to rough machine translations from English when
articles are not initially available in the target language.


subject: [Wikitech-l] Categories problem

body:
On Tue, Aug 29, 2006 at 06:46:24PM +0200, Steve Bennett wrote:
> On 8/29/06, Jay R. Ashworth <jra at baylink.com> wrote:
> > I don't see why it's not well-formed.  They've just made it magic,
> > because it looks prettier on output to hide the parenthetical.
>
> How would you know? How can you test if the parser can parse something
> if every time you try and save it, mediawiki converts it into
> something else?
>
> Maybe something really tricky like using subst would work:  [[foo
> (blah){{a}} where {{a}} is the string "|]]".

Your question is, I think, really "does the parser treat it as a first
class object, handling all legal arguments in that situation?"

And yeah, that's a valid question.  :-)

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

	The Internet: We paved paradise, and put up a snarking lot.


from_name: David Gerard

subject: [WikiEN-l] on new article creation

body:
On 29/08/06, Steve Bennett <stevagewp at gmail.com> wrote:
> On 8/29/06, Gordon Joly <gordon.joly at pobox.com> wrote:

> > When I started being editing, and I am a late comer (January 2004),
> > there was no clear policy (or I was unaware of it).

> The living persons policy is quite new (late 2005 or early 2006).

The important point about the living persons policy is that it's
really a guideline to be really hard-arsed about NPOV and
verifiability. If you keep that in mind, everything follows.

- d.


subject: [Wikitech-l] Disabling users

body:
On 8/29/06, Dion Rowney <dion_rowney at hotmail.com> wrote:
> Hi,
>
> We have setup Mediawiki within our University and have a fair understanding
> of it.  Hoever, we failed to test the block feature and we discovered this
> after setting it up and starting to use it :(
>
> Block seems to clock the username from posting but it does not block the
> user from logging in.  Has there been any work to either block logins for
> blocked accounts or add an enabled flag in the user table?
>
> Although wikis should be open communities, we use it for internal
> documentation and when an employee leaves (or student drop a course etc), we
> would like to be able to delete the or block the account from gaining read
> access.  I am willing to work on this code if no one has done so already but
> want the efforts to be put into the main source so I dont have to do it over
> and over each time there is an upgrade.
>
> Has anyone done this/started this/talked about this?

See http://bugzilla.wikimedia.org/show_bug.cgi?id=1924.


from_name: geni

body:
On 8/29/06, Aphaia <aphaia at gmail.com> wrote:
> Hello all,
> thank you for your help and interest as usual, now we close candidate
> accepting. I hope we can release soon the complete list of candidates.
> This election gets a wide attention, and we have now close to 20
> candidates.

So less than a third of the total who ran in en.wikipedia's arbcom
elections. Are people now going to accept that
[[MediaWiki:Watchdetails]] provides enough profile for this kind of
notice?

--
geni


from_name: [LiM] Manop

body:
Thank you for the reply. It seems that people from Thailand cannot access
Wikipedia in other languages as well as Thai Wikipedia; I and my friends did
test in English (en), German (de), and Japan (ja). The problem occurs in
other projects as well including Wiktionary, Wikisources.

However I and my friends in Thailand can access to this site
https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page

Manop

On 8/29/06, Andrew Gray <shimgray at gmail.com> wrote:
>
> On 29/08/06, [LiM] Manop <manop at 6tub1.com> wrote:
> > Hello,
> >
> > I'm wondering if anyone have the same problem. Several of my friends in
> > Thailand cannot access to Thai Wikipedia (http://th.wikipedia.org) today
> > since 4-5 hours ago. But I access from the USA, it works fine for me.
>
> Is it just th.wikipedia, or other language sites as well?
>
> --
> - Andrew Gray
>   andrew.gray at dunelm.org.uk
>

--
(LiM) Manop Kaewmoracharoen
427 Town Engineering Bldg.
Iowa State University


from_name: Brion Vibber

subject:
[Wikitech-l] [WM project][Sitenotice] Please blank it for a
	while.

body:
Aphaia wrote:
> Global sitenotice on the Wikimedia project says:
>> Candidates for the Election for the Board of Trustees of the Wikimedia Foundation
>> are being accepted until 23:59 UTC Monday, August 28, 2006.
>
> On behalf of Election Committee and all those who helped this
> acceptance, I am happy to say hereby we closed acceptance on August 28
> successfully. Soon the complete list of candidates will be in public.
> Now we don't therefore need to advertise it moreover. Please now
> remove the message. Thank you!

Done.

-- brion vibber (brion @ pobox.com)

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


from_name: stevertigo

subject: [WikiEN-l] Policy across different languages

body:
--- Kirill Lokshin <kirill.lokshin at gmail.com> wrote:

> "Bureaucracy = evil" -- ??????????????????
>
> "Without a strict understanding of 'authoritative source', the rule is
> useless and perhaps even harmful" -- Jannikol
>
> "Forbidding original research will be enough, in my opinion.  Extra
> disputes and bureaucracy won't lead to anything good" -- Terminus
>
> "The assertion that verifiability is more important than truth seems
> disputable.  And furthermore, to create the ideal article, we need to
> study the actual thing, not stories about it in 'authoritative
> sources'" -- Fred

I had hoped the Russians loved NPOV too!  :)

Stevertigo

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


from_name: Oskar Sigvardsson

subject: [WikiEN-l] Colbert on the loose

body:
On 8/29/06, Steve Bennett <stevagewp at gmail.com> wrote:
> Ok, the current example is trivial, but maybe we need some sort of
> organised response to these kind of attacks, which will presumably
> become more common. What if an organised group starting planting
> "George Bush is dead" all over the place or something...
>
> Steve

Then we'll revert, block the users and if they still keep coming,
semi-protect the article until the shitstorm is over. Hasn't this been
the way we've always dealt with vandals? (well, semi-protection is
new, but you get my point)

The thing to remember with these attacks is that they are very
short-lived. They're tenacious, but after a while they will get tired
of it. In a month, who will even remember the Colbert thing? This sort
of vandalism has never really been wikipedias problem, much more
dangerous is the subtle, change-a-date-to-be-a-few-days-off-style
vandalism. And we're cracking down on that too with the whole
verifiability and sourcing thing.

--Oskar


from_name: Sydney aka FloNight

body:
---- David Gerard <dgerard at gmail.com> wrote:

=============
See WT:LIVING, discussion at end. The "nutshell" has been
instruction-crept by the well-meaning and is an obfuscated mess.

Key problem: the innovation of "sensitivity" which was introduced as a
fresh new thing in this guideline. While it seems the proper and human
thing to be sensitive to living persons, the use of the term in that
form does pretty much subvert the NPOV "hard policy" in the wording of
a secondary guideline<->policy.

I appreciate the need, but there's gotta be a way to word it that
doesn't seem like an end-run around NPOV.

Idea: the thing already in about notability of life details. That
would seem to me to cover it.

Any more ideas?

- d.

David,

IMO, BLP articles need to be treated differently. See policy talk page for my complete reply. Several other editors responded also.

Can you give me examples of how being sensitive has made the situation worse?

None of us that support that wording think that NPOV, NOR, or V is overwritten by BLP policy. If anything, we say that the BLP policy causes our core policies to be applied more aggressively.

Sydney aka FloNight


from_name: George Herbert

subject: [Wikitech-l] Disabling users

body:
Have you tried:

Create a new group "readers", with "read" userright.
Disable "read" rights for "users" group.
Put your open content in the $wgWhitelistRead variable (login, main pages,
etc); make sure anything sensisitve isn't in $wgWhitelistRead.
To "activate" a new account, a burecrat has to add them to group "readers".
To "deactivate" a new account, a burecrat removes them from group "readers".

See:
http://meta.wikimedia.org/wiki/Help:User_rights
LocalSettings.php
includes/DefaultSettings.php

I haven't tested this quite yet, but was going to this week for an internal
corporate MediaWiki I'm running.

If it doesn't work, let me know, so I can figure something else out.  8-)

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


from_name: ATR

subject: [Foundation-l] Celebrity pictures

body:
 | Date: Tue, 29 Aug 2006 09:36:30 -0400
| From: Anthony <wikilegal at inbox.org>
| Subject: Re: [Foundation-l] Celebrity pictures
| To: "Wikimedia Foundation Mailing List" <foundation-l at wikimedia.org>
| Message-ID:
| <71cd4dd90608290636p645474e7m1f132123a17319e9 at mail.gmail.com>
| Content-Type: text/plain; charset=ISO-8859-1; format=flowed
|
| On 8/29/06, Ray Saintonge <saintonge at telus.net> wrote:
| > Anthony wrote:
| > >On 8/28/06, Ray Saintonge <saintonge at telus.net> wrote:
| > >>Perhaps more significant than whether anyone has lost is whether any
| > >>such case has ever been filed.  Given that they are distributed for
the
| > >>specific purpose of publicity there could be an implicit permission.
| > >>
| > >>
| > >If you're using the image for the purposes of promoting the person.
| > >If, on the other hand, you're using the image to sell an encyclopedia
| > >article which portrays the person in a way which they don't want to be
| > >portrayed, then there probably isn't implicit permission.
| > >
| > I don't know if it's to "sell" an encyclopedia.  Lindsay Lohan would
| > need to think she's pretty special if she believes a picture of her will
| > make all the difference in encyclopedia sales.  Is she as self-absorbed
| > as Paris Hilton?  Our use is transformative, and it in no way adversely
| > affects the company's sales..  It would even be interesting to hear the
| > companies comment on the function of publicity shots.
| >
| I was talking about reuse.  Specifically, someone who was selling
| print encyclopedias with the current Lindsay Lohan article in it.  I
| didn't mean to imply that the selling point was the picture, but
| merely that the encyclopedia was being sold.
|
| > >Maybe I'm overly paranoid, but even here in the US where we have some
| > >very strong fair use and first amendment rights, I still wouldn't feel
| > >comfortable selling an encyclopedia with the current [[Lindsay Lohan]]
| > >article in it, without first receiving permission from the copyright
| > >holders of the images.
| > >(http://en.wikipedia.org/w/index.php?title=Lindsay_Lohan&oldid=72480012
| > >in case it changes before this is read)
| > >
| > This may be a problem for the print version, and specific permissions
| > should probably be sought when we get that far.  For the on-line
| > verrsion however I have no problem with an active campaign to replace
| > the fair use images with "free" ones.  It's clear that I'm more risk
| > tolerant than you, but that doesn't mean there's such a wide gap between
| > our views.
| >
| I don't think it makes sense to have such significant differences
| between the print version and the online version.  Other than that, I
| agree with you though.  I wouldn't have a problem distributing the
| current article online.  In fact, I have a website where I'm doing it.
|
| Jimbo has stated, long in the past, that he doesn't want the print
| version to be a fork of the online version.  Maybe he's changed his
| mind, but if not I think you have to consider the print and online
| versions to be the same thing.
|
| > >Frankly I think that case could be probably be won by the museum on
| > >appeal, if they spent enough money fighting it.
| > >
| > Yeah, Dillinger has been dead since 1934.
| >
| In Indiana the right to publicity persists after death, though.
|
| > >Besides, there are
| > >always going to be crazy jurisdictions (like Indiana, apparently) with
| > >laws so out of touch with reasonableness that we just can't follow
| > >them.
| > >
| > Developing policies to account for such extremes is playing to the
| > lleast common denominator.
| >
| Absolutely.  I agree.  But at the same time, US fair use is an extreme
| too, just on the other end of the spectrum.
|
| > >As for relying on the copyright holder of the image finding the
| > >Wikipedia article "respectful", well, I just think that's a horrible
| > >thing for us to even have to consider.  Would Linsay Lohan (*) object
| > >to our portrayal of her in "Media spotlight"?  I don't know, and I
| > >don't care.
| > >
| > There's also the question of who owns the copyright.  I suspect it's the
| > studio who sends out fan pics to admirers.
| >
| I would think, with a publicity photo, that it'd be the publicist.
|
| Anthony
|

Might also the NY Times test apply here? Celebrities, being public figures
should be viewed in public. A publicity photo is just for that purpose, to
have the person's photo
be put out into the public. Besides the strict fair use argument (there is
no loss to their
marketplace by putting the celebrity photo out) one could also argue that a
plain head
shot (that does not involve any creative positioning etc.) really the photo
belongs to the
celebritity (and usually they own those photos by contractual work made for
hire agreements anyway) not to a publicist or other third party (though
sometimes photos made for specific publications are copyright by that
publication as part of a story that
is being done for that publication). A regular publicity photo might only
have a claim by
the celebrity and in that case one might even argue that under the NY Times
test that
as long as actual malice does not apply to use of the photo, that the photo
can be
reproduced anywhere else (I haven't done any caselaw research on this so I
cannot state
that this would prevail but it seems a reasonable argument to make now).

This question also opens up all the moral rights questions associated with
altering someone's work. Obviously if some punk rocker took a GFDL released
photo (with a right of publicity implicitly released) from someone's profile
on WP and then altered it into making them look "evil" that could be
considered defamatory (either as a breach of privacy or perhaps some other
tort, if not actual defamation) and so one could argue that the GFDL and CC
never include permission for such tranformations of an image, even a public
domain image could be the basis of a tortious transformation. If it were
just being
used in another encyclopedia article how could they argue that an accurate
image of their
face damages them in anyway (including under copyright laws) since that is
the reason they released the photo in the first place?  Having the photo
used in a thumbnail in an encyclopedia is just enhancing their celebrity
status, not causing them to loose money.
It is the other transformative uses that need to be looked at, I think.

Of course if the GFDL were drafted by an Canadian open source foundation
then the
whole bundle of moral rights protections would definitely apply, besides the
right of
pubicity issues, but in the US it is not so clear even though it signed the
Berne Convention it has limited moral rights protections under the [[Visual
Artists Rights Act]]
that only apply to limited types of "works of visual art" as defined in
Title 17 USC  sec. 101 and do not cover publicity photos.

alex756 (IAAL)


subject: [Foundation-l] Celebrity pictures


from_name: Dion Rowney

subject: [Wikitech-l] Disabling users

body:
This bug has status "Resolved (wontfix)"

Am I correct in that it Its also seems to elude to trying to block users
from certain sections, The entire wiki and loging completion?

Dion

>From: Simetrical <Simetrical+wikitech at gmail.com>
>Reply-To: Wikimedia developers <wikitech-l at wikimedia.org>
>To: "Wikimedia developers" <wikitech-l at wikimedia.org>
>Subject: Re: [Wikitech-l] Disabling users
>Date: Tue, 29 Aug 2006 14:09:10 -0400
>
>On 8/29/06, Dion Rowney <dion_rowney at hotmail.com> wrote:
> > Hi,
> >
> > We have setup Mediawiki within our University and have a fair
>understanding
> > of it.  Hoever, we failed to test the block feature and we discovered
>this
> > after setting it up and starting to use it :(
> >
> > Block seems to clock the username from posting but it does not block the
> > user from logging in.  Has there been any work to either block logins
>for
> > blocked accounts or add an enabled flag in the user table?
> >
> > Although wikis should be open communities, we use it for internal
> > documentation and when an employee leaves (or student drop a course
>etc), we
> > would like to be able to delete the or block the account from gaining
>read
> > access.  I am willing to work on this code if no one has done so already
>but
> > want the efforts to be put into the main source so I dont have to do it
>over
> > and over each time there is an upgrade.
> >
> > Has anyone done this/started this/talked about this?
>
>See http://bugzilla.wikimedia.org/show_bug.cgi?id=1924.
>_______________________________________________
>Wikitech-l mailing list
>Wikitech-l at wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikitech-l


subject: [WikiEN-l] [[User:Jon_Awbrey]] is at it again...

body:
On 8/29/06, Daniel R. Tobias <dan at tobias.name> wrote:
>
> Now he's trying to get [[Wikipedia:WikiLawyering]] deleted:
>
> http://en.wikipedia.org/wiki/Wikipedia:Miscellany_for_deletion/Wikiped
> ia:WikiLawyering

...and he forgot to link from the main MFD page.

I just fixed that.

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


from_name: Gregory Maxwell

body:
On 8/29/06, geni <geniice at gmail.com> wrote:
> So less than a third of the total who ran in en.wikipedia's arbcom
> elections. Are people now going to accept that
> [[MediaWiki:Watchdetails]] provides enough profile for this kind of
> notice?

By your logic we would conclude that a watchlist only site notice gets
higher visability than the system wide one.


body:
On 8/29/06, Steve Bennett <stevagewp at gmail.com> wrote:
> However, I can't see why Irukandji jelly fish would be so high. It's
> not linked from anything, it's not in the news, and it's not even
> jellyfish season in Queensland. It could just be a statistical
> anomaly, or perhaps someone is deliberately messing with the stats?

Might be on various school national caricular.
--
geni


from_name: Mark Clements

subject: [Wikitech-l] Upload large files

body:
"Timwi" <timwi at gmx.net> wrote in message
news:ecl9gm$dij$1 at sea.gmane.org...
> Simetrical wrote:
> > On 8/24/06, Timwi <timwi at gmx.net> wrote:
> >
> >>I was trying to address the security issues
> >>that come from the user's ability to cause the server to perform any GET
> >>request to any server.
> >
> > This is a problem why, provided the server is careful about what it
> > does with the response?
>
> It's not the response that's the problem, it's the GET request itself.
>
> Suppose some stupid web programmer programmed a forum where you can
> delete posts with a GET request. If you can fire GET requests to any
> server from Wikimedia's servers, then the forum's servers will only log
> Wikimedia's IPs, and the mass-deletion forum vandal is now untraceable.
>
> I'm sure there are even more significant cases that I haven't thought of.
>
> Timwi

It would not be hard to include appropriate trace information in the headers
(referrer & useragent), which will show up in the remote website's logs.
For example, IP/username of the uploader, link back to the resulting image
page, etc.

We could even set the referrer URL to a non-editable page giving full
details about the specific request, with further links that explain the
feature and how it works, give details about how to report abuse/copyright
infringement, etc.

- Mark Clements (HappyDog)


from_name: Andrew Gray

body:
On 29/08/06, Steve Bennett <stevagewp at gmail.com> wrote:
> On 8/29/06, Andrew Gray <shimgray at gmail.com> wrote:
> > Jellyfish wasn't on the list at all last night; the statistics are
> > sampling (I think) one in five thousand pageviews, so it's quite
> > likely a glitch. They've only been running for a couple of days, and
> > I'd strongly advise against treating them as reliable until at least a
> > fortnight in.
>
> The sampling period is, from my observation, constantly being
> decreased. It was 5000, then 1000, then 500, now 333. Well, I'm
> guessing just looking at what numbers have turned up at different
> times.

You can see what I believe is the sampling period by looking at
[[MediaWiki:monobook.js]]; it's currently 5000, and hasn't been lower
than 3000.

> However, I can't see why Irukandji jelly fish would be so high. It's
> not linked from anything, it's not in the news, and it's not even
> jellyfish season in Queensland. It could just be a statistical
> anomaly, or perhaps someone is deliberately messing with the stats?

I'm betting on anomaly.

> > That said... JonBenet Ramsay is interesting - it surged last night and
> > with no link from the front page. Interesting to see how quickly our
> > use (apparently) reacts to news stories. The sex-related ones - lists
> > of porn stars etc - were consistently high and are now dropping; I
> > wonder where they'll stabilise at.
>
> Yes, that trend is interesting - why did they all show up so high then
> disappear. Was it a time of day thing? More stats required!! :)
>
> I really hope we will end up with "last 24 hours" and "last 7 days" stats.

It looks like it's designed to work month-by-month - I'm not sure how
reliable the figures would be at smaller "resolutions". Best ask
Leon...

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


from_name: Alphax (Wikipedia email)

subject: [WikiEN-l] OT gmail spam increase?

body:
Mark Ryan wrote:
> I get precisely 45 spam messages a day, but Gmail catches almost all of them.
>

If you want some of my old ones, just ask... :)

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

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


subject: [Foundation-l] How I should consider GFDL in shared content?

body:
Jeff V. Merkey wrote:
> Brion Vibber wrote:
>> Robert Scott Horning wrote:
>>> There are a few bugs with the page import, but those few bugs can be
>>> usually compensated for by compitent administrators.
>>>
>>>
>> Please report these bugs... :)
>>
> importDump is busted in 1.7.1 (fails on NULL revision history).  I
> already reported it over on mediawiki.  Have not seen any fix for it yet.

I already gave you directions on this by private email, and you thanked me for
the help. So, I assume you are in fact aware of this issue and how to correct it.

If there is some other issue which is different from the one you already asked
me about and which I already helped you with, please go to
http://bugzilla.wikimedia.org/ and submit a bug report including details of
which files you're using, how you're using them, your configuration, the exact
error message and exact directions on how to reproduce it.

Please don't continue this discussion in foundation-l, where it is offtopic and
will unnecessarily clutter things and cause raised tempers. I will not make any
further replies in this thread.

-- brion vibber (brion @ pobox.com)

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


body:
Jeff V. Merkey wrote:
> Brion Vibber wrote:
>> Robert Scott Horning wrote:
>>> There are a few bugs with the page import, but those few bugs can be
>>> usually compensated for by compitent administrators.
>>>
>>>
>> Please report these bugs... :)
>>
> importDump is busted in 1.7.1 (fails on NULL revision history).  I
> already reported it over on mediawiki.  Have not seen any fix for it yet.

I already gave you directions on this by private email, and you thanked me for
the help. So, I assume you are in fact aware of this issue and how to correct it.

If there is some other issue which is different from the one you already asked
me about and which I already helped you with, please go to
http://bugzilla.wikimedia.org/ and submit a bug report including details of
which files you're using, how you're using them, your configuration, the exact
error message and exact directions on how to reproduce it.

Please don't continue this discussion in foundation-l, where it is offtopic and
will unnecessarily clutter things and cause raised tempers. I will not make any
further replies in this thread.

-- brion vibber (brion @ pobox.com)

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


body:
Jeff V. Merkey wrote:
> Brion Vibber wrote:
>> Robert Scott Horning wrote:
>>> There are a few bugs with the page import, but those few bugs can be
>>> usually compensated for by compitent administrators.
>>>
>>>
>> Please report these bugs... :)
>>
> importDump is busted in 1.7.1 (fails on NULL revision history).  I
> already reported it over on mediawiki.  Have not seen any fix for it yet.

I already gave you directions on this by private email, and you thanked me for
the help. So, I assume you are in fact aware of this issue and how to correct it.

If there is some other issue which is different from the one you already asked
me about and which I already helped you with, please go to
http://bugzilla.wikimedia.org/ and submit a bug report including details of
which files you're using, how you're using them, your configuration, the exact
error message and exact directions on how to reproduce it.

Please don't continue this discussion in foundation-l, where it is offtopic and
will unnecessarily clutter things and cause raised tempers. I will not make any
further replies in this thread.

-- brion vibber (brion @ pobox.com)

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


body:
Jeff V. Merkey wrote:
> Brion Vibber wrote:
>> Robert Scott Horning wrote:
>>> There are a few bugs with the page import, but those few bugs can be
>>> usually compensated for by compitent administrators.
>>>
>>>
>> Please report these bugs... :)
>>
> importDump is busted in 1.7.1 (fails on NULL revision history).  I
> already reported it over on mediawiki.  Have not seen any fix for it yet.

I already gave you directions on this by private email, and you thanked me for
the help. So, I assume you are in fact aware of this issue and how to correct it.

If there is some other issue which is different from the one you already asked
me about and which I already helped you with, please go to
http://bugzilla.wikimedia.org/ and submit a bug report including details of
which files you're using, how you're using them, your configuration, the exact
error message and exact directions on how to reproduce it.

Please don't continue this discussion in foundation-l, where it is offtopic and
will unnecessarily clutter things and cause raised tempers. I will not make any
further replies in this thread.

-- brion vibber (brion @ pobox.com)

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


from_name: jayjg

body:
It appears that Russian Wikipedia is about to reject Verifiability as a policy:

http://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%93%D0%BE%D0%BB%D0%BE%D1%81%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F/%D0%9F%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D0%B5%D0%BC%D0%BE%D1%81%D1%82%D1%8C

Verifiability is usually considered one of the 3 core content policies
on English Wikipedia.

This leads to a question; must the different Wikipedias have the same
core policies? Could Russian Wikipedia do away with NPOV and NOR as
well?  Could some other language Wikipedia do away with WP:CIVIL,
etc.?

Jay.


from_name: Rob Church

body:
On 29/08/06, Steve Bennett <stevage at gmail.com> wrote:
> On 8/29/06, Chuck Smith <chuckssmith at gmail.com> wrote:
> > During WikiSym, we (Christoph Sauer, Janne Jalkanen, Ward Cunningham
> > and I) held a five-hour workshop where we agreed on a new common wiki
> > markup based on looking at the markup of popular wikis as well as
>
> What are the popular wikis?

Project-wise, I'm thinking WardsWiki, MeatBall, Wikipedia, etc. - the
large, well-known ones, and the ones that were around first.

Engine-wise, that'd be UseModWiki, MediaWiki, MoinMoin and other
similar solutions.

Rob Church


body:
On 8/29/06, jayjg <jayjg99 at gmail.com> wrote:
> It appears that Russian Wikipedia is about to reject Verifiability as a policy:
http://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%93%D0%BE%D0%BB%D0%BE%D1%81%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F/%D0%9F%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D0%B5%D0%BC%D0%BE%D1%81%D1%82%D1%8C

It would be useful if someone could translate some of this for those
of us who do not read russian.


from_name: Yuri Astrakhan

subject:
[Wikitech-l] [MediaWiki-CVS] SVN: [16217]
	trunk/phase3/includes/SpecialDisambiguations.php

body:
Rob, thanks for the heads up on the release notes (although it is not a
breaking functionality - the original format of the message will continue to
work).
As for the DB -- the case almost never happens (you always have a disambig
template listed), plus its a batch process, so it does not get run very
often. Lastly, the way the QueryPage class is structured, I did not see an
easy way to return an empty result without calling the server.

Where do we keep the release notes?

--Yurik

On 8/25/06, Rob Church <robchur at gmail.com> wrote:
>
> On 25/08/06, yurik at svn.leuksman.com <yurik at svn.leuksman.com> wrote:
> > Revision: 16217
> > Author:   yurik
> > Date:     2006-08-24 21:32:33 -0700 (Thu, 24 Aug 2006)
> >
> > Log Message:
> > -----------
> > * Now [[MediaWiki:Disambiguationspage]] may have either disambig
> template name, or a list of links to disambig templates.
>
> For what purpose?
>
> > +        if( $set === false ) {
> > +            $set = 'FALSE';  # We must always return a valid sql query,
> but this way DB will always quicly return an empty result
>
> Don't issue the SELECT at all in that case, it's a waste of a database
> connection.
>
> You didn't update the release notes. This is a change which will
> affect the user's use of that message, plus the behaviour of the page;
> the release notes MUST be updated.
>
>
> Rob Church
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


from_name: Simetrical

body:
On 8/29/06, Yuri Astrakhan <yuriastrakhan at gmail.com> wrote:
> Where do we keep the release notes?

trunk/phase3/RELEASE-NOTES


from_name: Delirium

body:
jayjg wrote:

>It appears that Russian Wikipedia is about to reject Verifiability as a policy:
>
>http://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%93%D0%BE%D0%BB%D0%BE%D1%81%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F/%D0%9F%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D0%B5%D0%BC%D0%BE%D1%81%D1%82%D1%8C
>
>Verifiability is usually considered one of the 3 core content policies
>on English Wikipedia.
>
>This leads to a question; must the different Wikipedias have the same
>core policies? Could Russian Wikipedia do away with NPOV and NOR as
>well?  Could some other language Wikipedia do away with WP:CIVIL,
>etc.?
>
>
If they're core policies, then no; the Wikimedia Foundation is committed
to supporting certain types of projects, not to generally supporting any
project that a group of people want to have.

WP:CIVIL is probably more borderline, because it's more about internal
dynamics of the community than about the encyclopedia.  Presumably all
communities will come up against issues of civil behavior, but I'd be
inclined to let them decide how to formulate policies to deal with
them.  But we can't support an encyclopedia project under the
"Wikipedia" name that isn't neutral and based on existing, cited sources.

-Mark


from_name: Steve Bennett

subject: [WikiEN-l] Colbert on the loose

body:
On 8/29/06, Cheney Shill <halliburton_shill at yahoo.com> wrote:
> While looking over this myself, I found a sourced article referring to a specific wildlife area where the elephant population had tripled, so having an automated search & replace isn't the answer.  OTOH, if the software can be told to watch for

Yeah I found that too - Kruger Park (and I was very skeptical about
the reference at first - can you believe it, too many elephants,
culling needed!) Definitely not search & replace, but an automated
search & flag would be useful.

The bigger worry is when we can't search and replace because the
nature of the change is too vague. "Everyone go and change some random
dead person to having married just before their death".

I do note, however, that there have been several uncoordinated
responses. Some links:

http://en.wikipedia.org/wiki/User:Centrx/Colbert (probably the most
authoratitive?)
http://en.wikipedia.org/wiki/User:Harmil
http://en.wikipedia.org/w/index.php?title=Talk%3AElephant&diff=67362078&oldid=67361780
(call to arms)
http://en.wikipedia.org/wiki/Wikipedia:Wikiality_and_Other_Tripling_Elephants

A simple centralized "mass vandalism" page would be a great place to
handle these attacks. People could list all the instances they find,
categorised as Centrx did, into high and low frequencies, facilitating
the task of monitoring them.

Steve


subject: [WikiEN-l] Colbert on the loose

body:
Oh, http://en.wikipedia.org/wiki/Wikipedia:Dealing_with_coordinated_vandalism
is also a start.

Steve

On 8/29/06, Steve Bennett <stevagewp at gmail.com> wrote:
> On 8/29/06, Cheney Shill <halliburton_shill at yahoo.com> wrote:
> > While looking over this myself, I found a sourced article referring to a specific wildlife area where the elephant population had tripled, so having an automated search & replace isn't the answer.  OTOH, if the software can be told to watch for
>
> Yeah I found that too - Kruger Park (and I was very skeptical about
> the reference at first - can you believe it, too many elephants,
> culling needed!) Definitely not search & replace, but an automated
> search & flag would be useful.
>
> The bigger worry is when we can't search and replace because the
> nature of the change is too vague. "Everyone go and change some random
> dead person to having married just before their death".
>
> I do note, however, that there have been several uncoordinated
> responses. Some links:
>
> http://en.wikipedia.org/wiki/User:Centrx/Colbert (probably the most
> authoratitive?)
> http://en.wikipedia.org/wiki/User:Harmil
> http://en.wikipedia.org/w/index.php?title=Talk%3AElephant&diff=67362078&oldid=67361780
> (call to arms)
> http://en.wikipedia.org/wiki/Wikipedia:Wikiality_and_Other_Tripling_Elephants
>
> A simple centralized "mass vandalism" page would be a great place to
> handle these attacks. People could list all the instances they find,
> categorised as Centrx did, into high and low frequencies, facilitating
> the task of monitoring them.
>
> Steve
>


from_name: Aphaia

subject: [Foundation-l] Fwd: Hadraj Said

body:
Salut,
merci pour ton aide, guillom, je pense que nous (Officiales
d'Election) n'avons pas besoin de vous demander plus travail. J'ai
connu la situation, et espere la bonne sante pour Hadraj.

Tres cordialement,

---
Hello,
thank you for your help, Guillom. I think we Election Official don't
need to bother you more. I understand the situation, and hope a good
health for Hadraj,
Sincerely,

On 8/29/06, Guillaume Paumier <guillom.pom at gmail.com> wrote:
> Hello,
>
> As Hadraj can't speak English, I am sending this email for him.
> Hadraj has decided to withdraw his candidacy to the Board for health
> reasons.
>
> g.
>
>
>
> ---------- Forwarded message ----------
> From: said hadraj <hadraj_said at yahoo.fr>
> Date: Aug 28, 2006 11:04 PM
> Subject: Hadraj Said
> To: guillom.pom at gmail.com
>
> Bonsoir
> Je vous remercie fort bien pour vore collaboration,je vous informe que je
> retire ma candidature pour des raisons de sant? .
> Mrci
> cordialement
>
>
> Hadraj Said
>
> ------------------------------
> D?couvrez un nouveau moyen de poser toutes vos questions quelque soit le
> sujet ! Yahoo! Questions/R?ponses pour partager vos connaissances, vos
> opinions et vos exp?riences. Cliquez
> ici<http://fr.rd.yahoo.com/evt=42054/*http://fr.answers.yahoo.com>.
>
>
>
>
> --
> Guillaume Paumier
> Disciplus Simplex
> http://fr.wikipedia.org : Resistance is futile ? You will be assimilated.
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>

--
Kizu Naoko
  Wikiquote: http://wikiquote.org
  * vivemus, mea Lesbia, amemus *


subject: [Foundation-l] Fwd: Hadraj Said


body:
On 8/29/06, geni <geniice at gmail.com> wrote:
> On 8/29/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> > It would be useful if someone could translate some of this for those
> > of us who do not read russian.
>
> as far as I can figure out from machine translations the policy has
> recently been translated from English and they are now trying to get
> community approval. Most of the opposition appears to be from those
> who think it is over ridged and that cites should only need to be
> provided in cases where something has been challanged.

This is the practice on enwiki in any case. Cites are recommended but
not mandatory unless there is a dispute.  Here we have an example of
where the complex real policy mismatching the clearly stated written
policy is causing problems.


subject: [Wikitech-l] Disabling users

body:
Thank you so much.  Thats work perfectly.  Saved me a huge amount of time.
We see only one drawback which should be easy enough to fix.  When a user
logs in, if they dont have "reader" access they get an error message saying
"Login Required."  We plan to override the message and say "Access Denied."

Regards!

Dion

>From: "George Herbert" <george.herbert at gmail.com>
>Reply-To: Wikimedia developers <wikitech-l at wikimedia.org>
>To: "Wikimedia developers" <wikitech-l at wikimedia.org>
>Subject: Re: [Wikitech-l] Disabling users
>Date: Tue, 29 Aug 2006 14:47:15 -0700
>
>Have you tried:
>
>Create a new group "readers", with "read" userright.
>Disable "read" rights for "users" group.
>Put your open content in the $wgWhitelistRead variable (login, main pages,
>etc); make sure anything sensisitve isn't in $wgWhitelistRead.
>To "activate" a new account, a burecrat has to add them to group "readers".
>To "deactivate" a new account, a burecrat removes them from group
>"readers".
>
>
>See:
>http://meta.wikimedia.org/wiki/Help:User_rights
>LocalSettings.php
>includes/DefaultSettings.php
>
>
>I haven't tested this quite yet, but was going to this week for an internal
>corporate MediaWiki I'm running.
>
>If it doesn't work, let me know, so I can figure something else out.  8-)
>
>
>--
>-george william herbert
>george.herbert at gmail.com
>_______________________________________________
>Wikitech-l mailing list
>Wikitech-l at wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikitech-l


from_name: Kirill Lokshin

body:
On 8/29/06, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On 8/29/06, jayjg <jayjg99 at gmail.com> wrote:
> > It appears that Russian Wikipedia is about to reject Verifiability as a policy:
> http://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%93%D0%BE%D0%BB%D0%BE%D1%81%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F/%D0%9F%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D0%B5%D0%BC%D0%BE%D1%81%D1%82%D1%8C
>
> It would be useful if someone could translate some of this for those
> of us who do not read russian.

It's a bit too long to translate entirely (and some of it seems to be
people settling personal scores -- oppose because so-and-so supports
and that sort of thing), but here's a sampling of the opposes:

"Bureaucracy = evil" -- ??????

"Don't see the point.  These rules are too obvious (on the level of
being fundamental principles of Wikipedia), and are thus simply
extraneous" -- Edward???

"Without a strict understanding of 'authoritative source', the rule is
useless and perhaps even harmful" -- Jannikol

"Our deletionist activists will start to remove the contents of the
encyclopedia at a very rapid pace.  The {{citation needed}} template
is quite sufficient" -- ???

"Forbidding original research will be enough, in my opinion.  Extra
disputes and bureaucracy won't lead to anything good" -- Terminus

"And what am I supposed to do if my source is a paper book?" -- ?? ????????????

"The assertion that verifiability is more important than truth seems
disputable.  And furthermore, to create the ideal article, we need to
study the actual thing, not stories about it in 'authoritative
sources'" -- Fred

"According to this rule, I cannot, for example, write about something
which I saw with my own eyes..." -- Azh7

(I haven't read the actual policy yet; I wonder how close it is in
meaning to the English one.)

--
Kirill Lokshin


from_name: David Gerard

body:
See WT:LIVING, discussion at end. The "nutshell" has been
instruction-crept by the well-meaning and is an obfuscated mess.

Key problem: the innovation of "sensitivity" which was introduced as a
fresh new thing in this guideline. While it seems the proper and human
thing to be sensitive to living persons, the use of the term in that
form does pretty much subvert the NPOV "hard policy" in the wording of
a secondary guideline<->policy.

I appreciate the need, but there's gotta be a way to word it that
doesn't seem like an end-run around NPOV.

Idea: the thing already in about notability of life details. That
would seem to me to cover it.

Any more ideas?

- d.


from_name: Chuck Smith

body:
During WikiSym, we (Christoph Sauer, Janne Jalkanen, Ward Cunningham
and I) held a five-hour workshop where we agreed on a new common wiki
markup based on looking at the markup of popular wikis as well as
deciding what would be intuitive.  Our conclusion was not to replace
wiki markup, but rather to provide an alternative way to edit wikis,
so that visitors of a new wiki engine will feel more welcome. Several
wiki engines have agreed to jump on board (including MediaWiki and the
Ward's original WikiWikiWeb).

Although we do not say how to implement Creole for a particular wiki
engine, two possibilities would be to have a separate edit button,
using placeholders to hide advanced native wiki markup from users or
if possible to have a mixed edit where users could use Creole as well
as native markup which would then be translated to the native markup.

We have set up the WikiCreole wiki (www.wikicreole.org) to continue
the discussion and work.  We would be interested to know what you
think and to hear from you if you would also like to add Creole
support to your wiki.

Starting points:
- http://www.wikicreole.org/
- http://www.wikicreole.org/wiki/AllMarkup
- http://www.wikicreole.org/wiki/Engines

Best wishes,
Chuck


from_name: Sydney aka FloNight

body:
---- Matt Brown <morven at gmail.com> wrote:

=============
On 8/29/06, David Gerard <dgerard at gmail.com> wrote:
> Our pop culture articles are rubbish, and they definitely need no more
> encouragement toward a hagiographic point of view.

Very much agreed.  I am very against any suggestion that strongly
sourced, accurate negative information that is relevant to the
person's notability/notoriety should be removed from articles for
'sensitivity'.

I am in favor of being very tough about the 'well sourced' part,
though, and about the notability of life details.  Not everything
about their private lives that has been e.g. dragged out in divorce
court is really notable.

-Matt
=====================================================
Matt and David,

Matt's comment is the intent of the BLP policy with the inclution of sensitivity theme.

IO, being sensitive to the fact that details about a living person's life can cause harm, editors need to be very sure that the information is notable, relevant, and verifiable.
When in doubt error on the side of do no harm. This in no way says that all criticism or negative should be removed from articles.

Sydney aka FloNight


body:
On 8/29/06, Chuck Smith <chuckssmith at gmail.com> wrote:
> During WikiSym, we (Christoph Sauer, Janne Jalkanen, Ward Cunningham
> and I) held a five-hour workshop where we agreed on a new common wiki
> markup based on looking at the markup of popular wikis as well as

What are the popular wikis?

Steve


body:
On 29/08/06, Jay R. Ashworth <jra at baylink.com> wrote:
> *Puhleeze*?  (and you might want to put the obligatory companion "Log
> me in?" "Remember me?" and "Don't ever remember anyone, this is a
> public computer" check boxes, though perhaps that's too much...)

"Puhleeze"? You can't submit a patch? ;)

Rob Church


body:
On 29/08/06, [LiM] Manop <manop at 6tub1.com> wrote:
> Hello,
>
> I'm wondering if anyone have the same problem. Several of my friends in
> Thailand cannot access to Thai Wikipedia (http://th.wikipedia.org) today
> since 4-5 hours ago. But I access from the USA, it works fine for me.

Is it just th.wikipedia, or other language sites as well?

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


subject:
[Foundation-l] Swahili Machine Translation First Run Completed
	for enwiki-20060817

body:
Generally machine translation creates nothing but a mess.
Swwiki has a good community even small - five active contributors and
they are in progress. They have also a good relation to local media, I
heard from one of them.

They know to write what they want to describe. They will translate
some articles from somewhere, but it is apparently nonsense "English
Wikpedia can be transfeered to anywhere without local community
consent".

If you disturb them without any negotiation with them, so you will
know how the global Wikimedia community can react public enemy at that
time, at least what rage and fury of Britomartis will be.

Sincerely,

On 8/29/06, Jeffrey V. Merkey <jmerkey at wolfmountaingroup.com> wrote:
>
> The first pass machine translation run of the English Wikipedia into the
> Swahili Language has completed and is posted.
> The translated XML dumps are posting to :
>
> http://sw.wikigadugi.org
>
> they will post throughout the night.
>
> Lexicons can be downloaded from:
>
> ftp://www.wikigadugi.org/africa/lexicon/swlexicon.public.bz2  - public
> swahili lexicon
> ftp://www.wikigadugi.org/africa/lexicon/swlexicon.kamusi.bz2 - kamusi
> project lexicon
> ftp://www.wikigadugi.org/africa/lexicon/sw.thesaurus.bz2 - rogets
> thesaurus in swahili
>
> MediaWiki Messages Files:
>
> ftp://www.wikigadugi.org/africa/MediWiki/MessagesSW.php.bz2
>
> Machine Translated XML Dumps against the ewiki-20060817 XMl Dumps from
> the English Wikipedia:
>
> ftp://www.wikigadugi.org/africa/xml/swphwiki-20060816-pages-articles.xml.bz2
>
> This first run does NOT employe the verb stem decomposer and conjugator,
> does NOT employ the grammar parser or sentence composer, does NOT
> employ the AI Inference engine, and does not perform verb or noun
> disambiguation as do the other machine translations as I have not
> constructed
> a decomposition rule set or grammar rules set for the translator.  This
> first run uses simple word by word translation and phrase matching with
> hierarchical
> thesaurus lookups and substitution.
>
> This first pass is provided as an illustration of just how rapidly
> Wikipedia can be translated into a target language.  A swahili grammar
> manual has been
> overnighted to me and later this week I will perform another run with
> grammar and sentence parsing rules.  Since I am not a native speaker of
> swahili, I request a native speaker to select 20 or more very long
> articles and correc them.  When I completed the disambiguator and
> grammar rules
> set for sentence construction, I will use the corrected articles to
> teach the AI engine how to reorder and retense the translations.  This
> should get
> the translations over 90% accurracy.  Unlike Cherokee, swahili appears
> to be a much simpler language for this task.
>
> The Machine translation of swahili is a VERY early first run and is a
> work in progress.
>
> Jeffrey V. Merkey
>
>
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>

--
Kizu Naoko
  Wikiquote: http://wikiquote.org
  * vivemus, mea Lesbia, amemus *


subject: [Wikitech-l] Wikitech-l Digest, Vol 37, Issue 125

body:
> What are the popular wikis?

http://www.wikicreole.org/wiki/WikiPopularity

Chuck


subject: [Wikitech-l] Categories problem

body:
On 29/08/06, Steve Bennett <stevage at gmail.com> wrote:
> How would you know? How can you test if the parser can parse something
> if every time you try and save it, mediawiki converts it into
> something else?

The pedantic response: Special page extension or otherwise; pass it
direct into the parser without going via a pre-save transform.

Rob Church


subject:
[Wikitech-l] [MediaWiki-CVS] SVN: [16269]
	trunk/phase3/includes/SpecialDisambiguations.php

body:
On 29/08/06, yurik at svn.leuksman.com <yurik at svn.leuksman.com> wrote:
> Revision: 16269
> Author:   yurik
> Date:     2006-08-29 09:51:11 -0700 (Tue, 29 Aug 2006)
>
> Log Message:
> -----------
> * Ordered the query results by disambiguation page title

Yurik, you still haven't updated the release notes to reflect that the
format of the "disambiguationpages" message has changed. Hint hint,
cough cough, etc. :)

Rob Church