from_name: Yann Forget

subject: [Wikitech-l] Images used in templates are shown as orphan

body:
Hi,

Images used in templates are shown as orphan on fr:
Is this bug already known?

cf.
1. http://fr.wikipedia.org/wiki/Image:Shiva.jpg
used in http://fr.wikipedia.org/wiki/Shiva
2. http://fr.wikipedia.org/wiki/Image:Narmada.jpg
used in http://fr.wikipedia.org/wiki/Narmad?

http://fr.wikipedia.org/w/wiki.phtml?title=Special:Unusedimages&limit=100&offset=1800
Image #1872

This is the case for all images included in templates that I can see.

Yann

--
http://www.non-violence.org/ | Site collaboratif sur la non-violence
http://www.forget-me.net/ | Alternatives sur le Net
http://fr.wikipedia.org/ | Encyclop?die libre
http://www.forget-me.net/pro/ | Formations et services Linux


list: wikipedia-l

source: pipermail-mbox

from_name: Henry H. Tan-Tenn

subject: [Wikipedia-l] Re: Peh-oe-ji on minnan.wikipedia.org (clarification)

references:
<cf4paf$2j3$1@sea.gmane.org>
	<cf5gna$7cd$1@sea.gmane.org>	<20040809001909.A64440@formosa.org>
	<cf5ka4$dp3$1@sea.gmane.org>

body:
Tim Starling wrote:

> The point is that Peh-oe-ji is not representative of Min Nan. There are
> millions of Min Nan speakers who do not use a romanised script,
> hopefully I am speaking for their interests.

I was also puzzled by your juxtaposing zh and minnan, as if the latter
must necessarily follow from the former in terms of how a language is
written.  People who happen to speak Minnan contribute whichever
Wikipedia they happen to be interested in (hopefully with proficiency).

Now, more to the point, your claim that "millions of Min Nan speakers"
don't know a romanized script is *absurdly* true.  But that does not
mean knowing a Chinese script (be it Traditional, Simplified) -- which
is taught for Mandarin -- means these speakers are a community of Min
Nan readers/writers.  As an analogy, knowing your ABCs does not mean you
know how to spell English or French.  Most Min Nan speakers do not write
Min Nan, have never been taught how to write Min Nan.  Among those who
do -- and that still leaves tens of thousands by my unscientific
estimate -- some have come to Wikipedia.

Is that a surprise?  Look at the many dozens of Wikipedia language
subdomain names reserved for all those languages.  Why are they vacant,
seemingly dead?  Undoubtedly there are many reasons:
material/technological hurdles, economics (expense), educational,
political, few speakers to begin with, etc.  I submit that a major
reason is that speakers of some of those languages, for political,
cultural, or economic reasons, are illiterate.  The writing system may
also not be standardized.  But at some time during the course of a
language's development, *some*, perhaps only a few, speakers must start
to read and write that language to get things going.  That is what we
Min Nan editors have been doing.  If what we do, as literate
reader/writers of Min Nan, fail to match your expectation, that is not
our fault.  We did not *invent* POJ, which has been around for 150
years.  Nor are we *reviving* POJ, which has never stop being used
(though governments have tried to suppress it) and thus needs no
reviving.  Nor is POJ a Taiwanese particularity (we have non-Taiwanese
editors).  In a sense we are *promoting* it through Wikipedia, but that
is what every Wikipedia does implicitly by writing in a language.

~~~~


list: wikien-l

from_name: Martin Harper

subject: [WikiEN-l] anons and new articles

body:
> Another idea would be to not allow anons to create new articles
> (editing existing articles would still be allowed). They would get a
> message after following a red link that invites them to create a
> user account so that they can create a new page

Rather than *forbidding* or *allowing* things, why not use a more
gentle method of discouragement? Simply don't display red links to
anonymous editors. They can still create articles if they really want
to by going directly to the appropriate URL, and experienced
anonymous contributors would no doubt do just that.

I think this would also improve the reading experience for those who
have no intention of editing.

-Martin


from_name: Daniel P.B.Smith

subject: [WikiEN-l] Re: 200-byte rule; all stubs not equally valuable

body:
> From: Fred Bauder <fredbaud at ctelco.net>
> Why don't you just leave stubs alone and let them develop into articles
> through a natural process?
>
> Fred

That assumes that they _will_ develop into articles. Some stubs are
useful nuclei around which articles will crystallize. Others aren't. To
assume that all stubs are equally valuable is silly.

Stubs were probably more useful in Wikipedia's early days as
placeholders to flag important pieces of missing content than they are
now.

Let me try a test. I'm going to look in newpages right now. I am going
to look at the most recent new page with an article length of less than
200 bytes, and then I am going to look at most recent new page with an
article length between 200 and 300 bytes.

Most recent under-200-byte page:
     **
IRISH LEPRECHAUN: A leprechaun is a creature from the folklore of the
irish...it is believed that such creatures are related to fairies.
according to tales of these beasts, if followed, they can lead one to a
pot of gold at the end of the rainbow
     **

Given that we have a 2469-byte article on "Leprechaun" (which is short
on serious or scholarly folkloric content, but is a decent description
of the leprechaun as known in modern popular culture--and includes
everything in "Irish Leprechaun" and more.)

Do you seriously think that "Irish Leprechaun" should be left to grow?
Do you think it is going to become a scholarly essay on how Irish
leprechauns differ from those of other nations? Or do you think it
should become a redirect to "Leprechaun"

Most recent 200-to-300-byte page:
      **
COTILLION: Cotillion is a formal presentation of young ladies to
society that have been recommended by a distinguished committee. The
beneficiary is Children's National Medical Center. The National
Debutante Cotillion and Thanksgiving Ball of Washington D.C. is 55
years old in 2004.

This article is a stub. You can help Wikipedia by expanding it .
     **

Now, that, to me, is a perfectly reasonable stub.

I don't know that the 200-byte rule is infallible, but I just tried it
for the first time, and it seemed to work.

--
Daniel P. B. Smith, dpbsmith at verizon.net
"Elinor Goulding Smith's Great Big Messy Book" is now back in print!
Sample chapter at http://world.std.com/~dpbsmith/messy.html
Buy it at http://www.amazon.com/exec/obidos/ASIN/1403314063/


list: wikitech-l

from_name: Eric Pierce

subject: [Wikitech-l] (no subject)

body:
Alfio Puglisi <puglisi at arcetri.astro.it> wrote:

> Compressing 2.5 GB of images you won't gain
> anything. And compressing the html files will
> make them less easy to browse. Likely an
> installer would be needed.

Mozilla does on-the-fly decompression of tar.gz files,
at least. Might take an extra split-second to open an
article.

Eric

=====
Do you know stuff? Contribute to Wikipedia! http://www.wikipedia.org/
Help preserve the public domain by becoming a Distributed Proofreader. http://www.pgdp.net/

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail


from_name: Timwi

subject: [WikiEN-l] Re: Sub-stub city

body:
Hi.

Please could you tell your mail software to use word-wrapping? Thanks.

> I think 200 bytes is a reasonable lower limit.  [...]
> That would eliminate almost all tests in the article space and increase
> the likelihood that an article has at least some useable context to it.

