from_name: leercontainer-wikimedia at yahoo.com

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

body:
As far as I understood this message, you are not looking for a way of
limiting access and edits, merely a way of approving edits.

I have seen a feature that I think would be usable for you on a
MediaWiki roadmap some time ago. It was supposed to be an alternative
to protecting pages that is already implemented in some other wiki
software.

What the feature did was that you could specify a time period that a
page had to be "stable" before edits to a page were "activated", and
thereby presented to the readers. Lets say this period was set to 7
days "the approvers" would have 7 days to discover and fix any
maliscious edits before they were presented to the readers of the
website.

I don't know what wiki software has this feature, or if it still is on
some roadmap, but I myself find it a very neat feature, and with the
new database scheme it should't be too hard to implement in MediaWiki
either I'm guessing.

--Dittaeva

--- Randy Becker <lemnar at gmail.com> wrote:

> I'm a high school student involved in our website
> (http://www.rileyhighschool.com/). After taking a look at the sorry
> state of our site, and subsequently visiting wikipedia, I came to the
> realization that a wiki, especially mediawiki, would be enormously
> beneficial to our site in many ways. I investigated further,
> installed
> 1.3, got some content in, customized monobook a little bit, got
> familiar with the software. I decided that it really would be a great
> improvement, and continued further testing. Upon further review, and
> in conversation with the administration, it was determined that the
> principal objection to using mediawiki as our primary site was that
> anyone could edit. Although it has been presented that this is not a
> serious problem in practice, it was still too much of a risk for them
> to take. Downtrodden, but not discouraged, knowing that mediawiki is
> an open source product, and being familiar with php and mysql, I
> looked further into what was available. Ultimately, it was determined
> that unapproved edits cannot come to exist in the first place,
> irregardless of the ease of their removal. I began looking for a way
> to implement an approval mechanism.
>
> On #mediawiki it was suggested that I look into the recent changes
> patrolling in 1.4 as a potential method of implementing this
> solution.
> I have done this and determined that it will be just as difficult to
> use this as it will be to implement a cleaner solution, involving a
> new table in the database and an approval mechanism. Therefore, I'm
> here to ask for suggestions, comments, and help implementing this, or
> a similarly acceptable solution.
>
> -Randy


list: wikitech-l

source: pipermail-mbox

from_name: Ashar Voultoiz

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

body:
Anthere wrote:
> you dropped the forum idea ? :-)

I still think a forum is better for the village pump, I just almost
stopped reading it :o)

--
Ashar Voultoiz


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

body:
Evan Prodromou wrote:
> On Fri, 2004-10-01 at 00:15 +0200, Ashar Voultoiz wrote:
>>Hello,
>>
>>I am willing to know if we are willing to use a blog software to
>>communicate with wikipedians and mediawiki users.
>
> Any particular reason not to do it as a wikiblog?

Basicly : RSS feeds, automatic archiving and the ability to only read
the content that matter (eg split posts using "development", "wikifarm"
and categories).

--
Ashar Voultoiz


from_name: Erik Moeller

subject: [Wikitech-l] devs and admins blog

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

I strongly believe that MediaWiki should support chronological display of
content blocks. Essentially, you would have something like

        {{News:5 new abstracts}}

which would insert summaries of the 5 most recently created pages from the
News: namespace in reverse chronological order + link to talk page. This
could be done with any existing namespace. (The abstracts would have to
somehow marked up in the source page, e.g. using <abstract></abstract>.)

What about updates? This could be solved through the minor/major edit
flags. Minor edits do not affect the sort order, while major edits push a
story to the top.

Add in a "Post new entry" link that creates a page in the desired
namespace, and you've got a nice wikiblog. For Wikinews I think some more
advanced workflow will be necessary, but for what you are proposing this
should be enough.

So I strongly suggest hacking on something like this instead of installing
a blog software. Blogs are a dime a dozen and do not make good use of the
potential of collaboration.

Regards,

Erik


list: wikien-l

from_name: Sj

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

body:
That sounds right to me also.
Jens, perhaps a simple poll asking about 3 months?
That should pass most easily, and deal with 95% of the
problem cases.

+sj+

On Thu, 30 Sep 2004 20:14:29 -0700 (PDT), Mark Richards
<marich712000 at yahoo.com> wrote:
> I have followed this a little, and it seems that there
> is a concensus that a reasonable amount of time should
> pass between relisting of the same article. 3-6 months
> seems reasonable to me, I think another poll proposing
> this would pass easily.
> Mark
>
> --- Jens Ropers <ropers at ropersonline.com> wrote:
>
> > This poll on an amendment to the deletion policy:
> > >> http://en.wikipedia.org/wiki/Wikipedia_talk:
> > >>
> >
> Deletion_policy#Proposed_new_rule:_No_repeat_submission_of_articles


list: wikipedia-l

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

body:
David-
> It seems to me that the syntax for templates, image thumbnails, tables,
> and mathematic formulas have already made the wikitext hard to read and
> understand for new users.

Not really. Templates hide complexity and give ordinary users the power to
quickly make use of things like nicely formatted infoboxes without knowing
anything about the HTML. I have to admit that I am not a big fan of our
table syntax, however; I'm as geeky as they come and I still fall back to
HTML every now and then. The reStructured Text syntax is much lovelier,
albeit easy to mess up:

+------------------------+------------+----------+----------+
| Header row, column 1   | Header 2   | Header 3 | Header 4 |
| (header rows optional) |            |          |          |
+========================+============+==========+==========+
| body row 1, column 1   | column 2   | column 3 | column 4 |
+------------------------+------------+----------+----------+
| body row 2             | Cells may span columns.          |
+------------------------+------------+---------------------+
| body row 3             | Cells may  | - Table cells       |
+------------------------+ span rows. | - contain           |
| body row 4             |            | - body elements.    |
+------------------------+------------+---------------------+
http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#tables

Still, I think a combination of something like this for quick tables, and
HTML hidden in templates for complex ones would be best.

Like templates, image tags have also reduced the amount of visible HTML in
articles - don't you remember when we cleaned out all the
 tags? This is a good thing. Surely you're not
suggesting there's a need for empirical proof that added complexity deters
newbies? I hold that truth to be self-evident, but in case you don't,
browse around a TWiki or TikiWiki site sometime.

I believe that in the long term, we must entirely eliminate HTML from all
regular pages and limit its use exclusively to templates. For this, we
need to make some improvements to the template syntax (default values,
loops, conditions) so that all current HTML content can be moved there and
used dynamically.

Things which need a clean wikitext replacement:
- —   (my suggestion: --)
-      (my suggestion: __)
-
      (my suggestion: \\)
...

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

I think you won't find any supporters for that scheme ;-). Even though we
have ugliness in some articles, our sentences are at least readable. The
current situation with regard to spelling is somewhat dissatisfactory to
consistency nuts like ourselves, but aside from auto-conversion for the
most common words (which would probably take too much performance to be
worthwhile), I really see no good solution.

Regards,

Erik


from_name: Ray Saintonge

body:
David Friedland wrote:

> Delirium wrote:
>
>> Angela wrote:
>>
>>> One reason is that the differences between American and British
>>> English are more involved than simply changing the spelling of a few
>>> words. Punctuation and grammar are also involved. If you changed
>>> behavior to behaviour in an otherwise AE sentence, the sentence would
>>> then be wrong in both languages.
>>
>> I can't seem to find the page now, but I seem to remember a policy
>> page where we've basically settled on a compromise,
>> partially-invented "international English" punctuation style for
>> clarity and because it's not really worth fighting over.  The
>> compromise included the British-style "put punctuation _after_
>> closing quotation marks", and something from US style that I can't
>> remember.  As for being "wrong", that's only the case if you happen
>> to be a [[en:prescription and description|grammatical
>> prescriptivist]], which not all of us are.
>>
>> But as far as the spelling issue goes, it seems like a solution in
>> search of a problem.  The current approach seems to be working well
>> enough.
>
> I heartily disagree. The current approach is a constant source of
> disagreement and worsening of linguistic tensions. I am always running
> into minor tiffs over British vs American spelling that could be
> eliminated with multi-dialect support. This would also mean that when
> I run into a Britishism on an article that might be confusing or
> misleading to an American reader, instead of changing it to an
> Americanism and drawing the ire of the original author (or changing it
> to something neutral and probably drawing the ire of the original
> author), the original author's Britishism can stay, the Americanism
> will be viewable to Americans, and everyone is a little bit happier.
>
> I think that the minor increase in complexity for editing is far
> outweighed by the increase in understandability, familiarity, and
> dialectical consistency. As for syntactic differences between the
> dialects, I have yet to see anything that differed by more than a
> handful of words. Most of the major differences are in informal,
> colloquial speech.

I agree with Mark and Angela on this. Your position is premised on their
being only two strictly demarcated forms of English.  Canadian English
is a hybrid that lies between the two, and often depends on the
preferences of the individual who happens to be writing.  Australians
and South Africans may generally tend toward Commonwealth English, but
they too can have their esceptions.  Indian English must have a lakh of
interesting variations, and we haven't yet considered African and
Caribbean variants.  I can't possibly imagine a hardware fix that would
adequately deal with all these rich varieties.

Ec


from_name: Angela

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

body:
On Thu, 30 Sep 2004 20:05:32 -0400, Evan Prodromou <evan at wikitravel.org> wrote:

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

There are already two development wikis. One is at
http://mediawiki.wikimedia.org/wiki/Main_Page and never used. The
other is at http://wp.wikidev.net/Main_Page which makes more sense
than dev.wikimedia.org would because it means the developers still
have their stuff to work from when Wikimedia's servers are down.

The ability to add something blog-like to an existing wiki page would
be better than having to have it outside the wiki. You lose the
advantages of recent changes, watchlists, contributions lists etc if
you have to use an external forum. I think this why the Wikimedia
Boards at http://boards.wikimedia.org never took off.

Angela.


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

