On Mon, Mar 19, 2012 at 12:23 AM, Bawolff Bawolff bawolff@gmail.com wrote:
Message: 1 Date: Sun, 18 Mar 2012 13:02:53 +0800 From: Liangent liangent@gmail.com To: "A list for announcements and discussion related to the Wikimedia Labs project." labs-l@lists.wikimedia.org, Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] [Labs-l] New project request Message-ID: CAJ23o9ijb2TrfW6Gk+XTaVZQwHfoST0M4EE2UD4A5xcmdXVLdQ@mail.gmail.com Content-Type: text/plain; charset=UTF-8
[..]
What do you think is a better approach to implement this? In 1.16 version I had to create another DB table but in modern MediaWiki, categories have better sorting support so another choice (which seems more natural) is to patch MediaWiki and change $wgCategoryCollation to an array to support multiple collation at the same time. Maybe another choice is to reuse the existing categorylinks table in an extension but this requires MediaWiki to have enough hooks.
Hmm interesting. I could definitely see how it could feel "natural" that this be in core. I could also see fairly good arguments for it being an extension. Either way I think it should (ideally) integrate with the categorylinks table. As it stands though, the unique index on (cl_from,cl_to) would probably prevent that [change to a unique index on cl_from,cl_to,cl_collation?]. Otherwise I don't see any major hurdles. If going the extension route, hooks can always be added if there are not enough. Some maintenance scripts would have to be changed, and some changes to the Collation class would have to be made, but I don't think they would be super-complicated changes by any means.
On a related note, there's also a bug that wants sort collations to be specified per category (but still only 1 collation to a category) - https://bugzilla.wikimedia.org/show_bug.cgi?id=28397
-bawolff
This is my quick work and I'll push it for review after Git migration. Comments are welcome.
-Liangent