from_name: ciaran

subject: [Wikitech-l] Re: Unbelieveable 1.1.0

body:
Hello. I have further isolated this issue. Of course, it may be some
weird manifestation of Bug ID 802814
(http://sourceforge.net/tracker/index.php?func=detail&aid=802814&group_id=34373&atid=411192)...

but I am not sure.

Brion Vibber said the following on 2/25/2004 12:47 PM:

 > Probably nothing to do with memcache, as memcache is not used for links
 > in any way at present. Note that problems with link updates can be
 > caused by errors that occur at save time, which may be hidden by the
 > subsequent HTTP redirect to view the page. Try disabling the redirect
 > for debugging purposes. (Grep for 'Location:' and comment out the
 > header() call including it to disable automatic redirects.)
Perhaps the errors below are relevant (all other warnings occur during
page loads for all pages and they are attributed to OutputPage.php and
Setup.php). I have taken them from my php error log as suggested.

---
C:\DRIVES\IMAGO\PUB\public_html\www\yotz\wiki\LinksUpdate.php on line 230
[25-Feb-2004 19:03:45] PHP Notice:  Undefined variable:  fname in
C:\DRIVES\IMAGO\PUB\public_html\www\yotz\wiki\LinksUpdate.php on line 246
[25-Feb-2004 19:03:45] PHP Notice:  Undefined variable:  fname in
C:\DRIVES\IMAGO\PUB\public_html\www\yotz\wiki\LinksUpdate.php on line 247
[25-Feb-2004 19:03:45] PHP Notice:  Undefined variable:  fname in
C:\DRIVES\IMAGO\PUB\public_html\www\yotz\wiki\LinksUpdate.php on line 250
[25-Feb-2004 19:03:46] PHP Notice:  Undefined variable:
wgCommandLineMode in
C:\DRIVES\IMAGO\PUB\public_html\www\yotz\wiki\Setup.php on line 87
---

 > Are you using MySQL 3.x? If so, did you put $wgEnablePersistentLC   =
 > false; into LocalSettings.php?
 >
 > If not, could you check that the linkscc table is present?
The linkscc table is present. I am running mySQL 4.0.14 on Apache 2.0.47
  on a Windows XP-SP1 machine.

 > Can you confirm that links are not being updated, rather than cached
 > pages not being updated?
I have further established that links from the $wgSitename and
$wgSitename_talk namespace (only) do not update. I have this variable
set in LocalSettings.php and $wgMetaNamespace set to FALSE (in the same
file).

 >
 > Can you check your Apache error log for PHP error messages? Is PHP
 > configured to log error messages? What version of PHP are you running?
PHP 4.3.2.

This is not a cache issue; I am running Firefox 0.8 in both cache (25MB)
and no cache modes and have cleared my cache on several occasions to
verify the link status. If I edit the offending page (the one displaying
the red links) and save it, the links update.

Thanks.

ciaran


list: wikitech-l

source: pipermail-mbox

subject: [Wikitech-l] Re: Unbelieveable 1.1.0

body:
Erik Moeller said the following on 2/25/2004 12:49 PM:

 > You could try
 > $wgCachePages=false;
 > in LocalSettings.php. Does that help?
Browser caching is the first thing I checked. I set this variable in
LocalSettings to make sure, but the issue was unaffected. Please see my
reply to Mr. Vibber's post.

 > Are you logged in / logged out? Which browser are you using? Is your
wiki
 > public somewhere?
I am logged in, using Firefox 0.8 on Windows XP with zero cache. My wiki
is at http://yotz.zeromass.org/wiki (you left a message on it one time :)

Try editing the sandbox and then return to the main page. The sandbox
link does not update.

Thanks.

ciaran


subject: [Wikitech-l] Re: Unbelieveable 1.1.0

body:
Evan Prodromou said the following on 2/25/2004 3:04 PM:

 >     c> I really wish I hadn't "upgraded" to this recommended
 >     c> version. But I won't go into all the issues here.
 >
 > ...just quickly insult the people who made the software for you to
 > use, then ask for their help again.
Actually, if it was my intention to insult them, I wouldn't mention
something I wish _I_ hadn't done. I use the wiki to collaborate on
software development; it would be difficult for me to discount any
programming effort by another person or people.

Thanks for the caching suggestion. However, I think there is something
going on php- or db-wise.

ciaran


from_name: Lars Aronsson

subject: [Wikitech-l] Re: User-agent block list & Netscape 3

body:
Hunter Peress wrote:
> Theres 3 main cases where someone has an old browser:
>    3)They are in the third world.

The only reason a country is in the third world is because they are
completely clueless.  Why waste time on that?

Or is there something wrong with this kind of argument? Perhaps it is
the other way around: The only reason some websites fail to support
old browsers is because the maintainers are completely clueless.

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


list: wikien-l

from_name: Ray Saintonge

subject: [WikiEN-l] No forks! (was: Re: Print edition)

body:
Jake Nelson wrote:

>Even if we don't use this plan, we definitely want to keep them separate
>from normal articles. The print versions should be different, and we
>shouldn't freeze or delete normal articles for this. I'm not keen on a
>en-print.wikipedia.org type fork as was suggested, but it's at least an
>option.
>
There are many valid objections against a fork, but the strongest
argument for it may be simplicity.  Our thinking about the print version
needs to be a lot more production oriented.   Complicated new software
based solutions would be ill-advised.  Categories, have been discussed
before, but not implemented.  We have not had the opportunity to shake
out the bugs from category software or category schemes.  Production
time is no time to be doing that.  Maybe those categories will be
helpful for a later edition.  Six months is a very short time for
developing a print ready product.  We need to develop a strict time line
showing when certain steps absolutely MUST be completed.  There will be
little time in all that for software bugs or NPOV wrangles.  Wikipedia
as we now know it must continue to live without its purposes and
procedures being in conflict with those of the print version.

>Personally, eventually, I forsee three versions: the Pocket Wikipedia
>(basically the first-paragraph thing), the Concise Wikipedia (a big volume),
>and the Unabridged Wikipedia (pretty much the entirety of the web content).
>Concise will want pictures, but shouldn't overdo it.
>
This is conceivable, but we shouldn't let the first edition get hung up
on finding suitable pictures.  If we have them we use them, but we
shouldn't feel obliged to look for pictures if we don't have them.

Ec


list: wikipedia-l

from_name: Yann Forget

subject: [Wikipedia-l] New record on Alexa!

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

Le Friday 27 February 2004 18:37, Mark Christensen a ?crit :
> > BTW Why does Alexa do not rank wikipedia.org on
> > their ranking of Encyclopedias???
> > http://www.alexa.com/browse/general?catid=251&mode=general
>
> Because it is on the list of open content encyclopedias.
>
> http://www.alexa.com/browse/general?catid=50241&mode=general

And it seems that Wikipedia has reached a new record (traffic rank: 676).
http://www.alexa.com/data/details/traffic_details?&range=3m&size=large&compare_sites=&url=http://www.wikipedia.org#graph

Yann
- --
http://www.non-violence.org/ | Site collaboratif sur la non-violence
http://www.forget-me.net/ | Alternatives sur le Net
http://fr.wikipedia.org/ | Encyclop?die libre
http://www.forget-me.net/pro/ | Formations et services Linux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAP9msm4KYjQo0y9oRArv0AJ9BaWuviQ3VtjWoQNMAP2irVms+TwCdHwOG
AiWyCGMnE53Ae0NwV0BUbgw=
=gf08
-----END PGP SIGNATURE-----


from_name: Jeff Meyer

subject:
[Wikipedia-l] Re: WikiGIS perhaps? (was: Mapping complement
	toWikipedia?)

body:
Hi Daniel -
Isn't GRASS raster only? If so, are you thinking of that as one of several
options?
If not, cool, but will that make some interesting vector data inaccessible?
Thanks,
Jeff

"Daniel Mayer" <maveric149 at yahoo.com> wrote in
message news:20040228035231.5119.qmail at web12826.mail.yahoo.com...
> Jeff Meyer wrote
> >The plan is to deliver an easily searchable repository (content &
searchable
> >clearinghouse) of quality map content to cover the entirety of human
> >history. Along with it would be a freely distributable, open source map
> >player. People could then link their existing maps, add modifications,
build
> >new map content, etc.
>
> I happen to be finishing up my GIS credentials and geography/cartography
degree
> right now and was thinking about playing around with the free software
GRASS
> GIS program this summer. See http://grass.baylor.edu/ and the GRASS Wiki
> http://grass.itc.it/wiki2/
>
> It would be neat to tie GRASS into MediaWiki for map creation. I'll see if
I
> can get that to work later this year (at least for creating simple maps).
>
> There is a whole bunch of public domain GIS data out there (mostly in the
> U.S....). It would eventually be neat to have a place to do GIS editing on
the
> Internet to help maintain and extend those data. As it is, the public
domain
> GIS material created by the U.S. government is made into proprietary
products
> by GIS firms who clean up, extend, and then sell the data. AFAIK there is
no
> free content alternative.
>
> WikiGIS perhaps? I better snag that one... Done.  WikiGIS.org and
WIkiGIS.com
> are reserved for the Wikimedia Foundation if and when the foundation wants
> those domains.
>
> Which reminds me, Wikimedia.org is about to expire... I better fix that.
>
> -- Daniel Mayer (aka  mav)
>
> __________________________________
> Do you Yahoo!?
> Get better spam protection with Yahoo! Mail.
> http://antispam.yahoo.com/tools


from_name: Jake Nelson

body:
Daniel Mayer wrote:
> >Why not make it equivalent to a language Wikipedia?
> >We already have the 'Simple English' Wikipedia. The
> >other language type link on an article could tell you
> >the page had been selected (or moved).
>
> No offense, but this is a horrendously bad idea. We should instead focus
on
> adding a good category system and on writing articles in news style so
that the
> first section of each article is a concise article in its own right (I
call
> this the 'lead section').
>
> I also think that Simple was a bad idea as well since the lead section can
and
> should be written in language that can be understood by an average
person - no
> special knowledge of the subject area should be required to understand the
lead
> section.
>
> In addition, it would be nice to have the ability to mark particular
versions
> of articles as "ready for print" (via a sifter-like mechanism). Then when
the
> Concise Wikipedia script parses the database it would create concise
articles
> out of the lead sections of every article version that was marked 'ready
for
> print'. That would prevent any vandalism from entering the print edition.
>
> Thus we have no forks and no freezing of Wikipedia articles. We could also
> create an updated version of Wikipedia Concise with each database backup.
Such
> a thing would be great to have in a format that could be used by PDAs and
palm
> top PCs. Hm. MediaWiki Lite...

