Please put templates on separate lines (when it won't break things) and don't (when it will)
Closed, ResolvedPublic0 Story Points

Description

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 automobile

The current behavior:

{{distinguish|Studebaker Land Cruiser}}{{Refimprove|date=May 2016}}{{Infobox automobile
Restricted Application added a project: VisualEditor. · View Herald TranscriptMay 18 2016, 6:12 PM
Restricted Application added subscribers: Zppix, Aklapper. · View Herald Transcript
Elitre added a subscriber: Elitre.May 19 2016, 7:59 AM
Jdforrester-WMF closed this task as Invalid.May 19 2016, 10:24 AM
Jdforrester-WMF added a subscriber: Jdforrester-WMF.

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.

Whatamidoing-WMF reopened this task as Open.Jun 1 2016, 6:17 AM

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.

ssastry added a subscriber: ssastry.Jun 8 2016, 9:01 PM

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?

Whatamidoing-WMF added a comment.EditedJun 9 2016, 5:52 AM

@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.

ssastry added a comment.EditedJun 9 2016, 5:55 AM

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?

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?

Whatamidoing-WMF added a comment.EditedJun 9 2016, 10:36 PM

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.

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.

Jdforrester-WMF renamed this task from Please put templates on separate lines to Please put templates on separate lines (when it won't break things) and don't (when it will).
Jdforrester-WMF triaged this task as Normal priority.
Jdforrester-WMF added a project: TemplateData.
Jdforrester-WMF moved this task from To Triage to TR1: Releases on the VisualEditor board.
cscott added a subscriber: cscott.Jul 21 2016, 8:18 PM

@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.

  • Some templates are supposed to be used inline. You should put them inline when you are adding a new one, but it's ok to have it on its own line in existing wikitext. This is what avoid should do.
  • Some templates should be on a separate line. The most prominent examples are infoboxes. But in almost all cases it's also ok to use these templates inline. This is what prefer should do.
  • I'm not sure what always does. Does it put templates on a separate line, even if you did not touched that wikitext? Even if this may be helpful in some rare cases, I do not think it's a good idea. Cleanup jobs like this should be done by bots, AWB or similar tools.
  • Same with never.
cscott added a comment.Aug 6 2016, 4:23 PM

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

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

Jdforrester-WMF set the point value for this task to 0.Aug 12 2016, 8:22 PM

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.

cscott added a comment.EditedAug 16 2016, 7:45 PM

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):

  1. Compare the two different selector widgets for Block/Inline and for Prefer/Avoid to the one combined selector proposed above. Two widgets gives a bit more power before you have to fall down into a custom string.
  1. I'm allowing input of the format string with literal "\n" in place of newline characters, so as not to require a multiline widget (and potentially-invisible characters at the end of the format string). It might be nicer to style the newline as ↵ in the text box, but then it becomes perhaps an issue to discover how to enter it? I'm hooking the enter event to insert the "\n" sequence, so maybe discoverability won't be so bad after all.

EDIT: note that "block" implying "prefer" would be a backwards-incompatible change, which might lead to dirty diffs.

Update from IRC chat (sorry!):

  • Let's avoid having block/inline imply anything w.r.t. external whitespace, as we don't want dirty diffs.
  • Having a single selector widget for block/inline and making people use the syntax for anything more complex seems easiest.
  • Using "↵" in lieu of "\n" would be great.

Change 306975 had a related patch set uploaded (by Cscott):
Extend 'format' spec to include custom format strings.

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

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

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

Change 295741 had a related patch set uploaded (by Cscott):
WIP: Use improved format specifier for TemplateData.

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

Pols12 added a subscriber: Pols12.Sep 8 2016, 3:12 PM

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.

Is this bug fixed?

No. See the child task for progress.

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.

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

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.

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

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.

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)

Deskana closed this task as Resolved.Oct 11 2017, 8:24 PM
Deskana claimed this task.
Deskana added a subscriber: Deskana.
Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptOct 11 2017, 8:24 PM
Restricted Application reassigned this task from Deskana to R3609901. · View Herald TranscriptFri, Nov 17, 3:45 AM
Deskana claimed this task.Fri, Nov 17, 11:22 AM
Deskana added a subscriber: R3609901.