subject: [Wikitech-l] Potential additions to 1.5 database schema

body:
David Gerard wrote:
> Tomer Chachamu (the.r3m0t at gmail.com) [050329 06:30]:
> > On Tue, 29 Mar 2005 03:30:25 +0800, b schewek <schewek at linuxmail.org> wrote:
>
> > > Have there been any considerations to add support
> > > for the following ideas:
> > > http://meta.wikimedia.org/wiki/Reviewed_article_version
>
> > People have not yet agreed on [[meta:Article_validation]] - even some
> > basic issues, such as whether to show to anons the reviewed or latest
> > version. I can't imagine support for this will be in 1.5.
>
>
> That's a really bad thing, considering a pile of plans are hung waiting for
> just that feature or something like it.

Yes, I think we need to have an understanding of what needs to be done
in this 1.5 version.  We do *not* need to decide such issues as
whether to show anons the reviewed or latest version.  All we need for
starters is... starters.

What I envision for 1.5 is the simplest possible data gathering tool.

People rate articles, and we record everything about that rating --
who did the rating, what was the rating, what version was rated, etc.
Then we do nothing at all with the data except study it.  We can
anonymize it and share it, and people can run studies of various kinds
on how to combine the ratings effectively.  We can look at the ratings
and see if they are sane, or where they are sane... do anons do a good
job of rating? do experienced editors tend to give the same ratings,
etc.

The beauty of just gathering data and studying it for awhile, with *no
actual implications for the site*, is that we don't have to "a priori"
figure out how to prevent the ratings system from becoming a
slashdot-style karma-whoring game.  We just gather the data, and think
really really hard about it.

--Jimbo


list: wikitech-l

source: pipermail-mbox

from_name: Edward Z. Yang

subject: [Wikitech-l] Long-term: Wiki import/export format

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

John Fader wrote:
> On Mon, 28 Mar 2005 11:22:20 -0800, Ray Saintonge <saintonge at telus.net> wrote:
> None.  This purely affects what a database dump file looks like (giant
> pile of unreadable XML crap vs giant pile of unreadable mysql crap).
> Mirrors and those mining mediawiki datadumps care, ordinary users
> won't see any difference.

The idea (in my understanding) is to standardize the dump format to
increase forward/backward compatibility. I don't have any problems with
standardization, but of course, as John puts it, we're still going to
have a lot of crap when it comes to database dumps, perhaps even more so
with XML.

- --
Edward Z. Yang      Personal: edwardzyang at thewritingpot.com
SN:Ambush Commander Website: http://www.thewritingpot.com/
GPGKey:0x869C48DA   http://www.thewritingpot.com/gpgpubkey.asc
3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFCSGZ0qTO+fYacSNoRAvkvAJ0YrC6A5vjUHoMu8WuMR/MMBEPVjACdH5iQ
FwvyRLqcJsrtQGzMLTW50Dg=
=CmgB
-----END PGP SIGNATURE-----


list: foundation-l

from_name: Brion Vibber

subject:
National chapters (was Re: [Foundation-l] UK Wikimedia Foundation
	notes)

body:
David Gerard wrote:
> Worse than that even - sh: was Serbo-Croatian, then they were separated at
> some stage. Anyone know the history?

The ISO 639 language code 'sh' for Serbo-Croatian was officially
deprecated over five years ago:
http://www.loc.gov/standards/iso639-2/codechanges.html

While I'm sure a happy world in which the violent breakup of Yugoslavia
never happened would be great, the fact is that it did happen, and the
resulting nations are heavily invested in playing up nationalistic
ethnic and linguistic differences.

I don't particularly care whether someone attempts to re-merge them or
not, but you're going to run into very annoyed people either way.

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


body:
David Gerard wrote:
> Worse than that even - sh: was Serbo-Croatian, then they were separated at
> some stage. Anyone know the history?

The ISO 639 language code 'sh' for Serbo-Croatian was officially
deprecated over five years ago:
http://www.loc.gov/standards/iso639-2/codechanges.html

While I'm sure a happy world in which the violent breakup of Yugoslavia
never happened would be great, the fact is that it did happen, and the
resulting nations are heavily invested in playing up nationalistic
ethnic and linguistic differences.

I don't particularly care whether someone attempts to re-merge them or
not, but you're going to run into very annoyed people either way.

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


list: wikimedia-l

body:
David Gerard wrote:
> Worse than that even - sh: was Serbo-Croatian, then they were separated at
> some stage. Anyone know the history?

The ISO 639 language code 'sh' for Serbo-Croatian was officially
deprecated over five years ago:
http://www.loc.gov/standards/iso639-2/codechanges.html

While I'm sure a happy world in which the violent breakup of Yugoslavia
never happened would be great, the fact is that it did happen, and the
resulting nations are heavily invested in playing up nationalistic
ethnic and linguistic differences.

I don't particularly care whether someone attempts to re-merge them or
not, but you're going to run into very annoyed people either way.

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


body:
David Gerard wrote:
> Worse than that even - sh: was Serbo-Croatian, then they were separated at
> some stage. Anyone know the history?

The ISO 639 language code 'sh' for Serbo-Croatian was officially
deprecated over five years ago:
http://www.loc.gov/standards/iso639-2/codechanges.html

While I'm sure a happy world in which the violent breakup of Yugoslavia
never happened would be great, the fact is that it did happen, and the
resulting nations are heavily invested in playing up nationalistic
ethnic and linguistic differences.

I don't particularly care whether someone attempts to re-merge them or
not, but you're going to run into very annoyed people either way.

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


from_name: Yaroslav Fedevych

subject: [Wikitech-l] Re: Long-term: Wiki import/export format

body:
On Mon, Mar 28, 2005 at 02:26:01PM +0200, Karl Eichwalder wrote:
> Brion Vibber <brion at pobox.com> writes:
>
> > (Semantic web my ass! XML is meaningless; just a container format. :P)
>
> As long as you try to derive the XML from the current wiki markup, it is
> surely meaningless because it is layout driven.  Let us use a well
> defined schema and you will get the semantic web for free.

Meaningless? What about AsciiDoc?

--
X windows: You haven't died 'til you've used it.


subject:
[Foundation-l] Re: Positive discrimination related to smaller
	communities and projects

body:
Amgine wrote:
> In wikinews there has been an ongoing discussion regarding the
> unresponsiveness of the mediawiki team to issues considered critical to
> the project. This has now become a discussion regarding a fork of both
> hardware and software, and contributors are actively working toward
> doing so. I don't think this is the best choice, but it is beginning to
> look like the only choice.

Sites like Wiktionary or Wikinews are not really suitable for a wiki to
begin with. I think it's unfortunate that people have so casually thrown
"Wiki" on the front of the name and slapped up a new project wiki
without any actual plan for making it work.

Wikipedia is *very well* suited to a wiki model because an encyclopedia
is largely unstructured prose text, with cross-references between
articles and some light indexing. That's exactly what a wiki is, and our
wiki software is strongly geared to that.

Wiktionary requires structured data which is *completely* unlike what
the wiki model provides. The project's been limping along with
unstructured text for years and is going to have a hard time converting
all that when the appropriate software is finally written for it (a
project which is soon to get underway, I'm told, with a grant for
development which Erik Moeller will be working on).

Wikinews similarly has special needs which are simply outside the scope
of something like MediaWiki, with a much more limited content model,
organization, categorized feeds, much stronger requirements for
verification and moderation etc.

If the Wikinewsies would like to write and maintain suitable software
for their project, I for one think that's *great* and applaud them for
being willing to step up and put in the work instead of assuming someone
else will do it for them. The wiki spirit is all about being able to do
things yourself, after all!

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


body:
Amgine wrote:
> In wikinews there has been an ongoing discussion regarding the
> unresponsiveness of the mediawiki team to issues considered critical to
> the project. This has now become a discussion regarding a fork of both
> hardware and software, and contributors are actively working toward
> doing so. I don't think this is the best choice, but it is beginning to
> look like the only choice.

Sites like Wiktionary or Wikinews are not really suitable for a wiki to
begin with. I think it's unfortunate that people have so casually thrown
"Wiki" on the front of the name and slapped up a new project wiki
without any actual plan for making it work.

Wikipedia is *very well* suited to a wiki model because an encyclopedia
is largely unstructured prose text, with cross-references between
articles and some light indexing. That's exactly what a wiki is, and our
wiki software is strongly geared to that.

Wiktionary requires structured data which is *completely* unlike what
the wiki model provides. The project's been limping along with
unstructured text for years and is going to have a hard time converting
all that when the appropriate software is finally written for it (a
project which is soon to get underway, I'm told, with a grant for
development which Erik Moeller will be working on).

Wikinews similarly has special needs which are simply outside the scope
of something like MediaWiki, with a much more limited content model,
organization, categorized feeds, much stronger requirements for
verification and moderation etc.

If the Wikinewsies would like to write and maintain suitable software
for their project, I for one think that's *great* and applaud them for
being willing to step up and put in the work instead of assuming someone
else will do it for them. The wiki spirit is all about being able to do
things yourself, after all!

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


body:
Amgine wrote:
> In wikinews there has been an ongoing discussion regarding the
> unresponsiveness of the mediawiki team to issues considered critical to
> the project. This has now become a discussion regarding a fork of both
> hardware and software, and contributors are actively working toward
> doing so. I don't think this is the best choice, but it is beginning to
> look like the only choice.

