On Mon, Mar 19, 2012 at 12:23 AM, Bawolff Bawolff
<bawolff(a)gmail.com> wrote:
Message:
1
Date: Sun, 18 Mar 2012 13:02:53 +0800
From: Liangent <liangent(a)gmail.com>
To: "A list for announcements and discussion related to the Wikimedia
Labs project." <labs-l(a)lists.wikimedia.org>rg>, Wikimedia
developers
<wikitech-l(a)lists.wikimedia.org>
Subject: Re: [Wikitech-l] [Labs-l] New project request
Message-ID:
<CAJ23o9ijb2TrfW6Gk+XTaVZQwHfoST0M4EE2UD4A5xcmdXVLdQ(a)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