Page MenuHomePhabricator

Page status indicator should not be automatically sorted outside main namespace
Open, NormalPublic

Description

As the title states: Page status indicator should not be automatically sorted outside main space.

Page status indicators are a great enhancement and makes implementing status icons a breeze. They are normally sorted alphabetically, but this generates some aversion with users that use the indicators on their user pages; they have no way of controlling their ordering. There are LUA hacks being devised to allow some control in ordering, but that goes directly against the move to simplify indicators, negating the whole system. See https://en.wikipedia.org/wiki/Template_talk:Top_icon#Sorting

I understand the need for consistency in articles; that is probably the reason for automatically ordering them. However, this means having no control over them in user space, other then hacking around it by manipulating the name, which itself hits limitation in PHP sorting. Therefor I request that the auto-ordering only take place in main space, and be disabled outside main space.

Event Timeline

Edokter created this task.Mar 28 2015, 5:24 PM
Edokter raised the priority of this task from to Normal.
Edokter updated the task description. (Show Details)
Edokter added a subscriber: Edokter.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 28 2015, 5:24 PM
Edokter updated the task description. (Show Details)Mar 28 2015, 5:33 PM
Edokter set Security to None.
He7d3r renamed this task from Page staus indicator should not be automatically sorted outside main space to Page staus indicator should not be automatically sorted outside main namespace.Mar 28 2015, 6:35 PM
He7d3r updated the task description. (Show Details)

To be honest, I think this should not be implemented. Still, the request is not unreasonable, so I won't oppose if someone does it.

I recommend that users who want reliable custom ordering just place a single <indicator/> tag on their pages, with whatever content they want inside, in whatever order they want it.

matmarex removed a subscriber: matmarex.Mar 28 2015, 9:01 PM
Anomie added a subscriber: Anomie.Mar 28 2015, 9:03 PM

which itself hits limitation in PHP sorting

This needs more explanation. What it's referring to is the fact that PHP's SORT_REGULAR gets confused when asked to sort things with both numeric and non-numeric keys due to violation of transitivity. For example: 3 < "10x", "10x" < "foo", "foo" < 3.

This part could be fixed by specifying SORT_STRING, or after we drop PHP 5.3 support SORT_NATURAL.

To be honest, I think this should not be implemented. Still, the request is not unreasonable, so I won't oppose if someone does it.
I recommend that users who want reliable custom ordering just place a single <indicator/> tag on their pages, with whatever content they want inside, in whatever order they want it.

Can you point to the documentation for this tag, may be all that is needed to solve the issue.

I recommend that users who want reliable custom ordering just place a single <indicator/> tag on their pages, with whatever content they want inside, in whatever order they want it.

That isn't much of a solution, since most user page icons are implemented with templates[1] that do not allow setting the indicator name (nor should that be necessary). The tags should simply appear in the order specified, and only auto-sort where consistency is required.

[1] https://en.wikipedia.org/wiki/Template:Top_icon_templates

This part could be fixed by specifying SORT_STRING, or after we drop PHP 5.3 support SORT_NATURAL.

Again, why should users even be concerned with how sorting works if there is a much simpler solution? Isn't the whole indicator system designed to get away from these hacks?

Can you point to the documentation for this tag, may be all that is needed to solve the issue.

I'm afraid that https://www.mediawiki.org/wiki/Help:Page_status_indicators is all documentation there is.

matmarex renamed this task from Page staus indicator should not be automatically sorted outside main namespace to Page status indicator should not be automatically sorted outside main namespace.Mar 29 2015, 11:26 AM
matmarex removed a subscriber: matmarex.

That isn't much of a solution, since most user page icons are implemented with templates[1] that do not allow setting the indicator name (nor should that be necessary).

Why can't the templates take an optional "name" parameter, besides that you
personally think it shouldn't be necessary?

The tags should simply appear in the order specified, and only auto-sort where consistency is required.

OTOH, then you have differing behavior in sandboxes than on articles, which
can be annoying when testing stuff.

TheDJ added a comment.Mar 29 2015, 4:06 PM

OTOH, then you have differing behavior in sandboxes than on articles, which can be annoying when testing stuff.

Also you'll want a pretty much consistent position for something like protection icons, no matter what the namespace is.

Users should not have to hack around with the name parameter just to get them in the right order (with the unpredictive results mentioned above). How about only excluding user pages from auto-sorting.?

Is there a way to just sort them in the order they are placed on the page? Excluding certain namespaces seems silly given the versatility of MediaWiki software. I may have other namespaces on my wiki that utilize topicons in the same way we do on our userpages.