Sites like Wiktionary or Wikinews are not really suitable for a wiki to
begin with. I think it's unfortunate that people have so casually thrown
"Wiki" on the front of the name and slapped up a new project wiki
without any actual plan for making it work.

Wikipedia is *very well* suited to a wiki model because an encyclopedia
is largely unstructured prose text, with cross-references between
articles and some light indexing. That's exactly what a wiki is, and our
wiki software is strongly geared to that.

Wiktionary requires structured data which is *completely* unlike what
the wiki model provides. The project's been limping along with
unstructured text for years and is going to have a hard time converting
all that when the appropriate software is finally written for it (a
project which is soon to get underway, I'm told, with a grant for
development which Erik Moeller will be working on).

Wikinews similarly has special needs which are simply outside the scope
of something like MediaWiki, with a much more limited content model,
organization, categorized feeds, much stronger requirements for
verification and moderation etc.

If the Wikinewsies would like to write and maintain suitable software
for their project, I for one think that's *great* and applaud them for
being willing to step up and put in the work instead of assuming someone
else will do it for them. The wiki spirit is all about being able to do
things yourself, after all!

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


body:
Amgine wrote:
> In wikinews there has been an ongoing discussion regarding the
> unresponsiveness of the mediawiki team to issues considered critical to
> the project. This has now become a discussion regarding a fork of both
> hardware and software, and contributors are actively working toward
> doing so. I don't think this is the best choice, but it is beginning to
> look like the only choice.

Sites like Wiktionary or Wikinews are not really suitable for a wiki to
begin with. I think it's unfortunate that people have so casually thrown
"Wiki" on the front of the name and slapped up a new project wiki
without any actual plan for making it work.

Wikipedia is *very well* suited to a wiki model because an encyclopedia
is largely unstructured prose text, with cross-references between
articles and some light indexing. That's exactly what a wiki is, and our
wiki software is strongly geared to that.

Wiktionary requires structured data which is *completely* unlike what
the wiki model provides. The project's been limping along with
unstructured text for years and is going to have a hard time converting
all that when the appropriate software is finally written for it (a
project which is soon to get underway, I'm told, with a grant for
development which Erik Moeller will be working on).

Wikinews similarly has special needs which are simply outside the scope
of something like MediaWiki, with a much more limited content model,
organization, categorized feeds, much stronger requirements for
verification and moderation etc.

If the Wikinewsies would like to write and maintain suitable software
for their project, I for one think that's *great* and applaud them for
being willing to step up and put in the work instead of assuming someone
else will do it for them. The wiki spirit is all about being able to do
things yourself, after all!

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


from_name: Richard Holton

subject: [Wikitech-l] Running afoul the parser cache...

body:
I'm working on implementing (in 1.5) the feature requested in BUG
#1289 (http://bugzilla.wikipedia.org/show_bug.cgi?id=1289), which I
believe can be (at least partially) addressed by allowing for
descending category lists.

The thought I had was to implement a new magic word "__SORT_DESC__"
(of course, the actual wording is open to change). If this directive
is included in the category page text, then the category listings
would be in descending order.

I've added a bit of code to Parser.php that detects this magic word
and makes a call to the CategoryPage object to tell it to use a DESC
sort. Seems simple enough.

I've got things working, except that when the cached copy of the
parsed page is used, this call to the CategoryPage object is never
executed, and the category list is not DESC. When the cached copy of
the page is not used (or does not exist), then things happen just
right.

The actual category lists are not cached -- only the introductory
portion that people can edit manually. So when I first visit such a
page, things look great, But if I do a reload (eg, ctrl-F5 on Firefox)
the directive is lost. I run into the same problem on subsequent pages
of a multi-page category list.

Short of turning off the parserCache for all category pages, does any
know how to avoid this problem?

-- Rich Holton

en.wikipedia:User:Rholton


from_name: Ray Saintonge

body:
David Gerard wrote:

>Brion Vibber (brion at pobox.com) [050329 09:22]:
>
>
>>David Gerard wrote:
>>
>>
>>>Worse than that even - sh: was Serbo-Croatian, then they were separated at
>>>some stage. Anyone know the history?
>>>
>>>
>>The ISO 639 language code 'sh' for Serbo-Croatian was officially
>>deprecated over five years ago:
>>http://www.loc.gov/standards/iso639-2/codechanges.html
>>
>>
>yay w00t!
>
>
>>While I'm sure a happy world in which the violent breakup of Yugoslavia
>>never happened would be great, the fact is that it did happen, and the
>>resulting nations are heavily invested in playing up nationalistic
>>ethnic and linguistic differences.
>>I don't particularly care whether someone attempts to re-merge them or
>>not, but you're going to run into very annoyed people either way.
>>
>>
>Possibly not a great place for an officially affiliated Foundation chapter
>as yet.
>
That varies with the country.  The political fault lines are already
clearer than they might be in Belgium.  A Croatian foundation might work
more easily than one in Serbia or Bosnia.

Ec


from_name: Daniel Mayer

subject:
[Foundation-l] Development tasks and project needs (was: Positive
	discrimination related to smaller communities and projects)

body:
--- Erik Moeller <erik_moeller at gmx.de> wrote:
> It is true that Wikinews is reaching the limits of human scaling. This is
> because we're getting so large that we will soon have to stop listing all
> stories on the Main Page, and will have to use separate index pages
> instead.

Yep. Such as pages devoted to news in particular nations. We could register
wikinews.us, for example, and redirect it to the U.S. news page on the English
Wikinews. If and when other Wikinews' U.S. news pages get busy enough, then we
could have xx.wikinews.us redirects as well. But wikinews.us by itself should
still auto redirect to the English version (and wikinews.ru should always
prefer the Russian Wikinews even if other xx.wikinews.ru redirects exist, ect
for each nation/primary language spoken in that nation).

> Since I'm the person Gerard spoke about who is going to implement
> structured data functionality over the next 3-4 months, my own resources
> are limited. However, I have offered in the past to act as a development
> task coordinator for the Wikimedia Foundation, and that offer still
> stands.

For what it is worth you have my support. :)

> Such a task coordinator would prioritize tasks, maintain contacts to
> potentially interested sponsors, and make recommendations on spending a
> certain part of our internal budget on development tasks. He would write
> the basic specifications, try to locate interested developers (both by
> inviting them directly, and by having public calls for tenders), watch
> over the implementation, and decide whether it meets the specs (together
> with the Board and the MediaWiki Release Manager, Brion Vibber).

Sounds more like a Chief Technical Officer to me. If we can't pay you to do
this, then you might as well have a nice title to put on your resume. :) That
would not prevent us from finding a way to pay you in the future for this (if
the board so wishes), nor should it prevent you from working on and getting
paid for development tasks approved by the board in the interim.

> I strongly believe that a combined model of full-time employment for
> people like Brion, and task-based contracts for project-specific needs, is
> the only way forward.

Nod. We certainly have enough money for a couple full time employees and a few
limited term mini contract positions without putting a significant dent in the
overall budget. Whether or not the board wants to do that is a policy matter
for them to decide.

> As for the specific needs Wikinews has, Ilya has already written a bit
> about that. I have a fairly good idea in my head how news feeds could work
> within MediaWiki in a scalable fashion. The question is, are we willing to
> spend the money to get this done?

We have $20,000 budgeted for development projects and/or extra hardware this
quarter.
http://wikimediafoundation.org/wiki/Budget/2005

What we need is somebody to coordinate spending priorities and have that
approved by the board. A good deal of justification will be needed to spend
money on anything other than hardware so this is not a trivial task.

> Just because Wikipedia sort of works (even though we still don't have peer
> review functionality after more than 4 years), we shouldn't start
> slacking. We have half a dozen active developers at any given time. We
> have hundreds of thousands of users and even more readers. We've tried
> recruiting. Jimbo has given his speech at FOSDEM. There's more we can do,
> but in part due to the growing complexity of MediaWiki, this imbalance can
> ultimately only be addressed with one resource: money.

I've also noticed some fairly obvious vandalism slipping through for days
before being corrected. Our old way of RC patrol is not scaling well by not
letting different users divide the workload.

If I trust a set of users, then why would I need to check a diff they already
checked? And why would their edits show up just as prominently as people I
don't know/trust? Right now there is no way for me to know that somebody I
trust (or trust by proxy) has checked any particular diff. So I either check it
again or miss it in the flood of 20 to 30 edits a minute we get on the English
Wikipedia.

-- mav

__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/


from_name: Karl Eichwalder

body:
Yaroslav Fedevych <jaroslaw at linux.org.ua> writes:

> Meaningless?

At least, it is ambiguous.  Surrounding a phrase with ''apostrophs''
means, you would like to see it in italics - the phrase might be a
quotations, a "see also", a catch word, or something else.  Worse, this
kind of markup is very fragile (no line-breaks are allowed) and if if
you make an error be accident, the wike will ''happily' accept it.

The good thing is, the always morphing wiki syntax keeps us busy,
especially those who like to write parsers ;-)

--
http://www.gnu.franken.de/ke/                           |      ,__o
                                                        |    _-\_<,
                                                        |   (*)/'(*)
Key fingerprint = F138 B28F B7ED E0AC 1AB4  AA7F C90A 35C3 E9D0 5D1C


list: wikipedia-l

from_name: Anthere

subject: [Wikipedia-l] Re: Autofellatio

body:
Andre Engels a ?crit:
 > On Mon, 28 Mar 2005 12:54:17 +0200, Anthere