I doubt that. I think it would only encourage more wordy tests. Instead
of "Bush is gay" people will just write "Bush is gaaaaaaaay" (with loads
more a's). Or if someone is posting a dicdef I think they're likely to
fill the article with newlines at the end to bring it to 200 bytes. It
really doesn't help the specific problem you've mentioned.

If we introduced your suggested mechanism, we would be acting against
our own philosophies. In loads of places we brag how everyone can
contribute, and advise people to "be bold". You are now essentially
saying that some contributions should not be accepted, and some people
should not be bold. I disagree.

Wikipedia brags about its self-healing abilities. People patrolling RC
and NP are valuable because they make this self-healing work. The
"correct" way to "fix" this situation is what Daniel Mayer mentioned:
Allowing logged-in users (or only admins) to "flag" an edit to show
others that it's been looked at. This eliminates duplicate work, but it
does not restrict the ability of anyone to post new articles or make any
other edit.

Timwi


from_name: Fred Bauder

body:
> From: "Daniel P.B.Smith" <dpbsmith at verizon.net>
> Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
> Date: Sun, 8 Aug 2004 13:54:22 -0400
> To: wikien-l at Wikipedia.org
> Subject: [WikiEN-l] Re: 200-byte rule; all stubs not equally valuable
>
>> From: Fred Bauder <fredbaud at ctelco.net>
>> Why don't you just leave stubs alone and let them develop into articles
>> through a natural process?
>>
>> Fred
>
> That assumes that they _will_ develop into articles. Some stubs are
> useful nuclei around which articles will crystallize. Others aren't. To
> assume that all stubs are equally valuable is silly.
>
> Stubs were probably more useful in Wikipedia's early days as
> placeholders to flag important pieces of missing content than they are
> now.
>
> Let me try a test. I'm going to look in newpages right now. I am going
> to look at the most recent new page with an article length of less than
> 200 bytes, and then I am going to look at most recent new page with an
> article length between 200 and 300 bytes.
>
> Most recent under-200-byte page:
> **
> IRISH LEPRECHAUN: A leprechaun is a creature from the folklore of the
> irish...it is believed that such creatures are related to fairies.
> according to tales of these beasts, if followed, they can lead one to a
> pot of gold at the end of the rainbow
> **
>
> Given that we have a 2469-byte article on "Leprechaun" (which is short
> on serious or scholarly folkloric content, but is a decent description
> of the leprechaun as known in modern popular culture--and includes
> everything in "Irish Leprechaun" and more.)
>
> Do you seriously think that "Irish Leprechaun" should be left to grow?
> Do you think it is going to become a scholarly essay on how Irish
> leprechauns differ from those of other nations? Or do you think it
> should become a redirect to "Leprechaun"

It should become a redirect to "Leprechaun"
>
> Most recent 200-to-300-byte page:
> **
> COTILLION: Cotillion is a formal presentation of young ladies to
> society that have been recommended by a distinguished committee. The
> beneficiary is Children's National Medical Center. The National
> Debutante Cotillion and Thanksgiving Ball of Washington D.C. is 55
> years old in 2004.
>
> This article is a stub. You can help Wikipedia by expanding it .
> **
>
> Now, that, to me, is a perfectly reasonable stub.

How about [[fandango]], a dance or party among the multi-cultural society
which developed among the [[mountain men]] during the early 19th century in
the American west.?
>
> I don't know that the 200-byte rule is infallible, but I just tried it
> for the first time, and it seemed to work.
>
> --
> Daniel P. B. Smith, dpbsmith at verizon.net
> "Elinor Goulding Smith's Great Big Messy Book" is now back in print!
> Sample chapter at http://world.std.com/~dpbsmith/messy.html
> Buy it at http://www.amazon.com/exec/obidos/ASIN/1403314063/
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l


subject:
[WikiEN-l] Display reason for article deletion to anons? (was:
 anons and new articles)

body:
Martin Harper wrote:

>>Another idea would be to not allow anons to create new articles
>>(editing existing articles would still be allowed). They would get a
>>message after following a red link that invites them to create a
>>user account so that they can create a new page
>
> Rather than *forbidding* or *allowing* things, why not use a more
> gentle method of discouragement? Simply don't display red links to
> anonymous editors. They can still create articles if they really want
> to by going directly to the appropriate URL, and experienced
> anonymous contributors would no doubt do just that.

Although you're right that we don't want to "forbid" or "disallow"
legitimate editing, I don't think we want to discourage it either. Your
suggestion makes it harder for well-meaning newbies to find out how to
edit or create articles.

A better way would be to encourage more healing. We already have the
"stub" message which encourages newbies to expand a stub they encounter.

One idea I was toying with in my mind recently is this. When sysops
delete an article, the article goes back to saying "Wikipedia does not
have an article with this title yet." Maybe we should actually let
everyone (including anonymous users) know that there used to be an
article, and (this is the important part) show the reason for its deletion.

If a newbie goes back to see what happened to their article, and they
see it gone, they are more likely to just put it back in (it looks to
them more like a glitch in the system or an accident than a deliberate
deleting). If it actually said "This article was deleted for the
following reason: vandalism", they are more likely to ackowledge that
putting their article back in is going to have the same effect again.

Timwi


subject: [Wikipedia-l] Re: Peh-oe-ji on minnan.wikipedia.org

body:
Tim Starling wrote:

> All the same, I'd like to hear
> any comments or objections anyone has.

I might not have anything helpful to say that will bring the matter
closer to resolution, but I'd just like to state here that I'm very
impressed with your research, and the dedication you put into it. I
didn't even know you were interested in Taiwanese linguistics. :)

It's nice to know that someone is taking care of the smaller wikis that
have outstanding issues. Thanks, Tim!

Timwi


subject:
[WikiEN-l] Display reason for article deletion to anons? (was:
	anons and new articles)

body:
On Sun, 08 Aug 2004 14:15:52 +0100, Timwi wrote:

> One idea I was toying with in my mind recently is this. When sysops
> delete an article, the article goes back to saying "Wikipedia does not
> have an article with this title yet." Maybe we should actually let
> everyone (including anonymous users) know that there used to be an
> article, and (this is the important part) show the reason for its deletion.

That wouldn't work with the way things are currently deleted as sysops
usually don't type a reason when deleting speedy deletion candidates.
They leave the full text of the article as the deletion reason, which
helps others to check what has been deleted as any user can read this
text in the deletion log.

As an alternative, I've added the following to [[MediaWiki:Noarticletext]]:
 * If you created an article under this title previously, it may have
been deleted. See [[Wikipedia:Candidates for speedy deletion#The
cases|candidates for speedy deletion]] for possible reasons.

Perhaps this will help explain to newcomers where their article went.

Angela.


list: foundation-l

subject: [Foundation-l] Re: Copyright issues...walking on thin ice

body:
>> The legal risk lies with the user who uploaded it

I was basing this on the statement made in the Submission standards,
previously linked to from our terms of use.
http://en.wikipedia.org/w/wiki.phtml?title=Wikipedia:Submission_Standards&oldid=2470321#Your_indemnification_of_Wikipedia.

"Your indemnification of Wikipedia

In all cases if you submit anything you are responsible for the
submission, not Wikipedia. Should there be any legal consequences you
specifically agree that you indemnify and hold harmless Wikipedia,
Wikimedia Foundation Inc., Bomis Inc. their officers, directors or
agents, and the other volunteers of Wikipedia. Such indemnification
includes costs and reasonable attorneys fees; you indemnify these
entities and individuals from any claims, suits, causes of action in
law or equity, judgments, levies, fines, whatsoever from the time of
your first contribution to Wikipedia or any other Wikimedia project.
Any individual making a submission to Wikipedia will not benefit from
this indemnification vis-?-vis other contributors if their submissions
are in violation of these standards."

Angela.


list: wikimedia-l


from_name: Ray Saintonge

subject: [Wikipedia-l] Re: Request for the second Serbian Wikipedia

body:
Thomas R. Koll wrote:

>On Sun, Aug 08, 2004 at 06:52:05PM +0100, Timwi wrote:
>
>
>>millosh wrote:
>>
>>
>>>So, I think that we can do something like this: We can make secondary
>>>Serbian Wikipedia using secondary two-letters code for Serbian language:
>>>sp.
>>>
>>>
>>Or, alternatively, you can create two pages for each article on the
>>Serbian Wikipedia, one in Latin and one in Cyrillic, similar to the way
>>the Chinese Wikipedia handles traditional and simplified characters.
>>
>>
>I think that would be even easier than on zh-* because they don't share many
>letters if any.
>
>
I suppose this all depends on there being a reversible one-to-one
relationship between the two versions of Serbian.

Ec


from_name: Magnus Manske

subject: [Wikitech-l] Wikipedia exceeds DVD size

body:
Krzysztof Kowalczyk wrote:

>Once you start going down the "standalone browser" road, adding on-the
>fly decompression of data is quite easy (compared to all other stuff
>that would likely need to be done).
>
>
I  will use this opportunity to shamelessly plug the "waikiki" module in
the CVS tree, which already does this, except compression. But, being
C++, the database is realized as a class, which would make it easy to
insert some compressing/decompressing code.

I also use the waikiki thing with a (initially) blank database as
notes-on-USB-stick, as it can also write the sqlite database. Quite handy.

Magnus


subject: [WikiEN-l] Sub-stub city

body:
Stephen Adair wrote:

>I think 200 bytes is a reasonable lower limit.  Under 200 bytes gets you a message about needing more substance (or some more tactful word) before an article can be created, along with a link to the sandbox for those who want to practice editing.
>
>

Why not have the software add {{autostub}} or
[[Category:Wikipedia:Automatic stub]] to every new article below, say,
500 bytes? That would keep track of those and give stubhunters a list of
what to look at. If it is a "legimate stub", replace the automated
message with {{stub}}.

Magnus


body:
millosh wrote:

>You say that I work against the decision of community... Scripts are not the problem, I understand functions of bots. The problem is decision of community, and this is not to work in Latin alphabet on sr:.
>
This is puzzling.  If nobody wants a Latin alphabet version than why are
we even bothering with this conversation?

If a significant minority wants to have a Latin version, then a majority
vote against that should not be an excuse for restricting the rights of
the minority.  It appears that the technical means are available that
will allow the two versions to co-exist in one project.

Ec


from_name: Dietrich von Hase

body:
Michael Snow wrote:

> Angela_ wrote:
>
>>On Sat,  7 Aug 2004 18:44:52 -0400, mbecker wrote:
>>
>>
>>>Even if this is fair use, what's stopping the copyright holders from suing the wikimedia foundation, and incurring a great deal of legal fees?
>>>
>>>
>>The legal risk lies with the user who uploaded it and claimed it was
>>fair use, not with the Foundation.
>>
> Even if the Foundation would ultimately prevail on the merits, it's
> still correct that the copyright holders can sue, and can force us to
> incur serious legal fees. Also, the publisher can be liable for
> copyright infringements, so I think it's inaccurate to suggest that
> there's no legal risk to the Foundation. More correct is Angela's
> later statement that OCILLA protects us to some extent.

May I add that - as English is spoken also in many other countries where
there are no fair use regulations in copyright law - the copyright
holder can - in principle -  sue the individual publisher there as the
online edition of wikipedia is offered and used internationally. Also
the foundation could be sued in other countries as the foundation
already knows about fair use images being published worldwide including
countries where the fair use principles are not supported by law or
jurisdiction. There might however be some protection for the foundation
being located in the US, but not in principle, it only makes it more
difficult for the copyright holder. In case the foundation did not know
about possible copyright violations of an image put online by an
individual publisher it cannot be sued for the mistake by others. But
since the foundation knows that there many pictures are neither public
domain nor published under open content license such jurisdiction would
not apply in the case of pictures under fair use US regulations on
courts of countries without fair use legislation.

As cameras are around today nearly everywhere and it is easy for
everybody to make photos and there is also much open content or public
domain material around - I personally think that it would not harm the
success of Wikipedia in any way when fair use images are no more
included. The growth rate of the number of images published on Wikipedia
is about 25% a month - much larger then the growth rate of articles.

Dietrich


from_name: Jens Ropers

subject:
[WikiEN-l] electronic reproduction permission request -- Nick Ut's
	"naked girl running from napalm attack" photograph of Kim
	Phuc Phan Thi

body:
Dear Sir/Madam of the Associated Press,

	cc: English Wikipedia Mailing List <wikiEN-L at Wikipedia.org>

I am writing on behalf of the Wikipedia, the free Internet encyclopedia
(http://wikipedia.org), of which I am a contributor.

An anonymous contributor has recently uploaded the following image --
of which I believe you hold the copyright  -- to the Wikipedia:
	http://en.wikipedia.org/wiki/Image:TrangBang.jpg
In case the picture is already deleted by the time you access that link:
The picture in question is Huynh Cong (Nick) Ut's "naked girl running
after napalm attack" photograph of Kim Phuc Phan Thi.

As we have become aware of potential copyright issues with the
aforesaid photograph, proceedings have been initiated to delete the
picture.
However I would like to kindly ask you, on behalf of Wikipedia, to
please consider granting us permission for reproduction of the said
picture on the Wikipedia.

The Wikipedia is an Internet based free volunteer project by the
non-profit Wikipedia Foundation. As such we cannot unfortunately offer
payment.
However, I would like to make the following points in favour of
licensing the picture for Wikipedia use:

- You would leave a lasting very positive impression of the Associated
Press to Wikipedia users and Internet users worldwide. An appropriate
caption could be added to that effect.
- You would not loose any rights to the picture, as NOT all pictures on
the Wikipedia are in the public domain and neither does the GNU Free
Documentation License always apply. Copyrighted pictures have been
licensed for Wikipedia use before. A caption could clearly state this
and even made part of the picture.
- You would do the public a service and combat disinformation: The
picture is at the center of various disputes on Wikipedia, with those
contributors most emphatically seeking its removal having a politicized
edit history: For example, they have denied that the U.S. strike
documented by the picture was carried out by the U.S.; this despite the
fact that Kim Phuc's meeting with John Plummer is well documented.
- Please also consider that by licensing the picture for Wikipedia use,
you would NOT loose potential revenue -- due to the volunteer nature of
the project, Wikipedia cannot incorporate any for-fee material (like
conventional encyclopedias can). If we cannot convince you to kindly
grant permission, we would simply have to refrain from using the
picture.
- Also, the image file which was uploaded to us is low resolution and
unfit for print publication. Thus, hypothetically, even if some party
intended to maliciously copy the file from the Wikipedia for further
reproduction, they would find it of rather limited use.

Please be invited to visit http://en.wikipedia.org to find out more
about the Wikipedia.

(The Wikipedia is also available in many languages other than English
-- including Vietnamese:
http://en.wikipedia.org/wiki/Main_Page#Wikipedia_in_other_languages ,
http://vi.wikipedia.org.)

Thanks and regards,
Jens Ropers

There are two types of IT techs: The ones who watch soap operas and the
ones who watch progress bars.
http://www.ropersonline.com/elmo/#108681741955837683

PS: I am writing all this on the assumption that you are indeed the
current copyright holder and that the picture's use with Wikipedia is
not covered under the "fair use" principle. Should I be wrong, then I
don't mean to make any misrepresentation one way or the other. I am
again assuming that you hold the copyright and that we cannot use the
picture without your permission, but I have no special insight into the
matter. Should you choose to deny us permission to use the picture, I
would urgently pass that message on to the relevant admins, where such
clarification from your side will certainly lead to a speedy resolution
of the issue.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3910 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20040808/66af7096/attachment.bin


from_name: David Gerard

subject:
[WikiEN-l] Nationalist POV-pushing on Wikpedia: what to do? (was
	Azerbaijan and Iran related articles)

body:
On 08/08/04 14:37, Jens Ropers wrote:

> IMHO nationalist POV has been a problem on Wikipedia for a LOOONG time:
> U.S. nationalist POV, that is.
> Examples?
> I'll give you an example:
> I've seen an article where it was disputed that the warfare use of
> napalm constituted chemical warfare, and where the caption to a famous
> picture showing the consequences of a U.S. napalm attack was changed --
> the contributor simply disputed whether the U.S. had been responsible
> for the Vietnam napalm attack. Later _the same contributors_ suddenly
> discovered that there were copyright issues with the use of the
> picture... (See my previous email to AP I cc'd you on.)
> But of course: It would have been a "Vietcong" trick, right? Bomb their
> own, have a photo shot, discredit the poor battered U.S. internationally...
> Yeez...
> I could not possibly make up a better real world example of George
> Orwell's [[Doublethink]] (of 1984, see WP article).
> Really folks, I do rarely, in this day and age, ever see people whose
> moral compasses and standards of truthfulness are so *seriously* out of
> whack as a certain group of U.S. "patriots".

Heh. You do realise I'm not American? (Australian living in London.)

- d.


body:
see below:

On 8 Aug 2004, at 05:21, fun at thingy.apana.org.au wrote:

> Message: 8
> Date: Sun, 8 Aug 2004 09:33:06 +1000
> From: David Gerard <fun at thingy.apana.org.au>
> Subject: [WikiEN-l] Nationalist POV-pushing on Wikpedia: what to do?
> 	(was	Azerbaijan and Iran related articles)
> To: English Wikipedia <wikien-l at Wikipedia.org>
> Message-ID: <20040807233306.GA18928 at thingy.apana.org.au>
> Content-Type: text/plain; charset=us-ascii
>
> S.Vertigo (sewev at yahoo.com) [040808 05:43]:
>
>> How about just protecting them, use a very condensed
>> version of the {{protected}} banner, (its just too
>> much text and graphics people) and make people work on
>> a proxy draft instead?
>
>
> Hasn't worked - the anons don't talk, they just revert. Protecting one
> page
> for a month did nothing - they just came back when it was unprotected
> and
> started over.
>
> Nationalist POV pushing is becoming a real problem on Wikipedia.
> Particularly in cases where it appears semi-official, as with these
> cases
> and with User:Levzur on Georgia-related articles. I suspect a series
> of AC
> rulings as we go isn't really the best way to approach the problem.
> What
> can we do abouthis sort of thing? Gdansk/Danzig is just the tip of it.
>
>
> - d.

I'm going to say something EXTREMELY unpopular -- because _it needs to
be kept in mind_ in this context:
(and no, I'm not trying to have a go at anybody with this)

IMHO nationalist POV has been a problem on Wikipedia for a LOOONG time:
U.S. nationalist POV, that is.

Examples?
I'll give you an example:
I've seen an article where it was disputed that the warfare use of
napalm constituted chemical warfare, and where the caption to a famous
picture showing the consequences of a U.S. napalm attack was changed --
the contributor simply disputed whether the U.S. had been responsible
for the Vietnam napalm attack. Later _the same contributors_ suddenly
discovered that there were copyright issues with the use of the
picture... (See my previous email to AP I cc'd you on.)

But of course: It would have been a "Vietcong" trick, right? Bomb their
own, have a photo shot, discredit the poor battered U.S.
internationally...
Yeez...
I could not possibly make up a better real world example of George
Orwell's [[Doublethink]] (of 1984, see WP article).
Really folks, I do rarely, in this day and age, ever see people whose
moral compasses and standards of truthfulness are so *seriously* out of
whack as a certain group of U.S. "patriots".

I do _not_ dispute that there are _big_ problems as regards non-U.S.
nationalist POV -- and I don't have a magical solution to that.
But I also seem to remember some story about a chip and a beam,
respectively... in some person's eyes...

What I'm trying to say is that, _especially_ with the inherent pro-U.S.
slant that's simply due to the large number of U.S. WP contributors,
it's IMPOSSIBLE for "the rest of us" to go it alone in trying to
balance things out. Given the said slant, I would like to appeal that
seriously minded U.S. NPOVers _help wherever they can_ and -- keeping
the above in mind -- always seek to apply _more_ restraint and a
_stricter_ standard whenever there is a possible U.S. side to an issue.
It's probably the only way we're going to get a lid on U.S. nationalist
POV.

And, yes, I too believe that it's utterly fruitless to start a
discussion on which country's contributors have the worst nationalist
POV offenders among them. But it can't hurt to keep the above in mind,
can it?

Thanks and regards,
Jens Ropers

There are two types of IT techs: The ones who watch soap operas and the
ones who watch progress bars.
http://www.ropersonline.com/elmo/#108681741955837683

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3786 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20040808/70e9e7b2/attachment.bin


from_name: Gertjan

subject: [Wikipedia-l] How to make a new Wiki? Pleas help me...

body:
How do I make a Kiribati language Wikipedia?

I am allready active on the Dutch, French, English and Nauruan Wikis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20040808/eaf4a3d8/attachment.htm


from_name: Milos Rancic

subject: [Wikipedia-l] Request for the second Serbian Wikipedia

body:
Hello,

I am Milos and I am bureaucrat on sr:

First of all, I have to tell you some introduction in our alphabet problems.

Until the second half of 19th century Serbs used only Cyrillic alphabet. (In the ancient history, Serbs was using Latin and Glagolic alphabet for a short time, but without stronger cultural consequences.) Between the second half of 19th century and the end of The Second World War, Latin alphabet was not used a lot; it was used by very small number of writers. After the end of WWII, strong cultural influence of Communist Party of Yugoslavia gave to Serbs active usage of Latin alphabet. During 1980's and 1990's Latin alphabet was used more often then Cyrillic (maybe 60%, maybe even 70%). Today, the situation is something about 50-50 with tendency of Cyrillic usage growth. In this moment we have very strong xenophobic movement. A lot of them are very active on Internet and on Wikipedia, too. They do not accept Latin alphabet as "Serbian". Even a lot of people use Latin alphabet.

I made voting for the question: Would Serbian Wikipedia has Latin pages too? Even the end of August is the end of voting for that question, I think that usage of Latin alphabet would not pass. Situation is 4:2 against and Serbian Wikipedia doesn't have a lot of active users (we have one or two new users which can't vote).

Even I use Cyrillic alphabet, I relies that usage of Latin alphabet is important for us: We have significant minority (about 50%!) of Latin users and if anyone starts to search on Internet, (s)he uses Latin alphabet, not Cyrillic (usually even without Serbian Latin letters). We have very ironic situation: If you type the name of one of Serbian 19th century writers, Radoje Domanovic (in Serbian Cyrillic: ?????? ?????????, in Serbian Latin: Radoje Domanovi?) in Google, you will get: (1) Cyrillic: Serbian Wikipedia is on the first place; (2) Any Latin: Wikipedia doesn't exists.

So, I think that we can do something like this: We can make secondary Serbian Wikipedia using secondary two-letters code for Serbian language: sp. It would not be "real" Wikipedia, because it should be used only for transliteration of Cyrillic Wikipedia (transliteration from Serbian Cyrillic to Serbian Latin is algorithmic, the reverse process is fuzzy). All of the pages on sp: should be "protected" and when someone writes something on Cyrillic Wikipedia, it should be transliterated to Latin, too. Also, all of users should be the same.

I think it is good solution because we would not have multiplication of work (such as we have now: Croatian, Bosnian and Serbo-Croatian Wikipedias are using the (very, very) almost the same language). All of people would work on sr:, not on sp:.

Also, I have some notes to developers (if the request passes): about technical solution for that. It would not any consequence to Wikimedia's performances because it is (almost) row transliteration.

Best,
Milos


from_name: Daniel Mayer

body:
--- Dietrich von Hase <hase at akademie.de> wrote:
> ....
> As cameras are around today nearly everywhere and it is easy for
> everybody to make photos and there is also much open content or public
> domain material around - I personally think that it would not harm the
> success of Wikipedia in any way when fair use images are no more
> included. The growth rate of the number of images published on Wikipedia
> is about 25% a month - much larger then the growth rate of articles.

Until time machines are created so that the cameras you talk about could be
used to snap photos of people now dead, events now past, and places now gone,
we will continue to need to use low resolution versions of these images.

However, you do correctly note that we should not depend on the fair use
doctrine in the U.S. We should instead work with more international doctrines
such as fair dealing (which covers much of the English Speaking world and is a
bit more restrictive than fair use and thus will be fine in the U.S. as well).
But this would be much less useful for non-English wikis (each language wiki
should develop its own policy on this).

-- mav

__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail


subject: [WikiEN-l] anons and new articles

body:
--- John Lee <johnleemk at yahoo.com> wrote:

> Like Fred, I think this goes against the spirit of a Wiki. Wikis thrive
> on the contributions of anonymous people. We wouldn't be anywhere near
> as successful as we are today if we didn't give anons the freedom they
> have now.

Wiki is a means to end, not an end in itself. We are buiding an encycloedia
here first and foremost. So when the people who are on new page patrol start to
complain about the volume of anon-created substubs and junk new pages, then we
should take that seriously. Looking at the issue, it would seem that making it
a bit more difficult for anons to create new pages (or at least sub-200 byte
pages) would solve a large part of the problem. Anons will still be able to
edit and at this point *improving* the articles we already have should be
encouraged over creating more tiny articles.

But this should be a wiki-by-wiki feature. Smaller wikis *need* to encourage
the creation of many small articles in order to seed topics. With well over
300,000 articles, the English Wikipedia no longer needs to do concentrate on
that so much. We already have too many seeds for the amount of fertilizer and
water on hand.

-- Daniel Mayer (aka mav)

__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now.
http://messenger.yahoo.com


subject: [WikiEN-l] Re: Sub-stub city

body:
--- Timwi <timwi at gmx.net> wrote:
> ...
> Wikipedia brags about its self-healing abilities. People patrolling RC
> and NP are valuable because they make this self-healing work. The
> "correct" way to "fix" this situation is what Daniel Mayer mentioned:
> Allowing logged-in users (or only admins) to "flag" an edit to show
> others that it's been looked at. This eliminates duplicate work, but it
> does not restrict the ability of anyone to post new articles or make any
> other edit.

If we did have such a team-based approach to patrol, then we may be able to
delay having to start locking things up for some time - perhaps indefinitely.

So yes, that would be the best of all proposed options.

-- Daniel Mayer (aka mav)

__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail


from_name: Erdal Ronahi

subject: [Wikipedia-l] Re: Re: Re: Request for the second Serbian Wikipedia

body:
Hello everybody!

We use two scripts on the Kurdish Wikipedia, too. Ours may be even stranger,
because it uses latin and arabic (right-to-left) script. Of course the interface
is only in latin script.

I think two scripts in the serbian Wikipedia may be the best solution, if it's
not a problem that the interface can't have both.

Just because I'm curious, can everybody in Serbia read both alphabets?

Greetings,
Erdal


from_name: Tim Starling

subject: [Wikipedia-l] Peh-oe-ji on minnan.wikipedia.org

body:
About a month ago, Shizhao requested that the wiki at
minnan.wikipedia.org be moved to poj.wikipedia.org, because the writing
there is Taiwanese, and not representative of Min Nan as a whole:

http://mail.wikipedia.org/pipermail/wikitech-l/2004-July/011003.html

Kaishu Tai ridiculed the POJ term as "meaningless", and requested that
the wiki be moved to zh-min-nan.wikipedia.org instead.

http://mail.wikipedia.org/pipermail/wikitech-l/2004-July/011013.html

I didn't know who to believe, and although I made some attempt to make
sense out of it, the end result was the status quo.

Just today, I did some reading of my own on the subject. The best
reference I found was this:

http://www.de-han.org/taiwan/chuliau/pehoeji-v.pdf

Other information sources are:
http://203.64.42.21/iug/ungian/POJ/siausit/2002/2002POJGTH/lunbun%5CK2-kloeter.pdf
http://en.wikipedia.org/wiki/Taiwanese_%28linguistics%29

Contrary to what Shizhao said, it seems that the Peh-oe-ji orthography,
as seen on minnan.wikipedia.org, is not even representative of
Taiwanese, let alone Min Nan. In fact it is only used by a small
minority. Now I have every respect for the goals of those who promote
Peh-oe-ji, but I don't think Wikipedia should assign subdomains which
support one political viewpoint over another.

Currently the predominant form of writing in Taiwan is "Traditional
Chinese", given the code zh-tw. Writing of this form is commonly used on
zh.wikipedia.org. The Taiwanese people who write in zh.wikipedia.org
speak the exact same language as those who write on
minnan.wikipedia.org. That language is a form of Min Nan, referred to in
Taiwan as Ho-lo-oe.

Based on the information I have now, I would like to move
minnan.wikipedia.org to peh-oe-ji.wikipedia.org. I'm expecting
objections to this from the users of that wiki, who seem to be keen
promoters of the Peh-oe-ji orthography. All the same, I'd like to hear
any comments or objections anyone has.

-- Tim Starling


body:
millosh wrote:

> So, I think that we can do something like this: We can make secondary Serbian Wikipedia using secondary two-letters code for Serbian language: sp.

Or, alternatively, you can create two pages for each article on the
Serbian Wikipedia, one in Latin and one in Cyrillic, similar to the way
the Chinese Wikipedia handles traditional and simplified characters.

Timwi


from_name: millosh

body:
Hello,

I am Milos and I am bureaucrat on sr:

First of all, I have to tell you some introduction in our alphabet problems.

Until the second half of 19th century Serbs used only Cyrillic alphabet. (In the ancient history, Serbs was using Latin and Glagolic alphabet for a short time, but without stronger cultural consequences.) Between the second half of 19th century and the end of The Second World War, Latin alphabet was not used a lot; it was used by very small number of writers. After the end of WWII, strong cultural influence of Communist Party of Yugoslavia gave to Serbs active usage of Latin alphabet. During 1980's and 1990's Latin alphabet was used more often then Cyrillic (maybe 60%, maybe even 70%). Today, the situation is something about 50-50 with tendency of Cyrillic usage growth. In this moment we have very strong xenophobic movement. A lot of them are very active on Internet and on Wikipedia, too. They do not accept Latin alphabet as "Serbian". Even a lot of people use Latin alphabet.

I made voting for the question: Would Serbian Wikipedia has Latin pages too? Even the end of August is the end of voting for that question, I think that usage of Latin alphabet would not pass. Situation is 4:2 against and Serbian Wikipedia doesn't have a lot of active users (we have one or two new users which can't vote).

Even I use Cyrillic alphabet, I relies that usage of Latin alphabet is important for us: We have significant minority (about 50%!) of Latin users and if anyone starts to search on Internet, (s)he uses Latin alphabet, not Cyrillic (usually even without Serbian Latin letters). We have very ironic situation: If you type the name of one of Serbian 19th century writers, Radoje Domanovic (in Serbian Cyrillic: ?????? ?????????, in Serbian Latin: Radoje Domanovi?) in Google, you will get: (1) Cyrillic: Serbian Wikipedia is on the first place; (2) Any Latin: Wikipedia doesn't exists.

So, I think that we can do something like this: We can make secondary Serbian Wikipedia using secondary two-letters code for Serbian language: sp. It would not be "real" Wikipedia, because it should be used only for transliteration of Cyrillic Wikipedia (transliteration from Serbian Cyrillic to Serbian Latin is algorithmic, the reverse process is fuzzy). All of the pages on sp: should be "protected" and when someone writes something on Cyrillic Wikipedia, it should be transliterated to Latin, too. Also, all of users should be the same.

I think it is good solution because we would not have multiplication of work (such as we have now: Croatian, Bosnian and Serbo-Croatian Wikipedias are using the (very, very) almost the same language). All of people would work on sr:, not on sp:.

Also, I have some notes to developers (if the request passes): about technical solution for that. It would not any consequence to Wikimedia's performances because it is (almost) row transliteration.

Best,
Milos

P.S. For admins of the list: Delete my pending message from millosh at users.sourceforge.net because this message is the same.


from_name: wulfhtmlteam at web.de

subject: [Wikitech-l] Installing EasyTimeline

body:
I am interested in installing the EasyTimeline extension. Unfortunately documentation of this is rather sparse. I even wrote the author, Erik, of the EasyTimeline script, but he did not know how to do this for mediawiki. After some fruitless attempts to get an answer via IRC, I will now try it this way.

Where can I read more about installing the EasyTimeline extension for mediawiki?
Who can help me setting it all up?

Hope you can help me,

wulf
____________________________________________________
Aufnehmen, abschicken, nah sein - So einfach ist
WEB.DE Video-Mail: http://freemail.web.de/?mc=021200


from_name: Marcus Lunzenauer

subject: [Wikitech-l] (kein Betreff)

body:
https://kontakte.web.de/adr_vervoll/?pickup=28571476&cid=149648520&owner=d3VsZmh0bWx0ZWFtQHdlYi5kZQ%3D%3D

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040808/4c4c077a/attachment.html>


from_name: Yann Forget

subject: [Wikipedia-l] Free photos from Israel and the West Bank

body:
Hi,

Here are a few photos from Israel and the West Bank available under free
licences (GFDL and CC-BY-SA).

http://fr.wikipedia.org/wiki/Discuter:Conflit_isra?lo-arabe

Use at will.

Yann
--
http://www.non-violence.org/ | Site collaboratif sur la non-violence
http://www.forget-me.net/ | Alternatives sur le Net
http://fr.wikipedia.org/ | Encyclop?die libre
http://www.forget-me.net/pro/ | Formations et services Linux


subject: [Wikitech-l] Template bugs

body:
After ritually sacrificing several furred and feathered animals ;-) I am
*pretty* sure I got the template bugs fixed that, apparently, were
introduced all at once after 1.2.6. and should now be resolved in CVS HEAD.

I may guide your attention to Parser.php, lines 858/859, and 1914,
respectively.

If anyone can confirm that this is indeed the solution to the various
problems, without any serious side effects, we can close the bugs
* 1002735
* 994833
* 977849
* 962674
* 962335
* 962917
* 926647

and probably some more. Worth checking out.

Magnus


from_name: Thomas R. Koll

body:
On Sun, Aug 08, 2004 at 06:52:05PM +0100, Timwi wrote:
> millosh wrote:
>
> >So, I think that we can do something like this: We can make secondary
> >Serbian Wikipedia using secondary two-letters code for Serbian language:
> >sp.
>
> Or, alternatively, you can create two pages for each article on the
> Serbian Wikipedia, one in Latin and one in Cyrillic, similar to the way
> the Chinese Wikipedia handles traditional and simplified characters.

I think that would be even easier than on zh-* because they don't share many
letters if any.

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


from_name: Alfio Puglisi

subject: [Wikitech-l] Template bugs

body:
Is CVS HEAD live on wikipedia.org ? If so, bug 962674 is still around
(didn't check the others)

Alfio

On Sun, 8 Aug 2004, Magnus Manske wrote:

>After ritually sacrificing several furred and feathered animals ;-) I am
>*pretty* sure I got the template bugs fixed that, apparently, were
>introduced all at once after 1.2.6. and should now be resolved in CVS HEAD.
>
>I may guide your attention to Parser.php, lines 858/859, and 1914,
>respectively.
>
>If anyone can confirm that this is indeed the solution to the various
>problems, without any serious side effects, we can close the bugs
>* 1002735
>* 994833
>* 977849
>* 962674
>* 962335
>* 962917
>* 926647
>
>and probably some more. Worth checking out.
>
>Magnus
>_______________________________________________
>Wikitech-l mailing list
>Wikitech-l at wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


subject: [Wikitech-l] Template bugs

body:
Alfio Puglisi wrote:

>Is CVS HEAD live on wikipedia.org ? If so, bug 962674 is still around
>(didn't check the others)
>
>
No, the latest (with the -hope-to-be fix) is not even on
test.wikipedia.org. You'd have to checkout/install yourself.

Magnus


from_name: daniwo59 at aol.com

subject: [WikiEN-l] anons and new articles

body:
In a message dated 8/8/2004 8:04:06 PM Eastern Standard Time,
maveric149 at yahoo.com writes:
But this should be a wiki-by-wiki feature. Smaller wikis *need* to encourage
the creation of many small articles in order to seed topics. With well over
300,000 articles, the English Wikipedia no longer needs to do concentrate on
that so much. We already have too many seeds for the amount of fertilizer and
water on hand.
While I might have phrased it differently, I agree. We really have to put a
concentrated into improving the quality of existing articles, lest they get
lost. There is too much to do to concentrate on cleaning up recent changes. Mav's
suggestion is a reasonable step toward handling this effectively. Let's start
switching our focus to quality, not quantity.

Danny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20040808/81130797/attachment.htm


from_name: Ray Saintonge

body:
Daniel Mayer wrote:

>However, you do correctly note that we should not depend on the fair use
>doctrine in the U.S. We should instead work with more international doctrines
>such as fair dealing (which covers much of the English Speaking world and is a
>bit more restrictive than fair use and thus will be fine in the U.S. as well).
>But this would be much less useful for non-English wikis (each language wiki
>should develop its own policy on this).
>
>
There is also something like fair dealing in the Berne Convention.  The
exact term escapes me for now.  The general rule is that this would be
brought into a country's law when it ratifies the Treaty.

Ec


from_name: Stan Shebs

subject: [WikiEN-l] Re: Sub-stub city

body:
Daniel Mayer wrote:

>--- Timwi <timwi at gmx.net> wrote:
>
>>...
>>Wikipedia brags about its self-healing abilities. People patrolling RC
>>and NP are valuable because they make this self-healing work. The
>>"correct" way to "fix" this situation is what Daniel Mayer mentioned:
>>Allowing logged-in users (or only admins) to "flag" an edit to show
>>others that it's been looked at. This eliminates duplicate work, but it
>>does not restrict the ability of anyone to post new articles or make any
>>other edit.
>>
>
>If we did have such a team-based approach to patrol, then we may be able to
>delay having to start locking things up for some time - perhaps indefinitely.
>
>So yes, that would be the best of all proposed options.
>
How about just displaying a count of how many logged-in users (or
admins) have looked at an article? If I've looked at an article and
done nothing about it, then it's probably an acceptable start. New
articles with low view counts will likely benefit from more early
attention than ones who've already been viewed a lot.

Stan


from_name: Ricky Beam

subject: [Wikitech-l] Wikipedia exceeds DVD size

body:
On Sat, 7 Aug 2004, Alfio Puglisi wrote:
>>heard of compression?
>
>Compressing 2.5 GB of images you won't gain anything. And compressing the
>html files will make them less easy to browse. Likely an installer would
>be needed.

Most modern browsers can eat gzip just fine. ('tho not directly off disk.)

--Ricky


from_name: John Lee

subject: [WikiEN-l] anons and new articles

body:
Like Fred, I think this goes against the spirit of a Wiki. Wikis thrive
on the contributions of anonymous people. We wouldn't be anywhere near
as successful as we are today if we didn't give anons the freedom they
have now.

John Lee (User:Johnleemk)

Martin Harper wrote:

>
>Rather than *forbidding* or *allowing* things, why not use a more
>gentle method of discouragement? Simply don't display red links to
>anonymous editors. They can still create articles if they really want
>to by going directly to the appropriate URL, and experienced
>anonymous contributors would no doubt do just that.
>
>I think this would also improve the reading experience for those who
>have no intention of editing.
>
>-Martin
>_______________________________________________
>WikiEN-l mailing list
>WikiEN-l at Wikipedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikien-l
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20040808/9e581458/attachment.htm


subject: [WikiEN-l] Display reason for article deletion to anons?

body:
I always wondered why that doesn't happen. I think this would be a good
idea if implemented properly.

John Lee (User:Johnleemk)

Timwi wrote:

> Although you're right that we don't want to "forbid" or "disallow"
> legitimate editing, I don't think we want to discourage it either.
> Your suggestion makes it harder for well-meaning newbies to find out
> how to edit or create articles.
>
> A better way would be to encourage more healing. We already have the
> "stub" message which encourages newbies to expand a stub they encounter.
>
> One idea I was toying with in my mind recently is this. When sysops
> delete an article, the article goes back to saying "Wikipedia does not
> have an article with this title yet." Maybe we should actually let
> everyone (including anonymous users) know that there used to be an
> article, and (this is the important part) show the reason for its
> deletion.
>
> If a newbie goes back to see what happened to their article, and they
> see it gone, they are more likely to just put it back in (it looks to
> them more like a glitch in the system or an accident than a deliberate
> deleting). If it actually said "This article was deleted for the
> following reason: vandalism", they are more likely to ackowledge that
> putting their article back in is going to have the same effect again.
>
> Timwi
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
> .
>


from_name: zero 0000

subject: [WikiEN-l] anons editing

body:
In my almost-a-year editing Wikipedia, I am yet to hear a convincing
reason for allowing anons to edit at all, but saw plenty of cases when
I wished they couldn't.  Zero.

__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail


body:
Sounds like a good compromise to me, although that won't cover pages
that went through VfD very well.

John Lee (User:Johnleemk)

Angela_ wrote:

>That wouldn't work with the way things are currently deleted as sysops
>usually don't type a reason when deleting speedy deletion candidates.
>They leave the full text of the article as the deletion reason, which
>helps others to check what has been deleted as any user can read this
>text in the deletion log.
>
>As an alternative, I've added the following to [[MediaWiki:Noarticletext]]:
> * If you created an article under this title previously, it may have
>been deleted. See [[Wikipedia:Candidates for speedy deletion#The
>cases|candidates for speedy deletion]] for possible reasons.
>
>Perhaps this will help explain to newcomers where their article went.
>
>Angela.
>_______________________________________________
>WikiEN-l mailing list
>WikiEN-l at Wikipedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikien-l
>.
>
>
>


from_name: Timwi

body:
millosh wrote:

>>On Sun, Aug 08, 2004 at 06:52:05PM +0100, Timwi wrote:
>>
>>>Or, alternatively, you can create two pages for each article on the
>>>Serbian Wikipedia, one in Latin and one in Cyrillic, similar to the way
>>>the Chinese Wikipedia handles traditional and simplified characters.
>>
>>I think that would be even easier than on zh-* because they don't share
>>many letters if any.
>
> Huh. Maybe my English is not so good... I said (or I wanted to say)
> that we (almost) have decision _not_ to work on Latin pages on sr:
> (i.e.: decision is that sr.wikipedia.org should not have Latin pages).
> I am trying to find alternate solution. Two-letters code "sp" is
> reserved for Serbian language so there is no code collision
> (sp.wikipedia.org doesn't exist, too).

We perfectly understood what you meant. You want an automatic conversion
from Cyrillic to Latin. That's fine. But what I'm saying is that you
don't need a separate sub-domain for this. You can set up a bot that
does it on sr.wikipedia.org, so that you will have both Latin and
Cyrillic pages on the same wiki.

Timwi


subject: [Wikipedia-l] Re: Press inquiry: South China Morning Post (scmp.com)

body:
David Wilson wrote:

> Could you say what it
> offers that Encarta and Britannica don't please?

The ability to correct all the annoying errors? :)


subject: [Wikipedia-l] Re: How to make a new Wiki? Pleas help me...

body:
Gertjan wrote:

> How do I make a Kiribati language Wikipedia?
>
> I am allready active on the Dutch, French, English and Nauruan Wikis.

The ISO language code for Kiribati is gil.


from_name: Jens Frank

subject: [Wikitech-l] Template bugs

body:
On Sun, Aug 08, 2004 at 08:14:40PM +0200, Magnus Manske wrote:
> After ritually sacrificing several furred and feathered animals ;-) I am
> *pretty* sure I got the template bugs fixed that, apparently, were
> introduced all at once after 1.2.6. and should now be resolved in CVS HEAD.
>
> I may guide your attention to Parser.php, lines 858/859, and 1914,
> respectively.
>
> If anyone can confirm that this is indeed the solution to the various
> problems, without any serious side effects, we can close the bugs
> * 1002735

See test case at http://mediawiki.mormo.org/index.php/1002735
Bug still persists, even worse, now the Category page only lists the template,
not the page using the template.

> * 994833
See test case at http://mediawiki.mormo.org/index.php/994833
Looks fine.

> * 977849
See test case at http://mediawiki.mormo.org/index.php?title=977849
Looks fine.

> * 962674
See test case at http://mediawiki.mormo.org/index.php?title=962674
Still broken, links to /6/61/Wappen-frankfurt.jpg instead of
/5/54/Wappen-frankfurt.jpg. Apparently hash is computed before
replacing variable.

> * 962335
No test case. Don't understand the bug.

> * 962917
See test case at http://mediawiki.mormo.org/index.php?title=962917
Problem still exists.

> * 926647
Not tested.

An improvement, yes. But not the final solution to all our problems :-(

Regards,

	JeLuF


subject: [Wikitech-l] Installing EasyTimeline

body:
On Sun, Aug 08, 2004 at 08:02:33PM +0200, wulfhtmlteam at web.de wrote:
> I am interested in installing the EasyTimeline extension. Unfortunately documentation of this is rather sparse. I even wrote the author, Erik, of the EasyTimeline script, but he did not know how to do this for mediawiki. After some fruitless attempts to get an answer via IRC, I will now try it this way.
>
> Where can I read more about installing the EasyTimeline extension for mediawiki?
> Who can help me setting it all up?
>
What did you try? Which error messages or results did you get?

Basically, extensions are enabled by including the extension/dir/extensioncode.php
script into LocalSettings.php, e.g. using
include("extensions/timeline/Timeline.php");

Regards,

JeLuF


subject: [WikiEN-l] anons editing

body:
zero 0000 wrote:

>In my almost-a-year editing Wikipedia, I am yet to hear a convincing
>reason for allowing anons to edit at all, but saw plenty of cases when
>I wished they couldn't.  Zero.
>
You must be looking at the wrong articles then. There's been a bunch
of new material for which I've been grateful to anons for doing the
scutwork of creating and filling in, and lots of grammar/spelling
corrections from them too. Some of these are from IPs that become
familiar, so I assume they have reasons for anonymity.

I'm not averse to making anons be third-class though, logins with
no real-world identification second-class, and real-world people as
the first class. Anonymity cannot build the web of trust that we'll
need for long-term stability and reliability, so we want to tolerate
it but not encourage. (For instance, a quality rating system might
elevate an article to where anons could no longer modify it.)

Stan


body:
>On Sun, Aug 08, 2004 at 06:52:05PM +0100, Timwi wrote:
>> millosh wrote:
>>
>> >So, I think that we can do something like this: We can make secondary
>> >Serbian Wikipedia using secondary two-letters code for Serbian language:
>> >sp.
>>
>> Or, alternatively, you can create two pages for each article on the
>> Serbian Wikipedia, one in Latin and one in Cyrillic, similar to the way
>> the Chinese Wikipedia handles traditional and simplified characters.
>
> I think that would be even easier than on zh-* because they don't share
> many letters if any.

Huh. Maybe my English is not so good... I said (or I wanted to say) that we (almost) have decision _not_ to work on Latin pages on sr: (i.e.: decision is that sr.wikipedia.org should not have Latin pages).  I am trying to find alternate solution. Two-letters code "sp" is reserved for Serbian language so there is no code collision (sp.wikipedia.org doesn't exist, too).


subject: [Wikitech-l] Re: (no subject)

body:
Eric Pierce wrote:

> Alfio Puglisi <puglisi at arcetri.astro.it> wrote:
>
>>Compressing 2.5 GB of images you won't gain
>>anything. And compressing the html files will
>>make them less easy to browse. Likely an
>>installer would be needed.
>
> Mozilla does on-the-fly decompression of tar.gz files,

No, it doesn't. Especially not if you navigate to a tar.gz file on the
local file system.

It de-compresses files that are sent as Content-type: text/html with
Content-Encoding: gzip. But IE, Netscape and Opera do that too.

Sometimes Mozilla will decompress a file designated as Content-type:
x/gzip-compressed (or whatever it is called), if it believes that it is
an error and should really be text/whatever with Content-Encoding: gzip.

Timwi


body:
millosh wrote:

> You say that I work against the decision of community...

No, I didn't.

> The problem is decision
> of community, and this is not to work in Latin alphabet on sr:.

You keep using the word "work". This suggests to me people don't want to
have to *write* articles in Latin script. Perhaps you could clarify
this. By any chance, do you mean that the community of Wikipedians on
the Serbian Wikipedia don't want Latin-script articles on sr at all?


from_name: Ashar Voultoiz

subject: [Wikitech-l] Re: skinning mediawiki

body:
Edward Peschko wrote:
> hey all,
>
> Is there a FAQ or recipe book for skinning mediawiki? I like its general
> layout, but would like to frame it and change its colorschemes, fonts and
> tabbing scheme.
>
> Thanks much for any pointers,
>
> Ed

Hello,

A little start is at : http://meta.wikimedia.org/wiki/Skins

Wich is part of the mediawiki user guide (
http://meta.wikimedia.org/wiki/MediaWiki_User%27s_Guide ).

You can change the monobook skin by editing the file
./templates/xhtml_slim.pt and/or hacking in skinphptal.php

--
Ashar Voultoiz


body:
You say that I work against the decision of community... Scripts are not the problem, I understand functions of bots. The problem is decision of community, and this is not to work in Latin alphabet on sr:.

-----Original Message-----
From: wikipedia-l-bounces at Wikimedia.org [mailto:wikipedia-l-bounces at Wikimedia.org] On Behalf Of Timwi
Sent: Sunday, August 08, 2004 10:46 PM
To: wikipedia-l at wikipedia.org
Subject: [Wikipedia-l] Re: Request for the second Serbian Wikipedia

millosh wrote:

>>On Sun, Aug 08, 2004 at 06:52:05PM +0100, Timwi wrote:
>>
>>>Or, alternatively, you can create two pages for each article on the
>>>Serbian Wikipedia, one in Latin and one in Cyrillic, similar to the way
>>>the Chinese Wikipedia handles traditional and simplified characters.
>>
>>I think that would be even easier than on zh-* because they don't share
>>many letters if any.
>
> Huh. Maybe my English is not so good... I said (or I wanted to say)
> that we (almost) have decision _not_ to work on Latin pages on sr:
> (i.e.: decision is that sr.wikipedia.org should not have Latin pages).
> I am trying to find alternate solution. Two-letters code "sp" is
> reserved for Serbian language so there is no code collision
> (sp.wikipedia.org doesn't exist, too).

We perfectly understood what you meant. You want an automatic conversion
from Cyrillic to Latin. That's fine. But what I'm saying is that you
don't need a separate sub-domain for this. You can set up a bot that
does it on sr.wikipedia.org, so that you will have both Latin and
Cyrillic pages on the same wiki.

Timwi

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


from_name: Daniel Mayer

subject: [WikiEN-l] Recent Changes Patrol

body:
--- Timwi <timwi at gmx.net> wrote:
>      New feature: Recent Changes Patrol. All edits and new pages are
>      now highlighted on Special:Recentchanges and Special:Newpages
>      until someone "marks" them as "patrolled" using a special link.
>      For new pages, this link appears at the bottom of the article if
>      the link in Recent Changes or New Pages is followed. For all
>      other edits, this link appears only in the diff and only if the
>      diff link is followed from Recent Changes. (Might need to add
>      this functionality to Watchlist too; haven't done that yet.)

Neat! But who gets to mark an edit as "patrolled"? Letting an anon or new user
do that would tend to defeat the purpose. Also, depending on a single person's
judgment may be problematic as well. Ideally an article would need to be viewed
by 3 non-newbies/anons to get the "patrolled" tag.

But this at least is a good start. I thank you for coding this feature. :)

-- mav

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


from_name: evan at wikitravel.org

subject: [Wikitech-l] New feature: Recent Changes Patrol

body:
On Mon, Aug 09, 2004 at 06:49:43AM +0100, Timwi wrote:

> I've committed a new feature I just wrote.

Suggestion: in the future, mention the feature on this list _before_
committing it. You'll get some good feedback, and maybe some good ideas.

> New feature: Recent Changes Patrol. All edits and new pages are
> now highlighted on Special:Recentchanges and Special:Newpages
> until someone "marks" them as "patrolled" using a special link.

Did you make this feature optional? If not, could you, please?

~ESP


from_name: Elisabeth Bauer

body:
Hiho,

Gertjan wrote:

> How do I make a Kiribati language Wikipedia?
>
> I am allready active on the Dutch, French, English and Nauruan Wikis.

Put your request with the necessary data on
http://meta.wikimedia.org/wiki/Proposals_for_new_projects

greetings,
elian


from_name: Stephen Adair

subject: [WikiEN-l] Re: Sub-stub city

body:
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20040809/c708b926/attachment.diff
-------------- next part --------------
An embedded message was scrubbed...
From: Jens Ropers <ropers at ropersonline.com>
Subject: Re: [WikiEN-l] Re: Sub-stub city
Date: Mon, 9 Aug 2004 04:10:30 +0200
Size: 10851
Url: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20040809/c708b926/attachment.eml


from_name: Pochung(Pektiong) Chen(Tan)

subject:
[Wikipedia-l] Re: Peh-oe-ji on minnan.wikipedia.org
	(clarification)

body:
On Mon, 9 Aug 2004, Tim Starling wrote:

> Of the speakers of Ho-lo-oe, most write using what we would call
> Traditional Chinese, a script which historically was promoted throughout
> East Asia by Chinese conquest and influence. A small minority of
> Ho-lo-oe speakers promote the use of latin-based orthographies, which
> follow phonetically from the spoken language. Such orthographies are
> referred to as "Peh-oe-ji", which means vernacular. The point I was
> trying to make with the quoted paragraph was that Ho-lo-oe speakers
> contribute to both zh.wikipedia.org and minnan.wikipedia.org.
>
> -- Tim Starling

Sorry, but what is the point?
Ho-lo-oe speakers may contribute to zh.wikipedia.org because she/he is
multilingual and understand written Mandarin and choose to contribute to
zh.wikipedia.org. She/he can also contribute to other wikipedias if she/he
can write in those languages.

-- Pektiong


body:
On Sun, 8 Aug 2004, Tim Starling wrote:
> Based on the information I have now, I would like to move
> minnan.wikipedia.org to peh-oe-ji.wikipedia.org. I'm expecting
> objections to this from the users of that wiki, who seem to be keen
> promoters of the Peh-oe-ji orthography. All the same, I'd like to hear
> any comments or objections anyone has.
>
> -- Tim Starling

Peh-oe-ji is a script/orthography, not a language. The peh-oe-ji
orthography, with some minor modifications, can and is used to write
orther languages such as Hakka and other aboriginal languages in Taiwan.

Historically, wikipedia has been using 'language', not 'orthography' to
classify the wikipedia. When a language is wrtten in only one orthography
there is no problem. When a language can be written in more than one
orthographies, there is a problem. In my opinion, wikipedia doesn't not
provide a method to solve this problem.

-- Pektiong


from_name: Tim Starling

subject: [Wikipedia-l] Re: Peh-oe-ji on minnan.wikipedia.org (clarification)

body:
I wrote:
> The Taiwanese people who write in zh.wikipedia.org
> speak the exact same language as those who write on
> minnan.wikipedia.org. That language is a form of Min Nan, referred to in
> Taiwan as Ho-lo-oe.

Kaishu let me know on the wiki that this statement was misleading, so
here is a clarification. There are several linguistic groups on Taiwan,
including:

* Speakers of Ho-lo-oe
* Speakers of Mandarin
* Speakers of aboriginal languages and other dialects of Chinese

Of the speakers of Ho-lo-oe, most write using what we would call
Traditional Chinese, a script which historically was promoted throughout
East Asia by Chinese conquest and influence. A small minority of
Ho-lo-oe speakers promote the use of latin-based orthographies, which
follow phonetically from the spoken language. Such orthographies are
referred to as "Peh-oe-ji", which means vernacular. The point I was
trying to make with the quoted paragraph was that Ho-lo-oe speakers
contribute to both zh.wikipedia.org and minnan.wikipedia.org.

-- Tim Starling


subject: [WikiEN-l] Re: anons and new articles

body:
Daniel Mayer wrote:

> Looking at the issue, it would seem that making it
> a bit more difficult for anons to create new pages (or at least sub-200 byte
> pages) would solve a large part of the problem.

But this "if people can potentially do something wrong, make it
impossible" is exactly the sort of thinking that leads to the
"conclusion" that wiki will never work, or that proprietary is clearly
better than open-source.

> Anons will still be able to
> edit and at this point *improving* the articles we already have should be
> encouraged over creating more tiny articles.

No, not at all: Do you really think someone will go "Oh my, I can't
create this new article. Why, in that case, I'll go and improve an
existing article!" Certainly not. It would discourage the creation of
very short pages (including legitimate ones), but it would neither
encourage the improvement of articles, nor (this is important) will it
discourage the creation of pages containing rubbish.

> With well over
> 300,000 articles, the English Wikipedia no longer needs to do concentrate on
> that so much. We already have too many seeds for the amount of fertilizer and
> water on hand.

I don't think we have "too many", and I don't think we could ever have
"too many". It's not like having a million stubs and 100,000 full
articles would be worse than only half a million stubs and 100,000 full
articles. In other words: It's not like more stubs meant less full
articles. The English Wikipedia doesn't need to focus on creating stubs,
but why lessen it?

Timwi


references:
<cf4paf$2j3$1@sea.gmane.org> <cf5gna$7cd$1@sea.gmane.org>
	<20040809001909.A64440@formosa.org>

body:
Pochung(Pektiong) Chen(Tan) wrote:
> Sorry, but what is the point?
> Ho-lo-oe speakers may contribute to zh.wikipedia.org because she/he is
> multilingual and understand written Mandarin and choose to contribute to
> zh.wikipedia.org. She/he can also contribute to other wikipedias if she/he
> can write in those languages.

The point is that Peh-oe-ji is not representative of Min Nan. There are
millions of Min Nan speakers who do not use a romanised script,
hopefully I am speaking for their interests.

-- Tim Starling


from_name: Brion Vibber

subject: [Wikipedia-l] Nauruan and this ugly message under each en:article

body:
Gerard.Meijssen wrote:
> On en: there is this _ugly_ message like "Retrieved from
> "http://en.wikipedia.org/wiki/Nauri_language""

Force a reload to update your stylesheet.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20040809/9951b602/attachment.pgp


subject: [Wikitech-l] Bughunt day 7

body:
We currently stand at 132 open bugs out of 1112 total reported bugs,
down 7 from yesterday. We're a smidge behind schedule.

The bughunt goal is to reach 107 open bugs (half of the 214 we had at
the start) which is another 25 bugs down -- let's see if we can reach
that in the next day or so and get 1.3.0 final out the door!

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040809/d0adfba8/attachment.pgp>


body:
Austin Hair wrote:
> Rather than selectively hiding elements from print media, why not

Patch please.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20040809/d52d74b7/attachment.pgp


from_name: Austin Hair

body:
> >On en: there is this _ugly_ message like "Retrieved from
> >"http://en.wikipedia.org/wiki/Nauri_language""
>
> Force a reload to update your stylesheet.

Like many others, my browser is altogether ignorant of stylsheets, and
thus the Wikipedia markup fancies that I must be viewing the page on
paper.  Why is this?  In particular:

Retrieved from "
http://en.wikipedia.org/wiki/Gospel_of_Mark"

Rather than selectively hiding elements from print media, why not
generate these using content: selectors?  The message above is perfectly
suited to this, as while browsers will not interpolate markup generated
as a result of said selectors, the markup used in this example is
pointless anyway -- unless, of course, you've come up with a method of
following hyperlinks on a printed page.

> -- brion vibber (brion @ pobox.com)

--
Austin D. Hair <austin at austinhair.org>
http://en.wikipedia.org/wiki/User:Callidus
http://www.austinhair.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20040809/3eebca44/attachment.pgp


subject:
[Wikipedia-l] Re: Nauruan and this ugly message under each
	en:article

body:
> >Rather than selectively hiding elements from print media,
>
> That's the correct way of doing it.

According to whom?  I've yet to see this as a W3C recommendation; in
fact, this is the reason content selectors were created in the first
place.

> >why not
> >generate these using content: selectors?
>
> Because then they won't show up when people print the page with a less
> conforming browser.

Consider the number of people printing Wikipedia articles from "less
comforming browsers" vs. the number of people actually viewing Wikipedia
articles online.  Is this the correct assumption to make?  Why do we
have to endure such frivolities as painting the current URL boldly
across the page, especially when this is almost always in the print
header to begin with?

> Timwi

--
Austin D. Hair <austin at austinhair.org>
http://en.wikipedia.org/wiki/User:Callidus
http://www.austinhair.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20040809/60174ef8/attachment.pgp


from_name: Jens Ropers

subject: [WikiEN-l] Re: Sub-stub city

body:
see below :-)

On 9 Aug 2004, at 03:23, Daniel Mayer <maveric149 at yahoo.com> wrote:

> Message: 6
> Date: Sun, 8 Aug 2004 18:10:09 -0700 (PDT)
> From: Daniel Mayer <maveric149 at yahoo.com>
> Subject: Re: [WikiEN-l] Re: Sub-stub city
> To: English Wikipedia <wikien-l at Wikipedia.org>
> Message-ID: <20040809011009.77996.qmail at web51606.mail.yahoo.com>
> Content-Type: text/plain; charset=us-ascii
>
> --- Timwi <timwi at gmx.net> wrote:
>> ...
>> Wikipedia brags about its self-healing abilities. People patrolling RC
>> and NP are valuable because they make this self-healing work. The
>> "correct" way to "fix" this situation is what Daniel Mayer mentioned:
>> Allowing logged-in users (or only admins) to "flag" an edit to show
>> others that it's been looked at. This eliminates duplicate work, but
>> it
>> does not restrict the ability of anyone to post new articles or make
>> any
>> other edit.
>
> If we did have such a team-based approach to patrol, then we may be
> able to
> delay having to start locking things up for some time - perhaps
> indefinitely.
>
> So yes, that would be the best of all proposed options.
>
> -- Daniel Mayer (aka mav)

Couple of points:
1. <AOL>Me too!!!</AOL> -- translation: I agree that an "I'm already
looking at it" flag would reduce a lot of work and frustration AND make
it very visible that Ed Stubhunter isn't the only poor soul out there
struggling against the deluge. This is the best solution to the said
problems, NOT a 200b limit.
2. Remember Sturgeon's Law: Ninety percent of everything is crap. --
Why am I saying that? Well, 90% of WP articles that are written new are
curd. JUST LIKE 90% of everything else is. 90% fluff stubs may LOOK
alarming (especially if you're only looking at new articles), but the
secret of our success lies in our cycle of incremental improvement,
which is what allows us to exceed the 90% rate by far. But looking at
the things that stand at the very beginning of that cycle, it just
shouldn't alarm or surprise _anybody_ that there's a lotta Mullarkey
out there. (Hey, and I /know/ Sturgeon's Law is not a natural law. I'm
making a point here.)
3. Have a break. -- Again, if you're sifting through new articles and
stubs all day, it WILL get very frustrating very quickly. See point
(2). So don't. Don't feel you had to fight the good fight
uninterruptedly. You don't. If you're an eager stubhunter, enjoy some
mature articles in-between. It will help you and re-adjust your
perception.
4. I acknowledge the 200b limit is not a totally insane idea. I can see
the sense and rationale in it. I just don't think is the way to go.
5. It still takes people time to discover the Wikipedia and figure it
out. It took me months and years after first seeing it, before I
finally stopped browsing past it ("Just another webbased
definition/article DB. Next.") and finally actually looked at it enough
to realize "Hey, I can REALLY EDIT THIS and do great stuff here." On a
similar vein, it took me an hour or so to explain the workings (and
incredible proposition) of the Wikipedia to an alert and studied
intellectual. Why am I saying this? - Well, we need to have _as few as
possible_ bars to entry. See next point.
6. Not only is the ad-nauseam repeated point about stubs growing into
brilliant articles nevertheless true, but - MUCH more importantly:
Fluff _contributors_ grow into valuable and respected Wikipedians. Lets
not raise the bar for entry. For the sake of future Wikipedians, who
will soon go beyond writing fluff. Their future contributions are worth
their erstwhile fluff articles many times over. (And if existing, loyal
Wikipedians really do keep writing silly stubs -- that's what Talk
pages are for.)

Thanks and regards,
Jens Ropers

There are two types of IT techs: The ones who watch soap operas and the
ones who watch progress bars.
http://www.ropersonline.com/elmo/#108681741955837683

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3979 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20040809/cf0c6072/attachment.bin


from_name: Poor, Edmund W

subject: [WikiEN-l] Nationalist POV-pushing on Wikpedia: what to do?

body:
David Gerard wrote:

> Nationalist POV pushing is becoming a real problem on
> Wikipedia. Particularly in cases where it appears
> semi-official, as with these cases and with User:Levzur on
> Georgia-related articles. I suspect a series of AC rulings as
> we go isn't really the best way to approach the problem. What
> can we do abouthis sort of thing? Gdansk/Danzig is just the tip of it.

The only thing we can do about it is what we've always done about it,
and it's the best solution anyway:

DESCRIBE EACH SIDE'S POV

Say that according to _this_ group of nationalists, the situation is
like this. Then say that according to _that_ group of nationalists, the
situation is like that.

Here's an example, from a different controversy. Gay rights groups
generally maintain that the homosexual population of the US and/or UK is
at ten percent (10%). Conservatives say it's much lower: one or two
percent (1% to 2%) for males, two or three percent (2% to 3%) for
females.

So what should the Wikipedia article say? Should it endorse the side
which is obviously right? No, because it's a disputed matter. Each side
touts its own 'objective' scientific studies and asserts that they are
being totally sincere about "just wanting to tell the truth" about the
situation.

Enter the NPOV policy:

*According to the HRC, the US male homosexual percentage is 10% (or
whatever their website or books say)
*According to NARTH, the percentage is 1% to 2%.

We can also say:

*The general public is more sympathetic to HRC's views, and the higher
figure is generally used by mainstream journalists.
*Moreover, [[gay rights]] activists dismiss NARTH's research as
hopelessly biased due to the groups perceived "anti-gay" prejudice.

I didn't check just now, but I think that's pretty much how the
Wikipedia describes the topic now.

I think we should handle all Nationalist POV the same way: describe each
POV, and possibly indicate how widely held it is.

Ed Poor


from_name: Daniel P.B.Smith

subject: [WikiEN-l] Re: Recent changes patrol

body:
> From: Daniel Mayer <maveric149 at yahoo.com>
>

> Neat! But who gets to mark an edit as "patrolled"? Letting an anon or
> new user
> do that would tend to defeat the purpose. Also, depending on a single
> person's
> judgment may be problematic as well. Ideally an article would need to
> be viewed
> by 3 non-newbies/anons to get the "patrolled" tag.

I don't think so. It's not as if marked articles would never be looked
at. The function of the feature, as I see it, is not to be technical
armor against bad behavior and bad faith, but to reduce Wikistress by
insuring that many eyes _do not_ look at new articles if many eyes are
not needed.

I think it's a very good idea. And it doesn't need to work perfectly in
order for it to work.

I don't think it will help dramatically, but I think it will help
noticeably.

--
Daniel P. B. Smith, dpbsmith at verizon.net
"Elinor Goulding Smith's Great Big Messy Book" is now back in print!
Sample chapter at http://world.std.com/~dpbsmith/messy.html
Buy it at http://www.amazon.com/exec/obidos/ASIN/1403314063/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1143 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20040809/a066d604/attachment.bin


subject: [WikiEN-l] Markiing a version with a status flag

body:
One idea that came out of the Boston meeting was very similar to what
Maveric asked for: a way of reducing duplicate effort on RC patrol.

The idea is very simple conceptually, and ought to be fairly easy for
our noble, selfless team of hard-working developers to implement.

Every user can "flag" a particular version of an article with a status
code, such as:

* RC Cleared: I have glanced at the diff and certify that this latest
edit was NOT "simple vandalism" (i.e, graffiti like "Jerry has big ones"
or "Toby loves Christine").

* Unfair revert: Looks like someone is ignoring everyone else's
contributions and trying to make the article endorse their own POV.

If Mav or someone else I've come to trust has flagged a particular
version of an article as "RC Cleared" (or whatever we end up calling
it), then:

1. I don't have to bother re-doing his work: I can go on and check the
next edit in the Recent Changes queue.

2. I might not even want to see that version in my custom RC list. That
is, I'd like an option that says to show me all Recent Changes that
HAVEN'T GOT an "RC Cleared" flag attached to them

We might even fine-tune option #2, if it's not too hard for the
developers: let each user specify a short list of "trusted users". Then
the option would be to show all Recent Changes that DON'T HAVE an "RC
Cleared" flag from anyone in my "trusted users" set.

(The SQL code for this is trivial, by the way.)

With a flag like "Unfair revert", we could sort articles by:

* Current version has more than 2 "Unfair revert" flags; or,

* More than a total of 5 "Unfair revert" flags have been placed on all
versions of this article in the last 3 days.

(Each user could specify parameters like "more than 3 flags" on current
version, or "more than 12 total in the last 5 hours".)

The questions are:

A. Does anyone else want this?
B. Will it slow down the server?
C. Is it valuable enough to justify trying it out?

Ed Poor
Developer Emeritus


body:
Hi.

I've committed a new feature I just wrote. Recent Changes Patrol. The
commit message explains everything:

	New feature: Recent Changes Patrol. All edits and new pages are
	now highlighted on Special:Recentchanges and Special:Newpages
	until someone "marks" them as "patrolled" using a special link.
	For new pages, this link appears at the bottom of the article if
	the link in Recent Changes or New Pages is followed. For all
	other edits, this link appears only in the diff and only if the
	diff link is followed from Recent Changes. (Might need to add
	this functionality to Watchlist too; haven't done that yet.)

Since the patch you see in the CVS commit messages is useless because of
all the pointless whitespace removal, I am providing here a patch in
diff -u format which ignores the whitespace changes:

http://lionking.org/~timwi/t/wikipedia/recent-changes-patrol-patch.txt

Please test this feature thoroughly. Thanks!
Timwi


subject: [WikiEN-l] Recent Changes Patrol

body:
Hi.

I have just written a new feature which I hope will be useful to users
interested in a Recent Changes Patrol system. I wrote:

     New feature: Recent Changes Patrol. All edits and new pages are
     now highlighted on Special:Recentchanges and Special:Newpages
     until someone "marks" them as "patrolled" using a special link.
     For new pages, this link appears at the bottom of the article if
     the link in Recent Changes or New Pages is followed. For all
     other edits, this link appears only in the diff and only if the
     diff link is followed from Recent Changes. (Might need to add
     this functionality to Watchlist too; haven't done that yet.)

THIS FEATURE IS NOT YET LIVE on the real Wikipedia. I'm only announcing
it here so that you no longer need to discuss this topic and talk about
hypothetical alternatives. Maybe someone will put this feature live on a
test server, and then you can have a go at it.

Greetings,
Timwi


subject: [Wikipedia-l] Recent Changes Patrol

body:
Hi.

I posted this to wikien-l, but actually I meant to post it here. So here
it is again.

I have just written a new feature which I hope will be useful to users
interested in a Recent Changes Patrol system. I wrote:

     New feature: Recent Changes Patrol. All edits and new pages are
     now highlighted on Special:Recentchanges and Special:Newpages
     until someone "marks" them as "patrolled" using a special link.
     For new pages, this link appears at the bottom of the article if
     the link in Recent Changes or New Pages is followed. For all
     other edits, this link appears only in the diff and only if the
     diff link is followed from Recent Changes. (Might need to add
     this functionality to Watchlist too; haven't done that yet.)

THIS FEATURE IS NOT YET LIVE on the real Wikipedia (or any other
project). I'm only announcing it here so that you no longer need to
discuss this topic and talk about hypothetical alternatives. Maybe
someone will put this feature live on a test server, and then you can
have a go at it.

Greetings,
Timwi


from_name: Jimmy (Jimbo) Wales

subject: [Wikipedia-l] Re: Request for the second Serbian Wikipedia

body:
millosh wrote:
> You say that I work against the decision of community... Scripts are
>not the problem, I understand functions of bots. The problem is
>decision of community, and this is not to work in Latin alphabet on
>sr:.

Hello!

You mentioned that the vote is 4:2, but that there are not many users.
Can you give us the overall vote totals (not just the ratio)?  If it
is exactly 4 to 2, is that really enough people to be making such a
controversial policy?

Perhaps the time is not ripe yet to make such a decision.

--Jimbo


subject: [Wikitech-l] machine translaton of the articles...

body:
prasad gadgil wrote:
> I have just joined, I am from mumbai, india. I would like to get the
> articles translated in marathi, my mother tongue. Looking at the effort
> and no of volunteers, this will not be usable in any reasonable amount
> of time.

I understand.  According to Wikipedia, there are 68 million native
speakers of Marathi, and 3 million second language speakers.  This is
comparable, for example, to Italian, with 70 million total speakers.

Getting Wikipedia content in languages such as Marathi is absolutely
central to our mission, and so I want you to know that I support you
fully in your desire to find ways to make this happen in a timely and
effective manner.

> That has made me think of alternatives - machine translation. A state
> funded institute has a software available but I don't have access to it
> yet.
>
> Pl. comment about this approach. Has this been tried for any other
> language earlier.

First, it is important to understand that for the most part, the individual
wikipedia languages are not mere translations.  In some cases, of course,
contributors find it easier to just translate an article -- after all, for
many many topics, en.wikipedia.org is the most convenient and best reference,
and the content is available for free.  But it is more generally the case in
fr, de, ja, it, etc. that the articles are independent constructions from
scratch.

Second, machine language translation is typically quite poor.  It is not
likely that the tool you are talking about can do a good enough job.

At the same time, I absolutely think that if you can find a way to get
access (is there some way that I can help, for example by writing a
letter to some authorities, or giving you a signature on an
application, or even paying money, if it is not too much?) for
wikipedia contributors to this state-funded agency's tool, then if it
helps a small number of contributors to work faster, then I am all for
it.

What I would envision is that you would have to do a machine
translation and then immediately edit it to correct grammar and
meaning mistakes.  Whether that would be faster or slower than either
writing the article from scratch or doing a human-translation
yourself, I do not know.

--Jimbo


subject: [Wikitech-l] Re: New feature: Recent Changes Patrol

body:
evan at wikitravel.org wrote:

> On Mon, Aug 09, 2004 at 06:49:43AM +0100, Timwi wrote:
>
>>I've committed a new feature I just wrote.
>
> Suggestion: in the future, mention the feature on this list _before_
> committing it. You'll get some good feedback, and maybe some good ideas.

You can still provide feedback; there is no need to delay the
committing. In fact, committing it allows someone with the relevant
access privileges to put it on a test server. So you can provide even
more feedback.

> Did you make this feature optional? If not, could you, please?

This feature does not take anything away, so making it "optional"
doesn't make any sense. That's like saying "please could you make the
wiki syntax for bold text optional?" - you don't have to use it. You can
remove the highlighting using CSS.

Timwi


subject: [WikiEN-l] Re: Recent Changes Patrol

body:
Daniel Mayer wrote:

> Neat! But who gets to mark an edit as "patrolled"?

I made it so that each wiki can be set up to allow either all logged-in
users or only sysops to do this. (techtalk: set $wgOnlySysopsCanPatrol
in LocalSettings.php)

> Letting an anon or new user do that would tend to defeat the purpose.

I was going to make it so that you can't "patrol" your own edits, but I
haven't done that yet. (techtalk: it would require an extra DB query)

> Also, depending on a single person's
> judgment may be problematic as well.

True. Fortunately, the database field I created (rc_patrolled) can be
used to store a number, too, so it can be changed to be a counter, and
the highlighting can be made to stay until the counter has reached a
certain threshold.

> But this at least is a good start. I thank you for coding this feature. :)

Welcome :)

Timwi


from_name: karl at karllong.com

subject: [Wikitech-l] installation problem

body:
Hi all,
I'm trying to install mediawiki on a shared host and am getting an error
regarding the /tmp directory:

Checking environment...

      Warning: set_time_limit(): Cannot set time limit in safe mode in
/home/virtual/site22/fst/var/www/html/wiki/install-utils.inc on line
26
    * PHP 4.3.3 ok
    * PHP server API is apache; ok, using pretty URLs (index.php/Page_Title)
    * Have XML / Latin1-UTF-8 conversion support.
    * PHP's memory_limit is 8M. If this is too low, installation may fail!
Attempting to raise limit to 20M... failed.
    * Have zlib support; enabling output compression.
    * Found GD graphics library built-in, image thumbnailing will be
enabled if you enable uploads.
    * Installation directory: /home/virtual/site22/fst/var/www/html/wiki
    * Script URI path: /wiki
      Warning: $wgProxyKey is insecure Can't find a writable temp
directory for the XHTML template. Check that the TMP environment
variable points to a writable directory, or that the default temp
dir (/tmp) exists and is writable.

I have acttually created a /tmp directory in my mediawiki directory and
made it writable, I've also gone into the PHPTAL.php and changed the TMP
variable to a foll path ie.
/home/virtual/site22/fst/var/www/html/wiki/tmp, but that still results in
the install seeming to hang  at "Warning: $wgProxyKey is insecure"

Any help is appreciated,

Karl


subject: [Wikitech-l] (no subject)

body:
You can disregard my comment about changing the PHPTAL.php as I've done a
clean installation. The only action I have taken is to create a directory
(writable by everyone) called /tmp in the media wiki folder.

The error I get when installing is this:

Checking environment...

      Warning: set_time_limit(): Cannot set time limit in safe mode in
/home/virtual/site22/fst/var/www/html/wiki/install-utils.inc on line
26
    * PHP 4.3.3 ok
    * PHP server API is apache; ok, using pretty URLs (index.php/Page_Title)
    * Have XML / Latin1-UTF-8 conversion support.
    * PHP's memory_limit is 8M. If this is too low, installation may fail!
Attempting to raise limit to 20M... failed.
    * Have zlib support; enabling output compression.
    * Found GD graphics library built-in, image thumbnailing will be
enabled if you enable uploads.
    * Installation directory: /home/virtual/site22/fst/var/www/html/wiki
    * Script URI path: /wiki
      Warning: $wgProxyKey is insecure Can't find a writable temp
directory for the XHTML template. Check that the TMP environment
variable points to a writable directory, or that the default temp
dir (/tmp) exists and is writable.

Thanks for any help,

Karl

> <karl at karllong.com>:
>> I have acttually created a /tmp directory in my mediawiki directory and
>> made it writable, I've also gone into the PHPTAL.php and changed the TMP
>> variable to a foll path ie.
>> /home/virtual/site22/fst/var/www/html/wiki/tmp, but that still results in
>> the install seeming to hang  at "Warning: $wgProxyKey is insecure"
>
> What dit you change exactly in PHPTAL.php?


subject: [Wikitech-l] installation problem


subject: [Wikitech-l] installation problem

body:
I've actually found several tmp directories (writable by everyone):
/home/virtual/site22/fst/tmp
/home/virtual/site22/fst/var/tmp

I'm not permissioned to write to /var/www/

I wonder if there is somewhere I can tell the mediawiki installer to use
on of those tmp directories.

> If I'm not mistaken you need the tmp-directory in your virtual host
> setting to be writeable by your apache user.
> Maybe you got a tmp directory like so /home/virtual/site22/fst/var/www/tmp
> in the virtual_host config of your account (So it's outside docroot). That
> virtual host directory may have permissions like drwxr_xr_x or just
> drwx______ with you as owner and ftpuser as group.
> That's something the apache user won't have any write permissions to. If
> so, you can give that tmp directory write permissions like 777 or ask your
> provider to do a chown apache-user.apache-user (www-data in my case) to
> that tmp directory and it should work.
>
> But that would mean your VirtualHost setup is being a poor, sad story.
> I.e. not real useful.
>
> --tictric