body:
Erik Moeller wrote:
> Ashar-
>
>>Developpers and wikifarm administrators will be able to post lengthy
>>articles about the various things happening. Be it new servers added to
>>the farm, new features being developped or polling the user base to help
>>us make choices.
>
>
> I strongly believe that MediaWiki should support chronological display of
> content blocks. Essentially, you would have something like
>
>         {{News:5 new abstracts}}
>
> which would insert summaries of the 5 most recently created pages from the
> News: namespace in reverse chronological order + link to talk page. This
> could be done with any existing namespace. (The abstracts would have to
> somehow marked up in the source page, e.g. using <abstract></abstract>.)
>
> What about updates? This could be solved through the minor/major edit
> flags. Minor edits do not affect the sort order, while major edits push a
> story to the top.
>
> Add in a "Post new entry" link that creates a page in the desired
> namespace, and you've got a nice wikiblog. For Wikinews I think some more
> advanced workflow will be necessary, but for what you are proposing this
> should be enough.
>
> So I strongly suggest hacking on something like this instead of installing
> a blog software. Blogs are a dime a dozen and do not make good use of the
> potential of collaboration.
>
> Regards,
>
> Erik

Helo,

Of course it's possible to hack MediaWiki further more. But I believe
it's far easier to install a blog software, have it ready and set up in
like 10 minutes.

The aim of the blog will not aim at building a cooperative content,
that's what wiki is for. Instead it will help easily publish important
messages from the dev/admin team to the userbase be it maintenance, new
releases, ongoing changes available on test.wikipedia.org .

--
Ashar Voultoiz


body:
Angela wrote:

>Wiki is supposed to be easy to edit. Having markup like the following
>is going to be very off-putting to most users, and not only to
>newcomers.
>
>with one g like {-en-us garbage en-gb rubbish-},
>
In some parts of the US it is "trash" :-)

Ec


from_name: Ævar Arnfjörð Bjarmason

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

body:
Though i am not very familiar with MediaWiki itself you should be able
to do this with htaccess rules in apache, just require a password
which you give out to trusted users, such as those in the student body
to everything that matches /w/wiki.phtml?title=*&action=history

