from_name: Chong Yidong

subject: [Wikitech-l] File upload borked

body:
On the English Wikipedia, I have been trying to upload the latest
version of wikipedia-mode.el, an Emacs lisp mode for editing wikipedia
articles. After submitting the file, I end up at a page that says
"Warning: .el is not a recommended file format". There used to be two
buttons underneath this, labelled "Upload anyway" and "Cancel", but
these have disappeared, which means I'm no longer able to proceed.

Can someone fix this?

-- CYD


list: foundation-l

source: pipermail-mbox

from_name: Andrew Lih

subject: [Foundation-l] Stories of WP

body:
On Wed, 29 Sep 2004 19:43:35 +0100, Rowan Collins
<rowan.collins at gmail.com> wrote:
> Well, he did say "outside of US/Europe", which must put a pretty big
> dent in English. And both English and Spanish, are technically
> speaking, European languages, so his second paragraph is probably
> technically accurate, from a pedantic point of view.

Right, I consider English and Spanish as having European roots.

> But especially with Spanish, you do have a point: I wonder how
> many South American contributors we have there (and what of
> Brazillian Portugese?)...

Yes, this is what I would like more stories about, and maybe some
numbers about how many Latin American users we have now. There should
be a fair number of Brazilians, since the threat of a Portuguese
language split was an issue recently. But I just don't know much about
the Spanish speaking WP community.

--
Andrew Lih
andrew.lih at gmail.com


list: wikimedia-l

subject: [Foundation-l] Stories of WP


list: wikitech-l

from_name: Angela

subject: [Wikitech-l] Wikidown message - again

body:
On Wed, 29 Sep 2004 11:16:52 -0700 (PDT), Daniel Mayer
<maveric149 at yahoo.com> wrote:
> ''Please'' create a static copy of the old fundraising page
> and link to that from a failsafe server.

There's a static version at WikiSearch.
http://www.wikisearch.org/wikimediafundraising.htm

It's based partly on the old fundraising page to avoid the need to
keep copies of dozens of templates up to date. I haven't done
non-English versions yet, but will do at some point.

Angela.


list: wikien-l

from_name: Poor, Edmund W

subject: [WikiEN-l] A plea - live and let live

body:
If there are a dozen or 6 dozen separate, tiny articles with a common
theme, then why not:

* Copy the text of each article into one new comprehensive article (like
[[List of Apprentice contestants]]
* Turn the text of each old article into:  #REDIRECT [[List of
Apprentice contestants]]

This is how Maveric asked me to handle the Simpsons, way back when...

Ed Poor
"very good, always helps"    <--- 40 WikiBonus points if u can ID this
quote

> -----Original Message-----
> From: Andrew Lih [mailto:andrew.lih at gmail.com]
> Sent: Wednesday, September 29, 2004 8:42 PM
> To: English Wikipedia
> Subject: Re: [WikiEN-l] A plea - live and let live
>
>
> On Thu, 30 Sep 2004 07:31:33 +1000, David Carson
> <david at hemiware.com> wrote:
> > Mark Richards wrote:
> >
> > That's a fairly large misstatement of the actual situation, seeing
> > that virtually all of the "over 70 new listings" are a list
> of over 70
> > esoteric programming languages listed for VFD by one person.
>
> Note that over a dozen entries on VfD were "The Apprentice"
> contestants, added in one big shot. As Wikipedia's popularity
> grows, the listing on VfD will too.
>
> -Andrew (User:Fuzheado)
>
>


subject: [WikiEN-l] Censorship by vfd

body:
See my post at
http://en.wikipedia.org/w/wiki.phtml?title=Wikipedia:Votes_for_deletion/
We_believe_in_human_dignity&action=edit&section=1

Jongarrettuk, David Remahl, Benc, Neutrality, and Mikkalai have "voted"
to delete this short article (which I wrote) because it's "Non-notable
political propaganda".

I beg to differ. It's one of the 3 most significant speeches of George
W. Bush's career, and if it's propaganda then we SHOULD have an article
in which some political expert SAYS it's propaganda.

I suspect the motive to "delete" is really censorship, i.e., the desire
to make it harder for Wikipedians to find out what Bush is saying about
world affairs. Part of this dovetails with the Kerry campaign's POV, the
constant refrain that Bush has nothing of substance to say about Iraq or
anything else for that matter.

A major service Wikipedia provides is to bring hidden facts to light. If
one politician says "My opponent A has NEVER spoken about X", then it
can make a big difference to our readers whether a quick Wikipedia
search turns up:

* nothing by A about X, or
* an obscure reference by A about X, or
* a public speech by A to a major world body about X

Maybe the article should be moved to a more bland title. Instead of "We
believe in human dignity", call it [[George Bush speech at the United
Nations on September 21, 2004]]

... Or whatever our naming convention is for speeches.

Ed Poor


from_name: David Carson

subject: [WikiEN-l] A plea - live and let live

body:
Mark Richards wrote:

>Deletion seems to have stepped up a gear recently,
>with over 70 new listings just today. Is it just me,
>or is this spiralling out of control? Most of these
>are verifiable things that folks don't think are
>'notable'.
>
>

That's a fairly large misstatement of the actual situation, seeing that
virtually all of the "over 70 new listings" are a list of over 70
esoteric programming languages listed for VFD by one person.

And given that the vote is overwhelmingly to KEEP them at the moment,
I'm not sure what exactly is "spiralling out of control".

My suggestion: calm down, and if a user is repeatedly submitting
articles for VFD for which the consensus is to keep, have a quiet word
to them about it.

Now, as always, if you ignore huge statistic-skewing events like these
esoteric programming languages, most of the stuff which is listed on VFD
is deleted, by near-unanimous consent, because it simply does not fit
the community standards of what Wikipedia is for.

Cheers!
David...


from_name: Anthony DiPierro

subject: [WikiEN-l] "Editorial purposes only" images

body:
> But we already incorporate fair use images. It's not fair use to uses
> someone's image to advertise your product - so what's theproblem with
> this licence?

> Theresa

I agree.  As long as the image is usable in a commercial mirror, I think we
should allow it.  Since Wikimedia refuses to define freeness itself, I'll go
to http://www.gnu.org/encyclopedia/free-encyclopedia.html.  This page says
that a free encyclopedia requires permission of modification of images, but
the examples it gives are related to editorial modifications.  I think this
license is well within the spirit of this definition.

> The problem is that one (for-profit) publisher of wikipedia which is not
> the wikimedia foundation could say: "hey, look what terrific
> images we have got in this publication"... And AFAIK that
> goes against that very license.

> Theresa

Seems to me that this would go against the license even if it was a
non-profit publisher doing that.  But I don't see the big deal.  The
publisher can just use a different image for eir ad.

> GFDL implies absolute freedom or nothing at all. In this spirit,
> Richard Stallman had two or three interventions in this mailing list
> some months ago.

I think you're thinking of public domain, not GFDL.  GFDL is not absolute
freedom.  Furthermore, we haven't committed ourselves to the GFDL, only the
spirit of the GFDL.

> But IANAL (and probably those images are not THAT terrific though :)

I'm not a lawyer either, so I'm relying on Jimmy Wales' assertion that
mixing *any* image with GFDL text is legally permitted.  The question here
is whether or not we *should* use these images, not whether or not we
legally *can* use them.

> Pedro.

Anthony


from_name: Thomas R. Koll

subject: [Foundation-l] Stories of WP

body:
On Thu, Sep 30, 2004 at 12:01:15AM +0800, Andrew Lih wrote:
> I'll be talking to the BBC tomorrow about Wikipedia, and they're also
> interested in stories about Wikipedia outside of US/Europe.
>
> Of the top 20 languages, only Chinese and Japanese are non-European.
> However, if anyone can point me to some interesting stories regarding
> users in developing countries or how Wikipedia is used in unusual
> ways,  please let me know.

Maybe not excactly what you want, but on de: we have a group of
Swiss pupils (age 15-17) who wrote a lot about the small island-country of
Nauru making it to the maybe best described country in Wikipedia.
They also start to translate their articles to English.

http://de.wikipedia.org/wiki/Portal_Nauru
http://de.wikipedia.org/wiki/Kategorie:Nauru
http://de.wikipedia.org/wiki/Benutzer:CdaMVvWgS - the group of pupils

ciao, tom
--
== Weblinks ==
* http://shop.wikipedia.org - WikiReader Internet zu kaufen
* http://de.wikipedia.org/wiki/Benutzer:TomK32
* http://www.hammererlehen.de - Urlaub in Berchtesgaden


subject: [Foundation-l] Stories of WP


subject: [WikiEN-l] A plea - live and let live

body:
On Thu, 30 Sep 2004 07:31:33 +1000, David Carson <david at hemiware.com> wrote:
> Mark Richards wrote:
>
> That's a fairly large misstatement of the actual situation, seeing that
> virtually all of the "over 70 new listings" are a list of over 70
> esoteric programming languages listed for VFD by one person.

Note that over a dozen entries on VfD were "The Apprentice"
contestants, added in one big shot. As Wikipedia's popularity grows,
the listing on VfD will too.

-Andrew (User:Fuzheado)


from_name: KNOTT, T

body:
>>  On the other
>> hand, it's a less free license than many we use.

<snip> but since to
>comply with our existing licencing obligations it would mean offering
>two copies of the database, I think anything that cannot be
>distributed under the GFDL should be avoided.

But we already incorporate fair use images. It's not fair use to uses
someone's image to advertise your product - so what's theproblem with
this licence?

Theresa


subject: [WikiEN-l] Anti-Israeli bias in Current Events

body:
The following news story has an anti-Israeli bias:

:Two Palestinians are killed by Israeli troops returning fire after an
Israeli soldier was killed at an observation post in the northern Gaza
strip. The troops have been engaged in that part of the northern Gaza
Strip since yesterday, September 29. (September 30 Current Events in
Wikipedia)

1. It downplays the killing of the Israeli soldier
2. It does not clarify whether the "Palestinians" who were killed, were
armed (although "returned fire" implies this)
3. It seems designed to give the impression that Israel is conducting a
campaign of indiscriminate slaughter.

If some advocate believes that Israel is killing "Palestinians" without
concern for international law or moral considerations, we should include
a comment attributed to that source, like:

* "This is another example of Israel's indiscriminate slaughter of
freedom-loving Palestinians. Those hypocrites say they love democracy,
but they don't even respect elementary human rights," said Mustapha al
Fahda, leader of the [[Alliance for Palestinian Democracy]].

I think the best way to describe armed violence is to mention who fired
the first shot, like this:

* An Israeli soldier is killed at an observation post in the northern
Gaza strip. Israeli troops returned fire, killing two Palestinians.

Please think carefully about the impression your writing makes, and try
hard to avoid letting bias creep in.

Ed Poor


from_name: Pedro Fortuny Ayuso

