An item that's been burning on my bug fix todo list for some time is
sort order.
Alphabetical ordering is used in the user account list and the 'all
pages' list (rarely used, but people like that kind of index and an
improved version should be made -- which makes correct ordering more
important), and maybe here and there elsewhere. Sort orders can vary
from language to language, and of course we have a mix of latin1 and
utf-8...
MySQL does support selectable modules for sort order -- but only on a
server-wide basis. This would not handle our multiple language issues at
all even if we switch everyone to utf-8; there is no 'universal' sort
order that will work right for every language.
One possibility is to pull another ugly hack: add a canonical-sort-key
field and have a per-language function to munge strings into something
that will sort correctly in a traditional ascii-order sort.
Better suggestions are welcome.
-- brion vibber (brion @ pobox.com)
OK, if we're going to have categories (which I'm basically all in favor
of), I'd like to point out that IMHO it should be a separate table in
the database for these, at least for the links. Look at the mess we
(I;-) made with the language links.
I imagine the following tables
# "categories" : cat_name, cat_id
# "cat_structure" : cat_parent_id, cat_child_id
# "art_in_cat" : article_id, category_id
That means we can have, for example, "Biochemistry" as child of both
"Chemistry" and "Biology", as it should be. That would require several
SQL queries, though, in order to display something like
"Science/Biology/Biochemistry/Proteomics". The alternative would be
# "cat_structure" : category_id, category_full_parent_name
and the parse the category_full_parent_name (e.g.
"Science/Biology/Biochemistry") for "/" in order to display something like
"[[category:science|Science]]/[[category:biology|Biology]]/[[category:Biochemistry|Biochemistry]]/[[category:Proteomics|Proteomics]]"
which will be a lot fater, but probably harder to maintain.
In any case, a Special Page should be used to manage both categories
itself and the articles that belong into them.
*If* we won't have separate tables (for whatever reason), I suggest we
do it like this:
# There's an (editable) category namespace; maybe we won't have to make
it "special" at all, though; I am talking more about an agreement on
that prefix rather than yet another namespace
# On saving an edit to [[category:crap]], all articles linked from there
get "[[category:crap]]" appended to their text, and the appropriate link
set in the linked table.
# On saving an article containing "[[category:crap]]", this article is
appended to the list on that page, if it is not there already.
# All these "edits" could show up on Recent Changes, commited by
"system" or something.
I agree it looks a little patchy (because we don't use a new table!),
but it will be much faster to look up the "what categories does this
page belong to" when displaying it. It will also reduce the display of
the category page to a normal article display.
Magnus
Heh, I've found out another unused(?) variable causing some
rubbish to appear on the screen, namely $rcrows on line 72
of SpecialContributions.php:
if ( 0 == $nCur && 0 == $nOld && 0 == $rcrows ) {
And this is the only place in the _whole_ code where
this variable appears.
Is the code in CVS up to date?
Regards
Youandme
P.S. I'm using PHP 4.3.0
Is it a killer to all the bugs? :-)
Hello all,
Perusing Wikipedia articles I see more and more of them have not
been updated (reviewed) for a long time. It is quite obvious
with 100000+ articles.
Suppose I wanted to watch out and review indecently old articles.
Perhaps the Ancient Changes list/page (the equivalent of Recent Changes)
might come in handy.
Regards,
Kpjas.
Hello all,
There is a harmless bug in a succession of articles incorporating
tables with Scientific classification ([[Human]], [[Carnivore]],
[[Gorilla]] etc)
s/cellpading/cellpadding/
It doesn't impair the layout of the tables.
Regards,
Kpjas.
While reinstaling Wikipedia on my system
I've encountered a small problem with the scope of $mlink variable
(causing error messages across recentchanges page)
I guess that it is obsolete since it was used to hide minor changes
on Recentchanges and Recentchangeslinked pages.
I suggest commenting out (if not removing) line 155 from SpecialRecentchanges.php
$note = str_replace( "$3", $mlink, $note );
The value of $mlink was set by another functions and passed "illegaly"
$3 corresponded here to the third argument of extinct version of 'rclinks' text.
Seems that this solution works for me for the time being.
Alternative: passing $mlink as an argument of rcDayLimitLinks function
(tested with success as well, should I send a patch for that solution?)
Youandme
In case of syntax error one shouldn't have to press Back (and cause
previous query to be resubmitted).
There should be textarea with contents of submitted query
and a Submit button also in case of submitting wrong query.
We already have almost everything we need for categorization of articles,
except for
1) A category namespace.
2) Some code to render links to this namespace differently than normal
links, and some code to render pages within the category namespace.
How it would work:
You add a link to
[[Category:stub]]
[[Category:movie]]
[[Category:painter]]
or whatever; on the page this is rendered a bit like the interlanguage
links, separate from the textual content:
This article belongs into the following categories:
[[Category:stub]] - [[Category:movie]]
etc.
When you visit a Category page, you then automatically get a two-part page
that consists of
1) Editable category description
2) Result of the "What links here" query
This would allow us to make many, many pages more effective:
- Find or fix a stub could be replaced with [[Category:Stub]] in stub
articles.
- "Links to disambiguation pages" could be replaced with
[[Category:disambiguation]].
- "Pages in need of attention" could be replaced with [[Category:Work
needed]].
All these pages currently work very ineffectively because links are often
not removed when they need to be, and the pages get long and unwieldy. I'm
hesitant regarding "Votes for deletion", but with some additional work
that could also be changed to use the new scheme.
Aside from that, we could start categorizing the Wikipedia content itself
more effectively. Many of our "lists of" could be changed into auto-
generated category pages. List gets too long? Then nest categories by
adding a category tag to a category page.
Thoughts? Objections? I consider implementing this myself if nobody cares
enough to do it.
Regards,
Erik
Please change regular expressions used to match URLs so
that final `)' isn't matched.
Probably some other characters should be disallowed too,
like comma and dot.
I've been chugging away some more at updating (well, rewriting) the
UseMod conversion script, and have started adding some automated testing
to make sure that various operations are working as intended.
(Very prelim code in cvs: importUseModWiki.php, importTests.php in the
maintenance subdir.)
We would probably benefit from a unit test suite that could
automatically test the various pieces of the wiki code more or less in
isolation. (Though we have a lot of globals, funky dependencies, and
mixing together of backend and interface code which makes testing rather
harder... we should clean this stuff up anyway!)
http://c2.com/cgi/wiki?UnitTestinghttp://c2.com/cgi/wiki?PhpUnithttp://c2.com/cgi/wiki?UnitTestsAndDatabases
-- brion vibber (brion @ pobox.com)