<anthere9 at yahoo.com> wrote:
 >
 >
 >>In case of all sensible images such as the autofellatio, it should be
 >>the project choice whether to display it or not. And I think the
 >>multiplication of complaints on the topic requires to think about a
 >>viable solution for all of us.
 >
 >
 > It IS the choice of the project. If you don't want the image on your
 > project, don't add a link to it. And yes, people can add the link
 > again, but then, they can upload the image again too, or re-insert a
 > copyright violation, or whatever. I don't see the problem.
 >
 > Andre Engels

No, it is not the choice of the project.

When editors start to complain noisily over and over and over that the
pornographic pictures of the english wikipedia are spilling over their
project, then there is a problem. And I think it is normal that I report
it, because I think it is understandable that people are upset and ask
that a solution is brought.

Add that this is done by a bot and at high speed, and add that it is NOT
easy to revert a redirect to another project, and you have the seed of a
crisis boiling.

When porn images were linked many times in the english project, due to
vandalism, it resulted in some solution being proposed : no direct
linking allowed (granted, there was also the issue of the copyright).

When wrong images are uploaded at high speed by anonymous editor, the
solution is to allow image upload only to log-in editors.

These two solutions do not allow to entirely prevent vandalism, but they
allow to slow down the speed of it.

Now, we have several projects, such as the french, the dutch, the
spanish ones, which are victims of vandalism spree by a bot, which
redirect pages to the english pornography. It is a vandalism difficult
to revert. It is time consuming. And it is very upsetting to editors.

The question is "is it okay that several editors spent several hours
running to remove pornographic images from other editors talk page or
their main page ?"; Is it the best way to use people time ? what value
do you give to people time when they spent 1 hour cleaning up the mess
of a 5mn bot ?

Dunno, but when editors leave me a spanish desperate message on my talk
page, when I see calls on the french pump to go for deletion of the
english image, I just think there IS a problem.

I am not sure the solution of this problem is to make a general call on
all pedias vandalised to go vote for the image deletion.


body:
Brion Vibber wrote:

> Sites like Wiktionary or Wikinews are not really suitable for a wiki to
> begin with. I think it's unfortunate that people have so casually thrown
> "Wiki" on the front of the name and slapped up a new project wiki
> without any actual plan for making it work.
>
> Wikipedia is *very well* suited to a wiki model because an encyclopedia
> is largely unstructured prose text, with cross-references between
> articles and some light indexing. That's exactly what a wiki is, and our
> wiki software is strongly geared to that.
>
> Wiktionary requires structured data which is *completely* unlike what
> the wiki model provides. The project's been limping along with
> unstructured text for years and is going to have a hard time converting
> all that when the appropriate software is finally written for it (a
> project which is soon to get underway, I'm told, with a grant for
> development which Erik Moeller will be working on).

This really depends on the vision that one applies to a dictionary.  If
the focus is on the host language of a particular Wiktionary the present
software can be made to do, but I can see where it will not be adequate
for Gerard's vision of a super-dictionary.  The super-dictionary has a
much stronger focus on translation issues, and that can tolerate
somewhat less semantic debate than might be the case in a particular
language.  Once the super-dictionary has a working model it will
probably be easier to co-ordinate between that and the various language
specific projects.

Ec


from_name: Aphaia

subject: [Foundation-l] german wikiquotes

body:
Well we Japanese Wikiquotians have the same problem; no cite without
context is legally allowed.

On Sun, 27 Mar 2005 09:45:30 +0100, Anthere <anthere9 at yahoo.com> wrote:
> Any suggestion to help on the topic ?

If de.wp would like to have those quotes  survive, in my opinion, give
them context; describe how those quotes would be esteemed, in what
context they have been quoted, what context they had originally, and
so on and so on.

Perhaps they woudl get a sort of commentary and then the problem is if
it would be what they want to have (personally I don't like it -I
prefer a reciprocity of quotation with minimum commentary and that is
one of reason Japanese Wikiquote hasn't chosen this way).

P.S. how do you think we have a new mailinglist dedicated for wikiquote?

--
Aphaea@*.wikipedia.org
email: Aphaia @ gmail (dot) com


subject: [Foundation-l] german wikiquotes


from_name: Nicolas Weeger

subject: [Wikipedia-l] Re: Autofellatio

body:
Sj a ?crit :
> Agreed.  Make an interwiki redirect say "the page you want is [here]"
> without automatic redirection.  It's needed almost never, save when
> trying to play with a visitor's mind.
>
> SJ

Agreed too.

Ryo


from_name: Alfio Puglisi

subject: [Wikipedia-l] Re: Autofellatio

body:
On Mon, 28 Mar 2005, Daniel Mayer wrote:

>Simple. Let's get rid of interwiki redirects altogether. They have *always*
>been more trouble than they are worth due to transporting readers to another
>wiki without any obvious way for them to know, nor any obvious way to revert
>the redirect.

I must confess that I didn't even know that interwiki redirects were
possible. Are they actually used for some purpose?

Alfio


from_name: Lee Daniel Crocker

body:
On Tue, 2005-03-29 at 03:30 +0800, b schewek wrote:

> Have there been any considerations to add support
> for the following ideas:
> http://meta.wikimedia.org/wiki/Reviewed_article_version
>

Something along those lines is pretty high on my priority list,
but awaits better handling of metadata in general.

--
Lee Daniel Crocker <lee at piclab.com>  <http://www.piclab.com/lee/>
<http://creativecommons.org/licenses/publicdomain/>


from_name: GerardM

body:
Hoi,
I think the worst we can do is fork. It will mean that we will not
benefit from the economies of scale that the Wikimedia Foundation
offers. These benefits are huge, with a project that is part of the
larger community, you will be known and otherwise you have to struggle
to get the same "facetime". You will be just another project
struggling to get recognition. You will have to find programmers, you
will have to find hardware, you will have to do all the hard work that
is already done really well.

Take me as an example, I did not give up on Wiktionary, I worked hard
to get an idea of what we should have (by putting in a lot of work) I
got some community going and learned that we need one database to rule
them all .. :) I discussed this and learned about Wikidata. This is
the necessary building block for the "ultimate wiktionary". I found
someone to program it, I found someone to pay the programmer and, the
development has started. Wikispecies will benefit from this if we get
enough traction (read also but not only money) to make this happen. I
have uploaded some 3000 soundfiles and now the upload screen is
uploaded to such an extend that I can upload a Dutch pronunciation in
a fraction of the time.

My point to you is: Do not give up, get your community to grow and
find out what you really need. And work at it. My point to the list in
general is, there are many things that need doing We need resources to
make the things happen to grow the projects and communities other than
Wikipedia. When we agree to have all these projects and communities,
we have to invest in their well being. It is a defeat of who we are
when we get a fork because of unresponsiveness. It is certainly a pity
when we CAN hire programmers to create the desperately needed
functionality.

An example: It is easier to upload Dutch, English, German soundfiles
than Farsi soundfiles I can do easily 10 times more words in the same
time. It upsets me that a soundfile obscures text in Hebrew, Arabic or
Farsi because of this stupid symbol that is seen because Commons is
seen as an external resource.

I want to have dia shows when we have too many pictures for a subject.
I have ideas about "language immersion training" it needs some
software to allow for different target languages. Those are only my
ideas.... there are so many even better idea's....

We can get money for functionality, we can get money for servers. We
just have to ask. That is why the Foundation can be such a powerfull
organisation. It can be an enabler. That is in my opinion what we have
done brilliantly, given the outrageous success that Wikipedia is. We
just have to work hard on making the other projects a success too.

Define projects, define functionality, get a community interested in
change find money, find programmers. And let's make things even
better..

One thing you cannot do is expect others to do the work for you. If
you cannot do the programming, find someone who can and who will. If
you do not have the money find someone who does.  If you cannot define
your needs, find someone who can because without a well defined need
you are snookered and, on your own it will be only worse,

Thanks,
    GerardM

On Mon, 28 Mar 2005 06:35:24 -0800, Amgine <amgine at saewyc.net> wrote:
> In wikinews there has been an ongoing discussion regarding the
> unresponsiveness of the mediawiki team to issues considered critical to
> the project. This has now become a discussion regarding a fork of both
> hardware and software, and contributors are actively working toward
> doing so. I don't think this is the best choice, but it is beginning to
> look like the only choice.
>
> Amgine
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>


from_name: Lars Aronsson

body:
Lee Daniel Crocker wrote:
> Proposed solution: Let's create a standardized file format (probably
> something XML-ish) for storing the information contained in a wiki.
> All the text, revisions, meta-data, and so on would be stored in a
> well-defined format, so that, for example, upgrading the wiki software
> (from any version to any other--no need to do one at a time!) could
> be done by exporting the wiki into this format and then importing it
> into the new installation.  The export format would be publishable

It sounds so easy.  But would you accept this procedure if it requires
that Wikipedia is unavailable or read-only for one hour? for one day?
for one week?  The conversion time should be a design requirement.

My experience is that software bandwidth (and sometimes hardware
bandwidth) is the limit.  The dump will be X bytes big, and the
export/import procedures will pump at most Y bytes/second, making the
whole procedure take X/Y seconds to complete.  If you get acceptable
numbers for the Estonian Wikipedia (say, 23 minutes), it will come as
a surprise that the English is so many times bigger (say, 3 days). You
might also get an error (hardware problem, power outage, whatever)
after 75 % of the work is completed, and need to restart it.

XML is very good at making X bigger, and doesn't help increasing Y.
Already after a short introduction, everybody calls themselves an
expert in designing an XML DTD, but who cares to tweak the performance
of the interface procedures?  How do you become an expert before
having tried this several times?