On Thu, 30 Sep 2004 21:02:56 -0500, Randy Becker <lemnar at gmail.com> wrote:
> I'm a high school student involved in our website
> (http://www.rileyhighschool.com/). After taking a look at the sorry
> state of our site, and subsequently visiting wikipedia, I came to the
> realization that a wiki, especially mediawiki, would be enormously
> beneficial to our site in many ways. I investigated further, installed
> 1.3, got some content in, customized monobook a little bit, got
> familiar with the software. I decided that it really would be a great
> improvement, and continued further testing. Upon further review, and
> in conversation with the administration, it was determined that the
> principal objection to using mediawiki as our primary site was that
> anyone could edit. Although it has been presented that this is not a
> serious problem in practice, it was still too much of a risk for them
> to take. Downtrodden, but not discouraged, knowing that mediawiki is
> an open source product, and being familiar with php and mysql, I
> looked further into what was available. Ultimately, it was determined
> that unapproved edits cannot come to exist in the first place,
> irregardless of the ease of their removal. I began looking for a way
> to implement an approval mechanism.
>
> On #mediawiki it was suggested that I look into the recent changes
> patrolling in 1.4 as a potential method of implementing this solution.
> I have done this and determined that it will be just as difficult to
> use this as it will be to implement a cleaner solution, involving a
> new table in the database and an approval mechanism. Therefore, I'm
> here to ask for suggestions, comments, and help implementing this, or
> a similarly acceptable solution.
>
> -Randy
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


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

body:
> The ability to add something blog-like to an existing wiki page would
> be better than having to have it outside the wiki. You lose the
> advantages of recent changes, watchlists, contributions lists etc if
> you have to use an external forum. I think this why the Wikimedia
> Boards at http://boards.wikimedia.org never took off.
>
> Angela.

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

--
Ashar Voultoiz


subject: [Wikitech-l] Vandalism problem

body:
We've been having a bit of trouble with a vandal [[User:Hi332211]] at
Wiktionary.  He has been using the move function to transfer the Main
Page to silly places.  I managed to get the Main Page back to where it
belongs, but lost its history in the process.  By using the history link
in Recent Changes corresponding to when he made the move I find the
entire history is now at
http://en.wiktionary.org/w/wiki.phtml?title=You_are_an_idiot%21&curid=58201&action=history
but I don't know how to put it back where it belongs.

The talk page is now at [[Wiktionary talk:Main Page]] along with its
history.  Someone else had put it there in an attempt to fix the
vandalism.  I hesitate to attempt correcting this lest I lose that
history as well.

The Main Page has been protected, and the vandal is now blocked.

Ec


from_name: Stirling Newberry

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

Getting to consensus, even if the process is acrimonious, is part of
what we do here. If there is a localized expression, then it should be
filed away, even if the original editor isn't happy with it. Getting to
NPOV doesn't just mean overt biases, but also the less overt ones, one
of which is geographic origin. So if you run into it, comment it or put
it on the discussion page and keep going.


from_name: Jens Ropers

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

body:
1. This should solve your problem:
   http://meta.wikimedia.org/wiki/Preventing_Access
   Simply prevent anonymous editing and prevent new registrations
(otherwise any Internet surfer could just register themselves). Then
appoint a person (or a number of persons) who will be responsible for
manually creating accounts for anybody who you want to be able to edit.
All of these measures are described on the meta page as per the above
link.

2. Your needs (which are easily solved by implementing the instructions
as per the above link) probably differ significantly from the Wikipedia
community's needs for an approval mechanism. One reason why they differ
is that there isn't consensus yet within the Wikipedia community on
just what kind of an approval mechanism (if any) we want. Incidentally,
I am going to present a detailed proposal on this here:
http://meta.wikimedia.org/wiki/
Wikimedia_meetup_2005#Possible_speakers_and_workshops
Consensus on and implementation of a Wikipedia approval mechanism may
be some time off (and, again, may differ significantly from your
needs).

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

On 1 Oct 2004, at 04:02, Randy Becker wrote:

> I'm a high school student involved in our website
> (http://www.rileyhighschool.com/). After taking a look at the sorry
> state of our site, and subsequently visiting wikipedia, I came to the
> realization that a wiki, especially mediawiki, would be enormously
> beneficial to our site in many ways. I investigated further, installed
> 1.3, got some content in, customized monobook a little bit, got
> familiar with the software. I decided that it really would be a great
> improvement, and continued further testing. Upon further review, and
> in conversation with the administration, it was determined that the
> principal objection to using mediawiki as our primary site was that
> anyone could edit. Although it has been presented that this is not a
> serious problem in practice, it was still too much of a risk for them
> to take. Downtrodden, but not discouraged, knowing that mediawiki is
> an open source product, and being familiar with php and mysql, I
> looked further into what was available. Ultimately, it was determined
> that unapproved edits cannot come to exist in the first place,
> irregardless of the ease of their removal. I began looking for a way
> to implement an approval mechanism.
>
> On #mediawiki it was suggested that I look into the recent changes
> patrolling in 1.4 as a potential method of implementing this solution.
> I have done this and determined that it will be just as difficult to
> use this as it will be to implement a cleaner solution, involving a
> new table in the database and an approval mechanism. Therefore, I'm
> here to ask for suggestions, comments, and help implementing this, or
> a similarly acceptable solution.
>
> -Randy
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


from_name: Randy Becker

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

body:
As to restricting new accounts: This is what we have already done, but
it still is not enough, as there are only 1-2 people with the
authority and common sense to dictate what is and is not appropriate
and fitting material for the wiki. In addition, the wide collaborative
structure is seen as very much a benefit, owing to the large group of
people (faculty, staff, students, alumni) who would have an interest
in contributing. Thus, we wish to allow anonymous editing etc. In
short, too many people need access to easy editing to restrict our
user group so much.

As to a "stable" time: Yes, we really want to not limit access as much
as possible, to encourage widespread contribution. On the "stable"
time, this is actually where I am currently headed with my
modifications based on the patrolled flag, and it is only present in
the recent changes table, and that table is cleared after a certain
amount of time, of a certain number of edits, I believe. This would
cause whatever was in cur to be displayed.

This is part of the reason I'm swaying away from the current course
I've taken, and towards a cleaner approach, but I will bring up the
"stable time" to see if it's an acceptable solution. Also, part of the
problem with this is how does it reach a stable point, as *all*
evidence of an edit by a user should not be evident from the wiki,
except to sysops or the like. (editing should display the previously
approved entry, and only approved entries should appear in the history
etc.) Because of all of this, I'm thinking of trying to implement a
kind of queue of edits, which would bee looked at, and then approved
or rejected, and if rejected, just dropped, if approved, added as if
the user which submitted them had added them themselves.

-Randy

On Fri, 1 Oct 2004 01:26:35 -0700 (PDT),
leercontainer-wikimedia at yahoo.com <leercontainer-wikimedia at yahoo.com>
wrote:
> As far as I understood this message, you are not looking for a way of
> limiting access and edits, merely a way of approving edits.
>
> I have seen a feature that I think would be usable for you on a
> MediaWiki roadmap some time ago. It was supposed to be an alternative
> to protecting pages that is already implemented in some other wiki
> software.
>
> What the feature did was that you could specify a time period that a
> page had to be "stable" before edits to a page were "activated", and
> thereby presented to the readers. Lets say this period was set to 7
> days "the approvers" would have 7 days to discover and fix any
> maliscious edits before they were presented to the readers of the
> website.
>
> I don't know what wiki software has this feature, or if it still is on
> some roadmap, but I myself find it a very neat feature, and with the
> new database scheme it should't be too hard to implement in MediaWiki
> either I'm guessing.
>
> --Dittaeva
>
>
>
> --- Randy Becker <lemnar at gmail.com> wrote:
>
> > I'm a high school student involved in our website
> > (http://www.rileyhighschool.com/). After taking a look at the sorry
> > state of our site, and subsequently visiting wikipedia, I came to the
> > realization that a wiki, especially mediawiki, would be enormously
> > beneficial to our site in many ways. I investigated further,
> > installed
> > 1.3, got some content in, customized monobook a little bit, got
> > familiar with the software. I decided that it really would be a great
> > improvement, and continued further testing. Upon further review, and
> > in conversation with the administration, it was determined that the
> > principal objection to using mediawiki as our primary site was that
> > anyone could edit. Although it has been presented that this is not a
> > serious problem in practice, it was still too much of a risk for them
> > to take. Downtrodden, but not discouraged, knowing that mediawiki is
> > an open source product, and being familiar with php and mysql, I
> > looked further into what was available. Ultimately, it was determined
> > that unapproved edits cannot come to exist in the first place,
> > irregardless of the ease of their removal. I began looking for a way
> > to implement an approval mechanism.
> >
> > On #mediawiki it was suggested that I look into the recent changes
> > patrolling in 1.4 as a potential method of implementing this
> > solution.
> > I have done this and determined that it will be just as difficult to
> > use this as it will be to implement a cleaner solution, involving a
> > new table in the database and an approval mechanism. Therefore, I'm
> > here to ask for suggestions, comments, and help implementing this, or
> > a similarly acceptable solution.
> >
> > -Randy
>
>


from_name: Charles Matthews

subject: [WikiEN-l] Censorship by vfd

body:
Ed Poor wrote

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

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

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

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

Not my country, not my politics.  There is a prima facie case that anything
a President of the USA says or does might be significant.

BUT - Ed, your argument is really that WP should be in a state so that it
can be used as a rebuttal machine, by party-political Americans.  I see no
reason that it should be.  I don't think that that is the project I'm
working on; and it looks to me that it would just make matters worse, from
the point of view of partisan people trying to get 'their' points in.

I would have thought that major speeches on foreign policy find their
natural home in narratives of international events.

Charles


subject: [Wikitech-l] Re: HEADS UP: major database schema change in 1.4

references:
<9881B450-0FFB-11D9-B5C6-000A95DAA284@pobox.com>
	<9H$5X+OxpVB@erik_moeller> <cjjihu$kva$2@sea.gmane.org>

body:
On Fri, 01 Oct 2004 14:29:03 +0200, Timwi <timwi at gmx.net> wrote:
>
> Personally, I'd prefer a transition without downtime such as the one I
> proposed before, but nobody seemed interested enough to discuss it.

To the contrary, I think this is very interesting, the right way to do things,
and worth serious discussion.   It sounded as though Ivan might have
been interested in a no-downtime solution as well.

--
+sj+


from_name: Jimmy (Jimbo) Wales

subject: [Wikitech-l] shell accounts

body:
I'm a little confused on the process whereby we make decisions about
shell access.  I'm thinking right now primarily of access for a couple
of people from the German e.V. to work on their website, which doesn't
yet exist, rather than thinking of shell access to the main cluster.

Related to this, it seems sensible to me that we should buy a special
server to host things that we want to be separate, like for example
the donation pages, so that if wikipedia is blown up for some reason,
people can still donate money.  This would also permit us to give
shell accounts more freely to people with a specific need on some
auxiliary website.

--Jimbo

--
"La n??fle est un fruit." - first words of 50,000th article on fr.wikipedia.org


from_name: Carson, David

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

body:
Ed Poor wrote:
> If there are a dozen or 6 dozen separate, tiny articles with a common
> theme, then why not:
>
> * Copy the text of each article into one new comprehensive article
(like
> [[List of Apprentice contestants]]
> * Turn the text of each old article into:  #REDIRECT [[List of
> Apprentice contestants]]
>
> This is how Maveric asked me to handle the Simpsons, way back when...

That's what I voted for, and indeed, that was the overwhelming consensus
of the VFD vote, and is what has been done.

And indeed, that could have been boldly done by someone without needing
a VFD vote. But I would say that (a) there would have been a guaranteed
edit war following it; and (b) there WAS a definite minority opinion
that these people didn't deserve to be in the Wikipedia AT ALL, being
merely "game show contestants".

Me, I see the whole affair as further proof that VFD is not at all
broken, and continues to excellently serve the community.

Cheers!
David...

_____________________________________________________________________________________________________
This email and its attachments are for the sole use of the addressee and may contain information which is confidential and/or
legally privileged. This email and its attachments are subject to copyright and should not be partly or wholly reproduced without
the consent of the copyright owner. Any unauthorised use of disclosure of this email or its attachments is prohibited. If you receive
this email in error, please immediately delete it from your system and notify the sender by return email.


list: wiktionary-l

from_name: Gerard Meijssen

subject: [Wiktionary-l] Request for comment

body:
Gerard Meijssen wrote:

> On [[wikt:nl:Egypte]] I have two things that I would like your
> comments for.
>
> * Under the header for pronounciation, it says on a line: * Geluid:
> Egypte
>    When pressing the template for sound ( {{-sound-}}translates to
> Geluid ), you get a sound.howto
>    When pressing on Egypte, the process of letting you hear Egypte
> will start (media)
> *Under the header for Translations, there are three lines for Portugese;
>    * Indicating Portugese
>       One line with Brazilian Portugese and the word
>       One line with Portugese Portugese and the word
>
> With the first thing I think I give ample attention to the potential
> problems with sound. When there is a SAMPA transliteration, it would
> be on a seperate line and the SAMPA would get you to something about
> SAMPA,
>
> With the second thing I think I have a proper way of presenting
> alternate standard translations within one language. the templates
> used are {{pr br}} and {{pt pt}}
>
> Thanks,
>    GerardM

In addition  to Portugese, English and German, I have added two
templates for Chinese zh-sc for Simplified Chinese and zh-tc for
Traditional Chinese. The way of presenting will be like mentioned above
for Portugese.

Thanks,
    GerardM


from_name: Brion Vibber

subject: [Wikipedia-l] Editing only by registered users

body:
On Oct 1, 2004, at 9:14 AM, Stephen Brandwood wrote:
> I was suprised not to see anything about this on the Meta Wiki, as it
> seems like a common practice to use on some Wikis.

http://meta.wikimedia.org/wiki/Help:Installation_FAQ

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20041001/2da7e311/attachment.pgp


from_name: Lars Aronsson

subject: [Wikitech-l] Webalizer stats missing again

body:
It is today October 1st, and the page http://en.wikipedia.org/stats/
was last updated September 27th.  It should be updated daily.
Furthermore, the numbers for September 24th thru 26th seem
unrealistically low.  The same goes for other languages.

What's up?  Are we losing Webalizer again?  Why?  Is the disk full?
It has worked fine in July and August.

Lars Aronsson, lars at aronsson.se
--
  Aronsson Datateknik


from_name: Matt Brown

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

body:
Listing on VfD is not equivalent to deletion.

My experience is that very few if any articles are ever deleted
through VfD that should not be.  Those cases and most borderline ones
then have the option of VfU.

VfD is really about trying to get the community opinion about an
article's inclusion.  Options other than straight keep or straight
delete are often used too -- in this case, merging into one article.

-Matt

On Thu, 30 Sep 2004 20:17:13 -0700 (PDT), Mark Richards
<marich712000 at yahoo.com> wrote:
> This highlights to problem of deletion. In the case
> you are talking about, someone should very much have
> boldly edited this as redirects. If this had happened
> to be wrong, people would have seen it, and it could
> have been put right through wiki process.
>
> Deletion is a totally different beast, it removes the
> information, and, for most users, even the evidence
> that it was ever there, removing the possibility of
> process to improve the information.
>
> Mark
>
>
>
> --- "Carson, David" <DCarson at nine.com.au> wrote:
>
> > Ed Poor wrote:
> > > If there are a dozen or 6 dozen separate, tiny
> > articles with a common
> > > theme, then why not:
> > >
> > > * Copy the text of each article into one new
> > comprehensive article
> > (like
> > > [[List of Apprentice contestants]]
> > > * Turn the text of each old article into:
> > #REDIRECT [[List of
> > > Apprentice contestants]]
> > >
> > > This is how Maveric asked me to handle the
> > Simpsons, way back when...
> >
> > That's what I voted for, and indeed, that was the
> > overwhelming consensus
> > of the VFD vote, and is what has been done.
> >
> > And indeed, that could have been boldly done by
> > someone without needing
> > a VFD vote. But I would say that (a) there would
> > have been a guaranteed
> > edit war following it; and (b) there WAS a definite
> > minority opinion
> > that these people didn't deserve to be in the
> > Wikipedia AT ALL, being
> > merely "game show contestants".
> >
> > Me, I see the whole affair as further proof that VFD
> > is not at all
> > broken, and continues to excellently serve the
> > community.
> >
> > Cheers!
> > David...
> >
> >
> >
> _____________________________________________________________________________________________________
> > This email and its attachments are for the sole use
> > of the addressee and may contain information which
> > is confidential and/or
> > legally privileged. This email and its attachments
> > are subject to copyright and should not be partly or
> > wholly reproduced without
> > the consent of the copyright owner. Any unauthorised
> > use of disclosure of this email or its attachments
> > is prohibited. If you receive
> > this email in error, please immediately delete it
> > from your system and notify the sender by return
> > email.
> > _______________________________________________
> > WikiEN-l mailing list
> > WikiEN-l at Wikipedia.org
> > http://mail.wikipedia.org/mailman/listinfo/wikien-l
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Henning Heitkötter

subject: [Wikitech-l] No Webalizer stats since September 27

body:
Apparently, Webalizer stopped working at September 27. Additionally,
stats for September 24-26 seem to be comparatively low.

Please, could anyone look after it [and fix it ;-)], as they are really
useful and interesting? (For example: compare John Kerry and George W.
Bush in September-stats  (
http://wikimedia.org/stats/en.wikipedia.org/usage_200409.html ) )

Thanks,

Henning
--[[de:Benutzer:HenHei]]


from_name: Timwi

subject: [Wikitech-l] Re: Test my lex/yacc parser!

references:
<cigum2$i19$1@sea.gmane.org>	<9f02ca4c04091910144fb9fc68@mail.gmail.com>	<cil3do$mpb$1@sea.gmane.org>	<9f02ca4c04092005563f022703@mail.gmail.com>	<cimtnk$o3c$1@sea.gmane.org>	<9f02ca4c04092310162250f65a@mail.gmail.com>	<civ3io$4ph$1@sea.gmane.org>	<9f02ca4c0409231636191ed0ca@mail.gmail.com>	<cjf6cc$s39$1@sea.gmane.org>
	<9f02ca4c04092915215b4b9fb9@mail.gmail.com>

body:
Rowan Collins wrote:

> OTOH, the code *outside* the parser will have to, and more: if you
> want to avoid putting redirects through the parser at all, that code
> has to do the following:
> 1] spot that the page is a redirect
> 2] determine what it is a redirect to
> 3] find all the article's entries in the links tables (links,
> brokenlinks, categorylinks) and delete all those except the target of
> the redirect.
> 1 has to be done one way or another anyway; 2 and 3 would be natural
> side-effects of parsing *any* page before save (unless I've completely
> misunderstood the current code structure, or you have some magic way
> of avoiding this), so why duplicate them in special case code just for
> redirects?

