See https://en.wikipedia.org/w/index.php?title=Toyota_Land_Cruiser&oldid=prev&diff=720847140
The desired behavior:
{{distinguish|Studebaker Land Cruiser}}
{{Refimprove|date=May 2016}}
{{Infobox automobileThe current behavior:
{{distinguish|Studebaker Land Cruiser}}{{Refimprove|date=May 2016}}{{Infobox automobile| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • Deskana | T135667 Please put templates on separate lines (when it won't break things) and don't (when it will) | |||
| Resolved | cscott | T138492 Add support for actual format strings to TemplateData's "format" parameter |
This was fixed months ago. The first two templates lack the TemplateData asking for them to be put on separate lines.
Please could you link to the relevant task where this was fixed and/or the relevant TemplateData documentation to help people if this happens again.
Hey my friend.
I believe the documentation is at en.wiki, and the relevant task was https://phabricator.wikimedia.org/T111674. HTH.
James, you've answered the wrong question. I don't want the three parameters on separate lines. I want three templates on separate lines.
The "block" and "inline" TemplateData options do not affect whether {{Distinguish}} and {{Refimprove}} go on separate lines. I'm totally happy with inline parameters. I just want a line break between the separate templates.
Or, give me this:
{{stub}}
{{stub}}
{{stub}}and not this:
{{stub}}{{stub}}{{stub}}Here's another example of multiple templates ending up on one line, when there should be a line break between them: https://en.wikipedia.org/w/index.php?diff=724044096&oldid=723346360
This is the wikitext that we got:
{{Bury F.C. squad}}{{England-footy-forward-stub}}This is the wikitext that we want:
{{Bury F.C. squad}}
{{England-footy-forward-stub}}Two templates, two lines of wikitext. Not an unlimited number templates smashed together on a single line.
Wrong, the Wikitext that we want is
{{Bury F.C. squad}}
{{DEFAULTSORT:Styles, Callum}}
[[Category:2000 births]]
[[Category:Living people]]
[[Category:English footballers]]
[[Category:Bury F.C. players]]
[[Category:Association football forwards]]
[[Category:The Football League players]]
{{England-footy-forward-stub}}stubs go last, after the cats; and there should be blank lines between navbox and defaultsort, also between cats and stub.
Please note that Parsoid doesn't have access to this info at all (transclusions on separate lines / stubs go last, etc.) and so cannot implement these requirements.
If there is a correlation between templates that are marked block/inline and translcusions of those templates on separate lines, Parsoid can use that info. If not, new templatedata files would have to be introduced, if that is deemed useful.
There is no good correlation. We want {{Refimprove|date=May 2016}} to be "inline" formatting for the template itself, but we don't want any other template to be on the same line of wikitext.
Perhaps a different question is: How many templates should be on the same line as another? Could Parsoid differentiate between The object is {{convert|3|m|yd}} long (which should be all one line) and {{a-stub}}{{b-stub}} (which should almost(?) always be separate lines), without adding another setting to TemplateData?
@Redrose64, I believe that when you wrote "stubs go last, after the cats; and there should be blank lines between navbox and defaultsort, also between cats and stub." that you actually meant, "At the one particular wiki that I happen to frequent, we do it this way". Different projects have different rules about the order for these things.
And, importantly, that's a different task, T52882: VisualEditor: Place page meta-data in expected order. This task happens to be relelvant to the subcomponent of multiple stub templates, but this task began with {{multiple issues}}, which should not be anywhere near the categories or stub tags. On your favorite wiki, anyway.
How will Parsoid know that wiki-specific semantic info except by consulting a list of template names that have this behavior? For reasons of maintainability and accuracy, this would have to be editor-maintained (rather than maintained by someone at WMF since we won't be able to keep up with edits on all the wikis). So why not just do it with TemplateData, the current established mechanism for maintaining semantic info (not otherwise available in wikitext) about templates?
So why not just do it with TemplateData
Because if Parsoid can figure out that some templates are in the middle of running text (and keep those on one line), and other templates are adjacent to other templates (and put those on separate lines), then we might be able to solve most of the problems approximately "now", rather than sometime in the distant future, after someone manually updates the TemplateData for a million templates across hundreds of wikis.
TemplateData is a good solution, but it is not a prompt solution.
Fair enough regarding using heuristics to handle some of these scenarios. I'll discuss with teammates and see what we can do.
@thiemowmde provided the suggestion for the T138492: Add support for actual format strings to TemplateData's "format" parameter improvement, so I'm mentioning him here in case he has more good ideas.
I'll start off with a strawman: let's add a new "ownline" parameter, with the possible values, "always", "never", "prefer" and "avoid". The latter two will put the template on its own line/inline only if doing so doesn't incur a dirty diff.
(Avoiding the name "inline" because we already have "format: inline" which would create confusion.)
@Whatamidoing-WMF @thiemowmde could you comment on the strawman proposal above, and see if it would be sufficient to solve the problem? I don't want to implement something that no one has +1'ed.
(I think @Jdforrester-WMF suggested that the "prefer" and "avoid" values in my suggestion above we're needed. In their absence, newly-added templates without any "ownline" property in the templatedata would behave the same as they do now, which I believe means that newly-added templates get added without any intervening linebreaks, as https://phabricator.wikimedia.org/T135667#2365143 shows. That is, the default behavior is what I called "avoid" in my strawman. Changing that default behavior to "prefer" is a bit problematic, because in general the whitespace between templates *is* significant. I believe that VE currently allows you to *add* whitespace between templates (just type a space!), but if the default serialization had whitespace automatically inserted between templates there would be no way to *remove* that whitespace using VE on a case-by-case basis.)
From what I know the ownline: "always|never|prefer|avoid" proposal above is sufficient. If you want to start with a smaller proposal, start with prefer|avoid only (with avoid being the default) and implement always|never later, when needed.
It depends on the template if a newline before and after does make a difference.
My thought was that the always/never options would prevent users using visual editor from manually removing/adding whitespace around the template (likely by accident). Perhaps @Jdforrester-WMF could confirm/refute this. My understanding is that you could still press enter (or "shift-enter"? or something like that) after a template and/or press backspace after a template to manipulate the intervening space without marking the template itself as "edited". The always/never options would prevent such modifications from breaking the page by enforcing the presence/absence of the newline even if the template itself was not edited (but instead the intervening whitespace was edited).
James, does this make sense given your understanding of how whitespace between templates appears in Visual Editor? (I'll have to confirm myself that Parsoid's selser algorithm is capable of marking the *whitespace* as edited while leaving the *templates* as unedited. But I think that's our own selser diff algorithm works. Maybe @ssastry can help me check that.)
But perhaps this is how prefer/avoid should work as well, and trying to distinguish between "new content" and "edited content" is getting a little too baroque. The users perhaps won't understand the difference.
Change 303432 had a related patch set uploaded (by Cscott):
Add new 'ownLine' property to control newlines around templates
Following up from a discussion @Jdforrester-WMF started in the gerrit patch comments: rather than ownLine = prefer or avoid, what if we wrote a format string like:
"\n{|\n_ = _}\n"where the newlines before/after the braces indicate whether a newline should be forced before/after the template. The contents inside the braces would be identical to the current format string (in T138492).
I'm not sure I'm actually advocating this syntax: it seems to me that the formatting of *parameters* and the format of the *template itself* might well be different -- also, the UI for "avoid/prefer" and "block/inline" is substantially simpler to understand that this full format string syntax, although I suppose we could kludge around it on the UI side and make the UI show the block/inline and avoid/prefer options while still using this full representation in the TemplateData JSON blob. Anyway -- let's hear some other opinions, I'm willing to be swayed either way here.
Copying @Jdforrester-WMF's comment from gerrit:
Yeah, that's what I was envisioning. I don't think anyone really thinks that the formatting of the wikitext that happens to be inside vs. outside the brackets of the transclusion makes much of a difference. Having two values to read is much more complex for authors and users alike, I feel.
My response:
Do you want to then make 'block' imply 'prefer' and 'inline' imply 'avoid'? Then in the UI you'd have one four-way selector for "format": Unspecified/Block/Inline/Custom, and if you selected "custom" you could write "\n{|_=_}\n" (which is inline+prefer) or "{|\n_=_}" (which is block+avoid) or any other thing you could dream up, like "\n{|_=_}" (inline, but make sure it's at the start of a line) for example.
UI issues I'd like some feedback on (probably you should check out the patch from gerrit and play with the UI a bit):
EDIT: note that "block" implying "prefer" would be a backwards-incompatible change, which might lead to dirty diffs.
Update from IRC chat (sorry!):
Change 306975 had a related patch set uploaded (by Cscott):
Extend 'format' spec to include custom format strings.
Change 303432 abandoned by Cscott:
Add new 'ownLine' property to control newlines around templates
Reason:
Abandoned in favor of https://gerrit.wikimedia.org/r/306975
Change 295741 had a related patch set uploaded (by Cscott):
WIP: Use improved format specifier for TemplateData.
Is this bug fixed? If so, how to edit TemplateData parmaters?
This bug can cause WYSIWYG parsing issues. Please try to edit this page with VE. A table will appear.
Another example:
{{userboxbottom}}'s sole contents is the table-closing wikitext, |}.
If it's not at the start of a new line, it doesn't work.
Change 306975 merged by jenkins-bot:
Extend 'format' spec to include custom format strings.
When a template on its own line is moved within a page, it should be placed on its own line at the new location. See https://en.wikipedia.org/w/index.php?title=United_States_presidential_eligibility_legislation&diff=801114094&oldid=797558629
In that example I dragged and dropped the Wikisource template to the top of the "Birth certificate" section until VE showed me a thin horizontal black line between the heading and the first line of body text, which I interpreted as meaning it would insert a new line with the template on. As this is what I wanted, dropped the template there.
As T173455 was merged here I am presuming that this should be treated as part of this bug too, but do let me know if I'm wrong.
Change 295741 merged by jenkins-bot:
[mediawiki/services/parsoid@master] Use improved format specifier for TemplateData.
You're right.
This is now going live with Parsoid in the next few hours. To make templates format onto their own line, you need to tweak their templatedata to specify it. I've written https://www.mediawiki.org/wiki/Help:TemplateData#Custom_formats – it's not great, but it's a start.
Mentioned in SAL (#wikimedia-operations) [2017-10-11T20:22:05Z] <subbu> updated Parsoid to ddf7b293 (T138492, T135667, T177612)