Quoting myself from [[meta:MediaWiki_architecture]]:

 "As of February 2005, the "cur" table of the English Wikipedia holds
  3 GB data and 500 MB index (download as 500 MB compressed dump)
  while the "old" table holds 80 GB data and 3 GB index (download as
  29 GB compressed dump)."

Assuming these sizes would be the same for an XML dump (ROTFL) and
that export/import could be done at 1 MB/second (optimistic), this is
3500 seconds or about one hour for the "cur" table and 83,000 seconds
or close to 24 hours for the "old" table.  And this is for the sizes
of February 2005, not for May 2005 or July 2008.  You do the math.

Not converting the database is the fastest way to cut conversion time.
Perhaps you can live with the legacy format?  Consider it.

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


subject:
[Foundation-l] Re: Positive discrimination related to smaller
 communities and projects

body:
Amgine a ?crit:
> In wikinews there has been an ongoing discussion regarding the
> unresponsiveness of the mediawiki team to issues considered critical to
> the project. This has now become a discussion regarding a fork of both
> hardware and software, and contributors are actively working toward
> doing so. I don't think this is the best choice, but it is beginning to
> look like the only choice.
>
> Amgine

I do not think finding hardware to host a project this size would be
very problematic in the short run, but who would take care of it ? And
mostly, if you think the current team is unresponsive to current
wikinews software needs, who do you think will take care of modifying
the MediaWiki software outside of the current team ? Is it perceived it
would be more efficient to have a software fork or even to use another
software ?

Incidently, though I often heard of some software features for the
wiktionary and species project, which features are necessary to wikinews
and where has this been discussed ?

Ant


body:
On Mon, 2005-03-28 at 14:34 -0800, Jimmy (Jimbo) Wales wrote:

> What I envision for 1.5 is the simplest possible data gathering tool.

Agreed...it's the data that's important, and the presentation can wait.
But it would sure be nice to have some sort of general facility for
metadata in place, and a better facility for user identification and
validation (for example, what would happen if we collected all this
data about who likes what articles, and then someone hijacked the user
accounts of the reviewers and changed their data?)  Some sort of basic
signature system would solve that pretty easily.

It should also be pointed out that there's no reason metadata has to
be in the Wiki database itself, as long as there's a stable and
standard way to /point/ to an article revision (another thing in
dire need of standardization).  The wiki software should probably try
to facilitate entering the data, though.

--
Lee Daniel Crocker <lee at piclab.com>  <http://www.piclab.com/lee/>
<http://creativecommons.org/licenses/publicdomain/>


body:
Lars Aronsson <lars at aronsson.se> writes:

> It sounds so easy.  But would you accept this procedure if it requires
> that Wikipedia is unavailable or read-only for one hour? for one day?
> for one week?

It could be done on-the-fly, even if it takes some weeks.  "Simply" also
start storing the converted articles in a second table (or database
system)...

> Assuming these sizes would be the same for an XML dump (ROTFL) and
> that export/import could be done at 1 MB/second (optimistic), this is
> 3500 seconds or about one hour for the "cur" table and 83,000 seconds
> or close to 24 hours for the "old" table.  And this is for the sizes
> of February 2005, not for May 2005 or July 2008.  You do the math.

Of course, you must use a database system designed for holding XML data
;)  If we start using XML properly we can give up on many a lot hacks.
We will also save resources because the set of allowed tags is limited
and their usage is well-defined :)

--
http://www.gnu.franken.de/ke/                           |      ,__o
                                                        |    _-\_<,
                                                        |   (*)/'(*)
Key fingerprint = F138 B28F B7ED E0AC 1AB4  AA7F C90A 35C3 E9D0 5D1C


body:
On Mon, Mar 28, 2005 at 04:21:33PM +0200, Karl Eichwalder wrote:

> The good thing is, the always morphing wiki syntax keeps us busy,
> especially those who like to write parsers ;-)
>

Oh... Could those *incredibly* good and generous people write an
AsciiDoc parser or at least make a quick point where and what to
redefine to do it by myself? (Sources are not so self-contained as they
seem to be) :)  Many thanks!

--
X Windows: Accept any substitute.


from_name: Sj

subject: [Wikipedia-l] Autofellatio

body:
On 28 Mar 2005 23:12:00 +0100, Erik Moeller <erik_moeller at gmx.de> wrote:
> 1) Brion is on the case already. There's a code change in CVS that will
> allow InterWiki redirects to show a "Redirected from" like regular
> redirects.

Better to just nott auto-redirect at all.

SJ


from_name: George Stevens

body:
I have some experience with this sort of thing, so thought I would add
my 2p to the information pool being shared here.

1) In general, there is no such thing as a universal format.
Having a data mediation format that spans versions is often an
intractable problem to solve.  Essentially, if we can find a format that
is agnostic to any version of the application, then we would just use
that format as the data schema and not worry about data migrations for
any version change because every version uses the same format.  Finding
such a format nearly always subsumes the possibility of future
application innovation.

2) An existing standard can be settled upon that meets core needs.
In this case, the stakeholders identify a standard format that has some
level of widespread use and agree to always have the capability to
export and import in that format.  This is how we individually overcome
limits in the applications we use daily.  Specifically, we often search
for a Save-As format from a source application that we know is
accommodated by a destination application.  The problem with this is
that although it can be lossy, it is more likely to be gainful - meaning
that the importing application has to make assumptions in order to fill
in missing data that it might need.
	This solution is not ideal, primarily because there may be a
data requirement of the importing application that cannot be
algorithmically determined.  As a result, human intervention might be
required for each unit of data imported.  This is certainly not a
reasonable solution for even moderately sized datasets of just a few
hundred elements.

3) Look-ahead designs are used before features are implemented.
In this case, a very heavy-weight design effort attempts to
prognosticate the data design well ahead of code implementation.  This
actually can be done if innovation is buffered and features are queued
and agreed upon well in advance.  This is about as un-agile as software
development gets, however; and, as most software engineers know, it is
brutally difficult to design something to this level of detail so far
ahead of implementation (and indeed it almost always fails in my
experience).

4) Create a migration mechanism for each release.
This is typically what is done.  The reasons are simple, the source
application data formats are well known and the destination data formats
are well known.  The only thing needed is an intelligent mapping from
one to the other.  As Lee has pointed out, the problem with this is that
it places a burden on the user community to stay abreast of development
whenever a migration is required.

I am sure there are other analyses in the solution domain, but the above
is off the top of my head.  Although certainly not empirical, I
conjecture that an industry best practice is to provide 4) as a minimum,
and support a collection of widespread formats for 2).

Sorry for rambling on about this, but this has been a problem that has
been around for a long time in software engineering circles.  Comments
and criticisms welcome.

Thanks,
George

-----Original Message-----
From: mediawiki-l-bounces at Wikimedia.org
[mailto:mediawiki-l-bounces at Wikimedia.org] On Behalf Of Lee Daniel
Crocker
Sent: Monday, March 28, 2005 11:26 AM
To: Wikimedia developers
Cc: Mediawiki List
Subject: [Mediawiki-l] Re: [Wikitech-l] Long-term: Wiki import/export
format

On Mon, 2005-03-28 at 17:51 +0200, Lars Aronsson wrote:

> It sounds so easy.  But would you accept this procedure if it requires
> that Wikipedia is unavailable or read-only for one hour? for one day?
> for one week?  The conversion time should be a design requirement.
> ...
> Not converting the database is the fastest way to cut conversion time.
> Perhaps you can live with the legacy format?  Consider it.

A properly written export shouldn't need to have exclusive access to the
database at all.  The only thing that would need that is a complete
reinstall and import, which is only one application of the format and
should be needed very rarely (switching to a wholly new hardware or
software base, for example).  In those few cases (maybe once every few
years or so), Wikipedia being uneditable for a few days would not be
such a terrible thing--better than it being down completely because the
servers are overwhelmed.

--
Lee Daniel Crocker <lee at piclab.com>  <http://www.piclab.com/lee/>
<http://creativecommons.org/licenses/publicdomain/>
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l at Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l


subject: [Wikipedia-l] Re: Autofellatio

body:
David Gerard wrote:
> Alfio Puglisi (puglisi at arcetri.astro.it) [050329 01:34]:

>>I must confess that I didn't even know that interwiki redirects were
>>possible. Are they actually used for some purpose?

Mark wrote:
>in the case of user pages, it is sometimes a useful feature.

David wrote:
> There are some en:Wikipedia: space pages that are now redirects to the
> equivalent on meta: . That's all I can think of.

I confess I have in the distant past used the feature for both cases you
two describe. However I came to realize that the downsides outweigh the
ups (even without this annoying new trend in vandalism), and strongly
support turning off the feature.

Minimal "soft redirects" that say "this page is now on meta", or "please
see my user page on en" are definitely to be prefered.

Pete/Pcb21
p.s. Brion has made some comments on this feature at bugzilla (850, I
believe).


list: wikien-l

from_name: Violet/Riga

subject: [WikiEN-l] Ultra slow again - preventing deletion and moves

body:
Once again I can't do a thing.  I've been trying to do some of the
work at WP:RM for the last hour and am sick of seeing the "Sorry- we
have a problem..." message - not been able to do a single one yet.

It's not too slow looking at pages, even editing them isn't too bad,
but trying to delete or move is simply impossible at the moment.  So
damn frustrating.

~~~~ Violet/Riga


