`[[:{{ARTICLESPACE}}:{{PAGENAME}}]]` results in `[[::Foo]]`, which
is not a valid link.
Luckily, there's a magic word `{{SUBJECTPAGENAME}}`, which is the same
as `{{ARTICLESPACE}}:{{PAGENAME}}`, but without pesky leading colons.
Follow-up to bb0b65dc0c.
Change-Id: I992bdb8807c665561cad58997017aab5a6c1d8e8
This includes the dtrepliedto URL functionality from
I3f81e4d77faed367606e47678b8896051982359d.
Bug: T274831
Bug: T274832
Bug: T277329
Change-Id: I035d04f30c8312b0cb42902d3bf940df1482ffb3
Since it's no longer tied to the "Reply" button, we can move the code
from ReplyWidget to NewTopicController, where it belongs.
Bug: T272543
Change-Id: I8c90ffb772573d22d26c608d45877ee948fd232d
* Add the preference
* Only display it when the reply tool is enabled
* Use it when opening the reply tool
* Save it when the menu is toggled from the reply tool interface
Bug: T261539
Change-Id: Icb8fa6b3f1e9a3644669f21b08f34ea8c175f2f9
Load 'ext.visualEditor.mwsignature' (which implements VE's existing
handling for signatures), then subclass and override a bunch of things
in order to:
* Replace the context menu with a note that you don't need to type the
signature when commenting using the reply widget
* Override the sequence/command to insert signature so that it selects
it afterwards and thus displays the context menu
* Treat signatures as signature nodes when switching from wikitext,
instead of the normal pre-save transform turning them into regular
links and text
Bug: T255738
Change-Id: Icb542451c2307ab51e56bd627804096c7b5552c8
When the user clicks a "Reply" link on a page that is affected by the
'fostered' lint error (indicating fostered content in the HTML
representation), display an error and refuse to edit it, as Parsoid's
transformations will damage the page content.
The error message includes a link to documentation about lint errors,
and a link to the editor that will highlight the error location.
Depends-On: I723ec766d1244d117f8d624440026fe5af0d3403
Bug: T246481
Change-Id: Ic60cb58f98d10dc9b113469e5d3bbfb2d2b0564f
* When we discover the comment comes from a transcluded page, follow
the transclusion to find the source page. We follow transclusions
recursively, up to an arbitrary limit of 10.
* In the reply widget, display the title of the page where we will
save the reply, to avoid users confused why their edit won't show up
in the history. In the wikitext workflow this is done by redirecting
the user to the edited page at the end, but it seems less surprising
to stay on the current page.
* After saving the reply, we must purge the current page, otherwise
the new content will not be immediately visible on it.
Bug: T247535
Change-Id: I1c6631aa65a2fce6c1c2f0dd4a8c7aa6389caf94
When trying to reply to a comment that is inside a transclusion,
detect if it's transcluded from a subpage or simply wrapped in a
template, and show appropriate error messages.
References:
* VisualEditor ve.dm.Converter#getAboutGroup()
* VisualEditor ve.dm.ModelRegistry#matchElement()
* Parsoid Linter#findEnclosingTemplateName()
Bug: T245694
Change-Id: If3dd1ebbf1d02ee4379c200019bfc3a8ec02325b
Sets the placeholder text to "Reply to <user>".
Bug: T245227
Depends-On: I7f3a58b7093d00aace9f9c6a95a121ba4e901ad8
Change-Id: Ie51f1848c17bb892e7f64adf6f7f19fc38e56202
* Hide the top-level discussiontools tag
* Change the wording of others to be more compact and consistent with the tense requested
Bug: T242184
Change-Id: Id7ba7fd7d0a387a3ca198fd546edf65fb663a9f8
The most common case of edit conflicts on talk pages is several people
responding to the same comment at the same time.[citation needed]
We can easily resolve this case by fetching the latest revision of the
page and re-running our code to insert a reply on it.
When we can't insert a reply, that probably means the parent comment
was deleted or moved, so display an error message indicating that
instead of the generic one.
Bug: T240643
Change-Id: Ic686acc747580d46779960211a02e9830a6ae86f
This sets up the tags:
* discussiontools
* discussiontools-reply
* discussiontools-edit (not yet implemented)
* discussiontools-newsection (not yet implemented)
The tags are flagged as user-addable, because otherwise they can't be
passed through to the VE API (at least, not without editing it so that
it explicitly knows about them, which seems like a strange
interdependency). It's assumed that letting users who know about the
tags add them to random changes via action=editchangetags would be
(a) the pettiest and most inconsequential vandalism possible, and
(b) unlikely to happen.
This relies upon I2c1d0f8d69bc03e5c1877c790247e165f160e966 in
VisualEditor to not also tag the edits with `visualeditor`.
Bug: T242184
Change-Id: I4e5e26afdd52279df242e1912f073b415b812c3b
