Any ideas?
----- Forwarded message from Stephen Thornton <Stephen.Thornton(a)mic.ul.ie> -----
From: Stephen Thornton <Stephen.Thornton(a)mic.ul.ie>
Date: Mon, 9 Sep 2002 12:26:14 +0100
To: "'comments(a)nupedia.com'" <comments(a)nupedia.com>
Subject: Popper Entry
Hi There,
I'm the author of the Popper entry in Nupedia.com, and I haven't been able
to access it for some time now.
Can you shed any light on this?
Regards,
Stephen Thornton
Dr. Stephen Thornton,
Co-Ordinating Director of Postgraduate Studies in the Arts,
Department of Philosophy,
Mary Immaculate College (University of Limerick),
South Circular Road,
Limerick,
Ireland.
http://www.mic.ul.ie/
Tel: +353 61 204341
Fax: +353 61 313632
----- End forwarded message -----
> I reported this bug a while ago. Attempting to move a page with
> spaces in its name produces a URL with spaces...
Yes, I'm showing that as a still open bug in Sourceforge.
It will get fixed eventually. I'm just working on things I
consider more important for now.
I reported this bug a while ago. Attempting to move a page with spaces in its
name produces a URL with spaces. This elicits the error "400 Bad Request Bad
Request Your browser sent a request that this server could not understand.
The request line contained invalid characters following the protocol string."
Changing the spaces to plus signs makes it work.
phma
>> Would that work?
>No, it wouldn't.
You're probably right; too much computation for every article save
operation. On the other hand, it is not of utmost importance that
every article always carries the precisely correct and current topic
classification; rough approximations are good enough. New pages can
then still be assigned topics quickly. I doubt that topic assignments
of a given article would change very often anyway. And every couple of
weeks or so, we can recompute every article's topic from scratch in a
breadth first manner.
Would that work?
>As for saving time for regulars, that may be a very limited benefit.
>We all have certain subject areas where we tend to track things and
>tend to ignore topics outside of that.
Yup, but I would like to see a list of the 10-20 daily edits in my
subject area without having to wade through 2000+ RecentChanges
entries.
Axel
> That reminds me. Whatever happend to the code for grouping edits
> on the recent changes page? I remember you made a test site and
> then ... nothing?
I'm still not happy with my latest code, and I've been working
on other matters. But I'll get back to that shortly, because I
think I have a solution to the one thing I didn't like.
>> So, why not add a new field to the database, for each
>> article, where LanguageLinks and the like can be "collected"?
> Please put the language links in a separate table, otherwise
> you are violating the first normal form of database design
> theory. Any introductory text on database design will tell you
> why that is bad.
The Wikipedia database layout is already pretty far from
normalized (mainly because MySQL is too slow on joins), but if
I did add this feature I would make it a proper one-to-one
mapping table. I'm not yet convinced that it would be worth
the effort, though. I'm more inclined to think that the
international wikis should be more independent and encapsulated.
>I like the idea of links for categories ('biography', 'country',
>'mathematical theorem', 'book', 'movie', ...) by the way.
We discussed tings like that early on, and initially rejcted it
as an attempt to categorize articles in a non-wiki way; we wanted
different organization schemes to evolve out of normal wiki
editing and linking, rather than imposing order from the outside.
But it might be time to revisit the idea, because at 2,500 edits
a day and growing, it's just no longer possible for one person to
keep track of edits to articles he's interested in, and subject
is the only filter that really makes sense for reducing that data
to a manageable level. I'd still like to see if we couldn't
build those subjects automatically in some way based on links in
the database.
> Nope. I mean that if, in German, [[Zeug]] links to [[en:Stuff]],
> _then_ the en: article [[Stuff]] should automatically link back
> to [[de:Zeug]]. Now, if someone linked the [[Stuff]] article to
> its Esperanto counterpart, then the eo: article should link back
> to [[Stuff]], and "following" the language links from there, link
> to [[Zeug]] as well, which then would link back to the eo: article
> as well.
I think Ray understood what you were suggesting; I think you
missed what he was saying--namely, that it is an incorrect
assumption that because English article X links to German
article Y, that therefore German article Y should link back
to English article X. Different wikis will divide up the
space of ideas differently, as do different languages and
different cultures. Disambiguation pages will have entirely
different sets of links in each language, yet it still might
make sense for a language link to go to a disambiguation page
if there's some overlap. It's very likely that many one-page
topics in the foreign wikis will be split into several pages
on the English wiki, and some topics will be split further on
foreign wikis than they are on the English one. At any rate,
the simplistic one-to-one link idea will probably create as
many problems as it solves.
>> Please put the language links in a separate table, otherwise
>> you are violating the first normal form of database design
>> theory. Any introductory text on database design will tell you
>> why that is bad.
> I doubt that many of us have such a text in their libraries.
> OTOH Wikipedia is a real database rather than a theoretical one
> so the rules for theoretical databases shouldn't apply. :-)
I don't have Jan's experience, but I do have Date's book on my
shelf, and a few others, and I do take database design seriously.
Unfortuneately, history and performance sometimes force decisions
that one might not have otherwise made for data integrity reasons.
<anotherReallyGreatIdea>
I have noticed that the LanguageLinks, while working great, start
looking a little odd in the articles; they are also hard to manage once
the need arises, and it will, as soon as more wikipedias are switched to
the new software. LanguageLinks should then be cross-checked and
maintained (semi-)automatically; otherwise, they might drift into utter
chaos.
Now, if anyone read my recent mail on wikipedia-l ("And now for
something completely different"), I actually argued for *even more*
links like that, for "technical categories" so to speak, like
"biography" etc.
So, why not add a new field to the database, for each article, where
LanguageLinks and the like can be "collected"? Just another text field
on the edit page, it could be parsed on each Save into a more
machine-readable style, and be "regenerated" into text for editing. Such
a field could well hold "This article is based on..." information as
well. And it could store tags like "stub", if we want to.
</anotherReallyGreatIdea>
Magnus
I just created an account on the German Wikipedia and am setting my
preferences. I see the following notice:
Geben Sie die Anzahl der Stunden ein, die zwischen Ihrer Zeitzone und
U.S.-Westküstenzeit liegen. Für Deutschland "9" eintragen.
But on the English Wikipedia it says:
Enter number of hours your local time differs from server time (UTC).
Why is the German Wiki on Pacific, when the English one is on UTC? How is
someone in Brazil or Australia supposed to answer the question, since
southern DST is out of phase with northern?
phma