body:
On Mon, Mar 28, 2005 at 05:51:20PM +0200, Lars Aronsson wrote:
> Not converting the database is the fastest way to cut conversion time.
> Perhaps you can live with the legacy format?  Consider it.
>

What about having it (*not* necessarily XML) as an option and being
customizable? Not every Mediawiki-powered site is that large and some
of them in fact may require something like that.

--
The environment of today... tomorrow!
    X windows.


from_name: Michael Snow

subject: [Foundation-l] Re: Development tasks and project needs

body:
I'm close to being out of my depth on some of this discussion, but
perhaps somebody would be able to explain for me. A few people have
raised the possibility that what is technically desirable on one project
may not be so on another.

It seems to me that in some areas, perhaps we could more explicitly
design for different options, where some projects are better suited for
one option and some for another. I'm reminded of the recent debate over
nofollow attributes, where it was suggested that some larger projects
that already fight spam effectively might choose to turn this off. Do we
have a conscious preference for having all sites on basically the same
software configuration? For example, could we get something like dynamic
listing, for which I can see the usefulness on Wikinews, without
applying the same thing to Wikipedia where it might be detrimental? Is
this sort of thing happening already more than I'm aware of? Why would
this not be possible within the MediaWiki framework?

For projects where consistent data structures are most helpful, like
Wiktionary or Wikispecies, I can understand a little why the software
needs *might* ultimately prove incompatible with Wikipedia. With respect
to Wikinews, from my experience there I have yet to grasp why anything
resembling a software fork would be necessary.

Since I'm not familiar with all the details here, maybe these are just
dumb questions. But looking at things only from a distance, the picture
I see makes me want to ask anyway.

--Michael Snow


from_name: Magnus Manske

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

As the change from 1.4 to 1.5 db will be a big step anyway, two
additions come to mind:

* Language links
Should we finally put these into a real table? At least, additionally to
keep them in the text? With an interwiki link table up and current, we
could then switch to "real" interwiki management at a later stage.

* Templates
At German wikipedia, we have a "Personendaten" (person data) template.
It might be of use to be able to access the data put into it. I don't
have an actual application for that, though.

None of these items is essential, but IMHO there's an oppurtunity to at
least prepare for an improved metadata management.

Magnus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCSD+JCZKBJbEFcz0RAluFAJ9HX3wfsuWhmiZW7px+RxEnZFAvnwCfR6li
YjtE6suBRh0Q74URXomtIj0=
=CGOC
-----END PGP SIGNATURE-----


from_name: Mathias Schindler

body:
Magnus Manske wrote:

> * Templates
> At German wikipedia, we have a "Personendaten" (person data) template.
> It might be of use to be able to access the data put into it. I don't
> have an actual application for that, though.

The prime use for Personendaten is that it allows you to automatically
create an alphabetically sorted list of Lemmata that follow classic
conventions like "Dole, Bob" under D instead of [[Bob Dole]] under B.

A second feature is something like "list all people that were born
between 1700 and 1800 in Frankfurt".

All people who died on March 18. and so on.

Mathias


from_name: Yaroslav Fedevych

references:
<1111978414.23849.16.camel@penguin.piclab.com>
	<Pine.LNX.4.58.0503281722290.20883@sara.aronsson.se>
	<shsm2f7ns5.fsf@tux.gnu.franken.de>

body:
On Mon, Mar 28, 2005 at 06:12:10PM +0200, Karl Eichwalder wrote:
>
> Of course, you must use a database system designed for holding XML data
> ;)  If we start using XML properly we can give up on many a lot hacks.
> We will also save resources because the set of allowed tags is limited
> and their usage is well-defined :)
>

BTW, I hate to type articles in XML, it sucks for that purpose badly.
Structured text is the thing to go for, but XML... Arrrrgggghhh!!!!

--
?????????? ??????????? -- ?????? ?????? ???.
	?. ?. ????


body:
Yaroslav Fedevych <jaroslaw at linux.org.ua> writes:

> BTW, I hate to type articles in XML, it sucks for that purpose badly.

You can use an XML editor or plug-in.

> Structured text is the thing to go for, but XML... Arrrrgggghhh!!!!

I would not mind switching to SGML with some minimization feature
switched on; it is possible to write SGML with minimal markup.

--
http://www.gnu.franken.de/ke/                           |      ,__o
                                                        |    _-\_<,
                                                        |   (*)/'(*)
Key fingerprint = F138 B28F B7ED E0AC 1AB4  AA7F C90A 35C3 E9D0 5D1C


subject: [Wikipedia-l] Autofellatio

body:
--- Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Mon, 28 Mar 2005 12:54:17 +0200, Anthere
> <anthere9 at yahoo.com> wrote:

> > Many months ago, we made it impossible to link to
> external images,
> > because we were fighting to avoid the goatse.
> > Now, several wikipedias are dirtied by the
> pornographic images available
> > on the english wikipedia.
> > So, I suggest that
> > * either we all agree to share common images,
> since they can impact us
> > and in this case, I would like that a common vote
> is held to decide the
> > deletion of this image from the english wikipedia
> > * or we agree that no local projects should be
> submitted to the
> > editorial choices made by other projects and
> redirections between
> > projects should be cancelled
> > * or we find a filtering solution, so that certain
> images not welcome to
> > other projects may not be redirected.
> >
> > In case of all sensible images such as the
> autofellatio, it should be
> > the project choice whether to display it or not.
> And I think the
> > multiplication of complaints on the topic requires
> to think about a
> > viable solution for all of us.
>
> Let me suggest the correct course of action:
>
> If your interest is to censor encyclopedic content
> on any wikimedia
> wikipedia, then your goals are at odds with the
> goals of the
> foundation.

I am not exactly sure who is "you" in your sentence.

Unless I am entirely mistaken somewhere, I was elected
to be a representative of editors.
Now, I have three different wikipedia editors
contacting me to raise this issue which is important
to them, and asking me to help them find the right
solution, most approved by the community.

So, there are two options
* either I accordingly receive their complaints and
report them so that a solution be found and editors
happy again
* or I just tell them to mind their own business and
find a solution all by themselves.

I tend to think the first case fit with my role.

Second, I am well aware some editors are supporting
keeping these images, for whatever reasons. I support
keeping them WHEN they are informative, which all the
veneral diseases definitly are. I do not think this
autofellatio image is, and am quite glad to replace it
directly online with Rama's drawing.

Lastly, whatever the decision is, keeping the image or
not keeping the image, this image has NOTHING to do on
a user talk page.

Because you do not share the same
> goals, you should fork
> and produce your own project with censorship among
> it's goals.

Who is "you" ???

May I suggest that the english wikipedia is NOT the
Foundation. And that if I recognise the rights of the
english wikipedia to decide itself what is good taste
from what is bad taste, I do not recognise its right
to decide alone what is censorship and what is not
censorship. And I do not recognise its right to decide
what should be on all the other projects from what
should be absolutely.

Asking that porn pictures be not displayed largely on
user talk page is frankly not a question of
censorship, it is a question of civility.

And when editors are complaining of large vandalism
displaying porn pictures on their talk page, I think
it would be good manner to recognise there is a
problem and find a solution to it.

> If you continue to endorse censorship you are
> harming the project.
> Please allow those who want to share knowledge
> freely the ability to
> do so on wikipedia by taking your censorship
> someplace else.

I admire your ability to discuss an issue. I report 3
different wikipedias complaints about large scale
vandalisme, and your answer is "fork".

> The claim that pages are somehow 'dirtied'  by a
> mere image speaks
> strongly about your lack of neutral perspective.

There is currently strong support for deleting this
image.

And yes, if I find my user page replaced by a man
sucking his cock, forgive me, but I find this to be
dirty.

> Wiki vandalism is unfortunate, but it is not a
> sufficient cause to
> reduce the available knowledge and the free exchange
> of information to
> mankind. It is not an excuse for censorship.

I do not think a talk page being replaced by
pornographic pictures will reduce world knowledge. And
I do not think a man sucking is cock being limited on
one article only rather than thousand of pages will be
a bad blow in free exchange of information.

However, I do think that such reactions to other
people opinions is a bad blow in wikilove that we
should all try to respect.
>

__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/


from_name: Sean Barrett

subject: [Wikipedia-l] Autofellatio

body:
Gregory Maxwell stated for the record:

> If your interest is to censor encyclopedic content on any wikimedia
> wikipedia, then your goals are at odds with the goals of the
> foundation.  Because you do not share the same goals, you should fork
> and produce your own project with censorship among it's goals.
>
> If you continue to endorse censorship you are harming the project.
> Please allow those who want to share knowledge freely the ability to
> do so on wikipedia by taking your censorship someplace else.

I find it admirable that you are so utterly certain that you know what
the goals of the foundation are better than members of the Board of
Trustees of the Wikimedia Foundation, and are so unhesitatingly willing
to accuse those Trustees of harming your project, and are so quick to
request that Trustees leave your project.

Admirable, and very wrong.

But admirable.

Well, sorta.


from_name: John Fader

body:
On Mon, 28 Mar 2005 11:22:20 -0800, Ray Saintonge <saintonge at telus.net> wrote:

>  The question that
> this boils down to is, "How will adopting XML affect the average user?"

None.  This purely affects what a database dump file looks like (giant
pile of unreadable XML crap vs giant pile of unreadable mysql crap).
Mirrors and those mining mediawiki datadumps care, ordinary users
won't see any difference.

--
John Fader


from_name: Tomer Chachamu