I still don't understand why it was chosen to be sorted alphabetically in the first place? How is this helpful? On enwiki, don't we always wanted our {{featured article}} icon rightmost?

Nemo_bis removed a subscriber: Nemo_bis.Apr 3 2015, 7:32 PM
Edokter claimed this task.EditedApr 6 2015, 8:56 AM

The more I think about it, the more I am puzzled. The argument for sorting is "consistency", but this has not been thought through. When two specific indicators are used on multiple pages, their order would be consistent, but that is also easily achieved within the templates utilizing the indicators.

However, if there are two different sets of indicators, sharing one of them, there is no telling at which place that shared icon will end up, thereby negating the entire purpose of sorting. I now believe sorting should be controlled by the project (by placement order) and not forced by the software, as it only triggers hacks to disable the forced behaviour.

I will be uploading a patch removing the ksort() line from OutputPage.php.

Change 202012 had a related patch set uploaded (by Gerrit Patch Uploader):
Disable automatic sorting of Page Status Indicators

https://gerrit.wikimedia.org/r/202012

Ricordisamoa added a subscriber: Ricordisamoa.

I don't understand the seemingly strong push for this request: what's so hard about making indicators have names which sort in the way you want, whatever it is?

To the contrary, it's very hard (read: impossible, AFAIK) for a template to know whether another template exists before or after it in the same page which adds the same (or another) status indicator. So if one used to have flexible mechanisms to add icons one would now need to verify them on all pages and/or centralise them in a single template and/or use some hack to sort stuff as expected.

Position in wikitext is not controllable, hence it should not be meaningful for page properties; seems a rather simple principle, am I making sense?

@Nemo_bis: This seems to be a very valid reason for me:

However, if there are two different sets of indicators, sharing one of them, there is no telling at which place that shared icon will end up, thereby negating the entire purpose of sorting. I now believe sorting should be controlled by the project (by placement order) and not forced by the software, as it only triggers hacks to disable the forced behaviour.

To control this you need to either need to make those templates to accept a parameter to specify on each page the order of such indicators, or use awkward names for each of the indicators (like numbers) that should be already compiled for all the indicators of the wiki to use the desired consistent order on all pages. That's IMHO harder than just place templates in the order you want the indicators to appear (in case, of course, that the order actually matters).

Edokter added a comment.EditedMay 15 2015, 3:50 PM

I don't understand the seemingly strong push for this request: what's so hard about making indicators have names which sort in the way you want, whatever it is?

Because indicators are incorporated in templates, which do not accept name parameters.

To the contrary, it's very hard (read: impossible, AFAIK) for a template to know whether another template exists before or after it in the same page which adds the same (or another) status indicator.

That makes it even harder to disable sorting; one template cannot know the name of another template. A single wrapper template solves this. Otherwise, we end up with hacks like this: //en.wikipedia.org/wiki/Module:Top_icon, which still requires all template to accept the name parameter. And I thought the entire idea behind this is to not have these hacks?

Other then that, "consistency" is a misnomer. The number of pages that have multiple icons are negligable. And where they do, the formentioned wrapper template can solve this, which is a whole lot easier to implement then any means to circumvent auto-sorting.

In short: editors want control, and right now, they do't have it. Give back control.

Control is still in the hands of editors, just moved in another place (the indicator definition). But then, as I said I don't understand this issue, so I'll remove myself.

Nemo_bis removed a subscriber: Nemo_bis.May 15 2015, 6:12 PM

Again, no editor is directly using <indicator>, but uses templates, which there are a few hundreds of, and I am not about to go through them all again to add a name parameter, which has other disadvantages, like breaking id naming.

Someone else want to step up and fix this? Would it help if I am upfront about this and intend to bitch and moan about it until this is resolved? I will counter any argument in favor of sorting and thus my list with counter-arguments will only grow.

demon added a subscriber: demon.May 23 2015, 1:55 PM

Why is this a MW 1.25 bug? Is this a regression or just a nice to have?

Because I'd like to have this cleared before it gets released.

I believe this needs more discussion, and maybe some sort of switch between the two behaviors.

Then discuss... I have put my arguments forward in that auto-sorting gives more trouble then advantages, and that sorting can easily be achieved localy instead.

I think that auto-sorting is a better behaviour than forcing users to manually sort for 99% of cases where we actively want the consistency of ordering. I also think that having different behaviour between namespaces is undesirable, being confusing, unexpected and undiscoverable. Setting the default sort-order through the naming is a neat way to give readers a familiar, sensible ordering which can be worked around by careful naming.

