https://bugzilla.wikimedia.org/show_bug.cgi?id=50882
James Forrester <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|Unprioritized |Lowest CC| |[email protected] Component|MediaWiki integration |General Assignee|[email protected] |[email protected] Product|VisualEditor |Parsoid Summary|VisualEditor inserts |Provide a way for Parsoid |categories after stub tag |to know that some types of | |some content on some wikis | |go after the meta-data, not | |in the body of the document Severity|minor |enhancement --- Comment #2 from James Forrester <[email protected]> --- 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. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