body:
On Tue, 29 Mar 2005 03:30:25 +0800, b schewek <schewek at linuxmail.org> wrote:
>
> >
> > As the change from 1.4 to 1.5 db will be a big step anyway, two
> > additions come to mind:
> >
> > * Language links
> > Should we finally put these into a real table? At least, additionally to
> > keep them in the text? With an interwiki link table up and current, we
> > could then switch to "real" interwiki management at a later stage.
> >
>
> Have there been any considerations to add support
> for the following ideas:
> http://meta.wikimedia.org/wiki/Reviewed_article_version

People have not yet agreed on [[meta:Article_validation]] - even some
basic issues, such as whether to show to anons the reviewed or latest
version. I can't imagine support for this will be in 1.5.


from_name: MacGyverMagic/Mgm

body:
> It's not too slow looking at pages, even editing them isn't too bad,
> but trying to delete or move is simply impossible at the moment.  So
> damn frustrating.
Frustrating indeed. Every single edit I've done so far has fetched me
an error message. Some went through, but I also edits I had to repeat
3 times before anything happened. No doubt, some newbies are
recreating some new pages too many times with server response times
like this. *grumble*

Mgm


references:
<1111978414.23849.16.camel@penguin.piclab.com>
	<Pine.LNX.4.58.0503281722290.20883@sara.aronsson.se>
	<shsm2f7ns5.fsf@tux.gnu.franken.de>
	<20050328165138.GA22688@fly.osdn.org.ua>
	<shoed37j37.fsf@tux.gnu.franken.de>

body:
On Mon, Mar 28, 2005 at 07:53:32PM +0200, Karl Eichwalder wrote:
> Yaroslav Fedevych <jaroslaw at linux.org.ua> writes:
>
> > BTW, I hate to type articles in XML, it sucks for that purpose badly.
>
> You can use an XML editor or plug-in.
>
> > Structured text is the thing to go for, but XML... Arrrrgggghhh!!!!
>
> I would not mind switching to SGML with some minimization feature
> switched on; it is possible to write SGML with minimal markup.
>

As I have mentioned -- if markup is minimal, there are worthier
alternatives which permit 1:1 conversion... If {SG,X}ML is really
needed.

--
????? ???, ?????? ?????????? ??????????? ?????????? Windows --
???????????? ???????. ????? ??? ????? ?????????? ??????
?????.


from_name: Walter van Kalken

subject:
[Foundation-l] Re: Positive discrimination related to
	smallercommunities and projects

body:
Amgine wrote:

> In wikinews there has been an ongoing discussion regarding the
> unresponsiveness of the mediawiki team to issues considered critical
> to the project. This has now become a discussion regarding a fork of
> both hardware and software, and contributors are actively working
> toward doing so. I don't think this is the best choice, but it is
> beginning to look like the only choice.
>
Can I ask where the discussion is being done?

Walter (Waerth)


from_name: Erik Moeller

body:
I am not aware of any serious discussions concerning a fork. DV suggested
that video files might be best hosted on some external service, but I
commented that Wikimedia has more than enough resources to do that, and
that we mostly need to agree on which politically correct video codec to
use. I strongly oppose both project and software forks for reasons that
should be obvious.

It is true that Wikinews is reaching the limits of human scaling. This is
because we're getting so large that we will soon have to stop listing all
stories on the Main Page, and will have to use separate index pages
instead.

When Wikinews started, I did set up such index pages for regions and
topics. It already became clear during the demo phase that these are
nearly impossible to maintain manually -- it's not a fun job, so it
doesn't get done, especially because everyone with some small technical
knowledge knows that a computer could do this.

So, what's the solution?

Since I'm the person Gerard spoke about who is going to implement
structured data functionality over the next 3-4 months, my own resources
are limited. However, I have offered in the past to act as a development
task coordinator for the Wikimedia Foundation, and that offer still
stands.

Such a task coordinator would prioritize tasks, maintain contacts to
potentially interested sponsors, and make recommendations on spending a
certain part of our internal budget on development tasks. He would write
the basic specifications, try to locate interested developers (both by
inviting them directly, and by having public calls for tenders), watch
over the implementation, and decide whether it meets the specs (together
with the Board and the MediaWiki Release Manager, Brion Vibber).

His Holiness JW III is not infinitely scalable. I believe I am well-
qualified for the role in question, and it is something I would love to
do. The WMF has hired Brion on a part-time basis. But that's not going to
cut it. Brion has got his hands full making sure that all the crazy
inventions by people like me actually work, fixing existing bugs, working
on sponsor-specific tasks like OAI support for GuruNet, churning out
releases, watching over scalability, and addressing high priority general
project issues like single login.

I strongly believe that a combined model of full-time employment for
people like Brion, and task-based contracts for project-specific needs, is
the only way forward.

As for the specific needs Wikinews has, Ilya has already written a bit
about that. I have a fairly good idea in my head how news feeds could work
within MediaWiki in a scalable fashion. The question is, are we willing to
spend the money to get this done?

And Wikinews is not the only project which needs changes. Wikipedia,
Wikisource, Wiktionary, Wikibooks, Wikispecies, Wikiquote, and very
importantly, Wikicommons, would all benefit greatly from certain added
functionality. Whenever I go to a meetup, I hear from a dozen people about
all the new features which we need to make their projects, or projects
within a project, work. Often these ideas are really bad. That's why there
needs to be a gatekeeper process by which good ones are selected for
implementation.

Just because Wikipedia sort of works (even though we still don't have peer
review functionality after more than 4 years), we shouldn't start
slacking. We have half a dozen active developers at any given time. We
have hundreds of thousands of users and even more readers. We've tried
recruiting. Jimbo has given his speech at FOSDEM. There's more we can do,
but in part due to the growing complexity of MediaWiki, this imbalance can
ultimately only be addressed with one resource: money.

Regards,

Erik


from_name: Karl Eichwalder

body:
Yaroslav Fedevych <jaroslaw at linux.org.ua> writes:

> As I have mentioned -- if markup is minimal, there are worthier
> alternatives which permit 1:1 conversion... If {SG,X}ML is really
> needed.

I simply believe in standards - others do not.  And the rest refuses to
accept something not invented by themselves.

--
http://www.gnu.franken.de/ke/                           |      ,__o
                                                        |    _-\_<,
                                                        |   (*)/'(*)
Key fingerprint = F138 B28F B7ED E0AC 1AB4  AA7F C90A 35C3 E9D0 5D1C


from_name: Gregory Maxwell

subject: [Wikipedia-l] Autofellatio

body:
On Mon, 28 Mar 2005 12:54:17 +0200, Anthere <anthere9 at yahoo.com> wrote:
> I would like to raise a little issue.
>
> It is currently possible to do redirection from all projects to one
> project image.

I believe Interwiki redirects should be made soft, I think there is
some degree of consensus here, so I'm not going to comment on that
matter further... However:

[snip]
> Many months ago, we made it impossible to link to external images,
> because we were fighting to avoid the goatse.
> Now, several wikipedias are dirtied by the pornographic images available
> on the english wikipedia.
> So, I suggest that
> * either we all agree to share common images, since they can impact us
> and in this case, I would like that a common vote is held to decide the
> deletion of this image from the english wikipedia
> * or we agree that no local projects should be submitted to the
> editorial choices made by other projects and redirections between
> projects should be cancelled
> * or we find a filtering solution, so that certain images not welcome to
> other projects may not be redirected.
>
> In case of all sensible images such as the autofellatio, it should be
> the project choice whether to display it or not. And I think the
> multiplication of complaints on the topic requires to think about a
> viable solution for all of us.

Let me suggest the correct course of action:

If your interest is to censor encyclopedic content on any wikimedia
wikipedia, then your goals are at odds with the goals of the
foundation.  Because you do not share the same goals, you should fork
and produce your own project with censorship among it's goals.

If you continue to endorse censorship you are harming the project.
Please allow those who want to share knowledge freely the ability to
do so on wikipedia by taking your censorship someplace else.

The claim that pages are somehow 'dirtied'  by a mere image speaks
strongly about your lack of neutral perspective.

Wiki vandalism is unfortunate, but it is not a sufficient cause to
reduce the available knowledge and the free exchange of information to
mankind. It is not an excuse for censorship.


body:
Ray Saintonge wrote:

> Of course we've had unplanned downtime that has lasted for more than
> an hour. Then too en:wikipedia has so far resisted converting to
> Unicode. :-)

All I'm saying is that time is an important parameter, and that you
can calculate how much time will be needed, and set a limit to what is
acceptable (if it means downtime).

If you have lots of data (e.g. the English "old" table), it is often
an advantage if you can convert one piece at a time.  I guess this
could be done for converting the old table to Unicode.  You could add
column (or a separate table) that indicates if entry X of the old
table is in Unicode, alter the software to look in this column, then
start the conversion one article at a time as a low priority
background process.  After the conversion is completed, the software
can be altered back again.

That strategy would be the total opposite of defining a unified export
dump format and stop everything for a week to do a dump, convert, and
import.  Just like a pipeline and a tanker ship are two different ways
to transport oil.

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


from_name: Phil Sandifer

subject: [Wikipedia-l] Autofellatio

body:
On Mar 28, 2005, at 9:54 PM, Gregory Maxwell wrote:
>

> If your interest is to censor encyclopedic content on any wikimedia
> wikipedia, then your goals are at odds with the goals of the
> foundation.  Because you do not share the same goals, you should fork
> and produce your own project with censorship among it's goals.
>