Being able to over-ride the automatic order on a per-page basis with an additional sort-key seems like a nice-to-have, but I certainly don't think we should disrupt pages by removing the automatic order (even only on non-NS0 pages) merely to solve an edge use case. Consequently, I'm removing this from the REL1_25 tag, which isn't appropriate at this late stage.

Edokter added a comment.EditedMay 23 2015, 5:54 PM

@Jdforrester-WMF, I don't think there has been any case studies done with regards to indicator use, and I think you have no idea how indicators are used in real wiki-life. I am talking from experience and as the one how implemented it on enwiki, I get all the complaints regarding sorting.

Let's examine real use...

Articles and other pages:
There are two major uses for indicators on articles: protection- and featured status icons. The numbers of articles where both are used is less then 1/100 of those where only one is used. So the 99% you cite is completely unfounded. Before indicators, we have never had an issue with ordering top icons; they were there or they weren't.

Now, as advertised by this feature, indicators should be implemented using templates (in other words, article or any other page should not use the indicator tag directly). The use of protection- and featured icons were already very consistent by use of the various protection- and featured content templates, which in itself guarantees consistent ordering. So there is no need for automatic ordering.

User pages:
This is where the majority of complaint come from... Users like to place their indicator icons in their preferred order. And they would like to do so without having to muck about with naming or sorting parameters. Most, if not all of our user top-icon template have no name parameter. They used to have a position parameters, but it is completely unpractical to integrate this into the indicator's name attribute... at least not wihtout an inordinate ammount of hacking on the project level (see the module I linked above).

That means users actually have no control over icon placement. This is directly contradicting documentation, which is actually contradicting itself; It advises to use templates, but in doing so, loses any method of placement control. In short, we are forced to regress to unsightly hacks to disable sorting!

In summary, you cite consistency as the only reason for automatic sorting, but have not demonstrated its actual use case. On the other hand, it takes away control from users who wish to control their own icon order. In fact, I regard the need for consistent ordering to be the edge case; I have now amply demonstrated that.

Back to you...

demon added a comment.May 24 2015, 8:27 AM

As a core developer: I don't really have an opinion on this one way or the other. Sort, no sort, randomize on every page load, doesn't matter to me one bit :p

As release manager for 1.25: Barring any last minute consensus on this today, this will not make REL1_25. It's a nice to have, sure, but it's not a regression in behavior and it's not something that should block the GA of the tarball.

How can it be a regression? It's a new feature with a new bug?

There was never a consensus to sort in the first place; the dev that put it in never considered the drawbacks (and now tries to ignore them). The sorting should be removed, or at least be disabled by default.

The discussion is stuck.
So, what about a $wgSortIndicators, or a hook to allow manipulating them?

To allow...?

It should never have been restricted to begin with. Add a sort=true parameter instead, so that those templates that need sorting, can. (I expect zero usage though.)

Adding a new variable to control this won't help if it won't be switched on WMF wikis...

Qgil removed a subscriber: Qgil.Jun 8 2015, 7:20 PM
Krinkle closed this task as Declined.Jun 8 2015, 7:26 PM
Krinkle added subscribers: matmarex, Krinkle.

I recommend that users who want reliable custom ordering just place a single <indicator/> tag on their pages, with whatever content they want inside, in whatever order they want it.

Agreed. I thought the same. Indicators are not meant to have relations inside or among them. If you want to use it as a way to place content there, use a single one.

Firstly, as a user, re-consider whether the order really matters to you. If it does, is that personal, or rational?

If it's rational, update the user-page specific indicator templates on your wiki to include a sort key. E.g. if you can agree with other users that {{User-FooB, {{User-FooA, and {{User-Baz should always sort on user pages in that order, then update the templates to have a key that reflects that desired order. Like so: <indicator name="userpage-10-foob">, <indicator name="userpage-20-fooa">, <indicator name="userpage-100-baz">. Or if you can't agree with other users what the order should be, expose it as a parameter to the user page templates so you can do it manually.

The discussion is stuck.
So, what about a $wgSortIndicators, or a hook to allow manipulating them?

This has nothing to do with site-wide configuration or extension hooks.

It should never have been restricted to begin with. Add a sort=true parameter instead, so that those templates that need sorting, can. (I expect zero usage though.)

Per your own words:

@Edokter wrote:

I understand the need for consistency in articles; that is probably the reason for automatically ordering them. However, this means having no control over them in user space, other then hacking around it by manipulating the name, which itself hits limitation in PHP sorting. Therefor I request that the auto-ordering only take place in main space, and be disabled outside main space.

What limitation in PHP sorting? This sounds interesting. But other then that, I think the name parameter gives you everything you need to sort them anyway you want. Outlined in my first comment above how this can be done. Either agree on a sort order with other users, or convince other users you need it exposed as a parameter so you can override it.

Anomie added a comment.Jun 8 2015, 7:30 PM

What limitation in PHP sorting? This sounds interesting.

which itself hits limitation in PHP sorting

This needs more explanation. What it's referring to is the fact that PHP's SORT_REGULAR gets confused when asked to sort things with both numeric and non-numeric keys due to violation of transitivity. For example: 3 < "10x", "10x" < "foo", "foo" < 3.
This part could be fixed by specifying SORT_STRING, or after we drop PHP 5.3 support SORT_NATURAL.

The discussion is stuck.
So, what about a $wgSortIndicators, or a hook to allow manipulating them?

This has nothing to do with site-wide configuration or extension hooks.

A configuration variable or a hook could have allowed single wikis to implement their own sorting algorithms (or no sorting at all).

Edokter reopened this task as Open.Jun 8 2015, 9:04 PM

Reopening... @Krinkle, you do not have the authority do decline this request, and I will not leave this alone until users have some control over ordering, wihtout having to revert to indicator name-hacking.

Agreed. I thought the same. Indicators are not meant to have relations inside or among them. If you want to use it as a way to place content there, use a single one.

That is not possible when different user icons are spread over different templates.

Firstly, as a user, re-consider whether the order really matters to you. If it does, is that personal, or rational?

Personal, of course... it is their userpage. What is the logic behind restricting such control?

If it's rational, update the user-page specific indicator templates on your wiki to include a sort key.

Let me stop you right there... Again, why are users expected to jump through a 1000 hoops in order to regain control that has been taken away.

Per your own words:

@Edokter wrote:

I understand the need for consistency in articles; that is probably the reason for automatically ordering them. However, this means having no control over them in user space, other then hacking around it by manipulating the name, which itself hits limitation in PHP sorting. Therefor I request that the auto-ordering only take place in main space, and be disabled outside main space.

I never changed my core request: to allow control in user space, but even that is being severly objected to... and I have absolutely no clue as to why.

Give... control... to... users!!! That is all I ask. Why is this so vehemently opposed???

matmarex added a comment.EditedJun 8 2015, 9:30 PM

Reopening... @Krinkle, you do not have the authority do decline this request

In your opinion, who has the authority to decline this request?

Let me rephrase that: Declining a task should only be done if the request is eihter unreasonable, hard to implement or going against core design priciples. Neither of those apply, so no single dev can decline.

And I still havent heard a single argument that refuted any of mine.

Aklapper added a subscriber: Qgil.Jun 9 2015, 10:19 AM

[offtopic]
https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle defines cases for "declined" (which can be discussed on its talk page).

demon removed a subscriber: demon.Aug 19 2015, 3:48 PM

For dewiki, this change would be somewhat problematic.

On dewiki, there is a large amount of templates which place stuff into the title area. These templates can be divided in two subcategories: Those which contain an icon only, and those which also contain text.

Formerly, all these templates used CSS and even JavaScript hacks for placement in the title area. Icon templates have already been converted to <indicator> tags. Even though the visual change was very, very small, there were some discussions about why the look changed.

With the proposed change, it would become very difficult to get rid of the remaining CSS hacks for text-containing templates. We have such templates in all namespaces (even project pages and categories), and the proposal would make it very difficult to get the look consistent.

I'd say that problems on user pages should have the lowest priority. If we really need namespace-dependent rules, let's rather make them so that user pages are different from everything else (and not article pages different from anything else). After all, users have (hopefully) always been warned that these icons used to rely on a fragile hack.

Agreed. I thought the same. Indicators are not meant to have relations inside or among them. If you want to use it as a way to place content there, use a single one.

That is not possible when different user icons are spread over different templates.

It is entirely possible. Create the indicator on the host page instead of within the template.

<indicator>
{{User rollback}}
{{User GoogleChrome}}
</indicator>
Krinkle added a comment.EditedApr 16 2016, 12:59 AM

[..] What is the logic behind restricting such control?
[..] Again, why are users expected to jump through a 1000 hoops in order to regain control that has been taken away.
[..] I never changed my core request: to allow control in user space, but even that is being severly objected to... and I have absolutely no clue as to why.

I am not now, and have not in the past, opposed that. I'm merely opposing the unnecessary convolution of this core feature for a use case that is already trivially satisfied in at least two other ways.

What control has been taken away? This was previously done on Wikipedia by having userbox templates pass an "offset" parameter as override to use as part of the name. That is still possible now. Right?

I don't see relevancy to PHP sorting here. However if SORT_NATURAL or SORT_STRING works better, I'd be fine totally fine with switching to that. It'd be more intuitive and easier to use in general as well.

Qgil removed a subscriber: Qgil.Apr 16 2016, 1:38 PM
This comment was removed by Edokter.
This comment was removed by Edokter.

OK, let me explain my exact goals again...

User (and other indicator) icons are implemented in enwiki using (300+) templates. Each template in turn calls on the {{Top icon}} meta template. Before the indicators were introduced, a whole slew of CSS/JS hackery was needed to properly place the icons, and even then, conflicts were unavoidable. The most important icons had static positions.

Now that indicators are introduces, that problem went away. Now we have a means where users can add as many icons as they want and not worry about conflicts, but they want to control over the ordering when using these templates. The easiest way to do so is by listing them in the right order. That is not possible because the autosort is being forced, and there is no way to disable it. It is suggested to put everything in one <indicator> block, but that is not possible in the current top icon framework on enwiki. And it is not possible wihtout using wrappers.

What I want is giving the user the ability to control the order...

  • WITHOUT having to use extra parameters
  • WITHOUT having to use extra wrappers

These mechanisms are considered too complex for non-techical editors, so we want to minimize these sort of requirements. Now, the "trivial" solutions @Krinkle has been posting, are not aware of the current implementation on enwiki (meta template), and the requirements for ease-of-use concerning user icons.

So... Am I required to "trivially" build a monster LUA module to attain what I want, OR am I forced to impose extra complexity on our users by way of wrapper templates and order parameters, OR are developers going to add a (really) trivially option to switch ordering on and off?

Perhaps I'm missing something, and there is a trivial solution, in which case I will shut up and close this ticket. BUT remember that me having to completely overhaul and edit 300+ template is NOT trivial.

matmarex removed a subscriber: matmarex.Apr 17 2016, 7:39 AM

Perhaps I'm missing something, and there is a trivial solution, in which case I will shut up and close this ticket.

I don't think that's even possible. I doubt there's a way to know from a template the position of all page status indicators transcluded on the page to alter their name (logic that would need to be put inside the template that transcludes the indicator and should run for each instance transcluded on the page.

Having a way to sort icons in a consistent manner without relying on the order they're inserted on the page (the current situation) is perfectly valid and desirable (as discussed in T94307#2209996), and this is probably not going to change, because other wikis would complain otherwise.

Still, having to specify a unique name for each icon (otherwise only the last duplicate is shown) can be a feature, but that's also very odd for people not paying attention to the names when creating such templates when they don't work.

I don't see why having to use extra parameters for the templates, when ordering needs to be specified on a page, can be so problematic for users, if they have to learn how to put the templates on the page anyway.

Changing this behavior on pages other than main namespace (or selected namespaces) would also be confusing and inconsistent. A probably sensible approach that won't require specifying the name on each indicator to tune it's sorting would be adding a new magic word that, when present on the page, would turn off the automatic sort of indicators by name. I think this can be a very simple solution to implement and give users control on each page.

@Edokter Hey! Over two years on from the opening of this ticket, {{top icon}} on enwiki has support for a sortkey parameter that allows custom sorting. You can check out my userpage for an example of this in action. This unfortunately does not meet your request for a solution without extra parameters.

A probably sensible approach that won't require specifying the name on each indicator to tune it's sorting would be adding a new magic word that, when present on the page, would turn off the automatic sort of indicators by name. I think this can be a very simple solution to implement and give users control on each page.

A magic word is possibly the best option here, but I also understand the argument that the extra code isn't worth the effort and complexity.

remember that me having to completely overhaul and edit 300+ template is NOT trivial.

If you ever have these sort of issues with enwiki templates (i.e. they are missing sortkey support, etc.) you are encouraged to request assistance from either me, anyone listed in en:Category:Wikipedians willing to assist with templates, or on m:Tech/Ambassadors/List. If it's a matter of fixing 300+ templates, I can get that sorted.

Please take a look at your current options, and let me know how you feel about them.

Give... control... to... users!!! That is all I ask. Why is this so vehemently opposed???

I would take a moment to note that the developers are responsible for managing hundreds upon hundreds of variables and codepaths, and it's simply not sustainable to accept every single little change that destandardises a behaviour. Funnelling users who want to be able to do something "their way" towards something that meets everyone's design goals is a crucial part of their job, and it's important to remember that they aren't just being difficult on purpose.