Hi!
Someone on the German mailinglist pointed out that CologneBlue
doesn't show tables correctly. It ignores the table's cellpadding
tag. A screenshot can be found here:
http://www.studentendorf-vauban.de/~zeno/pics/wikipedia-table-cb.png
This is also the case on the English wikipedia, e.g.
http://www.wikipedia.org/wiki/Alberta
The reason is an entry in cologneb.css:
>#article, #article td, #article th, #article p {
> font-family: Verdana, Arial, sans-serif;
> font-size: 10pt; color: black;
> padding: 0;
>}
If you delete
>padding: 0;
everything looks fine.
I also want to remind you about another thing that needs to be fixed
with the CologneBlue stylesheet:
http://mail.wikipedia.org/pipermail/wikitech-l/2003-July/004911.html
Thanks
Daniel
So, with the MediaWiki (sweet name, btw), users uploading an image
write up the rights info for an image on the Image: page.
It would be a lot easier for downstream users to have data in the
database about what's under a free license, what's copyrighted, and
who has copyright on what. Especially for a license like the GFDL or
the by-sa, where attribution is required to re-use content, it becomes
pretty necessary.
I was thinking that IWBNI there was a radio-button list on the upload
page for defining the rights of an image. Something like this:
I affirm that:
( ) I am the copyright holder of this image and I agree to
license it according to $COPYRIGHT_PAGE.
( ) The copyright holder is [textbox here] and they have agreed
to license it according to $COPYRIGHT_PAGE.
( ) This image is in the public domain because [textbox].
( ) This image was created by [textbox here] and I am uploading
it here according to the principle of $FAIR_USE_PAGE|fair use
because [textbox].
(o) I left the default value of this radio button list checked
because I don't read fine print, especially about confusing
copyright info.
Empty values for the text boxes, or leaving the default chosen, would
be an error.
It might actually be useful to mark article edits similarly:
I affirm that:
( ) I wrote these changes and I agree to license them according
to $COPYRIGHT_PAGE.
( ) The writer is [textbox here] and they have agreed
to license their work according to $COPYRIGHT_PAGE.
( ) This text is in the public domain because [textbox].
( ) This text was created by [textbox here] and I am uploading
it here according to the principle of $FAIR_USE_PAGE|fair use
because [textbox].
(o) I left the default value of this radio button list checked
because I don't read fine print, especially about confusing
copyright info.
An additional side benefit would probably be a lower rate of copyvios.
I'm going to try to make this work on wikitravel.org, and submit a
patch for MediaWiki afterwards.
~ESP
--
Evan Prodromou
evan(a)prodromou.san-francisco.ca.us
Daniel Herding wrote:
>In the Upload form, below the ''summary'' field,
>there should be fields called ''source'' and
>''copyright status''. ''summary'' should be
>renamed to ''description''. The Wikipedia software
>should refuse to accept the file unless all fields
>are filled out. After that, it can create a nice
>image description page from the entered information.
I agree completely. We could also add category tags
based on the above info so that third parties could
filter out "fair use" and no tag images.
-- Daniel Mayer (aka mav)
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
On Wed, 13 Aug 2003 00:31:49 +0200, Tomasz Wegrzanowski wrote:
>Anyway, it'd be much better to delete every image of dubious legal status
>straight away.
The problem is that most people don't add information about source and
copyright status when they upload an image. That's why I think it
should be enforced.
In the Upload form, below the ''summary'' field, there should be
fields called ''source'' and ''copyright status''. ''summary'' should
be renamed to ''description''.
The Wikipedia software should refuse to accept the file unless all
fields are filled out. After that, it can create a nice image
description page from the entered information.
Best regards,
Daniel
> There's still room for optimization, and it would be nice to get some
of the Special Pages back. (Erik Moeller)
Special pages like longest article, orphans etc could easily be
extracted from a SQL dump, I'll write a Perl script if there is capacity
to run it and daily dumps to feed into it.
All discussions so far center on speed, how about robustness? In the
current situation a disk crash is disastrous. Remember no dump was made
for 18 days just recently. So will this be cured when a replicated
server is introduced? Also, Brion mentioned: "unless we lock the wiki
the cur and old databases will be inconsistent in the backup. (Which is
in fact the present state of the backups for the English wiki.)"
One of the advantages of RAID ('I' stands for inexpensive) is the
possibility to introduce redundancy, so that a crashed disk can be
replaced on the fly and the content rebuilt from the other disks.
Erik Zachte
This requests goes out _especially_ to the 'hands dirty' developers
who are intricately familiar with where our hardware bottlenecks are
most likely to be. But anyone with solid, non-speculative ideas is
welcome to comment!
As Jason said, he bought another gig of ram -- we are planning to
basically max out the machines if that will help. That hard drive
that didn't work, well, we'll get the right one soon, and that'll help
significantly I think. Also, if I'm not mistaken, one of these
machines has a dual processor board, but only a single processor, is
that right, Jason? So that's an easy upgrade, once we find and buy
the right part.
But, imagine this: suppose I were shopping at
http://www.penguincomputing.com/, as I always do, and I wanted to
spend around $3000 on new hardware for wikipedia. Presumably, this
could either be one new kickass machine, or 2 new very nice frontend
webservers, or whatever else we think we could best use.
Given that budget, what should I buy that's most likely to give us the
best bang for the buck?
And then, of course, once we have settled on the general type of
hardware (i.e. 2 medium machines or 1 kickass machine) that will be
most useful to us, we could also extend our shopping to other
suppliers. I have used penguincomputing many times and I've been very
happy, but I'd go elsewhere if there was good reason.
--Jimbo
>>>>> "TW" == Tomasz Wegrzanowski <taw(a)users.sourceforge.net> writes:
TW> Is it another attempt to introduce images of dubious legal
TW> status (claimed by some to be under "fair use") into Wikipedia
TW> ?
No, not at all. "Fair use" isn't good enough to get stuff into Wikitravel:
http://www.wikitravel.org/article/Wikitravel:Copyright_details#Fair_Use
...and I'd probably disable that option for wikitravel.org.
The main idea is to store as much rights information as possible in
machine-readable format. For me, I want to be able to put
automatically-generated copyright notices on the printable version of
a page.
~ESP
--
Evan Prodromou <evan(a)wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide
I would like to get CVS access to be able to upload new versions of
languageNl.php myself rather than have to go through a busy Brion VIBBER
every time.
As things are now, I intend to use this access only for updating the Dutch
(and perhaps in the future the Frisian) language-version.
Andre Engels
>>>>> "EM" == Erik Moeller <erik_moeller(a)gmx.de> writes:
EM> No underlying logic AFAIK (or none that is applicable any
EM> longer with underlining itself being an option). Stub links
EM> are simply not used by default on any of the Wikimedia
EM> projects, so that aspect of the style sheets is a bit
EM> neglected.
Good. I don't feel so bad about re-enabling them, then.
Thanks,
~ESP
--
Evan Prodromou <evan(a)wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide
