"Simetrical" Simetrical+wikilist@gmail.com wrote in message news:7c2a12e20803050907x3895a8f8o7d900a5fb589571f@mail.gmail.com...

On Wed, Mar 5, 2008 at 11:56 AM, Raimond Spekking raimond.spekking@gmail.com wrote:

...

The intention was to give this extra flexibility. You can use multiple columns now and sort in any manner the community finds it useful.

But I will think about/work on your suggestion to use messagekeys instead to avoid duplication of the special pages list.

But what happens when an extension adds a special page? What happens when a new special page is added to the core software? It will be put at the end until someone manually alters the list. Maybe you're giving a little extra flexibility, but on the other hand you're forcing more ongoing maintenance to get it to work nicely.

As a wiki administrator, for something as trivial as this, I would certainly prefer to have a sensible ordering that I *couldn't* change than a modifiable ordering that I *had to* change. Especially given that with an appropriate hook or two, any changes I really wanted could be done by extensions.

I've been planning to rework the Special:SpecialPages page for a while now, but it looks like someone has beaten me to it! In case it's any use, here's how I was planning to implement the change:

Each special page would have an extra 'section' parameter added to it's definition, e.g. 'user-management'.

The special page list would group items under their sections, in alphabetical order. If a section only has one item then it is added to a special 'miscellaneous' category instead, to stop a list where there are loads of single-element sections.

The labels for each section are pulled from the MediaWiki namespace, at sp-section-name, e.g. 'sp-section-user-management'. If no string is defined, then hyphens become spaces and each word is capitalised (or rather, put into appropriate title-case for the interface language).

Extensions also specify a 'section' when they are defined. These may be one of the built-in sections or a new one. The fact that sections with a single entry are collapsed into the 'miscellaneous' section avoids the problem of having many extensions that each specify a different section, whilst stopping extensions from being restricted to a potentially fairly narrow group of built-in sections.

A global variable $wgSpecialPageSectionOverrides allows sections to be overridden if necessary (key is name of special page, value is new section to put it in).

The page output is nicely wrapped in CSS classes so that layout can be modified (columns, boxes, etc.).

I hope some of these notes help with the implementation of this feature. I'd be happy to contribute further, either to discussions or coding, if that would be useful.

- Mark Clements (HappyDog)

On Wed, Mar 5, 2008 at 1:16 PM, Mark Clements gmane@kennel17.co.uk wrote:

If no string is defined, then hyphens become spaces and each word is capitalised (or rather, put into appropriate title-case for the interface language).

I don't see any reason to avoid our usual method of printing messages that <arent-defined>. It's ugly, but it should be, because something or other has broken. I doubt it would be an issue anyway, so adding special logic to handle it is pointless and bloaty.

A global variable $wgSpecialPageSectionOverrides allows sections to be overridden if necessary (key is name of special page, value is new section to put it in).

I'd say just go with a hook in the SpecialPage constructor. It seems simpler and more flexible. I don't think such a narrow feature needs its own config variable.

On Wed, Mar 5, 2008 at 7:37 PM, Mark Clements gmane@kennel17.co.uk wrote:

This is slightly different though. As the section names are extensible, we would be in a situation where every extension that is not in one of the built-in section would need to include the interface text for it's section heading. If two extensions in the same section differ in their default text, which one has precedence? What happens if this section name is later added to core? If extensions can just use a sensible English name knowin that the default rendering is normally sufficient then it makes things a lot easier to maintain, plus we still have the full flexibility of the localisation system. Once this is in use, I envisage that sections that have a sufficiently high number of common extensions in them will have default labels added to core, even if core doesn't have any extensions in that section itself.

I would say that maybe you should avoid such deliberate decentralization and anarchy to begin with. Create a fixed list of core categories, and provide a mechanism for extensions to add their own if they have some reason (for instance, if they create many special pages). The expectation should be that most extensions should not consider adding any categories beyond the default, and those that do should prefix the keys as usual to avoid conflict. It shouldn't be focusing on each special page making up its own mind with special provisions for things like some loner page deciding it wants to be in its own category. Picture categorization by a single small group of people in a unified fashion, with a few independent extensions needing the ability to slightly expand on the groupings -- because that's the reality, not a ton of independent pages that don't know about any of the others.

To be honest, I added that in response to the e-mail, where it seemed to be desired functionality. I'm not sure how useful it would be in practice. I will leave it out for now.

Makes sense. Too much flexibility can definitely be a bad thing: it's always a tradeoff against uniformity and simplicity, which have their own merits.