This was very enlightening and convincing. You're right. The parser
should parse redirects.

>>As I mentioned before, it is *not* necessary for anyone to "deal with"
>>anything. People can continue to use the old not-a-parser if they want!
>
> For how long? As new features come along, what are the chances that
> they will be back-ported to the not-a-parser?

You're talking as if you're regarding myself as some sort of
authoritative figure who determines the future direction of development.
Open source software doesn't work like that, and especially not MediaWiki.

If people need certain features or certain functionality, then they need
to make sure that they are programmed; if nobody volunteers to do it,
they need to do it themselves. I can't, won't, and should not be
required to, take any responsibility for the effects of my parser on
other system administrators. If people need new parser features
backported, then they need to do it themselves; whether or not this is
difficult should not and cannot be a criterion for the direction of the
development of my parser.

In the hypothetical scenario you are describing, i.e. the old
not-a-parser becoming completely obsolete and outdated, administrators
will either have to use the new parser or enhance the old parser for
themselves. This is their problem and their decision, not mine.

> BTW, did anyone ever find a compiler-compiler that could output PHP?

Myself, I haven't even looked. However, I had already retracted my
original hypothesis that porting a C-based yacc/bison file to PHP would
be easy. I have done quite some C-specific programming here (see
parsetree.c), which can certainly be translated to PHP, but not trivially.

Greetings,
Timwi


body:
Kate Turner wrote:

>>Why aren't these things discussed on-list or on meta:?
>
> Is there a problem with the change that needs to be discussed?

I think people are trying to say that you should ask that question
before you actually make the change.

Myself, I have no idea what change you are making, but a change to the
'old' table is going to incur downtime on wikis as large as the
English-language Wikipedia. Seeing as we were going to redesign the
entire database for 1.5, I don't see the point in doing that.

Timwi


body:
Erik Moeller wrote:

> Brion-
>
>>A possible alternative which has been brought up before is to avoid
>>changing the structure of the old table, rather pullings its
>>non-textual data out to a separate table and continuing to use the old
>>table (unaltered) as a store for old_text. This avoids copying around
>>the most data and should in theory be faster.
>
> How about doing a quick hack now instead, such as adding a "sysop_move"
> flag to cur_restrictions which would then make certain pages only be
> movable by sysops? This until we do a proper database redesign, where we
> would then convert the existing DB into the new schema in one well-
> coordinated step, with associated downtime.

Personally, I'd prefer a transition without downtime such as the one I
proposed before, but nobody seemed interested enough to discuss it.


from_name: Paginazero

subject: [Wikitech-l] Wikimedia + WikiTeX ?

body:
Hi. I'm Paginazero, an Italian user/contributor to it.wiki.

As most of my contributions are related to the chemistry, I'm eagerly waiting
to have the WikiTeX functions included in MediaWiki - that would be a great
help to avoid image uploading and to define a common standard for writing
chemical formulae and reaction schemes.
I'm so impatient that I already began to prepare a tutorial for the Italian
users!

Looking forward to getting rid of ASCII-art formulae, I thank you all for your
kind attention. If I can be of any help, let me know.

G.


from_name: Jimmy O'Regan

body:
Jens Ropers wrote:
> On 1 Oct 2004, at 11:57, Ray Saintonge wrote:
>
>> Indian English must have a lakh of interesting variations
>
>
> Indian English... A LAKH OF...
>
> ;-D  ;-)  :-P
>
> To the above observation of INDIAN English I add the following:
>
> BRITISH: My dear old chap, British English probably has an indeed
> substantial amount of interesting variations.
> IRISH: For f*cks sake, Irish English must have a bunch of interesting
> variations -- and all that Mullarkey.

No, no, no.

"For feck sake, Irish English is all over the shop -- and all that shite."


from_name: Mark Richards

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

body:
The trouble with VFU is that only admins can even see
what was deleted. The process is proundly un wiki.
Mark

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

> Listing on VfD is not equivalent to deletion.
>
> My experience is that very few if any articles are
> ever deleted
> through VfD that should not be.  Those cases and
> most borderline ones
> then have the option of VfU.
>
> VfD is really about trying to get the community
> opinion about an
> article's inclusion.  Options other than straight
> keep or straight
> delete are often used too -- in this case, merging
> into one article.
>
> -Matt
>
>
> On Thu, 30 Sep 2004 20:17:13 -0700 (PDT), Mark
> Richards
> <marich712000 at yahoo.com> wrote:
> > This highlights to problem of deletion. In the
> case
> > you are talking about, someone should very much
> have
> > boldly edited this as redirects. If this had
> happened
> > to be wrong, people would have seen it, and it
> could
> > have been put right through wiki process.
> >
> > Deletion is a totally different beast, it removes
> the
> > information, and, for most users, even the
> evidence
> > that it was ever there, removing the possibility
> of
> > process to improve the information.
> >
> > Mark
> >
> >
> >
> > --- "Carson, David" <DCarson at nine.com.au> wrote:
> >
> > > Ed Poor wrote:
> > > > If there are a dozen or 6 dozen separate, tiny
> > > articles with a common
> > > > theme, then why not:
> > > >
> > > > * Copy the text of each article into one new
> > > comprehensive article
> > > (like
> > > > [[List of Apprentice contestants]]
> > > > * Turn the text of each old article into:
> > > #REDIRECT [[List of
> > > > Apprentice contestants]]
> > > >
> > > > This is how Maveric asked me to handle the
> > > Simpsons, way back when...
> > >
> > > That's what I voted for, and indeed, that was
> the
> > > overwhelming consensus
> > > of the VFD vote, and is what has been done.
> > >
> > > And indeed, that could have been boldly done by
> > > someone without needing
> > > a VFD vote. But I would say that (a) there would
> > > have been a guaranteed
> > > edit war following it; and (b) there WAS a
> definite
> > > minority opinion
> > > that these people didn't deserve to be in the
> > > Wikipedia AT ALL, being
> > > merely "game show contestants".
> > >
> > > Me, I see the whole affair as further proof that
> VFD
> > > is not at all
> > > broken, and continues to excellently serve the
> > > community.
> > >
> > > Cheers!
> > > David...
> > >
> > >
> > >
> >
>
_____________________________________________________________________________________________________
> > > This email and its attachments are for the sole
> use
> > > of the addressee and may contain information
> which
> > > is confidential and/or
> > > legally privileged. This email and its
> attachments
> > > are subject to copyright and should not be
> partly or
> > > wholly reproduced without
> > > the consent of the copyright owner. Any
> unauthorised
> > > use of disclosure of this email or its
> attachments
> > > is prohibited. If you receive
> > > this email in error, please immediately delete
> it
> > > from your system and notify the sender by return
> > > email.
> > > _______________________________________________
> > > WikiEN-l mailing list
> > > WikiEN-l at Wikipedia.org
> > >
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around
> > http://mail.yahoo.com
> >
> >
> > _______________________________________________
> > WikiEN-l mailing list
> > WikiEN-l at Wikipedia.org
> >
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
> >
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

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


body:
On 1 Oct 2004, at 11:57, Ray Saintonge wrote:

> Indian English must have a lakh of interesting variations

Indian English... A LAKH OF...

;-D  ;-)  :-P

To the above observation of INDIAN English I add the following:

BRITISH: My dear old chap, British English probably has an indeed
substantial amount of interesting variations.
IRISH: For f*cks sake, Irish English must have a bunch of interesting
variations -- and all that Mullarkey.
AMERICAN: Yeah man, American English has, like, a gazillion of
interesting variations, oh boy.
AUSTRALIAN: Crikey! Australian English has a rweal loarge amount of
interesting variations!

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


