I think this is related to https://bugzilla.wikimedia.org/show_bug.cgi?id=47434

Detailed explanation follows:

• On parsoid.wmflabs.org, selective serialization (selser) is enabled. This immediately sets the regular (non-selser) serializer in editing mode. Since we've enabled editing support for templates, in non-selser mode, templates are rendered assuming parameters have been edited. This then normalizes white-space.

• The reason for why selser is disabled is in the bug above.

That said, here are a couple improvements we could do on the Parsoid end:

1. Disable editing support for templates at this point, since VE doesn't support that anyway.
2. Add another level of modification detection for template parameters in addition to whether we are in selser mode (but that merely adds additional state we have to maintain in the DOM)
3. Change the tpl-wikitext normalization to add a space before/after the "=". But, this just shifts dirty diffs to templates that dont use spaces before/after the "=".

For now, I would recommend 1. In addition, we should maybe apply 3. as well depending on the most common whitespace use around template parameters.

But, we should try to ensure the selective serialization is enabled as far as possible.

I fixed bug 47434 in VE master, but this fix is not yet deployed. I have verified that templates are not marked as differing with selser enabled, so things work fine once the VE code is updated.

Disabling editing support would be a temporary work-around. I think it is much preferable to deploy the fix to bug 47434 asap as this also avoids a host of other issues that are now reported (predictably) as bugs.

• This bug has been marked as a duplicate of bug 47434 ***

[Edit conflict] Agreeing with Gabriel - his patch for bug 47434 will be going out in the push on Thursday; assuming that this fixes that, yay.

(In reply to comment #1)

3. Change the tpl-wikitext normalization to add a space before/after the

"=".
But, this just shifts dirty diffs to templates that dont use spaces
before/after the "=".

It seems that large template transclusions like infoboxes tend to use spaces around the '=', while citations and other 'inline' transclusions omit them mostly. From a quick look I got the impression that overall both options are about equally good or bad.

In any case this is not directly relevant to the cause of this bug.