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.

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.

In T94307#1159632, @matmarex wrote:

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.

In T94307#1159632, @matmarex wrote:

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

In T94307#1159640, @Anomie wrote:

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?

In T94307#1159662, @Xaosflux wrote:

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.

In T94307#1159671, @Edokter wrote:

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.

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?

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

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:

In T94307#1181640, @Edokter wrote:

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).

In T94307#1287739, @Nemo_bis wrote:

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.

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.

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.

@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...

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...

In T94307#1346987, @Krinkle wrote:

What limitation in PHP sorting? This sounds interesting.

In T94307#1159640, @Anomie wrote:

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.

In T94307#1346987, @Krinkle wrote:

In T94307#1345403, @Ricordisamoa wrote:

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).

In T94307#1347290, @Edokter wrote:

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.

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

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.

In T94307#1347290, @Edokter wrote:

In T94307#1346987, @Krinkle wrote:

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>

In T94307#1347290, @Edokter wrote:

[..] 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.

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.

In T94307#2212673, @Edokter wrote:

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.

In T94307#2212729, @Ciencia_Al_Poder wrote:

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.

In T94307#2212673, @Edokter wrote:

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.

In T94307#1347290, @Edokter wrote:

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.

Change #202012 abandoned by Thiemo Kreuz (WMDE):

[mediawiki/core@master] Disable automatic sorting of Page Status Indicators

Reason:

A 9 year old patch doesn't help much. It can still be found via T94307.

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