Signature parser function

To improve the reliability of signature parsing, we propose to introduce a new parser function {{#~}} with three arguments: the user id, an ISO 8601 timestamp,^[3] and an optional customized signature string. Currently when an edit is saved ~~~~ is expanded to:

[[User:Username|Username]] ([[User talk:Username|talk]]) 17:24, 16 August 2025 (UTC)

Instead we propose to expand it to:

{{#~:Username|2025-08-16T17:24}}

and this would render identically to before:

Username (talk) 17:24, 16 August 2025 (UTC)

Note that the timestamp is still rendered in localized format appropriate for the user and wiki, but is stored in the wikitext in a format which is easily machine-parsable.

If the user has customized their signature, then {{#~}} would render their current customized signature.^[4] Some users, however, use their signature to track the passing of time and don't want to update old signatures. For users who have "always show latest signature" deselected in their user preferences, we use the third argument to track their current signature. ~~~~ expands to:

{{#~:Username|2025-08-16T17:24|[[User:Username|Username]] ([[User talk:Username|talk]]}}

or whatever their custom signature currently is, and {{#~}} uses the third argument instead of their current customized signature. The custom signature doesn't override the localized time, and the user id is still easily parsed from wikitext as the first argument to {{#~}} irrespective of user customizations.

Block list items

Currently a comment which extends to multiple paragraphs in wikitext looks like this:

: This is the parent comment. {{#~:Alice|2025-08-01T01:23}}
:: This is a long reply.  It goes on and on.
:: In fact it is still going.
:: Finally, Bob concludes. {{#~:Bob|2025-08-02T12:34}}

This syntax is fragile, and doesn't allow for many wikitext constructs inside the comment, like tables. Each "paragraph" is a separate list item in the HTML. We have to make guesses about the exact start of Bob's comment: does it really include all three paragraphs/list items, or were the first one or two lines a comment by some other user, who just forgot to sign their comment? We propose that each comment should be a single list item, using the following syntax for block list items:

: This is the parent comment. {{#~:Alice|2025-08-01T01:23}}
:: <<< This is a long reply.  It goes on and on.

In fact it is still going.

Finally, Bob concludes. {{#~:Bob|2025-08-02T12:34}} >>>

This uses the <<< >>> delimiters proposed in long arguments to templates, and can be extended with hash fragments as discussed in that proposal to allow arbitrary wikitext to be included in each comment without breaking the list item syntax. Some users may wish to include optional line prefixes as well so that replies maintain a consistent indentation level.

List item (and heading) attributes

Taking inspiration from table attribute syntax, we can extend the above "long" list item syntax to accommodate optional attributes on the list item:

:: id=my-comment class=important <<< This is my comment! >>>

This allows associating specific permanent ids to a certain comment. These could be generated by reply tool to be unique but user-friendly. Further, we could extend the same to "long" headings:

== id=my-heading <<< This is my heading >>> ==

There is a modest amount of lookahead needed past the attribute list to determine if a "long" delimiter <<< is present.

Putting this all together, a discussion might look like this:

== Is this syntax okay? ==
I think it probably will be fine. {{#~:Alice|2019-08-17T10:45}}
: Will it, though? {{#~:Bob|2019-08-17T10:46}}

== id=rebuttal <<< Maybe we need a few extensions >>> ==
It’s possible we need to think this through more?
{{#~:Eve|2019-08-17T10:47}}
: id=denial <<< No, nothing’s wrong with it.

In fact, I love it! {{#~:Mallory|2019-08-17T10:48}} >>>
:: Agreed, everything is just fine. {{#~:Alice|2019-08-17T10:49|[[User:Alice|'''alice''']]}}

Next section: {{#media}}