Last modified: 2013-09-04 05:00:49 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T26574, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 24574 - Sort order in Special:ListUsers should be case-insensitive
Sort order in Special:ListUsers should be case-insensitive
Status: NEW
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-28 21:20 UTC by Gnu1742
Modified: 2013-09-04 05:00 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Gnu1742 2010-07-28 21:20:05 UTC
Until now Special:ListUsers sorts Users in this way:
AAA, AAB, ..., ABC, ..., AZZZZZZZZZZZ,AAa,AAb,...AZZZZZZZZZZZZz,...,AZzzzzzzzz,...,Aaa,...
In short: the aaa-Usernames, differing only in upper-/lowercase-letters appear in 2^3=8 total different places of the log.

It should be
AAA,AAa,AaA,Aaa,...

The ranking depending on upper-/lowercase-letters makes it nearly impossible for Oversights to do a efficient search for libelous Usernames: The vandal only has to create the same name over and over again with different combinations of upper-lower-case letters and the bureaucrat/oversight has to search in dozens of places in the logfiles.
Comment 1 db [inactive,noenotif] 2010-07-29 20:10:39 UTC
This looks like a duplicate to the collation bug 164, because this change the sortorder of the items. The current behaviour is the same as for Categories etc.
Comment 2 Bawolff (Brian Wolff) 2010-07-29 21:47:46 UTC
(In reply to comment #1)
> This looks like a duplicate to the collation bug 164, because this change the
> sortorder of the items. The current behaviour is the same as for Categories
> etc.

I would call them separate bugs, since the solution currently being worked on for category pages will not fix this bug. (afaik)
Comment 3 Roan Kattouw 2010-08-03 20:32:31 UTC
They are indeed separate bugs, but this fixing this one would require disproportionate resources for marginal benefit. Suggest WONTFIX.
Comment 4 Gnu1742 2010-08-04 08:10:36 UTC
I doubt that the benefit is marginal: It would it make a lot lot more easier for Oversights/Stewards to look for libelous/harassing Usernames to get rid of them.

Could you please elaborate why this fixing requires 'disproportionate resources'?
I do not know the actual implementation in mediawiki, but in every programming language i recently worked in there are sort-algorithms which do not make a difference between 'A' and 'a', so i guess there should be one for php.

Anyway: People don't expect this sorting order. They are used to other orders from their phone-book or printed encyclopedias.
Comment 5 Roan Kattouw 2010-08-04 11:42:27 UTC
(In reply to comment #4)
> I do not know the actual implementation in mediawiki, but in every programming
> language i recently worked in there are sort-algorithms which do not make a
> difference between 'A' and 'a', so i guess there should be one for php.
> 
Yes, you can sort case-insensitively in PHP just fine, but you can't (efficiently) do so in MySQL. Like with the category thing, we'd have to add a new column to hold the 'normalized' username and sort by that instead. For English 'normalized' can just be all lowercase, but for other languages you'll want to sort accented characters in all sorts of interesting ways.
Comment 6 Gnu1742 2010-08-04 12:15:14 UTC
OK, didn't know that the sorting was done in the database. Thanks for the update.
So probably a regexp search on the usernames could be helpful. Do you know if something like this exists (maybe even as an external tool)?
Comment 7 Roan Kattouw 2010-08-04 12:50:18 UTC
(In reply to comment #6)
> OK, didn't know that the sorting was done in the database. Thanks for the
> update.
> So probably a regexp search on the usernames could be helpful. Do you know if
> something like this exists (maybe even as an external tool)?
Regexp searches can't be done 'internally', as you might have guessed. It doesn't exist as an external tool AFAIK, but it shouldn't be too hard to write a toolserver tool that executes wildcard queries (SQL does allow those, they're just kinda slow in most cases) on the database or uses a dump of all user names to run regexes on.
Comment 8 Nemo 2013-09-04 04:58:28 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > This looks like a duplicate to the collation bug 164, because this change the
> > sortorder of the items. The current behaviour is the same as for Categories
> > etc.
> 
> I would call them separate bugs, since the solution currently being worked on
> for category pages will not fix this bug. (afaik)

Did it?
I also wonder how this interacts with bug 26396.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links