This issue just occurred again, resulting in disruption to COVID-19 pandemic, a very high-traffic page. @Aklapper, I don't know much about tagging phabricator tasks. Since you're the only other one here, would you be able to help get this in front of whoever might be able to fix it? Until it's fixed, this is going to keep happening at COVID-19 pages, many of which are using noinclude tags to make excerpting possible.

@Certes just identified a possible reason for this bug; see this discussion.

This problem is basically the same as T247001.

VE appears to simplify piped links in a way incompatible with transclusion, specifically to replace [[Foo bar|Foo<noinclude> bar</noinclude>]] by [[Foo bar]], This is helpful and harmless on the page being edited, but makes a transcluding page behave as if noinclude had not been used.

Change 595052 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/VisualEditor@master] Handle <noinclude> etc. as nodes rather than metaitems

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

This patch should fix this problem. The tags will be shown in the editor in a rudimentary way, so that you can edit the text inside/outside of them:

I don't think we'll be able to deploy the fix before Monday though, at the soonest.

By the way, since when are <noinclude> tags used in articles? It was of course always possible, but I thought that using them in article pages was discouraged (similar to e.g. parser functions like {{#if:…}}). We never prioritised implementing proper support for them for this reason. Have the practices changed recently?

@matmarex thanks! The noinclude tags are being used because of the spread of excerpts — they allow, for instance, leads of articles on aspects of the pandemic that start with "during the COVID-19 pandemic" to just say "during the pandemic" when transcluded to the COVID-19 pandemic article.

@Sdkb: great spot; we appreciate you filing this task.

@matmarex: some implementation comments below based on the conversation you and I have been having in chat and the conversation @Esanders, @iamjessklein and I had about this today...

Approach

Principles
For this initial approach [1], it is important people editing articles in the visual editor that contain <noinclude>, <onlyinclude> and <includeonly> , to know the content wrapped in/affected by these tags:

• Is different from other content on the page they are editing
• Is different from other content on the page they are editing in that this content is being used by (read: transcluded onto) other page(s).
• If changed, will impact other pages that depend on/mirror it.

Implementation
With the above in mind, we would like to make the following changes to the current implementation [2]:

• CHANGE the <> that is currently displayed to the tag itself
  • In this example, someone editing in VE would see: Hello <noinclude>there here</noinclude>! dfdfdf instead of Hello <>there here<>! dfdfdf
• ADD a "tooltip" that appears when the tag metaitem/node is clicked; this "tooltip" should appear and be presented in ways similar to what is currently done for comments <! ---
  • These tooltips should include the following:
    • Title: "⚠️ Warning"
    • Call to action: None
    • Contents:
      • <noinclude>…</noinclude>: "Be careful when editing the content in between these tags. Other pages depend on it. To learn how these tags work, visit: Help:Inclusion control.
      • <includeonly>…</includeonly>: "Be careful when editing the content in between these tags. Other pages depend on it. To learn how these tags work, visit: Help:Inclusion control."
      • <onlyinclude>…</onlyinclude>: "Be careful when editing the content outside these tags. Other pages depend on it. To learn how these tags work, visit: Help:Inclusion control." [3]

Open questions
The question below is now in the task description as well.

• How should <noinclude> and other similar tags be treated? As metaitems? As nodes?
  • If this question has already been answered, please comment as much. Documenting it here b/c I remember it coming up during standup last week without it sounding like y'all (engineering) having arrived at an answer.
• Are there help pages for "inclusion control" at each wiki? If not, what is common practice when wanting to direct people to more information about something that is not written in that person's local langauge?

1. We can revisit this implementation in: TASK
2. http://patchdemo.wmflabs.org/wikis/4f42faac93ed6fba3a86431ad568623d/w/index.php/B?veswitched=1
3. I suspect this language isn't going to leave people with more questions than answers; I think this is okay. In fact, it's intended...the main thing we want people to think/know when they see this is: "This seems like something I shouldn't change." and I think people being confused will lead them to have this thought, or one similar to it.

Open questions
The question below is now in the task description as well.

• How should <noinclude> and other similar tags be treated? As metaitems? As nodes?

They will be normal nodes now rather than metaitems – metaitems are for things that are not visible in the editing area, e.g. categories, and we've decided we want to make them visible.

• Are there help pages for "inclusion control" at each wiki? If not, what is common practice when wanting to direct people to more information about something that is not written in that person's local langauge?

We usually use translateable help pages on mediawiki.org, in this case I found documentation at: https://www.mediawiki.org/wiki/Transclusion#Partial_transclusion

I'm going to use that page instead of the one on English Wikipedia (it can be changed locally later if anyone wants to).

In T250937#6147229, @ppelberg wrote:

Implementation
With the above in mind, we would like to make the following changes to the current implementation [2]:

• CHANGE the <> that is currently displayed to the tag itself
  • In this example, someone editing in VE would see: Hello <noinclude>there here</noinclude>! dfdfdf instead of Hello <>there here<>! dfdfdf

The <> is a standard OOUI icon and I think we shouldn't modify it, so I added the text after it – we already have a similar interface for some other rare tags, e.g. <poem>:
https://en.wikipedia.org/wiki/Oscar_Wilde#Burial

• ADD a "tooltip" that appears when the tag metaitem/node is clicked; this "tooltip" should appear and be presented in ways similar to what is currently done for comments <! ---
  • These tooltips should include the following:
    • Title: "⚠️ Warning"
    • Call to action: None
    • Contents:
      • <noinclude>…</noinclude>: "Be careful when editing the content in between these tags. Other pages depend on it. To learn how these tags work, visit: Help:Inclusion control.
      • <includeonly>…</includeonly>: "Be careful when editing the content in between these tags. Other pages depend on it. To learn how these tags work, visit: Help:Inclusion control."
      • <onlyinclude>…</onlyinclude>: "Be careful when editing the content outside these tags. Other pages depend on it. To learn how these tags work, visit: Help:Inclusion control." [3]

I don't like using "Warning" etc. as a label, it takes up space but doesn't really deliver any information.

I thought about it for a bit and came up with the following short descriptions to be used instead:

I wrote the descriptions about "excerpts" rather than "partial transclusions", as that seems to be the convention now (even if both refer to the same thing). I also wrote them about "markers" rather than "tags", since that seems more correct when referring to the visual interface rather than the code.

I updated the patch, and created a new demo: http://patchdemo.wmflabs.org/wikis/3ab0b41f9c3fea53c6aac3a980dd5558/w/index.php/B

Instead of <>noinclude with the icon, why not just <noinclude> in monospace?

Because we have used the <> icon followed by tag name for other tags, e.g. the aforementioned <poem>, which will display like this if it has no actual content:

Do you think <noinclude> and the others are sufficiently different from normal extension tags that we shouldn't use that convention? Or do you think all tags should be shown like you propose?

I think given that these are start & end markers, unlike extension blocks, <>noinclude and <>/noinclude are needlessly confusing.

Or do you think all tags should be shown like you propose?

I wouldn't say definitely not, but I don't think the inconsistency is bad enough that we need to address it now.

Change 595052 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Handle <noinclude> etc. as nodes rather than metaitems

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

In T250937#6165595, @matmarex wrote:

Do you think <noinclude> and the others are sufficiently different from normal extension tags that we shouldn't use that convention? Or do you think all tags should be shown like you propose?

+1 in thinking <noinclude> and the other tags that "invisibly" draw boundaries [in VE] around content warranting a different treatment than something like <poem> tags.

@matmarex: is what's live on patch demo [1] what's being shipped? If so, the tags are still showing as <>noinclude and <>/noinclude> for me...

As for the contents of the tooltip, I think they should be revised. I'll file a separate task for that.

In T250937#6193332, @ppelberg wrote:

@matmarex: is what's live on patch demo [1] what's being shipped? If so, the tags are still showing as <>noinclude and <>/noinclude> for me...

No, the final version is on the Beta Cluster now: https://en.wikipedia.beta.wmflabs.org/wiki/B?veaction=edit

Question about includeonly, see my test page https://de.wikipedia.beta.wmflabs.org/wiki/Test_noinclude?venotify=created&veaction=edit

noinclude is shown as start and end node, onlyinclude too.

But includeonly is shown as 1 node  <includeonly /> only. Feature or bug?

That may be a bug. <includeonly>...</includeonly> affects text between the opening and closing tags. <includeonly /> affects no text, and is not useful.

@Raymond @Certes It's intentional, there are two reasons for this:

• The contents between <includeonly> and </includeonly> are not visible in read mode, so I thought it would be confusing to make them visible on the editing surface
• We can't render the contents between <includeonly> and </includeonly> visually, because Parsoid doesn't parse them, so the only thing we have is the wikitext – I thought that displaying the wikitext on the visual editing surface would be even more confusing

The wikitext between <includeonly> and </includeonly> is currently shown in the context menu when you highlight the node.

It might not have been the best idea to use the text <includeonly /> as the representation of the node on the editing surface (since indeed it wouldn't make sense to write that in wikitext). Do you think it would be more intuitive to instead use <includeonly>…</includeonly>? (Or should we actually display the wikitext on the editing surface?)

In T250937#6203367, @matmarex wrote:

It might not have been the best idea to use the text <includeonly /> as the representation of the node on the editing surface (since indeed it wouldn't make sense to write that in wikitext). Do you think it would be more intuitive to instead use <includeonly>…</includeonly>? (Or should we actually display the wikitext on the editing surface?)

More intuituve would be at least <includeonly>…</includeonly> because <includeonly /> does not exist.

Change 604131 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/VisualEditor@master] ve.dm.MWIncludesNode: Change label for includeonly nodes per feedback

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

Change 604131 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] ve.dm.MWIncludesNode: Change label for includeonly nodes per feedback

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

In T250937#6193416, @matmarex wrote:

No, the final version is on the Beta Cluster now: https://en.wikipedia.beta.wmflabs.org/wiki/B?veaction=edit

Roger that.

In T250937#6193332, @ppelberg wrote:

As for the contents of the tooltip, I think they should be revised. I'll file a separate task for that.

T255289