body:
The problem is that one (for-profit) publisher of wikipedia which is not
the wikimedia foundation could say: "hey, look what terrific
images we have got in this publication"... And AFAIK that
goes against that very license.

GFDL implies absolute freedom or nothing at all. In this spirit,
Richard Stallman had two or three interventions in this mailing list
some months ago.

But IANAL (and probably those images are not THAT terrific though :)

Pedro.

On Thu, 30 Sep 2004 09:41:14 +0100, KNOTT, T <tknott at qcl.org.uk> wrote:
>
>
> >>  On the other
> >> hand, it's a less free license than many we use.
>
>
> <snip> but since to
> >comply with our existing licencing obligations it would mean offering
> >two copies of the database, I think anything that cannot be
> >distributed under the GFDL should be avoided.
>
> But we already incorporate fair use images. It's not fair use to uses
> someone's image to advertise your product - so what's theproblem with
> this licence?
>
> Theresa
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

--
Pedro Fortuny Ayuso
Colegio Mayor Pe?afiel
C/Estudios 6. 47005 Valladolid. SPAIN
http://pfortuny.sdf-eu.org


from_name: Brion Vibber

subject: [Wikitech-l] Admin interface / user rights

body:
On Sep 30, 2004, at 10:15 AM, Magnus Manske wrote:
>> Finally, should I start it now for the 1.4 release or wait for a
>> later release ?
>
> Last I heard, time for 1.4-release is running out (Brion?).

I would like to go beta in mid-October, aiming for a Novemberish
release. I definitely want a stable 1.4.0 out by the end of the year...
If this stuff can be done fairly cleanly, please get started quickly so
the beta period isn't too upheaval-ish. :)

For reference, our past major releases have come roughly four months
apart:

August 29, 2003: MediaWiki-stable snapshot
December 8, 2003: 1.1.0
March 24, 2004: 1.2.0
August 12, 2004: 1.3.0

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040930/73a98d0e/attachment.pgp>


subject: [Wikitech-l] Why do I keep getting an out-of-date watchlist?

body:
On Sep 30, 2004, at 11:07 AM, Rowan Collins wrote:
> Over the last few days, I've had an intermittent problem where my
> watchlists on both w:en: and meta: come up as though I was loading the
> page a day or so ago. As in, it says "..the last X changes in the last
> 3 days" but then begins with "29 Sep 2004" and goes back from there.

This is probably due to one of the database slaves being behind in
replication. I believe it's being poked at...

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040930/1c38f4f4/attachment.pgp>


from_name: Rick

subject: [WikiEN-l] Censorship by vfd

body:
The title in and of itself is political advocacy, and the article is, as well.  It has nothing to do with "the desire
to make it harder for Wikipedians to find out what Bush is saying about
world affairs and all to do with whether the people who have listed it believe this is in fact an encyclopedia article.  But all of this should be discussed on the VfD page or the article's Talk page, and not here.

RickK

"Poor, Edmund W" <Edmund.W.Poor at abc.com> wrote:
See my post at
http://en.wikipedia.org/w/wiki.phtml?title=Wikipedia:Votes_for_deletion/
We_believe_in_human_dignity&action=edit?ion=1

Jongarrettuk, David Remahl, Benc, Neutrality, and Mikkalai have "voted"
to delete this short article (which I wrote) because it's "Non-notable
political propaganda".

I beg to differ. It's one of the 3 most significant speeches of George
W. Bush's career, and if it's propaganda then we SHOULD have an article
in which some political expert SAYS it's propaganda.

I suspect the motive to "delete" is really censorship, i.e., the desire
to make it harder for Wikipedians to find out what Bush is saying about
world affairs. Part of this dovetails with the Kerry campaign's POV, the
constant refrain that Bush has nothing of substance to say about Iraq or
anything else for that matter.

A major service Wikipedia provides is to bring hidden facts to light. If
one politician says "My opponent A has NEVER spoken about X", then it
can make a big difference to our readers whether a quick Wikipedia
search turns up:

* nothing by A about X, or
* an obscure reference by A about X, or
* a public speech by A to a major world body about X

Maybe the article should be moved to a more bland title. Instead of "We
believe in human dignity", call it [[George Bush speech at the United
Nations on September 21, 2004]]

... Or whatever our naming convention is for speeches.

Ed Poor

_______________________________________________
WikiEN-l mailing list
WikiEN-l at Wikipedia.org
http://mail.wikipedia.org/mailman/listinfo/wikien-l

---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!


subject: [WikiEN-l] Deletion policy and Kerry's Purple Heart medals

body:
I did a search for "kerry purple heart" and got nothing of significance.

http://www.google.com/search?domains=en.wikipedia.org&num=50&ie=iso-8859
-1&oe=iso-8859-1&q=kerry+purple+heart&btnG=Google+Search&sitesearch=en.w
ikipedia.org

Google quotes Wikipedia as saying:

:Hibbard and Elliot have alleged, respectively, that Kerry's first
Purple Heart and Silver Star were undeserved."

I don't see how this justifies creating a vote on "swift deletion" or
whatever they call their proposal to let 3 admins collaborate on
deleting a page.

1. There are too many admins. It would be very easy for a
politically-motivated clique to abuse an "admins only" vote and
eliminate political information merely because they don't want anyone to
read about it.

2. The best way to deal with political bias is to LABEL IT POV and WRITE
ABOUT IT. If Kerry opponents make an issue of his Purple Hearts, then
include some info about this in an article, or write an article about
the [[Kerry Purple Heart controversy]].

We have the ability to write neutrally on controversies. Deleting stuff
that one side doesn't want mentioned, is not the solution.

By the way, this is the 2nd "delete what makes Kerry bad or Bush good"
issue I've uncovered today. I see an unsettling trend.

We can write articles about Bush speeches or Swift Boat veterans'
claims, without censorship. Just as we can write articles about Bush
drunk driving or using privilege to evade combat or doctor's
appointments, or assigning huge contracts to his VP's former company --
without censorship.

Ed Poor
First Amendment Champion


from_name: Gerard Meijssen

subject: [Wikitech-l] Problem solving with sound

body:
Hoi,
One difference with pictures is, that when you save a screen with a
picture on it, you save the picture at the same time. When you save an
"image" with a sound, you do NOT save the sound at the same time. The
problem is that when people prepare their computer to use .ogg files.
One stage is to check if you can hear .ogg files locally. This means
that you have to HAVE an .ogg file.

Yesterday I mentioned that sounds being "Image"s for wikimedia is
counterintuitive, today I ask for  a Sound detail screens which has the
option to download the sound,

Thanks,
    GerardM


body:
What article are you talking about?  And when did this become the Ed Poor political advocacy mailing list?

RickK

"Poor, Edmund W" <Edmund.W.Poor at abc.com> wrote:
I did a search for "kerry purple heart" and got nothing of significance.

http://www.google.com/search?domains=en.wikipedia.org&num=50&ie=iso-8859
-1&oe=iso-8859-1&q=kerry+purple+heart&btnG=Google+Search&sitesearch=en.w
ikipedia.org

Google quotes Wikipedia as saying:

:Hibbard and Elliot have alleged, respectively, that Kerry's first
Purple Heart and Silver Star were undeserved."

I don't see how this justifies creating a vote on "swift deletion" or
whatever they call their proposal to let 3 admins collaborate on
deleting a page.

1. There are too many admins. It would be very easy for a
politically-motivated clique to abuse an "admins only" vote and
eliminate political information merely because they don't want anyone to
read about it.

2. The best way to deal with political bias is to LABEL IT POV and WRITE
ABOUT IT. If Kerry opponents make an issue of his Purple Hearts, then
include some info about this in an article, or write an article about
the [[Kerry Purple Heart controversy]].

We have the ability to write neutrally on controversies. Deleting stuff
that one side doesn't want mentioned, is not the solution.

By the way, this is the 2nd "delete what makes Kerry bad or Bush good"
issue I've uncovered today. I see an unsettling trend.

We can write articles about Bush speeches or Swift Boat veterans'
claims, without censorship. Just as we can write articles about Bush
drunk driving or using privilege to evade combat or doctor's
appointments, or assigning huge contracts to his VP's former company --
without censorship.

Ed Poor
First Amendment Champion
_______________________________________________
WikiEN-l mailing list
WikiEN-l at Wikipedia.org
http://mail.wikipedia.org/mailman/listinfo/wikien-l

---------------------------------
Do you Yahoo!?
vote.yahoo.com - Register online to vote today!


list: wikipedia-l

from_name: David Friedland

subject: [Wikipedia-l] Re: [Wikitech-l] Hyperlink convention

body:
Delirium wrote:
> Angela wrote:
>
>> One reason is that the differences between American and British
>> English are more involved than simply changing the spelling of a few
>> words. Punctuation and grammar are also involved. If you changed
>> behavior to behaviour in an otherwise AE sentence, the sentence would
>> then be wrong in both languages.
>
> I can't seem to find the page now, but I seem to remember a policy page
> where we've basically settled on a compromise, partially-invented
> "international English" punctuation style for clarity and because it's
> not really worth fighting over.  The compromise included the
> British-style "put punctuation _after_ closing quotation marks", and
> something from US style that I can't remember.  As for being "wrong",
> that's only the case if you happen to be a [[en:prescription and
> description|grammatical prescriptivist]], which not all of us are.
>
> But as far as the spelling issue goes, it seems like a solution in
> search of a problem.  The current approach seems to be working well enough.
>
> -Mark

I heartily disagree. The current approach is a constant source of
disagreement and worsening of linguistic tensions. I am always running
into minor tiffs over British vs American spelling that could be
eliminated with multi-dialect support. This would also mean that when I
run into a Britishism on an article that might be confusing or
misleading to an American reader, instead of changing it to an
Americanism and drawing the ire of the original author (or changing it
to something neutral and probably drawing the ire of the original
author), the original author's Britishism can stay, the Americanism will
be viewable to Americans, and everyone is a little bit happier.

I think that the minor increase in complexity for editing is far
outweighed by the increase in understandability, familiarity, and
dialectical consistency. As for syntactic differences between the
dialects, I have yet to see anything that differed by more than a
handful of words. Most of the major differences are in informal,
colloquial speech.

IBM {-en-us has en-gb have-} introduced several new products...

In sum, if the code is already being written to support a major case
(Chinese), it strikes me as perverse to not allow for minor cases like
English. If people want to do it, why not let them?

- David


from_name: Sean Barrett

body:
> True.  In American English, a list of 3 items is usually "bacon, eggs, and cheese" - not "bacon, eggs and cheese."  The later implies a connection between the items, but the former doesn't.

>From a book dedication:

I'd like to thank my parents, God and Ayn Rand.


list: wiktionary-l

from_name: cookfire

subject: [Wiktionary-l] Italie .... Italian Wiktionary

body:
Sabine Cretella schreef:

>
>>>
>>> So who is the one I need to talk to for the Italian admin and if
>>> there isn't one what to do to become one - as things need to be
>>> adjusted now and not somewhere in the future. Imagine a person
>>> uploading 1500 terms including images ... sigh ... and then having
>>> to adapt hundreds/thousands of terms to upper/lowercase ... no, this
>>> must be done now.
>>>
>>
>> What you need to do to become an admin is to start an election. If
>> there is enough people who agree you would make a good admin, you can
>> ask Andr? Engels to make you one. It wouldn't be a bad idea to
>> nominate several of the more active people and have something like
>> three or five people administering a Wiktionary. If you manage to
>> determine a good person to take on the task of burocrat during the
>> same elections, then you don't have to bother Andre any more afterwards.
>>
>>
> Hi Jo,
>
> this means I should try to contact the people contributing to the
> Italian wiktionary and maybe also ask who of them would also like to
> take over an admin job. Where does this election then take place? On
> the wiktionary itself? Maybe on the admin page? Is there any example
> around? How can I determine who are the people who contributed most to
> the wiktionary - is there some kind of list? Sorry for so many questions.

Ciao Sabine,

I thought you were an active contributor yourself. Then you would have
known who contributes a lot. Otherwise you can see what contributions
people do and see if they are regular. The election would take place on
the administrator's page. (an example from the Spanish page:
http://es.wiktionary.org/wiki/Wiktionary:Administrador)
People can propose themselves or they can be nominated.

I hope this helps,

Polyglot


from_name: Chris Sherlock

subject: [WikiEN-l] Australian images

body:
Hello all,

Apologies if this has been discussed before (I'm a newbie to the list), but the Australian users on the "Wikipedia:Australian wikipedians' notice board" would like to use some images that we will not be able to license under the GFDL or any other copyleft like license. The reason for this is because Australia does not have any fairuse legislation, and we require permission for images that are under 50 years old - even if they are from the Australian government.

For instance, we have recently started collaborating on the Cyclone Tracy article and I took off my image and had to list it on Images for Deletion because I didn't secure permission before uploading it. Yes, very naughty I know! In the meantime I have found some extremely excellent images. I have purchased one (URL for the image is http://www.nla.gov.au/apps/picturescatalogue?action=PCDisplay&mode=display&rs=resultset-5743&no=13) and the other seems to be from the government archives and is probably OK to use also (see http://www.pictureaustralia.org/apps/pictureaustralia?action=PASearch&mode=display&rs=resultset-2609&no=1). My question is: will I be allowed to upload and use them in the article? I will have to apply a restrictive license.

I realise that this is not the best situation, but in some cases we will be unable to use images for some recent historical events if we are unable to upload such images. This would really be a shame :(

Anyway, apologies if this has been asked and debated before, but I would really appreciate feedback on this issue.

Thanks,
Chris (Ta bu shi da yu)


from_name: Mark Richards

subject: [WikiEN-l] A plea - live and let live

body:
Exactly. This is what should be done. What I am
worried about is that deletion has become the first
and only resort in dealing with these kinds of issues.
Mark

--- "Poor, Edmund W" <Edmund.W.Poor at abc.com> wrote:

> If there are a dozen or 6 dozen separate, tiny
> articles with a common
> theme, then why not:
>
> * Copy the text of each article into one new
> comprehensive article (like
> [[List of Apprentice contestants]]
> * Turn the text of each old article into:  #REDIRECT
> [[List of
> Apprentice contestants]]
>
> This is how Maveric asked me to handle the Simpsons,
> way back when...
>
> Ed Poor
> "very good, always helps"    <--- 40 WikiBonus
> points if u can ID this
> quote
>
> > -----Original Message-----
> > From: Andrew Lih [mailto:andrew.lih at gmail.com]
> > Sent: Wednesday, September 29, 2004 8:42 PM
> > To: English Wikipedia
> > Subject: Re: [WikiEN-l] A plea - live and let live
> >
> >
> > On Thu, 30 Sep 2004 07:31:33 +1000, David Carson
> > <david at hemiware.com> wrote:
> > > Mark Richards wrote:
> > >
> > > That's a fairly large misstatement of the actual
> situation, seeing
> > > that virtually all of the "over 70 new listings"
> are a list
> > of over 70
> > > esoteric programming languages listed for VFD by
> one person.
> >
> > Note that over a dozen entries on VfD were "The
> Apprentice"
> > contestants, added in one big shot. As Wikipedia's
> popularity
> > grows, the listing on VfD will too.
> >
> > -Andrew (User:Fuzheado)
> >
> >
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail


from_name: Milos Rancic

subject: [Wikipedia-l] Anarchopedia

body:
I started new Wikipedia, Anarchopedia (www.anarchopedia.org). In this
moment it is blank MediaWiki, but I hope it would become real free
anarchist encyclopedia.

The main difference between Wikipedia and Anarchopedia is that
Anarchopedia _is_ test for anarchy. Also, we would have more
anarchistic articles then Wikipedia.

Anarchopedia has sister AnarchApedia (www.anarchapedia.org).

Where to announce new Wikipedian project?

I would like to hear your suggestions as well as I would like to see
Wikipedians anarchists to work on Anarchopedia and Anarchapedia.


from_name: Ashar Voultoiz

subject: [Wikitech-l] Re: File upload borked

body:
Brion Vibber wrote:
> On Sep 29, 2004, at 11:08 PM, Chong Yidong wrote:
>
>> On the English Wikipedia, I have been trying to upload the latest
>> version of wikipedia-mode.el, an Emacs lisp mode for editing wikipedia
>> articles. After submitting the file, I end up at a page that says
>> "Warning: .el is not a recommended file format". There used to be two
>> buttons underneath this, labelled "Upload anyway" and "Cancel", but
>> these have disappeared, which means I'm no longer able to proceed.
>
>
> Please see:
>
> On Sep 23, 2004, at 1:09 PM, Brion Vibber wrote:
>
>> We're tightening up security on the uploads due to exploitable
>> Internet Explorer and Safari bugs that allow for scripting attacks to
>> steal session and saved password cookies.
>>
>> For the moment uploads are limited to the default extension whitelist:
>> 'png', 'gif', 'jpg', 'jpeg', 'ogg'. Other types of files can't be
>> uploaded to the wikis until we expand it again, but files already
>> uploaded remain accessible.

Maybe .zip .rar .tar.gz should be allowed ?

--
Ashar Voultoiz


subject: [Wikitech-l] advertisiing firefox (was: Re: soundfiles and stuff)

body:
Gerard Meijssen wrote:
<snip>
> I have read the posts about Firefox and the problems that we have
> supporting Internet Explorer. Would it be an idea to suggest that
> Wikimedia is best experienced with Firefox / Opera / .. I am myself a
> fan of Firefox, it really increases my productivity using two screens
> with 9 tabs on average. That is what the Firefox experience is for me :)
> Seriously though, when we do not allow MP3, would it not make equally
> good sense to suggest that our content is best experienced not using IE
> ?? Needless to say, we would continue the support for IE !!
>
> It only needs to be a small statement on our main page or on our user
> portal ...
>
> Thanks,
>    GerardM

Hello,

There is an effort to spread firefox usage at:
    http://www.spreadfirefox.com/

Basicly the idea is to ask people to put a firefox banner on their
website and track the number of click and downloaded firefox through the
banner. Material is available with source code at:
http://www.spreadfirefox.com/community/?q=affiliates/homepage

Wikipedia being NPOV I don't think we should enter the war. Moreover
saying "this site is best seen with firefox / opera" will just mean to
IE users that we are lazy webmasters that didn't want to put any effort
in supporting multi browsers (which is false, ask gwicke about css
tweaking).

So basicly, it's a good idea for freeness, but bad for NPOV :o)

--
Ashar Voultoiz


from_name: Anthere

subject: [WikiEN-l] Re: Wkipedia slowness

body:
How infortunate :-(

Well... in this case, I suspect the best direction for you is probably
to head for wikitech-l at wikimedia.org and complain that no site notice
was warning people of a technical down time.

The question might be... how many messages can we decently put on the
site notice message ? :-)

------

Rick a ?crit:
> I see nothing on the Village Pump announcing any downtime or slowness.
>
> RickK
>
> Anthere <anthere9 at yahoo.com> wrote:
> Yes it was planned.
>
> I presume it was announced on en:pump, for JamesDay took the time to
> warn fr.
>
> Yes several people are currently working on it.
> Just on irc, I notice Jimbo, Jamesday, jeronimo and others.
>
>
> Do not worry :-)
>
>
> Rick a ?crit:
>
>>Last night, Wikipedia was so slow (at least 5 minutes from the time I hit SAVE until the article was actually saved, lucky if I didn't get an ERROR message) that I eventually gave up. And now today it seems to be in the same unuseable mode.
>>
>>What's going on, and will it be fixed soon?
>>
>>RickK
>>
>>
>>
>>---------------------------------
>>Do you Yahoo!?
>>vote.yahoo.com - Register online to vote today!
>
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>
>
> ---------------------------------
> Do you Yahoo!?
> vote.yahoo.com - Register online to vote today!


subject: [Wikitech-l] MediaWiki 1.3.5 released

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

MediaWiki 1.3.5 is a security update, which contains a small fix for a
potential cross-site scripting vulnerability. All MediaWiki 1.3.x users
are strongly encouraged to upgrade to this latest release.

The only substantial change from 1.3.4 is in includes/RawPage.php, so
you can copy that one file in to perform a 'hotfix'. (Copy also
includes/DefaultSettings.php to update the version number.)

Changes from 1.3.4:
* Clean up input validation in 'raw' page output mode which was a
potential
   cross-site scripting opportunity.

Release notes:
http://sourceforge.net/project/shownotes.php?release_id=271848

Download:
http://prdownloads.sf.net/wikipedia/mediawiki-1.3.5.tar.gz?download

Wiki admin help mailing list:
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l

Bug report system:
http://bugzilla.wikipedia.org/

Play "stump the developers" live on IRC:
#mediawiki on irc.freenode.net

- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBXGXdwRnhpk1wk44RAmIwAJ0RupGm+mNo1cZ433k8hHa7J50U2QCgnuG+
SZLnmAK5JuKaHyIaVkxvHbg=
=0PBU
-----END PGP SIGNATURE-----


from_name: Delirium

body:
Angela wrote:

>One reason is that the differences between American and British
>English are more involved than simply changing the spelling of a few
>words. Punctuation and grammar are also involved. If you changed
>behavior to behaviour in an otherwise AE sentence, the sentence would
>then be wrong in both languages.
>
I can't seem to find the page now, but I seem to remember a policy page
where we've basically settled on a compromise, partially-invented
"international English" punctuation style for clarity and because it's
not really worth fighting over.  The compromise included the
British-style "put punctuation _after_ closing quotation marks", and
something from US style that I can't remember.  As for being "wrong",
that's only the case if you happen to be a [[en:prescription and
description|grammatical prescriptivist]], which not all of us are.