body:
PS: To all non-native speakers: The joke here is that the term "lakh"
originated in India. Hah, the joys of etymology!
Hey, waitaminute!
I'm a non-native speaker, actually! 96% verbal SAT percentile, but '''I
ASSURE YOU''' I am a non-native speaker.
Hm. Whatever. Go figure.
</braggadocio>

On 1 Oct 2004, at 16:18, Jens Ropers wrote:

> On 1 Oct 2004, at 11:57, Ray Saintonge wrote:
>
>> Indian English must have a lakh of interesting variations
>
> Indian English... A LAKH OF...
>
> ;-D  ;-)  :-P
>
> To the above observation of INDIAN English I add the following:
>
> BRITISH: My dear old chap, British English probably has an indeed
> substantial amount of interesting variations.
> IRISH: For f*cks sake, Irish English must have a bunch of interesting
> variations -- and all that Mullarkey.
> AMERICAN: Yeah man, American English has, like, a gazillion of
> interesting variations, oh boy.
> AUSTRALIAN: Crikey! Australian English has a rweal loarge amount of
> interesting variations!
>
> -- ropers [[en:User:Ropers]]
>     www.ropersonline.com
>


subject:
[Wikitech-l] Re: The difficulty of collaborative design in a
	volunteer enviornment

body:
Tim Starling wrote:

> In my experience, volunteer developers don't like being told what to do.

I half-disagree.

In my experience, volunteer developers are discouraged when being told
to do something that is difficult, or something they are not
particularly interested in.

However, I think being asked to do something can be an extremely
efficient motivator, if the developer that is being asked personally
feels there is potential for success (i.e. if they're interested, if
it's easy to do, etc.). If you're asked to do something, then you know
that once you've finished it someone will appreciate your work.

I'm saying this because on LiveJournal developers used to be very
motivated and encouraged even though they've always been told what to do
(not just by Brad, but also by fellow volunteers attempting to represent
Brad's interets). Fixing bugs or writing smallish features in
LiveJournal was easy because their software is well organised, modular,
structured, and easy to get into. LiveJournal volunteer development has
come to a halt not because people were told what to do, but exactly
because they are no longer told: instead, suggestions and even finished
patches are ignored and left uncommented-on, developers feel
unappreciated, become frustrated and leave.

According to this, being told what to do is discouraging on MediaWiki
only because there are few things that are easy or interesting.

> Part of the fun of coding comes from creative expression -- the joy that
> comes from having an idea, and carrying it through until you see it
> realised. By publishing plans, you destroy that motivation for anyone
> else who had the same idea, or might have had it in the future.

I don't think like that. Some people might, but I don't.

Yes, part of the fun of coding comes from creative expression -- but for
some people, it might not be the biggest part. For some people, I'm sure
the biggest part is the social recognition that results from success
(being able to say "I made this!" and hearing other people reply "Well
done!").

Both personalities like to publish their plans because, like a finished
implementation, a plan is also (1) a form of creative expression, and
(2) something that can harvest social recognition ("Nice plan!" etc.).

On the contrary, if someone else publishes a plan, there are three
possible ways in which I can react. Either I think the plan is bad and I
think I can come up with something better; or I think the plan is good
and I might only have minor suggestions for improvement or perhaps not
even that; or there is something important about the plan that I don't
understand (e.g. why it's supposed to be better) or that I can't judge
(e.g. its advantages and disadvantages). Unfortunately, the third is the
most common; many very competent developers' weakest skill is
communication, and often a plan includes just the bare implementation
idea, not the information on why it's better and what its advantages are.

> What developers do when faced with this problem is they attempt to
> ignore all plans which have gone before. They invent their own, and fool
> themselves into thinking that their idea is truly creative and new. This
> allows them to regain the motivation that was lost.

No, I don't think I fool myself into thinking that my ideas are truly
creative and new, but I fool myself into thinking that my ideas are good
ones. I explicitly do not pass judgment over plans I read that fall into
the third category above, but subconciously it feels like the ideas I
understand best (which, inevitably, are my own) are somehow better.

> This curious aspect of volunteer psychology makes collaborative design
> very difficult. Fortunately there is an alternative which allows us to
> avoid the most obvious planning mistakes, and that is by the use of an
> oracle. It works like this.  [...]

Your idea would essentially create a hierarchy. Those that you call
"senior developers" would be regarded as having a superior social
status, and would seem like they have more say in the development of the
software.

This isn't necessarily bad with regard to the software; every largish
project needs some management and guidance. But whether this is good in
the social sense, I'm not sure.

> In our project, this role of oracle is filled by Brion, and I'd like to
> think to a lesser extent myself.

Unfortunately, that's not very many people. I have continuous trouble
contacting either of you for a conversation. I would have been more than
happy to discuss my database schema redesign ideas (or any other ideas,
for that matter) with you (or anyone, for that matter), but it never
works out. You're either too busy, or have to leave too soon, or you're
simply not interested enough. I am not trying to point fingers here;
don't get me wrong. This isn't a complaint. This is just where your
oracle idea is slightly flawed. We either need more of those oracle
people (which defeats the purpose of your idea, because then within the
oracle group you have the same issues again), or we need an oracle
member that is very much dedicated to listening to and evaluating plans
and ideas, and not occupying themselves too much with coding. Such a
person is unlikely to be found.

Greetings,
Timwi


subject: [Wikitech-l] Re: Membership and payment

body:
Anthere wrote:

> Roughly, the goal is
> * to add to preferences a mention of default joining the foundation when
>  creating an account, and adding a link to an opt-out option
> * set a form to join as a contributing member. The paiement itself
> should be multilingual, include several different amounts, and allow the
> person to enter a preference for use of part of the fee. Generate a tax
> receipt for us contributors (desactivated for now).
> * Find a solution to add as contributing members, editors who paid fees
> in a local chapter.
> * store all data about the member as "confidential" data (another db or
> encryption). Make it available automatically for voting.
> * Generate an access and interface of some sort, so that someone can
> consult/manage the list of members.

No offense to you, Anthere, but I don't understand any of this. Quite
frankly, this is quite poor English, which for me (as a non-native
speaker) is impossible to parse. I understand the task is to add an
option in the preferences. That's all I can figure out. What is the
option supposed to do?

Sorry :/
Timwi


subject: [Wikitech-l] Re: Nauruose

body:
Gerard Meijssen wrote:

> Some time ago I wrote to this list that the local word for Nauruan
> should be Nauruose, the source I quoted was the Nauruan wikipedia.
> Consequently it was changed  for use with interwikis. However, it has
> transpired that the Nauruan wikipedia has been squated. Nobody knows
> what language the content is in. I am afraid that Nauruose is propably
> wrong.

Indeed, a Google search for "Nauruose" returns only Wikimedia-related
results.


subject: [Wikitech-l] Re: Nauruose

body:
Gerard Meijssen wrote:

> Some time ago I wrote to this list that the local word for Nauruan
> should be Nauruose, the source I quoted was the Nauruan wikipedia.
> Consequently it was changed  for use with interwikis. However, it has
> transpired that the Nauruan wikipedia has been squated. Nobody knows
> what language the content is in. I am afraid that Nauruose is propably
> wrong.

A quick Google search indicates that Nauruan in Nauruan is Nauri.

Timwi


body:
Mark, +sj+,

Thanks for your emails.

So do you think that there's gotta be another vote? (I was hoping that
could be avoided but anyway.)
Are you User:Mark and User:Sj, respectively? i.e. are you WP
administrators?
If so, could you possibly go in and open that new poll, saying that I
asked for admin help? I'm not trying to be a lazy b*gger, it's just
that I'm concerned that my credibility on this occasion has probably
been eroded too much for me to do it myself -- as the most recent
comment by "anthony (see warning)" illustrates.

I'd be really grateful if you could assist.

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

On 1 Oct 2004, at 08:00, Sj wrote:

> That sounds right to me also.
> Jens, perhaps a simple poll asking about 3 months?
> That should pass most easily, and deal with 95% of the
> problem cases.
>
> +sj+
>
> On Thu, 30 Sep 2004 20:14:29 -0700 (PDT), Mark Richards
> <marich712000 at yahoo.com> wrote:
>> I have followed this a little, and it seems that there
>> is a concensus that a reasonable amount of time should
>> pass between relisting of the same article. 3-6 months
>> seems reasonable to me, I think another poll proposing
>> this would pass easily.
>> Mark
>>
>> --- Jens Ropers <ropers at ropersonline.com> wrote:
>>
>>> This poll on an amendment to the deletion policy:
>>>>> http://en.wikipedia.org/wiki/Wikipedia_talk:
>>>>>
>>>
>> Deletion_policy#Proposed_new_rule:_No_repeat_submission_of_articles
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


body:
On 1 Oct 2004, at 16:30, Jimmy O'Regan wrote:

> Jens Ropers wrote:
>> On 1 Oct 2004, at 11:57, Ray Saintonge wrote:
>>> Indian English must have a lakh of interesting variations
>> Indian English... A LAKH OF...
>> ;-D  ;-)  :-P
>> To the above observation of INDIAN English I add the following:
>> BRITISH: My dear old chap, British English probably has an indeed
>> substantial amount of interesting variations.
>> IRISH: For f*cks sake, Irish English must have a bunch of interesting
>> variations -- and all that Mullarkey.
>
> No, no, no.
>
> "For feck sake, Irish English is all over the shop -- and all that
> shite."

Jimmy, you wouldn't possibly be a Dublin lad, would you? Or knew a few
Wikipedians from "the capital"?
Because "the nation needs your help".

Please visit
>> http://en.wikipedia.org/wiki/Wikipedia:
>> Irish_wikipedians%27_notice_board
and read the note headed "ATTENTION".
Then please help getting as many Dublin-based Wikipedians as possible
to head over to
>> http://meta.wikimedia.org/wiki/Wikimedia_meetup_2005#Dublin.2C_Ireland
and sign up as potential Dublin helpers.

Thanks a million!

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


from_name: Stephen Brandwood

body:
I was suprised not to see anything about this on the Meta Wiki, as it
seems like a common practice to use on some Wikis. I am in a situation
where i have a small Wiki and am the only Sysop. I really don't want to
have to be checking every edit just in case it's vandalism. So far they
have all been by unregistered users and whilst they may not have been
destructive, they are generally annoying. Is there anyway i can only let
registered users edit pages? I'm not so much bothered about people
adding new pages, as they still need to be added to a menu somewhere to
be really useful.

Thanks for any help
-Steve


subject: [Wikitech-l] Re: Membership and payment

body:
On 1 Oct 2004, at 16:39, Timwi wrote:

> Anthere wrote:
>
>> Roughly, the goal is
>> * to add to preferences a mention of default joining the foundation
>> when  creating an account, and adding a link to an opt-out option
He wants to add and option (possibly a tickbox) to the account creation
page, allowing the person creating an account to automatically join the
Wikimedia Foundation as well.
>> * set a form to join as a contributing member.
He wants that there be an optionally accessible form allowing people to
sign up as a contributing member of the Wikimedia Foundation right at
account signup.
>> The paiement itself should be multilingual, include several different
>> amounts, and allow the person to enter a preference for use of part
>> of the fee.
Not sure if I understand him correctly on this one, but he probably
wants to offer people who sign up as contributing members different
amounts of recurring contribution/member fees.
>> Generate a tax receipt for us contributors (desactivated for now).
He wants an option to get tax receipts for the contributions (which
would remain deactivated until the Wikimedia Foundation is fully
accredited as tax exempt in all of the U.S. (and thus, by merit of
international treaties, abroad as well).
>> * Find a solution to add as contributing members, editors who paid
>> fees in a local chapter.
He wants to allow people who already pay membership fees/recurring
contributions to local chapters of the Wikimedia Foundation to get
registered with the Wikimedia Foundation proper as contributing members
without paying twice -- they'd continue to pay the local chapter but
would hold equal standing as people who hold their membership directly
with the Wikimedia Foundation.
>> * store all data about the member as "confidential" data (another db
>> or encryption).
He wants to have all pertaining personal data securely stored in
another database or encrypted in the same database.
>> Make it available automatically for voting.
He wants mechanisms that would allow Wikimedia Foundation members to
seamlessly participate in Foundation elections, possibly w/o having to
log in separately.
>> * Generate an access and interface of some sort, so that someone can
>> consult/manage the list of members.
He wants to allow for the list of Wikimedia Foundation members to be
retrievable and manageable via an appropriate interface to the database
holding that list.
>
> No offense to you, Anthere, but I don't understand any of this. Quite
> frankly, this is quite poor English, which for me (as a non-native
> speaker) is impossible to parse. I understand the task is to add an
> option in the preferences. That's all I can figure out. What is the
> option supposed to do?
>
> Sorry :/
> Timwi
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


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

body:
This is one of the drawbacks I considered: the increased amount of
conflicting edits. However, the 'partially' invisible edits would not
really meet our needs as it would allow any given user to view
unapproved content submitted by any other given user. The
administration seems to be rather insistent  that this should not
happen in any way. It will increase the burden on the approvers, to
resolve edit conflicts, but I think that is probably a price they will
have to pay for retaining such strong control over the wiki. I
wouldn't think that it would be that hard to merge then via the
already existing code for merging edits.

-Randy

On Fri, 1 Oct 2004 18:57:54 +0100, Rowan Collins
<rowan.collins at gmail.com> wrote:
> On Fri, 1 Oct 2004 06:36:38 -0500, Randy Becker <lemnar at gmail.com> wrote:
> > This is part of the reason I'm swaying away from the current course
> > I've taken, and towards a cleaner approach, but I will bring up the
> > "stable time" to see if it's an acceptable solution. Also, part of the
> > problem with this is how does it reach a stable point, as *all*
> > evidence of an edit by a user should not be evident from the wiki,
> > except to sysops or the like. (editing should display the previously
> > approved entry, and only approved entries should appear in the history
> > etc.) Because of all of this, I'm thinking of trying to implement a
> > kind of queue of edits, which would bee looked at, and then approved
> > or rejected, and if rejected, just dropped, if approved, added as if
> > the user which submitted them had added them themselves.
>
> The only drawback to this kind of "invisible queue" is that you might
> get the same edit submitted multiple times, because it hadn't been
> approved yet. Also (and potentially even more annoying) you might get
> edits that cause edit conflicts even though they happened hours apart,
> e.g.:
> Current text: "This s a senntence"
> Alice edits this to: "This is a senntence"
> Later, Bob edits it to: "This s a sentence"
> Carol the admin pops these from the approval queue, and the software
> goes "whoops". No different from a current edit conflict, but
> potentially a lot more common.
>
> The only way I see round this is to only make the queued edits
> *partially* invisible: a user asking to edit the page sees a message
> saying "the following edits have already been submitted for approval"
> with either a whole load of diffs, or a set of links to diffs
> (labelled with the edit summary, perhaps). Then they can choose to
> build on one of those to create their own version.
>
> --
> Rowan Collins BSc
> [IMSoP]
>
>


subject: [Wikitech-l] Re: Nauruose

body:
The wikisquatter likely suffers from Nauruose neurosis.

On 1 Oct 2004, at 16:56, Timwi wrote:

> Gerard Meijssen wrote:
>
>> Some time ago I wrote to this list that the local word for Nauruan
>> should be Nauruose, the source I quoted was the Nauruan wikipedia.
>> Consequently it was changed  for use with interwikis. However, it has
>> transpired that the Nauruan wikipedia has been squated. Nobody knows
>> what language the content is in. I am afraid that Nauruose is
>> propably wrong.
>
> A quick Google search indicates that Nauruan in Nauruan is Nauri.
>
> Timwi
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


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

body:
That would be better, but it still denies future
generations of Wikipedian the right to edit and
improve. There are a few circumstances where legal,
ethical reasons or simple nonsense compel deletion,
but blanking, redirecting or refactoring is almost
always better.
Mark

--- David Carson <david at hemiware.com> wrote:

> Mark Richards wrote:
>
> >The trouble with VFU is that only admins can even
> see
> >what was deleted. The process is proundly un wiki.
> >
> >
>
> Perhaps it would be helpful if listings on VFU were
> accompanied by an
> admin copying the deleted article to a temporary
> subpage a.s.a.p. ?
>
> Cheers!
> David...
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com


from_name: Guillaume Blanchard

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

body:
I proposed something similar some weeks ago, WikiForum.
Here is the idea:
- New thread is created into "thread:" namespace then anybody can edit
it like all other pages.
- Each time a thread file is edited a forum page is rebuild according to
last modified thread.
- The X lasted threads are fully included into forum page (like templates).
- The Y next threads are included into a table showing some information
(title, date of last modification, last modifier, etc.)
- All is full Mediawiki compatible (same syntax, same user account, etc.).
In fact the idea aimed on create an auto?cleaning village pump (=the
forum) but I think we can enhance it to provide RSS/ATOM feed and so on.
I created a prototype that some wikipedians tried, but I didn't carry on
the development.
If someone is interest in sharing experience and go on this idea or
something similar, contact me.

Aoineko


from_name: Ashar Voultoiz

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

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

I just commited the Userlevels interface that allow sysops to add/edit
groups and change group memberships of any users.

* Forms posted aren't checked !!
* The "group" class looks like the "user" one.
* Postgresql untested.
* Various bugs.

--
Ashar Voultoiz


from_name: Vít Zvánovec

subject: [Wikitech-l] Please, delete :cs:Wikipedie:Co je článek

body:
This can be done only by devolopers:

:cs:Wikipedie:Co je ?l?nek
(http://cs.wikipedia.org/wiki/Wikipedie:Co_je_%C4%8Dl%C3%A1nek) is in
a bad namespace, that's why it cannot be deleted normally. (You can
click on it in http://cs.wikipedia.org/wiki/Special:Lonelypages) It
claims, it has 138 bytes.
(http://cs.wikipedia.org/wiki/Special:Shortpages) Can you please
delete it?

How can be deleted a file with no name - see
http://cs.wikipedia.org/wiki/Special:Unusedimages, for a file: . .
08:23, 14. 9. 2004 . . Beny

					V?t Zv?novec, sysop of cs:


from_name: Randy Becker

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

body:
That's not a problem at all. That would be one of the reasons I'm
personally a fan of open source: that if *I* want a feature, then I
can add it myself, even if I'm the only person in the world who wants
it.

I'm mainly just looking for ideas or suggestions on implementation,
and to let it be known that I'm going to be attempting this, and if
anyone wants to help, all the better, or if not that's perfectly fine
too. I just figured that in the interest of not wasting effort on the
possibility of someone else being interested, or to get an idea of how
best to go about this, and for more experienced people to give some
advice as to potential pitfalls etc. it would be a good idea to post
this here.

All this being said, I do think that a wiki, and particularly
MediaWiki, (Which I've come to *really* like in many many ways) is the
best tool for the job, and unfortunately the political situation I'm
in won't allow for MediaWiki as it exists today, even though I think
it would be the best solution, it is just a bit too radical for our
organization. I would *love* to implement it as a standard install,
but it just isn't going to happen that way, and rather than not happen
at all, I'd like to at least make use of some of the advantages a
similar environment could provide.

-Randy

On Sat, 2 Oct 2004 00:33:31 +0200, Jens Ropers <ropers at ropersonline.com> wrote:
> What I'm going to say is purely my personal opinion and I've never
> contributed a single line of code to MediaWiki:
>
> Given your below email, I wonder if you might not be better off looking
> at other solutions instead of MediaWiki.
> Yes, MediaWiki is very powerful and we like it A LOT. But it is mostly
> built for a defined job, and it just isn't a Content Management System
> (CMS) -- see:
> >> http://meta.wikimedia.org/wiki/Wiki_Uses#What_is_MediaWiki_-_not.3F
> Yes, all the features you are looking for may (or may not) be
> forthcoming sooner or later, but if I were you I wouldn't hold my
> breath. Again, MediaWiki is built mostly with Wikipedia-alike wikis in
> mind, and I dare say primarily built for Wikipedia. If others can use
> MediaWiki, hey, that's great! If others have good ideas that they can
> code and contribute to MediaWiki, that's even better! But if you were
> to ask our developers to code some feature that we don't have and don't
> need yet (because there isn't consensus yet on what Wikipedia's
> approval mechanism needs are), if you were to ask people to code a
> feature just because you could use it for your installation, then you'd
> probably find yourself sorely disappointed by the response. (And I'm
> not saying that you'd actually asked thus yet -- you haven't.)
>
> Again, if you can code and contribute a feature or even you're more
> than welcome.
> Feature suggestions are welcome too, but-- I guess what I'm saying is
> that there are no guarantees in that area.
>
> There are a lot of Open Source CMSs out there -- a cursory glance
> returned these:
> http://www.mamboserver.com/
> http://typo3.com/
> http://plone.org/
> There also are truckloads of other Wiki software projects, some of
> which may include the features you are looking for. Google for them.
>
> Then again, I am not speaking for others on this list and I may be
> wrong.
>
> -- ropers [[en:User:Ropers]]
>      www.ropersonline.com
>
>
>
> On 1 Oct 2004, at 13:36, Randy Becker wrote:
>
> > As to restricting new accounts: This is what we have already done, but
> > it still is not enough, as there are only 1-2 people with the
> > authority and common sense to dictate what is and is not appropriate
> > and fitting material for the wiki. In addition, the wide collaborative
> > structure is seen as very much a benefit, owing to the large group of
> > people (faculty, staff, students, alumni) who would have an interest
> > in contributing. Thus, we wish to allow anonymous editing etc. In
> > short, too many people need access to easy editing to restrict our
> > user group so much.
> >
> > As to a "stable" time: Yes, we really want to not limit access as much
> > as possible, to encourage widespread contribution. On the "stable"
> > time, this is actually where I am currently headed with my
> > modifications based on the patrolled flag, and it is only present in
> > the recent changes table, and that table is cleared after a certain
> > amount of time, of a certain number of edits, I believe. This would
> > cause whatever was in cur to be displayed.
> >
> > This is part of the reason I'm swaying away from the current course
> > I've taken, and towards a cleaner approach, but I will bring up the
> > "stable time" to see if it's an acceptable solution. Also, part of the
> > problem with this is how does it reach a stable point, as *all*
> > evidence of an edit by a user should not be evident from the wiki,
> > except to sysops or the like. (editing should display the previously
> > approved entry, and only approved entries should appear in the history
> > etc.) Because of all of this, I'm thinking of trying to implement a
> > kind of queue of edits, which would bee looked at, and then approved
> > or rejected, and if rejected, just dropped, if approved, added as if
> > the user which submitted them had added them themselves.
> >
> >
> > -Randy
> >
> >
> > On Fri, 1 Oct 2004 01:26:35 -0700 (PDT),
> > leercontainer-wikimedia at yahoo.com <leercontainer-wikimedia at yahoo.com>
> > wrote:
> >> As far as I understood this message, you are not looking for a way of
> >> limiting access and edits, merely a way of approving edits.
> >>
> >> I have seen a feature that I think would be usable for you on a
> >> MediaWiki roadmap some time ago. It was supposed to be an alternative
> >> to protecting pages that is already implemented in some other wiki
> >> software.
> >>
> >> What the feature did was that you could specify a time period that a
> >> page had to be "stable" before edits to a page were "activated", and
> >> thereby presented to the readers. Lets say this period was set to 7
> >> days "the approvers" would have 7 days to discover and fix any
> >> maliscious edits before they were presented to the readers of the
> >> website.
> >>
> >> I don't know what wiki software has this feature, or if it still is on
> >> some roadmap, but I myself find it a very neat feature, and with the
> >> new database scheme it should't be too hard to implement in MediaWiki
> >> either I'm guessing.
> >>
> >> --Dittaeva
> >>
> >>
> >>
> >> --- Randy Becker <lemnar at gmail.com> wrote:
> >>
> >>> I'm a high school student involved in our website
> >>> (http://www.rileyhighschool.com/). After taking a look at the sorry
> >>> state of our site, and subsequently visiting wikipedia, I came to the
> >>> realization that a wiki, especially mediawiki, would be enormously
> >>> beneficial to our site in many ways. I investigated further,
> >>> installed
> >>> 1.3, got some content in, customized monobook a little bit, got
> >>> familiar with the software. I decided that it really would be a great
> >>> improvement, and continued further testing. Upon further review, and
> >>> in conversation with the administration, it was determined that the
> >>> principal objection to using mediawiki as our primary site was that
> >>> anyone could edit. Although it has been presented that this is not a
> >>> serious problem in practice, it was still too much of a risk for them
> >>> to take. Downtrodden, but not discouraged, knowing that mediawiki is
> >>> an open source product, and being familiar with php and mysql, I
> >>> looked further into what was available. Ultimately, it was determined
> >>> that unapproved edits cannot come to exist in the first place,
> >>> irregardless of the ease of their removal. I began looking for a way
> >>> to implement an approval mechanism.
> >>>
> >>> On #mediawiki it was suggested that I look into the recent changes
> >>> patrolling in 1.4 as a potential method of implementing this
> >>> solution.
> >>> I have done this and determined that it will be just as difficult to
> >>> use this as it will be to implement a cleaner solution, involving a
> >>> new table in the database and an approval mechanism. Therefore, I'm
> >>> here to ask for suggestions, comments, and help implementing this, or
> >>> a similarly acceptable solution.
> >>>
> >>> -Randy
> >>
> >>
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l at wikimedia.org
> > http://mail.wikipedia.org/mailman/listinfo/wikitech-l
> >
>
>


from_name: Jens Ropers

subject: [Wikitech-l] shell accounts

body:
Sounds like a plan.

IN ADDITION to this, if we're mad on redundancy, we also ''could''
consider splitting the cluster into two clusters, with round robin DNS
spreading the traffic load between these clusters -- that way, if one
entire cluster were to fall over, the Wikipedia would still work.
HOWEVER:
* I'm not sure how likely it is that an entire cluster falls over.
* This would create absolutely MENTAL replication traffic.
(Okay, maybe that's not such a good idea then. Anyway.)

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

On 1 Oct 2004, at 18:06, Jimmy (Jimbo) Wales wrote:

> I'm a little confused on the process whereby we make decisions about
> shell access.  I'm thinking right now primarily of access for a couple
> of people from the German e.V. to work on their website, which doesn't
> yet exist, rather than thinking of shell access to the main cluster.
>
> Related to this, it seems sensible to me that we should buy a special
> server to host things that we want to be separate, like for example
> the donation pages, so that if wikipedia is blown up for some reason,
> people can still donate money.  This would also permit us to give
> shell accounts more freely to people with a specific need on some
> auxiliary website.
>
> --Jimbo
>
> --
> "La n??fle est un fruit." - first words of 50,000th article on
> fr.wikipedia.org
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


from_name: Rowan Collins

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

body:
On Fri, 1 Oct 2004 06:36:38 -0500, Randy Becker <lemnar at gmail.com> wrote:
> This is part of the reason I'm swaying away from the current course
> I've taken, and towards a cleaner approach, but I will bring up the
> "stable time" to see if it's an acceptable solution. Also, part of the
> problem with this is how does it reach a stable point, as *all*
> evidence of an edit by a user should not be evident from the wiki,
> except to sysops or the like. (editing should display the previously
> approved entry, and only approved entries should appear in the history
> etc.) Because of all of this, I'm thinking of trying to implement a
> kind of queue of edits, which would bee looked at, and then approved
> or rejected, and if rejected, just dropped, if approved, added as if
> the user which submitted them had added them themselves.

The only drawback to this kind of "invisible queue" is that you might
get the same edit submitted multiple times, because it hadn't been
approved yet. Also (and potentially even more annoying) you might get
edits that cause edit conflicts even though they happened hours apart,
e.g.:
Current text: "This s a senntence"
Alice edits this to: "This is a senntence"
Later, Bob edits it to: "This s a sentence"
Carol the admin pops these from the approval queue, and the software
goes "whoops". No different from a current edit conflict, but
potentially a lot more common.

The only way I see round this is to only make the queued edits
*partially* invisible: a user asking to edit the page sees a message
saying "the following edits have already been submitted for approval"
with either a whole load of diffs, or a set of links to diffs
(labelled with the edit summary, perhaps). Then they can choose to
build on one of those to create their own version.

--
Rowan Collins BSc
[IMSoP]


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

body:
Which is what is almost always done.  Very few articles are actually deleted.

-Matt

On Fri, 1 Oct 2004 17:35:32 -0700 (PDT), Mark Richards
<marich712000 at yahoo.com> wrote:
> That would be better, but it still denies future
> generations of Wikipedian the right to edit and
> improve. There are a few circumstances where legal,
> ethical reasons or simple nonsense compel deletion,
> but blanking, redirecting or refactoring is almost
> always better.
> Mark
>
>
>
> --- David Carson <david at hemiware.com> wrote:
>
> > Mark Richards wrote:
> >
> > >The trouble with VFU is that only admins can even
> > see
> > >what was deleted. The process is proundly un wiki.
> > >
> > >
> >
> > Perhaps it would be helpful if listings on VFU were
> > accompanied by an
> > admin copying the deleted article to a temporary
> > subpage a.s.a.p. ?
> >
> > Cheers!
> > David...
> >
> >
> > _______________________________________________
> > WikiEN-l mailing list
> > WikiEN-l at Wikipedia.org
> > http://mail.wikipedia.org/mailman/listinfo/wikien-l
> >
>
>
> _______________________________
> Do you Yahoo!?
> Declare Yourself - Register online to vote today!
> http://vote.yahoo.com
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


list: foundation-l

from_name: Daniel Mayer

subject: [Foundation-l] Re: [WikiEN-l] Wikipedia spanks Encarta, Brockhaus

body:
--- Sj <2.718281828 at gmail.com> wrote on Wikipedia-l:
> Brockhaus "must concede defeat" to Wikipedia
> ....
> The net result: Wikipedia ran away with the top prize, a comfortable
> distance ahead of its stately predecessors.  "Brockhaus Premium
> surpassed the competition from Redmond," the review reported, "but
> must however concede defeat to Wikipedia".

Wow! That is totally awesome! Did they compare the English versions or German
versions of each encyclopedia (all the better if it were the German versions)?
Reading... Oh, it does look like they looked at the German version - sweet.

Two words: PRESS RELEASE!

Seriously, once the fund drive is over we should have a press release about
this and also mention the fact and result of our 'recent successful fund
drive.' We should also quote Jimbo when he said that commercial encyclopedias
will be out of business in 5 years if they keep doing as they have been.

> Happily, the full breakdown of the experts' ratings were published
> along with the article, so that each encyclopedia may benefit from the
> spot check.
>
> A full translation will be available on meta presently :
>  http://meta.wikimedia.org/wiki/Wikipedia vs Brockhaus and Encarta

Working URL: http://meta.wikimedia.org/wiki/Wikipedia_vs_Brockhaus_and_Encarta

Is the copyright cleared on that translation (since a translation is a
derivative work it is still covered by the original copyright)?

-- Daniel Mayer (aka mav)

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


subject: [WikiEN-l] Wikipedia spanks Encarta, Brockhaus


list: wikimedia-l


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

body:
What I'm going to say is purely my personal opinion and I've never
contributed a single line of code to MediaWiki:

Given your below email, I wonder if you might not be better off looking
at other solutions instead of MediaWiki.
Yes, MediaWiki is very powerful and we like it A LOT. But it is mostly
built for a defined job, and it just isn't a Content Management System
(CMS) -- see:
>> http://meta.wikimedia.org/wiki/Wiki_Uses#What_is_MediaWiki_-_not.3F
Yes, all the features you are looking for may (or may not) be
forthcoming sooner or later, but if I were you I wouldn't hold my
breath. Again, MediaWiki is built mostly with Wikipedia-alike wikis in
mind, and I dare say primarily built for Wikipedia. If others can use
MediaWiki, hey, that's great! If others have good ideas that they can
code and contribute to MediaWiki, that's even better! But if you were
to ask our developers to code some feature that we don't have and don't
need yet (because there isn't consensus yet on what Wikipedia's
approval mechanism needs are), if you were to ask people to code a
feature just because you could use it for your installation, then you'd
probably find yourself sorely disappointed by the response. (And I'm
not saying that you'd actually asked thus yet -- you haven't.)

Again, if you can code and contribute a feature or even you're more
than welcome.
Feature suggestions are welcome too, but-- I guess what I'm saying is
that there are no guarantees in that area.

There are a lot of Open Source CMSs out there -- a cursory glance
returned these:
http://www.mamboserver.com/
http://typo3.com/
http://plone.org/
There also are truckloads of other Wiki software projects, some of
which may include the features you are looking for. Google for them.

Then again, I am not speaking for others on this list and I may be
wrong.

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

On 1 Oct 2004, at 13:36, Randy Becker wrote:

> As to restricting new accounts: This is what we have already done, but
> it still is not enough, as there are only 1-2 people with the
> authority and common sense to dictate what is and is not appropriate
> and fitting material for the wiki. In addition, the wide collaborative
> structure is seen as very much a benefit, owing to the large group of
> people (faculty, staff, students, alumni) who would have an interest
> in contributing. Thus, we wish to allow anonymous editing etc. In
> short, too many people need access to easy editing to restrict our
> user group so much.
>
> As to a "stable" time: Yes, we really want to not limit access as much
> as possible, to encourage widespread contribution. On the "stable"
> time, this is actually where I am currently headed with my
> modifications based on the patrolled flag, and it is only present in
> the recent changes table, and that table is cleared after a certain
> amount of time, of a certain number of edits, I believe. This would
> cause whatever was in cur to be displayed.
>
> This is part of the reason I'm swaying away from the current course
> I've taken, and towards a cleaner approach, but I will bring up the
> "stable time" to see if it's an acceptable solution. Also, part of the
> problem with this is how does it reach a stable point, as *all*
> evidence of an edit by a user should not be evident from the wiki,
> except to sysops or the like. (editing should display the previously
> approved entry, and only approved entries should appear in the history
> etc.) Because of all of this, I'm thinking of trying to implement a
> kind of queue of edits, which would bee looked at, and then approved
> or rejected, and if rejected, just dropped, if approved, added as if
> the user which submitted them had added them themselves.
>
>
> -Randy
>
>
> On Fri, 1 Oct 2004 01:26:35 -0700 (PDT),
> leercontainer-wikimedia at yahoo.com <leercontainer-wikimedia at yahoo.com>
> wrote:
>> As far as I understood this message, you are not looking for a way of
>> limiting access and edits, merely a way of approving edits.
>>
>> I have seen a feature that I think would be usable for you on a
>> MediaWiki roadmap some time ago. It was supposed to be an alternative
>> to protecting pages that is already implemented in some other wiki
>> software.
>>
>> What the feature did was that you could specify a time period that a
>> page had to be "stable" before edits to a page were "activated", and
>> thereby presented to the readers. Lets say this period was set to 7
>> days "the approvers" would have 7 days to discover and fix any
>> maliscious edits before they were presented to the readers of the
>> website.
>>
>> I don't know what wiki software has this feature, or if it still is on
>> some roadmap, but I myself find it a very neat feature, and with the
>> new database scheme it should't be too hard to implement in MediaWiki
>> either I'm guessing.
>>
>> --Dittaeva
>>
>>
>>
>> --- Randy Becker <lemnar at gmail.com> wrote:
>>
>>> I'm a high school student involved in our website
>>> (http://www.rileyhighschool.com/). After taking a look at the sorry
>>> state of our site, and subsequently visiting wikipedia, I came to the
>>> realization that a wiki, especially mediawiki, would be enormously
>>> beneficial to our site in many ways. I investigated further,
>>> installed
>>> 1.3, got some content in, customized monobook a little bit, got
>>> familiar with the software. I decided that it really would be a great
>>> improvement, and continued further testing. Upon further review, and
>>> in conversation with the administration, it was determined that the
>>> principal objection to using mediawiki as our primary site was that
>>> anyone could edit. Although it has been presented that this is not a
>>> serious problem in practice, it was still too much of a risk for them
>>> to take. Downtrodden, but not discouraged, knowing that mediawiki is
>>> an open source product, and being familiar with php and mysql, I
>>> looked further into what was available. Ultimately, it was determined
>>> that unapproved edits cannot come to exist in the first place,
>>> irregardless of the ease of their removal. I began looking for a way
>>> to implement an approval mechanism.
>>>
>>> On #mediawiki it was suggested that I look into the recent changes
>>> patrolling in 1.4 as a potential method of implementing this
>>> solution.
>>> I have done this and determined that it will be just as difficult to
>>> use this as it will be to implement a cleaner solution, involving a
>>> new table in the database and an approval mechanism. Therefore, I'm
>>> here to ask for suggestions, comments, and help implementing this, or
>>> a similarly acceptable solution.
>>>
>>> -Randy
>>
>>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


body:
Begin forwarded message:

> From: Jens Ropers <ropers at ropersonline.com>
> Date: 1 October 2004 06:12:00 GMT+02:00
> To: Wikimedia developers <wikitech-l at wikimedia.org>, randy at lemnar.com
> Cc: Subject: Re: [Wikitech-l] RFC: Approved Edits Only
> Reply-To: Wikimedia developers <wikitech-l at wikimedia.org>
>
> 1. This should solve your problem:
>   http://meta.wikimedia.org/wiki/Preventing_Access
>   Simply prevent anonymous editing and prevent new registrations
> (otherwise any Internet surfer could just register themselves). Then
> appoint a person (or a number of persons) who will be responsible for
> manually creating accounts for anybody who you want to be able to
> edit. All of these measures are described on the meta page as per the
> above link.
>
> <snip>

On 1 Oct 2004, at 18:14, Stephen Brandwood wrote:

> I was suprised not to see anything about this on the Meta Wiki, as it
> seems like a common practice to use on some Wikis. I am in a situation
> where i have a small Wiki and am the only Sysop. I really don't want
> to have to be checking every edit just in case it's vandalism. So far
> they have all been by unregistered users and whilst they may not have
> been destructive, they are generally annoying. Is there anyway i can
> only let registered users edit pages? I'm not so much bothered about
> people adding new pages, as they still need to be added to a menu
> somewhere to be really useful.
>
> Thanks for any help
> -Steve
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>


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

body:
On Fri, 1 Oct 2004 17:25:09 -0500, Randy Becker <lemnar at gmail.com> wrote:
> This is one of the drawbacks I considered: the increased amount of
> conflicting edits. However, the 'partially' invisible edits would not
> really meet our needs as it would allow any given user to view
> unapproved content submitted by any other given user. The
> administration seems to be rather insistent  that this should not
> happen in any way. It will increase the burden on the approvers, to
> resolve edit conflicts, but I think that is probably a price they will
> have to pay for retaining such strong control over the wiki. I
> wouldn't think that it would be that hard to merge then via the
> already existing code for merging edits.

Fair enough. And you're quite right, there would only be the conflicts
that are too close together in the text for the diff3 feature to merge
them. Perhaps you could code an extra check that threw out multiple
people suggesting exactly the same change - you only can't do that
normally, because the editor has to get a result one way or the other
when they hit submit. With an approval queue, it could simply be like
the edit was never made.

--
Rowan Collins BSc
[IMSoP]


from_name: Sj

body:
Brockhaus "must concede defeat" to Wikipedia

c't, the popular german magazine for computer engineering, just
released a study they conducted of the three major digital
encyclopedias in germany -- Brockhaus, Encarta, and (most recently)
Wikipedia.  They tested the encyclopedias on breadth, depth, and
comprehensibility of content, ease of searching, and quality of
multimedia content.

The content test was the most elaborate : first they divided content
in three broad fields, Science, Society, and Culture.  They further
subdivided these into 22 total subject areas, and within each subject
selected an easy, a moderate, and a difficult topic.  They then
searched for the best matching article (and supplementary content) in
the encyclopedia.

Finally, they brought in experts in each broad field who rated the
articles from 1 to 5, based on technical correctness and completeness
of the texts, and on their comprehensibility.  Once this was finished,
the results were totalled at each level of conceptual difficulty,
within each broad field, and across all 66 topics.

The net result: Wikipedia ran away with the top prize, a comfortable
distance ahead of its stately predecessors.  "Brockhaus Premium
surpassed the competition from Redmond," the review reported, "but
must however concede defeat to Wikipedia".

Happily, the full breakdown of the experts' ratings were published
along with the article, so that each encyclopedia may benefit from the
spot check.

A full translation will be available on meta presently :
 http://meta.wikimedia.org/wiki/Wikipedia vs Brockhaus and Encarta

Grab a copy of the original at your local international-pubs shop, if you can.

http://www.heise.de/ct/

Encyclopedias: Wikipedia vs. Brockhaus and Encarta (pg. 132)

--
+sj+


subject: [Wikipedia-l] Wikipedia spanks Encarta, Brockhaus


subject: [Wikitech-l] Re: Membership and payment

body:
Thanks for your help with clarifying the point in the task outlined by
Anthere, Jens.

It seems to me that it would best be done as part of the database
redesign, or after the database redesign (hoping the redesign would be
extensible enough), but somehow it feels like the Foundation would want
it sooner ;-)

Timwi


subject:
[Wikitech-l] [Patch] new function Parser::replaceImageLinks()
	instead of calling replaceInternalLinks twice

body:
In order to solve some conflicts between internal and external links,
wmahan rearranged Parser.php to call replaceInternalLinks() before
replaceExternalLinks(). However, this in turn broke the ability to put
external links inside image captions, since these are created in
replaceInternalLinks()

In order to cope with *internal* links inside image captions,
replaceInternalLinks() is currently called twice, the second pass
catching those images that couldn't be parsed properly because they
had internal links in them. This has always been rather a hack, but
until now, it worked. However, we really want things to be dealt with
in the order:
1 internal links
2 external links
3 images

In order to do this, we need a seperate function that parses *all*
image rendering. I have called this replaceImageLinks(), and based it
on replaceInternalLinks(), but without anything that isn't relevant to
images (including all the prefix and trail processing, for a start). I
rather suspect this may actually make it a whole lot more efficient
than the previous code; still not as efficient as doing proper parsing
in one go, but with the current structure of the code there's no way
to tell that [[foo [[bar]] baz]] is one entity (that would require
looking ahead, and remember we need to be able to process
[[Image:Foo|opts|Caption with a [[piped|link]] in]], so there's no
clever spotting pipes to be done)

Download from: http://195.137.84.82/~ron/replaceImageLinks.diff
It seems to work for me, but obviously I would welcome all comments and testing.

Note: this patch fails parserTests.php on a couple of things, but the
"Image caption with a free URL" and "Thumbnail image caption with a
free URL" tests are actually wrong themselves, so that's no surprise;
testing manually, these cases seem to have the appropriate result. The
"Image caption with a link" appears to fail (unrelatedly) because the
word "link" now appears in a comment, not just surrounded by HTML
tags, so the removal of /<*?>/ now kills it; which is a shame.
--
Rowan Collins BSc
[IMSoP]