User "Simetrical" changed the status of MediaWiki.r86100.

Old Status: new
New Status: fixme

User "Simetrical" also posted a comment on MediaWiki.r86100.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86100#c16009
Commit summary:

(bug 28540) revert r83544 - It really breaks things when using uca-default 
collation (As noticed on tw)

Various functions (particuarly the getFirstCharacter ones) all expect to have 
the human readable sortkey.
Passing them the binary sortkey results in the getFirstChar headers to be 
totally wrong. It also
causes paging not to work since the sortkey gets double encoded.

This issue probably wasn't noticed, since it wouldn't be visible on the 
uppercase collation
as uppercasing the first letter won't affect the first character headings, nor 
does double uppercasing
something matter.

Also changed one of the variable names from $rawSortkey to $humanSortkey as it 
confused me
(raw as in before turning to binary, or raw as in the real non-human readable 
sortkey)

Comment:

This is wrong for the reason I gave in the r83544 commit summary.  I'd suggest 
that you use cl_sortkey if cl_collation is the empty string, otherwise use 
getCategorySortkey() as at present.  Otherwise it will break if the 
categorylinks migration script hasn't yet run, or hasn't yet finished running.

You're right that my commit was wrong, though.  Apparently I misunderstood "raw 
sortkey" myself, although I wrote the code.  I thought it meant "possibly 
binary" rather than "unprocessed".  I'd suggest that someone look through all 
the sortkey stuff and make sure it's clear in all cases whether you're dealing 
with 1) cl_sortkey_prefix, 2) the output of Title::getCategorySortkey(), or 3) 
cl_sortkey.  Otherwise you'll probably see more confusion and bugs like this.

_______________________________________________
MediaWiki-CodeReview mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Reply via email to