You can ask flow developers how did they solve all these. Because their notifications have a lot of links, including parsable of the first line of new post. And so yes, it's possible.

Even if Flow notifications do have more elements that link to more pages, each element has only one link.

Flow notifications do not parse links in titles or body text excerpts. Test 1, Test 2.

If I am not interpreting correctly your suggestion, please provide a test.

Hi. I am sorry. I checked now in my account, and you are right. There are no created links in the text. I was confused with another text design, and remembered a phab task that I filed once with very wierd bug that was fixed than. So I can just ask to do this, but I understand the answer is 97% no. But, if it will be no, you can do something else, the second best choice: parse the text, and publish the result in the notification when removing the text design. This is done in some kinds of notifications, so you can do it easily. I mean, if the text of user notice is
Hi [[User:Abc|man]], how are you?
the result isn't
Hi [[User:Abc|man]], how are you?
literally, but
Hi man, how are you?
So, the text is readable again. The reason for this is that the links will remain clickable in email, and both, notification and email, will look fine. And if it exists, at least in user notice, but I think also in some other places, you can take the ready code from there. Thank you and sorry again for the confusion.

The background of the decision not to allow wikitext in descriptions of newsletters and issues:

In T116353#2167708, @Qgil wrote:

In T110642#2006505, @MZMcBride wrote:

• Description field doesn't parse wikitext (http://newsletter-test.wmflabs.org/wiki/Special:Newsletters)

I think parsing wikitext would complicate things a lot (i.e. not allowing people to insert images, templates, etc. It is meant to be a plain description, and I think plain text is just fine.

Nobody contested this idea at the time. During the security review, titles and descriptions in plaintext only made everybody happier, because opening to wikitext poses more vulnerabilities and room for abuse.

I think we are talking about different things in these two tasks.

This is exactly the reason I spoke about the ready code. Flow developers already solved all these issues.

I still don't see a strong use case for allowing/parsing wikitext in descriptions. Newsletters and issues point to wiki pages where authors can squeeze the power of wikitext at will.

The main use case of newsletter descriptions are the lists of newsletters, where plain text for everybody is preferred for usability reaons.

The main use case of issue descriptions are notifications, which are also more consistent when only plaintext is used.

So remove the design, not apply it. It's simplier, doesn't have the problems you mentioned, but still allows to use links in email version.

Personally I actually think wikitext is more inline with user expectations.

We allow wikitext almost everywhere, certainly on "page" like things.

I feel the same as @Bawolff

I'm not sure how wikitext "poses more vulnerabilities and room for abuse" if you don't allow external linking, but I'm not a developer so I am not aware of all issues. That said, it'd be curious that a wiki extension is vulnerable to wiki syntax, right? :)

In T175280#3595014, @MarcoAurelio wrote:

I feel the same as @Bawolff

I'm not sure how wikitext "poses more vulnerabilities and room for abuse" if you don't allow external linking, but I'm not a developer so I am not aware of all issues. That said, it'd be curious that a wiki extension is vulnerable to wiki syntax, right? :)

Speaking as security person, adding wikitext support to the page does not represent an increase in risk in terms of XSS, or other issues of that nature.

If you mean, it allows users to put shock images or other "annoying" content, I suppose that's true, but its true on all the other pages too.

The thing is, the list of newsletters and web/email notifications are not "page" like things.

How do you expect wikitext to be rendered in the descriptions at https://www.mediawiki.org/wiki/Special:Newsletters? Or in web / email notifications?

The use case of adding additional links has been mentioned. As said, Newsletters and issues come always with their own links, and adding more links to the mix might defeat the point (users clicking the secondary links and therefore not landing in the newsletter main page and the issue main page.

Beyond links, what happens when the wikitext in a description contains templates, tables, images...?

How do you expect wikitext to be rendered in the descriptions at https://www.mediawiki.org/wiki/Special:Newsletters? In web or email notifications?

We send rich text emails for echo notifications, why not just render as wikitext?

If not, one can always just convert to html, delete all the tags, and the result is plain-text content.

I'm sure every other type of notification has this problem, we could do whatever they do.

How do edit summaries parse wikitext, and could we use the same approach? Edit summaries accept wikitext links [[Some page]] that will be parsed as such in the page history and Recent Changes. However, http links, images, templates etc will not be parsed.

Slightly related: T175432#3595683