This is a Parsoid issue - but I suspect they won't want to change this behaviour - or make it site configurable.

And could you provide me reason why? I think that better will be to don't allow VE change order of params when a template was already inserted, but tagging is possible and TemplateData'll be used only for inserting a new template.

@Esanders In my opinion, VE should sort template parameters according to paramOrder option in template's TemplateData and not sort them if there isn't this option set. Or there could be at least some switcher to turn off this sorting (like there is format option, there could be sort option).

One bad aspect of this behavior is that user doesn't see his/her change, because VE adds its own changes (sometimes really large) to diff.

Recording from IRC conversation.

<subbu> Dvorapa, hi .. quick qn ... are you saying Parsoid is reordering parameters even if it does not have 'paramOrder' field set in templatedata?
<subbu> if so, that sounds like a bug, but, my gut sense is that paramOrder is present because otherwise parsoid wouldn't know how to order the params.
<Dvorapa> yes
<subbu> ok, let me look at some sample diffs and look at the affected templates and templatedata for them.
<subbu> 1. for https://cs.wikipedia.org/w/index.php?title=V%C3%ADt%C4%9Bzslav_Jand%C3%A1k&type=revision&diff=13849145&oldid=13642729 .. https://cs.wikipedia.org/w/api.php?action=templatedata&titles=Template:Infobox%20Politik&format=json specifies the paramOrder.
<subbu> https://cs.wikipedia.org/w/index.php?title=Michael_Koc%C3%A1b&diff=prev&oldid=13849130 is Infobox Politik as well
<subbu> and so is https://cs.wikipedia.org/w/index.php?title=Helena_T%C5%99e%C5%A1t%C3%ADkov%C3%A1&diff=prev&oldid=13849139 ..
<subbu> Dvorapa, ^ so .. all of them use Infobox Politik and templatedata for it does provide a paramOrder field.
<Dvorapa> I added paramOrder after those incorrect behavior happenned (see template history x diffs time)
<subbu> oh, hmm ..
<Dvorapa> We thought Parsoid uses order of parameters in *params* and we also thought it is "by design" (not a bug)
<subbu> no, it should use the order specified by paramOrder only .. otherwise, leave param order unchanged.

This is the former revision of the Infobox Politik template and its TemplateData, which caused the incorrect behavior described above. Maybe there could be some issue with the TemplateData block? (@ssastry).

Update: current revision also makes this buggy behavior

https://github.com/wikimedia/parsoid/blob/8fd4c9bbee79ab0fe30f86d6ba44dc73b11b62a1/lib/html2wt/WikitextSerializer.js#L460-L477 is the code that determines order in which args are serialized. So, if paramOrder is not present, data-parsoid & data-mw info is used .. so, I suspect something else unrelated to templatedata affected these edits.

params is currently a keyed object and therefore has no order however I have suggested getting rid of this: T127958

I am still investigating the bug .. it doesn't seem tied to paramOrder at this time.

@Vojtech.dostal if anybody wants to be assigned to this issue, (s)he make it her/himself. Currently ssastry is investigating this issue and there is also a conversation between me and him on IRC (#mediawiki-parsoid, most important points were cited above).

It seems that API contains paramOrder, but template doesn't. Therefore paramOrder is automatically added by TemplateData (?), which causes this bug. Compare API output with TemplateData of an example template.

This is a bug in TemplateData. See the else in https://github.com/wikimedia/mediawiki-extensions-TemplateData/blob/master/TemplateDataBlob.php#L397-L426

Can we make any progress on this? There are more and more erroneous edits on cswiki and users complain :/

LGTM. Let's remove the auto-creation of this property from the parser normalisation. I added it originally because property order enumeration happens to be stable in PHP (and originally the wikitext was only manually modified). However made it impossible to leave the order unspecified.

The TemplateData spec does not describe paramOrder as required, and for back-compat both our authored content and consumers may not assume the presence of this property.

Let's verify (or fix) VisualEditor and Parsoid to indeed not assume the existence of paramOrder, then we can go ahead and remove the auto-creation of it in the parser.

In T138200#2414976, @Krinkle wrote:

Let's verify (or fix) VisualEditor and Parsoid to indeed not assume the existence of paramOrder and function properly when absent.

Parsoid doesn't assume the existence of paramOrder. See tests that spec this and the mock API that supports those tests.

Any progress on it? This is a high priority problem but last comment was made before almost half a year!

Any progress?

Any progress? High priority and last comment was almost one year ago!

Adding current PM.

Change 389852 had a related patch set uploaded (by Subramanya Sastry; owner: Subramanya Sastry):
[mediawiki/services/parsoid@master] Preserve original transclusion's parameter order

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

In T138200#3748126, @gerritbot wrote:

Change 389852 had a related patch set uploaded (by Subramanya Sastry; owner: Subramanya Sastry):
[mediawiki/services/parsoid@master] Preserve original transclusion's parameter order

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

This patch was merged. The next step is to update TemplateData PHP code to match the specification, that is, to leave paramOrder unspecified. Currently, the TemplateData PHP code fills in paramOrder automatically during its normalisation/upgrade phase.

Change 481811 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/extensions/TemplateData@master] Remove default value for 'paramOrder'

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

Change 481811 merged by jenkins-bot:
[mediawiki/extensions/TemplateData@master] Remove default value for 'paramOrder'

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