https://bugzilla.wikimedia.org/show_bug.cgi?id=28397
Bug #: 28397
Summary: Allow collation to be specified per category
Product: MediaWiki
Version: wikimedia-deployment
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: Normal
Component: Categories
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: bawolff...@gmail.com
CC: simetrical+wikib...@gmail.com
Classification: Unclassified
It was suggested on irc by Skalman12 (as well as in some other places.
Presumably bug 164, but I don't feel like reading the 5 billion comments on it)
that it should be possible to override the collation. Specifically, the
Wiktionaries would find it useful.
Its not entirely clear if this is a wontfix, but i think its possible.
As a further aside, This also won't be very useful until some future time when
we actually have multiple useful collations.
Suggested ways of doing this that I've heard so far:
*Global config variable that provides specific categories that use different
collation.
Downside: Thats something very specific to put in LocalSettings.php - It'd
probably be a long list, it would also probably change on a regular enough
interval that the number of shell requests would be annoying. A maintenance
script would also have to be run each time this is done
*magic word/parser func - {{#usecollation:uca-german}} on a category page.
Upside: Wiki users can specify what collation easily. Could store the relevent
info in page_props table. Could re-fresh the sorting of categorymembers with
the job queue. Seems kind of the wiki-way of doing such thing, rather similar
to how hidden categories work.
Downside: Well the categories are being re-sorted, the category page becomes
kind of borked. Would be a good vandalism target to do this to
[[category:Living people]]. Thus we probably want to limit collation changes to
admins, so people don't abuse it.
*put config info in system message (mediawiki namespace page).
Upside: Wiki users can configure it them self. Limited to admins so people
don't be stupid.
Downside: Not as easy to trigger the re-sort category jobs. Not as clear to the
end user why category x is sorted differently from category y. And
configuration in system messages is kind of evil.
*Use a special page. (Similar to how we do page protection). Could have a link
in the toolbox for sufficiently privileged users to "Change category sorting".
Upside: Kind of a nicer UI. Could present a list of valid choices to user,
instead of expecting them to know, along with help info about the various
choices. Can have a separate right for changing collations.
Downside: Slightly more complex to implement, would require a new db table to
manage the info. Also, to the average user wondering why this category sorts
differently then others, its not as obvious as the parser func method, since
nothing different in page source (although could have a notice similar to that
of page protection perhaps, not sure if that'd entirely make sense).
---
I personally think the special page approach is the best way to do this
(assuming that we do do that).
>From a backend prespective, what would need to be done (I think anyways):
*Collation::singleton would have to be changed to accept an argument, for what
category it is. Probably would need a change in name to to something more
appropriate if its no longer a singleton.
*Collation would probably need a static method to map category names to
collation name, so we can full out cl_collation field of the categorylinks
table properly.
*Would need to implement support in the job queue to fix cl_sortkey field when
we change it for a category. Probably not that hard since we have a maintenance
script that does something close to that already. The relevant maintenace
script expects everything to use the same collation name if i recall, so that'd
also have to be changed.
Thoughts?
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
