https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #198 from Aryeh Gregor <simetrical+wikib...@gmail.com> 2010-07-26 21:43:21 UTC --- (In reply to comment #187) > Drop this tacking immediately in the PHP code: the cl_sortkey is only intended > to store the clear-text sortkey "hint" specified in {{DEFAULTSORT:sortkey}} or > [[category:...|sortkey]] to override the sort order, and this clear-text > sortkey is not really a true sortkey but a sort hint to override the default > sort order. > > For example in people's names whose page name is "FirstNames LastName" but > that > we want to sort as if they were "LastName, FirstNames" by indicating only > {{DEFAULTSORT:LastName !}} (it should not needed to include the FirstNames in > the wiki text, as this sort hint will not be unique and the group of pages > using the same hint will still need to sort within this group using their > natural order). Even in that case, there's no need to bogously tack the > cl_from > field in the stored field. How do you propose this be implemented? We would need some character that sorts before all characters that can legitimately occur in a sort key. (In reply to comment #197) > I note that you have started to define the Collator class as the Language > class. This is completely provisional and can easily be changed later. As far as I understand, I'm not the one who will work on it. > But really, to test a complete implementation of the CollatorFactory, you'll > need to be able to expose it in the two optional builtin parser functions that > I described. As this can be clearly developped separately even if you start > with a stub for the factory, and tested with the very basic Parser Functions > installed on a test server. > > So I maintain my position for the non-risky ParserFunctions (notably also > because it will be simpler for an existing non-Wikimedia installation of > MediaWiki to install the simple functions only, without upgrading to the new > schema immediately, knowing that the factory can also be a basic stub as well > on these installations). Upgrading the schema will be handled by running maintenance/update.php, which must be run on every update anyway. We typically have a number of schema changes in every release, and those always must be applied when deploying the new code. So this is not an issue. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l