I don't know how easy this would be to implement, but you could make a special case where, if the "user" that left a message at the talk page was the user controlled by the mass message extension, retrieve the name of the sender from the inline html comment and use that for the email instead. Alternatively, T71954 could be actioned.

@Etonkovidova will look into this

Confirmed - presently the notification truncates the user name:

Note: For Flow-based talk pages, the notification has a different text:

Triaging to "future" for the Growth team but it's possible we'll get to it as part of the effort to reduce Echo's backlog.

Here's the solutions I can think of to make the notification more understandable, in order of simplicity:

1. Rename "MediaWiki message delivery" to something shorter so it doesn't get truncated.
2. Revisit Echo's max length for usernames in notification text. It's possible that adding 5 or 10 characters would allow a lot more usernames to be fully displayed while keeping the average notification header's length reasonable. This would need a bit of testing with most notifications and several languages.
3. Have MassMessage hook into Echo and do some magic. Possibly changing the event type from 'edit-user-talk' to something MassMessage-specific that has its own PresentationModel to phrase the header is a way that emphasize the message title over the sender.

Pharos bugged me about this again in person today.

In T218724#5153007, @SBisson wrote:

3. Have MassMessage hook into Echo and do some magic. Possibly changing the event type from 'edit-user-talk' to something MassMessage-specific that has its own PresentationModel to phrase the header is a way that emphasize the message title over the sender.

This sounds like the best way to move forward I think.

Actually, I think something else might be going wrong here...the notification *should* include the section title. EchoEditUserTalkPresentationModel has a bunch of stuff for the section title, but I don't see it in the primary URL. My guess is that DiscussionParser isn't grabbing it correctly.

Any luck on this? I think @Legoktm is probably right that this was a simple bug introduced at one point.

So testing locally, it looks like it only includes the section header in the email alert if it detects a signature.

In T218724#5657896, @Bawolff wrote:

So testing locally, it looks like it only includes the section header in the email alert if it detects a signature.

I can't think of a good reason for this, great if that limitation could just be removed. MassMessage deliveries typically do not include identiable signatures, and they are a very important use case.

Best would be to have custom behavior if it's from the MassMessage bot, with no pointless authour information, and the section header in the title of the email. (so people know what the message is about before clicking).

So digging further into the code (line 588 DiscussionParser.php), I can confirm, that mass message bot messages get classified as unknown-unsigned-addition (probably because the fake sig that involves interwiki links) which don't send the header. Its unclear to me if that's generally something that should change for all unsigned-addition's or if we should special case it for mass message. Like if someone adds a section, why does it matter if they sign their edit or not?

Would it be possible to just make a quick exception for MassMessage for now? Then we can figure out later if the limitation makes sense in general for unsigned additions.

Its probably technically easier to do it for all (although probably politically harder)

I guess noone objects to changing behavior in case of MassMessage? I would rather not wait another year for this, let's agree to just do that part.

Just as an aside, I just got an email notice about arbcom election, and flow did seem to be able to get the section header (probably because it was signed by mass message bot) - but the results were still subpar.

The subject was MediaWiki message de...‬ left you a message on Wikipedia

And the body of the email was:

MediaWiki message de...‬ left a message on your talk page in "‪ArbCom 2019 election voter message‬".

Hello! Voting in the 2019 Arbitration Committee elections is now open until 23:59 on Monday, 2 December 2019. All eligible users are allowed to vot...

Which is better than the interwiki case, but still not great.

MassMessage does not send emails. Is this about notifications send on pages on watchlist?

In T218724#7651969, @Nikerabbit wrote:

MassMessage does not send emails. Is this about notifications send on pages on watchlist?

On talk pages, rather (the "Edit to my user talk page" / edit-user-talk Echo notification).
It might be relevant for watchlist emails as well once T203941: Allow watchlist notifications to be delivered as web notification (through Echo) lands; the current watchlist emails do not have any section support.