But as far as the spelling issue goes, it seems like a solution in
search of a problem.  The current approach seems to be working well enough.

-Mark


subject: [Wikitech-l] advertisiing firefox

body:
Ashar Voultoiz wrote:

> Gerard Meijssen wrote:
> <snip>
>
>> I have read the posts about Firefox and the problems that we have
>> supporting Internet Explorer. Would it be an idea to suggest that
>> Wikimedia is best experienced with Firefox / Opera / .. I am myself a
>> fan of Firefox, it really increases my productivity using two screens
>> with 9 tabs on average. That is what the Firefox experience is for me
>> :) Seriously though, when we do not allow MP3, would it not make
>> equally good sense to suggest that our content is best experienced
>> not using IE ?? Needless to say, we would continue the support for IE !!
>>
>> It only needs to be a small statement on our main page or on our user
>> portal ...
>>
>> Thanks,
>>    GerardM
>
>
> Hello,
>
> There is an effort to spread firefox usage at:
>    http://www.spreadfirefox.com/
>
> Basicly the idea is to ask people to put a firefox banner on their
> website and track the number of click and downloaded firefox through
> the banner. Material is available with source code at:
> http://www.spreadfirefox.com/community/?q=affiliates/homepage
>
> Wikipedia being NPOV I don't think we should enter the war. Moreover
> saying "this site is best seen with firefox / opera" will just mean to
> IE users that we are lazy webmasters that didn't want to put any
> effort in supporting multi browsers (which is false, ask gwicke about
> css tweaking).
>
> So basicly, it's a good idea for freeness, but bad for NPOV :o)

When comparing Firefox and IE, many things can be said that are not POV.
Firefox has better and more functionality, it has shown itself to be
more responsive compared to IE regarding fixing known security issues.
An US-American governmental organisation has suggested not to use IE
because of its security issues. Firefox is more compliant to standards.
Contrary to other organisaations who are not capable enough to create
standard comformant web-sites, we do support IE.

As you only quote part of my mail, one reason that is left out is; we
support .ogg sound files and we do not *allow* .mp3 files. This is
because we want to promote open standards. Supporting open standards is
exactly what we achieve when we promote Firefox. When one of the leading
websites (us) informs the public that there is something good over the
horizon ... Why would we not support browsers who are better standards
compliant ??

Yes, I know spreadfirefox; 2 million downloads in 10 days :) So many
more to go..

Thanks,
    GerardM


from_name: Erik Moeller

subject: [Wikitech-l] advertisiing firefox

body:
Ashar-
> Wikipedia being NPOV I don't think we should enter the war. Moreover
> saying "this site is best seen with firefox / opera" will just mean to
> IE users that we are lazy webmasters that didn't want to put any effort
> in supporting multi browsers (which is false, ask gwicke about css
> tweaking).

Agreed. However, we should prominently state that Wikimedia is best viewed
using a browser that supports web standards A, B, C and D. We could then
have an information page (table) that shows which browser supports which
standards.

The problem with the browser monopoly is that Microsoft can exercise
control over standards. It is this control which matters to us and to
everyone else, and making people aware of that fact is perfectly fair and
neutral. We should give our readers the necessary information to take
control. As long as Microsoft supports all these standards, everything is
fine and they will have an "X" in all the table columns.

In the near future, SVG should be one of these standards - as soon as it
becomes part of the mainline builds for Firefox and Mozilla. SVG is really
important to enable things like animations (without non-scalable and 256-
color limited GIFs) and interactive timelines. The current timelines are
nice, but SVG makes them zoomable and adds potential for other features
which you find in timeline systems of CD-ROM encyclopedias. Note that
basic SVGs are already generated, if you view the image for a timeline you
can substitute ".png" in the URL with ".svg".

XForms may also provide us with some benefits, although that is probably
of more interest to Wikidata where form entry verification is desirable.
Switching to full XHTML will be important if we ever want to add WYSIWYG
support, as it will enable us to convert back and forth between wiki-
syntax and XHTML.

I have no idea what Microsoft's long term plans are for these standards.
See, I'm perfectly neutral. ;-)

Regards,

Erik


from_name: Anthony DiPierro

body:
> Sorry to only pick up on one point out of a whole e-mail, but we are
> absolutely committed to the GFDL, whether we like it or not: anything
> that we use 99.99% of the content already submitted for has to be
> compatible with the GFDL, because that is the licence it has been
> submitted to us under.

As I said in the very email you replied to (see what happens when you pick
up on one point and ignore the rest), Jimmy Wales has already said that all
images, regardless of license, are compatible with the GFDL.

> As I say, we can do two things with images:
> (1) distribute a GFDL version of Wikipedia with only those images that
> are compatible with the GFDL, and a separate version which includes
> all images, but is under a more restrictive licence that is compatible
> with the licence of *all* images used; fair use images, strictly,
> should not appear in the former; and the latter may actually breach
> the GFDL's terms for "derivative works" for all I know.
> or (2) throw out any image that is not GFDL-compliant

I suggest you read the GFDL, specifically, clause 7.

"A compilation of the Document or its derivatives with other separate and
independent documents or works, in or on a volume of a storage or
distribution medium, is called an "aggregate" if the copyright resulting
from the compilation is not used to limit the legal rights of the
compilation's users beyond what the individual works permit. When the
Document is included in an aggregate, this License does not apply to the
other works in the aggregate which are not themselves derivative works of
the Document."

> AFAIK, currently, we are following option (0), which is "fudge it by
> saying we haven't decided yet, and offer the images for reuse under a
> label saying 'these may or may not actually be legal for you to
> reuse'; and rely on the fact that nobody hates us enough yet to
> challenge us over it". I may be wrong on that bit, but that's my
> understanding.

There really hasn't been an official determination made by the board, as far
as I can tell, and the statement on [[Wikipedia:Copyrights]] is ambiguous as
hell, but the position that the website is an aggregation of both GFDL and
non-GFDL documents is certainly plausible.  I'd say the bigger problem right
now is that we don't have a compliant title page or history section.

>  Rowan Collins BSc

Anthony


from_name: Kiss All

body:
Very good plan!

> I am also willing to completly rewrite the rule system. Instead of
> anonymous / logged in / Sysops / Bureaucrate, I am willing to assign
> users to groups, each group having rights like "edit, move, special
> page, site administration, mediawiki, protecting page ...".

My question here is: How do you plan to manage the target pages?

Do you want to assign permissions of a group to each page?  I think
putting pages into groups is more practical than treating them
individually.

   There are already the concept of category in wikipedia. We may use
category name as the natural group name for a page and assign user
group's permissions to the page's category rather than the page
itself.

   I surveyed and tested other wiki software these days and found
Tikiwiki may be the best for user permission management. eGroupware is
good also for this. Some of them even have interfaces to access LDAP
sever.  You may refer their work to design and implement the right one
for wikipedia.

  Another thing I want to mention is Mambo Server at mamboforge.net. I
almost get addicted to trying it those days.  It is something like an
web based operating system and you can install and uninstall
components(poll, forum, pic gallery, doc management, online-shop)
conveniently. Some people there are also trying to port wiki into this
flexible framework.

  Anyway, keep our eyes open is good for wikipedia for a long run.

--
Be good....


body:
Jens Ropers wrote:
> My 2 [[eurocent]]s:
>
> The possibilities for diverse British/American spelling being so
> widespread, the adoption of "both options"-markup would absolutely
> _guarantee_ that every single article's markup would become so
> convoluted that it will more successfully prevent new contributors from
> joining the Wikipedia than all other "less than optimal" proposals
> combined.
>
> The differences between British/US English DO NOT impair understanding
> of the article text for most people.
> Extra markup to "cater for" these differences DECIDEDLY WOULD impair
> understanding of the markup text for most people.
>
> IMHO the motion to introduce the proposed markup epitomizes the victory
> of grammarian stormtrooping over the KISS principle.

Every suggestion to add a feature to wiki markup gets immediately
denounced by certain people who insist that adding any new feature will
make the wiki markup too complicated and drive away new users.

And yet, no one has ever shown that that new users have been put off
complex wiki markup. In fact, the number of editors grows every day, and
continues to grow, regardless of the complexity of wiki markup. This
kind of reactionary opposition to the addition of features to wiki
markup is unwarranted. We already have wiki markup for mathematical
formulas and even Egyptial hieroglyphics. Why is support for dialect
variants such an onerous addition? Do want to not implement a feature
that actual people want and desire and will use because there may be
hypothetical people who might not join the project because we have the
feature?

It seems to me that the syntax for templates, image thumbnails, tables,
and mathematic formulas have already made the wikitext hard to read and
understand for new users. The reality is that in the creation of an
encyclopedia, there are complicated things and ideas that require
complicated markup. Is localized dialectical consistency not something
worth striving for? And who should make that decision?

Is

The -{en-us colors; en-gb colours}- of the U.S. flag are red, white and
blue.

going to dissuade users from editing an article any more than the following?

If you were looking for an article on the abbreviation "VFD",
please see [[VFD]].

{{Shortcut|[[WP:VFD]]}}
{{deletiontools}}
{{VfD_header}}

[http://en.wikipedia.org/w/wiki.phtml?title=Wikipedia:Votes_for_deletion&action=edit&section=0
edit]

Rather than trying to live in the fiction that en-us and en-gb are
equally understandable and mutually compatible, we should admit that
they are different, that those differences can and empirically do cause
problems, and that we should create a solution to solve it.

- David Friedland


from_name: Stan Shebs

body:
David Friedland wrote:

>
> The -{en-us colors; en-gb colours}- of the U.S. flag are red, white
> and blue.
>
> going to dissuade users from editing an article any more than the
> following?
>
>
 7px;">If you were looking for an article on the abbreviation "VFD",
> please see [[VFD]].

>
> {{Shortcut|[[WP:VFD]]}}
> {{deletiontools}}
> {{VfD_header}}
>
> [http://en.wikipedia.org/w/wiki.phtml?title=Wikipedia:Votes_for_deletion&action=edit&section=0
> edit]
>
Actually this already happens - look at article histories, and
you'll see dozens of editors not fixing obviously broken table or
image markups, and when I fix those myself, I'll get little
thank-you notes from people saying "I have no idea how those work".
Fortunately they occur in support bits like images, not in the content
proper. As Angela's excellent example shows, the markup can easily
overwhelm the text and render it as unreadable as any HTML hack.

> Rather than trying to live in the fiction that en-us and en-gb are
> equally understandable and mutually compatible, we should admit that
> they are different, that those differences can and empirically do
> cause problems, and that we should create a solution to solve it.