You know Anthere is on the foundation board, right?

-Snowspinner


from_name: Jimmy (Jimbo) Wales

subject: [Foundation-l] german wikiquotes

body:
Walter van Kalken wrote:
> >Laws may very well restrict our activities, but there should be no
> >obligation to interpret them in the most restrictive way.  When a
> >particular law gives a ridiculous result, that is the time to see if
> >there are legal arguments available for interpretations that are more
> >favorable.
> >
> Not just that. May I remind people that German is not just spoken in
> Germany. Austria, Liechtenstein and Switzerland come to mind. So if it
> is not allowed under German law, but is under their law we could always
> make a writ that the de.wikiquote is meant for country xxx .

I'm learning German, and I live in the US.

The issue of which laws of which jurisdictions we need to worry about,
and to what degree, is a very complex one with no simple formulaic
answers.  For example, I think it is a good thing that the German
wikipedia is quite strict against fair use, because most re-users of
that work will be trying to distribute it in Germany, and relying on
the more liberal provisions of fair use/fair dealing that en.wikipedia
relies on would be unwise.

On the other hand, if something about German law made it impossible to
have a legal redistribution of Wikipedia in German *no matter what*
then we'd just have to ignore the law and build Wikipedia anyway,
knowing that redistribution within Germany will be problematic.

In the case of Wikiquote, I need to study the issue more carefully,
but I generally agree that the mere fact that redistributing the work
(or hosting it on servers in Germany) is problematic is no reason for
us to shut it down.  It's perfectly legal where it is.

At the same time, I think what we need to do is think really hard
about how to do what we want to do, within the confines of the law.
For example, it has been said that we can't quote "without context" --
ok, let's get a sense of what that means in reality.  What legal
arguments do German versions of Bartlett's rely on?  What kind of
context need we supply?

Maybe the solution is that de.wikiquote has to be a lot more strict
about detailed attribution and contextualization of quotes -- fine.

--Jimbo


subject: [Foundation-l] german wikiquotes


subject: [Wikipedia-l] Autofellatio

body:
1) Brion is on the case already. There's a code change in CVS that will
allow InterWiki redirects to show a "Redirected from" like regular
redirects.

2) Angela pointed out to me that even if the image was deleted from the
English Wikipedia, it could still be on any of the other wikis on the
InterWiki map (e.g. all Wikicities), all of which can be used for
InterWiki redirects. So you wouldn't just need a cross-Wikipedia deletion
or linking policy, but pretty much one across all wikis. That is clearly
not a workable solution.

3) The autofellatio image may be a case where many people agree that it is
inappropriate in any context, but many images which we clearly want, such
as the photos GerardM uploaded of venereal diseases, would be clearly
inappropriate on user talk pages. That doesn't mean such images should be
deleted.

We should simply consider this vandalism, and improve the tools we use to
deal with it. 1) helps a great deal already. Single login will also help,
as people will not suddenly be thrown into a wiki whose language they do
not speak once they have set their language user preference. We may,
however, want to consider disabling InterWiki redirects specifically for
non-Wikimedia wikis whose policies are beyond our control.

All best,

Erik


from_name: Lars Aronsson

body:
Ray Saintonge wrote:
> There has been much talk about XML, but it would be sheer pretence
> to suggest that I understand.any of it.  Nevertheless I will presume
> to speak as democratically unelected representative of the luddites.
> Many of us are happy to carry on with our familiar wiki markup and

In *this* thread (see Subject: Wiki import/export format), the
mentioning of XML was *not* related to the wiki markup.  Some people
apparently believed it was, but that was a mistake.

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


from_name: GerardM

body:
In doing maintenance and development there is this 80/20% rule. There
are things that make a huge difference to people doing the work in the
projects that do not cost much in developer resources. The one thing
that is really important that some triage is done on the bugs editted
in Bugzilla to find these little gems. Development is not only about
the big developments but also about the little ones.

One issue that then arises is do you want a fix or do you want the all
singing all dancing gizmo. I was really happy when commons arrived, it
is still not 100% as we want it to be but it makes a world of
difference in the practice of our projects. The latest update on the
upload page was brilliant, it just needs this increase in length for
the filename field and it would make my life easier.

There are other features like this. The thing is we do not always the
perfect code straight away because we have to learn what perfection
should look like and, we want some features badly.

So lets make things better but spend money on the strategic stuff,
particularly when developers feel an itch things things will be fixed
and when things are not fixed because it is NOT wikipedia let us have
it fixed and spend money to get us the 80% of what we desperately
need..

Thanks,
   GerardM

On 28 Mar 2005 22:27:00 +0100, Erik Moeller <erik_moeller at gmx.de> wrote:
> I am not aware of any serious discussions concerning a fork. DV suggested
> that video files might be best hosted on some external service, but I
> commented that Wikimedia has more than enough resources to do that, and
> that we mostly need to agree on which politically correct video codec to
> use. I strongly oppose both project and software forks for reasons that
> should be obvious.
>
> It is true that Wikinews is reaching the limits of human scaling. This is
> because we're getting so large that we will soon have to stop listing all
> stories on the Main Page, and will have to use separate index pages
> instead.
>
> When Wikinews started, I did set up such index pages for regions and
> topics. It already became clear during the demo phase that these are
> nearly impossible to maintain manually -- it's not a fun job, so it
> doesn't get done, especially because everyone with some small technical
> knowledge knows that a computer could do this.
>
> So, what's the solution?
>
> Since I'm the person Gerard spoke about who is going to implement
> structured data functionality over the next 3-4 months, my own resources
> are limited. However, I have offered in the past to act as a development
> task coordinator for the Wikimedia Foundation, and that offer still
> stands.
>
> Such a task coordinator would prioritize tasks, maintain contacts to
> potentially interested sponsors, and make recommendations on spending a
> certain part of our internal budget on development tasks. He would write
> the basic specifications, try to locate interested developers (both by
> inviting them directly, and by having public calls for tenders), watch
> over the implementation, and decide whether it meets the specs (together
> with the Board and the MediaWiki Release Manager, Brion Vibber).
>
> His Holiness JW III is not infinitely scalable. I believe I am well-
> qualified for the role in question, and it is something I would love to
> do. The WMF has hired Brion on a part-time basis. But that's not going to
> cut it. Brion has got his hands full making sure that all the crazy
> inventions by people like me actually work, fixing existing bugs, working
> on sponsor-specific tasks like OAI support for GuruNet, churning out
> releases, watching over scalability, and addressing high priority general
> project issues like single login.
>
> I strongly believe that a combined model of full-time employment for
> people like Brion, and task-based contracts for project-specific needs, is
> the only way forward.
>
> As for the specific needs Wikinews has, Ilya has already written a bit
> about that. I have a fairly good idea in my head how news feeds could work
> within MediaWiki in a scalable fashion. The question is, are we willing to
> spend the money to get this done?
>
> And Wikinews is not the only project which needs changes. Wikipedia,
> Wikisource, Wiktionary, Wikibooks, Wikispecies, Wikiquote, and very
> importantly, Wikicommons, would all benefit greatly from certain added
> functionality. Whenever I go to a meetup, I hear from a dozen people about
> all the new features which we need to make their projects, or projects
> within a project, work. Often these ideas are really bad. That's why there
> needs to be a gatekeeper process by which good ones are selected for
> implementation.
>
> Just because Wikipedia sort of works (even though we still don't have peer
> review functionality after more than 4 years), we shouldn't start
> slacking. We have half a dozen active developers at any given time. We
> have hundreds of thousands of users and even more readers. We've tried
> recruiting. Jimbo has given his speech at FOSDEM. There's more we can do,
> but in part due to the growing complexity of MediaWiki, this imbalance can
> ultimately only be addressed with one resource: money.
>
> Regards,
>
> Erik
> _______________________________________________
> foundation-l mailing list
> foundation-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>


from_name: Delirium

subject: [Foundation-l] german wikiquotes

body:
Walter van Kalken wrote:

> Not just that. May I remind people that German is not just spoken in
> Germany. Austria, Liechtenstein and Switzerland come to mind. So if it
> is not allowed under German law, but is under their law we could
> always make a writ that the de.wikiquote is meant for country xxx .

Not to mention that German is spoken by a non-zero number of people in
the United States, where the servers are hosted and where such
collections of quotes are legal...  (The same is true of Japanese and
most other languages.)

-Mark


subject: [Foundation-l] german wikiquotes


subject: [WikiEN-l] Re: Ultra slow again - preventing deletion and moves

body:
In addition my watchlist seems to perpetually consist of "Internal
error" .... I assume I am not the only one.


from_name: Sj

body:
This is a great discussion.

On 28 Mar 2005 22:27:00 +0100, Erik Moeller <erik_moeller at gmx.de> wrote:

> Since I'm the person Gerard spoke about who is going to implement
> structured data functionality over the next 3-4 months, my own resources
> are limited. However, I have offered in the past to act as a development
> task coordinator for the Wikimedia Foundation, and that offer still
> stands.

I would love to see your ideal priority-list and calendar for software
development over the next year.  (The same goes for the other active
developers)

> Such a task coordinator would prioritize tasks, maintain contacts to
> potentially interested sponsors, and make recommendations on spending a
> certain part of our internal budget on development tasks. He would write
> the basic specifications, try to locate interested developers (both by
> inviting them directly, and by having public calls for tenders), watch
> over the implementation, and decide whether it meets the specs (together
> with the Board and the MediaWiki Release Manager, Brion Vibber).

