Ævar Arnfjörð Bjarmason wrote:
There are still numerous issues with this validation
feature, both
internal and external, I've pointed some of these out in the past.
1. The UI sucks
The text is changeable through the normal MediaWiki way. The colors etc.
are CSS.
When you turn on this feature, go to a random page and
click the
"validate" tab you're presented with this:
http://kohl.wikimedia.org/~avar/tmp/revisions.png
Well, apart from the black buttons, which seem to come from your
personal settings (?), you haven't define any topics to validate/rate,
which makes it kind of hard to display a list of these...
See:
http://magnusmanske.de/wikipedia/rate1.png
for how it would look like (again, color is CSS).
A form that, excuse me for saying so, looks like shit,
and furthermore
makes no sense at all, if you follow the 'See the validation
statistics for "Main Page" here' link you're presented with this:
http://kohl.wikimedia.org/~avar/tmp/validation.png
Again, no topics defined. No topics, no ratings. Of course the page
looks rather plain.
Again, something that makes no sense at all, and it
doesn't get any
better when you follow the 'Show my validations' link, then you're
presented with this:
http://kohl.wikimedia.org/~avar/tmp/overview.png
...and those numbers are supposed to mean..?
Again...
And it doesn't get any better, in fact, I've
been fiddling with this
thing for 20 minutes and still haven't figured out how to make it do
*anything at all*, it says things like "Your ratings have been
stored!" and yet it saves nothing to the validate table.
2. It's impossible to fully translate the UI
Please use wfMsg() for every string that should be translated, don't
hardcode messages in the code.
Is it, keeping up the high quality of your review, in any way possible
that you didn't use the latest version? Because that *does* use wfMsg
throughout.
The latest version is in CVS HEAD; copying it back to the 1.5 tree
should do nicely.
3. It's going to be slow
Here are some examples, with line numbers, of it making queries with
no LIMIT claues where the set of return values could get very large:
82 $res = $db->select( 'validate', '*', array(
'val_page' => 0 ), 'SpecialValidate::getTopicList' );
You omitted:
# NOTE : This query returns only the topics to vote on
So, if there are, say, fifteen topics defined, it returns fifteen
entries. This will, of cource, clearly overload our 100+ servers.
225 $res = $db->select(
'validate', '*', array_merge(
array( 'val_page' => $id ), $this->identifyUser($user) ) );
You omitted:
# NOTE : This query gets the votes for a single user on a single
page.
# Assuming most people will use the "merge" feature,
# this will be only a single entry.
$limit here is a user supplied value with no upper
limit enforced:
245 $b = array ( "ORDER BY" =>
"val_page,val_revision"
, "OFFSET" => $offset , "LIMIT" => $limit ) ;
246 $res = $db->select( 'validate', '*', $a ,
'getAllVotesList' , $b );
You omitted:
# Reads a partial vote list for this user for all articles
Yes, that one could become potentially large over time, except for the
LIMIT you quoted yourself. The default call (line 747) sets the limit to 25.
So, if we could please go back to the state of the feature *right now*,
which is basically the same as *before WikiMania*. If there's anything
to complain about, please tell me or (shock!) take a minute and fix it.
It's supposed to be a collaborative effort, though this long demanded
feature sure as hell hasn't see its share of it.
Magnus (state: slightly annoyed)
