On Sunday 28 July 2002 03:00 am, The Cunctator wrote:
> What are the articles this person has been changing?
For 66.108.155.126:
20:08 Jul 27, 2002 Computer
20:07 Jul 27, 2002 Exploit
20:07 Jul 27, 2002 AOL
20:05 Jul 27, 2002 Hacker
20:05 Jul 27, 2002 Leet
20:03 Jul 27, 2002 Root
20:02 Jul 27, 2002 Hacker
19:59 Jul 27, 2002 Hacker
19:58 Jul 27, 2002 Hacker
19:54 Jul 27, 2002 Principle of least astonishment
19:54 Jul 27, 2002 Hacker
19:52 Jul 27, 2002 Trance music
19:51 Jul 27, 2002 Trance music
For 208.24.115.6:
20:20 Jul 27, 2002 Hacker
For 141.157.232.26:
20:19 Jul 27, 2002 Hacker
Most of these were complete replacements with discoherent statements.
Such as "TAP IS THE ABSOLUTE DEFINITION OF THE NOUN HACKER" for Hacker.
For the specifics follow http://www.wikipedia.com/wiki/Special:Ipblocklist
and look at the contribs.
--mav
I hereby decree, in my usual authoritarian and bossy manner, that today shall
forever be known as Magnus Manske day. Wikipedians of the distant future will
marvel at the day when the new software era dawned upon us.
Tonight at dinner, every Wikipedian should say a toast to Magnus and his many
inventions.
--Jimbo
What is the situation when you want to include information which is
essentially in the public domain (e.g. a historical list of the Governors-
General of NZ) but where all the convenient sources have their own
copyright notices? Are they in effect copyrighting the information (which I
would consider to be in the public domain) or just their presentation of
it?
Happy New Year!
--
Richard Grevers
On 31 Dec 2002 19:59:00 +0100, Erik Moeller
<erik_moeller=Mmb7MZpHnFY(a)public.gmane.org> wrote:
>> I disagree. On the web, a standard blue underline that turns purple
>> after you visit it is simple and instantly recognizable.
>
> Blue underlined, yes; purple is almost used nowhere these days. CNN,
> Yahoo, Amazon, eBay etc. all don't use it. So the expecation isn't there.
> Blue underlined vs. blue is not such a big difference as to be confusing,
>
> and we *are* a very link-heavy site.
>
To add to the dilemma, Wikipedia has to distinguish between three different
classes of link:
*Wikipedia article
*Non existant Wikipedia Article
*External link
and only for the second of these is Visited status not important. Thus
there need to be five distinct link designations.
Most useability guidelines suggest that visited links should have a less
distinctive marking than unvisited. I tend to use "closer to grey/black" as
less distinctive, e.g. the two link colours for external links ought to
have the same hue (green) but different saturation or lightness/darkness.
I currently find the red to be a little strong (giving missing articles too
much visual weight) and the green a little weak. (using the cologne blue
stylesheet).
With respect to underlining, thought might be given to the following
markup, which will result in a less intrusive underline in good browsers
(IE, unfortunately, still renders dotted as solid):
a.whatever {text-decoration:none; border-bottom: 1px dotted #ddeeff;} (I've
used an arbitrary colour and class here). This also avoids problems where
some browser/font combinations result in underlines striking out the bottom
pixel-row of descenders, which impairs redability.
--
Richard Grevers
On 12/31/02 3:27 AM, "Derek Moore" <jizzbug(a)hotmail.com> wrote:
> Because of the nature of Wikipedia, articles tend to get rather congested
> with links. All these super-bright reds and blues and gaudy underlines can
> sometimes get the better of an article. I was working on [[w:LAMP]] just
> now when my eyes just couldn't take anymore.
>
> It might be nice to find some softer colors for links, visited links, and
> non-existent links. And to also, via CSS, get rid of the underlines on
> links within the body of an article (the underlines are kinda helpful for
> the menus to left, above, and below articles, though [but maybe for style
> these underlines could be done away with, too, and instead go with bolding
> the font faces]). I do like red for non-existent articles, and blue for
> existent articles; they're just way too bright as it is.
>
> Anyways, I really think something ought to be done about this, as too many
> link-filled articles just look terrible, and their readability is quite
> degraded. It's just too distracting on the eyes, especially when you're
> tryin' to study the text.
>
One, this isn't a matter for wikitech. Two, I think it's fine for there to
be a non-default skin that satisfies your desires. Three: in no way should
non-underlined links be the default. It's bad practice in terms of usability
to violate standards.
On lun, 2002-12-30 at 13:08, Magnus Manske wrote:
> What's with the Tex feature update? Anything final yet?
It's sitting in CVS, and the fixed English language file looks right.
(** But we're still missing translations for the TeX options for most
languages! **)
Shall I install it wikipedia-wide? Is there any objection other than
Toby's? See: http://meta.wikipedia.org/wiki/Texvc
On a related note, I'd like some feedback on the suggestion to provide
support for inline musical notation via GNU Lilypond:
http://meta.wikipedia.org/wiki/Music_markup
-- brion vibber (brion @ pobox.com)
Hello everyone,
My apologies if this has been discussed before, but I just noticed that
Wikipedia pages carry a doctype declaration of
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Since this does not include the URL to a full DTD, the curse of doctype
sniffing sees most browsers render the page in "Quirks" or "Bugwards
compatible" mode rather than "strict" mode. In the interests of making
wikipedia accessible, I think it would be better to force strict mode -
then editors would be more likely to notice markup errors which affect the
rendering on browsers which do not correct for bad markup.
--
Richard Grevers
CHristchurch, NZ
Hi again,
I attempted to submit a sample Wkipedia page to the W3C validator and was
amzaed to see that carried no character encoding whatsoever. Here is the
full report from the validator -
I was not able to extract a character encoding labeling from any of the
valid sources for such information. Without encoding information it is
impossible to validate the document. The sources I tried are: The HTTP
Content-Type field.
The XML Declaration.
The HTML "META" element.
And I even tried to autodetect it using the algorithm defined in Appendix F
of the XML 1.0 Recommendation. Since none of these sources yielded any
usable information, I will not be able to validate this document. Sorry.
Please make sure you specify the character encoding in use. IANA maintains
the list of official names for character sets. ----
<end quote>
Surely Wikipedia ought to use an encoding such as UTF-8?
--
Richard Grevers
Wikipedia is currently under GFDL. Would the Open Publication License
not be more suited?
I just found it at http://www.opencontent.org/openpub/
Just a thought.
Magnus
I noticed that the Lattice entry lumps together 3 different senses
of the word "Lattice". I believe these should be separate entries
for each *sense*: [[Lattice algebraic structure]],
[[Lattice in material science]] etc.
Then there should be a disambiguation page that explains
that in the context of algebra, the word "lattice" means
[[Lattice algebraic structure]], in the context of material
science it means [[Lattice in material science]] etc. In
general, I think that we should not get distracted by the
fact that such entries are grouped together in traditional
printed encyclopedias; this appears to be an artifact of the
primitive lookup operation used in that case.
I would even go as far as marking specially the pages whose
primary purpose is to map words to senses. The reason is
the following potential useful enhancement of wikipedia.
Image that *every* sense used in wikipedia article has an
entry in wikipedia (or wiktionary). Then one could build an
interactive tool that would help replace every occurrence of
a word in an article with a unique sense of that word.
Therefore, all words would have unambiguous meaning. This
might not seem like a great advantage for human readers, but
I believe that wikipedia has a large potential for automated
processing.
Viktor