This is not minor, unless enwiki has agreed to abandon the long-established rules set out in http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Layout#Order_of_sections . I have just added a category to [[Permyak Salty Ears]] (it's a sculpture I was stub-sorting), and it has been put below the stub tag and interwiki link, and not adjacent to two existing categories.

There are also rules for the top of the article: navigational hatnotes go before anything else. Not in VE. WP:AWB sorts these out misplaced elements as part of "General fixes"; Twinkle can put a newly-added maintenance tag within the {{tl|multiple issues}} tag. It is very disappointing that VE seems incapable of offering the same level of helpfulness as these existing systems have offered for years.

I've re-titled this bug to "Provide a way for Parsoid to know that some types of some content on some wikis go after the meta-data, not in the body of the document", which I think captures the 'ask' here most generally. I believe that currently, Parsoid puts all content first, followed by meta-data in the order "Magic words (e.g. DEFAULTSORT) > Categories > Language links", which is MediaWiki standard style.

The problem here is not specifically "stub templates", but the general idea that some items of content - in this case, on one wiki, a sub-type of template that is trivially-identifiable to humans but not necessarily so for software - should have its own special ordering when the page is re-serialised. The explanation for why this (relatively new?) policy change for enwiki seems to be absent, unlike for the other elements; it adds complexity without justifying why, as far as I can see.

I think it is unlikely that we will change things so that Parsoid has an understanding of what kinds of content it is dealing with, much less a concept of per-wiki settings for where the content should be positioned. Just because the English Wikipedia likes things one way doesn't mean we should impose those standards on everyone else - for example, another wiki might like their categories at the top, or their semi-structured data template (like PERSONDATA) at the very bottom, or… any one of countless other possible orderings that don't effect readers. Remember that VisualEditor is currently available on 300 wikis, and is being developed for all ~900 Wikimedia wikis, the ~300,000 Wikia wikis, and numerous other wikis as well.

This is not saying that this request is impossible, that the barriers are insurmountable, that it will never be done, or that our mind is set for ever on this matter. However, coming up with a system for specifying this on a per-wiki basis, and justifying us spending (significant) developer time adding complexity and confusion to the code and the user interfaces is going to be challenging. This is time that would otherwise be spent on fixing bugs, on editing tables, on a better reference dialog, on supporting language variants as used in (e.g.) Chinese. I don't think that we can prioritise this above these other issues; sorry.

In the medium term I'd like to move metadata like categories out of the page and into a header section (see bug 49143).

In the meantime, we serialize metadata wherever the VE places it in the DOM.

Moving back to VE as this is handled in VE until we move metadata out of the body.

(In reply to comment #2)

The problem here is not specifically "stub templates", but the general idea
that some items of content - in this case, on one wiki, a sub-type of
template that is trivially-identifiable to humans but not necessarily so for
software - should have its own special ordering when the page is
re-serialised. The explanation for why this (relatively new?) policy change
for enwiki seems to be absent [...]

This practice has been documented at [[WP:LAYOUT]] for at least a few years. It's been standard practice since before then. There's a note in the current version of that document that explains that it's due to a battle with bots (notable AutoWikiBrowser, as I recall). Because most people add stub categories with AWB or similar scripts, the conventions those tools use become (or rather, became) wiki conventions.

I agree with the general point that we should move this type of information (whether a page is a stub and if so, what kind of stub) to a metadata area.

The reasons behind [[WP:ORDER]] are:

1. We want "stub categories" to appear Last in the list of categories.
2. We want 2 blank lines preceding stub-templates, for whitespace. (Other ways of achieving this are more complex, or don't work for articles with multiple stub-templates.)

See example of both factors, at http://en.wikipedia.org/w/index.php?title=Milo_McCarger&oldid=532917627

(To quote the [[WP:ORDER]] reference here, for ease of access: "While categories are entered on the editing page ahead of stub templates, they appear on the visual page in a separate box after the stub templates. One of the reasons this happens is that every stub template generates a stub category, and those stub categories appear after the "main" categories. Another is that certain bots and scripts are set up to expect the cats, stubs and ILLs to appear in that order, and will reposition them if they don't. Therefore, any manual attempt to change the order is doomed unless the bots and scripts are also altered.")

• Bug 51714 has been marked as a duplicate of this bug. ***

There's also an inconsistency in how VE inserts {{DEFAULTSORT}} and categories.

If you edit the page's properties to add a {{DEFAULTSORT}}, apply, then edit the properties again to add a category, then the {{DEFAULTSORT}} is added before the category, as is usually expected based on community guidelines.

However, if you do the sequence in the other order (add a category first, apply, then edit the properties again to add a {{DEFAULTSORT}}), then the {{DEFAULTSORT}} is added after the categories.

Since the user doesn' t have a way to specify or change that order, VE should be consistent in how it outputs them in the wikitext.