Personally, I'd like a 'Print version' (well, actually, that name isn't
great, as we already have 'Printable version' it'd easily get confused with,
but I don't have a better suggestion for example purposes) link on each
article page. This goes to a Print: namespace. For example, article Foo, the
print version link goes to 'Print:Foo'. I haven't decided whether a
'Talk:Print:Foo' would be good, or to just use the normal Talk page
(probably the latter). The pages in the Print: namespace are absent (red
link) until someone edits, when someone makes the first edit, they get the
text of the current article revision in the edit box (possibly with some
automated change, like piped links become a (see [[blah]]) after the linked
text). Deletion of Print: pages would leave the associated normal article
and talk pages intact.
'Wikipedia:' or 'Special:List of Print version articles' would be a good
thing to have, or something along those lines.
Even if we don't use this plan, we definitely want to keep them separate
from normal articles. The print versions should be different, and we
shouldn't freeze or delete normal articles for this. I'm not keen on a
en-print.wikipedia.org type fork as was suggested, but it's at least an
option.
Personally, eventually, I forsee three versions: the Pocket Wikipedia
(basically the first-paragraph thing), the Concise Wikipedia (a big volume),
and the Unabridged Wikipedia (pretty much the entirety of the web content).
Concise will want pictures, but shouldn't overdo it.
Anyway, my thoughts on the matter.

-- Jake


body:
Daniel Mayer wrote:

>>Why not make it equivalent to a language Wikipedia?
>>We already have the 'Simple English' Wikipedia. The
>>other language type link on an article could tell you
>>the page had been selected (or moved).
>>
>
>No offense, but this is a horrendously bad idea. We should instead focus on
>adding a good category system and on writing articles in news style so that the
>first section of each article is a concise article in its own right (I call
>this the 'lead section').
>
And who is going to have the time to verify that all the chosen articles
are written in "news style"?  Even if we limit ourselves to a mere
10,000 srticles it will be a horrendous task.

>I also think that Simple was a bad idea as well since the lead section can and
>should be written in language that can be understood by an average person - no
>special knowledge of the subject area should be required to understand the lead
>section.
>
I'm no great fan of the Simple project, but I have no incentive to
bother them in whatever they are doing.  Keeping the language simple is
easier said than done.  It's a fine ideal, but I can forsee a lot of
arguments over whether this or that has been put in simple terms.

Ec


from_name: Brion Vibber

subject: [Wikitech-l] MediaWiki 1.2.0rc1 release candidate

body:
MediaWiki 1.2.0rc1 is now available for download at:
https://sourceforge.net/project/showfiles.php?group_id=34373

This is a release candidate, and may contain a few rough edges still.
Those feeling adventurous, please try it out -- on a safe server after
backing up all your data -- and please report any exciting new
problems. If we don't hear about your problems, they'll never get
fixed!

A few notes:
* Things should again work out of the box with MySQL 3.x (though 4.x is
preferred).
* We are now compatible with short_open_tag = Off
* wiki.phtml and redirect.phtml have now become index.php and
redirect.php to improve compatibility. The old names are still
available for compatibility, so you don't have to change your
configuration for existing installs. If you're mixing other stuff in
with the wiki's install directory, please be sure this doesn't conflict
with other existing files!
* Installation now prompts you to ask if you want to create a sysop or
developer account and lets you pick the name and password instead of
using the AdminSettings.php defaults.
* A new page, Special:Version lists the MediaWiki, PHP, and MySQL
version numbers. Please don't forget to note these when reporting bugs!
We tend to track current production releases of PHP and MySQL, and
sometimes things break on older or experimental versions of these that
we don't always see.

Database messages are now on by default, you can turn this off if the
performance hit is too great. We hope to improve the speed of this
soon.

A couple things we don't have in yet:
* We don't yet have an installer that's friendly to those without shell
access, sorry. Hopefully we'll have something for 1.2.0 final.
* We still require register_globals = On.
* No PHP5 compatibility. I know there are a few keyword conflicts which
should be easy to fix, but we haven't tested this yet.

See the file RELEASE-NOTES for a bit on the new features and bug fixes.

You can report problems at SourceForge at:
http://sourceforge.net/tracker/?group_id=34373&atid=411192

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


subject:
[Wikitech-l] Possible bug: "The file /wiki/$ARTICLE" could not be
	found

body:
On Feb 28, 2004, at 00:50, Arvind Narayanan wrote:
> When I clicked on a link to [[Indian Institutes of Technology]] I
> got a popup saying: "Alert: The file
> /wiki/Indian_Institutes_of_Technology
> could not be found. Please check the name and try again later" or
> something like that. Repeated several times, same result. Didn't
> get this error on any other page. After a while I clicked on some
> link which redirected to [[Indian Institutes of Technology]], and
> it worked. Then I tried the original link and it worked too. Some
> cache problem?

Using Mozilla?

This unhelpful kind of error message tends to get spat out by Mozilla
when it has certain kinds of problems, such as a disagreement between
the content-encoding in its headers and its cached copy. Might well be
a cache problem; I'd recommend clearing out your browser cache to be on
the safe side; if you see it again, there may be something funky in the
squids or elsewhere.

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


body:
In CVS, the 1.2.0 stuff has been put onto the REL1_2 branch. You may
once again put experimental fun stuff into the head branch without
fear... :)

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


subject:
[Wikitech-l] Re: [Mediawiki-l] MediaWiki 1.2.0rc1 release
	candidate

body:
On Feb 28, 2004, at 02:10, M.Alberto wrote:
> On Sat, Feb 28, 2004 at 01:11:04AM -0800, Brion Vibber wrote:
>> MediaWiki 1.2.0rc1 is now available for download at:
>> https://sourceforge.net/project/showfiles.php?group_id=34373
> I would like to upgrade from 1.1.0 stable. What I have to do?
> Thank you.

1) backup everything!
2) Download and uncompress the tarball, above.
3) Copy in your AdminSettings.php and LocalSettings.php from 1.1.0
4) run 'php update.php'. This will make the necessary tweaks to the
database and install the updated PHP scripts.