So you're saying that there are Americans unable to follow articles
written in British style, and vice versa? I've not seen that - the
most common situation is where readers understand full well what is
being said, but object to the way it's being said, usually for
nationalist/chauvinist reasons. We should take our example from the
Portuguese, who recognize that there are local dialects, but who
have set themselves the goal of writing their encyclopedic material
in a dialect-neutral fashion.

Stan


from_name: Rowan Collins

subject:
[Wikitech-l] Patch for template backlinks AKA easy template
	editing/viewing

body:
On Wed, 29 Sep 2004 23:25:24 -0600, Hunter Peress <hunterp at gmail.com> wrote:
> My idea: http://bugzilla.wikipedia.org/show_bug.cgi?id=607 was denied
> because its similar to a fix thats in 1.4 CVS:
> http://bugzilla.wikipedia.org/show_bug.cgi?id=143
>
> This 143 fix is not sufficient because it makes links to templates
> available from the editing screen. My proposal is for a backlink (to
> the template itself or its edit page)  to be rendered in directly in a
> standard article (not only on its edit page).

I've marked 607 as a dupe of 229, and 229 as WONTFIX, not dupe. This
is clearly a distinct feature, even if its one we don't want to code.

> I write this argument to the list now because if we have a link in the
> actual page for editing sections, then we should surely have a link
> helping us quickly get back to a template.

I think the counter-arguments are:
1) people currently use templates to *hide* parts of a page [e.g.
en.wikipedia's Main_Page is split into templated sections which are
unprotected, but you have to find them first, giving a "speed bump"
effect] Not the strongest argument, but worth bearing in mind

2) unlike sections, templates have no defined structural extent, by
which I mean they're not always the same shape: some are tables, some
are paragraphs, some just a fragment of text that could be included in
another paragraph. It's not clear how an automatic mechanism could
position an edit link so that it was clear what it referred to without
limiting the usefulness of the templates themselves (by having an
automatic frame around them or somesuch).

Perhaps a simple keyword could be added that inserted such a link on
demand, to be used at will by template editors. As mentioned in
comments on bug 229, there is already a workaround in use at
http://en.wikipedia.org/wiki/Template:Ed; perhaps something like this
could be incorporated into the software?

--
Rowan Collins BSc
[IMSoP]


subject: [Wikitech-l] Re: File upload borked

references:
<E1CCu7I-00027i-Uh@shark.dnsvelocity.com>
	<44B9627D-12A9-11D9-AE6B-000A95DAA284@pobox.com>
	<cjgnbt$1g3$1@sea.gmane.org>

body:
On Thu, 30 Sep 2004 12:32:28 +0200, Ashar Voultoiz <thoane at altern.org> wrote:

> Maybe .zip .rar .tar.gz should be allowed ?

Um... So anyone can upload a virus as long as they zip it up first?
Remember that some systems (like WinXP, for instance) deal with zip
files automatically, so you only have to convince somebody that they
want to investigate what's inside and... "oh look, it's not a news
report about the assassination of George W Bush after all; hmm, why's
my computer just frozen?"

So no, I think maybe not.

--
Rowan Collins BSc
[IMSoP]


from_name: David Gerard

subject:
[WikiEN-l] Admin note regarding posting using an unsubscribed
	address

body:
If you post to a Wikipedia mailing list from a different address,
please take the time to subscribe that address!

Reason:

The wikien-l list only automatically forwards posts to the list when
you're subscribed to it. If you don't, it ends up in the moderator
queue - amongst piles of V*agra spam. Where the mail from real people
can easily get deleted accidentally!

If you want to post to a mailing list from an address other than
your normal one, it's generally worth the effort to subscribe from
that address too. You can set an option for 'no delivery'.

If you're subscribed, then your posts also show up straight away,
rather than hanging around until someone spots them in the queue
and lets them through :-)

- d.


subject: [Wikitech-l] Problem solving with sound

body:
On Thu, 30 Sep 2004 11:32:43 +0200, Gerard Meijssen
<gerardm at myrealbox.com> wrote:
> Hoi,
> One difference with pictures is, that when you save a screen with a
> picture on it, you save the picture at the same time. When you save an
> "image" with a sound, you do NOT save the sound at the same time.

I'm not sure what you mean by "save a screen with a picture on it" -
do you mean pressing "save" in the browser and using some "save web
page complete with all its bits" function?

> The
> problem is that when people prepare their computer to use .ogg files.
> One stage is to check if you can hear .ogg files locally. This means
> that you have to HAVE an .ogg file.

Well, if you click a Media: link to a .ogg file, and there's nothing
set up to load it, you'll be asked to save the file, like any other
unrecognised download. So then you'll have an Ogg.

> Yesterday I mentioned that sounds being "Image"s for wikimedia is
> counterintuitive, today I ask for  a Sound detail screens which has the
> option to download the sound,

This might actually be quite a good idea, because Media: links have an
annoying flaw: since they by-pass the description page, you can't
access a description through them. If we had a proper Sound: (or,
thinking ahead, AV: or some other combined term for sounds and videos,
which are generally treated similarly) namespace, we could have magic
links like we do for images.

[[Image:foo]] gives you an inline image, plus access to a description
page; [[Sound:foo]] (or [[AV:foo]]) could give you a direct link to
the file (marked "Play", or with that symbol that always means 'play')
plus a link to a description, which would include help; or maybe a
third link to help, giving something like:
+-----------------------------------------+
 | Listen to foo. |> [Info] [Help] |
+-----------------------------------------+

If we wanted to be *really* clever, we could provide options for using
inline browser plugins to play the sound, but given the desire to
support as many alternatives as possible, that may be a bit complex...

--
Rowan Collins BSc
[IMSoP]


body:
Sean Barrett wrote:

>>True.  In American English, a list of 3 items is usually "bacon, eggs, and cheese" - not "bacon, eggs and cheese."  The later implies a connection between the items, but the former doesn't.
>>
>>
>
>>From a book dedication:
>
>I'd like to thank my parents, God and Ayn Rand.
>
>
This case is covered in the style manual, which recommends the "with
comma" version for exactly that reason, at
http://en.wikipedia.org/wiki/Wikipedia:Manual_of_style#Commas