I think this might be Resolved?
It seems to be fixed, from the old bug described in section header.
At least in plaintext-output mode.

E.g. 2021:

but 2022/now:

I don't think that's new. For instance I have an email from 2019:

‪MediaWiki message de...‬ left a message on your talk page in "‪ArbCom 2019 election voter message‬".

Hello! Voting in the 2019 Arbitration Committee elections is now open until 23:59 on Monday, 2 December 2019. All eligible users are allowed to vot...

View message: https://en.wikipedia.org/wiki/User_talk:Nemo_bis?markasread=176292205&markasreadwiki=enwiki#ArbCom_2019_election_voter_message

followed a few days later by:

‪MediaWiki message de...‬ left a message on your talk page.

View message: https://en.wikipedia.org/wiki/User_talk:Nemo_bis?markasread=176658163&markasreadwiki=enwiki

Notice that there are different messages being used to compose those email bodies. One is notification-header-edit-user-talk-with-section.

The basic problem is probably the usual, that Echo fails to parse the pieces of information it needs (section title, username, text snippet, whatever). I'm not sure how to tell whether it even tried or whether MassMessage's posting method influences the result.

Ah, good point. Yeah, I think this might still need developer-investigation then.
Interestingly, here two examples of the same newsletter (Books & Bytes), in which one worked well (2022) and the other didn't (2021).

• Included good details in email: https://en.wikipedia.org/w/index.php?title=User_talk:Quiddity&oldid=prev&diff=1069484824&diffmode=source
• Had no details in email: https://en.wikipedia.org/w/index.php?title=User_talk:Quiddity&oldid=prev&diff=1002658414&diffmode=source

I wonder, @Samwalton9 do you remember if anything changed with the way you setup the delivery, in the last year? The wikitext seems to be identical, so maybe it was something in the MassMessage interface that was selected differently? (if not, no worries, unsubscribe from here freely :) )

I wonder, @Samwalton9 do you remember if anything changed with the way you setup the delivery, in the last year?

I don't have any recollection of doing anything differently :)

I went through my email inbox, it started working (displaying the section header in the email) sometime in the period between 5/12/15 and 6/28/15, and stopped working sometime in the period between 4/27/2016 and 5/21/2016. @Legoktm do you recall what changes you might have made about these times?

Did some late-night hacking with @jeremyb recently, and was able to confirm that a message with a subject header that is too long for MassMessage fails to show in the email notification, but that the exact same message works for a user manually leaving it. Email notification only works on MassMessage if the header is very short.

Two MassMessages I sent on May 25 https://en.wikipedia.org/w/index.php?title=User_talk:Pharos&oldid=prev&diff=1089767985 and https://en.wikipedia.org/w/index.php?title=User_talk:Pharos&oldid=prev&diff=1089772397 worked correctly in terms of posting the section header in the email (yes, the latter was the infamous accidental "Bison" stampede). I get the impression that there is perhaps a 10-character limit to section headers. I have not been able to replicate this functionality since, no matter the number of characters, have there been some technical changes recently?

OK, on further experimentation, it communicates the subject header to email if it has a character length of 10 or fewer, and only if there is no message body. If there is a message body, it communicates the first 150 characters to email (removing the last 3 with an "..."), and it seems to fail if there are fancy templates involved.

On further further experimentation, it appears that most of the problem came from using ~~~~~ instead of ~~~~! Using the standard 4 tildes, which we had been avoiding to have a custom signature, the first few words of the subject does now show up in the email message.

In T218724#7974506, @Pharos wrote:

On further further experimentation, it appears that most of the problem came from using ~~~~~ instead of ~~~~! Using the standard 4 tildes, which we had been avoiding to have a custom signature, the first few words of the subject does now show up in the email message.

The 4 tildes vs 5 tildes thing may only be an issue on enwiki but not on meta, not sure what setting might control this.