On Sunday 28 July 2002 03:00 am, The Cunctator wrote:
> What are the articles this person has been changing?
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
20:20 Jul 27, 2002 Hacker
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.
So, it seems (if I interpret Jimbo's mail on wikitech and the discussion
here correctly) that most of us would like *some kind* of category
scheme in wikipedia. I do, too! But, we seem to differ on the details
So far, I saw three concepts:
1. Simple categories like "Person", "Event", etc.; about a dozen total.
2. Categories and subcategories, like
"Science/Biology/Biochemistry/Proteomics", which can be "scaled down" to
#1 as well ("Humankind/Person" or something)
3. Complex object structures with machine-readable meta-knowledge
encoded into the articles, which would allow for quite complex
queries/summaries, like "biologists born after 1860".
1. Easy to edit (the wiki way!)
2. Still easy to edit, but making wikipedia browseable by category,
fine-tune Recent Changes, etc.
3. Strong improvement in search functions, meta-knowledge available for
1. Not much of a help...
2. We'd need to agree on a category scheme, and maintenance might get a
3. Quite complex to edit (e.g., "<category type='person'
occupation='biologist' birth_month='5' birth_day='24' birth_year='1874'
For a wikipedia I'd have to write myself, I'd choose #3, but with
respect to the wiki way, #2 seems more likely to achieve consensus (if
there is such a thing;-)
I'm posting this to wikipedia-l as it concerns all Wikipedias; albums are
in that respect language independent.
As you may know, freedb.org provides a huge open content database of
existing music CDs. Overall, the statistics page currently lists 882172
individual CDs. For each album it provides the name, band, track
information (including length) and sometimes other details such as the
In part because FreeDB already exists, I believe we need a strict policy
against mere CD database entries for Wikipedia that provide no additional
information about an album. If there are no objections, I will create the
respective policy page on the English Wikipedia.
1) If we imported all entries from FreeDB into Wikipedia, some facilities
of Wikipedia would become unusable. "Random page" would lose much of its
current value. The search would be massively slowed (because the database
size would drastically increase) and return many useless hits, because
song titles use pretty much every word in every language. Possible future
facilities such as an "Ancient pages" feature to view the pages that have
been edited the longest time ago would also be drastically impaired.
2) Much of the imported information would be neglected -- FreeDB database
entries are generated automatically by running an application on a
computer while a CD is inserted, which is why there are so many of them.
We cannot and should not keep up with this process. We would only
duplicate existing work.
3) Wikipedia is not a mirror for source material. As far as only album
data is entered, in my opinion the criterion of "source material" is
4) Not allowing the import of FreeDB entries but allowing manual entry of
album track lists is even worse. We create an extremely incomplete list,
and encourage our users to duplicate existing work.
What we should do instead, I think, is this:
1) Make a clear policy that pages which only contain track lists and
nothing else of value can be deleted (they still need to be put on the
"Votes for deletion" page or equivalent on other Wikipedias, but they can
be deleted quickly).
2) Make another policy that pages about bands should *not* contain links
to the individual albums. These links should be created on demand, not for
all album titles. Instead, add an external link to the FreeDB query for
that band to the band page.
3) Supply criteria for what kind of pages about albums are acceptable --
provide good examples. For instance, a detailed discussion of the music on
a particular album, with excerpted lyrics, notes etc. is certainly
acceptable. In such a discussion, a track listing could also be added to
Please note: This is not at all intended as an offense against the Albums
WikiProject. Good, comprehensive articles about albums should most
definitely be added. What I believe we should avoid is to turn Wikipedia
into Everything2 and to import everything that could possibly at some
point be turned into an article. This is also not a general policy against
bot import of articles, only in this case, where there is already a
collaborative open content project that fulfills the need perfectly and no
point for us to duplicate its work.
Even if this policy is not implemented, I will point out at this juncture
that I am strongly opposed to an import of the FreeDB data, should that
ever come up. But to be consistent and to avoid unnecessary work, I think
we should apply these rules even to existing, manually added album pages.
(Moved from wikien-l to wikipedia-l; discussion of revamped alphabetical
page index affects all languages.)
On dim, 2003-02-16 at 17:17, Ray Saintonge wrote:
> Brion Vibber wrote:
> >How about something like the alphabetical index
> >for the online AHD: http://www.bartleby.com/61/s0.html ?
> That would be a definite improvement over what we don't have now!
Okay, very preliminary version (code is in CVS):
Note that the test wiki contains nearly all pages starting with 'A', so
the index seems a little oddly weighted. ;)
There's probably some wiggle room in the ideal number of links per page
and whatnot. It needs to be made prettier, with backlinks to the top
level index and forward/back browsing, but the basic functionality is
Also we need to get a proper sorting system in (see my recent post on
wikitech-l); for instance if I put this on the Esperanto wiki all the
accented letters pile up at the end instead of in their proper places:
Other things: currently the list includes redirects. Some redirects
should definitely stay -- alternate names that would not appear near
each other, for instance. Others (spelling, caps variations) could maybe
be dropped, but that's harder to do consistently. Or more simply, we
could just italicize redirects or something.
The generation of the top level index is currently pretty inefficient;
it makes a separate database query for each chunk of 480 articles, and
takes a while to generate on a wiki with 100,000+ articles. Before
putting it on the English wiki live, it'll need to have some sort of
caching mechanism if it can't be made a lot faster.
Here's a saved copy of the toplevel index for the big English Wikipedia
just to give an idea of scale (the links don't work):
-- brion vibber (brion @ pobox.com)
On Thursday 27 February 2003 05:33 pm, Erik Moeller wrote:
> Even if this policy is not implemented, I will point out at this juncture
> that I am strongly opposed to an import of the FreeDB data, should that
> ever come up. But to be consistent and to avoid unnecessary work, I think
> we should apply these rules even to existing, manually added album pages.
I have no problem with your proposed policy (at least for en.wiki) but
wouldn't it be a good idea if we somehow collaborated with FreeDB? It would
be great if at the end of a freedb entry there was a link to a Wikipedia
article on the album. Just thinking out loud.
The usual at [[February 21]]
Wikipedia supports HTML comments. You can enclose text in
<!-- and -->. This means that while the text will still be visible in
wikisource, it will not be visible on the displayed page.
I see in many articles that people add comments like: "To do: .." or
"needs to be expanded" or "who was this?". Some pages also have "Notes to
Wikipedia editors" and the like.
In case of detailed discussions, this should of course be moved to the
Talk page. But if it is useful to have directly in the text but only
useful for editors, we should use HTML comments for these kind of meta-
remarks. A non Wikipedia editor should not be exposed to meta-content like
So when you see such a remark and don't want to delete it, please enclose
it in <!-- and --> to hide it from the rendered page, but not from those
who edit it. You *must* use this exact character sequence, the shorter
<!- foo -> or other variants like <- foo -> will *not* work.
Brion Vibber wrote:
>Wouldn't it be more sensible if [[kingdom (biology)]]
>_automatically_ displayed as "kingdom", and in the
>much rarer cases we had to add a pipe to force the
Yes that would be much more sensible and unless there
is an objection I say go ahead and implement it (with
the proper announcements to Wikipedia News on meta of
>What about handling of namespaces and interwiki
>links? Currently they're displayed be default,
>and the pipe trick strips them just like
I rarely ever want to actually display any namespace
(including interwiki ones) other than the various talk
namespaces. IMO all non-talk namespaces (wikipedia,
user, special and interwiki) should not displayed by
What about all the piped links that are already in
Wikipedia? Will all instances of [[kingdom (biology) |
kingdom]] that are in articles right now be converted
to [[kingdom (biology)]] but displayed as
<u>kingdom</u>? Or would [[kingdom (biology)]]
automatically be converted to [[kingdom (biology) |
kingdom]] in the wiki code upon save? Or would we keep
all cases of [[kingdom (biology) | kingdom]] and
still support that syntax but also support [[kingdom
(biology)]] being displayed as just <u>kingdom</u>
without converting the wiki code to [[kingdom
(biology) | kingdom]] at save?
What would also be nice is the extend the pipe trick
for comma titles. IMO to follow the logic of your
proposed change [[Auburn, California]] would
automatically become [[Auburn, California | Auburn]]
but that may brake many links that already intend to
display the whole link name. So just to make linking
easier for at least those in the know perhaps
[[Auburn, California | ]] could be displayed as just
<u>Auburn</u> but in the wiki code it could still be
[[Auburn, California | ]] so that newbies can figure
out the trick. Yeah I know this would be inconsistent
with the proposed change in how the pipe trick works
with parentheticals but it is still tedious to type
[[Auburn, California | Auburn]] all the time.
-- Daniel Mayer (aka mav)
I added many events to [[February 10]] and updated all
the year and many of the other pages linked from that
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
I'm currently having an argument in [[Talk:List of communities in Quebec]].
This morning, I moved the article that Ron Davis had created from its rather
unwieldy title of [[Communities of the Province of Quebec, Canada]]. I did
this for the following reasons:
1) the title [[Communities in the province of Quebec, Canada]] is
2) the title List of communities in Quebec matches the format [[List of
cities in Canada]];
3) it has the word "List" in the title (an article "Communities..." etc.
would ordinarily be expected to be about the communities, e.g. municipal
politics and suchlike; compare [[List of popes]] etc.)
Cf. [[List of Georgia counties]].
Ron seems to have taken great offence at
this, believing some kind of political motive, and moved it back (by copying
and pasting, not the move tool.) Further, he seems to think it's "his"
I think I'm right, but I'm reluctant to try this again without some backup
for fear of an edit war. Help please?
Some discussion has occured in [[Wikipedia talk:Manual of Style (dates
and numbers)]] about the formats of dates; i.e., whether or not
[[January 2]], [] is American-Imperialist. (My feeling: yes, but
that's not the only reason I like it.)
A suggestion was made to allow date strings to be wrapped in <date> -
</date> tags which the Wikipediware will parse and render properly. I
have written a Perl routine to not only do this, but also return either
the American or the European format, based on a flag set in each user's
How would I go about adding this routine to the Wikipediware?
Should I even bother adding this routine to the Wikipediware?
Does anyone care?
Sean Barrett | The more you sweat in peace,
sean(a)epoptic.com | the less you bleed in war.