(FWIW, the punctuation section I couldn't remember the reference to is
on that page as well, at
http://en.wikipedia.org/wiki/Wikipedia:Manual_of_style#Punctuation)

The current style suggestions seem mostly reasonable to me.  Certainly
better than a bunch of weird wikimarkup to try to accomodate all variants.

-Mark


from_name: Stirling Newberry

body:
On Sep 30, 2004, at 3:49 PM, Delirium wrote:
>>
> This case is covered in the style manual, which recommends the "with
> comma" version for exactly that reason, at
> http://en.wikipedia.org/wiki/Wikipedia:Manual_of_style#Commas
>
> (FWIW, the punctuation section I couldn't remember the reference to is
> on that page as well, at
> http://en.wikipedia.org/wiki/Wikipedia:Manual_of_style#Punctuation)
>
> The current style suggestions seem mostly reasonable to me.  Certainly
> better than a bunch of weird wikimarkup to try to accomodate all
> variants.
>
> -Mark

I agree, the mark up idea looks like a problem in search of a problem.


subject: [Wikitech-l] soundfiles and stuff

body:
On Thu, 30 Sep 2004 00:25:17 +0200, Gerard Meijssen
<gerardm at myrealbox.com> wrote:
> Hoi,
> To celebrate the 5000th word of nl:wiktionary, I have uploaded 100 .ogg
> files to Commons. These are Dutch words pronounced by me. While doing
> this excercise, I have written a blurp about sound and how to handle it
> on Wikimedia. The piece is still in Dutch, it is still in nl:wiktionary,
> but I have asked the nl:wikipedia crowd to review it. When this is done,
> I will translate it in English and post it in Meta ? en:Wikipedia ?
> Please let me know..

No need to translate: if its for the whole of Wikimedia, it should go
on meta: somewhere, and people can translate, discuss, translate
discussions, etc. That's what it's for. Now, where is it at the
moment.. aha, found it:
http://nl.wiktionary.org/wiki/WikiWoordenboek:Geluid am I right?

>From what I can gather (I know no Dutch, but English+German gives me a
good start), this so far covers adding sounds far better than it
covers accessing them. I was thinking about how to do this, and I came
to the conclusion that we really need *two* help pages: one to answer
"Help! How do I make this sound play?" and one to answer "How can I
contribute sounds to Wikimedia?"

I'm going to hash out some of my ideas on this at
http://meta.wikimedia.org/wiki/Multimedia; please join me.

--
Rowan Collins BSc
[IMSoP]


body:
Hello,

For the next 3 days I will be able to spend my full time on MediaWiki
development.

I am really willing to code an administration interface that will
superseed the install script and manually editing localsettings.php. My
idea so far is that the install script will just deal with things like
database and path, everything else will be available in the admin interface.

I am also willing to completly rewrite the rule system. Instead of
anonymous / logged in / Sysops / Bureaucrate, I am willing to assign
users to groups, each group having rights like "edit, move, special
page, site administration, mediawiki, protecting page ...".

Is there any dev already working on one of those two topics ? Do you
have any specific idea to share ?

Finally, should I start it now for the 1.4 release or wait for a later
release ?

cheers,

--
Ashar Voultoiz


body:
On Thu, 30 Sep 2004 07:46:42 -0400, Anthony DiPierro
<anthony_dipierro at hotmail.com> wrote:
> I think you're thinking of public domain, not GFDL.  GFDL is not absolute
> freedom.  Furthermore, we haven't committed ourselves to the GFDL, only the
> spirit of the GFDL.

Sorry to only pick up on one point out of a whole e-mail, but we are
absolutely committed to the GFDL, whether we like it or not: anything
that we use 99.99% of the content already submitted for has to be
compatible with the GFDL, because that is the licence it has been
submitted to us under.

As I say, we can do two things with images:
(1) distribute a GFDL version of Wikipedia with only those images that
are compatible with the GFDL, and a separate version which includes
all images, but is under a more restrictive licence that is compatible
with the licence of *all* images used; fair use images, strictly,
should not appear in the former; and the latter may actually breach
the GFDL's terms for "derivative works" for all I know.
or (2) throw out any image that is not GFDL-compliant

AFAIK, currently, we are following option (0), which is "fudge it by
saying we haven't decided yet, and offer the images for reuse under a
label saying 'these may or may not actually be legal for you to
reuse'; and rely on the fact that nobody hates us enough yet to
challenge us over it". I may be wrong on that bit, but that's my
understanding.

--
Rowan Collins BSc
[IMSoP]


subject: [WikiEN-l] Australian images

body:
On Thu, 30 Sep 104 22:05:23 +1000, Chris Sherlock
<csherlock at mail.ljh.com.au> wrote:
> Hello all,
>
> Apologies if this has been discussed before (I'm a newbie to the list), but the Australian users on the "Wikipedia:Australian wikipedians' notice board" would like to use some images that we will not be able to license under the GFDL or any other copyleft like license. The reason for this is because Australia does not have any fairuse legislation, and we require permission for images that are under 50 years old - even if they are from the Australian government.
[snip]
My question is: will I be allowed to upload and use them in the
article? I will have to apply a restrictive license.

Well, my understanding was that we didn't really want any image that
wasn't licencable under the same licence as the rest of Wikipedia, but
this is definitely a controversial topic, as another thread on this
list shows.

--
Rowan Collins BSc
[IMSoP]


body:
Erik Moeller wrote:
> David-
>
>>It seems to me that the syntax for templates, image thumbnails, tables,
>>and mathematic formulas have already made the wikitext hard to read and
>>understand for new users.
>
>
> Not really. Templates hide complexity and give ordinary users the power to
> quickly make use of things like nicely formatted infoboxes without knowing
> anything about the HTML. I have to admit that I am not a big fan of our
> table syntax, however; I'm as geeky as they come and I still fall back to
> HTML every now and then. The reStructured Text syntax is much lovelier,
> albeit easy to mess up:
>
> +------------------------+------------+----------+----------+
> | Header row, column 1   | Header 2   | Header 3 | Header 4 |
> | (header rows optional) |            |          |          |
> +========================+============+==========+==========+
> | body row 1, column 1   | column 2   | column 3 | column 4 |
> +------------------------+------------+----------+----------+
> | body row 2             | Cells may span columns.          |
> +------------------------+------------+---------------------+
> | body row 3             | Cells may  | - Table cells       |
> +------------------------+ span rows. | - contain           |
> | body row 4             |            | - body elements.    |
> +------------------------+------------+---------------------+
> http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#tables
>
> Still, I think a combination of something like this for quick tables, and
> HTML hidden in templates for complex ones would be best.
>
> Like templates, image tags have also reduced the amount of visible HTML in
> articles - don't you remember when we cleaned out all the <div
> style="float:right"> tags? This is a good thing. Surely you're not
> suggesting there's a need for empirical proof that added complexity deters
> newbies? I hold that truth to be self-evident, but in case you don't,
> browse around a TWiki or TikiWiki site sometime.
>
> I believe that in the long term, we must entirely eliminate HTML from all
> regular pages and limit its use exclusively to templates. For this, we
> need to make some improvements to the template syntax (default values,
> loops, conditions) so that all current HTML content can be moved there and
> used dynamically.
>
> Things which need a clean wikitext replacement:
> - —   (my suggestion: --)
> -      (my suggestion: __)
> - <br>      (my suggestion: \\)
> ...
>
>
>>The -{en-us colors; en-gb colours}- of the U.S. flag are red, white and
>>blue.
>
>
> I think you won't find any supporters for that scheme ;-). Even though we
> have ugliness in some articles, our sentences are at least readable. The
> current situation with regard to spelling is somewhat dissatisfactory to
> consistency nuts like ourselves, but aside from auto-conversion for the
> most common words (which would probably take too much performance to be
> worthwhile), I really see no good solution.
>
> Regards,
>
> Erik

I've just had an idea:

Why not use templates as the solution? Put the dialect-specific code in
the templates, and just put {{ }} around words that vary by dialect.
That can't be any worse than '' '' for italics, can it? That would solve
probably 90% of the cases.

Thus, for our example sentence, we would have something like

The {{colour}}s of the U.S. flag are red, white, and blue.

And the colour template would have the dialect-specific code like

-{en-us color; en-gb colour}-

Similarly, {{zucchini}} could be

Of course, then we would have to agree on what to call the templates,
but that seems like a much easier problem to deal with. At the very
least, {{color}} could just include the {{colour}} template, or vice-versa.

- David


references:
<cjhtsm$p34$1@sea.gmane.org> <9I07bAohpVB@erik_moeller>
	<cji8lu$q2m$1@sea.gmane.org>

body:
Grrr, accidentally pressed ctrl-return to send...

I meant to say

I've just had an idea:

Why not use templates as the solution? Put the dialect-specific code in
the templates, and just put {{ }} around words that vary by dialect.
That can't be any worse than '' '' for italics, can it? That would solve
probably 90% of the cases.

Thus, for our example sentence, we would have something like

The {{colour}}s of the U.S. flag are red, white, and blue.

And the colour template would have the dialect-specific code like

-{en-us color; en-gb colour}-

Similarly, {{zucchini}} could be

{-en-au Zucchini en-nz Courgette en-us Zucchini en-gb Courgette en-ca
Zucchini-}

Of course, then we would have to agree on what to call the templates,
but that seems like a much easier problem to deal with. At the very
least, {{color}} could just include the {{colour}} template, or vice-versa.

- David


from_name: Angela

body:
e2m <e2m at ig.com.br> wrote:
> Why this resource is not used to deal with the differences of the type
> "behaviour" and "behavior" or "center" and "centre"?

One reason is that the differences between American and British
English are more involved than simply changing the spelling of a few
words. Punctuation and grammar are also involved. If you changed
behavior to behaviour in an otherwise AE sentence, the sentence would
then be wrong in both languages. See
http://en.wikipedia.org/wiki/American_and_British_English_differences

Angela.


from_name: David Friedland

subject: [Wikitech-l] Re: devs and admins blog

references:
<cji0i3$2r5$1@sea.gmane.org> <9I07arDxpVB@erik_moeller>
	<cjiauu$dc$1@sea.gmane.org>

body:
> Helo,
>
> Of course it's possible to hack MediaWiki further more. But I believe
> it's far easier to install a blog software, have it ready and set up in
> like 10 minutes.
>
> The aim of the blog will not aim at building a cooperative content,
> that's what wiki is for. Instead it will help easily publish important
> messages from the dev/admin team to the userbase be it maintenance, new
> releases, ongoing changes available on test.wikipedia.org .
>

In other words, just because you have a hammer, that doesn't make
everything a nail.


from_name: Evan Prodromou

subject: [Wikitech-l] devs and admins blog

body:
On Fri, 2004-10-01 at 00:15 +0200, Ashar Voultoiz wrote:
> Hello,
>
> I am willing to know if we are willing to use a blog software to
> communicate with wikipedians and mediawiki users.

Any particular reason not to do it as a wikiblog?

~ESP

--
Evan Prodromou <evan at wikitravel.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040930/cafd50e1/attachment.pgp>


from_name: modean52 at comcast.net

body:
True.  In American English, a list of 3 items is usually "bacon, eggs, and cheese" - not "bacon, eggs and cheese."  The later implies a connection between the items, but the former doesn't.

James

-------------- Original message --------------

> e2m wrote:
> > Why this resource is not used to deal with the differences of the type
> > "behaviour" and "behavior" or "center" and "centre"?
>
> One reason is that the differences between American and British
> English are more involved than simply changing the spelling of a few
> words. Punctuation and grammar are also involved. If you changed
> behavior to behaviour in an otherwise AE sentence, the sentence would
> then be wrong in both languages. See
> http://en.wikipedia.org/wiki/American_and_British_English_differences
>
> Angela.
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l


from_name: Magnus Manske

subject: [Wikitech-l] advertisiing firefox

body:
Ashar Voultoiz wrote:

> Wikipedia being NPOV I don't think we should enter the war. Moreover
> saying "this site is best seen with firefox / opera" will just mean to
> IE users that we are lazy webmasters that didn't want to put any
> effort in supporting multi browsers (which is false, ask gwicke about
> css tweaking).
>
How about something along the lines "Due to security concerns with the
Internet Explorer (viruses disguised as images) we recommend that you
use another browser."? For IE users only of course, and only on pages
with images ;-)

See, perfectly neutral!

Magnus


body:
Over the last few days, I've had an intermittent problem where my
watchlists on both w:en: and meta: come up as though I was loading the
page a day or so ago. As in, it says "..the last X changes in the last
3 days" but then begins with "29 Sep 2004" and goes back from there.

Does anyone know why this is? Is it a result of overloaded servers? Or
just some on-going maintenance? Or is there something more serious - a
server with an incorrect internal clock, for instance?

Just thought I'd ask because a) it's a bit annoying and b) if nobody
who had the power to fix it knew about it, it would carry on being
annoying on and off for ages. So I apologise if this is something
you're already working on.

--
Rowan Collins BSc
[IMSoP]


from_name: Jimmy (Jimbo) Wales

subject:
[WikiEN-l] Re: Zero0000 has blocked
	Lance6Wins....apparentlycontray to Block

body:
> The tolerance for editors who willfully damage Wikipedia is
> astounding; known repeat offenders are agonized over, sometimes for
> weeks at a time, before action is taken, and even then actions are
> watered down in the hopes that one day, perhaps, with the right
> tutoring, the editor might make some valuable edit or contribution.

I agree with this completely.

The key, though, is that the solution to this problem has to be
undertaken in a way that is respectful of due process.  My deep
conviction that sysops who violate the rules must lose their sysop
privileges should not be mistaken for a toleration for trolls and
vandals.  The amount of time that we allow *bad people* to waste for
*good people* is staggering to me.

--Jimbo


body:
Ashar Voultoiz wrote:

> Hello,
>
> For the next 3 days I will be able to spend my full time on MediaWiki
> development.

There's something to envy :-)

> I am really willing to code an administration interface that will
> superseed the install script and manually editing localsettings.php.
> My idea so far is that the install script will just deal with things
> like database and path, everything else will be available in the admin
> interface.
>
> I am also willing to completly rewrite the rule system. Instead of
> anonymous / logged in / Sysops / Bureaucrate, I am willing to assign
> users to groups, each group having rights like "edit, move, special
> page, site administration, mediawiki, protecting page ...".
>
>
> Is there any dev already working on one of those two topics ? Do you
> have any specific idea to share ?

Now that you ask...

Two database tables:
* list of user <=> group association
* list of possible groups, maybe a description field, and a
"can-be-assigned-by" field ("sysop" can be assigned by "admin,sysop")

Also, for those that would like to keep parts of their wikis private,
how about a "cur_can_view" field? Empty=everyone can view, otherwise
only the listed groups (comma-separated).

Make sure noone can create group names that contain commas!

> Finally, should I start it now for the 1.4 release or wait for a later
> release ?

Last I heard, time for 1.4-release is running out (Brion?).

Magnus


subject: [Wikitech-l] Re: devs and admins blog

body:
On Fri, 2004-10-01 at 01:52 +0200, Ashar Voultoiz wrote:

> >>I am willing to know if we are willing to use a blog software to
> >>communicate with wikipedians and mediawiki users.
> >
> > Any particular reason not to do it as a wikiblog?
>
> Basicly : RSS feeds, automatic archiving and the ability to only read
> the content that matter (eg split posts using "development", "wikifarm"
> and categories).

Is there something in there MediaWiki can't do?

I think http://dev.wikimedia.org/ would be a good place to have a
development wiki with blog stuff.

~ESP

--
Evan Prodromou <evan at wikitravel.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040930/f8600a38/attachment.pgp>


from_name: Mark Richards

subject: [WikiEN-l] deletion policy amendment poll -- admin help requested

body:
I have followed this a little, and it seems that there
is a concensus that a reasonable amount of time should
pass between relisting of the same article. 3-6 months
seems reasonable to me, I think another poll proposing
this would pass easily.
Mark

--- Jens Ropers <ropers at ropersonline.com> wrote:

> This poll on an amendment to the deletion policy:
> >> http://en.wikipedia.org/wiki/Wikipedia_talk:
> >>
>
Deletion_policy#Proposed_new_rule:_No_repeat_submission_of_articles
> has become a bit of a mess, due to my slightly
> unfortunate choice of
> words when I opened the poll.
>
> I have now added a statement acknowledging the
> problems but I have
> requested that the poll results be respected despite
> the (arguably not
> major) insufficiencies.
>
> However I feel that any further steps towards
> codifying the proposed
> rule might be frowned upon if I take them.
> I would like to ask our admins to help
> I would like to request that an admin (preferably a
> few admins) look at
> the situation and see if it can be sorted out
> without a repeat poll.
>
> I don't think a repeat poll is a good idea because
> with every poll
> there will be deviating preferences and minor
> criticisms.
> I feel that if that were enough to invalidate a poll
> then every poll
> would have to be invalidated and we could never make
> any decision.
> We'd end up holding polls on whether we can accept a
> poll on whether we
> can accept a poll.
>
> Again, I'd like to ask for some "old hands" (admins)
> to please look at
> things and provide some guidance and leadership as
> regards  this issue.
>
> -- ropers [[en:User:Ropers]]
>      www.ropersonline.com
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

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


subject: [WikiEN-l] A plea - live and let live

body:
This highlights to problem of deletion. In the case
you are talking about, someone should very much have
boldly edited this as redirects. If this had happened
to be wrong, people would have seen it, and it could
have been put right through wiki process.

Deletion is a totally different beast, it removes the
information, and, for most users, even the evidence
that it was ever there, removing the possibility of
process to improve the information.

Mark

--- "Carson, David" <DCarson at nine.com.au> wrote:

> Ed Poor wrote:
> > If there are a dozen or 6 dozen separate, tiny
> articles with a common
> > theme, then why not:
> >
> > * Copy the text of each article into one new
> comprehensive article
> (like
> > [[List of Apprentice contestants]]
> > * Turn the text of each old article into:
> #REDIRECT [[List of
> > Apprentice contestants]]
> >
> > This is how Maveric asked me to handle the
> Simpsons, way back when...
>
> That's what I voted for, and indeed, that was the
> overwhelming consensus
> of the VFD vote, and is what has been done.
>
> And indeed, that could have been boldly done by
> someone without needing
> a VFD vote. But I would say that (a) there would
> have been a guaranteed
> edit war following it; and (b) there WAS a definite
> minority opinion
> that these people didn't deserve to be in the
> Wikipedia AT ALL, being
> merely "game show contestants".
>
> Me, I see the whole affair as further proof that VFD
> is not at all
> broken, and continues to excellently serve the
> community.
>
> Cheers!
> David...
>
>
>
_____________________________________________________________________________________________________
> This email and its attachments are for the sole use
> of the addressee and may contain information which
> is confidential and/or
> legally privileged. This email and its attachments
> are subject to copyright and should not be partly or
> wholly reproduced without
> the consent of the copyright owner. Any unauthorised
> use of disclosure of this email or its attachments
> is prohibited. If you receive
> this email in error, please immediately delete it
> from your system and notify the sender by return
> email.
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

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


from_name: Randy Becker

subject: [Wikitech-l] RFC: Approved Edits Only

body:
I'm a high school student involved in our website
(http://www.rileyhighschool.com/). After taking a look at the sorry
state of our site, and subsequently visiting wikipedia, I came to the
realization that a wiki, especially mediawiki, would be enormously
beneficial to our site in many ways. I investigated further, installed
1.3, got some content in, customized monobook a little bit, got
familiar with the software. I decided that it really would be a great
improvement, and continued further testing. Upon further review, and
in conversation with the administration, it was determined that the
principal objection to using mediawiki as our primary site was that
anyone could edit. Although it has been presented that this is not a
serious problem in practice, it was still too much of a risk for them
to take. Downtrodden, but not discouraged, knowing that mediawiki is
an open source product, and being familiar with php and mysql, I
looked further into what was available. Ultimately, it was determined
that unapproved edits cannot come to exist in the first place,
irregardless of the ease of their removal. I began looking for a way
to implement an approval mechanism.

On #mediawiki it was suggested that I look into the recent changes
patrolling in 1.4 as a potential method of implementing this solution.
I have done this and determined that it will be just as difficult to
use this as it will be to implement a cleaner solution, involving a
new table in the database and an approval mechanism. Therefore, I'm
here to ask for suggestions, comments, and help implementing this, or
a similarly acceptable solution.

-Randy


from_name: Gerard Meijssen

subject: [Wikitech-l] Request for comment

body:
On [[wikt:nl:Egypte]] I have two things that I would like your comments for.

* Under the header for pronounciation, it says on a line: * Geluid: Egypte
    When pressing the template for sound ( {{-sound-}}translates to
Geluid ), you get a sound.howto
    When pressing on Egypte, the process of letting you hear Egypte will
start (media)
*Under the header for Translations, there are three lines for Portugese;
    * Indicating Portugese
       One line with Brazilian Portugese and the word
       One line with Portugese Portugese and the word

With the first thing I think I give ample attention to the potential
problems with sound. When there is a SAMPA transliteration, it would be
on a seperate line and the SAMPA would get you to something about SAMPA,

With the second thing I think I have a proper way of presenting
alternate standard translations within one language. the templates used
are {{pr br}} and {{pt pt}}

Thanks,
    GerardM


subject: [Wiktionary-l] Request for comment


from_name: Jens Ropers

body:
My 2 [[eurocent]]s:

The possibilities for diverse British/American spelling being so
widespread, the adoption of "both options"-markup would absolutely
_guarantee_ that every single article's markup would become so
convoluted that it will more successfully prevent new contributors from
joining the Wikipedia than all other "less than optimal" proposals
combined.

The differences between British/US English DO NOT impair understanding
of the article text for most people.
Extra markup to "cater for" these differences DECIDEDLY WOULD impair
understanding of the markup text for most people.

IMHO the motion to introduce the proposed markup epitomizes the victory
of grammarian stormtrooping over the KISS principle.

-- ropers [[en:User:Ropers]]
     www.ropersonline.com

On 30 Sep 2004, at 20:53, modean52 at comcast.net wrote:

> True.  In American English, a list of 3 items is usually "bacon, eggs,
> and cheese" - not "bacon, eggs and cheese."  The later implies a
> connection between the items, but the former doesn't.
>
> James
>
> -------------- Original message --------------
>
>> e2m wrote:
>>> Why this resource is not used to deal with the differences of the
>>> type
>>> "behaviour" and "behavior" or "center" and "centre"?
>>
>> One reason is that the differences between American and British
>> English are more involved than simply changing the spelling of a few
>> words. Punctuation and grammar are also involved. If you changed
>> behavior to behaviour in an otherwise AE sentence, the sentence would
>> then be wrong in both languages. See
>> http://en.wikipedia.org/wiki/American_and_British_English_differences
>>
>> Angela.
>> _______________________________________________
>> Wikipedia-l mailing list
>> Wikipedia-l at Wikimedia.org
>> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>


body:
Wiki is supposed to be easy to edit. Having markup like the following
is going to be very off-putting to most users, and not only to
newcomers.

{-en-us " en-gb '-}IBM {-en-us has en-gb have-} announced that {-en-us
' en-gb "-}{-en-us eggplant en-gb aubergine-} should be {-en-us
spelled en-gb spelt-} with one g like {-en-us garbage en-gb rubbish-},
{-en-us analog en-gb analogue-}{-en-us , en-gb -} and {-en-us gray
en-gb grey-}{-en-us '. en-gb ."-}{-en-us " en-gb '-}

If the process was automated, problems would occur since you don't
want the sentence appearing as IBM having commented on the spelling of
aubergine when they haven't done so. An automated translation would
also suggest the word "rubbish" was spelt with a "g". Many similar
examples exist, such as "forward" which is sometimes "forwards" in
British English, but not always, so this really can't be automated.

Bring in other forms of English and the problem gets even more
complicated. Should we really have {-en-au Zucchini en-nz Courgette
en-us Zucchini en-gb Courgette en-ca Zucchini-}?

{-en-gb Angela}


body:
On Thu, 30 Sep 2004 14:29:59 -0700, David Friedland <david at nohat.net> wrote:
> Is
> The -{en-us colors; en-gb colours}- of the U.S. flag are red, white and
> blue.
> going to dissuade users from editing an article any more than the following?

I think you are over-simplifying the problem, David. My point earlier
was that changing from American to British English is about far more
than just swapping a few words.
In the example you give above, you'd actually need

The -{en-us colors; en-gb colours}- of the -{en-us U.S.; en-gb US}-
flag are red, white-{en-us ,; en-gb }-and blue.

This is not a natural way of writing and would be practically
impossible to read in the edit box, or on a diff page. The difference
between this and templates such as the VfD shortcut is that
{{Shortcut|[[WP:VFD]]}} very rarely needs to be edited. These are
add-ons to articles, not part of the body of text itself. There's no
need to ever learn what {{VfD header}} does, whereas if you want to
edit an article you would need to understand this proposed spelling
syntax.

Angela.


subject: [Foundation-l] Support for local chapters

body:
There has apparently been a major misunderstanding over my view
towards local chapters, so I want to go on record as saying I
*strongly* support the idea of Wikimedia having local chapters and I
always have done.

The source of the misunderstanding appears to be an edit by an
anonymous user:
http://meta.wikimedia.org/w/wiki.phtml?title=Talk:Membership_fees&diff=41997&oldid=41996
stating they did not see the point of local chapters.

Anthere later edited the page to sign this comment as me:
http://meta.wikimedia.org/w/wiki.phtml?title=Talk:Membership_fees&diff=48109&oldid=47756

This was most definitely not me and represents the complete opposite
to my view. It was only on reading the logs of the Hindi Wikimedia IRC
channel that I discovered this problem.

I see the existence of Wikimedia chapters as a very positive step and
I will help in any way I can to encourage the growth of these. I hope
to see them in every part of the world. I want one day for no one to
become a member directly of the Foundation because everyone will have
a local chapter they can join. Issues such as the legalities of money
transfer between chapters and the Foundation in certain countries are
problems that we need to work around, but these should in no way
prevent the creation of a chapter in any country with a sufficient
number of interested volunteers. The main reason I went to Berlin in
June was so I could learn more about the process of starting a chapter
since Wikimedia Germany were the first country to do this. I also went
to Paris and observed the beginnings of the French chapter there, and
discussed ESTU with Arno Lagrange when we were in London. I fully
intend to have a UK chapter registered as a charity in this country
later next year.

I have never been opposed to local chapters, and I am upset that
people are under the mistaken impression that I am.

Angela


body:
On Thu, 30 Sep 2004 14:29:59 -0700, David Friedland <david at nohat.net> wrote:
> Is
>
> The -{en-us colors; en-gb colours}- of the U.S. flag are red, white and
> blue.
>
> going to dissuade users from editing an article any more than the following?

Here's a scenario: Sue the Surfer comes across an article that says
"The colour of the U.S. flag are red, white and blue." Spotting the
"Edit this page" link - and maybe having surfed enough to get the idea
that it really means she can - she clicks. She looks for the text she
wanted to change, and sees "The -{en-us color; en-gb colour}- of the
U.S. flag are red, white and blue." Does she know what to do now? Are
"en-us" and "en-gb" likely to mean anything to her? Will she know that
she needs to put the s onto both spellings? Will she understand that
some people see one and some the other? The answer is likely to be no,
and the result may be that she "leaves it to someone more
experienced".

Unlike with a lot of the existing features, this example doesn't
feature anything intrinsically complex (maths formulae, formatted
navigation boxes which are displayed on multiple pages, etc); it just
comes in the middle of a sentence. I think that's quite a significant
difference. Note that markup such as ''italics'' and '''bold''',
although somewhat opaque to a new user, doesn't actually interfere
with the text, it just looks like somewhat spilt some punctuation
nearby. Probably the most imposing markup we have *in the middle of
sentences* right now is piped links: "The colours of the [[United
Kingdom|British]] flag are red, white and blue" (there are times it
looks worse than that, I know, but I'm tired). Hopefully, the effect
of those is clear enough that it wouldn't take someone long to just
guess; language switching may not be quite so obvious, because it's
very hard to see in action.

