Notification email footer shows raw notification type key

[karl-bullock]

Current Behavior

The notification email footer shows the raw notification type key instead of a readable name. For example a mention email reads:

This email was sent to user@example.com because you are subscribed to "postMentioned" notifications on My Forum.

Any notification type does this, including ones from extensions (e.g. "linkrobinsSupportNewReply").

Expected Behavior

The footer should show a human readable notification name, like the wording used on the notification settings screen, not the internal type key.

Steps to Reproduce

1. Receive any notification email (for example a post mention).
2. Read the footer line "...you are subscribed to {type} notifications...".

Cause

NotificationMailer passes the raw type into the footer text:

$type = $blueprint::getType();

That value is interpolated directly into core.email.notification.footer.main_text as {type}, so the machine key is shown verbatim.

[karl-bullock]

I am happy to send a PR. Which approach would you prefer?

1. Drop the type from the footer wording, e.g. "...you are subscribed to notifications on {forumTitle}", and stop passing {type}. Simple, no API change, removes the raw key.

2. Add a backend source for a readable name, e.g. a method on MailableInterface with a default, and use it in the footer. Proper fix, but it is an interface change and each notification type needs a translation key.

Happy to go either way, just want to match what you would accept before writing it.

[imorland]

Not sure about this one, this is working "as designed" right now.

[karl-bullock]

I'll dig into it some more.
I've had 5 sites stand up back to back with the same issue.

[karl-bullock]

I dug into this properly and captured real rendered emails to confirm it. I think it's less "working as designed" and more an unfinished placeholder: the footer can't render a readable name as things stand.

What a recipient actually gets. A real postMentioned email from a test install (mail driver = log):

Subject: KBExit replied to your post in TOC heading test discussion

...

This email was sent to tester7@example.test because you are subscribed to "postMentioned" notifications on Flarum.

Note the subject is perfectly readable, while the footer prints the internal key. It is identical for extension types; real emails from my support extension render ...subscribed to "linkrobinsSupportNewReply" notifications... and "linkrobinsSupportNewTicket".

Why it can't be readable today.

• NotificationMailer::send() sets $type = $blueprint::getType() (the raw machine key) and shares it into the view.
• views/email/{html,plain}/notification.blade.php interpolate it straight into core.email.notification.footer.main_text as {type}.
• Nothing translates or humanises $type on that path.

The readable names only exist on the frontend, in NotificationGrid.notificationTypes(), where each type is registered with a hand-picked label key (e.g. discussionRenamed -> core.forum.settings.notify_discussion_renamed_label). There is no programmatic mapping from the type key to that label and it is not exposed server-side, so the mailer has nothing readable to use. Every notification email, core and extension alike, therefore prints an internal identifier to the recipient.

Two ways forward:

1. Drop {type} from the footer wording ("...because you are subscribed to notifications on {forumTitle}"). No interface change, no BC, and nothing readable is lost, since the subject already says what the email is about (see above). This is what I would suggest.
2. Add a server-side readable-name source (an optional blueprint method returning a translated label, defaulting to omitting the type). Keeps per-type specificity, but it is an interface addition with BC cost and needs a key per type.

[karl-bullock]