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