If you're doing a manual install because the install script doesn't
work for you, you can upgrade manually:
1) backup everything!
2) Load patch-rc-newindex.sql and patch-ipb_expiry into your database
(via the mysql command-line client, or phpmyadmin, or whatever).
They're in the tarball under maintenance/archives.
3) Copy *.phtml index.php redirect.php LocalSettings.php includes/*.php
languages/*.php into the destination directory to update the scripts.
4) Copy stylesheets/*.css stylesheets/*.js into the style subdirectory
5) Copy images/*.png into the upload subdirectory
6) Hope things work... :)

You might also need to run rebuildMessages.php (in the maintenance
directory) to get the MediaWiki interface messages up to date.

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


from_name: Timwi

subject: [Wikitech-l] Re: Faster parsing

body:
Ivan Krstic wrote:
> Timwi wrote:
>
>> I'm not sure I fully understand what you mean by this. Apparently we
>> do update something like the "recentchanges" table on every edit,
>> because some people seem to have thought that it would make for better
>> performance, but I'm pretty much convinced that this assumption is
>> fallacious.
>
> I lay no claims to expertise in this area, but I'm (and I'm sure others
> are) more than willing to hear better proposals. How would you do it?

Do what? Recent Changes?

Currently, on every edit, among lots of other things, this happens:
- a row is inserted into "old" (involves a BLOB and several varchars)
- the row in "cur" is updated (also involves a BLOB & several varchars)
- another row is inserted into "recentchanges" (several varchars)

This is three operations for something that can be done in one. (Simply
insert a row into some generic table, 'articlerevisions' or somesuch.)
There is neither a reason for the cur/old split, nor is there a reason
for the 'recentchanges' table.

Now, of course the database schema I proposed would indeed require two
inserts (rather than just one) for this operation:
- one insert for the metadata (edit summary being the only varchar)
- one insert for the actual article text (the BLOB and nothing else)

However, this is not noticeably more costly than adding the same data
into one table that contains both (which is bad because then reading the
metadata when you don't need the article text is inefficient).
Furthermore, it means you don't lock an entire table with central
importance for quite as long.

Again, please let me stress that I do not claim to be an expert in this.
Although I have created database schemata in the past, I have not had
the benefit of testing them under load as heavy as that of Wikipedia.
However, a major contribution to my experience is my involvement at
LiveJournal, which is also a pretty heavily loaded website.

Timwi


subject: [Wikitech-l] Re: Faster parsing

body:
Ivo K?thnig wrote:

>>Using a database allows us to run a set of highly complex queries to
>>examine the relationships between articles and the metadata about
>>articles. In fact we can even examine the relationship between articles
>>and users (watchlist), or between the metadata of different articles
>>(redirect status in "What links here").
>
> This also can be done without a database. Of course in that case you have to
> implement the needet datastructure and can not use sql-queries.  This takes
> more time to develop, but you are free to code whatever datastructure you
> might think is the best. The try to emulate it by a db-structure can fail and
> even if you it does not fail you are slower since you have all the
> overhead-calculations the database produce since it wants to be as generell
> as possible.

You have not provided examples of "overhead calculations" that a DB
would have to perform that a file system wouldn't. You also haven't
provided evidence of your claim that DBMSs cannot represent the required
range of data structures.

There is a huge number of organisatorial tasks that you would need to do
with your files (when reading, that would be parsing the file, locating
data, possibly caching and perhaps sorting; when writing, that would be
updating indexes, managing "holes" in the file, and a huge host of other
horrendous things). Next, if your data structures are spread over
several files, you will have huge problems implementing atomicity, and
you will run into a number of race conditions.

DBMSs are specifically designed to do exactly these things. People often
tend to forget that DBMSs aren't really much more than systems that
manage files! But they have all these incredibly complicated and
advanced things in it that you need and you really really don't want to
have to re-implement from scratch.

For 99.9% of data you want to store, you *can* create *exactly* the data
structure you need using an RDBMS.

>>It is a fallacy that a database makes things more complicated. It makes
>
> I dont say this. It makes coding easier. But easy code is always slow...

It is pretty bold to think that you can do so much better (i.e. faster)
than the hundreds of thousands of experienced developers who have put
their effort into MySQL.

Timwi


subject: [WikiEN-l] Re: wikipedia access denied

body:
John Knouse wrote:

> Well.  I was right in the middle of a lengthy edit, and
> tried to save it, and got a message access denied.  I've
> tried multiple means of access.  Wikipedia seems to be
> somehow completely screwed up right now.  Fortunately, I had
> the (for me) atypical good sense to save the whole edit on
> my local computer before I lost it all.

If you are afraid of losing edits, you should probably think about using
a browser that doesn't eat them. I don't know what browser you are
using, but if it's Internet Explorer, it is known to eat submitted form
data frequently; this really isn't Wikipedia's fault or in any way under
Wikipedia's control.

I use Firefox. When Wikipedia is down, I just press Reload a few minutes
later and it will re-send my edit.

Timwi


subject: [Wikitech-l] Re: Faster parsing

body:
Timwi wrote:
> This is three operations for something that can be done in one. (Simply
> insert a row into some generic table, 'articlerevisions' or somesuch.)
> There is neither a reason for the cur/old split, nor is there a reason
> for the 'recentchanges' table.

Good thinking, could be worth trying.  However, you should consider
that the number of edits is far smaller than the number of reads.
And a read is a simple select from today's cur table.

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


subject: [Wikitech-l] Re: Faster parsing

body:
Lars Aronsson wrote:

> Timwi wrote:
>
>>This is three operations for something that can be done in one. (Simply
>>insert a row into some generic table, 'articlerevisions' or somesuch.)
>>There is neither a reason for the cur/old split, nor is there a reason
>>for the 'recentchanges' table.
>
> Good thinking, could be worth trying.  However, you should consider
> that the number of edits is far smaller than the number of reads.
> And a read is a simple select from today's cur table.

I know that; but you also need to consider that a write locks a database
table, a read does not.

Timwi


from_name: limholt at excite.com

subject: [WikiEN-l] Concise Print Wikipedia is a Fork

body:
Several discussion points have been made for or against the concept of a fork. But, regardless of method or desires, the proposed 'pedia will be a fork when it goes to print. The project being discussed can't alter this, the question is simply when and how to create the fork.

Daniel Mayer (Mav) hopes to use a 'print ready' condition or flag to allow the first section of an article to be picked up in the Concise version. This might be ideal, but I have serious doubts about doing it this way.

One example of the difference is in internal references (or q.v. entries). Even if the 'news style' first section approach is used, the first section of the full Wikipedia article would contain links to articles that don't exist in the concise version.

Another difference was raised by Mav himself, when he asked that 'we have no forks and no freezing of Wikipedia articles.' I give firm support to the idea that we should never freeze a Wikipedia article in the process of creating the Concise Print version. But the urgency of creating the print ready version imposes two areas of discipline. The first is (IMHO) that we will need to freeze an article as ready. The second was raised by Ray Saintonge (Ec), and that is that the project will probably need to restrict editing rights, something that we'd never want in Wikipedia.

When I wrote the first note about using the 'Language Wiki' method of creating a fork, I just assumed that the fork was going to happen. I think we ought to reach a clear consensus on that point before addressing the mechanics or the pro and con arguments about any given technique.

Lou Imholt (aka LouI)

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!


from_name: Daniel Mayer

body:
Jeff Meyer wrote:
>Isn't GRASS raster only? If so, are you thinking of that
>as one of several options? If not, cool, but will that
>make some interesting vector data inaccessible?

I think it used to be raster only, but I'm pretty sure it handles vectors
natively now.  But then, as I said, I haven't played with it yet (from what
I've seen it looks a lot like ArcInfo workstation - which I'm currently
learning).

>From http://grass.baylor.edu/general.html :
|GRASS (Geographic Resources Analysis Support System)
|is a raster/vector GIS, image processing system, and
|graphics production system

-- Daniel Mayer (aka mav)

__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools


body:
Jake Nelson wrote:
>Even if we don't use this plan, we definitely want to
>keep them separate from normal articles. The print
>versions should be different, and we shouldn't freeze
>or delete normal articles for this. I'm not keen on a
>en-print.wikipedia.org type fork as was suggested,
>but it's at least an option.

Why the hell does the print version have to be so different as to warrent a
fork in the content? All forks do is divide the workforce and multiply work to
update and extent articles - edits would have to be duplicated.

How is that a good thing? I'm sorry but I won't shut up on this point:

NO FORKS!

Call me a curmudgeon on this point if you like.

Ray Saintonge wrote:
>And who is going to have the time to verify that all the
>chosen articles are written in "news style"?

And who is going to have time to create tens of thousands of forked articles?
Who is going to have time to keep the print fork and the live fork in content
sync? Some human is going to have to reformat existing Wikipedia content to do
that under the ill-advised fork idea. Best to encourage the natural development
of articles toward news style so that the lead sections can be concise
articles. Then all a human has to do is mark a specific version as ready for
print - no additional work is required so long as that version is already in
news style. This in fact is already the case for many, if not most, of our most
well-developed articles.

We should encourage that.

-- Daniel Mayer (aka mav)

__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools


from_name: David Speakman

subject: [WikiEN-l] Trading with the Enemy

body:
This doesn't apply to WP for 2 reasons:
1. WP authors give up all rights to the public domain. Once it is
uploaded onto the WP servers it no longer is a work belonging to any one
person.
2. Trade requires that the writer gets money or other tangible goods in
exchange for services. WP is one way.

-----Original Message-----
On Behalf Of Fred Bauder
Sent: Saturday, February 28, 2004 5:44 AM
To: wikien-l at Wikipedia.org
Subject: [WikiEN-l] Trading with the Enemy

Editing material which originates in Iran, North Korea, Cuba and other
nations with which most trade is banned without a government license may
be illegal. It is interpreted as aiding the enemy. No corrections of
spelling or grammar would be allowed under this interpretation, only use
of camera ready copy. Theoretically correcting a spelling mistake by
Osama ben Ladin would fall into this category of crime.

This potentially affects us as we can in the routine conduct of
business, without even knowing, accept imput from these nations, from a
user who simply appears to be an ordinary user.

One could interprete this to apply only to input the origin of which is
clearly identified.

http://www.nytimes.com/2004/02/28/national/28PUBL.html?th

New York Times login required

Fred

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


body:
>One example of the difference is in internal references
>(or q.v. entries). Even if the 'news style' first section
>approach is used, the first section of the full Wikipedia
>article would contain links to articles that don't exist in
>the concise version.

Oh come on. That is easy to fix - don't mark what would be dead links in a
concise version as anything special. This could be done automatically.

>Another difference was raised by Mav himself, when he
>asked that 'we have no forks and no freezing of Wikipedia
>articles.' I give firm support to the idea that we should
>never freeze a Wikipedia article in the process of creating
>the Concise Print version. But the urgency of creating the
>print ready version imposes two areas of discipline. The first
>is (IMHO) that we will need to freeze an article as ready.

Sifter software has already been written that exports the current article
version of selected articles to another site. It is therefore a fallacy to
think that freezing the article is the only option. Just edit the Wikipedia
article into news style and then select the resulting version as ready for
print. Let a script take care of the rest (removing everything but the lead
section, converting links to something that would work in print, removing what
would be empty links, etc.).

>The  second was raised by Ray Saintonge (Ec), and that
>is that the project will probably need to restrict editing
>rights, something that we'd never want in Wikipedia.

Only give selected people the ability to use the sifter software. Fixed without
the need for a fork or freezing Wikipedia content.

>When I wrote the first note about using the 'Language Wiki'
>method of creating a fork, I just assumed that the fork was
>going to happen.

So long as I'm still breathing I will strenuously fight against any
Wikimedia-sponsored fork.

-- Daniel Mayer (aka mav)

__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools


from_name: Jimmy Wales

subject: [WikiEN-l] Trading with the Enemy

body:
http://www.nytimes.com/2004/02/28/national/28PUBL.html

I just assumed that Fred was joking or exaggerating about what this
story says.  But he's reporting it accurately.

I will say that we should cautious about believing all the quotes in
the story.  One of the scholars quoted suggests that this sort of
editing "would constitute aiding and abetting the enemy".  I very much
doubt if that's accurate.  I don't think that violating a trade
embargo would lead to that sort of charge (treason) exactly.

As for me personally, I intend to just plain and simple ignore this as
bureaucratic fantasy.  I can't imagine this passing constitutional
muster for even a second.  I defy the government to bring a case
against me or any of you or the Wikimedia Foundation over this.
They'll look like complete idiots and be laughed out of court.

--Jimbo


subject: [WikiEN-l] Trading with the Enemy

body:
David Speakman wrote:
> 1. WP authors give up all rights to the public domain. Once it is
> uploaded onto the WP servers it no longer is a work belonging to any one
> person.

This is not true.  Where did you get that idea?  You should probably
study up on the differences between the GNU FDL and "public domain".

> 2. Trade requires that the writer gets money or other tangible goods in
> exchange for services. WP is one way.

That isn't what the story says.  But if you're right, that's great,
although it tempts me personally to find and pay an author in one of
those countries $1 to contribute to Wikipedia, and then to edit it.

I'll ask Larry Lessig and Eugene Volokh (both 1st Amendment scholars)
to comment on this.


body:
Mark Pellegrini wrote:
>The print-version page could, in many cases,
>simply be the first paragraph of the main article.

Then use it directly and IMPROVE Wikipedia articles that are not in news style
so that their lead sections could be used in a concise version. See my last
email talking about sifter.

-- mav

__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools


body:
Daniel Mayer wrote:
> So long as I'm still breathing I will strenuously fight against any
> Wikimedia-sponsored fork.

Me, too, so let's not sweat about that part too much.

I'm not yet convinced that there's any need for it, but we really need
some wordcount statistics to have a grasp of what would be needed.

--Jimbo


from_name: Fred Bauder

subject: [WikiEN-l] Trading with the Enemy

body:
Editing material which originates in Iran, North Korea, Cuba and other
nations with which most trade is banned without a government license may be
illegal. It is interpreted as aiding the enemy. No corrections of spelling
or grammar would be allowed under this interpretation, only use of camera
ready copy. Theoretically correcting a spelling mistake by Osama ben Ladin
would fall into this category of crime.

This potentially affects us as we can in the routine conduct of business,
without even knowing, accept imput from these nations, from a user who
simply appears to be an ordinary user.

One could interprete this to apply only to input the origin of which is
clearly identified.

http://www.nytimes.com/2004/02/28/national/28PUBL.html?th

New York Times login required

Fred


from_name: Daniel P.B.Smith

subject: [WikiEN-l] Print version skepticism, negativism...

body:
I will follow with great interest the print version project. I would
never have expected Wikipedia itself to work as well as it does so I
hope to be pleasantly surprised and that the negativism I am about to
spew will turn out to be utterly misguided. However...

I suspect that producing a print version will magnify many of
Wikipedia's weak points and minimize many of its strong points. One
point about web Wikipedia is that there is no overview, and
consequently the variation in style, quality, and depth of coverage is
not directly obvious. Flipping through a print book will make this much
more apparent.

Another problem is that producing a respectable-looking print version
will, I think, require a high degree of selectivity and quality control
and a fairly rigid approval process by editors who in turn will have to
be approved... and articles frozen after approval. That is, exactly the
opposite of the Wikipedia creation process.

Another problem is that I think that to come up to peoples' expectation
in print versions, a large fraction of the output will have to be
actively edited (for tyops, repeated words words, and to fully
complying with grammatical and language standards). Will people stand
for a mixture of British and American spelling? How many minutes per
article will it take to copyedit to print-Wikipedia standards.

And despite the perfectly clear disclaimer on the every edit page that
explains that you are donating your work, I suspect that some people
who see the work they did for free appear in a bookstore with a price
tag on it will be upset. And I think copyright violations could be a
minefield. Do you think every single one will be caught? Whatever the
theory, I expect that in practice the consequences of a copyright
violation in a print version will be more serious than on the Web. What
if some print encyclopedia company were to act like SCO and assert that
they have found tens of thousands of individual sentences lifted from
their print version by hundreds of contributors (and that they won't
tell anyone which they are?) Even assuming their case is no stronger
than SCOs it could be a substantial nuisance.

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


body:
Jimbo wrote:
>I'm not yet convinced that there's any need
>for it, but we really need some wordcount
>statistics to have a grasp of what would be
>needed.

As of Feb 26, 2004 there were 66.7 million words in the English Wikipedia
(217,000 articles; 2214 characters/article).
Source: http://www.wikipedia.org/wikistats/EN/Sitemap.htm

Encyclop?dia Britannica's 2002 edition (a full general encyclopedia) has 55
million words (85,000 articles; 3882 characters/article).
Source: http://en.wikipedia.org/wiki/Wikipedia:Size_comparisons

Columbia Encyclopedia, Sixth Edition (a concise encyclopedia) has a word count
of 6.5 million words (51,000 articles;  765 characters/article).
Source: http://en.wikipedia.org/wiki/Wikipedia:Size_comparisons

-- Daniel Mayer (aka mav)

__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools


subject: [WikiEN-l] Trading with the Enemy

body:
The original author still has a copyright although it is licensed through
the GNUFDL. Most material on Wikipedia is not in the public domain.

Fred

> From: "David Speakman" <david at speakman.com>
> Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
> Date: Sat, 28 Feb 2004 06:05:16 -0800
> To: "'English Wikipedia'" <wikien-l at Wikipedia.org>
> Subject: RE: [WikiEN-l] Trading with the Enemy
>
> 1. WP authors give up all rights to the public domain. Once it is
> uploaded onto the WP servers it no longer is a work belonging to any one
> person.


body:
Here's a belly laugh. He's over at Wikinfo now and after proposing a
permanent ban at Wikipedia I have to welcome him and give him a fair chance.

He started with September 11, 2001 attacks.

Expecting a miracle...

Fred

> From: Sheldon Rampton <sheldon.rampton at verizon.net>
> Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
> Date: Sat, 28 Feb 2004 08:16:23 -0600
> To: wikien-l at Wikipedia.org
> Subject: [WikiEN-l] Re: Plautus was kicked off this list
>
> Jimbo wrote:
>
>> He seems to think that somehow Disney is behind all this, among a
>> number of other interesting theories about people using pre-arranged
>> and encrypted signals, etc.
>
> LOL...at least we got one halfway decent chuckle out of the guy...
>
> --Sheldon Rampton
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l


from_name: Sheldon Rampton

subject: [WikiEN-l] Re: Plautus was kicked off this list

body:
Jimbo wrote:

>He seems to think that somehow Disney is behind all this, among a
>number of other interesting theories about people using pre-arranged
>and encrypted signals, etc.

LOL...at least we got one halfway decent chuckle out of the guy...

--Sheldon Rampton


from_name: Elly Waterman

body:
"Daniel Mayer" <maveric149 at yahoo.com> schreef
in bericht news:20040228035231.5119.qmail at web12826.mail.yahoo.com...
> Jeff Meyer wrote
> >The plan is to deliver an easily searchable repository (content &
searchable
> >clearinghouse) of quality map content to cover the entirety of human
> >history. Along with it would be a freely distributable, open source map
> >player. People could then link their existing maps, add modifications,
build
> >new map content, etc.

I also think that a wikiGIS would be the most up to date manner to set up a
site of maps. The problem is most users will not be aware of the enormous
power of GIS methods to produce and edit maps. It takes some time to getting
to know the software (but it can be done, even if you are above 40).

In the Netherlands, most GIS data are owned by publicly funded
organisations, but cannot be used freely. To the contrary these data a very
expensive.

Elly Waterman


subject: [WikiEN-l] Print edition hurdles

body:
Mark Pellegrini (Raul654) on Feb. 28 described four hurdles to the Concise Print Wikipedia. To address them one at a time:

>A) Articles in en.wikipedia must not be frozen (or this would kill >the Wikipedia project), but must be stable enough that they can be >verified a print-ready.

Agreed, and so far no one has disagreed.

>B) Weblinks and interlinks have to be removed from our print >articles, but not from our regular database.

This has to be addressed in two parts. Weblinks could be retained in a printed Wikipedia. our current 'Printable Version' option does this, keeping any Wikipedia description and following it with the Web address. I have a number of books that include Web addresses. This doesn't decide if Web addresses are desirable in the Wikipedia Concise Encyclopedia (WCE). Even if kept, it would have some standard about ephemeral web pages compared to those that are fairly static and reliable.

Interlinks need only be removed if the article linked is not included in the WCE. I have seen Encyclopedia's where other articles are indicated by highlighted text, besides the more traditional 'q.v.' entry. Points previously raised about 'piped' links and redirects remain valid.

> C) While Wikipedia is not paper, a printed version is. Wikipedia >doesn't have to be concise, but a printed version does. By the same >token, electronic Wikipedia doesn't have to define terms very >precisely when interlinks can be used, but a paper encyclopedia, to a >larger degree, should. So we absolutely cannot just copy the articles >as they exist in the en database.

Yes, the Concise (or WCE) version must in some cases differ from Wikipedia. And I agree we can't just copy articles (never without inspection and consideration, but some might make it without change). As to definition of terms, an Encyclopedia, even a WCE, is not a dictionary.

>D) Forks, with the inevitable loss of efficiency that occurs from >repeated efforts, are always bad.

Yes,,,, BUT .. This becomes part of the decision as to whether to proceed, and if affirmative, whether the project succeeds or fails. I would expect a successful project to make some scope and manpower estimates, recruit (and/or authorize) volunteers, develop and adhere to a schedule. In some cases activities, (e.g. supply missing articles) would also benefit the normal 'en:Wikipedia'. But, in some cases volunteers will be giving up some of their normal Wikipedia time. With 5,000 users (abut 500 fairly active), the question becomes: 'Is the benefit of a printed CWE greater than the value of the lost contributions'? I suggest that each volunteer will need to come up with their own answer.

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!


from_name: Evan Prodromou

subject:
[Wikipedia-l] > 230 request/second - but no Wikipedia news on
	slashdot ; ) what is this?

body:
>>>>> "JW" == Jimmy Wales <jwales at bomis.com> writes:

    JW> I have written to them about this, but you know how dmoz is,
    JW> not always responsive.

A very diplomatic understatement, that.

~ESP

--
Evan Prodromou <evan at wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide


body:
Daniel Mayer wrote:
> As of Feb 26, 2004 there were 66.7 million words in the English
> Wikipedia (217,000 articles; 2214 characters/article).  Source:
> http://www.wikipedia.org/wikistats/EN/Sitemap.htm

> Encyclop?dia Britannica's 2002 edition (a full general encyclopedia)
> has 55 million words (85,000 articles; 3882 characters/article).
> Source: http://en.wikipedia.org/wiki/Wikipedia:Size_comparisons

> Columbia Encyclopedia, Sixth Edition (a concise encyclopedia) has a
> word count of 6.5 million words (51,000 articles; 765
> characters/article).  Source:
> http://en.wikipedia.org/wiki/Wikipedia:Size_comparisons

Something seems slightly odd with your numbers, because this gives
an average word length for Britannica and Columbia of 5.999 and 6.002,
but an average word length for Wikipedia of 7.200.

I suspect that the oddity here is that I'm multiplying
characters/article by articles to get total number of characters, but
probably the 217,000 is a count by some other means than "raw"?

Anyhow, no matter, as the discrepancy is minor and can surely be
resolved with a little tweak.  (Or, perhaps it's true that we use
bigger words on average?)

[WAIT: I see the trouble.  I just read the source article, and I see
that the reason for the discrepancy is that the characters/word figure
was estimated for Britannica and Columbia.]

Here's what I wonder...

The essential question for us is whether we can slim down to
Columbia's size primarily by leaving out articles, rather than by
editing existing articles down to size.  If we can, that's huge,
because the process then becomes *primarily* a matter of selection,
and not a matter of huge rewrites.

This keeps the "forkage" down to an absolute minimum, imposes the
least burden on the community, and might make for a very interesting
result.

--Jimbo


subject: [WikiEN-l] Cool project for perl programmer

body:
To compare Wikipedia to Columbia Encyclopedia...

http://www.encyclopedia.com/

has the full text of Columbia.

There are pages for alphabetic browsing.

http://www.encyclopedia.com/browse/browse-Aa.asp

>From these pages, it should be possible to get a list of all their
article titles.

These could be matched up against Wikipedia article titles.

Then we could ask the hypothetical: suppose Wikipedia just snagged the
same 55,000 topics as Columbia?  How big would the resulting text be?

If the answer is in the ballpark of 6,500,000 words -- i.e. the same
size as Columbia - then we have an obvious strategy.  If, as I would
imagine, the answer is that we're bigger, then we can start digging
into how many of our longer articles would have to be edited down in
order to hit the same "ballpark".

Note that we don't have an answer from a publisher as to how big we
can be.  The guy I talked to expressed a desire to be "as big as
possible" but I warned him that that's a limitation that's going to
come from their end, not ours, because we're already bigger than
Britannica, so our issue is how to get *small enough*, not how to
produce *enough*.

--Jimbo


subject: [Wikitech-l] Cool project for perl programmer


subject: [Wikipedia-l] 500,000 milestone is here!

body:
Andrew Lih wrote:
> One of the most standard outlets for press releases is PR Newswire.  It
> costs some money to put it on there, but we can investigate the cost and
> see if it's worth it.

I once paid $1200 for a press release about Nupedia that ended up
being basically a waste of money.

Of course, as Wikipedia gets bigger and has name recognition already,
a press release can be more powerful.  If a release on PR Newswire gets
it in front of journalists who are interested anyway, that's likely to
generate a fair amount of follow-on interest.

--Jimbo


subject: [WikiEN-l] Columbia and Copyright

body:
Martin Harper wrote:
> > There are pages for alphabetic browsing.
> > http://www.encyclopedia.com/browse/browse-Aa.asp
>
> > Auppose [the Wikipedia print edition] snagged the
> > same 55,000 topics as Columbia?  How big would the resulting
> > text be?
>
> Wouldn't selecting the exact same 55,000 topics as Colombia be a possible
> copyright infringement? Choosing an appropriate selection of topics for a
> concise encyclopedia is a creative act...

I don't know, but that wasn't my proposal.  We absolutely must
exercise our own editorial judgment, and not just for legal reasons,
but because we're going to be a lot *better* than existing
encyclopedias.

To be perfectly clear, the point of this exercise is to guide us with
solid information as to the feasibility of "slimming down" by
selecting articles, rather than by editing articles.

Clearly, we will have to do some of both.  We have 10x as many words
as they do, and 4x as many articles.  It would not make sense, in my
opinion, to try to retain our breadth of coverage by editing every
article down to size.  It would probably not make sense, either, to
try to retain our depth of coverage by just omitting articles and not
doing any editing down.

But my hope here is that we might find that on the exact same topics
as they cover, we have 12,000,000 words, and that actually our overrun
comes from 10% of the articles that are huge compared to theirs.  Or
something like that.

So we could learn that it's possible to select topics to get similar
coverage to theirs, and then edit down only 5,500 articles, and end up
with a book that's only a little bigger than theirs.

Or, we might learn that the entire approach is hopeless, that all of
our articles are so much bigger than theirs that we absolutely must do
a ton of editing.

But I do NOT propose that we simply run off an exact copy of their
list of articles.  I doubt if it would be any sort of legal violation,
but more importantly, I think that their list is flawed and that we
can improve on it.

I'm just trying to get some estimates of what it is that we need to
do, estimates based on actual numbers rather than conjectures.
(Although, of course, at this early stage, conjectures are welcome!)

--Jimbo


body:
Daniel P.B.Smith wrote:
> Another problem is that producing a respectable-looking print version
> will, I think, require a high degree of selectivity and quality control
> and a fairly rigid approval process by editors who in turn will have to
> be approved... and articles frozen after approval. That is, exactly the
> opposite of the Wikipedia creation process.

I think it's important to combat this notion repeatedly until it dies.
:-) I do not anticipate in any way "freezing" articles.  Development
on Wikipedia can and should continue as always.

What I envision is pointers-to-versions rather than freezes or forks.

Just to be clear, because I've spoken firmly against forks earlier
this morning, there will of course have to be some very minor and last
minute "fork" in the sense of final formatting and copyediting.  Let's
say we deliver a product such that the print publisher needs to cut
out a few dozen pages in order to fit some print constraints -- that's
going to happen after we've handed it over to them, and will be a
minor fork in that sense.

I'm hopeful for now that we can produce this thing without needing to
do massive rewrites of 50,000 articles.  I'm hopeful that we can meet
the size constraints mostly by selectivity of which articles to
include.

--Jimbo


subject: [Wikitech-l] Deleting page histories

body:
I think that this is pretty important, too.  Can you please raise the
license issue gently over there?  It's better to keep a copyvio around
in the page history for a little while, until a developer can delete
it by hand, than to do what they are doing.

Your idea for a feature is a very good one, too.

Timwi wrote:

>
> It has just been brought to my attention (well, rather: I found out)
> that on the German Wikipedia, if someone submits a text that constitutes
> a copyright violation, the sysops there immediately delete the complete
> page history and reinstate the most recent version before the copyvio.
>
> This is a pretty serious issue; I'm pretty sure that this is not
> GFDL-legal (while, obviously, keeping the copyvio in the page history
> isn't either); it removes legitimate contributions from legitimate
> users; and less seriously, it messes up statistics.
>
> I am therefore strongly suggesting that someone add a feature whereby a
> sysop can delete a single previous revision, rather than the entire
> history of a page.
>
> It would probably suffice to delete just from the 'old' table; if you
> want to delete the most current revision, you should probably revert to
> an older version first anyway, thereby moving the one you want to delete
> to the 'old' table.
>
> Timwi
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


subject: [WikiEN-l] Trading with the Enemy

body:
Absolutely.

Sean Barrett wrote:

> > http://www.nytimes.com/2004/02/28/national/28PUBL.html
> >
> > I just assumed that Fred was joking or exaggerating about what this
> > story says.  But he's reporting it accurately.
>
> Nyarly H. Hotep on a rubber raft.  Does anybody have an Iranian
> article I can edit?  I'm willing to stand up and be a test case if
> WikiMedia is willing to be my publisher.
>
> --
>  Sean Barrett
>  sean at epoptic.com
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Sean Barrett

subject: [WikiEN-l] Trading with the Enemy

body:
> http://www.nytimes.com/2004/02/28/national/28PUBL.html
>
> I just assumed that Fred was joking or exaggerating about what this
> story says.  But he's reporting it accurately.

Nyarly H. Hotep on a rubber raft.  Does anybody have an Iranian
article I can edit?  I'm willing to stand up and be a test case if
WikiMedia is willing to be my publisher.

--
 Sean Barrett
 sean at epoptic.com


from_name: D.I. Redhouse

body:
On Sat, 28 Feb 2004, Jeff Meyer wrote:

> Isn't GRASS raster only?

No:

     http://grass.itc.it/

--
David Redhouse, Department of Archaeology, University of Cambridge
0791 9058197       dir21 at cam.ac.uk      http://www.arch.cam.ac.uk/


from_name: Erik Moeller

subject: [Wikitech-l] Re: Unbelieveable 1.1.0

body:
ciaran-
> Try editing the sandbox and then return to the main page. The sandbox
> link does not update.

I got a linkscc-related SQL error message on the first save. The page was
saved regardless, but the table wasn't updated. I would try setting
 $wgEnablePersistentLC   = false;
in LocalSettings.php

Regards

Erik


subject: [WikiEN-l] Print edition - Publisher Discussion Points

body:
Some of these have been raised before, I've included them again. Others are new, and the list is in no particular order or implied importance.

1. Dates - when does a final 'first draft' need to be at the publishers? There are sub-points:

1.A. - If we miss that date but deliver a worthwhile product, do they still want to publish? Or do they want to wait to Holiday's 2005?

1.B - If they don't pursue do we (Wikimedia or a sub) have right to shop for another publisher?

1. C. - Penalty for non-performance?

2. For talking purposes: What is their view of final size and scope: Number of Articles, Pages, Words?

3. We will, of course, keep each finished article on-line. And may update them after publication.

4. Does Wikimedia keep rights to republish 2nd (3rd....) edition? On what terms do we extend the contract?

.5. How often may publisher reprint without updating? I don't think either party would want to see a January, 2005 reprint that still lacked 2004 election results.

6. Formatting of delivered material? PDF, MS-Word, etc.?

7. Tentative schedule and turnaround for proofs, galleys, etc.?

8. A Formal title (e.g. Wikipedia Concise Encyclopedia, Wikimedia C E, etc.). My suggestion is that the Wikipedia or Wikimedia name stays first, and we keep rights to any other names such as the Wikimedia Almanac.

9. Intended primary audience: U.S. or wider, what about Canada, U.K., Australia, etc.? To a certain extent this will influence the choice of articles.

Just a summary so far.

Lou Imholt (aka LouI)

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!


from_name: John C. Penta

subject: [WikiEN-l] Trading with the Enemy

body:
Your government does not matter. The servers are in the US, and the US Government thus matters.

----- Original Message -----
From: Charles Matthews <charles.r.matthews at ntlworld.com>
Date: Saturday, February 28, 2004 9:28 am
Subject: Re: [WikiEN-l] Trading with the Enemy

> Fred Bauder wrote
>
> > Editing material which originates in Iran, North Korea, Cuba and
> other> nations with which most trade is banned without a
> government license may
> be
> > illegal. It is interpreted as aiding the enemy.
>
> Perhaps by your government - I doubt it is by mine.
>
> Charles
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Ivo Köthnig

subject: [Wikitech-l] Re: Faster parsing

references:
<93fCM9PhpVB@erik_moeller> <200402271619.02257.koethnig@web.de>
	<c1p1hb$4bp$1@sea.gmane.org>

body:
Am Samstag, 28. Februar 2004 04:22 schrieb Timwi:
> Ivo K?thnig wrote:
> >>Using a database allows us to run a set of highly complex queries to
> >>examine the relationships between articles and the metadata about
> >>articles. In fact we can even examine the relationship between articles
> >>and users (watchlist), or between the metadata of different articles
> >>(redirect status in "What links here").
> >
> > This also can be done without a database. Of course in that case you have
> > to implement the needet datastructure and can not use sql-queries.  This
> > takes more time to develop, but you are free to code whatever
> > datastructure you might think is the best. The try to emulate it by a
> > db-structure can fail and even if you it does not fail you are slower
> > since you have all the overhead-calculations the database produce since
> > it wants to be as generell as possible.
>
> You have not provided examples of "overhead calculations" that a DB
> would have to perform that a file system wouldn't. You also haven't
> provided evidence of your claim that DBMSs cannot represent the required
> range of data structures.

That starts with parsing and transforming a sql-statement into an expression
of relational algebra (which can not always produce the optimal (fastets)
expression) and ends by the point that you are restricted to these
expressions which can be handeled only step by step (operation always on the
huge table).

> There is a huge number of organisatorial tasks that you would need to do
> with your files (when reading, that would be parsing the file, locating
> data, possibly caching and perhaps sorting; when writing, that would be
> updating indexes, managing "holes" in the file, and a huge host of other

that is no problem if you use good datastructures...

> horrendous things). Next, if your data structures are spread over
> several files, you will have huge problems implementing atomicity, and
> you will run into a number of race conditions.

That is a good point and one of the points I wanted to hear from you to
convince me.

> DBMSs are specifically designed to do exactly these things. People often
> tend to forget that DBMSs aren't really much more than systems that
> manage files! But they have all these incredibly complicated and
> advanced things in it that you need and you really really don't want to
> have to re-implement from scratch.

Yes, but you don't want to implement each of that features.

> For 99.9% of data you want to store, you *can* create *exactly* the data
> structure you need using an RDBMS.

By data structure I am not only mean the structure of data. I also mean the
code which belongs to it to handle it (For example heaps, sorted lists and so
on). The structure for the data surly can be created but not the code...

But yes: Indexing and sorting is something the dbms (hopefully) can handle
perfectly... (But on the other hand sorting and indexing can be implemented
very easy)

> >>It is a fallacy that a database makes things more complicated. It makes
> >
> > I dont say this. It makes coding easier. But easy code is always slow...
>
> It is pretty bold to think that you can do so much better (i.e. faster)
> than the hundreds of thousands of experienced developers who have put
> their effort into MySQL.

The reason ist not that I can code much better (and I never told this). The
argument was that we (may) don't need this general piece of software. Of
course hundreds of thousands of experienced developers who have put
their effort into MySQL can implement a better MySQL. But we also don't use M$
Windows just because hundreds of thousands of (may or may not) experienced
developers coded there some functions we may could use.

I really just asked why we use it and what the advantages are. You pointed out
a good point (atomicity). That is something I would accept. Thats a point
that makes sence for me.

--Ivo K?thnig


from_name: mapellegrini at comcast.net

body:
Just to lay out what *I* think are going to be the biggest hurdles to creating
a print Wikipedia
A) Articles in en.wikipedia must not be frozen (or this would kil the Wikipedia
project), but must be stable enough that they can be verified a print-ready.
B) Weblinks and interlinks have to be removed from our print articles, but not
from our regular database.
C) While Wikipedia is not paper, a printed version is. Wikipedia doesn't have to be
concise, but a printed version does. By the same token, electronic Wikipedia doesn't
have to define terms very precisely when interlinks can be used, but a paper
encyclopedia, to a larger degree, should. So we absolutely cannot just copy the
articles as they exist in the en database.
D) Forks, with the inevitable loss of effeciency that occurs from repeated efforts,
are always bad.

To summarize the ideas presented regarding the
print version:
1) Some people argue that we should create a print Wikipedia project (ala the
simple english project).
2) Others argue that we should do it behind the scenes, by changing our
markup language or using a hidden flag
3) My idea was to create a talk-page like "Print version" page

I'm sorry to repeat myself, but I still think my idea is the best. Getting a
full, printed version of Wikipedia is going to require a LOT of effort. IMO,
those side projects fall short of it by orders of magnitude. Plus, it would mean
that users would have to keep track of two seperate Wikipedia namespaces - not
something that most people are going to do.

Meanwhile, the do-it-behind-the-scenes idea falls apart completely on point C, (and
point B to a lesser extent).

My idea of a talk-page like structure is distinct from the normal Wikipedia articles
that it doesn't require major changes to the markup langugage, but not too far
removed as to cause ineffeciency. Changes to the printed version would show up in the
watchlist, just like changes to talk pages do. The print-version page could, in many
cases, simply be the first paragraph of the main article.

--Mark Pellegrini
User:Raul654


subject: [Wikitech-l] Re: MediaWiki 1.2.0rc1 release candidate

in_reply_to:
<c1qda9$amg$1@sea.gmane.org> (timwi@gmx.net's message of "Sat,
	28 Feb 2004 15:49:24 +0000")

body:
>>>>> "T" == Timwi  <timwi at gmx.net> writes:

    T> Honestly, if you want for people to report and manage bugs in
    T> an efficient manner (or even if you just want me to get
    T> involved :) ), you seriously need to trash this SourceForge
    T> Tracker and use BugZilla.

It'd actually be cooler to use meta.w.o to track bugs.

~ESP

--
Evan Prodromou <evan at wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide


subject: [Wikitech-l] Re: [Mediawiki-l] MediaWiki 1.2.0rc1 release candidate

body:
On Sat, Feb 28, 2004 at 01:11:04AM -0800, Brion Vibber wrote:
> MediaWiki 1.2.0rc1 is now available for download at:
> https://sourceforge.net/project/showfiles.php?group_id=34373
I would like to upgrade from 1.1.0 stable. What I have to do?
Thank you.

Regards.
Alberto.


from_name: Delirium

subject: PR-strategy was: Re: [Wikipedia-l] 500,000 milestone is here!

body:
Robert Michel wrote:

>The wikipeida is a little bit caotic and unpland what article is written next.
>I started a try on the German mailinglist to think more about a strategie and
>culture for PR, especialy that as many Wikipedianers become skilled and
>"multipliers" as possible.
>
>You can`t by PR, a NGO must live PR.
>
>
I guess to me it seems like this shouldn't be a major problem---we don't
need to do PR, because the PR comes to us.  People have already started
noticing us on their own, and if we simply keep doing what we're doing,
more and more people will notice us.  If we release a printed book
version, that in itself will get us a bunch of PR.  If we get to the
point where we're competing with Britannica in a multi-volume printed
set, that will get us lots of PR (some of it negative---"they're killing
off Britannica!"---but all PR is good PR, right?).

So as long as we keep doing what we're doing, I don't think people will
be able to help but notice us.

-Mark


body:
Daniel Mayer wrote:

>>One example of the difference is in internal references
>>(or q.v. entries). Even if the 'news style' first section
>>approach is used, the first section of the full Wikipedia
>>article would contain links to articles that don't exist in
>>the concise version.
>>
>>
>
>Oh come on. That is easy to fix - don't mark what would be dead links in a
>concise version as anything special. This could be done automatically.
>
>
But we also often use links to be explanatory, which isn't appropriate
for print.  On Wikipedia we can say "follower of [[so-and-so]]", but in
print, you really should say "follower of [[so-and-so]], who was
blah-blah-blah".

Of course, the non-fork solution is to make Wikipedia articles like
that.  Which I do to some extent, because I don't like, even on the web,
the idea of having to click through to another article to make sense of
the current one.  But it's a massive task, as currently a lot of
Wikipedia articles are not fully intelligible on their own, without the
links.

-Mark


from_name: Ray Saintonge

subject: [WikiEN-l] Trading with the Enemy

body:
Fred Bauder wrote:

>Editing material which originates in Iran, North Korea, Cuba and other
>nations with which most trade is banned without a government license may be
>illegal. It is interpreted as aiding the enemy. No corrections of spelling
>or grammar would be allowed under this interpretation, only use of camera
>ready copy. Theoretically correcting a spelling mistake by Osama ben Ladin
>would fall into this category of crime.
>
Is this a suggestion that the servers should be moved to a free country?

>This potentially affects us as we can in the routine conduct of business,
>without even knowing, accept imput from these nations, from a user who
>simply appears to be an ordinary user.
>
It would seem absolutely unwiki to discriminate against an individual
because of his national origin.  The attitude of the U.S. regime against
his government has nothing to do with how we treat individuals from that
country.  The flip side of your argument would have all of us outside of
the United States treat every American individual as though he were an
unqualified supporter of Bush and his cronies.  I could not in good
conscience treat every American that I meet in that way, and you woulkd
do well not to treat individual Iranians, North Koreans or Cubans in
that way.

That being said, I know of no contributors to the Wikimedia family who
are from those countries, so the argument may be moot.

>One could interprete this to apply only to input the origin of which is
>clearly identified.
>
>http://www.nytimes.com/2004/02/28/national/28PUBL.html?th
>
>New York Times login required
>
I have no intention of using the NYT login system.

Ec


subject: [WikiEN-l] Trading with the Enemy

body:
Jimmy Wales wrote:

>As for me personally, I intend to just plain and simple ignore this as
>bureaucratic fantasy.  I can't imagine this passing constitutional
>muster for even a second.  I defy the government to bring a case
>against me or any of you or the Wikimedia Foundation over this.
>They'll look like complete idiots and be laughed out of court.
>
>
I agree, we should just ignore it.  Even the NYTimes article says "in
theory---and almost certainly only in theory", so this is unlikely to be
prosecuted.  So while I admire people's willingness to offer themselves
as test cases, I don't see it as very likely that you're going to
convince the US government to sue you, so we might as well just ignore it.

-Mark


body:
Jimmy Wales wrote:

>Daniel Mayer wrote:
>
>>So long as I'm still breathing I will strenuously fight against any
>>Wikimedia-sponsored fork.
>>
>Me, too, so let's not sweat about that part too much.
>
I suppose this begs the question, "When is a fork a fork?"  Many of
Wikipedia's sister projects have some characteristics of a fork, but
they all come under the same umbrella.

Ec


from_name: Arvind Narayanan

body:
Hi,

When I clicked on a link to [[Indian Institutes of Technology]] I
got a popup saying: "Alert: The file /wiki/Indian_Institutes_of_Technology
could not be found. Please check the name and try again later" or
something like that. Repeated several times, same result. Didn't
get this error on any other page. After a while I clicked on some
link which redirected to [[Indian Institutes of Technology]], and
it worked. Then I tried the original link and it worked too. Some
cache problem?

Arvind
--
Its all GNU to me


subject:
[Wikipedia-l] Gallery of 53 Main Pages - For quick comparison
	of	general layouts

body:
Erik Zachte wrote:

>For a quick comparison of layouts of all 53 Main Pages have a look at
>http://eza.gemm.nl/Wikipedia/Gallery/Gallery.htm
>
>Complete pages are shown, captured at a virtual 1000*3000 screen resolution,
>reduced to 40% size.
>At 40% reduction the text is hardly readable, but it gives a nice comparison
>of overall layout per wikipedia.
>
Very pretty!
Ec


from_name: Charles Matthews

subject: [WikiEN-l] Trading with the Enemy

body:
Fred Bauder wrote

> Editing material which originates in Iran, North Korea, Cuba and other
> nations with which most trade is banned without a government license may
be
> illegal. It is interpreted as aiding the enemy.

Perhaps by your government - I doubt it is by mine.

Charles


subject: [WikiEN-l] Re: Print edition

body:
Ray Saintonge wrote

>Simply marking an article as "ready for print" would
> effectively freeze it from further editing.  The living Wikipedia
> article needs to be continually editable so that the version that is on
> the 2nd printed edition can show further improvements.

Agree.  The threads on this issue are already a little tangled.  I agree
wholeheartedly with comments about the copyediting being key.

Invisible HTML comments could be used to insert standard messages such as
'above here is written in news style as a candidate short print article',
without much inhibiting further editing. Presumably anyone who cared enough
to put an article forward by adding this comment would watch edits to those
pages.  Perhaps that and another possible , less specific, message: 'this
page is currently being considered for the print WP'.

Charles


from_name: Arno M

subject: [WikiEN-l] Plautus was kicked off this list

body:
I guess that one needs to experience Plautus firsthand, in order to really appreciate him, as Jimbo's found out for himself.

Actually, I cannot refrain from adding that Plautus'es contributions on this list reminded me of Hal from 2001:A Space Odyssey, and the output it gave out just before Hal pulled out those computer chips. All that was missing from Plautus before Jimbo pulled the plug on him was a recital of "Daisy, Daisy...." .

"I'm not sure what Ed's talking about, vis-a-vis the vote, but to be
clear, I kicked Plautus off the list on my own initiative because I'm
sick of his nonsense.

Please know that this guy is sending me many many many emails that I
can only charitably describe as perplexing.

He seems to think that somehow Disney is behind all this, among a
number of other interesting theories about people using pre-arranged
and encrypted signals, etc.

I can't make heads nor tails of it, to tell you the truth. I just
wanted to stop flooding all the subscribers with it."

____________________________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20040228/ee789585/attachment.htm


from_name: Timwi

subject: [Wikitech-l] Re: Unbelieveable 1.1.0

body:
ciaran wrote:

> Evan Prodromou said the following on 2/25/2004 3:04 PM:
>
>  >     c> I really wish I hadn't "upgraded" to this recommended
>  >     c> version. But I won't go into all the issues here.
>  >
>  > ...just quickly insult the people who made the software for you to
>  > use, then ask for their help again.
>
> Actually, if it was my intention to insult them, I wouldn't mention
> something I wish _I_ hadn't done.

It can nevertheless easily be taken as an insult. "I wish I hadn't
upgraded to this recommended version" sounds a bit like "This so-called
recommended version is so crap that it's not worth upgrading to."


subject: [Wikitech-l] Re: Faster parsing

body:
Ivo K?thnig wrote/schrieb/a ?crit/skribis/etc.:

> Am Samstag, 28. Februar 2004 04:22 schrieb Timwi:
>
>>You have not provided examples of "overhead calculations" that a DB
>>would have to perform that a file system wouldn't. You also haven't
>>provided evidence of your claim that DBMSs cannot represent the required
>>range of data structures.
>
> That starts with parsing and transforming a sql-statement into an expression
> of relational algebra (which can not always produce the optimal (fastets)
> expression) and ends by the point that you are restricted to these
> expressions which can be handeled only step by step (operation always on the
> huge table).

I think you are greatly underestimating the powerful optimisations that
can be done (and are done) in MySQL. Parsing an SQL statement is trivial
(in terms of required computational power); I don't know much about
relational algebra, but it seems that you would somehow have to express
and then parse statements in that algebra too. If you don't have an
index, then operations on huge tables are slow no matter what data
structure you use. Any kind of indexing alleviates this problem, and
RDMBSs do indexing really well.

>>There is a huge number of organisatorial tasks that you would need to do
>>with your files (when reading, that would be parsing the file, locating
>>data, possibly caching and perhaps sorting; when writing, that would be
>>updating indexes, managing "holes" in the file, and a huge host of other
>
> that is no problem if you use good datastructures...

I think you haven't quite understood what I was getting at here. This is
independent of what data structure you use.

>>DBMSs are specifically designed to do exactly these things. People often
>>tend to forget that DBMSs aren't really much more than systems that
>>manage files! But they have all these incredibly complicated and
>>advanced things in it that you need and you really really don't want to
>>have to re-implement from scratch.
>
> Yes, but you don't want to implement each of that features.

Yes, you do. You do need to manage your files. You do need to store your
data structures somehow, and parse them, and update them, etc.etc.

>>For 99.9% of data you want to store, you *can* create *exactly* the data
>>structure you need using an RDBMS.
>
> By data structure I am not only mean the structure of data. I also mean the
> code which belongs to it to handle it (For example heaps, sorted lists and so
> on). The structure for the data surly can be created but not the code...

You never specifically need [[heap]]s. A heap is a special way of
implementing a [[priority queue]] - if you need a priority queue, then
you can do that by creating an indexed table. Whether the index is
implemented as a heap should not be your concern (it should be the
DMBS's). It is well possible that MySQL uses heaps, I don't know.

Timwi


from_name: Erik Zachte

subject:
[Wikipedia-l] Gallery of 53 Main Pages - For quick comparison of
	general layouts

body:
For a quick comparison of layouts of all 53 Main Pages have a look at
http://eza.gemm.nl/Wikipedia/Gallery/Gallery.htm

Complete pages are shown, captured at a virtual 1000*3000 screen resolution,
reduced to 40% size.
At 40% reduction the text is hardly readable, but it gives a nice comparison
of overall layout per wikipedia.

Erik Zachte

This job was easy thanks to url2bmp (Windows freeware)
http://www.pixel-technology.com/freeware/url2bmp/
despite its name it handles other image formats as well,
can be run in batch mode


body:
Brion Vibber wrote:

> and please report any exciting new problems.
> If we don't hear about your problems, they'll never get fixed!

Have you fixed the problem with Special:Whatlinkshere?

Example: The following Whatlinkshere page suggests that there is a
double-redirect where there isn't actually one:
http://en.wikipedia.org/w/wiki.phtml?title=Special:Whatlinkshere&target=Bah%E1%27%ED_Faith
Now, I have *not* tried to edit the wrongly-displaying redirect to see
if this would fix the problem, because if it does, then this evidence
would be gone and I would have to perform more tests to see if the bug
was actually fixed.

> You can report problems at SourceForge at:
> http://sourceforge.net/tracker/?group_id=34373&atid=411192

Honestly, if you want for people to report and manage bugs in an
efficient manner (or even if you just want me to get involved :) ), you
seriously need to trash this SourceForge Tracker and use BugZilla.

Timwi


subject:
[Wikitech-l] Re: Possible bug: "The file /wiki/$ARTICLE" could not
	be found

body:
Arvind Narayanan wrote:

> Hi,
>
> When I clicked on a link to [[Indian Institutes of Technology]] I
> got a popup saying: "Alert: The file /wiki/Indian_Institutes_of_Technology
> could not be found. Please check the name and try again later"

It's a known bug in Mozilla:
http://bugzilla.mozilla.org/show_bug.cgi?id=123662


from_name: Rick

subject: [WikiEN-l] Trading with the Enemy

body:
Where would you suggest?  In France, it's illegal to criticize the government.  In Germany, it's illegal to display Nazi memorabilia.  In the UK there's the Official Secrets Act to deal with.

RickK

Ray Saintonge <saintonge at telus.net> wrote:
Is this a suggestion that the servers should be moved to a free country?

---------------------------------
Do you Yahoo!?
Get better spam protection with Yahoo! Mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20040228/66262548/attachment.htm


from_name: Vicki Rosenzweig

subject: [WikiEN-l] Trading with the Enemy

body:
At 05:43 PM 2/28/04 +0000, Abi wrote:
>On Sat, 2004-02-28 at 17:34, Sean Barrett wrote:
> > > http://www.nytimes.com/2004/02/28/national/28PUBL.html
> > >
> > > I just assumed that Fred was joking or exaggerating about what this
> > > story says.  But he's reporting it accurately.
> >
> > Nyarly H. Hotep on a rubber raft.  Does anybody have an Iranian
> > article I can edit?  I'm willing to stand up and be a test case if
> > WikiMedia is willing to be my publisher.
>
>[[User:Roozbeh]] is editing from Iran, so...

So I took a look. The article [[Majlis of Iran]] needed copyediting, so
I've done
so. I am a US citizen, resident within the United States. (I thought Roozbeh
had created it, but the creation was from an IP address which my handy
converter can't resolve but that traceroute gets me to a comcast machine on.

I'll keep looking.


subject: [Wikitech-l] Deleting page histories

in_reply_to:
<shoerjcam4.fsf@tux.gnu.franken.de> (Karl Eichwalder's message
	of "Sat, 28 Feb 2004 19:38:59 +0100")

body:
>>>>> "KE" == Karl Eichwalder <ke at gnu.franken.de> writes:

    TW> I am therefore strongly suggesting that someone add a feature
    TW> whereby a sysop can delete a single previous revision, rather
    TW> than the entire history of a page.

    KE> You must also delete _all_ revisions derived from the
    KE> copyright violation.  Of course, you can preserve parts of the
    KE> jounger revisions which are not derived from the questionable
    KE> parts.

It'd be interesting to treat the changes as diffs. So if you've got 4
versions:

        Version 1
        Version 2
        Version 3
        Version 4

...and Version 2 is No Good For Some Reason, you create some diffs:

        Version 1
        Version 2
        Diff 3 from 2
        Diff 4 from 3

You then apply Diff 3 from 2 as a patch to Version 1, and Diff 4 from
3 as a patch against the result of that.

It would probably result in terrible conflicts, but it's an
interesting idea.

~ESP

--
Evan Prodromou <evan at wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide


subject: [WikiEN-l] Trading with the Enemy

body:
At 03:59 PM 2/28/04 -0500, I wrote:
>At 05:43 PM 2/28/04 +0000, Abi wrote:
>>On Sat, 2004-02-28 at 17:34, Sean Barrett wrote:
>> > > http://www.nytimes.com/2004/02/28/national/28PUBL.html
>> > >
>> > > I just assumed that Fred was joking or exaggerating about what this
>> > > story says.  But he's reporting it accurately.
>> >
>> > Nyarly H. Hotep on a rubber raft.  Does anybody have an Iranian
>> > article I can edit?  I'm willing to stand up and be a test case if
>> > WikiMedia is willing to be my publisher.
>>
>>[[User:Roozbeh]] is editing from Iran, so...
>
>So I took a look. The article [[Majlis of Iran]] needed copyediting, so
>I've done
>so. I am a US citizen, resident within the United States. (I thought Roozbeh
>had created it, but the creation was from an IP address which my handy
>converter can't resolve but that traceroute gets me to a comcast machine on.
>
>I'll keep looking.

Looking a little further, the article [[Yas-e-no]] was created by Roosbeh. The
edit history now has two additional edits by Roosbeh, and one by me.

Vicki


from_name: Geoff Burling

subject: [WikiEN-l] Trading with the Enemy

body:
On Sat, 28 Feb 2004, Ray Saintonge wrote:

> Fred Bauder wrote:
>
> >
> >http://www.nytimes.com/2004/02/28/national/28PUBL.html?th
> >
> >New York Times login required
> >
> I have no intention of using the NYT login system.
>
I have never used the NYT login system either -- except when someone on
Slashdot would post usernames & passwords for all to use like
"cypherpunk/cypherpunk". (And no, this account no longer works.)

But I discovered 6 months ago anything worth reading on the NYT website
could be accessed thru http://news.google.com. Just plug in the likely
keyword for Google to search, & you can privately read the article.

Geoff


from_name: Brion Vibber

body:
On Feb 28, 2004, at 07:49, Timwi wrote:
> Brion Vibber wrote:
>> and please report any exciting new problems. If we don't hear about
>> your problems, they'll never get fixed!
>
> Have you fixed the problem with Special:Whatlinkshere?

There's nothing wrong with Special:Whatlinkshere. There is corruption
in the link tables on Wikipedia, which is visible in
Special:Whatlinkshere.

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


subject: [Wikitech-l] MySQL tables and indexes

body:
On Feb 28, 2004, at 12:44, Timwi wrote:
> 1) When I load the downloaded SQL dump into MySQL, does it matter if I
> have already created the indices for the table, or is this
> detrimental?

Loading the dump drops any existing table of the same name and creates
a new one. It doesn't matter what you've created, it'll be gone.

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


from_name: Anthere

body:
Fred Bauder a ?crit:
> Here's a belly laugh. He's over at Wikinfo now and after proposing a
> permanent ban at Wikipedia I have to welcome him and give him a fair chance.
>
> He started with September 11, 2001 attacks.
>
> Expecting a miracle...
>
> Fred

At least, you are not gonna mutilate your fingers yourself Fred


subject: [Wikitech-l] Deleting page histories

body:
It has just been brought to my attention (well, rather: I found out)
that on the German Wikipedia, if someone submits a text that constitutes
a copyright violation, the sysops there immediately delete the complete
page history and reinstate the most recent version before the copyvio.

This is a pretty serious issue; I'm pretty sure that this is not
GFDL-legal (while, obviously, keeping the copyvio in the page history
isn't either); it removes legitimate contributions from legitimate
users; and less seriously, it messes up statistics.

I am therefore strongly suggesting that someone add a feature whereby a
sysop can delete a single previous revision, rather than the entire
history of a page.

It would probably suffice to delete just from the 'old' table; if you
want to delete the most current revision, you should probably revert to
an older version first anyway, thereby moving the one you want to delete
to the 'old' table.

Timwi


body:
Evan Prodromou wrote:

>>>>>>"T" == Timwi  <timwi at gmx.net> writes:
>
>     T> Honestly, if you want for people to report and manage bugs in
>     T> an efficient manner (or even if you just want me to get
>     T> involved :) ), you seriously need to trash this SourceForge
>     T> Tracker and use BugZilla.
>
> It'd actually be cooler to use meta.w.o to track bugs.

Possibly; it would be more wiki-like. However, BugZilla has a vast
amount of organisatorial features, most notably for searching, and
resolving bugs esily. It is also very well-known (and well-appreciated)
in the open-source community.

Timwi


body:
Robert Michel wrote:

>Bad news are good news, from the news papers point of view.
>Bad PR is just bad PR. Do you remember of the image problem of the German
>chemical big group Bayer (BAY) after the Lipobay "problems"?
>
>
>My starting points for creating a PR-strategy was not popularity for user, and
>not finding as many new wikipedianer as possible. They were:
>- qualitative growing - becomming experts to be active wikipedianer
>- Howto ask effective for the use of pictures with the condition of the
>GNU-FDL
>- to find donator and heirships
>
>
Sorry, I misunderstood you then; I thought you were working on a
strategy to make Wikipedia more in-the-media and more popular, which I
think will happen on its own.  The three bullet points you have there
are really good ideas though.

-Mark


subject: [WikiEN-l] Re: Trading with the Enemy

body:
Anthere wrote:

>
>
> Rick a ?crit:
>
>> Where would you suggest?  In France, it's illegal to criticize the
>> government.  In Germany, it's illegal to display Nazi memorabilia.
>> In the UK there's the Official Secrets Act to deal with.
>>
>> RickK
>
>
> May I *seriously* suggest that you consider avoiding libel and
> comments that might anger your peers RickK ?

Well, according to the World Press Freedom Committee's document "Insult
Laws: A Insult to Press Freedom"
(http://www.wpfc.org/site/docs/pdf/Publications/Insult%20Laws-An%20Insult%20to%20Press%20Freedom-1996%20booklet.pdf):

"...the primary form of this crime became known as 'insult to the
president of the republic,' whose classic form was set in the French
press law of 1881.  It remains the basic press legislation in France
today.  The 1881 law also carries serious penalties for insulting
foreign chiefs of state, foreign ministers or ambassadors of friendly
countries, and official bodies like parliament, the judiciary, and armed
forces... Similar provisions are on the books in Austria, Germany, the
Netherlands, Norway, and Spain."

The report goes on to note that the French law was last actually used
under Charles de Gaulle in the 1960s, when a spectator was arrested for
crying out "hoo hoo" at him.  More recently the Sun was threatened with
a lawsuit for insulting Chirac, though this never materialized.

The report also notes that the French law has served as an example for
many laws in other countries, especially less-developed countries, and
especially former French colonies, that *are* enforced, and those
countries defend their law under "well, France has such laws, so why
shouldn't we?"

So "illegal to criticize" is going too far, but it's not entirely
without basis either.

-Mark


from_name: Martin Harper

subject: [WikiEN-l] Columbia and Copyright

body:
Jimbo:

> There are pages for alphabetic browsing.
> http://www.encyclopedia.com/browse/browse-Aa.asp

> Auppose [the Wikipedia print edition] snagged the
> same 55,000 topics as Columbia?  How big would the resulting
> text be?

Wouldn't selecting the exact same 55,000 topics as Colombia be a possible
copyright infringement? Choosing an appropriate selection of topics for a
concise encyclopedia is a creative act...

-Martin


from_name: Michael Snow

subject:
[Wikipedia-l] Re: Gallery of 53 Main Pages - For quick comparison
	of general layouts

body:
Erik Zachte wrote:

> For a quick comparison of layouts of all 53 Main Pages have a look at
>
>http://eza.gemm.nl/Wikipedia/Gallery/Gallery.htm
>
>Complete pages are shown, captured at a virtual 1000*3000 screen resolution,
>reduced to 40% size.
>At 40% reduction the text is hardly readable, but it gives a nice comparison
>of overall layout per wikipedia.
>
>
It's nice to see that quite a few languages are getting images on their
main pages. I wish I knew enough, or any, Romanian, to understand how
that picture of two frying pans got featured.

ZH appears to have picked up EN's new layout (or did we get it from
them?). I particularly enjoy seeing the right-to-left layouts in Hebrew
and Arabic.

--Michael Snow


from_name: Abigail Brady

subject: [WikiEN-l] Trading with the Enemy

body:
On Sat, 2004-02-28 at 17:34, Sean Barrett wrote:
> > http://www.nytimes.com/2004/02/28/national/28PUBL.html
> >
> > I just assumed that Fred was joking or exaggerating about what this
> > story says.  But he's reporting it accurately.
>
> Nyarly H. Hotep on a rubber raft.  Does anybody have an Iranian
> article I can edit?  I'm willing to stand up and be a test case if
> WikiMedia is willing to be my publisher.

[[User:Roozbeh]] is editing from Iran, so...

--
Abi


subject:
Bug tracker (was Re: [Wikitech-l] Re: MediaWiki 1.2.0rc1 release
	candidate)

body:
>>>>>> "T" == Timwi  <timwi at gmx.net> writes:
>     T> Honestly, if you want for people to report and manage bugs in
>     T> an efficient manner (or even if you just want me to get
>     T> involved :) ), you seriously need to trash this SourceForge
>     T> Tracker and use BugZilla.

I agree the bug tracker on sourceforge sucks.

Bugzilla unfortunately is also horribly intimidating to use. If *I*
find it intimidating, think what joe random "I'm having a problem, I
just want to see it fixed" is going to think. My eyes glaze over just
tyring to do a search!

(Of course, it took me two years to notice that one *can* search in the
sourceforge bug tracker. It really really is badly designed.)

On Feb 28, 2004, at 08:09, Evan Prodromou wrote:
> It'd actually be cooler to use meta.w.o to track bugs.

Tracking bugs on wiki pages is terribly difficult too, unfortunately;
that's why we started using the tracker. Reports get left, then we ask
for more information, and the original poster never comes back to
check. Duplicates aren't managed. The list gets very long and things
disappear without being kept after. Nobody gets notification of changes
in state.

Perhaps if we put more work into organizing bug reports on the wiki it
could be managed (one page per bug, use your watchlists, be really anal
about keeping order in the list page), but historically this has not
done well.

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


subject:
[Wikitech-l] PHP5 compatibility (was Re: MediaWiki 1.2.0rc1 release
	candidate)

body:
On Feb 28, 2004, at 01:11, Brion Vibber wrote:
> * No PHP5 compatibility. I know there are a few keyword conflicts
> which should be easy to fix, but we haven't tested this yet.

Actually, it seems that these may have been fixed already. I've done a
quick test with PHP 5.0.0b4 and haven't run into any problems yet. I'd
appreciate a confirmation on this from anybody who's using PHP 5 more
regularly or notices that a particular operation does fail.

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