>
 7px;">If you were looking for an article on the abbreviation "VFD",
> please see [[VFD]].

>
> {{Shortcut|[[WP:VFD]]}}
> {{deletiontools}}
> {{VfD_header}}
>
> [http://en.wikipedia.org/w/wiki.phtml?title=Wikipedia:Votes_for_deletion&action=edit&section=0
> edit]

That example shows some interesting things: the
 at the top is
ugly, because it is essentially a hack to get the desired effect,
something we haven't come up with wiki-syntax for. The templates
neatly hide away ugly table code, and some ugly
s; they are hard
to edit, because templates are relatively new, and we haven't come up
with a decent interface for them yet - this could indeed be a fairly
major point of confusion. The last line is even hackier than the
first, and is just crying out for some proper wiki-markup to be
invented, because it looks a lot more complex than it really is.

This suggests to me that: extra wiki-markup can be a force for good as
well as evil. We need to use it sparingly, and design it carefully, so
that the confusion caused doesn't outweigh the advantage of the extra
feature.

> Rather than trying to live in the fiction that en-us and en-gb are
> equally understandable and mutually compatible, we should admit that
> they are different, that those differences can and empirically do cause
> problems, and that we should create a solution to solve it.

But the question is: is the impact of the proposed solution
proportional to the impact of the problem. My personal feeling is
that, for barely-dialectical variants of English, the answer is no.

I also agree with Angela's point that we need to remember just how
many variants of English there are out there, and consider whether
artificially splitting the English-speaking world into US and UK could
actually *cause* conflict over what the people see who are neither.

--
Rowan Collins BSc
[IMSoP]


from_name: Ivan Krstic

subject: [Wikitech-l] Re: devs and admins blog

body:
Ashar Voultoiz wrote:
> Looks like my next task will be to create a phpbb<->mediawiki
> communication :o)

I would wait until Erik shared his mockups and specs for LiquidThreads
with us. Evaluating those, and getting them coded if they look like what
we need, would probably be a great step forward for MediaWiki.

Ivan


body:
This poll on an amendment to the deletion policy:
>> http://en.wikipedia.org/wiki/Wikipedia_talk:
>> Deletion_policy#Proposed_new_rule:_No_repeat_submission_of_articles
has become a bit of a mess, due to my slightly unfortunate choice of
words when I opened the poll.

I have now added a statement acknowledging the problems but I have
requested that the poll results be respected despite the (arguably not
major) insufficiencies.

However I feel that any further steps towards codifying the proposed
rule might be frowned upon if I take them.
I would like to ask our admins to help
I would like to request that an admin (preferably a few admins) look at
the situation and see if it can be sorted out without a repeat poll.

I don't think a repeat poll is a good idea because with every poll
there will be deviating preferences and minor criticisms.
I feel that if that were enough to invalidate a poll then every poll
would have to be invalidated and we could never make any decision.
We'd end up holding polls on whether we can accept a poll on whether we
can accept a poll.

Again, I'd like to ask for some "old hands" (admins) to please look at
things and provide some guidance and leadership as regards  this issue.

-- ropers [[en:User:Ropers]]
     www.ropersonline.com


body:
David Friedland wrote:

> Jens Ropers wrote:
>
>> My 2 [[eurocent]]s:
>>
>> The possibilities for diverse British/American spelling being so
>> widespread, the adoption of "both options"-markup would absolutely
>> _guarantee_ that every single article's markup would become so
>> convoluted that it will more successfully prevent new contributors
>> from joining the Wikipedia than all other "less than optimal"
>> proposals combined.
>>
>> The differences between British/US English DO NOT impair
>> understanding of the article text for most people.
>> Extra markup to "cater for" these differences DECIDEDLY WOULD impair
>> understanding of the markup text for most people.
>>
>> IMHO the motion to introduce the proposed markup epitomizes the
>> victory of grammarian stormtrooping over the KISS principle.
>
>
> Every suggestion to add a feature to wiki markup gets immediately
> denounced by certain people who insist that adding any new feature
> will make the wiki markup too complicated and drive away new users.
>
> And yet, no one has ever shown that that new users have been put off
> complex wiki markup. In fact, the number of editors grows every day,
> and continues to grow, regardless of the complexity of wiki markup.
> This kind of reactionary opposition to the addition of features to
> wiki markup is unwarranted. We already have wiki markup for
> mathematical formulas and even Egyptial hieroglyphics. Why is support
> for dialect variants such an onerous addition? Do want to not
> implement a feature that actual people want and desire and will use
> because there may be hypothetical people who might not join the
> project because we have the feature?
>
> It seems to me that the syntax for templates, image thumbnails,
> tables, and mathematic formulas have already made the wikitext hard to
> read and understand for new users. The reality is that in the creation
> of an encyclopedia, there are complicated things and ideas that
> require complicated markup. Is localized dialectical consistency not
> something worth striving for? And who should make that decision?
>
> Is
>
> The -{en-us colors; en-gb colours}- of the U.S. flag are red, white
> and blue.
>
> going to dissuade users from editing an article any more than the
> following?
>
>
 7px;">If you were looking for an article on the abbreviation "VFD",
> please see [[VFD]].

>
> {{Shortcut|[[WP:VFD]]}}
> {{deletiontools}}
> {{VfD_header}}
>
> [http://en.wikipedia.org/w/wiki.phtml?title=Wikipedia:Votes_for_deletion&action=edit&section=0
> edit]
>
> Rather than trying to live in the fiction that en-us and en-gb are
> equally understandable and mutually compatible, we should admit that
> they are different, that those differences can and empirically do
> cause problems, and that we should create a solution to solve it.
>
> - David Friedland

Please consider that there is English spoken outside us and uk, consider
our dear friends down under, who are said to be understandable while
speaking English, Please consider these poor sods who do not speak
English right from the tit. Yes, there are differences, but when I,
someone from the Netherlands am to write stupid markup where I am not
even really aware if it is American or English what I write, I promis
you that you will find many people like me leaving the English wikipedia
as an editor.

The difference with table markup and whatever markup is, that they add
value, they add content that everyone understands. Not only that, this
mark-up works in ALL wikipedia and is not so parochial. The difference
between en-uk or en-us or en-au is not something that adds value for
many, while complicating wiki beyond recognition. If this extra markup
is hidden from view when editing, we are talking. But as long as we are
to see this markup, we will lose many people and for what, for who ?

Thanks,
    GerardM


from_name: Ashar Voultoiz

subject: [Wikitech-l] devs and admins blog

body:
Hello,

I am willing to know if we are willing to use a blog software to
communicate with wikipedians and mediawiki users.

Developpers and wikifarm administrators will be able to post lengthy
articles about the various things happening. Be it new servers added to
the farm, new features being developped or polling the user base to help
us make choices.

We already have this mailing list, irc to discuss issues but important
announcments are flooded with questions and generals ideas. We also have
  the server admin log wich is great for the hour per hour action
logging as well as for internal documentation. But I think a blog will
attract more people and will easily provide rss feed + comments :o)

This afternoon I ported monobook to the serendipity blog software. You
can have a quick look at it on http://www.twenkill.net/serendipity/ .

cheers,

--
Ashar Voultoiz


from_name: Anthere

subject: [Wikitech-l] Re: devs and admins blog

body:
you dropped the forum idea ? :-)

Ashar Voultoiz a ?crit:
> Hello,
>
> I am willing to know if we are willing to use a blog software to
> communicate with wikipedians and mediawiki users.
>
> Developpers and wikifarm administrators will be able to post lengthy
> articles about the various things happening. Be it new servers added to
> the farm, new features being developped or polling the user base to help
> us make choices.
>
> We already have this mailing list, irc to discuss issues but important
> announcments are flooded with questions and generals ideas. We also have
>  the server admin log wich is great for the hour per hour action logging
> as well as for internal documentation. But I think a blog will attract
> more people and will easily provide rss feed + comments :o)
>
> This afternoon I ported monobook to the serendipity blog software. You
> can have a quick look at it on http://www.twenkill.net/serendipity/ .
>
> cheers,
>


subject: [Foundation-l] Re: Support for local chapters

body:
Angela a ?crit:
> I have never been opposed to local chapters, and I am upset that
> people are under the mistaken impression that I am.
>
> Angela

It was in trying to reorganise the whole page, and archive all bits that
seemed to be old talk, because the page was getting very heavy and
confusing, while keeping some of the unadressed comments, and I made the
mistake.
There were two paragraphs, and answers from me in between, with Angela
signature under the second and no signature under the first. In moving
and archiving it all, in an attempt to clarify who said what, I added
Angela signature to what has been in reality an anon comment (visible in
history).

I really apology for this, and I hope Angela will believe it was not
done in bad faith. I really thought it was her position at that time,
though I totally had the feeling she had changed her position later on.
I should have realised my mistake. I am sorry Angela.