Æ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.
- 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.
- 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.
- 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)