I have to repeat what I always say to suggestions like this :
rewarding a single person with a title and/or salary may entice that
person to do great work; it also creates a new bottleneck, and a
single person only scales so far.   In my experience, creating such a
titled person does not magically create a community of volunteers
eager to help with the goal in question, though I am not discounting
the possibility that this might happen.

We should address building this community spirit and focus, whether or
not one or two elevated roles are created to facilitate the process.
(My personal feeling is that we would do best to let our communities
of volunteers choose those who will have special power or authority;
and hire / appoint people to be stewards fulfilling community desires,
with obligations to be reliable and available, but no special
authority)

> I strongly believe that a combined model of full-time employment for
> people like Brion, and task-based contracts for project-specific needs, is
> the only way forward.

We might focus on identifying and defining tasks, and setting up an
infrastructure for sharing and claiming them, before we worry about
contracts.

> As for the specific needs Wikinews has, Ilya has already written a bit
> about that. I have a fairly good idea in my head how news feeds could work
> within MediaWiki in a scalable fashion. The question is, are we willing to
> spend the money to get this done?

This in particular  should not require money, considering how many
people are  in love with the idea of wikinews feeds.

> We've tried recruiting. Jimbo has given his speech at FOSDEM. There's more we can do,
> but in part due to the growing complexity of MediaWiki, this imbalance can ultimately
> only be addressed with one resource: money.

Nonsense.  Money is an excellent resource when properly applied, but
there is no fundamental reason why we should have fewer volunteer
developers than Linux has, for instance.  After all, what are we
writing but the kernel for our collective intelligence?

--SJ

PS - We could all recruit a *lot* more.  The lack of paid coordinators
can be a great selling point.  We had a meetup yesterday in Boston.
It was an last-minute "extra" meetup to discuss collaboration with
local libraries, Wikimania publicity, and Mediawiki hacking, and I
only promoted it a week in advance.  Two of the attendees wanted to
help out.  One of them, a long-time programmer, had only three
questions: "who are the people who decide what direction the project
takes?"  [Answer: everyone, even you]  "but who is paid to coordinate
everything?"  [Answer: No-one.  well, there is maybe one cool
exception...]  "Amazing...  how can I help?"  [Answer:  Let me send
you a few links... :) ]

--
+sj+


subject: [Wikipedia-l] Autofellatio

body:
[snip]
> Lastly, whatever the decision is, keeping the image or
> not keeping the image, this image has NOTHING to do on
> a user talk page.

Which is why I had carefully selected which part of your text I was
replying to...  I think the redirect problem can be solved and I
wasn't trying to discuss it further,  I think vandalism stinks thought
the existing methods work pretty well and new protections will come
overtime.... I wasn't trying to address the vandalism issue.

My concern was that you appear to be supporting the idea that due to
differences in cultural norms it is acceptable to censor content on
some wikipedias and not others.  If I have misunderstood you I
apologise.

It is my strongly held position that if you wish to censor, then you
are not in agreement with the ideals of the overall project and you
would be better off with your own fork.

> Who is "you" ???

Whomever you speak for that has decided that whatever language you are
editing needs a differing policy with respect to neutrality and
censorship than the more heavily trafficed wikipedias.

> May I suggest that the english wikipedia is NOT the
> Foundation. And that if I recognise the rights of the
> english wikipedia to decide itself what is good taste
> from what is bad taste, I do not recognise its right
> to decide alone what is censorship and what is not
> censorship. And I do not recognise its right to decide
> what should be on all the other projects from what
> should be absolutely.

Is there not a consensus that denying, by policy, the inclusion of
useful, informative, and encyclopedic information is censorship?

Of course everyone has a right to decide what you will add... but if
you wish to procedurally remove informative contributions because of
some non-neutral position, than you would be better off involved with
another project that includes such a non-neutral slant as part of its
charter.

> Asking that porn pictures be not displayed largely on
> user talk page is frankly not a question of
> censorship, it is a question of civility.

It's a question of vandalism, which is an issue I was specifically
trying not to address. Vandalism is bad, no argument.

> And when editors are complaining of large vandalism
> displaying porn pictures on their talk page, I think
> it would be good manner to recognise there is a
> problem and find a solution to it.

Agreed.

However, your proposals included censoring wikipedia. Not only would
this not solve your problem (bad guy just uploads the image under a
new name and you're even more shocked, because you cant just click the
firefox adfilter plugin option to block it forever if they keep
changing the name), but it is not an acceptable means for preventing
vandalism because it compromises the core goals of the project.

> I admire your ability to discuss an issue. I report 3
> different wikipedias complaints about large scale
> vandalisme, and your answer is "fork".

I admire your ability to discuss an issue. Three different wikipedias
have a problem with a class of vandalism which can be reduced by
simple technical/procedural means (soft redirects + three mouse
clicks), and your answer is to censor.

> There is currently strong support for deleting this
> image.

Throughout history there has been strong support for a lot of things
that we view in hindsight as very wrong. Neutrality is a core value of
these projects. By supporting this venture you are attempting to
impose your values on others, it's not neutral.   If we abandon this
goal in the favor of a few practical gains we abandon much of what
makes the project special.

> > Wiki vandalism is unfortunate, but it is not a
> > sufficient cause to
> > reduce the available knowledge and the free exchange
> > of information to
> > mankind. It is not an excuse for censorship.
>
> I do not think a talk page being replaced by
> pornographic pictures will reduce world knowledge. And
> I do not think a man sucking is cock being limited on
> one article only rather than thousand of pages will be
> a bad blow in free exchange of information.

Why do you now limit your remedies to talk pages?
In your initial message you proposed censoring the images available
for use in all wikipedias to be the least common denominator.   It
would hurt knowledge, and it wouldn't help your goal.   I'd attach a
copy of the image to this email to demonstrate how censoring wikipedia
doesn't protect you from unwanted content.... If you're that
concerned, you can browse with images off. (or use the firefox adblock
plugin to filter it with two mouse clicks).

> However, I do think that such reactions to other
> people opinions is a bad blow in wikilove that we
> should all try to respect.

I respect peoples feelings, but feelings are more transitory than
freedom and feelings are less universal than knowledge.  If the
project goals were amended to say that it is the primary objective to
make people feel good, then I would not be making the same argument
now.


subject: [Wikipedia-l] Autofellatio

body:
On Mon, 28 Mar 2005 20:49:15 -0800, Sean Barrett
> I find it admirable that you are so utterly certain that you know what
> the goals of the foundation are better than members of the Board of
> Trustees of the Wikimedia Foundation, and are so unhesitatingly willing
> to accuse those Trustees of harming your project, and are so quick to
> request that Trustees leave your project.
> Admirable, and very wrong.
> But admirable.
> Well, sorta.

Well better to judge the ideas than the speaker...

Or perhaps,  A lie told often enough can become the truth.
Sometimes the secret to change is to tell the right lies. ;)

In any case, I've read over and over that it explicitly not the goal
of the project to attempt to impose a set of arbitrary value
judgements on the work. Perhaps my interpretation of the matters is
wishful and lacking in accuracy, but I'd rather I state it strongly
and be rebutted strongly as that will bring about the deepest
understanding in the least amount of time.   In any case, it will
hopefully result in clear answers that will be useful in preventing
confusion in others later. :)


subject: [Wikipedia-l] Autofellatio

body:
> You know Anthere is on the foundation board, right?

Oh I knew. :)

But I think the ideas are wrong and at odds with the published goals.
If I do not misunderstand Anthere and the views are truly
representative and accepting censorship based on some peoples
non-neutral value judgements is acceptable ... then I think we should
discuss the matter, because I think a lot of people are misled by the
principal of neutrality 'as advertised'.


from_name: Stefan F. Keller

subject:
[Wikitech-l] Add evaluation param to action=raw and Special:Export
	page

body:
Hi

I added a comment to Bug 1012 and I thought I'd explain it here little bit
more. The problem:

When requesting category one will get the raw Wiki-text as a response which
will be like this in the case of
http://en.wikipedia.org/wiki/Category:Geography_by_country?action=raw (or
edit):

  [[Category:Geography|*Country, Grouped by]]
  [[Category:Categories by country]]
  {{catAZ}}
  ... some few lines more...

But what an API or a crawler would expect in this case is the fully
evaluated Wiki-text (or XML). This will be the same content of the HTML
result page but with no style and as a - potentially large - contiguous list
of countries (in Wiki-text or XML again).

I now have looked again what has been proposed until today and I found "Bug
208: API for external access" some requests at Wikitech-l like a
"Minimalistic Web-API for use by Tools nad Bots".

All alternative solutions proposed so far, like the Phyton Framework (being
a HTML screen scraper) or Perl (reading SQL-Dump) do not solve our problem.
So I really want to begin to play around with the Wikimedia-PHP code.

Any comments or help?

Stefan


from_name: Jakob Voss

body:
Lars Aronsson wrote:
> Ray Saintonge wrote:
>
>>There has been much talk about XML, but it would be sheer pretence
>>to suggest that I understand.any of it.  Nevertheless I will presume
>>to speak as democratically unelected representative of the luddites.
>>Many of us are happy to carry on with our familiar wiki markup and
>
> In *this* thread (see Subject: Wiki import/export format), the
> mentioning of XML was *not* related to the wiki markup.  Some people
> apparently believed it was, but that was a mistake.
>

But XML representation of wiki markup is what is needed while the
database dump is much more comfortable to handle as raw SQL as you
showed above.

Jakob