Last modified: 2011-04-30 01:16:48 UTC
this is utterly trivial, but I just noticed that the 'Special:Watchlist/edit' page uses ASCII sorting rather than natural language sorting. This mostly has to do with capitalization: the pages 'Historic Anglicans' and 'Historic animals' would end up nowhere near each other if you have a number of other pages beginning with 'Historic...'. I think this is trivial to fix in PHP, no? plus, while you're at it, could you get rid of the absolutely spurious list bullets? list bullets before checkboxes are pointless (since the checkbox itself will do double-duty as a bullet), and IMO, they look dorky. :-)
(In reply to comment #0) > I think this is trivial to fix in PHP, no? Unfortunately it is not. Getting and setting the correct locale for the user language is next to impossible in PHP, because it just uses the underlying system's locales verbatim. > plus One issue in one bug please.
err... maybe I'm confused, but (a) wikimedia projects are already generally speaking localized (en.wikipedia, es.wiktionary...), and (b) each user can set their language localization in their preferences (which I'm assuming is stored in an easily accessible cookie, and probably defaults to the the encoding of the project they're working on). given that (and cribbing from the PHP manual at http://www.php.net/manual/en/function.sort.php): <?php setlocale( 'LC_ALL', $lang_code ); // $lang_code form a cookie or project, as above, possibly LC_COLLATE would be sufficient sort( $array_of_watchlist_article_names, SORT_LOCALE_STRNG ); // ...continue processing the list normally ?> might be a few extra lines of housekeeping code needed, but otherwise why wouldn't something like this work? also, I think this behavior changed in PHP 6, so there might need to be code to account for that.
(In reply to comment #2) > setlocale( 'LC_ALL', $lang_code ); // $lang_code form a cookie or project, See the examples at: http://www.php.net/manual/en/function.setlocale.php Also: "Different systems have different naming schemes for locales." We are not going to maintain list of codes for each language in each supported platform.
(In reply to comment #3) > (In reply to comment #2) > > setlocale( 'LC_ALL', $lang_code ); // $lang_code form a cookie or project, > See the examples at: > http://www.php.net/manual/en/function.setlocale.php > > Also: "Different systems have different naming schemes for locales." > > We are not going to maintain list of codes for each language in each supported > platform. > To clarify: we'd need a one-to-one mapping from the languages that MediaWiki support to system locales. Such a one-to-one correspondence might not exist for all languages, and naming schemes for locales vary across systems, which makes creating and maintaining this mapping pretty much impossible. A more viable option would be to specify the sort order for each language in the language file; leaving it up to the i18n folks to decide whether this is desired.
a 1:1 mapping would be nice, but not necessary: you make the best mapping you can, check if the mapping fails, and use the (current/default) ASCII sort where it does. Special:watchlist/edit is not an article page: it's unique to each user, so you don't need to worry about consistency the way you need to with more public pages. but never mind. as I said, this is a trivial annoyance, and it's apparently less trouble to live with it than to discuss it.
*** This bug has been marked as a duplicate of bug 164 ***
